1. 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)

2. 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

3. What do you remember about phases in SW Design? (Your list below)

4. 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

5. 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

6. A simple interaction design model (more on this later)
Identify needs/
establish
requirements
(Re)Design
Evaluate
Build an
interactive
version
Final product

7. 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

8. 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

9. 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

10. Some practical issues Who are the users? What are ‘needs’?
Where do alternatives come from?
How do you choose among alternatives?

11. 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 competitor’s 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

12. 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

13. 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

14. 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

15. How do you choose among alternatives?
Evaluation with 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

16. 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

17. A simple interaction design model
Identify needs/
establish
requirements
(Re)Design
Evaluate
Build an
interactive
version
Final product

20. Excerpts from… Introduction to Software Engineering
From old slides from CS201….

21. 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

22. 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.

23. 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

24. 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”

25. 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”

26. 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

27. Requirements, Design, and Implementation
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

28. 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.

29. 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?

30. 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

31. Relative Cost Per Phase

32. Software Development Processes
Outline
What’s this all about?
Some example models for life-cycle
General principles

33. 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 we’re done with current task; know if we’re late; estimate time to completion, costs; Etc.
New team-members know what to do

34. 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

35. 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

36. 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.

37. Traditional ‘waterfall’ lifecycle
Requirements analysis
Design
Code
Test
Maintenance

38. 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

39. 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.

40. 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

41. The Spiral Model

42. Features of the Spiral Process Model
Each cycle around the spiral can be like a phase
Each cycle has four stages
Determine objectives, constraints (i.e. plan!)
Identify and manage risks. Explore alternatives as part of risk management
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.
Review results and plan for next stage
May include getting client/customer feedback

43. 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

45. End of SW Engin Review

46. A simple interaction design model
Identify needs/
establish
requirements
(Re)Design
Evaluate
Build an
interactive
version
Final product

47. Traditional ‘waterfall’ lifecycle
Requirements analysis
Design
Code
Test
Maintenance

48. 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

49. Star Lifecycle “model”

50. A Lifecycle for RAD (Rapid Applications Development)
Project set-up
JAD workshops
Iterative design and build
Engineer and
test final prototype
Implementation
review

51. The Spiral Model

52. 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

54. 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 we’ve seen
Try looking for books on this with Google or at Amazon
Many light-weight or Agile Process Models
Best known example: Extreme Programming
Look at the diagram. Compare to waterfall and spiral

56. Agile Process Models Emphasizes
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 it’s: “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)

57. 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.

58. END

59. Some practical issues Who are the users? What are ‘needs’?
(Later) Where do design alternatives come from?
How do you choose among alternatives?

60. 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 competitor’s 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

61. 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

62. 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