五、软考·系统架构师——系统分析

系列文章

一、程序员进阶架构师的基础知识【计算机基础】
二、程序员进阶架构师的基础知识【操作系统】
三、程序员进阶架构师的基础知识【计算机网络基础】
四、程序员进阶架构师的专业知识【软件工程基础】
五、程序员进阶架构师的专业知识【UML建模工具】
六、程序员进阶架构师的专业知识【系统分析】
七、程序员进阶架构师的专业知识【系统设计】
八、程序员进阶架构师的专业知识【架构设计】
九、程序员进阶架构师的专业知识【架构质量及评估】
十、程序员进阶架构师的专业知识【软件测试及维护】

前言

  《软件工程基础》中有写需求分析是整个系统建设的关键阶段。系统分析阶段也称为逻辑设计阶段，系统分析师要和用户一起对现有系统进行详细调查，把用户的初始需求具体化、明确化，描述现有系统的业务流程，指出现有系统的局限性和不足之处（这里的现有系统不一定是软件系统），确定新系统的基本目标和逻辑功能要求，最终转换成关于新系统“做什么”的逻辑模型。工作成果体现在系统需求规格说明书中，这是系统建设的必备文件，是系统设计阶段的工作依据，也是将来系统验收的依据。

---

调查阶段

  调查阶段需要深入了解企业管理工作中信息处理的全部具体情况和存在的具体问题，对系统所涉及领域的各个方面，根据科学合理的原则，采用科学合理的方法，进行静态信息(例如，组织结构、系统功能等)和动态信息(例如，业务流程、数据流程等)周密完备的调查，为提出新系统的逻辑模型提供可靠的依据。调查的主要方法有：

收集资料

收集资料就是把与系统有关的、对系统开发有益的信息收集起来。它是调查的基本手段，只有收集了资料，才能进行调查。

开调查会

开调查会也称为座谈调查，这是一种集中征询意见的方法，适合于对系统的定性调查。开调查会可以按两种方法进行组织，一种是按职能部门召开座谈会，了解各部门的业务范围、工作内容、业务特点，以及对新系统的想法和建议;另一种是召开联合讨论会，即各类人员联合座谈，着重听取用户对现有系统存在的问题和对新系统的要求。

个别访问

个别访问也称为用户访谈或面谈，这种方法是对开调查会的一种补充。开调查会不能完全反映每个与会者的意见，在会后根据需要再进行个别访问是很有必要的。访问是收集数据的主要来源之一，可以充分听取各方面的要求和希望。

书面调查

书面调查也称为问卷调查或表格调查，是一种根据系统特点设计调查表，进行问卷访问，征求意见和收集数据的方法。当系统比较复杂时，项目干系人会很多，涉及范围会很宽，采用这种方法会获得比较好的效果。

抽样调查

抽样调查也称为采样，是根据概率统计的随机原则，从全体被调查对象中选取部分对象进行详细调查，并将统计分析得出的调查结果推广到全体对象。该方法适用于那些需要全面资料而又不可能进行全面调查，或者进行全面调查有困难，或者没有必要进行全面调查的情况。

现场观摩

现场观摩也称为观察法或实地调查，对于许多较为复杂的流程和操作而言，是比较难以用言语表达清楚的，而且这样做也会显得很低效。因此，针对这一现象，系统分析师可以就一些较复杂、较难理解的流程和操作采用现场观摩的方法来获得需求。具体来说，就是走到客户的工作现场，一边观察，一边听客户的讲解。

参加业务实践

针对具体存在的问题，扮演或模拟扮演系统中的角色或元素，参加系统的业务实践。通过参加业务实践，可以非常有效地发现问题的本质和寻找解决问题的办法。

阅读历史文档

阅读历史文档也称为文档考古。对于一些数据流比较复杂的，工作表单较多的项目，有时是难以通过说，或者通过观察来了解系统细节的。这时就可以借助于阅读历史文档的方法，对历史存在的一些文档进行研究，从中获得所需的信息。该方法的主要风险是历史文档可能与新系统的流程、数据有一些不吻合的地方，并且还可能承载一些现有系统的缺陷。要想有效地避免和发现这些问题，就需要系统分析师能够运用自己的聪明才智，将其与其他详细调查技术结合，以便对照。

  以上八种详细调查的方法不是互相排斥的，而是包容和交叉的关系。例如，现场观摩和参加业务实践可以结合起来使用，在现场观摩的同时，对复杂业务进行实践。另外，为了便于系统分析师和用户之间进行业务交流和分析问题，在调查过程中应尽量使用各种形象、直观的图表工具。图表工具的种类很多，例如，用组织结构图描述企业的组织结构，用业务流程图描述业务状况，用数据流程图描述和分析数据、数据流程及各项功能，用判定树和决策表等描述处理功能和决策模型。

---

分析阶段

  系统分析师应该在进行调查的基础上，开展对现有系统进行分析的工作。在研究现有系统时千万不要“闭门造车”，应该多与用户进行沟通，了解他们对现有系统的认识和评价。分析阶段如下：

现有系统分析

  现有系统分析过程如图所示。

1. 获得现有系统的物理模型。现有系统可能是需要改进的某个已在计算机运行的系统，也可能是一个人工的数据处理过程。在这一步，系统分析师首先要分析、理解现有系统是如何运行的，了解现有系统的组织结构、输入/输出、资源利用情况和日常数据处理过程，并用一个具体模型来反映自己对现有系统的理解。物理模型用来描述系统“怎么做”的问题，应该客观地反映现有系统的实际情况。
2. 抽象出现有系统的逻辑模型。在理解现有系统“怎么做”的基础上，抽取其“做什么”的本质，从而从现有系统的物理模型抽象出新系统的逻辑模型。
3. 建立新系统的逻辑模型。分析新系统与现有系统逻辑上的差别，明确新系统到底要“做什么”，对现有系统的逻辑模型根据实际情况进行调整和优化，导出新系统的逻辑模型。
4. 建立新系统的物理模型。根据新系统的逻辑模型构建出相应的物理模型。这项工作属于系统设计阶段的任务。

组织结构分析

  组织结构是一个企业内部部门的划分及其相互之间的关系。 每个企业都有自己的组织结构图，它将企业分成若干部分，标明行政隶属关系。组织结构图是一种类树结构，树的分枝是根据上下级和行政隶属关系绘制的。

  组织结构分析就是对企业组织结构与职责进行分析，明确企业内部的部门划分，以及各部门之间的领导与被领导关系、信息传递关系、物质流动关系和资金流动关系，并了解各部门的工作内容与职责，包括业务程序和业务岗位等，其中岗位又包括工作名称、职责、权限、责任、薪资、级别，以及该岗位与其他各岗位的关系等。此外，还应详细了解各级部门存在的问题和对新系统的要求等。通过组织结构调查，系统分析师可以掌握企业组织结构的现状和存在的问题。

系统功能分析

  在掌握企业组织结构的基础上，以组织结构为线索，层层了解各个部门的职责、工作内容和内部分工，就可以掌握系统的功能体系，并用功能体系图来表示。功能体系图是一个完全以业务功能为主体的树形图，其目的在于描述企业内部各部门的业务和功能。

  确定了系统的所有功能后，还需要分析各功能之间的关系和流程，一般使用功能流程图来描述。功能流程图可以检验是否识别出所有的功能，判定系统分析师是否理解了系统功能，也是以后进行系统设计的基础。

业务流程分析

  业务流程分析的目的是了解各个业务流程的过程，明确各个部门之间的业务关系和每个业务处理的意义，为业务流程的合理化改造提供建议，为系统的数据流程变化提供依据。业务流程分析可以帮助系统分析师了解业务的具体处理过程，发现和处理系统调查工作中的错误和疏漏，修改和删除现有系统的不合理部分，在现有系统基础上优化业务处理流程。

业务流程分析方法

• 价值链分析法
  价值链分析法找出或设计出那些能够使顾客满意，实现顾客价值最大化的业务流程。价值链就是一个创造价值的工作流程，在这一总流程基础上有些业务流程特别重要，对形成企业核心竞争力起着关键作用，这样的业务流程称为基本业务流程，对应于价值链中的基本活动;其他业务流程是对企业的基本经营活动提供支持和服务，称为辅助业务流程，对应于价值链中的辅助活动。
• 客户关系分析法
  客户关系分析法就是把CRM用在业务流程的分析上。CRM的目标是建立真正以客户为导向的组织结构，以最佳的价值定位瞄准最具吸引力的客户，最大化地提高运营效率， 建立有效的合作伙伴关系。
• 供应链分析法
  供应链分析法是从企业供应链的角度分析企业的业务流程，它源于SCM。供应链是指用一个整体的网络用来传送产品和服务，从原材料开始一直到最终客户(消费者)，它凭借一个设计好的信息流、物流和资金流来完成。供应链分析法主要从企业内部供应链和外部供应链两个角度来分析企业的业务流程， 分析哪些流程处于供应链的核心环节。
• 基于ERP的分析法
  ERP的基本思想是将企业的业务流程看作是一个紧密联接的供应链，将供应商和企业内部的采购、生产、 销售，以及客户紧密联系起来，对供应链上的所有环节进行有效管理，实现对企业的动态控制和各种资源的集成和优化，从而提升企业基础管理水平，追求企业资源的合理、高效利用。
• 业务流程重组
  通过重新审视企业的价值链，从功能成本的比较分析中，确定企业在哪些环节具有比较优势。在此基础上， 以顾客满意为出发点进行价值链的分解与整合，改造原有的业务流程，实现业务流程的最优化。

业务流程建模

  业务流程建模可以采取两种方式，分别是自顶向下和的自底向上。自顶向下的方法从企业任务目标出发，根据流程上的价值链来确定最基本的流程，逐层分析业务目标直至底层。此过程涉及到将业务需求细化为系统需求，再将系统需求细化为功能。自底向上的方法分析现有系统，从已有业务流程活动及其联系出发，用于明确业务细节问题。
  描述业务流程模型最常见的方法是形式化描述和图示化描述。形式化描述方法的特点是精确、严谨，易于系统以后的实现，但难以掌握和理解，模型可读性差，往往只有专业人员才会使用，因此难以推广。常见的业务流程建模方法：

• 标杆瞄准
  标杆瞄准是一个连续、系统化地对外部领先企业进行评价的过程，通过分析和评价，确定出代表最佳实践的经营过程和工作过程，以便合理地确定本企业的业务流程。人们形象地把标杆瞄准法比喻为是一个合理、合法地“拷贝”优秀企业成功经验的过程。事实上，企业中的许多业务流程(例如，库存管理、供应商管理、客户管理、广告与雇佣等)在不同的行业中都是相似的，因此，运用标杆瞄准法对这些项目实施瞄准，尤其是在不同的行业对同一项目实施标杆瞄准时，对企业的参考价值可能更大。
• IDEF
  IDEF是一系列建模、分析和仿真方法的统称，从IDEF0到IDEF14(包括IDEF1X在内)共有16套方法，每套方法都是通过建模程序来获取某个特定类型的信息。它们分别是IDEF0(功能建 模)、IDEF1(信息建模)、IDEF1X(数据建模)、IDEF2(仿真建模设计)、IDEF3(过程描述获取)、IDEF4(面向对象设计)、 IDEF5(本体论描述获取)、IDEF6(设计原理获取)、IDEF7 (信息系统审计)、IDEF8(用户界面建模)、IDEF9(场景驱动信息系统设计)、IDEF10(实施架构建模)、IDEF11(信息制品建模)、IDEF12(组织建模)、IDEF13(三模式映射设计)和 IDEF14(网络规划)。
• DEMO
  DEMO 通过六种模型来描述信息系统的构成，包括交互模型、业务流程模型、事务模型、行为模型、事实模型和互约束模型。
• Petri
  Petri网作为一种从流程的角度出发描述和分析复杂系统的模型 工具，适用于多种系统的图形化、数学化建模工具，为描述和研究 具有并行、异步、分布式和随机性等特征的信息系统提供了强有力的手段。
• 业务流程建模语言
  主流的业务流程建模语言标准有BPEL(Business Process Execution Language，业务流程执行语言)、BPML(Business Process Modeling Language，业务流程建模语言)、BPMN (Business Process Modeling Notation，业务流程建模标注)、XPDL(XML Process Definition Language，XML流程定义语言)和UML五种，表现形式上来说，可以将它们划归为两大类，分别是文本类和图元类。
  
  • BPEL是一种使用XML编写，用于自动化业务流程的形式规约语言。用XML文 档写入BPEL中的流程，能在Web Service之间以标准化的交互方式得到精心组织，这些流程能够在任何一个符合BPEL规范的平台或产品上执行。通过允许用户在各种创作工具和执行平台之间移动这些流程，BPEL可以保护用户在流程自动化上的投资。
  • BPML与BPEL的设计理念非常相似，也用XML这种 结构化的方式对流程和流程执行的语义进行描述，在语法上也有循环和分支等控制结构，同时也是一种可执行的建模语言。
  • XPDL是WfMC(Workflow Management Coalition，工作流管理联盟)定义的一套流程建模标准，用来在支持BPM的各种工具和引擎间交换流程设计的定义。
  • 同为BPMI的标准之一，BPMN是BPML的有力补充。作为一 个图形化的流程建模语言，它能够弥补BPML等文本类建模语言在 图形表示上的先天不足。BPMN的用途更多在于其图形化的直观表示。
  • UML常被看作是系统建模和设计活动中的“瑞士军刀”，它所囊括的十多种图形化表示方案，可以用来捕获系统动态或静态的各个方面。但就业务流程管理领域而言，UML的作用不是很明显。在UML中，主要使用活动图来对业务流程进行建模。

数据分析

  数据与数据流程分析是以后建立数据库系统和设计功能模块处理过程的基础。在系统调查中，系统分析师收集了大量的数据载体(例如，报表、统计文件等)和数据调查表，这些原始资料基本上是按企业组织结构或业务流程收集的，它们往往只是局部反映了某项业务对数据的需求和现有的数据管理状况。对于这些数据资料必须加以汇总、整理和分析，理清它们之间的关系，为以后各子系统共享数据奠定基础。

• 数据汇总
  数据汇总是一项较为烦杂的工作，为使数据汇总能顺利进行，通常将它分为如下几个步骤:

  1. 将系统调查中所收集到的数据资料，按业务流程进行分类编码，按处理过程的顺序排放在一起。
  2. 按业务流程自顶向下地对数据项进行整理。例如，对于综合统计业务，应从最终统计报表开始，检查报表中每一栏数据的来源和算法，一直查到最终原始统计数据(例如，生产数据、财务数据和计划数据等)或原始财务数据(例如，单据和凭证等)为止。
  3. 将所有原始数据和最终输出数据分类整理出来。原始数据是进行数据库设计时确定基本表的主要内容，而最终输出数据则是反映业务所需要的主要指标。这两类数据对于后续工作来说是非常重要的，所以应该单独列出来。
  4. 确定数据的字长和精度。根据系统调查中用户对数据的满意程度，以及预计业务可能的发展规模，统一确定数据的类型、字长和精度。

• 数据属性分析
  数据的汇总只是从某项业务的角度对数据进行了分类整理，还不能确定所收集数据的具体形式和特征。因此，还需要对数据做进一步的分析。在信息系统中，经常用属性的名和属性的值来描述事物某些方面的特征。一个事物的特征可能表现在多个方面，需要用多个属性的名和其相应的值来描述。例如，对某客户来说，其属性名和对应的属性值有客户编号、客户名、客户所在地区、法人代表、银行账号等。数据的属性分析主要包括静态分析和动态分析。
  静态分析是指分析数据的静态特性，包括以下几个方面:

  1. 类型和长度。数据的类型通常有字符型、数值型、时间型、 多媒体类型等，长度包括占用空间的大小、整数位数和小数位数等， 这是建立数据库和分析处理所必须要求确定的内容。
  2. 取值范围。包括最大值、最小值等，这是数据输入、校对和审核所必须的。
  3. 发生的业务量。包括数据发生的频率、峰值数据量和峰值时间、存储和保留的时间周期等。
  4. 哪些业务使用这些数据。
  5. 重要程度和保密程度。重要程度决定系统设计时的输入、 校对、存储、复制、备份等功能，保密程度决定了网络设计和数据库设计时的措施，以及数据访问权限体系的设置。

  动态特性有三种，分别是固定值属性、固定个体变动属性和随机变动属性。

  1. 具有固定值属性的数据，其值一般不随时间而改变。例如，生产活动中的物料主数据、客户基础资料、会计科目等。
  2. 具有固定个体变动属性的数据项，对总体来说具有相对固定的个体集，但是对于个体来说其值是变动的。例如，销售管理中的订单数量，购买商品的客户名称基本上是固定的，但每个客户每次订购商品的数量都在变化。
  3. 具有随机变动属性的数据项，其个体是随机出现的，其值也是变动的。例如，销售管理系统中的产品月累计销售量，并非每月每个产品都有销售量，可能某个产品在某个月无销售量。

• 数据存储分布
  区分数据动态特性的目的是为了确定数据和数据库表(或文件)的关系，也就是确定哪些数据存储在哪种数据文件中。例如，一般将具有固定属性的数据存放在基本表(或主文件)中，将具有随机变动属性的数据存放在视图(或处理文件)中。不仅需要确定数据的存储文件，还需要确定数据在整个系统中的存储分布状况。例如，哪些数据存储在本地 设备上，哪些数据存储在网络服务器或系统主机上。

• 数据流程分析
  数据流程是指在系统中产生、传输、加工处理、使用、存储的过程，数据流程分析把数据在企业内部的流动情况抽象地独立出来，舍去了具体的企业组织结构、信息载体、物质、材料等，单从数据流动过程来考查实际业务的数据处理模式。目的是要发现和解决数据流通中的问题，例如，数据流程不畅、前后数据不匹配、数据处理过程不合理、输入输出不平衡等。导致出现这些问题的原因，有些是属于数据处理流程的问题，有些是属于现有系统管理混乱的问题。
  数据流程分析主要包括对数据的输入、输出、流动、传递、处理和存储的分析，具体包括以下四个方面:

  1. 收集现有系统的全部输入单据和报表、输出单据和报表，以及数据存储介质(例如，账本、清单等)的典型格式。
  2. 明确各个处理过程的处理方法和计算方法。
  3. 调查、确定上述各种单据、报表、账本、清单的制作单位、报送单位、存储单位、发生频率、发生的高峰时间和高峰量等。
  4. 注明各项数据的类型、长度、取值范围等。

---

需求规格说明书

  系统需求规格说明书也称为系统分析报告，或简称为系统说明书，它是系统分析阶段的技术文档，也是系统分析阶段的工作成果。根据国家标准GB/T 8567-2006，系统需求规格说明书可以分为九大部分，如下:

1. 引言。
2. 引用文件。
3. 需求。分条详述系统需求，包括功能、业务(包括接口、 资源、性能、可靠性、安全性和保密性等)和数据需求，也就是构成系统验收条件的系统特性。
4. 合格性规定。
5. 需求可追踪性。本部分需要说明每个子系统需求到其涉及的系统需求的双向可追踪性。
6. 非技术性需求。包括交付日期和里程碑的设置等。
7. 尚未解决的问题。
8. 注解。
9. 附录。

  系统需求规格说明书在整个系统开发中占有非常重要的地位，应该对其进行正式的评审，参加评审的人员有核心开发人员、企业领导、业务代表、系统分析师和外聘的专家等。在评审中，如果有关人员发现较大的差错或遗漏，或者对系统需求规格说明书中所提出的方案不满意，则需要返工，重新进行系统调查和分析，直到系统需求规格说明书通过为止。
  一旦通过评审，系统需求规格说明书将成为系统开发中的权威性文件，是系统设计阶段的主要依据。同时，系统需求规格说明书也是承建方与建设方之间的技术合同，是将来对系统进行验收的标准之一。