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