Understanding the Planning Process, Page 8
So how can this scenario occur so frequently in the software industry? In fairness, creating software is not as straightforward and clean-cut as building a house. There are many more variables and far fewer standard materials and methods. Yet, there are many basic lessons from home construction that seem to escape the notice of software builders.
First, you can't promise the customers exactly what they want for exactly what they would like to pay. Sure that may be a strategy for getting a sale, but not necessarily a formula for running a successful business.
Second, you can estimate the cost of a house pretty well just by knowing the square feet enclosed. Based on only that one metric, you can tell the owners within a narrow range what their house will cost, only adjusted for any high-quality extras they might want. There is no such square footage metric for software, so the estimation process is infinitely more difficult.
Third, you can't build a house based on traffic flow diagrams and room modeling charts that describe the house indirectly at best, with required details buried inconsistently among all the superfluous information. The builders of houses require a clear blueprint designed specifically to meet their needs. Yet in software development, more complex in many ways, we set about our jobs without an analogous blueprint.
Yet the level of complexity is really quite comparable. Software blueprints can be far more simple, standardized, clear, and efficient than the documents we normally produce in their place. What elements would a comparable software blueprint contain?
- A Data Dictionary to establish a clear, unambiguous vocabulary
- Mockups or prototypes to lay out the floor plan of the screens
- Pseudocode to unambiguously define operational logic
- Precise definitions of data elements so that the forms and databases can be constructed
- Logic to clearly define the rules for data translations
- Narratives to describe relevant background
With such a blueprint in hand, developers normally have all the information they need to produce software quickly and accurately the first time, with minimal input from the business experts. Builders of a house don't need to understand a lot about the day-to-day activities of the future owners. Likewise, software developers don't necessarily need to understand a lot about the client's business. The reason that many experts feel that greater understanding by developers is a requirement is because the developers usually do their own research or use their own judgment to compensate for incomplete project plans.
Obviously, you can't take disorganized output generated during the planning process and call that a blueprint. A blueprint has very specific characteristics. It distills other information and presents it in a logically complete and consistent format for use by the software builders.
Blueprint format has to be the expressed goal of all your efforts right from day one. The specific format of that blueprint must be clearly known from the start of the process, and all efforts should be dedicated to getting to that blueprint as efficiently as possible. You can't start with all the things you have been generating in the past and create a blueprint from it. Also, you can't get to a blueprint by accident. Nor can you create a good blueprint as an afterthought.
To produce a good software blueprint, you must engineer a planning process that begins to develop that blueprint from day one. The curious thing is that if you do so, that process can be considerably more simple and efficient than your current strategies that achieve far less useful results.
1 We will take a romp into the more distant future of software development in Section 8.1.
2 I was immediately corrected by Jim Highsmith who pointed out that he worked on the re-entry calculations for the Apollo moon missions. Some guys get all the glamour jobs!
3 The Far Side © by Gary Larson ) 1990 FarWorks, Inc. All Rights Reserved. Used with permission.
4 Robertson, James and Suzanne, Mastering the Requirements Process, © 1999. Reprinted by permission of Pearson Education, Inc.
5 Humphrey, Watts S., Managing the Software Process, © 1989 Addison-Wesley Publishing Company, Inc. Reprinted by permission of Pearson Education, Inc.
6 DeMarco, Tom, Controlling Software Projects: Management, Measurement, and Estimation, 1st ed. Englewood Cliffs, NJ: Prentice Hall PTR/Sun Microsystems Press, 1998.
7 Yourdon, Edward, Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects. Upper Saddle River, NJ: Prentice Hall PTR, 1999.
8 In the next chapter we will review the project planning phases in detail.
9 Section 4.7 will go into greater detail about the Direct to Blueprint approach.
10 Chapter 9 will describe the Software Blueprinter application in detail.
11 Section 4.4 will discuss the Data Dictionary.
12 Chapter 7 is dedicated to the topic of metadata.
13 Section 4.8 discusses the problem of uncontrolled elicitation in great detail.
14 The topic of phase overlap is discussed in Section 3.6.
15 Reprinted with the permission of Dorset House Publishing from Why Does Software Cost So Much? by Tom DeMarco. Copyright © 1995 by Tom DeMarco, pg. 8. All rights reserved.
16 Reprinted with the permission of Dorset House Publishing from Ken Orr's "Foreword" to Adaptive Software Development by James A. Highsmith III. Copyright ) 2000 by Kenneth T. Orr, p. xxi. All rights reserved.
Source of this material
|This is Chapter 2: Understanding the Planning Process from the book Planning Smarter: Creating Blueprint-Quality Software Specifications (ISBN: 0-13-065414-0) written by Tyson Gill, published by Prentice Hall Inc..|
To access the full Table of Contents for the book