The document discusses various software development models, primarily focusing on the Waterfall, Prototyping, Spiral, and Incremental models. Each model has its strengths and weaknesses; for instance, the Waterfall model is structured but inflexible to changing requirements, while the Spiral model allows for iterative refinement through risk analysis. It also outlines when each model is appropriate based on project characteristics like complexity, risk, and customer needs.

1. The waterfall model

2. The waterfall model
• The classic way of looking at S.E. that accounts
for the importance of requirements, design and
quality assurance.
– The model suggests that software engineers should
work in a series of stages.
– Before completing each stage, they should perform
quality assurance (verification and validation).
– The waterfall model also recognizes, to a limited
extent, that you sometimes have to step back to
earlier stages.

3. Limitations of the waterfall model
– The model implies that you should attempt to complete
a given stage before moving on to the next stage
• Does not account for the fact that requirements constantly
change.
• It also means that customers can not use anything until the
entire system is complete.
– The model makes no allowances for prototyping.
– It implies that you can get the requirements right by
simply writing them down and reviewing them.
– The model implies that once the product is finished,
everything else is maintenance.

4. Waterfall Strengths
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff,
track)
• Works well when quality is more important
than cost or schedule

5. When to use the Waterfall Model
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new platform.

6. Prototyping Model
• A prototype is a working model that is functionally
equivalent to a component of the product.
• reflects an attempt to increase the flexibility of the
development process by allowing the client to
interact and experiment with a working
representation of the product
• developmental process only continues once the
client is satisfied with the functioning of the
prototype

7. Overview
• Identify basic requirements. Determine basic requirements
including the input and output information desired. Details,
such as security, can typically be ignored.
• Develop Initial Prototype. The initial prototype is developed
that includes only user interfaces.
• Review The customers, including end-users, examine the
prototype and provide feedback on additions or changes.
• Revise and Enhancing the Prototype. Using the feedback
both the specifications and the prototype can be improved.
If changes are introduced then a repeat of steps #3 and #4
may be needed.

8. Types of Prototyping
• Throwaway prototype
Creation of a model that will eventually be discarded
rather than becoming part of the finally delivered software
• Evolutionary/System prototype
To build a very robust prototype in a structured manner
and constantly refine and rebuilt it
• Incremental prototype
Final product is built as separate prototypes. At the end the
separate prototypes are being merged in an overall design

9. The spiral model(System Prototype)

10. The spiral model
• It explicitly embraces prototyping and an iterative approach to
software development.
– Start by developing a small prototype.
– Followed by a mini-waterfall process, primarily to gather requirements.
– Then, the first prototype is reviewed.
– In subsequent loops, the project team performs further requirements,
design, implementation and review.
– The first thing to do before embarking on each new loop is risk
analysis( includes development cost overruns, operating cost
miscalculations or any other factor that leads to less than satisfactory
final product)
– Maintenance is simply a type of on-going development.
– Intended for large, expensive and complicated projects

11. Spiral Model Weaknesses
• Time spent for evaluating risks too large for small or low-
risk projects
• Time spent planning, resetting objectives, doing risk
analysis and prototyping may be excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• Developers must be reassigned during non-development
phase activities
• May be hard to define objective, verifiable milestones that
indicate readiness to proceed through the next iteration

12. When to use Spiral Model
• When creation of a prototype is appropriate
• When costs and risk evaluation is important
• For medium to high-risk projects
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research
and exploration)

13. Incremental Model

14. Incremental Model
• It introduces the notion of incremental
development.
– After requirements gathering and planning, the project
should be broken into separate subprojects, or phases.
– Each phase can be released to customers when ready.
– Parts of the system will be available earlier than when
using a strict waterfall approach.
– However, it continues to suggest that all requirements be
finalized at the start of development.

15. Incremental Model Strengths
• Develop high-risk or major functions first
• Each release delivers an operational product
• Customer can respond to each build
• Uses “divide and conquer” breakdown of tasks
• Lowers initial delivery cost
• Initial product delivery is faster
• Customers get important functionality early
• Risk of changing requirements is reduced

16. When to use the Incremental Model
• Risk, funding, schedule, program complexity, or
need for early realization of benefits.
• Most of the requirements are known up-front
but are expected to evolve over time
• A need to get basic functionality to the market
early
• On projects which have lengthy development
schedules
• On a project with new technology