Helping CMMI Adoption and Return on Investment With Integrated Lifecycle Solutions Dominic TAVASSOLI Director of Product Marketing 1 © Telelogic AB Development process challenges • Producing more quality software with less – Maintain quality level and number of simultaneous projects – Limited resources • Increasing Complexity – Embedded software everywhere (cars, phones…) – e-Business, Intranet… – Reliability, performance… • Team structure is also complex – Distributed team on the same project • Geography, time zones, language, culture… – Offshore development – Need foolproof Communication & Collaboration 2 © Telelogic AB What's a process? • A process is a set of practices performed to achieve a given purpose – May include tools, methods, materials, and/or people. • “The quality of a product is largely determined by the quality of the process that is used to develop and maintain it.” – Underlying premise of process improvement • Process improvement… – To make the most of your human resources • "Work smarter, not more" – Optimize software tool usage • Tools should support a process 3 © Telelogic AB What is a CMM? • Software Engineering Institute's Capability Maturity Model – How do you evaluate a software company? – Origin back in 1983, first version 1991, v1.2 in 2006 • A reference model of mature practices • All work is viewed as "processes" • Each level consists of key process areas e.g. CM at level 2 – Incremental process improvement – List of steps to ensure you build & master your processes • “All models are wrong, but some are useful.” -George Box • http://www.sei.cmu.edu/cmmi/products/models.html Capability Maturity Model®, CMM®, CMM Integration, and CMMI are service marks and registered trademarks of Carnegie Mellon University © Telelogic AB Actual project effort vs. predicted Demonstrated success +140% Improved planning, predictability 0% -140% . . ... .... .. .... . . . . . .. ... . . .. .. . .............. ... ............................ . .. .. .... . . .... . . . . ... .. .. ... . .. . .. . .. . . .. . ... . .. .. .. . . .. . . . .... . .. . . . . .. . . .. ..... .... . . . .. .. .... .. . . . . . . . . .. Without Historical Data With Historical Data . Variance between + 20% to - 145% (CMM levels 1 & 2) Variance between - 20% to + 20% (CMM level 3) (Based on 120 projects at Boeing Information Systems) Ref.: John D. Vu. “Software Process Improvement Journey:From Level 1 to Level 5.” 7th SEPG Conference, San Jose, March 1997. 5 © Telelogic AB CMMI Performance results - 2005 • Improvements measured and reported by CMMI-assessed organizations: Productivity: 67% Quality: 50% Schedule: 37% Cost: 20% Customer Satisfaction: 14% • Mean Return on Investment measured = 4.8 : 1 – Varies from 2:1 to 27.7:1! © 2006 by Carnegie Mellon University 6 © Telelogic AB What's the CMMI ? • The SW-CMM model (Software CMM) was a victim of it's own success – Creation of many derived models (Systems engineering, human resources…) – Hard to know which to implement • CMMI was introduced in 2000 (I as in "integrated") – Integrating the better elements of all models – Feedback from over 20 years usage & + 5000 organizations – Two representations of the model • Formal assessments and certification – Not military-specific! – Of the 878 organizations assessed in 2005 by the SEI, 64% were Commercial/In-House © Telelogic AB Two CMMI models Staged Continuous Process Area Capability ML4 ML3 ML2 ML 1 PA PA PA . . .for a single process area or a set of process areas 8 ML5 . . .for an established set of process areas across an organization ML: Maturity levels © Telelogic AB Maturity levels • "If you master your process, you'll reduce risk and improve productivity" Optimizing 5 4 Continual process improvement Quantitatively Managed Process driven and measured, predictable Defined 3 Organization standard process, consistent and proactive Managed 2 Process per project, often reactive Initial 1 9 Unpredictable process, little control, reactive © Telelogic AB CMMI Process Areas • Engineering – – – – – – Requirements Management Requirements Development Technical Solution Product Integration Verification Validation • Support – – – – – 11 Configuration Management Process and Product Quality Assurance Measurement and Analysis Causal Analysis and Resolution Decision Analysis and Resolution • Project Management – – – – – – Project Planning Project Monitoring and Control Supplier Agreement Management Integrated Project Management Risk Management Quantitative Project Management • Process Management – – – – Organizational Process Focus Organizational Process Definition Organizational Training Organizational Process Performance – Organizational Innovation and Deployment © Telelogic AB Requirements Management • Purpose: – Manage the requirements of the project’s product and product components and identify inconsistencies between those requirements and the project’s plans and work products. • Key practices: – Obtain an Understanding of Requirements – Obtain Commitment to Requirements – Manage Requirements Changes – Maintain Bidirectional Traceability of Requirements – Identify Inconsistencies between Project Work and Requirements 12 © Telelogic AB Capturing requirements in a central repository Capabilities: • Intuitive system for capturing business and system requirements • Automatic traceability of requirements throughout the project • Process for managing changes to requirements and making impact analysis • History and baselines to control scope creep Benefits: • • • • 13 Confidence that all requirements are fulfilled Confidence that every effort fulfils a requirement Simplified maintenance of final system Focused development resources © Telelogic AB Requirements Development • Purpose: – Produce and analyze customer, product, and product-component requirements. • Key practices: – Develop Customer Requirements – Develop Product Requirements – Analyze and Validate Requirements 14 © Telelogic AB Requirements Development 15 Develop Customer Requirements Develop Product Requirements Customer Requirements Product Requirements Analyze and Validate Requirements Validated Requirements © Telelogic AB End-to-end visual traceability User Reqts 1. 820.30(b) Design and Development Planning Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process. Technical Reqts Design 1. 820.30(b) Design and Development Planning Comply with FDA Design Control Guidance GMP Regulation Comply with FDA Design Control Guidance GMP Regulation Each manufacturer shall establish and maintain plans that describe or reference the design and development 1.1. Identify impacted elements due to a change in another element activities and define responsibility for implementation. 1. Capture design and related information 1. Capturewith design and related information driving design elements Traceability Reports: consistency 1.1. Input electronically formatted data Input electronically Impact Reports: other design1.1. elements affected formatted data The plans shall identify and describe the interfaces with different groups or activities that provide, or result 1.2. Reference external information sources 1.2. Reference external information sources Links to impacted design elements in, input to the design and development process. 1.3. Reference external documentation 1.3. Reference external documentation 1.1.1.Create backward traces to design elements within and across any organizational The plans shall be reviewed as design and development evolves. The plans shall be updated as design and development evolves. The plans shall be approved as design and development evolves. 2. 820.30(c) Design Input 2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. 2.3. The procedures shall include a mechanism for addressing incomplete requirements. 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 2.6. The design input requirements shall be documented by a designated individual(s). 2.7. The design input requirements shall be reviewed by a designated individual(s). 2.8. The design input requirements shall be approved by a designated individual(s). 2.9. The approval, including the date and signature of the individual(s) approving the requirements, shall be documented. 2.10. Questions. 2.10.1. Summarize the manufacturer's written procedure(s) for identification and control of design input. 2.10.2. From what sources are design inputs sought? 2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and list additional aspects.) 2.10.3.1. intended use 2.10.3.2. user/patient/clinical 2.10.3.3. performance characteristics 2.10.3.4. safety 2.10.3.5. limits and tolerances 2.10.3.6. risk analysis 2.10.3.7. toxicity and biocompatibility 2.10.3.8. electromagnetic compatibility (EMC) 2.10.3.9. compatibility with accessories/auxiliary devices 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors 2.10.3.12. physical/chemical characteristics 2.10.3.13. labeling/packaging 2.10.3.14. reliability 2.10.3.15. statutory and regulatory requirements 2.10.3.16. voluntary standards 2.10.3.17. manufacturing processes 2.10.3.18. sterility 2.10.3.19. MDRs/complaints/failures and other historical data 2.10.3.20. design history files (DHFs) 2.10.4. For the specific design covered, how were the design input requirements identified? 2.10.5. For the specific design covered, how were the design input requirements reviewed for adequacy? The plans shall be reviewed as design and development evolves. 2. Store design and related information 2. Store design and related information procedure The plans shall be updated as design and development evolves. 2.1. Identify and tag design information as unique “design elements” 2.1. IdentifyAttribute and tag design information as unique “design elements” Traceability Reports: Procedure The plans shall be approved as design and development evolves. 2.2. Organize design elements 2.2. Organize design elements 1.1.2.Create backward traces to design elements within and across any project milestone 2.2.1. Organize by Design Control Guidance Element 2.2.1. Organize by Design Control Guidance Element 2. 820.30(c) Design Input Traceability Reports: Milestone Attribute 2.2.2. Organize by inter-relationships 2.2.2. Organize by inter-relationships 2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a 2.3. Ensure all design elements are available 2.3. Ensure all design elements available 1.1.3.Create backward traces to design elements within and are across Design Control device are appropriate address the intended use of the device, including the needs of the user 2.3.1. Store design elements by Design Control Guidance and Element 2.3.1. Store design elements by Design Control Guidance Element Guidance Elements andhistorical patient. values 2.3.2. Store design elements and their 2.3.2. Store design elements and their historical values Reports: Linked design elements Traceability 2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to a Create forward impacts3.to design within and across any organizational device are appropriate and address the intended use of the device, including the 1.1.4. needs of the user 3. Manage all user needs Manage elements all user needs procedure 3.1. Identify the source of the user needand patient. 3.1. Identify the source of the user need 2.3. The procedures shall include a mechanism for addressing incomplete requirements. 3.2. Identify all user types (groups) 3.2. Identify all user types (groups) Attribute Impact Reports: Procedure 3.3. Identify the customer (s) 2.4. The procedures shall include a mechanism for addressing ambiguous requirements. 3.3. Identify the customer 1.1.5.Create forward impacts to design elements within(s) and across any project milestone 3.4. Profile the expected patients 2.5. The procedures shall include a mechanism for addressing conflicting requirements. 3.4. Profile the expected patients Impact Reports: Milestone Attribute 2.6. The design input requirements shall be documented by a designated individual(s). 3.5. State the intended use of the product (family) 3.5. State the intended use of the product (family) 2.7. The design input requirements shall be reviewed by a designated individual(s). 1.1.6. Create forward impacts to design elements within and across Design Control 3.6. Capture the acceptance criteria for each user need 3.6. Capture the acceptance criteria for each user need 2.8. The design input requirements shall be approved by a designated individual(s). Guidance Elements 4. Manage design input requirements2.9. The approval, including the date and signature of the individual(s) approving the requirements, 4. Manage input requirements designdesign elements Impact Reports: Linked shall be documented. 4.1. Identify the source of the requirement 4.1. Identify the source of the requirement 1.2. Associate changed design elements with related elements 2.10. Questions. 4.2. Identify the associated user need 4.2. Identify the associated user need 2.10.1. Summarize the manufacturer's written procedure(s) for identification and LinkofChange Design Object 4.3. withCapture affected design element(s) control 4.3. Capture requirement description and attributes requirement description and attributes design input. 4.4. Capture acceptance criteria 4.4. from Capture acceptance criteria affected design element(s) Traceability Links and Reports 2.10.2. From what sources are design inputs sought? 4.5. Assign responsibility for each requirement 4.5. affected Assign responsibility for each requirement Impact Links and Reports from design element(s) 4.6. Manage incomplete requirements2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and 4.6. Manage incomplete requirements 1.2.1. Associate design element changes with decisions, rationale, and approval authority list additional aspects.) 4.7. Manage ambiguous requirements 4.7. Manage ambiguous requirements 2.10.3.1. intended use information 4.8. Manage conflicting requirements 4.8. Manage conflicting requirements 2.10.3.2. user/patient/clinical following Attributes: 4.9. Approve all requirements Approve all requirements Change Decision Objects4.9.with 2.10.3.3. performance characteristics Disposition Attribute 2.10.3.4. safety 5. Manage acceptance 5. Manage acceptance Decision Attribute 2.10.3.5. limits and tolerances 5.1. Ensure the acceptance of every user need 5.1. Ensure the acceptance of every user need risk analysis Rationale Attribute 5.2. Ensure the acceptance of every design2.10.3.6. input requirement 5.2. Ensure the acceptance of every design input requirement 2.10.3.7. 5.3. Document the results of every user need acceptancetoxicity test and biocompatibility 5.3. Document the results of every user need acceptance test Owner Attribute electromagnetic compatibility (EMC) 5.4. Document the results of every design 2.10.3.8. input requirements test 5.4. Document the results of every design input requirements test Management Approval Attribute compatibility with accessories/auxiliary devices 5.5. Make acceptance results available 2.10.3.9. 5.5. Make acceptance results available 1.2.2.Provide associations within and across any organizational procedure 2.10.3.10. compatibility with the environment of intended use 2.10.3.11. human factors Link on Procedure Attribute Change Design Object 6. Manage change 6. Traceability Manage change 2.10.3.12. physical/chemical characteristics 6.1. Maintain history of design element changes 6.1. Maintain of design Attribute element changes Link history on Procedure Change Design Object Impacts 2.10.3.13. labeling/packaging 6.1.1. Make complete change history available Makeany complete change history available 1.2.3.Provide associations within and6.1.1. across project milestone 2.10.3.14. reliabilityprocedure 6.1.2. Maintain history within and across any organizational 6.1.2. Maintain history within and across any organizational procedure Link on Milestone Attribute 2.10.3.15. statutory and regulatory requirements Change Design Object Traceability 6.1.3. Maintain history within and across any project milestone 6.1.3. Maintain history within and across any project milestone 2.10.3.16. voluntary on Milestone Attribute Change Design Object Impacts 6.1.4. Maintain history within and across any Design Control standards Guidance Elements 6.1.4.Link Maintain history within and across any Design Control Guidance Elements 2.10.3.17. 6.2. Capture frequency and nature of element changes manufacturing processes natureGuidance of element changes 1.2.4.Provide associations within6.2. andCapture acrossfrequency Design and Control Elements 6.2.1. Provide rationale for change 2.10.3.18. sterility 6.2.1. Provide for design change elements Linkrationale to traced Change Design Object Traceability 2.10.3.19. MDRs/complaints/failures and other historical data 6.2.2. Describe decisions made 6.2.2. Describe decisions made to linked elements 2.10.3.20. Change Design Object Impacts 6.2.3. Identify approval authority for the change design history files (DHFs) 6.2.3.Link Identify approvaldesign authority for the change 2.10.4.of approving For the specific design covered, how were the design input requirements identified? 1.3. Mange the change process 6.2.4. Capture date, time, and signature authority 6.2.4. Capture date, time, and signature of approving authority specific design covered, how were the design input requirements reviewed forChange Module 6.3. Identify impacted elements due to2.10.5. a changeFor in the another element 6.3. Identify impacted elements due to a change in another element Design adequacy?within and across any organizational procedure 6.3.1. Create backward traces to design elements 6.3.1. Create backward traces to design elements within and across any organizational procedure 6.3.2. Create backward traces to design elements within and across any project milestone 16 Design Change Reports Object History Object History Reports Versions Baselines 6.3.2. Create backward traces to design elements within and across any project milestone Test Cases 1.1. Identify impacted elements due to a change in another element Traceability Reports: consistency with driving design elements Impact Reports: other design elements affected Links to impacted design elements 1.1.1.Create backward traces to design elements within and across any organizational procedure Traceability Reports: Procedure Attribute 1.1.2.Create backward traces to design elements within and across any project milestone Traceability Reports: Milestone Attribute 1.1.3.Create backward traces to design elements within and across Design Control Guidance Elements Traceability Reports: Linked design elements 1.1.4.Create forward impacts to design elements within and across any organizational procedure Impact Reports: Procedure Attribute 1.1.5.Create forward impacts to design elements within and across any project milestone Impact Reports: Milestone Attribute 1.1.6.Create forward impacts to design elements within and across Design Control Guidance Elements Impact Reports: Linked design elements 1.2. Associate changed design elements with related elements Link Change Design Object with affected design element(s) Traceability Links and Reports from affected design element(s) Impact Links and Reports from affected design element(s) 1.2.1.Associate design element changes with decisions, rationale, and approval authority information Change Decision Objects with following Attributes: Disposition Attribute Decision Attribute Rationale Attribute Owner Attribute Management Approval Attribute 1.2.2.Provide associations within and across any organizational procedure Change Design Object Traceability Link on Procedure Attribute Change Design Object Impacts Link on Procedure Attribute 1.2.3.Provide associations within and across any project milestone Change Design Object Traceability Link on Milestone Attribute Change Design Object Impacts Link on Milestone Attribute 1.2.4.Provide associations within and across Design Control Guidance Elements Change Design Object Traceability Link to traced design elements Change Design Object Impacts Link to linked design elements 1.3. Mange the change process Design Change Module Design Change Reports Object History Object History Reports Versions Baselines © Telelogic AB Developing Customer Requirements • Organizations need a critical layer of customer need capturing, prioritization, decision-making, and release planning capabilities Market Conditions Competitive Information Technology Drivers Cost vs. Value Features 17 © Telelogic AB Requirements Analysis • Visual requirements modeling – Simple and powerful way to communicate with customers and end users. – Helps clarify requirements – Scenarios and use-cases • Increases communication and collaboration across all stakeholders – Consistency & navigation • 18 Traceability to technical solution ‘A picture is worth a thousand words’ © Telelogic AB What if… the requirements change? • Reduce the manual effort of managing an evolving set of requirements • Reduce confusion • Ensure nothing is missed • Manage project confidently Suspect links to be checked 19 © Telelogic AB Technical Solution • Purpose: – Design, develop, and implement solutions to requirements. – Solutions, designs and implementations encompass products, product components, and product related life-cycle processes either singly or in combinations as appropriate. • Key practices: – Select Product-Component Solutions – Develop the Design – Implement the Product Design 20 © Telelogic AB One Common Visual Language – UML / SysML Requirements 21 Specification Design & implement © Telelogic AB Requirements-driven development • Drive development from requirements • Complete traceability from needs to product – Communication & visibility – Clear priorities – Impact analysis • Better project control – Avoid unnecessary or inadequate development – Confidence in cost & schedule – Building "on-demand" configurations 23 © Telelogic AB Verification versus Validation • Verification – Ensure that selected work products meet their specified requirements. – Did you build the product right? – That is, did you meet the requirements specification? • Validation – Demonstrate that a product or product component fulfills its intended use when placed in its intended environment – Did you build the right product? – That is, did you meet the operational need? 24 © Telelogic AB Aligning Requirements and Tests 25 © Telelogic AB Configuration Management • Purpose: – Establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits. • Key practices – Establish Baselines – Track and Control Changes – Establish Integrity 26 © Telelogic AB Going beyond basic CM: reaching the ROI Capabilities: • CM is also your development team process backbone for coordinating changes, versions and configurations • Enterprise-wide support for distributed teams • Automation of manual and mundane activities Benefits: • Increased quality of applications • Higher confidence in schedules and costs • Increased efficiency of development resources • Better synchronization of distributed teams *Source: Yphise Report 2003 27 © Telelogic AB Building traceability automatically • Developers indicates the context of the changes they are about to make, automating • • Just select in the To-Do list Development activities are automatically related to customer needs, latest decisions and priorities. Implementation Requests Tasks Objects Implementation 28 © Telelogic AB Round-trip traceability • Confirm planned features and bug fixes were implemented. • Determine partially implemented changes, or changes assigned but not included. • Invaluable to all team members Deliver stable, documented releases frequently & efficiently 29 © Telelogic AB Process and Product Quality Assurance • Purpose: – Provide staff and management with objective insight into processes and associated work products. • Key practices: – Objectively Evaluate Processes and Work Products – Provide Objective Insight 30 © Telelogic AB Objective Quality assessment • Automated Quality Assessment while reducing key resource usage: – Automated Coding Rule Checking – Code Audit, Quality Evaluations – Graphical Code Views – Structure-based Testing – Test Coverage Analysis 31 © Telelogic AB Casual Analysis and Resolution • Purpose: – Identify causes of defects and other problems and take action to prevent them from occurring in the future • Key practices: – Determine Causes of Defects – Address Causes of Defects 32 © Telelogic AB Enterprise Change Management Requirements Change Issue Change Control Defect/Test Tracking Activity/Task Management • Repeatable, documented, reliable process • Workflow and Process Automation • • • Cross Platform Support • Web Based for Ease of Use and Enterprise-wide Adoption Reporting and Querying Change Metrics and Graphics Generation of Project Performance Software Configuration & Build Management 33 © Telelogic AB Integrated Defect Management Process QA Defect Process Acquire Synchronization Reconsider Synchronization Rework Development Change Request Process Implementation 34 Synchronization Create Task(s) Objects © Telelogic AB ECM: Change Control Board • List of changes to be reviewed • Review and decisions 35 © Telelogic AB Measurement and Analysis • Purpose: – Develop and sustain a measurement capability that is used to support management information needs. • Key practices: – Align Measurement and Analysis Activities – Provide Measurement Results 36 © Telelogic AB Navigate Quickly to Trouble Areas 37 • Measurement & analysis to help with compliance and assessment • Quickly drill through information to find projects that require attention • Filter projects by status to list just the ones under-performing © Telelogic AB Project Monitoring and Control • Purpose: – Provide understanding into the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan. • Key practices: – Monitor Project Against Plan – Manage Corrective Action to Closure 38 © Telelogic AB Manage By Exception 39 • Quickly spot troubled areas, assess and correct issues during the project lifecycle • Automatically evaluate collected/analyzed data against all rules and targets • Color-coded status and alert emails © Telelogic AB Monitor Project Against Plan • Project plans based on requirements – Ensure all project goals (requirements) are planned and resourced – Enable assessment of the impact of requested changes on the plan – Enable assessment of the impact of schedule or resource changes on the Requirements 40 requirements Project Plan © Telelogic AB CMMI Process Areas • Engineering – – – – – – Requirements Management Requirements Development Technical Solution Product Integration Verification Validation • Support – – – – – 41 Configuration Management Process and Product Quality Assurance Measurement and Analysis Causal Analysis and Resolution Decision Analysis and Resolution • Project Management – – – – – – Project Planning Project Monitoring and Control Supplier Agreement Management Integrated Project Management Risk Management Quantitative Project Management • Process Management – – – – Organizational Process Focus Organizational Process Definition Organizational Training Organizational Process Performance – Organizational Innovation and Deployment © Telelogic AB Organizational Training • Purpose: – Develop the skills and knowledge of people so they can perform their roles effectively and efficiently. • Key practices: – Establish an Organizational Training Capability – Provide Necessary Training 42 © Telelogic AB Reducing training costs and increasing adoption 43 • CM systems can now be automated for casual users • Web interfaces can make adoption a lot easier for enterprise users • Removes user errors of manual operations • Greatly improves adoption and acceptance • Minimal training and cost of implementation © Telelogic AB Process Management • Organizational Process Focus – Plan and implement organizational process improvement based on a thorough understanding of the current strengths and weaknesses of the organization’s processes and process assets. • Organizational Process Definition – Establish and maintain a usable set of organizational process assets. • Organizational Process Performance – Establish and maintain a quantitative understanding of the performance of the organization’s set of standard processes • Organizational Innovation and Deployment – Select and deploy incremental and innovative improvements that measurably improve the organization’s processes and technologies. 44 © Telelogic AB Define and Validate Your Processes 45 • Business process models enable you visualize roles and tasks to coordinate the development team • • • Validate and improve Traceability to descriptions Make available over the organization’s Intranet © Telelogic AB Develop and Deliver Processes • Eclipse Process Framework (EPF) – Composer - Tool for authoring, configuring and publishing processes, guidelines, checklists and templates – OpenUP – an exemplary process that is suitable as-is for small co-located teams or can be extended using Composer 46 © Telelogic AB Best practices for process improvement • Today’s best practices help implement CMMI processes and achieve a return on investment – Requirement Driven Development – Enterprise Change Management – Complete integration with Requirements management, Testing, Project Management – Out-of-the-box, automated processes – Process modeling & simulation 47 © Telelogic AB Trace Your Processes Back to the CMMI for Compliance Links to processes and process steps that implement these CMMI goals 48 © Telelogic AB Telelogic Lifecycle Solutions System Architect Focal Point Enterprise Architecture & Business Process Product, Portfolio & Requirements Management DOORS Synergy Requirements & Test Management Configuration & Build Management Change TAU Change Process & Workflow Visual Design, Implementation & Test Dashboard Logiscope Rhapsody & Metrics and monitoring Quality Assurance Statemate Embedded Systems & Software Development Token-based licensing delivers access to the Telelogic suite 50 © Telelogic AB Achieving benefits with the CMMI • Productivity – TATA Consultancy Services – Over 250% improvement in productivity over five quarters as the organization progressed toward and achieved CMMI maturity lvl 5 • Cost – DB Systems GambH – Costs dropped 48 percent from a baseline prior to SW-CMM maturity level 2 as the organization moved toward CMMI maturity level 3 • Schedule – General Motors – Percentage of milestones met improved from approximately 50% to approximately 85% following organization focus on CMMI http://www.sei.cmu.edu/cmmi/results 51 © Telelogic AB Achieving benefits with the CMMI • Quality – JPMorgan Chase – 80% reduction in post release defects as the organization moved from SW-CMM lvl 1 to CMMI lvl 3 (40%, then 50%) • Customer satisfaction – Lockheed Martin Management and Data Systems – Increased award fees by 55% between SW-CMM lvl 2 and CMMI lvl 5 • Return on Investment – Raytheon Corporation – 6:1 ROI in a CMMI maturity level 3 organization http://www.sei.cmu.edu/cmmi/results 52 © Telelogic AB CMMI Adoption and ROI • The CMMI is today’s most popular path to process improvement • Integrated lifecycle solutions can facilitate deployment of best practices across the organization, helping organizations reach a faster ROI • Telelogic has an integrated lifecycle solution portfolio combining both requirements driven development and actionable architecture that helps you implement best practices to reach CMMI levels, while achieving tangible benefits and a clear return on investment. 53 © Telelogic AB Thank you! Q&A Dominic.Tavassoli@telelogic.com 54 © Telelogic AB