Original Source: Boeing
..
CMM KPAs and Activities

LEVEL 2 KEY PRACTICES
Requirements Management (RM)
Software Project Planning (PP, SPP)
Software Project Tracking and Oversight (PT, PTO)
Software Subcontract Management (SM, SSM)
Software Quality Assurance (QA, SQA)
Software Configuration Management (CM, SCM)

..
LEVEL 3 KEY PRACTICES
Organization Process Focus (PF, OPF)
Organization Process Definition (PD, OPD)
Training Program (TP)
Integrated Software Management (IM, ISM)
Software Product Engineering (PE, SPE)
Intergroup Coordination (IC)
Peer Reviews (PR)
..
LEVEL 4 KEY PRACTICES
Quantitative Process Management (QP, QPM)
Software Quality Management (QM, SQM)

..
LEVEL 5 KEY PRACTICES
Defect Prevention (DP)
Technology Change Management (TM, TCM)
Process Change Management (PC, PCM)
..
ACRONYMS
CMM - COMPONENT ACRONYMS
ALPHABETIZED CMM-RELATED ACRONYMS




..
LEVEL 2 KEY PRACTICES

Requirements Management (RM)
..
Goals:
  1. System requirements allocated to software are controlled to establish a baseline for software engineering and management use.
    ..
  2. Software plans, products, and activities are kept consistent with the system requirements allocated to software.
..
Activities:
  1. The software engineering group reviews the allocated requirements before they are incorporated into the software project.
    ..
  2. The software engineering group uses the allocated requirements as the basis for software plans, work products, and activities.
    ..
  3. Changes to the allocated requirements are reviewed and incorporated into the software project.
..
Software Project Planning (PP, SPP)
..
Goals:
  1. Software estimates are documented for use in planning and tracking the software project.
    ..
  2. Software project activities and commitments are planned and documented.
    ..
  3. Affected groups and individuals agree to their commitments related to the software project.
..
Activities:
  1. The software engineering group participates on the project proposal team.
    ..
  2. Software project planning is initiated in the early stages of, and in parallel with, the overall project planning.
    ..
  3. The software engineering group participates with other affected groups in the overall project planning throughout the project's life.
    ..
  4. Software project commitments made to individuals and groups external to the organization are reviewed with senior management according to a documented procedure.
    ..
  5. A software life cycle with predefined stages of manageable size is identified or defined.
    ..
  6. The project's software development plan is developed according to a documented procedure.
    ..
  7. The plan for the software project is documented.
    ..
  8. Software work products that are needed to establish and maintain control of the software project are identified.
    ..
  9. Estimates for the size of the software work products (or changes to the size of software work products) are derived according to a documented procedure.
    ..
  10. Estimates for the software project's effort and costs are derived according to a documented procedure.
    ..
  11. Estimates for the project's critical computer resources are derived according to a documented procedure.
    ..
  12. The project's software schedule is derived according to a documented procedure.
    ..
  13. The software risks associated with the cost, resource, schedule, and technical aspects of the project are identified, assessed, and documented.
    ..
  14. Plans for the project's software engineering facilities and support tools are prepared.

  15. Software planning data are recorded.
..
Software Project Tracking and Oversight (PT, PTO)
..
Goals:
  1. Actual results and performances are tracked against the software plans. Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans.
    ..
  2. Changes to software commitments are agreed to by the affected groups and individuals.
..
Activities:
  1. A documented software development plan is used for tracking the software activities and communicating status.
    ..
  2. The project's software development plan is revised according to a documented procedure.
    ..
  3. Software project commitments and changes to commitments made to individuals and groups external to the organization are reviewed with senior management according to a documented procedure.
    ..
  4. Approved changes to commitments that affect the software project are communicated to the members of the software engineering group and other software-related groups.
    ..
  5. The size of the software work products (or size of the changes to the software work products) are tracked, and corrective actions are taken as necessary.
    ..
  6. The project's software effort and costs are tracked, and corrective actions are taken as necessary.
    ..
  7. The project's critical computer resources are tracked, and corrective actions are taken as necessary.
    ..
  8. The project's software schedule is tracked, and corrective actions are taken as necessary.
    ..
  9. Software engineering technical activities are tracked, and corrective actions are taken as necessary.
    ..
  10. The software risks associated with cost, resource, schedule, and technical aspects of the project are tracked.
    ..
  11. Actual measurement data and replanning data for the software project are recorded.
    ..
  12. The software engineering group conducts periodic internal reviews to track technical progress, plans, performance, and issues against the software development plan.

  13. Formal reviews to address the accomplishments and results of the software project are conducted at selected project milestones according to a documented procedure.
..
Software Subcontract Management (SM, SSM)
..
Goals:
  1. The prime contractor selects qualified software subcontractors.
    ..
  2. The prime contractor and the software subcontractor agree to their commitments to each other.
    ..
  3. The prime contractor and the software subcontractor maintain ongoing communications.
    ..
  4. The prime contractor tracks the software subcontractor's actual results and performance against its commitments.
..
Activities:
  1. The work to be subcontracted is defined and planned according to a documented procedure.
    ..
  2. The software subcontractor is selected, based on an evaluation of the subcontract bidders' ability to perform the work, according to a documented procedure.
    ..
  3. The contractual agreement between the prime contractor and the software subcontractor is used as the basis for managing the subcontract.
    ..
  4. A documented subcontractor's software development plan is reviewed and approved by the prime contractor.
    ..
  5. A documented and approved subcontractor's software development plan is used for tracking the software activities and communicating status.
    ..
  6. Changes to the software subcontractor's statement of work, subcontract terms and conditions, and other commitments are resolved according to a documented procedure.
    ..
  7. The prime contractor's management conducts periodic status/coordination reviews with the software subcontractor's management.
    ..
  8. Periodic technical reviews and interchanges are held with the software subcontractor.
    ..
  9. Formal reviews to address the subcontractor's software engineering accomplishments and results are conducted at selected milestones according to a documented procedure.
    ..
  10. The prime contractor's software quality assurance group monitors the subcontractor's software quality assurance activities according to a documented procedure.
    ..
  11. The prime contractor's software configuration management group monitors the subcontractor's activities for software configuration management according to a documented procedure.
    ..
  12. The prime contractor conducts acceptance testing as part of the delivery of the subcontractor's software products according to a documented procedure.
    ..
  13. The software subcontractor's performance is evaluated on a periodic basis, and the evaluation is reviewed with the subcontractor.
..
Software Quality Assurance (QA, SQA)
..
Goals:
  1. Software quality assurance activities are planned.
    ..
  2. Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively.
    ..
  3. Affected groups and individuals are informed of software quality assurance activities and results.
    ..
  4. Noncompliance issues that cannot be resolved within the software project are addressed by senior management.
..
Activities:
  1. A SQA plan is prepared for the software project according to a documented procedure.
    ..
  2. The SQA group's activities are performed in accordance with the SQA plan.
    ..
  3. The SQA group participates in the preparation and review of the project's software development plan, standards, and procedures.
    ..
  4. The SQA group reviews the software engineering activities to verify compliance.
    ..
  5. The SQA group audits designated software work products to verify compliance.
    ..
  6. The SQA group periodically reports the results of its activities to the software engineering group.
    ..
  7. Deviations identified in the software activities and software work products are documented and handled according to a documented procedure.
    ..
  8. The SQA group conducts periodic reviews of its activities and findings with the customer's SQA personnel, as appropriate.
..
Software Configuration Management (CM, SCM)
..
Goals:
  1. Software configuration management activities are planned.
    ..
  2. Selected software work products are identified, controlled, and available.
    ..
  3. Changes to identified software work products are controlled.
    ..
  4. Affected groups and individuals are informed of the status and content of software baselines.
..
Activities:
  1. A SCM plan is prepared for each software project according to a documented procedure.
    ..
  2. A documented and approved SCM plan is used as the basis for performing the SCM activities.
    ..
  3. A configuration management library system is established as a repository for the software baselines.
    ..
  4. The software work products to be placed under configuration management are identified.
    ..
  5. Change requests and problem reports for all configuration items/units are initiated, recorded, reviewed, approved, and tracked according to a documented procedure.
    ..
  6. Changes to baselines are controlled according to a documented procedure.
    ..
  7. Products from the software baseline library are created and their release is controlled according to a documented procedure.
    ..
  8. The status of configuration items/units is recorded according to a documented procedure.
    ..
  9. Standard reports documenting the SCM activities and the contents of the software baseline are developed and made available to affected groups and individuals.
    ..
  10. Software baseline audits are conducted according to a documented procedure.
..
LEVEL 3 KEY PRACTICES

Organization Process Focus (PF, OPF)
..
Goals:
  1. Software process development and improvement activities are coordinated across the organization.
    ..
  2. The strengths and weaknesses of the software processes used are identified relative to a process standard.
    ..
  3. Organization-level process development and improvement activities are planned.
..
Activities:
  1. The software process is assessed periodically, and action plans are developed to address the assessment findings.
    ..
  2. The organization develops and maintains a plan for its software process development and improvement activities.
    ..
  3. The organization's and projects' activities for developing and improving their software processes are coordinated at the organization level.
    ..
  4. The use of the organization's software process database is coordinated at the organizational level.
    ..
  5. New processes, methods, and tools in limited use in the organization are monitored, evaluated, and, where appropriate, transferred to other parts of the organization.
    ..
  6. Training for the organization's and projects' software processes is coordinated across the organization.
    ..
  7. The groups involved in implementing the software processes are informed of the organization's and projects' activities for software process development and improvement.
..
Organization Process Definition (PD, OPD)
..
Goals:
  1. A standard software process for the organization is developed and maintained.
    ..
  2. Information related to the use of the organization's standard software process by the software projects is collected, reviewed, and made available.
..
Activities:
  1. The organization's standard software process is developed and maintained according to a documented procedure.
    ..
  2. The organization's standard software process is documented according to established organization standards.
    ..
  3. Descriptions of software life cycles that are approved for use by the projects are documented and maintained.
    ..
  4. Guidelines and criteria for the projects' tailoring of the organization's standard software process are developed and maintained.
    ..
  5. The organization's software process database is established and maintained.
    ..
  6. A library of software process-related documentation is established and maintained.
..
Training Program (TP)
..
Goals:
  1. Training activities are planned.
    ..
  2. Training for developing the skills and knowledge needed to perform software management and technical roles is provided.
    ..
  3. Individuals in the software engineering group and software-related groups receive the training necessary to perform their roles.
..
Activities:
  1. Each software project develops and maintains a training plan that specifies its training needs.
    ..
  2. The organization's training plan is developed and revised according to a documented procedure.
    ..
  3. The training for the organization is performed in accordance with the organization's training plan.
    ..
  4. Training courses prepared at the organization level are developed and maintained according to organization standards.
    ..
  5. A waiver procedure for required training is established and used to determine whether individuals already possess the knowledge and skills required to perform in their designated roles.
    ..
  6. Records of training are maintained.
..
Integrated Software Management (IM, ISM)
..
Goals:
  1. The project's defined software process is a tailored version of the organization's standard software process.
    ..
  2. The project is planned and managed according to the project's defined software process.
..
Activities:
  1. The project's defined software process is developed by tailoring the organization's standard software process according to a documented procedure.
    ..
  2. Each project's defined software process is revised according to a documented procedure.
    ..
  3. The project's software development plan, which describes the use of the project's defined software process, is developed and revised according to a documented procedure.
    ..
  4. The software project is managed in accordance with the project's defined software process.
    ..
  5. The organization's software process database is used for software planning and estimating.
    ..
  6. The size of the software work products (or size of changes to the software work products) is managed according to a documented procedure.
    ..
  7. The project's software effort and costs are managed according to a documented procedure.
    ..
  8. The project's critical computer resources are managed according to a documented procedure.
    ..
  9. The critical dependencies and critical paths of the project's software schedule are managed according to a documented procedure.
    ..
  10. The project's software risks are identified, assessed, documented, and managed according to a documented procedure.
    ..
  11. Reviews of the software project are periodically performed to determine the actions needed to bring the software project's performance and results in line with the current and projected needs of the business, customer, and end users, as appropriate.
..
Software Product Engineering (PE, SPE)
..
Goals:
  1. The software engineering tasks are defined, integrated, and consistently performed to produce the software.
    ..
  2. Software work products are kept consistent with each other.
..
Activities:
  1. Appropriate software engineering methods and tools are integrated into the project's defined software process.
    ..
  2. The software requirements are developed, maintained, documented, and verified by systematically analyzing the allocated requirements according to the project's defined software process.
    ..
  3. The software design is developed, maintained, documented, and verified, according to the project's defined software process, to accommodate the software requirements and to form the framework for coding.
    ..
  4. The software code is developed, maintained, documented, and verified, according to the project's defined software process, to implement the software requirements and software design.
    ..
  5. Software testing is performed according to the project's defined software process.
    ..
  6. System and acceptance testing of the software are planned and performed to demonstrate that the software satisfies its requirements.
    ..
  7. The documentation that will be used to operate and maintain the software is developed and maintained according to the project's defined software process.
    ..
  8. Data on defects identified in peer reviews and testing are collected and analyzed according to the project's defined software process.
    ..
  9. Consistency is maintained across software work products, including the software plans, process descriptions, allocated requirements, software requirements, software design, code, test plans, and test procedures.
..
Intergroup Coordination (IC)
..
Goals:
  1. The customer's requirements are agreed to by all affected groups.
    ..
  2. The commitments between the engineering groups are agreed to by the affected groups.
    ..
  3. The engineering groups identify, track, and resolve intergroup issues.
..
Activities:
  1. The software engineering group and the other engineering groups participate with the customer and end users, as appropriate, to establish the system requirements.
    ..
  2. Representatives of the project's software engineering group work with representatives of the other engineering groups to monitor and coordinate technical activities and resolve technical issues.
    ..
  3. A documented plan is used to communicate intergroup commitments and to coordinate and track the work performed.
    ..
  4. Critical dependencies between engineering groups are identified, negotiated, and tracked according to a documented procedure.
    ..
  5. Work products produced as input to other engineering groups are reviewed by representatives of the receiving groups to ensure that the work products meet their needs.
    ..
  6. Intergroup issues not resolvable by the individual representatives of the project engineering groups are handled according to a documented procedure.
    ..
  7. Representatives of the project engineering groups conduct periodic technical reviews and interchanges.
..
Peer Reviews (PR)
..
Goals:
  1. Peer review activities are planned.
    ..
  2. Defects in the software work products are identified and removed.
..
Activities:
  1. Peer reviews are planned, and the plans are documented.
    ..
  2. Peer reviews are performed according to a documented procedure.
    ..
  3. Data on the conduct and results of the peer reviews are recorded.
..
LEVEL 4 KEY PRACTICES

Quantitative Process Management (QP, QPM)
..
Goals:
  1. The quantitative process management activities are planned.
    ..
  2. The process performance of the project's defined software process is controlled quantitatively.
    ..
  3. The process capability of the organization's standard software process is known in quantitative terms.
..
Activities:
  1. The software project's plan for quantitative process management is developed according to a documented procedure.
    ..
  2. The software project's quantitative process management activities are performed in accordance with the project's quantitative process management plan.
    ..
  3. The strategy for the data collection and the quantitative analyses to be performed are determined based on the project's defined software process.
    ..
  4. The measurement data used to control the project's defined software process quantitatively are collected according to a documented procedure.
    ..
  5. The project's defined software process is analyzed and brought under quantitative control according to a documented procedure.
    ..
  6. Reports documenting the results of the software project's quantitative process management activities are prepared and distributed.
    ..
  7. The process capability baseline for the organization's standard software process is established and maintained according to a documented procedure.
..
Software Quality Management (QM, SQM)
..
Goals:
  1. The project's software quality management activities are planned.
    ..
  2. Measurable goals for software product quality and their priorities are defined.
    ..
  3. Actual progress toward achieving the quality goals for the software products is quantified and managed.
..
Activities:
  1. The project's software quality plan is developed and maintained according to a documented procedure.
    ..
  2. The project's software quality plan is the basis for the project's activities for software quality management.
    ..
  3. The project's quantitative quality goals for the software products are defined, monitored, and revised throughout the software life cycle.
    ..
  4. The quality of the project's software products is measured, analyzed, and compared to the products' quantitative quality goals on an event-driven basis.
    ..
  5. The software project's quantitative quality goals for the products are allocated appropriately to the subcontractors delivering software products to the project.
..
LEVEL 5 KEY PRACTICES

Defect Prevention (DP)
..
Goals:
  1. Defect prevention activities are planned.
    ..
  2. Common causes of defects are sought out and identified.
    ..
  3. Common causes of defects are prioritized and systematically eliminated.
..
Activities:
  1. The software project develops and maintains a plan for its defect prevention activities.
    ..
  2. At the beginning of a software task, the members of the team performing the task meet to prepare for the activities of that task and the related defect prevention activities.
    ..
  3. Causal analysis meetings are conducted according to a documented procedure.
    ..
  4. Each of the teams assigned to coordinate defect prevention activities meets on a periodic basis to review and coordinate implementation of action proposals from the causal analysis meetings.
    ..
  5. Defect prevention data are documented and tracked across the teams coordinating defect prevention activities.
    ..
  6. Revisions to the organization's standard software process resulting from defect prevention actions are incorporated according to a documented procedure.
    ..
  7. Revisions to the project's defined software process resulting from defect prevention actions are incorporated according to a documented procedure.
    ..
  8. Members of the software engineering group and software-related groups receive feedback on the status and results of the organization's and project's defect prevention activities on a periodic basis.
..
Technology Change Management (TM, TCM)
..
Goals:
  1. Incorporation of technology changes are planned.
    ..
  2. New technologies are evaluated to determine their effect on quality and productivity.
    ..
  3. Appropriate new technologies are transferred into normal practice across the organization.
..
Activities:
  1. The organization develops and maintains a plan for technology change management.
    ..
  2. The group responsible for the organization's technology change management activities works with the software projects in identifying areas of technology change.
    ..
  3. Software managers and technical staff are kept informed of new technologies.
    ..
  4. The group responsible for the organization's technology change management systematically analyzes the organization's standard software process to identify areas that need or could benefit from new technology.
    ..
  5. Technologies are selected and acquired for the organization and software projects according to a documented procedure.
    ..
  6. Pilot efforts for improving technology are conducted, where appropriate, before a new technology is introduced into normal practice.
    ..
  7. Appropriate new technologies are incorporated into the organization's standard software process according to a documented procedure.
    ..
  8. Appropriate new technologies are incorporated into the projects' defined software processes according to a documented procedure.
..
Process Change Management (PC, PCM)
..
Goals:
  1. Continuous process improvement is planned.
    ..
  2. Participation in the organization's software process improvement activities is organization wide.
    ..
  3. The organization's standard software process and the projects' defined software processes are improved continuously.
..
Activities:
  1. A software process improvement program is established which empowers the members of the organization to improve the processes of the organization.
    ..
  2. The group responsible for the organization's software process activities (e.g., software engineering process group) coordinates the software process improvement activities.
    ..
  3. The organization develops and maintains a plan for software process improvement according to a documented procedure.
    ..
  4. The software process improvement activities are performed in accordance with the software process improvement plan.
    ..
  5. Software process improvement proposals are handled according to a documented procedure.
    ..
  6. Members of the organization actively participate in teams to develop software process improvements for assigned process areas.
    ..
  7. Where appropriate, the software process improvements are installed on a pilot basis to determine their benefits and effectiveness before they are introduced into normal practice.
    ..
  8. When the decision is made to transfer a software process improvement into normal practice, the improvement is implemented according to a documented procedure.
    ..
  9. Records of software process improvement activities are maintained.
    ..
  10. Software managers and technical staff receive feedback on the status and results of the software process improvement activities on an event-driven basis.




..
ACRONYMS
CMM   COMPONENT ACRONYMS


..
ML1 Initial Level
..
ML2 Repeatable Level RM Requirements Management PP Software Project Planning (also SPP) PT Software Project Tracking and Oversight (also PTO)
..
SM Software Subcontract Management (also SSM) QA Software Quality Assurance (also SQA) CM Software Configuration Management (also SCM) ML3 Defined Level
..
PF Organization Process Focus (also OPF) PD Organization Process Definition (also OPD) TP Training Program IM Integrated Software Management (also ISM)
..
PE Software Product Engineering (also SPE) IC Intergroup Coordination PR Peer Reviews ML4 Managed Level
..
QP Quantitative Process Management (also QPM) QM Software Quality Management (also SQM) ML5 Optimizing Level DP Defect Prevention
..
TM Technology Change Management (also TCM) PC Process Change Management (also PCM) CF Common Features GO Goal (technically not a common feature)
..
CO Commitment to Perform AB Ability to Perform AC Activities Performed ME Measurement and Analysis
..
VE Verifying Implementation
..
ALPHABETIZED CMM-RELATED ACRONYMS AB ability to perform (CMM KPA common feature) AC activities performed (CMM KPA common feature) AI Assessment Instrument (ISO SPICE)
..
ATQG Assessor Training and Qualification Guide (ISO SPICE) BPG Baseline Practices Guide (ISO SPICE) CBA CMM-based appraisal CCB configuration control board
..
CDG Capability Determination Guide (ISO SPICE) CM [Software] Configuration Management (CMM Level 2 KPA) CMM capability maturity model CMU Carnegie Mellon University
..
CO commitment to perform (CMM KPA common feature) DOD Department of Defense DP Defect Prevention (CMM Level 5 KPA) DTIC Defense Technical Information Center
..
GAO General Accounting Office IC Intergroup Coordination (CMM Level 3 KPA) IDEAL initiating, diagnosing, establishing, acting, leveraging IG Introductory Guide (ISO SPICE)
..
IM Integrated [Software] Management (CMM Level 3 KPA) ISM Integrated Software Management (CMM Level 3 KPA) ISO International Organization for Standardization JTC1 Joint Technical Committee 1 (ISO/IEC joint technical committee on information technology)
..
KP key practice KPA key process area KSLOC thousand source lines of code ME measurement and analysis (CMM KPA common feature)
..
MQ maturity questionnaire OPD Organization Process Definition (CMM Level 3 KPA) OPF Organization Process Focus (CMM Level 3 KPA) PAG Process Assessment Guide (ISO SPICE)
..
PAT process action team PC Process Change [Management] (CMM Level 5 KPA) PCM Process Change Management (CMM Level 5 KPA) PD [Organization] Process Definition (CMM Level 3 KPA)
..
PE [Software] Product Engineering (CMM Level 3 KPA) PF [Organization] Process Focus (CMM Level 3 KPA) PIG Process Improvement Guide (ISO SPICE) PP [Software] Project Planning (CMM Level 2 KPA)
..
PR Peer Reviews (CMM Level 3 KPA) PT [Software] Project Tracking [and Oversight] (CMM Level 2 KPA) PTO [Software] Project Tracking and Oversight (CMM Level 2 KPA) QA [Software] Quality Assurance (CMM Level 2 KPA) quality assurance
..
QFD quality function deployment QM [Software] Quality Management (CMM Level 4 KPA) QP Quantitative Process [Management] (CMM Level 4 KPA) QPM Quantitative Process Management (CMM Level 4 KPA)
..
RM Requirements Management (CMM Level 2 KPA) ROI return on investment SC7 Subcommittee 7 (ISO JTC1 subcommittee on software engineering) SCCB software configuration control board
..
SCE Software Capability Evaluation (SEI project; now CBA) software capability evaluation (method) SCM Software Configuration Management (CMM Level 2 KPA) software configuration management SDF software development file
..
SDP software development plan SEI Software Engineering Institute SEPG Software Engineering Process Group SLOC source lines of code
..
SM [Software] Subcontract Management (CMM Level 2 KPA) SOW statement of work SPA Software Process Assessment (SEI project; now CBA) software process assessment (method) SPE Software Product Engineering (CMM Level 3 KPA)
..
SPIN Software Process Improvement Network SPM Software Process Measurement (SEI project) SPP Software Process Program Software Project Planning (CMM Level 2 KPA) SQA Software Quality Assurance (CMM Level 2 KPA) software quality assurance
..
SQM Software Quality Management (CMM Level 4 KPA) SSM Software Subcontract Management (CMM Level 2 KPA) TC176 Technical Committee 176 (ISO technical committee on quality management systems) TCM Technology Change Management (CMM Level 5 KPA)
..
TM Technology [Change] Management (CMM Level 5 KPA) TP Training Program (CMM Level 3 KPA) TQM Total Quality Management VE verifying implementation (CMM KPA common feature)
..
WBS work breakdown structure WG10 Working Group 10 (ISO/IEC JTC1/SC7 Working Group on software process assessment) WG7 Working Group 7 (ISO/IEC JTC1/SC7 Working Group on software life cycle processes)
..