7. Why have a model
• A model recognize that Software Engineering is more than
just programming
• Recognize product life cycles
– Various requirements specification phases
– Design phases
– Coding and testing phases
– Maintenance phase (bug fixes and revisions)
8. More reasons to have a model
• A model helps recognize and define the division of labor
– Individual responsibilities (program managers, software design
engineers, UI designers, testers, product support,
internationalization, marketing, etc.)
– How big should a team be
– Parallel work efforts
– Does a one person team need a model
• Provide a common means of communication between all
involved parties
• Documentation is vital
– Comments in the code is not sufficient documentation
9. Goals of a good model
• The obvious “Provide a framework for building a solidly
engineered product”
• A paradigm that adds discipline and order to software
development
• Provides a formal mechanism to clarify, track, and modify
the product requirements throughout the product life cycle
• Provide a guideline for engineers to use in the product life
cycle
• Provide feedback into the development cycle
10. More goals of a good model
• Compel engineers to want to use it
– Doesn’t get in the way
– Convinces them that they will build a better product
– Be easy to understand and use
• Keep everyone organized
• Many more “common sense” reasons
13. More on the waterfall model
• What it is
– Each phase is carried out completely (for all requirements) before
proceeding to the next
– The process is strictly sequential - no backing up or repeating
phases
• What it tried to accomplish
– Account for more than programming
– Feedback between phases
– A requirement change can have a major cost downstream
14. More on the waterfall model
• Benefits
– Simple, easy to understand and follow
– Highly structured, therefore good for beginners
– After specification is complete, low customer involvement
required
• Limitations
– Limited feedback increases risk
– Inflexible - can't adapt to changes in requirements
– A requirement change can have a major cost downstream
16. More on prototyping model
• A variation of the waterfall that adds a new phase,
prototyping
• Prototypes intend to reduce risk by building a quick and
dirty replica or mockup of the intended system.
• Demonstrate technical feasibility when the technical risk is
high.
• Used to better understand and elicit user requirements.
• Goal: reduce risk and limit costs by increasing
understanding of proposed solutions before committing
more resources.
18. More on incremental
development
• developing an initial implementation
• exposing this to user feedback
• evolving it through several versions until an
acceptable system has been developed.
19. Incremental Vs Waterfall Model
• cost of accommodating changing
• customer feedback
• rapid delivery
21. More on the spiral model
• What it is
– An iterative approach where multiple passes are made through
each phase
– During each iteration the system is explored at greater depth and
more detail is added
• What it tried to accomplish
– Recognize that Software Engineering is a process of iterative
refinement
– Allow for alternate designs and implementations
22. More on the spiral model
• Benefits
– The iterative natures allows for knowledge gained during early
passes to inform subsequent passes
– Requires low up-front commitment
– Manages uncertainty inherent in exploratory projects
– Strong approval and documentation control
– Additional Functionality can be added at a later date
– Software is produced early in the software life cycle
23. More on the spiral model
• Limitations
– Difficult to establish stable documents
– Things keep getting modified during each iteration
– Too much dependable on Risk Analysis and requires highly
specific expertise
– Spiral may go on indefinitely
– End of the project may not be known early
– May be hard to define objective, verifiable milestones
– Large numbers of intermediate stages require excessive
documentation
24. When to use Spiral model
• 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)
25. Real Life Examples of software
using spiral model
• Evolution of Microsoft Windows operating
system
27. Assignments
• RAD model (Odd Roll Numbers)
• V-Model (Even Roll Numbers)
• Instructions:
– Explain its distinction with others
– Benefits & Limitations
– Where to use
– Real life examples
29. Lessons from the models
• Each trying to capture or dictate how a project should be
run
• Even a good properly applied model cannot fix a flawed
design
• Not any model offers the 100% solution
• Often borrowing from one or more model is necessary
• Just as Software Engineering is full of compromises so is
using a Software Engineering model
• So take these models with a grain of salt and use only
those parts that apply to your situation
