😀前言
随着技术的快速发展，软件已经成为我们日常生活中不可或缺的一部分。从智能手机应用到大型企业系统，软件都在为我们提供便利、增强效率和创造价值。然而，随之而来的是对软件质量的日益增长的关注。软件的质量不仅关乎其功能性和性能，还涉及其可靠性、使用性、可维护性和可移植性。为了更好地理解和评估软件的质量，我们需要一个结构化的方法来描述和测量软件的各种质量特性。本章将深入探讨软件工程的基础知识，包括软件过程、软件开发过程模型、软件测试和软件质量模型等内容
🏠个人主页：尘觉主页
🧑个人简介：大家好，我是尘觉，希望我的文章可以帮助到大家，您的满意是我的动力😉😉
在csdn获奖荣誉: 🏆csdn城市之星2名
💓Java全栈群星计划top前5
🤗 端午大礼包获得者
🥰阿里云专家博主
😉亚马逊DyamoDB结营
💕欢迎大家：这里是CSDN，我总结知识的地方，欢迎来到我的博客，感谢大家的观看🥰
如果文章有什么需要改进的地方还请大佬不吝赐教 先在次感谢啦😊
文章目录
- 软件设计师笔记系列（四）
软件设计师笔记系列（四）
第五章 软件工程基础知识
标记🔺需背诵
软件过程
🔺 1. 能力成熟度模型（CMM）
CMM 将软件过程改进分为以下5个成熟度级别：
1）初始级
软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用。
2）可重复级
建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。
3）已定义级
管理和工程两方面的软件过程已经文档化、标准化 ，并综合成整个软件开发组织的标准软件过程。
4）已管理级
制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。
5）优化级
加强了定量分析，通过来自过程质量 反馈和来自新观念、新技术的反馈使过程能不断持续地改进。
🔺 2. 能力成熟度模型集成（CMMI）
CMMI 提供了两种表示方法：
1）阶段式模型
阶段式模型的结构类似于 CMM，它关注组织的成熟度。
有五个成熟度等级：
- 初始的：过程不可预测且缺乏控制。
- 已管理的：过程为项目服务。
- 已定义的：过程为组织服务。
- 定量管理的：过程已度量和控制。
- 优化的：集中于过程改进。
2）连续式模型
连续式模型关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力能力。
CMMI 中包括6个过程域能力等级：
- CL₀（未完成的）：过程域未执行 或未得到 CL₁ 中定义的所有目标。
- CL₁（已执行的）：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工
作产品，以实现支持过程域的特定目标。 - CL₂（己管理的）：其共性目标集中于己管理的过程的制度化 。根据组织级政策规定过
程的运作将使用哪个过程，项目遵循己文档化的计划和过程描述，所有正在工作的人
都有权使用足够的资源，所有工作任务和工作产品都被监控、控制和评审。 - CL₃（己定义级的)：其共性目标集中于己定义的过程的制度化 。过程是按照组织的剪
裁指南从组织的标准过程集中剪裁得到的，还必须收集过程资产和过程的度量，并用
于将来对过程的改进。 - CL₄(定量管理的)：其共性目标集中于可定量管理的过程的制度化 。使用测量和质量
保证来控制和改进过程域，建立和使用关于质量和过程执行的定量目标作为管理
准则。 - CL₅（优化的)：使用量化（统计学）手段改变和优化过程域 ，以满足客户要求的改变
和持续改进计划中的过程域的功效。
软件过程模型
软件开发过程模型是指为了有效地开发、维护和更新软件系统，提出的一系列步骤、阶段和方法的系统框架，以实现提高软件质量、加快开发速度和降低开发成本的目的。
常见的软件开发过程模型包括瀑布模型、增量模型、演化模型和喷泉模型。
瀑布模型
瀑布模型是一种线性的软件开发过程模型，开发流程严格按照顺序依次进行，每个阶段都必须完成后才能进入下一个阶段。瀑布模型包括需求分析、设计、编码、测试和维护五个阶段。
特点：
- 明确的阶段，每个阶段都有明确可执行的目标
- 任务分工明确，各个阶段的任务可以并行开展
- 阶段间有严格的输入、输出关系
不足：
- 迭代能力不强，回退成本高，变更需求引起全局变化成本高
- 不适用于需求不完全确定的项目、对质量控制要求极高的项目
增量模型
增量模型采用了逐步完善的思路，将软件的开发过程划分为一个个的增量，每个增量都能够独立实现某一或多项功能或特性。在逐步实现的过程中，可以不断根据需求变化来进行迭代，从而保证最终的软件达到客户需求和期望。
特点：
- 采用可迭代的方式，适应需求不断变化的局面
- 可集成性强，增量之间保持一致性
- 开发完一个增量可实现部分投入使用
不足：
- 需求变化频繁，增量之间的界限可能模糊，不便于控制
- 增量标准的确定和成本效益考虑要求高
演化模型
演化模型是一种以进化为中心的软件开发过程模型，侧重于以人的知识和技能为核心，强调在开发过程中不断地学习、改进和重构。演化模型适用于复杂性较高、需求不稳定的软件开发项目。
特点：
- 适应需求频繁变动和较长开发周期的软件开发项目
- 开发人员可不断地矫正和完善软件，可利用先前的成果进行开发
- 风险得到有效控制，软件质量有所提高
不足：
- 开发人员几乎对整个软件的开发掌握程度较低，软件项目的可控性相对较差
- 软件演化过程因为没有严格的阶段，是软件项目能否成功的关键之一
喷泉模型
喷泉模型是一种基于风险管理的软件开发过程模型，强调需要通过精细的风险分析和风险管理来降低软件开发的风险。喷泉模型包含三个阶段：确定性阶段、风险工程阶段和支持性阶段。
特点：
- 考虑风险的因素，强调风险的管理和控制
- 逐步递增开发，先确定重要功能，在不断补充和完善功能
- 每次递增是独立的，能够实现部分投入使用
- 对于需求、设计等方面的变化能够有较好的适应性
不足：
- 开发人员难以准确把握风险，可能导致风险的发生和增加
- 递增过程中缺乏整体性的考虑，可能出现集成困难的情况
- 难以精确评估投资回报，不便于制定成本预算
敏敏方法
敏捷方法是一种反应灵活、拥有高度互动性和以人为本的软件开发方法。它的核心是通过不断地交付成果和及时反馈，来满足客户需求和不断变化的业务环境。以下是敏捷方法中的一些常见实践：
- 极限编程（XP）
- 水晶法（Crystal）
- 并列争求法（Scrum）
- 自适应软件开发（ASD）
- 敏捷统一过程（AUP）
极限编程（XP）
XP 是一种敏捷方法，它注重软件开发过程的可持续性和软件产品的高质量。XP 方法主要包括测试驱动开发、持续集成、设计简单、重构和小步交付等实践，能够提高软件开发的质量和可靠性。
水晶法（Crystal）
Crystal 是一种敏捷方法，它注重团队成员的协作和沟通，强调不同规模和复杂度的软件开发项目需要采用不同的方法。Crystal 方法通过对不同的项目规模和复杂度进行分类，针对性地提供了不同的软件开发模型和方法，能够加强软件开发团队的可持续性和合作精神。
并列争求法（Scrum）
Scrum 是一种敏捷方法，它强调团队的自我管理和创造力，通过不断迭代和反馈来持续提高软件产品的价值。Scrum 过程主要包括产品待办列表、迭代、日常会议、回顾和展示等环节，能够加强团队协作和增强开发效率。
自适应软件开发（ASD）
ASD 是一种敏捷方法，它强调团队自治和边缘化的规划，通过不断探索和实验来寻找最优解。ASD 方法主要包括多个迭代周期和完整开发周期的规划，允许团队自行确定工作重点，增强团队成员的创造力和参与程度。
敏捷统一过程（AUP）
AUP 是一种敏捷方法的变体，注重详细和规范的迭代过程和文档，同时强调迭代周期的规划和管理。AUP 方法主要包括迭代周期和完整开发周期的明确，规范化的需求、设计和测试活动，能够提高软件开发的整体效率和质量。
概要设计
- 设计软件系统总体结构
- 确定每个模块的功能
- 确定模块之间的调用关系
- 确定模块之间的接口
- 数据结构及数据库设计
- 编写概要设计文档
- 评审
详细设计
- 对每个模块进行详细的算法设计
- 对模块内的数据结构进行设计
- 对数据库进行物理设计
- 其他设计
- 编写详细设计说明书
- 评审
系统测试
意义 ：系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。
目的：测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。
系统测试原则
- 应尽早并不断地进行测试。
- 测试工作应该避免由原开发软件的人或小组承担。
- 在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期输出结果。
- 在设计测试用例时，不仅要设计有效、合理的输入条件，也要包含不合理、失效的输入条件。
- 在测试程序时，不仅要检验程序是否做了该做的事，还要校验程序是否做了不该做的事。
- 严格按照测试计划来进行，避免测试的随意性。
- 妥善保存测试计划、测试用例。
- 测试例子都是精心设计出来的。
- 系统测试阶段的测试目标来自于需求分析阶段。
单元测试
- 单元测试的测试内容
- 模块接口。测试模块的数据流可以正确地流入、流出。
- 局部数据结构。
- 重要的执行路径。
- 出错处理。
- 边界条件。
- 单元测试过程
- 驱动模块。
- 桩模块。
集成测试
- 自顶向下集成测试
自顶向下集成测试是一种构造软件体系结构的增量方法。
- 自底向上集成测试
自底向上集成测试就是从原子模块（程序结构的最底层构件）开始进行构造和测试。
动态测试
黑盒测试
- 等价类划分：有效等价类、无效等价类
- 边界值分析
- 错误推测
- 因果图
白盒测试
- 逻辑覆盖。逻辑覆盖考察用测试数据运行被测程序时对程序逻辑的覆盖程度
逻辑覆盖标准有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖
- 循环覆盖
- 基本路径测试
系统维护概述
🔺 1. 系统可维护性概念
系统是否能被很好地维护，可以用系统的可维护性这一指标来衡量。
系统可维护性的评价指标
- 可理解性。
- 可测试性。
- 可修改性。
编写高质量文档可以提高软件开发的质量。
文档也是软件产品的一部分，没有文档的软件就不能称之为软件。
软件文档的编制在软件开发工作中占有突出的地位和相当大的工作量高质量文档对于软件产品的效益有着重要的意义。
总的来说，软件文档只好不坏，选项中说软件文档不好的就是不正确的。
🔺 2.系统维护的内容及类型
软件维护：
-
正确性维护。正确性维护是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。
-
适应性维护。适应性维护是指使应用软件适应信息技术变化和管理需求变化而进行的修改。
-
完善性维护。这是为扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。
-
预防性维护。为了改进应用软件的可靠性和可维护性，为了适应未来的软/硬件环境的变化。
可靠性、可用性利可维护性是软件的质量属性，软件工程中，用 0-1 之间的数来度量。
可靠性是指一个系统对于给定的时间间隔内、在给定条件下无失效运作的概率。可以用 MTTF/(1+MTTF) 来度量，其中 MTTF 为平均无故障时间。
可用性是在给定的时间点上，一个系统能够按照规格说明正确运作的概率。可以用 MTBF/(1+MTBF) 来度量，其中 MTBF 为平均失效间隔时间。
可维护性是在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完
成维护活动的概率。可以用 1/(1+MTTR) 来度量，其中 MTTR 为平均修复时间。
软件质量模型
#### 为什么软件质量模型重要？
- 共同的语言：它为所有涉及软件开发的各方提供了一个共同的语言和参考，从而确保了对质量的共同理解。
- 质量评估：它提供了一个框架，用于评估软件产品的质量，从而帮助识别潜在的问题和改进点。
- 质量保证：通过使用这些模型，组织可以确保其软件满足既定的质量标准。
- 决策支持：它为管理层提供了有关软件质量的关键信息，从而支持更好的决策。
😄总结
经过本章的学习，我们对软件工程的基础知识有了更深入的了解。我们明白了软件开发不仅仅是编写代码，更多的是遵循一系列的过程和方法来确保软件的质量和可靠性。软件测试是确保软件质量的关键环节，而软件质量模型为我们提供了一个评估和改进软件质量的框架。随着技术的不断进步，软件工程的方法和工具也在不断发展和完善。但不变的是，软件的质量始终是我们追求的目标。希望通过本章的阅读，大家能够更好地理解和应用软件工程的知识，为创造高质量的软件产品做出贡献。
😁热门专栏推荐
想学习vue的可以看看这个
等等等还有许多优秀的合集在主页等着大家的光顾感谢大家的支持
🤔欢迎大家加入我的社区 尘觉社区
文章到这里就结束了，如果有什么疑问的地方请指出，诸佬们一起来评论区一起讨论😁
希望能和诸佬们一起努力，今后我们一起观看感谢您的阅读🍻
如果帮助到您不妨3连支持一下，创造不易您们的支持是我的动力🤞