Simon,

Jeff Conklin has a new book coming out about dialogue mapping, and I
don't know whether he discusses your list of uses or not, but your
could touch base and ask him. He might be willing to share content on
some basis. I know he has done a lot of work in dialogue mapping with
Southern California Edison.

Regards,
Eric
On Aug 10, 2005, at 3:25 AM, Simon Buckingham Shum wrote:

> 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
Eric H. Brachhausen
Vice President
American Technology Alliances
499 Seaport Ct., Suite 100
Redwood City, CA 94063
Phone: 650-569-3838, X3
Fax: 650-569-3839
Cell: 650-207-5110
Home: 510-793-3791
Email: brock@...
URL: www.amtech-usa.org

"Imagination is more important than knowledge." Albert Einstein