Swebok

這個月是審查 IEEE 的軟體工程知識寶典。這是嘗試定義我們專業領域的知識體系，以便為特許專業奠定基礎。

我通常會忽略這類事情。IEEE 有許多標準，但從事商業軟體開發的人通常會忽略這些標準。這些標準大多是由學者和參與大型政府專案的人員撰寫的。商界人士不會將政府視為效率的同義詞。

但是，我已學會尊重其判斷的 Cem Kaner 確實認真看待這件事。他在他的部落格中說：「如果 SWEBOK 是許可考試的基礎，那麼 SWEBOK 中的做法將被視為醫療事故訴訟的基礎。在 SWEBOK 中被稱為良好做法的人，如果因醫療事故而被起訴，將能夠在法庭上為自己的做法辯護。採用可能更好的做法，但與 SWEBOK 相衝突的人，將冒著在法庭上受到嚴厲批評的風險。作為許可考試的基礎，SWEBOK 成為特許專業領域中已核准做法的官方聲明。」

那麼 Swebok 有多大的缺陷？這個月對我來說很忙，所以沒有時間深入探討。只要閱讀幾節，就足以提出一些警訊，並確認 Swebok 過度強調計畫驅動開發的觀點，以至於排除了敏捷方法。

我查看的第一個部分是設計部分。顯然，Swebok 將設計視為與程式設計分開的活動，這與敏捷運動中大多數人的觀點相反。它暗示需要非常詳細的設計層級作為編碼和測試的輸入，儘管無法確切說明它認為應該有多詳細。

它提出的書籍選擇並不可怕，儘管我對四人幫沒有列入推薦清單感到驚訝。（它在次要的「進一步閱讀」中，但不在主要的「推薦參考」部分。）

此流程區段極度仰賴基於測量的控制概念，而這概念有嚴重的缺陷，因為我觀察到您無法衡量生產力。顯然它強烈依循科學管理原則，因此完全忽略了人員和人際互動在流程中的角色。由於個人和互動比流程更重要，因此這是知識體系中的重大缺陷。

需求區段專注於在開始開發前製作全面的系統需求規格，這又是非常瀑布式的思考方式。（有趣的是，它顯示了螺旋模型的圖片，但僅用於製作需求文件！）在需求中探索成本取捨毫無意義，在我看來，這是任何需求工作的重要元素。

快速掃描完畢。我未來可能會再深入探討。但基本上我同意 Cem Kaner 的說法。我們的產業尚未成熟到可以產生這類型的知識體系。我們仍在學習許多關於軟體開發的知識，目前有許多不同的學派。軟體工程社群有自己的見解，這些見解可能適用於軟體開發的一部分。但目前尚未有廣泛的共識。

（如需進一步評論，請參閱Robert Levy。）