【正文】 2＋n2*） （公式14－3）令L＝V*/V，其值取決于具體的程序設(shè)計語言和程序。由于n1 n2 N1 N2相同的程序在控制結(jié)構(gòu)和數(shù)據(jù)復(fù)雜性等方面可能存在相當大的差異，程序員使用程序設(shè)計語言描述算法的水平和熟悉程度也有很大區(qū)別，因此Halstead的估算方法有一定的局限性。軟件除了不會出現(xiàn)磨損故障外，由其他幾種類似原因引發(fā)的故障都有可能出現(xiàn)。初始時刻程序工作正常，,于是，和滿足 （公式14－5） （公式14－6）從0時刻開始，到t1時刻為止，程序發(fā)生故障的概率由于同一時刻程序成功運行和發(fā)生故障是兩個互斥事件，所以[0,t]區(qū)間程序成功運行的概率和發(fā)生故障的概率滿足 （公式14－7）程序成功運行的概率就是可靠性，一般用標記。隨著歲月的流逝，由于機械磨損、腐蝕、化學(xué)變化等方面的原因，損耗型故障增加，直到硬件系統(tǒng)報廢。軟件修復(fù)時間是一個隨機變量，在可靠性分析過程中，為了簡單，經(jīng)常使用平均修復(fù)時間的概念。對于不可修復(fù)系統(tǒng)或沒有修理能力的部門，＝；對于允許修理并有一定修理能力的部門。這些模型可分為宏觀模型和微觀模型兩類。排錯工作進行數(shù)天之后，統(tǒng)計人員發(fā)現(xiàn)共查出n個錯誤，其中個屬于植入錯誤，于是公式14－18可以估算出程序的殘留錯誤。(1) 軟件故障率是常數(shù)。下面給出估算k的計算公式。在軟件項目立項和軟件項目管理工作中，客戶和項目管理人員都十分重視軟件項目的成本估算。為了實現(xiàn)軟件項目估算，實踐中開發(fā)了大量的軟件項目自動估算工具，用以支持軟件工作量或成本估算。將CAD項目按功能分解為如下7個子項目：（1） 用戶界面和控制；（2） 二維幾何分析；（3） 三維幾何分析；（4） 數(shù)據(jù)庫管理；（5） 計算機圖形顯示；（6） 外設(shè)控制；（7） 設(shè)計分析。兩種方法估算的工作量和成本基本一致。基本CoCoMo模型用于系統(tǒng)開發(fā)的初期，估算整個系統(tǒng)的工作量（包括軟件維護）和軟件開發(fā)所需要的時間，中間CoCoMo模型用于估算各個子系統(tǒng)的工作量和開發(fā)時間，詳細CoCoMo模型用于估算獨立的軟部件，如子系統(tǒng)內(nèi)部的各個模塊。計算機屬性包括程序執(zhí)行時間、程序占用內(nèi)存的大小、軟件開發(fā)環(huán)境的變化以及軟件開發(fā)環(huán)境的響應(yīng)速度。使用中間CoCoMo模型不僅可以估算開發(fā)軟件產(chǎn)品的工作量，而且還可以比較各種開發(fā)方案對工作量的影響。一般說來，由N個程序員組成的小組，實現(xiàn)相同規(guī)模的程序，相互通信數(shù)為＝N（N－1）/2，設(shè)每次通信和交換意見的平均工作量為，則增加的通信開銷為 EC=N（N－1）/2 (公式14－32)【例4】計算3人和5人開發(fā)一個程序的通信開銷。當15個Fi的值選定后，EAF的計算如下：EAF=Fi調(diào)節(jié)因子集的定義和調(diào)節(jié)因子定值是由統(tǒng)計結(jié)果和經(jīng)驗決定的。表a、b取值表工作量調(diào)節(jié)因子與軟件產(chǎn)品屬性、計算機屬性、人員屬性和項目屬性有關(guān)。它是在靜態(tài)、單變量模型的基礎(chǔ)上構(gòu)造出來的。相差5％左右。如果當前估算的軟件子項目比以前完成的項目復(fù)雜，那么所用的生產(chǎn)率值可以低于平均生產(chǎn)率，反之也可以高于平均生產(chǎn)率。上述四種方法可以同時或組合使用，以便取長補短、互相參考，提高項目估算的精度和可靠性。以小時計，表示程序運行時間。利用、的定義和公式14－23可以計算出的值。與公式14－17類比，有 （公式14－19）于是，程序中殘留錯誤的估計值可用下式計算 （公式14－20）用Hyman的改進方法估算程序的殘留錯誤，無論技術(shù)上還是經(jīng)濟上都比原始的錯誤植入模型優(yōu)越。當帶標記和不帶標記的魚隨機、均勻地混雜在一起之后，撈出n條，其中帶有標記的魚條，于是母體N與的關(guān)系和字樣n與的關(guān)系滿足 （公式14－17）由公式14－17得出母體N的估算值 （公式14－18）Mills首先將播種模型用于程序中殘留錯誤的估算，稱為錯誤植入模型。軟件系統(tǒng)投入運行后，在某一段時間內(nèi)可以用大量的、復(fù)雜的輸入數(shù)據(jù)引發(fā)程序中殘留的錯誤，程序經(jīng)多次修復(fù)后，錯誤逐漸減少甚至消除，程序的有效性不斷提高。表示100個相同的系統(tǒng)有95個無故障運行250小時，有5個在此期間發(fā)生故障。軟件修復(fù)包括發(fā)現(xiàn)故障、糾正錯誤、測試和系統(tǒng)重新啟動4個步驟。硬件早期故障通常是由設(shè)計、裝配、運輸?shù)确矫娴脑蛟斐傻?。在某個定時時間間隔內(nèi)，程序按照規(guī)格說明成功運行的概率定義為軟件的可靠性。 軟件可靠性的概念制造問題、設(shè)計錯誤、元器件過載、機械磨損等原因都會導(dǎo)致硬件故障，這些故障有些是不確定的，有些是隨機的。I不僅與程序設(shè)計語言的表達能力有關(guān)，而且還依賴于程序員的水平。編寫程序的過程也就是從長度為n的符號表中（其中，n＝n1 ＋n2）選擇操作符和操作數(shù)的過程。他建議一個模塊V(G)的值不要大于10。圖147程序控制結(jié)構(gòu)的V（G）值（a） e=1,n=2,v=1。下面介紹幾種滿足上述部分原則的復(fù)雜性度量模型。ISO認為，應(yīng)對高層和中層建立國際標準，以便在國際范圍內(nèi)推廣應(yīng)用軟件質(zhì)量管理，而低層可由各使用單位自行制定。表14－8 質(zhì)量要素與評價準則質(zhì)量要素關(guān)系正確性可靠性有效性完整性可維護性可測試性可移植性可重用性可互操作性可用性靈活性評價準則可審查性　　　√　√　　　　　準確性　√　　　　　　　　　通信通用性　　　　　　　　√　　完全性√　　　　　　　　　　復(fù)雜性　√　　　√　　　　　簡明性　　√　√　　　　　√一致性√√　　√　　　　　√數(shù)據(jù)通用性　　　　　　　　√　　容錯性　√　　　　　　　　　執(zhí)行效率　　√　　　　　　　　可擴充性　　　　　　　　　　√通用性　　　　　　√√√　√硬件獨立性　　　　　　√√　　　檢測性　　　√√√　　　　　模塊化　√　　√√√√√　√可操作性　　√　　　　　　√　安全性　　　√　　　　　　　自文檔化　　　　√√√√　　√簡單性　　　　√√　　　　√軟件系統(tǒng)獨立性　　　　　　√√　　　可追蹤性√　　　　　　　　　　易培訓(xùn)性　　　　　　　　　√　McCall等人提出的軟件質(zhì)量度量模型、軟件質(zhì)量要素和評價準則為軟件質(zhì)量管理奠定了基礎(chǔ)。理解程序的難易程度。劃分成邏輯上相對獨立的成分，具有良好的接口定義。能夠?qū)Y(jié)構(gòu)設(shè)計、數(shù)據(jù)設(shè)計和過程設(shè)計進行擴充的程度。采用統(tǒng)一的概念、術(shù)語及符號，接口、規(guī)格說明等保持一致。值越大表示精度越高。定義評價準則的基礎(chǔ)是確定影響軟件質(zhì)量要素的屬性。（5） 可測試性。（1） 正確性。例如，國際標準化組織（ISO）在1985年提出了軟件質(zhì)量度量（SQM）工作報告。（3） 用戶對軟件產(chǎn)品的綜合反映程度。大量軟件事故的慘痛教訓(xùn)時刻提醒人們千萬不能忽視軟件產(chǎn)品的質(zhì)量。 LOC和FP測量常常用于導(dǎo)出生產(chǎn)率度量。算法定義為“特定計算機程序中所包含的一個界定的計算問題”。為了適應(yīng)這類應(yīng)用，數(shù)據(jù)維（前面討論的信息域值）被強調(diào)而排除功能維及行為（控制）維。表14－3問題表問題Fi（1） 系統(tǒng)需要可靠的備份和恢復(fù)嗎？（2） 需要數(shù)據(jù)通信嗎？（3） 需要數(shù)據(jù)通信嗎？（4） 性能很關(guān)鍵嗎？（5） 系統(tǒng)是否在一個現(xiàn)存的、重負的操作環(huán)境中運行？（6） 系統(tǒng)需要聯(lián)機數(shù)據(jù)登錄？（7） 聯(lián)機數(shù)據(jù)登錄是是否需要在多屏幕或多操作之間切換以完成輸入？（8） 需要聯(lián)機更新文件嗎？（9） 輸入、輸出文件或查詢很復(fù)雜嗎？（10） 內(nèi)部處理復(fù)雜嗎？（11） 代碼需要被設(shè)計成可復(fù)用的嗎？（12） 設(shè)計中需要包括轉(zhuǎn)換及安裝嗎？（13） 系統(tǒng)的設(shè)計支持不同組織的多次安裝嗎？（14） 應(yīng)用的設(shè)計方便用戶修改和使用嗎？每個問題的回答是使用從0到5衡量的，具體見表14－4，復(fù)雜度調(diào)整值數(shù)值表。計數(shù)每個邏輯的主文件（即數(shù)據(jù)的一個邏輯組合，它可能是某個大型數(shù)據(jù)庫的一部分或是一個獨立的文件）。（2）用戶輸出數(shù)。因為“功能”不能直接測量，所以必須通過利用其他直接的測量來間接地導(dǎo)出。利用代碼行數(shù)不僅能度量軟件和規(guī)模，還可度量軟件開發(fā)的生成率、開發(fā)每行代碼的平均成本、文檔按代碼的比例關(guān)系、每千行代碼的軟件錯誤數(shù)等，采用代碼行數(shù)以LOC，常用千行代碼數(shù)K LOG（1 KLOG=103 LOC）來度量。軟件度量也可以這樣分類。測度通過提供目標評價的機制從而使我們對目標做到更深的了解。進度安排的原則為： 1) 任務(wù)劃分及定義 將項目劃分為子項目、任務(wù)、活動等可以管理的部分。 項目估算 在軟件項目管理過程中的關(guān)鍵活動就是制定項目計劃，而在做項目計劃時就需要對項目所需的人力（以人月為單位）、項目持續(xù)時間（以年份或月份為單位）、成本（以元為單位）進行估算。關(guān)鍵的問題要對軟件項目范圍，各階段/活動中可能存在的風險，需要和資源（包括人、軟/硬件及其它資源），要實現(xiàn)的任務(wù)、經(jīng)歷的里程碑，花費的工作量及成本，進度安排等進行計劃及控制。本質(zhì)上，項目管理者和軟件小組的決策應(yīng)該是“保持其簡單”。然后又通過建立合適的開發(fā)小組并給予小組完成工作所需的自主權(quán)、權(quán)力和技術(shù)而增強。5） 業(yè)務(wù)需求發(fā)生變化（或未被很好地定義）。兩個項目都執(zhí)行了我們稱之為客戶通信的框架活動，但第一個項目組只執(zhí)行了第二個項目組一半的軟件工程工作任務(wù)。3） 研究如何刻畫推薦的解決方案和已有的方法。3） 共同給出范圍陳述。類似地，具有其他特性（如不確定的需求、突破性的技術(shù)、困難的客戶、明顯的復(fù)用潛力等）的項目將導(dǎo)致選擇其他過程模型。實質(zhì)上，產(chǎn)生了一個類似圖141所示的矩陣。 合并產(chǎn)品和過程項目計劃開始于產(chǎn)品和過程的合并。l 增量模型。少量的公共過程框架活動可應(yīng)用于所有軟件項目，不考慮其規(guī)模和復(fù)雜性。例如，考慮我們要建造一個新的字處理產(chǎn)品的項目。也就是說，明確給出定量的數(shù)據(jù)（如同時使用的用戶的數(shù)目、郵件列表的大小、允許的最大響應(yīng)時間），說明約束和/或局限（如產(chǎn)品成本限制內(nèi)存大?。?，以及描述其他的緩解因素（如希望使用的算法能夠被很好的理解并寫成C++程序）。一旦了解了產(chǎn)品的目的和范圍，就要開始考慮備選的解決方案了。項目組必須建立有效的辦法以協(xié)調(diào)參與工作的人員，要建立小組成員之間及多個小組之間的正式和非正式的通信機制。3） 小組成員需要共同工作的時間（小組生存期）。項目經(jīng)理有責任對項目小組成員進行績效考評。與組織（企業(yè)）高層進行及時有效的溝通，及時匯報項目的進展狀況，成本、時間等資源的花費，項目實施可能的結(jié)果，以及對將來可能發(fā)生的問題的預(yù)測。每一個軟件項目都有上述的人員參與。2） 項目（技術(shù)）管理者。將軟件進行項目管理也需采用上述5個方面的內(nèi)容進行管理，由于軟件項目的特殊性，將項目管理技術(shù)用于軟件項目管理上，其有效的項目管理集中于四個P上：人員（people）、產(chǎn)品（product）、過程（process）和項目（project）。第14章 軟件項目管理“項目”如今普遍存在于我們的工作和生活之中，并對我們的工作和生活產(chǎn)生著重要的影響。其基本內(nèi)容為 1）項目定義， 2）項目計劃， 3）項目執(zhí)行 ，4）項目控制， 5）項目結(jié)束。負責定義業(yè)務(wù)問題，這些問題往往對項目產(chǎn)生很大影響。一旦軟件發(fā)布成為產(chǎn)品，最終用戶是直接與軟件進行交互的人。對組織分配給項目的資源進行適當?shù)墓芾恚ＷC在資源約束條件所得資源能夠被充分有效地利用 2） 產(chǎn)生的程序的規(guī)模，以代碼行或者功能點來衡量。小組的核心是由以下人員組成的：高級工程師（“主程序員”），負責計劃、協(xié)調(diào)和評審小組的所有技術(shù)活動；技術(shù)人員（一般2到5個人），執(zhí)行分析和開發(fā)活動；后備工程師，支持高級工程師的活動，并能在項目進行過程中以最小的代價取代高級工程師的工作。范圍標識出與產(chǎn)品相關(guān)的數(shù)據(jù)、功能和行為，更重要的是，它以量化的方式約束了這些特性。對軟件范圍的描述必須是界定的。因為成本和進度都是面向功能的，所以某種程度的分解通常是很有用的。 過程軟件過程提供了一個框架，在該框架下可以建立一個軟件開發(fā)的全面計劃。l 原型實現(xiàn)模型。一旦建立了初步的計劃，便可以開始進行過程分解，即必須建立一個完整的計劃反映框架活動中所需要的工作任務(wù)。開發(fā)某產(chǎn)品功能的項目組成員都要將每一個框架活動應(yīng)用于該功能的實現(xiàn)上。如果時間太緊，不可能完成所有功能時，增量模型可能是最合適的。2） 與客戶見面討論需澄清的問題。2） 計劃和安排與客戶進行正式的、促進性的會議。10） 根據(jù)需求修改文檔范圍。4） 選擇的技術(shù)發(fā)生變化。這是通過努