1 © Telelogic AB

Helping CMMI Adoption

and Return on Investment

With Integrated Lifecycle Solutions

Dominic TAVASSOLI

Director of Product Marketing

2 © 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

3 © 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

© 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

5 © Telelogic AB

Demonstrated success

0 %

-140%Without Historical Data With Historical Data

Variance between + 20% to - 145% Variance between - 20% to + 20% (CMM levels 1 & 2) (CMM level 3)

Act

ual

pro

ject

eff

ort

vs.

pre

dic

ted

(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.

Improved planning, predictability

+140%

6 © 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

© 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

8 © Telelogic AB

Staged

ML 1

ML2

ML3

ML4

ML5

. . .for an established set of process areas across anorganization

Continuous

. . .for a single process areaor a set of process areas

PA PA

Pro

cess

Are

a C

apab

ility

0

1 2

3

4

5

PA

Two CMMI models

ML: Maturity levels

9 © Telelogic AB

Maturity levels

Unpredictable process, little control, reactive

Process per project, often reactive

Organization standard process, consistent and proactive

Process driven and measured, predictable

Continual process improvement

Optimizing

Quantitatively Managed

Defined

Initial

Managed

1

2

3

4

5

• "If you master your process, you'll reduce risk and improve productivity"

11 © Telelogic AB

CMMI Process Areas

• Engineering– Requirements Management

– Requirements Development

– Technical Solution

– Product Integration

– Verification

– Validation

• Support– 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

12 © 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

13 © 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:

• Confidence that all requirements are fulfilled

• Confidence that every effort fulfils a requirement

• Simplified maintenance of final system

• Focused development resources

14 © 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

15 © Telelogic AB

Requirements Development

Develop Customer

Requirements

CustomerRequirements

ProductRequirements

DevelopProduct

Requirements

Analyze andValidate

Requirements

ValidatedRequirements

16 © Telelogic AB

End-to-end visual traceability

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.

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 Input2.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 userand patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand 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 ofdesign 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 use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.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?

Comply with FDA Design Control Guidance GMP Regulation

1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation

2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values

3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements

5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design element changes

6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone

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 elements1.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 ControlGuidance Elements Traceability Reports: Linked design elements

1.1.4. Create forward impacts to design elements within and across any organizationalprocedure 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 ControlGuidance 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

1. 820.30(b) Design and Development Planning

Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.

The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.

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 Input2.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 userand patient.

2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand 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 ofdesign 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 use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.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?

Comply with FDA Design Control Guidance GMP Regulation

1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation

2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements

2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships

2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values

3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need

4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements

5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available

6. Manage change6.1. Maintain history of design element changes

6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements

6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority

6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone

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 elements1.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 ControlGuidance Elements Traceability Reports: Linked design elements

1.1.4. Create forward impacts to design elements within and across any organizationalprocedure 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 ControlGuidance 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

User Reqts Technical Reqts Test CasesDesign

17 © 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

18 © 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

• Traceability to technical solution

‘A picture is worth a thousand words’

19 © 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

20 © 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

21 © Telelogic AB

One Common Visual Language – UML / SysML

Requirements Specification Design & implement

23 © 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

24 © 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?

25 © Telelogic AB

Aligning Requirements and Tests

26 © 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

27 © 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

28 © 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

29 © 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

30 © Telelogic AB

• 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

Process and Product Quality Assurance

31 © 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

32 © Telelogic AB

• 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

Casual Analysis and Resolution

33 © Telelogic AB

Enterprise Change Management

• Repeatable, documented, reliable process

• Workflow and Process Automation

• Cross Platform Support

• Reporting and Querying

• Change Metrics and Graphics Generation of Project Performance

• Web Based for Ease of Use and Enterprise-wide Adoption

Requirements Change Defect/Test Tracking

Issue Change Control

Software Configuration & Build Management

Activity/Task Management

34 © Telelogic AB

Integrated Defect Management Process

Development Change Request Process

Reconsider Rework

Task(s)Create

ObjectsImplementation

QA Defect Process

Acquire Synchronization SynchronizationSynchronization

35 © Telelogic AB

ECM: Change Control Board

• List of changes to be reviewed

• Review and decisions

36 © 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

37 © Telelogic AB

Navigate Quickly to Trouble Areas

• 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

38 © 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

39 © Telelogic AB

Manage By Exception

• 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

40 © 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

requirementsRequirements Project Plan

41 © Telelogic AB

CMMI Process Areas

• Engineering– Requirements Management

– Requirements Development

– Technical Solution

– Product Integration

– Verification

– Validation

• Support– 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

42 © 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

43 © Telelogic AB

Reducing training costs and increasing adoption

• 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

44 © 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.

45 © Telelogic AB

Define and Validate Your Processes

• 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

46 © 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

47 © 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

48 © Telelogic AB

Trace Your Processes Back to the CMMI for Compliance

Links to processes and process steps that implement these CMMI goals

50 © Telelogic AB

System Architect

Enterprise Architecture& Business Process

Focal Point

Product, Portfolio& RequirementsManagement

DOORSRequirements & TestManagement

SynergyConfiguration& BuildManagement

TAU

Visual Design,Implementation& Test

Change

ChangeProcess &Workflow

Telelogic Lifecycle Solutions

Token-based licensing delivers access

to the Telelogic suite

Dashboard

Metrics and monitoring

Logiscope

Quality Assurance

Rhapsody &

Statemate

Embedded Systems & Software Development

51 © 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

52 © 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

53 © 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.

54 © Telelogic AB

Thank you!

Q & A

Dominic.Tavassoli@telelogic.com