《本科自考02333軟件工程課后習題答案-2012版》完整版

1、本科自考02333軟件工程課后習題答案2011版 王立福第1章 緒論1、解釋術語（1）軟件: 軟件是指計算機系統(tǒng)中的程序及其文檔。P16(2)軟件工程：軟件工程是應用計算機科學理論和技術以及工程管理原則和方法，按預算和進度實現滿足用戶要求的軟件產品的工程，或以此為研究對象的學科。P15（3）軟件危機：軟件生產率、軟件質量遠遠滿足不了社會發(fā)展的需求，成為社會，經濟發(fā)展的制約因素，人們通常把這一現象稱為“軟件危機”。P152、 簡答題（1） 簡述軟件開發(fā)的本質。答：軟件開發(fā)的本質就是實現問題空間的概念和處理邏輯到解空間的概念和處理邏輯之間的映射。P19（2） 簡述實施軟件開發(fā)的基本途徑。答：實施軟

2、件開發(fā)的基本途徑是系統(tǒng)建模。所謂系統(tǒng)建模，是指運用所掌握的知識，通過抽象，給出該系統(tǒng)的一個結構系統(tǒng)模型。P19（3） 簡述何謂模型以及軟件開發(fā)中所涉及的模型。答：模型是一個抽象。該抽象是在意圖所確定的角度和抽象層次對物理系統(tǒng)的一個描述，描述其中的成分和成分之間所具有的特定語義的關系，還包括對該系統(tǒng)邊界的描述。軟件開發(fā)中所涉及的模型可分為兩大類，一類稱為概念模型，描述了系統(tǒng)是什么；另一類統(tǒng)稱為軟件模型，描述了實現概念模型的軟件解決方案。P19（4）簡述軟件開發(fā)所涉及的兩大類技術。答：軟件開發(fā)所涉及的兩大類技術為：一是求解軟件的開發(fā)邏輯，二是求解軟件的開發(fā)手段。P17第2章 軟件需求與軟件需求規(guī)約

3、1、解釋術語（1）軟件需求 軟件需求以一種技術形式，描述了一個產品/系統(tǒng)應該具有的功能、性能和其它性質。P23（2）功能需求 功能需求規(guī)約了系統(tǒng)或系統(tǒng)構件必須執(zhí)行的功能。P24（3）非公能需求 非公能需求是性能、外部接口、設計約束和質量屬性這4類需求的統(tǒng)稱。P23 (4) 需求規(guī)約 需求規(guī)約是一個軟件項/產品/系統(tǒng)所有需求陳述的正式文檔，它表達了一個軟件產品/系統(tǒng)的概念模型。P28 2、簡述需求與需求規(guī)約的基本性質。 答：需求的基本性質：1） 必要的，該需求是用戶所要求的。2）無歧義的，該需求只能用一種方式解釋。 3）可測的，該需求是可進行測試的。 4）可跟蹤的，該需求可從一個開發(fā)階段跟蹤到另

4、一個階段。 5）可測量的，該需求是可測量的。P23 需求規(guī)約的基本性質： 1）重要性和穩(wěn)定性程度：按需求的重要性和穩(wěn)定性，對需求進行分級。 2）可修改的：在不過多地影響其他需求的前提下，可以容易地修改一個單一需求。3）完整的：沒有被遺漏的需求。4）一致的：不存在互斥的需求。P283、簡述軟件需求的分類。 答：軟件需求可以分為兩大類：一類是功能需求，一類是非公能需求，而非公能需求可分為性能需求，外部接口需求、設計約束和質量屬性需求。P234、舉例說明功能需求和非功能需求之間的基本關系。 答：非功能需求可作用于一個或多個功能需求，例如功能需求3功能需求2功能需求1 作用于非功能需求2非功能需求1其

5、中，非功能需求1作用于功能需求1和功能需求3等；非功能需求2作用于功能需求2等。P245、有哪幾種常用的初始需求發(fā)現技術？答：有5種常用的需求發(fā)現技術：自悟、交談、觀察、小組會和提煉。P266、簡述需求規(guī)約的3種基本形式。 （1） 非形式化的需求規(guī)約。非形式化的需求規(guī)約即以一種自然語言來表達需求規(guī)約，如同使用一種自然語言寫了一篇文章。 （2） 半形式化的需求規(guī)約。半形式化的需求規(guī)約即以半形式化符號體系（包括術語表、標準化的表達格式等）來表達需求規(guī)約。 （3）形式化的需求規(guī)約。形式化的需求規(guī)約即以一種基于良構數學概念的符號體系來編制需求規(guī)約，一般往往伴有解釋性注釋的支持。 P297、簡述軟件需求

6、規(guī)約的內容和作用。答：軟件需求規(guī)約的內容有：引言、總體描述、特定需求、附錄、索引。P28需求規(guī)約的作用可概括為以下4點：1）需求規(guī)約是軟件開發(fā)組織和用戶之間一份事實上的技術合同書，是產品功能及其環(huán)境的體現。 2）對于項目的其余大多數工作，需求規(guī)約是一個管理控制點。 3）對于產品/系統(tǒng)的設計，需求規(guī)約是一個正式的、受控的起始點。 4）需求規(guī)約是創(chuàng)建產品驗收測試計劃和用戶指南的基礎。P318、簡述需求規(guī)約在項目開發(fā)中的基本作用。答：需求規(guī)約的作用可概括為以下4點：1）需求規(guī)約是軟件開發(fā)組織和用戶之間一份事實上的技術合同書，是產品功能及其環(huán)境的體現。 2）對于項目的其余大多數工作，需求規(guī)約是一個管理

7、控制點。 3）對于產品/系統(tǒng)的設計，需求規(guī)約是一個正式的、受控的起始點。 4）需求規(guī)約是創(chuàng)建產品驗收測試計劃和用戶指南的基礎。P319、簡述需求規(guī)約和項目需求的不同。答：需求規(guī)約和項目需求是兩個不同的概念。需求規(guī)約是軟件開發(fā)組織和用戶之間一份事實上的技術合同書，即關注產品需求，回答“交付給客戶的產品/系統(tǒng)是什么”；而項目需求是客戶和開發(fā)者之間有關技術合同產品/系統(tǒng)需求的理解，應記錄在工作陳述中或其他某一項目文檔中，即關注項目工作與管理，回答“開發(fā)組要做的是什么”。P30第三章 結構化方法1.基本概念需求分析：一般來說，分析是系統(tǒng)地使用信息，對一個問題的估算。軟件需求分析是這一概念的特化，即系統(tǒng)

8、化地使用“數據流”、“加工”、“數據存儲”、“數據源”和“數據潭”等術語所表達的信息，對待建系統(tǒng)“是什么”給出一個估算系統(tǒng)概念模型軟件設計：在需求分析的基礎上，定義滿足需求所需要的結構，即針對給定的問題，給出該問題的軟件解決方案，確定“怎么做”的問題數據流圖：表達功能模型的工具，即數據流圖（Dataflow Diagram） 簡稱DFD圖，簡單的說，DFD圖是一種描述數據變換的圖形化工具，其中飲食的元素可以是數據流、數據存儲、加工、數據源和數據潭等變換型數據流圖：具有較明顯的輸入部分和變換（主加工）部分之間的界面變換部分和輸出部分之間界面的數據流圖事務型數據流圖：數據到達一個加工T，該加工T根

9、據輸入數據的值，在其后的基干動作序號（稱為一個事務）中選出一個來執(zhí)行模塊：執(zhí)行一個特殊任務的一個過程以及相關的數據結構1.簡答題2.何謂模塊耦合？簡述模塊耦合的類型。答：耦合是不同模塊之間相互依賴程序的度量內容耦合：當一個模塊直接修改或操作另一個模塊的數據，或一個模塊不通過正常入口而轉入到另一個模塊時，公共耦合：兩個或兩個以上的模塊共同引用一個全局數據項控制耦合一個模塊通過氣喘吁吁向另一個模塊傳遞一個控制信息，接收信號的模塊根據信號值進行適當的動作標記耦合：若一個模塊A通過接口向兩個模塊B和C傳遞一個公共參數數據耦合：模塊之間通過參數來傳遞數據3.何謂模塊內聚？簡述模塊內聚的類型。答：指一個模

10、塊內部各成分之間相互關聯(lián)程度的度量偶然內聚：一個模塊的各成分之間基本不存在任何關系邏輯內聚：幾個邏輯上相關的功能被放在同一個模塊中時間內聚：一個模塊完成的功能必須在同一時間內執(zhí)行，但這些功能只是因為時間因素關聯(lián)在一起過程內聚：一個模塊內部的處理成分是相關的，而且這些處理必須以特定的次序執(zhí)行通信內聚：一個模塊的所有成分都操作同一數據集或生成同一數據集順序內聚：一個模塊的各個成分和同一個功能密切相關，而且一個成分的輸出作為另一個成分的輸入功能內聚：最理想的內聚，模塊的所有成分對于完成單一的功能都是基本的。功能內聚的模塊對完成其功能而言是充分必要的4.何謂模塊的控制域和模塊的作用域？并舉例說明控制域

11、：模塊本身以及所有直接或間接從屬于它的模塊的集合。作用域：受該模塊內的一個判定所影響的所有模塊的影響第四章 面各對象方法UML1.基本概念類及其屬性和操作類是一組具有相同屬性、操作、關系和語義的對象的描述。類的屬性是類的一個命名特征，該特征是由該類的所有對象所共享、用于表達對象狀態(tài)的數據接口是操作的一個集合，其中每個操作描述了類、構件或子系統(tǒng)的一個服務關聯(lián)及其鏈：關聯(lián)是類目之間的一種結構關系，是對一組具有相同結構、相同鏈的描述。鏈是對象之間具有特定語義關系的抽象泛化：活佛是一般性類目（稱為超類或父類）和它的較為特殊性類目(稱為子類)之間的一種關系，有時稱為”is a kind of ”關系聚合

12、：聚合是關聯(lián)的一種特殊形式，表達的是一種“整體/部分”關系依賴：依賴是一種使用關系，用于描述一個類目使用另一個類目的信息和服務2.簡答題為了表達客觀事物，UML給出了哪些基本術語？答：為了支持抽象分析和設計中的事物，UML給出了8個基本術語，即類、接口、協(xié)作、用況、主動類、構件、制品、結點，并給出了這些基本術語的一些變體。為了表達客觀事物之間的關系，UML給出了哪些基本術語？這些術語之間是什么關系？關聯(lián)、泛化、細化和依賴，以及它們的一些變體什么是對象的構成與表示？并說明。類是一組具有相同屬性、操作、關系和語義的對象的描述。對象是類的一個實例什么是類圖的構成成分？答：類圖是可視化地表達系統(tǒng)表態(tài)結

13、構模型的工具，通常飲食類、接口、關聯(lián)、泛化和依賴什么是順序圖的構成成分？順序圖是一種交互圖，即由一組對象以及按時序組織的對象之間的關系組成，其中還飲食這些對象之間所發(fā)送的消息如何描述對象之間的關聯(lián)語義用況之間有哪幾種關系？在什么情況下需要建立狀態(tài)圖？狀態(tài)圖可用于創(chuàng)建有關系統(tǒng)（或系統(tǒng)成分）的行為生存周期模型，表達有關系紡（或系統(tǒng)成分）的一種動態(tài)結構，給出有關系統(tǒng)（或系統(tǒng)成分）在生存期間有哪些階段、每一階段可從事的活動以及對外所呈現的特征等 方面 的信息對象操作和對象狀態(tài)之間的關系是什么？同時引入“操作”和“方法”的目的是什么？答：表達模型化包之間的關系為什么使用包？如何劃分包使用UML可以從那些

14、角度來刻畫一個系統(tǒng)的行為？為什么？何謂順序圖中的控制操作子？試舉例說明。為了控制交互行為描述的復雜性，以便更清晰地表達順序圖中的復雜控制，給出了個個控制操作子，選擇、條件、并發(fā)、迭代操作控制子第五章 面各對象方法RUP1.基本概念RUP的定義及主要特點RUP是一種軟件開發(fā)過程框架，基于面向對象符號體系給出了有關軟件開發(fā)過程組織及實施的指導。該框架體現了3個突出特征，即以用況驅動、體系結構為中心以及迭代、增量式開發(fā)演化模型與“RUP增量、迭代開發(fā)”之間關系RUP迭代、增量式開發(fā)是演化模型的一個變體，即規(guī)定了“大的”迭代數量4個階段，并規(guī)定了每次迭代的目標初使階段：獲得與特定腹部和平臺無關的系統(tǒng)體

15、系結構輪廓，以此建立產品功能范圍;編制實例業(yè)務實例，從業(yè)務角度指出該項目的價值，減少項目主要的錯誤風險精華階段：通過捕獲并描述系統(tǒng)的大部分需求，建立系統(tǒng)體系結構基線的第一個版本，主要包括用況模型和分析模型，減少次要的錯誤風險，到該階段未，就能夠估算成本、進步，并能詳細地規(guī)劃構造階段構造階段：通過演化，形成最終的系統(tǒng)體系結構基線，開發(fā)完整的系統(tǒng)，確保產品可以開始向客戶交付，即具有初始操作能力移交階段：確保有一個實在的產品發(fā)布給用戶群。期間培訓用戶如何使用該軟件RUP與UML之間關系RUP與UML是一對“姐妹”，它們構成了一種特定的軟件開發(fā)方法學。其中，UML作為一種可視化建模語言，給出了表達事物

16、和事物之間關系的基本術語，給出了多種模型的表達工具;而RUP利用這些術語定義了需求獲取層、系統(tǒng)分析層、設計層、實現層，并給出了實現各層模型之間映射的基本活動以及相關指導什么是特征（Teature）?舉例如何描述它。從客戶、用戶、計劃者、開發(fā)者想法和意愿中搜取特征，形成特征表。特征是一個新的項及其簡要描述“按不同科目計算平均成績” 計算平均成績：按所學的不同科目計算每一個學生的期末考試平均成績，給出分數段并描述其狀態(tài)（如提議、批準、合并和驗證等）、實施的代價及風險、重要程度以及對其他特征的影響等特征可作為需求，并被轉換為其它制品需求獲取層及相關概念需求獲取層目標：使用UML中 的用況、參與者以及

17、依賴等 術語來抽象客觀實際問題，形成系統(tǒng)的需求獲取模型;基本術語：用況、參與者、用于表達用況參與者之間關系的關聯(lián)、用于表達況之間的包含和擴展、用于表達參與者之間關系泛化。術語確定了系統(tǒng)用況模型的各種形態(tài)需求獲取模型的基本組成使用UML中 的用況、參與者以及依賴等 術語來抽象客觀實際問題，形成系統(tǒng)的需求獲取模型建造一個系統(tǒng)需求獲取模型的活動和任務，以及各活動的輸入和輸出1. 發(fā)現描述參與者和用況，輸入：業(yè)務模型或領域模型，補充需求，特征表;輸出：用況模型概述，術語表2. 賦予用況優(yōu)先級：輸入：用況模型概述，補充需求，術語表;輸出：體系結構描述用況模型視角3. 精華用況：輸入：用況模型概述，補充需

18、求，術語表;輸出：用況精化4. 構造人機接口原型：輸入：用況精華，用況模型概述，補充需求，術語表;輸出：人機接口原理5. 用況模型結構化：輸入：用況精華，用況模型概述，補充需求，術語表;輸出：用況模型精化如何描述系統(tǒng)的參與者和用況？舉例說明參與者：發(fā)現參與者與描述參與者：1)之前已經存在業(yè)務用況模型，可依據業(yè)務模型直接發(fā)現一些候選參與者，2)沒有業(yè)務用況模型，即使存在領域模型，也需要系統(tǒng)分析人員與客戶一起來標識系統(tǒng)參與者用況是系統(tǒng)向它的參與者提供結果（值）的功能塊，表達參與者使用系統(tǒng)的方式，因此一個用況可用于規(guī)約系統(tǒng)可執(zhí)行的、與參與者進行交互的一個動作序列，包括其中一些可選動作序列，并且用況還

19、有自己 的屬性需求獲取層對以后開發(fā)工作的影響？需求分析層及相關概念在系統(tǒng)用況模型的基礎上，創(chuàng)建系統(tǒng)分析模型以及在該分析模型視角下的體系結構描述，系統(tǒng)分析模型是系統(tǒng)的一種概念模型，解決系統(tǒng)用況模型中存在的二義性和不一致性問題，并以一種系統(tǒng)化的形式準確地表達用戶的需求需求分析模型的基本組成RUP的分析如同結構化分析，其目標之一是在一個特定的抽象層上建立系統(tǒng)分析模型。為此，RUP首先給出了3個術語：分析包、分析類和用況細化，用于表達需求中“大粒度”的概念，開發(fā)人員使用這些術語可以規(guī)約系統(tǒng)分析中所要使用的信息分析類：是類的一種衍型，很少有操作和特征標記，而用責任來定義其行為，并且其屬性和關系也是概念性

20、的，包括：邊界類、實體類、控制類用況細化：是一個針對一個用況，其行為可用多個分析類之間的相互作用來細化，并記為用況細化分析分析包：分析包是一種控制信息組織復雜性的機制，提供了分析制品的一種組織手段，形成了一些可管理的部分。建造一個系統(tǒng)需求分析模型的活動和任務，以及各活動的輸入和輸出體系結構分析：輸入：用況模型、補充需求、業(yè)務模型或領域模型、體系結構描述用況模型;輸出：分析包概述、分析類概述、體系結構描述分析細化用況：輸入：用況模型、補充需求、業(yè)務模型或領域模型、體系結構描述分析;輸出：用況細化分析、分析類概述對類分析：輸入：用況細化分析、分析類概述 輸出：分析類完成對包進行分析：輸入：系統(tǒng)體系

21、結構描述分析、分析包概述輸出：分析類完成需求分析模型對以后開發(fā)工作的影響1) 對設計中子系統(tǒng)的影響。分析包一般將影響設計子系統(tǒng)的結構2) 對設計類的影響。分析包可以作為類設計時的規(guī)格說明。3) 對用況細化設計的影響。用況細分分析對用況細化設計有兩方面影響，一個是它們有乃至于為用況創(chuàng)建更精確的規(guī)格說明，另一個是當對用況進行設計時，用況細化分析可作為其輸入。需求獲取模型與需求分析模型之間比較1) 語言描述不同：客戶語言與開發(fā)語言2) 視圖：系統(tǒng)外與系統(tǒng)內3) 結構：使用用況予以結構化，給出外部視角系統(tǒng)結構與使用衍型類結構化，給了部視角系統(tǒng)結構4) 作用：標注“系統(tǒng)應該做什么，不應該做什么”與可以做

22、出開發(fā)者理解系統(tǒng)如何勾畫、如何設計和如何實現基礎5) 問題：可能存在冗余、不一致和沖突等問題與解決了上述問題6) 捕獲系統(tǒng)功能，包括體系結構方面具有意義的功能與給出細化系統(tǒng)功能，包括在體系結構方面具有意義的功能7) 定義一些進一步需要在分析模型中予以分析用況與定義每一個用況細化設計層及相關概念設計目標：定義滿足系統(tǒng)/產品分析模型所規(guī)約需求的軟件結構基本術語：設計子系統(tǒng)、設計類、用況細化設計、接口、以及用于表達子系統(tǒng)之間關系的依賴、用于表達設計類之間關系的關聯(lián)等 ，這些術語確定了系統(tǒng)設計模型的各種形態(tài)設計模型的基本組成設計子系統(tǒng)、設計類、用況細化設計、接口、以及用于表達子系統(tǒng)之間關系的依賴、用于

23、表達設計類之間關系的關聯(lián)等 ，這些術語確定了系統(tǒng)設計模型的各種形態(tài)建造一個系統(tǒng)設計模型的活動和任務，以及各活動的輸入與輸出體系結構設計：輸入：用況模型、補充需求、分析模型、體系結構描述分析模型角度;輸出：子系統(tǒng)概述、接口概述、設計類概述、部署模型概述、體系結構描述設計設計用況：輸入：用況模型、補充需求、分析模型、部署模型;輸出： 用況設計-實現、設計類概述、子系統(tǒng)概述、接口概述對類設計：輸入: 用況設計-實現、設計類概述、接口概述 、分析類完成;輸出：設計類完成 設計子系統(tǒng)：體系結構描述設計、子系統(tǒng)概述、接口概述;輸出：子系統(tǒng)完成、接口完成如何處理需求中所捕獲的非功能需求。需求分析模型與設計模

24、型之間的比較第六章 軟件生存周期過程與管理1.基本概念軟件測試：有規(guī)程地發(fā)現錯誤的過程，其中錯誤（ERROR）:與所期望的設計之間的偏差，該偏差可能產生不期望的系統(tǒng)行為或失效。失效(FAILURE):與所規(guī)約的系統(tǒng)執(zhí)行之間的偏差。失效是系統(tǒng)故障或錯誤的后果。故障（FAULT）：導致錯誤或失效的不正常條件。故障可以是偶然性的或是系統(tǒng)性的。測試用例：為了發(fā)現程序中的故障而專門設計的一組數據或腳本測試覆蓋率：定量描述一個或一組測試的效率2.簡答題測試過程模型，并分析這一模型在軟件測試技術研究以及實踐中的作用答：軟件測試是一個有程序的過程，包括測試設計、測試執(zhí)行、以及測試結果比較等1. 環(huán)境模型、被測

25、模型和錯誤模型在軟件測試中扮演了一種很重要的角色;這些模型的質量，特別是程序模型的質量，對發(fā)現錯誤具有關鍵性的作用2. 軟件測試的錯誤假定是，實際結果與預期結果不符，而后在此基礎上可進一步分析是什么錯誤軟件測試與調度的區(qū)別答：1） .測試從一側面證明程序員的“失敗”。調度為了證明程序員是正確的2).測試以已知條件開始，使用預告定義的程序且有預知的結果，不可預見的僅是程序是否通過測試3).測試是有計劃的，并要進行測試設計。高度是不受時間約束的4).測試是發(fā)現錯誤、改正錯誤、重新測試的過程。調試是一個推理過程5).的執(zhí)行是有規(guī)程的。調 試的執(zhí)行往往要求程序員進行必要推理6).測試經常由獨立的測試組

26、在不了解軟件技術的條件下完成的。高度必須由了解詳細設計的程序員完成7)大多數測試的執(zhí)行和設計可由工具支持。調試時，程序員能利用的工具主要是調試器程序流程圖的作用及構成答：著重于過程屬性描述簡述語名覆蓋、分支覆蓋、條件組合覆蓋、路徑覆蓋的含義及它們之間的關系答：路徑覆蓋：執(zhí)行所有可能穿過程序控制流程的路徑語句覆蓋：至少執(zhí)行程序中所有語句一次分支覆蓋：至少將程序中的每一個分支執(zhí)行一次條件覆蓋：指每個判定中的所有可能的條件取值至少執(zhí)行一次條件組合覆蓋：設計足夠測試，使每個判定中的所有可能的條件聚會組合至少執(zhí)行一次存在以下關系：語句覆蓋分支覆蓋條件組合覆蓋。路徑覆蓋簡術單元測試、集成測試、有效性測試的

27、含義及它們之間的區(qū)別答：單元測試：主檢驗軟件設計的最小單元模塊。該測試以詳細設計文檔為指導，測試模塊內的重要控制路徑。集成測試：是軟件組裝的一個系統(tǒng)化技術，其目標是發(fā)現與接口有關的錯誤有效性測試：發(fā)現軟件實現的功能與需求規(guī)格說明書不一致的錯誤簡述路徑測試技術、事務流測技術的主要依據答：一個依據程序邏輯結構，一個依據軟件行為描述簡述程序流程圖與事務流程圖之間的主要區(qū)別，并分析這些區(qū)別的主要原因答：1)基本模型元素所表達的語義不同2)一個事務不等 同于路徑測試中一條路徑，可能在中間某處就完成了某一用戶工作，終結了一個事務3).事務流程圖中的分支和節(jié)點可能是一個復雜的過程簡述白盒測試技術的要點，并舉

28、例說明答：白盒測試技術依據程序的邏輯結構，以控制流程圖作為被測對象建模工具，其中涉及過程塊、分支、節(jié)點、鏈以及路徑，并針對測試民，給出了4種覆蓋策略：語名覆蓋、分支覆蓋、條件組合覆蓋和路徑覆蓋，它們之間具有偏序關系，并且可根據項目需求給出其他覆蓋策略事務流測試技術的要點，并舉例說明 答：事務流測試技術是一種功能測試技術，目前提出了很多功能測試技術，如定義域測試技術、等價類測試技術以及基于因果圖的測試技術等，統(tǒng)稱為黑盒子測試技術。黑盒測試將被測軟件看成黑盒子，只通過外部的輸入和輸出來發(fā)現軟件中的錯誤，因此黑盒測試是一種基于軟件規(guī)約的測試第七章 軟件生存周期過程與管理1.基本概念軟件生存周期過程：

29、軟件生存周期是軟件產品或系統(tǒng)的一系列相關活動的全周期。從形成概念開媽，歷經開發(fā)、交付使用、在使用中不斷修訂和演化，直到最后被淘汰，讓位于新的軟件產品軟件生存周期模型：是一個包括軟件產品開發(fā)、運行和維護中有關過程、活動和任務的框架，覆蓋了從該系統(tǒng)的需求定義到系統(tǒng)的使用終止過程管理：過程規(guī)則與管理是軟件項目管理的一項重要工作。沒有過程規(guī)劃就淡不上過程管理乃至項目管理，沒有過程管理就不可能存在有效的軟件工程2.簡述軟件開發(fā)中的過程類，以及它們的基本作用和它們之間的基本關系答：分為3類基本過程：那些軟件生產直接相關的活動集，分5個過程：獲取過程、供應過程、開發(fā)過程、運行過程和維護過程支持過程：有關各方

30、面按他們的目標所從事的一系列相關支持活動集，有助于提高系統(tǒng)或軟件產品的質量，分為：文檔過程、配置管理過程、質量保證過程、驗證過程、確認過程、聯(lián)合評審過程、審計過程和問題解決過程等組織過程：與軟件生產組織有關的活動集，分管理過程、基礎設施過程、培訓過程、改進過程3.在ISO/IEC12207-2008中如何描述一個過程？舉例說明答：1).為獲取方獲取一個軟件產品或服務，為供應方開發(fā)、運行、維護、提供和銷毀一個軟件產品，建立了一種軟件生存周期框架，包含過程、活動和任務，并通過過程分類、過程描述，給出它們之間的內在關系2).為軟件生存周期過程的定義、控制和改進提供了一個過程，即生存周期模型管理過程供

31、應過程：為獲取方提供滿足所協(xié)商需求的產品或服務軟件實現過程：軟件實現過程是為了生產一個已規(guī)約系統(tǒng)元素，作為一個軟件產品或服務而實現軟件需求分析過程：建立系統(tǒng)軟件部分的需求軟件體系結構設計：為軟件的實現及其可以按需求進行驗證，提供一種設計軟件驗證過程：證實一個過程或項目的每一個軟件工作產品/服務是否正確地反映所規(guī)約的需求軟件確認過程：證實所期望的軟件工作產品是否滿足其需求？4.什么是軟件開發(fā)特定的過程類？舉例說明5.什么是驗證和確認？簡述它們的作用和區(qū)別答：驗證：證實一個過程或項目的每一個軟件工作產品/服務是否正確地反映所規(guī)約的需求驗證和確認是有區(qū)別的。驗證是通過提供的客觀證據，證實規(guī)約的需求是

32、否得以滿足確認是通過提供的客觀證據，證實有關特定期望的使用或應用的需求是否得以滿足軟件確認過程：證實所期望的軟件工作產品是否滿足其需求6.簡述瀑布模型以及可適應的情況瀑布模型將軟件生存周期的各項活動規(guī)定為按固定順序而連接的若干階段工作，形如瀑布流水，最終得到產品適應情況：需求已被很好的理解，并且開發(fā)組織非常熟悉為實現這一模型所需求的過程7.簡述演化模型以及可適應的情況答：表達了一種彈性的過程模式，由一些小的開發(fā)步組成，每一步歷經需求分析、設計、實現和驗證，產生軟件產品的一個增量，通過這些迭代，最終完成軟件產品的開發(fā)主要針對事先不能完整定義需求的軟件開發(fā)8.簡述增量模型的優(yōu)缺點答：優(yōu)點1)第一個

33、可交付版本所需要的成本和時間是較少的，從而可減少開發(fā)由增量表示的小系統(tǒng)承擔的風險2)由于很快發(fā)布第一個版本，因此可以減少用戶需求的變更3)允許增量投資，即在項目開始時可以僅對一個或兩個增量投資缺點：1)如果沒有對用戶的變更要求進行規(guī)劃，那么產生的初始增量可能會造成后來增量的不穩(wěn)定2)如果需求不像早期思考的那樣穩(wěn)定和完整，那么一些增量就可能需要重新開發(fā)，重新發(fā)布3)由于進度和配置的復雜性，可能會增大管理成本，超出組織的能力9簡述螺旋模型以及它與其它模型之間的主要區(qū)別答：螺旋模型是瀑布模型與深化模型的基礎上，加入兩者所忽略的風險分析所建立的一種軟件開發(fā)模型螺旋模型關注解決問題的基本步驟，即標識問題

34、，標識一些可選方案，選擇一個最佳方案，遵循動作步驟并實施后續(xù)工作，突出特征，在開發(fā)的迭代中實際上只有一個迭代過程真正開發(fā)了可交付的軟件2)與深化模型和增量模型相比，同樣使用了瀑布模型作為一個嵌入的過程，即分析、設計、編碼、實現和維護的過程，并且在框架和全局體系結構方面是等同的。但是，螺旋模型所關注的階段以及它們的活動是不同的，如增加一些管理活動和支持活動。盡管增量模型也有一些管理活動，但它基于以下假定：需求是最基本的、并且是唯一的風險源，因而在螺旋模型中增大了決策和風險的空間，螺旋模型擴大了增量模型的管理范圍。如果項目的開發(fā)風險很大或客戶不能確定系統(tǒng)需求，在更廣泛的意義上來講，還包括一個系統(tǒng)或

35、系統(tǒng)類型的要求，這時螺旋模型就是一個好的生存周期模型第八章 集成化能力成熟度模型一、術語解釋過程域：是一個業(yè)務域中一束相關實踐，當它們一起得以實現時，就滿足被認為對該過程域的改善具有重要作用的一組條件。過程改善：是指人為設計的一個活動程序，其目的是改進組織的過程性能和成熟度，并改進這一程序的結果專用目標：每一個過程域中都有一個或多個“專用目標”，用于描述該過程域必須呈現的一些獨有特征共用目標：每一個過程域中都有一個或多個“共用目標”，用于描述實現制度化的該過程必須呈現的特征專用實踐：每一個過程域中都有一個或多個“專用實踐”，這些專用實踐被認為對于達到該過程域的專用目標是重要活動，即期望以專用實

36、踐所描述的活動，會導致達到一個過程域的專用目標共用實踐：每一個過程域中都有一個或多個“共用實踐”，這些共用實踐被認為對于達到該過程域相關的共用目標是重要活動能力等級：是指單一過程域中已達到的過程改善，能力等級是為了管理，對過程改善程序所設定的幾個“臺階”成熟度等級：是指達到預先定義的一組過程域所有目標的一種過程改善等級2.簡答題CMMI提出所基于的基本思想答：該模型基于過程途徑思想，通過過程把軟件質量的3個支撐點受訓的人員、規(guī)程和方法、工具和設備進行集成，以開發(fā)所期望的系統(tǒng)/產品。為此，CMMI緊緊圍繞開發(fā)、維護和運行，把經過證明的“最佳實踐“放在一個結構中。該結構有乃至于指導組織確定其過程的

37、發(fā)送優(yōu)先次序;有乃至于指導這些改善的實施，以提高其過程能力和成熟度，并且還支持其它領域（如獲取和服務）能力成熟度模型開發(fā)。什么是過程制度化？在CMMI把過程制度化分幾個等級？簡要回答每一等級主要特征簡述CMMI模型支持兩種過程改善路徑答：CMMI提供了兩種改善路徑，一是稱為能力等級是一種過程改善路徑，該路徑可使組織針對單一過程域不斷改善該過程域二是稱為成熟度等級也是一種過程改善路徑，該路徑可使組織通過關注一組過程域不斷改善一組相關過程域簡述CMMI模型的模型部件及部件間關系組圖簡述專用實踐與共用實踐關系答：專用實踐：每一個過程域中都有一個或多個“專用實踐”，這些專用實踐被認為對于達到該過程域的

38、專用目標是重要活動，即期望以專用實踐所描述的活動，會導致達到一個過程域的專用目標共用實踐：每一個過程域中都有一個或多個“共用實踐”，這些共用實踐被認為對于達到該過程域相關的共用目標是重要活動，例如，對共有目標“該過程予以制度化，使之成為一個已管理過程“而言，一個共用實踐是”為該過程的執(zhí)行、工作產品的開發(fā)以及該過程的服務，提供充足的資源“。之所以稱為“共用實踐“，是因為同一實踐可應用于多個過程。簡述每一成熟度等級所包含的過程域。答：在成熟度等級，把開發(fā)、維擴、運行中的過程分為4個組。1) 包含7個過程域：配置管理、測量與分析、項目監(jiān)控、項目規(guī)劃、過程和產品質量保證、需求管理、提供方協(xié)議管理。2)

39、 包含11個過程域：決策分析與解決、集成項目管理、組織過程定義、緩緩過程關注、組織培訓、產品集成、需求開發(fā)、風險管理、技術解決方案、驗證、確定3) 組織過程性能和定量項目管理4) 原因分析與解決和組織創(chuàng)新和部署3.簡述項目規(guī)劃過程域的專用目標與專用實踐答：專用目標1:SG1建立估算，4個專用實踐 SP1.1估算項目規(guī)模,SP1.2 建立工作產品和任務屬性的估算SP1.3定義項目生存周期SP1.4確定工作量和成本的估算專用目標2:SG2 開發(fā)項目計劃,7個專用實踐：SP2.1建立預算和進度，SP2.2標識項目風險SP2.3規(guī)劃數據管理SP2.4規(guī)劃項目資源SP2.5規(guī)劃需要的知識和技能SP2.6

40、規(guī)劃利益攸關方參與SP2.7建立項目計劃專用目標3:SG3獲得對該計劃的承諾：SP3.1評審該項目的計劃SP3.2調和工作和資源等級，使之一致。SP3.3獲得計劃承諾4.簡述開發(fā)過程的專用目標與專用實踐答：專用目標1:SG1開發(fā)客戶需求，2個專用實踐 SP1.1引出要求SP1.2開發(fā)客戶需求 專用目標2:SG2開發(fā)產品需求，3個專用實踐SP2.1 建立產品和產品構件的需求SP2.2分配產品構件需求SP2.3標識接口需求 專用目標3:SG3分析并驗證需求,5個專用實踐SP3.1建立操作概念和場景SP3.2建立所需功能的定義SP3.3分析需求SP3.4分析需求，達到權衡SP3.5確認需求5.簡述共

41、用目標2及其相關的共用實踐共用目標2:GG2把過程制度化為一個已管理過程，10個共用實踐GP2.1建立組織策略GP2.2規(guī)劃該過程GP2.3提供資源GP2.4指定責任GP2.5培訓人員GP2.6管理配置GP2.7標識相關利益方的參與GP2.8監(jiān)控該過程GP2.9客觀地評估過程的符合性GP2.10以高層管理的視覺評審狀態(tài)6.簡述各共用目標及其相關的共用實踐簡述共用目標2及其相關的共用實踐答37這是用PDL書寫的一段程序。請根據你的理解，用N-S圖表示它。P65頁beginA；While(P1)if(P2)B；elseC；D；End需求發(fā)現的常用技術中，無法驗證所發(fā)現的需求是否滿足用戶的要求，而且

42、無法驗證其正確性的是_自悟_和_提煉_。31簡述軟件需求的分類及其關系。P23-24； 答：軟件需求可以分為功能需求和非功能需求2大類；功能需求規(guī)定了系統(tǒng)及構件必須執(zhí)行的功能；非功能需求又可以分為性能需求、外部接口需求、設計約束和質量屬性需求。功能需求是整個軟件需求的主體，沒有功能需求就沒有性能、外部接口、設計約束和質量的需求；一個非功能需求可以作用于1個或多個功能需求。32什么是模塊?什么是模塊內聚?請列出從低到高的常見內聚類型。P56、57、58、59 答：模塊是執(zhí)行一個特殊任務的過程以及相關的數據結構。內聚是指一個模塊內部各個成分之間相互關聯(lián)程度的度量。從低到高的內聚類型：偶然內聚；邏輯

43、內聚；時間內聚；過程內聚；通信內聚；順序內聚；功能內聚。33什么是狀態(tài)?什么是狀態(tài)圖?簡述實際應用中使用狀態(tài)圖的作用。107、108、113 答：狀態(tài)是類目的一個實例在其生存中的一種條件或情況；期間該實例滿足這一條件，就執(zhí)行某一活動或等待一個消息。狀態(tài)圖是現實狀態(tài)機的圖，強調從一個狀態(tài)到另一個狀態(tài)的控制流。在實際使用中狀態(tài)圖的作用：創(chuàng)建一個系統(tǒng)的動態(tài)圖和創(chuàng)建一個場景的模型。34簡述RUP中需求獲取的基本步驟和相關制品。P132答：需求獲取的步驟和相關制品：第1步是列出候選的特征，相關制品是特征表；第2步是理解系統(tǒng)語境，相關制品是領域模型或業(yè)務模型；第3步是捕獲系統(tǒng)功能需求，相關制品是用況模型（

44、use case模型）；第4步是捕獲非功能需求，相關制品是補充的需求或針對特殊需求的用況。35簡述黑盒測試技術的要點。P186答：黑盒測試技術的要點： （1）支持測試工程模型的中間部分； （2）事務流測試技術是將路徑測試技術用于功能測試的產物，是一種實用的功能測試技術，通過事務的操作邏輯發(fā)現軟件中的錯誤； （3）事務流測試技術是基于軟件規(guī)約的，對錯誤的假定是軟件通過了與預想不同的事務路徑； （4）基于事務的基本操作；事務流測試技術的最大問題和最大代價是獲取事務流程圖及用例設計； （5）事務處理流程測試要達到基本的測試覆蓋。36簡述增量模型以及可適應的情況。P224答：增量模型意指需求可以結構化

45、分組，形成一個個增量，并形成一個結構，之后對每一個增量進行瀑布開發(fā)。 用增量模型開發(fā)的前提是需求的結構化，模型適合“技術驅動”的軟件產品開發(fā)。31.軟件開發(fā)方法：一種使用早已定義好的技術集及符號表示習慣來組織軟件生產的過程.32.數據字典: 簡稱，就是用來定義數據流圖中的各個成分具體含義的，它以一種準確的、無二義性的說明方式為系統(tǒng)的分析、設計及維護提供了有關元素的一致的定義和詳細的描述.33.黑盒測試法：將程序當成是黑盒子以設計中的功能為標準在程序的接口出進行測試看它能否達到功能要求。34.軟件質量保證：向用戶及社會提供滿意的高質量的產品，確保軟件產品從誕生到消亡為止的所有階段的質量活動，即確

46、定、達到和維護需要的軟件質量而進行的所有有計劃、有系統(tǒng)的管理活動。35.模塊的作用范圍：一個模塊的控制范圍是指它本身及其所有下屬模塊的集合。這里下屬模塊包括直接下屬模塊及下屬模塊的下屬模塊36.簡述軟件產品的特性。答：1.軟件產品是一種邏輯產品。2.軟件產品的生產主是研制，軟件產品的成本主要體現在軟件的開發(fā)和研制上，軟件開發(fā)完成后，復制就產生了大量軟件產品。 3 .軟件產品不會用壞，不存在磨損、消耗問題。4.軟件產品的生產主要是腦力勞動，還未完全擺脫手工開發(fā)方式，而且碰分是"定做"的。5.軟件費用不斷增加，成本相當昂貴。37.簡述在需求分析基本任務中，對問題的綜合需求包括哪

47、幾個方面。答: 一.確定對系統(tǒng)的綜合要求1. 功能需求這方面的需求指定系統(tǒng)必須提供的服務。通過需求分析應該劃分出系統(tǒng)必須完成的所有功能。2. 性能需求性能需求指定系統(tǒng)必須滿足的定時約束或容量約束，通常包括速度(響應時間)、信息量速率、主存容量、磁盤容量、安全性等方面的需求。3. 可靠性和可用性需求可靠性需求定量地指定系統(tǒng)的可靠性。可用性與可靠性密切相關，它量化了用戶可以使用系統(tǒng)的程度。4. 出錯處理需求這類需求說明系統(tǒng)對環(huán)境錯誤應該怎樣響應。例如，如果它接收到從另一個系統(tǒng)發(fā)來的違反協(xié)議格式的消息，應該做什么?注意，上述這類錯誤并不是由該應用系統(tǒng)本身造成的。5. 接口需求接口需求描述應用系統(tǒng)與它的環(huán)境通信的格式。常見的接口需求有：用戶接口需求；硬件接口需求；軟件接口需求；通信接口需求。6. 約束設計約束或實現約束描述在設計或實現應用系統(tǒng)時應遵守的限制條件。在需求分析階段提出這類需求，并不是要取代設計(或實現)過程，只是說明用戶或環(huán)境強加給項目的限制條件。常見的約束有：精度；工具和語言約束；設計約束；應該使用的標準；應該使用的硬件平臺。7. 逆向需求逆向需求說明軟件系統(tǒng)不應該做什么。理論上有無