软件工程知识体系（SWEBOK）

这是 IEEE 软件工程知识体系 审查的月份。这是试图以一种可以为获得执照的职业奠定基础的方式来定义我们职业的知识体系。

通常我会忽略这样的事情。有大量的 IEEE 标准被从事商业软件开发的任何人 routinely 忽略。它们大多是由学者和参与大型政府项目的人编写的。商人并不认为政府是效率的同义词。

但 Cem Kaner，我学会尊重他的判断，却认真对待它。在他的 博客 中，他说：“如果 SWEBOK 是执照考试的基础，那么 SWEBOK 中的实践将被视为医疗过失诉讼的基础。在 SWEBOK 中执行所谓良好实践的人，如果他们因医疗过失而被起诉，将能够在法庭上为自己的实践辩护。那些采用可能好得多的实践，但与 SWEBOK 冲突的实践的人，将在法庭上冒着受到严厉批评的风险。作为执照考试的基础，SWEBOK 成为获得执照的职业将要获得的关于该领域批准实践的官方声明。”

那么 Swebok 有多大的缺陷呢？这个月我非常忙，所以没有时间详细研究它。仅仅阅读几个部分就足以引起一些警示，并且肯定可以证实 Swebok 对计划驱动开发过分强调的观点，这种程度排除了敏捷方法。

我查看的第一个部分是关于设计的。显然 Swebok 将设计视为与编程分离的活动——这与敏捷运动中的大多数人相矛盾。它暗示需要非常详细的设计级别作为编码和测试的输入——尽管无法确定它实际上认为应该有多详细。

它提出的书籍选择并不糟糕——尽管我感到震惊的是 四人帮 没有进入推荐列表。（它在次要的“进一步阅读”中，但不在主要的“推荐参考”部分。）

过程部分严重依赖于基于测量的控制的概念，这是严重有缺陷的，因为我观察到您 无法衡量生产力。它显然是基于科学管理原则，因此完全忽略了人员和人际互动问题在过程中的作用。同样，由于个人和互动胜过过程，这是知识体系中一个巨大的漏洞。

需求部分集中在开发开始之前生成全面的系统需求规格说明——这再次是典型的瀑布式思维。（有趣的是，它显示了一个螺旋模型的图片——但只是为了生成需求文档！）它没有考虑在需求中探索成本权衡——在我看来，这是任何需求工作中至关重要的因素。

好了，快速浏览就到这里。我将来可能会进一步研究。但从根本上说，我同意 Cem Kaner 的观点。我们的行业还没有成熟到足以产生这种知识体系。我们仍在学习关于软件开发的许多知识，目前存在许多学派。软件工程界有自己的观点，这些观点可能适用于软件开发的一部分。但目前还没有广泛的共识。

（有关更多评论，请参阅 Robert Levy。）