A methodology consists of a language to specify elements and relationsof interest and a process that tells the developer what parts of thelanguage to use, how to use them, and when to use them.
The Harmony process uses UML and variants, such as theSystems Modeling Language (SysML) or the Department ofDefense Architecture Framework (DoDAF) UML profiles, asthe language. The Harmony process also specifies an integrated set ofworkflows to guide the developer so that they can use the UML to itsfullest advantage in developing robust, capable, and safe systems.
It is basically the next revision in the ROPES (Rapid Object-orientedProcess for Embedded Systems) process, discussed in the author'sprevious 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 rigorousprocesses. This chapter begins the discussion with an overview of thetwo major variants of theHarmonyprocess, and then gives detailed workflows for each of the phases inthe process.
The Harmony Development Process
A process is an integrated set of workflows. Each workflow takes someaspect, typically a phase in the process, and elaborates whatactivities are necessary for the workers to accomplish, when and howthey are going to accomplish it, and what artifacts they generate.
A good process provides guidance on an effective way to develophigh-reliability systems at minimal costs. Far too many processes areeither completely under-specify workflows or waste valuable developertime and resources doing the wrong things, such as generating reams ofpaperwork. A good process usually produces some paper artifacts, butonly those that add value, and even then in a cost-effective manner.
|Figure2.1. Basic elements of process|
The basic reason why we, as software and system developers, should beconcerned about and use a good process is to improve our lives and ourproducts. Specifically, a good process:
1) Provides a projecttemplate to guide workers through the development and delivery of aproduct
2) Improves product qualityin 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 projectinformation appropriate to different stakeholders in ways that allowthem to use it effectively
If you have a process that doesn't achieve these goals, then youhave a bad process and should think about changing it for the better.These goals can be achieved with a good process or they can beinhibited by a bad process.
So, what's a process? In Harmony, we define a process to be thespecification of a sequenced set of activities performed by acollaborating set of workers resulting in a coherent set of projectartifacts, one of which is the desired system.
A process consists of worker roles, the “hats” worn by workers whiledoing various project activities. Each activity results in the creationor modification of one or more artifacts. For example, most processeshave requirements capture (activity) somewhere early on before designoccurs.
This is performed by a requirements analyst (worker) acting as asoftware modeler (a worker role), and might result in an artifact, suchas a portion of the software model from which code will be generated.Figure 2.1 above depicts these fundamental aspects and relationsinherent in a development process.
The activities are the tasks that the worker does in performance ofhis or her duty. The activities are grouped together into workflowsfocused around a common thread, such as the work done
1) in a development phase
2) to achieve a specificgoal
3) to create a specificartifact
4) by a particular workerrole. A process is normally organized into phases, which might bethought of as the largest-scale activities. Each phase is specifiedwith one more workflows.
Each workflow is a sequenced set of activities – simple tasksperformed by workers – with resulting artifacts. A common way torepresent workflows is with UML activity diagrams, and that approachwill be followed here.
Artifacts are the things created or modified during activities. Thesingular most important artifact is The System being produced but thereare many others, such as the source code, the software model, therequirements specification, test vectors, and so on.
Generally speaking, every activity results in the creation ormodification of at least one artifact. The Harmony process, describedin more detail in the next section, is applicable to (and in currentuse 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, andnano. Smaller projects will give much more attention to the micro andnano cycles, but as the projects grow in size, more attention isshifted to the macro scale to organize and orchestrate the entiredevelopment process.
Secondly, a number of artifacts are optional and created during theprocess only as needed. Hazard analysis, for example, is only used forsafety-critical applications. The subsystem architecture view, foranother example, is only created when systems are large enough toprofit from such decomposition.
In fact, the Harmony process has two major variants: one, called theFull Harmony process, includes a detailed systems-engineering processthat precedes the subsystem development, and another, calledHarmony-SW, focuses on software development only.
Despite its well-known problems, waterfall lifecycle is still byfar the most common way of scheduling and managing projects.Nevertheless, the most fundamental issue with the waterfall lifecycleis that defects introduced early in the process are not identified orfixed until late in the process.
Certain kinds of strategic defects – requirements and architecturaldefects, specifically – are three or four orders of magnitude moreexpensive to repair in the waterfall lifecycle because they have broadsweeping implications. This is inherent in the waterfall lifecyclebecause testing comes at the end.
The longer you wait to identify and repair defects, the more theyhave become entrenched and the greater the number of dependencies onthe flawed aspects. Put another way, the problem with the waterfalllifecycle is that it fundamentally assumes each step in the process canbe completed more-or-less without serious defects, but in fact that isdemonstrably untrue. When the defects are finally identified andrepaired, the cost is very high.
|Figure2.2. Harmony process time frames|
The spiral (also known as the iterative)lifecycle has become popular to address the concernsassociated with the waterfall lifecycle. The basic advantage of thespiral lifecycle is that the system is tested far earlier and far moreoften.
This results in the identification and repair of defects muchearlier and at a significantly reduced cost. The spiral lifecycleessentially breaks up the development project into a set of smallerprojects, and incrementally adds capabilities to the system, but notbefore validating the ones already present. Each addition of a set ofcapabilities is called a “spiral” or “increment.”
Each of these subprojects is more limited in scope, is produced withmuch greater ease, and has a much more targeted focus than the entiresystem. The result of each spiral is what Harmony calls an iterativeprototype—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 executesome portion of the requirements and/or reduce some set of risks andcontains the actual code that will ship with the product, oncecomplete.
The Harmony process can be conceptualized as occurringsimultaneously in three different scales or time frames (see Figure 2.2 above ). The macrocycleprocess occurs over the course of many months to years and guides theoverall 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 seeshortly, and the result of each microcycle is the production of aniterative prototype.
The macrophases are a way to show that the missions of theprototypes tend to evolve over time in a standard way. The earlyprototypes tend to focus on key concepts, such as requirements,architecture, or technology. The next several prototypes introduce andfocus on the secondary concepts of requirements, architecture, andtechnology.
After that, the focus shifts to design and implementation concerns.The last set of prototypes emphasizes optimization and deployment (inthe target hardware and in the customer's environment). The shift infocus of the prototypes tends to be gradual, hence the overlappingnature of the macrophases.
If required, Preliminary Design Reviews (PDRs) and Critical DesignReviews (CDRs) are easily incorporated into the process. Usually a PDRoccurs at or near the end of the first macrophase and a CDR occurs ator near the end of the second macrophase.
Each macrocycle contains several microcycles, or spirals. Eachmicrocycle is fairly short, usually completing within 4″6 weeks. Eachmicrocycle is focused around the production and delivery of a singleincremental prototype with limited but highquality functionality. Thisis most commonly focused around one or a small number of use cases, butmay also include specific risk-reduction activities.
Within the microcycle, the developers work to produce thehigh-quality object collaborations that realize the use cases of theprototype. During this process, the increasingly completecollaborations 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 collaborationwill 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) objectand get that to work in isolation, through model execution.
Then add another object and get them to work together. Then refinethe objects, or add a third; and so on, making small enhancements tothe capabilities supported in the collaboration but validating, throughexecution, each small incremental step. Executable modeling tools, suchas Rhapsody, make this process highly efficient.
The basic premise of the nanocycles is to make tiny incrementalsteps and demonstrate through execution that they are right beforeadding the next. The so-called “agile processes” such as the ExtremeProgramming (XP) approach focus almost exclusively on the nanocyclescale of development.
Harmony Process Overview
The Harmony process is a general systems-development process that,while emphasizing the real-time and embedded-software developmentaspects, includes the steps to produce general-purpose software andsystems.
The Harmony process has been used effectively on very small 1″3person projects as well as large teams consisting of hundreds of teammembers. Harmony is a highly scalable “medium-weight” process, strikinga balance between static heavyweight processes and lightweight,so-called “agile methods ” suchas Extreme Programming (XP) ,while incorporating aspects of both. The “nanocycles” timeframe in theprocess corresponds to the agile method's primary scale of concern.
(Note: The version of the Harmonyprocess described in the remainer of this series of articles is version1.5; it is under configuration management at Telelogic so that userscan be sure that they have a coherent set of artifacts that areinternally consistent. It is anticipated that over time, the processwill be further modified and updated. )
|Figure2.3. General Harmony Hybrid-spiral|
The Harmony process comes in two generic forms. The first isintended for projects that are larger in scale and have significanthardware-software codevelopment.
Because of the long lead times necessary for the development ofmechanical and electronic components, it is important that all therequirements be fully described and understood and the overallarchitecture be well defined before any significant design occurs. Forthis reason, the general Harmony Process Macrocycle is a hybrid of theclassic “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 anupfront effort -referred to generically as “systems engineering” inwhich the requirements are fully specified and organized into usecases, the subsystem architecture is defined, the requirements areallocated to the subsystems, and, at the subsystem level, requirementsare allocated to the engineering disciplines of mechanical, electronic,chemical, and software.
The systems engineering portion of the general Harmony Hybrid-spiralwas developed primarily by Dr. Hans-Peter Hoffman, Chief SystemsMethodologist for Telelogic. He and I worked together for a number ofyears to create a fully integrated systems and software process
The result of that work we called the Harmony process because itharmonizes the systems and software engineering disciplines togetherinto a single coherent process. The three phases in the systemsengineering part of the process are shown in Figure 2.4 below.
|Figure2.4. Systems engineering phases of the Harmony Hybrid process.|
After the systems engineering phases, the incremental developmentcycle 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 thegeneral process, previously detailed use cases are selected and used asthe basis for the prototype development, while in the software-onlyprocess, the as-yet-unspecified use cases must be detailed as a part ofthe spiral. Other than that, the spirals are essentially identical. Thespiral part of the process is shown in Figure2.5 below.
|Figure2.5. Harmony spiral (overview)|
In the General Harmony process, the prototype definition phasewithin analysis is simply a matter of selection of the use casesprevious specified in the systems engineering work.
In the software-only spiral model, these use cases have beenidentified (named and given a single paragraph mission statement) butthe detailed requirements for those use cases have not yet beenspecified. In this latter case, the first part of the spiral detailsthe use cases so that they are fully specified.
The next part in this series provides the workflows for each ofthese phases with UML activity diagrams used to show processactivities, 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'sReal-Time Analysis and Design Working Group.