CS3205 : HCI in SW Development

1. CS3205: 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 3205: Usability Engineering • Next: • Process of HCI/Interaction Design Then, an intro to evaluation • HW2 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) • Requirements Analysis • Specifications • How to use technology to build a solution • Design • Prototypes • Planning how you’ll meet the requirements • Implementation • Integration • Verification • Maintenance

4. What do you remember about phases in SW Design? (List from past term) • User requirements • Req. 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: • Identifying needs and establishing requirements • Including usability 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. How to Get a Good Idea • “The best way to get a good idea, is to get lots of ideas.” -- Linus Pauling (two-time Nobel Prize winner) • Also: get lots of ideas quickly, and be able to evaluate your ideas

15. Where do design 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

16. How do you choose among alternatives? • Evaluation with users or with peers, e.g. show them 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

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

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

22. Excerpts from…Introduction toSoftware Engineering • From old slides from CS2110….

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

24. 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 modifiedon time and within cost estimates. • Engineering versus science: • Production, practical, quality, maintenance, reuse, standards, teams, management, etc.

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

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

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

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

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

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

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

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

33. Relative Cost per Phase

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

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

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

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

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

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

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

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

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

43. The Spiral Model

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

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

47. End of SW Engin Review

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

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

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