軟件工程總結樣本

軟件工程復習提綱TOC\o"1-3"\h\u21448第1章 軟件工程簡介 225308軟件是什么 231863第2章 過程綜述 217106軟件工程定義 216169層次化 3285通用過程框架 326311第3章過程模型 4493各種過程模型 48189第4章敏捷視角下過程 615220敏捷宣言 631628第5章系統(tǒng)工程 727003第6章需求工程 89208質量功能布置（QFD） 831442分析模型元素 1127078第7章構建分析模型 1128431第8章設計工程 118885第9章進行體系構造設計 1220343體系構造風格分類 1231621第10章構件級設計建模 131035第11章完畢顧客界面設計 136487黃金規(guī)則 133592第12章軟件測試方略 143753軟件測試需要籌劃和執(zhí)行一系列測試環(huán)節(jié) 1415195第13章測試技術 152417兩個不同測試用例設計技術 1517121第14章產品度量 15

第1章 軟件工程簡介軟件是什么軟件是形成配備一組術語或對象，涉及：程序(計算機程序)：指令集合,通過執(zhí)行這些指令可以滿足預期特性、功能和性能需求數(shù)據(jù)構造:它使得程序可以充分運用信息文檔:描述程序操作和使用文檔（圖文資料）舉例闡明“意外效應法則”（lawofunintendedconsequences）在計算機軟件方面應用。某些新科技創(chuàng)造創(chuàng)造會給其她某些看似無關技術領域、商業(yè)公司、公眾甚至整個社會文化帶來深遠而出人意料影響和作用。如：用自己語言描述保證通曉規(guī)律（TheLawofConservationofFamiliarity）、質量衰減規(guī)律（TheLawofDecliningQuality）以及組織穩(wěn)定性守恒規(guī)律（TheLawofConservationofOrganizationalStability）。保證通曉性規(guī)律(1980)：隨著E類型系統(tǒng)演化，所有有關人員（如開發(fā)人員、銷售人員和顧客）都必要清晰地理解演化內容和過程，以便達到滿意演化效果。質量衰減規(guī)律(1996)：如果沒有嚴格維護和適應性調節(jié)使之適應運營環(huán)境變化，E類型系統(tǒng)質量有衰減趨勢。組織穩(wěn)定性守恒規(guī)律(1980)：一種不斷演化E類型系統(tǒng)，其組織在全球范疇內平均有效活動率在產品生命周期中是保持不變。在交付最后顧客之前，或者第1個版本投入使用之后，許多應用程序都會有頻繁變更。為防止變更引起軟件失效，請?zhí)岢瞿承┯行Ы鉀Q辦法。一方面從心態(tài)上承認變化是必然，咱們可以通過在軟件發(fā)布之邁進行alpha，beta測試，運用迭代模式，在吸取測試過程中經驗之后，立即改進軟件。同步保持和顧客良好溝通，在提交顧客時進行恰當培訓，讓顧客按照開發(fā)思路進行試用，可以見減少因用法不當引起變化。第2章 過程綜述軟件工程定義軟件工程是：（1）將系統(tǒng)化、規(guī)范、可量化辦法應用于軟件開發(fā)、運營和維護，即將工程化辦法應用于軟件。（2）在（1）中所述辦法研究。層次化通用過程框架溝通（Communication）策劃（Planning）建模（Modeling）需求分析（Analysisofrequirements）設計（Design）構建（Construction）代碼生成（Codegeneration）測試（Testing）布置（Deployment）重點：Baetjer說過“軟件過程為顧客和設計者之間、顧客和開發(fā)工具之間以及設計者和開發(fā)工具之間提供交互途徑[技術]?！痹O計下面問題“⑴設計者應當問顧客；⑵顧客應當問設計者；⑶顧客對將要構建軟件自問；⑷設計者對于軟件產品和建造該產品采用軟件過程自問。（如何獲取需求）為溝通活動設計一種任務集辨認重要客戶和其她共利益者與客戶會談環(huán)境無關話題寫一頁項目范疇評審范疇闡明討論項目大體階段商定各個部門代表，并使她們互相結識為籌劃活動做準備用自己話描述過程框架。當咱們談到框架活動合用于所有項目時，與否意味著對于不同規(guī)模和復雜度項目，可應用相似工作任務？請解釋。過程框架定義了若干小框架活動，為完整軟件開發(fā)過程建立基本，這些框架活動可以廣泛用于所有軟件開發(fā)項目，無論這些項目復雜性和規(guī)模如何，此外，還涉及某些合用于各個軟件過程普適性活動。雖然過程框架是普適性，但是對于不同規(guī)模和復雜度項目不能應用相似工作任務。一方面在軟件開發(fā)不同階段，工作任務不同。另一方面不同軟件項目有不同需求，有特殊背景，找不到一種通用工作任務。圖2-1中，基于“質量關注點”指明了軟件工程三個層次。這意味著在整個開發(fā)組織內采用質量管理活動，如“全面質量管理”。仔細研究，并列出全面質量管理活動中核心原則大綱。過程模型各種過程模型慣例軟件過程模型力圖給軟件開發(fā)帶來秩序和構造。盡管每一老式過程模型都建議了一種不同過程流，但均實現(xiàn)了同樣一組通用框架活動：溝通、籌劃、建模、構建和布置。瀑布模型建議線性流程框架活動，與軟件世界里當代軟件開發(fā)實際（持續(xù)變更、演化系統(tǒng)、急迫開發(fā)時間）不符；但瀑布模型的確合用于需求定義清晰且穩(wěn)定軟件開發(fā)；增量軟件過程模型通過一系列增量發(fā)布產生軟件。RAD模型迅速應用程序開發(fā)，是為大型且必要在嚴格時間內提交項目而設計；演化過程模型結識到大多數(shù)軟件工程項目迭代特性，其設計目是為了適應變更演化模型（如原型模型、螺旋模型），其迅速產生增量工作產品（或是軟件工作版本），這些模型可以應用于所有軟件工程活動——從概念開發(fā)到長期軟件維護?；跇嫿Ｐ蛷娬{構件復用及組裝。形式化辦法模型倡導采用數(shù)學辦法進行軟件開發(fā)和驗證。面向方面模型目是解決跨整個軟件體系構造橫切關注點；統(tǒng)一過程模型是一種“用例驅動、以體系構造為核心、迭代及增量”軟件過程框架，由UML辦法和工具支持。統(tǒng)一過程是一種增量模型，定義了五個階段：起始階段：涉及顧客溝通和籌劃活動兩個方面，強調定義和細化用例，并將其作為重要模型；細化階段：涉及顧客溝通和建模活動，重點是創(chuàng)立分析和設計模型，強調類定義和體系構造表達；構建階段：細化設計模型，并將設計模型轉化為軟件構建實現(xiàn)；轉化階段：將軟件從開發(fā)人員傳遞給最后顧客，并由顧客完畢Beta測試和驗收測試；生產階段：持續(xù)地監(jiān)控軟件運營，并提供技術支持。重點：開發(fā)質量“足夠好”軟件，其長處和缺陷是什么？當咱們追求開發(fā)速度賽過產品質量時候，會產生什么后果？咱們總在質量和開發(fā)速度之間做取舍，開發(fā)質量“足夠好”軟件，明顯強調質量，長處是使軟件符合或超過客戶預期，在性能上，交互上力圖做到盡善盡美。缺陷是忽視了開發(fā)成本，很容易導致開發(fā)時間延期，影響軟件工程后幾種階段工作，對全局導致不利影響。當沿著螺旋過程流發(fā)展時候，你對正在開發(fā)或者維護軟件看法是什么？在螺旋模式下，開發(fā)過程是迭代式，采用循環(huán)方式逐漸加深系統(tǒng)定義和實現(xiàn)深度，同步減少風險。當軟件交付使用后，螺旋模式沒有停止，它將永遠保持可操作性，每一圈完畢后都會計算成本，可以更好維護軟件?？梢院嫌脦追N過程模型嗎？如果可以，舉例闡明?？梢浴追N過程模型，都是互相兼容可以互相擴展，如螺旋模型結合了原型迭代性質和瀑模型系統(tǒng)性和可控性特點。在詳細項目實行中，對于某一某些可以合用幾種過程模型，例如形式語言與自動機演示軟件在算法開發(fā)過程，就需要使用形式化辦法模型，用嚴格數(shù)學符號定義形式語言和自動機。尚有某些桌面應用程序前臺UI某些，可以單獨使用RAD模型，例如用delphi語言開發(fā)桌面窗體就是一種RAD實現(xiàn)。而其她某些可以使用其她如瀑布式模型等辦法。敏捷視角下過程敏捷宣言個體和交互賽過過程和工具（Individualsandinteractionsoverprocessesandtools）可工作軟件賽過寬泛文檔（Workingsoftwareovercomprehensivedocumentation）客戶合伙賽過合同談判（Customercollaborationovercontractnegotiation）響應變化賽過遵循籌劃（Respondingtochangeoverfollowingaplan）重點：與否每一種敏捷過程都可以用第2章所提及通用框架性活動來描述？建一張表，將通用活動和每個敏捷過程所定義活動相應起來。用自己語言描述（用于軟件項目）敏捷性？普遍存在變化是敏捷基本動力，敏捷需要有效響應變化，它勉勵在共利益者之間進行更便利溝通和協(xié)作，強調可運營軟件迅速交付。敏捷容許項目團隊調節(jié)并合理安排任務，理解易變性并制定籌劃。精簡并維持最基本工作產品，強調增量交付，迅速提供可運營軟件。許多敏捷過程模型推薦面對面交流，事實上，當前軟件開發(fā)團隊成員及其客戶在地理上是分散。你與否以為這意味著這種地理上分散應當避免？能否想出一種辦法克服這個問題。我以為這種地理上分散是現(xiàn)實，是無法避免。我以為可以分為客戶和開發(fā)人員分散，開發(fā)人員內某些散兩種狀況。對于第一種：產品經理需要同客戶建立一條良好通信信道，如通過email,即時聊天工具進行定期溝通。對于第二種：開發(fā)人員需定期組織交流，通過webgroup消除地理上分散。為什么需求變化這樣大，人們終歸無法擬定她們想要什么嗎？我以為是這樣。其實需求是客戶對她們心目中軟件一種描述，由于軟件還沒有實現(xiàn)，這種描述便是不擬定，模糊。同步當今世界處在高速變化之中，人們需求會隨著環(huán)境變化而變化。因此敏捷開發(fā)承認變化，以為普遍存在變化是敏捷基本動力。系統(tǒng)工程在寫下每行代碼之前理解所要解決問題(詳見溝通與建模)理解基本設計原則和概念選取一種可以滿足軟件構建以及運營環(huán)境規(guī)定編程語言選取一種能提供工具以簡化工作編程環(huán)境構件級編碼完畢后進行單元測試系統(tǒng)工程層次圖重點：對你熟悉系統(tǒng)、產品或服務，建立它們層次系統(tǒng)。層次應當向下擴展到簡樸系統(tǒng)要素（硬件、軟件等），至少得到層次樹一種分支。即時聊天系統(tǒng)系統(tǒng)工程師由3種來源：系統(tǒng)開發(fā)人員、顧客或某些外部組織。討論一下每種來源利與弊。描述一種抱負系統(tǒng)工程師。研究文獻并寫出一篇簡短文章描述建模和模仿工具是如何工作?；蛘呤鞘占瘍蓚€或更多商用建?；蚰７鹿ぞ呶墨I，并且比較它們相似處與不同處。需求工程質量功能布置（QFD）是一種將客戶規(guī)定轉化成軟件技術需求技術。QFD“目是最大限度地讓客戶從軟件工程過程中感到滿意”，并強調“什么是對客戶有價值”。確認三類需求：正常需求：反映了在和客戶開會時擬定針對某產品或系統(tǒng)目的。如果實現(xiàn)了這些需求，將滿足客戶（例如：所規(guī)定圖形顯示類型、特定系統(tǒng)功能以及已定義性能級別）。盼望需求：隱含在產品或系統(tǒng)中，并且也許是非?；疽灾劣诳蛻魶]有顯式地闡明，但缺少這些將導致客戶明顯不滿（例如：易交互性、可操作性、可靠性、易安裝等）。令人興奮需求：反映了客戶盼望之外特點，但如果實現(xiàn)了這些特點，將會使客戶非常滿意。重點：為如下活動之一開發(fā)一種完整用例：在ATM提款；在餐廳使用信用卡付費；使用一種在線經紀人賬戶購買股票；使用在線書店搜索書（某個指定主題）；ATM用例圖“ATM取款”用例規(guī)約用例名稱：ATM取款簡述：客戶持銀行卡（本行或其她行）從ATM提取鈔票actors:客戶和銀行主機基本流：客戶插入銀行卡。ATM從銀行卡讀入卡號（含銀行標記和賬號），驗證卡有效性?？蛻糨斎朊艽a。ATM驗證帳號和密碼。ATM顯示涉及取款在內服務功能，客戶選取“取款”。輸入取款額：客戶輸入數(shù)量為50元倍數(shù)取款額。ATM向銀行主機告知卡號、密碼、賬號和取款額，獲得具有最新余額取款成功確認信息。ATM打印并吐出憑條。ATM清點并吐出鈔票，記錄取款成功。ATM詢問客戶與否繼續(xù)服務?？蛻暨x取否，ATM吐出銀行卡，結束用例，否則回到環(huán)節(jié)5。[用例結束]備選流：3-7，10a.客戶取消服務：ATM記錄服務取消，打印憑條，吐出憑條和銀行卡，[用例失敗]3,6,11a.客戶未及時輸入超過30秒：ATM吞卡，[用例失敗]2a.卡無效：ATM吞卡，[用例失敗]2b.讀卡器或卡被損壞：ATM吞卡，[用例失敗]4a.密碼錯：4a1.客戶重新輸入密碼合計3次密碼錯誤：ATM吞卡，[用例失敗]4b.無此帳號：ATM吞卡，[用例失敗]5a.ATM無鈔票：ATM不顯示“取款”功能，客戶可選取其她服務，[用例失敗]6a.取款額超過ATM鈔票余額：ATM規(guī)定客戶重新輸入取款額。7a.帳戶余額局限性：ATM規(guī)定客戶重新輸入取款額。7b.取款額超過當天最高限額：ATM規(guī)定客戶重新輸入取款額。7c.網絡或銀行主機失效、通訊超時：ATM記錄服務取消，打印憑條，吐出憑條和銀行卡，[用例失敗]8a.憑條打印失敗，紙用完或卡紙：8a1.ATM告知銀行主機取消取款8a2.ATM記錄服務取消，吐出銀行卡，[用例失敗]9a.吐鈔票失?。?a1.ATM告知銀行主機取消取款9a2.ATM記錄服務取消，吐出銀行卡，[用例失敗]11a.客戶未及時取走卡：ATM吞卡，[用例失敗]業(yè)務規(guī)則：7b單日取款不得超過5000元6c每次取款不得超過元為什么大量軟件開發(fā)人員沒有足夠注重需求工程？此前有無什么狀況讓你可以跳過需求工程？一方面軟件開發(fā)人員以為客戶已經把需求說清晰了，但是大多數(shù)狀況初步需求都是模糊。另一方面工程進度規(guī)定很急迫，軟件開發(fā)人員迫切但愿投入到代碼編寫階段。最后和客戶溝通比較困難，使得大多數(shù)軟件開發(fā)人員不注重需求工程。又一次，項目時間很短，規(guī)定一種月完畢，咱們只是大體上對需求有一種結識，就跳過需求工程開始動手編碼，成果固然失敗了。簡短地討論一種分析模型每個元素，指出每個元素對模型貢獻，每個元素為什么是唯一以及每個元素所示概要信息。分析模型元素基于場景元素(用例圖)：使用基于場景辦法可以從顧客視角描述系統(tǒng)。例如基本用例和基于模板用例。普通分析模型第一步，作為創(chuàng)立其她模型輸入。基于類元素（類圖）:每個使用場景都暗示著當一種參加者與系統(tǒng)交互時所操做一組對象，這些對象被提成類——具備相似屬性和共同行為事務集合。行為元素(狀態(tài)圖)：狀態(tài)指明了在某個特殊事件后采用什么動作。面向信息流模式：描述信息轉換。第7章構建分析模型重點：簡樸用幾句話嘗試闡明構造化分析和面向對象分析重要差別？構造化分析考慮數(shù)據(jù)和解決，其中數(shù)據(jù)作為獨立實體轉換，數(shù)據(jù)對象建模定義了對象屬性和關系，操作對象解決建模應當表白數(shù)據(jù)對象在系統(tǒng)內流動時解決如何轉換數(shù)據(jù)。面向對象分析關注于定義類和影響客戶需求類之間協(xié)作方式。有無也許在分析模型創(chuàng)立后及時開始編碼？解釋你答案，然后說服反方。設計工程重點：如果軟件設計不是程序（它擬定不是），那么它是什么？是一套結實、合用和賞心悅目模型或設計表達。它涉及數(shù)據(jù)、類設計，體系構造設計、接口設計、構件設計。當你“編寫”程序時你設計軟件嗎？軟件設計和編碼有什么不同嗎？設計。軟件設計是逐漸細化一種可以工作模型，而編碼是在生成一種可執(zhí)行程序。軟件設計重要關注與否實現(xiàn)了顧客需求，必要從實現(xiàn)角度闡明數(shù)據(jù)域、功能域和行為域，是編碼工作指引。用你自己話闡明軟件體系構造。系統(tǒng)構造是程序構件（模塊）構造或組織，這些構件交互形式以及這些構件因此數(shù)據(jù)構造。構件可以被推廣，用于代表重要系統(tǒng)元素及其交互。進行體系構造設計體系構造風格分類以數(shù)據(jù)為中心體系構造數(shù)據(jù)流體系構造：當輸入數(shù)據(jù)通過一系列計算和操作構件變換形成輸出數(shù)據(jù)時，可以應用這種體系構造。信息流被描述為單個數(shù)據(jù)項，被稱為事務，她可以沿多條途徑中一條觸發(fā)其她數(shù)據(jù)流。調用和返回體系構造面向對象體系構造層次體系構造重點：使用數(shù)據(jù)流程圖和解決論述，描述一種具備明顯數(shù)據(jù)流特性和一種具備明顯事務流特性計算機系統(tǒng)。數(shù)據(jù)流特性：opengl管線事務流特性：銀行轉賬以房子或建筑體系構造作比喻，與軟件體系構造進行對比。老式建筑體系構造學科和軟件體系構造有何相似之處？有何不同之處？構件級設計建模構件：系統(tǒng)中某一定型化、可配備和可替代部件，該部件封裝并暴露了某些列接口。內聚性：內聚性cohesion意味著構件或者類只封裝那些互有關聯(lián)密切，以及與構件或類自身有密切關系屬性和操作。耦合性：類之間彼此聯(lián)系限度一種定性度量完畢顧客界面設計黃金規(guī)則置顧客于控制之下；以不逼迫顧客進入不必要或不但愿動作方式來定義交互模式。提供靈活度交互。容許顧客交互被中斷和撤銷。當技能級別增長時可以使交互流線化并容許定制交互。使顧客與內部技術細節(jié)隔離開來。設計容許顧客與出當前屏幕上對象直接交互。減少顧客記憶承擔；減少對短期記憶規(guī)定。建立故意義缺省。定義直觀快捷方式。界面視覺布局應當基于真實世界象征。以不斷進展方式揭示信息。保持界面一致性。容許顧客將當前任務放入故意義環(huán)境中。在應用系統(tǒng)家族內保持一致性。如果過去交互模型已經建立起了顧客盼望，除非有不得已理由，否則不要變化它。重點：試給出兩個附加“減少顧客記憶承擔”、“保持界面一致性”設計原則。假設你被邀請開發(fā)一種基于WEB家庭銀行系統(tǒng)。請給出顧客模型、設計模型、心理模型和實現(xiàn)模型。軟件測試方略軟件測試需要籌劃和執(zhí)行一系列測試環(huán)節(jié)單元測試集成測試確認測試系統(tǒng)測試重點：用自己話描述驗證與確認不同。兩者都要使用測試用例設計辦法和測試方略嗎？驗證是保證軟件正的確現(xiàn)某一特定功能某些列活動；確認是指保證開發(fā)軟件可追溯到顧客需求此外一系列活動。都需要。