Page 203 -

174 PART TWO MANAGING SOFTWARE PROJECTS

applied. SQA, SCM, documentation, and measurement tasks will be con-
ducted in a streamlined manner.
Strict. The full process will be applied for this project with a degree of disci-
pline that will ensure high quality. All umbrella activities will be applied and
robust work products will be produced.
Quick reaction. The process framework will be applied for this project, but
8
because of an emergency situation only those tasks essential to maintaining
If everything is an good quality will be applied. “Back-filling” (i.e., developing a complete set of
emergency, there’s
something wrong with documentation, conducting additional reviews) will be accomplished after
your software process the application/product is delivered to the customer.
or with the people who The project manager must develop a systematic approach for selecting the degree
manage the business
or both. of rigor that is appropriate for a particular project. To accomplish this, project adap-
tation criteria are defined and a task set selector value is computed.

7.3.2 Defining Adaptation Criteria
Adaptation criteria are used to determine the recommended degree of rigor with which
the software process should be applied on a project. Eleven adaptation criteria [PRE99]
are defined for software projects:
• Size of the project
• Number of potential users
• Mission criticality
• Application longevity
• Stability of requirements
• Ease of customer/developer communication
• Maturity of applicable technology
Adaptable Process Model
• Performance constraints
• Embedded and nonembedded characteristics

• Project staff
• Reengineering factors
Each of the adaptation criteria is assigned a grade that ranges between 1 and 5, where
1 represents a project in which a small subset of process tasks are required and over-
all methodological and documentation requirements are minimal, and 5 represents
a project in which a complete set of process tasks should be applied and overall
methodological and documentation requirements are substantial.

8 Emergency situations should be rare (they should not occur on more than 10 percent of all work
conducted within the software engineering context). An emergency is not the same as a project
with tight time constraints.