文章目录
- 一、前言
- 二、基础知识点
-
- [2.1 软件危机](#2.1 软件危机)
- [2.2 软件生命周期](#2.2 软件生命周期)
- 三、软件过程模型（论文）
-
- [3.1 瀑布模型](#3.1 瀑布模型)
- [3.2 原型模型](#3.2 原型模型)
- [3.3 螺旋模型](#3.3 螺旋模型)
- [3.4 敏捷模型](#3.4 敏捷模型)
- [3.5 软件统一过程模型](#3.5 软件统一过程模型)
- [3.6 软件成熟度模型](#3.6 软件成熟度模型)
- [3.7 软件成熟度模型集成](#3.7 软件成熟度模型集成)
- 四、需求工程
- 五、软件测试
-
- [5.1 根据程序执行状态分类](#5.1 根据程序执行状态分类)
- [5.2 根据是否关注内部实现分类](#5.2 根据是否关注内部实现分类)
- [5.3 根据程序执行方式分类](#5.3 根据程序执行方式分类)
- [5.4 根据测试阶段分类](#5.4 根据测试阶段分类)
- 六、项目管理
-
- [6.1 软件进度管理](#6.1 软件进度管理)
- [6.2 软件配置管理](#6.2 软件配置管理)
- [6.3 软件质量管理](#6.3 软件质量管理)
- [6.4 软件风险管理](#6.4 软件风险管理)
一、前言
笔记目录大纲请查阅：【软考速通笔记】系统架构设计师------导读
二、基础知识点
2.1 软件危机
- 软件开发进度难以预测
- 软件开发成本难以控制
- 软件功能难以满足用户期望
- 软件质量无法保证
- 软件难以维护
- 软件缺少适当的文档资料
2.2 软件生命周期
- 需求分析
- 软件设计
- 软件开发
- 运行维护
- 直到被淘汰
三、软件过程模型（论文）
3.1 瀑布模型
瀑布模型是一种传统的软件开发模型，结构化开发方法，特点是因果关系紧密相连，前一个阶段工作的输出结果是后一个阶段工作的输入。
缺点：
- 需求难以一次确定
- 变更的代价高
- 结果难以预见
- 各阶段工作不能并行
瀑布模型的流程是
- 需求分析
- 系统设计
- 程序设计
- 编码实现
- 单元测试
- 集成测试
- 系统测试
- 运行维护
3.2 原型模型
原型模型，又称为快速原型。
- 解决问题：瀑布模型需求难以一次确定，结果难以预见的问题。
- 使用方法：它通过快速构建一个可以运行的原型，让用户和开发者更直观地了解系统的功能和外观。
原型模型有原型开发和目标软件开发两个阶段。
- 在原型开发阶段，开发者会快速构建一个简单的原型，供用户测试和反馈。
- 根据用户的反馈，开发者会对原型进行修改和完善，直到用户满意为止。
- 最后，开发者会根据最终的原型开始目标软件的开发。
3.3 螺旋模型
螺旋模型，在快速原型的基础上结合瀑布模型扩展而成。
它把整个软件开发流程分为多个阶段，每个阶段都由目标设定、风险分析、开发和有效性验证、评审等4部分组成。
在螺旋模型中，每个迭代都会进行风险评估和管理，以确保项目的顺利进行。这种模型适用于大型、复杂、高风险的项目，因为它可以帮助开发者更好地管理风险和不确定性。
3.4 敏捷模型
属于敏捷方法使用的模型。
- 极限编程：高效低风险，测试先行（先写测试程序，再编写程序）。
- 水晶系列方法：不同的项目，采用不同的策略。
- 并列争球法：侧重于项目管理。
- 特征驱动开发方法：将开发人员分类，分为指挥者、类程序员等。
3.5 软件统一过程模型
软件统一过程（Rational Unified Process，RUP）模型。
- 9个核心工作流：业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境
- 特点：用例驱动、以架构为中心、迭代和增量
- "4+1"视图模型
- 逻辑视图：支持功能性需求，常用类图、对象图、状态图、协作图表示。
- 实现视图（开发视图）：描述软件的实现结构，包括代码组织和软件组件的实现。常用包图和组件图。
- 进程视图（过程视图）：考虑非功能性需求，如性能、并发、可用性、容错性、分布式、系统完整性等问题。常用活动图表示。
- 部署视图（物理视图）：反映了部署在硬件上的软件分布和配置情况，包括服务器、数据库、网络设备等资源的分配和连接关系。
- 用例视图：所有视图都依靠用例视图（场景）来指导它们
3.6 软件成熟度模型
软件成熟度模型（Capability Maturity Model for Software，CMM）
是一种评估和提高组织软件工程能力的标准体系。
CMM把软件开发过程的成熟度由低到高分为五个级别，等级越高，表明该企业软件开发失败风险越低，整体开发时间越短，并能减少开发成本，降低错误发生率，提高产品质量。
3.7 软件成熟度模型集成
软件成熟度模型集成（Capability Maturity Model Integrattion for Software，CMMI）
在CMM的基础上发展而来，将软件过程改进的步骤组织成5个成熟度等级。
- 初始级：组织的软件开发过程是不可预测的，缺乏稳定性，通常依赖于个别人的经验和技能。
- 已管理级：组织已经有了基本的过程管理和文档标准的要求，并进行了控制。这些程序通常是项目级别的，而不是组织级别的。
- 已定义级：组织的过程已经被标准化和文档化，并且在组织中得到了广泛的运用。组织能够自下而上地看到过程，并能进行过程的改进。
- 量化管理级：组织通过定量的方法评估和控制过程的性能，并对过程进行持续改进。组织不仅需要有标准的软件开发过程，还需要对这些过程进行量化分析和度量，以便更好地了解过程的表现并做出持续改进。
- 优化级：在优化级别上，组织的过程完全被优化，并且能够实现持续的过程改进和优化。
量化管理级与已定义级的区别是对过程性能的可预测
四、需求工程
需求工程由5个阶段组成
- 需求获取：方法包括用户面谈、需求专题讨论会、问卷调查、现场观察、原型化方法和头脑风暴。
- 需求分析：需求被进一步分析和细化。
- 需求文档化：形成需求规格。
- 需求确认与验证：确保需求文档准确反映了用户的实际需求。
- 需求管理
- 需求变更：问题分析和变更描述、变更分析和成本计算、变更实现。
- 需求跟踪：建议与维护"需求---设计---编程---测试"。
- 版本控制：确保需求文档准确反映了用户的实际需求。
五、软件测试
5.1 根据程序执行状态分类
- 静态测试
- 动态测试
5.2 根据是否关注内部实现分类
- 黑盒测试
- 白盒测试
- 灰盒测试
5.3 根据程序执行方式分类
- 人工测试
- 自动化测试
5.4 根据测试阶段分类
- 单元测试
- 集成测试
- 系统测试
- 验收测试
六、项目管理
6.1 软件进度管理
工作分解结构（Work Breakdown Structur，WBS）把一个项目，按照一定原则分解成任务，任务再分解成一项项工作，再把工作分配到每个人的活动中，直到分解不下去为止。
- 活动定义：明确项目需要完成的具体活动或任务。
- 活动排序：确定活动之间的逻辑关系，即哪些活动需要先完成，哪些活动可以并行进行。
- 活动资源估计：评估完成每个活动所需的资源，包括人力、物力、财力等。
- 活动历时估计：预测完成每个活动所需的时间。
- 制定进度计划：根据活动排序、资源估计和历时估计，制定详细的进度计划。
- 进度控制：监控项目进度，确保项目按计划进行，并在必要时进行调整。
6.2 软件配置管理
软件配置管理（Software Configuration Management，SCM）是一种标识、组织和控制修改的技术。
- 目的：是使错误降为最小并最有效地提高生产效率。
- 核心内容：版本控制和变更控制。
6.3 软件质量管理
软件质量管理（Software Quality Assurance SQA），软件质量保证。
- 目的：使软件过程对于管理人员来说是可见的。
- 主要任务：SQA审计预评审，SQA报告，处理不符合问题。
- 软件质量认证：ISO 9001 和 CMM。
6.4 软件风险管理
在软件开发过程中遇到预算和进度等方面的问题，以及这些问题对软件项目的影响。
- Bochm
- 风险估计：风险预测、风险辨识、风险分析、风险排序
- 风险管理：风险管理计划、风险处理、风险监督
- Charette
- 风险分成分析：辨识、估计、评价
- 管理：计划、控制、监督
若觉得文章对你有帮助，随手『点赞』、『收藏』、『关注』，也是对我的支持。