Demonstrates that the system conforms to

and testing


functionality to increase the probability of project success (Beck and Andres, 2005). The incremental life cycle achieves this shortening by performing the requirements, specify, develop, and test phases to deliver fully functional pieces of the overall solution, and by iteratively applying the phases until the full system is completed. The iterations also promote overall project success by driving the integration of system components to demonstrate working functionality within each phase (Matta and Ashkenas, 2003). Figure 36.4 compares the waterfall life cycle with the incremental life cycle.

The unified software development process (UP) is a well-known incremental life cycle. The key characteristics of UP are that it is use-case driven, architecture centric, iterative, and incremental (Jacobson, 1999).

• Use cases describe a piece of functionality provided by a system that delivers a result of value to a user. Use cases mature during the project cycle as the stakeholders and project team gain greater understanding of the required functions.

• System architecture defines the elements (IT components) of the solution. If a use case is function, system architecture is form. The architecture describes the organization and interaction of the solution elements, participating system(s), and platforms (e.g., operating systems, database management systems, Java runtime environment).

• The iterative and incremental approach divides the system implementation undertaking into mini projects called iterations. Each iteration produces a product, called an increment. Controlled iterations reduce the risk on a single increment (Jacobson, 1999).

The UP life cycle includes the following phases, each with different focus:

• Inception—The inception phase is focused on establishing and documenting the business case and baseline vision for the solution.

• Elaboration—During this phase the team translates business requirements into solution needs. In the elaboration phase, the focus of the project shifts to discovery of the system architecture to provide a stable basis for the implementation effort in the development phase. The architecture evolves out of a consideration of the most significant requirements, those that have a great impact on the architecture of the system.

figure 36.4 Waterfall compared with incremental life cycle.

• Construction—During the construction phase, the focus is on developing detailed specification/configuration documents tied to the requirements identified in the previous phase, implementing the functions/configurations, and performing unit testing of the components. In the construction phase, the architecture and requirements have an established baseline, the specification/configuration documents, and a strict change-management process controls changes.

• Transition—During the transition phase, the project team transfers the product to the user community. Once users inspect the product, issues often arise that require additional development to adjust the product, correct undetected problems, or finish some of the features that may have been postponed. This phase typically starts with a "beta release" of the product.

Although the focus evolves with each succeeding phase, the phases all include the iterative performance of "work flows," to produce increments. These work flows correspond to the basic phases of the waterfall: requirements, specify, develop, and test.

Incremental life cycles are often used for large systems developed over many years, such as the RODS system described earlier.

3.3. Other IT Project Life Cycles

Table 36.4 summarizes a number of other IT project life cycles. The "Methodologies" column describes well-known methodologies combining life cycles with methodology-specific processes project teams must accomplish within the life cycle phases.

3.4. Evaluating Project Life Cycles

By our definition, life cycles are fundamental to project management and significantly affect how the project is structured. This section provides a method to choose a life cycle that is well suited for a project. Dr. Richard Bechtold developed a method for considering project-specific characteristics ("key strengths" in Bechtold's terminology) to determine what development life cycle(s) are most appropriate (Bechtold, 1999). Table 36.5 is a summary of project-specific characteristics.

The following table matches project life cycles with project characteristics. For example, the waterfall project life cycle could be appropriate for a project with high ratings for "appropriate processes," "project brevity," and "requirements stability."

The two project examples presented later in this chapter were both brief projects. In Table 36.6, the project characteristic "Project Brevity" indicates the applicability of the waterfall life cycle. The examples describe how the project teams successfully applied the waterfall life cycle by adapting the project phases to address project-specific requirements.

Note that the IT industry is rife with "methodology wars," and IT practitioners may identify deeply with their life-cycle methodology of choice. The authors of this chapter provide the assignment of a sample methodology to life cycle category or the lumping of two competing methodologies in a single category to help project managers compare their project characteristics to major advantages of a life cycle. Clearly, a good team can deliver successful projects by using a life cycle not listed as most appropriate. Likewise, an appropriate life cycle does not guarantee project success.

Note that the IT life cycles are actually based on software development life cycles, which may not cover all aspects of a CBBS implementation. Therefore, applying them without recognizing this limitation may hide both risks and opportunities:

Hidden risk—CBBSs are data driven, and many CBBS projects obtain their data from people and organizations outside the project. External data creates unique and formidable project risks, including uncertain data acquisition tasks, unknown source data, misunderstood source data, and uncertain data cleansing tasks. Software development project life cycles do not directly address data.

table 3 6^4 Implementation Life Cycles



Appropriate Use



Linear ordering of major implementation activies.

Requirements well understood and stable.

Was this article helpful?

0 0

Post a comment