軟件工程項目管理教材

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

按預定的成本和進度開發(fā)系統(tǒng)，并且使得用戶滿意的概率?？衫斫庑?/p>

理解和使用軟件的容易程度?？删S護性

診斷和改正在運行現場發(fā)現的錯誤所需要的工作量大小。軟件質量的屬性適應性

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

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

把軟件從一軟硬件環(huán)境移植到另一配置環(huán)境時，需要的工作量大小?？芍赜眯?/p>

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

允許軟件能夠從一臺計算機很容易地傳輸到另一臺需要運行的計算機上的能力。

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

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

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

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

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

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

)。代碼行技術代碼行技術的優(yōu)點：代碼是所有軟件項目開發(fā)都包含的“產品”，而且代碼行數很容易計算。代碼行技術的缺點：源程序僅是軟件配置的一個成分，用它的規(guī)模代表整個軟件規(guī)模不太合理；用不同語言實現同一個軟件所需的代碼行數并不相同，即它依賴于所使用的編程語言；不適合于非過程語言。功能點技術是為克服代碼行技術缺點提出的；它涉及多種因素的度量方法；功能點技術根據軟件的基本功能來定義，所以在系統(tǒng)設計初期就能夠估算出軟件項目的規(guī)模。信息域特性產品信息域的5個特性：輸入項數(Inp):用戶向軟件輸入的項數，這些輸入給軟件提供了面向應用的數據。輸出項數(Out):軟件向用戶輸出的項數，它們向用戶提供面向應用的信息。查詢數(Inq):查詢即一次聯機輸入，它導致軟件以聯機輸出方式產生某種即時響應。主文件數(Maf):邏輯主文件（數據的一個邏輯集合）的數目。外部接口數(Inf):

機器可讀的全部接口的數量。功能點技術基本原理使用5個信息域的“加權和”CT與14個技術因素的“復雜性調節(jié)值”Fi來計算功能點FP:估算功能點的步驟1、計算未調整的功能點數CT首先把信息域的每個特性都分類為簡單級、平均級或復雜級，根據等級按下表分配功能點數：1075接口系數a515107文件系數a4643查詢系數a3754輸出系數a2543輸入系數a1復雜平均簡單特性系數復雜級別然后用下式計算未調整的功能點數CT：CT=a1×Inp＋a2×Out＋a3×Inq＋a4×Maf＋a5×Inf估算功能點的步驟2、計算技術復雜因子TCF軟件復雜度的估算基于14個問題，逐一對各問題做出復雜度估計Fi，其取值范圍是0-5。估算功能點的步驟“沒有影響”取值0“偶然的”取值1“適中的”取值2“普通的”取值3“重要的”取值4“極重要的”取值5系統(tǒng)需要可靠的備份和復原嗎？需要數據通信嗎？有分布處理功能嗎？性能很關鍵嗎？系統(tǒng)是否在一個已有的、很實用的操作環(huán)境中運行？系統(tǒng)需要聯機入口嗎？聯機入口需要在多屏幕或多操作之間切換以完成輸入？系統(tǒng)聯機需要更新主文件嗎？系統(tǒng)的輸入、輸出、文件或查詢很復雜嗎？系統(tǒng)內部處理復雜嗎？代碼需要被設計成可復用的嗎？設計中要包括轉換及安裝嗎？系統(tǒng)的設計支持不同組織的多次安裝嗎？系統(tǒng)的設計有利于用戶修改和使用嗎？功能點技術功能點技術沒有涉及系統(tǒng)本身的算法復雜性。因此，它僅僅適合與算法比較簡單的事務處理系統(tǒng)軟件的規(guī)模度量；對算法較復雜的大型軟件系統(tǒng)并不適應。工作量估算軟件估算模型使用由經驗導出的公式來預測軟件開發(fā)工作量，工作量是軟件規(guī)模(LOC或FP)的函數，工作量的單位通常是人月（pm）。靜態(tài)單變量模型動態(tài)多變量模型COCOMO2模型支持大多數估算模型的經驗數據，都是從有限個項目的樣本集中總結出來的，因此，沒有一個估算模型可以使用于所有類型的軟件和開發(fā)環(huán)境。靜態(tài)單變量模型靜態(tài)單變量的總體結構形式如下：

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

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

＋840×2－250×15＝17930（行/年）即新增加人，并未提高生產率。Brooks定律向一個進度已經落后的項目增派開發(fā)人員，可能使項目完成得更晚。人與月是不能互換的！開發(fā)人員以算術級數增加，人員之間交換意見的路徑數將以幾何級數增加。項目組的組織方式軟件項目組的組織方式很多，如民主制程序員組、主程序員組、現代程序員組等。具體項目組組織方式的選擇，取決于所承擔的項目特點、以往組織經驗及管理者的看法和喜好！民主制程序員組小組成員完全平等，享有充分民主，通過協商做出決策。小組成員之間的通訊是平行的，如果小組有n個成員，則可能的通訊信道為n(n-1)/2條。民主制程序員組通常采用非正式的組織方式，雖然名義上有一個組長，但其與組內其它成員完成同樣的任務。由小組全體成員討論協商決定應該完成的工作，并依據各成員能力和經驗分配適當的任務。民主制程序員組優(yōu)點：組員對發(fā)現程序錯誤持積極的態(tài)度，這種態(tài)度有助于更快地發(fā)現錯誤，從而導致高質量的代碼；組員享有充分民主，小組有高度凝聚力，組內學習氣氛濃厚，有利于攻克技術難關。民主制程序員組如果組內多數成員是經驗豐富、技術熟練的程序員，采用該組織方式是非常有效的。但是，在組內多數成員技術水平不高或缺乏經驗情況下采用該組織方式，將會因為沒有明確的權威指導項目進展，小組成員間缺乏必要的協調，而導致項目失敗。適合于研制周期長、難度大的項目。日本大多數軟件開發(fā)公司都采用這種形式。主程序員組項目開發(fā)普遍存在以下事實：軟件開發(fā)人員多數比較缺乏經驗；程序設計過程有許多事務性的工作；多渠道通訊很浪費時間，降低程序員的生產率。IBM在20世紀70年代初期開始使用主程序員組的組織方式。編程秘書負責完成與項目有關的全部事務性工作，如，維護項目資料庫和項目文檔，編譯、連接、執(zhí)行源程序和測試用例。主程序員既是成功的管理人員，又是經驗豐富、技術好、能力強的高級程序員，負責體系結構設計和關鍵部分的詳細設計，并且負責指導其他程序員完成詳細設計和編碼工作主程序員組主程序員編程秘書后備程序員程序員程序員程序員后備程序員也應該技術熟練而且富于經驗，他協助主程序員工作并且在必要時(主程序員生病、出差或跳槽)接替主程序員的工作。所以后備程序員必須和主程序一樣優(yōu)秀，一樣深入了解項目。主程序員組主程序員組使用經驗豐富、技術好、能力強的程序員作為主程序員。同時，利用人和計算機在事務性工作方面給主程序員提供充分支持，而且保證所有通訊都通過一兩個人進行。這種組織方式類似于外科手術小組的組織：主刀大夫對手術全面負責，并且完成訂制手術方案、動手術等關鍵工作，同時麻醉師、護士等技術熟練的專門工作人員協助配合主刀大夫工作，此外，必要時還要聘請領域專家予以協助。主程序員組的重要特征專業(yè)化 該組每名成員僅完成他們受過專業(yè)訓練的那些工作。層次性 主程序員負責指揮每名成員工作，對軟件項目全面負責。主程序員組的不足雖然主程序員組有很多優(yōu)點，但是，我們還應看到這種組織方式固有的不切實際的地方：主程序員既是高級程序員又是優(yōu)秀管理者，但現實中這種人才很難見到。后備程序員更難找。人們希望后備程序員像主程序員一樣優(yōu)秀，但他們必須坐在“替補席”上，拿著較低的工資等待接替主程序員。編程秘書也很難找。專業(yè)的軟件技術人員一般都厭煩日常的事務性工作?，F代程序員組使用主程序員組時，主程序員對每行代碼質量負責，因此，他必須參與所有代碼審查工作。他往往會把發(fā)現程序錯誤與小組成員業(yè)績聯系起來，造成小組成員不愿意發(fā)現錯誤的心理。解決辦法是：取消主程序員的行政管理工作。這樣既解決了問題，又使尋找主程序員的人選不再那么困難。行政組長技術組長程序員程序員程序員技術管理非技術管理圖例：現代程序員組由于項目組人員不宜過多，當軟件規(guī)模較大時，應該把程序員劃分成若干小組，宜采用下圖所示的組織結構：程序員程序員程序員組長程序員程序員程序員組長程序員程序員組長項目經理技術管理圖例：現代程序員組為了更好的把主程序員組和民主程序員組的優(yōu)點結合其來，在合適的時候才用分散決定的方法，即集中指導下的發(fā)揚民主：程序員程序員程序員組長程序員程序員程序員組長程序員程序員組長項目經理技術管理圖例：軟件配置管理任何軟件開發(fā)都是迭代過程，因此在軟件開發(fā)過程中，變化既是必要的，又是不可避免的。同時，變化也很容易失去控制。如果不能適當的控制管理這些變化，勢必導致混亂并產生嚴重的錯誤！軟件配置管理目標：使變化更準確且容易被適應，在必須變化時減少所需要花費的工作量。軟件配置管理是在軟件項目啟動時就開始，并且一直持續(xù)到軟件軟件退役才終止的一組追蹤和控制軟件變動的保護性活動。軟件配置管理（SCM），是在軟件整個生命周期內管理變化的一組活動。是對工作成果的一種有效保護。軟件配置上述這些項組成了軟件過程中產生的全部信息，我們把他們統(tǒng)稱為軟件配置，其中每一項即一個軟件配置項（SoftwareConfigurationItem，簡稱SCI）。SCI是納入配置管理范疇的工作成果。SCI是配置管理的基本單位。軟件開發(fā)過程的工作成果：

計算機程序（源代碼和可執(zhí)行程序）；

描述計算機程序的文檔（供技術人員或用戶使用）；數據（包括程序內部和外部定義的數據）。軟件配置項SCI的主要屬性：名稱、標識符、狀態(tài)、版本、作者、日期等。SCI的狀態(tài)有：草稿(Draft)、正式發(fā)布(Released)和正在修改(Changing)。正式發(fā)布正在修改評審或審批草稿通過否決自由修改變更控制SCI狀態(tài)變遷圖基線(Baseline)IEEE把基線定義為： “已經通過正式復審和批準的某規(guī)約或產品，它因此可以作為進一步開發(fā)的基礎，并且只能遵循正式的變化控制過程得到改變”簡而言之，基線是由通過正式評審的一組軟件配置項組成。在軟件配置項變成基線之前，可以迅速而非正式的修改它。一旦建立了基線以后，基線中的配置項就被“凍結”了，不能再被任何人隨意修改?；€的主要屬性有名稱、標識符、版本、日期等。通常將交付給客戶的基線稱一個“Release”，為內部開發(fā)用的基線則稱為一個“Build”計劃分析設計編碼測試計劃計劃基線需求規(guī)格說明需求基線設計基線編碼基線測試基線配置基線設計方案程序清單測試報告基線是軟件開發(fā)的里程碑基線(Baseline)軟件配置管理活動軟件配置管理

是軟件質量保證的重要一環(huán)，它包含主要如下任務：配置項標識變動控制版本控制配置審計配置狀態(tài)報告軟件配置管理流程配置庫操作配置管理計劃變動管理版本控制配置審計配置管理計劃……開發(fā)人員CCB負責人配置管理員職責描述人員角色1、人員與職責……備份設備計算機軟件工具描述資源名稱2、軟件硬件資源源代碼測試文檔設計文檔需求文檔預計正式發(fā)布時間標識符主要配置項3、配置項計劃配置管理計劃4、基線計劃預計建立時間基線包含的配置項基線名稱5、配置庫備份計劃備份內容、目的的、方式等備份人時間、頻度6、版本控制規(guī)劃提示：配置管理員簡述本項目的版本控制規(guī)則。7、變更控制規(guī)劃提示：配置管理員簡述本項目的變更控制規(guī)則。8、審批提示：CCB負責人（或項目經理）審批本計劃。注：CCB為配置控制委員會配置項標識目標： 明確項目生存周期內所要產生的文檔、程序以及確定文檔、程序的名稱和命名規(guī)則。內容單獨命名每個配置項，然后采用面向對象方法把所識別的配置項組織起來。每個配置項都擁有一組能唯一標識它的特征：名字、描述、資源列表和“實現”。變動控制變動控制的目的是防止SCI被隨意修改而導致混亂。變動控制，就是在生存期中對SCI的變動建立評審及核準的機制。為提高效率，對于處于“草稿”狀態(tài)的SCI，不必進行變更控制，因為草稿本來就要不斷地修改。當SCI處于“正式發(fā)布”狀態(tài)，或該SCI已經成為某個基線的一部分，若要修改，必須按照變更控制規(guī)則執(zhí)行。當變更被核準后，就把軟件移交給開發(fā)或維護團隊，以實現變更。當軟件變更時，每個組件的變更記錄都應該維護，這稱為：組件的導出歷史。組件頭信息//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版本控制版本控制的目的是按照一定的規(guī)則保存SCI的所有版本，避免發(fā)生版本丟失或混淆等現象，并且可以快速準確地查找到SCI的任何版本。版本標識一個大型系統(tǒng)內有數以百計的軟件組件，其中每種組件都可能有許多不同的版本。版本標識過程必須定義一種明確標識軟件組件版本的方式。簡單的版本編號方式是使用線性導出：V1,V1.1,V1.2,V2.1,V2.2等。實際導出結構是樹型或網絡型，而不是順序型的。版本導出結構版本導出規(guī)則SCI版本號與SCI狀態(tài)緊密相關：處于“草稿”狀態(tài)的SCI版本號格式為：0.YZYZ數字范圍為01～99；隨著草稿的不斷完善，“YZ”值應遞增，初值和增幅由規(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值設為0，增加X.Y值。參見規(guī)則2。發(fā)布版本系統(tǒng)的發(fā)布版本是分發(fā)給客戶的系統(tǒng)版本。系統(tǒng)的發(fā)布版本不僅僅是系統(tǒng)的可執(zhí)行代碼，還包括：配置文件數據文件安裝程序電子和書面文檔包裝和相關的宣傳發(fā)布管理者不能想當然認為客戶總是想安裝新的系統(tǒng)版本。因此系統(tǒng)的新版本不能依賴于以前的版本。發(fā)布版本我們來看一個例子，考慮以下情況：系統(tǒng)的發(fā)布版本1發(fā)布并投入使用；發(fā)布版本2隨后發(fā)布。由于發(fā)布版本2需要安裝新的數據文件，而有些客戶不需要發(fā)布版本2所提供的功能，而仍使用發(fā)布版本1；發(fā)布版本3需要發(fā)布版本2中的數據文件，沒有新的數據文件。發(fā)布人員不能認為發(fā)布版本3所需要的文件已經安裝在所在地點。有些地點可能從發(fā)布版本1直接到發(fā)布版本3，跳過了發(fā)布版本2。有些地方則可能已經根據具體情況對發(fā)布版本2有關的數據文件做了修改。因此數據文件必須隨同系統(tǒng)的發(fā)布版本3一起發(fā)布和安裝。配置審計配置審計主要目的是要保證基線在技術上、管理上的完整性，保證對SCI的變動是服從需求規(guī)定的。配置審計工作是變動控制委員會批準SCI的先決條件。在SLC間，不斷進行配置審計。配置狀態(tài)報告建立并發(fā)布配置狀況報告（ConfigurationStatusReporting，簡稱CSR）是軟件配置管理的一項重要任務。CSR主要是回答“發(fā)生了什么事情”、“誰做的”、”何時發(fā)生的“、“有什么影響”等問題。通過CSR紀錄和報告的復查，便能確定合適做過何種變動，何種元素被添加到已批準的基線及在給定時刻軟件配置處于何種狀態(tài)等等。配置管理工具SourceSafeMicrosoftVisualStudio套件之一簡單易用，一學就會是國內最流行的配置管理工具CVSConcurrentVersionSystem（并行版本系統(tǒng)）開源工具，服務器用JAVA編寫，用于UNIX，LINUX客戶端很雜，安裝使用不便

ClearCaseRational產品是軟件行業(yè)公認的功能最強大、價格最昂貴的配置管理軟件