Software Acquisition Capability Maturity Model ® a ( SA-CMM ® ) Version 1 . m 02

The ideas and findings in this report should not be construed as an official DoD position. It is published in the interest of scientific and technical information exchange. Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and "No Warranty" statements are included with all reproductions and derivative works. External use. Requests for permission to reproduce this document or prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at 252.227-7013. For information about purchasing paper copies of SEI reports, please visit the publications portion of our Web site The Office of the Secretary of Defense provided major funding for the genesis of the SA-CMM, providing for both initial trial use and development of training aids. The resulting SA-CMM points to current acquisition practices that can be used in any environment. (Note: Applying the SA-CMM to defense acquisition process improvement requires adherence to DoD directives, which have been streamlined and updated, such as DoD Directive 5000.1 and DoD 5000.2-R.) The development of Version 1.02 of the SA-CMM was based on experience gained from the use of Version 1.01. Some 300 comments were received and considered in developing this version. Many of these comments were the result of conducting several SA-CMM Based Assessments for Internal Process Improvement (CBA IPI) and Software Capability Evaluations (SCE) of government and industry organizations. Other comments were based on organizations' experiences in implementing SA-CMM based software acquisition process improvements. Additionally, a select group of model experts provided valuable comments during their review of the draft version 1.02. The development of Version 1.03 of the SA-CMM was based on experience gained from the use of Version 1.02. New comments were received and considered in developing this version. Many of these comments were the result of conducting several SA-CMM Based Assessments for Internal Process Improvement (CBA IPI) and Software Capability Evaluations (SCE) of government and industry …

Introduction other words, progress is made in stages or steps. The levels of maturity and their key process areas thus provide a roadmap for achieving higher levels of maturity.
Typically, a portion of the goals or activities of some higher level key process areas are satisfied/performed at a lower level. However, a key process area cannot be achieved until all of its goals have been satisfied. A maturity level is achieved by mastering all of its key process areas. Once a maturity level is achieved, the model requires that the satisfaction of all lower level goals is maintained.
The stages of the model are complementary and flow upward. For example, at Level 2 some of the activities of Contract Tracking and Oversight will result in corrective actions (a reactive approach to deficiencies). This process grows and matures; in Level 3 the activities of Contract Performance Management are performed to identify and prepare for deficiencies before they occur (a proactive approach). Contract Performance Management grows and matures to become Quantitative Acquisition Management at Level 4 when the process(es) is adjusted based on quantitative data (quantitative approach). At Level 5, Continuous Process Improvement uses quantitative data to optimize process performance (optimizing approach).
Just as the stages of a capability maturity model flow upward, the satisfaction of goals must be maintained as an organization moves up the levels of maturity.The SA-CMM contains a similar thread; activities or events that occur at a lower level are not required to be re-instantiated at higher levels. For example, a group is established for managing the contract in the Contract Tracking and Oversight key process area at Level 2, the SA-CMM assumes that the same group is still in place when the organization moves to Level 3. Thus, there is no requirement in the Contract Performance Management key process area at Level 3 to re-establish a contract management group. This approach reduces unnecessary redundancy in subsequent key process areas and makes implementation more efficient.
The SA-CMM is designed to be generic enough for use by any government or industry organization, regardless of size, acquiring software. When applying the SA-CMM to a particular organization, translations may need to be made (in addition to tailoring the model to fit a specific acquisition). The SA-CMM addresses an "organization" which is the parent of the "acquisition organization." The acquisition organization specializes in acquisition and may be responsible for more than one project. The project team is the entity that has the responsibility for executing the specific acquisition. The project team is supported by "other (affected) groups" (functionals, matrix, etc.) in the conduct of the acquisition. In the SA-CMM, the terms "group," "team," "office," and similar terms may indicate situations where the specific implementation may vary from a single individual assigned part-time, to several part-time individuals assigned from other organizations, to several individuals dedicated full-time. The structure of the model must be mapped onto the particular situation where the model is being applied. Also, the terminology of the Introduction model has been made as generic as possible and must be mapped onto the local situation; some examples are "contracting official," "affected groups," and "domain." The SA-CMM should be interpreted in the context of the needs of the organization; just because something is in the SA-CMM does not mean it should be applied automatically. Effective and efficient software acquisition processes are critical to successful process improvement, but the quality of their output can only be determined in the context of the business needs of the organization.
Use of the SA-CMM is not limited to situations where software is being acquired under formal contract. It can be used by any organization acquiring software or software-related services. For this usage, the term "contractor" refers to the organization performing the software engineering effort. The term "project team" refers to the individuals within the acquiring organization who have an assigned software acquisition responsibility, and the term "contract" refers to the agreement between the organizations.
The SA-CMM applies to the acquisition of all types of embedded and stand-alone software applications, including those where commercial-off-the-shelf (COTS) and nondevelopmental item (NDI) software are being acquired, either as a part of a system or separately. Naturally, the model may have to be tailored to fit the specific circumstances.
The SA-CMM is appropriate for use throughout the entire software life cycle. During the life cycle of a system, many individual acquisitions can occur; an acquisition can occur in the system's operational and support phase as well as for its initial development. In cases where products and services for enhancing or reengineering the software are being acquired, the software support organization takes on the role of the acquirer. Thus, the model is applicable.
The SA-CMM accommodates the software that is acquired as a part of a total system acquisition. It does not specifically address the "system acquisition" process; however, it is in harmony with and references that process.
Every acquisition project germinates with a requirement, albeit at a very high level. As the acquisition begins to form, more requirements are identified and refined. This evolution proceeds and the set of requirements continues to grow. By the time the solicitation package is developed, a significant set of software technical and non-technical requirements exists. For purposes of the SA-CMM, these requirements must be baselined (managed and controlled), not frozen. As software requirements further evolve (e.g., allocation, elaboration, and refinement), they are incorporated into the requirements baseline, and managed and controlled. Management and control of the software requirements remain the acquirer's responsibility even though the contractor team may be involved in the requirements development process.
CMU/SEI-99-TR-002 1-3 Introduction A project should have established baselines for the software's performance (technical) requirements, for the cost of the software being acquired, and for the schedule of the acquisition project. The SA-CMM recognizes that, historically, project managers may not have had the latitude to make trade-offs in these parameters to optimize the project. Consequently, the model recognizes the necessity of giving the project manager the flexibility to adjust one of these baselines for control and use in making trade-offs, thereby enhancing the probability for a successful acquisition.
The SA-CMM is based on the expectation that a mature organization and its projects will do a thorough job of planning an acquisition. The Software Acquisition Planning key process area addresses the planning process that must take place as an adjunct to managing the software acquisition project. Each of the remaining key process areas addresses a planning process as one of the area's activities. How to document this planning is the option of the acquisition organization and the project team. While other planning documents may be created for the project, the SA-CMM does identify two specific plans -the Project Management Plan and the Software Acquisition Risk Management Plan. The method of documenting these two specific plans is also the option of the acquisition organization and the project team. The resulting project planning documentation need not be any more extensive than that of any well-managed software acquisition project.

Introduction
The SA-CMM defines five levels of maturity. Each maturity level (except Level 1) indicates process capability and contains key process areas. Key process areas contain goals and five common features. The common features are attributes that indicate if the implementation and institutionalization of a key process area can be effective, repeatable, and lasting. Figure 1 depicts the architecture of the SA-CMM and Figure 2 provides a synopsis of its content. The goals and five common features are described below: Goals. Goals are the aggregate result achieved by the effective implementation of the common features of a key process area.
Commitment to perform. Commitment to perform describes the actions that the organization must take to establish the process and ensure that it can endure. Commitment to perform typically involves establishing organizational policies and management sponsorship.
Ability to perform. Ability to perform describes the preconditions that must exist in the project or organization to implement the software acquisition process competently. Ability to perform typically involves resources, organizational structures, and training.
Activities performed. Activities performed describes the roles and procedures necessary to implement a key process area. Activities performed typically involves establishing plans and procedures, performing the work, tracking it, and taking appropriate management actions.
Measurement and analysis. Measurement and analysis describes the need to measure the process and analyze the measurements. 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. Verifying implementation describes the steps to ensure that the activities are performed in compliance with the process that has been established. Verifying implementation typically encompasses reviews by management. Competent people and heroics Initial Figure 2. Synopsis of the SA-CMM 1) Initial -The software acquisition process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined and success depends on individual effort. For an organization to mature beyond the initial level, it must install basic management controls to instill self-discipline.
2) Repeatable -Basic software acquisition project management processes are established to plan all aspects of the acquisition, manage software requirements, track project team and contractor team performance, manage the project's cost and schedule baselines, evaluate the products and services, and successfully transition the software to its support organization. The project team is basically reacting to circumstances of the acquisition as they arise. The necessary process discipline is in place to repeat earlier successes on projects in similar domains. For an organization to mature beyond the level of selfdiscipline, it must use well-defined processes as a foundation for improvement.
Introduction into all aspects of the project, and the organization provides the training required by personnel involved in the acquisition. For an organization to mature beyond the level of defined processes, it must base decisions on quantitative measures of its processes and products so that objectivity can be attained and rational decisions made.

4)
Quantitative -Detailed measures of the software acquisition processes, products, and services are collected. The software processes, products, and services are quantitatively and qualitatively understood and controlled.

5)
Optimizing -Continuous process improvement is empowered by quantitative feedback from the process and from piloting innovative ideas and technologies. Ultimately an organization recognizes that continual improvement (and continual change) is necessary to survive.
Introduction be implemented or who should perform an action; it describes what characteristics the software acquisition process should possess.
Technology. The SA-CMM is technology independent. No specific tools, methods, or technologies are mandated by the SA-CMM. Appropriate tools, methods, and technologies should be made available to support the process.
Professional Judgement. Professional judgement must be applied when interpreting, for a particular organization, the activities of the SA-CMM. The SA-CMM should be tailored to fit the organization; the organization should not be restructured to reflect the SA-CMM.
The Competence Principle. The competence of the people doing the work is a major factor in project performance and organizational success. (Competence includes knowledge of the application domain, software acquisition methods, and quantitative methods, and having interpersonal and problem solving skills.) Level 1 -The Initial Level At the Initial Level, the project team typically does not provide a stable environment for acquiring software. The project team is staffed based on the availability of individuals, resulting in a random composition of acquisition skills. Software acquisition does not receive adequate management visibility. The project is pursued in an ad hoc manner.
There are no key process areas at Level 1. CMU/SEI-99-TR-002 Li-1 Level 2-The Repeatable Level At the Repeatable Level, the project team is knowledgeable and supportive of promulgated policies, regulations, and standards that relate to its project and makes a dedicated attempt to comply with them. Software acquisition management plans and procedures are established by the project team. The planning and tracking of new projects are based on experience with similar projects. An objective in achieving Level 2 is to stabilize both the software contract management and project management processes, allowing project teams to repeat successful practices employed on earlier projects.
Level 2 project teams have instituted basic software acquisition management practices and controls. All members of the team are committed to complying with project plans, required policies, regulations, and standards. Project managers track costs, schedules, requirements, and performance of the project. Problems in meeting commitments are identified when they arise. Software requirements are baselined and the content is controlled. Software documentation is evaluated for compliance with specified requirements. Project teams work with their prime contractors, and any subcontractors, to establish a stable, cooperative working environment. Project teams track the performance of the contractor team for adherence with project plans and for ensuring that contractual requirements are being satisfied.
The process capability of Level 2 acquisition organizations can be summarized as being stable for planning and tracking the software acquisition because documented procedures provide a project environment for repeating earlier successes. The purpose of Software Acquisition Planning is to ensure that reasonable planning for the software acquisition is conducted and that all elements of the project are included.
Software Acquisition Planning involves the preparation for software-related areas in system level planning such as early budgetary action, schedule determination, acquisition strategy, risk identification, and software requirements definition. There are other traditional software acquisition planning activities that must be performed in the context of the system as a whole and in coordination with the project team (e.g., system requirements development, hardware/software partitioning, system level software requirements allocation, and solicitation management). Software Acquisition Planning also involves planning all aspects of the software acquisition project. Software acquisition planning documentation provides for implementation of all software acquisition-related policies.
Software acquisition planning begins with the earliest identification of a role for software in the system to be acquired. The process starts when reasonable resources are assigned to form a project team for the acquisition, independent of whether or not the team is formally constituted as an organizational entity. Software acquisition planning provides for conducting and documenting software acquisition planning activities and participation in system level planning activities as appropriate.

Goals
Goal 1 Software acquisition planning documents are prepared during system acquisition planning and maintained throughout the acquisition.
Goal 2 Software acquisition planning addresses the project's entire software acquisition process and life cycle support.

Commitment to perform
Commitment 1 The acquisition organization has a written policy for planning the software acquisition.
This policy typically specifies that: 1. The implementation of all software acquisition-related policies is provided for in the plans.
L2-2 CMU/SEI-99-TR-002 3. A review process is established for resolving issues, facilitating acquisition decisions, and focusing on critical issues such as affordability and risk.
4. Responsibility and accountability are clearly established for the project.

5.
Software acquisition planning documentation is prepared prior to solicitation activities.
6. Software acquisition planning documentation is maintained current.
7. Software acquisition strategy is included in the plans.
Commitment 2 Responsibility for software acquisition planning activities is designated.

Ability to perform
Ability 1 A group that is responsible for planning the software acquisition exists.

Ability 2
The acquisition organization provides experienced software acquisition management personnel to support project software acquisition planning. Experience means, for example, having participated in software acquisition management planning on at least one project, having a minimum of five years acquisition experience, having knowledge of the software's application domain, and having knowledge of current software engineering processes and technology.
Ability 3 Adequate resources are provided for software acquisition planning activities.
Resources include funding, staff, equipment, and tools.

Activities performed
Activity 1 Software acquisition planning personnel are involved in system acquisition planning.

Software Acquisition Planning
Level 2: The Repeatable Level Activity 2 The project's software acquisition planning is accomplished in conjunction with system acquisition planning.

Activity 3
The software acquisition strategy for the project is developed and documented.
The strategy typically includes considerations of: 1. The objectives of the acquisition.
2. Project constraints, such as funding and schedules.
3. Available and projected assets and technologies, such as reuse, NDI, and COTS.

5.
Potential contract types and terms.
7. Consistency with the system acquisition strategy. 4. The roles and responsibilities of the groups involved in the project.
Typically roles and responsibilities include: end user representation and involvement in the software acquisition, interface with system-level activities, and project team's relationship with and responsibilities to the acquisition organization.
6. A master schedule of software acquisition milestones.
7. Measurements to determine the progress of the software acquisition.
Activity 6 Life cycle support of the software is included in software acquisition planning documentation.
Life cycle support provisions typically include: 1. Identifying adequate facilities and resources for the software support organization.
2. Providing for transitioning the software from acquisition to operation and to the software support organization.
3. Providing for long-term growth and supportability of the system.

Activity 7
Life cycle cost and schedule estimates for the software products and services being acquired are prepared and independently reviewed.
In this instance, "independently reviewed" means a review by an individual (

Verifying implementation
Verification 1 Software acquisition planning activities are reviewed by acquisition organization management on a periodic basis.
The primary purpose of these reviews by acquisition organization management is to provide awareness of, and insight into, software acquisition planning activities at an appropriate level of abstraction. The reviews verify that acquisition organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
Verification 2 Software acquisition planning activities are reviewed by the project manager on both a periodic and event-driven basis.

L2-6 CMU/SEI-99-TR-002
Level 2: The Repeatable Level Solicitation Solicitation a key process area for Level 2: Repeatable The purpose of Solicitation is to prepare a solicitation package that identifies the needs of a particular acquisition and to select a contractor who is best capable of satisfying the requirements of the contract.
Solicitation involves planning and performing the activities necessary to issue the solicitation package, preparing for the evaluation of responses, conducting the evaluation, conducting supporting negotiations, and making recommendations for award of the contract. Solicitation ends with contract award.

Goals
Goal 1 The selection official selects a contractor who is qualified to satisfy the contract's requirements for the project's software-related products and services.
Goal 2 Solicitation activities are compliant with relevant laws, regulations, policies, and guidance.

Goal 3
The solicitation package includes the contractual software requirements and proposal evaluation criteria.

Commitment to perform
Commitment 1 The acquisition organization has a written policy for the conduct of the software portion of the solicitation.
This policy typically specifies that: 1. Planning for solicitations is documented.
2. Planning for proposal evaluation activities is documented.
3. Solicitations are conducted in a manner compliant with applicable laws, regulations, policies, and guidance for the solicitation.
4 Solicitation activities are tailored based on the cost and/or complexity of the software item or service being acquired.

Solicitation
Level 2: The Repeatable Level 5. The contract type (e.g., fixed-price, cost-reimbursement) is chosen based on the perceived risk of successfully delivering the required items while satisfying the cost and schedule requirements of the contract.
Normally, the less the risk to the offeror, the more rigid the contract type. For example, a fixed-price contract type would be suitable for a commodity buy while a cost-reimbursement contract type is more suitable for a research and development contract. 6. A selection official is designated for each solicitation.
Generally, selection officials are chosen based on their authority to commit the organization to a specified dollar amount which is equal to or greater than the estimated value of the solicitation.
7. The selection official for a solicitation has the ultimate responsibility for the conduct of the solicitation and for selecting the winning offeror.
Commitment 2 Responsibility for the software portion of the solicitation is designated.
Commitment 3 A selection official has been designated to be responsible for the selection process and the decision.

Ability to perform
Ability 1 A group that is responsible for coordinating and conducting solicitation activities exists.
Ability 2 Adequate resources are provided for solicitation activities.
Resources include funding, staff, equipment, and tools.
Ability 3 Individuals performing solicitation activities have experience or receive training. Experience means, for example, having participated in a software acquisition management role on at least one project, having knowledge in the domain of the application being acquired, and having familiarity of current software engineering processes, products, technology, and costing methodologies and tools. Additionally, some individuals must have experience in conducting solicitation activities.

Ability 4
The groups supporting the solicitation (e.g., end user, systems engineering, software support organization, and application domain experts) receive orientation on the solicitation's objectives and procedures.
L2-8 CMU/SEI-99-TR-002 Level 2: The Repeatable Level Solicitation Activities performed Activity I The project team performs its activities in accordance with its documented solicitation plans.
The plans typically cover: 1. The objectives of the solicitation.
2. Identification of the contents of the solicitation package such as: l The software requirements.
Refer to the Requirements Development and Management key process area.
P The proposal evaluation criteria.
In some solicitations a determination of the offeror's ability to perform the proposed tasks, over and above the evaluation of the material submitted, is appropriate. The value of the procurement, the cost of the determination, the staff resources available to perform the determination, and the development risk are some of the items that should be taken into account in determining the appropriateness of a determination effort.
• specifications; test plans, procedures, reports; study reports; configuration management plans, procedures, and reports; administrative, financial, and management reports; and project-specific products and reports.

P
The contract form (e.g., completion or term), contract type (e.g., fixed-price, cost-reimbursement), incentives, and a list of deliverable supplies and services.
• Information on contract acceptance procedures, specific acceptance criteria, and payment.
P Additional information guiding contractor performance during the contract, including enabling third-party participation, warranty provisions, and required data rights.
CMU/SEI-99-TR-002 L2-9 Solicitation Level 2: The Repeatable Level • Guidance on how the offerors are to respond, how the responses will be evaluated, and any additional administrative requirements such as socioeconomic program compliance.
• Documentation requirements for the offerors to submit with their response.
Some examples of required submissions include: a software engineering plan describing how offerors will carry out the software-related tasks in the solicitation package; a risk management plan describing how they will identify and manager risks associated with the software related risks called out in the solicitation package; identification of the measurements to be used in the project and made available to the project office; a statement of the offeror's planned use of NDI and COTS, and non-deliverable software, including any limitation on data rights; visibility for software engineering task progress and costs at a level appropriate for the type of contract and commensurate with the degree of risk related to the software acquisition; and the software-related work to be performed by subcontractors; and providing support for evaluation -and acceptance.
3. The participants, responsibilities, processes, methodologies, techniques, and schedules that will be followed in the conduct of the solicitation.
4. The proposal evaluation plans typically contain: i A description of the proposal evaluation organization structure, including the participants and their responsibilities.
in Proposed pre-evaluation activities.
in A summary of the acquisition strategy.
Po A statement of the proposal evaluation factors and their relative importance.
The proposal evaluation factors for software should contain factors central to the success of the software item or service being acquired.
•o. A description of the proposal evaluation process, methodology, and techniques to be used.
Offerors are evaluated based on their past performance, including domain experience, software development process maturity, and mature software products in the relevant domain.
Po A schedule of significant proposal evaluation milestones.
in A requirement to conduct analyses of the risks associated with each proposal.

A process for managing and controlling the solicitation documents.
Refer to Activity 4 of the Software Acquisition Planning key process area.
Activity 2 Solicitation activities are conducted in a manner compliant with relevant laws, policies, and guidance.
L2-10 CMU/SEI-99-TR-002 Level 2: The Repeatable Level Solicitation Activity 3 The software and evaluation requirements are incorporated into the solicitation package and resulting contract.
The contract provisions typically include: 1. Software technical and non-technical requirements to be satisfied by the contractor.
2. Requirements for the contractor to document a plan for developing the software products and services.
3. Requirements for the contractor to document a plan for evaluating the software products and services.
4. Measurements that provide the project team visibility into the contractor team's development and evaluation programs and results.

5.
Mechanisms and deliverables that provide the project team sufficient data to allow evaluation and analyses of acquired software products and services.
6. Requirements for the contractor to establish a corrective action system which includes a change control process for rework and reevaluation.
7. Requirements to ensure the contractor team supports each of the project's evaluation activities.
Activity 4 Proposals are evaluated in accordance with documented solicitation plans.
Activity 5 Cost and schedule estimates for the software products and services being sought are prepared.
Activity 6 Software cost and schedule estimates are independently reviewed for comprehensiveness and realism.
In this instance, "independently reviewed" means a review by an individual(s) other than the author(s) of the cost and schedule estimates.

Activity 7
The selection official uses proposal evaluation results to support his or her decision to select an offeror.

Activity 8
The project team takes action to ensure the mutual understanding of software requirements and plans with the selected offeror(s) prior to contract signing.

Verifying implementation
Verification 1 Solicitation activities are reviewed by the acquisition organization management on a periodic basis.
The primary purpose of these reviews by acquisition organization management is to provide awareness of, and insight into, the solicitation activities at an appropriate level of abstraction. The reviews verify that acquisition organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
Verification 2 Solicitation activities are reviewed by the project manager or designated selection official on both a periodic and event-driven basis.
L2-12 CMU/SEI-99-TR-002 The purpose of Requirements Development and Management is to establish a common and unambiguous definition of software-related contractual requirements that is understood by the project team, end user, and the contractor team. Software-related contractual requirements consist of technical requirements (system requirements allocated to software) and non-technical requirements (contractual agreements, conditions, and terms affecting the software portion of the acquisition). This key process area is divided into two subprocesses; development of softwarerelated contractual requirements and the management of these requirements for the duration of the acquisition.
Software requirements development involves those activities in which system level requirements are decomposed and allocated to software. To ensure software is appropriately addressed during system requirements definition and solicitation package preparation, the project team participates with the overall system acquisition team. Reuse of existing software assets, including architecture, is analyzed for use in satisfying requirements. Requirements development often involves direct participation from the end user to ensure that system-level requirements are well understood.
Software requirements management involves establishing and maintaining agreement among the project team, including the end user, and contractor team with respect to the software-related contractual requirements. It involves baselining the software requirements and controlling all subsequent requirements changes. This key process area and the contract address both technical and non-technical software requirements.
Requirements development and management begins with the translation of operational or end user requirements into solicitation documentation (e.g., specifications) and ends with the transfer of responsibility for the support of the software products.
Software-related contractual requirements define the scope of the software effort. Softwarerelated contractual requirements are incorporated into software project plans, activities, and products in an orderly manner. Requirements management ensures that software requirements are unambiguous, traceable, verifiable, documented, and controlled.

Requirements Development and Management
Level 2: The Repeatable Level Goals Goal 1 Software-related contractual requirements are developed, managed, and maintained.

Goal 2
The end user and other affected groups have input to the software-related contractual requirements over the life of the acquisition.
Goal 3 Software-related contractual requirements are traceable and verifiable.

Goal 4
The software-related contractual requirements baseline is established prior to release of the solicitation package.

Commitment to perform
Commitment 1 The acquisition organization has a written policy for establishing and managing the software-related contractual requirements.
1. This policy typically specifies that: • Software-related contractual requirements are documented.
• Software-related contractual requirements are reviewed by: "* Project management.

"* Other affected groups.
Some examples of affected groups include: end user, project system engineering, project evaluation, project quality assurance, software support organization, and project configuration and data management.
• Changes to the software-related contractual requirements are reflected in software acquisition plans, work products, services, and activities.
o A change control mechanism exists to manage and control changes to the softwarerelated contractual requirements.
"Managed and controlled" implies that the software requirements are baselined, the version of the software requirements at a given time (past or present) is known (i.e., version control), and the changes are incorporated in a controlled manner (i.e., change control).

Software requirements include:
L2-14 CMU/SEI-99-TR-002 Activities performed Activity I The project team performs its activities in accordance with its documented requirements development and management plans.
The plans typically cover: 1. The objectives of the project team's requirements development and management activities.
2. The activities to be performed, including requirements definition.

Identification of the groups, and intergroup coordination, associated with requirements development and management activities.
Some examples of groups include: potential bidders, project system engineering, project cost analysis, project configuration and data management, project evaluation, product-line management, project quality assurance, and end user.
4. Procedures for requirements development, including planning, elicitation, analysis, and verification.

5.
Procedures for requirements management, including baseline establishment, change control, and status reporting.
6. Procedures to define attributes that describe a "satisfactory" requirement. Refer to Activity 4 of the Software Acquisition Planning key process area.

Activity 2
The project team develops, baselines, and maintains software-related contractual requirements and places them under change control early in the project, but not later than release of the solicitation package.
2. Software-related contractual requirements are reviewed for completeness, understandability, verifiability, and priority.
3. Acceptance criteria for software-related contractual requirements are established and controlled.
4. Changes to the baseline are managed and controlled.

Activity 3
The project team appraises system requirements change requests for their impact on the software being acquired.

Activity 4
The project team appraises all changes to the software-related contractual requirements for their impact on performance, architecture, supportability, system resource utilization, and contract schedule and cost.
1. The impact on existing commitments is determined and changes in commitments are negotiated as appropriate.
Some examples of changes include: Changes to commitments made to individuals and groups external to the acquisition organization and changes to commitments within the acquisition organization.
2. Changes to software acquisition plans, work products, services, or activities resulting from changes in software-related contractual requirements are: • Tracked to completion.
Activity 5 Bi-directional traceability between the contractual requirements and the contractor team's software work products and services is maintained throughout the effort.
Some examples of mechanisms providing this traceability include: the project team itself performs and maintains this traceability and the project team tasks the contractor team (or other) to perform and maintain the traceability.

Activity 6
The end user and other affected groups are involved in the development of all software-related contractual requirements and any subsequent change activity.

Measurement and analysis
Measurement 1 Measurements are made and used to determine the status of the requirements development and management activities and resultant products.
Some examples of measurements include: effort expended; funds expended; progress towards completion of requirements development and management planning, the initial software requirements, and baselining the software requirements; number of change requests appraised; and completion of milestones.

Verifying implementation
Verification 1 Requirements development and management activities are reviewed by acquisition organization management (and the contractor) on a periodic basis.

Requirements Development and Management
The primary purpose of these reviews by acquisition organization management is to provide awareness of, and insight into, requirements development and management activities at an appropriate level of abstraction. The reviews verify that acquisition organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
Verification 2 Requirements development and management activities are reviewed by the project manager on both a periodic and event-driven basis. CMU/SEI-99-TR-002

L2-19
Project Management Level 2: The Repeatable Level

Project Management
a key process area for Level 2: Repeatable The purpose of Project Management is to manage the activities of the project office and supporting organizations to ensure a timely, efficient, and effective software acquisition.
Project Management involves planning, organizing, staffing, directing, and controlling project activities, such as determining project tasks, estimating software effort and cost, scheduling activities and tasks, training, leading the assigned personnel, and accepting software products and services.
Project management begins when the project office is officially chartered and terminates when the acquisition is completed.

Goals
Goal 1 Project management activities are planned, organized, controlled, and communicated.

Goal 2
The performance, cost, and schedule objectives of the software acquisition project are measured and controlled throughout the software acquisition.
Goal 3 Problems discovered during the software acquisition are managed and controlled.
Commitment to perform Commitment 1 The acquisition organization has a written policy for execution of the software project.
This policy typically specifies that: 1. The software-related requirements are used as the basis for planning the software acquisition project.

Refer to the Requirements Development and Management key process area.
L2-20 CMU/SEI-99-TR-002 4. Acquisition organization management reviews all software-related project commitments made to individuals and groups external to the organization.

5.
The project's software acquisition plans are managed and controlled.
6. A corrective action system is to be established by the project team to record problems and issues discovered.
Commitment 2 Responsibility for project management is designated.

Ability to perform
Ability 1 A team that is responsible for performing the project's software acquisition management activities exists.
Ability 2 Adequate resources for the project team are provided for the duration of the software acquisition project.
1. The project office allocates sufficient funds for internal operations, matrix support, contractual efforts, and specific mission areas of responsibility.
2. The project office is staffed with the proper number and kinds of people to address internal responsibilities and matrix support needed to accomplish the project's activities.
3. The project office plans for and provides the equipment needed to accomplish the project's activities.
4. The project office plans for and provides the tools needed to accomplish the project's activities.
Ability 3 When project trade-offs are necessary, the project manager is permitted to alter the performance, cost, or schedule software acquisition baseline.

Ability 4
The project team has experience or receives training in project software acquisition management activities.
Experience means, for example, having participated in a software acquisition management role on at least one project and having experience in the domain of the application being acquired. Additionally, some individuals should have general management skills as well as budgeting and scheduling experience.

Activities performed
Activity 1 The project team performs its activities in accordance with its documented software acquisition management plans.
Project software acquisition management plans typically contain or reference documents that contain: 1. Project objectives, purpose, scope, and duration.
2. Project summary and authorization.
8. Risk identification and tracking.
9. Relationship to systems engineering.
11. Installation of the Software Engineering Environment and other products of the contract.
14. Security policy and requirements.
16. The extent of end user involvement in the acquisition.
Refer to Activity 4 of the Software Acquisition Planning key process area.

Project Management
Activity 2 The roles, responsibilities, and authority for the project functions are documented, maintained, and communicated to affected groups.

Activity 3
The project team's commitments, and changes to commitments, are communicated to affected groups.

Activity 4
The project team tracks the risks associated with cost, schedule, resources, and the technical aspects of the project.
1. The priorities of the risks and the contingencies for the risks are adjusted as additional information becomes available.
2. High risk areas are reviewed with acquisition organization management on a regular basis.

Activity 5
The project team tracks project issues, status, execution, funding, and expenditures against project plans and takes action.

Activity 6
The project team implements a corrective action system for the identification, recording, tracking, and correction of problems discovered during the software acquisition.

Activity 7
The project team keeps its plans current during the life of the project as replanning occurs, issues are resolved, requirements are changed, and new risks are discovered. Verifying implementation Verification 1 Project management activities are reviewed by acquisition organization management on a periodic basis.

Measurement and analysis
The primary purpose of these reviews by acquisition organization management is to provide awareness of, and insight into, project management activities at an appropriate level of abstraction. The reviews verify that acquisition organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
Verification 2 Project management activities are reviewed by the project manager on both a periodic and event-driven basis.
L2-24 CMU/SEI-99-TR-002 The purpose of Contract Tracking and Oversight is to ensure that the software activities under contract are being performed in accordance with contractual requirements.
Contract Tracking and Oversight involves providing ongoing inputs and guidance to the contractor's effort and identifying risks and problems in the effort.
Contract tracking and oversight begins with the award of the contract and ends at the conclusion of the contract's period of performance.
The contract provides the binding agreement for establishing the requirements for the software products and services to be acquired. It establishes the mechanism to allow the project team to oversee the contractor team's software activities and evolving products and to evaluate any software products and services being acquired. It also provides the vehicle for mutual understanding between the project team and the contractor of the software requirements of the contract.

Goals
Goal 1 The project team has sufficient insight into the contractor's software engineering effort to ensure the effort is managed and controlled and complies with contract requirements.

Goal 2
The project team and contractor team maintain ongoing communication and commitments are agreed to by both parties.

Goal 3
The contract, and any changes, adhere to relevant laws, policies, regulations, and other planned guidance and implements project software acquisition requirements.

Commitment to perform
Commitment 1 The acquisition organization has a written policy for the contract tracking and oversight of the contracted software effort. 3. Applicable tools and methodologies are to be used to track the contracted effort.
4. The integrity of the contract is to be maintained throughout the contract performance period.

5.
Software efforts are to be addressed at reviews of contractor team performance.
Commitment 2 Responsibility for contract tracking and oversight activities is designated.
Commitment 3 The project team includes contracting specialists in the execution of the contract.

Ability to perform
Ability 1 A group that is responsible for managing contract tracking and oversight activities exists.
Ability 2 Adequate resources are provided for contract tracking and oversight activities.
Resources include funding, staff, equipment, and tools.
Ability 3 Individuals performing contract tracking and oversight activities have experience or receive training. Experience means, for example, having participated on at least one software project in areas of tracking software development under contract, providing technical guidance to contractors, and correctly applying contractual and legal policies and regulations for that effort.

Activities performed
Activity 1 The project team performs its activities in accordance with its documented contract tracking and oversight plans.
The plans typically cover: 1. Guidelines and criteria used in defining the project team's contract tracking and oversight activities.
L2-26 CMU/SEI-99-TR-002 Level 2: The Repeatable Level Contract Tracking and Oversight 2. Activities to be performed and the schedule to perform these activities.
3. Identification of groups, assigned responsibilities, and intergroup coordination.

5.
Techniques, tools, and methodologies to be employed for review and tracking of contractor team performance and compliance of the evolving software products and services.
6. Resources required to accomplish contract tracking and oversight activities.
7. Procedures to be followed to track and identify issues to closure.
Refer to Activity 4 of the Software Acquisition Planning key process area.

Activity 2
The project team reviews required contractor software planning documents which, when satisfactory, are used to oversee the contractor team's software engineering effort.
Changes to these plans are to be coordinated with the project team before being implemented by the contractor team.
Some examples of contractor planning documents that may be required include: project management, software risk management, software engineering, reuse, configuration management, and subcontractor management.

Activity 3
The project team conducts periodic reviews and interchanges with the contractor team.
These reviews may include end user and other affected groups input as needed. I These reviews typically attempt to ensure: 1. Continuing communications and mutual understanding of the contractual software requirements.
2. The contractor team is implementing activities according to approved plans.
3. Open issues with the contractor are resolved.
4. The contractor's activities and results are addressed.

5.
The contractor team's evaluations of the software products and services comply with approved evaluation plans and procedures.

Contract Tracking and Oversight
Level 2: The Repeatable Level 6. The contractor's corrective action system, including deficiency reporting, deficiency correction, re-testing, and rework, is being implemented according to approved plans and procedures.
7. The software requirements being analyzed and documented by the contractor team are unambiguous, traceable, testable, documented, and controlled.
8. Evolving software products and services will satisfy software-related contractual nontechnical and technical requirements, including functional, performance, operational, supportability, and other quality requirements.
Refer to the Evaluation key process area for evaluation of evolving products and services.
9. Issues are identified and plans developed for their resolution.

Activity 4
The actual cost and schedule of the contractor's software engineering effort are compared to planned schedules and budgets and issues are identified.
Some examples of contractor team progress tracking include: contract work packages, periodic progress measurements, earned value practices, and performance evaluations.

Activity 5
The size, critical computer resources, and technical activities associated with the contractor team's work products are tracked and issues identified.

Activity 6
The project team reviews and tracks the development of the software engineering environment required to provide life cycle support for the acquired software and issues are identified.
Activity 7 Any issues found by the project team during contract tracking and oversight are recorded in the appropriate corrective action system, action taken, and tracked to closure.
The appropriate corrective action system can be either the project team's or the contractor's.

Activity 8
The project team ensures that changes to the software-related contractual requirements are coordinated with all affected groups and individuals, such as the contracting official, contractor, and end user.

Verifying implementation
Verification 1 Contract tracking and oversight activities are reviewed by acquisition organization management on a periodic basis.
The primary purpose of these reviews by acquisition organization management is to provide awareness of, and insight into, contract tracking and oversight activities at an appropriate level of abstraction. The reviews verify that acquisition organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available. The purpose of Evaluation is to provide objective evidence that the evolving software products and services satisfy contract requirements prior to acceptance and transition to support.
Evaluation involves the development of requirements for the evaluation approach, including acceptance criteria, which are incorporated into both the solicitation package and the contract.
Evaluations are conducted throughout the contract performance period and results are analyzed to determine acceptability of the software products and services. Evaluation activities are designed to reduce interference with contractor-performed evaluations and to reduce duplication of evaluation efforts. Evaluation supports the activities that establish and verify the contractual requirements. Evaluation interacts with the Solicitation, Requirements Development, and Contract Tracking and Oversight key process areas.
Evaluation begins with development of the system requirements and ends when the software acquisition is completed.

Goals
Goal 1 Evaluation requirements are developed in conjunction with the technical requirements and are maintained over the life of the acquisition.
Goal 2 Evaluations are planned and conducted throughout the total period of the acquisition to provide an integrated approach that satisfies evaluation requirements and takes advantage of all evaluation results.

Goal 3
Evaluations provide an objective basis to support the decision for acceptance of the software products and services.
Commitment to perform Commitment 1 The acquisition organization has a written policy for managing the evaluation of the acquired software products and services.
This policy typically specifies that: L2-30 CMU/SEI-99-TR-002 Level 2: The Repeatable Level Evaluation 1. Evaluations are intended to reduce acquisition risk and to estimate effectiveness and suitability of the software products and services to support the satisfaction of end user needs.
2. The project includes plans for the evaluation of the acquired software products and services which specify evaluation objectives and evaluation criteria.
3. The project's evaluation activities begin with the development of the software-related contractual requirements.
Refer to the Requirements Development and Management key process area.

The project defines the evaluation requirements for the acquisition.
Some examples of evaluation requirements include: documented evaluation approach involving the project team, contractor team, and other affected groups; contractor evaluation activities, or tasks required; contractor deliverables such as test plans and reports; and integration evaluation schedule.

5.
Results of the evaluations are used as a basis for acceptance of the software products and services.
6. The project's software evaluation planning is updated to reflect changes to the software requirements.
Commitment 2 Responsibility for evaluation activities is designated.

Ability to perform
Ability 1 A group that is responsible for planning, managing, and performing evaluation activities for the project exists.
The evaluation group may include: 1. Independent evaluators.
4. System and software engineers.

5.
Members of the software requirements development and management group. Ability 3 Individuals performing evaluation activities have experience or receive training.

Refer to the Requirements Development and
Experience means, for example, having developed methods for the evaluation of software products and services, having applied basic analysis techniques, and having evaluated product quality data on at least one project.
Ability 4 Members of the project team and groups supporting the software acquisition receive orientation on the objectives of the evaluation approach.
Activities performed Activity 1 The project team performs its activities in accordance with its documented evaluation plans.
The plans typically cover: 1. A summary of the operational need and key operational effectiveness or suitability issues that must be addressed by evaluation.

2.
A brief description of the system and key areas of technical or engineering risk that must be addressed by evaluation.
3. A brief description of the integrated evaluation approach, including evaluation objectives, the evaluation activities to be performed, and the integrated schedule for these activities.
4. The groups responsible for conducting evaluation activities.

5.
A summary of the resources required to perform the evaluations.
6. The actions to be taken when software product or service quality is determined or projected to fall short of established requirements.
Refer to Activity 4 of the Software Acquisition Planning key process area.

L2-32 CMU/SEI-99-TR-002
Level 2: The Repeatable Level Evaluation Activity 2 The project's evaluation requirements are developed in conjunction with the development of the system or software technical requirements.
1. Development of evaluation requirements involves groups participating in evaluation activities, including the end users.
2. Development of evaluation requirements may involve: io Identifying the system or software requirements to be evaluated.
N Identifying architectural compliance issues to be evaluated.
p Establishing objective evaluation and acceptance criteria.
N Designing detailed activities to perform the evaluations.
• Identifying how to evaluate the quality of the acquired software products and services.
• Identifying requisite resources and ensuring that these resources will be in place.
o Developing a detailed schedule of activities.
N Ensuring traceability of evaluation requirements to system requirements.

Activity 3
The project's evaluation activities are planned to minimize duplication and take advantage of all evaluation results, where appropriate.

Activity 4
The project team appraises the contractor team's performance over the total period of the contract for compliance with requirements.
Any problems or issues such as areas of non-compliance found by evaluation activities are recorded in the appropriate corrective action system. I Refer to Activity 3 of the Contract Tracking and Oversight key process area.
Activity 5 Planned evaluations are performed on the evolving software products and services prior to acceptance for operational use.
As part of the planned integrated approach, complementary evaluations may be performed independently by the project team (with support of the contractor team) to further reduce the risk that the acquired software products and services will fail to satisfy contractual requirements.

Activity 6
Results of the evaluations are analyzed and compared to the contract's requirements to establish an objective basis to support the decision to accept the products and services or to take further action.

Verifying implementation
Verification 1 Evaluation activities are reviewed by acquisition organization management on a periodic basis.
The primary purpose of these reviews by acquisition organization management is to provide awareness of, and insight into, evaluation activities at an appropriate level of abstraction. The reviews verify that acquisition organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
Verification 2 Evaluation activities are reviewed by the project manager on both a periodic and event-driven basis.
L2-34 CMU/SEI-99-TR-002 The purpose of Transition to Support is to provide for the transition of the software products being acquired to the eventual software support organization. The necessary resources are identified, budgeted for, and are available when needed. The designated software support organization is fully prepared to accept responsibility for the software products in time to ensure uninterrupted support.
Transition to Support involves developing and implementing the plans for transitioning the acquired software products. It also involves ensuring that the contractor team and the software support organization are informed on the contents of the software engineering and support environments. The project team provides for an orderly, smooth transition of the software products from the contractor team to the software support organization.
Transition to support begins with the earliest definition of software requirements and ends when the responsibility for the software products is turned over to the software support organization.

Goals
Goal 1 The project team ensures the software support organization has the capacity and capability to provide the required support upon assumption of responsibility for the support of the software products.
Goal 2 There is no loss in continuity of support to the software products during transition from the contractor to the software support organization.
Goal 3 Configuration management of the software products is maintained throughout the transition.

Commitment to perform
Commitment I The acquisition organization has a written policy for the transitioning of software products to the software support organization.
This policy typically specifies that: 1. The software support organization is identified prior to developing the solicitation package.
CMU/SEI-99-TR-002 L2-35 Transition to Support Level 2: The Repeatable Level 2. Resources for software support are included in the appropriate budget(s).
3. The designated software support organization is involved, as appropriate, throughout the acquisition.
Commitment 2 The acquisition organization ensures that the software support organization is involved in planning for transition to support.
Commitment 3 Responsibility for transition to support activities is designated.

Ability to perform
Ability 1 A group that is responsible for coordinating transition to support activities exists.
Ability 2 Adequate resources are provided for transition to support activities.
Resources include funding, staff, equipment, and tools.

Ability 3
The organization responsible for providing support of the software products is identified no later than initiation of the solicitation package's development.

Ability 4
The software support organization, prior to transition, has a complete inventory of all software and related items that are to be transitioned.
Some examples of related items include: software descriptive documentation, necessary support software, reusable software assets, pertinent data from the corrective action and configuration management systems, and maintenance documentation.
Ability 5 Individuals performing transition to support activities have experience or receive training.
Experience means, for example, having participated in a software acquisition management role on at least one project and having participated in supporting software for at least two years.

Ability 6
The members of organizations interfacing with the transition to support activities receive orientation on the salient aspects of transition to support activities.

Activities performed
Activity 1 The project team performs its activities in accordance with its documented transition to support plans.
The plans typically cover: 1. The objectives and scope of the transition to support activities.
2. Identification and involvement of the software support organization.

5.
A schedule of transition activities.
7. Installation of products that are to be delivered.

Warranty and data rights provisions.
Refer to Activity 4 of the Software Acquisition Planning key process area.
Activity 2 Responsibility for the software products is transferred only after the software support organization demonstrates its capability and capacity to modify and support the software products.
This capability typically includes the availability of: 1. Hardware, software, physical, fiscal, and personnel resources.
3. An established configuration management system capable of supporting the software. The project team conducts activities to ensure that support of the software products is maintained and is effective during the transition from the contractor to the software support organization.

Activity 4
The project team oversees the configuration control of the software products throughout the transition.

Measurement and analysis
Measurement

Verifying implementation
Verification 1 Transition to support activities are reviewed by acquisition and software support organizations' managements on a periodic basis.
The primary purpose of these reviews by acquisition and software support organizations' management is to provide awareness of, and insight into, transition to support activities at an appropriate level of abstraction. The reviews verify that acquisition organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
Verification 2 Transition to support activities are reviewed by the project manager on both a periodic and event-driven basis.

-The Defined Level
At the Defined Level, the acquisition organization's standard software acquisition process is established, including the processes for both software contract management and project management, and its use is integrated into each project. The acquisition organization exploits effective software acquisition techniques when standardizing software acquisition processes.
There is a permanent focus on the process; the acquisition organization's software acquisition process group facilitates process definition and maintenance efforts. Processes established at the Defined Level are tailored as appropriate to perform more effectively within the project. An organization-wide training program is implemented to ensure that all practitioners and managers have the knowledge and skills required to carry out their tasks.
Projects use the acquisition organization's standard software acquisition process as a basis for creating their own defined software acquisition process that encompasses the unique characteristics of the project. Because the acquisition organization's standard software acquisition process is well defined and understood, management has good visibility into technical progress of the project. Management and engineering activities are coherently integrated on each project. When attempting to comply with required policy, the project team is capable of balancing the intent of the policy with a conflicting project need. The project team ensures compliance with plans and contract requirements and works with the contractor to resolve compliance difficulties when they arise. Risks are identified and managed throughout the acquisition.
The process capability of Level 3 acquisition organizations can be summarized as being controlled, since performance, cost, schedule, and requirements are under control and software quality is tracked. This capability is based on a common understanding of processes, roles, and responsibilities in a defined acquisition process. The purpose of Process Definition and Maintenance is to establish the acquisition organization's standard software acquisition process and an organizational responsibility for stabilizing and maintaining the standard software acquisition process.
Process Definition and Maintenance involves understanding the organization's and projects' software acquisition processes, collecting a set of software acquisition process assets, and coordinating efforts to appraise and improve software acquisition processes.
The acquisition organization provides the long-term commitments and resources to establish and maintain a software acquisition process group. This group is responsible for the definition, maintenance, and improvement of the acquisition organization's standard software acquisition process and other process assets, including guidelines for all projects to tailor the standard software acquisition process to their specific situations. It coordinates process activities with the software projects and related elements of the organization.

Goals
Goal 1 A standard software acquisition process for the acquisition organization is defined, managed, and controlled.
Goal 2 Process definition and maintenance activities are coordinated across the acquisition organization.
Goal 3 Information relating to the use of the acquisition organization's standard software acquisition process by the software acquisition projects is collected, analyzed, and made accessible.

Commitment to perform
Commitment 1 The acquisition organization has a written policy for software acquisition process definition and maintenance activities.
This policy typically specifies that: L3-2 CMU/SEI-99-TR-002 1. A software acquisition process group is established and is responsible for the acquisition organization-level software acquisition process activities and coordinating these activities with the projects.
2. A standard software acquisition process is defined for the acquisition organization.
The acquisition organization's standard software acquisition process may contain more than one process. A choice of processes may be necessary to address a project's unique acquisition environment.
3. The software acquisition process used by the projects is selected from the acquisition organization's standard software acquisition process and is tailored based on a project's specific acquisition environment.
4. The software acquisition process assets are maintained.
The acquisition organization's software acquisition process assets include: the acquisition organization's standard software acquisition process, guidelines and criteria for the projects' tailoring of the acquisition organization's standard software acquisition process, descriptions of the standard acquisition strategies approved for use, and the software acquisition process repository.
5. Improvements to, lessons learned, and other useful information on each project's defined software acquisition process, tools, and methods are collected and made accessible to other projects.
6. Information collected from the projects is reviewed, analyzed, and used to improve the acquisition organization's standard software acquisition process.
Commitment 2 Organization management sponsors the acquisition organization's activities for process definition and maintenance.
Organization management establishes: 1. Long-term plans and commitments for funding, staffing, and other resources, and its commitment to these software acquisition process activities.
2. Strategies for managing and implementing the activities for process definition and maintenance.
Commitment 3 Responsibility for process definition and maintenance activities is designated.

Ability to perform
Ability 1 A group that is responsible for the acquisition organization's process definition and maintenance activities exists.

Process Definition and Maintenance
Level 3: The Defined Level Ability 2 Adequate resources are provided for process definition and maintenance activities.
Resources include funds, staff, equipment, and tools.
Ability 3 Members of the software acquisition process group have experience or receive required training. Experience means, for example, having participated in a software acquisition management role on at least one project and membership in an active process group, such as a software engineering process group, for at least one year.
Ability 4 Project team members receive training on the acquisition organization's standard software acquisition process and their roles in this process.
Refer to the Training Program key process area.

Activities performed
Activity 1 The acquisition organization performs its activities in accordance with its documented process definition and maintenance plans.
The plan(s) should be consistent with other acquisition organization plans. Inputs, such as action plans from software acquisition process appraisals, strategic and operational business plans, and acquisition organization improvement initiatives, should be considered in the development of and subsequent updates to the plan.
The plans typically cover: 1. The objectives of the acquisition organization's process definition and maintenance activities.
Objectives define the direction and general timing for the acquisition organization's process definition and maintenance activities. Objectives may specify particular areas for improvement focus, such as contract performance management and procedural guidance and the coverage and time intervals for periodic appraisals of the software acquisition process.
2. The process definition and maintenance activities to be performed and the schedule for these activities.
3. The groups and individuals responsible for the process definition and maintenance activities.
4. The resources required to perform the process definition and maintenance activities.
5. The procedures to be followed in performing the process definition and maintenance activities.
L3-4 CMU/SEI-99-TR-002 Level 3: The Defined Level Process Definition and Maintenance 6. A required review and approval by acquisition organization management.

Management and control of the plan(s).
Refer to Activity 4 of the Software Acquisition Planning key process area.

Activity 2
The acquisition organization's standard software acquisition process is defined and maintained in accordance with its documented process definition and maintenance plans.
These plans typically require that: 1. The acquisition organization's standard software acquisition process satisfies the software acquisition policies, process standards, product standards, and legal requirements imposed on the organization, as appropriate.
2. State-of-the-practice software acquisition tools and methods are incorporated into the acquisition organization's standard software acquisition process, as appropriate.
3. A cost model(s) for project planning and estimating is developed and maintained as part of the acquisition organization's standard software acquisition process.
The cost model(s) include a software cost model(s) for estimating the contractor's software effort, schedule, and cost; a model(s) for estimating the project team's effort, schedule, and cost; and a software cost model(s) for estimating life cycle cost.
4. The software acquisition process group reviews, approves, manages, and controls any changes to the standard software acquisition process.

Activity 3
The acquisition organization's standard software acquisition process is appraised periodically and action plans developed and implemented to address the findings of the appraisal.
The action plans typically identify: 1. Which appraisal findings will be addressed, their priority, and the schedule for addressing them.
2. Guidelines for implementing changes to address the findings.
3. Responsibility for implementing the changes.
4. Closure plans for implementing the changes.

5.
Appraisal findings that will not be addressed and rationale for not doing so.

Activity 4
The acquisition organization's and projects' activities for defining and maintaining their software acquisition processes are coordinated at the organization level.

Process Definition and Maintenance
Level 3: The Defined Level Activity 5 Guidelines and criteria for a project's selection and tailoring of the acquisition organization's standard software acquisition process are developed and maintained.
The guidelines and criteria typically cover: 1. Selecting and tailoring the acquisition organization's standard software acquisition process and software acquisition strategy to accommodate the project's characteristics.
2. Standards for documenting the project's defined software acquisition process.
3. Procedures for obtaining permission to deviate from the acquisition organization's standard software acquisition process.
Activity 6 An organizational repository of software acquisition process information is established, managed, controlled, and maintained to support process definition and maintenance activities.
1. Information includes data about software the acquisition process, work products, software acquisition process-related documentation, and lessons learned.
Software acquisition process and work products data include: cost model used; project software measurements (planned and actual); and software size, effort, schedule, and deficiencies.
Some examples of software acquisition process-related documentation include: description of a project's defined software acquisition process and a project's software acquisition documentation (e.g., acquisition strategy, evaluation, solicitation, and software acquisition management plans).
2. Information on the acquisition organization's and projects' software acquisition processes and work products is collected.
3. Candidate information items are reviewed and appropriate items are included in the repository.
4. Information items are catalogued for easy access.

5.
The repository contents are made available for use by the software acquisition projects and other software acquisition-related groups.
6. The use of each information item is reviewed periodically for currency, relevancy, and validity, and the results are used to maintain the repository contents.
7. User access to the repository contents is controlled to ensure completeness, integrity, and accuracy of the information.
8. Access is limited to those who have a need to enter, change, view, analyze, or extract information. Sensitive information is protected and access to this information is appropriately controlled. progress towards completion of process definition and maintenance planning, defining the acquisition organization's standard software acquisition process, defining guidelines for tailoring the standard software acquisition process, establishing the standard software acquisition, repository, and establishing vehicles for disseminating software acquisition information; and completion of milestones.

Verifying implementation
Verification 1 Process definition and maintenance activities are reviewed by acquisition organization management on a periodic basis.
The primary purpose of these reviews by acquisition organization management is to provide awareness of, and insight into, process definition and maintenance activities at an appropriate level of abstraction. The reviews verify that acquisition organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
At a minimum, these reviews verify that: 1. Progress and status of the activities to define and improve the software acquisition process are reviewed against the plan. The purpose of Project Performance Management is to manage the software acquisition project according to a defined software acquisition process.
Project Performance Management involves developing the project's defined software acquisition process and managing the acquisition using this defined process. The project's defined software acquisition process is tailored from the acquisition organization's standard software acquisition process to address specific attributes of the project.
The project's management plans are based on the project's defined software acquisition process. These plans describe how the project's defined software acquisition process will be implemented and managed.
The basic requirements for estimating, planning, and tracking a software acquisition project are established in the Software Acquisition Planning, Project Management, and Contract Tracking and Oversight key process areas. The emphasis in Project Performance Management at Level 3 shifts from reacting to acquisition problems and issues to anticipating these problems and acting to mitigate the risk.

Goals
Goal 1 The project is managed according to a defined software acquisition process which is tailored from the acquisition organization's standard software acquisition process.

Goal 2
The project team achieves its software acquisition objectives.

Commitment to perform
Commitment 1 The acquisition organization has a written policy for the planning and managing of the project's software acquisition activities.
This policy typically specifies that: 1. The project's defined software acquisition process is developed and documented by tailoring the acquisition organization's standard software acquisition process according to approved tailoring guidelines.

Level 3: The Defined Level
Refer to Activity 5 of the Process Definition and Maintenance key process area.
2. The project's software acquisition activities are planned and performed according to the project's defined software acquisition process.

3.
Appropriate project measurement data are collected and stored by the project team according to the acquisition organization's software acquisition process repository requirements.
Ability to perform Ability 1 The individuals responsible for managing the software acquisition project activities have experience or receive required training. Experience means, for example, having participated in a software acquisition management role on at least one project and having experience in the domain of the application being acquired. Additionally, some individuals should have experience in project planning, organizing, controlling, budgeting, and scheduling.

Activities performed
Activity 1 The project's defined software acquisition process is developed and documented by tailoring the acquisition organization's standard software acquisition process according to the organization's tailoring guidelines.
Refer to Activity 5 of the Process Definition and Maintenance key process area.

Activity 2
The project team develops and maintains the Project Management Plan in accordance with the acquisition organization's standard software acquisition process.

Refer to the Software Acquisition Planning, Project Management, and Contract Tracking and
Oversight key process areas.
The Project Management Plan typically addresses: I . Management of solicitation and proposal evaluation plans.
2. Management of transition to support plans.

3.
Provisions for gathering, analyzing, and reporting measurement data needed to manage the software acquisition project.
4. Activities for software estimating, planning, and tracking related to the key tasks and work products of the project's defined software acquisition process.

L3-10
CMU/SEI-99-TR-002 8. Review and use of software acquisition management lessons learned, recorded, and stored in the acquisition organization's software acquisition process repository to estimate, plan, track, and re-plan the software acquisition project.
Refer to Activity 6 of the Process Definition and Maintenance key process area.

9.
A staffing plan that addresses the software acquisition project's needs for individuals with special skills and acquisition domain knowledge.
10. Training needs identified and documented to fit the specific needs of the software acquisition project.
Refer to the Training Program key process area.
11. Software acquisition management plans and processes to be followed in interacting with other groups.

Risk management planning.
Refer to Activity 2 of the Acquisition Risk Management key process area.
13. Resources to accomplish the requirements of the Project Management Plan.
14. Management of both organizational and technical interfaces.
15. Tailoring of the acquisition organization's standard software acquisition process.

Activity 3
The project team's software acquisition management activities are performed in accordance with the project's defined software acquisition process and the Project Management Plan.

Activity 4
The project's defined software acquisition process is revised as required to remain consistent with current project objectives.

Activity 5
The project team coordinates its activities with other organizations and activities supporting the project.

Activity 6
The acquisition organization's software acquisition process repository is used for project planning, estimating, and management.
Refer to Activity 6 of the Process Definition and Maintenance key process area.

Project Performance Management
Level 3: The Defined Level Activity 7 Critical dependencies are identified, negotiated, and managed.

Activity 8
The project team performs periodic reviews to ensure current and projected needs of the end user will be satisfied.

Activity 9
Measurements are used to determine project team performance and trends analyzed.
ITrend analysis relies on internal and external data.i

Activity 10
The project team identifies and analyzes risks and identifies specific risk mitigation actions for those risks.
Refer to Activity 3 of Software Acquisition Planning, Activity I of Contract Performance Management, and Activity 5 of Acquisition Risk Management key process areas.

Activity 11
The project team's software acquisition lessons learned are identified, documented, and entered into the acquisition organization's software acquisition process repository.

Measurement and analysis
Measurement The primary purpose of these reviews by acquisition organization management is to provide awareness of, and insight into, project performance management activities at an appropriate level of abstraction. The reviews verify that acquisition organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
Verification 2 Project performance management activities are reviewed by the project manager on both a periodic and event-driven basis.
The review should include the activities performed as specified in the Project Management Plan.

Contract Performance Management
Level 3: The Defined Level

Contract Performance Management a key process area for Level 3: Defined
The purpose of Contract Performance Management is to implement a defined contract management process, the objective of which is to acquire software products and services that satisfy contract requirements.
Contract Performance Management involves appraising the contractor team's software engineering performance and the quality of the evolving products and ongoing services. Based on the results of the appraisals, the acquisition may be adjusted. The process includes evaluation of final products and services to determine satisfaction of contractual requirements. The emphasis in contract performance management is to be proactive regarding contractor team performance and contract compliance issues and to minimize the effects of these issues. Additional activities include contributing to the project's risk management activities, fostering an environment of mutual cooperation with the contractor, and identifying improvements to the contract performance management process.
The contract performance management process integrates contract performance management activities with other project management activities. Contract Performance Management builds on the Contract Tracking and Oversight and Evaluation key process areas. Contract performance management begins when the contract is awarded and ends at the conclusion of the contract's period of performance.

Goals
Goal 1 The quality of contractor team process, performance, products, and services is appraised throughout the contract's period of performance to identify risks and take action to mitigate those risks as early as possible.
Goal 2 Contract Performance Management activities intended to foster a cooperative and productive environment among the end user, project team, and the contractor team are implemented.

Commitment to perform
Commitment I The acquisition organization has a written policy for the performance of contract performance management activities.

Contract Performance Management
This policy typically specifies that: 1. Contract performance management activities are performed in accordance with the project's defined software acquisition process.
2. Appropriate tools and methodologies are used to evaluate the products and services.
3. Risk analysis and management are included as part of the contract performance management activities.
4. Software products and services must pass a successful evaluation of contract requirements before they are accepted.

5.
Software acceptance is dependent on the successful completion of operational evaluation.
6. Evaluation requirements and measurable acceptance criteria are established before the request for proposals is released.
7. The contractor is encouraged to establish a rigorous engineering evaluation process.
8. The project's software evaluation planning is updated to reflect changes to the requirements.

Ability to perform
Ability 1 Individuals performing contract performance management activities have experience or receive required training in related software acquisition disciplines and contract performance management procedures. Experience means, for example, having participated on more than one software development project including appraising the contractor's planning documents, software engineering process, products, and services; having knowledge of current software development technologies; and having knowledge in the domain of the application being acquired.
Training includes areas of software evaluation, data reduction, and analysis techniques.

Activities performed
Activity 1 The project team performs its activities in accordance with its documented contract performance management plans.
In addition to the planning information called for in the Contract Tracking and Oversight key process area, these plans also typically cover: CMU/SEI-99-TR-002 L3-15 1. The guidelines and criteria used in defining the project's contract performance management activities.
2. The activities to be performed and the schedule to perform the activities.
Refer to Activity 3 of Software Acquisition Planning and Activity I of the Contract Tracking and Oversight key process areas.

Activity 2
The contractor team's software engineering process is appraised according to the project's defined software acquisition process.
Typical activities include: 1. The contractor team's software engineering process, practices, methodologies, and procedures are continually appraised for effectiveness and for compliance with contractual requirements.
2. The contractor's quality assurance, configuration management, corrective action, and risk management systems and processes are appraised for compliance with standards and plans to ensure that associated results support/promote attainment of contract objectives and compliance with contractual requirements.
3. Trend analysis of the contractor team's software engineering process is performed to detect issues in satisfying contractual requirements as early as possible.
Activity 3 Results of the contractor team's engineering activities are appraised according to the project's defined software acquisition process.
Appraisals conducted typically verify that: 1. The software requirements are being developed, documented, maintained, and verified according to the contractor team's software engineering process and are traceable to higher level requirements.
2. The software architecture is feasible and will satisfy future system growth and reuse needs.
3. The software design is developed, documented, maintained, and verified according to the contractor's software engineering process.
4. The software is developed and documented according to the contractor's software engineering process.

5.
The documentation that will be used to operate and support the software is developed and maintained according to the contractor's software engineering process.
6. The integration of commercial off-the-shelf (COTS) products with developed software is accomplished in accordance with the contractor's software engineering process and planning documents.
Activity 5 As understanding of the contractor team's software engineering process, products, and services improves, the project team may propose changes to the software acquisition approach to mitigate risks.
1. The project team determines the impact of changes before the changes are implemented.
2. Changes to the acquisition approach are coordinated within the project team and communicated to other affected groups.
3. Adjustments that affect contractual requirements are made through official contracting channels.

Activity 6
The end user periodically participates in the evaluation of evolving software products and services to determine the satisfaction of operational requirements.
Refer to Activity 5 of the Evaluation key process area.
Activity 7 Contract performance management activities are performed to foster a cooperative and productive environment among the end user, project team, and the contractor team.
Typical activities include: 1. Supporting a mutual understanding of the contract's requirements (and their flow down) between the project team and the contractor team.
2. Maintaining ongoing communications between the project team and the contractor team at appropriate levels.
3. Allowing the contractor to manage the software engineering efforts for which it is responsible, including engineering evaluation, with minimal project team interference.
4. Promoting the joint development of solutions to issues by the project team and the contractor team.
5. Requiring that the project team satisfies its commitments to the contractor team, such as review of contractor-generated documentation and timely feedback of the results of project team evaluations of contractor team's performance, products, and services.
6. Maintaining mutual understanding of methods to administer the contract.

Level 3: The Defined Level
Some examples of areas to be addressed include: maintenance of bi-directional, non-intrusive communications between the project team and the contractor team; how issues and concerns not resolvable at lower levels will be decided; methods of identifying and mitigating risks; and the use of both software process and product measurements as a common basis of communication to understand the requirements and the status of the project.

Measurement and analysis
Measurement 1 Measurements are made and used to determine the status of the contract performance management activities and resultant products.
Some examples of measurements include: effort expended; funds expended; progress towards completion of contract performance management planning, appraisals, evaluations, and risk analysis; and completion of milestones.

Verifying implementation
Verification 1 Contract performance management activities are reviewed by acquisition organization management on a periodic basis.
The primary purpose of these reviews by acquisition organization management is to provide awareness of, and insight into, contract performance management activities at an appropriate level of abstraction. The reviews verify that acquisition organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
Verification 2 Contract performance management activities are reviewed by the project manager on both a periodic and event-driven basis.
L3-18 CMU/SEI-99-TR-002 The purpose of Acquisition Risk Management is to identify risks as early as possible, adjust the acquisition strategy to manage those risks, and develop and implement a risk management process as an integral part of the acquisition organization's standard software acquisition process. Acquisition risk management begins with the process of defining the system need and terminates when the software acquisition is completed. Acquisition risk management becomes an integral part of the solicitation, project performance management, and contract performance management processes.
Acquisition risk management is a two-part process. First, the software acquisition strategy identifies the risks associated with the acquisition of the system and the approach is planned based on those risks. Second, a process is employed to manage the risks throughout the acquisition.
Risk identification includes categorization of the risk based on historical data and estimates to determine the impact of each risk on quality, performance, schedule, and cost. The risks are analyzed to determine their impact on acquisition strategy and software engineering. Analysis includes determining the driver of each risk area and the impact of the risk so that risk handling strategies may be proposed and tested.
Acquisition risk management is planned through the Software Acquisition Risk Management Plan which details the processes to take place in acquisition planning and software acquisition management. The Software Acquisition Risk Management Plan describes the management actions and procedures to identify, analyze, and rank order risks, and the risk handling methods to be applied.

Goals
Goal 1 Project-wide participation in the identification and mitigation of risks is encouraged and rewarded.

Goal 2
The project team's defined software acquisition process provides for the identification, analysis, and mitigation of risks for all project functions. This policy typically specifies that: 1. Risk identification is performed throughout the project life cycle in accordance with the project's defined software acquisition process.
2. Risk management activities involve the project team, end user, and the contractor team as appropriate.
3. Risk management is a positive and proactive part of software acquisition.

Risk information is communicated throughout the project team.
Commitment 2 Responsibility for software acquisition risk management activities is designated.

Ability to perform
Ability 1 A group that is responsible for coordinating software acquisition risk management activities exists.
Ability 2 Adequate resources are provided for software acquisition risk management activities.
Resources include funding, staff, equipment, and tools.
Ability 3 Individuals performing software acquisition risk management activities have experience or receive required training. Experience means, for example, having participated in a software acquisition management role and having applied risk management techniques on at least one project and having experience in the domain of the application being acquired.

Activities performed
Activity 1 Software acquisition risk management activities are integrated into software acquisition planning.

Acquisition Risk Management
Risk management includes risk identification, analysis, planning, tracking, and controlling.
The acquisition strategy evolves based on risk identification and analysis.
Refer to Activity 3 of the Software Acquisition Planning key process area.

Activity 2
The Software Acquisition Risk Management Plan is developed in accordance with the project's defined software acquisition process.
The plan typically provides for: 1. The processes that the project team will follow for risk management.
2. Reporting on risk management activities.
3. Plans for identification, analysis, and mitigation of risks.
4. The process for managing and controlling the Software Acquisition Risk Management Plan.

Resource requirements.
Refer to Activity 4 of the Software Acquisition Planning key process area.

Activity 3
The project team performs its software acquisition risk management activities in accordance with its documented plans.

Activity 4
The project team encourages and rewards project-wide participation in the identification and mitigation of risks.
1. Mitigation plans and decisions are predicated upon key project milestones.
2. Risks are presented, discussed, and action taken in a non-threatening environment.
3. Where appropriate, research on individual risks is authorized and encouraged.
Activity 5 Risk management is conducted as an integral part of the solicitation, project performance management, and contract performance management processes.
Refer to Activity I of Solicitation, Activities 2 and 10 of Project Performance Management, and Activities I and 2 of the Contract Performance Management key process areas.
Activity 6 Software acquisition risks are analyzed, tracked, and controlled until mitigated.
2. Reporting of the updated risk assessments.
3. Planned mitigation actions are maintained current.
Activity 7 Project reviews include the status of identified risks.
Items reported typically include: 1. Changes in the priority of risks.
2. Changes in mitigation plans.

New risks identified.
Refer to Activity 10 of the Project Performance Management key process area.

Measurement and analysis
Measurement

Verifying implementation
Verification 1 Acquisition risk management activities are reviewed by acquisition organization management on a periodic basis.
The primary purpose of these reviews by acquisition organization management is to provide awareness of, and insight into, acquisition risk management activities at an appropriate level of abstraction. The reviews verify that acquisition organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available. The purpose of Training Program is to develop the skills and knowledge of individuals so they can perform their software acquisition roles effectively and efficiently.
Training Program involves appraisal of training requirements at the acquisition organization, project, and individual levels. The acquisition organization surveys its current and future skill needs and determines how these skills will be obtained. Current weaknesses of the acquisition organization are understood and plans are developed to systematically address the weaknesses.
Some skills are effectively and efficiently imparted through informal vehicles, whereas other skills need more formal training vehicles to be effectively and efficiently imparted. The appropriate vehicles are selected and used.
Members of the acquisition organization are schooled in the standard software acquisition process, the project, the domain, and in the skills and knowledge needed to perform their jobs effectively. Members effectively use, or are prepared to use, the capabilities and features of the existing and planned work environment. The project teams become more effective through a better understanding of their work processes.
This key process area covers the group that is performing the organization's training function. The processes identifying specific training topics (e.g., knowledge or skills needed) are contained in the common feature "Ability to perform" of the individual key process areas.

Goals
Goal 1 Training required for the projects to achieve their software acquisition objectives is identified and provided.

Goal 2
The training program satisfies the acquisition organization's training needs, including training on the standard software acquisition process.

Commitment to perform
Commitment 1 The organization has a written policy for satisfying its training needs.

Ability to perform
Ability I A group that is responsible for fulfilling the training needs of the organization exists.
IThe members of the triiggopmyinclude full-time orpr-ieinstructors drawn from the organization and from external sources.
Ability 2 Adequate resources are provided for training program activities. The organization's training program typically covers: 1. Training senior management in the technologies and strategies that are being used for acquisition management.
2. The set of skills needed and when those skills are needed.
3. Training that is required, for whom it is required, and when it is required.
Training for individuals is tied to their work responsibilities such that on-the-job activities or outside experience will reinforce the training within a reasonable time after receiving the training.
The training may be provided by the project, by the organization's training program, or by an external group-Activity 2 Each software acquisition project identifies specific training needs and develops a training plan in accordance with training program procedures.
The project's training plan typically covers: 1. The set of skills needed and when those skills are needed.
2. Skills for which training is required and the skills that will be obtained via other vehicles.
3. Training that is required, for whom it is required, and when it is required.
Training for individuals is tied to their work responsibilities such that on-the-job activities or outside experience will reinforce the training within a reasonable time after receiving the training.
4. How training will be provided with a breakdown of resources required to provide this training.
The training may be provided by the project, by the organization's training program, or by an external group-1 5. The requirement that the software acquisition project's training plans undergo a peer review.
Refer to Activity 4 of the Software Acquisition Planning key process area.
Activity 3 Software acquisition training for the organization is provided in accordance with the organization's training program.
Activity 4 A waiver procedure for required training is established and used to determine whether individuals already possess the knowledge and skills required to perform their designated roles.
Activity 5 Training records are maintained.
Some of the records to be maintained are: 1. All students who successfully complete each training course or other approved training activity.
2. All students who successfully complete their designated required training as specified in their training plan.

Verifying implementation
Verification 1 Training program activities are reviewed by organization management on a periodic basis.
The primary purpose of these reviews by organization management is to provide awareness of, and insight into, training program activities at an appropriate level of abstraction. The reviews verify that organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.

Level 4 -The Quantitative Level
At the Quantitative Level, the project team sets quantitative quality objectives for processes, products, and services. A process is established to provide a quantitative foundation for evaluating project processes, products, and services.
Project teams achieve control over acquisition processes, products, and services by narrowing the variation in project performance to within acceptable quantitative boundaries. Data on the defined software acquisition process and variations outside the acceptable quantitative boundaries are used to adjust the process to prevent recurrence of deficiencies. An acquisition organization-wide process repository provides for the collection and analysis of data from the projects' defined software acquisition processes.
The process capability of Level 4 acquisition organizations can be summarized as measured and operating within measurable limits. This level of process capability allows an organization to predict process and product quality trends within the quantitative bounds of these limits. When these limits are exceeded, action is taken to correct the situation. The purpose of Quantitative Process Management is to quantitatively control the project's performance resulting from implementation of the software acquisition process. Projects fully implementing quantitative process management will have stable processes that are under quantitative control. Additionally, the capability of the acquisition organization's standard software acquisition process is defined quantitatively.
Quantitative Process Management involves each project team setting performance objectives, measuring performance, analyzing results, and making adjustments to maintain performance within acceptable limits. Performance variations (i.e., variations attributable to specific implementations of the process) are measured and actions taken to bring performance within acceptable limits. When the project team's performance is stabilized within acceptable limits, the defined software acquisition process, the associated measurements, and the acceptable performance limits are baselined to permit quantitative control of the project team's performance.
The acquisition organization collects performance data from the software acquisition projects and uses these data to define the capability of its standard software acquisition process (see the Process Definition and Maintenance key process area). The capability of the acquisition organization's standard software acquisition process is indicative of the performance that can be expected from the next software acquisition project undertaken. These capability data are, in turn, used by the software acquisition project teams to set their performance objectives and to analyze the performance of their defined software acquisition processes. The capability data are also used by the project teams in tailoring the acquisition organization's standard software acquisition process to a particular acquisition.

Goals
Goal 1 The performance of each project is quantitatively measured, managed, and controlled.

Goal 2
The capability of the acquisition organization's standard software acquisition process is analyzed and defined in quantitative terms.

Commitment to perform
Commitment 1 The acquisition organization has a written policy for the measurement and quantitative control of software acquisition process performance.

Quantitative Process Management
The term "quantitative control" implies any quantitative or statistically-based technique appropriate for analyzing a software acquisition process, identifying causes of process performance variations, and adjusting the process to bring performance within prescribed limits.
This policy typically specifies that: 1. Each project team plans and implements quantitative control of its defined software acquisition process.
2. Access to sensitive data is appropriately controlled.
Commitment 2 The acquisition organization has a written policy for analysis of the capability of its standard software acquisition process.
This policy typically specifies that: 1. Each project team's measurements of process performance are analyzed to establish and maintain a process capability baseline for the acquisition organization's standard software acquisition process.
o The process capability baseline includes: "* The description of the acquisition organization's standard software acquisition process.
"* The standard definitions of the measurements.
"* The expected range of values for the measurements.
2. The acquisition organization's software acquisition process capability baseline is used by each project team in establishing its process performance objectives.
Ability to perform Ability 1 Adequate resources are provided for quantitative process management activities.
Resources include funds, staff, equipment, and tools.
•. Tools to support quantitative process management activities are made available. Ability 2 Acquisition organization management support exists for collecting, recording, storing, and analyzing process and product measurement data.

Ability 3
The individuals implementing or supporting quantitative process management activities have experience or receive required training. Experience means, for example, having participated in a software acquisition management role on at least one project and having a minimum of three years experience in acquisition, software measurement, and statistical process control.
Some examples of experience or training include: defining and performing the software acquisition process; modeling and analyzing the software acquisition process; selecting, collecting, and verifying process measurement data; applying basic quantitative methods and analysis techniques; and defining quantitative objectives for process management.

Ability 4
The members of the project team and groups supporting the software acquisition project receive orientation on the objectives and values of quantitative process management.

Activities performed
Activity 1 The acquisition organization's software acquisition process capability baseline is defined in quantitative terms and is maintained according to a written procedure.
This procedure typically specifies that: 1. Project teams' process performance is analyzed to establish the acquisition organization's quantitative process capability baseline.
2. Process capability trends for the acquisition organization's standard software acquisition process are examined to predict likely deficiencies or opportunities for improvements.

Quantitative Process Management
Some examples of using measured capability trends include: predicting the occurrence of project deficiencies and comparing the predictions to actuals and predicting the distribution and severity of deficiencies remaining in a project team work product based on data from reviews.
3. Changes to the acquisition organization's standard software acquisition process are tracked and analyzed to determine their effect on the quantitative process capability baseline.
Activity 2 Each project team's quantitative goals and objectives are derived from the acquisition organization's quantitative process capability baseline.
Refer to the Program Performance Management key process area for a description of tailoring requirements.

Activity 3
Each project team performs its activities in accordance with its documented quantitative process management plans.
The plans typically cover: 1. The goals and objectives of the project team's quantitative process management activities.
2. The software acquisition tasks or other acquisition tasks that will be measured and analyzed.
The data collection and the quantitative analyses strategy are based on the project's defined software acquisition process.
3. The instrumentation of the project's defined software acquisition process.
The instrumentation is based on the acquisition organization's measurement program, the description of the acquisition organization's standard software acquisition process, and the description of the project's defined software acquisition process.
4. The quantitative process management activities to be performed and the schedule for these activities.
In addition to current organizational and project needs, measurements that may be useful to future efforts may be included.

5.
The groups and individuals responsible for the quantitative process management activities.
6. The resources required to perform the quantitative process management activities, including staff and tools.
7. The procedures to be followed in performing the quantitative process management activities.

Quantitative Process Management
Level 4: The Quantitative Level Activity 4 The measurement data used to quantitatively control the project's defined software acquisition process are collected in accordance with the acquisition organization's standard software acquisition process.
Some examples of measurement data include: effort, schedule, and cost estimates used in the solicitation phase; actual project data on software size, effort, schedule, and cost; project team productivity data (e.g., staff hours expended, document pages reviewed, and requirements normally tested); project team quality measurements (e.g., number and severity of deficiencies found in the project requirements and project team work products); and timeliness of project team work products.
Project team work products are those products that are produced by the project team as it executes the project's defined software acquisition process (e.g., solicitation, acquisition plans, document reviews).
Project team work products are not the deliverables, products, end items, or other output produced by[ the contractor in satisfaction of the contract.
The process typically specifies that: 1. The measurement data collected support the acquisition organization's and the project team's measurement objectives.
2. The specific measurement data to be collected, their precise definitions, the intended use and analysis of each measurement, and the process control points at which they are collected are defined.
3. The measurements cover the properties of the software acquisition process activities and major software acquisition work products.
4. The verification of each project's measurement data is independently determined.

5.
The collected measurement data are stored in the acquisition organization's software acquisition process repository as appropriate.
Refer to Activity 6 of the Process Definition and Maintenance key process area.
Activity 5 Each project's defined software acquisition process is analyzed and quantitatively controlled according to the project's quantitative process management plans.
The plans typically specify that: 7. The process performance for the software acquisition project team is managed and controlled.
Activity 6 Causal analysis is conducted on a periodic basis to determine special causes of variances from the project's defined software acquisition quantitative process goals and objectives.
An example of a method to determine root causes is cause/effect analysis.

Activity 7
Changes in the project's defined software acquisition process are implemented to correct special causes of variance.
Activity 8 Reports documenting the results of the project team's quantitative process management activities are prepared and recorded in the software acquisition organization's process repository.
Refer to the Process Definition and Maintenance key process area for incorporating process data in the repository. the percentage of integration of the quantitative process management activities into the acquisition organization's standard software acquisition process and the percentage of integration of the quantitative process management activities into the project's defined software acquisition process.

Verifying implementation
Verification 1 Quantitative process management activities are reviewed by acquisition organization management on a periodic basis.
The primary purpose of these reviews by acquisition organization management is to provide awareness of, and insight into, quantitative process management activities at an appropriate level of abstraction. The reviews verify that acquisition organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.

Verification 2
Each project team's quantitative process management activities are reviewed by the project manager on both a periodic and event-driven basis.
This review may be conducted in conjunction with project management oversight reviews, such as those conducted for the Project Performance Management and Contract Performance Management key process areas.
L4-8 CMU/SEI-99-TR-002 The purpose of Quantitative Acquisition Management is to manage the contractual effort through the application of quantitative methods.
Quantitative Acquisition Management involves utilizing process and product measurements as an intrinsic part of management review and oversight to quantitatively manage the acquisition of software products and services.
As the acquisition organization continues to attain higher levels of maturity there is a transition to quantitative methods. This transition is marked by the involvement of all levels of acquisition management. The result represents an advance from contract performance management to acquisition management using quantitative methods. Another result of this transition is an expected increase in the quality of acquired products and services.
The quantitative acquisition management process is integrated with quantitative process management. The actions of quantitative process management at the project level and across the acquisition organization are integral to acquisition management.

Goals
Goal 1 Quantitative objectives for the acquired products and services are defined.

Goal 2
The contracted effort is managed quantitatively.

Commitment to perform
Commitment 1 The acquisition organization has a written policy for quantitatively managing the acquisition of software products and services.
The term "quantitative management" implies using quantitative or statistical based techniques for analyzing the acquired products and services, identifying causes of performance variations, and making adjustments to bring the products and services within prescribed limits.
This policy typically specifies that: CMU/SEI-99-TR-002 L4-9 Quantitative Acquisition Management Level 4: The Quantitative Level 1. Each project's defined software acquisition process calls for planning and implementing quantitative control of its software acquisition.
2. Each project defines quantitative objectives for the acquisition of software products and services and collects measurements based on the project's defined software acquisition process.
Comnmitment 2 The acquisition organization has a written policy that incorporates quantitative methods into management review and oversight activities.
Ability to perform Ability 1 Project team personnel have experience and are trained in quantitative methods.
Experience means, for example, having participated in an acquisition where quantitative methods have been applied to the process, products, and services of the acquisition.

Ability 2
The members of the project team and groups supporting the software acquisition project receive orientation on the goals and values of quantitative methods.

Measurement and analysis
Measurement 1 Measurements are made and used to determine the status of the quantitative acquisition management activities and resultant products.
Some examples of measurements include: effort expended, funds expended, progress towards completion of quantitative acquisition management planning and the quantitative objectives for the solicitation and contract, and completion of milestones.
Measurement 2 Measurements are made and used to determine the effectiveness of the quantitative acquisition management activities and resultant products.
Some examples of measurements include: analytical reports that address quality of software products and services, percentages of variances from stated objectives (i.e., based on upper and lower bounds), and percentages of variances from quantitative objectives.

Verifying implementation
Verification 1 Quantitative acquisition management activities are reviewed by acquisition organization management on a periodic basis.

Quantitative Acquisition Management
The primary purpose of these reviews by acquisition organization management is to provide awareness of, and insight into, quantitative acquisition management activities at an appropriate level of abstraction. The reviews verify that acquisition organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
Verification 2 Quantitative acquisition management activities are reviewed by the project manager on both a periodic and event-driven basis.
At the Optimizing Level, the acquisition organization is focused on continuous process improvement. An acquisition organization has the means to identify processes that are candidates for optimization. Statistical evidence is available to analyze process effectiveness and is used to refine policies. Technological innovations that exploit the best software acquisition management and engineering practices are identified, appraised, and institutionalized.
Level 5 acquisition organizations are continuously striving to reduce variation in performance while increasing their level of performance. Improvement occurs both by incremental advancements in the existing mechanisms and by innovations using new technologies and techniques.

Continuous Process Improvement
Level 5: The Optimizing Level

Continuous Process Improvement
a key process area for Level 5: Optimizing The purpose of Continuous Process Improvement is to evolve the software acquisition processes used in the acquisition organization through managed continuous process improvement. Quantitative objectives for the acquisition organization's standard software acquisition process and the projects' defined software acquisition processes are the targets of the improvement activity.
Continuous Process Improvement involves defining quantitative process improvement objectives with the involvement and sponsorship of acquisition organization management. It is a continuous effort to proactively and systematically identify, appraise, and implement improvements to the acquisition organization's standard software acquisition process and the projects' defined software acquisition processes.
The commitment to continuous process improvement is acquisition organization wide. Training and incentive programs are established to encourage and enable all acquisition organization personnel to participate in the software acquisition continuous process improvement activities. Improvement opportunities are identified and appraised in terms of how well they move the acquisition organization and its projects toward software acquisition continuous process improvement objectives.
When software acquisition process improvements are approved for normal practice, the acquisition organization's standard software acquisition process and the projects' defined software acquisition processes are revised. The Process Definition and Maintenance key process area defines the actions for changing the acquisition organization's standard software acquisition process. The Project Performance Management key process area defines the actions for changing the projects' defined software acquisition processes.
The Acquisition Innovation Management key process area defines the actions for adopting and transforming new techniques and technologies into the acquisition organization.

Goals
Goal 1 Participation in continuous process improvement activities is acquisition organization wide.

L5-2 CMU/SEI-99-TR-002
2. Each process improvement proposal is evaluated, the expected benefits are determined, a decision is made whether to implement the proposal, and the decision rationale is documented.
3. Implementation of the approved process improvement actions is assigned and planned.
4. The status of each process improvement proposal is tracked.

5.
Completed process improvement actions are reviewed, verified, and approved before closure.
6. Submitters of process improvement proposals receive: o Prompt acknowledgment of their proposals.
o Notification of the disposition of their proposals.
7. Appropriate process changes are incorporated into the acquisition organization's standard software acquisition process.
Refer to Activities 2, 3, and 4 of the Process Definition and Maintenance key process area.
L5-6 CMU/SEI-99-TR-002 Level 5: The Optimizing Level Continuous Process Improvement 8. Appropriate changes are incorporated into the projects' defined software acquisition processes.
Refer to Activity 4 of the Project Performance Management key process area.

Activity 6
Records of process improvement activities are maintained in the acquisition organization's repository for software acquisition process information.
1. Information about the initiation, status, and implementation of the process improvement proposals is maintained.
2. Historical data are maintained and reports produced on process improvement activities and results.
Some examples of records and reports include the: projects' productivity, quality, and schedule performances; projects' deficiency histories; organizational quality and productivity trends; and cost, schedule, and productivity of software acquisition process definition and maintenance.
Refer to Activity 6 of the Process Definition and Maintenance key process area. the percentage of integration of process improvement activities into the acquisition organization's standard software acquisition process, the number of process improvement proposals submitted and implemented for each process area, the response time for handling process improvement proposals, CMU/SEI-99-TR-002 L5-7

Continuous Process Improvement
Level 5: The Optimizing Level the number and type of recognition for process improvement activities awarded, and analytical reports that address the improvement of product and service quality.

Verifying implementation
Verification 1 Continuous process improvement activities are reviewed by acquisition organization management on a periodic basis.
The primary purpose of these reviews by acquisition organization management is to provide awareness of, and insight into, continuous process improvement activities at an appropriate level of abstraction. The reviews verify that acquisition organization policy is being implemented. The time between reviews should satisfy the needs of the organization and may be lengthy, as long as adequate mechanisms for exception reporting are available.
Some examples of review subjects include: participation in the continuous process improvement activities, process performance, needed changes in objectives, issues, and revisions to the continuous process improvement plans as appropriate.
Verification 2 Acquisition organization managers and project managers receive feedback on the status and results of continuous process improvement activities.
Feedback is provided on a periodic or event-driven basis and includes: 1. A summary of the major continuous process improvement activities.
2. Significant innovations and actions taken to address continuous process improvement.
3. A summary status of process improvement proposals that are submitted, opened, and completed or closed.
4. Reports on the effectiveness of implemented process improvements.

L5-8 CMU/SEI-99-TR-002
Level 5: The Optimizing Level Acquisition Innovation Management Acquisition Innovation Management a key process area for Level 5: Optimizing The purpose of Acquisition Innovation Management is to continually improve the acquisition process through the adoption and transfer of new techniques and technologies. Acquisition innovation management is a primary responsibility of the acquisition organization; however, the adoption activity may be carried out through individual acquisition projects. While a project can act by itself, the environment for adoption should be fostered and led by the acquisition organization.
Acquisition Innovation Management involves the identification, appraisal, implementation, adoption, and transfer of new techniques and technologies that support the software acquisition process.
The focus is on improving the acquisition process through the adoption and implementation of new techniques and technologies. Adoption of new techniques and technologies is accomplished in concert with continuous process improvement (refer to the Continuous Process Improvement key process area).
Acquisition innovation management of new techniques and technologies encompasses a range of possibilities. These techniques and technologies are those which are new on the horizon or are new to the acquisition. They may range from introduction of a new technique to the project (such as automated documentation) to adoption of a new management strategy (e.g., product line) at the acquisition organization level. The acquisition organization and the project act in cooperation to implement new techniques and technologies that may provide a specific benefit to the project, as well as an overall benefit to the organization.

Goals
Goal 1 The acquisition organization proactively adopts and implements new techniques and technologies to improve the standard software acquisition process.
Goal 2 Participation in the acquisition innovation management process is organization wide.