Process-Oriented Design

6. Strengths and Weaknesses of Process Analysis and Design Methodologies

The objectives of structured analysis and design are reasonably clear; the manner of obtaining the objectives is much less clear. Structured methods rely on the individual SE's expertise to design the technical details of the application. For implementation specific details, that makes sense, but the heuristics for evaluation cannot be applied in every situation. Consequently, the SE must know what situations apply and don't apply. More than the other methods discussed in this book, you must know when to adhere to, bend, and break the rules of structured methods. 

The methodology's ability to result in minimal coupling and maximal cohesion is low because of its reliance on the SE's ability. If coupling and cohesion are not optimal, maintenance will cost more than it should, and the application will be difficult to test. In 1972, D. Parnas wrote about maximal cohesion and minimal coupling as desirable characteristics of programs. In 1968, Dijkstra wrote about the problems with 'go to' statements in programs and proposed goto-Iess programming. In 1966, Bohm and Jacopini proposed structured programming's minimalist contents as sequence, iteration (e.g., if ... then ... else) and selection (e.g., do while and do until). By the time structured analysis and design were documented in books, the notions of coupling and cohesion were understood fairly well; but how to obtain them was not.

General statements about keeping the pieces small and related to one part of the problem domain rely on the analyst to know what to do and when to start and stop doing it. Unfortunately, only experience can guide such vague suggestions. While novices can learn to rely on the methodology to guide their actions, they have no basis for evaluating the correctness or incorrectness of their work. Thus, the apprenticeship approach, with a junior person working with a more senior one to learn how to evaluate designs, is required. The more complex the application, the more important having experienced senior analysts becomes. 

Another problem is that structured design does not encompass enough of the activities to make it a complete methodology. We must have screen designs in order to develop a program specification. We must know the details of interfaces to other applications and messages to/from them to be able to develop program specifications. Structured methods do not pay any attention to either of these issues. To develop an application, the SE needs to analyze requirements and design for control, input, output, security, and recoverability. None of these are encompassed in the process-oriented methods. To summarize, process methods are useful in analyzing and designing applications that are procedural in nature; but the methods omit a great many required analysis and design activities.