Iterative design and prototyping

Transcription

1 Iterative design and prototyping

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 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. INCREMENTAL Final product is built as a separate component. Final system is partitioned into independent components. Final component is released as a series of product.

5 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.

6 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.

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

8 TIME 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.

9 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.

10 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.

11 Limited functionality simulations More functionality must be bulit 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.

12 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.

13 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.

14 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.

15 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

16 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.

17 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.

18 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.

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

20 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

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

22 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

23 The QOC notation option Criterion Question Option option Criterion option Criterion Consequent

24 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

25 THANK YOU!!!!!