软件项目管理课件

chapter__11軟體專案管理chapter__12專案初始chapter__13軟體專案管理第一篇第2章軟體生存期模型chapter__14本章要點一、生存期模型定義二、專案生存期三、案例分析chapter__15選擇專案策略chapter__16建築工程類專案典型生存期模型chapter__17制藥專案典型生存期模型chapter__18生存期模型選擇

Productrealization

InputOutput

ProductCustomerRequirementsCustomerSatisfactionSPM實施策略?chapter__19軟體生存期模型特徵描述了開發的主要階段定義了每一個階段要完成的主要過程和活動規範了每一個階段的輸入和輸出提供了一個框架，可以將必要的活動映射到該框架中。chapter__110本章要點一、生存期模型定義二、專案生存期三、案例分析chapter__111常用生存期模型瀑布WaterfallV模型V-shaped原型Prototyping增量Incremental螺旋式Spiral快速應用開發RAD漸近式階段敏捷開發模型chapter__112瀑布模型（WaterFallmodel）需求分析設計實施測試維護chapter__113瀑布模型適合的專案在專案開始前,專案的需求很明確在專案開始前,解決方案也很明確類似的專案如：短期專案chapter__114V模型接收測試集成測試系統測試用戶需求需求分析總體設計詳細設計編碼和調試集成測試單元測試chapter__115V模型適合的專案在專案開始前,專案的需求很明確在專案開始前,解決方案也很明確對系統的性能安全很嚴格的專案類似的專案如：太空梭等公司的財務系統

V模型實例chapter__116原型模型chapter__117原型模型適合的專案在專案開始前,專案的需求不明確需要減少專案需求的不確定性類似的專案如：第一次開發的產品，驗證可行性需求不明確chapter__118增量模型：IncrementalModel核心功能核心功能112123第一增量第二增量第三增量核心功能112123……chapter__119增量模型適合的專案專案開始，明確了需求的大部分，但是需求可能會發生變化對於市場和用戶把握不是很准，需要逐步瞭解對於有龐大和複雜功能的系統進行功能改進，就需要一步一步實施的。

增量模型實例chapter__120螺旋式模型：SpiralModelchapter__121螺旋式模型適合的專案風險是主要的制約因素,例如不確定因素限制了專案進度用戶對自己的需求也不是很明確可能發生一些重大的變更專案規模很大專案中採用了新技術

螺旋模型實例chapter__122RAＤ複用或者代碼生成.例如:Acceleo，能把模型轉換為Java，C#，PHP等代碼。chapter__123RAD模型規劃分析設計構建測試規劃後置傳統開發快速應用開發後置壓縮chapter__124RAD模型適合的專案很小並且具有探索性質的專案chapter__125漸進式階段模型綜合了增量模型和螺旋式模型的一個實用模型漸進式前進階段式提交chapter__126

漸進式迭代模型

26chapter__127階段性完成規劃chapter__128漸進式階段模型的特點階段式提交一個可運行的產品關鍵的功能更早出現早期預警問題，避免軟體缺陷不知不覺的增長減少報告負擔階段性完成可以降低估計失誤階段性完成均衡了彈性與效率chapter__129漸進式階段模型適合的專案可以適合任何規模的專案，主要是中型或大型專案希望隨時看到未來的專案chapter__130銀行業務系統的生存期實例產品階段1設計業務需求分析原形系統分析專案規劃集成測試產品階段1開發產品階段n設計產品階段n開發確認測試產品提交銀行業務需求原形系統源代碼專案規劃專案規劃chapter__131產品階段1設計

階段目標： 設計公共控制系統功能模組 輸入： 系統設計檔 資料庫結構定義 過程： 詳細設計 輸出： 詳細設計檔 時間計畫： 2011/1/15-2011/2/15（暫定）敏捷開發模型敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。chapter__132敏捷開發模型-整體框架圖chapter__133敏捷宣言個體和交互勝過過程和工具可以工作的軟體勝過面面俱到的文檔客戶合作勝過合同談判回應變化勝過遵循計畫

chapter__134Scrumchapter__135Scrumchapter__136XP(eXtremeProgramming)極限編程XP(eXtremeProgramming)極限編程是由KentBeck提出的一套針對業務需求和軟體開發實踐的規則，它的作用在於將二者力量集中在共同的目標上，高效並穩妥地推進開發。chapter__137XP最佳實踐chapter__138XP-主要活動chapter__139XP方法的實施原則快速回饋(Rapidfeedback)假設簡單(Assumingsimplicity)包容變化(Embracingchange)chapter__140OpenUPchapter__141chapter__142其他模型其他例如:Codeandfix自定義chapter__143Codeandfix模型的改進需求瞭解編碼、走查編譯、檢錯修正編寫文檔提交修正測試chapter__144選擇生存期的步驟熟悉各種生存期模型評審、分析專案的特性選擇適合專案的生存期模型標識生存期模型與專案不一致地方,並進行裁減chapter__145All===All===chapter__146本章要點一、專案立項二、專案生存期五、案例分析chapter__147案例分析

校務通專案生存期chapter__148小結生存期模型瀑布模型V模型原型模型增量模型螺旋式模型快速應用開發模型漸進式階段模型敏捷開發模型chapter__149情景專案:SPM生存期模型描述SPM生存期模型，以圖示展示說明選擇這個生存期模型的原因chapter__250軟體專案管理北京郵電大學軟體學院韓萬江chapter__251承上啟下第二篇軟體專案的計畫chapter__253沒有計畫的情況時間資源投入開發工作計劃性工作協調性工作chapter__254有計畫的情況時間資源投入開發工作計劃性工作協調性工作chapter__255專案計畫chapter__256範圍計畫chapter__257軟體專案管理第3章---軟體專案需求管理chapter__258需求管理中的問題舉例需求的隱含錯誤需求不明確、含糊用戶不斷增加需求、變更需求用戶不配合需求調研開發人員的鍍金chapter__259需求管理的重要性chapter__260本章要點一、軟體需求定義二、軟體需求管理過程三、需求建模的基本方法四、案例分析chapter__261軟體需求需求是指用戶對軟體的功能和性能的要求，就是用戶希望軟體能做什麼事情，完成什麼樣的功能，達到什麼性能。chapter__262專案失敗的原因分析No.

Top10Factors

平均值

1

Inadequaterequirementsspecification

不充分的需求規範

4.5

2

Changesinrequirements

需求的改變

4.3

3

Shortageofsystemsengineers

缺乏系統工程師

4.2

4

Shortageofsoftwaremanagers缺乏瞭解軟體特性的經理人

4.1

5

Shortageofqualifiedprojectmanagers缺乏合格的專案經理

4.1

6

Shortageofsoftwareengineers缺乏軟體工程師

3.9

7

Fixed-pricecontract固定價合同

3.8

8

Inadequatecommunicationsforsystemintegration系統集成階段,交流與溝通不充分

3.8

9

Insufficientexperienceasteam團隊缺乏經驗

3.6

10

Shortageofapplicationdomainexperts缺乏應用領域專家

3.6

Scale:5=VerySerious3=Serious1=NoSerious

Source:Carnegie-MellonUniversity,SoftwareEngineeringInstitutechapter__263本章要點一、軟體需求定義二、軟體需求管理過程三、需求建模的基本方法四、案例分析chapter__264軟體需求管理的過程需求分析編寫需求規格需求驗證需求獲取需求變更需求確認需求變更chapter__265本章要點一、軟體需求定義二、軟體需求管理過程需求獲取需求分析編寫需求規格需求驗證需求變更三、需求建模的基本方法四、案例分析chapter__266需求獲取圖示chapter__267需求獲取用戶要求軟體需求獲取需求chapter__268情景專案:需求獲取SPM需求獲取過程模擬chapter__269本章要點一、軟體需求定義二、軟體需求管理過程需求獲取需求分析編寫需求規格需求驗證需求變更三、需求建模的基本方法四、案例分析chapter__270需求分析定義需求分析是為最終用戶所看到的系統建立一個概念模型，是對需求的抽象描述。chapter__271需求分析模型chapter__272本章要點一、軟體需求定義二、軟體需求管理過程需求獲取需求分析編寫需求規格需求驗證需求變更三、需求建模的基本方法四、案例分析chapter__273需求規格需求分析工作完成的一個基本標誌是形成了一份完整的、規範的需求規格說明書需求規格說明書的編制是為了使用戶和軟體開發者雙方對該軟體的初始規定有一個共同的理解，使之成為整個開發工作的基礎。chapter__274軟體需求規格說明的原則從現實中分離功能，即描述要“做什麼”而不是“怎樣實現”採用一定的規格說明語言如果被開發軟體只是一個大系統中的一個元素，那麼整個大系統也包括在規格說明的描述之中規格說明應該包括系統運行環境規格說明應該容許不完備性並允許擴充chapter__275需求規格文檔參考引言系統定義應用環境功能規格性能需求產品提交實現約束品質描述其他簽字認證chapter__276情景專案:需求規格編寫SPM需求規格展示chapter__277本章要點一、軟體需求定義二、軟體需求管理過程需求獲取需求分析編寫需求規格需求驗證需求變更三、需求建模的基本方法四、案例分析chapter__278需求驗證需求是正確的嗎？需求是一致的嗎？需求是完全的嗎？需求是實際可行的嗎？需求是必要的嗎？需求是可檢驗的嗎？需求是可跟蹤的嗎？最後的簽字chapter__279本章要點一、軟體需求定義二、軟體需求管理過程需求獲取需求分析編寫需求規格需求驗證需求變更三、需求建模的基本方法四、案例分析chapter__280需求總在變化chapter__281chapter__282需求變更管理確定需求變更控制過程建立變更控制委員會(SCCB)進行需求變更影響分析跟蹤所有受需求變更影響的工作產品建立需求基準版本和需求控制版本文檔維護需求變更的歷史記錄跟蹤每項需求的狀態衡量需求穩定性chapter__283需求變更控制系統一個正式的文檔，說明如何控制需求變更建立變更審批系統chapter__284變更申請需求方開發方忽略選擇變更方式SCCB評估專案經理自行決定根據評估結果拒絕接受本次修改下個版本再修改修改合同相關資訊修改相關需求修改相應的專案計畫chapter__285情景專案:需求變更管理SPM需求變更系統chapter__286本章要點一、軟體需求定義二、軟體需求管理過程三、需求建模的基本方法四、案例分析chapter__287需求建模的基本方法原型方法結構化分析法面向對象的用例分析法功能列表法其他chapter__288chapter__289本章要點一、軟體需求定義二、軟體需求管理過程三、需求建模的基本方法原型方法結構化分析法面向對象的用例分析法功能列表法四、案例分析chapter__290原型方法需求分析原型開發原型評價chapter__291原型實例原型系統chapter__292本章要點一、軟體需求定義二、軟體需求管理過程三、需求建模的基本方法原型方法結構化分析法面向對象的用例分析法功能列表法四、案例分析chapter__293結構化分析方法

20世紀70年發展起來的面向數據流的方法是一種自頂向下逐步求精的分析方法根據軟體內部數據傳遞、變換的關係進行分析的chapter__294結構化分析方法-技術數據流圖(DFD)數據字典(DD)系統流程圖chapter__295描述銀行取款過程的數據流圖chapter__296數據字典描述系統中涉及的每個數據,是數據描述的集合,通常配合數據流圖使用,用來描述數據流圖中出現的各種數據和加工.chapter__297數據字典-組成資料項目:數據元素數據流:由資料項目組成的數據流數據檔:表示對數據檔的存儲chapter__298數據流圖需求分析實例建立學生管理系統學管科體檢科學籍科學生處chapter__299數據流圖-頂層學管科體檢科學籍科學生管理資訊系統學生處領導學生基本資訊學生健康資訊學生成績學生健康情況表學生成績單查詢要求不及格人數人數統計表chapter__2100數據流圖-0層chapter__2101數據流圖-1層chapter__2102數據流圖-1層chapter__2103數據字典-數據流

學生基本資訊：學號十姓名學生健康資訊：學號十健康情況學生成績：學號十{課程名+成績}

查詢要求：[健康查詢單|平均成績查詢單l不及格人數查詢]

學生健康情況表：優％十良％十一般％十差％學生成績單：學號十姓名十{課程名+成績}+總成績不及格人數統計表：學號十成績十不及格總人數chapter__2104數據字典-數據檔檔案名：基本資訊組成：｛學號十姓名十入學成績十生源｝組織：按學號遞增順序排列檔案名：健康檔組成：{學號+姓名+健康情況}組織：按照健康情況為優、良、一般、差順序排列檔案名：成績檔組成：{學號+姓名+平均成績}組織：按照評劇成績遞增順序排列chapter__2105系統流程圖系統包含的部分以及各個部分之間的關係是描述物理系統的工具用圖形符號表示系統中的元素表達了系統中各個元素之間的資訊流動情況chapter__2106chapter__2107本章要點一、軟體需求定義二、軟體需求管理過程三、需求建模的基本方法原型方法結構化分析法面向對象的用例分析法功能列表法四、案例分析chapter__2108用例需求（Usecase）分析用例需求分析方法採用一種面向對象的情景分析方法用例是系統向用戶提供一個有價值的結果的某項功能從用戶角度出發考慮的功能需求所有的用例結合起來就構成了用例模型chapter__2109UML需求視圖用例視圖（UsecaseDiagram）順序圖（SequenceDiagram）狀態圖（StateDiagram）活動圖（ActivityDiagram）chapter__2110UML圖符chapter__2111用例視圖chapter__2112用例視圖chapter__2113順序視圖chapter__2114活動視圖chapter__2115UseCase需求分析方法綜述識別出系統的Actor描述主要的Usecase實現用例視圖實現順序視圖，活動視圖,狀態視圖等chapter__2116實例用Rationalrose工具實現的需求規格文檔貿易鏈需求的需求實例chapter__2117本章要點一、軟體需求定義二、軟體需求管理過程三、需求建模的基本方法原型方法結構化分析法面向對象的用例分析法功能列表法四、案例分析chapter__2118功能列表需求類別（功能/性能）名稱/標識描述

特性（Feature）AA.1

……

A.n

特性FeatureBB.1

……

B.n

特性FeatureCC.1

……

C.n

chapter__2119功能列表實例某網站功能列表實例chapter__2120本章要點一、軟體需求定義二、軟體需求管理過程三、需求建模的基本方法四、案例分析chapter__2121案例分析“校務通系統”專案的需求管理過程：需求確認：原型法,軟體需求規格需求變更：變更控制系統chapter__2122需求管理-小結軟體需求開發過程需求獲取需求分析編寫需求規格需求驗證需求變更需求建模的基本方法原型方法結構化分析法面向對象的用例分析法關鍵功能列表法chapter__2123SPM情景專案展示說明軟體需求規格SPM的需求規格文檔軟體需求變更SPM的需求變更控制流程chapter__2124軟體專案管理北京郵電大學軟體學院韓萬江chapter__2125範圍計畫chapter__2126情景引入SPM專案規劃的基礎?chapter__2127軟體專案管理第4章---軟體專案任務分解chapter__2128本章要點一、任務分解定義二、任務分解的類型三、任務分解的方法四、任務分解指南五、案例分析chapter__2129任務分解任務分解的過程將一個專案分解為更多的工作細目或者子項目，使專案變得更小、更易管理、更易操作。任務分解的結果WBS（WorkBreakdownStructure:任務分解結構）chapter__2130WBSWBS(WorkBreakdownStructure)面向可交付成果的Workpackages（工作包）WBS的最低層次的可交付成果chapter__2131WBS實例購買西服一套商品採購購買麵包購買食品購買遊戲機一臺購買水果購買熟肉chapter__2132PMIdefinesWBSWBS是一個分級的樹型結構，是對專案由粗到細的分解過程。WBS是面向可交付成果的對專案元素的分組,它組織並定義了整個專案範圍.不在WBS中包括的工作就不是該專案的工作chapter__2133PMIdefinesWorkpackagesWBS的最低層次的可交付成果工作包應當由唯一主體負責工作包可以分配給另外一位專案經理通過子項目的方式完成chapter__2134本章要點一、任務分解定義二、任務分解的類型三、任務分解的方法四、任務分解指南五、案例分析chapter__2135WBS類型清單圖表chapter__2136圖表類型“變化計數器”系統檔比較預處理增加代碼結果處理統計總行標記修改記錄修改版本比較找出增刪行統計增刪行刪除代碼增加行數刪除行數chapter__2137清單類型

1.

變化計數器1.1

比較兩個版本的程式1.1.1

預處理1.1.2

檔比較1.1.3

結果處理1.2

找出修改後的程式中增加和刪除的代碼行1.2.1

找出增加的代碼行1.2.2

找出刪除的代碼行1.3

統計修改後的程式中增加和刪除的代碼行數1.3.1

統計增加代碼行數1.3.2

統計刪除代碼行數1.4

統計總的代碼行數

1.5

設定標記以指示修改的次數1.6

在程式的頭部增加修改紀錄chapter__2138本章要點一、任務分解定義二、任務分解的類型三、任務分解的方法四、任務分解指南五、案例分析chapter__2139任務分解過程輸入分解WBSchapter__2140分解方法類比模版自上而下自下而上chapter__2141WBS範本舉例chapter__2142分解方法-自上而下“變化計數器”系統檔比較預處理增加代碼結果處理統計總行標記修改記錄修改版本比較找出增刪行統計增刪行刪除代碼增加行數刪除行數chapter__2143分解方法-自下而上“變化計數器”系統檔比較預處理增加代碼結果處理統計總行標記修改記錄修改版本比較找出增刪行統計增刪行刪除代碼增加行數刪除行數chapter__2144任務結構分解(WBS)步驟確認並分解專案的組成要素確定分解標準確定分解是否詳細確定專案交付成果驗證分解的正確性(建立編號)chapter__2145WBS編號系統功能1:11軟體產品:1功能2-子功能2:122功能2:12功能3:13功能2-子功能1:121功能2-子功能3:123chapter__2146標識項

功能名

F1.1獲取網路資源數據

F1.2將資源數據存入資料庫

F1.3獲取網路資源資訊

F1.4觀察網路資源

F1.4.1依類型分類觀察網路資源

F1.4.2依狀態分類觀察網路資源

F1.5觀察邏輯網

F1.6觀察資源狀態

F1.7修改網路資源的狀態

F1.8依條件檢驗網路使用情況

F1.9顯示拓撲圖

F1.10建立通道chapter__2147分解標準應統一學生管理按照生存期階段分解規劃需求設計編碼測試提交按照產品組成分解1.1

招生管理1.2

分班管理1.3

學生檔案管理1.4

學生成績管理chapter__2148分解標準應統一（續）不能同時使用兩種標準進行分解招生管理

分班管理

學生檔案管理學生成績管理規劃需求設計編碼測試提交chapter__2149檢驗分解結果的標準最底層的要素是否是實現目標的充分必要條件最底層要素是否有重複的每個要素是否清晰完整定義最底層要素是否有定義清晰的責任人,是否可以進行成本估算和進度安排chapter__2150本章要點一、任務分解定義二、任務分解的類型三、任務分解的方法四、任務分解指南五、案例分析chapter__2151WBS的指南WBS分解的規模和數量因專案而異、因專案經理而異最低層是可控的和可管理的，但是避免不必要的過細，最好不要超過7層，每個Workpackage必須有一個提交物定義任務完成的標準每個WBS必須有利於責任分配可以準備WBS的字典軟體專案推薦分解到40小時的任務注：80/8規則chapter__2152WBS字典chapter__2153WBS意義提供了專案範圍基線,是範圍變更的重要輸入為評估和分配任務提供具體的工作包進行估算和編制專案進度的基礎對整個專案成功的集成和控制起到非常重要的作用chapter__2154任務分解實例chapter__2155WBS實例:一次野餐會GeorgeandMartha計畫與家人和朋友舉行一次特殊的野餐活動,以慶祝Martha的升職和他們35周年的結婚紀念.Martha是工程師,George是會計.他們有兩個非常活潑的確孩子,Mary13歲,Thomas17歲.經過過去幾年的發展,家裏不斷壯大,無論是時間和金錢上的需要都在增加,所以他們已經逐漸成為非常好的計畫能手,最近他們又通過了PMP的認證考試,所以他們非常清楚對於這樣野餐活動也需要開發一個WBS.chapter__2156野餐準備活動任務分解序號任務持續時間工作人員1開始02做冰茶15George3準備三明治10Martha4準備水果2Martha5準備籃子2Martha6收拾毛毯2George7收拾運動服3Martha8裝車4George9加油6George10開車去野餐營地20Martha11結束0chapter__2157本章要點一、任務分解定義二、任務分解的類型三、任務分解的方法四、任務分解指南五、案例分析chapter__2158案例分析“校務通系統”專案任務分解WBS結果chapter__2159小結WBS相關概念WBS的分解方法範圍基準的形成課堂練習—WBS分解chapter__2160chapter__2161情景專案:SPM任務分解SPM任務分解結果chapter__2162(核心計畫)進度計畫三步曲範圍基準成本基準時間基準chapter__3163軟體專案管理北京郵電大學軟體學院韓萬江chapter__3164情景引入:如何規劃工作量chapter__3165軟體專案管理第5章軟體專案成本計畫chapter__3166本章要點一、軟體專案規模成本的概念二、估算過程三、估算方法四、成本預算五、案例分析chapter__3167關於估算估算不是很準確，有誤差經驗（歷史）數據非常重要不要太迷信數學模型chapter__3168軟體專案規模軟體專案規模即工作量，是從軟體專案範圍中抽出的軟體功能，然後確定每個軟體功能所必須執行的一系列軟體工程任務包括：軟體規劃，軟體管理，需求，設計，編碼，測試，以及後期的維護等任務。chapter__3169規模的單位LOC(LocofCode)源代碼程式長度的測量FP(FunctionPoint)用系統的功能數量來測量人月人天人年chapter__3170軟體專案成本完成軟體規模相應付出的代價。待開發的軟體專案需要的資金。

人的勞動的消耗所需要的代價是軟體產品的主要成本chapter__3171成本的單位貨幣單位人民幣元美元……..chapter__3172軟體的規模和成本的關係規模是成本的主要因素，是成本估算的基礎有了規模就確定了成本,chapter__3173成本管理過程成本管理規劃成本估算成本預算成本控制chapter__3174本章要點一、軟體專案規模成本的概念二、估算過程三、估算方法四、成本預算五、案例分析chapter__3175成本估算過程估算輸入估算結果成本估算方法chapter__3176成本估算輸入專案需求、WBS歷史專案度量資源要求（資源編制計畫）資源消耗率:如人員成本:100元/小時進度規劃：專案總進度（一般是合同要求）學習曲線chapter__3177成本估算結果直接成本間接成本chapter__3178直接成本與具體專案相關的成本chapter__3179間接成本不能具體到某個專案中的成本，可以分攤到各個具體專案中的成本，例如：培訓房租水電員工福利市場費用管理費其他等等chapter__3180本章要點一、軟體專案規模成本的概念二、估算過程三、估算方法四、成本預算五、案例分析chapter__3181估算的基本方法代碼行、功能點類比(自頂向下)估算法自下而上估算法參數估算法專家估算法chapter__3182代碼行（LOC）從軟體程式量的角度定義專案規模。與具體的編程語言有關要求功能分解足夠詳細的有一定的經驗數據（類比和經驗方法）chapter__3183代碼行技術的主要優點代碼是所有軟體開發專案都有的“產品”，而且很容易計算代碼行數。chapter__3184代碼行（LOC）缺點對代碼行沒有公認的可接受的標準定義代碼行數量依賴於所用的編程語言和個人的編程風格.在專案早期,需求不穩定、設計不成熟、實現不確定的情況下很難準確地估算代碼量.代碼行強調編碼的工作量,只是專案實現階段的一部分chapter__3185情景專案:代碼行估算SPM專案用代碼行估算如何?chapter__3186功能點（FP:Functionpoint）與實現產品所使用的語言和技術沒有關係的用系統的功能數量來測量其規模兩個評估內部基本功能外部基本功能加權和量化chapter__3187功能點的公式FP=UFC*TCFUFC：未調整功能點計數TCF：技術複雜度因數chapter__3188UFC-未調整功能點計數功能計數項:(從處理邏輯的角度)外部輸入外部輸出外部查詢外部檔內部檔chapter__3189外部輸入(ExternalInputs：EI)給軟體提供面向應用的數據的項（如螢幕、表單、對話框、控件，檔等）；在這個過程中，數據穿越外部邊界進入到系統內部。

chapter__3190外部輸出(ExternalOutputsEO)向用戶提供(經過處理的)面向應用的資訊，例如，報表和出錯資訊等。chapter__3191外部查詢(ExternalInquiryEQ)外部查詢即是一次聯機輸入，它導致軟體以聯機輸出方式產生某種即時回應。chapter__3192外部介面檔（ExternalInterfaceFilesEIF’s）外部介面檔是用戶可以識別的一組邏輯相關數據，這組數據只能被引用。是機器可讀的全部介面（例如，磁片或磁帶上的數據檔）的數量，用這些介面把資訊傳送給另一個系統。chapter__3193內部邏輯檔(InternalLogicalFiles：ILF’S)用戶可以識別的一組邏輯相關的數據，而且完全存在於應用的邊界之內，並且通過外部輸入維護，是邏輯主文件的數目。

chapter__3194FP估算方法舉例chapter__3195UFC-未調整功能點計數功能計數項的複雜度等級複雜度權重因素項簡單(低)一般（中）複雜（高）外部輸入346外部輸出457外部查詢346外部檔5710內部檔71015chapter__3196功能點計算實例-UFC

功能點項簡單一般複雜外部輸入6*32*43*6外部輸出7*47*50*7外部查詢0*32*44*6外部檔5*52*73*10內部檔9*70*102*15總計UFC301根據某專案的需求評估:外部輸入:11項;外部輸出:14項;外部查詢:6項;外部檔:10項;內部檔:11項chapter__3197TCF-技術複雜度因數TCF=0.65+0.01(sum(Fi))：Fi:0-5,TCF:0.65-1.35技術複雜度因數F1可靠的備份和恢復F2數據通信F3分佈式函數F4性能F5大量使用的配置F6聯機數據輸入F7操作簡單性F8線上升級F9複雜介面F10複雜數據處理F11重複使用性F12安裝簡易性F13多重站點F14易於修改chapter__3198技術複雜度因數的取值範圍調整係數描述0不存在或者沒有影響1不顯著的影響2相當的影響3平均的影響4顯著的影響5強大的影響chapter__3199功能點計算實例FP=UFC*TCFUFC=301TCF=0.65+0.01(14*3)=1.07FP=301*1.07=322chapter__3200情景專案:FP估算SPM採用FP估算如何?chapter__3201功能點與代碼行的轉換語言代碼行/FPAssembly320C150COBOL105FORTRAN105PASCAL91ADA71PL/165PROLOG/LISP64SMALLTALK21SPREADSHEET6chapter__3202估算的基本方法代碼行、功能點類比(自頂向下)估算法自下而上估算法參數估算法專家估算法chapter__3203類比-定義估算人員根據以往的完成類似專案所消耗的總成本（或工作量），來推算將要開發的軟體的總成本（或工作量），然後按比例將它分配到各個開發任務單元中是一種自上而下的估算形式chapter__3204類比—使用情況有類似的歷史專案數據資訊不足（要求不是非常精確)的時候市場招標和合同期chapter__3205類比—特點簡單易行,花費少具有一定的局限性準確性差,可能導致專案出現困難chapter__3206類比—理論舉例chapter__3207類比—主觀判斷舉例證券交易網站需求類似歷史數據：10萬類比估算：10萬chapter__3208情景專案:類比估算SPM採用類比估算如何?chapter__3209估算的基本方法代碼行、功能點類比(自頂向下)估算法自下而上估算法參數估算法專家估算法chapter__3210自下而上---定義利用任務分解結構圖,對各個具體工作包進行詳細的成本估算,然後將結果累加起來得出專案總成本。“變化計數器”系統檔比較預處理增加代碼結果處理統計總行標記修改記錄修改版本比較找出增刪行統計增刪行刪除代碼增加行數刪除行數估算結果chapter__3211自下而上---使用情況專案詳細規劃,WBS開發階段需要進行準確估算的時候chapter__3212自下而上---特點相對比較準確，它的準確度來源於每個任務的估算情況非常費時,估算本身也需要成本支持chapter__3213自下而上---舉例chapter__3214情景專案:自下而上估算SPM採用自下而上估算如何?

chapter__3215估算的基本方法代碼行、功能點類比(自頂向下)估算法自下而上估算法參數估算法專家估算法chapter__3216參數估算法—定義通過過去專案數據,進行回歸分析,得出的回歸模型使用專案特性參數建立數據模型來估算(規模)成本的方法，是一種統計技術。chapter__3217參數估算法—使用情況具有良好的專案數據為基礎存在成熟的專案估算模型chapter__3218參數估算法－特點比較簡單,而且也比較準確如果模型選擇不當或者數據不准,也會導致偏差chapter__3219參數模型:規模(成本)模型整體公式:E=a+b*SCE:以人月表示的工作量a,b,c:經驗導出的係數S:主要的輸入參數(通常是LOC,FP等)chapter__3220參數模型:規模(成本)模型(續)面向LOC驅動的Walston-Felix(IBM)E=5.2*(KLOC)^0.91Balley-BasiliE=5.5+0.73*(KLOC)^1.16.COCOMOE=3.2*(KLOC)^1.05DotyE=5.288*(KLOC)^1.047chapter__3221參數模型:規模(成本)模型(續)面向FP驅動的AlbrechtandGaffneyE=-12.39+0.0545FPMatson,BarnettE=585.7+15.12FPchapter__3222建議掌握模型ＩＢＭ模型－（Walston-Felix）COCOMO模型－(Boehm）chapter__3223ＩＢＭ模型1977年，IBM的Walston和Felix提出了如下的估算公式E＝5.2×L^0.91

，L是源代碼行數(以KLOC計)，E是工作量（以PM計）D＝4.1×L^0.36，D是專案持續時間(以月計)S＝0.54×E^0.6，S是人員需要量(以人計)DOC＝49×L^1.01。DOC是文檔數量(以頁計)chapter__3224舉例採用java完成專案，366功能點，則L=366×46=16386行=16.386KLOCE＝5.2×L^0.91＝5.2×16.386^0.91＝66人月DOC＝49×L^1.01＝49×16.386^1.01＝826頁chapter__3225COCOMO（ConstructiveCostmodel）結構化成本模型是世界上應用最廣泛的參數型軟體成本估計模型由BarryBoehm開發的chapter__3226COCOMO模型發展COCOMO81COCOMOII模型系列chapter__3227COCOMO基本原理將開發所需要的工作量表示為軟體規模和一系列成本因數的函數,基本估算公式:A:可以校準的常量;S為軟體規模;E為規模的指數,說明不同規模軟體具有的相對規模經濟和不經濟性;EM為工作量乘數,反映某個專案特徵對完成專案開發所需工作量的影響程度;n為描述軟體專案特徵的成本驅動因數的個數chapter__3228COCOMO81專案類型：有機:Organic嵌入式:Embedded半有機:Semidetached模型類別：基本COCOMO中等COCOMO高級COCOMOchapter__3229COCOMO81模型類別基本COCOMO靜態單變數模型中等COCOMO基本模型基礎上考慮影響因素，調整模型高級COCOMO中等COCOMO模型基礎上考慮各個步驟的影響chapter__3230COCOMO81專案類型有機:Organic，各類應用程式，例如數據處理、科學計算等受硬體的約束比較小，程式的規模不是很大

嵌入式:Embedded系統程式，例如即時處理、控制程式等

緊密聯繫的硬體、軟體和操作的限制條件下運行，軟體規模任意

半有機:Semidetached各類實用程式，介於上述兩種軟體之間，例如編譯器（程式）規模和複雜度都屬於中等或者更高

chapter__3231基本COCOMO-81E=aX(KLOC)b其中：E是所需的人力（人月）KLOC是交付的代碼行a

，b是依賴於專案自然屬性的參數chapter__3232基本COCOMO-81係數表方式ab有機2.41.05半有機3.01.12嵌入式3.61.2chapter__3233舉例一個33.3KLOC的軟體開發專案，屬於中等規模、半有機型的專案，採用基本COCOMO：a=3.0，b=1.12。E=3.0＊L

^1.12=3.0＊33.3

^1.12=152PM

chapter__3234中等COCOMO-81E=a*(KLOC)b*乘法因數a

b是係數乘法因數是根據成本驅動屬性打分的結果，對公式的校正係數

chapter__3235中等COCOMO-81係數表方式ab有機2.81.05半有機3.01.12嵌入式3.21.2chapter__3236乘法因數屬性產品屬性平臺屬性人員屬性過程屬性chapter__3237乘法因數chapter__3238乘法因數計算每個属性Fi的取值範圍为：

很低、低、正常、高、很高、極高，共六級。

正常情况下Fi=1。

当每個Fi的值選定後，乘法因數的計算如下

乘法因子＝F1*F2*…Fi…*Fnchapter__3239舉例（續）一個33.3KLOC的軟體開發專案，屬於中等規模、半有機型的專案，採用中等COCOMO模型

a=3.0，b=1.12。乘法因數＝0.70*0.85*1……*1.15=1.09E=3.0＊L

^1.12＊乘法因數=3.0＊33.3

^1.12×１．０９＝１６６PM

chapter__3240高級（詳細）COCOMO將專案分解為一系列的子系統或者子模型在一組子模型的基礎上更加精確地調整一個模型的屬性，chapter__3241高級（詳細）COCOMOchapter__3242COCOMOII應用組裝模型---規劃階段早期設計模型---設計階段後體系結構模型---開發階段chapter__3243COCOMOII-後體系結構模型A,可以校準,目前設定A=2.94B,可以校準,目前設定B=0.91chapter__3244模型研究例子—專案數據步驟:xx=[41132144194194291255378591];時間:yy=[6,10,11,16,22,32,30,35,42];chapter__3245模型研究例子—專案數據圖式chapter__3246模型研究例子--擬合算法演算法：functionn=cocomo(m) xx=[41132144194194291255378591]; yy=[6,10,11,16,22,32,30,35,42]; fun=@(c,x)[c(1)*x.^c(2)]; abc0=[11]; c=lsqcurvefit(fun,abc0,xx,yy); n=fun(c,m);endchapter__3247模型研究例子--結果輸出模型輸出圖形輸出chapter__3248模型研究例子--模型應用chapter__3249情景專案:COCOMO模型估算方法SPM採用COCOMO估算如何?

chapter__3250估算的基本方法代碼行、功能點類比(自頂向下)估算法自下而上估算法參數估算法專家估算法chapter__3251專家估算法由多位專家進行成本估算，一個專家可能會有偏見，最好由多位專家進行估算，取得多個估算值,最後得出綜合的估算值。chapter__3252專家估算法-Deiphi組織者發給每位專家一份軟體系統的規格說明和一張記錄估算值的表格，請他們估算專家詳細研究軟體規格說明後，對該軟體給出3個規模的估算值最小ai最可能的mi最大bi組織者對專家的表格中的答復進行整理計算每位專家的Ei=(ai+4mi+bi)/6,chapter__3253專家估算法-Deiphi(續)綜合結果後:E=E1+E2+…En/n（N:表示N個專家）再組織專家無記名填表格，比較估算差，並查找原因如果各個專家的估算差異超出規定的範圍（例如：15%），則需重複上述過程，最終可以獲得一個多數專家共識的軟體規模chapter__3254Deiphi專家估算法-舉例某多媒體資訊查詢系統—專家估算專家1：1，8，9=〉（1+9+4*8）/6=7（萬元）專家2：4，6，8=〉（4+8+4*6）/6=6（萬元）估算結果=（6+7）/2=6.5（萬元）chapter__3255情景專案:專家估算方法SPM採用專家估算如何?

chapter__3256估算方法總結初期類比（主要方法）專家估算計畫階段自下而上參數模型實施階段（包括變更發生）自下而上參數模型chapter__3257成本估算方法綜述主要考慮三種模型:類比法,自下而上法,參數法.

各種方法不是孤立的,應該注意相互的結合使用自下而上法費時費力,參數法比較簡單自下向上法與參數法的估計精度相似類比法通常用來驗證參數法和自下而上法的結果chapter__3258實用軟體估算模型是一種自下而上和參數法的結合模型,步驟如下:對任務進行分解:1,2,…,i…估算每個任務的成本Ei直接成本=E1+E2+……+Ei+……+En間接成本估算專案總估算成本=直接成本+間接成本專案總報價chapter__3259估算每個任務的成本直接估算成本Ei先估算規模Qi，然後估算成本Ei=Qi*人力成本參數退出chapter__3260直接成本估算直接成本組成開發成本管理成本品質成本例如：人力成本參數=5萬/人月，30人月(包括開發\管理\品質)規模的專案的直接成本是150萬chapter__3261直接成本估算－簡易估算：開發（工作量）規模：Scale(Dev)(單位：人月)管理、品質（工作量）規模：Scale(Mgn)=a*Scale(Dev)[a為比例係數：例如：20%--25%]直接成本＝Scale(Dev)＋a*Scale(Dev)退出chapter__3262間接成本估算成本=直接成本+間接成本間接成本估算：按照企業模型直接估算：簡易演算法：間接成本=直接成本*間接成本係數間接成本=規模*人力成本參數*間接成本係數例如：間接成本係數=0.3退出chapter__3263專案總估算成本估算成本=直接成本+間接成本估算成本=直接成本+直接成本*間接成本係數估算成本=直接成本(1+間接成本係數)估算成本=規模*人力成本參數（1+間接成本係數）成本係數=人力成本參數*（1+間接成本係數）簡易演算法：估算成本=規模*成本係數例如：成本係數=8萬/人月退出chapter__3264專案總報價專案總報價=專案總估算成本+風險利潤專案利潤=估算成本*a%風險基金=估算成本*b%稅=估算成本*c%(例如:c為5.5左右)專案總報價=(a+b+c)%*專案總估算成本+專案總估算成本專案總報價=(1+(a+b+c)%)*專案總估算成本chapter__3265總估算成本（BAC）費用BAC時間?chapter__3266本章要點一、軟體專案規模成本的概念二、估算過程三、估算方法四、成本預算五、案例分析chapter__3267成本預算成本預算是將專案的總成本按照專案的進度分攤到各個工作單元中去。成本預算將總的成本安排到各個任務中成本預算的目的是產生成本基線

chapter__3268專案成本預算分配專案成本預算包括三種情況：分配資源成本給任務分配固定資源成本給任務分配固定成本chapter__3269分配資源成本資源成本與資源的基本費率緊密相連設置資源費率標準費率加班費率每次使用費率。。。。。。chapter__3270分配固定資源成本當一個專案的資源需要固定數量的資金時，用戶可以向任務分配固定資源成本。例如：需要的硬體設備

chapter__3271分配固定成本有些任務是固定成本的類型的任務，也就是說，管理者知道某項任務的成本不變，不管任務的工期有多長，或不管任務使用了那些資源。在這種情況下，管理者向任務直接分配成本。例如：培訓任務

chapter__3272成本基線chapter__3273估算準確度類型準確度說明量級估算:合同前Orderofmagnitude-25~~+75%概念和啟動階段決策預算估算:合同期Budget-10~~+25%編制初步計畫確定性估算:WBS後Definitive-5~~+10%工作分解後的詳細計畫chapter__3274估算不准的原因基礎數據不足缺乏經驗的估算人員人為因素，例如簽約前後不連貫估算對需求的敏感性。。。。。。chapter__3275避免低劣估算避免無準備的估算留出估算的時間，並做好計畫使用以前的專案數據使用開發人員提供的數據為基礎估算分類法估算詳細的較低層次上的估算使用軟體估算工具使用幾種不同估算技術，並比較它們的結果chapter__3276本章要點一、軟體專案規模成本的概念二、估算過程三、估算方法四、成本預算五、案例分析chapter__3277案例分析“校務通系統”專案成本估算專案估算結果chapter__3278情景專案:功能點估算SPM專案採用功能點估算如何?chapter__3279情景專案:自下而上估算SPM採用自下而上估算如何?

chapter__3280小結成本估算的過程成本估算的方法成本預算的方法chapter__6281軟體專案管理北京郵電大學軟體學院韓萬江chapter__4282時間計畫chapter__4283專案進度計畫chapter__4284軟體專案管理第6章軟體專案進度計畫chapter__4285本章要點一、進度管理的基本概念及過程二、進度估算的基本方法三、編制進度計畫四、案例分析chapter__4286進度的定義進度是對執行的活動和里程碑制定的工作計畫日期表chapter__4287進度管理的重要性按時完成專案是專案經理最大的挑戰之一時間是專案規劃中靈活性最小的因素進度問題是專案衝突的主要原因，尤其在專案的後期。chapter__4288進度管理的重要性chapter__4289軟體專案進度(時間)管理過程規劃進度管理（PlanSchedulemanagement）活動定義（Activitydefinition）活動排序（Activitysequencing）活動資源估計(Activityresourceestimating)活動歷時估計(Activitydurationestimating)制定進度計畫（Scheduledevelopment）進度控制（Schedulecontrol）-專案跟蹤chapter__4290活動定義（DefiningActivities）確定為完成專案的各個交付成果所必須進行的諸項具體活動chapter__4291活動定義活動1活動2功能1軟體產品功能2-子功能2功能2功能3功能2-子功能1功能2-子功能3設計說明書編寫設計說明書設計評審chapter__4292專案活動排序專案各項活動之間存在相互聯繫與相互依賴關係,根據這些關係進行適當的順序安排前置活動（任務）---〉後置活動（任務）chapter__4293任務(活動)之間的關係ABAB結束-開始結束-結束AB開始-開始AB開始-結束chapter__4294任務(活動)之間排序的依據強制性依賴關係軟邏輯關係外部依賴關係chapter__4295進度管理圖示網路圖甘特圖里程碑圖資源圖chapter__4296網路圖網路圖是活動排序的一個輸出展示專案中的各個活動以及活動之間的邏輯關係網路圖可以表達活動的歷時chapter__4297網路圖圖例chapter__4298常用的網路圖PDM(PrecedenceDiagrammingMethod）優先圖法,節點法(單代號)網路圖ADM(ArrowDiagrammingMethod)箭線法(雙代號)網路圖chapter__4299PDM圖例開始活動1活動3活動2結束chapter__4300PDM(PrecedenceDiagrammingMethod)構成PDM網路圖的基本特點是節點(Box)節點(Box)表示活動（任務）用箭線表示各活動(任務)之間的邏輯關係.可以方便的表示活動之間的各種邏輯關係。chapter__4301PDM(PrecedenceDiagrammingMethod)-優先圖法圖例開始(1)需求獲取(3)專案規劃(2)需求確認(4)專案計畫評審(5)總體設計(6)詳細設計(7)系統測試(10)集成測試(9)編碼(8)結束(11)chapter__4302ADM圖例總體設計需求確認需求獲取系統測試集成測試編碼詳細設計計畫評審專案規劃123698754chapter__4303ADM（ArrowDiagrammingMethod）ADM也稱為AOA（activity-on-arrow）或者雙代號專案網路圖，在ADM網路圖中,箭線表示活動(任務),節點Node（圓圈:circle）表示前一任務的結束,同時也表示後一任務的開始.chapter__4304ADM圖例-虛活動虛活動為了定義活動為了表示邏輯關係不消耗資源的12AB231ABchapter__4305情景專案:網路圖示SPM網路關係圖展示?chapter__4306甘特圖-實例chapter__4307甘特圖顯示基本的任務資訊任務的工期開始時間和結束時間資源資訊。chapter__4308里程碑圖示SpecificationDesign08/1111/11Testing02/125/12AvailableCoding9/1211/12Announcechapter__4309里程碑圖示chapter__4310里程碑圖示里程碑顯示專案進展中的重大工作完成里程碑不同於活動活動是需要消耗資源的里程碑僅僅表示事件的標記chapter__4311資源圖chapter__4312本章要點一、進度管理的基本概念及過程二、進度估算的基本方法三、編制進度計畫四、案例分析chapter__4313專案進度估算-歷時估計專案進度估算是估計任務的持續時間-歷時估計每個任務的歷時估計專案總歷時估計chapter__4314專案進度估算的基本方法定額估算法經驗導出模型CPMPERT基於承諾的進度估計Jones的一階估算準則其他策略chapter__4315定額估算法T=Q/(R*S)T:活動持續時間Q:活動的工作量R:資源（人力或設備）的數量S:工作效率chapter__4316定額估算法例如Q=6人月,R=2人,S=1則：T=3月例如Q=6人月,R=2人,S=1.5則：T=2月chapter__4317定額估算法方法比較的簡單，容易計算。適合專案的規模比較小，參與的人員比較少,例如說人數2-3人chapter__4318專案進度估算的基本方法定額估算法經驗導出模型CPMPERT基於承諾的進度估計Jones的一階估算準則其他策略chapter__4319經驗導出模型經驗導出模型：D=a*Eb：D:進度(以月單位)E：工作量(以人月單位)a:2—4之間b:1/3左右:依賴於專案的自然屬性chapter__4320建議掌握模型Walston-Felix(IBM)：D=2.4*E0.35基本COCOMO:D=2.5*Eb，b：0.32-0.38方式b有機0.38半有機0.35嵌入式0.32chapter__4321舉例(續第5章)採用基本COCOMO模型估算的規模E＝152ＰM

採用基本COCOMO模型估算的進度

D=2.5＊E0.35

=2.5*1520.35＝14.5M

chapter__4322經驗導出模型舉例假設:a=3，b=1/3,則導出模型D=3*E1/3如果：E=65人月則：D=3*65exp(1/3)=12月chapter__4323專案進度估算的基本方法定額計算法經驗導出方程CPMPERT基於進度表的進度估算基於承諾的進度估計Jones的一階估算準則其他策略chapter__4324關鍵路徑法估計（CPM：CriticalPathMethod）根據指定的網路順序邏輯關係,進行單一的歷時估算當估算專案中某項單獨的活動，時間比較確定的時候採用關鍵路徑是網路圖中最長的路徑。關鍵路徑可以確定專案完成時間chapter__4325CPM估計開始A:100天B:10天結束chapter__4326專案進度估算的基本方法基於規模的進度估算，CPMPERT基於承諾的進度估計Jones的一階估算準則其他策略chapter__4327工程評估評審技術（PERT)(ProgramEvaluationandReviewTechnique)利用網路順序圖邏輯關係和加權歷時估算來計算專案歷時的技術。當估算專案中某項單獨的活動，存在很大的不確定性時採用。chapter__4328工程評估評審技術（PERT)它是基於對某項任務的樂觀，悲觀以及最可能的概率時間估計採用加權平均得到期望值E=（O+4m+P)/6，O是最小估算值:樂觀(Optimistic)，P是最大估算值:悲觀(Pessimistic)，M是最大可能估算(MostLikely)。chapter__4329PERTFormulaandExampleExample:PERTweightedaverage=

8days+4X10days+24days=12days

6where8=optimistictime,10=mostlikel