【软件设计师-从小白到大牛】上午题基础篇：第六章 软件工程基础（重点中的重点）
文章目录
- 前言
- 一、软件开发模型
-
- 1、瀑布模型（SDLC）
- 真题链接
- 2、其他经典模型概览
- 3、 增量模型
- 真题链接
- 4、原型模型、螺旋模型
- 真题链接
- 真题链接
- 5、V模型、喷泉模型与RAD
- 真题链接
- 6、构件组装模型（CBSD）
- 7、统一过程（UP/RUP）
- 真题链接
- 8、敏捷开发方法
- 真题链接
- 真题链接
- 真题链接
- 二、信息系统开发方法
-
- 真题链接
- 三、需求的分类
-
- 真题链接
- 系统设计（补）
-
- 概要设计
- 真题链接
- 详细设计
- 四、结构化设计
- 五、软件测试
-
- 1、测试原则与类型
- 真题链接
- 2、测试用例设计
- 真题链接
- 3 、测试阶段
- 4、McCabe复杂度
- 六、系统运行与维护
-
- 真题链接
- 七、软件过程改进
-
- 1、能力成熟度模型（CMM）（重点，主要记忆各阶段关键词，可以区分各阶段）
- 真题链接
- 2、能力成熟度模型集成（CMMI）（重点，主要记忆各阶段关键词，可以区分各阶段）
-
- 阶段式模型（了解）
- 连续式模型（一般考这个）
- 真题链接
- 八、项目管理
-
- 真题链接
- 风险管理
- 真题链接
- 软件项目估算（补）
- 真题链接
- 软件配置管理（补）
- 软件质量（补）
-
- 软件质量特性
- 真题链接
- 软件评审
- 真题链接
- 软件容错技术
- 真题链接
前言
本系列文章为观看b站视频以及b站up主@zst_2001系列视频所做的笔记，感谢相关博主的分享。如有侵权，立即删除。
视频链接：视频链接（注：文章中有关图片、以及网友的相关评论与总结等内容未标明出处均出自该视频，感谢大家的分享！）
b站up主页：b站up
一、软件开发模型
1、瀑布模型（SDLC）
- 各个活动依照线性顺序连接，只适用于 需求明确 的项目。
- 优点：容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试。
- 不足：客户需求必须十分明确；对项目风险管控能力弱，从而导致项目常常延期完成，开发费用超出预算。
真题链接
- 瀑布模型 适用于： 系统需求是完善的、简明的、一致的，而且可以先于设计和实现完成之前产生的项目。
2、其他经典模型概览
3、 增量模型
- 增量模型融合了瀑布模型的基本成分和原型实现的迭代特征
- 优点：增量模型作为瀑布模型的一个变体具有瀑布模型的所有优点；第一个可交付版本所需要的成本和时间少；风险不大；减少用户需求的变更；运行增量投资，即在项目开始时，可以仅对一个或两个增量投资。
- 不足：可能会造成增量不稳定；增量可能需要重新开发，重新发布；管理发生的成本、进度和配置的复杂性可能会超出组织的能力。
- （注：下图来自《软件设计师教程》（第5版）（褚华、霍秋艳主编，清华大学出版社））
真题链接
- 增量模型：是一种能够快速构造可运行产品的好方法。
4、原型模型、螺旋模型
- 原型模型
- 原型方法比较适合于 用户需求不清、需求经常变化 的情况，能快速、低成本地构建原型。
- （注：下图来自《软件设计师教程》（第5版）（褚华、霍秋艳主编，清华大学出版社））
真题链接
- 为了有效地捕获系统需求，应采用 原型模型。
- 螺旋模型
- 有多个模型的组合，具有多个模型的特征。最显著的特征是：有风险分析，适用于 庞大、复杂并且具有高风险的系统。
- 优点：支持用户需求的动态变化；有助于提高软件的适应能力；降低了软件开发的风险。
- 不足：需要开发人员具有相当丰富的风险评估经验和专门知识；过多的迭代次数会增加开发成本，延迟提交时间。
真题链接
- 某公司计划开发一种产品，技术含量很高，与客户相关的风险也很多，则最适于采用 螺旋 开发过程模型。
5、V模型、喷泉模型与RAD
- V模型
- V模型在瀑布模型基础上将基本问题逐步细化，描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系。（优点和不足与瀑布模型类似）
- 喷泉模型
- 喷泉模型是一种 以用户需求为动力，以对象作为驱动 的模型，适用于 面向对象 的开发方法。开发过程具有 迭代性 和 无间隙性，允许各开发活动交叉、迭代地进行。
- 优点：可以提高软件项目的开发效率，节省开发时间。
- 不足：需要大量的开发人员，不利于项目的管理；要求严格管理文档，使得审核的难度加大。
- （注：下图来自《软件设计师教程》（第5版）（褚华、霍秋艳主编，清华大学出版社））
真题链接
- 喷泉 开发过程模型以用户需求为动力，以对象为驱动，适合于面向对象的开发方法。 开发过程具有 迭代性 和 无间隙性。
6、构件组装模型（CBSD）
7、统一过程（UP/RUP）
4个技术阶段里程碑（技术阶段由主要里程碑所终止）
- 初始阶段：生命周期目标
- 精化阶段：生命周期架构
- 构建阶段：初始运作功能
- 移交阶段：产品发布
真题链接
- （注：下图来自前言中up主视频）
- RUP在每个阶段都有主要目标，并在结束时产生一些制品。在 构建阶段 结束时产生“在适当的平台上集成的软件产品”。
（注：下图来自前言中up主视频）- 统一过程（UP） 的 精化阶段 的里程碑是生命周期架构。关注 需求分析和架构演进。
8、敏捷开发方法
- 极限编程（XP）
- 4大价值观：（见上图）
- 5个原则：（见上图）
- 12个最佳实践：（见上图）
真题链接
- 极限编程（XP） 的价值观包括 沟通、简单性、反馈和勇气。系统的设计要能够尽可能早交付，属于 小型发布 最佳实践。
- 水晶方法（Crystal）
- 水晶法认为 每一个不同的项目都需要一套不同的策略、约定和方法论。
真题链接
- 敏捷开发方法中，水晶方法（Crystal） 认为每一种不同的项目都需要一套不同的策略、约定和方法论。
- 并列争求法（Scrum）
- 并列争求法使用 迭代 的方法，其中，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
真题链接
- 在敏捷过程的开发方法中，并列争求法 使用了迭代的方法，其中，把每段时间（30天）一次的迭代称为一个“冲刺”，并按需求的优先级来实现产品，多个自组织和自治的小组并行地递增实现产品。
（注：下图来自前言中up主视频）
- 自适应软件开发（ASD）（了解即可）
- 敏捷统一过程（AUP）（了解即可）
二、信息系统开发方法
- 面向对象的开发方法：Booch方法、Coad方法 和 OMT方法。
- 面向数据结构的开发方法：Jackson方法。
真题链接
- 采用面向对象方法开发软件的过程中，抽取和整理用户需求并建立问题域精确模型的过程叫 面向对象分析。
- 若用户需求不清晰且经常发生变化，但系统规模不太大且不太复杂，则最适宜采用 原型化 开发方法，对于数据处理领域的问题，若系统规模不太大且不太复杂，需求变化也不大，则最适宜采用 结构化 开发方法。
- （注：下图来自前言中up主视频）
- 软件的 分层式体系结构 把软件系统划分为4层，这4层结构自底向上分别是 系统软件、中间件、业务构件、应用软件。
三、需求的分类
- 基本需求：用户明确提出了要完成的一些需求开发团队必须完成的。
- 期望需求：用户没明确提出，但是默认开发需要完成的。
- 兴奋需求：用户没提出来但是开发也做了（额外的事情涉及到成本问题风险大，要严格控制）。
- 功能需求：考虑系统要做些什么，在何时做，在何时以及如何修改或升级。
- 性能需求：考虑软件开发的技术性指标。例如，存储容量限制、执行速度、响应时间及吞吐量。
- 数据需求：考虑输入、输出数据的格式，接收、发送数据的频率，数据的准确性和精度，数据流量，数据需保持的时间。
真题链接
- “软件产品必须能够在3秒内对用户请求作出响应”属于软件需求中的 非功能需求。
- （注：下图来自前言中up主视频）
系统设计（补）
概要设计
- 设计软件系统总体结构（模块化，确定模块调用关系等）
- 数据结构及数据库设计
- 数据结构的设计
- 数据库的设计
- 概念设计
- 逻辑设计
- 物理设计
- 编写概要设计文档
- 评审
真题链接
- 确定软件的模块划分及模块间的调用关系是 概要设计 阶段的任务。
- 在 概要设计 阶段选择适当的解决方案，将系统分解为若干个子系统，建立整个系统的体系结构。
- （注：下图来自前言中up主视频）
- 软件工程的基本要素包括方法、工具和 过程。
- （注：下图来自前言中up主视频）
- （注：下图来自前言中up主视频）
- （注：下图来自前言中up主视频）
详细设计
在概要设计基础上对各模块内部进行设计等，例如模块内算法设计、数据结构设计等，了解即可。
四、结构化设计
见【软件设计师-从小白到大牛】上午题基础篇：第五章 结构化开发方法
五、软件测试
1、测试原则与类型
- 系统测试阶段的测试目标来自于需求分析阶段。
真题链接
- 一个成功的测试能发现至今未发现的错误。
- 在设计测试用例时，应遵循 不仅要设计有效合理输入，也要包含不合理、失效的输入 原则。
- 在软件开发过程中，系统测试阶段的测试目标来自于 需求分析 阶段。
- 一个项目为了修正一个错误而进行了变更。但这个错误被修正后，却引起以前可以正确运行的代码出错。回归测试 最可能发现这一问题。
- 在改正当前故障的同时可能会引入新的故障，这时需要进行 回归测试。
- 软件调试的任务就是根据测试时所发现的错误，找出原因和具体的位置，进行改正。其常用的方法中，归纳法 是指从测试所暴露的问题出发，收集所有正确或不正确的数据，分析它们之间的关系，提出假想的错误原因，用这些数据来证明或反驳，从而查出错误所在
2、测试用例设计
- 不好的测试用例：用例中每个数据都不符合测试条件，即输入的数据均是不合法的。（在设计测试用例时，应当包括合理的输入条件和不合理的输入条件）。
- 黑盒测试 技术：等价类划分、边界值分析、错误推测 和 因果图 等。
- 白盒测试（由弱到强）：
- 语句覆盖：每条语句至少执行一次。
- 判定覆盖（分支覆盖）：每个判定表达式至少获得一次“真”值和“假”值。
- 条件覆盖：每一判定语句中每个逻辑条件的各种可能的值至少满足一次（即判定表达式中的每个条件（以
&&、||连接的所有条件））。 - 判定条件覆盖：判定中每个条件的所有可能取值（真/假）至少出现一次，并使每个判定本身的判定结果（真/假）也至少出现一次。
- 条件组合覆盖：每个判定中条件的各种可能值的组合都至少出现一次（每个条件的真假组合至少出现一次）。
- 路径覆盖：覆盖被测试程序中所有可能的路径。
- 伪代码转流程图：
- （注：下图来自《Java语言程序设计》（陈俊杰、相洁主编，高等教育出版社））
- （注：下图来自《Java语言程序设计》（陈俊杰、相洁主编，高等教育出版社））
- （注：下图来自《Java语言程序设计》（陈俊杰、相洁主编，高等教育出版社））
- 黑盒测试：只知道输入什么，输出是什么。
- 白盒测试：透明的，可看到设计内部的。
- 边界值分析选取的数据应为4个：恰好等于边界值的两个区间端点的2个数据和稍小于边界 值、稍大于边界值的2个数据。
- 错误推测法：更多的是基于经验和直觉来推测可能存在的错误。
真题链接
- 白盒测试技术中，路径覆盖法往往能比语句覆盖发现更多的错误。
- 某系统重用了第三方组件（但无法获得其源代码），则应采用 黑盒测试 对组件进行测试。
- 使用白盒测试方法时，应根据 程序的内部逻辑 和指定的覆盖标准确定测试数据。
3 、测试阶段
- 自顶向下集成测试：不需要编写驱动模块，需要编写桩模块。
- 自底向上集成测试：不需要编写桩模块，需要编写驱动模块。
- （注：下图来自前言中up主视频）
- 一次性组装：时间快 。
- 增量式组装：稳妥，但是花时间长。
- Alpha测试（α测试）：针对产品，实验环境，开发环境进行测试。
- Beta测试（β测试）：针对产品，由用户在本地计算机去使用它。
4、McCabe复杂度
三种计算方法：
- 线性无关的区域数等于环形时间复杂度
- V(G)=E-N+2（E是流图中边的条数，N是结点数）
- V(G)=P+1（P是流图中判定结点的数目）
- 公式可记为：V(G)=弧-节点+2（或n等于node,节点的意思，来帮助记忆或区分）。
- （注：下图来自前言中up主视频）
V=弧数-结点数+2（V也等于闭合区域数+1）（使用第一个公式时注意，两个结点之间的边才算入总弧数）
六、系统运行与维护
- 软件文档
- （注：下图来自前言中up主视频）
- 软件维护：
- 正确性维护（改正性维护）：改正错误（改正在系统开发阶段已发生而测试阶段尚未发现的错误）。
- 适应性维护：适应变化，进行修改（使应用软件适应信息技术变化和管理需求变化而进行的修改）。
- 完善性维护（改善性维护）：扩充功能，改善性能（对已有的软件系统增加一些系统分析和设计阶段中没有规定的功能与性能特征）。
- 预防性维护：主动预防，增新功能（主动增加预防性的新功能，以使应用系统适应各类变化而不被淘汰）。
- 可靠性、可用性、可维护性
- （注：下图来自前言中up主视频）
（可靠性：无失效运作概率。可用性：正确运行。可维护性：规定的过程和资源完成维护活动。）
真题链接
- 逆向工程从源代码或目标代码中提取设计信息，通常在原软件生命周期的
软件维护 阶段进行。- 在采用面向对象技术构建软件系统时，很多敏捷方法都建议的一种重要的设计活动是 重构，它是一种重新组织的技术，可以简化构件的设计而无须改变其功能或行为。
- 软件工程每一个阶段结束前，应该着重对可维护性进行复审。在系统设计阶段的复审期间，应该从 容易修改、模块化和功能独立的目的 出发，评价软件的结构和过程。
- （注：下图来自前言中up主视频）
- （注：下图来自前言中up主视频）
- （注：下图来自前言中up主视频）
- 基于构件的软件开发，强调使用可复用的软件“构件”来设计和构建软件系统，对所需的构件进行合格性检验、适应性修改，并将它们集成到新系统中。
- 系统可维护性的评价指标：可理解性、可测试性、可修改性。
- 文档是软件可维护性的决定因素。可维护性是所有软件都应具有的基本特点，必须在开发阶段保证软件具有可维护性的特点。在软件工程的每一个阶段都应考虑并提高软件的可维护性，在每个阶段结束前的技术审查和管理复查中应该着重对可维护性进复审。
- 软件 可靠性 是指一个系统在给定时间间隔内和给定条件下无失效运行的概率。
七、软件过程改进
1、能力成熟度模型（CMM）（重点，主要记忆各阶段关键词，可以区分各阶段）
CMM将软件过程改进分为以下5个成熟度级别：
- 初始级（第一级）：软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用。
- 可重复级（第二级）：建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。
- 已定义级（第三级）：管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。
- 已管理级（第四级）：制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。
- 优化级（第五级）：加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。
真题链接
- CMM第三级（已定义级）的核心是 使用标准开发过程（或方法论）构建（或集成）系统。
- CMM第四级（已管理级）的核心是 对软件过程和产品都有定量的理解和控制。重点关注 产品和过程质量。
2、能力成熟度模型集成（CMMI）（重点，主要记忆各阶段关键词，可以区分各阶段）
阶段式模型（了解）
- 初始的：过程不可预测且缺乏控制
- 已管理的：过程为项目服务
- 已定义的：过程为组织服务
- 定量管理的：过程已度量和控制
- 优化的：集中于过程改进
连续式模型（一般考这个）
- CL0（未完成的）：过程域未执行或未得到CL1中定义的所有目标
- CL1（已执行的）：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品
- CL2（已管理的）：其共性目标集中于已管理的过程的制度化
- CL3（已定义级的）：其共性目标集中于已定义的过程的制度化，关注过程的组织标准化和部署。
- CL4（定量管理的）：其共性目标集中于可定量管理的过程的制度化
- CL5（优化的）：使用量化（统计学）手段改变和优化过程域，以满足客户要求的改变和持续改进计划中的过程域的功效。
真题链接
- CMMI能力等级3主要关注过程的 组织标准化和部署。
- CMMI中 CL1（已执行的） 的共性目标是 过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。
- CMMI中 CL5（优化的） 的共性目标是 使用量化（统计学）手段改变和优化过程域，以应对客户要求的改变和持续改进计划中的过程域的功效。
八、项目管理
1. Gantt图（甘特图）
- （注：下图来自前言中up主视频）
- PERT图、项目活动图（必考题！！！）
-
（注：下图来自前言中up主视频）
-
最早时刻：任务与任务之间单指向单指出，直接用前面的任务的最早时刻+任务持续时间=后面任务的最早时刻。若一个任务被多个任务指向，则最早时刻取多个任务完成时间的最大值。（最早时刻从前往后推（加上任务持续时间））
-
最迟时刻：任务与任务之间单指向单指出，直接用后面的任务的最迟时刻-任务持续时间=前面任务的最迟时刻。若一个任务指向多个任务，则最迟时刻取多个任务最迟时刻的最小值。（最迟时刻最后往前推（减去任务持续时间））
-
松弛时间：任务与任务之间单指向单指出，直接用某个任务的最迟时刻-其最早时刻即为松弛时间。若一个任务多指向（指出）需要分别来用不同任务的最迟时刻来分别计算其松弛时间（各路径上的最迟时刻-该任务的最早时刻）。
-
关键路径：松弛时间为0的完成整个工程的所有任务（从后往前推，按最早时刻来推，如果后一个时刻减去路径上任务的持续时间等于前一个任务的最早时刻，则该任务在关键路径上）。
-
关键路径上的任务其最早时刻=最迟时刻，即其松弛时间为0。
-
项目活动图：
-
（注：下图来自前言中up主视频）
[也可以直接求出所有从起点到终点的路径权值之和的最大者，该路径即为关键路径]。 -
缩短关键路径上的活动的持续时间才能缩短整个项目的工期。
真题链接
- 进度安排的常用图形描述方法有Gantt图和PERT图。Gantt图不能清晰地描述 各任务之间的依赖关系。
- 使用PERT图进行进度安排，不能清晰地描述 各任务之间的并行情况。
正确答案：D、C
线上的数字：表示耗时。
先正推最早开始时间，再逆推回来事件6是时间：15-4-1。
如图
-
沟通路径：
-
无主程序员（题目未提主程序员即为该情况）：n个人沟通路径最多与n(n-1)/2条（枚举每个人都要和剩下的人有路径，第一个人需要有n-1条路径，最后一个人不需要任何路径）。
-
主程序员，普通程序员（总共n个人，1个主程序员，n-1个普通程序员）：只需要n-1条沟通路径（只需要每个普通程序员和主程序员之间有沟通路径即可）。
-
（注：下图来自前言中up主视频）
风险管理
- 一般认为软件风险包含两个特性：不确定性 和 损失。不确定性是指风险可能发生也可能不发生；损失是指如果风险发生，就会产生恶性后果。
- 项目风险：指预算、进度、人员（聘用职员及组织）、资源、利益相关者、需求等方面的潜在问题以及它们对软件项目的影响。项目复杂度、规模及结构不确定性也属于项目风险因素。（项目风险威胁到项目计划）
- 技术风险：指设计、实现、接口、验证和维护等方面的潜在问题（技术风险威胁到要开发软件的质量及交付时间）
- 商业风险：（威胁到要开发软件的生存能力）
- 市场风险。（开发了一个没有人真正需要的优良产品或系统）
- 策略风险。（开发的产品不再符合公司的整体商业策略）
- 销售风险。（开发了一个销售部门不知道如何去销售的产品）
- 管理风险。（由于重点的转移或人员的变动而失去了高级管理层的支持）
- 预算风险。（没有得到预算或人员的保证）
- 风险曝光度（风险显露度）
整体的风险显露度（曝光度）（Risk Exposure， RE）可由下面的关系确定：
RE=P×C（其中，P是风险发生的概率，C是风险发生时带来的项目成本。）
风险是针对自身项目而言的。
真题链接
- 对风险排优先级是根据 风险的曝光度 来进行的，曝光度等于风险的产生后果乘以风险发生的概率。
- 软件风险一般包含 不确定性和损失。（不确定性是指风险可能发生也可能不发生；损失是指如果风险发生，就会产生恶性后果）。
- 风险预测从两个方面评估风险，即 风险发生的可能性 以及 风险发生所产生的后果。
- 在软件开发过程中进行风险分析时，风险控制 活动的目的是辅助项目组建立处理风险的策略，有效的策略应考虑风险避免、风险监控、风险管理及意外事件计划。
- 若软件项目组对风险采用主动控制方法，则 风险避免 是最好的风险控制策略。
- 定义风险参照水准是 风险评估 活动常用的技术。
- 项目复杂性、规模和结构的不确定性属于 项目 风险。
- 某个项目在开发时采用了不成熟的前沿技术，由此带来的风险属于 技术 风险。
- 风险的优先级通常是根据 风险暴露（Risk Exposure） 设定。
- 确定构件软件系统所需要的人数时，无需考虑 系统的市场前景。
- （注：下图来自前言中up主视频）
软件项目估算（补）
- 基本COCOMO模型：静态单变量模型
- 中级COCOMO模型：静态多变量模型
- COCOMOII模型
- 应用组装模型（使用对象点）
- 早期设计阶段模型（使用功能点，功能点可以转化为代码行）
- 体系结构阶段模型
- 和所有的软件估算模型一样，COCOMO II模型也需要使用规模估算信息，在模型层次结构中有3种不同的规模估算选择：对象点、功能点和代码行。应用组装模型使用的是对象点；早期设计阶段模型使用的是功能点，功能点可以转化为代码行。
真题链接
- 基本COCOMO 软件成本估算模型是一种静态单变量模型，用于对整个软件系统进行估算。
- 成本估算时，COCOMO II 方法以规模作为成本的主要因素，考虑多个成本驱动因子。该方法包括三个阶段性模型，即应用组装模型（对象点）、早期设计阶段模型（功能点）和体系结构阶段模型（代码行）。
软件配置管理（补）
- （注：下图来自前言中up主视频）
软件质量（补）
软件质量特性
- （注：下图来自希赛网）
- （注：下图来自《软件设计师教程》（第5版）（褚华、霍秋艳主编，清华大学出版社））
真题链接
- 根据ISO/IEC 9216软件质量度量模型定义，一个软件的时间和资源质量子特性属于 效率 质量特性。
- 将每个用户的数据和其他用户的数据隔离开，是考虑了软件的 功能性 质量特性。
- 根据ISO/IEC 9216软件质量模型中对软件质量特性的定义，可维护性质量特性的 易测试性 子特性是指与为确认经修改软件所需努力有关的软件属性。
- 在ISO/IEC 9216软件质量模型中，软件质量特性 功能性 包含质量子特性安全性。
- 软件质量属性中，吞吐量 是指软件每分钟可以处理多少个请求。
软件评审
该部分不常考，记忆真题知识点即可。
真题链接
- 正式技术评审的目标是 发现软件中的错误。
软件容错技术
容错的一般方法（了解、记忆真题知识点即可）：
- 结构冗余
- 静态冗余
- 动态冗余
- 混合冗余
- 信息冗余
- 时间冗余
- 冗余附加技术
- （注：下图来自前言中up主视频）
真题链接
- 冗余技术通常分为4类，其中 结构冗余 按照工作方法可以分为静态、动态和混合冗余。