1. Chair, IEEE Software Engineering Standards Committee
Strategies for Applying the CMMI to Software Maintenance
Paul R. Croll
Chair, IEEE Software Engineering Standards Committee
Vice Chair, ISO/IEC JTC1/SC7 U.S. TAG
Computer Sciences Corporation

2. Agenda The Five Types of Software Maintenance
Maintenance in the System Life Cycle
Maintenance in the Software Life Cycle
The CMMI and Maintenance
Maintenance-Related CMMI Process Areas
Issues for Software Maintenance Organizations
Estimation for Maintenance
Maturity Level Determination
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

3. Five Types of Software Maintenance
Corrective Maintenance
Identify and remove defects
Correct actual errors
Perfective Maintenance
Improve performance, dependability, maintainability
Add new functionality
Adaptive Maintenance
Adapt to a new/upgraded environment (e.g., hardware, operating system, middleware)
Many people are surprised to hear that software maintenance has so many flavors. We’ve just addressed examples of specific work we’ve done using 2 of the 4 maintenance models. Incidentally, in case you’re wondering about the applicability of the models shown on this slide, we’re using maintenance terminology as defined in IEEE Standard umteeump. Now, let’s consider the last 2 maintenance models. The work we did on the SPY Radar’s Tactical Component Architecture, or “TCA” for short, is a classic example of Perfective Maintenance. As performance requirements became ever more demanding, the long-standing SPY tactical application began to have difficulty meeting its critical timing loop and began experiencing stability problems and bottlenecks in processing and distributing data to the combat system. Ironically, code that had been purposely tightly coupled to meet performance requirements in the military computer environment (UYK-43s) became a limiting factor when asked to do more than it was designed to do. In another side effect, regression problems began to surface from routine, small fixes. When these symptoms began to show themselves, we re-designed the application using the principles of object orientation to successfully eliminate these problems and restore performance reserves. When an early engineering load was made available to selected ship crews, they enthusiastically reported markedly improved radar performance. Now, this new design is being incorporated into future baseline products. The maintainability of the SPY Radar application will be much easier on these new baselines as a direct benefit of the Perfective Maintenance measures taken.
We have practiced the 4th maintenance model, Emergency Maintenance, very effectively for many years, often to enable expensive ship trials to proceed on schedule. To follow the formal upgrade process would extend these trials beyond the bounds of practicality. Nonetheless, close adherence to a formal process is key to avoid safety problems and the expense of wasted missile shots.
The point is that we are well versed in all phases of software maintenance, and can apply these principles to all kinds of software applications, be they simple tools or as complex as a major combat system.
Preventive Maintenance
Identify and detect latent faults
Systems with safety concerns
Emergency Maintenance
Unscheduled corrective maintenance
(Risks due to reduced testing)
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

4. Two Types of Maintenance Activities – Bug Fixing
Corrective Maintenance
Identify and remove defects
Correct actual errors
Bug Fixing
Many people are surprised to hear that software maintenance has so many flavors. We’ve just addressed examples of specific work we’ve done using 2 of the 4 maintenance models. Incidentally, in case you’re wondering about the applicability of the models shown on this slide, we’re using maintenance terminology as defined in IEEE Standard umteeump. Now, let’s consider the last 2 maintenance models. The work we did on the SPY Radar’s Tactical Component Architecture, or “TCA” for short, is a classic example of Perfective Maintenance. As performance requirements became ever more demanding, the long-standing SPY tactical application began to have difficulty meeting its critical timing loop and began experiencing stability problems and bottlenecks in processing and distributing data to the combat system. Ironically, code that had been purposely tightly coupled to meet performance requirements in the military computer environment (UYK-43s) became a limiting factor when asked to do more than it was designed to do. In another side effect, regression problems began to surface from routine, small fixes. When these symptoms began to show themselves, we re-designed the application using the principles of object orientation to successfully eliminate these problems and restore performance reserves. When an early engineering load was made available to selected ship crews, they enthusiastically reported markedly improved radar performance. Now, this new design is being incorporated into future baseline products. The maintainability of the SPY Radar application will be much easier on these new baselines as a direct benefit of the Perfective Maintenance measures taken.
We have practiced the 4th maintenance model, Emergency Maintenance, very effectively for many years, often to enable expensive ship trials to proceed on schedule. To follow the formal upgrade process would extend these trials beyond the bounds of practicality. Nonetheless, close adherence to a formal process is key to avoid safety problems and the expense of wasted missile shots.
The point is that we are well versed in all phases of software maintenance, and can apply these principles to all kinds of software applications, be they simple tools or as complex as a major combat system.
Preventive Maintenance
Identify and detect latent faults
Systems with safety concerns
Emergency Maintenance
Unscheduled corrective maintenance
(Risks due to reduced testing)
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

5. Two Types of Maintenance Activities – Development/Migration
Perfective Maintenance
Improve performance, dependability, maintainability
Add new functionality
Post-Delivery
Adaptive Maintenance
Adapt to a new/upgraded environment (e.g., hardware, operating system, middleware)
Many people are surprised to hear that software maintenance has so many flavors. We’ve just addressed examples of specific work we’ve done using 2 of the 4 maintenance models. Incidentally, in case you’re wondering about the applicability of the models shown on this slide, we’re using maintenance terminology as defined in IEEE Standard umteeump. Now, let’s consider the last 2 maintenance models. The work we did on the SPY Radar’s Tactical Component Architecture, or “TCA” for short, is a classic example of Perfective Maintenance. As performance requirements became ever more demanding, the long-standing SPY tactical application began to have difficulty meeting its critical timing loop and began experiencing stability problems and bottlenecks in processing and distributing data to the combat system. Ironically, code that had been purposely tightly coupled to meet performance requirements in the military computer environment (UYK-43s) became a limiting factor when asked to do more than it was designed to do. In another side effect, regression problems began to surface from routine, small fixes. When these symptoms began to show themselves, we re-designed the application using the principles of object orientation to successfully eliminate these problems and restore performance reserves. When an early engineering load was made available to selected ship crews, they enthusiastically reported markedly improved radar performance. Now, this new design is being incorporated into future baseline products. The maintainability of the SPY Radar application will be much easier on these new baselines as a direct benefit of the Perfective Maintenance measures taken.
We have practiced the 4th maintenance model, Emergency Maintenance, very effectively for many years, often to enable expensive ship trials to proceed on schedule. To follow the formal upgrade process would extend these trials beyond the bounds of practicality. Nonetheless, close adherence to a formal process is key to avoid safety problems and the expense of wasted missile shots.
The point is that we are well versed in all phases of software maintenance, and can apply these principles to all kinds of software applications, be they simple tools or as complex as a major combat system.
Development/Migration
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

6. How do we know what the objectives and expected outcomes should be for Maintenance?

7. Maintenance in the System Life Cycle
ISO/IEC 15288
System Life Cycle Processes
SYSTEM LIFE CYCLE
PROJECT ASSESSMENT
PROJECT PLANNING
PROJECT CONTROL
DECISION MAKING
RISK MANAGEMENT
CONFIGURATION MANAGEMENT
INFORMATION MANAGEMENT
ENTERPRISE(5)
SYSTEM LIFE CYCLE MANAGEMENT
RESOURCE MANAGEMENT
QUALITY MANAGEMENT
ENTERPRISE ENVIRONMENT MANAGEMENT
INVESTMENT MANAGEMENT
TECHNICAL (11)
PROJECT (7)
ACQUISITION
SUPPLY
AGREEMENT (2)
TRANSITION
STAKEHOLDER REQUIREMENTS DEFINITION
REQUIREMENTS ANALYSIS
ARCHITECTURAL DESIGN
IMPLEMENTATION
INTEGRATION
VERIFICATION
VALIDATION
OPERATION
MAINTENANCE
DISPOSAL
(25)
Maintenance
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

8. ISO/IEC 15288 – Maintenance Process – Purpose
Clause Purpose of the Maintenance Process
The purpose of the Maintenance Process is to sustain the capability of the system to provide a service.
This process monitors the system’s capability to deliver services, records problems for analysis, takes corrective, adaptive, perfective and preventive actions and confirms restored capability.
Source: ISO/IEC 15288:2002, © ISO/IEC2002.
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

9. ISO/IEC 15288 – Maintenance Process – Expected Outcomes
Clause Maintenance Process Outcomes
As a result of the successful implementation of the Maintenance Process:
a) A maintenance strategy is developed.
b) Maintenance constraints are provided as inputs to requirements.
c) Replacement system elements are made available.
d) Services meeting stakeholder requirements are sustained.
e) The need for corrective design changes is reported.
f) Failure and lifetime data is recorded.
Source: ISO/IEC 15288:2002, © ISO/IEC2002.
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

10. Maintenance in the Software Life Cycle
IEEE/EIA 12207
Software Life Cycle Processes
SOFTWARE LIFE CYCLE
TAILORING
CONFIGURATION MANAGEMENT
DOCUMENTATION
QUALITY ASSURANCE
VERIFICATION
VALIDATION
JOINT REVIEW
AUDIT
PROBLEM RESOLUTION
PRIMARY (5)
DEVELOPMENT
OPERATION
ACQUISITION
SUPPLY
ORGANIZATIONAL (4)
MANAGEMENT
INFRASTRUCTURE
IMPROVEMENT
TRAINING
SUPPORTING (8)
Source: Singh97
(17+1)
Maintenance
MAINTENANCE
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

11. IEEE/EIA 12207 – Maintenance Process – Purpose
Clause 5.5 Maintenance process
This process is activated when the software product undergoes modifications to code and associated documentation due to a problem or the need for improvement or adaptation
The objective is to modify the existing software product while preserving its integrity
This process includes the migration and retirement of the software product
The process ends with the retirement of the software product
The activities provided in this clause are specific to the Maintenance Process; however, the process may utilize other processes in this International Standard. If the Development Process (5.3) is utilized, the term developer there is interpreted as maintainer
Source: IEEE/EIA , © IEEE.1998
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

12. IEEE/EIA 12207 – Maintenance Process – Expected Outcomes
Appendix G, Clause G.9 Maintenance process
The use of the Maintenance process should achieve the following objectives:
a) Define the impact of organization, operations, and interfaces on the existing system in operation;
b) Identify and update appropriate life cycle data;
c) Develop modified system components with associated documentation and tests that demonstrate that the system requirements are not compromised;
d) Migrate system and software upgrades to the user's environment;
e) Ensure fielding of new systems or versions does not adversely affect ongoing operations;
f) Maintain the capability to resume processing with prior versions.
Source: IEEE/EIA , © IEEE.1998
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

13. How does the CMMI Treat Maintenance?
Development
The word “development,” when used in the CMMI Product Suite, implies not only development activities, but also maintenance activities.
Projects that benefit from the best practices of CMMI can focus on maintenance, development, or both.
Source: CMMI -SE/SW/IPPD/SS, V1.1, Continuous Representation, © CMU SEI,2002.
The term Maintenance appears in the CMMI 70 times
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

14. How does the CMMI map to the consensus-based objectives and expected outcomes for Maintenance?

15. The CMMI and System Maintenance – Objectives
ISO/IEC 15288
Maintenance Objectives
CMMI
Process Areas
Monitor the system’s capability to deliver services
Record problems for analysis
Take corrective, adaptive, perfective and preventive actions
Confirm restored capability
PMC
PPQA
RSKM
VER
VAL CM
CAR
PPQA
RSKM CM
CAR RD
REQM TS PI
RSKM
VER
VAL
PMC
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

16. The CMMI and System Maintenance – Outcomes
ISO/IEC 15288
Maintenance Outcomes
CMMI
Process Areas
A maintenance strategy is developed
Maintenance constraints are provided as inputs to requirements
Replacement system elements are made available
Services meeting stakeholder requirements are sustained
The need for corrective design changes is reported
Failure and lifetime data is recorded PP TS RD PI
PMC
SAM
ISM
PPQA
RSKM RD CM
PPQA CM
RSKM
PMC
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

17. The CMMI and Software Maintenance – Objectives
IEEE/EIA 12207
Maintenance Objectives
CMMI
Process Areas
Define the impact of organization, operations, and interfaces on the existing system in operation
Identify and update life cycle data
Develop modified system components with associated documentation and tests that demonstrate that the system requirements are not compromised
Migrate system and software upgrades to the user's environment
Ensure fielding of new systems or versions does not adversely affect ongoing operations
Maintain the capability to resume processing with prior versions TS
RSKM RD
REQM
RSKM TS PI
VER
VAL CM
PPQA
RSKM PI CM
PPQA
VER
VAL
RSKM TS CM
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

18. Let’s take a closer look at several places where Maintenance-related activities occur in the CMMI

19. Bug Fixing vs. Post-Delivery Development/Migration
CAR PP CM
PMC
RSKM
PPQA
All Maintenance
VER
VAL TS
REQM PI
Bug Fixing
Post-Delivery
Development/
Migration RD
REQM TS PI
VER
VAL
ISM
SAM
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

20. Configuration Management
Changes to baselines and the release of work products built from the configuration management system are systematically controlled and monitored via the configuration control, change management, and configuration auditing functions of configuration management.
Refer to the Causal Analysis and Resolution process area for more information about both the method to use for analyzing the impact of change requests and the method to use when evaluating changes
Refer to the Project Monitoring and Control process area for more information about performance analyses and corrective actions
Source: CMMI -SE/SW/IPPD/SS, V1.1, Continuous Representation, © CMU SEI,2002.
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

21. CM – Tracking and Controlling Changes
Establish Integrity
Action
Items
Audit
Results
Perform Configuration Audits
Establish Baselines
Configuration Management
System
Identify
Configuration
Items
Change Request Database
Establish
Config. Mgmt.
Records
Establish
a Config.
Management System
Change
Requests
Reports
Track and Control
Changes
Create or Release
Baselines
Track Change
Requests
Control
Configuration
Items
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

22. CAR – Evaluating the Effect of Changes
Determine Causes of Defects
Address Causes of Defects
Implement the Action Proposals
Evaluate
the Effect
of Changes
Analyze
Causes
Action Proposals
Improvement Proposals
Select Defect Data for
Analysis
Record
Data
Performance
Measures
QPM
CAR Records
Defects and Problems
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

23. PMC – Managing Corrective Actions
Project Plan
Monitor Data Management
Monitor
Commitments
Project Planning Parameters
Conduct Milestone Reviews
Project
Risks
Monitor Project Against Plan
Conduct Progress Reviews
Stakeholder Involvement PP
Manage Corrective Action to Closure
Analyze Issues
Take Corrective Action
Manage Corrective
Action
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

24. Requirements Development
SP Establish Operational Concepts and Scenarios
Establish and maintain operational concepts and associated scenarios.
Subpractices
1. Develop operational concepts and scenarios that include functionality, performance, maintenance, support, and disposal as appropriate.
Source: CMMI -SE/SW/IPPD/SS, V1.1, Continuous Representation, © CMU SEI,2002.
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

25. RD – Establishing Operational Concepts and Scenarios
Analyze and Validate Requirements
Establish
Operational
Concepts
& Scenarios
Establish a Definition of
Required
Functionality
CL3 Analyze Requirements to Achieve Balance
Analyze Requirements
CL2 Validate Requirements with Comprehensive Methods
Validate Requirements
Product, Product-Component, and
Interface Requirements
Validated
Requirements
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

26. Requirements Management
Part of the management of requirements is to document requirements changes and rationale and maintain bi-directional traceability between source requirements and all product and product-component requirements.
SP Manage Requirements Changes
Manage changes to the requirements as they evolve during the project.
Source: CMMI -SE/SW/IPPD/SS, V1.1, Continuous Representation, © CMU SEI,2002.
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

27. REQM – Managing Requirements Changes
Manage Requirements
Obtain an Understanding of
Requirements
Identify Inconsistencies Between Project Work and Reqmts
Requirements
CL2
Obtain Commitment to Requirements
CL2
Maintain Bidirectional
Traceability of Requirements
Manage Requirements Changes
Traceability Matrix or Requirements Tracking System
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

28. Technical Solution
For a maintenance or sustainment organization, the requirements in need of maintenance actions or redesign may be driven by user needs or latent defects in the product components. New requirements may arise from changes in the operating environment. Such requirements can be uncovered during verification of the product(s) where actual performance can be compared against the specified performance and unacceptable degradation can be identified. Processes associated with the Technical Solution process area should be used to perform the maintenance or sustainment design efforts.
Source: CMMI -SE/SW/IPPD/SS, V1.1, Continuous Representation, © CMU SEI,2002.
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

29. TS – Maintenance Design Efforts
Requirements
Development
Select Product-
Component
Solutions
Develop the
Design
Implement the
Product Design
Alternative Designs and Evaluation Criteria
Design Detail &
Documentation
Developed
Product
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

30. TS – Evolving Operational Concepts and ScenariosRD
DAR
Select Product-Component Solutions
CL2
Develop
Detailed Alternative
Solutions and
Selection
Criteria
Develop Alternative
Solutions and
Selection
Criteria
CL2
Evolve
Operational
Concepts &
Scenarios
Select
Product-
Component
Solutions
Alternative Solutions
Selection Criteria
New Technology Evaluations
Selection Decisions
Compliant w/Requirements
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

31. ISM – Sourcing When COTS is a Part of the Maintenance Solution
Analyze and Select Sources of Products
SAM
Evaluate
and
Determine
Sources of
Products
Analyze
Potential
Sources of
Products
Coordinate Work with Suppliers
Monitor
Selected
Supplier
Processes
Evaluate
Selected
Supplier
Work
Products
Revise the
Supplier
Agreement or
Relationship
Supplier Work Products
Supplier Processes
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

32. SAM – Managing the COTS Supplier Relationship
Establish Supplier Agreements
Determine Acquisition Type
Establish Supplier Agreements
Select Suppliers
Product
Supplier Requirements
Supplier Agreement PI
Satisfy Supplier Agreements
Transition Products
Execute the Supplier Agreement
Accept the Acquired Product
Review COTS
Products
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

33. COTS Integration is Not Trivial
Effective COTS integration requires:
Good market research
In-depth vendor discussions
Candidate product verification
Diminishing manufacturing sources risk mitigation planning
Efficient product selection* and procurement
Middleware development and integration
*Use DAR
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

34. Product Integration SP 2.2-1 Manage Interfaces
Manage internal and external interface definitions, designs, and changes for products and product components.
Management of the interfaces includes maintenance of the consistency of the interfaces throughout the life of the product, and resolution of conflict, noncompliance, and change issues.
Source: CMMI -SE/SW/IPPD/SS, V1.1, Continuous Representation, © CMU SEI,2002.
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

35. PI – Ensuring Interface Compatibility
DAR
Ensure Interface Compatibility
Prepare for
Product Integration
Assemblies
Technical Solution
Sub-assemblies
Assemble Product Components and Deliver the Product
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

36. PI – Managing Interfaces
Ensure Interface Compatibility
Technical Solution
Review Interface
Descriptions for Completeness
Manage
Interfaces
Integration Sequence
- Integration Procedures and Criteria
- Integration Environment
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

37. Verification SP 1.1-1 Select Work Products for Verification
Select the work products to be verified and the verification methods that will be used for each.
Work products are selected based on their contribution to meeting project objectives and requirements, and to addressing project risks.
The work products to be verified may include those associated with maintenance, training, and support services. The work product requirements for verification are included with the verification methods. The verification methods address the technical approach to work product verification and the specific approaches that will be used to verify that specific work products meet their requirements.
Source: CMMI -SE/SW/IPPD/SS, V1.1, Continuous Representation, © CMU SEI,2002.
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

38. VER – Reporting Corrective Actions
Perform Peer Reviews
Prepare for Verification
Corrective Actions
Verify Selected Work Products
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

39. Validation SP 1.1-1 Select Products for Validation
Select products and product components to be validated and the validation methods that will be used for each.
Subpractices
2. Determine which categories of user needs (operational, maintenance, training, or support) are to be validated.
The product or product component must be maintainable and supportable in its intended operational environment. This specific practice also addresses the actual maintenance, training, and support services that may be delivered along with the product.
Source: CMMI -SE/SW/IPPD/SS, V1.1, Continuous Representation, © CMU SEI,2002.
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

40. VAL – Reporting Conformance Deficiencies
Requirements Development
Validate Product or
Product Components
Prepare for Validation
- Conformance
- Deficiencies
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

41. PPQA Reports and Records Relevant Stakeholders
Provide Objective Insight
Objectively Evaluate Processes
Establish Records
Communicate and Ensure Resolution of Noncompliance
Issues
Objectively Evaluate Work Products & Services
Relevant Stakeholders
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

42. RSKM Risk Repository Determine Risk Sources and Categories Define Risk
Parameters
Identify Risks
Evaluate, Categorize, and Prioritize Risks
Develop Risk Mitigation Plans
Implement Risk Mitigation Plans
Risk Repository
Prepare for Risk Management
Identify and Analyze Risks
Mitigate Risks
Establish a Risk Management Strategy PP
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

43. Some Final Issues for Software Maintenance Organizations

44. Software Maintenance is Different Than Software Development
Establish the maintenance process
Develop maintenance plans and procedures
Establish MR/PR procedures
Implement configuration management
Perform problem/modification analysis
Analyse MRs/PRs
Replicate or verify the problem
Develop options for implementing the modification
Document the MR/PR, the results, and implementation options
Obtain approval for the selected modification option
Develop and test the modification
Verify and validate the modification
Source: ISO/IEC 14764:1999, © ISO/IEC1999.
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

45. PP – Establish Estimates
Determine
Estimates of Effort and Cost
Planning
Data
Establish Estimates
Estimate the Scope of the Project
Establish Estimates of
Work Product and Task
Attributes
Define
Project Life Cycle
Source: Introduction to CMMI-Continuous V 1.1 © by Carnegie Mellon University
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

46. An Estimation Conundrum
Traditional parametric estimation models don’t do a very good job of estimating for software maintenance
A staged, earned-value approach to estimation, based on historical data works better
Validate the Problem
Analyze the Problem
Develop and Test the Modification
Integrate the Modification
Verify and Validate the Modification
15%
30%
30%
10%
15%
Time
Note: All values are notional
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

47. So You Want to be a CMMI Level X
For Maintenance Organizations focusing on corrective, preventive, or emergency maintenance
Sufficient objective evidence to meet SCAMPI requirements for a maturity rating may be difficult to obtain
Requirements Development may be missing
Requirements Management may be weak
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

48. For More Information . . . For IEEE Standards:
Paul R. Croll
Computer Sciences Corporation
5166 Potomac Drive
King George, VA
Phone:
Fax:
For IEEE Standards:
For ISO/IEC Standards:
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

49. References
CMMI -SE/SW/IPPD/SS, V1.1, CMMI for Systems Engineering/Software Engineering/Integrated Product and Process Development, and Supplier Sourcing Version 1.1, CMMI -SE/SW/IPPD/SS, V1.1, Continuous Representation. CMU/SEI-CMU/SEI-2002-TR-011, ESC-TR , Carnegie Mellon University, Software Engineering Institute, Pittsburgh, PA, March 2002.
IEEE/EIA Standard , Industry Implementation of International Standard ISO/IEC12207:1995 — (ISO/IEC 12207) Standard for Information Technology —Software life cycle processes, Institute of Electrical and Electronics Engineers, Inc. New York, NY, 1998.
Introduction to CMMI – Continuous V 1.1, Carnegie Mellon University ,
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,

50. References - 2
ISO/IEC , Software Engineering — Software Maintenance, ISO/IEC JTC1/SC7, 1999.
ISO/IEC 15288:2002, Systems Engineering — System Life Cycle Processes, ISO/IEC JTC1/SC7, 2002.
[Singh97] Raghu Singh, An Introduction to International Standards ISO/IEC 12207, Software Life Cycle Processes, 1997.
3rd Annual CMMI Technology Conference and Users Group – Track 1 – 18 November 2003,