CS305: HCI in SW

Development
Software process and
user-centered design

Readings:
(1) ID-Book, Chapter 9
(2) Ch. 1 from Task-Centered
User Interface Design (on web)
 CS 305: Usability Engineering

Next:
Process of HCI/Interaction Design
Then, an intro to evaluation
HW1 is an assignment on evaluating an app
Integrating usability and user-centered
design into normal software
development
Goal: Get you to where you can do an
interesting HW quickly
What do you remember about phases in
SW Design? (Your list below)
What do you remember about phases in
SW Design? (Your list below)
User requirements
Specification
verification (after all steps?)
Design
Validation
Prototyping to get feedback from customer
Or, to see how something works
Implementation
// Testing (includes alpha beta versions)
Integration
Release (with celebration)
Packaged and delivered / installers / help, documentation
Maintenance
 From on-line text
figure out who's going to use the system to do what
choose representative tasks for task-centered design
plagiarize
rough out a design
think about it
create a mock-up or prototype
test it with users
iterate
build it
track it
change it
A simple interaction design model
(more on this later)

Identify needs/
establish
requirements

(Re)Design
Evaluate

Build an
interactive
version

Final product
 What Is Design in HCI?
It is a process:
a goal-directed problem solving activity
informed by intended use, target domain,
materials, cost, and feasibility
a creative activity
a decision-making activity to balance trade-offs

It is a representation:
a plan for development
a set of alternatives & successive elaborations
 Four basic activities
There are four basic activities in Interaction
Design:
1. Identifying needs and establishing
requirements
2. Developing alternative designs
3. Building interactive versions of the
designs
4. Evaluating designs
 Three key
characteristics
Three key characteristics permeate these four
activities:
1. Focus on users early in the design and
evaluation of the artifact
2. Identify, document and agree specific
usability and user experience goals
3. Iteration is inevitable. Designers never
get it right first time
 Some practical
issues
Who are the users?

What are needs?

Where do alternatives come from?

How do you choose among alternatives?

 Who are the
users?
Not as obvious as you think:
those who interact directly with the product
those who manage direct users
those who receive output from the product
those who make the purchasing decision
those who use competitors products ???
Three categories of user:
primary: frequent hands-on
secondary: occasional or via someone else;
tertiary: affected by its introduction, or will influence
its purchase.
Wider term: stakeholders
 Who are the users?
(contd)
What are their capabilities? Humans vary in
many dimensions!
Some examples are:
size of hands may affect the size and
positioning of input buttons;
motor abilities may affect the suitability
of certain input and output devices;
height if designing a physical kiosk;
strength - a childs toy requires little
strength to operate, but greater strength to
change batteries
 What are
needs?
Users rarely know what is possible
Users cant tell you what they need to help
them achieve their goals
Instead, look at existing tasks:
their context
what information do they require?
who collaborates to achieve the task?
why is the task achieved the way it is?
Envisioned tasks:
can be rooted in existing behaviour
can be described as future scenarios
 Where do alternatives

come from?
Humans stick to what they know works
But considering alternatives is important to
break out of the box
Designers are trained to consider
alternatives, software people generally are not
How do you generate alternatives?
Flair and creativity: research & synthesis
Seek inspiration: look at similar products
or look at very different products
 How do you choose among

Evaluation withalternatives?
users or with peers e.g.
prototypes
Technical feasibility: some not possible
Quality thresholds: Usability goals lead to
usability criteria (set early and checked regularly)
safety: how safe?
utility: which functions are superfluous?
effectiveness: appropriate support? task coverage,
information available
efficiency: performance measurements
 Lifecycle
models
Show how activities are related to each
other
Lifecycle models are:
management tools
simplified versions of reality
Many lifecycle models exist, for example:
from software engineering: waterfall,
spiral, JAD/RAD, Microsoft
from HCI: Star, usability engineering
A simple interaction design model
A simple interaction
design
model Identify needs/
establish
requirements

(Re)Design
Evaluate

Build an
interactive
version

Final product
 Excerpts from

Introduction to
Software Engineering
From old slides from CS201.
 Whats the Problem?
Software costs are increasing as hardware costs
decline.
Many software development disasters:
Cost overruns, late delivery
Reduced or wrong functionality, non-existent
documentation
Many failures attributed to software
Cost of failure becoming very high:
Financial
Loss of life or loss of equipment
Inconvenience
 Definition of Software
Engineering
Fairleys:
Software engineering is the technological and
managerial discipline concerned with systematic
production and maintenance of software
products that are developed and modified on
time and within cost estimates.
Engineering versus science:
Production, practical, quality, maintenance,
reuse, standards, teams, management, etc.
SW Engineering Is and Is Not...
It is (or should be):
Engineering
Building software systems
Modifying software systems
A systematic, careful, disciplined, scientific
activity
It is not:
Just building small systems or new systems.
Hacking or debugging until it works.
Easy, simple, boring or pointless
 One Way to Think About It
Build a bridge to cross a small creek
Cut down a tree. Drop a board across it.
Build a bridge across the Golden Gate
Need a big tree!

Whats different?
Size of project matters. Number of people involved. How
long does it has to last. Risk. Economics.
Programming in the large vs. Programming in
the small
 Software Lifecycle and Phases
Stages or phases that are typical in software
development, from birth to death
There are various different models (more later)
Phases might include:
Requirements phase
Specification phase
Design phase
Implementation phase
Integration or testing phase
Maintenance phase
Also maybe conception and planning
Analogy: SE is like Construction
Think about how buildings come to be:
Requirements
Architecture
Construction

Differences?
Maintenance
Buildings dont change much
Design
Buildings really are less complex
Number of states
Remove one brick
 Requirements, Design, and
Implementation
Requirements
Statements of what the system should do (or what
qualities it should have)
From the customer or client point of view
Not expressed in terms of a solution
Design
A description of how we will implement a solution
A model or blueprint for meeting requirements
Done before implementation, so it can be evaluated
Many possible designs for a set of requirements. How to
choose?
Often models are used to describe either of these
 Three Key Elements in SE
Process:
life-cycle model used, project management and
assessment, quality assurance, etc.
Method:
Approaches for solving a particular problem. The how
tos for doing some specific task.
E.g. object-oriented design; black-box testing; prototypes for
requirements analysis.
Tools:
Software that supports methods and/or processes
CASE: Computer-aided Software Engineering
Test environments, 4GLs, Design tools, etc.
 Example: Process, Method, Tools
Unit testing of code modules (before integration)
Process: How its to be done? When, who, etc.?
Documents:
Overall SW QA Plan
Software Test Plan
Based on design; includes test strategies, test cases, etc. for
each module
Who?
Development team has a SQA lead
Perhaps a department or company SQA group
Independent testers, or tested by developers?
How do we verify (check) that its been done?
 Example: Process, Method, Tools (contd)

Method: What approach to be used?

Example: Black box testing
Test cases, grouped into classes
Before testing, expected outcome is documented
After testing, did expected behavior occur?
Example: Testing for memory leaks
Tools: Software approach for process and methods
Test case generator: creates test cases
Regression test environment: repeats earlier tests
Memory leak tool
Problem reporting tool: keep problem database
Test-case matrix: which tests cover which requirements
 Relative Cost Per Phase
Module Integration
testing

Module
coding
7% 8%
Design 5%

6%
Specification (Analysis)
5%

Requirements 2%

Maintenance 67%
 Software Development
Processes
Outline
Whats this all about?
Some example models for life-cycle
General principles
 Life-cycle Process Models
Process means the events or tasks a development
organization does, and their sequence
Again, think about construction
Organizations want a well-defined, well-
understood, repeatable software development
process. Why?

Find and repeat good practices

Management: know what to do next; know when
were done with current task; know if were late;
estimate time to completion, costs; Etc.
New team-members know what to do
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
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
 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.
 Traditional waterfall
lifecycle
Requirements
analysis

Design

Code

Test

Maintenance
 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
 A Quality-based View
People who do testing and
SW Quality often re-draw
the waterfall to emphasize
testing activities that are
not explicit in the last
diagram

Is this a model organization

a group can follow?
No. Its a big-picture view
for understanding.
A company might have a
detailed standard plan
(their process)
It could reflect this.
 The Spiral Model

Important features
Risk analysis and other management are
explicitly shown in the model at each
stage
Prototyping and iterative development
fit in this model
Repetition of activities clearly in model
Suggests that alternatives can be explored
The Spiral Model
Features of the Spiral Process Model
Each cycle around the spiral can be like a
phase
Each cycle has four stages
1. Determine objectives, constraints (i.e. plan!)
2. Identify and manage risks. Explore alternatives as
part of risk management
3. Develop and verify next stage or level of the
product
Depending on the spiral, Product might be a
requirements document, a high-level design, code, etc.
4. Review results and plan for next stage
May include getting client/customer feedback
Is the Spiral Model the Answer?
For some situations, yes. (There is no one answer.)
Original study that analyzed the spiral model says:
Intended for internal development of large systems
Internal: developers and clients in same organization
Intended for large-scale systems where cost of not doing
risk management is high
But, the spiral model is important
Historically
And as an illustration of many desired features of a
software development process
End of SW Engin Review
A simple interaction
design
model Identify needs/
establish
requirements

(Re)Design
Evaluate

Build an
interactive
version

Final product
 Traditional waterfall
lifecycle
Requirements
analysis

Design

Code

Test

Maintenance
 The Star lifecycle
model
Suggested by Hartson and Hix

Important features:
Evaluation at the center of activities
No particular ordering of activities.
Development may start in any one
Derived from empirical studies of
interface designers
Star Lifecycle model
 A Lifecycle for RAD
Project set-up (Rapid Applications
Development)
JAD workshops

Iterative design
and build

Engineer and
test final prototype

Implementation
review
The Spiral Model
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
 Other Process Models
The Unified Process
A widely-adopted process model in industry
Originally developed by Rational (now part of IBM)
More complicated model that what weve seen
Try looking for books on this with Google or at
Amazon

Many light-weight or Agile Process Models

Best known example: Extreme Programming
http://www.extremeprogramming.org
Look at the diagram. Compare to waterfall and
spiral
 Agile Process Models
Many developers and organization feel existing
process models have been too heavy weight
Too many rules and documents. Inflexible. Not fun.
XP and many other agile methods try to be
alternatives
XP says its: a deliberate and disciplined approach
to software development. (So it is a process model.)
Claims to be good for risky projects with dynamic
requirements, and when continuous customer involvement
is crucial (and possible)
Emphasizes
Team development: pair-programming
Write tests before code (unit testing)
 Final Thoughts on Process Models
Every organization does have a process
Might be chaos every time
But, should be defined, documented, planned and
managed
Should be based on the nature of the projects the
team is building
People have strong feelings on this subject about
what works!
(IMHO) There is no silver bullet here.
I.e. no one thing that will solve all your problems all
the time.
END
 Some practical
issues
Who are the users?

What are needs?

(Later) Where do design alternatives

come from?

How do you choose among alternatives?

 Who are the
users?
Not as obvious as you think:
those who interact directly with the product
those who manage direct users
those who receive output from the product
those who make the purchasing decision
those who use competitors products ???
Three categories of user:
primary: frequent hands-on
secondary: occasional or via someone else;
tertiary: affected by its introduction, or will influence
its purchase.
Wider term: stakeholders
 Who are the users?
(contd)
What are their capabilities? Humans vary in
many dimensions!
Some examples are:
size of hands may affect the size and
positioning of input buttons;
motor abilities may affect the suitability
of certain input and output devices;
height if designing a physical kiosk;
strength - a childs toy requires little
strength to operate, but greater strength to
change batteries
 What are
needs?
Users rarely know what is possible
Users cant tell you what they need to help
them achieve their goals
Instead, look at existing tasks:
their context
what information do they require?
who collaborates to achieve the task?
why is the task achieved the way it is?
Envisioned tasks:
can be rooted in existing behaviour
can be described as future scenarios