2014軟件工程各章節(jié)重要知識(shí)點(diǎn)按考試大綱總結(jié)

1、2014軟件工程各章節(jié)重點(diǎn)知識(shí)點(diǎn)（按考試大綱總結(jié)）第1章 ：軟件工程的范疇THE SCOPE OF SOFTWARE ENGINEERING1掌握軟件工程、軟件危機(jī)、生命周期的概念 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實(shí)際步驟 performed執(zhí)行 on a specific具體 product.2掌握維護(hù)的3種分類并能夠結(jié)合具體例子進(jìn)行判斷 1%Postdeli

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

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

5、 testing or documentation phase.This testing is the responsibility職責(zé) 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軟件項(xiàng)目管理計(jì)劃(SPMP);“What the product is supposed期望 to do”3. Design phaseArchitectural design結(jié)構(gòu)設(shè)計(jì), followed by;Detailed design詳細(xì)設(shè)計(jì);“How the product do

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

9、is is a temporal時(shí)間性 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 掌握編碼-修補(bǔ)模型、瀑布

11、模型、快速原型開發(fā)模型、開源模型、敏捷過程模型、同步-穩(wěn)定模型、螺旋模型等這些模型的模型圖（如果有圖的話）以及優(yōu)缺點(diǎn)和適用場(chǎng)合，并能繪制。5-10%Code-and-Fix Model代碼-修復(fù)模型 1.without requirements or specifications or design2.may work well on short programming exercises較短的編程練習(xí) (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ū)動(dòng)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缺陷報(bào)告, 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目標(biāo)產(chǎn)品Ag

15、ile Processes敏捷過程stories特性;pair programming成對(duì)編程;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í)光盒技術(shù)Another common feature of agil

16、e processes is stand-up meetings站立會(huì)議Stand-up meetings and timeboxing techniques are instances實(shí)例 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風(fēng)險(xiǎn)分析Strengths優(yōu)點(diǎn)risk-driven風(fēng)險(xiǎn)驅(qū)動(dòng)Weaknesses缺點(diǎn)For large-scale大型 and internal內(nèi)部 software only Summary：第3章：軟件過程SOFTWARE PROCESS1掌握每個(gè)工作流（包括需求流、分析流、設(shè)計(jì)流、實(shí)現(xiàn)流、測(cè)試流）的目標(biāo) 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細(xì)化 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目標(biāo) software product in the selected implementation languageThe Test WorkflowAim: to find defect（mistake過錯(cuò), fault差錯(cuò), 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評(píng)審:walkthrough走查;inspections審查kinds of running test cases測(cè)試用例:unit單元 testing;integration集成 test

23、ing;product產(chǎn)品 testing;acceptance驗(yàn)收 testingThe COTS software is released for testing by prospective clients潛在客戶:alpha release (版)beta release (版): the correct release2掌握需求流的每個(gè)步驟（了解應(yīng)用領(lǐng)域、建立業(yè)務(wù)模型、找出限制條件），了解主要限制條件（包括最終期限、可靠性、成本），掌握以下觀點(diǎn)：開發(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)時(shí)間;cost成本:The client will rarely inform告知 the developer how much money is available,A bidding procedure招標(biāo)程序 is used instead.Developer should do what the client needs,not what the client wants3掌握設(shè)計(jì)流的兩個(gè)步驟：結(jié)構(gòu)設(shè)計(jì)和詳細(xì)設(shè)計(jì)的設(shè)計(jì)內(nèi)容2%Classical Design傳統(tǒng)范型的設(shè)計(jì):architectural design結(jié)構(gòu)設(shè)計(jì)decompose分解 the product

26、into modulesdetailed design詳細(xì)設(shè)計(jì)design each module:data structures數(shù)據(jù)結(jié)構(gòu);algorithms算法4掌握統(tǒng)一過程的四個(gè)階段以及每個(gè)階段的目標(biāo) 1%The Phases of the Unified Process:inception phase開始階段 Aim: to determine whether the proposed software product is economically viable經(jīng)濟(jì)上可行elaboration phase細(xì)化階段 Aim: to refine細(xì)化 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)的問題（包括模糊、不完備和矛盾），掌握軟件項(xiàng)目管理計(jì)劃的組成部分（包括可交付的東西、里程碑和預(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被點(diǎn)亮; 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一級(jí)前瞻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í)用到的具體指標(biāo)（例如：代碼行、每千行代碼檢測(cè)出的錯(cuò)誤數(shù)、平均故障間隔時(shí)間等等），掌握五種基本度量（即規(guī)模、成本、持續(xù)時(shí)間、工作量、質(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ù)時(shí)間(4) effort工作量(5) quality度量時(shí)的具體指標(biāo):lines of code (LOC)size; LOC per monthsize; defects錯(cuò)誤數(shù) per 1000 LO

31、Cquality；number of faults detectedquality；person-monthseffort；monthsduration；3掌握CASE工具的概念以及分類（即高端與低端，工具與工作平臺(tái)與環(huán)境）1%Conception概念：computer-aided software engineering (CASE) tools 計(jì)算機(jī)輔助軟件工程工具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工作平臺(tái):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打印機(jī)驅(qū)動(dòng) for supporting an ink-jet噴墨 printer and a laser激光 printerVariations are designed to coexist共存 in parallel平行.PS:name version technique:(1)multiple多個(gè)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章 ：測(cè)試TESTING1掌握質(zhì)量的定義以及軟件質(zhì)量保證小組（即SQA小組）的責(zé)任 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掌握走查時(shí)小組成員的構(gòu)成、走查清單的構(gòu)成、走查的兩個(gè)步驟、走查的兩種方式以及這兩種方式之間的區(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負(fù)責(zé) the current workflow and for the next workf

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

38、cument-driven文檔驅(qū)動(dòng):read-question-answer form;3掌握審查時(shí)小組成員的構(gòu)成、審查的五個(gè)步驟 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.五個(gè)步驟An inspecti

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

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

41、onsutility實(shí)用性: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嚴(yán)重性 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掌握測(cè)試的兩種分類 1%There are 2 basic types of testing:Execution-based基于執(zhí)行的 testing執(zhí)行測(cè)試:executing執(zhí)行code;running test cases運(yùn)行測(cè)試用例Non-execution-based基于非執(zhí)行的 testing非執(zhí)行測(cè)試:review評(píng)審:document review; code review第7章：從模塊到對(duì)象FROM MODULES TO OBJECTS1掌握以下概念的定義：模塊、模塊內(nèi)聚、模塊耦合 1%Module模塊:A lexically