Modeling and Simulation - Part 1

Modeling and Prototyping Have Been Used for Many Years - and the Results?

Industry statistics about software development, without modeling and simulation but including modeling and prototyping (i.e., static screen shots, wire frames, etc.), paint a grim picture. We will contrast today's situation with modeling and simulation as we work through this discussion. The following statistics are representative:

- 66% of projects fail, run late or are over budget (Standish Group)

- 45% of software features are never used (Standish Group)

- The two primary reasons for project failures are poorly defined requirements and lack of user input (Standish Group)

- 40% of total budget for software are projects is rework (R. Dion)

- 80% of all product defects are inserted in the requirement definition stage (M. Sue White)

- 70-85% of software project rework attributed to requirement errors (D. Leffingwell)

- "The cost difference between detecting an error in the design at the time of capturing the requirements versus detecting an error after the system has been produced is over 270 times the amount" (Gartner Group)

Note that these statistics come during the time that modeling and prototyping have increased their usage throughout the industry. At best, the change modeling and prototyping brought is incremental.

The Requirements Problem

Requirements are prominent in the statistics cited above. Almost one-half of the features built are not even used.

This means that the wrong things were specified and built in the first place – wasting time, human resources and money. Users are notoriously unable to describe what they do in their jobs and what they want to make it better.

However, this is not just a "user" problem; it is true for all of us. It is a human problem. Modeling and simulation help address this problem.

Our Human Problem

Consider how you could accurately and unambiguously describe using just words something relatively complex you do all the time like driving a car. You know how to drive but you would have a very difficult time describing it in words clearly enough that a driving program could be built from just your words.

Which way do you turn the steering wheel when the car skids in snow anyway?

"The hardest single part of building a software system is deciding what to build" says Frederick Brooks in his classic, The Mythical Man-Month. That was true then and remains true today. However, today we have mature tools to aid in modeling and simulation to help users define the best thing to build.

Fuzzy Mental Models

Because we are human, our individual mental models are:
- fuzzy
- incomplete
- imprecisely stated.

Even for an individual person, a specific mental model changes over time – sometimes within a single conversation!

Fundamental assumptions vary but are rarely brought to light and examined. A mental model must be expressed in terms stakeholders can grasp in order to be understood. Modeling and simulation help identify our fuzzy mental models.

Are We Attacking the Right Problem?

An article titled, Software development productivity and project success rates: Are we attacking the right problem? (opens in new window), by Joe Marasco, former Senior Vice President and Business Unit Manager of Rational before IBM's purchase of Rational, was published in IBM's Rational Edge in February 2006. It is so well worded that we quote from it here.

"We have made some progress. We no longer view paper napkins and Post-It Notes as legitimate vehicles for transmitting requirements. And the notion of use cases has dramatically improved our ability to describe what systems do from the users' point of view.

But note something interesting. All the effort has gone into two areas: managing requirements and something called ‘requirements traceability.’”

Graph shows that 50% of project failures due to requirement failures. Modeling and simulation (as used to date) are having minimal effect.

The Crux of the Matter

Marasco continues,

"What good does it do to ‘manage’ and ‘trace’ 500 requirements if 250 of them are wrong in the first place? Get the requirements right, and you only need to devote your valuable time and resources dealing with those correct requirements.

We have today very few tools that enable the specifiers of their systems to validate their requirements. That is, far too many of the requirements we are managing and tracing today are simply wrong: ambiguous, unclear, incomplete, or contradictory. We can now make sure that none of them are forgotten, but we are doing virtually nothing to improve the quality of the requirements.

I claim that until we address this problem, significant progress will not be made on the fundamental problem of software development project success."

We second Marasco's claim. Anything we can do to get requirements right will have a positive ripple effect throughout the entire software development lifecycle.

Root Causes of Requirements Problems

The root causes for these all-too-common problems in software development include:

1. Lack of User involvement

Users do not normally think the way that requirements are usually written. In other words, modeling and simulation as used today do not help many stakeholders.

2. Stakeholders Cannot Validate Requirements Until Application Developed

Even if business representatives participate in requirement artifact walkthroughs, they frequently comment on what the review facilitator says rather than on what the artifacts actually document.

3. Requirements Discovered After Code Written

Too often a maintenance release consists of fixing requirement misses as much as coding errors and minor changes requested from the field once they see the application. It is much more costly to fix requirements problems late.

4. Project Budgets Inaccurate

Project budgets can be inaccurate because the true scope of development is unknown when project plans are prepared and approved. Even high-level requirements are not understood or well-documented.

5. Users Do Not Know What They Want

We have come to believe that defining good requirements is like defining good art. No one can do it - but everyone knows it when they see it!

Addressing the Root Causes

We describe how modeling and simulation addresses each root cause in Part 2. Simulation works in a way that modeling alone cannot.

From Part 1 to Part 2

From Modeling and Simulation to Building Requirements Consensus™ Home