某互聯網項目軟件過程改進實踐
目錄
1. 項目概述
本公司主要運營互聯網產品。每次均以項目的方式開發、升級產品。項目週期短。
項目名稱：某互聯網娛樂平臺
軟件開發方法：採用RUP進行迭代開發。本系統是B/S結構。並採用了MVC模式進行WEB開發。
軟件開發技術及工具：
技術：Struts+Spring+Hibernate
工具：Eclipse3.2
數據庫：ORACLE 10G
2. 項目組織結構
組織結構：弱矩陣
項目成員的角色：
|
角色 |
人數（名） |
部門 |
|
項目經理 |
１ |
技術部 |
|
技術經理 |
１ |
技術部研發組 |
|
測試經理 |
1 |
技術部測試組 |
|
系統架構師 |
1 |
技術部研發組 |
|
高級軟件工程師 |
２ |
技術部研發組 |
|
軟件工程師 |
２ |
技術部研發組 |
|
測試工程師 |
２ |
技術部測試組 |
|
項目助理 |
１ |
技術部 |
|
美工 |
4 |
技術部UI組 |
|
需求工程師 |
2 |
產品部需求組 |
表1 項目角色表
3. 軟件過程現狀分析[1]
3.1. 項目過程描述
軟件開發流程：項目分6個迭代，每４周1個迭代。
1） 第1個迭代是項目初始階段。開項目啓動會議，確定項目章程、劃定項目範圍。進行項目的WBS計劃、風險列表、項目管理計劃、項目的里程碑並根據需求進行項目的系統設計工作。獲得客戶需求，畫出用例圖等。並選擇2個風險較大的核心用例進行開發測試。
2） 第2個迭代進行項目的細化階段。在完善第次1迭代製品的基礎上。完成大部分用例的設計。並選擇3個風險大用例進行開發、測試。
3） 第3~5個迭代進行項目構造階段，根據剩餘用例和系統設計對系統進行研發、測試。併發布BATE版到公網進行公測。
4） 第6個迭代進行項目的收尾移交階段。編寫項目的系統使用手冊和培訓文檔等製品。
爲確保項目交付物在提交時間內按質按量完成。在開發的過程中使用了SVN作爲版本控制服務器。確保產品的版本一致性、減小風險。並作爲績效考覈的依據之一。
每週一上午9:00開項目例會，對開發的實際情況進行跟蹤並對項目管理計劃進行監控、調整和工作的溝通協調。按計劃交付里程碑規定的相應制品。單元測試始終伴隨着開發進行。每個迭代代碼研發階段完成後。提交給測試組按照測試計劃和測試用例進行集成測試。在測試結束後進行測試評估。並根據測試報告進行評審再將BUG反饋給研發組進行修改。在修改後測試組進行迴歸測試，確保項目的質量。在項目開發完成後，將產品移交給運營部進行維護。
公司發現在產品的第一版項目研發的過程中沒有建立整套的軟件工程體系。在軟件工程的實踐中基本上是以部門爲單位進行管理和控制的，在統計的過程中，依據軟件過程的主要過程以及所屬部門進行分類和彙總。
在調查過程中，發現問題分屬於10個不同的過程（域），他們分別是：軟件需求、項目計劃、項目跟蹤與監控、軟件配置管理、軟件質量保證、培訓大綱、軟件控制管理(軟件測試)、軟件評審、溝通管理、風險管理。
從問題的分佈結構，可以發現公司基本的軟件過程還沒有得到完善的建立，主要的問題集中在軟件工程活動較基礎的幾個環節：
3.2. 軟件需求管理
該過程主要考察軟件項目的需求管理，包括產品需求的獲取、系統需求的獲取、軟件需求的確定、軟件需求的控制和變更等。
主要的問題：
1. 沒有建立較全的需求管理過程。
2. 需求的變更沒有進行管理、評估和跟蹤測量。
3. 項目的研發組和其他軟件相關組（如產品組（產生產品需求）、測試組）的成員缺乏實施需求管理活動的培訓。
因需求導致影響較大的技術部的研發組、測試組和產品組。
結論：
需求不夠完整，沒有組織級的統一管理，在對需求的理解層次上還有所欠缺。
3.3. 項目管理計劃
軟件項目管理計劃的目的是完成軟件工程和管理軟件項目制定合理的計劃。依據項目初步範圍說明書、項目管理各個過程、事業環境因素、組織過程資產通過項目管理方法系以及專家判斷和項目管理信息系統將確定、協調與綜合所有部分計劃所需要的行動形成文件，使其成爲項目管理計劃。它確定了執行、監控、和結束項目的方式和方法。
軟件項目管理計劃包括：
項目範圍管理計劃、進度管理計劃、費用管理計劃、質量管理計劃、過程改進計劃、人員配備管理計劃、溝通管理計劃、風險管理計劃、採購管理計劃、里程碑清單、資源日曆、進度基準、費用基準、質量基準、風險登記手冊等。
主要問題：
1. 沒有根據規範制定項目計劃，項目中僅對項目進度管理計劃、資源日曆進行了詳細的制定。其它均比較模糊。
2. 軟件質量保證組沒有進行評審和（或）審覈軟件項目計劃和產品。
3. 歷史數據的收集、比較、管理做的比較差。
項目管理計劃沒有統一的規範，各部門依據自己的規範制定各部門的工作計劃，計劃沒有經過質量保證組及相關人員的評審。軟件項目管理計劃中的項目範圍管理計劃、費用管理計劃、質量管理計劃、過程改進計劃、溝通管理計劃、風險管理計劃、採購管理計劃、費用基準、質量基準、風險登記手冊等比較粗糙。其制定主要根據計劃編制人的經驗。
結論：
項目缺乏有效的控制，項目經理對項目的控制依靠個人的能力。
3.4. 項目跟蹤與監控軟件項目的跟蹤與監控的目的是建立對實施進展的適當的可視性，使管理者能在軟件項目性能明顯偏離軟件計劃時採取有效措施。
主要問題：
因爲項目中沒有對軟件產品的範圍、成本以及風險進行量化，而工作量的安排沒有細緻到合理的粒度，所以項目進度的跟蹤沒有足夠的量化的依據。
沒有組織級的跟蹤和控制項目機制，當前週報的機制不能對項目起到合適的監控作用。
沒有統計和彙報項目實際情況並與項目計劃的偏差比較。
項目的跟蹤與監控，很大程度取決於項目計劃編寫的科學性，公司目前項目進度沒有書面的跟蹤與監控機制，當前實施的有員工周志制度，該制度效果較差，另外部分項目組或部門有周例會制度。
結論：
項目級的跟蹤機制只能依靠各層管理人員的人爲管理、干預。
3.5. 軟件配置管理
軟件配置管理的目的是建立和維護在項目的整個軟件生命週期中軟件項目產品的完整性。軟件配置管理包括標識在給定時間點上的軟件配置（即選定的軟件工作產品及其描述），系統地控制對配置的更改，並維護整個生命週期內配置的完整性和可可跟蹤性。
主要問題：
1. 配置項的識別和描述（以代碼爲主）不規範，沒有建立基線。
2. 配置管理的過程不規範，軟件配置管理的控制和更改不完善。
項目有建立軟件配置管理庫（SVN），有相應的簡單過程（沒有完全實施），配置管理的程度靠配置管理人員的能力，配置管理的人力方面存在安全風險。
結論：
配置管理的範圍只在初級的代碼和技術文檔的配置控制，配置庫有安全的風險。
3.6. 軟件質量保證
軟件質量保證（QA）的目的是向管理者提供適當的對軟件項目正使用的過程和正構造產品的可視性。軟件質量保證包括評審和審計軟件產品和活動以驗證它們符合適用的規程和標準，給項目和其它相關的經理這些評審和審計的結果。
主要問題：
1. 沒有機構管理策略來實施軟件質量保證。
2. 軟件工程活動沒有進行一致的驗證，對軟件質量保證的認識程度僅限於軟件測試階段。
3. 沒有歸檔、處理和跟蹤軟件活動和軟件工作產品中的偏差。
有一部分的軟件質量保證的工作在項目組中進行，另有一部分在企業戰略策劃組，因爲沒有相關的規程，以及受到自身角色的限制，所以質量保證活動基本上屬於失控狀態。
結論：
組織中缺少質量保證的人員和資源，質量保證活動系統的展開和管理，高層管理人員的監控和支持不夠。
3.7. 培訓大綱
培訓大綱的目標是提高個人的知識和技能，使其有效地履行職責。
主要問題：
1. 公司沒有負責實施培訓的小組，沒有書面的培訓管理策略。
2. 沒有對培訓需求的識別和管理，缺乏對培訓活動的控制和實施。
3. 公司因爲缺乏對項目的瞭解，特別是技術方面的瞭解，導致在軟件需求方面不穩定。另外員工普遍缺乏對項目管理和軟件工程方面的培訓。
結論：
公司沒有系統的培訓規劃，缺少足夠的資源，高層管理人員重視不夠，員工缺乏產品開發技術以及項目管理、軟件工程等方面的培訓。
3.8. 軟件控制管理(軟件測試)
軟件控制管理（軟件測試）的目的是爲了始終如一的執行嚴格定義的項目過程。軟件工程任務包括分配到軟件上的系統需求、軟件需求開發、軟件架構開發、軟件設計、軟件代碼實現、軟件元素集成以及軟件測試以驗證其是否滿足具體要求（即分配到軟件上的系統需求和軟件需求）。
主要問題：
1. 軟件測試過程沒有覆蓋到足夠的層次。
2. 各個階段測試準備都就緒準備沒有建立。
3. 各個層的軟件測試活動的規程沒有。測試計劃、測試用例不完善，或者沒有進行評審。
4. 公司的單元測試、集成測試、部分迴歸測試是項目組進行的，相應的測試規程不完善。對於項目組內的測試能力依靠測試者的個人能力，單元測試沒有很好的進行管理和控制。測試負責進行產品的驗收測試或者系統測試，測試組與其它部門接口不夠明確。
結論：
公司有軟件產品測試管理體系，但軟件產品測試範圍不能覆蓋到足夠的層次。
3.9. 軟件評審
軟件評審的目的是儘早有效地排除軟件工作產品中存在的問題。軟件評審包括對軟件工作產品進行系統檢查，以發現問題和需要修改的範圍。要進行軟件評審的具體產品在項目的被定義軟件過程中被標識，並且作爲軟件項目策劃活動的組成部分被列入進度。
主要問題：
1. 沒有對需要進行評審的工作產品的識別、以及實施評審的規程。
2. 公司沒有嚴格定義上的評審，但一些關於代碼審查（走查），以及一些技術文檔的評審是以評審的形式進行的。評審的工作產品與規程沒有組織級的定義，在各個部門或項目的規程中有部分定義，但是實施沒有受控。
結論：
評審已經在項目中應用，但沒有組織級統一的過程定義和監督。
3.10. 溝通協調管理
溝通管理包括軟件工程組對其它工作組工作的參與，以適應系統級的需求、目標和問題。需求組、技術組和測試組參與建立系統級的需求、目標和計劃。這些需求、目標和計劃成爲所有工程活動的基礎。組間的技術工作接口和相互配合形成計劃並被管理，以確保整個系統的質量和完整性。
主要問題：
1. 制定需求時，相關組的協調不完善。
2. 沒有確定、協調和跟蹤項目組之間的關鍵依賴關係的書面規程。
3. 沒有以書面計劃方式約定小組的工作。
在調查中，因溝通協調而出現的工作問題比較直接，而且比較嚴重，溝通協調容易出現問題的一般是跨部門。一般影響工作產品的質量的程度都比較嚴重，如項目超期，需求更改等等。
結論：
溝通協調工作不夠，各小組間以及部門間的接口不夠明晰，沒有公司級的統一溝通管理機制。
3.11. 風險管理
風險是一種不能確定的事件或情況，一旦發生，會對至少一個項目目標如：時間、費用、範圍或質量產生積極或消極的影響。風險管理就是對項目進行規劃、識別、分析、應對和監控的過程。它的目標是增加積極事件的概率和影響，降低項目消極事件的概率和影響。
主要問題：
1、 風險管理規劃、風險登記表、風險分析、風險應對規劃以及對風險的監測與控制重視程度不夠、過程不規範。
2、 風險的應對大部分根據個人的能力。遇到突發風險，沒有預選的風險應急計劃。
總結
系統在實施的過程中有很多不可預知的風險。爲此項目團隊借鑑了一些以往風險列表中的風險，並將其放在風險計劃上來預防風險的發生並解決已發生的風險。在項目結項時，將所發生的風險總結到風險列表中，以便以後的項目借鑑。
3.12. 分析總結
優點：
較好的過程存在與軟件設計實現和測試過程。
技術能力是強項，包括設計和編碼方面做的比較好。同時也反映出了公司在推行軟件工程的過程中還有許多不足之處。可以保證需求被管理。過程得到計劃、執行、衡量和控制。有助於保證現有的過程即使在處於壓力下也能夠執行。在執行過程中，項目按預定的計劃進行管理。
缺點：
其主要問題體現在需求的制定（獲取）、理解和變更控制。
溝通協調和測試過程中發生的問題，很多都源於軟件需求不明確和更改沒有受控，而需求過程的主要問題，並不只是因爲過程以及過程定義的問題，更多的問題是偏於技術能力方面的，所以在技術培訓方面的過程中有所欠缺。
4. 軟件過程改進計劃[2]
過程改進的要素是：
文檔化、培訓、實踐、強制、可提高、可裁剪。
4.
過程改進的總體計劃通常包括：介紹、制定計劃時所使用的方法、對評審結果和推薦措施的總結，主要內容是各個改進項目的方案和策劃活動的結果。
4.1. 在初始階段
在初始階段，必須識別所有與系統交互的外部實體，定義系統與外部實體交互的特性。在這個階段中所關注的是整個項目的業務和需求方面的主要風險。對於建立在原有系統基礎上的開發項目來說，初始階段可能很短。
（1） 明確項目規模
建立項目的軟件規模和邊界條件，包括驗收標準；瞭解環境及重要的需求和約束，識別系統的關鍵用例(Use Case)。
（2）評估項目風險
軟件過程主要關心的是軟件開發的已知方面，只能準確描述、計劃、分配和評審那些已經知道將要完成的事情。風險管理則主要關心未知方面。在基於RUP的迭代式軟件過程中，很多決策要受風險決定。要達到這個目的，開發者需要詳細瞭解項目所面臨的風險，並對如何降低或處理風險有明確的策略。
（3）制訂項目計劃
估計整個項目的總體成本、進度和人員配備。綜合考慮備選體系結構，評估設計和自制、外購、重用方面的方案，從而估算出成本、進度和資源。在這個過程中，要通過對一些概念的證實來證明可行性，該證明可採用可模擬需求的模型形式或用於探索高風險區的初始原型。初始階段的原型設計工作應該限制在確信解決方案可行就可以了，具體實現留到細化階段和構建階段。
（4）階段技術評審
初始階段結束時要進行一次技術評審，檢查初始階段的目標是否完成，並決定繼續進行項目還是取消項目。在評審過程中，需要考慮項目的規模定義、成本和進度估算是否適中，估算根據是否可靠，是否已經確定所有風險，並且有針對每個風險的規避策略等問題。
4.2. 細化階段
細化階段的任務是分析問題領域，建立健全的體系結構基礎，淘汰項目中最高風險的元素。在細化階段，必須在理解整個系統的基礎上，對體系結構做出決策，包括其範圍、主要功能和諸如性能等非功能需求，同時爲項目建立支持環境。
（1） 確定體系結構
確保體系結構、需求和計劃足夠穩定，充分減少風險，從而能夠有預見性地確定開發所需的成本和開發進度。通過處理體系結構方面重要的場景(Scene)，建立一個已確定基線的體系結構。證明已建立基線的體系結構將在適當時間、以合理的成本支持系統需求。
（2） 制訂構建階段計劃
爲構建階段制訂詳細的過程計劃併爲其建立基線。
（3） 建立支持環境
建立支持環境，包括開發環境、開發流程、支持構建團隊所需的工具和自動化/半自動化支持。
（4） 選擇構件
評估現有的(構件庫)和潛在構件，充分了解自制、外購、重用決策，以便有把握地確定構建階段的成本和進度。集成所選構件，並按主要場景進行評估。
（5） 階段技術評審
評審時，需要檢驗詳細的系統目標和範圍、體系結構的選擇以及主要風險的解決方案。在技術評審中，需要考慮的問題有：
（1）產品需求是否穩定，體系結構是否是穩定的。
（2）可執行原型是否表明已經找到了主要的風險元素，並且得到妥善解決。
（3）構建階段的迭代計劃是否足夠詳細和真實，是否有可靠的估算支持，可以保證工作繼續進行。
（4）所有與項目有關的人員是否一致認爲，如果在當前體系結構環境中執行當前計劃來開發完整的系統，則當前的需求可以實現。
（5）實際的資源耗費與計劃的耗費相比是否有偏差，該偏差是否可以接受。
在構建階段，要開發所有剩餘的構件和應用程序功能，把這些構件集成爲產品，並進行詳細測試。從某種意義上說，構建階段是一個製造過程，其重點放在管理資源及控制操作，以優化成本、進度和質量。
4.3. 構建階段
構建階段的主要任務是通過優化資源和避免不必要的報廢和返工，使開發成本降到最低；完成所有所需功能的分析、開發和測試，快速完成可用的版本；確定軟件、場地和用戶是否已經爲部署軟件作好準備。
在構件階段，開發團隊的工作可以實現某種程度的並行。即使是較小的項目，也通常包括可以相互獨立開發的構件，從而使各團隊之間實現並行開發。這種並行性在較大幅度地加速開發進度的同時，也增加了資源管理和工作流程同步的複雜程度。
構建階段結束時也要進行技術評審，評審產品是否可以在β測試環境中進行安裝和運行。在評審中，需要考慮的問題有:
（1）該產品發佈版是否足夠穩定和成熟，可安裝和運行在實際環境中。
（2）所有與項目有關的人員是否已準備好將產品發佈。
（3）實際的資源耗費與計劃的耗費相比是否有偏差，該偏差是否可以接受。
當基線已經足夠完善，可以安裝到最終用戶實際環境中時，則進入交付階段。交付階段的重點是確保軟件對最終用戶是可用的。
4.4. 交付階段
交付階段的主要任務是進行β測試，製作產品發佈版本；對最終用戶支持文檔定稿；按用戶的需求確認新系統；培訓用戶和維護人員；獲得用戶對當前版本的反饋，基於反饋調整產品，如進行調試、性能或可用性的增強等。
交付階段結束時也要進行技術評審，評審目標是否實現，是否應該開始進化過程，用戶對交付的產品是否滿意等。
4.5. 評審
在每個階段結束時都要進行一次技術評審，以確定在完成該階段的最終迭代後是否應該讓項目進入下一階段。技術評審要考慮的主要問題應該主要與項目管理有關，因爲主要的技術問題應該已經在該階段的最終迭代以及隨後的活動中得到解決。
（1） 安排評審會議日程
技術評審會議的參加者必須包括項目的管理團隊（項目經理以及項目團隊各功能區域的團隊負責人）和項目評審委員會。與會者一旦確定，就應安排會議的召開日期和時間，以便爲與會者留出充足的準備時間，讓他們能夠評審有關材料。
（2） 分發會議材料
在會議召開之前，應當將技術評審材料分發給評審人員。要在會議召開之前及早地將這些材料分發出去，讓評審人員有充足的時間對其進行審閱。
（3） 召開評審會議
在會議期間，評審人員主要關注狀態評估。在會議結束時，評審人員應作出是否批准的決定。技術評審會議可能會得到以下結果之一：
（Ⅰ）階段被接受：評審委員會認爲項目實現了該階段的預期目標，可以進入下一階段。
（Ⅱ）有條件接受：評審委員會同意項目可以進入下一階段，但必須先完成指定的糾正操作。如果發現的問題很少並且不是很重要，則客戶可能決定在項目團隊執行某些糾正操作的同時有條件地接受該產品。在這種情況下，項目經理需要根據問題的重要性，或選擇開始新的迭代，以處理所出現的問題，或只是通過延長最終迭代來處理問題，二者的差異在於所需的計劃工作量。
（Ⅲ）階段不被接受：項目沒有實現該階段的預期目標，項目經理就可能必須開始另一次迭代，甚至項目經理無法決定對問題的解決方案，而需要由有關人員根據合同重新確定項目規模或終止項目。
（4） 記錄會議決定
在會議結束時應完成評審記錄，其中包括重要的討論或活動以及評審的結果。如果結果是"階段不被接受"，則應暫時安排一次後續複審。
5. 實施過程改進
在項目的第二版版本時，公司加強了軟件過程的管理並依據過程改進計劃實施過程改進：
在項目的初始階段，主要建立項目的軟件規模和邊界條件，明確用戶的需求，形成規格說明書，作爲驗收標準。同時，估計了整個項目的總體成本和進度，評估了潛在的風險，作出了具有20%資源預留的項目計劃。選擇了Rational Rose 2003作爲分析和建模工具、Project 2003作爲項目管理工具。系統開發工具採用Eclipse3.2，後臺數據庫管理系統採用Oracle 10G。
在項目的細化階段，我們根據實際需求，選擇了B/S軟件體系結構。攻關一些關鍵性的算法，製作了頁面的原型。並在此基礎上，爲構建階段制訂了詳細的迭代計劃。在構件的選擇方面，決定主要採用已有構件，對構件庫中沒有的構件，則重新開發。
在項目的構建階段，主要任務是完成新構件的開發和測試，集成所有構件，進行集成測試。
在項目的交付階段，把經過集成測試的軟件發佈到公網服務器上，接受實際環境的公測。然後對客服、維護人員以及有關用戶進行培訓和指導。在公測結束後，系統正式上線。
在以上各階段結束時，都進行了階段技術評審。
由於全面採用了基於RUP的軟件過程，規範了管理和開發流程，有效地控制了資源，該項目使用部分預留資源。在系統運行期間，根據市場的導向和公司的商業戰略，運營部對該軟件進行優化，最終由軟件項目過渡到一個產品。現在，該軟件產品已經在互聯網上使用，用戶反映良好。
6. 評估過程改進[3]
6.1. 對商業目標的影響對商業目標的影響是指某項改進工作對總體的戰略目標的影響。首先，策劃小組要和主管的高層經理進行討論，明確公司商業目標、並分析確定決定商業目標能否實現的5-7個關鍵成功因素（CSFs）。明確成文的商業目標，並且形成了文檔，策劃小組的核心工作就是分析關鍵成功因素並每個關鍵成功因素確定權重。接下來，要對每項改進活動進行分析，按其對每個關鍵成功因素的貢獻進行評分，然後將結果進行加權平均，作爲最後比較的一個依據。
6.2. 風險因素
通常，風險的來源主要有三個方面：項目的規模、結構的問題和技術。項目規模風險，是指實施的人工成本，一般人工成本越低風險越小。
結構方面的風險，主要有以下因素：參與該項目開發的功能組的數量 。項目的複雜程度。制定解決方案的人員在該過程域的經驗是否豐富。對改進中帶來變更，預期存在牴觸行爲 。
技術風險，主要包括以下方面：需要改進的軟件工程過程的成熟程度 。能否獲得充分的新技術方法的培訓 。工具和其他支持條件的成熟程度 。
6.3. CMMI中的定位
是指某一改進活動對達到更高能力成熟度等級的貢獻。權重是按照KPA所屬的能力成熟度等級來確定，比較簡單。初步確定：目前所處等級的下一個能力成熟度等級的KPA權重最大且相等，其後按順序遞減。各改進點的分值按 其對個KPA的影響確定，有些改進點可能影響多個KPA；另外需要注意，各個改進點對某一個KPA的影響總值不能超過100%。接下來，我們還可以根據評審結果將下一個成熟度等級的KPA進行劃分，看看哪些更重要。評審中，大家達成共識認爲對組織影響最大的問題所對應的KPA應該獲得較高的權重。
6.4. 對改進方案進行排序
進行了以上分析之後，按照分值對各個改進方案進行排序，總分的計算方法如下：
總分=(權重1)(對商業目標的影響)+(權重2)(風險)+ (權重3)(在CMMI中的定位)
公式中的得分是按上面介紹的步驟進行處理得出的，權重主要是根據策劃小組成員的共識確定的，有些公司認爲三方面的因素同樣重要因此賦予相同權重，也有些公司認爲對商業目標的影響的重要性是在CMMI中定位的三倍，而風險因素是在CMMI中定位的兩倍。這樣，基本建立了各個改進項目的優先級，分數最高的優先級最高。
6.5. 估計實施的進度表
排序完成後，我們就要考慮各個改進點的依賴關係，根據優先級順序和依賴關係進行總體戰略策劃，並制定進度表。
6.6. 獲得管理層的承諾
完成正式的計劃、提交管理層獲得認同和承諾。高層管理人員的參與確定關鍵成功因素是非常必要的，因爲他們要負責批准戰略計劃、授權啓動改進項目並且不斷重申對於過程改進的承諾。
7. 參考文獻
《軟件過程改進》 中科永聯高級技術培訓中心
《PMPBOK2004》 (美)項目管理協會
《RUP2003》 IBM