Process Models (Part 2 )

Process Assessment and Improvement

The existence of a software process is no guarantee that software will be delivered on time, that it will meet the customer’s need, or that it will exhibit the technical characteristics that will lead to long term quality characteristics. Process patterns must be coupled with solid software engineering practice. Assessment attempts to understand the current state of the software process with the intent of improving it. A number of different approaches to software process assessment and improvement have been proposed over the past few decades:

·         Standard CMMI Assessment Method for process Improvement SCAMPI

·         CMM-Based Appraisal for Internal Process Improvement (CBA IPI)

·         SPICE (ISO/IEC15504)

·         ISO 9001-2000 for software

Perspective Process Model

Prescriptive process models define a prescribed set of process elements and a predictable process work flow. Each process model prescribes a set of process elements – framework activities, software engineering action, tasks, work products, quality assurance and change control mechanisms for each product. Each process model also prescribes a process flow that is manner in which the process elements are interrelated to one another. All software process models can accommodate the generic framework activities but each applies a different emphasis to these activities and defines a process flow that invokes each framework activity in a different manner.

Waterfall Model

There are times when the requirements for a problem are well understood, when work flows communication through deployment in a reasonably linear fashion. This situation is sometimes encountered when well defined adaptation or enhancement to an existing system must be made (e.g., an adaptation to accounting software that has been mandated because of changes to government regulations). It may also occur in a limited number of new development efforts, but only when requirements are well defined and reasonably stable. The waterfall model, sometimes called the classic life cycle, suggests a systematic, sequential approach to software development that begin with customer specification of requirements and progresses through planning, modeling, construction and deployment, culminating in ongoing support of the completed software.

Problems with Waterfall Model

Real projects rarely follow the sequential flow that the model proposes. It is often difficult for the customer to state all requirements explicitly. The waterfall model requires this and has difficulty accommodating the natural uncertainty that exists at the beginning of many projects. The customer must have patience. A working version of the program will not be available until late in the project time span. A major blunder, if undetected until the working program is reviewed, can be disastrous.

The V Model

A variation in the representation of the waterfall model is called the V model. As a software team moves down the left side of the V, basic problem requirements are refined into progressively more detailed and technical representations of the problem and its solution. One code has been generated, the team moves up the right side of the V, essentially performing a series of tests that  validate each of the models created as the team moved down the left side. In reality, there is no fundamental difference between the classic life cycle and the V-model.

Incremental Process Models

The incremental model delivers a series of release, called increments, that provide progressively more functionality for the customer as each increment is delivered. The incremental model combines elements of linear and parallel process flows. When an incremental model is used, the first increment is often a core product. The basic requirements are addressed but many supplementary features (some known, others unknown) remain undelivered. The core product is used by the customer or undergoes detailed evaluation. As a result of use and/or evaluation, a plan is developed for the next increment. This process is repeated following the delivery of each increment, until the complete product is produced.

Evolutionary Process Models

Software like all complex systems, evolves over a period of time. Business and product requirements often change as development proceeds making a straight line path to an end product unrealistic. Evolutionary models iterative. They are characterized in a manner that enables you to develop increasingly more complete versions of the software. Prototyping, The spiral model.

Prototyping

Often, a customer defines a set of general objectives for software, but does not identify detailed requirements for functions and features. In other cases, the developer may be unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form that human machine interaction should take. In such similar cases we use prototyping paradigm. Although prototyping can be used as a stand alone process model, it is more commonly used as a technique that can be implemented within the context of any other process model. The prototyping paradigm assists you and other stakeholders to better understand what is to be built when requirements are fuzzy. Prototype is built to serve as a mechanism for defining requirements. It is then discarded (at least in part) and the actual software is engineered with an eye toward quality.

The Spiral Model

The spiral model is evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model. Using the spiral model, software is developed in a series of evolutionary release. During early iterations, the release might be a model or prototype. During later iterations, increasingly more complete versions of the engineered system are produced. The spiral model is realistic approach to the development of large scale systems and software. Because software evolves as the process progresses, the developer and customer better understand and react to risks at each evolutionary level. The spiral model uses prototyping as a risk reduction mechanism but more important enables you to apply the prototyping approach at any stage in the evolution of the product.