ACM SIGSOFT Software Engineering Notes Page 8 May 2010 Volume 35 Number 3 SDLC, then, is a conceptual framework or process that consid- ers the structure of the stages involved in the development of an application from its initial feasibility study through to its deploy- ment in the field and maintenance. There are several models that describe various approaches to the SDLC process. An SDLC model is generally used to describe the steps that are followed within the life-cycle framework. It is necessary to bear in mind that a model is different from a methodology in the sense that the former describes what to do whereas the latter, in addition, describes how to do it. So a model is descriptive whilst a methodology is prescriptive. As a result, we consider SDLC models in this article in terms of their relev- ance to particular types of software projects. This approach re- cognizes the context in which a SDLC model is used. For example, the waterfall model may be the best model to use when developing an enterprise relational database but it may not be the optimum model when developing a web-based application. I therefore consider the models for three distinct use cases, or soft- ware categories, in order to provide a context for their applica- tion, as follows: Software Development Lifecycle Category 1.Software that provides back-end functionality. Models Typically, this is software that provides a service to Nayan B. Ruparelia other applications. Hewlett-Packard Enterprise Services Category 2. Software that provides a service to an end-user or to < [email protected] > an end-user application. Typically, this would be DOI: 10.1145/1764810.1764814 software that encapsulates business logic or formats http://doi.acm.org/10.1145/1764810.1764814 data to make it more understandable to an end-user. Category 3.Software that provides a visual interface to an end- Abstract user. Typically, this is a front-end application that is a graphical user interface (GUI). This history column article provides a tour of the main soft- SDLC models, also, may be categorized as falling under three ware development life cycle (SDLC) models. (A lifecycle covers broad groups: linear, iterative and a combination of linear and all the stages of software from its inception with requirements iterative models. A linear model is a sequential one where one definition through to fielding and maintenance.) System devel- stage, upon its completion, irrevocably leads to the initiation of opment lifecycle models have drawn heavily on software and so the next stage. An iterative model, on the other hand, ensures that the two terms can be used interchangeably in terms of SDLC, all the stages of the model shall be revisited in future; the idea especially since software development in this respect encom- being that development remains a constant endeavor for im- passes software systems development. Because the merits of se- provement throughout its lifecycle. A combined model recognizes lecting and using an SDLC vary according to the environment in that the iterative development process can be halted at a certain which software is developed as well as its application, I discuss stage. three broad categories for consideration when analyzing the rela- Although there is an abundance of SDLC models in existence, tive merits of SDLC models. I consider the waterfall model be- we shall consider the most important ones or those that have fore the other models because it has had a profound effect on gained popularity. These include: the waterfall, spiral, unified, software development, and has additionally influenced many incrementing, rapid application development, the v and the w SDLC models prevalent today. Thereafter, I consider some of the models. mainstream models and finish with a discussion of what the fu- ture could hold for SDLC models. Waterfall Model Keywords: SDLC, SEN History Column, Waterfall, Spiral, The waterfall model, also known as the cascade model, was Wheel-and-spoke, Unified, RAD, Incremental, B-model, V- first documented by Benington [1] in 1956 and modified by model. Winston Royce [2] in 1970. It has underpinned all other models Introduction since it created a firm foundation for requirements to be defined SDLC is an acronym that is used to describe either software or and analyzed prior to any design or development. systems development life-cycles. Although the concepts between The original cascade model of Bennington recommended that the two are the same, one refers to the life-cycle of software whe- software be developed in stages: operational analysisĺ RSHU a- reas the other to that of a system that encompasses software de- tional specification ĺGHVLJQ and coding specifications ĺGHYH l- velopment. In this article, software development is emphasized opment ĺWHVWLQJĺGHSOR\PHQWĺHYDOXDWLRQ%\UHFRJQL]LQJ although the same principles can be transmuted to systems. Also, that there could be unforeseen design difficulties when a baseline most of the innovation and thought leadership in terms of devis- is created at the end of each stage, Royce enhanced this model by ing models and concepts has come from software development, providing a feedback loop so that each preceding stage could be and systems development has borrowed heavily from software revisited. This iteration is shown in Figure 1 using red arrows for development as a result. ACM SIGSOFT Software Engineering Notes Page 9 May 2010 Volume 35 Number 3 the process flow; this allowed for the stages to overlap in addition The waterfall model is the most efficient way for creating to the preceding stage to be revisited. But Royce also felt that this software in category 1 discussed earlier. Examples for this would arrangement could prove inadequate since the iteration may need be relational databases, compilers or secure operating systems. to transcend the succeeding-preceding stage pair’s iteration. This would be the case at the end of the evaluation (or testing) stage B-Model when you may need to iterate to the design stage bypassing the In 1988, Birrell and Ould discussed an extension to the water- development stage or at the end of the design stage where you fall model that they called the b-model [3]. By extending the op- may need to revisit the requirements definition stage bypassing erational life-cycle (denoted as the maintenance cycle) and then the analysis stage. That way, the design and the requirements, attaching it to the waterfall model, they devised the b-model as respectively, are redefined should the testing or the design war- shown in Figure 2. This was done to ensure that constant im- rant. This is illustrated in Figure 1 by the dashed arrows that show provement of the software or system would become part of the a more complex feedback loop. Further, Royce suggested that a development stages. Also, they felt that an alternative to obsoles- preliminary design stage could be inserted between the require- cence needed to be captured so that enhanced or even newer sys- ments and analysis stages. He felt that this would address the cen- tems could be developed as spin-offs from the initial system. tral role that the design phase plays in minimizing risks by being re-visited several times as the complex feedback loop of Figure 1 shows. Figure 1: Waterfall model with Royce’s iterative feedback. When referring to the waterfall model in this article, I shall mean Royce’s modified version of Benington’s cascade model. One aspect of the waterfall model is its requirement for docu- mentation. Royce suggested that at least six distinct types of doc- ument be produced: 1) Requirements document during the requirements stage. 2) Preliminary design specification during the preliminary design stage. 3) Interface design specification during the design stage. Figure 2: The b-model extends the waterfall model. 4) Final design specification that is actively revised and up- In a sense, the b-model was an attempt to modify the waterfall dated over each visit of the design stage; this is further up- by creating an evolutionary enhancement process that was cap- dated during the development and validation stages. tured by the spiral model that we shall discuss later. The b-model, 5) Test plan during the design stage; this is later updated however, is more suitable to the development of category 1 soft- with test results during the validation or testing stage. ware like its cousin, the waterfall. 6) Operations manual or instructions during the deployment stage. Incremental Model Quality assurance is built into the waterfall model by splitting The incremental model, also known as the iterative waterfall each stage in two parts: one part performs the work as the stage’s model, can be viewed as a three dimensional representation of the name suggests and the other validates or verifies it. For instance, waterfall model. The z-axis contains a series of waterfall models the design stage incorporates verification (to assess whether it is to represent the number of iterations that would be made in order fit for purpose), the development stage has unit and integration to improve the functionality of the end product incrementally. testing, and the validation stage contains system testing as its part The incremental model, in this sense, is a modification to the wa- and parcel. terfall that approaches the spiral model. ACM SIGSOFT Software Engineering Notes Page 10 May 2010 Volume 35 Number 3 The main strengths of this model are: the spiral model adds user involvement during its risk reduction i. Feedback from earlier iterations can be incorporated in activities whereas the v and the waterfall models incorporate it the current iteration. during the initial requirements definition phase. Additionally, the ii. Stakeholders can be involved through the iterations, and risks and opportunities feature of the vee+ mean that certain stag- so helps to identify architectural risks earlier.