1. Ch.4 The UCSD Process

2. Integration Deployment
The Waterfall Model
Requirements
Architectural Design
Detailed Design
Coding
Integration Deployment
Maintenance

3. 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’

4. 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

5. Stages of the WF Model Architectural Design: Detailed 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

6. UCSD Observation of existing systems Problem Stmt Task Analysis HTA
Requirements Stmt:
-functional
-non-functional
Usability Guidelines & heuristics
Requirements Gathering
Design & Storyboarding
Technical & Legal Constraints
Storyboard
Prototype
Prototype Implementation
Transcript Evaluation
Evaluation
Final Implementation
Installation

7. UCSD 3 themes of the UCSD: Analyze users and their needs
Evaluate ideas with potential users
Test to be sure the design works well with users

8. 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

9. 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.

10. 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.

11. 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

12. 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

13. Key Activities of the UCSD
Installation
Inputs to I:
A fully featured ‘prototype’
Outputs to I:
An acceptable evaluation
The ‘finished’ system