🌈 个人主页：十二月的猫-CSDN博客
🔥 系列专栏： 🏀软件开发必练内功_十二月的猫的博客-CSDN博客💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光
目录
1. 前言
2 章节概述和章节框架
3. 软件过程
3.1 过程与生命周期是什么
3.2 过程模型
3.2.1 为何需要为过程建立模型
3.2.2 瀑布模型
3.2.2.1 瀑布模型的优点
3.2.2.2 瀑布模型的缺点
3.2.3 原型化的瀑布模型
3.2.4 V模型
3.2.5 原型化模型
3.2.6 阶段化开发模型
3.2.6.1 阶段化开发的特点
3.2.7 螺旋模型
3.2.8 敏捷方法
3.2.8.1 敏捷方法的四条原则
3.2.8.2 敏捷开发过程的几种方法
3.3 过程建模工具和技术
3.3.1 两种主要种类的建模工具
4. 总结
1. 前言
在进入本篇文章前，大家可以先去看看另一篇文章：【软件工程】第一章·软件工程概述-CSDN博客
通过上一篇文章，我们能够对【软件工程】有一个更加全面的认识，这对我们后续学习的开展有很多好处。
这里简单来回顾一下：
重点知识回顾：
1、软件工程是什么——定义、方法、作用。
2、软件工程的前世今生——出现的问题（error、fault、failure）、应对方法（问题分析方法+系统化方法+工程化方法）。
3、软件工程的未来——Wasserman 规范（抽象、分析设计方法和符号描述系统、软件过程、软件体系结构、重用和复用、用户界面原始模型、测试代码、工具和集成环境）
2 章节概述和章节框架
软件过程是软件工程过程中各种活动的组织方式，是我们在对问题进行分析、画出一系列分析设计方法以及符号描述系统后，需要进一步考虑的事情。软件过程有助于我们在软件开发整个活动中，协调各种活动，保证软件开发过程的科学性、有序性，从而提高软件质量。
这一章我们要详细分析软件工程中的各种步骤的组织方式，以便我们协调各种活动。面对的主要问题有如何理解过程模型，如何应对软件开发过程中的种种状况，为此我们首先要解释过程模型的意义，然后为大家介绍各种模型的思想，为了响应变化和规避风险，会涉及到原型化和迭代开发的思想。关键在于思想的理解，模型是固化的，思想运用是灵活的。本章重点在过程与生命周期和过程模型。
重点内容：
1、理解过程模型。
2、理解过程模型思想，从而应对软件开发中的各种状况。
3、掌握建立过程模型的工具/技术。
3. 软件过程
第二章·软件过程主要学习三部分内容：
- 过程与生命周期是什么
- 过程模型有哪些
- 过程模型建模
3.1 过程与生命周期是什么
过程的定义：
1、一组有序的任务，它涉及活动、约束和资源使用的一系列步骤，用于产生某种想要的输出。
2、过程不仅仅是步骤，过程是步骤的集合，它将步骤组织起来使人们能够生产满足一系列目标和标准的产品。
生命周期的定义：
软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程，因此，有时把软件开发过程称为软件生命周期。
过程的意义：
（1）它强制活动具有一致性和一定的结构。
（2）过程结构允许我们分析、理解、控制和改进组成过程的活动，并以此来指导我们的活动。
（3）它使我们获取经验并把经验传授给他人。
3.2 过程模型
过程模型就是软件过程中最重要的部分，每一个软件的开发都需要在开发进行之前便确定好过程模型。然后在这个过程模型的指导下，进行软件开发活动。
3.2.1 为何需要为过程建立模型
（1）达成共识：开发团队在记录开发过程的描述时，自然的对软件所涉及到的活动,资源,约束等达成共识，这共识就是”模型”。
（2）发现缺陷：发现过程层面的缺陷(过程实施时的不一致性、多余部分、缺省部分、不完善部分)，从而让过程更有效。
（3）评价与优化：模型应该反映开发的诸多目标，并评价侯选活动的有效性和正确性,以构建高质量软件。
思考：不对过程进行建模，软件开发的活动安排将存在不确定性，大概率难以得到最佳的活动安排。在过程建模中，可以发现缺陷并评价改进我们的过程，同时有利于达成共识。
3.2.2 瀑布模型
线性的安排每一个阶段，将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段。一个开发阶段必须在另一个开发阶段开始之前完成。
开发过程像瀑布一样从上到下，没有回头路。
本质：将工程化过程按照瀑布模样从上到下一一进行
3.2.2.1 瀑布模型的优点
（1）它的简单性使得开发人员很容易向不熟悉软件开发的客户作出解释。
（2）每一个过程活动都有与其相关联的里程碑和可交付产品，以便于项目经理评估项目进度。
（3）瀑布模型是最基础的模型，很多其他更复杂的模型实际上是在瀑布模型的基础上的润色，如加入反馈循环以及额外的活动。
1、简单，容易解释。
2、每一个过程都有里程碑产品，便于评估项目进度。
3、瀑布模型是很多其他模型的基础，有很好的泛化性，能与多个模型叠加。
3.2.2.2 瀑布模型的缺点
（1）除了一些理解非常充分的问题之外，实际上软件是通过大量的迭代进行开发的。软件是一个创造的过程, 不是一个制造的过程。软件变动时, 该模型无法处理实际过程中的重复开发问题。
（2）文档转换有困难。它说明了每一个活动的产品（例如，需求、设计或代码），但没有揭示一个活动如何把一种制品转化为另外一种制品（例如，从需求文档转化为设计文档）。
问题：
1、软件开发需要多次的迭代过程去完成，瀑布模型难以迭代。
2、文档转化很困难，文档整合困难。
3.2.3 原型化的瀑布模型
我们注意到瀑布模型将过程抽象为线性发展的，这种抽象给它带来了简单、明确和直观的优点，但同时也招致了许多问题。可是实际的开发中每个步骤并不是理想中的线性发展的的状态，比如在设计阶段了解到客户更新了需求，或者在设计阶段的疏漏直到测试时才被发现，以上的情况都需要返回之前的步骤进行修正才能解决。我们需要对瀑布模型进行优化，引入原型化以有助于控制活动之间的往返。
（1）原型的概念
一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。原型可以理解为小样，在某一阶段产品定型前先做一些小样，通过对各种样品的评价和分析，并最终为产品定型。
原型化的瀑布模型如下图所示，在实现代码前的需求和设计阶段引进原型化的概念，在需求分析阶段，通过设计和分析原型以确保需求是一致、可行和符合实际的，避免在测试阶段付出巨大的代价进行修正；在设计阶段，原型化有助于开发人员评价可选的设计策略以及决定哪一种策略是最适合的。为了确保产品符合需要，在测试阶段要进行确认/核准（validate）和验证（verify）。
（2）区分确认和验证：
确认：确保系统实现了所有需求。
验证：确保每一项功能都是正确的。
确认保证开发人员构造的是正确的产品，而验证检查实现的质量。
关键点：
1、原型化模型：分析设计阶段的产品，没有进行全面code，仅仅为了帮助大家分析。
2、测试阶段：通过确认来审核需求，用验证来审核系统功能吗，如果有问题会返回。
3.2.4 V模型
通过前面对瀑布模型的研究，我们发现其存在问题：过程难以回溯
过程回溯发生在测试和设计阶段之间，因此V模型将测试和设计分离，增强模型的回溯性
V 模型是瀑布模型的变种，它说明测试活动是如何与分析和设计相联系的。
如下图所示，编码位于 V 型的顶点，分析和设计在左边，测试和维护在右边。测试的每个步骤都与分析和设计相对应，如果在验证和确认期间发现了问题，可以重新执行响应的步骤加以修正。验收测试对应需求分析，系统测试对应系统设计，单元测试和集成测试对应程序设计。
这是一个非常漂亮的模型，将设计和测试之间的关系一一呈现出来。
V 模型与瀑布模型的区别：
（1）V 模型使得隐藏在瀑布模型中的迭代和重做活动更加明确。（2）瀑布模型关注文档和制品，V 模型关注活动和正确性。
3.2.5 原型化模型
之前在瀑布模型的优化中介绍了原型化的思想，原型化并不依附于瀑布模型，原型化模型本身是有效的过程模型的基础。因为它允许用户以独立的工程模型的方式, 每一阶段都基于原型的建立, 以快速构造系统, 逐步完成各阶段任务。
如上图所示，原型化模型并不依赖于明确的需求或设计，在情况不明朗的情况下使用原型化模型，先根据简单的需求和设计构造系统的简单样品以理解或澄清问题，以确保开发人员、用户和客户对产品达成共识。也就是说，要根据对每一阶段样品的反响明确需求和设计的具体内容。原型化设计有助于开发人员和客户达成共识，减少了开发中的风险和不确定性。但是为达成共识可能会需要反复进行原型设计。
关键点：
1、原型化开发本身也不像一个具体的模型，它更像是一种思想，这个思想可以运用到过程模型中的每一个部分。
2、在该步骤（分析、设计、编码）不清晰时，可以使用原型化思想去帮助理解或澄清问题。
3.2.6 阶段化开发模型
问题：商业环境不允许产品有长开发时间，但是较短开发时间难以有高质量且完整的产品。
想法：将产品开发分为几个阶段，后一阶段是前一阶段的补充。边开发边交付，从而为产品开发提供更多时间，用户体验也将更好。
定义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。
循环周期：从软件开发时整理需求文档到系统交付经过的时间。
为何要阶段化开发：我们需要了解现在的商业环境不允许产品长时间拖延，所以我们要缩短循环周期，使用阶段化开发模型使系统能一部分的交付，从而在系统其余部分正在开发的同时，用户已经获得了一部分功能。
3.2.6.1 阶段化开发的特点
(1) 产品系统和开发系统
因为一边开发一边交付，所以有两个系统在并行运行。
运行系统/产品系统：当前正在被客户和用户使用的系统。开发系统：准备代替现行产品系统的下一个版本。
两者关系如下图所示，开发人员总是在开发 n+1，而与此同时 n 正在运行。
(2) 增量开发和迭代开发
因为有不断发布的开发系统和已经运行的产品系统，我们需要有一种组织两者的方式。增量开发和迭代开发是两种最常用的方式。
①增量开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。
②迭代开发：系统开始就提供了整体功能框架，后续版本陆续增强各个子系统，最后版本使各个子系统的功能达到最强。
增量开发：目的是产生新功能，开拓市场
迭代开发：目的是及时修复问题，完成功能优化
(3) 迭代进化式开发（迭代增量式开发）
一个新发布的版本可能包含新功能，并对已有功能做了改进。两种开发方式结合的原因：
①观察用户反馈。
②为新功能开拓市场。
③及时修复问题。
④针对不同版本设置不同专业领域技术的优化。
(4) 统一过程开发（目前最核心的开发方式）
统一过程（UP/RUP）：用例驱动的、以基本架构为中心的、迭代式和增量式的软件开发过程框架。它使用对象管理组织（OMG）的 UML 并与对象管理组织（OMG）的软件过程工程原模型（SPEM）等相兼容。
统一过程开发
1、用例驱动
2、基本架构为中心
3、结合迭代式和增量式开发
①统一过程的特点：
(a)统一过程”将重复一系列生命期，这些生命期构成了一个系统的寿命。每个生命期都以向客户推出一个产品版本而结束。
(b)每个周期包括四个阶段：开始阶段、确立阶段、构建阶段和移交阶段。每个阶段可以进一步划分为多次迭代。
(c)三个支持工序和六个核心工序：
支持工序：
(1)配置变更管理工序，用来管理系统和需求变更的配置。
(2)项目管理工序，用来管理项目。
(3)环境配置工序，用来配置项目的环境，包括所涉及到的过程和工具。
核心工序：
(1)业务模型工序，用业务模型获取相关知识以理解需要系统自动完成的业务。
(2)需求工序，通过用例模型获取相关知识以理解自动完成业务的系统需求。
(3)分析设计工序，通过分析/设计模型以分析需求，设计系统结构。
(4)实现工序，基于实现模型实现系统。
(5)测试工序，通过测试模型进行针对需求的系统测试。
(6)部署工序，通过部署模型部署系统。
下图展示了统一过程的四个阶段和六个核心工序之间的关系，上面一行表示四个阶段，左边一列表示六个核心工序，二者都包含在软件项目的生命期中。每个阶段都包含六个工序，但是重点不同。开始阶段最关注业务模型，几乎不涉及测试和部署；确立阶段最关心需求和分析；构建阶段最关心实现；移交阶段最关心测试和部署，几乎不涉及业务模型和需求。图中箭头表示六个工序执行顺序，菱形覆盖的面积表示关注程度。 
六大核心工序：和工程化方法的步骤本质是一样的。
特别记忆：
1、 Wasserman 八大规范：是整个软件工程学习的内容，同样也是整个软件从开发到生命终止的过程，里面包括软件过程。
2、统一过程是分阶段过程模型的一部分，用来解决开发系统和运行系统的版本问题。统一过程开发中的六大核心工序：业务模型、需求分析、分析设计、实现、测试、部署。本质就是工程化方法的步骤。
3.2.7 螺旋模型
此法将开发活动与风险管理结合起来, 以降低和控制风险。有些类似于迭代开发模型，结合了迭代的思想，同时也结合了原型化的思想。该模型的适用范围于较大型软件工程项目。
如下图所示，螺旋模型每次迭代有四个任务，依次是计划、目标/可选方案、风险评估、开发与测试。螺旋模型共有四次迭代，依次是操作概念、软件需求、软件设计、开发与测试。每一次迭代都根据需求和约束进行风险分析，以权衡不同选择，并且在确定选择之前，通过原型化验证可行性和期望度。
核心思想：四轮迭代，每一轮都将的到一个原型化模型
3.2.8 敏捷方法
之前介绍的几种模型逐渐引入了原型化和迭代开发的思想，使得过程模型变得庞大，而敏捷方法打破了这种局面。
敏捷方法强调灵活性在快速有效的软件生产中所发挥的作用，是重量级方法的叛逆者。
背景：考虑到问题开始，我们往往对需求并不清晰，因此引入原型化和迭代化方法，使得软件过程更加合理。
问题：如此的后果，就是软件过程模型变得非常复杂冗余。
解决方法：因此有人提出敏捷开发，强调灵活性和快速性。
3.2.8.1 敏捷方法的四条原则
①个体和交互的价值胜过过程和工具。
②可以工作的软件胜过面面俱到的文档。
③客户合作胜过合同谈判。
④响应变化胜过遵循计划。
这四条原则反映了敏捷方法的软件过程倾向性。它强调人与人之间的交互是复杂的，并且其效果从来都是难以预期的，但却是工作中最重要的方面。
敏捷开发的总体目标：尽可能早的，持续的对有价值的软件的交付活动，以客户满意。
敏捷开发：快、准、狠
3.2.8.2 敏捷开发过程的几种方法
①极限编程(XP)：激发人员创造性，使管理负担最小的一组技术，是敏捷方法中最主
要的流派。（稍后有详细介绍）
②Crystal （水晶法）：每一个不同的项目都需要一套不同的策略、约定和方法论。
③SCRUM（并列争球法）：使用迭代的方法，其中把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。
④Adaptive Software Development(ASD) (自适应软件开发)
⑤Feature Driven Development(FDD) (特征驱动软件开发)
极限编程（XP）：
（a）四个变量：成本、时间、质量和范围，通过研究变量之间的相互作用，将项目开发分析的更加透彻，成功讲述一个项目成功的原则。
不同的任务对这四个变量有不同的要求，分析哪一个变量是项目进展的制约，集中精力解决关键问题。
（b）四个准则：
①沟通: 客户与开发者之间持续的交流意见。
②简单性: 鼓励开发者选择最简单的设计或实现来应对客户的需求。③反馈: 指在软件开发过程中的各个活动中,包含各种反馈循环工作。
④勇气: 指尽早的和经常性的交付软件功能的承诺。
（c）十二条原则：计划游戏、小版本、隐喻、简单设计、测试、重构、结队编程、代
码集体所有、持续集成、每周工作 40 小时、现场客户、编码标准
①小版本：系统设计要支持尽可能早的交付。（测试要简单有效。）
②简单设计：只处理当前需求，使设计保持简单。（因为假设需求是变化的）③编码标准：编码支持其他实践，例如测试和重构等。
3.3 过程建模工具和技术
用来完成软件过程建模的技术和工具
3.3.1 两种主要种类的建模工具
(1) 静态建模——Lai 表示法
描述一个过程如何由输入转换为输出。
综合的过程符号描述系统, 允许人们在任何详细的层次上对任何过程建模, 该模型范式中可由人员完成角色,由资源完成活动, 最后导致软件工件/制品的产生。过程模型可以用角色、活动、加工项(工件)来显示彼此之间的关系，用状态表显示每个加工项(工件)在特定时间的完成情况。
过程的元素：
①活动：过程中要发生的事件。各种前后关系、触发条件、规则、团队成员等等。也
可以理解为子过程。
②序列：活动顺序等等。
③过程模型：小型工程可以认为是开发方式等描述。
④资源：活动所需的各种资源标注。
⑤控制：针对活动的外部影响等。
⑥策略：各种指导原则，包括约束等。
⑦组织：各种层次化结构等描述。包括物理的和软件逻辑的结构。
(2) 动态建模
推演一个过程，用户和开发人员可以看到中间产品和最终产品如何随着时间的推移进行转换。
系统动力学：展示资源流(非一般性输入)如何通过活动成为输出。
(3) 在所有的软件开发过程模型中，你认为哪些过程给予你最大的灵活性以应对需求的变更？
①设计对于分析模型应该是可跟踪的：软件的模块可能被映射到多个需求上。
②设计结构应当尽可能的模拟实际问题。
③设计应当表现出一致性。
④不要把设计当成编写代码。
⑤在创建设计时就应该能够评估质量。
4. 总结
对于本文，我还有类似的另一篇文章：
【软件工程】一篇入门软件开发模型_软件工程生命周期过程模型图-CSDN博客
该篇文章在细节上更好，但是本篇文章更注重整体框架，大家可以结合起来看。
如果觉得对你有帮助，可以点个赞、收藏一下啦~~~·
