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.