您会产生哪些基本的设计工件？

在软件开发生命周期中，您会产生哪些重要的设计工件？是什么使它们对您的练习至关重要？

我目前正在进行的项目已经进行了8年。在此期间，该Web应用程序得到了积极的增强和维护。尽管我们已经制定了基于CMMI的策略和流程，并且对部分实践进行了明确定义，但设计阶段却被大大忽略了。最佳做法，有人吗？

---

过去曾在很多瀑布项目上工作，最近又在很多临时项目和敏捷项目上工作，尽管我不能说出它真正取决于什么，但我还是喜欢创建许多设计工件。项目的详细信息(方法/团队结构/时间表/工具等)。

对于基于服务器的通用\\'企业应用程序\\'，我希望最低限度应遵循以下原则：

• 详细的功能设计文档(又称规范)。尽管可能带有一些UML用例图，但通常与Joel的WhatsTimeIsIt示例规范相似。
• 软件技术设计文档。对于100％的系统覆盖率并不一定要详细说明，但应在所有关键领域进行详细说明并包含所有设计决策。有点UML怪异之处，很高兴能沿着package图，组件图，关键要素类图以及可能抛出的一些顺序图的路线看到很多图片。
• 基础结构设计文档。可能使用UML部署图进行概念设计，或者使用网络图进行更实际的设计。

当我说文档时，以上任何内容都可能分解为多个文档，或者可能存储在Wiki /其他工具上。

关于其有用性，我的理念一直是：开发团队应始终能够将应用程序移交给支持团队，而不必移交他们的电话号码。如果设计工件没有说明应用程序的功能，如何执行以及在何处执行，那么您将知道支持团队将给予应用程序相同的照顾和关注，就像狂犬病一样。

我应该提及的是，我并没有证明一旦完成将软件从开发团队移交给支持团队的做法，这引发了各种有趣的问题，我只是说应该如果需要，可以进行管理。

---

工作代码...和白板图纸。

：P

---

本质上，这不是设计文档，但是我们的单元测试具有双重目的，即"描述"其测试代码应如何工作。这样做的好处是它们永远不会过时，因为必须通过单元测试才能使我们的构建成功。

---

在我们的模型(非常特定于业务流程应用程序)中，设计伪像包括：

• 域数据模型，其中包含对每个实体和属性的注释
• 一个属性文件，列出每个实体上的所有修改和创建触发器，计算出的属性，验证器和其他业务逻辑
• 一组屏幕定义(视图模型)

但是这些真的算作设计文物吗？我们的框架是这样的，这些定义用于生成系统的实际代码，因此它们可能超出了设计范围。

但是，它们具有双重职责这一事实之所以强大是因为，按照定义，它们是最新的，并且始终与代码保持同步。

---

设计在开发过程中发生了很大的变化，此后，一旦代码投入生产，我精心制作的大多数文档就会在源代码管理中流失，几乎成为一种障碍，而不是帮助。我认为设计文档对于进行良好的交流和澄清您在开发某些东西时的想法是必不可少的，但是在此之后，需要花大力气来保持它们的正确维护。

我确实为白板拍照，并将JPEG保存到源代码管理中。这些是我最好的一些设计文档！

---

由于以下原因，我认为没有什么可以代替良好的老式设计规范：

• 它是与他人交流如何构建应用程序的一种手段。
• 它使您可以从头脑中获得灵感，因此您不必担心同时跟踪一百万个事物。
• 如果您必须暂停一个项目然后稍后再返回，则无需重新开始思考过程。

我喜欢在设计规范中查看各种信息：

• 您应对挑战的方法的一般说明
• 您将如何监视您的应用程序？
• 有哪些安全问题，如何解决？
• 流程图/顺序图
• 开放式问题
• 已知限制

单元测试虽然是应用程序开发中不可思议且至关重要的项目，但并未涵盖所有这些主题。

---