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?
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).”
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
Requirements
specification

Architectural
design

Detailed
design

Coding and
unit testing

Integration
and testing

Operation and
maintenance
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 -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
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
Real-world
requirements
and constraints The formality gap

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
The life cycle for interactive
systems
cannot assume a linear
Requirements sequence of activities
specification
as in the waterfall model
Architectural
design

Detailed
design

Coding and
unit testing

lots of feedback! Integration

and testing

Operation and
maintenance
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 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
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
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?
some metrics from ISO 9241

Usability Effectiveness Efficiency Satisfaction

objective 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 for

trained 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
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 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
Design rationale
Design 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
supports
Position Argument
responds to
Issue
responds to
objects to
Position Argument
specializes

Sub-issue generalizes

questions

Sub-issue

Sub-issue
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 semantics
Design Representation Languge
the QOC notation

Option Criterion

Question Option Criterion

Option
Criterion

… Consequent …
Question
Question
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 topics
The 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