(转)《软件工程的事实与谬论》

《软件工程的事实与谬论》

作者：hydrangea

========================================

软件工程的事实与谬论
Facts and Fallacies of Software Engineering

========================================

第一章 管理

1.1 人员

　　事实1：在软件开发中，最重要的因素不是程序员采用的工具和技术，而是程序员自身的质量。

　　事实2：对“个体差异”的研究表明，最好的程序员要比最差的程序员强28倍之多，即使他们的报酬不同，优秀的程序员也是软件业中最廉价的劳动力。

　　事实3：给延期的项目增加人手会使项目进一步延期。

　　事实4：工作环境对工作效率和产品的质量具有深刻的影像。

1.2 工具和技术

　　事实5：夸大宣传是软件的瘟疫。多数软件工具对于效率和质量的提高幅度仅为5%～35%。但是总有人反复说提高幅度是“数量级”的。

　　事实6：在学习新工具或者新技术的初期，程序员的工作效率和产品质量都会下降，只有克服了学习曲线之后，才可能得到实质性的收益。只有满足下面两个条件，采用新工具或新技术才有意义：(a)新东西确实有用；(b)要想获得真正的收益，必须耐心等待。

　　事实7：软件开发者对于工具说的多，评估的少，买的多，用的少。

1.3 估算
    事实8：项目失控的两个最主要原因之一是糟糕的估算。
    事实9：许多估算是在软件生命周期开始时完成的。后来，我们才认识到在需求定义之前，即理解问题之前进行项目估算是不正确的；也就是说，估算实际是错误的。
    事实10：许多软件项目都是由高层管理人员或者营销人员来估算，而不是由真正构建软件的人或者他们的主管来进行估算。因此，估算软件的人员是错误的。
    事实11：软件估算很少根据项目进度进行调整。因此，这些估算通常是错误的人在错误的时间的出的错误的结果。
    事实12：因为估算的数据如此糟糕，所以在软件项目不能达到估算目标时，不应该再考虑估算。但是无论如何，每个人都在考虑它。
    事实13：在管理者和程序员之间存在隔阂。对于一个未满足估算目标的项目的调查表明：从管理者看来这是一个失败的项目，而在技术人员看来却是最成功的项目。
    事实14：对于可行性调研的回答几乎总是“可行”。

1.4 复用
    事实15：小规模的复用（子程序库）开始于50多年以前，这个问题已经得到很好的解决。
    事实16：虽然每个人都认为大规模复用（组件）非常重要、非常急需，但是这个问题至今还没有基本解决。
    事实17：大规模复用最好适用于相关的系统，也就是依赖于具体应用领域，这样就限制了它的应用范围。
    事实18：有关复用问题，有两个“三倍法则”：（a）构建可复用的组建比使用组建难三倍；（b）在将组建收录到复用库并成为通用组件之前，应该在三个不同的应用中尝试应用该组件。
    事实19：修改复用的代码特别容易引起错误。如果一个组件中超过20%～25%的代码需要修改，那么重新实现的效率会更高。
    事实20：设计模式复用是解决代码复用中故有问题的一种方法。

1.5 复杂性
    事实21：问题的复杂性每增加25%，解决方案的复杂性就增加100%。这不是一个可改变的条件（即使人们都努力降低复杂性），而是客观存在的。
    事实22：80%的软件工作是智力活动。相当大的比例是创造性的活动。很少是文书性的工作。
    事实22，好像忽略了“体力劳动”?

2.1 需求
    事实23：导致项目失败的两个最常见原因之一是不稳定的需求（另一个见事实8所说的项目估算失误）。
    事实24：在产品完成时修订需求错误的代价最大，在开发早期修订需求错误的代价最小。
    事实25：遗漏需求是最难修订的需求错误。

2.2 设计
    事实26：从需求转入设计，因为制定方案过程的复杂性，会激增出大量的衍生需求（针对一种特定设计方；案的需求）。设计需求是原始需求的50倍之多。
    事实27：对于一个软件问题，通常不存在惟一的最佳设计方案。（对于同一个问题的定义，多位优秀的设计者通常也不可能提出完全相同的最优设计方案。“在一个房间中坐满了顶级的软件设计人员，如果其中任意两个人达成一致，那就可以通过了”）
    事实28：设计师一个复杂的、迭代的过程。最初的设计方案可能是错误的，当然也不是最优的。

2.3 编码
    事实29：从设计转到编码阶段时，设计者按照自己掌握的水平，已经将问题分解为“原语”。如果编程者和设计者不是同一个人，二者的“原语”不吻合，就会出现问题。
    事实30：COBOL是一种非常糟糕的语言，但是其他的（用于商业数据处理的）语言也同样糟糕。

2.4 错误消除
    事实31：错误消除是软件生命周期中最耗时的阶段。

2.5 测试
    事实32：普通程序员认为已经彻底测试过的软件其实只执行了55%～60%的逻辑路径。采用覆盖分析器等自动工具，可以将上述比例提高到85%～90%。几乎不可能测试软件中100%的逻辑路径。
    事实33：及时测试覆盖可能达到100%，这种测试也不够。大约35%的错误是源于逻辑路径的缺失，还有40%的错误源于执行特定的路径组合。不可能实现100%的覆盖。
    事实34：没有工具就无法做好错误消除工作。人们常用调试器，很少使用覆盖分析器等其他工具。
    事实35：自动测试很少，也就是说有些测试可以也应该自动化，但是有许多测试任务不能自动完成。
    事实36：程序员在程序中嵌入测试代码、目标代码中的编译参数等方法，都是测试工具的重要补充。

2.6 评审和检查
    事实37：在运行第一个测试用例之前进行严格审查可以消除软件产品中多大90%的错误。
    事实38：虽然严格审查由很多优点，但是不能也不应该代替测试。
    事实39：通常认为，事后评审对于了解客户的满意度和改进过程都很重要。但是很多软件公司不开展事后评审。
    事实40：同行评审涉及技术和社会两方面问题，忽视任何一方面都会产生严重的灾难。（这一点一定要记住，现在已经遇到这方面的问题，经理参与技术评审，往 往偏离主题，他们评审的不是技术，而是技术人员。通常搞得技术人员非常不爽。关系好的一帮人员一起评审，也应该抛开个人因素，记住，评审的是技术，不是 人。）

2.7 维护
    事实41：维护开支通常占软件成本的40%～80%（平均为60%）。因此，维护可能是软件生命周期中最重要的阶段。
    事实42：增强功能大约占软件维护成本的60%，错误更正仅占17%。因此，软件维护的主题是在旧软件中加入新功能，而不是更正错误。
    事实43：维护是解决方案，而不是问题。
    事实44：比较软件开发和软件维护中的工作，除了维护中“理解现有的产品”这项工作之外，其他工作都一样。这项工作占据了大约30%的维护时间，是主要的维护活动。因此可以说维护比开发更难。
    事实45：更好的软件工程开发导致更多而不是更少的维护。

3.1 质量
    事实46：质量是一组属性的组合。
    事实47：软件质量不是用户满意、满足需求、满足成本和时间表目标，或者可靠性。

3.2 可靠性
    事实48：绝大多数程序员都会犯某些错误。
    事实49：错误通常聚集在一起。
    事实50：没有惟一最好的消除软件错误的方法。
    事实51：总会有残存的错误。我们的目标应该是消除严重错误，或者使之最少。

3.3 效率
    事实52：效率主要来自于优秀的设计，而不是优秀的编码。
    事实53：高级语言代码配合适当的编译器优化，大约可以达到汇编语言90%的效率。对于一些复杂的现代体系结构，效率更高。
    事实54：在空间和实践之间折中。通常，改进一方面会降低另一方面。

4. 研究
    事实55：许多软件研究者不是做调查，而是鼓吹。因此，（a）有些概念比鼓吹的糟糕、更少；（b）缺少有助于确定这些概念真实价值的评估性研究。

========================================

下面是十个谬误：

    5. 管理
    谬误1：你不能管理自己无法度量的东西。（你无法控制自己无法度量的东西。DeMarco）
    谬误2：可以管理软件产品的质量。

    5.1 人员
    谬误3：可以，也应该“忘我”地编程。

    5.2 工具和技术
    谬误4：工具和技术是通用的。
    谬误5：软件需要更多的方法论。

    5.3 估算
    谬论6：要估算成本和时间表，应首先估算代码行数。

    6. 生命周期

    6.1 测试
    谬误7：随机测试输入是优化测试的好方法。

    6.2 评审
    谬误8：“假如有了足够多的关注，所有的BUG都显而易见。”

    6.3 维护
    谬误9：估计将来的维护成本和做出产品更新的决策需要参考过去的成本数据。

    7. 教育
    谬误10：教别人编程的方法是教别人写程序。