|
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. fb6 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 requirement 196
s 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 Proje fc2 ct 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,
e 190 ffort, 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 fc0 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
197 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 a fba nd 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 revi 197 ews 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 an fc8 d 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 196 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 organ fc1
izational 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 softwa
196 re 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 fc4 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 190 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 Integrat fc7 ed 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 softw 192 are 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 def fc3 ined 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 softwa 191 re
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 id fc7
entified 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 ac 196 cording 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 goal fc7 s, 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 192 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 a fc1 ctions 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 soft
191 ware 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
standa fd4 rd 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 >>>
|
|