为软件项目捕获知识的实用方案

耿俊燕 译

很少有一个专业领域象软件开发发展得那样快。新技术频繁地改变着客户的需求，增大着综合软件的体系结构、方法和工具，软件团体一直在不断努力跟上新技术的发展。最近，许多团体已逐渐意识到想在未来兴旺发展，就必须更有效地在个人、小组和团体级管理和使用知识。有效的产生、分发和再利用最新的知识是成功的关键因素，然而在实践中却很难做到。

在软件工程的语境中，我们将知识管理定义为一组有助于在整个团体中产生、传送SE知识的活动、技术和工具。KM（知识管理）的一个用途是支持软件过程改进。这种支持是重要的，因为如果不全面了解软件开发团体所需的和所做的，那么软件工程和质量管理技术都不会成功。

那么，怎样在软件团体中有效捕获知识呢？为了回答这个问题，我们在一家开发软件密集型电子产品的全球企业的某一独立商业单位中做了案例分析。这家公司想为一个特殊的项目改进软件开发知识的捕获和再利用。它已尝试了几次来改进知识的再利用，但所有的尝试都未奏效。为什么早期的尝试没有成功？有效的解决方案是什么？我们从过去遇到的困难和成功着手开始研究这些问题。

分析基于知识管理的SPI（软件过程改进）的状态

对雇员的采访和相关的文档显示：管理人员的设计人员都感到许多知识被浪费了。现存的知识很难找到，当找到时已经不能再利用了。早期实行的模式显然不成功。

根本的目标曾是通过增加不同项目的知识传输来减少软件缺陷。将要共享的信息存贮在“lessons to learn”数据库中。采访清楚地显示许多项目的管理人员不知道数据库的存在，几乎没有人使用它。对数据库的分析表明大量条目是不完备的，四个主题部分只有一部分被积极使用。按照数据库概念拥有者的说法，这是因为准备数据库条目很耗时而且管理数据很困难。另外，数据的正确性和关联是不明显的，因为大部分提供的数据不带数据结构。

项目间共享知识的另一途径是Data Transfer Days（数据转移日）. 这些会议关注于分析过去的问题和成功的事例。与会者在会议期间捕获并共享重要的知识，尽管当他们的项目结束后，回忆过去的成功和失误会有些困难。会议的目的是通过分析、打包并保存会议的结果，为新项目提供参考，不幸的是，在这一点上，积极性通常消失了。会议主要对那些能参加的人有用。然而，组成员间自由的面对面谈话最终成为比数据库更好的知识共享方式。

正如所看到的，Data Transfer Days，尤其是lessons to learn数据库都不能象原先希望的那样起作用。对于后者，很明显的原因是项目管理过程不能并入存贮、搜索知识的方针中。数据库的有效使用可能会需要更多培训过程和在捕获、整理、搜索、保持及再利用知识方面付出更多努力。此外，许多项目管理人员过于忙着解决日常问题而不愿承担更多的责任。我们的采访也显示软件设计者宁愿相信身边的任何人，也不愿相信任何特定的专家或共享数据库。

调查这些问题的研究者已在别处发现了与我们相似的问题，并提出以下知识再利用失败的原因：知识捕获过程太不正式，没有并入工程过程或不为团体的系统结构所支持。Davenport和Prusak声明如果想以技术为核心的解决方案（例如，数据库）开始，而忽视行为的、文化的和团体的变化，那么所期望的优势不会体现出来。

寻觅新的解决方案

这一团体制订了有挑战性的要求：新的解决方案应对软件开发团体和过程有最小的影响，而且不应依靠新的技术。因为现存过程不应被触动，简单的、人工操作的、离线的方法是更可取的，它免除了知识管理过多的负担。这种软件过程改进行动旨在创造一个有助于公司从现存资源中得到经验的过程，例如公司的数据库和人员，这一过程可以应用于正在进行的SE项目。一个需要定义和验证的新方法是使用软件过程改进专家作为知识捕获代理，而不是让软件开发者匆匆忙忙地亲自做这件事。这种方法将项目看作是需要特定知识的个别客户。与为随后的项目做的大规模调查、分析、整理、共享和更新知识工作相比，应集中努力于客户现有的知识需求。

公司的软件过程改进人员和外部专家建立了一种捕获知识的新方法。这种新方法包括知识捕获项目和客户项目。前者从相关来源收集知识、整理知识，并把它提供给一个客户项目以使得即时再利用。这种解决方法没有改变团体设置，也不需任何新的工具。知识可能来源于现有资源如项目最终报告、出错信息数据库、讨论会和人（这是最重要的）。最后，这种假想证明是正确的。图1显示了一个简化的捕捉过程。

图1

与其它方法不同，这种方法不能期望正在进行的软件项目提供经验。知识捕获项目与经验软件工程框架中的分析团体很相似，因为该项目分析知识并将知识打包到可再利用资产中。然而，知识捕获过程做这件事是为满足客户项目的即时需要。

我们和公司一起在迫切需要界面相关知识的项目上验证这种方法。这种特殊知识在多种文档、备忘录、数据库和人们间传播。Lessons to learn数据库不提供这类知识，Data Transfer Days也无济于事。客户项目的需要是排列好的，来显示需要哪些特定知识，需要哪种形式的知识，知识会怎样被重新利用。这些需要也被分成过程相关的和产品相关的知识。前者包括软件设计和验证任务，作用，团体、技巧、方法和工具，后者包括产品的描述、界面和产品家族的层次。我们按计划追踪了知识捕获过程，用半结构化的采访作为获取知识的主要技术。这一过程花费了300小时，最耗力的阶段是经验整理，这花了一大半时间。

传送的界面知识包充分满足了它所有的需求：客户项目检索、现有界面所需的知识。选择的办法很起作用，客户项目非常及时地得到了所需知识。

尽管我们承认简单案例研究的局限性，我们仍毫不迟疑地质疑把以技术为中心的解决方案作为管理软件开发知识的主要方法。我们认为我们的研究是迈向更广泛基于需求的知识管理方法的第一步。我们将继续扩大这种及时知识管理过程的使用，将努力使它成为正常项目入门步骤的一部分。随着时间的推移，我们的努力将有助于提供结构化的、打包过的信息，这些信息对软件项目有真正的价值。

本文原载于计算机世界