SDLC Models

2. Software Development Life Cycles
Life cycle: Entire duration of a project, from inception to termination
Different life cycle models:
2.1. Code-and-fix model:
_ Earliest software development approach (1950s)
_ Iterative, programmers' approach
_ Two phases: 1. coding, 2. fixing the code
No provision for:
_ Project planning
_ Analysis
_ Design
_ testing
_ Maintenance
Problems with code-and-fix model:
1. After several iterations, code became very poorly structured; subsequent fixes became very expensive
2. Even well-designed software often very poorly matched users’ requirements: were rejected or needed to be redeveloped (expensively!)
3. Changes to code were expensive, because of poor testing and maintenance practices
Solutions:
1. Design before coding
2. Requirements analysis before design
3. Separate testing and maintenance phases after coding
2.2. Waterfall model:
_ Also called the classic life cycle
_ Introduced in 1956 to overcome limitations of code-and-fix model
_ Very structured, organized approach, suitable for planning
Main phases:
1. Feasibility study
2. Analysis
3. Design (overall design & detailed design)
4. Coding
5. Testing (unit test, integration test, acceptance test)
6. Maintenance
_ Waterfall model is a linear approach, quite inflexible
_ At each phase, feedback to previous phases is possible (but is discouraged in practice)
_ Still is the most widespread model today
Problems with Waterfall Model:
It doesn’t happen( Requirements are frizzed)
Real projects tend not to follow a sequential flow
Activities are done opportunistically during all “phases”
Delivery only at the end (long wait)
2.3. Prototyping model:
_ Introduced to overcome shortcomings of waterfall model
_ Suitable to overcome problem of requirements definition
_ Prototyping builds an operational model of the planned
system, which the customer can evaluate
Main phases:
1. Requirements gathering
2. Quick design
3. Build prototype
4. Customer evaluation of prototype
5. Refine prototype
Iterate steps 4. and 5. to "tune" the prototype
6. Engineer product
Mostly, the prototype is discarded after step 5. and the actual system is built from scratch in step 6. (throw-away prototyping)
Possible problems:
_ Customer may object to prototype being thrown away and may demand "a few changes" to make it working (results in poor software quality and maintainability)
_ Inferior, temporary design solutions may become permanent after a while, when the developer has forgotten that they were only intended to be temporary (results in poor software quality)
2.4 Incremental:
During the first one-month phase, the development team worked from static visual designs to code a prototype. In focus group meetings, the team discussed users’ needs and the potential features of the product and then showed a demonstration of its prototype. The excellent feedback from these focus groups had a large impact on the quality of the product.
Main phases:
1. Define outline req uirements
2. Assign requirements to increments
3. Design system architecture
4. Develop
5. Integrate
6. Validate
After the second group of focus groups, the feature set was frozen and the product definition complete. Implementation consisted of four-to-six-week cycles, with software delivered for beta use at the end of each cycle. The entire release took 10 months from definition to manufacturing release. Implementation lasted 4.5 months. The result was a world-class product that has won many awards and has been easy to support.
2.5 Spiral model:
_ Objective: overcome problems of other models, while combining their advantages
_ Key component: risk management (because traditional models often fail when risk is neglected)
_ Development is done incrementally, in several cycles _ Cycle as often as necessary to finish
Main phases:
1. Determine objectives, alternatives for development, and
constraints for the portion of the whole system to be
developed in the current cycle
2. Evaluate alternatives, considering objectives and
constraints; identify and resolve risks
3. Develop the current cycle's part of the system, using
evolutionary or conventional development methods
(depending on remaining risks); perform validation at
the end
4. Prepare plans for subsequent phases
Advantages of spiral model:
_ Most realistic approach for large systems envelopment
_ Allows identification and resolution of risks early in the development
Problems with spiral model:
_ Difficult to convince customer that this approach is controllable
_ Requires significant risk assessment expertise to succeed
_ Not yet widely used: efficacy not yet proven