A methodology consists of a language to specify elements and relations of interest and a process that tells the developer what parts of the language to use, how to use them, and when to use them.

The Harmony process uses UML and variants, such as the Systems Modeling Language (SysML) or the Department of Defense Architecture Framework (DoDAF) UML profiles, as the language. The Harmony process also specifies an integrated set of workflows to guide the developer so that they can use the UML to its fullest advantage in developing robust, capable, and safe systems.

It is basically the next revision in the ROPES (Rapid Object-oriented Process for Embedded Systems) process, discussed in the author's previous books with greatly expanded coverage for systems engineering.

There is a very broad range of development processes in use today, from "We don't need no stinking process" to very formal rigorous processes. This chapter begins the discussion with an overview of the two major variants of the Harmony process, and then gives detailed workflows for each of the phases in the process.

The Harmony Development Process
A process is an integrated set of workflows. Each workflow takes some aspect, typically a phase in the process, and elaborates what activities are necessary for the workers to accomplish, when and how they are going to accomplish it, and what artifacts they generate.

A good process provides guidance on an effective way to develop high-reliability systems at minimal costs. Far too many processes are either completely under-specify workflows or waste valuable developer time and resources doing the wrong things, such as generating reams of paperwork. A good process usually produces some paper artifacts, but only those that add value, and even then in a cost-effective manner.

Figure 2.1. Basic elements of process

Why Process?
The basic reason why we, as software and system developers, should be concerned about and use a good process is to improve our lives and our products. Specifically, a good process:

1) Provides a project template to guide workers through the development and delivery of a product

2) Improves product quality in terms of
- Decreased number of defects
- Lowered severity of defects
- Improved reusability
- Improved stability and maintainability

3) Improves project predictability in terms of
- Total amount of effort
- Length of calendar time required for completion

4) Communicates project information appropriate to different stakeholders in ways that allow them to use it effectively

If you have a process that doesn't achieve these goals, then you have a bad process and should think about changing it for the better. These goals can be achieved with a good process or they can be inhibited by a bad process.

So, what's a process? In Harmony, we define a process to be the specification of a sequenced set of activities performed by a collaborating set of workers resulting in a coherent set of project artifacts, one of which is the desired system.

A process consists of worker roles, the "hats" worn by workers while doing various project activities. Each activity results in the creation or modification of one or more artifacts. For example, most processes have requirements capture (activity) somewhere early on before design occurs.

This is performed by a requirements analyst (worker) acting as a software modeler (a worker role), and might result in an artifact, such as a portion of the software model from which code will be generated. Figure 2.1 above depicts these fundamental aspects and relations inherent in a development process.

The activities are the tasks that the worker does in performance of his or her duty. The activities are grouped together into workflows focused around a common thread, such as the work done

1) in a development phase

2) to achieve a specific goal

3) to create a specific artifact

4) by a particular worker role. A process is normally organized into phases, which might be thought of as the largest-scale activities. Each phase is specified with one more workflows.

Each workflow is a sequenced set of activities - simple tasks performed by workers - with resulting artifacts. A common way to represent workflows is with UML activity diagrams, and that approach will be followed here.

Artifacts are the things created or modified during activities. The singular most important artifact is The System being produced but there are many others, such as the source code, the software model, the requirements specification, test vectors, and so on.

Generally speaking, every activity results in the creation or modification of at least one artifact. The Harmony process, described in more detail in the next section, is applicable to (and in current use in) projects of widely different scale.

Harmony achieves this scalability in a couple of different ways. First, the process is viewed at multiple timescales—macro, micro, and nano. Smaller projects will give much more attention to the micro and nano cycles, but as the projects grow in size, more attention is shifted to the macro scale to organize and orchestrate the entire development process.

Secondly, a number of artifacts are optional and created during the process only as needed. Hazard analysis, for example, is only used for safety-critical applications. The subsystem architecture view, for another example, is only created when systems are large enough to profit from such decomposition.

In fact, the Harmony process has two major variants: one, called the Full Harmony process, includes a detailed systems-engineering process that precedes the subsystem development, and another, called Harmony-SW, focuses on software development only.

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.

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.