软件危机与软件过程模型

1 前言

由于我的本科专业为计算机科学，软件工程不属于我的必修课程，导致我虽然是计算机科班学生，却缺乏软件工程相关的知识。在实习招聘过程中，软件工程知识，尤其是软件过程模型相关的知识，常被问及。因此正好借高级软件工程期末博客的机会，记录下自己课内外对于软件危机和软件过程模型的一些收获。

为江北等地区用户提供了全套网页设计制作服务，及江北网站建设行业解决方案。主营业务为成都网站设计、做网站、江北网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！

2 软件危机

软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。由于软件规模越来越大，软件复杂性越来越高，可靠性问题也越来越突出，软件概念结构的复杂性，无法达成软件概念的完整性和一致性，迫切需要改变软件生产方式，提高软件过程效率，软件危机随之爆发。

有关软件危机的争论是从1975年的《人月神话》开始的，Fred Brooks在书中指出大型项目中难以汇集众多软件过程参与人员的设计理念，从而使得大型软件项目往往会进展缓慢、成本暴涨及错误百出，这是软件危机的典型体现。

1986年，Brooks发表了一篇著名的论文“没有银弹（No Silver Bullet: Essence and Accidents of Software Engineering）”，断言“在10年内无法找到解决软件危机的杀手锏（银弹）。

1990年，面向对象分析与设计领域的大师Brad Cox，针对Brooks的观点，发表了一篇重要文章“有一个银弹（There Is a Silver Bullet）”，以说明他找到了应对软件危机的杀手锏，即经济上的利益诱导会促使人类将软件组件内的复杂结构包装起来，使得软件组件简单易用，由这些组件整合而成的大型软件，自然也简单易用，从而软件危机得以化解。

1995年初，Brooks的名著《人月神话》第二版出版，书中的文章里Brooks赞扬Brad Cox的文章，但他仍然认为杀手锏仍未出现。

1995年底，作为回应，Brad Cox发表了文章“No Silver Bullet Reconsidered”。文章里Brad Cox深刻探讨了文化和思维范式的变迁，从人类文化的观点阐释软件危机的原因，最终得到乐观的结论：解决软件危机的杀手锏（银弹）是可能的。简单来说，Brad Cox认为可以利用软件供应链来鼓励组织和个人生产、买卖软件组件以及更小的子子孙孙组件。如果买卖各层组件者皆有利可图，形成产业链，人们自然会想尽办法将组件封装得简单易用。

如今来看，Brooks的预测是千真万确的，软件危机的困境依然没有从根本上找到解决方法。

3 软件过程模型

作为软件工程延缓软件危机的努力，软件开发过程模型应运而生。软件开发过程模型是指软件开发全部过程、活动和任务的结构框架。软件开发包括分析、设计、实现、交付和维护阶段。 使用软件开发过程模型有以下几点好处：

• 让整个项目团队对软件开发过程有一致的理解（项目团队）
• 让我们审视软件过程中是否有活动上的冲突，是否有重复劳动和遗漏。（活动本身）
• 在规划软件过程时，方便我们为特定的目标评估合适的软件过程。（规划）

3-1 瀑布模型

瀑布模型（Waterfall） 是最简单的软件开发历史上第一个模型。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。瀑布模型易于理解，但是这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：

• 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
• 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
• 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果；

3-2 原型化的瀑布模型（快速原型）

由于瀑布模型在软件过程的后期才能看到结果，会将各种风险积攒到后期，为了尽早暴露风险进行风险控制，在瀑布模型的基础上增加一个原型化阶段，可以将风险前移。

原型就是根据需要完成的软件的一部分，完成哪一部分是根据开发原型的目标确定。例如需求分析阶段原型可以是用户接口原型，可以有效地整理需求，提供直观的反馈形式，有利于确认需求是否被准确理解；在设计阶段，原型可能是系统架构的一部分，有利于验证技术方案的可行性。

3-3 V模型

V模型也称为V模型或验证与验证模型，是瀑布方法的扩展。使用 V 模型时，进度并不会直线移动，而是在实施和开发后逐渐上升。

对于V型项目，早期测试介入是与瀑布模型相比的主要区别。每个开发阶段都有一个并行测试阶段，这有助于在继续下一步之前验证和验证每个步骤。单元测试、集成测试和系统测试在不同层面验证设计，交付测试确认需求是否得到满足。

3-4 迭代和增量模型

迭代和增量模型将迭代设计和工作流与增量构建模型结合在一起。在这种情况下，团队将按周期开发产品，并以渐进方式构建小零件。开发的交付策略分为两种，一是增量开发，二是迭代开发。增量开发就是从一个功能子系统开始交付，每次交付会增加一些功能，这样逐步扩展功能最终完成整个系统功能的开发。迭代开发是首先完成一个完整的系统或者完整系统的框架，然后每次交付会升级其中的某个功能子系统，这样反复迭代逐步细化最终完成系统开发。

迭代和增量模型的一个有价值的特点是可以在不知道所有需求的情况下开始开发。该模型包含其他模型的步骤——需求收集，设计，实施和测试，但要经过多次构建。开发团队可以利用先前构建中取得的成就来改善下一构建。迭代和增量模型可能看起来像一组微型瀑布模型或微型 V 形模型。

3-5 螺旋模型

螺旋模型是一种演化软件开发过程模型，兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型被认为是最灵活的 方法之一。它从迭代模型及其重复中获得启发。该项目以“螺旋式”的方式反复经历四个阶段，直到完成为止，从而可以进行多轮改进，在每个迭代阶段，构建原型是螺旋模型减小风险的基本策。迭代过程主要分为四个阶段：制定计划、风险分析、实施工程、客户评估。

螺旋模型主要用于大型项目，它允许构建高度定制的产品，并且用户反馈可以在项目的早期就被纳入。但可能有项目会形成永无止境的螺旋式发展的风险。

3-6 敏捷模型

敏捷模型是迭代和增量方法的组合，致力于通过早期交付工作软件来适应灵活的需求并满足用户和客户的需求。敏捷项目中的需求和解决方案可能会在开发过程中发展。

通过敏捷开发，该产品被分为小的增量构建，并以迭代方式交付。将所有任务划分为较小的时间范围，以便为每个版本准备工作功能。最终产品版本包含所有必需的功能。敏捷开发是技术行业中使用最广泛的。敏捷软件开发生命周期有许多成熟的方法，最受欢迎的两个是Scrum和看板。

4 总结

在我看来，软件危机从未被真正解决，当下一次应用需求和开发能力错位时可能还会出现（比如量子计算机的软件开发），但软件工程会通过不断地改进和优化软件开发过程来延缓这个危机。
高级软件工程课程让我受益颇多，课程内容十分实用。Vscode和Git命令大大提升了我平时的开发效率和编码体验，软件工程思想也给我带来了很多启发，让我在设计编码时能衡量代码架构的合理性。本文所述的软件开发过程模型知识补足了我在软件工程专业方面的短板，感谢老师一学期的陪伴和教导。

参考资料：代码中的软件工程 https://gitee.com/mengning997/se

网页题目：软件危机与软件过程模型
转载来源：http://scjbc.cn/article/dschgps.html