第二講需求管理..ppt

1、第二講 需求管理,內(nèi) 容,軟件發(fā)展的三個時期 軟件生存期過程 軟件開發(fā)過程 軟件需求 需求工程 需求管理 CMM2級需求管理關(guān)鍵過程域,一、軟件發(fā)展的三個時期,表一,二、軟件生存期過程,ISO/IEC12207 信息技術(shù)軟件生存期過程,基本過程,支持過程,組織過程,軟件生存期過程,圖1-1,供應(yīng)過程,開發(fā)過程,運行過程,基本過程,獲取過程,維護(hù)過程,圖1-2,基礎(chǔ)設(shè)施過程,改進(jìn)過程,培訓(xùn)過程,組織過程,管理過程,圖1-4,三、軟件開發(fā) 過程,1.計算機(jī)系統(tǒng),人員,硬件,軟件,數(shù)據(jù),傳輸 機(jī)構(gòu),執(zhí)行 機(jī)構(gòu),（劇作家、導(dǎo)演）,（舞臺,劇本,演員,道具）,圖2 計算機(jī)系統(tǒng),2.軟件開發(fā)過程： 活動任

2、務(wù),系統(tǒng)需求分析 系統(tǒng)結(jié)構(gòu)設(shè)計 軟件需求分析 建立軟件需求 評價軟件需求 聯(lián)合評審 軟件結(jié)構(gòu)設(shè)計 軟件詳細(xì)設(shè)計 軟件編碼和測試 軟件集成 軟件鑒定測試 系統(tǒng)集成 系統(tǒng)鑒定測試 軟件安裝 軟件驗收支持,軟件開發(fā)面臨的實際問題,軟件開發(fā)面臨的實際問題,軟件開發(fā)面臨的實際問題,3 定義軟件開發(fā)過程的步驟 （1）確定軟件模型 （2）確定活動 （3）確定活動間的關(guān)系 （4）文檔化每個活動的其他有用信息 （5）文檔化剪裁過程 （6）文檔化改善過程 （7）獲得過程的認(rèn)可 （8）不斷使用和改善過程,3.1 確定軟件模型 編碼修復(fù)模型 瀑布模型 增量模型 迭代模型 3.2 確定活動 3.3 確定活動間的關(guān)系 3

3、.4 活動的有用信息文檔化,3.5 剪裁過程文檔化 3.6 改善過程文檔化 3.7 過程獲得認(rèn)可并培訓(xùn)員工 3.8 不斷使用和改善過程,4當(dāng)前軟件開發(fā)項目的特點,規(guī)模大： LOC1萬幾十萬 HP激光打印驅(qū)動軟件 4萬110萬 復(fù)雜 質(zhì)量要求高滿足客戶需求和期望 客戶滿意度統(tǒng)計 開發(fā)和維護(hù)成本缺陷后期發(fā)現(xiàn) 返工成本 延誤交付期,四、軟件需求 1.系統(tǒng)需求分析,軟件 系統(tǒng)需求(1),系統(tǒng)需求,分配,軟件工程組,硬件 系統(tǒng)需求(2),其它成分 系統(tǒng)需求(n),軟件需求,客戶,最終用戶,系統(tǒng)工程組,圖3 系統(tǒng)需求分配,2.軟件需求, 定義（IEEE-STD-610） 用戶為解決某個問題、或為實現(xiàn)某一目

4、標(biāo)， 要求軟件必須滿足的條件或能力。 軟件需求的三個層次 業(yè)務(wù)需求 用戶需求 功能需求和非功能需求,非功能需求,過程需求：交付需求，實現(xiàn)需求，遵循的標(biāo)準(zhǔn) 性能需求：速度，容量，可靠性 外部需求：互操作性，倫理性， 機(jī)密性，安全性， 使用要求,業(yè)務(wù)需求,業(yè)務(wù)說明,使用實例,用戶需求,功能需求,約束條件,非功能需求,軟 件 需 求 規(guī) 格 說 明,圖 4 軟件需求的層次,質(zhì)量功能展開（QFDQuality Function Development）,客戶需求,常規(guī)需求：客戶明確提出 期望需求：并未明確提出的潛在需求， 不 言而喻的需求 興奮需求：客戶未想到，若實現(xiàn)客戶 感到意外,分配需求的實例,系

5、 統(tǒng) 需 求 ACCS應(yīng)能使汽車保持在預(yù)期車速的2KMH范圍內(nèi)行駛,分配給硬件的需求 硬件應(yīng)能使車速在規(guī)定的精確度1.5KMH范圍內(nèi),分配給軟件的需求 軟件應(yīng)能在車速超出預(yù)期車速0.5KMH時給硬件加/減速命令,軟 件 需 求 軟件應(yīng)能： 讀入當(dāng)前車速值 計算當(dāng)前車速與預(yù)期車速之差 若差值0.5KMH給出加/減速命令,圖5 汽車限速系統(tǒng)ACCS的需求分配,3CMM 2級 關(guān)鍵過程域需求管理（KPA RM）中對軟件需求的解釋：,分配需求（allocated requirements）： 分配給軟件的系統(tǒng)需求,（1）分配需求包括： 影響和確定軟件項目活動的非技術(shù)性需求 （在合同條款中規(guī)定），如：

6、要交付的產(chǎn)品 交付日期 里程碑 軟件的技術(shù)需求，如： 最終用戶、操作人員、支持或集成的功能 性能需求 設(shè)計約束條件 編程語言 界面需求 用于確認(rèn)軟件產(chǎn)品滿足分配需求的驗收準(zhǔn)則,（2）分配需求應(yīng)當(dāng)是： 以軟件來實現(xiàn)是可行的，而且是適合的； 已得到清晰而正確的闡述； 相互之間是一致的； 可以測試的。 同時，分配需求應(yīng)當(dāng)： 被管理和控制（如必要可納入軟件配置管理） 是制定軟件開發(fā)計劃SDP的基礎(chǔ) 是制定軟件需求的基礎(chǔ),（3）與分配需求相關(guān)的組： 軟件評估組 系統(tǒng)工程組 系統(tǒng)測試組 軟件質(zhì)量保證組SQA 合同管理組 文檔支持組,五、需求工程,1需求工程需求開發(fā)需求管理,獲取需求,分析需求,定義需求,驗

7、證需求,需求變更控制,需求跟蹤,需求狀態(tài)跟蹤,需求文檔版本控制,需求開發(fā),需求管理,需求工程,圖6 需求工程的構(gòu)成,用戶/系統(tǒng),市場,管理者,初始需求,變更的需求,獲取,分析,定義,驗證需求,控制需求變更,需求規(guī)格說明,項目環(huán)境,需求開發(fā),需求管理,圖7 需求開發(fā)與需求管理,2需求開發(fā),（1）獲取需求 確定目標(biāo)用戶、服務(wù)對象 明確用戶代表 用戶培訓(xùn) 了解實際業(yè)務(wù)和業(yè)務(wù)需求 （2）分析需求 分清功能需求、性能需求、使用需求 必要性 可行性,（3）定義需求 編寫軟件需求規(guī)格說明（SRS） 作用 要求：完整、正確、可行、無歧意、可驗證 形式：圖、表、文字 （4）驗證需求 聯(lián)合評審,六、需求管理,需求

8、管理的目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護(hù)需求與工作成果的一致性，并控制需求的變更。 包括：需求確認(rèn) 需求變更控制 需求跟蹤 1、需求確認(rèn) 需求確認(rèn)是指開發(fā)方和客戶共同對需求文檔進(jìn)行評審，雙方對需求達(dá)成共識后做出書面承諾，使需求文檔具有商業(yè)合同效果。,需求確認(rèn)步驟： （1）非正式需求評審 項目經(jīng)理先在項目內(nèi)部組織人員進(jìn)行非正式的需求評審，消除明顯的錯誤和分歧。 （2）正式需求評審 項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的意愿。 （3）獲取需求承諾 通過正式評審后，開發(fā)方負(fù)責(zé)人（項目經(jīng)理）和客戶對需求文檔做書面承

9、諾，使之具有商業(yè)合同效果。,例如： 本需求文檔建立在雙方對需求的共同理解基礎(chǔ)上，我同意后續(xù)的開發(fā)工作根據(jù)該需求文檔開展。如果需求發(fā)生變化，我們將按照“需求變更控制規(guī)程”執(zhí)行。我明白，需求的變更將導(dǎo)致雙方重新協(xié)商成本、資源和進(jìn)度等。 甲方負(fù)責(zé)人簽字 乙方負(fù)責(zé)人簽字,2、需求變更控制 什么是需求變更？,初始需求,變更的需求,對問題的 初始理解,對問題的 新理解,時間,圖8 需求的變更,需求變更原因分析,單純的用戶因素 市場形勢變化 系統(tǒng)因素 工作環(huán)境和要求變化 需求開發(fā)的缺陷 需求分析、定義和評審不充分 與用戶溝通不暢,需求變更對軟件開發(fā)的影響, 使變更前開發(fā)工作和成果失效 返工成為被迫采取的對策

10、 工作量及資源投入的增加使開發(fā)成本提高 項目完成時間后延,需求變更失控可能導(dǎo)致的后果, 未受控的需求 變更引起需求 和實現(xiàn)不一致, 受控的需求 變更使需求和實現(xiàn)一致,圖7 未受控及受控的需求變更,降低需求變更風(fēng)險的策略, 與用戶充分溝通 與用戶共同明確確定的需求的意義,向用戶說明需求不確切或頻繁變更對開發(fā)工作的沖擊 使用戶理解過多變更最終對用戶不利, 與用戶共同確定需求，作為合同附件， 簽字生效 合同中含有對需求變更的條款 采用原型方法開發(fā)，或螺旋模型開發(fā) 項目計劃中適當(dāng)留有余地（時間進(jìn)度、人力投入、 費用等） 嚴(yán)格實施變更控制,需求變更控制要求,變更控制的策略 （1）所有需求變更必須遵循需求

11、變更控制規(guī)程實施變更。 （2）需求變更提出后是否被接受，應(yīng)由專門的組織變 更控制委員會（CCBChange Control Board）審查決定。 （3）不得以任何理由刪除和修改需求變更的原始文件。 （4）應(yīng)將已接受的需求變更通知到所有相關(guān)人員。 （5）已接受的需求變更應(yīng)能追溯到批準(zhǔn)的變更請求。 （6）對項目的需求賦予狀態(tài)屬性，以利于需求變更的控制。,需求變更影響的控制,按CMM2級RM KPA的要求，由于分配需求的變更導(dǎo)致軟件計劃、工作產(chǎn)品和活動的變更，都應(yīng)對其作： 識別 評價 風(fēng)險分析 編制文檔 制定計劃 傳達(dá)給受影響的小組和人員 跟蹤直至結(jié)束,變更控制的步驟,（1）提出變更請求 （2）審

12、理變更請求，進(jìn)行變更影響評估。評估內(nèi)容包括： 變更所需人力投入 變更對原計劃安排的影響 估計變更引起的成本增加 （3）批準(zhǔn)變更請求 （4）取得用戶的認(rèn)可 （5）修訂項目計劃 （6）實施變更 （7）驗證變更,需求變更控制實施,需求變更請求 （1）內(nèi)容 申請?zhí)?變更說明 變更類別 影響分析 變更請求狀態(tài) 變更請求日期,需求變更請求實例（表三）,需求變更累積影響的跟蹤,（1）需求變更累積影響跟蹤的意義和作法 累積影響 變更累積表 （2）需求變更累積表實例（表四）,表四需求變更累積表,需求控制流,（1）需求狀態(tài)及其演變 軟件需求在后繼階段開發(fā)工作中將逐步展開，加以實現(xiàn)。 在不同的開發(fā)階段軟件需求以不同

13、的形式進(jìn)行著狀態(tài)的演變。例如： 需求階段從獲取的需求到定義的需求 建議階段制定出項目計劃以后演化為承諾的需求 設(shè)計階段設(shè)計工作完成并在驗收后成為設(shè)計的需求 編碼階段完成編碼和單元測試后成為實現(xiàn)的需求 測試階段完成確認(rèn)測試后成為完成的需求,開發(fā) 階段,需求 狀態(tài),需求,建議,設(shè)計,編碼,測試,獲取,定義,承諾,設(shè)計,實現(xiàn),完成,圖11 生存期各階段需求 狀態(tài)的演變,(1) 需求可跟蹤與需求變更控制 隨著開發(fā)工作的進(jìn)展需求將逐步擴(kuò)展和演化 各個開發(fā)階段的工作產(chǎn)品之間存在的繼承關(guān)系 可跟蹤矩陣 (2)可跟蹤管理的目標(biāo) 使每一項需求均能追溯到 前后繼承關(guān)系的脈絡(luò)清晰可見 (3)兩類不同的跟蹤 （1）向

14、前跟蹤 （2）向后跟蹤,3、需求跟蹤,可跟蹤矩陣,（1）矩陣的作用 可防止遺漏 為評審提供方便 便于進(jìn)行變更影響追蹤、分析和檢查 （2）矩陣的建立與維護(hù),（3）矩陣的應(yīng)用 完整性檢驗 考察有無需求遺漏的情況 有無冗余代碼 檢查所有性能需求是否已被測試用例測試 對集成測試計劃和系統(tǒng)測試計劃進(jìn)行交互檢查 需求變更控制 需求變更后相關(guān)的工作產(chǎn)品受影響的部分應(yīng)隨之變更 更新需求規(guī)格說明，同時要更新跟蹤矩陣 每增加一項需求，應(yīng)在跟蹤矩陣中得到體現(xiàn),表五 跟蹤矩陣實例,需求跟蹤歸納如下： 1、建立和維護(hù)需求跟蹤矩陣 正向跟蹤 逆向跟蹤 當(dāng)需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣 2、查找不

15、一致 后續(xù)工作成果沒有實現(xiàn)需求文檔中的某些需求 后續(xù)工作成果實現(xiàn)了需求文檔中不存在的需求 后續(xù)工作成果沒有正確實現(xiàn)需求文檔中的需求 3、消除不一致 將消除不一致記錄到“需求跟蹤報告” 消除不一致后，項目經(jīng)理更新“需求跟蹤矩陣”,七、CMM 2級 RM KPA,需求管理（RMRequirements Management）是CMM 2級的第1個關(guān)鍵過程域。需求管理的目的是要在客戶和將處理客戶需求的軟件項目之間形成共同的理解。 這種共同理解應(yīng)該體現(xiàn)在： 客戶需求的文檔和對客戶需求的控制中 使項目的計劃、產(chǎn)品和活動都應(yīng)與需求一致,2級,RM,SPP,SPTO,SSM,SQA,SCM,目標(biāo),G1 G2

16、,約定,能力,活動,測量,驗證,C1,Ab1,Ab2,Ab3,Ab4,Ac1,Ac2,Ac3,M1,V1,V2,V3,圖13 RM KPA 結(jié)構(gòu),1目標(biāo)與活動,目標(biāo)1：分配給軟件的系統(tǒng)需求應(yīng)是受控的， 以利建立軟件工程和管理的基線 活動1：在分配需求被納入軟件項目之前， 軟件工程組應(yīng)對其進(jìn)行評審 目標(biāo)2：軟件計劃、產(chǎn)品和活動要與分配給軟件的 系統(tǒng)需求保持一致 活動2：軟件工程組將分配需求作為軟件計劃、 工作產(chǎn)品和活動的基礎(chǔ) 活動3：評審對分配需求的變更，并將變更納入 軟件項目,2約定與能力,約定1：項目要遵循一個書面的組織方針來管理 分配給軟件的系統(tǒng)需求 能力1：為每個項目規(guī)定分析系統(tǒng)需求并將其分 配給硬件、軟件和其它系統(tǒng)成分的職責(zé) 能力2：編制分配需求文檔 能力3：為管理分配需求提供足夠的資源和資金 能力4：軟件工程組人員和與軟件相關(guān)的其它組 人員要接受培訓(xùn)，以利于完成他們的需 求管理活動,3測量與驗證,測量1：進(jìn)行測量，并將測量結(jié)果用于確定對分配 需求所作管