Modified Waterfall Models

Modified Waterfall Models

Introduction

The subject of software engineering is not simply limited to prolific software development, but is primarily about developing good software by using knowledge of available theories with the help of various defined methods and effective use of tools in hand. There are various software development approaches defined and designed which can be employed during a software development process, these approaches are also referred to as "Software Development Process Models" (Jalote, 13). Each process model follows a particular life cycle in order to ensure success in the process of software development. Subject to endless debate and supported by patient experience, such a methodical approach to software development is aimed towards attaining fewer defects and ultimately shorter delivery times and better value. This paper examines a number of approaches for describing or modeling how software systems are developed. It begins with the definition of a traditional software process model, discusses its phases and further examines the advantages and the limitations inherent in the model. This is followed by a review of the alternative models of software development, which are in fact extensions of traditional software model. Depending on the availability of qualitative research sources, some alternative models have received a more comprehensive evaluation than others. MUST ADD

Background

Explicit models of software evolution date back to the earliest projects developing large software systems in the 1950's and 1960's (Scacchi, 1). As programs became bigger the need for a better requirements phase, more sophisticated thoughts on the design and ampler testing increased. Programmers found it more and more difficult to keep an abstract of the program in their mind and transfer it into code. Overall, the apparent purpose of these early software life cycle models was to provide "a conceptual scheme for rationally managing the development of software systems" (Scacchi, 1). Such a scheme could therefore serve as a basis for planning, organizing, staffing, coordinating, budgeting, and directing software development activities.

The Waterfall Model

One approach that was widely used in the early years of software development was the "Waterfall Model". The model, which follows a sequential and document driven methodology, was first introduced by Winston W. Royce (Jalote, 14). In this model, the whole process of software development is divided into separate non-overlapping phases. To advance from one phase to the next one, the project team is required to review and release an artifact in the form of a document. The release of the corresponding document triggers the end of one phase and the beginning of the next. The total number of phases and their respective names depend on the program at hand and the unique flair that a project team wants to bring in the software development process. For that matter, different textbooks show slightly varying figures of the Waterfall model based on Royce's diagram. In general, however, the model may be considered as having the following key phases (Widrig, 25), described below:

Requirement Analysis & Specification: All possible requirements of the system to be developed are captured in this phase. Requirements are set of functionalities and constraints that the end-user (who will be using the system) expects from the system. The requirements are gathered from the end-user through consultation, these requirements are analyzed for their validity and the possibility of incorporating the requirements in the system to be developed is also studied. Finally, a Requirement Specification document is created which serves the purpose of guideline for the next phase of the model (Jalote, 15).

System & Software Design: Before starting the actual coding, it is highly important to understand what is going to be created and what it should look like? The requirement specifications from first phase are studied in this phase and system and software design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture. The system and software design documents serve as an input for the next phase of the model (Jalote, 15).

Implementation & Unit Testing: On receiving system and software design documents, the work is divided in modules/units and actual coding is started. The system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality; this is referred to as Unit Testing. Unit testing mainly verifies if the modules/units meet their specifications.

Integration & System Testing: As specified above, the system is first divided in