Bryan MacLean — Fri, 07 Jan 2011 19:39:59 GMT

I’m with Simunication and have talked with many different companies regarding simulation & prototyping. I am a developer/analyst by trade and I’d like to share some observations …with my Simunication hat off :-)

Firstly, I agree with Scott that there is no doubt that simulation/prototyping tools are real, effective and here to stay. It’s a reflection of the maturing process of the ~20 year old enterprise/web software industry. It took a century for airplane, auto and manufacturing sectors to mature processes like simulation.

I think what will be interesting to see is how the role of simulation will evolve in app development. In regards to this forum, the BA role was created to fill a communication gap between computer programmers and the business users yet we still have an endemic requirements problem. This is not a reflection on the BA’s competence, as many other factors come into play as we know. Now viewed from another level, the BA is now being asked to perform the role of computer programmers to build simulations, now “possible” with the support of these new tools. Will that work better? Maybe?

Now throw in new methodologies like Agile with developers typically programming a prototype with the intention to evolve and refactor it into the end application. This prototype is developed in short increments and reviewed constantly with the stakeholder to address inevitable changing requirements. Will that work better? Maybe?

I think the combination of these two approaches suggest the following to increase the project success rate:
1.) an interative process with customer involvement is necessary
2.) a prototype or simulation be developed in the elaboration phase, nothing beats this to flush out user requirements
3.) the simulation tool must support that a user could be any of the following, BA,UX, IA, Architect, developer, etc. with the nature and risk level of the project dictating the skills required to build a simulation that ultimately will put the customer at ease at signoff
4.) the simulation can’t be thrown away and minimally must export real assets for development, in the future maybe even evolvable into the final application

If I was starting a software project, there is no question I would simulate or prototype first. My tool considerations if I was new to simulation would be both short and long term. In the short term, I’d try several tools on several projects, and insist with vendors on a free trial of a month or two. There is a relatively low learning curve to most tools and little risk of jeopardizing a project. After trying a project or two then you can see what features work for your own particular environment.

Long term I suspect the following feature questions will weigh heavily on product choice: Do you need true interactive data driven simulations or dynamic screen flows? Will you mainly be creating high or low fidelity? Do you need reusability so you don’t have to start from scratch every time? Do you need exportable assets like HTML/JS/CSS? Do you need web based distribution? Do you need requirements export to tools from Borland/IBM/Telelogic etc? Do you need incubation that gives the customer the ultimate simulation experience?

(Simunication hat on) Let me just update the information provided regarding Simunication. Our product was renamed to Simunicator about six months ago with a new AJAX version made available a couple of weeks ago with new features and improved usability.

It’s an early market and all products are evolving very quickly. The users will dictate the product features through forums like this and thoughtful insight is always appreciated.

Boxes and Arrows: Comments by Bryan MacLean