London software testing news UK


Risks to BMUF (Big Modelling Up Front)

Posted in Software testing by testing in London on September 28, 2007

From Dr Dobbs

There are two risks to be concerned about with “big modelling up front (BMUF)” approaches in general. The most obvious one is that overall project cost is driven up with the creation, review, and maintenance of overly detailed models and documents. This is something which the Agile community refers to as “traveling heavy”.

Second, and what isn’t so obvious, is that there are few opportunities for process improvement pertaining to traditional approaches to modelling and documentation. The problem is that the feedback cycle between creating the models up front and validating the models with working software is too long, often months or even years in length. It’s common practice for up-front modellers, particularly business analysts and data analysts, to swoop in at the beginning of a project to do their work, get it accepted, and then move on to the next project. By the time you determine, through system integration testing (SIT) and user acceptance testing (UAT), whether the models actually reflect reality the modellers are often long gone. Worse yet, so many other people have been involved with the actual construction that it’s incredibly easy for the modellers to blame them for any problems — the models were reviewed and accepted after all, so the problem must be in the implementation. This lack of concrete accountability may explain why the traditional modelling community has been stuck in their BMUF rut for almost 30 years.

There are clearly serious problems with traditional approaches to modeling. However, a fair question is whether traditional approaches address risks which agile approaches do not. The answer is a resounding “no” to the consternation of many traditionalists. Traditional modeling approaches provide the opportunities to think things through early in the project, thereby reducing the risk of starting off on the wrong track. However, initial agile requirements and architectural envisioning also enable you to do that.

In short, traditional approaches to modelling increase your risk of building software that people don’t want, working under a false sense of security which in turn prevents you from questioning what you’re doing, increase the chance that you’ll make architectural decisions too early, that you’ll overbuild the system, that you won’t want to deviate from your questionable strategy, that your overall costs will be higher, and that you won’t have easy opportunities for process improvement. Worse yet, the few risks that traditional modeling approaches do seem to deal with are better addressed through Agile Modeling strategies.

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: