System Development Life Cycle Methodologies
Henny Marske (S#864346)
System Analysis, Fall 2002


INTRODUCTION

          Organizations generally follow a set of predetermined steps for the development of information systems.  The process that they follow is referred to as the 'systems development life cycle' (SDLC). (Hoffer, 2002) However, there are many models of the SDLC that can be followed and each may be more or less appropriate depending on the needs of the organization.  The purpose of this paper is to review the various and most prominent models of the SDLC and discuss their features, strengths and weaknesses.

DISCUSSION

          There are a number of different approaches, or models, that describe the relationship between and among the various phases of the life cycle of system development each of which are used to one extent or another by organizations as they 'mix and match' these different SDLC models to fit their projects' specific and unique needs (LevelA.com).  I will review some of these including:

·          Waterfall
·          Prototyping
·          Spiral
·          Rapid Application Development (RAD)

Waterfall Model

          The Waterfall life cycle model was introduced by Winston Royce in 1970 and is currently the most commonly used model for software development. It is characterized by sequential (thus, 'cascading') phases each of which has established milestones and reviews at the end of each phase. A distinguishing characteristic is that each phase is validated before the next one can proceed.  As Boehm points out, "the successful completion of one of the life-cycle phases  corresponds to the achievement of the counterpart goal in the sequence of program engineering goals" [Boehm, 1981] He defines these sub-goals as:  feasibility, requirements, product design, detailed design, coding, integration, implementation, maintenance and phase-out.  Other waterfall models identify these goals as:  project identification and selection, initiation and planning, analysis, design, implementation and maintenance. [Hoffer, 2002] Each step must be completed and accepted before the next step can begin and, generally, none of the steps overlap. In addition, once a step has been completed and accepted, the model does not allow for further review of the steps.  One of the main reasons for the development of this model was to counteract the disorganized habits of early systems development work.  Programmers "would get an idea of what the client wanted" and then would proceed to write code.  Documentation happened as an afterthought that generally was incomplete and hard to follow. [Berard]

       The benefits of the Waterfall model include: 1) a disciplined reliance on documentation as a phase is complete until the documentation is complete; 2) evidence of progress towards the project's goals through the attainment of "milestones"; and 3) a testing of each phase. But these benefits can also render the model as inflexible and a "one way street, with no turning back". Because of this limitation, the waterfall model has evolved to the point where a return to a previous phase is allowed in what is called a "feedback loop." It is also known as the "Iterative Waterfall" because even when a phase has been completed it allows for a return to a previous step at any time and introduce a change. [Mckenzie] Obviously, the benefits of allowing a return to the previous phase overcame the initial inflexibility of the model.  In addition, the Waterfall model has other disadvantages worth noting. The documentation that is produced is not easily understood by the users thus making it difficult for them to interpret.  The first chance the customer (user) has an opportunity to review the system is after code is written, which could lead to rework should requirements not have been properly interpreted by the development team.  [Landay, 2001] It is a model that is well suited to low risk projects but that have a high risk in budget and schedule, therefore requiring predictability and control.

Prototyping

        In real world situations it is often difficult to determine all system requirements prior to testing a working (or partially working) system. This poses a problem in the Waterfall model because there is a risk that end user requirements are found to not have been fully met after a significant investment in development time has been made.  In contrast, the prototyping model allows key parts of the system to be modeled or implemented quickly to gain user feedback early in the development cycle. These prototype implementations are then disregarded, having cost relatively little to develop.  In other words, this model adds flexibility by allowing trial and error to test elements of the system before the implementation phase.  Prototyping is generally regarded as a good practice as it opens up channels of communication between the end-user and the development team.  In addition, prototyping contributes to better understanding of end user requirements.  A survey conducted by Neufelder of government software development projects indicates that "sixty percent of all errors were made in the requirements phase but only fifteen percent of the errors were caught in that phase"  [Neufelder, 1993]  It follows from this study that having a development plan that can catch errors, omissions, etc., early in the SDLC has significant benefits. 

       As with any model, there are several phases when using a prototype approach. Among them:

         1. system requirements have to be established, normally by interviewing as many users as                 possible and establishing a view of the current system;

         2. the development team arrives at a preliminary design of a future system;

         3. the users are asked to evaluate the prototype noting what features should be kept and                     what additional features must be incorporated or removed altogether;

         4. based on this end-user feedback, the prototype is refined to incorporate these inputs;

         5. the second prototype is evaluated again by the end users;

         6. a third prototype is developed with user input;

         7. when the user is satisfied, the final prototype is converted into the final system;

         8. testing and maintenance is the culmination of this model.

A distinguishing feature of prototyping is that it allows the development team to quickly turn requirements into a basic working system that can be reworked in an iterative fashion to arrive at a system that meets the end user's requirements. It is commonly referred to as evolutionary prototyping.

        Prototyping tends to be selected in situations when requirements are not clearly defined perhaps because the user is unable to precisely articulate the requirements of the proposed system.  It is also frequently used with Rapid Application Development (RAD) techniques for speed in development. The prototyping method assumes, therefore, that prototypes will be quickly developed and discarded after they are reviewed by the end-user.  In other words, these prototypes are simplified versions of a potential system that allows the user to reflect back what features are desirable, what features are to be discarded and what features ought to be included that were not coded into the system.  This activity generates another round of prototyping activities that attempt to further refine and address the requirements of the system. [Newman et. a.l, 1995]

       As with any model or method, there are also disadvantages with prototyping.  Among them one can cite:  1) a general disregard for disciplined documentation; 2) the prototypes became very "idiosyncratic" to the end-user that makes it difficult to adapt to other systems; 3) they are often developed in isolation to other systems with little consideration given to data-sharing between systems; 4) the "checks" in the SDLC are frequently by-passed causing certain important system requirements to be ignored. [Hoffer, et. al., 2002]
          
Spiral Model

          Initially presented by Boehm in 1986, the Spiral Model is a combination of the Waterfall and Prototype Model allowing "for multiple generations of prototype systems resulting in a finished system."  [NeoWorks]   Also know as the spiral lifecycle model, the spiral model is "favored for large, expensive, and complicated projects." [SearchVB.com]

          As the figure below indicates, this model is a series of cycles.  Each spiral addresses major risks that were previously identified. In other words, the method uses a risk management approach to systems development.  After all the risks have been addressed, the spiral model terminates as a waterfall software life cycle.  In this way, the spiral life cycle is similar to the waterfall model.

          For example, a software developer [BSS] announces and advertises its system development approach using the Spiral method thusly:

          The BSS Development Methodology uses the Spiral Method of Software Engineering Process to:
·          Combine the iterative nature of prototyping with the controlled and systematic aspects of Waterfall Model.
 
·          Rapidly develop software in a series of incremental releases
           (During early iterations the incremental releases may be a paper model or prototype)
 
·          Produce increasingly complete versions of the software in later iterations.

















·          



          Product Specifications are developed with the first (or more) circuits of the planning regions of the spiral.
 
·          The Prototype and sophisticated versions of the software are developed progressively by repeatedly following all the             steps enunciated in the planning regions.
 
·          Project Plans are adjusted with each spiral of the planning regions.
 
·          Cost and Schedules are adjusted based on the feedback from the Client Evaluation.

One thing to keep in mind is that as the circles widen, so do development costs incrementally become larger.

Rapid Application Development (RAD)

          Rapid application development is a methodology introduced by Dr. James Martin, an influential IT thinker who has made significant contributions to this body of knowledge, that effectively streamlines the SDLC through the use of CASE tools.  It joins the end-users with the developers for the purposes of developing a system quickly. [Thompson, 1992]  A solid explanation of what RAD is, is stated as follows:  "RAD is a concept that products can be developed faster and of higher quality through:

·          Gathering requirements using workshops or focus groups
·          Prototyping and early, reiterative user testing of designs
·          The re-use of software components
·          A rigidly paced schedule that defers design improvements to the next product version
·          Less formality in reviews and other team communication " (Whatis.com)

      So far in this discussion, the concept of "quality" has not been mentioned.  All the methodologies discussed so far and RAD have as their ultimate goal to produce a system that meets the business needs of the end-user.  In this respect, "quality" is measured as the degree to which a system meets the business needs of the end-user.  At the same time, the development effort must be cognizant of overall cost, which as we know, is impacted by the amount of development time that is required to deliver a final product.  As the label of this methodology clearly implies, rapidity in producing a final system is one of the key drivers in the selection of RAD as a methodology.  In an effort to address the issue of quality, software developers frequently adopt rapid development techniques to address this issue by relying heavily on end-user participation during the analysis and design phases of the SDLC. Involving the end-user is an accepted best-practice because (and specifically as it relates to RAD) it promotes the early detection and correction of errors. We know that early detection of errors leads to reduced costs as it takes less time to correct these deficiencies.  Software development is no different that any other value-added realization process and it is subject to the same economic forces as other production processes.  The following graphic [UCDavis] illustrates this concept:





















        In addition to end-user participation, there are other factors that contribute to the popularity of RAD as a technique that enables development teams to deliver quality systems within shortened timeframes:  1) prototyping is extensively used to render ever increasing refined systems that lead to the final product; 2) using CASE tools to "enforce technical integrity in modeling  generate 'bug-free' code  and allow for the reuse of templates and components"; 3) extending end-user involvement beyond the requirement setting phase into the construction phase; and 4) developing a "task structure that encourages parallel project activities." [UCDavis]

        As a methodology, RAD consists of four stages rather than the six stages of the traditional SDLS. In RAD, the project identification and selection and project initiation and planning phases found in the SDLS is compressed into a single planning phase. The planning phase flows right into the design phase, which represents another compression of two phases in the SDLC  analysis and design.  It is followed by the development phase and between these two (design and development) the various iterations for system refinements occur. The process ends with the cutover phase that is a compression of the implementation and maintenance phases in SDLC.

       RAD does not mean that the development of applications ignore best practices in software development.  But given the compression in time it is subject to risk. Therefore, it is incumbent on the organization to ensure it addresses certain key elements before they adopt RAD.  Hoffer et.al. refers to these elements as "pillars" and point to the work of Martin in 1991 and that of McConnell in 1996.  Each of these pillars are "necessary but not sufficient" to contribute to the success of RAD.  All have to be working in concert to assure the successful implementation of RAD. Martin's four pillars identify 1) the use of tools; 2) a "coherent" methodology; 3) the backing of management; and 4) the proper use of people. Briefly, with respect to the use of tools, CASE tools (Computer Aided Software Engineering) facilitate system development.  Second, the development methodology must clearly identify the various tasks that need to be achieved along the course of the development cycle. Third, management must support RAD. Finally, people must be properly trained and prepared to execute RAD.

        McConnell, on the other hand, suggests a different set of four pillars, which are:  1) avoiding classic mistakes; 2) applying development fundamentals; 3) managing risks; and 4) applying schedule-oriented practices.  For the classic mistakes, he suggests 36 mistakes that he groups along four main categories.  One category is the "people-related" mistakes such as poorly trained staff, turnover, understaffing the project in its early stages and having unrealistic expectations.  Another is the "process-related" category, which are mistakes that ensue because of poor planning, optimistic schedules and "planning to catch-up later." The third category of classic mistakes is "product-related." Here McConnell suggests that scope creep and "requirement gold-plating" are the most common mistakes.  Finally, "technology-related" is the fourth category of classic mistakes.  In this case, mistakes are made because of a reliance on a technology as a "silver-bullet" with the promise to solve all problems as well as being overly optimistic in the savings that can be expected from new tools.

        As an example of practical application of RAD methodology, Gong, Scott, Xiao and Offen discuss RAD as an  approach in their research of meta-CASE tool development design.  They define meta-CASE tools as "providing generic CASE tool components that can be customized  into particular CASE tools" and " address the particular needs of organizations, projects and individuals without the high cost of building customized CASE tools from scratch."  In their research they focus on "the development of a rapid CASE tool design environment" using the meta-CASE tool so that users (programmers/developers) can focus on their task rather than on figuring out the usage of meta-CASE tools.  This is perhaps a very esoteric and refined usage of RAD but it serves the purpose of illustrating that RAD can be applied to different system development environments. [Gong, et.al., 1997]  A more well-known practical example of RAD use is the case of DuPont that invested about $14 million to create an infrastructure that would allow for the "responsible" development of applications by using "RAD-like" tools and techniques. They cite that this approach resulted in an estimated $18 million in cost development savings over a five-year period.  [Thompson, 1992]

          In summary, the life cycle of system development goes through several structured stages.  All have the ultimate deliverable goal of realizing an application that meets the end-user's business needs.  System developers follow a predefined set of tasks that are defined by the organization to which they belong.  The selection of a particular methodology is a dependent on several factors, on the philosophical inclinations of the organization as well as on the characteristics of the project.  The Waterfall Model of the SDLC is the more traditional of all approaches and also the more structured and inflexible of the lot.  While RAD is on the other side of the continuum offering organization a platform on which their application development cycles can be significantly reduced.  


REFERENCES


[Berard] Berard, Edward V.,  Life-Cycle Approaches (http://www.itmweb.com/essay552.htm)

[Boehm,1981] Boehm, Barry W., Software Engineering Economics, Prentice-Hall, Inc., New Jersey, 1981.

[Boehm,1986]  Boehm, Barry W. , "A Spiral Model of Development and Enhancement," Software Engineering Notes, Vol. 11, No. 4, August, 1986.

Davis, Alan M., et. al., A Strategy for Comparing Alternative Software Development Life Cycle Models, IEEE Transactions on Software Engineering, October 1988.

[Gong, et. al., 1997] Gong, M., L. Scott, Y. Xiao, R. Offen, "A Rapid Development Model for Meta-CASE Tool Design," as found in Embley, David W. and Robert C. Goldstein (Eds.), Conceptual Modeling  ER '97, 16th International Conference on Conceptual Modeling, Los Angeles, CA, November 1997 Proceedings. Springer, 1997.

Hoffer, Jeffrey A., Joey F. George, Joseph S. Valacich. Modern Systems Analysis & Design. Prentice-Hall, New Jersey, 2002.


LevelA.com (http://www.levela.com/software_life_cycles_swdoc.htm)

McConnell, Steve. Rapid Development:  Taming Wild Software Schedules. Microsoft Press, 1996.


NeoWorks (http://www.neoworks.com/info/technologies/process/)

[Neufelder, 1993] Neufelder, Ann Marie, Ensuring Software Reliability, Marcel Dekker, Inc., New York, New York.

Newman, W.M. and Lamming, M.G., Interactive System Design, Addison-Wesley, 1995.

Royce, W.W., "Managing the Development of Large Software Systems: Concepts and Techniques," Proceedings, WESTCON, August, 1970.

Schneider, Kurt (1996) "Prototypes as Assets, not Toys  Why and How to Extract Knowledge from Prototypes", Proceedings of ISCE-18, 522-531, Institute of Electrical and Electronics Engineers, Inc.

[Thompson, 1992] Thompson, Don, Reorganizaing MIS: The Evolution of Business Computing in the 1990s, SAMS, A Div. Of Prentice-Hall, Carmel, Indiana, 1992.

[UCDavis] as found in: http://sysdev.ucdavis.edu/WEBADM/document/rad-components.htm, accessed November 2, 2002, 11:38 am.