Throughout this book, we have seen an evolution of ideas and techniques in the field of systems analysis. They fall into three broad periods of time:

This chapter summarizes some of the major changes that have taken place since the introduction of classical structured analysis in the late 1970s, and to use this as a starting point for discussing likely changes over the next 5 to 10 years.

25.1 WHAT HAS CHANGED

Several aspects of structured analysis have gradually changed over the past ten years. The major areas of change include the following:

It is important for you to be familiar with these changes, for you may find yourself working for an organization that has not yet incorporated the changes into their standards; in 1987, when the first edition of this book was being written, many large organizations that I visited throughout the United States were still using systems development methods that were at least 10 years old.

25.2 FUTURE DEVELOPMENTS IN STRUCTURED ANALYSIS

No one can profess to know the future in any detail; the most we can hope for, as Arthur C. Clarke points out in the introduction to this chapter, is to find some signposts to the future. Recent developments suggest a number of trends that are likely to continue well into the next decade. They include the following:

25.2.1 More Widespread Awareness of Systems Analysis

Computers, as we all know, are becoming a ubiquitous part of everyone’s life. Consequently, we are finding that a larger and larger part of society is learning to use computers and talk about computers; more importantly (in the context of this book), many people are becoming increasingly familiar with structured analysis and other aspects of software engineering. I am especially interested in the future impact of structured analysis on three groups: senior management in our business and government organizations, children, and computer professionals in Third World countries.

In most large organizations, one typically finds that the senior levels of management are people in their late 40s, or 50s, or 60s. This means that they received their education and spent the formative years of their career 20 or 30 or even 40 years ago. If we look at corporate cultures up through the 1970s, and perhaps even the 1980s, we have to remember that while computers were certainly being used, they were not widely available to individuals, and they were not part of the technology or culture that people grew up with. But this has changed dramatically since the early 1990s; we are beginning to see senior levels of management who either (1) began their career in the data processing or IT organization [1], or (2) began their career in some other part of the organization (e.g., accounting, sales, or manufacturing) whose day-to-day operation was dramatically affected by computer technology. This means that you can expect, as a systems analyst, that top management will be increasingly aware of the strategic importance of information processing systems in their organization, and they will be increasingly interested in seeing high-level models of major new systems. If you tried to show a dataflow diagram to the CEO of your organization today, chances are that he would not understand it and would not understand why he or she should understand it. Especially now that the Internet and “e-business” are having such a dramatic effect on the economy, I believe that senior management will come to realize that it is just as important to be able to read (and critique) a system model as it is to read and critique a balance sheet or profit and loss statement.

Children will also become more and more familiar with the concepts structured analysis over the next several years. Already structured programming and structured design are being taught at the high school level in some parts of the United States. Structured analysis, once the subject of graduate level seminars, is now being taught at the third year and fourth year of undergraduate computer science and business school curricula, and will soon be part of a standard first-year college subject. Long division was once a college subject and is now taught regularly to young children; similarly, structured analysis will be a topic that children learn during their normal educational process.

It has been estimated that any U.S. child born after 1980 will graduate from secondary school having written 10,000 lines of code; this is equivalent to roughly a year of full-time programming experience for today’s adult programmer. Along with all this programming experience, we can expect that the current generation of children will have more and more experience with systems design and systems analysis. Not all this generation will end up choosing a career as a programmer or systems analyst; indeed, only a small fraction will choose such a career path. But the rest of today’s children, whether they choose to be accountants or engineers, salespeople, teachers, or politicians, will form a community of intelligent end users of information systems; users will know much more about what to expect from a systems analyst and what to ask of a systems analyst. Much of our present work, predicated, it seems, on the difficulty of dealing with ignorant users, may be superfluous in the future.

There is one other aspect of the growing awareness of structured analysis that we should mention: the impact on software industries in developing nations. Throughout the latter part of the 20th century, international competition in a variety of manufacturing industries has become more and more intense, and American industries have often lost competitive ground (or gone out of business) when faced with Japanese, Korean, Chinese, or Brazilian industries offering a high-quality product at a competitive price. The same phenomenon is beginning to happen in the systems development industry. Software engineering techniques, including the structured analysis techniques discussed in this book, can help the competitive organization develop systems with a productivity ten times higher than that of many American organizations and with a level of quality (expressed in mean time between failure or number of bugs) one hundred times higher than that of comparative American organizations [2]. And since, to a larger and larger degree, all our products and all our services depend on computer-based information systems, this has profound implications for all of American industry [3].

25.2.2 Deployment of Automated Tools

Throughout this book, we have discussed the possibility of using workstation-based tools to automate various aspects of structured analysis, especially the labor-intensive activities of creating graphical system models and checking them for completeness and correctness.

Appendix A describes the features of many such analyst toolkits that are currently available. But few systems analysts are using these tools, even today. In the early 1990s, approximately 10% of the systems analysts in North America, Western Europe and other software development centers) typical systems development organization had access to person workstations for creating dataflow diagrams, entity-relationship diagrams, and so on.. It was expected that by the end of the decade, we would have reached the “critical mass” of 50% deployment of such tools throughout the industry; however, there was a backlash against such tools in the mid-1990s because of their perceived inefficiency and overhead. Throughout the latter part of the 1990s and early part of the 21st century, there has been a great emphasis on visual development environments that greatly enhance the ease of prototyping and rapid implementation, and a stagnation of interest in analysis/design modeling tools.

Assuming that we do eventually reach a critical mass of deployment of automatic analysis tools, it will be reasonable to argue that our approach to systems analysis will have fundamentally changed. To draw an analogy: it is interesting to talk about the improvements that can be achieved in the field of carpentry by using a power saw instead of a hand saw, but the issue is moot if only 1% of the carpenters have electricity. And the power of the tool does indeed affect the way we work with the world around us; Craig Brod made this point very eloquently in a classic book called Technostress ([Brod, 1984]):

25.2.3 The Impact of Maintenance Disasters

In the previous chapter, we discussed the user of the structured analysis model to facilitate ongoing maintenance and modification of systems. But this is an issue that often seems abstract, philosophical, and politically unimportant during the development phase of a project, when the primary emphasis seems to be getting the system delivered to the user. Preferably a working system; hopefully the system the user wanted. But, failing that, any system that appears to work and appears to satisfy at least some of the user requirements. The simple political reality is this: the importance of structured analysis and formal, rigorous system models has not been fully appreciated by many senior managers in our organizations. Even within the ranks of EDP management, structured analysis doesn’t have the same “gut-level” sense of urgency as the political necessity of delivering a working (or allegedly working) system on time to the user.

As I suggested above, this situation may change as the user population becomes more familiar with computer technology and as competition from Third World countries becomes more intense. But there is another phenomenon that will dramatically highlight the need for current, up-to-date system models that are maintained as diligently as the source code: maintenance disasters that that will cause current systems to collapse.

In the extreme case, this may happen because an existing system — a large, complex, undocumented system — aborts or comes to a standstill, with no one able to figure out how to repair it. But this is unlikely; it is more likely that the cause of the failure will be identified and simply outlawed. The word will go out, “You can’t enter a type X25 transaction into the system any more because it causes problems.”

No, the likely cause of a major maintenance disaster will be the total impossibility of making a necessary, urgent modification to an existing system. Such changes are often mandated by new legislation or government policy; but they may also be required because of changes to the business environment or competitive situation.

Many organizations faced this problem during their Y2K remediation efforts — i.e., when systems had to be updated to properly handle both 20th-century and 21st-century dates. Part of the problem was related to the implementation of the system, that is, coding that had been patched and repatched so many times that it was no longer possible to determine accurately how the system operated. In several cases, the only viable option was to scrap the system and replace it with an entirely new package, often acquired at considerable expense.

But the larger problem, both in the Y2K projects and with many current maintenance situations, is that nobody knows or remembers what these systems are really supposed to do. Third-generation maintenance programmers are now interacting with third-generation users to discuss potential changes to a system whose original requirements are a mystery to both. In this environment, it is inevitable that the maintenance programmers will eventually throw up their hands and refuse to make any more changes.

When faced with a problem like this, top management is likely to have a “knee-jerk” reaction: committees will be formed, standards will be imposed, and new procedures will be promulgated. Just as we have seen government leaders react to problems of toxic waste, oil spills, corruption, and a number of other problems only after a major disaster occurs, I believe that a number of top business and government managers will react to the problem of nonexistent system models only after a major maintenance problem occurs [4].

25.2.4 The Marriage of Structured Analysis and Artificial Intelligence

Starting in the late 1980s, significant attention has being devoted throughout business, government, and the computer industry to artificial intelligence (AI): expert systems, natural language systems, robotics, and many related fields. Though AI had previously been considered an academic subject with little practical application, and though it was once implemented on exotic hardware with unfamiliar programming languages like LISP and PROLOG, it has gradually become more of a mainstream topic — particularly the area of expert systems, those systems that can replicate the behavior of human experts in certain narrowly defined fields. More and more AI software packages and textbooks are available for COBOL-based environments and PC-based environments (see, for example, [Taylor, 1985], [Derfler, 1985], [Webster, 1985], [Keller, 1986], and [Rose, 1985]). More and more AI applications, ranging from medical diagnosis to oil exploration to stock portfolio evaluation to tax planning, are finding their way into the mainstream business world [5].

What does this have to do with structured analysis? The connection between artificial intelligence and expert systems works in both directions: structured analysis can help in the process of building an expert system, and expert system technology can help in the process of doing structured analysis.

When building an expert system, three aspects of the system are often dominant: the human interface, the knowledge representation, and the inference engine that evaluates and interrogates the knowledge base. The human interface may involve natural-language (English, French, German, etc.) input and a combination of graphics, text, and sound for output. The knowledge base may be expressed as a series of IF-THEN-ELSE rules or as a series of frames [6]. And the inference engine may be based on a forward-chaining or backward-chaining approach and may be implemented with a vendor-supplied “expert shell.”

But the significant thing about all this is that the expert system components are now becoming just a part of a larger system, for example, an operational system that feeds and updates the knowledge base or that uses the output of the expert system component to carry on other system functions. Thus, the modeling tools of structured analysis may be used to help model the overall system. But more important, it means that in the coming years, you may need to become familiar with the technology of expert systems and artificial systems in order to be a successful systems analyst. Keller’s book ([Keller, 1986]) is a good place to start, for it shows many of the interactions between structured analysis and expert systems.

In a reverse sense, AI can assist the process of structured analysis by acting as a tutor to guide a junior analyst through the various steps and processes described in this book. One could easily imagine, for instance, an “analyst’s assistant” that would ask a series of questions of the human analyst and then produce a proposed context diagram or event list. Just think: can you remember, now that you have reached the end of this book, all of the rules and guidelines of the past several hundred pages? Do you think you’ll remember them all a year from now? Wouldn’t it be nice to have an expert system available in a desktop computer that could remind you how to draw DFDs, ERDs, and STDs that are all properly balanced?

While all this sounds very exciting, you should not be concerned that expert systems are doing to do away with human systems analysts. Researchers in this field point out that all the successful expert systems, ranging from medical diagnosis to portfolio analysis, have succeeded because they have concentrated on a very limited domain of expertise. A successful systems analyst, though, really needs to be an expert in several different areas: he must understand the technology of structured analysis presented in this book; he must understand the user’s application area; he should know a lot about accounting, so that he can produce accurate cost-benefit calculations; he should be an expert in communications and cognitive psychology, so that he can communicate effectively with the user; and he should also be well-versed in computer hardware and software, so that he can communicate effectively with designers and programmers. Current estimates (see, for example, [Barstow, 1987]) are that expert systems will be able to help do the job of systems analyst on simple systems by the mid-1990s, but it will be well past the end of the century before expert systems technology will be able to do systems analysis on large systems.

25.2.5 The Impact of New Generations of Computer Hardware

Enormous sums of money are being expended today by private companies, universities, research organizations, military organizations, and governments around the world, all with the objective of producing dramatically more powerful computer hardware during the next 10 to 15 years. What has this to do with systems analysis? Simply this: the business of defining user requirements for an information system has to be done within the context of what the user and the systems analyst think is possible with available technology. But what we think is possible is based largely on what we know now about computer technology. It could well be argued that most end users and most systems analysts do not even begin to make use of existing computer hardware technology, so what are they going to do with technology one million times more powerful?

Past experience with other technological advances, for example, in the field of communication (from smoke signals to telegraph to telephone, etc.) and transportation (from walking to horses to cars to airplanes, etc.) gives us a clue; our first reaction to radically improved technology is to continue doing the same kind of things we did before, but a little faster and more easily (and more economically, in many cases). Only later do we begin to see entirely new applications for the new technology.

As an example, consider the field of transportation, with which we are all familiar; while airplane travel is relatively new (compared to the history of the human race), it has been with us all our lives, and it has an important impact on our assumptions, both conscious and unconscious, explicit and implicit, about the way we can live our lives. Suppose someone told you tomorrow, though, that a supersonic underground train was available to carry you from the East Coast of the United States to the West Coast at speeds of 3000 miles per hour [7]. What would this do to your business life? To your social life? What kind of changes would you begin making today if you were reasonably certain that this advanced technology would be available to you within the next 3 to 5 years?

And that is exactly the position that we will find ourselves in as systems analysts for the rest of this century; each time we are given dramatically more powerful computer technology, our first reaction (and the reaction of the end users, too) will be to reimplement existing applications somewhat more efficiently. The challenge will be to find entirely new applications — entirely new, radically different uses of computer technology — than the applications currently being developed.

25.3 CONCLUSION

It is important that you have a future-oriented perspective as you finish this book and begin practicing structured analysis in the real world. While the modeling, iterative problem solving, top-down partitioning, and other concepts discussed in this book will almost certainly be valid for the foreseeable future, many of the details (e.g., the technology available to support structured analysis, and even such specific techniques as event partitioning) may change or be replaced.

You should not expect that the material you have learned in this book is constant, permanent, impervious to change. Like all science, and especially like all other aspects of computer science, the field of systems analysis is destined to continue changing, evolving, and (hopefully) improving well into the next century and beyond. For some, it is frightening to realize that half of what one learns in this technical field is obsolete within 5 years. For others, and I hope that you will include yourself in this category, it is a source of constant renewal and excitement.

And on that note we come to the end of this book. You are not yet a veteran systems analyst, but you should have enough tools and techniques to enter the profession without fear of falling flat on your face. May you enjoy the practice of structured analysis on information systems that will benefit society. And may you return in less than 5 years to see what has changed. Ciao!

REFERENCES

QUESTIONS AND EXERCISES

FOOTNOTES