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

C&C++论坛精华

作者：rick1126
email: [e-mail]
日期：8/15/2001 6:48:56 AM
第2章 可行性分析和需求确定


   【可行性分析】

   〖信息系统开发可行性〗

     . 可行性分析是位于系统计划之后的一个可选的但是非常重要的系统分析和设计的分析阶段的活动
     . 可行性分析的一个考虑因素就是是否有利可图
     . 用来度量开发或者增强一个信息系统能够给公司带来多大收益
     . 增进用户的信任 -- 随着时间的推移, 加强用户对所开发的信息系统的忠诚度和拥有程度
     . 在关键时刻了解项目的进展
       - 按照原定计划继续
       - 改变
       - 取消

   〖可行性类型〗

     . 操作可行性    度量给定环境的工作性能
     . 技术可行性    度量实用性和技术资源可用性
     . 经济可行性    度量性能价格比 -- 给定时间内开发和运行信息系统的费用和财务回报

   〖相关费用和收益〗

     . 系统开发费用        一次性费用
     . 年运行费用        常年性费用

     . 可见收益
       - 处理        减少错误, 增强能力
       - 响应        更迅速
       - 消除工作等级    
       - 增收节支
       - 提高信誉
       - 减少信誉损失
       - 减少应收款项
     . 不可见收益
       - 增加客户信任
       - 增强雇员士气, 工作满意度
       - 提供更好服务
       - 改善决策


ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ
   【需求确定】

   〖概念〗

     讨论如何寻求记录信息系统的真正需求

   〖难度〗
    
     . 需求确定是极具认知性和创造性的重复性循环渐进的活动
     . 问题域的动态性
     . 人和人之间的沟通问题
     . 其他因素

   〖问题域〗

     . 商业领域或者商业功能
     . 研究目的就是为了增强商业功能, 考虑是否购买, 新建, 改进信息系统
     . 确定问题域的范围和边界需要反复权衡和折衷

   〖需求确定技巧〗

     . 划分需求主题领域的框架和方法, 不会遗漏需求领域
     . 如何向用户提问的指南和经验

   〖划分问题域框架〗

     . 需求确定子活动

       - 需求期望        基于经验和理解, 假定存在的某些需求
       - 需求引导        使用各种技巧向用户征求需求
       - 需求验证        和用户一起确认需求的有效性和正确性
       - 需求规格说明    该活动的产品
       * 上面的4个活动相互联系可以反复进行

     . PIECES框架

       - Performance(性能)    系统怎样为用户服务 = 处理能力 + 反应时间
       - Information(信息)    为持久性数据的信息模型或者数据模型奠定基础
       - Economy    (经济)    开发和运行维护费用, 以及一切系统相关的经济目标和错误目标
       - Control    (控制)    与系统安全相关及编辑输入数据有关
       - Efficiency (效率)    衡量方法正确与否 = 公司, 部门, 个人
       - Services   (服务)    功能相关, 还涉及易用性, 对持续使用维护系统, 培训和文档需求提供必要的支持

     . Kozar 需求模型

       - 比较特点: 将信息系统的目标和策略同商业目标和策略联系, 需求模型的关键就是如何建立商业目标和信息系统之间的联系
       - 模型层次
         内部/外部刺激    表达变革的要求或者希望
         商业目标        针对实现该机构目的的详细书面陈述, 可度量的, 通常有明确的时间和资金规定, 安装TQM观点, 需要不断提高和超越
         商业策略        实现商业目标的具体行动, 如果含有信息系统, 则形成两个层次: 信息系统目标和策略
         信息系统目标    直接支持一个或者多个商业策略
         信息系统策略    如何实施信息系统的目标, 表示系统分析员和其他技术人员为达到系统目标而进行的工作

       - 基本原则: 更抽象或者更具体
       - 过程顺序: 任务/意图( 信息系统需要存在的理由 ) -> 目的( 总体系统陈述 ) -> 目标( 可度量的开发目标 ) -> 策略和要求( 如何实现目标 ) -> 信息系统( 用户的行动支持 )

     . 需求模型的优缺点和适用范围
       
       - 优势在于利用良好的商业策略模型
       - 缺点在于如果现实中一般没有非常精确完整的商业策略

       - 在商业模型不明确的时候, PIECES更好

   〖面向对象的需求确定建模活动〗

     . 建模方法的基本思考概念
       - 对象    任意感兴趣的研究对象
       - 模式    带有典型责任和交互的模板, 模板可以复用, 是构成对象的基本材料; 其实模式就是类型即对于对象的抽象
       - 责任    对象自身了解( 属性, 状态 ); 对象相互关系( 联系 ); 对象提供的服务( 功能 )
       - 场景    完成特定功能所需要的一组对象交互顺序( 流程 )

     . 建模方法的步骤
       - 确定信息系统的目标和特点
       - 确定对象和模式
       - 建立对象的责任
       - 设计系统的动态场景

     . 模型的组成
       - 问题域
       - 人机交互
       - 数据管理
       - 系统交互

ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ
   【搜集信息系统需求的方法】

   〖角度〗
     
     . 全局
       - 主要是从历史和横向角度进行需求收集, 不直接面对用户. 通过现有的文档, 其他公司的商业目标/策略, 同类系统的目标/策略进行需求收集.
       - 优点: 有利于系统分析员熟悉新系统情况, 了解起码的系统需求
       - 缺点: 着重当前或者以前的工作, 忽视未来的改进工作, 处于仿造角度考虑

     . 个人
       - 通过采访用户, 问卷或者调查方式, 建立原型期待用户反馈等方式进行, 直接从用户方面得到需求
       - 原型: 用户直到看到自己不想要的东西的时候才知道自己需要什么
     
     . 团队
       - 主要使用团队头脑风暴, 电子联合应用开发, 团队系统软件等团队讨论手段, 是的用户, 系统分析员, 开发小组一起讨论需求
       - 优点: 增强团队凝聚力, 用户的想法得到承认, 用户个人意见得到集中处理 ==> 综合讨论结果的自然方法
       - 缺点: 人际关系如果不能正确协调, 系统分析员不能从头脑风暴中正确得到需要的信息, 对于项目是一场灾难
       - 划分: 按照 [现在必要] [将来需要] [不需要] 进行划分
       - 可行性: 可见性, 技术可行性
       - 特点: 必须向用户反馈得到确认, 需要上下文无关内容, 需要良好的沟通技巧

   〖需求的不确定性〗

     . 需求搜集作为一种高度感性的充满不确定性的活动面临各种潜在问题
       - 遗漏的需求 -- 颠覆系统的可能
       - 模棱两可得措辞
       - 新加的成份 -- 自做主张

ˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉˉ