典型的软件过程模型

0. 软件开发需要过程么？

  写了再改，不挺好么？不需要太多其他准备或相关知识，无需文档，无需规划，无需质量保障，上来就写代码；也许就能写出来，写不出来就改，也许能改好。但是这种写法适用的场合有限:

• “只用一次”的程序
• “看过了就扔” 的原型
• 一些不实用的演示程序

但是要开发一个复杂的软件，这个方法的缺点就太大了，现实中基本毫无用处。

1. 黑盒与白盒过程

• 黑盒测试
  • 概念：测试者不了解程序的内部情况，不需具备应用程序的代码、内部结构和编程语言的专门知识。只知道程序的输入、输出和系统的功能，这是从用户的角度针对软件界面、功能及外部结构进行测试，而不考虑程序内部逻辑结构。测试案例是依应用系统应该做的功能，照规范、规格或要求等设计。测试者选择有效输入和无效输入来验证是否正确的输出；
  • 适用场合：大部分测试，如整合测试和系统测试。
  • 存在的问题：要求开发之前需求被充分理解；与客户的交互只在开始(需求)和最后(发布)——类似于产品制造过程；而实际情况往往不是如此。
    
• 白盒测试
  • 概念：在白盒测试时，以编程语言的角度来设计测试案例。测试者输入数据验证数据流在程序中的流动路径，并确定适当的输出，类似测试电路中的节点。测试者了解待测试程序的内部结构、算法等信息，这是从程序设计者的角度对程序进行的测试。
  • 适用场合：白盒测试可以应用于单元测试、集成测试和系统的软件测试流程，可测试在集成过程中每一单元之间的路径，或者主系统跟子系统中的测试。尽管这种测试的方法可以发现许多的错误或问题，它可能无法检测未使用部分的规范。
  • 优点：通过改进可见性来减少风险；在开发过程中，通过不断地获得顾客的回馈允许变更——类似于服务过程。
    

2. 典型的软件过程模型

• 瀑布模型

  也叫做鲑鱼模型，向前一阶段回溯，很难，特点：

• 上一个阶段结束，下一个阶段才能开始；
• 每个阶段均有里程碑和提交物；
• 上一阶段的输出是下一阶段的输入；
• 每个阶段均需要进行V&V；
• 侧重于文档与产出物。

  优点：简单、易懂、易用、快速；为项目提供了按阶段划分的检查点，项目管理比较容易。总之，追求效率。
  缺点：用户难以清楚地确定所有需求，需求的错误很难在开发后期纠正，因此难以快速响应用户需求变更；开发人员与用户之间缺乏有效的沟通，开发人员的工作几乎完全依赖规格说明文档，容易导致不能满足客户需求。总之，过于理想化。

• 增量过程模型

  在很多情况下，由于初始需求的不明确，开发过程不宜采用瀑布模型。这时增量过程模型应运而生。其分为两种：增量模型和RAD。
  增量模型：软件被作为一系列的增量来设计、实现、集成和测试，每一个增量是由多种相互作用的模块所形成的提供功能的代码片段构成。本质：以迭代的方式运用瀑布模型。
  RAD：侧重于短开发周期(一般为60~90天)的增量过程模型，是瀑布模型的高速变体，通过基于构件的构建方法实现快速开发。

增量模型是串行的瀑布模型，RAD是并行的瀑布模型。

• 演化过程模型

  软件系统会随着时间的推移而发生变化，在开发过程中，需求经常发生变化生变化，直接导致产品难以实现；本质：循环、反复、不断调整当前系统以适应需求变化。其分成两种：快速原型法和螺旋模型。

• 敏捷过程模型
  详情参考：浅谈「敏捷」开发

3. 对比总结

  我个人认为这些方法都有各自适应的情况，瀑布模型追求效率，增量过程模型适用用户需求不断增加，但是核心计划不变，而演化过程模型较为复杂，是在不断迭代，重新策划中进行。
  在短期、项目小、人员有限的情况下，敏捷过程模型是最恰当不过了。