h1

What’s Really Going On With Modeling?

April 27, 2010

UML has been on the market well over a decade.  Visual modeling in general has been around much longer.   Some contend that modeling is now mainstream and pervasive in software development.  Is it really?  What do you say?

This survey asks 3 simple questions that will provide important insights. I will post the results for you when the survey is complete.  Tell us what you have seen.

Advertisements

6 comments

  1. The barriers to UML modeling:
    – The is so much leeway in how to apply the elements that models can vary greatly across the population of people who use them. No penalty for doing so.
    – The models are not seen as an asset. Lack of executable models or clear transforms to produce code leave models as “visual communication tools” which management does see as a step to getting a system.
    – Most scorecard/ reward systems in companies do not have model completion as an item.
    – Job listings – for the most part – do not post modeling as a key skill

    Some cures?
    – Clear semantics for executing/ translating models to get to code – this also would limit the options/ choices about how to apply the UML elements and would contribute to models as a useable asset.
    – Once models are proved as having value, they may be something valued in assessing necessary skills and job achievement.


    • When BPMN tried to tighten things up so the “model” could be executed, it apparently made it much harder to use it as a communications tool to non-BPMN experts. UML is or already has approached this limit. I would hate to see it pass it.


  2. Interesting point Tom. Many people feel UML 2.x, while providing more “completeness” added much that that is not very useful. And in practice, most(not all) people use few and only the more basic diagrams (the ones that people can communicate with). Hmmmmmm.


  3. I recently managed a fairly large IT project which required deployment of various integrated software modules and in some cases also distributed.

    I was the consultant managing the project on behalf of the supplier and I dealt directly with the end-user (central Africa).

    The first assumption (supplier) –
    The deployment and the customization is easy, we have done it more than 5 times.

    The second assumption (supplier) –
    Doing a high-level document on deliverables will lock down the customer and limit scope creep.

    Although in many cases, the above assumptions was correct, we have faced problems with re-writing (on-the-fly), several critical components more than three times.

    Fortunately, a new requirement came up for a module we have never done before. I took the initiative and did the whole UML spec right to the point where class diagrams was created. Needless to say, the software was delivered 99% correct and completed with user manuals long before some of the other “customized” modules was delivered.

    Clearly there is an advantage in modeling, but yet the supplier does not appreciate the value.

    I came to the following conclusions,

    1. The deliverable is software and with the “drag-drop” functionality of developer tools, even clients think it is a matter of quickly changing something. There is no need to discuss and document it…just drag and drop it!!

    2. Software must be available in the shortest time. Clients want to see a product!, not documentation.

    3. Compiling UML models and specification involve many meetings. Clients are tired of meetings. Everybody want to see results.

    4. In many cases, the perception is that the software developers are playing with their thumbs while the UML expert is compiling specifications. This is a waste of resources and generally the decision is made to “let’s start with the basics while the UML guy is doing he’s thing”

    The most basic solution to the above:
    Involve the end-user from day one as well as the techi’s. There should be very frequent deliverables with basic screen designs so that the end-user “think” there is progress and that they also visually understand what they can expect.

    As for the supplier, I will in future insist on deliverables based on detail specifications. This is the only way I am not held responsible for scope creep situations!!

    At the end: the said project was a success, delivered on-time but with a lot of frustration, simply because of the original assumptions!!

    Hope the above add some value to the discussion. Please feel free to comment / suggest.


    • Francois. Thanks for the detailed sharing of your experience. I find it unfortunate that many see the use of UML models as merely documentation. Used properly such models are a powerful analysis and design tool. Driven by the “rush to code” (as you described) good analysis has become underappreciated and may become a dying practice. For the good of our industry, let’s hope not.


  4. UML and MDA have been a key subject by my company where people use to face software maintenance contracts.
    UML appears to be a fantastic tool for reengineering software, especially where business rules are complex.
    Once regrouped in a consistent and comprehensive model, MDA transform tools are additionally very useful to reverse model on a specific technological target.
    Aside this specific use for round-trip engineering, UML should be understood as a communication support. If UML become a struggle between software engineer and technology-averse people, it simply should be extracted from communication artefacts. Meanwhile, it should remain the privileged tool for analysis and design activities within software team.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: