PROTOTYPING

"Plan to build two systems and throw one away- you will anyway" (Brooks)

Prototyping is a technique of risk reduction. Prototyping is one means for addressing uncertainty. Experiment shows that the prototyping approach shows that this approach took 40% less time and resulted in 45% less code. From the prototype, developer can generate a system more quickly by using existing program fragments.

Prototyping consists of requirements and analysis gathering, quick design, prototype building, client evaluation, prototype refining and product engineering. This cycle continues until the required system is developed. The concept of prototyping is particularly for maintenance. In simple words, a prototype is created before the final product is built so that any adjustment or addition features and requirements can be implemented before the final system is built. Ideally, prototyping is done to test the principles, to ensure the system works, and to obtain design feedback which enables design to be altered and corrected before the money is spent.

1. Requirement gathering & analysis

Software developer and client identify the overall objectives, requirements and specification for the prototype.

 

2. Quick Design

A "Quick Design" of the prototype allow client to evaluate what and how the real prototype works.

 

3. Build prototype

After iterations of evaluation from the client, a prototype is build.

 

4. Client evaluation

At this phase, client evaluates the prototype. The prototype is "tuned" to satisfy the requirement of the client.

 

5. Refining prototype

Refinements of requirements are made to the prototype so that client are satisfy and comfortable with the new system.

 

6. Engineer product

There are two kinds of prototyping, which have different objectives and two different types of implementation:

• Evolutionary
• Throw-away

The objective of evolutionary prototyping is to deliver a working system to end- users. The prototype is designed to form the basis for development of the final system. The objective is to build an implementation that is well understood by the client/end user. The final system is developed under constant evolutions of the prototype so that new features can be added and requirements can be refined as proposed by the client/end-user.

The objective of throw-away is to validate or to derive the system requirement.

Throw-away prototyping starts with poorly understood requirements. The prototype is designed in this way so that vague specification and requirement outlines can be ascertained. This is intended to clarify requirements and provide additional information for managers to reduce risk. Throw-away prototyping is intended to determine the system specification so that the final system follows the requirements set by the end-user.

Strengths

• A "quick design" can be developed for the client/end user to try out requirements before agreeing to it; however the design is limited.
• Allows system to be developed and delivered rapidly.
• Clients are able to propose any additional requirements and features in the software process.
• Clients can discover requirement error or oversight early in the software process. Requirement validation is performed since users are able to experiment with requirements and the system.
• Incomplete and /of inconsistent requirement can be found.
• Misunderstanding between software developer and client may be identified.
• Maintenance will be low due to fewer changes after the system is in operation.
• The final system is the expected result set by the client.
• The end result will have better user acceptance.
• Clarification and specification between the client and the software developer before the system is built. Therefore, reducing risk of unexpected change.
• Documentation need is reduced.

Weaknesses

• Important characteristic such as performance, security, robustness and reliability may be left out during the prototype development.
• Progress is difficult to measure since it is not visible. If systems are developed rapidly, documentation is not created.
• Schedule expectation of users and software developer tends to be unrealistic with respect to the throw-away prototypes.
• The prototype may not correspond to the way in which the final system is used, especially with the throw-away prototype.
• Continual change from the client tends to corrupt the system especially when the system maintainers are not the original software developers.
• System will be difficult and expensive to maintain due to the system changes made.
• Prototype clients/user may be pressured by software developers to draw quick responses concerning the prototype.
• Lifetime of the prototyping system is not long. As the structure of the system is unmaintainable, it must be completely rewritten.

 Appropriate and Inappropriate Domains of Application in Prototype Model

Appropriate domain

• The development of relatively small system. The entire system may need to re-write whenever major changes are needed and when the system is unmaintainable.
• System which must need immediate needs in a short period of time.
• The development of a system with short life span. The system is developed in a short amount of time because of the constant changes in the system.
• The development of systems or modules of larger systems for which detailed specifications cannot be defined in advance, such as artificial intelligence systems.

Inappropriate Domains

• Large scale system should not be developed using prototyping.
• Systems with a long life span should not be developed using prototyping.

There are a number of methods which can be used for system prototyping. In fact, there are three generic classes to do rapid prototyping.

Developing a prototype from a formal specification language combines unambiguous specification with a prototype. There are no additional costs in the prototyping development after the specification has been written.

One of the practical difficulties is that the prototype development may not be particularly rapid. This is because the formal specification requires detailed system analysis and time to have a detailed modeling after the prototype evaluation.

Using 4GLs for developing data processing is very cost effective especially in small systems. Fourth Generation Techniques-based development can be used for evolutionary prototyping or in conjunction with a method based analysis to generate the prototype.

Example:

• 4GLs are used with CASE to build a small to medium-sized system

Prototypes can be developed in a short time if there are a library of reusable components and mechanism to compile these components into the system.

An example of this approach of prototyping can be found in

• UNIX.

The success of the Smalltalk and Lisp is due to their reusable component libraries in their language facility.

• http://osiris.sunderland.ac.uk/rif/linda_spence/HTML/2.1.4.html

• Software Engineering by Ian Sommerville

• Software Engineering, A practitioner's approach, Third Edition by Roger S. Pressman

• http://enuxsa.eas.asu.edu/~calliss/cse560/class_notes/Lifecycles.htm

• Dr. Hines's class note