Visualize first, build later: The advantage of simulation tools

Computerworld - When Jan Scheetz was asked for a wish list of what she wanted in an electronic physician-order system for patient rehab regimens, she wasn't shy about her requirements. According to Scheetz, the ideal system would generate a valid electronic signature from a physician, which is necessary to process insurance and Medicare claims but is often a challenge to obtain.

"This is something we were dreaming of for a long time," says Scheetz, the outpatient supervisor at MD Anderson Cancer Center in Houston. Right now "we have consults online that [do not result in] signed orders" and therefore require substantial manual work to complete. But a new process will allow hospital staffers to treat an online consultation as a valid signed order generated by a physician.

Perhaps best of all, Scheetz and her colleagues got to see what the system would look like even before it was developed.

The hospital used a software tool called iRise, which allows enterprises to simulate and create images of what software applications will look like before actual development occurs. They are not working prototypes; instead, they're "acting" applications with a finished look and feel, but with no coding behind them.

Scheetz and others in her department worked with business analysts at MD Anderson. They all used iRise to hash out what they wanted in the physician order system and then, several months later, Scheetz and her colleagues took a look at the first version.

Requirements matter

The challenge that business stakeholders face in trying to communicate their requirements to software developers isn't a new problem, notes Melinda-Carol Ballou, an analyst at IDC in Framingham, Mass. But dealing with that challenge has become more critical in the wake of the economic downturn.

"With increasingly scarce resources, there isn't any margin for error. So if there's a disconnect between what you create and what the business actually needed, the costs of failure are [more pronounced] in this economy," says Ballou, adding that this is the reason products are now evolving to specifically address that issue. (See box, at left.)

"When you're visualizing requirements and looking at a screen, it gives users something tangible" so they can see what "something means in physical terms," she adds.

There is a significant need for better communication between stakeholders and developers. Boston-based IT research firm The Standish Group reports that there was a decrease in project success rates from 2006 to 2008. (Standish conducts its research studies every two years, and 2008 is the most recent year for which data is available; the results of a new study are due early next year.) In 2008, 32% of all projects succeeded, meaning they were delivered on time and on budget, with required features and functions, according to Standish. In comparison, the firm's 2006 study showed that 35% of projects succeeded.

On the other hand, in 2008, about 44% of projects were late, over budget and/or came in without all of the required features and functions, and 24% failed and were canceled prior to completion or delivered and never used, according to Standish. In 2006, the failure rate was at 19%.