Lecture Software process improvement: Lesson 16 - Dr. Ghulam Ahmad Farrukh

Lecture Software process improvement: Lesson 1 provide students with knowledge about: CMMI staged – maturity level 3; the maturity levels; attributes of a process suggested by CMMI; defined process builds; requirements development; technical solution; product integration; verification; validation; organizational process focus;... Please refer to the detailed content of the lecture!

­ 1

Lecture # 16

The Maturity Levels

organizational identity

• There are common, shared approaches for performing daily tasks on each project. For example, estimating the size of a project 

may be done using the Delphi Technique 

(basically subject matter experts discussing best­case and worst­case estimates), a 

standard metric may have been 

institutionalized (such as using function 

points instead of lines of code), and a 

standard tool may be in use 5

• This organizational way of doing business 

is documented in the Organization’s Set of Standard Processes (OSSP)

• However, should a project need to tailor 

this OSSP to more adequately fit its needs, then that tailoring request is bought to a 

decision­making body (usually the 

Engineering Process Group [EPG]), and if appropriate, the request is granted

by lines of code. The Delphi Technique is still used, but lines of code is the 

• To perform at Level 3, an organization must have satisfied all of the goals for all of the process areas (PAs) in both Level 2 and 

Level 3

• Sometimes exceptions may be made. 

Caution should be exercised however

and the less likely the organization is to 

achieve a maturity level through an 

by CMMI

• Activities—Tasks that must be performed. These tasks are usually later broken down 

• Verification steps—What reviews are 

performed to determine that this process is followed and is producing the correct 

results? (Usually management and quality assurance reviews, but sometimes can 

include customer, peer, and project team 

reviews.)

• Outputs—Work products, plans, approved products (can be the completed inputs)

• Exit criteria—How do we know when it is time to stop this process? (Usually 

expressed in verbs, and usually becomes the entry criteria for the next process step or 

next process.)

• Another distinction is made concerning 

processes. A managed process is a process 

that tackles project management efforts, is planned and executed according to a policy, 

is monitored, and reviewed to ensure 

adherence to its process description

• This is the type of process expected at 

Maturity Level 2

inserted

11 Process Areas for Level 3 

(Defined)

• To satisfy the goals for Level 3, the goals for Level 2 must be satisfied as well

• This mandate holds true for both the 

specific goals (listed in each process area 

below) and the generic goals

• There are two generic goals for levels 2 and 3

• GG2 Institutionalize a Managed Process

• GG3 Institutionalize a Defined Process

Generic Practices for Institutionalize 

a Defined Process

GG3 Institutionalize a Defined  Process – Generic Practices

• GP 3.1 Establish a Defined Process

• GP 3.2 Collect Improvement Information

PA 1

• The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component 

SG3 Analyze and Validate  Requirements – Specific Practices

• SP 3.1 Establish Operational Concepts and Scenarios

• SP 3.2 Establish a Definition of Required Functionality

• SP 3.3 Analyze Requirements

• SP 3.4 Analyze Requirements to Achieve Balance

Discussion on RD

• Requirements Development is where requirements  are created and documented

• Requirements Management at Level 2 is where 

changes are administered

• Requirements Development gathers requirements  and then must usually refine these requirements in  some way—by stating them more clearly, 

determining whether they are redundant or 

inconsistent with other requirements, and breaking  them down into more detailed and traceable 

in new development or in maintenance mode, there  are always new requirements or changes to existing  requirements that require  definition ,  refinement , 

user interaction , and so forth. That is, all of the 

behaviors necessary to produce complete and 

accurate requirements, and discussed in this process  area

32

• This process area introduces the Concept of 

Operations or, using the CMMI term, 

operations concept. This document is usually  the first document written when determining 

whether to pursue development of a product. It 

is usually a high­level statement of the desired  functionality, and a preliminary plan and 

schedule for development, to justify initiating  this new project to higher­level management

• In the commercial these documents are 

generally not used. This can be a problem when following the CMMI because this 

document is expected in several practices throughout the model. Organizations that 

are not DOD­like generally rely on object­oriented techniques, use cases, or man–

machine interface documentation to satisfy this concept

• Maintenance shops also do development

• Even if you get your requirements directly from the customer, some refinement and 

• There are no generic practices that directly map to this process area

• Requirements Development includes collecting and 

eliciting customer requirements from all involved parties 

at all levels; breaking down those high­level requirements  into lower­level, more detailed requirements, and 

assigning them to categories for further development; 

defining interfaces among the requirements and any other  areas necessary to fulfill the requirements; more 

adequately defining and documenting the operational need,  concept, scenario, and functionality desired; ensuring that  the requirements are complete, required, and consistent;  negotiating needs versus wants versus constraints; and 

validating the requirements against risk in the early phases 

PA 2

• SG1 Select Product Component Solutions

• SG2 Develop the Design

• SG3 Implement the Product Design

SG1 Select Product Component  Solutions – Specific Practices

• SP 1.1 Develop Alternative Solutions and Selection Criteria

• SP 1.2 Select Product Component Solutions

• Peer reviews are mentioned in this process area

• Alternative solutions should be investigated

• There are no generic practices that directly map to this process area

• Technical Solution includes determining how to satisfy the  requirements via analysis of different alternatives and 

implementing the design and generating supporting 

documentation

PA 3

• Specific goals for this process area are

– SG1 Prepare for product integration

– SG2 Ensure Interface Compatibility

– SG3 Assemble Product Components and Deliver  the Product

50

SG3 Assemble Product Components  and Deliver the Product – Specific 

Discussion on PI

• This is where the product comes together 

and you get to see the results of your work

• It is also where you deliver the product, and that means you get paid

• This process area expects the project to 

demonstrate each step to the user

• This process area is not release 

management. Releasing products is covered somewhat in Configuration Management, Supplier Agreement Management, and 

Technical Solution

• There are no generic practices that directly map to this process area

• Product Integration includes determining 

how to assemble the product and what the sequence of assembly should be; creating 

an operational environment in which to 

satisfactorily deploy the product; 

documenting procedures and criteria for 

integrating the product; ensuring adequate integration of interfaces; and delivering the 

• There are no generic practices that directly map to this process area

Summary

• Interpreting the CMMI: A Process 

Improvement Approach, Second Edition, by Margaret K. Kulpa and Kent A. Johnson, 

Auerbach Publication, 2008 (electronic 

file), (Chapter 6)