Tdc 2013 alm com dev o ps

Editor's Notes

• #4: An entertainment company routinely spent 2 weeks just getting the software to work in the test lab
• #7: Customers practicing Application Lifecycle Management (ALM) have many choices to make in how they define their disciplines, roles, and workflows. Many lifecycle tools are available from commercial vendors and in open source that will support those disciplines and roles. These tools as a whole offer more than adequate support for individual disciplines and the associated types of users. But ALM is about coordinating across those disciplines and roles. This is always a challenge, and even more so when operating with tools stemming from many different sources.
• #8: One response is to consolidate all lifecycle tools from a single vendor. A common vendor gives the best chance of getting an integrated development and support solution. The problem is that most organizations—for a variety of reasons—simply cannot do that. They can ’t just rip out tools from disciplines that have mature practices in place, even if they wanted to. Sometimes they can migrate from the old to the new. But even those situations require a transition period where both systems must coexist for at lease some amount of time. So the challenge is, how does one gain the benefits of practicing ALM and yet retain operational use of tools that are in place and working well enough? Doing so requires that the tools interacts in a way such that data from one tool can be traced to related data in another tool (traceability). Doing that will provide users in one discipline insight into data created and managed by other users in different but related disciplines with the tools that they use (visibility). And in doing all of that, users across disciplines can find more efficient and effective ways to work together in the overall software delivery process (collaboration). The key to making all of this happen is lifecycle tool integration. And its been done over the years in many different ways. The problem is that those ways of integrating aren ’t working very well—especially across tools stemming from a variety of sources.
• #9: So what exactly is so wrong with how integrations are handled today? First, integrations are typically an afterthought of product development. Vendors start out trying to solve a specific and relatively narrow part of the overall lifecycle needs and deliver a point-product. Examples include compilers for code development, SCM tools for version management, automated testing tools for Quality Management, etc. Once these tools do their particular job well, vendors other tools with which they need to integrate. But by then, the tools are disparate—they provide vendor-specific Application Program Interfaces (API) that generally don ’t match up with APIs from other tools. Nonetheless, two tools can be integrated one way or another. And that ’s how things start out: point-to-point. The problem then is that, as more and more tools need to interact, the combinations grow exponentially. Developers quickly find that point-to-point integrations done with conventional approaches simply don’t scale. They are hard to develop, and even harder to maintain. Customers become quickly disenchanted with the results and eventually give up on trying to make such a solution work across any broad scale of deployment. More importantly, customers that do stick it out with these integrations find themselves locked into not only the vendor-specific lifecycle tools but also their integrations. This results in tremendous inflexibility for the customer to respond to changing business conditions. Consequently, over time, the cost of maintaining their ALM lifecycle tool solution grows significantly with no abatement in sight.
• #11: Jazz é uma iniciativa para transformar nossa visão em realidade. Jazz é uma platforma para transformar como as pessoas trabalham em equipe, com o objectivo final de melhor alinhar o trabalho com valor comercial
• #13: Key to our vision is the Open Services for Lifecycle Collaboration initiative. In 2008 we launched this initiative with key partners and vendors. Our collective goal is to enable teams to use the tools they want and share lifecycle resources in delivering software, whether the tools are from IBM, other vendors, open source projects, or in-house development. We aim to do so in a way that is open and non-proprietary and that will encourage all industry members to collaborate. We're gratified with the progress of this initiative to date, which has grown to encompass all of the companies you see here. FAQs on OSLC What is IBM announcing? IBM is introducing an initiative, called Open Services for Lifecycle Collaboration, aimed at simplifying collaboration across the software delivery lifecycle. Our goal is to enable teams to use disparate tools and share lifecycle resources in delivering software, whether the tools are from IBM, other vendors, open source projects, or in-house development. We aim to do so in a way that is open and non-proprietary and that will encourage all industry members to collaborate.   Specifically, we're publishing several things at Jazz.net, including an initial set of descriptions for lifecycle resources such as requirements and test cases, as well as protocols and services for accessing these resources. We're also providing code that illustrates usage of these protocols. We hope that by openly sharing our ideas and sample code, our efforts will promote cross-industry collaboration that will lead to agreement on a common architecture and to both commercial products and open source projects that implement these protocols. What problem are you trying to solve? The software delivery tools marketplace of today grew organically from point tools aimed at solving specific narrow needs in the software delivery lifecycle. Teams and organizations who are concerned with all aspects of software delivery have historically had to rely on multiple point-to-point integrations between tools. Consequently, this has created barriers for teams to collaborate and have made cross-lifecycle processes and cross-tool integrations expensive to create, complex to manage, and difficult to change over time, despite the best efforts of tools vendors to integrate their own tools or create alliances with complementary vendors.   The increasing focus in software delivery on governance and business alignment make it imperative that the industry move to solve the closely-related problems of tool interoperability and lifecycle collaboration. Our goal is to find a means for allowing tools to readily share lifecycle resources, enabling organizations to more easily integrate, manage, and evolve lifecycle tools and processes for software delivery in response to new business demands. What fresh approach does IBM bring to the solution of this challenge? First, IBM’s experience has identified three degrees of interoperability that are relevant to this challenge: (1) fundamental services that allow different tools to share and exchange the data that they produce; (2) common understanding of relationships between lifecycle resources, such as test cases and requirements; and (3) detailed agreement on the information in an resource, such as a Use Case. A successful solution to this challenge must allow for any and all of these degrees of integration, without forcing tools to agree at the most detailed level where that isn’t necessary. Second, we recognize that the interoperability mechanisms must be robust and flexible allowing companies to easily upgrade individual tools without breaking tool integrations or process flows. A successful solution to this challenge cannot be dependent on close cooperation or continuous coordination between vendors. That’s why our proposal relies heavily on the architecture of the web, which robustly integrates disparate providers of information and services. Similarly, we model our approach on Web 2.0 concepts such as mashups, exploiting document formats, metadata and services rather than traditional brittle APIs. Third, any eventual solution must be recognized as being independent of one vendor’s control. To that end, in the future we’d like to explore the role that open standards and open source projects might play in ensuring that agreed-to protocols and resource descriptions will be freely and equitably available and evolve under independent governance. To promote discussion and help people to understand the ideas being proposed, we are also making illustrative code available under an open source license. What are you making available on Jazz.net? We are making available documents outlining the Open Services for Lifecycle Collaboration initiative as well as sample implementations of the services and resource descriptions. The documents (1) outline IBM’s motivations for this initiative and discuss the architectural principles and technical underpinnings for the proposed resource descriptions and services; (2) suggest a topology of lifecycle resource types and initial descriptions for a core set of resource types, including requirements and test cases; and (3) describe an initial set of protocols and services for accessing resources, including services for retrieving and updating resources, for collecting resources into projects, and for controlling access to resources. Additionally, we’ve published sample implementations for the resource descriptions and for the services. What do you expect people to do with what you’ve published on Jazz.net? What are the next steps? The documents and sample code published on Jazz.net are intended to start the discussion by illustrating our ideas. We encourage other vendors and members of the community to examine these resources and begin the dialog with us and each other that can lead to a common approach for achieving lifecycle collaboration. Image licensed with attribution per following: http://en.wikipedia.org/wiki/Image:Web_2.0_Map.svg
• #16: From the Agenda: In this “new normal,” the most forward thinking companies will: Establish an enterprise capability for accelerated delivery of software that enables them to seize market opportunities and reduce time to customer feedback, improve governance while balancing quality and cost
• #18: When it comes to ALM solutions, one size does not fit all. That’s why IBM provides a comprehensive set of ALM capabilities you can mix and match to meet specific team needs. Rational ALM capabilities have been designed to fit the way you already work and extend the software infrastructure investments you have already made. And it’s the only solution that will provide you with seamless interoperability across heterogeneous platforms, including distributed systems, System z and Power systems. Rational ALM capabilities include:   Requirements management IBM Rational Requirements Composer, IBM Rational RequisitePro and IBM Rational DOORS Architecture Management Rational Application Developer, Software Architect, and Rhapsody     Change and Software Configuration Management Rational Team Concert ClearQuest, ClearCase, Change/Synergy, Build and Deploy management Rational Team Concert, IBM Rational Build Forge Quality Management IBM Rational Quality Manager, Performance Tester, Functional Tester and SOA Services Tester   Collectively, these capabilities empower your organization to: Meet the domain-specific needs of skilled practitioners, while enabling a real-time flow of information and ideas. Improve collaboration across teams and geographies through consistent access to team process, workflow and artifacts Enable continuous and measurable capability improvement by combining fact-based reporting and metrics with best practices. Automate and enforce any software and systems delivery process, with extensive support for Agile practices
• #19: When it comes to ALM solutions, one size does not fit all. That’s why IBM provides a comprehensive set of ALM capabilities you can mix and match to meet specific team needs. Rational ALM capabilities have been designed to fit the way you already work and extend the software infrastructure investments you have already made. And it’s the only solution that will provide you with seamless interoperability across heterogeneous platforms, including distributed systems, System z and Power systems. Rational ALM capabilities include:   Requirements management IBM Rational Requirements Composer, IBM Rational RequisitePro and IBM Rational DOORS Architecture Management Rational Application Developer, Software Architect, and Rhapsody     Change and Software Configuration Management Rational Team Concert ClearQuest, ClearCase, Change/Synergy, Build and Deploy management Rational Team Concert, IBM Rational Build Forge Quality Management IBM Rational Quality Manager, Performance Tester, Functional Tester and SOA Services Tester   Collectively, these capabilities empower your organization to: Meet the domain-specific needs of skilled practitioners, while enabling a real-time flow of information and ideas. Improve collaboration across teams and geographies through consistent access to team process, workflow and artifacts Enable continuous and measurable capability improvement by combining fact-based reporting and metrics with best practices. Automate and enforce any software and systems delivery process, with extensive support for Agile practices
• #22: Author Note: Mandatory Rational closing slide (includes appropriate legal disclaimer). Graphic is available in English only.