软件过程模型：从瀑布到敏捷——漫画解读软件开发模式变迁史

目录：

软件过程：

软件开发模型的内在特征：

瀑布模型：

快速原型模型：

增量模型：

螺旋模型：

 喷泉模型：

基于组件的开发模型：

统一软件开发过程模型： 

敏捷过程：​​​​​​​

---

这张图片从上向下，五个房间，分别是瀑布模型（waterfall），敏捷开发（agile），看板（KANBAN），SCRUM 和精益软件开发（lean）。

软件过程：

软件工程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各任务的工作步骤，概括的说，软件过程描述为了开发出客户需要的软件，什么人(who)、在什么时候(when)、做什么事(what)以及做这些事怎样(how)以实现某一各特定的具体目标。

---

软件开发模型的内在特征：

1. 描述了主要的开发阶段。
2. 定义了每个阶段要完成的主要任务和活动。
3. 规范了每个阶段的输入和输出。
4. 提供了一个框架，把必要的活动映射到这个框架中。

---

瀑布模型：

瀑布模型是20世纪80年代之前最受推崇的软件开发模型，它是一种线性的开发模型，具有不可回溯性。瀑布模型 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环 反馈 ，因此，如果有信息未被覆盖或者发现了问题，那么最好 "返回"上一个阶段并进行适当的修改，项目开发进程从一个阶段"流动"到下一个阶段，这也是瀑布模型名称的由来。. 包括 软件工程 开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。

瀑布模型有以下优点：

1. 为项目提供了按阶段划分的检查点。
2. 当前一阶段完成后，您只需要去关注后续阶段。
3. 可在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
4. 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

瀑布模型有以下缺点：

1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4. 瀑布模型的突出缺点是不适应用户需求的变化。

 

---

快速原型模型：

快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。

优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险

优点：所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。

---

增量模型：

增量模型又称为渐增模型，也称为有计划的产品改进模型，它从一组给定的需求开始，通过构造一系列可执行中间版本来实施开发活动。第一个版本纳入一部分需求，下一个版本纳入更多的需求，依此类推，直到系统完成。每个中间版本都要执行必需的过程、活动和任务。 增量模型是瀑布模型和原型进化模型的综合，它对软件过程的考虑是：在整体上按照瀑布模型的流程实施项目开发，以方便对项目的管理；但在软件的实际创建中，则将软件系统按功能分解为许多增量构件，并以构件为单位逐个地创建与交付，直到全部增量构件创建完毕，并都被集成到系统之中交付用户使用。

增量模型的最大特点就是将待开发的软件系统模块化和组件华。基于这个特点，增量模型具有以下优点

1. 将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。
2. 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
3. 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。

---

 螺旋模型：

旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。

螺旋模型有以下优点：

1. 设计上的灵活性,可以在项目的各个阶段阶段进行变更。
2. 以小的分段来构建大型系统,使成本计算变得简单容易。
3. 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
4. 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
5. 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

 螺旋模型的缺点：

• 很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

---

 喷泉模型：

喷泉模型主要用于采用对象技术的软件开发项目。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。

 喷泉模型的优点

• 喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。

 喷泉模型的缺点：

• 由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
   

---

基于组件的开发模型：

        基于组件开发方法的需求分析和系统验证与其他过程类似，不同之处在于中间的几个阶段。在需求确定后，开发人员会搜寻可供使用的组件，并分析得到的组件。通常没有刚好满足要求的组件，在分析组件信息基础。开发人员可能调整需求以适应组件或者修改现有组件以适应需求。所选的组件可能是从市场上采购或从旧组件中提炼出来的，也可能是新开发的。选完组件后，开发人员要依据所选组件设计系统架构或者复用已有的架构。最后，将所有组件集成起来并完成测试工作。
      基于组件的开发方法可以减少待开发软件数量，减低软件成本，提高软件质量，相对其他过程具有明显的优势。然而，该方法的使用也受到一些因素的制约。为适应组件，需求的修改通常是不可避免的，而这种修改有可能导致系统不符合用户的需要。此外，系统的进化无法控制，因为可复用组件的新版本不一定是出开发机构控制的。

---

统一软件开发过程模型： 

统一过程（Unified Process，UP）是由 Rational 公司开发的一种迭代的软件过程，是一个优秀的软件开发模型，它提供了完整的开发过程解决方案，可以有效地降低软件开发过程的风险，经过裁剪的 UP 可以适应各种规模的团队和系统。
UP 的二维模型
UP 是一个很有特色的模型，它本身是一个二维的结构，如图 6-5 所示。对于 UP 而言，时间主线就是横轴的阶段，随着时间的流逝，软件开发活动总要经过初始、细化、构建和交付这 4 个阶段方能完成。而纵轴的工作流程则描述了在不同的阶段需要进行的主要工作。例如在初始阶段，软件组织需要进行大量的调研，对软件进行业务建模、需求，同时进行一些设计以验证建模的合理性，还要进行一些实施甚至测试和部署的工作，用以验证需求和设计的工作及开发系统原型，当然配置与变更管理、项目管理和环境是在任何阶段都是不能缺少的。

---

敏捷过程：

敏捷开发是一种以人为核心，以迭代方式循序渐进开发的方法，其软件开发的过程称为“敏捷过程”。
在这一过程中，软件项目的构建被切分成多个子项目，各个子项目的成功都经过测试，具备集成和可运行的特征。
在2001年年初，一些业界专家成立了敏捷联盟，起草了敏捷软件开发宣言。该宣言针对一些企业的现状，提出了让软件开发团队具有快速工作、快速应变能力的若干价值观和原则，其中包括4个简单的价值观以及敏捷开发方法应遵循的12条原则。

敏捷开发应遵循的12条原则：

1. 通过尽早的、不断地提交有价值的软件来使客户满意。
2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3.  以从几个星期到几个月为周期，尽快、不断地提交可运行的软件。
4.  在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5. 以积极向上的员工为中心，建立项目组，给他们提供所需的环境和支持，并对他们的工作予以充分的信任。
6. 在团队内部，最有效、效率最高的传递信息的方法，就是面对面的交流。
7.  测量项目进展的首要依据是可运行软件。
8.  敏捷过程提倡可持续的开发，责任人、开发者和用户应该为能够保持一个长期的、恒定的开发速度而努力。
9. 时刻关注技术上的精益求精和好的设计，以增强敏捷能力。
10. 简单是最根本的。
11.  最好的构架、需求和设计出于自组织的团队。
12. 每隔一定时间，团队要反省如何才能更有效地工作，然后相应地调整自己的行为。