软件方案 我为什么要写软件方案报告？

GJB2786A和GJB438B已经对软件的开发过程和开发过程中应该编写的文档类型进行了全面详细的规定。然而，我们的一些客户仍然要求我们编写一些只由系统或设备编写的文档，如软件方案报告、软件可靠性大纲等。这种文档不在我们前面提到的两个标准范围内。那么他们真的有必要写吗？

让我们试着弄清楚神圣的含义(如果把顾客当成上帝，上帝的话就是皇帝的旨意)。

当客户要求审查软件建议报告时，他的意图应该是查看软件是如何设计和实现的。这个初衷是正确的，应该得到我们开发者的支持。但是为什么看设计还要写软件项目报告呢？这不是软件开发的标准输出文档。如前所述，我们应该记录软件开发过程和开发过程的两个标准没有“软件方案报告”等输出文档。当客户要求开发人员准备软件方案报告时，必须借用系统或设备上“方案报告”的俗语。这可能是因为客户对软件开发过程和需求不太熟悉。他们更熟悉系统或设备的原始要求和实践。

另一方面，对于软件，软件的设计方案在软件设计规范中描述。在软件设计规范中，软件需求将被设计为实现了多少个软件单元，将描述这些软件单元形成稳定和可扩展的软件体系结构的方式，并将设计特定的单元以及它们之间的动态和静态关系。

所以，如果用户想看软件的设计方案，为什么不让开发者直接给出软件的设计描述呢？

再来说说软件可靠性大纲。

当客户提出编制软件可靠性大纲的要求时，也必须借鉴系统中“可靠性大纲”的说法。所以提出这个要求，说明客户重视软件的可靠性，希望软件能够可靠运行。在软件的实际使用过程中，软件零故障。

然而，系统和软件的可靠性要求并不完全相同。就系统而言，它具有定量的可靠性指标和一套成熟的可靠性预测、分配和评估方法。对于软件可靠性来说，系统的这种成熟方法可能并不适合。就可靠性指标而言，用平均故障间隔时间(MTBF)来衡量软件可靠性仍有争议，MTBF用于衡量系统可靠性。可靠性是软件的质量因素之一，也是软件规划中的一个关键要求，它也需要开发、设计、实现和验证。因此，软件的可靠性实际上已经分散在一系列的软件文档中，比如软件任务书、需求说明书、设计描述、测试计划、测试描述、测试报告等。

客户提出让软件开发人员在系统层面编译这些常用文档，可以说明两个问题:一方面说明客户对这些内容的重视；另一方面，这也表明客户对软件开发过程没有深刻的理解。客户的这种做法可能会造成一些不良后果。一方面可能不利于系统更好的顶层设计，不利于软硬件的有机结合，不利于系统的优化；另一方面，这种做法给软件增加了大量的文档工作，占用了开发者大量的时间，并可能缩短软件分析、设计和验证的时间，不仅对软件质量没有帮助，还可能对其造成危害。

让我们把我们的软件开发回归到原来正确的流程！即根据系统分配给软件的功能，做好需求分析、架构设计、详细设计、充分验证、质量保证。没有必要去做对这些工作没有帮助的事情。