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

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

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

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

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

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

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

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

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

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

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

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

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

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

14、量上的開支風(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)容它沒有支持多工程的開發(fā)結(jié)構(gòu)，這在一定程度上降低了在開發(fā)組織內(nèi)大范圍實(shí)現(xiàn)重用的可能性。

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

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

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

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