CMMi & SW-CMM – A comparison

The first CMM (CMM v1.0) was developed for software and released in August 1990

• Based on this success and the demand from other interests CMMs were developed for other disciplines and functions

• Systems Engineering
• People
• Integrated Product Development
• Software Acquisition
• Software Quality Assurance
• Measurement
• Others…….

· While organizations found these various CMMs to be useful they also found them to be:

§ ³Overlapping

§ ³Contradicting

§ ³Lacking clean, understandable interfaces

§ ³Lacking standardization

§ ³Displaying different levels of detail

§ In addition, many organizations also had to deal with ISO 9001 Audits or TickIT audits based on ISO 9000-3.uThis resulted in expensive, confusing and conflicting process improvement programs

The CMM Integration Project was formed to:

• ³Establish a framework to integrate current and future models
• ³Build an initial set of integrated models

The source models that served as the basis for the CMMI include:

• ³CMM for Software v2.0 Draft C
• ³EIA – 731 Systems Engineering
• ³IPD CMM (IPD) v0.98a

Requirements Management

• uBi-Directional Traceability is now explicitly asked for in requirements Management
• ³Hard to determine if the delivered product matches the requirements and approved requirements change requests and nothing more without requirements traceability
• ³Always been necessary but not clearly demanded
• uRequirements Management is expected to operate in parallel with Requirements Development and offer support as new requirements are discovered and requirements change requests are made

Project Planning

• uThere is a heavier emphasis on having a detailed Work Breakdown Structure
• uIncludes a focus on the project having the necessary Knowledge and Skills to execute the project according to the estimations and plan
• uData Management or the planning and maintaining of project data items and their contents has been added to the list of project management concerns
• uData Management Requires administrative control of project data, both deliverable and non-deliverable
• ³Some large, critical projects demand that even
• Engineering Notebooks with daily entries be placed
• under control for audit purposes
• ³Covers all other forms of data such as CD-ROMs,
• Disks, Notebooks, etc
• ³Part of Project Planning process area
• uEstimation focuses on size and complexity while effort and cost, and schedule are determined and established respectively based on the size estimation
• uEstimate size and/or relative difficulty or complexity
• uDetermine the project effort and cost based on the size and complexity estimations
• uEstablish and maintain the project schedule based on the size and complexity estimations
• u The identification and involvement of stakeholders is

an important evolution of the “all affected groups”

statement that appeared frequently in the SWCMM

• u The required plan for stakeholder interaction includes:
• ³List of all relevant stakeholders
• ³Rationale for stakeholder involvement
• ³Expected roles and responsibilities
• ³Relationships between stakeholders
• ³Relative importance of stakeholder to project success by
• phase
• ³Resources needed to ensure relevant stakeholder interaction
• ³Schedule for phasing of stakeholder interaction

o uThe commitment process is now explicitly defined in Specific Practice 3.3

Project Monitoring and Control

• uMonitoring Commitments has also been elevated to specific practice level - (SP 1.2)
• uMonitoring Risks and Stakeholder Involvement is also more strongly emphasized in the CMMI compared to the SWCMM
• uMonitoring Stakeholder Involvement is explicitly brought out and enables the Generic Practice 2.6 – Identify and Involve Relevant Stakeholders

Process and Product Quality Assurance

• uStresses the objective evaluation of products

as well as processes!!

• uEvaluation criteria must be established based

on business objectives

• ³What will be evaluated?
• ³When or how often will a process be evaluated?
• ³How will the evaluation be conducted?
• ³Who must be involved in the evaluation?

Configuration Management

• uThe idea of “Software Library” has been

replaced by the more encompassing

“Configuration Management System”

• uA configuration management system

includes:

³The storage media

³The procedures

³The tools for accessing the configuration system

Supplier Agreement Management

• uReplaces the initial ideas found in Subcontract

Management

• uNow incorporates the original intent of

Subcontract Management as well as lessons

learned over the past 7 years 

Measurement and Analysis

• Provides a description of a measurement

initiative that involves the following:

• ³Specifying the objectives of measurement and analysis such that they are aligned with established information needs and business objectives
• ³Defining the measures to be used, the data collection process, the storage mechanisms, the analysis processes, the reporting processes, and the feedback processes
• ³Implementing the collection, storage, analysis, and presentation of the data
• ³Providing objective results that can be used in making business judgments and taking appropriate corrective actions
• An organization that barely passes the Measurement and Analysis Common Feature requirements of CMM for Software would not pass the measurement requirements of CMMI
• Sets up the organization to evolve its measurement program from basic project management measures to those based on the organization’s set of standard processes to statistical control of selected subprocesses according to the organization’s business needs

Requirements Development

• uThe concepts presented in Requirements Development are consistent with very modern publications on Requirements Engineering
• uClearly defines the need for identification and care of stakeholders
• uIncorporates the interface ideas of Systems Engineering and Software Engineering with regards to gathering, analyzing, documenting, and maintaining requirements found in CMM for Software v1.1 and expands on them
• u Requirements Development together with Technical Solution truly shows the recursive and iterative nature of developing requirements:
• Stakeholder Needs
• Customer Requirements
• Product and Product
• Component Requirements
• Requirements Analysis
• Derived Requirements
• Allocation to Product
• Functions and Product
• Components including
• Objects, People,
• and associated Processes
• or People
• uThe Requirements Development PA includes a description of developing an operational concept and operational scenarios to refine and discover new requirements, needs, and constraints that include the interaction of the product, the end user and the environment
• uIt also includes a strong focus on interface requirements
• uIt suggests the use of models, simulations, and prototyping to perform risk assessments to reduce the cost and risk of product development
• uIt is very tightly coupled to the Technical Solution process area
• uIt emphasizes the idea of starting the process of requirements validation very early in the product lifecycle

Technical Solution

• Technical Solution practices apply not only to the product and product components but also to services and product-related processes
• Technical Solutions are presented as being developed interactively with product or product component requirements definition
• Technical Solution stresses the need for developing alternative solutions

(Engineer in Quality)

• To engineer in quality means to add quality to software during the engineering process
• uTo achieve this, software engineers must be aware of quality requirements at the same time they are building the functional requirements
• uQuality requirements thus take on the same relationship to the product as functional requirements do
• uIf we engineer quality in, we add quality to the product as we build it
• uQuality Factors (e.g., maintainability, expandability, reliability) were discussed in the CMM/SW Level 4 KPA Software Quality Management – “Quality goals for the project’s software products are defined, monitored, and revised throughout the software lifecycle”
• uCMMI discusses the quality factors first in Requirements Development and emphasizes their importance in Technical Solution
• uDesign criteria are often established to ensure that the product or product component exhibits one or more of the following quality attributes:
• ³Modularity
• ³Clarity
• ³Maintainability
• ³Expandability
• ³Portability
• ³Efficiency
• ³Reliability
• ³Security
• ³Usability
• ³Scalability

Product Integration

• uProduct Integration presents the concepts to achieve complete product integration through progressive assembly of product components, in one stage or in incremental stages, according to a defined integration strategy
• uIt stresses the careful analysis and selection of the optimum integration strategy
• ³The basis for effective product integration is an integration strategy that uses combinations of techniques in an incremental manner
• uIt points out the need to establish and maintain the environment required to support the integration of the product components
• uIt introduces the concept of product component and product assembly Checkout, to evaluate its performance and suitability
• uIt presents the idea of applying (Product Integration, Verification, and Validation) in successive triplets until the product is ready for packaging and delivery
• uIt stresses the effective management of all interfaces to ensure that all interfaces will be complete and compatible
• ³Interface descriptions
• ³Interface data
• uPackaging and Delivery is specifically called out in Specific Practice 3.4 – an improvement over the information provided in the SWCMM
• uInspecting Product Elements Upon Receipt is an activity that is not well done in the industry today and deserves the attention that is now defined in the CMMI!

Verification

• uVerification is used to assure that selected work products meet their specified requirements
• uVerification assures “You built it right”
• uExpects a verification strategy that addresses the specific actions, resources, and environments that will be required for work product verification to be developed
• ³Developed concurrently and iteratively with the

product and product component designs

• uCaptures the ideas of using:
• ³Peer Reviews
• ³Load, stress and performance testing
• ³Functional decomposition based testing
• ³Simulation
• ³Prototypes
• ³Observations and demonstrations
• ³Operational scenario testing

as they apply to ensuring that the requirements are being addressed at each phase of the development lifecycle from a systems, and

software point of view

Validation

• uValidation is used to demonstrate that a product or product component fulfills its intended use when placed in its intended

operational environment

• uValidation assures “You built the right thing”

Risk Management

• uThe concepts inherent to Risk Management finally made it to Process Area status
• ³Risk Identification
• ³Risk Assessment
• ³Risk Analysis
• ³Risk Prioritization
• ³Risk Mitigation
• ³Risk Contingency Planning
• uThe ideas behind Risk Contingency Planning and Risk Mitigation have been merged but are definitely clearer

Decision Analysis & Resolution

• uDecision and Analysis presents the concepts of identifying alternatives to issues that have a significant impact on meeting objectives, analyzing the alternatives, and selecting one or more alternatives that best support prescribed objectives
• uDecision and Analysis is a new concept for the software world whose time has certainly come
• u Decision and Analysis helps determine which issues should be examined by formal decision analysis – typical criteria for when to require formal decision making includes:
• ³When a decision is directly related to topics assessed as being of medium or high risk
• ³When a decision is related to changing work products under configuration management
• ³When a decision would cause schedule delays over a certain percentage or specific amount of time
• ³When a decision has an impact on the ability to achieve project objectives
• ³When a decision’s costs are reasonable compared to the decision’s impact
• uUnderstanding decision making models from Operations Research can help in making full use of this Process Area
• ³Linear Optimization Models

­ Simplex Method for executive decision making

• ³Stochastic Programming Models
• ³Dynamic Optimization Models
• ³Unbounded Horizon Models
• ³Queuing Decision Models

Organizational Process Definition

• uThe wording for this process area has changed subtly but significantly from that of the SWCMM
• ³Establish and maintain a usable set of organizational process assets including the organization’s set of standard processes
• ³Acknowledges that an organization may utilize more than one standard process to handle its product lines and business needs
• uProcess Database evolved into Organizational Measurement Repository

Integrated Project Management

• u Integrated Project Management takes on the aspects of Integrated Software Management and Intergroup Coordination that were found in the SWCMM
• ³The project is conducted using a defined process that is tailored from the organization's set of standard processes
• u It also emphasizes the need to proactively integrate the concepts in the Project Plan and all supporting plans such as:
• ³Quality assurance plans
• ³Configuration management plans
• ³Risk management strategy
• ³Verification strategy
• ³Validation strategy
• ³Product integration plans

Organizational Process Performance

• uThe Organizational Process Performance process area was developed to help organizations set the stage for quantitative process management:
• ³Baselines and models that characterize the expected process performance of the organization's set of standard processes are established and maintained

Performance Baselines

• uThe organization’s process performance baselines measure performance for the organization’s set of standard processes at various levels including:
• ³Individual processes (e.g., test case inspection element)
• ³Sequence of connected processes
• ³Processes for the complete lifecycle
• ³Processes for developing individual work products
• uThere may be several process performance baselines to characterize performance for subgroups of the organization – Examples include:
• ³Product Line
• ³Application domain
• ³Complexity
• ³Team size
• ³Work product size

Quantitative Project Management

• uThis Process Area combines the concepts of Quantitative Process Management and Software Quality Management from the SWCMM point of view
• uThe concepts of quantitative management and statistical process control are strongly present in this process area.
• uQuantitative Project Management is tightly coupled with Organizational Process Performance, taking standard process

measures from it to achieve stability of subprocesses and providing information back to it once the statistical control boundaries are established

Quantitative Management Concepts

• uQuantitative Management is tied to the organization’s strategic goals for product quality, service quality, and process performance
• uWhen higher degrees of quality and performance are demanded, the organization and projects must determine if they have the ability to improve the necessary processes to satisfy the increased demands
• uAchieving the necessary quality and process performance objectives requires stabilizing the processes that contribute most to the achievement of the objectives
• uAssuming the technical requirements can be met, the next decision is to determine if it is cost effective
• uReducing process variation is an important aspect to quantitative management:
• ³It is important to focus on subprocesses that can be controlled to achieve a predictable performance
• uStatistical process control is often better focused on organizational areas such as Product Lines where there is high similarity of processes, than on the organization’s entire set of products
• uSuccessful application of Quantitative

Management concepts must look closely to:

• ³The business demands
• ³The capability of existing processes
• ³The ability of the organization to bring processes and subprocesses under statistical control in a cost effective manner

Organizational Innovation and Deployment

• uCombined Process Change Management and Technology Change Management from the SWCMM point of view
• uJust Do It! – Or once one has the innovation ideas identified and analyzed against the organization’s business objectives and cost measures, get it tried and expanded wherever possible throughout the organization
• uSubpractices are excellent and provide a solid picture of what is required for this process area

Overview

• uThe Organizational Innovation and Deployment process area selects and deploys improvements that can improve the organization’s ability to meet its quality and process performance objectives
• uQuality and process performance objectives that this process area might address include:
• ³Improved product quality
• ³Increased productivity
• ³Decreased developed cycle time
• ³Greater customer and end user satisfaction
• uProcess and technology improvements that will be deployed are selected from proposals based on the following criteria:
• ³A quantitative understanding of the organization’s current quality and process performance
• ³Estimates of the improvement resulting from the deployment
• ³The resources and funding available for that deployment
• ³The expected benefits weighed against the cost and impact to the organization

• CMMI Framework provides the opportunity to apply the principles of both the staged and continuous representations in a process improvement oriented manner or a manner.

Clear CMM vs CMMI mapping was given at a Practice level by SEI. You can find the PDF at this location:

http://www.sei.cmu.edu/cmmi/adoption/pdf/stsc-mappings.pdf