UML Training - Avoid Analysis Paralysis!
I've been in several situations in which students would stop me
in a UML training class and ask with stern faces: "How do
you avoid analysis paralysis?" First time I heard that I
sincerely replied: "How do you get to be paralyzed?" Indeed,
there are many ways to avoid analysis paralysis-at least 5. The
rest of this article assumes you're in the shoes of an analyst,
with the mission to model some new topics that experts are
explaining to you.
Perhaps a manually run business operation is to be automated.
The analyst must first understand what the system has to do
(analysis) before deciding how to automate it (design). Muscular
paralysis comes from blocking the connection between the brain
and muscles. Mental paralysis, the analogy used here, comes from
either having no idea what to do or having too many options to
choose. The following advice cures the no-idea case and gives
priorities to help you determine where to start and how to
continue.
Picture the subject matter experts throwing all kinds of
elaborated concepts at you. They're the experts, yet you may see
them stumble over fundamental definitions, use terms you can't
relate to, contradict another expert, call-up a colleague to
check on key concepts and so on. That would slow down and even
freeze your analysis process, wouldn't it?
1. Deal with the best-known topics first
Identify a topic your experts seem to know best and model it
right away. It doesn't have to be an easy one (half of the time
it won't be). You know how to model and the experts know the
topic. Here is your opportunity to make quick progress. Once
you're done, go on with the next best-known topic, and so on.
Your tactic at that early stage is to channel everyone's energy
to come to closure quickly on existing knowledge, knowledge that
is readily available. This will bring you two immediate
benefits: a) everyone will feel satisfied with the rapid
progress; b) future discussions won't be cluttered with these
topics.
While dealing with the best-known topics and concepts first, you
might end up building a good chunk of your model. This will
definitely prepare the ground for further modeling. Later on,
additional and more-complex concepts might easily "plug-in" with
the already modeled ones.
2. Locate the most knowledgeable person(s)
We've all been there: you work hard with a very well intentioned
fellow trying to understand some deep topic, but somehow the
more you analyze it the less you feel you can grasp it. After
some considerable labor, he or she tells you: "I don't really
know--after all, I'm not the expert! You can avoid this problem
by looking for the experts prior to starting anything. Always
ask: "Who's the top expert in this matter?" Spend time with the
experts first. If they can't really afford to spend hours with
you, invite them to join some of your short analysis sessions.
Involve them by all means.
You'll find that real subject matter experts will make your
project progress with giant leaps.
3. Use the marvels of natural language
UML may be a great modeling language and you might be a
champion at using it, yet you could experience a very slow
start. Have the expert write one or a few paragraphs on the
subject matter. For example, Paul is the man who truly
understands retirement plans. It's a hairy subject. Don't start
to model it straight from a first encounter with him. Have Paul
write a few paragraphs ahead of time to summarize retirement
plans. Then Paul and you can meet and model. In so many years of
consulting and mentoring in the industry, I've almost never seen
a true expert fail in writing his/her knowledge in plain
English. Natural language has its unquestionable power.
Ask also that key words used in that text be defined in the
glossary-still in plain English. With these two documents, the
expert's knowledge will be clarified, you'll get a powerful
start and you'll have a reference that you and the expert can
use while modeling. I've tried it both ways: with or without a
narrative to start with. I feel that modeling sessions are much
faster if you start with a short narrative (I also call it a
"problem statement" or "business synopsis"). They will enjoy
seeing their terms appear in your UML diagrams and use case
narratives. Remember, with UML you are structuring their
expertise, not encrypting it.
Some people object that plain English is not that useful and
certainly not as high-tech as the UML. They argue that tools
like UML sequence diagrams could "get you there" much faster.
It's a myth. Narratives expose the meaning; they build up
fundamental understanding in the analyst's mind. That's the best
place to start and it's quickly obtained. Note: In a future tech
letter I'll write about object interactions, activity diagrams
and business process modeling. I'll also write about the power
of relationships as modeled in various UML diagrams.
4. Slice up concepts
Now, assuming you've got the right expert(s) to speak with and a
narrative to start with, what's your next step? That's where
your analysis activity really begins. Stick to the business
concepts: what they mean, how they differ from each other, what
type they belong to, what characteristics they exhibit, what
they are made of and so on. Very importantly: how they relate
with other concepts.
That part is like "dissection": slicing up the concepts. All the
above angles, as you know, lead you to using fundamental UML
constructs. Examples are: classes (or objects), attributes,
inheritance, composition, associations and association
classes.
In very little time your UML picture is built of various
diagrams and you feel at home. Don't think you're done. You need
to present the outcome of your analysis back to the experts, as
advised in the next paragraph.
5. Assemble concepts back together
As you probably remember from our course, a model is only as
good as its effectiveness in reflecting the reality. Experts
took the time to work with you; they hope for more than a
cryptic picture that you seem to be the only one to appreciate.
You need to close the feedback loop.
Read the whole diagram back to them "in plain English", using
their business terms. Examples would be: "Purchase orders refer
to goods that are requested by manufacturing departments?" Do
not say things like: "Here is the PO class that is associated
with the Goods class, and it's a 1 to many association?"
Do not use any UML terms while describing your model back to the
domain experts. They need to "hear" your model. Based on that,
they'll tell you whether your understanding is right. They'll
help you fix details and refine your model, based on your own
reading of the model. After a few iterations your understanding
will be raised to the expert's level.
Now, your model is ready. It's the blueprint for the whole
project. It's a bridge between the expert's mind and the actual
system that will be built to automate the business needs.
Before modeling, we always make sure that enough knowledge about
the subject matter is available. If it's not, then we go get the
experts. We model what is known. We postpone what's not known.
We use natural languages to start with and also to conclude.
What was said at the beginning of the analysis period will also
be expressed at the end. In the process the model is built.
It's a very simple, systematic strategy based on common sense,
based on human understanding (and of course with a little help
from some good UML training). This very dynamic process
moves you towards the goal. How could you possibly get stuck?
There is no excuse for paralysis while doing analysis; that is
nothing more than an old catch phrase.