发信人: wjanry()
整理人: majorsun(2000-03-08 14:00:28), 站内信件
|
As we are new to the UML process, training will be needed for the anal
yst role.
Who makes the best analyst? Consultant already trained - technical bus
iness user or member of the IT development team trained in legacy syst
ems?
Jim Conallen
Administrator posted 04-22-99 02:17 PM
----------------------------------------------------------------------
----------
What a great question! ?wish I had a great answer? Analysts have IMHO
one of the most daunting tasks. The role of the analyst is primarily t
o define that the system should do?without specifying how. We have lot
s of mechanisms to express this with (use cases, requirement specs, st
andards documents, prototypes & storyboards, etc.). So some level of t
echnical proficiency is required.
In my experience the best analysis folk haven all come from the same
background (domain expert, power user, consultant, IT, management, ?.
I think the qualities of a good analyst are more personality related.
Of course an analyst has to have some technical skill and possess exce
llent communication/interpersonal skills.
A good analyst needs to be open minded. One of the most difficult prob
lems in writing good requirements is not specifying the how? that seen
too many requirements that have essentially specified the entire solu
tion in addition to the problem.
A good analyst also needs to technology neutral. I’m sure you the see
n cases where the problem was phrased such that only one vendor抯 solu
tion could possibly be applied. (argh! gov. work flashback :-)
The analyst needs to be a mediator, since they are essentially writing
a contract between the domain side and the technical side of the deve
lopment team. Hey, maybe that抯 what we can do with all those extra la
wyers out there :-)
[This message has been edited by Jim Conallen (edited 04-22-99).]
Kurt Neubek
Member posted 04-23-99 11:13 AM
----------------------------------------------------------------------
----------
I'm a "building" architect, one of the few in the country who speciali
zes full time in pre-design requirements development ("architectural p
rogramming and planning" in our vocabulary). But I've also worked with
many software developers including folks at Bell Labs and Lucent to t
rain them in the processes and techniques that have been developed in
our realm over the last 40 to 50 years. So I have a better understandi
ng than you might first imagine of analysis and requirements developme
nt for software and hardware. And, as evidenced by this posting, I try
to keep up with new developments in your world of analysis. I've been
amazed at how similar our work is. (None of that is meant to be comme
rcial; rather to establish my perspective.)
As one who has been recruiting and training people to specialize in re
quirements development for more than a decade, I have several observat
ions and lessons learned:
1. SPECIALISTS ARE BEST
Pre-design analysis is a specialty that requires specialized tools and
techniques, along with experience. A part-time analyst can't possibly
develop the same level of skill that a full-timer does.
2. AVOID FOLKS WITH A "DESIGNER" MINDSET
People who are creative and energetic designers (or coders), who love
to solve the problem or come up with the answer, rarely make good anal
ysts. It's not that they CAN'T do it--some designers are very good ana
lysts--but their thought processes naturally keep trying to solve the
problem before it's fully defined. So they either have to learn to "tu
rn off that side of their brain" during analysis, or, more commonly, t
hey get bored with requirements.
3. DON'T TRAIN A TOTAL NOVICE
It takes experience to be a good analyst. I've seen too many people co
me right out of school into this specialty, and they either stray from
it because they need to try other things in their careers; or they st
ick with it, but they're limited by their lack of experience. They can
eventually learn to be very good analysts, but they have to work clos
ely with a more senior specialist for years.
4. DON'T HIRE "OLD DOGS" (Who Can't Learn New Tricks)
At the other extreme, I no longer hire experienced analysts (unless th
ey have had the proper training, which is rare). They come thinking th
ey know how to do this work, so they're less open to learning everythi
ng it takes to be exceptional at this discipline. And/or, they have le
arned or developed bad habits and shortcuts which are difficult for th
em to break.
5. RECRUIT PROVEN THINKERS
So if I don't hire novices nor gray beards, who's left? I've found peo
ple with at least 2 years of real world architecture experience have a
t least enough exposure to the business to understand issues--especial
ly if they've had good broad exposure during that time, not just one b
ig project. But I also look for people who can think analytically and
have discovered that they don't have to be a designer to be fulfilled.
Often, they have a slightly non-traditional background, such as a pre
vious degree (or minored) in business, finance, or construction scienc
e (or computer science!).
6. SEEK THESE ATTRIBUTES
The best analysts are extremely well rounded. They must:
a) have excellent people skills. In many ways, we're more "facilitator
s" than architects. We help the users state and prioritize their expec
tations in terms the development team can use.
b) be good listeners.
c) be "reductionists" (a phrase from one of my mentors, William Pena).
Analysis, when done poorly, is stenography of the users' wish lists.
Done professionally, we abtract each idea or suggestion to its essence
, identifying the core concept behind the stated "requirement" (which
is almost always a limiting preconceived solution). This brings clarit
y to the problem to be solved, and frees the design/development team t
o come up with the most appropriate and cost effective implementation.
d) be quick learners. We have to immerse ourselves in the users' busin
ess and thought processes.
e) be very organized and able to document and track details.
f) be able to see the big picture--the forest for the trees. For most
people, this one of the most difficult lessons to be learned.
g) be able to think conceptually and document diagrammatically. As fac
ilitators, the communication and documentation of all the requirements
is paramount. This requires both verbal and graphic communication ski
lls. As building architects, we've generally had some training in art;
nevertheless, most do not possess the ability to quick capture and gr
aphically communicate ideas in real time, with the users. This takes t
ime and a willingness to learn.
7. TRAIN, INTERN, TRAIN, OVERSEE, MENTOR
Once you have the right people, it takes intensive immersive training
to infuse the appropriate mindset and skills. Then we use on-the-job-t
raining working closely with more experienced specialists (internship)
. Then, after exposure to many projects, we go through the training ag
ain, because "you learn best what you already half know." When the per
son is ready to lead projects of their own (in our world that's after
1 to 3 years), it takes careful oversight to nurture and support them
without smothering or demotivating them. (Now we're getting into the r
equirements of the manager!)
A lengthy reply, I know. If you have any questions, I'd be happy to di
scuss more, and share additional lessons learned.
Wojtek Kozaczynski
Administrator posted 04-23-99 12:19 PM
----------------------------------------------------------------------
----------
Kurt, thanks for this great contribution. If you asked me what my prof
essional profile was, I would answer that I am a software architect (I
am member of the architecture practice at Rational). I agree with you
r points on the skills and attributes of good analysts. I also agree t
hat there are a lot of parallels between defining and architecting sof
tware systems and physical systems (buildings in particular), but ther
e are also differences. These differences may not effect the analyst t
hat much, but they certainly effect the architects who are the poor fe
llas siting right between analysts and developers.
Software systems are invisible, temporal, and infinitely alterable. We
can only see the raw material (the code) and the external behavior of
a system. Sure, we create abstract views of a system (this is a big c
hunk of architecting), but we are sill debating (as a profession) what
the common views are, what concerns they address and how. UML is a bi
g step in the right direction, but UML is a notation (a language) not
a set of agreed upon use profiles of the language.
To complicate the matters, software system can change (and do change)
their behavior. Actually this is what they do all the time by applying
different rules to the data at hand and the signals they receive. Thi
s is what I call the temporal nature of software systems. Of course th
e most degenerate case is a system that modifies its own binary repres
entation (which can be easily done in assembler), but thanks goodness
I have not seen that used for a while.
Software systems also evolve all the time sometimes because they need
to and sometimes because they can. Making changes to software is easy
and this is both a blessing and a curse or our profession.
Over time I learned to use the parallels between software architecting
and building architecting with caution. They are great in explaining
concepts and roles, but in many cases should not be treated too litera
lly.
Thanks again for the message.
Kurt Neubek
Member posted 04-23-99 04:19 PM
----------------------------------------------------------------------
----------
Wojtek, Thanks for your kind words. I'd like to add a brief observatio
n about the similarities between software and building architecture:
I discovered long ago working with software analysts and developers th
at software and building architecture is QUITE similar, once people un
derstand what building architects do. (We don't build buildings!)
Like you, we define requirements, we "architect" or conceptualize how
all the various systems should be arranged and related, what the user
interface and look and feel will be, what infrastructure and technolog
ies are available, then we develop and write arcane instruction codes
(in the form of specifications, plans, elevations, sections, and detai
ls to the builder). Along the way, a team of people creates virtual mo
dels, and each person works on different pieces and views the conceptu
al model in different ways.
You can't walk through our output (except in the same way you can "wal
k through" code), and you can only experience whether it really works
by using it!
And, like software, our creations do have various "releases" (bug fixe
s are called change orders, and plans for renovations or additions are
new releases!). Sometimes the feature set can be easily adapted in ou
r model, but other times, the existing system has to be completely ree
ngineered to accommodate new uses.
Anyway, I don't mean to debate this issue--I just thought this clarifi
cation of what building architecture entails might be of use to someon
e. Adios.
Wojtek Kozaczynski
Administrator posted 04-23-99 05:07 PM
----------------------------------------------------------------------
----------
Kurt, thanks for the response. The very purpose of this forum it to fa
cilitate exchange of ideas so as long as we both enjoy it and someone
can learn from it, let's continue.
Yes, what building and software architects do is similar in some respe
cts, but still different in others. We build models and you build mode
ls. However, most of our models communicate structural relationships b
etween system components and almost no system behavior, which is most
critical. In order to communicate (and measure) system behavior we bui
ld prototypes. However, we use the same material that we will use to b
uild the system. In fact, our prototypes are incomplete versions of th
e system. In the physical world this would be equivalent to building a
part of a house and potentially tearing it down if the customer didn'
t like it or if it would not measure up to some expectations (we call
them quality attributes).
One of the most important qualities of software system architecture is
its ability to handle change (of the systems, not the architecture).
This change is inevitable and it amounts to acknowledgment, that syste
m requirements are either incomplete or will drift. Why is it that in
the software domain we accept that requirements will either change or
will be incomplete? This is because it is very difficult to communicat
e what a system will or will not do without building it. This is why o
ne of the principles of the Rational best practices is iterative devel
opment - build what you understand and what's critical first. Here we
are back to the invisibility and temporal (behavioral) nature of softw
are systems.
There is yet another interesting difference. Building architects use s
tructural engineers to make sure that their architectures don't violat
e laws of physics and mechanics. There is no simple equivalence of the
laws of physics in software and only a few "mechanical" principles. I
n the software domain we must build something to see if it flies. Luck
y for us it takes one key stroke (DELETE to get back to square one. E
ven more lucky for us, many parts of a system can be reused (so we sel
dom delete our code, we archive it .
Now please don't get me wrong. I have always advocated learning from b
uilding architects and I always believed that we had a lot to learn fr
om them (both of my parents were architects). On the other hand, I als
o advocated that we don't try to apply all their practices without ada
pting them to our domain.
Kurt Neubek
Member posted 04-28-99 10:55 AM
----------------------------------------------------------------------
----------
Excellent points, Wojtek. I especially applaud your closing remarks. I
n my work with software architects (and project managers, analysts, de
velopers, etc.), my great "aha" was how much we ALL learned when we AD
APTED building architecture best practices to software architecture. I
n mapping our processes, we found many, many direct equivalents, a few
had to be adapted or just translated differently, but all of it appli
ed. And, notably for my clients, we identified many processes or conce
pts or steps that didn't map, but which they realized were holes in (o
r at least improvements to) their traditional software development cyc
le.
And perhaps most rewarding for me, I was excited by the crossover know
ledge, my direct exposure with world class software development (my mi
nor in grad school), and seeing others' "ahas" when they, too, grasped
each analogy or crossover or potential operational or strategic advan
tage.
On a different note: By the way, I think there ARE natural laws or lim
its that software developers are subject to--like gravity in our world
. You call them things like bandwidth and throughput and MHz and resol
ution and refresh rates, etc. (Admittedly hardware limitations, not so
ftware.) These are equivalent "site constraints" that you certainly un
derstand and have to work within or around. But I also appreciate the
point you were making--software itself is cursed by it's (at least per
ceived) limitlessness!
Thanks so much for the dialogue.
[This message has been edited by Kurt Neubek (edited 04-28-99).]
Frank
Member posted 04-28-99 12:29 PM
----------------------------------------------------------------------
----------
I believe I have "the answer" to my question. Thank you for the excell
ent responses. A colleague of mine has printed them out to share with
the Java class he is teaching locally.
However, I would like to put a spin on this question. We are a large o
rganization - matrix managed. You have identified the attributes requi
red for the individual to be assigned the role of analyst, but not the
organization he belongs to.
I have seen customers (users) who wish to retain control of the requir
ements process. As we are new to UML and people need to be trained, we
will be hiring consultants to mentor our people as we ramp up on this
process (if we do it right). Why not train someone from the user depa
rtment?
Jim talks about the analyst being a mediator between the domain side a
nd the technical side of the development team. Can (should) a customer
do this? Or should this be an organizationally "neutral" person?
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.96.184.24]
|
|