chapter 6 hci in the software process morten fjeld...chapter 6 hci in the software process morten...

1/36

Chapter 6HCI in the Software Process

Morten Fjeld

Based on Dix et al., 3rd ed, when nothing else stated.

2/36

SW Characteristics & SW EngineeringSW Life Cycle Paradigms (1-3)From SW to UI Quality AssuranceUsability PrinciplesDesign Rationale

Overview

3/36

• Software is both a product and a vehicle for developing a product

• Software is engineered not manufactured

• Software does not wear out, but it does deteriorate

• Most software is still custom-built

Software Characteristics

4/36

Early detection saves money – by avoiding costly errors caused by software. Major examples are:

• Lost water supply and telephone services (NY)

• NASA's Mars Polar Lander was lost December due to

software error that shut down the descent engines (1999)

• Commercial aircraft accidentally shot down during First Gulf

War due to a poor user interface

• Financial fraud, mostly not made public by banks concerned

Importance of Software Engineering

5/36

Definition phase -- focuses on what (information engineering, software project planning, requirements analysis)

Development phase -- focuses on how (software design, code generation, software testing)

Support phase -- focuses on change (corrective maintenance, adaptive maintenance, perfective maintenance, preventative maintenance)

Software Life Cycle Phases

6/36

1: Waterfall paradigm; linear

2: Spiral model paradigm; iterative

3: Extreme programming paradigm

Software Life Cycle Paradigms

7/36

Requirementsspecification


Architecturaldesign

Architecturaldesign

Detaileddesign

Detaileddesign

Coding andunit testing


Integrationand testingIntegrationand testing

Operation andmaintenance


What the eventualSystem will beExpected to provide

How the system provide the services expected from it

Refinement ofThe architectualcomponents

Verify the Performance Of each unit

Put the Components together

Correction of errors in the system

1: Waterfall Paradigm

8/36

Real-worldrequirementsand constraints

The formality gap

Waterfall Paradigm, verification & validation

9/36



Architecturaldesign

Architecturaldesign

Detaileddesign

Detaileddesign



Integrationand testingIntegrationand testing



Iterative design, not a linear sequence

10/36

MAINTENANCE

Waterfall Paradigm, different wording

DESIGN

ANALYSIS

CODE

TESTING

SYSTEMENGINEERING

By Ludvig A. Norin, Intentia Research & Development AB

11/36

Waterfall Paradigm – The V Model

By www.convergsoft.com

12/36

2: Spiral Model Paradigm

13/36

2: Spiral Model Paradigm

14/36

2: Spiral Model Example: Socket Board

15/36

2: Spiral Model Example: Socket Board

16/36

3: Extreme Programming Paradigm

By Ron Jeffries

17/36

3: Extreme Programming Example

By Woodware Designs

18/36

Quality Software must be ...

... be useful (to the original customer)

... be portable (work at all of the customer’s sites)

... be maintainable

... be reliable

... have integrity (produce correct & accurate results)

SW Quality 1/3

19/36

Quality Software must be ...

... be efficient

... have consistency of function(does what users would expect it to do)

... be accessible to the user

... have good human engineering(easy to learn and easy to use)

SW Quality 2/3

20/36

Quality Software can be reached by mean of ...

... Code review (source : walkthrough or inspectionobject : automatic)

... Metrics (e.g. #classes, #methodes,identify identic code, copy/paste)

... ISO 9000 (e.g. ISO 9001, ISO 9006, ...)

... Testing (e.g. incremental, benchmark, ...)

SW Quality 3/3

21/36

StickyChats: Remote Conversations over Digital DocumentsChurchill et al. (2000), FX Palo Alto Laboratory

StickyChats bring together text-based conversations and digital documents. It supports:

-real-time, content-focused conversations AND -asynchronous collaborative annotation.

Video 1 from CSCW

http://www.open-video.org/details.php?videoid=8200&PHPSESSID=2a1b312091c2fd0d200bc0ca329b4d3f

22/36

Usability refers to the extent to which a productcan be used by specified users to achieve specifiedgoals with effectiveness, efficiency and satisfactionin a specified context of user.

UI Quality: Usability 1/3

23/36

Usability can be improved by means of ....

... User-centred Design

... Heuristic Testing

... Usability Evaluation

... Prototyping

... Task Analysis

... Collaborative Walk-through


24/36

Usability according to ISO 9241-11:

Effectiveness measures the accuracy and completeness with which users achieve specified goals;

Efficiency measures the resources expended in relation to the accuracy and completeness with which users achieve goals;

Satisfaction measures the freedom from discomfort, and positive attitudes towards the use of the product.


25/36

Some metrics from ISO 9241

Usability Effectiveness Efficiency Satisfactionobjective measures measures measures

Suitability Percentage of Time to Rating scale for the task goals achieved complete a task for satisfaction

Appropriate for Number of power Relative efficiency Rating scale for

trained users features used compared with satisfaction with an expert user power features

Learnability Percentage of Time to learn Rating scale forfunctions learned criterion ease of learning

Error tolerance Percentage of Time spent on Rating scale for errors corrected correcting errors error handling successfully

26/36

Major principles of usability

a) Shneiderman's "Eight Golden Rules of Dialo Design”http://www.cc.gatech.edu/classes/cs6751_97_winter/Topics/design-princ/#ben

b) Mayhew's "General Principles of User Interface Design”http://www.cc.gatech.edu/classes/cs6751_97_winter/Topics/design-princ/#deb

c) IBM's "Design Principles for Tomorrow”http://www.cc.gatech.edu/classes/cs6751_97_winter/Topics/design-princ/#ibm

d) Collection by Mikael Eriksson, Univ. of Linköpinghttp://www.ida.liu.se/%7Emiker/hci/guidelines.html

References[1] Ben Shneiderman, Designing the User Interface - Strategies for Effitive Human-Computer

Interaction, second edition, Reading, MA: Addison-Wesley Publishing Company, 1992[2] William M. Newman and Michael G. Lamming, Interactive System Design, Reading, MA:

Addison-Wesley Publishing Company, 1995[3] Deborah J. Mayhew, Principles and Guidelines in Software User Interface Design,

Englewood Cliffs, NJ: Prentice Hall, 1992

27/36

Compilation of ten principles of usable design,by Mark D. Huang, based on a, b and c: 1 Use simple and natural dialog in user's language

Match user's task in natural way. Avoid jargon, and techno-speak. Present exactly information users need, not too little or too much.

2 Strive for consistencySequences, actions, commands, layouts and terminology should be consistent so as to make the interface more predictable.

3 Provide informative feedbackContinuously inform user what is happening. It is most important to provide feedback on substantive and infrequent actions.

Mark D. Huang, http://www.cc.gatech.edu/classes/cs6751_97_winter/Topics/design-princ

28/36

4 Minimize user's memory loadHuman mind can recognize better than recall. Provide enough information so that the usercan take action without recalling a lot.

5 Permit easy reversal of actions (undo)To reduce anxiety and encourageexperiments.

6 Provide clearly marked exitsSo that the user won't be trapped on any levelof the applications.

Compilation of ten principles of usable design,by Mark D. Huang, based on a, b and c:


29/36

7 Provide shortcutsEnable frequent users to perform often usedoperations quickly.

8 Support internal locus of controlPut user in charge, not computer.

9 Handle errors smoothly and positivelyMake the system robust and provide easy to use recovery measures.

10 Provide useful help and documentUsers should be able to get sufficient helpinformation when they get confused.

Compilation of ten principles of usable design,by Mark D. Huang, based on a, b and c:


30/36

Design rationale (1/2)Design rationale is information that explains why a computer system is the way it is.

Benefits of design rationale– communication throughout life cycle– reuse of design knowledge across products– enforces design discipline– presents arguments for design trade-offs– organizes potentially large design space– capturing contextual information

31/36

Design rationale (2/2)Types of DR:• Process-oriented

– preserves order of deliberation and decision-making• Structure-oriented

– emphasizes post hoc structuring of considered design alternatives

• Two examples:– Issue-based information system (IBIS)– Design space analysis

32/36

Issue-based information system (IBIS)Ad-hoc

• 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

33/36

Structure of gIBIS

Sub-issue

Issue

Sub-issue

Sub-issue

Position

Position

Argument

Argument

responds to

responds toobjects to

supports

questions

generalizes

specializes

34/36

Design space analysis, post-hoc• 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

35/36

The QOC notation

Question

Option

Option

Option

Criterion

Criterion

Criterion

Question … ConsequentQuestion

…

36/36

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