在软件开发生命周期中,您会制作哪些基本设计工件?是什么让它们对你的实践至关重要?
我目前正在进行的项目已经生产了8年多。此Web应用程序在此期间得到了积极的增强和维护。虽然我们已经制定了基于CMMI的政策和流程,但我们的部分实践得到了很好的定义,但设计阶段在很大程度上被忽视了。最好的做法,有人吗?
答案 0 :(得分:6)
过去曾经参与过很多瀑布项目,而且最近有很多adhoc和敏捷项目,我想创建一些设计工件虽然我不能说明它真的取决于细节项目(方法/团队结构/时间表/工具等)。
对于基于服务器的通用“企业应用程序”,我希望最低限度是这样的:
当我说上述任何文件时,可能会将其分解为多个文件,或者可能存储在维基/其他工具上。
至于它们的用处,我的理念始终是开发团队应始终能够将应用程序移交给支持团队,而无需交出他们的电话号码。如果设计工件不清晰表明应用程序的功能,它是如何工作的,以及它在何处执行,那么您就会知道支持团队会给应用程序提供与狂犬病相同的关注和关注。
我应该提一下,一旦完成,我就没有证明将软件从开发团队转移到支持团队的做法,这引发了各种有趣的问题,我只是说它如果管理层愿意,应该是可能的。
答案 1 :(得分:5)
工作代码......和白板图纸。
:P
答案 2 :(得分:1)
设计在开发过程中发生了很大的变化,之后我的大多数精心设计的文档都在源代码控制中腐烂了,一旦代码投入生产,它就变成了一种障碍,而不是一种帮助。我认为设计文件对于良好的沟通是必要的,并且在你开发某些东西时澄清你的想法,但在那之后需要付出巨大的努力来保持它们得到适当的维护。
我会拍摄白板照片并将JPEG保存到源代码控制中。这些是我最好的设计文档!
答案 3 :(得分:1)
在我们的模型中(对业务流程应用程序非常具体),设计工具包括:
然而,这些真的算作设计文物吗?我们的框架是这样的,这些定义用于生成系统的实际代码,因此它们可能超出了设计范围。
但是他们提供双重职责的事实是强大的,因为根据定义,它们始终是最新的并且始终与代码同步。
答案 4 :(得分:1)
这本身不是设计文档,但我们的单元测试具有“描述”他们测试的代码应该如何运行的双重目的。关于这一点的好处是它们永远不会过时,因为我们的单元测试必须通过我们的构建才能成功。
答案 5 :(得分:0)
由于以下原因,我认为任何东西都不能代替好的老式设计规范:
我喜欢在设计规范中看到各种信息:
单元测试虽然是应用程序开发中包含的一个非常棒且可以说是关键的项目,但并未涵盖所有这些主题。