开发后创建软件设计文档是否合理？

我目前正在为我的“软件开发”研究而毕业，在该研究中，我必须在外部公司中单独开发复杂的软件。所有这些都需要以结构化的方式完成，创建所有相应的文档。

对于这个项目，我选择使用IEEE标准文档：软件需求文档（SRS），软件体系结构文档（SAD）和软件设计文档（SDD）。尽管在学校另有授课，但对于该项目，我选择在开发后（而不是之前）创建SDD 。我的理由是：

我从事实习的公司给了我指导，以实验方式创建满足某些要求的复杂软件。由于他们在项目定义中给了我很大的自由度，因此几乎没有什么可以事先确定的，并且在开发过程中进行试验时最好能遇到。此外，我以个人方式创建软件，对于公司中的其他任何人来说，事先进行此软件设计对我来说都是没有好处的。事前做会花很多时间，以后再做，因为我可以确定由于项目的不确定性，我做的设计必须作很多改动。这对我来说适得其反。

在开发后创建SDD是否有充分的理由？如果没有，那有什么正当理由吗？

编辑：之后创建SDD的原因是为了将来的开发人员继续该项目。在毕业期间，我将无法完成整个项目，因此其他开发人员将不得不继续使用当前的代码库。

在上下文中的IEEE Std 1016第3.1节软件设计中，您可以找到以下段落：

可以准备SDD，并在各种设计情况下使用。通常，SDD准备支持软件项目的开发以解决问题，其中已根据一组要求表达了此问题。然后可以将SDD的内容追溯到这些要求。在其他情况下，SDD准备了解缺乏设计文档的现有系统。在这种情况下，需要准备SDD，以便捕获，组织，呈现和分发感兴趣的信息给所有相关方。通过识别和解决基本的设计问题，可以将该感兴趣的信息用于软件系统的计划，分析，实现和发展。

IEEE Std 1016的作者认识到SDD可能不会预先创建。可以在软件系统存在后创建一个，以便为感兴趣的各方捕获信息。

第1.1节范围还提供了一些有趣的信息：

该标准没有规定用于设计，配置管理或质量保证的特定方法。

在这个问题的上下文中，关键词是“配置管理”。配置管理不仅适用于正在创建的软件系统，而且还适用于任何相关文档。

在您个人的情况下，以及在许多情况下，预先创建SDD都是浪费。David Arno的答案几乎是我认为正确的答案。您的软件系统的真正设计是代码。但是，“在此之前创建SDD”或“在此之后创建SDD”并不是您唯一的选择。您还有第三种选择-使用软件系统开发SDD。

如果您遵循IEEE Std 1016之类的标准，则对SDD有要求。具体来说，本标准的第4节定义了您所拥有的内容。在进行设计决策时，开始创建不同的视点，视图和叠加层。在做出决策时，请抓住它们的设计原理。

这将使有兴趣的各方能够跟踪软件设计的发展，而无需深入研究代码。当然，人们可能有意见或建议。如果您要更新SDD，他们可以跟踪您的进度并尽早提供有关方法的反馈，然后您可以将其纳入产品和SDD中。当您退出项目时，如果软件代码和SDD是同步的，则有人应该可以轻松地入职并接管工作。

如果您要从SDD中寻找的只是与他人进行设计交流，那么可以，您可以在开发后创建它。唯一的是，它被称为文档。

但是，我想指出的是，SDD也可以用于其他目的。它还可以帮助您推理设计并确保“快速失败”。这是一件好事，尤其是如果很多事情事先不确定的时候，因为您可以放弃在整个实现初期就无法使用的方法。通过在弄清楚设计之前不进行任何编码，它还可以防止您很快关注技术细节。

我建议您至少先尝试一下SDD。如果遇到不确定如何工作的事情，则可以为要解决的问题制作小型原型。从长远来看，这将为您提供解决项目中特定问题的经验，这将有益于整个解决方案的质量。

您将创建的一个真正的详细设计文档是代码。它恰好告诉编译器如何构建您的应用程序。因此，您的设计要等到发货前完成最后一个构建才能完成。

完成设计（代码）后，您创建的任何其他设计文档（如SDD）都需要更新。因此，之后有一个令人信服的理由编写SDD：您只需要做一次。

明显的反驳是“ 事件发生后您真正多久编写一次SDD ”？该应用程序已交付，因此您不太可能希望在该阶段花时间记录文档。但这同样适用于更新现有的。更糟的是，没有SDD或SDD错误且无法信任吗？

但是有两个原因需要事先编写。首先，这可能是您的强制性要求（不好，但这确实发生了）。其次，创建这样的文档可以帮助您制定设计的总体策略。但这可以通过以非正式方式绘制图片，涂鸦笔记等来很好地完成。而且，由于以后需要重写，因此“快速而肮脏的”方法在前期宏设计过程中有很多好处。

对我来说，这不是一个很好的论据。

如果确实需要，我将重点放在原型开发上，以更好地了解未知的问题领域。但是，即使在那种情况下，以前的一些设计还是有用的。

无论如何，都需要事先做一个案例。因为这样做是为了学习有关编写此类文档的知识。跳过这项工作是因为这里可能不需要100％的学习，这意味着您可以跳过学习。

一个折衷的办法是在实现过程中编写它。在程序的每个组件/模块/屏幕或其他细分之前，您需要考虑如何制作它。然后，将您的决定添加到设计文档中，然后执行它们。

如果以后有任何更改，请更新文档。

与事后编写相比，它具有多个优点：

• 当需求发生变化时，您将学会保持设计文档的更新，这是一个有用的习惯

• 在实施之前，您将学习思考设计

• 事实并非如此，这不像编写设计文档那样令人讨厌

• 如果时间用完了，则会有一个设计文档来描述您到目前为止所拥有的，以便其他人继续您的工作

• 这样就不需要太多额外的工作

• 随着项目的进行，您可能不太确定为什么自己要在两个月前以这种方式进行操作，并且您会得到一些笔记来告诉您。

系统设计文档，记录了基本要求以及（新功能）随着项目的发展而不断更新的新设计和解决方案属性。一直保持到交付项目/解决方案为止。有用，它可以与所有相关人员进行通信。