【正文】 倉庫模型的主要優(yōu)點： ① 數(shù)據(jù)由一個子系統(tǒng)產(chǎn)生，并且被另外一些子系統(tǒng)共享； ② 共享數(shù)據(jù)能得到有效的管理，各子系統(tǒng)之間不需要通過復(fù)雜的機制來傳遞共享數(shù)據(jù)。項目管理人員以它為依據(jù)，規(guī)劃軟件開發(fā)過程、計劃，估算軟件成本和控制需求的變更過程。軟件需求規(guī)格說明（ Software Requirement Specification ,SRS）是將需求的結(jié)果按照不同開發(fā)方法規(guī)定的格式用圖形和文檔形式描述出來。這是分析階段的核心工作。確定系統(tǒng)與其他外部實體或其他系統(tǒng)的邊界和接口。獲取過程為： ① 了解領(lǐng)域知識，工程技術(shù)人員需要依靠領(lǐng)域?qū)＜遥瑢W(xué)習(xí)和理解相關(guān)的專業(yè)知識，才能正確抽取用戶需求。 第二章 1. 需求分析的定義 在傳統(tǒng)軟件工程生命周期中，涉及軟件需求的階段稱做需求分析。如果開發(fā)風(fēng)險過大，開發(fā)機構(gòu)和客戶無法接受，項目有可能就此中止；多數(shù)情況喜下，會沿著螺旋線繼續(xù)下去，自內(nèi)向外逐步延伸，最終得到滿意的軟件產(chǎn)品。而增量模型屬于非整體開發(fā)模型，它推遲某些階段或所有階段中的細節(jié)，從而較早地產(chǎn)生工作軟件。 2) 增量模型 (incremental model) ? 增量模型是一種非整體開發(fā)的模型。 3. 目前常見的軟件過程模型如下： 瀑布模型、增量模型、螺旋模型、噴泉模型、智能模型等。已交付的軟件投入正式使用后，便進入軟件維護階段，它可以持續(xù)幾年甚至幾十年。它是保證軟件質(zhì)量的重要手段，其主要方式是在設(shè)計測試用例的基礎(chǔ)上檢驗軟件的各個組成部分。即對每個模塊完成的功能進行具體描述，要把功能描述變?yōu)榫_的、結(jié)構(gòu)化的過程描述。 ③ 概要設(shè)計。 軟件生命周期分為以下階段： ① 可行性研究和項目開發(fā)計劃?？荚囂峋V：（ 選擇題（ 3*10）、簡答題（ 6*9） ） 1. 軟件工程的定義 2. 軟件生存周期 3. 軟件過程模型 4. 需求分析的定義、獲取 5. 常見的軟件體系結(jié)構(gòu)（ B/S 、 C/S 、 軟件總線中間件） 6. SOA 的定義、特點、和工作模型（松耦合、明確定義的接口） 7. 云計算的定義、優(yōu)勢和應(yīng)用模型 8. 軟件測試的概念、原則、方法和測試策略 9. 軟件維護的類型 10. 軟件項目管理的管理過程和領(lǐng)域 11. 成本估算模型、進度計劃的方法 12. 風(fēng)險管理、質(zhì)量管理的概念 13. CMM 第一章 1. 軟件工程的定義：（ P3） 軟件工程是 一門指導(dǎo)軟件開發(fā)的工程學(xué)科，它以計算機理論及其他相關(guān)學(xué)科的理論為指導(dǎo)，采用工程化的概念、原理、技術(shù)和方法進行軟件的開發(fā)和維護，把經(jīng)實踐證明的科學(xué)的管理措施與最先進的技術(shù)方法結(jié)合起來。該階段必須要回答的問題是“要解決的問題是什么”。 概要設(shè)計就是設(shè)計軟件的結(jié)構(gòu)，該結(jié)構(gòu)由哪些模塊組成，這些模塊的層次結(jié)構(gòu)是怎樣的，這些模塊的調(diào)用關(guān)系是怎樣的，每個模塊的功能是什么。 ⑤ 編碼。測試分為，模塊測試、組裝測試、確認測試等。 在大部分文獻中將生存期劃分為 5 個階段，即 要求定義、設(shè)計、編碼、測試及維護。 1) 瀑布模型 優(yōu)點：在軟件工程的第一階段，瀑布模型得到了廣泛的應(yīng)用，它簡單易用，在消除非結(jié)構(gòu)化軟件，降低軟件的復(fù)雜性，促進軟件開發(fā)工程化方面起了很大的作用。是一種進化式的開發(fā)過程。 ? 一般的增量模型如下： 3) 螺旋模型 ? 對大型軟件 ,需要多個原型描述系統(tǒng)的生存期，螺旋模型將瀑布模型與原型化模型結(jié)合起來 ,并加入了風(fēng)險分析。 4) 噴泉模型 噴泉模型以面向?qū)ο蟮能浖_發(fā)方法為基礎(chǔ)，以用戶需求作為噴泉模型的源泉。 2. 需求工程的定義 需求工程是一個包括創(chuàng)新和維護系統(tǒng)需求文檔所必須的一切活動，是對系統(tǒng)應(yīng)該提供的服務(wù)和所受到的約束進行理解、分析、檢驗和建立文檔的過程。 ② 需求收集，與項目相關(guān)人員進行溝通，在進一步了解專業(yè)領(lǐng)域的基礎(chǔ)上，發(fā)現(xiàn)系統(tǒng)需求的過程。 ② 分類排序。需求分析模型是對需求的主要描述手段，是根據(jù)不同的分析方法建立的各種視圖，例如數(shù)據(jù)流圖（ DFD）、實體關(guān)系圖（ ER）、用例圖（ Use Case）、類圖、狀態(tài)圖、各種交互圖等。需求規(guī)格說明在整個開發(fā)過程中具有很重要的作用，是用戶和開發(fā)人 員之間進行交流和理解系統(tǒng)的手段。 第三章 ? 軟件體系結(jié)構(gòu)設(shè)計 ? 倉庫模型（ The repository model） 也稱“容器模型 ”，是一種集中式的模型。 ③ 一個子系統(tǒng)不必關(guān)心其他的子系統(tǒng)是如何使用它產(chǎn)生的數(shù)據(jù)的 。 ② 一個 子系統(tǒng)發(fā)生了改變，它產(chǎn)生的數(shù)據(jù)結(jié)構(gòu)也可能發(fā)生改變。 ④ 集中式的控制使數(shù)據(jù)和子系統(tǒng)的分布變得非困難甚至成為不可能。 ② 開放性高：系統(tǒng)可以方便地增刪不同軟、硬件結(jié)構(gòu)的結(jié)點。 分布式結(jié)構(gòu)有如下一些不足： ① 復(fù)雜性：分布式系統(tǒng)比集中式系統(tǒng)要復(fù)雜的多。 ④ 不可預(yù)知性：這主要指系統(tǒng)的響應(yīng)時間。 ② 客戶（ Client） :多個并發(fā)客戶應(yīng)用訪問多個服務(wù)器提供的服務(wù)，每個客戶應(yīng)用都是獨立的同樣的客戶應(yīng)用可以同時有多個實例。 C/S 結(jié)構(gòu)的應(yīng)用都由三個相對獨立的邏輯部分組成： ① 用戶界面部分：數(shù)據(jù)表示層，實現(xiàn)與用戶交互。其結(jié)構(gòu)如下圖： ? 現(xiàn)在舉數(shù)據(jù)庫應(yīng)用的例子來說明兩層 C/S 結(jié)構(gòu)的工作方式。實際上， C/S 的工作 模式是一種遠程過程調(diào)用（ Remote Procedure Call, RPC）模式。這種結(jié)構(gòu)往往被稱為胖客戶端（ FatClient）結(jié)構(gòu)，一般的數(shù)據(jù)庫應(yīng)用都是屬于這種結(jié)構(gòu)的。 不過，越來越多的 B/S 應(yīng)用包含了一些可以遷移的代碼，例如包含客戶端腳本的網(wǎng)頁，這些代碼從服務(wù)器端下載到客戶端并在客戶端執(zhí)行，這樣一來，客戶端也或多或少地要處理一部分的應(yīng)用邏輯。因此， C/S 架構(gòu)不適合用在多用戶、多數(shù)據(jù)庫、非安全的網(wǎng)絡(luò)環(huán)境中。 第三級是用戶界面級，強調(diào)高效、方便易用的用戶界面。這是一種典型的 B/S結(jié)構(gòu)。 ③ 降低了部署與維護的開銷，提高了靈活性、可伸縮性。 ? 每個對象在邏輯上是平等的，它們可以互相為對方提供所需的服務(wù)。為了將分散的對象提供的服務(wù)“串”起來，一種被形象地稱為“軟 件總線（ Software Bus)”的中間件起了關(guān)鍵的作用。由對象管理組織 OMG （ Object Management Group）提出的應(yīng)用軟件體系結(jié)構(gòu)和對象技術(shù)規(guī)范 。 EJB 構(gòu)件駐留在 EJB 容器中。支撐應(yīng)用的計算機硬件、操作系統(tǒng)、網(wǎng)絡(luò)協(xié)議、數(shù)據(jù)庫系統(tǒng)，以及開發(fā)工具種類繁多，需要考慮數(shù)據(jù)表示、調(diào)用接口、處理方式等諸多問題。 ⑤ 業(yè)務(wù)邏輯集中放在服務(wù)器上有所有用戶共享，使得系統(tǒng)的維護和更新變得簡單，也更安全。 ? 接口是采用中立的方式進行定義的，它應(yīng)該獨立于實現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言。 ? 服務(wù)（ service）是封裝成用于業(yè)務(wù)流程的可復(fù)用構(gòu)件的應(yīng)用程序函數(shù)。 ④ 在復(fù)雜的應(yīng)用程序里，業(yè)務(wù)過程的控制可以被隔離：引入一個業(yè)務(wù)規(guī)則引擎用來控制已經(jīng)定義好的業(yè)務(wù)過程流。 ? 明確定義的接口 ? 服務(wù)交互必須是明確定義的 ? Web 服務(wù)描述語言（ Web services Description Language， WSDL）是受到廣泛支持的方法，用于描述服務(wù)請求者所要求的綁定到服務(wù)提供者的細節(jié) ? 服務(wù) ? 調(diào)用操作的消息 ? 構(gòu)造這種消息的細節(jié) ? 關(guān)于向何處發(fā)送用于構(gòu)造這種消息的處理細節(jié)的消息的信息 ? 無狀態(tài)的服務(wù)設(shè)計 ? 服務(wù)應(yīng)該是獨立的、自包含的請求，在實現(xiàn)時它不需要從一個請求到另一個請求的信息或狀態(tài) ? 服務(wù)不應(yīng)該依賴于其他服務(wù)的上下文和狀態(tài)。 2. 云計算的優(yōu)勢： ① 開發(fā)容易快速 ② 無多余的開支 ③ 每月花費低 ④ IT 人員減少，費用降低 ⑤ 提供最新的技術(shù)和功能 ⑥ 支持、推行 IT 標(biāo)準 ⑦ 系統(tǒng)和信息共享更容易 3. 云計算的應(yīng)用模型 ? 云計算三種服務(wù)方式 ? SAAS（ Software as a Service ） ? PAAS（ Platform as a Service ） ? IAAS（ Infrastructure as a Service ） ? 云計算的應(yīng)用 —IAAS（ Infrastructure as a Service） ? 實現(xiàn)模式 ? 完全操作系統(tǒng)（軟硬件）接入 ? 防火墻 ? 路由器 ? 負載平衡 ? 優(yōu)勢 ? 節(jié)省費用 /所付及所用 ? 即時升級 ? 安全 ? 可靠 ? APIs ? 實例 ? 當(dāng)你想運行成批的程序組，但是沒有合適的軟硬件環(huán)境，可使用 Amazon的 EC2。 可靠。一般而言，測試計劃可以在需求分析完成后開始，詳細的測試用例定義可以在設(shè)計模型被確定后立即開始，因此，所有測試可以在任何代碼被編寫前進行計劃和設(shè)計。即從模塊測試開始，再進行系統(tǒng)測試。 ? 其他的測試原則： ① 在設(shè)計測試用例時，應(yīng)包括合理的輸入條件和不合理的輸入條件 ②嚴格執(zhí)行測試計劃，排除測試的隨意性 ③ 應(yīng)當(dāng)對每一個測試結(jié)果做全面檢查 ④妥善保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告，為維護提供方便 ⑤檢查程序是否做了應(yīng)做的事僅是成功的一半，另一半是檢查程序是否做了不該做的事。 ? 黑盒測試法注重于測試軟件的功能需求，主要試圖發(fā)現(xiàn)下列幾類錯誤：功能不對或遺漏；性能錯誤；初始化和終止錯誤；界面錯誤；數(shù)據(jù)結(jié)構(gòu)或外部數(shù)據(jù)庫訪問錯誤。 ? 單元測試的內(nèi)容 ① 模塊接口 ② 局部數(shù)據(jù)結(jié)構(gòu) ③ 重要的執(zhí)行路徑 ④ 邊界條件 ⑤ 錯誤處理 ? 單元測試步