2014軟件工程各章節(jié)重要知識點(按考試大綱總結(jié))_第1頁
2014軟件工程各章節(jié)重要知識點(按考試大綱總結(jié))_第2頁
2014軟件工程各章節(jié)重要知識點(按考試大綱總結(jié))_第3頁
2014軟件工程各章節(jié)重要知識點(按考試大綱總結(jié))_第4頁
2014軟件工程各章節(jié)重要知識點(按考試大綱總結(jié))_第5頁
已閱讀5頁,還剩27頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、2014軟件工程各章節(jié)重點知識點(按考試大綱總結(jié))第1章 :軟件工程的范疇THE SCOPE OF SOFTWARE ENGINEERING1掌握軟件工程、軟件危機、生命周期的概念 1%Software engineering is a discipline學(xué)科 aim is the production生產(chǎn) of software.fault-free;delivered on time ;within budget;satisfies the clients needs;be easy to modify when the needs changeSoftware crisis:the q

2、uality of software was unacceptably low,deadlines and budgets were not being met.Life-cycle model:The steps to follow遵循 when building構(gòu)建 software,A theoretical description理論描述 of what should be done.Life cycle:The actual steps實際步驟 performed執(zhí)行 on a specific具體 product.2掌握維護的3種分類并能夠結(jié)合具體例子進行判斷 1%Postdeli

3、very maintenance:Corrective糾錯性 maintenance;Perfective完善性 maintenance;Adaptive適應(yīng)性 maintenanceCorrective糾錯性 maintenance:removal去除 of residual faults殘留錯誤 ;leaving the specifications規(guī)格說明文檔 unchangedPerfective完善性 maintenance:additional functionality額外功能;decreased response time減少響應(yīng)時間Adaptive適應(yīng)性 maintenanc

4、e:changes made in response to changes in the environment3掌握為什么沒有計劃、文檔和測試階段 1%Why There Is No Planning Phase計劃階段, Testing Phase測試階段 or Documentation Phase文檔階段?Planning, continual持續(xù)的 testing and documentation activities活動 are carried out執(zhí)行 throughout貫穿于 the life cycle.There is no separate獨立的 planning,

5、 testing or documentation phase.This testing is the responsibility職責 of Every software professional專業(yè)人員, and The software quality assurance group軟件質(zhì)量保證小組(SQA group) Documentation Must Always be Current:Key individuals may leave before the documentation is complete.We cannot perform a phase without h

6、aving the documentation of the previous phase.We cannot test without documentation.We cannot maintain without documentation.4掌握軟件工程的傳統(tǒng)生命周期模型(瀑布模型)的階段劃分和各階段的主要任務(wù)1%Classical(Waterfall瀑布) Life-Cycle Model 1. Requirements phaseExplore研究 the concept概念;Elicit提取 the clients requirements客戶需求2. Analysis (spe

7、cification) phaseAnalyze分析 the clients requirements;Draw up制定 the specification document規(guī)格說明文檔(specifications);Draw up the software project management plan軟件項目管理計劃(SPMP);“What the product is supposed期望 to do”3. Design phaseArchitectural design結(jié)構(gòu)設(shè)計, followed by;Detailed design詳細設(shè)計;“How the product do

8、es it”4. Implementation phaseCoding編碼;Unit testing單元測試;Integration集成;Acceptance testing驗收測試5. Postdelivery maintenanceCorrective糾錯性 maintenance;Perfective完善性 maintenance;Adaptive適應(yīng)性 maintenance6. Retirement5掌握傳統(tǒng)的維護觀念與現(xiàn)代的維護觀念之間的區(qū)別1%Classical maintenance is Development-then-maintenance model開發(fā)-維護 模型Th

9、is is a temporal時間性 definition,Classification歸類 as development or maintenance depends on取決于 when an activity is performed.Modern Maintenance is nowadays defined as:The process過程 that occurs when a software artifact軟件制品 is modified被修改 because of a problem or because of a need for improvement改善 or ada

10、ptation適應(yīng).Maintenance occurs whenever software is modified修改.Regardless of不管 whether this takes place before or after installation of the software product.Modern maintenance is corrective, perfective, or adaptive maintenance performed at any time.第2章 :軟件生命周期模型SOFTWARE LIFE-CYCLE MODELS1 掌握編碼-修補模型、瀑布

11、模型、快速原型開發(fā)模型、開源模型、敏捷過程模型、同步-穩(wěn)定模型、螺旋模型等這些模型的模型圖(如果有圖的話)以及優(yōu)缺點和適用場合,并能繪制。5-10%Code-and-Fix Model代碼-修復(fù)模型 1.without requirements or specifications or design2.may work well on short programming exercises較短的編程練習 (100 or 200 lines)3.the easiest way to develop software and by far目前 the worst wayWaterfall Mode

12、l1. with feedback loops2. documentation driven文檔驅(qū)動no phase is complete until the documentation for that phase has been completed;The waterfall model, depending on依賴于 specifications, can lead to導(dǎo)致 the products that do not meet the clients needs.Rapid Prototyping Model快速原型1. linear development2. rapid

13、3. meet the clients needOpen-Source Life-Cycle Modelpostdelivery maintenance life-cycle model Two informal非形式的 phasesCore group核心小組 Peripheral group外圍小組Open-source software is generally maintained by unpaid volunteers志愿者Users may submit defect reports缺陷報告, both failure reports and fault reportsAn in

14、itial working version is produced when using The rapid-prototyping model;The code-and-fix model; and The open-source life-cycle modelThen:Rapid-prototyping model:The initial version is discarded丟棄Code-and-fix model and open-source life-cycle model:The initial version becomes the target product目標產(chǎn)品Ag

15、ile Processes敏捷過程stories特性;pair programming成對編程;Extreme programming極限編程:XP is one of a number of new paradigms collectively referred to as統(tǒng)稱為 agile processes.A principle原則 of XP is to minimize最小化 the number of features.One way of achieving this is to use timeboxing時光盒技術(shù)Another common feature of agil

16、e processes is stand-up meetings站立會議Stand-up meetings and timeboxing techniques are instances實例 of two basic principles原則 that underlie應(yīng)用 all agile methods敏捷方法:ommunication溝通;satisfying the clients needs as quickly as possible盡可能快地1. Agile processes have had some successes with small-scale小型 softwar

17、e development 2. Agile processes are good when requirements are vague模糊不清 or changing Synchronize-and Stabilize Model同步-穩(wěn)定模型Microsofts life-cycle modelAt the end of the day synchronize同步 (test and debug調(diào)試)At the end of the build構(gòu)件 stabilize穩(wěn)定化 (freeze凍結(jié) the build)Spiral Model螺旋模型a rapid-prototyping

18、model with each phase preceded by之前帶有 risk analysis風險分析Strengths優(yōu)點risk-driven風險驅(qū)動Weaknesses缺點For large-scale大型 and internal內(nèi)部 software only Summary:第3章:軟件過程SOFTWARE PROCESS1掌握每個工作流(包括需求流、分析流、設(shè)計流、實現(xiàn)流、測試流)的目標 2%The Requirements WorkflowAim: to determine what the client needs,not what the client wantsT

19、he Analysis WorkflowAim: analyze分析 and refine提取 the requirementsPS:Why not do this during the requirements workflow?The artifacts of the requirements workflow be comprehensible能被理解 by the client and be expressed in a natural language用自然語言描述;All natural languages are imprecise不精確Two separate workflow

20、s are needed:the language of the client(natural language);complete enough for the designers(UML)The Design WorkflowAim: to refine細化 the analysis workflow until the material材料 is in a form that can be implemented by the programmers PS:Many nonfunctional requirements need to be finalized at this time,

21、 including choice of programming language,reuse issues,portability issues.The Implementation WorkflowAim: to implement the target目標 software product in the selected implementation languageThe Test WorkflowAim: to find defect(mistake過錯, fault差錯, failure故障)PS:The test workflow is the responsibility of

22、 Every developer and maintainer, and The quality assurance groupTraceability可追蹤性 of artifacts is an important requirement for successful testingThe analysis artifacts should be checked by means of a review評審:walkthrough走查;inspections審查kinds of running test cases測試用例:unit單元 testing;integration集成 test

23、ing;product產(chǎn)品 testing;acceptance驗收 testingThe COTS software is released for testing by prospective clients潛在客戶:alpha release (版)beta release (版): the correct release2掌握需求流的每個步驟(了解應(yīng)用領(lǐng)域、建立業(yè)務(wù)模型、找出限制條件),了解主要限制條件(包括最終期限、可靠性、成本),掌握以下觀點:開發(fā)者能夠給予客戶的應(yīng)該是客戶需要的而不是客戶想要的 1%Requirements Workflow Tasks:(1) gain an u

24、nderstanding of the application domain應(yīng)用領(lǐng)域:That is, the specific business environment in which the software product is to operate(2) build a business model業(yè)務(wù)模型:Use UML to describe the clients business processes(3) determine the clients constraints限制條件:deadline期限;portability可移植性;reliability可靠性;respon

25、se time響應(yīng)時間;cost成本:The client will rarely inform告知 the developer how much money is available,A bidding procedure招標程序 is used instead.Developer should do what the client needs,not what the client wants3掌握設(shè)計流的兩個步驟:結(jié)構(gòu)設(shè)計和詳細設(shè)計的設(shè)計內(nèi)容2%Classical Design傳統(tǒng)范型的設(shè)計:architectural design結(jié)構(gòu)設(shè)計decompose分解 the product

26、into modulesdetailed design詳細設(shè)計design each module:data structures數(shù)據(jù)結(jié)構(gòu);algorithms算法4掌握統(tǒng)一過程的四個階段以及每個階段的目標 1%The Phases of the Unified Process:inception phase開始階段 Aim: to determine whether the proposed software product is economically viable經(jīng)濟上可行elaboration phase細化階段 Aim: to refine細化 the initial requir

27、ementsconstruction phase構(gòu)建階段 Aim: to produce the first operational-quality version可工作版本 of the software producttransition phase轉(zhuǎn)換階段 Aim: to ensure that the clients requirements have indeed been met5. 掌握規(guī)格說明文檔中可能出現(xiàn)的問題(包括模糊、不完備和矛盾),掌握軟件項目管理計劃的組成部分(包括可交付的東西、里程碑和預(yù)算)1%Specification document規(guī)格說明文檔It const

28、itutes構(gòu)成 a contract合同;It must not have imprecise phrases like:optimal最優(yōu);98% complete;if 0=num=30, green light is lit被點亮; if 30num OLD1.2.3. write OLD to NEWTRAN OLD1.2.3. write OLD to NEWTRAN OLD1. write TRAN to NEW 2.3. errorThird Refinement第三次求精The third refinement is wrong.“Modify Jones” followed

29、 by “Delete Jones” is incorrectly handled.Solution:Level-1 lookahead一級前瞻Processing a TRAN only after the next TRAN has been analyzed分析.PS:Introduce level-1 lookahead, and draw up a 3*3 table.2掌握軟件度量的兩種分類(即產(chǎn)品度量和過程度量)以及度量時用到的具體指標(例如:代碼行、每千行代碼檢測出的錯誤數(shù)、平均故障間隔時間等等),掌握五種基本度量(即規(guī)模、成本、持續(xù)時間、工作量、質(zhì)量)1%Software M

30、etrics度量:Product metrics產(chǎn)品度量(size規(guī)模 of product;reliability可靠性 of product)Process metrics過程度量(efficiency效率 of fault detection during development)The Five Basic Metrics:(1) size規(guī)模(2) cost(3) duration持續(xù)時間(4) effort工作量(5) quality度量時的具體指標:lines of code (LOC)size; LOC per monthsize; defects錯誤數(shù) per 1000 LO

31、Cquality;number of faults detectedquality;person-monthseffort;monthsduration;3掌握CASE工具的概念以及分類(即高端與低端,工具與工作平臺與環(huán)境)1%Conception概念:computer-aided software engineering (CASE) tools 計算機輔助軟件工程工具Taxonomy分類 of CASE:UpperCASE tool: 高端CASE工具(1)help developer during the earlier phase:requirement, analysis, desi

32、gn;(2)front-end前端 toolLowerCASE tool: 低端CASE工具(1)help developer during the latter phase:implement, postdelivery maintenance;(2)back-end后端 tooltool工具:a product that assists in just one aspectworkbench工作平臺:a collection of tools that together support one or two activitiesenvironment環(huán)境:supports the comp

33、lete software process4掌握軟件版本的兩種分類(即修訂版和變種版)以及這兩種分類的區(qū)別 1%Software Versions:revisions修訂版 and variations變種版1. revision修訂版: a version to fix a fault in the artifact.Revision is written to replace its predecessor前任.We cannot throw away an incorrect version (the old version)2. variation變種版: is a version f

34、or a different operating systemhardware.Example: two variations of the printer driver打印機驅(qū)動 for supporting an ink-jet噴墨 printer and a laser激光 printerVariations are designed to coexist共存 in parallel平行.PS:name version technique:(1)multiple多個revision:sacknowledgeMessage/1;acknowledgeMessage/2(2) multipl

35、e variations:printerDriver(inkJet);printerDriver(laser)(3)multiple revisions of one variation:printerDriver(laser)/12;printerDriver(laser)/13;printerDriver(laser)/14第6章 :測試TESTING1掌握質(zhì)量的定義以及軟件質(zhì)量保證小組(即SQA小組)的責任 2%Software quality assurance group軟件質(zhì)量保證小組(SQA group)The role of SQA group:ensure the quali

36、ty of software process軟件過程,thereby從而 ensure the quality of software product2掌握走查時小組成員的構(gòu)成、走查清單的構(gòu)成、走查的兩個步驟、走查的兩種方式以及這兩種方式之間的區(qū)別 2%小組成員的構(gòu)成:A walkthrough team consists of from 4 to 6 members;走查清單的構(gòu)成:It includes representatives代表 of (1)The team responsible for負責 the current workflow and for the next workf

37、low(2)The SQA groupThe walkthrough team is chaired主持 by the SQA representative走查的兩個步驟:The walkthrough is preceded by preparation準備 lists of items:(1)items not understood;(2)items that appear to be incorrect走查的兩種方式Two types of conducting實施 a walkthrough:participant-driven參加者驅(qū)動:question-answer form;do

38、cument-driven文檔驅(qū)動:read-question-answer form;3掌握審查時小組成員的構(gòu)成、審查的五個步驟 2%審查小組成員構(gòu)成:An inspection team has four members:moderator主持者;members of the teams performing the current workflow and the next workflow;a member of the SQA group;Special roles are played by the moderator,reader,recorder.五個步驟An inspecti

39、on has five formal steps:overview概要;preparation準備;inspection審查;rework修訂;follow-up跟蹤4掌握走查與審查之間的區(qū)別 2%區(qū)別Comparison比較 of inspections and walkthroughs:walkthrough走查:Two-step, informal process (1)preparation準備(2)analysis分析inspection審查:Five-step, formal process (1)overview概要(2)preparation準備(2)inspection審查(

40、4)rework修訂(5)follow-up跟蹤PS:Strengths優(yōu)點 and Weaknesses缺點 of Reviews評審Strengths:Faults are detected earlierWeakness:may be less effective if the process is inadequate不充分5掌握需要測試的五個行為特性(即實用性、可靠性、健壯性、性能和正確性)的定義以及相關(guān)度量指標(如平均故障間隔時間、平均修復(fù)時間)1%correctness正確性:A product is correct if it satisfies its specificati

41、onsutility實用性:The extent程度 to which the product meets the users needs. Eg:ease of use;useful functions;cost effectivenessreliability可靠性:A measure of the frequency頻率 and criticality嚴重性 of failure故障Eg:mean平均 time between failures;mean time to repairrobustness健壯性:A function函數(shù) of The range of operating

42、conditions; The possibility of unacceptable results with valid有效 input; The effect of invalid inputperformance性能:The extent to which space and time constraints限制 are metEg:real-time software is characterized by hard real-time constraints;If data are lost because the system is too slow, there is no w

43、ay to recover those data;6掌握測試的兩種分類 1%There are 2 basic types of testing:Execution-based基于執(zhí)行的 testing執(zhí)行測試:executing執(zhí)行code;running test cases運行測試用例Non-execution-based基于非執(zhí)行的 testing非執(zhí)行測試:review評審:document review; code review第7章:從模塊到對象FROM MODULES TO OBJECTS1掌握以下概念的定義:模塊、模塊內(nèi)聚、模塊耦合 1%Module模塊:A lexically

溫馨提示

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

評論

0/150

提交評論