軟件需求-一二部分

軟件需求工程太原理工大學計算機學院張澤華

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

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

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

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

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

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

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

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

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

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

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

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

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

——JanL.A.vandeSnepscheut

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

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

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

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

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

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

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

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

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

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

切換到另外的工件

小增量建模

和他人一起建模

用代碼驗證

使用最簡單的工具

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

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

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