Sunday, 12 June 2011

Iterative risk analysis and planning


In an evolutionary process model, the requirements are not fully known at the beginning. Each iteration redefines the scope of the work and the risks associated with it. Therefore, the project plan for an evolutionary process model evolves as the project proceeds. The plan is prepared at the beginning of the project for the initial iteration. When the requirements are known in greater detail at the end of the iteration, the plan for the next iteration is prepared again. Also, the risks associated with the project keep changing; therefore, planning and risk analysis are repeated for each iteration.
In this model, it is not possible to develop fixed cost estimates and static schedules due to the uncertainties involved. However, the outer bounds to cost estimates and time schedules can be fixed.
The incremental process model
It is important to understand what an incremental process model is before we discuss the spiral process model (an example of the evolutionary model) because the two models are often confused with each other.
The incremental process model is used in situations in which the requirements are reasonably well understood, but it is not feasible to deliver the product within the desired time frame. This could be because of time pressure, limited resources, or other business constraints. It combines elements of linear sequential process model with the iterative philosophy of prototyping process model.
The primary objective of the incremental process model is to deliver various increments of the operational software product to the customer according to a planned set of iterations. Each increment aims to provide some useful functionality to the customer. The first increment is often the core product that addresses the basic requirements. In the subsequent increments, subsystems and other features are added to this core product.
An incremental process model involves the definition of increments and their sequence. Each increment delivers the software with some of the required functionalities. The sequence of the increments depends on the sequence in which the customer requires the functionalities.
The steps of an incremental process model are:
1.     Listen to the customer, and establish an incremental delivery strategy for the software product.
2.     Engineer or build increments of the product based on customer needs (for the increment to be delivered).
3.     Allow the customer to evaluate the increment and obtain feedback.
4.     Modify the existing increment based on customer feedback and specify the requirements for the next increment.
5.     Continue with step 2 to 4 until the final increment is delivered.
An example
Alpha Software Inc. is a software organization that specializes in office software. Based on a market survey, it has decided to develop an integrated voice-based word processor product for computers. The business plan demands early entry into the marketplace, with subsequent versions providing increased functionality and voice accuracy over a period of one year.
In this example, the full requirements of the product are reasonably well understood but the time-to-market pressure demands an early delivery. The approach chosen is, therefore, of an incremental process model. Each 'version' of the word processing software would represent one increment.
The spiral process model
The best-known evolutionary model is the spiral process model, proposed by Dr. Barry Boehm. The model is iterative, starting from the innermost point and proceeding radially outwards, with each circuit (cycle) around the spiral representing an iteration. Moving outwards on the spiral means moving towards more complete versions of the software product.
The set of tasks performed in each iteration is organized into 'task regions'. The spiral process model is divided into four task regions—planning, risk analysis, engineering, and customer evaluation.
Each iteration around the spiral can be considered a mini-project with tasks such as communication, planning, engineering, construction, validation, and customer assessment to be performed. The iteration ends with a decision on whether or not the next iteration should be performed.
The spiral process model: Task regions
The spiral model shown here is a 'first generation' evolutionary model and consists of four task regions. The tasks performed in each task region are as given below.
  • In the planning task region the project plan (tasks, schedules, project framework, etc.) is established and the effort is estimated.
  • In the risk analysis task region the potential risks are identified and analyzed.
  • In the engineering task region the product is built using the required technical activities.
  • In the customer evaluation task region feedback is obtained from the customer on the product, so that appropriate planning for the next iteration can be done.
The spiral process model: The planning task region
Planning is the first task region of the spiral process model. It involves obtaining preliminary information from the customer in the form of fundamental or baseline documentation. Formal meetings with the customer are used to derive the initial requirements. These form the basis for preparing the preliminary project plan, which includes the initial cost and schedule estimates.
A project using a spiral process model involves multiple iterations. The preliminary project plan also includes the projected number of iterations that the project may require.
The spiral process model: The risk analysis task region
The second task region of the spiral process model is the risk analysis task region. In this region, project risks are analyzed in a formal way. Analysis involves identification of the risks and a quantitative assessment of their probability and loss.
Risk analysis provides the information required to decide whether or not to proceed with the project. The risk analysis task region is followed by the 'go/no-go' axis, which is a decision point. If the risks are high, the decision may be 'not to proceed with the project in its current state'. In case of such decisions, the management needs to be involved.
Risk analysis and the subsequent decision on whether or not to proceed with the project are required because of the evolutionary nature of the project. The risks keep changing, and there is a need to understand the risks involved and whether they are worth taking.
The spiral process model: The engineering task region
The third task region of the spiral process model is the engineering task region.
Once the decision is taken to proceed with the project, the work product for the iteration is engineered.
In the engineering task region, activities that are required to build or modify one or more work products that the iteration has to produce are performed. For example, if the iteration has to produce an analysis model, the engineering task region of the iteration would include only analysis. On the other hand, if the end result of the iteration is a prototype, the engineering task region could involve prototyping.
The engineering task region could also incorporate a full life-cycle sequence of analysis-design-code-test and build a software product from a given set of requirements.
The spiral process model: The customer evaluation task region
The fourth task region of the spiral process model is the customer evaluation task region.
In this task region, the customer evaluates the output of the engineering task region and provides the feedback, which is used for planning the next iteration.
Customer involvement is ensured in each iteration of the customer evaluation task region. This provides control to the customer in the direction and implementation of the project. Besides, involvement in each iteration educates the customer and makes communication more effective.
The spiral process model: Steps in an iteration
Each iteration is one circuit around the spiral that results in an end product for evaluation. Every iteration comprises:
  • Planning the iteration, including the estimation of the cost and the schedule. Customer feedback from the previous iteration, if any, is also taken into account
  • Evaluating the risks to arrive at a 'go/no-go' decision
  • Engineering or building the product based on the end product of the iteration
  • Customer evaluating the end product built during the iteration
These iterations continue until either the final product is accepted or it is decided to stop further work on the product.