Ch.4 The UCSD Process

Integration Deployment 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: 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

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

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

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