Transcript Software Metrics - University of Central Florida

Software
Process Improvement:
SEI Capability Maturity Model
COP 4331 and EEL4884
Processes for OO Software Development
© Dr. David A. Workman
School of EECS
University of Central Florida
April 20, 2010
Introduction
•
Reference: The Capability Maturity Model: Guidelines for Improving the
Software Process, by Carnegie Mellon University, SEI, Addison-Wesley, 1994,
ISBN=0-201-54664-7
•
•
Reference: The Capability Maturity Model for Software, by Paulk et al,
Text[pp48-59]
History
– Originally the vision of Watts Humphrey and produced by a team of SEI
researchers including:
Mark Paulk
Bill Curtis
Mary Beth Chrissis
Ed Averill
Judy Bamberger
Tim Kasse
Mike Konrad
Jeff Perdue
Charlie Weber
Cindi Wise
Jim Withey
– Version 1.0 was released in August 1991
April 20, 2010
Motivation
•
•
•
•
•
“Software Crisis”
“No Silver Bullet” (technology is only part of the solution)
Demand for more and more complex software systems have outstripped
our ability to cope with changes required to meet these demands.
Organizations began to realize the fundamental problem is the inability to
manage the software process!
Examples
– A review of 17 major DOD contracts found that the average 28-month
schedule was missed by 20 months!
– Deployment of the B1 bomber was delayed by software problems and the
$58 billion A12 aircraft program was canceled partly for the same
reason.
– GAO concluded a study of more than 20 large software projects with this
statement, “The understanding of software as a product and of software
development as a process is not keeping pace with the growing
complexity and software dependence of existing and emerging missioncritical systems.”
April 20, 2010
Evolution
• Humphrey’s Book, “Managing the Software Process”
Addison-Wesley, 1989.
“Characterizing the Software Process: A Maturity Framework,”
IEEE Software, March 1988.
– Method: Software Process Assessment
An appraisal by a team of trained software professionals to determine the state
of an organization’s current software process, to determine the most
important process-related issues, and to obtain organizational support for
improvement.
– Method: Software Capability Evaluation
An appraisal by a team of trained software professionals to identify
contractors qualified to perform the software work or to monitor the state of
the software process used on an existing software effort.
– Maturity Questionaire
• SEI Development and Release 1991-92
• SEI Influenced the ISO 9000 Standard series, specifically 9001.
April 20, 2010
Fundamental Concepts
The CMM focuses on the capability of software organizations to
produce high-quality products consistently and predictably. Software
process capability is the inherent ability of a software process to
produce planned results.
• DEFINITION (Process) A sequence of steps performed for a given
purpose. The process integrates people, tools, and procedures.
• DEFINTION (Software Process) A set of activities, methods,
practices, and transformations that people employ to develop and
maintain software and the associated products (documents, etc.)
• DEFINTION (Software Process Capability)decribes the range of
expected results that can be achieved by following a software
process.
April 20, 2010
Fundamental Concepts
The CMM focuses on the capability of software organizations to produce
high-quality products consistently and predictably. Software process
capability is the inherent ability of a software process to produce planned
results.
•
DEFINITION (Software Process Performance) the actual results achieved
by following a software process.
•
DEFINTION (Software Process Maturity) the extent to which a specific
process is explicitly defined, managed, measured, controlled, and effective.
•
As a software organization matures, it needs an infrastructure and culture
to support its methods, practices, and procedures so that they endure
after those who originally defined them have gone.
DEFINTION (Institutionalization) is the building of infrastructure and
culture to support methods, practices, and procedures so that they are the
ongoing way of doing business.
April 20, 2010
Software Process Maturity Framework
Five Maturity Levels:
• Initial: The software process is characterized by ad hoc, and occasionally
even chaotic. Few processes are defined, and success depends on individual
effort and heroics.
•
Repeatable: Basic project management processes are established to track
cost, schedule, and functionality. The necessary process discipline is in
place to repeat earlier successes on projects with similar applications.
•
Defined: The software process for both management and engineering
activities is documented, standardized, and integrated into a standard
software process for the organization. All projects use an approved, tailored
version of the organization’s standard software process for developing and
maintaining software.
April 20, 2010
Software Process Maturity Framework
Five Maturity Levels (continued):
• Managed: Detailed measures of the software process and product quality
are collected. Both the software process and products are quantitatively
understood and controlled.
•
Optimizing: Continuous process improvement is enabled by quantitative
feedback from the process and from piloting innovative ideas and
technologies.
April 20, 2010
The CMM Level Structure
Maturity
Levels
Indicate
Process
Capability
Contains
Achieves
Key
Process
Areas
Organized by
Common
Features
Goals
Address
Implementation/
Institutionalization
Contain
Key
Practices
Describe
Activities or
Infrastructure
April 20, 2010
Key Process Areas
• Definition
Except for level 1, each maturity level is decomposed into several key
process areas that indicate where an organization should focus to
improve its software process. KPAs identify the issues that must be
addressed to achieve a desired maturity level. If an organization is at
level K+1 then it has addressed all of the KPAs at levels  K.
Each KPA identifies a cluster of activities that, when performed
collectively, achieve a set of goals considered important for enhancing
process capability.
The KPAs may be considered to be the requirements for achieving a
particular maturity level.
See Notes!
April 20, 2010
KPAs – Level 2
•
Focus: project concerns related to establishing basic project
management controls.
1. Requirements Management
(establish customer & user repoire, involve customer & users in the
process)
2. Software Project Planning: (establish project management and
engineering procedures)
3. Software Project Tracking and Oversight (make visible to the
organization)
4. Software Subcontract Management (qualified subcontractors)(avoid
disconnect in management and engineering maturity and capability)
5. Software Quality Assurance (make SQA visible to management)
6. Software Configuration Management (control access and change to
engineering work products and project deliverables)
April 20, 2010
KPAs – Level 3
•
Focus: project and organizational issues leading toward the
infrastructure that institutionalizes effective software engineering
across all projects.
1. Organization Process focus: coordinate and integrate process across
all projects.
2. Organization Process definition: develop a reusable set of process assets
(documents, training materials) defining the organization’s standard
software process (includes a tool set)
3. Training program: train personnel in the various process procedures
and roles
4. Integrated Software Management:
5. Software Product engineering:
6. Inter-group coordination:
7. Peer Reviews:
April 20, 2010
KPAs – Level 4
•
Focus: establishing a quantitative understanding of both the
software process and the software products being built (process
and product metrics and measures).
1. Quantitative Process Management: develop the quantitative measures
necessary to control process performance of software projects.
2. Software Quality Management: develop quantitative measures
necessary to control the quality of software products.
–
–
April 20, 2010
Software Quality Metrics
Metrics Validation Process (IEEE Standard 1061)
KPAs – Level 5
•
Focus: addressing issues concerning organization and projects
relating to continuous and measurable software process
improvement.
1. Defect Prevention: detect causes of defects and prevent them from
recurring.
2. Technology Change Management: identify beneficial new technologies
(tools, methods, and processes) and transfer them into the organization
in an orderly manner.
3. Process Change Management: continually improve software processes
in the organization with the intent of improving software quality,
increasing productivity, and decreasing the cycle time for product
development.
April 20, 2010
Common Features
•
Definition
Attributes that indicate whether the implementation and institutionalization
of a KPA is effective, repeatable, and lasting. There are 5:
1. Commitment to perform:
actions the organization must take to ensure that the process is established
and will endure; establish organizational policies and leadership.
2. Ability to perform:
defines the preconditions that must exist in the project or organization to
implement the software process competently; resources, organizational
entities, and training.
3. Activities to perform:
activities, roles, and procedures necessary to implement KPAs; create plans
and procedures, tracking progress, taking corrective action when not
done.
4. Measurement and analysis:
determine process status.
5. Verifying implementation:
steps to ensure compliance with process.
April 20, 2010
Level 2: Requirements Engineering Practices
Goals:
–
–
–
–
Requirements Management establishes common understanding (agreement)
between customer and vendor of the customer's requirements addressed by the
project.
It involves allocating system requirements to software modules or components.
The "agreement" covers technical and non-technical requirements (e.g. delivery
dates) and forms the basis for estimating, planning, performing and tracking
project activities.
To achieve control, the team reviews initial and revised system requirements
allocated to software to resolve issues before they are incorporated in
development. Whenever requirements change, the affected plans, work
products, and activities are adjusted to remain consistent with the updated
requirements.
1. System requirements allocated to software are controlled to establish a
baseline for software engineering and management use.
2. Software Plans, products, and activities are kept consistent with the
system requirements allocated to software.
April 20, 2010
CMM
Key Practices by Level
Dr. David Workman
School of EE and CS
January 17, 2006
Level 2: Requirements Engineering Practices
Requirments Engineering Practices:
1. The team reviews allocated requirements before they are incorporated into
development.
2. The team uses allocated requirements as the basis for software plans, work
products, and activities.
3. Changes to allocated requirements are reviewed and incorporated into the
software project.
April 20, 2010
Level 2: Software Planning Practices
Goals:
1. Software estimates (size, resources, schedule, risks, commitments) are
documented for use in planning and tracking development.
2. Project activities and commitments are planned and documented.
3. Affected stakeholders agree to their commitments related to the project.
April 20, 2010
Level 2: Software Planning Practices
Software Project Planning Practices:
1. The development team participates on the project proposal.
2. The software project planning is initiated in the early stages of, and in
parallel with, the overall project planning.
3. The software team participates with the other stakeholder planning
groups throughout the project's life.
4. Project commitments made to individuals and groups external to the
organization are reviewed with senior management according to a
documented procedure.
5. Software development stages of manageable size are identified or
defined.
6. The software development plan is developed according to a documented
procedure.
7. The software development plan is documented.
April 20, 2010
Level 2: Software Planning Practices
Software Project Planning Practices:
8. The software work products that are needed to establish and maintain
control of the project are identified.
9. Estimates for the size of software work products (or changes to their
sizes) are derived according to a documented procedure.
10. Estimates for the project's critical computing resources are derived
according to a documented procedure.
11. The project's schedule is derived according to a documented procedure.
12. The software risks associated with cost, resources, schedule, and
technical aspects of the project are identified, assessed, and
documented.
13. Plans for the project's software engineering facilities and support tools
are prepared.
14. Software planning data are recorded.
April 20, 2010
Level 2: Project Tracking & Control Practices
Goals:
1. Actual results and performance are tracked against the software development
plan; accomplishments and results (size, effort, schedule, cost) are compared
with documented estimates.
2. Corrective actions are taken and managed to closure when actual results and
performance deviate significantly from the software plans.
3. Changes to software commitments are agreed to by the affected stakeholders.
April 20, 2010
Level 2: Project Tracking & Control Practices
Project Tracking & Control Practices:
1. A documented software plan is used for tracking the software activities
and communicating status.
2. The project's development plan is revised according to a documented
procedure.
3. Software project commitments and their changes made by external
stakeholders are reviewed by senior management according to a
documented procedure.
4. Approved changes to commitments that affect the software project are
communicated to the members of the development group and other
software-related groups (e.g. tools, training, contracts, 3rd party
vendors)
5. The size of software work products (or the size of changes to) are
tracked, and corrective actions are taken as necessary.
6. The project's software effort and costs are tracked, and corrective
actions are taken as necessary.
7. The project's critical resources (e.g. funds spent) are tracked, and
corrective actions are taken as necessary.
April 20, 2010
Level 2: Project Tracking & Control Practices
Project Tracking & Control Practices:
8. The project's software schedule is tracked, and corrective actions are taken
as necessary.
9. Software engineering technical activities are tracked, and corrective
actions are taken as necessary.
10. The software risks associated with cost, resources, schedule, and
technical aspects of the project are tracked.
11. Actual measurement data and replanning data for the software project
are recorded.
12. The software development team conducts periodic internal reviews to
track technical progress, plans, performance, and issues against the
software development plan.
13. Formal reviews to address the accomplishments and results of the
software project are conducted at selected project milestones according
to a documented procedure.
April 20, 2010
Level 2: Subcontract Management Practices
Goals:
1.
2.
3.
4.
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 on-going communciation
with each other.
The prime contractor tracks the software subcontractor's actual results and performance
against its commitments.
The purpose of SSM is to select qualified software subcontractors and manage them
effectively.
SSM involves selecting a software subcontractor, establishing commitments with the
subcontractor, and tracking and reviewing subcontractor’s performance and
results.
A documented agreement covering the technical and nontechnical 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’s standards.
The software planning, tracking, and control activities for the subcontracted work are
preformed by the subcontractor. The prime ensures that these planning, tracking
and control activities are performed appropriately and that the software products
delivered by the subcontractor satisfy their acceptance criteria.
April 20, 2010
Level 2: Subcontract Management Practices
Subcontract Management Practices:
1. The subcontracted work is defined and planned according to a
documented procedure.
2. The software subcontractor is selected based on an evaluation of the
subcontract bidder's ability to perform the work, according to a
documented procedure.
3. The contractual agreement between the prime and subcontractor is
used as the basis for managing the subcontract.
4. A documented subcontractor's software development plan is reviewed
and approved by the prime.
5. A documented subcontractor's software development plan is used for
tracking the software activities and communicating status.
6. Changes to the software subcontractor's statement of work, terms and
conditions, and other commitments are resolved according to a
documented procedure.
7. The prime's management conducts periodic status/coordination reviews
with the subcontractor's management.
April 20, 2010
Level 2: Subcontract Management Practices
Subcontract Management Practices:
8. Periodic technical reviews and interchanges are held with the
subcontractor.
9. Formal reviews to address the subcontractor's accomplishments and
results are conducted at selected milestones, according to a documented
procedure.
10. The prime's software quality assurance group monitors the
subcontractor's software quality assurance activities, according to a
documented procedure.
11. The prime's software configuration management group monitors the
subcontractor's configuration management activities, according to a
documented procedure.
12. The prime conducts acceptance testing as part of the delivery of the
subcontractor's software products, according to a documented
procedure.
13. The subcontractor's performance is evaluated on a periodic basic, and
the evaluation is reviewed by the subcontractor.
April 20, 2010
Level 2: Software Quality Assurance Practices
Goals:
1. Software quality assurrance activities are planned.
2. Adherence of software products and activities to the applicable standards,
procedures, and requirements is verified objectively.
3. Affected groups and individuals are informed of software quality assurance
activities and results.
4. Noncompliance issues that cannot be resolved within the software project are
addressed by senior management.
The purpose of SQA is to provide management with appropriate visibility into the
process being used by the project and the products being built.
SQA involves reviewing project products and activities to verify they comply with
applicable documented procedures and standards.
SQA provides the software project and other designate managers the results of
reviews and audits.
SQA works with the project team during its early stages to establish plans, standards,
and procedures that will add value to the project and satisfy the constraints of
the project and the organization’s policies.
April 20, 2010
Level 2: Software Quality Assurance Practices
Software Quality Assurance Practices:
1. A SQA plan is prepared for the software project, according to a documented
procedure.
2. The SQA group’s activities are performed in accordance with the SQA plan
3. The SQA group participates in the preparation and review of the project’s
software development plan, standards, and procedures.
4. The SQA group reviews software engineering activities to verify compliance.
5. The SQA group audits designated software work products to verify
compliance.
6. The SQA group periodically reports the results of its activities to the
software team.
7. Deviations identified in the software activities and software work products
are documented and handled according to a documented procedure.
8. The SQA group conducts periodic reviews of its activities and findings with
the customer’s SQA personnel, as appropriate.
April 20, 2010
Level 2: Software Configuration Management Practices
Goals:
1.
2.
3.
4.
Software configuration management activities are planned.
Selected software work products are identified, controlled, and available.
Changes to identified software work products are controlled.
Affected stakeholders are informed of the status and content of the software
baselines.
The purpose of SCM is to establish and maintain the integrity of the products of the
software project throughout the project’s life cycle.
SCM 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.
A software baseline library is established containing the software baselines as they
are developed. Changes to baselines and release of the software products built
from the baseline library are systematically controlled via change control and
configuration auditing functions of the SCM.
Products placed under CM include customer deliverables and items that are required
to create them (e.g. a compiler).
April 20, 2010
Level 2: Software Configuration Management Practices
Software Configuration Management Practices:
1. An SCM plan is prepared for each software project according to documented
procedure.
2. A documented and approved SCM plan is used as the basis for performing SCM
activities.
3. A configuration management library system is established as a repository for the
software baselines.
4. The software work products to be placed under configuration management are
identified.
5. Change requests and problem reports for all configuration items/units are
initiated, recorded, reviewed, approved, and tracked according to documented
procedure.
6. Changes to baselines are controlled according to documented procedure.
7. Products from the software baseline library are created and their release is
controlled according to documented procedure.
8. The status of configuration items/units is recorded according to documented
procedure.
9. Standard reports documenting the SCM activities and the contents of the
software baseline are developed and made available to affected stakeholders.
10. Software baseline audits are conducted according to documented procedure.
April 20, 2010
Level 3: Key Practices (Organization Process Focus)
Purpose: Organization Process Focus
–
–
–
To establish the organizational responsibility for software practice activities that
improve the organization's overall software process capability.
This involves developing and maintaining an understanding of the
organization's and project's software processes and coordinating activities to
assess, develop, maintain, and improve these processes.
This is accomplished by establishing a software process group responsible for
the organization's software process activities. It is responsible for developing
and maintaining process standards for the organization, and it coordinates the
process activities with each project.
Goals: Organization Process Focus
1. Software process development and improvement activities are coordinated across
the organization.
2. The strengths and weaknesses of the software processes used are identified
relative to a process standard.
3. Organization-level process development and improvement activities are planned.
April 20, 2010
Level 3: Key Practices (Organization Process Focus)
Organization Process Focus Practices:
1. The software process is assessed periodically, and action plans are developed to
address the assessment findings.
2. The organization develops and maintains a plan for its software process
development and improvement activities.
3. The organization's and project's activities for developing and improving their
software processes are coordinated at the organizational level.
4. The use of the organization's software process database is coordinated at the
organizational level.
5. New processes, methods, and tools in limited use in the organization are
monitored, evaluated, and, where appropriate, transferred to other parts of the
organization.
6. Training for the organization's and project's software processes is coordinated
across the organization.
7. The groups involved in implementing the software processes are informed of the
organization's and project's activities for software development and
improvement.
April 20, 2010
Level 3: Key Practices (Organization Process Definition)
Purpose: Organization Process Definition
–
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.
– Involves developing and maintaining the organizations standard
software process, along with related process assets, such as description
of software lifecycles, process tailoring guidelines and criteria, the
organization's process database, and a library of process-related
documentation.
Goals: Organization Process Definition
1. A standard software process is developed and maintained.
2. Information related to the use of the organization's standard process is
collected, reviewed, and made available in a persistent form.
April 20, 2010
Level 3: Key Practices (Organization Process Definition)
Organization Process Definition Practices:
1. The organization's standard software process is developed and
maintained according to a documented procedure.
2. The organization's standard software process is documented according
to established organization standards.
3. Descriptions of approved software lifecycles available for use by
projects are documented and maintained.
4. Guidelines and criteria for projects' tailoring of the organization's
standard process are developed and maintained.
5. The organization's software process database is developed and
maintained.
6. A library of software process-related documentation is established and
maintained.
April 20, 2010
Level 3: Key Practices (Training Program)
Purpose: Training Program
–
To develop the skills and knowledge of individuals so they can perform
their roles effectively and efficiently.
– Involves identifying training needs.
– Involves procuring the training agent and delivery system.
Goals: Training Program
1. Training activities are planned.
2. Training for developing skills and knowledge needed to perform
software management and technical roles are provided.
3. Individuals in the software engineering group and software-related
groups receive the training necessary to perform their roles.
April 20, 2010
Level 3: Key Practices (Training Program)
Training Program Practices:
1. Each software project develops and maintains a training plan
that specifies its training needs.
2. The organization's training plan is developed and revised
according to a documented procedure.
3. The training for the organization is performed in accordance
with the organization's training plan.
4. Training courses prepared at the organization level are
developed and maintained according to organization standards.
5. A waiver procedure for required training is established and used
to determine whether individuals already posses the knowledge
and skills required to perform in their designated roles.
6. Records of training are maintained.
April 20, 2010
Level 3: Key Practices (Integrated Software Management)
Purpose: Integrated Software Management
–
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 the Organization Process Definition.
– Involves developing the project’s process defined software process and
managing the project using that defined software process; the defined
project software process is tailored from the organization’s standard
process to address specific project characteristics.
Goals: Integrated Software Management
1. The project’s defined software process is a tailored version of the
organization’s standard process.
2. The software development plan is based on the project’s defined
process.
3. The management of the project’s size, effort, cost, schedule,
staffing, and other resources are tied to the project’s defined
process.
April 20, 2010
Level 3: Key Practices (Integrated Software Management)
Integrated Software Management Practices:
1. The project’s defined software process (pdsp) is developed by tailoring the
organization’s standard software proces (ossp) according to a documented
procedure(adp).
2. Each pdsp is revised adp.
3. The software project’s software development plan, which describes the use of the
pdsp, is developed and revised adp.
4. The software project is managed in accordance with the pdsp.
5. The ossp database is used for software planning and estimating.
6. The size of the software work products (or the size of their changes) is managed
adp.
7. The project’s software effort and costs are managed adp.
8. The project’s critical computer resources are managed adp.
9. The critical dependencies and critical pats of the project’s schedule are managed
adp.
10. The project’s software risks are identified, assessed, documented, and managed
adp.
11. Reviews of the software project are periodically performed to determine the
actions needed to bring the software project’s performance and results in line
with the current and projected needs of the business, customer, end users, as
appropriate.
April 20, 2010
Level 3: Key Practices (Software Product Engineering)
Purpose: Software Product Engineering
–
To perform consistently a well-defined engineering process that
integrates all the software engineering activities to produce correct,
consistent software products effectively and efficiently.
– Involves performing the engineering tasks to build and maintain the
software using the project’s defined software process and appropriate
methods and tools.
Goals: Software Product Engineering
1. The software engineering tasks are defined, integrated, and
consistently performed to produce the software.
2. Software work products are kept consistent with one another.
April 20, 2010
Level 3: Key Practices (Software Product Engineering)
Software Product Engineering Practices:
1. Appropriate software engineering methods and tools are integrated into
the pdsp.
2. The software requirements are developed, maintained, documented, and
verified by systematically analyzing the allocated requirements
according to the pdsp.
3. The software design is developed, maintained, documented, and verified
according to the pdsp, to accommodate the software requirements and
to form the framework for coding.
4. The software code is developed, maintained, documented, and verified
according to the pdsp, to implement the software requirements and
software design.
5. Software is testing is performed according to the pdsp.
6. Integration testing of the software is planned and performed according
to the pdsp.
April 20, 2010
Level 3: Key Practices (Software Product Engineering)
Software Product Engineering Practices:
7. System and acceptance testing of the software are planned and
performed to demonstrate that the software satisfies its requirements.
8. The documentation that will be used to operate and maintain the
software is developed and maintained according to the psdp.
9. Data on defects identified in peer reviews and testing are collected and
analyzed according to the pdsp.
10. 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.
April 20, 2010
Level 3: Key Practices (Intergroup Coordination)
Purpose: Intergroup Coordination
–
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.
– Involves the software engineering group's participation with the other
engineering groups to address system-level requirements, objectives,
and issues.
Goals: Intergroup Coordination
1. The customer's requirements are agreed to by all affected groups.
2. The commitments between engineering groups are agreed to by the
affected groups.
3. The engineering groups identify, track, and resolve intergroup issues.
April 20, 2010
Level 3: Key Practices (Intergroup Coordination)
Intergroup Coordination Practices:
1. The software engineering group and the other engineering groups
participate with the customer and end users, as appropriate, to establish
the system requirements.
2. Representatives of the project's software engineering group work with
representatives of the other engineering groups to monitor and
coordinate technical activities and resolve technical issues.
3. A documented plan is used to communicate intergroup commitments
and to coordinate and track the work performed.
4. Critical dependencies between engineering groups are identified,
negotiated, and tracked according to a documented procedure.
5. Work products produced as input to other engineering groups are
reviewed by representatives of the receiving groups to ensure that the
work products meet their needs.
6. Intergroup issues not resolvable by the individual representatives of the
project engineering groups are handled according to a documented
procedure.
7. Representatives of the project engineering groups conduct periodic
technical reviews and interchanges.
April 20, 2010
Level 3: Key Practices (Peer Reviews)
Purpose: Peer Reviews
–
–
To remove errors from the software work products early and efficiently.
Involve a methodical examination of software work products by the
producer's peers to identify errors and areas where changes are needed.
Goals: Peer Reviews
1. Peer review activities are planned.
2. Errors or required changes in software work products are identified
and removed.
April 20, 2010
Level 3: Key Practices (Peer Reviews)
Peer Reviews Practices:
1. Peer reviews are planned and plans are documented.
2. Peer reviews are performed according to a documented procedure.
3. Data on the conduct and results of the peer reviews are recorded.
April 20, 2010