NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/software/3215

Text File | 1992-08-14 | 8.6 KB | 163 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!seas.smu.edu!vivaldi!aslws01!aslws01!terry
From: [e-mail] (Terry Bollinger)
Subject: Re: Do you use SADT ?
Message-ID: <[e-mail]>
Keywords: SADT
Sender: [e-mail]
Nntp-Posting-Host: aslws01
Organization: NEC America, Inc. Irving, Texas
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 14 Aug 1992 15:54:15 GMT
Lines: 149

In article <[e-mail]>
[e-mail] (Ralph Johnson) writes:

> A decade or so ago I spent several months trying to figure out SADT,
> and decided that the documents that were supposed to describe it didn't.
> Where does one go to learn it?  Also, if it is so wonderful, why don't
> more people use it?

INFO ON SADT

Best book on the subject that I'm aware of is:

   D.A. Marca and C.L. McGowan, SADT: Structured Analysis and Design
   Technique, McGraw-Hill, New York, 1988.

This book discusses the type of process-oriented uses of SADT that Bob
Munck of Unisys mentioned yesterday.  Clem McGowan, Shawn Bohner, and I
used SADT extensively -- and quite successfully -- in process assessments
we performed in the Federal Systems and Telephone Operations components
of Contel.  I was originally somewhat skeptical about the SADT method, but
that changed quickly as Clem demonstrated how extraordinarily effective
the method is for recording and verifying process-level information.

Clem and I developed a quite brief (2-page, one graphical, one bullet text)
description of the basics of SADT that we included in each of our Contel
process assessment reports.  By emphasizing the *simplicity* of the basic
SADT methods (vs. a large set of additional detail that is available if
needed), we seem to have greatly reduced the "intimidation factor" greatly
and helped people realize that such diagrams are remarkably easy to learn.

The SADT documentation problem is probably one of the reasons why SADT did
not compete well years ago against other structured methods.  (I'll ask
Clem whether he can provide any insights on the issue, and will post any
relevant response from him.)  Also, the focus on *process* as sort of
thing best handled by SADT methods is (I believe) relatively recent, and
was probably not well recognized (if at all) ten years ago.

SADT AND PROCESS ANALYSIS

For verifying and solidifying your understanding of the current process
(whether software or any other type of industrial process), you really
can't beat SADTs, because essentially NO explanation is needed.  As soon
as people saw the diagrams with the names of their own activities, products,
controls, and resources on it, understanding was darned near instantaneous.
Because they *knew* those components and names, they had no trouble figuring
out what was being said, pretty well regardless of educational background
or whether they had ever used such diagrams before.

The effect of immediate understanding by people within the process is what
makes SADT so great for verifying the process model -- usually within five
minutes of the first review, people would be making all sorts of detailed
comments about details of the model, missing items, wrong connections, etc.
By the time you were done the verification reviews you could not help but
get the feeling that your model was SOLID -- and at the same time, that you
had built up a really good working relationship with your customer.  You
cannot underestimate the importance of having people feel that you truly
understand what they do when your goal is process improvement -- it makes
people far more likely to take improvement suggestions seriously and work
hard to implement them, since they have greater confidence that you have
truly understood the current problems.

Perhaps the most telling point about the value of SADT for use in process
improvement is that people would *spontaneously* make copies of their
SADT process model diagrams and post them on their walls.  People LIKE
the idea of knowing how they fit into their overall process -- it tells
them who they are, why their work is important, and who they need to
interface with.

EXAMPLE OF SADT PROCESS ANALYSIS

Incidentally, our work with SADT at Contel did not end with application
of the original methods.  We also developed some new concepts of process
efficiency that were based on the idea of minimizing "lost work," which is
much like Boehm's "rework" metric, but a somewhat different emphasis.  We
would look at process models in terms of risks that they might result in
large chunks of work being thrown out needlessly, then restructure them
in ways that either eliminated or at least drastically reduced the amount
of work lost.

Example:  One project that did not involve testing until very late in the
process always seemed to wind up losing a lot of time and effort whenever
they transferred products from development to testing.  The problem was
that the testing group simply could not prepare the needed test environment
quickly enough after the transfer, and both the developers and testers would
wind up losing a lot of earlier work as they scurried to "fit together" a
product and test environment that were not designed in concert.  No one
recognized the problem because both testing and development kept pointing
their fingers at *each other*, not realizing that the problem might be
a bit broader in nature.

After we built the SADT model for this process and reviewed it with them,
things started to change quickly *and spontaneously* -- we did not even
have to tell them what was needed in some cases, because the model itself
provided them with the insights they needed.  To solve the above problem,
they created a new information flow from the requirements review activity
to the testing activity -- meaning simply that they had someone from the
test group start participating in the early-phase requirements reviews.
The addition of this flow allowed the test group to have critical info
that it needed to prepare test environments in time, and also helped the
developers by allowing some highly valuable and work-saving comments from
test-oriented people to be added to the development process *before* the
critical design decisions were made.

The look of little light-bulbs coming on in peoples heads was great to
watch.  By looking at the process as a whole, they had realized that the
problem that had people in development and testing ready to scream at
each other was really a process-structure problem, *not* some kind of
mutual personality problem.  The SADT process model had permitted people
to think in terms of constructive solutions, instead of just repeating
old complaints without seeing any way to resolve them.

SADT AND "LOST WORK" PROCESS ANALYSIS

In terms of graphical methods and potential extensions to SADT, issues
of how and why work is lost can be shown in terms of "shrinking" loops
that represent work is lost due to backtracking later in the process.
For a design process, you cannot completely eliminate such loops, but
you CAN shrink them by splitting activities into two parts:  a "trial"
part that focuses on isolating or splitting the design problem, and a
non-looping development activity that has been "secured" by the results
of the much smaller loop.  A lot of widely recognized "good practices"
in software development -- e.g., early verification of requirements and
certain types of prototyping activities -- are easily recognized as
specific implementations of this type of loop-reduction activity.

REFS:

pp 35-37 of "A Critical Look at Software Capability Evaluations" (IEEE
Software, July 1991) has a box article on lost work analysis, with an
emphasis on risk issues.  That box article also discusses the difference
between design and replication processes.  (Acronyms and terms used in
that box article are subject to change without notice in future articles/
books on this subject, but our basic concepts given there are quite stable.)

A very brief summary of our SADT work at Contel (originally as long as the
SCE critique -- but the paper was getting really huge) is given on p. 40
under the non-intuitive heading of "Suggested fix."  We really must get
around to resubmitting that one -- it's an interesting article with lots
of practical implications.

                Cheers,
                Terry Bollinger

+--------------------------------------------+-------------------------------+
| Terry Bollinger                            | Phone: [phone]           |
| Advanced Switching Laboratory, NEC America |   Fax: [phone]           |
| 1525 Walnut Hill Lane, Irving, Texas 75038 | Email: [e-mail]   |
+--------------------------------------------+-------------------------------+