Imran Hussain

1
Virtual University Human-Computer Interaction
Lecture 16HCI PROCESS AND Methodologies

• Imran Hussain
• University of Management and Technology (UMT)

2
In the Last Lecture

• HCI Process and Methodologies
• Problems with digital devices and products
• Significance of process
• Key factors to be consider
• Quality and Usability
• Usability in process
• Evolution of software development process
• Design
• Difference between interface design and
  interaction design

3
In Todays Lecture

• Life-cycle Models for Interactive systems
• Waterfall Model
• Spiral Model
• RAD Model
• Star Life-cycle Model
• Usability engineering Model
• Goal Directed Model

4
Design Approach

• Iterative and incremental approach towards design

5
Lifecycle Models

• Software lifecycle model consists of different
  stages and phases from start to completion.

6
Various Models for SW Lifecyles

• Historical Models
• Waterfall model
• Spiral model
• Government Standards
• DoD standards 2167, 2167A
• FAA standard DO-178A, DO-178B
• Corporate Standards or common practices
• Many companies define their own.
• Perhaps using
• Unified Process (was the Rational U.P.)
• Extreme Programming

7
Why Learn About Process Now?

• There are general principles of about
• What we do at various stages of SW development
• How to inject quality into SW
• How to avoid early problems that cause huge
  problems later
• Recognize that SE is not just writing code

8
Waterfall Model

• Early, simple model
• Do the phases shown before, in order
• Complete one phase before moving on to the next
• Produce a document that defines what to do at the
  start of each phase
• At end of each stage, a document or other
  work-product is produced requirements doc,
  design doc, code, etc.
• Little or no iteration (going back to previous
  phase)
• The order of phases/stages is generally right,
  but
• Following the waterfall precisely is not
  effective in real development practice.

9
Traditional Waterfall Lifecycle
Requirements analysis
Design
Code
Test
Maintenance
10
Traditional Waterfall Lifecycle
Requirements analysis
Design
Code
Test
Maintenance
11
Activities in the Life Cycle

• Requirements specification
• Designer and customer try capture what the system
  is expected to provide can be expressed in
  natural language or more precise languages, such
  as a task analysis would provide
• Architectural design
• High-level description of how the system will
  provide the services required factor system into
  major components of the system and how they are
  interrelated needs to satisfy both functional and
  non-functional requirements
• Detailed design
• Refinement of architectural components and
  interrelations to identify modules to be
  implemented separately the refinement is governed
  by the non-functional requirements

12
Flaws of the Waterfall

• Need iteration and feedback
• Things change (especially requirements)
• Change late requires change in earlier results
• Often need to do something multiple times, in
  stages
• As described, its very rigid
• Not realistic to freeze results after each phase
• The model does not emphasize important issues
• Risk management
• Prototyping
• Quality

13
A Lifecycle for RAD (Rapid Applications
Development)
Project set-up
JAD workshops
Iterative design and build
Engineer and test final prototype
Implementation review
14
Spiral Model (Barry Boehm)

• Important features
• Risk analysis
• Prototyping
• Iterative framework allowing ideas to be checked
  and evaluated
• Explicitly encourages alternatives to be
  considered
• Good for large and complex projects but not
  simple ones

15
Spiral Lifecycle Model
16
Features of Win Win Spiral Model

• Identification of stakeholders
• Stakeholder includes user
• Win condition of each stakeholder was specified

17
HCI in the Software Process

• Software engineering and the design process for
  interactive systems
• Usability engineering
• Iterative design and prototyping
• Design rationale

18
The Software Lifecycle

• Software engineering is the discipline for
  understanding the software design process, or
  life cycle
• Designing for usability occurs at all stages of
  the life cycle, not as a single isolated activity

19
A Simple Interaction Design Model
Identify needs/ establish requirements
(Re)Design
Evaluate
Build an interactive version
Final product
Exemplifies a user-centered design approach
20
The Star Lifecycle Model

• Suggested by Hartson and Hix (1989)
• Important features
• Evaluation at the centre of activities
• No particular ordering of activities. Development
  may start in any one
• Derived from empirical studies of interface
  designers

21
The Star Model (Hartson and Hix, 1989)
task/functional analysis
Implementation
Requirements specification
Evaluation
Prototyping
Conceptual/ formal design
22
Usability Engineering Lifecycle Model

• Reported by Deborah Mayhew
• Important features
• Holistic view of usability engineering
• Provides links to software engineering
  approaches, e.g. OOSE
• Stages of identifying requirements, designing,
  evaluating, prototyping
• Can be scaled down for small projects
• Uses a style guide to capture a set of usability
  goals

23
Usability Engineering Lifecycle Model
Word document is provided for the figure required
at this page
24
Goal-directed Design
Product
Desirability
Capability
Viability
25
Overall probability Of product success
Probability of Sustaining business (up to launch
and Long enough after to build revenue)
Probability of Technical completion (delivery)
Probability of customer Adoption (once the
product Has launched)

• User Plan
• Design
• schedule
• Form and
• behavior
• spec

• User Model
• Context
• Historical
• Social
• Economic
• User
• Demographics
• Psychographics
• Technographics
• Values
• Goals
• scenarios

• Technology Model
• Technology components
• Competitors
• Build vs buy
• buy vs open source

• Business Model
• Funding model
• Income/expense projections etc.

• Business Plan
• Marketing plan
• Launch plan
• Distribution plan

26
User Research

• Qualitative nature
• Market Research and Market segmentation
• Market research gives user survey data.
• Quantitative data is useful for selling a product
  but not useful for providing information how
  people use the product.

27
Gap between user research and ultimate design
solution
28
Reason for Gap
Goal-directed methods are not being used
29

• Goals of users
• Needs of business
• Constraints of technology

30
Research is carried out by researchers instead of
designers
31
Goal-directed Design
Research User and the domain
Modeling Users and use context
Requirements Definition of user, business
technical needs
Framework Definition of design structure flow
Refinement Of behavior, form content
32
Development Stages
Initiate
Design
Code
Test
Ship