Project characteristic: Project type

Most software projects belong to one or more of the following generic project types.

• Concept development projects
• New application development projects
• Application enhancement projects
• Application maintenance projects
• Re-engineering projects
• Web application development projects

Project characteristic: Degree of rigor

Software projects differ in the required degree of formality, that is, the relative degree of formality with which software engineering tasks will be conducted.
For a short-lived software product that will be used by a limited number of people and is of relatively low business criticality, a casual approach to software engineering may be appropriate.
On the other hand, for a software product that is business-critical, expected to have a long life, likely to undergo many changes, and be used by hundreds or thousands of people, a strict approach to software engineering is indicated.
The four broad categories for the degree of rigor are casual, structured, strict, and quick reaction.
Let us see how these categories impact the adaptation of the CPF.

Adapting the CPF depending on the degree of rigor

There are four broad categories of the degree of rigor that are followed to select a task set. These are:

• Casual: In this category, the minimum tasks are used and documentation requirements are reduced. It is ensured that the basic principles of software engineering are applied.
• Structured: In this category, the tasks necessary to ensure high quality are applied. SQA, SCM, documentation, and measurement are implemented in a streamlined manner.
• Strict: In this category, the tasks are chosen to ensure the degree of discipline required for high quality. Robust documentation is produced.
• Quick reaction: In this category, an emergency-like approach is used and only the tasks that are essential for maintaining good quality are selected. This approach uses 'back-filling' (for example, developing complete documentation and conducting additional reviews) after delivering the product to the customer.

APM: Adaptation criteria

The APM uses ratings for a set of adaptation criteria to determine the recommended degree of rigor. It defines the following adaptation criteria.

• The size of the project
• The number of potential users
• Mission-criticality
• Application longevity
• The stability of the requirements from external customer
• Ease of communication between customers and developers
• The maturity of the applicable technology
• Performance constraints
• Embedded and non-embedded characteristics
• Project staffing
• Interoperability
• Re-engineering factors

Adaptation criteria: Applicability

The adaptation criteria applicable to a project depend on the project type. For example, for a 'concept development' project, the APM suggests using four of the eleven adaptation criteria. These are:

• Ease of communication between the customer and the developer
• Maturity of the applicable technology
• Embedded and non-embedded characteristics
• Project staffing

While adapting the APM, the project type is used to decide the applicable adaptation criteria. These criteria are then graded and given weights to determine the degree of rigor.

Let us see how the applicable adaptation criteria are graded.

Adaptation criteria: Grading

In the APM, each adaptation criterion is assigned a grade that ranges between 1 and 5.
The value, 1, represents a project that requires fewer tasks and in which the overall methodological and documentation requirements are minimal. This implies the lowest degree of rigor required.
The value, 5, represents a project that requires a larger number of tasks and in which the overall methodological and documentation requirements are also substantial. This implies the highest degree of rigor required.
To determine the appropriate grade for each adaptability criterion, a suggested set of project characteristics is provided. It is important to note that there is an overlap between these project characteristics.

An example of grading an adaptation criterion

Let us consider the size of the project as an example of an adaptation criterion.
The size of the project is an adaptation criterion because it impacts the degree of rigor of a project. We can estimate the size of a project in terms of the work units, such as person months, or in terms of product units, such as the number of lines of code (LOC) to be generated.
The given table shows the grades and characteristics of the size of the project used in the APM. The grades range from 1 (requiring the least rigor) to 5 (requiring the highest degree of rigor).

Grade	Characteristics
1	Less than 3 person months and/or 3,000 LOC (30 function points)
2	Between 3 and 9 person months and/or 3,000 and 6,000 LOC (30 to 60 function points)
3	Between 6 and 12 person months and/or 5,000 and 20,000 LOC (50 to 200 function points)
4	Between 9 and 24 person months and/or 10,000 and 30,000 LOC (100 and 300 function points)
5	Between 18 and 48+ person months and over 25,000 LOC (250 function points)

Grades and corresponding characteristics

The tabulation of grades and characteristics of each APM adaptation criterion makes it easy for the project team to determine the grade corresponding to that criterion. Given below is a list of the APM adaptation criteria with their characteristics and the corresponding grades on a scale of 1 to 5.

• The size of the project
• The number of potential users
• Mission-criticality
• Application longevity
• The stability of the requirements from external customer
• Ease of communication between the customer and the developer
• The maturity of the applicable technology
• Performance constraints
• Embedded and non-embedded characteristics
• Project staffing
• Interoperability
• Re-engineering factors

Adaptation criteria: Weights

In addition to providing a grade for each applicable adaptation criterion, a 'weight' is also assigned to each criterion.

The weight provides an indication of the relative importance of the criterion in determining the required degree of rigor. The weight can range from 0.8 to 1.2.

Therefore, the impact of an adaptation criterion on the TSS depends on the following two values.

• Grade (1 to 5, with 1 requiring least rigor and 5 the most)
• Weight (0.8 to 1.2, with 0.8 implying that the criterion is less important and 1.2 implying that it is more important)

Let us now look at the steps involved in the TSS computation.

Adaptation criterion	Grade (1 to 5)	Weight (0.8 to 1.2)
Ease of communication
Maturity of technology
Embedded and non-embedded
Project staffing

Computing the TSS

The APM uses the following steps to compute the TSS and obtain the degree of rigor.

1.     Compute the product of the grade and the weight (grade * weight) for each applicable adaptation criterion.

2.     Compute the TSS as the average of this product for all the adaptation criteria.

Let us now find out how the APM uses this computed TSS value to arrive at a suggested degree of rigor.

Selecting a task set

The selected degree of rigor is used to finally choose the recommended task set. The given table depicts the degree of rigor based on the TSS value.
Note that the range of TSS values corresponding to one degree of rigor overlaps the range for another degree of rigor. This overlap illustrates that sharp boundaries are impossible to define when selecting a task set.
The choice of the recommended task set takes into account the TSS value, past experience, and common sense.

Task set selector value	Task set category
TSS < 1.2	Casual
1.0 < TSS < 3.0	Structured
TSS > 2.4	Strict

Adapting a CPF

The APM implements a CPF to provide a generic process framework and a user-friendly way to adapt it based on the characteristics of a project. It allows users to change the recommended task set.

The organizations that consider using an available implementation of the CPF should ensure that the following are suitable for all its projects.

• The set of framework and umbrella activities
• The collection of task sets described for the framework and umbrella activities
• The method of specifying the project characteristics for adapting the CPF

The adaptation guidelines should be simple and should capture the best practices for using the project characteristics to select the recommended task set. In addition, the CPF implementation should be flexible enough so that project teams can override recommendations and fine-tune the task sets as required.