Matching software development life cycles to the project environment
Just as each project is intended to create a unique product or service, the environment in which the project is undertaken is unique. This is especially true with software development projects. The organizational characteristics, the degree of familiarity with the technologies to be used, and the competitive demands for initiating the project are just some of the environmental factors that can differ from project to project. The success of the project is greatly influenced by the extent to which these environmental factors are identified and acted upon. Of primary concern for software development projects is the selection of a development life cycle best suited for the environment in which the software is to be developed.
The objective of this paper is to encourage conscious identification of the environmental factors during the planning phase and matching those factors to the selection and use of the most suitable development life cycle. It is not uncommon for organizations to adopt a singular approach to software development. If the project environment is predictable and repetitive, the singular approach may be the most efficient. However, for the dynamic project environments typically found today, care and consideration needs to be given to the selection of the development life cycle to be employed.
For every project, there is a unique set of circumstances in which the project is undertaken. Taken together, these circumstances, or the degree to which different variables exist or do not exist, constitute what we will refer to as the Project Environment. There are a multitude of variables that define the Project Environment and a multitude of ways in which to organize those variables. There is no one definitive classification of variables. What is important is for the organization developing the software to define those variables they see as influencing the decision to undertake the project and having a major impact on the project's success.
Some of the Project Environment variables and their magnitude will be readily apparent when the project is initiated. These include variables of the “market based” variety. That is, the project is being undertaken to meet a specific market demand that competitors not have yet addressed and the sponsoring organization desires to be the first to market with such a product. Or the project is initiated to add functionality to a genre of existing software, such as a new feature to accounting software, to add a distinguishing capability.
There also exist a set of variables that can be classified as “technology based.” Projects initiated to build on a base set of functionality constitute an environment different from projects where leading edge technology will be employed. The project that builds on a base set of functionality does not have the same level of risk and uncertainty associated with it as a project where the leading edge technology will be employed. The base functionality and leading edge technology projects represent the ends of the spectrum for the technology based project environments. In between lies the project that starts with a “proof of concept.” That is, there is an understanding of the technology and how it can be applied, but what the user may be asking for in terms of functionality may be pushing the boundaries of the base technology.
The eventual role of the system within the organization can be used to define where on the spectrum of “business based” variables the project lies. The environment in which a system is being developed to provide ongoing operational support presents different challenges than a system that is deemed mission critical. The approach to be employed in developing the systems to support this continuum of business operations needs to be considered when planning the project. As the degree to which the success of the business depends on the success of the project increases, so does the need to ensure that requirements are correctly defined increase. Not only does the need to accurately define the requirements increase, but the need to ensure the design defines how those requirements are to be met increases. The increased importance of the project on the success of the business also impacts how the development testing and deployment should be approached.
One of the more complex set of Project Environment variables that the Project Manager must assess are those variables centered around the clarity with which the requirements are understood and defined at the onset of the project. It is often difficult to determine where on the spectrum of “requirements based” variables the project lies during initiation and planning. Do the users really know what they need, or is it a case of “I‘m not sure exactly what I need, but I will know it when I see it.” Once the requirements are defined, what is the likelihood they will remain stable? Some projects are initiated with the understanding that a base set of functionality can be articulated in the beginning, with an expectation that additional functionality will be defined based on the acceptance of that base functionality.
There are many other variables that define the Project Environment and an attempt should be made to identify and evaluate them when deciding on a development approach. For example, have time constraints been imposed? A project expected to be completed within a short duration may need to be approached differently from a project where the expectation is that it will take as long as it takes, as long as the functionality and quality meet defined requirements. To what degree will the users be involved in the design and review of the development products? Is the system a stand-alone system, or is there a high degree of dependency on interfaces with other systems?
Unfortunately, there is no definitive list of variables that define the Project Environment, and for the variables a Project Manager can identify, there is no definable scale with which to quantify them. However, software development Project Managers must give ample consideration to the circumstances under which a project will be executed, and based on that consideration, select a project life cycle that works best in that environment.
Development Life Cycles
The PMBOK® Guide defines a project life cycle as a collection of project phases that identifies the beginning and end of a project. How the phases are organized in between the beginning and end is what distinguishes one life cycle from another. Most Project Managers are familiar with the Waterfall approach to software development. The premise of the Waterfall life cycle is that requirements can be completely defined at the onset, and once defined will remain stable. As discussed above, the ability to define the complete set of requirements and the stability of those requirements are just one of the variables used to define the Project Environment. Given a Project Environment where the requirements are not stable, the Waterfall approach will prove difficult to implement. In fact, an approach that allows for adaptation during the development effort would be best suited for an unstable requirements environment.
Predictive Versus Adaptive Life Cycles
The recognition that not all development efforts are predictable and there is a need for adjustment during the effort has led to a classification of project life cycles as either Predictive or Adaptive. Predictive life cycles concentrate heavily on the planning and design processes. The basic idea is that if a process can be clearly articulated then its schedule and cost can be accurately predicted. With this type of life cycle, a large portion of the project time is spent attempting to get a clear picture of the entire system and then producing a design that is representative of this picture. Users typically do not see any tangible results for an extended period of time. This is the traditional approach to software development that is embodied in the Waterfall life cycle. Under the right conditions, these life cycles can produce highly optimized systems that meet or exceed cost and schedule constraints. However, implicit in all predictive life cycles is that the requirements are relatively stable.
On the other hand, Adaptive life cycles make the implicit assumption that requirements are constantly in a state of flux. More projects then we would like to admit have requirements that are extremely unstable. Typical everyday examples are projects with a user community that has difficulty in visualizing abstract requirements or software for in an extremely competitive environment such as the Internet.
With Adaptive life cycles, long planning cycles are abandoned in favor of producing a tangible result that is representative of the system the users desire. Where the interim result is unsatisfactory, it is changed in a future iteration. This approach gives the users the illusion of speed and if done correctly will produce useful results more rapidly than traditional processes. However, it is extremely difficult to predict schedule and cost parameters for projects built using Adaptive life cycles.
The Predictive life cycles favor optimization over adaptability. There are circumstances where this is desirable and necessary. Many real time and embedded software systems will not lend themselves to development in the Adaptive framework due to the constraints of execution speed and code size placed upon them. Another example of where the Adaptive life cycle would not be appropriate is with systems that cannot tolerate failures. An example is the life support system for the space shuttle; a failure in this system could result in loss of human life. This system needs to be carefully planned with all execution paths carefully documented for later rigorous testing.
As the name implies, Adaptive Life Cycles accept and embrace change during the development process and resist detailed planning. The Adaptive Life Cycles stress the creative process of software development and recognize that it cannot be easily planned. With this lack of planning comes unpredictability. If used with a disciplined team of developers in the appropriate circumstances as outlined above, the Adaptive life cycles can yield the following advantages:
• Applications that closely match customer requirements due to constant customer feedback
• Changing business needs are more easily accommodated
• Customers see more progress earlier, more “bang for the buck,” in the process thus increasing their confidence early in the project
• Reduced risk of major failures.
On the other hand, if the requirements are relatively stable the Predictive life cycles yield the following advantages:
• Less risky
• Require less disciplined staff
• Useable for fixed price contracts.
Predictive Life Cycles
The Waterfall life cycle is also known as the Traditional or Top Down approach and is the baseline from which to determine if another approach is better suited. The life cycle is characterized by the linear ordering of the major software development activities. Each life cycle phase is completed before the next begins. Once a life cycle phase is completed, it is assumed that it will remain done and not be revisited.
This life cycle is highly effective for short duration, well-understood projects with very stable requirements. It avoids the common problem of starting the next phase before the current phase is completed. The strengths of the Waterfall life cycle are that it requires output at each phase, is well documented at each phase and requires reviews and evaluations at each phase. The benefit is that the investment of time and effort in the beginning saves on costs in the later phases.
The Waterfall life cycle is not well suited for interface-driven applications. It is a rigid, document-driven process that requires the user to wait until near the end of the project to see the product. In fast moving technology environments, the products that are built using this approach might be delivered obsolete.
The premise behind the Prototyping life cycle is to use a model to generate functional requirements and physical design specifications simultaneously. The method by which the prototype is presented can vary greatly based on project needs. Examples of presentation methods include drawings on paper, screen layouts with little or no functionality and working designs with limited functionality. There are two primary variations of the Prototyping life cycle. The first is the “throw-away” approach, where the prototype is discarded and the resulting requirements and design specifications are the inputs to the development phase. The second variation is the “partial keep,” where specific design elements are retained in the final design.
One of the primary benefits of the Prototyping life cycle is that it requires intensive user involvement in the creation and review of the prototype. Prototyping allows the user to see what is possible and provide feedback and identify additional requirements. As a result of this intensive user involvement, early validation of the requirements results in stable requirements, thereby reducing risk. Another benefit is that it provides a “Proof of Concept” approach with minimal investment, allowing developers the opportunity to sell the users on a specific technical approach.
Before selecting Prototyping as the development life cycle, consider that the scope of the project is not clearly defined during the initiation and planning phases. The project scope is defined along with the prototype. Also consider that with the Prototyping life cycle, it is easy to lose sight of the goal and expend unnecessary resources making the prototype functional versus finalizing specifications and designing anew, making the entire process cost ineffective.
Rapid Application Development (RAD)
RAD life cycles employ the use of an evolving prototype that is not thrown away. This requires intensive involvement of the user in the design. The goal is to meet the true user requirements as effectively as possible versus conforming to written specifications as completely as possible. Often times SWAT (Skilled With Advanced Tools) teams armed with CASE tools and advanced programming languages are used to quickly assemble components and solicit feedback through the use of JRP (Joint Requirements Planning) and JAD (Joint Application Design) sessions.
One of the benefits of the RAD life cycle is the reduction in development time and a corresponding reduction in overall development costs. Additional benefits include the identification of issues early in the life cycle when correction costs the least. The RAD life cycle also effectively meets business needs by avoiding specifications becoming obsolete before delivery.
A major key to the successful use of the RAD life cycle is a Project Environment where executive users must be willing to move fast. Issues require quick resolution and design decisions must be made quickly. Also, senior management must be willing to commit to the initial investment of tools and facilities.
In deciding whether to employ the RAD life cycle, care must be taken not to forsake the “big picture” for the sake of speed. This potential lack of considering the big picture and an absence of a well-defined system infrastructure and/or data architecture, can lead to discrete applications that do not work well together.
The Incremental Build life cycle is characterized its decomposition of a large development effort into a succession of smaller components. A key assumption of the Incremental Build life cycle is that the system requirements are complete before starting the design phase. Once the requirements are complete, the design, coding and testing phases are performed in stages. The goal of testing in each stage is both verification and validation of the requirements. This life cycle works well on large complex systems where the base functionality of the technology to be implemented is well understood by the project team.
With the Incremental Build life cycle, design decisions can be deferred until more insight into the system details is established. This life cycle produces interim results that can be tested to ensure functional reliability and compliance with users expectations. Risk is reduced through the creation of successive smaller subsystems or components.
A potential downside to employing the Incremental Build approach is the need for resources for longer periods; designers and developers remain on the project through each successive build while testers join the effort earlier. Additionally, there is the increased potential for requirements, and therefore scope, to change. Before adopting the Incremental Build life cycle, ensure that a strong change control management system is in place.
The Spiral life cycle is characterized by the repetition of the same set of life cycle phases of plan, design, build and evaluate until development is complete. With the Spiral life cycle, the planning is conducted at two levels. The first level of planning addresses the number of cycles through the life cycle phases and the second level addresses the detailed planning for the current cycle. This detailed planning reduces the likelihood that far-reaching plans become inaccurate.
The “Risk-driven” variation of the life cycle analyzes risk before each cycle and allows for development of the component that presents the highest risk. Using this variation provides the opportunity to systematically examine and reduce risk early in the project. If a project is going to fail, with the Spiral approach it will fail with the least amount of money and time invested.
The Spiral life cycle is effective when the user does not know what the final product should look like, and a prototype will not help identify the solution. This makes the Spiral life cycle an excellent candidate for the Project Environment where there is a feeling of “not sure if or how it can be done” exists.
The drawbacks of the Spiral life cycle are that the multiple planning, design, build and evaluation cycles extend the life of the project. Thus, it is not well suited for short duration projects. Also, the lack of formal structure in terms of defining when system components will be built adds to user uncertainty.
When using the Spiral life cycle, caution must be exercised to avoid defining cycles that guarantee success. Rather the cycles must be defined to ensure that going forward into the next cycle does not add to the risk of success.
Adaptive Life Cycles
Adaptive Software Development
The Adaptive Software Development (ASD) Life Cycle embodies the principles of Adaptive life cycles, as the name would suggest. ASD is characterized by the following five attributes:
• Mission driven—Understanding the mission of the project allows for planning that focuses on producing the product intended, not just the product needed. In the ASD life cycle, deviations are viewed as a means of guiding the development effort to the correct solution, not as errors that prevent achieving the planned solution.
• Component based—Rather that focusing on accomplishing specific tasks, ASD focuses on the features that the software must exhibit. Components are planned and implemented together in an orderly fashion.
• Iterative cycles—ASD emphasizes continuous learning about what the correct solution is, rather than on its final form. Redoing takes on as much importance, if not more, that doing. The iterative cycles allow for a convergence of the user's view with the developer's view resulting in a product that satisfies the requirements of both.
• Time boxed cycles—By time boxing the work, tradeoff decisions are forced to be made within the context of the end date of the time box. The benefit of time boxing is that it forces developers to concentrate on the most important activities in order to meet target date.
• Risk-driven and change-tolerant—With ASD, the development effort focuses on responding to risk and change rather than attempting to control them. Using this approach, the end result is a product that has addressed and incorporated strategies to mitigate the impact of risks and change.
One of the key benefits of ASD is that it allows the development effort, and the developers, to advance or to recede. It is acceptable to back up to find an alternative path. The result is that the developer is given the opportunity to learn and advance from their experience.
ASD is well suited for very complex projects and for projects that demand quick results while accepting a high degree of change in achieving those results. Obviously, ASD is not useful in environments where there is little latitude in how the solution will be implemented.
A potential obstacle for electing to use ASD is the need for changing the mental picture of the software development process. The development staff and users must be willing to focus on the features of the end product and allow themselves to explore, and potentially travel down, paths not previously considered. They must be willing to forego a vision of what the end result will look like and instead focus on the mission. At the same time both developers and users must be willing to collaborate and learn, and in doing so, converge their individual views into a solution that achieves the project mission.
Extreme Programming (XP) was created to provide a method of software development in environments of changing requirements to address problems of project risk. One of the distinguishing characteristics of XP is the composition of the development teams and the role the team plays in the entire process. XP teams include not only developers, but also managers and user representatives. By having all interested parties as part of the team, communication bottlenecks are eliminated.
A unique feature of XP is that programming is done in pairs. The assumption is that with two people at a terminal the resulting synergy increases productivity. Also, the role of the developer is not to simply create code; they are also responsible for writing the tests as they develop the code.
Developing software with the XP approach is an iterative process. Rather that consider future needs, the focus of the design effort is strictly on the current iteration. This can result in somewhat chaotic code, which is why XP incorporates refactoring into later iterations to ensure functionality is located in only one place.
XP is best suited for projects that require from two to twenty developers. It is also expected that the project environment will allow for the creation of automated unit and functional tests. XP emphasizes user satisfaction by producing tangible results in a short time, while promoting teamwork and collective code ownership.
Before electing to employ the XP approach, consider that it is not recommended for use with large development teams. Also consider that when using XP, a key team member is a full time user representative and that the developers on the team need to be highly disciplined. Lastly, XP will not work well if there is a requirement to predict the cost and schedule at the project onset and to meet those cost and schedule commitments.
The SCRUM development life cycle is similar to the other adaptive life cycles that employ an iterative development process to address changing requirements. In the SCRUM life cycle, the iterations are referred to as “sprints,” which typically last 30 days. Before beginning a sprint, the functionality to be delivered during that sprint is defined based on the current state of the requirements. Once the functionality to be delivered is defined, the team then delivers that functionality with the goal of stabilizing the requirements during the sprint.
A key feature of SCRUM is the active role management plays during the development process. Each day the entire team meets for a short meeting, called a scrum, where it is determined what will be accomplished during the next day. The team also identifies any obstacles seen as impeding their progress, and it is management's responsibility to resolve and remove those obstacles.
Using small teams focused on discrete pieces of work, SCRUM allows for large development projects to be approached through parallel efforts that are continuously synchronized. Each team addresses a set of related objects, with clear interfaces and behavior. A benefit of this “divide and conquer” approach is that discrete work efforts result in more product features being ready in a shorter period of time. By synchronizing across teams, the teams can share knowledge on problems encountered and their resolution. This reduces the likelihood that another team will encounter the problem, and if they do, spending as much time finding a resolution. However, this synchronization requires strong leadership to implement effectively.
The SCRUM life cycle is not well suited for applications with extensive procedural code, with its many and intertwined interfaces. SCRUM should be considered for projects utilizing Object Oriented technology as the objects, based on product features, offer a discrete and manageable environment.
Because each project is unique and the environment in which is to be undertaken is equally unique, it would be extremely ambitious to try and identify, categorize and quantify all the variables that define the Project Environment. We have endeavored to identify some of those variables, and concede that others certainly exist. It would be equally ambitious to try and prescribe a specific software development life cycle for a given set of environmental variables. In this presentation, we have addressed a limited selection of both Predictive and Adaptive life cycles. To help ensure the end result of the software development effort meets the objectives of the users and/or customers, it is the Project Manager's responsibility to survey the Project Environment and then select a development life cycle best suited for that environment. It is not unconceivable that as a result of trying to match existing life cycles to the Project Environment, a new approach will be defined. Properly selected based on the Project Environment, the development life cycle will certainly contribute to the success of the project.
Bechtold, Richard. 1999. Essentials of Software Project Management. Vienna, VA: Management Concepts.
Beck, Kent, and Fowler, Martin. 2001. Planning Extreme Programming, New York: Addison-Wesley.
DeGrace, Peter, and Stahl, Lesliel. 1990. Wicked Problems, Righteous Solutions. Englewood Cliffs, NJ: Prentice Hall.
Highsmith, James. 2000. Adaptive Software Development, New York: Dorset House Publishing Company Inc.
Martin, James. 1991. Rapid Application Development. New York: MacMillan Publishing Company.
Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA