1. CS305: HCI in SW Development Software process and user-centered design Readings: ID-Book, Chapter 9

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. 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) Evaluate (Re)Design Identify needs/ establish requirements 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. Evaluate (Re)Design Identify needs/ establish requirements Build an interactive version Final product

20. Excerpts from… Introduction to Software Engineering CS201 Spring 2004

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

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 Evaluate (Re)Design Identify needs/ establish requirements 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. JAD workshops Project set-up Iterative design and build Engineer and test final prototype Implementation review A Lifecycle for RAD (Rapid Applications Development)

51. The Spiral Model

52. 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 Usability engineering lifecycle model

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 http://www.extremeprogramming.org http://www.extremeprogramming.org –Look at the diagram. Compare to waterfall and spiral

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