软件和需求的实践（2）

　　有个英国人学煮鸡蛋，开始，他把鸡蛋放到开水里煮时总会炸裂。他为此想了各种方法，并找到了一个解决方案：在鸡蛋上打个孔。但在鸡蛋上打孔带来了另一个问题:孔打小了，鸡蛋还会裂；孔打大了，蛋清会在它凝固以前流出来。于是，这个英国人给一批鸡蛋分别打了各种不同孔径的洞，并记录下每个鸡蛋孔径的大小。通过这一方法，他找到了一个最合适的大小──既避免了炸裂，又保证蛋清不会流出来。这时，虽然煮鸡蛋炸裂的问题解决了，但这个英国人仍然不知道煮多长时间才能把鸡蛋煮熟。为了解决这个问题，他又开始尝试煮不同时间的结果，并从中找出最佳的时间长度。最后，他终于找到了一个放之四海而皆准的煮鸡蛋的方法。这个案例对很多中国人来说是个可笑的例子。因为聪明的中国人早就知道把鸡蛋放在水中与之一起加热至鸡蛋浮起来就可以了。 从煮鸡蛋这样一个小小的事件上，中国人和英国人体现了两种完全不同的思维习惯──中国人凭借他的聪明直奔结果，而英国人却仔细地把每一个过程细化到最简单，然后按部就班地执行。（管理软件的发展之路 洪奇）

　　聪明的中国人虽然拥有四大发明，但是对于现代的管理思想，中国人一直没有领会到真谛所在。无论是哪一种的管理方法，过程能力都是特别重要的，虽然生产一件产品的相关人员有千千万万，但是生产出来的产品却只有一种。这种能力并不是从天上掉下来的，是通过制定极为详尽的生产过程规定得到的。在中国接受了ISO的思想之后，这种能力也在国内的制造业中逐渐体现出来。但是在软件行业中，拥有这种过程能力的软件组织仍然是少的可怜，大多数的软件组织奉行的还是一种在八九十年代的个人英雄主义，开发软件单靠个人的力量，能力强的程序员能够成功的完成软件，能力差的则失败。大多数的软件组织中，少数人掌握着代码，他们就是一切，如果他们因为私人原因离开所在的组织，手上的代码则是他们的资本，原有的组织将受到沉重的打击。 中国人热衷于结果，2001年的热点在CMM上，现在还很难说CMM中是不是有一定的泡沫存在，但是可以肯定的一点是，CMM之进入中国软件组织为中国软件工业的发展开创了一个新的时代。中国的软件工业将逐渐摆脱原来的作坊式开发，进入软件工业时代。之所以用软件工业而不用软件产业的原因是希望软件产品能够像工业革命那样进入大规模生产，降低价格的时代。

　　可惜，软件毕竟不同于工业产品，在工业化生产的过程中，质量检测的一个方法是在产品出厂前设置质量检测，通过质量检测的出厂，否则回收。这种方法无法适用于软件。后来，质量检测逐渐倾向于生产过程，在过程中监测产品质量。这种方法比起前一种方法进步了很多，但是它需要对生产全过程进行追踪。这种方法的思想正是软件过程的质量保证的精髓所在。

　　在《软件工程》一书中，作者把软件工程分成三层，最底层是软件过程，上一层是软件方法，最高层是CASE工具。软件过程中充满了各种各样的方法论，从需求到最后的维护。要在自己软件组织中应用所有的方法是不可能的。所以你如果看完软件工程的文章后有一种要在明天就实现现代化的冲动的话，打消那种念头，从零做起。

需求过程

　　需求过程是软件过程的一个很重要的部分。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的"祸根"（Leffingwell 1997）。我在自己的身边也做过一次小范围的调查，结果显示成功的项目都离不开成功的需求（一个重要的标志是用户的支持）。

　　需求过程，也有叫做需求工程和需求阶段的，包括了需求开发和需求管理，他们所涉及到的具体工作流如图所示：

　　需求分析的这个过程，我们可以称它为需求工程，也有叫做需求过程和需求阶段的。需求工程包括了需求开发和需求管理，他们所涉及到的具体工作流如上图标明的那样。

需求过程和CMM

　　软件工程协会 (SEI Software Engineering Institude) 的能力成熟度模型 (CMM Capability Maturity Model) 提供了一种著名的软件过程成熟度基准。CMM 已经成为了许多领域内的流行工具，用于评估一个组织的软件过程的成熟程度。（更详细的定义和说明请参看《CMM白皮书》）。

　　CMM中和需求有关系的是第2级（可重复级）中对需求管理的要求和第3级（已定义级）中对需求跟踪能力的要求。必须指出的是，CMM只是规定成熟的软件组织应该达到的关键能力，是一种改进软件过程的策略，对具体的方法并没有做限制规定。所以CMM中没有涉及到需求开发的内容。

需求过程和软件生命周期模型

　　任何软件都是从最模糊的概念开始的：为某个公司设计办公的流程处理；设计一种商务信函打印系统并投放市场。这个概念是不清晰的，但却是最高层的业务需求的原型。这个概念都会伴随着一个目的，例如在一个"银行押汇系统" 的目的是提高工作的效率。这个目的将会成为系统的核心思想，系统成败的评判标准。99年政府部门上了大量的OA系统，学过一点Lotus Notes的人都发了财（IBM更不用说了），但是更普遍的情况是，许多的政府部门原有的处理模式并没有变化，反而又加上了自动化处理的一套流程。提高工作效率的初衷却导致了完全不同的结果。这样的软件究竟是不是成功的呢？

　　从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为"生命周期模型"（Life Cycle Model）。

　　典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。瀑布模型（Waterfall Model）首先由Royce提出。该模型由于酷似瀑布闻名。在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。想象一下，你去买衣服的时候，售货员给你出示的是一本厚厚的服装规格说明，你会有什么样的感触。虽然瀑布模型有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有