Presentation on theme: "CS305: HCI in SW Development"— Presentation transcript:
1CS305: HCI in SW Development Software process anduser-centered designReadings:(1) ID-Book, Chapter 9 (2) Ch. 1 from Task-Centered User Interface Design (on web)
2CS 305: Usability Engineering Next:Process of HCI/Interaction DesignThen, an intro to evaluationHW1 is an assignment on evaluating an appIntegrating usability and user-centered design into “normal” software developmentGoal: Get you to where you can do an interesting HW quickly
3What do you remember about phases in SW Design? (Your list below)
4What do you remember about phases in SW Design? (Your list below) User requirementsSpecificationverification (after all steps?)DesignValidationPrototyping to get feedback from customerOr, to see how something worksImplementation// Testing (includes alpha beta versions)Integration…Release (with celebration)Packaged and delivered / installers / help, documentationMaintenance
5From on-line “text”figure out who's going to use the system to do whatchoose representative tasks for task-centered designplagiarizerough out a designthink about itcreate a mock-up or prototypetest it with usersiteratebuild ittrack itchange it
6A simple interaction design model (more on this later) Identify needs/establishrequirements(Re)DesignEvaluateBuild aninteractiveversionFinal product
7What Is “Design” in HCI? It is a process: a goal-directed problem solving activity informed by intended use, target domain, materials, cost, and feasibilitya creative activitya decision-making activity to balance trade-offsIt is a representation:a plan for developmenta set of alternatives & successive elaborations
8Four basic activitiesThere are four basic activities in Interaction Design:1. Identifying needs and establishing requirements2. Developing alternative designs3. Building interactive versions of the designs4. Evaluating designs
9Three key characteristics Three key characteristics permeate these four activities:1. Focus on users early in the design and evaluation of the artifact2. Identify, document and agree specific usability and user experience goals3. Iteration is inevitable. Designers never get it right first time
10Some practical issues Who are the users? What are ‘needs’? Where do alternatives come from?How do you choose among alternatives?
11Who are the users? Not as obvious as you think: those who interact directly with the productthose who manage direct usersthose who receive output from the productthose who make the purchasing decisionthose who use competitor’s products ???Three categories of user:primary: frequent hands-onsecondary: occasional or via someone else;tertiary: affected by its introduction, or will influence its purchase.Wider term: stakeholders
12Who 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
13What are ‘needs’? Users rarely know what is possible Users can’t tell you what they ‘need’ to help them achieve their goalsInstead, look at existing tasks:their contextwhat 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 behaviourcan be described as future scenarios
14Where do alternatives come from? Humans stick to what they know worksBut considering alternatives is important to ‘break out of the box’Designers are trained to consider alternatives, software people generally are notHow do you generate alternatives?‘Flair and creativity’: research & synthesisSeek inspiration: look at similar products or look at very different products
15How do you choose among alternatives? Evaluation with users or with peers e.g. prototypesTechnical feasibility: some not possibleQuality 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 availableefficiency: performance measurements
16Lifecycle models Show how activities are related to each other Lifecycle models are:management toolssimplified versions of realityMany lifecycle models exist, for example:from software engineering: waterfall, spiral, JAD/RAD, Microsoftfrom HCI: Star, usability engineeringA simple interaction design model
17A simple interaction design model Identify needs/establishrequirements(Re)DesignEvaluateBuild aninteractiveversionFinal product
20Excerpts from… Introduction to Software Engineering From old slides from CS201….
21What’s the Problem?Software costs are increasing as hardware costs decline.Many software development disasters:Cost overruns, late deliveryReduced or wrong functionality, non-existent documentationMany failures attributed to softwareCost of failure becoming very high:FinancialLoss of life or loss of equipmentInconvenience
22Definition 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.
23SW Engineering Is and Is Not... It is (or should be):EngineeringBuilding software systemsModifying software systemsA systematic, careful, disciplined, scientific activityIt is not:Just building small systems or new systems.Hacking or debugging until it works.Easy, simple, boring or pointless
24One Way to Think About It Build a bridge to cross a small creekCut down a tree. Drop a board across it.Build a bridge across the Golden GateNeed 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”
25Software 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 phaseSpecification phaseDesign phaseImplementation phaseIntegration or “testing” phaseMaintenance phaseAlso maybe “conception” and “planning”
26Analogy: SE is like Construction Think about how buildings come to be:RequirementsArchitectureConstructionDifferences?MaintenanceBuildings don’t change muchDesignBuildings really are less complexNumber of statesRemove one brick
27Requirements, Design, and Implementation Statements of what the system should do (or what qualities it should have)From the customer or client point of viewNot expressed in terms of a solutionDesignA description of how we will implement a solutionA model or blueprint for meeting requirementsDone before implementation, so it can be evaluatedMany possible designs for a set of requirements. How to choose?Often models are used to describe either of these
28Three 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 processesCASE: Computer-aided Software EngineeringTest environments, 4GLs, Design tools, etc.
29Example: Process, Method, Tools Unit testing of code modules (before integration)Process: How it’s to be done? When, who, etc.?Documents:Overall SW QA PlanSoftware Test PlanBased on design; includes test strategies, test cases, etc. for each moduleWho?Development team has a SQA leadPerhaps a department or company SQA groupIndependent testers, or tested by developers?How do we verify (check) that its been done?
30Example: Process, Method, Tools (cont’d) Method: What approach to be used?Example: Black box testingTest cases, grouped into classesBefore testing, expected outcome is documentedAfter testing, did expected behavior occur?Example: Testing for memory leaksTools: Software approach for process and methodsTest case generator: creates test casesRegression test environment: repeats earlier testsMemory leak toolProblem reporting tool: keep problem databaseTest-case matrix: which tests cover which requirements
32Software Development Processes OutlineWhat’s this all about?Some example models for life-cycleGeneral principles
33Life-cycle Process Models Process means the events or tasks a development organization does, and their sequenceAgain, think about constructionOrganizations want a well-defined, well-understood, repeatable software development process. Why?Find and repeat good practicesManagement: 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
34Various Models for SW Lifecyles “Historical Models”Waterfall modelSpiral modelGovernment StandardsDoD standards: 2167, 2167AFAA standard DO-178A, DO-178BCorporate “Standards” or common practicesMany companies define their own.Perhaps using:Unified Process (was the Rational U.P.)Extreme Programming
35Why Learn About Process Now? There are general principles of about:What we do at various stages of SW developmentHow to inject quality into SWHow to avoid early problems that cause huge problems laterRecognize that SE is not just writing code
36Waterfall Model Early, simple model Do the phases shown before, in orderComplete one phase before moving on to the nextProduce a document that defines what to do at the start of each phaseAt 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.
38Flaws of the Waterfall Need iteration and feedback Things change (especially requirements)Change late requires change in earlier resultsOften need to do something multiple times, in stagesAs described, it’s very rigidNot realistic to freeze results after each phaseThe model does not emphasize important issuesRisk managementPrototypingQuality
39A Quality-based ViewPeople who do testing and SW Quality often re-draw the waterfall to emphasize testing activities that are not explicit in the last diagramIs 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.
40The Spiral Model Important features Risk analysis and other management are explicitly shown in the model at each stagePrototyping and iterative development “fit” in this modelRepetition of activities clearly in modelSuggests that alternatives can be explored
42Features of the Spiral Process Model Each cycle around the spiral can be like a phaseEach cycle has four stagesDetermine objectives, constraints (i.e. plan!)Identify and manage risks. Explore alternatives as part of risk managementDevelop and verify next stage or level of the productDepending on the spiral, “Product” might be a requirements document, a high-level design, code, etc.Review results and plan for next stageMay include getting client/customer feedback
43Is 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 organizationIntended for large-scale systems where cost of not doing risk management is highBut, the spiral model is importantHistoricallyAnd as an illustration of many desired features of a software development process
48The Star lifecycle model Suggested by Hartson and HixImportant features:Evaluation at the center of activitiesNo particular ordering of activities.Development may start in any oneDerived from empirical studies of interface designers
52Usability engineering lifecycle model Reported by Deborah MayhewImportant features:Holistic view of usability engineeringProvides links to software engineering approaches, e.g. OOSEStages of identifying requirements, designing, evaluating, prototypingCan be scaled down for small projectsUses a style guide to capture a set of usability goals
54Other Process Models The Unified Process A widely-adopted process model in industryOriginally developed by Rational (now part of IBM)More complicated model that what we’ve seenTry looking for books on this with Google or at AmazonMany light-weight or Agile Process ModelsBest known example: Extreme ProgrammingLook at the diagram. Compare to waterfall and spiral
56Agile Process Models Emphasizes 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 alternativesXP 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)EmphasizesTeam development: pair-programmingWrite tests before code (unit testing)
57Final Thoughts on Process Models Every organization does have a processMight be chaos every timeBut, should be defined, documented, planned and managedShould be based on the nature of the projects the team is buildingPeople 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.
59Some practical issues Who are the users? What are ‘needs’? (Later) Where do design alternatives come from?How do you choose among alternatives?
60Who are the users? Not as obvious as you think: those who interact directly with the productthose who manage direct usersthose who receive output from the productthose who make the purchasing decisionthose who use competitor’s products ???Three categories of user:primary: frequent hands-onsecondary: occasional or via someone else;tertiary: affected by its introduction, or will influence its purchase.Wider term: stakeholders
61Who 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
62What are ‘needs’? Users rarely know what is possible Users can’t tell you what they ‘need’ to help them achieve their goalsInstead, look at existing tasks:their contextwhat 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 behaviourcan be described as future scenarios