Usability Engineering Lifecycles As Part of User-Centred Design Major sources: (Based on a PowerPoint Presentation obtained from Laura Leventhal at Bowling Green State Univ.) Hix & Hartson: Chapters 4, 5 Developing User Interfaces Ensuring Usability Through Product & Process by Deborah Hix and H. Rex Hartson © 1993 by John Wiley & Sons, Inc. Preece et al.: Human-Computer Interaction by Jenny Preece, Yvonne Rogers, Helen Sharp, David Benyon, Simon Holland, Tom Carey © 1994 The Open University (Published by Addison-Wesley) Mayhew: The Usability Engineering Lifecycle: A Practitioner's Handbook for User Interface Design ©1999 by Morgan Kaufmann Publishers, Inc. LCC QA76.9.U83M395 1999 ISBN 1-55860-561-4 Continues on next slide

Usability Engineering Lifecycles Notes (2 of 2) Usability Engineering Lifecycles Sources (cont.): Denning & Dargan A discipline of software architecture By Peter J. Denning and Pamela A. Dargan interactions v.I n.1 (Jan. 1994), pp. 55 – 65 <URL:http://doi.acm.org/10.1145/174800.174807> Curtis & Hefley A wimp no more: the maturing of user interface engineering By Bill Curtis and Bill Hefley interactions v.I n.1 (Jan. 1994), pp. 22 – 34 <URL:http://doi.acm.org/10.1145/174800.174803>

What This Lecture Is About The problem with software today Usability engineering lifecycles Next: early analysis activities

Building a UI — What Do We Know? Principles of UI development are neither obvious nor intuitive Principles of UI development are not applied as often as they should be Developing a UI is part of the larger problem of developing software What are the big trends driving the field today? The software crisis Software chronic problem Software explosion — forget crisis Freefalling costs Demand for increased functionality

Special Challenges to UI Development The communications explosion The media explosion The usability explosion

The Communications Explosion Essence of UI used to be one-user, standalone. Now moving more toward connectivity (e.g., WWW, CSCW, etc.) Superhighway; Communications services; Expanding user pops

The Media Explosion Mice, pens, touch screens, video, speech, VR etc. UI code is half the code Gets more complicated, the more the media (e.g., multimedia)

The Usability Explosion Users want availability (open architecture) Increased awareness of costs of poor UIs

The SE S/W Dev. Life Cycle Plus UE Waterfall model Systematic, sequential approach to software development Begins at system level and progresses through a series of phases

Waterfall Model (picture) System Engineering Classic Lifecycle Model Requirements Analysis Design Coding Testing Maintenance

Phases Systems engineering and analysis Software requirements analysis Software design Coding Testing Maintenance Explain the phases Show how they correspond to UI development Use Figure 5 from Curtis & Hefley Explaining the phases: Systems engineering and analysis Requirements gathering about the context of the software. What other software, hardware, people, procedures etc., will the software interface with. Software requirements analysis Gathering requirements for the software itself. Goals are to understand the nature of the program(s) to be built, the problem domain, the required function, performance and (software) interfacing constraints. The output of this phase is a software specification document. Software design Multistep processes that focusses on four distinct attributes of the program(s): data structures, software architectures, procedural details, and (software) interface characteristics. The output of this phase is a software design document. (Notes continue on next slide)

Phases Systems engineering and analysis Software requirements analysis Software design Code Testing Maintenance Notes continued from previous slide Code Translate the design into machine-readable form. The output of this phase is the code as well as the program documentation. Testing Once code is generated, begin testing. Testing focuses on: logical internals & code flows through the software, and functional externals and how well the software meets the specifications. The output from this phase is a testing report. Maintenance Software undergoes change after it is delivered or marketed. Changes result from errors or because of external changes in the environment or because requirements change. Maintenance uses a ‘mini’ form of the lifecycle for its changes.

Integrating UE Processes Source: Curtis & Hefley, Figure 5, page 31. Caption: Integrating User Interface Engineering Processes Overhead slide is much clearer Curtis & Hefley Figure 5 (p. 31)

Issues for Waterfall Model The waterfall model is the oldest and most widely-used paradigm for software engineering Following any methodology imposes discipline on the software development process It appears to be easy to specify a timetable and costing for s/w developed with the waterfall model

Some Problems (1) Real problems rarely follow the sequential flow that model suggests: Iteration always occurs and Creates problems in the application of the paradigm Difficult for customer to state all requirements explicitly: Life cycle has difficulty accommodating uncertainty that exist at beginning of many projects

Some Problems (2) Customer must have patience Working version of the software will not be available until late in the time span

Spiral Model Common model for risky development Iteration is built-in It is ‘rapid’ but still rigid Barry Bane (long-A) US Dept. of Defense For real-time embedded systems Risk analysis is what we would call task analysis/feasibility Last ¼ is straight waterfall model Permits revisiting of stages Harder to evaluate costs, so Use milestones for each iteration Set maximum # of iterations (Notes continue on next slide)

Spiral Model Continued from previous slide Image copied from The Neume Notation Editor -- Spiral Model of Software Development By Louis W. G. Barton <URL:http://scribe.fas.harvard.edu/medieval/spiral.htm> (19 June 2002) Barton gives this credit for image: Avelino J. Gonzalez and Douglas D. Dankel, The Engineering of Knowledge-Based Systems, p. 299 (Englewood Cliffs, NJ: Prentice Hall, 1993). Two other sources for similar images: Denning & Dargan or Oxford Dictionary of Computing 1) Denning & Dargan See citation in note accompanying first slide 2) Oxford Dictionary of Computing: 3rd ed. (1991) Figure (from IEEE Computer, May 1988, p. 62) on page 433 ISBN 0-19-286131-X

The ‘Let's Get Real’ Model Hix & Hartson observed that UI developers worked in ‘alternating waves’ of top-down, bottom-up, inside-out, … See Star Life Cycle figure Fig. 4.2 in Hix & Hartson Figs. 2.8, 18.5 in Preece et al. Hix and Hartson (1993) Figure 4.2 (page 102) Preece et al. Figure 2.8 (page 49) Figure 18.5 (page 381) Try not to mention extreme programming, please! Inside-out programming: (p. 100 H&H) ‘the major work being the development of a good impedance match between what is at hand at the bottom and what is expected at the top’ Some description of ‘impedance’ on pp. 10 – 11 What is possible with the available tools, sometimes existing s/w base or tools limit what can be done Extremely rare for any s/w to start de novo — it almost always builds on existing system or toolkit

Star Life Cycle Redrawn from Fig. 18.5 (p. 381) in Preece et al. Definition of prototyping (for now): developing a working model

The Star Life Cycle Is… Not sequential Evaluation-centred Activities can proceed in any order Evaluation-centred Each activity is evaluated Interconnected Through the evaluation in the middle Primary activity that unites all phases is usability evaluation How will we proceed? Our approach is somewhat star-like We do task analysis only once but we may do other steps more than once Not a sequential model Activities can proceed in any order All phases are interconnected Centred on user evaluation

Getting Started—specifics SE/UI lifecycle divided into Definitional activities (Called ‘early system analysis activities’) Development/design activities

Early System Analysis Activities Documents concerned with Detailing the UI from the user’s perspective Goal Produce detailed documents that spell out as specifically as possible what the UI for the product will be like Details See the ‘early analysis activities’ slides Show Curtis & Hefley Figure 5?

Review Curtis & Hefley Figure 5 (p. 31)