March 93 - Solution-based Modeling: A Methodology for the Rest of Us
Solution-based Modeling: A Methodology for the Rest of Us
Jeff Alger and Neal Goldstein
This is the first part of a two-part article, much of which is excerpted from a
forthcoming book by Jeff Alger and Neal Goldstein. Copyright © 1993 by Jeff Alger
and Neal Goldstein. All rights reserved.
An interesting piece of historical trivia: 30 years ago, three out of four software
projects failed. Either the project was never completed or the original objectives were
not substantially met. A frightening contemporary fact: despite three decades of
supposed progress in software engineering tools and methods, three out of four
software projects today fail.
Three years ago, this and a number of other sour observations about the state of
software methods led us to reconsider the entire subject from basic principles. The
result was Solution-Based Modeling (SBM), a methodology quite different from the
pack in both philosophy and practice. Our philosophy is that methodologies should
concentrate on what most determines whether a software project succeeds or fails:
communications and decision-making. This obvious perspective is often lost in the
roar of technologies, dogma and personalities. We observe that people are actually
pretty good problem-solvers before we get in their way, so we first study how people
best work when left to their own devices, then we figure out how to let them work that
way. From these simple principles the entire method springs.
We described this approach in our book, Developing Object-Oriented Software for the
Macintosh: Analysis, Design and Programming, which, by the way, isn't really specific
to the Macintosh despite the title. We have also taught seminars on SBM around the U.S.
and in Europe and are now starting on a new, updated book on the subject. This article
explores the problems of communications and decision-making in software projects
followed by a brief overview of the methodology and its companion notational system,
the Visual Design Language (VDL). The second part, to appear in the May FrameWorks,
will explore the development process in more depth and conclude with a discussion of
tools soon to be released to support the use of SBM and VDL.
What's the problem?
Before plunging into details of the method and notation, more background on the
problems is in order. Though most people have a gut feeling that these are important
issues, the true nature of the problems is often misunderstood.
Remember the childhood game of "Telephone"? Arrange people at a party into a circle.
Whisper some complex story into the ear of one person, who turns and repeats it in a
whisper to the next person, and so on. The last person tells out loud what she heard,
and the room erupts with laughter. Seldom is the final message anywhere close to the
original (see Figure 1).
We know, even as children, that this is the way communications work. Why, then are
we surprised when the same thing happens in software projects? Communications are
typically extremely poor in software projects. One study concluded that at best we
retain about 50% of the information gathered during a software project. And that was
IBM developing software for NASA, two organizations completely fearless when it
comes to investing in paperwork. The rest of us do, on average, considerably worse.
There are two specific problems with communications in software projects: distortion
and loss of information. Distortion occurs whenever information is conveyed or
translated, even just in the act of reading. Loss occurs under the same circumstances,
but also when some piece of information is not written down.
A parent told us recently of a daughter who came home excitedly from kindergarten and
said, "Mommy, Mommy, I learned how to write in school today." "That's wonderful,
replied the mother. "What did you write?" "I don't know. I don't know how to read yet.
The media we use to document software projects is, to put it kindly, not
people-centered. Comprehension and retention rates for textual documents in general
are awful, on the order of 10%-20%, and rates for typical graphical notations aren't
much better. Think about that for a minute: if you sit down and read a requirements
document, you've undoubtedly missed or forgotten four-fifths of the material. What's
the point?
A graphical notation is not an automatic solution. When we teach our methodology
seminars we run a simple test to drive this point home. We divide up the class into
three, randomly selected groups, then show each group one of three figures for exactly
seven seconds. They then have sixty seconds to attempt to reconstruct what they saw.
Those who see the second version, which is in our own Visual Design Language (VDL)
notational system, do far and away the best. Second, however, are those who see the
textual version. Trailing far behind are those who see the third, sloppy graphic
version, typically recalling little, if any, of what they saw. A bad visualization can be
worse than none at all.
Little wonder that one often hears the lament, "But that's not what I meant" coming
from an end user or product marketing. What we have in software development is
precisely what one would predict, given the methods in widespread use.
Decision-Making
One can identify three specific problems in the way decisions are made in software
projects.
• Decisions aren't made, or a decision is put off so long that only one option
remains by default.
• Decisions are made by the wrong people.
• Decisions are made in the absence of useful information.
This last is a particularly ironic problem, for it is not always the lack of information
that is the problem but the timeliness. For example, features are often cut following
an estimation phase, which, in turn, follows an analysis phase. What's wrong with this
picture? Analysis typically consumes 50% of total development costs. This means you
are throwing out work that is already half done! Decisions are being made during
analysis in the absence of critical information: Are we on, ahead of, or behind schedule
overall? When it arrives, the estimate may or may not be accurate, but it doesn't
matter; it has arrived too late to do any practical good.
Estimation is just one example of decision-making processes that are seriously out of
kilter in most software projects. Valuation, setting priorities, balancing competing
input from inside and outside the team, and dealing with changing objectives and
business environments are all areas in which traditional methods simply don't deliver
in real projects. A related symptom of decision-making problems is a tendency of
project teams, including management, to refuse to face reality. The problem is not just
that decisions are poorly made, but that the process by which decisions are made is
poorly understood.
How People Work
or
What They Don't Teach in 'Methodologies 101'
One of the most remarkable characteristics of the major software methodologies is
their consistency in basic assumptions about how people produce good results.
Consistently wrong. Here is a limited sample:
1. People produce good results working top-down. That is, starting from a
high-level, abstract description, then systematically decomposing into finer
and finer levels of granularity.
2. People produce good results by dividing a problem into distinct,
non-overlapping modules.
3. People produce good results working linearly, that is, finishing one task
before starting the next.
4. People communicate well through text.
Of course, most people know instinctively that these are suspect, yet we continue to
manage software projects on these assumptions. Here, by contrast, is what cognitive
scientists know about the creative design process as the result of solid research:
1. People do not work top-down, even when asked to do so. They also do not
work bottom-up. Instead, they concentrate on what is known as the "basic
level." Below and above this level communications become progressively more
difficult as cultural and individual differences become more and more
dominant and thought processes become fuzzier.
2. People do not partition problems into non-overlapping pieces but rather
perceive situations in terms of many overlapping gestalts.
3. People work non-linearly. They jump from one task or topic to another,
juggling several things in parallel and transferring results of work in one
area to work in other areas.
4. People communicate poorly through text as a rule.
And, we would add the following.
5. People work the way they want to, then make it look like they worked in
the way they were expected to.
Let's draw the logical inference here. If we try to force people to work in an unnatural
fashion, such as top-down or linearly, they won't, but they will translate the way they
really worked into some other form of documentation. This introduces (surprise!)
distortion and loss of information. Artificial processes also lead to poor
decision-making since they tend to take away leverage we use in everyday life. Finally,
processes that require unlearning what Nature taught us about life require high
outlays for training and years of experience, not the stuff of extended teams drawn
from across an organization. Little wonder that there is such widespread cynicism
about software methodologies, particularly among the brightest and most creative!
Historically, it is easy to see how things got to be such a mess. Software development
methods started with programmers organizing their own source code, then
systematically moved out into the worlds of design, analysis, business modeling and
strategic planning. The direction is the opposite of what a Martian coming to study our
methods might expect. If the fundamental problems have to do with extended teams and
communications, one might expect to start by studying those kinds of people, not
programming languages, then proceed gradually in the exact opposite direction until
the results converge on working code. This is exactly what we have attempted to do in
Solution-Based Modeling: reconsider software development methods by starting from
principles of cognitive science, communications, and team management, then derive
implementation strategies from them.
Overview of SBM
Solution-Based Modeling and its companion notational system, the Visual Design
Language, were developed to map well to the way creative people work best while still
allowing management to estimate, schedule and maintain control. The objectives are to
improve communications, decision-making and, as a consequence, the success rate of
projects, chiefly through improving communications and decision-making.
There are three basic components of SBM:
• An architecture that structures analysis, design and programming
information into a series of well-defined models.
• A notation, VDL, that can be used to define and express the models with
minimal loss and distortion of information.
• A process for overall development that pays attention to the needs of all
parties to the project, from end users to management to engineering to quality
assurance and documentation. This includes modeling technology that helps
teach people how to build robust, complete models, alone or in work groups,
and continuous quality assurance structures: algorithms and metrics that
make quality software a consequence of the overall process, rather than the
result of a separate step.
A fourth component, tools, is under development by SBM International and others. We
will briefly discuss what those tools will look like in the second part of this article in
the May FrameWorks.
Architecture
There is growing acceptance in the software engineering community today of the
so-called "multiple models" approach: dealing with a single subject by building many
overlapping models. In SBM, we create a series of models of the following kinds:
• Business models describe the business system that surrounds the
computer system or program.
• Conceptual models are idealized, or deliberately simplified, models of the
content and interface of the program.
• Run-time models describe the running program and ignore
implementation details about how the source code is structured.
• Implementation models collectively are the implementation, expressed as
a combination of source code and design diagrams.
We call these four kinds of models planes and name them the Business, Technology,
Execution and Implementation planes, respectively. Within each plane, we use the
term region to describe one model of that kind. Figure 2 shows the overall four-plane,
eleven region model.
Business Plane
The Business Plane describes the overall business system, including the program
under development, its users, other collaborative programs and computers, and in
many cases machinery, files, and other physical entities. The idea is to produce a
high-fidelity model, one that faithfully describes the real world. To do this, we use
real-world objects, their responsibilities and attributes, and relationships among all
three. Figure 3 shows the basic element and relationship types used in this plane.
Our standard for what is and is not a real-world object is, if you can point to it and
give it a name, it is a legitimate real-world object. That sounds simplistic, but in fact
it is a very useful working definition. Thus, a user would certainly be an object, but
"Time" would not (you can't point to it).
To get started, you might want to think of the term responsibility as synonymous with
the word "behavior." That is, these are the things that the objects do. The term
"responsibility," however, is more useful in business models, as the focus should be
on the desired outcomes or objectives rather than the behaviors.
Real-world objects are described with their real-world responsibilities, data content
and relationships. A Mouse object that is physically manipulated by someone is a good
real-world object, but a Mouse object that is expected to move itself is not. Many
objects have no real behaviors. Take an Employment Record object, for example,
which is just a piece of paper with information on it. It is certainly important to the
business model, but what are its "responsibilities"? There aren't any because it
doesn't do anything. It must be described in terms of its data content (see Figure 4 on
page 58).
The Provides Data relationship here shows that the Payroll Clerk uses the data from
the form, which in turn just sits there doing nothing. In addition to attributes and the
Provides Data relationship, we have two additional relationships, Provides Algorithm