在软件开发的早期历史中出现了一些“神话”。这些神话不同于古代的神话，古代神话通常给人留下一些值得注意的教训，而软件神话传播的只是错误的消息和混乱，软件神话还常常不易被识破，它们看起来像是对事实的合理描述(有时还包含真实成份)，如果没有足够的学识和经验，就会相信这些神话。即使时至今日，一些软件神话仍然有人相信。下面就介绍一些较普遍的软件神话，同时也会给出神话背后真正的现实。这些神话和现实应当在软件工程培训的时候，讲给适合的人听，以澄清误解。
神话：一个对目标的总的描述就足以开始编写程序——我们可以在以后再填入细节。
现实：拙劣的提前定义是软件工作失败的主要原因，关于功能、 性能、接口、设计约束、和有效性准则的形式的和详细的描述是 基本的。这些特征只有在通过用户和开发者之间的详细沟通之后才能被决定。
剖析：这是一个非常普遍的神话。对于客户来说，似乎是合乎情理的。作为一个客户我只需要大致讲出想要的是什么东西，开发人员就应该给我开发出来。可是，如果告诉开发人员的只是一个模糊的东西，开发人员又怎能开发出来呢？或者，即使开发出来了，又怎会符合你心中所想呢？没有足够的细节支撑，一个笼统的描述客户和开发人员很难对最终产品达成一致理解。没有这个一致理解就动手开发，后面的变更就不可避免，变更的量积累到一定程度，就会影响项目的成败。毕竟，你不可能不考虑进度和成本。
神话的受众人群：这个神话和现实适合讲给客户和管理者听。
神话：一旦我们编写了程序并且使它远行，我的任务就已完成。
现实：软件开发存在着软件生存周期。初始工作集中在编制计划而不是 “编写程序”)，接着的工作集中于开发(设计、编码和测试)， 而最后，在软件是“完成的”情况下维护软件。
剖析：软件工程包括3个阶段，策划和分析、设计和实现、维护。编码和调试只是第二个阶段中的一个步骤而已。编码之前，要进行开发活动和策划，策划风险、资源、相关方，分析、确认和分配需求；调试之后，要进行单元、集成、系统测试，有了这些完整的活动，才能确保开发出了客户需要的软件，且软件能够安全可靠运行，这样才算完成了开发任务。
神话的受众人群：这个神话和现实适合讲给开发人员中的新人听。
神话：项目要求不断地改变，但是改变可以容易地适应，因为软件是灵活的。
现实：软件需求确实要改变这是对的，但是改变带来的影响随着改变引入的时间而不同。如果对提前定义给予认真的注意，改变可能容易适应。用户可以评审需求并建议作些修改，这时对成本影响相当小。而软件设计期间，需求改变，成本影响迅速增长。 资源已经调拨，初步设计构架已经建立，改变可能引起动乱，要求附加资源和修改主要设计，即增加成本。在实现(编码和测试)期间，改变功能、性能、接口、或其它特性会严重地影响代价。 在一个项目的末期需求改变，会比在早期要求同样的改变所花的经费多出一个数量级以上。
剖析：如果不计时间和成本，这个神话是成立的。可是，范围、时间和成本是制约项目的 3个因素，不计时间和成本的项目才是真正的“神话”。需求变更不是不能接受，而是有计划、有控制地接受。越早变更所需成本越少，所以项目早期的工作更为重要。
神话的受众人群：这个神话和现实适合讲给客户听。
神话：评审是多余的，太费时间或无法着手。
现实：评审是对于管理和技术控制所知道的仅有的措施。在软件开发工作的早期阶段，没有其它评价手段。
剖析：说评审“太费时间”，那是因为没有形成评审规程，评审人员选择不当，评审没有可遵循的准则，导致评审效果不佳。但这并不是评审这一机制是多余的理由。正相反，评审在软件工程活动中对于软件质量控制的重要性甚至高于测试。理由之一就是越早发现问题纠正成本越少。而且，在项目早期 ，评审几乎是唯一的质量控制措施。
神话的受众人群：这个神话和现实适合讲给管理层和开发人员听。
神话：如果我们落在了进度的后面，我们可以增加更多的程序员并且赶上进度(有时这称为“蒙古族游牧部落的概念”)。
现实：软件开发不是一种像生产制造那样的机械过程，当新人员加入时，他要学习并且需要工作人员之间的沟通，这可能并且确实减少了花在生产性开发工作上的时间，但是增加了沟通时间;人员可以增加，但只能有计划的并且以一种协调得很好的方式来增加人员。
剖析：“人多力量大”并不完全适合软件开发。一个由多个构件组成的复杂软件系统，如果几个构件的进度落后，就增加构件的开发人员，那么新增加的人员不仅要了解本构件的功能、性能、接口，不要了解上层构件的功能、性能、接口，了解项目的开发进度和其它管理和技术的要求，了解项目的设计约束……增加的人员越多，这个熟悉和了解的赶微信小程序开发时间就越长。如果软件的架构不清晰，这个时间更会多出无数倍。那样的话，进度只会被延误。
神话的受众人群：这个神话和现实适合讲给管理层听。
神话：一个成功的项目可交付使用的只是能运行的程序。
现实：一个能运行的程序仅仅是配置的一部份。文挡资料编制构成了成功开发的基础。并且，更重要的是，它提供了软件维护任务的指导。
剖析：要保证程序满足客户要求，就要按照软件工程的流程开展软件开发活动，策划-分析-设计-实现-测试，实现之前的各项活动的主要成果就是文档。有了这些策划文档、分析文档、设计文档，才能评价这些工作的质百度排名量。只有这些工作的质量得到保证，后面的程序质量才能保证。另外，软件将会后的维护阶段更需要有这些文档的支持，否则，维护成本可能会大于重新开发的成本。
神话的受众人群：这个神话和现实适合讲给管理层和开发人员听。
神话：一旦软件能够“运行”，维护是极少的，并且可以用一切方法进行处理。
现实：把一个相当小的预算比例分配给维护，但是在维护上的实际花费却超过预算的50%。所以，软件维护应该进行组织、计划 和控制。
剖析：软件维护包括纠错性维护和完善性维护前者是对客户使用软件遇到的测试遗留的BUG进行的纠错性质的维护；后者是为满足客户使用软件后提出新的需求而增加新的功能的维护活动。即使你设计水平再高，测试再完美，遗留缺陷再少，也避免取消了维护活动的产生。
神话的受众人群：这个神话和现实适合讲给管理层和开发人员听。
神话：给一个好的技术人员一本程序设计书，你已经拥有了一个程序员。
现实：我们已经说明了硬件工程和软件工程之间的相似性。如果我们接受“硬件工程需要正式训练”，那么，我们应该承认，只有通过正式教育和有价值的体验，才能达到软件工程能力。
剖析：这里定义的程序员，不是简单的“编码人员”。程序员应该是熟悉和了解软件工程，按照软件工程的要求开展软件开发活动，交付高质量的软件产品的。如果没有一定的软件工程实践，仅靠书本知识，是不可能完成这样的任务的。
神话的受众人群：这个神话和现实适合讲给管理层和开发人员听。
参考书目：《软件工程——实践者的研究途径和方法》
微信号：IdeaofSE
