What essential design artifacts do you produce?在软件开发生命周期中，您会产生哪些重要的设计工件？是什么使它们对您的练习至关重要？ 我目前正在进行的项目已经进行了8年。在此期间，该Web应用程序得到了积极的增强和维护。尽管我们已经制定了基于CMMI的策略和流程，并且对部分实践进行了明确定义，但设计阶段却被大大忽略了。最佳做法，有人吗？ 过去曾在很多瀑布项目上工作，最近又在很多临时项目和敏捷项目上工作，尽管我不能说出它真正取决于什么，但我还是喜欢创建许多设计工件。项目的详细信息(方法/团队结构/时间表/工具等)。 对于基于服务器的通用\\'企业应用程序\\'，我希望最低限度应遵循以下原则：
当我说文档时，以上任何内容都可能分解为多个文档，或者可能存储在Wiki /其他工具上。 关于其有用性，我的理念一直是：开发团队应始终能够将应用程序移交给支持团队，而不必移交他们的电话号码。如果设计工件没有说明应用程序的功能，如何执行以及在何处执行，那么您将知道支持团队将给予应用程序相同的照顾和关注，就像狂犬病一样。 我应该提及的是，我并没有证明一旦完成将软件从开发团队移交给支持团队的做法，这引发了各种有趣的问题，我只是说应该如果需要，可以进行管理。 工作代码...和白板图纸。 ：P 本质上，这不是设计文档，但是我们的单元测试具有双重目的，即"描述"其测试代码应如何工作。这样做的好处是它们永远不会过时，因为必须通过单元测试才能使我们的构建成功。 在我们的模型(非常特定于业务流程应用程序)中，设计伪像包括：
但是这些真的算作设计文物吗？我们的框架是这样的，这些定义用于生成系统的实际代码，因此它们可能超出了设计范围。 但是，它们具有双重职责这一事实之所以强大是因为，按照定义，它们是最新的，并且始终与代码保持同步。 设计在开发过程中发生了很大的变化，此后，一旦代码投入生产，我精心制作的大多数文档就会在源代码管理中流失，几乎成为一种障碍，而不是帮助。我认为设计文档对于进行良好的交流和澄清您在开发某些东西时的想法是必不可少的，但是在此之后，需要花大力气来保持它们的正确维护。 我确实为白板拍照，并将JPEG保存到源代码管理中。这些是我最好的一些设计文档！ 由于以下原因，我认为没有什么可以代替良好的老式设计规范：
我喜欢在设计规范中查看各种信息：
单元测试虽然是应用程序开发中不可思议且至关重要的项目，但并未涵盖所有这些主题。 |
