為軟件項(xiàng)目捕獲知識的實(shí)用方案

申請免費(fèi)試用、咨詢電話：400-8352-114

為軟件項(xiàng)目捕獲知識的實(shí)用方案

耿俊燕 譯

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

在軟件工程的語境中，我們將知識管理定義為一組有助于在整個(gè)團(tuán)體中產(chǎn)生、傳送SE知識的活動、技術(shù)和工具。KM（知識管理）的一個(gè)用途是支持軟件過程改進(jìn)。這種支持是重要的，因?yàn)槿绻蝗媪私廛浖_發(fā)團(tuán)體所需的和所做的，那么軟件工程和質(zhì)量管理技術(shù)都不會成功。

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

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

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

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

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

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

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

尋覓新的解決方案

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

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

圖1

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

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

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

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

本文原載于計(jì)算機(jī)世界