Lecture 6:

Risk Reduction Through

Prototyping
What is a Prototype
 The word prototype has multiple meanings, and participants in a
prototyping activity can hold very different expectations.
 For example, A prototype airplane actually flies—it’s the first instance
of a new type of airplane. In contrast, a software prototype is only a
portion or a model of a real system—it might not do anything useful at
all.
 Software prototypes can be static designs or working models; quick
sketches or highly detailed screens; visual displays or full slices of
functionality; or simulations.
Prototyping: What and why
 A software prototype is a partial, possible, or preliminary
implementation of a proposed new product. Prototypes can serve three
major purposes, and that purpose must be made clear from the very
beginning:
 Clarify, complete, and validate requirements Used as a
requirements tool, the prototype assists in obtaining agreement,
finding errors and omissions, and assessing the accuracy and quality
of the requirements.
Prototyping: What and why (Cont.)
 Explore design alternatives Used as a design tool, a prototype lets
stakeholders explore different user interaction techniques, envision
the final product, optimize system usability, and evaluate potential
technical approaches. Prototypes can demonstrate requirements
feasibility through working designs.
 Create a subset that will grow into the ultimate product Used as a
construction tool, a prototype is a functional implementation of a
subset of the product, which can be elaborated into the complete
product through a sequence of small-scale development cycles.
Prototyping: What and why (Cont.)
This lecture describes three classes of prototype attributes, each of
which has two alternatives:
 Scope A mock-up prototype focuses on the user experience; a proof-
of-concept prototype explores the technical soundness of a proposed
approach.
 Future use A throwaway prototype is discarded after it has been used
to generate feedback, whereas an evolutionary prototype grows into
the final product through a series of iterations.
 Form A paper prototype is a simple sketch drawn on paper, a
whiteboard, or in a drawing tool. An electronic prototype consists of
working software for just part of the solution.
Mock-ups and proofs of concept
 A mock-up is also called a horizontal prototype. Such a prototype
focuses on a portion of the user interface; it doesn’t dive into all the
architectural layers or into detailed functionality.
 This type of prototype lets you explore some specific behaviors of the
intended system, with the goal of refining the requirements. The
mock-up helps users judge whether a system based on the prototype
will let them do their job in a reasonable way.
Mock-ups and proofs of concept (Cont.)
 A proof of concept, also known as a vertical prototype, implements a
slice of application functionality from the user interface through all
the technical services layers.
 A proof-of-concept prototype works like the real system is supposed
to work because it touches on all levels of the system implementation.
Develop a proof of concept when you’re uncertain whether a
proposed architectural approach is feasible and sound, or when you
want to optimize algorithms, evaluate a proposed database schema,
confirm the soundness of a cloud solution, or test critical timing
requirements.
Throwaway and evolutionary prototypes

 Build a throwaway prototype to answer questions, resolve

uncertainties, and improve requirements quality. Because you’ll
discard the prototype after it has served its purpose, build it as
quickly and cheaply as you can.
 The more effort you invest in the prototype, the more unprepared
the project participants are to discard it and the less time you will
have available to build the real product.
Throwaway and evolutionary prototypes
(Cont.)
 A wireframe is a particular approach to throwaway prototyping
commonly used for custom user interface design and website
design. You can use wireframes to reach a better understanding of
three aspects of a website:
 The conceptual requirements
 The information architecture or navigation design
 The high-resolution, detailed design of the pages
Throwaway and evolutionary prototypes
(Cont.)
 An evolutionary prototype provides a solid architectural foundation
for building the product incrementally as the requirements become
clear over time.
 Agile development provides an example of evolutionary prototyping.
 Agile teams construct the product through a series of iterations, using
feedback on the early iterations to adjust the direction of future
development cycles. This is the essence of evolutionary prototyping.
Throwaway and evolutionary prototypes
(Cont.)
 Therefore, an evolutionary prototype takes longer to create than a
throwaway prototype that simulates the same system capabilities.
 An evolutionary prototype must be designed for easy growth and
frequent enhancement, so developers must emphasize software
architecture and solid design principles. There’s no room for shortcuts
in the quality of an evolutionary prototype.
Several possible ways to incorporate prototyping
into the software development process
Paper and electronic prototypes
 A paper prototype is a cheap, fast, and low-tech way to explore how a
portion of an implemented system might look.
 Paper prototypes help you test whether users and developers hold a
shared understanding of the requirements.
 They let you take a tentative and low-risk step into a possible solution
space prior to developing production code. A similar deliverable is called
a storyboard.
Paper and electronic prototypes (Cont.)
 Numerous tools are available if you decide to build an electronic
throwaway prototype. They range from simple drawing tools such as
Microsoft Visio and Microsoft PowerPoint to commercial prototyping
tools and graphical user interface builders.
 Tools also are available specifically for creating website wireframes.
Such tools will let you easily implement and modify user interface
components, regardless of how inefficient the temporary code behind the
interface is.
Working with prototypes
 A throwaway prototype or a wireframe elaborates the dialog elements
into specific screens, menus, and dialog boxes. When users evaluate the
prototype, their feedback might lead to changes in the use case
descriptions (if, say, an alternative flow is discovered) or to changes in
the dialog map.
 After the requirements are refined and the screens sketched, each user
interface element can be optimized for usability.
 These activities don’t need to be performed strictly sequentially. Iterating
on the use case, the dialog map, and the wireframe is the best way to
quickly reach an acceptable and agreed-upon approach to user interface
design.
Activity sequence from use cases to user
interface design using a throwaway prototype.
Working with prototypes (Cont.)
 This progressive refinement approach is cheaper than leaping directly
from use case descriptions to a complete user interface implementation
and then discovering major issues that necessitate extensive rework.
 It needed to perform as many steps in this sequence as are necessary to
acceptably reduce the risk of going wrong on the user interface design.
 If the stackholders is confident that they understand the requirements,
that the requirements are sufficiently complete, and that they have a good
handle on the right UI to build, then there’s little point in prototyping.
Working with prototypes (Cont.)
To help make this whole process more tangible, let’s look at an actual
example, a small website to promote a book, a memoir of life lessons called
Pearls from Sand. The author of the book Karl, actually thought of several
things that visitors should be able to do at the website, each of which is a use
case.
Working with prototypes (Cont.)
 The second step was to think of the pages the website should provide and
imagine the navigation pathways between them.
 The final website might not implement all of these pages separately. Some
pages might be condensed together; others might function as pop-ups or
other modifications of a single page.
Partial dialog map for PearlsFromSand.com.
Working with prototypes (Cont.)
 The third step was to construct a throwaway prototype or a wireframe
of selected pages to work out the visual design approach.
 Each of these can be a hand-drawn sketch on paper, a simple line drawing,
or a mock-up created with a dedicated prototyping or visual design tool.
 The wireframe illustrated in was drawn by using PowerPoint in just a few
minutes. Such a simple diagram is a tool to work with user representatives
to understand the broad strokes of what sort of page layout and features
would make the pages easy to understand and use.
Sample wireframe of one page for
PearlsFromSand.com.
Working with prototypes (Cont.)
 Finally, the fourth step is to create a detailed user interface
screen design.
 The next slide show the final page from the PearlsFromSand.com
website, the culmination of the requirements analysis and
prototyping activities that came before.
 This iterative approach to user interface design leads to better
results than diving immediately into high-resolution page design
without having a clear understanding of what members of
various user classes will want to do when they visit a website.
A final implemented page from
PearlsFromSand.com.
Prototype evaluation
 Prototype evaluation is related to usability testing. You’ll learn more by
watching users work with the prototype than just by asking them to tell
you what they think of it.
 To improve the evaluation of user interface prototypes, create scripts
that guide the users through a series of operations and ask specific
questions to elicit the information you seek. This supplements a general
invitation to “tell me what you think of this prototype.”
Prototype evaluation (Cont.)
 Derive the evaluation scripts from the use cases, user stories, or features
that the prototype addresses.
 The script asks evaluators to perform specific tasks, working through the
parts of the prototype that have the most uncertainty.
 At the end of each task, and possibly at intermediate points, the script
presents specific task-related questions.
Prototype evaluation (Cont.)
You might also ask general questions like the following:
 Does the prototype implement the functionality in the way you expected?
 What functionality is missing from the prototype?
 Can you think of any possible error conditions that the prototype doesn’t
address?
 Are any unnecessary functions present?
 How logical and complete does the navigation seem to you?
 Are there ways to simplify any of the tasks that require too many
interaction steps?
 Were you ever unsure of what to do next?
Risks of prototyping
 Pressure to release the prototype
 Distraction by details
 Unrealistic performance expectations
 Investing excessive effort in prototypes
Prototyping success factors
 Include prototyping tasks in your project plan. Schedule time and
resources to develop, evaluate, and modify the prototypes.
 State the purpose of each prototype before you build it, and explain
what will happen with the outcome: either discard (or archive) the
prototype, retaining the knowledge it provided, or build upon it to
grow it into the ultimate solution.
 Make sure those who build the prototypes and those who evaluate
them understand these intentions.
 Plan to develop multiple prototypes. You’ll rarely get them right on
the first try, which is the whole point of prototyping!
Prototyping success factors
 Create throwaway prototypes as quickly and cheaply as possible.
Invest the minimum amount of effort that will answer questions or
resolve requirements uncertainties. Don’t try to perfect a throwaway
prototype.
 Don’t include input data validations, defensive coding techniques,
error-handling code, or extensive code documentation in a throwaway
prototype. It’s an unnecessary investment of effort that you’re just
going to discard.
 Don’t prototype requirements that you already understand, except to
explore design alternatives.
Assignment
 Search about the latest wireframe tools and which one you
desire to work with and why. Make the search in form of
report.
 If you decided to work with a certain wireframe tool can
you make a wireframe for Chemical Tracking System.
Please back to its dialog map in lecture 2.