




版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)
文檔簡介
1、63,1,軟件需求工程的概念,北京航空航天大學(xué)軟件工程研究所 羅燕京 2013.2第7版 Luo_,63,2,軟件需求工程的概念,對(duì)軟件需求的認(rèn)識(shí) 軟件需求工程的基本框架 需求與其他項(xiàng)目過程的聯(lián)系 需求工程描述,63,3,對(duì)軟件需求的認(rèn)識(shí),63,4,1.1 對(duì)軟件需求的初級(jí)認(rèn)識(shí),需求不是根本問題,編碼才是軟件開發(fā)工作。 給我一個(gè)項(xiàng)目,無論需求多么復(fù)雜我一定能完成它。需求很重要,但很容易搞清它。 在初級(jí)軟件開發(fā)人員的潛意識(shí)中需求不是那么可怕,編程技術(shù)才是重要的。 當(dāng)這些問題與需求管理處理技能不足,缺乏管理工具,出現(xiàn)需求管理混現(xiàn)時(shí)才會(huì)逐漸引起項(xiàng)目管理者的重視。,1.2 業(yè)界的當(dāng)前狀況,根本某軟件公
2、司近五年的實(shí)踐總結(jié), 在軟件項(xiàng)目開發(fā)中的主要分類10種問題; 總結(jié)的10種問題分類中需求過程占了30%; 需求問題占了47%;,63,5,63,6,具體問題實(shí)例,我們不了解客戶的配合工作執(zhí)行情況,很難有機(jī)會(huì)與客戶交流項(xiàng)目進(jìn)度情況,存在溝通理解偏差的情況; 前期需求方面加大力度,明確及確認(rèn)各項(xiàng)需求邊界,做好需求變更控制; xx項(xiàng)目需求變更過大,不能有效控制; 頻繁的人員變動(dòng)及需求變更導(dǎo)致進(jìn)度不斷延遲; 需求沒有在實(shí)際開發(fā)開展之前與客戶達(dá)成共識(shí);,63,7,具體問題實(shí)例,總體感覺項(xiàng)目范圍界限沒有用需求規(guī)格說明書或者需求說明書規(guī)范,導(dǎo)致在系統(tǒng)設(shè)計(jì)、開發(fā)的過程中發(fā)現(xiàn)問題無據(jù)可查。 客戶不斷的提出修改要
3、求,使最初的有序開發(fā),逐步轉(zhuǎn)變?yōu)槠S趹?yīng)付客戶新要求 面對(duì)需求頻繁變更給我們帶來的許多不確定性的問題,目前沒有太好的辦法來解決。 客戶方對(duì)自己的需求并不清晰,開發(fā)項(xiàng)目過程受客戶方影響過大,客戶方在適用階段才提出了不少的變更;,63,8,具體問題實(shí)例,沒有受控的需求,甚至需求還未完成的基礎(chǔ)上就已開始了測試工作; 一份與客戶達(dá)成共識(shí)的需求規(guī)格說明書很重要! 售前工作方面提升的空間很大,包括與客戶溝通、收集客戶需求、編寫方案、等等技術(shù)技能方面都比較欠缺,對(duì)行業(yè)領(lǐng)域內(nèi)的專業(yè)知識(shí)還需要進(jìn)一步的積累;,63,9,總結(jié)評(píng)估,說明大部分軟件項(xiàng)目所遇到的問題是基本一致的; 說明軟件研發(fā)人員對(duì)所遇到的問題的認(rèn)識(shí)是基
4、本一致的; 說明大多數(shù)軟件項(xiàng)目的技術(shù)過程瓶頸是基本一致的; 說明軟件需求過程問題是當(dāng)前項(xiàng)目研發(fā)中的主要過程技術(shù)瓶頸;,63,10,1.3 項(xiàng)目失敗的根本原因,需求來源:市場需求主導(dǎo)不足 不完整的需求 缺乏用戶介入 不實(shí)際的客戶期望 需求和規(guī)范的變更 缺乏高層的支持 勝任的團(tuán)隊(duì)成員大少 缺乏項(xiàng)目管理經(jīng)驗(yàn),63,11,63,12,1.4 相對(duì)重要的軟件問題,一次調(diào)查以確定在產(chǎn)業(yè)中相對(duì)重要的軟件問題,根據(jù)3800個(gè)被調(diào)查人的回答,大約半數(shù)的被調(diào)查者回答的兩個(gè)最大問題是: 1)需求規(guī)格說明 2)管理客戶需求 相對(duì)而言編碼不是問題 很顯然,我們完全可以把需求當(dāng)作導(dǎo)致軟件問題的最根本原因。,63,13,需
5、求錯(cuò)誤的頻率,缺陷來源 潛在缺陷 排除的效率 提交的缺陷 需求 1.00 77% 0.23 設(shè)計(jì) 1.25 85% 0.19 編碼 1.75 95% 0.09 建檔 0.60 80% 0.12 不恰當(dāng)修復(fù) 0.40 70% 0.12 合計(jì) 5.00 85% 0.75,63,14,需求錯(cuò)誤的頻率,需求錯(cuò)誤在提交缺陷(用戶著到的缺陷)中是最高的,占了大約全部提交缺陷的三分之一。 因此需求錯(cuò)誤是系統(tǒng)開發(fā)錯(cuò)誤中最常見的一類錯(cuò)誤。,63,15,1.5 需求錯(cuò)誤的高昂代價(jià),如果把編碼階段發(fā)現(xiàn)和修復(fù)一個(gè)錯(cuò)誤所需要的努力用1個(gè)成本單元表示的話,那么需求階段的錯(cuò)誤修復(fù)成本是它的5到10倍。而且,在維護(hù)階段發(fā)現(xiàn)和
6、修復(fù)一個(gè)錯(cuò)誤的成本超過20倍。 在項(xiàng)目的需求階段發(fā)現(xiàn)錯(cuò)誤所花費(fèi)的成本與維護(hù)階段發(fā)現(xiàn)錯(cuò)誤的成本比例是200:1,63,16,在生命周期不同階段修復(fù)缺陷的相對(duì)成本,20,5,2,1,0.5,0.1,需求,設(shè)計(jì),編碼,單元測試,驗(yàn)收測試,維護(hù),63,17,結(jié)論,需求錯(cuò)誤可能是最常見的錯(cuò)誤。 需求錯(cuò)誤可能是修改花費(fèi)最昂貴的錯(cuò)誤。 需求錯(cuò)誤可能消耗整個(gè)項(xiàng)目預(yù)算的25%到40%。 給定需求錯(cuò)誤的頻率及其“修改成本”的倍增效果因子,可以預(yù)言,需求錯(cuò)誤將占去返工成本的70%或更多。 返工通常會(huì)消耗項(xiàng)目預(yù)算的30%到50%,因此得出:需求錯(cuò)誤很容易就消耗掉整個(gè)項(xiàng)目預(yù)算的25%到40%!,63,18,1.6 軟件
7、需求的主要問題,領(lǐng)域知識(shí) 需求過程 需求方法 需求技術(shù) 需求工具 需求管理經(jīng)驗(yàn) 高層管理的支持 勝任的團(tuán)隊(duì)成員 資金與時(shí)間,63,19,軟件需求的主要問題,63,20,什么是好的需求,好的需求是正確的、無歧義的、可檢驗(yàn)和可驗(yàn)證的并且是可跟蹤的。 好的需求集合是完整的、一致的和可修改的。(IEEE軟件需求規(guī)格說明標(biāo)準(zhǔn)),63,21,對(duì)現(xiàn)代軟件需求的認(rèn)識(shí),軟件需求是領(lǐng)域知識(shí)的學(xué)習(xí)、經(jīng)驗(yàn)積累的過程。 軟件需求是領(lǐng)域知識(shí)的傳遞過程。 軟件需求是在軟件開發(fā)過程中迭代增量的認(rèn)識(shí)過程。 軟件需求是不斷變化的,我們要承認(rèn)和適應(yīng)這種變化,要學(xué)習(xí)適應(yīng)軟件變化的技術(shù)和方法。 軟件需求是軟件開發(fā)過程中最關(guān)鍵的過程。,
8、63,22,軟件需求工程的基本框架,63,23,軟件需求工程的概念,軟件需求工程包括了以下主要內(nèi)容: 對(duì)軟件需求基本知識(shí)的學(xué)習(xí)和了解 掌握一個(gè)基本的需求過程 熟練過程活動(dòng)的方法和技術(shù),軟件需求過程的六個(gè)主要活動(dòng),軟件需求過程包括需求開發(fā)和需求管理兩大類活動(dòng)。 需求開發(fā)活動(dòng) 需求獲取 需求分析 需求定義 需求管理活動(dòng) 需求驗(yàn)證和確認(rèn) 需求跟蹤 需求變更控制,63,24,63,25,開發(fā)過程產(chǎn)品,軟件需求工程的基本框架,63,26,需求處理過程的生命周期,63,27,軟件需求過程,軟件需求過程包括需求開發(fā)和需求管理兩大類活動(dòng)。 需求開發(fā)活動(dòng) 需求獲取、需求分析、需求定義 需求管理活動(dòng) 需求驗(yàn)證和確
9、認(rèn)、需求跟蹤、需求變更控制,63,28,需求開發(fā)與需求管理之間的界限,63,29,基本的軟件需求過程,63,30,好的過程屬性,過程被書面化 過程是靈活的,可變的 每個(gè)人都同意遵循這個(gè)過程 過程包含度量,該度量用于測量過程的有效性 度量是修改過程的基礎(chǔ) 過程被主動(dòng)管理,63,31,軟件需求工程框架,我們把所有與軟件需求相關(guān)的活動(dòng)通稱為軟件需求工程。 需求工程中的活動(dòng)可分為兩大類: 需求開發(fā) 需求管理,63,32,需求開發(fā),需求開發(fā)包括三個(gè)知識(shí)和實(shí)踐要點(diǎn): 1.需求獲取 2.需求分析 3.需求定義,63,33,需求開發(fā),需求開發(fā)可分為兩個(gè)階段:“用戶需求調(diào)查階段”和“產(chǎn)品需求定義階段”,“需求分
10、析”則貫穿于上述兩個(gè)階段。 需求調(diào)查階段和需求定義階段在邏輯上存在先后關(guān)系,實(shí)際工作中二者通常是迭代進(jìn)行的。我們把從事需求開發(fā)工作的人員稱為需求分析員(系統(tǒng)分析員),63,34,需求管理,需求管理包括三個(gè)知識(shí)和實(shí)踐要點(diǎn) 1.需求驗(yàn)證和確認(rèn) 2.需求跟蹤 3.需求變更控制,63,35,什么是需求管理,需求定義了系統(tǒng)必須具有的能力,一個(gè)項(xiàng)目的成功與否往往取決于它是否符合一系列的需求。因此,探討需求的確切含義、把它們寫下來、組織起來、跟蹤它們的變更就顯得非常有意義。 需求管理定義為:為系統(tǒng)的需求進(jìn)行啟發(fā)、組織、建檔的系統(tǒng)方法,建立和維護(hù)客戶和項(xiàng)目團(tuán)隊(duì)之間關(guān)于變更系統(tǒng)需求所達(dá)成的一致性的過程。,63,
11、36,需求管理,任何曾經(jīng)參與過復(fù)雜軟件系統(tǒng)的人,無論是作為用戶還是開發(fā)人員,都知道從用戶和風(fēng)險(xiǎn)承擔(dān)人那里獲取需求的能力是非常關(guān)鍵的技能; 與一個(gè)系統(tǒng)相關(guān)的需求即使沒有上千條,也至少有數(shù)百條,因此把它們合理地組織起來非常重要。 我們無法記憶太多的信息,因此為需求建檔能夠有效支持風(fēng)險(xiǎn)承擔(dān)人之間的溝通。 必須把需求用可訪問的介質(zhì)來記錄:文檔,模型。,63,37,需求管理,需求管理與項(xiàng)目的大小和復(fù)雜度有關(guān) 兩個(gè)人、十條需求的項(xiàng)目,不需要管理需求。但是,如果要驗(yàn)證一個(gè)有500-1000條需求的軟件產(chǎn)品,我們就面臨著必須對(duì)這些需求進(jìn)行組織、劃定優(yōu)先級(jí)、控制對(duì)它們的訪問以及為它們提供存儲(chǔ)資源的問題。 可以把
12、需求管理看成處理重要的復(fù)雜項(xiàng)目需求的一系列理有組織的、標(biāo)準(zhǔn)化的、系統(tǒng)化的過程和技術(shù)。,63,38,軟件需求工程的螺旋模型,63,39,過程活動(dòng)的方法和技術(shù),需求獲取的方法和技術(shù) 發(fā)現(xiàn)(方法:角色、活動(dòng)、資源、產(chǎn)品) 收集(方法:用例、流程圖) 分類(方法:按活動(dòng)、角色相關(guān)度) 評(píng)估(方法:風(fēng)險(xiǎn)、原因) 優(yōu)先級(jí)(方法:重要性、價(jià)值) 文檔(用戶需求說明書) 需求分析的方法和技術(shù) 結(jié)構(gòu)化分析方法和面向?qū)ο蟮幕痉椒?基于UML的用例分析技術(shù)),63,40,過程活動(dòng)的方法和技術(shù),需求定義的方法和技術(shù)(需求規(guī)格說明書) 用例模型建模方法和用例補(bǔ)充規(guī)約說明 需求驗(yàn)證和確認(rèn)的方法和技術(shù) 驗(yàn)證與評(píng)審和測試方
13、法技術(shù) 需求跟蹤的方法和技術(shù) 需求跟蹤矩陣 需求變更控制的方法和技術(shù) 需求變更控制流程和變更控制委員會(huì),63,41,需求與其他項(xiàng)目過程的聯(lián)系,63,42,需求工程描述,63,43,需求工程的用例,63,44,涉眾,涉眾是所有會(huì)受到項(xiàng)目結(jié)果重大影響的人。 要有效地解決任何復(fù)雜的問題,就會(huì)涉及到滿足不同涉眾的需要。涉眾通常會(huì)對(duì)問題持有不同的觀點(diǎn),因而必須用所提供的解決方案來滿足不同的需要。 許多涉眾都是系統(tǒng)的用戶。其中許多涉眾只是系統(tǒng)的間接用戶,或者只受到系統(tǒng)所影響的業(yè)務(wù)結(jié)果的影響。還有許多涉眾是系統(tǒng)的經(jīng)濟(jì)型買主或支持者。 了解涉眾的組成及其特定需要是開發(fā)有效解決方案的關(guān)鍵。,63,45,風(fēng)險(xiǎn)承擔(dān)
14、者,風(fēng)險(xiǎn)承擔(dān)者是高層需求的提出者,他們往往對(duì)需求細(xì)節(jié)不是很關(guān)心。 系統(tǒng)的主要功能產(chǎn)生的作用及效益是他們關(guān)心的重點(diǎn)。 注意系統(tǒng)風(fēng)險(xiǎn)承擔(dān)者的宏觀需求是有效解決問題的關(guān)鍵和項(xiàng)目成功的保證之一。,63,46,客戶,客戶有兩種: 系統(tǒng)的操作者和維護(hù)者,他們對(duì)系統(tǒng)的界面、易使用性、易維護(hù)性、穩(wěn)定性比較關(guān)心。 系統(tǒng)的用戶,對(duì)系統(tǒng)的功能可以給他們帶來的便利程度、舒適度、工作效率、工作滿意度比較關(guān)心。,63,47,領(lǐng)域?qū)<?領(lǐng)域?qū)<揖哂胸S富的業(yè)務(wù)領(lǐng)域經(jīng)驗(yàn),是系統(tǒng)業(yè)務(wù)流程、業(yè)務(wù)規(guī)則的提供者。 領(lǐng)域?qū)<沂菢I(yè)務(wù)建模的主要角色。 但是領(lǐng)域?qū)<乙话闳狈I(yè)務(wù)模型轉(zhuǎn)化為計(jì)算機(jī)邏輯模型的經(jīng)驗(yàn)和能力。 具有領(lǐng)域經(jīng)驗(yàn)和計(jì)算機(jī)建模
15、經(jīng)驗(yàn)的專家是非常少的,兩者的結(jié)合是需求成功的保證。,63,48,變更控制經(jīng)理,變更控制經(jīng)理負(fù)責(zé)對(duì)變更控制過程進(jìn)行監(jiān)督。 此角色通常由配置(或變更)控制委員會(huì) (CCB) 來擔(dān)任,該委員會(huì)應(yīng)該由有關(guān)各方(包括客戶、開發(fā)人員和用戶)的代表組成。 在小型項(xiàng)目中,項(xiàng)目經(jīng)理或軟件構(gòu)架設(shè)計(jì)師一人即可承擔(dān)此角色。,63,49,系統(tǒng)分析員,系統(tǒng)分析員通過概括系統(tǒng)的功能和界定系統(tǒng)來領(lǐng)導(dǎo)和協(xié)調(diào)需求獲取及用例建模。例如,確定存在哪些主角和用例,以及他們之間如何交互。 擔(dān)任系統(tǒng)分析員的人員應(yīng)該善于協(xié)調(diào),并且具有良好的溝通技巧。擔(dān)任此角色的人員中必須要有具備業(yè)務(wù)和技術(shù)領(lǐng)域知識(shí)的人才,但這些知識(shí)并不是所有人都必須具備的。
16、,63,50,1.需求獲取,需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息(原始材料),產(chǎn)生用戶需求說明書。,63,51,需求獲取,需求獲取本質(zhì)上是一個(gè)涉及不同團(tuán)體的交流過程??煞纸鉃橄铝谢顒?dòng): 發(fā)現(xiàn)(方法:角色、活動(dòng)、資源、產(chǎn)品) 收集(方法:用例、流程圖) 分類(方法:按活動(dòng)、角色相關(guān)度) 評(píng)估(方法:風(fēng)險(xiǎn)、原因) 優(yōu)先級(jí)(方法:重要性、價(jià)值) 文檔:(用戶需求說明書),63,52,2. 需求分析,需求分析的目的是對(duì)各種需求信息進(jìn)行分析,消除錯(cuò)誤,刻畫細(xì)節(jié)等。 常用的需求分析方法有 “結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā薄?面向?qū)ο蠓治龇壳俺S玫姆椒ㄊ腔赨ML的用例分析技術(shù),產(chǎn)品是用例模
17、型。,63,53,3. 需求定義,需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果,進(jìn)一步定義準(zhǔn)確無誤的產(chǎn)品需求,產(chǎn)生產(chǎn)品需求規(guī)格說明書。 系統(tǒng)設(shè)計(jì)人員將依據(jù)產(chǎn)品需求規(guī)格說明書開展系統(tǒng)設(shè)計(jì)工作。,63,54,需求開發(fā)過程產(chǎn)生的主要文檔,用戶需求說明書。 產(chǎn)品需求規(guī)格說明書 用例模型 補(bǔ)充規(guī)約說明,63,55,4. 需求驗(yàn)證和確認(rèn),需求驗(yàn)證是指開發(fā)方和客戶共同對(duì)需求文檔進(jìn)行評(píng)審,雙方對(duì)需求達(dá)成共識(shí)后做出書面承諾,使需求文檔具有商業(yè)合同效果。,63,56,需求驗(yàn)證和確認(rèn),需求驗(yàn)證是確保開發(fā)活動(dòng)不斷地符合客戶需要的過程,驗(yàn)證主要是通過評(píng)審活動(dòng)來完成的。 需求確認(rèn)活動(dòng)是在軟件開發(fā)后判斷軟件是否正確地實(shí)現(xiàn)了需求,需求確認(rèn)主要是通過測試和測量活動(dòng)來完成的。,63,57,
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。
最新文檔
- 廣告應(yīng)急預(yù)案管理辦法
- 影視版權(quán)登記管理辦法
- 各類資金賬戶管理辦法
- 護(hù)理管理人員管理辦法
- 肝臟中醫(yī)課件
- 室內(nèi)培訓(xùn)課件舞蹈圖片
- 肝癌晚期護(hù)理
- 二七區(qū)全區(qū)統(tǒng)考數(shù)學(xué)試卷
- 芬蘭八年級(jí)的數(shù)學(xué)試卷
- 肚子響中醫(yī)辯證課件
- 2025年銀行反洗錢知識(shí)競賽考試卷庫90題
- 算法用戶標(biāo)簽管理制度
- 《選礦廠安全生產(chǎn)標(biāo)準(zhǔn)化評(píng)分辦法》
- 期末試卷(含答案)2024-2025學(xué)年四年級(jí)下冊數(shù)學(xué)北師大版
- 《客艙安全與應(yīng)急處置》-課件:火災(zāi)的基礎(chǔ)知識(shí)
- 自然資源執(zhí)法監(jiān)察工作規(guī)范培訓(xùn)課件
- 部編版《語文》三年級(jí)下冊全冊教案及反思
- NB∕T 10731-2021 煤礦井下防水密閉墻設(shè)計(jì)施工及驗(yàn)收規(guī)范
- 《干部履歷表》(1999版電子版)
- 基因組學(xué)期末復(fù)習(xí)資料(共22頁)
- 河南省道路運(yùn)輸企業(yè)質(zhì)量信譽(yù)考核申請表
評(píng)論
0/150
提交評(píng)論