11.3 Creating an Executable Model

(I apologize but the formatting problems continue.) 

Several companies have tools available that allow for modeling systems using UML (or SysML) diagrams.    These companies include EmbeddedPlus Engineering^11-7, Vitech and IBM© under their Rational© product suite.   The tools support the modeling language semantics so the engineer can focus on creating the design of the system and not on the accuracy of the diagrams per the modeling language specifications.  

Vitech supports the following UML diagram types in their CORE^11-8 Software: 

·         Activity

·         Sequence

·         Class

·         Package

·         Use Case

IBM Rational supports the following UML diagram types in their Statemate^11-9 product:

·         Use Case

·         Sequence

·         State Machine

Using a standard development process, these tools are used from requirements down to executable software.  Benefits from creating an executable model include verifying completeness and correctness of the system and bridging the gap between the systems engineering functional domain to the Object-Oriented Software Engineering domain.  The models are not just done at the beginning of system definition, but evolve as the development process progresses until there is executable software.   The SysML Forum, http://www.sysmlforum.com/, provides an overview of possible SysML tools that can be used for creating an executable model.  

12.4 Benefits and Limitations of UML

Benefits 0f using UML when defining a system include:

·         Standardized (by OMG Group), not proprietary

·         Common language for communicating

·         Explained and described in every aspect by vast amount of publications, resources, textbooks, etc.

·         Can be customized and extended for specific application domain, software process, or implementation platform

·         Uses object oriented design concepts

·         Independent of specific programming language

SysML benefits include:

·         Requirement modeling support provides the ability to assess the impact of changing requirements to a system’s architecture

·         Precise language, including support for constraints and parametric analysis that allows models to be analyzed and simulated, greatly improving the value of system model compared to textual system descriptions

·         Open standard

Whereas UML has many benefits, it also has limitations:

·         Still no specification for modeling of user interfaces

·         Poor for distributed systems – no way to formally specify serialization and object persistence

·         Requires training/certification

·         Specification is large and takes time to understand

·         Can’t describe relationships between complex system composed of both hardware and software

12.5 Where to Find More Information on UML (SysML)

To learn more about SysML and the different diagrams, please see http://www.omgsysml.org/INCOSE-OMGSysML-Tutorial-Final-090901.pdf

There are many available resources on UML both in book form and on the internet.   Beneficial books include:

1.       Systems Engineering with SysML/UML: Modeling, Analysis, Design by Tim Weilkiens

2.       Model-Based Development: Applications, by H. S. Lahman

3.       Using UML: Software Engineering with Objects and Components, by Perdita Stevens

4.       Software Modeling and Design: UML, Use Cases, Patterns, and Software Architectures, by Hassan Gomaa

5.       UML for Real: Design of Embedded Real-Time Systems, by Luciano Lavagno, Grant Martin and Bran V. Selic

6.       Model-Driven Development with Executable UML (Wrox Programmer to Programmer), by DraganMilicev

7.       UML 2.0 in a Nutshell, by Dan Pilone and Neil Pitman

8.       SysML for Systems Engineering (Professional Applications of Computing), by J. Holt and S. Perry

9.       Writing Effective Use Cases, by Alistair Coburn

10.   Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design , by Larry L. Constantine and Lucy A. D. Lockwood

11.   Use Case Modeling , by Kurt Bittner and Ian Spence 

12.   Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, by Ian Alexander, Neil Maiden

13.   Use Case Driven Object Modeling With UML: Theory And Practice, by Doug Rosenberg, Matt Stephens

Beneficial web sites include:

1.       Unified Modeling Language Resource Page, http://www.uml.org/

2.       Systems Modeling Language Resource Page, http://www.omgsysml.org/

3.       SysML Forum, http://www.sysmlforum.com/

4.       Embarcadero Developer Network, http://edn.embarcadero.com/article/31863

5.       Unified Modeling Language Tutorial, http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/

6.       OMG Systems Modeling Language Tutorial, http://www.uml-sysml.org/documentation/sysml-tutorial-incose-2.2mo

7.                              An Introduction to Systems Engineering with Use Cases, by Ian Alexander and Thomas Zink, http://easyweb.easynet.co.uk/~iany/consultancy/use_cases/use_cases.htm

8.                        Visual Paradigm, http://www.visual-paradigm.com/product/vpuml/provides/umlmodeling.jsp?src=google&kw=use%20cases&mt=p&net=s&plc=&gclid=CJSQzqzNkqgCFYi8KgodmmeJCw

9.                        SmartDraw, http://www.smartdraw.com/specials/ppc/softdesign.htm?id=10514&gclid=CNSquMTNkqgCFcW5KgodrHR2Dg

References

11-1 Model-based Systems Engineering (MBSE) Initiative, by Mark Sampson and Sanford Friedenthal, Presented at the Opening Plenary of the International Workshop, Phoenix, AZ, 29 January 2011; http://www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:mbse_iw_2011_intro-b.pdf

11-2 Foundational Concepts For Model Driven System Design by Loyd Baker, Paul Clemente, Bob Cohen, Larry Permenter, Byron Purves, and Pete Salmon, INCOSE Model Driven System Design Interest Group

11-3 The Unified Modeling Language User Guide, by Grady Booch, James Rumbaugh, and Ivar Jacobson, Addison-Wesley Professional; 2 edition, May 29, 2005

11-4 Unified Modeling Language Tutorial, http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/activity.htm

11-5 Object-Oriented Development in an Industrial Environment, Ivar Jacobson, Proceedings of OOPSLA´87, SIGPLAN Notices, Vol. 22, No. 12, pages 183-191, 1987

11-6 Object-Oriented Software Engineering: A Use Case Driven Approach, by Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard, Addison-Wesley, Wokingham, England, 1992.

11-7 Embedded Plus Engineering Web Site, http://www.embeddedplus.com/SysML.php

11-8 CORE Software Web Site, Vitech, http://www.vitechcorp.com/products/index.html

11-9 Rational Statemate Web Site, http://www-01.ibm.com/software/awdtools/statemate/

11.2.3 Behavior Diagrams

(Apologies for the formatting problems in this posting. The editor is scrambling the input formats and won't change.)

Three of the eight behavior diagrams are discussed with examples in this section.

Activity Diagram - An activity diagram shows the flow from activity to activity within a system.  An activity shows a set of activities, the sequential of branching flow from activity to activity, and objects that act and are acted upon.  Activity digrams are used to illustrate the dynamic view of a system and are important in modeling the function of a system.  Activity digrams essentially are flow charts and emphasize the flow of control among objects.  Figure 11-4, shows a possible activity diagram for Taking a Picture in the digital camera system.

Figure 11-4 Example Activity Diagram for a Digital Camera System

Activity diagrams can also include forks to describe conditions and parallel activities.   A fork is used when multiple activities are occurring at the same time.  As shown on the diagram , all branches at some point are followed by a merge to indicate the end of the conditional behavior started by that branch. 

Activity diagrams should be used in conjunction with other modeling techniques such as sequence diagrams and state machine diagrams.  The main reason to use activity diagrams is to model the workflow behind the system being designed.  Activity Diagrams are also useful for: analyzing a use case by describing what actions need to take place and when they should occur;  describing a complicated sequential algorithm;  and modeling applications with parallel processes^11-4.  Software engineers have also found them to be useful for scientific software development.

Sequence Diagram - A sequence diagram is an interaction diagram that emphasizes the time ordering of messages.  A sequence diagram shows the objects and the messages that go between those objects at a particular instance of time.  They are used to illustrate the dynamic view of a system.  An example of a possible sequence diagram for the digital camera system is hown in Figure 11-5.

Figure 11-5 Example Sequence Diagram for a Digital Camera System

As shown in the diagram, an object has veritical lines called lifelines which represent the existence of an object over a period of time.  The stick figure represents an actor, the Picture Taker.  The messages become method calls when translated into executable software.  The focus of control represents the period of time during which an object is performing an action directly or through a subordinate operation.  Other graphic elements used in a sequence diagram can be found in the UML specification at http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML

Sequence diagrams can be used at all levels of defining a software system – Use Cases down to a detailed software function.  Although sequence diagrams are typically used to describe object-oriented software systems, they are also extremely useful as system engineering tools to design system architectures.

State Machine Diagram - A state machine is a behavior that specifies the sequence of states an object goes through during its lifetime in response to events, together with its response to those events.  A state machine diagram shows the state machine, consisting of states, transitions, events, and activities.  These diagrams are used to illustrate the dynamic view of a system.  These are important when modeling the behavior of an interface, class, or collaboration and are useful when modeling reactive systems.  Figure 11-6 shows a state machine diagram for the Shutter Object.  When the button on the camera is pushed to take a picture, the Shutter object moves from the Opened state to the Closed state.  Once the button is released, the Shutter Object moves back into the opened state. 

  

Figure 11-6 Example State Machine Diagram for a Digital Camera System

Note that a transition from one state to another could be a signal, an event, a change in some condition, or the passage of time.  A state machine diagram may have a transition back to its own state.  At its simplest, an object within a software system has two states, idle or running.  When defining a software system, state diagrams are very beneficial for defining complex objects and how they behave.

Use Case Diagram – A Use Case Diagram is a diagram that shows a set of use cases and actors and their relationships.  A Use Case is a description of a system’s behavior as it responds to a request that originates from outside of that system.  It provides context to what is within a system and what interacts with a system and defines the behavior of the system when it receives external stimuli (i.e. the goals of the system).   A system is made up of multiple Use Cases to define the behavior of the overall system.  Use Cases were first defined in 1987 at the Proceedings of OOPSLA^11-5 by Ivar Jacobson for use in Software Engineering to define functional requirements.  Ivar Jacobson, et al, later published a book titled Object-Oriented Software Engineering: A Use Case Driven Approach in 1992^11-6 based on his experiences with Use Cases while working on large telecommunications systems.  Figure 11-7 shows a Use Case Diagram for the simple Digital Camera System.

Figure 11-7 Example Use Case Diagram for a Digital Camera System

The Picture Taker and the Printer are outside the boundary of the system being defined and are called Actors.  Take Digital Picture, Print Picture, and Delete Picture are all use cases within the system (i.e. functions the Digital Camera performs).  When developing Use Cases, all Actors are described as “nouns” while the Use Cases are “verb phrases” that describe an action the system performs.  The arrow on the association line indicates initiation of interaction.  If either the Use Case or the Actor can initiate interaction, then there is no arrow on the relationship line.  There can be two types of actors depicted on a Use Case diagram:  Primary Actors which benefit from the Use Case (arrow from Actor to Use Case) and secondary actors which participate in the system but don’t get benefit (arrow from Use Case to Actor).

Use Case modeling not only includes the model, but also written text to describe how the system behaves when the external Actor stimulates the system.  Typically a Use Case template is defined so all needed information is captured on how the system behaves.  One example of a Use Case template for capturing the behavior of a system is shown in Figure 11-8.

 Figure 11-8 Example Use Case Template

When starting Use Cases, it’s advisable to keep the description at the top-level at first and add details as the Use Case is better understood. Typically a Use Case is started with the normal flow of events; alternate and exception paths are added if needed.  One of the strengths and a significant benefit of Use Cases is that it makes engineers think about how they want the system to behave under abnormal or failure conditions. 

 11-4 Unified Modeling Language Tutorial, http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/activity.htm

11-5 Object-Oriented Development in an Industrial Environment, Ivar Jacobson,  Proceedings of OOPSLA´87, SIGPLAN Notices, Vol. 22, No. 12, pages 183-191, 1987

11-6 Object-Oriented Software Engineering: A Use Case Driven Approach, by Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard, Addison-Wesley, Wokingham, England, 1992. 

11.2 Introduction to the Unified Modeling LanguageTM(UML®)1

The Unified Modeling Language is a language used to specify, visualize, and document models of software systems, including their structure and design.  The language was formed by Grady Booch, Ivar Jacobson, and James Rumbaugh^11-3 after a critical mass of ideas started forming in the 1990s from their individual work in object-oriented methods.  Collectively they defined UML for three reasons:

1.       Their methods were evolving toward each other independently

2.       To provide stability to the object-oriented modeling language

3.       To provide improvements to the language  

UML 1.0 was offered by the Object Management Group (OMG) for standardization in January 1997 with the final acceptance of version 1.1 in September 1997.  The OMG maintains the UML specification with the latest version found on the OMG website at http://www.uml.org/

In March 2003, the OMG along with the International Council on Systems Engineering (INCOSE) developed a Request for Proposal (RFP) for UML for Systems Engineering.  The RFP specified the requirements for extending UML to support the needs of the systems engineering community.  SysML™[1] is a general purpose graphical modeling language for specifying, analyzing, designing and verifying complex systems.  The system may include hardware, software, information, personnel, procedures, and facilities.  SysML represents a subset of UML.   The SysML specification was developed with the OMG announcing the adoption of the OMG SysML in July 2006 and the availability of the specification in September 2007.  The latest version of the SysML specification can be found at the OMG website at http://www.omg.org/spec/SysML/

11.2.1 Types of Diagrams in the UML- UML 2.4 See (http://www.omg.org/spec/UML/2.4) defines fourteen types of diagrams, divided into two categories:

1.       Structure Diagrams, which include:

a.       Class Diagram

b.      Package Diagram (diagram same for SysML)

c.       Object Diagram

d.      Component Diagram

e.      Composite Structure Diagram

f.        Deployment Diagram

2.       Behavior Diagrams, which include:

a.       Activity Diagram

b.      Sequence Diagram (diagram same for SysML)

c.       Communication Diagram

d.      Interaction Overview Diagram

e.      Timing Diagram (optional)

f.        Interaction Tables (optional)

g.       State Machine Diagram (diagram same for SysML)

h.       Use Case Diagram (diagram same for SysML)

Structure diagrams are used to visualize, specify, construct and document the static aspects of a system i.e. no time element).  Behavior diagrams are used to visualize, specify, construct and document the dynamic aspects of a system (i.e. time is considered).

Not all diagrams in each category need to be used when defining a software system, just what is needed to communicate how the software system works; how it is built structurally, how it behaves, and what it interacts with.  Without both category representations, a software system is not fully defined and can lead to issues when the software system is built.  For example, without understanding the timing requirements for a real-time embedded system, software designers may define the software structure to meet all functional requirements of the system, but find out during testing that it does not meet the timing requirements. The software system would need to be re-architected to meet both the functional and timing requirements. 

The next sections provide simple examples of some of the UML diagram types including common diagrams with SysML.  These are simple examples based on the Digital Camera System first introduced in Chapter 6.  Note that the examples are not meant to represent a complete Digital Camera System or to be 100% accurate.  They are just representative of the UML diagrams to help understand the basic structure and information they are conveying.  There are many books that provide more detailed instructions on how to create these diagrams and on what they are used for when modeling a software system.  There are also many Web Sites that provide examples of each diagram type.

11.2.2 Structure Diagrams- Examples of Class Diagrams, Package Diagrams and Deployment Diagrams are Structure Diagrams shown and discussed in this section.

Class Diagram - A class diagram is used to show a set of classes, interfaces, and collaborations and their relationships.  Class diagrams provide a static view of the system.  Using the Simple Digital Camera System, Figure 11-1 illustrates a possible class diagram based on Take a Digital Picture Use Case .

Figure 11-1 Class Diagram Example for a Simple Digital Camera System

Shutter, LCD, and Storage are all classes within the system that interact with each other and represent real world items that make-up a Digital Camera.  Each class contains attributes and operations.  Attributes are a named property of a class that describes a range of values that instances of the property may hold; using software terms, a data structure or a variable.  An attribute is some piece of information the class needs in order to perform its function.  A class may have any number of attributes or none at all.  The class Storage has an attribute of imageCount to keep track of the number of images stored and it has three operations indicated, storeImage, incrementImageCount, and isStorageAvailable. 

When first identifying classes within a system start with the requirements specification or Use Cases and identify nouns.  Alternatively, start with the real world items that make-up the system.  All of these are candidates for possible classes.  As more is understood about the system, the class diagrams will evolve until the final class diagram for the system is achieved.  In modeling a software system, the classes tend to become more abstract and may not have real world counterparts.

The example above does not contain all possible graphic elements that are possible in a class diagram.  For more information, see the UML specification at: http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML

Package Diagram- A package is a general-purpose mechanism for organizing elements into groups.  Or in other words, it indicates a subsystem or block of functionality within a system and is used to simplify the view of a system in order to understand it better.  Figure 11-2 shows a possible package diagram for the Digital Camera System.

Figure 11-2 Package Diagram Example for a Simple Digital Camera System

The package diagram also shows the interactions or relationships between each package.  Figure 11-2 illustrates the Camera Controller Package as a depdency on both the Image Acquisition Package and the Storage Device Package.  Since packages are a way of abstracting or simplfying the view of a system, each package may contain more packages, class diagrams, use cases, components,  etc. until the view is at the lowest level.  Well-designed packages group like elements that tend to change together.  Well-structured packages are loosely coupled and highly cohesive (See Section 6.6.3 for definitions of coupling and cohesion).  The graphic elements used in class diagrams to show relationships are also used in package diagrams.  Package diagrams are used to show different views of a system’s architecture.    

Deployment Diagram - A deployment diagram shows the configuration of run time processing nodes and the components that live on each node.  They are used to illustrate the static deployment view of a software system onto the hardware on which the system executes.  Names of the nodes should represent the vocabulary of the hardware in the domain of the system being developed.  Nodes represent a physical element and represent a computational resource having at least some memory and processing capability.  Figure 11-3 shows a deployment diagram for the Digital Camera System assuming there are three processors in the system.

Figure 11-3 Example Deployment Diagram for a Digital Camera System

For real-time embedded software with only one processor, the deployment diagrams look like context diagrams from the system engineering world.  They show the devices with which the processor board is interacting using what are called stereotypes to identify the hardware components.  Client/Server and Distributed software systems have more processors on their deployment diagrams and provide the designers with an understanding of where each software component resides on the physical hardware.

The relationships between nodes are typically an association that represents a physical connection (i.e. Ethernet, cPCI bus).   For more information on possible types of relationships for deployment diagrams, see the UML specification at: http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML

---

[1] Systems Modeling Language and SysML are either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries.

11 Introduction to Model Based Systems Engineering

11.0 Introduction

The advantages of using labeled graphical models, diagrams, tables of data and similar non prose descriptions compared to natural language or prose descriptions have been discussed several times. Now we make a distinction between two types of models. One type is, as stated, a non-prose description of something. The second type is analysis models; either static models that predict performance or dynamic models referred to as simulations. Static analysis models may be strictly analytical or may be machine readable and executable. Modern simulations are typically machine readable and executable. This is an arbitrary distinction as the DoD defines a model as a physical, mathematical, or otherwise logical representation of a system, entity, phenomenon, or process. (DoD 5000.59 -M 1998)

In Chapter 5 it was stated that PBSE is model based but includes prose documents as well. The models used in PBSE can be either the first type or the second type. Now we want to introduce a different approach to using models for systems engineering. This approach is called Model Based System Engineering (MBSE) and it strives to accomplish system engineering with models that are machine readable, executable or operative. An INCOSE paper^11-1 defines MBSE as an approach to engineering that uses models as an integral part of the technical baseline that includes the requirements, analysis, design, implementation, and verification of a capability, system, and/or product throughout the acquisition life cycle.

This chapter is an introduction to MBSE; no attempt is made to review or even summarize the extensive literature on MBSE. MBSE is rapidly evolving, facilitated both by development of commercial tools and by an INCOSE effort to extend the maturity and capability of MBSE over the decade from 2010 to 2020. Whereas we attempt to describe how MBSE offers benefits compared to traditional prose based systems engineering it isn’t claimed that pure MBSE is superior or inferior to methodologies that mix MBSE, PBSE and traditional methods. The intent is to provide an introduction that enables readers to assess how MBSE can be beneficial to their work and to point the way toward further study.

Traditional systems engineering is a mix of prose based material, typically requirements and plans, and models such as functional diagrams, physical diagrams and mode diagrams. Eventually design documentation ends in drawings, which are models. MBSE can be thought of as replacing the prose documents that define or describe a system, such as requirements documents, with models. We are not concerned as much with plans although plans like test plans are greatly improved by including many diagrams, photos and other models with a minimum of prose.

To some it may seem difficult to replace requirements documents with models. However, QFD can be stand-alone systems engineering process and QFD is a type of MBSE. Although it does not attempt to heavily employ machine readable and executable models, QFD is an example of defining requirements in the form of models. Another way to think about requirements is that mathematically requirements are graphs and can therefore be represented by models. A third way to think about requirements as models is as tree structures. Each requirement may have parent requirements and daughter requirements and just as no leaf of a tree can exist without connection to twigs, twigs to limbs, and limbs to the trunk no requirement can stand alone. Trees can be represented by diagrams so requirements can all be represented in a diagram.

Throughout this book there is an emphasis on representing design information as models in order to reduce ambiguity and the likelihood of misinterpretation of text based design information. There is also an emphasis on using analysis models and simulations as much as possible throughout the life cycle of a system development. The use of models and simulations improves functional analysis, design quality, system testing and system maintenance. Think of MBSE as combining these two principles; then it becomes clear why MBSE is desirable. Another way to look at traditional systems engineering vs. MBSE is for traditional systems engineering engineers write documents and then models are developed from the documents. In MBSE the approach is to model what is to be built from the beginning.

Model based design has been standard practice for many engineering specialties since the 1980s. Structural analysis, thermal analysis, electrical circuit analysis, optical design analysis and aerodynamics are a few examples of the use of Computer Aided Design (CAD) or model based design analysis. It is systems engineering that been slow to transition from non-model based methods, with the exception of performance modeling and simulation. To achieve the benefits of MBSE systems engineers need to embrace requirements diagrams, Use Case analysis and other MBSE tools along with performance modeling and simulation.

11.1 Definitions of Models As Applied to MBSE

Models have been referred to throughout this material without providing a formal definition or defining the types of models typically used in systems engineering. Formally, a model is a representation of something, as described in the DoD definition given above. For our purposes a model is a representation of a design element of a system. Types of models of interest to MBSE include^11-2:

Schematic Models: A chart or diagram showing relationships, structure or time sequencing of objects. For MBSE schematic models should have a machine-readable representation. Examples include FFBDs, interface diagrams and network diagrams.

Performance Model: An executable representation that provides outputs of design elements in response to inputs. If the outputs are dynamic then the model is called a simulation.

Design Model: A machine interpretable version of the detailed design of a design element. Design models are usually represented by CAD drawings, VHDL, C, etc.

Physical model: A physical representation that is used to experimentally provide outputs in response to inputs. A breadboard or brass board circuit is an example.

Achieving machine readable and executable models means that the models must be developed using software. Useful languages used by software and systems engineers for such models are the Unified Modeling Language^TM (UML®) and its derivative SysML™. A brief introduction to these languages is presented here along with references for further study.

Chapters Available for Viewing or Download

The first 10 chapters of the book Introduction to Pattern and Model Based Systems Engineering are available for viewing or download at https://sites.google.com/site/themanagersguide/system-engineering . These ten chapters include all of the material posted to date on this blog. The final two chapters are planned to be posted in September, first as blogs on this site and then as complete downloadable chapters on the site above. After the final chapters are posted a book will be published with all the chapters. This book is intended as a guide for training in modern methods that speed up systems engineering, reduce the cost of the systems engineering phase of product development and improve the quality of the systems engineering work.

Two More Risk Reduction Tools

10.3.2 Risk Register - The risk summary grid can be used as a tool in the development team’s risk management meetings but a better tool is the risk register. The risk register ranks risks by the expected dollar value of each risk according to the operational definition of risk given earlier. Constructing the risk register on a spreadsheet allows risks to be sorted by dollar value so that the highest risks are always on top of the list. The risk register also facilitates keeping all risks in the same data base even though management actions may be active on only the top five or ten at any time. When a high risk is mitigated the expected dollar value of the risk is reduced and it falls out of the top five or ten but is still on the list. This enables reviewing mitigated risks to ensure they remain mitigated or to readdress a risk at a later time when all the higher risks have been mitigated to even lower values. An example of a simple risk register with three risks constructed on a spread sheet is shown in Figure 10-8.

Figure 10-8 An example of a risk register constructed in columns on a spread sheet.

The risk type and impact if risk occurs are usually described as “if”, “then” statements as in Figure 10-8. This helps the management team remember specifically what each risk entails as they conduct reviews over the life of the activity. Expected values are expressed in dollars, which facilitates both ranking and decisions about how much resources should be assigned to mitigation activities. Assuming of course that in managing activities in the development organization it is the practice to hold some fraction of the budget in reserve to handle unforeseen events. Funds from this reserve budget are assigned to risk mitigation activities. Risk mitigation actions should be budgeted and scheduled as part on on-going work. A failure many inexperienced managers make is handling risks outside of the mainline budget and schedule. This undisciplined approach often leads to risk management degenerating into an action item list and finally to a reactive approach to unexpected events rather that a proactive approach to reduce the risks systematically.

A more complete risk register template than the example shown in Figure 10-8 might contain columns for the risk number, title, description (if), impact (then), types (three columns: cost, schedule, quality or technical), probability of occurrence, cost impact, schedule impact, mitigation plan and mitigation schedule. The form of the risk register template is not critical so the team managing the risks should construct a template that contains the information they feel they need to effectively manage risks.

The risk register, if properly maintained and managed, is a sufficient tool for risk management on small and short duration projects. Setting aside an arbitrary management reserve budget to manage risks is ok for small projects. Portions of the reserve are allocated to mitigation of risks and the budgets and expenses for risk mitigation can be folded into the overall cost management system. Large, long duration projects or high value projects warrant a more focused approach to budgeting for risk management. These management actions do not usually involve systems engineering but systems engineers should be aware of the methods used for management of risk reduction budgets.

In summary, spending a small amount of money in proactively mitigating risks is far better than waiting until the undesirable event occurs and then having to spend a large amount of money fixing the consequences. Remember that risk management is proactive (problem prevention) and not reactive. Also risk management is NOT an action item list for current problems. Finally, risk management is an on-going activity. Do not prepare risk summary grids or risk registers and then put them in a file as though that completes the risk management process, a mistake inexperienced managers make too often.

10.4 Design Iterations Reduce Risk

Design iterations are planned “build, test and learn” activities for high risk parts of the system; parts that are small enough to build, test and assess rapidly. Examples best illustrate the concept of using design iterations to reduce risk:

• Engineering builds and tests two types of breadboard circuits to get data needed for a subsystem specification, trade studies and subsequent detailed design
• Manufacturing pilots a new production process during architecture definition and uncovers yield problem early
• Analysts simulate three candidate signal processing algorithms during concept development and recommend the best
• Software implements and tests high risk parts of three alternative approaches for system control software during requirements analysis.

Design iteration is not a fire fighting technique; it is a methodical risk reduction methodology. Design iteration is not “build the entire system, test it and fix it if it doesn’t work” approach; in fact it is intended to avoid falling into such an unproductive approach. Note that “spiral development”, described earlier, is system level risk reduction methodology. Design iterations can be thought of as a methodology that supports implementing progressive freeze.

Recall the message in Figure 6-32 that the cost of making design changes is low in the early stages of a system development when there are many degrees of freedom and becomes higher as the development progresses and there are fewer and fewer degrees of freedom. Thus design iterations are cost effective for many high risk items in the early stages of a development. It’s ok to have many short cycle iterations in parallel in early phases and it’s ok to “throw away” some results as the team learns and lowers risk.