软件工程概述 软件工程指的是应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件 问题的工程，目的是提高软件生产率、提高软件质量、降低软件成本。
概述：
软件开发模型：指导软件开发的体系
需求分析确定软件要完成的功能及非功能性要求；
概要设计将需求转化为软件的模块划分，确定模块之间的调用关系；
详细设计将模块进行细化，得到详细的数据结构和算法；
编码根据详细设计进行代码的编写，得到可以运行的软件，并进行单元测试。
1 CMM
五个成熟度级别
- 初始级
- 可重复级
- 可定义级
- 已管理级
- 优化级
2．能力成熟度模型集成（CMMI）
CMMI提供了两种表示方法：阶段式模型和连续式模型（考）。
（1）阶段式模型。结构类似于CMM，它关注组织的成熟度。CMMI-SE/SW/IPPD 1.1版本中 有五个成熟度等级。
1）初始级：过程不可预测且缺乏控制。
2）已管理级：过程为项目服务。
3）已定义级：过程为组织服务。
4）定量管理级：过程已度量和控制。
5）优化级：集中过程改进。
（2）连续式模型。关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域 能力等级（简称CL）。
基于连续式表述的CMMI 共有6个（0〜5)能力等级，对应于未完成级、已执行级、已管理级、已定义级、量化管理级、优化级。每个能力等级对应到一个一般目标，以及一组一般执行方法和特定方法。
- 能力等级0指未执行过程，表明过程域的一个或多个特定目标没有被满足
- 能力等级1指过程通过转化可识别的输入 工作产品，产生可识别的输出 工作产品，关注于过程域的特定目标的完成
- 能力等级2指过程作为已管理的过程制度化，针对单个过程实例的能力
- 能力等级3指过程作为已定义的过程制度化，关注过程的组织级标准化和部署
- 能力等级4指过程作为定量管理的过程制度化
- 能力等级5指过程作为优化的过程制度化，表明过程得到很好地执行且持续得到改进。
例题：
3、软件过程模型
软件过程模型习惯上称为软件开发模型，它是软件开发全部过程、活动和任务的结构框架。典 型的软件过程有瀑布 模型、增量 模型、演化模型（原型 模型、螺旋 模型）、喷泉模型、基于构件的 开发模型和形式化方法模型等。
3.1 瀑布模型
＃每个阶段末尾都会有评审，评审上一阶段的工作是否达标
优点：容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试。
缺点 ：初期分析需求无法把控，开发末期的结果和客户要求不一致，全盘推翻（不能适应变化的需求）
适用场景 ：需求明确/二次开发/有过经验，用新技术重构也用瀑布
ｖ模型：质量保证活动
例题：
3.2 增量模型
增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，如图所示。
增量：先做出核心，好处在核心模块尽早和用户接触了==（逐步理解需求）==，但是这种模式如何进行模块划分是****难点
（错）很容易把需求划分为一系列增量
- 增量模型的优点：可交付的第一个版本所需要的成本和时间很少 ，开发由增量表示的小系统所 承担的风险不大，由于很快发布了第一个版本，因此可减少用户需求的变更。同时，它也具有瀑布 模型所有的优点。
- 增量模型的缺点：若没有 对用户的变更 要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定 ；若需求不 像早期思考的那样稳定 和完整，那么一些增量就可能需要重新开发或重新发布 ；管理发生的**成本、**进度和配置的复杂性可能会超出组织的能力。
例题：
3.3 原型模型
原型：定义在需求不明确 的情况，初期构建一个简易系统让用户发现问题，探索用户的需求（只应用于需求分析阶段），也可以探索出特殊的软件解决方案
能够迅速开发出一个让用户看得见的系统框架，可以用来支持用户界面设计
不能指导代码优化
原型模型最不适合大规模软件开发
3.4 演化（迭代）模型
相比原型，适用于需求清楚，尽早投入使用，要不断改善的时候
3.5 螺旋模型
最适合大规模开发的模型
将开发活动和风险管理 结合起来，求将风险降到最小并控制风险
有多个模型的特点：瀑布+快速原型
包含维护周期，所以开发和维护之间没有本质区别
引入了风险分析：当某一个事件存在两种或者两种以上的可能性时，才认为该事件存在风险
风险分析是4个不同的活动：风险识别（系统化地确定对项目计划的威胁）、风险预测（两方面评估：发生的可能性和产生的后果）、风险评估（根据发生概率和影响，决定是否影响参考水平值）、风险控制（辅助项目路建立处理风险的策略，有效的策略要考虑风险避免、风险监控和意外事件计划）
喷泉模型与RAD
1.面向对象
2.用户需求为动力 ，对象 作为驱动 ，克服 了瀑布模型不支持软件重用和多项开发活动集成的局限性
3.迭代、无间隙（开发活动之间不存在明显边界）
RAD：快速开发模型，SDLC（瀑布模型）+CBSD（构件化开发模型）
4.可以快速构建应用系统
构件的开发模型
（1）领域工程的目的是构建领域模型、领域基准体系结构和可复用构件库。 （2）应用系统工程的目的是使用可复用构件组装应用系统。
形式化 方法模型 形式化方法是建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机软件形式化 的数学规格说明。
4.、统一过程UP
也称RUP，用例和风险为驱动，以架构为中心，迭代并增量开发
用于大型项目
五个阶段：起始、精化、构建、移交、产生
开发过程包括多次迭代，每次迭代包括：计划、分析、设计、构造、集成、测试、内部发布、外部发布
每个迭代有五个核心工作流
初始：需求
细化：建立架构
构建：开发（产生产品）
β测试：由用户发起的测试 （α测试是在开发环境里做的）
每个阶段达到里程碑的时候代表结束了：
初始 ：生命周期目标（产生一个构想文档 、一个有关用例模型的调查、一个初始的业务用例、一个早期的风险评估 和一个可以显示阶段和迭代的项目计划等制品）
精化 ：生命周期架构 （产生一个补充需求分析 、一个软件架构描述和一个可执行的架构原型等）
构建 ：初始运作功能（产生一个转交到最终用户手中的产品，包括：在适当的平台上集成的软件产品，用户手册，版本描述）
移交 ：产品发布（产生移交给用户产品发布版本）
例题：
5、敏捷开发方法
- 给开发减轻负担
- 适合小型项目
- 随时对接客户
- 大型任务上连续
包括：
- 自适应方法ASD==（6个基本原则）、
- 水晶方法Crystal（每个项目用不同方法）、
- 特征驱动开发
- 并列争球法SCRUM（30天一迭代的冲刺，按需求优先级实现）、
- 极限编程XP（激发创造性、管理负担小）
scrum步骤
- Product Backlog 产品待办事项清单（不包括Refactoring 重构）
- Sprint Backlog Sprint待办事项清单
- Sprint冲刺迭代
选B
极限编程XP
是一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方法，其特性包含在12个最佳实践中。
（1）计划游戏：快速制定计划、随着细节的不断变化而完善；
（2）小型发布：系统的设计要能够尽可能早地交付；
（3）隐喻：找到合适的比喻传达信息；
（4）简单设计：只处理当前的需求使设计保持简单；
（5）测试先行：先写测试代码再编写程序；
（6）重构：重新审视需求和设计，重新明确地描述它们，以符合新的和现有的需求;
（7）结队编程；（编码速度和担任差不多）
（8）集体代码所有制；
（9）持续集成：可以按日甚至按小时为客户提供可运行的版本；
（10）每周工作40个小时；
（11）现场客户；
（12）编码标准。
统一过程的典型代表是RUP，RUP是UP的商业扩展，完全兼容UP，比UP更完整、更详细。 敏捷方法的总体目标是通过"尽可能早地、持续地对有价值的软件进行交付"使客户满意。
敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念，即 敏捷宣言。 常用的方法 ：极限编程（XP）、水晶法（Crystal）、并列争球法（Scrum）、自适应软件开发（ASD）、 敏捷统一过程（AUP）。
敏捷统一过程（AUP）
6、软件需求
信息系统开发方法（四种）结构 化法：流程不灵活，所以被面向对象方法取代了（用来开发结构简单的项目）
原型 法：需求不明确
- 开发人员和管理人员沟通的主要文档是：系统开发计划，包括工作任务分解表、PERT图、甘特图和预算分配表等
- 总体规划和开发合同用于与系统分析人员在系统规划和系统分析阶段的沟通。
- 测试计划用于系统测试人员与系统开发人员之间的沟通。
1. 软件系统文档 是系统建设过程的**"痕迹"** ，是系统维护人员的指南，是开发人员与用户交流的工具。
软件系统文档不仅包括应用软件开发过程中产生的文档，还包括硬件采购和网络设计 中形成的文档；不仅包括有一定格式要求的规范 文档，还包括系统建设过程中的各种来往文件、会议纪要、会计单据等资料 形成的不规范文档。
软件系统文档可以提高软件开发的可见度，提高 软件开发效率，且便于用户理解软件的功能、性能等各项指标。
系统设计为系统制定蓝图， 软件设计模型关注新系统总体结构、代码设计、处理过程、数据结构和界面模型等。对项目范围的关注在软件设计之前。
7、系统设计
系统设计的主要内容 包括新系统总体结构 设计、代码 设计、输出 设计、输入 设计、处理过程 设 计、数据存储 设计、用户界面 设计和安全控制设计等。
常用的设计方法 有：面向数据流的结构化设计方法（SD）、面向对象的分析方法（OOD）。 系统设计包括两个基本的步骤 ：概要设计 、详细设计。
概要设计 主要包括：①软件系统总体结构设计（模块）；②数据结构及数据库设计；③编写概要设计文 档（概要设计说明书、数据库设计说明书、用户手册及修订测试计划）；④评审。
详细设计 主要包括：①对每个模块进行详细设计；②对模块内部 的数据结构 进行设计；③对数据库进行物理设计，即确定数据库的物理结构；④其他设计（代码设计、输入/输出设计、用户界 面设计）；⑤编写详细设计说明书；⑥评审。
需求的分类
设计约束：例如让使用特定语言进行开发
基本需求：用户明确提出的需求
期望需求：用户默认希望做到的需求
兴奋需求：用户也没有觉得要做到的，但是额外做了（不提倡）
结构化设计
调用的深度越深，出错的可能性越大
扇入：自己被调用
扇出：自己调用的
扇入扇出适中
划分模块的原则：作用范围应该在控制范围内
8、系统测试
系统测试系统测试是将已经确认的软件、硬件、外设、网络等其他因素结合在一起，进行各种集成测试和确认测试，主要包括恢复测试、安全性测试、压力测试、性能测试、部署测试。
测试原则与类型
测试不只是从程序编码时开始
回归测试：修改了测试出的bug之后，要把之前测过的重新测
已经发现bug越多的，越要重点测试
测试是用来发现尽可能多的错误，而不能证明没有错误
- 动态测试：用到计算机的
- 静态测试：手动
测试方法
（1）静态测试：被测程序不在机器 上运行，采用人工 检测和计算机辅助静态分析的手段对程 序进行测试，包括人工检测、计算机辅助静态分析。
（2）动态 测试：通过运行程序发现错误，一般采用黑盒测试和白盒测试。
1）黑盒 测试：也称功能测试，在不考虑软件内部结构和特性的情况下，测试软件的外部特性。
2）白盒 测试：也称结构测试，根据程序的内部结构和逻辑 来设计测试用例，对程序的路径和 过程进行测试，检查是否满足设计的需要。
白盒
覆盖技术从弱到强：语句覆盖、判定覆盖（分支覆盖）、条件覆盖、路径覆盖
- 语句 覆盖：所有的程序语句只要经过就可以
- 判断 覆盖：只针对整个判断语句
- 条件 覆盖：在统计所有用例中，每个判断中的每个条件的true和false都有取一次就行（两个条件，用例就可以是TF和FT）
- 路径 覆盖是最高级别：所有可行路径都覆盖
例题：
循环别管次数
McCabe概念：
McCabe度量法是一种基于程序控制流的复杂性度量方法。
McCabe复杂性度量又称环路度量,其计算公式为:
V(g)=m-n+2,其中m和n分别代表图中的边数和顶点数
有向图环路复杂度：有向边数-节点数+2
软件复杂性主要参数：
- 规模 ：代码行数
- 难度：操作数的数目
- 结构 ：程序结构有关的度量
- 智能度：算法难易程度
eg：(2015年上半年试题)若采用白盒测试方法测试以下代码，并满足条件覆盖，则至少需要___个测试用例。采用McCabe度量法算出该程序的环路复杂性为___
cppint find_max(int i, int j, int k){ int max; if(i > j) { if(i > k){ max = i; } else { max = k; } } else { if(j > k) { max = j; } else { max = k; } } return max; }先画出该代码的流程图，如下：
要满足条件覆盖，要求三个判断框的Y和N至少要经过一次，即：1Y2Y，1Y2N，1N3Y，1N3N，至少需要4个测试用例。
根据McCabe度量法环路复杂性公式V(g)=m-n+2,图中m=9,n=7, V(g)=9-7+2=4。
那么答案应是：4个用例，环路复杂度为4。
eg2：
语句覆盖：1条；
复杂度：3，这种直接算闭环比较简单；
测试阶段
- 确认 测试一般是最后一个环节；始于集成测试的结束，那时已测试完单个构件，软件已经组装成完整的软件包，而且 接口错误已被发现和改正。 确认过程的一个重要成分是配置评审，主要检查软件、文档、数据是否齐全、分类有序。
- 单元测试：模块
- 确认测试：测需求
- 系统 测试：性能 ，验证是否按照需求分析中的完成了（测试目标来自需求分析）
- 负载测试：并发
- 强度测试：系统不正常情况下
- 容量 测试：极限值测试
- 三明治 测试策略：结合了自顶向下和自底向上，一次性测试然后继承，缺点是需要写较多的驱动模块和桩模块
- 自顶向下 的优点：较早验证 主要的；只需要一个驱动
- 自底向上优点：较早验证底层 组件，比顶向下效率高，减少了桩的工作量（不用写桩程序）
集成测试通常有以下两种方法：
（1）非增量集成：分别测试各个模块，再将这些模块组合起来进行整理测试。
（2）增量集成：以小增量的方式逐步进行构造和测试。
自顶向下集成测试、自底向上集成测试、回归测试、冒烟测试
调试
（1）试探法：调试人员分析错误的症状，猜测问题所在的位置，一步步试探和分析问题所在。 该方法效率低，适用于结构比较简单的程序。
（2）回溯法：调试人员从发现错误症状的位置开始，人工沿着程序的控制流程往回追踪代码， 直到找出问题根源为止。该方法适用于小型程序。
（3）对分查找法：该方法主要用来缩小错误范围，直到把故障范围缩小到比较容易诊断为止。
（4）归纳法：从测试所暴露的问题出发，收集所有正确、不正确的数据，并分析它们之间的 关系，提出假想的错误原因，用这些数据证明或反驳，从而查出错误所在。
（5）演绎法：根据测试结果，列出可能的错误原因，分析已有的数据，排除不可能和彼此矛 盾的原因。若有多个错误同时存在，就要重新分析，提出新的假设，直到发现错误为止。
系统运行与维护
可维护性评价指标：可理解 性、可测试 性、可修改性
软件系统的可维护性评价指标包括可理解性、可测试性、可修改性、可靠性、可移植性、可使用性和效率
改正 性维护：发现bug后维护
适应 性维护：兼容环境
软件文档：
软件可靠性，可用性，可维护性
eg：
软件质量管理
- 快捷记忆：https://blog.csdn.net/fxq8866/article/details/49534269
- 易使用性：易理解性、易学性、易操作性(没有易分析性，这个属性可维护性)
- 将每个用户的数据隔离开，属于功能性
- 模块结构评审包括：控制流结构、数据流结构、模块结构与功能结构之间的对应关系
- 容错技术：对无法避免的差错，使其影响降到最低
- 冗余技术分为四类：结构冗余、信息冗余、时间冗余、冗余附加技术
- 结构冗余：按照工作方法可以分为静态、动态和混合冗余
- 信息冗余，指的是为了检测或纠正信息在运算或传输中的错误另外加的一部分信息；
- 冗余附加技术，是指为实现上述冗余技术所需的资源和技术。
- （在屏蔽硬件错误的容错技术中，冗余附加技术包含：关键程序和数据的冗余存储：检测、表决、切换、重构、纠错、复算的实现）
- （在屏蔽软件错误的容错技术中，冗余附加技术包含：冗余备份程序的存储和调用、实现错误检测和错误恢复的程序、实现容错软件所需的固化程序）
- 知识冗余：可以通过知识分析得到的数据
软件配置管理
项目估算
得不到精确的估算结果
方法：专家估算方法（收到专家的主观影响）、启发式方法COCOMO模型（参数难以确定）、机器学习（难以训练数据集的特征和相似性）
Wolverton模型：基于成本矩阵，定义不同软件类型和难易成本
COCOMO模型：将规模 视为成本的主要因素，考虑多个成本驱动因子
COCOMO II模型：还考虑了软件开发的不同阶段，包含三个阶段性模型 ，即应用组装模型、早期设计阶段模型和体系结构阶段模型，三种规模估算选择：对象点、功能点、代码行
Gantt图
Pert图
项目计划评审技术图（PERT）
最早时刻：
最晚时刻：
松弛时间：
= 迟-早
eg：
McCall
软件质量模型给出了一个三层模型框架，第一层为质量特性，第二层为评价准则，第 三层为度量指标。
McCall认为软件质量由12个特性组成，分别面向软件产品的运行、修正、转移。
（1） 产品运行：正确性、可靠性、可使用性、效率、完整性、安全性。
（2） 产品修正：可维护性、可测试性、灵活性。
（3） 产品转移：互连性、可移植性、复用性。
1、正确性：系统满足规格说明和用户目标的程度，即在预定环境下能正确地完成预期功能的程度。
2、健壮性：在硬件发生故障、输入的数据无效或操作错误等意外环境下，系统能做出适当响应的程度。
3、效率：为了完成预定的功能，系统需要的计算资源的多少。
4、完整性：对未经授权的人使用软件或数据的企图，系统能够控制（禁止）的程度。
5、可用性：系统在完成预定应该完成的功能时令人满意的程度。
6、风险：按预定的成本和进度把系统开发出来，并且为用户所满意的概率。
7、可理解性：理解和使用该系统的容易程度。
8、可维修性：诊断和改正在运行现场发现的错误所需要的工作量的大小。
9、灵活性：修改或改进正在运行的系统需要的工作量的多少。
10、可测试性：软件容易测试的程度。
11、可移植性：把程序从一种硬件配置和软件系统环境转移到另一种配置和环境时，需要的工作量多少。
12、可再用性：在其他应用中该程序可以被再次使用的程度。
13、互运行性：把该系统和另一个系统结合起来需要的工作量的多少。
软件风险管理
软件风险 软件风险包括两个特性：不确定性和损失。不确定性是指风险可能发生也可能不发生；损失是 指风险发生后会产生恶性后果。 常见的商业风险有：市场风险、策略风险、销售风险、管理风险、预算风险。
风险识别 当识别出已知风险和可预测风险后，项目管理者首先要做的是尽可能回避这些风险，在必要时 控制这些风险。风险因素可以定义为：性能风险、成本风险、支持风险、进度风险。
风险预测 风险预测又称为风险估计，它试图从两个方面评估一个风险：风险发生的可能性或概率；风险 发生后所产生的后果。
风险控制 应对风险最好的办法是主动地避免风险，即在风险发生前分析引起风险的原因，然后采取措施 避免风险的发生。
黄金准则
Theo mandel关于界面设计（人机交互）的三条换黄金准则：
用户操纵控制、减轻用户记忆负担、保持界面一致
管道过滤器体系结构
系统处理数据流的结构
单步数据处理封装在一个过滤器中，数据在过滤器之间的管道传输。
data source（数据源），filter（过滤器）和data sink（数据汇点）三者，使用pipe（管道）进行连接
过滤器视为组件。
管道视为连接件。
管道将一个过滤器的输出传给另一个过滤器的输入。
优点：
- 高内聚低耦合
- 经系统看做过滤器简单合成
- 支持软件复用
- 维护和增强性能简单
- 允许分析吞吐量和死锁
- 支持并行
缺点：
1.数据传输和转化开销大
2.错误处理复杂
后续刷题，写错题