I've come acorss this query online a few times and I thought I'd take thet time to pitch in with my dime's worth on the subject.
Q. "How much value does modelling offer to software development in an mISV situation?"
This question comes in another variation which is: "Our [small] team of Agile developers don't model our software, we just code it, is that really unprofessional?" but I consider these to be begging for the same answer.
To answer that question one needs to evaluate why we model software. Three major reasons to model software spring immediately to mind:
-
To capture the system requirements for the purposes of coming to an agreement with the customer as to what will be delivered.
- To communicate effectively to the developer(s) what the system requirements are of the software project.
- Because some people really just love to model.
There may be some other other reasons to model software (e.g. to pass your software engineering degree) but they're not really up there with The Big Three
Customer-facing Specification
I have found that when one uses modelling languages and diagrams to relay back to your customer *their* software requirements, as you understand them, the resulting project will completely miss the mark.
Unless the customer has a degree in software engineering the chances are they won't be able to tell from your specification of their requirements that you're completely off the mark. Instead, for fear of looking like an idiot in front of you they'll nod and smile and tell you it all looks in order.
Away you go and make them some software that doesn't suit their purpose. They get angry with you and tell everyone what a disappointment you were to work with.
I put a far greater value on writing a clear specification that the customer can actually understand very much in the style of the "painless functional specification"descrbied here - http://www.joelonsoftware.com/articles/fog0000000036.html
Developer-facing Specifications
In my mISV experiences I have always made sure that I hired developers with enough brains and end-user empathy that I could just give them the Customer-facing Spec.
Any developer who can't read a well written customer-focused spec is probably not going to be able to develop a customer-focused application.
Most developers don't really get modelling languages anyway; and the ones who are good at understanding 'Real People' and their needs seem to have their noggins wired in such a way as to get grumpy when presented with a UML diagram of some classes that they could very easily have deduced if you'd just shown them the customer-spec.
Modelling For Love
Modelling can however be an enjoyable activity (although possibly not as enjoyable as spotting trains). I'm sure it can be because otherwise people won't write so many books on the subject, would they?
But seriously, there is a use for modelling software when you have a one super developer who comes up with all the good ideas and then gets an army of grunt/junior developers to churn out the details.
But that's not the situation in a microISV.