关于软件神话

关于软件神话，摘抄一些句子。觉得还是很有道理的，人常常会在同一个问题上反复犯错误，最好的解决办法，就是记下来。

[b]管理者的神话[/b]：负责软件的管理者象大多数其他行业的管理者一样，都有巨大的压力，要维持预算、保持进度及提高质量。就像溺水者抓住一根救命稻草，软件管理者常常抓住软件神话不放，[b]如果这些神话能够缓解其压力的话[/b](哪怕是暂时的)。

[b]神话[/b]：我们已经有了关于建造软件的标准和规程的书籍，难道它们不能给人们提供所有其需要知道的信息吗？
[b]事实[/b]：不错关于标准的书籍已经存在，但真正用到了它们吗？软件实践者知道它们的存在吗？它们是否反映了现代软件开发的过程？它们完整吗？很多情况下，对于这些问题的答案均是“不”。
[i][b]新的神话[/b]：过度一栏软件工程的流程和规范，而忽略了软件是由人来创造的。这些人既不是艺术家也不是工程师，而应被称为[b]工匠[/b][/i]


[b]神话[/b]：我们已经有了很多很好的软件开发工具，而且，我们为它们买了最新的计算机。
[b]事实[/b]：为了使用最新型号的主机、工作站和PC机去开发高质量的软件，我们已经投入太多的费用。[b]实际上，计算机辅助软件工程(CASE)工具相比起硬件而言对于获得高质量和高生产率更为重要，但大多数软件开发者并未使用它们[/b]。
[i][b]新的神话[/b]：过度迷恋最新的工具或者是技术，云计算，虚拟化或者SOA之类的，期待能够彻底改变软件工程中的弊端。但事实上软件工程自诞生以来，从未过出现革命性的技术能做到这一点，不管那些大公司如何吹嘘[/i]


[b]神话[/b]：如果我们已经落后于计划，可以增加更多的程序员来赶上进度(“有时称为蒙古大夫概念”)。
[b]事实[/b]：软件开发并非象制造一样是一个机械过程。用Brooks［BRO75］的话来说，“给一个已经延迟的软件项目增加人手只会使其更加延迟”。看起来，这句话与人的直觉正好相反。但实际上，增加新人，原来正在工作的开发者必须花时间来培训新人，这样就减少了他们花在项目开发上的时间。[b]人手可以增加，但只能是在计划周密、协调良好的情况下[/b]。
[i][b]新的神话[/b]：敏捷开发认为可以通过灵活多变的计划方式避免这样的问题，但事实上帮助微乎其微，所以我们曾经遇到的问题，在敏捷开发中都会遇到。Agile至多也只是提供了一种心理上的安慰。[/i]

[b]用户的神话[/b]：需要计算机软件的用户可能就是邻桌的人，或是另一个技术组，也可能是市场/销售部门，或另外一个公司。在许多情况下，用户相信关于软件的神话，因为负责软件的管理者和开发者很少去纠正用户的错误理解。神话导致了用户过高的期望值，并引起对开发者的极端不满意。

[b]神话[/b]：有了对目标的一般描述就足以开始写程序了——我们可以以后再补充细节。
[b]事实[/b]：[b]不完善的系统定义是软件项目失败的主要原因[/b]。关于待开发项目的应用领域、功能、性能、接口、设计约束及确认标准的形式化的、详细的描述是必需要的。这些内容只有通过用户和开发者之间的通信交流才能确定。
[i][b]新的神话[/b]：有关此项，敏捷开发与传统开发方式仍在大战中，很难说清楚谁对谁错。[/i]

[b]神话[/b]：项目需求总是在不断变化，但这些变化能够很容易地满足，因为软件是灵活的。
[b]事实[/b]：软件需求确实是经常变化的，但这些变化产生的影响会随着其引入的时间不同而不同。如果我们很注重早期的系统定义，这时的需求变化就可被很容易地适应。用户能够复审需求，并提出修改的建议，这时对成本的影响会相对较小。当在软件设计过程中才要求修改时，对成本的影响就会提高得很快。资源已经消耗了，设计框架已经建立了，这时的变化可能会引起大的改动，需要额外的资源和大量的设计修改，例如，额外的花费。实现阶段(编码和测试阶段)功能、性能、接口及其他方面的改变对成本会产生更大的影响。当软件已经投入使用后再要求修改，这时所花的代价比起较早阶段做同样修改所花的代价可能是几何级数级的增长。
[i][b]新的神话[/b]：有关此项，敏捷开发与传统开发方式仍在大战中，很难说清楚谁对谁错。[/i]

[b]开发者的神话[/b]：那些至今仍被软件开发者相信的神话是由几十年的程序设计文化培植起来的。正如我们在本章一开始就提到的，在软件的早期阶段，[b]程序设计被看作是一门艺术[/b]。这种旧的观念和方式是很难改变的。

[b]神话[/b]：一旦我们写出了程序并使其正常运行，我们的工作就结束了。
[b]事实[/b]：有人说过：“越早开始写程序，就要花越长时间才能完成它”，产业界的数据表明在一个程序上所投入的50％到70％的努力是花费在第一次将程序交给用户之后。
[i][b]新的神话[/b]：究竟该何时交付可以使用的程序，现代的开发流程认为应该尽早交付可运行的程序。[/i]

[b]神话[/b]：在程序真正运行之前，没有办法评估其质量。
[b]事实[/b]：从项目一开始就可以应用的最有效的软件质量保证机制之一是正式的技术复审。软件复审(见第8章)是“质量的过滤器”，比起通过测试找到某类软件错误要有效得多。（[i]事实上，有一种理论说测试并没有真正改善软件质量[/i]）

[b]神话[/b]：一个成功项目唯一应该提交的就是运行程序。
[b]事实[/b]：运行程序仅是软件配置的一部分，软件配置包括：程序、文档和数据。文档是成功开发的基础，更重要的是，文档为软件维护提供了指导。