Filetype PDF | Posted on 30 Jan 2023 | 3 years ago
Authentication
digital resources
306x Filetype PDF File size 0.25 MB Source: bulletin.feccupit.ro
85
RAPID PROTOTYPING FOR SOFTWARE PROJECTS WITH USER
INTERFACES
1 2
1 Ali Tizkar SADABADI , Naser M. TABATABAEI
State Engineering University of Armenia (SEUA), Department of Computer Systems and
Informatics 2 Seraj Higher Education Institute, Iran
al_tz2@yahoo.com, n.m.tabatabaei@gmail.com
Key words: rapid prototyping, software, development process,
Abstract: Rapid prototyping is a process for creating a realistic model of a product’s user
interface. A rapid prototyped user interface is easy to change and gets customers involved early in
the design of the product. To prototype successfully, you should pick a rapid prototyping tool that
meets your needs, form a small prototyping team, get lots of customer feedback, and iterate until
customers are delighted with your user interface. A prototype typically implements only a small
subset of the features of the eventual program, and the implementation may be completely different
from that of the eventual product. Prototyping has several benefits: The software designer and
implementer can obtain feedback from the users early in the project. The client and the contractor
can compare if the software made matches the software specification, according to which the
software program is built. It also allows the software engineer some insight into the accuracy of
initial project estimates and whether the deadlines and milestones proposed can be successfully
met. The degree of completeness and the techniques used in the prototyping have been in
development and debate since its proposal in the early 1970's.
1. INTRODUCTION 2. ELEMENTS OF SUCCESSFUL
RAPID PROTOTYPING
The process of prototyping involves the
following steps: Successful rapid prototyping is performed:
1.Identify basic requirements: Determine •Quickly – The first pass must be done
basic requirements including the input and quickly, and subsequent improvements should
output information desired. Details, such as be incorporated immediately. While the
security, can typically be ignored. prototype needs to give customers a realistic feel
2.Develop Initial Prototype: The initial for the product, it does not need to include
prototype is developed that includes only user special graphics or computational algorithms
interfaces. that require a lot of time and effort to create.
3.Review: The customers, including end- •Iteratively – The prototyped user interface is
users, examine the prototype and provide reviewed, commented upon, improved, and
feedback on additions or changes. reviewed again in a repeating cycle. No one
4.Revise and Enhancing the Prototype: Using creates a perfect design the first time. This
the feedback both the specifications and the iterative cycle allows you to gradually improve
prototype can be improved. Negotiation about the user interface. These cycles can be
what is within the scope of the contract/product completed more quickly if the prototype is easily
may be necessary. If changes are introduced then changed.
a repeat of steps #3 ands #4 may be needed. •Using domain experts – Ideally, the
prototype should be built by a domain expert.
ISSN – 1453 – 1119
86 UNIVERSITY OF PITESTI – ELECTRONICS AND COMPUTERS SCIENCE, SCIENTIFIC BULLETIN, No. 9, Vol.2, 2009
Domain experts are familiar with the user – his requirements. In rapid prototyping, customers
or her job, expectations, requirements, jargon, are involved directly throughout the
and priorities. These people may have done the development process. Also, the traditional
user’s job in the past. Domain experts can do the process goes from requirements, to design, to
best job of incorporating user requirements into development in a fixed series of steps. In rapid
the prototype. If your prototyping tool is too prototyping, the process is iterative. This makes
difficult for the domain expert to use, make sure it easier to change or add requirements that will
that the domain expert works closely with the make the product more popular with customers.
programmer. There are two obvious differences between
the traditional product development process and
3. TRADITIONAL DEVELOPMENT the rapid prototyping process shown in Figure 1.
PROCESS VERSUS RAPID These differences are customer involvement and
PROTOTYPING PROCESS iterative design. Customers are involved only
indirectly at the beginning of the traditional
The traditional process used to develop a process, when marketing and planning specify
product follows the general steps shown in requirements. In rapid prototyping, customers
are involved directly throughout the
Figure 1. During Step 1, “Analyze Proposed development process. Also, the traditional
System,” marketing and planning identify a process goes from requirements, to design, to
customer need and determine whether the development in a fixed series of steps. In rapid
company can develop a product that will prototyping, the process is iterative. This makes
profitably meet that need. In Step 2, “Specify it easier to change or add requirements that will
Requirements,” marketing and planning draft make the product more popular with customers.
general requirements for the proposed product.
In Step 3, “Design System,” development writes 3.1. Types of prototyping: Throwaway
detailed specifications for the proposed product. prototyping
In Step 4, “Develop System,” development
creates the product. In Step 5, “Release Throwaway or Rapid Prototyping refers to
Product,” the company releases the product. the creation of a model that will eventually be
There are two obvious differences between discarded rather than becoming part of the
the traditional product development process and finally delivered software. After preliminary
the rapid prototyping process shown in Figure 1. requirements gathering is accomplished, a
These differences are customer involvement and simple working model of the system is
iterative design. Customers are involved only constructed to visually show the users what their
indirectly at the beginning of the traditional requirements may look like when they are
process, when marketing and planning specify implemented into a finished system.
requirements. In rapid prototyping, customers Rapid Prototyping involved creating a
are involved directly throughout the working model of various parts of the system at
development process. Also, the traditional a very early stage, after a relatively short
process goes from requirements, to design, to investigation. The method used in building it is
development in a fixed series of steps. In rapid usually quite informal, the most important factor
prototyping, the process is iterative. This makes being the speed with which the model is
it easier to change or add requirements that will provided. The model then becomes the starting
make the product more popular with customers. point from which users can re-examine their
There are two obvious differences between expectations and clarify their requirements.
the traditional product development process and When this has been achieved, the prototype
the rapid prototyping process shown in Figure 1. model is 'thrown away', and the system is
These differences are customer involvement and formally developed based on the identified
iterative design. Customers are involved only requirements.
indirectly at the beginning of the traditional
process, when marketing and planning specify
ISSN – 1453 – 1119
ALI TIZKAR SADABADI, NASER M. TABATABAEI
Rapid Prototyping For Software Projects With User Interfaces 87
Figure 1. Traditional and Rapid Prototyping Product Development Processes
The most obvious reason for using Making changes early in the development
Throwaway Prototyping is that it can be done lifecycle is extremely cost effective since there is
quickly. If the users can get quick feedback on nothing at that point to redo. If a project is
their requirements, they may be able to refine changed after a considerable work has been done
them early in the development of the software. then small changes could require large efforts to
ISSN – 1453 – 1119
88 UNIVERSITY OF PITESTI – ELECTRONICS AND COMPUTERS SCIENCE, SCIENTIFIC BULLETIN, No. 9, Vol.2, 2009
implement since software systems have many
dependencies. Speed is crucial in implementing 3.2.Types of prototyping: Evolutionary
a throwaway prototype, since with a limited prototyping
budget of time and money little can be expended
on a prototype that will be discarded. Evolutionary Prototyping (also known as
Another strength of throwaway prototyping is breadboard prototyping) is quite different from
its ability to construct interfaces that the users Throwaway Prototyping. The main goal when
can test. The user interface is what the user sees using Evolutionary Prototyping is to build a very
as the system, and by seeing it in front of them, robust prototype in a structured manner and
it is much easier to grasp how the system will constantly refine it. "The reason for this is that
work. the Evolutionary prototype, when built, forms
It is asserted that revolutionary rapid the heart of the new system, and the
prototyping is a more effective manner in which improvements and further requirements will be
to deal with user requirements-related issues, built.
and therefore a greater enhancement to software When developing a system using
productivity overall. Requirements can be Evolutionary Prototyping, the system is
identified, simulated, and tested far more quickly continually refined and rebuilt.
and cheaply when issues of evolvability, "…evolutionary prototyping acknowledges
maintainability, and software structure are that we do not understand all the requirements
ignored. This, in turn, leads to the accurate and builds only those that are well understood."
specification of requirements and the subsequent This technique allows the development team
construction of a valid and usable system from to add features, or make changes that couldn't be
the user's perspective via conventional software conceived during the requirements and design
development models. phase.
Prototypes can be classified according to the For a system to be useful, it must evolve
fidelity with which they resemble the actual through use in its intended operational
product in terms of appearance, interaction and environment. A product is never "done;" it is
timing. One method of creating a low fidelity always maturing as the usage environment
Throwaway Prototype is Paper Prototyping. The changes…we often try to define a system using
prototype is implemented using paper and our most familiar frame of reference---where we
pencil, and thus mimics the function of the are now. We make assumptions about the way
actual product, but does not look at all like it. business will be conducted and the technology
Another method to easily build high fidelity base on which the business will be implemented.
Throwaway Prototypes is to use a GUI Builder A plan is enacted to develop the capability, and,
and create a click dummy, a prototype that looks sooner or later, something resembling the
like the goal system, but does not provide any envisioned system is delivered.
functionality. Evolutionary Prototyping have an advantage
Not exactly the same as Throwaway over Throwaway Prototyping in that they are
Prototyping, but certainly in the same family, is functional systems. Although they may not have
the usage of storyboards, animatics or drawings. all the features the users have planned, they may
These are non-functional implementations but be used on an interim basis until the final system
show how the system will look. is delivered.
In summary, this approach to protyping is "It is not unusual within a prototyping
constructed with idea that it would be discarded environment for the user to put an initial
and financial system would be built from the prototype to practical use while waiting for a
scratch.The steps in this approach are: more developed version…The user may decide
1. Write prelim requirements that a 'flawed' system is better than no system at
2. Design the prototype all."
3. User experiences/uses the prototype, In Evolutionary Prototyping, developers can
specifies new requirements. focus themselves to develop parts of the system
4. Writing final requirements that they understand instead of working on
5. Developing the real product developing a whole system.
ISSN – 1453 – 1119
no reviews yet
Please Login to review.
