The Book is Now Available

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 Integrating Modern Methods for Faster Systems Engineering

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.

Functional Flow Block Diagrams

6.5.1.1 Functional Flow Block Diagrams - Graphical models are used to define and depict the sequence of functions making up a higher level function necessary to fulfill requirements. Functional Flow Block Diagrams (FFBD) can be process-oriented models that represent functions as nodes and objects as the connecting links. Nodes are typically labeled but links are typically unlabeled in process-oriented FFBDs. Figure 6-21 is a FFBD for two of the functions of a digital camera. Here only one external interface is identified, i.e. the interface with light from the scene.

Figure 6-21 A FFBD developed as a process-oriented model has named and numbered functions as nodes and objects as links.

Part of the task of functional design is to decompose high level functions into the lower level functions necessary to carry out the action implied by the high level function. For example, the function “image scene” can be decomposed as shown in the FFBD of Figure 6-22. In this example the objects linking the four lower level functions are also labeled. Note that nodes are numbered as well as named with the numbers indicating the level of the functions in the overall hierarchy of functions. The numbers are selected to provide traceability; e.g. sub functions decomposed from a function 1.1 with n sub functions are numbered 1.1.1 to 1.1.n.

Figure 6-22 The function Image Scene 1.1 from Figure 6-18 can be decomposed into four lower level functions.

Notice that functions 1.1.2 and 1.1.3 in Figure 6-22 could be interchanged in the sequence and still be a logical sequence. This is a simple example of having more than one logical sequence of lower level functions. The “best” sequence is determined by conducting design trade studies when these functions are allocated to physical elements. Note also that the functions 1.1.1 and 1.1.2 are easily grouped whereas 1.1.1 and 1.1.3 or 1.1.2 and 1.1.3 are not easily grouped. Therefore the sequence shown is likely to be the preferred sequence, at least until design trade studies are complete.

An alternative to the process-oriented model of a FFBD is an object-oriented model with the nodes and links reversed. An example of an object oriented model is shown in Figure 6-23.

  Figure 6-23 An example of a FFBD as an object-oriented model of two of the functions of a digital camera with named functions as links and named objects as nodes.

The decision to develop process-oriented or object-oriented models depends upon the experience of the systems engineer and the details of the system being designed. A comparison of the two approaches resulting from an analysis of both approaches is shown in the table.

Table 6-1 Selecting an Object-Oriented or Process-Oriented model depends on the details of the specific system design. From the paper Cognitive Fit Applied to Systems Engineering Models by Larry Doyle and Michael Pennotti, Conference on Systems Engineering Research, 2004. 

As with context or domain diagrams it is helpful to have pattern diagrams for all levels of FFBDs representing the class of systems that includes the system being designed. This saves considerable time compared to having to generate the FFBDs for all the levels of a new system under development. The objective is that the pattern diagrams contain all possible functions, sub functions and external and internal interfaces of the entire class of systems. Then the task becomes examining each top level function and interface to determine if it belongs to the new system. If a functions does not belong it is deleted along with all sub functions decomposed from the unneeded top level function. After deleting all unnecessary functions and interfaces from the top level and the sub functions and interfaces traceable to the deleted top level functions and interfaces it is necessary to examine the sub functions in each level to ensure that only necessary ones are kept. The system being designed may include a top level function from the pattern but may not include the entire set of sub functions decomposed from the top level function.   It is also necessary to examine the partitioning and grouping of functions as the best choice is likely to be system design specific and not necessarily that captured in the pattern diagrams.

Introduction to Pattern Based Systems Engineering

“Each Problem that I solved became a rule which served afterwards to solve other problems” - René Descartes

Reusable Systems Engineering Products – Descartes’ experience is not unique. Experienced engineers typically examine new problems to see if solutions they have used for past problems can be applied or adapted to the new problem. When past solutions can be used for new problems it both shortens the time it takes to reach a solution and increases the confidence the engineer has in the solution. Confidence is increased because the past solution has been found sound or discarded. Often the quality of a solution based on a past solution is superior to a totally new solution because the past solution has been refined with testing and use. Pattern Based Systems Engineering (PBSE) is a methodology of developing and exploiting past solutions for new systems engineering tasks in a standard way that allows systems engineers to reuse and share past solutions. This has an additional advantage; inexperienced engineers benefit from the work of more experienced peers and are able to work at the quality levels of more experienced engineers.

Most systems engineering work involves design elements that belong to families of design elements that design teams have experience with from executing previous development programs. The objective of Pattern Based System Engineering (PBSE) is to exploit this experience to minimize system engineering effort and design errors by reusing past systems engineering work much like hardware and software designs are reused. In fact, hardware and software are not reusable unless the systems engineering, particularly the requirements and decision rational behind the designs, is reusable.

Think about how experienced engineers work. When starting a new task the first thing they do is look for similarities to tasks they have previously performed. Then they refer to reports and design documentation from their previous work to guide the new work. For example, if a diagram exists from a design element of the same family as the current design element it is much faster, and results in fewer errors, to edit the diagram from the previous effort than to construct a new diagram.

Now consider if the example diagram to be edited represented not just a specific member of the family but the entire family. This means that it contains all the possible parameters relating to the family. This complete diagram is called a pattern diagram. The editing job for a pattern diagram consists of deleting those portions of the pattern diagram that don’t apply to the current design element. This can be done quickly and there is little chance of not considering any parameter since all are contained in the pattern diagram. The only possible mistakes are deleting items that shouldn’t be deleted or leaving items that should be deleted; assuming that all possible items are indeed in the pattern diagram.

Note how easy it is to peer review the resulting diagram. The peer reviewers compare the pattern and edited diagrams to see if they agree with each deletion and each item not deleted. Thus having a pattern diagram dramatically shortens the time to develop a diagram for a new design effort and it reduces the chances of errors in the resulting new diagram. Experience shows that all top level diagrams can be developed from patterns in a few hours for a moderately complex system instead of the several weeks it takes to develop these diagrams starting from scratch.

Thus PBSE is largely a model based approach that produces the desired models in a fraction of the time it takes to develop models from scratch or edit similar models from previous work and it achieves higher quality models. Think of Patterns as reusable models. However, PBSE is not entirely model based; prose documents are a part of PBSE, particularly requirements and data dictionaries containing definitions of functions. Reusability is facilitated with prose documents by structuring them as templates organized to maximize the connectivity to other documents and models and thereby minimize the editing necessary for new system documents.

Readers familiar with the Yourdan systems method may see similarities to PBSE and be concerned that PBSE is subject to some of the problems of the early version of the Yourdan methods. PBSE is fundamentally different in that the patterns aren’t based on a physical model and are not inherently subject to having unnecessary items in a design.

It is important to note that the title to this chapter is “Introduction to Pattern Based Systems Engineering”. The objective is to introduce PBSE in a way that inspires readers to both try it and to do further reading. This book does not present systems science; rather it presents pragmatic systems engineering methods and tools the authors have found useful in their work. It isn’t that we don’t believe systems science is worthwhile, it’s that we are working systems engineers and managers of systems engineering work and don’t claim expertise in systems science. It also means that we are not trying to present a comprehensive introduction to or history of all systems engineering methods; rather we present what has proven to be effective in our work. We reference work of systems scientists and highly recommend that readers of this book dig further into methods by studying the works of well-known systems scientists.

After reading this chapter readers interested in adopting PBSE methods should study papers by William Schindel of ICTT Systems Sciences. Start with “Pattern-Based Systems Engineering: An Extension of Model-Based SE” available on the web. Especially recommended is “Requirements Statements Are Transfer Functions: An Insight from Model-Based Systems Engineering”, by W.D. Schindel, ICTT, Inc., and System Sciences, LLC. Presented at the 15th Annual International Symposium, INCOSE 2005, 10-14 July 2005. The implementation of PBSE presented here differs in details from Schindel’s because of what we have found that works well for us and our organizations. Schindel’s version of PBSE may work better than the version presented here for other organizations so we recommend readers study both. Experienced systems engineers may develop implementations that differ from both that presented here and in Schindel’s work that may work better for their organizations and their work.

Note particularly Schindel’s use of logical subsystem architectures for allocating requirements. Logical subsystems are analogous to the logical interfaces used to characterize inputs and outputs for systems before the physical architecture is defined. Some find this a preferable approach over traditional functional analysis and some experienced with traditional methods prefer just doing functional analysis. For example, consider constraint requirements like mass and volume. It can be confusing for inexperienced systems engineers to allocate such constraint requirements to functions since functions have no mass or volume. However, allocating mass or volume to a logical subsystem seems intuitively more appropriate.

In this work we choose to present traditional requirements allocation to functions. This approach requires less change for systems engineering organizations and in the authors’ experience does not detract from the intrinsic value of developing and using patterns.