<<軟件工程>>

SoftwareEngineering

第一章軟件與軟件工程軟件軟件工程軟件生存周期軟件開發(fā)模型CASE工具及環(huán)境Question:

什么是軟件？計算機軟件是與計算機系統(tǒng)操作有關的程序、規(guī)程、規(guī)則及任何與之有關的文檔及數(shù)據(jù)。軟件的組成程序和數(shù)據(jù)（機器可執(zhí)行）文檔（機器不可執(zhí)行）程序程序是用程序設計語言描述的、適合于計算機處理的語句序列。面向機器:匯編語言、機器語言等面向過程:Fortran,Pascal,C等面向對象:C++,Java等面向問題:結構化查詢語言SQL等文檔文檔是一種數(shù)據(jù)媒體和其上所記錄的數(shù)據(jù)。文檔記錄軟件開發(fā)的活動和階段成果，它具有永久性并能供人或機器閱讀。不僅用于專業(yè)人員和用戶之間的通信和交流，而且還可以用于軟件開發(fā)過程的管理和運行階段的維護軟件的特點抽象性：邏輯產(chǎn)品而非物理產(chǎn)品開發(fā)費用高：開發(fā)設計幾乎都是從頭開始，成本和進度很難估計可復制性：與開發(fā)成本相比，復制成本很低無折舊受硬件制約維護比硬件困難：糾錯性維護；完善性維護；適應性維護軟件的分類系統(tǒng)軟件實時軟件嵌入式軟件科學和工程計算軟件事務處理軟件人工智能軟件個人計算機軟件CASE工具軟件軟件的發(fā)展第一階段（1950-1960）程序員個人聰明才智：自己開發(fā)自己使用第二階段（1960-1975）軟件車間軟件個性第三階段（1975-1985）分布式、網(wǎng)絡的發(fā)展:軟件產(chǎn)品幾萬份Copy第四階段（1985-現(xiàn)在）面向對象、Internet的發(fā)展軟件的發(fā)展軟件發(fā)展存在的問題(1/2)軟件開發(fā)能力不能滿足人們的需要。社會對軟件的依賴程度加大，人們普遍關注軟件的安全和可靠性。建造高可靠性、高質量軟件的任務任重而道遠。軟件發(fā)展存在的問題(2/2)若干年前開發(fā)的應用軟件經(jīng)過幾十次修改已無人認識它的內(nèi)部結構，己經(jīng)不可維護。由于經(jīng)濟原因,嵌入式系統(tǒng)存在許多怪現(xiàn)象，企業(yè)不愿意投入資源再生產(chǎn)，而采取打補丁+時髦界面的方法。軟件危機軟件成為限制計算機系統(tǒng)發(fā)展的關鍵因素計算機硬件性能/價格比平均每十年提高二個數(shù)量級；軟件成本卻逐年上升，質量無保證，開發(fā)生產(chǎn)率遠遠跟不上需求軟件危機2000年，StandishGroup對280，000個軟件開發(fā)項目進行了分析軟件危機導致大量人力、物力的浪費Question:

什么是軟件危機？

軟件危機是指在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題。主要是兩個問題：1.如何開發(fā)軟件，怎樣滿足對軟件的日益增長的需求。2.如何維護數(shù)量不斷膨脹的已有軟件不僅僅“不能正常運行的”程序具有，幾乎所有軟件不同程度地存在這些問題軟件危機的主要表現(xiàn)對軟件開發(fā)成本和進度的估計不準確用戶不滿意軟件質量不高、可靠性差軟件常常不可維護、錯誤難以改正。缺乏適當?shù)奈臋n資料軟件成本占系統(tǒng)總成本的比例逐年上升軟件開發(fā)速度跟不上計算機發(fā)展速度軟件危機的原因用戶對軟件需求的描述不精確軟件開發(fā)人員對用戶需求的理解有偏差管理人員和軟件開發(fā)人員之間的誤解大型軟件開發(fā)容易產(chǎn)生疏漏和錯誤缺乏有力的方法學和工具支持軟件產(chǎn)品的特殊性和人類智力的局限性軟件危機仍在繼續(xù)影響軟件質量的糊涂認識(1/3)在項目的初始階段對系統(tǒng)若明若暗就開始寫程序認為軟件是靈活的容易修改，對軟件需求的改變不以為然程序調試成功標志著工作的結束軟件危機仍在繼續(xù)影響軟件質量的糊涂認識(2/3)程序運行前無法評價程序的質量一個軟件項目給客戶提交的主要是程序，而軟件文檔則認為可有可無、可多可少等等。雖然發(fā)布了軟件標準和規(guī)范，但在實踐中執(zhí)行需要額外的開銷，劃不來軟件危機仍在繼續(xù)--影響軟件質量的糊涂認識(3/3)雖然開發(fā)了許多軟件工具，但很多開發(fā)者對使用這些工具興趣不大為了開發(fā)軟件人們不惜用重金購買最新型號的主機和工作站而不愿意購買軟件工具在軟件開發(fā)過程中，進度遲后就增派更多的程序員突擊，趕進度………如何解決軟件危機？軟件設計、實現(xiàn)和維護應當與傳統(tǒng)的工程學科具有同等地位，因此軟件開發(fā)應當同其它工程任務的開發(fā)相似1968年，北大西洋公約組織(Nato)計算機科學會議上FritzBauer首先提出了

“軟件工程”

建立并使用正確的工程方法開發(fā)出成本低、可靠性好并在機器上能高效運行的軟件。Question:

什么是軟件工程軟件工程[教材]軟件工程是用工程、科學和數(shù)學的原則與方法研制、維護計算機軟件的有關技術及管理方法。Question:

什么是軟件工程-2

軟件工程[IEE93](1)將系統(tǒng)的、規(guī)范的、可度量的方法應用于軟件的開發(fā)、運行和維護的過程；(2)上述方法的研究。軟件工程三要素-過程、方法和工具(1/6)質量是軟件工程的生命線，軟件工程以質量保證為基礎。質量管理促進了過程的改進,創(chuàng)造了許多行之有效的軟件開發(fā)方法和工具。軟件工程三要素-過程、方法和工具(2/6)軟件工程釆用層次化的方法,每個層次都包括過程、方法、工具三要素。方法支撐過程和工具、過程和工具促進方法學的研究。軟件工程三要素-過程、方法和工具(3/6)將系統(tǒng)的、規(guī)范的、可量化的方法運用到軟件工程的始終，滲透到軟件工程的過程、方法和工具中。軟件工程過程方法工具軟件工程三要素-過程、方法和工具(4/6)軟件工程的過程過程貫穿軟件開發(fā)的各個環(huán)節(jié)，各環(huán)節(jié)之間建立里程碑；管理者在軟件工程過程中對軟件開發(fā)的質量、進度、成本進行評估、管理和控制；技術人員采用相應的方法和工具生成軟件工程產(chǎn)品（模型、文檔、數(shù)據(jù)、報告、表格等）。軟件工程三要素-過程、方法和工具(5/6)軟件工程的方法軟件工程方法是完成軟件工程項目的技術手段。它支持項目計劃和估算、系統(tǒng)和軟件需求分析、設計、編程、測試和維護。軟件工程方法依賴一組原則，它貫穿軟件工程的各個環(huán)節(jié)。軟件工程方法分兩類：傳統(tǒng)方法和面向對象方法軟件工程三要素-過程、方法和工具(6/6)

軟件工程工具它為軟件工程的過程和方法提供自動化或半自動化的工具支持。將若干工具集成起來，與軟件工程數(shù)據(jù)庫和計算機系統(tǒng)構成一個支持軟件開發(fā)的系統(tǒng)稱“計算機輔助軟件工程(CASE)”，系統(tǒng)中某一工具的信息加工結果可以作為另一工具的輸入。集成的軟件工程工具再加上人的因素構成了軟件工程環(huán)境。軟件開發(fā)方法和軟件工具結構化分析方法結構化程序設計語言面向對象分折方法面向對象程序設計語言軟件和軟件開發(fā)過程軟件過程和軟件產(chǎn)品密切相關。大型軟件項目沒有良好的軟件開發(fā)過程，不可能建造出用戶滿意的優(yōu)質產(chǎn)品；反之，一個好的軟件產(chǎn)品隱含著良好的軟件開發(fā)過程。計算機軟件領域產(chǎn)品和過程不斷交替創(chuàng)新，促進軟件工程的進步和發(fā)展。軟件工程的目標(1/6)

在給定成本、進度的前提下，開發(fā)滿足用戶需求的并具有以下特性的軟件產(chǎn)品?？尚薷男杂行钥煽啃钥衫斫庑钥删S護性可重用性可適應性可移植性可追蹤性可互操作性軟件工程的目標(2/6)有效性能有效地利用計算機的時間和空間資源可修改性容許對系統(tǒng)進行修改而不增加原系統(tǒng)的復雜性，它支持軟件的調試與維護。軟件工程的目標(3/6)可靠性具有能夠防止因概念、設計和結構等方面的不完善而造成的系統(tǒng)失效，具有挽回因操作不當造成軟件系統(tǒng)失效的能力可理解性系統(tǒng)具有清晰的結構，能直接反映軟件需求。軟件工程的目標(4/6)可維護性便于對軟件增加新功能、改進性能、修改錯誤、移植

可重用性軟件易于被再次使用軟件工程的目標(5/6)可適應性采用流行的程序設計語言、運行環(huán)境、標準的術語和格式?？勺粉櫺詫浖M行正向和反向追蹤的能力

軟件工程的目標(6/6)可移植性從一個環(huán)境搬遷到另一個環(huán)境

可互操作性多個軟件要素相互通訊協(xié)同完成任務的能力軟件工程的原則(1/6)抽象信息隱藏模塊化局部化一致性完全性可驗證性軟件工程的原則(2/6)抽象關注事物基本、重要的部分，忽略不相關成分

抽象可以使我們的思維聚焦于問題本質，從而簡化問題，控制問題復雜度，支持復雜、龐大軟件系統(tǒng)的開發(fā)。

軟件工程原則(3/6)信息隱藏模塊中的軟件設計決策信息封裝起來的技術，只知道它的功能以及對外的接口，而不知它的內(nèi)部細節(jié)

有助于軟件開發(fā)人員的注意力集中于更高的抽象層次

軟件工程的原則(4/6)模塊化模塊是程序中一個邏輯上相對獨立、具有良好的接口定義的編程單位：過程、函數(shù)、類、程序包等模塊化是,將復雜的系統(tǒng)分解為一個個相對獨立的模塊來加以實現(xiàn)，有助于抽象和信息隱藏以及表示復雜的系統(tǒng)軟件工程原則(5/6)局部化物理模塊內(nèi)集中邏輯上相互關聯(lián)的計算資源

確保模塊內(nèi)各成分關系密切而?？熘g的關系松散，保證模塊具有良好的獨立性軟件工程原則(6/6)一致性整個軟件系統(tǒng)均使用統(tǒng)一的符號、概念和術語完全性整個軟件系統(tǒng)不丟失任何重要的成分，軟件完全實現(xiàn)系統(tǒng)所需的功能、行為和性能可驗證性軟件系統(tǒng)應易于檢查、測試和評審軟件工程的基本原理1983年，Boehm提出了軟件工程的七條基本原理七條原理互相獨立，缺一不可，并且相當完備。軟件工程基本原理用分階段的生命周期計劃嚴格管理；

Boehm認為，應制定并嚴格執(zhí)行六類計劃：項目概要計劃、里程碑計劃、項目控制計劃、產(chǎn)品控制計劃、驗證計劃、運行維護計劃。堅持進行階段評審原因：（1）大部分錯誤是在編碼前造成的（設計錯誤63％，編碼錯誤37％）；（2）錯誤發(fā)現(xiàn)越晚，所付出的代價越大。軟件工程基本原理實行嚴格的產(chǎn)品控制（1）軟件開發(fā)過程中不應隨意改變需求，因為改變一項需求往往需要付出較高的代價。（2）當改變需求時，為了保持軟件各個配置成分的一致性，必須實行嚴格的產(chǎn)品控制，其中主要是實行基準配置管理（變動控制）。（3）一切有關修改軟件的建議，特別是涉及到對基準配置的修改建議，都必須按照嚴格的規(guī)程進行評審，獲得批準以后才能實施修改。軟件工程基本原理采用現(xiàn)代程序設計技術(1)60年代末提出了結構程序設計技術，已經(jīng)成為絕大多數(shù)人公認的先進的程序設計技術。(2)以后又進一步發(fā)展出各種結構分析（SA）與結構設計（SD）技術。(3)80年代中期提出的面向對象程序實際技術(4)實踐表明，采用先進的技術既可提高軟件開發(fā)的效率，又可提高軟件維護的效率。軟件工程基本原理結果應能清楚地審查（1）軟件產(chǎn)品不同于一般的物理產(chǎn)品，它是看不見摸不著的邏輯產(chǎn)品。（2）為了提高軟件開發(fā)過程的可見性，應該根據(jù)軟件開發(fā)項目的總目標及完成期限，規(guī)定開發(fā)組織的責任和產(chǎn)品標準軟件工程基本原理開發(fā)小組的人員應該少而精（1）軟件開發(fā)小組的組成人員的素質好，開發(fā)效率可能高幾倍至幾十倍，而且開發(fā)錯誤少。（2）隨著開發(fā)小組人員數(shù)目的增加，因為交流情況討論問題而造成的通信開銷會急劇增加。軟件工程基本原理承認不斷改進軟件工程實踐的必要性（1）僅有上述六條原理并不能保證軟件開發(fā)與維護的過程能趕上時代前進的步伐，能跟上技術的不斷進步。（2）不僅要積極主動地采納新的軟件技術，而且要注意不斷總結經(jīng)驗。Question:

什么是軟件生存周期軟件產(chǎn)品從形成概念開始，經(jīng)過開發(fā)、使用和維護，直到最后退役的全過程。軟件生存周期的劃分軟件定義軟件開發(fā)軟件使用與維護可行性研究、制定初步軟件項目計劃需求分析、制定需求規(guī)格說明詳細設計概要設計確認測試組裝測試實現(xiàn)使用維護退役軟件生存周期

問題定義1.可行性研究任務

了解用戶要求和現(xiàn)實環(huán)境

從技術、經(jīng)濟、市場等方面研究并論證開發(fā)該軟件系統(tǒng)的可行性可行性研究

(2/3)技術可行性當前的軟件開發(fā)方法和工具能否支持需求的實現(xiàn)；操作可行性用戶能否在特定的環(huán)境下使用這個軟件；經(jīng)濟可行性開發(fā)和使用、維護這個軟件的成本能否被用戶所接受。可行性研究

(3/3)階段性產(chǎn)品可行性論證報告制定初步項目開發(fā)計劃(人員,進度)問題定義2.需求分析任務 確定用戶對軟件系統(tǒng)的需求：功能需求軟件必須要完成的功能；性能需求軟件的安全性、可靠性、可維護性、精度、錯誤處理、適應性、用戶培訓等；運行環(huán)境約束待開發(fā)的軟件產(chǎn)品必須滿足的環(huán)境要求需求分析(2/4)重要性軟件開發(fā)的依據(jù)，軟件驗收的標準困難難以說清、

動態(tài)變化、

歧義、復雜、應用軟件的需求分析涉及應用領域的知識和經(jīng)驗。需求分析(3/4)需求分析過程需求分析人員必須與用戶不斷、反復地交流和商討，使用戶需求逐步準確、一致、完全。方法

面向數(shù)據(jù)流的分析方法面向數(shù)據(jù)流的分析方法面向對象的分析方法抽象、問題分解、快速原型、多視點等工具RationalRose,WitClass,VisualModel需求分析(4/4)階段性產(chǎn)品軟件需求規(guī)格說明書SRS用軟件需求規(guī)格說明語言描述軟件系統(tǒng)的功能需求、性能需求、接口需求、設計需求、軟件產(chǎn)品的基本結構、采用的開發(fā)標準和驗收原則等。用戶手冊概要。軟件開發(fā)1.概要設計任務根據(jù)SRS建立目標軟件系統(tǒng)的總體結構、設計全局數(shù)據(jù)庫和數(shù)據(jù)結構，規(guī)定設計約束，制定組裝測試計劃等等。概要設計(2/3)方法根據(jù)軟件需求規(guī)格說明書，

自頂向下、逐步求精、

抽象、

模塊化、

局部化、信息隱藏…堅持功能模塊內(nèi)部緊耦合，功能模塊之間松耦合的原則；堅持與需求規(guī)格說明書的一致性概要設計(3/3)工具

面向數(shù)據(jù)流的設計方法結構圖面向對象的設計方法RationalRose階段性產(chǎn)品概要設計規(guī)格說明書數(shù)據(jù)庫或數(shù)據(jù)結構設計說明書集成測試計劃。詳細設計任務細化概要設計所生成的各個模塊,并詳細描述程序模塊的內(nèi)部細節(jié)(算法，數(shù)據(jù)結構等)，形成可編程的程序模塊，制訂單元測試計劃階段新產(chǎn)品詳細設計規(guī)格說明書,單元測試計劃實現(xiàn)(1/2)任務根據(jù)詳細設計規(guī)格說明書編寫源程序，并對程序進行調試、單元測試、系統(tǒng)集成，驗證程序與詳細設計文檔的一致性實現(xiàn)(2/2)方法以詳細設計規(guī)格說明書為依據(jù)、基于某種程序設計語言進行編碼結構化程序設計面向對象程序設計工具VisualC++,VisualJava,etcIDE階段產(chǎn)品源程序代碼組裝測試任務

組裝測試應滿足概要設計的要求。途徑測試模塊連接的正確性；測試系統(tǒng)或子系統(tǒng)的I/O；測試系統(tǒng)的功能和性能。產(chǎn)品滿足概要設計要求的程序、組裝測試報告。確認測試

任務根據(jù)軟件需求規(guī)格說明書，測試軟件系統(tǒng)是否滿足用戶的需求

方法用戶參與，以軟件需求規(guī)格說明書為依據(jù)進行確認測試工具專用測試工具(如IBM的RationalTeststudio)

階段性產(chǎn)品可供用戶使用的軟件產(chǎn)品(文檔，源程序)軟件開發(fā)與測試的對應關系可行性研究運行

需求分析確認測試

概要設計組裝測試詳細設計單元測試編碼與調試軟件開發(fā)模型瀑布模型原型模型螺旋模型其他模型瀑布模型典型瀑布模型具有順序性和依賴性瀑布模型具有維護循環(huán)的軟件生存期的瀑布模型瀑布模型的特征階段間具有順序性和依賴性1.必須等前一階段的工作完成之后，才能開始后一階段的工作；2.前一階段的輸出文檔就是后一階段的輸入文檔。推遲實現(xiàn)的觀點質量保證的觀點1.每個階段都必須完成規(guī)定的文檔；2.每個階段結束前都要對所完成的文檔進行評審。瀑布模型的缺點從認識論角度看，人的認識是一個多次反復循環(huán)的過程，不可能一次完成。但瀑布模型中劃分的幾個階段，沒有反映出這種認識過程的反復性軟件開發(fā)是一個知識密集型的開發(fā)活動，需要相互合作完成，但瀑布模型沒有體現(xiàn)這一點原型模型原型模型的特征它是一個可實際運行的系統(tǒng)。它沒有固定的生存期。從需求分析到最終產(chǎn)品都可作原型，即可為不同目標作原型。它必須快速、廉價。它是迭代過程的集成部分，即每次經(jīng)用戶評價后修改、運行，不斷重復雙方認可。螺旋模型螺旋模型的特征在螺旋模型結構中，維護只是螺旋模型的另一個周期，在維護和開發(fā)之間本質上并沒有區(qū)別，從而解決了做太多測試或未作足夠測試所帶來的風險一般只適用于大規(guī)模軟件的開發(fā)變換模型

用于軟件的形式化開發(fā)方法，從軟件需求形式化說明開始，經(jīng)過一系列變換，最終得到系統(tǒng)的目標程序需要嚴格的數(shù)學理論和一整套開發(fā)環(huán)境的支持目前形式化開發(fā)方法在理論、實踐和人員培訓方面離工程應用尚有一段距離噴泉模型噴泉模型特征噴泉模型是一種以用戶需求為動力，以對象為驅動的模型，主要用于描述面向對象的軟件開發(fā)過程軟件開發(fā)過程自下而上周期的各階段是相互重疊和多次反復的，就像水噴上去又可以落下來，類似一個噴泉。各個開發(fā)階段沒有特定的次序要求，并且可以交互進行，可以在某個開發(fā)階段中隨時補充其他任何開發(fā)階段中的遺漏噴泉模型優(yōu)缺點優(yōu)點:該模型的各個階段沒有明顯的界限，開發(fā)人員可以同步進行開發(fā)，可以提高軟件項目開發(fā)效率，節(jié)省開發(fā)時間，適應于面向對象的軟件開發(fā)過程。缺點一：由于該模型在各個開發(fā)階段是重疊的，在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項目的管理。缺點二:該模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況?；谒拇夹g的模型組合模型Question:

什么是CASE？CASEComputerAidedSoftwareEngineering

計算機輔助軟件工程CASE工具事務系統(tǒng)規(guī)劃工具項目管理工具支撐工具分析和設計工具程序設計工具測試工具原型制造工具維護工具框架工具小結軟件工程是，采用系統(tǒng)的、規(guī)范的和可度量的方法支持軟件開發(fā)、運行和維護的過程；軟件工程的目標是，在給定成本、進度的前提下開發(fā)出高質量的、滿足用戶需求的軟件產(chǎn)品。過程、方法、工具的研究和應用是軟件工程學科的核心；小結軟件工程是一門工程學科，涉及軟件生產(chǎn)的各個方面；過程、方法和工具構成了軟件工程的全部內(nèi)容；軟件產(chǎn)品由開發(fā)的程序及相關文檔構成；軟件產(chǎn)品的基本屬性是可維護性、可依賴性、有效性、可用性；軟件過程由開發(fā)軟件產(chǎn)品的一系列活動組成。基本的活動有：軟件描述、開發(fā)、有效性驗證和進化；小結軟件工程方法是軟件生產(chǎn)的組織方式，包括對軟件過程的建議、使用的標記法、進行系統(tǒng)描述的規(guī)律和設計指南；CASE工具是一些軟件系統(tǒng)，支持軟件過程的常規(guī)活動，如編輯設計圖表、檢查圖表的連貫性、跟蹤已經(jīng)運行的程序測試等；軟件工程人員對軟件工程這一職業(yè)和社會負有責任，不應該只關心技術問題；職業(yè)協(xié)會頒布的行為準則規(guī)定了協(xié)會成員應該遵守的一系列行為標準。90內(nèi)容軟件度量軟件項目估算軟件質量度量軟件復雜性度量軟件開發(fā)過程的管理CMM91軟件項目管理的目的為了使軟件項目能夠在預定成本、進度、質量的前提下順利完成，必須對軟件工程項目進行計劃、組織、監(jiān)控和管理92軟件項目管理任務制定軟件項目的實施計劃和方案；對人員進行組織和分工；按照計劃進度，以及成本管理、風險管理、質量管理的要求進行軟件開發(fā)，完成軟件項目的各項要求和任務。93Question:

什么是軟件項目管理？成本管理：估算軟件項目的成本，作為簽訂合同或項目立項的依據(jù)；在軟件開發(fā)過程中按計劃管理經(jīng)費的使用。質量管理：制定軟件質量保證計劃；按照軟件質量評價體系控制軟件質量要素；對階段性的軟件產(chǎn)品進行評審；對最終產(chǎn)品進行驗證和確認，確保軟件產(chǎn)品的質量。軟件配置管理：制定配置管理計劃；對程序、文檔和數(shù)據(jù)的各種版本進行管理，確保軟件的完整性和一致性。94軟件項目管理特點管理在軟件工程項目中的地位和作用與其它工程項目一樣十分重要，必須對成本、人員、進度、質量、風險等進行分析和管理。軟件產(chǎn)品是邏輯的，軟件項目的施工是開發(fā)小組集體的智力勞動，使用的開發(fā)工具是建立在計算機系統(tǒng)上的軟件。軟件很多屬性無法直接度量為軟件定量分析和項目管理增加困難。95軟件度量軟件度量的意義軟件度量的概念軟件規(guī)模度量軟件功能度量96度量、測量和估算(1/8)

度量(metrics)軟件度量是軟件產(chǎn)品、軟件開發(fā)過程或資源簡單屬性的定量描述。如程序規(guī)模、操作符個數(shù)、程序中錯誤的個數(shù)等。97度量、測量和估算(2/8)測量measure對軟件開發(fā)過程、產(chǎn)品和資源進行實時和事后的定量描述，涉及測量的要素、方法、過程、工具和數(shù)值結果。直接測量和間接測量直接測量用于不依賴于其它屬性的簡單屬性；間接測量用于依賴于若干其它屬性的要素、準則和屬性。98度量、測量和估算(3/8)估算estimation對軟件產(chǎn)品、過程、資源進行預測估算可以采用經(jīng)驗公式、或參考歷史資料估算用于事前簽訂合同、立項、制定工作計劃等99度量、測量和估算(4/8)軟件的外部屬性和內(nèi)部屬性外部屬性軟件產(chǎn)品、過程、資源與環(huán)境的關系如，成本、效益、勞動生產(chǎn)率、可靠性、可維護性內(nèi)部屬性軟件產(chǎn)品、過程、資源、環(huán)境自身的屬性如，產(chǎn)品結構、模塊化程度、復雜性、程序長度等。100度量、測量和估算(5/8)用戶和管理者關心外部屬性，但在開發(fā)過程中無法直接管理和控制。由于外部屬性是由內(nèi)部屬性決定的，因此必須建立外部屬性與內(nèi)部屬性的關系，并通過內(nèi)部屬性的度量去度量外部屬性。101度量、測量和估算(6/8)產(chǎn)品的內(nèi)部屬性程序代碼長度程序功能模塊化重用性控制流數(shù)據(jù)流模塊耦合度與內(nèi)聚度產(chǎn)品的外部屬性程序的可靠性可用性可維護性軟件的可理解性有效性可移植性

102度量、測量和估算(7/8)過程的內(nèi)部屬性工作量計劃和進度一段時間內(nèi)某類事件發(fā)生的次數(shù)過程的外部屬性成本可控制性可觀察性穩(wěn)定性103度量、測量和估算(8/8)資源的內(nèi)部屬性人軟硬件環(huán)境方法經(jīng)驗資源的外部屬性成本時間軟件度量分類：104Question:面向規(guī)模的度量?代碼行估算方法計算：軟件項目的生產(chǎn)率

Pl=L/E

其中L軟件項目代碼行數(shù)

E軟件項目工作量（人月PM）Pl軟件項目生產(chǎn)率（LOC/PM）代碼出錯率

EQRl=Ne/L

其中Ne軟件項目的代碼錯誤數(shù)

EQRl每千行代碼的錯誤數(shù)105面向規(guī)模的度量-代碼行估算每行代碼平均成本

Cl=S/L

其中S軟件項目總開銷（元／美元）

Cl軟件項目每千行代碼的平均成本文檔與代碼比

Dl=Pd/L

其中Pd軟件項目文檔頁數(shù)

Dl每千行代碼的平均文檔數(shù)106例：軟件項目記錄項目工作量

PM成本萬美元代碼行kLOC文檔頁數(shù)

Pd錯誤數(shù)

Ne人數(shù)

MAaa-012416.812.1365293Ccc-046244.027.21224865Fff-034331.420.21050646107代碼行估算軟件規(guī)模的優(yōu)缺點優(yōu)點：簡單，容易實行缺點：代碼行數(shù)的估算依賴于程序設計語言的功能和表達能力；采用代碼行估算方法會對設計精巧的軟件項目產(chǎn)生不利的影響；代碼行估算只適用于過程式程序設計語言，不太適用于非過程式的程序設計語言108Question:面向功能的度量?軟件功能點度量方法(三個步驟)FP=CT[0.65+0.01∑Fi](2-5)CT:5個信息量的加權和(表2.3)∑Fi:14個因素的復雜性調節(jié)值Fi取值0,1,...,5當Fi=0時，表示Fi不起作用

Fi=5時，表示Fi作用最大109表2.3功能點度量

測量參數(shù)值權值用戶輸入數(shù)□*4＝□用戶輸出數(shù)□*5＝□用戶查詢數(shù)□*4＝□文件數(shù)□*7＝□外部界面數(shù)□*7＝□CT＝

□110面向功能的度量表2.3中的五個信息量按下列方式取值用戶輸入數(shù)用戶為軟件提供的輸入?yún)?shù)個數(shù)用戶輸出數(shù)軟件系統(tǒng)為用戶提供的輸出參數(shù)個數(shù)用戶查詢數(shù)一個聯(lián)機輸入確定一次查詢，軟件以聯(lián)機輸出的形式,實時地產(chǎn)生一個響應文件數(shù)統(tǒng)計邏輯的主文件個數(shù)外部界面數(shù)統(tǒng)計所有機器可讀的界面，利用這些界面可以將信息從一個系統(tǒng)傳送到另一個系統(tǒng)111面向功能的度量用功能點定義的概念生產(chǎn)率

Pf=FP/E

其中Pf表示每人月完成的功能點數(shù)112面向功能的度量軟件規(guī)模的功能點度量沒有直接涉及軟件系統(tǒng)本身的算法復雜性。1986年Jones把軟件項目中的算法復雜性因素引入到功能點計算中來，為了避免混淆，我們把Albrecht定義的功能點稱為簡單功能點，用FPs表示，把Jones推廣的功能點稱為功能點，用FP表示。推廣的功能點包括計算機程序中用于各類問題求解的算法因素，如求解線性代數(shù)方程組、遍歷二叉樹的各個結點、處理中斷等等。功能點計算仍用公式(2—5),其中CT按表2.5計算。113表2.5功能點度量測量參數(shù)值權值用戶輸入數(shù)□*4＝□用戶輸出數(shù)□*5＝□用戶查詢數(shù)□*4＝□文件數(shù)□*7＝□外部界面數(shù)□*7＝□算法□*3＝□CT＝

□114

面向功能的度量對一般的工程計算或事務處理軟件，用表2.3和表2.5兩種方法計算出來的FP值應該基本上相同對于比較復雜的軟件系統(tǒng)

FP比FPs的值高20%～35%

115功能點度量方法的優(yōu)缺點優(yōu)點：與程序設計語言無關，適用于過程式與非過程式語言；功能點度量能適用于軟件項目的開發(fā)初期；缺點：涉及到的主觀因素比較多，如各種權函數(shù)的取值；信息領域中的某些數(shù)據(jù)有時不容易采集；FP的值沒有直觀的物理意義。116代碼行度量與功能點度量的比較代碼行度量依賴于程序設計語言，而功能點度量不依賴于程序設計語言。Albrecht和Jones等人對若干軟件采用事后處理的方式分別統(tǒng)計出不同程序設計語言每個功能點與代碼行數(shù)的關系，用LOC/FP的平均值表示。表2.6表明，一行Ada語言代碼的“功能”平均是一行FORTRAN語言代碼“功能”的1.4倍。一行四代語言代碼的“功能”平均是一行傳統(tǒng)程序設計語言代碼“功能”的3至5倍。117表2.6各種語言的LOC/FP(平均值)程序設計語言LOC/FP(平均值)匯編語言300COBOL100FORTRAN100Pascal90Ada70面向對象的語言30四代語言(4GL)20代碼生成器15

118軟件項目估算當前在基于計算機的系統(tǒng)中，軟件開發(fā)成本占總成本的比例很大。在軟件項目立項和軟件項目管理工作中，客戶和項目管理人員都十分重視軟件項目的成本估算。軟件是邏輯產(chǎn)品，成本估算涉及人、技術、環(huán)境、政策等多種因素，在項目完成之前，很難精確地估算出項目的開銷。119軟件項目估算方法參照已經(jīng)完成的類似項目將大的項目分解成若干小的子項目將軟件項目按軟件生存周期分解根據(jù)實驗或歷史數(shù)據(jù)給出軟件項目工作量或成本的經(jīng)驗估算公式120代碼行、功能點和工作量估算軟件項目的規(guī)模是影響軟件項目成本和工作量的重要因素。軟件項目代碼行和功能點估算是成本和工作量估算的基礎。采用上述四種估算方法可以估算出LOC或FP的樂觀值a，悲觀值b和一般值m，然后根據(jù)下列加權公式計算出期望值

e=(a＋4m＋b)／6(2-10)

希望LOC或FP的值落在區(qū)間［a,b］之外的概率極小121代碼行、功能點和工作量估算當LOC或FP的期望值估算出來之后，根據(jù)以前軟件項目開發(fā)的平均生產(chǎn)率LOC/PM或FP/PM就可以計算出工作量。如，軟件項目的規(guī)模估算為310FP，以前完成的軟件項目的生產(chǎn)率為5.5FP/PM，于是工作量估算為E=310/5.5=56PM。如果當前估算的軟件子項目比以前完成的項目復雜，那么所用的生產(chǎn)率值可以低于平均生產(chǎn)率，反之也可以高于平均生產(chǎn)率。122經(jīng)驗估算模型之一CoCoMo模型計算機軟件的估算模型是根據(jù)以前完成項目的實際數(shù)據(jù)導出的，用于軟件項目的計劃階段。模型是根據(jù)“從前的”，“局部的”數(shù)據(jù)得出的，估算模型不可能完全適用于當前所有的軟件項目和全部開發(fā)環(huán)境。這些模型的計算結果僅供參考。兩個常用的估算模型

CoCoMo模型Putnam模型123

CoCoMo模型1981年Boehm提出“構造性成本模型”(ConstructiveCostModel)，簡稱CoCoMo模型。它是在靜態(tài)、單變量模型的基礎上構造出來的。

CoCoMo模型分為基本、中間、詳細三個層次，分別用于軟件開發(fā)的三個不同階段。124

CoCoMo模型基本CoCoMo模型用于系統(tǒng)開發(fā)的初期，估算整個系統(tǒng)的工作量(包括軟件維護)和軟件開發(fā)所需要的時間。中間CoCoMo模型用于估算各個子系統(tǒng)的工作量和開發(fā)時間。詳細CoCoMo模型用于估算獨立的軟部件，如子系統(tǒng)內(nèi)部的各個模塊。125基本CoCoMo模型靜態(tài)、單變量模型

E=aLb(2-11)D=cEd(2-12)其中：E表示工作量，單位是人月(PM)。D表示開發(fā)時間，單位是月(M)。L是項目的代碼行估計值，單位是千行代碼

a,b,c,d是常數(shù)，取值如表2.9所示。126

表2.9基本CoCoMo模型參數(shù)軟件類型abcd適用范圍組織型2.41.052.50.38各類應用程序半獨立型3.01.122.50.35各類實用程序、編譯程序等嵌入型3.61.202.50.32實時處理、控制程序、操作系統(tǒng)127中間CoCoMo模型中間CoCoMo模型以基本CoCoMo模型為基礎，在工作量估計公式中乘以工作量調節(jié)因子EAFE=aLb*EAF

(2-13)其中：L是軟件產(chǎn)品的目標代碼行數(shù)

a,b是常數(shù)，取值如表2.10所示。128中間CoCoMo模型表2.10中間CoCoMo模型參數(shù)軟件類型ab

組織型3.21.05半獨立型3.01.12嵌入型2.81.20129

中間CoCoMo模型工作量調節(jié)因子與軟件產(chǎn)品屬性、計算機屬性、人員屬性、項目屬性有關軟件產(chǎn)品屬性軟件可靠性、軟件復雜性、數(shù)據(jù)庫的規(guī)模。計算機屬性程序執(zhí)行時間、程序占用內(nèi)存的大小、軟件開發(fā)環(huán)境的變化、軟件開發(fā)環(huán)境的響應速度。人員屬性分析員的能力、程序員的能力、有關應用領域的經(jīng)驗、開發(fā)環(huán)境的經(jīng)驗、程序設計語言的經(jīng)驗項目屬性軟件開發(fā)方法的能力，軟件工具的質量和數(shù)量、軟件開發(fā)的進度要求。130中間CoCoMo模型四種屬性共15個要素。每個要素調節(jié)因子Fi,i=1,2,...,15,的值分為：很低、低、正常、高、很高、極高，共六級。正常情況下Fi=1。Boehm推薦的Fi值范圍

(0.70,0.85,1.00,1.15,1.30,1.65)

當15個Fi的值選定后，EAF的計算如下

EAF＝F1*F2*……*F15

131中間CoCoMo模型

調節(jié)因子集的定義和調節(jié)因子定值是由統(tǒng)計結果和經(jīng)驗決定的。不同的軟件開發(fā)組織，在不同的歷史時期，隨著環(huán)境的變化，這些數(shù)據(jù)可能改變。132例2.3用基本CoCoMo模型估算例2.2工作量、開發(fā)時間和項目開發(fā)人數(shù)在例2.2中，目標代碼行數(shù)為33.3KLOCCAD軟件開發(fā)屬于中等規(guī)模、半獨立型從表2.9中查到a=3.0，b=1.12。代入公式(2-11)

E=3.0＊L1.12=3.0＊33.31.12=152PM133例2.3用基本CoCoMo模型估算例2.2將E的估算值代入公式(2-12)取C=2.5d=0.35D=2.5＊E0.35=2.5*1520.35=14.5M

建議參加項目開發(fā)的人數(shù)

N=E/D=152/14.5≈11Notice:盲目增加程序員人數(shù)會推遲軟件完成的日期134CoCoMo模型例中計算出來的11人是粗略估計在軟件項目開發(fā)過程中，11個人不可能都有相同的能力和個性，相同的經(jīng)驗和知識結構，并且在軟件開發(fā)的各個階段對人的要求也不同。135人員和工作量之間的關系十個人年工作量的項目不可能由一個人干十年，但十個人干一年也無法完成任務,因為十個人的任務組需要交流的開銷；項目后期增加人員還需要增加培訓的工作量，可能會使項目的交付日期一托再托；項目工作人員的數(shù)量和項目整體生產(chǎn)率之間的關系不是線性的。136

CoCoMo模型若干人共同開發(fā)一個軟件項目還應該增加他們之間相互通信和交換意見的額外工作量。

設

N個程序員組成小組，實現(xiàn)相同規(guī)模的程序，相互通信數(shù)為

C=N(N-1)/2

每次通信和交換意見的平均工作量為μ

則增加的通信開銷為

Ec＝μN(N-1)/2(2-14)137

CoCoMo模型由N個程序員組成的小組共同開發(fā)一個程序總的工作量ET滿足

ET=E+Ec程序員小組的生產(chǎn)率是

PG=LOC/(E+Ec)

程序員小組生產(chǎn)率和單個程序員生產(chǎn)率的比為

Rp=E/(E+Ec)

隨著程序員小組人數(shù)的增加Ec≈μN*N/2，程序員小組的生產(chǎn)率將會下降。模型表明

盲目增加程序員人數(shù)會推遲軟件完成的日期138

CoCoMo模型

以靜態(tài)單變量CoCoMo模型為基礎，還可以定義估算資源R的靜態(tài)多變量模型

R＝∑ai*ei**bi

其中：ei表示軟件第i個特性

ai,bi是與軟件第i個特性有關的常數(shù)，通常由實驗數(shù)據(jù)確定。

139經(jīng)驗估算模型之二：Putnam模型

1978年，Putnam提出了大型軟件項目工作量(一般在30人年以上)估算模型。它是一個動態(tài)多變量模型，適用于軟件開發(fā)的各個階段，估算模型以大型軟件項目的實測數(shù)據(jù)為基礎，導出工作量分布曲線，該曲線與Rayleigh-Norden曲線形狀比較相似140大型軟件項目的工作量分布141

Putnam模型該模型描述了開發(fā)工作量，開發(fā)時間和軟件代碼行數(shù)之間的關系:

L=CKE1/3td4/3其中：L表示源程序代碼行數(shù)

td表示開發(fā)時間

Ck表示技術狀態(tài)常數(shù)

E表示工作量(以人年記，包括維護)142

Putnam模型-Ck的確定差的軟件開發(fā)環(huán)境軟件開發(fā)沒有方法學的支持，缺乏對文檔的評審，采用批處理方式。一般的軟件開發(fā)環(huán)境應有軟件開發(fā)方法學的支持，有適宜的文檔和評審，采用交互處理方式。好的軟件開發(fā)環(huán)境應采用CASE工具和集成化CASE環(huán)境。

CK=2000比較差的軟件開發(fā)環(huán)境8000一般的軟件開發(fā)環(huán)境11000比較好的軟件開發(fā)環(huán)143軟件開發(fā)過程人員與時間的關系144Putnam模型的啟示軟件開發(fā)項目的工作量隨著時間t的增長并不呈線性增長趨勢。參加軟件項目開發(fā)的人員數(shù)目不應該是一成不變的。如果按照線性分布方案配備人員，即每年的人數(shù)是常數(shù)。那么起始段一部分人力是多余的，而峰值段人力又不夠，到項目后期再增加人力為時已晚，造成浪費。由于人力調度的不合理，不得不延長項目開發(fā)時間，增加一部分額外工作量。145Putnam模型的缺點它沒有反映軟件產(chǎn)品屬性，軟件項目屬性、軟件開發(fā)人員屬性，計算機軟硬件資源屬性等用Putnam模型進行軟件項目的成本估算是十分粗糙的146軟件質量軟件質量是軟件的生命，它直接影響軟件的使用與維護。質量低下的軟件不但影響基于計算機系統(tǒng)的工作效率，而且還可能給用戶帶來災難性的后果。提高軟件產(chǎn)品質量是軟件工程的首要任務。軟件開發(fā)人員、管理人員、維護人員和用戶在軟件開發(fā)、維護、使用過程中所處地位不同，對軟件質量的理解和要求也不同。147軟件質量管理人員關心軟件開發(fā)標準，在經(jīng)費和時間允許的情況下，如何實現(xiàn)軟件需求規(guī)格說明中定義的功能維護人員重視軟件的正確性，可理解性和可修改性用戶更關心軟件的性能和可靠性等等

因此應該對軟件質量給出一個客觀的、科學的定義并盡量予以量化。148Question:什么是軟件質量？1983年ANSI/IEEEstd729給出的定義：軟件產(chǎn)品滿足規(guī)定的和隱含的與需求能力有關的全部特征和特性，包括：軟件產(chǎn)品質量滿足用戶要求的程度；軟件各種屬性的組合程度；用戶對軟件產(chǎn)品的綜合反映程度；軟件在使用過程中滿足用戶要求的程度。149軟件度量軟件質量依賴于軟件的內(nèi)部特性及其組合為了對軟件質量進行度量，必須對影響軟件質量的要素進行度量，并建立實用的軟件質量度量體系或模型150軟件質量度量-發(fā)展1968年Rubey和Hartwick提出了軟件某些屬性的度量方法1976年Boehm提出了定量評價軟件質量的概念，給出了60個軟件質量度量公式和軟件質量度量的層次模型151軟件質量度量-發(fā)展1978年Walters和McCall提出了包括質量要素(factor)、準則(criteria)和度量(metric)的三層次軟件質量度量模型G.Murine又提出了軟件質量度量技術SQM用于定量地評價軟件質量1985年國際標準化組織(ISO)提出了軟件質量度量(SQM)工作報告152McCall的軟件質量度量模型

質量要素(factor)評價準則(criteria)度量(metric)153軟件質量要素軟件質量要素直接影響軟件開發(fā)過程各個階段的產(chǎn)品質量由于對軟件質量理解的不斷深化，軟件質量要素不是一成不變的McCall等人給出的軟件質量要素共11個，分為三類。154McCall的軟件質量要素軟件的運行特征正確性可靠性有效性完整性可用性軟件承受修改的能力可維護性靈活性可測試性軟件對新環(huán)境的適應程度可移植性可重用性連接性

155軟件的屬性（續(xù)）正確性(Correctness):程序滿足規(guī)格說明及完成用戶目標的程度。

完整性(Integrity):控制未被授權人員訪問程序和數(shù)據(jù)的程度?？捎眯?Usability):學習使用軟件的難易程度。包括：操作軟件、為軟件準備輸入數(shù)據(jù)，解釋軟件輸出結果。156軟件的屬性（續(xù)）靈活性(Flexibility)

改變一個操作程序所需的工作量?？蓽y試性(Testability)

測試程序使之具有預定功能所需的工作量。連接性(Interoperability)

兩個或多個系統(tǒng)交換信息并相互使用已交換信息的能力。157

軟件質量要素之間的關系軟件質量要素之間有正相關，也有負相關。系統(tǒng)設計過程中應根據(jù)具體情況對各種要素的要求進行折衷，以便得到在總體上用戶和系統(tǒng)開發(fā)人員都滿意的質量標準。實時控制系統(tǒng)的可靠性、有效性是決定系統(tǒng)成敗的關鍵要素，必須全力保證，而軟件的可移植性、可重用性就不是主要的了。通用軟件工具對可維護性、可移植性、可重用性應該給予更多的注意158軟件質量要素評價準則直接測量軟件質量要素十分困難，甚至是不可能的，McCall等人定義了一組比較容易度量的軟件質量要素評價準則，通過評價準則間接測量軟件質量要素。定義評價準則的關鍵是確定影響軟件質量要素的屬性。這些屬性必須滿足①比較完整、準確的描述軟件質量要素；②比較容易量化和測量，能夠反映軟件質量的優(yōu)劣159McCall的評價準則（21種）可審查性準確性通信通用性完全性簡明性一致性數(shù)據(jù)通用性容錯性執(zhí)行效率可擴充性通用性硬件獨立性檢測性模塊化可操作性安全性自文檔化簡單性軟件系統(tǒng)獨立性可追蹤性易培訓性160McCall軟件質量要素評價準則(1/6)可審查性(Auditability)

檢查軟件需求、規(guī)格說明、標準、過程、指令、代碼及合同是否一致的難易程度。準確性(Accuracy)

計算和控制的精度，最好表示成相對誤差的函數(shù),值越大表示精度越高。通信通用性(CommunicationCommonality)

使用標準接口、協(xié)議和頻帶的程度。161McCall軟件質量要素評價準則(2/6)完全性(Completeness)見1.2簡明性(Conciseness)程序源代碼的緊湊性。一致性(Consistency)見1.2數(shù)據(jù)通用性(DataCommonality)在程序中使用標準的數(shù)據(jù)結構和類型。162McCall軟件質量要素評價準則(3/6)容錯性(Error

tolerance)

系統(tǒng)在各種異常條件下提供繼續(xù)操作的能力執(zhí)行效率(ExecutionEfficiency)

程序運行效率可擴充性(Expandability)

能夠對結構設計、數(shù)據(jù)設計和過程設計進行擴充的程度通用性(Generality)

程序部件潛在的應用范圍的廣泛性163McCall軟件質量要素評價準則(4/6)硬件獨立性(HardwareIndependence)

軟件同支持它運行的硬件系統(tǒng)不相關的程度。檢測性(Instrumentation)

監(jiān)視程序的運行，一旦發(fā)生錯誤時，標識錯誤的程度。模塊化(Modularity)見1.2可操作性(Operability)

操作一個軟件的難易程度。164McCall軟件質量要素評價準則(5/6)安全性(Security)

控制或保護程序和數(shù)據(jù)不受破壞的機制，以防止程序和數(shù)據(jù)受到意外的或蓄意的存取、使用、修改、毀壞或泄密。自文檔化(Self-documentation)

源代碼提供有意義文檔的程度。簡單性(Simplicity)

理解程序的難易程度。165McCall軟件質量要素評價準則(6/6)軟件系統(tǒng)獨立性(SoftwareSystemIndependence)

程序與非標準的程序設計語言特征、操作系統(tǒng)特征、以及其他環(huán)境約束無關的程度?？勺粉櫺?Tracebility)見1.2易培訓性(Training)

軟件支持新用戶使用該系統(tǒng)的能力。166Mcall的軟件質量度量模型軟件質量要素Fj的值可用下式計算

LFj＝∑CjkMkj=1,2，...,11.

k=1其中Mk是軟件質量要素Fj對第k種評價準則的測量值

Cjk是相應的加權系數(shù).滿足∑Cjk＝1并且Cjk≥0當質量要素Fj與k項評價準則無關時，Cjk=0

McCall定義的評價準則多數(shù)都沒有客觀的測量方法，只能憑主觀印象為評價準則定值。McCall將評價準則分為0--10級:0級最低,10級最高。

Mk的取值是0,0.1,0.2,…,1.0167軟件質量的FURPS度量1987年Hewlett-Packard提出一組被稱之為FURPS的軟件質量要素。這組要素由功能性(Functionality)、可用性(Usability)、可靠性(Reliability)、性能(Performance)和可支撐性(Supportability)組成。Grad和Caswell給出了以調查報告/規(guī)格說明、設計、實現(xiàn)、測試、支撐為行，以上述要素為列的5行5列矩陣，通過對矩陣元素的度量導出軟件開發(fā)過程和軟件產(chǎn)品質量要素的FURPS度量。168FURPS軟件貭量要素要素關系準則功能性可用性可靠性性能可支撐性論證報告/規(guī)格說明設計實現(xiàn)測試支撐環(huán)境169ISOvs.McCall三層軟件質量度量模型軟件質量需求評價準則vs.要素軟件質量設計評價準則vs.評價準則軟件質量度量評價準則vs.度量170軟件復雜性度量軟件復雜性及度量原則控制結構的復雜性度量文本復雜性度量171軟件復雜性及度量原則開發(fā)規(guī)模相同、復雜性不同的軟件，花費的時間和成本會有很大差異。K.Magel從六個方面描述了軟件復雜性172K.Magel的軟件復雜性描述

①理解程序的難度；②糾錯、維護程序的難度；③向他人解釋程序的難度；④按指定方法修改程序的難度；⑤根據(jù)設計文件編寫程序的工作量；⑥執(zhí)行程序時需要資源的程度。它反映了軟件的可理解性、模塊性、簡潔性等屬性。173軟件復雜性度量的原則(1/2)1.軟件復雜性與程序大小的關系不是線性的；2.控制結構復雜的程序較復雜；3.數(shù)據(jù)結構復雜的程序較復雜；4.轉向語句使用不當?shù)某绦蜉^復雜；5.循環(huán)結構比選擇結構復雜；選擇結構又比順序結構復雜；6.語句、數(shù)據(jù)、子程序和模塊在程序中的次序對復雜性有影響；174軟件復雜性度量的原則(2/2)7.全程變量、非局部變量較多時，程序較復雜；8.參數(shù)按地址調用比按值調用復雜；9.函數(shù)副作用比顯式參數(shù)傳遞難于理解；10.具有不同作用的變量共用一個名字時較難理解；11.模塊間、過程間聯(lián)系密切的程序比較復雜；12.嵌套越深程序越復雜。175控制結構的復雜性度量程序控制結構圖

程序結構對應于有一個入口結點和一個出口結點的有向圖圖中每個結點對應一個語句或一個順序流程的程序代碼塊弧對應于程序中的轉移由入口結點可以到達圖中每個結點，并且從圖中每個結點都可以到達出口結點176控制結構的復雜性度量

McCabe用程序控制結構圖的巡回秩數(shù)V(G)作為程序結構復雜性的度量

V(G)=e-n+2

其中：e為結構圖的邊數(shù)

n為結構圖的結點數(shù)可以證明V(G)等于結構圖中有界或無界的封閉區(qū)域個數(shù)177例計算程序控制結構的V(G)值E=1E=3N=2N=3V=1V=2178計算程序控制結構的V(G)值E=4E=3N=4N=3V=2V=2179控制結構的復雜性度量McCabe建議把V(G)作為模塊規(guī)模的定量指標，一個模塊V(G)的值不要大于10當V(G)>10時，模塊內(nèi)部結構就會變得復雜，給編碼和測試帶來困難。

180文本復雜性度量M.Halstead用下式定義程序量

V=Nlog2(n1+n2)其中n1為程序中不同操作符的個數(shù)

n2為程序中不同操作數(shù)的個數(shù)

N1為程序中操作符的個數(shù)

N2為程序中操作數(shù)的個數(shù)N=N1+N2它反映了程序在“詞匯”上的復雜性。181軟件開發(fā)過程管理風險分析進度安排軟件開發(fā)標準軟件質量保證軟件開發(fā)人員的組織與分工軟件項目的開發(fā)過程管理182風險分析--風險的概念風險與將要發(fā)生的事情有關，研究風險就是研究明天將要發(fā)生的事情風險涉及思想、觀念、行為、地點、時間等多種因素風險隨條件的變化而改變，人們通過改變、選擇、控制與風險密切相關的條件減少、回避風險改變、選擇、控制條件的策略是不確定的183風險分析-對待風險的態(tài)度被動從不擔心發(fā)生任何問題，問題發(fā)生后再做出反應。軟件項目組對存在的風險不聞不問，直到出了問題才趕緊采取措施，當種種努力失敗后，項目處于真正的危機之中。主動項目開始時就預測、標識項目存在的各種風險，評估風險發(fā)生的概率和影響的大小並按重要性進行排序；項目組建立風險管理計劃和意外事件處理計劃，以便預防風險，及時處理突發(fā)事件184風險分析-風險類別項目風險：項目在預算、進度、人力、資源、顧客和需求等方面的原因對軟件項目產(chǎn)生的不良影響；技術風險：項目在設計、實現(xiàn)、接口、驗證和維護過程中可能發(fā)生的潛在問題對項目帶來的危害；商業(yè)風險：開發(fā)了一個沒人需要的優(yōu)質軟件，開發(fā)的產(chǎn)品不符合公司的產(chǎn)品銷售戰(zhàn)略等。185Question:以下情況分別屬于哪種風險？開發(fā)的產(chǎn)品沒有銷路沒能夠在預定的時間內(nèi)完成任務開發(fā)環(huán)境的更改186軟件工程的風險187風險標識對侍風險不能采取回避態(tài)度項目開始時應對一般性風險和特定產(chǎn)品風險進行系統(tǒng)標識，並隨著項目的展開不斷更新。一般可預測風險產(chǎn)品規(guī)模、商業(yè)影響、客戶、過程、技術、環(huán)境、人員及經(jīng)驗等。識別風險的有效方法風險檢測表188例:人員配備風險檢測表(1)開發(fā)人員的水平如何。(2)開發(fā)人員在技術上是否配套。(3)開發(fā)人員的數(shù)量如何。(4)開發(fā)人員是否能夠自始至終地參加軟件開發(fā)工作。(5)開發(fā)人員是否能夠集中全部精力投入到軟件開發(fā)工作。(6)開發(fā)人員對自己的工作是否有正確的期望。(7)開發(fā)人員是否接受過必要的培訓。(8)開發(fā)人員的流動是否能夠保證工作的連續(xù)性。189例:人員配備風險檢測表上述問題可以選用0,1,2,3,4,5來回答。完全肯定取值為0反之為5，中間情況分別取值1,2,3,4值越大表示風險越大。人員配備風險檢測表反映了人的因素給軟件項目帶來的風險190風險估算如果某一風險檢測表由m項組成，每項選取一個整數(shù)值0,1,…，N，在最理想的情況取值為0，反之取值為N對于中間狀態(tài)依次取值1,2,…,N-1設第i種風險檢測表第j項取值Xij，對應的加權系數(shù)是Wij，于是第i種風險的估算值可以定義為

mσi＝∑WijXij／(mN)j=1

其中∑Wij＝m，Wij≥0191風險估算如果第i種風險對整個軟件項目的風險估算σi，加權系數(shù)是ρi,i=1,2,…,I.I為風險要素的個數(shù)∑ρi＝1則軟件項目風險估算定義為

R＝∑ρiσi0≤R≤1

當R接近于0時表示風險比較小，R接近于1時表示風險比較大。當ρiσi比較大時，表示第i類風險出現(xiàn)并帶來不良影響的可能性比較大，必須引起足夠重視，設法改善條件，減小σi的值。192風險評價和管理風險評價是風險管理的重要步驟任務

進一步審查風險預測的精度；更新風險優(yōu)先次序；考慮控制和/或避免可能發(fā)生風險的辦法。193風險評價定義

風險管理三元組[ri，li，xi]i=1,2,3…

其中：ri

表示風險

li

表示風險發(fā)生的概率

xi表示風險產(chǎn)生的影響對大多數(shù)軟件項目，應該定義性能、成本、支持及進度的風險參考水平值，當某一風險或風險組合值超過水平值時項目被迫停止。194評價風險的影響風險影響三要素風險的性質風險發(fā)生時可能產(chǎn)生的問題。風險的范圍風險引發(fā)損失的分布及嚴重性。風險的時間風險發(fā)生的時間、持續(xù)的時間，應注意這時項目所處的狀態(tài)。195確定風險影響的步驟確定每個風險元素發(fā)生的平均概率給出每個元素影響的大小填寫風險表並分析其結果風險預測和分析技術可以在軟件項目進展過程中反復使用，項目組應定期復查風險表，評估每一個風險，以此為基礎判斷風險發(fā)生概率及影響的變化。必要時可潻加新的風險元素，刪去不存在影響的元素，並對風險表重新排序。196風險預測（1／2）風險預測又稱風險評估（1）風險發(fā)生的概率；（2）風險發(fā)生產(chǎn)生的后果。197風險預測（2／2）風險預測活動風險的度量估算風險產(chǎn)生的后果估算風險對項目及產(chǎn)品的影響標注風險預測的整體精度，避免誤解項目管理人員和技術人員共同參加198風險評估的步驟1定義項目的風險參考水平值；2建立三元組，給出相應的參考水平值；3預測一組臨界點，定義項目終止區(qū)域；4預測什么樣的風險組合會影響參考水平值199風險表（1／3）風險類別概率影響RMMM123項目開始時應在第一列列出所有風險;第二列給出風險類別；第三列給出每種風險發(fā)生的概率；第四列給出各種風險產(chǎn)生影響的評估值；第五列給出風險緩解、監(jiān)控和管理計劃。200風險表（2／3）評估值按風險因素：性能、支持、成本、進度的影響類別求加權平均值影響類別取值：災難的1，嚴重的2，輕微的3，可忽略的4。對風險表中的風險按照發(fā)生概率大小、影響大小，由大至小排序。201風險表（3／3）項目管理者對風險表進行研究后應定義一條中止線，線上的風險較大者應給予特別的關注，線下的風險需要進一步的跟蹤、評估、排序。對風險發(fā)生概率較大的事件應引起特別關注，要及早采取措施盡量避免它的發(fā)生。202風險緩解、監(jiān)控和管理風險分析的目的協(xié)助項目組建立處理風險的策略。有效的風險處理策略風險避免；風險監(jiān)控；風險管理及異常事件處理。風險緩解計劃軟件項目組主動避免風險發(fā)生的最好策略。落實風險緩解計劃項目管理者應該對引發(fā)風險的因素和采取措施取得的效果進行監(jiān)控;當風險發(fā)生時,采取積極的補救措施。203204風險評價和管理-例子三元組［ri,li,xi］是風險管理的基礎設高級職員流動給項目帶來風險r1,

根據(jù)歷史的經(jīng)驗或直觀感覺，高級職員離開課題組的概率l1

=70%,

這一風險導致事件x1

發(fā)生

項目開發(fā)時間延長15%，成本增加20%．205項目負責人采取的風險管理措施(1)項目開始前控制產(chǎn)生風險的原因。項目開工后應設法減輕風險的影響。(2)了解項目開發(fā)人員變動的原因，在項目開發(fā)期間應控制上述原因，盡量減少人員的流動。(3)在工作方法和技術上采取適當措施，防止因人員流動給工作帶來損失。(4)項目在開發(fā)過程中應及時公布并交流項目開發(fā)的信息。(5)建立組織機構，確定文檔標準、并及時生成文檔。(6)對工作進行集體復審，使多數(shù)人都能了解工作的細節(jié)，跟上工作進度。(7)為關鍵技術準備后備人員。206

RMMM計劃風險緩解、監(jiān)控和管理計劃

RiskMitigation,Monitoring,andManagementPlan

將風險分析工作文擋化，成為項目的一部分。207進度安排制定進度表的兩