系统分析及建模

❖ 需求分析是管理信息系统开发活动的起点，分析结果能否准确地反映 用户的实际要求，将直接影响到后续各阶段的开发活动，决定着最终 开发出来的系统能否满足用户的需求。这一阶段是系统建设工作中任 务最为繁重、耗费资源最多的一个时期(功能需求、技术需求)。
4
4.1 系统分析的目标
❖ 需求定义必须满足以下几个方面的要求： （1）完备的：所有需求都必须加以正确说明。 （2）一致的：需求之间应该没有逻辑上的矛盾。 （3）非冗余：不应有多余的、含混不清的需求说明。 （4）可理解：参加的各方应能以一种共同的方式来解释和理解需求。 （5）可测试：需求必须能够验证。 （6）可维护：文档的编写应该是可灵活修改和易读的。
25
4.6 建模
7、建模价值 ❖ 建模（Modeling）是捕捉问题本质的过程。为了降低风险和获得高回报，建模活动
普遍应用于各种行业，信息系统（软件）开发更不例外。为了说明建模的价值， Grady Booch曾经给出过一个经典的类比：
▪ 盖一个宠物窝棚、修一个乡间别墅和建一座摩天大楼，三种工作对建筑规划图 纸的依赖程度有质的差异。建立一个简单的系统，模型可有可无；建立一个比 较复杂的系统，模型的必要性增大；建立一个高度复杂的系统，模型则不可缺 少。应用处理简单系统的方法对待复杂系统通常是行不通的，这好比用搭建一 个宠物窝棚的方法来营造一座摩天大厦。
与计划
划的制订
含计划） （或签协议、订合同）
7
4.2 系统分析的内容与主要活动
活动名称
目标
关键问题
主要成果 （产品）
管理决策
3
现行系统调查
详细调查现行系统 的工作过程，建立 现行系统的逻辑模 型，发现现行系统 存在的主要问题。
现行系统的结构业 务流程和数据的详 细分析，确认存在 的问题（结构化遍 历3W+1H）
24
4.6 建模
6、模型表述 ❖ 模型是一组具有完整语义的信息，包括两个方面的含义：
▪ 一方面，模型是对现实的简化； ▪ 另一方面，模型反映了认知主体（开发人员）对问题域认识的
视角和抽象层次。不同的视角，表现为各种类型的图 （Diagram）及其包含的元素和关联；不同的抽象层次，表现 为不同类型的视图（View）。两者都是模型不可或缺的要素。 ❖ 尽管说模型是简化的现实，并强调化简价值，但这并不意味着可 以片面地夸大图示信息的作用，好的模型应该是图文并茂，其关 键是可用和易用。
❖ 4.1系统分析的目标 ❖ 4.2系统分析内容和主要活动 ❖ 4.3需求分析的重要性 ❖ 4.4系统分析面临的主要问题 ❖ 4.5系统分析相关概念 ❖ 4.6建模 ❖ 4.7 需求分析说明书的编写
3
4.1 系统分析的目标
❖ 系统分析、系统设计和系统实施构成系统开发周期的三个主要阶段。 系统分析是开发人员和用户共同参与的一项活动。这一阶段的主要任 务是充分挖掘和理解用户对新系统的要求，并将其明确表述成一份书 面资料。这份资料的主要内容就是新系统的逻辑模型，这就是系统分 析说明书，又称用户需求说明书。
❖ 简单地讲，模型是对现实的简化、或者说，模型是简化的现实； ❖ 模型会先于方案而存在，模型提供了营造方案的蓝图。
21
4.6 建模
3、建模目的 ❖ 建模的目的，是为了认识复杂的问题（或系统）；简化是认识复杂系统的一种有效方
法；而建模是简化问题的有效手段； ❖ “简化”是有目的的进行的
▪ 准确地讲，一个具体的模型是人对现实系统抽象认知的结果，这一结果取决于人 和他观察问题的角度。人是认知活动的主体，他在认识一个事物的时候，往往是 带有主观意志的，即他会从自己的立场或角度来看问题。
22
4.6 建模
4、建模原则 ❖ 在建立模型的过程中，建模者的主观立场或认识问题的角度，被强调
为认知活动的原则，这很重要。 ❖ 建模过程就是简化问题的过程，就是要把某些主要的关键的东西勾勒
出来，把对讨论问题无关紧要的东西暂时略去，以免干扰视线。 ▪ 因此，在讨论一个系统中的某个问题的时候，我们不是把整个系
现行系统的调 查报告
（审查现行系统 的调查报告）
新系统逻辑方 明确用户信息需求， 用户需求分析，新
4 案的提出
提出新系统的逻辑 系统逻辑模型的建 系统说明书
方案
立（BPR）
审查系统说明书， 若同意，则批准 进入系统设计阶 段
8
4.3 需求分析的重要性
❖ 系统分析的核心任务是用户需求分析。用户需求指的是用户要求新系 统必须满足的所有功能和约束条件，包括用户对功能、性能、可靠性、 安全保密性等方面的要求，以及开发费用、开发周期和可使用资源等 方面的限制，其中功能需求是最基本的。
第 四 章 系 统 分 析 及 建 模
内容简介
❖ 开发周期包括系统分析、系统设计、系统实施等几个重要阶段。 ❖ 本章主要介绍系统分析的相关内容， ❖ 包括：
▪ 系统分析的主要目标和作用； ▪ 系统分析各阶段的主要活动； ▪ 系统分析的方法和工具等； ▪ 最后，给出一个管理信析面临的主要问题
❖ 系统分析活动中，有一些难题是管理信息系统开发项目与生俱来的特 性。
12
难题之一
❖ 需求只能由用户亲自提出来，但用户对计算机系统的不了解，使得他 们无法一次性、完整、准确地讲出所有的需求。实际上，往往是等工 作一段时间，用户对新系统有了一定的认识之后，才会有好的思路和 想法。也有可能是用户心里有想法，但讲不出来。这就需要开发人员 来启发和挖掘需求。
❖ 除此之外，系统的边界和结构的不明确性，业务环境的不断变化的特 性，也是系统分析阶段面对的难题。
14
系统分析员的作用
❖ 以上困难的解决往往寄希望于系统分析员。系统分析员是这一阶段的 关键人物，他要充当技术人员与用户间沟通的桥梁。“桥梁”的作用， 对系统分析员的知识面、业务技能等又是一个极大的挑战。
系统开发 建议书
是否同意系统发建议 书？ 若同意，则安排可行 性研究活动。
进一步明确系统 系统开发的技术可行性 可行性研 审定可行性研究报告，
的目标、规划与 研究、经济可行性研究、 究报告
2
可行性研究 功能，提出系统 营运可行性研究，系统
系统开发 （设计）
若同意，则下达系统 开发（设计）任务书
开发的初步方案 开发初步方案与开发计 任务书（
植性。 (7) 优化业务处理流程和数据流程，定义经济数学算法和模型。 (8)确定计算机系统配置,计算机网络技术方案。
6
4.2 系统分析的内容与主要活动
活动名称
目标
1
初步调查
明确系统开发 目标和规划
关键问题
主要成果 （产品）
管理决策
是否开发新系统？ 若开发，提出新系统的 目标、规划、主要功能 的初步设想，粗略估计 系统开发所需的资源
(1) 可选关系 （2）强制关系 3、事物的属性 4、数据实体和对象 （1）结构化方法 （2）面向对象方法
17
4.5 系统分析相关概念
❖ 事件 1、事件及其类型 （1）外部事件 （2）临时事件 （3）状态事件 2、定义事件 （1）区分事件和触发事件的条件以及系统响应 （2）跟踪事物处理的生命周期 （3）暂不考虑技术依赖事件和系统控制 3、实例（图书管理系统）
用户
系统 分析员
系统设计 员\程序员
图4.1 系统分析员是用户与开发人员之间的桥梁
15
4.5 系统分析相关概念
❖ 模型 （1）数学模型（公式）
(2) 描述模型（判定树、结构化英语） （3）图形模型（逻辑模型、物理模型）
16
4.5 系统分析相关概念
❖ 事物 1、 事物及其类型 2、 事物间的关系（1:1、1：n）
❖ 建模的意义随着系统复杂程度的增加而越发显著，从起初借助于模型以更好地理解 系统，到后来不得不借助模型来理解系统。人脑对复杂问题的理解能力是有限的， 与模型相应的特定视角和抽象层次是简化复杂问题的有效出发点。
26
4.6 建模
❖ 建模对于复杂软件系统的开发是必要的 ▪ 目前，我们开发的软件，特别是商业软件，通常一开始就很不简单，并且复杂性随着时间 的演进和技术的发展持续上升。一个复杂软件系统的开发必须面对多种未知因素、多个开 发人员、复杂的开发工具和永远不够用的时间。开发人员不可能、更没有必要去了解从问 题到方案的所有细节。他们需要那些基于特定视角的、有助于解决问题的并且是完整的某 一部分信息，即所谓的模型。总之，建模对于复杂软件系统的开发是必要的。
❖ 从某个角度看问题，排除不必要的干扰，把问题化简，抓住主要矛盾和事物的本质， 这就是建模的目的。 ▪ 打一个比方，一座大楼在土木设计师眼里可能是一堆钢筋混凝土和表面材质；在 管道设计师眼里可能是一堆管子和接头；在网络工程师眼里可能是一堆网络设备 和布线。不同主体对同一客体的认识结果有赖于各自的视角，即看问题的角度。 这样能更好地集中注意力，从而有效地解决关键问题。
5
4.2 系统分析的内容与主要活动
系统分析的基本内容： 系统分析阶段需要对管理信息系统的下列问题进行调研和分析：
（1）确定新系统的目标。 （2）系统的总体结构描述。 （3）子系统功能描述： （4）子系统数据分析： （5）数据输入输出描述： （6）确定技术性能指标，包括可靠性、安全保密性、适用性、可维护性和可移
9
4.3 需求分析的重要性
❖ 需求分析阶段的工作质量，对于项目的开发成本有绝对的影响。 费用 1000 修正错误的成本
50
需求
设计
编码 开发测试 应用测试 实际运行
10
经验与教训
❖ 需求定义是否准确、真实，甚至决定项目的成败，必须引起足够的重 视，应有保障需求定义质量的技术手段。如果需求定义不完整、不合 乎逻辑、不贴切或使人易于发生误解，那么后续的开发活动可能就是 在为一个错误的、不合乎逻辑的、不贴切的用户需求定义，设计了一 个好的实现方案，编制了相应的高质量的代码，这样的设计和程序编 码都是徒劳的。不论后续开发工作质量如何，都必然导致项目失败。