Ch.4 The UCSD Process
The Waterfall Model
Requirements
Architectural
Design
Detailed Design
Coding
Integration
Deployment
Maintenance
Weaknesses of the WF Model
• Focus is on Tech. (take a purely technical systems approach)
• Reflects the views of the designer and not of the stakeholder
– Holds information in their mind
– Difficult to find locations
– Easy process for designer yet difficult for the user
• The user interface is designed around a technical view of how the
system works
• Problem lies with the process by which systems are developed
– The process is sequential
– ‘get it right the first time’
Stages of the WF Model
• Requirements Specification:
– based upon a good understanding of users and their needs
– How to get users needs?
– Key Issues:
• What data to collect
• Explore requirements.
• Poorly defined requirements leads to project failure
– Types of Requirements:
•
•
•
•
•
Functional R’s - ex, providing the means of undoing an action
Data R’s - ex, car rental system
Environmental R’s - ex, the system will run on Linux OS
User R’s - ex, the typical user, significant subgroups
Usability R’s - ex, the system must provide clear instructions
Stages of the WF Model
• Architectural Design:
– Requirements focus upon what is required: architectural design is focused on
how it can be achieved.
• Detailed Design:
– Its developed from the architectural design, selecting between available
options
• Coding & Testing:
– Given a detailed design, the next step is to produce software and to test it
thoroughly.
– Spotting bugs for repair
• Integration & Deployment:
– the individual components are integrated according to the overall
architectural design
• Maintenance:
– This is when the system in in use
– It is not part of the design process
Problem Stmt
UCSD
Task Analysis
Usability Guidelines
& heuristics
Technical & Legal
Constraints
Requirements
Gathering
Design &
Storyboarding
Prototype
Implementation
Evaluation
Installation
Observation of
existing systems
HTA
Requirements Stmt:
-functional
-non-functional
Storyboard
Prototype
Transcript Evaluation
Final Implementation
UCSD
3 themes of the UCSD:
1. Analyze users and their needs
2. Evaluate ideas with potential users
3. Test to be sure the design works well with users
Key Activities of the UCSD
• Task Analysis
– Inputs to TA:
• Problem stmt
• Observation of existing systems
• Analysis of user population
– Outputs to TA:
• HTA
– Why do TA?
• It provides a clear understanding of what clients want
• It gives a clearer understanding of what users want
• Redesign of an existing product
Key Activities of the UCSD
• Requirements Gathering
– Inputs to RG:
•
•
•
•
•
HTA
Design Heuristics
Relevant user models
Usability principles
Other constraints
– Outputs to RG:
• A stmt of requirements
– Why do we need to have a stmt of requirements?
• It provides an explicit , testable description of what is wanted of
the system
• It describes what the system should do without worrying too much
about how it does it.
Key Activities of the UCSD
• Design & Storyboarding
– Inputs to D&S:
•
•
•
•
Stmt of Requirements
Usability principles and Heuristics
Other constraints
Evaluation from previous iterations
– Outputs to D&S:
•
•
•
•
A storyboard design
System justification: why the system is going to be the way it is
A first-draft design of how the system works and what it looks like
A stakeholder analysis
– Why do we need a D&S phase?
• It provides designers with an opportunity to visualize their design
and review it, quickly and cost-effectively with users.
Key Activities of the UCSD
• Prototype Implementation
– Inputs to PI:
• A storyboard design
• Evaluation from previous iterations
– Outputs to PI:
• A working testable prototype
– Why do we need to prototype our designs?
• It provides designers with an opportunity to visualize their design and review it, quickly
and cost-effectively with users.
• Different types of prototypes:
– Wizard of Oz - the prototype is controlled by the designer ‘behind the scenes’
– Horizontal P. - simulates the user-interface only with no functionality
– Vertical P. - has full functionality but for a limited vertical slice of the proposed
system
– Full P. - has full functionality but low performance
Key Activities of the UCSD
• Evaluation
– Inputs to E:
• A working prototype
• Stmt of Requirements
– Outputs to E:
• Transcript of the evaluation: what was said or done during the evaluation
• The evaluation report . Ex, Are the requirements met? If not, why not?
– Why do an evaluation?
• It provides tangible evidence of how a system is actually used.
• Heuristic Evaluation
– Commonly used
– Quick and cost effective
– Done by a team of 5 conductors
Key Activities of the UCSD
• Installation
– Inputs to I:
• A fully featured ‘prototype’
– Outputs to I:
• An acceptable evaluation
• The ‘finished’ system