為軟件項目捕獲知識的實用方案

申請免費試用、咨詢電話：400-8352-114

為軟件項目捕獲知識的實用方案

耿俊燕 譯

很少有一個專業(yè)領(lǐng)域象軟件開發(fā)發(fā)展得那樣快。新技術(shù)頻繁地改變著客戶的需求，增大著綜合軟件的體系結(jié)構(gòu)、方法和工具，軟件團體一直在不斷努力跟上新技術(shù)的發(fā)展。最近，許多團體已逐漸意識到想在未來興旺發(fā)展，就必須更有效地在個人、小組和團體級管理和使用知識。有效的產(chǎn)生、分發(fā)和再利用最新的知識是成功的關(guān)鍵因素，然而在實踐中卻很難做到。

在軟件工程的語境中，我們將知識管理定義為一組有助于在整個團體中產(chǎn)生、傳送SE知識的活動、技術(shù)和工具。KM（知識管理）的一個用途是支持軟件過程改進。這種支持是重要的，因為如果不全面了解軟件開發(fā)團體所需的和所做的，那么軟件工程和質(zhì)量管理技術(shù)都不會成功。

那么，怎樣在軟件團體中有效捕獲知識呢？為了回答這個問題，我們在一家開發(fā)軟件密集型電子產(chǎn)品的全球企業(yè)的某一獨立商業(yè)單位中做了案例分析。這家公司想為一個特殊的項目改進軟件開發(fā)知識的捕獲和再利用。它已嘗試了幾次來改進知識的再利用，但所有的嘗試都未奏效。為什么早期的嘗試沒有成功？有效的解決方案是什么？我們從過去遇到的困難和成功著手開始研究這些問題。

分析基于知識管理的SPI（軟件過程改進）的狀態(tài)

對雇員的采訪和相關(guān)的文檔顯示：管理人員的設(shè)計人員都感到許多知識被浪費了。現(xiàn)存的知識很難找到，當找到時已經(jīng)不能再利用了。早期實行的模式顯然不成功。

根本的目標曾是通過增加不同項目的知識傳輸來減少軟件缺陷。將要共享的信息存貯在“l(fā)essons to learn”數(shù)據(jù)庫中。采訪清楚地顯示許多項目的管理人員不知道數(shù)據(jù)庫的存在，幾乎沒有人使用它。對數(shù)據(jù)庫的分析表明大量條目是不完備的，四個主題部分只有一部分被積極使用。按照數(shù)據(jù)庫概念擁有者的說法，這是因為準備數(shù)據(jù)庫條目很耗時而且管理數(shù)據(jù)很困難。另外，數(shù)據(jù)的正確性和關(guān)聯(lián)是不明顯的，因為大部分提供的數(shù)據(jù)不帶數(shù)據(jù)結(jié)構(gòu)。

項目間共享知識的另一途徑是Data Transfer Days（數(shù)據(jù)轉(zhuǎn)移日）. 這些會議關(guān)注于分析過去的問題和成功的事例。與會者在會議期間捕獲并共享重要的知識，盡管當他們的項目結(jié)束后，回憶過去的成功和失誤會有些困難。會議的目的是通過分析、打包并保存會議的結(jié)果，為新項目提供參考，不幸的是，在這一點上，積極性通常消失了。會議主要對那些能參加的人有用。然而，組成員間自由的面對面談話最終成為比數(shù)據(jù)庫更好的知識共享方式。

正如所看到的，Data Transfer Days，尤其是lessons to learn數(shù)據(jù)庫都不能象原先希望的那樣起作用。對于后者，很明顯的原因是項目管理過程不能并入存貯、搜索知識的方針中。數(shù)據(jù)庫的有效使用可能會需要更多培訓(xùn)過程和在捕獲、整理、搜索、保持及再利用知識方面付出更多努力。此外，許多項目管理人員過于忙著解決日常問題而不愿承擔(dān)更多的責(zé)任。我們的采訪也顯示軟件設(shè)計者寧愿相信身邊的任何人，也不愿相信任何特定的專家或共享數(shù)據(jù)庫。

調(diào)查這些問題的研究者已在別處發(fā)現(xiàn)了與我們相似的問題，并提出以下知識再利用失敗的原因：知識捕獲過程太不正式，沒有并入工程過程或不為團體的系統(tǒng)結(jié)構(gòu)所支持。Davenport和Prusak聲明如果想以技術(shù)為核心的解決方案（例如，數(shù)據(jù)庫）開始，而忽視行為的、文化的和團體的變化，那么所期望的優(yōu)勢不會體現(xiàn)出來。

尋覓新的解決方案

這一團體制訂了有挑戰(zhàn)性的要求：新的解決方案應(yīng)對軟件開發(fā)團體和過程有最小的影響，而且不應(yīng)依靠新的技術(shù)。因為現(xiàn)存過程不應(yīng)被觸動，簡單的、人工操作的、離線的方法是更可取的，它免除了知識管理過多的負擔(dān)。這種軟件過程改進行動旨在創(chuàng)造一個有助于公司從現(xiàn)存資源中得到經(jīng)驗的過程，例如公司的數(shù)據(jù)庫和人員，這一過程可以應(yīng)用于正在進行的SE項目。一個需要定義和驗證的新方法是使用軟件過程改進專家作為知識捕獲代理，而不是讓軟件開發(fā)者匆匆忙忙地親自做這件事。這種方法將項目看作是需要特定知識的個別客戶。與為隨后的項目做的大規(guī)模調(diào)查、分析、整理、共享和更新知識工作相比，應(yīng)集中努力于客戶現(xiàn)有的知識需求。

公司的軟件過程改進人員和外部專家建立了一種捕獲知識的新方法。這種新方法包括知識捕獲項目和客戶項目。前者從相關(guān)來源收集知識、整理知識，并把它提供給一個客戶項目以使得即時再利用。這種解決方法沒有改變團體設(shè)置，也不需任何新的工具。知識可能來源于現(xiàn)有資源如項目最終報告、出錯信息數(shù)據(jù)庫、討論會和人（這是最重要的）。最后，這種假想證明是正確的。圖1顯示了一個簡化的捕捉過程。

圖1

與其它方法不同，這種方法不能期望正在進行的軟件項目提供經(jīng)驗。知識捕獲項目與經(jīng)驗軟件工程框架中的分析團體很相似，因為該項目分析知識并將知識打包到可再利用資產(chǎn)中。然而，知識捕獲過程做這件事是為滿足客戶項目的即時需要。

我們和公司一起在迫切需要界面相關(guān)知識的項目上驗證這種方法。這種特殊知識在多種文檔、備忘錄、數(shù)據(jù)庫和人們間傳播。Lessons to learn數(shù)據(jù)庫不提供這類知識，Data Transfer Days也無濟于事?？蛻繇椖康男枰桥帕泻玫?，來顯示需要哪些特定知識，需要哪種形式的知識，知識會怎樣被重新利用。這些需要也被分成過程相關(guān)的和產(chǎn)品相關(guān)的知識。前者包括軟件設(shè)計和驗證任務(wù)，作用，團體、技巧、方法和工具，后者包括產(chǎn)品的描述、界面和產(chǎn)品家族的層次。我們按計劃追蹤了知識捕獲過程，用半結(jié)構(gòu)化的采訪作為獲取知識的主要技術(shù)。這一過程花費了300小時，最耗力的階段是經(jīng)驗整理，這花了一大半時間。

傳送的界面知識包充分滿足了它所有的需求：客戶項目檢索、現(xiàn)有界面所需的知識。選擇的辦法很起作用，客戶項目非常及時地得到了所需知識。

盡管我們承認簡單案例研究的局限性，我們?nèi)院敛贿t疑地質(zhì)疑把以技術(shù)為中心的解決方案作為管理軟件開發(fā)知識的主要方法。我們認為我們的研究是邁向更廣泛基于需求的知識管理方法的第一步。我們將繼續(xù)擴大這種及時知識管理過程的使用，將努力使它成為正常項目入門步驟的一部分。隨著時間的推移，我們的努力將有助于提供結(jié)構(gòu)化的、打包過的信息，這些信息對軟件項目有真正的價值。

本文原載于計算機世界