1. Imran Hussain University of Management and Technology (UMT)
Virtual University Human-Computer Interaction
Lecture 16 HCI Process and Methodology
Imran Hussain
University of Management and Technology (UMT) 1

2. Open Your Eyes

3. In the Last Lecture WIMP Interfaces What are Paradigms
Paradigms of Interaction
Paradigm shifts (example)
Batch processing
Timesharing
Networking
Graphical display
Microprocessor
WWW
Ubiquitous Computing 2

4. In Today’s Lecture Lifecycle Models Software Engineering
Life-cycle Process Models
Waterfall Model
RAD Model
Spiral Model
HCI in Software Processes
Star Life-cycle Model
Usability Life-cycle Model
Some other models 1

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

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

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

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

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

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

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

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

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

14. Example: Process, Method, Tools
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

15. Relative Cost Per Phase

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

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

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

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

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

21. Traditional ‘Waterfall’ Lifecycle
Requirements analysis
Design
Code
Test
Maintenance

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

23. Verification and Validation
Real-world requirements and constraints
The formality gap
Verification
designing the product right
 Validation
designing the right product
The formality gap
validation will always rely to some extent on subjective means of proof
Management and contractual issues
design in commercial and legal contexts

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

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

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

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

28. Spiral Lifecycle Model

29. HCI in the Software Process
Software engineering and the design process for interactive systems
Usability engineering
Iterative design and prototyping
Design rationale

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

31. The Life Cycle for Interactive Systems
lots of feedback!
cannot assume a linear sequence of activities as in the waterfall model
Requirements specification
Architectural design
Detailed design
Coding and unit testing
Integration and testing
Operation and maintenance

32. A Simple Interaction Design Model
Identify needs/
establish
requirements
(Re)Design
Evaluate
Build an
interactive
version
Final product
Exemplifies a user-centered design approach

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

34. The Star Model (Hartson and Hix, 1989)
Implementation
task/functional
analysis
Requirements
specification
Prototyping
Evaluation
Conceptual/
formal design

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

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

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

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

39. And here endeth today’s lesson