軟件工程演示文稿_第1頁
軟件工程演示文稿_第2頁
軟件工程演示文稿_第3頁
軟件工程演示文稿_第4頁
軟件工程演示文稿_第5頁
已閱讀5頁,還剩136頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

軟件工程演示文稿當前第1頁\共有141頁\編于星期一\15點軟件工程第章當前第2頁\共有141頁\編于星期一\15點經(jīng)理管什么?計劃預算組織進度標準什么是軟件項目管理?當前第3頁\共有141頁\編于星期一\15點

管理就是通過計劃、組織和控制等一系列活動,合理地配置和使用各種資源,以達到既定目標的過程。什么是軟件項目管理?當前第4頁\共有141頁\編于星期一\15點什么是軟件項目管理?成本管理:估算軟件項目的成本,作為簽訂合同或項目立項的依據(jù);在軟件開發(fā)過程中按計劃管理經(jīng)費的使用。質量管理:制定軟件質量保證計劃;按照軟件質量評價體系控制軟件質量要素;對階段性的軟件產品進行評審;對最終產品進行驗證和確認,確保軟件產品的質量。軟件配置管理:制定配置管理計劃;對程序、文檔和數(shù)據(jù)的各種版本進行管理,確保軟件的完整性和一致性。當前第5頁\共有141頁\編于星期一\15點第2章 軟件項目管理2.1軟件度量2.2軟件項目估算2.3軟件質量度量2.4軟件復雜性度量2.5軟件可靠性度量2.6軟件開發(fā)過程的管理當前第6頁\共有141頁\編于星期一\15點

軟件度量是軟件產品、軟件開發(fā)過程或自愿簡單屬性的定量描述。如程序規(guī)模、操作符個數(shù)、程序中錯誤的個數(shù)等。面向規(guī)模的度量面向功能的度量2.1軟件度量當前第7頁\共有141頁\編于星期一\15點2.1軟件度量2.1.1軟件度量的基本概念1.測量、度量、估算和指標

軟件工程項目的定量描述涉及測量、度量、估算和指標等一些基本概念。當前第8頁\共有141頁\編于星期一\15點1)測量(measure):對產品或過程的某個屬性的范圍、數(shù)量、維度、容量或大小提供一個定量的指示。2.1軟件度量4)指標(guideline):是一個度量或度量的組合,它可對軟件產品、過程或資源提供更深入的理解。2)度量(metric):對系統(tǒng)、部件或過程的某一特性所具有的程度進行的量化測量。如軟件質量度量等。3)估算(estimation):對軟件產品、過程、資源等使用歷史資料或經(jīng)驗公式等進行預測。如工作量、成本、完成期限等。估算一般用于立項、簽訂合同、制定工作計劃等。當前第9頁\共有141頁\編于星期一\15點2.軟件項目管理的對象及其屬性

軟件項目管理的對象主要包括產品、過程和資源等。產品(product)是指軟件開發(fā)過程得到的文檔和程序。過程(process)是指與軟件項目有關的活動。資源(resource)是指進行軟件項目所需要的各種支持。要對軟件項目管理的對象進行有效的管理與控制,就必須對這些對象的屬性進行測量、度量與估算。一般來說,產品、過程、資源等對象都具有內部屬性和外部屬性。2.1軟件度量當前第10頁\共有141頁\編于星期一\15點對象的屬性對象的內部屬性是指對象本身的屬性,如軟件產品的代碼長度、模塊化的程度、復雜性等。對象的外部屬性體現(xiàn)了對象與環(huán)境的關系,如軟件的可靠性、可維護性、可移植性、成本、人員的生產率等。當前第11頁\共有141頁\編于星期一\15點表2-1軟件工程的產品、過程、資源的屬性

產品過程資源內部屬性程序代碼行長度;程序功能;模塊化;控制流結構;重用性;模塊耦合度與內聚度。工作量;計劃及進度;事件。人員;方法;工具;環(huán)境;經(jīng)驗。外部屬性軟件的可靠性;軟件的可理解性;軟件的有效性;軟件的可用性;軟件的可維護性;軟件的可移植性。成本;可控制性;可觀察性;穩(wěn)定性。成本;生產率;時間。當前第12頁\共有141頁\編于星期一\15點3.軟件度量的分類可分為直接度量和間接度量兩類:1)直接度量。即對不依賴于其他屬性的簡單屬性的測量。如軟件的模塊數(shù)、程序的代碼行數(shù)、操作符的個數(shù),工作量、成本等。2)間接度量。即對涉及若干個其他屬性的軟件要素、準則或屬性的度量。因為它們必須通過建立一定的度量方法或模型才能間接推斷而獲得。如軟件的功能性、復雜性、可靠性、可維護性等等。2.1軟件度量當前第13頁\共有141頁\編于星期一\15點2.1.2面向規(guī)模的度量

面向規(guī)模的度量是以軟件的代碼行(LOC,LineofCode)數(shù)為基礎的直接度量。

L表示軟件的代碼行數(shù),單位為KLOC(千行代碼)或LOC;

E表示開發(fā)軟件所需工作量,單位為人月(PM)或人年(PY);

S表示軟件成本,單位為美元或元;

N表示錯誤個數(shù);

Pd表示軟件文檔頁數(shù);

M表示開發(fā)所用的人數(shù)。當前第14頁\共有141頁\編于星期一\15點1.軟件開發(fā)的生產率P:P=L/E2.開發(fā)每行代碼的平均成本C:C=S/L3.代碼出錯率EQR:EQR=N/L4.軟件的文檔率D:D=Pd/L面向規(guī)模的度量當前第15頁\共有141頁\編于星期一\15點

面向規(guī)模的度量當前第16頁\共有141頁\編于星期一\15點優(yōu)點:簡單、直接。缺點:①代碼行數(shù)的估算依賴于程序設計語言的功能和表達能力。②對設計精巧的軟件項目產生不利影響。③在開發(fā)初期估算代碼行十分困難。④只適用于過程式程序設計語言。

面向規(guī)模的度量當前第17頁\共有141頁\編于星期一\15點2.1.3面向功能的度量1.簡單功能點度量1979年,Albrecht首先提出了功能點度量方法。這是一種面向功能的間接度量方法,即從軟件定義的基本功能出發(fā),來估算軟件系統(tǒng)的規(guī)模。因此,該方法可以在軟件開發(fā)項目的初期,在軟件定義過程中即可預測待開發(fā)軟件的規(guī)模。當前第18頁\共有141頁\編于星期一\15點1.簡單功能點度量功能點FP的度量公式如下:FP=CT×TCF=CT[0.65+0.01∑Fi]其中:CT——基本功能點。CT值按表2-2來計算,它的值為5個參數(shù)加權值的總和。14i=1當前第19頁\共有141頁\編于星期一\15點表2-2簡單功能點度量的基本功能點的計算測量參數(shù)值加權因子加權值簡單一般復雜用戶輸入數(shù)×3×4×6=用戶輸出數(shù)×4×5×7=用戶查詢數(shù)×3×4×6=文件數(shù)×7×10×15=外部接口數(shù)×5×7×10=

基本功能點CT當前第20頁\共有141頁\編于星期一\15點表2-2中的5個參數(shù)的含義1)用戶輸入數(shù):用戶為軟件系統(tǒng)提供的輸入?yún)?shù)的個數(shù)(不包括查詢);2)用戶輸出數(shù):軟件為用戶提供的輸出參數(shù)(報告、屏幕幀、錯誤信息等)的個數(shù);3)用戶查詢數(shù):一次聯(lián)機輸入導致軟件以聯(lián)機輸出方式實時產生一個響應的個數(shù);4)文件數(shù):邏輯主文件的個數(shù);5)外部接口數(shù):機器可讀的接口(如磁盤或磁帶上的數(shù)據(jù)文件等)的個數(shù)。當前第21頁\共有141頁\編于星期一\15點1.簡單功能點度量在FP度量公式中:TCF——技術復雜性調節(jié)因子。0.65和0.01——經(jīng)驗數(shù)據(jù)。Fi(i=1,2,…,14)——復雜性調節(jié)值。Fi所代表的因素如表2-3所示,每個Fi可根據(jù)實際情況取0、1、2、3、4、5中的一個值。其中:0—沒有影響、1—偶然的、2—適中、3—普通、4—重要、5—極重要的影響。TCF取值范圍:0.65~1.35。當前第22頁\共有141頁\編于星期一\15點表2-3Fi

取值表i因素Fii因素Fi1234567需要可靠的備份和恢復嗎?需要數(shù)據(jù)通信嗎?有分布式處理的功能嗎?性能是關鍵嗎?在現(xiàn)存實用的操作環(huán)境下運行嗎?需要聯(lián)機數(shù)據(jù)入口嗎?聯(lián)機數(shù)據(jù)入口需要用輸入信息構造復雜的界面或操作嗎?891011121314

需要聯(lián)機更新主文件嗎?輸入、輸出、文件、查詢復雜嗎?內部處理過程復雜嗎?要求代碼設計可重用嗎?設計中包含轉換和安裝嗎?系統(tǒng)設計支持不同組織的多次安裝嗎?系統(tǒng)設計有利于用戶的修改、使用嗎?當前第23頁\共有141頁\編于星期一\15點2.功能點度量簡單功能點度量方法沒有直接考慮軟件本身的算法的復雜性問題。所以它僅適用于度量算法簡單的事務處理等系統(tǒng)。1986年Jones對簡單功能點度量進行了推廣,在計算軟件系統(tǒng)的基本功能點CT時,引入了算法復雜性因素,即使用表2-4計算CT。我們稱這種推廣的度量方法為功能點度量。這兩種方法對一般的事務處理系統(tǒng)等算法簡單的軟件系統(tǒng)計算出來的FP值基本相同,但對于較復雜的軟件系統(tǒng),功能點度量方法比簡單功能點度量方法計算出來的FP值要高20%~35%。當前第24頁\共有141頁\編于星期一\15點表2-4推廣的功能點度量的基本功能點的計算測量參數(shù)值權值加權值用戶輸入數(shù)×4=用戶輸出數(shù)×5=用戶查詢數(shù)×4=文件數(shù)×7=外部接口數(shù)×7=復雜算法數(shù)×3=基本功能點CT當前第25頁\共有141頁\編于星期一\15點用功能點計算軟件項目的有關參考量:1)生產率P:P=FP/E2)平均成本C:C=S/FP3)代碼出錯率EQR:EQR=N/FP4)軟件的文檔率D:D=Pd/FP

當前第26頁\共有141頁\編于星期一\15點3.功能點度量方法的優(yōu)缺點優(yōu)點:①可用于軟件項目開發(fā)的初期階段的項目估算。②與程序設計語言無關。缺點:①某些參考量的收集有一定困難;②度量值的主觀因素較多,如Fi取值;③功能點FP本身沒有直觀的物理意義。當前第27頁\共有141頁\編于星期一\15點2.2軟件項目估算常用的軟件項目的估算方法主要有以下4種1.自頂向下的估算方法2.自底向上的估算方法3.差別估算法4.根據(jù)經(jīng)驗估算公式2.2.1軟件項目的估算方法當前第28頁\共有141頁\編于星期一\15點1.自頂向下的估算方法基本思想:首先根據(jù)已完成項目的總成本或總工作量來推算待開發(fā)軟件的總成本或總工作量,然后再按比例將其分配到各開發(fā)任務中去。即從整體到局部。優(yōu)點:估算工作量小、速度快。缺點:對項目中的特殊困難估計不足,有可能產生遺漏,估算出的值盲目性較大。當前第29頁\共有141頁\編于星期一\15點2.自底向上的估算方法基本思想是:把待開發(fā)軟件細分,直到每一個子任務或階段都已經(jīng)明確所需要的開發(fā)工作量或成本,然后再把它們累加起來,得到待開發(fā)軟件的總工作量或總成本。優(yōu)點:計算各個部分的準確性較高。缺點:缺少各個子任務之間相互聯(lián)系的工作量和系統(tǒng)工作量(如項目管理、配置管理、質量管理),估算值往往偏低,必須用其他方法進行校正。當前第30頁\共有141頁\編于星期一\15點3.差別估算法基本思想:把待開發(fā)的軟件項目與過去完成的軟件項目進行比較,從各子任務中區(qū)分出類似的和不同的部分。類似的部分按已知的實際量計算,不同的部分則采用某種方法進行估算。差別估算法綜合了以上兩種方法的優(yōu)點。優(yōu)點:估算的準確程度高。缺點:不容易劃分相似的界限。當前第31頁\共有141頁\編于星期一\15點4.根據(jù)經(jīng)驗估算公式通過眾多實際軟件項目的經(jīng)驗,總結出一些有價值的軟件成本和工作量估算的經(jīng)驗模型。這些模型對于軟件項目管理具有一定的指導意義和驗證效果。當前第32頁\共有141頁\編于星期一\15點2.2.2代碼行和功能點的估算采用中介紹的估算方法可以估算出代碼行或功能點的樂觀值a、一般值m和悲觀值b,并用如下的加權平均公式計算LOC或FP的期望值(expectation):X=(a+4m+b)/6軟件的LOC或FP的期望值估算出來后,就可以根據(jù)已有的標準生產率對成本和工作量等進行估算了。當前第33頁\共有141頁\編于星期一\15點2.2.3軟件項目的經(jīng)驗估算模型1.IBM模型(靜態(tài)單變量模型)數(shù)據(jù)利用最小二乘法擬合,得到的經(jīng)驗估算公式:E=5.2×L0.91D=4.1×L0.36=2.136×E0.3956S=0.54×E0.6DOC=49×L1.01當前第34頁\共有141頁\編于星期一\15點2.Putnam模型(動態(tài)多變量模型)該模型以工作量在30人年以上的大型軟件項目的實測數(shù)據(jù)為依據(jù),推導出了工作量分布曲線,如圖2-2-1所示。2.2.3軟件項目的經(jīng)驗估算模型當前第35頁\共有141頁\編于星期一\15點圖2-2-1軟件項目的工作量分布曲線系統(tǒng)定義功能設計規(guī)格說明設計編碼測試和確認維護管理系統(tǒng)定義、需求分析開發(fā)運行維護0開發(fā)占總工作量的40%維護占總工作量的60%總工作量td時間t(年)工作量(人年)圖2-2-1軟件項目的工作量分布曲線當前第36頁\共有141頁\編于星期一\15點2.Putnam模型Putnam估算模型如下:L=CkE1/3td4/3Ck為技術狀態(tài)常數(shù),與開發(fā)環(huán)境有關,如下:2000較差,沒有方法學的支持,缺乏文檔和評審,采用批處理方式;Ck

=8000一般,有方法學的支持,有適當?shù)奈臋n和評審,采用交互處理方式;11000較好,有集成化的CASE工具和環(huán)境。E=L3/(Ck3td4)當前第37頁\共有141頁\編于星期一\15點圖2-2-2人力資源的分配初級技術人員高級技術人員管理人員驗收測試組裝測試單元測試編碼詳細設計概要設計需求分析系統(tǒng)定義人數(shù)當前第38頁\共有141頁\編于星期一\15點Putnam模型的優(yōu)缺點優(yōu)點:揭示了軟件項目的源程序代碼長度、軟件開發(fā)時間和工作量三者之間的關系,在理論上有重要意義。缺點:準確程度不高。沒有反映軟件產品、項目、參加人員、軟硬件資源等屬性。當前第39頁\共有141頁\編于星期一\15點3.CoCoMo模型(構造性成本模型)CoCoMo模型按其詳細程度分三個層次:

基本CoCoMo模型;

中間CoCoMo模型;

詳細CoCoMo模型。2.2.3軟件項目的經(jīng)驗估算模型當前第40頁\共有141頁\編于星期一\15點(1)基本CoCoMo模型其工作量和開發(fā)時間的估算公式如下:E=aLb

D=cEd

其中:L——軟件代碼行的估算值(以KLOC計);E——工作量(以PM計);D——開發(fā)時間(以月計);a、b、c、d——經(jīng)驗常數(shù)。當前第41頁\共有141頁\編于星期一\15點表2-8a、b、c、d參數(shù)值的選取軟件類型abcd適應領域組織型2.41.052.50.38一般應用程序半獨立型3.01.122.50.35實用程序、編譯程序等嵌入型3.61.202.50.32實時控制程序、操作系統(tǒng)當前第42頁\共有141頁\編于星期一\15點(2)中間CoCoMo模型中間CoCoMo模型在估算工作量時,在基本CoCoMo模型的基礎上再乘以由15個因素組成的工作量調節(jié)因子EAF,于是有:E=aLbEAF=aLb∏Fi

其中:L——軟件的代碼行數(shù)(以KLOC計);E——工作量(以PM計);a、b——經(jīng)驗常數(shù);i=115當前第43頁\共有141頁\編于星期一\15點表2-9a、b參數(shù)的取值軟件類型ab組織型3.21.05半獨立型3.01.12嵌入型2.81.20當前第44頁\共有141頁\編于星期一\15點(2)中間CoCoMo模型工作量調節(jié)因子EAF與軟件的產品的取值屬性、計算機屬性、人員屬性、項目屬性等因素有關。這15個因素Fi(i=1~15)的值可按等級取值,即可分為很低、低、正常、高、很高、極高,共6級。正常情況下Fi=1。Boehm推薦的Fi值的范圍是.70~1.66,F(xiàn)

i的值可根據(jù)實際情況按表2-10來選取。工作量E求出之后,就可以用公式(2-18)即D=cEd計算出開發(fā)時間D。當前第45頁\共有141頁\編于星期一\15點(3)詳細CoCoMo模型詳細CoCoMo模型的基本工作量(指EAF=1時的工作量)公式、開發(fā)時間公式與中間CoCoMo模型相同。所不同的是詳細CoCoMo模型在計算EAF時針對每個影響因素,分層次(系統(tǒng)層、子系統(tǒng)層、模塊層)并按軟件生存周期分階段給出工作量因素的分級表。詳細CoCoMo模型可以更準確地估算軟件項目的工作量。當前第46頁\共有141頁\編于星期一\15點表2-11子系統(tǒng)層軟件可靠性工作量因素分級表

階段可靠性級別需求分析和概要設計詳細設計編碼及單元測試集成及測試綜合很低0.800.800.800.600.75低0.900.900.900.800.88正常1.001.001.001.001.00高1.101.101.101.301.15很高1.301.301.301.701.40當前第47頁\共有141頁\編于星期一\15點通信數(shù)圖2-2-4N=3和N=5時的通信數(shù)當前第48頁\共有141頁\編于星期一\15點成功的標準:2.3軟件質量度量失敗的根本原因:

用戶在用用戶可很容易做完要做的事開發(fā)人員寫出的東西達不到用戶要求(人的問題、技術問題)當前第49頁\共有141頁\編于星期一\15點不貪污的官就是好官嗎“運行正確”的程序就是高質量的程序嗎?也許運行速度很低并且浪費內存;也許代碼寫得一塌糊涂

當前第50頁\共有141頁\編于星期一\15點2.3.1軟件質量的定義軟件質量是軟件產品滿足規(guī)定的和隱含的與需求能力有關的全部特征和特性,包括:1.軟件產品滿足用戶要求的程度;2.軟件擁有所期望的各種屬性的組合程度;3.用戶對軟件產品的綜合反映程度;4.軟件在使用過程中滿足用戶需求的程度。當前第51頁\共有141頁\編于星期一\15點2.3.2軟件質量的度量模型1976年,Boehm提出了定量度量軟件質量的概念,他給出了軟件質量的層次模型,并給出了60個軟件質量度量公式;1978年,Walters和McCall提出了三層次軟件質量度量模型;1985年,ISO提出了SQM(SoftwareQualityMetric,軟件質量度量)工作報告等等。當前第52頁\共有141頁\編于星期一\15點1.McCall等人的軟件質量度量模型McCall等人提出了由軟件質量要素、評價準則、定量度量三個層次組成的三層次度量模型。其中:第一層是將對軟件質量的度量歸結為對直接影響軟件質量的若干個軟件質量要素的度量;第二層是用若干個可度量的評價準則來間接度量軟件質量要素;第三層是對相應評價準則的直接度量。當前第53頁\共有141頁\編于星期一\15點圖2-3-1軟件質量三層次度量模型要素j評價準則1評價準則2評價準則L度量1度量2度量L……當前第54頁\共有141頁\編于星期一\15點2.軟件質量要素當時McCall等人認為,軟件質量由11個軟件質量要素來衡量。這11個質量要素可劃分為三類:面向運行特征的軟件質量要素有正確性、可靠性、有效性、完整性和可用性;面向軟件承受修改的質量要素有可維護性、靈活性、可測試性;面向轉移的軟件質量要素有可移植性、可重用性、可互操作性。這三類要素構成了軟件質量的三個側面,如圖2-3-2所示。當前第55頁\共有141頁\編于星期一\15點圖2-3-2軟件質量要素的構成產品修正產品轉移產品運行可維護性靈活性可測試性可移植性可重用性可互操作性正確性可靠性有效性完整性可用性當前第56頁\共有141頁\編于星期一\15點質量要素概念1)正確性(correctness):指程序滿足需求規(guī)格說明及用戶目標的程度;2)可靠性(reliability):指在給定的時間間隔內,程序成功運行的概率??煽啃允呛饬寇浖|量的一個重要目標。3)有效性(efficiency):指軟件系統(tǒng)的時間和空間效率。這是一個應當努力追求的重要目標。4)完整性(integrity):指對未授權人員訪問程序或數(shù)據(jù)加以控制的程度;5)可用性(usability):指學習使用軟件(即操作軟件、準備輸入數(shù)據(jù)、解釋輸出結果等)的難易程度;當前第57頁\共有141頁\編于星期一\15點質量要素概念1)靈活性(flexibility):指改變一個操作的順序所需工作量的多少;2)可測試性(testability):指測試軟件以便使其具有預定功能所需工作量的多少;3)可維護性(maintainability):指軟件產品交付使用后,在實現(xiàn)改正潛伏的錯誤、改進性能等屬性、適應環(huán)境變化等方面工作的難易程度。當前第58頁\共有141頁\編于星期一\15點1)可互操作性(interoperability):指程序與其他系統(tǒng)相互交換并使用信息的能力。2)可重用性(reusability):指軟部件可以在多種場合使用的程度。3)可移植性(portability):指軟件從一個計算機系統(tǒng)或環(huán)境移植到另一個上去的難易程度。質量要素概念當前第59頁\共有141頁\編于星期一\15點2.軟件質量要素軟件質量要素不是獨立的,一個要素可能與其他幾個要素有關系,如表2-12所示,其中:正相關以“√”表示,負相關以“×”表示。對于具有負相關的質量要素,在開發(fā)時應根據(jù)具體情況加以取舍或進行折衷。例如,對于實時控制系統(tǒng),必須確保系統(tǒng)的可靠性和有效性,而軟件的可重用性、可移植性等質量要素就可以放寬要求。當前第60頁\共有141頁\編于星期一\15點表2-12質量要素間的關系關系要素要素正確性可靠性有效性完整性可用性可維護性靈活性可測試性可移植性可重用性可互操作性正確性

可靠性√有效性完整性×

可用性√√×

√可維護性√√×

√靈活性√√×

×

√√可測試性√√×

√√√可移植性×

√√可重用性×

×

×

√√√√可互操作性×

×

√當前第61頁\共有141頁\編于星期一\15點3.軟件質量要素的評價準則

軟件質量要素一般很難直接測量。為了對11個要素進行度量,McCall等人通過確定影響軟件質量要素的屬性,定義了21個軟件質量要素的評價準則。這些評價準則既能夠比較完整、準確地描述軟件質量要素,又比較容易測量。通過這組評價準則就可以間接測量軟件質量要素,進而度量整個軟件質量。當前第62頁\共有141頁\編于星期一\15點評價準則新概念1)可審查性(audit-ability):檢查軟件需求、文檔、過程、標準等是否一致的難易程度;2)準確性(accuracy):計算和控制的精確程度;3)簡明性(conciseness):程序源代碼的緊湊程度;4)通信通用性(communicationcommonality):使用標準接口、協(xié)議和帶寬的程度;5)數(shù)據(jù)通用性(datacommonality):在程序中使用標準數(shù)據(jù)結構和類型的程度;6)容錯性(error-tolerance):在各種異常情況下軟件能繼續(xù)提供操作的能力;當前第63頁\共有141頁\編于星期一\15點評價準則新概念7)執(zhí)行效率(executionefficiency):軟件運行效率;8)可擴充性(expandability):結構、數(shù)據(jù)、過程等設計可以擴充的程度;9)通用性(generality):程序潛在應用領域的多少;10)硬件獨立性(hardwareindependence):軟件與其運行的硬件環(huán)境無關的程度;11)檢測性(instrumentation):程序監(jiān)視自身運行并標識錯誤的程度;12)可操作性(operability):操作該軟件的難易程度;當前第64頁\共有141頁\編于星期一\15點評價準則新概念13)安全性(security):控制或保護程序和數(shù)據(jù)不被破壞、非法訪問等機制的能力;14)自文檔化(self-documentation):源代碼提供自身說明文檔的程度;15)簡單性(simplicity):程序易于理解的程度;16)軟件獨立性(softwareindependence):軟件與非標準編程語言特征、操作系統(tǒng)特征等軟件環(huán)境約束無關的程度;17)易培訓性(training):軟件對使用它的新用戶的支持程度。當前第65頁\共有141頁\編于星期一\15點18)可追蹤性(traceability):是指根據(jù)軟件需求對軟件設計、程序進行正向追蹤,或根據(jù)程序、軟件設計對軟件需求進行逆向追蹤的能力。19)模塊化(modularity):把一個程序劃分成若干個模塊,每個模塊完成一個子功能,將這些模塊組裝成一個整體,即可完成該程序指定的功能。20)一致性(consistency):整個軟件系統(tǒng)(包括程序、數(shù)據(jù)和文檔)的各個模塊應使用一致的概念、符號和術語;程序內部接口應保持一致;軟件與環(huán)境的接口應保持一致;系統(tǒng)規(guī)格說明應與系統(tǒng)行為保持一致;用于形式化規(guī)格說明的公理系統(tǒng)應保持一致。21)完全性(completeness):軟件系統(tǒng)不丟失任何重要成分,完全實現(xiàn)所需的系統(tǒng)功能的程度。評價準則新概念當前第66頁\共有141頁\編于星期一\15點表2-13質量要素與評價準則的關系評價準則關系質量要素可追蹤性完全性一致性容錯性準確性簡單性可操作性執(zhí)行效率可審查性檢測性安全性數(shù)據(jù)通用性可擴充性通用性硬件獨立性簡明性通信通用性自文檔化軟件獨立性易培訓性模塊化正確性√√√可靠性√√√√有效性√√√完整性√√√可用性√√可維護性√√√√√√靈活性√√√√√√√可測試性√√√√√可移植性√√√√√可重用性√√√√√可互操作性√√√√當前第67頁\共有141頁\編于星期一\15點4.軟件質量要素的度量第j種軟件質量要素Fj(j=1,2,…,11)的計算公式為:Fj=∑CjkMk其中:Mk是第j種軟件質量要素Fj對第k種評價準則的測量值。評價準則多數(shù)只能按主觀想法定值。McCall將每個評價準則都劃分為0~10級,并且Mk的值可以在0,0.1,0.2,…,1.0中取一個。加權系數(shù)Cjk滿足∑Cjk=1,Cjk≥0。Cjk=0表示質量要素與第k種評價準則無關。當前第68頁\共有141頁\編于星期一\15點4.軟件質量要素的度量例如,要度量某軟件的F2(可靠性)假設C23=0.1,C24=0.3,C25=0.4,C26=0.2,其余的C2k=0,而M3=0.7、M4=0.6、M5=0.5,M6=0.8,則可靠性的度量值為:F2=C23M3+C24M4+C25M5+C26M6=0.1×0.7+0.3×0.6+0.4×0.5+0.2×0.8=0.61當前第69頁\共有141頁\編于星期一\15點ISO三層次軟件質量度量模型。1985年,國際標準化組織也提出了三層次軟件質量度量模型。其中:高層稱為軟件質量需求評價準則(SQRC),并由正確性、可容性、有效性、安全性、可用性、可維護性、靈活性、可互操作性等8個要素組成;中層稱為軟件質量設計評價準則(SQDC),并由可追蹤性、完全性…、等共23個評價準則組成;低層稱作軟件質量度量評價準則(SQMC)。當前第70頁\共有141頁\編于星期一\15點2.4軟件復雜性度量通過軟件的復雜性度量值可以估算出軟件中故障的數(shù)量;也能估算出軟件開發(fā)所需的工作量;定量度量的結果還可以用于比較不同設計方案的優(yōu)劣。同時,軟件的復雜性也能從某些方面影響軟件的可維護性、可靠性等軟件質量要素。因此,軟件復雜性度量是軟件度量的一個重要組成部分。當前第71頁\共有141頁\編于星期一\15點2.4.1軟件復雜性的概念及度量原則

1.軟件復雜性的概念K.Magel從6個方面來描述軟件復雜性:1)理解程序的難度;2)維護程序的難度;3)向其他人解釋程序的難度;4)按指定方法修改程序的難度;5)根據(jù)設計文件編寫程序的工作量;6)執(zhí)行程序時需要資源的多少。軟件復雜性反映了軟件的可理解性、模塊化、簡單性等屬性。當前第72頁\共有141頁\編于星期一\15點2.軟件復雜性度量的原則軟件復雜性的度量,的一些基本原則:1)軟件的復雜性與其規(guī)模的關系不是線性的;2)數(shù)據(jù)結構復雜的程序較復雜;3)控制結構復雜的程序較復雜;4)轉向語句使用不當?shù)某绦蜉^復雜;5)循環(huán)結構比選擇結構復雜、選擇結構比順序結構復雜;6)語句、數(shù)據(jù)、子程序模塊等出現(xiàn)的順序對復雜性有影響;當前第73頁\共有141頁\編于星期一\15點2.軟件復雜性度量的原則7)非局部變量較多的程序較復雜;8)參數(shù)按地址調用(Callbyreference)比按值調用(Callbyvalue)復雜;9)函數(shù)副作用比顯式參數(shù)傳遞難理解;10)作用不同的變量同名時較難理解;11)模塊、過程間聯(lián)系密切的程序較復雜;12)程序嵌套層數(shù)越多越復雜。以上這些基本原則是指導我們進一步研究定量度量軟件復雜性的基礎。當前第74頁\共有141頁\編于星期一\15點2.4.2McCabe度量模型該方法是把程序流程圖轉化為程序圖:即把程序看成是有一個入口結點和一個出口結點的有向圖,圖中每個結點對應一個語句、一個簡單判斷或一個順序流程的代碼塊,原來程序流程圖中的箭頭變成連接各結點的有向?。ɑ蚍Q為邊)。一般地,可以假設從程序圖中的開始結點可以到達圖中的任一結點,而從圖中的任一結點都可以到達出口結點。程序圖又稱為程序控制結構圖或程序流圖。當前第75頁\共有141頁\編于星期一\15點2.4.2McCabe度量模型McCabe給出了程序控制結構圖G的巡回秩數(shù)V(G)作為程序控制結構復雜性的度量,其度量模型為:V(G)=E–N+2其中:E——程序圖G中邊的總數(shù);N——程序圖中結點的總數(shù)。V(G)又稱為圖G的環(huán)形復雜度??梢宰C明,V(G)的值等于結構圖中有界和無界的封閉區(qū)域的個數(shù)。當前第76頁\共有141頁\編于星期一\15點R1圖2-4-1三種基本結構的程序圖R1R2R1R2(a)順序結構V(G)=E–N+2=1–2+2=1

(b)選擇結構V(G)=E–N+2=4–4+2=2(c)while結構R1R2V(G)=E–N+2=3–3+2=2(d)until結構V(G)=E–N+2=3–3+2=2當前第77頁\共有141頁\編于星期一\15點2.4.2McCabe度量模型程序結構的復雜性度量值V(G)取決于程序控制流的復雜程度。當程序內的分支數(shù)和循環(huán)數(shù)增加時,V(G)值將隨之增加,即程序的復雜性增大。McCabe研究大量程序后指出,V(G)可作為程序規(guī)模的定量指標,V(G)值越高的程序往往是越復雜、越容易出問題的程序。McCabe建議模塊規(guī)模應滿足:V(G)≤10當前第78頁\共有141頁\編于星期一\15點【例2.5】程序流程圖如圖2-4-2所示,試求出其巡回秩數(shù)V(G)解:(1)畫出程序流程圖對應的程序圖。開始abchgfdei結束圖2-4-3程序圖abcfghdeiR1R2R3R41234567891011圖2-4-2程序流程圖當前第79頁\共有141頁\編于星期一\15點【例2.5】程序流程圖如圖2-4-2所示,試求出其巡回秩數(shù)V(G)(2)由程序圖(或流圖)可得:abcfghdeiR1R2R3R41234567891011(3)由程序圖可以看出,其有界區(qū)域有R1、R2、R3共3個,還有1個無界區(qū)域R4,共4個封閉區(qū)域,所以:V(G)=E–N+2=11–9+2=4

V(G)=4當前第80頁\共有141頁\編于星期一\15點2.4.3Halstead度量模型20世紀70年代初,Halstead給出了稱為文本復雜性度量的模型。它是根據(jù)統(tǒng)計程序中的操作符和操作數(shù)的個數(shù)來度量程序的復雜程度。程序可以看成是由操作符和操作數(shù)組成的符號序列。操作符是指程序中出現(xiàn)的語法符號,如+、–、if-then-else、while等。操作數(shù)是操作對象,如程序中定義或使用的變量、常量、數(shù)組、指針等。令:N1為程序中操作符出現(xiàn)的總個數(shù),N2為程序中操作數(shù)出現(xiàn)的總個數(shù)。則程序的語言符號長度N定義為:N=N1+N2。當前第81頁\共有141頁\編于星期一\15點2.4.3Halstead度量模型如果已經(jīng)測得程序中不同操作符的個數(shù)n1和不同操作數(shù)的個數(shù)n2,則程序的長度N可用下式來估算:N≈n1log2n1+n2log2n2Halstead用下式來定義程序量(即程序在詞匯上的復雜性):V=Nlog2(n1+n2)Halstead還給出了預測錯誤數(shù)的公式如下:E=Nlog2(n1+n2)/3000當前第82頁\共有141頁\編于星期一\15點2.4.3Halstead度量模型可以對多個某種程序設計語言的程序進行統(tǒng)計分析,從而得出每千代碼行(KLOC)或每個功能點(FP)所包含的操作符和操作數(shù)個數(shù)CL或CF,于是,可以將程序語言符號長度N折合成相應的代碼行數(shù)或功能點數(shù)。當前第83頁\共有141頁\編于星期一\15點2.5軟件可靠性度量

軟件可靠性定義為在某個給定時間間隔內,程序按照規(guī)格說明成功運行的概率。當前第84頁\共有141頁\編于星期一\15點1.軟件可靠性令:隨機變量t表示發(fā)生故障的時刻,t∈[0,∞];函數(shù)f(t)為隨機變量t的概率密度函數(shù),F(xiàn)(t)表示分布函數(shù);P(0≤t≤t1)表示從初始時刻到t1時刻程序發(fā)生故障的概率。設:初始時刻程序運行正常,即F(0)=0。于是有:F(t)=∫f(x)dxf(t)=dF(t)dt0t當前第85頁\共有141頁\編于星期一\15點令:Pf(t1)表示從0到t1時刻程序發(fā)生故障的概率,有:Pf(t1)=P(0≤t≤t1)=F(t1)–F(0)=F(t1)如果在[0,t]區(qū)間程序成功運行的概率為Ps(t)、發(fā)生故障的概率為Pf(t),則有:Ps(t)+Pf(t)=1Ps(t)就是可靠性,一般標記為R(t)。由以上幾個式子可導出:R(t)=1–Pf(t)=1–F(t)=1–∫f(x)dx上式說明,當軟件殘留的錯誤數(shù)一定時,程序運行的時間越長,發(fā)生故障的次數(shù)越多,軟件的可靠性越小。0t當前第86頁\共有141頁\編于星期一\15點下面引入故障率函數(shù)Z(t),以比較一個程序在不同時期、或不同程序在同一時期的可靠性。設系統(tǒng)一直成功運行至時刻t,t∈[t1,t1+△t],P(t1≤t≤t1+△t,t>t1)是系統(tǒng)在[t1,t1+△t]時間間隔且t>t1時發(fā)生故障的概率。故障率函數(shù)Z(t1)的值定義為:Z(t1)=limP(t1≤t≤t1+△t,t>t1)/△t可以證明:Z(t)=·對前式的兩端對時間t求導得:dF(t)/dt=–dR(t)/dt,代入上式,得:

=–Z(t)dt

1R(t)dF(t)d(t)dR(t)R(t)當前第87頁\共有141頁\編于星期一\15點對上式兩端積分,利用初始條件R(0)=1,可得:R(t)=exp[–∫Z(x)dx]

上式即為可靠性和故障率的基本方程式。據(jù)此可以導出幾個常用的故障模型:Z(t)=λ,其中λ是常數(shù)。將λ代入式前式,可得:R(t)=e–λt上式稱為故障率為常數(shù)的可靠性模型。由于故障率是常數(shù),可靠性將隨著時間t的增加呈指數(shù)衰減。t0當前第88頁\共有141頁\編于星期一\15點Z(t)=kt,這里k為常數(shù),t≥0。將kt代入前式可得:

R(t)=e–kt2/2

上式稱為故障率是時間的線性函數(shù)時的可靠性模型。即當存在損耗和退化時,故障率將隨著時間的增加而線性增加。該模型一般不適合于軟件產品。需要指出,軟件中的錯誤一般都是人為的設計錯誤,其中多數(shù)是邏輯錯誤。隨著對軟件的測試及修復,軟件系統(tǒng)中的錯誤會越來越少。因此,實際軟件系統(tǒng)的故障率函數(shù)曲線應如圖2-5-1所示,即軟件故障率不是常數(shù)、也不是線性函數(shù),而是按指數(shù)規(guī)律下降。實際的統(tǒng)計結果也說明了這一點。當前第89頁\共有141頁\編于星期一\15點圖2-5-1軟件系統(tǒng)故障率Z(t)Ot當前第90頁\共有141頁\編于星期一\15點2.軟件的有效性及其度量軟件的有效性函數(shù)A(t)定義為軟件系統(tǒng)在時刻t按照規(guī)格說明成功運行的概率??煽啃耘c有效性之間的差別是,可靠性強調軟件系統(tǒng)在0~t這段時間間隔內都有效,而有效性強調軟件系統(tǒng)在時刻t這一時間點有效。A(200)=0.93表示假設有100個相同的系統(tǒng)同時啟動運行,運行到200小時這一時刻,其中有93個處于正常運行狀態(tài),7個出現(xiàn)故障,等待修復。R(200)=0.93表示假設有100個相同的系統(tǒng)有93個無故障運行了200小時,有7個在此期間發(fā)生故障。當前第91頁\共有141頁\編于星期一\15點2.軟件的有效性及其度量一般來說,對R(200)=0.93的要求比對A(200)=0.93的要求要嚴格得多。對于不可修復系統(tǒng)(即不允許程序停止運行的系統(tǒng))或沒有修復能力的情況:A(t)=R(t)對于可修復系統(tǒng)并能及時修復的情況:A(t)≥R(t)。當前第92頁\共有141頁\編于星期一\15點軟件穩(wěn)態(tài)有效性的兩種度量方法1)軟件系統(tǒng)投入運行后,在一段時間內,可統(tǒng)計軟件系統(tǒng)的故障停機時間tdi和正常運行時間tuj,則軟件系統(tǒng)的穩(wěn)態(tài)有效性為:A(t)=Tu/(Tu+Td)其中:t=Tu+Td,Td=∑tdi,Tu=∑tuj當前第93頁\共有141頁\編于星期一\15點軟件穩(wěn)態(tài)有效性的兩種度量方法2)軟件系統(tǒng)在穩(wěn)態(tài)運行時,可統(tǒng)計其平均故障間隔時間MTBF(meantimebetweenfailurs,即程序正常運行時間的平均值)和平均修復時間MTTR(meantimetorepair,即平均停機時間),則軟件系統(tǒng)的穩(wěn)態(tài)有效性為:A=MTBF/(MTBF+MTTR)采用上述方法,在開發(fā)階段和投入運行后都可以定量地度量軟件系統(tǒng)的有效性和可靠性。軟件系統(tǒng)投入運行的一段時間內,可以用各種輸入和操作來引發(fā)程序中殘留的錯誤,經(jīng)過多次修復后錯誤將逐漸減少,有效性和可靠性將不斷提高。當前第94頁\共有141頁\編于星期一\15點2.5.2軟件可靠性的估算軟件可靠性估算模型大致分為宏觀和微觀模型兩類。宏觀模型是從程序中殘留錯誤數(shù)的角度建立模型,并用統(tǒng)計方法確定模型參數(shù)。而微觀模型則以程序的控制結構和語句分析為基礎。下面僅介紹幾個典型的宏觀模型。1.殘留錯誤總數(shù)的估算模型對殘留錯誤總數(shù)的估算是可靠性估算的基礎。典型的估算模型:錯誤植入模型;分別測試模型。當前第95頁\共有141頁\編于星期一\15點1)錯誤植入模型Mills首先提出了估算程序中殘留錯誤總數(shù)的錯誤植入模型。即在進行測試之前,由專人(比如統(tǒng)計人員)在程序中隨機地植入一些錯誤(稱為帶有標記的錯誤),測試人員測試之后,通過統(tǒng)計測試人員發(fā)現(xiàn)的原有錯誤和植入錯誤的比例來估算程序中原有錯誤總數(shù)。設:Nt—植入的錯誤數(shù),n—測試發(fā)現(xiàn)原有的錯誤數(shù),nt—發(fā)現(xiàn)植入的錯誤數(shù),ET—原有的錯誤總數(shù)。則有:ET/Nt≈n/nt于是ET的估算模型為:ET=Nt·n/nt

當前第96頁\共有141頁\編于星期一\15點2)分別測試模型1973年,Hyman對錯誤植入模型做了改進,即用甲、乙兩個程序測試員同時對一個程序的兩個副本進行獨立測試。設:ET——程序中原有的殘留錯誤總數(shù),E1——甲在[0,τ]時間內發(fā)現(xiàn)的錯誤數(shù),E2——乙在[0,τ]時間內發(fā)現(xiàn)的錯誤數(shù),E0——兩人在[0,τ]時間內發(fā)現(xiàn)的相同的錯誤的個數(shù),則有:ET=E1·E2/E0

Hyman提出的分別測試模型無論在技術上還是在經(jīng)濟上都比錯誤植入模型優(yōu)越。當前第97頁\共有141頁\編于星期一\15點2.軟件平均故障間隔時間的估算軟件的平均故障間隔時間MTBF是可靠性度量的一個重要參數(shù),往往作為一個重要的質量指標由用戶提出來。下面介紹MTBF的估算方法。1)軟件故障率為常數(shù)當軟件故障率λ為常數(shù)時,假設程序運行H小時,共發(fā)生r次故障,則λ的估算值為:λ≈r/H于是有:MTBF=1/λ=H/r當前第98頁\共有141頁\編于星期一\15點2)軟件故障率與程序殘留錯誤數(shù)成正比設:IT—程序代碼長度;ET—測試之前程序中殘留錯誤總數(shù);Ec(τ)—[0,τ]區(qū)間內改正的錯誤數(shù);Er(τ)—在τ時刻程序中剩余的錯誤數(shù);其中τ為調試和排錯時間。于是,剩余的錯誤數(shù)為:Er(τ)=ET–Ec(τ)當前第99頁\共有141頁\編于星期一\15點2)軟件故障率與程序殘留錯誤數(shù)成正比Er(τ)=ET–Ec(τ)用IT去除上式的兩邊,有:Er(τ)/IT=ET/IT–Ec(τ)/IT令:εr(τ)=Er(τ)/IT,εT=ET/IT,εc(τ)=Ec(τ)/IT,于是有:εr(τ)=εT–εc(τ)當前第100頁\共有141頁\編于星期一\15點2)軟件故障率與程序殘留錯誤數(shù)成正比由于軟件故障率λ=λ(τ)與程序殘留錯誤數(shù)成正比,所以有:λ=kεr(τ)=k(εT–εc(τ))其中的比例因子k可通過實驗測試和統(tǒng)計的方法來估算。設進行n次軟件排錯實驗,時間區(qū)間為[0,τj],到τj時刻為止,共排除了Ec(τj)個錯誤,而在時間區(qū)間[0,τj]內,程序運行了Hj小時,出現(xiàn)了rj個錯誤,j=1,2,…,n。此時k的估計值為:

k

=∑rj/∑Hj[εT–εc(τj)]nj=1nj=1當前第101頁\共有141頁\編于星期一\15點2)軟件故障率與程序殘留錯誤數(shù)成正比k

=∑rj/∑Hj[εT–εc(τj)]當n=1時,

k=r/H[εT–εc(τ)]當n=2時,k=(r1+r2)/{H1[εT–εc(τ1)]++H2[εT–εc(τ2)]}k的值估算出來之后,即可利用公式估算MTBF,它是τ的函數(shù)。當前第102頁\共有141頁\編于星期一\15點2)軟件故障率與程序殘留錯誤數(shù)成正比對于確定的τ值,λ=kεr(τ)為常數(shù),于是,經(jīng)過[0,τ]區(qū)間的排錯后,軟件可靠性估算為:R(t)=exp[–kεr(τ)t]=exp(–t/MTBF)上式中時間參數(shù)τ以月計,表示對程序調試和維護的時間,t∈[0,τ],以小時計,表示程序運行的時間。上式可理解為經(jīng)過τ個月的調試后所達到的軟件可靠性。當前第103頁\共有141頁\編于星期一\15點2.6軟件開發(fā)過程的管理為達到軟件工程的目標,必須對軟件開發(fā)項目的工作范圍、所需的工作量和成本、必需的人力和軟硬件資源、可能遇到風險、進度的安排、待實現(xiàn)的任務、經(jīng)歷的里程碑等進行管理。軟件開發(fā)過程的管理應在所有技術工作開始之前啟動,直至軟件工程過程的結束。當前第104頁\共有141頁\編于星期一\15點軟件開發(fā)項目管理過程主要包括以下幾個方面:1.啟動一個軟件項目

2.成本估算3.風險分析4.進度安排5.追蹤和控制當前第105頁\共有141頁\編于星期一\15點風險分析風險的特點:①不確定性,某項風險可能發(fā)生也可能不發(fā)生;②損失,一旦某項風險變成了現(xiàn)實,就必然會給項目帶來不良的影響和損失,甚至災難性后果。(1)按照風險的影響范圍分類

①項目風險

②技術風險

③商業(yè)風險2.風險分類:

(2)按照風險的可預測性分類

①已知風險

②可預測的風險

③不可預測的風險當前第106頁\共有141頁\編于星期一\15點風險分析3.風險分析的三個主要活動:

風險標識;風險估算;處理風險的策略。

Ifyoudon’tactivelyattacktherisks,theywillactivelyattackyou.——TomGilb(1988)當前第107頁\共有141頁\編于星期一\15點1.風險標識Boehm建議使用各類風險檢測表來標識風險。在風險檢測表中列出所有可能的與每一個風險因素有關的問題。包括產品規(guī)模風險檢測表、商業(yè)風險檢測表、客戶風險檢測表、過程風險檢測表、開發(fā)環(huán)境風險檢測表、技術風險檢測表、人員風險檢測表等等。例如,“人員風險檢測表”可如表2-14所示。

在表2-14中,可以根據(jù)實際情況選用0、1、2、3、4、5來回答每一個問題,某個問題取值越大表示該項風險也越大。人員風險檢測表反映了人的因素可能對軟件項目的影響。當前第108頁\共有141頁\編于星期一\15點表2-14人員風險檢測表序號問題回答(0、1、2、3、4、5}1開發(fā)人員的水平如何?22開發(fā)人員在技術上是否配套?13是否有足夠的人員可用?04開發(fā)人員是否能自始至終參加軟件項目的工作?25開發(fā)人員是否能把全部精力投入到軟件開發(fā)工作中?26開發(fā)人員對自己的工作是否有正確的期望?17開發(fā)人員是否已接受了必要的培訓?08開發(fā)人員的流動是否還能保證工作的連續(xù)性?3當前第109頁\共有141頁\編于星期一\15點2.風險估算——風險預測風險預測(也稱為風險估算)試圖從兩個方面來評估每個風險:風險變成現(xiàn)實的可能性或概率,以及當風險變成現(xiàn)實時所造成的后果。(1)評估風險后果美國空軍建議從性能、支持、成本和進度等四個方面評估風險的后果,他們把上述四個方面稱為四個風險因素。下面給出這四個風險因素的定義?!ば阅茱L險·成本風險·支持風險·進度風險當前第110頁\共有141頁\編于星期一\15點2.風險估算根據(jù)風險發(fā)生時對上述四個風險因素影響的嚴重程度,可以把風險后果劃分成四個等級:可忽略的、輕微的、嚴重的和災難性的。(2)建立風險表當前第111頁\共有141頁\編于星期一\15點評估風險后果當前第112頁\共有141頁\編于星期一\15點3.處理風險的策略

對于絕大多數(shù)軟件項目來說,上述的4個風險因素(性能、成本、支持和進度)都有一個臨界值,超過臨界值就會導致項目被迫終止。也就是說,如果性能下降、成本超支、支持困難或進度延遲(或這4種因素的組合)超過了預先定義的限度,則因風險過大項目將被迫終止。如果風險還沒有嚴重到迫使項目終止的程度,則項目組應該制定一個處理風險的策略。一個有效的策略應該包括下述三方面的內容:風險避免(或緩解);風險監(jiān)控;風險管理和意外事件計劃。當前第113頁\共有141頁\編于星期一\15點

(1)風險緩解如果軟件項目組采用主動的策略來處理風險,則避免風險總是最好的策略。這可以通過建立風險緩解計劃來達到。(2)風險監(jiān)控隨著項目的進展,風險監(jiān)控活動也就開始了。項目管理者監(jiān)控某些能指出風險概率正在變高還是變低的因素。(3)風險管理和意外事件計劃風險管理和意外事件計劃假設緩解風險的努力失敗了,風險變成了現(xiàn)實。3.處理風險的策略當前第114頁\共有141頁\編于星期一\15點

項目管理者的目標是定義全部項目任務,識別出關鍵任務,跟蹤關鍵任務的進展狀況,以保證能及時發(fā)現(xiàn)拖延進度的情況。為了做到這一點,管理者必須制定一個足夠詳細的進度表,以便監(jiān)督項目進度,并控制整個項目。軟件項目的進度安排是一項活動,它通過把工作量分配給特定的軟件工程任務,并規(guī)定完成各項任務的起、止日期,從而將估算的工作量分布于計劃好的項目持續(xù)期內。進度安排當前第115頁\共有141頁\編于星期一\15點基本原則下述的基本原則能夠指導軟件項目的進度安排。1.劃分2.相互依賴性3.時間分配4.工作量確認5.定義責任6.定義結果7.定義里程碑進度安排當前第116頁\共有141頁\編于星期一\15點1、GanttChart(甘特圖)tw12345678ABCD當前進度優(yōu)點:簡單,能動態(tài)地反映開發(fā)進展。缺點:難以反映多個任務間的邏輯關系。進度安排當前第117頁\共有141頁\編于星期一\15點012345678

codingA

testingA

debuggingABcoding

understandingC

modifyingC

testingB

testingC

debuggingB

debuggingC

testingABC012356789

codingA

testingA

debuggingA

understandingC

modifyingC

testingB

testingC

debuggingB

debuggingC

testingABC4

debuggingABcoding2、PERT(ProgramEvaluation&ReviewTechnique)和CPM(CriticalPathMethod)例:開發(fā)三個模塊A、B、C。

A為公用模塊,B、C的測試須等A的調試完成后進行。A的編碼需6天,測試8天,調試6天。B的編碼需7天,測試8天,調試6天。C利用已有的模塊,須先理解原模塊8天,再修改8天,測試9天,調試7天。最后三模塊集成測試需5天完成。當前第118頁\共有141頁\編于星期一\15點持續(xù)時間LastingTime機動時間SlackTime編號EarliestStartTimeLatestStartTime012345678941363029222014126006142082028293641(0)(0)(15)(4)(2)(4)(0)(2)(0)(2)(0)(0)686678886975(1)標出LastingTime(2)標出EST:=從起點始,所有進入事件的EST+LT中最大的(3)標出LST:=從終點(EST=LST)始,所有離開事件的LSTLT中最小的(4)標出ST:=終點LST起點EST

LT(5)標出CriticalPath:即EST=LST的所有事件組成的路徑當前第119頁\共有141頁\編于星期一\15點軟件質量保證1)在需求分析階段提出對軟件質量的需求,并將其自頂向下逐步分解為可以度量和控制的質量要素,為軟件開發(fā)、維護各階段軟件質量的定性分析和定量度量打下基礎;2)研究并選用軟件開發(fā)方法和工具;3)對軟件生存周期各階段進行正式的技術評審(FTR);4)制定并實施軟件測試策略和測試計劃;5)及時生成軟件文檔并進行其版本控制;6)保證軟件開發(fā)過程與選用的軟件開發(fā)標準相一致;7)建立軟件質量要素的度量機制;8)記錄SQA的各項活動,并生成各種SQA報告。1.軟件質量保證(SQA,SoftwareQualityAssurance)活動的內容當前第120頁\共有141頁\編于星期一\15點2.技術復審的必要性正式技術復審的明顯優(yōu)點是,能夠較早地發(fā)現(xiàn)錯誤,防止錯誤被傳播到軟件過程的后續(xù)階段。正式技術復審實際上是一類復審方法,包括走查(Walkthrough)和審查(Inspection)等具體方法。走查的步驟比審查少,而且沒有審查那樣正規(guī)。軟件質量保證當前第121頁\共有141頁\編于星期一\15點(1)參與者驅動法參與者按照事先準備好的列表,提出他們不理解的術語和認為不正確的術語。文檔編寫組的代表必須對每個質疑做出回答,要么承認確實有錯誤,要么對質疑做出解釋。走查(2)文檔驅動法文檔編寫者向走查組成員仔細解釋文檔。走查組成員在此過程中不時針對事先準備好的問題或解釋過程中發(fā)現(xiàn)的問題提出質疑。這種方法可能比第一種方法更徹底,往往能檢測出更多錯誤。經(jīng)驗表明,采用文檔驅動法時許多錯誤是由文檔講解者自己發(fā)現(xiàn)的。當前第122頁\共有141頁\編于星期一\15點

審查的范圍要比走查廣泛得多,它的步驟也比較多。一般來說,審查有5個基本步驟?!ぞC述·準備·審查·返工·跟蹤審查當前第123頁\共有141頁\編于星期一\15點

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論