Lecture 10

HCI in the software process

Topics for Today Software engineering and the design process for

interactive systems

Usability engineering

Iterative design and prototyping

Design rationale

What is software engineering?

“The establishment and use of sound engineering principles in order to obtain economically built software that is reliable and works efficiently on real machines.”

“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).”

IEEE Definition (1993)

Classic Definition (1969)

From Wikipedia“Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.’’

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

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

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.

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.

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.

The waterfall model – Activities

Requirementsspecification

Requirementsspecification

Architecturaldesign

Architecturaldesign

Detaileddesign

Detaileddesign

Coding andunit testingCoding andunit testing

Integrationand testingIntegrationand testing

Operation andmaintenance

Operation andmaintenance

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.

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.

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.

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.

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

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.

Communication is a critical element.

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.

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.

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.

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.

Detailed Design

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.

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.

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.

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.

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.

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.

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.

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.

Activities in the life cycle -OverviewRequirements 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 designhigh-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 designrefinement of architectural components and interrelations to identify modules to be implemented separately the refinement is governed by the nonfunctional requirements

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.

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.

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.

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.

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

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.

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.

Verification and validation

Verificationdesigning the product right

 Validationdesigning the right product

 The formality gap

validation will always rely to some extent on subjective means of proof

Management and contractual issuesdesign in commercial and legal contexts

Real-worldrequirementsand constraints The formality gap

The life cycle for interactive systems

cannot assume a linearsequence of activities

as in the waterfall model

lots of feedback!

Requirementsspecification

Requirementsspecification

Architecturaldesign

Architecturaldesign

Detaileddesign

Detaileddesign

Coding andunit testingCoding andunit testing

Integrationand testingIntegrationand testing

Operation andmaintenance

Operation andmaintenance

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.

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.

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.

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.

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

Part of a usability specification for a VCR

Attribute: Backward recoverability

Measuring concept: Undo an erroneous programming sequence

Measuring method: Number of explicit user actionsto 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

use a VCR to pre-record two programs

ISO usability standard 9241

adopts traditional usability categories:

effectivenesscan you achieve what you want to?

efficiencycan you do it without wasting effort?

satisfactiondo you enjoy the process?

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 forfunctions learned criterion ease of learning

Error tolerance Percentage of Time spent on Rating scale for errors corrected correcting errors error handling successfully

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

Techniques for prototypingStoryboards

need not be computer-basedcan be animated

Limited functionality simulationssome part of system functionality provided by designerstools like HyperCard are common for these Wizard of Oz technique

Warning about iterative designdesign inertia – early bad decisions stay baddiagnosing real usability problems in prototypes….

…. and not just the symptoms

Design rationaleDesign rationale is information that explains why a computer system is the way it is.

Benefits of design rationale communication throughout life cycle reuse of design knowledge across products enforces design discipline presents arguments for design trade-offs organizes potentially large design space capturing contextual information

Design rationale (cont’d)Types of DR: Process-oriented

preserves order of deliberation and decision-making Structure-oriented

emphasizes post hoc structuring of considered design alternatives

Two examples: Issue-based information system (IBIS) Design space analysis

Issue-based information system (IBIS) basis for much of design rationale research process-oriented main elements:

issues– hierarchical structure with one ‘root’ issue

positions– potential resolutions of an issue

arguments– modify the relationship between positions and issues

gIBIS is a graphical version

structure of gIBIS

Sub-issue

Issue

Sub-issue

Sub-issue

Position

Position

Argument

Argument

responds to

responds toobjects to

supports

questions

generalizes

specializes

Design space analysis structure-oriented

QOC – hierarchical structure:questions (and sub-questions)

– represent major issues of a design

options

– provide alternative solutions to the question

criteria

– the means to assess the options in order to make a choice

DRL – similar to QOC with a larger language and more formal semanticsDesign Representation Languge

the QOC notation

Question

Option

Option

Option

Criterion

Criterion

Criterion

Question … ConsequentQuestion

…

Psychological design rationale to support task-artefact cycle in which user tasks are affected by the

systems they use

aims to make explicit consequences of design for users

designers identify tasks system will support

scenarios are suggested to test task

users are observed on system

psychological claims of system made explicit

negative aspects of design can be used to improve next iteration of design

Summary of today’s topicsThe software engineering life cycle

distinct activities and the consequences for interactive system design

Usability engineering making usability measurements explicit as requirements

Iterative design and prototyping limited functionality simulations and animations

Design rationale recording design knowledge process vs. structure