软件危机和软件缺陷的特点和区别

软件危机和软件缺陷的特点和区别

由于软件危机和软件缺陷存在互相促进的可能性，很多情况下较难从事故现场对两者进行一个清晰、明确的划分，从软件开发的5个阶段——需求、设计、编码、测试和维度逐一讨论或许是个不错的尝试。

需求阶段

作为软件开发流程的排头兵，这一阶段累积的各种错误都会以不同的形式迁移转化为各种地雷在接下来的开发流程中引爆。最明显的一类就是软件缺陷需求范围上的错误，如“软件未达到产品说明书中已经注明的功能”、“软件未达到产品说明书中虽未指明但应明显达到的目标”、“软件功能超出产品说明书指明的范围”等等。具体分析各个案例可以发现，这些事故往往伴随着需求不清、需求频繁变更或需求广泛等特点。

虽然需求阶段的错误也会引发软件危机，但这往往是通过某种间接的机制实现的，不像软件缺陷一样是直接作用。如通过影响人事安排、经费预算、时间预期等来促使一线开发人员“走捷径”、不管“技术债”、疯狂赶ddl交付项目等。

此外，从交付结果来看，软件缺陷至少能够提交一个阉割版的产品，但软件危机往往导致项目延期，或者从此搁浅，成为“烂尾楼”。

设计阶段

在排除设计阶段极度压榨编码阶段的前提下，基本少见软件危机直接或间接在这一阶段产生影响。设计阶段出现的多数糟心事都是需求阶段进一步迁移转化而来的。可见连目标都不清楚，即使有鬼斧神工也白搭。

编码阶段

在较为大型、正规的互联网公司和组织中，这一阶段较少见到直接由软件缺陷造成的影响或故障，更多的案例是由软件危机导致的。外行领导内行、上级疯狂push疯狂pua、ddl越来越近……在这样的压力之下，很少还有程序员能坚守自己的技术操守继续做下去，要不提桶走人、要不置“技术债”于不顾，进而出现开发人员和开发过程