本人学习zst_2001的课程总结如下链接：zst_2001的个人空间_哔哩哔哩_Bilibili
目录
伪代码+白盒测试+ McCabe度量法（详细请b站搜索zst_2001)
CMM：
CMM将软件过程改进分为以下5个成熟度级别 09-18年 重点是：背
1、初始级：软件过程的特点是杂乱无章的，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄核心人物的作用。（成熟度：低）
2、可重复级：建议了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。Ps：（跟踪）
3、已定义级：管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。Ps:（标准）
4、已管理级：制定了软件过程和产品的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。Ps：（产品质量）
5、优化级：加强了定量分析，通过来自过程质量反馈和来自新观念，新技术的反馈使过程能不断持续地改进。Ps：（改进）（成熟度：高）
能力成熟度模型集成（CMMI）10年-18年
CMMI：
CMMI提供了两种表示方法：阶段式模型和连续模型
阶段式模型 （从未考过，了解即可）
初始的：过程不可预测且缺乏控制
已管理的：过程为项目服务
已定义的：过程为组织服务
定量管理的：过程已度量和控制
优化的：集中于过程改进
连续式模式 （重点）
CL0（未完成的）：过程域未执行或CL1中定义的所有目标。
CL1（已执行的）：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。（仅考一次，原概念）
CL2（已管理的）：其共性目标集中于已管理的过程的制度化。
CL3（已定义级的）：其共性目标集中于已定义过程的制度化。
CL4（定量管理的）：其共性目标集中于定量管理的过程的制度化。
CL5（优化的）：使用量化（统计学）手段改变和优化过程域、以满足客户要求的改变和持续改进计划中的过程域的功效。（仅考一次，原话）
软件可靠性、可用性、可维护性：
软件可靠性、可用性和可维护性 （11、16、20、21年考过）（仅考过一次概念，其他全部考公式，务必要记得 可靠性是TF、可用性是BF、可维护性是TF）
可靠性是指一个系统对于给定的时间间隔内、在给定条件下无失效运行的概率。
可以用MTTF/（1+MTTF）来度量，其中MTTF为平均无故障时间。
（简单来记公式就是可靠性是TF）
可用性是在给定的时间点上，一个系统能够按照规格说明正确运作的概率。
可以用MTBF/（1+MTBF）来度量，其中MTTF为平均失效间隔时间。
（简单来记公式就是可用性是BF）
可维护性是在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成维护活动的概率。
可以用1/（1+MTTR）来度量，其中MTTR为平均修复时间。
（简单来记公式就是可维护性是TR）
沟通路径
公式：n*（n-1）/2 从左往右算
例：10各成员 10*9/2=45
软件过程模型
瀑布模型：
瀑布模型：它是以文档作为驱动、适合于软件需求很明确的软件项目的模型（10-16年考过）
（一般都是说具备什么开发经验、改系统什么，已经做过一次，那么需求就很明确了）
瀑布模型的优点是，容易理解，管理成本低；强调开发的阶段早期计划及需求调查和产品测试。不足之处是，客户必须能够完整、正确和清晰地表达他们的需求；
V模型：（不考，以干扰选项出现）
增量模型：
增量模型：12-18、21考过
1、融合了瀑布模型的基本成分和原型，可以将需求分段为一系列增量产品，第一个增量往往是核心的产品。
2、增量模型具有瀑布模型的所有优点，他还有一下的优点：第一个可交付版本所需要的成本和时间很少，开发由增量表示的小系统所承担的风险大不，由于很快发布第一版本，因此可以减少用户需求的变更，不必等到整个系统开发完成就可以使用。
演化模型：
演化模型：软件开发人员需要一种专门应对不断演变的软件产品的过程模型，演化模型是迭代的过程，使用软件开发人员能够逐步开放出更完整的软件版本。
演化模型：特别适用于对软件需求缺乏准确认识的情况（仅18年考）
原型模型：
原型模型：比较适合于用户需求不清、需求经常变化的情况，当系统规模不是很大，也不是太复杂时，采用这个方法比较好。（有效地捕获系统需求）
螺旋模型：
螺旋模型：螺旋模型将瀑布模型（需求）和演化模型（迭代更新）结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。
螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。
螺旋模型强调风选分析，使得开发人员和用户对每个演化层出现的风险有所了解，因此特别适用于庞大、复杂并且具有高风险的系统。
螺旋模型支持用户需求的动态变化，另外过多的迭代次数会增加开发成本，延迟提交时间。
喷泉模型：
喷泉模型：是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。
喷泉模型克服了瀑布模型不支持软件重用和多项开发活动的集成的局限性
喷泉模型中的开发活动常常需要重复多次，在迭代过程中不断的完善软件系统
各开发活动之间不存在明显的边界（喜欢这句话）
（11、15、20年考过）
敏捷方法（10-21）
极限编程XP：
4大价值：沟通、简单性、反馈和勇气
5大原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
12个最佳实践：
计划游戏（快速制定计划、随着细节的不断变化而改善）
小型发布（系统的设计要能够尽可能早地交付）
隐喻（先找到合适的比喻传达信息）
简单设计（只处理当前的需求，使设计保持简单）
测试先行（先写测试代码，然后再编写程序）
重构（重新审视需求和设计，重新明确地描述他们以符合新的和现有的需求）
结对编程（可以按日甚至按小时为客户提供可运行的版本，两人一起编程）
每周工作40小时
现场客户
编码标准
水晶法：（重点）
水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论。
并列争求法：（重点）
使用迭代的方法，其中，把每30天一次的迭代称为一个冲刺。
敏捷统一过程（AUP）：
采用在大型上连续以及在小型上迭代的原理来构造软件系统，采用经典的UP阶段性活动，即初始化、精化、构造和转换。
IS0 IEC 9126 软件质量特性：
（近10年都考 重点是背质量特性包含什么子特性）
功能性（质量特性）：与一组功能及其指定的性质的存在有关的属性，功能是指定满足规定或隐含需求的那些功能。
功能性包含以下质量子特性：
1、适应性：与对规定任务能否提供一组以及这组功能是否适合额有关的。
2、准确性：与能够得到正确或相符的结果或效果有关的软件属性。
3、互用性：与其他指定系统进行交互操作的能力相关的软件属性。
4、依从性：使软件服从有关等等标准、约定、法规及类似规定的软件属性。
5、安全性：与避免对程序及数据的非授权故意或意外访问的能力有关的软件属性。
可靠性（质量特性）：与规定的一段时间内规定的条件下软件维持在其性能水平有关的能力。
可靠性包含以下质量子特性：
1、成熟性：与由软件故障引起失效的频度有关的软件属性。
2、容错性：与在软件错误或违反指定接口的情况下维持指定的性能水平能力有关的能力。
3、易恢复性：与在故障发生后，重新建立其性能水平并恢复受影响数据的能力，以及为达到此目的所需的时间和努力有关的软件属性。
易使用性（质量特性）与为使用所需的努力和由一组规定或隐含的用户对这样使用所做的个别评价有关的一组属性。
易使用性包含以下质量子特性：
1、易理解性：与用户为理解逻辑概念及其应用所付出的劳动有关的软件属性
2、易学性：与用户为学习及其应用所付出的努力相关的软件属性。
3、易操作性：与用户为进行操作和操作控制所付出的努力有关的软件属性。
效率（质量特性）：在规定条件下，与软件的性能水平与所用资源之间的关系有关的软件属性。
1、效率包含以下质量子特性：
2、时间特性：与响应和处理时间以及软件执行其功能时的吞吐率有关的软件属性。
3、资源特性：与软件执行其功能时，所使用的资源量以及使用资源的持续时间有关的软件属性。
可维护性（质量特性）：与进行规定的修改所需要的努力有关的一组属性。
可维护性包含以下质量子特性：
1、易分析性：与诊断缺陷或失效原因，或为判定待修改的部分所需努力有关的软件属性。
2、易改变性：与进行修改、排错或适应环境变换所需努力有关的软件属性。
3、稳定性：与修改造成未预料效果的风险有关的软件属性。
4、易测试性：为确认修改软件所需要努力有关的软件属性。
可移植性（质量特性）：与软件可从某一环境的能力有关的一组属性。
可移植性包含以下质量子特性
1、适应性：与软件转移到不同环境时的处理或手段有关的软件属性。
2、易安装性：与在指定环境下安装软件所需要努力有关的软件属性。
3、一致性：使软件服从与可移植性有关的标准或约定的软件属性。
4、易替代性：与一软件在该软件环境中来替代指定的其他软件的可能和努力有关的软件属性。
系统可维护性评价指标
1、可理解性
2、可测试性
3、可修改性
软件维护内容（常考2、3）09-21年
1、正确性维护：改正在系统开发阶段已发生而系统测试阶段尚未发生的错误。（修改错误）
2、适应性维护：使应用软件适应信息技术变化和管理需求变化而进行的修改。（需求变化）
3、完善性维护：为扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些系统分析和设计阶段中没有规定的功能性与性能特征。（扩展功能，改善性能能改善系统）
4、预防性维护：为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应增加预防性的新功能，以使应用系统适应各类变化而不被淘汰。（改进软件，防止给淘汰）
软件项目估算
(考过4题)
COCOMO估算模型
1、基本COCOMO模型：是一种静态单变模型。
2、中级COCOMO模型：是一种静态多变模型。
3、详细COCOMO模型：它将软件系统分为系统、子系统和模块3个层次。（不用背）
COCOMOII模型：
分为三个阶段：
1、应用组装模型：对象点
2、早期设计阶段模型：功能点
3、体系结构阶段模型：代码行
软件配置管理：
软件配置管理：考过3次 10、15、17年
主要目标包括：变更标识、变更控制、版本控制、确保变更正确的实现、变更报告。
主要内容包括：版本管理、配置支持、变更支持、过程支持、团队支持、变化报告、审计支持。
上下为两个不同的版本：
主要内容包括：软件配置标识、变更管理、版本控制、系统建立、配置审核、配置状态报告。
配置数据库分为以下三类（考过一次）
1、开发库
2、受控库
3、产品库
软件评审 （15年后没有考过）
详细请看书 304页
软件容错（14年后没有考过）
详细请看书 306页
软件维护工具
1、版本控制工具
2、文档分析工具
3、开发信息库工具
4、逆向工程工具（重点，经常问属不属于软件维护工具）
5、再工程工具
系统设计 11-21年
概要设计是设计软件系统总体结构
其基本任务是采用某种设计方法，将一个复杂的系统按功能划分成模块，确定每个模块的功能；确定模块直接的调用关系；确定模块之间的接口，即模块之间传递的信息；评价模块结构的质量。
详细设计
对每个模块进行详细的算法设计；
系统测试 10-21年
系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。（为了发现错误，下面是9种测试）
1、应尽早并不断进行测试，测试应贯穿在开发的各个阶段。
2、测试工作应该避免由原开发软件的人或小组承担。
3、在设计测试方案中，不仅要确定输入数据，还要确定预期输出结果。
4、在设计测试方案中，不仅要设计有效、合理的情况，也要包含不合理、失效的输入条件。
5、测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事。
6、严格按测试计划来进行，避免测试的随意性。
7、妥善保存测试计划。
8、测试例子都是精心设计出来的。
9、系统测试阶段的测试目标来自需求分析阶段。
单元测试、集成测试 13、15年后没有考过
详细看书，重点是回归测试。
测试方法 09-19年
测试用例由测试输入数据和与对应的预期输出结果组成。在设计测试用例时，应当包括合理的输入条件和不合理的输入条件（一个错的一个正确的或者两个对的是一个好的用例，两个都是错的就是一个不好的用例）重点
黑盒测试法：
1、等价类划分
2、边界值分析
3、错误推测
4、因果图
McCabe度量法 （十分多，重点）09-21 边-节+2
白盒测试：（重点）
白盒测试也称为结构测试，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要。
逻辑覆盖：
语句覆盖：每个语句都要执行一次 （最弱）
图中 Y真 N假
判定覆盖：每个分支条件真假都要取一次
条件覆盖：判定语句中的真假都要满足一次 逻辑条件与或非
判定条件覆盖/分支覆盖：
条件组合覆盖：
路径覆盖：覆盖所有路径（重点考）最强
1370
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
