基于CMMl模型的K公司軟件開發(fā)項目體系

毛程佳

(科多思（北京）咨詢有限公司上海分公司，上海 200335)

1 引言

K公司目前的主要業(yè)務是為各大通信運營商提供各種服務，包括域名系統(tǒng)(DNS)、電話號碼映射(ENUM)服務和認證授權(quán)計費(AAA)服務等產(chǎn)品。由于該產(chǎn)品是從瑞典轉(zhuǎn)移來到上海，缺乏核心骨干的技術(shù)支持，并且沒有嚴格的軟件項目管理模式。雖然有相關(guān)的項目管理人員，但是從傳統(tǒng)的瀑布型開發(fā)模式變革為敏捷開發(fā)模式，項目管理人員并沒有相關(guān)的項目管理經(jīng)驗和相關(guān)的培訓，需要一定的時間去適應新的環(huán)境以及開發(fā)模式。這就導致了項目開發(fā)過程中出現(xiàn)了各種問題，例如，沒有定期進行項目階段審評、日程進度安排不合理、對項目進度估計失誤、拖延工期、一定程度返工，即使勉強按照項目計劃完成，產(chǎn)品質(zhì)量也達不到預期要求。因此，分析并解決上述問題成為企業(yè)的當務之急，有必要深入研究質(zhì)量管理相關(guān)的方法，從而構(gòu)建適合K公司軟件開發(fā)的質(zhì)量管理體系。

2 軟件項目質(zhì)量管理

軟件質(zhì)量往往是軟件工程的核心所在。軟件質(zhì)量是一個被過度使用的術(shù)語，它對不同的人意味著不同的東西，其主要包括了軟件質(zhì)量管理、質(zhì)量管理計劃、質(zhì)量保證、質(zhì)量控制、文檔及其相關(guān)的缺陷跟蹤。

軟件質(zhì)量的含義可以概括為：一個實體的特征的總和，它依賴于滿足明確和隱含需求的能力。這意味著交付的軟件產(chǎn)品必須按照定義的需求。

2.1 CMMI概述

能力成熟度模型集成(CMMI)是一個過程和行為模型，可以幫助組織簡化過程改進，并鼓勵生產(chǎn)效率高的行為，從而降低成本、產(chǎn)品和服務開發(fā)中的風險。

2.2 CMMI的組織成熟度層次

CMMI將能力成熟度分為5個等級，分別是：初始級、已管理級、已定義級、量化管理級和優(yōu)化級。這5個等級中每一個等級構(gòu)成了下一級的基礎(chǔ)。CMMI為改進一個組織的過程提供了一個單一的集成化框架，新的集成模型框架消除各個模型的不一致性，減少模型間的重復，增加透明度和理解，建立一個自動的、可擴展的框架，從而從整體上改進產(chǎn)品的質(zhì)量和組織的效率。

K公司的目標是將其組織提升至第4級，即量化管理層次。

2.3 CMMI的能力等級

CMMI能力等級描述了組織對于過程域的能力，能力由相關(guān)的共性和特定實踐組成，該過程域可以改進與其相關(guān)的組織流程。每一層都是持續(xù)過程改進的基礎(chǔ)。

CMMI將能力等級分為6個等級：不完整級、已執(zhí)行級、已管理級、已定義級、定量管理級和優(yōu)化級。

2.4 CMMI的表達方式

根據(jù)所使用的領(lǐng)域（獲取，服務，開發(fā)）的不同，它所包含的過程域?qū)⒂兴煌＿^程域是CMMI模型的基本組織特征。表1列出了CMMI 1.3版本所定義的17個核心過程域。

表117個核心過程域

度量與分析組織過程定義組織過程焦點組織績效管理組織過程績效組織培訓項目跟蹤與監(jiān)控項目計劃過程域產(chǎn)品質(zhì)量保證量化項目管理需求管理風險管理供應商協(xié)議管理2335432224232

3 基礎(chǔ)過程管理過程域

3.1 組織過程定義

目的：建立和維護一組可用的過程資產(chǎn)。

步驟：創(chuàng)建組織過程資產(chǎn)：

(1)建立組織的標準過程。

(2)建立生命周期模型描述。

(3)制定裁剪標準和指導方針。

(4)建立組織的過程資產(chǎn)庫。

(1)將每個標準過程分解為組成數(shù)個過程元素，以了解和描述過程所需的細節(jié)。每個過程元素涵蓋一系列相關(guān)的活動。過程元素可能包含模板、片段、需要細化的抽象等內(nèi)容。

(2)指定每個過程元素的關(guān)鍵屬性。

(3)指定流程元素之間的關(guān)系。

(4)文檔化組織標準的標準過程。

3.1.2 創(chuàng)建組織生命周期模型描述

—— 瀑布模型

圖1 瀑布模型

—— 增量模型

圖2 增量模型

—— 極限編程模型

這段時間里，老鄧頻繁地來現(xiàn)場勘查。當然，他每次都會開玩笑，要么是一瓶酒，要么是一斤糖或幾斤鹽。剛開始是丁主任主動送的，后來成了老鄧主動要，而且每次都毫不含糊，好像根本沒看見丁主任越來越哭喪的臉。

圖3 極限編程模型

—— 快速原型模型

圖4 快速原型模型

3.1.3 制定組織裁剪標準和指導方針

裁剪的目的就是為標準軟件過程裁剪，提供框架和總體指導方針，進而利用現(xiàn)有的資源優(yōu)化現(xiàn)有的流程。K公司擬定每月進行一次內(nèi)部審核，當月如果遇到新的文檔或有待解決的問題時，會根據(jù)審核報告進行項目改進計劃，并結(jié)合裁剪準則進行裁剪。

表2 制定組織裁剪標準

3.1.4 創(chuàng)建組織過程資產(chǎn)庫

組織過程資產(chǎn)庫的集合主要包含：

(1)過程和過程元素的描述，例如各工作流程、流程中各元素的定義等。

(2)生命周期的描述，針對整個軟件開發(fā)和維護生命周期的描述，例如，從何時開始，到何時結(jié)束，當中經(jīng)過幾次小版本和大版本的發(fā)布。

(3)過程裁剪的指導方針。

(4)過程相關(guān)的文檔和數(shù)據(jù)。

3.2 組織級培訓

組織級培訓提供崗位所需的技能培訓，并以此提高技術(shù)人員專業(yè)能力和工作技巧。許多開發(fā)人員甚至是管理人員沒有意識到組織級培訓的重要性和前瞻性。為了能夠讓開發(fā)人員整體上達到組織級別的需求，項目組應當定期地組織培訓，分享工作經(jīng)驗成果，針對未來的前瞻技術(shù)進行基礎(chǔ)的培訓。

級培訓分為：

(1)規(guī)章制度培訓。在新員工入職時執(zhí)行，包括公司的規(guī)章制度、安全須知、年假病假等。

(2)技術(shù)技能培訓。針對程序員、測試人員等技術(shù)方面的培訓，包括開發(fā)工具、開發(fā)環(huán)境等。

(3)開發(fā)流程培訓。針對目前已有的開發(fā)模型，進行詳細的流程方面的講解和梳理。

(4)內(nèi)部技術(shù)分享。針對新開發(fā)的功能和特性，相關(guān)開發(fā)人員應當進一步將開發(fā)經(jīng)驗分享出來，提高整體開發(fā)人員技術(shù)能力。

(5)其他類型的培訓。例如項目管理方面的培訓，技術(shù)文檔寫作方面的培訓，針對工作各種可能運用到的技術(shù)，都可以組織培訓提高相關(guān)人員的水平。

4 基礎(chǔ)工程過程域

4.1 需求開發(fā)

在引入CMMI模型之前，K公司需求開發(fā)流程較為松散，也沒有有效的監(jiān)控措施，并不是所有的需求都進行了文檔化，有的時候甚至是口頭傳輸信息，對于某些含糊不清的地方，也沒有盡可能地解釋清楚，所以可能會導致開發(fā)人員的誤解。加之，缺乏完整有效的審核機制，使構(gòu)建的需求可能會無法滿足客戶的真實需求。

K公司擬定建立一套規(guī)范的流程對需求開發(fā)進行管理。需求開發(fā)主要是集中在項目，需求分析人員與客戶或產(chǎn)品經(jīng)理通過引導客戶實際的具體的需求，完成《客戶需求分析研究報告》，之后需求分析人員進一步細化需求，將所得到的具體需求文檔化為《需求分析報告》，并保存起來以便于接下來的審核和整理。接下來《需求分析報告》交由專家進行審核，通過以后再與客戶確認需求并簽字。

K公司需求開發(fā)的流程如圖5所示：

圖5 需求開發(fā)流程

4.2 需求管理

隨著K公司項目的開發(fā)進展，將會陸續(xù)收到各種需求，為了避免需求蔓延，首先必須制定適當?shù)那酪垣@得需求。需求提供者與需求分析人員共同進行需求分析，以確保對需求的正確理解。對于需求的管理需要有一套標準的規(guī)范，K公司擬定撰寫《評估和接受需求的標準》。

在獲得了項目各相關(guān)利益者的承諾后，將項目承諾的需求以及需求變更文檔化。其次在發(fā)生需求變更的情況下，項目經(jīng)理需要分析需求變更的影響，是否需要提供額外的控制手段，任何的需求變化都必須文檔化。

對于需求的可追溯性，必須要提供一個可以追蹤需求的系統(tǒng)，K公司擬定使用OpenALM進行需求的管理和追溯。對于各類需求需提供水平和垂直的關(guān)系表。盡可能將原始需求細化為最小的力度，這種雙向的可追溯性有助于確定所有的原始需求已被完全處理，并且在較低層次的需求也可以追溯到一個有效的原始需求。

K公司的需求管理的流程如圖6所示：

圖6 需求管理流程

4.3 技術(shù)解決方案

通過從需求開發(fā)和需求管理中接收的產(chǎn)品和產(chǎn)品組件的需求，技術(shù)解決方案才得以開啟。

項目啟動后，產(chǎn)品經(jīng)理需創(chuàng)建《產(chǎn)品概要設(shè)計》，產(chǎn)品組的研發(fā)人員針對《產(chǎn)品概要設(shè)計》進行詳細設(shè)計，建立《詳細設(shè)計》和《測試用例分析》等說明書，并且需要經(jīng)過專家的審核，如不通過，需退回去重新修改，通過以后，產(chǎn)品正式進行開發(fā)流程。

專家必須包括已有相關(guān)經(jīng)驗的高級開發(fā)人員、專職的項目審核人員、項目經(jīng)理等。

項目的測試人員根據(jù)《產(chǎn)品概要設(shè)計》進行測試用例的分析，與組內(nèi)開發(fā)人員進行合作，制定出《測試用例分析報告》報告等，測試用例必須要涵蓋所開發(fā)或更新模塊的所有功能。

技術(shù)文檔工程師根據(jù)《詳細設(shè)計》撰寫用戶支持使用說明書，主要包含的內(nèi)容包括產(chǎn)品的安裝，升級，配置文檔，各類接口文檔，以及功能和特性文檔的需求詳述。針對臨時發(fā)生的需求變更，需要重新進行技術(shù)方案的評審工作，并且得重新估算項目時間。

產(chǎn)品經(jīng)理可以根據(jù)功能將產(chǎn)品拆分為數(shù)個組件的形式，以工作包的形式分發(fā)給各個開發(fā)組進行并行開發(fā)，以此提高開發(fā)效率。工作包主要包含了產(chǎn)品架構(gòu)的描述、分配的需求、產(chǎn)品組件的描述、關(guān)鍵的產(chǎn)品特性、接口需求、測試標準（保證需求得以滿足）、使用條件和場景等。

在項目開發(fā)周期內(nèi)，項目經(jīng)理需安排相關(guān)負責人（一般為產(chǎn)品經(jīng)理）對需求進行跟蹤，如遇到需求相關(guān)的問題，需及時登記《項目問題日志》，持續(xù)跟蹤并將問題解決。

K公司的技術(shù)解決方案流程如圖7所示：

圖7 技術(shù)解決方案流程

4.4 確認驗證

驗證包括對產(chǎn)品和中間工作產(chǎn)品的驗證，以對抗所有選定的需求，包括客戶、產(chǎn)品和產(chǎn)品組件需求。驗證本質(zhì)上是一個漸進的過程，因為它發(fā)生在產(chǎn)品和工作產(chǎn)品的開發(fā)過程中，從對需求的驗證開始，通過對不斷變化的工作產(chǎn)品的驗證，并最終對已完成的產(chǎn)品進行驗證。

5 結(jié)語

本文針對K公司的軟件開發(fā)項目，結(jié)合CMMI的管理體系，進行軟件質(zhì)量管理的優(yōu)化。主要是基于CMMI中的兩個基礎(chǔ)過程域：過程管理過程域和工程過程域，進行流程和解決方案上的優(yōu)化。通過聘請專家組對這些過程域的流程進行審核。通過建立標準過程，定義產(chǎn)品生命周期模型，制定項目剪裁標注，以及創(chuàng)建資產(chǎn)庫（即文檔），組織各類培訓，使項目管理過程規(guī)模化和正規(guī)化。對于項目的需求開發(fā)和管理，通過技術(shù)解決方案和確認驗證進行了進一步的流程優(yōu)化以及責任分配，從項目開始至結(jié)尾進行了嚴格的把握，最終可以對于項目的質(zhì)量產(chǎn)品了積極的影響。