項目控制的學習1.為什么要控制?事情不按計劃進行：-范圍改變-活動的估計值不同于實際值-實際問題：*硬件不工作*通訊連接-資源*辭職*突然離去/意外事故/生病-未預計的附加活動

變化“管理的中心問題是更好地理解變化，并從變化中抽出有用信息。”跟蹤的數據要分析，要用策劃和控制策劃建立目標，控制跟蹤現實跟蹤時將實際值與計劃值相比較如果現實與計劃不一致，現實必須優先控制要求不斷的修定開發計劃監督與控制的目的是保證在即使偏離計劃時仍能實現項目的目標測量的重要性

測量是控制的載體沒有控制軟件工程就不是有效的工程學科仍然是手工勞作（藝術品）從數據中學習·控制：搜集數據 分析數據 解決問題P：計劃將要作什么，并預計效果D：作；執行計劃C：檢查；評估結果，并從結果中學習---控制A：行動；真正著手去作“PDCA是管理的核心，即確保今日的工作并開發明日更好的工作方法。”檢查的重要性：“把已有的決策當作是從中吸取經驗教訓的實驗，那就把PDCA的所有步驟落實。” 2.一般如何跟蹤跟蹤的四個問題跟蹤中要解決以下四個問題：·確定跟蹤對象·采集信息·分析信息·報告信息（1）測量量的確定要采集的度量包括與技術有關的和與管理有關的在確定要采集的度量時可參照HP的經驗：-從工程實際出發，管理人員和工程人員總結自己工作中實際需要的度量-采用目標/提問/度量（G/Q/M）的框架：

*分析目標*提出要解決的問題*從問題中提出度量HP的經驗盡早確定所要采取的度量，如FURPS采取目標—提問—度量G1G2Q1Q2Q3Q4M1M2M3M4M5例子目標：減少工作量和縮短進度其中一個問題是：當要求更改代碼時，何時作更改，何時不作更改？他們分析得出的度量是：

M1:問題發生率M2:缺陷密度M3:代碼穩定性M4:復雜性M5:要更改的模塊數起步核心測量SEI建議DOD的軟件組織采用四個起步核心測量-軟件規模-工作量-進度-缺陷監控什么在項目中受監控的典型方面：-進度-工作量-總成本-質量-范圍(scope)-風險-職員流動-項目的其它被標識的主要目標*技能水平改變過程度量過程度量量化過程或開發環境例子：-生產率-質量-資源度量-缺陷插入率-缺陷及其消除率產品度量產品度量獨立于其過程例子：-規模-可靠性-質量（也是過程度量）-代碼的復雜性-功能性過程方法作工作的規程檢查工作的規程返工輸出產品測量過程測量標準工具輸入過程的測量與分析為什么要采集過程性能數據？要管理過程就需要：能預測過程的未來性能減小過程結果的偏差人們不能控制哪些未測量和理解的東西這是連續過程改進的基礎（2）定義度量的原則通過G/Q/M方法能確定出與經營目標密切相關的測量和度量。在定義這些度量時，必須考慮以下原則：·可重復性：其它人能重復測量，得到同樣的結果；·利于交流：對記錄的測量結果，其它人能精確地知道它包含什么，不包含什么。測量的單位是什么。數據數據是控制的核心。管理改進必須基于測量結果為使數據分析有用，必須了解數據的含義及如何對它作有意義的分析開始時僅采集一小組有用的數據管理者需要保證注意力明顯地集中在項目所有的關鍵方面，包括那些難于測量的，不能只關注那些易于測量和跟蹤的方面（3）測量量的采集任何等級都必須采集度量多數度量存在于開發工作中，必須人人動手采集過程度量等有瞬時的特點，如不及時采集，無法補救要預先確定需采集的最小集合，再不斷補充與誰有關？監控要求群組所有成員參加從每個群組成員的個人計劃開始在高層次上，處理經過整理的/更為一般的問題如何能采集到正確的數據？對事不對人采用工具（4）項目報告項目受監控、控制的等級依賴于管理層次-項目經理要求每日更新-其它開發經理（例如技術管理者）可能滿足于月更新采集的數據要及時、正確、詳細3.有關SPTO基本的監控監控活動是否按計劃進行監控缺陷是否均已解決監控問題是否均已處理L2:基本的監控L3:建立監控的門檻值，監控風險……L4:定量監控跟蹤基線SPTO針對項目計劃進行跟蹤項目計劃中列出了跟蹤要求，包括被跟蹤的主要工作產品、跟蹤頻度、跟蹤機制、跟蹤內容-其跟蹤內容除了規模、成本和工作量、進度外，還有風險、資源（包括關鍵計算機資源），技術活動和糾正措施計劃中列出了被跟蹤量的估計值或預測值，它們作為跟蹤的基礎跟蹤時，將采集的實際值與計劃中的估計值相比較，來確定進展。它們有時被稱為跟蹤基線對軟件工程技術活動的跟蹤活動9中提出對軟件工程技術活動進行跟蹤，這是等級2中唯一與工程技術活動有關的實踐。-要求軟件工程組的成員定期向其直接領導報告技術狀態，包括活動的進展和問題；-將其交付的供后續工作用的工作產品的內容與計劃做比較；-報告任何工作產品中的問題，并建立文檔；-跟蹤問題到問題結束。糾正措施如果計劃和實際進展間存在明顯偏差，就要采取糾正措施。這首先要做評價和判斷。評價：評價項目性能和項目相對計劃的狀態，決定偏差是否明顯，是否需要采取行動。要分析產生偏差的原因。當然首先必須明確定義“明顯”的含義。判斷：采取哪種行動。措施項有兩種可能：-改變正在進行工作的方式；-調整計劃；跟蹤方式跟蹤軟件工程技術活動，必要時采取糾正措施（如定期報告機制）軟件工程組進行定期的內部評審以便對照軟件開發計劃跟蹤技術進度、計劃、性能和問題按照文檔化規程在所選擇的項目里程碑處進行正式評審以評價軟件項目的完成情況和結果（如同行評審）各種報告和表格跟蹤和監控方式

填寫數據采集表格

項目人員定期向其直接領導報告,其主要方式是填寫數據采集表格（如周報，周狀態報告）它們既包括相對計劃的進展（管理方面），又包括技術進展和技術問題（技術方面）一般SPTO需設計和提供適用的對各類人員的跟蹤表格。內部評審內部評審:軟件項目組內部定期進行的評審目的是跟蹤技術進展、計劃完成情況、當前狀態和問題一般一線軟件經理和軟件作業領導參加評審，需要時，和軟件經理和其他軟件經理一起評審正式評審里程碑處的正式評審。目的是評價跟蹤的結果，進行監控而不是跟蹤評價時使用的材料必須經過有關軟件經理的評審和批準-分析軟件活動的約定、計劃和狀態；-識別出重大問題、相應的措施和做出決策，并建立文檔；-分析軟件項目風險；-必要時，做出修訂軟件開發計劃的決定。4.跟蹤表格項目報告—進度表周工時表在項目進度上，作狀態標記(PERT/CPM)周狀態報告進度指示器—全面監控活動層監控的甘特圖周工時表個人周狀態報告進度監控-甘特圖進度指示器—全面監控

到該日止已完成所計劃的活動數進度指示器1=—————————————

到該日止計劃要完成的活動數到該日止已完成的在關鍵路徑上所計劃的活動數進度指示器2=———————————————

到該日止計劃的要完成的在關鍵路徑上的活動數項目報告—工作量周工時表進入實際時間，預計遺留工作量周狀態報告工作量指示器-用于全面監控工作量表活動層監控工作量表（活動層監控）工作量指示器-用于全面監控到該日為止總的實際人-小時工作量指示器1=——————————總的所計劃的完成活動的人-小時總的所預期的（遺留）+實際的人天工作量指示器2=——————————總的所計劃的人天項目報告—成本成本報告類似于工作量成本分量：-工作量（可能分別計算正常的和加班的）-出差-硬件-軟件-通訊項目報告—質量缺陷日志/測試日志ItemWise質量記錄缺陷陷漏矩陣質量指示器ItemWise

質量記錄缺陷泄漏矩陣評審的重要性（泄漏缺陷）需求評審設計評審功能測試靜態分析結構測試251510需求缺陷設計缺陷編碼缺陷返工的費用呈指數式增長質量指示器—全面監控質量指示器1=對已完成的QC作業，總的實際缺陷數------------------------------------------------------------------------對已完成的QC作業，總的預期缺陷數質量指示器2=階段內發現的總缺陷數------------------------------------------所發現的總缺陷數項目報告—范圍更改請求范圍變化指示器范圍變化指示器由于更改請求所造成的總的工作量(全部經批準的更改請求)范圍指示器1=-------------------------------------------到該日為止總的實際工作量對已批準的，更改請求的總的花費范圍指示器2=----------------------------所收到的總的更改請求所收到的更改請求數范圍指示器3=---------------------------------時間(所完成的期間或總的計劃的期間)缺陷與發現階段發現的階段缺陷的例子需求規格說明評審-不正確的或太強的假定-不完全的外部界面說明-過程流不清晰-需求不可跟蹤-含糊性-不完全性項目計劃評審-不恰當的工作量或進度估計-風險評估有問題-不恰當的人力安排-計劃不完全…………缺陷類別缺陷類別例子邏輯標準多余的代碼用戶界面性能重用性設計問題存貯管理缺陷文檔缺陷不一致性跟蹤性可移植性缺陷問題關注error-prone模塊。如果有重復出現的缺陷，它們經常在同一段代碼中出現許多研究指出，少量缺陷能導致失敗中的很大一部分（即，80：20法則）測量每個模塊（或代碼段）的缺陷水平并關注其相應的修正措施5.測量量的利用開發過程中必須基于度量作分析，不斷改進過程（不限于四級）或發現問題度量放在數據庫中供以后項目用估計時最好使用自己的數據需積累本地區的行業數據狀態好壞的標識及措施（L3）

□以實際量與估計量的比值來判斷狀態好壞，該比值稱為標志值□如果比值<，標志為紅色如果比值<<，標志值為蘭色如果比值<<，標志值為綠色□如果規模、工作量、進度、或問題報告的標識值中的任何一個為紅色，或者以上量