軟件項目范圍計劃

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

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

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

假設和依賴1.2文檔約定3.

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

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

變化計數(shù)器1.1

比較兩個版本的程序1.1.1

預處理1.1.2

文件比較1.1.3

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

找出增加的代碼行1.2.2

找出刪除的代碼行1.3

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

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

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

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

1.5

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

在程序的頭部增加修改紀錄三、任務分解的方法參照具有類比性的項目(具有相同或相似的周期和工作細目要求)的WBS。類比模板使用應用領域內(nèi)標準或半標準的WBS作為模板參考使用。與類比所參照的WBS不同，模板更具有抽象性，在任務分解時需根據(jù)指導說明來開發(fā)項目的WBS。自上而下“變化計數(shù)器”系統(tǒng)文件比較預處理增加代碼結(jié)果處理統(tǒng)計總行標記修改記錄修改版本比較找出增刪行統(tǒng)計增刪行刪除代碼增加行數(shù)刪除行數(shù)自下而上“變化計數(shù)器”系統(tǒng)文件比較預處理增加代碼結(jié)果處理統(tǒng)計總行標記修改記錄修改版本比較找出增刪行統(tǒng)計增刪行刪除代碼增加行數(shù)刪除行數(shù)確認并分解項目的組成要素確定分解標準確定分解是否詳細確定項目交付成果驗證分解的正確性(建立編號)任務結(jié)構(gòu)分解(WBS)步驟WBS編號系統(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任務名稱工期開始時間完成時間1項目計劃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總體設計9工作日2010年3月22日2010年3月31日2.3詳細設計9工作日2010年4月1日2010年4月13日2.4應用程序編碼18工作日2010年4月14日2010年5月6日2.5驅(qū)動程序編碼30工作日2010年3月29日2010年5月6日2.6軟件測試18工作日2010年4月14日2010年5月6日2.7軟件審核2工作日2010年5月7日2010年5月8日3機構(gòu)設計7工作日2010年3月18日2010年3月25日4硬件設計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原理圖設計5工作日2010年3月15日2010年3月19日4.2.2原理圖審核1個工作日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與機構(gòu)溝通10工作日2010年3月26日2010年4月8日4.3.3BOM表4工作日2010年3月29日2010年4月1日4.3.4BOM器件采購12工作日2010年4月2日2010年4月17日4.3.5PCB制版采購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電路板測試1個工作日2010年5月5日2010年5月5日4.5軟硬件集成4工作日2010年5月10日2010年5月13日4.6產(chǎn)品初期驗收1個工作日2010年5月14日2010年5月14日WBS與OBS（組織分解結(jié)構(gòu)）學生管理系統(tǒng)分解標準規(guī)劃需求設計編碼測試提交按照生存期分解：按照產(chǎn)品組成分解：1.1招生管理1.2分班管理1.3學生檔案管理1.4學生成績管理分解標準要統(tǒng)一，不能同時使用兩種標準進行分解最底層的要素是否是實現(xiàn)目標的充分必要條件最底層要素是否有重復的每個要素是否清晰完整定義最底層要素是否有定義清晰的責任人,是否可以進行成本估算和進度安排檢驗分解結(jié)果的標準WBS分解的規(guī)模和數(shù)量因項目而異、因項目經(jīng)理而異收集與項目相關的所有信息參看一下類似的項目的WBS,與相關人員討論可以參照模板最低層是可控的和可管理的，但是避免不必要的過細，最好不要超過7層，軟件項目推薦分解到40小時的任務每個Workpackage必須有一個提交物定義任務完成的標準每個WBS必須有利于責任分配可以準備WBS的字典最后與相關人員進行評審WBS指南WBS字典內(nèi)容WBS編號：名稱：主題目標：描述：完成的任務：責任者：完成的標識：備注：提供了項目范圍基線,是范圍變更的重要輸入為評估和分配任務提供具體的工作包進行估算和編制項目進度的基礎對整個項目成功的集成和控制起到非常重要的作用WBS意義網(wǎng)管系統(tǒng)（圖表）分解實例FF1配置管理F2故障管理F3安全管理F4性能管理F3.2F3.3F3.1F3.4