你制作了什么重要的设计文物?

时间:2008-09-04 22:39:53

标签: artifacts

在软件开发生命周期中,您会制作哪些基本设计工件?是什么让它们对你的实践至关重要?

我目前正在进行的项目已经生产了8年多。此Web应用程序在此期间得到了积极的增强和维护。虽然我们已经制定了基于CMMI的政策和流程,但我们的部分实践得到了很好的定义,但设计阶段在很大程度上被忽视了。最好的做法,有人吗?

6 个答案:

答案 0 :(得分:6)

过去曾经参与过很多瀑布项目,而且最近有很多adhoc和敏捷项目,我想创建一些设计工件虽然我不能说明它真的取决于细节项目(方法/团队结构/时间表/工具等)。

对于基于服务器的通用“企业应用程序”,我希望最低限度是这样的:

  • 详细的功能设计文档(又名规范)。通常是Joel s'WhatsTimeIsIt example spec的内容,尽管可能有一些UML用例图。
  • 软件技术设计文档。不一定详细的100%系统覆盖范围,但在所有关键领域详细说明并包含所有设计决策。作为一个UML怪人,很高兴看到很多图片沿着包图,组件图,关键要素类图,以及可能的一些序列图,这些都是很好的衡量标准。
  • 基础设施设计文档。可能是概念设计的UML部署图,也可能是更实际的网络图。

当我说上述任何文件时,可能会将其分解为多个文件,或者可能存储在维基/其他工具上。

至于它们的用处,我的理念始终是开发团队应始终能够将应用程序移交给支持团队,而无需交出他们的电话号码。如果设计工件不清晰表明应用程序的功能,它是如何工作的,以及它在何处执行,那么您就会知道支持团队会给应用程序提供与狂犬病相同的关注和关注。

我应该提一下,一旦完成,我就没有证明将软件从开发团队转移到支持团队的做法,这引发了各种有趣的问题,我只是说它如果管理层愿意,应该是可能的。

答案 1 :(得分:5)

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

:P

答案 2 :(得分:1)

设计在开发过程中发生了很大的变化,之后我的大多数精心设计的文档都在源代码控制中腐烂了,一旦代码投入生产,它就变成了一种障碍,而不是一种帮助。我认为设计文件对于良好的沟通是必要的,并且在你开发某些东西时澄清你的想法,但在那之后需要付出巨大的努力来保持它们得到适当的维护。

我会拍摄白板照片并将JPEG保存到源代码控制中。这些是我最好的设计文档!

答案 3 :(得分:1)

在我们的模型中(对业务流程应用程序非常具体),设计工具包括:

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

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

但是他们提供双重职责的事实是强大的,因为根据定义,它们始终是最新的并且始终与代码同步。

答案 4 :(得分:1)

这本身不是设计文档,但我们的单元测试具有“描述”他们测试的代码应该如何运行的双重目的。关于这一点的好处是它们永远不会过时,因为我们的单元测试必须通过我们的构建才能成功。

答案 5 :(得分:0)

由于以下原因,我认为任何东西都不能代替好的老式设计规范:

  • 它可以作为一种方式来传达如何为他人构建应用程序。
  • 它可以让您从头脑中获取想法,这样您就不必担心同时跟踪一百万件事情。
  • 如果你必须暂停一个项目并稍后再回到它,你就不会重新开始你的思考过程了。

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

  • 您对手头挑战的态度的一般解释
  • 您将如何监控您的申请?
  • 有哪些安全问题以及如何解决?
  • 流程图/序列图
  • 未解决的问题
  • 已知限制

单元测试虽然是应用程序开发中包含的一个非常棒且可以说是关键的项目,但并未涵盖所有这些主题。