天大研究生軟件項(xiàng)目管理Chp3軟件項(xiàng)目計(jì)劃ppt課件

1、軟件工程管理天津大學(xué)軟件學(xué)院王 贊0RoadMap 工程終了 工程執(zhí)行控制 工程方案 工程初始第二篇軟件工程方案沒(méi)有方案的情況資源投入開(kāi)發(fā)任務(wù)方案性任務(wù)協(xié)調(diào)性任務(wù)有方案的情況資源投入開(kāi)發(fā)任務(wù)方案性任務(wù)協(xié)調(diào)性任務(wù)方案的重要性PMI：工程勝利的三大要素法寶：方案、方案、方案方案是通向工程勝利的道路圖進(jìn)度方案是最重要的方案工程進(jìn)度方案編制進(jìn)度方案的三步曲義務(wù)分解WBS-范圍基準(zhǔn)本錢估算資源、進(jìn)度安排本錢基準(zhǔn)，進(jìn)度基準(zhǔn)RoadMap 合同 方案 風(fēng)險(xiǎn) 方案 溝通 方案 人力 方案 質(zhì)量 方案 本錢 方案 時(shí)間 方案 集成 方案范圍方案 工程 終了 工程執(zhí) 行控制 工程 方案

2、 工程 初始軟件工程管理第2章軟件工程范圍方案本章要點(diǎn)一、軟件需求管理過(guò)程二、需求建模的根本方法三、義務(wù)分解過(guò)程四、義務(wù)分解方法五、義務(wù)分解檢驗(yàn)軟件需求需求是指用戶對(duì)軟件的功能和性能的要求，就是用戶希望軟件能做什么事情，完成什么樣的功能，到達(dá)什么性能。軟件需求的層次業(yè)務(wù)需求用戶需求功能需求軟件需求規(guī)格非功能性需求質(zhì)量特性約束和假設(shè)系統(tǒng)需求需求管理的重要性工程失敗的緣由分析No. Top 10 Factors 平均值 1 Inadequate requirements specification 不充分的需求規(guī)范 4.5 2 Changes in requirements 需求的改動(dòng) 4.3 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 Fixed- price contract 固定價(jià)合同 3.8 8 Inadequate communications for system integration 系統(tǒng)集成階段, 交流與溝通不充分 3.8 9

4、Insufficient experience as team團(tuán)隊(duì)缺乏閱歷 3.6 10 Shortage of application domain experts 缺乏運(yùn)用領(lǐng)域?qū)＜?3.6 Scale: 5 = Very Serious 3 = Serious 1 = No Serious Source: Carnegie-Mellon University, Software Engineering Institute軟件需求管理的過(guò)程需求分析編寫(xiě)需求規(guī)格需求驗(yàn)證需求獲取需求變卦需求確認(rèn)需求變卦需求工程根本義務(wù)需求工程需求管理需求開(kāi)發(fā)需求獲取需求分析需求規(guī)格闡明需求驗(yàn)證變卦管理需求獲取圖

5、示需求獲取用戶要求 擴(kuò)展需求基線需求軟件需求需求分析定義需求分析是為最終用戶所看到的系統(tǒng)建立一個(gè)概念模型，是對(duì)需求的籠統(tǒng)描畫(huà)。 需求分析模型需求規(guī)格需求分析任務(wù)完成的一個(gè)根本標(biāo)志是構(gòu)成了一份完好的、規(guī)范的需求規(guī)格闡明書(shū)需求規(guī)格闡明書(shū)的編制是為了運(yùn)用戶和軟件開(kāi)發(fā)者雙方對(duì)該軟件的初始規(guī)定有一個(gè)共同的了解，使之成為整個(gè)開(kāi)發(fā)任務(wù)的根底。軟件需求規(guī)格闡明的原那么從現(xiàn)實(shí)中分別功能，即描畫(huà)要“做什么而不是“怎樣實(shí)現(xiàn)采用一定的規(guī)格闡明言語(yǔ)假設(shè)被開(kāi)發(fā)軟件只是一個(gè)大系統(tǒng)中的一個(gè)元素，那么整個(gè)大系統(tǒng)也包括在規(guī)格闡明的描畫(huà)之中規(guī)格闡明應(yīng)該包括系統(tǒng)運(yùn)轉(zhuǎn)環(huán)境規(guī)格闡明應(yīng)該是一個(gè)認(rèn)識(shí)模型規(guī)格闡明應(yīng)該允許不完備性并允許擴(kuò)展規(guī)格

6、文檔參考引言系統(tǒng)定義 運(yùn)用環(huán)境功能規(guī)格 性能需求產(chǎn)品提交實(shí)現(xiàn)約束質(zhì)量描畫(huà)其它簽字認(rèn)證需求驗(yàn)證需求是正確的嗎？需求是一致的嗎？需求是完全的嗎？需求是實(shí)踐可行的嗎？需求是必要的嗎？需求是可檢驗(yàn)的嗎？需求是可跟蹤的嗎？最后的簽字需求總在變化需求變卦管理確定需求變卦控制過(guò)程建立變卦控制委員會(huì)(SCCB)進(jìn)展需求變卦影響分析跟蹤一切受需求變卦影響的任務(wù)產(chǎn)品建立需求基準(zhǔn)版本和需求控制版本文檔維護(hù)需求變卦的歷史記錄跟蹤每項(xiàng)需求的形狀衡量需求穩(wěn)定性需求變卦管理管理和控制需求基線的過(guò)程需求變卦控制系統(tǒng)一個(gè)正式的文檔，闡明如何控制需求變卦建立變卦審批系統(tǒng)變卦懇求需求方開(kāi)發(fā)方忽略選擇變卦方式SCCB評(píng)價(jià)工程經(jīng)理自行

7、決議根據(jù)評(píng)價(jià)結(jié)果回絕接受本次修正下個(gè)版本再修正修正合同相關(guān)信息修正相關(guān)需求修正相應(yīng)的工程方案表4-3 需求變卦提交單軟件基線產(chǎn)品修正提交單懇求人Bob懇求日期2021。1011工程稱號(hào)工程管理系統(tǒng)階段稱號(hào)系統(tǒng)設(shè)計(jì)文件稱號(hào)RCR-PM-01.doc, RCR-PM-02.doc,變卦簡(jiǎn)述如下修正內(nèi)容1修正測(cè)試流程控制：將2個(gè)角色，3個(gè)渠道流，改為3個(gè)角色，4個(gè)渠道流，詳見(jiàn)RCR-PM-01.doc2添加開(kāi)發(fā)人員技藝信息庫(kù)管理，詳見(jiàn)RCR-PM-02.doc驗(yàn)證意見(jiàn)贊同RCR-PM-01.doc變卦。RCR-PM-02.doc的變卦可以推遲到下一個(gè)版本實(shí)施驗(yàn)證人Jack驗(yàn)證日期20211011SC

8、CBAa, bb, cc 填表人bob本章要點(diǎn)一、軟件需求管理過(guò)程二、需求建模的根本方法三、義務(wù)分解過(guò)程四、義務(wù)分解方法五、義務(wù)分解檢驗(yàn)需求建模的根本方法原型方法構(gòu)造化分析法面向?qū)ο蟮挠美治龇üδ芰斜矸ㄆ渌菊乱c(diǎn)一、軟件需求管理過(guò)程二、需求建模的根本方法三、義務(wù)分解過(guò)程四、義務(wù)分解方法五、義務(wù)分解檢驗(yàn)六、案例分析義務(wù)分解過(guò)程輸入分解WBSWBS (Work Breakdown Structure)義務(wù)分解的過(guò)程將一個(gè)工程分解為更多的任務(wù)細(xì)目或者子工程，使工程變得更小、更易管理、更易操作。義務(wù)分解的結(jié)果WBS義務(wù)分解構(gòu)造。 WBS面向可交付成果的。Work packages任務(wù)包WBS的最低

9、層次的可交付成果WBS實(shí)例功能1軟件產(chǎn)品功能2-子功能2功能2功能3功能2-子功能1功能2-子功能3PMI defines WBS是面向可交付成果的對(duì)工程元素的分組,它組織并定義了整個(gè)工程范圍.不在WBS中包括的任務(wù)就不是該工程的任務(wù)它是一個(gè)分級(jí)的樹(shù)型構(gòu)造，是對(duì)工程由粗到細(xì)的分解過(guò)程。任務(wù)構(gòu)造每細(xì)分一個(gè)層次表示對(duì)工程元素更細(xì)致的描畫(huà)PMI defines Work packagesWBS的最低層次的可交付成果任務(wù)包該當(dāng)由獨(dú)一一個(gè)部門或承包商擔(dān)任這一交付成果可以分配給另外一位工程經(jīng)理進(jìn)展方案和執(zhí)行,或者經(jīng)過(guò)子工程的方式完成任務(wù)包可進(jìn)一步分解為子工程的WBS或各個(gè)活動(dòng)WBS類型清單圖表圖表類型“變

10、化計(jì)數(shù)器系統(tǒng)文件比較預(yù)處置添加代碼結(jié)果處置統(tǒng)計(jì)總行標(biāo)志修正記錄修正版本比較找出增刪行統(tǒng)計(jì)增刪行刪除代碼添加行數(shù)刪除行數(shù)清單類型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ì)錄義務(wù)分解步驟確認(rèn)并分解工程的組成要素確定分解規(guī)范確定分解能否詳細(xì)確定工程交付成果驗(yàn)

11、證分解的正確性(建立編號(hào))WBS編號(hào)系統(tǒng)功能1:11軟件產(chǎn)品:1功能2-子功能2:122功能2:12功能3:13功能2-子功能1:121功能2-子功能3:123標(biāo)識(shí)項(xiàng) 功能名F1.1獲取網(wǎng)絡(luò)資源數(shù)據(jù)F1.2將資源數(shù)據(jù)存入數(shù)據(jù)庫(kù)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依條件檢驗(yàn)網(wǎng)絡(luò)運(yùn)用情況F1.9顯示拓?fù)鋱DF1.10建立通道WBS與OBS組織分解構(gòu)造分解規(guī)范生存期功能組成工程的組織單位。分解規(guī)范應(yīng)一致學(xué)生管理按照生命期分解規(guī)劃需求設(shè)計(jì)編碼測(cè)試提交按照產(chǎn)品

12、組成分解1.1招生管理1.2分班管理1.3學(xué)生檔案管理1.4學(xué)生成果管理 分解規(guī)范應(yīng)一致續(xù)不能同時(shí)運(yùn)用兩種規(guī)范進(jìn)展分解招生管理分班管理學(xué)生檔案管理學(xué)生成果管理 規(guī)劃需求設(shè)計(jì)編碼測(cè)試提交本章要點(diǎn)一、軟件需求管理過(guò)程二、需求建模的根本方法三、義務(wù)分解過(guò)程四、義務(wù)分解方法五、義務(wù)分解檢驗(yàn)義務(wù)分解方法模版類比自上而下自下而上WBS模板舉例分解方法-自上而下“變化計(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ì)總行標(biāo)志修正記錄修正版本比較找出增刪行統(tǒng)計(jì)增刪行刪除代碼添加

13、行數(shù)刪除行數(shù)本章要點(diǎn)一、軟件需求管理過(guò)程二、需求建模的根本方法三、義務(wù)分解過(guò)程四、義務(wù)分解方法五、義務(wù)分解檢驗(yàn)檢驗(yàn)分解結(jié)果的規(guī)范最底層的要素能否是實(shí)現(xiàn)目的的充分必要條件最底層要素能否有反復(fù)的每個(gè)要素能否明晰完好定義最底層要素能否有定義明晰的責(zé)任人,能否可以進(jìn)展本錢估算和進(jìn)度安排WBS的指南(1)WBS分解的規(guī)模和數(shù)量因工程而異、因工程經(jīng)理而異搜集與工程相關(guān)的一切信息參看一下類似的工程的WBS,與相關(guān)人員討論可以參照模板最低層是可控的和可管理的，但是防止不用要的過(guò)細(xì)，最好不要超越7層，軟件工程引薦分解到40小時(shí)的義務(wù)注：80/8規(guī)那么WBS的指南2每個(gè)Work package必需有一個(gè)提交物定義

14、義務(wù)完成的規(guī)范每個(gè)WBS必需有利于責(zé)任分配可以預(yù)備WBS的字典最后與相關(guān)人員進(jìn)展評(píng)審WBS字典內(nèi)容WBS表示號(hào)稱號(hào)主標(biāo)題的描畫(huà)完成的義務(wù)責(zé)任者完成的標(biāo)識(shí)備注1. WBS意義提供了工程范圍基線,是范圍變卦的重要輸入為評(píng)價(jià)和分配義務(wù)提供詳細(xì)的任務(wù)包進(jìn)展估算和編制工程進(jìn)度的根底對(duì)整個(gè)工程勝利的集成和控制起到非常重要的作用網(wǎng)管系統(tǒng)圖表分解實(shí)例FF1配置管理F2缺點(diǎn)管理F3平安管理F4性能管理F3.2F3.3F3.1F3.4F4.2F4.3F4.5F4.6F4.7F4.4F4.1F4.7.1F4.7.2網(wǎng)管系統(tǒng)圖表分解實(shí)例F1F1.1F1.2F1.3F1.4F1.5F1.6F1.7F1.8F1.9F1.10F1.11F1.4.1F1.4.2網(wǎng)管系統(tǒng)圖表分解實(shí)例F2F2.1F2.2F2.3F2.4F2.5F2.6F2.7F2.8F2.9F2.6.1F2.6.2F2.9.2F2.9.4F2