Man is a tool-using animal. ... Without tools he is nothing, with tools he is all.
Thomas Carlyle, Sartor Resartus, Book I, Chapter 4

A.1 THE BACKGROUND OF AUTOMATED TOOLS

An automated tool can be defined as anything that replaces manual work on the part of the computer programmer, the systems analyst, or even the end user who must somehow communicate his or her requirements to a systems development team. Thus, there are many things that could be regarded as tools:

• High-level programming languages, ranging from COBOL and Pascal, to the current fourth generation languages that allow the programmer to use high-level, English-like statements that are automatically translated into the low-level, primitive instructions that the computer understands.
• Cross-reference listings, “pretty-print” programs, and other utility programs that provide the programmer with ancillary, static information about his or her program.
• Testing tools, debugging tools, simulators, and the like, that provide the programmer with information about the dynamic behavior of his or her program as it is running. Testing tools help the programmer create a wide variety of test cases to ensure that a program is well-tested. Debugging tools help the programmer track down errors once he or she knows that something has gone wrong. Simulators provide the programmer with a more visual, graphic representation of the execution of the program, for example, by showing the program as a flowchart on a computer display screen, and simulating the behavior of the program as it executes by showing the flow of control through the flowchart.
• Desktop PCs and mainframes, which replace “dumb” terminals and batch development enviroments. This battle was fought and won years ago in most software organizations, but it is important to realize that the time-sharing terminal is a tool. Prior to the 1980s, programmers in most organizations had to write their programs, manually, on large coding pads; the program statements were then keypunched on cards and then fed into the computer in the middle of the night. If something was wrong (e.g., because the programmer wrote a syntactically incorrect statement)an error report would be waiting for the programmer the next morning. And the cycle would begin anew. This practice has long since disappeared in most organizations: a programmer now types his or her program directly into a desktop workstation, which often shares project-related information with hundreds of other programmers and/or end users. The program can be checked for syntactic correctness on the spot, and the programmer can test and debug his program on the spot. Today, it is hard to imagine any other environment.
• Source code control packages that prevent the programmer from making unauthorized changes to official versions of a program in the middle of the night. In a large programming project, one of the difficulties is configuration management: making sure that there is a firm control over the various pieces of the final system. Each programmer works on her or his own piece and may need dozens of revisions to that piece before it is finished. But that piece interacts with similar pieces being worked on by a dozen other programmers. Unless everyone knows which version of which piece is to be considered the official version, anarchy prevails. A source code control package is like an automated librarian: it prevents unauthorized withdrawal of or tampering with official documents.
• Systems analysis and design workbenches. The tools described above are concerned primarily with the job of writing programs (i.e., deciding what COBOL statements are required to solve a well-defined problem). But that is not where we have the major difficulty in building a software system. The real problem is in the early stages of systems analysis (figuring out what the system should do) and design (figuring out what the overall architecture of the system should be). Now we are beginning to see tools that provide assistance to the systems analysts and systems designers.

Most of the tools described above have been available for the past 10 to 15 years and many are widely used in IT organizations. The analyst/designer workbenches, on the other hand, are newer and less widely deployed. It is these tools, in my opinion, that have the potential of helping to dramatically improve the quality and effectiveness of the structured analysis concepts described in this book.

As we have seen throughout this book, successful systems analysis relies heavily on models of a system that is to be computerized. The analyst/designer workbench tools are primarily concerned with the effective development of those models, for example, they help the systems analyst construct graphical diagrams that enable the end user to understand what the system will do for him. The workbenches also help the analyst and designer ensure that the model is complete, accurate, and consistent, so the errors discovered downstream in the programming phase will be only programming errors, and not a reflection of an ongoing misunderstanding between the end user and the systems analyst. [1] And, finally, the workbenches may assist the programmer in translating the model into a working program. In the future, we may expect the workbenches to completely automate this process.

Analyst/designer tools began to appear late 1970s and early 1980s, but most organizations ignored them, for they were not very powerful, not by the mainframe standards by which they judged computer power. A sufficiently high-power workstation capable of helping the analyst/designer with his or her software engineering models would have cost $50,000 to $100,000 in the early 1980s, and that was simply out of the question for most IT organizations. Only a very few organizations with enormous projects and enormous budgets could even consider such an expenditure; and then the most one could hope for was one workstation for an entire department of hundreds of people. Some early workstations were developed in aerospace companies, defense contractors, and manufacturers of sophisticated computer graphics workstations, but the mainstream IT community studiously ignored the concept.

By the mid-1980s, things had begun to change. Powerful personal computers, with high-resolution graphics and adequate storage capacity, had dropped below a magical price barrier of $10,000. [2] Some of these were engineering-oriented workstations made by aggressive new computer companies like Apollo Computer and Sun Computer; but most were customized configurations of IBM’s immensely popular personal computer. By providing an open architecture, IBM made it possible for anyone to build a special-purpose configuration to suit his or her own needs. Thus, the software tool industry could construct a powerful workstation consisting of an IBM PC chassis, a graphics board from vendor A, additional memory from vendor B, and a high-resolution display screen from vendor C.

This ability to construct a powerful workstation that says IBM on the front was crucially important in the marketplace. The political reality is that in business organizations — banks, insurance agencies, and the nonmilitary government agencies — the personal computer must say IBM on the front panel; this is, unfortunately, more important than technological superiority of the hardware. Engineering and scientific organizations don’t care as much whose computer they use (though many of them would prefer that any personal computer they buy look like a DEC VAX computer), and defense contractors don’t care what kind of computer they use, as long as its cost can be included in the government contract.

There are now numerous companies in the United States and Europe building automated development tools — often known as CASE tools, for Computer-Aided Software Engineering — to assist the systems analyst and designer. Most of the products run on IBM PCs, though a few of the vendors have chosen the Apple Macintosh or UNIX-based workstations. Virtually all the products provide the user with a palette of icons (shapes that can be used to create drawings) and a “mouse” with which to select the icons. This may be familiar to you if you have used such graphics programs as Visio on IBM PCs. However, the analyst workstation products are far more; they understand the subject matter of the drawings. And, as we will see below, they have many features not found on simple drawing programs.

A.2 IMPORTANT FEATURES IN AUTOMATED TOOLS

It is easy to think of automated workbenches for systems analysts and designers as nothing more than “electronic etch-a-sketch” products. It is certainly true that the graphics capability of these products is the most visible and the most “sexy,” but it is only one of the important features. The workbenches must provide the following features to be of significant use in the development of a complex system:

• Graphics support for multiple types of models
• Error-checking features to ensure model accuracy
• Cross-checking of different models
• Additional software engineering support

A.2.1 Graphics Support

As we have seen throughout this book, structured analysis models rely on various forms of information: text, data dictionaries, and graphical diagrams. Text and data dictionaries can be automated using word-processing systems and conventional mainframe computers; it is the graphics support that has always been lacking. The systems analyst needs a workstation that will allow him to compose, revise, and store the following kinds of diagrams:

• Dataflow diagrams (DFD)
• Structure charts (SC)
• Flowcharts (FC)
• Entity-relationship diagrams (ERD)
• State-transition diagrams (STD)

Thus, an analyst workbench might allow the systems analyst to compose the DFD shown in Figure A.1(a).

Figure A.1(a): A typical DFD.

The computer display screen that the systems analyst looks at while composing such a diagram is shown in Figure A.1(b).

Figure A.1(b): A typical analyst workstation screen

I should point out that I composed this diagram using an “intelligent” drawing program called Top-Down on the Apple Macintosh computer that I used to write this book. [3] It took me 15 minutes to compose the diagram and another 30 seconds to copy it directly into the text of this chapter. I could have drawn the diagram by hand in 3 minutes, and I could have pasted it into the chapter, using scissors and tape, in about 30 seconds. The benefit of graphics support clearly does not come from the initial drawing of the diagram; it comes instead from the ease of modification.

In a typical systems development project, a diagram like Figure A.1 might be modified a dozen times. Indeed, one systems analyst at Tektronix told me that he and the end user had modified a DFD like Figure A.1 over a hundred times before they finally agreed that it was an accurate model of the user’s requirements. [4] Nobody in his right mind would consider redrawing a diagram manually a hundred times; however, making a small change to a diagram on the computer display screen usually takes only a minute or so. Some early results from the Hartford Insurance Group, which installed overr 600 workstations for their systems developers, indicate as much as a 40% improvement in productivity just because of the automated graphics support (see [Crawford, 1985]).

I should also emphasize that general-purpose graphics programs like Top-Down or Canvas (on the Macintosh) or Visio (on the IBM PC) are not really adequate for the software engineer. To build formal software engineering models, we must first decide what icons, or graphical symbols, will be allowed. We must then define rules that define the properties of the icons and the legal connections between icons. Figure A.1, for example, uses the four icons associated with a standard DFD: a circle, a rectangle, a notation for a data store, and a line showing the flow of data from one place to another. Top-Down, however, would have happily allowed me to include triangles, hexagons, and any other graphic representation on the diagram.

A.2.2 Error-Checking Features

Though graphics support is clearly necessary, it is by no means enough to justify the expense of an expensive “analyst workbench” tool. An analyst workbench must examine the model created by the systems analyst or designer to ensure that it is complete and internally consistent. Figure A.1, for example, could be analyzed in the following way:

• Are all the icons connected? Are there any free-standing data stores or process bubbles floating around on the diagram, with no inputs and no outputs?
• Does each process bubble have at least one output? If not, it is a suspicious black hole that gobbles up data but never produces any output.
• Are all the dataflows (the named lines connecting the boxes and bubbles) named? Do all the names exist in a data dictionary?
• Do all the processes (the bubbles) have unique names?

Similar error-checking can be done on SCs, FCs, ERDs, and STDs. And the error-checking can be extended to different levels of modeling. Figure A.1, for example, might be a low-level subsystem represented by a single bubble (bubble number 1) in a higher-level accounting system modeled in Figure A.2.

Figure A.2: A higher-level DFD.

The analyst workbench should ensure that the inputs and outputs shown in Figure A.1 match those shown for bubble 1 in Figure A.2. If they do not match, the model is inconsistent, and there will be hell to pay weeks later (or months later) when someone tries to translate the graphical model into COBOL. The same kind of balancing can be applied to several other graphical models that provide a top-down view of a system.

A.2.3 Cross-Checking of Different Models

The most important feature of an analyst/designer workbench is its ability to cross-check the consistency of several different types of models of a system. There are two aspects of this: cross-checking different models in one phase of a project and cross-checking different models at different phases of a project.

In the systems analysis phase of a project, for example, the primary objective is to determine what the user wants from the system, with little or no reference to the particular computer technology that will be used to implement those requirements. To do this, we need DFDs to highlight the division of those requirements into separate functions and the interface between the functions. We need ERDs to highlight the objects of stored data in the system and the relationship between the objects. And we need STDs to highlight the states in which the system may find itself and the time-dependent behavior of the system. In addition, we use a data dicary to maintain a definition of all the data elements in the system and some form of textual description to define the formal business policy for each bottom-level function in the system.

The key point is that all these models must be consistent with one another. If the DFD refers to a data element that is not in the data dictionary, something is wrong; if the data dictionary defines data elements that do not appear in any other model, something is wrong. If the DFD shows data stores that are not defined in the ERD, there is an inconsistency; and if the ERD shows objects that are not defined in the data dictionary and not shown in a DFD, there is an inconsistency. As we discussed in Chapter 14, all this cross-checking could be done manually, but it is a tedious, error-prone process at best. My several years of experience with software engineering in typical IT environments allows me to say with some confidence (unfortunately) that it will not be done manually, despite the exhortations of project managers and the best intentions of the technicians.

In addition to consistency checking between models in one phase of a project, it is important to compare the models developed during different phases. For example, the models developed during the analysis phase should be compared with the models developed during the design phase. This comparison should demonstrate a one-to-one correspondence between the two: every requirement described in the analysis model (i.e., the DFDs, ERDs, etc.) should be represented somewhere in the design model (i.e., the SCs, etc.), and every feature described in the design model should correspond to a requirement described somewhere in the analysis model. The most common problem, of course, is that a requirement in the analysis model gets dropped and doesn’t show up anywhere in the design model.

This is particularly common when the systems analysis model is developed by one group of people, and the design model (and subsequent coding and testing) is developed by a separate group. In the extreme case (which often occurs on government projects), the two groups may work for different companies. In any case, the two groups often represent different interests and perspectives, and they may not communicate well with each other on any level. Hence a requirement that the analysis team thought was perfectly clear may not be understandable to the design team.

Sometimes the problem is just the opposite of the above: the design team decides to introduce features that were never requested by the user and never documented in the analysis model. This may happen innocently, but it usually occurs when someone on the design team says, “Even though they didn’t ask for it, I’ll bet the users will really love this feature.” Or the veteran, slightly cynical, designer says, “Even though the users didn’t request feature X today, I know from past experience that they’ll want it next week. It’s easier to put it in now than to wait for them to ask for it.” Whether or not this is reasonable is beside the point. The important thing is to get this discussion out in the open, rather than letting the designer make a unilateral decision.

In the same way, the design model should be compared against the actual code. Again, there should be a one-to-one relationship between components of the code (the actual implementation of the analysis and design models) and components of the design model.

A.3 ADVANCED FEATURES OF AUTOMATED TOOLS

The features described above constitute the “basic” features required to make an analayst/designer tool useful in a real-world project. On the more advanced, sophisticated tool, you should expect to find one or more of the following features:

• Networks for project-wide use
• Customized software engineering methodology support
• Document control
• Project management facilities
• Productivity statistics and software metrics
• Early checking for excessive complexity
• Automated testing and simulation
• Computer-assisted proof of correctness
• Code generation
• AI support of reusable code
• Project team “blackboards”

A.3.1 Networks for Project-Wide Use

Automated tools are useful even on small, one-person projects; so is software engineering. But a small project has the advantage that the work can be done over and over again until it is right so that the use of formal models and formal tools does not have much of a sense of urgency.

Automated tools will be of most use on the large, multiperson, multiyear, multimillion dollar software development project. In projects of this kind, there are several systems analysts (often a dozen or more), several end users (often in different geographical locations), and several designers and programmers. In this kind of environment, it is important not only that the work of each systems analyst be internally consistent, but also that the work of analyst A and analyst B be consistent with one another.

This means that there has to be a level of intelligence above that of the individual systems analyst or programmer. Though there are many ways of implementing this, one of the more attractive architectures is shown in Figure A.3. Several vendors listed in Table A.1 are working to provide this kind of architecture, typically using commercial database packages (e.g., Oracle) to implement the “project repository” of models and data definitions.

The project-level server should have enough storage capacity and enough processing power to carry out project-wide consistency checking. It should also have enough power to perform additional functions. It should allow the programmers to connect directly to the organization’s mainframe for testing and other normal duties. And it is the obvious place to put the intelligence associated with many of the functions described next.

Figure A.3: A project-level analyst/designer workbench.

The addition of such a storage, together with associated disk storage, communication channels, and so on, obviously increases the cost of automated support. It is a worthwhile investment, but it typically cannot be funded out of a single year’s operating budget for a large IT staff; it could easily cost over a million dollars for an organization with a few hundred system developers. It must be recognized as part of a capital investment in the effort to make the staff more productive and more professional.

A.3.2 Customized Software Engineering Methodology Support

The automated tool usually supports a specific form of software engineering notation and procedures. The diagrams in this appendix, for example, as well as the earlier ones throughout this book, use the notation described in several YOURDON Press textbooks. Surprise! But several CASE products also support other popular software engineering methodologies, such as the Gane/Sarson notation as well as the Warnier/Orr notation. Several of the other automated support tools currently available also support more than one brand of software engineering methodology.

But there is something much more important than just supporting the methodology of vendor A or vendor B: the automated tool should allow for a customized methodology. An IT organization will almost always find that any of the popular software engineering methodologies fails to provide an adequate notation or adequate set of guidelines for the peculiar kind of system it is developing. Perhaps, for example, the IT organization feels strongly that it wants to use triangles to emphasize inputs and outputs from Martians and Captain Kirk’s Star Trek explorers (most of us don’t have to worry about such inputs and outputs, so it’s never occurred to us to ask for triangles on our automated tool). And maybe the IT organization has decided to pass an edict that no dataflow diagram will have more that 13 (a baker’s dozen) bubbles on it; another organization may decide that no system should have more than three levels of dataflow diagram. And so forth.

Clearly, this kind of customization must be allowed or the tool will gradually fall into disuse as system developers find that it does not meet their needs. Most of the current automated tools do not have this facility; virtually all second-generation products will have such a feature or they will disappear from the marketplace.

A.3.3 Document Control

As we have seen, structured analysis relies on a number of formal graphical models, supported by such textual materials as data dictionaries and process specifications; the workstations automate the development and maintenance of these documents. However, they permit something else: the control of the documents. While this may seem straightforward, it is a radical concept for most IT organizations. Many of them have only recently begun to control the source code that is produced in the programming phase of the project. [5]

But just as it is disastrous to allow a programmer to make a “teeny-weeny” change to an operational computer program in the middle of the night, so it is equally disastrous to allow a systems analyst to make a “teeny-weeny” change to a DFD or ERD in the middle of the systems analysis phase of a project, unless that change has been authorized and approved.

To make this work, we must distinguish between the private libraries that each project member maintains on his or her stand-alone workstation and the project file maintained on the project-level minicomputer shown in Figure A.3. It is the project file that we want to control. Once a systems analyst or designer has indicated that he has finished a model (or diagram) and is ready to submit it to the project file, the analyst is no longer the unilateral owner of the material.

A.3.4 Project Management

Document control is one aspect of another feature that can be provided by a project-level server: project management. The project manager can have his or her own workstation and can use the facilities of the server to coordinate, administrate and supervise the activities of the project team. With appropriate software support, he can make sure that he knows when analyst A finishes the DFD he was working on; he can instruct the server to send that DFD to analyst B for review and comments; he can then assign another piece of work to analyst A. He can use all of this material to update his project schedule and budget; and since the server keeps its own neutral record of when analyst A began and finished his DFD, he is likely to get much more accurate, unbiased input for his project scheduling activities. It may be difficult to provide a hard estimate of the value of such a facility, but most project teams will find that it is a feature that they cannot live without once it is given to them.

A.3.5 Productivity Statistics and Software Metrics

As mentioned above, the project minicomputer can keep its own record of the starting date and ending date of each piece of work (the development of a DFD, the revision of the DFD, the walkthrough of the DFD, etc.) that a systems analyst or designer or programmer carries out. Thus, productivity measures can be generated almost invisibly, which will hopefully lessen the impact of the Heisenberg uncertainty principle. [6] Compare this to the typical software development project today, where programmers and systems analysts spend an hour or so each week recording information about how they spent their time. There is a barely disguised tendency to fill out the form to make it look the way the boss wants it to (programmers may be rascals and charlatans, but they are not entirely out of touch with reality!). Also, if the recording process takes an hour, then it is interfering with the work itself; this is a form of what nuclear physicists call the Heisenberg uncertainty principle.

Almost any other software metrics that the project team decides to keep track of can be carried out by the project level minicomputer. Thus, the project team may decide that it is important to know how many DFDs are required for the system, or how many data elements, or how many functional primitives, or how many revisions were required of a DFD before it was finally accepted by the user. This information may be useful for future projects; it may also be useful for estimates of project size and cost.

A.3.6 Early Checking for Excessive Complexity

One of the most useful metrics in the long term is that of complexity. There are mathematical models of program complexity that can be used to predict the difficulty of testing and maintaining a computer program. [7] If the mathematical models are applied automatically to every module or program in the system being developed, then the developers and the project manager will have an early warning of potentially dangerous portions of the system; alternative designs can then be explored.

A.3.7 Computer-Assisted Testing and Simulation

As mentioned earlier in this appendix, there are already computer-assisted testing packages and animators that provide the programmer with a graphical representation of the execution of her or his program. There is no reason why that intelligence could not be put into the remote workstation or the project-level minicomputer.

Indeed, almost all the conventional program support tools listed at the beginning of this appendix could be incorporated into the automated workbench. As personal workstations become more powerful, it should be possible for the programmer to follow up the modeling process with actual writing of code (if it can’t be generated automatically), as well as compilation and testing. Only when the program is finished should the programmer need to upload it to the project-level minicomputer.

A.3.8 Computer-Assisted Proof of Correctness

As we discussed in Chapter 23, the field of computer-assisted proofs of correctness is still not developed to the point where average programmers and systems analysts can make use of it. But there is a wide spectrum between informal consistency checking and formal proofs of correctness. With automated support tools, we will gradually find that we move further and further away from informal consistency checking and closer and closer to complete, formal proofs of correctness. To accomplish this will require a higher level of training and sophistication on the part of the programmer than can be expected today. Hence, we should not expect to see this feature in most business-oriented workstations for another 5 years.

A.3.9 Code Generation

A major goal of many tool builders is the automated generation of COBOL, C, Visual Basic, or Java code by the workbenches. Thus, nobody would ever have to look at the code, just as today hardly anyone looks at the binary 1s and 0s that the computer hardware actually understands. In this context, we would be dealing with computable specifications, developed by the end user and the systems analyst.

We may never be able to achieve this for all systems, nor will we be able to insist on the necessary level of formal, rigorous specification from all end users. But by putting more and more emphasis on the analysis and design activities, we can easily reduce programming to a simple clerical activity. Even if we can’t completely automate it, we can arrange for the majority of it to be carried out by junior clerks, rather than Computer Science graduates earning astronomical salaries.

A.3.10 AI Support of Reusable Code

Far more appealing than the concept of automated code generation is the concept of reusable code. In the vast majority of projects (business-oriented and scientific/engineering-oriented) most of the software we intend to develop has already been done before. This year’s brand-new system is, in fact, almost like last year’s system, and not too different than the one before that. And most of the bottom-level functional primitives have been programmed before hundreds of times and exist free as library routines supplied as part of the vendor’s operating system. The only thing that distinguishes this year’s brand-new system as unique is the particular combination of those previously implemented functions, or some parameters that can be fed into the program when it begins running. For example, this year’s payroll system is basically the same as last year’s, but the FICA tax rate has changed.

This suggests that the systems analyst (and even more so the systems designer) should not look upon each new project as a grand experiment in scientific exploration, but rather a scavenger hunt to see which existing library modules, subroutines, and programs can be connected together to satisfy the user’s needs.

This is where artificial intelligence could come in handy. By matching the characteristics of a function identified by the systems analyst (e.g., number of inputs, nature of outputs, and transformation specifications or the rules that describe how inputs are turned into outputs, etc.) with an existing library of implemented functions, an expert system could suggest to the designer a number of potential candidates to be used to implement the system. And it could interact with the systems analyst to show him that by making a small change to the requirements (i.e., by compromising the user’s original requirements a little bit) an existing library function could be used in situ.

A.3.11 Project Team Blackboards

Some of the leading researchers feel that the real productivity improvements will come from the synergistic effects of a project team rather than the individual; this is because today’s large systems are not built by individuals, but rather by groups of groups of people (often in different companies). Most of the concepts described thus far concern the improved productivity of an individual worker, but the intelligence of the project-level server could be used to provide a convenient project-level view of an entire system as it gradually takes shape and grows.

More important, we are beginning to see the emergence of a number of “groupware” tools to support collaboration among knowledge workers of all kinds. Some of these tools are outgrowths of popular e-mail packages like Lotus Notes; others are based on more of a free-form document- and idea-sharing approach using the Internet and World Wide Web; some of the newer ones support video-conferencing, shared-document markup and annotation features, etc. To the extent that these tools can be incorporated into a software engineering environment, they are almost certain to increase the productivity of the development team.

A.4 CONCLUSION

My bias and excitement for this aspect of software development is obvious. Some managers will say that this technology is too expensive, that no programmer is worth the investment that would be required. Perhaps not; but since hardware is getting cheaper all the time, today’s $25,000 hardware investment is tomorrow's $10,000 and next year’s $5000.

However, a software profession dominated by automated workstations and CASE tools does raise some interesting questions: Does it make programmers obsolete? Will it destroy our creativity? Can we afford the cost? And does it guarantee that we will make dramatic improvements in our ability to produce high-quality software more productively?

There is nothing magical about automated software tools; anyone with common sense can answer these questions. Automated tools will certainly not make programmers obsolete in the short term and will not make maintenance programmers obsolete for the foreseeable future. In the meantime, it should help de-emphasize the business of programming, which will continue a trend that has been in motion since the first high-level language was invented in the late 1950s. It does not threaten the job of any programmer; it simply means that programmers will spend more time on design and analysis tasks than low-level coding tasks.

Will an automated workstation destroy the creativity of software developers? Bah! Humbug! Do CAD/CAM (computer-aided design) systems destroy the ability of a designer to design an esthetically beautiful automobile or airplane? No! A hundred times: No, no, no! Quite the contrary. The availability of automated support tools helps the programmer and systems analyst concentrate on the truly creative part of the job and spend less time worrying about the mundane parts of the job. Since an analyst workbench allows the systems analyst to spend more time inventing more models of the user’s requirements, it makes him or her more creative.

Can we afford the cost of these workstations? The simple answer is this: we cannot afford the cost of not using these workstations! Keep in mind that the cost of a sophisticated workstation, assuming that we include the project-level server support, has already dropped from a price-tag of about $25,000 in the early 1990s to a figure well below $10,000 in the early part of the 21st century. Even in the early 1990s, the cost of automated support tools was no more than the annual salary of a typical computer programmer with one to two years of experience. If one includes the overhead cost (insurance, pension benefits of 100%), that cost represented about six months of the “fully loaded” cost of an average software developer. Since we can easily justify amortizing the cost of the hardware and associated software over 3 years, the cost was roughly equal to 15% of an developer’s annual cost. In other words, if it increased the software developer’s productivity by 15% each year, it paid for itself. And now, several years later, the cost of the technology has decreased, and the average salary of developers has increased; the economic argument becomes easier and easier.

But does an automated software development workbench guarantee to improve productivity by a factor of 10? Anyone who can seriously ask such a question must still believe in the Tooth Fairy and the Easter Bunny. Does going to church every Sunday guarantee that you will go to heaven? Stupidity, arrogance, laziness, and other human frailties will always make it possible to fail despite the best of tools and support; there is no way that we can preclude this possibility. But if we believe in the power of information systems and automated support for society and for business, we should believe in it for the profession that builds systems for the rest of the human race. It should not always be true that the cobbler’s children are the last to wear shoes.

REFERENCES

1. Jack Crawford, speech at Wang Computer Company, May 6, 1985.
2. James Martin, An Information Systems Manifesto. Englewood Cliffs, N.J.: Prentice-Hall, 1984.
3. Paul Ward and Steve Mellor, Structured Systems Development for Real-Time Systems, Volumes 1-3. New York: YOURDON Press, 1985.
4. Meilir Page-Jones, The Practical Guide to Structured Systems Design, 2nd ed. New York: YOURDON Press, 1988.
5. Steve McMenamin and John Palmer, Essential Systems Analysis. New York: YOURDON Press, 1984.
6. Paul Ward, Systems Development Without Pain. New York: YOURDON Press, 1984.
7. Brian Dickinson, Developing Structured Systems. New York: YOURDON Press, 1980.
8. Edward Yourdon, Managing the System Life Cycle, 2nd ed. New York: YOURDON Press, 1988.
9. Edward Yourdon and Larry Constantine, Structured Design. Englewood Cliffs, N.J.: Prentice-Hall, 1979.
10. Tom DeMarco, Structured Analysis and System Specification. Englewood Cliffs, N.J.: Prentice-Hall, 1979.
11. Chris Gane and Trish Sarson, Structured Systems Analysis and Design. New York: Improved Systems Technologies, 1977.
12. Ken Orr, Structured Systems Development. New York: YOURDON Press, 1977.

FOONOTES

1. [1] This is important, because we know that roughly 50% of the errors in a typical systems development project today are due to misunderstandings between the end user and the systems analyst; and 75% of the cost of error removal in an operational system is associated with errors that originated in the systems analysis phase of the project.
2. [2] $10,000 is magical because it is the level at which higher levels of authorization are required before spending corporate funds.  A project manager can often see the practical benefits of a software engineering workstation and can often provide realistic cost-benefit figures.  But if the decision involves $20,000, it will escalate up to the level of an assistant vice-president who has spent weeks trying to stay awake long enough to do something useful in the organization.  Now he can organize a committee, develop standards, survey the industry, and write memos to dozens of other equally sleepy assistant vice-presidents. While all this high-level decision making is taking place, the project manager shrugs his shoulders, tries to forget that he ever submitted the requisition in the first place, and goes back to using his tried-and-true Stone Age techniques for building systems.  As you can tell, I am entirely objective and have absolutely no emotional feelings about this subject.
3. [3] Most software developers use CASE products that run on IBM PC computers, but the diagrams in this book are not from such  products.  To use them, I would have had to figure out how to merge the diagrams the text file for this book, which I am writing on a Macintosh.
4. [4] It was obviously a more complicated diagram than the one shown in Figure A.1.  Indeed, most real-world dataflow diagrams are; they have seven or eight bubbles, three or four data stores, a dozen or more dataflows, and several external terminators.
5. [5] Interestingly, the enormous effort required to review the enterprise portfolio of software for Y2K compliance emphasized the need for source code control.  Many organizations found that they had lost the source code for some of their mission-critical legacy systems; others found that they had six different, incompatible versions of the source code — none of which matched the object code that was actually running in production.
6. [6] Though the Heisenberg uncertainty principle is usually associated with the field of nuclear physics, it applies here as well: very simply, the principle says that you can’t measure a phenomenon without changing the phenomenon.  If a worker has to spend 10% of his time measuring his own work, then his productivity goes down by at least 10% and the fact that he knows that he is being measured (by virtue of measurements that he captures himself) is likely to alter his behavior.
7. [7] As we discussed in Chapter 23, one of the more popular models is the McCabe cyclomatic complexity measure. For more about this and other models, see Tom DeMarco’s Controlling Software Projects (New York: YOURDON Press, 1982).