軟件工程復(fù)習(xí) 課件整理修改版

1、精品文檔就在這里 -各類專業(yè)好文檔，值得你下載，教育，管理，論文，制度，方案手冊(cè)，應(yīng)有盡有- - 英文版軟件工程教學(xué)內(nèi)容回顧2014下 (下述問題僅是課件中的主要部分回顧，問題答案以課件為主要參考) Chapter01 SE的定義、目的、方法及作用（P2 / P16） 定義：軟件工程是一種系統(tǒng)工程，不止包括對(duì)技術(shù)問題的分析與解決，還包括對(duì)開發(fā)過程和給參與者分配合適的角色等方面的管理 目的：生產(chǎn)出高質(zhì)量的軟件進(jìn)而找到解決方案，并考慮那些對(duì)質(zhì)量有影響的特性 方法及作用： 分析（analysis）-分析問題，調(diào)查軟件正反兩方面， 設(shè)計(jì)（design）-給出解決方案， 開發(fā)團(tuán)隊(duì)（developing

2、team）-描述在團(tuán)隊(duì)中的人員的角色和職責(zé)， 開發(fā)（develop）-實(shí)現(xiàn)解決方案（實(shí)現(xiàn)對(duì)象、活動(dòng)、封裝等等）， 將系統(tǒng)分為小部分，逐步明確過程，控制進(jìn)度，處理每個(gè)改變等等）-項(xiàng)目管理（project management /開發(fā)模式（paradiam）（P4） 它表示開發(fā)軟件時(shí)特定的方法或哲學(xué)。 說明錯(cuò)誤、缺陷、失效的含義與聯(lián)系。（請(qǐng)舉例說明）（6頁(yè)）（44頁(yè)習(xí)題3） 錯(cuò)誤error，是進(jìn)行軟件開發(fā)過程中人為出錯(cuò)造成的 例如，設(shè)計(jì)人員可能誤解了某個(gè)需求，創(chuàng)建出與需求分析人員和用戶的實(shí)際意圖不相符的設(shè)計(jì)。這個(gè)設(shè)計(jì)故障是一種錯(cuò)誤的編碼，可能導(dǎo)致其他故障，如不正確的代碼或用戶手冊(cè)中不正確的描述等。

3、 故障/缺陷fault：當(dāng)人們?cè)谶M(jìn)行軟件開發(fā)活動(dòng)的過程中出現(xiàn)錯(cuò)誤時(shí)，就會(huì)引起缺陷。（靜態(tài)存在） （動(dòng)態(tài)存在）產(chǎn)生）故障。失效failure是指系統(tǒng)違背了它應(yīng)有的行為（由于 例如，需求文檔可能會(huì)包含故障，所以即使系統(tǒng)按照需求規(guī)格來運(yùn)行，如果它未進(jìn)行應(yīng)有的行為，也稱為失效。 聯(lián)系：?jiǎn)蝹€(gè)錯(cuò)誤可能產(chǎn)生多個(gè)故障。故障是系統(tǒng)的內(nèi)部視圖，這是從開發(fā)人員的角度看待系統(tǒng)；而失效是系統(tǒng)的 。外部視圖，它是用戶所看到的問題。并非每一個(gè)故障都對(duì)應(yīng)于一個(gè)失效（不執(zhí)行故障代碼就不會(huì)是代碼失效） 軟件質(zhì)量應(yīng)從哪幾個(gè)方面來衡量？論述之。（9-12頁(yè)） 產(chǎn)品質(zhì)量 特性的重要性取決于分析這個(gè)軟件的人，如果軟件用易于學(xué)習(xí)或是易于使

4、用的方式做了用戶想做的事情，用戶就斷定軟件是高質(zhì)量的。 軟件還必須由那些設(shè)計(jì)和編寫代碼的人員以及維護(hù)該程序的人員來評(píng)價(jià)，這些時(shí)間人員傾向于考慮產(chǎn)品的內(nèi)部特性，有時(shí)甚至?xí)诋a(chǎn)品交付給用戶之前就考慮這些內(nèi)部特性。 過程質(zhì)量 有很多活動(dòng)會(huì)影響到最終的產(chǎn)品質(zhì)量。只要活動(dòng)出了差錯(cuò)，產(chǎn)品的質(zhì)量就會(huì)受到影響。因此，許多軟件工程師認(rèn)為開發(fā)和維護(hù)過程的質(zhì)量與產(chǎn)品的質(zhì)量是同等重要的。 商業(yè)價(jià)值 在商業(yè)環(huán)境中，質(zhì)量是根據(jù)軟件所處的商業(yè)環(huán)境提供的產(chǎn)品和服務(wù)來看待的。也就是說，我們考慮的是產(chǎn)品的技-精品 文檔- 精品文檔就在這里 -各類專業(yè)好文檔，值得你下載，教育，管理，論文，制度，方案手冊(cè)，應(yīng)有盡有- - 術(shù)價(jià)值，而

5、不是更廣泛的商業(yè)價(jià)值。/軟件系統(tǒng)的系統(tǒng)組成（P16） 1. 活動(dòng)和對(duì)象 2. 關(guān)系和系統(tǒng)邊界 ) + boundary(邊界) + activities(活動(dòng)) + relationships(關(guān)系實(shí)體A system = entities( 現(xiàn)代軟件工程大致包含的幾個(gè)階段及各個(gè)階段文檔（P23-24） 1. 需求分析和定義需求規(guī)格說明 2. 系統(tǒng)設(shè)計(jì)設(shè)計(jì)描述 3. 程序設(shè)計(jì) 4. 程序?qū)崿F(xiàn)程序文檔 5. 單元測(cè)試 6. 集成測(cè)試測(cè)試數(shù)據(jù) 7. 系統(tǒng)測(cè)試 8. 系統(tǒng)交付培訓(xùn)手冊(cè) 9. 維護(hù) / 使現(xiàn)代SE實(shí)踐發(fā)生變化的（七個(gè)）關(guān)鍵因素是什么？（28-29頁(yè)） 商業(yè)軟件的投放市場(chǎng)時(shí)間的緊迫性 計(jì)

6、算經(jīng)濟(jì)學(xué)的改變 強(qiáng)力的桌面計(jì)算平臺(tái)的出現(xiàn) 局域網(wǎng)和廣域網(wǎng)的延伸 面向?qū)ο蠹夹g(shù)的出現(xiàn)和采用 使用窗口、圖標(biāo)、菜單和指針的圖形用戶界面 瀑布模型用于軟件開發(fā)的不可預(yù)測(cè)性 什么是抽象？（30頁(yè)） 抽象（abstraction）是在某種概括層次上對(duì)問題的描述，使得我們能夠集中于問題的關(guān)鍵方面而不會(huì)陷入細(xì)節(jié)。 什么是軟件過程？軟件過程的重要性是什么？包含幾個(gè)階段？（32頁(yè)）（45頁(yè)） 定義：軟件開發(fā)活動(dòng)中的各種組織及規(guī)范方法。 重要性：具有通用性（一致性、結(jié)構(gòu)性）和指導(dǎo)性。 階段：上有 什么是復(fù)用？（34頁(yè)） 重復(fù)采用以前開發(fā)的軟件系統(tǒng)中具有共性的部件, 用到新的開發(fā)項(xiàng)目中去。 -精品 文檔- 精品文檔

7、就在這里- -各類專業(yè)好文檔，值得你下載，教育，管理，論文，制度，方案手冊(cè)，應(yīng)有盡有- Chaoter02 瀑布模型及各階段文檔，優(yōu)缺點(diǎn)？（P49） 瀑布模型將開發(fā)階段描述為從一個(gè)階段瀑布般轉(zhuǎn)到另外一個(gè)階段。一個(gè)開發(fā)階段必須在另一個(gè)開發(fā)階段之前完成。 優(yōu)點(diǎn)：在幫助開發(fā)人員布置他們需要做的工作時(shí)，瀑布模型是非常有用的； 它的簡(jiǎn)單性使得開發(fā)人員很容易向不熟悉軟件開發(fā)的客戶作出解釋。 是其他復(fù)雜模型的基礎(chǔ) 缺點(diǎn)：瀑布模型最大的問題是它并不能反映實(shí)際的代碼開發(fā)方式。 面臨軟件變動(dòng)時(shí), 該模型無法處理實(shí)際過程中的重復(fù)開發(fā)問題 文檔轉(zhuǎn)換有困難 原型的概念（P51） ）是一個(gè)部分開發(fā)的產(chǎn)品，用來讓用戶和開發(fā)

8、者共同研究，提出意見，為最終產(chǎn)品定型。prototype原型（ 論述分階段開發(fā)模型的含義, 其基本分類及特點(diǎn)是什么？（56頁(yè)） definition: 系統(tǒng)被設(shè)計(jì)成部分提交, 每次用戶只能得到部分功能, 而其他部分處于開發(fā)過程中。 分類及特點(diǎn)： 增量開發(fā)：系統(tǒng)需求按照功能分成若干子系統(tǒng)，開始建造的版本是規(guī)模小的、部分功能的系統(tǒng)，后續(xù)版本添加包含新功能的子系統(tǒng)，最后版本是包含全部功能的子系統(tǒng)集。 迭代開發(fā)：系統(tǒng)開始就提供了整體功能框架，后續(xù)版本陸續(xù)增強(qiáng)各個(gè)子系統(tǒng)，最后版本使各個(gè)子系統(tǒng)的功能達(dá)到最強(qiáng)。 螺旋模型四個(gè)象限的任務(wù)及四重循環(huán)的含義？ （P58） 四象限：確定目標(biāo)、可選方案及約束； 評(píng)估可

9、選方案及風(fēng)險(xiǎn) 計(jì)劃 開發(fā)與測(cè)試 操作概念是第一次迭代的產(chǎn)品，而需求則是第二次迭代的主要產(chǎn)品，第三次迭代系統(tǒng)開發(fā)產(chǎn)生設(shè)計(jì)，第四次迭代能 。夠進(jìn)行測(cè)試 針對(duì)本章描述的每一種過程模型，討論使用該模型的優(yōu)點(diǎn)和缺點(diǎn)分別是什么？ 針對(duì)本章描述的每一種過程模型，討論該模型是如何處理開發(fā)后期重要的需求變化的？ -精品 文檔- 精品文檔就在這里 -各類專業(yè)好文檔，值得你下載，教育，管理，論文，制度，方案手冊(cè)，應(yīng)有盡有- - 瀑布模型 V模型 原型化模型 可操作規(guī)格模型 分階段開發(fā)模型 螺旋模型 瀑布模型從一種非常高層的角度描述了軟件開發(fā)過程中進(jìn)行的活動(dòng)，并且提出了要求開發(fā)人員經(jīng)過的事件序列。該模型適用于項(xiàng)目開始

10、時(shí)需求已確定的情況。V模型是瀑布模型的變種，它說明測(cè)試活動(dòng)是如何與分析和設(shè)計(jì)相聯(lián)系的。原型模型允許開發(fā)人員快速地構(gòu)造整個(gè)系統(tǒng)或系統(tǒng)的一部分以理解或澄清問題。原型的用途是獲知用戶的真正需求，因此原型模型可以有效地引發(fā)系統(tǒng)需求。螺 旋模型把開發(fā)活動(dòng)和風(fēng)險(xiǎn)管理結(jié)合起來，以將風(fēng)險(xiǎn)減到最小并控制風(fēng)險(xiǎn)。 /在所有的軟件開發(fā)過程模型中，你認(rèn)為哪些過程給予你最大的靈活性以應(yīng)對(duì)需求的變更？ 1. 設(shè)計(jì)對(duì)于分析模型應(yīng)該是可跟蹤的：軟件的模塊可能被映射到多個(gè)需求上。 2. 設(shè)計(jì)結(jié)構(gòu)應(yīng)當(dāng)盡可能的模擬實(shí)際問題。 3. 設(shè)計(jì)應(yīng)當(dāng)表現(xiàn)出一致性。 4. 不要把設(shè)計(jì)當(dāng)成編寫代碼。 5. 在創(chuàng)建設(shè)計(jì)時(shí)就應(yīng)該能夠評(píng)估質(zhì)量。 6.

11、評(píng)審設(shè)計(jì)以減少語(yǔ)義性的錯(cuò)誤。 什么是UP， RUP? 統(tǒng)一過程（RUP/UP，Rational Unified Process）是一種以用例驅(qū)動(dòng)、以體系結(jié)構(gòu)為核心、迭代及增量的軟件過程模型，由UML方法和工具支持，廣泛應(yīng)用于各類面向?qū)ο箜?xiàng)目。 統(tǒng)一過程是一個(gè)面向?qū)ο笄一诰W(wǎng)絡(luò)的程序開發(fā)方法論。Chapter03 什么是項(xiàng)目調(diào)度？活動(dòng)？里程碑？（83頁(yè)） 項(xiàng)目調(diào)度：通過列舉項(xiàng)目的各個(gè)階段，把每個(gè)階段分解成離散的任務(wù)或活動(dòng)，來描述特定項(xiàng)目的軟件開發(fā)周期。 項(xiàng)目進(jìn)度是對(duì)特定項(xiàng)目的軟件開發(fā)周期的刻畫。 活動(dòng)：是項(xiàng)目的一部分，它在一段時(shí)間內(nèi)發(fā)生。 ：是活動(dòng)的完成某一特定的時(shí)刻。里程碑 如何計(jì)算軟件項(xiàng)目活

12、動(dòng)圖的關(guān)鍵路徑？（習(xí)題2，3）冗余時(shí)間？最早和最遲開始時(shí)間（課堂習(xí)題講解） 關(guān)鍵路徑是一條每個(gè)節(jié)點(diǎn)的時(shí)差都為零的路徑。最長(zhǎng)路徑就是一條關(guān)鍵路徑。 時(shí)差=可用時(shí)間-真實(shí)時(shí)間 最早開始時(shí)間-=最晚開始時(shí)間時(shí)差 軟件人員應(yīng)該具備的能力是什么？（96頁(yè)） 完成工作的能力，對(duì)工作的興趣，開發(fā)類似應(yīng)用的經(jīng)驗(yàn)， -精品 文檔- 精品文檔就在這里- -各類專業(yè)好文檔，值得你下載，教育，管理，論文，制度，方案手冊(cè)，應(yīng)有盡有- 使用類似工具或語(yǔ)言、開發(fā)環(huán)境、技術(shù)的經(jīng)驗(yàn)，培訓(xùn)， 與其他人交流的能力，與其他人共同承擔(dān)責(zé)任的能力。管理技能 頁(yè)）軟件項(xiàng)目組織的基本結(jié)構(gòu)？（101 108頁(yè)）專家估算法的大致含義？（106頁(yè)

13、），算式估算法的大致含義？（/ ，和y）x）、一個(gè)樂觀的預(yù)測(cè)（專家估算：請(qǐng)幾位專家做出3種預(yù)測(cè)，來形式化地表示類推過程：一個(gè)悲觀的預(yù)測(cè)（概率分布的平均值。通過使用這種技術(shù)，產(chǎn)生的估beta）/6計(jì)算這些數(shù)的x+4y+z最可能的預(yù)測(cè)（z），通過公式（ 。算是對(duì)個(gè)人估算的“規(guī)范化”這些模型通常用方研究人員已經(jīng)創(chuàng)建出表示工作量和影響工作量的因素之間關(guān)系的模型。算式估算（這個(gè)不用看）：。其) m(X)程式描述。大部分模型認(rèn)為項(xiàng)目規(guī)模是方程式中影響最大的因素，表示工作量的方程是：E = (a + bSc是基于這些因素的一個(gè)的一個(gè)成本因素的向量，m到X是從x1xn、中S是估算的系統(tǒng)規(guī)模，而ab、c是常量。

14、 調(diào)整因子。 111頁(yè)）COCOMO模型的三個(gè)階段基本工作原理或含義。（試述 ：根據(jù)高層的工作量生成器來獲取項(xiàng)目的規(guī)模。階段1（應(yīng)用組裝） ：使用功能點(diǎn)對(duì)規(guī)模進(jìn)行測(cè)量。階段2（早期設(shè)計(jì)） ：根據(jù)功能點(diǎn)或代碼行來進(jìn)行規(guī)模預(yù)算。3（后體系結(jié)構(gòu)）階段 122頁(yè)）什么是軟件風(fēng)險(xiǎn)？有幾種降低風(fēng)險(xiǎn)的策略？（119、 風(fēng)險(xiǎn)：人們不希望看到的、有負(fù)面結(jié)果的事件。 通過改變性能或功能需求來降低風(fēng)險(xiǎn) 通過把風(fēng)險(xiǎn)分配到其他系統(tǒng)中，或者購(gòu)買保險(xiǎn)以便在風(fēng)險(xiǎn)成為事實(shí)彌補(bǔ)經(jīng)濟(jì)上的損失 假設(shè)風(fēng)險(xiǎn)會(huì)發(fā)生，接受并用項(xiàng)目資源控制風(fēng)險(xiǎn) Chapter04 ) ? (143頁(yè)需求的含義是什么 需求，就是對(duì)期望的行為的表達(dá)。 - 精品-

15、 文檔 精品文檔就在這里- -各類專業(yè)好文檔，值得你下載，教育，管理，論文，制度，方案手冊(cè)，應(yīng)有盡有- 4.1）需求作為一個(gè)工程，其確定需求的過程是什么？（144頁(yè) 圖 舉例說明獲取需求時(shí)，若有沖突發(fā)生時(shí)，如何考慮根據(jù)優(yōu)先級(jí)進(jìn)行需求分類。（152頁(yè)） 絕對(duì)要滿足的需求（必須的）（1） ）非常值得要的但并非必須的需求（值得要的 （2） ）可要可不要的需求（可選的（3） 、要求購(gòu)買類型分析例如：信用卡記賬系統(tǒng)，要求列出最近的費(fèi)用、要求加起來并要求在某日期前支付）1（2）3（ ）151-152 /如何使需求變得可測(cè)試？（頁(yè), sidebar4.4 A: 針對(duì)需求確定一種量化的描述方法，避免模糊的表達(dá)

16、方式 將各種指代用詞替換為實(shí)體的正式名稱B: 每個(gè)名詞或款項(xiàng)應(yīng)在需求文檔中給出唯一定義。C: 需求文檔分為哪兩類？（153頁(yè)） 需求定義，它面向的是業(yè)務(wù)相關(guān)的人員，例如：委托人，客戶以及用戶； ，它面向的是技術(shù)性人員，例如：設(shè)計(jì)人員、測(cè)試人員以及項(xiàng)目經(jīng)理。需求規(guī)格說明 /什么是功能性需求和非功能性需求質(zhì)量需求？ 頁(yè)）/設(shè)計(jì)約束？過程約束？（149 根據(jù)要求的活動(dòng)（如對(duì)輸入的反應(yīng)，活動(dòng)發(fā)生時(shí)每一個(gè)實(shí)體之前和之后的狀態(tài)）來描述需要的行為。功能需求高可靠性或，描述一些軟件解決方案必須擁有的質(zhì)量特性，如快速的響應(yīng)時(shí)間、易使用性、質(zhì)量需求非功能性需求/ 低維護(hù)代價(jià)。 設(shè)計(jì)約束是已經(jīng)作出的設(shè)計(jì)決策或限制問

17、題解決方案集的設(shè)計(jì)決策，例如平臺(tái)或構(gòu)建接口的選擇。是對(duì)于構(gòu)建系統(tǒng)的技術(shù)和資源的限制。例如，客戶可能堅(jiān)持使用敏捷方法，以便在繼續(xù)增加新特征的時(shí)候過程約束 能夠使用早期版本。 頁(yè)）需求的特性？（正確性、一致性、完整性）（155 ：我們和客戶都應(yīng)該評(píng)審需求文檔，確保它們符合我們對(duì)需求的理解正確 一致：一般來講，如果不可能同時(shí)滿足兩個(gè)需求，那么這兩個(gè)需求就是不一致的。 無二義：如果需求的多個(gè)讀者能夠一致、有效地解釋需求，那么需求就是無二義性的。：如果需求指定了所有約束下的、所有狀態(tài)下的、所有可能的輸入的輸出以及必需的行為，那么這組需求就是完備 完備的。 ：當(dāng)用戶要求兩個(gè)或更多的質(zhì)量需求時(shí)，常常會(huì)出現(xiàn)可

18、行性問題可行 相關(guān)：有時(shí)，某個(gè)需求會(huì)不必要地限制開發(fā)人員，或者會(huì)包含與客戶需要沒有直接關(guān)系的功能。- -精品 文檔 精品文檔就在這里- 各類專業(yè)好文檔，值得你下載，教育，管理，論文，制度，方案手冊(cè)，應(yīng)有盡有- ，需求就是可測(cè)試的?？蓽y(cè)試：如果需求能夠提示驗(yàn)收測(cè)試（明確證明最終系統(tǒng)是否滿足需求）求定義中的每一條都在需求規(guī)格說明中有對(duì)應(yīng)，已達(dá)到易于引用的目的；可跟蹤：對(duì)需求進(jìn)行精心組織并唯一標(biāo)記， 反之亦然。 圖的構(gòu)成及畫法（DFD172頁(yè)）了解 ：Data Flow Diagrams 數(shù)據(jù)流圖DFD 在需求原型化方面，什么是拋棄型原型？什么是演化型原型？（192-193頁(yè)） 拋棄型原型是為了對(duì)問

19、題或者提議的解決方案有更多的了解而開發(fā)的軟件。 不僅幫助我們回答問題，而且還要演變?yōu)樽罱K的產(chǎn)品。 演化型原型是這樣的軟件： Chapter05 223-224什么是軟件體系結(jié)構(gòu)？設(shè)計(jì)模式？設(shè)計(jì)公約？設(shè)計(jì)？概念設(shè)計(jì)？技術(shù)設(shè)計(jì)？（ 頁(yè)） 早期的設(shè)計(jì)決策專注于系統(tǒng)的體系結(jié)構(gòu)，用以解釋如何將系統(tǒng)分解為單元以及這些單元又如何相互關(guān)聯(lián) 三種設(shè)計(jì)層次及其關(guān)系？（229頁(yè)） 體系結(jié)構(gòu)設(shè)計(jì):由軟件需求中的系統(tǒng)能力與系統(tǒng)部件關(guān)聯(lián)起來而得到軟件整體結(jié)構(gòu)的過程 代碼設(shè)計(jì):各個(gè)部件（模塊）的算法、數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì) 運(yùn)行設(shè)計(jì):最底層設(shè)計(jì)內(nèi)存分配、數(shù)據(jù)格式、位模式等等 關(guān)系：流程工作中，先是體系結(jié)構(gòu)設(shè)計(jì)，然后是代碼設(shè)計(jì)，最后

20、是運(yùn)行設(shè)計(jì)； 隨著設(shè)計(jì)人員對(duì)解決方案及其含義有更多的理解，他們就會(huì)往返于各層次之間。 （程序設(shè)計(jì)由代碼設(shè)計(jì)和運(yùn)行設(shè)計(jì)組成） 論述設(shè)計(jì)用戶界面應(yīng)考慮的問題。（242頁(yè)） 設(shè)計(jì)界面要注意解決的要素（寓意/比喻、思維模型、領(lǐng)航規(guī)則、外觀、感覺）； 文化差異問題； 用戶愛好問題 Chapter06 什么是模塊化？什么是抽象？（238頁(yè)） 模塊化，也稱作關(guān)注點(diǎn)分離，是一種把系統(tǒng)中各不相關(guān)的部分進(jìn)行分離的原則，以便于各部分能夠獨(dú)立研究。 -精品 文檔- 精品文檔就在這里- 各類專業(yè)好文檔，值得你下載，教育，管理，論文，制度，方案手冊(cè)，應(yīng)有盡有- 。對(duì)細(xì)節(jié)的隱藏稱為抽象 248-xxx頁(yè)）-模塊獨(dú)立性-耦合

21、與內(nèi)聚的概念及各個(gè)層次劃分？（節(jié)5.5 耦合：兩個(gè)軟件部件之間的相互關(guān)聯(lián)程度 內(nèi)聚：軟件部件內(nèi)部的關(guān)聯(lián)程度 層次劃分：如下 舉例說明耦合與內(nèi)聚的基本分類。以及各個(gè)分類的含義與特征（284頁(yè)習(xí)題4，5） 非直接耦合 ：模塊相互之間沒有信息傳遞 數(shù)據(jù)耦合 ：模塊間傳遞的是數(shù)據(jù) 特征耦合：模塊間傳遞的是數(shù)據(jù)結(jié)構(gòu) 控制耦合：模塊間傳遞的是控制量 公共耦合：不同模塊訪問公共數(shù)據(jù) 內(nèi)容耦合：一個(gè)模塊直接修改另一個(gè) 偶然性內(nèi)聚：不相關(guān)的功能, 過程,數(shù)據(jù)等出現(xiàn)在同一個(gè)部件中 邏輯性內(nèi)聚：邏輯上相關(guān)或相似的功能或數(shù)據(jù)放置在同一個(gè)部件內(nèi) 時(shí)間性內(nèi)聚：部件各部分要求在同一時(shí)間完成 通訊性內(nèi)聚：各部分訪問共享數(shù)據(jù)

22、過程性內(nèi)聚：各部分有特定次序 順序性內(nèi)聚：各部分有輸入輸出關(guān)系 功能性內(nèi)聚：各部分組成單一功能 /什么是面向?qū)ο?？?86頁(yè)） 面向?qū)ο笫且环N軟件開發(fā)方法，它將問題及其解決方法組織成一系列獨(dú)立的對(duì)象，數(shù)據(jù)結(jié)構(gòu)和動(dòng)作都被包括在內(nèi) OO有幾個(gè)基本特征？如何使用高級(jí)語(yǔ)言實(shí)現(xiàn)這些基本特/征？了解并使用高級(jí)語(yǔ)言的OO基本編程方法和技巧。（286-291） 基本特征：一致性、抽象、分類、封裝、繼承、多態(tài)、持久性 /什么是設(shè)計(jì)模式？ 設(shè)計(jì)模式編寫了設(shè)計(jì)決策以及最好的實(shí)踐，它們根據(jù)設(shè)計(jì)原則來解決一些特定的問題； 它們不是拿來就可以使用的打包的解決方案，而是解決方案的模板，必須針對(duì)特定的狀況進(jìn)行修改和調(diào)整。 /

23、OO設(shè)計(jì)的基本原則？ 模塊化、接口、信息隱藏、增量式開發(fā)、抽象、通用性 OO開發(fā)有何優(yōu)勢(shì)？（291頁(yè)） 語(yǔ)言具有一致性（在同一時(shí)期同時(shí)描述問題和解決方案）； 。過程具有一致性（從需求到測(cè)試，所有的過程采用相同的語(yǔ)義構(gòu)造） OO開發(fā)過程有幾個(gè)步驟？（292頁(yè)） -精品 文檔- 精品文檔就在這里- -各類專業(yè)好文檔，值得你下載，教育，管理，論文，制度，方案手冊(cè)，應(yīng)有盡有- 測(cè)試OOOO低級(jí)設(shè)計(jì)、OOP、OO需求、OO高級(jí)設(shè)計(jì)、 294熟悉用例圖的組成和畫法，用例的幾個(gè)要素的含義，掌握用例圖的實(shí)例解析方法（ 頁(yè)） 用例圖、類圖等對(duì)面向?qū)ο蟮捻?xiàng)目開發(fā)的意義是什么？ 這些表示法每種都顯現(xiàn)了系統(tǒng)的某個(gè)方面

24、，因此相應(yīng)地，這種表達(dá)也提供了對(duì)于問題或解決方案的詳細(xì)描述。 ）熟悉類圖中各個(gè)類之間的基本關(guān)系分類（303-305 頁(yè)）熟悉類圖等的組成和畫法（300-308 其他圖的基本用途。了解UML Chapter07 頁(yè)）/為什么說編碼工作是紛繁復(fù)雜甚至令人氣餒？（337 第一，設(shè)計(jì)對(duì)于編碼來說并不總是簡(jiǎn)單明了的； 第二， 編碼應(yīng)該是可懂的 第三， 需要考慮重用 340-344頁(yè)）一般性的編程原則應(yīng)該從哪三個(gè)方面考慮？（ 編程標(biāo)準(zhǔn)對(duì)自身的用處 編程標(biāo)準(zhǔn)對(duì)他人的用處 設(shè)計(jì)與編程實(shí)現(xiàn)相匹配 342頁(yè)）/論述編碼階段實(shí)現(xiàn)某種算法時(shí)所涉及的問題。（ 編寫更快代碼的代價(jià)?？赡軙?huì)使代碼更加復(fù)雜，從而花費(fèi)更多的時(shí)間

25、編寫代碼。 測(cè)試代碼的時(shí)間代價(jià)。代碼的復(fù)雜度要求有更多的測(cè)試用例或測(cè)試數(shù)據(jù)。 用戶理解代碼的時(shí)間代價(jià)。 需要修改代碼時(shí)，修改代碼的時(shí)間代價(jià)。 頁(yè)）HCB外，還應(yīng)添加什么注釋信息？（352-354在編寫程序內(nèi)部文檔時(shí)，除了 文檔化數(shù)據(jù)安排格式以增強(qiáng)理解、4.1.其他程序注釋、2.有意義的變量名和語(yǔ)句標(biāo)記、3. 什么是極限編程(XP)? 以及派對(duì)編程？(357頁(yè)) 極限編程（XP）是一種輕量級(jí)的軟件開發(fā)方法論，屬于敏捷開發(fā)方法。XP從實(shí)踐中來，是對(duì)實(shí)踐的總結(jié)，也是經(jīng)過實(shí)踐檢驗(yàn)的，其主要特征是要適應(yīng)環(huán)境變化和需求變化，充分發(fā)揮開發(fā)人員的主動(dòng)精神。XP承諾降低軟件項(xiàng)目風(fēng)險(xiǎn)，改善業(yè)務(wù)變化的反應(yīng)能力，提高

26、開發(fā)期間的生產(chǎn)力，為軟件開發(fā)過程增加樂趣等等 。 派對(duì)編程屬于主要的敏捷開發(fā)方法，其開發(fā)方式是兩個(gè)程序員共同開發(fā)程序，且角色分工明確。一個(gè)負(fù)責(zé)編寫程序，另一個(gè)負(fù)責(zé)復(fù)審與測(cè)試。兩人定期交換角色。 -精品 文檔- 精品文檔就在這里 -各類專業(yè)好文檔，值得你下載，教育，管理，論文，制度，方案手冊(cè)，應(yīng)有盡有- - Chapter08 / 產(chǎn)生軟件缺陷的原因？（365頁(yè)） 規(guī)格說明可能是錯(cuò)誤的，或者遺漏了某個(gè)需求； 對(duì)于指定的硬件和軟件，規(guī)格說明中可能包含不可能實(shí)現(xiàn)的需求 系統(tǒng)設(shè)計(jì)中可能包含故障。 程序設(shè)計(jì)中可能包含故障。 程序代碼可能是錯(cuò)誤的。 /將軟件缺陷進(jìn)行分類的理由？（367頁(yè)） 當(dāng)不存在明顯的

27、故障時(shí)，我們就測(cè)試程序，通過創(chuàng)造一些條件，使代碼不能像計(jì)劃的那樣做出反應(yīng)，看一看能否發(fā) 現(xiàn)更多的故障。因此，知道我們正在查找什么類型的故障是很重要的。 幾種主要的缺陷類型？（367-368頁(yè)） A. 算法故障 B. 計(jì)算故障和精度故障 C. 文檔故障 D. 壓力故障或過載故障 E. 能力故障或邊界故障 F. 計(jì)時(shí)故障 G. 性能故障 H. 恢復(fù)故障 I. 硬盤和系統(tǒng)軟件故障 J. 標(biāo)準(zhǔn)和過程路障 什么是正交缺陷分類？（369頁(yè)） 其中，故障被分為不同的類別，這些類別共同勾畫出開發(fā)過程的哪些部分需要關(guān)注，因?yàn)樗鼈兪钱a(chǎn)生很多故障的原 因。因此，分類方案必須是產(chǎn)品無關(guān)的和組織無關(guān)的，并且可適用于開發(fā)

28、的所有階段的。 / 測(cè)試的態(tài)度問題？（為什么要獨(dú)立設(shè)置測(cè)試團(tuán)隊(duì)？）（373頁(yè)） 即使用忘我方法開發(fā)一個(gè)系統(tǒng)，有時(shí)也難以從測(cè)試過程中排除個(gè)人感情。因此，通常使用一個(gè)獨(dú)立的測(cè)試小組來測(cè) 試系統(tǒng)，這樣，避免了故障的個(gè)人責(zé)任與盡可能多地發(fā)現(xiàn)故障的需要之間的沖突。 測(cè)試的各個(gè)階段及其任務(wù)？（372頁(yè)圖8.3） -精品 文檔- 精品文檔就在這里- 各類專業(yè)好文檔，值得你下載，教育，管理，論文，制度，方案手冊(cè)，應(yīng)有盡有- ）黑盒、白盒的概念？（測(cè)試的方法-374：從外部觀察測(cè)試對(duì)象，將其看做是一個(gè)不了解其內(nèi)容的閉盒或黑盒，那么，我們的測(cè)試就是向閉盒提供輸入黑盒 數(shù)據(jù)，并記錄產(chǎn)生的輸出。 ：將測(cè)試對(duì)象看成是一

29、個(gè)開盒（透明盒）或白盒，然后可以根據(jù)測(cè)試對(duì)象的結(jié)構(gòu)用不同的方式來進(jìn)行測(cè)試。白盒 什么是單元測(cè)試？ 什么是走查和審查？（376頁(yè)） 單元測(cè)試：檢查集成的系統(tǒng)是否按照需求中指定的那樣執(zhí)行它的功能 在走查中，程序員向評(píng)審小組提交代碼及其相關(guān)文檔，然后評(píng)審小組評(píng)論它們的正確性。 在審查中，評(píng)審小組按照一個(gè)事前準(zhǔn)備好的關(guān)注問題清單來檢查代碼和文檔（更正式）。 黑盒白盒方法各自的分類？測(cè)試用例的設(shè)計(jì)和給出方法（結(jié)合補(bǔ)充材料） 黑盒白盒方法的分類，各種覆蓋方法等。（課件和補(bǔ)充課件） -精品 文檔- 精品文檔就在這里 -各類專業(yè)好文檔，值得你下載，教育，管理，論文，制度，方案手冊(cè)，應(yīng)有盡有- - 考慮如何面對(duì)

30、一個(gè)命題，設(shè)計(jì)和給出測(cè)試用例的問題。（課件） -課堂練習(xí)的測(cè)試題目和講解內(nèi)容 集成測(cè)試及其主要方法的分類？（390-392）（驅(qū)動(dòng)，樁的概念） （1） 自低向上集成（驅(qū)動(dòng)程序） 優(yōu)點(diǎn)：易生成測(cè)試用例；適合于面向?qū)ο箝_發(fā)系統(tǒng)；底層為通用模塊比較好 缺點(diǎn)：頂層設(shè)計(jì)缺陷為主要的缺陷，不能及時(shí)地發(fā)現(xiàn)改正 （2） 自頂向下集成（樁） 優(yōu)點(diǎn)：頂層模塊缺陷盡早發(fā)現(xiàn) 缺點(diǎn)：產(chǎn)生測(cè)試用例比較難，需要大量的樁 傳統(tǒng)測(cè)試和OO測(cè)試有何不同？OO測(cè)試有何困難？（398-399頁(yè)） 面向?qū)ο笙到y(tǒng)的測(cè)試中更容易和更困難的部分： /測(cè)試計(jì)劃涉及的幾個(gè)步驟？40頁(yè) （1）制定測(cè)試目標(biāo) （2）設(shè)計(jì)測(cè)試用例 （3）編寫測(cè)試用例

31、（4）測(cè)試測(cè)試用例 （5）執(zhí)行測(cè)試 ）評(píng)估測(cè)試結(jié)果6（了解） Chapter09 系統(tǒng)測(cè)試的主要步驟及各自含義？（420頁(yè), 圖9.2） 1. 功能測(cè)試：系統(tǒng)是否按照需求中指定的那樣執(zhí)行它的功能 2. 性能測(cè)試：軟件與非功能系統(tǒng)需求進(jìn)行比較 3. 驗(yàn)收測(cè)試：根據(jù)用戶的需求描述檢查系統(tǒng) 4. 安裝測(cè)試：保證系統(tǒng)按照它應(yīng)有的方式進(jìn)行- 文檔 精品- 精品文檔就在這里- 各類專業(yè)好文檔，值得你下載，教育，管理，論文，制度，方案手冊(cè)，應(yīng)有盡有- 什么是系統(tǒng)配置？軟件配置管理？基線？（423頁(yè)）（或見課件）/ 系統(tǒng)配置是向特定客戶交付的一組系統(tǒng)組件。 配置管理控制不同系統(tǒng)配置之間的差別，將風(fēng)險(xiǎn)和錯(cuò)誤降低到最低程度。 某個(gè)特定系統(tǒng)的一個(gè)配置有時(shí)稱為一個(gè)版本 是軟件文檔或源碼的一個(gè)穩(wěn)定版本,它是進(jìn)一步開發(fā)的基礎(chǔ)（這基線我百度的）基線 什么是回歸測(cè)試？（425頁(yè)）/ 回歸測(cè)試是用于新的版本或發(fā)布的一種測(cè)試，以驗(yàn)證與舊版本或發(fā)布相比，它是否以同樣的方式執(zhí)行相同的功能。 430頁(yè)）功能測(cè)試的含義及其作用？（ 相反，必須知道系統(tǒng)應(yīng)該做什么。功能測(cè)試基于系統(tǒng)功能性需求