第一篇：軟件工程導(dǎo)論復(fù)習(xí)重點總結(jié)很全(第六版)(精)

第1章軟件工程學(xué)概述 1.1 軟件危機(jī) 1.1.1 軟件危機(jī)的介紹

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

軟件危機(jī)包含下述兩方面的問題: 如何開發(fā)軟件,滿足對軟件日益增長的需求;如何維護(hù)數(shù)量不斷膨脹的已有軟件。軟件危機(jī)的典型表現(xiàn):(1對軟件開發(fā)成本和進(jìn)度的估計常常很不準(zhǔn)確;(2用戶對“已完成的”軟件系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生;(3軟件產(chǎn)品的質(zhì)量往往靠不住;(4軟件常常是不可維護(hù)的;(5軟件通常沒有適當(dāng)?shù)奈臋n資料;(6軟件成本在計算機(jī)系統(tǒng)總成本中所占的比例逐年上升;(7軟件開發(fā)生產(chǎn)率提高的速度,遠(yuǎn)遠(yuǎn)跟不上計算機(jī)應(yīng)用迅速普及深入的趨勢。1.1.2 產(chǎn)生軟件危機(jī)的原因(1與軟件本身的特點有關(guān)

(2與軟件開發(fā)與維護(hù)的方法不正確有關(guān)

1.1.3 消除軟件危機(jī)的途徑 對計算機(jī)軟件有正確的認(rèn)識。

認(rèn)識到軟件開發(fā)是一種組織良好、管理嚴(yán)密、各類人員協(xié)同配合、共同完成的工程項目。應(yīng)該推廣使用在實踐中總結(jié)出來的開發(fā)軟件的成功技術(shù)和方法,并繼續(xù)研究探索。

應(yīng)該開發(fā)和使用更好的軟件工具。

總之,為了解決軟件危機(jī),既要有技術(shù)措施(方法和工具,又要有必要的組織管理措施。

1.2 1.2.1 軟件工程的介紹

軟件工程:是指導(dǎo)計算機(jī)軟件開發(fā)和維護(hù)的一門工程學(xué)科。采用工程的概念、原理、技術(shù)和方法來開發(fā)與維護(hù)軟件,把經(jīng)過時間考驗而證明正確的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來,以經(jīng)濟(jì)地開發(fā)出高質(zhì)量的軟件并有效地維護(hù)它,這就是軟件工程。(期中考

軟件工程的本質(zhì)特性: 軟件工程關(guān)注于大型程序的構(gòu)造 軟件工程的中心課題是控制復(fù)雜性 軟件經(jīng)常變化

開發(fā)軟件的效率非常重要 和諧地合作是開發(fā)軟件的關(guān)鍵 軟件必須有效地支持它的用戶

在軟件工程領(lǐng)域中是由具有一種文化背景的人替具有另一種文化背景的人創(chuàng)造產(chǎn)品

1.2.2 軟件工程的基本原理 用分階段的生命周期計劃嚴(yán)格管理 堅持進(jìn)行階段評審 實行嚴(yán)格的產(chǎn)品控制 采用現(xiàn)代程序設(shè)計技術(shù) 結(jié)果應(yīng)能清楚地審查 開發(fā)小組的人員應(yīng)該少而精

承認(rèn)不斷改進(jìn)軟件工程實踐的必要性 1.2.3 軟件工程方法學(xué)

軟件工程包括技術(shù)和管理兩方面的內(nèi)容。軟件工程方法學(xué)3要素:方法、工具、過程

1.傳統(tǒng)方法學(xué)(生命周期方法學(xué)或結(jié)構(gòu)化范型——強(qiáng)調(diào)自頂向下 2.面向?qū)ο蠓椒▽W(xué)——強(qiáng)調(diào)主動地多次反復(fù)迭代 面向?qū)ο蠓椒▽W(xué)4個要點:對象、類、繼承、消息 1.3 軟件生命周期(必考

三個時期八個階段:軟件生命周期由軟件定義、軟件開發(fā)和運行維護(hù)(也稱為軟件維護(hù)三個時期組成,每個時期又進(jìn)一步劃分成若干個階段。

三個時期:八個階段: 軟件生命周期軟件定義 軟件開發(fā) 軟件維護(hù) 問題定義 可行性研究 需求分析 概要設(shè)計 詳細(xì)設(shè)計 編碼和單元測試 綜合測試

運行維護(hù) 系統(tǒng)設(shè)計 系統(tǒng)實現(xiàn) 1.4 軟件過程 1.4.1 瀑布模型

1.4.2 快速原型模型 1.4.3 增量模型 1.4.4 螺旋模型 1.4.5 噴泉模型 第2章可行性研究 2.1可行性研究的任務(wù) 可行性研究的目的: 不是解決問題,而是確定問題是否值得去解決。可行性研究的實質(zhì): 進(jìn)行一次大大壓縮簡化了的系統(tǒng)分析和設(shè)計的過程,也就是在較高層次上以較抽象的方式進(jìn)行的系統(tǒng)分析和設(shè)計的過程。

可行性研究的內(nèi)容: 首先進(jìn)一步分析和澄清問題定義,導(dǎo)出系統(tǒng)的邏輯模型;然后從系統(tǒng)邏輯模型出發(fā),探索若干種可供選擇的主要解法(即系統(tǒng)實現(xiàn)方案;對每種解法都研究它的可行性,至少應(yīng)該從三方面研究每種解法的可行性。主要方面: 技術(shù)可行性,經(jīng)濟(jì)可行性,操作可行性, 其他方面: 運行可行性,法律可行性，2.2 可行性研究過程 1.復(fù)查系統(tǒng)規(guī)模和目標(biāo) 2.研究目前正在使用的系統(tǒng) 3.導(dǎo)出新系統(tǒng)的高層邏輯模型 4.進(jìn)一步定義問題 5.導(dǎo)出和評價供選擇的解法 6.推薦行動方針 7.草擬開發(fā)計劃 8.書寫文檔提交審查 2.3 系統(tǒng)流程圖

系統(tǒng)流程圖:是概括地描繪物理系統(tǒng)的傳統(tǒng)工具。表達(dá)的是數(shù)據(jù)在系統(tǒng)各部件之間流動的情況,而不是對數(shù)據(jù)進(jìn)行加工處理的控制過程。

2.4數(shù)據(jù)流圖 2.4.1符號 基本符號:

數(shù)據(jù)存儲:數(shù)據(jù)存儲是處于靜止?fàn)顟B(tài)的數(shù)據(jù);數(shù)據(jù)流:數(shù)據(jù)流是處于運動中的數(shù)據(jù)。附加符號: 星號(*:表示“與”關(guān)系 加號(+:表示“或”關(guān)系 異或(⊕:表示互斥關(guān)系 2.5數(shù)據(jù)字典

數(shù)據(jù)流圖和數(shù)據(jù)字典共同構(gòu)成系統(tǒng)的邏輯模型。2.5.1 數(shù)據(jù)字典的內(nèi)容

數(shù)據(jù)字典的組成:數(shù)據(jù)流數(shù)據(jù)流分量(即數(shù)據(jù)元素 數(shù)據(jù)存儲處理 2.5.2定義數(shù)據(jù)的方法 方法:對數(shù)據(jù)自頂向下分解。

數(shù)據(jù)組成方式(三種基本類型:順序選擇重復(fù)附加類型:可選 符號: =意思是等價于(或定義為;+意思是和(即,連接兩個分量;[]意思是或(即,從方括弧內(nèi)列出的若干個分量中選擇一個,通常用“|”號隔開供選擇的分量;{ }意思是重復(fù)(即,重復(fù)花括弧內(nèi)的分量;常常使用上限和下限進(jìn)一步注釋表示重復(fù)的花括弧。

(意思是可選(即,圓括弧里的分量可有可無。2.5.3數(shù)據(jù)字典的實現(xiàn) 計算機(jī)實現(xiàn)人工實現(xiàn) 2.6成本/效益分析

2.6.1 成本估計:1.代碼行技術(shù) 2.任務(wù)分解技術(shù) 3.自動估計成本技術(shù) 2.6.2 成本/效益分析的方法 成本/效益分析涉及的4個概念: 1.貨幣的時間價值 2.投資回收期 3.純收入

4.投資回收率:P = F1/(1 + j + F2/(1 + j 2 + …+ Fn(1 + j n 第3章需求分析 需求分析的任務(wù): 需求分析是軟件定義時期的最后一個階段,它的基本任務(wù)是準(zhǔn)確地回答“系統(tǒng)必須做什么?”這個問題。

確定系統(tǒng)必須完成哪些工作,也就是對目標(biāo)系統(tǒng)提出完整、準(zhǔn)確、清晰、具體的要求。

系統(tǒng)分析員應(yīng)該寫出軟件需求規(guī)格說明書,以書面形式準(zhǔn)確地描述軟件需求 3.1需求分析的任務(wù) 確定對系統(tǒng)的綜合要求 分析系統(tǒng)的數(shù)據(jù)要求 導(dǎo)出系統(tǒng)的邏輯模型 修正系統(tǒng)開發(fā)計劃

3.1.1確定對系統(tǒng)的綜合要求 1.功能需求 2.性能需求

3.可靠性和可用性需求 4.出錯處理需求 5.接口需求

6.約束 7.逆向需求

8.將來可能提出的要求 3.1.2 分析系統(tǒng)的數(shù)據(jù)要求 建立數(shù)據(jù)模型——ER圖

描繪數(shù)據(jù)結(jié)構(gòu)——層次方框圖和Warnier圖 數(shù)據(jù)結(jié)構(gòu)規(guī)范化

3.2 與用戶溝通獲取需求的方法

訪談:1.正式訪談 2.非正式訪談 3.調(diào)查表 4.情景分析技術(shù) 面向數(shù)據(jù)流自頂向下求精 簡易的應(yīng)用規(guī)格說明技術(shù)

快速建立軟件原型:(1 第四代技術(shù)(4GL(2 可重用的軟件構(gòu)件(3 形式化規(guī)格說明和原型環(huán)境

3.3分析建模與規(guī)格說明 3.3.1 分析建模

需求分析過程應(yīng)該建立3種模型:數(shù)據(jù)模型功能模型行為模型 數(shù)據(jù)字典是分析模型的核心

實體-聯(lián)系圖用于建立數(shù)據(jù)模型的圖形 數(shù)據(jù)流圖是建立功能模型的基礎(chǔ)

狀態(tài)轉(zhuǎn)換圖是行為建模的基礎(chǔ) 3.4實體-聯(lián)系圖

數(shù)據(jù)模型中包含3種相互關(guān)聯(lián)的信息:數(shù)據(jù)對象、數(shù)據(jù)對象的屬性、數(shù)據(jù)對象彼此間相互連接的關(guān)系

3.4狀態(tài)轉(zhuǎn)換圖 3.6.1狀態(tài) 狀態(tài)圖分類: 表示系統(tǒng)循環(huán)運行過程,通常不關(guān)心循環(huán)是怎樣啟動的。表示系統(tǒng)單程生命期,需要標(biāo)明初始狀態(tài)和最終狀態(tài)。3.6.2事件

事件就是引起系統(tǒng)做動作或(和轉(zhuǎn)換狀態(tài)的控制信息。3.6.3符號

3.7其他圖形工具 3.7.1 層次方框圖 3.7.2Warnier圖 3.7.3IPO圖

3.8驗證軟件需求(重點

3.8.1 從哪些方面驗證軟件需求的正確性 一致性完整性現(xiàn)實性有效性 第五章總體設(shè)計 5.1設(shè)計過程 由兩個主要階段組成: 系統(tǒng)設(shè)計階段,確定系統(tǒng)的具體實現(xiàn)方案:設(shè)想供選擇的方案選取合理的方案推薦最佳方案

結(jié)構(gòu)設(shè)計階段,確定軟件結(jié)構(gòu):功能分解設(shè)計軟件結(jié)構(gòu)設(shè)計數(shù)據(jù)庫制定測試文檔書寫文檔審查和復(fù)查

5.2設(shè)計原理 5.2.1 模塊化 模塊化的作用: 采用模塊化原理可以使軟件結(jié)構(gòu)清晰,不僅容易設(shè)計也容易閱讀和理解。模塊化使軟件容易測試和調(diào)試,因而有助于提高軟件的可靠性。模塊化能夠提高軟件的可修改性。

模塊化也有助于軟件開發(fā)工程的組織管理。5.2.2抽象 5.2.3逐步求精

5.2.4信息隱藏和局部化 5.2.5 模塊獨立 盡量使用數(shù)據(jù)耦合, 少用控制耦合和特征耦合, 限制公共環(huán)境耦合的范圍, 完全不用內(nèi)容耦合。七種內(nèi)聚的優(yōu)劣評分結(jié)果: 高內(nèi)聚:功能內(nèi)聚 順序內(nèi)聚 中內(nèi)聚:通信內(nèi)聚 過程內(nèi)聚 低內(nèi)聚:時間內(nèi)聚 邏輯內(nèi)聚 偶然內(nèi)聚 5.3啟發(fā)規(guī)則

1.改進(jìn)軟件結(jié)構(gòu)提高模塊獨立性 2.模塊規(guī)模應(yīng)該適中

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

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

5.力爭降低模塊接口的復(fù)雜程度 6.設(shè)計單入口單出口的模塊 7.模塊功能應(yīng)該可以預(yù)測 5.4 描繪軟件結(jié)構(gòu)的圖形工具 5.4.1 層次圖和HIPO圖 1.層次圖(H圖

層次圖用來描繪軟件的層次結(jié)構(gòu)。很適于在自頂向下設(shè)計軟件的過程中使用。2.HIPO圖 5.4.2結(jié)構(gòu)圖

5.5面向數(shù)據(jù)流的設(shè)計方法

結(jié)構(gòu)化設(shè)計方法(簡稱SD方法,也就是基于數(shù)據(jù)流的設(shè)計方法。5.5.1概念

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

第6章詳細(xì)設(shè)計 6.1 結(jié)構(gòu)程序設(shè)計 經(jīng)典的結(jié)構(gòu)程序設(shè)計: 只允許使用順序、IF-THEN-ELSE型分支和DO-WHILE型循環(huán)這3種基本控制結(jié)構(gòu);擴(kuò)展的結(jié)構(gòu)程序設(shè)計: 如果除了上述3種基本控制結(jié)構(gòu)之外,還允許使用DO-CASE型多分支結(jié)構(gòu)和DO-UNTIL型循環(huán)結(jié)構(gòu);修正的結(jié)構(gòu)程序設(shè)計: 再加上允許使用LEAVE(或BREAK結(jié)構(gòu)。6.2人機(jī)界面設(shè)計 6.2.1設(shè)計問題

設(shè)計人機(jī)界面過程中會遇到的4個問題: 系統(tǒng)響應(yīng)時間:長度易變性

用戶幫助設(shè)施:集成的幫助設(shè)施附加的幫助設(shè)施 出錯信息處理 命令交互

6.2.3 人機(jī)界面設(shè)計指南 一般交互指南 信息顯示指南 數(shù)據(jù)輸入指南 6.3過程設(shè)計的工具 6.3.1 程序流程圖(程序框圖 程序流程圖的主要缺點: 程序流程圖本質(zhì)上不是逐步求精的好工具,它誘使程序員過早地考慮程序的控制流程,而不去考慮程序的全局結(jié)構(gòu)。

程序流程圖中用箭頭代表控制流,因此程序員不受任何約束,可以完全不顧結(jié)構(gòu)程序設(shè)計的精神,隨意轉(zhuǎn)移控制。

程序流程圖不易表示數(shù)據(jù)結(jié)構(gòu)。6.3.2盒圖(N-S圖 盒圖具有下述特點:

功能域明確。不可能任意轉(zhuǎn)移控制。

很容易確定局部和全程數(shù)據(jù)的作用域。

很容易表現(xiàn)嵌套關(guān)系,也可以表示模塊的層次結(jié)構(gòu)。6.3.3 PAD圖

它用二維樹形結(jié)構(gòu)的圖來表示程序的控制流,將這種圖翻譯成程序代碼比較容易。

PAD圖的主要優(yōu)點如下: 使用表示結(jié)構(gòu)化控制結(jié)構(gòu)的PAD符號設(shè)計出來的程序必然是結(jié)構(gòu)化程序。PAD圖所描繪的程序結(jié)構(gòu)十分清晰。PAD圖表現(xiàn)程序邏輯易讀、易懂、易記。

容易將PAD圖轉(zhuǎn)換成高級語言源程序,這種轉(zhuǎn)換可用軟件工具自動完成。即可表示程序邏輯,也可描繪數(shù)據(jù)結(jié)構(gòu)。

PAD圖的符號支持自頂向下、逐步求精方法的使用。6.3.4 判定表

判定表卻能夠清晰地表示復(fù)雜的條件組合與應(yīng)做的動作之間的對應(yīng)關(guān)系。

判定表的缺點: 判定表的含義不是一眼就能看出來的,初次接觸這種工具的人理解它需要有一個簡短的學(xué)習(xí)過程。

當(dāng)數(shù)據(jù)元素的值多于兩個時,判定表的簡潔程度也將下降。6.3.5 判定樹 判定樹的優(yōu)點: 它的形式簡單,一眼就可以看出其含義,因此易于掌握和使用。判定樹的缺點: 簡潔性不如判定表,數(shù)據(jù)元素的同一個值往往要重復(fù)寫多遍,而且越接近樹的葉端重復(fù)次數(shù)越多。

畫判定樹時分枝的次序可能對最終畫出的判定樹的簡潔程度有較大影響。6.3.6 過程設(shè)計語言(偽碼 偽代碼的基本控制結(jié)構(gòu):

簡單陳述句結(jié)構(gòu):避免復(fù)合語句。

判定結(jié)構(gòu):IF_THEN_ELSE或CASE_OF結(jié)構(gòu)。選擇結(jié)構(gòu):WHILE_DO或REPEAT_UNTIL結(jié)構(gòu)。PDL的優(yōu)點: 可以作為注釋直接插在源程序中間。有助于保持文檔和程序的一致性,提高了文檔的質(zhì)量。可以使用普通的正文編輯程序或文字處理系統(tǒng),很方便地完成PDL的書寫和編輯工作。

已經(jīng)有自動處理程序存在,而且可以自動由PDL生成程序代碼。PDL的缺點: 不如圖形工具形象直觀,描述復(fù)雜的條件組合與動作間的對應(yīng)關(guān)系時,不如判定表清晰簡單。

6.4 面向數(shù)據(jù)結(jié)構(gòu)的設(shè)計方法

面向數(shù)據(jù)結(jié)構(gòu)的設(shè)計方法的最終目標(biāo)是得出對程序處理過程的描述。6.4.1Jackson

A由B、C、D 3個元素順序組成根據(jù)條件A是B或C或D中的某一個 A由B出現(xiàn)N次(N ≥0組成

6.4.2 改進(jìn)的Jackson圖 6.4.3 Jackson方法

6.5 程序復(fù)雜程度的定量度量 6.5.1 McCabe方法 1.流圖(程序圖

2.計算環(huán)形復(fù)雜度的方法 V(G=流圖中的區(qū)域數(shù) V(G=E-N+2 其中E是流圖中的邊數(shù),N是結(jié)點數(shù) V(G=P+1 其中P是流圖中判定結(jié)點的數(shù)目 6.5.2 Halstead方法

令N1為程序中運算符出現(xiàn)的總次數(shù),N2為操作數(shù)出現(xiàn)的總次數(shù),程序長度N定義為: N=N1+N2 程序中使用的不同運算符(包括關(guān)鍵字的個數(shù)n1,以及不同操作數(shù)(變量和常數(shù)的個數(shù)n2。預(yù)測程序長度的公式如下: H = n1 log2n1 + n2 log2n2 預(yù)測程序中包含錯誤的個數(shù)的公式如下: E = N log2(n1+n2/3000 第7章實現(xiàn)

編碼和測試統(tǒng)稱為實現(xiàn)。7.1編碼

7.1.1 選擇程序設(shè)計語言 主要的實用標(biāo)準(zhǔn): 系統(tǒng)用戶的要求 可以使用的編譯程序 可以得到的軟件工具 工程規(guī)模 程序員的知識 軟件可移植性要求

軟件的應(yīng)用領(lǐng)域 7.1.2 編碼風(fēng)格

1.程序內(nèi)部的文檔:恰當(dāng)?shù)臉?biāo)識符適當(dāng)?shù)淖⒔獬绦虻囊曈X組織 2.數(shù)據(jù)說明 3.語句構(gòu)造 4.輸入輸出

5.效率:程序運行時間存儲器效率輸入輸出的效率 7.2軟件測試基礎(chǔ) 7.2.1 軟件測試的目標(biāo)

測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程;好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案;成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。7.2.3 測試方法 黑盒測試(功能測試: 把程序看作一個黑盒子;完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過程;是在程序接口進(jìn)行的測試。白盒測試(結(jié)構(gòu)測試: 把程序看成裝在一個透明的盒子里;

測試者完全知道程序的結(jié)構(gòu)和處理算法;按照程序內(nèi)部的邏輯測試程序,檢測程序中的主要執(zhí)行通路是否都能按預(yù)定要求正確工作。

7.2.4 測試步驟 1.模塊測試(單元測試

保證每個模塊作為一個單元能正確運行;發(fā)現(xiàn)的往往是編碼和詳細(xì)設(shè)計的錯誤。2.子系統(tǒng)測試

把經(jīng)過單元測試的模塊放在一起形成一個子系統(tǒng)來測試;著重測試模塊的接口。3.系統(tǒng)測試

把經(jīng)過測試的子系統(tǒng)裝配成一個完整的系統(tǒng)來測試;發(fā)現(xiàn)的往往是軟件設(shè)計中的錯誤,也可能發(fā)現(xiàn)需求說明中的錯誤;不論是子系統(tǒng)測試還是系統(tǒng)測試,都兼有檢測和組裝兩重含義,通常稱為集成測試。

4.驗收測試(確認(rèn)測試

把軟件系統(tǒng)作為單一的實體進(jìn)行測試;它是在用戶積極參與下進(jìn)行的,而且可能主要使用實際數(shù)據(jù)(系統(tǒng)將來要處理的信息進(jìn)行測試;發(fā)現(xiàn)的往往是系統(tǒng)需求說明書中的錯誤。

5.平行運行

7.2.5 測試階段的信息流 輸入信息有兩類: 軟件配置,包括需求說明書、設(shè)計說明書和源程序清單等;測試配置,包括測試計劃和測試方案。7.3 單元測試

單元測試集中檢測模塊;單元測試和編碼屬于軟件過程的同一個階段;可以應(yīng)用人工測試和計算機(jī)測試這樣兩種不同類型的測試方法;單元測試主要使用白盒測試技術(shù),對多個模塊的測試可以并行地進(jìn)行。7.3.1 測試重點 模塊接口 局部數(shù)據(jù)結(jié)構(gòu) 重要的執(zhí)行通路 出錯處理通路 邊界條件 7.3.2 代碼審查

由審查小組正式進(jìn)行測試稱為代碼審查;一次審查會上可以發(fā)現(xiàn)許多錯誤,可以減少系統(tǒng)驗證的總工作量。

7.3.3 計算機(jī)測試

驅(qū)動程序是一個“主程序”,它接收測試數(shù)據(jù),傳送給被測試的模塊,并且印出有關(guān)的結(jié)果。存根程序代替被測試的模塊所調(diào)用的模塊。它使用被它代替的模塊的接口,可能做最少量的數(shù)據(jù)操作,印出對入口的檢驗或操作結(jié)果,并且把控制歸還給調(diào)用它的模塊。

7.4 集成測試

集成測試是測試和組裝軟件的系統(tǒng)化技術(shù),主要目標(biāo)是發(fā)現(xiàn)與接口有關(guān)的問題。

由模塊組裝成程序時有兩種方法: 7.4.3 不同集成測試策略的比較

混合策略: 改進(jìn)的自頂向下測試方法 混合法 7.4.4 回歸測試 7.5 確認(rèn)測試

確認(rèn)測試也稱為驗收測試,它的目標(biāo)是驗證軟件的有效性。7.5.3 Alpha和Beta測試

Alpha測試是在受控的環(huán)境中進(jìn)行的。

Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的“真實”應(yīng)用。1.接口測試 2.路徑測試 3.功能測試 4.健壯性測試 5.性能測試 6.用戶界面測試 7.信息安全測試 8.壓力測試 9.可靠性測試

10.安裝/反安裝測試確認(rèn)測試也稱為驗收測試,它的目標(biāo)是驗證軟件的有效性。Alpha測試是在受控的環(huán)境中進(jìn)行的。

Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的“真實”應(yīng)用。4.接口測試 5.路徑測試 6.功能測試 4.健壯性測試 5.性能測試

6.用戶界面測試 7.信息安全測試 8.壓力測試 9.可靠性測試 10.安裝/反安裝測試 7.6 白盒測試技術(shù)

7.6.1 邏輯覆蓋 語句覆蓋

判定覆蓋:比語句覆蓋強(qiáng),但對程序邏輯的覆蓋程度仍不高。

條件覆蓋:判定覆蓋不一定包含條件覆蓋,條件覆蓋也不一定包含判定覆蓋。判定/條件覆蓋:有時判定/條件覆蓋也并不比條件覆蓋更強(qiáng)。

條件組合覆蓋:條件組合覆蓋標(biāo)準(zhǔn)的測試數(shù)據(jù)并不一定能使程序中的每條路徑都執(zhí)行到。

6.點覆蓋(語句覆蓋標(biāo)準(zhǔn)相同 7.邊覆蓋(判定覆蓋一致 8.路徑覆蓋

7.6.2 控制結(jié)構(gòu)測試覆蓋 1.基本路徑測試

基本路徑測試是Tom McCabe提出的一種白盒測試技術(shù)。首先計算程序的環(huán)形復(fù)雜度;以該復(fù)雜度為指南定義執(zhí)行路徑的基本集合;2.條件測試

從該基本集合導(dǎo)出的測試用例可保證程序中的每條語句至少執(zhí)行一次,而且每個條件在執(zhí)行時都將分別取真、假兩種值。

3.循環(huán)測試

循環(huán)測試是一種白盒測試技術(shù),它專注于測試循環(huán)結(jié)構(gòu)的有效性。在結(jié)構(gòu)化的程序中通常只有3種循環(huán),即簡單循環(huán)、串接循環(huán)和嵌套循環(huán)。7.7 黑盒測試技術(shù) 7.7.1 等價劃分 7.7.2 邊界值分析 7.7.3 錯誤推測 7.9 軟降可靠性 7.9.1 基本概念 軟件可靠性: 程序在給定的時間間隔內(nèi),按照規(guī)格說明書的規(guī)定成功地運行的概率。

軟件的可用性: 程序在給定的時間點,按照規(guī)格說明書的規(guī)定,成功地運行的概率。第8章維護(hù)

軟件工程的目的是要提高軟件的可維護(hù)性,減少軟件維護(hù)所需要的工作量,降低軟件系統(tǒng)的總成本。

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

軟件維護(hù):在軟件已經(jīng)交付使用之后,為了改正錯誤或滿足新的需要而修改軟件的過程。可分為4項活動: 改正性維護(hù) 適應(yīng)性維護(hù) 完善性維護(hù) 預(yù)防性維護(hù) 8.2軟件維護(hù)的特點

8.2.1 結(jié)構(gòu)化維護(hù)與非結(jié)構(gòu)化維護(hù)差別巨大 8.2.2 維護(hù)的代價高昂 8.2.3 維護(hù)的問題很多 8.3軟件維護(hù)過程 1.維護(hù)組織 2.維護(hù)報告

3.維護(hù)的事件流 4.保存維護(hù)記錄 5.評價維護(hù)活動 8.4 軟件的可維護(hù)性

決定軟件可維護(hù)性的因素主要有7個: 可理解性 可測試性 可修改性 可靠性 可移植性 可使用性 效率

第9章面向?qū)ο蠓椒▽W(xué)引論 9.1面向?qū)ο蠓椒▽W(xué)概述 9.1.1面向?qū)ο蠓椒▽W(xué)要點

(1認(rèn)為客觀世界是由各種對象組成的,任何事物都是對象

(2把所有對象都劃分成各種類對象,每個對象類都定義了一組數(shù)據(jù)和一組方法(3按照子類和父類的關(guān)系,把若干個對象類組成一個層次結(jié)構(gòu)的系統(tǒng)(4對象彼此之間僅能通過傳遞消息相互聯(lián)系

9.1.2 面向?qū)ο箝_發(fā)方法 面向?qū)ο?對象+類 +繼承+通信 9.1.4 面向?qū)ο蠓椒ńM成 面向?qū)ο蟮姆治?面向?qū)ο蟮脑O(shè)計 面向?qū)ο蟮某绦蛟O(shè)計 9.1.6 面向?qū)ο蠓椒ǖ膬?yōu)點 1.與人類習(xí)慣的思維方式一致 2.穩(wěn)定性好 3.可重用性好 4.可維護(hù)性好

5.較易開發(fā)大型軟件產(chǎn)品 9.2 面向?qū)ο蟮母拍?9.2.1 對象

是客觀事物或概念的抽象表述,即對客觀存在的事物的描述統(tǒng)稱為對象,對象可以是事、物、或抽象概念,是將一組數(shù)據(jù)和使用該數(shù)據(jù)的一組基本操作或過程封裝在一起的實體。

對象的特點(1 以數(shù)據(jù)為中心。

(2 對象是主動的。(3 實現(xiàn)了數(shù)據(jù)封裝。(4 本質(zhì)上具有并行性。(5 模塊獨立性好。9.2.2 類

是一組具有相同屬性和相同操作的對象的集合。9.2.3 實例

由某個特定的類所描述的一個具體的對象。9.2.4 消息

向?qū)ο蟀l(fā)出的服務(wù)請求(互相聯(lián)系、協(xié)同工作等。一個消息包含3個部分:接收消息的對象,消息名,消息變元

9.2.5 方法

方法就是對象所能執(zhí)行的操作,也就是類中所定義的服務(wù)。9.2.6 屬性

屬性就是類中所定義的數(shù)據(jù),它是對客觀世界實體所具有的性質(zhì)的抽象。9.2.7 封裝

對象封裝了對象的數(shù)據(jù)以及對這些數(shù)據(jù)的操作。9.2.8 繼承(I 繼承是子類自動地共享基類中定義的數(shù)據(jù)和方法的機(jī)制。

單重繼承:子類僅從一個父類繼承屬性和方法 多重繼承:子類可從多個父類繼承屬性和方法 9.2.9 多態(tài)性 9.2.10 重載 9.3 面向?qū)ο蠼?II 面向?qū)ο箝_發(fā)軟件,需要建立3種形式的模型。對象模型。描述系統(tǒng)數(shù)據(jù)結(jié)構(gòu)—數(shù)據(jù)結(jié)構(gòu)。動態(tài)模型。描述系統(tǒng)控制結(jié)構(gòu)—執(zhí)行操作。功能模型。描述系統(tǒng)功能—數(shù)值變化。9.4 對象模型

9.4.1類圖的基本符號(I 1.定義類

2.定義屬性

可見性屬性名:類型 = 缺省值 {性質(zhì)串} 可見性(visibility表示該屬性對類外的元素是否可見。分為: public(+公有的,即模型中的任何類都可以訪問該屬性。private(-私有的,表示不能被別的類訪問。

protected(#受保護(hù)的,表示該屬性只能被該類及其子類訪問。如果可見性未申明,表示其可見性不確定。

3.定義操作

可見性操作名(參數(shù)表:返回類型{性質(zhì)串}

9.4.2 表示關(guān)系的符號(I 9.4.2.1 關(guān)聯(lián)(I 關(guān)聯(lián)表示兩個類的對象之間存在某種語義上的聯(lián)系。(1普通關(guān)聯(lián)

遞歸關(guān)聯(lián):一個類與本身有關(guān)聯(lián)關(guān)系(3限定關(guān)聯(lián)

(4關(guān)聯(lián)類

9.4.2.2 聚集(I(1共享聚集

如果在聚集關(guān)系中處于部分方的對象可同時參與多個處于整體方對象的構(gòu)成,則該聚集稱為共享聚集。

(2組合聚集

如果部分類完全隸屬于整體類,部分與整體共存,整體不存在了部分也會隨之消失,則該聚集稱為組合聚集。

9.4.2.3 泛化(I

(1普通泛化(2受限泛化

預(yù)定義的約束有4種:多重、不相交、完全和不完全。

9.4.2.4 依賴

9.4.2.5 細(xì)化

9.5動態(tài)模型 9.6功能模型 9.6.1用例圖

模型元素:系統(tǒng)、行為者、用例及用例之間的關(guān)系(擴(kuò)展關(guān)系、使用關(guān)系用例的實例是腳本

第10章面向?qū)ο蠓治?10.1 面向?qū)ο蠓治龅幕具^程

面向?qū)ο蠓治?抽取和整理用戶需求并建立問題域精確模型的過程.理解----用戶、分析員和領(lǐng)域?qū)＜?/p>

表達(dá)----需求規(guī)格說明書(對象模型、動態(tài)模型、功能模型

驗證----二義性,完善性

對象模型最基本、最重要、最核心。靜態(tài)結(jié)構(gòu)(對象模型

3個子模型交互次序(動態(tài)模型 數(shù)據(jù)變換(功能模型

復(fù)雜問題的對象模型的5個層次 面向?qū)ο蠓治龅倪^程 尋找類與對象 識別結(jié)構(gòu) 識別主題 定義屬性 建立動態(tài)模型

建立功能模型 定義服務(wù) 10.2 需求陳述

需求陳述是闡明“做什么”,而不是“怎樣做” 問題范圍 功能需求 性能需求 應(yīng)用環(huán)境 假設(shè)條件

第11章面向?qū)ο笤O(shè)計 11.1 面向?qū)ο笤O(shè)計的準(zhǔn)則 1.模塊化 2.抽象 3.信息隱藏 4.弱耦合

耦合指不同對象之間相互關(guān)聯(lián)的緊密程度。對象之間的耦合分兩類: 交互耦合

如果對象之間的耦合通過消息連接來實現(xiàn),則這種耦合就是交互耦合。交互耦合應(yīng)盡可能松散。

繼承耦合

與交互耦合相反,應(yīng)該提高繼承耦合程度。5.強(qiáng)內(nèi)聚

在面向?qū)ο笤O(shè)計中存在下述3種內(nèi)聚: 服務(wù)內(nèi)聚:一個服務(wù)應(yīng)該完成一個且僅完成一個功能。

類內(nèi)聚:一個類應(yīng)該只有一個用途,它的屬性和服務(wù)應(yīng)該是高內(nèi)聚的。一般-特殊內(nèi)聚:設(shè)計出的一般-特殊結(jié)構(gòu),應(yīng)該符合多數(shù)人的概念 6.可重用 11.2 啟發(fā)規(guī)則

1.設(shè)計結(jié)果應(yīng)該清晰易懂 2.一般-特殊結(jié)構(gòu)的深度應(yīng)適當(dāng) 3.設(shè)計簡單的類 4.使用簡單的協(xié)議 5.使用簡單的服務(wù) 6.把設(shè)計變動減至最小 第13章軟件項目管理 軟件工程計劃

控制度量軟件規(guī)模估算工作量進(jìn)度計劃 風(fēng)險管理 質(zhì)量保證 配置管理

組織

明確軟件開發(fā)的目標(biāo)

提供組織機(jī)構(gòu)和資源配置方面的保證 保證開發(fā)目標(biāo)的實現(xiàn) 技術(shù)

管理

13.1估算軟件規(guī)模

13.1.1 代碼行技術(shù) 估算方法： 由多名有經(jīng)驗的軟件工程師分別做出估計。每個人都估計程序的最小規(guī)模(a、最大規(guī)模(b和最可能的規(guī)模(m，分別算出這 3 種規(guī)模的平均值之后，再用下式計算程序規(guī)模的估計值： 單位： LOC 或 KLOC。代

碼行技術(shù)的優(yōu)點： 代碼是所有軟件開發(fā)項目都有的“產(chǎn)品”，而且很容易計算代碼行數(shù)； 有大量參考文獻(xiàn)和數(shù)據(jù)。代碼行技術(shù)的缺點： 源程序僅是軟件配置的一個成分，由源程序度量軟件規(guī)模不太合理； 用不同語言實現(xiàn)同一個軟件所需要的代碼行數(shù)并不相同； 不適用于非過程性語言。13.1.2 功能點技術(shù) 功能點技術(shù)依據(jù)對軟件信息域特性和軟件復(fù)雜性的評估結(jié)果，估算軟件規(guī)模。這種方法用功能點(FP為單位度量軟件規(guī)模。1.信息域特性 輸入項數(shù)(Inp、輸出項數(shù)(Out、查詢數(shù)(Inq、主文件數(shù)(Maf、外部接口數(shù)(Inf 每個特征根據(jù)其復(fù)雜程度分配一個功能點數(shù)，即信息域特征系數(shù) a1，a2，a3，a4，a5 2.估算功能點的步驟(1 計算未調(diào)整的功能點數(shù) UFP UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf(2 計算技術(shù)復(fù)雜性因子 TCF 技術(shù)因素對軟件規(guī)模的綜合影響程度 DI： 技術(shù)復(fù)雜性因子 TCF 由下式計算： TCF = 0.65 + 0.01 × DI 因為 DI 的值在 0~70 之間，所以 TCF 的值在 0.65~1.35 之間。(3 計算功能點數(shù) FP FP = UFP × TCF 功能點技術(shù)優(yōu)點：與所用的編程語言無關(guān)，比代碼行技術(shù)更合理。功能點技術(shù)缺點： 在判斷信息域特性復(fù)雜級別和技術(shù)因素的影響程度時主觀因素較大，對經(jīng) 驗依賴性較強(qiáng)。13.2 工作量估算

13.2.1 靜態(tài)單變量模型 E ev 是估算變量（KLOC 或 FP）。13.2.2 動態(tài)多變量模型

動態(tài)多變量模型也稱為軟件方程式，該模型把工作量看作是軟件規(guī)模和開發(fā)時間這兩個變量 的函數(shù)。E=(LOC×B0.333/P3×(1/t4 13.2.3 COCOMO2 模型（構(gòu)造性成本模型）3 個層次的估算模型： 應(yīng)用系統(tǒng)組成模型： 這個模型主要用于估算構(gòu)建原型的工作量，模型名字暗示在構(gòu)建原型時 大量使用已有的構(gòu)件。早期設(shè)計模型：這個模型適用于體系結(jié)構(gòu)設(shè)計階段。后體系結(jié)構(gòu)模型：這個模型適用于完成體系結(jié)構(gòu)設(shè)計之后的軟件開發(fā)階段。COCOMO2 使用的 5 個分級因素：項目先例性、開發(fā)靈活性、風(fēng)險排除度、項目組凝聚力、過 程成熟度 13.3 進(jìn)度計劃 13.3.1 估算開發(fā)時間 Brooks 規(guī)律：向一個已經(jīng)延期的項目增加人力，只會使得它更加延期。13.3.2 Gantt 圖 Gantt 圖的主要優(yōu)點： Gantt 圖能很形象地描繪任務(wù)分解情況，以及每個子任務(wù)(作業(yè)的開始和結(jié)束時間。具有直觀簡明和容易掌握、容易繪制的優(yōu)點。Gantt 圖的 3 個主要缺點： 不能顯式地描繪各項作業(yè)彼此間的依賴關(guān)系； 進(jìn)度計劃的關(guān)鍵部分不明確，難于判定哪些部分應(yīng)當(dāng)是主攻和主控的對象； 計劃中有潛力的部分及潛力的

大小不明確，往往造成潛力的浪費。13.3.3 工程網(wǎng)絡(luò) 工程網(wǎng)絡(luò)是系統(tǒng)分析和系統(tǒng)設(shè)計的強(qiáng)有力的工具。13.3.4 估算工程進(jìn)度 計算最早時刻 EET 使用下述 3 條簡單規(guī)則： 考慮進(jìn)入該事件的所有作業(yè)； 對于每個作業(yè)都計算它的持續(xù)時間與起始事件的 EET 之和； 選取上述和數(shù)中的最大值作為該事件的最早時刻 EET。計算最遲時刻 LET 使用下述 3 條規(guī)則：

考慮離開該事件的所有作業(yè)； 從每個作業(yè)的結(jié)束事件的最遲時刻中減去該作業(yè)的持續(xù)時間； 選取上述差數(shù)中的最小值作為該事件的最遲時刻 LET。13.3.5 關(guān)鍵路徑 關(guān)鍵事件：EET=LET 13.3.5 機(jī)動時間=(LET結(jié)束－(EET開始－持續(xù)時間 =右下角－左上角－持續(xù)時間 13.4 人員組織 13.4.1 民主制程序員組 如果小組內(nèi)有 n 個成員，則可能的通信信道共有 n(n-1/2 條。13.4.2 主程序員組 主程序員組的兩個重要特性：專業(yè)化、層次性 13.4.3 現(xiàn)代程序員組 13.5 質(zhì)量保證 13.5.1 軟件質(zhì)量 13.5.2 軟件質(zhì)量保證措施 13.6 軟件配置管理 基于非執(zhí)行的測試（復(fù)審或評審），主要用來保證在編碼之前各階段產(chǎn)生的文檔的質(zhì)量； 基于執(zhí)行的測試（軟件測試），需要在程序編寫出來之后進(jìn)行，它是保證軟件質(zhì)量的最后一 道防線； 程序正確性證明，使用數(shù)學(xué)方法嚴(yán)格驗證程序是否與對它的說明完全一致。1.技術(shù)復(fù)審的必要性 2.走查:參與者驅(qū)動法、文檔驅(qū)動法 3.審查：綜述 準(zhǔn)備 審查 返工 跟蹤 4.程序正確性證明 軟件配置管理是在軟件的整個生命期內(nèi)管理變化的一組活動。具體地說，這組活動用來：①標(biāo)識變化；②控制變化；③確保適當(dāng)?shù)貙崿F(xiàn)了變化；④向需要 知道這類信息的人報告變化。軟件配置管理的目標(biāo)： 使變化更正確且更容易被適應(yīng)，在必須變化時減少所需花費的工作量。

13.6.1 軟件配置 1.軟件過程的輸出信息（軟件配置項）： 計算機(jī)程序（源代碼和可執(zhí)行程序）； 描述計算機(jī)程序的文檔（供技術(shù)人員或用戶使用）； 數(shù)據(jù)（程序內(nèi)包含的或在程序外的）2.基線 基線就是通過了正式復(fù)審的軟件配置項。13.6.2 軟件配置管理過程 軟件配置管理主要有 5 項任務(wù)： 1.標(biāo)識軟件配置中的對象：基本對象、聚集對象 2.版本控制 3.變化控制 4.配置審計 5.狀態(tài)報告 13.7 能力成熟度模型 1.初始級 軟件過程的特征是無序的，有時甚至是混亂的。2.可重復(fù)級 軟件機(jī)構(gòu)建立了基本的項目管理過程(過程模型，可跟蹤成本、進(jìn)度、功能和質(zhì)

量。3.已定義級 軟件機(jī)構(gòu)已經(jīng)定義了完整的軟件過程（過程模型），軟件過程已經(jīng)文檔化和標(biāo)準(zhǔn)化。4.已管理級 軟件機(jī)構(gòu)對軟件過程（過程模型和過程實例）和軟件產(chǎn)品都建立了定量的質(zhì)量目標(biāo)，所有項 目的重要的過程活動都是可度量的。5.優(yōu)化級 軟件機(jī)構(gòu)集中精力持續(xù)不斷地改進(jìn)軟件過程。這一級的軟件機(jī)構(gòu)是一個以防止出現(xiàn)缺陷為目 標(biāo)的機(jī)構(gòu)，它有能力識別軟件過程要素的薄弱環(huán)節(jié)，并有足夠的手段改進(jìn)它們。

第二篇：軟件工程導(dǎo)論復(fù)習(xí)整理(最新)

第一章

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

2.軟件與硬件的區(qū)別：軟件不同于硬件，它是計算機(jī)系統(tǒng)中的邏輯部件而不是物理部件。

3.軟件：程序、數(shù)據(jù)及相關(guān)文檔的完整集合。

4.軟件工程是指導(dǎo)計算機(jī)軟件開發(fā)和維護(hù)的一門工程學(xué)科，采用工程的概念、原理、技術(shù)和方法來開發(fā)與維護(hù)軟件，把經(jīng)過時間考驗而證明正確的管理技術(shù)和當(dāng)前能夠得到最好的技術(shù)方法結(jié)合起來，以經(jīng)濟(jì)地開發(fā)出高質(zhì)量的軟件并有校地維護(hù)它。

5.軟件工程方法學(xué)三要素：方法、工具和過程。

6.傳統(tǒng)方法學(xué)也稱為生命周期方法學(xué)或結(jié)構(gòu)化范型。它采用結(jié)構(gòu)化技術(shù)來完成軟件開發(fā)的各項任務(wù)，并使用適當(dāng)?shù)能浖ぞ呋蜍浖こ汰h(huán)境來支持結(jié)構(gòu)化技術(shù)的運用。

7.面向?qū)ο蠓椒▽W(xué)把數(shù)據(jù)和行為看成同等重要的，它是一種以數(shù)據(jù)為主線，把數(shù)據(jù)和對數(shù)據(jù)的操作緊密地結(jié)合起來的方法。

8.軟件生命周期劃分為三個時期:1軟件定義（問題定義、可行性研究、需求分析），2軟件開發(fā)（總體設(shè)計、詳細(xì)設(shè)計、編碼和單元測試、綜合測試），3運行維護(hù)（軟件維護(hù)）。

9.4類軟件維護(hù)活動：改正性維護(hù)，也就是診斷和改正在使用過程中發(fā)現(xiàn)的軟件錯誤；適應(yīng)性維護(hù)，即修改軟件以適應(yīng)環(huán)境的變化；完善性維護(hù)，即根據(jù)用戶的要求改進(jìn)或擴(kuò)充軟件使它更完善；預(yù)防性維護(hù)，即修改軟件，為將來的維護(hù)活動預(yù)先做準(zhǔn)備。

10.“瀑布模型”的缺點：它是由文檔驅(qū)動的，僅僅通過寫在紙上的靜態(tài)的規(guī)格說明，很難全面正確地認(rèn)識動態(tài)的軟件產(chǎn)品；瀑布模型幾乎完全依賴于書面的規(guī)格說明，很可能導(dǎo)致最終開發(fā)出的產(chǎn)品不能真正的滿足用戶的需要。

11.快速原型模型的優(yōu)點：原型系統(tǒng)已經(jīng)通過與用戶交互而得到驗證，據(jù)此產(chǎn)生的規(guī)格說明文檔正確地描述了用戶需求；開發(fā)人員通過建立原型系統(tǒng)已經(jīng)學(xué)到了很多東西，因此，在設(shè)計和編碼階段發(fā)生錯誤的可能性也比較小，這自然減少了在后續(xù)階段需要改正前面階段所犯錯誤的可能性。

第二章 1.可行性研究的三個方面：技術(shù)可行性:使用現(xiàn)有的技術(shù)能實現(xiàn)這個系統(tǒng)經(jīng)濟(jì)可行性:這個系統(tǒng)的經(jīng)濟(jì)效益能超過它的開發(fā)成本操作可行性:系統(tǒng)的操作方式在這個用戶組織內(nèi)行得通

2.數(shù)據(jù)流圖的4個基本符號及畫法P41

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

4.符號含義：＝表示“等價于”或“定義為”；＋表示連接；[ ]表示“或”，用“|”分隔；{ }表示“重復(fù)”，()表示“可選”用“，”號隔開；1｛A}5 表示上限和下限。

5.高校電話號碼數(shù)據(jù)的定義P54

第三章

1.需求分析3種模型：數(shù)據(jù)模型：實體-聯(lián)系圖，描繪數(shù)據(jù)對象及數(shù)據(jù)對象之間的關(guān)系；功能模型：數(shù)據(jù)流圖，描繪當(dāng)數(shù)據(jù)在軟件系統(tǒng)中移動時被變換的邏輯過程；行為模型：狀態(tài)轉(zhuǎn)換圖，指明了作為外部事件結(jié)果的系統(tǒng)行為，描繪了系統(tǒng)的各種行為模式。

2.ER圖3種基本成分：實體（數(shù)據(jù)對象），關(guān)系，屬性。P64

3.軟件需求驗證的四個方面：一致性，完整性，現(xiàn)實性，有效性。

第四章

1.總體設(shè)計2個主要階段：系統(tǒng)設(shè)計階段，確定系統(tǒng)的具體實現(xiàn)方案；結(jié)構(gòu)設(shè)計階段，確定軟件結(jié)構(gòu)。

2.信息隱藏：設(shè)計和確定模塊，使得一個模塊內(nèi)包含的特定信息，對于不需要這些信息的模塊來說，是不能訪問的。

3.模塊獨立2個度量標(biāo)準(zhǔn)：內(nèi)聚和耦合。耦合衡量不同模塊彼此間互相依賴（連接）的緊密程度；內(nèi)聚衡量一個模塊內(nèi)部各個元素彼此結(jié)合的緊密程度。4.耦合與內(nèi)聚判定P98-99

5.深度：表示軟件結(jié)構(gòu)中控制的層數(shù)，它往往粗略的標(biāo)志一個系統(tǒng)的大小和復(fù)雜程度，深度和程序長度之間應(yīng)該有粗略的對應(yīng)關(guān)系；寬度：是軟件結(jié)構(gòu)內(nèi)同一層次上的模塊總數(shù)的最大值；扇出：是一個模塊直接控制（調(diào)用）的模塊數(shù)目；扇入：表明一個模塊有多少上級模塊直接調(diào)用它

6.P100 模塊的作用域和模塊的控制域之間的關(guān)系：模塊的作用域定義為受該模塊內(nèi)一個判定影響的所有模塊的集合；模塊的控制域是這個模塊本身以及所有直接或間接從屬于它的模塊的集合；模塊的作用域應(yīng)該在控制域之內(nèi)（在設(shè)計的很好的系統(tǒng)中，所有受判定影響的模塊應(yīng)該都從屬于做出判定的那個模塊，最好局限于做出判定的那個模塊本身以及它的直屬下級模塊）。

6.層次圖，結(jié)構(gòu)圖P10

2第六章

1.結(jié)構(gòu)程序設(shè)計定義：如果一個程序的代碼塊僅僅通過順序、選擇和循環(huán)這3種基本控制結(jié)構(gòu)進(jìn)行連接，并且每一個代碼塊只有一個入口和一個出口，則稱這個程序是結(jié)構(gòu)化的。

2.P124 過程設(shè)計的工具：程序流程圖、盒圖、PAD圖、判定表、判定樹、過程設(shè)計語言。

3.畫出偽碼程序的程序流程圖和盒圖 P1

41第七章

1.軟件測試在軟件生命周期中橫跨兩個階段：單元測試：模塊的編寫者和測試者是同一個人，編碼和單元測試屬于軟件生命周期的同一個階段；綜合測試：由專門的測試人員承擔(dān)這項工作。

2.為什么軟件測試不能由程序的編寫人員來做？

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

(2)正確認(rèn)識測試的目標(biāo)是十分重要的，測試目標(biāo)決定了測試力案的設(shè)計。如果為了表明程序是正確的而進(jìn)行測試，就會設(shè)計一些不易暴露錯誤的測試方案；相反，如果測試是為了發(fā)現(xiàn)程序中的錯誤，就會力求設(shè)計出最能暴露錯誤的測試方案。

(3)由于測試的目標(biāo)是暴露程序中的錯誤，從心理學(xué)角度看，由程序的編寫者自己進(jìn)行測試是不恰當(dāng)?shù)摹?/p>

3.測試方法：(1)黑盒測試 ：把程序看作一個黑盒子，完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過程 ；對程序接口進(jìn)行測試，檢查程序功能是否能按規(guī)格說明書的規(guī)定正常使用； 程序是否能適當(dāng)?shù)亟邮茌斎霐?shù)據(jù)并產(chǎn)生正確的輸出信息； 程序運行過程中能否保持外部信息的完整性

(2)白盒測試 ：把程序堪稱裝在一個透明的白盒子里，測試者完全知道程序的結(jié)構(gòu)處理算法 ；按照程序內(nèi)部的邏輯測試程序，檢測程序中的主要執(zhí)行通路是否都能按 預(yù)定要求正確工作。

4.測試步驟：模塊測試，子系統(tǒng)測試，系統(tǒng)測試，驗收測試，平行運行。P151

5.集成測試是測試和組裝軟件的系統(tǒng)化技術(shù)，即是在把模塊按照設(shè)計要求組裝起來的同時進(jìn)行測試，由模塊組裝成程序時兩種方法：非漸增式測試方法和漸增式測試方法。

6.P162 邏輯覆蓋標(biāo)準(zhǔn)：語句覆蓋，判定覆蓋，條件覆蓋，判定條件覆蓋，條件組合覆蓋，（還有點覆蓋，邊覆蓋，路徑覆蓋）。

7.設(shè)計測試用例：P16

2第八章

1.軟件維護(hù)：在軟件已經(jīng)交付使用之后，為了改正錯誤或者滿足新的需要而修改軟件的過程。

2.維護(hù)工作量的一個模型： M = P + K × exp(c-d)其中： M是維護(hù)用的總工作量，P是生產(chǎn)性工作量，K是經(jīng)驗常數(shù)，c是復(fù)雜程度d是維護(hù)人員對軟件的熟悉程度。exp，以自然對數(shù)e為底指數(shù)函數(shù)，Exponential(指數(shù)曲線)。

3.軟件可維護(hù)性與哪些因素有關(guān)？在軟件開發(fā)過程中應(yīng)該采取哪些措施來提高軟件產(chǎn)品可維護(hù)性？

答：軟件的可理解性、可測試性、可修改性、可移植性 和可重用性是決定軟件可維護(hù)下的基本因素。

軟件生命周期每個階段的工作都和軟件可維護(hù)性有密切關(guān)系。良好的設(shè)計，完整準(zhǔn)確易讀易理解的文檔資料，以及一系列嚴(yán)格的復(fù)審和測試，使得一旦發(fā)現(xiàn)錯誤時比較容易診斷和糾正，當(dāng)用戶有新要求或外部環(huán)境變化時軟件能較容易地適應(yīng)，并且能夠減少維護(hù)引入的錯誤。因此，在軟件生命周期的每個階段都必須充分考慮維護(hù)問題，并且為軟件維護(hù)預(yù)做準(zhǔn)備。

第九章

1.面向?qū)ο蟮母拍睿簩ο螅悾瑢嵗ⅲ椒ǎ瑢傩裕庋b，繼承，多態(tài)性P209-215 對象：是封裝了數(shù)據(jù)結(jié)構(gòu)及可以施加在這些數(shù)據(jù)結(jié)構(gòu)上的操作的封裝體（類的實例）類：是對具有相同屬性和行為的一個或多個對象的描述（支持繼承的抽象數(shù)據(jù)類型）實例：是由某個特定的類所描述的一個具體的對象

消息:就是要求某個對象執(zhí)行在定義它的那個類中所定義的某個操作的規(guī)格說明。由3部分組成：接收消息的對象，消息選擇符，零個或多個變元

方法：是對象所能執(zhí)行的操作，描述了對象執(zhí)行操作的算法，響應(yīng)消息的方法

屬性：類中所定義的數(shù)據(jù)，對客觀世界實體所具有的性質(zhì)的抽象

封住：就是信息隱藏，通過封裝對外界隱藏了對象的實現(xiàn)細(xì)節(jié)

繼承：子類自動地共享基類中定義的數(shù)據(jù)和方法的機(jī)制

多態(tài)性：指子類對象可以像父類對象那樣使用，同樣的消息既可以發(fā)送給父類對象也可以發(fā)送給子類對象

2.面向?qū)ο蠼＃好枋鱿到y(tǒng)數(shù)據(jù)結(jié)構(gòu)的對象模型，描述系統(tǒng)控制結(jié)構(gòu)的動態(tài)模型，描述系統(tǒng)功能的功能模型。類名

3.對象模型：P217 屬性類圖符號：服務(wù)

4.表示關(guān)系的符號：類與類之間通常有關(guān)聯(lián)、泛化(繼承)、依賴和細(xì)化等4種關(guān)系關(guān)聯(lián)：表示倆個類的對象之間存在某種語義上的聯(lián)系

泛化：是通用元素和具體元素之間的一種分類關(guān)系

依賴：描述倆個模型元素（類，用例等）之間的語義連接關(guān)系

細(xì)化：用來協(xié)調(diào)不同階段模型之間的關(guān)系，表示各個開發(fā)階段不同抽象層次的模型之間的相關(guān)性，常常用于跟蹤模型的演變。

5.功能模型：用例圖包含的模型元素有系統(tǒng)、行為者、用例及用例之間的關(guān)系P224

第十章

1.面向?qū)ο蠓治觯褪浅槿『驼碛脩粜枨蟛⒔栴}域精確模型的過程

2.建立對象模型、動態(tài)模型、功能模型的基本方法P235-255

第三篇：軟件工程導(dǎo)論復(fù)習(xí)材料

1.軟件工程基本概念

1.（）因素促使計算機(jī)系統(tǒng)越來越復(fù)雜。

A.計算機(jī)內(nèi)存和存儲容量上的巨大增長

B.外部輸入／輸出選項的更加多樣性

C.計算機(jī)體系結(jié)構(gòu)方面的深刻變化

D.以上所有選項

2.下面的（）不再是現(xiàn)代軟件工程師關(guān)注的問題。

A.為什么不能在產(chǎn)品發(fā)布前去除軟件錯誤？

B.為什么軟件需要很長時間才能完成？

C.為什么開發(fā)一個軟件的成本這么高？

D.為什么計算機(jī)硬件的成本這么高？

3.軟件會逐漸退化而不會磨損，其原因在于（）。

A.軟件備件很難訂購

B.軟件錯誤通常發(fā)生在使用之后

C.通常暴露在惡劣的環(huán)境下

D.不斷的變更使組件接口之間引起錯誤軟件

4.大多數(shù)軟件仍然是定制開發(fā)的，其原因在于（）。

A.軟件組件重用是十分普遍的 B.可重用的組件太昂貴而無法使用

C.軟件在不使用其他組件的情況下很容易構(gòu)造出來

D.商業(yè)組件在很多應(yīng)用領(lǐng)域中可以得到

5.下面的（）說法是正確的。

A.軟件危機(jī)在20世紀(jì)70年代末期全面爆發(fā)

B.當(dāng)前先進(jìn)的軟件工程方法已經(jīng)解決了軟件危機(jī)的問題

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

D.軟件危機(jī)是指在軟件產(chǎn)品中存在一系列的質(zhì)量問題 1.瀑布模型本質(zhì)上是一種（）。

A、線性迭代模型

B、順序迭代模型C、線性順序模型

D、及早見產(chǎn)品模型 2.（）是用戶和設(shè)計交換最頻繁的方法。

A、原型化方法

B、瀑布模型方法C、螺旋模型方法

D、構(gòu)件組裝模型 5.在軟件開發(fā)模型中，提出最早、應(yīng)用最廣泛的模型是（）A.瀑布模型

B.噴泉模型

C.增量模型

D.螺旋模型

1.軟件工程的方法只適用于大型軟件的開發(fā)，對小型軟件的開發(fā)沒有幫助。（）1.什么是軟件危機(jī)？其主要表現(xiàn)有那些？

1.有人認(rèn)為?軟件工程過于耗費時間，并且妨礙開發(fā)人員的編程效率。?你是否認(rèn)同這種觀點？請闡述理由。

2.需求分析 需求規(guī)格說明描述了（）。

A.計算機(jī)系統(tǒng)的功能、性能及其約束

B.每個指定系統(tǒng)的實現(xiàn)

C.軟件體系結(jié)構(gòu)的元素

D.系統(tǒng)仿真所需要的時間

7．軟件可行性研究實質(zhì)上是要進(jìn)行一次（）需求分析、設(shè)計過程。A.簡化、壓縮的B.詳細(xì)的 C.徹底的D.深入的 11.下面說法不正確的是（）。

A.流程圖不易表示數(shù)據(jù)結(jié)構(gòu)

B.流程圖容易造成非結(jié)構(gòu)化的程序結(jié)構(gòu)

C.流程圖支持逐步求精

D.流程圖描述的是程序的邏輯結(jié)構(gòu) 1.需求分析中開發(fā)人員要從用戶那里了解（）。

A、軟件做什么B、用戶使用界面C、輸入的信息D、軟件的規(guī)模

2.需求分析階段，分析人員要確定對問題的綜合需求，其中最主要的是（）需求。A、功能 B、性能 C、數(shù)據(jù) D、環(huán)境 24.軟件可行性研究一般不考慮（）

A.是否有足夠的人員和相關(guān)的技術(shù)來支持系統(tǒng)開發(fā) B.是否有足夠的工具和相關(guān)的技術(shù)來支持系統(tǒng)開發(fā) C.待開發(fā)軟件是否有市場、經(jīng)濟(jì)上是否合算 D.待開發(fā)的軟件是否會有質(zhì)量問題 25.需求規(guī)格說明描述了（）

A.計算機(jī)系統(tǒng)的功能、性能及其約束 B.每個指定系統(tǒng)的實現(xiàn) C.軟件體系結(jié)構(gòu)的元素

D.系統(tǒng)仿真所需要的時間

26.需求分析階段，分析人員要確定對問題的綜合需求，其中最主要的是（）需求 A.功能

B.性能

C.數(shù)據(jù)

D.環(huán)境

7.成本效益分析的目的是從

角度評價開發(fā)一個項目是否可行。

2.軟件需求規(guī)格說明書在軟件開發(fā)過程中具有重要的作用，它是軟件可行性分析的依據(jù)。3.（）目前存在一個很普遍的現(xiàn)象，即不同的客戶提出的需求是相互矛盾的，但每個人都爭辯自己是正確的。

5.（）在需求分析過程中，分析員要從用戶那里解決的最重要的問題是明確軟件做什么。2.可行性研究主要確定問題分析階段所確定的問題是否有可行的解。（）6.在需求分析過程中，分析員要解決的最重要的問題是明確軟件做什么。（）7.數(shù)據(jù)流圖的畫法？

3.軟件設(shè)計與編碼.概要設(shè)計階段產(chǎn)生的文檔不包括（）。A.概要設(shè)計說明書

B.數(shù)據(jù)庫設(shè)計說明書 C.用戶手冊

D.開發(fā)進(jìn)度月報.一個模塊把數(shù)值作為參數(shù)傳送給另一個模塊，這種耦合方式稱為（）。A.數(shù)據(jù)耦合 B.公共耦合 C.控制耦合 D.標(biāo)記耦合

10．與詳細(xì)設(shè)計相對應(yīng)的是數(shù)據(jù)庫的（）設(shè)計。A.概念

B.邏輯 C.物理

D.功能 19.序言性注釋主要內(nèi)容不包括（）。

A.模塊的接口

B.數(shù)據(jù)的描述

C.模塊的功能

D.數(shù)據(jù)的狀態(tài) 11.模塊化的目的是：（）

A、增加內(nèi)聚性 B、降低復(fù)雜性C、提高易讀性D、減少耦合性 12.軟件設(shè)計中劃分模塊的一個準(zhǔn)則是（）。

A、低內(nèi)聚低耦合B、低內(nèi)聚高耦合C、高內(nèi)聚低耦合D、高內(nèi)聚高耦合 13.下列耦合中，耦合程度最高的是：（）A、標(biāo)記耦合 B、控制耦合 C、內(nèi)容耦合 D、公共耦合 14.模塊間耦合程度越高，說明模塊之間彼此依賴的程度越（）。A、松散 B、緊密 C、無法判斷 D、相等 15.程序的三種基本控制結(jié)構(gòu)是（）。A、過程、子程序和分程序。B、順序、選擇和重復(fù)。C、遞歸、堆棧和隊列。D、調(diào)用、返回和轉(zhuǎn)移。

2.軟件設(shè)計階段一般分為

和

兩個階段。

3.軟件開發(fā)過程中，模塊化開發(fā)追求的目標(biāo)是：__________________。6.數(shù)據(jù)建模常用的模型是______________。任何程序都可由

、和

3種基本控制結(jié)構(gòu)構(gòu)造。這3種基本結(jié)構(gòu)的共同點是

、。

4.軟件人員的數(shù)量與軟件開發(fā)進(jìn)度成正比。（）

8.模塊化程序設(shè)計中，模塊越小，模塊化的優(yōu)點越明顯。一般來說，模塊的大小都在10行以下。（）

9.模塊化，信息隱藏，抽象和逐步求精的軟件設(shè)計原則有助于得到高內(nèi)聚，低耦合度的軟件產(chǎn)品。（）

10.程序設(shè)計風(fēng)格指導(dǎo)原則提出，盡量多使用臨時變量。（）8.模塊化程序設(shè)計中，模塊越小，模塊化的優(yōu)點越明顯。（）

4.軟件測試

13．（）方法需要考察模塊間的接口和各模塊之間的聯(lián)系。A.單元測試

B.集成測試 C.確認(rèn)測試

D.系統(tǒng)測試

16．在軟件生存周期中，時間最長、所花費的精力和費用也最多的階段是（）。A.詳細(xì)設(shè)計

B.維護(hù) C.概要設(shè)計

D.測試 16.軟件測試的目的是？（）A、證明軟件的正確性

B、找出軟件系統(tǒng)中存在的所有錯誤 C、證明軟件系統(tǒng)中存在錯誤

D、盡可能多的發(fā)現(xiàn)軟件系統(tǒng)中的錯誤

17.（）是以提高軟件質(zhì)量為目的的技術(shù)活動。A．技術(shù)創(chuàng)新

B．測試

C．技術(shù)創(chuàng)造

D．技術(shù)評審

18.軟件維護(hù)工作的最主要部分是（）。A、校正性維護(hù) B、適應(yīng)性維護(hù) C、完善性維護(hù) D、預(yù)防性維護(hù)

19.檢查軟件產(chǎn)品是否符合需求定義的過程稱為（）。A、確認(rèn)測試 B、集成測試 C、驗收測試 D、系統(tǒng)測試

20.軟件維護(hù)的副作用，是指（）。A、開發(fā)時的錯誤 B、隱含的錯誤

C、因修改軟件而造成的錯誤 D、運行時誤操作

33.發(fā)現(xiàn)錯誤能力最弱的是（）A.語句覆蓋

B.判定覆蓋

C.條件覆蓋

D.路徑覆蓋 34.（）方法需要考察模塊間的接口和各模塊之間的聯(lián)系 A.單元測試

B.集成測試

C.確認(rèn)測試

D.系統(tǒng)測試 1.軟件測試主要可分為________和________兩種類型。

4.軟件維護(hù)可分為四類，它們是改正性維護(hù)，________，________ 和________。8.軟件可維護(hù)性的因素是可理解性、可測試性、可修改性、可移植性和_____。

9． 軟件質(zhì)量保證應(yīng)從________開始，直到投入使用和售后服務(wù)的軟件生存期的每一階段中 4 的每一步驟。

3.為了加快軟件維護(hù)作業(yè)的進(jìn)度，應(yīng)盡可能增加維護(hù)人員的數(shù)目。（）

5.質(zhì)量保證是為了保證產(chǎn)品和服務(wù)充分滿足消費者要求的質(zhì)量而進(jìn)行的有計劃,有組織的活動。（）

6.判定覆蓋不一定包含條件覆蓋，條件覆蓋也不一定包含判定覆蓋。（）7.測試只能證明程序有錯誤,不能證明程序沒有錯誤。（）3.軟件維護(hù)就是改正軟件中的錯誤。（）

10.用黑盒法測試時，測試用例是根據(jù)程序內(nèi)部邏輯設(shè)計的。（11.基本路徑測試的分析方法？）5

5.面向?qū)ο蟮能浖こ蹋║ML）..（）意味著一個操作在不同的類中可以有不同的實現(xiàn)方式。

A.消息

B.多繼承

C.多態(tài)性

D.封裝.順序圖反映對象之間發(fā)送消息的時間順序，它與（）是同構(gòu)的。A.用例圖

B.類圖

C.協(xié)作圖

D.狀態(tài)圖

28.在軟件工程學(xué)中，我們把一組具有相同數(shù)據(jù)結(jié)構(gòu)和操作的對象的集合定義為（）A.類

B.屬性

C.對象

D.消息

29.順序圖反映對象之間發(fā)送消息的時間順序，它與（）是同構(gòu)的 A.用例圖

B.類圖

C.協(xié)作圖

D.狀態(tài)圖 35.下列關(guān)于UML敘述不正確的是（）A、UML是一種高級編程語言，且是可視化的B、UML是一種文檔化語言 C、UML是一種可用于詳細(xì)描述的語言

D、UML是一種構(gòu)造語言

36.表示一種一般事物（父類）和特殊事物（子類）之間的關(guān)系是（）A、依賴

B、關(guān)聯(lián)

C、泛化

D、實現(xiàn) 1.（）用例參與者總是人員而不是系統(tǒng)設(shè)備。

6.（）面向?qū)ο笤O(shè)計是在分析模型的基礎(chǔ)上，運用面向?qū)ο蠹夹g(shù)生成軟件實現(xiàn)環(huán)境下的設(shè)計模型。

8.（）關(guān)系數(shù)據(jù)庫可以完全支持面向?qū)ο蟮母拍睿嫦驅(qū)ο笤O(shè)計中的類可以直接對應(yīng)到關(guān)系數(shù)據(jù)庫中的表。

9.UML用例圖的畫法？

6.項目管理

38.CMMI體系中，第三級是（）A、已管理級

B、已量化管理級 C、已定義級

D、持續(xù)優(yōu)化級 5.軟件配置管理中，基線是___________________________________。4.（）軟件工作產(chǎn)品一旦成為基線就不能再更改了。4.什么是軟件配置管理？主要目標(biāo)和手段是什么？ 4.什么是基線？

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

第一章

軟件過程：需求設(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è)計??

思想是重點；過程是方式；方法和工具是載體

第二章

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

捷是一種思想?Scrum是一個框架

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

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

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

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

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

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

Scrum的適用場景

?7人，+or-2

?偏小一些會更適合?最好能坐在一起

?客戶參不度高

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

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

第三章

軟件項目是為了改善某個組織的某些方面

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

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

4添加虛擬和極端用戶

第四章

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

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

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

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

?Name（標(biāo)題）

–簡短的、描述性的故事名

?Story（故事）

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

?Priority（重要性）

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

?Initial estimate（初始估計）

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

?How to demo（如何做演示）

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

?Notes（注解）

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

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

?思考：由誰來寫？

–主要是Product Owner

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

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

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

用戶故事的三個變量

范圍，重要性，估算

好故事的準(zhǔn)則

?獨立的（Independ）

?可討論的（Negotiable）

?對用戶戒客戶有價值的（Valuable）

?可估計的（Estimatable）

?小的（Small）

?可測試的（Testable）

Sprint會議如何迚行

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

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

–決定 sprint 要包含的故事

–一些其他問題

第六章

什么是界面原型

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

界面原型的目的?盡早驗證需求

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

?方便溝通交流

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

第八章

ICONIX過程

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

?適合中小型的、需求相對明確的軟件項目

?ICONIX核心思想

?開源！節(jié)流！

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

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

?愿景是確保項目成功的第一步；

?愿景必須來自老大；

?愿景必須是可度量。

如何獲取軟件項目的愿景

?獲取軟件項目愿景的三步曲：

?第一步：找到軟件項目的“老大”；

?第二步：得到“老大”對項目的期望（愿景）；

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

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

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

第九章

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

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

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

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

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

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

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

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

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

第十章

域建模的步驟

第一步：提取名詞或名詞短語

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

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

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

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

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

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

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

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

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

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

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

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

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

3.更新域模型

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

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

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

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

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

用例描述的作用

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

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

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

?基本路徑

?擴(kuò)展路徑

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

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

?可靠性[Reliability]。

?可用性[Usability]。

?性能[Performance]。

?可支持性[Supportability]。

需求獲取的方法

?研究文檔。

?問卷調(diào)查。

?訪談。

?觀察。

?研究競爭對手。

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

?形式：面對面會議。

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

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

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

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

第十一章

健壯性分析的步驟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第五篇：軟件工程導(dǎo)論最全復(fù)習(xí)總結(jié)(精)

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

2、軟件是程序、數(shù)據(jù)及相關(guān)文檔的完整集合,程序是能夠完成預(yù)定功能和性能的可執(zhí)行的

程序序列;數(shù)據(jù)是是使程序能夠適當(dāng)?shù)奶幚硇畔⒌臄?shù)據(jù)結(jié)構(gòu);文檔是開發(fā)、使用和維護(hù)程序所需要的圖文資料。

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

4、目前使用最廣泛的軟件工程方法學(xué)是傳統(tǒng)方法學(xué)和面向?qū)ο蠓椒▽W(xué)。

5、軟件工程方法學(xué)的軟件過程基本上可以用瀑布模型來描述。

6、瀑布模型、快速原型模型、增量模型、螺旋模型、噴泉模型。

7、Rup把軟件生命周期劃為:初始、精化、構(gòu)建、移交階段。

8、可行性研究的三方面:技術(shù)可行性、經(jīng)濟(jì)可行性、操作可行性。

9、數(shù)據(jù)流圖(DFD是一種圖形化技術(shù),他描繪信息流和數(shù)據(jù)從輸入移動到輸出的過程中

所經(jīng)受的變化。

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

11、數(shù)據(jù)流圖和數(shù)據(jù)字典共同構(gòu)成系統(tǒng)的邏輯模型,沒有數(shù)據(jù)字典,數(shù)據(jù)如就不嚴(yán)格, 沒有流程圖,數(shù)據(jù)字典也難以發(fā)揮作用。

12、需求分析階段結(jié)束之前,系統(tǒng)分析員應(yīng)該寫出軟件需求規(guī)格說明書,以書面形式準(zhǔn)

確的描述軟件需求。13、9、結(jié)構(gòu)化分析方法就是面向數(shù)據(jù)流自頂向下逐步求精進(jìn)行需求分析的方法。

14、ER圖中包含了實體、關(guān)系和屬性,矩形代表實體,菱形表示關(guān)系,橢圓或圓角矩

形表示屬性,用直線把實體和其屬性連接。

15、驗證軟件需求的正確性:一致性、完整性、現(xiàn)實性、有效性。

16、總體設(shè)計的基本目的是回答“概括地說,系統(tǒng)應(yīng)該如何實現(xiàn)?”,總體設(shè)計又稱為

概要設(shè)或初步設(shè)計。

17、模塊的獨立程度可以有兩個定性標(biāo)量度量:內(nèi)聚和耦合。

18、軟件測試的目標(biāo):(1測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程;(2好的

測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案;(3成功的測試是發(fā)現(xiàn)可至今為止尚未發(fā)現(xiàn)的錯誤的測試。

19、軟件測試步驟:模塊測試、子系統(tǒng)測試、系統(tǒng)測試、驗收測試、平行運行。

20、軟件可靠性是程序在給定的時間點,按照規(guī)格說明書的規(guī)定,成功的運行的概率。

21、用面向?qū)ο蠓椒ㄩ_發(fā)軟件,通常需要建立3種形式的模型:描述系統(tǒng)數(shù)據(jù)結(jié)構(gòu)的對

象模型,描述系統(tǒng)控制結(jié)構(gòu)的動態(tài)模型和描述系統(tǒng)功能的功能模型。

22、用面向?qū)ο蠓椒ㄩ_發(fā)軟件,在任何情況下,對象模型始終都是最重要、最基本的、最核心的。

23、通常,使用UML提供的類圖來建立對象模型。

24、類與類之間通常有關(guān)聯(lián)、泛化(繼承、依賴和細(xì)化等4種關(guān)系。

25、在UML中,在一段為空心的三角形的連線表示泛化關(guān)系。

26、復(fù)雜問題的對象模型通常由:主題層、類與對象層、結(jié)構(gòu)層、屬性層和服務(wù)層。

27、廣義的說,軟件重用可分為知識重用、方法和標(biāo)準(zhǔn)的重用、軟件成分的重用。

28、工程網(wǎng)絡(luò)和Gantt圖同樣是安排進(jìn)度和管理工程進(jìn)度情況的強(qiáng)有力的工具。29、3種典型人員組織方式:民主制程序員組、住程序員組、現(xiàn)代程序員組。30、軟件過程的輸出信息可以分為3類計算機(jī)程序、描述計算機(jī)程序的文檔、數(shù)據(jù),這

些項組成了軟件過程中產(chǎn)生的全部信息,人們把他們統(tǒng)稱為軟件配置,而這些項就是軟件配置項。

31、Cmm把軟件過程從無序到有序的進(jìn)化過程分成5個階段,并把這些階段排序,形

成五個逐層提高的等級。能力的成熟度的5個等級從低到高依次是:初始級(1級、可重復(fù)級(2級、已定義級(3級已管理級(4級和優(yōu)化級(5級。

15、編碼風(fēng)格:持續(xù)內(nèi)部文檔、數(shù)據(jù)說明、語句構(gòu)造、輸入輸出、效率、32、軟件危機(jī)的典型表現(xiàn):對軟件開發(fā)成本和進(jìn)度的估計常常很不準(zhǔn)確;用戶對“已完

成”的軟件系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生;軟件產(chǎn)品質(zhì)量往往靠不住;軟件常常是不可維護(hù)的;軟件通常沒有適當(dāng)?shù)奈臋n資料;軟件成本在計算機(jī)總成本中所占的比例逐年上升;軟件開發(fā)生產(chǎn)效率提高的速度,遠(yuǎn)遠(yuǎn)跟不上計算機(jī)應(yīng)用迅速普及深入的趨勢。

33、軟件不同于硬件,他是計算機(jī)系統(tǒng)的邏輯部件而不是物理部件。

34、軟件不同于一般程序,它的一個顯著特點就是規(guī)模龐大。簡單題

1、軟件工程基本原理(1用分階段的生存周期嚴(yán)格管理。(2堅持進(jìn)行階段評審。(3實行嚴(yán)格的產(chǎn)品控制。(4采用現(xiàn)代程序設(shè)計技術(shù)。(5結(jié)果應(yīng)能清楚地審查。(6開發(fā)小組人員應(yīng)該少而精。(7承認(rèn)不斷改進(jìn)軟件工程實踐的必要性。

2、軟件生命周期各階段的基本任務(wù)軟件生命周期由軟件定義、軟件開發(fā)和運行維護(hù)3個時期組成,每個時期又進(jìn)一步劃分成若干個階段。(1問題定義(2可行性研究(3需求分析(4總體設(shè)計(5詳細(xì)設(shè)計(6編碼和單元測試(7綜合測試(8軟件維護(hù)

3、需求分析的任務(wù)

一、確定對系統(tǒng)的綜合要求(1功能需求(2性能需求(3可靠性和可用性需求(4出錯處理需求(5接口需求(6約束(7逆向需求(8將來可能提出的需求

二、分析系統(tǒng)的數(shù)據(jù)要求

三、導(dǎo)出系統(tǒng)的邏輯模型

四、修正系統(tǒng)開發(fā)計劃

4、改進(jìn)軟件設(shè)計的啟發(fā)式規(guī)則(1改進(jìn)軟件結(jié)構(gòu)提高模塊獨立性(2模塊規(guī)模應(yīng)該適中(3深度、寬度、扇出和扇入都應(yīng)適當(dāng)(4模塊的作用域應(yīng)該在控制域之(5力爭降低模塊接口的復(fù)雜程度(6設(shè)計單入口單出口的模塊(7模塊功能應(yīng)該可以預(yù)測

5、面向?qū)ο笤O(shè)計準(zhǔn)則和啟發(fā)式原則

(1模塊化(2抽象(3信息隱藏(4弱耦合(5強(qiáng)內(nèi)聚(6可重用

(1設(shè)計結(jié)果應(yīng)該清晰易懂(2一般-特殊結(jié)構(gòu)的深度應(yīng)適當(dāng)(3設(shè)計簡單的類(4使用簡單的協(xié)議(5使用簡單的服務(wù)(6把設(shè)計變動減至最小

6、軟件維護(hù)的幾種類型

(1改正性維護(hù)(2適應(yīng)性維護(hù)(3完善性維護(hù)(4預(yù)防性維護(hù)

7、決定軟件可維護(hù)性因素

(1可理解性(2可測試性(3可修改性(4可移植性(5可重用性

8、軟件配置項

軟件配置的主要任務(wù)就是控制變化,同時也負(fù)責(zé)各個軟件配置項和軟件各種版本的標(biāo)志、軟件配置審計以及軟件配置發(fā)生的任何變化的報告。(1標(biāo)識軟件配置中的對象(2版本控制(3變化控制(4配置審計(5狀態(tài)報告

設(shè)計題

1、等價類有效/無效數(shù)據(jù)邊界值測試

2、UML類圖的描述

3、N-S圖、PAD圖 論述題

(1軟件工程(2可行性研究問題定義階段必須回答的關(guān)鍵問題是:“要解決的問題是

什么”。如果不知道問題是什么就試圖解決這個問題,顯然是盲目的,只會自白浪費

時間和金錢,最終得出的結(jié)果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的,但是在實踐中它卻可能是最容易被忽視的一個步驟。(3需求分析這個階段的任務(wù)仍然不是具體地解決客戶的問題,而是準(zhǔn)確地回答“目標(biāo)系統(tǒng)必須做什么”這個問題。(4總體設(shè)計這個階段的基本任務(wù)是,概括地回答“怎樣實現(xiàn)目標(biāo)系統(tǒng)?”這個問題。概要設(shè)計又稱為初步設(shè)計、邏輯設(shè)計、高層設(shè)計或總體設(shè)計。(5詳細(xì)設(shè)計這個階段的任務(wù)還不是編寫程序,而是設(shè)計出程序的詳細(xì)規(guī)格說明。這種規(guī)格說明的作用很類似于其他工程領(lǐng)域中工程師經(jīng)常使用的工程藍(lán)圖,它們應(yīng)該包含必要的細(xì)節(jié),程序員可以根據(jù)它們寫出實際的程序代碼。(6編碼實現(xiàn)(語言,測試這個階段的關(guān)鍵任務(wù)是寫出正確的容易理解、容易維護(hù)的程序模塊。(7維護(hù)維護(hù)階段的關(guān)鍵任務(wù)是,通過各種必要的維護(hù)活動使系統(tǒng)持久地滿足用戶的需要。

(8面向?qū)ο蠹夹g(shù)(9項目管理

1.軟件工程學(xué):為了更有效地開發(fā)與維護(hù)軟件,軟件工作者早20世紀(jì)60年代后期開始認(rèn)真

研究消除軟件危機(jī)的途徑,從而逐漸形成了一門新興的工程學(xué)科。2.軟件危機(jī)典型變現(xiàn):(1.對軟件發(fā)開成本和進(jìn)度的估計常常不準(zhǔn)確.(2.用戶對“已完成的”軟件系統(tǒng)不滿意的現(xiàn)象經(jīng)常發(fā)生.(3.軟件產(chǎn)品的質(zhì)量往往靠不住.(4.軟件常常是不可維護(hù)的.(5.軟件通常沒有適當(dāng)?shù)奈臋n資料.(6.軟件成本在計算機(jī)系統(tǒng)總成本中所占的比例逐年上升.(7.軟件開發(fā)產(chǎn)生率提高的速度,遠(yuǎn)遠(yuǎn)跟不上計算機(jī)應(yīng)用迅速普及深入的趨勢.3.產(chǎn)生軟件危機(jī)的原因:(1.軟件不同于硬件,它是計算機(jī)系統(tǒng)中的邏輯部件而不是物理部件.(2.軟件不同于一般程序,它的一個顯著特點是規(guī)模龐大,而且程序復(fù)雜性將隨著程序規(guī)模 的增加而呈指數(shù)上升.(3.軟件本身獨有的特點確實給開發(fā)和維護(hù)帶來一些客觀困難.(4與軟件開發(fā)和維護(hù)有關(guān)的許多錯誤認(rèn)識和做法形成,可以歸因于在計算機(jī)系統(tǒng)發(fā)展的早

期階段軟件開發(fā)的個體特點.4.消除軟件危機(jī)的途徑:(1.應(yīng)該對計算機(jī)軟件有一個正確的認(rèn)識.(2.充分認(rèn)識到軟件開發(fā)不是某種個體勞動的神秘技巧,而應(yīng)該是組織良好、管理嚴(yán)密、各

類人員協(xié)同配合、共同完成的工程項目.(3.在使用要總結(jié)出成功的技術(shù)和方法,盡快消除錯誤概念和做法.(4.開發(fā)和使用更好的軟件工具 5.軟件工程的本質(zhì)特性:(1.軟件工程關(guān)注于大型程序的構(gòu)造.(2.軟件工程的中心課題是控制復(fù)雜性.(3.軟件經(jīng)常變化.(4.開發(fā)軟件的效率非常重要.(5.和諧地合作是開發(fā)軟件的關(guān)鍵.(6.軟件必須有效地支持它的用戶.(7.在軟件工程領(lǐng)域中通常由具有一種文化背景的人替具有另一種文化背景的人創(chuàng)造產(chǎn)

品.6.軟件工程的原理:(1.用分段的生命周期計劃嚴(yán)格管理.(2.堅持進(jìn)行階段評審.(3.實行嚴(yán)格的產(chǎn)品控制.(4.采用現(xiàn)代程序設(shè)計技術(shù).(5.結(jié)果應(yīng)能清楚地審查.(6.開發(fā)小組的人員應(yīng)該少而精.(7.承認(rèn)不斷改進(jìn)軟件工程實踐的必要性.7.軟件生命周期:由軟件定義、軟件開發(fā)和運行維護(hù)3個時期組成,每個時期又進(jìn)一步劃分成若干個階段.8.軟件開發(fā)時期4個階段:總體設(shè)計,詳細(xì)設(shè)計,編碼和單元測試,綜合測試.9.軟件維護(hù),維護(hù)階段的關(guān)鍵任務(wù)是,通過各種必要的維護(hù)活動使系統(tǒng)持久地滿足用戶的需要.10.瀑布模型的特點:(1.階段間具有順序性和依賴性.(2.推遲實現(xiàn)的觀點.(3.質(zhì)量保證的觀點.11.快速原型模型:是快速建立起來的可以在計算機(jī)運行的程序,它所能完成的功能往往是最

終產(chǎn)品能完成的功能的一個子集.12.快速模型的主要優(yōu)點是不帶饋環(huán)的,軟件產(chǎn)品基本上是線性順序進(jìn)行的.13.可行性研究的目的:用最小的代價在盡可能短的時間內(nèi)確定問題是否能夠解決.14.可行性的解法:(1技術(shù)可行性.(2經(jīng)濟(jì)可行性.(3操作可行性.15.可行性研究過程步驟:(1.復(fù)查系統(tǒng)規(guī)模和目標(biāo).(2.研究目前正在使用的系統(tǒng).(3.導(dǎo)出新系統(tǒng)的高層邏輯模型.(4.進(jìn)一步定義問題.(5.導(dǎo)出和評價供選擇的解法.(6.推薦行動方針.(7.草擬開發(fā)計劃.(8.書寫文檔提交審查.16.系統(tǒng)流程圖:是概括地描繪物理系統(tǒng)的傳統(tǒng)工具.它的基本思想是用圖形符號以黑盒子形

式描繪組成系統(tǒng)的每個部件.17.數(shù)據(jù)流圖(DFD:是一種圖形化技術(shù),它描繪信息流和數(shù)據(jù)從輸入移動到輸出的過程中所經(jīng)

受的變換.18.數(shù)據(jù)字典:是關(guān)于數(shù)據(jù)的信息的集合,就是對數(shù)據(jù)流圖中包括的所有元素的定義的集合.19.數(shù)據(jù)字典組成元素:(1數(shù)據(jù)流.(2數(shù)據(jù)流分量.(3數(shù)據(jù)存儲.(4處理.20.定義數(shù)據(jù)的方法:定義絕大多數(shù)復(fù)雜事物的方法,都是用被定義的事物的成分的某種組合

表示這個事物,這些組成成分又由更底層的成分的組合來定義.21.數(shù)據(jù)字典最重要用途:作為分析階段的工具。

22.為什么要進(jìn)行需求分析:因為它的基本任務(wù)是準(zhǔn)確地回答“系統(tǒng)必須做什么?”這個問

題。可行性研究階段只是粗略了解用戶的需求,許多細(xì)節(jié)被忽略,然而最終的系統(tǒng)中卻不能遺漏任何細(xì)節(jié)。所以可行性研究并不能代替需求分析。

23.軟件系統(tǒng)綜合要求:(1功能需求.(2性能需求.(3可靠性和可行性需求.(4出錯處理需求.(5 接口需求.(6約束.(7逆向需求.(8將來可能提出的要求.24.訪談:是最早開始使用的獲取用戶需求的技術(shù),是迄今為止仍然廣泛使用的需求分析技術(shù).25.需求分析過程3種模型:數(shù)據(jù)模型、功能模型和行為模型.26.數(shù)據(jù)模型包含3種相互關(guān)聯(lián)信息:數(shù)據(jù)對象、數(shù)據(jù)對象的屬性及數(shù)據(jù)對象彼此間相互連接的關(guān)系.27.總體設(shè)計的目的:就是回答“概括地說,系統(tǒng)應(yīng)該如何實現(xiàn)?”這個問題.28.總體設(shè)計兩個過程:系統(tǒng)設(shè)計階段,確定系統(tǒng)的具體實現(xiàn)方案;結(jié)構(gòu)設(shè)計階段,確定軟件結(jié)

構(gòu).29.總體設(shè)計過程步驟:(1設(shè)想供選擇的方案.(2選取合理的方案.(3推薦最佳方案.(4功能分

解.(5設(shè)計軟件結(jié)構(gòu).(6設(shè)計數(shù)據(jù)庫.(7制定測試計劃.(8書寫文檔.(9審查和復(fù)查.30.模塊化:就是把程序劃分成獨立命名且可獨立訪問的模塊,每個模塊完成一個子功能,把這

些模塊集成起來構(gòu)成一個整體,可以完成指定的功能滿足用戶的需求.31.怎做到模塊獨立:開發(fā)具有獨立功能而且和其他模塊之間沒有過多的相互作用的模塊.32模塊獨立兩個定性標(biāo)準(zhǔn)度量:內(nèi)聚和耦合.33.耦合:對一個軟件結(jié)構(gòu)內(nèi)不同模塊之間互連程度的度量.34.內(nèi)聚:標(biāo)志著一個模塊各個元素彼此結(jié)合的緊密程度,它是信息隱藏和局部化概念的自然

擴(kuò)展.35.功能內(nèi)聚10分順序內(nèi)聚9分通信內(nèi)聚7分過程內(nèi)聚5分時間內(nèi)聚3分邏輯內(nèi)聚1 分偶然內(nèi)聚0分

36.設(shè)計時要力爭做到高內(nèi)聚,低耦合.37.啟發(fā)式規(guī)則介紹:(1.改進(jìn)軟件結(jié)構(gòu)提高模塊獨立性.(2.模塊規(guī)模應(yīng)該適中.(3.深度、寬度、扇出和扇入都應(yīng)適當(dāng).(4.模塊的作用域應(yīng)該在控制域之內(nèi).(5.力爭降低模塊接口的復(fù)雜程度.(6.設(shè)計單入口單出口的模塊.(7.模塊功能應(yīng)該可以預(yù)測

38.交換流:信息沿輸入通信路進(jìn)入系統(tǒng),同時由外部形式變換成內(nèi)部形式,進(jìn)入系統(tǒng)的信息通

過變換中心,經(jīng)加工處理以后再沿輸出路變成外部形式離開軟件系統(tǒng).39.事務(wù)流:數(shù)據(jù)沿輸入通路到達(dá)一個處理T,這個處理根據(jù)輸入數(shù)據(jù)的類型在若干個動作序列

中選出一個來執(zhí)行.40.詳細(xì)設(shè)計目標(biāo):確定應(yīng)該怎樣具體地實現(xiàn)所要求的系統(tǒng).41.結(jié)構(gòu)程序設(shè)計:如果一個程序的代碼塊僅僅通過順序、選擇和循環(huán)這3種基本控制結(jié)構(gòu)進(jìn)

行連接,并且每個代碼只有一個入口和一個出口.42.實現(xiàn):通常把編碼和測試統(tǒng)稱.43.編碼:就是那軟件設(shè)計結(jié)果翻譯成用某種程序設(shè)計語言書寫的程序.44.測試方法:黑盒測試(知產(chǎn)品的功能可測試和白盒測試(知產(chǎn)品內(nèi)部工作過程可測試

45.測試步驟:(1模塊測試.(2子系統(tǒng)測試.(3系統(tǒng)測試.(4驗收測試.(5平行運行.46.測試重點:(1模塊接口(2局部數(shù)據(jù)結(jié)構(gòu)(3重要的執(zhí)行通路(4出錯處理通路(5邊界條件.47.確認(rèn)測試:也稱驗收測試,它的目標(biāo)是驗收軟件的有效性.48.Alpha測試:由用戶在開發(fā)者的場所進(jìn)行,并且在開發(fā)者對用戶的“指導(dǎo)”下進(jìn)行測試.開發(fā)者

負(fù)責(zé)記錄發(fā)現(xiàn)的錯誤和使用中遇到的問題.49.Beta測試:由軟件的最終用戶在一個或多個客戶場所進(jìn)行.與Alpha測試不同,開發(fā)者通常

不在Beta測試的現(xiàn)場,因此,Bate測試時軟件在開發(fā)者不能控制的環(huán)境中的“真實”應(yīng)用.50.調(diào)試:是在測試發(fā)現(xiàn)錯誤之后排除錯誤的過程.51.軟件維護(hù):就是在軟件已經(jīng)交付使用之后,為了改正錯誤或滿足新的需要而修改的過程.52.改正性維護(hù):診斷和改正錯誤的過程.53.決定軟件維護(hù)性的因素:(1可理解性.(2可測試性.(3可修改性.(4可移植性.(5可重用性.54.用戶文檔:是用戶了解系統(tǒng)的第一步,它應(yīng)該能使用戶獲得對系統(tǒng)的準(zhǔn)確的初步印象.55.用戶文檔包括的內(nèi)容:(1功能描述(2安裝文檔(3使用手冊(4參考手冊(5操作員指南.56.系統(tǒng)文檔:指從問題定義、需求說明到驗收測試計劃這樣一系列和系統(tǒng)實現(xiàn)有關(guān)的文檔.