|
Designing Hard Software The Essential Tasks Douglas W. Bennett 1996 | 350 pages ISBN: 133046192 |
|||
 |
$47.95 | Softbound print book | |
Preface
I wrote this book because I believed the advertisements that PPI (later Stepstone) Corporation published. PPI was an early player in the object technology market. Their ads promised wonderful things to the users of object -oriented programing languages: reuse, quick development, robustness in the face of change, and ease of extension. I went to work for PPI and found that those benefits were not automatically appearing in products written in the company's programming language. Why not? It must be the methodology. Software methodologies were a little thin at the time, particularly in the area of object-oriented design. About this time, 1987, Ivar Jacobson had just started to publish articles on his proprietary (at the time) process for developing software. He was saying good things about the importance of making sure that our designs matched the needs of the users. So, I took what I could from the articles on Objectory, filled in the missing pieces and went out into the world to preach the gospel of object-oriented design.Before I left Stepstone, Brad Cox, one of the PPI founders, said two things that I believed then, and still believe. The first was that software was in the same position that gun manufacture was in before the development of gauges to measure tolerances: we have many tools for production but very few tools to measure the results. There was no "reuse" in the gun industry until measurement tools were introduced. The second was, "There is no such thing as object-oriented design, just good design and bad design." These two ideas grew in my training and consulting practice until they overwhelmed the cookbook approach to methodology I was preaching. I had seen the light: software could be treated like other engineered products. I had some confidence that this was a good light because I could make software design look like the chemical plant design I did as a chemical engineer. The evaluation of work products against external requirements has provided a way to objectively resolve many of the differences of opinion about software design issues. The discussions about those differences can sound like the subject is angels on pinheads rather than the design of a high technology product.
The combination of the evaluation idea with my belief in the myth that software can be built from reusable components led to the elevation of the software system architecture from its somewhat obscure position in current practice to the central role it plays here in making software, "hard." A key advance for me came when I realized that the benefits being claimed for object-oriented programming were not benefits to the users of systems, but benefited the people who paid for the development, the development sponsor. The system architecture could serve as the focus designing in extensibility and all those other wonderful 'ilities.
The result is that this book is not a methodology book, nor, even a book about object-oriented design. It was my intension to write a book about "good design" of software systems. I hope that readers will find that to be the case.
We never do anything alone. This work has been supported and contributed to by many people. Brad Cox and Ivar Jacobson have been generous in sharing their ideas with me. Their influence can be seen throughout these pages. It has been said that if you want to learn, teach. That has certainly been my experience. Preparing courses and presenting them to professional developers has been a great education. Being a consultant has given me the chance to see many software products and organizations. My clients have been patient teachers as we worked on the challenges they faced in delivering products.
My editor at Manning Publications, Marjan Bace, has been a gentle, but persistent nudge. His habit of claiming ignorance about software matters before asking pointed questions about how and what I was trying to say has contributed much to this effort. My wife, Pat, has been a very helpful reviewer and a source of suport and encouragement. The foibles, errors and inconsistencies are, of course, all mine. For the good ideas I owe much to the people who have shared their time, energy and ideas with me.
Doug Bennett
February 14, 1996
DESCRIPTION
Have you ever heard, "I can't define a good design but I know one when I see it"? Designing Hard Software discusses ways to develop software system designs that have the same tangibility and visibility as designs for hard objects like buildings or computer hardware. It emphasizes steps called "essential tasks" which result in software specifications that show how each requirement, including robustness and extensibility, will be satisfied. All software developers and managers seeking to develop "hard" software will benefit from these ideas.
There are six essential tasks necessary for a good design:
- User (run-time) requirements
- Development sponsor (build-time) requirements
- Domain information
- Behavior identification and allocation
- Behavior description
- Software system architecture
Designing Hard Software
goes beyond the standard software development methodologies such
as those by Booch, Rumbaugh, Yourdon, and others, by providing techniques
for a complete system architecture as well as explicit measures of the
goodness of design. So, "you "This book is well written ... The author does not fear to be
controversial. In doing so, he writes a coherent book."
Douglas W. Bennett is a Senior Consultant in Methodology Architecture
with IBM. He has used these techniques with many clients in his software
design consulting practice and taught them to hundreds of software
professionals at OOPSLA tutorials and elsewhere.WHAT THE EXPERTS SAY ABOUT THIS BOOK...
--Dr. Frank J. van der Linden, Phillips Research Laboratories
"...a very good job of providing solid examples that most books
lack. You have a best seller here."
--Jess Rico, IBM Consulting and ServicesABOUT THE AUTHOR...