Imran Hussain University of Management and Technology (UMT)

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

description

Virtual University Human-Computer Interaction. Lecture 16 HCI Process and Methodology. Imran Hussain University of Management and Technology (UMT). Open Your Eyes. In the Last Lecture. WIMP Interfaces What are Paradigms Paradigms of Interaction Paradigm shifts (example) Batch processing - PowerPoint PPT Presentation

Transcript of Imran Hussain University of Management and Technology (UMT)

Page 1: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction1 © Imran Hussain | UMT

Imran Hussain

University of Management and Technology (UMT)

Lecture 16

HCI Process and Methodology

Virtual University

Human-Computer Interaction

Page 2: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction2 © Imran Hussain | UMT

Page 3: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction3 © Imran Hussain | UMT

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

Page 4: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction4 © Imran Hussain | UMT

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

Page 5: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction5 © Imran Hussain | UMT

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

Page 6: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction6 © Imran Hussain | UMT

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

Page 7: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction7 © Imran Hussain | UMT

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.

Page 8: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction8 © Imran Hussain | UMT

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

Page 9: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction9 © Imran Hussain | UMT

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”

Page 10: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction10 © Imran Hussain | UMT

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

Page 11: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction11 © Imran Hussain | UMT

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

Page 12: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction12 © Imran Hussain | UMT

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.

Page 13: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction13 © Imran Hussain | UMT

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?

Page 14: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction14 © Imran Hussain | UMT

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

Page 15: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction15 © Imran Hussain | UMT

Relative Cost Per Phase

6%

5%

7% 8%

Maintenance 67%

Integration

Modulecoding

Moduletesting

Design

Specification (Analysis)5%

2%Requirements

Page 16: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction16 © Imran Hussain | UMT

Software Development Processes

• Outline– What’s this all about?

– Some example models for life-cycle

– General principles

Page 17: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction17 © Imran Hussain | UMT

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

Page 18: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction18 © Imran Hussain | UMT

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

Page 19: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction19 © Imran Hussain | UMT

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

Page 20: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction20 © Imran Hussain | UMT

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.

Page 21: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction21 © Imran Hussain | UMT

Traditional ‘Waterfall’ Lifecycle

Requirements analysis

Design

Code

Test

Maintenance

Page 22: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction22 © Imran Hussain | UMT

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

Page 23: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction23 © Imran Hussain | UMT

Verification and Validation

• 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

Real-worldrequirementsand constraints The formality gap

Page 24: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction24 © Imran Hussain | UMT

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

Page 25: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction25 © Imran Hussain | UMT

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.

Page 26: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction26 © Imran Hussain | UMT

A Lifecycle for RAD (Rapid Applications Development)

JAD workshops

Project set-up

Iterative design and build

Engineer and test final prototype

Implementationreview

Page 27: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction27 © Imran Hussain | UMT

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

Page 28: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction28 © Imran Hussain | UMT

Spiral Lifecycle Model

Page 29: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction29 © Imran Hussain | UMT

HCI in the Software Process

• Software engineering and the design process for interactive systems

• Usability engineering

• Iterative design and prototyping

• Design rationale

Page 30: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction30 © Imran Hussain | UMT

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

Page 31: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction31 © Imran Hussain | UMT

The Life Cycle for Interactive Systems

Requirementsspecification

Requirementsspecification

Architecturaldesign

Architecturaldesign

Detaileddesign

Detaileddesign

Coding andunit testingCoding andunit testing

Integrationand testingIntegrationand testing

Operation andmaintenance

Operation andmaintenance

lots of feedback!

cannot assume a linearsequence of activitiesas in the waterfall model

Page 32: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction32 © Imran Hussain | UMT

A Simple Interaction Design Model

Evaluate

(Re)Design

Identify needs/ establish

requirements

Build an interactive version

Final productExemplifies a user-centered design approach

Page 33: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction33 © Imran Hussain | UMT

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

Page 34: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction34 © Imran Hussain | UMT

The Star Model (Hartson and Hix, 1989)

Evaluation

Conceptual/formal design

RequirementsspecificationPrototyping

task/functionalanalysis

Implementation

Page 35: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction35 © Imran Hussain | UMT

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

Page 36: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction36 © Imran Hussain | UMT

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

http://www.extremeprogramming.org

– Look at the diagram. Compare to waterfall and spiral

Page 37: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction37 © Imran Hussain | UMT

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)

Page 38: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction38 © Imran Hussain | UMT

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.

Page 39: Imran Hussain University of Management and Technology (UMT)

Virtual University - Human Computer Interaction39 © Imran Hussain | UMT

And here endeth today’s lesson