摘要:BugNET 應用：從問題資料庫挖掘專案問題的線索
BugNET 應用：從問題資料庫挖掘專案問題的線索 
BugNET 這套問題追蹤工具除了具有免費、容易安裝設定等優點，個人用到現在也都沒碰到什麼大問題（目前用在約 20 人的團隊），挺穩定的，而且一直都還持續更新，功能也愈來愈強。最近對目前參與的專案有一些軟體品質方面的疑慮，想要從平日登錄到 BugNET 的資料抓出一些統計數據，這才發現 BugNET 提供的統計圖表並不是很夠用。所幸它提供了一個 view，從這個 view 取出的資料，幾乎已經能夠滿足我的需要了，剩下的只是如何產生圖表而已。這篇就大概介紹一下我從這個 view 取出哪些資料，以及利用 Excel 產生的圖表，同時扼要說明一下這些圖表的用途。
BugNET 提供的 view 名稱叫做 BugsView。以下分別介紹用來產生統計圖表的 SQL 命令、圖表範例、以及用途說明。由於 BugNET 本身已經有提供的問題狀態統計圖（一張圓餅圖，顯示已結案、處理中、重新提出...等各種問題處理狀態各佔多少百分比），所以這裡就不列出了。
要先說明的是，有些 SQL 命令看起來很冗長，我也沒特別花時間去查是否還有更精簡的指令，基本上只求能達到我的目的。此外，這裡的圖表範例，都是先利用 SQL 命令得到資料，然後直接貼到 Excel，稍作加工（修改欄位標題、加總等等），再使用 Excel 的插入圖表功能即可完成。當然你也可以撰寫程式將這些產生圖表的動作自動化，方便隨時查閱。
1. 每個月的問題數量
SQL 命令：
SELECT STR(YEAR(ReportedDate), 4, 0) + '/' + STR(MONTH(ReportedDate), 2, 0) AS RptYYMM,
COUNT(YEAR(ReportedDate) + MONTH(ReportedDate)) AS Cnt
FROM BugsView
GROUP BY YEAR(ReportedDate), MONTH(ReportedDate)
ORDER BY RptYYMM
圖表範例：
說明：
從這張統計圖可以看出哪些月份的問題數量比較多，以發現數字背後所隱藏的事件或原因。例如 2007 年 10 月可能有某個新系統上線，而使用者對該系統反映的問題較多，因此數量明顯增加；2008 年 2 月份由於經過一次年假，問題的數量就少得多。當系統完成驗收之後，系統應該會逐漸穩定，因此這張統計圖的問題數量應該呈現逐漸減少的趨勢，若非如此，專案 經理就得進一步了解實際的原因。
2. 問題的優先等級分布
SQL 命令：
SELECT PriorityName, COUNT(PriorityName) AS Cnt
FROM BugsView
GROUP BY PriorityName
圖表範例：
說明：
在登錄問題時，必須根據問題的嚴重或緊急程度做分級（triage）。在所有提出來的問題當中，我們比較有興趣的是「緊急」跟「很重要」的問題佔多 少比例，因為我們將這類問題定義為較具急迫性的問題，開發團隊必須在指定的期限內處理完畢。如果這類嚴重問題的數量很多，要不是軟體的品質水準太低，就是 登錄問題的人員對於問題的分級不確實，比如說，可能每次登錄時都希望問題盡快獲得解決，就一律歸類為緊急問題。
3. 問題數量與軟體品質的關係
SQL 命令：
SELECT TypeName, COUNT(TypeName) AS Cnt
FROM BugsView
GROUP BY TypeName
圖表範例：
說明：
BugNET 的問題類型也可以自行指定。我把問題的類型分成 Bug、改進意見、新增需求、需求變更、待討論、以及無效問題等六類。Bug 代表軟體的設計錯誤，包括設計不符合使用者的需要、無法執行特定的功能、以及執行結果不正確等等；改進意見代表功能雖然可正常執行，但是在易用性、穩定 性、效能等方面有待加強之處；以上兩項均代表軟體的品質，若其總和數量偏高（例如：超過事先定義的警戒線），專案經理就要特別注意。新增需求與需求變更皆 屬於需求異動的部份，開發團隊可以從這兩項數據得知使用者是否經常提出需求變更，以了解需求蒐集和系統分析階段是否有需要改進的地方是，例如：需求誘導技 巧是否需要改進、每一項需求是否皆經過使用者的同意即確認、或使用者是否傾向於事後（上線後）才提出新需求等等。屬於「待討論」的項目代表該問題的範圍或 定義尚未釐清，主要是讓開發人員可以紀錄一些尚未確定的需求或議題（後來發現這項並不實用）。「無效問題」則是開發人員實際測試後，發現是使用者對系統操 作方式不熟悉，或者其他環境因素所造成。
4. 各子系統的品質
SQL 命令：
SELECT ComponentName, TypeName, COUNT(*) AS Cnt
FROM BugsView
GROUP BY ComponentName, TypeName
ORDER BY ComponentName, TypeName
圖表範例：
說明：
BugNET 可讓我們設定系統有哪些 Components，也就是說，你可以自行定義子系統及各項元件，這樣在登錄問題時才能夠特別指明該問題是發生在哪個子系統，將來也才能夠得到比較詳細 的統計數據。當整個系統的 Bug 數量偏多，你可以從這張圖進一步看出各個子系統／元件的品質。例如圖中的人事系統光是 Bug 和改進意見的數量加起來就有 171 個，佔整個系統問題數量（689）的 25%，專案經理可能要針對這個子系統特別研究一下是哪裡出了問題。
P.S. 以上圖表都沒有標示時間範圍，它們都是同一個專案的 current stat，也就是從一開始登錄問題到目前為止的狀態統計。
P.S. 以上圖表除了子系統名稱被我換掉，其餘皆是真實資料的統計數據。
結語
有時候，我們從最近 user 的反應「感覺」最近系統好像很多毛病，並將此意見反映給開發團隊時，經常得到的答案是：「程式的品質並沒有太大的問題，很多都不是 bugs，而是 user 的需求一直變更和新增。」此時解決爭議的最好辦法，就是拿出數據，這也是我製作這些圖表的用意：讓數字說話。
不過，在運用這些圖表時，務須牢記一件事：無論是問題統計圖表還是其他專案度量結果，其提供的資訊可能只偏單一面向，專案經理在獲得此初步資訊之 後，應進一步蒐集其他相關資訊，以提供問題的佐證，或者向團隊詢問，如此方能確定問題的根源，並提出正確的解決方案；如果單憑某個單一數據就驟下結論，而 向團隊質疑或提出指控，不僅容易做出錯誤的決策，將專案開發工作引導至錯誤的方向，也很容易造成團隊成員的反感。
還有一種統計圖我很想看到卻沒有做的，就是問題的成長速度 vs. 問題的解決速度。因為有些問題實在花很多時間才解決掉，對於 bugs，我們特別關心它的平均處理時間。
以上有不少想法和觀念均來自《軟體工程與 Microsoft Visual Studio Team System》。我不時會回頭參考這本書，每每覺得這本書寫得真好，因機緣巧合而能夠翻譯此書，實在是沾了作者的光。希望 Guckenheimer 在 Rosario 問世之後也能更新這本書的內容。呃......大概只是奢望。
