[EMAIL PROTECTED] wrote:
> Does anyone know a good method to teach other employees of our company UML.
> We were thinking about something interactive like a workshop.
It all depends on the skills of your people. I'm a consultant and a
seasoned project manager. Lately, I teach the UML at Seneca College in
Toronto, Canada. We have a trimester system, and we teach introduction
to the UML in one trimester. We are seriously considering adding
another trimester.
Don't be too quick to suppose that your people are significantly
advantaged over college students. After all, your people still have to
do their jobs, so they will have even less study time than my students.
You have to bring them along with each new technique in such a way that
they are visibly more productive than before.
I think the trick is to teach the relevant tools as the team goes into
each phase of the project. For my money, that means starting with
scenarios (which aren't even standardized in the UML, I think) and
sequence diagrams. These are fine tools for getting started with domain
experts (who generally understand these diagrams very well). The more
traditional staffers can view this beginning as another approach to
requirements analysis.
The first big, jagged pill is use cases and use case diagrams. The
semantics of this space is just too weird for people - even OO
programmers - who are starting out. Documentation techniques for use
case flow of events descriptions are available from Terry Quatrani, but
they aren't complete or standardized. You'll need a mentor if you
aren't one yourself. For the most part, keep the domain experts out of
the room while you're doing use case analysis -- they won't understand
and their time gets wasted. Final use case diagrams are generally
accessable to the domain experts, though, and they might be used for
approvals.
If you have OO programmers in your team, they can start on class
diagrams and class specifications with the first scenario (again, hide
this from the domain experts). Once again, I suggest adding modelling
features to the employee's skill set as the need arises. Again, you
need a mentor, either on staff or on contract, to get people started
with each new thing.
I'm not going to continue this through the whole process. Point is, you
can't stop Niagara Falls to clean it -- it's gonna keep running, and you
have to adapt to that. Over and over, you will need a mentor to show
techniques, as they are required, to the newbies. A mentor can also
help to create appropriate project plans and explain them to management.
As a project manager, I've used these tactics very successfully. I'd
say the main thing is to get management visibility for the process of
cutting over to the UML, and make sure you don't underestimate the
amount of effort that will go into it. The first thing to show
management is that iterative development can nibble the risk of
integration gradually over the project, rather than trying to swallow it
whole at the end. If they have any smarts, they should love you to
pieces over the risk management benefits, alone.
-Eric
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
