【软考速通笔记】系统架构设计师⑤——软件工程基础知识

一、前言

笔记目录大纲请查阅：【软考速通笔记】系统架构设计师——导读

二、基础知识点

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
  • 风险分成分析：辨识、估计、评价
  • 管理：计划、控制、监督

若觉得文章对你有帮助，随手『点赞』、『收藏』、『关注』，也是对我的支持。