topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Thursday December 12, 2024, 2:33 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Model driven development  (Read 3659 times)

phitsc

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 1,198
    • View Profile
    • Donate to Member
Model driven development
« on: July 28, 2010, 02:30 PM »
Anyone of you guys had any experiences (good or bad) with model driven development (using tools like IBM's Rhapsody)? I'm interested in aspects like efficiency, mastering tool complexity (learning curve), round-tripping, developer acceptance, management acceptance, comparison with CAD, etc. whatever comes to mind.

I'm also interested in opinions of people with no MDD experience.

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,914
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Model driven development
« Reply #1 on: July 28, 2010, 02:51 PM »
my quick uninformed general impression is that these kinds of things become useful when you are working in a large team.  for a single developer or a very small close team of just a few people, they are more trouble than they are worth.

mnemonic

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 177
    • View Profile
    • My website
    • Donate to Member
Re: Model driven development
« Reply #2 on: July 28, 2010, 04:04 PM »
I've experience of Rational Rose (the UML part of Rhapsody) working in a large team

Pros:
  • Allows a standardised documentation method.
  • Means that information should all be in one place.

Cons:
  • Once it's part of a corporate environment, the methodology guys add a huge layer of complexity to the tool (which they don't have to use).  I'm very much of the opinion that diagrams are there to communicate processes, rather than having to be a stickler for methodology-based rules and complexity.
  • Like every documenting system, it quickly drifts out of sync with the development and becomes useless.  In a perfect world, the logical models and use-cases should be kept updated, but no-one ever has the time or inclination to do this.

Like mouser says, they are overkill for a small team.  I don't think that you can beat scribbling random flow diagrams and bullet points on paper or a whiteboard and then archiving them with your mobile phone's camera.