2軟件項目計劃過程——范圍計劃ppt課件

1、范圍方案 配置管 理方案 合同 方案 風(fēng)險 方案 溝通 方案 質(zhì)量方案 本錢 方案 時間方案 集成 方案 范圍方案 工程 終了 工程執(zhí) 行控制 工程 方案 工程初始 人力 方案 .中心三方案范圍方案進度方案本錢方案本錢基準，進度基準.軟件工程管理第2章軟件工程范圍方案.本章要點一、軟件需求管理過程二、義務(wù)分解定義三、義務(wù)分解的類型四、義務(wù)分解的過程五、案例分析.軟件需求需求是指用戶對軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，到達什么性能。.軟件需求的層次業(yè)務(wù)需求用戶需求功能需求軟件需求規(guī)格非功能性需求質(zhì)量特性約束和假設(shè)系統(tǒng)需求.工程失敗的緣由分析No. Top 1

2、0 Factors 平均值 1 Inadequate requirements specification 不充分的需求規(guī)范 4.5 2 Changes in requirements 需求的改動 4.3 3 Shortage of systems engineers 缺乏系統(tǒng)工程師 4.2 4 Shortage of software managers 缺乏了解軟件特性的經(jīng)理人 4.1 5 Shortage of qualified project managers 缺乏合格的工程經(jīng)理 4.1 6 Shortage of software engineers 缺乏軟件工程師 3.9 7 Fi

3、xed- price contract 固定價合同 3.8 8 Inadequate communications for system integration 系統(tǒng)集成階段, 交流與溝通不充分 3.8 9 Insufficient experience as team團隊缺乏閱歷 3.6 10 Shortage of application domain experts 缺乏運用領(lǐng)域?qū)＜?3.6 Scale: 5 = Very Serious 3 = Serious 1 = No Serious Source: Carnegie-Mellon University, Software Eng

4、ineering Institute.軟件需求管理過程軟件需求管理的過程需求分析編寫需求規(guī)格需求驗證需求獲取需求變卦需求確認需求變卦.需求工程根本義務(wù)需求工程需求管理需求開發(fā)需求獲取需求分析需求規(guī)格闡明需求驗證變卦管理.需求獲取用戶要求 擴展需求基線需求軟件需求.需求分析定義需求分析是為最終用戶所看到的系統(tǒng)建立一個概念模型，是對需求的籠統(tǒng)描畫。 .需求分析模型.需求規(guī)格需求分析任務(wù)完成的一個根本標志是構(gòu)成了一份完好的、規(guī)范的需求規(guī)格闡明書需求規(guī)格闡明書的編制是為了運用戶和軟件開發(fā)者雙方對該軟件的初始規(guī)定有一個共同的了解，使之成為整個開發(fā)任務(wù)的根底。.軟件需求規(guī)格闡明的原那么從現(xiàn)實中分別功能，即

5、描畫要“做什么而不是“怎樣實現(xiàn)采用一定的規(guī)格闡明言語假設(shè)被開發(fā)軟件只是一個大系統(tǒng)中的一個元素，那么整個大系統(tǒng)也包括在規(guī)格闡明的描畫之中.規(guī)格闡明應(yīng)該包括系統(tǒng)運轉(zhuǎn)環(huán)境規(guī)格闡明應(yīng)該是一個認識模型規(guī)格闡明應(yīng)該允許不完備性并允許擴展.規(guī)格文檔參考引言系統(tǒng)定義 運用環(huán)境功能規(guī)格 性能需求產(chǎn)品提交實現(xiàn)約束質(zhì)量描畫其它簽字認證.需求驗證需求是正確的嗎？需求是一致的嗎？需求是完全的嗎？需求是實踐可行的嗎？需求是必要的嗎？需求是可檢驗的嗎？需求是可跟蹤的嗎？最后的簽字.需求總在變化.需求變卦管理確定需求變卦控制過程建立變卦控制委員會(SCCB)進展需求變卦影響分析跟蹤一切受需求變卦影響的任務(wù)產(chǎn)品建立需求基準版本

6、和需求控制版本文檔維護需求變卦的歷史記錄跟蹤每項需求的形狀衡量需求穩(wěn)定性.需求變卦管理管理和控制需求基線的過程需求變卦控制系統(tǒng)一個正式的文檔，闡明如何控制需求變卦建立變卦審批系統(tǒng).變卦懇求需求方開發(fā)方忽略選擇變卦方式SCCB評價工程經(jīng)理自行決議根據(jù)評價結(jié)果回絕接受本次修正下個版本再修正修正合同相關(guān)信息修正相關(guān)需求修正相應(yīng)的工程方案.表4-3 需求變卦提交單軟件基線產(chǎn)品修正提交單懇求人韓萬江懇求日期2002。1011工程稱號工程管理系統(tǒng)階段稱號系統(tǒng)設(shè)計文件稱號RCR-PM-01.doc, RCR-PM-02.doc,變卦簡述如下修正內(nèi)容1修正測試流程控制：將2個角色，3個渠道流，改為3個角色，4

7、個渠道流，詳見RCR-PM-01.doc2添加開發(fā)人員技藝信息庫管理，詳見RCR-PM-02.doc驗證意見贊同RCR-PM-01.doc變卦。RCR-PM-02.doc的變卦可以推遲到下一個版本實施驗證人楊炎泰驗證日期20021011SCCB韓萬江，姜岳尊，孫泉 填表人韓萬江.本章要點一、軟件需求管理過程二、義務(wù)分解定義三、義務(wù)分解的類型四、義務(wù)分解的方法五、案例分析.WBS (Work Breakdown Structure)義務(wù)分解的過程將一個工程分解為更多的任務(wù)細目或者子工程，使工程變得更小、更易管理、更易操作。義務(wù)分解的結(jié)果WBS義務(wù)分解構(gòu)造。 WBS面向可交付成果的。.WBS實例系

8、 統(tǒng)子 系 統(tǒng)子 系 統(tǒng)子 系 統(tǒng)模塊模塊模塊 模塊模塊模塊模塊模塊模塊.PMI defines WBS是面向可交付成果的對工程元素的分組,它組織并定義了整個工程范圍.不在WBS中包括的任務(wù)就不是該工程的任務(wù)它是一個分級的樹型構(gòu)造，是對工程由粗到細的分解過程。任務(wù)構(gòu)造每細分一個層次表示對工程元素更細致的描畫.本章要點一、軟件需求管理過程二、義務(wù)分解定義三、義務(wù)分解的類型四、義務(wù)分解的方法五、案例分析.類型清單圖表.圖表類型“變化計數(shù)器系統(tǒng)文件比較預(yù)處置添加代碼結(jié)果處置統(tǒng)計總行標志修正記錄修正版本比較找出增刪行統(tǒng)計增刪行刪除代碼添加行數(shù)刪除行數(shù).清單類型1. 變化計數(shù)器1.1 比較兩個版本的程序

9、1.1.1 預(yù)處置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è)定標志以指示修正的次數(shù)1.6 在程序的頭部添加修正紀錄.本章要點一、義務(wù)分解定義二、義務(wù)分解的類型三、義務(wù)分解的方法四、義務(wù)分解指南五、案例分析.本章要點一、軟件需求管理過程二、義務(wù)分解定義三、義務(wù)分解的類型四、義務(wù)分解的方法五、案例分析.義務(wù)分解過程輸入分解WBS.分解方法類比模版自上而下自下而上.W

10、BS模板舉例.分解方法-自上而下“變化計數(shù)器系統(tǒng)文件比較預(yù)處置添加代碼結(jié)果處置統(tǒng)計總行標志修正記錄修正版本比較找出增刪行統(tǒng)計增刪行刪除代碼添加行數(shù)刪除行數(shù).分解方法-自下而上“變化計數(shù)器系統(tǒng)文件比較預(yù)處置添加代碼結(jié)果處置統(tǒng)計總行標志修正記錄修正版本比較找出增刪行統(tǒng)計增刪行刪除代碼添加行數(shù)刪除行數(shù).義務(wù)構(gòu)造分解(WBS)步驟確認并分解工程的組成要素確定分解規(guī)范確定分解能否詳細確定工程交付成果驗證分解的正確性(建立編號).WBS編號系統(tǒng)功能1:11軟件產(chǎn)品:1功能2-子功能2:122功能2:12功能3:13功能2-子功能1:121功能2-子功能3:123.標識項 功能名F1.1獲取網(wǎng)絡(luò)資源數(shù)據(jù)F1

11、.2將資源數(shù)據(jù)存入數(shù)據(jù)庫F1.3獲取網(wǎng)絡(luò)資源信息F1.4察看網(wǎng)絡(luò)資源F1.4.1依類型分類察看網(wǎng)絡(luò)資源F1.4.2依形狀分類察看網(wǎng)絡(luò)資源F1.5察看邏輯網(wǎng)F1.6察看資源形狀F1.7修正網(wǎng)絡(luò)資源的形狀F1.8依條件檢驗網(wǎng)絡(luò)運用情況F1.9顯示拓撲圖F1.10建立通道.分解規(guī)范生存期功能組成.分解規(guī)范應(yīng)一致學(xué)生管理按照生命期分解規(guī)劃需求設(shè)計編碼測試提交按照產(chǎn)品組成分解1.1招生管理1.2分班管理1.3學(xué)生檔案管理1.4學(xué)生成果管理 .分解規(guī)范應(yīng)一致續(xù)不能同時運用兩種規(guī)范進展分解招生管理分班管理學(xué)生檔案管理學(xué)生成果管理 規(guī)劃需求設(shè)計編碼測試提交.檢驗分解結(jié)果的規(guī)范最底層的要素能否是實現(xiàn)目的的充分必

12、要條件最底層要素能否有反復(fù)的每個要素能否明晰完好定義最底層要素能否有定義明晰的責(zé)任人,能否可以進展本錢估算和進度安排.WBS的指南(1)WBS分解的規(guī)模和數(shù)量因工程而異、因工程經(jīng)理而異搜集與工程相關(guān)的一切信息參看一下類似的工程的WBS,與相關(guān)人員討論可以參照模板最低層是可控的和可管理的，但是防止不用要的過細，最好不要超越7層，軟件工程引薦分解到40小時的義務(wù).WBS的指南2每個Work package必需有一個提交物定義義務(wù)完成的規(guī)范每個WBS必需有利于責(zé)任分配可以預(yù)備WBS的字典最后與相關(guān)人員進展評審.WBS字典內(nèi)容WBS表示號稱號主標題的描畫完成的義務(wù)責(zé)任者完成的標識備注1. .WBS意義

13、提供了工程范圍基線,是范圍變卦的重要輸入為評價和分配義務(wù)提供詳細的任務(wù)包進展估算和編制工程進度的根底對整個工程勝利的集成和控制起到非常重要的作用.George and Martha一次野餐會George and Martha方案與家人和朋友舉行一次特殊的野餐活動,以慶賀Martha的升職和他們35周年的結(jié)婚留念. Martha是工程師, George是會計.他們有兩個非常活潑確實孩子,Mary 13歲,Thomas 17歲.經(jīng)過過去幾年的開展,家里不斷壯大,無論是時間和金錢上的需求都在添加,所以他們曾經(jīng)逐漸成為非常好的方案能手,最近他們又經(jīng)過了PMP的認證考試,所以他們非常清楚對于這樣野餐活動也需求開發(fā)一個WBS.野餐預(yù)備活動義務(wù)分解序號任務(wù)持續(xù)時間工作人員1開始02做冰茶15George3準備三明治10Martha4準備水果2Martha5準備籃子2Martha6收拾毛毯2George7收拾運動服3Martha8裝車4George9加油6George10開車去野餐營地20Martha11結(jié)束