Five Characteristics of a Good Methodology

Remember this was published by 1992, I don't think we've learned anything to better this list in the last 15 years.

1. It Has to Work

The methodology has to work. It should consistently provide high quality software that is on time, within budget, and meets the needs of the users of the software. No other measure of success matters.

2. It Must Allow for Continual Evolution

Since we know that it is futile to try to develop fixed specifications, let's not try. Instead, our methodology should correspond to the way people think and businesses operate: by cyclical refinement. There will be no fixed ending point. Rather, there will be an on-going evolution that never ends, but with points of equilibrium along the way. Release of software will be based on utility of the "intermediate" result, not any notions of finality.

3. There Must be Rapid Turnaround

We know that the software itself will change the need, it is doubly important to start reaping results quickly. No siz-month to two-year turnaround here: initial results should be available in days or weeks.

4. It Must Minimze Distortion

.. popular childhood game called "Telephone," in which a person at one end of a long line of people whispers some complicated story into the next person's ear. That person quickly turns to the next one in line and repeats the story, and so on until the last one in the line tells the story - or such of it as has survived - to the prolonged laughter of the group. Seldom does the end result even resemble the initial story.

This game illustrates an important point: The more people we have involved in developing the software, the more important smooth communication becomes. ... Ideally, everybody involved should be able to explain perceptions and needs in ways that translate directly into software, and should be able to understand the structure of the resulting software without knowing much about computers. Put another way, we need a common lexicon and structure throughout the process of creating software, from analysis to code.

5. The Process Must Be Stable

We should be free to roam through the needs and design of the software, confident that short-term mistakes will be picked up and corrected in due course. It should matter little the order in which we explore the relevant topics. If the methodology is stable, comparable results wil be produced regardless. In particular, we should be able to focus first on central issues. Stability also implies - assuming that the right people are brought into the team - that the oder or manner in which we talk to various participants will at wors affect the time it takes to produce results, not the accuracy of the results. The methodology should not present a canvas on which we paint, but a chalkboard, portions of which can be erased and modified at any time. [GoldsteinAlger1992a]

The Right Way to Design a Graphic Notation

Notations have a long history in computer software, starting with flowcharts and proceeding through structure charts, data flow diagrams...various ways of visualizing objects and classes. However helpful these notations have been, they are quite crude by graphic design industry standards. The authors know this first-hand. They enlisted the help of a professional design firm to help develop a notational scheme for use with SBM, only to endure their amazement and, at times, benevolent laughter over our early, two-dimensional attempts at graphic symbols. [GoldsteinAlger1992b]

I got myself kicked off the early UML design discussion mailing list (OTUG) for taking Booch et al to task for their refusal to consider that they might not be the world's best graphic communicators and should consult some specialists. Sorry, UML users, I tried and a lot of more important people than I agreed but we were stuck with boxes and lines.

Visual Design Language

Unfortunately, I have been unable to find any copies of Goldstein & Alger's Visual Design Language online, other than a couple of figures in [Mattson1994].

The specific graphics are rather moot in this UML-dominated world, however some of their principles can still be applied (note these are Western-oriented visual cues):

1. Centre the most important elements on the diagram.
2. Use size for emphasis - larger is more important in the context of the diagram.
3. Left to right implies time sequence.
4. Foreground-background implies ancestry or time-sequence (note that the concept of foreground only starts to become significant when you have enough 3D-hinting in the diagram shapes).

For a modern, UML-centric guide to such principles, see The Elements of UML Style which as a version 2.0 is recent enough that you can still buy a copy.

Examining the Process

If there's interest, I'll spend a bit more time in another blog entry summarising important points from their process, which is based on:

1. Form Scenarios
2. Calibrate the model - overlapping views of different aspects of the problem and solution space should be made consistent.
3. Centre-Periphery-Calibrate

• Choose a central topic
• blanket it with scenarios
• expand to less central, or peripheral topics

[GoldsteinAlger1992c]

Other links of interest

• Frameworks Magazine 1991 description of a presentation on SBM, [Bamada1991].
• Attempt to get background info for a thesis, including comments by one of the authors, [comp.software-eng1992].
• Comparison of Solution-Based Modelling, Business Object Notation and Object Behaviour Analysis, [Mattson1994].