软考软件设计师中级——软件工程笔记

1.软件过程

1.1能力成熟度模型（CMM）

        软件能力成熟度模型（CMM）将软件过程改进分为以下五个成熟度级别，每个级别都定义了特定的过程特征和目标：

1. 初始级 (Initial)：

   • 软件开发过程杂乱无章，缺乏明确步骤。
   • 项目成功依赖个人能力和英雄式核心人物。

2. 可重复级 (Repeatable)：

   • 建立基本的项目管理过程，跟踪费用、进度和功能特性。
   • 有过程准则以重复以往项目的成功。

3. 已定义级 (Defined)：

   • 软件过程文档化、标准化，形成组织标准。
   • 所有项目采用并遵循这些标准过程进行开发和维护。

4. 已管理级 (Managed)：

   • 详细度量标准用于软件过程和产品质量。
   • 组织成员理解和控制过程及产品质量。

5. 优化级 (Optimized)：

   • 加强定量分析，持续改进过程。
   • 利用过程质量反馈和新观念、新技术进行优化

1.2 CMMI（能力成熟度模型集成）

1) 阶段式模型：

• 分为5个成熟度等级：
  • 初始级：过程不可预测且缺乏控制。
  • 已管理级：过程为项目服务。
  • 已定义级：过程为组织服务。
  • 定量管理级：过程已度量和控制。
  • 优化级：集中于过程改进。

2) 连续式模型：（考得比较多）

• CL₀（未完成的）：过程域未执行或未得到CL₁中定义的所有目标。
• CL₁（已执行的）：共性目标是将可标识的输入工作产品转换成可标识的输出工作产品。

• CL₂（已管理的）：聚焦于过程管理的制度化，包括遵循文档化计划、资源分配、监控和控制等。

• CL₃（已定义级的）：着重于过程定义的制度化，要求过程需从组织标准集中裁剪，并收集过程资产及度量数据以促进改进。

• CL₄（定量管理的）：强调过程的定量管理，利用测量和质量保证手段控制和优化过程，并设定质量与执行的定量目标。

• CL₅（优化的）：使用量化方法（统计学手段）持续改进和优化过程域，以适应客户要求的变化和持续改进计划。

1.3 软件开发模型

1.3.1 瀑布模型

• 瀑布模型是一种典型的软件过程模型，将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型。

特点：

• 每个阶段必须在前一阶段完成之后才能开始。
• 一旦进入下一阶段，就不能返回到前一阶段进行修改。
• 这种模型强调文档的重要性，每个阶段结束时都会产生相应的文档。

优点：

• 易于理解，管理成本低。
• 适用于需求明确且稳定的项目。

缺点：

• 缺乏灵活性，难以适应需求的变化。
• 如果前期的需求分析不准确，后期的修改成本会非常高。
• 对项目风险控制能力较弱。

1.3.2  V模型

• 定义：V模型是瀑布模型的一个变体，如图5-3所示。
• 描述：V模型描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系。

1.3.3 增量模型

增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，假设可以将需求分段为一系列增量产品，每一增量可以分别开发。该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。

增量模型强调每一个增量均发布一个可操作的产品。

优点：

1. 第一个可交付版本所需要的成本和时间少；
2. 开发由增量表示的小系统所承担的风险不大；
3. 由于很快发布了第一个版本，因此可以减少用户需求的变更；
4. 运行增量投资，即在项目开始时，只投入少量资金，以后根据项目的进展情况逐步追加投资。

1.3.4 演化模型（Evolutionary Model）

演化模型是一种迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本。特别适用于对软件需求缺乏准确认识的情况。典型的演化模型有原型模型和螺旋模型等。

（1）原型模型（Prototype Model）

 

• 特点：
  • 快速原型：原型方法比较适合于用户需求不清晰、需求经常变化的情况。当系统规模不是很大也不太复杂时，采用该方法比较好。
  • 目的：能快速、低成本地构建原型。
  • 过程：通过快速计划、交流、快速设计方式建模、快速构造、评估等步骤，不断迭代和完善原型。

注意：

• 演化模型是一种适应需求变化的软件开发方法，特别适用于需求不明确或经常变化的情况。
• 原型模型是演化模型的一种具体实现，通过快速构建可执行的原型来逐步完善系统，适合小规模、需求不明确的项目。

1.3.5 螺旋模型

该模型特别适用于庞大、复杂并且具有高风险的系统。

优点

• 强调风险分析，适合高风险项目。
• 支持需求变化，提高适应能力。
• 便于项目管理决策调整。

缺点：

• 需要开发人员有丰富的风险评估经验。
• 过多的迭代次数会增加开发成本，延迟提交时间。

 

• 特点：
  • 结合了瀑布模型和演化模型的优点。
  • 强调风险分析，确保项目顺利进行。
  • 每个螺旋周期包含四个关键步骤：制订计划、风险分析、实施工程、用户评估。
  • 通过不断迭代和改进，逐步完善软件产品。

 1.3.6 喷泉模型

喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。

特点：

1. 克服了瀑布模型不支持软件重用和多项开发活动集成的局限性

2. 迭代性和无间隙性：

   • 迭代性：开发过程具有迭代性，意味着开发活动常常需要重复多次，在迭代过程中不断地完善软件系统。
   • 无间隙性：开发活动之间没有明显的边界，允许各开发活动交叉、迭代地进行。

3. 阶段划分：

   • 各个阶段没有明显的界线，开发人员可以同步进行。
   • 主要阶段包括分析、设计、实现、维护和演化。

优点

• 可以提高软件项目的开发效率，节省开发时间。

缺点

• 在各个开发阶段是重叠的，需要大量的开发人员，不利于项目的管理。
• 要求严格管理文档，使得审核的难度加大。

1.3.7  统一过程模型（Unified Process Model）

统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，由UML方法和工具支持。

典型代表

• 适用场景：适用于大型复杂软件项目的开发。
• 特点：
  • 强调用例和风险驱动。
  • 以架构为中心。
  • 迭代和增量式开发。
  • 涵盖从项目启动到最终交付的全过程。
  • 各阶段有明确的工作产品和目标。
• 起始阶段：生命周期目标。
• 精化阶段：生命周期架构。
• 构建阶段：初始运作功能。
• 移交阶段：产品发布。

 

• RUP (Rational Unified Process)：是UP的商业扩展，完全兼容UP，但比UP更完整、更详细。

在准备系统所有蓝图的时候，RUP使用的是统一建模语言UML。

特点：用例驱动、以基本的架构为中心、迭代与增量。

1.

1.3.8 基于构件的模型（Component Software Development）

利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，复用构件库中一个或多个构件，通过组合手段提高效率，高质量地构造应用软件系统的过程。

1.4 敏捷方法 

• 总体目标：通过尽早、持续地交付有价值的软件来使客户满意。
• 灵活性：在软件开发过程中加入灵活性，允许用户在开发周期的后期增加或改变需求。

1.4.1 极限编程（XP）

• 特点：轻量级、高效、低风险、柔性、可预测、科学的软件开发方式。
• 组成部分：由价值观、原则、实践和行为四个部分组成，彼此相互依赖、关联，并贯穿于整个生存周期。

4大价值观：沟通、简单性、反馈、勇气

5个原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作

12个最佳实践：

1. 计划游戏（快速制定计划、随着细节的不断变化而完善）

2. 小型发布（系统的设计要能够尽可能早地交付）

3. 隐喻（找到合适的比喻传达信息）

4. 简单设计（只处理当前的需求，使设计保持简单）

5. 测试先行（先写测试代码，然后再编写程序）

6. 重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）

7. 结队编程

8. 集体代码所有制

9. 持续集成（可以按日甚至按小时为客户提供可运行的版本）

10. 每周工作40个小时

11. 现场客户

12. 编码标准

1.4.2 水晶法

每个不同的项目都需要一套不同的策略、约定和方法论。

1.4.3 并列争求法（Scrum）

• 使用迭代的方法，其中把每30天一次的迭代称为一个“冲刺”。
• 按需求的优先级别来实现产品。
• 多个自组织和自治的小组并行地递增实现产品。

1.4.4 自适应软件开发（ASD）

1. 有一个使命作为指导。
2. 特征被视为客户价值的关键点。
3. 过程中的等待是很重要的，因此“重做”与“做”同样关键。
4. 变化不被视为改正，而是被视为对软件开发实际情况的调整。
5. 确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求。
6. 风险也包含其中。

1.4.5 敏捷统一过程（AUP）

核心原理

• 连续性：在大型项目上采用连续的方法。
• 迭代性：在小型项目上采用迭代的方法。

AUP 采用经典的 UP 阶段性活动，包括：

1. 初始
2. 精化
3. 构建
4. 转换

团队活动

1. 建模：建立对商业和问题域的模型表述，这些模型“足够好”即可，以便团队继续前进。
2. 实现：将模型翻译成源代码。
3. 测试：像 XP 一样，团队设计和执行一系列的测试来发现错误以保证源代码满足需求。
4. 部署：对软件增量的交付以及获取最终用户的反馈。
5. 配置及项目管理：着眼于变更管理、风险管理以及对团队的任一制品的控制。项目管理追踪和控制开发团队的工作进展并协调团队活动。
6. 环境管理：协调工具以支持技术过程基础设施。

2.软件需求

软件需求是用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，需预先估计系统可达到的目标，同时要注意非功能性需求。

1. 功能需求：关注软件系统所具备的具体功能和操作流程。
2. 性能需求：关注软件开发的技术性指标，如存储容量限制、执行速度、响应时间及吞吐量。这些指标衡量软件运行的效率和能力。
3. 用户或人的因素：从用户使用体验和操作难度角度出发，确保软件易用性。
4. 环境需求：确保软件在不同的硬件和软件环境下都能正常运行。
5. 界面需求：涉及软件与其他系统交互时的数据处理和格式要求。
6. 文档需求：不同的文档服务于不同的对象，如开发人员、用户等。
7. 数据需求：保证数据在软件系统中的正确处理和存储。
8. 资源使用需求：从资源利用角度确保软件的正常开发和运行。
9. 安全保密要求：保障软件系统和用户数据的安全性和保密性。
10. 可靠性要求:这是衡量软件系统稳定性和容错能力的重要指标，确保软件在出现错误时能够快速恢复正常运行，减少对用户使用的影响。
11. 软件成本消耗与开发进度需求:这是衡量软件系统稳定性和容错能力的重要指标，确保软件在出现错误时能够快速恢复正常运行，减少对用户使用的影响。
12. 其他非功能性要求

 

• 开发模式相关：确定采用何种开发模式，例如敏捷开发、瀑布模型等，不同的开发模式会影响项目的开发流程和管理方式。
• 质量控制方面：明确质量控制标准，设定项目的里程碑以及评审和验收标准，同时确定各种质量要求的优先级。这些标准和要求是保证软件质量的关键因素。
• 可维护性方面：考虑软件的可维护性要求，包括软件在后续使用过程中进行修改、升级和修复的难易程度，这关系到软件的长期使用和持续发展。

3.软件设计

3.1 概要设计

3.1.1设计软件系统总体结构

软件系统总体结构设计是概要设计的关键环节，直接影响后续详细设计与编码工作，软件系统质量和整体特性在此阶段基本确定。

3.1.2数据结构及数据库设计

• 数据结构设计：在需求分析阶段对数据特性描述的基础上，概要设计阶段进一步细化，宜采用抽象数据类型，详细设计阶段规定具体实现细节。
• 数据库设计
  • 概念设计：基于数据分析，采用自底向上方法从用户视角进行视图设计，常用 E - R 模型表述数据模型，它是数据库和数据结构设计的基础。
  • 逻辑设计：结合具体数据库管理系统（DBMS）特征，基于 E - R 模型建立数据库逻辑结构。
  • 物理设计：针对不同 DBMS 的物理环境差异，设计数据模式的物理细节，如数据项存储要求、存取方法和索引建立等。

3.1.3编写概要文档

主要编写概要设计说明书、数据库设计说明书、用户手册以及修订测试计划等文档。

3.1.4评审

对设计部分是否完整实现需求规定的功能、性能等要求，设计方法的可行性，关键处理及内外部接口定义的正确性、有效性和各部分一致性等进行全面评审。

3.2详细设计

3.2.1算法设计

对每个模块进行细致的算法设计，运用图形、表格、语言等工具精确描述模块处理过程的详细算法，这是实现模块功能的核心步骤。

3.2.2数据结构设计

针对模块内的数据结构进行设计，目的是优化数据的组织和存储方式，以提高模块对数据的处理效率。

3.2.3数据库物理设计

确定数据库的物理结构，包括存储位置、存储方式等，使数据库在实际运行环境中能够高效存取数据。

3.2.4其他设计

1. 代码设计：为提升数据输入、分类、存储和检索等操作的效率，节约内存空间，对数据库中特定数据项的值进行代码设计，例如采用编码规则来简化数据表示。
2. 输入 / 输出格式设计：设计合理的输入 / 输出格式，确保数据的输入便捷准确，输出直观易懂，符合用户使用习惯和系统需求。
3. 用户界面设计：根据软件系统的类型和用户需求，设计友好、易用的用户界面，提升用户体验。

3.2.5文档编写

编写详细设计说明书，全面记录详细设计阶段的各项成果，为后续的编程实现和系统维护提供清晰的指导。

3.2.6评审

对处理过程的算法和数据库的物理结构进行评审，检查设计的合理性、正确性和高效性 ，及时发现并纠正潜在问题。

4.系统测试

4.1系统测试与调试

系统测试是为发现错误而执行程序的过程，成功的测试是能发现尚未被发现的错误的测试。

信息系统测试包括软件测试、硬件测试和网络测试，文中侧重软件测试。

原则：

1. 尽早且持续测试原则：测试不应在应用系统开发完成后才进行，由于开发过程的复杂性和多阶段性，错误可能出现在各个阶段，所以测试应贯穿开发全过程，尽早发现并纠正错误。
2. 独立测试原则：测试工作应由专门人员而非原开发人员或小组承担。因为开发人员可能不愿承认自己工作的错误，且容易受自身编程思路限制，专门人员测试更客观、有效。
3. 全面设计测试方案原则：设计测试方案时，不仅要确定输入数据，还要依据系统功能确定预期输出结果，通过比较实际输出与预期结果来判断测试对象的正确性。
4. 覆盖多种输入条件：设计测试用例时，既要包含有效、合理的输入条件，也要涵盖不合理、失效的输入条件。避免只关注正常情况测试，以发现异常情况下可能存在的隐患。
5. 双重检验程序功能：测试程序时，不仅要检查程序是否实现了预期功能（做了该做的事），还要检查是否存在多余操作（做了不该做的事），防止多余工作影响程序效率和带来潜在危害。
6. 严格遵循测试计划：严格按照包含测试内容、进度安排、人员安排、测试环境、测试工具和测试资料等的测试计划进行测试，避免测试的随意性，保障测试工作按进度协调开展。
7. 妥善保存测试文档：妥善保存测试计划和测试用例，使其作为软件文档的一部分，为后续软件维护提供便利。
8. 利用测试用例复用：测试用例是精心设计的成果，在纠正错误、扩充系统功能等需要重新测试或追加测试时，可复用之前的测试用例或在此基础上修改后使用，提高测试效率，减少重复性工作。
9. 系统测试阶段的测试目标来自于需求分析阶段。

4.2单元测试

        单元测试也称模块测试，在模块编写完成且无编译错误后进行，侧重于模块内部处理逻辑和数据结构，机器测试常用白盒测试法，可同时测试多个模块。

4.2.1单元测试的内容

        单元测试主要检查模块的以下5个特征：

        （1）模块接口

        （2）局部数据结构

        （3）重要的执行路径

        （4）出错处理

        （5）边界条件

4.2.2单元测试的过程

        由于模块不是独立运行的程序，各模块之间存在调用与被调用的关系。在对每个模块进行测试时，需要开发两种模块。

•  驱动模块：相当于一个主程序，接收测试例子的数据，将这些数据送到测试模块，输出测试结果。
• 桩模块(也称为存根模块)：桩模块用来代替测试模块中所调用的子模块，其内部可进行少量的数据处理，目的是为了检验入口，输出调用和返回的信息。

        一些增量集成策略：

        1.自顶向下集成测试

        自顶向下集成测试是一种构造软件体系结构的增量方法。模块的集成顺序为从主控模块(主程序)开始，沿着控制层次逐步向下，以深度优先或广度优先的方式将从属于(或间接从属于)主控模块的模块集成到结构中。

        集成过程可以通过下列5个步骤完成：

• 主控模块用作测试驱动模块，用这些从属于主控模块的所有模块代替桩模块。
• 依靠所选择的集成方法(即深度优先或广度优先)，每次用实际模块替换一个从属桩模块。
• 在集成每个模块后都进行测试。
• 在完成每个测试集之后，用实际模块替换另一个桩模块。
• 可以执行回归测试，以确保没有引入新的错误。
• 回到第(2)步继续执行此过程，直到完成了整个程序结构的构造。

     2.自底向上集成测试

        自底向上集成测试就是从原子模块(程序结构的最底层构件)开始进行构造和测试。由于构件是自底向上集成的，在处理时所需要的从属于给定层次的模块总是存在的，因此，没有必要使用桩模块。自底向上集成策略可以利用以下步骤来实现。

• 连接低层构件以构成完成特定子功能的簇。
• 编写驱动模块(测试的控制程序)以协调测试用例的输入和输出。
• 测试簇。
• 去掉驱动程序，沿着程序结构向上逐步连接簇。

        3.回归测试 

        每当加入一个新模块作为集成测试的一部分时，软件发生变更，建立了新的数据流路径，可能出现新的IO，以及调用新的控制逻辑。这些变更可能会使原来可以正常工作的功能产生问题。在集成测试策略的环境下，回归测试是重新执行已测试过的某些子集，以确保变更没有传播不期望的副作用。

        回归测试要执行的测试子集包含以下3 种测试用例：

1. 能够测试软件所有功能的具有代表性的测试样本。
2. 额外测试，侧重于可能会受变更影响的软件功能。
3. 侧重于已发生变更的软件构件测试。

        4.冒烟测试

        当开发软件产品时,冒烟测试是一种常用的集成测试方法,是时间关键项目的决定性机制它让软件团队频繁地对项目进行评估。本质上，冒烟测试方法包括下列活动:
        (1)将已经转换为代码的软件构件集成到构建中。一个构建包括所有的数据文件、库、可复用的模块以及实现一个或多个产品功能所需的工程化构件。
        (2)设计一系列测试以暴露影响构建正确的完成其功能的错误，其目的是为了发现极有可
能造成项目延迟的业务阻塞错误。

        (3)每天将该构建与其他构建及整个软件产品(以其当前形势)集成起来进行冒烟测试。
这种集成方法可以自顶向下，也可以自底向上。

4.2.3 测试方法 

        软件测试方法分为静态测试和动态测试：

        (1)静态测试：静态测试是指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。
        (2)动态测试：动态测试是指通过运行程序发现错误。在对软件产品进行动态测试时可以采用黑盒测试法和白盒测试法。测试用例由测试输入数据和与之对应的预期输出结果组成。在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

• 黑盒测试

        黑盒测试也称为功能测试，在完全不考虑软件的内部结构和特性的情况下，测试软件的外部特性。

        1.等价类划分:将输入域划分为若干等价类（有效/无效），每个类选取一个代表值测试。

        2. 边界值分析:测试输入域的边界值（如最小值、最大值、略小于边界、略大于边界）。

        3. 因果图法:分析输入条件（因）与输出结果（果）的逻辑关系，生成判定表。

• 步骤：

  1. 确定输入条件与输出结果。

  2. 绘制因果图（逻辑关系：与、或、非）。

  3. 转换为判定表，生成测试用例。

        4. 错误法:基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。其基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

• McCabe 度量法

        McCabe 度量法是通过定义环路复杂度，建立程序复杂性的度量，它基于一个程序模块的程序图中环路的个数。计算有向图G的环路复杂性的公式为:V(G)=m-n+2，其中V(G)是有向图G中的环路个数，m是G中的有向弧数，n是G中的节点数。

                                                

• 白盒测试

1. 语句覆盖：每条语句至少执行一次（最弱覆盖）。

2. 判定覆盖（分支覆盖）：每个判断的真/假分支至少执行一次。

3. 条件覆盖：每个判断中的每个条件（子表达式）的真/假均被覆盖。

4. 判定-条件覆盖：同时满足判定覆盖和条件覆盖。

5. 条件组合覆盖：覆盖所有条件的真/假组合（覆盖强度最高）。

6. 路径覆盖：覆盖程序中所有可能的执行路径（实际中复杂度高，通常仅针对关键路径）。

5.系统维护

5.1系统可维护性概念

5.1.1系统可维护性的评价指标

(1)可理解性。指别人能理解系统的结构、界面、功能和内部过程的难易程度。模块化、详细设计文档、结构化设计和良好的高级程序设计语言等都有助于提高可理解性。

(2)可测试性。诊断和测试的容易程度取决于易理解的程度。好的文档资料有利于诊断和测试，同时，程序的结构、高性能的测试工具以及周密计划的测试工序也是至关重要的。为此，开发人员在系统设计和编程阶段就应尽力把程序设计成易诊断和测试的。此外，在进行系统维护时，应该充分利用在系统测试阶段保存下来的测试用例。
(3)可修改性。诊断和测试的容易程度与系统设计所制定的设计原则有直接关系。模块的耦合、内聚、作用范围与控制范围的关系等都对可修改性有影响。

5.1.2系统维护的内容及类型

        系统维护主要包括硬件维护、软件维护和数据维护。
        1.硬件维护
        2.软件维护
        软件维护主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部修改。

        根据维护的目的和内容，软件维护分为以下四类：

维护类型	核心内容	典型场景	考试重点
正确性维护	正确性维护是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误，	- 用户报告程序崩溃或逻辑错误。 - 测试阶段未覆盖的隐藏问题。	占比约 15%~25%（非最高）。
适应性维护	使软件适应外部环境的变化（硬件、操作系统、数据库、法规等）。	- 操作系统升级导致兼容性问题。 - 数据库从MySQL迁移到Oracle。	占比约 20%~25%。
完善性维护	根据用户需求新增功能或优化现有功能（非缺陷修复）。	- 用户提出新的报表需求。 - 优化系统响应速度或界面交互。	占比最高（约 50%~60%）。
预防性维护	主动优化代码结构、文档或架构，降低未来维护成本（预防潜在问题）。	- 重构冗余代码提升可读性。 - 更新技术文档或增加注释。	占比最低（约 5%），常被忽略。

        3.数据维护 ：数据库结构变更（如新增字段）、数据迁移或清洗。

5.2软件质量属性

        可靠性、可用性和可维护性是软件的质量属性，软件工程中，用0-1之间的数来
度量。
        1.可靠性是指一个系统对于给定的时间间隔内、在给定条件下无失效运作的概率。可以用 MTTF/(1+MTTF)来度量，其中 MTTF （Mean Time To Failure）为平均无故障时间。
        2.可用性是在给定的时间点上，一个系统能够按照规格说明正确运作的概率。可以用MTBF/(1+MTBF)来度量，其中MTBF （Mean Time Between Failures）为平均失效间隔时间。
        3.可维护性是在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成维护活动的概率。可以用 1/(1+MTTR)来度量，其中MTTR（Mean Time To Repair） 为平均修复时间。

6.软件文档

        编写高质量文档可以提高软件开发的质量文档也是软件产品的一部分，没有文档的软件就不能称之为软件。软件文档的编制在软件开发工作中占有突出的地位和相当大的工作量高质量文档对于软件产品的效益有着重要的意义。

7.软件项目估算

7.1COCOMO 模型概述

• 全称：Constructive Cost Model（构造性成本模型），由 Barry Boehm 提出。

• 用途：估算软件开发项目的工作量（人月）、成本（费用）和工期（时间）。

• 适用阶段：适用于软件项目早期（需求明确后）的成本预测。

• 核心思想：基于代码行数（KLOC）和调整因子计算工作量。

7.2COCOMO 模型的三个层次

        COCOMO 模型是一种精确的、易于使用的成本估算模型。COCOMO 模型按其详细程度分
为基本 COCOMO 模型、中级 COCOMO 模型和详细 COCOMO 模型。

1. 基本 COCOMO（Basic COCOMO）

• 特点：基本 COCOMO 模型是一个静态单变量模型，用于对整个软件系统进行估算。仅考虑代码行数（KLOC），忽略其他因素，适用于快速粗略估算。

• 公式：

  \text{工作量（人月）} = a \times (\text{KLOC})^b工作量（人月）=a×(KLOC)b\text{工期（月）} = c \times (\text{工作量})^d工期（月）=c×(工作量)d

• 系数表（根据项目类型选择）：

  项目类型	a	b	c	d
  有机型（小型团队）	2.4	1.05	2.5	0.38
  半分离型（中型）	3.0	1.12	2.5	0.35
  嵌入型（复杂约束）	3.6	1.20	2.5	0.32

• 项目类型说明：

  • 有机型：需求稳定，团队经验丰富（如企业内部系统）。

  • 嵌入型：严格约束下的复杂系统（如航天控制软件）。

  • 半分离型：介于两者之间（如银行交易系统）。

2. 中间 COCOMO（Intermediate COCOMO）

• 特点：中级 COCOMO模型是一个静态多变量模型,它将软件系统模型分为系统和部件两个层次系统由部件构成，它把软件开发所需的人力(成本)看作是程序大小和一系列“成本驱动属性的函数。在基本模型基础上引入15个成本驱动因子（Cost Drivers），提高估算精度。

• 公式：

  \text{工作量} = a \times (\text{KLOC})^b \times \text{EAF}工作量=a×(KLOC)b×EAF

  • EAF（Effort Adjustment Factor）：15个成本驱动因子的乘积（每个因子取值范围0.7~1.66）。

• 典型调整因子（考试高频）：

  类别	示例因子	影响范围
  产品属性	软件可靠性、数据库复杂度	高→EAF增大
  硬件属性	执行时间约束、内存限制	高→EAF增大
  人员属性	开发人员经验、团队协作能力	低→EAF增大
  项目属性	开发工具先进性、进度压力	高→EAF增大

3. 详细 COCOMO（Detailed COCOMO）

• 特点：它将软件系统模型分为系统、子系统和模块3个层次，除包括中级模型所考虑的因素外，还考虑了在需求分析、软件设计等每一步的成本驱动属性的影响，适用于大型项目。

• 考试重点：理解其分层细化思想，具体计算较少考查。

7.3COCOMOII模型

根据项目阶段的不同，COCOMO II 分为以下三个子模型：

子模型	适用阶段	规模度量	核心公式
应用组装模型	早期需求阶段，这时用户界面的原型开发、对软件和系统交互的考虑、性能的评估以及技术成熟度的评价是最重要的。	对象点（Object Points）	基于复用组件和界面复杂度估算规模。
早期设计模型	概要设计阶段，在需求已经稳定并且基本的软件体系结构已经建立时使用。	功能点（FP）	初步估算工作量，支持架构决策。
后体系结构模型	详细设计及编码阶段，在软件的构造过程中使用。	代码行（SLOC）	最精确的估算模型，结合详细成本驱动因子。

---

7.4PERT图

        PERT 图是一个有向图，图中的箭头表示任务，它可以标上完成该任务所需的时间。图中的结点表示流入结点的任务的结束，并开始流出结点的任务，这里把结点称为事件。只有当流入该结点的所有任务都结束时，结点所表示的事件才出现，流出结点的任务才可以开始。事件本身不消耗时间和资源，它仅表示某个时间点。一个事件有一个事件号和出现该事件的最早时刻和最迟时刻。最早时刻表示在此时刻之前从该事件出发的任务不可能开始;最迟时刻表示从该事件出发的任务必须在此时刻之前开始，否则整个工程就不能如期完成。每个任务还可以有个松弛时间(Slack Time)，表示在不影响整个工期的前提下完成该任务有多少机动余地。

7.5Gantt图

        Gantt图是一种简单的水平条形图，它以日历为基准描述项目任务。水平轴表示日历时间线(如时、天、周、月和年等)，每个条形表示一个任务，任务名称垂直地列在左边的列中，图中水平条的起点和终点对应水平轴上的时间，分别表示该任务的开始时间和结束时间，水平条的长度表示完成该任务所持续的时间。当日历中同一时段存在多个水平条时，表示任务之间的并发。图 5-12 所示的 Gantt 图描述了3个任务的进度安排。任务1首先开始，完成它需要6个月时间;任务2在1个月后开始，完成它需要9个月时间;任务3在6个月后开始，完成它需要5 个月时间。

7.6项目活动图

1. 活动图基本要素

   • 顶点：表示里程碑（事件），不消耗时间，仅标志活动的开始或结束。
   • 边：表示活动（任务），标注持续时间，箭头方向代表依赖关系。
   • 关键路径：从起点到终点的最长路径，决定项目最短工期。关键路径上的活动称为关键活动，其松弛时间为 0。

2. 关键路径计算方法

   • 正向推导：从起点开始，计算每个事件的最早发生时间（ET）。若多个活动指向同一事件，取最大值作为 ET617。
   • 反向推导：从终点开始，计算每个事件的最晚发生时间（LT）。若多个活动从同一事件出发，取最小值作为 LT617。
   • 关键路径判定：ET=LT 的事件构成关键路径。

8.软件配置管理

主要考点：

软件配置管理其主要目标包括:变更标识、变更控制、版本控制、确保变更正确的实现、变更报告。

软件配置管理其主要内容包括:版本管理、配置支持、变更支持、过程支持、团队支持、变化报告、审计支持

上下为两个不同的版本

软件配置管理其主要内容包括:软件配置标识、变更管理、版本控制、系统建立、配置审核、配置状态报告

        配置数据库可以分为以下三类：
        (1)开发库。专供开发人员使用，其中的信息可能做频繁修改，对其控制相当宽松。
        (2)受控库。在生存期某一阶段工作结束时发布的阶段产品，这些是与软件开发工作相关的计算机可读信息和人工可读信息。软件配置管理正是对受控库中的各个软件项进行管理，受控库也称为软件配置库。
        (3)产品库。在开发的软件产品完成系统测试后，作为最终产品存入产品库，等待交付用户或现场安装。

9.风险管理

9.1风险基本概念

• 风险三要素：风险事件（如技术难题、需求变更）、发生概率、影响程度。
• 特性：不确定性和损失，不确定性是指风险可能发生也可能不发生;损失是指如果风险发生，就会产生恶性后果。
• 风险分类：
  1. 项目风险：进度延误、资源不足、团队沟通问题。
  2. 技术风险：技术兼容性、代码质量、新技术不成熟。
  3. 商业风险：

                                (1)市场风险。开发了一个没有人真正需要的优良产品或系统。
                                (2)策略风险。开发的产品不再符合公司的整体商业策略。
                                (3)销售风险。开发了一个销售部门不知道如何去销售的产品。
                                (4)管理风险。由于重点的转移或人员的变动而失去了高级管理层的支持,
                                (5)预算风险。没有得到预算或人员的保证。

9.2风险识别

        风险识别试图系统化地指出对项目计划(估算、进度、资源分配等)的威胁。

        识别风险的一种方法是建立风险条目检查表。该检查表可用于风险识别，并且主要用来识别下列几种类型中的一些已知风险和可预测风险。

• 产品规模。与要开发或要修改的软件的总体规模相关的风险
• 商业影响。与管理者或市场所施加的约束相关的风险。
• 客户特性。与客户的素质以及开发者和客户定期沟通的能力相关的风险。
• 过程定义。与软件过程定义的程度以及该过程被开发组织遵守的程度相关的风险。
• 开发环境。与用来开发产品的工具的可得性及质量相关的风险。
• 开发技术。与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险
• 人员才于及经验。与软件工程师的总体技术水平及项目经验相关的风险。

        当然，也可以采用另一种风险条目检查表格式，即仅仅列出与每一种类型有关的特性，最终给出一组风险因素和驱动因子以及它们发生的概率。风险因素包括性能、成本、支持和进度风险因素是以如下方式定义的。

• 性能风险。产品能够满足需求且符合其使用目的的不确定程度
• 成本风险。能够维持项目预算的不确定程度。
• 支持风险。开发出的软件易于纠错、修改及升级的不确定程度
• 进度风险。能够维持项目进度且按时交付产品的不确定程度。

9.3风险预测

        一种简单的风险预测技术是建立风险表。风险表的第1列列出所有的风险(由风险识别活动得到)，第 2~4列列出每个风险的种类、发生的概率以及所产生的影响。风险所产生的影响可用一个数字来表示:“1”表示灾难性的;“2”表示严重的;“3”表示轻微的;“4”表示可忽略的。

       整体的风险显露度(RiskExposure，RE)可由下面的关系确定:
                                                                RE=P*C
        其中，P是风险发生的概率，C是风险发生时带来的项目成本。

9.4风险评估

        在进行风险评估时，建立了如下形式的三元组:

                                                                     (ri​,li​,xi​)                                                    
        在风险评估过程中，需要执行以下4个步骤。
        (1)定义项目的风险参考水平值。
        (2)建立每一组 (ri​,li​,xi​) 与每一个参考水平值之间的关系。
        (3)预测一组临界点以定义项目终止区域，该区域由一条曲线或不确定区域所界定。
        (4)预测什么样的风险组合会影响参考水平值。

9.5风险控制

        风险控制的目的是辅助项目组建立处理风险的策略。一个有效的策略必须考虑以下3个
问题。

1. 风险避免：主动分析风险成因并采取措施规避风险。如针对 “频繁人员流动” 风险（概率 70%，影响为严重 2 级），可采取探究流动原因、缓解可控起因、保障人员离开后的工作连续性、促进信息传播交流、制定工作产品标准并建立创建机制、同等对待工作评审、为关键技术人员指定后备人员等策略。                                                                                                        (1)与现有人员一起探讨人员流动原因(如恶劣的工作条件、低报酬、竞争激烈的劳动力市场等)。
           (2)在项目开始之前采取行动，设法缓解那些能够控制的起因。
           (3)项目启动之后，假设会发生人员流动，当有人员离开时，找到能够保证工作连续性的方法。
           (4)组织项目团队，使得每一个开发活动的信息都能被广泛传播和交流。
           (5)制定工作产品标准，并建立相应机制以确保能够及时创建所有的模型和文档。
           (6)同等对待所有工作的评审。
           (7)给每一个关键的技术人员都指定一个后备人员
2. 风险监控：监测能反映风险变化（变高或变低）的因素。如在人员流动案例中，需监测团队成员对项目压力的态度、团队凝聚力、成员关系、报酬利益相关潜在问题、内外工作可能性等。
3. RMMM 计划：风险管理策略可融入软件项目计划，或组成独立的风险管理计划（文中提及但未详述，需关注其定义与作用）。

风险应对策略（考试重点）

策略	适用场景	示例
规避	风险影响极大且不可接受	放弃采用新技术，改用成熟方案。
减轻	风险可部分控制	增加测试用例覆盖关键路径。
转移	风险可外包或分摊	购买保险、外包高风险模块开发。
接受	风险影响小或应对成本过高	预留应急储备金或时间缓冲。

10.软件质量

        软件质量是指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体。

10.1软件质量特性

        讨论软件质量首先要了解软件的质量特性，目前已经有多种软件质量模型来描述软件质量特性，例如 ISO/EC 9126 软件质量模型和 Mc Call 软件质量模型。

1.ISO/EC 9126 软件质量模型
        ISO/EC9126 软件质量模型由3个层次组成:第一层是质量特性，第二层是质量子特性第三层是度量指标

质量特性	子特性	典型场景
功能性	适合性、准确性、互用性、依从性、安全性	软件是否实现需求文档中的功能。
可靠性	成熟性、容错性、易恢复性	系统在故障后能否快速恢复（如事务回滚）。
易用性	易理解性、易学性、易操作性	用户界面是否友好，操作是否直观。
效率	时间特性、资源利用率	系统响应时间、CPU/内存占用率。
可维护性	易分析性、易修改性、稳定性、易测试性	代码是否模块化，是否易于修复缺陷。
可移植性	适应性、易安装性、一致性、易替换性	软件能否在不同平台或环境中运行。

2.Mc Call 软件质量模型 

        Mc Cal 软件质量模型从软件产品的运行、修正和转移3个方面确定了 11个质量特性。Mc Cal 也给出了一个三层模型框架，第一层是质量特性，第二层是评价准则,第三层是度量指标。

1. 产品运行质量（面向用户）

质量因素	定义	评价准则（示例）
正确性	软件满足需求规格的程度	需求覆盖率、缺陷修复率。
可靠性	在规定条件下无故障运行能力	容错性、一致性、故障恢复时间。
效率	资源利用率与响应速度	吞吐量、响应时间、内存占用率。
完整性	防止未授权访问和数据丢失	加密强度、访问控制粒度。
易用性	用户学习和操作的容易程度	界面友好性、帮助文档完整性。

2. 产品修正质量（面向维护）

质量因素	定义	评价准则（示例）
可维护性	软件修改的难易程度	模块化程度、代码注释率。
灵活性	适应需求变化的容易程度	配置参数化、接口扩展性。
可测试性	测试和验证的容易程度	自动化测试覆盖率、日志完整性。

3. 产品迁移质量（面向环境）

质量因素	定义	评价准则（示例）
可移植性	跨平台和环境运行的能力	平台兼容性、依赖库标准化。
复用性	组件被其他系统复用的能力	接口通用性、功能独立性。
互用性	与其他系统交互的能力	接口协议标准化、数据格式兼容性。

10.2软件评审

10.2.1评审类型

1. 需求评审：审查需求规格说明书，确保需求的准确性、完整性、一致性、可验证性，避免歧义与遗漏，减少后期变更风险。
2. 设计评审：评估系统架构、详细设计文档，检查是否满足需求，关注可维护性、可扩展性、性能及安全性，例如确认架构设计是否遵循规范。
3. 代码评审：检查代码质量，发现潜在错误，确保代码符合编码标准与最佳实践，提升可读性与可维护性。
4. 测试评审：审查测试计划、用例、结果，确保测试覆盖全面，策略有效，例如验证测试用例是否覆盖所有需求点。
5. 发布前评审：在软件发布前，全面检查功能、性能、稳定性等，确认是否满足用户需求与质量标准。

10.2.2评审内容

• 文档层面：检查文档结构合理性（如引言、系统设计概述、数据库设计等）、内容完整性（无关键信息缺失）、语言准确性（无二义性）。
• 功能与性能：验证功能设计是否满足需求，性能指标（如响应时间、吞吐量）是否达标，安全性、兼容性等是否考虑周全。
• 过程合规性：确认开发过程是否遵循既定规范，例如代码编写是否符合团队标准，测试流程是否完整。

10.2.3评审方法

1. 文档评审：通过阅读文档发现问题，适用于初步检查。
2. 评审会议：组织开发、测试、需求方等多方参与，集中讨论评审内容，如需求评审会议。
3. 专家评审：邀请领域专家评估技术方案的合理性与可行性，例如架构设计的专家把关。
4. 集体审查：团队成员交叉检查，利用多人视角发现问题，常用于代码评审。
5. 电子邮件评审：分散收集意见，适合非紧急、需远程协作的场景。

10.2.4评审原则与标准

• 原则：文档编写需遵循简洁明了、完整性、可读性、独立性、一致性、可追溯性、可维护性、可扩展性等原则，确保文档质量。
• 标准：评审设计时关注合理性、可实现性、效率、可靠性、灵活性、可维护性、扩展性、稳定性等，例如评估架构是否具备良好的可扩展性以应对未来需求变化。

10.2.5评审流程要点

1. 准备阶段：明确评审对象（如测试计划、设计文档），通知相关人员，确保资料齐全。
2. 执行阶段：通过会议或文档审查，记录问题与建议，例如在代码评审中标记风格不符处。
3. 跟踪阶段：跟进问题整改，验证修复结果，更新评审记录，确保闭环管理。

10.3软件容错技术

1. 结构冗余：通过冗余硬件 / 软件模块提升可靠性，按工作方式分为：
   • 静态冗余：多模块同时运行，通过表决机制（如多数表决）屏蔽故障模块，如三模冗余系统。
   • 动态冗余：故障时切换到备份模块，如双机热备（主系统故障，备用系统接管）。
   • 混合冗余：结合静态与动态冗余，灵活应对不同故障场景。
2. 信息冗余：添加额外信息检测 / 纠正错误，如校验码（CRC 校验）、纠错码（海明码），确保数据传输或存储的正确性。
3. 时间冗余：重复执行指令或程序消除瞬时错误，如网络请求失败后重试，或关键操作多次执行验证结果一致性。在程序复算中比较常用的方法是程序滚回(Program Rollback)技术。
4. 冗余附加技术：支持上述冗余的资源与技术，包括冗余程序的存储调用、错误检测与恢复程序、固化程序（如 BIOS 中的容错处理）等。

        在屏蔽硬件错误的容错技术中，冗余附加技术包括:
     1.关键程序和数据的冗余存储及调用。
     2.检测、表决、切换、重构、纠错和复算的实现。
        在屏蔽软件错误的容错系统中，冗余附加技术的构成包括 

1. 冗余备份程序的存储及调用
2. 实现错误检测和错误恢复的程序
3. 实现容错软件所需的固化程序

11.软件工具

1.软件开发工具

阶段	工具类型	典型工具 / 技术	功能说明
需求分析	需求建模工具	Visio、Axure、UML 工具（如 Enterprise Architect）	绘制用例图、流程图，辅助需求结构化表达，生成需求规格说明书。
设计阶段	架构设计工具	Rose、StarUML、Archimate	支持 UML 建模（类图、组件图、部署图），辅助系统架构设计与可视化。
编码阶段	集成开发环境（IDE）	Eclipse、IntelliJ IDEA、VS Code	提供代码编辑、编译、调试、版本控制集成功能，支持多语言开发（Java、C++ 等）。
测试阶段	单元测试工具	JUnit（Java）、NUnit（.NET）、PyTest（Python）	自动执行单元测试用例，生成测试报告，验证代码逻辑正确性。
测试阶段	性能测试工具	LoadRunner、JMeter	模拟多用户并发场景，测试系统性能瓶颈，分析响应时间、吞吐量等指标。
测试阶段	自动化测试工具	Selenium（Web 自动化）、Appium（移动自动化）	录制 / 回放用户操作，实现功能测试自动化，减少手工测试成本。

2. 软件维护工具

工具类型	典型工具 / 技术	功能说明
版本控制工具	Git、SVN、GitHub、GitLab	管理软件不同版本，记录变更历史，支持分支管理（如 Feature 分支、Hotfix 分支），实现代码回滚与合并。
逆向工程工具	IDA Pro、JD-GUI、DotPeek	将目标代码（二进制 / 字节码）反编译为高级语言或设计模型（如类图），辅助理解遗留系统逻辑。
重构工具	IDE 内置重构功能（如 IDEA 的 Refactor）	自动优化代码结构（如重命名变量、提取方法、优化循环），提升代码可读性与可维护性。
代码分析工具	SonarQube、Checkstyle、FindBugs	静态分析代码质量，检测潜在缺陷（如代码异味、安全漏洞、性能问题），生成质量报告。
调试工具	WinDbg、GDB、VS 调试器	定位运行时错误，支持断点调试、变量监控、调用栈分析，辅助修正程序缺陷。
配置管理工具	Ansible、Chef、Puppet	自动化管理系统配置，确保维护过程中环境一致性（如服务器部署、软件依赖管理）。
数据迁移工具	ETL 工具（如 Talend、Kettle）	支持不同数据库 / 系统间的数据迁移与转换，辅助系统升级或数据整合维护。

2. 维护场景应用

12.补充知识

1.仓库风格

仓库风格是一种软件体系结构，其中包含一个数据仓库和若干个其他构件。数据仓库位于该体系结构的中心，其他构件访问该数据仓库并对其中的数据进行增、删、改等操作。数据库系统、超文本系统和黑板系统都属于仓库风格。

该体系结构的优点包括:
①对可更改性和可维护性的支持② 可复用的知识源:③ 支持容错性和健壮性。

缺点包括:
① 测试困难:②不能保证有好的解决方案:③ 难以建立好的控制策略;④ 低效⑤ 昂贵的开发工作⑥缺少并行机制的支持。

2.调试方法
目前，常用的调试方法有以下几种。
1)试探法
调试人员分析错误的症状，猜测问题所在的位置，利用在程序中设置输出语句，分析寄存器、存储器的内容等手段获得错误的线索，一步步地试探和分析出错误所在。这种方法效率很低，适合于结构比较简单的程序。
2)回溯法调试人员从发现错误症状的位置开始，人工沿着程序的控制流程往回跟踪代码，直到找出错误根源为止。这种方法适合于小型程序，对于大规模程序，由于其需要回溯的路径太多而变得不可操作。
3)对分查找法这种方法主要用来缩小错误的范围，如果已经知道程序中的变量在若干位置的正确取值，可以在这些位置上给这些变量以正确值，观察程序运行的输出结果，如果没有发现问题，则说明从赋予变量一个正确值开始到输出结果之间的程序没有错误，问题可能在除此之外的程序中。否则错误就在所考察的这部分程序中，对含有错误的程序段再使用这种方法，直到把故障范围缩小到比较容易诊断为止。
4)归纳法
归纳法就是从测试所暴露的问题出发，收集所有正确或不正确的数据，分析它们之间的关系，提出假想的错误原因，用这些数据来证明或反驳，从而查出错误所在。
5)演绎法演经法根据测试结果，列出所有可能的错误原因:分析已有的数据，排除不可能和彼此矛盾的原因;对其余的原因，选择可能性最大的，利用己有的数据完善该假设，使假设更具体;用假设来解释所有的原始测试结果，如果能解释这一切，则假设得以证实，也就找出错误，否则，要么是假设不完备或不成立，要么有多个错误同时存在，需要重新分析，提出新的假设直到发现错误为止。