軟件工程與開發(fā)技術（西電第二版）第17章 軟件計劃

第17章軟件方案17.1軟件范圍界定 17.2資源需求17.3工程估算17.4軟件工程方案的結(jié)構(gòu)17.5工程方案的分解求精17.6方案跟蹤監(jiān)督17.7方案執(zhí)行情況的度量與方案調(diào)控17.8小結(jié)17.1軟件范圍界定軟件工程方案的第一個活動是確定軟件的范圍。軟件范圍描述了軟件工程的功能、性能、約束條件、接口以及可靠性等質(zhì)量指標。此項工作旨在進一步將工程的開發(fā)任務明確化、具體化，并進行必要的功能分解，為下一步的估算工作打下根底。性能的考慮包括處理復雜度和系統(tǒng)響應時間的需求；約束條件那么標志著外部硬件或其他現(xiàn)有系統(tǒng)對軟件的限制。功能、性能和約束必須在一起進行綜合的評價。因為在功能相同時，性能限制不同，可能將導致開發(fā)工作量相差一個數(shù)量級，本錢和進度也會有顯著的差異。軟件和其他元素是相互作用的。方案制定者要考慮每個接口的性質(zhì)和復雜程度，以確定其對資源、本錢和進度的影響。接口的概念可以解釋為：(1)運行軟件的硬件及間接受軟件控制的設備和軟件之間的接口。(2)必須和新軟件連接的現(xiàn)有軟件和新軟件之間的接口。(3)人機接口。(4)軟件運行前后的一系列操作過程。針對每一種接口，都應當明確地理解通過接口的信息轉(zhuǎn)換要求。工程要求的軟件可靠性指標也應當作為一種約束予以考慮，以便在進行規(guī)模、本錢、工作量估算時能夠更加精確。在FP度量方法中，功能點復雜度加權(quán)因子和從F1～F14的取值就反映了約束條件對最終度量結(jié)果的影響。作為例子，我們對一個傳送帶分類系統(tǒng)(如圖14.1所示)的軟件需求進行范圍界定。圖17.1一個傳送帶分類系統(tǒng)原始的功能需求陳述：傳送帶分類系統(tǒng)(CLSS)用來傳送貼有識別條碼的六類不同的產(chǎn)品。產(chǎn)品通過由一個條碼閱讀器和一臺PC機組成的分類站。分類站的PC機連到一個分流器上，分流器將不同的產(chǎn)品分送到不同的包裝箱中去。CLSS軟件以和傳送帶速度一致的時間間隔接收條碼閱讀器送來的數(shù)據(jù)，將條碼數(shù)據(jù)譯碼轉(zhuǎn)換為產(chǎn)品標識符的規(guī)定格式并以此為查詢鍵值。在最多可容納1000個條目的數(shù)據(jù)庫中進行查詢檢索，以便確定當前產(chǎn)品應當放入哪個箱子中。查出來的該箱子的編號被送到分流器，分流器將根據(jù)接收到的數(shù)據(jù)將產(chǎn)品推入指定的箱子中。同時，每一個產(chǎn)品放入哪個箱子的信息還要寫入數(shù)據(jù)庫中備用。CLSS軟件還要接收來自脈沖流速計的輸入，用以使控制信號和流速計同步。根據(jù)分類站和分流器之間產(chǎn)生的脈沖個數(shù)，軟件將在適當時產(chǎn)生一個控制信號給分流器，以適當?shù)卮_定產(chǎn)品去向。根據(jù)以上陳述，我們就可以開始進行范圍界定工作。需求范圍界定：(1)讀條形碼作為輸入。(2)讀脈沖流速計輸入。(3)對條碼數(shù)據(jù)進行解碼。(4)檢索查詢數(shù)據(jù)庫。(5)確定適宜的箱子號。(6)產(chǎn)生并輸出分流器控制信號。(7)保存當前產(chǎn)品被存入的箱子的紀錄。

性能要求：每一個產(chǎn)品的全部處理都必須在下一個產(chǎn)品到達分類站之前處理完畢(根據(jù)傳送帶的流速可以換算出最大可接受的響應時間指標)。接口要求：(1)PC和分類站之間的數(shù)據(jù)接口，用來傳送原始條碼數(shù)據(jù)。(2)PC和脈沖流速計之間的接口，用來接收同步脈沖數(shù)據(jù)。(3)PC和分流器之間的接口，用來輸出分流器驅(qū)動數(shù)據(jù)。約束條件：(1)傳送帶勻速運動。(2)傳送帶上的產(chǎn)品間隔均勻擺放。如上例所示，進行了軟件范圍界定之后，就可以綜合考慮功能、性能、接口、約束條件要求，開始進行方案的下一步工作——確定資源需求并進行估算。17.2資源需求在進行了范圍界定之后，軟件方案的第二個任務是估算為完本錢軟件開發(fā)工作所需要的資源。包括人力資源、可復用軟件資源和環(huán)境資源(如圖17.2所示)。資源金字塔的底層是開發(fā)環(huán)境，包括硬件和軟件工具，提供支持開發(fā)工作的根底；再高一層是可復用的軟件構(gòu)件——軟件建筑塊，能夠極大地降低開發(fā)本錢并縮短交付時間；金字塔的頂端是人力資源，這是資源中的主要成分。在工程方案中，針對所需要的每類資源，都應當從資源描述、可用性說明、需要該資源的時間以及該資源被使用的持續(xù)時間四個特征上進行說明。圖17.2資源金字塔圖17.3不同開發(fā)階段的人員參與情況一個軟件開發(fā)組織，總是不斷地將自己的開發(fā)成果積累起來，形成自己的軟件財富庫。有一些通用功能(例如權(quán)限管理、數(shù)據(jù)維護、通用查詢等等)自然地就形成了可復用的軟件構(gòu)件。而且分析、設計階段的工作產(chǎn)品也都存在著在類似工程中重用的可能。直接使用可復用構(gòu)件，將會使開發(fā)工作量(不僅僅是編碼量)因重用而下降。所以，在方案階段，就應當考慮對可復用資源的需求?？紤]到需求吻合程度，對可復用構(gòu)件的使用，分為完全復用和修改復用兩種情況：(1)存在著現(xiàn)成的、完全滿足要求的軟件構(gòu)件，肯定應當重用它。(2)對于必須進行修改才能重用的軟件成分，要慎重處理，建議權(quán)衡了修改工作量和重新開發(fā)工作量的比照情況后再考慮是否重用。在工程方案階段，常常會無視可復用構(gòu)件重用問題，應當引起注意。硬件與軟件資源環(huán)境，是支持軟件開發(fā)的環(huán)境，通常稱為“軟件工程環(huán)境〞，集成了硬件和軟件兩大局部。硬件提供了一個支持工具平臺，如各類效勞器、網(wǎng)絡通信設備、各種外設等等；而軟件資源是工作在這一平臺上的工具集，包括分析設計工具、語言工具、中間件工具、數(shù)據(jù)庫系統(tǒng)、操作系統(tǒng)等等。除了要明確所需要的軟硬件資源環(huán)境之外，還應當明確地界定資源的時間窗口，并落實在指定的時間窗口中這些資源是否可用。17.3項目估算就本質(zhì)來說，工程估算就是“超前度量〞。直接度量和間接度量兩種模式，面向規(guī)模度量和面向功能度量兩種方法都可以用來進行估算。但是，由于“超前〞的特點，必要的根本度量數(shù)據(jù)往往難以直接得到，歷史數(shù)據(jù)和基于經(jīng)驗的模型往往成為進行估算的依據(jù)?！岸攘炕€〞在進行估算時的作用十分顯著。沒有度量基線，工程估算的根底就十分薄弱，很不穩(wěn)定。17.3.1基于問題分解的估算分解方法包括問題分解和過程分解，都可以用來進行工程的估算。在工程估算過程中，“規(guī)模〞是一個根本的度量。如果能夠估算出工程的規(guī)模，那么結(jié)合歷史數(shù)據(jù)對規(guī)模進行計算與分析，就不難完成對工作量、本錢的間接度量估算。在資源確定的前提下，進度估算也能夠利用工作量估算結(jié)果，采用間接方法完成。就規(guī)模估算本身來說，只要界定了需求目標并且進行了必要的分解細化，那么既可以利用LOC方法進行直接度量，也能夠使用功能點(或特征點、3D方法等)進行間接估算。通過對“問題〞的分解進行估算時，可以采用LOC或FP估算方法。LOC和FP的求取方法已經(jīng)在前一章中介紹過，不再重復。具體來說，LOC和FP在估算中有兩種作用：其一是作為一個估算變量，度量軟件中每個成分的規(guī)模；其二是結(jié)合度量基線數(shù)據(jù)進行計算，得到工作量與本錢估算數(shù)據(jù)。這時，來自度量基線中的生產(chǎn)率歷史數(shù)據(jù)起著非常重要的作用。由于工程的多樣性，只用一個單一的生產(chǎn)率歷史數(shù)據(jù)來作決定是不科學的。應當根據(jù)經(jīng)驗，從樂觀的、可能的、悲觀的三種主觀前提出發(fā)進行估算，根據(jù)計算出來的三個結(jié)果值再來計算LOC或FP的期望值?；诮?jīng)驗，可以采用下述加權(quán)求和公式來計算：上式中，Sopt代表“樂觀〞值，Sm代表“可能〞值，Spess代表“悲觀〞值。公式中給“可能值〞以最大權(quán)重，并遵循概率分布。一旦確定了估算變量的期望值，就可以開始使用歷史的LOC或FP相關數(shù)據(jù)作下一步估算。這種方法稱為“三點估算〞方法。(17.2)

例1基于LOC估算的例子，范圍說明如下：CAD軟件接收來自工程師輸入的三維或二維幾何數(shù)據(jù)。工程師通過用戶界面和CAD軟件進行交互，并控制它，該界面應當表現(xiàn)出良好的人機界面設計的特征。所有幾何數(shù)據(jù)及其他支持信息都保存在一個CAD數(shù)據(jù)庫中。要求開發(fā)設計分析模塊，以產(chǎn)生必要的輸出，這些輸出將表現(xiàn)在不同的圖形設備上。軟件在設計中要考慮與外設交互并控制它們。除顯示器之外，外設包括鼠標、數(shù)字化儀和激光打印機。假設已經(jīng)對上述要求進行了求精和分解，界定了以下的主要軟件子功能：(1)用戶界面及控制機制；(2)二維幾何分析(2DGA)；(3)三維幾何分析(3DGA)；(4)數(shù)據(jù)庫管理(DBM)；(5)計算機圖形顯示機制(CGDF)；(6)外設控制(PC)；(7)設計分析模塊(DAM)。表14.1基于問題分解的LOC方法的估算表問題分解所得的子功能估算的LOC期望值(行)用戶界面及控制機制2300二維幾何分析(2DGA)5300三維幾何分析(3DGA)6800數(shù)據(jù)庫管理(DBM)3350計算機圖形顯示機制(CGDF)4950外設控制(PC)2100設計分析模塊(DAM)8400估算總代碼行數(shù)期望值33?200查詢本組織的度量基線得知，此類系統(tǒng)的平均生產(chǎn)率為620LOC/PM；平均人月本錢為8000美元/人月，那么LOC平均本錢為13美元/LOC。計算可知本工程的總本錢為431000美元，總工作量54個人月。如果人力資源投入六名合格的工程師，那么預計工期為九個月。例二基于FP估算的例子。對于上例中的各個子功能進一步細化，將所有功能都分解為EI、EO、EQ以及ILF、EIF的組合，假設加權(quán)因子都取為“平均〞，計算出各類功能點見表14.2。表17.2估算信息域值——基于問題分解的FP估算信息域值樂觀值可能值悲觀值估算計數(shù)加權(quán)因子FP計數(shù)EI20243024496EO12152216580EQ16222822488ILF44541040EIF2232714總計數(shù)值

318表17.3CAD軟件工程復雜度調(diào)整因子值因子值備份和復原4信息域值復雜度5數(shù)據(jù)通信2內(nèi)部處理復雜度5分布式處理0可復用需求4關鍵性能4設計中的轉(zhuǎn)換及安裝3現(xiàn)有的操作環(huán)境3多次安裝5聯(lián)機數(shù)據(jù)登錄4方便修改的應用設計5多屏幕輸入切換5復雜度調(diào)整因子1.17主文件聯(lián)機更新3最后，得到整個工程的FP估算期望值： FP=318×[0.65+0.01×∑Fi]=372(功能點)。查詢組織的度量基線數(shù)據(jù)庫得知，這類系統(tǒng)的平均生產(chǎn)率為6.5FP/PM，一個PM的本錢仍取8000美元，那么每個FP的平均本錢約為1230美元，總工程本錢估算約為457000美元，工作量估算期望值是58個人月。17.3.2基于過程分解的估算通過對工作過程進行分解，也能夠結(jié)合度量基線進行估算。方法是將過程分解為相對較小的活動或任務，估算出完成每項任務的工作量，最后匯總即可。和基于問題分解的估算一樣，基于過程分解的估算也是開始于軟件功能描述。對于每一個功能，都必須要執(zhí)行一系列的活動，如果能夠利用同類工程的度量基線估算出對應于每項任務所需要的工作量，那么加總值就是本工程的工作量估算值。仍以CAD軟件開發(fā)工程為例，根底參數(shù)見表14.4，仍然按照每人月8000美元計算，工程總本錢368000美元，工作量共46個人月。表17.4CAD軟件工程基于過程分解的工作量估算??活動任務用戶通信計劃制訂風險分析工程分析設計UIGF

0.502.502DGA

0.754.003DGA

0.504.00DSM

0.503.00CGDF

0.503.00PCF

0.252.00DAM

0.502.00總和0.250.250.253.5020.50工作量0.5%0.5%0.5%8%45%表17.4CAD軟件工程基于過程分解的工作量估算建造發(fā)布用戶評估總和編碼測試0.405.00

8.400.602.00

7.351.003.00

8.501.001.50

6.000.751.50

5.750.501.50

4.250.502.00

5.004.7516.50

46.0010%36%

由上面的例子可見，采用不同的估算方法，結(jié)果會有一定的誤差。這在一定范圍內(nèi)是正常的，可以用幾種方法的平均估算值作為最終估算值。同時，也可以看出，度量基線在估算中的作用是無庸置疑的。如果幾種方法的估算偏差過大(一般以20%為界)，那么需要分析原因，進行再估算?？赡艿脑蛑饕袃煞N，其一是度量基線中的數(shù)據(jù)和當前問題的類型不匹配；其二是對工程的范圍理解不充分。方案者必須確定偏差過大的原因，并調(diào)和各個估算結(jié)果。17.3.3經(jīng)驗估算模型經(jīng)驗估算模型是用經(jīng)驗公式來進行工程的估算。因為公式是通過對有限樣本集的分析得出的，因此得到的結(jié)果并不一定適合當前工程類型，這種方法應當慎重使用。使用這種方法，工作量是LOC或FP的函數(shù)。典型的經(jīng)驗估算模型是通過對以前工程中收集到的數(shù)據(jù)進行回歸分析導出的?？傮w結(jié)構(gòu)具有類似的形式：E=A+B×(ev)C其中，ev是估算變量，A、B、C是基于經(jīng)驗導出來的常數(shù)，E是以人月為單位的工作量值。同時，還可以在公式中加一些調(diào)整因素以便適應當前工程的特征?；诠ぷ鲗嵺`，許多人提出了行之有效的經(jīng)驗估算模型，主要的有：(1)面向LOC的經(jīng)驗估算模型：Walston-Felix模型 E=5.2×(KLOC)0.91Bailey-Basili模型 E=5.5+0.73×(KLOC)1.16Boehm的簡單模型 E=3.2×(KLOC)1.05(2)面向FP的經(jīng)驗估算模型：Albrecnt-Gaffney模型E=－13.39+0.0545FPKemerer模型E=60.62×7.728×10－8(FP)3Maston-Barnett模型E=585.7+5.12FP不同的模型來源于不同的樣本數(shù)據(jù)集，結(jié)果對于相同的ev值會算出不同的結(jié)果。因此，估算模型必須按照當前工程特點進行調(diào)整。17.3.4COCOMO模型構(gòu)造性本錢模型(COCOMO，ConstructiveCostModel)是由BarryBoehm提出的一種被廣為應用的估算模型，它共有三個層次。(1)根本的COCOMO模型：將軟件開發(fā)工作量(及本錢)作為程序規(guī)模函數(shù)進行計算，程序規(guī)模以估算的代碼行數(shù)來表示。該模型是一個靜態(tài)單變量經(jīng)驗模型。(2)中級COCOMO模型：將軟件開發(fā)工作量(及本錢)作為程序規(guī)模及一組“本錢驅(qū)動因子〞的函數(shù)(共15項)來進行計算。其中，“本錢驅(qū)動因子〞包括對產(chǎn)品、硬件、人員及工程屬性的主觀評估。(3)高級COCOMO模型：包含了中級模型的所有特征，并結(jié)合了本錢驅(qū)動因子對軟件工程過程中每一個步驟(分析、設計、編碼等)的影響的評估。在COCOMO模型中，使用的根本量包括：源指令行數(shù)：DSI或KDSI，度量單位為行或千行，1KDSI=1024DSI(不包括注釋行)。開發(fā)工作量：MM，度量單位為“人月〞，1MM=19人日=152人時=1/12人年。開發(fā)進度：TDEV，度量單位為月，它由工作量確定。在使用COCOMO模型進行度量時，應當考慮到具體工程的特點和具體的開發(fā)環(huán)境。軟件工程的類型一般可以分為三類。(1)組織型：相對較小較簡單的軟件工程(KDSI<50)。需求不很苛刻，開發(fā)人員對軟件產(chǎn)品開發(fā)目標理解充分，軟件工作經(jīng)驗豐富，對軟件使用環(huán)境熟悉，受硬件約束小。多數(shù)應用軟件均屬此類。(2)嵌入型：要求在緊密聯(lián)系的硬件、軟件和操作的限制條件下運行。通常與某些硬設備緊密結(jié)合，因此對算法、數(shù)據(jù)結(jié)構(gòu)、接口要求較高的軟件規(guī)模任意。例如大型OS軟件、大型指揮系統(tǒng)軟件等都屬此類。(3)半獨立型：要求介于以上兩種之間的軟件。規(guī)模、復雜性規(guī)模都在中等以上。KDSI可能在300以上。例如大型ERP、簡單的指揮系統(tǒng)、大型事務處理軟件等屬于此類。針對不同的工程任務，應中選擇使用不同層次的COCOMO模型進行估算。根本的COCOMO模型工作量與進度估算公式見表14.5。表17.5根本COCOMO模型工作量與進度估算公式總體類型工作量進度組織型MM=2.4(KDSI)1.05TDEV=2.5(MM)0.38半獨立型MM=3.0(KDSI)1.12TDEV=2.5(MM)0.35嵌入型MM=3.6(KDSI)1.20TDEV=2.5(MM)0.32表17.6中級的COCOMO模型工作量與進度估算公式總體類型名義工作量名義進度組織型MM1=3.2(KDSI)1.05TDEV=2.5(MM1)0.38半獨立型MM1=3.0(KDSI)1.12TDEV=2.5(MM1)0.35嵌入型MM1=2.8(KDSI)1.20TDEV=2.5(MM1)0.32對于計算的結(jié)果，要基于經(jīng)驗進行調(diào)整，實際工作量：這里，R是經(jīng)驗系數(shù)，∏Fi是15項調(diào)整函數(shù)F1～F15的連乘積。實際進度也要利用實際工作量調(diào)整。15種影響軟件工作量的因素見表17.7。(17.4)表17.715種影響軟件工作量因素Fi

高級的COCOMO模型的名義工作量和名義進度計算公式和中級的類同，但是調(diào)整方式有區(qū)別：不再使用統(tǒng)一的工作量調(diào)整因子表，而是將15項工作量調(diào)整因子按照不同工作階段(分析與高層設計、詳細設計、編碼與單元測試、集成及測試)分別考慮，給出不同的階段工作量調(diào)整數(shù)據(jù)表，最后使用各個階段工作量調(diào)整因子的綜合均值進行工作量和工作進度調(diào)整，更為貼近實際。(17.5)對于實時嵌入式軟件的開發(fā)，典型值是p=2000；對于電信軟件及系統(tǒng)軟件，p=10000；對于科學計算軟件，p=12000；而對于商業(yè)系統(tǒng)應用，p=28000。當前工程的生產(chǎn)率數(shù)據(jù)可以從以前開發(fā)工作中收集到的歷史數(shù)據(jù)中導出。應當注意的是，軟件方程中有兩個獨立的參數(shù)：(1)規(guī)模的估算值(以LOC表示)；(2)以月或年表示的工程持續(xù)時間。為了簡化估算過程，并將該模型表示為更通用的形式，Putnum等又提出了一組方程式，它們均從軟件方程式中導出。最小開發(fā)時間被定義為tmin：tmin=8.14(LOC/P)0.43，單位是月工作量數(shù)據(jù)E：E=180Bt3，單位是人月(t的單位是人年)對于前面討論過的CAD軟件開發(fā)項目，當規(guī)模確定之后，利用上式進行計算可得(17.6)(17.7)(月)(人月)(1)對于工程規(guī)模(如LOC)或功能(如功能點)的定量估算。(2)定性的工程特性，如復雜度、所要求的可靠性或交付期限的緊迫程度。(3)對于開發(fā)人員和環(huán)境的描述。根據(jù)這些根本數(shù)據(jù)，利用自動估算工具能夠提供關于如下數(shù)據(jù)的間接估算：完成該工程所需的工作量，預期的工程本錢，工程持續(xù)時間，人員配置以及在某些情況下的開發(fā)進度及相關的風險防范。應當強調(diào)的是，實踐證明，假設干種不同工具應用于同一個工程時，得到的估算結(jié)果可能存在很大偏差。因此，應當明確，自動估算工具的輸出不應當作為惟一的估算數(shù)據(jù)來源。17.4軟件工程方案的結(jié)構(gòu)當界定了軟件范圍，明晰了約束條件和接口要求，確定了資源需求，估算出工程規(guī)模、本錢和工作量之后，制定工程開發(fā)方案就有了科學的依據(jù)。軟件工程方案由工程開發(fā)方案和相關的工作方案構(gòu)成。相關工作方案包括測試方案、品質(zhì)保證方案、配置管理方案、進度方案、培訓方案等等。在軟件工程開發(fā)方案的結(jié)構(gòu)中，應當包括任務描述、過程模型選擇、資源需求描述、工程度量估算、階段任務劃分、里程碑設置和工作產(chǎn)品清單等內(nèi)容。具體的工程開發(fā)方案的結(jié)構(gòu)可以參考“國家計算機軟件產(chǎn)品標準〞中的標準樣表。各個開發(fā)組織也可以按照自己的過程定義方法，定義本組織的工程方案結(jié)構(gòu)。3.規(guī)模、工作量、本錢及資源需求3.1軟件規(guī)模估算3.2軟件工作量估算與階段工作量分配3.3工程本錢估算與本錢控制方案3.4關鍵資源需求估算4.工程開發(fā)方案4.1工程組組織結(jié)構(gòu)4.1.1角色定義4.1.2人員分配4.2階段工作方案4.2.1工程方案階段方案4.2.2需求分析階段方案4.2.3體系結(jié)構(gòu)設計方案4.2.4詳細設計方案4.2.5測試的籌劃4.2.6編碼方案4.2.7測試方案4.2.8系統(tǒng)實施及試運行方案4.2.9驗收方案4.2.10工程維護方案5.人員培訓方案6.變更控制標準7.配置管理方案8.風險預測及應對措施9.關于本軟件開發(fā)方案的補充說明在軟件能力成熟度模型CMM中，將“軟件工程方案〞作為CMM2級的一個重要的KPA提了出來。17.5工程方案的分解求精“按照分階段的生命周期方案進行嚴格的控制〞是軟件工程七項原那么的第一項。方案是控制工程過程的依據(jù)，離開了方案，對工作的評價就沒有標準，對過程的控制就沒有根據(jù)。因此，在按照標準完成了包括范圍界定、規(guī)模估算、資源需求分析、階段劃分、角色定義等內(nèi)容的工程開發(fā)方案之后，應當進一步對其分解細化、調(diào)整求精。這樣將能夠使得開發(fā)工作步步、時時、事事有據(jù)可依、有章可循。17.5.1任務確實定與并發(fā)處理在工程開發(fā)方案中，已經(jīng)對工程的階段工作任務進行了劃分。但是在多人參加的工程中，開發(fā)工作中必然會出現(xiàn)并行情況，如圖17.4所示。圖17.4軟件工程階段任務的并行性從圖17.4中可以看到，在開發(fā)進程中設置了許多里程碑。里程碑為管理人員提供了指示工程進度的可靠依據(jù)。當一個軟件任務成功完成并通過評審，產(chǎn)生了文檔后，就完成了一個里程碑。階段任務之間的“并行〞特征也表示得較為清晰。由于軟件工程工程的“并行性〞，就提出了一系列的進度要求。因為并行任務是同時發(fā)生的，所以進度方案必須決定任務之間的附屬關系，確定各個任務的先后次序和彼此的銜接，確定各個任務完成的持續(xù)時間。此外，工程管理者必須特別注意構(gòu)成關鍵路徑的任務。在細化進度方案時，必須保證關鍵任務能夠提前，至少是按期完成。否那么必然導致工程的延誤。同時在人力資源的調(diào)配上，也要注意到并行工作帶來的影響。17.5.2制定明細的開發(fā)進度方案當工程規(guī)模、開發(fā)工作量已經(jīng)估算完畢，資源也已經(jīng)明確后，可以按照表17.8的建議來確定各個階段的工作量的分配比例，從而確定每一階段所需的開發(fā)時間，然后再針對每個階段進行任務分解，最后為分解出的各個任務進行工作量估算和開發(fā)時間的分配。在這個過程中，工程的進度方案被進一步求精，細化到了任務級。表14.8階段任務時間比例分配階段任務需求分析設計編碼與單元測試組裝與測試占開發(fā)時間的百分比10%～30%17%～27%25%～60%16%～28%為了比較清楚地表現(xiàn)各項階段任務之間在進度上的相互依賴關系，利用圖形方法表示進度方案比使用語言表達更清楚。在方案的圖形表示中，必須明確標明各個階段任務的方案開始時間、完成時間；各個任務完成的標志(約定：○表示文檔編寫；△代表評審)；各個任務中參加工作的人數(shù)；各個任務和工作量之間的銜接情況；完成各項任務所需要的物理資源和數(shù)據(jù)資源。甘特圖(GanntChart)常用來表示細化的進度方案。在用甘特圖進行進度求精時，時間單位可以分解到每周、每一個工作日乃至每一個工時，資源可以對應到每一個人。圖17.5用甘特圖表示進度方案在表示進度方案的各種形式之間進行切換，比方數(shù)據(jù)表、甘特圖、網(wǎng)絡圖等等。使用甘特圖時，每一任務的完成，不是以能否繼續(xù)下一階段的任務為標準，而是以必須交付應當交付的文檔和通過評審為標準。因此在甘特圖中，文檔編制和評審是軟件開發(fā)進度的里程碑。17.6方案跟蹤監(jiān)督?jīng)]有方案的工程是混亂的工程、沒有跟蹤監(jiān)督的方案是無效的方案。制訂方案是嚴格工程管理的第一步。在方案執(zhí)行的過程中，必須對方案的執(zhí)行情況進行跟蹤。并對跟蹤所得的結(jié)果和方案情況進行比照分析。當方案與實際之間存在著較大偏差時，必須對過程活動或者方案進行調(diào)整。方案的跟蹤監(jiān)督在能力成熟度模型CMM中是一個重要的關鍵活動域。方案是我們考核評價工作的標準，但是由于方案的根底是建立在不能完全保證精確度的“估算值〞之上，所以，即使是精心制訂的方案，也不見得就完全沒有偏差。從另一個角度來看，即使方案制訂得十分準確，當需求發(fā)生變更、資源發(fā)生變化或者發(fā)生了其他的風險，也會產(chǎn)生方案與實際進展情況脫節(jié)的現(xiàn)象。對于工程方案進行跟蹤和監(jiān)督的目的是建立對實際進展的適當可視性，使管理者能在軟件工程性能明顯偏離軟件方案時采取有效措施。工程方案的跟蹤和監(jiān)督活動包括對照文件化的估計、約定和方案審查和跟蹤軟件完成情況和結(jié)果，并且根據(jù)實際的完成情況和結(jié)果調(diào)整這些方案。軟件工程的文件化的方案(即軟件開發(fā)方案)用作跟蹤軟件活動、通報狀態(tài)和修訂方案的標準。管理者監(jiān)控軟件活動，主要通過在所選出的軟件產(chǎn)品完成時和在所選擇的里程碑處，將實際的軟件規(guī)模、工作量、本錢、資源和進度與方案值相比較，來確定真實的進展情況。必要時采取糾正措施。這些措施可以包括修訂軟件開發(fā)方案，重新籌劃遺留的工作或者改進過程性能。不管是什么原因?qū)е铝朔桨负凸こ袒顒又g的偏差，都可能造成工程的失控。因此，對方案的執(zhí)行情況進行制度化的跟蹤度量，是工程管理過程中的一項重要任務。一種可行的方法是采用周方案/周總結(jié)的方式來進行跟蹤監(jiān)督。工程經(jīng)理將工程開發(fā)方案分解到每個人、每一周。每個工作人員都必須按照工程方案制訂自己本周的工作方案并嚴格執(zhí)行，記錄必要的工作數(shù)據(jù)。在每周結(jié)束時進行周工作總結(jié)，對照自己的方案進行工作量、進度、本錢等數(shù)據(jù)的度量，找出存在的偏差并制定糾正偏差的措施。整個小組在個人跟蹤的根底上進行工程的跟蹤與監(jiān)督。在方案的跟蹤監(jiān)督活動中，最重要的跟蹤對象是工程活動、工作進度、工程資源、工作本錢和工作質(zhì)量。除了內(nèi)部的跟蹤與監(jiān)督之外，獨立于工程組的SQA人員也應當進行工程方案的跟蹤與監(jiān)督，并將發(fā)現(xiàn)的問題通報給工程成員，必要時向上級管理部門通報。對方案跟蹤監(jiān)督活動本身的進展，也應當進行度量，并將度量結(jié)果用于確定軟件跟蹤和監(jiān)督活動的狀態(tài)。需要度量的對象包括：(1)在完成跟蹤和監(jiān)督活動時所花費的工作量和其他資源；(2)根據(jù)跟蹤結(jié)果對軟件開發(fā)方案的更改活動，包括對軟件工作產(chǎn)品的規(guī)模估計、軟件本錢估計、關鍵計算機資源估計和進度的更改。17.7方案執(zhí)行情況的度量與方案調(diào)控在方案制訂并被細化求精之后，它實際上就已經(jīng)界定了工作的目標，給出了工程規(guī)模，預計的工作量，各個階段任務的完成期限，工程的總體本錢和各個階段的本錢，所需要的資源和可能發(fā)生的風險。因此，在工程工作中，應當針對這些方面的實際進展進行度量。這種度量應當是量化的、客觀的并應當形成書面的度量數(shù)據(jù)表，包括：(1)度量方案中羅列出來的所有軟件工作產(chǎn)品的實際規(guī)模數(shù)據(jù)(代碼行、文檔頁等等)；(2)度量完成各項任務的實際時間；(3)度量完成各項工作所消耗的實際本錢；(4)度量人力資源、可復用構(gòu)件資源和硬件/軟件環(huán)境資源的實際狀態(tài)(到位/未到位)；(5)度量實際的工作進度；(6)度量方案中指出的可能發(fā)生的風險情況(檢查特定的風險標識出現(xiàn)/未出現(xiàn))；(7)度量在一段時間內(nèi)發(fā)生的變更情況。上述所有度量的結(jié)果應當在工程組的周報和里程碑階段總結(jié)報告中明確地進行表述。必要時，增加對有關度量結(jié)果的說明和分析。這些工作必須形成制度，保證能夠得到執(zhí)行。度量數(shù)據(jù)和方案數(shù)據(jù)之間不可防止會存在偏差。工程管理者要對照方案進行偏差分析。當偏差超過一定范圍后，要采用修訂方