4.

PROTOTYPING
-Dimensions
• We can analyze prototypes and prototyping techniques along four
dimensions
• Representation describes the form of the prototype, e.g., sets of
paper sketches or computer simulations
• Precision describes the level of detail at which the prototype is to
be evaluated; e.g., informal and rough or highly polished
• Interactivity describes the extent to which the user can actually
interact with the prototype; e.g., watch-only or fully interactive; and
• Evolution describes the expected life-cycle of the prototype, e.g.
throwaway or iterative.

-Tools

Offline Online
prototypes prototypes
(paper (software
prototypes) prototypes)

include paper sketches, include computer animations, interactive

illustrated story-boards, video presentations, programs written
cardboard mock-ups with scripting languages, and
applications developed with interface
builders
-Method
• There are two methods of user participation in prototyping process : User
centered Design and Participatory Design
• User centered Design
• User-centered design places the user at the center of the
design process, from the initial analysis of user requirements
to testing and evaluation.
• Prototypes support this goal by allowing users see and
experience the final system long before it is built
 • Designers can identify functional requirements, usability
problems and performance issues early and improve the
design accordingly
• Prototypes can be compared directly with other, existing
systems, and designers can learn about the context of use
and the work practices of the end users.
• Participatory Design
• Participatory (also called Cooperative) Design is a form of
user-centered design that actively involves the user in all
phases the design process
• Users are not simply consulted at the beginning, but called in
to evaluate the system at the end; they are treated as
partners throughout.
• This early and active involvement of users helps designers
avoid unpromising design paths and develop a deeper
understanding of the actual design problem.
• Obtaining user feedback at each phase of the process also
changes the nature of the final evaluation, which is used to
fine-tune the interface rather than discover major usability
problems.

-Strategies

Requirements Evolutionary
Rapid Prototyping
Prototyping Prototyping
- Uses a prototype - Similar with - The goal of rapid prototyping is to
to determine the requirements develop prototypes very quickly, in a
requirements of a prototyping, but fraction of the time it would take to
proposed database after requirements develop a working system
system are complete, the
prototype is not - By shortening the prototype-
- Once the discarded, but with evaluation cycle, the design team can
requirements are the further evaluate more alternatives and iterate
complete, the development the design several times, improving the
prototype is becomes the likelihood of finding a solution that
discarded working database successfully meets the user's needs
system
- Early prototypes, e.g. sketches, can
be created in a few minutes. Later in
the design cycle, a prototype produced
in less than a week may still be
considered “rapid” if the final system is
expected to take months or years to
build.
-Requirement (?)
-Flow
Steps for Prototyping

Identify
Plan Refine Develop
data to be
Prototype Objectives prototype
used

Update Access
Review for
Document impact of
feasibility
ation prototype

1. Plan prototype
For the prototype to provide positive benefits to the development process,
it is vital that the following issues are considered and agreed before
prototyping starts :
a. Objectives : Why is the prototype necessary? What does the project
want to prove or learn from the prototype?
b. Scope : What aspect of the application are to be addressed by the
prototype. ex. In order to achieve the stated objectives, what must
be included in the prototype?
In planning the prototype, it is important to specify :
- The number of prototyping iterations which will be allowed
- What will be covered in each iteration
- The time box for each iteration

2. Refine Objectives
For each iteration of the prototype, it is important that the objectives and
scope of the iteration are reviewed to ensure :
• Consistency with the overall objectives and scope
• The result of the previous iteration are taken into account during
this iteration

3. Identify Data to be Used

 - Before starting a prototype iteration, the team must decide what data will
be used for prototyping purposes. This will be determined by the
objectives and scope of the prototype.
- If a prototype with high fidelity and high functionality is being built, it is
likely that a prototyping database comprising live data will be needed.
However, for prototypes with low and fidelity and low functionality; it may
be that “dummy” data can be used to populate the windows.
- The approach taken must reflect the objectives for the prototype

4. Develop Prototype
- The prototype is developed in accordance with the objectives and
scope of the iteration and within the duration of the timebox
- If high fidelity prototype is being built, it must reflect the Application
Style Guide which will be used for the target GUI.
- If the Application Style Guide does not yet exist, one will need to be
developed for the prototype which can later be enhanced and used to
build the target GUI

5. Review for Feasibility

- The aim of this step is to ensure that the prototype is not oversold to users
to the detriment of the final system
- Before handing a prototype over to users for evaluation particularly one of
high fidelity and low functionality, it should be assessed by the
development team to ensure that it will not raise User’s expectations as
regards performance and functional completeness

6. Assess Impact of Prototype

- Once the users have evaluated the prototype, their comments must
be assessed in terms of impact to:
The prototype itself and the changes necessary to the
objectives, scope and requirements of future prototyping
iterations
The target system, particularly the defined requirements and
the GUI design
- Impact analysis must address:
The amount of work needed to implement evaluation results
The time needed to implement the evaluation results
The benefit and cost of implementing

7. Update Documentation
- Once the final prototype has been evaluated and the impact of any
requested changes analyzed, the Requirements Specification
products must be updated

5. MONITORING AND TURNING

-Latar belakang denormalisasi:
• To determine whether introducing redundancy in a controlled manner by
relaxing the normalization rules will improve the performance of the
system
• Result of normalization is a design that is structurally consistent with
minimal redundancy.
• However, sometimes a normalized database does not provide maximum
processing efficiency.
• May be necessary to accept loss of some benefits of a fully normalized
design in favor of performance.
• Also consider that denormalization:
• makes implementation more complex;
• often sacrifices flexibility;
• may speed up retrievals but it slows down updates.
• Denormalization refers to a refinement to relational schema such that the
degree of normalization for a modified relation is less than the degree of
at least one of the original relations.
• Also use term more loosely to refer to situations where two relations are
combined into one new relation, which is still normalized but contains
more nulls than original relations.

-Plus minus dernormalisasi:

-Step-step dernomalisasi:
Step 7.2
Duplicating non-key attributes in 1:* relationships to reduce joins

Duplicating non-key attributes in 1:* relationships: Lookup Table

Step 7.4
Duplicating attributes in *:* relationships to reduce joins

Step 7.5
Introducing repeating groups