Appendix C: Abridged Version of the Key Practices

This abridgement contains a short description of the key process area, its goals, and the key practice statements from the Activities Performed common feature of the key process area. These items are extracted verbatim from the detailed key practice tables.

There are a number of other key practices specified under the other common features (i.e., Commitment to Perform, Ability to Perform, Measurement and Analysis, and Verifying Implementation) that are not contained in this appendix. These other key practices must be in place to ensure the key practices are implemented appropriately and effectively, are solidly established, will be maintained and not erode over time, and can be effectively applied to new work. To appropriately establish a key process area, the full set of key practices should be used.

Commitment to Perform typically involves establishing organizational policies and senior management sponsorship. Ability to Perform typically involves resources, organizational structures, and training. Measurement and Analysis typically includes examples of the measurements that could be taken to determine the status and effectiveness of the Activities Performed. Verifying Implementation typically encompasses reviews and audits by management and software quality assurance.

Level 2: Requirements Management

Requirements Management involves establishing and maintaining an agreement with the customer on the requirements for the software project. This agreement is referred to as the "system requirements allocated to the software." The "customer" may be interpreted as the system engineering group, the marketing group, another internal organization, or an external customer. The agreement covers both the technical and nontechnical (e.g., delivery dates) requirements. The agreement forms the basis for estimating, planning, performing, and tracking the software project's activities throughout the software life cycle.

The allocation of the system requirements to software, hardware, and other system components (e.g., humans) may be performed by a group external to the software engineering group (e.g., the system engineering group), and the software engineering group may have no direct control of this allocation. Within the constraints of the project, the software engineering group takes appropriate steps to ensure that the system requirements allocated to software, which they are responsible for addressing, are documented and controlled.

To achieve this control, the software engineering group reviews the initial and revised system requirements allocated to software to resolve issues before they are incorporated into the software project. Whenever the system requirements allocated to software are changed, the affected software plans, work products, and activities are adjusted to remain consistent with the updated requirements.

The goals of Requirements Management are:

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.

The top-level activities performed for Requirements Management are:

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.

Level 2: Software Project Planning

Software Project Planning involves developing estimates for the work to be performed, establishing the necessary commitments, and defining the plan to perform the work.

The software planning begins with a statement of the work to be performed and other constraints and goals that define and bound the software project (those established by the practices of the Requirements Management key process area). The software planning process includes steps to estimate the size of the software work products and the resources needed, produce a schedule, identify and assess software risks, and negotiate commitments. Iterating through these steps may be necessary to establish the plan for the software project (i.e., the software development plan).

This plan provides the basis for performing and managing the software project's activities and addresses the commitments to the software project's customer according to the resources, constraints, and capabilities of the software project.

The goals of Software Project Planning are:

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.

The top-level activities performed for Software Project Planning are:

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.

Level 2: Software Project Tracking and Oversight

Software Project Tracking and Oversight involves tracking and reviewing the software accomplishments and results against documented estimates, commitments, and plans, and adjusting these plans based on the actual accomplishments and results.

A documented plan for the software project (i.e., the software development plan, as described in the Software Project Planning key process area) is used as the basis for tracking the software activities, communicating status, and revising plans. Software activities are monitored by the management. Progress is primarily determined by comparing the actual software size, effort, cost, and schedule to the plan when selected software work products are completed and at selected milestones. When it is determined that the software project's plans are not being met, corrective actions are taken. These actions may include revising the software development plan to reflect the actual accomplishments and replanning the remaining work or taking actions to improve the performance.

The goals of Software Project Tracking and Oversight are:

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.

The top-level activities performed for Software Project Tracking and Oversight are:

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.

Level 2: Software Subcontract Management

Software Subcontract Management involves selecting a software subcontractor, establishing commitments with the subcontractor, and tracking and reviewing the subcontractor's performance and results. These practices cover the management of a software (only) subcontract, as well as the management of the software component of a subcontract that includes software, hardware, and possibly other system components.

The subcontractor is selected based on its ability to perform the work. Many factors contribute to the decision to subcontract a portion of the prime contractor's work. Subcontractors may be selected based on strategic business alliances, as well as technical considerations. The practices of this key process area address the traditional acquisition process associated with subcontracting a defined portion of the work to another organization.

When subcontracting, a documented agreement covering the technical and nontechnical (e.g., delivery dates) requirements is established and is used as the basis for managing the subcontract. The work to be done by the subcontractor and the plans for the work are documented. The standards that are to be followed by the subcontractor are compatible with the prime contractor's standards.

The software planning, tracking, and oversight activities for the subcontracted work are performed by the subcontractor. The prime contractor ensures that these planning, tracking, and oversight activities are performed appropriately and that the software products delivered by the subcontractor satisfy their acceptance criteria. The prime contractor works with the subcontractor to manage their product and process interfaces.

The goals of Software Subcontract Management are:

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.

The top-level activities performed for Software Subcontract Management are:

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.

Level 2: Software Quality Assurance

Software Quality Assurance involves reviewing and auditing the software products and activities to verify that they comply with the applicable procedures and standards and providing the software project and other appropriate managers with the results of these reviews and audits.

The software quality assurance group works with the software project during its early stages to establish plans, standards, and procedures that will add value to the software project and satisfy the constraints of the project and the organization's policies. By participating in establishing the plans, standards, and procedures, the software quality assurance group helps ensure they fit the project's needs and verifies that they will be usable for performing reviews and audits throughout the software life cycle. The software quality assurance group reviews project activities and audits software work products throughout the life cycle and provides management with visibility as to whether the software project is adhering to its established plans, standards, and procedures.

Compliance issues are first addressed within the software project and resolved there if possible. For issues not resolvable within the software project, the software quality assurance group escalates the issue to an appropriate level of management for resolution.

This key process area covers the practices for the group performing the software quality assurance function. The practices identifying the specific activities and work products that the software quality assurance group reviews and/or audits are generally contained in the Verifying Implementation common feature of the other key process areas.

The goals of Software Quality Assurance are:

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.

The top-level activities performed for Software Quality Assurance are:

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.

Level 2: Software Configuration Management

Software Configuration Management involves identifying the configuration of the software (i.e., selected software work products and their descriptions) at given points in time, systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the software life cycle. The work products placed under software configuration management include the software products that are delivered to the customer (e.g., the software requirements document and the code) and the items that are identified with or required to create these software products (e.g., the compiler).

A software baseline library is established containing the software baselines as they are developed. Changes to baselines and the release of software products built from the software baseline library are systematically controlled via the change control and configuration auditing functions of software configuration management.

This key process area covers the practices for performing the software configuration management function. The practices identifying specific configuration items/units are contained in the key process areas that describe the development and maintenance of each configuration item/unit.

The goals of Software Configuration Management are:

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.

The top-level activities performed for Software Configuration Management are:

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: Organization Process Focus

Organization Process Focus involves developing and maintaining an understanding of the organization's and projects' software processes and coordinating the activities to assess, develop, maintain, and improve these processes.

The organization provides the long-term commitments and resources to coordinate the development and maintenance of the software processes across current and future software projects via a group such as a software engineering process group. This group is responsible for the organization's software process activities. It is specifically responsible for the development and maintenance of the organization's standard software process and related process assets (as described in the Organization Process Definition key process area), and it coordinates the process activities with the software projects.

The goals of Organization Process Focus are:

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.

The top-level activities performed for Organization Process Focus are:

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.

Level 3: Organization Process Definition

Organization Process Definition involves developing and maintaining the organization's standard software process, along with related process assets, such as descriptions of software life cycles, process tailoring guidelines and criteria, the organization's software process database, and a library of software process-related documentation.

These assets may be collected in many ways, depending on the organization's implementation of Organization Process Definition. For example, the descriptions of the software life cycles may be an integral part of the organization's standard software process or parts of the library of software process-related documentation may be stored in the organization's software process database.

The organization's software process assets are available for use in developing, implementing, and maintaining the projects' defined software processes. (The practices related to the development and maintenance of the project's defined software process are described in the Integrated Software Management key process area.)

The goals of Organization Process Definition are:

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.

The top-level activities performed for Organization Process Definition are:

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.

Level 3: Training Program

Training Program involves first identifying the training needed by the organization, projects, and individuals, then developing or procuring training to address the identified needs.

Each software project evaluates its current and future skill needs and determines how these skills will be obtained. Some skills are effectively and efficiently imparted through informal vehicles (e.g., on-the-job training and informal mentoring), whereas other skills need more formal training vehicles (e.g., classroom training and guided self-study) to be effectively and efficiently imparted. The appropriate vehicles are selected and used.

This key process area covers the practices for the group performing the training function. The practices identifying the specific training topics (i.e., knowledge or skill needed) are contained in the Ability to Perform common feature of the individual key process areas.

The goals of Training Program are:

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.

The top-level activities performed for Training Program are:

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.

Level 3: Integrated Software Management

Integrated Software Management involves developing the project's defined software process and managing the software project using this defined software process. The project's defined software process is tailored from the organization's standard software process to address the specific characteristics of the project.

The software development plan is based on the project's defined software process and describes how the activities of the project's defined software process will be implemented and managed. The management of the software project's size, effort, cost, schedule, staffing, and other resources is tied to the tasks of the project's defined software process.

Since the projects' defined software processes are all tailored from the organization's standard software process, the software projects can share process data and lessons learned.

The basic practices for estimating, planning, and tracking a software project are described in the Software Project Planning and Software Project Tracking and Oversight key process areas. They focus on recognizing problems when they occur and adjusting the plans and/or performance to address the problems. The practices of this key process area build on, and are in addition to, the practices of those two key process areas. The emphasis of Integrated Software Management shifts to anticipating problems and acting to prevent or minimize the effects of these problems.

The goals of Integrated Software Management are:

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.

The top-level activities performed for Integrated Software Management are:

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.

Level 3: Software Product Engineering

Software Product Engineering involves performing the engineering tasks to build and maintain the software using the project's defined software process (which is described in the Integrated Software Management key process area) and appropriate methods and tools.

The software engineering tasks include analyzing the system requirements allocated to software (these system requirements are described in the Requirements Management key process area), developing the software requirements, developing the software architecture, designing the software, implementing the software in the code, integrating the software components, and testing the software to verify that it satisfies the specified requirements (i.e., the system requirements allocated to software and the software requirements).

Documentation needed to perform the software engineering tasks (e.g., software requirements document, software design document, test plan, and test procedures) is developed and reviewed to ensure that each task addresses the results of predecessor tasks and the results produced are appropriate for the subsequent tasks (including the tasks of operating and maintaining the software). When changes are approved, affected software work products, plans, commitments, processes, and activities are revised to reflect the approved changes.

The goals of Software Product Engineering are:

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.

The top-level activities performed for Software Product Engineering are:

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.

Level 3: Intergroup Coordination

Intergroup Coordination involves the software engineering group's participation with other project engineering groups to address system-level requirements, objectives, and issues. Representatives of the project's engineering groups participate in establishing the system-level requirements, objectives, and plans by working with the customer and end users, as appropriate. These requirements, objectives, and plans become the basis for all engineering activities.

The technical working interfaces and interactions between groups are planned and managed to ensure the quality and integrity of the entire system. Technical reviews and interchanges are regularly conducted with representatives of the project's engineering groups to ensure that all engineering groups are aware of the status and plans of all the groups, and that system and intergroup issues receive appropriate attention.

The software-specific practices related to these engineering tasks are described in the Requirements Management and Software Product Engineering key process areas.

The goals of Intergroup Coordination are:

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.

The top-level activities performed for Intergroup Coordination are:

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.

Level 3: Peer Reviews

Peer Reviews involve a methodical examination of software work products by the producers' peers to identify defects and areas where changes are needed. The specific products that will undergo a peer review are identified in the project's defined software process and scheduled as part of the software project planning activities, as described in Integrated Software Management.

This key process area covers the practices for performing peer reviews. The practices identifying the specific software work products that undergo peer review are contained in the key process areas that describe the development and maintenance of each software work product.

The goals of Peer Reviews are:

1. Peer review activities are planned.
2. Defects in the software work products are identified and removed.

The top-level activities performed for Peer Reviews are:

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: Quantitative Process Management

Quantitative Process Management involves establishing goals for the performance of the project's defined software process, which is described in the Integrated Software Management key process area, taking measurements of the process performance, analyzing these measurements, and making adjustments to maintain process performance within acceptable limits. When the process performance is stabilized within acceptable limits, the project's defined software process, the associated measurements, and the acceptable limits for the measurements are established as a baseline and used to control process performance quantitatively.

The organization collects process performance data from the software projects and uses these data to characterize the process capability (i.e., the process performance a new project can expect to attain) of the organization's standard software process, which is described in the Organization Process Definition key process area. Process capability describes the range of expected results from following a software process (i.e., the most likely outcomes that are expected from the next software project the organization undertakes). These process capability data are, in turn, used by the software projects to establish and revise their process performance goals and to analyze the performance of the projects' defined software processes.

The goals of Quantitative Process Management are:

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.

The top-level activities performed for Quantitative Process Management are:

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.

Level 4: Software Quality Management

Software Quality Management involves defining quality goals for the software products, establishing plans to achieve these goals, and monitoring and adjusting the software plans, software work products, activities, and quality goals to satisfy the needs and desires of the customer and end user for high quality products.

The practices of Software Quality Management build on the practices of the Integrated Software Management and Software Product Engineering key process areas, which establish and implement the project's defined software process, and the Quantitative Process Management key process area, which establishes a quantitative understanding of the ability of the project's defined software process to achieve the desired results.

Quantitative goals are established for the software products based on the needs of the organization, the customer, and the end users. So that these goals may be achieved, the organization establishes strategies and plans, and the project specifically adjusts its defined software process, to accomplish the quality goals.

The goals of Software Quality Management are:

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.

The top-level activities performed for Software Quality Management are:

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: Defect Prevention

Defect Prevention involves analyzing defects that were encountered in the past and taking specific actions to prevent the occurrence of those types of defects in the future. The defects may have been identified on other projects as well as in earlier stages or tasks of the current project. Defect prevention activities are also one mechanism for spreading lessons learned between projects.

Trends are analyzed to track the types of defects that have been encountered and to identify defects that are likely to recur. Based on an understanding of the project's defined software process and how it is implemented (as described in the Integrated Software Management and Software Product Engineering key process areas), the root causes of the defects and the implications of the defects for future activities are determined.

Both the project and the organization take specific actions to prevent recurrence of the defects. Some of the organizational actions may be handled as described in the Process Change Management key process area.

The goals of Defect Prevention are:

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.

The top-level activities performed for Defect Prevention are:

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.

Level 5: Technology Change Management

Technology Change Management involves identifying, selecting, and evaluating new technologies, and incorporating effective technologies into the organization. The objective is to improve software quality, increase productivity, and decrease the cycle time for product development.

The organization establishes a group (such as a software engineering process group or a technology support group) that works with the software projects to introduce and evaluate new technologies and manage changes to existing technologies. Particular emphasis is placed on technology changes that are likely to improve the capability of the organization's standard software process (as described in the Organization Process Definition key process area).

By maintaining an awareness of software-related technology innovations and systematically evaluating and experimenting with them, the organization selects appropriate technologies to improve the quality of its software and the productivity of its software activities. Pilot efforts are performed to assess new and unproven technologies before they are incorporated into normal practice. With appropriate sponsorship of the organization's management, the selected technologies are incorporated into the organization's standard software process and current projects, as appropriate.

Changes to the organization's standard software process (as described in the Organization Process Definition key process area) and the projects' defined software processes (as described in the Integrated Software Management key process area) resulting from these technology changes are handled as described in the Process Change Management key process area.

The goals of Technology Change Management are:

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.

The top-level activities for Technology Change Management are:

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.

Level 5: Process Change Management

Process Change Management involves defining process improvement goals and, with senior management sponsorship, proactively and systematically identifying, evaluating, and implementing improvements to the organization's standard software process and the projects' defined software processes on a continuous basis.

Training and incentive programs are established to enable and encourage everyone in the organization to participate in process improvement activities. Improvement opportunities are identified and evaluated for potential payback to the organization. Pilot efforts are performed to assess process changes before they are incorporated into normal practice.

When software process improvements are approved for normal practice, the organization's standard software process and the projects' defined software processes are revised as appropriate. The practices for revising the organization's standard software process are found in the Organization Process Definition key process area, and the practices for revising the projects' defined software processes are found in the Integrated Software Management key process area.

The goals of Process Change Management are:

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.

The top-level activities performed for Process Change Management are:

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.

Table of contents Appendix B