Re: UML

["Mike O." <obie1121 -at- yahoo -dot- com>]

John Posada wrote:
> What I need to know is this: Has anyone created 
> documentation under the umbrella of UML. What were 
> the "gotchas"?  What did you find out was the biggest 
> impact on what you do on a day to day basis? What was 
> your biggest obstacles. Did it improve what you create 
> and if so, how? 

I've been involved with a number of projects that used UML and/or RUP,
but frankly I have never seen a project that used either discipline to
its fullest extent (and maybe that's a good thing).

In my experience, projects use a pragmatic approach where they use the
UML/RUP features that benefit them, and discard the rest. You can study
UML or RUP as much as you want but ultimately, it's what your boss says
it is. 

To put it less charitably, some teams start out declaring allegience to
UML or RUP at the beginning of the project, but when the going gets
hard and the discipline gets harder, they revert to techniques they
know (waterfall, cowboy coding, death march, etc). 

And, every UML or RUP project I've seen has at least one high-level
purist who drags the whole team into religious wars about what is or
isn't the One True Way. Don't worry though, these people usually don't
last the whole project.

In my experience, UML's greatest contribution is that because of UML,
the concept of a 'modeling' phase even prior to design is now widely
accepted. The simplest part of UML (diagramming use cases) is really
the most important, because it forces all parties to define
requirements in simple direct terms, rather than in convoluted essay
answers. 

The least helpful thing about UML or RUP is the legacy of its birth,
when it was envisioned that you could use advanced CASE tools to create
fully coded systems using nothing more than your use case diagrams,
which would be created by business SMEs using drag 'n drop. This was
always a pipe dream, but the concept lives on in RUP's round-trip
engineering process (I've never seen that fully implemented either).

To some extent, RUP is just another document-driven SDLC, so you will
probably find your RUP experience to be just a series of documents,
which may turn out to be mostly boilerplate. RUP defines many
documents, but most teams usually implement only a subset of them. One
of your first tasks (once you understand RUP) should probably be to
minimize this subset... find out what RUP documents your team really
cares about, and forget about the rest, otherwise you will have heavy
doc overhead on every project. 

Be pragmatic, don't be a purist, find what works for your team. Don't
be afraid to heavily modify the RUP templates, or introduce new non-RUP
documents if you need them. 

Mike O.






__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ANNOUNCING ROBOHELP STUDIO
Create professional Help systems that feature interactive tutorials and
demos with all new RoboHelp Studio. More at http://www.ehelp.com/techwr-l2

Mercer University's online MS Program in Technical Communication Management:
Preparing leaders of tomorrow's technical communication organizations today.
See www.mercer.edu/mstco or write George Hayhoe at hayhoe_g -at- mercer -dot- edu -dot- 

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.