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

1、什么是軟件危機(jī)？

軟件危機(jī)泛指在計(jì)算機(jī)軟件的開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題。

2、軟件危機(jī)的主要表現(xiàn)

（1）對(duì)軟件開發(fā)成本和進(jìn)度的估計(jì)常常很不準(zhǔn)確

（2）用戶對(duì)“已完成的”軟件系統(tǒng)不滿意現(xiàn)象經(jīng)常發(fā)生

（3）軟件產(chǎn)品質(zhì)量往往靠不住

（4）軟件往往是不可維護(hù)的（5）軟件通常沒有適當(dāng)?shù)奈臋n資料

（6）軟件成本在計(jì)算機(jī)系統(tǒng)總成本中所占的比例逐年上升

（7）軟件開發(fā)生產(chǎn)效率提高的速度，遠(yuǎn)遠(yuǎn)跟不上計(jì)算機(jī)應(yīng)用迅速普及深入的趨勢(shì)

3、軟件危機(jī)產(chǎn)生的原因

(1)來自軟件自身的特點(diǎn)

是軟件系統(tǒng)的邏輯部件，缺乏可見性，管理和控制軟件開發(fā)過程相當(dāng)困難；規(guī)模龐大、復(fù)雜，修改、維護(hù)困難。

(2)軟件開發(fā)與維護(hù)的方法不當(dāng)

忽視需求分析；認(rèn)為軟件開發(fā)等于程序編寫；輕視軟件維護(hù)。

4、如何消除軟件危機(jī)？

（1）對(duì)計(jì)算機(jī)軟件有一個(gè)正確的認(rèn)識(shí)(軟件≠程序）

（2）必須充分認(rèn)識(shí)到軟件開發(fā)不是某種個(gè)體勞動(dòng)的神秘技巧，而應(yīng)該是一種組織良好、管理嚴(yán)密、各類人員協(xié)同配合、共同完成的工程項(xiàng)目

（3）推廣使用在實(shí)踐中總結(jié)出來的開發(fā)軟件的成功技術(shù)和方法

（4）開發(fā)和使用更好的軟件工具

5、面向?qū)ο蟮娜N模型：對(duì)象模型 動(dòng)態(tài)模型 功能模型 P2166、模塊獨(dú)立性的兩個(gè)標(biāo)準(zhǔn)：耦合 內(nèi)聚 P977、軟件測(cè)試方法：黑盒測(cè)試 白盒測(cè)試 P1518、軟件調(diào)試的途徑：蠻干法 回溯法 原因排除法 P1789、可行性研究：確定問題是否有行得通的解決辦法 P3510、需求分析：準(zhǔn)確地回答“系統(tǒng)必須干什么”這個(gè)問題 P5511、軟件成分的重用級(jí)別：代碼重用 設(shè)計(jì)結(jié)果重用 分析結(jié)果重用

可被重用的軟件成分有：項(xiàng)目計(jì)劃，成本估計(jì)，體系結(jié)構(gòu)，需求模型和規(guī)格說明，設(shè)計(jì)，源代碼，用戶文檔和技術(shù)文檔，用戶界面，數(shù)據(jù)，測(cè)試用例。

12、軟件可靠性的定義：軟件在給定的時(shí)間間隔內(nèi)，按照規(guī)格說明書的規(guī)定成功地運(yùn)行的概率。

軟件可用性的定義：程序在給定的時(shí)間點(diǎn)，按照規(guī)格說明書的規(guī)定，成功地運(yùn)行的概率。可靠性與可用性之間的主要差別是，可靠性意味著在0到t這段時(shí)間內(nèi)系統(tǒng)沒有失效，而可用性只意味著在時(shí)刻t，系統(tǒng)是正常運(yùn)行的。P17913、白盒測(cè)試：邏輯覆蓋 控制結(jié)構(gòu)測(cè)試 P162

黑盒測(cè)試：等價(jià)劃分 邊界值分析 調(diào)試 P171

環(huán)形復(fù)雜度的計(jì)算：復(fù)雜度=邊數(shù)-點(diǎn)數(shù)+2P13714、面向?qū)ο蟮?個(gè)子模式：對(duì)象模型 動(dòng)態(tài)模型 功能模型 P232

對(duì)象模型的5個(gè)層次：主題層 類與對(duì)象層 結(jié)構(gòu)層 屬性層 服務(wù)層 P23215、軟件定義階段干什么事：確定軟件開發(fā)工程必須完成的總目標(biāo)；確定工程的可行性；導(dǎo)

出實(shí)現(xiàn)工程目標(biāo)應(yīng)該采用的策略及系統(tǒng)必須完成的功能；估計(jì)完成該工程需要的資源和成本，并制定工程進(jìn)度表。

16、類和對(duì)象的關(guān)系：類是具有相同數(shù)據(jù)和相同操作的一組相似對(duì)象的定義，也就是說，類

是對(duì)具有相同屬性和行為的一個(gè)或多個(gè)對(duì)象的描述。類是支持繼承的抽象數(shù)據(jù)類型，而對(duì)象就是類的實(shí)例。P21117、UML有哪些圖？ P2171、用例圖：展示系統(tǒng)外部的各類執(zhí)行者與系統(tǒng)提供的各種用例之間的關(guān)系

2、類圖：展示系統(tǒng)中類的靜態(tài)結(jié)構(gòu)

3、對(duì)象圖：是類圖的一種實(shí)例化圖

4、狀態(tài)圖：描述一類對(duì)象具有的所有可能的狀態(tài)及其轉(zhuǎn)移關(guān)系

5、時(shí)序圖：展示對(duì)象之間的一種動(dòng)態(tài)協(xié)作關(guān)系

6、合作圖：從另一個(gè)角度展示對(duì)象之間的動(dòng)態(tài)協(xié)作關(guān)系

7、活動(dòng)圖：展示系統(tǒng)中各種活動(dòng)的執(zhí)行流程

8、構(gòu)件圖：展示程序代碼的物理結(jié)構(gòu)

9、配置圖：展示軟件在硬件環(huán)境中的配置關(guān)系

18、能力成熟度模型（CMM）：初始級(jí) 可重復(fù)級(jí) 已定義級(jí) 已管理級(jí) 優(yōu)化級(jí) P31119、什么是軟件生命周期模型?試比較瀑布模型、快速原型模型、增量模型和螺旋模型的優(yōu)

缺點(diǎn)，說明每種模型的適用范圍。P33習(xí)題1.720、軟件的可維護(hù)性定義：維護(hù)人員理解、改正、改動(dòng)或改進(jìn)這個(gè)軟件的難易程度。決定可維護(hù)性的因素：可理解性 可測(cè)試性 可修改性 可移植性 可重用性。

文檔是影響可維護(hù)性的決定性因素。P19521、如何評(píng)價(jià)軟件規(guī)格說明書？

從四個(gè)方面：一致性 完整性 現(xiàn)實(shí)性 有效性 P7022、層次圖 P10223、深度：軟件結(jié)構(gòu)中控制的層數(shù) P100

寬度：軟件結(jié)構(gòu)中同一個(gè)層次上的總數(shù)的最大值

扇出：一個(gè)模塊直接控制（調(diào)用）的模塊數(shù)目

散入：一個(gè)模塊被多少個(gè)上級(jí)模塊直接調(diào)用

24、面向數(shù)據(jù)流的設(shè)計(jì)方法 P10425、類構(gòu)件的重用方式：實(shí)例重用 繼承重用 多態(tài)重用

1.什么是軟件工程？軟件工程和計(jì)算機(jī)科學(xué)有何區(qū)別？

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

計(jì)算機(jī)科學(xué)研究的是構(gòu)成計(jì)算機(jī)和軟件系統(tǒng)基礎(chǔ)的有關(guān)理論和方法，而軟件工程則是研究軟件制作中的實(shí)際問題。

2、流程圖與數(shù)據(jù)流圖有什么主要區(qū)別？

（1）數(shù)據(jù)流圖（date flow diagram , DFD），是SA方法中用于表示系統(tǒng)邏輯模型的一種工具，它以圖形的方式描繪數(shù)據(jù)在系統(tǒng)中流動(dòng)和處理的過程，由于它只反映系統(tǒng)必須完成的邏輯功能，所以它是一種功能模型，是從數(shù)據(jù)的角度來描述一個(gè)系統(tǒng)的；而流程圖則是從對(duì)數(shù)據(jù)加工的角度來描述系統(tǒng)的；

（2）數(shù)據(jù)流圖中的箭頭是數(shù)據(jù)流，而流程圖中的箭頭則是控制流,它表達(dá)的是程序執(zhí)行的次序；

（3）數(shù)據(jù)流圖適合于宏觀地分析一個(gè)組織業(yè)務(wù)概況,而程序流程圖只適合于描述系統(tǒng)中某個(gè)加工的執(zhí)行細(xì)節(jié)。

（4）數(shù)據(jù)流程圖應(yīng)該重點(diǎn)描述了數(shù)據(jù)加工的過程，主要是模塊內(nèi)部，數(shù)據(jù)流圖則是描述模塊之間的關(guān)系。

3．軟件需求分析的任務(wù)是什么？有哪些主要步驟？

需求分析的基本任務(wù)是深入描述軟件的功能和性能、確定軟件設(shè)計(jì)的約束和軟件同其它系統(tǒng)元素的接口細(xì)節(jié)、定義軟件的其它有效性需求，總之，需求分析的任務(wù)就是借助于當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型，解決目標(biāo)系統(tǒng)的 “做什么” 的問題。

主要步驟：

1.問題識(shí)別

(1)功能需求：明確所開發(fā)的軟件必須具備什么樣的功能。

(2)性能需求：明確待開發(fā)的軟件的技術(shù)性能指標(biāo)。

(3)環(huán)境需求：明確軟件運(yùn)行時(shí)所需要的軟、硬件的要求。

(4)用戶界面需求：明確人機(jī)交互方式、輸入輸出數(shù)據(jù)格式。

2.分析與綜合，導(dǎo)出軟件的邏輯模型

分析人員對(duì)獲取的需求，進(jìn)行一致性的分析檢查，在分析、綜合中逐步細(xì)化軟件功能，劃分成各個(gè)子功能。用圖文結(jié)合的形式，建立起新系統(tǒng)的邏輯模型。

3.編寫文檔

(1)編寫“需求規(guī)格說明書”，把雙方共同的理解與分析結(jié)果用規(guī)范的方式描述出來，作為今后各項(xiàng)工作的基礎(chǔ)。

(2)編寫初步用戶使用手冊(cè)，著重反映被開發(fā)軟件的用戶功能界面和用戶使用的具體要求，用戶手冊(cè)能強(qiáng)制分析人員從用戶使用的觀點(diǎn)考慮軟件。

(3)編寫確認(rèn)測(cè)試計(jì)劃，作為今后確認(rèn)和驗(yàn)收的依據(jù)。

(4)修改完善軟件開發(fā)計(jì)劃。在需求分析階段對(duì)待開發(fā)的系統(tǒng)有了更進(jìn)一步的了解，所以能更準(zhǔn)確地估計(jì)開發(fā)成本、進(jìn)度及資源要求，因此對(duì)原計(jì)劃要進(jìn)行適當(dāng)修正。

4．簡(jiǎn)述結(jié)構(gòu)化分析、設(shè)計(jì)的要點(diǎn)：

結(jié)構(gòu)化分析方法適合于數(shù)據(jù)處理類型軟件的需求分析。

其要點(diǎn)是“自頂向下” 地開發(fā)系統(tǒng),由整體到各組成部分,由表及里,由抽象到具體,逐步求精.(1)模塊化

(2)由頂向下,逐步求精.(3)上層模塊分解為下層模塊,有三種不同的結(jié)構(gòu)形式,即順序結(jié)構(gòu),選擇結(jié)構(gòu)和循環(huán)結(jié)構(gòu).5．?dāng)?shù)據(jù)字典包含哪些主要內(nèi)容？

數(shù)據(jù)字典通常包括數(shù)據(jù)項(xiàng)、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)流、數(shù)據(jù)存儲(chǔ)和處理過程五個(gè)部分.據(jù)字典內(nèi)容包括：

數(shù)據(jù)庫(kù)中所有模式對(duì)象的信息，如表、視圖、簇、及索引等。

分配多少空間，當(dāng)前使用了多少空間等。

列的缺省值。

約束信息的完整性。

用戶的名字。

用戶及角色被授予的權(quán)限。

用戶訪問或使用的審計(jì)信息。

其它產(chǎn)生的數(shù)據(jù)庫(kù)信息。

6．軟件測(cè)試的目標(biāo)是什么，有哪幾種主要有測(cè)試方法？

軟件測(cè)試的目標(biāo)：

(1)測(cè)試是為了發(fā)現(xiàn)程序中的錯(cuò)誤而執(zhí)行程序的過程；

(2)好的測(cè)試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試方案；

(3)成功的測(cè)試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。

軟件測(cè)試的方法有黑盒測(cè)試、白盒測(cè)試。

7．白盒測(cè)試主要有哪些覆蓋？

語(yǔ)句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、點(diǎn)覆蓋、邊覆蓋、路徑覆蓋

8、選擇一種程序設(shè)計(jì)語(yǔ)言的主要有哪些依據(jù)？

為了使程序容易測(cè)試和維護(hù)以減少生命周期的總成本，選用的高級(jí)語(yǔ)言應(yīng)該有理想的模塊化機(jī)制，以及可讀性好的控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)；為了便于調(diào)試和提高軟件可靠性，語(yǔ)言特點(diǎn)應(yīng)該使編譯程序能夠盡可能多地發(fā)現(xiàn)程序中的錯(cuò)誤；為了降低軟件開發(fā)和維護(hù)的成本，選用的語(yǔ)言應(yīng)該有良好的獨(dú)立編譯機(jī)制。上述這些要求是選擇語(yǔ)言的理想標(biāo)準(zhǔn)，但是在實(shí)際選用語(yǔ)言時(shí)不能僅僅考慮理論上的標(biāo)準(zhǔn)，還必須同時(shí)考慮實(shí)用方面的各種限制。

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

(2)可以使用的編譯程序

(3)可以得到的軟件工具

(4)系統(tǒng)規(guī)模

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

(6)軟件可移植性要求

(7)軟件的應(yīng)用領(lǐng)域

9．軟件的維護(hù)的目標(biāo)是什么，有哪幾種維護(hù)類型？

糾正在使用過程中暴露出來的錯(cuò)誤而進(jìn)行的改進(jìn)性維護(hù)，適應(yīng)外部環(huán)境的變化而進(jìn)行的適應(yīng)性維護(hù)，改進(jìn)原有的軟件而進(jìn)行的完善性維護(hù)，以及改進(jìn)將來的可維護(hù)性和可靠性而進(jìn)行的預(yù)防性維護(hù)。

軟件維護(hù)主要?jiǎng)澐譃榧m錯(cuò)性維護(hù)、適應(yīng)性維護(hù)和完善性維護(hù)。

(1)糾錯(cuò)性維護(hù)。由于前期的測(cè)試不可能揭露軟件系統(tǒng)中所有潛在的錯(cuò)誤，用戶在使用軟件時(shí)仍將會(huì)遇到錯(cuò)誤，診斷和改正這些錯(cuò)誤的過程稱為糾錯(cuò)性維護(hù)。

(2)適應(yīng)性維護(hù)。由于新的硬件設(shè)備不斷推出，操作系統(tǒng)和編譯系統(tǒng)也不斷地升級(jí)，為了使軟件能適應(yīng)新的環(huán)境而引起的程序修改和擴(kuò)充活動(dòng)稱為適應(yīng)性維護(hù)。

(3)完善性維護(hù)。在軟件的正常使用過程中，用戶還會(huì)不斷地提出新的需求。為了滿足用戶新的需求而增加軟件功能的活動(dòng)稱為完善性維護(hù)。

10．簡(jiǎn)述提高軟件質(zhì)量的主要措施。

復(fù)審：是在軟件生命周期每個(gè)階段結(jié)束之前，都采用一定的標(biāo)準(zhǔn)對(duì)該段產(chǎn)生的軟件配置成分進(jìn)行嚴(yán)格的正式或非正式的檢測(cè)。

復(fù)查：是檢查已有的材料，以斷定在軟件生命周期某個(gè)階段的工作是否能夠開始或繼續(xù)。管理復(fù)審：是向開發(fā)組織或使用部門的管理人員提供有關(guān)項(xiàng)目的總體狀況、成本和進(jìn)度等方面的情況，以便他們從管理角度對(duì)開發(fā)工作進(jìn)行審查。

測(cè)試：包括測(cè)試計(jì)劃、測(cè)試過程和測(cè)試結(jié)果3個(gè)階段。

11．面向?qū)ο笕绾螌?shí)現(xiàn)模塊獨(dú)立性，其偶合和內(nèi)聚的含義是什么？

因?yàn)閷?duì)象是由數(shù)據(jù)及可以對(duì)這些數(shù)據(jù)施加的操作所組成的統(tǒng)一體，而且對(duì)象是以數(shù)據(jù)為中心的，操作圍繞對(duì)其數(shù)據(jù)所需做的處理來設(shè)置，沒有無(wú)關(guān)的操作。因此，對(duì)象內(nèi)部各種元素彼此結(jié)合得很緊密。內(nèi)聚性相當(dāng)強(qiáng)，由于完成對(duì)象所需要的元素（數(shù)據(jù)和方法）基本上都被封裝在對(duì)象內(nèi)部，它與外界的聯(lián)系自然就比較少。因此，對(duì)象之間的耦合通常比較松?？傊?，面向?qū)ο笫褂脤?duì)象、類、繼承和消息的方法，既使用類和繼承等機(jī)制，而且對(duì)象之間僅能通過傳遞消息實(shí)現(xiàn)彼此通信來實(shí)現(xiàn)模塊的獨(dú)立性。

12．面向?qū)ο蠛兔嫦蜻^程軟件工程有哪些區(qū)別？

（1）面向過程就是分析出解決問題所需要的步驟，然后用函數(shù)把這些步驟一步一步實(shí)現(xiàn)，使用的時(shí)候一個(gè)一個(gè)依次調(diào)用就可以了。面向?qū)ο笫前褬?gòu)成問題事務(wù)分解成各個(gè)對(duì)象，建立對(duì)象的目的不是為了完成一個(gè)步驟，而是為了描敘某個(gè)事物在整個(gè)解決問題的步驟中的行為。（2）面向過程是把一件事一項(xiàng)工程分解成為一個(gè)個(gè)小的功能,用一個(gè)個(gè)函數(shù)來實(shí)現(xiàn).面向?qū)ο笫前咽虑榭闯墒且粋€(gè)個(gè)小的對(duì)象組成的,或者說一個(gè)個(gè)小部分組成的,這些對(duì)象之間的相互關(guān)系,構(gòu)成了整個(gè)項(xiàng)目.在面向?qū)ο蟮乃枷胫?，萬(wàn)物皆對(duì)象。而“類”，就是對(duì)象的抽象或者說是概括。

13.簡(jiǎn)述對(duì)象、類、消息、方法的基本概念。

(1)對(duì)象是人們要進(jìn)行研究的任何事物，從最簡(jiǎn)單的整數(shù)到復(fù)雜的飛機(jī)等均可看作對(duì)象，它不僅能表示具體的事物，還能表示抽象的規(guī)則、計(jì)劃或事件。

(2)類是具有相同或相似性質(zhì)的對(duì)象的抽象。對(duì)象的抽象是類，類的具體化就是對(duì)象，也可以說類的實(shí)例是對(duì)象。類具有屬性，它是對(duì)象的狀態(tài)的抽象，用數(shù)據(jù)結(jié)構(gòu)來描述類的屬性。類具有操作，它是對(duì)象的行為的抽象，用操作名和實(shí)現(xiàn)該操作的方法來描述。

(3)對(duì)象之間進(jìn)行通信的結(jié)構(gòu)叫做消息。在對(duì)象的操作中，當(dāng)一個(gè)消息發(fā)送給某個(gè)對(duì)象時(shí)，消息包含接收對(duì)象去執(zhí)行某種操作的信息。發(fā)送一條消息至少要包括說明接受消息的對(duì)象名、發(fā)送給該對(duì)象的消息名（即對(duì)象名、方法名）。一般還要對(duì)參數(shù)加以說明，參數(shù)可以是認(rèn)識(shí)該消息的對(duì)象所知道的變量名，或者是所有對(duì)象都知道的全局變量名。

(4)類中操作的實(shí)現(xiàn)過程叫做方法，一個(gè)方法有方法名、參數(shù)、方法體。

14．簡(jiǎn)述面向?qū)ο蠓治鲈O(shè)計(jì)的三個(gè)模型。

答：三個(gè)模型：對(duì)象模型、動(dòng)態(tài)模型、功能模型

（1）對(duì)象模型描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，包括類和對(duì)象，它們的屬性和操作，以及它們之間的關(guān)系。構(gòu)造對(duì)象模型的目的在于找出與應(yīng)用程序密切相關(guān)的概念。對(duì)象模型用包含對(duì)象及對(duì)象的關(guān)系圖表示。

（2）動(dòng)態(tài)模型著重于系統(tǒng)的控制邏輯，考察在任何時(shí)候?qū)ο蠹捌潢P(guān)系的改變，描述這些涉及時(shí)序和改變的狀態(tài)。動(dòng)態(tài)模型包括狀態(tài)圖和事件跟蹤圖。狀態(tài)圖是一個(gè)狀態(tài)和事件的網(wǎng)絡(luò)，側(cè)重于描述每一類對(duì)象的動(dòng)態(tài)行為。事件跟蹤圖則側(cè)重于說明系統(tǒng)執(zhí)行過程中的一個(gè)特點(diǎn)“場(chǎng)景”，也叫做腳本(scenarios)，是完成系統(tǒng)某個(gè)功能的一個(gè)事件序列。腳本通常起始于一個(gè)系統(tǒng)外部的輸入事件，結(jié)束于一個(gè)系統(tǒng)外部的輸出事件。

（3）功能模型著重于系統(tǒng)內(nèi)部數(shù)據(jù)的傳送和處理。功能模型表明，通過計(jì)算，從輸出數(shù)據(jù)能得到什么樣的輸出數(shù)據(jù)，但不考慮參加計(jì)算的數(shù)據(jù)按什么時(shí)序執(zhí)行。功能模型由多個(gè)數(shù)據(jù)流圖組成，它們指明從外部輸出，通過操作和內(nèi)部存儲(chǔ)，直到外部輸出的整個(gè)數(shù)據(jù)流情況。功能模型還包括了對(duì)象模型內(nèi)部數(shù)據(jù)間的限制。功能模型中的數(shù)據(jù)流圖往往形成一個(gè)層次結(jié)構(gòu)，一個(gè)數(shù)據(jù)流圖的過程可以由下一層的數(shù)據(jù)流圖作進(jìn)一步的說明。

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

軟件的定義：軟件是計(jì)算機(jī)系統(tǒng)中與硬件相互依存的另一部分，軟件包括程序、數(shù)據(jù)及其相關(guān)文檔的完整集合。

在結(jié)構(gòu)化程序設(shè)計(jì)時(shí)代，程序的最小單位是向?qū)ο蟪绦蛟O(shè)計(jì)時(shí)代，程序的最小單位是類，在類中封裝了相關(guān)的數(shù)據(jù)及指令代碼。軟件的特性：形態(tài)特性、智能特性、開發(fā)特特性、維護(hù)特性、廢棄特性、應(yīng)用特性。軟件的分類：系統(tǒng)軟件、應(yīng)用軟件、支撐軟 軟件危機(jī)的表現(xiàn)：軟件開發(fā)周期長(zhǎng)、成本高、軟件危機(jī)發(fā)生的原因：（1）缺乏軟件開發(fā)的工作的計(jì)劃很難制定。（2）軟件人員與用戶的交流存在障礙。（3）軟件開發(fā)過程不規(guī)范，缺少方法論和規(guī)范的指導(dǎo)，開發(fā)人員各自為戰(zhàn)，缺少整體的規(guī)劃和配合，不重視文字資料工作，軟件難以維護(hù)。（4）隨著軟件規(guī)模的增大，其復(fù)雜性往往會(huì)呈指數(shù)級(jí)升高。（5）缺少有效的軟件測(cè)評(píng)手段，提高用戶的軟件質(zhì)量差，在運(yùn)行中暴露出大量的問題，輕者影響系統(tǒng)的正常使用，重者發(fā)生事故，甚至造成生命財(cái)產(chǎn)的重大損失。

首次提出“軟件工程”的概念的時(shí)間是1968年。

按工程化的原則和方法組織軟件開發(fā)工作是 軟件工程的定義：軟件工程是指導(dǎo)軟件開發(fā)和維護(hù)的工程性學(xué)科，它以計(jì)算機(jī)科學(xué)理論和其他相關(guān)學(xué)科的理論為指導(dǎo)，采用工程化的概念、原理、技術(shù)和方法進(jìn)行軟件的開發(fā)和維護(hù)，把經(jīng)過時(shí)間考驗(yàn)而證明是正確的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來，以較少的代價(jià)獲得高質(zhì)量的軟件并維護(hù)它。

軟件工程的目標(biāo)是運(yùn)用先進(jìn)的軟件開發(fā)技術(shù) 衡量軟件的質(zhì)量的六個(gè)特性：功能性、可靠

軟件生存期的三個(gè)時(shí)期：軟件定義、軟件開定義時(shí)期的主要任務(wù)是解決“做什么”的問地滿足用戶的需要。

開發(fā)過程中的典型文檔包括：軟件需求規(guī)格計(jì)說明書、用戶手冊(cè)。

各個(gè)階段所要完成的基本任務(wù)：?jiǎn)栴}定義與可行性研究、需求分析、軟件設(shè)計(jì)、程序編碼和單元測(cè)試、集成測(cè)試和系統(tǒng)測(cè)試、軟件運(yùn)行和維護(hù)。

典型的軟件生存期模型包括瀑布模型、原型模型、增量模型、螺旋模型等（噴泉模型）。

瀑布模型的特點(diǎn)：1）階段間具有順序性和依賴性。2）推遲實(shí)現(xiàn)的觀點(diǎn)。3）質(zhì)量保證的觀點(diǎn)。

瀑布模型的優(yōu)點(diǎn)：①可強(qiáng)迫開發(fā)人員采用規(guī)范化的方法。②嚴(yán)格地規(guī)定了每個(gè)階段必須提交的文檔。③要求每個(gè)階段交出的所有產(chǎn)品都必須是經(jīng)過驗(yàn)證（評(píng)審）的。

瀑布模型的缺點(diǎn)：①由于瀑布模型幾乎完全依賴于書面的規(guī)格說明，很可能導(dǎo)致最終開發(fā)出的軟件產(chǎn)品不能真正滿足用戶的需要。如果需求規(guī)格說明與用戶需求之間有差異，就會(huì)發(fā)生這種情況。②瀑布模型只適用于項(xiàng)目開始時(shí)需求已確定的情況。

快速原型模型的優(yōu)點(diǎn)：①有助于滿足用戶的互而得到驗(yàn)證，據(jù)此產(chǎn)生的規(guī)格說明文檔能夠正確地描述用戶需求。③軟件產(chǎn)品的開發(fā)基本上是按線性順序進(jìn)行。④因?yàn)橐?guī)格說明文檔正確地描述了用戶需求，因此，在開發(fā)過程的后續(xù)階段不會(huì)因?yàn)榘l(fā)現(xiàn)規(guī)格說明文檔的錯(cuò)誤而進(jìn)行較大的返工。⑤開發(fā)人員通過建立原型系統(tǒng)已經(jīng)學(xué)到了許多東西，因此，在設(shè)計(jì)和編碼階段發(fā)生錯(cuò)誤的可能性也比較小，這自然減少了在后續(xù)階段需要改正前面階段所犯錯(cuò)誤的可能性。⑥快速原型的本質(zhì)是“快速”。開發(fā)人員應(yīng)該盡可能快地創(chuàng)造出原型系統(tǒng)，以加速軟件開發(fā)過程，節(jié)約軟件開發(fā)成本。原型的用途是獲知用戶的真正需求，一旦需求確定了，原型可以拋棄，當(dāng)然也可以在原型的基礎(chǔ)上進(jìn)行開發(fā)。

增量模型的優(yōu)點(diǎn)：①能夠在較短的時(shí)間內(nèi)向構(gòu)件交付之日起，用戶就能做一些有用的工作。②逐步增加產(chǎn)品的功能可以使用戶有較充裕的時(shí)間學(xué)習(xí)和適應(yīng)新產(chǎn)品，從而減少全新的軟件可能給用戶組織帶來的沖擊。③項(xiàng)目失敗的風(fēng)險(xiǎn)較低，雖然在某些增量構(gòu)件中可能遇到一些問題，但其他增量構(gòu)件將能夠成功地交付給客戶。④優(yōu)先級(jí)最高的服務(wù)首先交付，然后再將其他增量構(gòu)件逐次集成進(jìn)來。一個(gè)必然的事實(shí)是：最重要的系統(tǒng)服務(wù)將接受最多的測(cè)試。這意味著系統(tǒng)最重要的部分一般不會(huì)遭遇失敗。

螺旋模型的優(yōu)點(diǎn)：①對(duì)可選方案和約束條件軟件質(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ā)人員可能還以為一切正常。

方法學(xué)：通常把在軟件生命周期全過程中使用的一整套技術(shù)的集合稱為方法學(xué)，也稱為范型。

軟件工程方法學(xué)三個(gè)要素：方法、工具和過傳統(tǒng)方法也稱為生命周期方法或結(jié)構(gòu)化范項(xiàng)任務(wù)。這種方法學(xué)把軟件生命周期的全過程依次劃分為若干個(gè)階段，然后順序地逐步完成每個(gè)階段的任務(wù)。每個(gè)階段的開始和結(jié)束都有嚴(yán)格的標(biāo)準(zhǔn)，對(duì)于任何兩個(gè)相鄰的階段而言，前一階段的結(jié)束標(biāo)準(zhǔn)就是后一階段的開始標(biāo)準(zhǔn)。在每個(gè)階段結(jié)束之前都必須進(jìn)行正式評(píng)審，評(píng)審?fù)ㄟ^之后這個(gè)階段才結(jié)束，否則就需要返工，返工之后還要評(píng)審。評(píng)審的一條主要標(biāo)準(zhǔn)就是每個(gè)階段都應(yīng)該交出高質(zhì)量的工作產(chǎn)品，其中，前面階段的工作產(chǎn)品主要是文檔，如需求規(guī)格說明書、軟件設(shè)計(jì)說明書等。

面向?qū)ο蠓椒ǖ幕驹瓌t，是盡量模擬人類習(xí)慣的思維方式，使開發(fā)軟件的方法和過程盡可能接近人類認(rèn)識(shí)問題和解決問題的方法與過程，從而使描述問題的問題空間與其解空間在結(jié)構(gòu)上盡可能一致。

封裝的定義：封裝是一種信息隱蔽技術(shù)，就作封裝在一起。①清楚的邊界②接口③受保護(hù)的內(nèi)部實(shí)現(xiàn)

軟件需求分析階段的主要工作產(chǎn)品有“軟件需求規(guī)格說明書”和“初步的用戶手冊(cè)” 需求獲取的主要任務(wù)是與客戶或用戶溝通，想要實(shí)現(xiàn)什么，系統(tǒng)和產(chǎn)品如何滿足業(yè)務(wù)的要求，最終系統(tǒng)或產(chǎn)品如何用于日常工作

需求獲取產(chǎn)生困難的原因：系統(tǒng)的目標(biāo)或范圍問題，需求不準(zhǔn)確性問題，需求的易變問題

需求獲取活動(dòng)需解決的問題：1.發(fā)現(xiàn)和分析問題，并分析問題的原因/結(jié)果關(guān)系2.與用戶進(jìn)行各種方式的交流，并使用調(diào)查研究方法收集信息3.按照三個(gè)成分即數(shù)據(jù)、過程和接口觀察問題的不同側(cè)面4.將獲取的需求文檔化，形式有例圖、決策表、決策樹等 軟件需求分析階段的工作4個(gè)步驟：需求獲取，需求分析，需求定義，需求驗(yàn)證

數(shù)據(jù)字典以詞條方式定義在數(shù)據(jù)模型、功能息的特性，給出它們的準(zhǔn)確定義

設(shè)計(jì)是技術(shù)世界和人類的目標(biāo)世界結(jié)合在一

軟件設(shè)計(jì)的原則：(1)分而治之(2)模塊獨(dú)立(4)復(fù)用性設(shè)計(jì)(5)靈活性設(shè)計(jì)

模塊獨(dú)立性，是指軟件系統(tǒng)中每個(gè)模塊只涉

復(fù)用是指同一事物不做修改或稍加修改就可質(zhì)量及生產(chǎn)率的重要方法，軟件復(fù)用已不再局限于軟件代碼的復(fù)用，復(fù)用范圍已經(jīng)擴(kuò)展到軟件開發(fā)的各個(gè)階段，包括需求模型和規(guī)格說明、設(shè)計(jì)模型、文檔、測(cè)試用例等復(fù)用。模塊間的耦合和內(nèi)聚兩個(gè)準(zhǔn)則來度量模塊獨(dú)的緊密程度）的度量，內(nèi)聚是模塊功能強(qiáng)度（一個(gè)模塊內(nèi)部各個(gè)元素彼此結(jié)合的緊密程度）的度量。模塊獨(dú)立性比較強(qiáng)的模塊應(yīng)是高度內(nèi)聚、松散耦合的模塊。

在最高的抽象層次上，可以使用問題所處環(huán)境的語(yǔ)言概括地描述問題的解決方法：在較低的抽象層次上，采用更過程化的方法，將面向問題的術(shù)語(yǔ)和面向?qū)崿F(xiàn)的術(shù)語(yǔ)結(jié)合起來描述問題的解法；在最低的抽象層次，則用某種程序設(shè)計(jì)語(yǔ)言來描述問題的解法。從工商管理的角度，可以將軟件設(shè)計(jì)分為兩個(gè)階段：概念設(shè)計(jì)階段和詳細(xì)設(shè)計(jì)階段。結(jié)構(gòu)圖是精確模塊結(jié)構(gòu)的圖形表示工具。清聯(lián)系。(1)模塊的條用關(guān)系和接口(2)模塊間的信息傳遞(3)輔助符號(hào)(4)結(jié)構(gòu)圖的形態(tài)特征(結(jié)構(gòu)圖的深度、寬度、扇入和扇出)過程描述工具有：圖形工具、表格工具、語(yǔ)

自頂向下、逐步求精方法的優(yōu)點(diǎn)：1)自頂向遍規(guī)律，可提高軟件開發(fā)的成功率和生產(chǎn)率2)用先全局后局部、先整體后細(xì)節(jié)、先抽象后具體的逐步求精的過程開發(fā)出來的程序具有清晰地層次結(jié)構(gòu)，因此程序更容易閱讀和理解3)程序自頂向下，逐步細(xì)化，分解成樹形結(jié)構(gòu)4)程序清晰和模塊化，使得在修改和重新設(shè)計(jì)一個(gè)軟件時(shí)，可復(fù)用的代碼量最大5)程序的邏輯結(jié)構(gòu)清晰，有利于程序正確性證明6)每一步工作盡在上層結(jié)點(diǎn)的基礎(chǔ)上做不多的設(shè)計(jì)擴(kuò)展，便于檢查7)有利于設(shè)計(jì)的分工和組織工作

軟件測(cè)試：在軟件投入生產(chǎn)性運(yùn)行之前，對(duì)復(fù)審，是軟件質(zhì)量控制的關(guān)鍵步驟。軟件測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程。

軟件測(cè)試的目的：①測(cè)試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯(cuò)誤；②一個(gè)好的測(cè)試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤；③一個(gè)成功的測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。軟件測(cè)試的目標(biāo)是想以最少的時(shí)間和人力系 軟件測(cè)試的原則：

1、盡早地和不斷地進(jìn)行軟之對(duì)應(yīng)的預(yù)期輸出結(jié)果這兩部分組成；

3、程序員應(yīng)避免檢查自己的程序。測(cè)試過程需要三類輸入：軟件配置、測(cè)試配控制流圖是描述程序的控制流的一種圖示方

環(huán)路復(fù)雜性V（G）的計(jì)算方法：

1、環(huán)路復(fù)

2、設(shè)E為控制流圖的邊數(shù)，N為圖中的結(jié)點(diǎn)數(shù)，則V（G）=E-N+2；

3、設(shè)P為控制流圖中的判定結(jié)點(diǎn)數(shù)，則V(G)=P+1.獨(dú)立路徑：是指包括一組以前有沒有處理的語(yǔ)句或條件的一條路徑。等價(jià)類劃分是一種典型的黑盒測(cè)試方法。有效等價(jià)類：是指對(duì)于軟件的規(guī)格說明來說，合理的、有意義的輸入數(shù)據(jù)構(gòu)成的集合。利用它可以檢查程序是否實(shí)現(xiàn)了規(guī)格說明預(yù)先規(guī)定的功能和性能。無(wú)效等價(jià)類：是指對(duì)于軟件的規(guī)格說明來說，軟件測(cè)試過程的4步驟：?jiǎn)卧獪y(cè)試、組裝測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試。

驅(qū)動(dòng)模式：相當(dāng)于被測(cè)模塊的主程序。它接受測(cè)試數(shù)據(jù)，把這些數(shù)據(jù)傳送給被測(cè)模塊，最后再輸出實(shí)測(cè)結(jié)果。樁模塊：也叫存根模塊。用以代替被測(cè)模塊 把模塊組裝為系統(tǒng)的方式通常有：一次性組確認(rèn)測(cè)試又稱有效性測(cè)試。它的任務(wù)是驗(yàn)證軟件的有效性，即驗(yàn)證軟件的功能和性能及其他特征是否與用戶的要求一直。對(duì)軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定。

面向?qū)ο蠓治瞿Ｐ陀?個(gè)獨(dú)立的模型構(gòu)成：用類和對(duì)象表示的靜態(tài)模型（對(duì)象模型）；有狀態(tài)圖和順序圖表示的動(dòng)態(tài)模型（交互模型）。

以上3個(gè)模型的重要程度是不同的。用例模型是整個(gè)后續(xù)工作的基礎(chǔ)，也是測(cè)試與驗(yàn)收的依據(jù)。由于面向?qū)ο笙到y(tǒng)中，類、接口、及對(duì)象是軟件的基本組成單元，因此對(duì)象模型是必須建立的，也是核心模型，幾乎解決任何一個(gè)問題都需要從客觀世界實(shí)體及實(shí)體間的相互關(guān)系抽象出極有價(jià)值的對(duì)象模型；當(dāng)問題涉及交互作用和時(shí)序是，動(dòng)態(tài)模型是重要的。

復(fù)雜的大型系統(tǒng)的對(duì)象模型由5個(gè)層次組 在系統(tǒng)分析階段，對(duì)象建模的主要任務(wù)是建世界中的類與對(duì)象以及它們之間的關(guān)系，而非實(shí)際的軟件類或?qū)嶋H構(gòu)件。

軟件維護(hù)類型：改正性維護(hù)，適應(yīng)性維護(hù)，影響維護(hù)工作量的因素：1.系統(tǒng)規(guī)模；2.系4.數(shù)據(jù)庫(kù)技術(shù)的應(yīng)用水平；5.所采用的軟件開發(fā)技術(shù)及軟件開發(fā)工程化的程度；6.其他。針對(duì)三種典型的維護(hù)，提出策略以控制維護(hù)成本。改正性維護(hù)的策略方法：數(shù)據(jù)庫(kù)管理高級(jí)（第四代）語(yǔ)言。軟件維護(hù)性定義：指當(dāng)對(duì)軟件實(shí)施各種類型能力。軟件維護(hù)性子特性：易分析性，易變更性，提高軟件維護(hù)性的開發(fā)技術(shù)和工具：1.使用2.實(shí)施開發(fā)階段產(chǎn)品的維護(hù)性審查；3.改進(jìn)文檔。

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

軟件工程復(fù)習(xí)重點(diǎn)總結(jié)

1.(P-2)

Analysis:

decompose a large problem into smaller, understandable pieces，(一個(gè)大問題分解成更小的、可以理解部分)abstraction is the key Synthesis:

build(compose)software from smaller building blocks,(生成撰寫軟件從較小的構(gòu)造塊)composition is challenging 2Software Engineering Solving Problems(continued)：(P-4)

method： refers to a formal procedure（指的是一個(gè)正式的程序）

tool：an instrument or automated system for accomplishing something in a better way procedure（過程）：a combination of tools and techniques to produce a product（工具和技術(shù)來生產(chǎn)一種產(chǎn)品的組合）

paradigm（范例）：philosophy or approach for building a product 3.(P-6)

A fault: occurs when a human makes a mistake, called an error, in performing some software activities（在執(zhí)行某些軟件活動(dòng)）;

A failure: is a departure（偏差）from the system’s required behaviour;

Error can lead to fault；fault can lead to failure。4.participates in a project：(P-15)

Customer:

the company, organization, or person who pays for the software system Developer:

the company, organization, or person who is building the software system User: the person or people who will actually use the system

5.Activities and objects(P-16)– An activity is an event initiated by a trigger（活動(dòng)是由一個(gè)觸發(fā)器的事件）– Objects or entities are the elements involved in the activities（Objects 或?qū)嶓w是要素參與活動(dòng)的）

6.Relationships and the system boundaries(P-17)– A relationship defines the interaction among entities and activities（A 關(guān)系定義實(shí)體和活動(dòng)的相互作用）

– System boundaries determine the origin of input and destinations of the output（邊界確定輸入的來源與目的地的輸出）

7.a system as a collection of things :(P-17)a set of entities(一組實(shí)體), a set of activities , a description of the relationships among entities and activities and a definition of the system.8.The development of software includes the following activities(P-24)? ? ? ? Requirements analysis and definition System design Program design Writing the programs ? Unit testing ? Integration testing ? System testing ? System delivery ? Maintenance 9.developer roles(P-26)Analyst

Designer

Programmer

Tester

Trainer 10.(P-45)A process: a series of steps involving activities, constrains, and resources that produce an intended output of some kind（一系列步驟涉及活動(dòng)，受到了限制，及資源，產(chǎn)生一預(yù)期的輸出）

A process involves a set of tools and techniques 11.(P-46)

Software life cycle:

Implementation ,delivery ,use, and maintenance（實(shí)施、發(fā)布、使用及維修）

When a process involves building a software, the process may be referred to as software life cycle – – – – – – – Requirements analysis and definition System(architecture)design Program(detailed/procedural)design Writing programs(coding/implementation)Testing: unit, integration, system System delivery(deployment)Maintenance

12．software process models：（P-48）

Waterfall model

V model Prototyping model(原型化)Operational specification model Transformational model（轉(zhuǎn)化）

Phased development（階段化開發(fā)）: increments and iterations（反復(fù)遞增）Spiral model（螺旋模型）Agile methods（敏捷方法）

13.Prototyping is useful for verification(確認(rèn))and validation（驗(yàn)證）（P-51）14.Elements of a process are viewed in terms of seven types（P-64）

Activity – Sequence – Process model 過程模型 – – – – Resource Control Policy Organization

15.Project schedule(P-83)Describes the software-development cycle for a particular project by

enumerating the phases or stages of the project(枚舉階段或項(xiàng)目的階段)

breaking each phase into discrete tasks or activities to be completed(每個(gè)階段分成離散任務(wù)或活動(dòng)，以完成)

Portrays(描繪)the interactions(相互影響)among the activities and estimates(估算)the times that each task or activity will take

16.Activity and milestone(P-83)Activity: takes place over a period of time

Milestone: completion of an activity--a particular point in time

17.Critical Path Method(CPM)(P--87)

見作業(yè)

18.Key activities requiring personnel（P-95）

requirements analysis system design program design program implementation（實(shí)現(xiàn)，執(zhí)行）testing training maintenance

quality assurance（保證）

19.risk（P—119）

is an unwanted event that has negative consequences(消極結(jié)果)

20.Risk impact(影響):（P--120）

the loss associated with the event與該事件關(guān)聯(lián)的損失

Risk probability(概率):

the likelihood that the event will occur事件發(fā)生的可能性

Risk control(控制):

the degree to which we can change the outcome我們可以更改結(jié)果的程度

Quantify(量化)the effect of risks：

Risk exposure =(risk probability)x(risk impact)

21.Risk management：（P--121）

risk assessment（評(píng)估）

risk control

22.（P--143）

A requirement：

is an expression of desired behaviour是所需行為的表達(dá)式 A requirement deals with ：

objects or entities，the states they can be in，and the functions that are performed to change states or object characteristics

23.Process for Capturing Requirements（P--144）

Elicitation（引入）

Analysis

Specification Validation（驗(yàn)證）

////構(gòu)成了software requirements specification(說明書)

24.functional requirement（P---148）

describes required behavior in terms of required activitie描述所需的活動(dòng)所需的行為s Quality requirement or nonfunctional requirement describes some quality characteristic that the software must possess(擁有)

Design constraint(約束):

a design decision such as choice of platform or interface components設(shè)計(jì)的平臺(tái)或界面組件如選擇決策 Process constraint: a restriction on the techniques or resources that can be used to build the system 對(duì)技術(shù)或可用于構(gòu)建系統(tǒng)的資源限制

25.Prioritization might separate requirements into three categories（P--152）

Essential(基本): absolutely must be met絕對(duì)需要滿足的需求

Desirable(合意): highly desirable but not necessary非常理想，但不必須的 Optional(可選): possible but could be eliminated但可能被淘汰

26.Requirements definition:（P--154）

a complete listing of everything the customer wants to achieve完整列表的客戶希望實(shí)現(xiàn)的一切

Describing the entities in the environment where the system will be installed

描述在將安裝在系統(tǒng)環(huán)境中的實(shí)體 Requirements specification:

restates（重申）the requirements as a specification of how the proposed（提出）system shall behave

27.ER diagram have three core constructs（P--158）ER 圖表有三個(gè)核心構(gòu)造

An entity: depicted as a rectangle, represents a collection of real-world objects that have common properties and behaviors描述為一個(gè)的矩形表示一個(gè)實(shí)際

的對(duì)象的集合 具有公共屬性和行為

A relationship: depicted as an edge between two entities, with diamond in the middle of the edge specifying（指定）the type of relationship描述為一個(gè)兩個(gè)實(shí)體之間的邊緣

An attribute: an annotation(注解)on an entity that describes data or properties associated with the entity描述數(shù)據(jù)或與該實(shí)體相關(guān)聯(lián)的屬性的實(shí)體上的注釋

28.（P--172）

A data-flow diagram(DFD)models functionality and the flow of data from one function to another數(shù)據(jù)流關(guān)系圖 DFD 模型的功能和數(shù)據(jù)到另一個(gè)函數(shù)的流

– A buble represents a process一個(gè) buble 表示一個(gè)流程 – An arrow represents data flow一個(gè)箭頭表示數(shù)據(jù)流量

– A data store: a formal repository(倉(cāng)庫(kù))or database of information –

Rectangles represent actors: entities that provide input data or receive the output result矩形表示參與者： 實(shí)體提供輸入的數(shù)據(jù)或接收輸出結(jié)果

–

29.(P--223)Design: is the creative process of transforming the problem into a solution The description of a solution is also known as design 是創(chuàng)造過程的問題轉(zhuǎn)化為解決方案的描述稱為設(shè)計(jì)

30.Design is a two-part interactive process(P—224)– Conceptual design(system design)(概念性設(shè)計(jì))– Technical design(技術(shù)性設(shè)計(jì))

–

31.(P—228)Modules or components: 組件

composite parts of design A system is modular when

– each activity of the system is performed by exactly one component活動(dòng)的系統(tǒng)由一個(gè)組件執(zhí)行

– inputs and outputs of each component are well-defined

? all inputs to it are essential to its function輸入其功能至關(guān)重要

? all outputs are produced by one of its actions輸出由其動(dòng)作之一制作

32.Architectural Styles and Strategies Three Design Levels:(P—229)

Architecture（系統(tǒng)結(jié)構(gòu)）

Code design

Executable design（執(zhí)行設(shè)計(jì)）

33.Architectural Styles and Strategies Design Styles（P—230）

Pipes and filters(管道/過濾器)Object-oriented design Implicit invocation(隱式調(diào)用)Layering（分層設(shè)計(jì)）Repositories(數(shù)據(jù)倉(cāng)庫(kù))Interpreters(解釋器)Process control(過程控制)Client-server(客戶/服務(wù)器)

34.Component independence（P--248）

Coupling(耦合度)Cohesion(內(nèi)聚度)Highly coupled when there is a great deal of dependencies Loosely coupled components have some dependency, but the interconnections among components are weak（大多數(shù)采用松散）

Uncoupled components have no interconnections at all

35.We can measure coupling along a range of dependence（P--249）

Characteristics of Good Design Coupling: Types of Coupling

Content(內(nèi)容)coupling

Common(公共)coupling Control(控制)coupling Stamp(標(biāo)記)coupling Data(數(shù)據(jù))coupling 36.Exceptions can be handled in one of three ways：（P—255）異常處理

– Retry(重試)– Correct(更正)– Report(報(bào)告)

37.program component involves at least three major aspect:(P---340)

Control structures ,algorithms,and data structure 38.making the codeefficiency(效率)may have hidden costs(代價(jià))(P--342)– cost to write the code faster – cost to test the code – cost to understand the code – cost to modify the code

39.Software Faults and Failures types of Faults(P--367)軟件故障及故障的類型的故障

Algorithmic fault算法

Computation and precision fault 計(jì)算和精度 Documentation fault Stress or overload faults Capacity or boundary faults 容量邊界 Timing or coordination faults(協(xié)調(diào))Throughput(吞吐量)or Performance faults Recovery fault 恢復(fù)故障

Hardware and system software fault Standards and procedures fault

40.Testing Organization（P—371.）

Module testing, component testing, or unit testing(單元測(cè)試)Integration testing(集成測(cè)試)The next step is ensuring that the interfaces among the components are defined and handled properly.Performance testing(性能測(cè)試)Compares the system with the remainder of these software an hardware requirements.41.Testing steps（P--372）

42.Integration Testing集成測(cè)試（P--390）具體實(shí)例見作業(yè)

Bottom-up(自底向上)

Merging components to test the larger system

Top-down(自頂向下)

Big-bang(大棒)

Sandwich testing(多層結(jié)構(gòu)測(cè)試)

Modified top-down(改性自上而下)

Modified sandwich(改性多層結(jié)構(gòu)測(cè)試)

43.Principles of System Testing Regression Testing Steps（P—425）系統(tǒng)測(cè)試回歸測(cè)試步驟的原則

? Inserting the new code ? Testing functions known to be affected by the new code ? Testing essential function of m to verify that they still work properly整體 ? Continuing function testing m + 1

44.Types of Performance Tests（P--436）性能測(cè)試

Stress tests(壓力)Volume tests(容量)Configuration tests(配置)Compatibility tests(兼容)

Regression tests(回歸)Security tests(安全)Timing tests(響應(yīng)時(shí)間)Environmental tests(環(huán)境)Quality tests(質(zhì)量)Recovery tests(恢復(fù))Maintenance tests(可維護(hù)性)Documentation tests(文檔)Human factors(usability)tests(使用)

45.Software reliability:

operating without failure under given condition for a given time interval 無(wú)故障下經(jīng)營(yíng)給予指定的時(shí)間間隔內(nèi)的條件 Software availability:

operating successfully according to specification at a given point in time 成功經(jīng)營(yíng)，依法規(guī)范在指定點(diǎn)的時(shí)間 Software maintainability:

for a given condition of use, a maintenance activity can be carried out within stated time interval, procedures and resources 為給定的使用條件，維護(hù)活動(dòng)可以內(nèi)進(jìn)行既定的時(shí)差 過程資源

注意：作業(yè)是重點(diǎn)，必考！這個(gè)翻譯（長(zhǎng)字段的）僅供參考，要結(jié)合軟件工程的角度加以分析理解！

第四篇：軟件工程復(fù)習(xí)重點(diǎn)總結(jié)

第一章

軟件過程：需求設(shè)計(jì)實(shí)現(xiàn)發(fā)布

軟件過程三要素: 過程+方法+工具

瀑布rup scrum Iconix

Scrum是一種迭代式增量軟件開發(fā)過程，通常用于敏捷軟件開發(fā)。Product Owner、Scrum Master、Team Product Backlog、SprintBacklog、Burndown Chart、Sprint、Sprint Planning Meeting、Daily Standup Meeting、Review Meeting、Retrospective Meeting ICONIX軟件開發(fā)過程

愿景、業(yè)務(wù)建模、需求分析、健壯性分析、系統(tǒng)設(shè)計(jì)??

思想是重點(diǎn)；過程是方式；方法和工具是載體

第二章

敏捷開發(fā)是一種以人為核心、迭代、循序漸進(jìn)的開發(fā)方法。敏

捷是一種思想?Scrum是一個(gè)框架

敏捷開發(fā)過程知多少？

?Scrum、?極限編程（XP）、?Crystal Methods（水晶方法族）

?特性驅(qū)動(dòng)開發(fā)（FDD）

?動(dòng)態(tài)系統(tǒng)開發(fā)（DSDM）

?輕量型統(tǒng)一過程（RUP）

調(diào)查結(jié)果：敏捷開發(fā)方法—Scrum最流行！

Scrum的適用場(chǎng)景

?7人，+or-2

?偏小一些會(huì)更適合?最好能坐在一起

?客戶參不度高

?快速移動(dòng)互聯(lián)網(wǎng)項(xiàng)目

?自主性研發(fā)的產(chǎn)品

第三章

軟件項(xiàng)目是為了改善某個(gè)組織的某些方面

–老大就是要改善的組織中最有權(quán)力的干系人。

用戶建模四步曲列出盡可能多的用戶識(shí)別關(guān)鍵用戶（購(gòu)買決策者/主要使用者）分類，合并次要用戶

4添加虛擬和極端用戶

第四章

?產(chǎn)品backlog是Scrum的核心

產(chǎn)品功能列表格式

?ID（標(biāo)示符）

–統(tǒng)一標(biāo)識(shí)符

?Name（標(biāo)題）

–簡(jiǎn)短的、描述性的故事名

?Story（故事）

–故事內(nèi)容描述

?Priority（重要性）

–產(chǎn)品負(fù)責(zé)人評(píng)出一個(gè)數(shù)值，指示這個(gè)故事有多重要

?Initial estimate（初始估計(jì)）

–團(tuán)隊(duì)的初步估算，表示不其他故事相比，完成該故事所需的工作量

?How to demo（如何做演示）

–它大略描述了這個(gè)故事應(yīng)該如何在sprint 演示上進(jìn)行示范

?Notes（注解）

–相關(guān)信息、解釋說明和對(duì)其它資料的引用等等

產(chǎn)品功能列表由誰(shuí)來寫？

?思考：由誰(shuí)來寫？

–主要是Product Owner

–Team也有權(quán)利，但最終由PO進(jìn)行取舍。

用戶故事是一種敏捷的需求挖掘方式，其側(cè)重點(diǎn)不是將需求書寫出來，而是將需求討論出來。

按“作為一個(gè)??，可以??，以便??”樣式和思路寫成的用戶需求，就是用戶故事。

用戶故事的三個(gè)變量

范圍，重要性，估算

好故事的準(zhǔn)則

?獨(dú)立的（Independ）

?可討論的（Negotiable）

?對(duì)用戶戒客戶有價(jià)值的（Valuable）

?可估計(jì)的（Estimatable）

?小的（Small）

?可測(cè)試的（Testable）

Sprint會(huì)議如何迚行

–確定Sprint目標(biāo)及長(zhǎng)度

–講解Story、估算時(shí)間、任務(wù)分解

–決定 sprint 要包含的故事

–一些其他問題

第六章

什么是界面原型

?界面原型指使用工具根據(jù)客戶需求及軟件分析人員的理解，將頭腦中的界面快速的反映到介質(zhì)上。

界面原型的目的?盡早驗(yàn)證需求

?盡早明確不確定性的因素

?方便溝通交流

?為后續(xù)界面設(shè)計(jì)提供基礎(chǔ)

第八章

ICONIX過程

?ICONIX過程的規(guī)模介于RUP和XP之間

?適合中小型的、需求相對(duì)明確的軟件項(xiàng)目

?ICONIX核心思想

?開源！節(jié)流！

ICONIX軟件過程是用例驅(qū)動(dòng)的軟件過程。

ICONIX過程中的第一步：明確愿景

?愿景是確保項(xiàng)目成功的第一步；

?愿景必須來自老大；

?愿景必須是可度量。

如何獲取軟件項(xiàng)目的愿景

?獲取軟件項(xiàng)目愿景的三步曲：

?第一步：找到軟件項(xiàng)目的“老大”；

?第二步：得到“老大”對(duì)項(xiàng)目的期望（愿景）；

?第三步：描述出愿景的度量指標(biāo)；

要點(diǎn)：系統(tǒng)要改善哪個(gè)組織的流程？

老大就是要改善的組織中最有權(quán)力的干系人

第九章

業(yè)務(wù)建模的目的：從組織的角度來定位系統(tǒng)的價(jià)值。

業(yè)務(wù)建模

?業(yè)務(wù)建模的目的是把視角從系統(tǒng)轉(zhuǎn)向組織，站在客戶角度看問題。

?業(yè)務(wù)用例是對(duì)組織為外部業(yè)務(wù)執(zhí)行者提供的價(jià)值的建模。

?現(xiàn)狀業(yè)務(wù)序列圖是對(duì)組織價(jià)值內(nèi)部實(shí)現(xiàn)流程（業(yè)務(wù)工人與業(yè)務(wù)實(shí)體的協(xié)作）的建模 ?改迚業(yè)務(wù)序列圖是對(duì)新系統(tǒng)為組織提供的改良的建模。

業(yè)務(wù)建模的步驟：

1.明確我們?yōu)檎l(shuí)服務(wù)（選定愿景要改進(jìn)的組織）。

2.要改進(jìn)的組織是什么現(xiàn)狀（業(yè)務(wù)用例圖、現(xiàn)狀業(yè)務(wù)序列圖）。

3.我們?nèi)绾胃倪M(jìn)（改進(jìn)業(yè)務(wù)序列圖）。

第十章

域建模的步驟

第一步：提取名詞或名詞短語(yǔ)

第二步：排除重復(fù)、相似

第三步：排除系統(tǒng)范圍外

第四步：畫出第一版域模型圖

第五步：整理第一版域模型

域模型之間的關(guān)系

?泛化[Generalization]，一般元素和特殊元素的關(guān)系。

?關(guān)聯(lián)[Association]，兩個(gè)類乊間存在著某種語(yǔ)義上的聯(lián)系。

系統(tǒng)需求分析的目的是把視角轉(zhuǎn)向新系統(tǒng)，站在最織

用戶（及其它干系人）的角度看問題。

?系統(tǒng)用例是對(duì)（新）系統(tǒng)為系統(tǒng)執(zhí)行者提供的價(jià)值的建模

系統(tǒng)用例建模步驟

1.繪制系統(tǒng)用例圖

2.編寫系統(tǒng)用例描述

3.更新域模型

繪制系統(tǒng)用例圖

1.確定系統(tǒng)邊界

2.識(shí)別系統(tǒng)執(zhí)行者

3.識(shí)別系統(tǒng)用例

4.確定用例間的關(guān)系

用例描述的作用

?用例圖描述總體，用例文檔描述紳節(jié)。

?每個(gè)用例必須對(duì)應(yīng)有用例描述。

用例描述的基本組成?干系人利益

?基本路徑

?擴(kuò)展路徑

?業(yè)務(wù)觃則

軟件產(chǎn)品的典型非功能性需求(RUPS)

?可靠性[Reliability]。

?可用性[Usability]。

?性能[Performance]。

?可支持性[Supportability]。

需求獲取的方法

?研究文檔。

?問卷調(diào)查。

?訪談。

?觀察。

?研究競(jìng)爭(zhēng)對(duì)手。

需求分析結(jié)果復(fù)核

?形式：面對(duì)面會(huì)議。

?參會(huì)人：甲乙雙方在需求分析階段的主要參與者。

?被審材料：域模型、用例圖、用例描述、非功能性需求；

?過程：需求分析師主持，最終需求分析成果，所有參與者交流討論，達(dá)成統(tǒng)一理解和確認(rèn)。?結(jié)論：所有參與者簽字確認(rèn)。（當(dāng)然，也有可能是未達(dá)成共識(shí)，需要返工。）

?注意：后續(xù)的工作基本不需要用戶的參不了。

第十一章

健壯性分析的步驟

第一步：創(chuàng)建一個(gè)空的健壯性圖。

第三步：從基本路徑的第一句話開始畫健壯性圖。

第二步：直接將用例文本粘貼到圖上（基本路徑和擴(kuò)展路徑）。

第四步：貫串整個(gè)用例基本路徑，一次一個(gè)句子，畫執(zhí)行者、適當(dāng)?shù)倪吔鐚?duì)象和實(shí)體對(duì)象以及控制器，和各元素乊間的連線。

第五步：將每一個(gè)擴(kuò)展路徑畫在健壯性圖上，并以紅色標(biāo)示出。

在用例驅(qū)動(dòng)的開發(fā)模式中，用例的準(zhǔn)確完整性是關(guān)鍵；

?健壯性分析技術(shù)兩個(gè)主要的價(jià)值：其一幫助完善用例分析結(jié)果；其二完善域模型，做為需求分析走向系統(tǒng)設(shè)計(jì)的過度技術(shù)；

?丌要花費(fèi)太多的精力和時(shí)間在本階段，本階段的成果也僅起到過度作用，不納入最終文檔； 第十二章

關(guān)鍵設(shè)計(jì)是功能性需求的設(shè)計(jì)，成果為類圖和序列圖；

?關(guān)鍵設(shè)計(jì)還沒考慮真實(shí)實(shí)現(xiàn)的平臺(tái)相關(guān)因素，因此不能基于這個(gè)階段的設(shè)計(jì)成果開始編碼； ?關(guān)鍵設(shè)計(jì)的方法就是在域模型、用例描述和健壯性分析的基礎(chǔ)上，迭代生成類圖和序列圖；

關(guān)鍵設(shè)計(jì)的步驟

?第一步：將現(xiàn)有的域模型直接作為第一版靜態(tài)類模型；

?第二步：基于用例描述和健壯性分析結(jié)果，畫出每個(gè)用例的序列圖；

?健壯性圖中的控制類會(huì)轉(zhuǎn)化為方法；

?如果也轉(zhuǎn)化為控制類，那么就添加到類圖中（注意：邊界類丌添加到類圖中）； ?第三步：整理靜態(tài)類圖和序列圖；

?第四步：關(guān)鍵設(shè)計(jì)復(fù)核，迭代更新用例圖、類圖和序列圖；

高內(nèi)聚、低耦合。是判斷設(shè)計(jì)好壞的標(biāo)準(zhǔn)。

關(guān)鍵設(shè)計(jì)復(fù)核的指導(dǎo)建議

?確保關(guān)鍵設(shè)計(jì)的“如何做”和需求階段的“做什么”匹配。也就是說每個(gè)用例都要和序列圖匹配，包含了用例的基本流程和分支流程。

?復(fù)核設(shè)計(jì)的品質(zhì)。應(yīng)該至少有一個(gè)設(shè)計(jì)與家在場(chǎng)。

?檢查消息的連貫性。檢查時(shí)序圖上消息箭頭的指向，有時(shí)我們會(huì)發(fā)現(xiàn)對(duì)象乊間缺少消息而造成跳躍，我們必須消除這些邏輯跳躍。

?確保方法分配給了適當(dāng)?shù)念悾愐晥D中的每一個(gè)類擁有適當(dāng)?shù)姆椒ê蛯傩浴?/p>

第五篇：軟件工程重點(diǎn)整理

可以把軟件開發(fā)的本質(zhì)概括為：不同抽象層術(shù)語(yǔ)之間，以及不同抽象層處理邏輯之間的映射 需求分析產(chǎn)生的正式文檔是需求規(guī)約

在結(jié)構(gòu)化分析方法中，表示“數(shù)據(jù)的靜態(tài)結(jié)構(gòu)”的術(shù)語(yǔ)是數(shù)據(jù)存儲(chǔ)

對(duì)模塊的寬度影響最大的因素是模塊的扇出 下列術(shù)語(yǔ)，可用于抽象客觀世界中事物的是類

大學(xué)由若干專業(yè)系構(gòu)成，則大學(xué)與專業(yè)的關(guān)系是組合

下列軟件測(cè)試技術(shù)中，依據(jù)程序邏輯結(jié)構(gòu)的是白盒測(cè)試技術(shù) 單元測(cè)試期間，通?？紤]模塊的重要的執(zhí)行路徑

軟件基本過程指那些與軟件生產(chǎn)直接相關(guān)的活動(dòng)集，可分為供應(yīng)過程、開發(fā)過程、運(yùn)行過程、維護(hù)過程和獲取過程

在常見的軟件開發(fā)模型中，適用于項(xiàng)目的開發(fā)風(fēng)險(xiǎn)很大或客戶不能確定系統(tǒng)需求的模型是螺旋模型

CMMI 能力等級(jí)中的 3 級(jí)是已定義級(jí)

軟件生產(chǎn)率、軟件質(zhì)量滿足不了社會(huì)發(fā)展的需求，并成為其發(fā)展的制約因素，這一現(xiàn)象被稱為軟件危機(jī)

對(duì)于單一的一個(gè)需求，必須具有的基本性質(zhì)：必要的、無(wú)歧義的、可測(cè)試的、可跟蹤的以及可測(cè)量的。

需求規(guī)約的基本性質(zhì)包括重要性和穩(wěn)定性程度、可修改的、完整的和一致的

在結(jié)構(gòu)化分析方法中，可采用結(jié)構(gòu)化自然語(yǔ)言、判定表和判定樹描述加工

用于定義數(shù)據(jù)流圖包含的所有數(shù)據(jù)流和數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)，直到給出構(gòu)成以上數(shù)據(jù)的各數(shù)據(jù)項(xiàng)的基本數(shù)據(jù)類型的工具是數(shù)據(jù)字典

在 UML 中，用于描述關(guān)聯(lián)的一定“內(nèi)涵”的術(shù)語(yǔ)是關(guān)聯(lián)名 RUP 利用 UML 提供的術(shù)語(yǔ)和工具定義了需求獲取層、系統(tǒng)分析層、設(shè)計(jì)層和實(shí)現(xiàn)層，并給出了實(shí)現(xiàn)各層模型之間映射的基本活動(dòng)以及相關(guān)的指導(dǎo)

軟件測(cè)試是一個(gè)有程序的過程，包括測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行以及測(cè)試結(jié)果比較等

由于軟件錯(cuò)誤的復(fù)雜性，在軟件工程測(cè)試中，應(yīng)綜合運(yùn)用測(cè)試技

術(shù)，并且應(yīng)實(shí)施合理的測(cè)試序列：

單元測(cè)試、集成測(cè)試、有效性測(cè)試和系統(tǒng)測(cè)試

《IS0/IEC 軟件生存周期過程 12207—1995》標(biāo)準(zhǔn)按過程主體把軟件生存周期過程分為基本過程、支持過程和組織過程 針對(duì)開發(fā)的 CMMI 是一個(gè)有關(guān)產(chǎn)品和服務(wù)的過程改善的成熟度模型，集成了 3 個(gè)源模型：軟件 CMM、系統(tǒng)工程 CMM和產(chǎn)品集成開發(fā) CMM

CMMI 中，遵循一個(gè)過程可達(dá)到的預(yù)期結(jié)果的程度是指過程能力

CMMI 模型基于過程途徑思想，通過過程把軟件質(zhì)量的 3 個(gè)支撐點(diǎn)：受訓(xùn)的人員、規(guī)程和方法、工具和設(shè)備進(jìn)行集成，以開發(fā)所期望的系統(tǒng)/產(chǎn)品

請(qǐng)簡(jiǎn)述計(jì)算機(jī)軟件的概念以及提出軟件工程概念的目的

（1）計(jì)算機(jī)軟件一般是指計(jì)算機(jī)系統(tǒng)中的程序及其文檔（2）其中，程序是計(jì)算機(jī)任務(wù)的處理對(duì)象和處理規(guī)則的描述（3）文檔是為了理解程序所需的闡述性資料（4）軟件工程概念的提出，其目的是倡導(dǎo)以工程的原理、原則和方法進(jìn)行軟件開發(fā)，以解決出現(xiàn)的軟件危機(jī)。

請(qǐng)簡(jiǎn)述初始發(fā)現(xiàn)需求的常用技術(shù)（1）自悟（2）交談（3）觀察（4）小組會(huì)（5）提煉

請(qǐng)敘述信息隱藏的概念及其意義

（1）信息隱藏是指在每個(gè)模塊中所包含的信息不允許其他不需要這些信息的模塊訪問（2）它是實(shí)現(xiàn)模塊低耦合的一種有效途徑（3）但是，如果一個(gè)模塊是“絕對(duì)”信息隱藏的，那么這種模塊對(duì)系統(tǒng)而言是毫無(wú)意義的

什么是驗(yàn)證和確認(rèn)？請(qǐng)敘述它們的區(qū)別

（1）驗(yàn)證就是證實(shí)一個(gè)過程或項(xiàng)目的每一軟件工作產(chǎn)品/服務(wù)是否正確地反映了所規(guī)約的需求（2）確認(rèn)就是證實(shí)所期望使用的軟件工作產(chǎn)品是否滿足其需求（3）區(qū)別：驗(yàn)證是通過提供的客觀證據(jù)，證實(shí)規(guī)約的需求是否得以滿足；確認(rèn)是通過提供的客觀證據(jù)，證實(shí)有關(guān)特定期望的使用或應(yīng)用的需求是否得以滿足