PSL/PSA: a computer-aided technique for structured documentation and analysis of information processing systems

• Authors: D. Teichroew;E. A. Hershey, III
• Venue: Classics in software engineering
• Year: 1979

I vividly remember a Datamation article, written by Daniel Teichroew in 1967, predicting that within ten years programmers would be obsolete. All we had to do, he said, was make it possible for users to state precisely what they wanted a computer system to do for them; at that point, it should be possible to mechanically generate the code. Having been in the computer field for only a few years, I was profoundly worried. Maybe it was time to abandon data processing and become a farmer? Those early ideas of Professor Teichroew perhaps were ahead of their time --- after all, there still were a sizable number of programmers in existence in 1977! --- but some of his predictions are beginning to take concrete form today. The following paper, written by Teichroew and Hershey and originally published in the January 1977 IEEE Transactions on Software Engineering, is the best single source of information on a system for automated analysis, known as "ISDOS" or "PSL/PSA." The Teichroew/Hershey paper deals specifically with structured analysis, and, as such, is radically different from the earlier papers on programming and design. Throughout the 1960s, it was fashionable to blame all of our EDP problems on programming; structured programming and the related disciplines were deemed the ideal solution. Then, by the mid-1970s, emphasis shifted toward design, as people began to realize that brilliant code would not save a mediocre design. But now our emphasis has shifted even further: Without an adequate statement of the user's requirements, the best design and the best code in the world won't do the job. Indeed, without benefit of proper requirements definition, structured design and structured programming may simply help us arrive at a systems disaster faster. So, what can be done to improve the requirements definition process? There are, of course, the methods proposed by Ross and Schoman in the previous paper, as well as those set forth by DeMarco in the paper that appears after this one. In this paper, Teichroew and Hershey concentrate on the documentation associated with requirements definition, and on the difficulty of producing and managing manually generated documentation. The problems that Teichroew and Hershey address certainly are familiar ones, although many systems analysts probably have come to the sad conclusion that things always were meant to be like this. They observe, for example, that much of the documentation associated with an EDP system is not formally recorded until the end of the project, by which time, as DeMarco points out, the final document is "of historical significance only" [Paper 24]. The documentation generated is notoriously ambiguous, verbose, and redundant, and, worst of all, it is manually produced, manually examined for possible errors and inconsistencies, and manually updated and revised as user requirements change. So, the answer to all of this, in Teichroew and Hershey's opinion, is a computer program that allows the systems analyst to input the user requirements in a language that can be regarded as a subset of English; those requirements then can be changed, using facilities similar to those on any modern text-editing system, throughout the analysis phase of the project --- and throughout the entire system life cycle/ Perhaps most important, the requirements definition can be subjected to automated analysis to determine such things as contradictory definitions of data elements, missing definitions, and data elements that are generated but never used. The concept for PSL was documented by Teichroew more than ten years ago, but it is in this 1977 paper that we begin to get some idea of the impact on the real world. Automated analysis slowly is becoming an option, with a number of large, prestigious organizations using PSL/PSA. One would expect continued growth; ironically, though, a reported problem is machine ineffTciencyf PSL/PSA apparently consumes significant amounts of CPU time and other computer resources, although Teichroew and Hershey maintain that such tangible, visible costs probably are smaller than the intangible, hidden costs of time wasted during "manual" analysis. It appears that PSL/PSA is most successfully used in organizations that already have vast computer installations and several hundred (or thousand) EDP people. A significant drawback to widespread adoption of PSL/PSA is the fact that it is written in FORTRAN! Admittedly this has helped make it portable --- but FORTRAN?