Supplementary Slides for
Software Engineering:
A Practitioner's Approach, 5/e
copyright © 1996, 2001
R.S. Pressman & Associates, Inc.
For University Use Only
May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
This presentation, slides, or hardcopy may NOT be used for
short courses, industry seminars, or consulting purposes.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
1
Chapter 15
User Interface Design
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
2
Agenda
The Golden Rules
UI Design
Task Analysis and Modeling
Interface Design Activities
Implementation Tools
Design Evaluation
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
3
Interface Design
Easy to learn?
Easy to use?
Easy to understand?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
4
Interface Design
Typical Design Errors
lack of consistency
too much memorization
no guidance / help
no context sensitivity
poor response
Arcane/unfriendly
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
5
Golden Rules
Place the user in control
Reduce the user’s memory load
Make the interface consistent
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
6
Place the User in Control
Define interaction modes in a way that does not force a user
into unnecessary or undesired actions.
Provide for flexible interaction.
Allow user interaction to be interruptible and undoable.
Streamline interaction as skill levels advance and allow the
interaction to be customized.
Hide technical internals from the casual user.
Design for direct interaction with objects that appear on the
screen.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
7
Reduce the User’s Memory Load
Reduce demand on short-term memory.
Establish meaningful defaults.
Define shortcuts that are intuitive.
The visual layout of the interface should be based on a
real world metaphor.
Disclose information in a progressive fashion.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
8
Make the Interface Consistent
Allow the user to put the current task into a meaningful
context.
Maintain consistency across a family of applications.
If past interactive models have created user
expectations, do not make changes unless there is a
compelling reason to do so.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
9
User Interface Design Models
System perception — the user’s mental image
of what the interface is(end-user)
User model — a profile of all end users of the
system(human-engineer)
System image — the “presentation” of the
system projected by the complete
interface(implementers)
Design model — data, architectural, interface
and procedural representations of the
software(software-engineer)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
10
User Interface Design Process
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
11
Task Analysis and Modeling
All human tasks required to do the job (of the
interface) are defined and classified
Objects (to be manipulated) and actions
(functions applied to objects) are identified
for each task
Tasks are refined iteratively until the job is
completely defined
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
12
Interface Design Activities
1. Establish the goals and intentions for each task.
2. Map each goal/intention to a sequence of specific actions.
3. Specify the action sequence of tasks and subtasks, also
called a user scenario, as it will be executed at the interface
level.
4. Indicate the state of the system, i.e., what does the interface
look like at the time that a user scenario is performed?
5. Define control mechanisms, i.e., the objects and actions
available to the user to alter the system state.
6. Show how control mechanisms affect the state of the system.
7. Indicate how the user interprets the state of the system from
information provided through the interface.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
13
Interface Design Issues
Systems response time (time between the
point at which user initiates some control
action and the time when the system
responds)
User help facilities (integrated, context
sensitive help versus add-on help)
Error information handling (messages should
be non-judgmental, describe problem
precisely, and suggest valid solutions)
Command labeling (based on user
vocabulary, simple grammar, and have
consistent rules for abbreviation)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
14
Design Evaluation Cycle
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
15
UI Design Evaluation Criteria




Length and complexity of written interface
specification provide an indication of amount of
learning required by the users
Number of user tasks and the average number of
actions per task provide an indication of interaction
time and overall system efficiency
Number of tasks, actions, and system states in the
design model provide an indication of the memory
load required of system users
Interface style, help facilities, and error handling
protocols provide a general indication of system
complexity and the degree of acceptance by the
users
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
16
Chapter 16
Component-Level Design
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
17
Agenda
Structured Programming
Graphical Design Notation
Tabular Design Notation
Program Design Languages (PDL)
Comparison of Design Notation
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
18
Component-Level Design
the closest design activity to coding
the approach:
review the design description for the
component
use stepwise refinement to develop
algorithm
use structured programming to implement
procedural logic
use ‘formal methods’ to prove logic
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
19
Stepwise Refinement
open
walk to door;
reach for knob;
open door;
walk through;
close door.
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
20
The Component-Level
Design Model
represents the algorithm at a level of detail
that can be reviewed for quality
options:
 graphical (e.g. flowchart, box diagram)
 pseudocode (e.g., PDL) ... choice of many
 programming language
 decision table
 conduct walkthrough to assess quality
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
21
Structured Programming
for Procedural Design
uses a limited set of logical constructs:
sequence
conditional — if-then-else, select-case
loops — do-while, repeat until
leads to more readable, testable code
important for achieving high quality,
but not enough
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
22
A Structured Procedural Design
add a condition Z,
if true, exit the program
a
x1
b
x2
x3
d
c
e
f
x4
g
x5
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
23
Program Design Language (PDL)
if-then-else
if condition x
then process a;
else process b;
endif
PDL
easy to combine with source code
machine readable, no need for graphics input
graphics can be generated from PDL
enables declaration of data as well as procedure
easier to maintain
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
24
Why Design Language?
can be a derivative of the HOL of choice
e.g., Ada PDL
machine readable and processable
can be embedded with source code,
therefore easier to maintain
can be represented in great detail, if
designer and coder are different
easy to review
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
25
Design Notation Assessment Criteria

Modularity (notation supports development of modular

Overall simplicity (easy to learn, easy to use, easy to write)

Ease of editing (easy to modify design representation when
changes are necessary)
Machine readability (notation can be input directly into a
computer-based development system)
Maintainability (maintenance of the configuration usually
involves maintenance of the procedural design representation)
Structure enforcement (enforces the use of structured
programming constructs)
Automatic processing (allows the designer to verify the
correctness and quality of the design)
Data representation (ability to represent local and global data
directly)
Logic verification (automatic logic verification improves testing
adequacy)
Easily converted to program source code (makes code
generation quicker)







software)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are
provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
26