Hi all

There is a lot of interest in the software design community in the
strengths and limitations of approaches such as Dialogue Mapping and
support tools like Compendium, for supporting their work by
improving/recording Design Rationale, the reasoning behind decisions.

Right now, I am working on a chapter for a new book that is in
preparation:

"Rationale Management in Software Engineering" (Eds.) Allen H. Dutoit,
Raymond McCall, Ivan Mistrik, and Barbara Paech.
Springer-Verlag/Computer Science Editorial

I would very much like to hear from you if you have a real example of
Dialogue Mapping +/or Compendium giving you benefits against any of the
following list of desired benefits one would hope for from 'the total
Design Rationale (DR) capture system. Feel free to send
stories/screenshots/references, to just me, or the whole list to
promote greater awareness.

Many thanks

Simon


1.1 Uses of DR and DR methods
There are many potential uses of DR, some aimed at improving the design
process, others at improving other phases of the artifact life cycle.
The most frequently proposed uses are listed below. Note that there are
some overlaps and dependencies among items in this list. We group them
into four main categories: the first focus on collaboration, the second
on reuse and change, the third on quality improvement and the fourth on
knowledge transfer.
1.1.1 Supporting collaboration
1.1.1.1 Promoting coordination in design teams
DR can help to coordinate many aspects of a design team’s work.
Different members of a team can use a common repository of DR to
understand what others in the team are doing and what the consequences
are for their own work. This can promote the identification of both
potential conflicts between team members and opportunities for mutual
support.
1.1.1.2 Exposing differing points of view
One use of DR is to expose differing points of view. Sometimes these
are merely differences of opinion on detailed issues, but sometimes
they are also profound differences of worldview on fundamental topics –
e.g., open-source vs. de facto commercial standards. Sometimes they
arise from differences in domain expertise in a functionally
differentiated design team. Sometimes they arise from the different
goals of different stakeholders in a project. Exposing differing points
of view and the reasoning behind them was a central goal in Rittel’s
use of IBIS. Not all DR approaches expose differing points of view.
Some promote a rapid convergence on a consensus that can conceal
differences.
1.1.1.3 Facilitating participation and collaboration in design
DR can be used to promote both collaborative and participatory design.
Rittel argued that participation by users in design is often inhibited
because they do not understand what rationale designers are using –
what questions they are addressing, what alternative answers they are
considering, what arguments they are using. He looked at IBIS as a way
of making designers’ reasoning transparent, i.e., a glass box rather
than a black box, and thus empowering users to ask questions and to
make comments and suggestions. Similarly, he saw collaboration as also
being inhibited when members of a design team did not understand the
rationale being used by other members. DR approaches other than IBIS
can also be used this way.
1.1.1.4 Building consensus
Some DR methods help in reaching consensus and making decisions. Many
users of IBIS have complained that it lacks adequate means for
promoting consensus and reaching decisions. Other DR methods might be
better for creating consensus for the simple reason that they do not go
to such lengths as IBIS goes to promote debate.
1.1.2 Supporting reuse and change
1.1.2.1 Supporting future changes
The most commonly mentioned reason for using DR in software engineering
is to support future changes in software – a problem that is perhaps
more pressing in this field than in any other design or engineering
field. This does not necessarily require a prescriptive approach to DR.
This goal might be well served by approaches that merely record what
designers happened to think. People who want to make future changes
need to understand the effects of those changes; knowledge of the
rationale for the design can help in achieving that understanding.
Sometimes that rationale may also reveal that some planned changes are
actually inappropriate. It is not uncommon that a design feature that
seems wrong to a new designer was originally arrived at through a
painful process of trial-and-error in which the “intuitive” approaches
all failed. Without a record of the rationale, this painful process
might have to be repeated – perhaps many times.
1.1.2.2 Supporting re-use
Software re-use is considered by many the “holy grail” of software
design. But before software can be re-used it often needs to be
understood and/or modified. This in turn requires that the reasoning
behind its original design be known. DR can also help to identify parts
of software that might be extracted and re-used.
1.1.3 Improving quality
1.1.3.1 Increasing consistency of decisions
Often it is only by making rationale explicit that consistency can be
achieved. For example, it is not uncommon in large projects for the
same decision tasks to be done by different groups within the design
team. Recording rationale makes it easier to identify this fact and to
make sure that decisions are mutually consistent. This use of DR is
prescriptive, for it seeks to change the way designers think – i.e.,
making it more consistent. Though this use of DR requires methods that
go beyond mere historical description of designer’s rationale, such
description may be of value because it exposes designers’ reasoning to
critical scrutiny.
1.1.3.2 Verifying designs (supporting traceability)
This use of DR requires an explicit linking of requirements criteria to
the descriptions of artifact features that satisfy these criteria. In
the case of software, it also suggests the desirability of linking the
criteria to actual features of the implemented software. At very least,
this traceability requires a DR approach that makes criteria explicit –
as QOC and DRL do – rather than approaches where criteria are implicit
or imbedded in larger arguments – as is the case with IBIS.
1.1.3.3 Supporting maintenance
One possible use of DR is to support debugging, fixing problems and
extending the functionality of an artifact. This problem is probably
more critical with software than with any other type of artifact. DR
can be used to spot conceptual errors in design as well as
implementation errors, and errors of omission as well as errors of
commission.
1.1.4 Supporting knowledge transfer
1.1.4.1 Learning from the past
To learn from the past we need to understand the reasoning behind past
decisions. Most DR researchers maintain that this can best be done
through explicit recording of the rationale for those decisions –
something that requires nothing more than a descriptive model of
whatever it was that the designers were thinking when they made
decisions.[23], however, have presented evidence that designers are
often able to effectively reconstruct the rationale for past designs
from data other than an explicit record of rationale. These authors
even suggest that it may be more useful to record such data rather than
the rationale itself.
1.1.4.2 Validating designs
To maximize learning from the past, we need to be able to compare
designers’ expectations about the consequences of their decisions with
the actual consequences. This requires more than an understanding of
the reasoning behind past decision; it requires evaluation of artifacts
in use. One approach to doing this is found in Case Based Reasoning
(CBR) projects by Kolodner [29]. Especially interesting is the ARCHIE
project, which records the experiences of users of artifacts
(buildings) and links these experiences to representations of the
artifact.
1.1.4.3 Organizing and delivering re-usable knowledge
The issue of learning from the past is also fundamentally connected to
the re-use of knowledge. Re-use can be thought of not only as using the
successful ideas and rationale from the past, but also a matter of
preserving records of what not to do. There is no point in re-inventing
the wheel, but it makes even less sense to re-invent the square wheel.
Thus, the blunders of past designers represent an important type of
re-usable knowledge.
There are two basic approaches to the re-use of knowledge: the
case-based approach, described above, and what we might call the
generalized approach. The latter term is intended here as an umbrella
term for a number of approaches that try to put knowledge in a
generalized form that goes beyond the mere annotation of individual
cases. There are currently a number of generalized approaches,
including patterns and issue bases.
Patterns, as used in software engineering, constitute one of the most
heavily used approaches for organizing re-usable knowledge. Integrating
rationale more completely into such patterns could be an important way
of making rationale re-usable. The patterns used in software
engineering ultimately derive from Alexander’s concept of pattern used
in his work on architecture and urban planning [1]. This pattern
concept has rationale explicitly built in, though this rationale is
relatively unstructured.
To date, domain-oriented issue bases have only been created in the PHI
version of IBIS. Such issue bases contain hierarchies of issues,
positions and arguments that are commonly raised in a project in the
given domain. Most of the issues are left unresolved and designers are
invited to make their own minds up on the issues. Wherever the software
technology permits, issue bases are extensible by designers, who can
add to them and even edit them for use in specific projects.
1.1.4.4 Supporting training
One use of DR is to bring new members of a design team up-to-date on
what has been done to date. DR can function as a sort of larger-scale
version of an FAQ, so that a new member can understand the rationale
for the current state of the artifact’s design before suggesting
changes in it.
1.1.4.5 Providing external design memory
A related use of DR is as an external memory aid for members of a
design team. This is especially important where projects go on for long
periods of time and where designers leave the team. It is very
important when designers leave a project that all knowledge of their
project rationale does not leave with them.


::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Dr Simon J. Buckingham Shum
Senior Lecturer, Knowledge Media Institute, The Open University
Milton Keynes, MK7 6AA, UK

Tel: +44 (0)1908 655723
Fax: +44 (0)1908 653169 [office]
eFax: +44 (0)870 122 8765 [direct]
Email: sbs@...
Web: www.kmi.open.ac.uk/sbs

"All models are wrong, but some are useful"      W. Edwards Deming
Compendium: hypermedia sensemaking    www.CompendiumInstitute.org
 Modelling the Iraq Debate: www.GlobalArgument.net