Solution-Based Modeling: A Methodology for the Rest of Us

Jeff Alger and Neal Goldstein

This article is the second of two parts, 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. The first part appeared in the March issue of Frameworks.

Review From Part I

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.

The architecture and notation were discussed in the first part of this article in the March issue of Frameworks. This part focuses on the process and briefly discusses a fourth component, tools, currently under development by SBM International and others. Extensions to the method are also discussed. Before proceeding, let us review briefly the overall architecture and notation discussed in the first part.

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.

Notation

The Visual Design Language (VDL) was designed in conjunction with graphics design experts and tested to enhance comprehension and retention of information in software projects. VDL emphasizes the use of small, self-contained diagrams called scenarios. An SBM project uses scenarios as the way to capture, communicate and validate business, conceptual design, software architecture, and programming informations. Scenarios typically overlap heavily in content and subject matter. Within any scenario there are elements and relationships among those elements. Provision is made for both static scenarios, in which time is not a factor, and dynamic scenarios that show a flow of action of state over time.

Process

There are four basic activities in a SBM project:

• Creating new scenarios,
• Validating scenarios,
• Programming, and
• Managing the project and library.

Creating New Scenarios

Participants in the team draft a series of simple scenarios, each of which concentrates on a single topic. The overall "model" is, in a sense, simply the collection of valid scenarios gathered during the project. SBM encourages and supports exploration of problems at or near the basic level, rather than using a top-down approach. However, to abandon top-down approaches without a substitute process in place would be foolish, since one still needs defined starting points and controlled, incremental expansion. To address this problem, SBM relies on centrality. Let's revisit the jigsaw puzzle analogy. Once the border is in place, what do you do next? Most people would pick some interesting topic, perhaps a building or a flower, and work on that pattern for awhile. When work on that topic bogs down, one shifts to some other central topic. Eventually, one works out toward the periphery perhaps connecting topics to each other or to the border. Finally, when there is nothing left but blue sky, the final, hard work begins.

This so-called center-periphery strategy is precisely the exploratory process used in SBM. It is such a natural process that it doesn't need to be formally taught; you already use it every day. In fact, even when people are asked to work in other ways, such as top-down, they end up using center-periphery strategies and make it look otherwise. SBM merely provides an environment in which it is safe and politically acceptable to run entire projects this way.

1. Start with a central topic.
2. Blanket that topic with small, overlapping scenarios in several regions of the overall four-plane model.
3. When that bogs down, pick another central topic and iterate.
4. As the model fills out, spend more and more time on the periphery.
5. When the overall structure of the project is well-established, do the fine detail work.

Notice that this not only does not require a top-down process, it also does not force a linear approach. That is, one is free to shift focus from plane to plane and region to region at any time, rather than having to finish one region before starting on the next. This, too, is simply the way people work whether you want them to or not. In SBM, we recognize that fact and design project management strategies around it. This is the essence of the multiple models approach: rather than viewing a problem from one direction only, we continually turn it around in our hand, considering it from multiple perspectives in order to gain a more complete understanding.

VDL and the scenario paradigm are useful in many different contexts, from a software engineer scribbling at a white board to interviews with people outside the central project team to a focus group of typical end users being asked to provide critical feedback to product marketing to briefings for management on the state and objectives of the project. This is not random chance: VDL was specifically designed to appeal to a broad cross-section of team participants and "level the playing field" of communications.

Validating

The process described above releases the creative juices. People are free to follow their creative flow in the most productive way, unencumbered by an artificial process. However, eventually one must return to hard reality: the scenarios and models must be formally validated. To that end, SBM uses a series of validation strategies collectively called calibration.

• Synthesis is used to ensure that scenarios are mutually consistent.
• Correlation assures that multiple models are consistent with one another and each is complete in terms of the other.
• Synchronization tests for completeness and consistency of the final architecture within itself.

Synthesis is a term borrowed from data modeling. Gather a set of scenarios, then compare them pairwise to remove any contradictions that may exist, such as synonyms and homonyms. These and other synthesis problems are really just common sense and most people have no problem recognizing them when two scenarios are laid side-by-side. With a small batch, one can simply spread them on a table and compare them pairwise visually. This quickly breaks down as the number of scenarios grows, so larger sets require the use of a cross-reference index that quickly answers requests such as "tell me all the scenarios in which object X occurs." The database support for this sort of query is surprisingly simple; in our book we describe a simple Hypercard-like database that has been used by a number of project teams to good effect. However, there is no substitute for a good automated tool here and this is a major focus of our own efforts today.

Correlation has already been described briefly: matching up one model with another through the correlation relationships Implements, Replaces and Same As. All, or a clearly defined subset (e.g., the program element of the Solution Model), of one model must be completely accounted for in the other model; in turn, each element of the other model must support some aspect of the original.

Synchronization is a series of five separate tests, all applied rigorously in the Execution Plane to validate the completeness of the run-time model. The synchronization tests are

• Creation, validating that objects and data structures are created before use,
• Destruction, validating that objects and data have not been destroyed prior to use,
• Object Knowledge, that is, demonstrating how an object obtains the address of another prior to sending it a message,
• Connectedness, validating that each method is called in response to some user or operating system event, and
• Protocol, making sure that the calling protocol for methods is consistent throughout the model.

The first three of these are closely related and apply to all collaborations, both for the objects at each end and the inputs and outputs that make up the calling protocol of the method: For each, demonstrate that it was created in time, hasn't been destroyed, and the originating object has the required object knowledge. These tests apply equally to primitive data structures.

In a procedural program, where the branching logic is hierarchical, it is easy to tell when a subroutine cannot possibly be reached. In an event-driven world of graphical user interfaces, it is not quite so simple to tell what is and is not reachable. Enter the connectedness test. A method is connected if it is called in response to some event. Events can include user activities like mouse clicks, operating system events such as timer interrupts, or higher-level events such as messages from collaborative applications. The basic algorithm works as follows.

1. Enumerate all sources of events.
2. For each one, mark the method or methods called directly in response by the operating system or class library.
3. For each marked method, mark its collaborators; that is, the other methods it calls. Apply this step recursively until no more methods can be marked.
4. Find all unmarked methods. These are unconnected.

Unconnected methods may indicate any of several underlying problems: synonyms, vestigal code, missing collaborations, or methods put in place to support future expansion.

The protocol test is also quite simple: is any given method always called with the same formal argument types? This is commonly handled as part of synthesis; if not, it must be a separate step as part of synchronization.

The combination of these five tests, applied to the Execution Plane, is designed to uncover the problems that occur in the worst nightmares of project managers and architects. It has been estimated that 50% of a C++ programmer's time is spent tracking down memory leaks and dangling pointers, the subject of the first three of the synchronization tests. Our own surveys show that these tests address problems typically associated with 30%-40% of the programming phase of a project, and that when they occur there seems to be an unwritten rule that they occur at the eleventh hour and cause maximal damage to class hierarchies, QA test suites, and team morale. What SBM does is take these out of the domain of programming and deal with them as design issues.

We can now complete the center-periphery process described earlier by taking into account the three forms of calibration. The result is that of Figure 4, with frequent iterations at all steps.

Programming

A wealth of detail already attended to, programming in SBM projects is considerably easier than in many other approaches. There are two aspects to programming: designing class hierarchies and writing the code that implements methods. In SBM, classes are designed to optimize the implementation; they are not required to have any intrinsic "meaning." Hierarchies are designed to maximize reuse within the project while also maximizing modularity and independence. The process is basically bottom-up in designing interfaces and both bottom-up and top-down in designing implementations of methods.

1. Group run-time objects of the Execution Plane into concrete types. All members of a concrete type share identical attributes, methods, interfaces and collaborators.
2. For each type, create a concrete class in the Implementation Plane.
3. Look for patterns of similarity among the concrete classes. Where such patterns exist, abstract classes are often formed to maximize sharing of properties across concrete classes.
4. As methods are implemented, differences in behavior, thought not protocol, emerge that lead in the opposite direction: derivation of subclasses that differ in method implementation but not interface.

Managing

In managing SBM projects, everyone on the team should understand at least the following basic subjects:

• Goal-directed phases,
• Prototyping,
• Estimation and the SHP formula,
• Library management, and
• Team management.

Goal-Directed Phases

In classical software project management, a phase is considered complete when some activity is complete. Thus, an analysis phase is complete when one is through doing analysis activities. This is in direct opposition to one of the basic principles of SBM, non-linear workflow. Fortunately, other fields have long used more sophisticated strategies in which phases of project plans are orthogonal to the activities that take place within those phases; we adapt those to the world of software development. For example, when a construction firm builds a bridge, it may go through several phases: site preparation, falsework (the temporary frame prior to pouring concrete), and so on through final cleanup. In each phase, there may be planning, design, construction, supervisory and other activities. One can tell that a given phase is complete when certain objectives have been met, independent of the activities used to get there.

In SBM projects, there are three phases between the time the project is identified and launched and the time of the final QA and shipping cycle: analysis, design and programming. Each of these phases has a defined objective to be reached.

The analysis phase is complete when

1. Someone in authority certifies that the Business and Technology Planes cover all intended scope,
2. All scenarios of those planes are synthesized with one another,
3. The Technology and Business Planes fully correlate to one another, and
4. A credible, detailed project plan is in place for the design phase.

Notice that these objectives do not require working in any particular order within the top two planes of the model. One can freely move around from region to region as long as all regions are complete by the end of the phase. In fact, there is nothing in these objectives that gets in the way of design or programming work during the analysis phase; that is, prototyping.

The design phase is complete when

1. The Execution Plane and Technology Plane fully correlate,
2. All scenarios of the top three planes are fully synthesized,
3. The Execution Plane has been fully synchronized, and
4. A credible, detailed project plan is in place for the implementation phase.

Again, this says nothing about the specific activities used to get there. One will, of course, spend a great deal of time doing design work in the Execution Plane, but there will also be refinement to the upper planes (analysis) and prototypical programming and class design.

The implementation phase is complete when

1. The Implementation Plane and Execution Plane fully correlate,
2. All scenarios in the model are fully synthesized, and
3. All methods have been implemented and passed engineering QA.

During this phase there will be a mixture of programming, design and some analysis activities.

It might seem at first glance that these objectives are internally inconsistent. After all, we said that the analysis phase is not done until the top two planes are complete, yet asserted that during the design and programming phases we would revise the top two planes. There really is no contradiction. During the analysis phase, new ideas and requirements are injected from outside the model. During the last two phases the only changes made to the upper two planes are the result of correlation from below

Prototyping

Putting all this together, we can identify a target plane for each phase. For the analysis phase, the target is the Technology Plane; for design, the Execution Plane; and for implementation the Implementation Plane. This concept of a target plane allows a broader framework for an age-old subject: prototyping. In SBM, prototyping is work below the target plane of the current phase. During the analysis phase, coding is certainly prototyping, but so is drafting design or class hierarchy scenarios. During the design phase, coding and class hierarchy design are both forms of prototyping.

Few methodologies have really come to grips with the problems of managing prototyping. Prototyping is often used as a substitute for analysis and design, rather than a complement to them. In SBM, we provide a sound theoretical and practical framework for prototyping. A prototype is undertaken to help achieve the objectives of the current phase. During the analysis phase, for example, it may be unclear what user interface has the best look and feel, or whether a key algorithm with acceptable performance can be found to implement some concept of the Content Model. In each case, prototyping is in order. We clearly identify the objectives of the prototype, then pick the form of prototype most suited to answering those questions. Prototyping is not an exception to our phases, but rather fits smoothly within them.

Estimation

SBM takes a fresh approach to the whole subject of estimation by returning to a simple basic premise: the purpose of estimating is to provide sound information on which to base decisions. Perfect estimates that arrive too late are unacceptable. Our estimates have to be available early enough to be useful when the most important decisions regarding scope and resources are being made, even if it means using approximations. Furthermore, the process by which estimates are made must be understandable to all, so that every member of the extended team understands the impact their own decisions have on whether the project comes in on time and within budget. Estimation in SBM is based on a simple formula we call the "SHP" (pronounced "ship") formula:

Scenarios = Human Resources * Productivity

Scenarios represent quantities of throughput for the project. That is, we can measure the "size" of a project by counting how many scenarios it creates. This has proven to be an extremely useful metric, much more useful than any other quantification we have considered and a considerable improvement over conventional metrics such as lines of code or function points. Be careful about interpreting this number, however. The number of scenarios is used to quantify all work, not just activities directly related to scenarios. This includes research, interviews, team meetings, coding, and general overhead activities.

Human resources are measured in person-days and productivity is measured in scenarios per person-day. That is, take the number of scenarios drafted, reviewed and calibrated by the team as a whole and divide by the number of person-days during that period. Our studies have shown that productivity is remarkably consistent across team sizes, platforms, even team experience (more experienced personnel simply get more done with fewer scenarios) at about 1.2 scenarios per person-day. The lowest number we have seen is 0.8, the highest 1.7, with a strong cluster centered on 1.2. (Until organizations gather statistics of their own, we recommend a conservative working estimate of 1.0 scenarios per person-day.) This fact makes the SHP formula a useful one for predicting how long a project will take: if you can estimate how many scenarios will be required, you can predict how long the project will take.

We combine the SHP formula with the statistic that 50% of development efforts go toward analysis activities to come up with a unique approach to software estimation. We assume that the estimators are wrong; in fact, consistently wrong. But by sampling a small subset of the estimate, then extrapolating the results to the overall "guestimate," we can converge on a statistically valid estimate for the project. It works something like this.

1. You guess that it will take 600 scenarios to complete the analysis phase, based on adding up smaller estimates for individual topics of the Reference and Solution frames.
2. Sample one or more of those topics by breaking them down into a finer-grained estimate based on subtopics. Suppose, for example, that the sum of the finer-grained estimate for a given topic is 50 scenarios, where the previous guess for that topic was 40. Extrapolate by increasing all other topics by 25%. The new estimate is 750 scenarios.
3. Sample one subtopic by actually doing the analysis work through to completion. Compare the actual number of scenarios, say, 16, against the estimate for the subtopic, say, 12, and extrapolate the ratio of the original estimate to the actual experience. The new estimate in this example is 1000 = 600 * 50/40 * 16/12.
4. Continue to sample in this way until the estimates converge with the samples.

There are a couple of minor subtleties to this process, such as accounting for the appearance of new, unanticipated topics during sampling, but this is the basic strategy. It is quick, reliable, and easy to explain, even to people who have no experience with software development. It also does not rely on completing more than a small sample of the analysis before yielding useful information about the size of the project. For most projects, a good, early estimate can be achieved within two to four weeks of the start of the analysis phase.

Not only is an early estimate possible, but the numbers - scenarios and human resources - take at most fifteen minutes a week to gather as the analysis phase proceeds. This makes it possible to generate a new estimate each week, adjusting scope smoothly each Monday to keep the project on track against its baseline delivery date. Thanks to sampling, features can usually be cut before the investment is made in their analysis.

Library Management

SBM and VDL are designed to make the primary means of documenting a project also the most convenient way for team members to take notes or scribble ideas. That is good, for it minimizes the time interval between creativity and documentation and minimizes the translation needed once information is captured. As we have discussed, this strikes at the heart of communications problems in software projects. This means that much, much more information is captured in paper or electronic form than is normally the case in software projects. We have found it not unusual for a project team to assemble three to ten times as much documentation, measured in terms of pages, than would normally be the case, but without slowing down the project in the process. That is almost a Holy Grail of software engineering. With that benefit, however, comes a cost: simply keeping track of the scenarios and keeping them current and calibrated.

There is no question that managing that much paper or a database that size, depending on the form of automated support used, is a major part of project management.

team Management

No method should be considered complete unless one maps it on to the sorts of day-to-day decisions faced by team members, including project managers. There are two areas of project management that deserve mention here: the structure of the project team and the use of SBM and VDL as a means of addressing classic problems of communications, decision-making and people management.

SBM recognizes the following decision-making roles, or areas of specialization (though in a typical project more than one area may be handled by a single person). This is in addition to overall project management.

• Business Analyst. Responsible for completion of the Business Plane.
• Content Architect. Responsible for completion of the Content Model and Content Architecture.
• User Interface Architect. Responsible for completion of the UI Model and UI Architecture.
• Environment Architect. Responsible for completion of the Environment Model and Environment Architecture.
• Software Engineer. Responsible for the Execution and Program Planes (thus overlapping the three Architects). Decisions are focused on optimization, synchronization, and software engineering issues such as modularity and reuse.
• Project Librarian. In a medium-to-large project, this should be a dedicated position, rather than have everyone do their own cataloguing and calibrating. Responsible for maintenance of the library of scenarios and for seeing to it that calibration is done completely and at the right time.

In each case, these are the people who are accountable for seeing to it that the work in their respective areas gets done, even if they do not personally do all the work. They also should carry the authority to make final decisions in those areas. These roles correspond to the sorts of skill sets commonly found in a single individual. They also concentrate related areas of decision-making.

Productivity is constrained by many factors, but at the top of the list are interpersonal, team-centered issues. We wrote earlier of the dominant personality problem: an individual with strong verbal skills and an aggressive personality often dominates project decision-making, all out of proportion to differences in skill level. VDL helps level the playing field by diminishing the roles of both verbal skills and personality. Anyone can learn to use VDL quickly and calibration demands that everyone's input be accounted for.

SBM and VDL also make it feasible for people to work separately or in teams of two, then integrate the results. This is otherwise difficult to do because the media of expression are not formalized enough to support the equivalent of synthesis. As a result, more decisions are made in group settings than is really healthy or productive. In SBM, we recommend a process we call "come together-break apart": one hour per day the team meets as a group to review work done by each other and identify and prioritize needs for new work. In the remaining time, team members work individually or in teams of two, resolving To Do items from scenarios already done. Breakout sessions are also used to revise work based on group feedback, catalog it, and calibrate. This process is not only more efficient than group meetings, since in a group only one person can (or should) be talking at a time, it also leads to better decision-making.

During group sessions, a printing white board is invaluable. It is used to sketch VDL scenarios - and the all-important To Do lists - as the group deliberates. More than a medium, it becomes a means of reaching agreement. Whoever holds the marker has a finger hovering over the "print" button and says, "Are we agreed? Going once… going twice… print!" Everyone in the room knows that agreement was reached and gets a copy of the result. VDL facilitates this because the medium is consistent, not the result of individual style or whim.

The estimation strategy outlined above makes possible a new model for accountability in software projects: the extended team, including engineers and non-engineers, is jointly responsible for meeting the deadline for completion of the analysis phase. The engineering team is then responsible for completion of the design and implementation on time. This seemingly simple change has a profound impact on the quality of decision-making.

These may sound like common sense or even trivial matters, but they are not. These sorts of issues are very important to the success or failure of entire projects, and are therefore not just petty interpersonal issues. SBM and VDL greatly facilitate the basics of people management: communicating, reaching agreement, making team productivity as close as possible to the productivity of one person times the size of the team. We are amazed at the lack of attention these issues have received in other methodologies given their impact on outcomes of projects.

Extensions to the Basic Method

SBM is actually a special case of a more general approach to managing change. For example, there are straightforward extensions that handle the full maintenance lifecycle, distributed systems, and large projects broken down into smaller subproject teams. It is also relatively easy to extend the approach to support future object-oriented frameworks that will not have clear boundaries between "applications," but rather what we call "object soup:" objects firing messages off to other objects without regard to application-level protocols.

We have also heard from a number of people who have been using SBM and VDL purely for their strength in business modeling, even if no software development is under consideration. The techniques of visualization, communication, decision-making and validation are as important for introducing change to businesses as they are for systems development projects. In fact, we view this as the largest future market for the SBM approach.

Finally, because of the modular, scenario-based form used to express analysis and design, SBM and VDL make it practical to reuse analysis and design scenarios across projects. With all the hoopla about reuse of code (notable for the lack of real success), a simple fact seems to have been forgotten: most of the money spent on software development is spent on analysis and design, not code. At this time we are working with several organizations on repositories of analysis and design scenarios to be used across projects. We also feel this presents an opportunity to create an entire new industry: production and sale of analysis and design "packages."

Automated Support

SBM and VDL can be supported with an extremely simple database, one that can be assembled in under a day with any consumer database product. Many SBM projects have been run completely manually, though not without a good deal of grumbling. Clearly, though, SBM could benefit from good, automated support.

The least important problem is graphic support, that is, drawing pretty pictures. This occupies a small fraction of the overall human resources in a SBM project. Instead, the focus should be on two issues that do take up a lot of time: calibration and browsing. The browsing is particularly important, answering such questions as "show me all the scenarios in which object X appears" or "show me all the responsibilities (or collaborators or parts…) of object X across all scenarios."

It is also important to maintain the basic principles behind SBM: non-linear and non-hierarchical flow, multiple models, visual communication, and defering calibration until creative flow has slowed. This combination has made it difficult for CASE vendors to support the methodology to date. ("Of course, we'll have to get rid of the 3D notation, divide everything up into three different tools to be used linearly, constrain the use of VDL to well-defined syntax, and otherwise change it all around, but SBM is great and we'd like to support it!") Despite this difficulty, we have recently been approached by several CASE vendors about proposed extensions to their products. As SBM continues to grow in popularity we expect this trend to continue until SBM is widely supported.

In the meantime, SBM International will soon be releasing a series of tools specifically designed to support SBM. As of this writing, the first of these tools , the VDL Companion™ modeling tool, is in beta test and should be in final release by the time this article is published. Higher-end products are being worked on that will support calibration algorithms (VDL Professional™) and multi-user repositories (VDL Teamware™). These are designed to maintain the spirit of SBM and VDL: non-linear, visual, non-hierarchical and supporting very flexible use of VDL for introducing new idioms.

SBM International provides consulting, training and tools that support the use of SBM. For more information, contact the authors at (415) 424-9400, FAX (415) 857-0198, or at 3124 South Court, Palo Alto, CA 94306.