Despite its well-known problems, waterfall lifecycle is still by far the most common way of scheduling and managing projects. Nevertheless, the most fundamental issue with the waterfall lifecycle is that defects introduced early in the process are not identified or fixed until late in the process.

Certain kinds of strategic defects - requirements and architectural defects, specifically - are three or four orders of magnitude more expensive to repair in the waterfall lifecycle because they have broad sweeping implications. This is inherent in the waterfall lifecycle because testing comes at the end.

The longer you wait to identify and repair defects, the more they have become entrenched and the greater the number of dependencies on the flawed aspects. Put another way, the problem with the waterfall lifecycle is that it fundamentally assumes each step in the process can be completed more-or-less without serious defects, but in fact that is demonstrably untrue. When the defects are finally identified and repaired, the cost is very high.

Figure 2.2. Harmony process time frames

The spiral (also known as the iterative) lifecycle has become popular to address the concerns associated with the waterfall lifecycle. The basic advantage of the spiral lifecycle is that the system is tested far earlier and far more often.

This results in the identification and repair of defects much earlier and at a significantly reduced cost. The spiral lifecycle essentially breaks up the development project into a set of smaller projects, and incrementally adds capabilities to the system, but not before validating the ones already present. Each addition of a set of capabilities is called a "spiral" or "increment."

Each of these subprojects is more limited in scope, is produced with much greater ease, and has a much more targeted focus than the entire system. The result of each spiral is what Harmony calls an iterative prototype—a functional, high-quality system that may not be as complete (or perhaps not done in as high fidelity) as the final system.

Nevertheless, the prototype does correctly implement and execute some portion of the requirements and/or reduce some set of risks and contains the actual code that will ship with the product, once complete.

The Harmony process can be conceptualized as occurring simultaneously in three different scales or time frames (see Figure 2.2 above). The macrocycle process occurs over the course of many months to years and guides the overall development from concept to final delivery.

The Harmony macro process has four primary, but overlapping, phases. Each macrophase actually contains multiple microcycles, as we will see shortly, and the result of each microcycle is the production of an iterative prototype.

The macrophases are a way to show that the missions of the prototypes tend to evolve over time in a standard way. The early prototypes tend to focus on key concepts, such as requirements, architecture, or technology. The next several prototypes introduce and focus on the secondary concepts of requirements, architecture, and technology.

After that, the focus shifts to design and implementation concerns. The last set of prototypes emphasizes optimization and deployment (in the target hardware and in the customer's environment). The shift in focus of the prototypes tends to be gradual, hence the overlapping nature of the macrophases.

If required, Preliminary Design Reviews (PDRs) and Critical Design Reviews (CDRs) are easily incorporated into the process. Usually a PDR occurs at or near the end of the first macrophase and a CDR occurs at or near the end of the second macrophase.

Each macrocycle contains several microcycles, or spirals. Each microcycle is fairly short, usually completing within 4"6 weeks. Each microcycle is focused around the production and delivery of a single incremental prototype with limited but highquality functionality. This is most commonly focused around one or a small number of use cases, but may also include specific risk-reduction activities.

Within the microcycle, the developers work to produce the high-quality object collaborations that realize the use cases of the prototype. During this process, the increasingly complete collaborations are executed dozens to hundreds of times.

This very short execution cycle - in the order of minutes to hours (at the long end) - is called the nanocycle. If an object collaboration will ultimately consist of 100 objects, experience has shown - clearly - that the best way is NOT to put down all 100 objects and say "Oh God, I Hope This Works" but instead to start with one (incomplete) object and get that to work in isolation, through model execution.

Then add another object and get them to work together. Then refine the objects, or add a third; and so on, making small enhancements to the capabilities supported in the collaboration but validating, through execution, each small incremental step. Executable modeling tools, such as Rhapsody, make this process highly efficient.

The basic premise of the nanocycles is to make tiny incremental steps and demonstrate through execution that they are right before adding the next. The so-called "agile processes" such as the Extreme Programming (XP) approach focus almost exclusively on the nanocycle scale of development.