<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" 
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Bug 數量與軟體品質控制</title>
<link>http://blog.roodo.com/rocksaying/archives/2121217.html/</link>
<description><![CDATA[
我日前看了「那些 Bug 是怎麼找來的？」這篇文章，裡面提到用 Bug 數量作為軟體品質的管理指標。管理學有云「可量化者方能管理」，可量化者就是指標項目，諸如一小時的產品生產數量、一天完成的工作項目等等。然而，錯定指標的例子也比比皆是。在軟體工程上，最經典的採用不適當管理指標的案例，就是用「程式行數」來管理工作進度了。就我所知，在理論或實務上，都不是用 Bug 數量作軟體品質管理的指標。此處所說的軟體品質管理，指的是開發過程中的品質管理，交貨時，理論上是無 Bug 的。既然選擇了不適當的指標項目，自然就產生「Bug 多，品質好；Bug 少，還是品質好！」這種無助於管理的結論。
]]>
	</description>
<language>zh-tw</language>
<generator>Roodo Blog System</generator>
<copyright>All Rights Reserved</copyright>
<atom:link href="http://blog.roodo.com/rocksaying/archives/2121217-comment.xml" rel="self" type="application/rss+xml" />
<item>
	<title>回應：Bug 數量與軟體品質控制</title>
	<description><![CDATA[完全同意。這讓我想起來獨孤木在 Taiwan.CNet 上發表的<a href="http://www.wretch.cc/blog/phopicking&article_id=5218178">一篇專案管理文章</a>。當初看到這篇文章時，差點笑翻。這種典型的上班族笑話，沒有親身經歷過的人看不出笑點在哪。

甲方 (使用者) 在看到乙方 (軟體開發廠商) 的雛形之後，往往就會產生先入為主的印象。雛形不好看，甲方就認為這乙方能力不行；雛形太好看，甲方就會對結果產生不切實際的期待。動輒得疚，兩面不是人。

我原本以為塑模工具的使用，可以減少這個問題，甚至可以讓使用者自己塑模。但我的想法在實際進入軟體產業後，被批評「太前衛」，實際上連乙方自己都不用塑模工具，又如何能指望甲方會用？這又牽扯到國內資訊教育的問題了，甲方接口單位通常是甲方的 MIS ，通常跟乙方一樣是資訊科班出身，但依我側面了解 (我不是資訊科班出身的) ，國內資訊教育對「資訊軟體的生產過程」這方面的知識可說是付之闕如，也難怪甲方無法參與開發流程，甚至參與後反而成為專案的阻力。]]>
	</description>
	<link>http://blog.roodo.com/rocksaying/archives/2121217.html</link>
	<guid>http://blog.roodo.com/rocksaying/archives/2121217.html#comment-3156101</guid>
		<category>文章回應</category>
	<pubDate>Thu, 28 Sep 2006 01:46:20 +0800</pubDate>
</item>
<item>
	<title>回應：Bug 數量與軟體品質控制</title>
	<description><![CDATA[Echo你一下: 的確, 在PSP(Personal Software Process)裡, 每個工程師的defect rate, 是工程師衡量自己的指標之一. 很多人立刻會跳腳, 怎麼可以這樣做? 這樣還有誰敢寫code? 不過, bug本就是人寫出來的, 再厲害的投手也不可能永遠不失分, 但還是要衡量自己, 才知自己好不好, 以求技藝的進步.

至於你最後的疑惑, 其實, use case 本就是user's case, 沒有 user, 真的很怪, 卻是事實. 曾聽某位PMP界的大老說, 在台灣, 甲方的問題, 比乙方大的多, 但是大家都在改進乙方, 甲方沒在改進. 你覺得呢?]]>
	</description>
	<link>http://blog.roodo.com/rocksaying/archives/2121217.html</link>
	<guid>http://blog.roodo.com/rocksaying/archives/2121217.html#comment-3153716</guid>
		<category>文章回應</category>
	<pubDate>Wed, 27 Sep 2006 18:32:46 +0800</pubDate>
</item>
<item>
	<title>回應：Bug 數量與軟體品質控制</title>
	<description><![CDATA[我雖然有做 trackback ，但 ithome 的 trackback 好像沒作用。

以我 MBA 的知識，加上個人的 programming 經驗，以 Bug 數量作為「軟體品質管理指標」的效果是很差的。一個 newbie programmer 可以在一天內搞出100個 bugs ，又在一天內全部被 senior programmer 修正。但有時一個 senior programmer 也會被一個 bug 困住好幾天。這樣能夠衡量什麼呢？也許更適合作為 programmer 的技術指標吧。

從 PM 的角度來看，以使用者和開發者都認可的 use case 為準，必須在此 use case 的範疇下無 bug 才能交貨。因此開發者關心的應該是開發過程中的 bug 。交貨後才發現的 bug ，確實「為時已晚」。

不過我觀察國內的 case 好像有個現象，使用者不參與 use case 內容的，彷彿使用者跟這軟體沒關係。依據開發者單方面規劃的 use case 來撰寫 test case ，通常驗收時都可以過關，等使用者實際上線後問題百出再來修正。這種現象好像很正常，但我個人總覺得哪裡不對。]]>
	</description>
	<link>http://blog.roodo.com/rocksaying/archives/2121217.html</link>
	<guid>http://blog.roodo.com/rocksaying/archives/2121217.html#comment-3128886</guid>
		<category>文章回應</category>
	<pubDate>Sat, 23 Sep 2006 00:16:05 +0800</pubDate>
</item>
<item>
	<title>回應：Bug 數量與軟體品質控制</title>
	<description><![CDATA[Hi 石頭君,

大概是ithome的trackback不work吧！直到今日我才注意到您的看法。

我以為，Bug 數量作軟體品質管理，是很常見的，至於合不合理，是另一個問題。例如，我們設一個品質目標︰沒有發現新的Bug時，才能交貨，這也是用Bug數量來做管理的例子。此外，很多人用軟體出貨後所發現的Bug，做為品質的指標，這個指標當然有意義，但可能為時已晚。

Bug 數量有非常多應用。每週發現的新bug、有待處理的bug、已發現bug的總數，都有其不同的管理應用方式。如您所說的測試案例 (test case) ，我也會拿來配合每週發現的bug數來一齊比對。例如，每週發現的bug數愈來愈少，呈現一個收斂圖形時，我也會檢查，每週所規劃的test case數、每週所執行的test case數，是否也有穩定的成長。如果收斂的bug數是來自於測試不完整，那就有疑點了。

Just my 2 cents!]]>
	</description>
	<link>http://blog.roodo.com/rocksaying/archives/2121217.html</link>
	<guid>http://blog.roodo.com/rocksaying/archives/2121217.html#comment-3125436</guid>
	<author>jonachen@gmail.com(喲哪桑)</author>	<category>文章回應</category>
	<pubDate>Fri, 22 Sep 2006 12:00:21 +0800</pubDate>
</item>
</channel>
</rss>