Harmony Process Overview
The Harmony process is a general systems-development process that, while emphasizing the real-time and embedded-software development aspects, includes the steps to produce general-purpose software and systems.

The Harmony process has been used effectively on very small 1"3 person projects as well as large teams consisting of hundreds of team members. Harmony is a highly scalable "medium-weight" process, striking a balance between static heavyweight processes and lightweight, so-called "agile methods" such as Extreme Programming (XP), while incorporating aspects of both. The "nanocycles" timeframe in the process corresponds to the agile method's primary scale of concern.

(Note: The version of the Harmony process described in the remainer of this series of articles is version 1.5; it is under configuration management at Telelogic so that users can be sure that they have a coherent set of artifacts that are internally consistent. It is anticipated that over time, the process will be further modified and updated.)

Figure 2.3. General Harmony Hybrid-spiral

The Harmony process comes in two generic forms. The first is intended for projects that are larger in scale and have significant hardware-software codevelopment.

Because of the long lead times necessary for the development of mechanical and electronic components, it is important that all the requirements be fully described and understood and the overall architecture be well defined before any significant design occurs. For this reason, the general Harmony Process Macrocycle is a hybrid of the classic "V" cycle and a spiral, as shown in Figure 2.3 above.

The general form of the Harmony process shown in Figure 2.3 has an upfront effort -referred to generically as "systems engineering" in which the requirements are fully specified and organized into use cases, the subsystem architecture is defined, the requirements are allocated to the subsystems, and, at the subsystem level, requirements are allocated to the engineering disciplines of mechanical, electronic, chemical, and software.

The systems engineering portion of the general Harmony Hybrid-spiral was developed primarily by Dr. Hans-Peter Hoffman, Chief Systems Methodologist for Telelogic. He and I worked together for a number of years to create a fully integrated systems and software process

The result of that work we called the Harmony process because it harmonizes the systems and software engineering disciplines together into a single coherent process. The three phases in the systems engineering part of the process are shown in Figure 2.4 below.

Figure 2.4. Systems engineering phases of the Harmony Hybrid process.

After the systems engineering phases, the incremental development cycle can begin. At this point, the two variants of the process, General Harmony and Harmony-SW, are remarkably similar.

There is an important difference in the analysis phases: in the general process, previously detailed use cases are selected and used as the basis for the prototype development, while in the software-only process, the as-yet-unspecified use cases must be detailed as a part of the spiral. Other than that, the spirals are essentially identical. The spiral part of the process is shown in Figure 2.5 below.

Figure 2.5. Harmony spiral (overview)

In the General Harmony process, the prototype definition phase within analysis is simply a matter of selection of the use cases previous specified in the systems engineering work.

In the software-only spiral model, these use cases have been identified (named and given a single paragraph mission statement) but the detailed requirements for those use cases have not yet been specified. In this latter case, the first part of the spiral details the use cases so that they are fully specified.

The next part in this series provides the workflows for each of these phases with UML activity diagrams used to show process activities, flows, and artifacts.

Next in Part 2: The Systems Engineering Harmony Workflows in Detail

Bruce Douglass, Ph.D, is the chief scientist for Telelogic (formerly i-Logix) which develops modeling tools for use in real-time systems development. He is also one of the co-chairs of the Object Management Group's Real-Time Analysis and Design Working Group.