Lesson 4 HCI in The Software Process

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 30
At a glance
Powered by AI
The key takeaways are software engineering principles, usability engineering, iterative design and prototyping, and design rationale.

The main activities in the software life cycle are requirements specification, architectural design, implementation, testing, and maintenance.

The different types of prototypes discussed are throw-away, incremental, and evolutionary prototypes.

HCI IN THE Module 2

SOFTWARE PROCESS
•Software Engineering
•Usability Engineering
•Iterative Design And
Prototyping
•Design Rationale
•Software Engineering
•Usability Engineering
•Iterative Design And
Prototyping
•Design Rationale
•Software Engineering
•Usability Engineering
•Iterative Design And
Prototyping
•Design Rationale
•Software Engineering
•Usability Engineering
•Iterative Design And
Prototyping
•Design Rationale
Software Engineering
What is Software Engineering?
Software engineering is the process of analyzing
user needs and designing, constructing, and testing
end-user applications that will satisfy these needs
through the use of software programming languages.
It is the application of engineering principles
to software development.
THE SOFTWARE LIFE
CYCLE
One of the claims for software development is that it should
be considered as an engineering discipline, in a way similar to
how electrical engineering is considered for hardware
development. One of the distinguishing characteristics of any
engineering discipline is that it entails the structured
application of scientific techniques to the development of
some product.
Activities in the life cycle 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. 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 but also 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
Activities in the life cycle The next activities 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. 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
Activities in the life cycle

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. 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.
Activities in the life cycle

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. Research on
this activity within the life cycle has concentrated on two areas. There is plenty of research that is geared
towards the automation of this coding activity directly from a low-level detailed design. 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
Activities in the life cycle 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. 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.
Activities in the life cycle 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.
Consequently, 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.

The waterfall model is a breakdown of


project activities into linear sequential
phases, where each phase depends on
the deliverables of the previous one and
corresponds to a specialization of tasks.
Feedback from maintenance activity to other design
activities
Validation and verification
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. 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.
Validation
Did we build the system right?

Verification
 Did we build the right system?
Interactive systems and the software life cycle

The interactive system design


shows that every phase
depends on each other to serve
the purpose of designing and
product creation. It is a
continuous process as there is
so much to know and users
keep changing all the time. An
interactive system designer
should recognize this diversity.
Usability Engineering
Usability engineering is a field that is
concerned generally with human-computer
interaction and specifically with devising
human-computer interfaces that have high
usability or user friendliness. It provides
structured methods for achieving efficiency
and elegance in interface design.
Usability has three components − effectiveness, efficiency and
satisfaction, using which, users accomplish their goals in
particular environments. Let us look in brief about these
components.

• Effectiveness − The completeness with which users


achieve their goals.
• Efficiency − The competence used in using the resources
to effectively achieve the goals.
• Satisfaction − The ease of the work system to its users.
Usability Engineering
• The emphasis for usability engineering is in
knowing exactly what criteria will be used to
judge a product for its usability.
• The ultimate test of a product’s usability is
based on measurements of users’ experience
with it.
USABILITY SPECIFICATION

measuring concept
measuring method
now level
worst case
planned level
best case
Attribute: Backward recoverability
Measuring concept Undo an erroneous programming sequence
Number of explicit user actions to undo
Measuring Method
current program
Now Level No current product allows such an undo
As many actions as it takes to program in
Worst Case
mistake
As many actions as it takes to program in
Planned Level
mistake
Best Case One explicit cancel action

Sample usability specification for undo with a VCR


Problems with usability engineering

 usability specification requires level of


detail that may not be possible early in
design satisfying a usability specification
does not necessarily satisfy usability
ITERATIVE DESIGN AND PROTOTYPING
A point we raised earlier is that requirements for an interactive
system cannot be completely specified from the beginning of the life
cycle. The only way to be sure about some features of the potential
design is to build them and test them out on real users. The design
can then be modified to correct any false assumptions that were
revealed in the testing. This is the essence of iterative design, a
purposeful design process which tries to overcome the inherent
problems of incomplete requirements specification by cycling
through several designs, incrementally improving upon the final
product with each pass
Prototypes
o simulate or animate some features of
intended system
o different types of prototypes
 throw-away
 incremental
 evolutionary
Throw-away

Throw-away prototyping within requirements specification


Incremental

Incremental prototyping within the life cycle


Evolutionary

Evolutionary prototyping throughout the life cycle


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
End

You might also like