Download Free Templates Websites Templates




Software Life Cycle Models



Because software engineering is still maturing, many different paradigms have been proposed, each of which is designed to support a different perspective of software development. A software engineering paradigm provides a framework through which a software project can be effectively managed. A paradigm defines the specific technical steps that should be conducted, and by implication, the milestones that should be achieved, and the deliverables to be produced. In essence, a paradigm provides a basis for the creation of a work break down structure (WBS) for software engineering.


1.2 Waterfall Model


The oldest paradigm for software engineering is the classic waterfall model. This Paradigm takes a linear, sequential view of the software engineering process.























Waterfall Model


            The process begins at the system level and continues through the maintenance level until product retirement. Each box encompasses a set of tasks that result in the production of one or more work products. Time is tracked from left to right and from top to bottom. Each new phase begins when the work products of the previous phase are completed, frozen, and signed off. For example, the code phase will begin when the design phase is completed and it will end when the coding is completed and before testing begins. The actual names and numbers of phases often vary from project to project. The major features of the waterfall chart are the following:


1- System Engineering


            Because software is usually part of a larger system, work begins by establishing requirements for system elements and then allocating some subset of these requirements to software. System engineering and analysis encompasses requirements gathering at a system level with a small amount of top-level design and analysis


2- Analysis


In this phase, the requirements gathering process is intensified and focused specifically on software. To understand the nature of the programs to be built, the software engineer (or analyst) must understand this information domain for the software, as well as the required function, behavior, performance, and interfacing characteristics.


3- Design


            Software design is actually a multi-step process that focuses on three distinct attributes of the program:


  • Data structures.

  • Software architecture.

  • Procedural details.


            The design process translates requirements into a representation of the software. This representation can be assessed for quality, for example, through the inspection and / or review processes and placed under configuration control before coding begins.


4- Coding


            The design must be translated into code readable form. The coding step performs this task. Code is verified, for example, through the inspection process and put under configuration management control prior to the formal testing phase.


5- Testing


            Once code has been generated, program testing begins. Testing focuses on the logical internals of the software, ensuring that all statements have been tested, and on the functional externals; that is, conducting tests to uncover errors to ensure that the defined input will be produce.



6- Maintenance


Software will undoubtedly undergo changes after it has been delivered to the customer (a possible exception is embedded software). Change will occur because errors have been encountered and new functionality is required. Software maintenance reapplies each of the preceding life cycle steps to an existing program, rather than new one.


Waterfall Model Advantages/Disadvantages


            The classic waterfall model has an important place in software engineering. Although it is rarely practiced in pure form, it provides a template into which methods, for analysis, design, coding, testing, and maintenance, can be placed. Other life cycle models refer to the phases and tasks of the waterfall model for definitions and reference. Disadvantages of the sequential waterfall approach are:


  • Real projects rarely follow this sequential flow. In real life, iterations occur which create problems in application of the paradigm. For example, a design problem discovered during testing would require moving the entire project back into the design phase until the design is corrected and signed off. At that time, the project would reenter the coding phase until all the program changes implied by the design changes are completed and signed off. Then the project could begin a new testing phase.


  • It is often difficult for customers to explicitly state the requirements. In commercial software development, it may be impossible to know the requirements until the customers have a chance to actually use the product

  • A working version of the software is not available until late in the project. A major defect, if undetected until system test, will cause loss and delays in the project.


1.2 Prototyping


                        Prototyping is a process that enables the developer to create a model of the software that is built in an evolutionary manner.



























Prototyping Approach



                  There are two versions of a prototyping approach that differ primarily in the full-scale development phase. Like all approaches to software development, both prototyping models begin with requirements gathering. The developer and customer meet and define the overall requirements. A quick design occurs and focuses on those aspects of the system that will be visible to the user (e.g., input approaches and output formats). A prototype (or mockup) is created based on the design to provide the external behaviors that the user will see.


                  The prototype may either be built on the target environment or on a convenient platform. Either way, the prototype is evaluated by the customer/ user and is used to refine the requirements. A process of tuning iterations occurs; allowing customer/ user and the software developer to better understand and improve the requirements. The two prototyping approaches diverge substantially when the customer is satisfied.


                  If the prototype is built on the target platform, the prototyping naturally progresses until the prototype becomes complete enough that the user can begin using it. Additional work is usually required to stabilize and complete the product but the prototyping approach continues until the product is complete.


                  If the prototype is built on a convenient platform, other than the one the system will be deployed upon, the accepted prototype becomes the specification of the system. Full-scale development is launched (typically using a Waterfall approach for design, implementation, and deployment) using the prototype as a detailed specification.


                  The advantages of the prototyping approach are that it provides a mechanism for identifying requirements, and facilitating buy-in and agreement on requirements with the customer and / or end-user.


                  The disadvantages are that continued change tends to corrupt the software structure and that existence of a prototype may provide false impressions to the customer of the availability of functionality. Also, the developer may make implementation compromises, such as using an inappropriate operating system for the sake of expediency. There may be pressures to make a less than ideal design decision part of the final product. The customer and developer may spend too much time tuning and never get to the real development of the system.


1.3 Spiral Model


                  The spiral model is another type of evolutionary model. It has been developed to provide the best feature of both the classic life cycle approach and prototyping, while at the same time, adding another element-risk analysis-which is missing from each of these paradigms. The model, represented by the four quadrants of the Figure:


  1. Planning – Determination of objectives, alternatives, and constraints.


  1. Risk analysis – Analysis of alternatives as well as an identification and / or resolution of risks.


  1. Engineering – Development of the next level of product.


  1. Customer evaluation –Assessment of the results of engineering.


Text Box: Planning Text Box: Risk analysis
Text Box: Customer Evaluation






                  With each iteration around the spiral (beginning at the center and working out), progressively more complete versions of the software are built. The following example illustrates one of the many approaches that may be used in implementing the spiral model.


                  During the first circuit around the spiral, if the results of risks analysis indicate that there is uncertainty in the requirements; prototyping may be used in the engineering quadrant to assist both the developer and the customer. The customer then evaluates the engineering work (customer evaluation quadrant) and makes suggestions for modifications. On the basis of the customer input, the next phase of planning and risk analysis occurs. At each loop around the spiral, the culmination of the risk analysis results in a go/ no-go decision. If risks are too great, the project can be terminated.


                  In most cases, however, flow around the spiral path continues, with each path moving the developer toward a more complete version of the system. Every circuit around the spiral requires engineering (lower right quadrant) that can be accomplished, using, for example, the Waterfall or prototype approach. It should be noted, that the number of development activities occurring in the lower right quadrant increase as the activities move further from the center of the spiral.


                  The spiral model enables the developer, and the customer, to understand and react to risks at each evolutionary level. Prototyping may be used as a risk reduction mechanism at any stage in the evolution of the product. The major advantage of the spiral model is that it maintains the systematic approach of the Waterfall model but incorporates an iterative framework that more realistically reflects the real world of development. If properly applied, the spiral model should reduce design risks.



1.4 Incremental Development Model


                  An incremental approach is commonly applied as a technique to break a large programming effort into smaller, more manageable components. Each component is developed in isolation from the rest (for practical purposes), and integration of the components is postponed until they are complete. Any life cycle can be used for the individual component development.


                  The incremental approach allows specialists to focus on one part of the life cycle (e.g., design) to best leverage their expertise by repeatedly performing their tasks on a series of small components. It also allows for early creation of components whose requirements are understood, while postponing those requiring more investigation. The approach requires good coordination between components for successful integration, and risks the necessity of redesign of completed components if there is a late discovery of dependencies of requirements. It also increases project management requirements, as each increment needs to be managed

























The Incremental Model



1.5 V-Model


            The software engineering process may be viewed as a Waterfall series of phases drawn in the form of a "V” as illustrated in the following figure. This model is called the V-Model or Decomposition /Integration Model. Time progression is from left to right, and the project components become more and more specific and granular as a project moves down the left side of the "V." The components are integrated to form larger and larger components moving up on the right side of the "V." The usefulness of the model comes from the observation that the information needed for testing components on the right is primarily from the corresponding phase on the left. For example, the requirements are the basis for identifying the design of the validation tests.


System Engineering










Adapted from Pressman (1992)33


            The primary drawback to the V-Model is that we do much better testing planning and test generation if we do not limit ourselves to documents and knowledge from only one particular phase. Integration and validation testing can usually be substantially improved by considering requirements and design.


1.6 Object-Oriented Development


            The Object-Oriented (OO) development approach can be used in the context of any of the above paradigms. However, a paradigm that explicitly addresses the OO method and incorporates the notion of software component reuse has been developed.


            Like other process models, the OO paradigm begins with requirements gathering. Once the overall objectives for the software are defined, inclusive of functional, behavioral, and known data requirements, Object-Oriented Analysis (OOA) begins. OOA is an activity in which classes and objects are extracted from the initial statement of the requirements. Then Object-Oriented Design (OOD) is used to create a model to each of the program components known objects. The mechanism for communication between objects is also considered .OOA and OOD occur interactively until a reasonable design for the system has been derived.


Once the design model has been created, the software engineer browses a library, or repository, that contains existing program components to determine if any of the components can be used in the design at hand. If reusable components are found, they are used as building blocks to construct a prototype of the software as illustrated in Figure 5.6.It is important to notice that Object-Oriented (OO) methods result in the creation of program components are inherently reusable. Therefore, the design and implementation steps result in the creation of other reusable components from the originals. Over time, the size of the component library grows, and the need to enter the design and implementation step is reduced.
























Implementation life cycle model


Maintenance life cycle model


Rounded Rectangle: Change requests and Bugs gathering                       











































Listed below is a comparison of the relative strengths and weaknesses of the major software engineering life cycle models.






·         This is the classic model used as a point of comparison for software life cycles.

·         Gains user buy –in with each phase signs-off.

·         Provides concrete, testable requirements and specifications.

·       Requires user to know their requirements seldom used in its pure form.

·       Requirement changes can have significant negative impacts.

·       Working software is not available until very late in the project.


·         Can effectively elicit user requirements.

·         Gains user buy-in through their direct participation.

·       Continued change reduce quality

·       User may believe that the mockup is fully functional.

·       Developers may make unwise compromises for expediency.

·       Can lead to analysis paralysis-never gaining agreement or closure.


·         Identifies and reduces risks

·         Combines strengths of waterfall and prototyping while capping the number of iterations

·         Can elicit requirements from users

·         Gains user buy-in through their direct participation

·       Continued change reduce quality

·       Customer may not accept the model is controllable

·       Project scope, cost, and schedule can significantly change with each cycle

·       Good understanding of risk assessment is required


·         Breaks large project into more manageable components.

·         Allows early start for some components and specifications that are ready for all of them.

·         Allows developers to specialize more effectively

·       Requires good coordination between components of integration.

·       Late discovery of some dependencies or requirements can lead to redesign of completed components.

·       Increases project management requirements.


·       Based on the Waterfall and is familiar.

·       Emphasizes test planning in early project phases.

·       Conceptually straightforward.

·       Requires users to know their requirements.

·       Requirement changes can have significant negative impacts.

·       Working software is not available until very late in the project.

·       The documents and knowledge from only one particular phase may limit test planning and test generation.


·       Designed for reuse of components.

·       Powerful for data modeling capabilities.

·       Large component libraries are difficult to manage


Hybrid models

·       Can pick the best, most useful aspects of life cycles.

·       Can fit the project exactly.

·       Analysis of project requirements needed before project get underway.

·       Requires knowledge of all models and their strengths and weaknesses.




Quality Management System (QMS)