Visualize First, Build Later

Simulation tools show users what applications will look like -- before actual coding begins.

When business analysts asked Jan Scheetz for a wish list of what she wanted in an electronic physician-order system, she wasn't shy about stating her requirements. The ideal system, she said, would generate a valid electronic signature from a physician, which is necessary to process insurance claims but 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. The new system will allow hospital staffers to treat an online consultation as a signed order generated by a physician.

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

The hospital's technology team 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 aren't working prototypes; rather, 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, they could see the first version.

IRise is the flagship offering of privately held software vendor iRise Inc. in El Segundo, Calif. It's one of several products emerging to tackle the old problem of ensuring that software developers build what the business stakeholders really need.

"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 IDC analyst Melinda-Carol Ballou.

That's where visualization comes in. Typically, developing a software application for beta testing can take months, even with newer agile development methods. But application visualization can be done within a matter of hours to give users some insight into what that system will look like and how it will work. It also allows for early discovery of whether a developer has missed the mark in terms of creating what the user wants.

"There's an increasing awareness that this is a problem worth investing in, because people will waste a lot of time in cycles of redesign," says Tom Grant, an analyst at Forrester Research Inc.

However, he says the few tools that are currently available aren't widely used. The biggest challenge these vendors have, Grant contends, is the cultural issue of trying to get companies to move away from using applications like spreadsheets and PowerPoint to get users to articulate their requirements.

Modeling the User Interface

Mark Hilbush, vice president of information systems at United Parcel Service Inc., is a big believer in using tools to improve collaboration among developers and users. "The idea is to get as much [as possible] right upfront, and to try to work with business users in a way they can really understand what it is we're building together," he says.

Hilbush's group is building a Web-based application that will be used in UPS operations all over the world. Using iRise's Studio tool, IT has been able to model different aspects of the user interface, he says.

"We were able to put the visualization in front of users who are across the United States and Europe and the Asia-Pacific region, and [iRise] allowed us to get many more people involved in the requirements process than would normally be involved," Hilbush explains.

Not only has the tool enabled IT to quickly uncover requirements that management may not have articulated, but it also has allowed Hilbush's group to get direct feedback from people who are going to use the system on a day-to-day basis. "The last thing you want is to get to alpha or beta or user testing and find out you've missed the mark on a few key requirements," he says. "That's the power of visualization -- it lets you do that very early in the life cycle."

For this global project, a big benefit was that non-English speakers could see the prototype to make sure key requirements weren't missed. Previously, when requesting comments from international users in a requirements document, things would inevitably get lost in translation, says Tony Baldassari, a senior project manager in UPS's package project management group. But sending out a prototype lets people visualize what the new system will look like and therefore helps ensure that it's built correctly from the start, Baldassari says.

UPS's new application, an international operations processing system to clear shipments from country to country, has been reviewed several times. People have been able to see all of the visual parts, including screens, links and how they would navigate through the pages, says Baldassari.

Once users put their comments into iRise, his group gathers the feedback, consolidates it and reworks the design before sending out another round of screenshots for viewing. "It allows us to iterate very quickly and get feedback and comments and, if needed, a Round 3. By the time we've done that, we're pretty confident we have very good buy-in from all the users," says Baldassari. "We finalize that with IT, and it saves time in the development cycle."

UPS uses iRise as part of the requirements-gathering process for systems that will be used inside the company and for customer-facing Web applications. It works well on just about any type of system that has a user interface, Hilbush says, and in 2009 it was used on 43 projects out of 47 that were identified as potential candidates for iRise.

"Our philosophy is if you have a Web application or a Windows app -- or any app with a user interface -- you've got to have a pretty compelling reason why you wouldn't use visualization on that project," says Hilbush.

While he declined to give specifics on the cost of implementing iRise, Hilbush says UPS has seen a return on its investment in the software, because in projects in which it was used, there were fewer changes during the project life cycle and fewer defects later on in development.

Lessons Learned

At MD Anderson Cancer Center, officials used iRise to develop an electronic medical records (EMR) system called ClinicStation. As a hospital specializing in cancer care, MD Anderson found that out-of the-box EMR systems with predefined requirements did not meet its needs, because those packages are designed for acute care centers, says Sherry Preston, business analyst manager of MD Anderson's EMR development and support team. The hospital spent about eight years trying to get three different EMR tools customized, but none worked. "The bugaboo is the workflow," she notes.

So hospital management decided to develop its own unique system and train clinicians like Preston -- who understood the nuances of nursing, pharmacies, labs, X-rays and medical records -- to become business analysts and work with end users on getting input on the different modules that they wanted to interact with Clinic Station. "It was important because we had to be able to document and elicit requirements and understand the workflow of each corner of the hospital," explains Preston, who worked as a nurse in MD Anderson clinics for 26 years.

Preston estimates that the hospital spent less than $300,000 to purchase iRise. She says there is very little about the tool that users don't like, but learning how it works takes a significant amount of time, and "if you don't use it, you will lose it."

Another lesson learned: Preston says the iRise software required MD Andersen to buy extra memory for business analysts' laptops. It was important to deploy iRise on laptops, because analysts generally use the iRise software in meetings with users. The need for more memory "caught us by surprise," Preston says.

UPS's Hilbush emphasizes that "you need to do the iRise simulation as early in the development cycle as possible" and make sure business users, business analysts and developers are involved. "If done well, the process is very open and collaborative," he says.

MD Andersen has cut about 25% off of its overall development time by using simulation, says CIO Lynn Vogel. "Our dream would be if simulation would generate all the code. But that's a very difficult process. Coding is as much an art as a science."

Shein is a freelance writer and editor. Contact her at eshein@shein.net.

This version of this story was originally published in Computerworld's print edition. It was adapted from an earlier version that first appeared on Computerworld.com.

Copyright © 2010 IDG Communications, Inc.

It’s time to break the ChatGPT habit
Shop Tech Products at Amazon