軟件項目管理是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到既定目標的過程，是在軟件開發過程中，對開發工作進行全方位評估的有效措施。

Hello！我是灰小猿，一個有故事、愛分享、沒技術的程序猿，

今天大灰狼來和大家聊聊除了軟件編碼，在軟件項目管理階段所需要進行哪些工作。提前祝大家從技術佬晉升產品總監！

很多剛步入軟件行業或者正在學習的小夥伴都有這樣的感覺，覺得編碼階段是軟件開發中的關鍵步驟，但其實不然，如果我們把軟件開發的過程比作建造一座大橋的話，編碼階段只不過是建築工人添磚加瓦的建造過程，更多的方面則是軟件的設計、管理、維護等階段的進行，同樣這也是一個軟件開發過程中必不可少的階段和流程。

軟件項目管理階段所需要進行的工作分別是：軟件規模評估、工作量評估、進度計劃、人員組織、質量保證、軟件配置管理、能力成熟度模型七個階段。

下面大灰狼和大家聊一下每個階段的任務和評估方法，（文章較長，小夥伴們可以收藏以後慢慢學習）

軟件項目管理

首先，什麼是軟件項目管理？

所謂管理就是通過計劃、組織和控制等一系列活動，合理地配置和使用各種資源，以達到既定目標的過程。

軟件項目管理先於任何技術活動之前開始，並且貫穿於軟件的整個生命週期之中。

軟件項目管理過程從一組項目計劃活動開始，而制定計劃的基礎是工作量估算和完成期限估算。

爲了估算項目的工作量和完成期限，首先需要估算軟件的規模。

軟件規模評估

常用的軟件規模評估的辦法是代碼行技術和功能點技術。這兩種評估方法各有利弊，接下來大灰狼和大家分別分析一下：

一、代碼行技術

代碼行技術是比較簡單的定量估算軟件規模的方法。

依據以往開發類似產品的經驗和歷史數據，估計實現一個功能所需要的源程序行數。

當有以往開發類似產品的歷史數據可供參考時，估計出的數值還是比較準確的。把實現每個功能所需要的源程序行數累加起來，就可得到實現整個軟件所需要的源程序行數。

估算方法：

由多名有經驗的軟件工程師分別做出估計。

每個人都估計程序的最小規模(a)、最大規模(b)和最可能的規模(m)。

分別算出這3種規模的平均值、和之後，再用下式計算程序規模的估計值：

單位：LOC或KLOC。

代碼行技術的優點：

代碼是所有軟件開發項目都有的“產品”，而且很容易計算代碼行數；
有大量參考文獻和數據。

代碼行技術的缺點：

源程序僅是軟件配置的一個成分，由源程序度量軟件規模不太合理；
用不同語言實現同一個軟件所需要的代碼行數並不相同；
不適用於非過程性語言。

二、功能點技術

功能點技術依據對軟件信息域特性和軟件複雜性的評估結果，估算軟件規模。

這種方法用功能點(FP)爲單位度量軟件規模。

1. 信息域特性

功能點技術定義了信息域的5個特性：

輸入項數(Inp)：用戶向軟件輸入的項數，這些輸入給軟件提供面向應用的數據。
輸出項數(Out)：軟件向用戶輸出的項數，它們向用戶提供面向應用的信息。
查詢數(Inq)：查詢即是一次聯機輸入，它導致軟件以聯機輸出方式產生某種即時響應。
主文件數(Maf)：邏輯主文件的數目。
外部接口數(Inf)：機器可讀的全部接口的數量，用這些接口把信息傳送給另一個系統。

每個特徵根據其複雜程度分配一個功能點數，即信息域特徵係數a1，a2，a3，a4，a5，見下表。

2. 估算功能點的步驟

(1) 計算未調整的功能點數UFP

首先，把產品信息域的每個特性都分類爲簡單級、平均級或複雜級，並根據其等級爲每個特性分配一個功能點數。

然後，用下式計算未調整的功能點數UFP： UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf

其中，ai(1≤i≤5)是信息域特性係數，其值由相應特性的複雜級別決定，如表13.1所示。

(2) 計算技術複雜性因子TCF

這一步驟度量14種技術因素對軟件規模的影響程度。在表13.2中列出了全部技術因素，並用Fi(1≤i≤14)代表這些因素。

根據軟件的特點，爲每個因素分配一個從0（不存在或對軟件規模無影響）到5（有很大影響）的值。

然後，用下式計算技術因素對軟件規模的綜合影響程度DI：

技術複雜性因子TCF由下式計算：

TCF = 0.65 + 0.01 × DI

因爲DI的值在0~70之間，所以TCF的值在0.65~1.35之間。

(3) 計算功能點數FP

FP = UFP × TCF

功能點技術優點：

與所用的編程語言無關，比代碼行技術更合理。

功能點技術缺點：

在判斷信息域特性複雜級別和技術因素的影響程度時主觀因素較大，對經驗依賴性較強。

工作量評估

工作量的評估通常有：靜態單變量模型、動態多變量模型、COCOMO2模型，

值得注意的是，大多數估算模型的經驗數據，都是從有限個項目的樣本集中總結出來的。

沒有一個估算模型可以適用於所有類型的軟件和開發環境。

明確了以上兩點之後，接下來就是各個模型的評估方法了，

一、靜態單變量模型

總體結構形式如下：

E = A + B × (ev) C

其中，A、B和C是由經驗數據導出的常數，E是以人月爲單位的工作量，ev是估算變量（KLOC或FP）。

1. 面向KLOC的估算模型

(1)Walston_Felix模型

E=5.2×(KLOC)0.91

(2)Bailey_Basili模型

E=5.5+0.73×(KLOC)1.16

(3)Boehm簡單模型

E=3.2×(KLOC)1.05

(4)Doty模型（在KLOC>9時適用）

E=5.288×(KLOC)1.047

2. 面向FP的估算模型

(1)Albrecht & Gaffney模型

E=-13.39+0.0545FP

(2)Maston,Barnett和Mellichamp模型

E=585.7+15.12FP

二、動態多變量模型

動態多變量模型也稱爲軟件方程式，該模型把工作量看作是軟件規模和開發時間這兩個變量的函數。

動態多變量估算模型的形式如下：

E=(LOC×B0.333/P)3×(1/t)4

其中E 是以人月或人年爲單位的工作量；t 是以月或年爲單位的項目持續時間；B 是特殊技術因子，它隨着對測試、質量保證、文檔及管理技術的需求的增加而緩慢增加，對於較小的程序（KLOC=5~15），B=0.16,對於超過70 KLOC的程序，B=0.39；

P是生產率參數，它反映了下述因素對工作量的影響：

總體過程成熟度及管理水平；
使用良好的軟件工程實踐的程度；
使用的程序設計語言的級別；
軟件環境的狀態；
軟件項目組的技術及經驗；
應用系統的複雜程度。

開發實時嵌入式軟件時，P的典型值爲2000；開發電信系統和系統軟件時，P=10000；對於商業應用系統來說，P=28000。可以從歷史數據導出適用於當前項目的生產率參數值。

三、COCOMO2模型

COCOMO是構造性成本模型（constructive cost model)的英文縮寫。

1981年Boehm在《軟件工程經濟學》中首次提出了COCOMO模型。

1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修訂版，它反映了十多年來在成本估計方面所積累的經驗。

COCOMO2給出了3個層次的軟件開發工作量估算模型，這3個層次的模型在估算工作量時，對軟件細節考慮的詳盡程度逐級增加。

3個層次的估算模型分別是：

應用系統組成模型：這個模型主要用於估算構建原型的工作量，模型名字暗示在構建原型時大量使用已有的構件。

早期設計模型：這個模型適用於體系結構設計階段。

後體系結構模型：這個模型適用於完成體系結構設計之後的軟件開發階段。

該模型把軟件開發工作量表示成代碼行數（KLOC）的非線性函數：

其中，E是開發工作量（以人月爲單位），a是模型係數，KLOC是估計的源代碼行數，b是模型指數，fi (i=1~17)是成本因素。

每個成本因素都根據它的重要程度和對工作量影響大小被賦予一定數值（稱爲工作量係數）。

與原始的COCOMO模型相比，COCOMO2模型使用的成本因素有下述變化。

新增加了4個成本因素，它們分別是要求的可重用性、需要的文檔量、人員連續性（即人員穩定程度）和多地點開發。
略去了原始模型中的2個成本因素（計算機切換時間和使用現代程序設計實踐）。
某些成本因素（分析員能力、平臺經驗、語言和工具經驗）對生產率的影響（即工作量係數最大值與最小值的比率）增加了，另一些成本因素（程序員能力）的影響減小了。

爲了確定工作量方程中模型指數b的值，COCOMO2採用了更加精細得多的b分級模型，這個模型使用5個分級因素Wi(1≤i≤5),其中每個因素都劃分成從甚低（Wi=5)到特高（Wi=0)的6個級別，然後用下式計算b的數值：

因此，b的取值範圍爲1.01~1.26。顯然，這種分級模式比原始COCOMO模型的分級模式更精細、更靈活。

COCOMO2使用的5個分級因素如下所述：

項目先例性：這個分級因素指出，對於開發組織來說該項目的新奇程度。

開發靈活性：這個分級因素反映出，爲了實現預先確定的外部接口需求及爲了及早開發出產品而需要增加的工作量。

風險排除度：這個分級因素反映了重大風險已被消除的比例。

項目組凝聚力：這個分級因素表明了開發人員相互協作時可能存在的困難。

過程成熟度：這個分級因素反映了按照能力成熟度模型度量出的項目組織的過程成熟度。

進度計劃

進度計劃總述

軟件項目的進度安排通過把工作量分配給特定的軟件工程任務並規定完成各項任務的起止日期，從而將估算出的項目工作量分佈於計劃好的項目持續期內。

進度計劃將隨着時間的流逝而不斷演化。

一、估算開發時間

各種模型估算開發時間的方程很相似，例如：

Walston_Felix模型

T=2.5E0.35

原始的COCOMO模型

T=2.5E0.38

COCOMO2模型

T=3.0E0.33+0.2×(b-1.01)

Putnam模型

T=2.4E1/3

其中，E是開發工作量（以人月爲單位），T是開發時間（以月爲單位）。

經驗告訴我們，隨着開發小組規模擴大，個人生產率將下降，以致開發時間與從事開發工作的人數並不成反比關係。出現這種現象主要有下述兩個原因：

當小組變得更大時，每個人需要用更多時間與組內其他成員討論問題、協調工作，因此增加了通信開銷。

如果在開發過程中增加小組人員，則最初一段時間內項目組總生產率不僅不會提高反而會下降。

Brooks規律：向一個已經延期的項目增加人力，只會使得它更加延期。

存在一個最佳的項目組規模Popt，這個規模的項目組其總生產率最高。項目組的最佳規模是5.5人，即Popt=5.5。

二、Gantt圖

Gantt(甘特)圖是歷史悠久、應用廣泛的制定進度計劃的工具。

例子：

舊木板房刷漆工程(15名工人，工具各5把)

Gantt圖的主要優點：

Gantt圖能很形象地描繪任務分解情況，以及每個子任務(作業)的開始和結束時間。
具有直觀簡明和容易掌握、容易繪製的優點。

Gantt圖的3個主要缺點：

不能顯式地描繪各項作業彼此間的依賴關係；
進度計劃的關鍵部分不明確，難於判定哪些部分應當是主攻和主控的對象；
計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。

三、工程網絡

工程網絡是制定進度計劃時另一種常用的圖形工具，它同樣能描繪任務分解情況以及每項作業的開始時間和結束時間。

它能顯式地描繪各個作業彼此間的依賴關係。

工程網絡是系統分析和系統設計的強有力的工具。

符號：

四、估算工程進度

工程網絡必要的信息：

每個作業估計需要使用的時間：箭頭長度和它代表的作業持續時間沒有關係，箭頭僅表示依賴關係，它上方的數字才表示作業的持續時間。

最早時刻EET：該事件可以發生的最早時間。

最遲時刻LET：在不影響竣工時間的前提下，該事件最晚可以發生的時刻。

機動時間：實際開始時間可以比預定時間晚一些，或者實際持續時間可以比預定的持續時間長一些，而並不影響工程的結束時間。

最早時刻的計算：

事件的最早時刻是該事件可以發生的最早時間。

通常工程網絡中第一個事件的最早時刻定義爲零，其他事件的最早時刻在工程網絡上從左至右按事件發生順序計算。

計算最早時刻EET使用下述3條簡單規則：

■考慮進入該事件的所有作業；

■對於每個作業都計算它的持續時間與起始事件的EET之和；

■選取上述和數中的最大值作爲該事件的最早時刻EET。

最遲時刻的計算：

事件的最遲時刻是在不影響工程竣工時間的前提下，該事件最晚可以發生的時刻。

按慣例，最後一個事件(工程結束)的最遲時刻就是它的最早時刻。其他事件的最遲時刻在工程網絡上從右至左按逆作業流的方向計算。

計算最遲時刻LET使用下述3條規則：

■考慮離開該事件的所有作業；

■從每個作業的結束事件的最遲時刻中減去該作業的持續時間；

■選取上述差數中的最小值作爲該事件的最遲時刻LET。

五、機動時間

某些作業有一定程度的機動餘地——實際開始時間可以比預定時間晚一些，或者實際持續時間可以比預定的持續時間長一些，而並不影響工程的結束時間。

機動時間=(LET)結束－(EET)開始－持續時間=右下角－左上角－持續時間

在制定進度計劃時仔細考慮和利用工程網絡中的機動時間，往往能夠安排出既節省資源又不影響最終竣工時間的進度表。

六、關鍵路徑

最早時刻和最遲時刻相同的事件(機動時間爲0的作業)定義了關鍵路徑，在圖中關鍵路徑用粗線箭頭表示。

關鍵路徑上的事件(關鍵事件)必須準時發生，組成關鍵路徑的作業(關鍵作業)的實際持續時間不能超過估計的持續時間，否則工程就不能準時結束。

人員組織

人員組織總述

爲了成功地完成軟件開發工作，項目組成員必須以一種有意義且有效的方式交互和通信。

管理者應該合理地組織項目組，使項目組有較高生產率，能夠按預定的進度計劃完成所承擔的工作。

除了追求更好的組織方式之外，每個管理者的目標都是建立有凝聚力的項目組。

一個有高度凝聚力的小組由一批團結得非常緊密的人組成，他們的整體力量大於個體力量的總和。

一、民主製程序員組

民主製程序員組的一個重要特點是，小組成員完全平等，享有充分民主，通過協商做出技術決策。因此，小組成員之間的通信是平行的，如果小組內有n個成員，則可能的通信信道共有n(n-1)/2條。

程序設計小組的人數不能太多，否則組員間彼此通信的時間將多於程序設計時間。

民主製程序員組通常採用非正式的組織方式，也就是說，雖然名義上有一個組長，但是他和組內其他成員完成同樣的任務。

民主製程序員組的優點：

■組員們對發現錯誤抱着積極的態度，有助於更快地發現錯誤，導致高質量的代碼；

■小組成員享有充分民主，有高度凝聚力，學術空氣濃厚，利於攻克技術難關；

■若組內多數成員經驗豐富，那麼本組織方式會非常成功。

民主製程序員組的缺點：

如果組內多數成員技術水平不高，或是缺乏經驗的新手，由於沒有明確的權威指導開發工程的進行，組員間將缺乏必要的協調，最終可能導致工程失敗。

二、主程序員組

採用這種組織方式的原因：

軟件開發人員多數比較缺乏經驗；

程序設計過程中有許多事務性的工作，例如，大量信息的存儲和更新；

多渠道通信很費時間，將降低程序員的生產率。

主程序員組的兩個重要特性：

1、專業化。該組每名成員僅完成他們受過專業訓練的那些工作。

2、層次性。主程序員指揮成員工作並全面負責。

典型的主程序員組由主程序員、後備程序員、編程祕書以及1~3名程序員組成。

主程序員組核心人員的分工：

主程序員既是成功的管理人員又是經驗豐富、技術好、能力強的高級程序員，負責體系結構設計和關鍵部分的詳細設計，並且負責指導其他程序員完成詳細設計和編碼工作。

後備程序員也應該技術熟練而且富於經驗，他協助主程序員工作並且在必要時（例如，主程序員生病、出差或“跳槽”）接替主程序員的工作。

編程祕書負責完成與項目有關的全部事務性工作，例如，維護項目資料庫和項目文檔，編譯、鏈接、執行源程序和測試用例。

主程序員組的組織方式不切實際：

首先，主程序員應該是高級程序員和優秀管理者的結合體。通常，既缺乏成功的管理者也缺乏技術熟練的程序員。

其次，後備程序員更難找。

第三，編程祕書也很難找到。

三、現代程序員組

實際的“主程序員”應該由兩個人共同擔任：

一個技術負責人，負責小組的技術活動，參與全部代碼審查工作，因爲他要對代碼的各方面質量負責；

一個行政負責人，負責所有非技術性事務的管理決策，不可以參與代碼審查工作，因爲他的職責是對程序員的業績進行評價。行政組長應該在常規調度會議上了解每名組員的技術能力和工作業績。

由於程序員組成員人數不宜過多，當軟件項目規模較大時，應該把程序員分成若干個小組。該圖描繪的是技術管理組織結構，非技術管理組織結構與此類似。

把民主製程序員組和主程序員組的優點結合起來的另一種方法，是在合適的地方採用分散做決定的方法。有利於形成暢通的通信渠道，以便充分發揮每個程序員的積極性和主動性，集思廣益攻克技術難關。

質量保證

一、軟件質量

概括地說，軟件質量就是“軟件與明確地和隱含地定義的需求相一致的程度”。

軟件質量是軟件與明確地敘述的功能和性能需求、文檔中明確描述的開發標準以及任何專業開發的軟件產品都應該具有的隱含特徵相一致的程度。

定義強調了下述的3個要點：

■軟件需求是度量軟件質量的基礎，與需求不一致就是質量不高。

■指定的開發標準定義了一組指導軟件開發的準則，如果沒有遵守這些準則，幾乎肯定會導致軟件質量不高。

■通常，有一組沒有顯式描述的隱含需求。如果軟件滿足明確描述的需求，但卻不滿足隱含的需求，那麼軟件的質量仍然是值得懷疑的。

影響軟件質量的主要因素，是從管理角度對軟件質量的度量。可以把這些質量因素分成3組，分別反映用戶在使用軟件產品時的3種不同傾向或觀點。這3種傾向是：產品運行、產品修改和產品轉移。

二、軟件質量保證措施

軟件質量保證（software quality assurance,SQA）的措施主要有：

■基於非執行的測試（複審或評審），主要用來保證在編碼之前各階段產生的文檔的質量；

■基於執行的測試（軟件測試），需要在程序編寫出來之後進行，它是保證軟件質量的最後一道防線；

■程序正確性證明，使用數學方法嚴格驗證程序是否與對它的說明完全一致。

1. 技術複審的必要性

正式技術複審的顯著優點是，能夠較早發現軟件錯誤，從而可防止錯誤被傳播到軟件過程的後續階段。

統計數字表明，在大型軟件產品中檢測出的錯誤，60%~70%屬於規格說明錯誤或設計錯誤，而正式技術複審在發現規格說明錯誤和設計錯誤方面的有效性高達75%。由於能夠檢測出並排除掉絕大部分這類錯誤，複審可大大降低後續開發和維護階段的成本。

正式技術複審是軟件質量保證措施的一種，包括走查（walkthrough)和審查（inspection）等具體方法。走查的步驟比審查少，而且沒有審查正規。

2. 走查

走查組由4~6名成員組成。走查組組長引導該組成員走查文檔，力求發現儘可能多的錯誤。

走查組的任務僅僅是標記出錯誤而不是改正錯誤，改正錯誤的工作應該由該文檔的編寫組完成。

走查的時間最長不要超過2小時，這段時間應該用來發現和標記錯誤，而不是改正錯誤。

走查主要有下述兩種方式：

■參與者驅動法

■文檔驅動法

3. 審查

■綜述：由負責編寫文檔的一名成員向審查組綜述該文檔。

■準備：評審員仔細閱讀文檔。

■審查：評審組仔細走查整個文檔。

■返工：文檔的作者負責解決在審查報告中列出的所有錯誤及問題。

■跟蹤：組長必須確保所提出的每個問題都得到了圓滿的解決。

通常，審查組由4人組成。組長既是審查組的管理人員又是技術負責人。審查過程不僅步數比走查多，而且每個步驟都是正規的。

4. 程序正確性證明

在20世紀60年代初期，人們已經開始研究程序正確性證明的技術，提出了許多不同的技術方法。

人工證明程序正確性，對於評價小程序可能有些價值，但是在證明大型軟件的正確性時，不僅工作量太大，更主要的是在證明的過程中很容易包含錯誤，因此是不實用的。爲了實用的目的，必須研究能證明程序正確性的自動系統。

目前已經研究出證明PASCAL和LISP程序正確性的程序系統，正在對這些系統進行評價和改進。現在這些系統還只能對較小的程序進行評價。

軟件配置管理

軟件配置管理總述

軟件配置管理是在軟件的整個生命期內管理變化的一組活動。

具體地說，這組活動用來：①標識變化；②控制變化；③確保適當地實現了變化；④向需要知道這類信息的人報告變化。

軟件配置管理的目標是，使變化更正確且更容易被適應，在必須變化時減少所需花費的工作量。

一、軟件配置

1. 軟件配置項

軟件過程的輸出信息可以分爲3類：

■計算機程序（源代碼和可執行程序）；

■描述計算機程序的文檔（供技術人員或用戶使用）；

■數據（程序內包含的或在程序外的）。

上述這些項組成了在軟件過程中產生的全部信息，我們把它們統稱爲軟件配置，而這些項就是軟件配置項。

2. 基線

基線是一個軟件配置管理概念，有助於我們在不嚴重妨礙合理變化的前提下控制變化。

IEEE把基線定義爲：已經通過了正式複審的規格說明或中間產品，它可以作爲進一步開發的基礎，並且只有通過正式的變化控制過程才能改變它。

簡而言之，基線就是通過了正式複審的軟件配置項。

二、軟件配置管理過程

具體來說，軟件配置管理主要有5項任務：標識、版本控制、變化控制、配置審計和報告。

1. 標識軟件配置中的對象

爲了控制和管理軟件配置項，必須單獨命名每個配置項，然後用面向對象方法組織它們。可以標識出兩類對象：

■基本對象，是軟件工程師在分析、設計、編碼或測試過程中創建出來的“文本單元”。

■聚集對象，是基本對象和其他聚集對象的集合。

2. 版本控制

版本控制聯合使用規程和工具，以管理在軟件工程過程中所創建的配置對象的不同版本。

藉助於版本控制技術，用戶能夠通過選擇適當的版本來指定軟件系統的配置。

3. 變化控制

典型的變化控制過程如下：

■首先評估該變化在技術方面的得失、可能產生的副作用、對其他配置對象和系統功能的整體影響以及估算出的修改成本。

■爲每個被批准的變化都生成一個“工程變化命令” 。把要修改的對象從項目數據庫中“提取”出來，進行修改並應用適當的SQA活動。

■最後，把修改後的對象“提交”進數據庫，並用適當的版本控制機制創建該軟件的下一個版本。

4. 配置審計

通常從下述兩方面採取措施：

■正式的技術複審，關注被修改後的配置對象的技術正確性。

■軟件配置審計，通過評估配置對象那些通常不在複審過程中考慮的特徵，是對正式技術複審的補充。

5. 狀態報告

書寫配置狀態報告回答下述問題：

■發生了什麼事？

■誰做的這件事？

■這件事是什麼時候發生的？

■它將影響哪些其他事物？

能力成熟度

能力成熟度模型總述

美國卡內基梅隆大學軟件工程研究所在美國國防部資助下於20世紀80年代末建立的能力成熟度模型（capability maturity model，CMM)，是用於評價軟件機構的軟件過程能力成熟度的模型。

CMM的定義：CMM是對於軟件組織在定義、實施、度量、控制和改善其軟件過程的實踐中各個發展階段的描述。

多種基於CMM的模型，構成了一個CMM族：

SW-CMM ：針對軟件過程的成熟度模型。
P-CMM：人員能力成熟度模型。
SA-CMM：軟件獲取成熟度模型。
IPD-CMM：集成系統產品開發能力成熟度模型。
SE-CMM：系統工程能力成熟度模型。
SSE-CMM：系統安全工程能力成熟度模型。

能力成熟度模型的基本思想是，由於問題是由我們管理軟件過程的方法不當引起的，所以新軟件技術的運用並不會自動提高軟件的生產率和質量。能力成熟度模型有助於軟件開發機構建立一個有規律的、成熟的軟件過程。

對軟件過程的改進，是在完成一個又一個小的改進步驟基礎上不斷進行的漸進過程，而不是一蹴而就的徹底革命。CMM把軟件過程從無序到有序的進化過程分成5個階段，並把這些階段排序，形成5個逐層提高的等級。

CMM

CMM包括以下組成部分：

成熟度等級(Maturity Levels) ；
過程能力(Process Capability)；
關鍵過程域(Key Process Areas, KPA)；
目標(Goals)；
公共特性(Common Features)；
關鍵實踐(Key Practices)。

CMM的用途：

軟件過程評估，藉助CMM分析軟件組織當前軟件過程的狀態，明確其強項和弱項

軟件過程改進，軟件開發組織用它來改進開發和維護軟件的過程，根據評估結果，從低級逐極向更高級發展，制定軟件過程改進的策略。

軟件能力評價，政府或商業企業用它來評價與一個特定的軟件公司簽訂軟件項目合同的風險。

1. 初始級

軟件過程的特徵是無序的，有時甚至是混亂的。幾乎沒有什麼過程是經過定義的（即沒有一個定型的過程模型），項目能否成功完全取決於開發人員的個人能力。

處於這個最低成熟度等級的軟件機構，基本上沒有健全的軟件工程管理制度，其軟件過程完全取決於項目組的人員配備，所以具有不可預測性，人員變了過程也隨之改變。

2. 可重複級

軟件機構建立了基本的項目管理過程(過程模型)，可跟蹤成本、進度、功能和質量。已經建立起必要的過程規範，對新項目的策劃和管理過程是基於以前類似項目的實踐經驗，使得有類似應用經驗的軟件項目能夠再次取得成功。

處於2級成熟度的軟件機構的過程能力可以概括爲，軟件項目的策劃和跟蹤是穩定的，已經爲一個有紀律的管理過程提供了可重複以前成功實踐的項目環境。軟件項目工程活動處於項目管理體系的有效控制之下，執行着基於以前項目的準則且合乎現實的計劃。

3. 已定義級

軟件機構已經定義了完整的軟件過程（過程模型），軟件過程已經文檔化和標準化。所有項目組都使用文檔化的、經過批准的過程來開發和維護軟件。這一級包含了第2級的全部特徵。

處於3級成熟度的軟件機構的過程能力可以概括爲，無論是管理活動還是工程活動都是穩定的。軟件開發的成本和進度以及產品的功能和質量都受到控制，而且軟件產品的質量具有可追溯性。這種能力是基於在軟件機構中對已定義的過程模型的活動、人員和職責都有共同的理解。

4. 已管理級

軟件機構對軟件過程（過程模型和過程實例）和軟件產品都建立了定量的質量目標，所有項目的重要的過程活動都是可度量的。該軟件機構收集了過程度量和產品度量的方法並加以運用，可以定量地瞭解和控制軟件過程和軟件產品，併爲評定項目的過程質量和產品質量奠定了基礎。這一級包含了第3級的全部特徵。

處於4級成熟度的軟件機構的過程能力可以概括爲，軟件過程是可度量的，軟件過程在可度量的範圍內運行。這一級的過程能力允許軟件機構在定量的範圍內預測過程和產品質量趨勢，在發生偏離時可以及時採取措施予以糾正，並且可以預期軟件產品是高質量的。

5. 優化級

軟件機構集中精力持續不斷地改進軟件過程。這一級的軟件機構是一個以防止出現缺陷爲目標的機構，它有能力識別軟件過程要素的薄弱環節，並有足夠的手段改進它們。在這樣的機構中，可以獲得關於軟件過程有效性的統計數據，利用這些數據可以對新技術進行成本/效益分析，並可以優化出在軟件工程實踐中能夠採用的最佳新技術。這一級包含了第4級的全部特徵。

處於5級成熟度的軟件機構的過程能力可以概括爲，軟件過程是可優化的。這一級的軟件機構能夠持續不斷地改進其過程能力，既對現行的過程實例不斷地改進和優化，又藉助於所採用的新技術和新方法來實現未來的過程改進。

以上就是進行軟件項目管理階段的七大階段的主要任務和評估方法，有不足的地方還希望大家及時提出以便更正。

覺得不錯記得點贊關注大灰狼喲！

同時有喜歡Python的小夥伴也可以關注我的微信公衆號“灰狼洞主”後臺回覆“Python筆記”獲取Python從入門到精通學習筆記和python常用函數及方法速查手冊！

大灰狼期待與你一同進步！

程序員一定要會的軟件項目管理評估方案，不做只會敲代碼的碼農！（建議收藏）