RE: [AM] ANN: Are You Ready For MDA?

Responding to several at once, sorry for any confusion.

- Scott


At 06:38 AM 3/10/2004, Jason wrote:
>Very interesting, Scott. I'm literally about to have lunch with one of the
>directors from Softeam/Objecteering, and Test-driven Analysis & Design (or
>"Test-driven Modeling") is something I'm keen to address with him. I've
>proposed an approach (which I do on paper because there's no tool support
>for it) that borrows liberally from Catalysis, but applied to an entirely
>test-driven development process. The basics are at
>http://www.parlezuml.com/tutorials/tdad/intro.htm (plug plug)
<snip>
Just added a link to it from my page.


At 06:44 AM 3/10/2004, Stefan wrote:
><snip>
>
>You write that embedded systems are a "spectecularly small percentage of the
>overall market". I'm not sure if I should agree. I thought in the contrary
>that embedded systems (nowadays) have a significant share of the software
>market and this share is still rising.
<snip>
Do you have any figures?  Gut feel tells me that it's less than 5% of the 
overall software development market.


At 06:53 AM 3/10/2004, Ashley wrote:
><snip>
>
>However, I believe that there is a good (and not much explored) case for a
>more limited form of MDA, where model execution is used as a mechanism for
>exploring and validating models early in the development process, even if
>the final code of the system is not fully generated or perhaps not generated
>at all. I believe that using this "scaled-down" form of MDA can give
>substantial benefit, and significantly ease the issues you raise:

This makes a lot of sense to me.  Do you have any links to articles written 
about it?



>- Stakeholders do not have to understand PIMs, as they can review and check
>the model as an executing model-driven prototype (Your point 4).
>
>- You are well placed to use TDM (or TDMDA), and there is no reason for
>model validation tools not to provide this (Your point 6).

Other than the fact that they haven't been built yet.  ;-)



>- You are not dependent on the tool vendor beyond the model validation
>phase -- in particular, not for deployment or support of the operational
>system. (Your point 7).

Yes, unless you decide to take the models the next step into detailed design.

I'm not sure that many people would be willing to do that much modeling and 
then throw the models away, could be wrong though.


>You do still need skilled modellers (your points 1, 2 and 3), but in much
>smaller numbers than you would if you were using MDA throughout the
>development. In my experience of using this technique, a team of three to
>five modellers can support a large project (total team size > 30).
>
>The big tool vendors are all pursuing the "soup to nuts" MDA model. I think
>that there is a market opportunity for less ambitious tools -- and that this
>would both allow smaller tool vendors to enter the market and also allow
>organisations interested in MDA to experiment with, and get value from,
>model driven approaches without committing themselves to the hilt, in terms
>of both money and risk, from the outset.

There is definitely a good market for focused tools, IMHO.

<snip>


At 07:34 AM 3/10/2004, Hubert wrote:
><snip>
>
>I link three things together when discussing tools and UML: modelling 
>maturity, process
>capability, and tool sophistication.  I don't think you can make any real 
>progress in one
>without having to address the others.  In the end, you extract value from 
>your tools only to
>the least-capable level of the three.  For instance, there is no point in 
>buying round-trip
>engineering or MDA tools if you have a weak process or immature 
>models.  CMM would say that
>you shouldn't be buying tools until you're at CMM Level 3 because you 
>won't know if they make
>any difference.
><snip>

With regards to:
1. Modeling maturity, I have to agree that you need people with effective 
modeling skills, ideally effective agile modeling skills.
2. Process capability, I believe that you need people who can work together 
effectively to develop, support, and operate systems.  That doesn't mean 
you need a well-defined process, it just means you need to know what you're 
doing.
3. Tool sophistication, I'm not so sure.  My experience is that you can be 
incredibly effective with paper and whiteboards, and those tools clearly 
are not that sophisticated.

- Scott



====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

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]

For Topica's complete suite of email marketing solutions visit:
http://www.topica.com/?p=TEXFOOTER
--^----------------------------------------------------------------