chapter 6

HCI in the software

process
HCI in the software process
- Our focus will be integrating the design of interactive systems within the
established frameworks of software development specifically software
development life cycle.

- We already have a large sub discipline that addresses the management

and technical issues of the development of software systems – called
software engineering.

- Our goal is not to discuss the problems in Software life cycle but to
emphasize that issues from HCI affecting the usability of interactive
systems are relevant within all the activities of the software life cycle.
THE SOFTWARE LIFE CYCLE

- In the development of a software product, we consider two main

parties:
- customer who requires the use of the product
- designer who must provide the product.
- Two roles of customer? The group of people who negotiate the features
of the intended system with the designer may never be actual users of
the system.
- In this chapter, we will use the term ‘customer’ to refer to the group of
people who interact with the design team and we will refer to those who
will interact with the designed system as the user or end-user.
Activities in the life cycle
- A more detailed description of the life cycle activities is depicted below
as Waterfall model (sequential model).

Requirements
specification

Architectural
design

Detailed
design

Coding and
unit testing

Integration
and testing

Operation and
maintenance
Activities in the Life Cycle
Requirements specification
Designer and customer try to capture what the system is expected to
provide. Involves gathering information from the customer about the
work environment, people whom it will potentially affect and the new
product’s relationship to any other products which it is updating or
replacing.

Architectural design
High-level description of how the system will provide the services
required. We try to decompose system into major components
(modules) that can either be brought in from existing software products
or be developed from scratch independently.
Activities in the Life Cycle (cntd)
Detailed design
Refinement of component description provided by the architectural design
and interrelations to identify modules to be implemented separately.e.g
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.

Coding and unit testing

After coding, the component can be tested to verify that it performs
correctly, according to some test criteria that were determined in earlier
activities.
By using unit testing we can test individual units of source code to
determine if they are fit for use. In functional programming a unit could be
an entire module but is more commonly an individual function. In object-
oriented programming a unit is often an entire interface, such as a class,
but could be an individual method. Unit tests are created by programmers
or occasionally by white box testers during the development process.
Activities in the Life Cycle (cntd)
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 behaviour and acceptable use of any
shared resources.

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. 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. Therefore, maintenance
provides feedback to all of the other activities in the life cycle.
Validation and Verification
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, respectively. It is normally the responsibility
of software testers as part of the software development lifecycle.
Validation
designing the right product
Verification
designing the product right

Validation ensures that the product actually meets the user's needs, and
that the specifications were correct in the first place, while verification is
ensuring that the product has been built according to the requirements
and design specifications.
For example, A form is valid, when all the necessary details (according
to user requirements for the form) are filled with appropriate values, a
text for name, a number for phone number, etc. But it is verified after it
has been cross-checked with ID or passport etc
Validation and Verification(cntd)
formality gap: there will always be a distance from the informal
situations of the real world to any formal and structured development
process. We refer to this inevitable disparity as the formality gap
Interactive systems and the software
life cycle
- The claim we are making here is that all of the requirements for
an interactive system cannot be determined from the start. The
result is that systems must be built and the interaction with users
observed and evaluated in order to determine how to make them more
usable.
Interactive systems and the software
life cycle

Requirements cannot assume a linear

sequence of activities
specification

Architectural
as in the waterfall model
design

Detailed
design

Coding and
unit testing

lots of feedback! Integration

and testing

Operation and
maintenance
USABILITY ENGINEERING
- Usability engineering is a field that is concerned generally with human-
computer interaction and specifically with making human-computer
interfaces that have high usability or user friendliness.

- In effect, a user-friendly interface is one that allows users to effectively

and efficiently accomplish the tasks for which it was designed and one
that users rate positively on opinion or emotional scales.

-Methods and tools Usability Engineers conduct usability evaluations of

existing or proposed interfaces and their findings are fed back to the
Designer for use in design or redesign. Common usability evaluation
methods include:
- usability testing (Gold standard of Usability Engineering, but the most
involved and expensive method)
- focus groups
USABILITY ENGINEERING ( cntd)
- questionnaires/surveys
- cognitive walkthroughs
- heuristic evaluations
- Think aloud protocol
Usability testing, is when participants are recruited and asked to use
the actual or prototype interface and their reactions, behaviours, errors,
and self-reports in interviews are carefully observed and recorded by the
Usability Engineer. On the basis of this data, the Usability Engineer
recommends interface changes to improve usability.
USABILITY ENGINEERING ( cntd)
Focus Groups It is a form of qualitative research
in which a group of people are asked about their
perceptions, opinions, beliefs, and attitudes towards a
product. Questions are asked in an interactive group
setting where participants are free to talk with other
group members.

Cognitive walkthrough It is a method which used to

identify usability issues in a piece of software ,
focusing on how easy it is for new users to accomplish
tasks with the system. They are task-specific. The
designers and developers of the software walk through
the steps as a group, asking users a set of questions at
each step. Data is gathered during the walkthrough,
and afterwards a report of potential issues is
compiled.
USABILITY ENGINEERING ( cntd)
Heuristic Evaluation A heuristic evaluation is a usability inspection
method for computer software that helps to identify usability problems in
the user interface (UI) design. It specifically involves evaluators
examining the interface and judging its compliance with recognized
usability principles (the "heuristics"). Several heuristics exist for
evaluation like User Control: heuristics that check whether the user has
enough control of the interface.
Think Aloud Protocol Think aloud protocols involve participants thinking
aloud as they are performing a set of specified tasks. Users are asked to
say whatever they are looking at, thinking, doing, and feeling, as they go
about their task. This enables observers to see first-hand the process of
task completion (rather than only its final product). Observers at such a
test are asked to objectively take notes of everything that users say,
without attempting to interpret their actions and words. Test sessions are
often audio and video recorded so that developers can go back and refer
to what participants did, and how they reacted. The purpose of this
method is to make explicit what is implicitly present in subjects who are
able to perform a specific task.