1. Iterative design and prototyping
SNS College of Engineering Department of Computer Science and Engineering
Iterative design and prototyping
Presented By
S.Yamuna

2. Iterative design and prototyping
Requirements of the iterative segments cannot be specified from the beginning.
Only way is to built them and test them on real users.
It is software engineering problem, together with technical and managerial issues.

3. PROTOTYPES Simulate or animate some features of intended system
Iterative design is described by the use of the prototypes.
Simulate or animate some features of intended system
Different types of prototypes
Throw-away
Incremental
Evolutionary

4. THROW AWAY The prototype is built and tested.
The experience gained is taken to built original system.
Actual prototype is discarded.

5. INCREMENTAL Final product is built as a separate component.
Final system is partitioned into independent components.
Final componeLt is released as a series of product.

6. EVOLUTIONARY
Prototype is not discarded it serves as basic for the next iteration of design.
Actual system evolves from the limited initial version to its final release.

7. Cont… An animation of requirement can involve no real functionality.
Full functionality can be provided at the expense of other performance characteristics.
Prototype of an interactive system is used to test requirements by evaluating with user.
Providing realism is costly.

8. non-functional features contracts
On the management side there are several problems
Management issues
time
planning
non-functional features
contracts

9. Building prototype takes time.
Value of prototyping is appreciated only if it was Fast.
At the same time it should not produce erroneous results.
Planning
Most project managers do not have the experience necessary for adequately planning and costing a design process which involves prototyping.

10. NON-FUNCTIONAL FEATURES
Most important features of the system will be non- functional one.
This problem is similar to the technical issue of prototype realism
CONTRACTS
The design process is often governed by contractual agreements b/w customer and designer.
There must be an effective way of translating the result from prototype into document.

11. Techniques for prototyping
Storyboards
Probably the simplest of a prototype is the storyboard.
Storyboard do not require must in term of company system power to construct.
For Interactive system design storyboard provides snapshot of interface at particular points of interaction.
Storyboard usually includes annotations and scripts Indicating how the interaction will occur.

12. Limited functionality simulations
More functionality must be built into the prototype to demonstrate the work that the application will do.
Some portion of the functionality must be simulated by the design team.
Once the stimulation is built,it can be evaluated and changed rapidly based on users experiences.

13. Cont.. Well-known and successful prototyping tool is hypercard.
The graphical images are placed on cards,and links between cards can be created for animation effects.
One technique for simulation which does not require very much computer supported functionality ,is the wizard of Oz techniques.

14. High-level programming support
HyperTalk was an special purpose high-level Programming language
It makes easy for the designer to program certain features of an interactive system.
Attach functional behaviour to the specific interactions that the user will be able to do.
It is Implementation dependent.

15. Cont.. “User interface management system”
Can be considered to provide high level programming support.
It is separate the application functionality from its presentation.
The job of UIMS ,is to allow the programmar to connect the behaviour at the interface with the underlying functionality.

16. WARNING ABOUT ITERATIVE DESIGN
There are 2 problems
First,it is often the case that design decisions taken at the very beginning stage of prototyping is wrong.
Second,if in the process of evaluation ,a potential usability problem is diagonised,it is important to understand the reason for the problem

17. DESIGN RATIONALE
Design rationale is information that explains why a computer system is the way it is.
Design rationale relates to an activity of both reflection and documentation that occur throughout the entire life cycle.

18. REASONS FOR DESIGN RATIONALE
Explicitly,design rationale provide a communication mechanism among the member of the design team.
Accumulated knowledge in the form of design rationale for a set of products can be reused for another situation.
The effort required to produce a design rationale forces designer to be more delibrate.

19. CONT….
Usually there is no single best alternative.often designer is faced with a set of Trade-off’s between different alternatives.
In project management, accountability is good.
Usability is very much dependent on the context of its use.

20. PROCESS-ORIENTED DESIGN RATIONALE
preserves order of deliberation and decision- making
Two examples:
Issue-based information system (IBIS)
Design space analysis

21. Issue-based information system (IBIS)
Basis for much of design rationale research
process-oriented
Main elements:
issues
– hierarchical structure with one ‘root’ issue
positions
– potential resolutions of an issue
arguments
– modify the relationship between positions and issues
gIBIS is a graphical version

22. structure of gIBIS . Sub-issue Issue Position Argument supports
responds to
objects to
supports
questions
generalizes
specializes

23. Design space analysis structure-oriented QOC – hierarchical structure:
questions (and sub-questions)
– represent major issues of a design
options
– provide alternative solutions to the question
criteria
– the means to assess the options in order to make a choice
DRL – similar to QOC with a larger language and more formal semantics

24. The QOC notation Criterion Question Criterion Consequent option option

25. Psychological design rationale
To support task-artefact cycle in which user tasks are affected by the systems they use
aims to make explicit consequences of design for users
designers identify tasks system will support
scenarios are suggested to test task
users are observed on system
psychological claims of system made explicit
negative aspects of design can be used to improve next iteration of design

26. THANK YOU!!!!!