Idea Based

They Were Right: KISS, Simplify, and Reduce Complexity

Many experienced systems engineers have argued that we need to systematically “Keep It Simple” and reduce the complexity of our systems. One of them was the master systems engineer, Eberhardt Rechtin [1]. I certainly agree. But we need to figure out how to do that. Here are a few suggestions as to what to consider in tackling this matter:

a. Develop measures of complexity that make sense

b. Use these measures to determine what is too complex, and what is not

c. Do the above as early as possible in the system’s life cycle

d. Actually reduce the complexity of the system(s) under consideration (implementation)

e. Take note of what it is that increases complexity, i.e., [2]

  • • Size
  • • Functionality (how many and type)
  • • Number of modes of operations
  • • Duty cycle (static vs. dynamic)
  • • Real-time operations
  • • Parallel vs. serial operation
  • • Very high performance
  • • Number and type of interfaces
  • • Degree of integration
  • • Human-machine interaction
  • • Non-linear behavior

It would seem that reducing complexity is not a primary concern of the system designers. Perhaps that is true. But it needs to be much further up on the list of things to worry about, and actually do something about.

If a reduction in complexity is achieved, then there is a lot more room for increasing reliability by using redundancy more effectively. Here is a real-world case that hopefully will illustrate the point.

I was working on a weather satellite known as Nimbus. Goddard Space Flight Center was the developer and designed a three-axis stabilized system with solar panels that were rotated so that they faced the sun most of the time. This, of course, provided a critical function (i.e., power supply) for the overall system.

As it turned out, the motor drive to carry out this rotation failed, and soon the overall system failed. This single point of failure mode was not rare; we had heard about this kind of problem before. It is one that persists today - for example, with certain manned missions and loss of life. That’s about as serious as it can be. And in terms of redundancy, it would have been possible to switch in a parallel (redundant) motor drive when the first one failed. Reduced complexity could have meant that we could have increased redundancy.

I can remember a post-mission failure review in which I explored the situation on Nimbus with the program manager at Goddard. We both agreed that this potential problem could have been avoided by using redundancy. But the point that he made went something like this - “You suggested a different design for several single-point failure situations. How do I choose, as program manager, which ones to consider seriously? After all, I’ve got dollar and time constraints that I need to worry about - every day”.

Of course I acknowledged that point and went back to my desk wondering how to answer his question. I never did, and the world continued to turn. Now I bring the point back to life in this treatise. Yes, the question is: We agree to reduce complexity and make room for redundancy, but how do we do that?

In one respect, it’s rather easy. There are measures of complexity out there, and we can examine them critically. For example, in the software arena, there’s the software complexity measure set forth by a leader in this field [3,4], Tom McCabe. In this case, cyclomatic complexity (CC) is given by:

CC=E-N+2

where E is the number of edges of the code and N is the number of nodes in the code.

More conventional approaches can be found with respect to software at the McCabe website and also in a variety of books on system reliability, and parts of books that deal with that subject [4].

References and Recommended Reading

  • 1. Rechtin, E., “Systems Architecting”, Prentice-Hall, 1991.
  • 2. Eisner, H., “ Managing Complex Systems - Thinking Outside the Box”, John Wiley, 2005.
  • 3. McCabe, T, “A Complexity Measure”, IEEE Transactions on Software Engineering. 2(4), 308-320. 1976.
  • 4. Eisner, H., “Essentials of Project and Systems Engineering Management”, Second Edition. John Wiley, 2008.

Seek a Balanced System Solution; Do Not Try to Optimize or Achieve Perfection (*)

One of the (serious) mistakes made by systems engineers is to try to optimize and achieve perfection. That approach is almost always wrong-headed. It leads to overruns in time and cost, with no provable optimum performance. The saying is - perfection is the enemy of the good, and it is correct. In systems engineering, one is aware of this problem and issue and tries to find another way.

What is that way? It involves reaching consensus on the part of the team and also some form of agreement from the sponsor and often the system “stakeholders”. They are part of the “system”, although it might not be obvious that such is the case.

Where is there room for consideration of “balance”?

Within the process of architecting, as represented in this treatise, is an analysis or evaluation step after several alternatives have been defined. This step involves “weighting and rating”, in which the weights represent how to look at the various evaluations. The same logic can be used to try to achieve balance in both the “analysis of alternatives” procedure and the “cost-effectiveness” analysis. We definitely want to use these weights to factor into the analysis and be a vehicle for achieving balance in our design as in our final system.

Another way to look for balance is by means of the architecting team as it represents different approaches and solutions. In this scenario, the skill of the project manager is called upon to hear everyone on the team and to know what their perspectives are in a variety of design decisions. In the ideal case, a better, more highly balanced system solution will evolve and be confirmed.

On the matter of different views leading to different weights, we present here a set of data for an aviation project in which this author participated [1]. These data are the weights given to a set of evaluation factors by the commissioners heading up the Aviation Advisory Commission (AAC) some years ago (see Table 20.1). The various and disparate points of view expressed by the commissioners were important aspects of their discussions and final report. That was my point of view (not necessarily shared by all the commissioners). However, this author was pleased to assist in the overall project at that time. To be more specific regarding the Commission, the criteria used by the commissioners were:

  • 1. Social effects
  • 2. Environmental effects
  • 3. Service quality
  • 4. System capacity
  • 5. Human factors
  • 6. International economic effects
  • 7. Investment costs
  • 8. Operating costs

The weights ranged from 5% to 40%. This kind of example illustrates how various people can look at the world, even one that they are all familiar with, and come to different answers and conclusions.

Other References to Balance

This author can readily think of three other references to “balance” that will be cited here.

The first is referred to in the context of model-based systems engineering, as follows [2]:

• “Systems Engineering is a multidisciplinary approach to transform a set of stakeholder needs into a balanced system solution that meets those needs”.

In the domain of systems architecting, we see the following statement from this author [3]:

• “A preferred architecture is a choice among several architectures that is balanced, cost-effective, and most congruent with the stated requirements and what the customer is seeking, as tempered by program and/or system constraints”.

TABLE 20.1 Weights vs. Evaluation Criteria from [1] Evaluators (Commissioners) 1-9

CRITERIA

1

2

3

4

5

6

7

8

9

AVERAGE*

Social effects

5

10

15

10

15

5

10

21

8

11.0

Environmental effects

20

40

10

15

20

5

15

8

12

16.1

Service quality

20

10

10

15

20

15

15

19

18

15.8

System capacity

10

10

10

15

20

20

15

15

13

14.2

Human factors

5

10

10

5

5

10

5

1

6

6.3

International economic effects

5

10

5

10

5

15

10

10

13

9.2

Investment costs

15

5

20

15

5

15

15

12

14

12.9

Operating costs

20

5

20

15

10

15

15

14

16

14.4

‘Columns do not add up to 100% due to rounding errors.

Idea Based 43

The third example comes from the systems engineering and specialty engineering section of the Systems Engineering Research Center [4], with a brief explanation of specialty engineering:

• “Specialty Engineering disciplines support product, service and enterprise development by applying crosscutting knowledge to system design decisions, balancing total system performance and affordability”.

Stakeholders

And while we are exploring balance, we must also recognize the fact that various stakeholders are looking for certain features in our systems. If we can satisfy them, we are then likely to wind up with a balanced system. These people are individually interested in:

a. Cost

b. Schedule

c. Performance

d. Specialty engineering

e. Sustainability

f. Environmental effects

g. Safety

h. Security

i. And a host of others (some fitting under specialty engineering such as RMA and ILS)

References and Recommended Reading

  • 1. Eisner, H., “Computer-Aided Systems Engineering”, Prentice Hall, 1988, p. 352.
  • 2. Friedenthal. S., et al, “Systems Engineering Overview”, Practical Guide to SysML. 2008.
  • 3. Eisner, H., “Essentials of Project and Systems Engineering Management”, Third Edition. John Wiley. 2008. p. 286.
  • 4. SERC, SEBoK (Systems Engineering Body of Knowledge), version 1.9.1, 16 October 2018, Stevens Institute of Technology.
 
Source
< Prev   CONTENTS   Source   Next >