| Designing Hard Software The Essential Tasks Douglas W. Bennett 1996 | 350 pages ISBN: 133046192 |
|||
RESOURCES
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. Chapters 1 and 2 of Designing Hard Software are available for download.
Each chapter is contained in a single ZIP file.
Free unzip programs can be found at www.download.com.
Software, which has does so well in standardizing and automating other
industries, is having trouble repeating that performance in its own
industry. The growth of productivity and product quality has been less in
software as compared to, say, electronic hardware or automobiles. Why so?
Some answers that have been voiced over the years include the following:
software is intrinsically complex, software is an art, or software
requirements change too fast.
If we look into how people develop software, we can see some things that
contribute to the view that software is complex and not at all like those
other kinds of products. Some comments and observations that I have heard
include the following:
Those methodologies and all that design documentation just get in the way
of the real work. - a programmer
Have you started coding yet, and When will the code be finished? - a manager
The development team for a system that will be implemented on a
client-server hardware architecture is responsible for everything from
nested case statements to ensuring that the system achieves the required
transaction throughput rates. - a project plan
I can code it from scratch faster than I can figure out what the existing
component does and modify it to do what I need. - a programmer
Our system architect has an advisory role on the project. - a developer
We don't have a system architect, but we encourage the various development
groups to talk to one another. - a project manager
Software developers who hold the views implied by these comments produce
software that can be accessed only through its source code or as a running
system. Programmers looking at source code can only see programming
language constructs. These constructs-functions, instances of classes,
etc.-are quite small relative to the size of most systems, so looking at a
software system in terms of its code makes it very difficult to see any
larger scale structures in the system.
Looking at just the trees makes it hard to see the forest.
I believe that the lack of a view of the larger scale structures of
software systems is a major contributor to the apparent complexity commonly
ascribed to software systems. Residential house design and construction
would look intrinsically complex if they were viewed from the level of
hammers and nails. Most carpenters, of course, work to a plan developed by
an architect. They can easily see the larger structure of the house in the
architect's plans. They even have the luxury of being able to step back and
looking at the complete structure. A software developer working without an
architecture diagram does not have that luxury. The result is that much
software looks like a house built without a plan by several carpenters who
did not talk to one another.
When most software development organizations wish to improve the quality of
their products and the economics of their process, they often turn to
software development methodologies. Methodology writers, or their case tool
vendors, promise wonderful things to those who use the methodology. Yet, it
appears that someone in the organization believes the promises, given the
time and money invested in selecting and deploying a methodology in some
organizations. There is often considerable energy invested in selecting
which one will be used because the methodologies are mutually exclusive. A
shop that uses structured analysis can hardly be expected to use Booch at
the same time.
It's hard to cook a banquet with just one recipe.
There are indications of problems with the process of adopting a
methodology. These problems have to do with the apparent inflexibility of
most methodologies. Thumb through the pages of any book on software
methodology and you will see a great many diagrams and documents being
called for. Listen to an enthusiastic adherent of the methodology and you
will get the impression that all the documents should be produced in every
project. However, if you compare the number different documents called for
in most methodologies with the much smaller number of document types
actually produced in most development organizations, you will see one of
the problems with adopting a methodology.
On the other hand, there are problems with the ability of software
methodologies to adequately describe the process of developing software. As
I will show in the chapters on the architecture and development processes,
software systems are composed of a hierarchy of products and subproducts.
Each product needs its own set of multilevel processes. Software
methodologies, on the other hand, sound much like a single level, single
thread process.
So, we have a situation where the source of guidance for process
improvements that organizations turn to-methodologies-does not appear to be
well suited to provide that guidance. On one side, the process they
describe is too far away from the current practice of software development
to be readily adopted. Experience from the Total Quality movement in the
manufacturing industries tells us that large, step changes in process and
culture are not feasible. On the other side, a single methodology cannot
adequately describe the multi-product, multi-process development universe
needed to deliver complex software systems.
The Situation in Hardware
How do those other guys do it?
In the discussion of differences between software products and other kinds
of products, I will refer to the other products as hard products. Hard
products seem to have some advantages over software in the areas of
manageability of both the complexity of the products and of the process for
developing them. Experience with hard product development indicates that if
hard products were treated with the same processes and practices used in
software, then hard products would also appear to be intrinsically complex,
product quality would be highly variable, and the process would be
expensive and labor intensive. I believe that the converse is also true. If
software were treated with the same processes and practices as are used in
the hard product industries, beginning with the essential tasks I will
describe in this book, software would begin to look more like a hard
product and be more manageable.
It is interesting to ask what hard products have that software products do
not. There are three things that are common in hard product development
that would be very valuable to have in the software industry. These include
a tangible representation of the product structure, flexible development
practices and measurements to determine if the desired attributes have been
designed into the product.
Product Structure
If you ask a building architect about his current project, you will be
shown a few drawings of floor plans and elevations of a building. The
diagrams will define the static structure of the complete building. The
architect will be able to describe how the occupants of the building and
their equipment will be facilitated in doing their jobs by the building
structure. The architect's drawings will not show the occupants, the
structural steel, the mechanical nor the electrical views of the building,
but there will be room in the structure for all those things. The
architectural diagrams of the building define the single structure that
will be built. All of the uses and views of the building are accommodated
within the physical structure.
Flexible Development Practices
New products like a reduced instruction set for chips, carbon composites in
aircraft frames or ceramic engines in cars start out as ideas. When an idea
is proposed it is often investigated with informal design studies to
uncover feasibility problems and to determine the economic potential of the
new product. If the economics look good, but there are feasibility
problems, a prototype may be designed and constructed to resolve the
problem. More detailed design studies may be carried out to get a better
handle on costs and risks, and finally production prototypes maybe designed
and built to work out production details.
A whole cook book of recipes.
Engineers of hard products have a well-stocked tool box of design
tools-notations and the techniques to apply them-they can use as the
situation warrants. These techniques range in formality from
back-of-the-envelope techniques to formal, mathematical simulations of the
product design. If the question to be answered is along the lines of, "is
it bigger than a bread box?" then informal techniques would be appropriate.
If the question is, "can we reduce the weight by 2% and still provide the
safety margins?" then a very different, more formal set of techniques would
be used. Having this set of techniques means that questions that arise at
any stage of the product's life cycle can be answered effectively and
efficiently.
Measurements
The term reuse is not used in the hard product industries like the
integrated circuit and aircraft industries. Instead, subsystems are bought
or built. Standard components, from light bulbs to jet engines are used.
This was not always the case. Consider the problems designers faced when
trying to develop reusable machine parts. Brad Cox has pointed out [COX89],
that Eli Whitney tried, and failed, to produce reusable parts for guns.
Congress tried for 50 years to get interchangeable parts for their guns.
These and other efforts failed until gauges were developed to compare the
tolerances of the parts during manufacture with the tolerance specified in
the design.
Two things are needed for measurements to contribute to reuse and other
attributes of product quality: one is a way to measure the property of
interest, the other is a goal for what values of the measurement are
acceptable. Having tolerances for parts and a way to measure those
tolerances was essential for developing "reusable" machine parts. Lately,
more esoteric properties of hard products have become important, such as
maintainability. Having acceptable levels of this property in hard products
requires that the product be explicitly designed to be maintained, that
measures are available to confirm that the maintainability is expressed in
the design documents and is manifest in the product.
Goals, building tools and measuring tools.
These three features of hard product design: a way to represent the
physical structure of the complete system; a flexible set of design tools;
and design goals for specific properties and measures of those properties,
would be very useful if applied to software product development.
Software as a Hard Product
Goals, building tools and measuring tools work in software, too.
The Hard Software in the title comes from applying these three features of
hard product development to software design practices. In fact, it is
possible to treat software development like hard product development and
end up with a product that is tangible, visible and amenable to the same
kinds of design goals and evaluations that are used in hard products. Many
of the techniques and diagrams for doing this already exist in the software
development domain. We need only a few additions and a slight attitude
adjustment to make the change.
Software System Architecture
In Chapter 1, an architecture for software systems is proposed that
consists of subsystems, channels and the boundary of the system. To make
the subsystems tangible, they are enclosed in existing implementation
containers. The different levels of implementation containers have a strict
contained-in relationship with one another, so the software subsystems have
the same contained-in relationships with each other. This software system
architecture definition provides a medium for designing in the emergent
properties of the system. Emergent properties include extensibility,
maintainability and any others that depend on the whole system for their
expression. The subject of software architecture definition is discussed in
Chapter 1 and the process of developing the architecture diagram is
discussed in Chapter 9.
A Tool Box of Design Techniques
The problems of methodologies appearing to be both too big and too small to
describe an effective process are addressed by separating the individual
design techniques from the application of those techniques. A set of tasks
based on the category of work product they produce is proposed. Together,
these task categories, called the Essential Tasks, are sufficient to
document the design of software systems from need through the system
architecture. They address all of the essential properties desired in a
finished product. The definition of Essential Tasks and their relationship
to methodologies and to real practice are covered in Chapter 2. Each of the
individual tasks gets its own chapter and a chapter of examples.
Measurements and Evaluations
As you recall from the earlier discussion, measurements were the missing
element that, when developed, enabled machine parts to be reusable.
Software developers are struggling with quality and reuse issues right now,
probably for the same sorts of reasons that congress and Ely Whitney
struggled with reuse: a lack of measurements. Having complete, quantified
goals for all the properties desired in a system, and measuring the design
documents to see that the properties are, in fact, designed in, are
critical to delivering software systems that express the properties. To
that end, a set of Basic Principles of Evaluation are described in Chapter
2. These principles are used to guide the application of each of the
Essential Tasks. In the chapter on Essential Tasks we will see how
application of the Basic Principles could lead to a structure of software
products that looks just like the structure of electronic hardware:
individual products defined at a single level of implementation unit.
Documenting external goals and using those goals as explicit evaluation
criteria for design documents represents the biggest departure in this book
from current methodology instruction. It is also the most important idea in
the book. If you only take one thing from this book, make it the idea of
evaluations against external goals. If you have these measures in your
design practice, you can detect and fix problems of inappropriate notations
and bad design decisions. Without these measures, you will have no way of
knowing whether those elusive properties of maintainability or reuse are
actually present in your design.
This book describes the tools in the engineer's tool box and how to use
each one individually. The topic of applying the appropriate tools in
useful sequences in various situations is mentioned briefly in the
Essential Tasks chapter, but the details are outside the scope of this book.
The Audience
Developers, engineers and managers.
The intended audience of this book includes the people I have dealt with in
my training and consulting work. These people are professional software
developers and their managers who work for, usually, large organizations.
They are responsible for the form, content and production of the software
products that their organization depends on. Their current development
practice is usually rather informal. Both the managers and the developers
of the organization recognize the need to improve the quality, economics,
reuse, maintainability, and flexibility of their software products. There
is usually wide-spread agreement that an important aspect of improving the
product is to improve the process and practice of designing the software.
There is usually wide-spread disagreement on what procedures to change and
how much time should be devoted to the changes.
For designers and engineers, this book can help them improve how they carry
out their design tasks. In, particular, I think the evaluations could
profitably be added to most existing tasks. Any of the essential tasks that
are not part of the current practice could be added.
For managers concerned with improving an invisible process, I believe that
the evaluation aspects of the tasks provide an opportunity to make the
development process, itself, more visible and tangible. The details of what
diagrams get drawn are less important than the demonstration that the
decisions documented in the diagram effectively address the external
requirements.
For methodologists selecting the "corporate methodology" the essential
tasks offer a basis for comparing and integrating existing methodologies.
The essential tasks help get beyond comparing methodologies using names of
the steps and diagram types.
Structure of the book
The chapters and their contents include:
What is architecture and how should we evaluate it.
This chapter includes a brief survey of the literature on architecture of
software systems. It then defines a single, physical architectural
structure for software systems in terms of hierarchies of subsystems, each
contained in a physical boundary. The subsystems are defined with existing
implementation components such as OpenDoc, heavyweight process, processor,
board, node, and cluster of nodes. This representation of the software
architecture corresponds directly and tangibly with the physical software
system.
Essential Tasks in the Practice Universe
Use separate levels of tools and practices.
This chapter describes the practice universe as all the things that must be
done to deliver economical, timely and successful software systems. There
are hierarchies of activities and processes. Down toward the bottom of the
hierarchies are the practices and processes associated with the engineering
of single software systems. Below that are the Essential Tasks that inform
and constrain those engineering practices as shown in Figure 1.
In this chapter, the Essential Tasks are described and their role in the
practice universe is discussed. That role includes serving as a basis for
comparing and unifying existing methodologies. How they can be applied in
developing common architectures across related products is described.
Common architectures are the necessary prerequisite for component reuse.
The Essential Tasks
A chapter of examples follows each chapter.
The remainder of the chapters of the book contain instructions and examples
for each of the essential tasks. The tasks follow in order dictated by
their information dependencies. They are as follows:
The External Requirements Tasks
External Requirements Example
The System State Task
System State Modeling Examples
The Behavior Description Task
Behavior Model Examples
The Software System Architecture Task
Architecture Examples
Conclusion
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...
Sample Chapters
Introduction
The Situation In Software
The tasks fall into two groups: documenting the external goals and
properties the system is to provide (Chapter 4), and making decisions about
how the system will do that (Chapters 5, 7, 9.) As you can see, each
chapter is followed by a chapter that illustrates the concepts using an
extended example. The extended examples contain useful illustrations of
notations, and discussions of evaluation processes.