过程塑造:（二）知识接力

在软件过程中，我们如何保证信息能够得到正确的传递呢？我们用什么方法来避免信息传递的失真呢？我们如何在这样一个过程中处理人与人之间的交互呢？在正确传递信息的情况下，我们又如何保证投入的最小化呢？
意图
软件开发过程是知识传递、知识转换的过程。注重知识转换中的完整性，保证知识经过各个阶段和活动，顺利的转换为软件是极为重要的。
示例
元朗公司是国内某银行的下属企业。从年初开始，公司就投入了大量的人力为银行开发新版本的国际收支系统。考虑到这是一个非常庞大的系统，因此公司把原先的软件开发团队扩大了一倍，补充的人员有些来自于其它的项目组，有些人员来自别的公司。为了保证开发的顺利进行，项目经理引入了软件过程。但是从一开始，麻烦的事情就出现了。项目组中的技术人员和银行的领域专家之间不断出现意见相左的情况。主要的问题是后加入的员工对目标领域不熟悉，难以配合领域专家的工作。最糟糕的是，某些领域专家身处异地，因此在需求分析的中期，开发团队邀请这些异地的领域专家来到开发所在地，进行了为期两天的讨论会。结果并不理想，讨论会上充满了对原先已定稿的需求的反对性意见，技术专家、领域专家吵成一团。需求分析阶段不得不在原先的基础上延长了50%的时间。在进入设计和编码阶段之后，问题少了许多。但在设计到编码的过程中仍是出了一些麻烦，原因是新加入的人员不熟悉开发团队的设计风格。经过一番周折，问题基本解决了。可等到项目进入到测试阶段，矛盾一下子就凸现出来了。测试报告指出，软件中存在着大量的问题，大部分的问题都被定性为无法满足需求的严重错误。经过对错误的复审，排除了其中17%的严重错误。经过分析，发现其中70%的错误都是发生在后加入人员负责的模块中。而产生大量错误的一个主要原因是在编码阶段，由于银行启用了新的会计制度，导致大量模块被修改，由于时间紧迫，因此没有进行正规的需求调研。现在看来，领域专家和技术专家对同一个问题的理解并不相同。最后，项目的开发周期延长了40%。
上下文
软件过程每经历一个阶段，就会发生一次知识转换的情况。这种转换是由人来完成的，这就是像是接力一样，一个人把脑中的知识以某种方式传递给另一个人，再有另一个人传递下去，直至编码人员把这些知识固化在最终的软件中。在软件成型之前，知识的主要载体是文档和模型。我们称它们为工件（Artifact）。例如，需求阶段时，领域专家在技术专家的帮助下，将自己脑中对领域的认识传递给技术人员，并最终形成需求规格书或是用例模型。而在分析设计阶段，技术专家借助需求规格书，把脑中对软件的初始认识进一步转换为分析模型、设计模型、数据模型等工件。最后，在编码阶段，编码人员把这些工件中隐藏的知识转化为软件的形式。经过测试和部署，软件将会交付到用户手中。这是非常典型的软件开发过程，再简单的软件开发也需要经历上述的这些阶段。
可以看到，在上述的软件开发过程中，知识形式发生了两次的重要转换，知识所属角色也改变了两次。知识完成第一次的形式转换之后，将成为需求规格书（或同类工件）的形式，知识从领域专家的脑中转换到技术专家的脑中。然后，知识开始了第二次的形式转换，形成设计模型（以及同类工件）。随着知识从技术专家转移到编码人员，知识转换为其最终的软件形式。在这些转换的过程中，最容易出现信息遗漏、信息失真的情况。保证转换过程中知识的完整性和正确性，对软件开发具有重要的意义。

原文转自：http://www.ltesting.net