SP（软件过程）的发展历程2:计划驱动软件开发过程时代

 

神话的破灭

但是随着软件规模的扩大和软件复杂度的提高，无序的开发过程开始显示出它的弱点，首先，开发质量没有保证。软件错误随着软件复杂度的增加而增加。几次恶性的软件错误导致的巨大损失导致软件危机的出现，软件危机让人们开始怀疑到底能不能开发出可靠的软件。其次，开发进度经常拖延，由于开发过程的随意性和无序性，软件产品更像是软件开发者兴之所至的手工作品，而不是拥有标准质量的工业产品，bug的不断增加和修改bug难度的增加，导致开发进度经常拖延，并且无法确定最后的交付时间。因为没有办法为寻找bug设定时限。软件产业面临迷茫。

 

软件设计变身软件工程

　　

为了摆脱困境，一些软件工程专家开始借鉴建筑，机械和汽车工业的流程的概念和方法试图建立软件工程方法和过程控制及管理模式。一大批软件开发的模型，瀑布模型，螺旋模型等等被提了出来。这些方法的共同特点就是采用严格的开发计划指导设计过程，并控制过程的执行，所以这些方法被统称为计划驱动的工程方法，简称计划驱动方法，也就是传统软件开发方法。计划驱动方法的共同思想根基就是传统工业的生产方法和过程。传统工业生产过程是典型的计划驱动模式，它已经被证明是行之有效的产品质量控制和管理方法和过程，它可以大规模的生产具有一致质量的大量工业品。一大批软件专家坚信它能够被移植到软件生产中来并且能够给软件生产带来革命性的变革。

 

这种方法随后得到了大规模的推广和实施。自上个世纪60年代以来，软件工程思想逐渐形成与发展，也出 现了很多软件开发模型与方法，例如瀑布模型、快速原型、增量模型和螺旋模型等。而在90年代以后，卡耐基梅隆软件学院推出的CMM，更是对于软件开 发的过程管理，提出了确切的衡量指标。这些方法取得了一些成果，软件的及时交付和质量有了一定的保证。但是这种方法并没有像传统工业方法那样取得巨大的成功，计划驱动方法从来没有被充分证明总是有效的，最近的研究表明，依然有50％的项目会拖延交付，有30％以上的项目会超出预算，软件开发领域的项目情况比软件工 程刚刚提出的时候相比，只是有很小的提高。软件开发的生产率依然很低。

 

这是什么原因呢？答案就在于软件生产的特殊性。生产软件不是生产汽车，软件工程也不是机械工程。完全借鉴工程方法不合“国”情。因此注定要失败。软件开发还处于初级阶段，远没有达到靠一套什么工程方法就可以达到大规模生产出具有一致质量的软件产品的程度。软件生产过程和传统工业生产过程至少存在以下几点区别：1，设计需求特点不同。传统工业的设计需求比较固定。因为设计一旦确定就很难改变，传统工业的设计基本上是一次完成的，所以生产过程才可以按照固定计划和方案进行，当然，新的，更加灵活多变的工业生产模式也已经悄然出现，但是整个工业生产模式还没有发生根本改变；而软件的特征之一就是软件的灵活性，软件需求的可变性，适应性很强，这也是软件被称之为“软”的原因。即使没有接触过软件开发的人也认为只要修改几行代码就可以轻易改变软件，所以软件的客户更容易改变需求，并不断提出新的需求。这样一来，依照事先的计划进行设计就很难满足用户快速变化的要求。2，人在过程中的作用不同。传统工业比如建筑和机械行业，设计过程在产品生产过程只占很少的部分，可能占所有工作量的10%左右，因此，依靠人完成的设计工作很少，大量的工作可以依靠机器和生产线完成，大量的工人只需要很少的技能就可以辅助机器完成工业生产工作；而软件生产是一种智力密集的活动。设计活动几乎是软件生产的全部过程，而设计工作，包括编码都要靠人，即程序员完成。在软件生产中，能够自动化完成的生产工作只有编译，链接和安装等工作，这些工作和设计编码工作比起来微乎其微。在传统建筑行业中，设计人员只要设计出图纸就可以交给任何一个工人完成实际工作；而在软件生产中，类似的各种设计工具，设计语言比如UML，不可能达到这样的程度，更多的设计决策只有在编码时才能确定。因此在软件生产中，一般我们认为的设计和编码不可能完全的分开，初期的设计在后期不断修正是司空见惯的。下面我们再详细地讨论软件设计的这些特殊之处。

 

需求是可以预测的吗？是固定的吗？

计划驱动方法的一个重要假设就是设计过程是可预测的，需求是可以预测的，工作量是可以预测的。为了过程的可预测，就必须实现固定设计需求，然后根据设计需求，制订开发计划，分配设计资源，最后按照开发计划完成开发任务。

这个假设和过程设计在传统机械行业是行得通的，但是，对于软件设计，这个前提很少成立，软件设计的需求是固定的吗？不是，软件设计的目标就是要适应不同的情况，弹性应对不同的需求，否则就不要成为“软”件了。因此变化的需求才是软件设计的一般假设，软件必须要适应变化才是软件的真理，而不是相反。

是不是存在需求固定的软件呢？可能神州七号宇宙飞船的软件设计需求是固定的，并且有充足的经费保证完成它。但是，对于大多数商业软件来说，需求必须适应千变万化的商业市场的实际，而不是坐在办公室里的所谓规划出来的需求。正所谓“树欲静而风不止”，就是客户想固定需求，有时候也不得不根据市场的新动向改变需求，以应付市场竞争的压力；还有一点是，由于软件的非直观可见性，客户在设计初期可能根本不能说明他到底要什么功能，或者什么东西是适合的；只有等待产品出来之后，经过试用，客户才真正了解他到底要什么东西，因此软件的改动基本上是不可避免的。因而采用计划驱动方法实施的项目基本是延误的，或者说基本上是失败的。

 

软件过程中人的作用

计划驱动方法的核心就是设计出一个标准化的，不依赖于特定人的流程。在计划驱动方法中，个人的作用弱化了，程序员变成了可以任意替换的机器零件。一个项目只要有项目经理，客户经理，软件架构师，程序员，测试员等等各种角色并且各自扮演好各自的角色就可以保证开发出符合要求，满足进度，高质量的软件。这个方法非常符合管理者的要求和熟悉的思路，通过这样的过程，卖白菜的也可以管理软件项目，只要他严格地按照事先的计划和管理的流程执行就行了；通过这样的流程，原来高贵的软件设计者现在变成了蓝领工人，就象生产线上的工人。管理者重新控制了软件产品的生产。这是管理者梦寐以求的结果。

但是，人真的是无足轻重的吗？艾克·卡文曾经帮助 IBM做关于OO（面向对象）方面的研究工作。他在做这些工作的时候，最主要的任务是访问不同的开发项目，发现成功的项目到底是哪些因素使得这个项目成功。他发现最后 得到的结果非常奇怪，所有的成功的项目他们之间没有一点在过程方面共通的地方。这些项目所共通的唯有一点共通：他们拥有能力非常强、交流非常好的开发团 队。

在软件开发的过程当中，其实最核心的部分应该是开发人员本身。但是，计划驱动的开发方法喜欢把编程人员当成传统工业中的机器来对待，以机器为中心的传统机械生产模式相对来说是静态的，一成不变的，容易控制的。而软件设计是一种智力活动，必须依靠人而不是“编程机器”完成，人与人是有差异的，人是有感情的动物，人的生产率和他自身的状态情绪有很大关系。希望通过过程管理把人变成统一的，没有差异的机器是不可能的。