Article Index
Fundamentals of Systems Engineering
Page 2
Page 3
Page 4
All Pages

Fundamentals of Systems Engineering

In this chapter we attempt to provide a technical overview of some topics from the field of software

engineering, stressing those that would be most useful to the working developer. The contents are an arbitrary

selection of the topics that would be most useful to the working analyst, designer, or programmer, operating

in the context of a smaller software project. We have avoided speculative discussions on the respective merits

of the various software engineering paradigms. The purpose of this chapter is to serve as an informational

background and to set the mood for the more practical discussions that follow. The discussion excludes object

orientation since Part II is devoted exclusively to this topic.

Characteristics of a New Discipline

Software engineering was first introduced in the 1960s in an effort to treat more rigorously the often frustrating task of designing and developing computer programs. It was around this time that the computer community became increasingly worried about the fact that software projects were typically over budget and behind schedule. The term software crisis came to signify that software development was the bottleneck in the advancement of computer technology.

During these initial years it became evident that we had introduced some grave fallacies by extending to software development some rules that were true for other fields of human endeavor, or that appeared to be common sense. The first such fallacy states that if a certain task takes a single programmer one year of coding, then four programmers would be able to accomplish it in approximately three months. The second fallacy is that if a single programmer was capable of producing a software product with a quality value of 25, then four programmers could create a product with a quality value considerably higher than 25, perhaps even approaching 100. A third fallacy states that if we have been capable of developing organizational tools, theories, and techniques for building bridges and airplanes, we should also be capable of straightforwardly developing a scientific methodology for engineering software.

The programmer productivity fallacy relates to the fact that computer programming, unlike ditch digging or apple harvesting, is not a task that is easily partitioned into isolated functions that can be performed independently. The different parts of a computer program interact, often in complicated and hard-to-predict ways. Considerable planning and forethought must precede the partitioning of a program into individually executable tasks. Furthermore, the individual programmers in a development team must frequently communicate to ensure that the separately developed elements will couple as expected and that the effects of

individual adjustments and modifications are taken into account by all members of the group. All of which leads to the conclusion that team programming implies planning and structuring operations as well as interaction between the elements of the team.

The cumulative quality fallacy is related to some of the same interactions that limit programmer productivity. Suppose the extreme case of an operating system program that was developed by ten programmers. Nine of these programmers have performed excellently and implemented all the functions assigned to them in a flawless manner, while one programmer is incompetent and has written code that systematically crashes the system and damages the stored files. In this case it is likely that the good features of this hypothetical operating system will probably go unnoticed to a user who experiences a destructive crash. Notice that this situation is different from what typically happens with other engineered products. We can imagine a dishwasher that fails to dry correctly, but that its other functionalities continue to be useful. Or a car that does not corner well, but that otherwise performs as expected. Computer programs, on the other hand, often fail catastrophically. When this happens it is difficult for the user to appreciate any residual usefulness in the software product.

This leads to the conclusion that rather than a cumulative quality effect, software production is subject to a minimal quality rule, which determines that a relatively small defect in a software product can impair its usability, or, at best, reduce its appraised quality. The statement that “the ungrateful look at the sun and see its spots” justifiably applies to software users. Also notice that the minimal quality rule applies not only to defects that generate catastrophic failures, but even to those that do not affect program integrity. For example, a word processor performs perfectly except that it hyphenates words incorrectly. This program may execute much more difficult tasks extremely well; it may have excellent on-screen formatting, a high-quality spelling

checker, an extensive dictionary of synonyms and antonyms, and many other important features. However, very few users will consider adopting this product since incorrectly hyphenated text is usually intolerable.

Finally, there is the unlikely assumption that we can engineer software programs in much the same way that we engineer bridges, buildings, and automobiles. The engineering methods fallacy is a consequence of the fact that software does not deal with tangible elements, subject to the laws of physics, but with purely intellectual creations. A program is more a thought than a thing. Things can be measured, tested, stretched, tempered, tuned, and transformed. A construction engineer can take a sample of concrete and measure its strength and resistance. A mechanical engineer can determine if a certain motor will be sufficiently powerful to operate a given machine. Regarding software components these determinations are not unequivocal. At the present stage-of-the-art a software engineer cannot look up a certain algorithm or data structure in a reference manual and determine rigorously if it is suitable for the problem at hand.

The Programmer as an Artist

Donald Knuth established in the title of his now classic work that programming is an art. He starts the preface

by saying:

“The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music.”

Therefore, it is reasonable to deduce that any effort to reduce the art of programming to the following of a strict and scientifically defined rule set is likely to fail. What results is like comparing the canvas by a talented artist with one produced by using a paint-by-the-numbers toy. Without talent the programmer’s productions will consist of the dull rehashing of the same algorithms and routines that are printed in all the common textbooks. With genius and art the code comes alive with imaginative and resourceful creations that make the program a beautiful conception.

The fact that computer programming is an art and that talented programmers are more artists than technicians does not preclude the use of engineering and scientific principles in pursuing this art. Software engineering is not an attempt to reduce programming to a mechanical process, but a study of those elements of programming that can be approached technically and of the mechanisms that can be used to make programming less difficult. However, we must always keep in mind that technique, no matter how refined, can never make an artist out of an artisan.

Software Characteristics

From an engineering viewpoint a software system is a product that serves a function. However, one unique attribute makes a computer program much different from a bridge or an airplane: a program can be changed. This malleability of software is both an advantage and a danger. An advantage because it is often possible to correct an error in a program much easier than it would be to fix a defect in an airplane or automobile. A danger because a modification in a program can introduce unanticipated side effects that may impair the functionality of those components that were executing correctly before the change. Another notable characteristic of programs relates to the type of resources necessary for their creation. A software product is basically an intellectual commodity. The principal resource necessary for producing it is human intelligence. The actual manufacturing of programs is simple and inexpensive compared to its design, coding, testing, and documenting. This contrasts with many other engineered products in which the resources used in producing it are a substantial part of the product’s final cost. For example, a considerable portion of the price of a new automobile represents the cost of manufacturing it, wile a less significant part goes to pay for the engineering costs of design and development. In the case of a typical computer program the proportions are reversed. The most important element of the product cost is the human effort in design and development while the cost of manufacturing is proportionally insignificant.