Upload
others
View
12
Download
3
Embed Size (px)
Citation preview
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
Requirementsspecification
Architecturaldesign
Architecturaldesign
Detaileddesign
Detaileddesign
Coding andunit testing
Coding andunit testing
Integrationand testingIntegrationand testing
Operation andmaintenance
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
Requirementsspecification
Requirementsspecification
Architecturaldesign
Architecturaldesign
Detaileddesign
Detaileddesign
Coding andunit testing
Coding andunit testing
Integrationand testingIntegrationand testing
Operation andmaintenance
Operation andmaintenance
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
UI Quality: Usability 2/3
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.
UI Quality: Usability 3/3
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:
Mark D. Huang, http://www.cc.gatech.edu/classes/cs6751_97_winter/Topics/design-princ
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:
Mark D. Huang, http://www.cc.gatech.edu/classes/cs6751_97_winter/Topics/design-princ
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