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
decomposition.
design
performs
this
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
sequence of activities
as in the waterfall model
Requirements
specification
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:
Measuring method:
Now level:
Worst case:
Planned level:
Best case:
Undo an erroneous programming
sequence
Number of explicit user actions
to undo current program
No current product allows such an undo
As many actions as it takes to
program-in mistake
A maximum of two explicit user actions
One explicit cancel action
ISO usability standard 9241
adopts traditional usability categories:

effectiveness
 can

efficiency
 can

you achieve what you want to?
you do it without wasting effort?
satisfaction
 do
you enjoy the process?
some metrics from ISO 9241
Usability
objective
Effectiveness
measures
Efficiency
measures
Satisfaction
measures
Suitability
for the task
Percentage of
goals achieved
Time to
complete a task
Rating scale
for satisfaction
Appropriate for
trained users
Number of power
features used
Relative efficiency
compared with
an expert user
Rating scale for
satisfaction with
power features
Learnability
Percentage of
functions learned
Time to learn
criterion
Rating scale for
ease of learning
Error tolerance
Percentage of
errors corrected
successfully
Time spent on
correcting errors
Rating scale for
error handling
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
Position
specializes
objects to
generalizes
Sub-issue
questions
Sub-issue
Sub-issue
Argument
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
Question
Question
Criterion
Option
Criterion
Option
Criterion
…
Consequent
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