 All of the projects over the life of a product when taken together, along with product inception and wrap-up, make up a product's complete life cycle. Depending on the development methodology used, project life cycles may be stacked end-to-end or they may occur in parallel. How much "parallelization" occurs and how the features within the projects and/or releases are allocated is reflective of the methodology being used. Some of the more common ones are:
- Linear - Stacked end-to-end.
- Waterfall - Feature sets are implemented incrementally in parallel until all of the desired features have been added.
- Iterative, Spiral, or Evolutionary - Features are evolved as the requirements are refined. Typically, the features are implemented in an engineering determined order to make the final delivery as early as possible.
- Agile - Features are implemented and re-implemented as requirements are refined in conjunction with the end users. Those of highest priority to the end-users are typically implemented first.
Before we get into the details, please note that the following figures are NOT to scale, either chronologically or in terms of effort. In fact, it depends on both methodology and corporate culture as to how much relative time is allocated to each item (or component, or task, or...). Also note that for ease of reading, only the first two figures explicitly show the Code Repair component. Please assume it is present in subsequent figures unless otherwise mentioned. None of the figures explicitly show a Production Repair component, though with the exception of the first one, it is implied and should be assumed to be present.
The first life cycle model, shown in the figure below, illustrates a Linear, single phase life cycle where no stage is started until the previous stage has completed and the cycle does not start over. Since only a single cycle is performed, the product is most likely either an extremely simple one or has a one-shot implementation specified in the contract. In cases of this kind, it is not unusual for post-production maintenance to be undertaken by the end users instead of the developing organization. The biggest downside to this model is that no one learns from mistakes made unless the results are so bad that the end users provide feedback. The upside is that ORT (Operational Readiness Testing) is often attended by customer representatives where their feedback against the initial requirements is factored into the Code Repair stage. When this occurs, ORT takes on the aspects of User Acceptance Testing (UAT).
Figure 1 - Linear Software Development Life Cycle
When two or more Linear cycles occur and each cycle starts only after ORT completion, a Waterfall life cycle is defined, illustrated by the figure below. Since each linear stage completes before the next stage starts, the maximum amount of control on the evolution of the product is allowed. If separate teams or departments are responsible for each stage, they are freed up to start work on other projects or products as soon as they have completed their current stage. This allows for maximum specialization, but learning from mistakes is difficult because the defects logged against each stage are often addressed by someone other than the original authors. This is often the way DOD (Department of Defense) projects are implemented. The implications are that the requirements are well defined up front for each cycle and that Production fixes are kept to a minimum.
Figure 2 - Waterfall Software Development Life Cycle
The figure below illustrates a simple Parallel life cycle. Each stage completes before the next stage starts, thus minimizing the surprises within a cycle, but the completion of each stage frees up the personnel assigned to it to immediately start work on the next cycle's work. The assumption is that the same teams or departments are responsible for the same stage in each cycle. Thus Requirements Engineering is always performed by the same personnel and they can learn from mistakes in previous cycles as well as factor in any corrective actions needed based on defects or change requests. The downside is twofold:
- Upstream (previous cycles') defects must effectively wait until the next cycle before being addressed, and
- Since the same personnel are always working on the same stage there is a tendency for both burnout (where they can no longer stand to work on the product) and burn-in (where they are so used to seeing the same thing that they can "no longer see the forest for the trees").
Note that more than one Production stages may be active at any one time. This is normal and is one of the desired benefits of this model. The iterations are short enough that, while real change to the product is possible, there should not be such a drastic change that it is mandatory for the end users to upgrade immediately. This often leads to increased support costs, but at the same time an increased level of customer satisfaction.
Figure 3 - Simple Parallel Software Development Life Cycle
The figure below illustrates an Incremental life cycle where stages themselves may be paralleled. This model is also referred to as either a Spiral or an Evolutionary life cycle. The major requirement is that no stage begins work based on the previous stage until the portion(s) relating to it are essentially complete. The checkered areas indicate times at which a stage is essentially unable to do any work, but that can be used as slack time for regression testing.
Figure 4 - Incremental Software Development Life Cycle
While it looks like each stage stays busy from the time it starts to the time it ends, this is not really the case. In the figure below it is possible to see a qualitative indication of how efforts are applied in each stage of a cycle. The major advantages of this model over the Parallel model is that it shortens the effective cycle time while still giving each stage the same overall time it has in the Parallel life cycle. The Incremental model also allows testers to more easily slip from upstream testing stages to those further downstream as they complete their workload. The Incremental model has all of the disadvantages of the Parallel model with the additional risk of not getting the needed information from upstream stages in time to prevent rework.
Figure 5 - Incremental Workload
In the past few years, there has been a trend to take the Incremental life cycle model to the extreme and focus more on the Code and Unit Test stages (hence the name Extreme Programming). This is accomplished by using short iterations and reviewing the results with the customer to refine the requirements almost on-the-fly. This combines the process of Requirements Elicitation, Rapid Prototyping and Incremental Product Development in a fashion that reduces overall rework at the end of the product development at the expense of smaller refinement rework earlier in the process. Extreme Programming became more of a template for the evolution of other Agile methodologies with the concepts of Sprints and SCRUM being the one most often extended beyond small teams or to larger, more complex projects.
The two figures below illustrate two different variations on Agile life cycles. The first is a simple one-sprint team Agile life cycle. It shows three iterations, or three sprints, one after the other. Each sprint follows the one before it, but each group (Requirements Engineering, Design and Development) are able to start in parallel with other work. In other words, Requirements Engineering can start work on the second iteration while Coding and Unit Testing are still proceeding on the first iteration. Note that the overlap of groups is similar to the Incremental SDLC described earlier. This is because the Agile life cycle evolved from it by performing additional testing earlier and by making multiple iterations prior to a production release.
Figure 6 - Simple Agile Software Development Life Cycle
The second figure illustrates two of possibly many sprint teams operating in parallel on a single product's development. They may be though of as separate projects by some, but that is not really what is happening internal to the development process. It is more likely that each sprint team is working on a different function or requirement set.
The major advantages of this approach are:
- Features (or feature sets) can be developed in parallel, but their introduction into the production codebase can be deferred to an appropriate time.
- Each sprint team may have specialized knowledge or expertise that allows them to be more efficient in implementing certain features over others.
- When multiple end-user stakeholders (customers) are involved, it allows some level of isolation as each feature set is able to be refined independent of others' needs.
The major disadvantages of this approach are:
- It requires the addition of Code Integration and Unit Test stages to pull the various sprint teams' results together.
- It requires discipline to ensure that the requirements specified by multiple end-user stakeholders do not conflict with each other.
- It requires discipline to ensure that any changes to common code between sprint teams are managed properly and subsequently merged with intelligent human participation and review.
Figure 7 - Multiple Sprint Agile Software Development Life Cycle
The part of the Agile life cycle that is generally not shown is the initial ramp-up. This is in addition to the product initiation and wrap-up stages mentioned at the beginning of this article (see Product vs. Project SCM). The reason for this is that there needs to be a core of base functionality present for the rest of the Agile development to use. This base functionality includes the architecture or hierarchical decomposition so that pathological connectivity between subsequently developed functions is kept to a minimum. This is critical when more than one sprint team is being used since Agile almost always involves refactoring code and this can make for very difficult merges when the teams' codebases are integrated together. As is apparent from the figure below, it is still possible to develop this initial ramp-up using iterations. It is just not as agile as Agile.
It is not uncommon, especially when market pressures are present, that Agile development will commence prior to the completion of the core architecture. If this occurs, always remember that the core always wins in a battle with the sprints. It may evolve as needs changes, but it always wins. If it doesn't, maintenance will be much more difficult and costly and the duration needed by each sprint will increase over time. It also leads to inconsistent UIs, differences in business logic in separate parts of the product, etc.
Figure 8 - Agile Software Development Life Cycle - The Missing Piece
Finally, the view of SCM as regards Software Development Life Cycles is shown below. The two key components of SCM, Version Control and Defect/Issues/Enhancement Tracking, are shown as repositories. The various data flows from the aggregate SDLC phases are shown in relation to these repositories. Note that the process shown is independent of any tools used to implement it.
Figure 9 - Software Configuration Management View of the Software Development Life Cycle
As the figure above shows, there is an assumption that feedback occurs at al levels. If a defect is detected in a requirement, then that defect is addressed at some point in time by those responsible for maintaining the requirements. The same goes for Design, Coding and Test. Note that while not explicitly shown, defects in the process being followed as well as in the CM tools, tool configurations, tool integrations, and supporting infrastructure (triggers, build scripts, etc.), also follow the same pattern of detection, logging, feedback, correction, test and redeployment.
One of the big problems out in the "real world" is that this feedback, especially to the Requirements and Design teams rarely happens. Or if it happens, it happens far too late to be effective in propagating the defect down stream, perhaps even into production. The further along one is towards the Agile model, the more one would assume that feedback takes place in a timely fashion. What often ends up happening is that the feedback is along the lines of look-and-feel more than it is about back-end processing and interfaces to outside systems.
In summary, each life cycle model has its advantages and disadvantages. There are still times where Waterfall is the appropriate model to use. As the need for faster turnaround and shorter delivery schedules comes into play, the further towards Agile one tends to go. There is no real difference in how CM is applied, regardless of which model is used, only the tools needed to support the increasingly rapid codebase churn and decreased testing cycles.
Some ask, "If all of the models are useful, why does it seem that Agile is everyone's first choice for new projects - or even for projects that are in trouble?" The answer is that in many cases Agile is oversold as a silver bullet. Agile takes a mindset change as well as process change. One cannot simply take the parts of Agile that one finds "attractive" such as short development and test cycles without refactoring the requirements and doing enhanced testing up front. Selecting an accelerated life cycle model is like driving a high performance race car - if you don't follow all of the steps necessary to keep the car in shape, the mistakes you make will tend to be fatal, or to at least sideline one while others finish first.
Ben Weatherall is currently based in Fort Worth, Texas where he practices Practical CM on a daily basis using a combination of CVS and custom tools to support a modified Agile-SCRUM development methodology. He is a member of IEEE, ASEE (Association of Software Engineering Excellence – The SEI’s Dallas based SPIN Affiliate), NTLUG (North Texas Linux Users Group), and PLUG (Phoenix Linux Users Group)
Trackback(0)
Comments 
Write comment
 |
CM Journal Articles 
TrackBack URI for this entry
Subscribe to this comment's feed