面向对象系统分析和设计 第02章 习题.txt

C&C++论坛精华

     答: 按照科萨尔的模型, 需求确定分为5个层次, 第一部分是内部/外部刺激. 类似信息系统的来源--问题, 机会和命令. 通常只会影响到第二部分的商业目标.

     → → → → → → → → → → → → → → → → → → → → → → → → 
     19.什么情况下, PIECES模型比需求模型更为实用?
     答: 在拥有精确完整的商业模型, 任务陈述或者目的陈述的时候科萨尔模型占有优势, 反之PIECES模型占优势.

     → → → → → → → → → → → → → → → → → → → → → → → → 
     20.说出并简述科德对问题域需求的搜集和建模的面向对象方法的四大活动
     答: 是
         1) 确定信息系统的目的和特点
         2) 确定对象和模式
         3) 建立对象责任
         4) 设计系统的动态场景

     → → → → → → → → → → → → → → → → → → → → → → → → 
     21.说出并简述科德对问题域需求的搜集和建模的面向对象方法的四大组成部分
     答: 是
         1) 问题域
         2) 人机交互
         3) 数据管理
         4) 系统交互

     → → → → → → → → → → → → → → → → → → → → → → → → 
     22.搜集需求的全局, 个人和团体方法各是什么? 这些方法存在的问题是什么?
     答: 具体方法描述如下:
         1) 全局
            从历史和横向观点进行调查的过程: 检查现有及以前的文档, 调查其他公司的类似工作, 参观类似系统
         2) 个人
            从微观角度的调查过程: 使用采访, 观察, 问卷/调查, 原型测试等方法进行
         3) 团体
            使用群件手段 -- 原型设计, 快速分析, 联合开发(JAD), 头脑风暴, 电子联合开发(EJAD)等团队讨论手段

         这些方法存在地问题如下:
         1) 全局
            有利于系统分析员熟悉新系统的情况, 了解最起码的系统需求. 问题在于需求确定过程不但是一个认知的过程也是一个创造性过程, 同时同类系统的需求也不是一成不变得, 而且不能单方面只顾及系统分析员一方而忽略了和用户及其开发小组成员的交流; 同时也要考虑到诸如认识程度等其他因素的干扰.
         2) 个人
            有利于确定用户的真正需求. 问题在于着重点的时候不能忽视面. 而且耗时过长.
         3) 团队
            有利于提高效率, 增强凝聚力, 改善和用户的关系, 是综合讨论结果的自然方法; 对于不善于交流, 无法解决冲突, 包含无关人员的项目团队是一场灾难. 同时, 系统分析员需要检查讨论清单的可行性, 并且根据用户可见性和技术可行性把清单上的条目分为必要的和有用的两类. 任何改动都应该及时反馈给用户, 因为团队讨论的结果是用户希望的基础

         上述三个方法的基本特点在于:
         1) 必须向用户反馈求得确认
         2) 需要上下文无关的背景内容
         3) 需要良好的沟通技巧

     → → → → → → → → → → → → → → → → → → → → → → → → 
     23.在需求确定过程中最应该牢记得是什么?
     答: 我认为应该是沟通, 不管使用何种方法, 最终必须求得用户认同, 同时需要随时反馈修改状况, 使得用户没有感觉自己在设计开发阶段是远离系统的.

     → → → → → → → → → → → → → → → → → → → → → → → → 
     24. 什么是建立原型? 在需求确定过程中有什么作用?
     答: 建立原型就是由个人或者团体完成一个代表预测基本功能的模拟系统, 来考察系统情况, 收集用户反映. 作用在于, "用户知道看到不想要的东西, 才知道自己需要什么". 所以在需求确定阶段建立原型的价值就是消除系统不受欢迎的功能, 确定系统需要的功能.

     → → → → → → → → → → → → → → → → → → → → → → → → 
     25. 其他团队层次的技巧是什么? 怎样运用这些技巧改善系统?
     答: 包括快速分析技巧和JAD, 团队头脑风暴, EJAD和团队系统软件 ==> 群件. 
         集中起来就是两大主流:
         1) 团队讨论
            发挥每一个人的主观能动性, 搜集尽可能多的想法, 甚至是上下文无关的背景内容; 通过综合分析得到必要以及非必要的需求
         2) 原型设计
            原型根据其形象性和可操作性的特点, 可以以"实战"的角度审视整个系统, 便于用户确认需求和发现潜在的系统问题.
     

     → → → → → → → → → → → → → → → → → → → → → → → → 
     26. 举例说明需求确定阶段团队层次的交互怎样可能导致失败?
     答: 首先我们审视团队方式的优势:
         1) 增强凝聚力
         2) 改善用户交流
         3) 集中处理个人意见

         由此可见, 这是事物的正面, 这些都是基于交流顺畅的前提, 否则就会走向事物的反面:
         1) 如果不能很好的协调团队, 调整团队对于不同见解的统一认识, 反而会降低团结性
         2) 如果不能很好的同用户交流, 用户反而无法将自己的需求正确反映到系统分析团队
         3) 如果无法正确分析不同意见, 就无法保证用户可见性和技术可行性

     → → → → → → → → → → → → → → → → → → → → → → → → 
     27. 描述需求确定阶段团队讨论的步骤?
     答: 其实这是一个反复过程, 就是从讨论开始, 结合原型设计进行逐步什么和有目标的讨论; 以无法得到进一步想法为限.

     → → → → → → → → → → → → → → → → → → → → → → → → 
     28. 不管采用何种搜集方法, 需求确定最核心的三个一般因素是什么?
     答: 用户认同, 背景辅助内容, 良好的沟通

     → → → → → → → → → → → → → → → → → → → → → → → → 
     29. 需求确定的主要目的是什么?
     答: 确定信息系统的真正需求和功能描述

     → → → → → → → → → → → → → → → → → → → → → → → → 
     30. 讨论导致需求二义性的问题, 怎样减轻这些问题?
     答: 主要有三个来源:
         1) 遗漏的需求
            减少一些必要因素的考虑
         2) 模棱两可的措辞
            要求用词明确
         3) 新加入的成分
            不要擅自添加功能而不向用户反馈

     → → → → → → → → → → → → → → → → → → → → → → → → 
     31. 在需求确定过程中, 为什么改正错误和缺陷很重要?
     答: 因为发现越早, 投入的财力和物力相对越少.