第5章 确定面向对象系统的需求.ppt

1、3-1,第5章 确定面向对象系统的需求,面向对象系统分析与设计 Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer,4-2,本章目标,学习本章后应该能够: 描述为确定系统需求而设计和引导的访谈的可选方案和开发计划. 解释观察工作人员和分析业务文档以确定系统需求的优点和不足. 参与并帮助策划一个联合应用程序设计会议 在确定系统需求时使用原型法. 描述确定需求的敏捷方法 选择恰当的方法导出系统需求,5-3, Prentice Hall, 2007,4-4,5.1 需求确定,需求描述系统应该做什么 系统能够或者将要执

2、行的功能 系统包含的对象及其状态 对象所需的属性 关于对象的行为的约束信息,5.1.1 需求是什么,4-5,需求来源 用户、报表、 表单和程序 确定需求的成功要素 鲁莽 公正 放宽限制 注意细节 再构造,5.1.2 确定需求的过程,5-6, Prentice Hall, 2007,5.1.3 交付产品和结果,4-7,确定需求需要大量时间和人力 尽量避免分析停滞 重点关注要开发的系统而非当前系统,5.1.4 需求组织,5-8, Prentice Hall, 2007,5.2 确定需求的传统方法,5-9, Prentice Hall, 2008,5.2.1 访谈和倾听,与用户或管理人员对话以获取他

3、们的需求 两种访谈表单: 开放式：谈话式的，问题没有确定答案 封闭式：结构化的，问题的答案在限定范围内,5-10, Prentice Hall, 2007,如何组织访谈,5-11, Prentice Hall, 2007,访谈指南是开发、设计和组织访谈的文档.,5-12, Prentice Hall, 2007,访谈指南中的每个问题可以包含语言的和非语言的信息.,5-13, Prentice Hall, 2007,5.2.2 直接观察用户,观察用户的工作 目的 获取雇员与信息系统之间交互的第一手的，客观的方法或度量 能提供比访谈中的自我称述更为准确的信息 不足 被观察的雇员可能会改变其行为；时

4、间上的约束使观察更为困难,5-14, Prentice Hall, 2007,5.2.3 分析程序和其它文档,研究对象 现有的系统和组织的业务文档 可以提供历史的和“正式的”系统需求的观点 相关文档 任务声明，业务规划，组织结构图，经营方针，作业描述，商业函件，组织研究报告等,5-15, Prentice Hall, 2007,书面工作程序是一种正式的描述工作过程的业务文档，可以提供关于系统功能和逻辑的有用的信息。,5-16, Prentice Hall, 2007,正式 vs. 非正式系统,正式系统 用组织文档描述的系统工作的正规方式 非正式系统 系统实际的工作方式,5-17, Prenti

5、ce Hall, 2007,业务表单是包含数据组织和可能的屏幕输出的有用信息的文档。,5-18, Prentice Hall, 2007,报表是用表格、图表等格式来动态显示数据。,5-19, Prentice Hall, 2007,观察 vs. 文档分析,5-20, Prentice Hall, 2007,5.3.1 联合应用程序设计 (JAD),紧张而高度组织化的需求确定技术 团队成员在同一时间聚集在离正常工作较远的地点 高度集中 资源密集 起源于IBM，1970s,5.3 确定需求的现代方法,5-21, Prentice Hall, 2007,JAD 团队成员,会议引导者协调员 用户信息来

6、源 管理人员信息来源 主办者JAD的后台与保证 系统分析员学习与倾听 抄写员记录者 IS 员工学习与倾听,5-22, Prentice Hall, 2007,5-23, Prentice Hall, 2007,5.3.2 原型法,分析人员和用户根据用户的反馈构建一个信息系统的初步版本的反复的过程 重复的循环：构建，使用，评估,5-24, Prentice Hall, 2007,5-25, Prentice Hall, 2007,何时使用原型,下列情况使用原型较好： 用户需求不清楚或不好理解. 系统影响到的用户数量相对较少. 设计比较复杂. 用户与分析人员之间的沟通需要被强化. 可以利用快速开发

7、工具.,5-26, Prentice Hall, 2007,原型的弊端,原型存在以下的缺点： 逃避创建正式的系统需求文档的趋势 原型可能成为个人用户的特异风格，其它用户难以接受 原型作为独立系统设计，因此没有强调数据共享和集成的问题 忽视了SDC中的检查，因此诸如安全性、控制和标准等问题可能被忽略,5-27, Prentice Hall, 2007,5.3.3 确定需求的敏捷方法,在系统设计期间鼓励用户不断参与并适应增量式的变化以引导出用户需求的技术 两类方法： 敏捷的以用户为中心的设计(与JAD类似) 极限编程,5-28, Prentice Hall, 2007,5.3.4 敏捷的以用户为中

8、心的设计步骤,将相关人员聚集在一个封闭的环境中 给每个人宣泄对系统的不满的机会并记录下这些抱怨 确定并列出最重要的用户角色 确定每个用户角色的任务 根据相似性将任务分组为“交互上下文” 在“交互上下文”中为每个任务写下任务描述 将每个“交互上下文” 看做一个独立的用户界面屏幕，并创建其原型 列出用户界面的所有步骤，确保这些步骤能在原型中实现,5-29, Prentice Hall, 2007,5.3.5 极限编程,典型的2人编程团队 计划、分析、设计和实现阶段的融合 特点： 开发周期短 增量式计划 注重自动化测试以监控开发过程 对演化式开发的依赖,5-30, Prentice Hall, 2007,极限编程计划游戏,玩家 业务（客户）和开发（系统建设者） 三个阶段：探究、承诺、指导 三摞故事卡片 必须的特征 增值的特征 最好要有