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

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

解决方案

回答

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

：P

回答

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

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

回答

在我们的模型(相当特定于业务流程应用程序)中，设计工件包括：

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

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

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

回答

过去曾从事过许多瀑布项目，最近又从事过许多临时项目和敏捷项目，尽管我不能说出它确实取决于项目的细节，但我还是想创建许多设计工件(方法/团队结构/时间表/工具等)。

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

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

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

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

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

回答

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

回答

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

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

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

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

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