軟體過程改進

概述

軟體過程改進/過程改進（Software Process improvement，SPI）幫助軟體企業對其軟體(製作)過程的改變(進)進行計畫、(措施)制定以及實施。 他的實施對象就是軟體企業的軟體過程，也就是軟體產品的生產過程，當然也包括軟體維護之類的維護過程，而對於其他的過程並不關注。

對於軟體企業來說，軟體過程是整個企業最複雜、最重要的業務流程，軟體產品就是軟體企業的生命，改進整個企業的業務流程，最重要的還是要改進它的軟體過程。多年以來，人們認識到要想高效率、高質量和低成本地開發軟體，必須以改善軟體生產過程為中心，全面開展軟體工程和質量管理手段。這是世界各國軟體產業都要走的路，我國軟體產業之所以落後，不是因為技術落後，而是對軟體生產的管理落後。CMM就是結合了質量管理和軟體工程的雙重經驗而制定的一套針對軟體生產過程的規範。由此可見，對軟體生產過程的管理在整個軟體企業的管理中起了決定性作用。因此，從這種意義上講，軟體企業的BPR和CMM軟體過程改進在實施對象是一致的。

在世界範圍內，軟體項目需求正以非常快的速度增長，並且這種增長看起來還遠未達到目的。這種增長已經導致軟體開發活動急劇性的增長，已使得對用於構築軟體的過程，正確的說法是軟體過程，得到更多的關注。軟體過程可以定義為人們用來開發和維護軟體以及相關產品（如：工程計畫、設計文檔、規章、檢測事例及用戶手冊）的一組活動、方法、實踐及轉換。軟體過程重要性的提高已經引起了對軟體過程改進的要求，這就需要過程分析和評估的方法。

CMM在軟體改進措施的策劃上，措施計畫的實施上和過程定義的都有著特使的價值。在策劃改進措施期間，具有有關其軟體過程問題和經營環境的知識的軟體工程組的成員可將CMM重關鍵過程域的目目標和當前的實踐相比較。應該開查與恭喜目標，管理優先權，實踐運行的層次，實施每次實踐對組織的價值，以及改組織在其文化背景下一個實踐的能力等方面有關的關鍵實踐。接下來，軟體工程過程組必須確定那些需要作過程改進，如何實現更改，以及如何獲得所需要的買進。CMM通過給有關過程改進的討論的出發點，並且幫助揭示與通用軟體工程實踐所採用的那些完全不同的假定，從而對這些活動提供幫助。在實施行動計畫計畫時，過程組可以用CMM 和關鍵實踐來構造部門可操作的行動計畫和定義軟體過程。

一、SPI的五條原則

SPI的五條核心原則分別是：
·注重問題
·強調知識創新
·鼓勵參與
·領導層的統一
·計畫不斷地改進。

“問題的解決是過程改進的核心，實踐不僅是SPI組的目標也是它的起點。”這條原則為過程改進人員指明了目標，明確了方法。SPI就是要在實踐中發現軟體過程中的問題，並在實踐中尋找和找到解決問題的辦法，可以說過程改進就是在不斷發現問題和解決問題的過程中不斷向前發展。

“改進是一種知識的創新，SPI是受知識的驅動的”。這條原則強調了知識創新在SPI中的作用，提醒了SPI人員在注重知識創新的同時更要注重知識的傳播和擴散。

通常從事SPI工作的做法是，過程改進僅僅是過程改進人員的事情，其他人員只是被動地接受。而“合作促使改進產生”這條原則給予了我們很好的啟發和提示。它告訴我們，過程改進不僅僅是一個人或幾個人的事情，而是整個組織的事情。只有鼓勵大家都積極參與，讓這些人基於自身的經驗和職業的判斷力來實實在在地設計和開發新的過程，才能使設計出來的過程真正為他們所理解，為他們所用，從而實現過程的成功。這也是我們在過程改進工作中容易疏忽的地方。

“SPI的關鍵點在於改變軟體開發的方式。然而，改變人的行為並不是件容易的事。”這條原則分析了我們在這項工作中可能會遇到的困難和阻力，本書中也不忘為我們提供了如何克服這些問題的可行方法、建議和實例。

“改進必須是綜合了各個層次的人的力量。”SPI人員一定要保證SPI的目標與組織的整體目標是一致的，因為只有這樣才能保證SPI工作得到各個領導層的贊同、支持和投入，才能綜合利用各個層次的力量來推動SPI工作的前進。這是預防過程改進項目風險的重要手段。

“改進應該是一個不斷持續的過程。”這一原則進一步提示和告誡SPI人員一定要認識到改進的不斷持續的特性。到達頂點並不重要，關鍵的是，你現在處在一個上升??達一個目標你就創造了另一個更高的目標，這個目標對我們的過程和環境都具有重要的意義。

這五條原則是從實踐中發展而來、相互關聯的SPI哲學，對我們SPI工作具有非常重要的指導作用。

二、軟體過程改進的策略

策略一：兩個方針

重診斷，輕評估 以診斷和解決企業實際問題為SPI方法論，不追求商業評估。以往實施ISO9000的過程中發現，企業拿證書的願望常常會沖淡“真正改進”的目的。所以，除非不得已，建議一開始不要把商業評估作為目標，以便將焦點集中在“改進”上。的確，一旦進行商業評估，難保不急功近利，限期取證。SPI如同“治病”，多長時間治好怎么可以人為規定呢？
重診斷,正是前述自底向上方法論的具體貫徹。根據企業的不同狀態和症狀，實施有針對性的方案，將有望設計出實用性更強、效率更高的套用模型。
重實施，輕宣傳 我們不妨來看一組數據，這是北京SPIN去年發起的一次調查，提問是“您認為軟體企業中開發不規範，不能突破管理瓶頸的原因是什麼？”
可見，以往我們多年來實施ISO9000這樣的體系，但效果差得可憐（客戶滿意度12%）。

據報導，中國通過ISO9000的企業超過了日本和韓國，但是中國並沒有因此成為質量強國！

ISO9000在軟體企業的現狀，並不能僅僅歸結於ISO9000不適合軟體企業這一點上，更大的問題在於，人們對體系的“可實施性”研究和重視得不太夠。
所以我們提出以高的“過程實施率”（定義的文檔被很好的遵守）和“過程性能改善”為SPI目標，不追求宣傳效應。

策略二：兩手抓

實施制度化的同時，並行實施企業文化；既要施壓，又要清障。
中小企業往往制度化體系很不健全，存在著隨意決策的管理習慣，甚至基本的企業紀律都不具備，企業還處於“人治”和“法制”的爭論中，這樣的狀態和某些大企業實施SPI的狀況是不同的，需要特彆強調行政施壓。由於缺乏統一的企業文化，所以理念的統一也要加以重視。

CMM的實質是制度化體系，實施CMM也是實施全面制度化的有效途徑。但是制度和企業文化總是辨證存在的，沒有良好的文化保障，制度化將困難重重，而沒有制度的支撐，文化也將是無源之水。企業文化的實施從改造企業價值觀開始，價值觀是企業文化的核心，一個企業中如果好的行為不能得到鼓勵，壞的行為不能得到懲罰，那怎么能倡導出有利於制度生存的價值觀呢？

兩手抓還包括另外一個層次的含義，過程改進要加強推進和減少阻力並重。這針對兩種現實中的錯誤認識：一種認為，員工都是自覺的，只要把道理講清楚了，制度就能得到實施。這種假定是不現實的，如同法律，如果假設人們都是遵紀守法的，那么法律本身就沒必要存在了。實際情況是，人們在組織中總是有區分的，有的人主動順應變革，有的人推一推也能動，有的人可能推十下也不動，從而成為變革的障礙。所以變革的落實需要一個強的“推力”。另外一個觀點剛好相反，認為沒必要對員工講為什麼，只要告訴怎樣做就行了。這又走到另外一個極端，體系在強力的推動下可能會暫時得到執行，但是由於並沒有解決觀念轉變的問題，一定難以持久。

策略三：推行兩種工具

要推行配置管理工具和項目管理工具這兩種工具，工具將有效分解事務性工作，從而緩解人力資源投入不足的矛盾。
配置管理工具根據不同的平台推薦使用VSS和CVS，項目管理工具使用微軟公司的MSP。使用工具，可有效分解管理工作量，提升工作效率；有助於管理制度的真正落實，使體系更加固定化。

策略四：補兩門基礎課

為了解決基礎薄弱的問題，需要在SPI前期為企業補基礎管理和基本軟體工程兩門課。

CMM的設計是以美國的軟體企業為研究對象，它假定企業在實施CMM前，已經具備了基本軟體工程和基本管理的能力，所以有“先管理、後工程”的觀點。就是先把項目管理到位，再實施軟體工程（即軟體工程到位）。

但是這個假定對於絕大部分的中國軟體企業是不成立的。

軟體企業需要補的基礎管理內容包括：基本時間管理、角色轉變、目標管理、溝通管理、基本人力資源管理等。基本軟體工程則包括基本的軟體工程生命周期、階段劃分、基本文檔編制等。

策略五：發動三方參與

按照ISO9000的說法叫全員參與，分成三個層面就是：

一是高於項目管理的層面，稱為高層經理。他們提供資源和戰略兩方面的支持，所以高層經理應該對體系總體架構、體系實施必要性、可行性、障礙和風險、資源等負有責任。

二是項目管理層面，含項目經理和SPI人員。SPI人員作為制度化體系的執行者和推行者應該加強自身修養，要求別人的事，一定要自己能做到。而項目經理作為主要的一線實施人員，需要對整個體系的細節有深入了解和研究，應該把日常工作時間的30%～50%放在工程化管理相關事宜上，要貫徹公司的SPI整體制度，積極主動在項目組內進行推行。

三是項目組成員，包括開發和測試人員，要求團隊以紀律性要求自己，做好局部和整體、短期和長期的矛盾平衡。

特別要關注試點項目的PM(項目經理)選擇，選擇好的PM意味著SPI一半的成功。
需要說明的是，自底向上並不是絕對不做正式評估，如果需要，等到水到渠成再實施評估，不僅使得過程改進更實在，而且只需投入少量的資金就可獲得評估。

三、軟體過程改進戰略策劃

介紹

如果我們把軟體過程改進看作一個項目，象其他項目一樣，它也要有一個好的計畫，這個計畫不但要滿足公司的商業目標，還要包含過程改進戰略和具體的實施步驟（子項目）。 軟體過程改進非一日之功，急於求成必將導致失敗；因此，如果不進行系統的戰略策劃而盲目進行過程改進，只會浪費時間和資金而不會取得好的效果。有了有效的戰略計畫，我們才能在這項長期的活動中獲得管理人員、開發人員和公司的所有者的理解和耐心的支持。

那么如何進行戰略策劃呢？本文介紹的兩位主任評審員開發的過程改進戰略策劃的方法，已經在很多軟體企業成功實施。其中套用的主要技術包括：戰略決策、優先權排序、過程改進與過程評審。

通常，戰略策劃由一個小組負責，小組裡要包括參與了過程評審的人員以及其他策劃工作的受益人，另外高層經理的參與是非常重要的；策劃的方式是在負責人的指導下以討論方式進行。實踐證明，以下步驟非常有效：

針對不同的改進點分別制定改進方案
方案評價
將改進方案排序
估計並制定實施的進度表
獲得管理層的承諾
具體介紹如下：

1 制定過程改進方案
評審結束後，策劃組要對評審結果進行分析，篩選出十個左右的改進點；然後將每個改進點都作為一個改進項目，分別制定兩到三頁的改進方案。方案主要包括以下內容：
現狀的簡單介紹
改進方案介紹
預期收益
實施負責人
對成本、資源和項目周期的估計
方案中還應該說明建議使用的實施方法，例如是否進行試用等。估計成本時要包括：過程定義的時間、試用期間人員培訓的成本、處理反饋意見的時間和重新試用的成本。
因為所有的改進工作不可能一次實施，所以接下來我們要確定各個改進項目的優先權，具體步驟如下：

2 評價各個改進方案
我們怎么確定改進活動的優先權呢？主要是通過考察三方面的因素，即：對商業目標的影響、風險和在CMM中的定位。
有些公司還會對各方案進行成本/收益分析（例如，考察投資回報率），但是1級或2級的企業往往沒有充分的歷史數據，因此無法準確估計過程改進的無形收益；4級和5級的企業通常就能作到這一點，3級的企業也有可能作到。
2.1 對商業目標的影響
對商業目標的影響是指某項改進工作對總體的戰略目標的影響。
首先，策劃小組要和主管的高層經理進行討論，明確公司商業目標、並分析確定決定商業目標能否實現的5-7個關鍵成功因素（CSFs）。如果公司沒有明確成文的商業目標，小組的首要工作就是確定商業目標；如果商業目標已經非常清楚、明確，並且形成了文檔，策劃小組的核心工作就是分析關鍵成功因素並每個關鍵成功因素確定權重。
接下來，我們要對每項改進活動進行分析，按其對每個關鍵成功因素的貢獻進行評分，然後將結果進行加權平均，作為最後比較的一個依據。

2.2 風險因素
風險是指實施改進工作的困難程度，我們要考慮實施某項改進是象賭博一樣冒險么？結果是不是有一定的可預測性呢？通常，風險的來源主要有三個方面：項目的規模、結構的問題和技術。
項目規模風險，是指實施的人工成本，一般人工成本越低風險越小。
結構方面的風險，主要有以下因素
參與該項目開發的功能組的數量
項目的複雜程度
制定解決方案的人員在該過程域的經驗是否豐富
對改進中帶來變更，預期存在牴觸行為
技術風險，主要包括以下方面：
需要改進的軟體工程過程的成熟程度
能否獲得充分的新技術方法的培訓
工具和其他支持條件的成熟程度

2.3 CMM中的定位：
是指某一改進活動對達到更高能力成熟度等級的貢獻。權重是按照KPA所屬的能力成熟度等級來確定，比較簡單。我們可以初步確定：目前所處等級的下一個能力成熟度等級的KPA權重最大且相等，其後按順序遞減。各改進點的分值按其對個KPA的影響確定，有些改進點可能影響多個KPA；另外需要注意，各個改進點對某一個KPA的影響總值不能超過100%。
接下來，我們還可以根據評審結果將下一個成熟度等級的KPA進行劃分，看看哪些更重要。評審中，大家達成共識認為對組織影響最大的問題所對應的KPA應該獲得較高的權重。

3 對改進方案進行排序

進行了以上分析之後，我們按照分值對各個改進方案進行排序，總分的計算方法如下：
總分=(權重1)(對商業目標的影響)+(權重2)(風險)
+ (權重3)(在CMM中的定位)
公式中的得分是按上面介紹的步驟進行處理得出的，權重主要是根據策劃小組成員的共識確定的，有些公司認為三方面的因素同樣重要因此賦予相同權重，也有些公司認為對商業目標的影響的重要性是在CMM中定位的的三倍，而風險因素是在CMM中定位的兩倍。
這樣，我們就基本建立了各個改進項目的優先權，分數最高的優先權最高。

4 估計實施的進度表

排序完成後，我們就要考慮各個改進點的依賴關係，根據優先權順序和依賴關係進行總體戰略策劃，並制定進度表。有趣的是，優先極較低的改進項目往往是優先權較高的項目的先決條件，因此在進度表中就應該靠前。另外，我們還要考慮實施效果的影響和可視性。例如，對於1級的企業，管理層還沒有建立起過程改進的威信，過去給人的印象總是言行不一，那么就要選擇風險較低，大家都能看到且有不凡收益的改進項目，幫大家建立信心，即使這些項目優先權較低。

5 獲得管理層的承諾

下一步，我們要完成正式的計畫、提交管理層獲得認同和承諾。我們在上面說過，高層管理人員的參與確定關鍵成功因素是非常必要的，這裡，我們要再次強調管理層的重要作用，因為他們要負責批准戰略計畫、授權啟動改進項目並且不斷重申對於過程改進的承諾。
過程改進的總體計畫通常包括：介紹（說明計畫的目標）、制定計畫時所使用的方法、對評審結果和推薦措施的總結，主要內容是各個改進項目的方案和策劃活動的結果。當然也應該包括：進度表、相關任務、負責人、項目運行指標以及所需的資源，如：人員、資金、軟體、硬體工具等。
管理人員評審和簽字批准，意味著管理層對改進活動人員和資源上的支持和承諾。

總結

通過以上的介紹，希望大家對過程改進的戰略策劃有了一定的了解。我們需要強調的是：成功的過程改進策劃是建立在以下的基本原則之上的：
過程改進與商業目標相結合
合適人員的參與
有效的策劃方法
積極溝通、思路共享
保持整體觀念
我們的很多客戶通過實施以上的方法，在評審結束後迅速、有效地實施了過程改進，他們對自己的決策滿懷信心、不斷向著更高的能力成熟度邁進。

四、軟體過程改進建議

1 改進用戶需求過程
1.1 改進用戶需求的獲取方式
1) 研究用戶特點
2) 成立需求調查小組
1.2 改進獲取用戶需求的態度
1) 正式的外部文檔方式
2) 正式的提交過程
1.3 改進用戶需求內容準備工作
1) 專業的用戶需求調查表單，力求取得用戶的配合，由用戶或需求調?
1) 用戶需求的分析、總結，須及時反饋到用戶方，以取得及時而有效、滿意但不多餘的需求
2 改進需求分析方式
1) 改進需求分析的前提條件——正確的獲取用戶的需求
2) 針對不同類型的系統採用不同的需求方式和模型，更有助於界定需求的範疇
3) 及時總結、改進需求分析方式和模型，形成需求分析模式庫
4) 復用和改進需求分析模式庫
5) 載入有效的、適用的、先進的需求分析理論於經驗分析基礎之上
6) 改進項目組內需求分析的溝通和流通
7) 在需求分析初始，儘早分析需求的可行性，並作備案
8) 對不適當需求，與用戶溝通，以取得理解和信任
9) 對不合理需求，協調用戶，以降低成本
10) 需求一旦獲得認定，儘快進行系統分析和設計
11) 及時有效的控制需求的變化，防止對需求隨意的更改和增刪
3 改進系統分析和設計原則
1) 以最小的代價實現系統
2) 以開發人員最熟悉的方法、技術和工具實現系統
3) 儘量採用先進的方法和理論，以適應發展的需求
4) 在系統的相關處，與具體的實施人員進行及時有效的溝通，尋求實現的最佳途徑
5) 以簡單、易懂的方式進行分析和設計
6) 以簡單、易懂的方式表現系統
7) 系統分析的方式要易於復用，並及時進行調整、改進，系統系統分析庫
8) 對系統的分析、設計加以控制、遵守，防止系統結構的隨意更改
4 改進系統的實施和驗證
1) 確保在取得共同的理解後才進行系統的實施和驗證
2) 系統的實施和驗證遵循一定的流程，以約定的方式進行溝通
3) 系統的變化能夠以多種不同方式進行溝通，以確保變化被告知、並被認可
4) 確保在系統的實施和驗證過程中，所採用的方式和方法是易於理解的，且不易發生變化
5) 系統的實施和驗證完成標識明顯，易於被相關人員識別
5 改進用戶驗收被動局面
1) 理解和支持用戶的行為
2) 取得用戶的理解和支持
3) 對系統進行充分的驗證
4) 提高系統安裝的成功率和速度
5) 改進系統界面，使系統直觀、有效
6) 保證進度，提高誠信度
6 改進系統維護過程
1) 對用戶進行有效的培訓
2) 快捷、有效、合理的處理用戶的問題
3) 跟蹤問題，形成問題庫

五、為什麼要實施SPI？

SPI的最根本利益其實在於，他能夠極大的提高項目成功的幾率，這是大家都追求的。當然需要明確定義這裡的“項目成功”的含義，不是客戶要求三個月完工，最後按時交工，就是成功。而是綜合平衡進度、交付後質量、成本等若干要素後所達到的最優狀態。

在項目管理三要素中，項目干係人通常會把進度當作第一目標，結果相當多趕進度完成的項目，在交付後面臨者大量的後續修改，甚至推翻重來。如果把這部分開銷算到項目中去，項目早已失敗的一塌糊塗了。
對大量失敗項目的統計結果表明，最大的原因在於缺乏過程或者沒有很好的遵循已定義的過程。我們知道決定項目質量和生產率的要素有人、技術和過程，如果借用木筒的比喻，過程不見得是其中最寬的一條，但是當前它是最短的，所以它決定著木桶的盛水量。我們迫切的需要SPI，就是要把最短的木條儘快補上去。

只有基於良好的過程，人和技術才能發揮出最大的威力。

六、以項目形式管理SPI

以項目形式管理軟體過程改進，特別有利於提高團隊凝聚力、規避風險、明確目標、提高效率，而且由於SPI項目組與其他項目組形成了一種矩陣式組織結構，可以有效促進組間交流。所以對於SPI這樣一件比較複雜的工程來說，以項目形式進行管理將是成功的重要保證。

國外的一項有關SPI（Software Process Improvement軟體過程改進）的調查表明，沒有很好地對過程改進進行管理造成了至少70%以上的軟體企業改進失敗或挫折！當我們問自己如下問題的時候，能否迅速給出滿意的答案——
SPI強調管理，自身是如何管理的？
SPI提供方法論，自己的方法論如何？
SPI強調做事要有計畫性，自身計畫性如何？
SPI倡導風險管理，自身的風險被很好識別了嗎？
本文試圖給出一種對SPI自身進行管理的方法——“以項目形式管理SPI”。

以項目形式管理SPI通常分為如下五步驟：體系診斷，方案設計，項目策劃，過程管理，項目驗收總結。

體系診斷

診斷是一切過程改進和管理諮詢的前奏，對於不以取證為目的的軟體過程改進來說，這一步尤其重要。

“過程診斷”和“過程審計”有著某種程度的相似性，通常的方式為面談、文檔查閱、檢查表填寫等形式。
典型的基於CMM的檢查表（軟體項目跟蹤和監督）舉例如下：

　 典型的SPI診斷花費大約為2～3人/日，這和組織的成熟度、組織的歷史長短、管理和業務的複雜度都有關係。

對診斷過程的漠視是自上向下改進策略的最大弊端。

方案設計

在了解了組織、項目的實際狀態以後，就可以有針對性地提出解決方案了，這一步驟稱為方案設計。

在上圖方案中，我們可以看到主要的元素來自於CMM、SEBOK（軟體工程）、Good Practice (最佳實踐)。這種結果是與該企業的如下現狀相適應的:

首先，該企業沒有形成基本的軟體工程流程。

其次，項目沒有生命周期的概念，無明確啟動和驗收點，正如其項目經理所言，“我們的項目結束點要等到下一個項目已經開始，本期項目不得不結束時才會出現”。

再次，該企業整體管理基礎薄弱，資源提供不充分，這種情況下，在大企業順理成章的事情可能在這裡都是問題，所以需要大量的變通和折衷策略，這些都被歸納在Good Practice中。

諸如此類的方案設計，存在兩個裁減特徵: 一是橫向裁減，可以在打破現有知識體系的基礎上，創造性的構建新體系；其二是縱向裁減，比如對於CMM具體KPA，也可以分兩步或更多步來達到要求。所有這些裁減都會帶來更多的靈活性。

SPI方案的編制需要涵蓋如下內容：本組織軟體過程改進的歷史，過程診斷（包括診斷方法、診斷結果和差距分析），改進方案（包括總體目標、總體工程化管理系統設計和詳細改進措施），資源需求預測，計畫進度概要（包括前提和承諾、資源需求預測），風險，里程碑。

項目策劃

方案得到認可後，可啟動項目策劃。SPI的項目策劃要求與其他項目策劃的要求並無多少差異，主要是編制一份項目計畫，有如下內容：項目目標（包括整體目標和本階段目標），假定和約束，項目組織（包括組織結構、接口關係、報告關係和責任矩陣），項目進度跟蹤方式，項目里程碑，交付物（包括文檔編制和人員培訓），風險管理，項目激勵，項目驗收。

值得一提的是SPI風險管理，其說明如下表。

過程管理

計畫制定好以後，還要對 SPI的實施過程進行定期和不定期的過程跟蹤，一般可通過“周”和“里程碑”兩種周期進行跟蹤。周跟蹤的內容為進度、完成量、問題和風險，通過周報和周會的形式進行；里程碑跟蹤的內容為進度、工作量、人力開銷、風險等，還要對項目管理的經驗和教訓進行總結，里程碑也是識別典型案例和收集最佳實踐的良好時機。里程碑跟蹤活動通常包括“里程碑總結報告編制”和“里程碑總結會”兩種形式。

項目驗收總結

對於自底向上的軟體過程改進，並沒有標準的驗收準則可利用，這要求組織根據自身裁減的體系編制自己的驗收準則。驗收準則有定性和定量兩種形式，定量適合於有一定管理基礎的組織，需要有足夠的、可信的、可比的歷史數據。但多數中小軟體企業可能在起步階段只能選擇定性驗收的方式，這種定性驗收方式常常是“先僵化、再固化、後最佳化”理念的一種體現。

項目驗收後，組織需要進行SPI項目的最後一項活動——項目總結，需要提交書面報告並召開總結會，項目總結中要統計匯總SPI本身數據、進度、開銷、偏差及分析，還要識別和共享經驗教訓。這一階段的工作將為今後的SPI持續改進打下良好的基礎。SPI將進入下一個改進循環。