1 / 13

Ch.4 The UCSD Process

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)

plato-coleman
Download Presentation

Ch.4 The UCSD Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ch.4 The UCSD Process

  2. 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: • 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

More Related