軟件需求-一二部分

軟件需求工程太原理工大學(xué)計(jì)算機(jī)學(xué)院張澤華

軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-2工程方法學(xué)成功往往來之不易軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-3案例：小型圖書資料管理系統(tǒng)問題描述–某學(xué)院打算開發(fā)一個(gè)小型圖書資料管理系統(tǒng)MiniLibrary，該系統(tǒng)基于Internet實(shí)現(xiàn)教師和學(xué)生對(duì)各種圖書資料的借閱、查詢和管理。–圖書管理員負(fù)責(zé)管理各種圖書資料，查詢圖書資料信息，并進(jìn)行圖書的借閱管理。–注冊(cè)用戶可以通過Internet隨時(shí)查詢圖書資料信息和個(gè)人借閱情況，預(yù)訂目前借不到的圖書資料，并可以快捷地查找和瀏覽所需要的電子資料。–系統(tǒng)可以提供適當(dāng)?shù)臑g覽器供用戶閱讀電子文獻(xiàn)資料。–要求用戶界面友好，響應(yīng)速度快，具有良好的可擴(kuò)展性。軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-4軟件需求的重要性軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-5內(nèi)容概要軟件需求的基本概念需求工程與需求工程過程需求獲取與需求分析需求文檔與需求質(zhì)量驗(yàn)證軟件需求管理軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-6第一部分軟件需求的基本概念需求問題

需求的層次軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-7第1章 需求問題需求是軟件項(xiàng)目成敗的關(guān)鍵所在。越早發(fā)現(xiàn)需求錯(cuò)誤，越早改正它，其代價(jià)越小需求是系統(tǒng)必須具有的能力。好需求的特征：無歧義、完整、一致、可檢驗(yàn)、確定、可跟蹤的，正確的，可行的和必要的。軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-8從諺語開始中國有句諺語：“好的開始就等于成功的一半”西方的諺語是：“Garbagein,garbageout！”

軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-9軟件開發(fā)的目標(biāo)軟件開發(fā)的目標(biāo)，簡單而言，就是滿足用戶的需要。軟件需求是決定軟件開發(fā)是否成功的一個(gè)關(guān)鍵因素–需求分析可以幫助開發(fā)人員真正理解業(yè)務(wù)問題–需求分析是估算成本和進(jìn)度的基礎(chǔ)–需求分析可以避免建造錯(cuò)誤的系統(tǒng)，從而減少不必要的浪費(fèi)–軟件規(guī)格說明有助于開發(fā)人員與客戶在“系統(tǒng)應(yīng)該做什么”問題上達(dá)成正式契約–需求分析形成了軟件開發(fā)的基線，有助于管理軟件的演化和變更–軟件需求是軟件質(zhì)量的基礎(chǔ)，為系統(tǒng)驗(yàn)收測試提供了標(biāo)準(zhǔn)軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-10項(xiàng)目失敗與成功的原因*三種最經(jīng)常使項(xiàng)目“遇到困難”的因素是：缺乏用戶介入：占所有項(xiàng)目的13%不完整的需求和規(guī)格說明：占所有項(xiàng)目的12%不斷改變的需求和規(guī)格說明：占所有項(xiàng)目的12%三種項(xiàng)目最主要的“成功因素”是：用戶介入：占所有成功項(xiàng)目的16%高層管理的支持：占所有成功項(xiàng)目的14%需求陳述清晰：占所有成功項(xiàng)目的12%*[StandishGroup，1994]軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-11軟件項(xiàng)目失敗的原因軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-122-8原則*80%的工程活動(dòng)是由20%的需求消耗的80%的軟件成本是由20%的構(gòu)件消耗的*[Royce，1998]

軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-13需求在項(xiàng)目中的作用在項(xiàng)目開發(fā)中，所有的涉眾（Stakeholder）都對(duì)需求分析階段備感興趣。未真正明白這些問題就開始編碼，結(jié)果沒有人對(duì)產(chǎn)品滿意。軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-14需求錯(cuò)誤的代價(jià)在生命周期的不同階段修復(fù)缺陷的相對(duì)成本軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-15需求缺陷造成的成本增加重新進(jìn)行需求規(guī)格說明重新設(shè)計(jì)重新編碼重新測試改變訂單——告訴用戶將以一個(gè)修正后的版本來替代有缺陷的版本。糾正活動(dòng)——消除由于不準(zhǔn)確的特定系統(tǒng)的錯(cuò)誤造成的危害，可能涉及到賠償客戶損失。報(bào)廢——包括對(duì)于已經(jīng)完成的代碼、設(shè)計(jì)和測試，當(dāng)發(fā)現(xiàn)它們是根據(jù)不正確的需求進(jìn)行的時(shí)候，這些工作成果不得不被丟棄。收回有缺陷的軟件產(chǎn)品以及相關(guān)的用戶手冊(cè)。產(chǎn)品賠償或保修的成本。重新安裝新版本的成本。重新建檔的成本。軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-16高質(zhì)量的需求過程帶來的好處

在開發(fā)后期和整個(gè)維護(hù)階段的重做的工作大大減少了。讓用戶積極參與需求收集過程能使產(chǎn)品更富有吸引力，而且能建立起更加忠實(shí)的客戶關(guān)系。用戶的參與能彌補(bǔ)用戶期望和開發(fā)者實(shí)際開發(fā)之間的“鴻溝”（期望差異）。將確定的系統(tǒng)需求明確地分配到各軟件子系統(tǒng)，確保軟硬件系統(tǒng)功能匹配適當(dāng)。有效的變更控制也能降低需求變更帶來的負(fù)面影響。將需求編寫成清晰、無二義性的文檔將會(huì)極大地有利于系統(tǒng)測試，確保產(chǎn)品質(zhì)量。軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-17需求定義[IEEE1997]IEEE軟件工程標(biāo)準(zhǔn)詞匯表定義需求為：用戶解決問題或達(dá)到目標(biāo)所需的條件或能力。系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力。一種反映上面(1)或(2)所描述的條件或能力的文檔說明。軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-18需求定義[Thayer,Dorfman.1997]MerlinDorfman和RichardH.Thayer提出了一個(gè)包容且更為精練的定義：用戶解決某一問題或達(dá)到某一目標(biāo)所需的軟件功能。系統(tǒng)或系統(tǒng)構(gòu)件為了滿足合同、規(guī)約、標(biāo)準(zhǔn)或其他正式實(shí)行的文檔而必須滿足或具備的軟件功能。對(duì)定義的理解軟件需求的概念涵蓋了用戶角度（系統(tǒng)的外部行為）和開發(fā)人員角度（系統(tǒng)的內(nèi)部特性）兩個(gè)方面，其中的關(guān)鍵在于需求一定要文檔化。軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-19好的需求應(yīng)具有的特性無歧義性：去除模糊以及關(guān)鍵字技術(shù)完整性：注重用戶任務(wù)而不是系統(tǒng)功能一致性：用戶需求和業(yè)務(wù)需求，開發(fā)者功能與用

戶需求可檢驗(yàn)性：合理方法測試確定性：需求是確定的，明確滿足條件時(shí)會(huì)發(fā)生

什么，不滿足條件時(shí)會(huì)發(fā)生什么軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-20好的需求應(yīng)具有的特性（續(xù)）可跟蹤性：唯一標(biāo)示以便能在設(shè)計(jì)、實(shí)現(xiàn)和測試的跟蹤正確性：準(zhǔn)確描述用戶需求保證軟件需求的正確實(shí)現(xiàn)可行性：每條需求都必須是在已知的系統(tǒng)和環(huán)境的限制范圍內(nèi)可以實(shí)施的必要性：每條需求都應(yīng)把客戶真正所需要的和最終系統(tǒng)所需達(dá)到的要求記錄下來軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-21第二章需求的層次需求是多層次的，包括業(yè)務(wù)需求、用戶需求、功能需求和非功能需求。需求路線圖：涉眾需要—〉系統(tǒng)的特性—〉建立軟件需求軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-22軟件需求包括不同的層次軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-23業(yè)務(wù)需求業(yè)務(wù)需求是組織或客戶對(duì)于系統(tǒng)的高層次目標(biāo)要求，定義了項(xiàng)目的遠(yuǎn)景和范圍，即確定軟件產(chǎn)品的發(fā)展方向、功能范圍、目標(biāo)客戶和價(jià)值來源。?業(yè)務(wù)需求的內(nèi)容–業(yè)務(wù)：產(chǎn)品屬于哪類業(yè)務(wù)范疇？應(yīng)該完成什么功能？需要為什么服務(wù)？–客戶：產(chǎn)品為誰服務(wù)？目標(biāo)客戶是誰？–特性：產(chǎn)品區(qū)別于其他競爭產(chǎn)品的特性是什么？–價(jià)值：產(chǎn)品的價(jià)值體現(xiàn)在什么方面？–優(yōu)先級(jí)：產(chǎn)品功能特性的優(yōu)先級(jí)次序是什么？軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-24

業(yè)務(wù)需求：MiniLibrary業(yè)務(wù)要求–各種圖書資料的借閱、查詢和管理；–使用計(jì)算機(jī)實(shí)現(xiàn)圖書資料的日常管理，提高工作效率和服務(wù)質(zhì)量；–用戶通過網(wǎng)絡(luò)查詢和瀏覽電子資料，改變?cè)械慕栝喣Ｊ?；–由于版權(quán)的限制，某些電子資料只能讓用戶瀏覽和打印而不能下載。客戶與用戶–學(xué)院的高層管理者–圖書管理員–借閱者：教師、學(xué)生軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-25用戶需求用戶需求是從用戶角度描述的系統(tǒng)功能需求和非功能需求，通常只涉及系統(tǒng)的外部行為，而不涉及系統(tǒng)的內(nèi)部特性。用戶需求的描述–原則：應(yīng)該易于用戶的理解。一般不采用技術(shù)性很強(qiáng)的語言，而是采用自然語言和直觀圖形相結(jié)合的方式進(jìn)行描述。–問題：自然語言表達(dá)容易含糊和不準(zhǔn)確。軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-26

用戶需求：MiniLibrary舉例：–用戶可以通過Internet隨時(shí)查詢圖書信息和個(gè)人借閱情況，并可以快捷地查找和瀏覽所需要的電子資料。分析：上述需求描述包含了三個(gè)不同的需求–用戶可以通過Internet隨時(shí)查詢圖書信息。–用戶可以通過Internet隨時(shí)查詢個(gè)人借閱情況。–用戶可以通過Internet快捷地查找和瀏覽所需要的電子資料。問題：–“隨時(shí)”和“快捷”是對(duì)系統(tǒng)功能的約束，十分模糊。軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-27

系統(tǒng)需求系統(tǒng)需求是更加詳細(xì)地描述系統(tǒng)應(yīng)該做什么，通常包括許多不同的分析模型，諸如對(duì)象模型、數(shù)據(jù)模型、狀態(tài)模型等。系統(tǒng)需求模型的描述–結(jié)構(gòu)化英語（PDL）–可視化模型–形式化方法系統(tǒng)需求主要是面向開發(fā)人員進(jìn)行描述，是開發(fā)人員進(jìn)行軟件設(shè)計(jì)的基礎(chǔ)。軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-28功能需求功能需求–描述系統(tǒng)應(yīng)該提供的功能或服務(wù)，通常涉及用戶或外部系統(tǒng)與該系統(tǒng)之間的交互，一般不考慮系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)。舉例：MiniLibrary–用戶可以從圖書資料庫中查詢或者選擇其中的一個(gè)子集。–系統(tǒng)可以提供適當(dāng)?shù)臑g覽器供用戶閱讀電子文獻(xiàn)。–用戶每次借閱圖書應(yīng)該對(duì)應(yīng)一個(gè)唯一的標(biāo)識(shí)號(hào)，它被記錄到用戶的帳戶上。軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-29非功能需求非功能需求–從各個(gè)角度對(duì)系統(tǒng)的約束和限制，反映了應(yīng)用對(duì)軟件系統(tǒng)質(zhì)量和特性的額外要求，例如響應(yīng)時(shí)間、數(shù)據(jù)精度、可靠性、開發(fā)過程的標(biāo)準(zhǔn)等。舉例：MiniLibrary–系統(tǒng)應(yīng)在20秒之內(nèi)響應(yīng)所有的請(qǐng)求。–系統(tǒng)每周7天、每天24小時(shí)都可以使用。–對(duì)于一個(gè)沒有經(jīng)驗(yàn)的用戶而言，經(jīng)過兩個(gè)小時(shí)的培訓(xùn)就可以使用系統(tǒng)的所有功能。軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-30非功能需求軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-31軟件的6個(gè)質(zhì)量特征[ISO9126]軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-32軟件的非功能性需求可靠性、可用性、有效性、可維護(hù)性、可移植性軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-33用戶的權(quán)利法則（User’sBillofRights）

[Karat1998]用戶總是對(duì)的。如果系統(tǒng)使用有問題，那么系統(tǒng)就是問題所在，而不是用戶。用戶有權(quán)進(jìn)行簡易安裝和卸載軟件和硬件系統(tǒng)，而不會(huì)產(chǎn)生任何負(fù)面的影響。用戶有權(quán)要求系統(tǒng)達(dá)到承諾的性能。用戶有權(quán)獲得易于使用的指導(dǎo)（用戶指南、在線或上下文幫助、出錯(cuò)信息），從而理解和使用系統(tǒng)，達(dá)到既定目標(biāo)，并能從系統(tǒng)發(fā)生的問題中有效地恢復(fù)。用戶有權(quán)控制系統(tǒng)，并且能使系統(tǒng)響應(yīng)其要求。用戶有權(quán)要求系統(tǒng)提供有關(guān)正在進(jìn)行的任務(wù)及進(jìn)展的清晰、準(zhǔn)確而可理解的信息。用戶有權(quán)要求所有有關(guān)正確使用軟件或硬件的系統(tǒng)信息。用戶有權(quán)知道系統(tǒng)的能力限制。用戶有權(quán)與技術(shù)提供商聯(lián)系，并得到合理而有用的幫助。用戶應(yīng)該是軟件和硬件的主人，而不是相反。產(chǎn)品應(yīng)該簡單而直觀，易于使用。軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-34約束約束定義為：對(duì)系統(tǒng)的設(shè)計(jì)或開發(fā)系統(tǒng)過程的限制。它不影響系統(tǒng)的外部行為，但必須被遵守執(zhí)行以符合技術(shù)上、商業(yè)上的要求。約束主要來自于幾個(gè)方面：設(shè)計(jì)選擇的約束、加在開發(fā)過程上的約束以及規(guī)章制度和標(biāo)準(zhǔn)。設(shè)計(jì)選擇的約束是指當(dāng)出現(xiàn)一種以上的設(shè)計(jì)選擇時(shí)，選擇的內(nèi)容帶來的約束。一般情況下，應(yīng)該由設(shè)計(jì)人員，而不是需求分析人員來做選擇。軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-35需求金字塔軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-36需求路線圖：涉眾需要—〉系統(tǒng)的特性—〉建立軟件需求特征（feature）特征（feature）是系統(tǒng)為了完成涉眾的一個(gè)或多個(gè)需要而提供的服務(wù)。特征范例[Leffingwell,2003]應(yīng)用領(lǐng)域特征范例電梯控制系統(tǒng)在發(fā)生火警時(shí)人工控制通道存貨管理系統(tǒng)及時(shí)提供所有存貨的最新狀況缺陷跟蹤系統(tǒng)提供缺陷走勢(shì)數(shù)據(jù)評(píng)估產(chǎn)品質(zhì)量工資管理系統(tǒng)到目前為止的金額分類扣除報(bào)告家用自動(dòng)照明系統(tǒng)長時(shí)間外出的設(shè)置軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-37特征屬性

軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-38思考問題分析以下描述，它們是否屬于需求？–普通讀者必須注冊(cè)成合法用戶才可以使用該系統(tǒng)。–用戶可以預(yù)訂目前借不到的圖書資料。–用戶不希望自己的借閱記錄被他人查閱。–系統(tǒng)通過ADO與圖書資料數(shù)據(jù)庫連接，并從圖書資料數(shù)據(jù)表中獲得圖書資料的基本信息。–系統(tǒng)應(yīng)該具有良好的可擴(kuò)展性。思考：如果所開發(fā)的軟件系統(tǒng)只是簡單地替代現(xiàn)行的手工操作方式，是否可行？為什么？軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-39

就理論而言，理論和實(shí)踐并無差異。但真付諸實(shí)行，差異即開始顯現(xiàn)。

——JanL.A.vandeSnepscheut

軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 2-40第二部分需求工程及其過程需求工程需求工程是應(yīng)用已證實(shí)有效的原理和方法，并通過合適的工具和符號(hào)，系統(tǒng)地描述出待開發(fā)系統(tǒng)及其行為特征和相關(guān)約束。–需求獲取：開發(fā)人員聆聽客戶的需求，觀察用戶的行為；–需求分析：分析和整理所收集的用戶需求；–需求規(guī)格說明：以文檔形式，精確地闡述一個(gè)軟件系統(tǒng)必須提供的功能和性能以及它所要考慮的限制條件；–需求驗(yàn)證：使用評(píng)審和商議等有效手段對(duì)其進(jìn)行驗(yàn)證，最終形成一個(gè)需求基線；–需求管理：在軟件開發(fā)過程中有效地管理和控制需求變更。需求工程與需求工程過程軟件需求與產(chǎn)品生命周期瀑布模型快速應(yīng)用開發(fā)(RAD)模型螺旋模型RUP迭代式模型形式化方法關(guān)于選擇生命周期模型的總結(jié)需求工程什么是需求工程需求工程的內(nèi)容需求工程過程需求工程的涉眾人員需求工程的方法面向?qū)ο蟮男枨蠊こ谭椒嫦驅(qū)ο蟮男枨蠊ぷ髁餍枨筮^程的改進(jìn)軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 2-42第3章主要軟件生命周期模型

瀑布模型快速應(yīng)用開發(fā)模型（RAD）螺旋模型RUP迭代式模型3.1瀑布模型WinstonRoyce在軟件生命周期概念的基礎(chǔ)上，于1970年提出了著名的“瀑布模型”（waterfallmodel）。維護(hù)評(píng)價(jià)3.1瀑布模型瀑布模型中的每一個(gè)開發(fā)活動(dòng)具有下列特征：本活動(dòng)的工作對(duì)象來自于上一項(xiàng)活動(dòng)的輸出，這些輸出一般是代表本階段活動(dòng)結(jié)束的里程碑式的文檔。根據(jù)本階段的活動(dòng)規(guī)程執(zhí)行相應(yīng)的任務(wù)。產(chǎn)生本階段活動(dòng)相關(guān)產(chǎn)出——軟件工件，作為下一活動(dòng)的輸入。對(duì)本階段活動(dòng)執(zhí)行情況進(jìn)行評(píng)審。瀑布模型的優(yōu)點(diǎn)客戶很容易熟悉該模型。以有序的方式解決復(fù)雜的問題，易于理解，目標(biāo)簡單—完成所需要的活動(dòng)。可以嚴(yán)格控制項(xiàng)目進(jìn)程，使項(xiàng)目管理易于實(shí)施。方便按階段設(shè)置里程碑，便于項(xiàng)目跟蹤。定義了質(zhì)量控制過程。運(yùn)用該過程來確定系統(tǒng)的質(zhì)量。瀑布模型的缺點(diǎn)（一）它有內(nèi)在的線性順序，嘗試重新使用兩個(gè)或更多階段開改正一個(gè)問題或缺陷，會(huì)導(dǎo)致成本上升和進(jìn)度安排上工作量的急劇增加。它不能準(zhǔn)確反映軟件開發(fā)中解決問題的特點(diǎn)。各階段嚴(yán)格與活動(dòng)一致，而不管開發(fā)團(tuán)隊(duì)的實(shí)際工作如何。它的狀態(tài)和進(jìn)展容易給人以錯(cuò)覺，實(shí)際工作中“完成50%的工作”對(duì)項(xiàng)目經(jīng)理來說并無實(shí)際意義。最后集成造成較大的風(fēng)險(xiǎn)。由于過程中的線性傳遞特點(diǎn)，常常在集成中出現(xiàn)問題時(shí)就已為時(shí)太晚。最后會(huì)發(fā)現(xiàn)前期未發(fā)現(xiàn)的錯(cuò)誤或設(shè)計(jì)缺陷，由于沒有時(shí)間恢復(fù)而增加了風(fēng)險(xiǎn)。它是文檔驅(qū)動(dòng)的，文檔工作量非常大。當(dāng)瀑布模型必須面對(duì)范圍管理的挑戰(zhàn)時(shí)，就顯得力不從心了。如果把這個(gè)模型應(yīng)用于大范圍的項(xiàng)目時(shí)，會(huì)出現(xiàn)最后期限到來時(shí)，沒有任何實(shí)質(zhì)性的成果，系統(tǒng)集成和測試被迫推遲或放棄，在前期需求規(guī)格說明、設(shè)計(jì)和編碼中可觀的投入未能產(chǎn)生有效的成果，沒有任何可提交的產(chǎn)品。瀑布模型的缺點(diǎn)（二）實(shí)際的項(xiàng)目很少按照該模型給出的順序進(jìn)行。雖然瀑布模型能夠容許迭代，但卻是間接的。結(jié)果，在項(xiàng)目組的開發(fā)過程中變化可能引起混亂。用戶常常難以清楚地給出所有需求，而瀑布模型卻要求如此，它還不能接受在許多項(xiàng)目的開始階段自然存在的不確定性。開發(fā)者常常被不必要地耽擱。在對(duì)實(shí)際項(xiàng)目的分析中，Bradac［BRA,1994］發(fā)現(xiàn)傳統(tǒng)生命周期的線性特征會(huì)導(dǎo)致“阻塞狀態(tài)”，其中某些項(xiàng)目組成員不得不等待組內(nèi)其他成員先完成其依賴的任務(wù)。事實(shí)上，花在等待上的時(shí)間可能會(huì)超過花在開發(fā)工作上的時(shí)間。阻塞狀態(tài)經(jīng)常發(fā)生在線性順序過程的開始和結(jié)束。3.1瀑布模型瀑布模型的優(yōu)缺點(diǎn)優(yōu)點(diǎn)缺點(diǎn)降低了軟件開發(fā)的復(fù)雜程度，而且提高了軟件開發(fā)過程的透明性，提高了軟件開發(fā)過程的可管理性。模型缺乏靈活性，特別是無法解決軟件需求不明確或不準(zhǔn)確的問題。推遲了軟件實(shí)現(xiàn)，強(qiáng)調(diào)在軟件實(shí)現(xiàn)前必須進(jìn)行分析和設(shè)計(jì)工作。模型的風(fēng)險(xiǎn)控制能力較弱。

以項(xiàng)目的階段評(píng)審和文檔控制為手段有效地對(duì)整個(gè)開發(fā)過程進(jìn)行指導(dǎo)，保證了階段之間的正確銜接，能夠及時(shí)發(fā)現(xiàn)并糾正開發(fā)過程中存在的缺陷，從而能夠使產(chǎn)品達(dá)到預(yù)期的質(zhì)量要求。瀑布模型中的軟件活動(dòng)是文檔驅(qū)動(dòng)的，當(dāng)階段之間規(guī)定過多的文檔時(shí)，會(huì)極大地增加系統(tǒng)的工作量；而且當(dāng)管理人員以文檔的完成情況來評(píng)估項(xiàng)目完成進(jìn)度時(shí)，往往會(huì)產(chǎn)生錯(cuò)誤的結(jié)論。采用瀑布模型需要具備的項(xiàng)目特征

在系統(tǒng)開發(fā)前要對(duì)需求有完整、全面、清晰的了解。上述需求不存在隱含的不可克服的風(fēng)險(xiǎn)。需求變更不能過于頻繁。不同涉眾的需求互相兼容，不存在明顯的沖突。開發(fā)團(tuán)隊(duì)掌握了解決需求問題的有效方法。開發(fā)期限允許分階段地串行工作。V模型和W模型1980年代后期PaulRook提出了V模型W模型Evolutif公司在V模型的基礎(chǔ)上提出了W模型3.2快速應(yīng)用開發(fā)模型快速應(yīng)用開發(fā)（RapidApplicationDevelopment，RAD）是一個(gè)增量型的軟件開發(fā)過程模型，強(qiáng)調(diào)極短的開發(fā)周期。快速應(yīng)用開發(fā)(RAD)模型RAD模型的優(yōu)點(diǎn)

采用高效率的開發(fā)工具，從而減少了整個(gè)產(chǎn)品的開發(fā)周期。提高了生產(chǎn)率，降低了成本。用戶能夠持續(xù)地參與開發(fā)，提高了用戶參與程度，從而使用戶的滿意度上升，保證了系統(tǒng)能夠滿足用戶的需要。工作重點(diǎn)從文檔轉(zhuǎn)為構(gòu)建，所見即所得。RAD模型的缺點(diǎn)

如果用戶不能持續(xù)地參與整個(gè)生命周期中，最終產(chǎn)品會(huì)受到負(fù)面影響。要求系統(tǒng)能適當(dāng)模塊化，如果沒有可重用的組件，它的效率就會(huì)下降。盲目應(yīng)用時(shí)，會(huì)缺乏成本概念和項(xiàng)目完成的時(shí)間限制。項(xiàng)目有永遠(yuǎn)不能完結(jié)的風(fēng)險(xiǎn)。對(duì)于大型的、但可伸縮的項(xiàng)目，RAD需要足夠的人力資源以創(chuàng)建足夠的RAD組。RAD要求承擔(dān)必要的快速活動(dòng)的開發(fā)者和用戶在一個(gè)很短的時(shí)間框架下完成一個(gè)系統(tǒng)。如果兩方中的任何一方?jīng)]有完成約定，都會(huì)導(dǎo)致RAD項(xiàng)目失敗。采用RAD模型的項(xiàng)目特征系統(tǒng)可模塊化（基于組件的結(jié)構(gòu)）和可縮放。用戶能參與到整個(gè)生命周期中。項(xiàng)目開發(fā)周期很短通常約60天。項(xiàng)目團(tuán)隊(duì)熟悉問題領(lǐng)域，能熟練使用開發(fā)工具。3.3螺旋模型Boehm于1988年提出，主要針對(duì)大型軟件項(xiàng)目的開發(fā)。大型軟件項(xiàng)目的特點(diǎn)：（1）需求功能復(fù)雜，無法一開始就明確；開發(fā)周期長，中途需求經(jīng)常變化；（2）往往存在諸多風(fēng)險(xiǎn)因素，在不同程度上損害軟件開發(fā)過程和軟件產(chǎn)品的質(zhì)量，所以必須對(duì)風(fēng)險(xiǎn)進(jìn)行管理。螺旋模型最大特點(diǎn)就是引入了明確的風(fēng)險(xiǎn)管理。螺旋模型四個(gè)象限制定計(jì)劃風(fēng)險(xiǎn)分析實(shí)施工程客戶評(píng)價(jià)3.3螺旋模型制定計(jì)劃：確定軟件項(xiàng)目目標(biāo)；明確對(duì)軟件開發(fā)過程和軟件產(chǎn)品的約束；制定詳細(xì)的項(xiàng)目管理計(jì)劃；根據(jù)當(dāng)前的需求和風(fēng)險(xiǎn)因素，制定實(shí)施方案，并進(jìn)行可行性分析，選定一個(gè)實(shí)施方案，并對(duì)其進(jìn)行規(guī)劃。風(fēng)險(xiǎn)分析：明確每一個(gè)項(xiàng)目風(fēng)險(xiǎn)，估計(jì)風(fēng)險(xiǎn)發(fā)生的可能性、頻率、損害程度，并制定風(fēng)險(xiǎn)管理措施規(guī)避這些風(fēng)險(xiǎn)。實(shí)施工程：針對(duì)每一個(gè)開發(fā)階段的任務(wù)要求執(zhí)行本開發(fā)階段的活動(dòng)。客戶評(píng)估：客戶使用原型，反饋修改意見；根據(jù)客戶的反饋，對(duì)產(chǎn)品及其開發(fā)過程進(jìn)行評(píng)審，決定是否進(jìn)入螺旋線的下一個(gè)回路。

螺旋模型的優(yōu)點(diǎn)能夠及時(shí)找到項(xiàng)目存在的風(fēng)險(xiǎn)，避免因?yàn)榭朔涣说睦щy而造成大的損失。使用戶能夠盡早將信息經(jīng)常反饋給開發(fā)人員，保證了產(chǎn)品的正確性和高質(zhì)量。可以方便地評(píng)估和驗(yàn)證每次迭代的成果；實(shí)現(xiàn)從開發(fā)到維護(hù)的無縫連接。螺旋模型的缺點(diǎn)如果項(xiàng)目本身是低風(fēng)險(xiǎn)的或者規(guī)模較小，采用該模型可能產(chǎn)生昂貴的成本。每一次螺旋結(jié)束后評(píng)估風(fēng)險(xiǎn)的時(shí)間及人工耗費(fèi)都較大。模型本身比較復(fù)雜，開發(fā)人員和用戶難于掌握。大量的中間階段會(huì)產(chǎn)生額外的內(nèi)外部文檔。難以定義每階段的目標(biāo)。采用螺旋模型的項(xiàng)目特征適用于大型項(xiàng)目；更適用于內(nèi)部開發(fā)（指沒有外包的開發(fā)內(nèi)容）。用于新功能、新產(chǎn)品或需要采用新技術(shù)時(shí)。收益不確定，項(xiàng)目不能確保成功時(shí)。用戶不能確定其需求或需求很復(fù)雜時(shí)。3.4新型軟件生命周期模型3.4RUP3.5迭代式模型3.6敏捷模型3.7形式化方法統(tǒng)一軟件過程RUPRUP（RationalUnifiedProcess）統(tǒng)一過程模型是由Rational公司（現(xiàn)被IBM公司收購）開發(fā)的一種軟件工程過程框架，是一個(gè)面向?qū)ο蟮幕趙eb的程序開發(fā)方法論。RUP既是一種軟件生命周期模型，又是一種支持面向?qū)ο筌浖_發(fā)的工具，它將軟件開發(fā)過程要素和軟件工件要素整合在統(tǒng)一的框架中。?2009

BUPTTSEG北京郵電大學(xué)通信軟件工程中心3.4RUPRUP的基本結(jié)構(gòu)RUP的核心概念3.4RUPRUP中的軟件生命周期在時(shí)間上被分解為四個(gè)順序的階段：初始階段（Inception）、細(xì)化階段（Elaboration）、構(gòu)造階段（Construction）和交付階段（Transition）。每個(gè)階段結(jié)束于一個(gè)主要的里程碑(MajorMilestones)，并在階段結(jié)尾執(zhí)行一次評(píng)估以確定這個(gè)階段的目標(biāo)是否已經(jīng)滿足。如果評(píng)估結(jié)果令人滿意的話，可以允許項(xiàng)目進(jìn)入下一個(gè)階段。RUPRUP的9個(gè)核心工作流6個(gè)核心過程工作流商業(yè)建模（BusinessModeling）需求（Requirements）分析和設(shè)計(jì)（Analysis&Design）實(shí)現(xiàn)（Implementation）測試（Test）部署（Deployment）RUP3個(gè)核心支持工作流：配置和變更管理（Configuration&ChangeManagement）項(xiàng)目管理（ProjectManagement）環(huán)境（Environment）RUP初始階段目標(biāo)是為系統(tǒng)建立商業(yè)案例（businesscase）并確定項(xiàng)目的邊界。商業(yè)案例包括項(xiàng)目的驗(yàn)收規(guī)范、風(fēng)險(xiǎn)評(píng)估、所需資源估計(jì)、階段計(jì)劃等。要確定項(xiàng)目邊界，需識(shí)別所有與系統(tǒng)交互的外部實(shí)體，并在較高層次上定義外部實(shí)體與系統(tǒng)交互的特性，主要包括識(shí)別外部角色（actor）、識(shí)別所有用例并詳細(xì)描述一些重要的用例。階段結(jié)束里程碑：生命周期目標(biāo)（LifecycleObjective）里程碑，包括一些重要的文檔，如：項(xiàng)目構(gòu)想（vision）、原始用例模型、原始業(yè)務(wù)風(fēng)險(xiǎn)評(píng)估、一個(gè)或者多個(gè)原型、原始商業(yè)案例等。需要對(duì)這些文檔進(jìn)行評(píng)審，以確定正確理解用例需求、項(xiàng)目風(fēng)險(xiǎn)評(píng)估合理、階段計(jì)劃可行等。RUP細(xì)化階段目標(biāo)是分析問題領(lǐng)域，建立健全的體系結(jié)構(gòu)基礎(chǔ)，編制項(xiàng)目計(jì)劃，完成項(xiàng)目中高風(fēng)險(xiǎn)需求部分的開發(fā)。里程碑：生命周期體系結(jié)構(gòu)（LifecycleArchitecture）里程碑。包括風(fēng)險(xiǎn)分析文檔、軟件體系結(jié)構(gòu)基線、項(xiàng)目計(jì)劃、可執(zhí)行的進(jìn)化原型、初始版本的用戶手冊(cè)等。通過評(píng)審確定軟件體系結(jié)構(gòu)已經(jīng)穩(wěn)定、高風(fēng)險(xiǎn)的業(yè)務(wù)需求和技術(shù)機(jī)制已經(jīng)解決、修訂的項(xiàng)目計(jì)劃可行等。RUP構(gòu)造階段將所有剩余的技術(shù)構(gòu)件和穩(wěn)定業(yè)務(wù)需求功能開發(fā)出來，并集成為產(chǎn)品，所有功能被詳細(xì)測試。從某種意義上說，構(gòu)造階段只是一個(gè)制造過程，其重點(diǎn)放在管理資源及控制開發(fā)過程以優(yōu)化成本、進(jìn)度和質(zhì)量。里程碑：初始運(yùn)行能力（InitialOperationalCapability）里程碑。包括可以運(yùn)行的軟件產(chǎn)品、用戶手冊(cè)等，它決定了產(chǎn)品是否可以在測試環(huán)境中進(jìn)行部署。此刻，要確定軟件、環(huán)境、用戶是否可以開始系統(tǒng)的運(yùn)行。RUP移交階段移交階段的重點(diǎn)是確保軟件對(duì)最終用戶是可用的。交付階段可以跨越幾次迭代，包括為發(fā)布做準(zhǔn)備的產(chǎn)品測試，基于用戶反饋的少量調(diào)整。里程碑：產(chǎn)品發(fā)布(ProductRelease)里程碑。此時(shí)，要確定最終目標(biāo)是否實(shí)現(xiàn)，是否應(yīng)該開始產(chǎn)品下一個(gè)版本的另一個(gè)開發(fā)周期。在一些情況下這個(gè)里程碑可能與下一個(gè)周期的初始階段的相重合。RUPRUP的迭代增量開發(fā)思想RUP是融合了噴泉模型和增量模型的一種綜合生命周期模型。每一次迭代就是為了完成一定階段性小目標(biāo)而從事的一系列開發(fā)活動(dòng)。RUPRUP通過迭代增量建模思想提高了風(fēng)險(xiǎn)控制能力，這體現(xiàn)在：⑴迭代計(jì)劃安排是風(fēng)險(xiǎn)驅(qū)動(dòng)的，高風(fēng)險(xiǎn)因素集中在前兩個(gè)階段解決，特別是體系結(jié)構(gòu)級(jí)的風(fēng)險(xiǎn)在細(xì)化階段就得到了解決，及早降低了系統(tǒng)風(fēng)險(xiǎn)；⑵每一次迭代都包括需求、設(shè)計(jì)、實(shí)施、部署和測試活動(dòng)，因此，每一個(gè)中間產(chǎn)品都得到了集成測試，而且這個(gè)集成測試是在一個(gè)統(tǒng)一的軟件體系結(jié)構(gòu)指導(dǎo)下完成的；RUP⑶每一個(gè)階段結(jié)束時(shí)還有嚴(yán)格的質(zhì)量評(píng)審，保證里程碑文檔的質(zhì)量；⑷由于中間版本的產(chǎn)品是逐步產(chǎn)生的，而且核心功能和性能需求已經(jīng)包含在前面的版本中，所以，可以根據(jù)市場競爭的情況適時(shí)推出中間版本，降低市場風(fēng)險(xiǎn)。RUPRUP的最佳實(shí)踐：⑴短時(shí)間分區(qū)式的迭代：2～6周，不鼓勵(lì)時(shí)間推遲；⑵適應(yīng)性開發(fā)：小步驟、快速反饋和調(diào)整；⑶在早期迭代中解決高技術(shù)風(fēng)險(xiǎn)和高業(yè)務(wù)價(jià)值的問題；⑷不斷地讓用戶參與迭代結(jié)果的評(píng)估，并及時(shí)獲取反饋信息，以逐步闡明問題并引導(dǎo)項(xiàng)目進(jìn)展；⑸在早期迭代中建立內(nèi)聚的核心架構(gòu)。?2009

BUPTTSEG北京郵電大學(xué)通信軟件工程中心RUP⑹不斷地驗(yàn)證質(zhì)量；盡早、經(jīng)常和實(shí)際地測試；⑺使用用例驅(qū)動(dòng)軟件建模：用例是獲取需求、制定計(jì)劃、進(jìn)行設(shè)計(jì)、測試、編寫終端用戶文檔的驅(qū)動(dòng)力量。⑻可視化軟件建模：使用UML（UnifiedModelingLanguage，統(tǒng)一建模語言）進(jìn)行軟件建模。⑼仔細(xì)地管理需求：不要草率地對(duì)待需求，而要有機(jī)地進(jìn)行需求的提出、記錄、等級(jí)劃分、追蹤。拙劣的需求管理是項(xiàng)目陷入麻煩的一個(gè)常見原因。⑽實(shí)行變更請(qǐng)求和配置管理。RUPRUP是一個(gè)通用的過程模板，包含了很多開發(fā)指南、工件、開發(fā)過程所涉及到的角色說明等，因此，具體開發(fā)機(jī)構(gòu)在應(yīng)用RUP開發(fā)項(xiàng)目時(shí)要做裁剪。RUP裁剪可以分為以下幾步：⑴確定本項(xiàng)目需要的工作流。⑵確定每個(gè)工作流需要的工件。⑶確定4個(gè)階段之間的演進(jìn)計(jì)劃。以風(fēng)險(xiǎn)控制為原則，決定每個(gè)階段實(shí)施的工作流，每個(gè)工作流的執(zhí)行程度，生成的工件及其完成程度等。⑷確定每個(gè)階段內(nèi)的迭代計(jì)劃。規(guī)劃RUP的4個(gè)階段中每次迭代開發(fā)的內(nèi)容。⑸規(guī)劃工作流內(nèi)部結(jié)構(gòu)。用活動(dòng)圖（activitydiagram）規(guī)劃工作流中涉及的角色、角色負(fù)責(zé)的活動(dòng)及產(chǎn)出的工件。RUP的迭代開發(fā)模式多次迭代RUP的優(yōu)點(diǎn)降低了在一個(gè)增量上的開支風(fēng)險(xiǎn)。如果開發(fā)人員重復(fù)某個(gè)迭代，那么損失只是這一個(gè)開發(fā)有誤的迭代的花費(fèi)。降低了產(chǎn)品無法按照既定進(jìn)度進(jìn)入市場的風(fēng)險(xiǎn)。通過在開發(fā)早期就確定風(fēng)險(xiǎn)，可以盡早來解決而不至于在開發(fā)后期匆匆忙忙。加快了整個(gè)開發(fā)工作的進(jìn)度。因?yàn)殚_發(fā)人員清楚問題的焦點(diǎn)所在，他們的工作會(huì)更有效率。由于用戶的需求并不能在一開始就作出完全的界定，它們通常是在后續(xù)階段中不斷細(xì)化的。因此，迭代過程這種模式使適應(yīng)需求的變化會(huì)更容易些。RUP的缺點(diǎn)RUP只是一個(gè)開發(fā)過程，并沒有涵蓋軟件過程的全部內(nèi)容，例如它缺少關(guān)于軟件運(yùn)行和支持等方面的內(nèi)容它沒有支持多項(xiàng)目的開發(fā)結(jié)構(gòu)，這在一定程度上降低了在開發(fā)組織內(nèi)大范圍實(shí)現(xiàn)重用的可能性。

3.5迭代式模型在迭代的方法中，生命周期的階段與各階段的活動(dòng)是分離開來的，即允許我們?cè)陧?xiàng)目的不同迭代中重新進(jìn)行其中的某些活動(dòng)，如需求、設(shè)計(jì)、實(shí)現(xiàn)等。開發(fā)迭代是一次完整地經(jīng)過所有工作流程的過程：（至少包括）需求工作流程、分析設(shè)計(jì)工作流程、實(shí)施工作流程和測試工作流程。實(shí)質(zhì)上，它類似小型的瀑布式項(xiàng)目。迭代模型與瀑布模型的差別迭代方法常見的問題過分詳細(xì)的規(guī)劃項(xiàng)目不收斂輕率地開始設(shè)計(jì)和編碼自掘陷阱忘記新風(fēng)險(xiǎn)不同的小組按自己的進(jìn)度進(jìn)行工作第一次迭代做太多的事情太多的迭代迭代重疊3.6敏捷模型敏捷建模（AgileModeling，AM）是由ScottW.Ambler從許多的軟件開發(fā)過程實(shí)踐中歸納總結(jié)出來的一些敏捷建模價(jià)值觀、原則和實(shí)踐等組成的，它只是一種態(tài)度，不是一個(gè)說明性過程。AM是對(duì)已有生命周期模型的補(bǔ)充，它本身不是一個(gè)完整的方法論，在應(yīng)用傳統(tǒng)的生命周期模型時(shí)可以借鑒AM的過程指導(dǎo)思想。敏捷模型敏捷建模的價(jià)值觀：個(gè)人和交互勝過過程和工具；實(shí)用的軟件勝過面面俱到的文檔；客戶合作勝過合同談判；響應(yīng)變化勝過遵循計(jì)劃。溝通、簡單、反饋、勇氣、謙遜敏捷模型敏捷建模原則：(1)優(yōu)先考慮的是通過盡早地和不斷地提交有價(jià)值的軟件使客戶滿意；(2)即使到了開發(fā)的后期，也歡迎改變需求；(3)敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢(shì)；(4)經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個(gè)星期到幾個(gè)月，交付的時(shí)間間隔越短越好；(5)圍繞被激勵(lì)起來的個(gè)體來構(gòu)建項(xiàng)目；(6)給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作；敏捷模型(7)在團(tuán)隊(duì)內(nèi)部，最具有效果并富有效率的傳遞信息的方法，就是面對(duì)面的交談；工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)；敏捷過程提倡可持續(xù)的開發(fā)速度；(8)責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個(gè)長期的、恒定的開發(fā)速度；(9)不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會(huì)增強(qiáng)敏捷能力；(10)簡單是最根本的；(11)最好的構(gòu)架、需求和設(shè)計(jì)出于自組織團(tuán)隊(duì)；(12)每隔一定時(shí)間，團(tuán)隊(duì)會(huì)在如何才能更有效地工作方面進(jìn)行反省，對(duì)自己的行為進(jìn)行調(diào)整。敏捷模型敏捷建模核心實(shí)踐項(xiàng)目干系人的積極參與正確使用工件集體所有制測試性思維并行創(chuàng)建模型創(chuàng)建簡單的內(nèi)容簡單地建模公開展示模型

切換到另外的工件

小增量建模

和他人一起建模

用代碼驗(yàn)證

使用最簡單的工具

敏捷模型敏捷模型補(bǔ)充實(shí)踐：使用建模標(biāo)準(zhǔn)逐漸應(yīng)用模式（pattern）丟棄臨時(shí)模型合同模型要正式為外部交流建模為幫助理解建模重用現(xiàn)有的資源不到萬不得已不更新模型3.7形式化方法形式化方法模型包含了一組活動(dòng)，它們帶來了計(jì)算機(jī)軟件用數(shù)學(xué)說明描述的方法。形式化方法使得軟件工程師能夠通過采用一個(gè)嚴(yán)格的、數(shù)學(xué)的表示體系來說明、開發(fā)和驗(yàn)證基于計(jì)算機(jī)的系統(tǒng)。支配形式化方法的基本概念是：數(shù)據(jù)不變式?！獋€(gè)條件表達(dá)式，它在包含一組數(shù)據(jù)的系統(tǒng)的執(zhí)行過程中總保持為真；狀態(tài)。系統(tǒng)訪問和修改的存儲(chǔ)數(shù)據(jù)；操作。系統(tǒng)中發(fā)生的動(dòng)作，以及對(duì)狀態(tài)數(shù)據(jù)的讀或?qū)?。每一個(gè)操作是和兩個(gè)條件相關(guān)聯(lián)的：前置條件和后置條件。離散數(shù)學(xué)。與集合和構(gòu)造性規(guī)約、集合運(yùn)算符、邏輯運(yùn)算符、以及序列相關(guān)聯(lián)的符號(hào)體系，形成了形式化方法的基礎(chǔ)。這些數(shù)學(xué)在形式化規(guī)約語言，如Z語言中被實(shí)現(xiàn)。形式化方法的優(yōu)點(diǎn)形式化規(guī)約可以用數(shù)學(xué)方法研究，而非形式化方法則不能。某些形式的不完整性和不一致性可以被自動(dòng)地檢測。形式化方法提供了規(guī)約環(huán)境的基礎(chǔ)，它使得所生成的分析模型比用傳統(tǒng)的或面向?qū)ο蟮姆椒ㄉ傻哪Ｐ透暾?、一致和無二義。集合論和邏輯符號(hào)的描述使得軟件工程師能創(chuàng)建清晰的關(guān)于事實(shí)(需求)的陳述。形式化方法的缺點(diǎn)形式化規(guī)約主要關(guān)注于功能和數(shù)據(jù)，而問題的時(shí)序、控制和行為等方面卻更難于表示。使用形式化方法來建立規(guī)約比其他分析方法更難于學(xué)習(xí)。形式化模型的開發(fā)目前還很費(fèi)時(shí)和昂貴。因?yàn)楹苌儆熊浖_發(fā)者具有使用形式化方法所需的背景知識(shí)，所以尚需多方面的培訓(xùn)。難以使用該模型與用戶進(jìn)行交流溝通，因?yàn)閹缀跛械挠脩魧?duì)其一無所知。?2009

BUPTTSEG北京郵電大學(xué)通信軟件工程中心軟件文檔需求工程需求工程是應(yīng)用已證實(shí)有效的原理和方法，并通過合適的工具和符號(hào)，系統(tǒng)地描述出待開發(fā)系統(tǒng)及其行為特征和相關(guān)約束。–需求獲?。洪_發(fā)人員聆聽客戶的需求，觀察用戶的行為；–需求分析：分析和整理所收集的用戶需求；–需求規(guī)格說明：以文檔形式，精確地闡述一個(gè)軟件系統(tǒng)必須提供的功能和性能以及它所要考慮的限制條件；–需求驗(yàn)證：使用評(píng)審和商議等有效手段對(duì)其進(jìn)行驗(yàn)證，最終形成一個(gè)需求基線；–需求管理：在軟件開發(fā)過程中有效地管理和控制需求變更。第4章需求工程完整的軟件需求工程包括需求開發(fā)和需求管理兩個(gè)部分，需求開發(fā)的一般過程分為需求獲取、需求建模、需求規(guī)格說明、需求驗(yàn)證四個(gè)階段，需求管理則主要包括需求基線的建立、需求變更控制以及需求跟蹤等活動(dòng)。需求工程過程被認(rèn)為是建立軟件系統(tǒng)最重要的方面之一。在項(xiàng)目中，它涵蓋了與需求相關(guān)的所用活動(dòng)。需求工程的涉眾。需求工程方法大致分為四類：面向過程、面向數(shù)據(jù)、面向控制、面向?qū)ο?。面向?qū)ο蟮男枨蠊ぷ髁靼ǎ簡栴}分析，理解涉眾需要，定義系統(tǒng)，管理項(xiàng)目規(guī)模，改進(jìn)系統(tǒng)定義。軟件需求過程的改進(jìn)具有以下兩個(gè)主要目標(biāo)：解決在以前項(xiàng)目或目前項(xiàng)目中遇到的問題；防止和避免你可能在將來的項(xiàng)目中要遇到的問題。需求過程改進(jìn)路線圖。需求工程的內(nèi)容軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-100需求工程及其過程軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-101軟件需求華東師范大學(xué)軟件學(xué)院2007? 2-102Pressman的需求工程過程Boehm的需求工程過程

從需求管理角度出發(fā)，為需求確定好優(yōu)先次序，為需求準(zhǔn)備好規(guī)范的活動(dòng)。需求工程的涉眾人員廣義：需求的來源客戶或用戶–學(xué)院的高層管理者、項(xiàng)目投資人–系統(tǒng)管理員–教師、學(xué)生、圖書管理員.標(biāo)準(zhǔn)、政策或法律–圖書資料的標(biāo)準(zhǔn)–圖書資料管理規(guī)程、知識(shí)產(chǎn)權(quán)和版權(quán)保護(hù)等.系統(tǒng)或過程文檔–當(dāng)前手工管理的文件、表格、記錄等.相關(guān)領(lǐng)域的專家軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-105軟件需求工程太原理工大學(xué)軟件學(xué)院2015? 1-106需求工程的方法面向過程主要研究系統(tǒng)輸入輸出的轉(zhuǎn)化，如SA，SADT面向數(shù)據(jù)強(qiáng)調(diào)數(shù)據(jù)結(jié)構(gòu)的描述，如E-R圖面向控制強(qiáng)調(diào)同步死鎖互斥等，典型如DFD。面向?qū)ο笠韵到y(tǒng)對(duì)象及其交互為基礎(chǔ)，通過相關(guān)對(duì)對(duì)象的屬性、分類和集合機(jī)構(gòu)來定義和溝通需求。面向?qū)ο蟮男枨蠊こ谭椒ㄅc用戶廣泛接觸，收集和查看相關(guān)資料，對(duì)問題域有一個(gè)大致的了解。在此基礎(chǔ)上，提煉和標(biāo)識(shí)對(duì)象。描述對(duì)象（類）的屬性。描述對(duì)象之間的關(guān)系，如整體關(guān)系和從屬關(guān)系等。描述問題域的“場景”，即描述問題域中完成每個(gè)任務(wù)需要的對(duì)象間的協(xié)作關(guān)系。面向?qū)ο蟮男枨蠊ぷ髁餍枨筮^程的改進(jìn)把理論方法付諸實(shí)踐是改進(jìn)軟件過程的核心所在。從根本上說，改進(jìn)過程包括使用更多有效的方法避免使用過去使用過的令人頭痛的方法。然而，改進(jìn)之路卻是從失敗、錯(cuò)誤開始，還要?dú)v經(jīng)諸如受人為抵制的影響及因任務(wù)的時(shí)間緊迫導(dǎo)致改進(jìn)被擱置這樣的挫折。解決在以前項(xiàng)目或目前項(xiàng)目中遇到的問題防止和避免你可能在將來的項(xiàng)目中要遇到的問題如果目前采用的方法好像也挺有效的，你可能覺得沒有必要改變方法。但是，即便是很成功的軟件組織在面臨大項(xiàng)目、不同的客戶群、緊迫的進(jìn)度安排或全新的應(yīng)用領(lǐng)域時(shí)也會(huì)感到力不從心。因此，至少應(yīng)該知道其它一些很有價(jià)值也頗有效的需求工程方法，并把它們加入到軟件工程中。需求與其他項(xiàng)目過程的聯(lián)系需求是軟件項(xiàng)目成功的核心所在，它為其他許多技術(shù)、管理活動(dòng)奠定了基礎(chǔ)。變更你的需求開發(fā)和管理方法將對(duì)其他項(xiàng)目過程產(chǎn)生影響，反之亦然。1)制定項(xiàng)目計(jì)劃需求是制定項(xiàng)目計(jì)劃的基礎(chǔ)。因?yàn)殚_發(fā)資源和進(jìn)度安排的估計(jì)都要建立在對(duì)最終產(chǎn)品的真正理解之上。通常，項(xiàng)目計(jì)劃指出所有希望的特性不可能在允許的資源和時(shí)間內(nèi)完成，因此，需要縮小項(xiàng)目范圍或采用版本計(jì)劃對(duì)功能特性進(jìn)行選擇。2)項(xiàng)目跟蹤和控制監(jiān)控每項(xiàng)需求的狀態(tài)，以便項(xiàng)目管理者能發(fā)現(xiàn)設(shè)計(jì)和驗(yàn)證是否達(dá)到預(yù)期的要求。如果沒有達(dá)到，管理者通常請(qǐng)求變更控制過程來進(jìn)行范圍的縮減。3)變更控制在需求編寫成文檔并制定基線以后，所有接下來的變更都應(yīng)通過確定的變更控制過程來進(jìn)