A CPF activity: Actions and task sets

A framework or an umbrella activity is composed of one or more actions. The actions collectively address the requirements of the activity.

In the CPF, each action, in turn, is represented by a number of task sets. Each task set is a collection of tasks to be performed, the work products to be built, and the quality assurance (QA) checkpoints and project milestones to be achieved.
For example, consider the framework activity, 'modeling'. This activity consists of two software engineering actions-analysis and design. In analysis, an analysis model is produced, and in design, a design model and/or the design document is produced.
Let us look at the description of a task set in detail.

The CPF: Task sets

For each action, a suitable task set has to be performed. Although many task sets may be defined for an action, the project team selects the most suitable task set for a project.

A task set is described in terms of the following.

• The tasks to be performed
• The work products to be built
• The QA checkpoints to be achieved
• The project milestones to be achieved

For each action, the CPF should include a description of the task sets that caters to all types of projects that will use the CPF.

Adaptation guidelines

The selection of a task set described in the CPF depends on factors such as the complexity, size, and criticality of a project and the project schedule.
For the ease of adaptation, it is necessary to provide the adaptation guidelines with the CPF.
To understand the need for the adaptation guidelines, let us look at an example to see how the selection of a task set varies depending on the project characteristics.

Selection of a task set: An example

Consider a project in which one week of effort is budgeted for providing a function that will compute the shipping charges for an e-commerce Web site based on a customer's shipment choices. There is just one action (customer communication) for the 'customer communication' framework activity in this situation. The task set that may be required for the customer communication action is:

• Review the customer request
• Develop an issues list that identifies ambiguities, areas of clarification, and potential omissions
• Contact the customer via phone or e-mail
• Present an issues list and obtain clarifications
• Develop a paper or electronic prototype to provide the look and feel for the necessary data entry and result
• Get customer approval

All the above steps may be performed in a day.

Adapting the CPF

In the preceding pages, we discussed two types of projects. The action, 'customer communication', was applicable to both the projects, but the task set for it was different.
A CPF is generic because it contains all the task sets that may be required, given the range of projects that may use it. It is, therefore, like a superset of task sets. For example, for an organization that executes projects of both the simple and complex type, we would expect the task sets for both types of projects to be available in the CPF.
To effectively derive the benefit of the CPF, a project team should be able to adapt the CPF suitably for its project. The CPF should, therefore, be accompanied by the adaptation guidelines that will be used to select the task sets for each framework and umbrella activity.
In fact, the adaptation guidelines should be established along with the CPF.

Objective of the adaptation guidelines

Adaptation guidelines provide a mechanism for identifying the relevant project characteristics and selecting suitable task sets. They specify what can be changed and what is mandatory for all the projects. The adaptation guidelines are developed based on the characteristics of the projects for which they may be used.
Without the adaptation guidelines, the project team may miss out some important task sets or select task sets that do not ensure basic software engineering discipline or quality. In fact, without adaptation guidelines, project teams may consider the CPF too generic and impractical and never use it.
Adaptation guidelines save time and make adaptation simpler.

Selecting task sets

Although all the framework and umbrella activities apply for all the projects, the task sets within them are selected based on the project characteristics. The adaptation guidelines are used to assist in this selection. Let us see what the adaptation of the CPF involves.
For each activity, the actions applicable for the project are identified. It is possible that some actions defined for an activity are not required for a project. For example, the framework activity, modeling, may include two actions—'analysis' and 'design'. It is possible that this activity requires only analysis and design is not in the scope of the project.
For each applicable action, the most suitable task set is selected from the multiple task sets provided in the CPF.
Of course, the project team may add, change, or remove tasks from the task sets selected using the adaptation guidelines.

Benefits of using the CPF

Using the CPF, the project team constructs a process definition for a project by selecting appropriate task sets. If there were no CPF, the team would have to identify and define each task required to complete the project. The CPF, therefore, helps a project team to avoid 'reinventing the wheel' when it plans for the project.
A CPF provides a generic process framework and defines all the fundamental software engineering activities. By using the CPF as a basis for process definition, we ensure that the fundamental software engineering activities are always performed. The tasks performed for these activities are adapted to the needs of the project, the product, and the team.
The activities defined in the CPF capture the best practices suited to an organization. It is, therefore, a means of ensuring the availability of these best practices and encouraging their use within an organization.

The degree of detail in the CPF

To be useful, the CPF should be practical and suitable for both managers and engineers. It should be flexible enough so that the project teams can adapt and use it.
In the early days of software engineering work, the complete CPF spanned hundreds of written pages and was put in large binders. It often remained unused because it was simply too cumbersome, large, and bureaucratic to be used. Today, we recognize that a leaner approach for the CPF is better.
To assist adaptation, modern implementations of the CPF provide a menu-driven approach for teams to select suitable task sets and further allow fine-tuning of the selected task sets. The CPF ensures basic software engineering discipline and provides the project teams with the freedom to define the process in a way that best meets their needs, while not forgetting their responsibility to build high-quality products.