CS3205: 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 3205: Usability Engineering
• Next:
– Process of HCI/Interaction Design
Then, understanding users and their needs
• Part 1 of the project!
• Why look at development process?
– Integrating usability and user-centered
design into “normal” software
development
What do you remember about phases in
SW Design? (Your list below)
What do you remember about phases in
SW Design? (List from past term)
• User requirements
• Req. 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 TCUID 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
• Including usability 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
—those
—those
—those
—those
who
who
who
who
who
interact directly with the product
manage direct users
receive output from the product
make the purchasing decision
use competitor’s products ???
•More general term: stakeholders
Another Way to Characterize
Users
• Sometimes users fall into three categories:
—primary: frequent hands-on
—secondary: occasional or via someone else;
—tertiary: affected by its introduction, or will
influence its purchase.
• NOTE: don’t confuse these with user types (roles,
classes) used in use-case or OO analysis
– more on this later
Who are the users? (cont’d)
•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 child’s toy requires little
strength to operate, but greater strength to
change batteries
Assignment
• Read pp. 1-11 of tech report on
design interface for a children’s digital
library (see Readings page)
• Come ready to talk about children
user characteristics in next class
• Note: this is for the ICDL:
http://www.childrenslibrary.org/icdl/Simple
SearchCategory?ilang=English
What are ‘needs’?
•Users rarely know what is possible
•Users can’t 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
How to Get a Good Idea
• “The best way to get a good idea, is
to get lots of ideas.”
-- Linus Pauling
(two-time Nobel Prize winner)
• Also: get lots of ideas quickly, and
be able to evaluate your ideas
Where do design 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
alternatives?
• Evaluation with users or with peers, e.g. show
them 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 CS2110….
What’s 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
• Fairley’s:
– 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!
• What’s 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 don’t 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
to’s” 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 it’s 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 (cont’d)
• 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
2%
Requirements
5%
Specification
Design
6%
5%
7%
Module coding
Module testing
Integration
8%
67%
Maintenace
Software Development
Processes
• Outline
– What’s 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, wellunderstood, repeatable software development
process. Why?
• Find and repeat good practices
• Management: know what to do next; know when
we’re done with current task; know if we’re 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, it’s 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. It’s 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”
Project set-up
JAD workshops
A Lifecycle for RAD
(Rapid Applications
Development)
or JAD (Joint…)
Iterative design
and build
Engineer and
test final prototype
Implementation
review
The Spiral Model
From the Agile Manifesto
• One of the four “values”:
– Customer collaboration – requirements cannot
be fully collected at the beginning of the
software development cycle, therefore
continuous customer or stakeholder
involvement is very important.
• One of the twelve principles:
– Customer satisfaction by rapid delivery of useful
software
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
Agile Process Methodologies
• Many developers and organization feel existing
process models have been too “heavy weight”
– Too many rules and documents. Inflexible. Not fun.
• Agile Development
• Agile Manifesto and more (go read):
http://en.wikipedia.org/wiki/Agile_software
_development
• Best known example: Extreme
Programming
http://www.extremeprogramming.org
– Look at the diagram. Compare to waterfall and
spiral
END