HCI in the Software Process

1. Lecture 10 HCI in the software process

2. Topics for Today Software engineering and the design process for interactive systems Usability engineering Iterative design and prototyping Design rationale

3. What is software engineering? From Wikipedia “Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.’’ Classic Definition (1969) “The establishment and use of sound engineering principles in order to obtain economically built software that is reliable and works efficiently on real machines.” IEEE Definition (1993) “Software Engineering: (1) The application of a systematic, disciplines, quantifiable approach to the development, operation, and maintenance of software; that is the application of engineering to software. (2) The study of approaches as in (1).”

4. Software Engineering vs. Computer Science • Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software. • Computer science theories are still insufficient to act as a complete underpinning for software engineering (unlike e.g. physics and electrical engineering).

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

6. The software life cycle • The software life cycle is an attempt to identify the activities that occur in software development. • These activities must then be ordered in time in any development project and appropriate techniques must be adopted to carry them through.

7. The software life cycle • In the development of a software product, we consider two main parties: • The customer who requires the use of the product and • the designer who must provide the product • Typically, the customer and the designer are groups of people and some people can be both customer and designer.

8. The software life cycle • It is important to distinguish between the customer who is the client of the designing company and the customer who is the eventual user of the system. • These two roles of customer can be played by different people. • The group of people who negotiate the features of the intended system with the designer may never be actual users of the system.

9. Requirementsspecification Architecturaldesign Detaileddesign Coding andunit testing Integrationand testing Operation andmaintenance The waterfall model – Activities

10. Requirement specification • In requirements specification, the designer and customer try to capture a description of what the eventual system will be expected to provide. • This is in contrast to determining how the system will provide the expected services, which is the concern of later activities.

11. Requirement specifications • Requirements specification involves eliciting information from the customer about the work environment, or domain, in which the final product will function. • Aspects of the work domain include not only the particular functions that the software product must perform.

12. Requirement specification It also includes details about the environment in which it must operate, such as the people whom it will potentially affect and the new product’s relationship to any other products which it is updating or replacing.

13. Requirement Specification Requirements specification begins at the start of product development. Though the requirements are from the customer’s perspective, if they are to be met by the software product they must be formulated in a language suitable for implementation.

14. Requirement Specification • Requirements are usually initially expressed in the native language of the customer. • The executable languages for software are less natural and are more closely related to a mathematical language in which each term in the language has a precise interpretation, or semantics

15. Requirement specification The transformation from the expressive but relatively ambiguous natural language of requirements to the more precise but less expressive executable languages is one key to successful development.

16. Communication is a critical element.

18. Architectural design • Architectural design concentrate on how the system provides the services expected from it. • The first activity is a high-level decomposition of the system into components that can either be brought in from existing software products or be developed from scratch independently. • An architectural design performs this decomposition.

19. Architectural Design It is not only concerned with the functional decomposition of the system, determining which components provide which services. It must also describe the interdependencies between separate components and the sharing of resources that will arise between components.

20. Detailed Design • The architectural design provides a decomposition of the system description that allows for isolated development of separate components which will later be integrated. • For those components that are not already available for immediate integration, the designer must provide a sufficiently detailed description so that they may be implemented in some programming language.

21. Detailed Design The detailed design is a refinement of the component description provided by the architectural design. The behavior implied by the higher-level description must be preserved in the more detailed description.

22. Detailed Design

23. Coding and unit testing The detailed design for a component of the system should be in such a form that it is possible to implement it in some executable programming language. After coding, the component can be tested to verify that it performs correctly, according to some test criteria that were determined in earlier activities.

24. Coding and testing Here is plenty of research that is geared towards the automation of this coding activity directly from a low-level detailed design.

25. Coding and Testing Most of the work in formal methods operates under the hypothesis that, in theory, the transformation from the detailed design to the implementation is from one mathematical representation to another and so should be able to be entirely automated.

26. Coding and Testing Other work concentrates on the automatic generation of tests from output of earlier activities which can be performed on a piece of code to verify that it behaves correctly.

27. Integration and testing Once enough components have been implemented and individually tested, they must be integrated as described in the architectural design. Further testing is done to ensure correct behavior and acceptable use of any shared resources.

28. Integration and testing It is also possible at this time to perform some acceptance testing with the customers to ensure that the system meets their requirements. It is only after acceptance of the integrated system that the product is finally released to the customer.

29. Maintenance After product release, all work on the system is considered under the category of maintenance, until such time as a new version of the product demands a total redesign or the product is phased out entirely.

30. Maintenance The majority of the lifetime of a product is spent in the maintenance activity. Maintenance involves the correction of errors in the system which are discovered after release and the revision of the system services to satisfy requirements that were not realized during previous development.

31. Activities in the life cycle -Overview 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 nonfunctional requirements Detailed design refinement of architectural components and interrelations to identify modules to be implemented separately the refinement is governed by the nonfunctional requirements

32. Verification and Validation Throughout the life cycle, the design must be checked to ensure that it both satisfies the high-level requirements agreed with the customer and is also complete and internally consistent. These checks are referred to as validation and verification.

33. Verification.. • Verification of a design will most often occur within a single life-cycle activity or between two adjacent activities. • For example, in the detailed design of a component of a payroll accounting system, the designer will be concerned with the correctness of the algorithm to compute taxes deducted from an employee’s gross income.

34. Verification .. • The architectural design will have provided a general specification of the information input to this component and the information it should output. • The detailed description will introduce more information in refining the general specification.

35. Verification.. • The detailed design may also have to change the representations for the information and will almost certainly break up a single high-level operation into several low-level operations that can eventually be implemented.

36. Verification.. • In introducing these changes to information and operations, the designer must show that the refined description is a legal one within its language (internal consistency) and that it describes all of the specified behavior of the high-level description (completeness) in a provably correct way (relative consistency).

37. Validation Validation of a design demonstrates that within the various activities the customer’s requirements are satisfied. Validation is a much more subjective exercise than verification, mainly because the disparity between the language of the requirements and the language of the design forbids any objective form of proof.

38. Validation.. In interactive system design, the validation against HCI requirements is often referred to as evaluation and can be performed by the designer in isolation or in cooperation with the customer.

39. The formality gap Real-worldrequirementsand constraints 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

40. Requirementsspecification Architecturaldesign Detaileddesign Coding andunit testing Integrationand testing Operation andmaintenance The life cycle for interactive systems cannot assume a linearsequence of activitiesas in the waterfall model lots of feedback!

41. Management and contractual issue • The life cycle concentrated on the more technical features of software development. • In a technical discussion, managerial issues of design, such as time constraints and economic forces, are not as important. • The different activities of the life cycle are logically related to each other.

42. Management and contractual issue We can see that requirements for a system precede the high-level architectural design which precedes the detailed design, and so on. In reality, it is quite possible that some detailed design is attempted before all of the architectural design.

43. Management and contractual issue In management, a much wider perspective must be adopted which takes into account the marketability of a system, its training needs, the availability of skilled personnel or possible subcontractors, and other topics outside the activities for the development of the isolated system.

44. Managerial Issues In managing the development process, the temporal relationship between the various activities is more important, as are the intermediate deliverables which represent the technical content, as the designer must demonstrate to the customer that progress is being made.

45. Usability engineering The ultimate test of usability based on measurement of user experience Usability engineering demands that specific usability measures be made explicit as requirements Usability specification • usability attribute/principle • measuring concept • measuring method • now level/ worst case/ planned level/ best case Problems • usability specification requires level of detail that may not be • possible early in design satisfying a usability specification • does not necessarily satisfy usability

46. Part of a usability specification for a VCR use a VCR to pre-record two programs • Attribute: Backward recoverability • Measuring concept: Undo an erroneous programming sequence • Measuring method: Number of explicit user actions to undo current program • Now level: No current product allows such an undo • Worst case: As many actions as it takes to program-in mistake • Planned level: A maximum of two explicit user actions • Best case: One explicit cancel action

47. ISO usability standard 9241 adopts traditional usability categories: • effectiveness • can you achieve what you want to? • efficiency • can you do it without wasting effort? • satisfaction • do you enjoy the process?

48. some metrics from ISO 9241 • Usability Effectiveness Efficiency Satisfactionobjective measures measures measures • Suitability Percentage of Time to Rating scale for the task goals achieved complete a task for satisfaction • Appropriate for Number of power Relative efficiency Rating scale fortrained users features used compared with satisfaction with an expert user power features • Learnability Percentage of Time to learn Rating scale for functions learned criterion ease of learning • Error tolerance Percentage of Time spent on Rating scale for errors corrected correcting errors error handling successfully

49. Iterative design and prototyping • Iterative design overcomes inherent problems of incomplete requirements • Prototypes • simulate or animate some features of intended system • different types of prototypes • throw-away • incremental • evolutionary • Management issues • time • planning • non-functional features • contracts

50. Techniques for prototyping Storyboards need not be computer-based can be animated Limited functionality simulations some part of system functionality provided by designers tools like HyperCard are common for these Wizard of Oz technique Warning about iterative design design inertia – early bad decisions stay bad diagnosing real usability problems in prototypes…. …. and not just the symptoms