Prototype
(Alias: mock-up, model)
The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. [...] Hence plan to throw one away; you will, anyhow.
- Fred Brooks, The Mythical Man-Month: Essays on Software Engineering
A prototype is a working model of a system developed to demonstrate and validate a customer's expectations of major functions and user interfaces.
The Role of the Prototype in Software Development
The prototype is used to:
- Determine the feasibility of user requirements and design approaches
- Determine the necessity of a function
- Uncover missing requirements
- Determine the viability of a user interface
- Engage the end user in system design
- Test the viability of new technology.
Prototypes are used where the requirements of a system are not well understood or a new design approach is being trialed. Experience has shown that working models can improve communication with the user or, in the case of design, help solidify a practical design approach.
Prototypes are developed with small teams using high productivity tools that are typically not those of the target production environment.
The Benefits of Using a Prototype
Projects that adopt a prototyping approach experience the following benefits:
- Discovers missing requirements. End users operating a working system (as opposed to reading a document) are much more likely to identify missing functions and data
- Increases active user participation. End users take a more active role in determining system functionality. Prototypes generate more interest and therefore more active, creative involvement. The risk of user rejection of the production system is significantly reduced
- Validates requirements early. The customer is able to verify that the system will work in the business environment early in the development life cycle
- Migrates iteration earlier in the life cycle (where it's much cheaper). In environments where requirements are not well understood some iteration is always necessary. If a user must wait until a production system is delivered to identify problems, the corrective action can be extremely expensive. If the iteration is done in the requirements phase using a prototype, significant cost savings can be made as prototypes can be changed at low cost and the turnaround time between iterations can be one to three days
- Clarifies system scope for estimation. A prototype provides a more accurate model of the end system (when compared to a document) allowing developers to get more precise function point counts, the end result being a more accurate cost estimate to complete.
Attributes of a Good Prototype
- It works. It can be operated by user without a developer behind the curtain
- It is ergonomically sound. It can be operated by a user with minimal training
- It has a user guide. It has basic user documentation
- It looks like the end product. It approximates the look and feel of the proposed system: same user interface, same inter screen flow
- It provides all primary functionality
- It traps errors. It provides error detection and correction.
Prototypes Are Not Production Systems
Most prototypes are not suitable for deployment as production systems as they DO NOT have:
- Robustness. They are typically unstable
- Performance. They will be slow and unstable when scaled to production use (example: multiple concurrent users, high transaction rates)
- Concurrency control. They are designed for single user environments. For example, data may be corrupted if two users attempt to update the same information concurrently
- Security. They do not provide user access control or audit trails of user activity
- Completeness. They only demonstrate part of the system's functionality
- Recovery/restart. They do not address recovery from system failure modes
- Operational documentation. They are not formally specified
- Quality control. They are not thoroughly tested.
Member Comments |
26 Comments |
18 member ratings |
|
✭ ✭ ✭ ✭ ✩
|
|
|
