Just in Case You Wanted to Know Box 2.2
2.10 Comparison of Life-Cycle Models
Nine different software life-cycle models have been examined with special attention paid to some of their strengths and weaknesses. The code-and-fi x model (Section 2.9.1) should be avoided. The waterfall model (Section 2.9.2) is a known quantity. Its strengths are understood, and so are its weaknesses. The rapid-prototyping model (Section 2.9.3) was developed as a reaction to a specifi c perceived weakness in the waterfall model, namely, that the delivered product may not be what the client really needs. However, there is still insuffi cient evidence that this approach is superior to the waterfall model in other respects. The open-source life-cycle model has been incredibly successful in a small number of cases when used to con-struct infracon-structure software (Section 2.9.4). Agile processes (Section 2.9.5) are a set of controversial new approaches that, so far, appear to work, but for only small-scale software.
The synchronize-and-stabilize model (Section 2.9.6) has been used with great success by Microsoft, but as yet there is no evidence of comparable success in other corporate cultures.
Yet another alternative is to use the spiral model (Section 2.9.7), but only if the developers are adequately trained in risk analysis and risk resolution. The evolution-tree model (Section 2.2) and the iterative-and-incremental model (Section 2.5) are closest to the way that software is produced in the real world. An overall comparison appears in Figure 2.14 .
Each software development organization should decide on a life-cycle model that is appropriate for that organization, its management, its employees, and its software process
sch76183_ch02_035-073.indd 66
sch76183_ch02_035-073.indd 66 04/06/10 12:34 PM04/06/10 12:34 PM
and should vary the life-cycle model depending on the features of the specifi c product cur-rently under development. Such a model incorporates appropriate aspects of the various life-cycle models, utilizing their strengths and minimizing their weaknesses.
FIGURE 2.14
There are signifi cant differences between the way that software is developed in theory (Section 2.1) and the way it is developed in practice. The Winburg mini case study is used to introduce the evolution-tree model (Section 2.2). Lessons of this mini case study, especially that requirements change, are presented in Sec-tion 2.3. Change is discussed in greater detail in SecSec-tion 2.4, where the moving-target problem is presented using the Teal Tractors mini case study. In Section 2.5, the importance of iteration and incrementation in real-world software engineering is stressed, and the iterative-and-incremental model is presented. The Winburg mini case study is then re-examined in Section 2.6 to illustrate the equivalence of the evolution-tree model and the incremental model. In Section 2.7, the strengths of the iterative-and-incremental model are presented, particularly that it enables us to resolve risks early. Management of the iterative-and-incremental model is discussed in Section 2.8. A number of different life-cycle models are now described, including the code-and-fi x life-cycle model (Section 2.9.1), waterfall life-cycle model (Section 2.9.2), rapid-prototyping life-cycle model (Section 2.9.3), open-source life-cycle model (Section 2.9.4), agile processes (Section 2.9.5), synchronize-and-stabilize life-cycle model (Section 2.9.6), and spi-ral life-cycle model (Section 2.9.7). In Section 2.10, these life-cycle models are compared and suggestions are made regarding the choice of a life-cycle model for a specifi c project.
68 Part A Software Engineering Concepts
For Further Reading
The waterfall model was fi rst put forward in [Royce, 1970]. An analysis of the waterfall model is given in the fi rst chapter of [Royce, 1998].
The synchronize-and-stabilize model is outlined in [Cusumano and Selby, 1997] and described in detail in [Cusumano and Selby, 1995]. The spiral model is explained in [Boehm, 1988], and its application to the TRW Software Productivity System appears in [Boehm et al., 1984].
Extreme programming is described in [Beck, 2000]; refactoring is the subject of [Fowler et al., 1999]. The Manifesto for Agile Software Development may be found at [Beck et al., 2001]. Books have been published on a variety of agile methods, including [Cockburn, 2001] and [Schwaber, 2001]. Agile methods are advocated in [Highsmith and Cockburn, 2001], [Boehm, 2002], [DeMarco and Boehm, 2002], and [Boehm and Turner, 2003], whereas the case against agile methods is presented in [Stephens and Rosenberg, 2003]. Refactoring is surveyed in [Mens and Tourwe, 2004]. The use of XP in four mission-critical projects is described in [Drobka, Noftz, and Raghu, 2004]. Issues that can arise when introducing agile processes within an organization that currently is using traditional methodologies are discussed in [Nerur, Mahapatra, and Mangalaraj, 2005] and in [Boehm and Turner, 2005].
A number of papers on extreme programming appear in the May–June 2003 issue of IEEE Soft-ware , including [Murru, Deias, and Mugheddu, 2003] and [Rasmusson, 2003], both of which describe successful projects developed using extreme programming. The June 2003 issue of IEEE Computer contains several articles on agile processes. The May–June 2005 issue of IEEE Software has four articles on agile processes, especially [Ceschi, Sillitti, Succi, and De Panfi lis, 2005] and [Karlström and Runeson, 2005]. The extent to which agile methods are used in the software industry is analyzed in [Hansson, Dittrich, Gustafsson, and Zarnak, 2006]. A survey of the critical success factors in agile software products is presented in [Chow and Cao, 2008]. Approaches to assist in the transition to agile methods are given in [Qumer and Henderson-Sellers, 2008]. Refactoring poses problems for software confi guration management tools; a solution is put forward in [Dig, Manzoor, Johnson, and Nguyen, 2008].
Agile testing of a large-scale software product is described in [Talby, Keren, Hazzan, and Dubin-sky, 2006]. The effectiveness of test-driven development is discussed in [Erdogmus, Morisio, and Torchiano, 2005]. The May–June 2007 issue of IEEE Software has a variety of articles on test-driven development, including [Martin, 2007].
Risk analysis is described in [Ropponen and Lyttinen, 2000], [Longstaff, Chittister, Pethia, and Haimes, 2000], and [Scott and Vessey, 2002]. Managing risks in offshore software development is presented in [Sakthivel, 2007] and in [Iacovou and Nakatsu, 2008]. Risk management when software is developed using COTS components is described in [Li et al., 2008].
A major iterative-and-incremental model is described in detail in [Jacobson, Booch, and Rumbaugh, 1999]. However, many other iterative-and-incremental models have been put forward over the past 30 years, as recounted in [Larman and Basili, 2003]. The use of an incremental model to build an air-traffi c control system is discussed in [Goth, 2000]. An iterative approach to re-engineering legacy systems is given in [Bianchi, Caivano, Marengo, and Visaggio, 2003]. A tool for supporting incremental software development while ensuring that the artifacts evolve consistently is described in [Reiss, 2006].
Many other life-cycle models have been put forward. For example, Rajlich and Bennett [2000]
describe a maintenance-oriented life-cycle model. The July–August 2000 issue of IEEE Software has a variety of papers on software life-cycle models, including [Williams, Kessler, Cunningham, and Jeffries, 2000] which describes an experiment on pair programming, one component of agile methods.
Rajlich [2006] goes further and suggests that many of the topics of this chapter have led us to a new paradigm for software engineering.
The proceedings of the International Software Process Workshops are a useful source of informa-tion on cycle models. [ISO/IEC 12207, 1995] is a widely accepted standard for software life-cycle processes.
sch76183_ch02_035-073.indd 68
sch76183_ch02_035-073.indd 68 04/06/10 12:34 PM04/06/10 12:34 PM
Key Terms agile process 60 evolution-tree life-cycle
model 40
rapid-prototyping life-cycle model 55 more or less effective than the evolution-tree model? Explain your answer.
2.2 Assume that the programmer in the Winburg mini case study had used single-precision numbers from the beginning. Draw the resulting evolution tree.
2.3 What is the connection between Miller’s Law and stepwise refi nement?
2.4 Does stepwise refi nement correspond to iteration or incrementation?
2.5 How are a workfl ow, an artifact, and a baseline related?
2.6 What is the connection between the waterfall model and the iterative-and-incremental model?
2.7 Suppose you have to build a product to determine the cube root of 9384.2034 to four decimal places. Once the product has been implemented and tested, it will be thrown away. Which life-cycle model would you use? Give reasons for your answer.
2.8 You are a software engineering consultant and have been called in by the vice-president for fi nance of a corporation that manufactures tires and sells them via its large chain of retail outlets. She wants your organization to build a product that will monitor the company’s stock, starting with the purchasing of the raw materials and keeping track of the tires as they are manu-factured, distributed to the individual stores, and sold to customers. What criteria would you use in selecting a life-cycle model for the project?
2.9 List the risks involved in developing the software of Problem 2.8. How would you attempt to mitigate each risk?
2.10 Your development of the stock control product for the tire company is so successful that your organization decides that it must be reimplemented as a package to be sold to a variety of different organizations that manufacture and sell products via their own retailers. The new prod-uct must therefore be portable and easily adapted to new hardware and/or operating systems.
How would the criteria you use in selecting a life-cycle model for this project differ from those in your answer to Problem 2.8?
2.11 Describe the sort of product that would be an ideal application for open-source software development.
70 Part A Software Engineering Concepts
2.12 Now describe the type of situation where open-source software development is inappropriate.
2.13 Describe the sort of product that would be an ideal application for an agile process.
2.14 Now describe the type of situation where an agile process is inappropriate.
2.15 Describe the sort of product that would be an ideal application for the spiral life-cycle model.
2.16 Now describe the type of situation where the spiral life-cycle model is inappropriate.
2.17 Describe a risk inherent in using the waterfall life-cycle model.
2.18 Describe a risk inherent in using the code-and-fi x life-cycle model.
2.19 Describe a risk inherent in using the open-source life-cycle model.
2.20 Describe a risk inherent in using agile processes.
2.21 Describe a risk inherent in using the spiral life-cycle model.
2.22 (Term Project) Which software life-cycle model would you use for the Chocoholics Anonymous product described in Appendix A? Give reasons for your answer.
2.23 (Readings in Software Engineering) Your instructor will distribute copies of [Rajlich, 2006]. Do you agree that software engineering has embarked on a new paradigm? Explain your answer.
References [Arisholm, Gallis, Dybå, and Sjøberg, 2007] E. ARISHOLM, H. GALLIS, T. DYBÅ, AND D. I. K. SJØBERG,
“Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise,”
IEEE Transactions on Software Engineering 33 (February 2007), pp. 65–86.
[Beck, 2000] K. BECK, Extreme Programming Explained: Embrace Change, Addison-Wesley Longman, Reading, MA, 2000.
[Beck et al., 2001] K. BECK, M. BEEDLE, A. COCKBURN, W. CUNNINGHAM, M. FOWLER, J. GRENNING, J. HIGHSMITH, A. HUNT, R. JEFFRIES, J. KERN, B. MARICK, R. C. MARTIN, S. MELLOR, K. SCHWABER, J. SUTHERLAND, D. THOMAS, AND A. VAN BENNEKUM, Manifesto for Agile Software Development , agilemanifesto.org, 2001.
[Bianchi, Caivano, Marengo, and Visaggio, 2003] A. BIANCHI, D. CAIVANO, V. MARENGO, AND
G. VISAGGIO, “Iterative Reengineering of Legacy Systems,” IEEE Transactions on Software Engi-neering 29 (March 2003), pp. 225–41.
[Boehm, 1988] B. W. BOEHM, “A Spiral Model of Software Development and Enhancement,” IEEE Computer 21 (May 1988), pp. 61–72.
[Boehm, 2002] B. W. BOEHM, “Get Ready for Agile Methods, with Care,” IEEE Computer 35 (January 2002), pp. 64–69.
[Boehm and Turner, 2003] B. BOEHMAND R. TURNER, Balancing Agility and Discipline: A Guide for the Perplexed , Addison-Wesley Professional, Boston, MA, 2003.
[Boehm and Turner, 2005] B. BOEHMAND R. TURNER, “Management Challenges to Implementing Agile Processes in Traditional Development Organizations,” IEEE Software 22 (September–
October 2005), pp. 30–39.
[Boehm et al., 1984] B. W. BOEHM, M. H. PENEDO, E. D. STUCKLE, R. D. WILLIAMS, AND A. B. PYSTER,
“A Software Development Environment for Improving Productivity,” IEEE Computer 17 (June 1984), pp. 30–44.
[Booch, 2000] G. BOOCH, “The Future of Software Engineering,” keynote address, International Conference on Software Engineering, Limerick, Ireland, May 2000.
[Ceschi, Sillitti, Succi, and De Panfi lis, 2005] M. CESCHI, A. SILLITTI, G. SUCCI, AND S. DE PANFILIS,
“Project Management in Plan-Based and Agile Companies,” IEEE Software 22 (May–June 2005), pp. 21–27.
sch76183_ch02_035-073.indd 70
sch76183_ch02_035-073.indd 70 04/06/10 12:34 PM04/06/10 12:34 PM
[Chow and Cao, 2008] T. CHOWAND D.-B. CAO, “A Survey Study of Critical Success Factors in Agile Software Projects,” Journal of Systems and Software 81 (June 2008), pp. 961–71.
[Cockburn, 2001] A. COCKBURN, Agile Software Development , Addison-Wesley Professional, Read-ing, MA, 2001.
[Cusumano and Selby, 1995] M. A. CUSUMANOAND R. W. SELBY, Microsoft Secrets: How the World’s Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People , The Free Press/Simon and Schuster, New York, 1995.
[Cusumano and Selby, 1997] M. A. CUSUMANOAND R. W. SELBY, “How Microsoft Builds Software,”
Communications of the ACM 40 (June 1997), pp. 53–61.
[DeMarco and Boehm, 2002] T. DEMARCOAND B. BOEHM, “The Agile Methods Fray,” IEEE Com-puter 35 (June 2002), pp. 90–92.
[Dig, Manzoor, Johnson, and Nguyen, 2008] D. DIG, K. MANZOOR, R. E. JOHNSON, AND T. N. NGUYEN,
“Effective Software Merging in the Presence of Object-Oriented Refactorings,” IEEE Transac-tions on Software Engineering 34 (May–June 2008), pp. 321–35.
[Drobka, Noftz, and Raghu, 2004] J. DROBKA, D. NOFTZ, AND R. RAGHU, “Piloting XP on Four Mission-Critical Projects,” IEEE Software 21 (November–December 2004), pp. 70–75.
[Dybå et al., 2007] T. DYBÅ, E. ARISHOLM, D. I. K. SJØBERG, J. E. HANNAY, AND F. SHULL, “Are Two Heads Better than One? On the Effectiveness of Pair Programming,” IEEE Software 24 (November–December 2007), pp. 12–15.
[Erdogmus, Morisio, and Torchiano, 2005] H. ERDOGMUS, M. MORISIO, AND M. TORCHIANO, “On the Effectiveness of the Test-First Approach to Programming,” IEEE Transactions on Software Engi-neering 31 (March 2005), pp. 226–37.
[Fowler et al., 1999] M. FOWLER wITH K. BECK, J. BRANT, W. OPDYKE, AND D. ROBERTS, Refactoring:
Improving the Design of Existing Code , Addison-Wesley, Reading, MA, 1999.
[Goth, 2000] G. GOTH, “New Air Traffi c Control Software Takes an Incremental Approach,” IEEE Software 17 (July–August 2000), pp. 108–11.
[Hansson, Dittrich, Gustafsson, and Zarnak, 2006] C. HANSSON, Y. DITTRICH, B. GUSTAFSSON, AND
S. ZARNAK, “How Agile Are Industrial Software Development Practices?” Journal of Systems and Software 79 (September 2006), pp. 1217–58.
[Hayes, 2004] F. HAYES, “Chaos Is Back,” Computerworld , www.computerworld.com/
managementtopics/management/project/story/0,10801,97283,00.html, November 8, 2004.
[Highsmith and Cockburn, 2001] J. HIGHSMITHAND A. COCKBURN, “Agile Software Development:
The Business of Innovation,” IEEE Computer 34 (September 2001), pp. 120–22.
[Iacovou and Nakatsu, 2008] C. L. IACOVOUAND R. NAKATSU, “A Risk Profi le of Offshore-Outsourced Development Projects,” Communications of the ACM 51 (June 2008) pp. 89–94.
[ISO/IEC 12207, 1995] “ISO/IEC 12207:1995, Information Technology—Software Life-Cycle Pro-cesses,” International Organization for Standardization, International Electrotechnical Commis-sion, Geneva, 1995.
[Jacobson, Booch, and Rumbaugh, 1999] I. JACOBSON, G. BOOCH, AND J. RUMBAUGH, The Unifi ed Software Development Process , Addison-Wesley, Reading, MA, 1999.
[Jalote, Palit, Kurien, and Peethamber, 2004] P. JALOTE, A. PALIT, P. KURIEN, AND V. T. PEETHAMBER, “ Timeboxing: A Process Model for Iterative Software Development,” Journal of Systems and Software 70 (February 2004), pp. 117–27.
[Karlström and Runeson, 2005] D. KARLSTRÖMAND P. RUNESON, “Combining Agile Methods with Stage-Gate Project Management,” IEEE Software 22 (May–June 2005), pp. 43–49.
72 Part A Software Engineering Concepts
[Larman and Basili, 2003] C. LARMANAND V. R. BASILI, “Iterative and Incremental Development: A Brief History,” IEEE Computer 36 (June 2003), pp. 47–56.
[Li and Alshayeb, 2002] W. LIAND M. ALSHAYEB, “An Empirical Study of XP Effort,” Proceedings of the 17th International Forum on COCOMO and Software Cost Modeling , Los Angeles, October 2002, IEEE.
[Li et al., 2008] J. LI, O. P. N. SLYNGSTAD, M. TORCHIANO, M. MORISIO, AND C. BUNSE, “A State-of-the-Practice Survey of Risk Management in Development with Off-the-Shelf Software Compo-nents,” IEEE Transactions on Software Engineering 34 (March–April 2008), pp. 271–86.
[Longstaff, Chittister, Pethia, and Haimes, 2000] T. A. LONGSTAFF, C. CHITTISTER, R. PETHIA, AND
Y. Y. HAIMES, “Are We Forgetting the Risks of Information Technology?” IEEE Computer 33 (December 2000), pp. 43–51.
[Martin, 2007] R. C. MARTIN, “Professionalism and Test-Driven Development,” IEEE Software 24 (May–June 2007), pp. 32–36.
[Mens and Tourwe, 2004] T. MENSAND T. TOURWE, “A Survey of Software Refactoring,” IEEE Trans-actions on Software Engineering 30 (February 2004), pp. 126–39.
[Miller, 1956] G. A. MILLER, “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information,” The Psychological Review 63 (March 1956), pp. 81–97;
reprinted in: www.well.com/user/smalin/miller.html.
[Murru, Deias, and Mugheddu, 2003] O. MURRU, R. DEIAS, AND G. MUGHEDDU, “Assessing XP at a European Internet Company,” IEEE Software 20 (May–June, 2003), pp. 37–43.
[Nerur, Mahapatra, and Mangalaraj, 2005] S. NERUR, R. MAHAPATRA, AND G. MANGALARAJ,
“Challenges of Migrating to Agile Methodologies,” Communications of the ACM 48 (May 2005), pp. 72–78.
[Qumer and Henderson-Sellers, 2008] A. QUMERAND B. HENDERSON-SELLERS, “A Framework to Support the Evaluation, Adoption and Improvement of Agile Methods in Practice,” Journal of Systems and Software 81 (November 2008), pp. 1899–1919.
[Rajlich, 2006] V. RAJLICH, “Changing the Paradigm of Software Engineering,” Communications of the ACM 49 (August 2006), pp. 67–70.
[Rajlich and Bennett, 2000] V. RAJLICHAND K. H. BENNETT, “A Staged Model for the Software Life Cycle,” IEEE Computer 33 (July 2000), pp. 66–71.
[Rasmusson, 2003] J. RASMUSSON, “Introducing XP into Greenfi eld Projects: Lessons Learned,”
IEEE Software 20 (May–June, 2003), pp. 21–29.
[Raymond, 2000] E. S. RAYMOND, The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary , O’Reilly & Associates, Sebastopol, CA, 2000; also available at www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/.
[Reifer, Maurer, and Erdogmus, 2003] D. REIFER, F. MAURER, AND H. ERDOGMUS, “Scaling Agile Methods,” IEEE Software 20 (July–August 2004), pp. 12–14.
[Reiss, 2006] S. P. REISS, “Incremental Maintenance of Software Artifacts,” IEEE Transactions on Software Engineering 32 (September 2006), pp. 682–97.
[Ropponen and Lyttinen, 2000] J. ROPPONENAND K. LYTTINEN, “Components of Software Develop-ment Risk: How to Address Them? A Project Manager Survey,” IEEE Transactions on Software Engineering 26 (February 2000), pp. 96–111.
[Royce, 1970] W. W. ROYCE, “Managing the Development of Large Software Systems: Concepts and Techniques,” 1970 WESCON Technical Papers, Western Electronic Show and Convention , Los Angeles, August 1970, pp. A/1-1–A/1-9; reprinted in: Proceedings of the 11th International Conference on Software Engineering , Pittsburgh, May 1989, IEEE, pp. 328–38.
sch76183_ch02_035-073.indd 72
sch76183_ch02_035-073.indd 72 04/06/10 12:34 PM04/06/10 12:34 PM
[Royce, 1998] W. ROYCE, Software Project Management: A Unifi ed Framework , Addison-Wesley, Reading, MA, 1998.
[Rubenstein, 2007] D. RUBENSTEIN, “Standish Group Report: There’s Less Development Chaos Today,” www.sdtimes.com/content/article.aspx?ArticleID=30247, March 1, 2007.
[Sakthivel, 2007] S. SAKTHIVEL, “Managing Risk in Offshore Systems Development,” Communica-tions of the ACM 50 (April 2007), pp. 69–75.
[Schwaber, 2001] K. SCHWABER, Agile Software Development with Scrum , Prentice Hall, Upper Saddle River, NJ, 2001.
[Scott and Vessey, 2002] J. E. SCOTTAND I. VESSEY, “Managing Risks in Enterprise Systems Imple-mentations,” Communications of the ACM 45 (April 2002), pp. 74–81.
[Softwaremag.com, 2004] “Standish: Project Success Rates Improved over 10 Years,” www.
softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish, January 15, 2004.
[Spivey, 1992] J. M. SPIVEY, The Z Notation: A Reference Manual , Prentice Hall, New York, 1992.
[Standish, 2003] STANDISH GROUP INTERNATIONAL, “Introduction,” www.standishgroup.com/
chaos/introduction.pdf, 2003.
[Stephens and Rosenberg, 2003] M. STEPHENSAND D. ROSENBERG, Extreme Programming Refac-tored: The Case against XP , Apress, Berkeley, CA, 2003.
[Talby, Keren, Hazzan, and Dubinsky, 2006] D. TALBY, A. KEREN, O. HAZZAN, AND Y. DUBINSKY,
“Agile Software Testing in a Large-Scale Project,” IEEE Software 23 (July–August 2006), pp. 30–37.
[Tomer and Schach, 2000] A. TOMER AND S. R. SCHACH, “The Evolution Tree: A Maintenance-Oriented Software Development Model,” in: Proceedings of the Fourth European Conference on Software Maintenance and Reengineering (CSMR 2000) , Zürich, Switzerland, February/March 2000, ACM, pp. 209–14.
[Williams, Kessler, Cunningham, and Jeffries, 2000] L. WILLIAMS, R. R. KESSLER, W. CUNNINGHAM,
AND R. JEFFRIES, “Strengthening the Case for Pair Programming,” IEEE Software 17 (July–August 2000), pp. 19–25.