软件工程的事实与谬误

软件工程的事实与谬误 
   Robert L. Glass 
事实1：在软件开发中，最重要的因素不是程序员采用的工具和技术，而是程序员自身的质量。 
事实2：对“个体差异”研究表明，最好的程序员要比最差的程序员强28倍之多，即使他们的报酬不同，优秀程序员仍是软件业中最廉价的劳动力。 
事实3：（Brook法则）给延期的项目增加人手会使项目进一步延期。 
事实4：工作环境对工作效率和产品质量有深刻影响。 
事实5：多数软件工具对于效率和质量的提高幅度仅为5%~35%，但是总有人反复说提高幅度是数量级的。 
事实6：学习新工具和新技术的初期，程序员的工作效率和产品质量都会下降，只有克服了学习曲线以后，才可能得到实质性的收益。 
事实7：软件开发者对工具说得多，评估得少，买得多，用得少。 
事实8：项目失控的两个主要原因之一是糟糕的预算。 
事实9：许多估算是在软件生命周期开始时王承德，后来，我们才认识到在需求定义以前，即理解问题之前尽心项目估算是不正确的；也就是说，估算时机是错误的。 
事实10：许多软件项目是由高层管理人员获营销人员来估算，而不是真正构建软件的人或是他们的主管来进行估算。因此，估算软件的人员是错误的。 
事实11：软件估算很少根据项目进度进行调整。因此，这些估算通常是错误的人在错误的时间得出的错误结果。 
事实12：因为估算的数据是如此的糟糕，所以在软件项目不能达到估算目标时，不应该再考虑估算。但无论如何，每个人都在考虑它。 
事实13：在管理者和程序员之间存在隔阂。对于一个未满足估算目标的项目的调查表明：从管理者看来失败的一个项目，而是技术人员看来却是最成功的项目。 
事实14：对于可行性调研的回答几乎总是可行。 
事实15：小规模的复用（子程序库）开始于50多年以前，这个问题已经得到很好的解决。 
事实16：虽然每个人都认为大规模的复用（组件）非常重要，非常急需，但这个问题至今还没有基本解决。 
事实17：大规模复用最好使用于相关的系统，也就是依赖于具体应用领域，这样就限制了它的应用。 
事实18：有关复用问题，有两个“三倍法则”：（1）构建可复用组件比使用组件难三倍。（2）在将组件收录到复用库并成为通用组件之前，应该在三个不同的应用中尝试应用该组件。 
事实19:修改复用的代码特别容易引起错误。在一个组件中超过20%~25%的代码需要修改，那么重新实现效率会更高。 
事实20：设计模式复用是解决代码复用中固有问题的一种方法。 
             设计模式源于实践，而不是理论。 
事实21：问题的复杂性增加25%，解决方案的复杂性就增加100%。这不是一个可改变的条件（即使人们努力降低复杂性），而是客观存在的。 
事实22：80%的软件工作是智力活动，相当大的比例是创造性的活动，很少是文书性的工作。 
事实23：导致项目失控的两个常见原因之一是不稳定的需求。 
事实24：在产品完成时修订需求错误的代价的最大，在开发早期修订需求错误的代价的最小。 
事实25：遗漏需求是最难修订的需求错误。 
最持久的软件错误是遗漏逻辑错误，它可以逃离软件测试过程，进入发布的产品中。遗漏需求导致遗漏逻辑。 
事实26：从需求转入设计时，因为制定方案的复杂性，会激生出大量的衍生需求（针对一种特定设计方案的需求）。设计需求是原始需求的50倍之多。 
事实27：对于一个软件问题，通常不存在唯一的最佳设计方案。 
事实28：设计是一个复杂的迭代的过程，最初的设计方案可能是错误的，当然也不是最优的。 
事实29：从设计转向编码阶段，设计者按照自己的水平，已经将问题分解成原语。如果编程者和设计者不是同一个人，二者的原语不吻合，就会出现问题。 
事实30：COBOL语言是一种非常糟糕的语言，但是其他的（用于商业数据处理的）语言也同样糟糕。 
事实31：错误消除是软件生命周期中最耗时的阶段。 
         Checkout 检出testing 测试 verification and validation 验证和确认 
事实32：普通程序员认为已经彻底测试过的软件其实只执行了55%~60%的逻辑路径。采用覆盖分析器等自动化工具，可以将上述比例提高到85%~90%。几乎不可能测试软将中100%的逻辑路径。 
      需求驱动测试（测试是否满足了需求） 
      结构驱动测试（测试已构建的软件所有组成部分是否正确运行） 
      统计驱动测试（随机测试确定软件执行的时间和结果） 
      风险驱动测试（测试确定是否已经消除了最重要的风险） 
事实33：即使测试覆盖有可能达到100%，这种测试也不够。大约35%的错误来源于逻辑路径的缺失，还有40%的错误来源于执行特定路径的组合。不可能实现100%的覆盖。 
事实34：没有工具就无法做好错误消除工作。人们常用调试器，很少使用覆盖分析器等其他工具。 
事实35：自动测试很很少，也就是说有些测试可以也应该自动完成，但是有许多测试任务不能自动完成。 
事实36：程序员在程序中嵌入测试代码，目标代码中的编译参数等方法，都是测试工具的重要补充。 
事实37：在运行第一个测试用例之前进行严格的审查可以消除软件产品中多达90%的错误。 
事实38：虽然审查有很多优点，但是不能也不应该代替测试。 
事实39：事后评审对于了解客户的满意度和改进软件过程都很重要。但是很多公司不开展事后评审。 
       多数人建议在软件交付3~12个月进行事后评审。 
事实40：同行评审涉及技术和社会两个方面的问题，忽视任何一方面都回产生严重的灾难。事实41：维护开支通常占软件成本的40%~80%（平均60%）。因此，维护可能是软件爱女生命周期中最重要的阶段。 
    古老的硬件会被废弃，古老的软件每天都在使用。 
事实42：增强功能大约占软件维护成本的60%，错误更正仅占17%，因此，软件维护的主题是在旧软件中加入新功能，而不是更正错误。 
事实43：维护是解决方案，而不是问题。 
事实44：比较软件开发和软件维护中的工作，除了维护中“理解现有的产品”这项工作以外，其他工作都一样。这项工作占据了大约30%的维护时间，是主要的维护活动。因此可以说维护比开发更难。 
事实45：更好的软件过程开发导致更多而不是更少的维护。 
事实46：质量是一组属性的集合。 
        可靠性是指软件产品满足预期要求，值得信赖。 
人类工程学（可用性）软件用起来容易舒服。 
易理解和易维护性 
效率是指软件产品在运行时间和空间消耗上的经济性。（有些应用中应在首位） 
可测试性 
可移植性指易于在不同的平台之间移植的软件产品。 
事实47：软件质量不是用户满意，满足需求，满足成本和时间表，或者可靠性。 
事实48：绝大多数程序员会犯某些错误。 
N-Version ,fault-tolerant programming容错编程 
事实49：错误通常聚集在一起。 
事实50：没有唯一的最好的消除软件错误的方法。 
事实51：总会有残存的错误。我们的目标是消除严重错误，或是使之减少。 
事实52：效率主要来自优秀的设计，不是优秀的编码。 
        极限编程运动倡导简单化的设计方法和快速进入编码阶段。 
        极限编程强调：在编码之后通过持续地重构(refactoring)来修订设计汇总的低效率和事实53:高级语言代码配合适当的编译器优化，大约可以达到汇编语言的90%的效率。对于一些复杂的现代体系结构，效率更高。 
事实54：在时间和空间之间存在折中，通常改进一方面会降低另一方面。 
事实55：许多软件研究者不是调查，而是鼓吹。 
谬误1：要估算成本和时间表，应首先估算代码行数。 
谬误2：随机测试输入是优化测试的好方法。 
谬误3：加入有了足够的关注，所有的错误都显而易见。 
谬误4：估计将来的维护成本和做出产品更新的决策需求需要参考过去的成本数据。 
谬误5：教别人编程的好方法是教别人写程序。（应先阅读）。