What is Rational CLM?

Editor's Notes

• #4: Software is the invisible thread that enables systems-of-systems – large-scale, concurrent, distributed systems, that themselves are comprised of, or connect to, other complex systems. In a smarter planet, software is mission critical, so we need to look beyond software development to software and systems delivery . And let’s put it into an industry context – an industry that has the potential to touch all of us … healthcare . We see here an example of software-driven systems of systems that are used to deliver emergency cardiac care within a six-minute response window. Heart disease is the leading cause of death in the U.S., and is expected to cost more than $316 billion dollars this year alone. We start with our patient, who suffers from heart disease, and has an implanted medical device that monitors and regulates his heart... Unfortunately, today the patient is having a severe event that the implanted device has sensed and is wirelessly notifying the cardiac center that, in turn, can perform remote monitoring and data diagnosis. In a typical scenario, a patient whose heart has short-circuited has an average of six minutes to live – so response time is paramount. In the U.S., the national standard set by emergency responders is four minutes in 90% of all emergencies . So, we need to leverage technology here for faster, more-informed decisions about the patient – and we know that in these cases, response time of less than five minutes doubles survival rate . We also need to use the cardiac specialist’s time efficiently. Because the cardiac center staff has access to data from the device as well as other patient information, their reaction is swift. They notify ambulance dispatch with the patient’s location that they got from GPS in the device – along with an initial assessment of the event. In parallel, the on-call cardiac specialist is notified via preferred contact method – in this case a handheld device. Initial patient data can be pushed to the handheld, and the specialist has immediate access to the patient’s electronic medical record and can remotely monitor the patient. Ambulance dispatch prioritizes its response based on severity of the event, location, available staff, and ambulance readiness . Many dispatchers use systems to help with prioritization. Unfortunately, only 10% of ambulance calls are true life-and-death situations . Which mean there’s plenty of potential for sub-optimal response and utilization of resources. But in this case, since dispatch is operating off of the initial patient information, prioritization and decision support are immediate. In this part of the scenario, our invisible software thread includes ambulance queuing and decision support systems , as well as notifications of ambulance service readiness, inventory, and onboard staff skill levels . The ambulance arrives at the patient location . The ambulance personnel have real-time access to a virtual team of experts that can guide them with triage of the patient – including data and transmitted images. It enables the team to determine the optimum care center for this specific case – on-the-fly, and update best travel route to that location, and then communicate directly with the target facility to optimize emergency department readiness and response for this specific case. Including sending relevant patient information. [CLICK] And by arriving in less than five minutes they’ve doubled the chances of patient survival. Enabled by: 50-plus million lines of code in the vehicle 1,000 software components, each with 10 different interfaces 10,000 interfaces to track, update, test, deploy and maintain for the next 15 – 20 years Integration with vehicle monitoring system Real-time data transfer of patient vitals to virtual team
• #5: For anyone using the modern healthcare system you already know it is complex. healthcare delivery is a good example of an evolving mission-critical system-of-systems. Simply looking at the emergency response system itself , is already a complex system-of-systems. For example, in order to respond to an emergency call fast enough to save people’s life, the systems of systems including medical devices, ambulances, electronic healthcare record systems, healthcare specialists’ handhelds, GPS based data recording and intelligent traffic control systems must work together to send ambulance and related people to the patient’s home within a few min .
• #8: So we’ve just seen how important software is – in the previous example, literally a matter of life and death in the case of our cardiac care patient, and from a different perspective, at the heart of a $316 Billion health care problem. So how are we as an industry, doing at delivering high quality software on time and on budget? As you can see from this chart, barriers to effective software delivery remain. According to the Standish Group, only 34% of software projects are successful… Studies from McKinsey Quarterly show that less than 25% of executives felt that their IT investments were even aligned with their strategy! And our US Department of Commerce planning report, just looking at one discipline area – requirements management – costs US over $30 B annually. ------------------------------------------------------------------------------------ Most organizations can achieve clarity within a single team, project, or a discipline. When we multiply our need for clarity against the thousands of projects delivered with disparate teams, using different sets of tools and distinct processes and workflows, ut where we as a organizatiosoftware delivery breaks down is through a failure to view multiple teams, projects, disciplines and Sources 1) 'Software related downtime costs industry almost $300 billion annually", CHAOS Chronicles v12.3.9, The Standish Group, June 30, 2008. 2) Roger Roberts, Johnson Sikes, "IT's Unmet Potential", McKinsey Quarterly , November 2008 3) Planning Report 02-3, The Economic Impacts of Inadequate Infrastructure for Software Testing, Prepared by RTI for National Institute of Standards & Technology, Program office, Strategic Planning and Economic Analysis Group, May 2002, US Department of Commerce.
• #9: Five years ago we at IBM – who have been helping customers develop and deliver software for more than 50 years – decided to look at this question from a fresh perspective. And the question that we asked is, how can we fundamentally transform software delivery? How can we break down the silos between developers and testers, between IT and business stakeholders? We at IBM believe that what's needed is a fresh approach to solving the core problem of tool integration across the software lifecycle -- a software development platform. The KEY to a platform is that it replaces one vendor's view of the world (even our own view) with an open and extensible view that enables any vendor to participate. One that delivers real-time, transparent access to project data, risks and progress across the preferred environment that YOU choose -- including tools from IBM, competitors and open-source alternatives.
• #11: Agile development is defined by principles, patterns and practices. Principles define the high-level rules that each party to the project agree too and these have been outlined originally in the Agile Manifesto (www.agilemanifesto.org/) and are driven now by the Agile Alliance (www.agilealliance.org). Agile development values include: Individuals and interactions Working software Customer collaboration Responding to change Patterns help identify the current state by a set of constraints and a problem classification. Patterns cover organization as well as identify specific practices to put in place. Practices are small procedures that are followed to complete a task. While traditional development lives by a formal well-defined process, agile methods are themselves agile, adapting to the conditions and focusing on a specific outcome rather than a simple checklist of steps. The shift to dynamic script languages will be another driver toward agile development and the need for increased use of unit testing and source management solutions.
• #17: D1_Sabbah 12/07/11 13:44 IBM Rational
• #18: Innovate 2010 12/07/11 13:44 D4_Royce
• #23: End to end traceability that is seamless in all three products. If a tester finds a defect and can trace it to a use case, submit the defect and it will link to all the things associated to it. Thus the developer can see it is blocked and why and its all automatic. Don’t have to ask. Link artifacts and connect the dots so every artifact has the proper upstream and downstream relationship Send links to artifacts that lead to current artifact versions and sets the related artifact context including reviews and comments from other team members Link critical project artifacts so that the entire team have access to the latest version of the truth When organizations fail to deliver quality software on time and on budget, it is typically not because any individual is dysfunctional, but because the entire team or organization is misaligned. End-to-end visibility enables organizations to proactively steer projects to success based on real-time information.    The second imperative, End-to-end lifecycle traceability is a perquisite for meaningful insight into project status, issues and risks. For example, the question, “Are we ready to release?” requires knowledge that can only be gathered by correlating requirements, code, build, and test information—data that potentially resides in four different repositories. The ideal environment will allow teams to easily link related assets and maintain those linkages as assets evolve.   Traceability is the ability to gain an end-to-end view across your project lifecycle. When your software is delivered to the customer, you should be able to identify all the activities associated with the software. You should be able to answer all of the stakeholder questions on this slide. And you should be able to state with confidence that the software includes this specific requirement, included in this software build, validated by this test case and with this test result. Anything less, and you really don’t know what you are delivering and whether what you are delivering will meet your quality requirements. --------------- Traceability isn’t simply one of those “nice to have” capabilities in the software development  lifecycle. Traceability helps you understand what everyone else on the team is doing. For example, while the requirements analyst knows very well what requirements she has written, she still needs to know whether a given requirement will be addressed during a specific development iteration and, if so, which one. Or she wants to know if the implementation of that requirement has been tested and with what result. An ALM solution that allows for lifecycle artifact traceability helps teams to answer the hard questions about requirements and risk management. By linking related artifacts, teams are better equipped to answer questions such as “which requirements are affected by defects?” and “which work items are ready for test?”   It is important to understand how requirements, test and development are linked by projects and tasks. DON’T Do traceability for traceability sake. Identify a few meaningful questions or set one goal and institute a “just enough” approach for linking related artifacts. For example, link requirements and test cases, link test cases and development work items. Try one and get good at it before doing more. DON’T Rely on reports that go stale after you’ve created them. Practice continuous traceability: Leverage a system that shows the traceability links directly on the plan, or that uses queries that identify gaps, such as “Plan items without requirements” and “Plan items without test cases”, and “Defects blocking test.” DON’T Ignore, hide from or hope to pass regulatory audits Invest in an ALM solution that makes traceability easy to do, maintain and report against. DON’T: Work in disconnected project repositories, or cobble together a disparate set of tools. Seek products built with open interfaces. Seek vendors who understand and support the ALM integration challenges. Invest in tools with a longer-term integration roadmap in mind. DON’T: Enter links manually after the fact, it’s easy to forget, hard to enforce. Integrated tools make it easy to establish as the project executes. See image of linked Defect in upcoming slide DON’T: Build your own integration based on proprietary API’s. Choose a solution with open services (OSLC) for linking data across the lifecycle. DON’T: Choose a one-size-fits-no-one solution. Invest in a loosely coupled, integrated ALM solution that is built to scale and support open and flexible integrations. A single ALM repository will not scale to fit your needs over time. Times change, new products emerge; your ALM solution needs to be flexible enough to move with the times. Do you really want to face that data migration challenge? Many tools, document formats and repositories create “information islands”, making it hard to find, relate and use this information as requirements artifacts as well as use use it to inform downstream lifecycle activities Hard to relate it together, keep it coherent, and maintain those relationships. Team members undertake heroic measures to consolidate it understand, monitor status, and make decisions based on this information. These manual processes often don’t scale and introduce errors This leads to .. Wasted team effort due to duplication and lack of version control / change management … “Which version of that document should I be looking at?” Challenges in scaling current practices and making them repeatable Too many project surprises due to poor or missed requirements Information overload: challenges finding, using, and reusing information
• #24: A Workbench is a combination of products, services and practices designed to accelerate customers' software delivery transformation in a key focus area. Workbenches can support different types of focus areas, including vertical industries (i.e. automotive); best practices (i.e. requirements-driven testing) and technology domains (i.e. quality management). Workbenches are pre-configured and tested together to optimize transformation. They are supported by best practices guidance and professional services to accelerate customer deployment and results.
• #27: 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
• #29: Now that we are delivering on our vision, we are gaining the accolades of analyst firms, like Gartner, who track and evaluate vendors' ability to deliver on integrated ALM solution. And as you can see here, IBM is the only vendor -- of twelve vendors evaluated -- who was rated as Strong Positive, because of its current market strengths, breadth of portfolio, and the solid architectural foundation of the Jazz platform.
• #30: Jazz.net is a transparent software delivery laboratory where you can see our own products being built, using our own tools. It's also the home of our Jazz user community, where users can engage directly with the engineers building and refining our products, and has helped us significantly improve the level of direct customer communication. Jazz.net is the place where you can... Communicate with the development team Track the progress of builds and milestones Get the latest product trials and betas Join developers and product managers in discussion groups Submit defect and enhancement requests EZ Insight, Inc. Report, July 2009, “ The IBM Rational Jazz Strategy for Collaborative Application Lifecycle Management“ by Liz Barnett : "With the Jazz project, Rational has developed breakthrough technology and is poised to set the standard for collaborative ALM... Download the report Paul Herzlich , Ovum: "IBM has taken the opportunity to exploit the Jazz platform’s power inventively. Its ‘living’ test plan is a masterpiece of applying new technology to a familiar problem… What is being delivered will demonstrate convincingly that IBM is raising the standard for a test management product.“* Julie Craig, EMA : "Rational’s differentiators are difficult for competitors to equal, and the new Jazz platform foundation may well turn out to be one of the best investments the Rational team has made.” Forrester Wave - Agile Development Management Tools report: “Rational has the best current offering….and continues to raise the bar on building a complete development and delivery platform.” Download the report in the agility@scale ekit Yphise independent research : “Rational Team Concert certified as the best ranked solution for boosting team collaboration during software projects”. Download the report in the agility@scale ekit
• #32: Closing slide to be included in all external presentations. Learn more at: IBM Rational software: www.ibm.com/software/rational IBM Rational Software Delivery Platform: www.ibm.com/software/info/developer Process and portfolio management: www.ibm.com/software/rational/offerings/lifecycle.html Change and release management: www.ibm.com/software/rational/offerings/scm.html Quality management: www.ibm.com/software/rational/offerings/testing.html Architecture management: www.ibm.com/software/rational/offerings/design.html Rational trial downloads: www.ibm.com/developerworks/rational/downloads Leading Innovation Web site: www.ibm.com/software/rational/leadership developerWorks Rational: www.ibm.com/developerworks/rational IBM Rational TV: www.ibm.com/software/info/television/index.jsp?cat=rational&media=video&item=en_us/rational/xml/M259765N40519Z80.xml IBM Rational Business Partners: www.ibm.com/partnerworld/pwhome.nsf/weblook/index.html IBM Rational Case Studies: www.ibm.com/software/success/cssdb.nsf/topstoriesFM?OpenForm&Site=rational