CSC532 TERM PAPER
SOFTWARE PROTOTYPING
ANIL KUMAR.ARIKEPUDI
23RD OCTOBER 2003
Table of Contents
1. Introduction
2. Why Prototyping
3. Prototyping Process
3.1 Prototyping Plan
3.2 Outline Definition
3.3 Executable Prototype
3.4 Evaluation Report
4. Forms of Prototyping
4.1 Evolutionary Prototyping
4.1.1 Advantages of Evolutionary Prototyping
4.1.2 Disadvantages of Evolutionary Prototyping
4.2 Throw-Away prototyping
4.2.1 Advantages of Throw-Away prototyping
4.2.2 Disadvantages of Throw-Away Prototyping
4.3 Concept Prototyping
5. Tools and Techniques available
5.1 Low-Tech tools
5.2 High-Tech tools
5.3 Fourth generation languages
5.4 Evolutionary Prototyping tools
6. Benefits of Prototyping
7. Disadvantages of Prototyping
8. References
ABSTRACT:
Prototyping, the creation and enaction of models based on operational scenarios, has been advocated as a useful software engineering paradigm because it lends itself to intense interaction between customers, users, and developers, resulting in early validation of specifications and designs. An extensive and widespread interest in software prototyping in recent years has resulted in a daunting amount of literature and dozens of proposed methods and tools. As with any immature and growing technology, the expanding literature and approaches have resulted in correspondingly expansive and confusing terminology. This report presents an overview of technology and literature relating to the creation and use of software system prototypes [6].
1. INTRODUCTION:
A prototype is a version of the product that reflects only the design decisions made in the process of preparing the conceptual model, and not the decisions driven by implementation concerns. This allows the developer to probe the customer for further specifications. This process significantly reduces the risks associated with the project and the customer is less likely to request changes to the product later in the development process as they discover requirement errors and omissions early in the software process. Prototyping also allows the developers to consider the high-risk aspects of the specifications and therefore consider the feasibility of the project. This allows the customer to decide whether the project is worth while before too much of time and money are invested in the project. Basically software prototype is not intended for design validation (its design will often be quite different from the final system developed) but to validate the user requirements [7].
2. WHY PROTOTYPING:
The goal of any software processes is to reduce cost and to improve the quality of the final product. This is also used to demonstrate the feasibility of the system early in the life cycle. This method is also useful in risk assessment and as a means for validation to end users. Although there have been substantial advancements in software engineering methods and tools during the past two decades, requirements engineering still remains a key problem area in the development of complex, software-intensive systems. The toughest part of the software development is the analysis and setting of the exact requirements. One major source of continued difficulty is the lack of early requirements validation. Its not easy to validate requirements because they often are not well understood prior to development and they change frequently during development[6].
THE IMPORTANCE OF EARLY REQUIREMENTS VALIDATION [7]
3. PROTOTYPING PROCESS:
It is very important that the development of a prototype be managed correctly to ensure that maximum benefit is gained. The objective of the prototype should be made explicit before the activity begins. Various stages in the development of a prototype are depicted below.
PHASES IN PROTOTYPING [11]
3.1 PROTOTYPING PLAN:
All the objectives for developing the prototype must be considered and documented. The main goal of the initial process will be
· To gain further specification requirements from the customer.
· Convey about the ideas to the customers, what the developers believe will be vital aspects of the project.
· Knowing the more risky aspects of the project, if any.
3.2 OUTLINE DEFINITION:
This stage focuses in determining the level of functionality of the prototype and documenting these decisions. We can use a GUI with no functionality if our intention is only to demonstrate the intended design. Whereas if the goal is to get the customer to consider more functionality it may be necessary to implement large parts of the existing functionality so that the customer may consider that functionality and realize what else is necessary after interacting with the prototype. The level of functionality required will be very dependent on the goals listed in the previous document[8].
3.3 EXECUTABLE PROTOTYPE:
This stage is the development of the prototype; this will generally involve the use of some form of prototyping tool such as Visual Basic to allow the prototype to be constructed quickly. The length of this stage will be greatly dependent on the required functionality of the prototype.
3.4 EVALUATION REPORT:
At this point feedback will be gathered from both management and the customer thus allowing the prototype to be evaluated. This evaluation is then documented and considered. Three main events may happen after this stage, each of which is dependent on the evaluation.
1. The customer will be happy with the prototype and the development of the actual system will continue.
2. The project will be deemed unfeasible and the project will not continue.
3. The customer lists more requirements and the Specification will be amended to include these changes, resulting in either a plan for a new prototype of the commencement of development of the system as per the updated specifications[8].
FORMS OF PROTOTYPING:
Classification of prototyping approaches can be done according to the intended use and users of the prototype. In this sense, there are really two broad categories of prototyping approaches: “those that involve the creation of a series of fielded prototypes”, and “those intent on exploring ideas without resorting to field deployment”. The former is most commonly referred to as field or evolutionary prototype while the latter goes by many names like rapid, concept, throw- away, experimental, and exploratory prototypes.
Here we discuss three of them which are
1. Evolutionary prototyping
2. Throw-away prototyping
3. Concept prototyping
4.1 EVOLUTIONARY PROTOTYPING:
The focus is on achieving functionality for demonstrating a portion of the system to the eventual user for feedback and further system growth. Evolutionary prototype life cycle considers to first deliver an initial fielded prototype subsequent modifications and enhancements result in delivery of further more mature prototypes. The prototype is first designed, and then it is coded and tested. The developers initially do the testing, and the results are used to derive the specifications. This process continues until the user accepts the eventual product. This approach is normally used for where specifications cannot be developed upfront.
EVOLUTIONARY PROTOTYPING [11]
4.1.1 ADVANTAGES OF EVOLUTIONARY PROTOTYPING:
1. The most needed functionality will be produced first, thereby solving the user’s basic needs. This prevents the users from waiting through the entire software process to get a functional system and having to wait for another period of time if there are any discrepancies in the user's requirements.
2. This model establishes user engagement with the system. This increases the chances of producing a system that meets the users' requirements and also more likely to have users commit to the use of the system. However, this procedure requires frequent feedback from the user in order to validate and judge the success of the system [10].
4.1.2 DISADVANTAGES OF EVOLUTIONARY PROTOTYPING:
.1. The first problem that arises is the management problem. The evolutionary prototype's existing management processes always assumes a waterfall model of development which provides more visibility. Besides that, specialist skills are required throughout the process and it may not be available in all development teams.
2. The second problem of evolutionary prototyping lies with the maintenance of the system. Evolutionary prototyping requires frequent changes to the system in order to meet all users' requirements. This causes a huge increment in the maintenance cost of the system on a long-term basis. In addition, this prototyping approach also tends to corrupt the system structure through continual changes during the development phases.
3. Evolutionary prototyping does not develop a software specification, thus, causing contractual problems in the process. Software specification normally acts as a basis for a contract between the developers and the customer. Since evolutionary prototyping does not develop a software specification, contract writing for software development becomes a difficult task as requirements may sneak into the system and the intended budget could be exceeded [10].
4.2 THROW-AWAY PROTOTYPING:
This approach is beneficial when certain requirements are not clear. Software developer develops a working prototype to clarify and define the specifications with the help of the customer. The prototype is not part of the final product, so it is not necessary to maintain, and its structure is also not important as it should not influence the final product. It is used make sure that the product will meet the requirements of the customer.
Process
THROW-AWAY PROTOTYPING [11]
The system requirements are outlined and prototypes are developed for these requirements. The prototypes are then evaluated by the development team, and when required the customer will help. The specifications for the system are derived from those prototypes that meet the requirements. This cycle is repeated, and these smaller prototypes are gradually combined to form more functional prototypes. This process continues until the customer is satisfied with all the specifications. While the prototyping and the specification processes continue, the software development proceeds with the derived specifications. Where there are reusable components in the prototype, these are further refined and added into the system.
4.2.1 ADVANTAGES OF THROW-AWAY PROTOTYPING:
1. Unlike upfront specifications, these can be used to allow the customer to further define the product as it is being developed.
2. The throw away prototypes can be written in a language other than what is used for the final system to speed up the process of creating the prototype.
3. The prototype is not documented and it is not intended to be part of the final product. It is mainly used to define the specifications for the product. This reduces the overall time that would have been spent on writing the specifications upfront, and leaves the fine details for later where the specifications are further defined with the help of the prototypes [10].
4.2.2 DISADVANTAGES OF THROW-AWAY PROTOTYPING:
1. Throw-away prototyping gives more flexibility to the customer, because they can further define the product as the development proceeds. But, they will tend to find it difficult to turn away these prototypes as simply prototypes that are not part of the final product.
2. If the developer is under pressure to finish the final product, they may use parts of the prototypes in the final product. As a result this may lead to other problems, and it will make software maintenance very difficult and costly [10].
4.3 CONCEPT PROTOTYPING:-
Concept prototyping is a mechanism for achieving validation prior to commitment. Concept prototyping may be used to validate requirements prior to commitment to specific designs. Similarly, concept prototyping may be used to validate potential designs prior to commitment to specific implementations. In this sense, prototyping as a software development paradigm can be seen as tacit acceptance that requirements are not fully known or understood prior to design and implementation. Concept prototyping can be used as a means to explore new requirements and thus assist in the ongoing evolution1 of requirements [6].
5. TOOLS AND TECHNIQUES AVAILABLE:
The various tools come in many different forms ranging from languages to applications, even the humble pen and paper may be classed as a prototyping tool.
5.1 LOW TECH TOOLS:-
In the earliest design stages prototypes are often just pictures, charts and notes designed to facilitate communication between the customer and the developer. This type of prototyping is also known as “low tech” and both the customer and the developer may take an active part in this form of prototyping. Low tech is also the cheapest form of prototyping. Suitable tools include:
· Word
· PowerPoint
· Visio
5.2 HIGN TECH TOOLS:-
The following sections outline the tools that are suitable for “high tech” prototyping, which is where technical skill is necessary to build the prototype. A high tech prototype is an implemented system that has functionality. The customer will be able to use the prototype and observe its behavior. Other prototyping tools are necessary when deciding on the layout of the software that should take the arrangement of a GUI or a set of web pages.
· Visual Basic
· Denim
· EasyPilot
5.3 FOURTH GENERATION LANGUAGES:-
The next level in prototyping involves the use of 4th Generation Languages (4GL’s), which are results orientated, compiled or interpreted and less efficient than most other forms of code. 4GL’s are often useful for applications containing databases. The key concern when using a 4GL is the loss of efficiency and flexibility as this may impact design decisions [4].
· SQL
· MySQL
· Access
· Abeille
· Sculptor
5.4 EVOLUTIONARY PROTOTYPING TOOLS:-
The following tools are more flexible then those previously mentioned and are popular for use in evolutionary prototyping because they are also suitable for general development and thus it is suitable for the final system to still be written in them.
· Smalltalk
· Lisp
· XML
· PHP
· Java [4]
6. BENEFITS OF PROTOTYPING:
· Missing user services may be detected.
· Difficult-to-use or confusing user services may be identified and refined.
· Software development staff may find incomplete and/or inconsistent requirements as the prototype is developed.
· A working, albeit limited, system is available quickly to demonstrate the feasibility and usefulness of the application to management.
· The prototype serves as a basis for writing the specification for a production quality system.
· It can be used for training users before the production-quality system has been delivered.
· It can be used during system testing to run 'back-to-back' tests. This means that the same test cases are submitted to both the prototype and to the system being tested [4].