CS305: HCI in SW Development

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

12
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

13
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

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 designmodel
Identify needs/ establish requirements
(Re)Design
Evaluate
Build an interactive version
Final product
18
(No Transcript)
19
(No Transcript)
20
Excerpts fromIntroduction toSoftware
Engineering

• From old slides from CS201.

21
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

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

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!
• 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

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 dont change much
• Design
• Buildings really are less complex
• Number of states
• Remove one brick

27
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

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

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

30
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

31
Relative Cost Per Phase
32
Software Development Processes

• Outline
• Whats 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 were
  done with current task know if were 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, its 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. Its 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

44
(No Transcript)
45
End of SW Engin Review
46
A simple interaction designmodel
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

53
(No Transcript)
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 weve seen
• Try looking for books on this with Google or at
  Amazon
• Many light-weight or Agile Process Models
• Best known example Extreme Programminghttp//www
  .extremeprogramming.org
• Look at the diagram. Compare to waterfall and
  spiral

55
(No Transcript)
56
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)

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

61
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

62
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