軟件工程第13章

1、第第13章章 軟件項目管理軟件項目管理 13.1 估算軟件規(guī)模估算軟件規(guī)模 13.2 工作量估算工作量估算 13.3 進度計劃進度計劃 13.4 人員組織人員組織 13.5 質(zhì)量保證質(zhì)量保證 13.6 軟件配置管理軟件配置管理 13.7 能力成熟度模型能力成熟度模型 13.8 小結(jié)小結(jié) 習題習題 在經(jīng)歷了若干個大型軟件工程項目的失敗之后，在經(jīng)歷了若干個大型軟件工程項目的失敗之后， 人們才逐漸認識到軟件項目管理的重要性和特殊性。人們才逐漸認識到軟件項目管理的重要性和特殊性。 事實上，這些項目的失敗并不是由于從事軟事實上，這些項目的失敗并不是由于從事軟 件開發(fā)工作的軟件工程師無能，正相反，他們之中

2、件開發(fā)工作的軟件工程師無能，正相反，他們之中 的絕大多數(shù)是當時杰出的技術(shù)專家。的絕大多數(shù)是當時杰出的技術(shù)專家。 這些工程項目的失敗主要是因為管理不善。這些工程項目的失敗主要是因為管理不善。 所謂管理就是通過計劃、組織和控制等一系所謂管理就是通過計劃、組織和控制等一系 列活動，合理地配置和使用各種資源，以達到既定列活動，合理地配置和使用各種資源，以達到既定 目標的過程。目標的過程。 軟件項目管理過程從項目計劃活動開始，而制軟件項目管理過程從項目計劃活動開始，而制 定計劃的基礎(chǔ)是工作量估算和完成期限估算。定計劃的基礎(chǔ)是工作量估算和完成期限估算。 為了估算項目的工作量和完成期限，首先需要為了估算項目

3、的工作量和完成期限，首先需要 估算軟件的規(guī)模。估算軟件的規(guī)模。 代碼行技術(shù)是比較簡單的定量估算軟件規(guī)模的代碼行技術(shù)是比較簡單的定量估算軟件規(guī)模的 方法。方法。 這種方法依據(jù)以往開發(fā)類似產(chǎn)品的經(jīng)驗和歷這種方法依據(jù)以往開發(fā)類似產(chǎn)品的經(jīng)驗和歷 史數(shù)據(jù)，估計實現(xiàn)一個功能所需要的源程序行數(shù)。史數(shù)據(jù)，估計實現(xiàn)一個功能所需要的源程序行數(shù)。 把實現(xiàn)每個功能所需要的源程序行數(shù)累加起來，把實現(xiàn)每個功能所需要的源程序行數(shù)累加起來， 就可得到實現(xiàn)整個軟件所需要的源程序行數(shù)。就可得到實現(xiàn)整個軟件所需要的源程序行數(shù)。 13.1 估算軟件規(guī)模估算軟件規(guī)模 13.1.1 代碼行技術(shù)代碼行技術(shù) 為了使得對程序規(guī)模的估計值更接近

4、實際值，為了使得對程序規(guī)模的估計值更接近實際值， 可以由多名有經(jīng)驗的軟件工程師分別做出估計?？梢杂啥嗝薪?jīng)驗的軟件工程師分別做出估計。 每個人都估計程序的最小規(guī)模每個人都估計程序的最小規(guī)模(a)、最大規(guī)模、最大規(guī)模(b) 和最可能的規(guī)模和最可能的規(guī)模(m)，分別算出這，分別算出這3種規(guī)模的平均值種規(guī)模的平均值, 和之后，再用下式計算程序規(guī)模的估計值：和之后，再用下式計算程序規(guī)模的估計值： L= 6 4bma 用代碼行技術(shù)估算軟件規(guī)模時用代碼行技術(shù)估算軟件規(guī)模時: 當程序較小時常用的單位是代碼行數(shù)當程序較小時常用的單位是代碼行數(shù)LOC （Line of Code ），）， 當程序較大時常用的單位

5、是千行代碼數(shù)當程序較大時常用的單位是千行代碼數(shù)KLOC ( thousands of lines of code ) 。 (1) 代碼行技術(shù)的主要優(yōu)點是代碼行技術(shù)的主要優(yōu)點是: 代碼是所有軟件開發(fā)項目都有的代碼是所有軟件開發(fā)項目都有的“產(chǎn)品產(chǎn)品”，而，而 且很容易計算代碼行數(shù)。且很容易計算代碼行數(shù)。 (2) 代碼行技術(shù)的缺點是：代碼行技術(shù)的缺點是： 源程序僅是軟件配置的一個成分，用它的規(guī)源程序僅是軟件配置的一個成分，用它的規(guī) 模代表整個軟件的規(guī)模似乎不太合理；模代表整個軟件的規(guī)模似乎不太合理； 用不同語言實現(xiàn)同一個軟件所需要的代碼行用不同語言實現(xiàn)同一個軟件所需要的代碼行 數(shù)并不相同；數(shù)并不相同

6、； 這種方法不適用于非過程語言。這種方法不適用于非過程語言。 為了克服代碼行技術(shù)的缺點，人們又提出了功為了克服代碼行技術(shù)的缺點，人們又提出了功 能點技術(shù)。能點技術(shù)。 功能點技術(shù)依據(jù)對軟件信息域特性和軟件復雜功能點技術(shù)依據(jù)對軟件信息域特性和軟件復雜 性的評估結(jié)果，估算軟件規(guī)模。性的評估結(jié)果，估算軟件規(guī)模。 這種方法用功能點（這種方法用功能點（Function Point, FP）為單）為單 位度量軟件規(guī)模。位度量軟件規(guī)模。 13.1.2 功能點技術(shù)功能點技術(shù) 1. 信息域特性信息域特性 功能點技術(shù)定義了信息域的功能點技術(shù)定義了信息域的5個特性，分別是個特性，分別是: 輸入項數(shù)輸入項數(shù) (Inp)

7、、 輸出項數(shù)輸出項數(shù) (Out)、 查詢數(shù)查詢數(shù) (Inq)、 主文件數(shù)主文件數(shù) (Maf) 外部接口數(shù)外部接口數(shù) (Inf)。 2. 估算功能點的步驟估算功能點的步驟 用下述用下述3個步驟，可估算出一個軟件的功能點數(shù)個步驟，可估算出一個軟件的功能點數(shù) （即軟件規(guī)模）。（即軟件規(guī)模）。 （1） 計算未調(diào)整的功能點數(shù)計算未調(diào)整的功能點數(shù)UFP 把每個特性把每個特性(即即Inp、Out、Inq、Maf和和Inf)都分都分 類為簡單級、平均級或復雜級類為簡單級、平均級或復雜級. 并根據(jù)其等級為每個特性分配一個功能點數(shù)并根據(jù)其等級為每個特性分配一個功能點數(shù) 例如例如: 一個簡單級的輸入項分配一個簡單級

8、的輸入項分配3個功能點，個功能點， 一個平均級的輸入項分配一個平均級的輸入項分配4個功能點，個功能點， 而一個復雜級的輸入項分配而一個復雜級的輸入項分配6個功能點。個功能點。 用下式計算未調(diào)整的功能點數(shù)用下式計算未調(diào)整的功能點數(shù)UFP： UFP=a1Inp+a2Out+a3Inq+a4Maf+a5Inf 其中，其中，ai (1i5)是信息域特性系數(shù)，其值由相應(yīng)是信息域特性系數(shù)，其值由相應(yīng) 特性的復雜級別決定，如表特性的復雜級別決定，如表13.1所示。所示。 輸入項數(shù)輸入項數(shù) (Inp)、 輸出項數(shù)輸出項數(shù) (Out)、 查詢數(shù)查詢數(shù) (Inq)、 主文件數(shù)主文件數(shù) (Maf) 、 外部接口數(shù)外

9、部接口數(shù) (Inf) 。 (2) 計算技術(shù)復雜性因子計算技術(shù)復雜性因子TCF 這一步驟度量這一步驟度量14種技術(shù)因素對軟件規(guī)模的影響種技術(shù)因素對軟件規(guī)模的影響 程度。程度。 在表在表13.2中列出了全部技術(shù)因素中列出了全部技術(shù)因素. 為每個因素分配一個從為每個因素分配一個從0（對軟件規(guī)模無影響）（對軟件規(guī)模無影響） 到到5（有很大影響）的值。（有很大影響）的值。 計算技術(shù)因素對軟件規(guī)模的計算技術(shù)因素對軟件規(guī)模的綜合影響程度綜合影響程度DI： DI= 14 1i i F 技術(shù)復雜性因子技術(shù)復雜性因子TCF由下式計算：由下式計算： TCF=0.65+0.01DI 因為因為DI的值在的值在070之間

10、，所以之間，所以TCF的值在的值在 0.651.35之間。之間。 （3） 計算功能點數(shù)計算功能點數(shù)FP FP=UFPTCF 功能點數(shù)功能點數(shù)= 未調(diào)整的功能點數(shù)未調(diào)整的功能點數(shù) X 技術(shù)復雜性因子技術(shù)復雜性因子 功能點數(shù)與所用的編程語言無關(guān)，看起來功能功能點數(shù)與所用的編程語言無關(guān)，看起來功能 點技術(shù)比代碼行技術(shù)更合理一些。點技術(shù)比代碼行技術(shù)更合理一些。 功能點功能點 代碼行代碼行 粗略換算粗略換算 使用由經(jīng)驗導出的公式來預測軟件開發(fā)工作量，使用由經(jīng)驗導出的公式來預測軟件開發(fā)工作量， 工作量是軟件規(guī)模（千行代碼數(shù)工作量是軟件規(guī)模（千行代碼數(shù)KLOC或功能點數(shù)或功能點數(shù) FP）的函數(shù)，工作量的單位

11、通常是人月（）的函數(shù)，工作量的單位通常是人月（pm)。 支持大多數(shù)估算模型的經(jīng)驗數(shù)據(jù)，都是從有限個支持大多數(shù)估算模型的經(jīng)驗數(shù)據(jù)，都是從有限個 項目的樣本集中總結(jié)出來的，因此，沒有一個估算模項目的樣本集中總結(jié)出來的，因此，沒有一個估算模 型可以適用于所有類型的軟件和開發(fā)環(huán)境。型可以適用于所有類型的軟件和開發(fā)環(huán)境。 13.2 工作量估算工作量估算 這類模型的總體結(jié)構(gòu)形式如下：這類模型的總體結(jié)構(gòu)形式如下： E=A+B(ev)C 其中，其中， A、B和和C是由經(jīng)驗數(shù)據(jù)導出的常數(shù)，是由經(jīng)驗數(shù)據(jù)導出的常數(shù)， E是以人月為單位的工作量，是以人月為單位的工作量， ev是估算變量（是估算變量（KLOC或或FP）

12、。）。 下面給出幾個典型的靜態(tài)單變量模型。下面給出幾個典型的靜態(tài)單變量模型。 13.2.1 靜態(tài)單變量模型靜態(tài)單變量模型 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模型（在模型（在KLOC9時適用）時適用） E=5.288(KLOC)1.047 2. 面向面向FP的估算模型的估算模型 (1) Albrecht 組員間關(guān)系密切組員間關(guān)系密切,能夠互相學

13、習等等。能夠互相學習等等。 民主制程序員組雖然名義上有一個組長，但民主制程序員組雖然名義上有一個組長，但 是他和組內(nèi)其他成員完成同樣的任務(wù)。是他和組內(nèi)其他成員完成同樣的任務(wù)。 在小組中，由全體討論協(xié)商決定應(yīng)該完成的在小組中，由全體討論協(xié)商決定應(yīng)該完成的 工作，并且根據(jù)每個人的能力和經(jīng)驗分配適當?shù)娜喂ぷ?，并且根?jù)每個人的能力和經(jīng)驗分配適當?shù)娜?務(wù)。務(wù)。 主要優(yōu)點是，組員們對發(fā)現(xiàn)程序錯誤持積極的主要優(yōu)點是，組員們對發(fā)現(xiàn)程序錯誤持積極的 態(tài)度，這種態(tài)度有助于更快速地發(fā)現(xiàn)錯誤，從而導態(tài)度，這種態(tài)度有助于更快速地發(fā)現(xiàn)錯誤，從而導 致高質(zhì)量的代碼。致高質(zhì)量的代碼。 民主制程序員組的另一個優(yōu)點是，組員們享民

14、主制程序員組的另一個優(yōu)點是，組員們享 有充分民主，小組有高度凝聚力，組內(nèi)學術(shù)空氣濃有充分民主，小組有高度凝聚力，組內(nèi)學術(shù)空氣濃 厚，有利于攻克技術(shù)難關(guān)。厚，有利于攻克技術(shù)難關(guān)。 因此，當有難題需要解決時，也就是說，當因此，當有難題需要解決時，也就是說，當 所要開發(fā)的軟件的技術(shù)難度較高時，采用民主制程所要開發(fā)的軟件的技術(shù)難度較高時，采用民主制程 序員組是適宜的。序員組是適宜的。 如果組內(nèi)多數(shù)成員是經(jīng)驗豐富技術(shù)熟練的程序如果組內(nèi)多數(shù)成員是經(jīng)驗豐富技術(shù)熟練的程序 員員,那么上述非正式的組織方式可能會非常成功。那么上述非正式的組織方式可能會非常成功。 但是但是,如果組內(nèi)多數(shù)成員技術(shù)水平不高如果組內(nèi)多數(shù)

15、成員技術(shù)水平不高,那么這那么這 種非正式的組織方式也有嚴重缺點：種非正式的組織方式也有嚴重缺點： 由于沒有明確的權(quán)威指導開發(fā)工程的進行由于沒有明確的權(quán)威指導開發(fā)工程的進行,組組 員間將缺乏必要的協(xié)調(diào)員間將缺乏必要的協(xié)調(diào),最終可能導致工程失敗。最終可能導致工程失敗。 美國美國IBM公司在公司在20世紀世紀70年代初期開始采用主年代初期開始采用主 程序員組的組織方式。采用這種組織方式主要出于程序員組的組織方式。采用這種組織方式主要出于 下述幾點考慮：下述幾點考慮： (1) 軟件開發(fā)人員多數(shù)比較缺乏經(jīng)驗；軟件開發(fā)人員多數(shù)比較缺乏經(jīng)驗； (2) 程序設(shè)計過程中有許多事務(wù)性的工作，例如，程序設(shè)計過程中有

16、許多事務(wù)性的工作，例如， 大量信息的存儲和更新；大量信息的存儲和更新； (3) 多渠道通信很費時間，將降低程序員的生產(chǎn)率。多渠道通信很費時間，將降低程序員的生產(chǎn)率。 13.4.2 主程序員組主程序員組 主程序員組用經(jīng)驗多、技術(shù)好、能力強的程序主程序員組用經(jīng)驗多、技術(shù)好、能力強的程序 員作為主程序員，同時，利用人和計算機在事務(wù)性員作為主程序員，同時，利用人和計算機在事務(wù)性 工作方面給主程序員提供充分支持，而且所有通信工作方面給主程序員提供充分支持，而且所有通信 都通過一兩個人進行。都通過一兩個人進行。 這種組織方式類似于外科手術(shù)小組的組織：這種組織方式類似于外科手術(shù)小組的組織： 主刀大夫?qū)κ中g(shù)全

17、面負責，并且完成制訂手術(shù)方案、主刀大夫?qū)κ中g(shù)全面負責，并且完成制訂手術(shù)方案、 開刀等關(guān)鍵工作，同時又有麻醉師、護士長等技術(shù)開刀等關(guān)鍵工作，同時又有麻醉師、護士長等技術(shù) 熟練的專門人員協(xié)助和配合他的工作。熟練的專門人員協(xié)助和配合他的工作。 圖圖13.5 主程序員組的結(jié)構(gòu)主程序員組的結(jié)構(gòu) 主程序員組核心人員的分工如下所述：主程序員組核心人員的分工如下所述： （1） 主程序員既是成功的管理人員又是經(jīng)驗豐富、主程序員既是成功的管理人員又是經(jīng)驗豐富、 技術(shù)好、能力強的高級程序員，負責體系結(jié)構(gòu)設(shè)計技術(shù)好、能力強的高級程序員，負責體系結(jié)構(gòu)設(shè)計 和關(guān)鍵部分（或復雜部分）的詳細設(shè)計，并且負責和關(guān)鍵部分（或復雜部

18、分）的詳細設(shè)計，并且負責 指導其他程序員完成詳細設(shè)計和編碼工作。指導其他程序員完成詳細設(shè)計和編碼工作。 程序員之間沒有通信渠道，所有接口問題都由程序員之間沒有通信渠道，所有接口問題都由 主程序員處理。主程序員處理。 主程序員對每行代碼的質(zhì)量負責，因此，他還主程序員對每行代碼的質(zhì)量負責，因此，他還 要對組內(nèi)其他成員的工作成果進行復查。要對組內(nèi)其他成員的工作成果進行復查。 （2） 后備程序員也應(yīng)該技術(shù)熟練而且富于經(jīng)驗，后備程序員也應(yīng)該技術(shù)熟練而且富于經(jīng)驗， 他協(xié)助主程序員工作并且在必要時（例如，主程序他協(xié)助主程序員工作并且在必要時（例如，主程序 員生病、出差或員生病、出差或“跳槽跳槽”）接替主程序

19、員的工作。）接替主程序員的工作。 平時，后備程序員的工作主要是，設(shè)計測試方平時，后備程序員的工作主要是，設(shè)計測試方 案、分析測試結(jié)果及獨立于設(shè)計過程的其他工作。案、分析測試結(jié)果及獨立于設(shè)計過程的其他工作。 （3） 編程秘書負責完成與項目有關(guān)的全部事務(wù)性編程秘書負責完成與項目有關(guān)的全部事務(wù)性 工作，例如，維護項目資料庫和項目文檔，編譯、工作，例如，維護項目資料庫和項目文檔，編譯、 鏈接、執(zhí)行源程序和測試用例。鏈接、執(zhí)行源程序和測試用例。 主程序員組的組織方式主程序員組的組織方式 在許多方面卻是不切實際的。在許多方面卻是不切實際的。 1. 主程序員應(yīng)該是高級程序員和優(yōu)秀管理者的結(jié)合體。主程序員應(yīng)該

20、是高級程序員和優(yōu)秀管理者的結(jié)合體。 承擔主程序員工作需要同時具備這兩方面的才能，承擔主程序員工作需要同時具備這兩方面的才能， 但是，在現(xiàn)實社會中這樣的人才并不多見。但是，在現(xiàn)實社會中這樣的人才并不多見。 2. 后備程序員更難找。人們期望后備程序員像主程后備程序員更難找。人們期望后備程序員像主程 序員一樣優(yōu)秀，但是，他們必須坐在序員一樣優(yōu)秀，但是，他們必須坐在“替補席替補席”上，上， 拿著較低的工資。幾乎沒有一個高級程序員或高級拿著較低的工資。幾乎沒有一個高級程序員或高級 管理人員愿意接受這樣的工作。管理人員愿意接受這樣的工作。 3. 編程秘書也很難找到。編程秘書也很難找到。 專業(yè)的軟件技術(shù)人員

21、一般都厭煩日常的事務(wù)專業(yè)的軟件技術(shù)人員一般都厭煩日常的事務(wù) 性工作，但是，人們卻期望編程秘書整天只干這類性工作，但是，人們卻期望編程秘書整天只干這類 工作。工作。 我們需要一種更合理、更現(xiàn)實的組織程序員組我們需要一種更合理、更現(xiàn)實的組織程序員組 的方法，這種方法應(yīng)該能充分結(jié)合民主制程序員組的方法，這種方法應(yīng)該能充分結(jié)合民主制程序員組 和主程序員組的優(yōu)點，并且能用于實現(xiàn)更大規(guī)模的和主程序員組的優(yōu)點，并且能用于實現(xiàn)更大規(guī)模的 軟件產(chǎn)品。軟件產(chǎn)品。 民主制程序員組的一個主要優(yōu)點，是小組成員民主制程序員組的一個主要優(yōu)點，是小組成員 都對發(fā)現(xiàn)程序錯誤持積極、主動的態(tài)度。都對發(fā)現(xiàn)程序錯誤持積極、主動的態(tài)度

22、。 使用主程序員組時，主程序員對每行代碼的質(zhì)使用主程序員組時，主程序員對每行代碼的質(zhì) 量負責，因此，他必須參與所有代碼審查工作。量負責，因此，他必須參與所有代碼審查工作。 由于主程序員同時又是負責對小組成員進行評由于主程序員同時又是負責對小組成員進行評 價的管理員，他價的管理員，他 會把所發(fā)現(xiàn)的程序錯誤與小組成會把所發(fā)現(xiàn)的程序錯誤與小組成 員的工作業(yè)績聯(lián)系起來，從而造成小組成員出現(xiàn)不員的工作業(yè)績聯(lián)系起來，從而造成小組成員出現(xiàn)不 愿意發(fā)現(xiàn)錯誤的心理。愿意發(fā)現(xiàn)錯誤的心理。 13.4.3 現(xiàn)代程序員組現(xiàn)代程序員組 解決上述問題的方法是，取消主程序員的大部解決上述問題的方法是，取消主程序員的大部 分行

23、政管理工作。分行政管理工作。 實際的實際的“主程序員主程序員”應(yīng)該由兩個人共同擔任：應(yīng)該由兩個人共同擔任： 一個技術(shù)負責人，負責小組的技術(shù)活動；一個技術(shù)負責人，負責小組的技術(shù)活動； 一個行政負責人，負責非技術(shù)性事務(wù)的管理決策。一個行政負責人，負責非技術(shù)性事務(wù)的管理決策。 由于程序員組成員人數(shù)不宜過多，當軟件項目由于程序員組成員人數(shù)不宜過多，當軟件項目 規(guī)模較大時，應(yīng)該把程序員分成若干個小組。規(guī)模較大時，應(yīng)該把程序員分成若干個小組。 產(chǎn)品開發(fā)作為一個整體是在項目經(jīng)理的指導下產(chǎn)品開發(fā)作為一個整體是在項目經(jīng)理的指導下 進行的，程序員向他們的組長匯報工作，而組長則進行的，程序員向他們的組長匯報工作，而

24、組長則 向項目經(jīng)理匯報工作。向項目經(jīng)理匯報工作。 圖圖13.7 大型項目的技術(shù)管理組織結(jié)構(gòu)大型項目的技術(shù)管理組織結(jié)構(gòu) 另一種方法，是在合適的地方采用分散做決定另一種方法，是在合適的地方采用分散做決定 的方法，如圖的方法，如圖13.8所示。所示。 這樣做有利于形成暢通的通信渠道，充分發(fā)揮這樣做有利于形成暢通的通信渠道，充分發(fā)揮 每個程序員的積極性和主動性，每個程序員的積極性和主動性， 攻克技術(shù)難關(guān)。攻克技術(shù)難關(guān)。 圖圖13.8 包含分散決策的組織方式包含分散決策的組織方式 軟件質(zhì)量就是軟件質(zhì)量就是“軟件與明確地和隱含地定義的需軟件與明確地和隱含地定義的需 求相一致的程度求相一致的程度”。 這一定

25、義強調(diào)了下述的這一定義強調(diào)了下述的3個要點：個要點： （1） 與軟件需求不一致就是質(zhì)量不高。與軟件需求不一致就是質(zhì)量不高。 （2） 沒有遵守指定的開發(fā)標準，肯定會導致軟件質(zhì)沒有遵守指定的開發(fā)標準，肯定會導致軟件質(zhì) 量不高。量不高。 （3） 如果軟件不滿足隱含的需求（例如，軟件應(yīng)該如果軟件不滿足隱含的需求（例如，軟件應(yīng)該 是容易維護的）是容易維護的） ，那么軟件的質(zhì)量仍然是值得懷疑，那么軟件的質(zhì)量仍然是值得懷疑 的。的。 13.5 質(zhì)量保證質(zhì)量保證 13.5.1 軟件質(zhì)量軟件質(zhì)量 圖圖13.9 軟件質(zhì)量因素與產(chǎn)品活動的關(guān)系軟件質(zhì)量因素與產(chǎn)品活動的關(guān)系 軟件質(zhì)量保證（軟件質(zhì)量保證（software

26、 quality assurance,SQA） 措施主要有：措施主要有： 基于非執(zhí)行的測試（復審或評審），基于執(zhí)基于非執(zhí)行的測試（復審或評審），基于執(zhí) 行的測試（軟件測試）和程序正確性證明。行的測試（軟件測試）和程序正確性證明。 1. 復審復審主要用來保證在編碼之前各階段產(chǎn)生的文檔主要用來保證在編碼之前各階段產(chǎn)生的文檔 的質(zhì)量；的質(zhì)量； 2. 軟件測試軟件測試需要在程序編寫出來之后進行，它是保需要在程序編寫出來之后進行，它是保 證軟件質(zhì)量的最后一道防線；證軟件質(zhì)量的最后一道防線； 3. 正確性證明正確性證明使用數(shù)學方法嚴格驗證程序是否與對使用數(shù)學方法嚴格驗證程序是否與對 它的說明完全一致。它的

27、說明完全一致。 13.5.2 軟件質(zhì)量保證措施軟件質(zhì)量保證措施 1. 技術(shù)復審的必要性技術(shù)復審的必要性 正式技術(shù)復審的顯著優(yōu)點是，能夠較早發(fā)現(xiàn)軟正式技術(shù)復審的顯著優(yōu)點是，能夠較早發(fā)現(xiàn)軟 件錯誤，從而可防止錯誤被傳播到軟件過程的后續(xù)件錯誤，從而可防止錯誤被傳播到軟件過程的后續(xù) 階段。階段。 正式技術(shù)復審在發(fā)現(xiàn)規(guī)格說明錯誤和設(shè)計錯誤正式技術(shù)復審在發(fā)現(xiàn)規(guī)格說明錯誤和設(shè)計錯誤 方面的有效性高達方面的有效性高達75%。 由于能夠檢測出并排除掉絕大部分這類錯誤，由于能夠檢測出并排除掉絕大部分這類錯誤， 復審可大大降低后續(xù)開發(fā)和維護階段的成本。復審可大大降低后續(xù)開發(fā)和維護階段的成本。 2.測試測試 測試可以

28、暴露程序中的錯誤，但是，測試只能測試可以暴露程序中的錯誤，但是，測試只能 證明程序中有錯誤，并不能證明程序中沒有錯誤。證明程序中有錯誤，并不能證明程序中沒有錯誤。 因此，對于保證軟件可靠性來說，測試是一種因此，對于保證軟件可靠性來說，測試是一種 不完善的技術(shù)。不完善的技術(shù)。 3. 程序正確性證明程序正確性證明 一旦研究出實用的正確性證明程序一旦研究出實用的正確性證明程序(即，能自動即，能自動 證明其他程序的正確性的程序證明其他程序的正確性的程序)，軟件可靠性將更有，軟件可靠性將更有 保證，測試工作量將大大減少。保證，測試工作量將大大減少。 目前已經(jīng)研究出證明目前已經(jīng)研究出證明PASCAL和和L

29、ISP程序正確程序正確 性的程序系統(tǒng)，正在對這些系統(tǒng)進行評價和改進。性的程序系統(tǒng)，正在對這些系統(tǒng)進行評價和改進。 隨著時間推移客戶的需求也會發(fā)生變化。隨著時間推移客戶的需求也會發(fā)生變化。 在設(shè)計過程會發(fā)現(xiàn)需求說明書中的問題，在實在設(shè)計過程會發(fā)現(xiàn)需求說明書中的問題，在實 現(xiàn)過程又會暴露出設(shè)計中的錯誤，現(xiàn)過程又會暴露出設(shè)計中的錯誤，。 因此，在開發(fā)軟件的過程中，變化是不可避免因此，在開發(fā)軟件的過程中，變化是不可避免 的。的。 但是，變化也很容易失去控制，如果不能適當?shù)?，變化也很容易失去控制，如果不能適當 地控制和管理變化，勢必造成混亂并產(chǎn)生許多嚴重地控制和管理變化，勢必造成混亂并產(chǎn)生許多嚴重 的

30、錯誤。的錯誤。 13.6 軟件配置管理軟件配置管理 1. 軟件配置項軟件配置項 軟件過程的輸出信息可以分為軟件過程的輸出信息可以分為3類：類： 計算機程序（源代碼和可執(zhí)行程序）；計算機程序（源代碼和可執(zhí)行程序）； 描述計算機程序的文檔（供技術(shù)人員或用戶使描述計算機程序的文檔（供技術(shù)人員或用戶使 用）；用）； 數(shù)據(jù)（程序內(nèi)包含的或在程序外的）。數(shù)據(jù)（程序內(nèi)包含的或在程序外的）。 上述這些項組成了在軟件過程中產(chǎn)生的全部信上述這些項組成了在軟件過程中產(chǎn)生的全部信 息，我們把它們統(tǒng)稱為軟件配置，而這些項就是軟息，我們把它們統(tǒng)稱為軟件配置，而這些項就是軟 件配置項。件配置項。 13.6.1 軟件配置軟件

31、配置 2. 基線基線 基線是一個軟件配置管理概念。基線是一個軟件配置管理概念。 IEEE把基線定義為：把基線定義為： 已經(jīng)通過了正式復審的已經(jīng)通過了正式復審的 規(guī)格說明或中間產(chǎn)品，它可以作為進一步開發(fā)的基規(guī)格說明或中間產(chǎn)品，它可以作為進一步開發(fā)的基 礎(chǔ)，并且只有通過正式的變化控制過程才能改變它。礎(chǔ)，并且只有通過正式的變化控制過程才能改變它。 簡而言之，基線就是通過了正式復審的軟件簡而言之，基線就是通過了正式復審的軟件 配置項。配置項。 除了軟件配置項之外，許多軟件工程組織也把除了軟件配置項之外，許多軟件工程組織也把 軟件工具置于配置管理之下，也就是說，把特定版軟件工具置于配置管理之下，也就是說

32、，把特定版 本的編輯器、編譯器和其他本的編輯器、編譯器和其他CASE工具，作為軟件工具，作為軟件 配置的一部分配置的一部分“固定固定”下來。下來。 因為當修改軟件配置項時必然要用到這些工因為當修改軟件配置項時必然要用到這些工 具，為防止不同版本的工具產(chǎn)生的結(jié)果不同，應(yīng)該具，為防止不同版本的工具產(chǎn)生的結(jié)果不同，應(yīng)該 把軟件工具也基線化，并且列入到綜合的配置管理把軟件工具也基線化，并且列入到綜合的配置管理 過程之中。過程之中。 軟件配置管理是軟件質(zhì)量保證的重要一環(huán)，它軟件配置管理是軟件質(zhì)量保證的重要一環(huán)，它 的主要任務(wù)是控制變化，同時也負責各個軟件配置的主要任務(wù)是控制變化，同時也負責各個軟件配置

33、項和軟件各種版本的標識、審計以及對軟件配置發(fā)項和軟件各種版本的標識、審計以及對軟件配置發(fā) 生的任何變化的報告。生的任何變化的報告。 軟件配置管理主要有軟件配置管理主要有5項任務(wù)：項任務(wù)： 標識、版本控制、變化控制、配置審計和報告。標識、版本控制、變化控制、配置審計和報告。 13.6.2 軟件配置管理過程軟件配置管理過程 配置狀態(tài)變化對大型軟件開發(fā)項目的成功有重配置狀態(tài)變化對大型軟件開發(fā)項目的成功有重 大影響。大影響。 當大量人員在一起工作時，可能一個人并不知道當大量人員在一起工作時，可能一個人并不知道 另一個人在做什么。兩名開發(fā)人員可能試圖按照相另一個人在做什么。兩名開發(fā)人員可能試圖按照相 互

34、沖突的想法去修改同一個軟件配置項；互沖突的想法去修改同一個軟件配置項； 軟件工程隊伍可能耗費幾個人月的工作量根據(jù)軟件工程隊伍可能耗費幾個人月的工作量根據(jù) 過時的硬件規(guī)格說明開發(fā)軟件；過時的硬件規(guī)格說明開發(fā)軟件； 察覺到所建議的修改有嚴重副作用的人可能還察覺到所建議的修改有嚴重副作用的人可能還 不知道該項修改正在進行。不知道該項修改正在進行。 配置狀態(tài)報告通過改善所有相關(guān)人員之間的通配置狀態(tài)報告通過改善所有相關(guān)人員之間的通 信，幫助消除這些問題。信，幫助消除這些問題。 美國卡內(nèi)基梅隆大學軟件工程研究所在美國國美國卡內(nèi)基梅隆大學軟件工程研究所在美國國 防部資助下于防部資助下于20世紀世紀80年代末

35、建立的能力成熟度模年代末建立的能力成熟度模 型（型（capability maturity model，CMM)，是用于評，是用于評 價軟件機構(gòu)的軟件過程能力成熟度的模型。價軟件機構(gòu)的軟件過程能力成熟度的模型。 最初，建立此模型的目的主要是，為大型軟件最初，建立此模型的目的主要是，為大型軟件 項目的招投標活動提供一種全面而客觀的評審依據(jù)，項目的招投標活動提供一種全面而客觀的評審依據(jù)， 發(fā)展到后來，此模型又同時被應(yīng)用于許多軟件機構(gòu)發(fā)展到后來，此模型又同時被應(yīng)用于許多軟件機構(gòu) 內(nèi)部的過程改進活動中。內(nèi)部的過程改進活動中。 13.7 能力成熟度模型能力成熟度模型 多年來，軟件危機一直困擾著許多軟件開

36、發(fā)機多年來，軟件危機一直困擾著許多軟件開發(fā)機 構(gòu)。人們進一步考察軟件過程，從而發(fā)現(xiàn)關(guān)鍵問題構(gòu)。人們進一步考察軟件過程，從而發(fā)現(xiàn)關(guān)鍵問題 在于對軟件過程的管理不盡人意。在于對軟件過程的管理不盡人意。 事實證明，在無規(guī)則和混亂的管理之下，先進事實證明，在無規(guī)則和混亂的管理之下，先進 的技術(shù)和工具并不能發(fā)揮出應(yīng)有的作用。的技術(shù)和工具并不能發(fā)揮出應(yīng)有的作用。 能力成熟度模型的基本思想是，由于問題是由能力成熟度模型的基本思想是，由于問題是由 我們管理軟件過程的方法不當引起的，所以新軟件我們管理軟件過程的方法不當引起的，所以新軟件 技術(shù)的運用并不會自動提高軟件的生產(chǎn)率和質(zhì)量。技術(shù)的運用并不會自動提高軟件的

37、生產(chǎn)率和質(zhì)量。 能力成熟度模型有助于軟件開發(fā)機構(gòu)建立一個能力成熟度模型有助于軟件開發(fā)機構(gòu)建立一個 有規(guī)律的、成熟的軟件過程。有規(guī)律的、成熟的軟件過程。 改進后的軟件過程將開發(fā)出質(zhì)量更好的軟件，改進后的軟件過程將開發(fā)出質(zhì)量更好的軟件， 使更多的軟件項目免受時間和費用超支之苦。使更多的軟件項目免受時間和費用超支之苦。 CMM把軟件過程從無序到有序的進化過程分把軟件過程從無序到有序的進化過程分 成成5個階段。這個階段。這5個成熟度等級定義了一個有序的尺個成熟度等級定義了一個有序的尺 度，用以測量軟件機構(gòu)的軟件過程成熟度和評價其度，用以測量軟件機構(gòu)的軟件過程成熟度和評價其 軟件過程能力。軟件過程能力。

38、 從從“1級級”到到“5級級”，反映出一個軟件機構(gòu)為，反映出一個軟件機構(gòu)為 了達到從一個無序的、混亂的軟件過程進化到一種了達到從一個無序的、混亂的軟件過程進化到一種 有序的、有紀律的且成熟的軟件過程的目的，必須有序的、有紀律的且成熟的軟件過程的目的，必須 經(jīng)歷的過程改進活動的途徑。經(jīng)歷的過程改進活動的途徑。 能力成熟度的能力成熟度的5個等級從低到高依次是：個等級從低到高依次是： 初始級初始級 （又稱為（又稱為1級），級）， 可重復級可重復級 （又稱為（又稱為2級），級）， 已定義級已定義級 （又稱為（又稱為3級），級）， 已管理級已管理級 （又稱為（又稱為4級）級） 優(yōu)化級優(yōu)化級 （又稱為（又

39、稱為5級）。級）。 1. 初始級初始級 軟件過程的特征是無序的，有時甚至是混亂軟件過程的特征是無序的，有時甚至是混亂 的。幾乎沒有什么過程是經(jīng)過定義的（即沒有一個的。幾乎沒有什么過程是經(jīng)過定義的（即沒有一個 定型的過程模型），項目能否成功完全取決于開發(fā)定型的過程模型），項目能否成功完全取決于開發(fā) 人員的個人能力。人員的個人能力。 處于處于1級成熟度的軟件機構(gòu)，其過程能力是不級成熟度的軟件機構(gòu)，其過程能力是不 可預測的，其軟件過程是不穩(wěn)定的，產(chǎn)品質(zhì)量只能可預測的，其軟件過程是不穩(wěn)定的，產(chǎn)品質(zhì)量只能 根據(jù)相關(guān)人員的個人工作能力而不是軟件機構(gòu)的過根據(jù)相關(guān)人員的個人工作能力而不是軟件機構(gòu)的過 程能力來

40、預測。程能力來預測。 2. 可重復級可重復級 軟件機構(gòu)建立了基本的項目管理過程軟件機構(gòu)建立了基本的項目管理過程(過程模過程模 型型),可跟蹤成本、進度、功能和質(zhì)量?？筛櫝杀?、進度、功能和質(zhì)量。 對新項目的策劃和管理過程是基于以前類似對新項目的策劃和管理過程是基于以前類似 項目的實踐經(jīng)驗，使得有類似應(yīng)用經(jīng)驗的軟件項目項目的實踐經(jīng)驗，使得有類似應(yīng)用經(jīng)驗的軟件項目 能夠再次取得成功。能夠再次取得成功。 處于處于2級成熟度的軟件機構(gòu)已經(jīng)為一個有紀律級成熟度的軟件機構(gòu)已經(jīng)為一個有紀律 的管理過程提供了可重復以前成功實踐的項目環(huán)境。的管理過程提供了可重復以前成功實踐的項目環(huán)境。 3. 已定義級已定義級

41、軟件機構(gòu)已經(jīng)定義了完整的軟件過程（過程模軟件機構(gòu)已經(jīng)定義了完整的軟件過程（過程模 型），軟件過程已經(jīng)文檔化和標準化。型），軟件過程已經(jīng)文檔化和標準化。 所有項目組都使用文檔化的、經(jīng)過批準的過程所有項目組都使用文檔化的、經(jīng)過批準的過程 來開發(fā)和維護軟件。來開發(fā)和維護軟件。 處于處于3級成熟度的軟件機構(gòu)，無論是管理活動級成熟度的軟件機構(gòu)，無論是管理活動 還是工程活動都是穩(wěn)定的。還是工程活動都是穩(wěn)定的。 軟件開發(fā)的成本和進度以及產(chǎn)品的功能和質(zhì)量軟件開發(fā)的成本和進度以及產(chǎn)品的功能和質(zhì)量 都受到控制，而且軟件產(chǎn)品的質(zhì)量具有可追溯性。都受到控制，而且軟件產(chǎn)品的質(zhì)量具有可追溯性。 4. 已管理級已管理級 軟

42、件機構(gòu)對軟件過程（過程模型和過程實例）軟件機構(gòu)對軟件過程（過程模型和過程實例） 和軟件產(chǎn)品都建立了定量的質(zhì)量目標，所有項目的和軟件產(chǎn)品都建立了定量的質(zhì)量目標，所有項目的 重要的過程活動都是可度量的。重要的過程活動都是可度量的。 處于處于4級成熟度的軟件機構(gòu)的軟件過程在可度量級成熟度的軟件機構(gòu)的軟件過程在可度量 的范圍內(nèi)運行。可以預期軟件產(chǎn)品是高質(zhì)量的。的范圍內(nèi)運行?？梢灶A期軟件產(chǎn)品是高質(zhì)量的。 5. 優(yōu)化級優(yōu)化級 這一級的軟件機構(gòu)是一個以防止出現(xiàn)缺陷為目這一級的軟件機構(gòu)是一個以防止出現(xiàn)缺陷為目 標的機構(gòu)，它有能力識別薄弱環(huán)節(jié)，并有足夠的手標的機構(gòu)，它有能力識別薄弱環(huán)節(jié)，并有足夠的手 段改進它們

43、。段改進它們。 可以對新技術(shù)進行成本可以對新技術(shù)進行成本/效益分析，并可以優(yōu)效益分析，并可以優(yōu) 化出在軟件工程實踐中能夠采用的最佳新技術(shù)?；鲈谲浖こ虒嵺`中能夠采用的最佳新技術(shù)。 處于處于5級成熟度的軟件機構(gòu)的軟件過程是可優(yōu)級成熟度的軟件機構(gòu)的軟件過程是可優(yōu) 化的。能夠?qū)ΜF(xiàn)行的過程實例不斷地改進和優(yōu)化，化的。能夠?qū)ΜF(xiàn)行的過程實例不斷地改進和優(yōu)化， 又借助于所采用的新技術(shù)和新方法來實現(xiàn)未來的過又借助于所采用的新技術(shù)和新方法來實現(xiàn)未來的過 程改進。程改進。 統(tǒng)計數(shù)字表明，提高一個完整的成熟度等級大統(tǒng)計數(shù)字表明，提高一個完整的成熟度等級大 約需要花約需要花18個月到個月到3年的時間，年的時間， 但

44、是從第但是從第1級上升到第級上升到第2級有時要花級有時要花3年甚至年甚至5年年 時間。時間。 這說明要向一個迄今仍處于混亂的和被動的行這說明要向一個迄今仍處于混亂的和被動的行 動方式的軟件機構(gòu)灌輸系統(tǒng)化的方式，將多么困難。動方式的軟件機構(gòu)灌輸系統(tǒng)化的方式，將多么困難。 軟件工程包括技術(shù)和管理兩方面的內(nèi)容，是技術(shù)與軟件工程包括技術(shù)和管理兩方面的內(nèi)容，是技術(shù)與 管理緊密結(jié)合的產(chǎn)物。只有在科學而嚴格的管理之管理緊密結(jié)合的產(chǎn)物。只有在科學而嚴格的管理之 下，先進的技術(shù)方法和優(yōu)秀的軟件工具才能真正發(fā)下，先進的技術(shù)方法和優(yōu)秀的軟件工具才能真正發(fā) 揮出威力。因此，有效的管理是大型軟件工程項目揮出威力。因此，

45、有效的管理是大型軟件工程項目 成功的關(guān)鍵。成功的關(guān)鍵。 軟件項目管理始于項目計劃，而第一項計劃活動就軟件項目管理始于項目計劃，而第一項計劃活動就 是估算。為了估算項目工作量和完成期限，首先需是估算。為了估算項目工作量和完成期限，首先需 要預測軟件規(guī)模。要預測軟件規(guī)模。 13.8 小結(jié)小結(jié) 度量軟件規(guī)模的常用技術(shù)主要有代碼行技術(shù)和功能度量軟件規(guī)模的常用技術(shù)主要有代碼行技術(shù)和功能 點技術(shù)。這兩種技術(shù)各有優(yōu)缺點，應(yīng)該根據(jù)項目特點技術(shù)。這兩種技術(shù)各有優(yōu)缺點，應(yīng)該根據(jù)項目特 點及從事計劃工作的人對這兩種技術(shù)的熟悉程度，點及從事計劃工作的人對這兩種技術(shù)的熟悉程度， 選用適用的技術(shù)。選用適用的技術(shù)。 根據(jù)軟

46、件規(guī)模可以估算出完成該項目所需的工作量，根據(jù)軟件規(guī)模可以估算出完成該項目所需的工作量， 常用的估算模型為靜態(tài)單變量模型、動態(tài)多變量模常用的估算模型為靜態(tài)單變量模型、動態(tài)多變量模 型和型和COCOMO2模型。為了使估算結(jié)果更接近實模型。為了使估算結(jié)果更接近實 際值，通常至少同時使用上述際值，通常至少同時使用上述3種模型中的兩種。種模型中的兩種。 通過比較和協(xié)調(diào)使用不同模型得出的估算值，有可通過比較和協(xié)調(diào)使用不同模型得出的估算值，有可 能得到比較準確的估算結(jié)果。成本估算模型通常也能得到比較準確的估算結(jié)果。成本估算模型通常也 同時提供了估算軟件開發(fā)時間的方程式，這樣估算同時提供了估算軟件開發(fā)時間的方

47、程式，這樣估算 出的開發(fā)時間是正常開發(fā)時間，經(jīng)驗表明，用增加出的開發(fā)時間是正常開發(fā)時間，經(jīng)驗表明，用增加 開發(fā)人員的方法最多可以把開發(fā)時間減少到正常開開發(fā)人員的方法最多可以把開發(fā)時間減少到正常開 發(fā)時間的發(fā)時間的75%。 管理者必須制定出一個足夠詳細的進度表，以便監(jiān)管理者必須制定出一個足夠詳細的進度表，以便監(jiān) 督項目進度并控制整個項目。常用的制定進度計劃督項目進度并控制整個項目。常用的制定進度計劃 的工具有的工具有Gantt圖和工程網(wǎng)絡(luò)，這兩種工具各有優(yōu)圖和工程網(wǎng)絡(luò)，這兩種工具各有優(yōu) 缺點，通常，聯(lián)合使用缺點，通常，聯(lián)合使用Gantt圖和工程網(wǎng)絡(luò)來制定圖和工程網(wǎng)絡(luò)來制定 進度計劃并監(jiān)督項目進展

48、狀況。進度計劃并監(jiān)督項目進展狀況。 高素質(zhì)的開發(fā)人員和合理的項目組組織結(jié)構(gòu)，是軟高素質(zhì)的開發(fā)人員和合理的項目組組織結(jié)構(gòu)，是軟 件項目取得成功的關(guān)鍵。比較典型的組織結(jié)構(gòu)有民件項目取得成功的關(guān)鍵。比較典型的組織結(jié)構(gòu)有民 主制程序員組、主程序員組和現(xiàn)代程序員組等主制程序員組、主程序員組和現(xiàn)代程序員組等3種，種， 這這3種組織方式的適用場合并不相同。種組織方式的適用場合并不相同。 軟件質(zhì)量保證是在軟件過程中的每一步都進行的活軟件質(zhì)量保證是在軟件過程中的每一步都進行的活 動。軟件質(zhì)量保證措施主要有基于非執(zhí)行的測試動。軟件質(zhì)量保證措施主要有基于非執(zhí)行的測試 （也稱為復審）、基于執(zhí)行的測試（即通常所說的（也

49、稱為復審）、基于執(zhí)行的測試（即通常所說的 測試）和程序正確性證明。軟件復審是最重要的軟測試）和程序正確性證明。軟件復審是最重要的軟 件質(zhì)量保證活動之一，它的優(yōu)點是在改正錯誤的成件質(zhì)量保證活動之一，它的優(yōu)點是在改正錯誤的成 本相對比較低時就能及時發(fā)現(xiàn)并排除軟件錯誤。本相對比較低時就能及時發(fā)現(xiàn)并排除軟件錯誤。 軟件配置管理是應(yīng)用于整個軟件過程中的保護性活軟件配置管理是應(yīng)用于整個軟件過程中的保護性活 動，是在軟件整個生命期內(nèi)管理變化的一組活動。動，是在軟件整個生命期內(nèi)管理變化的一組活動。 軟件配置管理的目標是，使變化能夠更正確且更容軟件配置管理的目標是，使變化能夠更正確且更容 易被適應(yīng)，在需要修改軟

50、件時減少為此而花費的工易被適應(yīng)，在需要修改軟件時減少為此而花費的工 作量。作量。 能力成熟度模型（能力成熟度模型（CMM）是改進軟件過程的有效）是改進軟件過程的有效 策略。它的基本思想是，因為問題是管理軟件過程策略。它的基本思想是，因為問題是管理軟件過程 的方法不恰當造成的，所以采用新技術(shù)并不會自動的方法不恰當造成的，所以采用新技術(shù)并不會自動 提高軟件生產(chǎn)率和軟件質(zhì)量，應(yīng)該下大力氣改進對提高軟件生產(chǎn)率和軟件質(zhì)量，應(yīng)該下大力氣改進對 軟件過程的管理。事實上對軟件過程的改進不可能軟件過程的管理。事實上對軟件過程的改進不可能 一蹴而就，因此，一蹴而就，因此，CMM以增量方式逐步引入變化，以增量方式逐

51、步引入變化， 它明確地定義了它明確地定義了5個成熟度等級，一個軟件開發(fā)組個成熟度等級，一個軟件開發(fā)組 織可以用一系列小的改良性步驟邁入更高的成熟度織可以用一系列小的改良性步驟邁入更高的成熟度 等級。等級。 13-1 研究本書研究本書2.4.2小節(jié)所述的定貨系統(tǒng)，要求：小節(jié)所述的定貨系統(tǒng)，要求： （1） 用代碼行技術(shù)估算本系統(tǒng)的規(guī)模；用代碼行技術(shù)估算本系統(tǒng)的規(guī)模； （2） 用功能點技術(shù)估算本系統(tǒng)的規(guī)模；用功能點技術(shù)估算本系統(tǒng)的規(guī)模； （3） 用靜態(tài)單變量模型估算開發(fā)本系統(tǒng)所需的工用靜態(tài)單變量模型估算開發(fā)本系統(tǒng)所需的工 作量；作量； （4） 假設(shè)由一個人開發(fā)本系統(tǒng)，請制定進度計劃；假設(shè)由一個人開發(fā)

52、本系統(tǒng)，請制定進度計劃； （5） 假設(shè)由兩個人開發(fā)本系統(tǒng)，請制定進度計劃。假設(shè)由兩個人開發(fā)本系統(tǒng)，請制定進度計劃。 習題習題 13-2 研究本書習題研究本書習題2第第2題中描述的儲蓄系統(tǒng)，要求：題中描述的儲蓄系統(tǒng)，要求： （1） 用代碼行技術(shù)估算本系統(tǒng)的規(guī)模；用代碼行技術(shù)估算本系統(tǒng)的規(guī)模； （2） 用功能點技術(shù)估算本系統(tǒng)的規(guī)模；用功能點技術(shù)估算本系統(tǒng)的規(guī)模； （3） 用靜態(tài)單變量模型估算開發(fā)本系統(tǒng)所需的工用靜態(tài)單變量模型估算開發(fā)本系統(tǒng)所需的工 作量；作量； （4） 假設(shè)由一個人開發(fā)本系統(tǒng)，請制定進度計劃；假設(shè)由一個人開發(fā)本系統(tǒng)，請制定進度計劃； （5） 假設(shè)由兩個人開發(fā)本系統(tǒng)，請制定進度計劃。假設(shè)由兩個人開發(fā)本系統(tǒng)，請制定進度計劃。 13-3 下面敘述對一個計算機輔助設(shè)計（下面敘述對一個計算機輔助設(shè)計（CAD）軟）軟 件的需求：件的需求： 該該CAD軟件接受由工程師提供的二維或三維幾何軟件接受由工程師提供的二維或三維幾何 圖形數(shù)據(jù)。工程師通過用戶界面與圖形數(shù)據(jù)。工程師通過用戶界面與CAD系統(tǒng)交互系統(tǒng)交互 并控制它，該用戶界面應(yīng)該表現(xiàn)出良好的人機界面并控制它，該用戶界面應(yīng)該表現(xiàn)出良好的人機界面 特征。幾何圖形數(shù)據(jù)及其他支持信息都保存在一個特征。幾何圖形數(shù)據(jù)及其他支持信息都保存在一個 CAD數(shù)據(jù)