Readers of Mike Kelly’s post on software security uses for data visualization –- the ability to visualize patterns of data –- asked us for info on application visualization, too. Application visualization enables software developers, testers and users to see and interact with a fully functional prototype or simulation of a proposed application before coding. We’ll be covering both visualization topics more in this blog and on SearchSoftwareQuality.com.
In this post, I share excerpts from my interview with application visualization expert, Maurice Martin, president, COO and founder of iRise, a maker – of course – of application visualization products.
Developers and business analysts seeking to get software requirements right will find visualization far more effective than text documentation and diagrams, according to Martin. Planning to visualize applications in high fidelity before coding can ensure that the right requirements are captured early in the process.
Imagine giving stakeholders a fully-functional, working prototype early in the process; development teams can secure the right feedback early in the process, before any expensive coding happens.
“Instead of a stakeholder review meeting where everyone is flipping through giant binders of text requirements and struggling to understand what’s been written, now everyone can ‘test drive’ the application live,” Martin said. “The magic happens when changes are made to the visualization right in the stakeholder review meeting, cutting days, weeks or even months off the requirements cycle time.”
Application visualization is a paradigm-changing technology and approach for software development, in Martin’s opinion. Business analysts are no longer just reviewing text requirements, they’re “now rapidly iterating functional prototypes directly in front of the business stakeholders,” he told me. The result is quicker capture of more accurate requirements for designing and developing code, building test scripts and writing documentation or training content.
Until business analysts, developers and users can see, interact with and fully experience the application, they can really only guess at the requirements, Martin said and then continued, saying:
“Add to this the fact that the tools and processes used by most BAs are antiquated at best, and it’s no wonder project overruns, delays and missing features are all-to-common outcomes. The sad truth is this: the state-of-the-art in requirements definition for many organizations is still a giant text document, maybe annotated with a few static screen shot mock-ups or use case diagrams. Let’s face it, the cycle times to create these documents are long and the business stakeholders don’t understand –or read — these giant binders. This would be analogous to designing a new car, airplane, building or semiconductor today with a drafting board. It simply doesn’t happen in other industries; why are we still designing software this way?”
Visualizations can provide guides for what to build, eliminating confusion and enabling developers to focus on what’s important; architecture, design, coding and delivery, Martin said. He’s found that visualization can cut down on change orders and eliminate about 70% of downstream rework. In short, visualizations forces the business to articulate what they want in a language everyone can understand.