軟件項(xiàng)目范圍計(jì)劃課件

第二篇項(xiàng)目計(jì)劃第2章范圍計(jì)劃軟件需求管理任務(wù)分解定義任務(wù)分解的類型任務(wù)分解的過程案例分析第二篇項(xiàng)目計(jì)劃第2章范圍計(jì)劃軟件需求管理范圍計(jì)劃進(jìn)度計(jì)劃成本計(jì)劃核心三計(jì)劃——成本基準(zhǔn)，進(jìn)度基準(zhǔn)一、軟件需求管理軟件需求需求是指用戶對(duì)軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達(dá)到什么性能。范圍計(jì)劃核心三計(jì)劃——成本基準(zhǔn)，進(jìn)度基準(zhǔn)一、軟件需求管理軟軟件需求的層次業(yè)務(wù)需求用戶需求功能需求系統(tǒng)需求非功能性需求質(zhì)量特性約束和假設(shè)軟件需求規(guī)格軟件需求的層次業(yè)務(wù)需求用戶需求功能需求系統(tǒng)需求非功能性需求質(zhì)需求管理的重要性需求管理的重要性項(xiàng)目失敗的原因分析No.Top10FactorsAVG1Inadequaterequirementsspecification4.52Changesinrequirements4.33Shortageofsystemsengineers4.24Shortageofsoftwaremanagers4.15Shortageofqualifiedprojectmanagers4.16Shortageofsoftwareengineers3.97Fixed

-pricecontract3.88Inadequatecommunicationsforsystemintegration3.89Insufficientexperienceasteam3.610Shortageofapplicationdomainexperts3.6Scale:5=VerySerious3=Serious1=NoSeriousSource:Carnegie-MellonUniversity,SoftwareEngineeringInstitute項(xiàng)目失敗的原因分析No.Top10FactorsAVG1需求工程是指應(yīng)用工程化的方法、技術(shù)和規(guī)格來開發(fā)和管理軟件的需求。需求工程需求工程的目標(biāo)是獲取高質(zhì)量的軟件需求。以系統(tǒng)化、條理化、可重復(fù)的方法和技術(shù)進(jìn)行與需求相關(guān)的活動(dòng)，從而提高需求活動(dòng)和過程的可管理性，降低需求開發(fā)和管理的成本。需求工程分為需求開發(fā)和需求管理。需求工程是指應(yīng)用工程化的方法、技術(shù)和規(guī)格來開發(fā)和管理軟件的需需求工程需求管理需求開發(fā)需求獲取需求分析需求規(guī)格說明需求驗(yàn)證變更管理需求工程過程需求工程需求管理需求開發(fā)需求獲取需求分析需求規(guī)格說明需求驗(yàn)證需求獲取階段的任務(wù)可能是軟件開發(fā)中最困難、最關(guān)鍵、最易出錯(cuò)和最需要交流的活動(dòng)。需求獲取用戶要求

擴(kuò)展需求基線需求軟件需求目的是從宏觀上把握用戶的具體需求方向和趨勢(shì)，了解現(xiàn)有的組織架構(gòu)、業(yè)務(wù)流程、軟硬件環(huán)境、現(xiàn)有運(yùn)行系統(tǒng)等具體情況和客觀信息。需求獲取階段的任務(wù)可能是軟件開發(fā)中最困難、最關(guān)鍵、最易出錯(cuò)和需求獲取過程確定需求計(jì)劃確定項(xiàng)目范圍確定調(diào)查對(duì)象收集用戶需求確定非功能性需求和約束條件需求獲取需要從用戶提供的大量信息中分析和理解用戶的真正需求(做什么)，而應(yīng)剔除實(shí)現(xiàn)方式(怎么做)。需求獲取過程確定需求計(jì)劃確定項(xiàng)目范圍確定調(diào)查對(duì)象收集用戶需求需求分析需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模型(邏輯模型)，是對(duì)需求系統(tǒng)地抽象描述。需求分析的基本任務(wù)是分析和綜合已收集到的信息，在于透過現(xiàn)象看本質(zhì)，找出需求信息之間的內(nèi)在聯(lián)系和可能的矛盾，提煉、分析和仔細(xì)審查已收集到的需求信息，找出真正系統(tǒng)的需求，以確保項(xiàng)目相關(guān)人員對(duì)需求都有唯一的理解。需求分析建立的邏輯模型反應(yīng)的是業(yè)務(wù)運(yùn)作流程，而不是技術(shù)開發(fā)流程。需求分析需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模型(邏需求分析模型當(dāng)前系統(tǒng)物理模型邏輯模型目標(biāo)系統(tǒng)物理模型邏輯模型模型化抽象化例化具體化導(dǎo)出理解需求表達(dá)需求需求分析模型當(dāng)前系統(tǒng)物理模型邏輯模型目標(biāo)系統(tǒng)物理模型邏輯模型需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)范的需求規(guī)格說明書。需求規(guī)格需求規(guī)格說明書的編制是為了使用戶和軟件開發(fā)者雙方對(duì)該軟件的初始規(guī)定有一個(gè)共同的理解，使之成為整個(gè)開發(fā)工作的基礎(chǔ)。需求規(guī)格說明書是需求工程的最終輸出，以文檔的形式確定用戶需求和邏輯模型。1）需求規(guī)格是軟件設(shè)計(jì)和實(shí)現(xiàn)的基礎(chǔ)；2）需求規(guī)格是測(cè)試和驗(yàn)收的重要依據(jù)；3）需求規(guī)格為軟件維護(hù)提供重要信心。需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)范的需求1）正確性：所有需求規(guī)格的說明應(yīng)在開發(fā)中滿足；2）一致性：信息在需求規(guī)格描述一致，不發(fā)生矛盾；3）功能性：從實(shí)現(xiàn)中分離功能，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)”；4）規(guī)范性：采用一定的規(guī)格說明語言，無二義性；5）完整性：如果被開發(fā)軟件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格說明的描述之中；6）可行性：規(guī)格說明應(yīng)該包括系統(tǒng)運(yùn)行環(huán)境；7）抽象性：規(guī)格說明應(yīng)該是一個(gè)認(rèn)識(shí)模型；8）開放型：規(guī)格說明應(yīng)該容許不完備性并允許擴(kuò)充。軟件需求規(guī)格的原則1）正確性：所有需求規(guī)格的說明應(yīng)在開發(fā)中滿足；軟件需求規(guī)格的規(guī)格文檔參考1.引言2.5設(shè)計(jì)限制1.1目的2.6

假設(shè)和依賴1.2文檔約定3.

需求規(guī)格1.3預(yù)期讀者3.1功能需求1.4

產(chǎn)品范圍3.2邏輯模型1.5參考文獻(xiàn)3.3數(shù)據(jù)字典2.項(xiàng)目概述3.4性能需求2.1項(xiàng)目背景3.5安全性需求2.2項(xiàng)目目標(biāo)3.6接口需求2.3用戶類3.7其他需求2.4運(yùn)行環(huán)境附錄規(guī)格文檔參考1.引言2.5設(shè)計(jì)限制1.1目的2.6需求是正確的嗎？需求是一致的嗎？需求是完全的嗎？需求是實(shí)際可行的嗎？需求是必要的嗎？需求是可檢驗(yàn)的嗎？需求是可跟蹤的嗎？最后的簽字需求驗(yàn)證需求是正確的嗎？需求驗(yàn)證1）控制對(duì)需求規(guī)格基準(zhǔn)的變動(dòng)；2）保持項(xiàng)目計(jì)劃與需求的一致；3）控制單個(gè)需求的更改；4）管理需求、需求之間的聯(lián)系以及需求與設(shè)計(jì)的關(guān)系；5）跟蹤需求變更的狀態(tài)。需求管理需求管理是為有效地控制和管理需求變更等所進(jìn)行的活動(dòng)。需求管理的主要任務(wù)就是在開發(fā)人員在與提出更改的請(qǐng)求者協(xié)商的基礎(chǔ)上，評(píng)估需求變更帶來的潛在影響及其可能的成本和費(fèi)用，然后實(shí)施更改，以及有效地管理需求規(guī)格說明書和跟蹤更改需求的狀態(tài)。1）控制對(duì)需求規(guī)格基準(zhǔn)的變動(dòng)；需求管理需求管理是為有效地控制確定需求變更控制過程建立變更控制委員會(huì)(SCCB)進(jìn)行需求變更影響分析跟蹤所有受需求變更影響的工作產(chǎn)品建立需求基準(zhǔn)版本和需求控制版本文檔維護(hù)需求變更的歷史記錄跟蹤每項(xiàng)需求的狀態(tài)衡量需求穩(wěn)定性管理和控制需求基線的過程需求變更控制系統(tǒng)一個(gè)正式的文檔，說明如何控制需求變更建立變更審批系統(tǒng)需求變更控制確定需求變更控制過程需求變更控制變更申請(qǐng)需求方開發(fā)方忽略選擇變更方式SCCB評(píng)估項(xiàng)目經(jīng)理自行決定評(píng)估結(jié)果拒絕接受本次修改下個(gè)版本再修改修改合同相關(guān)信息修改相關(guān)需求修改相應(yīng)的項(xiàng)目計(jì)劃變更申請(qǐng)需求方開發(fā)方忽略選擇變更方式SCCB評(píng)估項(xiàng)目經(jīng)理自行軟件基線產(chǎn)品修改申請(qǐng)單申請(qǐng)人張三申請(qǐng)日期2010-03-24項(xiàng)目名稱軟件項(xiàng)目管理系統(tǒng)階段名稱系統(tǒng)設(shè)計(jì)文件名稱RCR-PM-01.doc,RCR-PM-02.doc修改內(nèi)容1）修改測(cè)試流程控制：將2個(gè)角色，3個(gè)渠道流，改為3個(gè)角色，4個(gè)渠道流，詳見RCR-PM-01.doc2）增加開發(fā)人員技能信息庫管理，詳見RCR-PM-02.doc驗(yàn)證意見同意RCR-PM-01.doc變更。RCR-PM-02.doc的變更可以推遲到下一個(gè)版本實(shí)施驗(yàn)證人李四驗(yàn)證日期2010-03-30SCCB李四，王五，趙六填表人張三軟件基線產(chǎn)品修改申請(qǐng)單申請(qǐng)人張三申請(qǐng)日期2010-03-24需求跟蹤是指編制每個(gè)需求與系統(tǒng)元素之間的聯(lián)系(可跟蹤信息)的文檔，其中系統(tǒng)元素包括：其他需求、體系結(jié)構(gòu)、設(shè)計(jì)部件、測(cè)試文檔等。需求跟蹤可跟蹤信息分類：需求-源可跟蹤性：與說明該需求的人或文檔連接；需求-理由可跟蹤性：和理由描述連接；需求-需求可跟蹤性：和依賴于該需求的需求連接；需求-體系結(jié)構(gòu)可跟蹤性：與實(shí)現(xiàn)系統(tǒng)連接；需求-設(shè)計(jì)可跟蹤性：與特定組件連接；需求-界面可跟蹤性：與外部系統(tǒng)界面連接。需求跟蹤是指編制每個(gè)需求與系統(tǒng)元素之間的聯(lián)系(可跟蹤信息)的二、任務(wù)分解定義Workpackages：WBS的最低層次的可交付成果WBS(WorkBreakdownStructure)任務(wù)分解的過程：將一個(gè)項(xiàng)目分解為更多的工作細(xì)目或者子項(xiàng)目，使項(xiàng)目變得更小、更易管理、更易操作。任務(wù)分解的結(jié)果：WBS（任務(wù)分解結(jié)構(gòu)）。WBS：面向可交付成果的。二、任務(wù)分解定義Workpackages：WBS的最低層WBS實(shí)例系統(tǒng)子系統(tǒng)子系統(tǒng)子系統(tǒng)模塊模塊模塊模塊模塊模塊模塊模塊模塊WBS實(shí)例系統(tǒng)子系統(tǒng)子系統(tǒng)子系統(tǒng)模塊模塊模塊模塊模塊模塊是面向可交付成果的對(duì)項(xiàng)目元素的分組，組織并定義了整個(gè)項(xiàng)目范圍，不在WBS中的工作就不是該項(xiàng)目的工作是一個(gè)分級(jí)的樹型結(jié)構(gòu)，是對(duì)項(xiàng)目由粗到細(xì)的分解過程。工作結(jié)構(gòu)每細(xì)分一個(gè)層次表示對(duì)項(xiàng)目元素更細(xì)致的描述WBS定義WBS的最低層次的可交付成果工作包應(yīng)當(dāng)由唯一主體負(fù)責(zé)這一交付成果可以分配給另外一位項(xiàng)目經(jīng)理進(jìn)行計(jì)劃和執(zhí)行,或者通過子項(xiàng)目的方式完成Workpackages定義是面向可交付成果的對(duì)項(xiàng)目元素的分組，組織并定義了整個(gè)項(xiàng)目范圍三、任務(wù)分解的類型圖表類型“變化計(jì)數(shù)器”系統(tǒng)版本比較找出增刪行統(tǒng)計(jì)增刪行統(tǒng)計(jì)總行標(biāo)記修改記錄修改預(yù)處理文件比較結(jié)果處理增加代碼刪除代碼增加行數(shù)刪除行數(shù)三、任務(wù)分解的類型圖表類型“變化計(jì)數(shù)器”系統(tǒng)版本找出統(tǒng)計(jì)統(tǒng)計(jì)清單類型1.

變化計(jì)數(shù)器

1.1

比較兩個(gè)版本的程序1.1.1

預(yù)處理1.1.2

文件比較1.1.3

結(jié)果處理1.2找出修改后的程序中增加和刪除的代碼行1.2.1

找出增加的代碼行1.2.2

找出刪除的代碼行1.3

統(tǒng)計(jì)修改后的程序中增加和刪除的代碼行數(shù)1.3.1

統(tǒng)計(jì)增加代碼行數(shù)1.3.2

統(tǒng)計(jì)刪除代碼行數(shù)1.4

統(tǒng)計(jì)總的代碼行數(shù)

1.5

設(shè)定標(biāo)記以指示修改的次數(shù)1.6

在程序的頭部增加修改紀(jì)錄清單類型1.

變化計(jì)數(shù)器三、任務(wù)分解的方法參照具有類比性的項(xiàng)目(具有相同或相似的周期和工作細(xì)目要求)的WBS。類比模板使用應(yīng)用領(lǐng)域內(nèi)標(biāo)準(zhǔn)或半標(biāo)準(zhǔn)的WBS作為模板參考使用。與類比所參照的WBS不同，模板更具有抽象性，在任務(wù)分解時(shí)需根據(jù)指導(dǎo)說明來開發(fā)項(xiàng)目的WBS。三、任務(wù)分解的方法參照具有類比性的項(xiàng)目(具有相同或相似的周期第2章軟件項(xiàng)目范圍計(jì)劃自上而下“變化計(jì)數(shù)器”系統(tǒng)文件比較預(yù)處理增加代碼結(jié)果處理統(tǒng)計(jì)總行標(biāo)記修改記錄修改版本比較找出增刪行統(tǒng)計(jì)增刪行刪除代碼增加行數(shù)刪除行數(shù)自上而下“變化計(jì)數(shù)器”系統(tǒng)文件比較預(yù)處理增加代碼結(jié)果處理統(tǒng)計(jì)自下而上“變化計(jì)數(shù)器”系統(tǒng)文件比較預(yù)處理增加代碼結(jié)果處理統(tǒng)計(jì)總行標(biāo)記修改記錄修改版本比較找出增刪行統(tǒng)計(jì)增刪行刪除代碼增加行數(shù)刪除行數(shù)自下而上“變化計(jì)數(shù)器”系統(tǒng)文件比較預(yù)處理增加代碼結(jié)果處理統(tǒng)計(jì)確認(rèn)并分解項(xiàng)目的組成要素確定分解標(biāo)準(zhǔn)確定分解是否詳細(xì)確定項(xiàng)目交付成果驗(yàn)證分解的正確性(建立編號(hào))任務(wù)結(jié)構(gòu)分解(WBS)步驟確認(rèn)并分解項(xiàng)目的組成要素任務(wù)結(jié)構(gòu)分解(WBS)步驟WBS編號(hào)系統(tǒng)系統(tǒng)1子系統(tǒng)2子系統(tǒng)3子系統(tǒng)1.2模塊1.3模塊1.1模塊2.2模塊3.3模塊2.1模塊2.3模塊3.1模塊3.2模塊WBS編號(hào)系統(tǒng)系統(tǒng)1子系統(tǒng)2子系統(tǒng)3子系統(tǒng)1.2模塊1.3WBS任務(wù)名稱工期開始時(shí)間完成時(shí)間1項(xiàng)目計(jì)劃6工作日2010年3月8日2010年3月13日2軟件開發(fā)44工作日2010年3月15日2010年5月8日2.1需求分析6工作日2010年3月15日2010年3月20日2.2總體設(shè)計(jì)9工作日2010年3月22日2010年3月31日2.3詳細(xì)設(shè)計(jì)9工作日2010年4月1日2010年4月13日2.4應(yīng)用程序編碼18工作日2010年4月14日2010年5月6日2.5驅(qū)動(dòng)程序編碼30工作日2010年3月29日2010年5月6日2.6軟件測(cè)試18工作日2010年4月14日2010年5月6日2.7軟件審核2工作日2010年5月7日2010年5月8日3機(jī)構(gòu)設(shè)計(jì)7工作日2010年3月18日2010年3月25日4硬件設(shè)計(jì)49工作日2010年3月15日2010年5月14日4.1硬件前期工作12工作日2010年3月15日2010年3月27日4.2原理圖6工作日2010年3月15日2010年3月20日4.2.1原理圖設(shè)計(jì)5工作日2010年3月15日2010年3月19日4.2.2原理圖審核1個(gè)工作日2010年3月20日2010年3月20日4.3PCB21工作日2010年3月26日2010年4月21日4.3.1PCB畫圖和封裝10工作日2010年3月29日2010年4月10日4.3.2PCB與機(jī)構(gòu)溝通10工作日2010年3月26日2010年4月8日4.3.3BOM表4工作日2010年3月29日2010年4月1日4.3.4BOM器件采購(gòu)12工作日2010年4月2日2010年4月17日4.3.5PCB制版采購(gòu)7工作日2010年4月14日2010年4月21日4.4電路板制作10工作日2010年4月22日2010年5月5日4.4.1SMT5工作日2010年4月22日2010年4月27日4.4.2電路板焊接4工作日2010年4月28日2010年5月4日4.4.3電路板測(cè)試1個(gè)工作日2010年5月5日2010年5月5日4.5軟硬件集成4工作日2010年5月10日2010年5月13日4.6產(chǎn)品初期驗(yàn)收1個(gè)工作日2010年5月14日2010年5月14日WBS任務(wù)名稱工期開始時(shí)間完成時(shí)間1項(xiàng)目計(jì)劃6工作日201WBS與OBS（組織分解結(jié)構(gòu)）WBS與OBS（組織分解結(jié)構(gòu)）學(xué)生管理系統(tǒng)分解標(biāo)準(zhǔn)規(guī)劃需求設(shè)計(jì)編碼測(cè)試提交按照生存期分解：按照產(chǎn)品組成分解：1.1招生管理1.2分班管理1.3學(xué)生檔案管理1.4學(xué)生成績(jī)管理分解標(biāo)準(zhǔn)要統(tǒng)一，不能同時(shí)使用兩種標(biāo)準(zhǔn)進(jìn)行分解學(xué)生管理系統(tǒng)分解標(biāo)準(zhǔn)規(guī)劃按照生存期分解：按照產(chǎn)品組成分解：1最底層的要素是否是實(shí)現(xiàn)目標(biāo)的充分必要條件最底層要素是否有重復(fù)的每個(gè)要素是否清晰完整定義最底層要素是否有定義清晰的責(zé)任人,是否可以進(jìn)行成本估算和進(jìn)度安排檢驗(yàn)分解結(jié)果的標(biāo)準(zhǔn)最底層的要素是否是實(shí)現(xiàn)目標(biāo)的充分必要條件檢驗(yàn)分解結(jié)果的標(biāo)準(zhǔn)WBS分解的規(guī)模和數(shù)量因項(xiàng)目而異、因項(xiàng)目經(jīng)理而異收集與項(xiàng)目相關(guān)的所有信息參看一下類似的項(xiàng)目的WBS,與相關(guān)人員討論可以參照模板最低層是可控的和可管理的，但是避免不必要的過細(xì)，最好不要超過7層，軟件項(xiàng)目推薦分解到40小時(shí)的任務(wù)每個(gè)Workpackage必須有一個(gè)提交物定義任務(wù)完成的標(biāo)準(zhǔn)每個(gè)WBS必須有利于責(zé)任分配可以準(zhǔn)備WBS的字典最后與相關(guān)人員進(jìn)行評(píng)審WBS指南WBS分解的規(guī)模和數(shù)量因項(xiàng)目而異、因項(xiàng)目經(jīng)理而異WBS指南WBS字典內(nèi)容WBS編號(hào)：名稱：主題目標(biāo)：描述：完成的任務(wù)：責(zé)任者：完成的標(biāo)識(shí)：備注：WBS字典內(nèi)容WBS編號(hào)：名稱：主題目標(biāo)：描述：完成的任務(wù)：提供了項(xiàng)目范圍基線,是范圍變更的重要輸入為評(píng)估和分配任務(wù)提供具體的工作包進(jìn)行估算和編制項(xiàng)目進(jìn)度的基礎(chǔ)對(duì)整個(gè)項(xiàng)目成功的集成和控制起到非常重要的作用WBS意義提供了項(xiàng)目范圍基線,是范圍變更的重要輸入WBS意義網(wǎng)管系統(tǒng)（圖表）分解實(shí)例FF1配置管理F2故障管理F3安全管理F4性能管理F3.2F3.3F3.1F3.4F4.2F4.3F4.5F4.6F4.7F4.4F4.1F4.7.1F4.7.2網(wǎng)管系統(tǒng)（圖表）分解實(shí)例FF1F2F3F4F3.2F3.3F標(biāo)識(shí)項(xiàng)模塊說明F1.1獲取網(wǎng)絡(luò)資源數(shù)據(jù)F1.2將資源數(shù)據(jù)存入數(shù)據(jù)庫F1.3獲取網(wǎng)絡(luò)資源信息F1.4觀察網(wǎng)絡(luò)資源F1.4.1依類型分類觀察網(wǎng)絡(luò)資源F1.4.2依狀態(tài)分類觀察網(wǎng)絡(luò)資源F1.5觀察邏輯網(wǎng)F1.6觀察資源狀態(tài)F1.7修改網(wǎng)絡(luò)資源的狀態(tài)F1.8依條件檢驗(yàn)網(wǎng)絡(luò)使用情況F1.9顯示拓?fù)鋱DF1.10建立通道標(biāo)識(shí)項(xiàng)模塊說明F1.1獲取網(wǎng)絡(luò)資源數(shù)據(jù)F1.2將資源數(shù)據(jù)存入GeorgeandMartha計(jì)劃與家人和朋友舉行一次特殊的野餐活動(dòng),以慶祝Martha的升職和他們35周年的結(jié)婚紀(jì)念.Martha是工程師,George是會(huì)計(jì).他們有兩個(gè)非?；顫姷拇_孩子,Mary13歲,Thomas17歲.經(jīng)過過去幾年的發(fā)展,家里不斷壯大,無論是時(shí)間和金錢上的需要都在增加,所以他們已經(jīng)逐漸成為非常好的計(jì)劃能手,最近他們又通過了PMP的認(rèn)證考試,所以他們非常清楚對(duì)于這樣野餐活動(dòng)也需要開發(fā)一個(gè)WBS.WBS實(shí)例GeorgeandMartha一次野餐會(huì)GeorgeandMartha計(jì)劃與家人和朋友舉行一次特序號(hào)任務(wù)持續(xù)時(shí)間工作人員1開始02做冰茶15George3準(zhǔn)備三明治10Martha4準(zhǔn)備水果2Martha5準(zhǔn)備籃子2Martha6收拾毛毯2George7收拾運(yùn)動(dòng)服3Martha8裝車4George9加油6George10開車去野餐營(yíng)地20Martha11結(jié)束0序號(hào)任務(wù)持續(xù)時(shí)間工作人員1開始02做冰茶15George3準(zhǔn)需求確認(rèn)需求變更控制WBS四、案例分析“校務(wù)通系統(tǒng)”項(xiàng)目任務(wù)分解需求確認(rèn)四、案例分析“校務(wù)通系統(tǒng)”項(xiàng)目任務(wù)分解第二篇項(xiàng)目計(jì)劃第2章范圍計(jì)劃軟件需求管理任務(wù)分解定義任務(wù)分解的類型任務(wù)分解的過程案例分析第二篇項(xiàng)目計(jì)劃第2章范圍計(jì)劃軟件需求管理范圍計(jì)劃進(jìn)度計(jì)劃成本計(jì)劃核心三計(jì)劃——成本基準(zhǔn)，進(jìn)度基準(zhǔn)一、軟件需求管理軟件需求需求是指用戶對(duì)軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，達(dá)到什么性能。范圍計(jì)劃核心三計(jì)劃——成本基準(zhǔn)，進(jìn)度基準(zhǔn)一、軟件需求管理軟軟件需求的層次業(yè)務(wù)需求用戶需求功能需求系統(tǒng)需求非功能性需求質(zhì)量特性約束和假設(shè)軟件需求規(guī)格軟件需求的層次業(yè)務(wù)需求用戶需求功能需求系統(tǒng)需求非功能性需求質(zhì)需求管理的重要性需求管理的重要性項(xiàng)目失敗的原因分析No.Top10FactorsAVG1Inadequaterequirementsspecification4.52Changesinrequirements4.33Shortageofsystemsengineers4.24Shortageofsoftwaremanagers4.15Shortageofqualifiedprojectmanagers4.16Shortageofsoftwareengineers3.97Fixed

-pricecontract3.88Inadequatecommunicationsforsystemintegration3.89Insufficientexperienceasteam3.610Shortageofapplicationdomainexperts3.6Scale:5=VerySerious3=Serious1=NoSeriousSource:Carnegie-MellonUniversity,SoftwareEngineeringInstitute項(xiàng)目失敗的原因分析No.Top10FactorsAVG1需求工程是指應(yīng)用工程化的方法、技術(shù)和規(guī)格來開發(fā)和管理軟件的需求。需求工程需求工程的目標(biāo)是獲取高質(zhì)量的軟件需求。以系統(tǒng)化、條理化、可重復(fù)的方法和技術(shù)進(jìn)行與需求相關(guān)的活動(dòng)，從而提高需求活動(dòng)和過程的可管理性，降低需求開發(fā)和管理的成本。需求工程分為需求開發(fā)和需求管理。需求工程是指應(yīng)用工程化的方法、技術(shù)和規(guī)格來開發(fā)和管理軟件的需需求工程需求管理需求開發(fā)需求獲取需求分析需求規(guī)格說明需求驗(yàn)證變更管理需求工程過程需求工程需求管理需求開發(fā)需求獲取需求分析需求規(guī)格說明需求驗(yàn)證需求獲取階段的任務(wù)可能是軟件開發(fā)中最困難、最關(guān)鍵、最易出錯(cuò)和最需要交流的活動(dòng)。需求獲取用戶要求

擴(kuò)展需求基線需求軟件需求目的是從宏觀上把握用戶的具體需求方向和趨勢(shì)，了解現(xiàn)有的組織架構(gòu)、業(yè)務(wù)流程、軟硬件環(huán)境、現(xiàn)有運(yùn)行系統(tǒng)等具體情況和客觀信息。需求獲取階段的任務(wù)可能是軟件開發(fā)中最困難、最關(guān)鍵、最易出錯(cuò)和需求獲取過程確定需求計(jì)劃確定項(xiàng)目范圍確定調(diào)查對(duì)象收集用戶需求確定非功能性需求和約束條件需求獲取需要從用戶提供的大量信息中分析和理解用戶的真正需求(做什么)，而應(yīng)剔除實(shí)現(xiàn)方式(怎么做)。需求獲取過程確定需求計(jì)劃確定項(xiàng)目范圍確定調(diào)查對(duì)象收集用戶需求需求分析需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模型(邏輯模型)，是對(duì)需求系統(tǒng)地抽象描述。需求分析的基本任務(wù)是分析和綜合已收集到的信息，在于透過現(xiàn)象看本質(zhì)，找出需求信息之間的內(nèi)在聯(lián)系和可能的矛盾，提煉、分析和仔細(xì)審查已收集到的需求信息，找出真正系統(tǒng)的需求，以確保項(xiàng)目相關(guān)人員對(duì)需求都有唯一的理解。需求分析建立的邏輯模型反應(yīng)的是業(yè)務(wù)運(yùn)作流程，而不是技術(shù)開發(fā)流程。需求分析需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模型(邏需求分析模型當(dāng)前系統(tǒng)物理模型邏輯模型目標(biāo)系統(tǒng)物理模型邏輯模型模型化抽象化例化具體化導(dǎo)出理解需求表達(dá)需求需求分析模型當(dāng)前系統(tǒng)物理模型邏輯模型目標(biāo)系統(tǒng)物理模型邏輯模型需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)范的需求規(guī)格說明書。需求規(guī)格需求規(guī)格說明書的編制是為了使用戶和軟件開發(fā)者雙方對(duì)該軟件的初始規(guī)定有一個(gè)共同的理解，使之成為整個(gè)開發(fā)工作的基礎(chǔ)。需求規(guī)格說明書是需求工程的最終輸出，以文檔的形式確定用戶需求和邏輯模型。1）需求規(guī)格是軟件設(shè)計(jì)和實(shí)現(xiàn)的基礎(chǔ)；2）需求規(guī)格是測(cè)試和驗(yàn)收的重要依據(jù)；3）需求規(guī)格為軟件維護(hù)提供重要信心。需求分析工作完成的一個(gè)基本標(biāo)志是形成了一份完整的、規(guī)范的需求1）正確性：所有需求規(guī)格的說明應(yīng)在開發(fā)中滿足；2）一致性：信息在需求規(guī)格描述一致，不發(fā)生矛盾；3）功能性：從實(shí)現(xiàn)中分離功能，即描述要“做什么”而不是“怎樣實(shí)現(xiàn)”；4）規(guī)范性：采用一定的規(guī)格說明語言，無二義性；5）完整性：如果被開發(fā)軟件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格說明的描述之中；6）可行性：規(guī)格說明應(yīng)該包括系統(tǒng)運(yùn)行環(huán)境；7）抽象性：規(guī)格說明應(yīng)該是一個(gè)認(rèn)識(shí)模型；8）開放型：規(guī)格說明應(yīng)該容許不完備性并允許擴(kuò)充。軟件需求規(guī)格的原則1）正確性：所有需求規(guī)格的說明應(yīng)在開發(fā)中滿足；軟件需求規(guī)格的規(guī)格文檔參考1.引言2.5設(shè)計(jì)限制1.1目的2.6

假設(shè)和依賴1.2文檔約定3.

需求規(guī)格1.3預(yù)期讀者3.1功能需求1.4

產(chǎn)品范圍3.2邏輯模型1.5參考文獻(xiàn)3.3數(shù)據(jù)字典2.項(xiàng)目概述3.4性能需求2.1項(xiàng)目背景3.5安全性需求2.2項(xiàng)目目標(biāo)3.6接口需求2.3用戶類3.7其他需求2.4運(yùn)行環(huán)境附錄規(guī)格文檔參考1.引言2.5設(shè)計(jì)限制1.1目的2.6需求是正確的嗎？需求是一致的嗎？需求是完全的嗎？需求是實(shí)際可行的嗎？需求是必要的嗎？需求是可檢驗(yàn)的嗎？需求是可跟蹤的嗎？最后的簽字需求驗(yàn)證需求是正確的嗎？需求驗(yàn)證1）控制對(duì)需求規(guī)格基準(zhǔn)的變動(dòng)；2）保持項(xiàng)目計(jì)劃與需求的一致；3）控制單個(gè)需求的更改；4）管理需求、需求之間的聯(lián)系以及需求與設(shè)計(jì)的關(guān)系；5）跟蹤需求變更的狀態(tài)。需求管理需求管理是為有效地控制和管理需求變更等所進(jìn)行的活動(dòng)。需求管理的主要任務(wù)就是在開發(fā)人員在與提出更改的請(qǐng)求者協(xié)商的基礎(chǔ)上，評(píng)估需求變更帶來的潛在影響及其可能的成本和費(fèi)用，然后實(shí)施更改，以及有效地管理需求規(guī)格說明書和跟蹤更改需求的狀態(tài)。1）控制對(duì)需求規(guī)格基準(zhǔn)的變動(dòng)；需求管理需求管理是為有效地控制確定需求變更控制過程建立變更控制委員會(huì)(SCCB)進(jìn)行需求變更影響分析跟蹤所有受需求變更影響的工作產(chǎn)品建立需求基準(zhǔn)版本和需求控制版本文檔維護(hù)需求變更的歷史記錄跟蹤每項(xiàng)需求的狀態(tài)衡量需求穩(wěn)定性管理和控制需求基線的過程需求變更控制系統(tǒng)一個(gè)正式的文檔，說明如何控制需求變更建立變更審批系統(tǒng)需求變更控制確定需求變更控制過程需求變更控制變更申請(qǐng)需求方開發(fā)方忽略選擇變更方式SCCB評(píng)估項(xiàng)目經(jīng)理自行決定評(píng)估結(jié)果拒絕接受本次修改下個(gè)版本再修改修改合同相關(guān)信息修改相關(guān)需求修改相應(yīng)的項(xiàng)目計(jì)劃變更申請(qǐng)需求方開發(fā)方忽略選擇變更方式SCCB評(píng)估項(xiàng)目經(jīng)理自行軟件基線產(chǎn)品修改申請(qǐng)單申請(qǐng)人張三申請(qǐng)日期2010-03-24項(xiàng)目名稱軟件項(xiàng)目管理系統(tǒng)階段名稱系統(tǒng)設(shè)計(jì)文件名稱RCR-PM-01.doc,RCR-PM-02.doc修改內(nèi)容1）修改測(cè)試流程控制：將2個(gè)角色，3個(gè)渠道流，改為3個(gè)角色，4個(gè)渠道流，詳見RCR-PM-01.doc2）增加開發(fā)人員技能信息庫管理，詳見RCR-PM-02.doc驗(yàn)證意見同意RCR-PM-01.doc變更。RCR-PM-02.doc的變更可以推遲到下一個(gè)版本實(shí)施驗(yàn)證人李四驗(yàn)證日期2010-03-30SCCB李四，王五，趙六填表人張三軟件基線產(chǎn)品修改申請(qǐng)單申請(qǐng)人張三申請(qǐng)日期2010-03-24需求跟蹤是指編制每個(gè)需求與系統(tǒng)元素之間的聯(lián)系(可跟蹤信息)的文檔，其中系統(tǒng)元素包括：其他需求、體系結(jié)構(gòu)、設(shè)計(jì)部件、測(cè)試文檔等。需求跟蹤可跟蹤信息分類：需求-源可跟蹤性：與說明該需求的人或文檔連接；需求-理由可跟蹤性：和理由描述連接；需求-需求可跟蹤性：和依賴于該需求的需求連接；需求-體系結(jié)構(gòu)可跟蹤性：與實(shí)現(xiàn)系統(tǒng)連接；需求-設(shè)計(jì)可跟蹤性：與特定組件連接；需求-界面可跟蹤性：與外部系統(tǒng)界面連接。需求跟蹤是指編制每個(gè)需求與系統(tǒng)元素之間的聯(lián)系(可跟蹤信息)的二、任務(wù)分解定義Workpackages：WBS的最低層次的可交付成果WBS(WorkBreakdownStructure)任務(wù)分解的過程：將一個(gè)項(xiàng)目分解為更多的工作細(xì)目或者子項(xiàng)目，使項(xiàng)目變得更小、更易管理、更易操作。任務(wù)分解的結(jié)果：WBS（任務(wù)分解結(jié)構(gòu)）。WBS：面向可交付成果的。二、任務(wù)分解定義Workpackages：WBS的最低層WBS實(shí)例系統(tǒng)子系統(tǒng)子系統(tǒng)子系統(tǒng)模塊模塊模塊模塊模塊模塊模塊模塊模塊WBS實(shí)例系統(tǒng)子系統(tǒng)子系統(tǒng)子系統(tǒng)模塊模塊模塊模塊模塊模塊是面向可交付成果的對(duì)項(xiàng)目元素的分組，組織并定義了整個(gè)項(xiàng)目范圍，不在WBS中的工作就不是該項(xiàng)目的工作是一個(gè)分級(jí)的樹型結(jié)構(gòu)，是對(duì)項(xiàng)目由粗到細(xì)的分解過程。工作結(jié)構(gòu)每細(xì)分一個(gè)層次表示對(duì)項(xiàng)目元素更細(xì)致的描述WBS定義WBS的最低層次的可交付成果工作包應(yīng)當(dāng)由唯一主體負(fù)責(zé)這一交付成果可以分配給另外一位項(xiàng)目經(jīng)理進(jìn)行計(jì)劃和執(zhí)行,或者通過子項(xiàng)目的方式完成Workpackages定義是面向可交付成果的對(duì)項(xiàng)目元素的分組，組織并定義了整個(gè)項(xiàng)目范圍三、任務(wù)分解的類型圖表類型“變化計(jì)數(shù)器”系統(tǒng)版本比較找出增刪行統(tǒng)計(jì)增刪行統(tǒng)計(jì)總行標(biāo)記修改記錄修改預(yù)處理文件比較結(jié)果處理增加代碼刪除代碼增加行數(shù)刪除行數(shù)三、任務(wù)分解的類型圖表類型“變化計(jì)數(shù)器”系統(tǒng)版本找出統(tǒng)計(jì)統(tǒng)計(jì)清單類型1.

變化計(jì)數(shù)器

1.1

比較兩個(gè)版本的程序1.1.1

預(yù)處理1.1.2

文件比較1.1.3

結(jié)果處理1.2找出修改后的程序中增加和刪除的代碼行1.2.1

找出增加的代碼行1.2.2

找出刪除的代碼行1.3

統(tǒng)計(jì)修改后的程序中增加和刪除的代碼行數(shù)1.3.1

統(tǒng)計(jì)增加代碼行數(shù)1.3.2

統(tǒng)計(jì)刪除代碼行數(shù)1.4

統(tǒng)計(jì)總的代碼行數(shù)

1.5

設(shè)定標(biāo)記以指示修改的次數(shù)1.6

在程序的頭部增加修改紀(jì)錄清單類型1.

變化計(jì)數(shù)器三、任務(wù)分解的方法參照具有類比性的項(xiàng)目(具有相同或相似的周期和工作細(xì)目要求)的WBS。類比模板使用應(yīng)用領(lǐng)域內(nèi)標(biāo)準(zhǔn)或半標(biāo)準(zhǔn)的WBS作為模板參考使用。與類比所參照的WBS不同，模板更具有抽象性，在任務(wù)分解時(shí)需根據(jù)指導(dǎo)說明來開發(fā)項(xiàng)目的WBS。三、任務(wù)分解的方法參照具有類比性的項(xiàng)目(具有相同或相似的周期第2章軟件項(xiàng)目范圍計(jì)劃自上而下“變化計(jì)數(shù)器”系統(tǒng)文件比較預(yù)處理增加代碼結(jié)果處理統(tǒng)計(jì)總行標(biāo)記修改記錄修改版本比較找出增刪行統(tǒng)計(jì)增刪行刪除代碼增加行數(shù)刪除行數(shù)自上而下“變化計(jì)數(shù)器”系統(tǒng)文件比較預(yù)處理增加代碼結(jié)果處理統(tǒng)計(jì)自下而上“變化計(jì)數(shù)器”系統(tǒng)文件比較預(yù)處理增加代碼結(jié)果處理統(tǒng)計(jì)總行標(biāo)記修改記錄修改版本比較找出增刪行統(tǒng)計(jì)增刪行刪除代碼增加行數(shù)刪除行數(shù)自下而上“變化計(jì)數(shù)器”系統(tǒng)文件比較預(yù)處理增加代碼結(jié)果處理統(tǒng)計(jì)確認(rèn)并分解項(xiàng)目的組成要素確定分解標(biāo)準(zhǔn)確定分解是否詳細(xì)確定項(xiàng)目交付成果驗(yàn)證分解的正確性(建立編號(hào))任務(wù)結(jié)構(gòu)分解(WBS)步驟確認(rèn)并分解項(xiàng)目的組成要素任務(wù)結(jié)構(gòu)分解(WBS)步驟WBS編號(hào)系統(tǒng)系統(tǒng)1子系統(tǒng)2子系統(tǒng)3子系統(tǒng)1.2模塊1.3模塊1.1模塊2.2模塊3.3模塊2.1模塊2.3模塊3.1模塊3.2模塊WBS編號(hào)系統(tǒng)系統(tǒng)1子系統(tǒng)2子系統(tǒng)3子系統(tǒng)1.2模塊1.3WBS任務(wù)名稱工期開始時(shí)間完成時(shí)間1項(xiàng)目計(jì)劃6工作日2010年3月8日2010年3月13日2軟件開發(fā)44工作日2010年3月15日2010年5月8日2.1需求分析6工作日2010年3月15日2010年3月20日2.2總體設(shè)計(jì)9工作日2010年3月22日2010年3月31日2.3詳細(xì)設(shè)計(jì)9工作日2010年4月1日2010年4月13日2.4應(yīng)用程序編碼18工作日2010年4月14日2010年5月6日2.5驅(qū)動(dòng)程序編碼30工作日2010年3月29日2010年5月6日2.6軟件測(cè)試18工作日2010年4月14日2010年5月6日2.7軟件審核2工作日2010年5月7日2010年5月8日3機(jī)構(gòu)設(shè)計(jì)7工作日2010年3月18日2010年3月25日4硬件設(shè)計(jì)49工作日2010年3月15日2010年5月14日4.1硬件前期工作12工作日2010年3月15日2010年3月27日4.2原理圖6工作日2010年3月15日2010年3月20日4.2.1原理圖設(shè)計(jì)5工作日2010年3月15日2010年3月19日4.2.2原理圖審核1個(gè)工作日2010年3月20日2010年3月20日4.3PCB21工作日2010年3月26日2010年4月21日4.3.1PCB畫圖和封裝10工作日2010年3月29日2010年4月10日4.3.2PCB與機(jī)構(gòu)溝通10工作日2010年3月26日2010年4月8日4.3.3BOM表4工作日2010年3月29日2010年4月1日4.3.4BOM器件采購(gòu)12工作日2010年4月2日2010年4月17日4.3.5PCB制版采購(gòu)7工作日2010年4月14日2010年4月21日4.4電路板制作10工作日2010年4月22日2010年5月5日4.4.1SMT5工作日2010年4月22日2010年4月27日4.4.2電路板焊接4工作日2010年4月28日2010年5月4日4.4.3電路板測(cè)試1個(gè)工作日2010年5月5日2010年5月5日4.5軟硬件集成4工作日2010年5月10日2010年5月13日4.6產(chǎn)品初期驗(yàn)收1個(gè)工作日2010年5月14日2010年5月14日WBS任務(wù)名稱工期開始時(shí)間完成