space13left
spacer
 
 
 
 
   
Rapid Prototyping

As part of our normal Feasibility Analysis, or following up on it, our Professional Services team will propose creating a rapid prototype as a further, practical proof-of-concept. Such a prototype will demonstrate key elements of the solution. It will illuminate both the appropriateness of the chosen technology path and its specific relevance to the business needs scoped out during feasibility analysis.

Developing the prototype normally entails a team of one to three people working two to four weeks. The development period begins after completion of the scoping work, normally performed in the Feasibility Analysis stage, to identify the project's direction and extent.

Goals and Elements of Rapid Prototypes

The best way of judging the value of an approach or design is to see a mini-solution that brings the thing to life. SQLstream is a strong advocate of building early mock-ups and prototypes.

We support an iterative development life-cycle rather than a strict waterfall model. We have found that the iterative approach maximizes opportunities for involving stakeholders --- users, designers, management, etc. --- in assessing models and methods as well as providing substantive useful course corrections. These can, often enough, include new insights affecting scope, design, integration opportunities, and efficiencies deriving from new perspectives on cost reduction, design elements, and ways to add business contributions.

Thus, creating a rapid prototype usually has the following two goals:

  • To remove risk by demonstrating executable feasibility for the proposed development, given particular cost, time, and performance constraints

  • To help visualize one way of solving the problem in order to elicit feedback that can steer the next iteration of development

In the service of these goals, a rapid prototype typically includes elements of the following types:

  • A dynamic data model for a relevant subset of the key streams and message fields

  • A data generator or data subset for input to the prototype

  • Sets of SQL views and queries to process the data

  • Appropriate adapters or plug-ins to provide application-specific processing or data integration

  • Implementation of a subset of the main processing path of the intended application

  • A disposable UI to illustrate the operation of the prototype

The code of the prototype is generally disposable, and will be replaced by the first iteration of the solution you or we will develop,