Common Process Framework

Introduction

Processes form the foundation of software engineering. In order to plan and manage a project, a project manager needs to define a suitable process.
Organizations often execute multiple projects, and each project requires a suitable process definition. Therefore, there is a need for a common process framework (CPF) that defines the broad activities applicable across all projects in an organization.
The CPF provides a standard starting point for a project team to define a project-specific software process. It helps to ensure that the fundamental software engineering activities in a project are always performed.
In this section, you will learn what a CPF is.

Process definition

To build good-quality software products and ensure project success, a process-centric approach should be used for software projects.
The work of a software project is planned and managed based on the process that is defined for the project. This process definition is based on a software process model that provides an abstract strategy for the project.
A process definition acts as a framework for the software project team and provides the tactical information required to complete a project. It also provides the input needed by the project team for planning the project. This input includes details of the tasks to be performed (including the tasks required for producing the output and any related quality assurance activities), the products to be built, and the task responsibilities.

Software process models

Before we discuss the CPF, let us look at the various software process models.

A software process model provides an abstract strategy for a project. It is the basis of the process definition for a project.

There are many available software process models in software engineering. Some of these are given below.

• Linear sequential process model
• Prototyping process model
• Evolutionary process models
• Component-based development model
• Cleanroom software engineering approach
• Agile process models

What do you think the process definition for analysis could involve?
To answer the above question, consider the trigger for the activity, the input required, the individual responsible for the activity, the steps and the sequence involved, the applicable standards for the activities and documentation, the output to be produced, and the 'exit condition'.

One of the possible process definitions for analysis is given below at a broad level.

• Trigger
  - A project is signed off and the project plan is ready.
  - The customer has been identified and is available for consultation.
• Input
  - The project proposal and scope document
  - Correspondence and interviews with the client
  - Supporting literature
  - Competitive product description and/or documentation of any existing system that is being replaced
• Responsible individual
  - The analyst and the customer
• Steps
  - Requirements elicitation
  - Analysis modeling
  - Data modeling
  - Functional modeling
  - Behavioral modeling
  - Model review
• Standards
  - The standard to be followed for the analysis document is IEEE Std. 830-1993.
• Output
  - A documented analysis model
• Exit condition
  - The analysis document is signed off by the customer and checked in to the project configuration library

This definition could be further elaborated to obtain a comprehensive process definition.

The common process framework

Organizations typically execute a number of software projects, and it is necessary to define a process for each project. Establishing a process definition for a project requires time and effort. Therefore, we need a generic process framework that has task sets that suit a wide variety of projects within an organization. The project team can then select the appropriate task sets from this framework and save time and effort.
The common process framework (CPF) is a generic process framework that defines the broad software engineering activities that apply to all projects regardless of the characteristics of the projects. It provides all the tactical information required for executing a project. It acts as a template that guides a software project team in its process definition.
The specific tasks of the CPF are adapted for a project based on the needs of the project, the product, and the team. It is quite flexible and is not a rigid framework

The approach for the CPF

Let us now find out the approach that needs to be followed to establish a CPF in an organization.
Essentially, the CPF should describe a set of activities that will be applicable to all the projects undertaken by the organization. This set of activities is to be performed for any project, large or small, regardless of the time or budgetary pressures. For each activity, the CPF should contain task sets from which appropriate task sets can be selected for individual projects.
The CPF should be such that it can be easily adapted and used for projects. It should provide a foundation for all software engineering work. The fundamental approach is that the CPF should contain what is required for the projects that an organization executes. For this, the CPF should be based on one or more process models that are suitable for the organization.
The CPF must be accompanied by adaptation guidelines for selecting the task sets for a project.

The CPF activities and tasks

A CPF includes two broad sets of activities, framework activities and umbrella activities.
A framework activity is a major software engineering function performed by a project team. The set of framework activities included in a CPF apply to all the projects regardless of the type, duration, or criticality of a project.
Umbrella activities are support activities that span the entire life cycle of a project and are essential for successful project execution.
Let us discuss the two types of activities in detail.

Framework activities

Every project requires some broad software engineering activities to be performed. These activities are called framework activities and apply to all the projects.
However, the tasks that need to be performed for each framework activity differ because of the different scope and characteristics of each project.
A generic set of framework activities that is applicable to the vast majority of software projects is communication, planning, modeling, construction, and deployment.
This set suggests that every project must begin with customer communication. Software engineers must understand the requirements of a customer. Once the requirements are understood, a plan should be established and the associated risks should be assessed. After these activities, an engineering model is prepared. Based on this model, the actual product is built and released to the customer. The customer then evaluates the product and provides feedback to the developer.
This set of framework activities is suitable for developing a wide range of projects—from small and simple programs to large and complex systems.

Accomplishing a framework activity

The framework activities are the same for all the projects. However, depending on the project characteristics, there are many possible ways to accomplish each framework activity.
For example, customer communication can be accomplished with a simple phone call or it may require a series of formal meetings, the creation of a formal requirements specification document, a set of follow-up reviews, and additional requirements elicitation and specification activities.
According to the CPF, the framework activity, 'customer communication', should always be performed. However, the project team can select the task sets that should be performed for the activity.
Let us discuss the other broad set of activities of the CPF—the umbrella activities.

Umbrella activities

Umbrella activities span the entire project. They can be viewed as the 'background tasks' that are ongoing throughout the project. Umbrella activities are essential because they provide a strong base for other software engineering activities. Some examples of umbrella activities are as given below.

• Software project management (SPM)
• Formal technical reviews (FTR)
• Software quality assurance (SQA)
• Software configuration management (SCM)
• Documentation preparation and production
• Reusability management
• Measurement
• Risk management

Although projects may differ in the tasks performed for an umbrella activity, all the umbrella activities need to be performed for each project.