--軟件項目管理軟件工程--軟件項目管理軟件工程1內(nèi)容提要軟件項目管理活動項目規(guī)劃項目進度質(zhì)量管理軟件成本估算人員管理配置管理CMM內(nèi)容提要軟件項目管理活動2軟件項目管理概述隨著信息技術(shù)的飛速發(fā)展，軟件產(chǎn)品的規(guī)模也越來越龐大，個人單打獨斗的作坊式開發(fā)方式已經(jīng)越來越不適應(yīng)發(fā)展的需要。各軟件企業(yè)都在積極將軟件項目管理引入開發(fā)活動中，對開發(fā)實行有效的管理。軟件項目管理就是通過合理地組織和利用一切可以利用的資源，按照計劃的成本和計劃的進度，完成一個計劃的目標，它包含團隊管理、風(fēng)險管理、采購管理、流程管理、時間管理、成本管理和質(zhì)量管理等。是否需要管理是專業(yè)軟件開發(fā)和業(yè)余編程之間的重要區(qū)別。軟件項目管理概述隨著信息技術(shù)的飛速發(fā)展，軟件產(chǎn)品的規(guī)模也越來3軟件項目管理的特點軟件產(chǎn)品是無形的；沒有標準的軟件過程；大型軟件項目經(jīng)常是“一次性的”。軟件工程管理者與其他工程管理者的性質(zhì)是相同的，但軟件工程管理很多方面有顯著的區(qū)別，這導(dǎo)致了軟件工程管理的難度相當大。許多大型軟件項目的失敗也告訴我們：軟件管理困難重重。軟件項目管理的特點軟件產(chǎn)品是無形的；軟件工程管理者與其他工程4軟件項目管理的特點項目管理是一項復(fù)雜的工作。項目管理具有創(chuàng)造性。項目管理需要集權(quán)領(lǐng)導(dǎo)和建立專門的項目組織。項目負責(zé)人在項目管理中起著非常重要的作用。具有創(chuàng)新性的工程項目經(jīng)常會存在進度問題。軟件項目管理的特點項目管理是一項復(fù)雜的工作。具有創(chuàng)新性的工程5軟件項目管理活動提出項目建議書項目規(guī)劃與進度項目成本管理項目監(jiān)督和評審人員管理擬定工作報告軟件項目管理活動提出項目建議書6項目建議書項目建議書要寫清楚：項目的目標和實現(xiàn)該目標的方法；還要估算項目的成本和進度；有時還要說明與某一特定機構(gòu)或團隊簽約的理由。許多軟件機構(gòu)之所以存在是因為其手頭有大量的建議書和合同。寫建議書沒有固定的格式供參考，它是一種經(jīng)驗性的技巧。項目建議書項目建議書要寫清楚：項目的目標和實現(xiàn)該目標的方法；7項目監(jiān)督項目監(jiān)督是一種連續(xù)性的活動。管理人員必須密切關(guān)注項目進展情況，將實際進展和成本與原計劃的進度和成本作比較。項目監(jiān)督可以劃分為：正式監(jiān)督非正式監(jiān)督項目監(jiān)督項目監(jiān)督是一種連續(xù)性的活動。管理人員必須密切關(guān)注項目8項目規(guī)劃對軟件項目的有效管理取決于對該項目進展狀況的全面規(guī)劃。項目管理者必須能預(yù)見可能出現(xiàn)的問題，并且準備好相應(yīng)的解決方案予以應(yīng)對。項目規(guī)劃在項目之初擬定，它是整個項目的驅(qū)動器。項目規(guī)劃是一個反復(fù)的過程，只有當項目完成時規(guī)劃才告一段落。項目規(guī)劃對軟件項目的有效管理取決于對該項目進展狀況的全面規(guī)劃9項目規(guī)劃過程確定項目的約束條件初步評估各項項目參數(shù)定義項目里程碑和可交付的文檔while項目未完成或被取消loop 擬定項目進度表 根據(jù)項目進度表啟動各項活動 等待（一定的時間） 評審項目進展狀況 修正對項目參數(shù)的初步估算 更新項目進度表 重新協(xié)商項目約束條件和可交付的文檔 if(出現(xiàn)問題)then 開始進行技術(shù)評審和可能的修正 endifendloop項目規(guī)劃過程確定項目的約束條件10(開發(fā)過程)項目計劃有些機構(gòu)的項目計劃包含：開發(fā)計劃、質(zhì)量計劃、有效性驗證計劃、配置管理計劃、維護計劃和人員開發(fā)計劃。有些機構(gòu)只涉及開發(fā)過程。項目計劃書的具體內(nèi)容隨著項目和開發(fā)機構(gòu)類型不同而改變。不過多數(shù)計劃書應(yīng)該包括以下幾個部分：引言項目組織風(fēng)險分析軟硬件資源需求工作分解項目進度監(jiān)控和報告機制(開發(fā)過程)項目計劃有些機構(gòu)的項目計劃包含：開發(fā)計劃、質(zhì)量計11項目里程碑一個項目里程碑就是一個軟件過程活動的終結(jié)。在每個里程碑都應(yīng)該有一個正式的可以提交給管理層的輸出結(jié)果。里程碑應(yīng)代表該項目的一個特定的邏輯意義上的階段的終結(jié)。里程碑的兩個必要特征：與軟件開發(fā)進展相關(guān)聯(lián)；在完成時必須非常明顯。項目里程碑一個項目里程碑就是一個軟件過程活動的終結(jié)。在每個里12可交付的文檔可交付的文檔是交付給客戶的項目成果，通常是在項目的描述、設(shè)計等主要項目階段結(jié)束時交付。可交付的文檔也是里程碑，但里程碑不一定要交付。里程碑是項目內(nèi)部的階段性成果，供項目管理者來檢查項目進展情況。可交付的文檔可交付的文檔是交付給客戶的項目成果，通常是在項目13軟件過程中的里程碑要建立里程碑，軟件過程就一定要分解成一系列相關(guān)的基本活動，而每一個這樣的基本活動都要建立相應(yīng)的輸出結(jié)果。以需求工程為例(以建立原型來幫助驗證需求)：可行性研究需求分析原型開發(fā)設(shè)計研究需求描述可行性研究報告用戶需求估算報告體系結(jié)構(gòu)設(shè)計系統(tǒng)需求活動里程碑軟件過程中的里程碑要建立里程碑，軟件過程就一定要分解成一系列14項目進度項目進度對軟件管理者的要求是十分苛刻的。管理人員必須估算完成各項活動所需要的時間和資源，并按照一定的順序把他們緊密組織起來。項目進度包括把一個項目所有工作分解為若干獨立活動，以及完成這些活動所需的時間。項目進度項目進度對軟件管理者的要求是十分苛刻的。管理人員必須15項目進度過程軟件需求識別活動識別活動依賴關(guān)系估算活動的資源為活動分配人員創(chuàng)建項目圖表活動圖表及條形圖有些活動是并行進行的，調(diào)度人員必須協(xié)調(diào)這些并行活動，并把整個工作組織起來，使人力資源得到充分利用。一定要避免出現(xiàn)因一項關(guān)鍵任務(wù)沒有完成而使整個項目延期交付的情形。項目進度過程軟件需求識別活動識別活動估算活動為活動創(chuàng)建活動圖16活動分解及進度管理正常情況，各活動應(yīng)至少持續(xù)1周；對所有活動安排一個最高的時間限制（8～10周左右），如一項活動持續(xù)時間超過限制，就應(yīng)該再次細分；估算進度時，管理者不能想當然認為項目的每個階段都不會出問題；初時間外，還必須估算完成每項任務(wù)所需的資源：人力資源和其他可能的資源。經(jīng)驗法則：估算時先假定什么問題也沒有，然后再把預(yù)計出現(xiàn)的問題加到估計中去（＋30％）。還要考慮因偶然因素帶來的意想不到的問題（＋20％）?；顒臃纸饧斑M度管理正常情況，各活動應(yīng)至少持續(xù)1周；經(jīng)驗法則：17進度管理工具項目進度通常用一系列的圖表表示，通過這些圖表可以了解任務(wù)分解、活動依賴關(guān)系和人員分配情況。常用的項目進度表示法有：甘特圖（Gantt）活動網(wǎng)絡(luò)圖（PERT）常用軟件管理工具是：MS-Project進度管理工具項目進度通常用一系列的圖表表示，通過這些圖表可以18甘特圖是歷史悠久、應(yīng)用廣泛的制定進度計劃的工具。例：假設(shè)有一座陳舊的矩形木板房需要重新油漆。這項工作必須分3步：首先刮掉舊漆，然后刷上新漆，最后清除濺在窗戶上的油漆。一共分配了15名工人去完成這項工作，而工具只有：5把刮舊漆的刮板，5把刷漆用的刷子，5把清除濺在窗戶上油漆的小刮刀。如何安排工作，最有效？甘特圖是歷史悠久、應(yīng)用廣泛的制定進度計劃的工具。例：19甘特圖刮舊漆刷新漆清理1或32312或4462墻壁工序各道工序估計需要時間（小時）木板房的第2、4兩面墻的長度是第1、3兩面墻的一倍。一種做法是，先刮掉4面墻的舊漆，然后給每面墻刷新漆，最后清除每個窗戶上的油漆，共需時間36小時。顯然，這是效率最低的做法，任何時候都有10名工人閑著沒事干。甘特圖刮舊漆刷新漆清理1或32312或4462墻壁工序各道工20248101214182016622甘特圖111234刮舊漆刷新漆清理時間(小時)工序舊木板房刷油漆工程的Gantt圖“流水作業(yè)法”肯定是好的方法。全部工程在22小時后結(jié)束。234234248101214182016622甘特圖111234刮舊漆21軟件工程是特殊的工程，Gantt圖也可以特殊化，每個任務(wù)的開始和結(jié)束時間均先用空心三角形表示，兩者用橫線相連。當活動開始時，左邊三角形涂黑，當活動結(jié)束時，再將右邊三角形涂黑。任務(wù)負責(zé)人2000年2001年123456789101112123456分析▲－－▲測試計劃▲－△總體設(shè)計▲－△詳細設(shè)計△－－△編碼△－－－△模塊測試△－△集成測試△－－△驗收測試△－△文檔▲－－－－－－－－－－－△軟件工程是特殊的工程，Gantt圖也可以特殊化，每個任務(wù)的開22甘特圖Gantt圖形象地描繪了任務(wù)的分解，及每個作業(yè)的開始和結(jié)束時間，優(yōu)點是直觀簡明、容易掌握和繪制，但有三個缺點：不能顯示地描繪各項作業(yè)間的依賴關(guān)系；進度的關(guān)鍵部分不明確，難以判斷哪些部分是主攻和主控的對象；計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。甘特圖中，每一任務(wù)完成的標準，不是以能否繼續(xù)下一階段任務(wù)為標準，而是必須交付應(yīng)交付的文檔與通過評審為標準。甘特圖Gantt圖形象地描繪了任務(wù)的分解，及每個作業(yè)的開始和23PERT圖與CPM技術(shù)1235468791011刮1刮2刮3刮4刷1刷2刷3刷4清1清2清3清4PERT圖中：對于某事件，箭頭進入表示此作業(yè)結(jié)束，箭頭離開表示此作業(yè)的開始；實線箭頭表示具體存在的作業(yè)；虛線箭頭表示虛擬作業(yè)，只為了表示作業(yè)之間的依賴關(guān)系。PERT圖與CPM技術(shù)1235468791011刮1刮2刮324活動網(wǎng)絡(luò)圖用箭頭表示作業(yè)(如刮舊漆、刷新漆、清理等)，用圓圈表示事件(一項作業(yè)的開始或結(jié)束)；事件僅是可以明確定義的時間點，它不耗費時間和資源；作業(yè)通常既消耗資源，又要持續(xù)一定時間?；顒泳W(wǎng)絡(luò)圖用箭頭表示作業(yè)(如刮舊漆、刷新漆、清理等)，用圓圈25活動網(wǎng)絡(luò)圖畫出PERT圖后，系統(tǒng)分析員就可以估算工程進度了，為此需要在PERT上增加一些必要的信息：把每個作業(yè)估計需要時間寫在表示該項作業(yè)的箭頭上方。為每個事件計算兩個統(tǒng)計數(shù)字：最早時刻(EET)和最遲時刻(LET)。這兩個數(shù)字分別寫在表示事件的圓圈的左上角和右下角。持續(xù)時間(機動時間)EETLET事件號活動網(wǎng)絡(luò)圖畫出PERT圖后，系統(tǒng)分析員就可以估算工程進度了，26活動網(wǎng)絡(luò)圖事件的最早時刻是該事件可以發(fā)生的最早時間。通常PERT中第一個事件的EET定義為0，其他事件的EET從左到右按事件發(fā)生順序計算。簡單原則：考慮進入該事件的所有作業(yè)；對每個作業(yè)都計算它的持續(xù)時間與開始事件EET之和；選取上述和數(shù)中最大值作為該事件的EET?；顒泳W(wǎng)絡(luò)圖事件的最早時刻是該事件可以發(fā)生的最早時間。通常PE27102610115348792424363612120000舊木板房刷漆工程的PERT圖事件2只有一個作業(yè)進入，只有當1-2完成才開始，所以EET＝22事件3也只有一個作業(yè)進入，只有當2-3完成才開始，所以EET＝2＋4＝666按此方法，不難沿著PERT圖從左到右順序算出每個事件的EET8121215152123事件4有兩個作業(yè)進入(2-4，3-4)，只有當兩者都完成后事件4才能開始，所以EET=max{2+3,6+0}=610261011534879242436361212000028活動網(wǎng)絡(luò)圖事件的最遲時刻是在不影響工程竣工時間的前提下，該事件最晚可以發(fā)生的時刻。按慣例，PERT中最后一個事件的LET就是它的EET，其他事件的LET從右到左按逆作業(yè)流的方向計算。簡單原則：考慮離開該事件的所有作業(yè)；從每個作業(yè)的結(jié)束時間的LET中減去該作業(yè)的持續(xù)時間；選取上述差數(shù)中最小值作為該事件的LET。活動網(wǎng)絡(luò)圖事件的最遲時刻是在不影響工程竣工時間的前提下，該事292621002610115348794243631210000舊木板房刷漆工程的PERT圖按慣例，事件11的LET與EET相同，都是23266812121515212323逆作業(yè)流方向，接著是計算事件10的LET,離開它的作業(yè)只有10-11，持續(xù)時間為2，而它的LET為23，因此事件10的LET=23-2=2121類似地，事件9的LET=21-1=2020事件8有兩個離開它的作業(yè)8-9和8-10，因此LET=min{20-0,21-6}=1515按此方法，不難沿著PERT圖從右到左的逆序算出每個事件的LET18121166226210026101153487942436312100030關(guān)鍵路徑（CPM，CriticalPathMethod）：從起點到終點，可以有許多條路徑，我們把耗時最長的路徑稱作關(guān)鍵路徑。關(guān)鍵路徑耗時等于整個工程的耗時，因此，要想縮短工程時間，就必須找出關(guān)鍵路徑，并研究如何減少關(guān)鍵路徑的耗時。6100261011534879242436312120000266812121515212323212015181211662關(guān)鍵路徑上事件的EET＝LET關(guān)鍵路徑的事件必須準時發(fā)生，作業(yè)的實際持續(xù)時間不能超過估計持續(xù)時間。否則工程不能按時完成。關(guān)鍵路徑（CPM，CriticalPathMethod）316100261011534879242436312120000266812121515212323212015181211662機動時間：不在關(guān)鍵路徑上的作業(yè)有一定程度的機動余地——實際開始時間可以比預(yù)定時間晚一些，或者實際持續(xù)時間可以比預(yù)定的持續(xù)時間長一些，而不影響整個工程的完成時間。一個作業(yè)可以有的全部機動時間＝(LET)結(jié)束－(EET)開始－持續(xù)時間(1)(3)(11)(4)(3)(6)(6)(5)(5)61002610115348792424363121200032活動網(wǎng)絡(luò)圖在制定進度計劃時仔細考慮和利用PERT圖中的機動時間，往往能夠安排出既節(jié)省資源又不影響最終竣工時間的進度表。從上圖可見，清理前三面墻窗戶的作業(yè)都有相當多的機動時間，即這些作業(yè)可以晚些開始或者持續(xù)時間長一些(少用一些資源)；此外，刮第3、第4面墻上舊漆和給第1面墻刷新漆的作業(yè)也都有機動時間，且這些機動時間之和大于清理前三面墻窗戶需要用的工作時間。因此，有可能僅用10個工人在同樣時間內(nèi)(23小時)完成這項工程?；顒泳W(wǎng)絡(luò)圖在制定進度計劃時仔細考慮和利用PERT圖中的機動時33248101214182016622刮舊漆刷新漆清理時間(小時)工序活動網(wǎng)絡(luò)圖這個方案不僅比前面的方案節(jié)省人力，而且改正了前圖的一個錯誤：因為給第3面墻刷漆的作業(yè)4-6不僅必須在給第1面墻刷完漆之后(2-4作業(yè)結(jié)束)，而且還必須在把第3面墻刮凈之后(2-3作業(yè)和3-4虛作業(yè)結(jié)束)才能開始。全部工程需要23小時，而不是22小時。248101214182016622刮舊漆刷新漆清理時間(小34活動網(wǎng)絡(luò)圖1100222612121021211123235811366466815157121891520242436362120000(0)(0)(1)(0)(3)(4)(0)(11)(0)(6)(5)(3)(5)(0)(0)舊木板房刷漆工程完整PERT圖活動網(wǎng)絡(luò)圖110022261212102121112323535進度管理實踐—MSProjectT11(M8)10T12T9(M6)7T11T5,T7(M7)15T10T3,T6(M4)15T9T4(M5)25T8T1(M1)20T7T1,T2(M3)5T6T2,T4(M2)10T510T4T1(M1)15T315T28T1依賴關(guān)系持續(xù)時間任務(wù)進度管理實踐—MSProjectT11(M8)10T12T36MSProject—活動網(wǎng)絡(luò)圖4/7/058天14/7/0515天4/8/0515天25/08/057天5/9/0510天19/9/0515天11/8/0525天10天20天5天25/7/0515天25/7/0518/7/05開始10天完成T8M5T4T2T3M1M3T7T6M2T5M4M7T10T12M8T11M6T9T1MSProject—活動網(wǎng)絡(luò)圖4/7/058天14/7/037MSProject--甘特圖4/711/718/725/71/88/815/822/829/85/912/919/9T4T1T2M1T7T3M5T8M3M2T6T5M4T9M7T10M6T11M8T12開始完成MSProject--甘特圖4/711/718/725/738人員分配4/711/718/725/71/88/815/822/829/85/912/919/9T4T8T11T12T1T3T9T2T6T10T7T5FredJaneAnneMaryJim人員分配4/711/718/725/71/88/815/8239質(zhì)量管理質(zhì)量是產(chǎn)品的生命線，不論任何產(chǎn)品，質(zhì)量都是極端重要的。軟件產(chǎn)品開發(fā)周期長，需耗費巨大的人力、物力，更必須特別注意保證產(chǎn)品質(zhì)量。質(zhì)量管理質(zhì)量是產(chǎn)品的生命線，不論任何產(chǎn)品，質(zhì)量都是極端重要的40軟件質(zhì)量的定義軟件質(zhì)量就是“軟件與明確的和隱含定義的需求相一致的程度”，即軟件與明確描述的功能和性能需求、文檔中明確描述的開發(fā)標準以及任何專業(yè)開發(fā)的軟件產(chǎn)品都應(yīng)該具有的隱含特征相一致的程度。軟件質(zhì)量的定義軟件質(zhì)量就是“軟件與明確的和隱含定義的需求相一41軟件質(zhì)量的定義上述定義強調(diào)了以下三個重要的方面：軟件需求是進行"質(zhì)量"度量的基礎(chǔ)，不符合需求就是質(zhì)量不高。規(guī)范化的標準定義了一些開發(fā)準則以指導(dǎo)軟件開發(fā)，如果不遵照這些準則，則極有可能導(dǎo)致質(zhì)量不高。往往會有一些隱含的需求沒有明確地提出來，如軟件的可維護性等，忽略了這些隱含需求，軟件的質(zhì)量也難以保證。軟件質(zhì)量是一個多因素的復(fù)雜混合，這些因素隨著不同的應(yīng)用和用戶而變化。軟件質(zhì)量的定義上述定義強調(diào)了以下三個重要的方面：軟件質(zhì)量是一42軟件質(zhì)量模型軟件質(zhì)量與軟件的內(nèi)部特性及其組合有關(guān)。要度量軟件質(zhì)量，就應(yīng)根據(jù)這些內(nèi)部特性（即軟件屬性）建立起軟件度量模型，進而構(gòu)建軟件質(zhì)量度量體系。從管理角度對軟件質(zhì)量進行度量的McCall軟件質(zhì)量模型如下：軟件質(zhì)量模型軟件質(zhì)量與軟件的內(nèi)部特性及其組合有關(guān)。要度量軟件43軟件質(zhì)量模型產(chǎn)品修改產(chǎn)品轉(zhuǎn)移產(chǎn)品運行可理解性可維護性靈活性可測試性可移植性可重用性互運行性輕便性正確性、健壯性、效率、完整性、可用性、風(fēng)險上述模型反映了用戶在使用軟件產(chǎn)品時的三種不同的傾向：產(chǎn)品運行、產(chǎn)品修改和產(chǎn)品轉(zhuǎn)移。軟件質(zhì)量模型產(chǎn)品修改產(chǎn)品轉(zhuǎn)移產(chǎn)品運行可理解性可移植性正確性、44軟件質(zhì)量的屬性正確性 系統(tǒng)滿足規(guī)格說明和用戶目標的程度，在預(yù)定環(huán)境下能正確完成預(yù)期功能的程度。健壯性 在硬件發(fā)生故障、輸入數(shù)據(jù)無效、操作錯誤等意外環(huán)境下，系統(tǒng)能做出適當響應(yīng)的程度。效率 為了完成預(yù)定功能，系統(tǒng)需要的計算資源的多少。完整性 對未經(jīng)授權(quán)的軟件使用請求或數(shù)據(jù)訪問的企圖，系統(tǒng)能夠控制（或禁止）的程度。軟件質(zhì)量的屬性正確性45軟件質(zhì)量的屬性可用性 系統(tǒng)在完成預(yù)定功能時令用戶滿意的程度。風(fēng)險 按預(yù)定的成本和進度開發(fā)系統(tǒng)，并且使得用戶滿意的概率。可理解性 理解和使用軟件的容易程度。可維護性 診斷和改正在運行現(xiàn)場發(fā)現(xiàn)的錯誤所需要的工作量大小。軟件質(zhì)量的屬性可用性46軟件質(zhì)量的屬性適應(yīng)性

修改或改進正在運行的系統(tǒng)需要的工作量大小可測試性

軟件容易測試的程度?？梢浦残?/p>

把軟件從一軟硬件環(huán)境移植到另一配置環(huán)境時，需要的工作量大小。可重用性

在其他應(yīng)用中該軟件可以被使用的程度或范圍。軟件質(zhì)量的屬性適應(yīng)性47軟件質(zhì)量的屬性互運行性把該軟件系統(tǒng)和另一軟件系統(tǒng)結(jié)合起來所需要的工作量大小。輕便性

允許軟件能夠從一臺計算機很容易地傳輸?shù)搅硪慌_需要運行的計算機上的能力。

軟件質(zhì)量的屬性互運行性48軟件質(zhì)量管理 軟件質(zhì)量管理就是確保軟件有較少缺陷，并達到軟件系統(tǒng)既定目標。一個機構(gòu)的質(zhì)量管理者的職責(zé)是確保軟件產(chǎn)品質(zhì)量達到客戶要求。理論上，質(zhì)量管理只包含制定軟件質(zhì)量規(guī)程和軟件開發(fā)標準，以及檢查是否所有的工程人員都遵守了這些規(guī)章和標準。但實際上，質(zhì)量管理內(nèi)容遠不止這些。好的質(zhì)量管理者致力于培養(yǎng)“質(zhì)量文化”，讓每個參與產(chǎn)品開發(fā)的人都有強烈質(zhì)量意識。他們鼓勵團隊對自己的工作質(zhì)量負責(zé)，鼓勵他們探求改善質(zhì)量的途徑和方法，鼓勵團隊每一員對軟件質(zhì)量特征量化的研究。軟件質(zhì)量管理 軟件質(zhì)量管理就是確保軟件有較少缺陷，并達到軟件49軟件質(zhì)量管理活動 軟件質(zhì)量管理有以下三個主要活動組成：1）質(zhì)量保證(QualityAssurance)

建立起機構(gòu)質(zhì)量規(guī)程和標準的整體框架，這是生產(chǎn)高質(zhì)量軟件的保證。2）質(zhì)量規(guī)劃(QualityPlanning)

從這個框架中選擇適當?shù)馁|(zhì)量規(guī)程和標準，進行改寫使之適應(yīng)于特定軟件項目。3）質(zhì)量控制(QualityControl)

定義并設(shè)計軟件過程，確保軟件開發(fā)團隊嚴格遵守項目質(zhì)量規(guī)劃和標準。軟件質(zhì)量管理活動 軟件質(zhì)量管理有以下三個主要活動組成：50軟件質(zhì)量管理活動質(zhì)量管理應(yīng)該與軟件項目管理相分離，這樣質(zhì)量管理就不會屈從于項目預(yù)算和進度。應(yīng)該由一個獨立的團隊專門負責(zé)質(zhì)量管理，并應(yīng)該向項目管理者的上級領(lǐng)導(dǎo)匯報。軟件質(zhì)量管理者不應(yīng)該參與具體的開發(fā)工作，而應(yīng)該負責(zé)整個機構(gòu)的質(zhì)量管理。軟件質(zhì)量管理活動質(zhì)量管理應(yīng)該與軟件項目管理相分離，這樣質(zhì)量管51質(zhì)量管理與軟件開發(fā)D1D2D3D4D5可交付產(chǎn)品質(zhì)量保證質(zhì)量規(guī)劃質(zhì)量控制軟件開發(fā)過程質(zhì)量管理過程質(zhì)量管理與軟件開發(fā)D1D2D3D4D5可交付產(chǎn)品質(zhì)量保證質(zhì)量52軟件質(zhì)量保證QA活動為達到高質(zhì)量軟件提供了一個框架。QA過程包括對軟件開發(fā)過程標準或軟件產(chǎn)品標準的定義和選擇。這些標準應(yīng)該融合在軟件開發(fā)的過程或過程中。軟件質(zhì)量保證QA活動為達到高質(zhì)量軟件提供了一個框架。QA過程53質(zhì)量標準 在質(zhì)量保證過程中要制定兩種類型的標準：產(chǎn)品標準

定義了所有要提供的產(chǎn)品的特征，包括：文檔標準，如生成的需求文檔的結(jié)構(gòu)；文檔編寫標準，如定義對象類時注釋頭的標準寫法；還有編碼標準，它規(guī)定了如何使用某種程序設(shè)計語言。過程標準

這些標準定義了軟件開發(fā)必須遵循的過程，包括描述、設(shè)計、有效性驗證過程的定義，以及對在這些過程中產(chǎn)生的文檔描述。質(zhì)量標準 在質(zhì)量保證過程中要制定兩種類型的標準：54產(chǎn)品標準與過程標準產(chǎn)品標準設(shè)計評審形式需求文檔結(jié)構(gòu)規(guī)程標題結(jié)構(gòu)Java編程規(guī)范項目計劃格式變更請求形式過程標準設(shè)計評審行為提交文檔給CM版本發(fā)放過程項目計劃批準過程變更控制過程測試記錄過程產(chǎn)品標準與過程標準產(chǎn)品標準過程標準55封裝了最成功的經(jīng)驗——避免重犯過去的錯誤。提供了質(zhì)量保證過程的框架——質(zhì)量控制的任務(wù)只要保證這些標準嚴格執(zhí)行就可以了。有助于工作的連貫性——由一個人著手進行的工作別人可以接著做。標準的重要性封裝了最成功的經(jīng)驗——避免重犯過去的錯誤。標準的重要性56質(zhì)量規(guī)劃質(zhì)量規(guī)劃描述希望得到的產(chǎn)品的質(zhì)量要求及其評定辦法，并且定義最重要的質(zhì)量屬性。質(zhì)量規(guī)劃應(yīng)該定義質(zhì)量的評定過程。也應(yīng)該說明采用哪個組織的標準，如果有必要還要定義新的標準。質(zhì)量規(guī)劃質(zhì)量規(guī)劃描述希望得到的產(chǎn)品的質(zhì)量要求及其評定辦法，并57質(zhì)量規(guī)劃產(chǎn)品介紹：說明產(chǎn)品、產(chǎn)品的意向市場及對產(chǎn)品性質(zhì)的預(yù)期。軟件計劃：包括產(chǎn)品確切的發(fā)布日期、產(chǎn)品責(zé)任及產(chǎn)品的銷售和售后服務(wù)計劃。過程描述：產(chǎn)品的開發(fā)和管理中應(yīng)該采用開發(fā)和售后服務(wù)質(zhì)量過程。質(zhì)量目標：包括鑒定和驗證產(chǎn)品的關(guān)鍵質(zhì)量屬性。風(fēng)險和風(fēng)險管理：說明影響產(chǎn)品質(zhì)量的主要風(fēng)險和這些風(fēng)險的應(yīng)對措施。Humphrey的結(jié)構(gòu)框架：質(zhì)量規(guī)劃產(chǎn)品介紹：說明產(chǎn)品、產(chǎn)品的意向市場及對產(chǎn)品性質(zhì)的預(yù)期58質(zhì)量規(guī)劃質(zhì)量規(guī)劃時要考慮各種潛在的軟件質(zhì)量屬性：安全性可理解性可移植性保密性可測試性可使用性可靠性適應(yīng)性復(fù)用性彈性模塊性效率魯棒性復(fù)雜性可學(xué)習(xí)性當然，要對任何系統(tǒng)的所有這些屬性都重點關(guān)注是不可能的，因此質(zhì)量規(guī)劃的一個關(guān)鍵任務(wù)是挑選出關(guān)鍵的質(zhì)量屬性，然后對如何達到這些質(zhì)量屬性做出規(guī)劃。質(zhì)量規(guī)劃質(zhì)量規(guī)劃時要考慮各種潛在的軟件質(zhì)量屬性：安全性可理解59質(zhì)量控制質(zhì)量控制就是監(jiān)督檢查整個軟件開發(fā)過程，以確保質(zhì)量保證規(guī)程和標準被嚴格執(zhí)行。有兩種質(zhì)量控制的方法：質(zhì)量評審：一組人對軟件、文檔編制及軟件制作過程進行評審。自動化的軟件評估：軟件和文檔生成后，經(jīng)過一定的程序進行處理，并與用于具體項目的標準相對照。質(zhì)量控制質(zhì)量控制就是監(jiān)督檢查整個軟件開發(fā)過程，以確保質(zhì)量保證60軟件成本估算成本估算是可行性分析的重要依據(jù)，也是軟件管理的重要內(nèi)容，直接影響到軟件開發(fā)的風(fēng)險。軟件開發(fā)成本主要是指軟件開發(fā)過程中所花費的工作量及相應(yīng)的代價，即主要是人的勞動的消耗。軟件產(chǎn)品不存在重復(fù)制造過程，它的開發(fā)成本是以一次性開發(fā)過程所花費的代價來計算的。因此軟件成本估算，應(yīng)以軟件計劃、需求分析、設(shè)計、編碼到測試的軟件開發(fā)全過程所花費的代價為依據(jù)。*成本估算與成本估計是軟件管理的核心任務(wù)之一。軟件成本估算成本估算是可行性分析的重要依據(jù)，也是軟件管理的重61軟件成本估算由于軟件成本涉及較多變量，因而難以對其作出準確的估算。我們需要使用多種不同的方法對軟件成本進行交叉估算，才有可能得到軟件成本的較精確的估算結(jié)果。對于大型項目，由于其項目的復(fù)雜度，必須建立相應(yīng)的估算模型，按照一定的方法、技術(shù)來進行估算。軟件成本估算由于軟件成本涉及較多變量，因而難以對其作出準確的62軟件成本估算項目的規(guī)模項目的難度項目的時間限制資源根據(jù)需求分析后確定的功能模塊的數(shù)量，或者用例的數(shù)量確定根據(jù)現(xiàn)有經(jīng)驗、技術(shù)水平確定根據(jù)客戶的要求及現(xiàn)有資源確定確定軟件成本估算項目的規(guī)模項目的難度項目的時間限制資源根據(jù)需求分63軟件規(guī)模估算代碼行技術(shù)功能點技術(shù)軟件規(guī)模估算代碼行技術(shù)64代碼行技術(shù)代碼行技術(shù)是比較簡單的定量估算軟件規(guī)模的方法。這種方法依據(jù)以往開發(fā)類似產(chǎn)品的經(jīng)驗和歷史數(shù)據(jù)，估算實現(xiàn)一個功能所需要的源程序行數(shù)。當有以往開發(fā)類似產(chǎn)品的歷史數(shù)據(jù)可供參考時，這種方法估算出的數(shù)值還是比較準確的。代碼行技術(shù)代碼行技術(shù)是比較簡單的定量估算軟件規(guī)模的方法。當有65代碼行技術(shù)為使得對軟件規(guī)模估計值更接近實際值，可以由多名有經(jīng)驗的軟件工程師分別作出估計。每個人都估計軟件的最小規(guī)模(a)、最大規(guī)模(b)和最可能規(guī)模(m)，分別算出三者的平均值a，b，m，再用下式計算軟件規(guī)模估算值：在使用代碼行技術(shù)估算軟件規(guī)模時，若軟件較小時常用的單位是代碼行數(shù)（LOC）；若軟件較大時常用的單位是千行代碼數(shù)（KLOC）。常使用的單位有：SLOC(singlelineofcode)、KLOC(thousandlinesofcode)、LLOC(logicallineofcode)、PLOC(physicallineofcode)、NCLOC(non-commentedlineofcode)、DSI(deliveredsourceinstruction交付源指令數(shù)

)。代碼行技術(shù)為使得對軟件規(guī)模估計值更接近實際值，可以由多名有經(jīng)66代碼行技術(shù)代碼行技術(shù)的優(yōu)點：代碼是所有軟件項目開發(fā)都包含的“產(chǎn)品”，而且代碼行數(shù)很容易計算。代碼行技術(shù)的缺點：源程序僅是軟件配置的一個成分，用它的規(guī)模代表整個軟件規(guī)模不太合理；用不同語言實現(xiàn)同一個軟件所需的代碼行數(shù)并不相同，即它依賴于所使用的編程語言；不適合于非過程語言。代碼行技術(shù)代碼行技術(shù)的優(yōu)點：67功能點技術(shù)是為克服代碼行技術(shù)缺點提出的；它涉及多種因素的度量方法；功能點技術(shù)根據(jù)軟件的基本功能來定義，所以在系統(tǒng)設(shè)計初期就能夠估算出軟件項目的規(guī)模。功能點技術(shù)是為克服代碼行技術(shù)缺點提出的；68信息域特性產(chǎn)品信息域的5個特性：輸入項數(shù)(Inp):用戶向軟件輸入的項數(shù)，這些輸入給軟件提供了面向應(yīng)用的數(shù)據(jù)。輸出項數(shù)(Out):軟件向用戶輸出的項數(shù)，它們向用戶提供面向應(yīng)用的信息。查詢數(shù)(Inq):查詢即一次聯(lián)機輸入，它導(dǎo)致軟件以聯(lián)機輸出方式產(chǎn)生某種即時響應(yīng)。主文件數(shù)(Maf):邏輯主文件（數(shù)據(jù)的一個邏輯集合）的數(shù)目。外部接口數(shù)(Inf): 機器可讀的全部接口的數(shù)量。信息域特性產(chǎn)品信息域的5個特性：69功能點技術(shù)基本原理使用5個信息域的“加權(quán)和”CT與14個技術(shù)因素的“復(fù)雜性調(diào)節(jié)值”Fi來計算功能點FP:功能點技術(shù)基本原理使用5個信息域的“加權(quán)和”CT與14個技術(shù)70估算功能點的步驟1、計算未調(diào)整的功能點數(shù)CT首先把信息域的每個特性都分類為簡單級、平均級或復(fù)雜級，根據(jù)等級按下表分配功能點數(shù)：1075接口系數(shù)a515107文件系數(shù)a4643查詢系數(shù)a3754輸出系數(shù)a2543輸入系數(shù)a1復(fù)雜平均簡單特性系數(shù)復(fù)雜級別然后用下式計算未調(diào)整的功能點數(shù)CT：CT=a1×Inp＋a2×Out＋a3×Inq＋a4×Maf＋a5×Inf估算功能點的步驟1、計算未調(diào)整的功能點數(shù)CT1075接口系數(shù)71估算功能點的步驟2、計算技術(shù)復(fù)雜因子TCF軟件復(fù)雜度的估算基于14個問題，逐一對各問題做出復(fù)雜度估計Fi，其取值范圍是0-5。估算功能點的步驟2、計算技術(shù)復(fù)雜因子TCF72估算功能點的步驟“沒有影響”取值0“偶然的”取值1“適中的”取值2“普通的”取值3“重要的”取值4“極重要的”取值5系統(tǒng)需要可靠的備份和復(fù)原嗎？需要數(shù)據(jù)通信嗎？有分布處理功能嗎？性能很關(guān)鍵嗎？系統(tǒng)是否在一個已有的、很實用的操作環(huán)境中運行？系統(tǒng)需要聯(lián)機入口嗎？聯(lián)機入口需要在多屏幕或多操作之間切換以完成輸入？系統(tǒng)聯(lián)機需要更新主文件嗎？系統(tǒng)的輸入、輸出、文件或查詢很復(fù)雜嗎？系統(tǒng)內(nèi)部處理復(fù)雜嗎？代碼需要被設(shè)計成可復(fù)用的嗎？設(shè)計中要包括轉(zhuǎn)換及安裝嗎？系統(tǒng)的設(shè)計支持不同組織的多次安裝嗎？系統(tǒng)的設(shè)計有利于用戶修改和使用嗎？估算功能點的步驟“沒有影響”取值0系統(tǒng)需要可靠的備份和復(fù)原73功能點技術(shù)功能點技術(shù)沒有涉及系統(tǒng)本身的算法復(fù)雜性。因此，它僅僅適合與算法比較簡單的事務(wù)處理系統(tǒng)軟件的規(guī)模度量；對算法較復(fù)雜的大型軟件系統(tǒng)并不適應(yīng)。功能點技術(shù)功能點技術(shù)沒有涉及系統(tǒng)本身的算法復(fù)雜性。74工作量估算軟件估算模型使用由經(jīng)驗導(dǎo)出的公式來預(yù)測軟件開發(fā)工作量，工作量是軟件規(guī)模(LOC或FP)的函數(shù)，工作量的單位通常是人月（pm）。靜態(tài)單變量模型動態(tài)多變量模型COCOMO2模型支持大多數(shù)估算模型的經(jīng)驗數(shù)據(jù)，都是從有限個項目的樣本集中總結(jié)出來的，因此，沒有一個估算模型可以使用于所有類型的軟件和開發(fā)環(huán)境。工作量估算軟件估算模型使用由經(jīng)驗導(dǎo)出的公式來預(yù)測軟件開發(fā)工作75靜態(tài)單變量模型靜態(tài)單變量的總體結(jié)構(gòu)形式如下：

其中，A、B、C是由經(jīng)驗數(shù)據(jù)導(dǎo)出的常數(shù)，E是以人月為單位的工作量，ev是估算變量（KLOC或FP）。下面給出典型的靜態(tài)單變量模型：面向KLOC的估算模型面向FP的估算模型靜態(tài)單變量模型靜態(tài)單變量的總體結(jié)構(gòu)形式如下：下面給出典型的靜76面向KLOC的估算模型Walston_Felix(IBM模型)Bailey_Basili模型 Boehm簡單模型 Doty模型(KLOC>9時適合) 面向KLOC的估算模型Walston_Felix(IBM模77面向FP的估算模型Albrecht&Gaffney模型Maston，Barnett和Mellichamp模型面向FP的估算模型Albrecht&Gaffney模型78靜態(tài)單變量的估算模型從上面可以看出，對于相同的KLOC或FP，用不同的模型估算的結(jié)果各不相同。主要原因： 這些模型都僅僅依據(jù)若干領(lǐng)域中有限個項目的經(jīng)驗數(shù)據(jù)推導(dǎo)出來的，適應(yīng)范圍有限。因此，必須根據(jù)當前項目特點選擇適應(yīng)的估算模型，并依據(jù)需要對相應(yīng)模型作出調(diào)整。靜態(tài)單變量的估算模型從上面可以看出，對于相同的KLOC或FP79動態(tài)多變量模型動態(tài)多變量模型，即軟件方程式，它是根據(jù)4000多個當代軟件項目中收集的生產(chǎn)率數(shù)據(jù)推導(dǎo)出來的。該模型把工作量看作是軟件規(guī)模和開發(fā)時間的函數(shù)，其形式如下：動態(tài)多變量模型動態(tài)多變量模型，即軟件方程式，它是根據(jù)400080動態(tài)多變量模型其中：E是以人月或人年為單位的工作量；t是以月或年為單位的項目持續(xù)時間；B是特殊因子，它隨著對測試、質(zhì)量保證、文檔及管理技術(shù)的需求的增加而緩慢增加。對于較小程序(KLOC=5～15)，B=0.16；而對于超過70KLOC的程序，B=0.39；P是生產(chǎn)率參數(shù)，它反映下屬因素對工作量的影響：總體過程成熟度及管理水平；使用良好的軟件工程實踐的程度；使用程序設(shè)計語言的級別；軟件環(huán)境狀態(tài)；軟件項目組的經(jīng)驗和技術(shù)；應(yīng)用系統(tǒng)的復(fù)雜性等。動態(tài)多變量模型其中：81動態(tài)多變量模型P的取值：

開發(fā)實時嵌入式軟件時，P的典型值為2000； 開發(fā)電信系統(tǒng)和系統(tǒng)軟件時，P=10000； 對于商業(yè)應(yīng)用軟件來說，P=28000。從上式可以看出，開發(fā)同一個軟件產(chǎn)品（即LOC固定）的時候，如果把項目持續(xù)時間延長，則可降低完成項目所需要功能的工作量。動態(tài)多變量模型P的取值：82COCOMO模型COCOMO模型--ConstructiveCostModel它是Boehm于1981年在靜態(tài)單變量模型基礎(chǔ)上提出的“構(gòu)造性成本模型”。1997年Boehm等人提出修訂版CoCoMo2模型。COCOMO模型COCOMO模型--Constructive83COCOMO模型依據(jù)系統(tǒng)規(guī)模和考慮因素的多少，由三種類型的COCOMO模型：基本COCOMO模型中間COCOMO模型詳細COCOMO模型COCOMO模型依據(jù)系統(tǒng)規(guī)模和考慮因素的多少，由三種類型的C84獨立型（Organic）較簡單，對產(chǎn)品目標理解充分，經(jīng)驗豐富，對軟件開發(fā)環(huán)境熟悉，由小團隊開發(fā)。大多數(shù)應(yīng)用軟件及老的操作系統(tǒng)、編譯系統(tǒng)屬此類。半獨立型（Semidetached)項目較復(fù)雜，團隊成員對系統(tǒng)可能有些經(jīng)驗。如新操作系統(tǒng)，大型數(shù)據(jù)庫，生產(chǎn)控制等軟件屬此類。嵌入型（Embadded)項目復(fù)雜，軟件只是復(fù)雜系統(tǒng)的一部分，軟件、硬件、規(guī)則和操作規(guī)程關(guān)系緊密，對接口、數(shù)據(jù)結(jié)構(gòu)，算法要求較高。如大型復(fù)雜的事務(wù)處理系統(tǒng)，大型、超大型的操作系統(tǒng)，軍事指揮系統(tǒng)，航天控制系統(tǒng)等。軟件復(fù)雜度的三種類型獨立型（Organic）軟件復(fù)雜度的三種類型85基本COCOMO模型基本COCOMO模型是一個靜態(tài)單變量模型，它把軟件系統(tǒng)所需要的成本看作是程序大小單一變量(KLOC)的(經(jīng)驗)函數(shù)，用于系統(tǒng)級的粗略估算。實時處理、控制程序、操作系統(tǒng)0.322.51.203.6嵌入型各類實用程序、編譯程序等0.352.51.123.0半獨立型各類應(yīng)用軟件0.382.51.052.4獨立型適應(yīng)范圍dcaC軟件類型工作量E=C×KLOCa(人月|人年)開發(fā)時間TDEV=cEd(月|年)基本COCOMO模型基本COCOMO模型是一個靜態(tài)單變量模型86中間COCOMO模型中間COCOMO模型是一個靜態(tài)多變量模型，它把軟件系統(tǒng)所需要的成本看作是程序大小和一系列成本驅(qū)動屬性的函數(shù)。估算方程：其中：E是開發(fā)工作量； C是模型系數(shù)； KLOC是估計代碼行數(shù)； a是模型指數(shù)； fi是成本因素1.202.8嵌入型1.123.0半獨立型1.053.2獨立型aC軟件類型中間COCOMO模型中間COCOMO模型是一個靜態(tài)多變量模型87每個成本因素Fi根據(jù)它的重要程度和影響大小賦予一定的值，可把這些成本因素劃分為(共15個)：產(chǎn)品因素計算機因素人員因素項目因素。中間COCOMO模型EAF＝∏Fii=115工作量調(diào)節(jié)因子每個成本因素Fi根據(jù)它的重要程度和影響大小賦予一定的值，可把881.101.041.001.081.23開發(fā)進度的要求（SCED)0.830.911.001.101.24軟件工具的使用(TOOL)0.820.911.001.101.24程序設(shè)計實踐(MODP)0.951.001.071.14程序設(shè)計語言的經(jīng)驗(LEXP)0.901.001.101.21開發(fā)環(huán)境的經(jīng)驗(VEXP)0.700.861.001.171.42程序員水平(PCAP)0.820.911.001.131.29應(yīng)用經(jīng)驗(AEXP)0.710.861.001.191.46系統(tǒng)分析員的能力(ACAP)1.151.071.000.87開發(fā)環(huán)境的響應(yīng)速度(TURN)1.301.151.000.87軟件開發(fā)環(huán)境的變化(VIRT)1.561.211.061.00內(nèi)存約束(STOR)1.661.301.111.00執(zhí)行時間約束(TIME)1.651.301.151.000.850.70軟件復(fù)雜性(CPLX)1.161.081.000.94數(shù)據(jù)庫規(guī)模(DATA)1.401.151.000.880.75軟件可靠性(RELY)極高很高高正常低很低級別成本因素1.101.041.001.081.23開發(fā)進度的要求（SC89詳細COCOMO模型詳細COCOMO模型除了包括中級COCOMO模型中所考慮的因素以外，并對工作量調(diào)節(jié)因子在軟件過程中每個步驟的影響作出詳細評估。該模型則將軟件分為系統(tǒng)、子系統(tǒng)、模塊三個層次。詳細COCOMO模型詳細COCOMO模型除了包括中級COCO90COCOMO模型基本CoCoMo模型用于系統(tǒng)開發(fā)的初期，估算整個系統(tǒng)(包括維護)的工作量和軟件開發(fā)所需要的時間。中間CoCoMo模型用于估算各個子系統(tǒng)的工作量和開發(fā)時間。詳細CoCoMo模型用于估算獨立的軟部件。COCOMO模型基本CoCoMo模型用于系統(tǒng)開發(fā)的初期，估算91人員管理人員是軟件機構(gòu)中最重要的資產(chǎn)，他們代表著智力資本。合理地調(diào)配人員是成功完成軟件項目的切實保證。因此軟件項目管理的關(guān)鍵是人員管理。項目管理者必須利用其團隊成員，用可能最有效的方式解決技術(shù)和非技術(shù)上的問題。軟件機構(gòu)要尊重員工，管理者要激勵員工。人員管理不當是項目成敗的最重要的原因之一！人員管理人員是軟件機構(gòu)中最重要的資產(chǎn)，他們代表著智力資本。人92人員組織軟件項目成功的關(guān)鍵是能夠?qū)⒏咚刭|(zhì)的軟件開發(fā)人員合理地組織起來，使他們有效地分工協(xié)作，共同完成開發(fā)工作。經(jīng)驗表明，人員組織的好壞決定著生產(chǎn)率的高低和產(chǎn)品質(zhì)量的好壞。人員組織軟件項目成功的關(guān)鍵是能夠?qū)⒏咚刭|(zhì)的軟件開發(fā)人員合理地93項目組的組織原則軟件開發(fā)小組的規(guī)模不宜太大，人數(shù)不能太多，一般3-5人左右為宜。切忌在開發(fā)過程中增加人員，這將使人員之間的聯(lián)系增多，造成通信成本的增加而導(dǎo)致效率降低。項目組的組織原則軟件開發(fā)小組的規(guī)模不宜太大，人數(shù)不能太多，一94項目組的組織原則例：設(shè)一開發(fā)小組有4個軟件工程師，開發(fā)效率為5000行/年，共有6條通信路徑，每條路徑降低生產(chǎn)率250行/年，則小組生產(chǎn)率為：5000×4－250×6＝18500（行/年）為了加快進度，新增加2人，每人效率為840行/年，通信路徑增加到15條，此時的小組生產(chǎn)率為：5000×4

＋840×2－250×15＝17930（行/年）即新增加人，并未提高生產(chǎn)率。項目組的組織原則例：95Brooks定律向一個進度已經(jīng)落后的項目增派開發(fā)人員，可能使項目完成得更晚。人與月是不能互換的！開發(fā)人員以算術(shù)級數(shù)增加，人員之間交換意見的路徑數(shù)將以幾何級數(shù)增加。Brooks定律向一個進度已經(jīng)落后的項目增派開發(fā)人員，可能使96項目組的組織方式軟件項目組的組織方式很多，如民主制程序員組、主程序員組、現(xiàn)代程序員組等。具體項目組組織方式的選擇，取決于所承擔(dān)的項目特點、以往組織經(jīng)驗及管理者的看法和喜好！項目組的組織方式軟件項目組的組織方式很多，如民主制程序員組、97民主制程序員組小組成員完全平等，享有充分民主，通過協(xié)商做出決策。小組成員之間的通訊是平行的，如果小組有n個成員，則可能的通訊信道為n(n-1)/2條。民主制程序員組通常采用非正式的組織方式，雖然名義上有一個組長，但其與組內(nèi)其它成員完成同樣的任務(wù)。由小組全體成員討論協(xié)商決定應(yīng)該完成的工作，并依據(jù)各成員能力和經(jīng)驗分配適當?shù)娜蝿?wù)。民主制程序員組小組成員完全平等，享有充分民主，通過協(xié)商做出決98民主制程序員組優(yōu)點：組員對發(fā)現(xiàn)程序錯誤持積極的態(tài)度，這種態(tài)度有助于更快地發(fā)現(xiàn)錯誤，從而導(dǎo)致高質(zhì)量的代碼；組員享有充分民主，小組有高度凝聚力，組內(nèi)學(xué)習(xí)氣氛濃厚，有利于攻克技術(shù)難關(guān)。民主制程序員組優(yōu)點：99民主制程序員組如果組內(nèi)多數(shù)成員是經(jīng)驗豐富、技術(shù)熟練的程序員，采用該組織方式是非常有效的。但是，在組內(nèi)多數(shù)成員技術(shù)水平不高或缺乏經(jīng)驗情況下采用該組織方式，將會因為沒有明確的權(quán)威指導(dǎo)項目進展，小組成員間缺乏必要的協(xié)調(diào)，而導(dǎo)致項目失敗。適合于研制周期長、難度大的項目。日本大多數(shù)軟件開發(fā)公司都采用這種形式。民主制程序員組如果組內(nèi)多數(shù)成員是經(jīng)驗豐富、技術(shù)熟練的程序員，100主程序員組項目開發(fā)普遍存在以下事實：軟件開發(fā)人員多數(shù)比較缺乏經(jīng)驗；程序設(shè)計過程有許多事務(wù)性的工作；多渠道通訊很浪費時間，降低程序員的生產(chǎn)率。IBM在20世紀70年代初期開始使用主程序員組的組織方式。主程序員組項目開發(fā)普遍存在以下事實：101編程秘書負責(zé)完成與項目有關(guān)的全部事務(wù)性工作，如，維護項目資料庫和項目文檔，編譯、連接、執(zhí)行源程序和測試用例。主程序員既是成功的管理人員，又是經(jīng)驗豐富、技術(shù)好、能力強的高級程序員，負責(zé)體系結(jié)構(gòu)設(shè)計和關(guān)鍵部分的詳細設(shè)計，并且負責(zé)指導(dǎo)其他程序員完成詳細設(shè)計和編碼工作主程序員組主程序員編程秘書后備程序員程序員程序員程序員后備程序員也應(yīng)該技術(shù)熟練而且富于經(jīng)驗，他協(xié)助主程序員工作并且在必要時(主程序員生病、出差或跳槽)接替主程序員的工作。所以后備程序員必須和主程序一樣優(yōu)秀，一樣深入了解項目。編程秘書負責(zé)完成與項目有關(guān)的全部事務(wù)性工作，如，維護項目資料102主程序員組主程序員組使用經(jīng)驗豐富、技術(shù)好、能力強的程序員作為主程序員。同時，利用人和計算機在事務(wù)性工作方面給主程序員提供充分支持，而且保證所有通訊都通過一兩個人進行。這種組織方式類似于外科手術(shù)小組的組織：主刀大夫?qū)κ中g(shù)全面負責(zé)，并且完成訂制手術(shù)方案、動手術(shù)等關(guān)鍵工作，同時麻醉師、護士等技術(shù)熟練的專門工作人員協(xié)助配合主刀大夫工作，此外，必要時還要聘請領(lǐng)域?qū)＜矣枰詤f(xié)助。主程序員組主程序員組使用經(jīng)驗豐富、技術(shù)好、能力強的程序員作為103主程序員組的重要特征專業(yè)化 該組每名成員僅完成他們受過專業(yè)訓(xùn)練的那些工作。層次性 主程序員負責(zé)指揮每名成員工作，對軟件項目全面負責(zé)。主程序員組的重要特征專業(yè)化104主程序員組的不足雖然主程序員組有很多優(yōu)點，但是，我們還應(yīng)看到這種組織方式固有的不切實際的地方：主程序員既是高級程序員又是優(yōu)秀管理者，但現(xiàn)實中這種人才很難見到。后備程序員更難找。人們希望后備程序員像主程序員一樣優(yōu)秀，但他們必須坐在“替補席”上，拿著較低的工資等待接替主程序員。編程秘書也很難找。專業(yè)的軟件技術(shù)人員一般都厭煩日常的事務(wù)性工作。主程序員組的不足雖然主程序員組有很多優(yōu)點，但是，我們還應(yīng)看到105現(xiàn)代程序員組使用主程序員組時，主程序員對每行代碼質(zhì)量負責(zé)，因此，他必須參與所有代碼審查工作。他往往會把發(fā)現(xiàn)程序錯誤與小組成員業(yè)績聯(lián)系起來，造成小組成員不愿意發(fā)現(xiàn)錯誤的心理。解決辦法是：取消主程序員的行政管理工作。這樣既解決了問題，又使尋找主程序員的人選不再那么困難。行政組長技術(shù)組長程序員程序員程序員技術(shù)管理非技術(shù)管理圖例：現(xiàn)代程序員組使用主程序員組時，主程序員對每行代碼質(zhì)量負責(zé)，因106現(xiàn)代程序員組由于項目組人員不宜過多，當軟件規(guī)模較大時，應(yīng)該把程序員劃分成若干小組，宜采用下圖所示的組織結(jié)構(gòu)：程序員程序員程序員組長程序員程序員程序員組長程序員程序員組長項目經(jīng)理技術(shù)管理圖例：現(xiàn)代程序員組由于項目組人員不宜過多，當軟件規(guī)模較大時，應(yīng)該把107現(xiàn)代程序員組為了更好的把主程序員組和民主程序員組的優(yōu)點結(jié)合其來，在合適的時候才用分散決定的方法，即集中指導(dǎo)下的發(fā)揚民主：程序員程序員程序員組長程序員程序員程序員組長程序員程序員組長項目經(jīng)理技術(shù)管理圖例：現(xiàn)代程序員組為了更好的把主程序員組和民主程序員組的優(yōu)點結(jié)合其108軟件配置管理任何軟件開發(fā)都是迭代過程，因此在軟件開發(fā)過程中，變化既是必要的，又是不可避免的。同時，變化也很容易失去控制。如果不能適當?shù)目刂乒芾磉@些變化，勢必導(dǎo)致混亂并產(chǎn)生嚴重的錯誤！軟件配置管理任何軟件開發(fā)都是迭代過程，因此在軟件開發(fā)過程中109軟件配置管理目標：使變化更準確且容易被適應(yīng)，在必須變化時減少所需要花費的工作量。軟件配置管理是在軟件項目啟動時就開始，并且一直持續(xù)到軟件軟件退役才終止的一組追蹤和控制軟件變動的保護性活動。軟件配置管理（SCM），是在軟件整個生命周期內(nèi)管理變化的一組活動。是對工作成果的一種有效保護。軟件配置管理目標：使變化更準確且容易被適應(yīng)，在必須變化時減110軟件配置上述這些項組成了軟件過程中產(chǎn)生的全部信息，我們把他們統(tǒng)稱為軟件配置，其中每一項即一個軟件配置項（SoftwareConfigurationItem，簡稱SCI）。SCI是納入配置管理范疇的工作成果。SCI是配置管理的基本單位。軟件開發(fā)過程的工作成果：計算機程序（源代碼和可執(zhí)行程序）；描述計算機程序的文檔（供技術(shù)人員或用戶使用）；數(shù)據(jù)（包括程序內(nèi)部和外部定義的數(shù)據(jù)）。軟件配置上述這些項組成了軟件過程中產(chǎn)生的全部信息，我們把他們111軟件配置項SCI的主要屬性：名稱、標識符、狀態(tài)、版本、作者、日期等。SCI的狀態(tài)有：草稿(Draft)、正式發(fā)布(Released)和正在修改(Changing)。正式發(fā)布正在修改評審或?qū)徟莞逋ㄟ^否決自由修改變更控制SCI狀態(tài)變遷圖軟件配置項SCI的主要屬性：名稱、標識符、狀態(tài)、版本、作者、112基線(Baseline)IEEE把基線定義為： “已經(jīng)通過正式復(fù)審和批準的某規(guī)約或產(chǎn)品，它因此可以作為進一步開發(fā)的基礎(chǔ)，并且只能遵循正式的變化控制過程得到改變”簡而言之，基線是由通過正式評審的一組軟件配置項組成。在軟件配置項變成基線之前，可以迅速而非正式的修改它。一旦建立了基線以后，基線中的配置項就被“凍結(jié)”了，不能再被任何人隨意修改?；€的主要屬性有名稱、標識符、版本、日期等。通常將交付給客戶的基線稱一個“Release”，為內(nèi)部開發(fā)用的基線則稱為一個“Build”基線(Baseline)IEEE把基線定義為：113計劃分析設(shè)計編碼測試計劃計劃基線需求規(guī)格說明需求基線設(shè)計基線編碼基線測試基線配置基線設(shè)計方案程序清單測試報告基線是軟件開發(fā)的里程碑基線(Baseline)計劃分析設(shè)計編碼測試計劃計劃需求規(guī)格說明需求設(shè)計編碼測試配置114軟件配置管理活動軟件配置管理是軟件質(zhì)量保證的重要一環(huán)，它包含主要如下任務(wù)：配置項標識變動控制版本控制配置審計配置狀態(tài)報告軟件配置管理活動軟件配置管理是軟件質(zhì)量保證的重要一環(huán)，它包115軟件配置管理流程配置庫操作配置管理計劃變動管理版本控制配置審計軟件配置管理流程配置庫操作配置管理計劃變動管理版本控制配116配置管理計劃……開發(fā)人員CCB負責(zé)人配置管理員職責(zé)描述人員角色1、人員與職責(zé)……備份設(shè)備計算機軟件工具描述資源名稱2、軟件硬件資源源代碼測試文檔設(shè)計文檔需求文檔預(yù)計正式發(fā)布時間標識符主要配置項3、配置項計劃配置管理計劃……開發(fā)人員CCB負責(zé)人配置管理員職責(zé)描117配置管理計劃4、基線計劃預(yù)計建立時間基線包含的配置項基線名稱5、配置庫備份計劃備份內(nèi)容、目的的、方式等備份人時間、頻度6、版本控制規(guī)劃提示：配置管理員簡述本項目的版本控制規(guī)則。7、變更控制規(guī)劃提示：配置管理員簡述本項目的變更控制規(guī)則。8、審批提示：CCB負責(zé)人（或項目經(jīng)理）審批本計劃。注：CCB為配置控制委員會配置管理計劃4、基線計劃預(yù)計建立時間基線包含的配置項基線118配置項標識目標： 明確項目生存周期內(nèi)所要產(chǎn)生的文檔、程序以及確定文檔、程序的名稱和命名規(guī)則。內(nèi)容單獨命名每個配置項，然后采用面向?qū)ο蠓椒ò阉R別的配置項組織起來。每個配置項都擁有一組能唯一標識它的特征：名字、描述、資源列表和“實現(xiàn)”。配置項標識目標：119變動控制變動控制的目的是防止SCI被隨意修改而導(dǎo)致混亂。變動控制，就是在生存期中對SCI的變動建立評審及核準的機制。為提高效率，對于處于“草稿”狀態(tài)的SCI，不必進行變更控制，因為草稿本來就要不斷地修改。當SCI處于“正式發(fā)布”狀態(tài)，或該SCI已經(jīng)成為某個基線的一部分，若要修改，必須按照變更控制規(guī)則執(zhí)行。當變更被核準后，就把軟件移交給開發(fā)或維護團隊，以實現(xiàn)變更。當軟件變更時，每個組件的變更記錄都應(yīng)該維護，這稱為：組件的導(dǎo)出歷史。變動控制變動控制的目的是防止SCI被隨意修改而導(dǎo)致混亂。120組件頭信息//BANKSECproject(IST6087)////BANKSEC-TOOLS/AUTH/RBAC/USER_ROLE////Object:currentRole//Author:N.Perwaiz//Creationdate:10thNovember2002////@LancasterUniversity2002////Modificationhistory//VersionMofifierDateChangeReason//1.0J.Jones1/12/2002AddheaderSubmittedtoCM//1.1N.Perwaiz9/4/2003NewFieldChangereq.R07/02組件頭信息//BANKSECproject(IST121版本控制版本控制的目的是按照一定的規(guī)則保存SCI的所有版本，避免發(fā)生版本丟失或混淆等現(xiàn)象，并且可以快速準確地查找到SCI的任何版本。版本控制版本控制的目的是按照一定的規(guī)則保存SCI的所有版本，122版本標識一個大型系統(tǒng)內(nèi)有數(shù)以百計的軟件組件，其中每種組件都可能有許多不同的版本。版本標識過程必須定義一種明確標識軟件組件版本的方式。簡單的版本編號方式是使用線性導(dǎo)出：V1,V1.1,V1.2,V2.1,V2.2等。實際導(dǎo)出結(jié)構(gòu)是樹型或網(wǎng)絡(luò)型，而不是順序型的。版本標識一個大型系統(tǒng)內(nèi)有數(shù)以百計的軟件組件，其中每種組件都可123版本導(dǎo)出結(jié)構(gòu)版本導(dǎo)出結(jié)構(gòu)124版本導(dǎo)出規(guī)則SCI版本號與SCI狀態(tài)緊密相關(guān)：處于“草稿”狀態(tài)的SCI版本號格式為：0.YZYZ數(shù)字范圍為01～99；隨著草稿的不斷完善，“YZ”值應(yīng)遞增，初值和增幅由規(guī)則定。處于“正式發(fā)布”狀態(tài)的SCI版本號格式為：X.YX為主版本號，取值1～9。Y為次版本號，取值1～9；SCI第一次“正式發(fā)布”時，版本號為1.0；如果SCI版本升級幅度較小，一般只增加Y值，X值保持不變，只有SCI版本升級幅度較大，才允許增加X值。處于“正在修改”狀態(tài)的SCI版本號格式為：X.YZSCI正在修改時，一般只增大Z值，X.Y值保持不變；當SCI修改完畢，狀態(tài)重新成為“正式發(fā)布”時，將Z值設(shè)為0，增加X.Y值。參見規(guī)則2。版本導(dǎo)出規(guī)則SCI版本號與SCI狀態(tài)緊密相關(guān)：125發(fā)布版本系統(tǒng)的發(fā)布版本是分發(fā)給客戶的系統(tǒng)版本。系統(tǒng)的發(fā)布版本不僅僅是系統(tǒng)的可執(zhí)行代碼，還包括：配置文件數(shù)據(jù)文件安裝程序電子和書面文檔包裝和相關(guān)的宣傳發(fā)布管理者不能想當然認為客戶總是想安裝新的系統(tǒng)版本。因此系統(tǒng)的新版本不能依賴于以前的版本。發(fā)布版本系統(tǒng)的發(fā)布版本是分發(fā)給客戶的系統(tǒng)版本。126發(fā)布版本我們來看一個例子，考慮以下情況：系統(tǒng)的發(fā)布版本1發(fā)布并投入使用；發(fā)布版本2隨后發(fā)布。由于發(fā)布版本2需要安裝新的數(shù)據(jù)文件，而有些客戶不需要發(fā)布版本2所提供的功能，而仍使用發(fā)布版本1；發(fā)布版本3需要發(fā)布版本2中的數(shù)據(jù)文件，沒有新的數(shù)據(jù)文件。發(fā)布人員不能認為發(fā)布版本3所需要的文件已經(jīng)安裝在所在地點。有些地點可能從發(fā)布版本1直接到發(fā)布版本3，跳過了發(fā)布版本2。有些地方則可能已經(jīng)根據(jù)具體情況對發(fā)布版本2有關(guān)的數(shù)據(jù)文件做了修改。因此數(shù)據(jù)文件必須隨同系統(tǒng)的發(fā)布版本3一起發(fā)布和安裝。發(fā)布版本我們來看一個例子，考慮以下情況：發(fā)布人員不能認為發(fā)布127配置審計配置審計主要目的是要保證基線在技術(shù)上、管理上的完整性，保證對SCI的變動是服從需求規(guī)定的。配置審計工作是變動控制委員會批準SCI的先決條件。在SLC間，不斷進行配置審計。配置審計配置審計主要目的是要保證基線在技術(shù)上、管理上的完整性128配置狀態(tài)報告建立并發(fā)布配置狀況報告（ConfigurationStatusReporting，簡稱CSR）是軟件配置管理的一項重要任務(wù)。CSR主要是回答“發(fā)生了什么事情”、“誰做的”、”何時發(fā)生的“、“有什么影響”等問題。通過CSR紀錄和報告的復(fù)查，便能確定合適做過何種變動，何種元素被添加到已批準的基線及在給定時刻軟件配置處于何種狀態(tài)等等。配置狀態(tài)報告建立并發(fā)布配置狀況報告（Configuratio129配置管理工具SourceSafeMicrosoftVisualStudio套件之一簡單易用，一學(xué)就會是國內(nèi)最流行的配置管理工具CVSConcurrentVersionSystem（并行版本系統(tǒng)）開源工具，服務(wù)器用JAVA編寫，用于UNIX，LINUX客戶端很雜，安裝使用不便ClearCaseRational產(chǎn)品是軟件行業(yè)公認的功能最強大、價格最昂貴的配置管理軟件不參加培訓(xùn)，基本不可能無師自通配置管理工具SourceSafe130能力成熟度模型CMM美國卡內(nèi)基-梅隆大學(xué)軟件工程研究所(SEI)80年代中期美國國防部資助提出軟件能力成熟度模型(SoftwareCapabilityMaturityModel)軟件過程改進工業(yè)標準克勞斯比漢弗萊成熟度框架能力成熟度模型CMM美國卡內(nèi)基-梅隆大學(xué)軟件工程研究所(SE131當初，建立CMM的目的主要是：為大型軟件項目的招投標活動提供一種全面而客觀的評審依據(jù)，發(fā)展到后來，此模型又同時被應(yīng)用于許多軟件機構(gòu)內(nèi)部的過程改進活動中。能力成熟度模型CMM當初，建立CMM的目的主要是：為大型軟件項目的招投標活動提供132軟件組織的比較產(chǎn)品質(zhì)量有保證，軟件過程有紀律，有必要的支持性基礎(chǔ)設(shè)施。

問題判斷無基礎(chǔ)，難預(yù)料；進度滯后時，常減少或取消評審、測試等保證質(zhì)量的活動。

質(zhì)量管理有歷史數(shù)據(jù)和客觀依據(jù)，比較準確。

無實際根據(jù)，硬件限定時，常在質(zhì)量上作讓步。

進度、經(jīng)費估計主動式，監(jiān)控產(chǎn)品質(zhì)量和顧客滿意程度。

反應(yīng)式（消防式）管理方式有統(tǒng)一標準，且切實可行，并不斷改進；通過培訓(xùn)，全員理解，各司其職，紀律嚴明。

臨時拼湊、不能貫徹軟件過程成熟的軟件組織

不成熟的軟件組織

比較項目

軟件組織的比較產(chǎn)品質(zhì)量有保證，軟件過程有紀律，有必要的支持性133CMM的基本概念軟件過程能力 描述開發(fā)組織或項目組遵循其軟件過程能夠?qū)崿F(xiàn)預(yù)期結(jié)果的程度，它既可對整個軟件開發(fā)組織而言，也可對一個軟件項目而言。軟件過程成熟度 一個特定軟件過程被明確且有效地定義、管理、測量和控制的程度。軟件能力成熟度等級 軟件開發(fā)組織在走向成熟的途中幾個具有明確定義的表示軟件過程能力成熟度的平臺。CMM的基本概念軟件過程能力134由于軟件危機等問題是由我們管理軟件過程的方法不當引起的，所以新軟件技術(shù)的應(yīng)用并不會自動提高軟件的生產(chǎn)率和質(zhì)量。能力成熟度模型有助于軟件開發(fā)機構(gòu)建立一個有規(guī)律的、成熟的軟件過程。改進的軟件過程將開發(fā)出質(zhì)量更好的軟件，使更多的軟件項目免受時間和經(jīng)費超支之苦。CMM基本思想由于軟件危機等問題是由我們管理軟件過程的方法不當引起的，所以135CMM把軟件過程從無序到有序的進化分成5個階段，排序而形成5個逐層提高的等級。用以測量軟件機構(gòu)的軟件過程成熟度和評價其軟件過程能力。1初始級2可重復(fù)級5優(yōu)化級3已定義級4已管理級CMM模型概要CMM把軟件過程從無序到有序的進化分成5個階段，排序而形成5136軟件過程是無序的，有時甚至是混亂的，對軟件過程幾乎沒有定義，成功取決于個人努力。管理是反應(yīng)式(消防式)。軟件機構(gòu)基本沒有健全的工程管理制度，軟件過程完全取決于項目組的人員配備，具有不可預(yù)測性，人員變了過程隨之改變。處于1級成熟度的軟件機構(gòu)，其過程能力不可預(yù)測，軟件過程是不穩(wěn)定的，產(chǎn)品質(zhì)量是根據(jù)相關(guān)人員的個人工作能力而不是軟件機構(gòu)的過程能力來預(yù)測。1初始級軟件過程是無序的，有時甚至是混亂的，對軟件過程幾乎沒137

建立了基本的項目管理過程(過程模型)來跟蹤成本、進度和質(zhì)量特性。制定了必要的過程規(guī)范，能重復(fù)早先類似應(yīng)用項目的實踐經(jīng)驗成功完成新項目。達到2級的目標是使項目管理過程穩(wěn)定，從而使得軟件機構(gòu)能重復(fù)以前在成功項目中所進行過的軟件項目工程實踐。

處于2級的軟件機構(gòu)，其軟件項目的策略和跟蹤是穩(wěn)定的，已經(jīng)為一個有紀律的管理過程提供了可重復(fù)以前成功實踐的項目環(huán)境。2可重復(fù)級建立了基本的項目管理過程(過程模型)來跟蹤成本、進度138已經(jīng)定義了完整的軟件過程，軟件過程已文檔化、標準化。所有項目均使用經(jīng)批準的、文檔化的標準軟件過程來開發(fā)和維護軟件。包含2級的全部特征。在第3級成熟度的軟件機構(gòu)中，有一個固定的過程小組從事軟件過程工程活動。過程小組可以利用過程模型進行過程例化活動，還可以推進軟件機構(gòu)的過程改進活動。實施了培訓(xùn)計劃，保證全體項目負責(zé)人和開發(fā)人員具有完成承擔(dān)的任務(wù)所要求的知識和技能。處于3級的軟件機構(gòu)，無論管理活動和工程活動都是穩(wěn)定的。成本、進度和質(zhì)量都受到控制，且軟件質(zhì)量具有可追溯性。3已定義級已經(jīng)定義了完整的軟件過程，軟件過程已文檔化、標準化。139所有項目的重要過程活動都是可度量的。軟件機構(gòu)收集了過程度量和產(chǎn)品質(zhì)量的方法并加以運用，對軟件過程和產(chǎn)品都有定量的理解與控制。包含3級的全部特征。處于4級成熟度的軟件機構(gòu)，軟件過程是可度量的，軟件過程在可度量的范圍內(nèi)運行。這一級的過程能力允許軟件機構(gòu)在定量的范圍內(nèi)預(yù)測過程和產(chǎn)品質(zhì)量趨勢，在發(fā)生偏離時可以及時采取措施予以糾正。4已定量管理級所有項目的重要過程活動都是可度量的。軟件機構(gòu)收集了過140過程的量化反饋和先進的新思想、新技術(shù)促進軟件過程不斷改進。軟件機構(gòu)是一個以防止出現(xiàn)缺陷為目標的機構(gòu)，它有能力識別出軟件過程要素的薄弱環(huán)節(jié)，并有足夠的手段改進它們。包含4級的全部特征。通過對過程實例性能的分析，確定產(chǎn)生某缺陷的原因，來防止出現(xiàn)這種類型的缺陷；通過對任何過程實例的分析所獲得的經(jīng)驗教訓(xùn)都可以成為該軟件機構(gòu)優(yōu)化其過程模型的有效依據(jù)，從而使其他項目的過程實例得到優(yōu)化。5優(yōu)化級過程的量化反饋和先進的新思想、新技術(shù)促進軟件過程不斷改進。軟141CMM概述這5個成熟度等級定義了一個有序的尺度，用以測量軟件機構(gòu)過程能力成熟度和評價其軟件過程能力。這些等級還能夠幫助軟件機構(gòu)把應(yīng)做的改進工作排出優(yōu)先順序。CMM對5個成熟度級別的描述，說明了不同級別之間軟件過程的主要變化。從1級到5級，反映了一個軟件機構(gòu)為了達到從一個無序、混亂的軟件過程進化到一個有序、有紀律且成熟的軟件過程的目標，必須經(jīng)歷的過程改進的途徑。CMM概述這5個成熟度等級定義了一個有序的尺度，用以測量軟件142統(tǒng)計數(shù)字表明，提高一個完整的成熟度等級大約需要花18個月到3年時間，但從第1級上升到第2級有時要花3年甚至5年時間。這說明要向一個處于混亂和被動的行動方式的軟件機構(gòu)灌輸系統(tǒng)化方法是困難的。CMM概述統(tǒng)計數(shù)字表明，提高一個完整的成熟度等級大約需要花18個月到3143軟件過程評估：目的是確定一個組織的當前軟件過程的狀態(tài)，找出組織所面臨的急需解決的與軟件過程有關(guān)問題，進而有步驟地實施軟件過程改進，使組織的軟件過程能力不斷提高。軟件能力評價：目的是識別合格的能完成軟件工程項目的承制方，或者監(jiān)控承制方現(xiàn)有軟件工作中軟件過程的狀態(tài)，進而提出承制方應(yīng)改進之處。CMM應(yīng)用軟件過程評估：目的是確定一個組織的當前軟件過程的狀態(tài)，找出組144--軟件項目管理軟件工程--軟件項目管理軟件工程145內(nèi)容提要軟件項目管理活動項目規(guī)劃項目進度質(zhì)量管理軟件成本估算人員管理配置管理CMM內(nèi)容提要軟件項目管理活動146軟件項目管理概述隨著信息技術(shù)的飛速發(fā)展，軟件產(chǎn)品的規(guī)模也越來越龐大，個人單打獨斗的作坊式開發(fā)方式已經(jīng)越來越不適應(yīng)發(fā)展的需要。各軟件企業(yè)都在積極將軟件項目管理引入開發(fā)活動中，對開發(fā)實行有效的管理。軟件項目管理就是通過合理地組織和利用一切可以利用的資源，按照計劃的成本和計劃的進度，完成一個計劃的目標，它包含團隊管理、風(fēng)險管理、采購管理、流程管理、時間管理、成本管理和質(zhì)量管理等。是否需要管理是專業(yè)軟件開發(fā)和業(yè)余編程之間的重要區(qū)別。軟件項目管理概述隨著信息技術(shù)的飛速發(fā)展，軟件產(chǎn)品的規(guī)模也越來147軟件項目管理的特點軟件產(chǎn)品是無形的；沒有標準的軟件過程；大型軟件項目經(jīng)常是“一次性的”。軟件工程管理者與其他工程管理者的性質(zhì)是相同的，但軟件工程管理很多方面有顯著的區(qū)別，這導(dǎo)致了軟件工程管理的難