1、第9講 軟件項目監控1內容項目監控的內容項目監控框架項目監控方法與工具變更控制項目修復2項目監控的內容監控項目的進展比較實際進度與計劃的差別修改計劃使項目能夠返回預定“軌道”3項目監控框架：過程4項目監控框架：責任（1）項目指導委員會（Project Steering Committee， Project Board）負責整個項目進度報告項目情況的組織結構5項目監控框架：責任（2）項目情況報告的內容6項目監控框架：進度評估基礎：定期信息收集或者發生的特定事件這些信息必須是客觀的和可度量的但是并非每一次都能夠得到符合要求的信息，因而通常需要項目成員進行主觀判斷7項目進度監控：檢查點設置檢查點(C

2、heckpoints)包括：定期的（如一星期一次，一月一次）與特定的事件綁定的，如生成一份報告或者交付部分產品8項目監控框架：監測頻率監測的頻率依賴于項目的大小和風險情況團隊領導，可能需要每天都了解一下進度項目經理需要每星期或每月了解情況管理層次越高，頻率越低，信息越抽象許多公司利用星期一早晨的短會來激勵員工實現短期目標9數據收集盡管整個過程被分成了容易管理的活動，但是項目執行中仍然需要在活動中對任務完成的比例進行評估，這種評估通常是困難的。思考：某一軟件開發者完成了一個需要500行代碼的軟件的250行，請解釋一下為什么不能認為他的工作已經完成了一半？10答案許多因素決定了不能用完成的代碼行的

3、比例來衡量進度：對整個軟件的代碼行的估計可能不準確寫完的代碼可能相對容易，或者相對容易一個軟件如果沒有通過測試就不能算完成，因而即使代碼全部寫完了，如果沒有測試也不能算完成。對所需完成內容的深入的了解有助于判斷進度，如將整個工作細分為子任務，如設計，編碼，單元測試等。11部分完成報告許多組織采用財務系統中的每周時刻表來記錄每個職員在每項工作中花費的時間，但是該表無法告訴項目經理目前產出了什么，進度是否滿足要求。因而可以對每周時刻表進行擴展，以包含完成的工作內容12風險報告詢問小組成員完成計劃的可能性交通燈方法：識別評價某項工作中的關鍵元素將這些關鍵元素分解為組成元素對于每一元素：如果符合計劃要

4、求：綠燈目前已經拖后，但是可以恢復，黃燈已經拖后，恢復很困難，紅燈13進度可視化Gantt圖14進度可視化滑動圖(slip chart)彎曲的越厲害，說明偏離計劃越明顯15進度可視化球圖：計劃開始，計劃結束作為兩個球，每次計劃改變后，日期添加到球中，如果時間是按計劃的，球被填為綠色，否則被填為紅色。每次更新后，圖不需重畫。16進度可視化前面的方法不能表示出項目生命周期中偏離計劃的情況。對計劃偏離的趨勢分析能夠避免將來的項目偏離。時間線圖（timeline）17進度可視化實際的時間計劃的時間第二個星期評估時發現，任務2需要延期，其它任務也相應延期第四個星期評估時發現，任務4需要延期，任務5也相應

5、延期第五個星期評估時發現，任務3需要延期18成本監控監控的意義成本本身是項目中的重要元素成本監控也能展示已經花費了多少勞力簡單的監控方法：累積消耗圖不能說明項目進展情況19累積消耗圖對普通的累積消耗圖上加上項目時間信息20盈余量盈余量（Earned Value):建立在對每個任務或工作包的消耗預測的基礎上。對每一項內容的原始預算成本被稱為預算基線或計劃工作的預算成本（budgeted cost of work scheduled, BCWS)。未開始的任務被賦予值0，當它被完成后，將被賦值。在項目中的一點上，全部的值將被成為盈余量或完成工作的預算成本（budgeted cost of work

6、 performed, BCWP)21盈余量當任務未完成時，需要分配一個盈余量給該任務，方法為：0/100技術：任務被分配值0直到任務完成后，被分配預算值的10050/50技術：任務一開始后，就賦予50%,直到項目結束后賦值100%里程碑方法：對任務中的一系列里程碑賦予特定值。建議用0/100方法，因為50/50方法由于活動開始后報告的值過高，容易給人一種錯誤的安全感，而里程碑方法最好將該任務細分為多個子任務。22預算基線建立盈余量分析的第一步是為項目建立一個預算基線(baseline budget)預算基線是建立在項目計劃的基礎上的，它是根據時間對盈余量值的預測。盈余量可以用貨幣單位來衡量，

7、也可以用人員工作量來衡量。23例子采用了0/100方法24盈余量監控隨著項目的進行，可以不斷進行盈余量監控，判斷項目的進度。？通過分析該圖是否可以判定項目中發生的情況25盈余量監控每一項任務的真正成本消耗為（Actual Cost work performed, ACWP)預算變動調度變動（成本）調度變動（時間）成本變動26盈余量監控性能比例：成本性能指數：CPIBCWP（盈余量）/ACWP（真正的成本消耗）調度性能指數：SPI=BCWP/BCWS(預算成本)值越大，工作完成得越好27例子28你被指定負責一個軟件項目，此項目由四個部分（A, B, C, D）組成，項目總預算為53000元，其中

8、A任務預算為26000，B任務預算為12000， C任務預算為10，000，D任務預算為5000，截至到8月31日，A已經全部完成，B過半，C剛開始，D還沒有開始采用50/50規則計算截至到8月31日的CV, SV, CPI, SPICV=BCWP-ACWPSV=BCWP-BCWSCPI=BCWP/ACWPSPI=BCWP/BCWS任務BCWS（計劃費用）： 元ACWP（實際花費）：元A26，00025，500B9，0005，400C4，8004，100D00截至到8月31日的計劃成本和實際成本29關鍵：計算BCWP采用50/50原則B任務過半， BCWP=6,000C任務開始，BCWP=5,

9、000D任務未開始，BCWP0任務BCWS（計劃費用）： 元ACWP（實際花費）：元BCWP（盈余量）：元A26，00025，50026,000B9，0005，4006,000C4，8004，1005,000D000Total39,80035,00037,00030截至到8月31日BCWS=39,800ACWP=35,000BCWP=37,000CV=37,000-35,000=2,000SV=37,000-39,800=-2800SPI=93%CPI=106%SPI小于1說明截至到8月31日沒有完成計劃的工作量，即進度落后CPI大于1說明截至到8月31日費用節省了，完成工作量的價值大于實際花

10、費的價值31盈余量監控盈余量概念還沒有被軟件界全面接受，原因可能在于建了一半的房屋可以有反映人力和材料消耗的記錄，而完成一半的軟件項目卻沒有任何數據。這是對盈余量分析的誤解。實際上盈余量分析是一項跟蹤項目進度的方法。32項目評審通過一定的方式對項目進行評價和審核評審活動的類型商務評審技術評審管理評審質量評審產品評審評審時間定期評審階段評審事件評審33定期評審準備評審要素確定評審方式依據采集數據統計項目性能評審管理/質量/技術等問題對評審作出結論計劃修改到達定期評審時間34階段評審準備評審要素組織相關評審評審本階段關鍵任務完成情況確認產品提交情況階段評語對下階段計劃調整到達階段評審時間統計報告數

11、據35事件評審按評審過程組織評審報告事件的情況對事件處理方案的討論確定事件影響的范圍計劃修改事件報告被批準對評審做出結論36監控的優先級關鍵路徑活動沒有自由浮動的活動小自由浮動時間活動的監控高風險的活動使用關鍵資源的活動37使項目回到正規幾乎所有的項目都會遇到延誤和意外事件。項目經理的一項任務就是識別這些事件發生的時間，在最小延遲時間和對項目團隊有最小的影響的情況下，消除問題的影響。38縮短關鍵路徑要求項目組人員“Work harder”有一些效果，但是不能輕易使用。分配額外的資源可以加快進度，但是并不總是奏效，例如分配給某一人員的小模塊，再增加一個人員并不一定能夠縮短時間。將非關鍵路徑上的資

12、源調整到關鍵路徑上注意：縮短關鍵路徑可能使其它路徑成為關鍵路徑。39重新考慮任務優先關系網絡計劃考慮的是理想情況和普通工作情況，因而在無法縮短關鍵路徑時，可以重新考慮任務優先關系。另一種方法是將活動再進行劃分，從而一部分可以與其它活動并行。重新考慮任務優先關系可能帶來風險或者質量上的影響。40變更控制（Change Control)用戶的需求可能變化，項目內部可能變化變更需要仔細考慮，因為一個部分的變化可能會對另外部分的造成影響問題：對程序描述的改變將引起軟件的設計和代碼的改變，還有什么其它產品可能需要修改？答案：測試數據，期待結果和用戶手冊等41變更管理員角色Configuration Li

13、brarian責任：識別所有需要變更控制的內容建立一個保存所有項目文檔和代碼的中央庫建立一套管理變更的正式過程維護讀取庫中內容的記錄和庫中每一項的狀態42變更控制過程用戶意識到需要對系統進行修改，考慮將修改請求提交給開發人員用戶端的管理者考慮是否將該修改請求提交給項目承擔者項目承擔端的管理者將該任務指派給一個成員，該成員將判斷該修改的成本以及修改的影響，并提交一個報告該報告被提交給用戶，用戶將考慮是否能夠承受額外的成本43變更控制過程用戶同意后，一個獲多個開發者被授權從主產品上取出要修改的部分的拷貝拷貝被修改。新版本開發出來后，將通知用戶，用戶進行接受測試當用戶滿意后，產品的配置項被新版本所代

14、替。44項目修復需要修復的項目沒有人對項目何時結束有一點點概念產品滿目瘡痍。開發組人員工作超時，每周多于60小時管理層已經無法控制進度，而評估項目狀態的準確性喪失殆盡客戶對開發組能否按承諾交付軟件不再抱有信心開發人員，市場人員，項目經理，客戶之間關系緊張開發組士氣低落45修復方案問題：如何挽救項目縮減項目規模，以便在計劃的時間與工作量內完成項目把注意力放在短期的改善上，以提高過程的生產率面對現實，放棄計劃有沒有其它方法？重新獲取控制權46修復計劃第一步評估你的處境應用W-理論分析作好修復項目的思想準備向開發組成員探問拯救項目的方法變得現實一些47項目修復：人員采取一切措施恢復開發組的士氣采取一

15、個象征性的行動，如給他們特許的條件（允許他們上班晚些，提供更好的工作環境），也可以放一次假確保為開發組創造了條件如去掉了過多的進度壓力，改善了惡劣的工作條件，剔除了管理上的不當做法消除重大的人員問題勇敢地面對問題，該調整的要調整48項目修復：人員消除重大領導問題更換子項目經理為經理配備助手增加新手一定要慎重充分利用開發人員的時間減輕他們其它的負擔為他們處理一些日常工作允許開發組人員各有不同絕不允許破壞士氣觀察開發人員的節奏不斷根據修復的情況來調整安排49項目修復：過程修正軟件開發過程中出問題的環節出問題的環節必然是項目有意或無意忽略了軟件開發的基本原則創建詳細的小型里程碑小型的（一、兩天規模的）二元性（要么完成，要么沒有完成）徹底性（所有里程碑完成，項目就完成了）依據里程碑的完成來安排進度為每個里程碑設置完成的時間，里程碑的設置必然是考慮