======Waterfall Model –

Design

Waterfall approach was fi rst SDLC Model to be used widely in Soft ware Engineering to
ensure success of the project. In "The Waterfall" approach, the whole process of soft ware
development is divided into separate phases. In this Waterfall model, typically, the
outcome of one phase acts as the input for the next phase sequenti ally.

The following illustrati on is a representati on of the diff erent phases of the Waterfall
Model.

The sequenti al phases in Waterfall model are −

Requirement Gathering and analysis  − All possible requirements of the system to be

developed are captured in this phase and documented in a requirement specifi cati on
document.

System Design − The requirement specifi cati ons from fi rst phase are studied in this phase
and the system design is prepared. This system design helps in specifying hardware and
system requirements and helps in defi ning the overall system architecture.

Implementati on − With inputs from the system design, the system is fi rst developed in
small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functi onality, which is referred to as Unit Testi ng.

Integrati on and Testi ng  − All the units developed in the implementati on phase are
integrated into a system aft er testi ng of each unit. Post integrati on the enti re system is
tested for any faults and failures.

Deployment of system − Once the functi onal and non-functi onal testi ng is done; the
product is deployed in the customer environment or released into the market.
Maintenance − There are some issues which come up in the client environment. To fi x
those issues, patches are released. Also to enhance the product some bett er versions are
released. Maintenance is done to deliver these changes in the customer environment.

Waterfall Model - Applicati on

1. Requirements are very well documented, clear and fi xed.

2. Product defi niti on is stable.

3. Technology is understood and is not dynamic.

4. There are no ambiguous requirements.

5. Ample resources with required experti se are available to support the product.

6. The project is short.

Waterfall Model - Advantages

Some of the major advantages of the Waterfall Model are as follows −

1. Simple and easy to understand and use

2. Easy to manage due to the rigidity of the model. Each phase has specifi c
deliverables and a review process.

3. Phases are processed and completed one at a ti me.

4. Works well for smaller projects where requirements are very well understood.

5. Clearly defi ned stages.

6. Well understood milestones.

7. Easy to arrange tasks.

8. Process and results are well documented.

Waterfall Model - Disadvantages

1. The major disadvantages of the Waterfall Model are as follows −

2. No working soft ware is produced unti l late during the life cycle.

3. High amounts of risk and uncertainty.

4. Not a good model for complex and object-oriented projects.

5. Poor model for long and ongoing projects.

6. Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.

7. It is diffi cult to measure progress within stages.

 8. Cannot accommodate changing requirements.

9. Adjusti ng scope during the life cycle can end a project.

10. Integrati on is done as a "big-bang. at the very end, which doesn't allow identi fying
any technological or business bott leneck or challenges early.

========================================================================

Iterati ve Model - Design

Iterati ve process starts with a simple implementati on of a subset of the soft ware
requirements and iterati vely enhances the evolving versions unti l the full system is
implemented. At each iterati on, design modifi cati ons are made and new functi onal
capabiliti es are added. The basic idea behind this method is to develop a system through
repeated cycles (iterati ve) and in smaller porti ons at a ti me (incremental).

The following illustrati on is a representati on of the Iterati ve and Incremental model −

Iterati ve and Incremental development is a combinati on of both iterati ve design or

iterati ve method and incremental build model for development. "During soft ware
development, more than one iterati on of the soft ware development cycle may be in
progress at the same ti me." This process may be described as an "evoluti onary
acquisiti on" or "incremental build" approach."

In this incremental model, the whole requirement is divided into various builds. During
each iterati on, the development module goes through the requirements, design,
implementati on and testi ng phases. Each subsequent release of the module adds functi on
to the previous release. The process conti nues ti ll the complete system is ready as per
the requirement.

The key to a successful use of an iterati ve soft ware development lifecycle is rigorous
validati on of requirements, and verifi cati on & testi ng of each version of the soft ware
against those requirements within each cycle of the model. As the soft ware evolves
through successive cycles, tests must be repeated and extended to verify each version of
the soft ware.

Iterati ve Model - Applicati on

1. Requirements of the complete system are clearly defi ned and understood.

2. Major requirements must be defi ned; however, some functi onaliti es or requested
enhancements may evolve with ti me.

3. There is a ti me to the market constraint.

4. A new technology is being used and is being learnt by the development team while
working on the project.

5. Resources with needed skill sets are not available and are planned to be used on
contract basis for specifi c iterati ons.

6. There are some high-risk features and goals which may change in the future.

The advantages of the Iterati ve and Incremental SDLC Model are as follows −

1. Some working functi onality can be developed quickly and early in the life cycle.

2. Results are obtained early and periodically.

3. Parallel development can be planned.

4. Progress can be measured.

5. Less costly to change the scope/requirements.

6. Testi ng and debugging during smaller iterati on is easy.

7. Risks are identi fi ed and resolved during iterati on; and each iterati on is an easily
managed milestone.

8. Easier to manage risk - High risk part is done fi rst.

9. With every increment, operati onal product is delivered.

10. Issues, challenges and risks identi fi ed from each increment can be uti lized/applied
to the next increment.

11. Risk analysis is bett er.

12. It supports changing requirements.

13. Initi al Operati ng ti me is less.

14. Bett er suited for large and mission-criti cal projects.

15. During the life cycle, soft ware is produced early which facilitates customer
evaluati on and feedback.
The disadvantages of the Iterati ve and Incremental SDLC Model are as follows −

1. More resources may be required.

2. Although cost of change is lesser, but it is not very suitable for changing
requirements.

3. More management att enti on is required.

4. System architecture or design issues may arise because not all requirements are
gathered in the beginning of the enti re life cycle.

5. Defi ning increments may require defi niti on of the complete system.

6. Not suitable for smaller projects.

7. Management complexity is more.

8. End of project may not be known which is a risk.

9. Highly skilled resources are required for risk analysis.

10. Projects progress is highly dependent upon the risk analysis phase.

========================================================================

The spiral model combines the idea of iterati ve development with the systemati c,
controlled aspects of the waterfall model. This Spiral model is a combinati on of iterati ve
development process model and sequenti al linear development model i.e. the waterfall
model with a very high emphasis on risk analysis. It allows incremental releases of the
product or incremental refi nement through each iterati on around the spiral.

Spiral Model - Design

The spiral model has four phases. A soft ware project repeatedly passes through these
phases in iterati ons called Spirals.

Identi fi cati on

This phase starts with gathering the business requirements in the baseline spiral. In the
subsequent spirals as the product matures, identi fi cati on of system requirements,
subsystem requirements and unit requirements are all done in this phase.

This phase also includes understanding the system requirements by conti nuous
communicati on between the customer and the system analyst. At the end of the spiral,
the product is deployed in the identi fi ed market.

Design

The Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and the fi nal
design in the subsequent spirals.
Construct or Build

The Construct phase refers to producti on of the actual soft ware product at every spiral.
In the baseline spiral, when the product is just thought of and the design is being
developed a POC (Proof of Concept) is developed in this phase to get customer feedback.

Then in the subsequent spirals with higher clarity on requirements and design details a
working model of the soft ware called build is produced with a version number. These
builds are sent to the customer for feedback.

Evaluati on and Risk Analysis

Risk Analysis includes identi fying, esti mati ng and monitoring the technical feasibility and
management risks, such as schedule slippage and cost overrun. Aft er testi ng the build, at
the end of fi rst iterati on, the customer evaluates the soft ware and provides feedback.

The following illustrati on is a representati on of the Spiral Model, listi ng the acti viti es in
each phase.

Based on the customer evaluati on, the soft ware development process enters the next
iterati on and subsequently follows the linear approach to implement the feedback
suggested by the customer. The process of iterati ons along the spiral conti nues
throughout the life of the soft ware.
Spiral Model Applicati on

The following pointers explain the typical uses of a Spiral Model −

1. When there is a budget constraint and risk evaluati on is important.

2. For medium to high-risk projects.

3. Long-term project commitment because of potenti al changes to economic

prioriti es as the requirements change with ti me.

4. Customer is not sure of their requirements which is usually the case.

5. Requirements are complex and need evaluati on to get clarity.

6. New product line which should be released in phases to get enough customer
feedback.

7. Signifi cant changes are expected in the product during the development cycle.

The advantages of the Spiral SDLC Model are as follows −

1. Changing requirements can be accommodated.

2. Allows extensive use of prototypes.

3. Requirements can be captured more accurately.

4. Users see the system early.

5. Development can be divided into smaller parts and the risky parts can be
developed earlier which helps in bett er risk management.

The disadvantages of the Spiral SDLC Model are as follows −

1. Management is more complex.

2. End of the project may not be known early.

3. Not suitable for small or low risk projects and could be expensive for small
projects.

4. Process is complex

5. Spiral may go on indefi nitely.

6. Large number of intermediate stages requires excessive documentati on.

========================================================================

Functi onal Requirements: Functi onal requirements are those requirements which deal
with what the system should do or provide for users.

1. Describes the behavior of the system as it relates to the system's functi onality.
 2. Includes the descripti on of the required functi ons, outlines of associated reports
or online queries, and details of data to be held in the system.

3. Specifi ed by users themselves.

Non Functi onal Requirements: Non-functi onal requirements are those requirements
which elaborate the performance characteristi c of the system and defi ne the constraints
on how the system will do so.

1. Defi nes the constraints, targets or control mechanisms for the new system.

2. Describes how, how well or to what standard a functi on should be provided.

3. Specifi ed by technical peoples e.g. Architect, Technical leaders and soft ware
developers.

4. They are someti mes defi ned in terms of metrics (something that can be measured
about the system) to make them more tangible.

5. Identi fy realisti c, measurable target values for each service level.

6. These include reliability, performance, service availability, responsiveness,

throughput and security

===========================================================================

soft ware requirements specifi cati on (SRS) is a document that captures complete
descripti on about how the system is expected to perform. It is usually signed off at the
end of requirements engineering phase.

Qualiti es of SRS:

1. Correct

2. Unambiguous

3. Complete

4. Consistent

5. Ranked for importance and/or stability

6. Verifi able

7. Modifi able

8. Traceable

Types of Requirements:

The below diagram depicts the various types of requirements that are captured during
SRS.
===========================================================================