About prototyping

Quite often the requirements are uncertain, i.e. ideas are not clear about what the required software should look and behave. Telling the programmer to do what he thinks is the best thing results in a design that may be quite elegant and maintainable but that probably is not satisfying at all for the user. Only the user can really say the last word about which feature are useful and which are not. Only the user, or a person that observes the user’s behavior, can say if a user interface is really usable or not.

Too often a system is built according reasonable requirements and then abandoned or heavily changed because the original requirements resulted in an unusable system. Of course a way to minimize the cost of such am outcome is to build a highly maintainable system, that may be changed rather easily. Another way is keeping the user informed of the progress of the development, so that any change of mind may be incorporated early in the development process.

These cited two techniques (maintainability, and continuous feedback) are advisable in any case, but another technique is advisable to ease a better requirements specification: prototyping.

In the software engineering world, the word prototyping means building a software system for the sole purpose of demonstrating the feasibility of a system, and evaluating its impact. Using a building simile, it is like building a scale model.

The simile is not perfect because a scale model is not a real building, while a prototype of a software system is a real software system. A prototype differs from the real system for the following aspects:

  • A prototype is built using a rapid application development tool, that eases development at the expense of the flexibility, testability and maintainability of a software system built to endure time.
  • A prototype does not really work with real data. The user may insert his input data, but when he asks the results of the computation or of the query, the prototype shows always the same precomputed date, without performing any computation and any database connection.
  • Some buttons or menu items are mock, with no performed command.
  • The user interface is not internationalized.
  • The software is not configurable.
  • Only the most typical scenarios are shown.
  • Prototypes are not formally tested, only shown to the user to get feedback.

But the most important thing to say about prototypes is that the software written to build a prototype should be thrown away and not reused for the real system, as it is tempting. To avoid such temptation, it is advisable to use different development tools or programming languages for the prototype and for the real system.


About Carlo Milanesi

I am a software developer in Italy. I have develop financial, engineering and commercial software using many programming languages, mainly C, C++, Visual Basic, Java, and C#. Now I am interested in Rust and TypeScript.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s