软件过程流和过程模式

首先还是引入Howard Baetjer Jr从经济学角度分析的软件过程：软件同其他资产一样，是知识的具体体现，而知识最初都是以分散的、不明确的、隐藏的且不完整的形式广泛存在，因此，软件开发是一个 会学习的过程。软件过程是一个对话的过程，在对话中，获取需要转化为软件的知识，并在软件中现实这些知识。过程提供了用户与设计人员之间、用户与不断演化的工具之间，以及设计人员与不断演化的工具（技术）之间的互动，软件开发是一个迭代过程，在其中演化的工具本身就作为沟通的媒介，每一轮对话都可以从参与的人员中获得更有用的知识。

回头看Baetjer Jr的软件描述，有几个非常关键的描述，“知识最初具有分散、不明确、隐藏、不完整的特性”，而软件是知识的具体体现，不要期望一次就能完全搞明白；“软件过程是一个对话的过程”，而对话是信息传递和获取的过程，同时也是信息对齐的过程，通过不断的对话，甲方和乙方之间才能实现需求的对齐，而这也是软件的原始输入。缺乏深入，就不可能充分的理解问题，后续的相应的计划和措施就会偏离甲方的需求。所以，沟通是重重之重。信息和需求的对齐需要不断的沟通，在沟通中纠正双方的理解不一致，而软件是沟通的结果和目标产物。而软件过程就是保证甲方和乙方之间从信息到结果的无偏差传递，实现目标结果无偏差达成。

这是为什么，在软件过程活动框架中，沟通是活动之首。没有充分沟通，信息对齐，后面的活动都是非常的危险。

软件工程的通用过程框架，Pressman定义为五种框架活动：“沟通、策划、建模、构建、部署“。其实，可以对应到前面一篇文章中提到的，George Polya写作的《How to Slove It》中总结的，”理解问题，制定计划，实施计划，检查结果“，通用问题的处理过程。通过沟通去充分的理解问题，这也是前面描述的软件过程开始最重要的一步；而制定计划对应的就是策划和建模，通过策划和建模的过程进一步完成对问题的分解和处理措施的制定，而实现从问题到落地处理的评估；下面的实施计划就是将前面的解决方案和措施落地，完成将客户的问题形成软件产品，解决客户的诉求，对应到框架活动的构建和部署。细心的读者会提出，怎么没有对检查结果的对应过程！其实，软件过程对结果的检查是分散到不同过程框架活动中，在什么阶段去对结果进行检查，会映射到不同的软件过程模型。

首先，看一下针对五种过程框架的4个不同的过程流，

图1：线性过程流

图2：迭代过程流

图3：演化过程模型

图4：并线过程流

1) 线性过程流：理想过程流，一气呵成。客户需求很明确，后期没有变化，设计人员经验丰富、管理人员身经百战，开发人员各个高手，从需求理解到需求分析再到需求开发完全按照规划和计划执行，最后完成开发、测试、发布和部署，并最终交付到客户手中。

2) 迭代过程流：理想的线性过程流，在现实中几乎不存在的，过程肯定会遇到一次次的不达标或存在偏差，需要通过反馈迭代而进一步修改或优化，这也是迭代过程反向流动箭头有代表的含义，通过多次迭代，让交付的软件产品符合客户需求。

3) 演化过程流：演化过程表示软件产品很难一次达成最终的客户目标，越是需求复杂、功能复杂的系统，越难一次通过类似的线性过程完成产品的交付。需要不断的通过输出过渡的软件产品，逐步演进到最终产品。这个过程跟迭代过程的最大差异在于，迭代过程流是通过对软件过程的不断迭代而去修复某个或某几个过程的偏差，而确保整个过程输出的软件产品符合客户要求。而演进过程是件软件产品交付过程通过多次输出客户可见的软件产品，并对产品进一步优化、改进而最终交付符合客户要求的软件产品。

4) 并线过程流：在梳理软件过程之间的依赖后，有些过程可以并行开展，或在一个过程进行并达到下一个过程启动的条件时，就可以启动此过程，而没有必要非要等上一个过程完全结束。对应到上图4，建模过程可以在沟通过程和策划过程进行到一定阶段后，就启动建模过程。比如，客户有很多需求，不同需求之间也比较独立，完全可以在与客户沟通清楚某个或某些需求后，就并行的启动针对此需求的策划和建模。

其实，上面列出的4个软件过程流，并不是非常充分，也不能完全覆盖实际的软件交付过程。可以将上面的4个软件过程流，看成基础的软件过程流。实际的软件交付过程是对这些软件过程流，按照软件研发过程的需要进行组合使用。后面在分析软件过程模型的时候，也可以看到，一个软件过程模型具有多种软件过程流。

最后，提一下软件的过程模式。搞过软件架构的人，对“模式“应该不会陌生，《设计模式》中的模式，跟软件过程模式中的模式，具有一样的含义。Christopher Alexander说过：“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动“。模式可以说是经验的积累，后人在遇到类似问题时，可以拿来使用（必要时，需要做些适当的调整）。可以说，合理的使用模式，可以让我们的工作事半功倍；人类的进步也可以说是在不断总结模式和使用模式中螺旋前进的。

而软件的过程模式就是描述了软件过程工作中遇到的软件交付过程的相关问题，明确问题环境并给出了针对该问题的一种或几种可证明的解决方案。软件过程模式一般通过一个标准化的模板向使用者展现，模板的形式，可以根据需要进行定制。一般来说，会包含名称、问题、解决方案、效果四个要素，也可以增加，比如目的、类型、启动条件、结束条件等。