Turn Desktop View Off
by Dinesh Thakur

A process model can be defined as a strategy (also known as software engineering paradigm), comprising process, methods, and tools layers as well as the generalphases for developing the software. It provides a basisfor controlling various activities required to develop and maintain the software. Inaddition, it helps the software development team in facilitating and understandingthe activities involved in the project.

                      Classical Life Cycle Model

A process model for software engineering depends on the nature and application of the software project. Thus, it is essential to define process models for each software project. IEEE defines a process model as 'a framework containing the processes, activities, and tasks involved in the development, operation, and maintenance of a software product, spanning the life of the system from the definition of its requirements to the termination of its use.' A process model reflects the' goals of software development such as developing a high quality product and meeting the schedule on time. In addition, it provides a flexible framework for enhancing the processes. Other advantages of the software process model are listed below.


Enables effective communication: It enhances understanding and provides a specific basis for process execution.

Facilitates process reuse: Process development is a time consuming and expensive activity. Thus, the software development team utilizes the existing processes for different projects.

Effective: Since process models can be used again and again; reusable processes provide all effective means for implementing processes for software development.

Facilitates process management: Process models provide a framework for defining process status criteria and measures for software development. Thus, effective management is essential to provide a clear description of the plans for the software project.

Every software development process model takes requirements as input and delivers products as output. However, a process should detect defects in the phases in which they occur. This requires Verification and Validation (V&V) of the products after each and every phase of the software development life cycle.

Verification is the process of evaluating a system or its components for determining the product developed at the end of each phase of the software development. IEEE defines verification as 'a process for determining whether the software products of an activity fulfill the requirements or conditions imposed on them in the previous activities.' Thus, verification confirms that the product is transformed from one form to another as intended and with sufficient accuracy.

Validation is the process of evaluating the product at the end of each phase to check whether the requirements are fulfilled. In addition, it is the process of establishing a procedure and method, which provides the intended outputs. IEEE defines validation as 'a process for determining whether the requirements and the final, as-built system or software product fulfils its specific intended use.' Thus, validation substantiates the software functions with sufficient accuracy with respect to its requirements specification.

Various kinds of process models are waterfall model, prototyping model, spiral model, incremental model, time-boxing model, RAD model, V model, build and fix model, and formal method model.

Waterfall Model

In the waterfall model (also known as the classical life cycle model), the development of software proceeds linearly and sequentially from requirement analysis to design, coding, testing, integration, implementation, and maintenance. Thus, this model is also known as the linear sequential model.

This model is simple to understand and represents processes which are easy to manage and measure. The waterfall model comprises different phases and each phase has its distinct goal. After the completion of one phase, the development of software moves to the next phase. Each phase modifies the intermediate product to develop a new product as an output. The new product becomes the input of the next process. Table lists the inputs and outputs of each phase of waterfall model.

                 Table Inputs and Outputs of each Phase of Waterfall Model

 

Input to phase

Process/Phase

Output of the phase

Requirements defined through communication

Requirements analysis

Software requirements specification document

Software requirements specification document

Design

Design specification document

Design specification document

Coding

Executable software modules

Executable software modules

Testing

Integrated product

Integrated product

Implementation

Delivered software

Delivered software

Maintenance

Changed requirements

 

As stated earlier, the waterfall model comprises several phases, which are listed below.

 

System/information engineering modeling: This phase establishes the requirements for all parts of the system. Software being a part of the larger system, a subset of these requirements is allocated to it. This system view is necessary when software interacts with other parts of the system including hardware, databases, and people. System engineering includes collecting requirements at the system level while information engineering includes collecting requirements at a level where all decisions regarding business strategies are taken.

Requirements analysis: This phase focuses on the requirements of the software to be developed. It determines the processes that are to be incorporated during the development of the software. To specify the requirements, users' specifications should be clearly understood and their requirements be analyzed. This phase involves interaction between the users and the software engineers and produces a document known as Software Requirements Specification (SRS).

Design: This phase determines the detailed process of developing the software after the requirements have been analyzed. It utilizes software requirements defined by the user and translates them into software representation. In this phase, the emphasis is on finding solutions to the problems defined in the requirements analysis phase. The software engineer is mainly concerned with the data structure, algorithmic detail and interface representations.

Coding: This phase emphasizes translation of design into a programming language using the coding style and guidelines. The programs created should be easy to read and understand. All the programs written are documented according to the specification.

Testing: This phase ensures that the software is developed as per the user's requirements. Testing is done to check that the software is running efficiently and with minimum errors. It focuses on the internal logic and external functions of the software and ensures that all the statements have been exercised (tested). Note that testing is a multistage activity, which emphasizes verification and validation of the software.

Implementation and maintenance: This phase delivers fully functioning operational software to the user. Once the software is accepted and deployed at the user's end, various changes occur due to changes in the external environment (these include-upgrading a new operating system or addition of a new peripheral device).The changes also occur due to changing requirements of the user and changes occurring in the field of technology. This phase focuses on modifying software, correcting errors, and improving the performance of the software.

Various advantages and disadvantages associated with the waterfall model are listed in Table.

 

                Table Advantages and Disadvantages of Waterfall Model

 

Advantages

Disadvantages

  • Relatively simple to understand
  • Each phase of development proceeds sequentially.
  • Allows managerial control where a schedule with deadlines is set for each stage of development.
  • Helps in controlling schedules, budgets, and documentation.
  • Requirements need to be specified before the development proceeds.
  • The changes of requirements in later phases of the waterfall model cannot be done. This implies that once the software enters the testing phase, it becomes difficult to incorporate changes at such a late phase.
  • No user involvement and working version of the software is available when the software is being developed.
  • Does not involve risk management.
  • Assumes that requirements are stable and are frozen across the project span.