軟件工程課件2年下半年部分題目網(wǎng)工略過版

1、目 錄第 1 章 軟件工程基礎(chǔ)知識11.11.21.31.4什么是軟件？1軟件及軟件工程？1有哪些流行的軟件工程方法學(xué)及其要素？1什么是軟件生存周期？有哪些活動？11.4.1 問題定義-“要解決的問題是什么？”11.4.2 可行性分析和項目開發(fā)計劃-“有行得通的解決方案嗎？”11.4.3 需求分析和定義-“系統(tǒng)必須做什么？”11.4.4 概要設(shè)計-“概括地說，應(yīng)該怎樣做？”21.4.5 詳細設(shè)計-“具體怎么樣做？”21.4.6 編碼-代碼實現(xiàn)21.4.7 測 試21.4.8 運行維護2各活動階段主要文檔21.5.1 可行性分析和項目開發(fā)計劃21.5.2 需求分析中的文檔21.5.3 概要設(shè)計階

2、段文檔21.5.4 詳細設(shè)計階段21.5.5 編碼21.5.6 測試31.5.7 系統(tǒng)測試階段3有哪些主要生存期模型？31.6.1 瀑布模型(傳統(tǒng)的軟件周期模型)31.6.2 原型模型31.6.3 螺旋模型41.6.4 噴泉模型41.6.5 敏捷開發(fā)方法5軟件過程基礎(chǔ)知識71.7.1 軟件過程71.7.2 評估工具7軟件工程項目管理基本知識81.8.1 時間管理81.8.2 成本管理91.8.3 風(fēng)險管理101.51.61.71.81.8.4組織管理111.9軟件配置管理121.10 模塊化基本知識121.10.1 模塊特性131.10.2 模塊與模塊的耦合性（7 種）131.10.3 模塊的

3、內(nèi)聚性131.10.4 模塊的深度、寬度、扇出與扇入141.10.5 模塊作用域和域141.10.6 模塊化基礎(chǔ)知識小結(jié)141.11 什么是軟件開發(fā)方法？有哪些主要方法？151.11.1 結(jié)構(gòu)化方法學(xué)151.11.2 結(jié)構(gòu)化設(shè)計161.11.3 詳細設(shè)計階段設(shè)計質(zhì)量度量方法 McCabe（網(wǎng)工略過）171.11.4 Jackson 方法191.12 軟件工具191.13 軟件質(zhì)量管理基礎(chǔ)知識191.14 軟件質(zhì)量191.15 容錯系統(tǒng)201.16 McCall 軟件質(zhì)量模型（網(wǎng)工略過）201.17 代碼評審技術(shù)211.18 軟件測試211.18.1 軟件測試經(jīng)過的步驟211.18.2 白盒測試

4、211.18.3 黑盒測試221.18.4 灰盒測試231.18.5 回歸測試231.18.6 單元測試231.18.7 集成測試231.18.8 確認測試231.18.9 系統(tǒng)測試231.19 軟件工程標準和軟件文檔241.20 軟件維護241.20.1 軟件維護類型241.20.2 軟件的可維護性251.21. 25第1章軟件工程基礎(chǔ)知識1.1 什么是軟件？1. 滿足用戶功能需求和性能需求的指令或計算機程序集合；2. 處理信息的數(shù)據(jù)結(jié)構(gòu)；3. 描述程序功能以及程序如何操作和使用所要求的文檔。以上三部分的組合了軟件。1.2 軟件及軟件工程？軟件是指在計算機軟件的開發(fā)和維護過程中所遇到的一序列

5、嚴重問題，在 20 世紀 60 年代末全面爆發(fā)，1968 年，北大西洋公約組織提出使用工程的概念、原理、技術(shù)和方法來開發(fā)與維護軟件，即以工程化的方式組織軟件的開發(fā)。產(chǎn)生軟件的可歸結(jié)為兩個重要的方面：軟件生產(chǎn)本身存在的復(fù)雜性；軟件開發(fā)所使用的方法和技術(shù)。注意：我們只能盡力減少軟件的危害，不可能徹底消除軟件，猶如人類的感冒，永遠不可能徹底消除！1.3 有哪些流行的軟件工程方法學(xué)及其要素？1. 使用最廣泛的軟件工程方法學(xué)是面向結(jié)構(gòu)化方法學(xué)、迭代化方法學(xué)、面向?qū)ο蠓椒▽W(xué)（上世紀 70-90 年代，流行面向結(jié)構(gòu)化方法學(xué)，上世紀 90 年代到現(xiàn)在，流行面向?qū)ο蠓椒▽W(xué)）。2. 要素：方法、工具和過程。1.4

6、 什么是軟件生存周期？有哪些活動？軟件生存周期指的是：一個軟件從提出開發(fā)要求開始到軟件廢棄不用的整個過程。而個軟件的活動從前往后依次是：問題定義、可行性分析和項目開發(fā)計劃、需求分析和定義、軟件設(shè)計（先后細分為：概要設(shè)計和詳細設(shè)計）、編碼、測試和運行維護。1.4.1 問題定義-“要解決的問題是什么？”通過對客戶的，系統(tǒng)分析員扼要地寫出關(guān)于問題性質(zhì)、工程目標和工程規(guī)模的報告，經(jīng)過討論和必要的修改之后這份報告應(yīng)該得到客戶的確認。參與人：用戶、系統(tǒng)分析員、項目。1.4.2 可行性分析和項目開發(fā)計劃-“有行得通的解決方案嗎？”用戶、項目和系統(tǒng)分析師搞清楚系統(tǒng)要解決的問題是什么？以及從技術(shù)、等方面論證項目

7、開發(fā)可行性。1. 技術(shù)可行性：現(xiàn)有的技術(shù)是否能夠有效地解決該問題？是否有多種不同的解決方案？現(xiàn)有的技術(shù)力量是否達到？2.何？3.可行性：所有可能的解決方案所需投入的成本能否超過它的開發(fā)成本？它的成本效益分析結(jié)果如何？投資回報率如可行性：該解決方案是否符合企業(yè)實際情況？是否符合員工利益？是否符合相關(guān)和行業(yè)規(guī)范？1.4.3 需求分析和定義-“系統(tǒng)必須做什么？”用戶、項目求，從而確和系統(tǒng)分析師確必須做什么？但不關(guān)心具體怎么做？要確的功能、性能、數(shù)據(jù)、界面等要的邏輯模型，同時制定后期測試計劃。1. 需求分析的任務(wù) （2014 年上）以下關(guān)于文檔的敘述中，不正確的是 (33) 。（33）A文檔僅僅描述和

8、規(guī)定了軟件的使用范圍及相操作命令 B文檔也是軟件的一部分，沒有文檔的軟件就不能稱之為軟件 C軟件文檔的編制在軟件開發(fā)工作中占有突出的地位和相當(dāng)大的工作量D高質(zhì)量文檔對于發(fā)揮軟件的效益有著重要的意義(1) 確定軟件系統(tǒng)的綜合要求：界面要求，功能要求，性能要求，安全性、理要求，將來可能提出的要求。性、可靠性要求，系統(tǒng)運行要求，異常處(2)(3)(4)(5)分析系統(tǒng)的數(shù)據(jù)要求：數(shù)據(jù)元素、數(shù)據(jù)元間的邏輯關(guān)系、數(shù)據(jù)量和峰值等。常用的數(shù)據(jù)描述是實體-關(guān)系模型。導(dǎo)的邏輯模型：結(jié)構(gòu)化分析方法中使用數(shù)據(jù)流圖；面向?qū)ο蠓治龇椒ㄖ惺褂妙惸Ｐ?類圖)修正項目開發(fā)計劃：在明確了用戶的真正需求后，可以更準確地估算軟件的成

9、本和進度，從而修正項目開發(fā)計劃如果必要，可個原型系統(tǒng)來獲取用戶真正的需求。2. 需求的分類(1)(2)(3)功能需求：所開發(fā)的軟件必須具備什么樣的功能。非功能需求：指必須具備的屬性或品質(zhì)，如可靠性、性能、相應(yīng)時間、容錯性和擴展性等。設(shè)計約束：也稱為限制條件、補充規(guī)約，這通常是對解決方案的一些約束說明。1.4.4 概要設(shè)計-“概括地說，應(yīng)該怎樣做？”系統(tǒng)分析師和軟件設(shè)計師在需求定義的基礎(chǔ)上，把各功能需求轉(zhuǎn)換成需要的體系結(jié)構(gòu)，即劃分模塊、模塊的層次、模塊之間的調(diào)用關(guān)系以及各模塊的功能，同時設(shè)計應(yīng)用系統(tǒng)的總體數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)庫結(jié)構(gòu)。特例：進銷存分為進、銷、存三個模塊。1.4.5 詳細設(shè)計-“具體怎么樣

10、做？”軟件設(shè)計師和程序員對概要設(shè)計階段得出的各功能模塊進行詳細描述成精確的、結(jié)構(gòu)化的過程描述，即各個功能模塊具體怎么實現(xiàn)，用相應(yīng)的工具把模塊的結(jié)構(gòu)表示出來，但還未進行編碼。1.4.6 編碼-代碼實現(xiàn)由程序員把詳細設(shè)計階段得出的各模塊結(jié)構(gòu)（圖形）轉(zhuǎn)變成計算機能識別的指令代碼。1.4.7 測 試由另一部門（）的軟件設(shè)計師或系統(tǒng)分析師花費最少的人力物力找出程序最多、最大的錯誤（bug）-“高產(chǎn)測試”,再高產(chǎn)的測試工作也只能發(fā)現(xiàn)大約 80%的軟件問題，不可能 100%的發(fā)現(xiàn)。1.4.8 運行維護由用戶和維護進行的軟件生存周期中時間最長的階段。1.5 各活動階段主要文檔1.5.1 可行性分析和項目開發(fā)計

11、劃nn可性行項目開發(fā)計劃1.5.2 需求分析中的文檔nnnnn需求規(guī)格說明書 初步用戶使用手冊確認測試的測試計劃修改完善的軟件開發(fā)計劃系統(tǒng)測試計劃文檔1.5.3 概要設(shè)計階段文檔nnnn概要設(shè)計說明書數(shù)據(jù)庫說明書 用戶手冊修訂的測試計劃（測試的策略、方法、步驟）1.5.4 詳細設(shè)計階段n詳細設(shè)計說明書1.5.5 編碼n程序1.5.6 測試nn完善的測試計劃書軟件測試報告1.5.7 系統(tǒng)測試階段n系統(tǒng)測試報告1.6 有哪些主要生存期模型？瀑布模型、原型開發(fā)模型（快速原型模型、演化模型、增量模型）、螺旋模型、噴泉模型、基于知識的模型和變化模型。1.6.1 瀑布模型(傳統(tǒng)的軟件周期模型)瀑布模型嚴格

12、遵循軟件生命周期各階段的固定順序：計劃、分析、設(shè)計、編程、測試和維護，上一階段完成后才能進入到下一階段，整個模型就像一個飛流直下的瀑布，如圖 1.1 所示。圖 1.1 瀑布模型采用規(guī)范的方法，嚴格規(guī)定了各階段必須提交的文檔；要求每一階段結(jié)束后，都要優(yōu)點：以文檔作為驅(qū)動，強迫開發(fā)進行嚴格的評審。與它最相適應(yīng)的開發(fā)方法是結(jié)構(gòu)化方法。缺點：不適應(yīng)用戶需求的改動。1.6.2 原型模型1. 快速原型模型快速原型的用途是獲知用戶的真正需求，一旦需求確定了，原型即被拋棄。主要用于需求分析階段。不追求也不可能要求對需求的嚴格定義，而是采用了動態(tài)定義需求的方法，所以不能定義完善的文檔。特征：簡化項目管理、盡快建

13、立初步需求、加強用戶參與和決策。具有廣泛技能水平的原型化是原型實施的重要保證。原型化應(yīng)該是具有經(jīng)驗與、訓(xùn)練有素的專業(yè)。衡量原型化能力的重要標準是他是否能夠從用戶的模糊描述中快速獲取需求。2. 演化模型在快速原型模型中，原型的用途是獲知用戶的真正需求，一旦需求確定了，原型即被拋棄。而演化模型應(yīng)用于整個軟件開發(fā)過程，是從初始模型逐步演化為最終軟件 的漸進過程。也就是說，快速原型模型是一種“拋棄式”的原型化方法，而演化模型則是一種“漸進式”的原型化方法。3. 增量模型(漸增式)增量模型主要用于設(shè)計階段，把軟件劃分為一系列的增量構(gòu)件，分別進行設(shè)計、編程、集成和測試。新的增量構(gòu)件不得破壞已經(jīng)開發(fā)出來的。

14、其示意圖如圖 1.2 所示。 (20014 年下)軟件開發(fā)中的瀑布模型典型的刻畫了軟件生存周期的階段劃分，與其最相適應(yīng)的軟件開發(fā)方法是 (9) 。（9）A.構(gòu)件化方法B.結(jié)構(gòu)化方法C.面向?qū)ο蠓椒―.快速原型法 (2005 年下)應(yīng)該在 （7） 階段制測試計劃。（7）A. 需求分析 B. 概要設(shè)計 C. 詳細設(shè)計 D. 系統(tǒng)測試 (2005 年下)（29）詳細描述軟件的功能、性能和用戶界面，以使用戶了解如何使用軟件。（29）A.概要設(shè)計說明書 B.詳細設(shè)計說明書 C.用戶手冊D.用戶需求說明書圖 1.2 增量模型4. 原型模型小結(jié)從下面的有關(guān)原型化方法的敘述中，選擇出正確的敘述：(1)快速原型

15、方法是一種企圖克服傳統(tǒng)軟件周期模型缺點的開發(fā)方法。(2)在用戶的數(shù)據(jù)沒有得到很好地組織和管理的時候，應(yīng)該使用原型化方法。(3)在用戶沒有明確地肯定其需求的時候，應(yīng)該使用原型化方法。(4)在用戶不希望把的時間軟件開發(fā)過程中的時候，應(yīng)該使用原型化方法。(5)使用原型化方法時應(yīng)該使用第三代編程語言。(6)原型化加強了開發(fā)過程中用戶的參與和決策。(7)原型化方法大致可分為三類：拋棄式、演化式和遞增式。(8)原型化方法大致可分為演化式和遞增式。(9)采用原型化方法時，軟件的開發(fā)成本較高。(10)采用原型化方法時，關(guān)鍵的因素是建立的速度，而不是運行的效率。1.6.3 螺旋模型如圖 1.3 所示，螺旋模型綜

16、合了瀑布模型和原型模型中的演化模型的優(yōu)點，還增加了風(fēng)險分析。螺旋線第一圈的開始點可能是一個概念項目。從第二圈開始，一個新命期結(jié)束。開發(fā)項目開始了，新的演化沿著螺旋線進行若干次迭代，一直轉(zhuǎn)到軟件生圖 1.3 螺旋模型1.6.4 噴泉模型噴泉模型主要用于描述面向?qū)ο蟮拈_發(fā)過程。噴泉一詞體現(xiàn)了面向?qū)ο箝_發(fā)過程的迭代和無間隙特征。迭代指的是開發(fā)活動常常需要重復(fù)多次，在不斷的迭代中逐漸完善軟件系統(tǒng)，無間歇性指在開發(fā)活動之間不存在明顯的邊界，叉、迭代地進行，如圖 1.4 所示。各開發(fā)活動交圖 1.4 噴泉模型1.6.5 敏捷開發(fā)方法1. 迭代軟件開發(fā)技術(shù)Rational 統(tǒng)一開發(fā)流程 RUP(Ration

17、al Unified Process)是一個通用的軟件流程框架，它是一個以架構(gòu)為中心、用例驅(qū)動的迭代化軟件開發(fā)流程。RUP 是從幾千個軟件項目的實踐經(jīng)驗中總結(jié)出來的，對于實際的項目具有很強的指導(dǎo)意義，是軟件開業(yè)事實上的行業(yè)標準。在 RUP 中，我們把軟件開發(fā)生命周期劃分為四個階段，每個階段的結(jié)束標志就是一個主要的里程碑（如下圖所示）。圖 1.5 RUP這四個階段主要是為了達到以下階段性的目標里程碑：nnnn先啟(Inception)：確定項目開發(fā)的目標和范圍精化(Elaboration)：確架構(gòu)和明確需求構(gòu)建(Construction)：實現(xiàn)剩余的系統(tǒng)功能化(Transition)：完成軟件的

18、化工作，將系統(tǒng)移交給客戶 （2005 年下）在個系統(tǒng)時，如果用戶對系統(tǒng)的目標不是很清楚，難以定義需求，這時最好使用 （6） 。（6）A. 原型法B. 瀑布模型C. V-模型D. 螺旋模型 （2006 年上）漸增式開發(fā)方法有利于 (4) 。(4)A.獲取軟件需求 B.快速開發(fā)軟件C.大型團隊開發(fā) D.商業(yè)軟件開發(fā) (2005 年下)在個系統(tǒng)時，如果用戶對系統(tǒng)的目標不是很清楚，難以定義需求，這時最好使用 （6） 。（6）A. 原型法B. 瀑布模型C. V-模型D. 螺旋模型 (2006 年上)漸增式開發(fā)方法有利于 (4) 。(4)A.獲取軟件需求 B.快速開發(fā)軟件 C.大型團隊開發(fā) D.商業(yè)軟件開

19、發(fā) (2006 年下)常見的軟件開發(fā)模型有瀑布模型、演化模型、螺旋模型、噴泉模型等。其中（5）模型適用于需求明確或很少變更的項目，（6）主要面向?qū)ο蟮能浖_發(fā)過程。（5） A瀑布模型B.演化模型C. 螺旋模型D.噴泉模型（6） A瀑布模型B.演化模型C. 螺旋模型D.噴泉模型2. 極限編程（XP-網(wǎng)工略過）一種輕量(敏捷)、高效、低風(fēng)險、柔性、可最大的不同在于：、科學(xué)而且充滿樂趣的軟件開發(fā)方法。與其他方法對比，1. 在更短的周期內(nèi)，更早地提供具體、持續(xù)的反饋信息2. 迭代地進行計劃編制，首先在最開始迅速生成一個總體計劃，然后在整個項目開發(fā)過程中不斷地發(fā)展3.依賴于自動測試程序來開發(fā)進度，并及早

20、地捕獲缺陷4. 依賴于口頭交流，測試和源程序5. 倡導(dǎo)持續(xù)的演化式的設(shè)計6. 依賴于開發(fā)團隊內(nèi)部的緊密協(xié)作7. 盡可能達到程序員短期利益和項目長期利益的平衡xp 由價值觀、原則、實踐和行為四個部分組成，它們彼此相互依賴、關(guān)聯(lián)，并通過行為貫穿于整個生命周期。xp 的是其總結(jié)的四大價值觀：、簡單、反饋和勇氣，它們是 xp 的基礎(chǔ)，也是 xp 的。5 個原則：快速反饋、簡單性假設(shè)、逐步修改、提倡更改和優(yōu)質(zhì)工作。在 xp 方法中，貫徹的是“小步快走”的開發(fā)原則，因此工作質(zhì)量絕不可打折扣，通常采用測試先行的編碼方式來提供支持。在 xp 中，集成了 12 個最佳實踐：計劃、小型發(fā)布、隱喻、簡單設(shè)計、測試先

21、行、重構(gòu)、結(jié)對編程、集體代碼所有制、持續(xù)集成、每周工作 40 小時，現(xiàn)場客戶，編碼標準。3. 敏捷建模（Agile Ming）AM 是一種最近才出現(xiàn)的軟件思想，一種輕方法論，XP 實踐既給了 AM 靈感，也是 AM 的一種具體實現(xiàn)。其原則為：主張簡單；擁抱變化；你的第二個目標是可持續(xù)性，簡單的說，你在開發(fā)的時候，你要能想象到未來；遞增的變化；令投資人的投資最大化；有目的的建模；多種模型；高質(zhì)量的工作；快速反饋； 軟件是項目的主要目標；輕裝前進。AM 補充原則為：內(nèi)容比表示更重要；三人行必有我?guī)?；了解你的模型；了解你的工具；局部調(diào)整；開放 (2008 年上)極限編程是一種輕量級軟件開發(fā)方法，（2

22、9)的準則不是它強調(diào)的。(29)A.持續(xù)的交流和B.用最簡單的設(shè)計 C.用測試驅(qū)動開發(fā)D.關(guān)注用戶反饋 (2009 年下)極限編程（XP）由價值觀、原則、實踐和行為四個部分組成，其中價值觀包括、簡單性、（36）。(36)A.好的計劃B.不斷的發(fā)布C.反饋和勇氣D.持續(xù)集成 （2006 年下）常見的軟件開發(fā)模型有瀑布模型、演化模型、螺旋模型、噴泉模型等。其中（5）模型適用于需求明確或很少變更的項目，（6）主要面向?qū)ο蟮能浖_發(fā)過程。（5） A瀑布模型B.演化模型C. 螺旋模型D.噴泉模型（6） A瀑布模型B.演化模型C. 螺旋模型D.噴泉模型 （2006 年下）統(tǒng)一過程（UP）的基本特征是“用例

23、驅(qū)動，以架構(gòu)為中心的和受控的迭代式增量開發(fā)”。UP 將一個周期的開發(fā)過程化分為 4 個階段，其中 (26)提交結(jié)果包含了系統(tǒng)架構(gòu)。（26）A.先啟階段B.精化階段C.構(gòu)建階段D.提交階段 （2008 年下）RUP（Rational Unified Process）分為 4 個階段，每個階段結(jié)都有重要的里程碑， 其中生命周期架構(gòu)是在 （18） 結(jié)的里程碑。（18）A.階段B.精化階段C.構(gòu)建階段D.移交階段 （2014 年上）以下關(guān)于統(tǒng)一過程 UP 的敘述中，不正確的是 (29) 。（29）AUP 是以用例和風(fēng)險為驅(qū)動，以架構(gòu)為中心，迭代并且增量的開發(fā)過程BUP 定義了四個階段，即起始、精化、構(gòu)

24、建和確認階段C每次迭代都包含計劃、分析、設(shè)計、構(gòu)造、集成、測試以及內(nèi)部和外部發(fā)布D每個迭代有五個工作流（2014 年上）某公司要個軟件，的某些需求是明確的，而某些需求則需要進一步細化。由于市場競爭的，需要盡快上市，則開發(fā)該軟件最不適合采用 (30) 模型。（30）A瀑布B原型C增量D螺旋誠實的。4. 自適應(yīng)軟件開發(fā)（Adaptive Software Development）ASD 的是三個非線性的、重迭的開發(fā)階段：猜測，合作與學(xué)習(xí)。5. 水晶方法體系（Crystal）水晶方法體系與 XP 一樣，都有以人為中心的理念，但在實踐上有所不同。水晶方法體系考慮到人們一般很難嚴格遵循一個紀律約束很強的

25、過程，認為每一種不同的項目都需要一套不同的策略、約定和方法論。因此，與 XP 的高度紀律性不同，水晶方法體系探索了用最少紀律約束而仍能的方法，從而在產(chǎn)出效率與易于上達到一種平衡。也就是說，雖然列不如XP 那樣的產(chǎn)出效率，但會有的人能夠接受并遵循它。：并列爭球法：用迭代的方法，其中把每 30 天一次的迭代稱為一個“沖刺”，并按需求的優(yōu)先級來實現(xiàn)。多個自組織和自治小組并行地遞增實現(xiàn)。協(xié)調(diào)是通過簡短的日常會議來進行的。1.7 軟件過程基礎(chǔ)知識1.7.1 軟件過程軟件過程是指人們用于開發(fā)和維護軟件及相關(guān)的一系列活動，包括軟件工程過程和軟件管理過程。1.7.2 評估工具1. 軟件能力成熟度模型（Capa

26、bility Maturity M，CMM），CMM1.1 的 5 個等級（由低級到高級）：n初始級軟件過程是無序的，有時甚至是的，對過程幾乎沒有定義，取決于個人努力，管理是反應(yīng)式（消防式）的。n可重復(fù)級建立了基本的項目管理過程來跟蹤費用、進度和功能特性。制定了必要的過程紀律，能重復(fù)早先類似應(yīng)用項目取得的。n已定義級已將軟件管理和工程兩方面的過程文檔化、標準化，并綜該組織的標準化軟件過程。所有項目均使用經(jīng)標準、裁減的標準軟件過程來開發(fā)和維護軟件。n已管理級收集對軟件過程和質(zhì)量的詳細度量，對軟件過程和都有定量的理解與。n優(yōu)化級加強了定量分析，通過來自過程質(zhì)量反饋和來自新觀念、新技術(shù)的反饋使過程能

27、持續(xù)不斷地改進。巧記：初級程序員，可重復(fù)寫程序，現(xiàn)已定義了管理策略來優(yōu)化程序設(shè)計！2. 成立成熟度集成模型CMMI 的一種表述方式為連續(xù)表述，主要關(guān)注某特定域的過程改進和能力評估；另一種表述方式為階段式，主要是衡量一個企業(yè)的成熟度，而不把單個過程是否完成作為重點。n階段表述方式初始級、已管理級、量化管理級和優(yōu)化級，這些等級要一級一級逐級進行，每個等級是下一個等級的基礎(chǔ)，當(dāng)前一個級別沒有達到時，不能進入下一個等級。n連續(xù)表述方式分為 0-5 能力等級：未完成級，已執(zhí)行級，已管理級，已定義級，量化管理級和優(yōu)化級。 (2011 年上)關(guān)于過程改進，以下敘述中不正確的是 （30） 。（30）A. 軟件

28、質(zhì)量依賴于軟件開發(fā)過程的質(zhì)量，其中個人因素占主導(dǎo)作用B. 要使過程改進有效，需要制定過程改進目標C. 要使過程改進有效，需要進行培訓(xùn) (2006 年下)軟件能力成熟度模型（CMM）是目前國際上最流行、最實用的軟件生產(chǎn)過程標準和軟件企業(yè)成熟度的等級認證標準。該模型將軟件能力成熟度自低到高依次劃分為初始級、可重復(fù)級、已定義級、已管理級、優(yōu)化級。從（17）開始，要求企業(yè)建立基本的項目管理過程的政策和管理規(guī)程，使項目管理過程有章可循。（17）A初始級 B. 可重復(fù)級 C. 已定義級 D. 已管理級 (2012 年下)敏捷開發(fā)方法中，(30)認為每一種不同的項目都需要一套不同的策略、約定和方法論。(30

29、) A極限編程(XP) B水晶法(Crystal) C并列爭球法( Scrum) D自適應(yīng)軟件開發(fā)(ASD)1.8 軟件工程項目管理基本知識軟件項目管理開始于任何技術(shù)活動之前，并且貫穿于整個的軟件生命周期。軟件工程項目管理一般分為時間管理、成本管理、人力管理、風(fēng)險管理。1.8.1 時間管理1. Gantt 圖如圖 1.6 所示，是一種簡單的水平條形圖，它以水平線段表示子任務(wù)的工作階段，線段的起點和終點分別對應(yīng)著子任務(wù)的起始時間，線段長度指示完成該任務(wù)所需要的時間。圖 1.6、可從圖上清楚地標出子任務(wù)間的時間對比，但它也有缺點：的優(yōu)點：直觀簡明、易學(xué)(1)(2)(3)不能顯示地描繪各項彼此間的依

30、賴關(guān)系；進度計劃的關(guān)鍵部分不明顯，難以哪些部分應(yīng)當(dāng)是主攻和主控的對象；計劃中有潛力的部分以及潛力的大小不明確，往往造成潛力的浪費。2. PERT 網(wǎng)圖與關(guān)鍵路徑PERT 網(wǎng)圖是一個由箭頭（標識任務(wù)）和結(jié)點（標識圖 1.7 所示。）組成的有向圖。將網(wǎng)絡(luò)方法用于工作計劃安排的評審和檢查，如圖 1.7 任務(wù)網(wǎng)絡(luò)圖間和完成該任務(wù)所需的時間，還給出了任務(wù)之間的依賴關(guān)系，即哪些任務(wù)PERT 圖不僅給出了每個任務(wù)的開始時間、結(jié)完成后才能開始另一些任務(wù)，以及如期完成整個工程的“關(guān)鍵路徑”。關(guān)鍵路徑（Critical Path）是由一連串的任務(wù)所組成的鏈，距離最大的一條路徑。軟件項目的管理應(yīng)該密切注視關(guān)鍵任務(wù)的

31、進展情況。如果希望縮短工期，只有往關(guān)鍵任務(wù)中增加有效果。 （2006 年上）在軟件項目管理中可以使用各種圖形工具來輔助決策，下面對 Gantt 圖的描述中，不正確的是 (5) 。A. Gantt 圖表現(xiàn)了各個活動的持續(xù)時間B. Gantt 圖表現(xiàn)了各個活動的起始時間C. Gantt 圖反映了各個活動之間的依賴關(guān)系 D. Gantt 圖表現(xiàn)了完成各個活動的進度D. CMMI 成熟度模型是一種過程改進模型，僅支持階段性過程改進而不支持連續(xù)性過程改進1.8.2 成本管理1. 成本估算方法一種常用的成本估算方法是先估計完成軟件項目所需的工作量（人月數(shù)），然后根據(jù)每個人月的代價（金額）計算機軟件的開發(fā)費

32、用：開發(fā)費用 人月數(shù)×每個人月的代價另法是估計軟件的規(guī)模（通常指源代碼行數(shù)），然后根據(jù)每行源代碼的平均開發(fā)費用（包括分析、設(shè)計、編碼、測試所花的費用），計算機軟件的開發(fā)費用：開發(fā)費用源代碼行數(shù)×每行平均費用。估算源代碼行數(shù)時，可以請n 為有經(jīng)驗的，每位對軟件給出 3 個估計值：nnnai-最少源代碼行數(shù)（該軟件可能的最小規(guī)模） bi-最大源代碼行數(shù)（該軟件可能的最大規(guī)模）mi-最可能的代碼行數(shù)（該軟件最可能的規(guī)模）a + 4m + b的估算期 Ei = iii ，n 位n的估算期望值的平均值 1 å E 就是代碼行數(shù)的估算值。然后計算出每位6in12. 成本估算模

33、型Putnam 模型和O 模型是常用的成本估算模型。(1) Putnam 模型：是一種動態(tài)多變量模型，它是假設(shè)在軟件開發(fā)的整個生存期中工作量的分布。(2)O 模型：是結(jié)構(gòu)性成本模型，是最精確、最易于使用的成本估算模型之一。該模型可以分為：1) 基本2) 中級O 模型，是一個靜態(tài)單變量模型，它是對整個軟件系統(tǒng)進行估算。O 模型，是一個靜態(tài)多變量模型。它將軟件系統(tǒng)模型分和部件兩個層次，系統(tǒng)由部件，它把軟件開發(fā)所需人力（成本）看作是程序大小和一系列“成本驅(qū)動屬性”的函數(shù)。3) 詳細O 模型，它將軟件系統(tǒng)模型分、子系統(tǒng)和模塊 3 個層次，它除包括中級模型所考慮的因素外，還考慮了在需求分析、軟件設(shè)計等每

34、一步的成本驅(qū)動屬性的影響。 （2010 年下半年）使用 PERT 圖進行進度安排，不能清晰地描述（16） ，但可以給出哪些任務(wù)完成后才能開始另一些任務(wù)。下面 PERT 圖所示工程從A 到中的關(guān)鍵路徑是（17），（圖中省略了任務(wù)的開始和結(jié)刻）。（16）A.每個任務(wù)從何時開始B.每個任務(wù)到何時結(jié)束C.各任務(wù)之間的并行情況D.各任務(wù)之間的依賴關(guān)系（17）A.ABEGHIKB.ABEGHJKC.ACEGHIKD.ACEGHJK （2010 年下半年）某軟件項目的活動圖如下所示。圖中頂點表示項目里程碑，連接頂點的邊表示包含的活動，則里程碑(16)在關(guān)鍵路徑上，活動 FG 的松弛時間為 (17) 。(16

35、) ABBCCDDI(17) A19B20C21D24（2014 年上）以下關(guān)于進度管理工具 Gantt 圖的敘述中，不正確的是 (18) 。（18）A能清晰地表達每個任務(wù)的開始時間、結(jié)間和持續(xù)時間 B能清晰地表達任務(wù)之間的并行關(guān)系C不能清晰地確定任務(wù)之間的依賴關(guān)系D能清晰地確定影響進度的關(guān)鍵任務(wù)1.8.3 風(fēng)險管理1. 風(fēng)險的定義n：風(fēng)險是否會導(dǎo)致軟件項目失?。縩關(guān)心變化：在用戶需求、開發(fā)技術(shù)、目標，以及所有其他與項目及時工作和全面完成有實體中會發(fā)生什么樣的變化？n關(guān)心選擇：應(yīng)采用什么方法和工具，應(yīng)配置多少人力，在質(zhì)量上強調(diào)到什么程度才能滿足要求？風(fēng)險的特性：風(fēng)險發(fā)生的概率和風(fēng)險帶來的損失。

36、2. 風(fēng)險的類型(1) 項目風(fēng)險：指潛在的預(yù)算、進度、人力(及組織)、客戶和需求等方面的問題以及它們對軟件項目的影響。例如：項目復(fù)雜性、規(guī)模和結(jié)構(gòu)不確定性等都是項目風(fēng)險、項目風(fēng)險威脅到項目計劃，即如果項目風(fēng)險變成現(xiàn)實，有可能會拖延項目的進度，增加項目的成本。(2) 技術(shù)風(fēng)險：指潛在的設(shè)計、實現(xiàn)、接口、驗證和維護等方面的問題。此外，規(guī)約的二義性、技術(shù)的不正確性，陳舊的技術(shù)和“先進的”技術(shù)也是技術(shù)風(fēng)險因素。技術(shù)風(fēng)險威脅到開發(fā)軟件的質(zhì)量及軟件交付時間，如果技術(shù)風(fēng)險成現(xiàn)實，則開發(fā)工作可能變得很或根本不可能。(3)nnnnn商業(yè)風(fēng)險：在信息系統(tǒng)項目業(yè)風(fēng)險威脅到要開發(fā)系統(tǒng)的生存能力。一般主要有 5 類商業(yè)

37、風(fēng)險：市場風(fēng)險：開發(fā)了一個沒有人真正需要的優(yōu)秀或系統(tǒng)策略風(fēng)險：開發(fā)的不再符合公司的整體商業(yè)策略銷售風(fēng)險：開發(fā)了一個銷售部門不知道如何去賣的管理風(fēng)險：由于重點的轉(zhuǎn)移或的變動而失去了高級管理層的支持預(yù)算風(fēng)險：沒有得到預(yù)算或人力上的保證3. 風(fēng)險管理活動(1) 風(fēng)險識別試圖系統(tǒng)化地確定對項目計劃的威脅，風(fēng)險識別的一個方法是建立風(fēng)險條目檢索表(文檔化)；常見的已知的及可的風(fēng)險有：規(guī)模、商業(yè)風(fēng)險、客戶特性、過程定義、開發(fā)環(huán)境、構(gòu)建的技術(shù)、數(shù)目及經(jīng)驗等。(2) 風(fēng)險：又稱風(fēng)險估算，通過對各種風(fēng)險發(fā)生的可能性和破壞性這兩個方面進行評估，并將它們按優(yōu)先級別進行排列。在進行軟件工程風(fēng)險分析時，項目管理要進行四種

38、風(fēng)險評估活動，包括建立表示風(fēng)險概率的尺度，描述風(fēng)險引起的后果，估計風(fēng)險影響的大小，確定風(fēng)險估計的正確性。(3) 風(fēng)險評估：定義風(fēng)險參照水準，成本、進度和性能就是三種典型的風(fēng)險參照水準，即對于成本超支、進度延期、性能降低有一個表明導(dǎo)致項目終止的水準；風(fēng)險評估的四個步驟：定義項目的風(fēng)險參考水平值、建立每一組與每一個參考水平值之間的關(guān)系、一組臨界點以定義項目終止區(qū)域，該區(qū)域由一條曲線或不確定區(qū)域所界定、水平值。(4) 風(fēng)險什么樣的風(fēng)險組合會影響參考這步所有風(fēng)險分析活動只有一個目的，即輔助項目建立處理風(fēng)險的策略。一個有效的策略必須包含 3 個問題：1）風(fēng)險避免；2）風(fēng)險；3）風(fēng)險管理及意外計劃；如果軟

39、件項目組對于風(fēng)險采用主動的方法，則避免是最好的策略。4. 風(fēng)險度風(fēng)險度(risk exposure)=風(fēng)險損失*風(fēng)險概率例如：正在開發(fā)的軟件項目可能存在一個未將發(fā)現(xiàn)的錯誤，這個錯誤出現(xiàn)的概率是 0.5%，給公司造成的損失將是 100 萬元，那么這個錯誤的風(fēng)險度是 5000 元。 （2012 年上半年）若軟件項目組對風(fēng)險采用主動的方法，則 (19) 是最好的風(fēng)險策略。(19)A風(fēng)險避免B風(fēng)險C風(fēng)險消除D風(fēng)險管理及意外計劃 （2012 年下半年）定義風(fēng)險參照水準是 (19) 活動常用的技術(shù)。(19) A風(fēng)險識別B風(fēng)險C風(fēng)險評估D風(fēng)險（2014 年上）項目復(fù)雜性、規(guī)模和結(jié)構(gòu)的不確定性屬于 (19)

40、風(fēng)險。 （2006 年上）使用 LOC (lines of code)度量軟件規(guī)模的優(yōu)點是 (9) 。(9)A.容易計算 B.與使用的編程語言相關(guān) C.與使用的開發(fā)模型有關(guān) D.在設(shè)計之前就可以計算出 LOC （2006 年上）軟件項目開發(fā)成本的估算依據(jù)，通常是開發(fā)成本估算模型，常用的模型有：IBM 模型Putnam 模型基本O 模型中級O 模型高級 OCOMO 模型其中（18）都是靜態(tài)單變量模型。（18）AB. C. D. （2014 年上） (17) 軟件成本估算模型是一種靜態(tài)單變量模型，用于對整個軟件系統(tǒng)進行估算。（17）APutnamB基本OC中級OD詳細O組織管理制程序員組1.8.4

41、1.是一種非正式的組織方式，小組成員完全平等，享有充分，小組成員通過協(xié)商作出技術(shù)決策，小組有高度的凝聚力，組內(nèi)學(xué)術(shù)空氣濃厚，有利于攻克技術(shù)難關(guān)。小組成員之間的通信是平行的，如果小組內(nèi)有 n 個成員，則可能的通信信道是n(n-1)/2。適用于開發(fā)少（28 人），軟件規(guī)模較小，每個開發(fā)技術(shù)水平都高的情況下。2.組在以下情況下，適用組的方式比較合適。nnn軟件開發(fā)多數(shù)比較缺乏經(jīng)驗；程序設(shè)計過程中有許多事務(wù)性的工作，例如，大量信息的和更新；多通信很費時間，將降低程序員的生產(chǎn)率。圖 1.8既懂管理，同時又是技術(shù)很很棒的組的結(jié)構(gòu)。而后備程序員是和如圖1.8 所示，水平相當(dāng)，隨時可替帶主程序員工作的，編程負

42、責(zé)項目相全部事務(wù)性工作，如維護項目資料庫和項目文檔等。3. 現(xiàn)代程序員組在主程序組的基礎(chǔ)上，取消的行政管理工作，讓其單純搞技術(shù)，負責(zé)技術(shù)工作方面的質(zhì)量，而加進行政組長負責(zé)管理方面的工作?，F(xiàn)代程序員組如圖 1.9、圖 1.10、圖 1.11 所示。圖 1.9 現(xiàn)代程序員組的結(jié)構(gòu)（19）A項目B技術(shù)CD商業(yè)圖 1.10 大型項目的技術(shù)管理組織結(jié)構(gòu)圖 1.11 包含分散決策的組織方式1.9 軟件配置管理軟件配置管理(Software Configure Management,SCM)用于整個軟件工程過程。主要目標是標識變更； 正確地實現(xiàn)；報告有關(guān)變更。SCM 是一組管理整個軟件生存期各階段中變更的活

43、動。1. 基線變更；確保變更基線是軟件生存期中各開發(fā)階段的一個特定點，把各個開發(fā)階段明確地，使本來連續(xù)的工作點在這些點上斷開，以便檢肯定階段成果。基線可以作為一個檢查點，在開發(fā)過程中，當(dāng)采用的基線發(fā)生錯誤時，可以知道所處的位置，返回到最近獲最恰當(dāng)?shù)幕€上。2. 軟件配置項軟件配置項(Software Cinfigure Item,SCI)是軟件工程中產(chǎn)生的信息項，是配置管理的基本象，并形成基線。，以下的 SCI 是SCM 的對系統(tǒng)規(guī)格說明書、軟件項目實施計劃、軟件需求規(guī)格說明書、設(shè)計規(guī)格說明書(數(shù)據(jù)設(shè)計、體系結(jié)構(gòu)設(shè)計、模塊設(shè)計、接口設(shè)計、對象描述)、源代碼管理，測試計劃和過程、測試用例和測試結(jié)

44、果，操作和安裝手冊、可執(zhí)行程序(可執(zhí)行程序模塊、連接模塊)、數(shù)據(jù)庫描述(模式和文件結(jié)果、初始內(nèi)容)、用戶手冊、維護文檔、軟件工程標準、項目開發(fā)小結(jié)。3. 版本一些文檔經(jīng)過轉(zhuǎn)換生成另外一些文檔，并產(chǎn)生一些信息；另一文檔又隨時會有新的變更出現(xiàn)，形成新的版本。4. 變更變更是一項最重要的軟件配置任務(wù)。為有效地實現(xiàn)變更，需借助于配置數(shù)據(jù)庫和基線的概念。配置數(shù)據(jù)庫分為以下三類：開發(fā)庫、受控庫、庫。1.10 模塊化基本知識模塊是指執(zhí)行某一特定任務(wù)的數(shù)據(jù)和可執(zhí)行語句程序元素的集合，通常是指可通過名字來調(diào)用等。模塊化就是將一個待開發(fā)的軟件劃分成若干個可完成某一子功能的模塊，每個模塊可的過程、函數(shù)、子程序或宏地

45、開發(fā)、測試，最后組裝成 （2012 年上）(18) 最不適于采用無組的開發(fā)組織形式。(18)A項目開發(fā)人數(shù)少（如 3-4 人）的項目 B采用新技術(shù)的項目 C大規(guī)模項目 D確定性較小的項目完整的程序。有以下的模塊類型：nnn傳入模塊：從下屬模塊取得數(shù)據(jù)，經(jīng)過某些處理，再將其結(jié)果傳送給模塊；傳出模塊：從模塊取得數(shù)據(jù)，經(jīng)過某些處理，再將其結(jié)果傳送給下屬模塊；變化模塊：也叫模塊。它從模塊取得數(shù)據(jù)，進行特定的處理，轉(zhuǎn)換成其他形式，再傳回模塊。它的數(shù)據(jù)流叫做變換數(shù)據(jù)流。n協(xié)調(diào)模塊：對所有的下屬模塊進行協(xié)調(diào)和管理的模塊。在系統(tǒng)的輸入輸出部分或數(shù)據(jù)部分可以找到這樣的模塊。在一個好的模塊結(jié)構(gòu)圖中，協(xié)調(diào)模塊應(yīng)在較

46、出現(xiàn)。1.10.1 模塊特性1. 可分解性如果一種設(shè)計方法提供了將問題分解成子問題的系統(tǒng)化機制，它就能降低整個系統(tǒng)的復(fù)雜性，從而實現(xiàn)一種有效的模塊化解決方案。2. 可組裝性如果一種設(shè)計方法使現(xiàn)存的（可復(fù)用的）設(shè)計構(gòu)件能被組裝成新系統(tǒng)，它就能提供一種不需要一切從頭開始的模塊化解決方案。3. 可理解性如果一個模塊可以作為一個4. 連續(xù)性的（不用參考其他模塊）被理解，那么它就易于構(gòu)造和修改。如果對系統(tǒng)需求的微小修改只導(dǎo)致對單個模塊，而不是整個系統(tǒng)的修改，則修改引起副作用就會被最小化。5. 保護性如果模塊內(nèi)部出現(xiàn)異常情況，并且它的影響限制在模塊內(nèi)部，注意“連續(xù)性”和“保護性”的區(qū)別！影響其他模塊，則錯

47、誤引起的副作用就會被最小化。1.10.2 模塊與模塊的耦合性（7 種）耦合是對一個軟件結(jié)構(gòu)內(nèi)不同模塊之間互連程度的度量。耦合可以分成下列幾種，它們之間的耦合度由高到低排列。1. 內(nèi)容耦合直接操作或修改另一模塊的數(shù)據(jù)，或不通過正常轉(zhuǎn)入另一個模塊。軟件設(shè)計時應(yīng)堅決2. 公共耦合內(nèi)容耦合，應(yīng)設(shè)計成單、單出口的模塊，避免連接。多個模塊同一全局數(shù)據(jù)區(qū)。例如，C 語言中的 external 數(shù)據(jù)類型、磁盤文件等都是全局數(shù)據(jù)區(qū)。3. 外部耦合模塊與軟件以外的環(huán)境有關(guān)聯(lián)。例如，輸入輸出把一個模塊與特定的設(shè)備、格式、通信協(xié)議耦合在一起。4.耦合一模塊明顯把開關(guān)量、名字等信息送入另一模塊，5. 標記耦合另一模塊的

48、功能。兩個模塊之間通過傳遞公共指針或地址相互作用的耦合。6. 數(shù)據(jù)耦合模塊間通過傳遞信息。7. 非直接耦合（無耦合）模塊間無任何關(guān)系，工作原則上講，模塊化設(shè)計總是希望模塊之間的耦合表現(xiàn)為非直接耦合方式。在以上耦合中，耦合度從高到低，內(nèi)容耦合度最高，非直接耦合度最低?？偨Y(jié)：內(nèi)公不好，家外被控了，標志數(shù)年心血了?。▋?nèi)功不好，家外被控了，標志數(shù)年心血白費了?。?.10.3 模塊的內(nèi)聚性內(nèi)聚是指一個模塊內(nèi)各個元素彼此結(jié)合的緊密程度，它是信息隱蔽和局部的概念的自然擴展。設(shè)計時應(yīng)該力求高內(nèi)聚，理想內(nèi)聚的模塊應(yīng)當(dāng)恰好做一件事情。1. 偶然內(nèi)聚：一個模塊的各成分之間毫無關(guān)系。比如：一組語句在程序的多處出現(xiàn)，為

49、了節(jié)省內(nèi)存空間，這些語句放在一個模塊中，該模塊的內(nèi)聚是偶然內(nèi)聚的。2. 邏輯內(nèi)聚：把幾種邏輯上相功能組放在同一模塊中。3. 瞬時內(nèi)聚（時間內(nèi)聚）：一個模塊所包含的任務(wù)必須在同一時間間隔內(nèi)執(zhí)行，例如初始化模塊。4. 過程內(nèi)聚：一個模塊的處理元素是相，而且必須按特定的次序執(zhí)行。5. 通信內(nèi)聚：一個模塊的所有成分都結(jié)合在同一個數(shù)據(jù)結(jié)構(gòu)上。6. 順序內(nèi)聚：模塊的成分同一個功能密切相關(guān)，且輸出，作為另外一個成分的輸入。7. 功能內(nèi)聚：模塊內(nèi)的所有成分屬于一個整體，完成單一的功能。在以上的內(nèi)聚中，內(nèi)聚度從低到高，偶然內(nèi)聚度最低，功能內(nèi)聚度最高。模塊的高內(nèi)聚、低耦合的原則稱為模塊也稱為模塊設(shè)計的原則。原則，

50、巧記：偶然邏輯，瞬間遺忘過程，打（通信）詢問，順序清楚，功能也搞定！1.10.4 模塊的深度、寬度、扇出與扇入1. 深度：表示軟件結(jié)構(gòu)中的層數(shù)；2. 寬度：是軟件結(jié)構(gòu)中同一個層次上的模塊總數(shù)的最大值；3. 扇入：一個模塊的扇入是指直接調(diào)用該模塊的模塊的個數(shù)；4. 扇出：一個模塊調(diào)用的下層模塊個數(shù)。圖 1.12 模塊結(jié)構(gòu)圖如圖 1.12 所示，模塊M 的深度為 4，寬度為 4，扇出為 4；模塊C 的扇出為 3，扇入為 1。注意：模塊設(shè)計原則：低扇出、高扇入。1.10.5 模塊作用域和域軟件設(shè)計時，模塊的作用域應(yīng)在域之內(nèi)。1.10.6 模塊化基礎(chǔ)知識小結(jié)1. 通過模塊的合并和分解，降低模塊的耦合度

51、。2. 模塊的扇入應(yīng)盡量大，扇出應(yīng)盡量小。一個模塊的扇入是指直接調(diào)用該模塊的模塊的個數(shù)。一個模塊的扇出是指該模塊直接調(diào)用的下級模塊的個數(shù)。扇入大表示模塊的重用性高，利用率高。扇出大表示模塊的復(fù)雜度高。所以要高扇入，低扇出。3. 要將模塊的作用范圍限制在模塊的范圍之內(nèi)。4. 降低模塊之間的復(fù)雜性，避免“連接”。 （2006 年上）模塊的耦合度描述了 (16) 。(16)A模塊內(nèi)各種元素結(jié)合的程度B模塊內(nèi)多個功能之間的接口C模塊之間公共數(shù)據(jù)的數(shù)量D模塊之間相互關(guān)聯(lián)的程度 （2006 年上）內(nèi)聚是一種指標，表示一個模塊 (17) 。(17)A代碼優(yōu)化的程度B代碼功能的集中程度C完成任務(wù)時及時程度D為

52、了與其他模塊連接所要完成的工作量 （2012 年下）在軟件設(shè)計階段，劃分模塊的原則是：一個模塊的(18)。(18)A作用范圍應(yīng)該在其范圍之內(nèi) B范圍應(yīng)該在其作用范圍之內(nèi)C作用范圍與范圍互不包含D作用范圍與范圍不受任何限制（2014 年上）模塊 A 提供某個班級某門課程的成績給模塊 B，模塊 B 計算平均成績、最高分和最低分，將計算結(jié)果返回1.11 什么是軟件開發(fā)方法？有哪些主要方法？nn軟件開發(fā)方法：使用已定義好的技術(shù)集及符號表示習(xí)慣組織軟件生產(chǎn)的過程。結(jié)構(gòu)化方法、面向?qū)ο蠓椒?、JACKSON 方法、維也納開發(fā)方法（VDM）等。1.11.1 結(jié)構(gòu)化方法學(xué)結(jié)構(gòu)化方法學(xué)也稱為生命周期方法學(xué)（瀑布模型方法），是一種面向數(shù)據(jù)流的需求分析方法。它的基本思想是自頂向下逐層分解。為了在需求改變時對軟件的影響較小，結(jié)構(gòu)化分析時應(yīng)該使程序結(jié)構(gòu)與問題結(jié)構(gòu)相對應(yīng)。常用工具： 數(shù)據(jù)流圖（DFD）、數(shù)據(jù)字典（DD）、實例-關(guān)系圖（E-R 圖）及描述1. 數(shù)據(jù)流圖(DFD 圖)數(shù)據(jù)流圖主要由 4 種成分組成，如表 1.1 所示：處理的結(jié)構(gòu)化語言、判定表、判定樹。表 1.1 數(shù)據(jù)流