Transcript 下載/瀏覽
軟體快速開發 第二十六章 度量 大綱 26.1 應用度量 26.2 管理度量的風險 26.3 度量的副作用 26.4 度量與其它活動的相互關係 26.5 度量的底線 26.6 成功應用度量的關鍵 度量 Measurement 度量不僅有激勵員工的短期效益，也有 在成本、品質和進度方面的長期效益。 為獲得最好的效果，應由常設度量小組 制定一套高水準的管理規定。 效果 縮短原定進度的潛力： 很好 過程可視性的改善： 好 對專案進度風險的影響：降低風險 一次成功的可能性： 大 長期成功的可能性： 極大 主要風險 對某個度量指標過度優化 在對員工評估中誤用度量方法 從程式碼行數度量中獲得誤導資訊 主要的相互影響和權衡 為改善專案預算、制定進度計畫、評估程式 設計方法提供了基礎。 度量計畫可以通過下列方法支援快速開發： 度量提供狀態的可視性 能確切地知道目前專案所處的狀態 度量聚焦人員的活動 人們會對設定的目標做出反應 度量能提高士氣 度量能幫助設定實際的期望 度量為改善長期進度打下基礎 度量可幫助累積經驗，有助於精確估算 專案和進行規劃 26.1應用度量 高效應用度量的關鍵因素如下： 確定目標 決定如何改善專案和產品 提出問題 決定要提出那些問題有利於達成目標 建立度量標準 建立度量標準將能回答問題 度量小組 理想的度量小組應該有以下領域的知識： 統計和多元分析 軟體工程文獻 軟體專案管理文獻 軟體規劃和評估方法 軟體規劃和評估工具 資料收集表格設計 檢查設計 品質控制方法 逐步審查，審查和測試的所有標準格式 有關專門軟體度量標準的正反兩方面論 述 會計原則 度量什麼 成本和資源資料 如：電腦資源、日期資料 更改和缺陷資料 如：缺陷分類、缺陷檢測方法 過程資料 如：過程定義、過程一致性 產品資料 如：開發日期、總工作量 一旦已經開始收集資料元素，就可以從原始的 資料獲得更深層的資料，以下是可建立的資料 元素： 公開的缺陷數與報告總缺陷數的對比 審查發現的缺陷數量和運行發現的缺陷數量對 比 已經評估過的歷史紀錄與一個專案實際還需要 的天數的對比 按程式設計語言統計每個員工每月的平 均功能點數 產品發佈前清除的缺陷數在總缺陷數中 所占的百分比 按缺陷嚴重程度、子系統、時間，分類 統計平均修復時間 產生每頁文檔的平均小時數 數據立度 Granularity 大多數公司所收集資料遇到的一個問題是資 料收集的範圍太大以至於無法使用。 下表列出了計算時間的種類及活動內容： 種類 活動 管理（專案） 計畫 管理客戶關係 管理開發者 管理品質保證 管理變更 種類 活動 管轄（行政） 停機時間 開發實驗室的建立 開發流程 創建開發流程 復審或審查開發流程 重做／修復開發流程 講解開發流程 需求規格說明 建立規格說明書 復審審查規格說明書 重做/修復規格說明書 在制定說明書期間檢測到的缺陷 數 種類 活動 建立雛型 建立雛型 復審或審查雛型 重做／修復雛型 在建立雛型期間檢測到的缺陷數 架構 建立架構 復審或審查架構 重做／修復架構 在建立架構期間檢測到的缺陷數 設計 建立設計 復審或審查設計 重做／修復設計 在設計期間檢測到的缺陷數 種類 活動 實作 建立實作 復審或審查實作 重做／修復實作 在實作期間檢測到的缺陷數 元件的取得 調查或取得元件，購買或自製 管理元件的取得 測試取得的元件 維護取得的元件 報告取得元件中的缺陷 整合 創建及維護建構 測試建構的系統 發佈建構的系統 種類 活動 系統測試 計畫系統測試 建立系統測試手冊 建立自動系統測試 執行手動系統測試 執行自動系統測試 報告系統測試期間的缺陷 產品發佈 準備和支援中期發佈 準備和支援alpha版發佈 準備和支援beta版發佈 準備和支持最終版發佈 度量標準 收集度量資料 分析度量資料 應用收集到的資料 Pareto分析 尋找那些花費80%時間而僅佔總活動只 有20%的活動。最佳化軟體專案的進度 與最佳化軟體的執行速度一樣。 度量在那些地方花了時間，然後設法提 高其效率。 分析 vs. 度量 為了使收集的資料有意義，就要對度量 標準進行定義和進行標準化，以便我們 能在不同的專案之間進行比較。 NASA的軟體工程實驗室獲得的一個教訓 是在分析上用較多的時間而在資料收集 上花較少的時間。 整理和分析資料的方法如下： 方程式 餅形統計圖 定義正常範圍的圖表 表格 定義流程 經驗法則 配備具有上述部份或全部功能的軟體 回饋 Feedback 當組織能給開發人員提供度量資訊回饋時， 開發者會喜歡度量計畫。 讓開發者參與到資料收集及標準制定，收 集的資料可能會更好，而且你的邀請能提 高參與熱情。 基準報告 組織機構提供度量計畫的一種特殊回饋方法是年度軟 體基準報告。 基準報告類似年度財政報告，描述的是機構軟體發展 能力的狀態。 基準報告是在歷史資料、調查、圓桌會議討論和採訪 等基礎上寫成的。 基準報告不是評估報告。 局限性 度量是有用的，但它不是靈丹妙藥。要 在腦海中記住它們的局限性。 過份的依賴統計資料 可從統計資料中獲得洞察力，但與相關 人員討論統計分析時，能獲得更深的瞭 解。 資料的精確性 大多數公司的追蹤系統都會在一個軟體 專案中忽略30%到70%的實際工作量。 在制定度量計畫時，應考慮到這些誤差 來源。 26.2管理度量的風險 對單一因素的度量過分優化 要使度量的因素獲得最優化，就需要仔 細確定度量的因素。 評估員工時採用錯誤的度量方法 一個成功的度量計畫依靠被評估工作人 員的參與活動，並且度量方案是追蹤專 案的，而不是追蹤特定的人。 從程式碼行數度量中獲得錯誤資訊 用程式碼來度量生產力會使高階語言的生產率 顯得比它實際的要低。 應用系統每一程式碼缺陷數較少的這個事實會 對應用程式產生品質水準的錯誤印象。 聰明快速的方法可以導致程式碼較少，還可以 考慮對某些度量採用功能點的辦法，它能提供 生產力及品質的共通標準。 26.3度量的副作用 度量的主要附帶效果是使度量的對象獲 得最優。 例如：優化缺陷率，提高可用性，執行 效能，優化進度等等。 26.4度量與其它活動的相互關係 一個度量計畫可以提供多方面改進的基 礎。 雖然可以制定一個度量計畫來減低開發 專案的開支，但不能對其它方面的活動 產生副作用。 26.5度量的底線 度量方案的有效性自然要有可靠的資料 來支援。 建立了完整的軟體度量規劃的機構能夠 連續四、五年內，每年提高品質40%和 生產力15%。（Jones 1991） 26.6成功應用度量的關鍵 建立一個度量小組。 這個小組負責確定有用的度量指標和幫助各項指標進 行測試。 在一個合適數據粒度（granularity）下追蹤計算時間的 資料。 開始時採用較少量的度量。 根據目標、問題和度量標準來選擇你想要度量什麼。 不要僅僅收集資料。 要分析資料且把它們回饋給與度量資料相關的人。 軟體快速開發 第二十七章 小型里程碑 大綱 27.1 應用小型里程碑 27.2 管理小型里程碑的風險 27.3 小型里程碑的副作用 27.4 小型里程碑與其它一些活動的相互 關係 27.5 小型里程碑的底線 27.6 成功應用小型里程碑的關鍵 小型里程碑是一種進行專案追蹤和控制 的好方法，它能很好地提供專案狀態的 可視性。 成功應用的關鍵包括克服被管理的人員 抗拒情緒和使這項活動真正保持小型的 特徵。 效果 縮短原定進度的潛力： 一般 過程可視性的改善： 很好 對專案進度風險的影響：降低風險 一次成功的可能性： 大 長期成功的可能性： 極大 主要風險 無 主要的相互影響和權衡 特別適合專案恢復 當與每日建構和冒煙測試法相結合使用時特別有效 能與漸進式雛形法、使用者界面雛形，需求規格說 明和其它難管理的專案活動的結合使用 增加專案追蹤工作量換來良好的可視性和控制性 小型里程碑對快速開發支援可以歸結以 下四點： 提高狀態的可視性 提高控制精確度 改善激勵 減少進度風險 小型里程碑就是在軟體發展中採用了粒度控制 （Fine-grain control）相同的思想，通過這方法 便不會偏離期望太多。 里程碑有助於對人員進行追蹤。沒有短期 里程碑很容易失去目標。 通過小型里程碑，每個人都不得不每一天 或者每兩天需要完成他們的目標。 27.1應用小型里程碑 及早啟動小型里程碑或者對危機做出反應 讓開發者建立他們自己的小型里程碑 保持里程碑的小型特徵 里程碑的二分性 只有做完和還沒做完兩種狀態 制定一系列完整的里程碑 在短期計畫中應用小型里程碑 定期評價進度和調整或重新計畫 如果一個開發者僅僅靠著不斷超時工作 才能完成計畫，那麼我們就應該調整這 個計畫。 當同時評估幾個開發者的進度計畫時， 可能會發現有一些開發者的進度計畫比 其它人長。如果差別很大時，可以轉移 一部份給其它人，使得工作更平均。 27.2管理小型里程碑的風險 不能有效的應用小型里程碑時會存在一 定的風險，但應用小型里程碑不會對專 案本身造成任何風險。 27.3小型里程碑的副作用 小型里程碑比其它方法需要更多的管理， 不需要很多複雜的方法。 小型里程碑比其它方法需要更多時間。 避免專案領導者不與專案本身進行接觸。 27.4小型里程碑與其它一些活動的 相互關係 因為小型里程碑支援每天的預計進度與 實際進度的比較，所以相對地也能快速 評價出這個專案大概要延長多長的時間 。 小型里程碑非常適用於每日建構和冒煙 測試活動（ch18）也適合於控制不定型 （amorphous）開發。 27.5小型里程碑的底線 如果覺得在3個月內可以完這專案，但不能為 要做的工作建立小型里程碑時，那實際上可能 還需要6到9個月才能完成這個專案。 由於所有工作都是在進度計畫中，所以可以減 少去做一些有興趣但沒有生產作用的迂迴開發 活動。 可以減少開發時間。 27.6成功應用小型里程碑的關鍵 在合適的時候啟動使用小型里程碑，可 在專案早期或者要對危機做出反應的時 候 里程碑要小，一般間距控制在一到兩天 內 確保里程碑是詳盡的 準確地報告里程碑的進展情形 定期地評價進度並且在它們脫離里程碑 進度時進行調整或者重新計畫 報告完畢 End