Which SDLC Model to choose waterfall, Slamdunk, Spiral, Evolutionary, Stage Gate, Rapid Prototype, Agile, and Sync-Stable
The name of the waterfall lifecycle model comes from its physical appearance, shown in Figure , and the process by which the results from one phase flow into the next. An alternative name for this model is the “Big Bang” lifecycle because working results first appear near the end of the process, something like how scientists describe the Big Bang theory of how the universe was created. The waterfall model is simple, easy to learn, and easy to use. I and others have used it successfully in its standard and modified forms. The format of this model makes it easy to document, update, and refine using software such as Office Project and other Gantt chart–based project management systems.
- Some experts imply that this lifecycle is not appropriate for software development or is in part responsible for problems in software projects .
- One source of problems in the waterfall approach is that there is little or no functionality that works, and then, at some point well into the project, a system appears. This is from software development communities that do not develop the early deliverables called for in the waterfall model (for example, a system design document). The focus of these groups is on producing the executable code while ignoring the long-term value of the other artifacts (such as design documentation) that are a vital part of a sustainable product.
- Those who have managed unsuccessful software projects and who have concluded that the problem was the software lifecycle model used and not the management of the project. These and others propose their own variations. The waterfall model still takes the project from the stage of not knowing what is going to be built to building it. These variations change some details of how this occurs or innovate by developing the system incrementally using early prototypes and mini-waterfall lifecycles. In the mini-waterfall lifecycle strategy, the complete system is broken down into separate subsystems, each with its own development and build schedule or schedules. In this way, short-term, incremental deliveries reduce the risk and anxiety inherent in a Big Bang development effort.
- A more serious criticism of the waterfall model is that it is not a good fit for the iterative manner in which humans solve complex problems. This problem can be solved by frequently updating or iterating the Gantt chart (which looks like the waterfall model) as the project proceeds to reflect both the positive and negative changes that must be made to the project plan.
Slam Dunk Model
The slam dunk lifecycle model predates just about all lifecycle models and is quite simple. The name for this model is derived from the expression in basketball used to describe the act of slamming the ball through the hoop. Customers, managers, and software developers all have a fair idea of what needs to be built. No real process, design, or plan is developed. The approach is trial and error. It does not usually lead to a viable product. Code is generated, debugged, perhaps even demonstrated, and then further enhanced, and so forth. Often, no overall system architecture is developed. In general, this approach has not consistently produced results. It is mentioned here because it is seen by some as viable.
Cost is represented in the model by the distance from center: the farther from the center the project is, the greater the cost because to get from the center to an outer ring the project must go through several stages over again. A key feature of this approach is the risk gate that is invoked between phases during which risk is assessed, mitigated, or otherwise dealt with, including curtailing or greatly modifying the project. At each stage, cost is incurred, and the costs continue to add up.
The advantage of this approach is that it focuses clearly on the objectives of the effort from several different viewpoints. These same viewpoints are employed in different contexts, and the context changes each time around the spiral. It encourages the reuse of code and exploration of alternatives. As we proceed from the center of the spiral toward the outer rim, we pass through a series of phases having a common title, prototype. This lifecycle engages the concept of prototyping that starts simply with a conceptual view of operation and some risk analysis (that is, “1. Prototype”) and ends with an “Operational Prototype” that lies on the outermost rim and, although unnumbered, is actually stage 4 in this cyclic model. Compared with the slam dunk model discussed earlier, the spiral lifecycle model skips the internal cycles during which the team refines their model through design and analysis and jumps right into coding. This is one of the ways that this model is something of a composite of all software lifecycle models.
Notice that at each stage, the objectives to be achieved are stated. It is implicit that not achieving the stated objectives from a previous round can cause the project to be reevaluated or canceled. In this regard, the spiral lifecycle model bears some resemblance to the stage gate approach discussed later in this chapter. The spiral model is purported simply to represent what “really” happens in a software development project. It formalizes and documents the process. However, tracking status and communicating with stakeholders are made very complex in the spiral model, which might be why there are no significant testimonials as to the model’s effectiveness.
The idea behind the evolutionary lifecycle model is, just as the name implies, the evolution of the system from an idea to successively refined, feature-enriched, and less error laden versions of the system. This model is built upon the concept of “build a little, test a little, repeat,” which is illustrated in Figure above. This concept has been refined more recently and published as the Agile programming lifecycle, discussed later in this post. The build-test cycle is similar to the way building construction is done: at key points in the construction process, inspections occur (similar to software testing) to ensure that the work done to that point is of sufficient quality to warrant proceeding to the next phase of construction.
My experience with this approach is on a project for which we combined the evolutionary model with the waterfall lifecycle model. The software development team for the project was very inexperienced. We addressed the architectural issue and through the successive refinement technique were able to overcome the inexperience of the team members. With some discipline, teams can use this approach quite effectively when the team needs to work together to build confidence in themselves and in the team as a whole. This can be an expensive proposition because changes late in the lifecycle become inordinately more expensive. For the project I worked on, we reduced this risk by creating an overall system architecture at the start, stubbing everything in, and replacing the stubs in conjunction with an implementation plan that strategically employed parallelism.
Not surprisingly, some proponents of this concept consider it the best way to develop software. Those who oppose it point out that it deemphasizes the importance of establishing the overall architecture for the system from the start, which subsequently results in a considerable amount of rework late in the lifecycle. Also, the benefits of stabilizing the system and releasing changes in batches could be lost if the cycle time between one set of changes and the next is too short.
Stage Gate Model
It looks like projects using this model might be doomed to failure because of the sequential nature of the stages depicted here; complaints from several peers about this model concern the sequential lifecycle processes. However, a lot of work is done in parallel to foreshorten development time and ensure timely completion. Also, what happens in each stage is prescribed by the process descriptions adopted by the development team. For example, pair programming, walkthroughs, and continuous testing could all be used as well as other methods and techniques.
The stage gate lifecycle model comes in various flavors, some of which have been trademarked under the title “Stage Gate.” This model has its origins in the manufacturing sector. The idea is relatively simple: Parts and subassemblies are staged. When all of the required parts, subassemblies, inspector signoffs, and any required tests have been completed, they pass through a virtual gate and are assembled into the next largest subsystem or perhaps the final system. In the software arena, this approach addresses the following requirements:
- Reduce risk to the project resulting from out-of-control development
- Improve the quality of deliverables
- Ensure that the processes put in place are followed
- Reduce the flow time through the development process
- Focus on all aspects of the software being produced
- Have a clearly stated set of goals and specific tasks that are achievable in the short term
At first glance, this approach might seem rather old school, and it is. But think back for a moment. How many times has the daily or weekly build been brought down by the fact that someone turned in code that should have been unit tested and regression tested prior to acceptance? This lifecycle model enforces the organization’s policies, prevents problems, and reduces rework and errors.
The idea of the gate might be a new concept to some managers. Gates are positioned at critical points in the lifecycle. They have a vital role in that before a project can proceed to the next stage, a review committee examines artifacts (such as presentations, documents, test cases) appropriate to that stage and evaluates them against standards established for that project and for the company overall. The committee makes one of four decisions:
Go Everything is in order, and the project can proceed to the next stage.
Cancel The project is in serious enough trouble that it should be disbanded here and now. Yes, some projects would have been better off if they had been canceled!
Hold At this point it would be best to suspend the project for the time being (for example, the market for the product is deteriorating, the customer is considering canceling, and so on).
Recycle Direct the project to correct/enhance the current results and try for approval again.
My experience with the stage gate lifecycle involved the development of a portion of an service desk system. The difficulties we were having gaining stability in previous efforts could be traced back directly to some programmers not following the configuration management and other content control practices adopted in our firm—people were turning in code that had not been walked through with their peers, that was untested, and so forth. Although instituting this lifecycle approach as an experiment caused a lot of complaining from the members of our team, it resulted in the fastest-to-market, lowest bug count we had experienced. This occurred even though this was a new product.
The challenge for software project managers using this approach is to “stay the course” and not to succumb to complaints from the development team regarding having to move through such strict processes. This aspect of the stage gate method is the source of most complaints about it from managers and developers alike.
Rapid Prototyping Model
The rapid prototyping approach uses the prototype as a means of developing a specification. For those not familiar with the term prototype, it means a mockup or stand-in. Prototypes have been used for many years in industries where the final product is too expensive to build and abandon in favor of a more robust or feature-laden version. In software, prototypes often take the form of a series of user actions and corresponding screens enabling the user to evaluate the process of navigating through the interface to achieve some objective. These screens have only the functionality behind them needed to support the navigational activity.
The assumption here is that improving communication with the client through the client’s ability to actually see and use the system as envisioned by the developers will ensure that what is delivered is what the client really wants. The danger here has been that prototypes have often become production systems. Clients see the prototype, it has a fair number of important features that work, and the client’s reaction is often to believe that the system is complete and only needs some minor cleanup. This approach requires a mature, disciplined development team to prevent runaway coding and to ensure that the client is educated enough to realize that what they are viewing is only a prototype and not a viable commercial product.
Often, once the specification portion is finished, it is difficult to get the development team to quit coding and get back to the problem of designing the solution. This approach treats robustness characteristics such as availability, safety, and security as afterthoughts in the rush to produce a working artifact. An additional problem is the fact that often it is not the customer or the developers who want to accept the prototype as a deliverable but the marketing people—they see something that can be sold and start selling it prematurely.
The Agile programming approach is actually a compendium of best practices gleaned from other lifecycle methods and programming practices that have been successful plus some added nuances. It employs continual interaction with the client by including a client representative on the development team. Although this might sound like a new practice, it was employed on more than one project more than 30 years ago.
The figure above depicts the Agile lifecycle model. Many of the ideas this lifecycle model promotes work well on their own. In Figure below, the vertical bars represent 2-week intervals; longer intervals can be used, but it is not recommended. This is the “nominal” time delta. Analogous to a miniature lifecycle, within each of these 2-week periods, a certain volume of work is completed, and working code results. This volume of work is referred to as a set of story points. A use case or Stimulus-Response scenario (SRS) technique is used to collect stories. The ratio is one use case or SRS per story. Each story is written on an index card or some other recording mechanism that is easily accessible to the entire project group. Each story is assigned an index score (story point) relative to its degree of difficulty. An optional guide is to have story points for a single story range from 1 to 10, but the upper level can be adjusted as more experience is gained using the technique.
In Agile programming, software engineers work in pairs. Pairs work at the same development workstation and share a keyboard. A pair is usually composed of a more senior, experienced developer and a less experienced one. Some people argue this lowers the productivity of the senior person. Although this might be true, over the course of a reasonably long project (such as 6 months) productivity for the group as a whole actually increases.
One concern expressed about this almost continual change approach is stability. Each batch of nuances or changes occurs on a short-term cycle, resulting in a lack of maturity in the resulting system. Even though there is continual testing, there is also continual change, which goes against recommendations by many experts and others regarding how to ensure that projects are successful. Their recommendation is that changes should occur in a burst, and then no changes should occur while testing takes place (a stable period), followed by another controlled burst of changes, and so forth. In Agile development, this stability issue is addressed by requiring daily builds that run, continual testing, and the application of coding standards that evolve over time. Also, the earlier admonitions regarding changes were based on a Big Bang style of development. That is, work went on for months with no running code, and then, at some point, a build happened.
The development team estimates how many stories it can achieve during the first 2-week period. They do this by simply selecting, in conjunction with the customer, several of the stories and adding up their story points. For example, they might select 50 points’ worth of stories for the first 2-week period. A schedule is estimated by taking the total number of points contained in the total set of SRS or use cases and dividing by the number of story points the team believes they will average per 2-week period. For example,
- Total Number of Story Points for Project = 2,000
- Estimated Average Number of Points/period = 50
- Estimated Project Duration (2,000 / 50) = 40 periods
At the end of the first period, the team counts up how many points they actually completed, and they adjust the schedule estimate accordingly, up or down. This early result is used as an assumed work rate. This process is repeated at the end of each subsequent period, and the average number of story points (estimated) per remaining period is recomputed based on the preceding weeks.
If the schedule starts to slide, the customer has the choice of living with the slide, hoping things will get better later, or deferring some features to a later release to maintain the original schedule. Usually, the customer selects lower-priority features or stories and defers them to the next release. Enough of these are selected so that the original date or an acceptable date for first release is achieved. This encourages, even requires, that the customer make some difficult decisions regarding what must absolutely be included in the system and what is optional.
What is really powerful about this technique is that it employs something similar to an engineering principle called design to cost. That is, given that we have only this much time and money, this is what we can deliver. Moreover, the customer is in control of which features the system will contain and can determine priorities based on business objectives, the marketplace, and their corporate strategy. This control on the part of the customer is extremely important in gaining acceptance of the results, no matter what they are.
Another concept employed by the Agile approach is that testing occurs continuously. This is possible because, right from the end of the first period, there is a running system. Granted, it will not have much functionality at first, but over time it will. The customer can use it and give feedback to the development team. All of this takes place very early in the project.
Agile programming employs three bases: customer business practices, developer practices, and quality assurance practices. The degree to which each set of practices affects a project is dependent on the quality assurance practices and their effect on the resulting system. Terms used to describe the practices in each category are presented in the table by category.
Developers, stakeholders, business analysts, quality assurance people all working together as a team.
Involves the use of cards or other schemes to identify each feature/ requirement that is part of the project; one feature or requirement per card.
Releases occur (typically) on a 2-week cycle. Supported features at each of these internal release points are available for the customer to experience and critique.
Tests are developed by the quality assurance group, one per card. Tests are automated as much as possible except for user interface–related testing, which occurs throughout the project with the biweekly releases.
The Agile approach has a considerable amount of merit, a growing number of devotees, and some positive reports regarding its effectiveness in small to medium-size projects. This model gathers early and frequent feedback, thus aligning the approach with iterative human problem solving. However, there are some cautionary notes to acknowledge. One is that this approach, perhaps more than any other that is popular today, could result in runaway programming. This can be overcome only if the project has a cadre of disciplined senior software engineers and a mature software project manager. If it is a small project, perhaps only one or two senior people are required, but someone has to ensure that the project maintains the discipline and practices inherent in this method.
Synchronization and Stabilization Model
The synchronization and stabilization approach is employed at Microsoft and, perhaps, other firms. It is similar to the incremental approach. Starting with requirements, the team generates a specification, sets priorities, and divides the effort into four major builds. These major builds are called Release Candidate (RC) 1 through RC 3 and Release to Manufacturing (RTM). RC 1 is the first major build and represents the point in the development cycle, with the widest range of possible changes in code and content3.
As time passes and subsequent RCs are established as baselines, the threshold for approving changes to the code rises, the number of newly introduced features decreases, and bug content drops significantly. The most serious and even minor bugs are absent by the time RC3 is established. Note that in the time frame between releases, Agile or any other development lifecycle model can be used. The key here is achieving the goal of stability and maturity in the released product.