Software Process Improvement

What is SPI?
SPI involves understanding existing processes and changing these processes to improve product quality and/or reduce costs and development time.

What is SPI?
SPI provides organisations with a powerful means of assessing their current capabilities for developing software systems and, in doing so, identifying their strengths and weaknesses. The underlying theme of SPI is that by understanding and defining an organisations current software development processes, organisations can determine the areas that can be controlled and manipulated in order to achieve a particular product effect (Humphrey, 1995).

Why SPI?
Customer Satisfaction Productivity

Quality

Process Improvement

Marketing Development Cost

Delivery Time

Why SPI? Motorola

10 9 8 7 6 5 4 3 2 1 Level 1 Level 2 Level 3 Level 4 Level 5 Productivity Increase Defect Reduction Cycle Time Reduction

Software Capability Maturity Model (CMM) Maturity

Diaz, M., & Sligo, J. (1997). How software process improvement helped motorola. IEEE Software, 14(5), 75-81. Capability Maturity Model and CMM are registered in the U.S. Patent and Trademark Office.

Why SPI? Hewlett Packard

70 60 50 Millions 40 30 20 10

89

90

91

92

93

94

95

96

97

98

Software Inspection Process Return on Investment (ROI)

Grady, R. B. (1997). Successful software process improvement. Saddle River, NH: Prentice Hall.

Why SPI? Raytheon

100 90 80 70 60 50 40 30 20 10 88 89 90 91 92 93 94 95 96

Software Productivity Increase

Haley, T. J. (1996). Software process improvement at raytheon. IEEE Software, 13(6), 33-4.

Why SPI? Boeings Space

Before SPI

After SPI

Why SPI? NEC

100

80

Defects

60

40

20

84

85

86

87

88

89

90

91

92

93

Defect Prevention Results (Corporate-Wide)

Kajihara, J., Amamiya, G, & Saya, T. (1993). Learning from bugs. IEEE Software, 10(5), 46-54.

Why SPI? Australia

Have SPI initiatives provided clear and expected benefits to the management?
80 70 60 50 40 30 20 10 0 Percentage Yes No Do not know

Niazi, M., Wilson, D. and Zowghi, D. Implementing Software Process Improvement Initiatives: An empirical study. The 7th International Conference on Product Focused Software Process Improvement, LNCS. 222-233. 2006

Why SPI? Vietnam

Have SPI initiatives provided clear and expected benefits to the management?
100 90 80 70 60 50 40 30 20 10 0 Percentage

Yes No Do not know

Niazi, M., and M, Ali Babar, D. Implementing Software Process Improvement Initiatives: An Analysis of Vietnamese Practitioners Views, submitted to ICGSE 2008

Six Steps for SPI

Understand the current status of development process
Learn how the organization works Identify the main problems and issues
if you dont know where you are map wont help

Six Steps for SPI contd..

Develop a vision of desired process
Current status Model Cost involved Management support
If you dont know where you are going, any road will do.

Six Steps for SPI contd..

Establish a list of required process improvement actions in order of priority
Identify required actions Set priorities by understanding the present structure
You cant improve what you dont understand

Six Steps for SPI contd..

Produce a plan to accomplish the required actions
Top-Down : CMM, Trillium Bottom-Up : Experience Factory

Six Steps for SPI contd..

Commit the resource to execute the plan
Need all level of managements commitment Resources Formation of SEPG Technical support ..

Six Steps for SPI contd..

Start over at step 1
Process improvement is a never ending continuous process We can never reach perfection

Organisational motivations for SPI

80 70 60 50 40 30 20 10 0 Percentage Process visibility Customer demands Market advantage Software quality Development time Development cost Productivity

How SPI?
CMMI, ISO 9001:2000, SPICE
Business Objectives New Development Process
?

Better Meets

A Model

Change Compliance Poorly Meets

Development Process

How SPI?
ISO 9001:2000 ISO/ IEC 15504 CMM

How SPI? - ISO

ISO9001:2000 is the internationally recognised Quality Management Standard. The ISO9001 process provides a robust framework for improving every organisations quality system by adopting 8 quality management principles:
Customer focus Leadership Involvement of people Documented processes Integrated systems Continuous improvement A factual approach to decision making Mutually beneficial supplier relationships

How SPI? ISO/ IEC 15504

ISO/IEC 15504 is an international standard for process assessment developed under the auspices of the International Organization for Standardization and the International Electrotechnical Commission (ISO/IEC). The full international Standard version of 15504 consists of five documents. 15504-1 (Concepts and Vocabulary), 15504-2 (Performing an Assessment), 15504-3 (Guidance on Performing an Assessment), 15504-4 (Guidance on Use for Process Improvement and Process Capability Determination), and 15504-5 (An Exemplar Process Assessment Model) were published in 2003-2006.

What is a process assessment?

A software process assessment is an appraisal or review of an organisations software process. The primary drive for software process assessment has come not from the software development industry, but rather from acquirers of large, critical, softwareintensive systems, notably in the defence and telecommunications sectors. Software process assessment has a variety of definitions in the literature.

23

What is a process assessment?

Software Engineering Institute defines process assessment as (Paulk et al. 1994): An appraisal by a trained team of software professionals to determine the state of an organisations current software process, to determine the high-priority software process-related issues facing an organisation, and to obtain the organisational support for software process improvement. The ISO/IEC 15504 documentation defined assessment as (ISO, 1997): A disciplined evaluation of an organisations software process against process model.
24

Assessment phases
Pre-Assessment/ Pre-Planning Assessment Cycle
Planning Fact finding Fact analysis

Post-Assessment/ Process Improvement Plan

25

Assessment phases
Pre-Assessment/ Pre-Planning
Investigate business needs Understand the business Understand corporate culture Define scope and boundaries Availability of resources

26

Assessment phases
Planning
This involves defining the assessment activities, resources, time scale and logistics. The assessment plan should contain deliverables, milestones and quality plans. Selection of assessment team. Training the assessment team. Gantt diagrams Pert charts

27

Assessment phases
Fact gathering
This involves gathering the data and information about the current state of the software process and practices as they exist in the organisation. It also involve gathering the views of individual. Selection of fact gathering approaches (interviews, questionnaire etc). Distributing and collecting questionnaire responses. Conducting interviews.
28

Assessment phases
Fact analysis
This involves analysing the facts gathered in order to identify strengths and weaknesses based on an accurate picture of the current state of the software process. Analysis of questionnaire and interviews. Analysis of the evidence gathered. Conducting interviews.

Reporting
This involves summarising the findings and recommendations and presenting them back to the sponsor.
29

Assessment phases
The Post-Assessment Phase
This phase will vary depending on the business context of the assessment. Implementing the process improvement actions recommended. Managing and monitoring the process improvement plan.

30

SW-CMM L2 & L3 KPAs

32

Maturity Levels

contain

CMM Structure
Organized by

indicate Process Capability achieve Goals

Key Process Areas

Common Features
address Implementation or Institutionalization describe
33

contain

Key Practices

Infrastructure or Activities

The KPAs
Each KPA is described by identifying the following characteristics: Goals: the overall objective that a KPA must achieve Commitment: requirements (imposed on organization) that must be met to achieve the goals, and provide proof of intent to comply with the goals Abilities: those things that must be in place (organizationally and technically) that will enable the organization to meet the commitments Activities: the specific tasks that are required to achieve the KPA function Methods for monitoring implementation: the manner in which the activities are monitored as they are put into place Methods for verifying implementation: the manner in which proper practice for the KPA can be verified. Eighteen KPAs are defined across the CMM
34

Key Process Arias (18-KPAs)

Optimizing
Defect Prevention Technology change management Process change management

Managed Defined

Quantitative process management Software quality management

Organization process focus Organization process definition Training program Integrated software management Software product engineering Intergroup coordination Peer reviews Requirements Management Software project planning Software project tracking and oversight Software subcontract management Software quality assurance Software configuration management 35

Repeatable

Initial

The CMM Structure Maturity Levels 2 3 4 5

Key Process Areas Goals

RM

PP

PT

SM

QA

CM

Common Activities Features Performed Key Practices

Commitment to Perform

Ability to Perform

Measurement and Analysis

Verifying Implementation

36

CMM Level 2 Key Process Areas

Requirements Management Software Project Planning Software Project Tracking & Oversight Software Subcontract Management Software Quality Assurance Software Configuration Management.

37

Level 2 Key Process Area:

Requirements Management
Purpose
To establish a common understanding between the customer and the software project of the customers requirements that will be addressed by the software project

Goals

Scope
Involves establishing and maintaining an agreement with the customer on the requirements for the software project Agreement is the basis for estimating, planning, performing, and tracking the projects software activities

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
38

Commitment
Written organizational Policy

Activities 1. 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. REQUIREMENTS MANAGEMENT
39

Measurement
Determine the status of the activities for managing the allocated requirements

2. Ability
1. 2. 3. Responsibility assigned Requirements documented Adequate resources & funding Training for requirements management activities

Verification
Activities reviewed with senior management on a periodic basis. Activities are reviewed with the project manager on both a periodic and eventdriven basis. SQA group reviews/ audits

3.

4.

Level 2 Key Process Area:

Software Project Planning

Purpose
To establish reasonable plans for performing the software engineering and for managing the software project

Goals

Scope
Involves: o developing estimates for the work to be performed o establishing the necessary commitments o defining the plan to perform the work Plan provides the basis for initiating the software effort and managing the work

1. Software estimates are documented for use in planning and tracking the software project. 2. Software project activities and commitments are planned and documented. 3. Affected groups and individuals agree to their commitments related to the software project.
40

Commitment
Designated Software Project Manager Written organizational policy for planning a software project

Activities The software engineering group participates on the project proposal team. Software project planning is initiated in the early stages 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
41

Measurement
Determine status of the software planning activities

SW PROJECT PLANNING

Ability
Documented and approved statement of work Responsibility for s/w development plan Adequate resources and funding for project planning Training - estimation & planning

Verification
Periodic Senior management review Review with project manager on both periodic and event driven basis Software Quality Assurance group reviews and /or audits

Software Project Planning - Activities

Software life cycle is 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.

42

Software Project Planning - Activities

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.
43

Level 2 Key Process Area:

Software Project Tracking and Oversight

Purpose
To provide adequate visibility into actual progress so that management can take effective actions when performance deviates significantly from the plan

Goals 1. Actual results and performances are tracked against the software plans. 2. Corrective actions are taken and managed to closure when actual results deviate significantly from the software plans. 3. Changes to software commitments are agreed to by the affected groups and

Scope
Involves:  tracking and reviewing software accomplishments and results against documented estimates, commitments, and plans  adjusting plans based on actual accomplishments and results

individuals.

44

Commitment
Project Software Manager Written Policy

Activities 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.

Measurement
Determine status of the software tracking and oversight activities

Ability
SW Development plan (doc & appr) Project SW Manager resp Adequate resources Training - technical & personnel aspects

Verification
Periodic Senior management review Review with project manager on both periodic and event driven basis Software Quality Assurance group reviews and /or audits

45

Software Project Tracking and Oversight

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.

46

Software Project Tracking and Oversight

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

47

Level 2 Key Process Area:

Software Subcontract Management

Purpose
To select qualified software subcontractors and manage them effectively

Goals 1. The prime contractor selects qualified software subcontractors. 2. The prime contractor and the software subcontractor agree to their commitments to each other. 3. The prime contractor and the software subcontractor maintain ongoing communications. 4. The prime contractor tracks the software subcontractors actual results and performances against its commitments.

Scope
Involves: o selecting a software subcontractor o establishing commitments with the subcontractor o tracking and reviewing the subcontractors performance and results

Not Applicable
48

Level 2 Key Process Area:

Software Quality Assurance

Purpose
To provide management with appropriate visibility into the process being used and the products being built

Scope
Involves: o reviewing and auditing the software products and activities to ensure that they comply with the applicable procedures and standards o providing the software project and other appropriate managers with the results of those reviews and audits

Goals 1. Software quality assurance activities are planned. 2. Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively. 3. Affected groups and individuals are informed of software quality assurance activities and results. 4. Noncompliance issues that cannot be resolved within the software project are addressed by senior management.

49

Commitment
Written Policy

Activities
A SQA plan is prepared for the software project according to a documented procedure The SQA groups activities are performed in accordance wit h the SQA plan.

Measurement
Cost and schedule status of SQA activities

SOFTWARE QUALITY ASSURANCE Verification

Periodic Senior management review Review with project manager on both periodic and event driven basis Review of SQA activities

Ability
Responsible Group Adequate resources Training - SQA activities Members of SW project orientation

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.
50

Software Quality Assurance

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.

51

Level 2 Key Process Area: Software Configuration Management

Purpose
To establish and maintain the integrity of the products of the software project throughout the software life cycle

Goals 1. Software configuration management activities are planned. 2. Selected software work products are identified, controlled, and available. 3. Changes to identified software work products are controlled. 4. Affected groups and individuals are informed of the status and content of software baselines.

Scope
Involves: o identifying configuration items/units o systematically controlling changes o maintaining integrity and traceability of the configuration throughout the software life cycle

52

Commitment
Written Policy

Activities 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.

Measurement
Determine status of the SCM Activities

SW CONFIGURATION MANAGEMENT Verification

Periodic Senior management review Review with project manager on both periodic and event driven basis Periodic audits by SCM group SQA review and/or audit

Ability
Authority defined SCM group exists Adequate resources Training - objectives, procedures of CM Training - SW engg and other groups

53

Software Configuration Management

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

54

Software Configuration Management

Software baseline audits are conducted according to a documented procedure.

55

CMM Level 3 Key Process Areas

Organization Process Focus\ Organization Process Definition Training Program Integrated Software Management Software Product Engineering Intergroup Coordination Peer Reviews
56

Level 3 Key Process Area:

Organization Process Focus

Purpose
To establish the organizational responsibility for software process activities that improve the organizations overall software process capability

Goals 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.

Scope
Involves: o developing and maintaining an understanding of organization and project software processes o coordinating the activities to assess, develop, maintain, and improve these processes

57

Commitment
Written Policy Sr. Management Sponsorship Sr. Management Oversees

Activities

Measurement
Determine status of the organizations process development and improvement activities

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.
58

Ability
Group responsible exists Adequate resources Training

Verification
Periodic Senior management review

ORGANIZATION PROCESS FOCUS

Organization Process Focus

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

59

Level 3 Key Process Area:

Organization Process Definition

Purpose
To develop and maintain a usable set of software process assets that improve process performance and provide a basis for cumulative, long-term benefits

Goals

1. A standard software process for

the organization is developed and maintained. 2. Information related to the use of the organizations standard software process by the software projects is collected, reviewed, and made available.

Scope
Involves developing and maintaining the organizations standard software process and related process assets The organizations standard software process describes the fundamental elements that each project incorporates and tailors to fit the project

60

Commitment
Written Policy

Activities
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.

Measurement
Determine status of the organizations process definition activities

Ability
Adequate resources and funding Training - for the process group

Verification
Software Quality Assurance group reviews and /or audits

ORGANIZATION PROCESS DEFINITION

61

Organization Process Definition

The organization's software process database is established and maintained. A library of software process-related documentation is established and maintained.

62

Level 3 Key Process Area:

Training Program
Purpose
To develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently

Goals 1. Training activities are planned. 2. Training for developing the skills and knowledge needed to perform software management and technical roles is provided. 3. Individuals in the software engineering group and softwarerelated groups receive the training necessary to perform their roles.

Scope
Involves: o identifying the training needs of the organization, the projects, and individuals o developing and/or procuring training to address these needs

63

Commitment
Written Policy

Activities
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.

Measurement
Determine status of the training program activities Quality of the training program

Ability
Responsible Group Adequate resources & Funding Training group to have necessary skills SW Managers orientation

The training for the organization is performed in accordance with the organization's training plan.

Verification
Periodic Senior management review Periodic evaluation Reviewed and / or audited

Training courses prepared at the organization level are developed and maintained according to organization standards

TRAINING PROGRAM

64

Training Program
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.

65

Level 3 Key Process Area:

Integrated Software Management

Purpose
To integrate the projects software engineering and management activities into a coherent, defined software process tailored from the organizations software process assets

Goals

Scope
Involves: o developing the projects defined software process by tailoring the organizations standard software process o managing the software project according to this defined software process

1. The projects defined software process is a tailored version of the organizations standard software process. 2. The project is planned and managed according to the projects defined software process.

66

Commitment
Written Policy

Activities 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.
67

Measurement
Determine the effectiveness of the integrated software management activities

INTEGRATED SW MANAGEMENT

Ability
Adequate resources and funding Training - tailoring of processes. Software Managers training

Verification
Periodic Senior management review Review with project manager on both periodic and event driven basis Software Quality Assurance group reviews and /or audits

Integrated Software Management

The software project is managed in accordance with the project's defined software process. The critical dependencies and critical paths of the project's software schedule are managed according to a documented procedure. 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.

68

Integrated Software Management

The project's critical computer resources 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

69

Level 3 Key Process Area:

Software Product Engineering

Purpose
To consistently perform a welldefined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently

Goals

Scope
Involves performing the engineering tasks to build and maintain the software using appropriate tools and methods Includes requirements analysis, design, coding, integration, and testing

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.

70

Commitment
Written Policy

Activities 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. SOFTWARE PRODUCT ENGINEERING

Measurement
Determine the functionality and quality of the software products Determine status of SE Engg. activities

Ability
Adequate resources and funding Training - technical areas Orientation on related SW engineering disciplines Orientation on technical aspects of the project

Verification
Periodic Senior management review Review with project manager on both periodic and event driven basis Software Quality Assurance group reviews and /or audits

71

Software Product Engineering

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.

72

Software Product Engineering

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.

73

Level 3 Key Process Area:

Intergroup Coordination
Purpose
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 customers needs effectively and efficiently

Goals 1. The customers requirements are agreed to by all affected groups. 2. The commitments between the engineering groups are agreed to by the affected groups. 3. The engineering groups identify, track, and resolve intergroup issues.

Scope
Involves the disciplined interaction and coordination of the project engineering groups with each other to address system-level requirements, objectives, and plans

74

Commitment
Written organizational policy

Activities 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. INTERGROUP COORDINATION

Measurement
Determine status of the intergroup coordination activities

Ability
Adequate resources and funding Support Tools Training - for all managers in teamwork Orientation - Task leaders Training - Members in teamwork

Verification
Periodic Senior management review Review with project manager on both periodic and event driven basis Software Quality Assurance group reviews and /or audits

75

Intergroup Coordination
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.

76

Intergroup Coordination
Representatives of the project engineering groups conduct periodic technical reviews and interchanges.

77

Level 3 Key Process Area:

Peer Reviews
Purpose
To remove defects from the software work products early and efficiently To develop a better understanding of the software work products and of defects that might be prevented

Goals

Scope
Involves a methodical examination of work products by the producers peers to identify defects and areas where changes are needed

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

78

Commitment
Written organizational Policy

Activities 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.

Measurement
Determine the status of the peer review activities

Ability
Adequate resources & funding Training - how lead peer reviews Training - Peer review obj. etc

Verification
SQA group reviews/ audits

PEER REVIEWS

79

80

81