系统分析教学幻灯片讲义.ppt

第四章 系统分析;本章重点;教学目的与要求;案例：软件工程师毫无用处？ “软件工程师毫无用处，我宁愿雇佣雷达专家教会他如何编程，也不愿意雇佣程序员来教会他雷达信号流程”。这段措辞严厉的声明来自于一位大型政府项目的经理，他所在部门的电脑系统曾经错误地发出了ICBM导弹来袭的警报。更加令他不能忍受的是程序员拒绝对此错误的功能承担责任。 程序员抱怨说这是由于系统说明不够全面造成的，而并非自己的原因。这位经理意识到，需求文档没有指出特定的环境会导致错误的警报，但他仍认为他所在部门的编程人员应该具备这样的基本知识的。 “没有任何雷达专家会犯如此基本的错误”，他坚持说。;课堂讨论： 1.如何理解项目经理的抱怨？ 2.在一个项目需求调研过程中，系统分析人员发现对用户进行简单的培训，他们做出的系统分析说明要比系统分析人员更加准确，你觉得这样的现象正常吗？;4.1系统分析概述;4.1系统分析概述;IEEE软件工程标准词汇表中将需求定义为： 用户解决问题或达到目标所需的条件或能力（Capability）。 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 一种反映上面（1）或（2）所描述的条件或能力的文档说明。 该定义从用户角度（系统的外部行为）和开发者角度（一些内部特性）来阐述了需求的含义。;需求是人们的期望。 探索需求是寻找人们的期望的过程。 开发就是把人们的期望转化成一种能够满足其期望的产品的过程。;“用户所需要的并能触发一个程序或系统开发工作的说明”（强调产品是什么样的，而并非产品是怎样设计、构造的。 需求是指明必须实现什么的规格说明。 它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。 需求是指用户要求软件系统必须满足的所有功能和限制。 需求包括： 功能要求、性能要求、可靠性要求、安全保密性要求以及开发费用和开发周期、可使用资源等方面的限制。;3、工作思路 遵循系统化和结构化的工作思路来进行。 按照先进行逻辑模型设计后进行物理模型设计的工作步骤进行开发。 ;4.1系统分析概述(续);4.1系???分析概述(续);目标 按系统规划所定的某个开发项目范围内，明确系统开发的目标和用户的功能和信息需求，提出系统的逻辑方案。 在整个系统开发过程中，解决系统“做什么”的问题，为下一阶段系统设计和实施提供依据。 主要活动;;（1）初步调查的目标 从系统分析人员和管理人员的角度看新项目开发有无必要和可能。 （2） 初步调查的内容 调查内容: 有关组织的整体信息 有关人员的信息 有关工作的信息（只了解做了什么，有什么问题），包括主要的输入、主要的输出、主要的处理功能以及与其他系统的关系。 分析内容包括： 现有什么 需要什么 在现有资源下能提供什么 此项目有无必要和可能作进一步的调查与开发 ;（3）调查结论及工作成果 可能得出下列结论之一 拟开发项目，有必要也有可能进行?????????? 不必要进行项目开发，只要对原有系统进行适当修改 原有系统未充分发挥作用，只需发挥原有系统的作用 目前无必要开发此项目 目前不具备开发此项目的条件;《系统开发建议书》的内容：;4.1系统分析概述(续);4.1系统分析概述(续);4.2可行性分析; 2、详细调查的内容 ;3、系统调查方法 ;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）; ;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;一般的组织结构图;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;;职能与功能的区别 组织的功能是组织完成某项具体任务的系列操作， 组织的职能是指组织完成某个目标的系列动作。 职能比功能粗，常是功能的集合，职能也称功能域。 职能具有稳定性，功能会因为技术、管理条件的变 化而变化。 展望 职能不宜划分太细 职能分析可与后面的业务分析、数据分析相结合进行 职能分析中可以进行一些优化、调整，以实现管理优化;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;4.3业务分析（续）;18.3 业务流程分析;图例