Prototyping, the iterative modeling of a system, enables users to be actively involved in the development process. The methodology which provides a working model of the system throughout development allows errors, missing functionality and confusing or difficult functions to be detected early, reducing risk of sub-optimal ROI on the finished project. In addition, prototyping provides users with a greater sense of involvement leading to increased organizational visibility, and stakeholder buy-in and funding.
The purpose of prototyping is to reduce the risk of getting it wrong but if third-party prototyping software presents you with developmental hurdles, the chances of getting right can be slim.
Though prototyping software is widely available, all solutions are not created equal. What if it can’t represent something your real solution can support? What if it lets you do something your real tool does differently? And what if at the end of the prototyping effort you’re left with something that still needs to be translated and configured into the real tool? The purpose of prototyping is to reduce the risk of getting it wrong but if third-party prototyping software presents you with developmental hurdles, the chances of getting right can be slim.
Common Problems With Prototyping
Many prototyping solutions utilize so-called “throwaway” methodology, in which a model is created, only to be eventually discarded. The steps involved are typically:
- Write preliminary requirements
- Design the prototype
- Modify prototype based on user testing
- Repeat as many times as necessary
- Write final requirements
- Discard the prototype
- Develop a production-ready system
While useful for generating feedback from end-users, throwaway prototyping can result in significant duplication of efforts as well as several common problems described on
End-User Issues: A prototype is a work in progress. It will evolve throughout each stage of the project and in the case of a throwaway prototype be scrapped entirely. However, many users will view a prototype as a near-complete model, drawing incomplete conclusions on features that are meant to be changed or they may assume that the prototype is near complete, and won’t change at all.
Developer Issues: It can be difficult for developers to focus on a holistic view of the completed project when presented with a prototype. Rather than using the prototype as a tool to assist in a proper analysis, they can easily get caught up in insignificant minutiae of the prototype itself resulting in a final project that doesn’t meet proper architectural standards.
Efficiency Issues: Developers must strike a balance between developing a prototype that is only half-baked and one that is near completion. An effective prototype should be developed quickly and assist in the fine-tuning the finished product. It is only when these requirements are met that a prototype can be considered successful and if they aren’t, productivity and efficiency are sacrificed.
“If only we could validate the design in the actual system ”
PolicyWriter is different. Integral to Adaptik’s P&C policy administration solution is evolutionary prototyping methodology a significantly different approach than throwaway prototyping. Evolutionary prototyping allows for the structured building and refinement of prototypes into finished software; the first prototype represents Version 1 of the application, and each subsequent iteration gets you closer to the production-ready version of the system.
This technique allows the development team to routinely add features and make changes that couldn't be conceived during the requirements and design phase. Do your users ever change their mind about what they want once they see it built based on their specs? Of course they do! So why not begin the project with the ability to adapt to inevitable changes?
Leveraging Robust Configuration Tools
PolicyWriter lets you configure nearly everything a page, an item, a coverage, a rule, page flow order or a user interface layout feature then immediately review it in the end-user test environment. Don’t like it? Change it. Do like it? Keep it, it’s ready for use with no translation, no reconfiguring, and no coding. It's really as simple as that. What’s more, system behavior is based on the configurations a fact that remains true in design, development, integration test, model office, UAT and production environments.
Integration is simple, too. PolicyWriter’s interface integration capabilities built on industry-standard XML allow you to adjust an interface by simply appending a data element, then send example XML or XSD to a services developer with a few clicks.
Patented Methodology
PolicyWriter’s integral prototyping is based on leading edge technology that has earned multiple patents. The capability PolicyWriter’s prototyping brings our clients who save time, money, and frustration by not throwing away good development work isn't just evolutionary. It's revolutionary.
