⇧
❮
❯
↻
🍀系统架构设计🍀 14878字 75分钟

系统架构核心知识（2b）：软件工程（系统设计、测试、运维、项目管理）

作者

软件工程内容极多，故于2026年7月26日将后半部分内容（系统设计、测试、运维、项目管理等）拆至本文。今后在各文下都会更新内容。

Hyplus目录

5 系统设计 ⭐️⭐️☀️

系统设计是软件开发的重要阶段。软件设计包括体系结构设计、接口设计、数据设计和过程设计：

  1. 架构设计：定义软件系统各主要部件之间的关系。
  2. 数据设计：将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程复杂性。
  3. 接口设计（人机界面设计）：软件内部，软件和操作系统之间以及软件和人之间如何通信。
  4. 过程设计：系统结构部件转换成软件的过程描述。确定软件各个组成部分内的算法及内部数据结构，并选定某种过程的表达形式来描述各种算法。

各开发阶段所使用的图：

  1. 需求分析阶段：数据流图
  2. 概要设计阶段：模块结构图、层次图、HIPO图——层次图+IPO图（Input-Process-Output）
  3. 详细设计阶段：程序流程图、伪代码、盒图

5.1 人机界面设计

人机界⾯（Human-Machine Interface，HMI）设计是指⽤户与系统之间架起⼀座桥梁，主要内容包括：定义界⾯形式、定义基本的交互控制形成、定义图形和符号、定义通⽤的功能键和组合键的含义及其操作内容、定义帮助策略等。

黄金三法则：

  1. 置于用户控制之下
    • 以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
    • 提供灵活的交互
    • 允许用户交互可以被中断和撤销
    • 当技能级别增加时可以使交互流水化并允许定制交互
    • 使用户隔离内部技术细节
    • 设计应允许用户和出现在屏幕上的对象直接交互
  2. 减少用户的记忆负担
    • 减少对短期记忆的要求
    • 建立有意义的缺省
    • 定义直觉性的捷径
    • 界面的视觉布局应该基于真实世界的隐喻
    • 以不断进展的方式揭示信息
  3. 保持界面的一致性
    • 允许用户将当前任务放入有意义的语境
    • 在应用系列内保持一致性
    • 如过去的交互模型已建立起了用户期望，除非有迫不得已的理由，不要改变它

注：原则上不提倡使用创新的模式吸引用户的眼球！

5.2 结构化设计（SD）

结构化设计（Structured Design，SD）是一种面向数据流的设计方法，目的在于确定软件的结构。

结构化设计的2种设计分类（亦为系统设计的常见设计）：

  1. 概要设计【外部设计】：将软件需求转化为数据结构和软件系统结构——设计各个部分的功能、接口、相互如何关联。功能需求分配给软件模块，确定每个模块的功能和调⽤关系，形成模块结构图。（完成了架构设计的职能）
  2. 详细设计【内部设计】：过程设计，通过对结构细化，得到软件详细数据结构和算法——设计具体模块的实现。为每个具体任务选择适当的技术⼿段和处理⽅法。

5.2.1 结构化设计原则

结构化设计的原则：

  • 模块独⽴性原则（⾼内聚、低耦合）
  • 保持模块的⼤⼩适中
  • 多扇⼊，少扇出
  • 深度和宽度均不宜过⾼

扇入与扇出的定义如图所示：
扇入扇出

模块独⽴性的度量：内聚、耦合

5.2.2 内聚与耦合

内聚（Cohesion）：衡量模块内部各元素结合的紧密程度，结构化设计的目标为高内聚。如表所示，从上到下为高内聚到低内聚：

内聚类型 描述
高 功能内聚 完成⼀个单⼀功能，各个部分协同⼯作，缺⼀不可。
顺序内聚 处理元素相关，⽽且必须顺序执⾏
通信内聚 所有处理元素集中在⼀个数据结构的区域上
（UC矩阵）
过程内聚 处理元素相关，⽽且必须按特定的次序执⾏
（与顺序内聚唯一区别为不强调时间顺序，不“必须”）
时间内聚
（瞬时内聚）		 所包含的任务必须在同⼀时间间隔内执⾏
（在上述内聚的基础上，进一步未规定该时间间隔内具体顺序）
逻辑内聚 完成逻辑上相关的⼀组任务
（不需要明确规定逻辑）
低 偶然内聚
（巧合内聚）		 完成⼀组没有关系或松散关系的任务

耦合（Coupling）：度量不同模块间互相依赖的程度，结构化设计的目标为低耦合。如表所示，从上到下为低耦合到高耦合：

耦合类型 描述
低 ⾮直接耦合 两个模块之间没有直接关系，其之间的联系完全通过主模块的控制和调⽤来实现
（通过第三方实现联系）
数据耦合 ⼀组模块借助参数表传递简单数据参数
（非控制参数、公共数据结构或外部变量）
标记耦合 ⼀组模块通过参数表传递记录信息（数据结构）
控制耦合 模块之间传递的信息中包含⽤于控制模块内部逻辑的信息
（例如控制分支的条件）
外部耦合 ⼀组模块都访问同⼀全局简单变量，且不通过参数表传递该全局变量的信息
公共耦合 多个模块都访问同⼀个公共数据环境
高 内容耦合 ⼀个模块直接访问另⼀个模块的内部数据
⼀个模块不通过正常⼊⼝转到另⼀个模块的内部
两个模块有⼀部分程序代码重叠
⼀个模块有多个⼊⼝

6.2.3 模块的四个要素

结构化设计中模块的4个要素：

  1. 输入和输出：模块的输入来源和输出去向都是同一个调用者，即一个模块从调用者那儿取得输入，进行加工后再把输出返回调用者。
  2. 处理功能：模块把输入转换成输出所做的工作。
  3. 内部数据：仅供该模块本身引用的数据。
  4. 程序代码：用来实现模块功能的程序。

模块的接口是模块与其他模块进行交互的部分，所以接口的定义不仅仅属于其模块自身的内部特性，与外部模块也具有相关性。

5.3 ⾯向对象设计（OOD）

面向对象设计（Object-Oriented Design，OOD）是面向对象程序设计（OOP）在软件设计阶段的应用，旨在通过定义和设计对象及其关系来构建软件系统，强调定义软件对象，并使这些对象互相协作来满足用户需求。

面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；设计模型包含以包图表示的软件体系结构图，以交互图表示的用例实现图，完整精确的类图，针对复杂对象的状态图和用以描述流程化处理的活动图等。

注意联系OOA中UML图部分。

基本过程：分析模型 -> 设计模型

⾯向对象设计

5.3.1 设计模式 ⭐️⭐️⭐️

设计模式（Design Pattern）是一套可以被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解并且提高代码的可靠性。设计模式着眼于解决某一特定的局部问题，是一种局部解决方案的应用。

【例】Java内存管理中的垃圾回收机制。

注：新考纲中，案例分析题已不再考察设计模式

根据目的分类，可分为以下3大类设计模式——

创建型模式：主要用于创建对象，为设计类实例化新对象提供指南。

  1. 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
  2. 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
  3. 工厂方法（Factory Method）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
  4. 抽象工厂（Abstract Factory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
  5. 建造者（Builder） 模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。

结构型模式：主要用于处理类或对象的组合，对类如何设计以形成更大的结构提供指南。

  1. 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
  2. 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
    • 解决方案：增加一个类作为适配器，转换类的接口到客户端类期望的另一个接口。实现一个适配器类，这个类为系统的其他部分提供了一个不变的方法供调用，为了集成不同商品供应商提供的税率计算类，编写一个适配器类的子类，包含调用购买类所需的代码。该子类将系统的调用映射到某个供应商的税率计算类。如果要更换供应商，那么只需要写一个新的适配器子类，其他保持不变。
  3. 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
  4. 装饰（Decorator）模式：动态地给对象增加一些职责，即增加其额外的功能。
  5. 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
  6. 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
  7. 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。

行为型模式：主要用于描述类或对象的交互以及职责的分配，对类之间交互以及分配责任的方式提供指南。

  1. 模板方法（Template Method）模式：定义一个操作中的算法骨架，将算法的一些步骤延迟到子类中，使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
  2. 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
    • 解决方案：在具有公共接口的独立类中定义每个计算。可以利用该模式创建各种促销类，它们从同一个超类继承。每个类都有相同名称的标准接口方法，用于根据订单编号计算将要折扣的金额总数。
  3. 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
  4. 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
  5. 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。
  6. 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行。
  7. 中介者（Mediator） 模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
  8. 迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
  9. 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
  10. 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
  11. 解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

根据作用范围分类，可分为类模式和对象模式：

  • 类模式：用于处理类和子类的关系，这种关系通过继承建立，在编译时就确定了，是一种静态关系。
  • 对象模式：处理对象间的关系，具有动态关系。

5.3.2 类的分类

  1. 边界类：API接口（机器接口）、用户界面（人机交互）
    • 例：显示屏、窗体、打印机接口、通信协议、对话框、菜单、购物车、报表、二维码
  2. 控制类：应用逻辑、业务逻辑、数据访问逻辑（均为解决逻辑）
    • 例：身份验证器
  3. 实体类：数据
    • 例：学员类、课程类

对象间的关系：组合，聚合，继承等

5.3.3 面向对象设计原则

面向对象设计的七大设计原则：

  1. 单⼀职责原则：设计⽬的单⼀的类。
  2. 开放-封闭原则：对扩展开放，对修改封闭。
  3. 里⽒替换原则（Liskov Substitution Principle，LSP）：⼦类可以替换⽗类。
    • 基本思想：一个软件实体如果使用的是一个基类对象，那么一定适用于其子类对象，而且觉察不出基类对象和子类对象的区别，即把基类都替换成它的子类，程序的行为没有变化。反过来则不一定成立，如果一个软件实体使用的是一个子类对象，那么它不一定适用于基类对象。
    • 在运用里氏替换原则时，尽量将一些需要扩展的类或者存在变化的类设计为抽象类或者接口，并将其作为基类，在程序中尽量使用基类对象进行编程。由于子类继承基类并实现其中的方法，程序运行时，子类对象可以替换基类对象，如果需要对类的行为进行修改，可以扩展基类，增加新的子类，而无需修改调用该基类对象的代码。
  4. 依赖倒置原则：要依赖于抽象，⽽不是具体实现；针对接⼝编程，不要针对实现编程。
  5. 接⼝隔离原则：使⽤多个专⻔的接⼝⽐使⽤单⼀的总接⼝要好。
  6. 组合重⽤原则：要尽量使⽤组合，⽽不是继承关系达到重⽤⽬的。
  7. 迪⽶特（Demeter）原则（最少知识法则）：⼀个对象应当对其他对象有尽可能少的了解。

5.4 软件系统建模 ⭐️

软件系统建模（Software System Modeling）可以与逆向工程、需求分析、软件设计等方面相联系。

软件系统建模

【例】论软件系统建模方法及其应用

软件系统建模（Software System Modeling）是软件开发中的重要环节，通过构建软件系统模型可以帮助系统开发人员理解系统、抽取业务过程和管理系统的复杂性，也可以方便各类人员之间的交流。软件系统建模是在系统需求分析和系统实现之间架起的一座桥梁，系统开发人员按照软件系统模型开发出符合设计目标的软件系统，并基于该模型进行软件的维护和改进。

请围绕“论软件系统建模方法及其应用”论题，依次从以下三个方面进行论述。

  1. 概要叙述你参与的软件系统开发项目以及你所担任的主要工作。
  2. 说明软件系统开发中常用的建模方法有哪几类？阐述每种方法的特点及其适用范围。
  3. 详细说明你所参与的软件系统开发项目中，采用了哪些软件系统建模方法，具体实施效果如何。

【答】

  1. 结构化建模⽅法：以过程为中⼼的技术，可⽤于分析⼀个现有的系统以及定义新系统的业务需求。结构化建模⽅法所绘制的模型称为数据流图（DFD）。对于流程较为稳定的系统可考虑结构化建模⽅法。
  2. 信息⼯程建模⽅法（或数据库建模⽅法）：⼀种以数据为中⼼，但过程敏感的技术，它强调在分析和研究过程需求之前，⾸先研究和分析数据需求。信息⼯程建模⽅法所创建的模型被称为实体-联系图（ERD）。主要⽤于数据建模。
  3. ⾯向对象建模⽅法：将“数据”和“过程” 集成到被称为“对象”的结构中，消除了数据和过程的⼈为分离现象。⾯向对象建模⽅法所创建的模型被称为对象模型。随着⾯向对象技术的不断发展和应⽤，形成了⾯向对象的建模标准，即UML（统⼀建模语⾔）。UML定义了⼏种不同类型的模型图，这些模型图以对象的形式共建⼀个信息系统或应⽤系统。⽬前⽐较常⽤的建模⽅法。

5.5 业务流程设计

总结+拓展

业务流程设计中，业务流程建模方法主要有：

  1. 流程图（Flow Chart）：最早用于业务流程的一种图形化描述方法，易学易理解，但存在无法清楚界定流程界限、不支持层次化描述业务流程等问题。
  2. 角色活动图（Role Activity Diagram，RAD）、角色交互图（Role Interaction Diagram，RID）：擅长描述角色与活动、角色与角色的交互关系，但不支持层次化描述业务流程。
  3. IDEF0、IDEF3：IDEFO描述业务流程做什么，但不指明谁做；IDEF3回答怎么做，但描
    述复杂业务流程难度大。
  4. 高级Petri网：具有较强的数学基础，可以计算/仿真分析业务流程性能，但用户的学习难度大
  5. UML（统一建模语言）：活动图易学习和使用，但模型的仿真和分析能力差；
  6. BPMN（Business Process Modeling Notation，业务流程建模标注）：一种以业务流程图的形式表示业务流程的图形方法，可以用其定义的一系列业务组件，组成业务流程图。

程序图的环路数是源代码复杂程度的度量，环路复杂度（Cyclomatic Complexity）是一种代码复杂度的衡量标准，目标是为了指导程序员写出更具可测性和可维护性的代码。可以用McCabe度量法来衡量一个模块判定结构的复杂程度（McCabe复杂度），计算公式为：V(G) = e - n + 2，其中e为在控制流图中的边的数量，n为在控制流图中的节点数量，包括起点和终点。

6 软件测试 ⭐️⭐️

软件测试（Software Test）不可以证明被测对象的正确性。软件测试的目标是发现软件中的错误和缺陷，而不是证明软件是正确的。

测试只能提供有限的覆盖范围和可靠性。即便通过了所有测试用例，软件也可能存在其他未被发现的错误。因此，测试只是尽可能地减少风险，而不能完全保证软件的正确性。

在软件测试中，优先测试那些最重要或最频繁使用的功能，80%的软件错误都可以在大概20%的模块中找到根源。

6.1 软件测试分类

设计测试用例即针对特定功能或组合功能设计测试方案，并编写成文档。测试用例的选择既要有一般情况，也应有极限情况以及最大和最小的边界值情况。因为测试的目的是暴露应用软件中隐藏的缺陷，所以在设计选取测试用例和数据时要考虑那些易于发现缺陷的测试用例和数据，结合复杂的运行环境，在所有可能的输入条件和输出条件中确定测试数据，来检查应用软件是否都能产生正确的输出。

一个典型的测试用例应包含以下组成部分：

  1. 测试用例标识
  2. 被测对象
  3. 测试环境及条件
  4. 测试输入
  5. 操作步骤
  6. 预期输出
  7. 判断输出结果是否符合标准
  8. 测试对象的特殊需求

6.1.1 动态测试与静态测试

软件测试⽅法总体上可以分为动态、静态两大类，如下所示：

  • 动态测试：计算机运行
    • 白盒测试
    • 黑盒测试
    • 灰盒测试（结合了⿊盒与⽩盒测试）
  • 静态测试：人工监测和计算机辅助分析（并非直接跑源码）
    • 桌前检查：自己看代码
    • 代码审查：交叉进行
    • 代码走查：人工执行代码（阅读，“脑补”结果）

静态测试都是做的【静态分析】，包括如下几个阶段：

  • 控制流分析：是否存在没有使⽤的语句/⽆法达到的语句/调⽤并不存在的⼦程序。
  • 数据流分析（数据使用分析）：突出程序中变量的使用情况，引⽤未定义的变量、对以前未使⽤的变量再次赋值。
  • 接⼝分析：检查模块之间接⼝的⼀致性、⼦程序和函数之间的接⼝⼀致性、函数形参与实参的数量、顺序、类型的⼀致性。
  • 信息流分析：找出输入变量和输出变量之间的依赖关系（I/O）
  • 路径分析：找出程序中所有可能的路径并画在此路径中执行的语句
  • 表达式分析：括号不配对、数组引⽤越界、除数为零。

6.1.2 ⽩盒测试与黑盒测试

⽩盒测试与黑盒测试均属于动态测试

⽩盒测试【结构测试】（White-box Test）：主要用于单元测试阶段，关注内部结构与逻辑。常用方法——

  • 控制流测试：逻辑覆盖测试，各种覆盖标准由弱到强（此处越“强”指测试用例数越多）依次为
    1. 语句覆盖：选择足够多的测试用例，使得运行这些测试用例时，被测程序的每个语句至少被执行一次。（最弱）
    2. 判定覆盖：不仅每个语句至少执行一次，而且每个判定的每种可能结果（分支）都至少执行一次，故又称分支覆盖。（对程序逻辑的覆盖程度仍不高）
    3. 条件覆盖：不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取得各种可能的结果。（不一定包含判定覆盖）
    4. 判定/条件覆盖：选取足够的测试用例，使得判定表达式中每个条件的所有可能结果至少出现一次，而且每个判定本身的所有可能结果也至少出现一次。（同时满足判定覆盖与条件覆盖）
    5. 条件组合覆盖：选取足够的测试用例，使得每个判定表达式中条件结果的所有可能组合至少出现一次。（一定覆盖判定/条件覆盖；仍无法保证程序中所有可能的路径都至少经过一次）
    6. 路径覆盖：选取足够的测试用例，使得程序的每条可能执行到的路径都至少经过一次（若程序中有环路，则要求每条环路路径至少经过一次）。（实际上考虑了程序中各种判定结果的所有可能组合，因此覆盖能力相对最强；但未考虑判定中的条件结果的组合，故并不能完全代替条件覆盖和条件组合覆盖）
  • 数据流测试
  • 程序变异测试【错误驱动测试】

白盒测试

⿊盒测试【功能测试】（Black-box Test）：主要用于集成测试、确认测试和系统测试阶段，关注输⼊输出及功能。常用方法（经常多种混合使用）：

  1. 等价类划分：不同等价类，揭示不同问题；有效等价类/⽆效等价类
  2. 边界值分析：若1 <= x <= 10，则可取x的值为0、1、10和11作为测试数据。
  3. 错误推测：依靠测试⼈员的经验和直觉。
  4. 判定表：最适合描述在多个逻辑条件取值的组合所构成的复杂情况下，分别要执⾏哪些不同的动作。
  5. 因果图：根据输⼊条件与输出结果之间的因果关系来设计测试⽤例。

黑盒测试

6.2 软件测试阶段

在V模型中，软件测试贯穿项⽬始终，存在如下几个主要测试阶段：

  1. 单元测试：依据软件【详细设计】，模块测试，模块功能、性能、接⼝等。
  2. 集成测试：依据软件【概要设计】，模块间的接⼝。
  3. 系统测试：依据软件【需求⽂档】，在真实环境下，验证完整的软件配置项能否和系统正确连接。（需配置完整的软硬件环境条件）
  4. 确认测试（合格性测试）：依据软件【需求⽂档】，验证软件与需求的⼀致性。分为以下四类：
    1. 内部确认测试
    2. α测试：在开发环境下进行的测试，由用户/内部用户模拟实际操作环境下进行的受控测试。
    3. β测试：用户在实际使用环境下进行的测试。
    4. 验收测试：确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务，向未来的用户表明系统能够像预定要求那样工作。

其他特殊测试：

  • 回归测试：对变更部分的测试，即软件变更之后变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其它规定的要求的不损害性。

集成测试常使用如下两种方法：

  1. 一次性组装：风险高
  2. 增量式组装：测试全面
    • 自顶向下：需要桩模块
    • 自底向上：需要驱动模块
    • 混合式：桩模块和驱动模块都需要

集成测试策略

其中，桩模块、驱动模块的作用均为填充下一步操作对应的暂未组装入的模块。例如自顶向下时，被测模块需要调用子模块，但其暂未组装入，因此用桩模块填充此位。自底向上时的驱动模块（改为被父模块调用）、混合式时均使用，与之同理。

由于桩模块、驱动模块均是围绕单一被测模块所定义，且集成测试常紧跟在单元测试之后，因此在实际工作中单元测试也常使用上述测试策略。

6.3 系统测试

系统测试的依据是软件需求规格说明书（即需求文档，见前述）。系统测试采用黑盒测试，以此来检查该系统是否符合软件需求。可分为如下几类：

  • 功能测试
  • 性能测试
    1. 负载测试：各种工作负载下系统的性能
    2. 压力测试【测上限】：系统的瓶颈或不能接受的性能点
      • 负载测试和压力测试可以结合进行，统称为负载压力测试
    3. 强度测试【测下限】：系统资源特别低/超负荷的情况下运行（系统受限的情况）
    4. 容量测试【并发测试】：同时在线的最大用户数
    5. 可靠性测试：正确运行的概率（详见系统可靠性分析与设计）
    6. 恢复测试：容错能力
  • 健壮性测试
  • 用户界面测试
  • 安全性测试
  • 安装与反安装测试

6.4 自动化测试

拓展

⾃动化测试（Automated Testing）指的是软件测试的⾃动化，即在预先设定的条件下⾃动运⾏被测程序，并分析运⾏结果。该测试⽅法即为将以⼈驱动的测试⾏为转化为机器执⾏的⼀种过程。

不适合场景：项⽬周期短，需求变动频繁

常⻅⾃动化测试：单元⾃动化测试、接⼝⾃动化测试、UI⾃动化测试

自动化测试工具主要使用脚本（Script）技术来生成测试用例，测试脚本不仅可以在功能测试上模拟用户的操作，比较分析，而且可以用在性能测试、负载测试上。虚拟用户可以同时进行相同的、不同的操作，给被测软件施加足够的数据和操作，检查系统的响应速度和数据吞吐能力。

常见的测试脚本：

  1. 线性脚本：录制手工执行的测试用例得到的脚本，这种脚本包含所有的击键、移动、输入数据等，所有录制的测试用例都可以得到完整的回放。
  2. 结构化脚本：类似于结构化程序设计，具有各种逻辑结构、函数调用功能。
  3. 共享脚本：可以被多个测试用例使用的脚本，也允许其他脚本调用。共享脚本可以在不同主机、不同系统之间共享，也可以在同一主机、同一系统之间共享。
  4. 数据驱动脚本：将测试输入存储在独立的（数据）文件中，而不是存储在脚本中。可以针对不同数据输入实现多个测试用例。
  5. 关键字驱动脚本：数据驱动脚本的逻辑扩展，将数据文件变成测试用例的描述，采用一些关键字指定要执行的任务。

7 系统运⾏与软件维护 ⭐️

7.1 系统转换计划

7.1.1 遗留系统演化策略

在处理遗留系统时，应综合考虑其业务价值与技术水平。有如下几种策略（按象限顺序）：

  1. 改造策略：遗留系统具有较⾼的业务价值，基本上能够满⾜企业业务运作和决策⽀持的需要。这种系统可能建成的时间还很短，对这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改造两个⽅⾯。系统功能的增强是指在原有系统的基础上增加新的应⽤要求，对遗留系统本身不做改变；数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。（直接拿来）
  2. 集成策略：遗留系统的技术含量较⾼，但其业务价值较低，可能只能完成某个部⻔或⼦公司的业务管理。这种系统在各⾃的局部领域⾥⼯作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台、不同的数据模型，形成了⼀个个信息孤岛，对这种遗留系统的演化策略为集成。（打通信息孤岛即可）
  3. 淘汰策略：遗留系统的技术含量较低，且具有较低的业务价值。对遗留系统的完全淘汰是企业资源的根本浪费，应善于“变废为宝”，通过对遗留系统功能的理解和借鉴，可以帮助新系统的设计，降低新系统开发的⻛险。
  4. 继承策略：遗留系统的技术含量较低，已经满⾜企业运作的功能或性能要求，且具有较⾼的商业价值，⽬前企业的业务尚紧密依赖该系统。对这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新⽼系统必须并⾏运⾏⼀段时间，再逐渐切换到新系统上运⾏。（仅需技术维度升级，业务需求无变化）

遗留系统演化策略

7.1.2 新旧系统转换策略

常见的新旧系统转换策略有如下3种：

  1. 直接转换：在原有系统停⽌运⾏的某⼀时刻，新系统⽴即投⼊运⾏，中间没有过渡阶段。采⽤这种⽅式时，⼈⼒和费⽤最省，适⽤于系统不太复杂或现有系统完全不能使⽤的场合。但是这种⽅式⻛险⾼。
  2. 并⾏转换：新系统和旧系统并⾏⼯作⼀段时间，经过这段时间的试运⾏后，再⽤新系统正式替换下现有系统。这种⽅式的好处是⻛险很⼩。在转换期间还可以同时⽐较新旧两套系统的性能，⽽且能够让操作⼈员得到全⾯培训，所以对于⼀些⽐较⼤的信息系统，或者处理过程⽐较复杂、数据⽐较重要的系统。并⾏转换是最常⽤的一种转换⽅式。这种转换⽅式的缺点在于，两套系统并⾏期间要有两组⼈员或两套处理⽅式同时并存，⼈⼒和费⽤消耗⽐较⼤，转换的周期⽐较⻓，⽽且难以控制新旧系统当中数据的变化。所以这就要求要做好转换计划，并且要加强管理。
  3. 分段转换：直接转换和并⾏转换的结合，也就是分期分批、逐步转换。⼀般⽐较⼤的系统采⽤这种⽅式⽐较合适，它能够保证软件平稳运⾏，费⽤也不太⾼，即将⼤的系统分成多个⼦系统，成熟⼀个⼦系统就切换⼀个⼦系统，核心是分期分批。如此新旧转换，震动⽐较⼩，⽤户⽐较容易接受。但是由于采取的是渐进的⽅式，会导致新旧系统的转换周期⽐较⻓。

新旧系统转换策略

7.1.3 数据转换与迁移

从旧数据库中抽取、转换、装载数据至新数据库。

方法：

  1. 系统切换前通过工具迁移
  2. 系统切换前采用手工录入
  3. 系统切换后通过新系统生成

数据转换与迁移

7.2 软件维护

软件维护（Software Maintenance）是指在软件产品交付之后对其进行修改，以排除故障，或改进性能和其他属性，或使产品适应改变了的环境。

影响软件可维护性的因素：

  1. 可理解性：通过阅读源代码和相关⽂档，了解软件的功能和如何运⾏的容易程度。
  2. 可修改性：修改软件的难易程度。
  3. 可测试性：验证软件程序正确的难易程度。可测试性好的软件，通常意味着软件设计简单，复杂性低。因为软件的复杂性越⼤，测试的难度也就越⼤。
  4. 可靠性：⼀个软件的可靠性越⾼，需要维护的概率就会越低。
  5. 可移植性：将软件从⼀个环境移植到新的环境下正确运⾏的难易程度。软件运⾏环境的变化是软件维护的⼀种常⻅情形，可移植性好的软件会降低维护的概率。

软件维护类型：

  1. 正确性维护【修BUG】：识别和纠正软件错误/缺陷，测试不可能发现所有错误。（改正产生于系统开发阶段而在系统测试阶段尚未发现的错误）
  2. 适应性维护【应变】：指使应⽤软件适应环境变化【外部环境、数据环境】⽽进⾏的修改。
  3. 完善性维护【新需求】：为扩充功能和改善性能⽽进⾏的修改。（例如增加新功能）
  4. 预防性维护【针对未来】：为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使⽤系统适应各类变化⽽不被淘汰。经典实例：【专⽤】改【通⽤】。

7.3 软件重用

拓展

软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。软件元素包括【需求分析文档】、设计过程、设计文档、程序代码、测试用例、领域知识等。

另见软件架构复用。

8 项目管理

  • 盈亏平衡分析 ⭐️
  • 进度管理 ⭐️⭐️⭐️
  • 软件质量管理 ⭐️⭐️
  • 软件配置管理 ⭐️⭐️

项目管理（Project Management）中时间管理的过程如下：

  1. 活动定义
  2. 活动排序
  3. 活动资源估算
  4. 活动历时估算
  5. 制定进度计划
  6. 进度控制

范围管理：项目范围定义是生产项目计划的基础。在初步项目范围说明书中已文档化的主要的可交付物、假设和约束条件的基础上准备详细的项目范围说明书，是项目成功的关键。范围定义的输入包括以下内容：

  1. 项目章程：如果项目章程或初始的范围说明书没有在项目执行组织中使用，同样的信息需要进一步收集和开发，以产生详细的项目范围说明书。
  2. 项目范围管理计划
  3. 组织过程资产
  4. 批准的变更申请

8.1 盈亏平衡分析 ⭐️

  • 正常情况下：销售额 = 固定成本 + 可变成本 + 税费 + 利润
  • 盈亏平衡时：销售额 = 固定成本 + 可变成本 + 税费 （没有利润）

【例】Hyplus网去年卖了20000台电脑，每台售价2500元，固定成本240万，可变成本3000万，税率16％。请计算卖多少台开始盈利。

【解】根据公式可得

  • 当前情况：2500 * 20000 = 2400000 + 30000000 + (2500 * 20000) * 16% + 利润

    注意“元”与“万元”单位问题

  • 盈亏平衡时
    • 固定成本 = 2400000
    • 可变成本占销售额的比例：可变成本 = (30000000 / (2500 * 20000))销售额 = 0.6销售额

      尽管可变成本是可变的，但可变成本占销售额的比例是不变的。固定成本、税费同理。

    • 税费 = 0.16 销售额
  • 设盈亏平衡时卖的台数为A，则有：2500 * A = 2400000 + (2500 * A) * 0.6 + (2500 * A) * 0.16
    • 解得：A = 4000

8.2 进度管理 ⭐️⭐️⭐️

进度管理/时间管理：为了确保项目按期完成所需要的管理过程。

8.2.1 工作分解结构（WBS）

工作分解结构（Work Breakdown Structure，WBS）是进行活动定义时通常使用的一种工具，是项目管理中的重要工具，实为用于范围管理的结构。如下图所示：

Work Breakdown Structure

WBS分解的基本要求：

  • WBS工作包是可控和可管理的，不能过于复杂。
  • 任务分解也不能过细，一般原则WBS的树形结构不超过6层。
  • 每个工作包要有一个交付成果。
  • 每个任务必须有明确定义的完成标准。
  • WBS必须有利于责任分配。

常用WBS工作包进行活动定义。包含WBS工作包的进度管理/时间管理的完整流程如下所示：

  • 活动定义：输入WBS工作包
  • 活动排序
  • 活动资源估算、活动历时估算
    1. 专家判断法
    2. 三点估算法：(乐观时间 + 4 * 最可能时间 + 悲观时间) / 6
    3. 功能点估算法
    4. 自上而下的估算
    5. 自下而上的估算
  • 制定进度计划
  • 进度控制

进度管理

8.2.2 制定进度计划

制定进度计划常使用以下两种方法

8.2.2.1 关键路径法（CPM）

关键路径法（Critical Path Method，CPM）是在制定进度计划时使用的一种进度网络分析技术。沿着项目进度网络路线进行正向与反向分析，从而计算出所有计划活动理论上的最早开始与完成日期、最迟开始与完成日期，不考虑任何资源限制。

  • 总时差（松弛时间）：在不延误总工期的前提下，该活动的机动时间。
  • 自由时差：延误时对后续活动无任何影响的时间。

单代号网络图（前导图法，Precedence Diagramming Method，PDM）是一种用来描述项目活动之间的顺序关系和依赖关系的图表。此处称入度为0的节点为源点，出度为0的节点为终点，持续时间（即松弛时间/总时差）为已知条件。

特点与具体参数意义如下所示（S：Start；F：Finish）：

活动排序

计算所有结点的ES、EF、LS、LF的方法：

  • 先按拓扑序列正推：
    • 源点的ES = 0，其他节点的ES = max{前驱节点的EF}
    • EF = ES + 持续时间
    • 项目的最短工期即为终点的EF
  • 再按逆拓扑序列逆推：
    • 终点的LF = 终点的EF，其他节点的LF = min{后继节点的LS}
    • LS = LF - 持续时间

8.2.2.2 Gantt图

甘特图（Gantt）通过条状图来显示项目、进度和其他时间相关的系统进展的内在关系随着时间进展的情况。

用细线表示工作时间安排，用粗线表示实际完成情况。

Gantt

  • 优点：甘特图直观、简单、容易制作，便于理解，能很清晰地标识出每一项任务的起始时间与结束时间，一般适用比较简单的小型项目，可用于WBS的任何层次、进度控制、资源优化、编制资源和费用计划。
  • 缺点：不能系统地表达一个项目所包含的各项工作之间的复杂关系，难以进行定量的计算和分析，以及计划的优化等。

8.2.3 进度控制

当活动出现问题时（如工期延误），通常可根据以下几条进行判定对整个项目的影响程度：

  1. 是否为关键活动：关键活动不得延误
  2. 偏差是否大于总时差：大于总时差时其可能变成关键路径
  3. 偏差是否大于自由时差：大于自由时差时会影响后续活动（较为罕见）

两种调整策略：

  1. 赶工：增加资源
  2. 快速跟进：活动并行执行

8.3 软件质量管理 ⭐️⭐️

影响软件质量的3组因素：

  1. 产品修改
    • 可理解性（我能理解它吗？）
    • 可维修性（我能修复它吗？）
    • 灵活性（我能改变它吗？）
    • 可测试性（我能测试它吗？）
  2. 产品转移
    • 可移植性（我能在另一台机器上使用它吗？）
    • 可再用性（我能再用它的某些部分吗？）
    • 互运行性（我能把它和另一个系统结合吗？）
  3. 产品运行
    • 正确性（它按我的需要工作吗？）
    • 健壮性（对意外环境它能适当地响应吗？）
    • 效率（完成预定功能时它需要的计算机资源多吗？）
    • 完整性（它是安全的吗？）
    • 可用性（我能使用它吗？）
    • 风险（能按预定计划完成它吗？）

8.3.1 软件质量控制与质量保证

质量保证（Quality Assurance，QA）一般是每隔一定时间（例如，每个阶段末）进行，主要通过系统的质量审计和过程分析来保证项目的质量。独特工具包括：质量审计和过程分析。（侧重对过程进行分析）

质量控制（Quality Control，QC）是实时监控项目的具体结果，以判断它们是否符合相关质量标准，制定有效方案，以消除产生质量问题的原因。（做测试）

质量保证的主要目标：

  • 【事前预防】工作。
  • 尽量在刚刚引入缺陷时即将其捕获，而不是让缺陷扩散到下一个阶段。
  • 作用于【过程】而【不是最终产品】。
  • 贯穿于【所有的活动之中】，而不是只集中于一点。

8.3.2 软件能力成熟度模型（CMM）

能力成熟度模型（Capability Maturity Model，CMM）在软件开发机构中被广泛用来指导软件过程改进。该模型描述了软件成立能力的5个成熟级别，每一级都包含若干个关键过程域（Key Process Areas，KPA）。

软件能力成熟度模型集成（Capability Maturity Model Integration，CMMI）分为阶段式和连续式。

阶段式所分的5级组织能力成熟度如下表所示（L1最混乱，L5最成熟）：

等级 名称 特点
L1 初始级 随意且混乱、组织成功依赖于个人能力
L2 已管理级 项目级可重复【建立了项目级的控制过程】（必须具有6个KPA）
L3 已定义级 组织级，文档化标准化
L4 定量管理级 量化式管理【过程性能可预测】
L5 优化级 持续优化

CMMI连续式的内容本质上与阶段式一致，操控上更为灵活。

需求管理是CMM可重复级中的6个关键过程域之一，其主要目标为：对于软件需求，必须建立基线以进行控制，软件计划、产品和活动必须与软件需求保持一致。（详见对应章节）

各个过程定义的负责人根据CMMI体系文件编写规范，完成相关文件的编写。相关文件自顶向下排列为：【拓展】

  1. 方针文件：过程文件及其他相关文件都应遵循方针文件。
  2. 过程文件：根据过程文件模板编制各PA过程文件，并对流程进行描述。
  3. 指南/规范文件：结合相应模板清晰说明如何完成这项工作，并说明对应的标准和需求。
  4. 模板文件：模板分为两类，一类是word文档模板， 一类是excel表格模板
    • Word文档：尽量利用公司现有的模板来制作，对需要填写替换的部分，给出具体解释或举例说明。
    • Excel表格：主要用于需要自动计算数据的模板，对需要填写替换的部分，给出具体解释或举例说明。

8.3.3 数据管理能力成熟度评估模型（DCMM）

拓展

数据管理能力成熟度评估模型（Data management Capability Maturity Model，DCMM）是我国首个数据管理领域的国家标准，提出了符合我国企业的数据管理框架。

DCMM定义了数据战略、数据治理、数据架构、数据应用、数据安全、数据质量、数据标准和数据生存周期等8个核心能力域，细分为28个过程域和445条能力等级标准：

  1. 数据战略：数据战略规划、数据战略实施、数据战略评估
  2. 数据治理：数据治理组织、数据制度建设、数据治理沟通
  3. 数据架构：数据模型、数据分布、数据集成与共享、元数据管理
  4. 数据应用：数据分析、数据开放共享、数据服务
  5. 数据安全：数据安全策略、数据安全管理、数据安全审计
  6. 数据质量：数据质量需求、数据质量检查、数据质量分析、数据质量提升
  7. 数据标准：业务数据、参考数据和主数据、数据元、指标数据
  8. 数据生存周期：数据需求、数据设计和开放、数据运维、数据退役

DCMM将企业数据管理能力成熟度划分为五个等级，自低向高依次为：初始级（1级）、受管理级（2级）、稳健级（3级）、量化管理级（4级）和优化级（5级）。（类似于CMMI）

8.4 软件配置管理 ⭐️⭐️

产品配置（Product Configuration）是指一个产品在其生命周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、计算机程序、部件及数据的集合，该集合的每一个元素称为该产品配置中的一个配置项（Configuration Item）。配置管理工具的核心功能包括【版本控制】、【变更管理】、配置状态管理、访问控制和安全控制等（版本控制工具用来存储、更新、恢复和管理一个软件的多个版本）。

配置项的分类：

  1. 基线配置项（可交付的工作成果）：需求文档、设计文档、源代码、可执行代码测试用例、运行软件所需数据等
  2. 非基线配置项（项目管理和机构支撑过程域产生的文档）：各类计划（如项目管理计划，进度管理计划）、各类报告

注：配置项由开发过程直接产生，第三方产品操作手册等既有事物不属于配置项，因此设备清单不属于配置项！

配置项的状态有3种：草稿（Draft）、正式发布（Released）、正在修改（Changing）。状态变迁图如下所示：

软件配置状态变迁图

用户文档主要描述所交付系统的功能和使用方法，并不关心这些功能是怎样实现的。用户文档是了解系统的第一步，它可以让用户获得对系统准确的初步印象。

用户文档至少应该包括下述5方面的内容：

  1. 功能描述：说明系统能做什么。
  2. 安装文档：说明怎样安装这个系统以及怎样使系统适应特定的硬件配置。
  3. 使用手册：简要说明如何着手使用这个系统（通过丰富的例子说明怎样使用常用的系统功能，并说明用户操作错误是怎样恢复和重新启动的）。
  4. 参考手册：详尽描述用户可以使用的所有系统设施以及它们的使用方法，并解释系统可能产生的各种出错信息的含义（对参考手册最主要的要求是完整，因此通常使用形式化的描述技术）。
  5. 操作员指南（若需要有系统操作员的话）：说明操作员应如何处理使用中出现的各种情况。

系统文档是从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序非常重要。

8.5 软件工具与软件开发环境（SDE）

按软件过程活动将软件系统工具分为：

  1. 软件开发工具：需求分析工具、设计工具、编码与排错工具、测试工具。
    • 需求分析工具：辅助软件需求分析活动，辅助系统分析员从需求定义出发，生成完成的、清晰的、一致的功能规范。按描述需求定义的方法可以分为基于自然语言或图形描述的工具和基于形式化需求定义语言的工具等
    • 设计工具：辅助软件设计活动，辅助设计人员从软件功能规范出发，得到相应的设计规范。
    • 编码与排错工具：辅助程序员进行编码活动。编码工具辅助程序员用某种程序语言编制源程序，并对源程序进行翻译，最终转换成可执行的代码，主要有编辑程序、汇编程序、编译程序和生成程序等。排错工具用来辅助程序员寻找源程序中错误的性质和原因，并确定其出错的位置，主要有源代码排错程序和排错程序生成程序两类。
  2. 软件维护工具：版本控制工具（VSS、CVS、SCCS、SVN）、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
  3. 软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。

软件开发环境（Software Development Environment，SDE）是指支持软件的工程化开发和维护而使用的一组软件，由软件工具集和环境集成机制构成。

软件开发环境应支持多种集成机制，例如平台集成、数据集成、界面集成、控制集成和过程集成等。软件开发环境应支持小组工作方式，并为其提供配置管理，环境的服务可用于支持各种软件开发活动，包括分析、设计、编程、调试和文档等。较完善的软件开发环境通常具有多种功能，例如软件开发的一致性与完整性维护、配置管理及版本控制、数据的多种表示形式及其在不同形式之间的自动转换、信息的自动检索与更新、项目控制和管理，以及对开发方法学的支持。软件开发环境具有集成性、开放性、可裁减性、数据格式一致性、风格统一的用户界面等特性，因而能大幅度提高软件生产率。

集成机制根据功能的不同，可划分为环境信息库、讨程控制与消息服务器、环境用户界面三个部分：

  1. 环境信息库：软件开发环境的核心，用以存储与系统开发有关的信息，并支持信息的交流与共享。环境信息库中主要存储两类信息，一类是开发过程中产生的有关被开发系统的信息，例如分析文档、设计文档和测试报告等；另一类是环境提供的支持信息，如文档模板、系统配置、过程模型和可复用构件等。
  2. 过程控制与消息服务器：实现过程集成和控制集成的基础。过程集成时按照具体软件开发过程的要求进行工具的选择与组合，控制集成使各工具之间进行并行通信和协同工作。
  3. 环境用户界面：包括环境总界面和由它实行统一控制的各环境部件及工具的界面。统一的、具有一致性的用户界面是软件开发环境的重要特征，是充分发挥环境的优越性、高效地使用工具并减轻用户的学习负担的保证。

8.6 项目管理工具

项目管理工具用来辅助软件的项目管理活动。通常项目管理活动包括项目的计划、调度、通信、成本估算、资源分配及质量控制等。一个项目管理工具通常把重点放在某一个或某几个特定的管理环节上，而不提供对管理活动包罗万象的支持。

项目管理工具具有以下特征：

  1. 覆盖整个软件生存周期
  2. 为项目调度提供多种有效手段
  3. 利用估算模型对软件费用和工作量进行估算
  4. 支持多个项目和子项目的管理
  5. 确定关键路径，松弛时间，超前时间和滞后时间
  6. 对项目组成员和项目任务之间的通信给予辅助
  7. 自动进行资源平衡
  8. 跟踪资源的使用
  9. 生成固定格式的报表和剪裁项目报告

注：无法指导软件设计人员按软件生存周期各个阶段的适用技术进行设计工作！

成本估算工具是一种典型的项目管理工具。

发表评论