1. 系统分析与设计

1.1. 系统分析概述

• 系统分析是一种问题求解技术，它将一个系统分解成各个组成部分，目的是研究各个部分如何工作、交互，以实现其系统目标
• 目的和任务： 系统分析的主要任务是对现行系统进一步详细调查，将调查中所得的的文档资料集中，对组织内部整体管理状况和信息处理过程进行分析，为系统开发提供所需的资料，并提交系统方案说明书
• 系统分析的主要步骤：
  • 认识、理解当前的现实环境，获得当前系统的 “物理模型”
  • 从当前系统的 “物理模型” 抽象出当前系统的 “逻辑模型”
  • 对当前系统的 “逻辑模型” 进行分析和优化，建立目标系统的 “逻辑模型”
  • 对目标系统的逻辑模型具体化（物理化），建立目标系统的物理模型
• **系统开发的目的** 是将现有系统的物理模型转换为目标系统的物理模型

1.2. 系统设计

1.2.1. 系统设计的基本原理

• 系统设计基本原理：
  • 抽象 (重点说明本质方面，忽略非本质方面)
  • 模块化 (可组合、分解和更换的单元)
  • 信息隐藏 (将每个程序的成分隐藏或封装在一个单一的设计模块中)
  • 模块独立 (每个模块完成一个相对独立的特定子功能，且与其他模块之间的联系简单)
• 模块的设计要求高内聚、低耦合
  • 内聚 是指一个模块内部功能之间的相关性
  • 耦合 是指多个模块之间的联系

1.2.2. 内聚

内聚程度从低到高如下表所示：

内聚分类	定义	记忆关键字
偶然内聚	一个模块内的各处理元素之间没有任何联系	无直接关系
逻辑内聚	模块内执行若干个逻辑上相似的功能，通过参数确定该模块完成哪一个功能	逻辑相似、参数决定
时间内聚	把需要同时执行的动作组合在一起形成的模块	同时执行
过程内聚	一个模块完成多个任务，这些任务必须按指定的过程序执行	指定的过程顺序
通信内聚	模块内的所有处理元素都在同一个数据结构上操作，或者各者处理使用相同的输入数据或者产生相同的输出数据	相同数据结构、相同输入输出
顺序内聚	一个模块中的各个处理元素都密切相关于同一功能且必须顺序执行，前一个功能元素的输出就是下一个功能元素的输入	顺序执行、输入为输出
功能内聚	最强的内聚，模块内的所有元素共同作用完成一个功能，缺一不可	共同作用、缺一不可

1.2.3. 耦合

耦合程度从低到高如下表所示：

耦合分类	定义	记忆关键字
无直接耦合	两个模块之间没有直接的关系，它们分别从属于不同模块的控制与调用，不传递任何信息	无直接关系
数据耦合	两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言中的值传递	传递数据值调用
标记耦合	两个模块之间传递的是数据结构	传递数据结构
控制耦合	一个模块调用另一个模块时，传递的是控制变量，被调用模块通过该控制变量选择执行某一功能	控制变量、选择执行功能
外部耦合	模块间通过软件之外的环境联合（如 I/O 将模块耦合到特定的设备、格式、通信协议上）时	软件外部环境
公共耦合	通过一个公共数据环境相互作用的那些模块间的耦合	公共数据结构
内容耦合	当一个模块直接使用另一个模块的内部数据，或通过非正常入口转入另一个模块内部时	模块内部关联

1.2.4. 系统设计

• 在系统分析阶段，我们已经搞清楚了软件“做什么”的问题，并把这些需求通过规格说明书描述了出来，这也是目标系统的逻辑模型。进入设计阶段，要将软件“做什么”的逻辑模型转换成“怎么做”的物理模型
• 系统设计的主要目的是为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，得出新系统的详细设计方案
• 步骤：概要设计和详细设计
  • 概要设计基本任务：设计软件系统总体结构、数据结构及数据库设计、编写概要设计文档、评审
  • 详细设计的基本任务：模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计（代码、输入 / 输出格式、用户界面）、编写详细设计说明书、评审

1.3. 系统总体结构设计

• 系统结构设计原则：

  • 分解 —— 协调原则
  • 自顶向下原则
  • 信息隐藏和抽象原则
  • 一致性原则
  • 明确性原则

• 模块间高内聚低耦合

• 模块的扇入参数和扇出参数合理

• 模块规模适当

• 子系统划分的原则：

  • 子系统要具有相对独立性
  • 子系统之间数据的依赖性尽量小
  • 子系统划分的结果应使数据冗余较小
  • 子系统的设置应考虑今后管理发展的需要
  • 子系统的划分应便于系统分阶段实现
  • 子系统的划分应考虑到各类资源的充分利用

2. WebApp 分析与设计

2.1. WebApp 分析

WebApp 是基于 web 的系统和应用。大多数 WebApp 采用敏捷开发过程模型进行开发

WebApp 的特性：

• 网络密集性（服务于不同客户全体的需求）
• 并发性（大量用户同时访问）
• 无法预知的负载量（用户数量）
• 性能（响应时间过长导致用户流失）
• 可用性（最好 7X24X365 可用）
• 数据驱动（和用户的数据交互）

WebApp 五种需求模型：

• 内容模型：给出由 WebApp 提供的全部系列内容，包括文字、图形、图像、音频和视频。包含结构元素，为 WebApp 的内容需求提供了一个重要的视图。这些结构元素包含内容对象和所有分析类，在用户与 WebApp 交互时生成并操作用户可见的实体

  • 内容的开发可能发生在 WebApp 实现之前、构建之中、或者投入运行以后（全过程）

  • 内容对象：产品的文本描述、新闻文章、照片、视频等

  • 数据树：由多项内容对象和数据项组成的任何内容都可以生成数据树，是内容设计的基础，定义一种层级关系，并提供一种审核内容的方法，以便在开始设计前发现遗漏和不一致内容

• 交互模型：描述了用户与 WebApp 采用了哪种交互方式。由一种或多种元素构成，包括用例、顺序图、状态图、用户界面原型等

  • 用例是交互分析的主要工具，方便客户理解系统的功能

  • 顺序图是交互分析中描述用户与系统进行交互的方式。用户按照已定顺序使用系统，完成相应的功能，如登录流程

  • 状态图是交互分析中对系统进行动态的描述。如状态的变化

  • 用户界面原型展现用户界面布局、内容、主要导航链接、实施的交互机制及用户 WebApp 的整体美观度

• 功能模型：许多 WebApp 提供大量的计算和操作功能，这些功能与内容直接相关（既能使用又能生成内容，如统计报表）。这些功能常常以用户的交互活动为主要目标

  • 功能模型定义了将用于 webApp 内容并描述其他处理功能的操作，这些处理功能不依赖于内容却是最终用户所必需的

• 导航模型：为 WebApp 定义所有导航策略。考虑了每一类用户如何从一个 WebApp 元素（如内容对象）导航到另一个元素

• 配置模型：描述 WebApp 所在的环境和基础设施。在必需考虑复杂配置体系结构的情况下，可以使用UML 部署图

2.2. WebApp 设计

• 架构设计：使用多层架构来构造，包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器，以及可以包含 WebApp 的业务规则的内容或模型层，描述将以什么方式来管理用户交互、操作内部处理任务、实现导航及展示内容

  • MVC（模型 - 视图 - 控制器）结构是 WebApp 基础结构模型之一，将 WebApp 功能及信息内容分离

• 构件设计：

  • WebApp 构件：定义良好的聚合功能，为最终用户处理内容或提供计算或处理数据；内容和功能的聚合包，提供最终用户所需要的功能。因此，WebApp 构件设计通常包括内容设计元素和功能设计元素
  • 构件级内容设计：关注内容对象，以及包装后展示给最终用户的方式，应该适合创建的 WebApp 特性
  • 构件级功能设计：将 WebApp 作为一系列构件加以交付，这些构件与信息体系结构并行开发，以确保一致性

• 内容设计：着重于内容对象的表现和导航的组织，通常采用线性结构、网格结构、层次结构、网络结构四种结构及其组合

• 导航设计：定义导航路径，使用户可以访问 WebApp 的内容和功能

3. 软件需求

• 按需求内容分类：

  • 业务需求：由客户提出的宏观的一个功能需求
  • 用户需求：设计员去调查需求中涉及到的每个用户的具体需求
  • 系统需求：经过整合，形成最终的系统需求，包括功能、性能、设计约束三个方面的需求

• 从客户角度分类：

  • 基本需求：需求明确规定的功能
  • 期望需求：除了基本需求外，客户认为理所应当包含在内的其他功能
  • 兴奋需求：客户未要求的其他功能需求，会浪费项目开发时间和成本。

• 软件需求分类：

  • 功能需求：软件必须完成的基本动作

  • 性能需求：说明软件或人与软件交互的静态或动态数值需求，如系统响应速度、处理速度等

  • 设计约束：受其他标准硬件限制等方面的影响

  • 属性：可用性、安全性、可维护性、可转移 / 转移性

  • 外部接口需求：用户接口、硬件接口、软件接口、通信接口。

3.1. 需求工程

需求工程六个阶段：

• 需求获取：获取需求，方法有收集资料、联合讨论会 JRP、用户访谈、书面调查、现场观摩、参加业务实践、阅读历史文档、抽样调查

• 需求分析与协商：分析不同人提出的所有需求之间的关系并判断

• 系统建模：建立系统的抽象模型

• 需求规约：也即需求定义，目的是为了编写需求规约 (即需求规格说明书），在双方之间达成一个共识

• 需求验证：需求开发阶段的复查手段，需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线

• 需求管理：对需求工程涉及的所有过程进行规划和控制

3.2. 需求管理

• 定义需求基线：通过了评审的需求说明书就是需求基线，下次如果需要变更需求，就需要按照流程来一步步进行

• 处理需求变更：主要关心需求变更过程中的需求风险管理，带有风险的做法有：无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的 SRS、不准确的估算

• 需求跟踪：双向跟踪，两个层次，正向跟踪表示用户原始需求是否都实现了，反向跟踪表示软件实现的是否都是用户要求的，不多不少。如下图所示：

4. 结构化分析

结构化的分析方法SA，自顶向下，逐步分解，是面向数据的，强调分析对象的数据流，需要建立：功能模型（数据流图）、行为模型（状态转换图）、数据模型（E-R 图）以及数据字典（数据元素、数据结构、数据流、数据存储、加工逻辑、外部实体）

4.1. 数据流图

数据流图描述数据在系统中如何被传送或变换，以及如何对数据流进行变换的功能或子功能，用于对功能建模，数据流图相关概念如图：

数据流图是可以分层的，从顶层（即上下文无关数据流）到 0 层、1 层等，顶层数据流图只含有一个加工处理表示整个管理信息系统，描述了系统的输入和输出，以及和外部实体的数据交互。数据流图示例如下：

数据流图基本设计原则：

• 数据守恒原则：对任何一个加工来说，其所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者说是通过该加工能产生的数据

• 守恒加工原则：对同一个加工来说，输入与输出的名字必须不相同，即使它们的组成成分相同

• 对于每个加工，必须既有输入数据流，又有输出数据流

• 外部实体与外部实体之间不存在数据流

• 外部实体与数据存储之间不存在数据流

• 数据存储与数据存储之间不存在数据流

• 父图与子图的平衡原则：子图的输入输出数据流同父图相应加工的输入输出数据流必须一致，此即父图与子图的平衡。父图与子图之间的平衡原则不存在于单张图

• 数据流与加工有关，且必须经过加工

4.2. 数据字典

数据字典是用来定义在数据流图中出现的符号或者名称的含义，在数据流图中，每个存储、加工义都必须定义在数据字典中，并且父图和子图之间这些名称要相同。示例如下：

符号	含义	举例说明
=	被定义为
+	与	x = a + b, 表示 x 由 a 和 b 组成
[..., ...] 或 [...|...]	或	x = [a, b], x = [a|b], 表示 x 由 a 或者 b 组成
{...}	重复	x = {a}, 表示 x 由 0 个或多个 a 组成
(...)	可选	x = (a), 表示 a 可在 x 中出现，也可以不出现

5. 测试基础知识

系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试

测试原则：

• 应尽早并不断的进行测试

• 测试工作应该避免由原开发软件的人或小组承担

• 在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期的输出结果

• 既包含有效、合理的测试用例，也包含不合理、失效的用例

• 检验程序是否做了该做的事，且是否做了不该做的事

• 严格按照测试计划进行

• 妥善保存测试计划和测试用例

• 测试用例可以重复使用或追加测试

5.1. 测试阶段

单元测试：对单个模块进行测试，由程序员自己测试模块内部的接口、信息、功能，测试依据是软件详细说明书。在单元测试中，驱动模块（上层）用来调用被测模块，自顶向下的单元测试中不需要另外编写驱动模块。桩模块（底层）用来模拟被测模块所调用的子模块

集成测试：将模块组合起来进行测试，分为一次性组装（简单，节约时间，发现错误少，只适合于小项目）和增量式组装（能够发现更多错误，耗时长，又可分为：自顶向下、自底向上、混合式）

确认测试：对已完成的软件进行功能上的测试，分为内部确认测试（无用户情况）Alpha 测试（用户在开发环境下进行测试）、Beta 测试（用户在实际使用时进行的测试）、验收测试（用户根据 SRS 对项目进行验收)

系统测试：对软件进行性能测试，主要测试三个方面，即负载测试（在极限情况下，系统各项性能指标）、强度测试（系统资源特别低的情况下）、容量测试（并发测试，系统可以处理的同时在线的最大用户数量）。其他还有可靠性等性能测试，系统测试采用的是黑盒测试方法

回归测试：软件修改错误或变更后，进行回归测试以验证之前正确的代码是否引入

5.2. 测试方法

动态测试：程序运行时测试，分为：

黑盒测试法：功能性测试，不了解软件代码结构，根据功能设计用例，测试软件功能

白盒测试法：结构性测试，明确代码流程，根据代码逻辑设计用例，进行用例覆盖

灰盒测试法：即既有黑盒，也有白盒

静态测试：程序静止时，即对代码进行人工审查，分为：

桌前检查：程序员检查自己编写的程序，在程序编译后，单元测试前

代码审查：由若干个程序员和测试人员组成评审小组，通过召开程序评审会来进行审查

代码走查：也是采用开会来对代码进行审查，但并非简单的检查代码，而是由测试人员提供测试用例，

让程序员扮演计算机的角色，手动运行测试用例，检查代码逻辑

5.3. 测试策略

自底向上：从最底层模块开始测试，需要编写驱动程序，而后开始逐一合并模块，最终完成整个系统的测

试。优点是较早的验证了底层模块

自顶向下：先测试整个系统，需要编写桩程序，而后逐步向下直至最后测试最底层模块。优点是较早的验证

了系统的主要控制和判断点

三明治：既有自底向上也有自顶向下的测试方法，二者都包括。兼有二者的优点，缺点是测试工作量大

5.4. 测试用例设计

黑盒测试用例：将程序看做一个黑盒子，只知道输入输出，不知道内部代码，由此设计出测试用例，分为下

面几类：

等价类划分：把所有的数据按照某种特性进行归类，而后在每类的数据里选取一个即可。等价类测试

用例的设计原则：设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一

步，直到所有的有效等价类都被覆盖为止；计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等

价类，重复这一步，直到所有的无效等价类都被覆盖为止

边界值划分：将每类的边界值作为测试用例，边界值一般为范围的两端值以及在此范围之外的与此范围

间隔最小的两个值，如年龄范围为 0-150，边界值为 0，150，-1，151 四个。

错误推测：没有固定的方法，凭经验而言，来推测有可能产生问题的地方作为测试用例进行测试

因果图：由一个结果来反推原因的方法，具体结果具体分析，没有固定方法

白盒测试用例：知道程序的代码逻辑，按照程序的代码语句，来设计覆盖代码分支的测试用例，覆盖级别从

低至高分为下面六种：

语句覆盖：逻辑代码中的所有语句都要被执行一遍，覆盖层级最低，因为执行了所有的语句，不代表执

行了所有的条件判断

判定覆盖：逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次

条件覆盖：对于代码中的一个条件，可能是组合的，如 a>0 && b<0 ，判断覆盖只针对此组合条件的

真假分支做两个测试用例，而条件覆盖是对每个独立的条件都要做真假分支的测试用例，共可有 4 个测

试用例，层级更高，注意区别，条件覆盖，针对每个条件都要真假覆盖，判定覆盖，只针对一个条件判

断语句

判定 / 条件覆盖：使判定中每个条件的所有可能取值（真 / 假）至少出现一次，并且每个判定本身的判

定结果（真 / 假）也至少出现一次，即两种覆盖的综合

No. 78 / 131 条件组合覆盖：每个判定条件中条件的各种可能值的组合都至少出现一次

路径覆盖：逻辑代码中的所有可行路径都覆盖了，覆盖层级最高

5.5. 调试

测试是发现错误，调试是找出错误的代码和原因

调试需要确定错误的准确位置；确定问题的原因并设法改正；改正后要进行回归测试

调试的方法有：

蛮力法

回溯法（从出错的地方开始，向回找）

原因排除法（找出所有可能的原因，逐一进行排除，具体包括演绎法、归纳法、二分法）

6. 系统转换

系统转换是指新系统开发完毕，投入运行，取代现有系统的过程，需要考虑多方面的问题，以实现与老系统

的交接，有以下三种转换计划：

直接转换：现有系统被新系统直接取代了，风险很大，适用于新系统不复杂，或者现有系统己经不能使用

的情况。优点是节省成本。

并行转换：新系统和老系统并行工作一段时间，新系统经过试运行后再取代，若新系统在试运行过程中

有问题，也不影响现有系统的运行，风险极小，在试运行过程中还可以比较新老系统的性能，适用于大

型系统。缺点是耗费人力和时间资源，难以控制两个系统间的数据转换。

分段转换：分期分批逐步转换，是直接和并行转换的集合，将大型系统分为多个子系统，依次试运行每

个子系统，成熟一个子系统，就转换一个子系统。同样适用于大型项目，只是更耗时，而且现有系统和

新系统间混合使用，需要协调好接口等问题

数据转换与迁移：将数据从旧数据库迁移到新数据库中。要在新系统中尽可能的保存归系统中合理的数据结

构，才能降低迁移的难度。也有三种方法：

系统切换前通过工具迁移

系统切换前采用手工录入

系统切换后通过新系统生成

转换的过程称为 ETL，有三个步骤：

抽取（旧数据库数据）

转换（三种转换方法）

装载（装入新数据库，并校验数据）

7. 系统维护

软件维护是软件生命周期中的最后一个阶段，不属于系统开发过程。是在软件已经交付使用之后为了改正错

误或满足新的需求而修改软件的过程，即软件在交付使用后对软件所做的一切改动

系统的可维护性可以定义为维护人员理解、改正、改动和改进这个软件的难易程度，其评价指标如下：

No. 79 / 131 易测试性：指为确认经修改软件所需努力有关的软件属性

易分析性：指为诊断缺陷或失效原因，或为判定待修改的部分所需努力有关的软件属性

易改变性：指与进行修改、排错或适应环境变换所需努力有关的软件属性

稳定性：指与修改造成未预料效果的风险有关的软件属性

系统维护包括硬件维护、软件维护和数据维护，其中软件维护类型如下：

正确性维护：发现了 bug 而进行的修改

适应性维护：由于外部环境发生了改变，被动进行的对软件的修改和升级

完善性维护：基于用户主动对软件提出更多的需求，修改软件，增加更多的功能，使其比之前的软件功

能、性能更高，更加完善

预防性维护：对未来可能发生的 bug 进行预防性的修改

8. 系统评价

系统评价分类：

立项评价：系统开发前的预评价，分析是否立项开发，做可行性评价

中期评价：项目开发中期每个阶段的阶段评审。或者项目在开发中途遇到重大变故，评价是否还要继续

结项评价：系统投入正式运行后，了解系统是否达到预期的目的和要求而对系统进行的综合评价

系统评价指标：

从信息系统的组成部分出发，信息系统是一个由人机共同组成的系统，所以可以按照运行效果和用户需

求〈人)、系统质量和技术条件（机）这两条线索构造指标

从信息系统的评价对象出发，对于开发方来说，他们所关心的是系统质量和技术水平；对于用户方而言，

关心的是用户需求和运行质量；系统外部环境则主要通过社会效益指标来反映

从经济学角度出发，分别按系统成本、系统效益和财务指标 3 条线索建立指标