Appendix C: Abridged Version of the Key Practices
This appendix provides an abridged version of the key practices, which provides
a high-level overview of the primary activities the SEI prescribes for each key
process area. It can be used to get a "quick look" at each key process area.
It does not, however, provide the specific activities for these key practices
nor does it cover all the key practices. It is intended for informational
purposes, not for determining compliance to the key practices or planning
process improvements.
This abridgement contains a short description of the key process area, its
goals, and the key practice statements from the Activities Performed common
feature of the key process area. These items are extracted verbatim from the
detailed key practice tables.
There are a number of other key practices specified under the other common
features (i.e., Commitment to Perform, Ability to Perform, Measurement and
Analysis, and Verifying Implementation) that are not contained in this
appendix. These other key practices must be in place to ensure the key
practices are implemented appropriately and effectively, are solidly
established, will be maintained and not erode over time, and can be effectively
applied to new work. To appropriately establish a key process area, the full
set of key practices should be used.
Commitment to Perform typically involves establishing organizational policies
and senior management sponsorship. Ability to Perform typically involves
resources, organizational structures, and training. Measurement and Analysis
typically includes examples of the measurements that could be taken to
determine the status and effectiveness of the Activities Performed. Verifying
Implementation typically encompasses reviews and audits by management and
software quality assurance.
Level 2: Requirements Management
The purpose of Requirements Management is to establish a common
understanding between the customer and the software project of the customer's
requirements that will be addressed by the software project.
Requirements Management involves establishing and maintaining an agreement with
the customer on the requirements for the software project. This agreement is
referred to as the "system requirements allocated to the software." The
"customer" may be interpreted as the system engineering group, the marketing
group, another internal organization, or an external customer. The agreement
covers both the technical and nontechnical (e.g., delivery dates) requirements.
The agreement forms the basis for estimating, planning, performing, and
tracking the software project's activities throughout the software life
cycle.
The allocation of the system requirements to software, hardware, and other
system components (e.g., humans) may be performed by a group external to the
software engineering group (e.g., the system engineering group), and the
software engineering group may have no direct control of this allocation.
Within the constraints of the project, the software engineering group takes
appropriate steps to ensure that the system requirements allocated to software,
which they are responsible for addressing, are documented and controlled.
To achieve this control, the software engineering group reviews the initial and
revised system requirements allocated to software to resolve issues before they
are incorporated into the software project. Whenever the system requirements
allocated to software are changed, the affected software plans, work products,
and activities are adjusted to remain consistent with the updated
requirements.
The goals of Requirements Management are:
- System requirements allocated to software are controlled to establish
a baseline for software engineering and management use.
- Software plans, products, and activities are kept consistent with the system
requirements allocated to software.
The top-level activities performed for Requirements Management are:
- The software engineering group reviews the allocated requirements
before they are incorporated into the software project.
- The software engineering group uses the allocated requirements as the basis
for software plans, work products, and activities.
- Changes to the allocated requirements are reviewed and incorporated into
the software project.
Level 2: Software Project Planning
The purpose of Software Project Planning is to establish reasonable
plans for performing the software engineering and for managing the software
project.
Software Project Planning involves developing estimates for the work to be
performed, establishing the necessary commitments, and defining the plan to
perform the work.
The software planning begins with a statement of the work to be performed and
other constraints and goals that define and bound the software project (those
established by the practices of the Requirements Management key process area).
The software planning process includes steps to estimate the size of the
software work products and the resources needed, produce a schedule, identify
and assess software risks, and negotiate commitments. Iterating through these
steps may be necessary to establish the plan for the software project (i.e.,
the software development plan).
This plan provides the basis for performing and managing the software project's
activities and addresses the commitments to the software project's customer
according to the resources, constraints, and capabilities of the software
project.
The goals of Software Project Planning are:
- Software estimates are documented for use in planning and tracking
the software project.
- Software project activities and commitments are planned and documented.
- Affected groups and individuals agree to their commitments related to the
software project.
The top-level activities performed for Software Project Planning are:
- The software engineering group participates on the project proposal team.
- Software project planning is initiated in the early stages of, and in
parallel with, the overall project planning.
- The software engineering group participates with other affected groups in
the overall project planning throughout the project's life.
- Software project commitments made to individuals and groups external to the
organization are reviewed with senior management according to a documented
procedure.
- A software life cycle with predefined stages of manageable size is
identified or defined.
- The project's software development plan is developed according to a
documented procedure.
- The plan for the software project is documented.
- Software work products that are needed to establish and maintain control of
the software project are identified.
- Estimates for the size of the software work products (or changes to the size
of software work products) are derived according to a documented procedure.
- Estimates for the software project's effort and costs are derived according
to a documented procedure.
- Estimates for the project's critical computer resources are derived
according to a documented procedure.
- The project's software schedule is derived according to a documented
procedure.
- The software risks associated with the cost, resource, schedule, and
technical aspects of the project are identified, assessed, and documented.
- Plans for the project's software engineering facilities and support tools
are prepared.
- Software planning data are recorded.
Level 2: Software Project Tracking and Oversight
The purpose of Software Project Tracking and Oversight is to provide
adequate visibility into actual progress so that management can take effective
actions when the software project's performance deviates significantly from the
software plans.
Software Project Tracking and Oversight involves tracking and reviewing the
software accomplishments and results against documented estimates, commitments,
and plans, and adjusting these plans based on the actual accomplishments and
results.
A documented plan for the software project (i.e., the software development
plan, as described in the Software Project Planning key process area) is used
as the basis for tracking the software activities, communicating status, and
revising plans. Software activities are monitored by the management. Progress
is primarily determined by comparing the actual software size, effort, cost,
and schedule to the plan when selected software work products are completed and
at selected milestones. When it is determined that the software project's
plans are not being met, corrective actions are taken. These actions may
include revising the software development plan to reflect the actual
accomplishments and replanning the remaining work or taking actions to improve
the performance.
The goals of Software Project Tracking and Oversight are:
- Actual results and performances are tracked against the software
plans.
Corrective actions are taken and managed to closure when actual results and
performance deviate significantly from the software plans.
- Changes to software commitments are agreed to by the affected groups and
individuals.
The top-level activities performed for Software Project Tracking and
Oversight are:
- A documented software development plan is used for tracking the
software activities and communicating status.
- The project's software development plan is revised according to a
documented procedure.
- Software project commitments and changes to commitments made to individuals
and groups external to the organization are reviewed with senior management
according to a documented procedure.
- Approved changes to commitments that affect the software project are
communicated to the members of the software engineering group and other
software-related groups.
- The size of the software work products (or size of the changes to the
software work products) are tracked, and corrective actions are taken as
necessary.
- The project's software effort and costs are tracked, and corrective actions
are taken as necessary.
- The project's critical computer resources are tracked, and corrective
actions are taken as necessary.
- The project's software schedule is tracked, and corrective actions are taken
as necessary.
- Software engineering technical activities are tracked, and corrective
actions are taken as necessary.
- The software risks associated with cost, resource, schedule, and technical
aspects of the project are tracked.
- Actual measurement data and replanning data for the software project are
recorded.
- The software engineering group conducts periodic internal reviews to track
technical progress, plans, performance, and issues against the software
development plan.
- Formal reviews to address the accomplishments and results of the software
project are conducted at selected project milestones according to a documented
procedure.
Level 2: Software Subcontract Management
The purpose of Software Subcontract Management is to select qualified
software subcontractors and manage them effectively.
Software Subcontract Management involves selecting a software subcontractor,
establishing commitments with the subcontractor, and tracking and reviewing the
subcontractor's performance and results. These practices cover the management
of a software (only) subcontract, as well as the management of the software
component of a subcontract that includes software, hardware, and possibly other
system components.
The subcontractor is selected based on its ability to perform the work. Many
factors contribute to the decision to subcontract a portion of the prime
contractor's work. Subcontractors may be selected based on strategic business
alliances, as well as technical considerations. The practices of this key
process area address the traditional acquisition process associated with
subcontracting a defined portion of the work to another organization.
When subcontracting, a documented agreement covering the technical and
nontechnical (e.g., delivery dates) requirements is established and is used as
the basis for managing the subcontract. The work to be done by the
subcontractor and the plans for the work are documented. The standards that
are to be followed by the subcontractor are compatible with the prime
contractor's standards.
The software planning, tracking, and oversight activities for the subcontracted
work are performed by the subcontractor. The prime contractor ensures that
these planning, tracking, and oversight activities are performed appropriately
and that the software products delivered by the subcontractor satisfy their
acceptance criteria. The prime contractor works with the subcontractor to
manage their product and process interfaces.
The goals of Software Subcontract Management are:
- The prime contractor selects qualified software subcontractors.
- The prime contractor and the software subcontractor agree to their
commitments to each other.
- The prime contractor and the software subcontractor maintain ongoing
communications.
- The prime contractor tracks the software subcontractor's actual results and
performance against its commitments.
The top-level activities performed for Software Subcontract Management
are:
- The work to be subcontracted is defined and planned according to a
documented procedure.
- The software subcontractor is selected, based on an evaluation of the
subcontract bidders' ability to perform the work, according to a documented
procedure.
- The contractual agreement between the prime contractor and the software
subcontractor is used as the basis for managing the subcontract.
- A documented subcontractor's software development plan is reviewed and
approved by the prime contractor.
- A documented and approved subcontractor's software development plan is used
for tracking the software activities and communicating status.
- Changes to the software subcontractor's statement of work, subcontract terms
and conditions, and other commitments are resolved according to a documented
procedure.
- The prime contractor's management conducts periodic status/coordination
reviews with the software subcontractor's management.
- Periodic technical reviews and interchanges are held with the software
subcontractor.
- Formal reviews to address the subcontractor's software engineering
accomplishments and results are conducted at selected milestones according to a
documented procedure.
- The prime contractor's software quality assurance group monitors the
subcontractor's software quality assurance activities according to a documented
procedure.
- The prime contractor's software configuration management group monitors the
subcontractor's activities for software configuration management according to a
documented procedure.
- The prime contractor conducts acceptance testing as part of the delivery of
the subcontractor's software products according to a documented procedure.
- The software subcontractor's performance is evaluated on a periodic basis,
and the evaluation is reviewed with the subcontractor.
Level 2: Software Quality Assurance
The purpose of Software Quality Assurance is to provide management with
appropriate visibility into the process being used by the software project and
of the products being built.
Software Quality Assurance involves reviewing and auditing the software
products and activities to verify that they comply with the applicable
procedures and standards and providing the software project and other
appropriate managers with the results of these reviews and audits.
The software quality assurance group works with the software project during its
early stages to establish plans, standards, and procedures that will add value
to the software project and satisfy the constraints of the project and the
organization's policies. By participating in establishing the plans,
standards, and procedures, the software quality assurance group helps ensure
they fit the project's needs and verifies that they will be usable for
performing reviews and audits throughout the software life cycle. The software
quality assurance group reviews project activities and audits software work
products throughout the life cycle and provides management with visibility as
to whether the software project is adhering to its established plans,
standards, and procedures.
Compliance issues are first addressed within the software project and resolved
there if possible. For issues not resolvable within the software project, the
software quality assurance group escalates the issue to an appropriate level of
management for resolution.
This key process area covers the practices for the group performing the
software quality assurance function. The practices identifying the specific
activities and work products that the software quality assurance group reviews
and/or audits are generally contained in the Verifying Implementation common
feature of the other key process areas.
The goals of Software Quality Assurance are:
- Software quality assurance activities are planned.
- Adherence of software products and activities to the applicable standards,
procedures, and requirements is verified objectively.
- Affected groups and individuals are informed of software quality assurance
activities and results.
- Noncompliance issues that cannot be resolved within the software project are
addressed by senior management.
The top-level activities performed for Software Quality Assurance are:
- A SQA plan is prepared for the software project according to a
documented procedure.
- The SQA group's activities are performed in accordance with the SQA plan.
- The SQA group participates in the preparation and review of the project's
software development plan, standards, and procedures.
- The SQA group reviews the software engineering activities to verify
compliance.
- The SQA group audits designated software work products to verify
compliance.
- The SQA group periodically reports the results of its activities to the
software engineering group.
- Deviations identified in the software activities and software work products
are documented and handled according to a documented procedure.
- The SQA group conducts periodic reviews of its activities and findings with
the customer's SQA personnel, as appropriate.
Level 2: Software Configuration Management
The purpose of Software Configuration Management is to establish and
maintain the integrity of the products of the software project throughout the
project's software life cycle.
Software Configuration Management involves identifying the configuration of the
software (i.e., selected software work products and their descriptions) at
given points in time, systematically controlling changes to the configuration,
and maintaining the integrity and traceability of the configuration throughout
the software life cycle. The work products placed under software configuration
management include the software products that are delivered to the customer
(e.g., the software requirements document and the code) and the items that are
identified with or required to create these software products (e.g., the
compiler).
A software baseline library is established containing the software baselines as
they are developed. Changes to baselines and the release of software products
built from the software baseline library are systematically controlled via the
change control and configuration auditing functions of software configuration
management.
This key process area covers the practices for performing the software
configuration management function. The practices identifying specific
configuration items/units are contained in the key process areas that describe
the development and maintenance of each configuration item/unit.
The goals of Software Configuration Management are:
- Software configuration management activities are planned.
- Selected software work products are identified, controlled, and available.
- Changes to identified software work products are controlled.
- Affected groups and individuals are informed of the status and content of
software baselines.
The top-level activities performed for Software Configuration Management
are:
- A SCM plan is prepared for each software project according to
a documented procedure.
- A documented and approved SCM plan is used as the basis for performing the
SCM activities.
- A configuration management library system is established as a repository for
the software baselines.
- The software work products to be placed under configuration management are
identified.
- Change requests and problem reports for all configuration items/units are
initiated, recorded, reviewed, approved, and tracked according to a documented
procedure.
- Changes to baselines are controlled according to a documented procedure.
- Products from the software baseline library are created and their release is
controlled according to a documented procedure.
- The status of configuration items/units is recorded according to a
documented procedure.
- Standard reports documenting the SCM activities and the contents of the
software baseline are developed and made available to affected groups and
individuals.
- Software baseline audits are conducted according to a documented procedure.
Level 3: Organization Process Focus
The purpose of Organization Process Focus is to establish the
organizational responsibility for software process activities that improve the
organization's overall software process capability.
Organization Process Focus involves developing and maintaining an understanding
of the organization's and projects' software processes and coordinating the
activities to assess, develop, maintain, and improve these processes.
The organization provides the long-term commitments and resources to coordinate
the development and maintenance of the software processes across current and
future software projects via a group such as a software engineering process
group. This group is responsible for the organization's software process
activities. It is specifically responsible for the development and maintenance
of the organization's standard software process and related process assets (as
described in the Organization Process Definition key process area), and it
coordinates the process activities with the software projects.
The goals of Organization Process Focus are:
- Software process development and improvement activities are
coordinated across the organization.
- The strengths and weaknesses of the software processes used are identified
relative to a process standard.
- Organization-level process development and improvement activities are
planned.
The top-level activities performed for Organization Process Focus are:
- The software process is assessed periodically, and action plans are
developed to address the assessment findings.
- The organization develops and maintains a plan for its software process
development and improvement activities.
- The organization's and projects' activities for developing and improving
their software processes are coordinated at the organization level.
- The use of the organization's software process database is coordinated at
the organizational level.
- New processes, methods, and tools in limited use in the organization are
monitored, evaluated, and, where appropriate, transferred to other parts of the
organization.
- Training for the organization's and projects' software processes is
coordinated across the organization.
- The groups involved in implementing the software processes are informed of
the organization's and projects' activities for software process development
and improvement.
Level 3: Organization Process Definition
The purpose of Organization Process Definition is to develop and
maintain a usable set of software process assets that improve process
performance across the projects and provide a basis for cumulative, long-term
benefits to the organization.
Organization Process Definition involves developing and maintaining the
organization's standard software process, along with related process assets,
such as descriptions of software life cycles, process tailoring guidelines and
criteria, the organization's software process database, and a library of
software process-related documentation.
These assets may be collected in many ways, depending on the organization's
implementation of Organization Process Definition. For example, the
descriptions of the software life cycles may be an integral part of the
organization's standard software process or parts of the library of software
process-related documentation may be stored in the organization's software
process database.
The organization's software process assets are available for use in developing,
implementing, and maintaining the projects' defined software processes. (The
practices related to the development and maintenance of the project's defined
software process are described in the Integrated Software Management key
process area.)
The goals of Organization Process Definition are:
- A standard software process for the organization is developed
and maintained.
- Information related to the use of the organization's standard software
process by the software projects is collected, reviewed, and made available.
The top-level activities performed for Organization Process Definition
are:
- The organization's standard software process is developed and
maintained according to a documented procedure.
- The organization's standard software process is documented according to
established organization standards.
- Descriptions of software life cycles that are approved for use by the
projects are documented and maintained.
- Guidelines and criteria for the projects' tailoring of the organization's
standard software process are developed and maintained.
- The organization's software process database is established and
maintained.
- A library of software process-related documentation is established and
maintained.
Level 3: Training Program
The purpose of the Training Program key process area is to develop the
skills and knowledge of individuals so they can perform their roles effectively
and efficiently.
Training Program involves first identifying the training needed by the
organization, projects, and individuals, then developing or procuring training
to address the identified needs.
Each software project evaluates its current and future skill needs and
determines how these skills will be obtained. Some skills are effectively and
efficiently imparted through informal vehicles (e.g., on-the-job training and
informal mentoring), whereas other skills need more formal training vehicles
(e.g., classroom training and guided self-study) to be effectively and
efficiently imparted. The appropriate vehicles are selected and used.
This key process area covers the practices for the group performing the
training function. The practices identifying the specific training topics
(i.e., knowledge or skill needed) are contained in the Ability to Perform
common feature of the individual key process areas.
The goals of Training Program are:
- Training activities are planned.
- Training for developing the skills and knowledge needed to perform software
management and technical roles is provided.
- Individuals in the software engineering group and software-related groups
receive the training necessary to perform their roles.
The top-level activities performed for Training Program are:
- Each software project develops and maintains a training plan that
specifies its training needs.
- The organization's training plan is developed and revised according to a
documented procedure.
- The training for the organization is performed in accordance with the
organization's training plan.
- Training courses prepared at the organization level are developed and
maintained according to organization standards.
- A waiver procedure for required training is established and used to
determine whether individuals already possess the knowledge and skills required
to perform in their designated roles.
- Records of training are maintained.
Level 3: Integrated Software Management
The purpose of Integrated Software Management is to integrate the
software engineering and management activities into a coherent, defined
software process that is tailored from the organization's standard software
process and related process assets, which are described in Organization Process
Definition.
Integrated Software Management involves developing the project's defined
software process and managing the software project using this defined software
process. The project's defined software process is tailored from the
organization's standard software process to address the specific
characteristics of the project.
The software development plan is based on the project's defined software
process and describes how the activities of the project's defined software
process will be implemented and managed. The management of the software
project's size, effort, cost, schedule, staffing, and other resources is tied
to the tasks of the project's defined software process.
Since the projects' defined software processes are all tailored from the
organization's standard software process, the software projects can share
process data and lessons learned.
The basic practices for estimating, planning, and tracking a software project
are described in the Software Project Planning and Software Project Tracking
and Oversight key process areas. They focus on recognizing problems when they
occur and adjusting the plans and/or performance to address the problems. The
practices of this key process area build on, and are in addition to, the
practices of those two key process areas. The emphasis of Integrated Software
Management shifts to anticipating problems and acting to prevent or minimize
the effects of these problems.
The goals of Integrated Software Management are:
- The project's defined software process is a tailored version of the
organization's standard software process.
- The project is planned and managed according to the project's defined
software process.
The top-level activities performed for Integrated Software Management
are:
- The project's defined software process is developed by tailoring the
organization's standard software process according to a documented procedure.
- Each project's defined software process is revised according to a documented
procedure.
- The project's software development plan, which describes the use of the
project's defined software process, is developed and revised according to a
documented procedure.
- The software project is managed in accordance with the project's defined
software process.
- The organization's software process database is used for software planning
and estimating.
- The size of the software work products (or size of changes to the software
work products) is managed according to a documented procedure.
- The project's software effort and costs are managed according to a
documented procedure.
- The project's critical computer resources are managed according to a
documented procedure.
- The critical dependencies and critical paths of the project's software
schedule are managed according to a documented procedure.
- The project's software risks are identified, assessed, documented, and
managed according to a documented procedure.
- Reviews of the software project are periodically performed to determine the
actions needed to bring the software project's performance and results in line
with the current and projected needs of the business, customer, and end users,
as appropriate.
Level 3: Software Product Engineering
The purpose of Software Product Engineering is to consistently perform a
well-defined engineering process that integrates all the software engineering
activities to produce correct, consistent software products effectively and
efficiently.
Software Product Engineering involves performing the engineering tasks to build
and maintain the software using the project's defined software process (which
is described in the Integrated Software Management key process area) and
appropriate methods and tools.
The software engineering tasks include analyzing the system requirements
allocated to software (these system requirements are described in the
Requirements Management key process area), developing the software
requirements, developing the software architecture, designing the software,
implementing the software in the code, integrating the software components, and
testing the software to verify that it satisfies the specified requirements
(i.e., the system requirements allocated to software and the software
requirements).
Documentation needed to perform the software engineering tasks (e.g., software
requirements document, software design document, test plan, and test
procedures) is developed and reviewed to ensure that each task addresses the
results of predecessor tasks and the results produced are appropriate for the
subsequent tasks (including the tasks of operating and maintaining the
software). When changes are approved, affected software work products, plans,
commitments, processes, and activities are revised to reflect the approved
changes.
The goals of Software Product Engineering are:
- The software engineering tasks are defined, integrated, and
consistently performed to produce the software.
- Software work products are kept consistent with each other.
The top-level activities performed for Software Product Engineering
are:
- Appropriate software engineering methods and tools are integrated
into the project's defined software process.
- The software requirements are developed, maintained, documented, and
verified by systematically analyzing the allocated requirements according to
the project's defined software process.
- The software design is developed, maintained, documented, and verified,
according to the project's defined software process, to accommodate the
software requirements and to form the framework for coding.
- The software code is developed, maintained, documented, and verified,
according to the project's defined software process, to implement the software
requirements and software design.
- Software testing is performed according to the project's defined software
process.
- System and acceptance testing of the software are planned and performed to
demonstrate that the software satisfies its requirements.
- The documentation that will be used to operate and maintain the software is
developed and maintained according to the project's defined software process.
- Data on defects identified in peer reviews and testing are collected and
analyzed according to the project's defined software process.
- Consistency is maintained across software work products, including the
software plans, process descriptions, allocated requirements, software
requirements, software design, code, test plans, and test procedures.
Level 3: Intergroup Coordination
The purpose of Intergroup Coordination is to establish a means for the
software engineering group to participate actively with the other engineering
groups so the project is better able to satisfy the customer's needs
effectively and efficiently.
Intergroup Coordination involves the software engineering group's participation
with other project engineering groups to address system-level requirements,
objectives, and issues. Representatives of the project's engineering groups
participate in establishing the system-level requirements, objectives, and
plans by working with the customer and end users, as appropriate. These
requirements, objectives, and plans become the basis for all engineering
activities.
The technical working interfaces and interactions between groups are planned
and managed to ensure the quality and integrity of the entire system.
Technical reviews and interchanges are regularly conducted with representatives
of the project's engineering groups to ensure that all engineering groups are
aware of the status and plans of all the groups, and that system and intergroup
issues receive appropriate attention.
The software-specific practices related to these engineering tasks are
described in the Requirements Management and Software Product Engineering key
process areas.
The goals of Intergroup Coordination are:
- The customer's requirements are agreed to by all affected groups.
- The commitments between the engineering groups are agreed to by the
affected groups.
- The engineering groups identify, track, and resolve intergroup
issues.
The top-level activities performed for Intergroup Coordination are:
- The software engineering group and the other engineering groups
participate with the customer and end users, as appropriate, to establish the
system requirements.
- Representatives of the project's software engineering group work with
representatives of the other engineering groups to monitor and coordinate
technical activities and resolve technical issues.
- A documented plan is used to communicate intergroup commitments and to
coordinate and track the work performed.
- Critical dependencies between engineering groups are identified, negotiated,
and tracked according to a documented procedure.
- Work products produced as input to other engineering groups are reviewed by
representatives of the receiving groups to ensure that the work products meet
their needs.
- Intergroup issues not resolvable by the individual representatives of the
project engineering groups are handled according to a documented procedure.
- Representatives of the project engineering groups conduct periodic technical
reviews and interchanges.
Level 3: Peer Reviews
The purpose of Peer Reviews is to remove defects from the software work
products early and efficiently. An important corollary effect is to develop a
better understanding of the software work products and of defects that might be
prevented.
Peer Reviews involve a methodical examination of software work products by the
producers' peers to identify defects and areas where changes are needed. The
specific products that will undergo a peer review are identified in the
project's defined software process and scheduled as part of the software
project planning activities, as described in Integrated Software Management.
This key process area covers the practices for performing peer reviews. The
practices identifying the specific software work products that undergo peer
review are contained in the key process areas that describe the development and
maintenance of each software work product.
The goals of Peer Reviews are:
- Peer review activities are planned.
- Defects in the software work products are identified and removed.
The top-level activities performed for Peer Reviews are:
- Peer reviews are planned, and the plans are documented.
- Peer reviews are performed according to a documented procedure.
- Data on the conduct and results of the peer reviews are recorded.
Level 4: Quantitative Process Management
The purpose of Quantitative Process Management is to control the process
performance of the software project quantitatively. Software process
performance represents the actual results achieved from following a software
process.
Quantitative Process Management involves establishing goals for the performance
of the project's defined software process, which is described in the Integrated
Software Management key process area, taking measurements of the process
performance, analyzing these measurements, and making adjustments to maintain
process performance within acceptable limits. When the process performance is
stabilized within acceptable limits, the project's defined software process,
the associated measurements, and the acceptable limits for the measurements are
established as a baseline and used to control process performance
quantitatively.
The organization collects process performance data from the software projects
and uses these data to characterize the process capability (i.e., the process
performance a new project can expect to attain) of the organization's standard
software process, which is described in the Organization Process Definition key
process area. Process capability describes the range of expected results from
following a software process (i.e., the most likely outcomes that are expected
from the next software project the organization undertakes). These process
capability data are, in turn, used by the software projects to establish and
revise their process performance goals and to analyze the performance of the
projects' defined software processes.
The goals of Quantitative Process Management are:
- The quantitative process management activities are planned.
- The process performance of the project's defined software process is
controlled quantitatively.
- The process capability of the organization's standard software process is
known in quantitative terms.
The top-level activities performed for Quantitative Process Management
are:
- The software project's plan for quantitative process management is
developed according to a documented procedure.
- The software project's quantitative process management activities are
performed in accordance with the project's quantitative process management
plan.
- The strategy for the data collection and the quantitative analyses to be
performed are determined based on the project's defined software process.
- The measurement data used to control the project's defined software process
quantitatively are collected according to a documented procedure.
- The project's defined software process is analyzed and brought under
quantitative control according to a documented procedure.
- Reports documenting the results of the software project's quantitative
process management activities are prepared and distributed.
- The process capability baseline for the organization's standard software
process is established and maintained according to a documented procedure.
Level 4: Software Quality Management
The purpose of Software Quality Management is to develop a quantitative
understanding of the quality of the project's software products and achieve
specific quality goals.
Software Quality Management involves defining quality goals for the software
products, establishing plans to achieve these goals, and monitoring and
adjusting the software plans, software work products, activities, and quality
goals to satisfy the needs and desires of the customer and end user for high
quality products.
The practices of Software Quality Management build on the practices of the
Integrated Software Management and Software Product Engineering key process
areas, which establish and implement the project's defined software process,
and the Quantitative Process Management key process area, which establishes a
quantitative understanding of the ability of the project's defined software
process to achieve the desired results.
Quantitative goals are established for the software products based on the needs
of the organization, the customer, and the end users. So that these goals may
be achieved, the organization establishes strategies and plans, and the project
specifically adjusts its defined software process, to accomplish the quality
goals.
The goals of Software Quality Management are:
- The project's software quality management activities are planned.
- Measurable goals for software product quality and their priorities are
defined.
- Actual progress toward achieving the quality goals for the software products
is quantified and managed.
The top-level activities performed for Software Quality Management
are:
- The project's software quality plan is developed and maintained
according to a documented procedure.
- The project's software quality plan is the basis for the project's
activities for software quality management.
- The project's quantitative quality goals for the software products are
defined, monitored, and revised throughout the software life cycle.
- The quality of the project's software products is measured, analyzed, and
compared to the products' quantitative quality goals on an event-driven
basis.
- The software project's quantitative quality goals for the products are
allocated appropriately to the subcontractors delivering software products to
the project.
Level 5: Defect Prevention
The purpose of Defect Prevention is to identify the cause of defects and
prevent them from recurring.
Defect Prevention involves analyzing defects that were encountered in the past
and taking specific actions to prevent the occurrence of those types of defects
in the future. The defects may have been identified on other projects as well
as in earlier stages or tasks of the current project. Defect prevention
activities are also one mechanism for spreading lessons learned between
projects.
Trends are analyzed to track the types of defects that have been encountered
and to identify defects that are likely to recur. Based on an understanding of
the project's defined software process and how it is implemented (as described
in the Integrated Software Management and Software Product Engineering key
process areas), the root causes of the defects and the implications of the
defects for future activities are determined.
Both the project and the organization take specific actions to prevent
recurrence of the defects. Some of the organizational actions may be handled
as described in the Process Change Management key process area.
The goals of Defect Prevention are:
- Defect prevention activities are planned.
- Common causes of defects are sought out and identified.
- Common causes of defects are prioritized and systematically eliminated.
The top-level activities performed for Defect Prevention are:
- The software project develops and maintains a plan for its defect
prevention activities.
- At the beginning of a software task, the members of the team performing the
task meet to prepare for the activities of that task and the related defect
prevention activities.
- Causal analysis meetings are conducted according to a documented procedure.
- Each of the teams assigned to coordinate defect prevention activities meets
on a periodic basis to review and coordinate implementation of action proposals
from the causal analysis meetings.
- Defect prevention data are documented and tracked across the teams
coordinating defect prevention activities.
- Revisions to the organization's standard software process resulting from
defect prevention actions are incorporated according to a documented
procedure.
- Revisions to the project's defined software process resulting from defect
prevention actions are incorporated according to a documented procedure.
- Members of the software engineering group and software-related groups
receive feedback on the status and results of the organization's and project's
defect prevention activities on a periodic basis.
Level 5: Technology Change Management
The purpose of Technology Change Management is to identify new
technologies (i.e., tools, methods, and processes) and track them into the
organization in an orderly manner.
Technology Change Management involves identifying, selecting, and evaluating
new technologies, and incorporating effective technologies into the
organization. The objective is to improve software quality, increase
productivity, and decrease the cycle time for product development.
The organization establishes a group (such as a software engineering process
group or a technology support group) that works with the software projects to
introduce and evaluate new technologies and manage changes to existing
technologies. Particular emphasis is placed on technology changes that are
likely to improve the capability of the organization's standard software
process (as described in the Organization Process Definition key process
area).
By maintaining an awareness of software-related technology innovations and
systematically evaluating and experimenting with them, the organization selects
appropriate technologies to improve the quality of its software and the
productivity of its software activities. Pilot efforts are performed to assess
new and unproven technologies before they are incorporated into normal
practice. With appropriate sponsorship of the organization's management, the
selected technologies are incorporated into the organization's standard
software process and current projects, as appropriate.
Changes to the organization's standard software process (as described in the
Organization Process Definition key process area) and the projects' defined
software processes (as described in the Integrated Software Management key
process area) resulting from these technology changes are handled as described
in the Process Change Management key process area.
The goals of Technology Change Management are:
- Incorporation of technology changes are planned.
- New technologies are evaluated to determine their effect on quality and
productivity.
- Appropriate new technologies are transferred into normal practice across the
organization.
The top-level activities for Technology Change Management are:
- The organization develops and maintains a plan for technology change
management.
- The group responsible for the organization's technology change management
activities works with the software projects in identifying areas of technology
change.
- Software managers and technical staff are kept informed of new technologies.
- The group responsible for the organization's technology change management
systematically analyzes the organization's standard software process to
identify areas that need or could benefit from new technology.
- Technologies are selected and acquired for the organization and software
projects according to a documented procedure.
- Pilot efforts for improving technology are conducted, where appropriate,
before a new technology is introduced into normal practice.
- Appropriate new technologies are incorporated into the organization's
standard software process according to a documented procedure.
- Appropriate new technologies are incorporated into the projects' defined
software processes according to a documented procedure.
Level 5: Process Change Management
The purpose of Process Change Management is to continually improve the
software processes used in the organization with the intent of improving
software quality, increasing productivity, and decreasing the cycle time for
product development.
Process Change Management involves defining process improvement goals and, with
senior management sponsorship, proactively and systematically identifying,
evaluating, and implementing improvements to the organization's standard
software process and the projects' defined software processes on a continuous
basis.
Training and incentive programs are established to enable and encourage
everyone in the organization to participate in process improvement activities.
Improvement opportunities are identified and evaluated for potential payback to
the organization. Pilot efforts are performed to assess process changes before
they are incorporated into normal practice.
When software process improvements are approved for normal practice, the
organization's standard software process and the projects' defined software
processes are revised as appropriate. The practices for revising the
organization's standard software process are found in the Organization Process
Definition key process area, and the practices for revising the projects'
defined software processes are found in the Integrated Software Management key
process area.
The goals of Process Change Management are:
- Continuous process improvement is planned.
- Participation in the organization's software process improvement activities
is organization wide.
- The organization's standard software process and the projects' defined
software processes are improved continuously.
The top-level activities performed for Process Change Management are:
- A software process improvement program is established which empowers
the members of the organization to improve the processes of the organization.
- The group responsible for the organization's software process activities
(e.g., software engineering process group) coordinates the software process
improvement activities.
- The organization develops and maintains a plan for software process
improvement according to a documented procedure.
- The software process improvement activities are performed in accordance with
the software process improvement plan.
- Software process improvement proposals are handled according to a documented
procedure.
- Members of the organization actively participate in teams to develop
software process improvements for assigned process areas.
- Where appropriate, the software process improvements are installed on a
pilot basis to determine their benefits and effectiveness before they are
introduced into normal practice.
- When the decision is made to transfer a software process improvement into
normal practice, the improvement is implemented according to a documented
procedure.
- Records of software process improvement activities are maintained.
- Software managers and technical staff receive feedback on the status and
results of the software process improvement activities on an event-driven
basis.
Table of contents
Appendix B
Appendix D