第一篇：軟件工程復(fù)習(xí)考點(diǎn)小結(jié) 1（小編推薦）

《軟件工程》考點(diǎn)小結(jié)

1,軟件工程的定義及軟件工程的研究?jī)?nèi)容？

軟件工程是研究軟件開發(fā)和軟件管理的一門工程學(xué)科。

軟件工程研究的內(nèi)容包括軟件開發(fā)方法、軟件開發(fā)模型、軟件支持過程和軟件管理過程。其中軟件開發(fā)方法的內(nèi)容又涵蓋市場(chǎng)調(diào)研、正式立項(xiàng)、需求分析、項(xiàng)目策劃、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編程、測(cè)試、試運(yùn)行、產(chǎn)品發(fā)布、用戶培訓(xùn)、產(chǎn)品復(fù)制、銷售、實(shí)施、系統(tǒng)維護(hù)、版本升級(jí)。

常用的軟件開發(fā)模型有瀑布模型、迭代模型、增量模型和原型模型。

軟件支持過程由所支持的CASE工具組成，常用的CASE工具有Power Designer和Rational Rose。

軟件管理過程主要有CMMI、ISO9000、微軟企業(yè)文化和敏捷文化現(xiàn)象。

2,軟件工程五個(gè)面向?qū)嵤├碚摚?/p>

“五個(gè)面向理論”是指“面向流程分析、面向數(shù)據(jù)設(shè)計(jì)、面向?qū)ο髮?shí)現(xiàn)、面向功能測(cè)試、面向過程管理”，它是在綜合“四種開發(fā)方法”各自的優(yōu)點(diǎn)之后提出的軟件工程實(shí)施理論，是對(duì)前者的繼承與發(fā)展。總之，上述提法既精彩又實(shí)用。

3什么是“軟件生命周期模型”，常用的軟件生命周期模型有哪些？ 在整個(gè)軟件生命周期中，軟件開發(fā)過程應(yīng)該遵循的開發(fā)路線圖，或者說，軟件生命周期模型是軟件開發(fā)全部過程，活動(dòng)和任務(wù)的結(jié)構(gòu)框架。

1.瀑布模型 瀑布模型是將軟件生存周期各個(gè)活動(dòng)規(guī)定為自上向下，按照線性順序連接的若干階段的模型。

2.增量模型 增量模型是一種遵循遞增方式來進(jìn)行軟件開發(fā)的模型。

3.原型模型

4.迭代模型 所謂迭代是指活動(dòng)的多次重復(fù)。5.螺旋模型 螺旋模型是一種風(fēng)險(xiǎn)驅(qū)動(dòng)的模型。6.噴泉模型 噴泉模型是一種以用戶需求為動(dòng)力，以對(duì)象作為驅(qū)動(dòng)的模型，適合于面向?qū)ο?的開發(fā)方法。

7.xp模型 即指極限編程模型

4,簡(jiǎn)述瀑布模型與迭代模型之間的關(guān)系？

在宏觀上，迭代模型是動(dòng)態(tài)模型，瀑布模型是靜態(tài)模型。一方面，迭代模型需要經(jīng)過多次反復(fù)迭代，才能形成最終產(chǎn)品。另一方面，迭代模型的每一次迭代，實(shí)質(zhì)上都是執(zhí)行一次瀑布模型，都要經(jīng)歷初始、精化、構(gòu)造、移交4個(gè)階段，走完瀑布模型的全過程。

在微觀上，迭代模型與瀑布模型都是動(dòng)態(tài)模型。迭代模型與瀑布模型在每一個(gè)開發(fā)階段（初始、精化、構(gòu)造、移交）的內(nèi)部，都有一個(gè)小小的迭代過程，只有經(jīng)歷這一迭代過程，該階段的開發(fā)工作才能做細(xì)做好。

瀑布模型與迭代模型之間的這種微妙關(guān)系，如下圖所示。

圖

瀑布模型與迭代模型之間的關(guān)系

由圖可見，在迭代和瀑布模型中，你中有我、我中有你。

瀑布模型與迭代模型之間的關(guān)系，反映了人們對(duì)客觀事物的認(rèn)識(shí)論：要認(rèn)識(shí)與掌握某一客觀事物，必須經(jīng)歷由宏觀到微觀的多次反復(fù)的過程。只有從宏觀上反復(fù)迭代幾次，才能看清全貌，掌握事物的宏觀發(fā)展規(guī)律。只有從微觀上反復(fù)迭代幾次，才能吃透每個(gè)細(xì)節(jié)，掌握事物的微觀發(fā)展規(guī)律。

5,何謂軟件的“多態(tài)性”？

同一操作作用于不同的對(duì)象，可以有不同的解釋，產(chǎn)生不同的執(zhí)行結(jié)果。這就是多態(tài)性。6,“數(shù)據(jù)字典”的定義？

數(shù)據(jù)字典是關(guān)于數(shù)據(jù)的信息的集合，也就是對(duì)數(shù)據(jù)流圖中包含的所有元素的定義的集合。

7,何謂軟件的“耦合性”？

耦合性也叫塊間聯(lián)系。指軟件系統(tǒng)結(jié)構(gòu)中個(gè)模塊間相互聯(lián)系緊密程度的一種度量。模塊之間聯(lián)系越緊密，其耦合性就越強(qiáng)，模塊的獨(dú)立性則越差，模塊間耦合的高低取決于模塊間接口的復(fù)雜性，調(diào)用的方式以及傳遞的信息。

8,數(shù)據(jù)庫物理設(shè)計(jì)的定義？

數(shù)據(jù)庫物理設(shè)計(jì)：設(shè)計(jì)數(shù)據(jù)庫的物理結(jié)構(gòu)，根據(jù)數(shù)據(jù)庫的邏輯結(jié)構(gòu)來選定RDBMS(如Oracle、Sybase等)，并設(shè)計(jì)和實(shí)施數(shù)據(jù)庫的存儲(chǔ)結(jié)構(gòu)、存取方式等。

9,需求分析的目的是什么，需求分析的難點(diǎn)在哪里？

軟件需求分析，其目的是用于說明軟件產(chǎn)品或軟件項(xiàng)目需要滿足的條件和限制。在軟件工程項(xiàng)目中首先要獲取用戶的需求，通過對(duì)軟件需要的提取、分析、文檔化及驗(yàn)證，為進(jìn)一步的設(shè)計(jì)和實(shí)現(xiàn)提供依據(jù)。

需求分析的難點(diǎn)是：在系統(tǒng)的功能、性能和接口方面，開發(fā)者與客戶達(dá)成完全一致的需求，讓客戶最終簽字確認(rèn)，并保證在項(xiàng)目驗(yàn)收前，需求相對(duì)穩(wěn)定不變。萬一需求有一點(diǎn)變化，雙方必須履行“需求變更管理程序”，而變更管理程序在簽訂合同時(shí)已經(jīng)做了規(guī)定。要知道，合同是具有法律效力的。

10,業(yè)務(wù)模型、功能模型、數(shù)據(jù)模型各是什么含義？

功能模型是描述系統(tǒng)能做什么，即對(duì)系統(tǒng)的功能、性能、接口和界面進(jìn)行定義。

業(yè)務(wù)模型是描述系統(tǒng)在何時(shí)、何地、由何角色、按什么業(yè)務(wù)規(guī)則去做，以及做的步驟或流程，即對(duì)系統(tǒng)的操作流程進(jìn)行定義。

數(shù)據(jù)模型是描述系統(tǒng)工作前的數(shù)據(jù)來自何處，工作中的數(shù)據(jù)存到什么地方，工作后的數(shù)據(jù)放到何處，以及這些數(shù)據(jù)之間的關(guān)聯(lián)，即對(duì)系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)進(jìn)行定義。

11,為什么說需求分析是面向流程的？

系統(tǒng)的功能、性能、接口、界面都是在流程中動(dòng)態(tài)實(shí)時(shí)的反映出來。在所有的流程（物流、人流、資金流、信息流、單據(jù)流、報(bào)表流、數(shù)據(jù)流）中，數(shù)據(jù)流最重要，也最具有代表性。因?yàn)樵谟?jì)算機(jī)網(wǎng)絡(luò)系統(tǒng)內(nèi)，一切流程都表現(xiàn)為數(shù)據(jù)流，或者說是數(shù)據(jù)流在不同方向的投影。而流程是動(dòng)態(tài)的、實(shí)時(shí)的。所以說，需求分析是面向流程的。

12,簡(jiǎn)述實(shí)用軟件測(cè)試的流程？ 實(shí)用軟件測(cè)試流程可以分5步展開：

（1）理解、驗(yàn)證和分解需求。

（2）編寫測(cè)試計(jì)劃（包括測(cè)試設(shè)計(jì)）。（3）測(cè)試執(zhí)行。（4）專項(xiàng)測(cè)試。（5）編寫測(cè)試報(bào)告。

13,軟件測(cè)試的目的和目標(biāo)是什么？

簡(jiǎn)單明了地說，軟件測(cè)試的目的就是發(fā)現(xiàn)軟件缺陷。但同時(shí)還要時(shí)刻牢記在心的是：軟件測(cè)試的目標(biāo)是盡可能早地發(fā)現(xiàn)軟件缺陷，并確保其得以修復(fù)。這里的缺陷，包括Bug和不符合項(xiàng)。

14,軟件需求分析過程中，需求分析的輸入是《合同》、《立項(xiàng)建議書》，以及對(duì)用戶現(xiàn)場(chǎng)的調(diào)研，分析和確認(rèn)，輸出是《用戶需求報(bào)告》或《需求規(guī)格說明書》。

15,軟件產(chǎn)品的來源是立項(xiàng)和簽合同。

16,信息標(biāo)準(zhǔn)化，就是信息的代碼化和規(guī)范化。

17,面向數(shù)據(jù)設(shè)計(jì)以E-R圖為基礎(chǔ)，按照一定的規(guī)則將CDM轉(zhuǎn)換成能被某種

數(shù)據(jù)庫管理系統(tǒng)接受的PDM。

18,按照“五個(gè)面向”的實(shí)施理論，軟件設(shè)計(jì)的主要方法是面向數(shù)據(jù)設(shè)計(jì)，軟件實(shí)現(xiàn)的主要方法面向?qū)ο髮?shí)現(xiàn)。

19, 軟件評(píng)估既是軟件策劃的核心，又是軟件策劃的重點(diǎn)和難點(diǎn)。20,軟件設(shè)計(jì)包括軟件架構(gòu)設(shè)計(jì)和軟件詳細(xì)設(shè)計(jì)，其中三種常用的詳細(xì)設(shè)計(jì)方法

21, 軟件設(shè)計(jì)包括軟件架構(gòu)設(shè)計(jì)和軟件詳細(xì)設(shè)計(jì)，其中三種常用的詳細(xì)設(shè)計(jì)方法是是面向過程、面向數(shù)據(jù)、面向?qū)ο蟆?/p>

22,SW-CMM的5個(gè)成熟度等級(jí)分別為初始級(jí)、可重復(fù)級(jí)、已定義級(jí)、已管理級(jí)、優(yōu)化級(jí)。

23,UML規(guī)定采用類圖和對(duì)象圖來表述數(shù)據(jù)模型。24,軟件設(shè)計(jì)可以分為概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)。25,UML規(guī)定采用用例圖來描述功能模型。

26,軟件一般存在5種風(fēng)險(xiǎn)，分別為：政策風(fēng)險(xiǎn)、技術(shù)風(fēng)險(xiǎn)、技能風(fēng)險(xiǎn)、資源風(fēng)險(xiǎn)和其他風(fēng)險(xiǎn)。

27,UML中有3種基本構(gòu)造塊：事務(wù)、關(guān)系和圖，它們是UML建模中的積木元素或積木合體。

28, 數(shù)據(jù)庫設(shè)計(jì)包括數(shù)據(jù)庫需求分析、數(shù)據(jù)庫概念設(shè)計(jì)、數(shù)據(jù)庫物理設(shè)計(jì)三個(gè)階段。

第二篇：軟件工程考點(diǎn)總結(jié)

第一章

1.軟件是程序和所使程序正確運(yùn)行所需的相關(guān)文檔和配置信息.軟件工程是一門工程學(xué)科，涉及軟件生產(chǎn)的各個(gè)方面.軟件過程是指制作軟件產(chǎn)品的一組活動(dòng)及其結(jié)果。

2.軟件過程的4項(xiàng)基本活動(dòng)有:軟件描述：客戶和工程師定義所要生產(chǎn)的軟件以及對(duì)其操作的一些約束軟件開發(fā)軟件得以設(shè)計(jì)和編程實(shí)現(xiàn)軟件有效性驗(yàn)證軟件經(jīng)過檢查以保證它就是客戶所需要的軟件進(jìn)化軟件隨不同的客戶和變化的市場(chǎng)需求而修改.3.軟件工程人員的工作不僅僅是技術(shù)的應(yīng)用，還要承擔(dān)很多責(zé)任.保密：工程人員必須嚴(yán)格保守雇主或客戶的機(jī)密，而不管是否簽署了保密協(xié)議.工作能力 工程人員應(yīng)實(shí)事求是地表述自己的工作能力，不應(yīng)有意接受超出了自己能力的工作.知識(shí)產(chǎn)權(quán)工程人員應(yīng)當(dāng)知曉控制專利權(quán)、著作權(quán)等知識(shí)產(chǎn)權(quán)使用的地方法律，必須謹(jǐn)慎行事，確保雇主和客戶的知識(shí)產(chǎn)權(quán)受到保護(hù).計(jì)算機(jī)濫用 軟件工程人員不應(yīng)該用自己的技能濫用他人的計(jì)算機(jī)，濫用計(jì)算機(jī)有時(shí)對(duì)他人影響不大（如在雇主的計(jì)算機(jī)上玩游戲），但有時(shí)后果非常嚴(yán)重（傳播病毒）.第二章

1軟件工程模型瀑布模型軟件描述和開發(fā)，分成獨(dú)立和不同的階段.增量式開發(fā)描述、開發(fā)和有效性驗(yàn)證交錯(cuò)進(jìn)行.面向復(fù)用的軟件工程基于已存在的很多可復(fù)用的組件.2.瀑布模型：1需求分析和定義，通過咨詢系統(tǒng)用戶建立系統(tǒng)的服務(wù)、約束和目標(biāo)。2系統(tǒng)和軟件設(shè)計(jì)系統(tǒng)設(shè)計(jì)過程通過建立系統(tǒng)的總體體系結(jié)構(gòu)將需求分為硬件需求和軟件需求。3實(shí)現(xiàn)和單元測(cè)試將軟件設(shè)計(jì)實(shí)現(xiàn)為一組程序或程序單元，單元測(cè)試是檢驗(yàn)每個(gè)單元是否符合其描述。4集成和系統(tǒng)測(cè)試集成單個(gè)的程序單元或一組程序，并對(duì)系統(tǒng)整體進(jìn)行測(cè)試以確保其滿足了軟件需求。5運(yùn)行和維護(hù)

3瀑布模型的問題1將項(xiàng)目分成不同階段，難以應(yīng)付不斷變化的客戶需求.2當(dāng)需求十分明確，軟件開發(fā)中只做有限修改時(shí)才適合使用該模型.3很少有業(yè)務(wù)系統(tǒng)有穩(wěn)定的需求。瀑布模型主要是用于大型系統(tǒng)工程項(xiàng)目，且軟件項(xiàng)目是大型工程項(xiàng)目的一部分時(shí)尤為適用.4增量式開發(fā)優(yōu)點(diǎn)：

1、降低了適應(yīng)用戶需求變更的成本

2、容易得到用戶及時(shí)的反饋

3、為及時(shí)交付用于的系統(tǒng)提供了可能問題1過程不可見;2系統(tǒng)結(jié)構(gòu)通常較差;3需要專業(yè)技能(如快速原型語言等).5過程活動(dòng)包括：軟件描述、軟件設(shè)計(jì)和實(shí)現(xiàn)、軟件有效性驗(yàn)證及軟件進(jìn)化.6軟件描述（需求工程）軟件描述或需求工程主要是理解并定義系統(tǒng)需要哪些服務(wù)以及找出開發(fā)和運(yùn)行期間受到哪些約束.可行性研究：指明現(xiàn)有的軟件硬件及能否實(shí)現(xiàn)用戶對(duì)新系統(tǒng)的要求需求導(dǎo)出和分析：通過對(duì)現(xiàn)有系統(tǒng)分析、與潛在用戶和購(gòu)買者討論、進(jìn)行任務(wù)分析等導(dǎo)出系統(tǒng)需求的過程需求描述：把在分析活動(dòng)中收集的信息以文檔的形式確定下來。需求有效性驗(yàn)證：檢查需求的現(xiàn)實(shí)性、一致性和完備性。

7軟件設(shè)計(jì)和實(shí)現(xiàn)把系統(tǒng)描述轉(zhuǎn)化為一個(gè)可運(yùn)行的系統(tǒng)的過程。軟件設(shè)計(jì)，實(shí)現(xiàn)軟件的結(jié)構(gòu)、系統(tǒng)的數(shù)據(jù)等描述。實(shí)現(xiàn)，把軟件結(jié)構(gòu)轉(zhuǎn)化為可執(zhí)行的程序。體系結(jié)構(gòu)設(shè)計(jì)識(shí)別系統(tǒng)總體結(jié)構(gòu)、基本組件、它們之間的關(guān)系以及它們是怎樣分布。接口設(shè)計(jì)定義系統(tǒng)結(jié)構(gòu)的借口組件設(shè)計(jì)針對(duì)每個(gè)系統(tǒng)組件設(shè)計(jì)它的運(yùn)行方式數(shù)據(jù)庫設(shè)計(jì)設(shè)計(jì)系統(tǒng)數(shù)據(jù)結(jié)構(gòu)，以及如何在數(shù)據(jù)庫中表示這些數(shù)據(jù)結(jié)構(gòu)

8軟件有效性驗(yàn)證也稱檢查和有效性驗(yàn)證，是為了表明系統(tǒng)符合其描述，滿足了客戶的需求.包括檢查和審查過程，還有系統(tǒng)測(cè)試.組件或單元測(cè)試由開發(fā)系統(tǒng)的人員對(duì)組成系統(tǒng)的組件進(jìn)行測(cè)試系統(tǒng)測(cè)試集成組件形成完整的系統(tǒng)。并測(cè)試是否滿足需求。接收測(cè)試系統(tǒng)在接受并運(yùn)行之前的最后階段測(cè)試

9軟件進(jìn)化軟件本質(zhì)是靈活的，可以改變的.由于業(yè)務(wù)環(huán)境的不斷變化，客戶需求也隨之發(fā)生變化，該軟件支持的業(yè)務(wù)也必須不斷更新和修改.10.Rational統(tǒng)一過程來自于UML上的工作和相關(guān)的軟件開發(fā)過程.開端建立一個(gè)業(yè)務(wù)案例細(xì)化增進(jìn)對(duì)問題域的理解，建立系統(tǒng)的體系框架，給出項(xiàng)目計(jì)劃、風(fēng)險(xiǎn)構(gòu)造系統(tǒng)設(shè)計(jì)、編程和測(cè)試轉(zhuǎn)換在其操作環(huán)境部署這一系統(tǒng).過程工作流：業(yè)務(wù)建模；需求；分析和設(shè)計(jì)；實(shí)現(xiàn)；測(cè)試；部署；支持工作流：配置和變更管理；項(xiàng)目管理；環(huán)境RUP 好的實(shí)踐：反復(fù)地開發(fā)軟件；對(duì)管理需求；使用基于組件的體系結(jié)構(gòu)；可視化模型軟件；驗(yàn)證軟件質(zhì)量；控制對(duì)軟件的變更

第三章

1.XP和敏捷方法的原則1增量式開發(fā)是通過系統(tǒng)的小的頻繁開發(fā)的版本來支持的；2客戶的參與是通過全時(shí)雇傭到開發(fā)團(tuán)隊(duì)的方式；3人（而不是過程）是通過結(jié)對(duì)編程、集體對(duì)系統(tǒng)代碼的所有權(quán)、可以忍受的開發(fā)過程而無需超額的工作小時(shí)來運(yùn)作的；4變更是通過經(jīng)常性的系統(tǒng)版本來支持的；5通過持續(xù)的再分解來維護(hù)系統(tǒng)的簡(jiǎn)潔性。

2問題：1很難將興趣保持在參與到開發(fā)的客戶身上。2團(tuán)隊(duì)成員個(gè)人可能從性格上不太適應(yīng)激烈的投入，這是敏捷方法的典型特征。3對(duì)變更做出優(yōu)先級(jí)排序可能是極困難的，尤其是對(duì)那些有很多參與者的系統(tǒng)。4維護(hù)簡(jiǎn)潔性需要額外的工作。5許多機(jī)構(gòu)很難向另一種工作模型轉(zhuǎn)換。6隨著其他迭代方法的發(fā)展，合同可能也是極限方法的一個(gè)問題。優(yōu)點(diǎn)1極限編程將增量式開發(fā)推向極致。2極限編程將軟件進(jìn)行再分解（refactoring），使得當(dāng)新情節(jié)實(shí)現(xiàn)的時(shí)候軟件總是容易理解和改變的。3.在創(chuàng)建程序特征之前開發(fā)自動(dòng)測(cè)試。

3結(jié)對(duì)編程優(yōu)點(diǎn)：1它支持共同擁有軟件和共同對(duì)系統(tǒng)負(fù)責(zé)2它擔(dān)當(dāng)了非正式的復(fù)查過程3有助于支持重構(gòu)

第四章

1需求工程過程包括可行性研究、需求導(dǎo)出和分析、需求描述、需求有效性驗(yàn)證及需求管理。2功能需求對(duì)系統(tǒng)應(yīng)該提供的服務(wù)、如何對(duì)輸入做出反應(yīng)以及系統(tǒng)在特定條件下的行為的描述。非功能需求對(duì)系統(tǒng)提供的服務(wù)或功能給出的約束。時(shí)間約束、開發(fā)過程的約束、標(biāo)準(zhǔn)等。3功能需求描述系統(tǒng)所預(yù)期提供的功能或服務(wù)。取決于開發(fā)的軟件類型、軟件未來的用戶以及開發(fā)的系統(tǒng)類型。理論上，系統(tǒng)的功能需求應(yīng)該既全面又具有一致性。全面用戶所需的所有服務(wù)都應(yīng)該給出描述；一致性在對(duì)系統(tǒng)功能需求進(jìn)行描述時(shí)，不能前后矛盾。在實(shí)際過程中，對(duì)大型而又復(fù)雜的系統(tǒng)而言，要做到需求描述既全面又一致幾乎是不可能的。

4非功能需求它們定義系統(tǒng)的屬性和約束。非功能性需求比功能性需求更關(guān)鍵。產(chǎn)品需求這些需求定義或約束軟件的行為。機(jī)構(gòu)需求很廣泛的系統(tǒng)需求，起源于客戶所在的機(jī)構(gòu)和開發(fā)者所在的機(jī)構(gòu)中的政策和規(guī)定。外部需求包括所有來自于系統(tǒng)外部因素和開發(fā)過程的需求。非功能性需求可能是很難精確描述的，并且不精確的需求可能也難以得到檢驗(yàn)。系統(tǒng)目標(biāo)用戶的一般的要求，比如系統(tǒng)的易用性。可檢驗(yàn)的非功能需求應(yīng)用某些度量進(jìn)行描述，它們可以客觀的得到驗(yàn)證。

5需求導(dǎo)出和分析（4個(gè)活動(dòng)）：1需求發(fā)現(xiàn)這是一個(gè)與系統(tǒng)的信息持有者交流從而收集他們的需求的過程。來自信息持有者和文檔的領(lǐng)域需求是在這個(gè)活動(dòng)中得以發(fā)現(xiàn)的。2需求分類與組織所收集的需求是無序的，需要對(duì)其重新組織和整理，將其分為相關(guān)的幾個(gè)組。3需求優(yōu)先排序和協(xié)商對(duì)需求進(jìn)行優(yōu)先權(quán)排序，并通過協(xié)商發(fā)現(xiàn)且解決這些沖突。4需求描述記錄需求并將它作為螺旋下一個(gè)循環(huán)的輸入，產(chǎn)生形式化和非形式化的需求文檔。系統(tǒng)需求導(dǎo)出和分析是困難的：1信息持有者表述泛泛2需求工程師沒有領(lǐng)域知識(shí)3不同的信息持有者需求不同4政治上的因素影響系統(tǒng)需求5經(jīng)濟(jì)和業(yè)務(wù)環(huán)境是動(dòng)態(tài)的6需求發(fā)現(xiàn)是一個(gè)收集準(zhǔn)備建立的系統(tǒng)和正在使用的系統(tǒng)的信息，并從這些信息當(dāng)中提取用戶和系統(tǒng)需求的過程。信息源包括已有文件、系統(tǒng)信息持有者以及類似系統(tǒng)的相關(guān)內(nèi)容。7腳本（場(chǎng)景）是對(duì)交互實(shí)例片段的描述。一個(gè)場(chǎng)景可能包擴(kuò)以下內(nèi)容：1在場(chǎng)景的開始部分有一個(gè)系統(tǒng)狀態(tài)描述；2一個(gè)關(guān)于標(biāo)準(zhǔn)事件流的描述；3一個(gè)關(guān)于哪兒會(huì)出錯(cuò)以及如何處

理錯(cuò)誤的描述；4有關(guān)其他可能在同一時(shí)間進(jìn)行的活動(dòng)的信息；5在場(chǎng)景完成后系統(tǒng)狀態(tài)的描述。

第五章

活動(dòng)圖，表示一個(gè)過程或數(shù)據(jù)處理中所涉及的活動(dòng)用例圖，表示一個(gè)系統(tǒng)和它所處的環(huán)境之間的交互。時(shí)序圖，表示參與者系統(tǒng)之間以及系統(tǒng)各部分之間的交互類圖，表示系統(tǒng)中對(duì)象類以及這些類之間的聯(lián)系狀態(tài)圖，表示系統(tǒng)是如何響應(yīng)內(nèi)外部事件的。

第六章

1明確設(shè)計(jì)和文檔化軟件體系結(jié)構(gòu)好處：1信息持有者之間的溝通體系結(jié)構(gòu)可以作為不同的項(xiàng)目相關(guān)人員之間討論的焦點(diǎn)2系統(tǒng)分析系統(tǒng)分析對(duì)體系結(jié)構(gòu)的設(shè)計(jì)決策，對(duì)系統(tǒng)能否滿足非功能需求具有很大的影響3大規(guī)模復(fù)用體系結(jié)構(gòu)能在相似需求的系統(tǒng)之間互用，以支持大規(guī)模的軟件復(fù)用。

2分層體系結(jié)構(gòu)分層模型用來把系統(tǒng)組織成一系列的層次，每一層提供一組服務(wù)。

3容器體系結(jié)構(gòu)系統(tǒng)所有數(shù)據(jù)在一個(gè)中央容器中管理，該容器可被所有系統(tǒng)組件訪問組件通過容器交互。優(yōu)點(diǎn)它是共享大量數(shù)據(jù)的一個(gè)高效方法；子系統(tǒng)不必關(guān)心數(shù)據(jù)是如何集中進(jìn)行的這些活動(dòng)；共享模型能通過容器模式而看得見。缺點(diǎn)子系統(tǒng)一定要與容器數(shù)據(jù)模型一致，不可避免地，每個(gè)專用的工具之間要做出妥協(xié)；數(shù)據(jù)進(jìn)化變得很困難和昂貴；容器模型迫使所有的子系統(tǒng)使用相同的策略；很難將容器有效的分配到多臺(tái)機(jī)器上。4客戶機(jī)/服務(wù)器體系結(jié):優(yōu)點(diǎn)數(shù)據(jù)的分布式最直接的;可以更有效地使用網(wǎng)絡(luò)系統(tǒng)，從而降低了對(duì)硬件的要求；很容易就添加一臺(tái)新的服務(wù)器或更新現(xiàn)有的服務(wù)器。缺點(diǎn)沒有共享數(shù)據(jù)模型，子系統(tǒng)以不同的方式組織它們的數(shù)據(jù)。數(shù)據(jù)交換效率就可能很低；每個(gè)服務(wù)器上出現(xiàn)冗余數(shù)據(jù)管理；沒有中央寄存器的名字和服務(wù)，這可能很難找出哪個(gè)服務(wù)器和哪些服務(wù)可用。5管道和過濾體系結(jié)優(yōu)點(diǎn)：易于理解并支持變換的復(fù)用。缺點(diǎn)：通信變換間所傳輸?shù)臄?shù)據(jù)格式必須協(xié)商好。

第七章

1復(fù)用 1抽象層:不直接復(fù)用，運(yùn)用軟件設(shè)計(jì)中的成功抽象。2對(duì)象層：直接復(fù)用庫中對(duì)象，代替自己編寫代碼3組件層：通常需要添加自己的代碼對(duì)組件進(jìn)行調(diào)成和擴(kuò)展 4系統(tǒng)層：復(fù)用整個(gè)系統(tǒng)

2配置管理管理變更中軟件系統(tǒng)的一般過程1版本管理對(duì)軟件不同版本的追蹤提供支持2系統(tǒng)集成提供支持幫助開發(fā)人員定義在創(chuàng)建每個(gè)系統(tǒng)版本時(shí)所用的組件版本 3問題追蹤提供支持允許用戶報(bào)告缺陷及其他問題，并允許開發(fā)人員誰在修復(fù)這些問題，以及何時(shí)完成修復(fù)。

第八章

1檢驗(yàn): “我們是否在正確地構(gòu)造一個(gè)產(chǎn)品”。軟件應(yīng)該符合設(shè)計(jì)規(guī)格。有效性驗(yàn)證: "我們是否在構(gòu)造一個(gè)正確的產(chǎn)品”。軟件應(yīng)該滿足用戶所需要的。

2商業(yè)軟件測(cè)試3階段：1開發(fā)測(cè)試2發(fā)布測(cè)試3用戶測(cè)試

3開發(fā)測(cè)試：1.單元測(cè)試，對(duì)單獨(dú)的程序單元活對(duì)象類進(jìn)行測(cè)試（功能）。2組件測(cè)試，多個(gè)程序單元整合創(chuàng)建一個(gè)合成的組件（接口）3系統(tǒng)測(cè)試，一些或所有組件作為整體（交互）。4選擇單元測(cè)試案例：1劃分測(cè)試，識(shí)別具有共同特征和以同樣方法處理的一組數(shù)據(jù)。2基于準(zhǔn)則測(cè)試，使用測(cè)試準(zhǔn)則來選擇測(cè)試案例。

5準(zhǔn)則：用一個(gè)只有單個(gè)值的序列來測(cè)試軟件；在不同的測(cè)試中使用不同規(guī)模的多個(gè)序列；導(dǎo)出一個(gè)測(cè)試，讓序列的第一個(gè)、中間一個(gè)和最后一個(gè)元素得到測(cè)試；測(cè)試序列的長(zhǎng)度為零。原則：選擇能強(qiáng)制系統(tǒng)生成的所有錯(cuò)誤信息輸入；設(shè)計(jì)能夠使系統(tǒng)的輸入緩沖溢出的輸入；重復(fù)相同的輸入或一系列輸入很多次；使產(chǎn)生無效的輸出；迫使輸出結(jié)果太大或者太小。6組件測(cè)試：1參數(shù)接口數(shù)據(jù)從一個(gè)過程傳到另外一個(gè)過程2共享內(nèi)存接口內(nèi)存塊為過程或函數(shù)所共享3程序接口子系統(tǒng)封裝一組程序，這些程序?yàn)槠渌酉到y(tǒng)調(diào)用4消息傳遞接口子

系統(tǒng)通過傳遞消息請(qǐng)求其他子系統(tǒng)上的服務(wù)。接口錯(cuò)誤3類：接口誤用調(diào)用者組件在調(diào)用其他組件時(shí)因接口使用不當(dāng)而發(fā)生接口錯(cuò)誤。接口誤解調(diào)用者組件誤解了被調(diào)用組件的接口描述而產(chǎn)生錯(cuò)誤，對(duì)唄調(diào)用組件進(jìn)行了錯(cuò)誤的假設(shè)。時(shí)序錯(cuò)誤調(diào)用和被調(diào)用組件以不同的速度運(yùn)行，中間過時(shí)的數(shù)據(jù)無法得到正確的處理.7用戶測(cè)試：α測(cè)試：軟件用戶和開發(fā)小組一起在開發(fā)小組一起在開發(fā)者的地點(diǎn)測(cè)試這個(gè)軟件。β測(cè)試：該軟件的版本是提供給用戶讓他們進(jìn)行測(cè)驗(yàn)，并向開發(fā)者提供發(fā)現(xiàn)的文題。接受測(cè)試：客戶測(cè)試系統(tǒng)決定他們是否愿意從系統(tǒng)開發(fā)者哪里接收系統(tǒng)并在客戶環(huán)境中部署。接收測(cè)試六個(gè)階段：1.定義接受準(zhǔn)則（合同）2.計(jì)劃接受測(cè)試 3導(dǎo)出接收測(cè)試 4.運(yùn)行接受、測(cè)試 5協(xié)商測(cè)試結(jié)果 6 拒絕/接收系統(tǒng)

第九章

1軟件進(jìn)化：變更請(qǐng)示、影響分析、版本規(guī)劃（缺陷修補(bǔ)、平臺(tái)適應(yīng)、系統(tǒng)增強(qiáng)）、變更實(shí)現(xiàn)、系統(tǒng)發(fā)布。變更實(shí)現(xiàn)：提議的變更、需求分析、需求更新、軟件開發(fā)緊急修補(bǔ)過程：變更請(qǐng)求、分析源代碼、修改源代碼、移交修改的系統(tǒng)。

2軟件維護(hù)：

1、修補(bǔ)軟件缺陷（糾正性）

2、是軟件適應(yīng)不同操作系統(tǒng)（適應(yīng)性）

3、增加或修改系統(tǒng)功能（完善性）

3投入后代價(jià)增加原因：1團(tuán)隊(duì)穩(wěn)定性2糟糕的開發(fā)實(shí)踐3人員技術(shù)水平4程序年齡和結(jié)構(gòu)。

第25章

1配置管理包括：變更管理：包括跟蹤來自客戶和開發(fā)者的軟件變更請(qǐng)求，計(jì)算做出這些變更的花費(fèi)并估計(jì)其影響，決定是否變更，何時(shí)完成變更。版本管理：包括跟蹤系統(tǒng)組件的多個(gè)版本，確保由不同開發(fā)者對(duì)組件做出的變更不會(huì)彼此干涉。系統(tǒng)構(gòu)建：是一個(gè)組裝程序組件，數(shù)據(jù)和庫的過程，然后把這些組件編譯連接成一個(gè)可以執(zhí)行的系統(tǒng)。發(fā)布管理：包括準(zhǔn)備對(duì)完發(fā)布的軟件，持續(xù)跟蹤已經(jīng)發(fā)布以供客戶使用的系統(tǒng)版本。

2配置項(xiàng)（軟件配置項(xiàng)）：與配置管理控制下的軟件項(xiàng)目有關(guān)的任何事物。配置項(xiàng)會(huì)存在多個(gè)不同的版本，每個(gè)配置項(xiàng)都有一個(gè)唯一的名字。

3變更管理確保系統(tǒng)的進(jìn)展是一個(gè)可管理的過程。主要關(guān)心的是對(duì)提建議的變更的成本收益分析，保證變更值得做，并記錄系統(tǒng)的哪些組件已經(jīng)改變。變更請(qǐng)求考慮的因素：不做變更會(huì)引起的后果，變更的益處，變更影響的用戶數(shù)，變更所需花費(fèi)，產(chǎn)品發(fā)布循環(huán)。

4版本管理是跟蹤軟件組件或配置信息以及使用這些組件系統(tǒng)的不同版本的過程。版本管理系統(tǒng)通常提供一系列特征：版本和發(fā)布版本識(shí)別被管理版本提交給系統(tǒng)時(shí)給他們分配標(biāo)識(shí)符存儲(chǔ)管理為了減少存儲(chǔ)空間，版本管理系統(tǒng)會(huì)提供存儲(chǔ)管理工具變更歷史記錄記錄并列出所有對(duì)系統(tǒng)或組件作出的變更獨(dú)立開發(fā)確保由不同的開發(fā)者對(duì)組件做出的變更互不影響項(xiàng)目支持一個(gè)版本管理系統(tǒng)可能支持共享組件的幾個(gè)項(xiàng)目的開發(fā)。

第三篇：軟件工程考點(diǎn)總結(jié)

關(guān)類組成一個(gè)層次結(jié)構(gòu)的系統(tǒng)；

4、對(duì)象彼此間只能通過發(fā)送消息相互聯(lián)系。

面向?qū)ο罅硪粋€(gè)優(yōu)點(diǎn)是軟件可重用。（6）：軟件生命周期？

1、問題定義

2、可行性研究

3、需求分析

4、總體設(shè)計(jì)

5、詳細(xì)設(shè)計(jì)

6、編碼和單元測(cè)試

7、綜合測(cè)試

8、軟件維護(hù)

（7）：幾個(gè)模型優(yōu)缺點(diǎn)

1、瀑布模型

優(yōu)點(diǎn)：可強(qiáng)迫開發(fā)人員采用規(guī)范的方法；嚴(yán)格地規(guī)定了每個(gè)階段必須提交的文檔；要求每個(gè)階段交出的所有產(chǎn)品都必須經(jīng)過質(zhì)量保證小組的仔細(xì)驗(yàn)證。

缺點(diǎn)：瀑布模型是由文檔驅(qū)動(dòng)的這個(gè)事實(shí)也是它的一個(gè)主要缺點(diǎn)。由于瀑布模型幾乎完全依賴于書面的規(guī)格說明，很可能導(dǎo)致最終開發(fā)出的軟件產(chǎn)品不能真正滿足用戶的需求。

2、快速原型模型

優(yōu)點(diǎn)：是不帶反饋環(huán)的，軟件產(chǎn)品開發(fā)基本上是線性順序進(jìn)行的。缺點(diǎn)：快速原型的本質(zhì)是“快速”，開發(fā)人員應(yīng)盡可能快地建造出原型系統(tǒng)，以加速軟件開發(fā)過程，節(jié)約軟件開發(fā)成本，原型的用途是獲知用戶的真正需求，一旦需求確定了，原型將被拋棄。

3、增量模型

優(yōu)點(diǎn)：能在較短時(shí)間內(nèi)向用戶提交可完成部分工作的產(chǎn)品，是增量模型的一個(gè)優(yōu)點(diǎn)，另一個(gè)優(yōu)點(diǎn)是逐步增加產(chǎn)品功能可以使用戶有較充裕的時(shí)間學(xué)習(xí)和適應(yīng)新產(chǎn)品，從而減少一個(gè)全新的軟件可能給客戶組織帶來的沖擊。

缺點(diǎn)：把每個(gè)新的增量構(gòu)件集成到現(xiàn)有的軟件體系結(jié)構(gòu)中時(shí)，必須不破壞原來已經(jīng)開發(fā)出的產(chǎn)品。此外，必須把軟件的體系結(jié)構(gòu)設(shè)計(jì)的便于按這種方式進(jìn)行擴(kuò)充，軟件體系結(jié)構(gòu)必須是開放的。

4、螺旋模型

優(yōu)點(diǎn)：對(duì)可選方案和約束條件的強(qiáng)調(diào)有利于已有軟件的重用，也有助于把軟件質(zhì)量作為軟件開發(fā)的一個(gè)重要目標(biāo)；減少了過多測(cè)試或測(cè)試不足所帶來的風(fēng)險(xiǎn)；更重要的是，在螺旋模型中維護(hù)只是模型的另一個(gè)周期，在維護(hù)和開發(fā)之間并沒有本質(zhì)區(qū)別。

缺點(diǎn)：是風(fēng)險(xiǎn)驅(qū)動(dòng)的。軟件開發(fā)人員具有豐富的風(fēng)險(xiǎn)評(píng)估經(jīng)驗(yàn)和這方面專門的知識(shí)，否則項(xiàng)目實(shí)際上正在走向?yàn)?zāi)難時(shí)，開發(fā)人員可能還認(rèn)為一切正常。

5、噴泉模型

優(yōu)點(diǎn)：體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特征。缺點(diǎn)：開發(fā)軟件是會(huì)產(chǎn)生無序現(xiàn)象。

目的：就是用最小的代價(jià)在盡可能短的時(shí)間內(nèi)確定問題是否能夠解決。任務(wù)：在較高層次上以較抽象的方式進(jìn)行的系統(tǒng)分析和設(shè)計(jì)的過程。以便于對(duì)以后的行動(dòng)方針提出建議。

過程：

1、復(fù)查系統(tǒng)規(guī)模和目標(biāo)

2、研究目前正在使用的系統(tǒng)

3、到處新系統(tǒng)的高層次邏輯模型

4、進(jìn)一步定義問題

5、導(dǎo)出和評(píng)價(jià)供選擇的解法

6、推薦行動(dòng)方針

7、草擬開發(fā)計(jì)劃

8、書寫文檔提交審查

（2）：數(shù)據(jù)字典4類元素

1、數(shù)據(jù)流

2、數(shù)據(jù)流分量

3、數(shù)據(jù)存儲(chǔ)

4、、處理

（3）：成本估計(jì)技術(shù)

1、代碼行技術(shù)

2、任務(wù)分解技術(shù)

3、自動(dòng)估計(jì)成本技術(shù)

（4）：成本效益分析方法，考慮方面？

1、貨幣的時(shí)間價(jià)值

2、投資回收期

3、純收入

4、投資回收率

（1）：設(shè)計(jì)過程的9個(gè)步驟

1、設(shè)想供選擇的方案

2、選取合理的方案

3、推薦最佳的方案

4、功能分解

5、設(shè)計(jì)軟件結(jié)構(gòu)

6、設(shè)計(jì)數(shù)據(jù)庫

7、制定測(cè)試計(jì)劃

8、書寫文檔

9、審查和復(fù)審（2）：軟件設(shè)計(jì)的原理

1、模塊化

2、抽象

3、逐步求精

4、信息隱藏和局部化

5、模塊獨(dú)立（3）：?jiǎn)l(fā)規(guī)則

1、改進(jìn)軟件結(jié)構(gòu)提高模塊獨(dú)立性

2、模塊規(guī)模應(yīng)該適中

3、深度、寬度、扇出和扇入都應(yīng)適當(dāng)

4、模塊的作用域應(yīng)該在控制域之內(nèi)

5、力爭(zhēng)降低模塊接口的復(fù)雜程度

6、設(shè)計(jì)單入口單出口的模塊

7、模塊功能應(yīng)該可以預(yù)測(cè)

（4）：面向數(shù)據(jù)流的設(shè)計(jì)方法把信息流映射成軟件結(jié)構(gòu)，信息流的類型決定了映射的方法，信息流有變換流和事務(wù)流兩種類型。

（1）：程序設(shè)計(jì)語言的標(biāo)準(zhǔn)

1、系統(tǒng)用戶的要求

2、可以使用的編譯程序

3、可以得到的軟件工具

4、工程規(guī)模

5、程序員的知識(shí)

6、軟件可移植性要求

7、軟件的應(yīng)用領(lǐng)域（2）：編碼遵循的規(guī)則

1、程序內(nèi)部的文檔

2、數(shù)據(jù)說明

3、語句構(gòu)造

4、輸入輸出

5、效率

（3）：軟件測(cè)試的準(zhǔn)則

1、所有測(cè)試都應(yīng)該能追溯到用戶需求。

2、應(yīng)該遠(yuǎn)在測(cè)試開始之前就制定出測(cè)試計(jì)劃。

3、把Pareto原理應(yīng)用到軟件測(cè)試中。

4、應(yīng)該從”小規(guī)?！皽y(cè)試開始，并逐步進(jìn)行”大規(guī)?！皽y(cè)試。

5、窮舉測(cè)試是不可能的。

6、為了達(dá)到最佳的測(cè)試效果，應(yīng)該由獨(dú)立的

第四篇：軟件工程小結(jié)

今天視頻看完了，可是沒有總結(jié)。還是感覺不會(huì)總結(jié)。一想到50講的課，怎么總結(jié)呢？開始聽的時(shí)候，是真不知道從哪里下手，因?yàn)殚_始看的時(shí)候有種迷迷糊糊的感覺。軟件工程，我期待的一門課就這么聽完了一遍。很有些囫圇吞棗的感覺，不過收獲還是很多的，至少知道了軟件工程的階段不是只有需求分析、編程和測(cè)試維護(hù)。當(dāng)然這個(gè)很早之前就知道，只是以前根本沒有什么概念。

第一個(gè)階段，計(jì)劃階段，要首先對(duì)用戶的要求進(jìn)行了解，對(duì)軟件的性能等進(jìn)行了解。然后進(jìn)行可行性分析研究，在各種可行性研究中，對(duì)于軟件開發(fā)人員來說，技術(shù)可行性研究最重要。之后就是需求分析階段了，需求分析階段也是計(jì)劃階段的最后一部分。需求分析定義了要做什么。把現(xiàn)實(shí)的需要用程序語言表達(dá)出來。但是這一階段并不解決怎么做。

解決怎么做的是下一個(gè)階段——設(shè)計(jì)階段。設(shè)計(jì)階段分為概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)。概要設(shè)計(jì)把每個(gè)組成部分的功能都給出意義明確的模塊，每個(gè)模塊都和一部分需求相對(duì)應(yīng)。但是不考慮細(xì)節(jié)。詳細(xì)設(shè)計(jì)，把每個(gè)模塊的功能實(shí)現(xiàn)詳細(xì)的表示出來，為源程序的編寫打下基礎(chǔ)。然后就是編程階段，我們一般最初接觸的就是編程，所以編程階段比較了解，由于前期文檔已經(jīng)做的很詳細(xì)，功能的實(shí)現(xiàn)數(shù)據(jù)和算法都已經(jīng)清楚了，所以編程是比較簡(jiǎn)單的。

編程完了就是測(cè)試階段了，測(cè)試階段的費(fèi)用是最多的。測(cè)試階段是發(fā)現(xiàn)錯(cuò)誤的階段，改錯(cuò)是調(diào)試階段。然后就是交付用戶使用，及維護(hù)。

以上幾點(diǎn)是軟件工程的生命周期的六個(gè)階段。軟件工程過程和軟件工程生命周期也不能等同。

軟件工程過程如下：

軟件規(guī)格說明：規(guī)定軟件的功能及其運(yùn)行的限制

軟件開發(fā)：產(chǎn)生滿足規(guī)格說明的軟件：

軟件的確認(rèn)：確認(rèn)軟件能夠完成客戶提出的要求：

軟件演進(jìn)：為滿足客戶的變更要求。軟件必須在使用的過程中演進(jìn)。

pdca

軟件工程過程與軟件生存期相對(duì)應(yīng)。軟件規(guī)格說明對(duì)應(yīng)計(jì)劃階段，軟件開發(fā)對(duì)應(yīng)設(shè)計(jì)、編程階段，軟件的確認(rèn)對(duì)應(yīng)測(cè)試調(diào)試階段，軟件演進(jìn)對(duì)應(yīng)運(yùn)行維護(hù)階段。

軟件開發(fā)的每個(gè)過程都有相關(guān)文檔，用老師們的話說叫做以文檔為驅(qū)動(dòng)。文檔的好壞直接影響到軟件開發(fā)的進(jìn)度和軟件的質(zhì)量。而文檔中最多的是使用圖表，dfd圖，sc圖。數(shù)據(jù)流程圖、過程流程圖、系統(tǒng)流程圖等各種圖表。還是那句話，一張好的圖表勝過一千句話。

在軟件生存周期的各個(gè)部分都有各自要注意的地方，過著說是各自的重點(diǎn)（或者是知識(shí)點(diǎn)）。

今天已經(jīng)是22號(hào)了，文檔還沒寫。先寫文檔了。唉，又落后了。

第五篇：軟件工程復(fù)習(xí)材料

1.軟件的概念

一般可以將軟件劃分為系統(tǒng)軟件、應(yīng)用軟件和介于這兩者之間的中間件。計(jì)算機(jī)軟件的傳統(tǒng)定義為：軟件是計(jì)算機(jī)系統(tǒng)中與硬件相依存的另一部分，軟件包括程序、數(shù)據(jù)及其相關(guān)文檔的完整集合。

程序是按事先設(shè)計(jì)的功能和性能要求執(zhí)行的指令序列；數(shù)據(jù)是使程序能正常操縱信息的數(shù)據(jù)結(jié)構(gòu)；文檔是與程序開發(fā)、維護(hù)和使用有關(guān)的圖文材料。

2.軟件的特性

1)形態(tài)特性。軟件是無形的、不可見的邏輯實(shí)體。2)智能特性。3)開發(fā)特性。4)質(zhì)量特性。5)生產(chǎn)特性。6)管理特性。7)環(huán)境特性。8)維護(hù)特性。9)廢棄特性。10)應(yīng)用特性。

軟件危機(jī)：軟件開發(fā)周期長(zhǎng)、成本高、質(zhì)量差、維護(hù)困難 原因

1)缺乏軟件開發(fā)的經(jīng)驗(yàn)和有關(guān)軟件開發(fā)數(shù)據(jù)的積累，使得開發(fā)工作的計(jì)劃很難制訂；

2)軟件人員與用戶的交流存在障礙；

3)軟件開發(fā)過程不規(guī)范，缺少方法論和規(guī)范的指導(dǎo)；

4)隨著軟件規(guī)模的增大，其復(fù)雜性往往會(huì)呈指數(shù)型增長(zhǎng)； 5)缺少有效的軟件評(píng)測(cè)手段，提交用戶的質(zhì)量差。

1.1.1 軟件工程的概念

軟件工程是指導(dǎo)計(jì)算機(jī)軟件開發(fā)和維護(hù)的工程學(xué)科。

采用工程的概念、原理、技術(shù)和方法來開發(fā)和維護(hù)軟件，把經(jīng)過時(shí)間考驗(yàn)而證明正確的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來，以經(jīng)濟(jì)地開發(fā)出高質(zhì)量的軟件并有效地維護(hù)它，這就是軟件工程。

1.1.2 軟件工程的目標(biāo)

軟件工程的目標(biāo)是運(yùn)用先進(jìn)的軟件開發(fā)技術(shù)和管理方法來提高軟件的質(zhì)量和生產(chǎn)率，也就是要以較短的周期、較低的成本生產(chǎn)出高質(zhì)量的軟件產(chǎn)品，并最終實(shí)現(xiàn)軟件的工業(yè)化生產(chǎn)。

衡量軟件質(zhì)量的6個(gè)特性：功能性、可靠性、可使用性、效率、可維護(hù)性和可移植性。1.1.3 軟件工程的基本原理 按軟件生存周期分階段制訂計(jì)劃并認(rèn)真實(shí)施； 3 堅(jiān)持進(jìn)行階段評(píng)審； 4 堅(jiān)持嚴(yán)格的產(chǎn)品控制； 5 使用現(xiàn)代程序設(shè)計(jì)技術(shù)； 6 明確責(zé)任； 7 用人少而精； 不斷改進(jìn)開發(fā)過程

軟件生存期: 軟件定義：?jiǎn)栴}定義、可行性研究和需求分析

軟件開發(fā)：概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼和測(cè)試

運(yùn)行維護(hù)：改正性維護(hù)、適應(yīng)性維護(hù)、完善性維護(hù)和預(yù)防性維護(hù)

軟件工程方法學(xué)包含3個(gè)要素：方法、工具和過程。

3.1 軟件需求分析階段的任務(wù)：獲取需求、分析需求、定義需求和驗(yàn)證需求

3.4 數(shù)據(jù)建模三要素：數(shù)據(jù)對(duì)象，屬性，關(guān)系 3.5 行為建模三要素：狀態(tài)，狀態(tài)轉(zhuǎn)換，事件

1.1.1 軟件設(shè)計(jì)的階段與任務(wù)：兩個(gè)階段：概要設(shè)計(jì)階段和詳細(xì)設(shè)計(jì)階段

1.1.2 模塊獨(dú)立性

1)松散耦合：非直接耦合，數(shù)據(jù)耦合，標(biāo)記耦合，控制耦合，外部耦合，公共耦合，內(nèi)容耦合。

高度內(nèi)聚：巧合內(nèi)聚，邏輯內(nèi)聚，時(shí)間內(nèi)聚，過程內(nèi)聚，通信內(nèi)聚，信息內(nèi)聚，功能內(nèi)聚

1.1.3 設(shè)計(jì)過程

(1)復(fù)查并精化數(shù)據(jù)流圖；

(2)確定數(shù)據(jù)流圖中數(shù)據(jù)流的類型，典型的數(shù)據(jù)流類型有變換型數(shù)據(jù)流和事務(wù)型數(shù)據(jù)流；

(3)導(dǎo)出初始的軟件結(jié)構(gòu)圖；(4)逐級(jí)分解；

(5)精化軟件結(jié)構(gòu)；

(6)導(dǎo)出接口描述和全局?jǐn)?shù)據(jù)結(jié)構(gòu)

1.1.4 軟件模塊結(jié)構(gòu)的改進(jìn)方法 1)模塊功能的完善化；

2)消除重復(fù)功能，改善軟件結(jié)構(gòu)；

3)模塊的作用范圍應(yīng)在控制范圍之內(nèi)；

4)盡可能減少高扇出結(jié)構(gòu)，隨著深度增大扇入； 5)避免或減少使用病態(tài)連接； 6)模塊的大小要適中

5.1.2 自頂向下、逐步細(xì)化的設(shè)計(jì)過程

一是將復(fù)雜問題的解法分解和細(xì)化成由若干個(gè)模塊組成的層次結(jié)構(gòu)； 二是將每個(gè)模塊的功能逐步分解細(xì)化為一系列的處理。

7.1面向?qū)ο蟮闹饕拍?1)對(duì)象(2)類(3)繼承

(4)消息：把向?qū)ο蟀l(fā)出的操作請(qǐng)求稱為消息；(5)關(guān)聯(lián)：是兩個(gè)或多個(gè)類之間的一個(gè)靜態(tài)關(guān)系；

(6)聚合：一個(gè)對(duì)象由其它若干個(gè)對(duì)象作為其構(gòu)成部分。

7.2基本原則主要有：抽象、分類、封裝、消息通信、多態(tài)性、復(fù)雜性控制

8.1面向?qū)ο蠓治觯∣OA）是軟件生命周期的一個(gè)階段，具有一般分析方法所共有的內(nèi)容、目標(biāo)及策略。

(1)OOA模型分為3個(gè)層次：對(duì)象層、特征層和關(guān)系層。

12.1.1 軟件維護(hù)的定義

稱在軟件運(yùn)行/維護(hù)階段對(duì)軟件產(chǎn)品所進(jìn)行的修改就是所謂的維護(hù)。1.改正性維護(hù)：診斷和改正錯(cuò)誤的過程；

2.適應(yīng)性維護(hù)：為了使軟件適應(yīng)外部環(huán)境或數(shù)據(jù)環(huán)境可能發(fā)生的變化，而修改軟件的過程稱為適應(yīng)性維護(hù)； 3.完善性維護(hù)：

修改或再開發(fā)軟件，以擴(kuò)充軟件功能、增強(qiáng)軟件性能、改進(jìn)加工效率、提高軟件的可維護(hù)性，這種情況下進(jìn)行的維護(hù)活動(dòng)稱為完善性維護(hù)。4..預(yù)防性維護(hù)

12.2 軟件維護(hù)活動(dòng) 1 軟件維護(hù)申請(qǐng)報(bào)告 2 軟件維護(hù)工作流程 3 維護(hù)檔案記錄 4 維護(hù)評(píng)價(jià)

12.3.3 修改程序的副作用以及其控制

所謂副作用是指因修改軟件而造成的錯(cuò)誤及其它不希望發(fā)生的情況 1.修改代碼的副作用 2.修改數(shù)據(jù)的副作用 3.修改文檔的副作用

12.4.1軟件可維護(hù)性的定義

所謂軟件可維護(hù)性，是指糾正軟件系統(tǒng)出現(xiàn)的錯(cuò)誤和缺陷，以及為滿足新的要求進(jìn)行修改、擴(kuò)充或壓縮的容易程度。

12.4.2 可維護(hù)性的度量 1.可理解性 2.可靠性 3.可測(cè)試性 4.可修改性 5.可移植性 6.效率

7.可使用性

10.2 傳統(tǒng)軟件過程模型 10.2.1 瀑布模型： 優(yōu)點(diǎn)：（1）可強(qiáng)迫開發(fā)人員采用規(guī)范化的方法

（2）嚴(yán)格的規(guī)定了每個(gè)階段必須提交的文檔

（3）要求每個(gè)階段交出的所有產(chǎn)品必須是經(jīng)過驗(yàn)證的 缺點(diǎn)：（1）幾乎完全依賴于書面的規(guī)格說明，很可能導(dǎo)致最終開發(fā)出的軟件產(chǎn)品不能真正滿足用戶的需求

（2）瀑布模型只適用于項(xiàng)目開始時(shí)需求已確定的情況

10.2.2 快速原型模型

優(yōu)點(diǎn)：(1)有助于滿足用戶的真實(shí)需求。

(2)原型系統(tǒng)已經(jīng)通過與用戶的交互而得到驗(yàn)證，據(jù)此產(chǎn)生的規(guī)格說明文檔能夠正確地描述用戶需求。

(3)軟件產(chǎn)品的開發(fā)基本上是按線性順序進(jìn)行。

(4)因?yàn)橐?guī)格說明文檔正確地描述了用戶需求，因此，在開發(fā)過程的后續(xù)階段不會(huì)因?yàn)榘l(fā)現(xiàn)規(guī)格說明文檔的錯(cuò)誤而進(jìn)行較大的返工。

(5)開發(fā)人員通過建立原型系統(tǒng)已經(jīng)學(xué)到了許多東西，因此，在設(shè)計(jì)和編碼階段發(fā)生錯(cuò)誤的可能性也比較小，這自然減少了在后續(xù)階段需要改正前面階段所犯錯(cuò)誤的可能性。(6)快速原型的突出特點(diǎn)是“快速”。10.2.3 增量模型

優(yōu)點(diǎn);(1)能在較短時(shí)間內(nèi)向用戶提交可完成一些有用的工作產(chǎn)品

(2)逐步增加產(chǎn)品的功能可以使用戶有較充裕的時(shí)間學(xué)習(xí)和適應(yīng)新產(chǎn)品，從而減少一個(gè)全新的軟件可能給用戶組織帶來的沖擊。(3)項(xiàng)目失敗的風(fēng)險(xiǎn)較低

(4)優(yōu)先級(jí)最高的服務(wù)首先交付，然后再將其他增量構(gòu)件逐次集成進(jìn)來。10.2.4 螺旋模型 ? 優(yōu)點(diǎn)

? 對(duì)可選方案和約束條件的強(qiáng)調(diào)有利于已有軟件的重用，也有助于把軟件質(zhì)量作為軟件開發(fā)的一個(gè)重要目標(biāo)。

? 減少了過多測(cè)試或測(cè)試不足所帶來的風(fēng)險(xiǎn)。

? 在螺旋模型中維護(hù)只是模型的另一個(gè)周期，因而在維護(hù)和開發(fā)之間并沒有本質(zhì)區(qū)別。? 缺點(diǎn)

? 螺旋模型是風(fēng)險(xiǎn)驅(qū)動(dòng)的，因此要求軟件開發(fā)人員必須具有豐富的風(fēng)險(xiǎn)評(píng)估經(jīng)驗(yàn)和這方面的專門知識(shí)，否則將出現(xiàn)真正的風(fēng)險(xiǎn)：當(dāng)項(xiàng)目實(shí)際上正在走向?yàn)?zāi)難時(shí)，開發(fā)人員可能還以為一切正常。

10.2.5 噴泉模型