Human Factors

Both client and future users must interact with the rapid prototype of the user interface.

	Reduces the risk of alteration to the final product.
	HCI = Human Computer Interface
	User Friendliness - ease with which human beings can communicate with the software product.

Need for user friendliness led to Menu-Driven products.

User selects from a set of possible responses

GUI = Graphical User Interface

HCI's employ graphics

	windows
	icons
	pull down menus

"Point and Click" selection to select a response Some human factors include:

	size of letters
	capitalization
	color (in different cultures, colors mean different things, so one should limit the amount of color)
	line length
	number of lines on the screen

Avoid delays that can anger users, such as a lengthy sequence of menus to achieve a simple operation.

User should be able to change a previous selection without having to return to the top level menu.

Different sets of HCIs can be used, tailored to the skill level and psychological profile of its intended users. Although HELP facilities must always be provided, they will be used less with a carefully designed HCI. Uniformity of HCI appearance across a product or group of products can result in users intuitively knowing how to use a screen they have never seen before. Benefits from considering the HCI

	Reduces learning time.
	Lowers error rates.
	Can also increase user productivity.

Rapid Prototyping as a Specification Technique

	A superficially attractive but dangerous variant of the prototyping model.
	Dispenses with specifications as such and uses the rapid prototype itself either as the specifications or as a significant part of the specifications.
	Advantage:

	offers speed and accuracy
	State that the product will do what the rapid prototype does, and list any additional features that the product must support, such as file updating, security, and error handling.

Disadvantage:

	unlikely that a rapid prototype will stand as a legal statement of a contract between developer and client.
	Potential problems with maintenance due to lack of documentation

because the rapid prototype is the current version of the specs, you don't necessarily have documentation of the prior versions.

 
 
 
 
 
 
 
 

Reusing the Rapid Prototype

	Another superficially attractive but dangerous variant of the prototyping model.
	Evolutionary Approach: develop and refine the rapid prototype rather than discard it.

	If not careful, this process can disintegrate into BuildandFix.
	Changes have to be made to a working product.
	Issue of performance:

	performance is important, especially in real-time systems
	because a rapid prototype is based on functionality, performance issues are not handles
	unlikely that response times and other timing constraints will be met.

One way of ensuring that the rapid prototype will be thrown away, and that the product is properly designed and implemented, rather than attempts made to refine it, is to build the rapid prototype in a different language from that of the product. One instance when it is permissible to refine a rapid prototype or, more specifically, portions of the rapid prototype:

When portions of the rapid prototype are computer generated, then those portions may be used in the final product.

Example: User interfaces generated using CASE tools such as screen generators and report generators.

Hybrid approach:

	In some organizations, management decides before the rapid prototype is constructed which portions may be used in the final product:
	Portions must pass the same quality assurance tests as other software components.
	Problems:

	components that are of sufficiently high quality to pass design and code tests are not usually found in rapid prototypes
	to ensure quality, must be built slower than "rapid"

Advantage:

Recovery of some of the time and money spent on developing the rapid prototype

Other Uses of Rapid Prototyping

	Means of arriving at a consensus when there is a disagreement among requirements analysis team (disagreement between client and developers or disagreement among the clients).
	Schach recommends the use of a rapid prototype as a requirements analysis technique.
	A rapid prototype can take the place of specifications for some types of products, but can never replace design.
	Main characteristic of the Rapid Prototyping model is that there is much more interaction with the client.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Management Implications of the Rapid Prototyping Model

Client requests increased number of major changes

due to perception about ease of change brought about through use of rapid prototype

Client expects a quick implementation

	because of speed with which prototype was produced
	Prototype not operational quality so client has to wait

Vital that management be aware of the advantages and disadvantage of rapid prototyping. Prototype products result in less code and less effort but not as much functionality Specifying produces more coherent designs and software that is easier to integrate.

Ease of integration is important for large-scale products, especially for C4I software

Command, control, communications, and intelligence.

Because the rapid prototype is rapidly thrown together, if it is kept, the following problems can ensue:

	poor design
	difficulty with maintenance
	poor performance

 
 
 
 
 
 
    Experiences with Rapid Prototyping

39 case studies of Rapid Prototyping by Gordon and Bieman

	33 successes, 3 failures, and 3 not rated.
	Incomplete data and specific topics may not be explicitly mentioned
	Found that rapid prototyping meets client needs
	Choice of language does not appear to be of critical importance.
	Risks involved with retaining a rapid prototype (bad design, hard to maintain, and poor performance) appear to grow in proportion with the size of the product.

 
 
 
 
 
 
 
 
 
 
 
 
 
 

Joint Application Design (JAD)

Also called Joint Application Development

A related method is called Participatory Design

JAD is an extended form of rapid prototyping in which the client organization plays a more active role.

	A technique for the requirements and specification phases
	Users and developers work as a team and take joint responsibility for the result.

Productivity increases of 20 to 60% have been reported using JAD Team leader must be a skilled facilitator

	JAD team leader should not have a vested interest in the success of the project.
	Aim of the team leader should be to obtain a consensus without having a specific interest in the decisions.

 
 
 
 
 
 
 
 
 
 
 
 

Comparison of Requirements Analysis Techniques

Interviewing = the primary requirements analysis technique

any combination of techniques must include interviewing

Rapid Prototyping is the most accurate analysis technique

Unless rapid prototyping or a related technique such as JAD is used, there is risk the the requirements analysis phase will not be performed properly and the client's needs will not be completely met by the product.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Testing during the Requirements Phase

Users (not necessarily the same entity as the client) must be given the opportunity to experiment with the rapid prototype.

Users suggest changes that, when approved by the client, will be implemented.

SQA (Software Quality Assurance Group) ensures that relevant individuals have the opportunity to interact with the prototype, and to make sure that their suggestions reach the client or committee of client managers responsible for analyzing suggestions.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

CASE Tools for the Requirements Phase

Interpreted languages work well for rapid prototyping

	do not have to be compiled or linked
	faster development
	difficult to maintain but this is irrelevant if the prototype is to be discarded

CASE tools:

	Smalltalk - has an environment to assist user with a variety of tools
	Interlisp environment - for Lisp programmers
	Java environments
	UNIX shell programming language
	Hypertext - ensures that prototype will be discarded

CASE tools for rapid prototyping of user interfaces:

	Demo II
	Guide
	Hypertext

	Hypercard
	Hypertalk

4GL (fourth generation languages)

	fewer statements are needed to achieve the same functionality
	many are supported by powerful CASE tools
	Examples of 4GLs that can be used:

	Oracle
	PowerBuilder
	SQL

Management must be shown that the cost of a rapid prototyping tool or workbench is small compared to the potentially huge expense of trying to convert a rapid prototype into production quality software and then attempting to maintain that product.
 
 
 
 
 
 
 

Metrics for the Requirements Phase

	Need for Metrics: IEEE definition of software engineering includes "quantifiable approach".
	What is important is how rapidly the prototyping team determines the client's real needs.
	Meaningful metrics for the requirements phase include:

	requirements volatility - how frequently the requirements change
	how many times a certain feature was tried (HCI) with rapid prototype
	number of requirements that change during the rest of the software process

if many requirement change during subsequent phases, then the methods of the requirements team need to be analyzed.

 
 
 
 
 
 
 
 
 
 
 
 
 
 

Object-Oriented Requirements?

	There is no such thing as Object-Oriented Requirements, nor should there be such a thing.
	Requirements Phase is a determination of the client's needs, that is, what the functionality of the target system should be.
	The requirements phase has nothing to do with how the system is to be built.
	However, in the construction of a rapid prototype, some insights may be gained into the fundamental building blocks of the product to be constructed.

This information may be useful in O.O. class extraction.