項目策劃及需求分析課件

1、項目策劃及需求分析經(jīng)驗交流提綱項目策劃（35分鐘）需求分析（35分鐘）討論（20分鐘）項目策劃項目策劃的重要性項目策劃相關內容項目策劃參考案例項目策劃的重要性從軟件實施成功率談起軟件項目成功率調查結果怎樣才算是一個成功的項目？項目策劃的重要性W理論Every stakeholder（涉眾 ） is a winner（獲勝者）客戶、用戶、項目經(jīng)理、開發(fā)者、維護者、軟件企業(yè)相關人員。項目策劃的重要性項目成功的十大關鍵因素中第一位： 清楚地界定項目范圍及制定項目計劃從項目管理角度：三個階段項目策劃的重要性一個完善的項目計劃 可以使失敗的概率降到最低，以最大限度的保證在預期的期限內取得預期的效果項目策

2、劃的重要性項目策劃項目策劃的重要性項目策劃相關內容項目策劃參考案例項目策劃內容軟件質量保證需求項目過程活動軟件配置管理項目管理分析實現(xiàn)測試交付項目策劃相關內容為什么要制定項目開發(fā)計劃？計劃趕不上變化？沒有充足的條件制定可行的計劃？計劃變更是合理的；關鍵在于如何使變更可控；結論：計劃變更是在正常不過的項目策劃相關內容誰來制定項目計劃？結論：計劃應由所有的涉眾制定項目策劃相關內容制定幾份項目計劃？結論：兩個協(xié)調的計劃并行；項目策劃相關內容項目策劃項目策劃的重要性項目策劃相關內容項目策劃參考案例項目策劃策劃前策劃中策劃后定義項目目標a、項目可交付的結果列表b、制定項目最終完成及中間里程碑的截至日期c

3、、交付結果必須滿足的質量準則d、項目不能超過的成本限制項目策劃定義項目前提a、項目是否依賴其他人員；b、項目是否有其所需的資源；c、成本對項目多重要，誰有權增加項目預算；d、項目的風險是否基本可控；項目策劃項目策劃策劃前策劃中策劃后選擇軟件開發(fā)過程模型項目策劃系統(tǒng)分析軟件需求分析設計編碼測試Full SystemIncrement 1Increment 2Increment 3瀑布模型增量模型螺旋模型RAD模型RUP項目策劃軟件開發(fā)過程模型軟件開發(fā)過程對客戶是個黑匣子項目策劃讓客戶加入到軟件過程中來，認識我們地軟件開發(fā)過程模型 軟件企業(yè)成熟，必須引導要求客戶成熟資源、工作量、進度、及成本估算相

4、關案例見下文項目策劃安排進度、確定里程碑項目策劃結論： 確定里程碑、快速實現(xiàn)階段成果，增加成就感，凝聚力，提高客戶滿意度，客戶分配資源、商討承諾項目策劃項目策劃策劃前策劃中策劃后計劃的執(zhí)行，及對計劃的執(zhí)行做出反饋；交流溝通的重要性；項目計劃要不斷展開和修正；項目策劃項目策劃項目策劃的重要性項目策劃相關內容項目策劃參考案例參考案例過程相似，結果截然不同的案例我們又是怎么做的？一、前提條件二、引言三、問題提出四、從軟件過程看“需求”五、需求文檔的書寫前提條件在這里只討論需求的開發(fā)需求管理（如基線）都不在討論之列引言方法論本身源于實踐方法論沒有絕對的真理，只有絕對的實際方法論限于環(huán)境，不同的環(huán)境有不

5、同的方法論！方法論不能絕對對的遵循，我們要學會了解方法論、優(yōu)化方法論，才能更好的為我們服務問題提出的開發(fā)中，特別是基礎套件的開發(fā)過程中，我們不得不再次思考以下幾個問題： 什么是軟件需求？ 需求文檔中應該有那些內容？ 需求寫到什么程度？ 從軟件過程看需求自上而下、逐步求精獲取市場或用戶需要或潛在需要了解具體使用者習慣和業(yè)務定義軟件的功能、展現(xiàn)方式及性能要求對軟件內部結構的設計程序設計及代碼編寫發(fā)布需求需求設計設計不同的組織對它的范圍有不同的解釋什么是“需求”I E E E軟件工程標準詞匯表（ 1 9 9 7年）中定義需求為：（1）用戶解決問題或達到目標所需的條件或權能（ C a p a b i

6、l i t y）。（2）系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權能。（3）一種反映上面（1）或（2）所描述的條件或權能的文檔說明。什么是“需求”實際上我們認為“需求”這個詞匯是個相對概念對需求的理解和范圍劃分要從涉眾是誰來看待 如，對開發(fā)人員來說的“需求”對于客戶而言就是“設計”寫好需求的前提做好需求的前提是，讓同一個團隊對“需求”的理解達成共識需求的三個層次業(yè)務需求用戶需求功能需求功能需求規(guī)格說明書在開發(fā)中我們認為需求有三個層次問題焦點我們要為設計或開發(fā)人員提供一份什么樣的 功能需求規(guī)格說明書？編寫需求是軟件開發(fā)過程中最難的嗎？需求的重要性有一點可以肯定：設計

7、和編寫代碼的代價是遠遠大于編寫各種需求文檔的代價。編寫各種需求文檔這里將著重討論功能需求規(guī)格說明書何時產(chǎn)生詳細的？我們能不能在需求階段提供詳細的？編寫各種需求文檔基本要求： 明確需求不是設計：需求強調的是產(chǎn)品是怎樣，而不是產(chǎn)品是怎樣設計和構造。描寫功能需求的時候應把系統(tǒng)或子系統(tǒng)看作是黑盒，描述他的響應和行為。而黑盒內部相關的結構和工作原理應留給開發(fā)人員去設計。如，軟件部件相關的格式，存儲應該由設計實現(xiàn)。編寫各種需求文檔定義：軟件的功能及是對用戶各種需求的抽象不同的軟件功能對事物的抽象層度不同，所以在需求階段描述的詳細度可能不同一、分清項目類型1、定制化項目（定制MIS)2、產(chǎn)品開發(fā)類項目3、技

8、術研究類項目1、定制化項目（定制MIS)簡單的抽象（某一個業(yè)務）業(yè)務需求：如文檔、文檔用戶需求:如功能需求:如需求說明書和概要設計有些類似2、技術研究類項目高層次抽象（某一類基礎技術）需要有大量的業(yè)務分析，理論研究，技術實驗，才能規(guī)劃出其功能。同時需求來源不是用戶，而是開發(fā)者或開發(fā)商。在需求階段只能描述出要做什么樣的事，而無法直接提出什么樣的軟件功能來完成什么事。所以在需求中只能描述其特性和技術指標具體的軟件功能則不涉及前提條件、其主要描述描述市場前景、商業(yè)模式、潛在收入、定價、成本、合同、銷售方式等等 如大量的場景描述初步版本迭帶次數(shù)更多很多開發(fā)產(chǎn)品的公司對功能的設計一般是在設計階段進行如易

9、用性設計之后才能確定功能需求歸和說明書3、產(chǎn)品開發(fā)類項目前提條件簡單的說： 關系到對事務認識的直接性和間接性 由功能提出和軟件功能實現(xiàn)的直接性和間接性我們來劃分那些該在需求中和設計中實現(xiàn)文檔項的部分說明例子，某字處理軟件，業(yè)務需求“用戶能有效的糾錯正文檔中的拼寫錯誤”用戶需求“找到一個文檔中的單詞錯誤，并提供一個錯誤列表，用戶可以通過該列表進行替換單詞 功能需求“拼寫檢查器，高亮度提示錯誤詞，替換對話框進行替換操作，與錯詞最相進的單詞列表顯示”設計則可能是描述實現(xiàn)以上功能，程序要怎么架構如要實現(xiàn)語法分析器，詞匯緩沖池、詞匯檢索引擎，單詞分析器，錯誤類比引擎，高亮顯示等等，以及更細粒度的劃分和設

10、計”。文檔項的部分說明 業(yè)務需求：描述提供給客戶和產(chǎn)品開發(fā)商的新系統(tǒng)的最初利益,反映了組織機構或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求業(yè)務流程描述及分析，軟件處理描述。用戶需求：獲取和描述了用戶使用產(chǎn)品必須要完成的任務。功能需求：功能需求定義了開發(fā)人員必須實現(xiàn)的軟件功能,舉IEEE的一個例子。根據(jù)不同項目，對功能需求的細化程度不同*：與數(shù)據(jù)模型之間的差別,數(shù)據(jù)字典只是描述業(yè)務過程相關的數(shù)據(jù)項目，而非具體軟件開發(fā)時的數(shù)據(jù)庫模型需求優(yōu)先級每項需求必須用優(yōu)先級進行排序對于產(chǎn)品，我們要規(guī)劃其長遠特性，并對哪些是下一版本實現(xiàn)的做出標識需求迭代和分包對于大系統(tǒng)需求是一個迭代的過程。我們不能簡單的把需求分為客戶需

11、求和功能需求，我們要注意的是我們的需求分析的過程，分析過程是一種方法論，過程的好壞直接影響到最終需求的質量。所以大項目的需求會劃分多個階段，每個階段需求分析的層次不同細致層度不同，是一種自上而下逐步求精的過程，不同的軟件項目需求的迭代次數(shù)也不盡相同。END提綱項目過程認證PDSPOSSPCMMOssp為組織及規(guī)范，pdsp為項目定義。項目管理流程范例項目管理機構范例項目策劃與跟蹤項目策劃需求管理項目跟蹤項目策劃估計：工作細分DELPHI方法簡介管理工作量估計進度及里程碑制訂風險預估估計目標估計目標：尋找估算和實際情況的交匯點合理的估計是準確的進度、有效計劃的基礎可靠估計的障礙 1、管理者/客戶

12、的壓力 2、總體確定后直接分配給項目成員 3、缺乏歷史數(shù)據(jù) 4、混亂的估計方法 5、太理想主義 6、忽視了必要的活動 7、過高的估計自己的能力 8、打折扣 9、即使完成了需求分析，對需要工作量的了解也 在50%以下軟件項目估計的波浪原則計劃在階段實施之前，每個階段都是一個“新”項目工作量和成本的估計來源于滾動的WBS元素每個成功的階段實施之后，估計將會越來越軟件項目估計方法詳細階段估計1.從下至上方法2.以WBS元素為基礎3.最好由實際做這項工作的人來估計項目初始階段：1.從上至下的項目估計2.基于項目定義、需求和高層設計3.方法：功能點、代碼行和德爾菲法工作細分前提一：軟件工程過程系統(tǒng)分析軟

13、件需求分析設計編碼測試Full SystemIncrement 1Increment 2Increment 3瀑布模型增量模型螺旋模型RAD模型工作細分前提二：識別工作產(chǎn)品Work ProductsProject Phases&ActivitiesDefinitionDesignCodingTestingSASTPSRAHLDDDITPCUTITSTDOCRELCustomer Reqts SpecXSoftware Reqts SpecXHigh-Level Design SpecXDetail Design SpecXCodeXSystem Test PlanXXIntegration T

14、est PlanXUnit Test PlanXUnit Test ReportXIntegration Test ReportXSystem Test ReportXUser Manual-PreliminaryXUser Manual-FinalXRelease NotesXInstallation TopeX工作細分（WBS）表WBS級別工作包2過程3模塊4子模塊5功能點任務描述工作產(chǎn)品技術方面管理和支持方面WBS制訂的方法和技巧1、使用過程模型作為第一層的基礎2、將第一層細分，定義低層的元素3、在詳細階段計劃時定義最后一層元素4、 最后一層元素定義完成之后，完成TDF任務描述表5、管理

15、活動也同樣技術活動一樣定義6、有些管理活動無法細分，只要有一定程度的努力即可TDF（任務描述表）責任人:所需技能:前期任務:工期:成本:時間:估計提交的產(chǎn)品:任務描述:WBS#:任務名稱:階段:項目名稱:WBS在實際項目中的使用慣例1、項目經(jīng)理負責劃分第一、二層2、應注意盡量不要遺漏測試、安裝實施、驗收等3、隨著階段計劃的開發(fā)，模塊負責人具體細化4、WBS細化后應符合2周（80小時）原則5、一般情況下項目組成員直接投入項目的時間只占70%80%，任務的評審應留出適當時間項目策劃估計：工作細分DELPHI方法簡介管理工作量估計進度及里程碑制訂風險預估DELPHI方法簡介計劃碰頭會個人準備估計會得

16、出結果完成估計是估計的一種方法2. 專家小組針對WBS或任務列表估計3. 是不記名的、記錄的、評審的和討論的估計4. 重復該過程直到達成一致意見DELPHI方法簡介第4輪第3輪第2輪第1輪50 100 150 200第4輪第3輪第2輪第1輪50 100 150 200專家討論、匿名投票，直到一致DELPHI方法簡介第4輪第3輪第2輪第1輪50 100 150 200第4輪第3輪第2輪第1輪50 100 150 200專家意見不一致，則取平均值、同時記錄最好和最壞值DELPHI方法簡介多輪投票的退出條件1. 完成4輪估計2. 估計的范圍已經(jīng)聚集在一個可接受得很窄 的范圍之內3. 接近會議結束時間

17、（2小時）4. 參與者已經(jīng)不愿再進一步修改自己的估計DELPHI方法簡介WBS活動估計#1變更#1變更#2變更#3估計結果假設前提 總計：項目策劃估計：工作細分DELPHI方法簡介管理工作量估計進度及里程碑制訂風險預估管理工作量估計SQA：一般占全部技術開發(fā)量的5%SCM：一般占全部技術開發(fā)量的5%項目管理：一般占全部工作量的20%管理預留：根據(jù)項目的特點制訂，一般為20%管理工作量估計例：項目預算開發(fā)工作量1000 小時配置管理（5%） 50質量保證（5%） 50其它（培訓） 24項目管理（20%） 220 總的審定預算： 1344管理預留（20%） 270 總的項目預算： 1614 小時項

18、目策劃估計：工作細分DELPHI方法簡介管理工作量估計進度及里程碑制訂風險預估甘特圖WEEKHours12345678910Activity1Activity5Activity4Activity6Activity9Activity2Activity7Activity10Activity3Activity8網(wǎng)絡圖開始ACFDGBH結束E里程碑制訂根據(jù)WBS細分，制訂項目里程碑明確項目里程碑內應完成的WBS每個WBS有其對應的里程碑定義獲取價值（EV）曲線獲得值（EV）技術使估算成本和項目進度結合起來EV提供了一般項目活動的度量衡項目活動的價值一般用人小時成本或人天表示當活動完成之后，活動的價值才獲得了通過EV分析，對項目的成本和進度能有一個直觀的了解建立項目基線將任務預算和時間進度聯(lián)合起來360510H530G480F350E360D270C240B120A進度（周）預算時間（小時）任務估計建立項目基線將任務預算和時間進度聯(lián)合起來360510H530G480F350E360D270C240B120A進度（周）預算時間（小時）任務估計按照項目基線計算獲取價值87630I,J,K650