Now that we have taken what is hopefully is a fresh look at what systems engineers do let’s back up and look at some traditional definitions of a system and systems engineering. I have used these definitions for so long that I have forgotten their original sources and I apologize. There are almost as many definitions of a system and of systems engineering as there are systems engineers so I prefer not to put much emphasis on these definitions but include them for completeness and to make a critical point about defining things with text based definitions.
One source says a system is a collection of objects working together to produce something greater. A system can be tangible, like a rocket or a communications network, or intangible like a computer software program or any combination of tangible and intangible. A system is composed of unique elements and the relationships between these elements. The elements in a system can be highly hierarchical or essentially flat like a network, or again any combination of hierarchical and flat. A system has the further property that it can be unbounded; each system is invariably a part of a still larger system. This characteristic of a system leads to a complication in definitions. Some systems engineers use names like “system of systems” to account for certain types of systems; often those involving complex interactions with humans. From a semantics point of view a term like “system of systems” makes no sense as it’s equivalent to saying a “universe of universes”; but if such terms communicate something important to those working on the development of certain types of systems then the terms serve a useful purpose. Also we have to remember that sometimes customers invent new terms and we have to use them even if we don’t agree. It usually isn’t worth trying to be “virtuous and pure” over such issues.
One pragmatic way to define a system is that it is the design element at the top of the hierarchy being developed by a systems engineer’s team. Thus it’s the collective name of that design element. The system being developed may be part of a larger system but the development team only has to be concerned with the requirements for their system and the interfaces of their system with the larger system, not with what to call the larger system.
Eberhardt Rechtin, in his book “Systems Architecting: Creating & Building Complex Systems”, says the essence of systems engineering is structuring. Structuring means bringing form to function or converting the partially formed ideas of a customer into a workable model. The key techniques are balancing the needs, fitting the interfaces and compromising among the extremes.
Others describe systems engineering as both a technical and management process. One source says “it is a discipline that ties together all aspects of a program to assure that individual parts, assemblies, subsystems, support equipment, and associated operational equipment will effectively function as intended in the operational environment”. One of my favorite definitions is from a U.S. Navy web site. It says systems engineering “is a logical sequence of highly interactive and iterative activities and decisions transforming operational needs into a description of system performance parameters as well as a preferred system configuration.” This definition is amusing because it is exactly correct in saying systems engineering is highly interactive and iterative but the reality is that it is logical only to a highly experienced system engineer. Something that is highly interactive and iterative hardly appears logical to someone not intimately familiar with it.
Comparing these definitions with the four tasks for systems engineers defined in Figure 3-3 of the previous post shows that the definitions do not capture all that is implied in the four tasks. From the definitions would a young engineer realize that a system engineer has a role in planning and scheduling a development program; or in verifying the performance of a system design? If this chapter started with the standard definitions of a system and systems engineering would a logical path to the four systems engineering tasks have been easily found? If just the five text words had been used to define the product development cycle instead of the labeled graphical model would it have raised the question of whether the four tasks are rigidly sequential or allowed to overlap in time? Perhaps, but not as easily as it is starting with the graphical model of product development as the five simple sequential tasks or phases of define, design, build, test and produce.
Graphical Models vs. Textual Models
There is a profound principle in the last paragraph above. Textual descriptions of complex ideas are often incomplete and very often lead to different readers having different understandings of the ideas. Labeled graphical models of complex ideas are less ambiguous. This is a critical point for systems engineers to remember and use in their work. Look back at the second figure in the previous post. The thin solid arrows indicate that the outputs of a task are the inputs to the next task. In the development of complex systems each task typically involves different teams. Therefore it is critical that the outputs of one task be easily understood and unambiguous to the teams working on the following tasks. Labeled graphical models are much easier to understand and less ambiguous than textual descriptions for most engineers.
Think back to the “Craftsman” model of product development defined earlier that was successfully used for centuries for simple products. The output documentation from the chief engineer and his/her team was engineering drawings. The workers and managers in the factories responsible for producing the products could clearly understand and use these engineering drawings. Imagine if the chief engineer and his team submitted textual descriptions of their product design to the factories.
Another example of a labeled graphical model being superior to textual descriptions is maps. Imagine going on a driving vacation through your country using just a textual description of the location of towns and the roads connecting them. Just keeping track of where you are with respect to the textual descriptions would become a time consuming task. This is why maps became the standard model for describing geography centuries ago.
One of the reasons development of complex systems often failed to achieve the planned schedule and budget after systems engineering was introduced in the 1950s and 1960s to address the complexity of modern systems was that some of the documentation produced by systems engineers and passed to design engineers was textual descriptions rather than labeled graphical models. Unfortunately this practice continued when concurrent engineering was introduced and continues today for many organizations. One of the primary objectives of this book is to convince systems engineers to use labeled graphical models wherever possible and avoid textual models wherever a graphical model can be used instead. This is one of the keys to achieving faster and lower cost systems engineering, as will be explained in a later article.
System Engineering and Design Engineering
Accompanying the introduction of systems engineering was the practice of distinguishing between systems engineers and design engineers. It was natural to label the engineers doing the systems engineering work as system engineers. Since functional engineering organizations were typically broken down into mechanical departments, electrical departments or some similar differentiation it was natural to set up systems engineering departments for the systems engineers. This is unfortunate because all engineers do some systems engineering work and all engineers do some design engineering work. It is true that systems engineering has become a specialty just like other specialties of design engineering and that systems engineers use some processes that are fundamentally different than design engineers. We must keep the various specialties but perhaps we could change the term design engineer. This might help remove some of the undesirable barriers that creep into our organizations that inhibit effective communications. However, using the term design engineer helps define the different rolls of system engineers and the various specialties. Let’s use the diagram from Figure 3-4 to help define the traditional roles and responsibilities of systems engineers and design engineers. The result is shown in Figure 3-5.
Figure 3-5 The traditional roles of system engineers and design engineers involve responsibilities within each development phase.
From Figure 3-5 and the description of what takes place during each task or phase we can further define the traditional differentiation between systems engineers and design engineers in simple terms as follows:
· Systems Engineers Determine
o What’s to be built
o How it’s supposed to function
o Whether it meets its requirements
· Design Engineers
o Determine how it’s to be built
o Make it operate (integration & test)
It is critical to understand that both systems engineers and design engineers are involved in all five phases as shown in Figure 3-5. To further define the role of systems engineers it helps to look at how they are integrated into a typical organization. That is the subject of the next article.
No comments:
Post a Comment