Ch 2: Software Life-Cycle Models CSCI 4320

Ideal Software Development

Actual Software Development Software developers make mistakes Clients requirements or environment changes while software is being developed. The Software Development Life-Cycle involves many iterations (loops).

Bus Fare Machine Program GOAL: Fare machines on bus must recognize real dollar bills. Episode 1: The first version is implemented Episode 2: A fault is found –The product is too slow because of an implementation fault (double precision instead of single precision used) –Changes to the implementation are begun Episode 3: The requirements change –A different/faster dollar recognition algorithm has been discovered Episode 4: A new design is adopted –New design is more accurate. - Development is complete Epilogue: A few years later, these problems recur

Teal Tractors Business Software Goal : Handle sales, inventory and commissions for business While the Teal Tractors software product is being constructed, the requirements change The company is expanding into Canada –Additional sales regions must be added –Canadian taxes and other business aspects that are handled differently –Two different currencies, US and CANADA

Moving Target Problem Growing companies are always going to change Even if the reasons for the change are good, the software product can be adversely impacted –Dependencies will be induced –Potentially cause a regression fault (A fault in an apparently unrelated part of the software) –feature creep There is no solution to the moving target problem

Life-Cycle Models Waterfall Life Code-and-Fix Rapid-Prototyping Extreme Programming and Agile Processes Synchronize-and-Stabilize Spiral Iteration and Incrementation

The basic software development process is Iterative –Each successive version is intended to be closer to its target than its predecessor An Incremental Process –Miller’s Law : concentrate on ~ 7 chunks –Use stepwise refinement –handle in order of current importance

Iteration and Incrementation Idea: –Project is divided into several mini projects (increments) –Each project goes through all phases, extending existing artifacts Multiple opportunities to check for faults Always have a working version of software

Waterfall No phase is complete until documentation for that phase is complete. Relying solely on written specifications may lead to products that don’t meet client’s needs.

Code-and Fix Developers simply throw code together and rework it as many times as necessary No Requirements written May work well for small programs Maintenance Nightmare!

Rapid Prototyping Build a rapid-prototype and let client interact and experiment with it. Developers draw up specifications from rapid prototype and develop true system Key: Speed is of the essence The rapid prototype is discarded but lessons learned are retained.

Open-Source Life-Cycle A single individual has an idea for a program and makes it available free of charge –SourceForge.net, FreshMeat.net Users become co-developers –Report and correct defects –Add additional functionality –Port program to new environment Individuals are not paid to participate Release new versions after minimal testing

Open Source Software 100,000 open-source projects at SouceForge.net and Freshmeat.net ½ have never attracted a team to work on the project Majority have never been completed But there are cases where it has been benefical –Operating Systems (Linux), web browsers (Firefox), compilers (gcc), web servers(Apache)

Extreme Programming and Agile Processes New Approach: responsive to change, collaborate with client Client picks features based on time and cost estimates Build is broken down into tasks Pair programming –Two programmers work on one computer –Alternate typing every 15 or 20 minutes –Team members change coding partners daily Client works with team at all times

Extreme Programming and Agile Processes No individual can work overtime for 2 weeks No specialization: All members of team work on analysis, design, coding No overall design step before the various builds Agile Processes Less emphasis on analysis and design Goal is to deliver working software frequently Have short meetings often Successful for small-scale projects where customer requirements are vague

Synchronized and Stabilize Microsoft Expected Features are prioritized Work is divided into several builds Each build is carried out by several teams working in parallel At the end of the day all teams synchronize and test

Spiral Waterfall method with each phase preceded by risk analysis Uses prototypes to mitigate risks Advantage: Emphasis on alternatives and constraints supports the reuse of existing software Problem: When do you determine if a phase has been sufficiently tested?

Comparison of Life-Cycle Models Figure 2.12