小專案實施軟體配置管理探析

目前，由美國軟體工程學會（SEI）開發的軟體能力成熟度模型（CMM，Capability Maturity Model），已經在軟體過程及質量改進方面被廣泛接受，但如何在商業驅動的軟體過程改進中有效地使用這一模型，特別是針對小型組織和小型工程專案，仍存在著許多誤解。本文就這個問題進行嘗試性的探討，並對CMM二級的軟體配置管理關鍵過程域的執行予以描述。

　　一、小組織/小專案與CMM

　　小組織/小專案必須引入標準的軟體能力成熟度模型，否則就不可能成為真正的軟體開發企業。在全面接受CMM理念的同時，最為急需匯入的是軟體配置管理關鍵過程域，要不失時機地上線使用軟體配置管理工具，以便支撐專案實施。專案承製方不僅能在開發過程中受益，最為實際的是通過軟體基線的界定，能形成階段性產品。這些產品是專案開發團隊理應關注的物件，也是市場部經理與客戶方博弈的砝碼。小組織/小專案在執行軟體配置管理關鍵過程域中，應該完全按照規範操作，不能做任何裁剪，在組織結構與角色劃分上儘量實現4個目標、25個關鍵實踐及其描述的各種活動。

　　1.小專案／小組織

　　CMM能否被用於小專案/小組織的問題中，關於“小”的定義一直是模糊難解的。

　　其中，小專案到微小專案是在小組軟體過程（TSP，Team Software Process）的範圍中，而個人的開發努力則在個體軟體過程（PSP，Personal Software Process）的範圍中。TSP和PSP闡明瞭CMM的概念是如何應用到小專案中的。

　　2.PSP和TSP

　　個體軟體過程是一種可用於控制、管理和改進個人工作方式的自我改善過程，是一個包括軟體開發表格、指南和規程的結構化框架。PSP為基於個體和小型群組軟體過程的優化提供了具體而有效的途徑，譬如，如何制定計劃，如何控制質量，如何與其他人相互協作等等。在軟體設計階段，PSP的著眼點在於軟體缺陷的預防，其具體辦法是強化設計結束的準則，而不是設計方法的選擇。

　　個體軟體過程與具體的技術（程式設計語言、工具或者設計方法）相對獨立，其原則能夠應用到幾乎任何軟體工程任務之中。個體軟體過程應達到：

　　①說明個體軟體過程的原則；

　　②幫助軟體工程師做出準確的計劃；

　　③確定軟體工程師為改善產品質量要採取的步驟；

　　④建立度量個體軟體過程改善的基準；

　　⑤確定過程的改變對軟體工程師能力的影響。

　　小組軟體過程致力於開發高質量的產品，建立、管理和授權專案小組，並指導他們在滿足計劃費用的前提下，在承諾的期限範圍內，不斷生產並交付高質量的產品。

　　小組軟體過程實施集體管理與自己管理相結合的原則，最終目的在於指導開發人員如何在最少的時間內，以預定的費用生產出高質量的軟體產品，所採用的方法是對群組開發過程的定義、度量和改進。

　　實現小組軟體過程的方法需要具備四個條件：

　　①需要高層主管和各級經理的支援，以取得必要的資源；

　　②整個軟體開發小組至少應在CMM的第二級（可重複層）；

　　③全體軟體開發人員必須經過個體軟體過程培訓，並有按小組軟體過程工作的願望和熱情；

　　④開發小組成員應在2到20個人之間。

　　在實施小組軟體過程中，如果發現未能按期按質完成，應立即分析原因，以判定問題是由於工作內容不合適或工作計劃不實際引起，還是由於資源不足或主觀努力不夠所引起的。開發小組應隨時追蹤專案進展狀況並定期彙報，還應經常審視自己是否按軟體開發過程的原理工作。如發現過程不合適，應及時改進。

　　3.CMM、PSP和TSP組成的軟體過程框架

　　CMM、PSP和TSP組成的軟體過程框架。

　　CMM是過程改善的第一步，它提供評價組織的能力、識別優先改善需求和追蹤改善進展的管理方式。PSP能夠指導軟體工程師如何保證自己的工作質量，估計和規劃自身的工作，度量和追蹤個人的表現，管理自身的軟體過程和產品質量。TSP結合了CMM的管理方法和PSP的工程技能，通過告訴軟體工程師如何將個體過程結合進小組軟體過程，並將後者與整個管理系統相聯絡；通過告訴管理層如何支援和授權專案小組，堅持高質量的工作，並且依據資料進行專案管理，向組織展示如何應用CMM原則和PSP去生產高質量的產品。

　　4.PSP和TSP對CMM的支援

　　二、軟體配置管理

　　軟體配置管理（SCM，Soft Configure Management）的目的是在整個專案的軟體生存週期內，建立和維護軟體專案產品的完整性。

　　軟體配置管理包括在給定時間點上及時地標識軟體的配置，系統地控制對配置的更改，並在整個軟體生存週期中維護配置的完整性和可跟蹤性。置於軟體配置管理之下的工作產品包括交付給客戶的軟體產品（如軟體需求文件和程式碼），以及與這些軟體產品一同標識的或為產生這些軟體產品所要求的產品項（如編譯程式）。

　　通過軟體配置管理的更改控制和配置稽核職能，專案能系統地控制對基線的更改和由軟體基線庫構造的軟體產品的釋出。

　　關鍵過程域包括實施軟體配置管理職能的有關實踐。標識特定配置項/單元的實踐則包含在描述各配置項/單元開發和維護的關鍵過程域中。

　　1.SCM的關鍵活動

　　CMM中的軟體配置管理包括了多項相關活動，包括版本控制、建立軟體配置庫系統、配置項變化的控制、軟體基線記錄報告等等。如果將SCM作為一個配置管理模型，應當強調以下幾點：

　　（1）任務清晰，責任明確

　　為了確保軟體開發過程中開發人員之間各種資訊交流的順暢和準確，首要問題是確立一個實施架構。通常是以“組”的概念細分一項工程中各類任務的執行單位，明確各組在開發和管理過程中各自的職責、需要完成的工作，管理層面可由此清晰地瞭解產品的完成情況。總體設計者利用任務的展開方式進行任務分配，用網路圖的方式控制各組之間的關係，包括時間進度計劃和各組之間的介面等等。

　　軟體開發過程中的任務管理是配置管理的基礎，如果任務定義不明確，配置管理的實施也將難以保證。通過對任務的詳細定義，把每一個子任務具體分配給某一個人去完成，這樣就將對集體管理的任務細化到對個人的管理層面上了。

（2）建立軟體配置管理庫系統

　　建立軟體配置管理庫系統的主要目的是用來存放軟體基線。它可以對軟體配置管理進行多級控制，譬如在產品開發週期中，不同階段有著不同力度的配置管理，隨著產品不斷成熟，控制力度也隨之增強；提供對庫中配置項的儲存和修改的功能，支援在相關組之間和庫中不同控制級間共享和傳輸配置項；支援生成軟體配置管理的報告文件及軟體基線內容的報告文件；有助於確保從軟體基線庫中釋出的相關文件和軟體產品的正確性。

　　（3）版本管理

　　版本控制是軟體配置管理的基本要求，它可以保證在任何時刻恢復任何一箇中間產品的任意版本。版本管理記錄了所有庫中程式碼和文件的開發歷程，可以保證產品的可追溯性，為除錯程式碼、清除缺陷提供很大的幫助。同時，版本管理支援並行開發和維護，為協同開發打下了基礎。

　　（4）變化控制

　　在有配置管理概念的軟體產品開發過程中，所有的改變都是在有效控制下的，包括軟體基線的改變、配置項的改變。改變管理的一個基本項就是改變請求（CR，Change Request），在一個軟體系統中描述邏輯上改變的實體。改變請求是由開發計劃變化和錯誤報告生成的。在開發過程中，CR主要收集有關係統改變的資訊。開發人員將一個新建或修改過的檔案寫入庫中時，要指出相關的CR，檔名稱和版本需在CR中登記。CR的最終版本包括邏輯改變的描述和所有修改的檔案版本資訊。由SCM組和SCCM（軟體配置控制委員會）稽核要寫入配置管理庫中的新的軟體基線。

　　2.軟體配置管理工具

　　軟體配置管理工具（SCMT，Soft Configure Management Tool）正是從這一角度出發，對軟體配置管理過程進行具體實施，將抽象的軟體配置管理工作轉化為可借鑑的、可操作的具體執行規範。SCMT作為軟體配置管理的輔助手段，必須要制定一個實際、可行的軟體配置管理流程，依據該流程，加之SCMT的輔助，軟體配置管理工作才能真正做到科學、有序。

　　3.軟體配置管理流程

　　SCMT將軟體配置管理工作分解為專案建立、配置策劃？專案策劃、計算機軟體配置項（CSCI）策劃？、CSCI入庫（初始入庫、更動入庫）、軟體問題報告、軟體更動報告、更動出庫、瀏覽出庫、專案歸檔、專案匯入、產品定義、產品出庫、配置審計、配置追蹤、狀態報告等。

　　首先由系統管理員建立專案，將專案基本資訊入庫和建立軟體配置控制委員會（SCCB）使用者、專案管理員；其次由專案管理員對已建立的專案進行專案策劃，劃分CSCI，一個專案可以包含一個或多個CSCI，包括將CSCI 基本資訊入庫和建立CSCI管理員、配置管理組成員，專案策劃需要由軟體配置控制委員會審批。

　　其次，由CSCI管理員進行CSCI策劃，包括劃分基線、為每條基線標識軟體配置管理項（CMI）、確定CMI之間的依賴關係、建立一般使用者，CSCI策劃由配置管理組審批；配置策劃完成後，即可進行初始入庫（指CMI的初次入庫，由許可權使用者操作，由配置管理組審批）。有了已入庫的CMI後就可以進行後續操作。

　　SCMT中規定如下配置更動規程：配置更動針對的是受控庫中登入的軟體問題，配置更動實施前必須填寫軟體更動報告，經更動評審組評審通過，且確認評審結論為“按計劃實施”時，才能從受控庫中提出需更動的 CMI並實施更動。更動實施完成後，必須通過評審才能重新進入受控庫。

　　更動過程在 SCMT 內分解為提交軟體問題報告，提交軟體更動報告，更動出庫和更動入庫。軟體問題報告由發現問題的人員填寫，不需要審批；軟體更動報告由CSCI管理員填寫，交更動評審組稽核。在專案建立時或在接到軟體更動報告後，建立更動評審組。根據所開發軟體的關鍵級別和規模大小決定更動評審組規模的大小，構成人員應包括軟體專案的管理人員、技術負責人員、總體設計人員、軟體質量保證人員和軟體配置管理人員，組成人數可視實際情況酌定。更動評審組收到軟體更動報告後，分析此更動的必要性和技術可行性，並權衡其他的更動策略和方法，所涉及的有關CMI，對系統的功能和效能的影響，更動所需的資源是否合理、充分以及對整個工程進展和經費的影響等。由此決策是否實施此項更動，並給出更動評審結論，同時由 SCCB簽署該軟體更動報告。

　　SCMT審查簽署後的軟體更動報告中的更動結論，清除問題時，形成“問題報告”－“更動報告”鏈併發布問題解決通告；暫緩執行時，不需做任何處理；按計劃實施時，允許CMI更動出庫。更動出庫由許可權使用者依據簽署的軟體更動報告進行；更動入庫由許可權使用者操作，由CMG審批。

　　瀏覽出庫指出於測試或閱讀的需要對CMI進行出庫，瀏覽出庫不需要審批。

　　產品定義、產品出庫、專案歸檔和專案匯入由專案管理員操作，由SCCB審批。要求出庫的產品必須曾經定義過，要求匯入的專案必須為歸檔專案。

　　配置審計、配置追蹤、狀態報告由SCCB、CMG、CSCI管理員操作。

　　SCMT提供配置審計嚮導，引導使用者完成配置審計處理過程。

　　在匯入SCMT時應該本著軟體配置管理關鍵域的核心思想，從現有市場中選擇適合自己的配置工具。需要強調的是，無論什麼樣的工具都無法完全實現軟體配置管理的目標與關鍵實踐，在此也不排除自我開發的SCMT.問題的關鍵在於對人的培訓，在使用工具的同時深化CMM管理理念，使整個軟體專案團隊在開發過程中確保質量達標。因此，手工操作仍然是今後一段時間內軟體配置管理實施中必不可少的基礎手段。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780914/viewspace-412115/，如需轉載，請註明出處，否則將追究法律責任。