A Rational Design Process: How and Why to Fake It
Total Page:16
File Type:pdf, Size:1020Kb
A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT David L. Parnas Department of Computer Science University of Victoria, Victoria BC VSW2Y2 Canada and Computer Science and Systems Branch Naval Research Laboratory Washington DC 20375 USA and Paul C. Clements Computer Science and Systems Branch Naval Research Laboratory Washington DC 20375 USA AB STRACT Software Engineers have been searching for the ideal software development process: a process in which programs are derived from specifications in the same way that lemmas and theorems are derived from axioms in published proofs. After explaining why we can never achieve it, this paper describes such a process. The process is described in terms of a sequence of documents that should be produced on the way to producing the software. We show that such documents can serve several purposes. They provide a basis for preliminary design review, serve as reference material during the coding, and guide the maintenance programmer in his work. We discuss how these doctmlents can be constructed using the same principles that should guide the software design. The resulting documentation is worth much more than the "afterthought" documentation that is usually produced. If we take the care to keep all of the documents up-to-date, we can create the appearance of a fully rational design process. 81 A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT David L. Parnas Computer Science Department University of Victoria, Victoria BC V8W 2Y2 Canada and Computer Science and Systems Branch Naval Research Laboratory Washington DC 20375 USA and Paul C. Clements Computer Science and Systems Branch Naval Research Laboratory Washington DC 20375 USA I. THE SEARCH FOR THE PHILOSOPHER' S STONE: WHY DO WE WANT A RATIONAL DESIGN PROCESS? A rational person is one who always has a good reason for what he does. Each step taken can be shown to be the best way to get to a well defined goal. Most of us like to think of ourselves as rational professionals. However, to many observers, the usual process of designing software appears quite irrational. Programmers often appear to make decisions without having reasons. They start without a clear statement of what they are going to build. They make a long sequence of design decisions with no clear statement of why they do things the way they do. Their goals are never defined; their rationale is rarely explained. Many of us are not satisfied with such a design process. That is why there is research in software design, programming methodology, structured programming and related topics. Ideally, we would like to derive our programs from a statement of requirements in the same sense that theorems are derived from axioms in a published proof. All of the methodologies that can be classified as "top down" are the result of 82 our desire to have a rational~ systematic way of designing software. This paper brings a message with both bad news and good news. The bad news is that, in our opinion~ we will never find the philosopherms stone. We will never find a process that allows us to design software in a perfectly rational way~ The good news is that we can fake it. We can present our system to others as if we had been rational designers. The further good news is that it pays to do so. II. WHY WILL A SOFTWARE DESIGN "PROCESS" ALWAYS BE AN IDEALISATION? We will never see a software project that proceeds as sug- gested above. Some of the reasons are listed below: 1. In most cases the people who commission the building of a software system do not know exactly what they want and are unable to tell us what they do know. 2. Even if we were to know the requirements~ there are many other facts that we need to know to design the software. Many of the details only become known to us as we progress in the implementation. Some of the things that we learn invalidate our design and we must backtrack. 3. Even if we were to know all of the relevant facts before we start, experience shows that human beings are unable to fully comprehend the plethora of details that must be taken into account in order to design and build a correct system. The process of designing the software is one in which we attempt to separate concerns so that we are working with a manageable amount of information. However, until we get to that point, we are bound to make errors. 4. Even if we could master all of the detail needed, all but the most trivial projects are subject to change for external reasons. 83 Some of those changes may invalidate previous design decisions. 5. Human errors can only be avoided if one can avoid the use of humans. No matter how rational our decision process, no matter how well we have collected and organised the relevant facts, we will make errors. 6. We are often burdened by preconceived design ideas, ideas that we invented, acquired on related projects, or heard about in a class. Sometimes we undertake a project in order to try out or use a favourite idea. Such ideas may not be derived from our requirements by a rational process; they may arise spontaneously from other sources. 7. Often we are encouraged, for economic reasons, to use software that was developed for some other project. In other situa- tions, we may be encouraged to share our software with another ongoing project. The resulting software may not be the ideal software for either project, i.e., not the software that we would develop based on its requirements alone, but it is good enough and will save effort. For all of these reasons, the picture of the software designer deriving his design in a rational, error-free, way from a statement of requirements is quite unrealistic. We believe that no system has ever been developed in that way, and probably none ever will. Even the small program developments shown in textbooks and papers are unreal. They have been revised and polished until the author has shown us what he wishes he had done, not what actually did happen. III. WHY IS A DESCRIPTION OF A RATIONAL IDEALISED PROCESS USEFUL NONETHELESS? What we have said above is quite obvious, known to every care- ful thinker and admitted by the honest ones. In spite of that we see conferences whose theme is the software design process, working groups on software design methodology, and a lucrative market for courses 84 purporting to describe logical ways to design software. what are these people trying to achieve? If we have identified an ideal process but cannot follow it precisely, we can still write the documentation that we would have produced if we had followed the ideal process. Someone reading the documentation would have the benefit of following a rational explana- tion of the design. This is what we mean by "faking a rational design process". Below we list some of the reasons for such a pretense: 1. Designers need guidance. When we undertake a large pro- ject we can easily be overwhelmed by the enormity of the task. We will be unsure about what to do first. A good understanding of the ideal process will help us to know how to proceed. 2. We will come closer to the ideal process, and to a rational design, if we try to follow the process than if we proceed on an ad hoc basis. For example, even if we cannot know all of the facts necessary to design an ideal system, the effort to find those facts before we start to code will help us to design better and backtrack less. 3. When an organisation undertakes many software projects there are advantages to having a standard procedure. It makes it easier to have good design reviews, to transfer people, ideas, and software from one project to another. If we are going to specify a standard process, it seems reasonable that it should be a rational one. 4~ If we have agreed on an ideal process, it becomes much easier to measure the progress that a project is making. We can com- pare the project's achievements with those that the ideal process 85 would call for. We can identify areas in which we are behind (or ahead). 5. Regular review of the project's progress by outsiders is essential to good management. If the project is attempting to follow an ideal process, it will be easier to review. IV. WHAT SHOULD THE DESCRIPTION OF THE DEVELOPMENT PROCESS TELL US? We believe that the most useful form of a process description will be in terms of work products. For each stage of the process, we describe: - what we should work on next; - what criteria that work product must satisfy; - what kind of persons should do the work; - what information they should use in their work; Management of any process that is not described in terms of work products can only be done by mindreaders. Only if we know which work products are due and what criteria they must satisfy can we review the project and measure progress. V. WHAT IS THE RATIONAL DESIGN PROCESS? In this section, we describe the rational, idealised software design process that we follow. Each step is accompanied by a detailed description of the work product associated with that step. The description of the process that follows includes neither testing nor review. This is not to suggest that we ignore either of those. In this paper we are describing an ideal process; testing and review belong in the real process, not the ideal.