How Simulation Software Can Streamline Application Development

Early adopters have said goodbye to prototyping and gathering requirements on paper. And they’re pretty happy about it.

By
Thu, February 01, 2007

CIO — In 2003, Citigroup’s mortgage lending group launched a new retail banking product and then found itself mired in what would become 8,000 hours’ worth of software fixes and enhancements.

That result wasn’t unusual, says Michael Chandler, director of user experience and product design in the consumer lending division of Citigroup’s North American IT unit. So Citigroup decided to change its mode of operations for application development. One goal: improve the requirements definition stage and speed up prototyping, with the help of simulation software from iRise.

The results: After Citibank’s mortgage division relaunched that retail application in November 2006, IT made just 120 hours of post-production changes, most of them minor. Chandler says that iRise clearly helped: "We’ve taken out paper-based prototyping and manual, text-based requirements, and moved it towards the electronic medium."

Welcome to the world of software simulation, an emerging area of application development tools. Don’t think of flight simulators, though: Think of CAD/CAM tools that eliminate paper-based tasks.

Tools like iRise "allow you to build the simulation of what you’re going to get at a really low cost," says Carey Schwaber, an analyst at Forrester Research, who calls poor requirements definition the root cause of bad software. IRise claims that it can cut requirements time in half and cut reworking time by 75 percent, numbers that Schwaber says sound reasonable.

At a time when businesses are asking CIOs to help deliver innovative changes quickly, old-world application development schedules simply may not fly. Simulation tools, targeted mostly toward business analysts, offer a novel solution. They also fit in well with the agile programming trend.

Citibank Changes Tempo

But simulation software, intriguing as it may be, won’t be a Band-Aid you can just slap on your current process. To pick up the pace of its software development, Citigroup went after its root problem in defining project requirements, which involved various business partners just "throwing requirements over the wall," Chandler says. Developers got a large list of functional specifications but lacked a sense of what the ultimate product should look like. Then, "when the production version comes, you’ve got 10,000 hours of changes," Chandler says.

So Citigroup adopted a user-centric design approach for all consumer mortgage lending products. Whether the ultimate users were employees or customers, the user needs helped define the requirements of the project.

Creating this culture in Citigroup IT was a big step forward, Chandler says, but IT found two big development inefficiencies remained—around prototyping and effective requirements gathering. As at most firms, prototypes came out of meetings where requirements were put down on paper. Models were also built on paper. "Paper prototyping is lengthy and it’s not connected to anything else. You prototype it and you throw it away," Chandler says.

Continue Reading

Our Commenting Policies