【正文】 考試提綱：（ 選擇題（ 3*10）、簡答題（ 6*9） ） 1. 軟件工程的定義 2. 軟件生存周期 3. 軟件過程模型 4. 需求分析的定義、獲取 5. 常見的軟件體系結(jié)構(gòu)（ B/S 、 C/S 、 軟件總線中間件） 6. SOA 的定義、特點(diǎn)、和工作模型（松耦合、明確定義的接口） 7. 云計(jì)算的定義、優(yōu)勢(shì)和應(yīng)用模型 8. 軟件測(cè)試的概念、原則、方法和測(cè)試策略 9. 軟件維護(hù)的類型 10. 軟件項(xiàng)目管理的管理過程和領(lǐng)域 11. 成本估算模型、進(jìn)度計(jì)劃的方法 12. 風(fēng)險(xiǎn)管理、質(zhì)量管理的概念 13. CMM 第一章 1. 軟件工程的定義：（ P3） 軟件工程是 一門指導(dǎo)軟件開發(fā)的工程學(xué)科，它以計(jì)算機(jī)理論及其他相關(guān)學(xué)科的理論為指導(dǎo)，采用工程化的概念、原理、技術(shù)和方法進(jìn)行軟件的開發(fā)和維護(hù)，把經(jīng)實(shí)踐證明的科學(xué)的管理措施與最先進(jìn)的技術(shù)方法結(jié)合起來。 軟件工程研究的目標(biāo)是“以較少的投資獲取高質(zhì)量的軟件”。 2. 軟件生存期 （ P5） 軟件生命周期（ SDLD）是指一個(gè)從用戶需求開始，經(jīng)過開發(fā)、交付使用，在使用中不斷地增補(bǔ)修訂，直至軟件報(bào)廢的全過程，亦稱軟件生存期（ Life Cycle）。 軟件生命周期分為以下階段： ① 可行性研究和項(xiàng)目開發(fā)計(jì)劃。該階段必須要回答的問題是“要解決的問題是什么”。 ② 需求分析。該階段的任務(wù)不是具體地解決問題，而是準(zhǔn)確地確定“軟件系統(tǒng)必須做什么”，確定軟件系統(tǒng)必須具備哪些功能。 ③ 概要設(shè)計(jì)。 概要設(shè)計(jì)就是設(shè)計(jì)軟件的結(jié)構(gòu)，該結(jié)構(gòu)由哪些模塊組成，這些模塊的層次結(jié)構(gòu)是怎樣的，這些模塊的調(diào)用關(guān)系是怎樣的，每個(gè)模塊的功能是什么。同時(shí)還要設(shè)計(jì)該項(xiàng)目的應(yīng)用系統(tǒng)的總體數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)庫結(jié)構(gòu)，即應(yīng)用系統(tǒng)要存儲(chǔ)什么數(shù)據(jù)，這些數(shù)據(jù)是什么樣的結(jié)構(gòu)，它們之間有什么關(guān)系等。 ④ 詳細(xì)設(shè)計(jì)。即對(duì)每個(gè)模塊完成的功能進(jìn)行具體描述，要把功能描述變?yōu)榫_的、結(jié)構(gòu)化的過程描述。 ⑤ 編碼。該階段把每個(gè)模塊的控制結(jié)構(gòu)轉(zhuǎn)換成計(jì)算機(jī)可接受的程序代碼，即寫成以某特定程序設(shè)計(jì)語言表示的“源程 序”。 ⑥ 測(cè)試。它是保證軟件質(zhì)量的重要手段，其主要方式是在設(shè)計(jì)測(cè)試用例的基礎(chǔ)上檢驗(yàn)軟件的各個(gè)組成部分。測(cè)試分為，模塊測(cè)試、組裝測(cè)試、確認(rèn)測(cè)試等。 ⑦ 維護(hù)。軟件維護(hù)是軟件生存期中時(shí)間最長的階段。已交付的軟件投入正式使用后，便進(jìn)入軟件維護(hù)階段，它可以持續(xù)幾年甚至幾十年。 在大部分文獻(xiàn)中將生存期劃分為 5 個(gè)階段，即 要求定義、設(shè)計(jì)、編碼、測(cè)試及維護(hù)。其中 要求定義階段包括可行性研究和項(xiàng)目開發(fā)計(jì)劃及需求分析，設(shè)計(jì)階段包括概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)。 為了描述軟件生存 期的活動(dòng)，提出了多種生存期模型，如瀑布模型、循壞模型、螺旋模型、噴泉模型、智能模型等。 3. 目前常見的軟件過程模型如下： 瀑布模型、增量模型、螺旋模型、噴泉模型、智能模型等。 1) 瀑布模型 優(yōu)點(diǎn)：在軟件工程的第一階段，瀑布模型得到了廣泛的應(yīng)用，它簡單易用，在消除非結(jié)構(gòu)化軟件，降低軟件的復(fù)雜性，促進(jìn)軟件開發(fā)工程化方面起了很大的作用。 缺點(diǎn)： 由于瀑布模型是一種理想的線性開發(fā)模式，它將一個(gè)充滿回溯的軟件開發(fā)過程硬性分割為幾個(gè)階段，無法解決軟件需求不明確或者變動(dòng)的問題。這些缺點(diǎn)對(duì)軟件開發(fā)帶來了嚴(yán)重影響，由于需求不明確，會(huì)導(dǎo)致開發(fā)的軟件不符合用戶的需求而夭折。 2) 增量模型 (incremental model) ? 增量模型是一種非整體開發(fā)的模型。是一種進(jìn)化式的開發(fā)過程。 ? 根據(jù)增量的方式和形式的不同，分為： ? 基于瀑布模型的漸增模型 ? 基于原型的快速原型模型 ? 該模型具有較大的靈活性，適合于軟件需求不明確、設(shè)計(jì)方案有一定風(fēng)險(xiǎn)的軟件項(xiàng)目。 ? 增量模型和瀑布模型之間的本質(zhì)區(qū)別是什么？ 增量模型和瀑布模型之間的本質(zhì)區(qū)別是 ：瀑布模型屬于整體開發(fā)模型，它規(guī)定在開始下一個(gè)階段的工作之前，必須完成前一階段的所有細(xì)節(jié)。而增量模型屬于非整體開發(fā)模型，它推遲某些階段或所有階段中的細(xì)節(jié)，從而較早地產(chǎn)生工作軟件。 ? 一般的增量模型如下： 3) 螺旋模型 ? 對(duì)大型軟件 ,需要多個(gè)原型描述系統(tǒng)的生存期，螺旋模型將瀑布模型與原型化模型結(jié)合起來 ,并加入了風(fēng)險(xiǎn)分析。 ? 該模型將開發(fā)過程分為幾個(gè)螺旋周期，每個(gè)螺旋周期可分為 4 個(gè)工作步驟： ① 制定計(jì)劃：確定目標(biāo) 、方案和限制條件； ② 風(fēng)險(xiǎn)分析：評(píng)估方案、標(biāo)識(shí)風(fēng)險(xiǎn)和解決風(fēng)險(xiǎn)； ③ 實(shí)施工程：開發(fā)確認(rèn)產(chǎn)品； ④ 客戶評(píng)估：計(jì)劃下一周期工作。 ? 一般的螺旋模型如下圖：沿著螺旋線每轉(zhuǎn)一圈，表示開發(fā)出一個(gè)更完善的新的軟件版本。如果開發(fā)風(fēng)險(xiǎn)過大，開發(fā)機(jī)構(gòu)和客戶無法接受，項(xiàng)目有可能就此中止；多數(shù)情況喜下，會(huì)沿著螺旋線繼續(xù)下去，自內(nèi)向外逐步延伸，最終得到滿意的軟件產(chǎn)品。 4) 噴泉模型 噴泉模型以面向?qū)ο蟮能浖_發(fā)方法為基礎(chǔ)，以用戶需求作為噴泉模型的源泉。如下圖： 6. 噴泉模型是對(duì)象驅(qū)動(dòng)的過程，對(duì)象是所有活動(dòng)作用的實(shí)體，也是項(xiàng)目管理的基本內(nèi)容。 7. 噴泉模型在實(shí)現(xiàn)時(shí)，由于活動(dòng)不同，可分為系統(tǒng)實(shí)現(xiàn)和對(duì)象實(shí)現(xiàn)，這既反映了全系統(tǒng)的開發(fā)過程，也反映了對(duì)象族的開發(fā)和重用過程。 第二章 1. 需求分析的定義 在傳統(tǒng)軟件工程生命周期中，涉及軟件需求的階段稱做需求分析。 2. 需求工程的定義 需求工程是一個(gè)包括創(chuàng)新和維護(hù)系統(tǒng)需求文檔所必須的一切活動(dòng)，是對(duì)系統(tǒng)應(yīng)該提供的服務(wù)和所受到的約束進(jìn)行理解、分析、檢驗(yàn)和建立文檔的過程。 3. 需求的獲取和分析 需求的獲取和分析是需求工程的關(guān)鍵和核心步驟，直接影響到后期的開發(fā)工作和系統(tǒng)的成敗。 ? 需求獲取 在深入實(shí)際調(diào)查研究，充分理解用戶需求的基礎(chǔ)上，獲取系統(tǒng)需求。獲取過程為： ① 了解領(lǐng)域知識(shí)，工程技術(shù)人員需要依靠領(lǐng)域?qū)＜?，學(xué)習(xí)和理解相關(guān)的專業(yè)知識(shí)，才能正確抽取用戶需求。 ② 需求收集，與項(xiàng)目相關(guān)人員進(jìn)行溝通，在進(jìn)一步了解專業(yè)領(lǐng)域的基礎(chǔ)上，發(fā)現(xiàn)系統(tǒng)需求的過程。 ? 需求分析 需求分析的過程是對(duì)收集到的需求進(jìn)行提煉、分析和審查的過程，最終確定需求，并確保所有項(xiàng)目相關(guān)人員對(duì)需求取得一致性認(rèn)識(shí)。分析階段的主要工作包括： ① 確定系統(tǒng)范圍。確定系統(tǒng)與其他外部實(shí)體或其他系統(tǒng)的邊界和接口。 ② 分類排序。對(duì)所收集的需求進(jìn)行重新組織、整理、分類和篩選，并對(duì)每類需求進(jìn)行排序，確定哪些是最重要的需求。 ③ 建立需求分析 模型。這是分析階段的核心工作。需求分析模型是對(duì)需求的主要描述手段，是根據(jù)不同的分析方法建立的各種視圖，例如數(shù)據(jù)流圖（ DFD）、實(shí)體關(guān)系圖（ ER）、用例圖（ Use Case）、類圖、狀態(tài)圖、各種交互圖等。還可建立輔助的說明，如數(shù)據(jù)詞典。 ④ 建立需求規(guī)格說明。軟件需求規(guī)格說明（ Software Requirement Specification ,SRS）是將需求的結(jié)果按照不同開發(fā)方法規(guī)定的格式用圖形和文檔形式描述出來。需求規(guī)格說明在整個(gè)開發(fā)過程中具有很重要的作用，是用戶和開發(fā)人 員之間進(jìn)行交流和理解系統(tǒng)的手段。用戶通過需求規(guī)格說明檢查是否符合和滿足所提出的全部需求。開發(fā)者則通過需求規(guī)格文檔，了解和理解 所開發(fā)系統(tǒng)的內(nèi)容，并以此作為軟件設(shè)計(jì)和軟件測(cè)試的依據(jù)。項(xiàng)目管理人員以它為依據(jù)，規(guī)劃軟件開發(fā)過程、計(jì)劃，估算軟件成本和控制需求的變更過程。 第三章 ? 軟件體系結(jié)構(gòu)設(shè)計(jì) ? 倉庫模型（ The repository model） 也稱“容器模型 ”，是一種集中式的模型。 在這種結(jié)構(gòu)模型當(dāng)中，應(yīng)用 系統(tǒng) 用一個(gè)中央數(shù)據(jù)倉庫來存儲(chǔ)各個(gè)子系統(tǒng) 共享的數(shù)據(jù)，其它的子系統(tǒng)可以直接訪問這些共享數(shù)據(jù)。 當(dāng)然，每個(gè)子系統(tǒng)可能會(huì)有自己的數(shù)據(jù)庫。為了共享數(shù)據(jù)，所有的 子系統(tǒng)之間緊密耦合 的，并且圍繞中央數(shù)據(jù)倉庫，如下圖： 倉庫模型的主要優(yōu)點(diǎn)： ① 數(shù)據(jù)由一個(gè)子系統(tǒng)產(chǎn)生，并且被另外一些子系統(tǒng)共享； ② 共享數(shù)據(jù)能得到有效的管理，各子系統(tǒng)之間不需要通過復(fù)雜的機(jī)制來傳遞共享數(shù)據(jù)。 ③ 一個(gè)子系統(tǒng)不必關(guān)心其他的子系統(tǒng)是如何使用它產(chǎn)生的數(shù)據(jù)的 。 ④ 所有的子系統(tǒng)都擁有一致的基于中央數(shù)據(jù)倉庫的數(shù)據(jù)視圖。如果 新子系統(tǒng)也采用相同的規(guī)范，則將它集成與系統(tǒng)中是容易的 。 倉庫模型的主要缺點(diǎn)： ① 為了共享數(shù)據(jù) ,各子系統(tǒng)必須有一致的數(shù)據(jù)視圖 ，不可避免地會(huì)影響了整個(gè)系統(tǒng)的性能。 ② 一個(gè) 子系統(tǒng)發(fā)生了改變，它產(chǎn)生的數(shù)據(jù)結(jié)構(gòu)也可能發(fā)生改變。 為了其他共享的目的，數(shù)據(jù)翻譯系統(tǒng)會(huì)被用到。但這種翻譯的代價(jià)是很高的，并且有時(shí)是不可能完成的。 ③ 中央數(shù)據(jù)倉庫和各子系統(tǒng)擁有的數(shù)據(jù)庫必須有相同的關(guān)于備份、安全、訪問控制和恢復(fù)的策略，這可能會(huì)影響子系統(tǒng)的效率。 ④ 集中式的控制使數(shù)據(jù)和子系統(tǒng)的分布變得非困難甚至成為不可能。這里分布指的是將數(shù)據(jù)或子系統(tǒng)分散到不同的機(jī)器上。 一般來說，命令控制系統(tǒng)、 CAD 系統(tǒng)等常采用這種結(jié)構(gòu)。 ? 分布式結(jié)構(gòu) 分布式結(jié)構(gòu)有如下一些優(yōu)勢(shì)： ① 資源共享：系統(tǒng)中每個(gè)服務(wù)結(jié)點(diǎn)上的資源都可以被系統(tǒng)中的其他結(jié)點(diǎn)訪問。 ② 開放性高：系統(tǒng)可以方便地增刪不同軟、硬件結(jié)構(gòu)的結(jié)點(diǎn)。 ③ 可伸縮性好：系統(tǒng)可以方便的增刪新的服務(wù)資源以滿足需要。 ④ 容錯(cuò)能力強(qiáng)：分布式系統(tǒng)中的信息冗余可以容忍一定程度的軟、硬件故障。 ⑤ 透明性高：系統(tǒng)中的結(jié)點(diǎn)一般只需知道服務(wù)的位置而不必清楚系統(tǒng) 的結(jié)構(gòu)。 分布式結(jié)構(gòu)有如下一些不足： ① 復(fù)雜性：分布式系統(tǒng)比集中式系統(tǒng)要復(fù)雜的多。集中式系統(tǒng)的性能主要依賴于主機(jī)的處理能力，而分布式系統(tǒng)的性能則還要依賴于網(wǎng)絡(luò)的帶寬，這讓情況變得更加 復(fù)雜。 ② 安全性：網(wǎng)絡(luò)環(huán)境隨時(shí)