Re: Tools was Re: [AM] A small success and a large irony

| From: Scott Ambler<[email protected]>
| 
| >  Tools that are lithe,
| >well-suited to purpose, and well-integrated, may make your modeling more
| >agile.  I can draw MSCs with our tools MUCH faster than I could draw
| >them by hand, AND I can easily modify them, I export them to other
| >tools, suck out lists of entity names as text, etc.
| 
| If that's the case, then do so.  But are you modeling with others when 
| you're doing that, or are you by yourself?
---

Yes.  That is, it works well either way.  Use of a project, or NetMeeting,
for sharing the view works fine.

---
| >| For example, when I am first exploring how I intend to build a screen I
| >| will often use Post-It notes, sticking them to the nearest flat surface
| >| (a desktop, a whiteboard, …) that I can find. Post-Its are easy to work
| >| with, you can write brief descriptions on them or little sketches, and
| >| easy to move around.  Furthermore they stay where you put them because
| >| of the glue on their backside. Post-Its are great at the beginning of
| >| screen design because you can get a feel for the layout very quickly,
| >| adding and removing widgets quickly.
| >---
| >
| >Post-its are a great tool.  Our UI designers use them extensively.  On
| >the other hand, I can make text boxes in Visio as fast as I can make
| >Post-its, I can move them around as easily, they remain sticky forever
| 
| That's nice, but are you working with your stakeholders when you're
| doing that.
---

Again, it can be either.  However, the UI modeling is usually done in
the user experience team, which works with customers and end users.

---
| >(unlike Post-its), and [the killer] I can mail the result to somebody
| >else, or print it in different sizes, or clone it as a base for
| >exploring a variation, or put it under version control so I can remember
| >the steps that led to the current state...
| 
| That's nice too, but you lose the value of inclusiveness with the 
| post-its.  Make the trade-offs that are best for your team.
---

How do you use inclusiveness, assuming you're doing this collaboratively
and making the results visible?

| >---
| >
| >As noted elsewhere, I think the agility should have occurred in
| >designing the screens and flows, which should happen before you go to
| >code.
| 
| Yes, spending a couple of minutes doing so makes sense.
---

In our case it's more like months, overall, by the time you've laid out
enough interaction to be useful and set and reviewed up user testing
sessions.  Obviously, consumer devices are different from software
that's used internally in a more narrowly-constrained task.

---
| 
| >("time lost waiting" surely is offsetting some manual
| >process that would probably take longer, "migration costs" should be
| >compared with costs of manual translation, "maintenance of the model" is
| >only a cost if you choose to maintain it,
| 
| If I'm not choosing to maintain it then I'd toss it away.  There'd also be 
| little motivation in this case for me to use a complex tool, unless it 
| generated code for me.
---

If the complex tool is effective, it should make the modeling faster
than doing it on paper.  That should be part of defining what makes a
tool effective.  It should be easier/faster to draw UML diagrams in a
good tool than by hand - if it isn't, then it may not be a good tool.

---
| >which you would only do if you
| >were getting continuing value out of it, and the "Benefits" section
| >fails to mention integration of multiple views that keeps them in synch
| >automatically when at least some kinds of changes are made.
| 
| I've found little value in keeping things in sync.  Everybody talks about 
| this, yet it just doesn't seem to be all that important in practice because 
| people can generally figure out what's going on.
---

The specific case that makes me happy is being able to go between
interaction diagrams (MSCs) and class diagrams and have the tool help
with populating the method lists, propagate name changes between
diagrams, etc.  We use the MSCs as input to our test team and to
automated analysis tools, so we do want to keep them.

I tend to find that keeping at least a core set of MSCs up-to-date is
extremely useful in teaching new people how the architecture works,
which matters a lot in large, globally-distributed, long-lived systems.

scott

-- 
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il  61820  
e-mail:	[email protected]	fax:	217-384-8550
phone:	217-384-8589	cell: 217-433-6114	pager: [email protected]

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------