Software Development Life Cycles

Waterfall Model :


Refer to site - All about Waterfall Model for more information


The waterfall model is a model which was developed for software development; that is to create software. It is called as such because the model develops systematically from one phase to other in a downward fashion, like a waterfall.

The most probable phases through which it progresses downwards are

•           Definition Study/Analysis
•           Basic Design
•           Technical Design/Detailed Design
•           Construction
•           Testing
•           Integration
•           Management and
•           Maintenance.

Waterfall Model

Waterfall Model

Before the advent of this method, the software development in the computer companies suffered from a haphazard integrated software network like cluttered knitting. However with this method they hoped to bring clarity in their projects.


About the Phases


As said earlier the waterfall model has been structured on multiple phases especially to help out the software construction companies to develop an organized system of construction. By following this method, the project will be divided into many stages thus easing out the whole process. For example you start with Phase I and according to this model, one only progresses to the next Phase once the previous one has been completed. This way one moves progressively to the final stage and once that point is reached, you cannot turn back; similar to the water in a waterfall.


Brief Description of the Phases of Waterfall Model


Definition Study / Analysis: During this phase research is being conducted which includes brainstorming about the software, what it is going to be and what purpose is it going to fulfill.

Basic Design: If the first phase gets successfully completed and a well thought out plan for the software development has been laid then the next step involves formulating the basic design of the software on paper.

Technical Design / Detail Design:  After the basic design gets approved, then a more elaborated technical design can be planned. Here the functions of each of the part are decided and the engineering units are placed for example modules, programs etc.

Construction / Implementation: In this phase the source code of the programs is written.

Testing: At this phase, the whole design and its construction is put under a test to check its functionality. If there are any errors then they will surface at this point of the process.


Integration: in the phase of Integration, the company puts it in use after the system has been successfully tested.


Management and Maintenance: Maintenance and management is needed to ensure that the system will continue to perform as desired.

Through the above mentioned steps it is clearly shown that the Waterfall model was meant to function in a systematic way that takes the production of the software from the basic step going downwards towards detailing just like a Waterfall which begins at the top of the cliff and goes downwards but not backwards.


History of the Waterfall Model


The history of the Waterfall model is somewhat disrupted. It is often said or believed that the model was first put forth by Winston Royce in 1970 in one of his articles; whereas he did not even used the word “waterfall.” In fact Royce later presented this model to depict a failure or a flaw in a non-working model. So later on, this term was mostly used in writing about something that is often wrongly done in the process of software development – like a common malpractice.


Royce was more of the opinion that a successful model should have the allowance of repetition or to go back and forth between phases which the waterfall model does not do. He examined the first draft of this model and documented that a recurrent method should be developed in this model. He felt the need of progressing only after a feedback from the previous stage has been received. This is known as the Iterative model.

As opposed to the Waterfall model, the Iterative model is more practical and has room for maneuver. Followers of the Iterative method perceive the Waterfall model as inappropriate.


Advantages of the Waterfall Model


Let’s look at some of the advantages of this model,
•   The project requires the fulfillment of one phase, before proceeding to the next. Therefore if there is a fault in this software it will be detected during one of the initial phases and will be sealed off for correction.

•   A lot of emphasis is laid on paperwork in this method as compared to the newer methods. When new workers enter the project, it is easier for them to carry on the work from where it had been left. The newer methods don’t document their developmental process which makes it difficult for a newer member of the team to understand what step is going to follow next. The Waterfall Model is a straight forward method and lets one know easily what stage is in progress.

•  The Waterfall method is also well known amongst the software developers therefore it is easy to use. It is easier to develop various software through this method in short span of time.


Disadvantages of the Waterfall Model


There are many disadvantages to the model as well. Let’s have a look at those,


Many software projects are dependent upon external factors; out of which the client for which the software is being designed is the biggest factor. It happens a lot of times, that the client changes the requirement of the project, thereby influencing an alteration in the normal plan of construction and hence the functionality as well. The Waterfall Model doesn’t work well in a situation like this as it assumes no alteration to occur once the process has started according to plan.


If, for instance, this happens in a Waterfall Model, then a number of steps would go to waste, and there would arise a need to start everything all over again. Of course this also brings about the aspect of time and money which will all go to waste. Therefore this method will not at all prove to be cost effective. It is not even easy to take out the cost estimate of each step, as each of the phases is quite big.


There are many other software developmental models which include many of the same aspects of the Waterfall model. But unlike the Waterfall model, these methods are not largely affected by the outside sources. In the waterfall model, there are many different people working in the different phases of the project like the designers and builders and each carries his own opinion regarding his area of expertise. The design, therefore, is bound to be influenced; however in the Waterfall model, there is no room for that.


•   The other negative aspect of this model is that a huge amount of time is also wasted. For example if we study any software development process, we know that Phase II

cannot be executed until Phase I has been successfully completed; so while the designers

are still designing the software, time of the builders is completely wasted.

•  Another disadvantage of this method is that the testing period comes quite late in the developmental process; whereas in various other developmental programs the designs would be tested a lot sooner to find the flaw at a time when a lot of time and money has not been wasted.

•   Elaborate documentation during the Waterfall method has its advantages, but it is not without the disadvantages as well. It takes a lot of effort and time, which is why it is not suitable for smaller projects.


Modified Waterfall Models


Due to the various disadvantages a lot of other modified versions of this model have also been put forth and some of these are mentioned below

Royce Model

Although not documented as the “Waterfall Model,” Winston W. Royce is credited with the first formal description of what we no know as the Waterfall Model in 1970. In his original definition, the model consisted of the following steps:  Requirements specification, Design, Construction (or coding in today’s terms), integration, testing and debugging, installation, and maintenance.


Sashimi Model

Sashimi is a true modified version of the Waterfall model. The phases are somewhat the same as in the Waterfall Model; only this time the phases are overlapping each other which present many advantages. For example the time won’t be wasted because before Phase I would be completed, Phase II would already be underway. Moreover, since they overlap, so one can return to the previous step if desired.


Aorta Lifecycle Model
The difference in this model is that they rely a lot on the feedback which comes from other phases before progressing onto the next.


 V Waterfall Model
The V Waterfall Model relies on a linear software developmental program which stresses on balanced development more than anything else. 



V Model :


refer to site - All about Waterfall Model for more information


The V model is a modified version of the Waterfall method. As opposed to the Waterfall method, this one was not designed in a linear axis; instead the stages turn back upwards after the coding phase is done so that it makes a V shape and hence the name – V Model. It was put forth by Paul E. Brook in 1986. Let’s look at the different stages, test processes, techniques, advantages and disadvantages of this method.


About The Cyclic Phases


The V Model is in contrast to the Waterfall method in more than one way. This developmental process is balanced and relies on the verification from the previous steps before proceeding forward. So the cycle of the model has been divided into several phases and each one is supposed to yield a predefined product.


When the product from one phase has reached completion, it will then form the basis for the next phase. This signifies the importance of verification in this model. Similar to the waterfall model, one progresses to the next step when the previous one has been completed. However in the V Model, the product from every phase needs to be checked and approved before moving forward.


This way of verification continues for all the stages and with subsequent phases, one receives a new base of an approved product which instills more confident in the project.



The Various Stages of the V model


V Model Software Engineering Model


1. Requirement Analysis

This is the first step in the verification process. It is in here that the project and its function is decided. So a lot of brainstorming and documentation reveals what all will be required to produce that program or product. During this stage the employees are not going to discuss how it is going to be built; it is going to be a generalized discussion and a user requirement document is put forth. This document will carry information regarding the function of the system, performance, security, data, interface etc.

This document is required by the business analysts to convey the function of the system to the users. So it will merely be a guideline.


2. System Design

Like the name of the phase suggests, here the possible design of the product is formulated. It is formulated after keeping in mind the requirement notes. While following the documents, if there is something that doesn’t fit right in the design, then the user is made aware of it and changes are accordingly planned. Diagrams and data dictionary is also produced here.


3. Architecture Design

The architecture design, also known as the computer architecture design or the software design should realize the modules and the functionality of the modules which have to be incorporated.


4. Module Design

In the module design, the architectural design is again broken up into sub units so that they can be studied and explained separately. The units are called modules. The modules can separately be decoded by the programmer.



The Validation Phases of the V model


1. Unit Testing

A unit in the programming system is the smallest part which can be tested. In this phase each of these units are tested.


2. Integration Testing or Interface Testing

In this phase the separate entities will be tested together to find out the flaws in the interfaces.


3. System Testing

After the previous stage of interface testing, in this phase it is checked if the system meets the requirements that have been specified for this integrated product.


4. Acceptance Testing

In the acceptance test, the integrated product is put against the requirement documents to see if it fulfills all the requirements.


5. Release Testing

It is in here that judgment has to be made if the product or software which is created is suitable for the organization.


Advantages of the V Model

  • The biggest advantage of using the V Model is that unlike the Waterfall model and the aorta life cycle method, every stage is tested.


Disadvantages of the V Model

  • It assumes that the requirements do not change.

  • The design is not authenticated.

  • The Requirements are not verified.

  • At each stage there is a potential of errors. The first testing is done after the design of modules which is very late and costs a lot. 


Spiral Model :


The spiral model is similar to the incremental model, with more emphasis placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral. Requirements are gathered during the planning phase.  In the risk analysis phase, a process is undertaken to identify risk and alternate solutions.  A prototype is produced at the end of the risk analysis phase.


Software is produced in the engineering phase, along with testing at the end of the phase.  The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.


Diagram of Spiral model:


Spiral model

Advantages of Spiral model:

  • High amount of risk analysis hence, avoidance of Risk is enhanced.

  • Good for large and mission-critical projects.

  • Strong approval and documentation control.

  • Additional Functionality can be added at a later date.

  • Software is produced early in the software life cycle.

Disadvantages of Spiral model:

  • Can be a costly model to use.

  • Risk analysis requires highly specific expertise.

  • Project’s success is highly dependent on the risk analysis phase.

  • Doesn’t work well for smaller projects.

When to use Spiral model:

  • When costs and risk evaluation is important

  • For medium to high-risk projects

  • Long-term project commitment unwise because of potential changes to economic priorities

  • Users are unsure of their needs

  • Requirements are complex

  • New product line

  • Significant changes are expected (research and exploration)


Agile Methodology

What Is Agile?


The Agile movement proposes alternatives to traditional project management. Agile approaches are typically used in software development to help businesses respond to unpredictability.



What is Scrum?


Scrum is the most popular way of introducing Agility due to its simplicity and flexibility. Because of this popularity, many organizations claim to be “doing Scrum” but aren’t doing anything close to Scrum’s actual definition. Scrum emphasizes empirical feedback, team self management, and striving to build properly tested product increments within short iterations. Doing Scrum as it’s actually defined usually comes into conflict with existing habits at established non-Agile organizations.


Scrum has only three roles: Product Owner, Team, and Scrum Master. These are described in detail by the Scrum Training Series. The responsibilities of the traditional project manager role are split up among these three Scrum roles. Scrum has five meetings: Backlog Grooming (aka Backlog Refinement)Sprint PlanningDaily Scrum (aka 15-minute standup), the Sprint Review Meeting, and the Sprint Retrospective Meeting.

Many books and classes are available from a variety of competing sources of varying accuracy and quality.  One place to start would be the Scrum Training Series, which uses an entertaining approach to cover the most popular way of introducing Agile to teams. You can also download the 6-page illustrated Scrum Reference Card.


What’s Wrong With Traditional Approaches?


In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems,” which criticized sequential development. He asserted that software should not be developed like an automobile on an assembly line, in which each piece is added in sequential phases, each phase depending on the previous. Dr. Royce recommended against the phase based approach in which developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. Royce specifically objected to the lack of communication between the specialized groups that complete each phase of work.


It’s easy to the problems with “waterfall” methodology. It assumes that every requirement of the project can be identified before any design or coding occurs. Could you tell a team of developers everything that needed to be in a software product before any of it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. Your company has spent time and money to create software that no one wants. Couldn’t it have been possible to ensure the end product would still be relevant before it was actually finished?


Today very view organizations openly admit to doing waterfall or traditional command and control. But those habits persist.


Why Agile?


Agile development provides opportunities to assess the direction throughout the development lifecycle. This is achieved through regular cadences of work, known as Sprints or iterations, at the end of which teams must present a potentially shippable product increment. By focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology is described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited. When a team stops and re-evaluates the direction of a project every two weeks, there’s time to steer it in another direction.


This “inspect-and-adapt” approach to development greatly reduces development costs and time to market. Because teams can develop software at the same time they’re gathering requirements, “analysis paralysis” is less likely to impede a team from making progress. And because a team’s work cycle is limited to two weeks, stakeholders have recurring opportunities to calibrate releases for success in the real world. Agile development helps companies build the right product. Instead of committing to market a piece of software that hasn’t been written yet, agile empowers teams to continuously replan their release to optimize its value throughout development, allowing them to be as competitive as possible in the marketplace. Agile development preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released.

Introduction to Scrum

Introduction to Scrum video

Print Print | Sitemap
© 2016 Automation Learn. All rights reserved.