1 引言

        今天去給發展預備黨員的積極分子評分，在他們的個人展示中，見到了許多優秀的同學，在向他們學習的同時，對於我個人來說，更重要的是做自己，走好自己的路。活動結束之後，我在思考一個問題，究竟什麼是優秀？這個問題，如果看到這篇文章的讀者有興趣，可以與我共同交流和探討。

        今天和大家給大家整理的內容是軟體工程導論的最後一章，內容是軟體專案管理。軟體專案管理是軟體工程中最重要也是最困難的一項工作，因為其本質設計到人員的管理。假設在具備方案、計劃書、規格說明書等所有的資源，如果沒有人的參與，那麼這些只能是一堆毫無價值的資源，整個開發工作註定是失敗。所以，必須注重軟體專案管理。

2 軟體專案管理

2.1 估算軟體規模

2.1.1 程式碼行技術

2.1.2 功能點技術

         依據對軟體資訊域特性和軟體複雜性的評估結果，估算軟體規模。這種方法用功能點（FP）為單位度量軟體規模。

1. 資訊域特性

功能點技術定義了資訊域的5個特性:

（1） 輸入項數: 使用者向軟體輸入的項數，這些輸入給軟體提供面向應用的資料。
（2） 輸出項數: 軟體向用戶輸出的項數，它們向用戶提供面向應用的資訊，（3） 查詢數: 查詢即是一次聯機輸入，它導致軟體以聯機輸出方式產生某種即時響應。
（4） 主檔案數：邏輯主檔案（即資料的一個邏輯組合，它可能是大型資料庫的一部分或是一個獨立的檔案）的數目。

（5） 外部介面數：機器可讀的全部介面（例如，磁碟或磁帶上的資料檔案）的數量，用這些介面把資訊傳送給另一個系統。

2. 估算功能點的步驟

、（1） 計算未調整的功能點數UFP

首先，把產品資訊域的每個特性（即Inp、Out、Inq、Maf和Inf)都分類為簡單級、平均級或複雜級，並根據其等級為每個特性分配一個功能點數（例如，一個簡單級的輸入項分配3個功能點，一個平均級的輸入項分配4個功能點，而一個複雜級的輸入項分配6個功能點）。

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

（2）計算技術複雜性因子TCF

這一步驟度量14種技術因素對軟體規模的影響程度

（3） 計算功能點數FP

FP=UFP×TCF

2.2 工作量估算

2.2.1 靜態單變數模型

總體結構形式如： E=A+B×(ev)C（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

        這些模型多數都是僅根據若干應用領域中有限個專案的經驗資料推匯出來的，適用範圍有限。因此，必須根據當前專案的特點選擇適用的估算模型，並且根據需要適當地調整（例如修改模型常數）估算模型。

2.2.2 動態多變數模型

      動態多變數模型也稱為軟體方程式，它是根據從4000多個當代軟體專案中收集的生產率資料推匯出來的。該模型把工作量看作軟體規模和開發時間這兩個變數的函式。動態多變數估算模型的形式如下：

其中，
E是以人月或人年為單位的工作量；
t是以月或年為單位的專案持續時間；

B是特殊技術因子，它隨著對測試、質量保證、文件及管理技術的需求的增加而緩慢增加，對於較小的程式（KLOC=5~15），B=0.16,對於超過70 KLOC的程式，B=0.39;

其中， P是生產率引數，它反映了下述因素對工作量的影響。 
總體過程成熟度及管理水平。    
使用良好的軟體工程實踐的程度。
使用的程式設計語言的級別。        
軟體環境的狀態。
軟體專案組的技術及經驗。            
應用系統的複雜程度。
        開發實時嵌入式軟體時，P的典型值為2000；開發電信系統和系統軟體時，P=10000；對於商業應用系統來說，P=28000。可以從歷史資料匯出適用於當前專案的生產率引數值。

        從上述公式可以看出，開發同一個軟體（即LOC固定）的時候，如果把專案持續時間延長一些，則可降低完成專案所需的工作量。

2.2.3 COCOMO2模型

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

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

COCOMO2給出了3個層次的軟體開發工作量估算模型：

（1）應用系統組成模型。
        這個模型主要用於估算構建原型的工作量，模型名字暗示在構建原型時大量使用已有的構件。
（2）早期設計模型。
    這個模型適用於體系結構設計階段。
（3） 後體系結構模型。

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

        為了確定工作量方程中模型指數b的值，原始的COCOMO模型把軟體開發專案劃分成組織式、半獨立式和嵌入式這樣3種類型，並指定每種專案型別所對應的b值（分別是1.05，1.12和1.20）。

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

2.3 進度計劃

         軟體專案的進度安排是這樣一種活動，它通過把工作量分配給特定的軟體工程任務並規定完成各項任務的起止日期，從而將估算出的專案工作量分佈於計劃好的專案持續期內。

         進度計劃將隨著時間的流逝而不斷演化。在專案計劃的早期，首先制定一個巨集觀的進度安排表，標識出主要的軟體工程活動和這些活動影響到的產品功能。隨著專案的進展，把巨集觀進度表中的每個條目都精化成一個詳細進度表，從而標識出完成一個活動所必須實現的一組特定任務，並安排好實現這些任務的進度。

2.3.1 估算開發時間

        綜合上述兩個原因，存在被稱為Brooks規律的下述現象：向一個已經延期的專案增加人力，只會使得它更加延期。

專案組規模與專案組總生產率的關係

2.3.2 Gantt圖

2.3.3 工程網路

         Gantt圖能很形象地描繪任務分解情況，以及每個子任務(作業)的開始時間和結束時間，因此是進度計劃和進度管理的有力工具。它具有直觀簡明和容易掌握、容易繪製的優點，但是Gantt圖也有3個主要缺點。

(1) 不能顯式地描繪各項作業彼此間的依賴關係。
(2) 進度計劃的關鍵部分不明確，難於判定哪些部分應當是主攻和主控的物件。

(3) 計劃中有潛力的部分及潛力的大小不明確，往往造成潛力的浪費。

         當把一個工程專案分解成許多子任務，並且它們彼此間的依賴關係又比較複雜時，僅僅用Gantt圖作為安排進度的工具是不夠的，不僅難於做出既節省資源又保證進度的計劃，而且還容易發生差錯。

         工程網路是制定進度計劃時另一種常用的圖形工具，它同樣能描繪任務分解情況以及每項作業的開始時間和結束時間，此外，它還顯式地描繪各個作業彼此間的依賴關係。因此，工程網路是系統分析和系統設計的強有力的工具。

         在工程網路中用箭頭表示作業(例如，刮舊漆，重新整理漆，清理等)，用圓圈表示事件(一項作業開始或結束)。注意，事件僅僅是可以明確定義的時間點，它並不消耗時間和資源。作業通常既消耗資源又需要持續一定時間。下圖是舊木板房刷漆工程的工程網路。圖中表示刮第1面牆上舊漆的作業開始於事件1，結束於事件2。用開始事件和結束事件的編號標識一個作業，因此“刮第1面牆上舊漆”是作業1-2。

          在下圖中還有一些虛線箭頭，它們表示虛擬作業，也就是事實上並不存在的作業。引入虛擬作業是為了顯式地表示作業之間的依賴關係。

2.3.4 估算工程進度

      畫出工程網路之後，系統分析員就可以藉助它的幫助估算工程進度了。為此需要在工程網路上增加一些必要的資訊。

      首先，把每個作業估計需要使用的時間寫在表示該項作業的箭頭上方。注意，箭頭長度和它代表的作業持續時間沒有關係，箭頭僅表示依賴關係，它上方的數字才表示作業的持續時間。

         其次，為每個事件計算下述兩個統計數字： 最早時刻EET和最遲時刻LET。這兩個數字將分別寫在表示事件的圓圈的右上角和右下角，如有圖左下角的符號所示。

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

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

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

2.3.5 關鍵路徑

2.3.6 機動時間

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

         一個作業可以有的全部機動時間等於它的結束事件的最遲時刻減去它的開始事件的最早時刻，再減去這個作業的持續時間： 

                             機動時間=(LET)結束-(EET)開始-持續時間

 對於前述油漆舊木板房的例子，計算得到的非關鍵作業的機動時間見下表13.6：

         在工程網路中每個作業的機動時間寫在代表該項作業的箭頭下面的括號裡(參看圖13.3)。在制定進度計劃時仔細考慮和利用工程網路中的機動時間，往往能夠安排出既節省資源又不影響最終竣工時間的進度表。

          例如，研究圖13.3(或表13.6)可以看出，清理前三面牆窗戶的作業都有相當多機動時間，也就是說，這些作業可以晚些開始或者持續時間長一些(少用一些資源)，並不影響竣工時間。
          此外，刮第3、第4面牆上舊漆和給第1面牆重新整理漆的作業也都有機動時間，而且這後三項作業的機動時間之和大於清理前三面牆窗戶需要用的工作時間。因此，有可能僅用10名工人在同樣時間內(23小時)完成舊木板房刷漆工程。

          進一步研究圖13.3中的工程網路可以看出，確實能夠只用10名工人在同樣時間內完成這項任務，而且可以安排出幾套不同的進度計劃，都可以既減少5名工人又不影響竣工時間。

圖13.1舊木板房刷漆工程的Gantt圖

圖13.4舊木板房刷漆工程改進的Gantt圖之一

        上述的簡單例子明顯說明了工程網路比Gantt圖優越的地方： 它顯式地定義事件及作業之間的依賴關係，Gantt圖只能隱含地表示這種關係。但是Gantt圖的形式比工程網路更簡單更直觀，為更多的人所熟悉，因此，應該同時使用這兩種工具制訂和管理進度計劃，使它們互相補充取長補短。

         以上通過舊木板房重新整理漆工程的簡單例子，介紹了制訂進度計劃的兩個重要工具和方法。軟體工程專案雖然比這個簡單例子複雜得多，但是計劃和管理的基本方法仍然是自頂向下分解，也就是把專案分解為若干個階段，每個階段再分解成許多更小的任務，每個任務又可進一步分解為若干個步驟等。這些階段、任務和步驟之間有複雜的依賴關係，因此，工程網路和Gantt圖同樣是安排進度和管理工程進展情況的強有力的工具。

2.4 人員組織

          軟體專案成功的關鍵是有高素質的軟體開發人員。然而大多數軟體的規模都很大，單個軟體開發人員無法在給定期限內完成開發工作，因此，必須把多名軟體開發人員合理地組織起來，使他們有效地分工協作共同完成開發工作。

         現有的軟體專案組的組織方式很多，通常，組織軟體開發人員的方法，取決於所承擔的專案的特點、以往的組織經驗以及管理者的看法和喜好。下面介紹3種典型的組織方式。

2.4.1 民主製程序員組

         民主製程序員組的一個重要特點是，小組成員完全平等，享有充分民主，通過協商做出技術決策。

         如果組內多數成員是經驗豐富技術熟練的程式設計師,那麼上述非正式的組織方式可能會非常成功。

2.4.2 主程式設計師組

IBM在20世紀70年代初期開始採用主程式設計師組的組織方式

        主程式設計師組用經驗多、技術好、能力強的程式設計師作為主程式設計師，同時，利用人和計算機在事務性工作方面給主程式設計師提供充分支援，而且所有通訊都通過一兩個人進行。 

         這種組織方式類似於外科手術小組的組織：主刀大夫對手術全面負責，並且完成制訂手術方案、開刀等關鍵工作，同時又有麻醉師、護士長等技術熟練的專門人員協助和配合他的工作。此外，必要時手術組還要請其他領域的專家（例如，心臟科醫生或婦產科醫生）協助。

上述比喻突出了主程式設計師組的兩個重要特性。 

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

（2） 層次性。主刀大夫指揮每名組員工作，並對手術全面負責。

        當時，典型的主程式設計師組的組織形式如下圖所示。該組由主程式設計師、後備程式設計師、程式設計祕書以及1~3名程式設計師組成。在必要的時候，該組還有其他領域的專家協助。

接下來介紹主程式設計師組的結構主程式設計師組核心人員的分工：

（1） 主程式設計師既是成功的管理人員又是經驗豐富、技術好、能力強的高階程式設計師，負責體系結構設計和關鍵部分（或複雜部分）的詳細設計，並且負責指導其他程式設計師完成詳細設計和編碼工作。如圖所示，程式設計師之間沒有通訊渠道，所有介面問題都由主程式設計師處理。主程式設計師對每行程式碼的質量負責，因此，他還要對組內其他成員的工作成果進行復查。

（2） 後備程式設計師也應該技術熟練而且富於經驗，他協助主程式設計師工作並且在必要時（例如，主程式設計師生病、出差或“跳槽”）接替主程式設計師的工作。因此，後備程式設計師必須在各方面都和主程式設計師一樣優秀，並且對本專案的瞭解也應該和主程式設計師一樣深入。平時，後備程式設計師的工作主要是，設計測試方案、分析測試結果及獨立於設計過程的其他工作。

（3） 程式設計祕書負責完成與專案有關的全部事務性工作，例如，維護專案資料庫和專案文件，編譯、連結、執行源程式和測試用例。

        主程式設計師組的組織方式說起來有不少優點，但是，它在許多方面卻是不切實際的。

2.4.3 現代程式設計師組

         民主製程序員組的一個主要優點，是小組成員都對發現程式錯誤持積極、主動的態度。但是，使用主程式設計師組的組織方式時，主程式設計師對每行程式碼的質量負責，因此，他必須參與所有程式碼審查工作。由於主程式設計師同時又是負責對小組成員進行評價的管理員，他參與程式碼審查工作就會把所發現的程式錯誤與小組成員的工作業績聯絡起來，從而造成小組成員出現不願意發現錯誤的心理。

 解決上述問題的方法是，取消主程式設計師的大部分行政管理工作。

      實際的“主程式設計師”應該由兩個人共同擔任：  一個技術負責人，負責小組的技術活動；一個行政負責人，負責所有非技術性事務的管理決策。

        技術組長要參與全部程式碼審查工作。相反，行政組長不可以參與程式碼審查工作，因為他的職責是對程式設計師的業績進行評價。行政組長應該在常規排程會議上了解每名組員的技術能力和工作業績。

組織結構圖

         在開始工作之前明確劃分技術組長和行政組長的管理許可權是很重要的。但是，即使已經做了明確分工，有時也會出現職責不清的矛盾。例如，考慮年度休假問題，行政組長有權批准某個程式設計師休年假的申請，因為這是一個非技術性問題，但是技術組長可能馬上否決了這個申請，因為已經接近預定的專案結束日期，目前人手非常緊張。解決這類問題的辦法是求助於更高層的管理人員，對行政組長和技術組長都認為是屬於自己職責範圍內的事務，制定一個處理方案。

         由於程式設計師組成員人數不宜過多，當軟體專案規模較大時，應該把程式設計師分成若干個小組，採用下圖所示的組織結構。

         該圖描繪的是技術管理組織結構，非技術管理組織結構與此類似。由圖可以看出，產品開發作為一個整體是在專案經理的指導下進行的，程式設計師向他們的組長彙報工作，而組長則向專案經理彙報工作。當產品規模更大時，可以適當增加中間管理層次。

         把民主製程序員組和主程式設計師組的優點結合起來的另一種方法，是在合適的地方採用分散做決定的方法，如下圖所示。

        這樣做有利於形成暢通的通訊渠道，以便充分發揮每個程式設計師的積極性和主動性，集思廣益攻克技術難關。這種組織方式對於適合採用民主方法的那類問題（例如研究性專案或遇到技術難題需要用集體智慧攻關）非常有效。儘管這種組織方式適當地發揚了民主，但是上下級之間的箭頭（即管理關係）仍然是向下的，也就是說，是在集中指導下發揚民主。顯然，如果程式設計師可以指揮專案經理，則只會引起混亂。

2.5 質量保證

         質量是產品的生命，不論生產何種產品，質量都是極端重要的。軟體產品開發週期長，耗費巨大的人力和物力，更必須特別注意保證質量。

2.5.1 軟體質量

         概括地說，軟體質量就是“軟體與明確地和隱含地定義的需求相一致的程度”。更具體地說，軟體質量是軟體與明確地敘述的功能和效能需求、文件中明確描述的開發標準以及任何專業開發的軟體產品都應該具有的隱含特徵相一致的程度。

上述定義強調了下述的3個要點。 
（1）  軟體需求是度量軟體質量的基礎，與需求不一致就是質量不高。
（2） 指定的開發標準定義了一組指導軟體開發的準則，如果沒有遵守這些準則，肯定會導致軟體質量不高。

（3） 通常，有一組沒有顯式描述的隱含需求（例如，軟體應該是容易維護的）。如果軟體滿足明確描述的需求，但卻不滿足隱含的需求，那麼軟體的質量仍然是值得懷疑的。

2.5.2 軟體質量保證措施

         軟體質量保證（software quality assurance, SQA）的措施主要有：基於非執行的測試（也稱為複審或評審），基於執行的測試（即以前講過的軟體測試）和程式正確性證明。

         複審主要用來保證在編碼之前各階段產生的文件的質量；基於執行的測試需要在程式編寫出來之後進行，它是保證軟體質量的最後一道防線；程式正確性證明使用數學方法嚴格驗證程式是否與對它的說明完全一致。

參加軟體質量保證工作的人員，可以劃分成下述兩類。 
軟體工程師，通過採用先進的技術方法和度量，進行正式的技術複審以及完成計劃周密的軟體測試來保證軟體質量。

SQA小組，職責是輔助軟體工程師以獲得高質量的軟體產品。其從事的軟體質量保證活動主要是：  計劃，監督，記錄，分析和報告。簡而言之，SQA小組的作用是，通過確保軟體過程的質量來保證軟體產品的質量。

2.6 軟體配置管理

2.6.1 軟體配置

          隨著軟體開發過程的進展，軟體配置項的數量迅速增加。不幸的是，由於前述的種種原因，軟體配置項的內容隨時都可能發生變化。為了開發出高質量的軟體產品，軟體開發人員不僅要努力保證每個軟體配置項正確，而且必須保證一個軟體的所有配置項是完全一致的。

        可以把軟體配置管理看作是應用於整個軟體過程的軟體質量保證活動，是專門用於管理變化的軟體質量保證活動。

          除了軟體配置項之外，許多軟體工程組織也把軟體工具置於配置管理之下，也就是說，把特定版本的編輯器、編譯器和其他CASE工具，作為軟體配置的一部分“固定”下來。

         因為當修改軟體配置項時必然要用到這些工具，為防止不同版本的工具產生的結果不同，應該把軟體工具也基線化，並且列入到綜合的配置管理過程之中。

2.6.2 軟體配置管理過程

         軟體配置管理是軟體質量保證的重要一環，它的主要任務是控制變化，同時也負責各個軟體配置項和軟體各種版本的標識、軟體配置審計以及對軟體配置發生的任何變化的報告。

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

2.7 能力成熟度模型

3. 已定義級

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

          在第3級成熟度的軟體機構中，有一個固定的過程小組從事軟體過程工程活動。當需要時，過程小組可以利用過程模型進行過程例化活動，從而獲得一個針對某個特定的軟體專案的過程例項，並投入過程運作而開展有效的軟體專案工程實踐。同時，過程小組還可以推進軟體機構的過程改進活動。在該軟體機構內實施了培訓計劃，能夠保證全體專案負責人和專案開發人員具有完成承擔的任務所要求的知識和技能。

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

4. 已管理級

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

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

5. 優化級

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

          這一級的軟體機構可以通過對過程例項效能的分析和確定產生某一缺陷的原因，來防止再次出現這種型別的缺陷；通過對任何一個過程例項的分析所獲得的經驗教訓都可以成為該軟體機構優化其過程模型的有效依據，從而使其他專案的過程例項得到優化。這樣的軟體機構可以通過從過程實施中獲得的定量的反饋資訊，在採用新思想和新技術的同時測試它們，以不斷地改進和優化軟體過程。

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

          一些統計數字表明，提高一個完整的成熟度等級大約需要花18個月到3年的時間，但是從第1級上升到第2級有時要花3年甚至5年時間。這說明要向一個迄今仍處於混亂的和被動的行動方式的軟體機構灌輸系統化的方式，將是多麼困難。

3 結束語

    估算軟體的規模和工作量估算，雖然有不少的學者已經推匯出公式，但是公式中的部分數值來源於經驗，並沒有嚴格的數學推理和證明，經驗越多，相對來說估計得更為準確。

    能力成熟度模型，不知道在現實的開發工作中，是否使用。