OOSADChapter5.pptVIP

5-* ? Prentice Hall, 2007 5-* ? Prentice Hall, 2007 5.3.2 原型法 分析人员和用户根据用户的反馈构建一个信息系统的初步版本的反复的过程 重复的循环：构建，使用，评估 5-* ? Prentice Hall, 2007 5-* ? Prentice Hall, 2007 何时使用原型 下列情况使用原型较好： 用户需求不清楚或不好理解. 系统影响到的用户数量相对较少. 设计比较复杂. 用户与分析人员之间的沟通需要被强化. 可以利用快速开发工具. 5-* ? Prentice Hall, 2007 原型的弊端 原型存在以下的缺点： 逃避创建正式的系统需求文档的趋势 原型可能成为个人用户的特异风格，其它用户难以接受 原型作为独立系统设计，因此没有强调数据共享和集成的问题 忽视了SDC中的检查，因此诸如安全性、控制和标准等问题可能被忽略 5-* ? Prentice Hall, 2007 5.3.3 确定需求的敏捷方法 在系统设计期间鼓励用户不断参与并适应增量式的变化以引导出用户需求的技术 两类方法： 敏捷的以用户为中心的设计 与JAD类似 极限编程 5-* ? Prentice Hall, 2007 5.3.4 敏捷的以用户为中心的设计步骤 将相关人员聚集在一个封闭的环境中 给每个人宣泄对系统的不满的机会并记录下这些抱怨 确定并列出最重要的用户角色 确定每个用户角色的任务 根据相似性将任务分组为“交互上下文” 在“交互上下文”中为每个任务写下任务描述 将每个“交互上下文” 看做一个独立的用户界面屏幕，并创建其原型 列出用户界面的所有步骤，确保这些步骤能在原型中实现 5-* ? Prentice Hall, 2007 5.3.5 极限编程 典型的2人编程团队 计划、分析、设计和实现阶段的融合 特点： 开发周期短 增量式计划 注重自动化测试以监控开发过程 对演化式开发的依赖 5-* ? Prentice Hall, 2007 极限编程计划游戏 玩家 – 业务（客户）和开发（系统建设者） 三个阶段：探究、承诺、指导 三摞故事卡片 必须的特征 增值的特征 最好要有的特征 在迭代计划游戏中故事卡片被任务卡片所取代 5-* ? Prentice Hall, 2007 4-* 本章小结 学习本章后可以 设计与引导访谈. 运用直接观察与业务文档分析法. 参与JAD会议. 在确定需求时使用原型. 在确定需求时使用敏捷方法. Chapter 5 ? Prentice Hall, 2008 ? Prentice Hall, 2008 Chapter 5 ? Prentice Hall, 2007 Chapter 5 ? Prentice Hall, 2007 Chapter 5 ? Prentice Hall, 2007 Chapter 5 ? Prentice Hall, 2007 Chapter 5 ? Prentice Hall, 2007 Chapter 5 ? Prentice Hall, 2007 Chapter 5 ? Prentice Hall, 2007 Chapter 5 ? Prentice Hall, 2007 Chapter 5 ? Prentice Hall, 2007 3-* 第5章 确定面向对象系统的需求 面向对象系统分析与设计 Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer 4-* 本章目标 学习本章后应该能够: 描述为确定系统需求而设计和引导的访谈的可选方案和开发计划. 解释观察工作人员和分析业务文档以确定系统需求的优点和不足. 参与并帮助策划一个联合应用程序设计会议 在确定系统需求时使用原型法. 描述确定需求的敏捷方法 选择恰当的方法导出系统需求 5-* ? Prentice Hall, 2007 4-* 5.1 需求确定 需求描述系统应该做什么 系统能够或者将要执行的功能 系统包含的对象及其状态 对象所需的属性 关于对象的行为的约束信息 5.1.1 需求是什么 4-* 需求来源 — 用户、报表、 表单和程序 确定需求的成功要素 鲁莽 公正 放宽限制 注意细节 再构造 5.1.2 确定需求的过程 5-* ? Prentice Hall, 2007 5.1.3 交付产品和结果 4-* 确定需求需要大量时间和人力 尽量避免分析停滞 重点关注要开发的系统而非当前系统 5.1.4 需求组织 5-* ? Prentice Hall, 2007 5.2 确定需求的传统方法 5-* ? Prentice Hall, 2008 5.2.1 访谈和倾听 与用户或