1.1.3 软件过程模型
软件开发过程包含各种复杂的风险因素，为了解决由这些因素带来的种种问题，软件开发人员经过多年的摸索，总结出了多种软件工程的实现方式——软件过程模型，如瀑布过程模型、螺旋过程模型、增量过程模型、快速原型过程模、敏捷过程模型等。这些软件过程模型是软件开发的指导思想和全局性框架，它们的提出和发展反映了人们对软件过程的认识观，体现了人们对软件过程认识的提高和飞跃。软件开发所遵循的软件过程是保证高质量软件开发的一个至关重要的因素。
1. 瀑布过程模型
瀑布过程模型反映了早期人们对软件工程的认识水平，是人们所熟悉的一种线性思维的体现。
瀑布过程模型强调阶段的划分及其顺序性、各阶段工作及其文档的完备性，是一种严格线性的、按阶段顺序的、逐步细化的开发模式，如图1.1所示。
图1.1 瀑布开发过程
瀑布过程模型主要由顺序的活动（或者阶段）组成，其开发阶段包括计划、需求分析、设计、编码、测试和运行维护等，各个阶段的主要工作内容如下。
• 计划阶段的工作主要是确定软件开发的总目标，给出软件的功能、性能、可靠性、接口等方面的设想；研究完成该项软件的可行性，探讨问题解决的方案；对可供开发使用的资源（如计算机硬、软件、人力等）、成本、可取得的效益和开发的进度作出估计；制定完成开发任务的实施计划。
• 需求分析是指收集产品的需求，对开发的软件进行详细的定义，由软件人员和用户共同讨论决定哪些需求是可以满足的，并且给予确切的描述；写出软件需求规格说明书等文档，提交管理机构审查。
• 设计是软件过程的技术核心。在设计阶段应把已确定的各项需求，转换成相应的体系结构，在结构中每一组成部分都是功能明确的模块，每个模块都能体现相应的需求，这一步骤称为总体设计。然后进行详细设计，对某个模块要完成的工作进行具体的描述，以便为程序编写打下基础。
• 编码阶段的工作是编写各种层次的代码，包括高级可视化开发系统生成的代码和用第四代程序设计语言编写的代码等。
• 软件测试主要是为了发现程序中的错误。
• 运行维护主要是对软件进行修复和改动，使它能够持续发挥作用。
在实际软件开发过程中，并不是严格按照图1.1中所示各阶段顺序执行的，因此过程中的各部分之间都有某种程度的重叠。造成这种重叠的原因是上述任何一个阶段都不可能在下一阶段开始之前完全结束。软件开发人员很少像图1.1所示的那样使用单纯的瀑布过程模型，除非是很小的项目或者是开发的产品与软件开发人员以前做过的项目类似，这主要是因为绝大多数软件都是复杂的、非线性的。
2. 螺旋过程模型
螺旋过程模型需要经历多次需求分析、设计、实现、测试这组顺序活动。这样做有多种原因，其中主要的原因是规避风险；另一个原因是在早期构造软件的局部版本时即交给客户以获得反馈；还有一个原因是为了避免像瀑布过程模型一样一次集成大量的代码。
螺旋过程模型的基本思路是依据前一个版本的结果构造新的版本，这个不断重复迭代的过程形成了一个螺旋上升的路径，如图1.2所示。
图1.2 螺旋开发过程
螺旋过程模型的一个额外的优点就是能够在每次迭代中都收集到过程中产生的各种度量数据。例如，在第一次迭代时记录下小组进行设计和实现所耗费的时间，依此即可以改进后续设计和实现所耗费时间的估计方法，这对于没有任何历史数据的开发组织尤其具有价值。
螺旋过程模型符合典型软件项目的发展特点，但是跟简单的瀑布过程模型相比，它需要投入更多的精力来更细致地管理其过程。这主要由于每次迭代完成之后都必须保证文档的一致性，特别是代码应该实现文档中描述的设计并且满足文档中记录的需求。此外，为了提高开发小组的生产效率，往往会在前一个迭代结束之前就开始一次新的迭代，这为协调文档的一致性增加了一定难度。
螺旋开发过程需要多少次迭代？这取决于具体的情况。例如，由3人组成的开发小组、耗时4个月的项目大概需要2次或者3次迭代，而项目若采用5次迭代，则所需要的管理费用通常会超过新增迭代所创造的价值。
3. 增量过程模型
当迭代的速度加快，每次迭代只是在前一次的基础上增加少量功能的时候，这种迭代过程就是增量开发过程。
增量过程模型是用一种几乎连续的过程小幅度地推进项目，如图1.3所示。增量过程模型在项目的后期尤其适用，比如当项目处于维护阶段，或者立项的产品与原先开发出来的产品结构极为相似。
图1.3 增量开发过程
4. 快速原型过程模型
在快速原型过程模型中，首先是快速进行系统分析，在设计人员和用户的紧密配合下，快速确定软件系统的基本要求，尽快实现一个可运行的、功能简单的原型系统，然后对原型系统逐步求精、不断扩充完善得到最终的软件系统。所谓“原型系统”就是应用系统的模型，用户在开发者的指导下试用原型，在试用的过程中考核评价原型的特性，分析其运行结果是否满足规格说明的要求，以及规格说明的描述是否满足用户的期望。开发人员根据用户的反馈意见纠正过去交互中的误解和分析中的错误，增补新的要求，并针对因环境变化或用户的新设想而引起系统需求的变动提出全面的修改意见。大多数原型系统中不合适的部分可以修正，修正后就成为新模型的基础，开发者和用户在迭代过程中不断将原型系统完善，直到软件的性能达到用户需求为止，因而快速原型过程模型能帮助开发人员快速完成所需要的目标系统。
快速原型过程模型的主要优点在于它是一种支持用户的方法，它使用户在系统生存周期的设计阶段起到积极的作用，并能减少系统开发的风险。特别是在大型项目的开发中，由于对项目的需求分析难以一次完成，应用快速原型过程模型效果更为明显。
5. 敏捷过程模型
是一种逐渐引起广泛关注的一些新型软件开发方法，由于其具有动态性且很容易适应环境。敏捷软件过程模型是一种迭代式增量软件开发过程。敏捷开发方法是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷软件开发是一个用来替代以文件驱动开发的瀑布开发模式。瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等。瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出的分析导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。
敏捷方法适用于小块工作，这些工作位于每次迭代以及迭代结尾发布的工作软件当中，敏捷方法的主要优势在于，它能完全适应用户环境，而且对产品进行持继迭代，它更注重交付能工作的软件，而不是实现需求规范中定义的需求。
以上5种模型只是众多软件过程模型中较为典型的，除此之外还有喷泉模型、统一软件开发过程模型等。介绍软件过程模型的目的是为了突出软件工程中软件过程模型的重要地位，从某种意义上说，不了解软件过程模型，就不了解软件工程。
同时还应该认识到，形成一套完整而成熟的软件开发过程不是一蹴而就的，它需要一个从无序到有序、从特殊到一般、从定性到定量、最后再从静态到动态的历程，或者说软件开发组织在形成成熟的软件过程之前必须经历一系列的探索阶段。因此，有必要建立一个软件过程成熟度模型来对过程作出一个客观、公正的评价，以促进软件开发组织改进软件开发过程，这就是所谓的软件能力成熟度模型（CMM）要做的工作。