軟件需求解讀-第二部分(最終版)解讀

1、軟件需求二軟件工程與需求工程軟件工程與軟件開發(fā)過程模型瀑布模型快速原型模型螺旋模型增量模型RUP噴泉模型關(guān)于選擇生命周期模型的總結(jié)需求工程 什么是需求工程需求工程的內(nèi)容需求工程過程需求工程的涉眾人員需求工程的方法面向?qū)ο蟮男枨蠊こ谭椒ǖ?章 軟件工程與軟件開發(fā)過程模型 軟件工程軟件開發(fā)過程模型2022/7/1543.1 軟件工程軟件危機是指人們難以控制軟件的開發(fā)和維護。表現(xiàn)： 1大型軟件系統(tǒng)十分復(fù)雜，很難理解和維護； 2軟件開發(fā)周期過長； 3大型軟件系統(tǒng)的可靠性差； 4軟件費用往往超出預(yù)算。 2022/7/155軟件工程續(xù)軟件危機的解決方法應(yīng)用工程化的方法來進行軟件的開發(fā)和維護 。軟件工程的研

2、究內(nèi)容軟件開發(fā)過程、軟件開發(fā)和維護的方法和技術(shù)、軟件開發(fā)和維護工具系統(tǒng)、質(zhì)量評價和質(zhì)量保證、軟件管理和軟件開發(fā)環(huán)境等。2022/7/1562.2 軟件開發(fā)過程模型軟件生命周期模型瀑布式模型快速原型模型 螺旋式模型 增量模型 RUP(Rational統(tǒng)一過程噴泉模型基于面向?qū)ο蠹夹g(shù) 1瀑布模型Waterfall Model 瀑布模型的優(yōu)點 客戶很容易熟悉該模型。是一種嚴格線性的按階段順序的、逐步細化的開發(fā)模式，消除了軟件開發(fā)的隨意性。各階段工作任務(wù)明確，要求文檔完備性，可方便按階段設(shè)置里程碑，便于工程跟蹤可以嚴格控制工程進程，使工程管理易于實施。定義了質(zhì)量控制過程。運用該過程來確定系統(tǒng)的質(zhì)量。

3、瀑布模型的缺點需求：客戶常常難以表達真正的需求，而這種模型卻要求嚴格的階段性成果，返工困難，變更代價很大風險：客戶要等到開發(fā)周期的晚期才能看到程序運行的測試版本，這時假設(shè)發(fā)現(xiàn)大的錯誤，可能引起客戶的驚慌，其后果也可能是災(zāi)難性的效率：因為前后任務(wù)的依賴關(guān)系，成員不能并行工作，有可能花在等待的時間比開發(fā)的時間要長，即所謂的“堵塞狀態(tài)適用于一些需求已明確并且變化較少的系統(tǒng)2快速原型模型原型快速建立起來的可以在計算機上運行的程序，通常選取系統(tǒng)中某個關(guān)鍵功能作為原型。編程測試分析定義需求設(shè)計原型實施完成再構(gòu)造快速原型的根本思想和開發(fā)步驟根本思想 在投入大量的人力、物力之前，在限定的時間內(nèi)，用最經(jīng)濟的方法

4、構(gòu)造一個系統(tǒng)原型，使用戶盡早看到系統(tǒng)的概貌，在系統(tǒng)原型的實際運行中與用戶一起發(fā)現(xiàn)問題，提出修改意見，不斷完善原型，使它逐步滿足用戶要求。開發(fā)步驟明確用戶根本信息需求建立初始原型集成原那么、最小系統(tǒng)原那么評價原型修改和完善原型快速原型的開發(fā)工具第四代技術(shù)可復(fù)用軟件構(gòu)件形式化規(guī)約和原型環(huán)境快速原型的類型拋棄式原型。將開發(fā)原型看做是溝通工具，永遠也不會將一次式原型引入正式運行環(huán)境中。主要解決需求的不確定性，二義性，不完整性等。進化式原型。會在未來的系統(tǒng)中包含的原型。這種方法能夠?qū)⒆畲罅康墓ぷ魍度氲秸较到y(tǒng)中。水平原型也稱為行為原型，用來探索預(yù)期系統(tǒng)的一些特定行為，并到達細化需求的目的。水平原型通常只

5、是功能導(dǎo)航，并未真實實現(xiàn)功能。主要用在用戶界面上。垂直原型也稱為結(jié)構(gòu)化原型，實現(xiàn)了一局部功能。主要用在復(fù)雜的算法實現(xiàn)上。拋棄式原型模型演化式原型模型是交付目標系統(tǒng)建立/完善原型系統(tǒng)充分嗎？否軟件過程的演化式原型模型使用原型系統(tǒng)需求抽象描述快速原型的典型應(yīng)用快速原型的評價這個原型所實現(xiàn)的功能與你所期望的一致嗎？有遺漏的功能嗎？有多余的功能嗎？你能考慮一下這個原型所沒有涉及到的一些出錯情況嗎？這些功能導(dǎo)航的邏輯性和完整性如何？有更簡單的方法來完成這一任務(wù)嗎？快速原型的特點和應(yīng)用場合用戶積極參與原型的開發(fā)沒有嚴密的階段性短期獲得測試版本，降低風險應(yīng)用于以下場合：需求模糊，用戶不能標識出詳細的輸入、處

6、理和輸出需求設(shè)計方案不明確，開發(fā)人員不能確定算法的有效性、操作系統(tǒng)的適應(yīng)性或人機交互的有效性快速原型的缺乏降低風險的同時，引入了其他風險：用戶隨意無止境的需求變化，因為用戶容易產(chǎn)生誤解，認為系統(tǒng)很容易被構(gòu)造和修改如果采用原型根底上繼續(xù)構(gòu)造，由于修補過度，軟件質(zhì)量不易于保證開發(fā)人員為了快速構(gòu)造原型，可能會采用不適宜的操作系統(tǒng)、語言、算法等，造成后期風險，如系統(tǒng)適應(yīng)性差、維護困難等快速原型開發(fā)的原那么你的工程方案中應(yīng)包括原型風險。方案開發(fā)多個原型，因為你很少能一次成功。盡快并且廉價地建立拋棄型原型。在拋棄型原型中不應(yīng)含有代碼注釋、輸入數(shù)據(jù)有效性檢查、保護性編碼技術(shù)，或者錯誤處理的代碼。對于已經(jīng)理解

7、的需求不要建立原型。不能隨意地增加功能。不要從水平原型的性能推測最終產(chǎn)品的性能。在原型屏幕顯示和報表中使用合理的模擬數(shù)據(jù)。不要期望原型可以代替需求文檔。3螺旋模型是增加了風險分析和躲避措施的“原型 + 瀑布的迭代式開發(fā)模型，由于一系列活動和活動間的回溯過程用螺旋線描述，故而得名。螺旋模型是一種迭代模型，軟件開發(fā)過程定義成不斷上升的螺旋周期，每個周期劃分為方案、風險分析、實施和評價四個方面。沿螺線自內(nèi)向外每旋轉(zhuǎn)一圈便開發(fā)出更為完善的一個新的軟件版本螺旋模型操作概念螺旋模型的優(yōu)點 能夠及時找到工程存在的風險，防止因為克服不了的困難而造成大的損失。使用戶能夠盡早將信息經(jīng)常反響給開發(fā)人員，保證了產(chǎn)品的

8、正確性和高質(zhì)量?？梢苑奖愕卦u估和驗證每次迭代的成果；實現(xiàn)從開發(fā)到維護的無縫連接。 螺旋模型的缺點 如果工程本身是低風險的或者規(guī)模較小，采用該模型可能產(chǎn)生昂貴的本錢。每一次螺旋結(jié)束后評估風險的時間及人工消耗都較大。模型本身比較復(fù)雜，開發(fā)人員和用戶難于掌握。大量的中間階段會產(chǎn)生額外的內(nèi)外部文檔。難以定義每階段的目標。 采用螺旋模型的工程特征 適用于大型工程；更適用于內(nèi)部開發(fā)指沒有外包的開發(fā)內(nèi)容。用于新功能、新產(chǎn)品或需要采用新技術(shù)時。收益不確定，工程不能確保成功時。用戶不能確定其需求或需求很復(fù)雜時。 4增量模型一條直線一次性到達目的總是困難的。緊迫的市場期限使得難以完成一個完善的軟件產(chǎn)品，緩解壓力的

9、方式是先提交一個有限的版本，細節(jié)局部逐步增加。增量模型融合了瀑布模型的根本成分和原型的迭代特征。采用隨著日程時間的進展而交錯的線性序列。搭積木的方式，如按子系統(tǒng)劃分增量增量模型的特點以功能遞增的方式進行軟件開發(fā)能較快地產(chǎn)生可操作的系統(tǒng)在每一步遞增中，都可以把用戶/開發(fā)者的經(jīng)驗結(jié)合到不斷求精的產(chǎn)品中可改善測試效果和降低軟件開發(fā)總本錢分析分析分析分析設(shè)計設(shè)計設(shè)計設(shè)計編碼編碼編碼編碼測試測試測試測試增量1增量2 增量3增量4 功能時間增量模型例如例子：設(shè)計一個字處理軟件增量1：實現(xiàn)軟件的根本需求，提供最核心的功能。增量2：提供更完善的編輯和文檔生成功能。增量3：實現(xiàn)拼寫和語法檢查功能。增量4：完成高

10、級的頁面排版功能。增量模型的應(yīng)用場合工程開始，明確了需求的大局部，但是需求可能會發(fā)生變化對于市場和用戶把握不是很準，需要逐步了解對于有龐大和復(fù)雜功能的系統(tǒng)進行功能改進，本身就需要一步一步實施的。5統(tǒng)一軟件過程 RUP統(tǒng)一軟件過程RUP，Rational Unified Process是基于面向?qū)ο蠼y(tǒng)一建模語言UML的一種面向?qū)ο蟮能浖^程模型。RUP遵循了逐步求精的、迭代的開發(fā)策略。RUP是以用例為驅(qū)動，以系統(tǒng)構(gòu)架為中心的一個迭代式的增量過程。RUP分成初始、細化、構(gòu)造和移交四個階段，每個階段又分成假設(shè)干次迭代，每次迭代都經(jīng)過一個核心工作流程。 統(tǒng)一軟件過程 RUP在統(tǒng)一過程中，有6個核心工作

11、流。 業(yè)務(wù)建模工作流：用商業(yè)用例為商業(yè)過程建立文檔。 需求工作流：目標是描述系統(tǒng)應(yīng)該做什么，確保開發(fā)人員構(gòu)建正確的系統(tǒng)。為此，需明確系統(tǒng)的功能需求和非功能需求約束。 分析和設(shè)計工作流：其目標是說明如何做。結(jié)果是分析模型和設(shè)計模型。 實現(xiàn)工作流：用分層的方式組織代碼的結(jié)構(gòu)，用構(gòu)件的形式來實現(xiàn)類，對構(gòu)件進行單元測試，將構(gòu)件集成到可執(zhí)行的系統(tǒng)中。統(tǒng)一過程的核心工作流 測試工作流：驗證對象之間的交互、是否所有的構(gòu)件都集成了、是否正確實現(xiàn)了所有需求、查錯并改正。 部署工作流：制作軟件的外部版本、軟件打包、分發(fā)、為用戶提供幫助和支持。統(tǒng)一過程的核心工作流續(xù)RUP初始階段的主要工作初始階段：確定所設(shè)立的工程

12、是否可行。明確說明工程規(guī)模，了解環(huán)境以及最重要的需求和約束。劃分主要子系統(tǒng)，給出系統(tǒng)的體系結(jié)構(gòu)概貌?？紤]時間、經(jīng)費、人員、技術(shù)、工程方案和效益等因素。分析工程執(zhí)行的風險。該階段的焦點是需求和分析工作流。RUP細化階段的主要工作細化階段：識別出大多數(shù)用例80%。建立健全的體系結(jié)構(gòu)根底，編制工程方案，細化風險評估。用例模型需要完成80%。創(chuàng)立軟件結(jié)構(gòu)的描述性文檔。創(chuàng)立可執(zhí)行的系統(tǒng)原型。細化風險列表。創(chuàng)立整個工程的開發(fā)方案。該階段的焦點是商業(yè)建模和需求工作流。RUP構(gòu)造階段的主要工作 構(gòu)造階段：識別出最后剩余的用例。每一次迭代開發(fā)都對用例進行分析、設(shè)計、編碼、測試和集成過程，最終得到滿足工程需求的產(chǎn)

13、品。優(yōu)化資源，使開發(fā)本錢降到最低。盡快到達質(zhì)量要求。盡快完成有用的版本。完成所有功能的分析、開發(fā)和測試。迭代式、遞增地開發(fā)隨時可以發(fā)布的產(chǎn)品。確定準備好軟件系統(tǒng)的外部環(huán)境。 該階段的焦點是實現(xiàn)工作流。RUP交付階段的主要工作交付階段：完成最后的軟件產(chǎn)品和產(chǎn)品驗收測試，并編制用戶文檔，進行用戶培訓(xùn)等工作。將完整的系統(tǒng)部署到用戶所處的環(huán)境，確保軟件對最終用戶是可用的。按用戶的要求驗證新系統(tǒng)。替換舊的系統(tǒng)。對用戶和維護人員進行培訓(xùn)。開始調(diào)整工作，例如性能或可用性的增強。與用戶達成共識，部署基線與評估標準一致。該階段的焦點是測試和部署工作流。RUP的迭代開發(fā)模式 屢次迭代 RUP的優(yōu)點 降低了在一個增

14、量上的開支風險。如果開發(fā)人員重復(fù)某個迭代，那么損失只是這一個開發(fā)有誤的迭代的花費。降低了產(chǎn)品無法按照既定進度進入市場的風險。通過在開發(fā)早期就確定風險，可以盡早來解決而不至于在開發(fā)后期匆匆忙忙。 加快了整個開發(fā)工作的進度。因為開發(fā)人員清楚問題的焦點所在，他們的工作會更有效率。由于用戶的需求并不能在一開始就作出完全的界定，它們通常是在后續(xù)階段中不斷細化的。因此，迭代過程這種模式使適應(yīng)需求的變化會更容易些。 RUP的缺點 RUP只是一個開發(fā)過程，并沒有涵蓋軟件過程的全部內(nèi)容，例如它缺少關(guān)于軟件運行和支持等方面的內(nèi)容它沒有支持多工程的開發(fā)結(jié)構(gòu)，這在一定程度上降低了在開發(fā)組織內(nèi)大范圍實現(xiàn)重用的可能性。

15、總結(jié)：迭代式模型 在迭代的方法中，生命周期的階段與各階段的活動是別離開來的，即允許我們在工程的不同迭代中重新進行其中的某些活動，如需求、設(shè)計、實現(xiàn)等 。開發(fā)迭代是一次完整地經(jīng)過所有工作流程的過程：至少包括需求工作流程、分析設(shè)計工作流程、實施工作流程和測試工作流程。實質(zhì)上，它類似小型的瀑布式工程。每次迭代工程都會向前推進一步，產(chǎn)生一個可以發(fā)布的產(chǎn)品。 迭代模型與瀑布模型的差異 迭代方法常見的問題 過分詳細的規(guī)劃 工程不收斂 輕率地開始設(shè)計和編碼 自掘陷阱 忘記新風險 不同的小組按自己的進度進行工作 第一次迭代做太多的事情 太多的迭代 迭代重疊 6噴泉模型噴泉模型：主要用于面向?qū)ο蠹夹g(shù)的軟件開發(fā)工

16、程，它克服了瀑布模型不支持軟件重用和多項開發(fā)活動集成的局限性，噴泉模型使開發(fā)過程具有迭代性和無間隙性。 噴泉模型以面向?qū)ο蟮能浖_發(fā)方法為根底，以用戶需求作為噴泉模型的源泉，屬于面向?qū)ο蟮能浖^程模型。 噴泉模型要點：各階段相互重疊，它反映了軟件過程并行性的特點表達認識事物的往返過程強調(diào)增量開發(fā)，整個過程是一個迭代的逐步提煉的過程。開發(fā)活動之間的無間隙性和循環(huán)迭代性適用于面向?qū)ο蟮拈_發(fā)過程強調(diào)無明顯的活動階段劃分 集成和測試階段編碼階段面向?qū)ο笤O(shè)計階段面向?qū)ο蠓治鲭A段需求階段進一步開發(fā)進行狀態(tài)維護期練習題假設(shè)要開發(fā)一個軟件，該軟件的功能是對特定工程進行一項驗證計算假定計算方法十分確定、成熟，一

17、旦實現(xiàn)后將用于該工程的測試驗證中，由于工程的特殊性，所以，該軟件產(chǎn)品在完成使命后將被拋棄。軟件需求明確，算法確定、成熟，故無須原型來驗證。一旦驗證完成之后將被拋棄，故無須使用提高軟件可維護性的迭代模型和螺旋模型。綜上所述，為了開發(fā)此軟件，使用瀑布模型即可。練習題續(xù)假設(shè)工程組正在開發(fā)已經(jīng)被廣泛使用的字處理軟件的新版本，由于市場競爭劇烈，公司規(guī)定了嚴格的完成期限。舊版本相當于一個原型，通過收集用戶對舊版本的反映，較容易確定新版本的需求，故無需用原型模型軟件工程師對舊版很熟悉，有開發(fā)字處理軟件的經(jīng)驗，具有采用迭代式增量模型開發(fā)的技術(shù)水平。軟件今后可能還要開發(fā)更新版本，因此該軟件的體系結(jié)構(gòu)應(yīng)該是開放式

18、的，已利于今后的改進和擴充。綜上所述，為了開發(fā)此軟件，使用迭代式增量模型即可。第4章 需求工程 需求工程的定義軟件需求工程的內(nèi)容軟件需求工程過程需求工程的涉眾需求工程方法需求工程的定義需求工程是指應(yīng)用已證實有效的技術(shù)、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統(tǒng)的所有外部特征的一門學(xué)科。需求工程的組成系統(tǒng)需求工程軟件需求工程軟件需求工程的定義分析并記錄軟件需求的學(xué)科分解系統(tǒng)需求子系統(tǒng)和任務(wù)分配將某些子系統(tǒng)和任務(wù)分配給軟件轉(zhuǎn)換將系統(tǒng)需求轉(zhuǎn)換為軟件的需求描述和一些性能參數(shù)。軟件需求工程的內(nèi)容 需求基線團隊成員已經(jīng)承諾將在某一特定產(chǎn)品版本中實現(xiàn)的功能和非功能需求的一組集合。一定要通過正式的評審和批準工程的涉眾必須要對此需求集合達成共識將此需求集合明確為一個基線版本即基線化SRS從此開始要實施嚴格的版本控制惟一地標識每一個SRS的不同版本。此后的需求管理將圍繞基線展開軟件需求工程過程 需求建模需求描述需求有效性驗證初步需求說明系統(tǒng)分析模型需求規(guī)格說明書確認的需求文擋需求獲取與分析軟件需求工程的根本活動獲取與分析需求；深入實際，在充分理解用戶需求的根底上，獲取系統(tǒng)需求。需求建模；進行需求