Chapter 2

The Harmony Process

Abstract

This chapter describes the Harmony process. The Harmony process is an agile approach to systems and software development that is, requirements–centric, and architecture focused. Harmony exists at three timescales – project, iteration, and nancocycle–and contains best practices at each level. The process emphasizes model-based engineering of systems and software.

Keywords

Harmonyprocessrolework producttask (work)spiraliterationprototypemacrocyclemicrocycleworkflowPDRCDRsystem engineering workflowsystem engineering hand-offpre-iteration planningchange managementconfiguration managementquality assuranceauditreviewsystem functional analysisshared modelsoftware development workflowarchitectural viewsverificationvalidationincrement reviewparty What You Will Learn • The Harmony development process • Why a process? • Harmony process overview • Key enabling technologies • Process timescales • Harmony process variants • Harmony development iteration in detail • Analysis • Design • Translation • Verification and validation • Party!

Introduction

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 process1 uses UML and variants as the language. This includes profiles such as the Systems Modeling Language (SysML) or the UML Profile for DoDAF and MODFAF (UPDM) for Department of Defense Architecture Framework models. The Harmony Process also specifies an integrated set of workflows to guide the developer so that they can use UML to its fullest advantage in developing robust, capable, and safe systems. 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. Beginning with the next chapter, problems will presented for you to work on. The set of problems is presented, roughly, in the order in which they appear when you follow the Harmony process. The order of these problems may vary from how they would appear to you if you follow a different 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 work products they generate. A good process provides guidance on an effective way to develop high-quality systems at a minimal cost. Far too many processes are either completely nonexistent or waste valuable developer time and resources doing the wrong things, such as generating reams of paperwork. A good process usually produces some paper work products, but only those that add value, and even then in a cost-effective manner.

Why a 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 • Provides a project template to guide workers through the development and delivery of a product • Improves product quality in terms of • Decreased number of defects • Lowered severity of defects • Improved reusability • Improved stability and maintainability • Improves project predictability in terms of • Total amount of effort • Length of calendar time required for completion • Communicates project information appropriate to different stakeholders in ways that they can use 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 in the following way: A process is the specification of sequenced set of activities performed by a collaborating set of worker roles resulting in a coherent set of project products, 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 work products (also known as 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 a work product, such as a portion of the software model from which code will be generated. Figure 2.1 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 in a development phase • To achieve a specific goal • To create a specific work product. • The work done by a particular worker role A process is normally organized into phases, which might be thought of as the largest-scale work activities. Each phase is specified with one more workflows. Each workflow is a sequenced set of activities – simple tasks performed by workers – with resulting work products. A common way to represent workflows is with UML activity diagrams. Another is to use a tool specifically designed to create and manage process content, such as Rational Method Composer2 (RMC), the approach that will be used here. Work products are the things created or modified during activities. The singularly most important work product is the system being produced, but there are many others, such as the source code, the software model, the requirements specification, hazard analysis, safety analysis, test vectors, and so on. Generally speaking, every activity results in the creation or modification of at least one work product. 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 (project timescale), micro (iteration timescale), and nano (work item timescale). Smaller projects will give much more attention to the micro- and nanocycles, 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 work products 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 subsystem development, and another, called Harmony/ESW (Embedded SoftWare), focuses on software development only. Despite its well-known problems, the waterfall lifecycle is still by far the most common way to schedule and manage projects, especially for embedded systems. Nevertheless, the most fundamental issue with the waterfall lifecycle is that defects introduced early in the process are not...