“New terms such as techno-stress and techno-shock have been coined to define the psychological manifestations of a public overwhelmed by everything from microwave ovens to home Pac-Man games. Unfortunately, these terms do not accurately describe progress within the data processing industry as it pertains to software development. For many data processing professionals, techno-stress is better defined as frustration with the slow pace of change in software development methods, in the face of ever-increasing demand for dp services.

“While there is no question that some progress toward better systems development methods has been made during the last 30 years, there is equally no question that, overall, any process of change is slow and discontinuous. Speaking from an historical perspective, it seems that for true progress to be realized, there must be a periodic, collective rethinking of basic ideas. The periods between each great leap forward can be tens of years to hundreds of years.”

— F.J. Grant
“Twenty-First Century Software,” Datamation, April 1, 1985

IN THIS CHAPTER, YOU WILL LEARN:

The systems analysis methods and tools presented in this book represent a state of the art approach that will be used in most systems development organizations at least throughout the first decade of the 21st century. Assuming that computer technology continues to advance at approximately the same rate that we have experienced for the past 40 years, it is likely that systems analysis will have evolved substantially by the end of this decade; Chapter 25 discusses the likely nature of that evolution.

But it is not enough for you to be aware of today’s systems analysis techniques. You must also have an understanding of the changes that have taken place over the past decade, changes that have led to the tools and techniques that we will explore in depth in Parts II and III. There are three reasons why you should be familiar with the evolution of systems analysis.

First, you may find that the systems development organization you work for has not evolved and that nobody has any intention of making any changes. Though the changes discussed in this chapter have occurred in approximately 80% of the data processing organizations in North America, Europe, and other parts of the world, there are still those backwater bastions of mediocrity that see no reason to change the way they were doing things 20 years ago. If you find yourself in this situation, the logical thing to do is to look for another job; or, if you are feeling brave, you might take on a leadership role and help bring your organization into the modern world of systems analysis.

Second (and more likely), you may find that your organization has begun to implement some of the changes discussed in this chapter, but the process of change will continue for another few years. A good example of this is the deployment of automated tools for requirements management, or requirements-based testing. Almost all systems analysts will tell you that such tools are a good idea, and some project managers are beginning to support the concept. But low-cost, powerful tools are relatively new, and organizations are slow to change; indeed, historical studies have shown that it often takes 12-15 years for new tools and techniques to permeate the IT community, even after they have been demonstrated to be effective. Thus, even though you and the other members of your organization may know what kind of tools and techniques will be installed three years from now, today’s approach to systems analysis may be somewhat different. It is important for you to know the approach that the organization was using previously and what kind of transition is underway.

Third, the notion of transition is important even if you work in one of the “leading edge” organizations that has completely implemented the systems analysis approaches presented in this book. The field of systems analysis, like all other aspects of the computer field, is dynamic; the way we do systems analysis in the second or third decade of the 21st century will undoubtedly be different than the way we do it now. But to see what changes will take place during the middle and latter part of the first decade of the 21st century, you need an appreciation of where the field came from and the direction it is heading in.

7.1 THE MOVE TOWARD STRUCTURED ANALYSIS

Until recently, the overwhelming majority of systems development projects began with the creation of a “Victorian novel” statement of user requirements. That is, the systems analyst documented his or her understanding of the user’s requirements in a massive document consisting primarily of narrative English. Early authors of “structured analysis” textbooks —especially (DeMarco, 1978), (Gane and Sarson, 1977), and (Weinberg, 1978) — pointed out that these ponderous tomes (often known as a functional specification) typically suffered from several major problems:

While all these problems were being debated, a complementary set of ideas was already being adopted in the area of programming and design. These ideas, generally referred to as structured programming (SP) and structured design (SD), promised great improvements in the organization, coding, testing, and maintenance of computer programs in the 1970s and 1980s; in the 1980s and 1990s, a newer set of ideas, involving object-oriented programming (OOP) and object-oriented design (OOD), gradually became popular. And indeed, structured development and object-oriented development techniques have generally proved successful; but more and more IT organizations gradually began to realize that there was no point writing brilliant computer programs and designing highly modular systems if nobody really knew what the systems were supposed to do. Indeed, it could be argued that SD/SP and OOD/OOP allowed some project teams to arrive at a disaster more quickly than ever before — building a brilliant solution to the wrong problem!

As a result, there has been a gradual movement — gradual in the sense that it has taken the systems development profession nearly ten years to accept it — toward functional specifications that are:

This approach, generally known as structured analysis, is now used in the majority of business-oriented systems development organizations, as well as a large number of engineering-oriented organizations. You will still find some organizations churning out Victorian novel specifications, but they are in the minority, and, like dinosaurs, they will eventually become extinct.

7.2 CHANGES IN CLASSICAL STRUCTURED ANALYSIS

As mentioned above, traditional systems analysis (characterized by Victorian novel specifications) began to change in the late 1970s. Many of the organizations now using structured analysis continue to base their approach on the early textbooks of DeMarco, Gane and Sarson, and others, as well as the seminars, videotapes and other training materials based on those books. However, several years of practical experience with classical structured analysis have pointed out a number of areas where changes or extensions need to be made. The major changes are these:

7.3 THE EMERGENCE OF AUTOMATED ANALYSIS TOOLS

As the graphical modeling techniques of structured analysis began to spread through systems development organizations in the 1980s and 1990s, systems analysts began to realize that there was a major problem: the artwork required to create dataflow diagrams, entity-relationship diagrams, structure charts, state-transition diagrams, and other graphic models was often overwhelming. The problem, in most cases, was not the initial creation of the diagrams, but rather their revision and maintenance; creating the initial diagram is time-consuming, but at least has the satisfaction of being a challenging, creative, intellectual activity. In a typical project, the systems analyst finds that he must redraw the graphical models several times before he and the user can reach an agreement on the requirements of the system. [6a]

On a large system, there may be 50 to 100 or more dataflow diagrams, several entity-relationship diagrams, and potentially several state-transition diagrams; so the amount of artistic labor involved can be daunting indeed. The practical consequence of this, in many organizations, is that classical structured analysis was not as successful as it should have been. The following problems occurred:

In addition to the work required to create and maintain the diagrams, classical structured analysis requires a great deal of work to verify the diagrams to ensure that they are complete and consistent; these rules are discussed in Chapter 14. [7a] Throughout the 1970s and most of the 1980s, systems analysts have had to depend on manual verification techniques (i.e., visually inspecting the diagrams to spot errors). Because the work is labor intensive and boring, its tends to be error prone. Consequently, many of the specification errors that should have been found were not.

Many of these problems can be solved with proper automated support; this was well known even when classical structured analysis was first introduced, but the cost of automation was far higher than most organizations could afford. However, the development of powerful graphics workstations in the mid-1980s has led to a whole new industry known as CASE (an acronym meaning Computer-Aided Software Engineering); several dozen vendors offer products (usually PC-based) that will draw dataflow diagrams, and the like, as well as perform a variety of error-checking tasks. Features and examples of these tools are discussed in Appendix A.

Only a small percentage of the systems analysts in the United States had access to such tools in the 1990s; and the CASE industry unfortunately suffered a backlash by promising miracles it could never deliver. [8] However, it still appears to be essential to successful practice of structured analysis, and we can expect that most professional systems analysts will eventually have access to such tools. This will lead, primarily, to a higher level of quality in the systems models produced; secondarily, it will lead to more visually pleasing graphic models of the system. To the extent that the error-checking concepts discussed in Chapter 14 are automated, it may eliminate the need for systems analysts to learn the material in Chapter 14! And to the extent that the CASE tools eventually begin generating programs (in COBOL, C, Visual Basic, etc.) directly from the specifications, it will even reduce the need for programmers!

7.4 THE USE OF PROTOTYPING

As we pointed out in Chapter 3, some users have a difficult time working with the graphic models of structured analysis; they prefer some other way of modeling the requirements and behavior of the system. Prototyping tools, which began to be widely available in the mid-1980s, have been seen by some as an alternative to structured analysis for such users.

There is another reason for the popularity of prototyping: as we discussed briefly in Chapter 6, classical structured analysis is regarded in some organizations as too time consuming; by the time the analysis phase is finished, the user will have forgotten why he wanted the system in the first place. This is usually the result of one of the following problems:

Prototyping tools (software tools that allow the systems analyst to build a “mockup” of the system) are thus seen as an effective solution to these problems. Note also that prototyping tends to concentrate on the human interface aspect of a systems development project.

Unfortunately, the prototyping tools are sometimes used to avoid the details of systems analysis and design altogether; an appropriate use of prototyping was shown in Section 5.6.

7.5 THE MARRIAGE OF SYSTEMS ANALYSIS AND DESIGN

As mentioned earlier in this chapter, improvements in the software engineering field began with structured programming and structured design; indeed, these two topics were the subject of considerable debate in systems development organizations throughout the early and mid-1970s. It was also during this period that the first textbooks on structured design began to appear (see (Myers, 1975) and (Yourdon and Constantine, 1975)); early books made no reference to structured analysis (since the concepts had not yet been developed), while later books such as (Page-Jones, 1980) included a brief overview of the subject. Work on structured analysis began in the mid-1970s, and the first textbooks began to appear in the late 1970s; but there was little or no connection between the discussion of structured analysis and the discussion of structured design. The main problem was that structured analysis dealt with the specification of large, complex systems, while structured design seemed more appropriate for the design of individual programs running on a single computer. The bridge between systems analysis and program design, that is, systems design, was missing.

This problem has been addressed by several consultants, authors, and systems development organizations in the 1980s. Recent books by (Ward and Mellor, 1985), as well as new editions of books by (Page-Jones, 1988) and (Yourdon and Constantine, 1989), now deal with the issues of systems design as well as program design.

7.6 SUMMARY

Like any field of science or engineering, systems analysis has undergone a series of evolutionary changes during the past 20 years. As indicated at the beginning of the chapter, it is important for you to know what those changes have been, because the software development industry is large enough and diverse enough that not everyone is practicing the same techniques at the same time. Your organization may be at the “leading edge” of technology, or it may be at the “bleeding edge.”

You can expect the field of systems analysis to continue; the techniques presented in this book will have evolved even further within the next five to ten years. Chapter 25 discusses the likely nature of further evolutionary changes.

REFERENCES

QUESTIONS AND EXERCISES

FOOTNOTE