“软件危机”引发的模型碰撞

20世纪50年代，软件诞生。 随着软件技术的发展，在软件开发及维护过程中，一系列问题逐渐浮出水面。关于如何开发软件，以满足不断增长、日趋复杂的需求；如何维护数量不断膨胀的软件产品；软件开发活动高难度、高风险、高失败率的特性等，这些问题都暴露出编写可供检验的、正确的计算机程序的困难程度较高。

1968年，北大西洋公约组织（NATO）针对这一系列问题提出 “软件危机”一词。同时针对“软件危机”，NATO在1968、1969年连续召开两次会议，提出了“软件工程”的概念。“软件工程”作为“软件危机”的解决方法而被提出，人们开始研制和使用软件工具，用以辅助进行软件 项目管理与技术生产。

“软件危机”的出现促使软件开发过程中各个模型涌现，它们之间产生了不同碰撞，摩擦出新的火花：

1.瀑布模型

瀑布模型（又称预测模型）要求软件开发由需求说明为起，进行分析、软件设计、编码、测试，最后进行系统运行与维护。

• 优点：

             瀑布模型要求项目进程按照一定标准，按部就班，各个环节层层推进，最终交付完整的成品。

• 局限：

             标准化模式导致只适合需求明确的项目，以及对于急需交付的项目也并不适合。

2.能力成熟度模型

能力成熟度模型（Capability Maturity Model for Software，简称CMM）的核心是将软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化，使企业能够更好地实现商业目标。 模型分为五个梯级：初始的、可重复的、被定义的、被管理的、优化的，软件开发过程中使软件组织不断走向成熟。这一特点对开发模式的大规模推广和应用起到了推动作用。

• 优点：

             对开发和维护过程进行监控，有效改进软件质量；

             提高软件产品生产率。

• 局限：

             相对关注于部分架构，没有考虑总体成果。

3.快速原型模型

为了适应客户需求的不确定性、变更性，产生了快速原型模型（Rapid Prototype Model）。快速原型是在开发真实系统之前，构造一个原型。这一原型用来获取用户需求的，或是用来试探设计是否有效的。一旦需求或设计确定下来了，原型就将被抛弃。

• 优点：

             相对快速地确定客户需求；

             减少了开发过程中因客户需求变更产生的资源浪费，节省人力、时间成本。

• 局限：

             快速原型因满足不到客户的需求而产生的浪费；

             快速原型不能被长期循环使用。

4.增量模型

增量模型（Incremental Model）融合了瀑布模型的基本成分和原型实现的迭代特征，采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。强调 每一个增量均可产生一个产品，第一个增量往往是核心的产品，即实现了基本需求。

• 优点：

             可以在较短时间内交付第一个版本；

             每个增量系统分担风险。

• 局限：

             每个小增量组合成的系统较为复杂，管理难度提高；

             增量之间会互相产生影响，导致整个系统的不稳定；

             用户需求的变更会导致后续每个增量发生改变。

5.螺旋模型

螺旋模型（Spiral Model）将瀑布模型和快速原型模型结合起来，弥补了两种模式的不足，强调对软件开发的风险分析。模型要求每一周期都包括 需求定义、风险分析、工程实现和用户评估四个阶段，由这四个阶段进行迭代。

• 优点：

             以产品质量为首要目标；

             强调风险分析，降低容错率；

             支持用户需求的动态变化，方便用户参与软件开发的所有关键决策。

• 局限：

             开发人员需要有较强的风险评估的经验。

软件开发者在开发软件工程模型的时候，希望兼顾各方， 既能提高软件的生产效率，又能降低软件开发成本，满足基本的功能需要，例如：产品功能强、性能好、按期交付使用、易于用户操作和维护等。

实际上，软件工程就是要解决如何在用户要求的功能、质量、成本、进度之间取得平衡。因此，为了应对“软件危机”，先后涌现的模型在相互碰撞中，不断优化、改进，力求构建最理想的软件开发模型，解决“软件危机”，满足社会对软件全方位、不同应用领域的应用需求。