軟件項目質量管理經驗談

2019-11-17 04:37:23

字體：大中小

來源：轉載

供稿：網友

原作者:楊志奇由網友:轉載 摘要:本文具體闡述了作者對軟件項目質量治理的熟悉，是作者實際經驗的總結。主要內容包括對軟件項目質量治理理論的熟悉、軟件項目質量治理在實踐中的具體做法。文章具體介紹了有關質量計劃編制、質量控制、質量保證的有關理論；文章也描述了進行質量治理責任分配、質量治理實施的具體方法。

要害詞:質量計劃，質量控制，質量保證，質量治理，過程治理，軟件度量第一章引言

許多IT項目開發的系統應用在生死攸關的場合。例如，1981年，由計算機程序改變而導致的1/67的時間偏差，使航天飛機上的5臺計算機不能同步運行，這個錯誤導致了航天飛機發射失敗。1986年，1臺Therac25機器泄露致命劑量的輻射，致使兩名醫院病人死亡。造成慘劇的原因是一個軟件出現了問題，導致這臺機器忽略了數據校驗。這些慘痛的教訓說明，在軟件開發項目中認真抓好質量治理，并加強有關軟件項目質量治理的研究是擺在我們面前的重要課題。軟件項目質量治理包括：質量計劃編制、質量保證和質量控制三個過程域。質量計劃是質量治理的第一過程域，它主要結合各個公司的質量方針，產品描述以及質量標準和規則通過收益、成本分析和流程設計等工具制定出來實施方略，其內容全面反應用戶的要求，為質量小組成員有效工作提供了指南，為項目小組成員以及項目相關人員了解在項目進行中如何實施質量保證和控制提供依據，為確保項目質量得到保障提供堅實的基礎。質量保證則是貫穿整個項目全生命周期的有計劃和有系統的活動，經常性地針對整個項目質量計劃的執行情況進行評估、檢查與改進等工作，向治理者、顧客或其他方提供信任，確保項目質量與計劃保持一致。質量控制是對階段性的成果進行檢測、驗證，為質量保證提供參考依據，它是一個PDCA循環過程。

第二章對軟件項目質量治理理論的熟悉

軟件項目的質量治理指的是保證項目滿足其目標要求所需要的過程，它包括編制質量計劃、質量控制、質量保證等過程。

2.1 質量計劃編制
　現代質量治理的基本宗旨是：“質量出自計劃，而非出自檢查”。只有做出精準的質量計劃，才能指導項目的實施、做好質量控制。

　　編制項目的質量計劃，首先必須確定項目的范圍、中間產品和最終產品，然后明確關于中間產品和最終產品的有關規定、標準，確定可能影響產品質量的技術要點，并找出能夠確保高效滿足相關規定、標準的過程方法。編制質量計劃通常采用流程圖、因果分析圖等方法對項目進行分析，確定需要監控的要害元素，設置合理的見證點（W點）、停工待檢點（H點），并制定質量標準：
1) 流程圖：
　　顯示系統的各種成分是如何相互關系的，幫助我們猜測在何處可能發生何種質量問題，并由此幫助開發處理他們的辦法。
2) 因果分析圖（也稱魚刺圖）：軟件項目質量治理經驗談（圖一）

對于復雜的項目，編制質量計劃時可以采用因果分析圖，描述相關的各種原因和子原因如何產生潛在問題或影響，將影響質量問題的“人員、設備、參考資料、方法、環境”等各方面的原因進行細致的分解，方便地在質量計劃中制定相應的預防措施。其次，質量計劃中還必須確定有效的質量治理體系，明確質量監理人員對項目質量負責和各級質量治理人員的權限。戴明環（又名PDCA循環法）作為有效的治理工具在質量治理中得到廣泛的應用，它采用計劃——執行——檢查——措施的質量環，質量計劃中必須將質量環上各環節明確落實到各責任單位，才能保證質量計劃的有效實施。

2.2 按照質量計劃實施有效的質量控制　　質量計劃確定后，按照其建立的質量治理體系，各責任單位就必須按照PDCA質量環的要求，實施有效的質量控制。質量控制應貫穿于項目的整個過程，它可分為監測和控制兩個階段：監測的目的就是收集、記錄和匯報有關項目質量的數據信息；控制就是使用質量監測提供的數據，進行控制，確保項目質量與計劃保持一致。

　　在質量監測過程中，對于質量計劃中設置的見證點、停工待檢點，質量監測人員要按照作業程序及時進行測量檢查（其中對于停工待檢點必須由監理人員簽字認可后才能進入下一道工序），以確定項目成果（或階段成果）是否符合相關的質量標準。對于見證點或停工待檢點要防止跳過檢查，因為避免錯誤的成本總是大大低于補救錯誤的成本。對質量監測的結果應采用相應的統計方法進行分析，如帕累托圖法（按發生頻率排序的直方圖，它顯示了可識別原因的種類和所造成的結果的數量）等。通過統計分析對人員、設備、參考資料、方法、環境等影響項目質量的因素進行監控，確定項目實施過程是否在控制之中，同時進行趨勢分析，對一些偏向于不合格的趨勢及早進行控制。質量控制階段應根據驗收數據做出驗收決定，確定是否進入下一步工序。對于質量監測中發現的不合格，應及時利用“因果分析圖”等方法分析原因，并進行適宜的處置，保證不合格得到識別和有效的控制。不合格處置包括返工、返修、降級、讓步放行、報廢等形式。

　　質量監測分析時，對于已發現的不合格或潛在不合格，應制定相應的糾正措施或預防措施，以消除不合格或潛在不合格的原因，防止不合格的發生。糾正措施或預防措施制定后，應對質量計劃進行相應的調整，保證項目的順利實施。

　　項目收尾包括項目評估和項目終止兩個階段。項目收尾階段的質量控制是一個非常重要而又輕易忽視的內容。

　　項目質量評估不僅僅是在項目完成后進行，還包括對項目實施過程中的各個要害點的質量評估。項目質量評估看起來屬于事后控制，但它的目的不是為了改變那些已經發生的事情，而是試圖抓住項目質量合格或不合格的精髓，以使將來的項目質量治理能從中獲益。

　　項目終止階段，是在決策項目終止后，檢查項目文件資料完備，包括項目施工質量驗評表、竣工報告等，同時進行項目總結。項目總結是一個把實際運行情況與項目計劃不斷比較以提煉經驗教訓的過程。通過項目質量計劃和總結，項目過程中的經驗和教訓將得到完整的記錄和升華，成為“組織財富”。

四、項目質量治理的難點

　　每個項目的實施總是擁有同樣的總體目標：質量、時間和成本。三者是一個相互制約、相互影響的統一體，其中任一項目標變化，都會引起另兩個目標變化，并受其制約。如何合理的保證項目質量，正確處理質量與時間、成本之間的矛盾是項目質量治理的一個難點，這需要整合項目所有方面的內容，保證按時、低成本地實現預定的質量目標。

　　根據側重點不同，項目可分為質量傾斜型、工期傾斜型及成本傾斜型體系。我們在編制項目計劃時，一般而言是時間、成本、質量標準均已確定，在項目實施過程中就需在從客觀因素、具體情況出發，根據將要采取的行動和可能導致的后果進行綜合分析研究；按切合實際的原則，使項目進展平衡有節奏地進行，以求達到預期目標。避免出現工期緊張或成本減少，導致質量降低的現象，而質量下降又往往造成返工等后果而導致延長工期和增加成本。 2.3 對軟件質量保證的熟悉
2.3.1 有關SQA的理論

我們都知道一個項目的主要內容是：成本、進度、質量；良好的項目治理就是綜合三方面的因素，平衡三方面的目標，最終依照目標完成任務。項目的這三個方面是相互制約和影響的，有時對這三方面的平衡策略甚至成為一個企業級的要求，決定了企業的行為，我們知道 IBM的軟件是以質量為最重要目標的，而微軟的“足夠好的軟件”策略更是耳熟能詳，這些質量目標其實立足于企業的戰略目標。所以用于進行質量保證的SQA工作也應當立足于企業的戰略目標，從這個角度思考SQA，形成對SQA的理論熟悉。

軟件界已經達成共識的：影響軟件項目進度、成本、質量的因素主要是 “人、過程、技術”。首先要明確的是這三個因素中，人是第一位的。

現在許多實施 CMM的人員沉溺于CMM的理論過于強調“過程”，這是很危險的傾向。這個思想傾向在國外受到了猛烈抨擊，從某種意義上各種靈敏過程方法的提出就是對強調過程的一種反思。 “XP”中的一個思想“人比過程更重要” 是值得我們思考的。我個人的意見在進行過程改進中堅持“以人為本”，強調過程和人的和諧。

根據現代軟件工程對眾多失敗項目的調查，發現治理是項目失敗的主要原因。這個事實的重要性在于說明了 “要保證項目不失敗，我們應當更加關注治理”，注重這個事實沒有說明另外一個問題“良好的治理可以保證項目的成功”。現在很多人基于一種粗糙的邏輯，從一個事實反推到的這個結論，在邏輯上是錯誤的，這種錯誤形成了更加錯誤的做法，這點在SQA的理解上是體現較深。
假如我們考證一下歷史的沿革，應當更加輕易理解 CMM的本質。CMM首先是作為一個“評估標準”出現的，主要評估的是美國國防部供給商保證質量的能力。CMM關注的軟件生產有如下特點：
（1）質量重要
（2）規模較大
這是 CMM產生的原因。它引入了“全面質量治理”的思想，尤其側重了“全面質量治理”中的“過程方法”，并且引入了“統計過程控制”的方法?？梢哉f這兩個思想是CMM背后的基礎。
上面這些內容形成了我們對軟件過程地位、價值的基本理解；在這個基礎上我們可以引申討論 SQA。2.3.2 生產線的隱喻
假如將一個軟件生產類比于一個工廠的生產。那么生產線就是過程，產品按照生產線的規定過程進行生產。 SQA的職責就是保證過程的執行，也就是保證生產線的正常執行。
抽象出治理體系模型的如下，這個模型說明了一個過程體系至少應當包含 “決策、執行、反饋”三個重要方面。軟件項目質量治理經驗談（圖二）

QA的職責就是確保過程的有效執行，監督項目按照過程進行項目活動；它不負責監管產品的質量，不負責向治理層提供項目的情況，不負責代表治理層進行治理，只是代表治理層來保證過程的執行。 2.3.3 SQA和其他工作的組合
在很多企業中，將 SQA的工作和QC、SEPG、組織級的項目治理者的工作混合在一起了，有時甚至更加注重其他方面的工作而沒有做好SQA的本職工作。
國內現在基本有三種QA（按照工作重點不同來分）：一是過程改進型，一是配置治理型，一是測試型。個人認為是因為SQA工作和其他不同工作組合在一起形成的。
下面根據經驗對它們之間的關系進行一個說明。
QA和QC ,兩者基本職責；
QC：檢驗產品的質量，保證產品符合客戶的需求；是產品質量檢查者；
QA：審計過程的質量，保證過程被正確執行；是過程質量審計者；
注重區別檢查和審計的不同，檢查：就是我們常說的找茬，是挑毛病的；
審計：來確認項目按照要求進行的證據；仔細看看CMM中各個KPA中SQA的檢查采用的術語大量用到了“證實”，審計的內容主要是過程的；對照CMM看一下項目經理和高級治理者的審查內容，他們更加關注具體內容。

對照上面的治理體系模型，QC進行質量控制，向治理層反饋質量信息；QA則確保QC按照過程進行質量控制活動，按照過程將檢查結果向治理層匯報。這就是QA和QC工作的關系。
在這樣的分工原則下， QA只要檢查項目按照過程進行了某項活動沒有，產出了某個產品沒有；而QC來檢查產品是否符合質量要求。

假如企業原來具有 QC人員并且QA人員配備不足，可以先確定由QC兼任QA工作。但是只能是暫時的，獨立的QA人員應當具備，因為QC工作也是要遵循過程要求的，也是要被審計過程的，這種混合情況，難以保證QC工作的過程質量。

QA和SEPG，兩者基本職責。SEPG：制定過程，實施過程改進；QA：確保過程被正確執行。SEPG應當提供過程上的指導，幫助項目組制定項目過程，幫助項目組進行策劃；從而幫助項目組有效的工作，有效的執行過程。假如項目和QA對過程的理解發生爭持，SEPG作為最終仲裁者。為了進行有效過程改進，SEPG必須分析項目的數據。QA本也要進行過程規范，那么所有QA中最有經驗、最有能力的QA可以參加SEPG，但是要注重這兩者的區別。

假如企業的 SEPG人員具有較為深厚的開發背景，可以兼任SQA工作，這樣利于過程的不斷改進；但是由于立法、執法集于一身也輕易造成SQA過于強勢，影響項目的獨立性。
治理過程比較成熟的企業，因為企業的文化和治理機制已經健全， SQA職責范圍的工作較少，往往只是針對具體項目制定明確重點的SQA計劃，這樣SQA的審計工作會大大減少，從而可以同時審計較多項目。

另一方面，由于分工的細致化，治理體系的復雜化，往往需要專職的 SEPG人員，這些人員要求了解企業的所有治理過程和運作情況，在這個基礎上才能統籌全局的進行過程改進，這時了解全局的SQA人員就是專職SEPG的主要人選；這些SQA人員將逐漸的轉化為SEPG人員，并且更加了解治理知識，而SQA工作漸漸成為他們的兼職工作。這種情況在許多 CMM5企業比較多見，往往有時看不見SQA人員在項目組出現或者很少出現，這種SEPG和SQA的融合非凡有利于組織的過程改進工作。SEPG確定過程改進內容，SQA計劃重點反映這些改進內容，從保證有效的改進，非凡有利于達到CMM5的要求。從這個角度，國外的SQA人員為什么高薪就不難理解了，也決定了當前中國SQA人員比較被輕視的原因；因為治理過程還不完善，我國的SQA人員還沒有產生這么大的價值。2.3.4 QA和組織級的監督治理

有的企業為了更好的監督治理項目，建立了一個角色，我取名為 “組織級的監督治理者”，他們的職責是對所有項目進行統一的跟蹤、監督、適當的治理，來保證治理層對所有項目的可視性、可治理性。為了有效治理項目， “組織級的監督治理者”必須分析項目的數據。他們的職責對照上圖的模型，就是執行 “反饋”職能。
QA本身不進行反饋工作，最多對過程執行情況的信息進行反饋。SQA職責最好不要和“組織級的項目治理者”的職責混合在一起，否則輕易出現SQA困境：一方面SQA不能準確定位自己的工作，另一方面過程執行者對SQA人員抱有較大戒心。
假如建立了較好的治理過程，那么就會增強項目的可視性，從而保證企業對所有項目的較好治理；而 QA來確保這個治理過程的運行。
2.3.5 SQA的工作內容和工作方法
2.3.5.1 計劃
針對具體項目制定 SQA計劃，確保項目組正確執行過程。制定SQA計劃應當注重如下幾點：
有重點：依據企業目標以及項目情況確定審計的重點。
明確審計內容：明確審計哪些活動，那些產品。
明確審計方式：確定怎樣進行審計。
明確審計結果報告的規則：審計的結果報告給誰。
2.3.5.2 審計/證實
依據 SQA計劃進行SQA審計工作，按照規則發布審計結果報告。注重審計一定要有項目組人員陪同，不能搞忽然襲擊。雙方要開誠布公，坦誠相對。審計的內容：是否按照過程要求執行了相應活動，是否按照過程要求產生了相應產品。
2.3.5.3 問題跟蹤
對審計中發現的問題，要求項目組改進，并跟進直到解決。
2.3.5.4 SQA的素質
過程為中心：應當站在過程的角度來考慮問題，保證了過程， QA就盡到了責任。
服務精神：為項目組服務，幫助項目組確保正確執行過程。
了解過程：深刻了解企業的工程，并具有一定的過程治理理論知識。
了解開發：對開發工作的基本情況了解，能夠理解項目的活動。
溝通技巧：善于溝通，能夠營造良好的氣氛，避免審計活動成為一種找茬活動。 第三章軟件項目質量治理在實際中的具體做法

3.1 質量治理責任分配
筆者曾在美國TAJ Technologies公司任軟件工程師工作。TAJ Technologies公司（位于美國明尼蘇達州，有約200名員工）在開發項目上按照規范化軟件的生產方式進行生產，在生產流程上采用ISO9000的標準進行。每個項目除配備了項目開發所需角色外，還專門配備了配置治理小組、測試小組和質量保證小組確保質量治理的實施，下面針對這三種角色進行說明：
3.1.1 配置治理小組職責
配置治理小組是保證項目開發完畢的同時，內部文檔和外部文檔都同時完成。內部文檔的及時產生和規范，是保證項目開發各小組能夠更好的接口和溝通的重要前提，從另一個方面講，也是保證工程不被某個要害路徑所阻塞而延滯的前提。如上所述，配置治理小組還是保證質量保證小組得以發揮作用的基礎。配置治理小組的主要職責包括：完善各個部門發送需要存檔和進行版本控制的代碼、文檔（包括外來文件）和階段性成果；對代碼、文檔等進行單向出入的控制；對所有存檔的文檔進行版本控制；提供文檔規范，并傳達到開發組中。3.1.2 測試小組職責
測試小組作為質量控制的主要手段，負責軟件的測試設計和執行工作。如同軟件開發一樣，測試在執行之前，同樣需要進行測試計劃和測試策略的設計，通常情況下測試可以分為如下幾種類型，如：正確性測試、功能性測試、性能測試、安全測試和系統測試等。而這些測試均需要在測試計劃和測試策略中進行描述用以指導測試小組成員進行測試用例編寫和測試執行。程序員在交給測試人員之前是進行過一定的單元測試，確保程序編譯、運行正確。測試人員根據具體設計的文檔對軟件要實現的功能進行一一測試，保證軟件的執行正確的實現設計要求，在此也只證實了軟件正確的反映了設計思想，但是否真正反映了用戶的需求仍需要進一步的功能性測試。測試人員只有根據軟件需求規格說明書所提及的功能進行檢測，才能確保項目組開發的軟件產品滿足用戶需求。在正確性測試完成之后，需要測試的是軟件的性能，軟件的性能在本項目中占有重要的地位，性能要求有可能改變軟件的設計，為避免造成軟件的后期返工，測試在性能上需要較大的側重。假如有必要的話，測試小組還需要做安全測試，以確保系統使用安全可靠。3.1.3 質量保證小組職責
質量保證小組作為質量保證的實施小組，主要職責是保證軟件透明開發的主要環節。在項目開發的過程中幾乎所有的部門都與質量保證小組有關。質量保證小組對項目經理提供項目進度與項目真正開發時的差異報告，提出差異原因和改進方法。在項目進度被延滯或質量保證小組認為某階段開發質量有問題時，提請項目經理、項目負責人等必要的相關人員舉行質量會議。解決當前存在的和潛在的問題。質量保證是建立在文檔的復審基礎之上，因而文檔版本的控制，非凡是軟件配置治理，直接影響軟件質量保證的影響力和力度。質量保證小組的檢測范圍包括：系統分析人員是否正確的反映了用戶的需求；軟件執行體是否正確的實現了分析人員的設計思想；測試人員是否進行了較為徹底的和全面的測試；配置治理員是否對文檔的規范化進行的比較徹底，版本控制是否有效。
3.2 質量治理實施
有了良好的資源配備，又如何在項目全生命周期內實施質量保證，讓我們從以下幾個方面來看質量保證的實施過程：

3.2.1 項目進度的質量保證
項目進度是項目進行是否順利的最直觀表現。顯然在項目開始之前，項目開發計劃是必須的。假如項目開發計劃的制定的是完全合理的，那項目進度也就真正表達了項目與最終的交付使用之間的距離，然而要制定完全合理的項目開發計劃幾乎不太可能?？梢娨ＷC項目進度，首先要保證項目開發計劃盡可能合理。項目計劃的合理程度與項目計劃制定者從事類似規模和類似業務的項目的經驗有直接關系，通過經驗往往能夠預見潛在的阻礙，這樣要求項目計劃制定者需要集眾人之力來完善計劃。當項目計劃制定初期，由質量保證小組組織召開的項目計劃評審會，邀請公司技術專家、用戶以及項目組小組成員一起討論項目計劃的可行性，會議通常采用頭腦風暴法，各抒己見，會后由指定的記錄員形成質量記錄，發送給相關人員，對其計劃中不合理的地方進行修改完善，并由質量保證人員對其結果跟蹤，以確保項目計劃完整性、可行性，完善后的計劃交由配置治理人員進行版本控制。然而在計劃實施過程中，計劃不是“固定化”。常有人道，“計劃趕不上變化”，但“要跟上變化”。項目計劃以里程碑為界限，將整個開發周期劃分為若干階段。根據里程碑的完成情況，適當的調整每一個較小的階段的任務量和完成的任務時間，這種方式非常有利于整個項目計劃的動態調整。也利于項目質量保證的實施。實際運作中，當質保小組發現計劃實施的差異后，報告項目經理，由項目經理組織負責對計劃進行周期性維護，對于已經變動的計劃由質保小組協助配置治理小組完成版本控制。

項目開發各階段的質量保證
a、需求分析
需求分析是開發人員對系統需要做什么和如何做的定義過程。從系統分析的經驗來看，這個過程往往是個循序漸進的過程，一次性對系統形成完整的熟悉是困難的。只有不斷地和客戶領域專家進行交流確認，方能逐步明了用戶的需求。從系統開發的過程得知，系統分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發的后期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發影響系統的工期和系統的質量。解決系統分析錯誤的方法。TAJ Technologies公司通常采用邀請用戶參與進行需求評定，然后對其用戶的意見由質保成員跟蹤檢測是否納入需求規格說明書，同時與用戶簽字確認形成需求基線，交由配置治理員放入配置治理庫。雖然盡早的邀請用戶參與，仍然避免不了項目進行中用戶的需求變更請求。對于開發過程存在的需求變動，我們要求用戶填寫變更申請單發送給項目配置治理員，在通過配置配置員轉交質保小組，負責組織專家小組和項目組成員一起討論實施變更的可行性及實施后所帶來的影響，小的變更則直接記錄入變更記錄原因分析項和風險項欄，大的變更則需要形成正式的變更報告，無論那種變更都需要對相應的文檔實施同步變更（包括需求規格說明書、具體設計文、安裝手冊、操作手冊等）。但是對于無法實現或是變更會帶來巨大的影響而將導致進度的延期，這時，我們將變更報告提交給用戶或邀請用戶進行協調會議，討論變更取舍問題或是項目進度變更問題。決定變更之后，由項目經理組織實施變更，測試人員檢測變更結果，而質保小組成員監督變更實施過程并協助配置治理員對變更后的成果物進行版本控制。變更實施完后，上線前還需要指定人員協助用戶一同測試并由用戶簽字后同意方可上線。b、系統設計
優良的體系結構應當具備可擴展性和可配置性，而好的體系結構則需要好的設計方法，自然設計選型成為了系統設計首要的工作，究竟是采用哪種設計方法好呢？對于設計選型不能一概而論，需要針對項目的結構、項目的特征和用戶的需求來分析，同樣也要考慮到參與項目小組成員的素質，假如其中大部分都沒有從事過面向對象的設計且項目進對緊迫，這樣沒有多余的時間來培訓小組成員來把握面向對象的設計方法，盡管眾所周知面向對象設計方法的優勢，我們還是不如采用面向過程的方式（除用戶指定開發設計方式外）可以減少項目承擔的技術風險。TAJ Technologies公司有過一個項目，用戶指定需要采用面向對象分析、設計和開發，且開發周期短，在無賴的情況下，項目小組只能選用面向對象的軟件開發過程，由于項目小組很少從事過面向對象的開發，經驗缺乏，導致項目上馬后項目進度延誤，項目沒有達到預期的效果。針對此次開發，我們分析其原因，發現小組成員在開發過程中對于新技術互相交流少，各自有各自的理解和想法，造成理解上的不一致性，導致工作重復性高，滯后項目進度。建議解決方法是項目組成員采用集中辦公，分塊學習，學習的成果馬上向項目相關人員發布，再由配置治理員對其發布的文檔進行整理、規類放入配置庫以供大家共享。這樣方便大家的互相學習，減少重復的工作。在這次開發中我們公司從治理人員、設計人員到開發人員都汲取了很多教訓，同時經過此次項目的開發，小組成員也積累了豐富的面向對象的開發經驗。除設計選型，還有一個輕易被忽視的問題，就是公共類開發。公共類開發可以減少工作中的重復工作，降低開發成本。這要求我們再設計階段通過對用戶需求的仔細研究，盡可能的識別出公共類，并進行定義指定專人負責設計通知其它設計人員，以減少重復工作。對于項目組提供的設計文檔，由質保小組組織技術專家、項目組設計人員、開發人員和測試人員對其設計文檔的評審，檢測設計文檔對其下一階段工作的可行性，及時發現設計中可能存在的錯誤，降低項目開發風險，同時確保設計文檔能為開發人員、測試人員提供切實的指導。對于可復用的設計進行提取作為公共庫設計和開發，提供項目組或整個公司重用。最后交由配置治理員進行設計文檔的版本控制。 c、實現實現也就是代碼的生產過程。這里不僅包括代碼的產生，同時也包括測試用例的產生。針對上一階段提供具體設計，程序員開始編碼并且調試程序，測試人員則根據設計進行測試用例的設計，設計出來的用例需要得到項目組成員認可由項目經理審核通過才能進入配置庫。同時程序員調試完程序提交測試人員進行程序正確性檢測。 d、文檔治理
文檔維護主要是配置治理小組的工作。文檔從用途上分主要分為內部文檔和外部文檔。內部文檔包括：項目開發計劃；需求分析；體系結構設計說明；具體設計說明；構件索引；構件成分說明；構件接口及調用說明；組件索引；組件接口及調用說明；類索引；類屬性及方法說明；測試報告；測試統計報告；質量監督報告；源代碼；文檔分類版本索引；軟件安裝打包文件。
外部文檔主要包括：軟件安裝手冊；軟件操作手冊；在線幫助；系統性能指標報告；系統操作索引。如何保證文檔的全面性，使其真正為項目的進度提供保證，又不因為文檔的寫作而耽誤項目的進度，這仍然是一個比較難解決的問題。解決此問題，其核心仍然是個"度"的問題。在本項目的開發中，配置治理小組的一個非常重要的任務還是書寫文檔規范和文檔
3.2.2 系統維護質量保證
在TAJ Technologies公司，維護小組的任務一方面是保證對項目客戶的跟蹤服務，另一方面是確保該項目其它的開發人員從項目中盡快的解脫出來以便投入到下一個項目的開發中。所以通常項目維護小組成員主要由項目組的少部分開發人員承擔完成。他們不僅了解軟件的核心內容，而且與客戶也不生疏，以便能夠以最快的速度修正錯誤。對于一般性的錯誤，如操作不當等引起的問題，全部由維護小組執行完成，但需要用戶測試確認上線。假如較大的修改則需要走變更控制流程，用戶或者維護人員填寫變更申請，經專家會議討論分析可行方案在由維護小組實施，通過測試后方可提交用戶。維護小組的人員基本上是按項目跟進的。當一個項目剛剛交付用戶時，在維護小組有較多的人員進行跟進，隨軟件的穩定，跟進的人逐步減少，并轉移到其它項目中去。

第四章參考文獻

《IT執行力----IT項目治理實踐》作者：劉慧，陳虔等編著，電子工業出版社出版
《IT項目治理》作者：（美）凱西.施瓦爾貝著，鄧世忠等譯,機械工業出版社出版作者:楊志奇
作者單位：北京國研網信息有限公司
地址：北京市海淀區金溝河路12號院4號樓4門4號
郵編：100039