軟件工程復(fù)習(xí)

軟件的特性軟件是一種規(guī)律實體，而不是具體的物理實體。它具有抽象性軟件的開發(fā)設(shè)計、生產(chǎn)、維護(hù)與硬件不同在軟件的運行和使用期間，沒有硬件那樣的機(jī)械磨損、老化問題大多數(shù)軟件是定制的軟件的開發(fā)和運行常常受到計算機(jī)系統(tǒng)的限制對計算機(jī)系統(tǒng)有著不同程度的依靠性軟件開發(fā)至今尚未完全擺脫手工藝的開發(fā)方式軟件是簡單的軟件本錢相當(dāng)昂貴相當(dāng)多的軟件工作涉及到社會因素軟件危機(jī)的表現(xiàn)、緣由軟件危機(jī)---主要表現(xiàn)：對軟件開發(fā)本錢和進(jìn)度的估量不準(zhǔn)確用戶不滿足軟件質(zhì)量不高、牢靠性差軟件常常不行維護(hù)、錯誤難以改正缺乏適當(dāng)?shù)奈臋n資料軟件本錢占系統(tǒng)總本錢的比例逐年上升〔1985 90%〕軟件開發(fā)速度跟不上計算機(jī)進(jìn)展速度歸結(jié)為主要為三方面--“時間、本錢、質(zhì)量”軟件危機(jī)--緣由：軟件規(guī)模日漸浩大〔數(shù)量、功能、本錢、質(zhì)量、時間〕軟件開發(fā)治理困難。規(guī)律部件而不是物理部件。發(fā)的質(zhì)量也較難評價。因此，治理和掌握軟件開發(fā)過程相當(dāng)困難。開發(fā)人員錯誤的觀念、方法和技術(shù)重編程、輕需求。生產(chǎn)方式落后：個體手工方式。開發(fā)技術(shù)落后\開發(fā)工具落后無視軟件開發(fā)前期的需求分析開發(fā)過程缺乏統(tǒng)一的、標(biāo)準(zhǔn)化的方法論的指導(dǎo)文檔資料不齊全或不準(zhǔn)確無視與用戶之間、開發(fā)組成員之間的溝通無視測試的重要性不重視維護(hù)或由于上述緣由造成維護(hù)工作的困難需求變化預(yù)料缺乏用例歸約用例規(guī)約--進(jìn)展用例闡述用例規(guī)約：更進(jìn)一步的精度用例文檔的核心，而用例圖作為用例文檔的總圖進(jìn)一步的精度：有層次的文檔文檔中每一句話都有其價值用例規(guī)約組成用例名稱：處理銷售用例標(biāo)識涉及的參與者涉及的用例描述用例的規(guī)格說明前置條件與后置條件正常大事流備選大事流其它非功能需求、設(shè)計約束、尚存在的問題舉例(非正式型)處理退貨主要成功場景：顧客帶著商品到收款處退貨，出納員使用POS終端記錄每一件。?？蛇x場景：假設(shè)系統(tǒng)中找不到商品標(biāo)識，那么就通知出納員并建議他手工輸入商品標(biāo)識碼〔或許商品的標(biāo)識已經(jīng)破損之間的通信失敗，那么就。正式型用例UC1：處理銷售主要參與者：出納員受益人及其利益：出納員：需要準(zhǔn)確、快速的輸入，并且不消滅支付錯誤銷售人員：需要銷售款得到更顧客：需要購置并花費最小的精力得到快速的效勞，并需要支持退貨功能公司：需要準(zhǔn)確地記錄交易并滿足客戶的利益。需要支付授權(quán)效勞記錄可承受的支付。需要一些容錯功能。需要賬目和存貨清單得到自動的快速更政府稅務(wù)機(jī)構(gòu)：需要從每一次銷售中收稅。支付授權(quán)效勞：需要用正確的格式和協(xié)議傳來的數(shù)字授權(quán)懇求。需要準(zhǔn)確計算它們可支付給商店的款額前置條件：出納員需要身份識別并授權(quán)后置條件：存儲了銷售狀況，正確地計算了稅金，更了賬目和存貨清單，記錄了銷售額，打印了收據(jù)主要成功場景：POS終端出預(yù)備購置出納員開頭一次的銷售出納員輸入商品標(biāo)識碼計算所應(yīng)付的款額。出納員重復(fù)步驟34，始終處處理完全部商品為止。系統(tǒng)給出所應(yīng)支付的總款額并計算稅金出納員告知顧客總價并懇求付款顧客付款，系統(tǒng)處理支付及存貨清單系統(tǒng)系統(tǒng)打印收據(jù)顧客帶著收據(jù)和商品離開類與類圖類及類之間的關(guān)系案例李小平是一個愛書之人，家里各類書籍已過千冊，而尋常又時常有朋友外借，因此需要一個個人圖書治理系統(tǒng)。該系統(tǒng)應(yīng)當(dāng)能夠?qū)母拘畔从嬎銠C(jī)類、表打印。另外，還期望能夠?qū)馁徶媒痤~、冊數(shù)按特定時間周期進(jìn)展統(tǒng)計。覺察類李小平是一個愛書之人家里各類書籍朋友外個人圖書治理系統(tǒng)根本信息按計算機(jī)類、非計算機(jī)類分別建檔，實現(xiàn)按書名、作者、類別、出版社等關(guān)鍵字的組合查詢功能書籍時系統(tǒng)會自動按規(guī)章生成書號修改信息記錄，可對外借狀況列表購置金額、冊數(shù)按特定時間周期進(jìn)展統(tǒng)計。篩選備選類也無須對其進(jìn)展建模；很明顯“書籍”是一個很重要的類，而“書名屬性，因此“規(guī)章”可以作為編寫“書籍”類構(gòu)造函數(shù)的指南?！案拘畔ⅰ眲t是書名、作者、類別等描述書籍的根本信息統(tǒng)稱字”則是代表其中之一，因此無需對其建模；關(guān)詞語，并不是問題域的本質(zhì)，因此先可以將其淘汰掉；篩選修選類建模，并改名為“計算機(jī)類書籍”和“非計算機(jī)類書籍借狀況將組成“外借狀況列表友”—借閱主體。雖然到本系統(tǒng)中并不需要建立“朋友”的資料庫，但考了能夠更好地表述，將“外借狀況”改名為“借閱記錄模，而“特定時限”則是統(tǒng)計的范圍，也無需將其建模；不過從這里的分就是執(zhí)行統(tǒng)計的主體。得到候選類在使用“名詞動詞法”查找類的時候，很多團(tuán)隊會在此消耗大量的時間，特別建立概要的了解，無需太過咬文嚼字關(guān)聯(lián)分析建模多重性分析建模職責(zé)分析書籍類：從需求描述中，可找到書名、類別、作者、出版社；同時從統(tǒng)計的需要中，可得知“定價”也是一個關(guān)鍵的成員變量。書籍列表類：書籍列表就是全部的藏書列表，其主要的成員方法是增、修改、查詢〔按關(guān)鍵字查詢、統(tǒng)計〔按特定時限統(tǒng)計冊數(shù)與金額。借閱記錄類：借閱人〔朋友、借閱時間。借閱記錄列表類：主要職責(zé)就是添加記錄〔借出、刪除記錄〔歸還〕以及打印借閱記錄挨次圖SequenceDiagram〔用例分析和設(shè)計階段。描述對象是如何交互的，即描述消息如何在對象間發(fā)送和接收?？v軸時間、橫軸對象描述了對象之間傳送消息的時間挨次，用來表示用例中的行為挨次顯示了交互的參與者以及參與者之間的消息挨次全部或局部用例而與參與者交互。留意：一個大事流一個挨次圖挨次圖例如-還書挨次圖例如-POS機(jī)軟件測試白盒測試也稱玻璃盒測試建立在對程序的構(gòu)造和語句的了解，以及對程序代碼內(nèi)部構(gòu)造的了解的根底上測試掩蓋率測試的目標(biāo)兩種測試方法掌握構(gòu)造測試條件測試數(shù)據(jù)流測試循環(huán)測試根本路徑測試測試掩蓋率承受白盒法進(jìn)展測試時，考慮的是測試用例對程序內(nèi)部規(guī)律的掩蓋程度。最徹底的白盒法是掩蓋程序中的每一條路徑，但這往往大到無法實現(xiàn)。因此承受其它一些標(biāo)準(zhǔn)來量度掩蓋的程度，并期望掩蓋程度盡可能高些。條件測試錯誤緣由布爾運算符錯誤布爾變量錯誤布爾括號錯誤關(guān)系運算符錯誤算術(shù)表達(dá)式錯誤策略分支測試：每個分支至少執(zhí)行一次3-4個用例白盒測試的目標(biāo)黑盒測試黑盒測試定義又稱功能測試或數(shù)據(jù)驅(qū)動測試，主要關(guān)注軟件的整體功能要在軟件的接口處進(jìn)展，不考慮程序內(nèi)部的規(guī)律構(gòu)造和內(nèi)部特性覺察錯誤類型是否有不正確或遺漏的功能界面錯誤輸入能否正確地承受，能否輸出正確的結(jié)果是否有數(shù)據(jù)構(gòu)造錯誤或外部信息〔如數(shù)據(jù)文件〕訪問錯誤性能上是否滿足要求是否有初始化或終止性錯誤比照測試(背靠背測試)也稱“背靠背”測試、比較測試比照測試法主要用于處理被認(rèn)為格外關(guān)鍵的系統(tǒng)時，在比照測試法中，將開發(fā)同一軟件的兩個獨立但一樣的版本不同的團(tuán)隊將開發(fā)這兩個版本度AlphaBeta測試的定義與區(qū)分承受Alpha測試和Beta測試來覺察只有最終用戶才能覺察的問題Alpha(α )測試：由一個用戶在開發(fā)者的場所、在開發(fā)者指導(dǎo)下進(jìn)展測試Beta(β )測試：由最終用戶在一個或多個用戶場所單獨地進(jìn)展測試測試停頓測試只能覺察軟件中的錯誤和缺陷，不能證明軟件沒有錯誤和缺陷停頓策略：單位時間內(nèi)覺察的錯誤數(shù)法缺陷密度法缺陷池方法缺陷引入法缺陷密度缺陷密度可以定義為每行代碼的錯誤數(shù)0.003這樣的數(shù)字10003一個更有用的方法是將缺陷密度設(shè)置為每千行代碼〔KLOC〕的缺陷數(shù)我們可以使用缺陷密度度量來確定是否可以公布正在開發(fā)的軟件的某個特定版本缺陷池這種方法中，我們將使用兩個池，例如池X和池Y來跟蹤缺陷現(xiàn)在，讓池XDxYDy軟件中覺察的唯一缺陷總數(shù)如下：唯一缺陷總數(shù)=Dx+Dy-XY中覺察的缺陷數(shù)軟件中的缺陷總數(shù)可以估量為：缺陷總數(shù)=(Dx*Dy)/在XY中覺察的缺陷數(shù)缺陷池—mysoft3.0X池 475錯誤Y池 370錯誤125個缺陷同時消滅在X、Y池中唯一缺陷總數(shù)=475+370-125=720缺陷總數(shù)=475*370/125=1406可能剩余缺陷=1406-720=686隱蔽缺陷密度=686/1406=48.79%缺陷引入在此方法中，一組測試人員有意將缺陷埋入軟件中另一組測試人員將試圖發(fā)現(xiàn)這些缺陷這么做的主要目的是估量被檢測到的引入的缺陷數(shù)與有意埋入的缺陷總數(shù)之比這使我們可以了解在此過程中未被覺察的不是有意埋入的缺陷的總數(shù)缺陷引入例如75個缺陷檢測到引入缺陷總數(shù)：DS=35覺察的不是引入的缺陷：DUF=520軟件中的缺陷總數(shù)=75/35*520=1114沒有覺察的缺陷數(shù)=1114-520=594工程治理工程打算P315面對規(guī)模的度量：LOC、KLOCLOC作為面對規(guī)模的度量最為大家生疏，它們是直接可以測量的〔進(jìn)展比較面對規(guī)模的度量是對軟件以及開發(fā)軟件過程的直接測量這些度量包括花費的精力和金錢、KLOC〔千行代碼、創(chuàng)立的文檔頁數(shù)、錯誤數(shù)以及工程中的開發(fā)人員數(shù)面對規(guī)模的度量面對功能的度量：FP功能點度量的優(yōu)勢需求階段可以估量工程的規(guī)模。推測實現(xiàn)軟件功能所需源語句的數(shù)目語言無關(guān)多種語言工程中測量工程的生產(chǎn)率MIS應(yīng)用程序不適用實時軟件、嵌入式系統(tǒng)、數(shù)學(xué)軟件可以使用功能部件的度量FP功能點的公式 FP=UFC*TCF 〔UFC：未調(diào)整功能點計數(shù)雜度因子〕UFC-未調(diào)整功能點計數(shù)功能計數(shù)項：外部輸入外部輸出

TCF：技術(shù)復(fù)外部查詢外部文件內(nèi)部文件本錢估算模型：COCOMOCOCOMOBarryBoehm開發(fā)的(南加州大學(xué))COCOMO81COCOMOII模型系列COCOMO81模型類別：根本COCOMO：靜態(tài)單變量模型COCOMO：考慮影響因素，調(diào)整模型COCOMO：考慮各個步驟的影響工程類型：有機(jī):Organic嵌入式:Embedded半有機(jī):Semidetached有機(jī):Organic，各類應(yīng)用程序，例如數(shù)據(jù)處理、科學(xué)計算等受硬件的約束比較小，程序的規(guī)模不是很大嵌入式:Embedded系統(tǒng)程序，例照實時處理、掌握程序等嚴(yán)密聯(lián)系的硬件、軟件和操作的限制條件下運行，軟件規(guī)模任意半有機(jī):Semidetached各類有用程序，介于上述兩種軟件之間，例如編譯器〔程序〕規(guī)模和簡單度都屬于中等或者更高Bohem模型：？？？工作量=〔平均最大規(guī)模+最小規(guī)模+4*最可能的規(guī)?！?6甘特圖、PERT網(wǎng)絡(luò)圖風(fēng)險分析風(fēng)險治理風(fēng)險分析影響的可能性這些因素還可以用于風(fēng)險分析風(fēng)險分析中還必需考慮如程序／應(yīng)用程序的實現(xiàn)／操作方法類型、參與人數(shù)等其它因素風(fēng)險確定風(fēng)險通常依據(jù)標(biāo)題分組，例如工程風(fēng)險、技術(shù)風(fēng)險和商業(yè)風(fēng)險等工程風(fēng)險涉及到進(jìn)度安排問題、人員問題、資源問題、需求問題等性等問題商業(yè)風(fēng)險涉及到關(guān)于投資回報和到達(dá)收支平衡必需的時間的問題風(fēng)險推測風(fēng)險推測中主要包括四個活動測量風(fēng)險發(fā)生的概