COMP 325 Lecture 2: Software Life Cycle Models
major resources: Object-Oriented and Classical Software Engineering 6ed, Schach 2005, Object-Oriented Software Engineering, Schach 2008.

[ previous | schedule | next ]

Life-Cycle Model

• a way of organizing the life cycle phases and activities
• there are many ways of organizing
• each has different strengths and weaknesses
• we will focus on several
• two issues important to all life cycle models:
• validation: "does the right thing" (meets clients expressed needs)
• verification: "does the thing right" (phase n correctly reflects phase n-1)

Waterfall Model

• developed in early 1970s
• phases are conducted sequentially
• requirements -> analysis -> design -> implementation -> maintenance
• phase n is not begun until phase n-1 is complete and documented and approved
• traditionally no feedback until implementation complete
• an error in any phase cannot be detected until post-delivery maintenance
• all the above support calling it "waterfall"
• consider it from the client's view
  • during what phases do they interact with the developers?
  • when do they first see the software?
  • the time between analysis and delivery could be a year or more
  • will client needs change and evolve during that time gap?
• documentation is crucial
• management uses documentation as evidence of progress
• phase n developers use documentation from phase n-1 as their guide
• conceivably each phase can be performed by different people/teams

Iterative and Incremental Models

• describe a family of development models in which system is produced piece-by-piece (increment) with multiple client-developer interactions in each increment (iterative)
• a core set of workflows (activities) are performed throughout
• requirements workflow
• analysis workflow
• design workflow
• implementation workflow
• test workflow
• visualize project timeline along x-axis and workflow activity on y-axis
• project timeline is partitioned into increments (possibly releases)
• each increment is partitioned into iterations
• each iteration involves all workflows in a waterfall fashion
• the number of increments and iterations varies by project
• iterative-and-incremental is thus seen as a sequence of mini-waterfalls
• the overall pattern of time spent on workflows may or may not resemble waterfall
• more responsive to changes in client needs than waterfall (better addresses risk)
• can have all the rigor of waterfall

Rapid Prototyping Model

• modify waterfall to make requirements phase highly iterative (lots of client interaction)
• built prototype to determine user needs
• traditional requirements phase replaced by rapid prototyping phase
• highly iterative
• work closely with client to quickly develop prototype
• prototype does not implement all features
• prototype features not completely implemented
• prototype typically focuses on design of user interface
• prototype is validated by client
• model proceeds much like waterfall from analysis onward
• use prototype to build specifications document
• prototype software itself should be discarded. Why?

Agile Process Models

• recent and still-evolving family of development practices
• term agile refers to responsiveness to change and small number of rules
• called a lightweight model due to small number of rules and practices
• some model characteristics
• highly iterative, close collaboration with clients
• implementation starts early
• reduced emphasis on analysis, design, documentation
• heavy emphasis on testing
• known to work well for small scale and vaguely specified projects
• not yet known how well it scales up
• most well known agile process is extreme programming (XP)
• see www.extremeprogramming.org for life cycle diagram
• involves more than just programming!
• highly iterative and incremental
• clients write user stories to describe how system is used
• developers develop time estimates from user stories
• acceptance tests are also developed from user stories
• developers and clients use time estimates to determine which stories will be implemented when. This is documented in release plan, which outlines sequence and schedule of releases.
• releases should be small and frequent (for agility)
• For a given release, stories are broken down into programming tasks.
• Programming tasks are assigned to programming pairs (driver at keyboard, navigator at side to give direction and spot errors quickly)
• programming begins early
• testing is formal, semi-automated, and continual (test-driven development) before, during and after coding
• integration is done frequently
• refactoring is done on the fly, rather than in pre-implementation design phase

Spiral Model

• risk-focused model developed in 1980s
• waterfall modified to add risk analysis at start of each phase
• idea is to identify and resolve risks before proceeding with a phase
• many risks can be resolved through prototyping
• a heavyweight process due to all the rules and activities
• many "lighter" variations have been adapted for specific projects
• works well for large scale projects
• overhead of risk analysis makes spiral unwieldy for smaller projects

Some Other Models

• Open-Source Model
• term "open source" normally associated with product and its licensing
• How does it differ from "free" software? Richard Stallman explains
• iterative and incremental model used for major free and open source products (e.g. Linux, Apache)
• First phase characterized by development of initial version, which is made available to be freely-distributed
• If it catches on, second phase evolves as users become co-developers
• Their everyday usage serves as testing workflow
• Reporting and fixing failures and defects
• Extending the software's capabilities
• Porting the software to new and different platforms
• Note that the last three above points illustrate the three types of maintenance: corrective, perfective, adaptive
• If project is large-scale, second phase management becomes an issue
• If you detected a fault in Linux and were able to fix it, how would you get your fix into the next release?
• Core group makes the decisions
• This model suits only certain kinds of software
• Evolutionary Tree Model
• Modifies waterfall by recording each feedback action as separate waterfall branch during actual development
• cannot be planned in advance, must be recorded as development evolves
• Synchronize-and-Stabilize Model
• a iterative and incremental model pioneered by and used within Microsoft
• following analysis, clients prioritize features into categories (e.g. core, important, nice to have)
• Sequence of builds is planned, first one with highest priority features, etc
• teams working on build must synchronize their work at end of day (integrate and test)
• at the end of build, requirements behind that build are frozen, or stabilized
• Code and Fix Model
• does not involve explicit requirements, analysis or design phases
• highly iterative and incremental
• risks are high: difficult to maintain and many faults not discovered until post-delivery maintenance
• works only for very small projects