The Manager's Guide

The Book is Now Available

2011-12-10T07:53:00.000-08:00

The collection of blog articles posted on this site is now available in book form for $19.50. You can order it from Create Space or from Amazon . The book includes edited versions of the blog articles plus other typical features of a book such as a table of contents and index. The title of the book is Modern Methods of Systems Engineering: With an Introduction to Pattern and Model Based Methods.
You can learn more about the book and the authors at our web site. Our plan is to add additional material to this blog as the authors feel it can contribute to systems engineering methods. This material will be added as it is available rather than on a regular weekly basis. The authors welcome comments on any of the blog articles and corrections, suggestions or other comments on the book. If any readers have material they feel contributes to systems engineering methods that isn't covered in the book please contact us via a comment and we will consider adding your material to this blog.

12.3 Return to Chief Designer Model

2011-10-24T08:53:00.000-07:00

Implementing ICE allows system development teams to function similarly to the model of chief designer and draftsman/assistant team popular before the emergence of modern complex systems in the 1960s. The large screen displays in a design command center and the supporting analysis models and simulations bring design information to the lead systems engineer with very little information latency. The lead systems engineer in a design session can interact with the design team just as a chief designer interacted with the draftsman/assistants in former times. This may be as near to the efficiency of the “craftsman” model as can be expected for the development of complex systems. Lead systems engineers can be empowered to function as chief designers for the systems engineering work in a mature ICE environment supported by comprehensive analysis, modeling and simulation tools. The lead systems engineer can be empowered to function as the chief designer for the entire development cycle if supported by specialist chief designers who are responsible for the electrical design, the mechanical design, etc.

Implementing ICE with an overall chief designer and supporting specialty chief designers for each IPT allows interleaving IPT design sessions with SEIT design sessions so that the desired iteration between levels of design and the coordination between IPTs necessary to maintain balance in the design can be achieved and the schedule for the development is likely to be significantly reduced.

The actual times it takes for the planning and for the documentation and analysis periods are highly dependent on the sophistication of the tools used by the design team. If pattern based systems engineering is used and if the team’s modeling and simulation tools are extensive and mature then the planning and the documentation/analysis periods may be possible to be integrated into the design sessions so that the design work becomes a continuous series of three to four hour intense design sessions in the design command center followed by a day or two of planning/documentation/analysis, followed by another design session. Alternatively, the team may be organized with design specialists and documentation specialists. The design specialists conduct analysis, modeling and simulations to determine design parameters. The documentation specialists capture the design parameters and product the necessary specifications, drawings and CDRLs while the design specialists are generating the next layer of design parameters.

12.4 Integrating Modern Methods

The 21^st century brought new constraints to system development:

Customers and global competition are demanding faster and cheaper system development
Skilled engineers are retiring faster than replacements are experienced enough to replace them
Development teams are spread across multiple sites and multiple organizations.

This new century has also brought new tools for system development:

Fast internet and intranet connections provide real time communication across multiple sites
Relatively cheap but powerful computers and network communication tools
Model based and Pattern Based Systems Engineering processes
Powerful CAD tools
Maturing integrated design and design documentation processes
Some integrated design and manufacturing tools
Potential for end to end documentation management

The question for systems engineers is how to use the new tools to relieve the new constraints.

One answer to this question is to integrate the methods described in this and previous chapters with disciplined execution of the traditional fundamentals of the systems engineering process.

Figure 12-4 illustrates methods that can be synergistically integrated to achieve reductions in design time of factors of three to ten and cost reduction by factors of two to three. These benefits are not achieved instantly. Training is needed for teams to use these methods effectively. Investment is necessary to achieve the best results of PBSE and to push patterns down from the system level to subsystem and assembly levels. Ongoing investment is necessary to maintain the modeling, simulation, software development and CAD/CAM tools required to remain competitive. Document generation and document management tools are likely to require investments and training to effectively reduce engineering effort. Finally it must be recognized that systems engineering is going to continually evolve by inventing new processes and tools and by introducing new methods and tools for executing current processes.

The rapid introduction of new tools and processes in the past two decades have increased the fraction of a systems engineer’s time that must be spent in training and self-study in order to maintain required skills. This is likely to continue. The increases in complexity of new systems are also likely to continue and these complexity increases may require more sophisticated systems engineering processes than available today. Hopefully new methods and tools will be developed that can handle increased system complexity and the increases in productivity from using new methods are enough to make time available for the training and self-study systems engineers will need.

Figure 12-4 The methods described in this book can be integrated to provide a robust approach to system development that can achieve dramatic reductions in cost and design time.

12.2 Integrated Concurrent Engineering (ICE) for Small Teams

2011-10-18T08:12:00.000-07:00

The ICE approach described in Section 12.1.1 and 12.1.2 applies to teams of 15 to several hundred people; assuming the large teams are organized into smaller IPTs of 10 to 25 people. The design command centers can be shared by many individual teams on a development project because each team uses the center for only a half day at a time and for only three to ten days a month typically. Some system developments can be accomplished with smaller teams of five to ten people. Whereas small teams can also use the same design command center and concept of operations as larger teams an alternative approach may be even more efficient.

Work spaces for most organizations use individual cubicles or cubicles shared by two or three people. Most of these work spaces are modular and can easily be reconfigured. For example suppose a project has six or seven workers each in his/her cubicle. Typically, workers are assigned cubicles without consideration of where others working on the same projects are located. Much of the communication takes place via emails or periodic meetings in a conference area. Figure 12-3 shows how a space of eight cubicles can be rearranged to colocate seven workers and a conference table. Collocating workers as shown in Figure 12-3 enables continuous face to face interactions to replace emails and periodic meetings in conference rooms. Research has shown that problems are solved much faster by groups communicating face to face compared to groups communicating via email. That is to be expected because the information latency in face to face communications is almost instantaneous whereas it is many seconds or even hours with email.

It increases productivity to have two workers with related skills close enough together that they can see each other’s computer screens and discuss what is on the screen without moving from their work positions. Examples include mechanical and thermal engineers or mechanical engineers and designers skilled in mechanical CAD tools that are supporting the engineers.

If the team leader is collocated with the rest of the team so that he/she can facilitate an ICE process then dramatic reductions in project cost and design time should be realized just as it is for larger teams using ICE. A caution is that team dynamics are more important for collocated teams than for teams in individual cubicles. Teams must be comprised of individuals who work well together or else productivity suffers. Workers who perform better as individual contributors are likely better left in their own cubicle. It is also advisable to provide training so that the workers understand why they are being asked to give up the privacy of individual cubicles.

Figure 12-3 Individual cubicles can be rearranged to form a space allowing a team of four to eight to see each other’s computer screens and exchange information without moving from their work station.

12 Integrating Modern Methods for Faster Systems Engineering

2011-10-11T07:54:00.000-07:00

12.0 Introduction

In chapter 2 it was explained that the best model for system development is the “craftsman” model that was widely used before systems became so complex that a single chief engineer could no longer understand a system in sufficient detail to control all aspects of design. System engineers, design engineers and other specialty engineers became necessary to handle the complexity of modern systems. Although this new approach has enabled the development of very complex modern systems it takes much longer to develop a system now than it used to take when a chief engineer and his/her team could develop a new system in a few months.

One objective of this book is to introduce new methods that enable the systems engineering work on system development to be accomplished faster and more accurately. This book has an emphasis on systems engineering fundamentals, as described in the DoD SEF and the NASA SE handbook, and readers will note that it takes time and discipline to follow these fundamental processes. Complex systems cannot be developed cost effectively by shortcutting the systems engineering fundamentals; what is necessary is faster and more accurate methods for executing these fundamentals. Accuracy is required because any errors in systems documentation results in costly “find and fix” efforts later in design or in integration and test. Several methodologies for ensuring accuracy have been discussed including using graphical models in place of text as much as possible, employing redundant tools for developing documentation, using modeling and simulation to support requirements analysis as well as design and checking work at the three levels of worker checking his/her work, peer reviews and design reviews.

In chapter 5 pattern based systems engineering was introduced, which when properly implemented, can dramatically reduce the time to produce much of the top level systems engineering documentation and at the same time increase the accuracy of requirements definition. Similarly using validated system performance models and simulations throughout the development cycle aids in reducing development time and increases the accuracy of requirements and design concepts and the robustness of systems.

The objective of this chapter is to describe methods for reducing information latency and then to show how integrating modern methods can achieve greatly reduced time for systems engineering work without sacrificing any process fundamentals critical to the accuracy of this work. Information latency is the time between when information is generated and the time it is available to others who are depending on the information for the next steps in their work. Information latency was increased with the evolution from the craftsman model for product development to models with systems engineers; this is the primary reason modern systems take so long in development. Reducing information latency to levels near what it was for the craftsman model is a necessary step in achieving faster system development cycles.

12.1 Integrated Concurrent Engineering

In the 1990s a method emerged for reducing information latency for system development teams. This method is similar to methods used previously when teams of workers were brought together in a common work area to collaborate to quickly accomplish some project. Many organizations in the aerospace and defense industry use special work areas to collocate the people writing and publishing proposals, which are often highly time constrained projects. The use of proposal preparation rooms with personal dedicated to working in these rooms results in highly productive teams for the limited times involved in typical proposal efforts. A major part of the increased productivity is due to the reduction in information latency achieved by having workers so close they can ask questions of one another and get immediate answers. If teams tried to maintain such intense work over long periods productivity would taper off due to workers being unable to maintain the long hours and intense work without burnout.

The methods that evolved in the 1990s achieve the reduction in information latency and the associated productivity gains of the colocated teams and permit teams to work effectively for long periods without burnout. These methods became possible by exploiting new technology as well as new work management methods.

The availability of inexpensive large screen display projectors, n to one video switches and inter/intra nets makes it cost effective to set up special work rooms where teams of 10 to 25 knowledge workers can gather with their laptops and software tools. These teams can simultaneously work and share the work results with the entire team on the large screen displays as fast as the results are available. Many organizations now use such facilities for teams to gather for intense work and information sharing periods of three to four hours two or three times weekly. These sessions must be well planned and workers must come prepared to work and share results in real time. Planning, documenting work and time consuming tasks are performed in between the sessions in the special work rooms. This approach is called by a number of names but Integrated Concurrent Engineering (ICE) is a common name. This approach is effective because it reduces information latency from minutes to seconds or hours to minutes.

ICE is proven to reduce cost and schedule of complex projects by factors of three to ten ^{12-1, 12-2}. Neff & Presley ^12-3 reported that the Jet Propulsion Laboratory initially achieved an average of over 80% reduction in project costs and significantly improved the quality and speed of work. With more experience a 92% reduction in design time and a 66% reduction in cost was reported. Designs produced using ICE are of higher quality because they examine each option in greater detail earlier in the design process by sharing thousands of design variables in real time. Approaches that are proven to reduce cost and schedule by factors of three to ten and increase quality at the same time should not be dismissed by organizations that wish to remain competitive.

The benefits of ICE are better understood by examining the work space and the work process in more detail. There is no single best work space design or work process; each organization tailors both to their views and their business processes. Examples presented here are guidelines for understanding ICE and not necessarily the best for any specific organization.

12.1.1 The ICE Design Command Center- A schematic diagram of a small ICE work area is shown in Figure 12-1. The room has large screen displays located where they are visible to everyone in the room. Several displays are used so that several different types of information can be displayed simultaneously. Each skill cluster has workers with common specialties and each worker has computer equipment and the design, modeling and simulation tools associated with his/her specialty. Alternatively each cluster can be an IPT responsible for a segment of the system design. Each of the computers is connected to one of the large screen displays via a video switch so that the results of analysis, modeling or simulation can be shared with everyone in the room on one of the large screen displays. The facilitator, typically the lead systems engineer for the systems engineering phase of development, is responsible for maintaining the design baseline visible to all at all times and to lead the team through a preplanned sequence of analysis tasks that lead to design decisions in real time.

Figure 12-1 A diagram of a small ICE work are showing six specialty skill clusters, five large screen displays and a facilitator/leader.

Many developments take place in multiple locations and it isn't practical to bring teams from different locations together in a common work area for each ICE session. Modern technology enables teams working is several separately located ICE facilities to communicate with each other and to see each other’s work in real time; thereby achieving the benefits of ICE even though the teams are in different locations. Technology allows virtual collocation. Using ICE with a team that is fractionated into multiple locations and even diverse cultures has the benefit of facilitating the interactions necessary to the success of any system development.

12.1.2 The ICE Concept of Operations - Integrated Concurrent Engineering is a repeating series of planning sessions followed by team work sessions, followed by documentation and follow-up analysis in parallel with the planning for the next series of team work sessions. The times for each of the components of the ICE cycle are dependent on the type and complexity of the system being developed. Example times are given here to explain the concept of operations. Development teams are likely to find adopting this concept of operations to their systems development requires adjustments. A typical approach is illustrated in Figure 12-2 where a series of three plan/ meet/document sessions are shown and each of the meet or design sessions is comprised of three intense team sessions separated by a day or two. Individual design sessions may last from two to four hours.

Figure 12-2 An example ICE concept of operations where A is planning, B is series of team work sessions and C is documentation and analysis.

The planning, indicated by A in Figure 12-2, is done by team leaders and might take a week to plan a series of three intense work sessions, indicated by B, over another week period. The series of work sessions is followed by perhaps two weeks of documenting work done in the design sessions and carrying out analyses that takes too much time to be done in design sessions. In the example shown in figure 12-2 nine intense design sessions are planned, executed and documented in a an eight week period. Note that since the design sessions are the only activities that require the ICE design command center such a center can support three or four ICE projects or separate IPTs of a large project concurrently.

12-1 The Integrated Concurrent Enterprise by David B. Stagney, MIT Department of Aeronautics and Astronautics, Sloan School of Management, August 13, 2003

12-2 Observation, Theory, and Simulation of Integrated Concurrent Engineering by John Chachere, John Kunz, and Raymond Levitt, Center For Integrated Facility Engineering, Working Paper #WP087, Stanford University, August 2004

12-3 Implementing a Collaborative Conceptual Design System

– The Human Element is the Most Powerful Part of the System by Jon Neff and Stephen P Presley, IEEE, 2000.

11.3 Creating an Executable Model

2011-10-04T07:10:00.000-07:00

(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

2011-09-27T08:27:00.000-07:00

(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

2011-09-20T08:17:00.000-07:00

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

2011-09-14T08:19:00.000-07:00

11.0Introduction

The advantages of using labeled graphical models, diagrams, tablesof data and similar non prose descriptions compared to natural language orprose descriptions have been discussed several times. Now we make a distinctionbetween two types of models. One type is, as stated, a non-prose description ofsomething. The second type is analysis models; either static models thatpredict performance or dynamic models referred to as simulations. Staticanalysis models may be strictly analytical or may be machine readable andexecutable. 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 includesprose documents as well. The models used in PBSE can be either the first typeor the second type. Now we want to introduce a different approach to usingmodels for systems engineering. This approach is called Model Based SystemEngineering (MBSE) and it strives to accomplish system engineering with modelsthat are machine readable, executable or operative. An INCOSE paper^11-1defines MBSE as an approach to engineering that uses models as an integral partof the technical baseline that includes the requirements, analysis, design,implementation, and verification of a capability, system, and/or productthroughout the acquisition life cycle.

This chapter is an introduction to MBSE; no attempt is made toreview or even summarize the extensive literature on MBSE. MBSE is rapidlyevolving, facilitated both by development of commercial tools and by an INCOSEeffort to extend the maturity and capability of MBSE over the decade from 2010to 2020. Whereas we attempt to describe how MBSE offers benefits compared totraditional prose based systems engineering it isn’t claimed that pure MBSE issuperior or inferior to methodologies that mix MBSE, PBSE and traditionalmethods. The intent is to provide an introduction that enables readers toassess how MBSE can be beneficial to their work and to point the way towardfurther 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 indrawings, which are models. MBSE can be thought of as replacing the prosedocuments that define or describe a system, such as requirements documents,with models. We are not concerned as much with plans although plans like testplans are greatly improved by including many diagrams, photos and other modelswith a minimum of prose.

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

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

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

11.1Definitions of Models As Applied to MBSE

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

SchematicModels: A chart or diagram showingrelationships, structure or time sequencing of objects. For MBSE schematicmodels should have a machine-readable representation. Examples include FFBDs,interface diagrams and network diagrams.

PerformanceModel: An executable representationthat provides outputs of design elements in response to inputs. If the outputsare dynamic then the model is called a simulation.

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

Physicalmodel: A physical representation that isused to experimentally provide outputs in response to inputs. A breadboard orbrass board circuit is an example.

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

Chapters Available for Viewing or Download

2011-08-30T07:55:00.000-07:00

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

2011-08-03T07:39:00.000-07:00

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.

Constructing a Risk Summary Grid

2011-07-25T15:06:00.000-07:00

10.3 Tools for Risk Management

Standard tools for risk management include risk matrices; also called risk summary grids, and risk registers. There are also tables of definitions and guidelines that aid in using the matrices and registers. A methodology useful for reducing risk through proactive and planned build and test steps is called design iteration. These tools and design iteration are described in this chapter. Other tools aiding or supporting the identification of risks include fault trees, worst case analysis and failure modes analysis. Risk burn down charts that display how the total expected value of all identified risks is reduced with time as mitigation actions are completed are useful in monitoring the overall progress of risk mitigation and the effectiveness of budgeting for risk management.^10-1

10.3.1 Risk Summary Grid - The risk summary grid is a listing of the top ranked risks on a grid of probability vs. impact. The risk summary gird is excellent for showing all top risks on a single graphic and grouping the risks as low, medium or high. Typical grids are 3 x 3 or 5 x 5. An example 5 x 5 template is shown in Figure 10-2.

Figure 10-2 One example of a 5 x 5 risk summary grid template

The 5 x 5 risk summary grid enables risks to be classified as low, medium or high; typically color coded green, yellow and red respectively, and ranked in order of importance. Relative importance is the product of probability and impact. Note that the definitions for low and medium are not standard. The definition used in Figure 10-2 is conservative in limiting low risk to the five squares in the lower left of the grid with risk values of 0.5 or less. Medium risks have values of 0.7 to 3.5 and high risks have values from 4.5 to 8.1. Others, e.g. the Risk Management Guide for DOD Acquisition^10-2 (An excellent tutorial on risk management), define the entire first column plus six other lower left squares as low risk.

Identified risks are assigned to a square according to the estimates of their probability of occurrence and impact to the overall activity. In Figure 10-2 there is one medium risk, shown by the x in the square with a probability 0.5, impact 7 and therefore having a relative importance of 3.5. The numbers shown for impact are arbitrary and must be defined appropriate to the activity for which risk is being managed.

Some risk management processes described on the web use letters rather than numbers to rank risk probability in constructing risk summary grids. The objective is to assign either a probability numbers or letter to each risk. To do this it is necessary to make a judgment of the likelihood that the risk occurs. The table shown in Figure 10-3 provides reasonable guidelines for such judgments. Thus, if the likelihood of an event occurring is judged to be remote then assign the probability of 0.1 or the letter A. If it is highly likely assign 0.7 or D. It may be argued that guidelines are needed for what is remote or likely. Unfortunately this wouldn’t help as there is always some guess work or judgment required. If several members of a team discuss the likelihood then they can probably reach agreement and this is adequate. It is important for the novice to understand that it isn’t essential that the probabilities are exact. The objective is to come close enough to compare the relative probabilities of several events so that the events can be prioritized in relation to their relative risk or relative probability of occurrence.

Figure 10-3 Guidelines for assigning probability numbers or letters to risk based on judgment criteria.

After assigning a probability to a risk it is necessary to make a judgment of the impact of occurrence of the risk. A risk event can cause an unexpected cost or cost increase, a slip in the schedule for achieving some related event or reduce the quality or technical performance of some design requirement. It is also possible for the risk to impact two or even all three of the cost, schedule or quality measures. The table shown in Figure 10-4 provides one set of guidelines for assigning impact numbers 1, 2, 3, 4 or 5 to a risk event.

Figure 10-4 Guidelines for assigning impact numbers to a risk event.

Costs can be defined as either percentage of budget, as shown in Figure 10-4, or in actual monetary units. Similarly schedule can be defined as percent slip, relative slip or actual time slip.

A risk summary grid template using the guidelines provided in Figures 10-3 and 10-4 is shown in Figure 10-5.

Figure 10-5 A less conservative risk summary grid template using the guidelines provided in Figures 10-3 and 10-4.

The process using a 3 x 3 risk summary grid typically assigns probability of risks as 0.1, 0.3 or 0.9 and impacts as 1, 3 or 9. There are three squares for each of the low, medium and high risk classifications with relative importance values ranging from 0.1 to 8.1 according to the products of probability and impact. An example of a 3 x 3 risk summary grid template is shown in Figure 10-6.

Figure 10-6 An example template for a 3 x 3 risk summary grid.

Specific process details or numerical values are not important. What is important is having a process that allows workers and managers to assess and rank risks and to communicate these risks to each other, and in some cases to customers. The simple risk summary grids are useful tools for accomplishing these objectives and are most useful in the early stages of the life cycle of an activity and for communicating an overall picture of risks.

The identified risks are collected in a list and the ten or so with the highest risk values are numbered or given letter identifications. The associated numbers or letters are then displayed in the appropriate square on the risk summary grid. In use the risk values of each square are either not shown in the square or made small so there is room for several risk identifiers in a square. The risk summary grid then provides a quick visual measure of the number of high, medium and low risks. In the early stages of a project it should be expected that there are more risks in the high and medium categories than the low and as risk mitigation progresses the number of high risks are reduced.

Having identified the risks and ranked them the team must decide what to do with risks that are assigned as Low, Medium or High. One set of guidelines is shown in the table provided in Figure 10-7.

Figure 10-7 Example guidelines for actions for each level of risk.

Again, the specific guidelines a team employs is not as important as it is for the team to have agreed upon guidelines appropriate to their work and organization and to follow them.

10-1 The Manager’s Guide for Effective Leadership by Joe Jenney, AuthorHouse, 2009

10-2 Risk Management Guide for DOD Acquisition, Sixth Edition (Version 1.0), Department of Defense, August 2006 http://www.dau.mil/pubs/gdbks/risk_management.asp

Introduction to Risk and Opportunity Management

2011-07-19T09:05:00.000-07:00

Risk is always present; its presence is a fact of nature. Accepting that risk is always present is the first step toward managing risks to reduce the effects of risks. Managing risk is the responsibility of the development program leaders but the mechanics are often delegated to systems engineering. Even if systems engineers are not responsible for maintaining the processes and tools it is essential that they understand the importance of risk management and the methods used for effective risk management. Inattention to risk management is the second highest cause of projects not meeting expectations. Just like other systems engineering processes it takes experience and discipline to conduct effective risk management.

Development programs also have opportunities for improving cost, schedule or system performance. It is important to identify and manage opportunities as well as risks in order to have an effective program. This chapter defines risk, outlines a risk management process that can be used for risk and opportunity management and provides examples of templates and processes useful for risk and opportunity management.

10.1 Risk Definition

Risk is the consequence of things happening that negatively impact the performance of a system development project. Risks arise from events that occur inside and outside the development organization. The consequence of an event can impact the quality, cost or schedule of a system development project, or some combination of these effects. There is risk in any project but there are usually more risks associated with projects that are new to the development organization’s experience. Risks are always present in the development of new products or services or changes to the processes, people, materials or equipment used in the development of products or services. Risks to developing new products and services arise from unplanned changes to the internal environment or changes in the external environment, such as the economy, costs of materials, labor market, customer preferences or actions by a competitor, a regulating body or a government agency. An effective development team faces up to risks and manages risks so that the negative impacts are minimized.

There is an operational definition of risk that aids in managing risk. This definition is:

Risk R is The Probability p of an Undesirable Event Occurring; Multiplied by The Consequence of the Event Occurrence measured in arbitrary units C or dollars $; R=p x C or R=p x $.

This definition allows risks to be quantified and ranked in relative importance so that the development team knows which risks to address first, i.e. the risks with the highest values of R. If the event consequence is measured in dollars then it’s easier to evaluate how much budget is reasonable to assign to eliminate or reduce the consequence of the risk.

The second definition measures risk in units of dollars. Thus impacts to the quality of a product or service or to the schedule of delivering the product or service are converted to costs. Impacts to quality are converted to dollar costs via estimated warranty costs, cost of the anticipated loss of customers or loss of revenue due to anticipated levels of discounting prices. Schedule delays are converted to dollar costs by estimating the extra costs of labor during the delays and/or the loss of revenue due to lost sales caused by the schedule delays.

Opportunities can also be defined operationally by the product of the probability an opportunity for improvement can be realized and the consequence if the opportunity is realized, measured either in arbitrary units or dollars. In the rest of this chapter when risk is addressed the reader should remember that it can be viewed as “risk or opportunity”.

The key to good risk management is to address the highest risk first. There are three reasons to address the highest risk first. First is that mitigating a high risk can result in changes to plans, designs, approaches or other major elements in a project. The earlier these changes are implemented the lower the cost of the overall project because money and people resources are not wasted on work that has to be redone later. The second reason is that some projects may fail due to the impossibility of mitigating an inherent risk. The earlier this is determined the fewer resources are spent on the failed project thus preserving resource for other activities. The third reason is that any project is continually competing for resources with other activities. A project that has mitigated its biggest risks has a better chance of competing for continued resource allocation than activities that still have high risks.

10.2 Managing Risk

Managing risk means carrying out a systematic process for identifying, measuring and mitigating risks. Managing risk is accomplished by taking actions before risks occur rather than reacting to occurrences of undesirable events. The DoD SEF defines four parts to risk management and the NASA SE Handbook defines five top level parts and a seven block flow chart for risk management. It is helpful to decompose these into 11 steps. The 11 steps in effective risk management are:

1. Listing the most important requirements that the project must meet to satisfy its customer(s). These are called Cardinal Requirements and are identified in requirements analysis or via Quality Function Deployment.

2. Identifying every risk to a project that might occur that would have significant consequence to meeting each of the Cardinal Requirements

3. Estimating the probability of occurrence of each risk and its consequences in terms of arbitrary units or dollars

4. Ranking the risks by the magnitude of the product of the probability and consequence (i.e. by the definition of risk given above)

5. Identifying proactive actions that can lower the probability of occurrence and/or the cost of occurrence of the top five or ten risks

6. Selecting among the identified actions for those that are cost effective

7. Assigning resources (funds and people) to the selected actions and integrating the mitigation plans into the project budget and schedule

8. Managing the selected action until its associated risk is mitigated

9. Identifying any new risks resulting from mitigation activities

10. Replace mitigated risks with lower ranking or new risks as each is mitigated

11. Conduct regular (weekly or biweekly) risk management reviews to:

· Status risk mitigation actions

· Brainstorm for new risks

· Review that mitigated risks stay mitigated

In identifying risks it is important to involve as many people that are related to the activity as possible. This means people from senior management, the development organization, other participating organizations and supporting organizations. Senior managers see risks that engineers do not and engineers see risks that managers don’t recognize. It is helpful to use a list of potential sources of risk in order to guide people’s thinking to be comprehensive. A list might look like that shown in Figure 10-1.

Figure 10-1 An example template for helping identify possible sources of risk to the customer’s cardinal requirements.

It also helps ensure completeness of understanding risks if each risk is classified as a technical, cost or schedule risk or a combination of these categories.

Summarize Verification Results in a Compliance Matrix

2011-07-15T07:07:00.000-07:00

9.2.5 Compliance Matrix – The data resulting from the actions summarized in the verification matrix for verifying that the system meets all requirements are collected in a compliance matrix. The compliance matrix shows performance for each requirement. It flows performance from the lowest levels of the system hierarchy up to top levels. It identifies the source of the performance data and shows if the design is meeting all requirements. The bottom up flow of performance provides early indication of non-compliant system performance and facilitates defining mitigation plans if problems are identified during verification actions. An example compliance matrix for the switch module is shown in Figure 9-3.

Figure 9-3 An example Compliance Matrix for the simple switch function illustrated in Figure 9-1.

Note that the requirements half of the compliance matrix is identical to the requirements half of the verification matrix. The compliance matrix is easily generated by adding new columns to the verification matrix. Results that are non-compliant, such as the switching force, or marginally compliant, such as the on resistance, can be flagged by adding color to one of the value, margin or compliant columns or with notes in the comments column.

In summary, the arrows labeled verification in Figure 6-4 from functional analysis to requirements analysis, from design to functional analysis and from design to requirements analysis relate to the iteration that the systems engineers do to ensure the design is complete and accurate and that all “shall” requirements are verified in system integration and system test. This iteration is necessary so that for each requirement a verification method is identified, any necessary test equipment, test software and data analysis software is defined in time to have validated test equipment, test procedures and test data analysis software ready when needed for system integration and test.

9.3 Systems Engineering Support to Integration, Test and Production

Manufacturing personnel and test personnel may have primary responsibility for integration, test and production however; systems engineers must provide support to these tasks. Problem resolution typically involves both design and systems engineers and perhaps other specialty engineers depending on the problem to be solved. Systems engineers are needed whenever circumstances require changes in parts or processes to ensure system performance isn’t compromised.

Planning for System Integration and Testing

2011-07-12T09:11:00.000-07:00

9.2.2 System Integration and Test Plan – The purpose of the System Integration and Test Plan (SITP) is to define the step by step process for combining components into assemblies, assemblies into subsystems and subsystems into the system. It is also necessary to define at what level software is integrated and the levels for conducting verification of software and hardware. Because of the intimate relationship of the verification matrix to the system integration and test it is recommended that the SITP be developed before the verification matrix is deemed complete.

The SITP defines the buildup of functionality and the best approach is usually to build from the lowest complexity to higher complexity. Thus, the first steps in integration are the lowest levels of functionality; e.g. backplanes, operating systems and electrical interfaces. Then add increasing functionality such as device drivers, functional interfaces, more complex functions and modes. Finally implement system threads such as major processing paths, error detection paths and end-to-end threads. Integration typically happens in two phases: hardware to hardware and software to hardware. This is because software configured item testing often needs operational hardware to be valid. Two general principles to follow are: test functionality and performance at the lowest level possible and, if it can be avoided, do not integrate any hardware or software whose functionality and performance has not been verified. It isn’t always possible to follow these principles, e.g. sometimes software must be integrated with hardware before either can be meaningfully tested.

One objective of the SITP is to define a plan that avoids as much as possible having to disassemble the system to implement fixes to problems identified in testing. A good approach is to integrate risk mitigation into the SIPT. For example, there is often a vast difference between the impact of an electrical design problem and a mechanical or optical design problem. Some electrical design or fabrication problems discovered in I & T of an engineering model can be corrected with temporary fixes (“green wires”) and I & T can be continued with minimal delay. However, a serious mechanical or optical problem found in the late stages of testing, e.g. in a final system level vibration test, can take months to fix due to the time it takes to redesign and fabricate mechanical or optical parts and conduct the necessary regression testing. Sometimes constructing special test fixtures for early verification of the performance of mechanical, electro-mechanical or optical assemblies is good insurance against discovering design problems in the final stages of I & T.

The integration plan can be described with an integration flow chart or with a table listing the integration steps in order. An integration flow chart graphically illustrates the components that make up each assembly, the assemblies that make up each subsystem etc. Preparing the SITP is an activity that benefits from close cooperation among system engineers, software engineers, test engineers and manufacturing engineers. For example, system engineers typically define the top level integration flow for engineering models using guidelines listed above. Manufacturing engineers typically define the detailed integration flow to be used for manufacturing prototypes and production models. If the system engineers use the same type of documentation for defining the flow for the engineering model that manufacturing engineers use then it is likely that the same documentation can be edited and expanded by manufacturing engineers for their purposes.

It should be expected that problems will be identified during system I & T. Therefore processes for reporting and resolving failures should be part of an organizations standard processes and procedures. System I & T schedules should have contingency for resolving problems. Risk mitigation plans should be part of the SITP and be in place for I & T; such as having adequate supplies of spare parts or even spare subsystems for long lead time and high risk items.

System integration is complete when a defined subset of system level functional tests has been informally run and passed, all failure reports are closed out and all system and design baseline databases have been updated. The final products from system integration include the Test Reports, Failure Reports and the following updated documentation:

Rebaselined System Definition

Requirements documents and ICDs
Test Architecture Definition
Test Plans
Test Procedures

Rebaselined Design Documentation

Hardware Design Drawings
Fabrication Procedures
Formal Release of Software including Build Procedures and a Version Description Document
System Description Document
TPM Metrics

It is good practice to gate integration closeout with a Test Readiness Review (TRR) to review the hardware/software integration results, ensure the system is ready to enter formal engineering or development model verification testing and that all test procedures are complete and in compliance with test plans. On large systems it is beneficial to hold a TRR for each subsystem or line replaceable unit (LRU) before holding the system level TRR.

9.2.3 Test Architecture Definition and Test Plans and Procedures – The SITP defines the tests that are to be conducted to verify performance at appropriate levels of the system hierarchy. Having defined the tests and test flow it is necessary to define the test equipment and the plans and procedures to be used to conduct the tests. Different organizations may have different names for the documentation defining test equipment and plans. Here the document defining the test fixtures, test equipment and test software is called the Test Architecture Definition. The test architecture definition should include the test requirements traceability database and test system and subsystems specifications.

Test Plans define the approach to be taken in each test; i.e. what tests are to be run, the order of the tests, the hardware and software equipment to be used and the data that is to be collected and analyzed. Test Plans should define the entry criteria to start tests, suspension criteria to be used during tests and accept/reject criteria for test results.

Test Procedures are the detailed step by step documentation to be followed in carrying out the tests and documenting the test results defined in the Test Plans. Other terminologies include a System Test Methodology Plan that describes how the system is to be tested and a System Test Plan that describes what is to be tested. Document terminology is not important; what is important is defining and documenting the verification process rigorously.

Designing, developing and validating the test equipment and test procedures for a complex system is nearly as complex as designing and developing the system and warrants a thorough systems engineering effort. Neglecting to put sufficient emphasis or resources on these tasks can result in delays of readiness of the test equipment or procedures and risks serious problems in testing due to inadequate test equipment or processes. Sound systems engineering practices treat test equipment and test procedure development as deserving the same disciplined effort and modern methods as used for the system under development.

The complexity of system test equipment and system testing drives the need for disciplined system engineering methods and is the reason for developing test related documentation in the layers of SITP, Test Architecture Definition, Test Plans and finally Test Procedures. The lower complexity top level layers are reviewed and validated before developing the more complex lower levels. This approach abstracts detail in the top levels making it feasible to conduct reviews and validate accuracy of work without getting lost in the details of the final documentation.

The principle of avoiding having to redo anything that has been done before also applies to developing the Test Architecture Definition, Test Plans and Test Procedures. This means designing the system to be able to be tested using existing test facilities and equipment where this does not compromise meeting system specifications. When existing equipment is inadequate then strive to find commercial off the shelf (COTS) hardware and software for the test equipment. If it is necessary to design new special purpose test equipment then consider whether future system tests are likely to require similar new special purpose designs. If so it may be wise to use pattern base systems engineering for the test equipment as well as the system.

Where possible use test methodologies and test procedures that have been validated through prior use. If changes are necessary developing Test Plans and Procedures by editing documentation from previous system test programs is likely to be faster, less costly and less prone to errors than writing new plans. Sometimes test standards are available from government agencies.

9.2.4 Test Data Analysis – Data collected during systems tests often requires considerable analysis in order to determine if performance is compliant with requirements. The quantity and types of data analysis needed should be identified in the test plans and the actions needed to accomplish this analysis are to be included in the test procedures. Often special software is needed to analyze test data. This software must be developed in parallel with other system software since it must be integrated with test equipment and validated by the time the system completes integration. Also some special test and data analysis software may be needed in subsystem tests during integration. Careful planning and scheduling is necessary to avoid project delays due to data analysis procedures and software not being complete and validated by the time it is needed for system tests.

Methods for Verifying System Performance

2011-07-08T13:32:00.000-07:00

9.2 Verifying that System Requirements are Met

The first phase of verifying system requirements is a formal engineering process that starts with requirements analysis and ends when the system is accepted by its customer. During the system integration and testing steps must be taken to verify that the system satisfies every “shall” statement in the requirements. These shall statement requirements are collected in a document called the Verification Matrix. The results of the integration and testing of these requirements are documented in a Compliance Matrix. The integration and testing is defined and planned in a System Integration and Test Plan. Related documentation includes the Test Architecture Definition, hardware and software Test Plans & Procedures and Test Data Analysis Plans.

The roles of systems engineers in verification include:

Developing the optimum test strategy and methodology and incorporating it into the design as it is developed
Developing the top level System Integration and Test Plan
Developing the hierarchy of Integration and Test Plans from component level to system level
Documenting all key system and subsystem level tests
Defining system and subsystem level test equipment needed and developing test architecture designs
Developing the Test Data Analysis Plans
Analyzing test data
Ensuring that all shall requirements are verified and documented in the Compliance Matrix.

Good systems engineering practice requires that requirements verification takes place in parallel with requirements definition. The decision to define a requirement with a “shall” or “may” or “should” statement involves deciding if the requirement must be verified and if so how the requirement will be verified. This means that the requirements verification matrix should be developed in parallel with the system requirements documentation and reviewed when the system requirements are reviewed, e.g. at peer reviews and at a formal System Requirements Review (SRR).

9.2.1 Verification Matrix – The verification matrix is documentation that defines for each requirement the verification method, the level and type of unit for which the verification is to be performed and any special conditions for the verification. Modern requirements management tools facilitate developing the verification matrix. If such tools are not used then the verification matrix can be developed using standard spreadsheet tools.

There are standard verification methods used by systems engineers. These methods are:

Analysis -Verifies conformance to required performance by the use of analysis based on verified analytical tools, modeling or simulations that predict the performance of the design with calculated data or data from lower level component or subsystem testing. Used when physical hardware and/or software is not available or not cost effective.
Inspection - Visually verifies form, fit and configuration of the hardware and of software. Often involves measurement tools for measuring dimensions, mass and physical characteristics.
Demonstration - Verifies the required operability of hardware and software without the aid of test devices. If test devices should be required they are selected so as to not contribute to the results of the demonstration.
Test - Verifies conformance to required performance, physical characteristics and design construction features by techniques using test equipment or test devices. Intended to be a detailed quantification of performance.
Similarity - Verifies requirement satisfaction based on certified usage of similar components under identical or harsher operating conditions.
Design – Used when compliance is obvious from the design, e.g. “The system shall have two modes, standby and operation”.
Simulation – Compliance applies to a finished data product after calibration or processing with system algorithms. May be only way to demonstrate compliance.

The DoD SEF defines only the first four of the methods listed above. Many experienced systems engineers find these four too restrictive and also use the other three methods listed. To illustrate a verification matrix with an example consider the function Switch Power. This function might be decomposed as shown in Figure 9-1.

Figure 9-1 A function Switch Power might be decomposed into four sub functions.

An example verification matrix for the functions shown in Figure 9-1 is shown in Figure 9-2. In this example the switch power function is assumed to be implemented in a switch module and that both an engineering model and a manufacturing prototype are constructed and tested. In this example no verification of the switch module itself is specified for production models. Verification of the module performance for production modules is assumed to be included in other system level tests.

It’s not important whether the verification matrix is generated automatically from requirements management software or by copy and paste from a requirements spreadsheet. What is important is to not to have to reenter requirements from the requirements document to the verification matrix as this opens the door for simple typing mistakes.

Figure 9-2 An example verification matrix for a switch module.

Verifying the Performance of a System Design

2011-07-06T07:48:00.000-07:00

9 Processes and Tools for Verifying Technical Performance

9.0 Introduction

There are two approaches to verifying technical performance. One is using good engineering practices in all the systems engineering and design work to ensure that the defined requirements and the design meets customer expectations. The other is a formal verification process applied in two phases to hardware and software resulting from the design to verify that requirements are met. Both begin during requirements analysis and continue until a system is operational. The work is represented by the three arrows labeled verification in Figure 6-4 that constitute the backward part of the requirements loop, the design loop and the loop from design synthesis back to requirements analysis and includes both verifying completeness and accuracy of the design and verifying the technical performance of the system.

The first phase of formal system verification typically ends with delivery of a system to the customer but may include integration and testing with a higher level system of the customer or another supplier. The second phase of system verification is accomplished by testing the system in its intended environment and used by its intended users. This phase is typically called operational test and evaluation and is the responsibility of the customer for military systems but may involve the supplier for commercial systems and some NASA systems.

9.1 Verifying Design Completeness and Accuracy

Verifying the completeness and accuracy of the design is achieved by a collection of methods and practices rather than a single formal process. The methods and practices used by systems engineers include:

System engineers checking their own work
Checking small increments of work via peer reviews
Conducting formal design reviews
Using diagrams, graphs, tables and other models in place of text where feasible and augmenting necessary text with graphics to reduce ambiguity
Using patterns vetted by senior systems engineers to help ensure completeness and accuracy of design documentation
Developing and comparing the same design data in multiple formats, e.g. diagrams and matrices or diagrams and tables
Verifying functional architecture by developing a full set of function and mode mapping matrices including:

Customer defined functions to functions derived by development team (Some team derived functions are explicit in customer documentation and some are implicit.)
Functions to functions for defining internal and external interfaces among functions
Sub modes to functions for each of the system modes
Mode and sub mode transition matrices defining allowable transitions between modes and between sub modes

Using tools such as requirements management tools that facilitate verifying completeness and traceability of each requirement
Using QFD and Kano diagrams to ensure completeness of requirements and identify relationships among requirements
Using robust design techniques such as Taguchi Design of Experiments
Iterating between requirements analysis and functional analysis and between design synthesis and functional analysis
Employing models and simulations to both define requirements and verify that design approaches satisfy performance requirements
Validating all models and simulations used in systems design before use (Note the DoD SEF describes verification, validation and accreditation of models and simulations. Here only verification and validation are discussed.)
Employing sound guidelines in evaluating the maturity of technologies selected for system designs
Maintaining a through risk management process throughout the development program
Conducting failure modes and effects analysis (FMEA) and worse case analysis (WCA).

Engineers checking their own work are the first line of defense against human errors that can affect system design performance. One of the most important things that experienced engineers can teach young engineers is the importance of checking all work and the collection of methods for verifying their work that they have learned over their years in the engineering profession. Engineers are almost always working under time pressure and it takes disciple to take the time to check work at each step so that simple human mistakes don’t result in having to redo large portions of work. This is the same principle that is behind using peer reviews to catch mistakes early so that little rework is required rather than rely on catching mistakes at major design reviews where correcting mistakes often requires significant rework, with significant impact on schedule and budget.

A reason for presenting duplicate methods and tools for the same task in Chapter 6 was not just that different people prefer different methods but also to provide a means of checking the completeness and accuracy of work. The time it takes to develop and document a systems engineering product is a usually a small fraction of the program schedule so that taking time to generate a second version in a different format does not significantly impact schedule and is good insurance against incomplete or inaccurate work.

Pattern based systems engineering, QFD and Taguchi Design of Experiments (DOE) help ensure the completeness, accuracy and robustness of designs. Extensive experience has demonstrated the cost effectiveness of using these methods even though QFD and Taguchi DOE require users to have specialized training to be effective.

Studies have shown that selecting immature technologies result in large increases in costs (See http://www.dau.mil/conferences/presentations/2006_PEO_SYSCOM/tue/A2-Tues-Stuckey.pdf) Immature technologies often do not demonstrate expected performance in early use and can lead to shortfalls in the technical performance of designs. As a result both NASA and DoD include guidelines for selecting technologies in their acquisition regulations. Definitions of technology readiness levels used by NASA are widely used and are listed at http://esto.nasa.gov/files/TRL_definitions.pdf . Definitions are also provided in Supplement 2-A of the DoD SEF.

Failure analysis methods like FEMA and WCA are more often used by design engineers than systems engineers but systems engineers can include failure modes and worse case considerations when defining the criteria used in system design trade studies.

In summary, verifying technical performance during system development includes the disciplined use of good engineering practices as well as the formal performance verification process. This should not be surprising as these practices have evolved through experience specifically to ensure that system designs meet expected performance as well as other requirements.

Who Leads System Design?

2011-06-30T13:15:00.000-07:00

8.5 Design Oversight Responsibility

Although it is not the intent of this book to describe systems engineering management processes it is helpful to briefly describe how roles and responsibilities change during the system development phases. The first change in responsibility takes place when the baseline design is refined through trade studies to be the preferred design, e.g. a best value design, and the design requirements database is complete. The system development work is then at the end of the define requirements phase and ready to enter the design phase. This means the design requirements are complete to the level of responsibility of each of the lowest level IPTs, assuming the work is organized so that the lowest level IPT leaders are able to work in the “craftsman” model, i.e. the leader has the knowledge and experience to make all the design decisions for the work assigned to his/her IPT. At this point the individual IPTs take leadership responsibility from the SEIT or systems engineering and lead in determining how the system is designed and any prototypes built.

During the design phase systems engineering watches over the design to ensure requirements compliance, testability and producibility and monitors MOEs, progress on “ilities” and risk management. In addition, systems engineering is responsibility to manage any specification changes. If designers encounter difficulties in meeting an allocated requirement then systems engineers should take responsibility for determining if and how the requirement in question can be modified without jeopardizing overall requirements compliance. The systems engineering role during the design phase can be summarized as supporting the designers to ensure that a balanced and compliant design is achieved that is testable, producible and maintainable.

The transition from the system definition phase to the design phase is typically gated with a design review, e.g. a System Design Review (SDR). Program managers often wish to move systems engineers off a development project when the actions items from a SDR are complete. Although this is a time to increase the design specialty engineers and decrease the systems engineers on the IPTs removing too many systems engineers can leave the designers without adequate systems engineering support and cause other necessary tasks to be understaffed. It is better to assign the systems engineers to tasks like preparing system and subsystem integration and test plans and completing and maintaining the system design documentation.

When the design phase is compete and any prototypes are fabricated then systems resumes lead responsibility during test even though other specialty engineers may conduct the testing. Typically this change in leadership occurs sometime during integration and subsystem testing of an engineering model or prototype. These leadership responsibility transitions should occur naturally for IPTs with experienced systems and design engineers.

Some Useful Design Concept Diagrams

2011-06-28T07:30:00.000-07:00

8.4 Diagrams Useful in Selecting the Preferred Design

As discussed previously much of systems engineering is determining relationships between a system and its environment and among the various subsystems. Ultimately these relationships are defined in detailed drawings but understanding the relationships in order to select the preferred design is aided by examining a system with different levels of abstraction. The modern tools used for electrical and optical design and the design practices of electrical and optical design engineers develop their respective design concepts with diagrams. The diagrams start with block diagrams with a high level of abstraction, perhaps just naming the subsystems, and proceed to greater and greater detail. This process makes it easy for systems engineers and other design engineers to readily understand the electrical and optical design concepts.

Although there are excellent modern design tools for mechanical and thermal design it isn’t as easy to present the mechanical and thermal designs with ever decreasing levels of abstraction so that system engineers and other design engineers can easily understand the mechanical and thermal designs. Experienced mechanical and thermal design engineers develop the desired diagrams and tailor their diagrams to the system being developed so that others can readily understand and assess their designs. A few examples are presented here to illustrate how experienced mechanical and thermal designers examine and communicate their design concepts. Note how easy it is to think of alternative design approaches when design concepts are presented in simple block diagram form with a high degree of abstraction. This enables engineers other than expert mechanical and thermal designers to assess design concepts and suggest design alternatives.

8.4.1 Simple Mechanical and Thermal Block Diagrams - Many times a simple block diagram is useful in describing a mechanical or a combined mechanical/thermal design concept. Figure 8-7 is an example showing a system that consists of five assemblies, a frame for mounting the assemblies and a mounting plate that supports the system with a three point mount.

Figure 8-7 A simple mechanical block diagram of a system illustrates how the assemblies interact with each other and the mounting frame.

It’s easy to see that the design concept is for each assembly to be coupled to the mounting frame and uncoupled from any other assembly. Four of the assemblies are temperature controlled whereas the fifth assembly is attached to the mounting frame but not within the temperature controlled region. By abstracting all of the size, shape, material and other characteristics of the system the basic mechanical and thermal relationships are easily understood and alternative concepts are obvious. The actual models that the mechanical designer uses to conduct trade studies of alternate mounting concepts are of course much more detailed and usually include the detailed characteristics of the various assemblies, frame and mounting plate; however, this detail is not necessary to explain the concepts and results of the trades to the system engineers and other designers.

Let’s suppose that three of the assemblies of the system shown in Figure 8-7 have critical alignment requirements. A perfectly good way to record and communicate the alignment requirements is with allocation trees. However, sometimes it makes the requirements clearer and possibly less prone to misunderstandings if a simple diagram is used in place of a tree. Such a diagram with the alignment requirements for each of the three assemblies and for the attachment points of each on the system mounting frame might look like Figure 8-8.

Figure 8-8 A simple block diagram illustrating the alignment requirements for three of assemblies and their respective interfaces with the mounting frame.

Similar simple block diagrams can be used to illustrate temperatures and heat flow paths. It sometimes makes design concepts easier to understand if mechanical and thermal diagrams are developed together. Examples are shown in Figures 8-9 and 8-10 that illustrate simple block diagrams of structural interfaces and thermal interfaces on similar block diagrams.

Figure 8-9 A block diagram illustrating structural interfaces within a system and between the system and its parent platform.

Figure 8-10 A block diagram illustrating thermal interfaces within a system and between the system and its environment using the same diagram approach as used for the structural interface diagram.

Even though it takes some time and care to develop diagrams such as shown in the examples above the benefits to the team in understanding and refining design concepts to reach the preferred design are well worth the effort. Diagrams like these and related simple diagrams for electrical, optical and other design concepts are invaluable in explaining a design concept to customers and management.

Modeling and Simulation Supports Entire Development Cycle

2011-06-23T06:36:00.000-07:00

8.3 Modeling and Simulation

Modeling and simulation tools are used in all phases of system development from definition to end-of-life. Systems engineers are concerned with the models and simulations used in system definition, design selection and optimization, and performance verification. Systems engineers should identify the models and simulations needed for these tasks during the program planning phase so that any development of required models and simulations can be complete by the time they are needed. Examining the customer’s system requirements and the planned trade studies help identify the needed models and simulations. Parameter diagrams are often helpful in identifying the models and simulations needed.

Models constrained by requirements are typically adequate to be used in the system definition phase to define a baseline design concept. Models may be adequate to develop error budgets and allocations but performance simulations are often necessary to select and optimize designs.

System simulations and particularly performance simulations are especially useful in system performance verifications. Therefore it is necessary to include any necessary validation of system simulations in test plans and procedures. End-to-end system simulations are sometimes needed to verify final design compliance with requirements. Other uses include developing the requirements for data analysis tools needed during subsystem and system verification testing, reducing risk and time for developing test software and supporting troubleshooting during test and operational support.

Examples of how models and simulations might be used in system development are shown in Figure 8-4. In this figure the system under development is assumed to be a system that measures parameters by sampling the parameters that are related to a desired phenomenon that cannot be easily or economically measured directly. The measured samples are assumed to be processed first by Data Algorithms, which in this example produce calibrated data. The calibrated data are

Figure 8-4 Examples of ways models and simulations might be used in developing a sensor or measurement system.

then input to Product Algorithms which use the calibrated data to produce estimates of the desired phenomena.

It is assumed that a database of truth data is available. This truth data is used in two ways. It is used to predict the parameters that the system is designed to sample by using a model; called a Parameter Model in Figure 8-4. These predicted parameters are then the input to the System Model and System Simulation. The truth data is also used to assess the validity of the system model and the system simulation by comparing the results predicted by the Product Algorithms with the truth data. This example assumes that the System Model generates calibrated data and the System Simulation generates data that must be processed by the Data Algorithms to provide calibrated data. If truth data is available for the desired phenomenon during system operation then the truth data can be used to assess the performance of the system during operation as suggested by the figure.

It is assumed that Environmental Models are developed that can also generate the parameters to be measured. Information from the System Specification is used to generate the parameters in the desired range and with the desired statistics. If the database of truth measurements is representative of the specified range and statistics of the phenomena to be measured then the Parameter Model can be used to generate inputs for system design analysis and as comparisons for system test data analysis and comparisons. If no database of truth measurements is available then Environmental Models are used in place of the Parameter Model but it is not possible to assess results against truth data.

8.3.1 Performance Modeling and Simulation - System performance models and system performance simulations are used in trade studies to evaluate alternative designs and to iteratively optimize the selected design. Typically the system design objective is to develop the “best value” design solution. A “best value” design can be defined as:

· Achieves performance above minimum thresholds

· Has life cycle costs within customer’s or marketing’s defined cost limits

· Meets requirements allocations (mass, power, etc.)

· Assessed to be relatively low risk (so that cost targets are likely attainable)

A general approach to achieving a best value system design is to develop multiple design concepts, assess the cost and performance of each and iterate until the best value is achieved. This usually involves progressively lower level trade studies.

Assessing the cost and performance of system design concepts requires analysis and state-of-the-art tools. Design tools for mechanical, thermal, electrical and optical analysis are well developed, widely available and indispensible for design of modern systems. The same cannot be said for the cost models and top level performance modeling and simulation tools for systems analysis. System performance modeling and simulation tools are too specialized for widespread utility. Thus most systems organizations must develop the modeling and simulation tools needed for defining their systems. Useful cost models are available for some systems for organizations developing systems for government agencies like the Defense Department and NASA. Examples of cost estimating models useful for several types of systems and cost estimating tasks include SEER (http://www.galorath.com/) and PRICE (http://www.pricesystems.com/).

The first two steps in seeking a best value design are shown in Figure 8-5. The cost model is used to identify a number of design parameters that drive the system cost and quantify how the cost, or the relative cost, depends on each design parameter. The system performance modeling and simulation tools are used to quantify the dependence of system performance on each of the same design parameters.

Figure 8-5 Cost models and system performance models and simulations are used to determine the relationship of cost and performance on design parameters.

Having the relationships of cost and performance on design parameters these data can be combined to reveal how the selected design parameters drive the relationship of performance to relative life cycle as shown in Figure 8-6. Assuming the cost and performance relationships are determined for n design parameters then the result is n trades of cost vs. performance as a function of each of the n design parameters. It is usually straightforward to select the value of each design parameter that offers the best value design according to the desired criteria. For example, in Figure 8-6 the best value for the design parameter shown is 8 cm because it’s near the maximum of the linear portion of the parametric curve and it offers the best performance within the constraints on this particular design parameter.

Figure 8-6 The best value design is determined by combining the data from the cost model and performance models and simulations that determine how design parameters drive cost and performance.

Design Trade Matrices and Other Trade Study Methods

2011-06-21T07:46:00.000-07:00

8.2.2 Design Trade Matrices - The Pugh Concept Selection process can be repeated until no new concepts are suggested that are better than the existing set. When a final set is agreed upon the next step is to conduct a weighted trade using a design trade matrix (decision matrix in NASA nomenclature). A design trade matrix might look like Figure 8-3 for three candidate concepts.

Figure 8-3 An example design trade matrix for three concepts and three weighted criteria.

Again if QFD is used the weights for the criteria can be drawn from the QFD analysis. If not then engineering judgment can be used for the weights. In the example shown the weights are selected over a range from 1 to 5. An alternative is to use percentages that add to 100 percent for all criteria. Attribute scores can be 1, 2 or 3 or 1, 3 or 9 or the actual results of using an analytical tool. If different tools are used for different criteria the attribute scores can be normalized to a fixed range for all criteria to maintain the validity of the selected weights.

The step following determining the total scores is to perform a sensitivity check so ensure the results are significant. One method of performing a sensitivity check is to examine evaluation values for criteria with large weights. If a small change in one evaluation changes the total score to favor a different concept that the results aren’t reliable. If the results are not reliable then consider adjusting the weights, adding additional criteria or using a more sensitive method of determining attribute scores.

8.2.3 Pitfalls for Trade Studies – Common mistakes that can lead to ineffective trade study results include:

Poor requirements definition can result in a trade result that may not be good for properly defined requirements.
Valuable alternatives may be missing if alternatives are defined without brainstorming by several experienced people with a diversity of skills and experience.
Allowing biased weightings or selection criteria often results in selecting alternatives that are driven by the biases and not the optimum alternative that would be selected with unbiased trades.
The fatal error is having no winner. This results if the spread of the weighted score is less than the spread of estimates of errors. The sensitivity analysis step in Figure 7.1 is crucial to effective trades.
Inappropriate models used for determining attribute scores. Models not only have to be relevant to the trade being performed they must have credibility in the eyes of the decision makers, they should lead to scores for the different alternatives that are spread more than the estimates of errors in the model results, the algorithms and internal mathematics must be transparent to the users and they must be sufficiently user friendly that the analysis can be conducted with confidence and in a timely manner.
Conducting system and design related trade studies outside the control of systems and design engineering. Development program managers sometimes pull systems and design engineers off programs early to save money and then allow procurement, operations or product assurance personnel to conduct trades without the oversight of the appropriate systems or design engineers. This can lead to a multitude of difficulties and usually expensive difficulties. Suffice it to say that systems engineers and design engineers must retain control of systems and design trades throughout the life cycle.

8.2.4 Other Design Trade and Decision Methodologies - The design trade process defined in Figure 8-1 is a proven methodology but not the only useful tool or methodology available. The NASA Systems Engineering handbook describes several techniques useful for trade studies and more general decision making. These include:

· Cost benefit analysis

· Influence diagrams/decision trees – the NASA handbook and Wikipedia have poor descriptions of these tools. A more useful description can be found at http://www.agsm.edu.au/bobm/teaching/SGTM/id.pdf and for a more thorough and mathematical description see http://www.stanford.edu/dept/MSandE/cgi-bin/people/faculty/shachter/pdfs/TeamDA.pdf These tools have available software to facilitate developing the diagrams and converting influence diagrams to decision trees.

· Multi-criteria decision analysis (MCDA) - useful for cases where subjective opinions are to be taken into account. Start with: http://en.wikipedia.org/wiki/Multi-criteria_decision_analysis See also http://www.epa.gov/cyano_habs_symposium/monograph/Ch35_AppA.pdf

o Analytic hierarchy process (AHP) – a particular type of MCDA that employs pairwise comparison of alternatives by experts.

· Utility Analysis (The DoD SE handbook calls this Utility Curve Analysis)

o Multi-Attribute Utility Theory (MAUT) (A MCDA technique for Utility Analysis)

· Risk-Informed Decision Analysis- for very complex or risky decisions that need to incorporate risk management into the decision process.

Trade Study Methodology

2011-06-09T07:36:00.000-07:00

8.2 Trade Study Methodology

It is a good practice for a systems engineering organization to adopt a standard methodology for conducting trade studies. A standard methodology makes control and management easier and the discipline of following a standard methodology usually results in faster and better trade results and gives management more confidence in the results. Independent of the methodology used trades must be defined and planned. Key top level trades should be identified in the SEMP but not all trades can be listed in the SEMP. Trade Tree diagrams are useful for defining trades if there are only a few alternatives and a few levels under consideration. Trade Tree diagrams are decision trees without the chance values applied to each node. Trade Trees and Decision Trees are useful tools well defined in the NASA Systems Engineering Handbook. If there are many trades to be conducted for a single level then N-squared diagrams are more useful than Trade Trees. The value of the N-squared diagram is that it provides an easy way to determine the best order to conduct trades and conducting the trades in the best order saves time and money. An N-squared diagram for trades is developed following the same process as for defining and ordering tasks using N-squared diagrams as described in Chapter 4.

One standard trade study methodology is present here and it is defined for physical design trades. Experience shows that this methodology is useful for design trades at all levels of a system hierarchy. This methodology combines Design Trade Matrices with Pugh Concept Selection and is best described by the diagram shown in Figure 8-1.

Figure 8-1 An excellent trade study process combines Pugh Concept Selection with a Design Trade Matrix.

Brainstorming is a good way to identify alternatives and many alternatives should be defined. It is important to select people with a diversity of skills and experience for effective brainstorming. Otherwise the alternatives may not have the variety and innovativeness desired. If a large number of alternatives is identified the number of alternatives can be thinned to narrow the trade space. This is accomplished by point design analysis or by using engineering judgment to select a subset of the “best” concepts. The next step is to define selection criteria. These criteria are derived from the requirements. If a process like QFD is used there are a set of requirements that are more important to customers than others. These are often called cardinal requirements or key requirements and they are the ones most likely to be the important criteria that should be used in trade studies.

8.2.1 Pugh Concept Selection - Having defined selection criteria the next step is to refine the concepts. Pugh Concept Selection is the critical step that leads to improved concepts. If large or complex system designs are being traded then first conduct Pugh Concept Selection at a sub system level. Then combine the best results into a top level system design concept.

Pugh Concept Selection is conducted by choosing one alternative concept as the benchmark. Each of the other alternative concepts is then compared to the benchmark. The objective is to use the results of the comparison to suggest new concepts or even new criteria. A matrix diagram is used to compare the alternative concepts to the benchmark as shown in Figure 8-2.

Figure 8-2 A Pugh Concept Selection matrix for three alternative concepts compared to a benchmark concept.

For each criteria each concept is compared to the benchmark concept and a decision is made as to whether the concept is better (+1), worse (-1) or the same (S) as the benchmark. Weighting should not be used at this point in the trades. The score for each concept is obtained by summing the number of pluses and minuses, each counting as a plus one or minus one and the S counting as zero. The next step is to examine the concept that scores the best, assuming that one scores better than the benchmark. For example, in Figure 8-2 concept a scores better than the benchmark and the other two concepts. Note however that for criteria 3 concepts b and c are superior to both the benchmark and concept a. Examine the reasons for concepts b and c being better for criteria 3 and see if changes can be made to either concept a or to the benchmark that will turn concept a’s minus score for criteria 3 to a plus or a same. The idea is to consider new alternatives that combine the best features of the traded concepts to arrive at a better concept. Thus the objective of Pugh Concept Selection is not to select the best of the alternatives but to define new concepts that are better than any of the initial concepts.

Managing to a Baseline System Design

2011-06-06T12:48:00.000-07:00

We now turn to the next step for systems engineers after the first system design concept is defined. This next step is the subject of chapter 8.

8 Selecting the Preferred Design

8.0 Review and Introduction

Selecting the preferred design involves several types of systems analysis tasks including: trade studies, risk assessment, cost modeling, performance analysis/modeling and simulation. Before describing some of these processes it is helpful to review several points from chapters 5 and 6. Trade studies, assessment and analysis are involved in each of the three major steps in the systems engineering process. Referring back to the systems engineering process described in Figure 6-4 shows that iteration takes place not just between each of the major steps of requirements analysis, functional analysis and design synthesis but also between each of these steps and the systems analysis processes of trade studies, modeling and simulation included under technical management. Figure 5-1 illustrates how these systems analysis tasks support the decisions involved in flowing down requirements. Chapter 6 discussed how functional analysis is involved in the flow down of requirements and how systems analysis supports allocating requirements to functions. Chapter 6 also discussed the value in considering many design alternatives at each stage of design synthesis but particularly during concept design. The preferred process for considering design alternatives is to arrive at a baseline design and then conduct trade studies of alternative designs. It is systems analysis processes that aid in selecting the preferred design from the alternatives studied. This chapter describes methods for conducting trade studies, provides an overview of modeling and simulation and introduces some additional diagrams that are useful in describing design concepts.[J1]

8.1 Baseline Concept Management

Project leaders must strive for a balance between forcing decisions too early so that promising alternatives are not considered and leaving too many decisions until just before major design reviews so that the design details are unclear. The standard process for achieving this balance is forcing a design baseline as soon as possible and then conducting trade studies of alternatives to the baseline. This facilitates having a controlled process for making decisions to adopt changes to the baseline and it enables all team members to have the same view of the baseline design at any time.

As soon as the top level function and physical diagrams, the system level specification document and the ICD are complete declare this documentation to be the baseline design. It’s ok that many assemblies or even subsystems are immature; just use the team’s best guesses, but do include as much detail as is available. The baseline design documentation should be maintained where it is available to all team members but no changes to the documentation are allowed without a formal decision process being executed.

As the design progresses and trade studies are performed use the baseline as the starting point and the reference for trades and design decisions. If analysis or trade studies suggest the baseline should change and the project leadership, including the lead systems engineer, agrees then the change is made and the lead systems engineer should notify all key engineering participants that a design change to the baseline has been made. Then the baseline documentation should be updated.

Following this simple baseline management process ensures the whole team is working from the same design data base at any time and it facilitates a controlled design decision process.

[J1]

A Brief Summary of QFD

2011-05-31T07:50:00.000-07:00

7.6 Summary

Quality Function Deployment (QFD) is a systematic process for translating customer requirements into appropriate company requirements at each stage from research and product development to engineering and manufacturing to market/sales and distribution. QFD is a complement to the System Engineering process. The principles of system engineering using QFD span the entire life cycle of a product. QFD is not a quality tool to audit functional organizations, but is a structured planning tool to guide and direct the product development process.

In summary QFD

· Is a systematic means of ensuring that the demands of the customer and the market place are accurately translated into products and/or services.

· Provides both a planning tool and a process methodology in a structured approach.

· Identifies the most important product characteristics.

· Provides a comprehensive tracking tool and communication medium when applied to all stages of product development.

· Applies a cross functional team approach combining information and expertise from marketing, sales, design engineering and manufacturing.

The QFD process leads the participants through a detailed thought process, pictorially documenting their work. The graphic and integrated thinking that results leads to the preservation of technical knowledge; minimizing the knowledge loss from retirements or other organizational changes. This use of QFD helps transfer knowledge to new employees, starting them higher on the learning curve. The use of QFD charts results in a large amount of knowledge captured and accumulated in one place. The charts provide an audit trail of the decisions made by the project team. Once a QFD project has been completed, the resulting charts may be used as a starting point for future versions, (a “re-engineering starting point”) for similar products.

Again, QFD is a method; it is not a panacea, it must be done correctly and it takes up front time and resources to get the best possible results.

Other Specialty Matrices Used in QFD

2011-05-18T08:09:00.000-07:00

7.5 Other Specialty Matrices

As previously stated, there are several approaches to QFD; each of these approaches makes use of matrices to organize and relate pieces of data to each other. There are typically four basic QFD matrices for Product Development. The basic structure of these matrices relates WHAT’s to HOW’s for each of the four product development stages. Since one of the objectives for System Engineering is to understand and determine relationships at all stages, there are other WHAT vs. HOW relationships that are important. Two “Specialty Matrices” that are important in front end system development are: 1) Preplanning Matrix and 2) Functional Architecture of the system (the WHAT’s) versus the structure of the Product Design, (the HOW’s)

7.5.1 Pre-Planning Matrix (PPM) - A Pre-Planning Matrix (PPM) is sometimes used in the product planning phase prior to launching Product Development. The PPM provides an assessment of current company capabilities versus the expected competition. The assessment is taken from where you believe the Customer rates your capabilities and your competition. The assessment identifies current strengths and weakness and shows where investment is needed to create a better competitive position prior to entering into the pursuit and/or development of a product. It also provides a method of identifying potential teaming, strategic partnerships and/or alliances to strengthen product development and improve competitive position. The PPM provides a means for prioritizing investments that might be needed to become competitive and increase the probability of win or sale.

The PPM also identifies potential Sales Points. A Sale Point is where current capabilities or the combined capabilities of a team provide a leading competitive position. The Sales Point is used to communicate with customer(s) and to emphasize why a team or product is superior to its competitors.

The PPM consists of the following sections; 1) Voice of Customer (VOC) requirements, 2) An order of importance of VOC, 3) Competitive Assessment, 4) Identification of probable Sales Points, 5) Improvement Factor of VOC, 6) A new weighted VOC,

Figure 7-18 illustrates a partial sample of a PPM. In reviewing the matrix Section A in Figure 7-18 lists each VOC requirements followed by a column that rates importance level of VOC on a scale of 1 to 5, with 1 rating being least important and a 5 rating being most important. Section B in Figure 7-18 provides an assessment of the competition and your current capability through the eyes of your customer for your company and each competitor, followed by an identification of probable Sales Points.

Figure 7-18 The initial PPM is constructed to show current competitive position and identify Sales Points.

The PPM as constructed so far shows that our present competitive assessment indicates that Company B has a better competitive position. The PPM also indicates that Our Company presently has two Sales Points to emphasize; that our product is Easier to Use and Easier to Hold versus competitor Company A and Company B.

Since the PPM from Figure 7-18 indicates that Company B has a better expected competitive position than Our Company for the defined VOC and Importance Rating, something must be done by Our Company to better the competitive position. Figure 7-19 illustrates a further expansion of the PPM to include additional sections. Section C includes Our Company Plan to increase capability in the “eyes of the Customer”. The column marked Our Target Position the improvements needed to increase the probability of convincing the Customer that Our Company has a better capability and therefore provides a more favorable chance of winning the Customer’s approval. However to achieve that Target Position Our Company needs to improve in two areas of the Customer’s view of our capabilities; 1) Waterproof and 2) Light Weight. Light Weight has an Importance Rating of 5 and it requires an improvement of 9:1 from our current position, Our Company gives this a top priority action, (Priority #1). The final column provides for a summary of Our Company’s Strategy to go forward to capture the customer’s approval. Accomplishing this development and partnering effort should provide Our Company with a strong competitive position over Company B, (i.e. a Relative Importance Rating of 162 versus Company B’s 101 rating).

Figure 7-19 Adding Section C to the PPM provides a prioritized strategy to improved competitive position.

The PPM as presented assumes that Company A and Company B do nothing to improve their competitive position, but in reality that is not likely to be the case. A further extension of the PPM is to forecast where Our Company thinks Company A and Company B might make improvements. For example if Company A and Company B were to establish a Strategic Alliance and combine their capabilities then the best of each company capability would result in a Relative Importance Rating of 125, which is still lower than our anticipated improved rating of 162. This assumes that Our Company is able to implement the identified strategy and investments and convenience the Customer of its improved capabilities.

There are other methods for the development of the PPM instead of the non-linear ratings used in Figure 7-19. For example instead of the non-linear symbols a numerical rating of 1 to 5 can be used to assess Our Company and Company A and B’s capability. However the overall benefit of the PPM is the process of walking through the questions and assessment needed to establish a company’s competitive position and provide priority and direction for further investment in development and/or teaming with another company.

It must be noted that other than identifying and emphasizing current Sales Points, nothing is attributed to the Relative Importance Rating for having these Sales Points over the competition. Some PPM methods assign a value of 1.5 for each Sales Point and multiply the VOC item by 1.5. If that had been done in this example the first Relative Importance Rating for Our Company would be 114.5 versus Company A’s 77 and Company B’s 101. This approach would influence whether Our Company might alter its strategy on investment or teaming. The decision would depend on Our Company’s ability to convince the Customer that these Sales Points provide increased value. It is easy to error based on self-evaluation and could lead Our Company into a false sense of competitive position.

7.5.2 Function vs. Product Design - One of the basic building blocks of QFD is the identification of the functions that a product or service must provide. Every product or service has a basic all-encompassing purpose. The primary or basic function is identified as the prime reason for the product’s or service’s existence. Functional Analysis/Allocation (FA/A) is an early step in the system engineering process, that defines a baseline of functions and sub functions and an allocation of decomposed performance requirements. The FA/A task is to create a functional architecture that provides the foundation for defining the system physical architecture through the allocation of function and sub function to hardware-software and/or operations (i.e. personnel).

It should be clearly understood that the term “functional architecture” only describes the hierarchy of decomposed functions and their allocations of performance requirements to functions within the system. It does not describe either the hardware architecture or the software architecture of the system. It describes “what” the system will do, not how it will do it. Therefore once the functional architecture of the system is defined and a conceptual baseline approach is generated the correlation of functional architecture to physical (hardware & software) architecture needs to be generated to determine:

· Where the function and sub functions are going to be performed in the physical design of the system and

· If all of the functions and sub functions are being performed

· The interfaces and what must cross each interface to perform the intended functions.

Figure 7-20 illustrates an example of a QFD matrix that correlates Functional Architecture with one potential Physical Architecture of the system. This QFD matrix provides a graphical picture of the coupling of Functional Architecture (What is to be accomplished) and Physical Architecture (How and where function is accomplished) along with were interfaces are required. Customers would likely define the primary function or all-encompassing purpose of a camera as “Take a Picture”. The systems engineer decomposes this primary function into the needed functions of Capture an image of a scene, Store the image, Display the image and Readout the image. The example illustrated in Figure 7-20 relates the needed function Capture an Image of a scene and the relationship of this function and its sub functions to a potential hardware concept.

In principle functions and sub functions can be defined totally independent of the technologies used in implementing the functions. However, often a decision is made on one or more of the technologies to be used as the result of market analysis or constructing a PPM. To complete this decision may require Technology Trade Studies to select the best technology approach. Let’s assume a choice between a photographic process using a light sensitive material and a digital technique using a charge coupled sensor where the image is electronically captured and stored on a focal plane of electronic detectors. Assume the decision after making a trade study of the advantages and disadvantages of both technologies is to capture the image electronically using an electronic device known as Charge Coupled Device (CCD). The sub functions that are associated with an electronic method of image capture include:

· Convert image light to electrical signal

· Focus light

· Control light intensity (to match CCD detector sensitivity)

· Condition light

· Block unwanted light

· Position light

· Support & protect components

A simplified baseline concept is to implement an electronic sensing material called a Charge Coupled Device (CCD). The subsystem components that make up the hardware tree for a camera using an electronic sensing approach are:

· CCD focal plane and electronic signal processing

· Entrance focus lens that places the image at the CCD focal plane

· Mechanical housing that proved structural rigidity and blocks outside light from CCD focal plane

· Entrance aperture baffled to block stray light

Ideally a function is performed in only one module or subsystem. This simplifies the interfaces, however this may be impossible to achieve. In reality functions are likely to be accomplished over more than one subsystem and therefore over one or more interfaces. Figure 7-20 provides a summary of a Functional to Physical QFD Matrix for this example and illustrates the following information:

· All but two sub functions are achieved in an individual subsystem

· Two sub functions, Control Light and Block unwanted light are accomplished in more than one subsystem. Therefore any performance requirements associated with controlling light and blocking unwanted light are allocated over more than one subsystem

· The subsystem Entrance focus lens & housing must support more than one function. In this case it supports five different sub functions.

When more than one sub function is accomplished in the same physical subsystem there can be potential interaction or interdependence of sub functions. Also as the number of sub functions increases in any one subsystem complexity also increases. In this example an analysis should be performed to determine if functional performance of the sub functions interacts or is influenced by the other functions in the subsystem. Tradeoff of performance may be necessary to balance out overall performance. These considerations are not readily apparent without construction of the Functional to Physical QFD Matrix.

Figure 7-20 An example functional to physical matrix for the Capture Image function of a digital camera.

It has been documented in Product Development activities that the Functional Architecture for a product or service varies little from one product version to another. The Functional Architecture is not an invariant, but will change only slightly from one product version to the next. The application of different technologies and design changes will cause the hardware/software tree to be different from one product version to the next. The Functional Architecture can be considered as a “re-engineering point” from one product release to the next. Therefore the Functional Architecture can be considered as a pattern of functions to be either reused or to be a starting point for new product/service development.

Constructing the Basic House of Quality

2011-05-10T08:23:00.000-07:00

7.4 Basic Matrix Structure

The QFD process is represented by a series of interconnecting matrices that establish the WHAT, the HOW's and the interrelationship of all parameters involved in the product development process. The QFD method is simply a disciplined way of deploying the voice of the customer (VOC) through each stage of the product cycle. The objective is to keep all efforts focused on the VOC requirements, to optimize cost and to minimize cycle time while being driven by the VOC.

The QT's are used in each product phase to communicate the knowledge developed to the next stage. In each stage translations take place to systematically bring the VOC to actions taken by functional organizations that result in a product/service that satisfies the customer. The purpose of the QT charts is to focus on answering three questions; WHAT, HOW and HOW MUCH. For each product stage and for each action taken in that stage these three questions must be addressed.

The “House of Quality”, sometimes referred to as the “Enhanced House of Quality” consists of multiple “rooms”. Four of the “rooms” are lists that capture the, “What’s, How’s, Why’s and How Much’s” of the project. Four additional “rooms” are formed by determining the correlation and relationships between these lists. Figure 7-4 illustrates the basic structure and location of these “rooms”. The following sections provide detail in forming the lists and relationships between these “rooms” that make up the “House of Quality”. All four phases of the hierarchical matrices follow this basic structure and form.

Figure 7-4 The rooms and relationships of the house of quality.

7.4.1 Voice of the Customer (The “What’s”) - QFD starts with a list of objectives, or the WHATs that we want to accomplish. In the context of developing a new product this is a list of customer requirements and is often called the Voice of the Customer (VOC). The items contained in this list are usually very general, vague and difficult to implement directly; they require further detailed definition. These vague needs are sometimes called “verbatims”, (e.g. easy to use, lasts long time, light weight, low power, easy to modify).

Figure 7-5 The “what’s” defined by the VOC are often general statements.

One such item might be “easy to test”, which has a wide variety of meanings to different people. This is a highly desirable product feature, but is not directly actionable.

7.4.2 Transformation of Action - Once the list of WHAT’s is developed, each requires further definition. The list is refined into the next level of detail by listing one or more HOW's for each WHAT, (i.e. How are we going to satisfy the WHAT’s) as shown in Figure 7-6. This process can be further refined and expanded into a more detailed list of HOW’s.

Figure 7-6 The list of WHAT’s are transformed into a list of HOW’s

The objective of this refinement is to identify each actionable requirement - one that a clear action taken will satisfy a WHAT.

7.4.3 Handling Complex Relationships - The problem that is encountered is depicted in Figure 7-7. Many of the HOWs identified affect more than one WHAT. The approach to charting the `WHATs and `HOWs sequentially would become a maze of lines due to interrelationship that exist between the parameters

Figure 7-7 Many HOW’s affect more than one WHAT

7.4.4 Structuring the Relationships in a Matrix - The complexity of the sequential process is solved by creating a matrix with the HOW list across the top (horizontally) and the WHAT list vertical down the side of the matrix. This determines the RELATIONSHIPS of the WHAT’s and HOW’s in a matrix where each intersect. This is called a Correlation Matrix. Figure 7-8 illustrates by the use of a “X” where the What’s and How’s are interrelated.

Figure 7-8 A correlation matrix determines the relationships between the WHAT’s and HOW’s

7.4.5 Kinds of Relationships - The RELATIONSHIPS are the third key element of any QFD matrix and are depicted by placing symbols at the intersections of the WHATs and HOWs that are related. It is possible to depict the strength of the relationships by using different symbols. Commonly used symbols are shown in Figure 7-9.

Figure 7-9 Symbols used to show the strength of relationships.

This method allows very complex relationships to be depicted graphically and is easily interpreted as shown in Figure 7-10.

Figure 7-10 Strength symbols are placed in the matrix relating each WHAT to its respective HOW’s.

Throughout the QFD process there are repeatedly opportunities to cross check thinking, thus leading to better and more complete designs. This technique of evolving plans into actions is useful for new product development as well as applications in business planning and systems design.

7.4.6 Target Values (How Much) - The fourth key element of any QFD chart is the HOW MUCH section. These are the measurements for the HOWs. These target values should represent what is necessary to satisfy the customer and may not be current performance levels. Easy to test, when translated into detailed requirements may be measured in terms of the number of test points, requirement for component spacing, component edge clearance, etc. The component clearance would be a HOW and the HOW MUCH would be 0.020 inches minimum. HOW MUCH's are needed for two reasons:

1. To provide an objective means of assuring that requirements have been met.

2. To provide targets for further detailed development

Figure 7-11 The HOW MUCH’s are added in rows at the bottom of the matrix.

The HOW MUCH's, added to the matrix as shown in Figure 7-11, provide specific objectives that guide the subsequent design and afford a means of objectively assessing progress, minimizing ``opinion-eering ''. The HOW MUCH's should be measurable as much as possible, because measurable items provide more opportunity for analysis and optimization than do non-measurable items. This aspect provides another cross check on thinking. If most of the HOW MUCH's are not measurable then the definition of the HOW's are not detailed enough. The HOW relationships that relate to the WHAT's become one means to check and measure to see if the WHAT requirements are being met. Viewed another way; meeting the target values will satisfy the HOW requirement. If all of the HOW requirements are satisfied that are related to a VOC item by the relationship matrix then the VOC item is met. Therefore the focus can be now on meeting the target values and not be directly concerned with the VOC, it is taken care of by fulfillment of the HOW MUCH's. These four key elements (WHAT, HOW, RELATIONSHIPS, HOW MUCH) form the foundation of QFD, and can be found on any QFD chart.

7.4.7 Correlation Matrix - The CORRELATION MATRIX is a triangular table often attached to the HOWs, establishing the correlation between each HOW item. The purpose of this roof-like structure is to identify areas where trade-off decisions, conflicts and research and development may be required. As in the RELATIONSHIP MATRIX, symbols are used to describe the strength of the relationships. The CORRELATION MATRIX also describes the type of relationship. The symbols commonly used are shown in Figure 7-12.

Figure 7-12 Symbols used to indicate correlation between pairs of HOW’s.

The correlation matrix identifies which of the HOWs support one another and which are in conflict. Positive correlations are those in which one HOW supports another HOW. These are important because some resource efficiencies are gained by not duplicating efforts to attain same result. If an action adversely affects one HOW, it will have a degrading effect on the other. Negative correlations are those in which one HOW adversely affects the achievement of another how. These conflicts are extremely important; they represent conditions in which trade-offs are suggested. If there are no negative correlations there is probably an error. A well optimized product is almost always the result of some level of trade-off, which is expressed by a negative correlation.

Generally every HOW MUCH item has a desired direction. For example, POWER of 100 watts; generally driving it lower is better. A good test for determining if a relationship is positive or negative is to ask the question: "If power is driven towards its desired direction, are the other HOW's driven toward or away from their desired target values? If the HOW is driven towards its desired target value when power goes towards its desired target value then it is a POSITIVE RELATIONSHIP. If it is driven away from its desired target value then it is a NEGATIVE RELATIONSHIP."

Be cautious not to jump to a trade-off too quickly. The goal is to accomplish all of the HOW’s in order to satisfy customer requirements. The response to a negative correlation should be to seek a way to make the trade-off go away. This may require some degree of innovation or a research and development effort that may lead to a significant competitive advantage.

Figure 7-13 The correlation matrix is constructed on top of the HOW’s.

Frequently, negative correlations indicate conditions in which design and physics are in conflict. When this occurs physics always wins. Such trade-offs must be resolved. Trade-offs that are not identified and resolved often lead to unfulfilled requirements even though everyone has done their best. Some of the trade-offs may require high level decisions because they cross engineering group, department, divisional or company lines. Early resolution of these trade-offs is essential to shorten program timing and avoid nonproductive internal iterations while seeking a nonexistent solution.

Trade-off resolution is accomplished by adjusting the values of HOW MUCH's. These decisions are based on all the information normally available: business and engineering judgment as well as various analysis techniques. If trade-offs are to be made, they should be made in favor of the customer and not what is easiest for the company to perform.

7.4.8 Competitive Assessment - The COMPETITIVE ASSESSMENT is a pair of graphs that depict item for item how competitive products compare with current company products. This is done for the WHAT’s as well as the HOW’s. The COMPETITIVE ASSESSMENT of the WHAT’s is often called a Customer Competitive Assessment, and should utilize customer oriented information. It is extremely important to understand the customer's perception of a product relative to its competition.

The COMPETITIVE ASSESSMENT of the HOW’s is often called a Technical Competitive Assessment, and should utilize the best engineering talent to analyze competitive products. The COMPETITIVE ASSESSMENT can be useful in establishing the value of the objectives (HOW MUCH's) to be achieved. This is done by selecting values which are competitive for each of the most important issues. The COMPETITIVE ASSESSMENT provides yet another way to cross check thinking and uncover gaps in engineering judgment. If the HOW’s are properly evolved from the WHAT’s, the COMPETITIVE ASSESSMENTs should be reasonably consistent.

WHAT and HOW items that are strongly related should also exhibit a relationship in the COMPETITIVE ASSESSMENT. For example, if we believe superior dampening will result in an improved ride, the COMPETITIVE ASSESSMENT would be expected to show that products with superior dampening also have superior ride; as illustrated in Figure 7-14.

If this does not occur, it calls attention to the possibility that something significant may have been overlooked. If not acted upon, we may achieve superior performance to our “in house" tests and standards, but fail to achieve expected results in the hand of our customers.

The IMPORTANCE RATING is useful for prioritizing efforts and making trade-off decisions. Numerical tables or graphs will depict the relative importance of each WHAT or HOW to the desired end result. The WHAT IMPORTANCE RATING is established based on customer assessment. It is expressed as a relative scale (typically 1-5) with the higher numbers indicating greater importance to the customer. The importance ratings are listed in a column between the WHAT’s and the matrix. It is important that these values truly represent the customer, rather than internal company beliefs. Since we can only act from the HOW’s, importance ratings for these HOW’s are needed.

Figure 7-14 Competitive assessment of the WHAT’s are put in a box on the right side of the matrix.

7.4.9 Importance Ratings - Weights are assigned to the RELATIONSHIP symbols, e.g. the 9-3-1 weighting shown in Figure 7-15 achieves a good variance between important and less important items. Other weighting system may be used. For each column (or HOW), the WHAT importance value is multiplied by the symbol weight, producing a value for each RELATIONSHIP. Summing these values vertically defines the HOW importance value. In Figure 7-16 the HOW importance rating for the first column is calculated in the following manner. The double circle symbol weight (9) is multiplied by the WHAT importance value (5), forming a RELATIONSHIP value of 45. The next double circle symbol weight (9) is multiplied by the WHAT importance value (2), forming a RELATIONSHIP value of 18. These two values (45 + 18) form the HOW importance value of 63. This process is repeated for each column as shown in Figure 7-16.

Figure 7-15 Importance ratings are obtained by assigning weights to the symbols in the relationship matrix

Figure 7-16 Importance ratings are calculated for each HOW as the sum of the weighted importance of each WHAT.

The IMPORTANCE RATING for the HOW’s provides a relative importance of each HOW in achieving the collective WHAT’s. We see that for the HOW’s listed; “Maximum Power” with a Target Value of 200 watts has the “HIGHEST” Relative Importance. Greater emphasis should be placed on the HOW with the 83 rating than the other HOW’s. It is important that we are not blindly driven by these numbers. The numbers are intended to help us, not constrain us. Look upon the numbers as further opportunities to cross check thinking. Question the relative values of the numbers in light of judgment. Is it reasonable that the HOW valued at 83 is the most important? Is it reasonable that the HOW’s with similar ratings are nearly equal in importance?

7.4.10 The Basic Matrix Structure - The previous section can now be integrated together into one chart. Figure 7-17 illustrates the Basic Matrix Structure. All of the matrices used in the product development stages could have these basic sections. Note the correlation matrix when added to the relationship matrix takes on the shape of a house with a roof. It is from this construction that the QFD matrices are termed the ̏houses of Quality''.

Figure 7-17 The basic form of the House of Quality relates the VOC and competitive assessment information to design requirements.

A Basic Approach to QFD

2011-05-03T11:55:00.000-07:00

7.2 The QFD Approach

There are several approaches to QFD; each of these approaches makes use of matrices to organize and relate pieces of data to each other. Many times these matrices are combined to form a basic QFD tool called a “House of Quality”.

The basic approach used here is conceptually similar to the practice followed by most American manufacturing companies. In QFD we typically follow the flow as defined in Figure 7-2. We start with customer requirements, which may be loosely stated qualitative items such as: looks good, easy to use, works well, feels good, safe, comfortable, lasts long, luxurious or specifically defined requirements. These are important to the customer, but do not represent a product definition. In order to implement a product system engineers need to convert these vague customer requirements into actionable internal company requirements, which we call design requirements. These are generally global product characteristics such that if properly executed the product will satisfy the customer requirements.

Figure 7-2 The typical flow of applying QFD has five steps

Products are not usually developed at this global level, but rather at the system, sub-system or part level. The global design requirements must then be translated into specific product design, company infrastructure and capital investment requirements. Every product has several critical characteristics that determine how good a product fulfills its intended functions. The QFD process allows one to track these critical characteristics throughout the development process. Next determine the required manufacturing operations. This stage is often constrained by previous capital investment. Development organizations usually do not want to build a new factory or install a new line of equipment to produce a new product version and this often constrains product design and production methods.

Within the defined operating constraints determine which manufacturing operations are most critical to creating the desired critical product and part characteristics, as well as the process parameters of those operations which are most influential. Think of these process parameters as the knobs or dials of the manufacturing operation that are controllable. The manufacturing operations are then deployed into production requirements, which are the entire set of procedures and practices that enable the production system to build products that ultimately satisfy customer requirements.

These operating procedures determine how the factory operates the manufacturing processes to consistently produce the required critical product/part characteristics. They include a number of ̏soft" issues such as inspection and Statistical Process Control (SPC) plans, preventive maintenance programs, operator instructions and training, as well as identifying the need for mistake proofing devices for preventing inadvertent operator errors

The hierarchical approach described above is not unlike the approach taken for years with varying degrees of success. The problem is that some of the translations are not made properly. There are several key reasons for these improper translations that are the result of the structure of large organizations and the complexity of the product development process.

7.3 Hierarchical Matrices and QFD Phases

There are several approaches to the implementation of QFD. The QFD method presented here follows the approach taught by the American Supplier Institute (ASI) based upon the “House of Quality” structure. The basic matrix structure consists of various types of matrix and table sections (or “rooms”) linked together to form what has been termed the “House of Quality”. The ASI approach implements a four phase approach with matrices representing the important characteristics for each phase. Figure 7-3 illustrates the four phases and how the key characteristics of each phase are deployed to the next phase of development.

Figure 7-3 The four phases of QFD consist of four linked matrices called Quality Tables.

The four phase approach results in a hierarchical series of matrices where each individual matrix is called a quality table and are numbered, e.g. QT-1 thru QT-4. In the four phase approach a team determines the relationships between customer requirements and product design requirements. The product design requirements are then deployed to the QT-2 matrix. In QT-2, the team determines the relationships between design requirements and product design. The product design is then deployed to the QT-3 matrix to determine the relationships between product design and process design. The process design is then deployed to QT-4 matrix to determine the relationship between process design and manufacturing operations.

The four phase hierarchical series of matrices when completed links the customer requirements all the way to the manufacturing operations. Thus as the manufacturing operations meet their deployed requirements then indirectly the customer requirements are being satisfied. Therefore the resulting product or system is Customer Driven.

Introduction to Quality Function Deployment

2011-04-26T13:49:00.000-07:00

Chapter 7 is the work of David Melton. David is an outstanding mechanical/thermal engineer, a highly experienced system engineer and executive manager. He has extensive training in Quality Function Deployment and years of experience putting it into practice. This chapter can be used as a stand alone guide for those desiring to use QFD as their primary systems engineering process or to augment more traditional systems engineering.

7 Quality Function Deployment (QFD) In System Engineering

7.0 Introduction

System development is a complex process. Bringing a product or system from concept through production, deployment (distribution) is generally called the Product Development Process. Consideration of product development as a process requires looking at a network of tasks that are necessary to bring the product to market and provide a product or system that fulfills the “Voice of the Customer “(VOC). The VOC represents a definition of the needs and wants of the customer. Regardless of how it is presented the product development process is exceedingly complex. It consists of numerous offs, shared responsibilities and interpretation of differences often resulting in conflicting priorities. A substantial body of technical knowledge must be employed (and deployed) often over a relatively long time frame, while experiencing constant resource changes. The product development process requires a great deal of communication and a substantial work effort from many different functional groups. Product development can no longer be viewed as simply a Design Engineering Function. Design Engineering is but one process of several interrelated processes and functions involved in developing a quality product. Ultimately the communication of information gets back to the customer in the form of a product/service. To minimize the risk and accomplish this effort successfully requires an effective communication and tracking tool and methodology. The implantation of the QFD method can achieve this objective.

A system, however complex, must be carefully planned out to minimize subsequent redesign. The full effect of inadequate planning (or understanding of relationships) is rarely detected until late in the development cycle or not until hardware is fabricated or code written. The later any design change or design defects are detected the more time and money a redesign effort incurs. System Engineering is primarily about understanding relationships and interdependencies during system development. The System Engineering objective is to translate customer requirements to product(s) and service(s) that fulfill the customer’s needs. Systems Engineering has emerged as a distinct professional discipline in direct response to the increasing complexity of new development projects for all market applications.

Quality Function Deployment (QFD) is a systematic process for translating customer requirements into appropriate company requirements at each stage from research and product development to engineering and manufacturing to market/sales and distribution. The output of the QFD process is a series of matrices that define critical parameters and requirements throughout the product life cycle. A Product Life Cycle (PLC) is a sequence of stages that a product goes through from conception through design, production, distribution and final phase out, (commonly called cradle to grave)

The prime assumption underpinning system engineering is that a product should be designed to fulfill the customer’s actual needs. Self-evident as this approach may seem, it is surprisingly common for companies to develop products with little or no customer input or confirmation of perceived customer needs. Even when a large market exists, a product can fail when the customer's real needs are poorly understood or improperly deployed to the subsequent design process. The QFD process applied to hardware development is very similar and complementary to the recommended System Engineering (SE) process. Much of the information generated by the QFD process is information needed to complete the System and Component specifications. One added benefit that QFD brings to the SE process is a method for prioritization of requirements. OFD also provides a method for identifying the critical design requirements (i.e. Cardinal requirements). QFD provides a pictorial illustration of the System and Component Specifications and shows where requirements are allocated to the subsystems.

The QFD process is complementary and beneficial to decision making in the system development stage. QFD is a structured process to identify these relationships and determine which are most important in driving requirements and system development. QFD generates the skeleton structure (architecture) for the system and subsystem specifications. When QFD is integrated into the system development process, it provides value-added information and knowledge to aid decision making while optimizing the product design

This section:

· Defines QFD and how it can be integrated into the SE and System Development process to provide complementary benefits and aid decision making in defining and specifying a system.

· Explains the benefits and features of using QFD in the System Development process.

· Presents a simple structured system engineering approach to product development using QFD prior to detailed product design.

· Focuses on the hardware development, but in general the concepts can be applied to software development to capture customer needs and requirements and flow requirements through algorithm development

Standard system engineering techniques have been defined in the United States (US) Department of Defense (DoD) and NASA for decades; and these techniques are also applied to large commercial products, e.g. in automotive and aircraft industries. The health care sector has introduced QFD as a means to develop systems for health care. The QFD initiative in the US for hardware developed items follows a structured and disciplined process very analogous to the SE process defined by DoD. DoD SE methodology standardizes the flow-down and traceability of specifications for complex products from customer requirements through production, operation, and disposal. SE integrates all of the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation.

The principles of system engineering using QFD span the entire life cycle of a product, but this chapter is concerned with the early feasibility and concept stages. Studies show that a large percent of the product's manufacturing cost is frozen at concept selection time. Many companies in all industries historically initiate product cost reduction efforts after the product is released to the production floor. If say, 85% of the manufacturing cost is frozen at concept development time, then post production release cost reduction is saving cost on 15% of manufacturing effort. The value-added return for the investment is likely to be low. Therefore, to make significant cost reductions, development effort must focus on the early concept selection stage where alternative concepts and technology are considered.

7.1 Background

The word quality in QFD has led to much misunderstanding. QFD was first introduced in most organizations through the Quality Assurance departments. In the QFD process several functional organizations other than the quality department are vital participants. Because the name can be misleading, QFD has been given a bad connotation. QFD is not a quality tool to audit functional organizations, rather it is a structured planning tool to guide and direct the product development process. Let us therefore not be resistant to the use of QFD because of the name, but rather seek to understand what QFD embodies.

Quality Function Deployment (QFD) is a translation of six Japanese Kanji characters:

HIN SHITSU KI NO TEN KAI

As with any translation there is room for other interpretations. Each pair of the Kanji characters has alternate translations; Figure 7-1 illustrates these different translations. The most accepted interpretation is Quality Function Deployment (QFD).

Figure 7-1 The Kanji characters for QFD have several alternate translations.

QFD has a broad meaning. It involves taking the features of a product driven by the customer's needs and evolving the product functions into an overall product. We may think of QFD as the act of taking the voice of the customer (VOC) or user all the way through the product development process to the factory floor and out into the market place. QFD is therefore more than a quality tool, but an important planning tool for introducing new products and upgrading existing products.

7.1.1 Features of QFD - As previously stated, QFD:

· Is a systematic means of ensuring that the demands of the customer and the market place are accurately translated into products and/or services.

· Is a structured approach that provides both a planning tool and a process methodology.

· Identifies the most important product characteristics, the necessary control issues and the best tools and techniques to use.

· Applies to all stages of product development and provides a comprehensive tracking tool and communication medium.

· Applies a cross functional team approach combining information and expertise from marketing, sales, design engineering and manufacturing.

· Provides a systematic and disciplined method of creating priorities, making improvements, and defining goals and objectives applicable to the company's products and/or services.

QFD is a method; it is not a panacea, it must be done correctly and it takes up front time and resources to get the best possible results.

7.1.2 Benefits of QFD - QFD is a relatively simple but highly detailed process. Upon initial evaluation it may appear to be too detailed - perhaps not worth the effort. However QFD has proven benefits, including:

· A PROPRIETARY KNOWLEDGE BASE;

The QFD process leads the participants through a detailed thought process, pictorially documenting their approach. The graphic and integrated thinking that results, leads to the preservation of technical knowledge, minimizing the knowledge loss from retirements or other organizational changes. This use of QFD helps transfer knowledge to new employees, starting them higher on the learning curve. The use of QFD charts results in a large amount of knowledge captured and accumulated in one place. The charts provide an audit trail of the decisions made by the project team. Once a QFD project has been completed, the resulting charts may be used as a starting point for future versions, (a “re-engineering starting point”) for similar products. The bottom line of QFD is higher quality, lower cost, and shorter development time resulting in a substantial competitive advantage.

2. SATISFIED CUSTOMERS; QFD forces increased understanding of customer requirements because it is driven by the voice of the customer, rather than the voice of the engineer or executive. By focusing on the customer, numerous engineering decisions are guided to favor the customer. Whereas numerous trade-offs are always necessary for any well optimized product, these trade-offs are made for customer satisfaction not for engineering convenience.

3. FEWER START-UP PROBLEMS: The preventive approach fostered by QFD results in fewer downstream problems, especially at production startup.

4. LOWER START-UP COST; This translates directly into reduced start-up costs

5. LESS TIME IN DEVELOPMENT: This approach not only saves money, it also saves overall development time. Product introduction cycle time has been shown to be a third to a half shorter by using QFD to thoroughly plan the product or service.

6. FEWER FIELD PROBLEMS; The cost savings has been demonstrated to continue well beyond startup, and is reflected in reduced problems for customers and consequent warranty cost reduction.

7. FEWER AND EARLIER CHANGES; A major advantage of QFD is that it promotes preventive rather than reactive development of products. QFD is a preventive approach that has demonstrated fewer downstream production problems; especially at production start-up; commonly referred to as “the transition from development to production”.

Checking the Partitioning of the Physical Architecture

2011-04-19T13:58:00.000-07:00

6.6.4 The Design Loop

As the physical design is created many alternatives should be considered. One task is to check that the grouping and sequencing of functions defined during the functional analysis task leads to an effective physical partitioning, i.e. a modular design as described in the previous section. If reasonable physical designs don’t result in subsystems being allocated to single functions or single groups of functions then recheck the grouping of functions to see if alternative grouping lead to cleaner physical partitioning and more modularity. It is important to seek clean partitioning of subsystems and their associated functions because the cleaner the partitioning the easier systems are to integrate and test, maintain and upgrade. A function that is implemented in two or more subsystems results in system designs that are more difficult to maintain and upgrade and are often more difficult to test. Envision the design loop as iteration between functional and physical design until both result in a modular physical architecture.

A second task during design synthesis is conducting trade studies, described in a later chapter, to select between design alternatives. Again when evaluating alternative architectures consider the partitioning for each design alternative and examine the possibility that modifying the functional architecture might lead to a better functional to physical allocation and partitioning.

6.6.4.1 Functional to Physical Allocation Matrices

A simple tool that is helpful in refining the functional and physical architectures is a functional to physical allocation matrix. An example matrix for the toaster functional architecture shown in Figure 6-24 and the design concept architecture shown in Figure 6-31 is shown in Figure 6-33. The functional to physical allocation matrix is particularly helpful in examining the partitioning of a design concept for modularity. Typically the more diagonal this matrix the better the modularity. However, opportunities for one physical entity to perform two or more functions are highly desirable and readily apparent in the matrix. Similarly, when the matrix shows a function spread across several physical entities the matrix provides a visual means of examining if the physical design concept is sound or if it should be changed to allow cleaner partitioning. Sometimes the nature of a function causes it to be spread across several physical entities without complicating the design in ways that cause manufacturing, testing or upgrade problems. For example, in Figure 6-32 the “apply heat” function is allocated to three entities and this is probably a reasonable design approach because it likely reduces the parts count and makes operation simpler.

Figure 6-33 A functional to physical allocation matrix for one candidate toaster design concept.