軟件工程概論sw課件

1、軟件質(zhì)量概念軟件質(zhì)量保證軟件可靠性軟件配置管理軟件質(zhì)量管理1第1頁，共142頁。軟件質(zhì)量概念軟件質(zhì)量的定義軟件質(zhì)量特性軟件質(zhì)量模型軟件質(zhì)量的度量和評價2第2頁，共142頁。軟件質(zhì)量的定義ANSI/IEEE Std 729-1983定義軟件質(zhì)量為“與軟件產(chǎn)品滿足規(guī)定的和隱含的需求的能力有關(guān)的特征或特性的全體”。M.J. Fisher 定義軟件質(zhì)量為“所有描述計算機軟件優(yōu)秀程度的特性的組合”。3第3頁，共142頁。質(zhì)量特性及其組合，是軟件開發(fā)與維護中的重要考慮因素為滿足軟件的各項精確定義的功能、性能需求，符合文檔化的開發(fā)標準，需要相應(yīng)地給出或設(shè)計一些質(zhì)量特性及其組合。如果這些質(zhì)量特性及其組合都能在

2、產(chǎn)品中得到滿足，則這個軟件產(chǎn)品質(zhì)量就是高的。4第4頁，共142頁。軟件需求是度量軟件質(zhì)量的基礎(chǔ)。不符合需求的軟件就不具備質(zhì)量。標準定義了一組開發(fā)準則，用來指導軟件人員用工程化的方法來開發(fā)軟件。如果不遵守這些開發(fā)準則，軟件質(zhì)量就得不到保證。軟件質(zhì)量是各種特性的復(fù)雜組合。它隨著應(yīng)用的不同而不同，隨著用戶提出的質(zhì)量要求不同而不同。5第5頁，共142頁。軟件質(zhì)量特性軟件質(zhì)量特性，反映了軟件的本質(zhì)。討論一個軟件的質(zhì)量，問題最終要歸結(jié)到定義軟件的質(zhì)量特性。定義一個軟件的質(zhì)量，就等價于為該軟件定義一系列質(zhì)量特性。人們通常把影響軟件質(zhì)量的特性用軟件質(zhì)量模型來描述。6第6頁，共142頁。軟件質(zhì)量模型軟件質(zhì)量特性

3、定義成分層模型最基本的叫做基本質(zhì)量特性，它可以由一些子質(zhì)量特性定義和度量。二次特性在必要時又可由它的一些子質(zhì)量特性定義和度量。1976年 Boehm質(zhì)量模型1979年 McCall質(zhì)量模型1985年 ISO質(zhì)量模型7第7頁，共142頁。8第8頁，共142頁。ISO的軟件質(zhì)量評價模型按照ISO/TC97/SC7/WG3/1985-1-30/N382，軟件質(zhì)量度量模型由三層組成軟件質(zhì)量需求評價準則（SQRC）軟件質(zhì)量設(shè)計評價準則（SQDC）軟件質(zhì)量度量評價準則（SQMC）高層和中層建立國際標準，低層可由各使用單位視實際情況制定9第9頁，共142頁。Boehm質(zhì)量模型10第10頁，共142頁。11第

4、11頁，共142頁。1991年 ISO質(zhì)量特性國際標準 （ISO/IEC9126）質(zhì)量特性：功能性、可靠性、可維護性、效率、可使用性、可移植性推薦21個子特性：適合性 準確性 互用性 依從性 安全性 成熟性 容錯性 可恢復(fù)性 可理解性 易學習性 操作性 時間特性 資源特性 可分析性 穩(wěn)定性 可變更性 可測試性 可安裝性 可替換性 適應(yīng)性 一致性 12第12頁，共142頁。13第13頁，共142頁。軟件質(zhì)量的度量和評價軟件質(zhì)量特性度量有兩類：預(yù)測型和驗收型。預(yù)測度量是利用定量或定性的方法，估算軟件質(zhì)量的評價值，以得到軟件質(zhì)量的比較精確的估算值。驗收度量是在軟件開發(fā)各階段的檢查點，對軟件的要求質(zhì)量

5、進行確認性檢查的具體評價值，它是對開發(fā)過程中的預(yù)測進行評價。14第14頁，共142頁。預(yù)測度量有兩種。第一種叫做尺度度量，這是一種定量度量。它適用于一些能夠直接度量的特性，例如，出錯率定義為：錯誤數(shù)KLOC單位時間。第二種叫做二元度量，這是一種定性度量。它適用于一些只能間接度量的特性，例如，可使用性、靈活性等等。15第15頁，共142頁。尺度度量檢查表16第16頁，共142頁。二元度量檢查表17第17頁，共142頁。通過對照檢查項目，確定一種質(zhì)量特性的有無。例如，在設(shè)計和編碼階段的復(fù)雜性度量，利用尺度度量方法來做。對模塊復(fù)雜性的度量采用McCabe 環(huán)路度量。對于二元度量，可針對檢查表中每一項

6、都應(yīng)給以記分，指定信息存在時記 “1”，否則記 “0”。表中所有各項的分數(shù)相加，即得度量結(jié)果。18第18頁，共142頁。軟件的質(zhì)量保證質(zhì)量保證的概念軟件質(zhì)量保證的主要任務(wù)質(zhì)量保證與檢驗軟件質(zhì)量保證體系質(zhì)量保證的實施軟件的質(zhì)量設(shè)計19第19頁，共142頁。質(zhì)量保證的概念什么是質(zhì)量保證，它是為保證產(chǎn)品和服務(wù)充分滿足消費者要求的質(zhì)量而進行的有計劃、有組織的活動。質(zhì)量保證是面向消費者的活動，是為了使產(chǎn)品實現(xiàn)用戶要求的功能，站在用戶立場上來掌握產(chǎn)品質(zhì)量的。軟件的質(zhì)量保證就是向用戶及社會提供滿意的高質(zhì)量的產(chǎn)品。20第20頁，共142頁。軟件的質(zhì)量保證活動也和一般的質(zhì)量保證活動一樣，是確保軟件產(chǎn)品從誕生到消

7、亡為止的所有階段的質(zhì)量的活動。即為了確定、達到和維護需要的軟件質(zhì)量而進行的所有有計劃、有系統(tǒng)的管理活動。21第21頁，共142頁。軟件質(zhì)量保證的主要任務(wù)為了提高軟件的質(zhì)量和軟件的生產(chǎn)率，軟件質(zhì)量保證的主要任務(wù)大致可歸結(jié)為8點。22第22頁，共142頁。1.用戶要求定義熟練掌握正確定義用戶要求的技術(shù)熟練使用和指導他人使用定義軟件需求的支持工具重視領(lǐng)導全體開發(fā)人員收集和積累有關(guān)用戶業(yè)務(wù)領(lǐng)域的各種業(yè)務(wù)的資料和技術(shù)技能。23第23頁，共142頁。2. 力爭不重復(fù)勞動考慮哪些既有軟件可以復(fù)用在開發(fā)過程中，隨時考慮所生產(chǎn)軟件的復(fù)用性。24第24頁，共142頁。3. 掌握開發(fā)新軟件的方法在開發(fā)新軟件的過程中

8、大力使用和推行軟件工程學中所介紹的開發(fā)方法和工具。 使用先進的開發(fā)技術(shù)：如結(jié)構(gòu)化技術(shù)、面向?qū)ο蠹夹g(shù) 使用數(shù)據(jù)庫技術(shù)或網(wǎng)絡(luò)化技術(shù) 應(yīng)用開發(fā)工具或環(huán)境 改進開發(fā)過程25第25頁，共142頁。4. 組織外部力量協(xié)作的方法一個軟件自始至終由同一個軟件開發(fā)單位來開發(fā)，也許是最理想的。但在現(xiàn)實中常常難以做到。改善對外部協(xié)作部門的開發(fā)管理。必須明確規(guī)定進度管理、質(zhì)量管理、交接檢查、維護體制等各方面的要求，建立跟蹤檢查的體制。26第26頁，共142頁。5. 排除無效勞動最大的無效勞動就是因需求規(guī)格說明有誤、設(shè)計有誤而造成的返工。定量記錄返工工作量，收集和分析返工勞動花費數(shù)據(jù)較大的無效勞動是重復(fù)勞動，即相似的軟

9、件在幾個地方同時開發(fā)建立互相交流、信息往來通暢、具橫向交流特征的信息流通網(wǎng)27第27頁，共142頁。6. 發(fā)揮每個開發(fā)者的能力軟件生產(chǎn)是人的智能生產(chǎn)活動，它依賴于人的能力和開發(fā)組織團隊的能力。開發(fā)者必須有學習各專業(yè)業(yè)務(wù)知識、生產(chǎn)技術(shù)和管理技術(shù)的能動性。管理者或產(chǎn)品服務(wù)者要制定技術(shù)培訓計劃、技術(shù)水平標準，以及適用于將來需要的中長期技術(shù)培訓計劃。28第28頁，共142頁。7. 提高軟件開發(fā)的工程能力要想生產(chǎn)出高質(zhì)量的軟件產(chǎn)品必須有高水平的軟件工程能力。在軟件開發(fā)環(huán)境或軟件工具箱的支持下，運用先進的開發(fā)技術(shù)、工具和管理方法開發(fā)軟件的能力。29第29頁，共142頁。8. 提高計劃和管理質(zhì)量能力項目開發(fā)

10、初期計劃階段的項目計劃評價計劃執(zhí)行過程中及計劃完成報告的評價將評價、評審工作在工程實施之前就列入整個開發(fā)工程的工程計劃中提高軟件開發(fā)項目管理的精確度30第30頁，共142頁。質(zhì)量保證與檢驗其一是切實搞好開發(fā)階段的管理，檢查各開發(fā)階段的質(zhì)量保證活動開展得如何；其二是預(yù)先防止軟件差錯給用戶造成損失。為了確保每個開發(fā)過程的質(zhì)量，防止把軟件差錯傳遞到下一個過程，必須進行質(zhì)量檢驗。31第31頁，共142頁。質(zhì)量檢驗的原則用戶要求的是產(chǎn)品所具有的功能，這是“真質(zhì)量”?？抠|(zhì)量檢驗，一般檢查的是“真質(zhì)量”的質(zhì)量特性。能靠質(zhì)量檢驗的質(zhì)量特性，即使全數(shù)檢驗，也只是代表產(chǎn)品的部分質(zhì)量特性。必須在各開發(fā)階段對影響產(chǎn)品

11、質(zhì)量的因素進行切實的管理，認真檢查實施落實情況。32第32頁，共142頁。當開發(fā)階段出現(xiàn)異常時，要從質(zhì)量特性方面進行檢驗，看是否會給后續(xù)階段帶來影響。雖然各開發(fā)階段進展穩(wěn)定，但由于工程能力不足，軟件產(chǎn)品不能滿足用戶要求的質(zhì)量。這時可通過檢驗對該產(chǎn)品做出評價，判斷是否能向用戶提供該產(chǎn)品。要以一定的標準檢驗產(chǎn)品，根據(jù)產(chǎn)品的質(zhì)量特性，檢查各個過程的管理狀態(tài)。33第33頁，共142頁。軟件質(zhì)量保證體系軟件的質(zhì)量保證活動，是涉及各個部門的部門間的活動。例如，如果在用戶處發(fā)現(xiàn)了軟件故障，產(chǎn)品服務(wù)部門就應(yīng)聽取用戶的意見，再由檢查部門調(diào)查該產(chǎn)品的檢驗結(jié)果，進而還要調(diào)查軟件實現(xiàn)過程的狀況，并根據(jù)情況檢查設(shè)計是否

12、有誤，不當之處加以改進，防止再次發(fā)生問題。34第34頁，共142頁。為了順利開展以上活動，事先明確部門間的質(zhì)量保證業(yè)務(wù)，確立部門間的聯(lián)合與協(xié)作的機構(gòu)十分重要，這個機構(gòu)就是質(zhì)量保證體系。 必須明確反饋途徑。 必須明確各部門的職責。 必須確定保證系統(tǒng)運行的方法、工具、有關(guān)文檔資料，以及系統(tǒng)管理的規(guī)程和標準。35第35頁，共142頁。 必須明確決定是否可向下一階段進展的評價項目和評價準則。 必須不斷地總結(jié)系統(tǒng)管理的經(jīng)驗教訓，能夠修改系統(tǒng)。 制定質(zhì)量保證計劃，在計劃中 確定質(zhì)量目標 確定在每個階段為達到總目標所應(yīng)達到的要求 確定進度安排 確定所需人力、資源和成本等。36第36頁，共142頁。軟件質(zhì)量保

13、證規(guī)程和技術(shù)準則規(guī)定在項目的哪個階段進行評審及如何評審；規(guī)定在項目的哪個階段應(yīng)當產(chǎn)生哪些報告和計劃；規(guī)定產(chǎn)品各方面測試應(yīng)達到的水平。 在每次評審和測試中發(fā)現(xiàn)的錯誤如何修正；37第37頁，共142頁。描述希望得到的質(zhì)量度量；說明各種軟件人員的職責，規(guī)定為了達到質(zhì)量目標他們必須進行哪些活動。建立 在各階段中執(zhí)行質(zhì)量評價的質(zhì)量評價和質(zhì)量檢查系統(tǒng) 有效運用質(zhì)量信息的質(zhì)量信息系統(tǒng)，并使其運行。38第38頁，共142頁。質(zhì)量保證的實施軟件質(zhì)量保證的實施需要從縱向和橫向兩個方面展開。 要求所有與軟件生存期有關(guān)的人員都要參加 要求對產(chǎn)品形成的全過程進行質(zhì)量管理這要求整個軟件部門齊心協(xié)力，不斷完善軟件的開發(fā)環(huán)境

14、。此外還需要與用戶共同合作。39第39頁，共142頁。質(zhì)量目標與度量為了開發(fā)高質(zhì)量的軟件，需要明確軟件的功能，明確軟件應(yīng)達到什么樣的質(zhì)量標準，即質(zhì)量目標。為了達到這個目標，在開發(fā)過程中的各個階段進行檢查和評價。在做質(zhì)量評價時，需要有對質(zhì)量進行度量的準則和方法。需要有在軟件生存期中如何使用這些準則和方法的質(zhì)量保證步驟，以及提高該項作業(yè)效率的工具40第40頁，共142頁。軟件質(zhì)量度量和保證的條件適應(yīng)性：適應(yīng)各種用戶、軟件類型易學性：不需要特殊技術(shù)，易掌握可靠性：同個軟件的評價結(jié)果一致針對性：設(shè)計階段就確立質(zhì)量目標，在各個階段實施落實?？陀^性：經(jīng)濟性：41第41頁，共142頁。質(zhì)量保證活動的實施步驟

15、：Target：以用戶要求和開發(fā)方針為依據(jù)，對質(zhì)量需求準則、質(zhì)量設(shè)計準則的各質(zhì)量特性設(shè)定質(zhì)量目標。Plan：設(shè)定適合于被開發(fā)軟件的評測檢查項目(質(zhì)量評價準則)。研討實現(xiàn)質(zhì)量目標的方法或手段。Do：制作高質(zhì)量的規(guī)格說明和程序。在接受質(zhì)量檢查前先做自我檢查。42第42頁，共142頁。Check：以Plan階段設(shè)定的質(zhì)量評價準則進行評價。計算結(jié)果用質(zhì)量圖的形式表示出來。比較評價結(jié)果的質(zhì)量得分和質(zhì)量目標，看其是否合格。Action：對評價發(fā)現(xiàn)的問題進行改進活動，如果實現(xiàn)并達到了質(zhì)量目標就轉(zhuǎn)入下一個工程階段。這樣重復(fù)“Plan”到“Action”的過程，直到整個開發(fā)項目完成。43第43頁，共142頁。4

16、4第44頁，共142頁。45第45頁，共142頁。46第46頁，共142頁。軟件的質(zhì)量設(shè)計質(zhì)量特性轉(zhuǎn)換為軟件的內(nèi)部結(jié)構(gòu)在軟件定義階段，必須定義對軟件的質(zhì)量需求。即確定軟件的質(zhì)量特性及必需的評價準則，并定量地設(shè)定其必須達到的質(zhì)量水平在以后軟件開發(fā)的每一階段結(jié)束時，要算出評價的分數(shù)，然后與目標值加以對照，以評估在這一階段開發(fā)的軟件質(zhì)量是否達到要求。47第47頁，共142頁。為了實現(xiàn)規(guī)定的質(zhì)量特性，就需要把這些質(zhì)量特性轉(zhuǎn)換為軟件的內(nèi)部結(jié)構(gòu)的特性。例如，軟件質(zhì)量需求中的“性能”，可以轉(zhuǎn)換成軟件內(nèi)部結(jié)構(gòu)中的構(gòu)成元素，即每一個程序模塊和物理數(shù)據(jù)各自應(yīng)具有的性能特性。這些性能特性的累積就形成外部規(guī)格中的性能

17、特性。48第48頁，共142頁。軟件的結(jié)構(gòu)特性與評價標準結(jié)構(gòu)特性 邏輯數(shù)據(jù)層次評價標準 全部數(shù)據(jù)元素定義完畢 所有層次的操作符定義完畢結(jié)構(gòu)特性 功能層次評價標準 全部功能元素定義完畢 所有層次的操作符定義完畢49第49頁，共142頁。結(jié)構(gòu)特性 邏輯數(shù)據(jù)與功能的對應(yīng)關(guān)系評價準則 所有數(shù)據(jù)都與功能對應(yīng) 所有功能元素都與數(shù)據(jù)對應(yīng) 邏輯數(shù)據(jù)與功能的相互關(guān)系個數(shù)（局部）50第50頁，共142頁。 結(jié)構(gòu)特性 物理數(shù)據(jù)層次評價準則 全部數(shù)據(jù)元素定義完畢 物理數(shù)據(jù)之間的所有指針定義完畢 上述指針都具有層次性51第51頁，共142頁。結(jié)構(gòu)特性 模塊層次評價準則 所有模塊定義完畢 模塊之間所有控制關(guān)系定義完畢 上

18、述關(guān)系都是標準過程調(diào)用形式 各層次上的模塊大小適當52第52頁，共142頁。結(jié)構(gòu)特性 物理數(shù)據(jù)與模塊的對應(yīng)關(guān)系評價準則 所有物理數(shù)據(jù)都與模塊對應(yīng) 所有模塊都與物理數(shù)據(jù)對應(yīng) 對應(yīng)于一個物理數(shù)據(jù)的模塊數(shù)（以一對一為好）53第53頁，共142頁。結(jié)構(gòu)特性 邏輯數(shù)據(jù)與物理數(shù)據(jù)的對應(yīng)關(guān)系評價準則 所有邏輯數(shù)據(jù)都與物理數(shù)據(jù)對應(yīng) 對應(yīng)于一個物理數(shù)據(jù)的邏輯數(shù)據(jù)數(shù)（以一對一為好）54第54頁，共142頁。結(jié)構(gòu)特性 功能與模塊的對應(yīng)關(guān)系評價準則 所有功能都與模塊對應(yīng) 對應(yīng)模塊的功能個數(shù)（以一對一為好）55第55頁，共142頁。軟件可靠性軟件生存期與軟件壽命的關(guān)系在軟件工程中常用的定義軟件可靠性定義測試中的可靠性分

19、析測試精確度和測試覆蓋度的評價56第56頁，共142頁。軟件生存期與軟件壽命的關(guān)系一切有生命的東西都有一個“壽命”這個概念也可以延伸到對非生命產(chǎn)品的質(zhì)量評價上來。例如一個電子產(chǎn)品的壽命就是指該產(chǎn)品從出廠直到喪失使用價值的持續(xù)時間。從軟件工程的角度來說，軟件產(chǎn)品的壽命是指軟件的整個生存期。57第57頁，共142頁。從軟件用戶的角度來看，更關(guān)心的是軟件在交付使用后的情況如何。希望用一個指標平均失效間隔時間 MTBF(MeanTime Between Failure) 來表明，在規(guī)定的要求和條件下，能在多大的程度上依賴這個軟件來完成任務(wù)。我們把在使用期間軟件能夠正常工作的持續(xù)時間叫做軟件的使用壽命。

20、58第58頁，共142頁。軟件的使用壽命與輸入環(huán)境有關(guān)。例如，有一個存在缺陷的編譯程序，當用于學生做簡單練習時，MTBF可能很長。而做一個大的課題時，由于程序連續(xù)出錯，MTBF就會變得很短。MTBF可以看做是對軟件可靠性做估計的樣本數(shù)據(jù)，但不能看做是依據(jù)。59第59頁，共142頁。“錯誤”這一術(shù)語。在沒有特別加以說明的情況下，這是一個泛用的、模糊的概念。它指的可能是bug(設(shè)計中的差錯)、 fault(故障)、error(錯誤)、failure(失效)、crash(重大事故)、problem(疑問)等。在漢譯中，這些術(shù)語的使用更加混亂。60第60頁，共142頁。在軟件工程中常用的定義故障(fa

21、ult)：軟件的內(nèi)在缺陷。這些缺陷可在生存期各個階段被引入。錯誤(error)：故障在一定的環(huán)境條件下的暴露，導致系統(tǒng)在運行中出現(xiàn)了不正常、不正確、不按規(guī)范執(zhí)行的狀態(tài)，稱為軟件出錯。失效(failure)：對錯誤不做任何修正和恢復(fù)， 導致系統(tǒng)的輸出不滿足用戶要求，稱為軟件的一次失效。61第61頁，共142頁。以上定義的故障、錯誤和失效，分別代表了廣義的“錯誤”在不同的條件下所對應(yīng)的術(shù)語。它們可以理解為：設(shè)計者的失誤導致系統(tǒng)中留有錯誤的設(shè)計缺陷或“故障”(fault)，這些故障導致系統(tǒng)的錯誤執(zhí)行錯誤(error)，由于錯誤導致系統(tǒng)的錯誤輸出失效(failure)。62第62頁，共142頁。故障是

22、物理地或靜態(tài)地存在的失誤、錯誤和失效都是系統(tǒng)的一種動態(tài)的轉(zhuǎn)瞬即逝的現(xiàn)象軟件發(fā)生失效標志著軟件一次使用壽命的結(jié)束發(fā)生過失效的軟件通常仍然是可用的。只有當軟件頻繁失效，或者公認已經(jīng)“過時”了的時侯，軟件才被廢棄，意味著當前這一版本軟件使用壽命的終結(jié)。63第63頁，共142頁。軟件故障產(chǎn)生原因支持軟件工作的基本條件(除硬件外的操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)、編譯程序、微代碼等)的缺陷軟件設(shè)計不當加入了允許范圍之外的輸入64第64頁，共142頁。軟件可靠性的定義軟件可靠性是軟件在給定的時間間隔及給定的環(huán)境條件下，按設(shè)計要求，成功地運行程序的概率。環(huán)境條件指的是軟件的使用環(huán)境。無論是什么軟件，如果不對它的使用

23、環(huán)境加以限制，都是會失效的。這種失效的數(shù)據(jù)，不能用來度量軟件的可靠性。65第65頁，共142頁。規(guī)定的時間在定義中，一般采用“運行時間” t 作為時間的尺度。因 具體要處理的問題是多種多樣的 其對應(yīng)的輸入環(huán)境是隨機 程序中相應(yīng)程序路徑的選取也是隨機的 軟件的失效也是隨機的應(yīng)當把運行時間t當作隨機變量來考慮。66第66頁，共142頁。規(guī)定的功能在考慮軟件可靠性時，首先應(yīng)當明確軟件的功能是什么，哪些功能是主要的，哪些功能是次要的。一般從軟件需求分析說明書和設(shè)計說明書中可以了解這些情況。 由于功能不同，失效帶來的損失就不一樣。因此，還要明確哪些失效是致命的，哪些失效是非致命的，哪些又是容易修復(fù)的。此

24、外，還要明確，怎樣才算是完成了一個規(guī)定的功能。67第67頁，共142頁。成功地運行程序是指不僅程序能正確地運行，滿足用戶對它的功能要求， 而且當程序一旦受到意外的傷害，或系統(tǒng)故障時，能盡快恢復(fù)，仍能正常地運行。68第68頁，共142頁。測試中的可靠性分析在軟件開發(fā)的過程中，利用測試的統(tǒng)計數(shù)據(jù)，估算軟件的可靠性，以控制軟件的質(zhì)量是至關(guān)重要的。推測錯誤的產(chǎn)生頻度，即推測錯誤產(chǎn)生的時間間隔推測殘留在程序中的錯誤數(shù)評價測試的精確度和覆蓋率69第69頁，共142頁。推測錯誤的產(chǎn)生頻度估算錯誤產(chǎn)生頻度的一種方法是估算平均失效等待時間MTTF (Mean Time To Failure)MTTF估算公式(S

25、hooman模型)70第70頁，共142頁。故障累積指數(shù)曲線模型71第71頁，共142頁。估算軟件中故障總數(shù)ET 的方法利用Shooman模型估算程序中原來錯誤總量ET 瞬間估算72第72頁，共142頁。解此方程組73第73頁，共142頁。利用最小二乘法進行程序原有錯誤數(shù)ET及K的估算由失效率 整理得 若對程序進行若干次不同的功能測試，可得到一系列實驗數(shù)據(jù)74第74頁，共142頁。 Ec ( ti ), ( ti ), i = 1, 2, , n令 有75第75頁，共142頁。用最小二乘法解此方程組，可解出a、b的估計值最后得到 K, ET 的估計值利用植入故障法估算程序中原有故障總數(shù)ET 捕

26、獲再捕獲抽樣法76第76頁，共142頁。設(shè)Ns 是在測試前人為地向程序中植入的故障數(shù)，ns 是經(jīng)過一段時間測試后發(fā)現(xiàn)的播種故障數(shù)目，n 是在測試中又發(fā)現(xiàn)的程序原有故障數(shù)。設(shè)測試用例發(fā)現(xiàn)植入故障和原有故障的能力相同，則程序中原有故障總數(shù) N ( =ET )估算值為77第77頁，共142頁。Hyman分別測試法由兩個測試員同時互相獨立地測試同一程序的兩個副本，用 t 表示測試時間，記 t0時，程序中原有故障總數(shù)是 B0；tt1 時，測試員甲發(fā)現(xiàn)的故障總數(shù)是 B1；測試員乙發(fā)現(xiàn)的故障總數(shù)是 B2；其中兩人發(fā)現(xiàn)的相同故障數(shù)目是 bc；兩人發(fā)現(xiàn)的不同故障數(shù)目是 bi。78第78頁，共142頁。在大程序測

27、試時，頭幾個月兩個測試員測試的結(jié)果應(yīng)當比較接近，bi 不是很大。這時有如果bi比較顯著，應(yīng)當每隔一段時間，由兩個測試員再進行分別測試，分析測試結(jié)果，估算B0。如果bi減小，或幾次估算值的結(jié)果相差不多，則B0作為原有錯誤總數(shù)的估算值。79第79頁，共142頁。測試精確度和測試覆蓋度的評價在軟件測試過程中累積發(fā)現(xiàn)的故障數(shù)，可用帶有平均值函數(shù) m(t) 的非齊次泊松過程(NHPP)來描述：其中，N是在測試中可能發(fā)現(xiàn)的故障總數(shù)，b是故障發(fā)現(xiàn)率。當N一定時，b越大，在短期內(nèi)發(fā)現(xiàn)的故障越多。80第80頁，共142頁。81第81頁，共142頁。N 可以認為是當測試時間無限延長時估計可能發(fā)現(xiàn)的故障總數(shù)。由于

28、測試的不完全，在某些很難發(fā)現(xiàn)的故障未發(fā)現(xiàn)前就可能結(jié)束測試 若程序中潛在的故障較少，則參數(shù)N的估計誤差較大因此，只用測試中累積發(fā)現(xiàn)的故障數(shù)來評價測試是不夠的。需要從測試的量的方面和質(zhì)的方面，全面地評價測試。82第82頁，共142頁。SPQL (Software Product Quality Level) 用如下公式度量： SPQL AcCv其中，Ac (Test Accuracy) 是測試的精確度，它反映了測試的質(zhì)量；Cv (Test Coveragy) 是測試的覆蓋度，它反映了測試的數(shù)量。測試結(jié)束時軟件產(chǎn)品質(zhì)量水準83第83頁，共142頁。測試質(zhì)量的度量可以靠測試的故障捕捉率和遺漏率來衡量。

29、測試數(shù)量的度量指標是執(zhí)行的測試用例數(shù)、確認的程序路徑數(shù)等等；84第84頁，共142頁。測試精確度Ac表明在測試的過程中以多大的把握捕捉了軟件中潛在的故障。測定Ac，需要預(yù)先植入播種故障，然后通過測試，根據(jù)播種故障的捕捉率來推測原有故障的捕獲率。85第85頁，共142頁。用ns 表示經(jīng)過相當長時間測試可能發(fā)現(xiàn)的播種故障數(shù)，用Ns 表示測試對象軟件內(nèi)預(yù)先埋設(shè)的播種故障總數(shù),用平均值為m(t)的NHPP模型描述測試時發(fā)現(xiàn)播種故障的過程m(t)的收斂值 m()N測試精確度Ac的推測值：86第86頁，共142頁。若設(shè)測試過程中到時刻 ti 能發(fā)現(xiàn)的累積播種故障總數(shù)為 yi ，則在測試期間可得到一連串數(shù)據(jù)

30、 (t0, 0), (t1, y1), , (tm, ym)可得到一組方程：應(yīng)用最小二乘法可得到參數(shù)N 與 b的估計值，并得到測試精確度Ac。87第87頁，共142頁。測試覆蓋率Cv表明在整個測試期間發(fā)現(xiàn)軟件內(nèi)潛在故障的可能性有多大?？赏ㄟ^被測試對象軟件內(nèi)潛在的原有故障的捕捉率來測定的。88第88頁，共142頁。測試過程中已發(fā)現(xiàn)原有故障總數(shù)為 n0(實測值)，經(jīng)過相當長時間測試后可能發(fā)現(xiàn)的原有故障總數(shù)為N0，采用平均值函數(shù)m(t)的NHPP模型描述測試發(fā)現(xiàn)原有故障的過程m(t)的收斂值m()Nc測試覆蓋率Cv的推測值：89第89頁，共142頁。 測試開始后，由于測試員對程序和測試環(huán)境不熟悉，造

31、成拖期。為描述這種情形，對原來NHPP的指數(shù)型平均值函數(shù)加以改造：它是把原來的指數(shù)型平均值函數(shù)在時間軸上平移而得到的結(jié)果，是具有時間延遲的NHPP模型。90第90頁，共142頁。91第91頁，共142頁。測試員從發(fā)現(xiàn)錯誤征兆到確認錯誤，需要反復(fù)執(zhí)行程序，以再現(xiàn)錯誤，造成時間拖延。因此，在使用測試結(jié)果進行軟件質(zhì)量評價時，只用指數(shù)型的NHPP的平均值曲線(A)是不夠的。實測結(jié)果多是如(B)所示的S型曲線。92第92頁，共142頁。實驗表明： 對于一般功能單純的小規(guī)模的程序模塊，具有時間延遲的NHPP模型比較合適； 對于功能比較復(fù)雜的程序模塊，S型NHPP模型比較合適； 對于80000行以上的程序，

32、最基本的指數(shù)型NHPP模型比較合適。93第93頁，共142頁。軟件配置管理在軟件建立時變更是不可避免的，因為在進行變更前沒有仔細分析，或沒有進行變更控制，變更加劇了項目中軟件人員之間的混亂。協(xié)調(diào)軟件開發(fā)使得混亂減到最小的技術(shù)叫做配置管理。配置管理是一組標識、組織和控制修改的活動，目的是使錯誤達到最小并最有效地提高生產(chǎn)率。94第94頁，共142頁。軟件配置管理的概念軟件配置管理，簡稱SCM，是一種“保護傘”活動，它應(yīng)用于整個軟件工程過程。SCM活動的目標是為了 (1) 標識變更； (2) 控制變更； (3) 確保變更正確地實現(xiàn)； (4) 向其他有關(guān)的人報告變更。95第95頁，共142頁。在軟件工

33、程過程中產(chǎn)生的所有信息項（文檔、報告、程序、表格、數(shù)據(jù)）構(gòu)成了軟件配置。軟件配置是軟件的具體形態(tài)在某一時刻的瞬時影像。隨著軟件工程過程的進展，軟件配置項(SCI)數(shù)目快速增加。系統(tǒng)規(guī)格說明可繁衍出軟件項目實施計劃和軟件需求規(guī)格說明。它們又依次繁衍出建立信息層次的其它文檔。96第96頁，共142頁?；€ (Baseline)基線是軟件生存期中各開發(fā)階段末尾的特定點，又稱里程碑。由正式的技術(shù)評審而得到的SCI協(xié)議和軟件配置的正式文本才能成為基線?；€的作用是把各階段工作的劃分更加明確化，以便于檢驗和肯定階段成果。97第97頁，共142頁。軟件開發(fā)各階段的基線98第98頁，共142頁。項目數(shù)據(jù)庫一旦

34、一個SCI成為基線，就把它存放到項目數(shù)據(jù)庫中。當軟件組織成員想要對基線SCI進行修改時，把它從項目數(shù)據(jù)庫中復(fù)制到該工程師的專用工作區(qū)中。例如，把一個名為B的SCI從項目數(shù)據(jù)庫復(fù)制到工程師的專用工作區(qū)中。工程師在B（B的副本）上完成要求的變更，再用B來更新B。99第99頁，共142頁。有些系統(tǒng)中把這個基線SCI鎖定。在變更完成、評審和批準之前，不許對它做任何操作。100第100頁，共142頁?；€SCI和項目數(shù)據(jù)庫101第101頁，共142頁。軟件配置項 SCI軟件配置管理的對象就是SCI軟件配置項。 系統(tǒng)規(guī)格說明 軟件項目實施計劃 軟件需求說明 可執(zhí)行的原型 初步的用戶手冊 設(shè)計規(guī)格說明102

35、第102頁，共142頁。 源代碼清單 測試計劃和過程、測試用例和測試結(jié)果記錄 操作和安裝手冊 可執(zhí)行程序（可執(zhí)行程序模塊、連接模塊） 數(shù)據(jù)庫描述（模式和文件結(jié)構(gòu)、初始內(nèi)容） 正式的用戶手冊 維護文檔（軟件問題報告、維護請求、工程變更次序）103第103頁，共142頁。軟件工程標準項目開發(fā)總結(jié)除以上所列SCI以外，許多軟件工程組織還把配置控制之下的軟件工具列入其中，即編輯程序、編譯程序、其它CASE工具的特定版本。因為要使用這些工具來生成文檔、程序和數(shù)據(jù)，如果編譯程序的版本不同，可能產(chǎn)生的結(jié)果也不同。104第104頁，共142頁。配置對象在實現(xiàn)SCM時，把SCI組織成配置對象，在項目數(shù)據(jù)庫中用一

36、個單一的名字來組織它們。一個配置對象有一個名字和一組屬性，并通過某些聯(lián)系“連接”到其它對象。每個對象與其它對象的聯(lián)系用箭頭表示。箭頭指明了一種構(gòu)造關(guān)系。105第105頁，共142頁。配置對象106第106頁，共142頁。雙向箭頭則表明一種相互關(guān)系。如果對“源代碼”對象作了一個變更，軟件工程師就可以根據(jù)這種相互關(guān)系確定，其它哪些對象（和SCI）可能受到影響。107第107頁，共142頁。軟件配置管理的任務(wù)軟件配置管理（SCM）的任務(wù)是： 標識單個的SCI 標識和管理軟件各種版本 控制變更 審查軟件配置 報告所有加在配置上的變更。108第108頁，共142頁。配置標識一方面隨著軟件生存期的向前推進

37、，SCI的數(shù)量不斷增多。整個軟件生存期的軟件配置就象一部不斷演變的電影，而某一時刻的配置就是這部電影的一個片段。為了方便對軟件配置的各個片段（SCI）進行控制和管理，不致造成混亂，首先應(yīng)給它們命名。109第109頁，共142頁。對象類型基本對象：是由軟件工程師在分析、設(shè)計、編碼和測試時所建立的文本單元。例如，基本對象可能是需求規(guī)格說明中的一節(jié)，一個模塊的源程序清單、一組用來測試一個等價類的測試用例。復(fù)合對象：是基本對象或其它復(fù)合對象的一個收集。110第110頁，共142頁。對象標識： （名字、描述、資源、實現(xiàn)）對象的名字明確地標識對象。對象描述包括：SCI類型（如文檔、程序、數(shù)據(jù)）、項目標識、

38、變更和或版本信息。資源包括由對象產(chǎn)生的、處理的、引用的或其它需要的一些實體。基本對象的實現(xiàn)是指向文本單元的指針，復(fù)合對象的實現(xiàn)為null。111第111頁，共142頁。命名對象之間的聯(lián)系對象的層次關(guān)系：一個對象可以是一個復(fù)合對象的一個組成部分，用聯(lián)系標識。 E-R diagram 1.4 data model; data model Design Specification;就可以建立SCI的一個層次。112第112頁，共142頁。對象的相互關(guān)聯(lián)關(guān)系：對象跨越對象層次的分支相互關(guān)聯(lián)。這些交叉的結(jié)構(gòu)聯(lián)系表達方式如下： data model data flow model; (兩個復(fù)合對象之間的相

39、互聯(lián)系) data model test case class m; (一個復(fù)合對象與一個特定的基本對象之間的相互聯(lián)系）113第113頁，共142頁。演變圖整個軟件工程過程中所涉及的軟件對象都必須加以標識。在對象成為基線以前可能要做多次變更，在成為基線之后也可能需要頻繁地變更。對于每一配置對象都可以建立一個演變圖，用演變圖記敘對象的變更歷史。114第114頁，共142頁。演變圖115第115頁，共142頁。在某些工具中，當前保持的只是最后版本的完全副本。為了得到較早時期(文檔或程序)的版本，可以從最后版本中“提取”出(由工具編目的)變更，使得當前配置直接可用，并使得其它版本也可用。116第11

40、6頁，共142頁。版本控制版本控制是SCM的基礎(chǔ)，它管理并保護開發(fā)者的軟件資源。版本控制管理在軟件工程過程中建立起配置對象的不同版本。版本管理可以把一些屬性結(jié)合到各個軟件版本上。通過描述所希望的屬性集合來確定（或構(gòu)造）所想要的配置。使用演變圖來表示系統(tǒng)的不同版本。117第117頁，共142頁。118第118頁，共142頁。圖中的各個結(jié)點都是聚合對象，是一個完全的軟件版本。軟件的每一版本都是SCI（源代碼、文檔、數(shù)據(jù)）的一個收集，且各個版本都可能由不同的變種組成。例如，一個簡單的程序版本由1、2、3、4和5等部件組成。其中部件4在軟件使用彩色顯示器時使用，部件5在軟件使用單色顯示器時使用。因此，

41、可以定義版本的兩個變種。119第119頁，共142頁。版本管理的主要任務(wù)集中管理檔案，安全授權(quán)機制： 版本管理的操作將開發(fā)組的檔案集中地存放在服務(wù)器上，經(jīng)系統(tǒng)管理員授權(quán)給各個用戶。 用戶通過登入（check in）和檢出（check out）的方式訪問服務(wù)器上的文件，未經(jīng)授權(quán)的用戶無法訪問服務(wù)器上的文件。120第120頁，共142頁。121第121頁，共142頁。軟件版本升級管理： 每次登入時，在服務(wù)器上都會生成新的版本。 任何版本都可以隨時檢出編輯，同一應(yīng)用的不同版本可以像樹枝一樣向上增長。122第122頁，共142頁。123第123頁，共142頁。加鎖功能： 目的是在文件更新時保護文件，避

42、免不同用戶更改同一文件時發(fā)生沖突。 某一文件一旦被登入，鎖即被解除，該文件可被其它用戶使用。 在更新一個文件之前鎖定它，避免變更沒有鎖定的項目源文件。124第124頁，共142頁。在文件登入和檢出時，需要注意登入和檢出的使用: 當需要修改某個小缺陷時，應(yīng)只檢出完成工作必需的最少文件； 需要對文件變更時，應(yīng)登入它并加鎖，保留對每個變更的記錄； 應(yīng)避免長時間地鎖定文件。如果需要長時間工作于某個文件，最好能創(chuàng)建一個分支，并在分支上做工作。125第125頁，共142頁。 如果需要做較大的變更，可有兩種選擇： a.將需要的所有文件檢出并加鎖，然后正常處理； b.為需要修改的所有分支創(chuàng)建分支，把變更與主干

43、“脫機”，然后把結(jié)果合并回去。126第126頁，共142頁。變更控制軟件生存期內(nèi)全部的軟件配置是軟件產(chǎn)品的真正代表，必須使其保持精確。軟件工程過程中某一階段的變更，均要引起軟件配置的變更，這種變更必須嚴格加以控制和管理，保持修改信息。變更控制包括建立控制點和建立報告與審查制度。127第127頁，共142頁。變更控制過程128第128頁，共142頁。129第129頁，共142頁。在此過程中，首先用戶提交書面的變更請求，詳細申明變更的理由、變更方案、變更的影響范圍等。然后由變更控制機構(gòu)確定控制變更的機制、評價其技術(shù)價值、潛在的副作用、對其它配置對象和系統(tǒng)功能的綜合影響以及項目的開銷、并把評價的結(jié)果以變更報告的形式提交給變更控制負責人（最終決定變更狀態(tài)和優(yōu)先權(quán)的某個人或小組）。130第130頁，共142頁。對每個批準了的變更產(chǎn)生一個工程變更順序（ECO），描述進行的變更、必須考慮的約束、評審和審計的準則等。要做變更的對象從項目數(shù)據(jù)庫中檢出（check out），對其做出變更，并實施適當?shù)馁|(zhì)量保證活動。然后再把對象登入（check in）到數(shù)據(jù)庫中并