高架学习笔记之软件工程基础

最新推荐文章于 2024-06-10 00:35:53 发布

犬余

最新推荐文章于 2024-06-10 00:35:53 发布

阅读量1.4k

点赞数 43

分类专栏：系统架构师学习笔记文章标签：学习笔记软件工程

本文链接：https://blog.csdn.net/shunda_zhou/article/details/136767520

版权

系统架构师学习笔记专栏收录该内容

10 篇文章 0 订阅

订阅专栏

一、软件工程

计算机刚刚投入实际使用时，软件基本上是在指定的计算机上由个人进行设计、使用以及操作，是很私人化的软件生产方式，但随着计算机的应用范围迅速扩大，软件开发量的规模也越来越大，逐渐产生了软件危机，软件危机具体表现在：开发进度难以预测、开发成本难以控制、功能难以满足用户期望、质量无法保证、难以维护并缺少文档资料，为了解决这些问题，就产生了软件工程；软件工程目前没有一个统一的定义，但简单来讲，软件工程就是让软件的开发运行和维护都能像建房子那样的工程项目一样，有一套严格的、系统化的、可量化的方法。

软件工程过程是指由软件工程师完成的一系列软件工程活动，包括4个方面：P（Plan）软件规格说明，D（Do）软件开发，C（Check）软件确认，A（Action）软件演进；这四个方面简称PDCA，又叫戴明环。

二、软件过程模型

软件生命周期描述了一个软件从生到死的全过程，包括需求分析、软件设计、软件开发、运行维护以及消亡，为了使这个周期中的各个阶段能有序地按照规程进行下去，就需要软件过程模型，或者叫做软件生命周期模型来给予约束，常见的软件过程模型包括瀑布模型、原型模型、增量模型、螺旋模型、构件组装模型、敏捷模型、统一过程模型（RUP）。

三、瀑布模型

瀑布模型（Waterfall Model）中各个环节的流程像是瀑布一样从上向下依次进行，上一个阶段的输出结果即为下一个阶段的输入，因果关系紧密相连，如图所示：

由于瀑布模型是严格串行化的，需要到比较后期的阶段才能得到一个看得见的软件系统，如果到了这个阶段才发现系统与用户期望的不一致，或者期间发生了需求变更，将产生巨大的损失，而且由于每一个阶段都是建立在前一个阶段的输出结果之上，一旦某一个阶段的输出出现了错误，就会导致后面所有环节全部错误，直至用户验收时才会发现问题，很有可能会完全推到重来。

四、原型模型

原型模型（Prototype Model）为了解决瀑布模型的缺点，而在瀑布模型的基础上增加了原型开发阶段，在原型开发阶段由软件开发人员根据用户的需求，快速开发出一个包含系统关键问题和大致面貌的原型，并不断地征求用户对原型的意见进而对原型不断修改完善直至与用户期望达成一致，再以此原型对系统进行开发等工作。

按照原型的作用不同，原型可以划分为抛弃型原型和演化型原型：抛弃型原型（也叫快速原型）作为需求确认的手段，在确认了需求之后就不再使用了；演化型原型则是在确认了需求之后，还会不断补充和完善原型，直至形成一个完整的产品。

注：对大型的软件来说，原型可能非常复杂且难以完成，如果没有现成的原型可供使用，就不适合采用原型法了。

五、螺旋模型

螺旋模型（Spiral Model）是在演化型原型和瀑布的基础上扩展而成，螺旋模型将这软件的整个开发流程分成多个阶段，其基本思路就是确认需求之后快速开发出一个原型，然后用瀑布模型的周期走一轮，开发出一个版本，然后再迭代原型，进行下一轮的开发，逐步迭代完善软件，最终得到符合用户期望的软件。螺旋模型在原型和瀑布模型的基础上还另外引入了风险分析的步骤，风险分析的目的是在原型开发之前就能对计划进行评估，并分析出计划中的风险并消除风险。螺旋模型支持并适合于大型软件的开发。

六、增量模型

增量模型和螺旋模型都是逐渐完善软件的模型，与螺旋模型不同的是，增量模型是将软件整体划分为多个模块，先将核心模块完成之后即可发布一个版本，后续再不断地开发补充新的模块，发布新的版本，直至所有模块开发完成。

七、构建组装模型

在构建组装模型中，软件系统被分解为多个独立的模块或组件，每个模块负责实现特定的功能。这些模块可以独立开发、测试和维护，然后组装在一起，形成完整的系统。这种模块化的设计使得系统更易于理解和管理，同时也可以将经过测试的模块用于不同的项目。

构建组装模型的一个关键优势是可以并行开发不同的模块，从而加快整个软件项目的开发进度。团队成员可以专注于各自负责的模块，而不会受到其他模块的影响。此外，当需要对系统进行升级或修改时，只需修改相关的模块而不影响其他部分，降低了维护成本和风险。

八、敏捷模型

敏捷模型（Agile Model）产生的目的在于缩短产品交付周期，和传统的软件开发流程相比，敏捷模型是“适应性”而非“预设性”的，是“面向人”的而非“面向过程”的，

核心思想

1) 适应型而非可预测型：拥抱变化，适应变化；

2）以人为本而非以过程为本：加强沟通，减少文档；开发人员有技术方面的决定权；

3）迭代增量式的开发过程：小版本发布，小步快跑。

九、统一过程模型（RUP）

统一过程模型（Rational Unified Process, RUP）是一种基于构建发展而来的重量级过程，RUP类似一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针、模板以及事例支持。RUP中定义了如下核心概念：

角色（Role）：Who的问题，决策描述某个人或一个小组的行为与职责，RUP预先定义了许多角色，如体系结构师、设计人员、实现人员、测试人员、配置管理人员等；
活动（Acitvity）：How的问题，活动是一个有明确目的的独立工作单元；
制品（Artifact）：What的问题，活动创建、生成或修改的一段信息，也可以叫产品、工件；
工作流（Workflow）：When的问题，描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。

RUP是用例驱动、以体系结构为中心、迭代和增量的软件开发过程：

用例驱动：RUP中的需求分析、设计、实现和测试等活动都是用例驱动的；
以体系结构为中心：即以架构为中心，软件体系结构是软件设计过程中的一个层次，和代码设计无关，也不依赖于具体的程序设计语言；对于一个软件系统，不同的人关心的内容是不同的，会从多个视角来描述软件体系结构，RUP采用4+1视图模型来描述系统体系结构的不同视图：

迭代与增量：RUP将整个项目开发拆分为多个迭代过程，每次迭代只考虑系统的一部分需求，进行分析，设计，实现，测试和部署等过程，在已完成部分的基础上增加新的功能，直至迭代到项目完成。

RUP每次迭代的生命周期包括：初始，细化，构建，交付：

十、软件能力成熟度模型

软件能力成熟度模型（Capability Maturity Model for Software，CMM）是一个概念模型，用于评估和改进组织在软件开发过程中的成熟度和能力。CMM 根据组织执行的特定任务来衡量组织的成功。它不太关注结果。CMM有五个成熟度级别，每个级别代表组织过程能力的不同阶段。这些级别依次是：

初始级别（Level 1 - Initial）: 过程通常是不可预测的，因为它们是不成熟的和无序的。
可重复级别（Level 2 - Repeatable）: 基本的项目管理过程被建立，以跟踪成本、进度和功能性。
已定义级别（Level 3 - Defined）: 组织的标准过程被建立、实施和维护。
已管理级别（Level 4 - Managed）: 组织通过收集详细的度量数据来监控和控制过程。
优化级别（Level 5 - Optimizing）: 组织持续改进其过程，通过创新和增量改进来提高过程性能。

软件能力成熟度模型集成（Capability Maturity Model Integration for Software，CMMI）是在CMM的基础上发展而来的，CMMI在评估成熟度水平的同时测量结果。CMMI有两种表示方法，一种是和CMM一样的阶段式表示方法，另一种是连续式的表现方法。阶段式表现方法仍通过五个成熟度级别进行评估：

初始级（Level 1 - Initial）: 过程通常是混乱的，很少有被定义的过程。
管理级（Level 2 - Managed）: 过程特征被理解，并且项目管理过程被实施。
已定义级（Level 3 - Defined）: 组织的过程被标准化、文档化，并在整个组织中得到了遵循。
量化管理级（Level 4 - Quantitatively Managed）: 过程被量化管理，使用统计和其他量化技术来理解和控制过程。
优化级（Level 5 - Optimizing）: 组织持续改进其过程，通过创新和增量改进来提高过程性能。

连续式的表示方法允许组织根据其独特的业务目标和改进优先级来选择特定过程领域和相关实践并确定其优先级。连续表示使用功能级别，而不是预定义的成熟度级别：