在软件开发生命周期中,您会生成哪些基本的设计工件?是什么让它们对你的实践至关重要?
我目前正在进行的项目已经生产了8年多.此Web应用程序在此期间得到了积极的增强和维护.虽然我们已经制定了基于CMMI的政策和流程,但我们的部分实践得到了很好的定义,但设计阶段在很大程度上被忽视了.最好的做法,有人吗?
过去曾参与过许多瀑布项目以及最近的许多特殊项目和敏捷项目,我想创建一些设计工件虽然我不能说明它真的取决于项目的细节(方法/团队结构/时间表/工具等).
对于基于服务器的通用"企业应用程序",我希望最低限度是这些方面:
详细的功能设计文档(又名规范).通常情况下,Joel的' WhatsTimeIsIt示例规范,尽管可能有一些UML用例图.
软件技术设计文档.不一定详细的100%系统覆盖范围,但在所有关键领域详细说明并包含所有设计决策.作为一个UML怪人,很高兴看到包装图,组件图,关键要素类图以及可能的一些序列图中的大量图片.
基础设施设计文档.可能有概念deisng的UML部署图,也许还有更实际的东西的网络图.
当我说文档中的任何一个可能被分解为多个文档,或者可能存储在wiki /其他工具上时.
至于它们的用处,我的理念始终是开发团队应始终能够将应用程序移交给支持团队,而无需交出他们的电话号码.如果设计工件不清晰表明应用程序的功能,它是如何工作的,以及它在何处执行,那么您就会知道支持团队会给应用程序提供与狂犬病相同的关注和关注.
我应该提一下,我并不能证明软件从开发团队转移到支持团队的做法,一旦它完成,这引发了各种有趣的问题,我只是说如果管理层如此需要它应该是可能的.
工作代码......和白板图纸.
:P