1、軟件需求（二）,周勇 ,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-2,就理論而言，理論和實踐并無差異。但真付諸實行，差異即開始顯現(xiàn)。 Jan L.A. van de Snepscheut,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-3,需求工程與需求工程過程,軟件需求與產(chǎn)品生命周期 瀑布模型 快速應用開發(fā)(RAD) 模型 螺旋模型 RUP 迭代式模型 形式化方法 關于選擇生命周期模型的總結 需求工程 什么是需求工程 需求工程的內容 需求工程過程 需求工程的涉眾人員 需求工程的方法 面向對象的需求工程方法 面向對象的需求工作流 需求過程的改進,200

2、7年7月 SEI of ECNU版權所有 軟件需求工程 2-4,第3章 主要軟件生命周期模型,瀑布模型 快速應用開發(fā)模型（RAD） 螺旋模型 RUP 迭代式模型,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-5,瀑布模型（Waterfall Model）,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-6,瀑布模型的優(yōu)點,客戶很容易熟悉該模型。 以有序的方式解決復雜的問題，易于理解，目標簡單完成所需要的活動。 可以嚴格控制項目進程，使項目管理易于實施。 方便按階段設置里程碑，便于項目跟蹤。 定義了質量控制過程。運用該過程來確定系統(tǒng)的質量。,2007年7月

3、SEI of ECNU版權所有 軟件需求工程 2-7,瀑布模型的缺點 （一）,它有內在的線性順序，嘗試重新使用兩個或更多階段開改正一個問題或缺陷，會導致成本上升和進度安排上工作量的急劇增加。 它不能準確反映軟件開發(fā)中解決問題的特點。各階段嚴格與活動一致，而不管開發(fā)團隊的實際工作如何。 它的狀態(tài)和進展容易給人以錯覺，實際工作中“完成50%的工作”對項目經(jīng)理來說并無實際意義。 最后集成造成較大的風險。由于過程中的線性傳遞特點，常常在集成中出現(xiàn)問題時就已為時太晚。最后會發(fā)現(xiàn)前期未發(fā)現(xiàn)的錯誤或設計缺陷，由于沒有時間恢復而增加了風險。 它是文檔驅動的，文檔工作量非常大。 當瀑布模型必須面對范圍管理的挑戰(zhàn)

4、時，就顯得力不從心了。如果把這個模型應用于大范圍的項目時，會出現(xiàn)最后期限到來時，沒有任何實質性的成果，系統(tǒng)集成和測試被迫推遲或放棄，在前期需求規(guī)格說明、設計和編碼中可觀的投入未能產(chǎn)生有效的成果，沒有任何可提交的產(chǎn)品。,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-8,瀑布模型的缺點 （二）,實際的項目很少按照該模型給出的順序進行。雖然瀑布模型能夠容許迭代，但卻是間接的。結果，在項目組的開發(fā)過程中變化可能引起混亂。 用戶常常難以清楚地給出所有需求，而瀑布模型卻要求如此，它還不能接受在許多項目的開始階段自然存在的不確定性。 開發(fā)者常常被不必要地耽擱。在對實際項目的分析中，Bra

5、dacBRA ,1994發(fā)現(xiàn)傳統(tǒng)生命周期的線性特征會導致“阻塞狀態(tài)”，其中某些項目組成員不得不等待組內其他成員先完成其依賴的任務。事實上，花在等待上的時間可能會超過花在開發(fā)工作上的時間。阻塞狀態(tài)經(jīng)常發(fā)生在線性順序過程的開始和結束。,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-9,采用瀑布模型需要具備的項目特征,在系統(tǒng)開發(fā)前要對需求有完整、全面、清晰的了解。 上述需求不存在隱含的不可克服的風險。 需求變更不能過于頻繁。 不同涉眾的需求互相兼容，不存在明顯的沖突。 開發(fā)團隊掌握了解決需求問題的有效方法。 開發(fā)期限允許分階段地串行工作。,2007年7月 SEI of ECNU版

6、權所有 軟件需求工程 2-10,快速應用開發(fā)(RAD) 模型,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-11,RAD模型的優(yōu)點,采用高效率的開發(fā)工具，從而減少了整個產(chǎn)品的開發(fā)周期。提高了生產(chǎn)率，降低了成本。 用戶能夠持續(xù)地參與開發(fā)，提高了用戶參與程度，從而使用戶的滿意度上升，保證了系統(tǒng)能夠滿足用戶的需要。 工作重點從文檔轉為構建，所見即所得 。,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-12,RAD模型的缺點,如果用戶不能持續(xù)地參與整個生命周期中，最終產(chǎn)品會受到負面影響。 要求系統(tǒng)能適當模塊化，如果沒有可重用的組件，它的效率就會下降。 盲目應用時

7、，會缺乏成本概念和項目完成的時間限制。項目有永遠不能完結的風險。 對于大型的、但可伸縮的項目，RAD 需要足夠的人力資源以創(chuàng)建足夠的RAD 組。 RAD 要求承擔必要的快速活動的開發(fā)者和用戶在一個很短的時間框架下完成一個系統(tǒng)。如果兩方中的任何一方?jīng)]有完成約定，都會導致RAD 項目失敗。,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-13,采用RAD模型的項目特征,系統(tǒng)可模塊化（基于組件的結構）和可縮放。 用戶能參與到整個生命周期中。 項目開發(fā)周期很短通常約60天。 項目團隊熟悉問題領域，能熟練使用開發(fā)工具。,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-

8、14,螺旋模型,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-15,螺旋模型的優(yōu)點,能夠及時找到項目存在的風險，避免因為克服不了的困難而造成大的損失。 使用戶能夠盡早將信息經(jīng)常反饋給開發(fā)人員，保證了產(chǎn)品的正確性和高質量。 可以方便地評估和驗證每次迭代的成果；實現(xiàn)從開發(fā)到維護的無縫連接。,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-16,螺旋模型的缺點,如果項目本身是低風險的或者規(guī)模較小，采用該模型可能產(chǎn)生昂貴的成本。每一次螺旋結束后評估風險的時間及人工耗費都較大。 模型本身比較復雜，開發(fā)人員和用戶難于掌握。 大量的中間階段會產(chǎn)生額外的內外部文檔。 難以

9、定義每階段的目標。,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-17,采用螺旋模型的項目特征,適用于大型項目；更適用于內部開發(fā)（指沒有外包的開發(fā)內容）。 用于新功能、新產(chǎn)品或需要采用新技術時。 收益不確定，項目不能確保成功時。 用戶不能確定其需求或需求很復雜時。,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-18,統(tǒng)一軟件過程 （RUP）,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-19,RUP的核心概念,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-20,RUP的核心工作流（一）,6個核心過程工作流 商業(yè)建模

10、（Business Modeling ） 需求（Requirements） 分析和設計（Analysis & Design） 實現(xiàn)(Implementation) 測試（Test） 部署（Deployment）,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-21,RUP的核心工作流（二）,3個核心支持工作流 配置和變更管理（Configuration & Change Management） 項目管理（Project Management） 環(huán)境（Environment）,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-22,RUP的裁剪,確定本項目需要哪

11、些工作流。RUP的9個核心工作流并不總是需要的，可以取舍。 確定每個工作流需要哪些制品。 確定4個階段之間如何演進。確定階段間演進要以風險控制為原則，決定每個階段要那些工作流，每個工作流執(zhí)行到什么程度，制品有那些，每個制品完成到什么程度。 確定每個階段內的迭代計劃。規(guī)劃RUP的4個階段中每次迭代開發(fā)的內容。 規(guī)劃工作流內部結構。工作流涉及角色、活動及制品，它的復雜程度與項目規(guī)模即角色多少有關。最后規(guī)劃工作流的內部結構，通常用活動圖的形式給出。,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-23,RUP的迭代開發(fā)模式,2007年7月 SEI of ECNU版權所有 軟件需求工

12、程 2-24,多次迭代,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-25,RUP的優(yōu)點,降低了在一個增量上的開支風險。如果開發(fā)人員重復某個迭代，那么損失只是這一個開發(fā)有誤的迭代的花費。 降低了產(chǎn)品無法按照既定進度進入市場的風險。通過在開發(fā)早期就確定風險，可以盡早來解決而不至于在開發(fā)后期匆匆忙忙。 加快了整個開發(fā)工作的進度。因為開發(fā)人員清楚問題的焦點所在，他們的工作會更有效率。 由于用戶的需求并不能在一開始就作出完全的界定，它們通常是在后續(xù)階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-

13、26,RUP的缺點,RUP只是一個開發(fā)過程，并沒有涵蓋軟件過程的全部內容，例如它缺少關于軟件運行和支持等方面的內容 它沒有支持多項目的開發(fā)結構，這在一定程度上降低了在開發(fā)組織內大范圍實現(xiàn)重用的可能性。,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-27,迭代式模型,在迭代的方法中，生命周期的階段與各階段的活動是分離開來的，即允許我們在項目的不同迭代中重新進行其中的某些活動，如需求、設計、實現(xiàn)等 。 開發(fā)迭代是一次完整地經(jīng)過所有工作流程的過程：（至少包括）需求工作流程、分析設計工作流程、實施工作流程和測試工作流程。實質上，它類似小型的瀑布式項目。,2007年7月 SEI of

14、 ECNU版權所有 軟件需求工程 2-28,迭代模型與瀑布模型的差別,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-29,迭代方法常見的問題,過分詳細的規(guī)劃 項目不收斂 輕率地開始設計和編碼 自掘陷阱 忘記新風險 不同的小組按自己的進度進行工作 第一次迭代做太多的事情 太多的迭代 迭代重疊,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-30,形式化方法,形式化方法模型包含了一組活動，它們帶來了計算機軟件用數(shù)學說明描述的方法。形式化方法使得軟件工程師能夠通過采用一個嚴格的、數(shù)學的表示體系來說明、開發(fā)和驗證基于計算機的系統(tǒng)。 支配形式化方法的基本概念是： 數(shù)

15、據(jù)不變式。個條件表達式，它在包含一組數(shù)據(jù)的系統(tǒng)的執(zhí)行過程中總保持為真； 狀態(tài)。系統(tǒng)訪問和修改的存儲數(shù)據(jù)； 操作。系統(tǒng)中發(fā)生的動作，以及對狀態(tài)數(shù)據(jù)的讀或寫。每一個操作是和兩個條件相關聯(lián)的：前置條件和后置條件。 離散數(shù)學。與集合和構造性規(guī)約、集合運算符、邏輯運算符、以及序列相關聯(lián)的符號體系，形成了形式化方法的基礎。這些數(shù)學在形式化規(guī)約語言，如Z 語言中被實現(xiàn)。,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-31,形式化方法的優(yōu)點,形式化規(guī)約可以用數(shù)學方法研究，而非形式化方法則不能。 某些形式的不完整性和不一致性可以被自動地檢測 。 形式化方法提供了規(guī)約環(huán)境的基礎，它使得所生成的

16、分析模型比用傳統(tǒng)的或面向對象的方法生成的模型更完整、一致和無二義。集合論和邏輯符號的描述使得軟件工程師能創(chuàng)建清晰的關于事實(需求)的陳述。,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-32,形式化方法的缺點,形式化規(guī)約主要關注于功能和數(shù)據(jù)，而問題的時序、控制和行為等方面卻更難于表示。 使用形式化方法來建立規(guī)約比其他分析方法更難于學習 。 形式化模型的開發(fā)目前還很費時和昂貴。 因為很少有軟件開發(fā)者具有使用形式化方法所需的背景知識，所以尚需多方面的培訓。 難以使用該模型與用戶進行交流溝通，因為幾乎所有的用戶對其一無所知。,2007年7月 SEI of ECNU版權所有 軟件需

17、求工程 2-33,第4章 需求工程,需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統(tǒng)的所有外部特征的一門學科。 完整的軟件需求工程包括需求開發(fā)和需求管理兩個部分，需求開發(fā)的一般過程分為需求獲取、需求建模、需求規(guī)格說明、需求驗證四個階段，需求管理則主要包括需求基線的建立、需求變更控制以及需求跟蹤等活動。 需求工程過程被認為是建立軟件系統(tǒng)最重要的方面之一。在項目中，它涵蓋了與需求相關的所用活動。 需求工程的涉眾。 需求工程方法大致分為四類：面向過程、面向數(shù)據(jù)、面向控制、面向對象。 面向對象的需求工作流包括：問題分析，理解涉眾需要，定義系統(tǒng)，管理項

18、目規(guī)模，改進系統(tǒng)定義。 軟件需求過程的改進具有以下兩個主要目標：解決在以前項目或目前項目中遇到的問題；防止和避免你可能在將來的項目中要遇到的問題。 需求過程改進路線圖。,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-34,需求工程的內容,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-35,Pressman的需求工程過程,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-36,Boehm的需求工程過程,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-37,需求工程的涉眾人員,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-38,需求工程的方法,面向過程 面向數(shù)據(jù) 面向控制 面向對象,2007年7月 SEI of ECNU版權所有 軟件需求工程 2-39,面向對象的需求工程方法,與用戶廣泛接觸，收集和查看相關資料，對問題域有一個大致的了解。在此基礎上，提煉和標識對象。 描