在您的软件开发生命周期过程中，您产生了哪些重要的设计工件？是什么让它们对您的实践至关重要？
我目前正在进行的项目已经生产了 8 年以上。在此期间，此 Web 应用程序已得到积极增强和维护。虽然我们已经制定了基于 CMMI 的策略和流程，并且我们的部分实践得到了很好的定义，但设计阶段在很大程度上被忽视了。最佳实践，有人吗？
user290
问问题
10733 次
6 回答
6
工作代码...和白板图纸。
:P
于 2008-09-04T22:41:00.413 回答
6
过去参与过很多瀑布项目，最近也参与过很多临时和敏捷项目，我喜欢创建许多设计工件，尽管我不能说它真的取决于项目的细节（方法/团队结构/时间表/工具等）。
对于一个通用的、基于服务器的“企业应用程序”，我希望最低限度是这样的：
- 详细的功能设计文档（又名规范）。通常类似于 Joel 的WhatsTimeIsIt 示例规范，尽管可能带有一些 UML 用例图。
- 软件技术设计文档。不一定要详细说明 100% 的系统覆盖率，但要详细说明所有关键领域并包含所有设计决策。作为一个有点 UML 的怪胎，很高兴看到很多沿着包图、组件图、关键特性类图的线条的图片，可能还有一些序列图可以很好地衡量。
- 基础设施设计文件。可能使用用于概念设计的 UML 部署图，也可能使用用于更物理的网络图。
当我说文档时，以上任何内容都可能被分解为多个文档，或者可能存储在 wiki/其他工具上。
至于它们的用处，我的理念一直是开发团队应该始终能够将应用程序交给支持团队，而不必交出他们的电话号码。如果设计工件没有清楚地表明应用程序做什么、它是如何做的以及它在哪里做的，那么你知道支持团队会给应用程序提供与疯狗一样的关心和关注。
我应该提一下，我并没有证明一旦完成后将软件从开发团队移交给支持团队的做法是正确的，这会引发各种有趣的问题，我只是说如果管理层愿意的话，这应该是可能的。
于 2008-09-04T23:28:49.020 回答
1
设计在开发过程中和之后发生了很大的变化，以至于我精心制作的大部分文档在源代码管理中都腐烂了，一旦代码投入生产，几乎变成了障碍而不是帮助。我认为设计文档对于良好的沟通和在您开发某些东西时澄清您的想法是必要的，但之后需要付出巨大的努力才能使它们得到妥善维护。
我确实会为白板拍照并将 JPEG 保存到源代码管理中。这些是我最好的设计文档！
于 2008-09-04T23:14:40.240 回答
1
在我们的模型中（相当特定于业务流程应用程序），设计工件包括：
- 域数据模型，对每个实体和属性都有注释
- 一个属性文件，列出每个实体上的所有修改和创建触发器、计算的属性、验证器和其他业务逻辑
- 一组屏幕定义（视图模型）
然而，这些真的算作设计文物吗？我们的框架是这样的，这些定义用于生成系统的实际代码，因此它们可能超出了设计范围。
但是它们具有双重职责这一事实是强大的，因为根据定义，它们是最新的并且始终与代码同步。
于 2008-09-04T23:26:47.810 回答
1
这本身不是一个设计文档，但我们的单元测试服务于“描述”他们测试的代码应该如何运行的双重目的。这样做的好处是它们永远不会过时，因为我们的单元测试必须通过才能使我们的构建成功。
于 2008-09-05T01:54:39.903 回答
0
由于以下原因，我认为没有任何东西可以取代一个好的老式设计规范：
- 它是一种向他人传达您将如何构建应用程序的方式。
- 它可以让您从头脑中获得想法，因此您不必担心同时跟踪一百万件事情。
- 如果您必须暂停一个项目并稍后返回它，您就不会重新开始您的思考过程。
我喜欢在设计规范中看到各种信息：
- 对您应对手头挑战的方法的一般说明
- 您将如何监控您的应用程序？
- 有哪些安全问题以及如何解决？
- 流程图/序列图
- 开放式问题
- 已知限制
单元测试虽然是包含在您的应用程序开发中的一个奇妙且可以说是关键的项目，但并未涵盖所有这些主题。
于 2009-06-26T00:01:02.537 回答