In this section, we detail only the software workflows of the spiral, but the reader should understand that, in the general Harmony hybrid-spiral, engineers of other disciplines are concurrently working in an incremental fashion as well.

Integration occurs in the testing phase of the spiral, and this integration may include mechanical, chemical, electronic, and software disciplines. There may not be hardware components to integrate in any specific spiral, but there often is.

It might be breadboard or wire-wrapped electronics, with mock-up or hand-built mechanicals, or first-run factory electronic and mechanical components. The point is to avoid the shotgun integration at the end of the project and plan for incremental integration as early as possible.

Figure 2.10. Increment review (party phase)

Increment Review (Party!) Workflow
The spiral starts in the increment review phase (also known as the party phase5). This phase is where the primary project planning and on-going assessment activities take place.

Remember that there are two forms to the Harmony process. In the general form, the first time into the spiral, the software, the general schedule, software development plan, configuration management plan, reuse plan (if any) are defined.

In the Harmony-SW variant, project scope and engineering approach are also selected and defined, and the system use cases are identified and given a one-paragraph mission statement. However, in this latter case, the use cases are not detailed—that takes place in the analysis phase of the spiral.

In subsequent spirals, the project and system are assessed against those plans and the plans modified as necessary. The primary artifacts assessed during the party phase are:

Schedule
Architecture
Process
Risks
Next Prototype Mission

One of the more serious project management mistakes made is inadequate assessment and adjustment of projects during their execution. As DeMarco and Lister note, "You cannot control what you do not measure.6" It is equally important that you apply the measured information to make adjustments.

In terms of schedule, such adjustments will be things like reassignment of resources, reordering activities, deletion of activities, reductions (or enhancements) of scope and/or quality, rescheduling subsequent activities, and so on.

Because the selection and implementation of a good architecture is crucial to the long-term success of a project and product, the party phase evaluates architecture on two primary criteria.

First, is the architecture adequately meeting the needs of the qualities of services that are driving the architectural selection? Second, is that architecture scaling well as the system evolves and grows? The process of reorganizing the architecture is called refactoring the system.

If the project team finds that the architecture must be significantly refactored on each prototype, then this is an indication that the architecture is not scaling well, and some additional effort should be given to the definition of a more scalable architecture.

Early on in the project, selections are made about how to manage the project—what tools will be used, where they and their data are located and how they are accessed, security procedures, artifact review and quality assessment procedures, work and artifact guidelines, etc. The Party phase seeks to improve the efficiency of the process during the project by actively looking for and correcting problems and issues.

In my experience, the biggest single reason for project failure is ignoring risks. To manage risks, we recommend each project maintain a risk management plan.

In this plan, each risk is identified and ranked and, where appropriate, a risk-mitigation strategy is described. Most of these will be activities to be done in the spirals to explore, reduce, or handle the risk. In the Party phase, the risk management plan is reviewed and newly identified risks are added.

Lastly, although the plan for the prototype mission is decided early on (and scheduled against), this plan is reviewed and possibly adjusted each iteration. It is common to make minor adjustments to the mission scope but, if nothing else, explicitly reviewing the plan ensures everyone knows what to do over the next 4"6 weeks it takes to complete the microcycle.

Figure 2.11. Prototype definition in the Harnmony-SW process variant

Analysis with the Harmony Process
The purpose of analysis is to define the essential properties of the system to be developed. The use of the term "essential" means that it defines the properties that, if missing, indicate the system is wrong or incomplete.

In model-driven architecture (MDA) terms, we are constructing a platform independent model (PIM) of the prototype capabilities in the analysis phase. The two primary workflows in the analysis phase of the spiral are the prototype definition and object analysis.