Professional Documents
Culture Documents
HCI in The Software Process
HCI in The Software Process
• Usability engineering
• Design rationale
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. A fundamental feature of software
engineering, therefore, is that it provides the structure for applying
techniques to develop software systems. 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 lifecycle
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 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
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
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, respectively. Boehm provides a useful distinction between
the two, characterizing validation as designing ‘the right thing’ and
verification as designing ‘the thing right’. Various languages are used
throughout design, ranging from informal natural language to very precise
and formal mathematical languages. Validation and verification exercises are
difficult enough when carried out within one language; they become much
more difficult, if not impossible, when attempted between languages.
Detailed
design
Coding and
unit testing
Integration
lots of feedback! and testing
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
• effectiveness
– can you achieve what you want to?
• efficiency
– can you do it without wasting effort?
• satisfaction
– do you enjoy the process?
Note: ISO (International Organization for Standardization)
(International Standards Organization)
Follow the uploaded book
(See Section 6.3 Pages 237-240)
some metrics from ISO 9241
Usability Effectiveness Efficiency Satisfaction
objective measures measures measures
• 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 This is not enough…
Follow the uploaded book
(See Section 6.4 Pages 241-244)
Techniques for prototyping
Storyboards
need not be computer-based
can be animated
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
Sub-issue generalizes
questions
Sub-issue
Sub-issue
Option Criterion
Option
Criterion
… Consequent …
Question
Question