【正文】 危機(jī)和大量的軟件項(xiàng)目失敗以后，人們發(fā)現(xiàn)正是一系列管理問題和技術(shù)問題導(dǎo)致了上述問題，終其原因，其一致原因可能就是：項(xiàng)目管理太弱。”人員管理成熟度模型為軟件人員定義了以下的關(guān)鍵實(shí)踐區(qū)域：招募、選擇、業(yè)績(jī)管理、培訓(xùn)、報(bào)酬、職業(yè)發(fā)展、組織和工作設(shè)計(jì)以及團(tuán)隊(duì)精神/企業(yè)文化培養(yǎng)。4） 客戶。 項(xiàng)目經(jīng)理的任務(wù)就是要對(duì)項(xiàng)目進(jìn)行全面的管理，具體表現(xiàn)在對(duì)項(xiàng)目目標(biāo)要有一個(gè)全局的觀點(diǎn)，并制定計(jì)劃，報(bào)告項(xiàng)目進(jìn)展，控制反饋，組建團(tuán)隊(duì)，在不確定環(huán)境下對(duì)不確定問題進(jìn)行決策，在必要的時(shí)候進(jìn)行談判及解決沖突。保證項(xiàng)目的整體性，保證項(xiàng)目在實(shí)施過程中自始至終以實(shí)現(xiàn)項(xiàng)目預(yù)期目標(biāo)為最終目的，由于項(xiàng)目在實(shí)施過程中存在各種各樣的沖突，項(xiàng)目經(jīng)理在解決項(xiàng)目的沖突過程中起著重要的作用，做到化解矛盾，平衡利害。 軟件項(xiàng)目組軟件項(xiàng)目組織結(jié)構(gòu)有多種，但軟件項(xiàng)目組織結(jié)構(gòu)是不能輕易改變。7） 項(xiàng)目所需要的社交性（通信）的程度。軟件開發(fā)者和客戶必須一起定義產(chǎn)品的目的和范圍。待建造的軟件如何適應(yīng)于大型的系統(tǒng)、產(chǎn)品或商業(yè)的語(yǔ)境，在該語(yǔ)境下要加什么約束？2） 信息目標(biāo)。簡(jiǎn)單講，就是將一個(gè)復(fù)雜的問題劃分成若干較易處理的小問題。項(xiàng)目組研究市場(chǎng)部與潛在客戶的交談并找出自動(dòng)復(fù)制編輯應(yīng)該具有下列功能：（1）拼寫檢查，（2）語(yǔ)句文法檢查，（3）大型文檔的參考書目關(guān)聯(lián)檢查（例如，對(duì)一本參考書的引用是否能在參考書目列表中找到？），（4）大型文檔中章節(jié)的參考書目關(guān)聯(lián)的確認(rèn)。軟件過程的一般性階段——定義、開發(fā)和支持——適用于所有軟件項(xiàng)目。l 形式化方法模型。l 風(fēng)險(xiǎn)分析——評(píng)估技術(shù)的及管理的風(fēng)險(xiǎn)所需要的任務(wù)。公共過程框架活動(dòng)軟件工程任務(wù)產(chǎn)品功能正文輸入編輯及格式設(shè)計(jì)自動(dòng)復(fù)制編輯頁(yè)面布局能力自動(dòng)建立索引及目錄文件管理文檔生成圖141 合并產(chǎn)品和過程 過程分解軟件項(xiàng)目組在選擇最適合項(xiàng)目的軟件工程范型以及選定的過程模型中所包含的軟件工程任務(wù)時(shí)，應(yīng)該有很大的靈活度。CPF是不變的，它充當(dāng)一個(gè)軟件組織所執(zhí)行的所有軟件工作的基礎(chǔ)。它們代表了適于小型的、相對(duì)簡(jiǎn)單的項(xiàng)目的一種過程分解。7） 評(píng)審每一份小規(guī)約，確認(rèn)其正確性、一致性和無二義性。有如下10個(gè)信號(hào)指示一個(gè)信息系統(tǒng)項(xiàng)目正處于危險(xiǎn)狀態(tài)之中：1） 軟件人員不了解他們的客戶的需要。9） 項(xiàng)目組缺乏具有合適技能的人員。3） 跟蹤進(jìn)展。評(píng)估計(jì)劃的和實(shí)際的進(jìn)度，收集和分析軟件項(xiàng)目度量，從項(xiàng)目組成員和客戶處獲取反饋，并記錄下所有發(fā)現(xiàn)。合理、精確的成本分析 風(fēng)險(xiǎn)分析 現(xiàn)代項(xiàng)目管理的優(yōu)勢(shì)在于引進(jìn)了風(fēng)險(xiǎn)分析技術(shù)，由于當(dāng)前許多項(xiàng)目不進(jìn)行風(fēng)險(xiǎn)分析就進(jìn)行開發(fā)，就存在了較大的項(xiàng)目風(fēng)險(xiǎn)，每當(dāng)在進(jìn)行一個(gè)軟件項(xiàng)目開發(fā)時(shí)，其人員、經(jīng)費(fèi)、進(jìn)度及用戶需求均存在著不確定的因素，如建立的軟件系統(tǒng)，其用戶需求是否確切地被理解，是否還存在有技術(shù)難題。 5) 定義的結(jié)果 每個(gè)任務(wù)都應(yīng)有一個(gè)目標(biāo)，軟件項(xiàng)目的目標(biāo)通常是一個(gè)工作產(chǎn)品（如一個(gè)模塊的設(shè)計(jì)）或某個(gè)工作產(chǎn)品的一部分，通常將多個(gè)工作產(chǎn)品組合成“可交付產(chǎn)品”。軟件工程的產(chǎn)品、過程資源都具有外部屬性和內(nèi)部屬性，外部屬性是面向管理者和用戶的屬性，體現(xiàn)了產(chǎn)品過程、資源與環(huán)境的關(guān)系，如成本、效益、程序員的生產(chǎn)率及軟件產(chǎn)品的可靠性、可用性、可維護(hù)性可移植性等。它們之間的關(guān)系如圖14－3所示圖14－3 軟件度量分類軟件生產(chǎn)率度量主要集中在軟件工程過程的輸出，軟件質(zhì)量度量可指明軟件滿足明確的和隱含的用戶需求的程度，技術(shù)度量主要集中在某些特征（如邏輯復(fù)雜性、模塊化程度）上，而不是軟件開發(fā)的全過程。在一個(gè)組織中，常用一個(gè)表格來記錄項(xiàng)目中面向規(guī)模的度量，如表14－1所示。其中確定了五個(gè)信息域特征，并在表中合適的位置提供計(jì)算。（3） 用戶查詢數(shù)。采用功能點(diǎn)方法的組織建立一個(gè)標(biāo)準(zhǔn)以確定某個(gè)特定的條目是簡(jiǎn)單的、平均的還是復(fù)雜的。l 每個(gè)功能點(diǎn)（FP）成本。特征點(diǎn)度量適用于算法復(fù)雜性較高的應(yīng)用。很多研究試圖將FP和LOC測(cè)量聯(lián)系起來?；诠δ茳c(diǎn)和LOC度量已被發(fā)現(xiàn)是軟件開發(fā)工作量和成本的相對(duì)精確的判定，然而，為了將LOC和FP用于估算，必須建立歷史的信息基線。因此，應(yīng)該對(duì)軟件質(zhì)量給出一個(gè)客觀的、科學(xué)的定義，并盡量予以量化。1968年，Rubey和Hartwick提出了軟件某些屬性的度量方法。它們之間的關(guān)系如圖14－6所示。（3） 可用性。各種軟件質(zhì)量要素之間的關(guān)系如表14－7所示。檢查軟件需求、規(guī)格說明、標(biāo)準(zhǔn)、過程、指令、代碼及合同是否一致的難易程度。軟件不丟失各重要成分，完全實(shí)現(xiàn)系統(tǒng)所需功能。系統(tǒng)在各種異常條件下提供繼續(xù)操作的能力。軟件同支持它運(yùn)行的硬件系統(tǒng)不相關(guān)的程度?？刂苹虮Ｗo(hù)程序和數(shù)據(jù)不受破壞的機(jī)制，以防止程序和數(shù)據(jù)受到意外的或蓄意的存取、使用、修改、毀壞或泄密?？稍谲浖臋n之間實(shí)現(xiàn)正向/逆向的追蹤能力。Grad和Caswell給出了以調(diào)查報(bào)告/規(guī)格說明、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試、支撐為行，以上述要素為列的5行5列矩陣，通過對(duì)矩陣元素的度量導(dǎo)出軟件開發(fā)過程和軟件產(chǎn)品能質(zhì)量要素的FURPS度量。它反映了軟件的可理解性、模塊性、簡(jiǎn)潔性等屬性。為不失一般性，假設(shè)圖中每個(gè)節(jié)點(diǎn)都可以由入口節(jié)點(diǎn)到達(dá)，并且從每個(gè)節(jié)點(diǎn)都可以到達(dá)出口節(jié)點(diǎn)。（e） e=6,n=5,v=3。操作符是由程序設(shè)計(jì)語(yǔ)言定義并在程序中出現(xiàn)的語(yǔ)法符號(hào)，如FORTRAN語(yǔ)言中的＋、－、*、/、IF、THEN、DO、END等。對(duì)某種程序設(shè)計(jì)語(yǔ)言，選用多個(gè)程序，計(jì)算并統(tǒng)計(jì)L的期望值I=E（L）≈。對(duì)于重要的計(jì)算機(jī)應(yīng)用系統(tǒng)，特別是實(shí)時(shí)、嵌入式計(jì)算機(jī)應(yīng)用系統(tǒng)，軟件可靠性關(guān)系到整個(gè)系統(tǒng)的成敗。這些故障可能來自硬件、軟件或人為因素。為了比較某一個(gè)程序在不同的時(shí)期或若干個(gè)程序在同一時(shí)期的可靠性，引入故障率是十分必要的。軟件錯(cuò)誤歸根結(jié)底是人的設(shè)計(jì)錯(cuò)誤，在復(fù)雜的計(jì)算機(jī)系統(tǒng)中，某些數(shù)據(jù)或某些指令的組合可能會(huì)引發(fā)程序邏輯錯(cuò)誤。有效函數(shù)定義為系統(tǒng)在時(shí)刻t正常運(yùn)行的概率。(1) 用n臺(tái)相同的計(jì)算機(jī)軟/硬件系統(tǒng)處理若干組相同或不同的輸入數(shù)據(jù)，如果發(fā)現(xiàn)某個(gè)計(jì)算機(jī)系統(tǒng)發(fā)生故障，則可以停機(jī)檢修，待修復(fù)后重新啟動(dòng)。微觀模型以程序的控制結(jié)構(gòu)和程序語(yǔ)句分析為基礎(chǔ)。事實(shí)上完全做到這一點(diǎn)是不現(xiàn)實(shí)的。繪出MTBF隨變化的曲線可以幫助分析軟件質(zhì)量的改進(jìn)程度。于是k的估算為 （公式14－25）當(dāng)m = 1時(shí) （公式14－26）當(dāng)m = 2時(shí) （公式14－27）利用公式14－24估算MTBF是的函數(shù)，隨著軟件測(cè)試、軟件維護(hù)工作的不斷深入，程序中殘留錯(cuò)誤不斷減少，故障率不斷降低，程序平均無故障時(shí)間不斷增加。人們常用的估算方法有如下四種：（1） 參照已經(jīng)完成的類似項(xiàng)目，估算待開發(fā)項(xiàng)目的成本和工作量。軟件項(xiàng)目代碼行和功能點(diǎn)估算是成本和工作量估算的基礎(chǔ)。分析7個(gè)子項(xiàng)目的規(guī)模復(fù)雜性和難度，參照以前開發(fā)類似項(xiàng)目的經(jīng)驗(yàn)，給出開發(fā)每行代碼的平均成本、每月開發(fā)的代碼行數(shù)。由于導(dǎo)出模型的數(shù)據(jù)是“從前的”、“局部的”，因此估算模型不可能適用于當(dāng)前所有的軟件項(xiàng)目和全部開發(fā)環(huán)境。 1） 基本CoCoMo模型基本CoCoMo模型是靜態(tài)、單變量模型，具有下列形式： E=a（L）b （公式14－30） D=cE4 （公式14－31）其中：E表示工作量，單位是人員（PM）；D表示開發(fā)時(shí)間，單位是月；L是項(xiàng)目的代碼行估計(jì)值，單位是千行代碼；a、b、c、d是常數(shù)，取值如表14－12所示。上述四種屬性共15個(gè)要素。在例3中，, CAD軟件開發(fā)屬于中等規(guī)模、半獨(dú)立型，從表14－11中查到a＝，b＝。嚴(yán)格地說，在軟件項(xiàng)目開發(fā)過程中，11個(gè)人不可能都有相同的能力和個(gè)性，也不可能有相同的經(jīng)驗(yàn)和知識(shí)結(jié)構(gòu)，并且在軟件開發(fā)的各個(gè)階段對(duì)人的要求也不同。正常情況下，F(xiàn)i＝1。Boehm把軟件劃分為組織型、半獨(dú)立型和嵌入型三類，允許不同應(yīng)用領(lǐng)域和復(fù)雜程度的軟件按照上述三類軟件的使用范圍選取相應(yīng)的參數(shù)a、b、c、d。本節(jié)和下一節(jié)分別介紹兩個(gè)常用的估算模型CoCoMo模型和Putnam模型。最后匯總的CAD軟件開發(fā)項(xiàng)目規(guī)模為33 360 LOC，成本為656 680美元。當(dāng)LOC或FP的期望值估算出來以后，根據(jù)以前軟件項(xiàng)目開發(fā)的平均生產(chǎn)率LOC/PM或FP/PM，就可以計(jì)算出工作量。（3） 將軟件項(xiàng)目按軟件生存周期分解，分別估算出軟件項(xiàng)目在軟件開發(fā)各個(gè)階段的工作量和成本，然后再把這些工作量和成本匯總，估算出整個(gè)項(xiàng)目的工作量和成本。當(dāng)然，對(duì)于大型軟件來說這是不現(xiàn)實(shí)的。設(shè)：為程序調(diào)試、排錯(cuò)時(shí)間， 為程序調(diào)試前殘留錯(cuò)誤總數(shù)， 為區(qū)間內(nèi)糾正的程序錯(cuò)誤數(shù)， 為程序在時(shí)刻殘留的錯(cuò)誤數(shù)， 為程序代碼長(zhǎng)度。他安排兩名程序測(cè)試員同時(shí)對(duì)一個(gè)程序進(jìn)行獨(dú)立測(cè)試。1) 錯(cuò)誤植入模型錯(cuò)誤植入模型用于估算程序中殘留的錯(cuò)誤，它借鑒了“估算池塘中魚尾數(shù)量的播種模型”。(2) 系統(tǒng)在穩(wěn)定運(yùn)行過程中，仔細(xì)地記錄一個(gè)程序運(yùn)行的有效時(shí)間和失效時(shí)間，則程序在穩(wěn)態(tài)運(yùn)行的有效性 （公式14－15）其中 ，(3) 當(dāng)系統(tǒng)處于穩(wěn)態(tài)時(shí)，程序正常運(yùn)行時(shí)間的平均值也是程序平均故障間隔時(shí)間(MTBF, mean time to failure)，程序平均停機(jī)時(shí)間也是程序平均修復(fù)時(shí)間(MTTR, mean time to repair)，于是系統(tǒng)穩(wěn)態(tài)時(shí)的程序有效性 （公式14－16）在上面介紹的三種有效性度量方法中，第一種方法最便于理解有效性概念，但在多數(shù)場(chǎng)合時(shí)不可行的；用第二種方法度量某個(gè)已經(jīng)投入運(yùn)行的程序系統(tǒng)的有效性比較容易；第三種方法可以用于軟件開發(fā)階段，軟件工程師在開發(fā)階段統(tǒng)計(jì)MTBF和MTTR的值。由此可看出有效性和可靠性的區(qū)別。從軟件可靠性的角度來看，存在著可修復(fù)系統(tǒng)和不可修復(fù)系統(tǒng)，在基于計(jì)算機(jī)的系統(tǒng)中，不允許程序停止運(yùn)行的系統(tǒng)稱為不可修復(fù)系統(tǒng)，如空中交通管理系統(tǒng)；反之，稱為可修復(fù)系統(tǒng)，如軟件開發(fā)環(huán)境中的各種軟件工具。 (2) ，其中k是常數(shù)，當(dāng)耗損或退化存在時(shí)，故障率將隨時(shí)間的流逝而線性增加，這種模型一般不適用于軟件產(chǎn)品。由于大型軟件是復(fù)雜的邏輯產(chǎn)品，采用枚舉技術(shù)不可能對(duì)程序運(yùn)行的所有路徑逐個(gè)進(jìn)行測(cè)試，投入使用的軟件很可能殘留一定數(shù)量的錯(cuò)誤?？煽啃苑治龊涂煽啃詼y(cè)試是衡量軟件質(zhì)量的重要手段。高級(jí)語(yǔ)言的程序級(jí)接近于1，低級(jí)語(yǔ)言的程序級(jí)接近于0。設(shè) n1 為程序中不同操作符的個(gè)數(shù)； n2為程序中不同操作數(shù)的個(gè)數(shù)； N1為程序中操作符的個(gè)數(shù)； N2為程序中操作數(shù)的個(gè)數(shù)。其次，在結(jié)構(gòu)化程序設(shè)計(jì)中求控制流從高層指向低層，如果出現(xiàn)從低層指向高層的流向，則會(huì)增加封閉區(qū)域的個(gè)數(shù)，于是，反方向的控制流向越多，程序結(jié)構(gòu)越復(fù)雜，V(G)越大。可以證明，V(G)等于結(jié)構(gòu)圖中有界或無界的封閉區(qū)域個(gè)數(shù)。人們一般認(rèn)為，軟件復(fù)雜性度量模型應(yīng)遵循下列基本原則：（1） 軟件復(fù)雜性與程序大小的關(guān)系不是線性的；（2） 控制結(jié)構(gòu)復(fù)雜的程序較復(fù)雜；（3） 數(shù)據(jù)結(jié)構(gòu)復(fù)雜的程序較復(fù)雜；（4） 轉(zhuǎn)向語(yǔ)句使用不當(dāng)?shù)某绦蜉^復(fù)雜；（5） 循環(huán)結(jié)構(gòu)比選擇結(jié)構(gòu)復(fù)雜，選擇結(jié)構(gòu)又比順序結(jié)構(gòu)復(fù)雜；（6） 語(yǔ)句、數(shù)據(jù)、子程序和模塊在程序中的次序?qū)?fù)雜性有影響；（7） 全程變量、非局部變量較多時(shí)，程序較復(fù)雜；（8） 參數(shù)按地址調(diào)用比按值調(diào)用復(fù)雜；（9） 函數(shù)副作用比顯式參數(shù)傳遞難于理解；（10） 具有不同作用的變量共用一個(gè)名字時(shí)較難理解。高層稱軟件質(zhì)量需求評(píng)價(jià)準(zhǔn)則（SQRC），中層稱軟件質(zhì)量設(shè)計(jì)評(píng)價(jià)準(zhǔn)則（SQDC），低層稱軟件質(zhì)量度量評(píng)價(jià)準(zhǔn)則（SQMC）。軟件支持新用戶使用該系統(tǒng)的能力。源代碼提供有意義文檔的程度。監(jiān)視程序的運(yùn)行，一旦發(fā)生錯(cuò)誤，標(biāo)識(shí)錯(cuò)誤的程度。程序運(yùn)行效率。程序源代碼的緊湊性。計(jì)算和控制的精度，是對(duì)無誤差程度的一種定量估計(jì)。例如，實(shí)時(shí)控制系統(tǒng)的可靠性、有效性是決定系統(tǒng)成敗的關(guān)鍵要素，必須全力保證，而軟件的可移植性、可重用性就不是主要的了；又如，設(shè)計(jì)通用的軟件工具對(duì)于可維護(hù)性、可移植性、可重用性應(yīng)該給予更多的注意，而有效性就不是影響系統(tǒng)成敗的關(guān)鍵要素了。圖14－6 McCall的軟件質(zhì)量要素（4） 靈活性。我們已介紹了軟件的可靠性、有效性、可維護(hù)性、可移植性和可重用性的概念。隨后，用于定量地評(píng)價(jià)軟件質(zhì)量。1983年，ADSI/IEEEstd729給出的軟件質(zhì)量定義是：軟件產(chǎn)品滿足規(guī)定的和隱含的與需求能力有關(guān)的全部特征和特性，包括如下幾方面：（1） 軟件產(chǎn)品質(zhì)量滿足用戶要求的程度。軟件開發(fā)人員、維護(hù)人員、管理人員和用戶都十分重視軟件的質(zhì)量。查看表可知，C++的一個(gè)LOC所提供的“功能性”（平均講）。為了計(jì)算特征點(diǎn)，還要進(jìn)行167。l 每人月完成的功能點(diǎn)（FP）數(shù)。我們采用下面的關(guān)系式計(jì)算功能點(diǎn)（FP）：FP=總計(jì)數(shù)值CT*（+*∑Fi）其中“總計(jì)數(shù)值”是從圖143得到的所有FP條目的總和。每一個(gè)不同的查詢都要計(jì)算。對(duì)每個(gè)用戶輸入進(jìn)行計(jì)數(shù)，它們向軟件提供不同的面向應(yīng)用的數(shù)據(jù)。 面向功能的度量面向功能度量是由Albrecht于1979年首先提出來的，他建議一種稱為功能點(diǎn)的測(cè)量。 面向規(guī)模的度量面向規(guī)模軟件度量是通過規(guī)范化質(zhì)量和/或生產(chǎn)率的測(cè)量而得到的，這些測(cè)量是基于所產(chǎn)生的軟件的“規(guī)?！薄＼浖獠繉傩栽谲浖_發(fā)過程中很難測(cè)量和控制，但它是由軟件的內(nèi)部屬性決定的，因此有必要研究軟件的內(nèi)部屬性與外部屬性之間的關(guān)系，并通過軟件內(nèi)部屬性度量解決軟件某些外部屬性的度量問題，從而建立軟件工程度量系統(tǒng)。 追蹤與控制 一旦適應(yīng)了項(xiàng)目開發(fā)計(jì)劃，就可以開始進(jìn)行項(xiàng)目追蹤和項(xiàng)目控制，一旦項(xiàng)目出現(xiàn)進(jìn)度/資源等變化，就需要對(duì)項(xiàng)目計(jì)劃進(jìn)行調(diào)整以利于更好地完成項(xiàng)目，最壞情況可以對(duì)項(xiàng)目的交付日期進(jìn)行修改。這些步驟貫徹于軟件工程過程中?？晒芾淼倪M(jìn)度安排從而，可在多個(gè)方案中選擇一個(gè)相對(duì)完善的方法，給