项目的详细设计文档怎么写( 二 )


设计内容容易过细,但设计阶段是不能考虑特别清楚地,时间也不允许 。
对于这个问题,一个对策是上边所提到的,文档只体现设计上的决策,页面原型所不能反映的信息,详细设计只体现总体设计对模块设计的一些考虑,例如对功能的数据库设计等等,而具体的实现实现,则到代码中再去实现,相关的设计也仅体现在代码中 。
需求、设计需要不断的被更新、构建,则设计文档需要不断的重新调整,文档的维护需要跟上,否则文档和系统的同步就很难得到保障了,且造成多余的工作量 。文档的内容易流于形势,质量糟糕,不能成为开发人员的参考手册,一是要建立起相关制度,如有修改,先改文档,后作开发,从工作流程上切实保障文档与系统的同步,二是要规范文档质量,对文档该写什么,不该写什么,标准是什么,粒度是什么,语法应该如何组织,有明确的标准和考虑,同时,建立审计文档评审、审核制度,充分保障系统的使用 。·
首先是文档的内容,根据项目和团队的不同,详细设计文档的内容也有所不同,一般说来,粒度不宜过细,不能代替开发人员的设计和思考,但要把有关设计的决策考虑进去,包括与其他模块、整体设计的关系、操作的处理流程,对业务规则的设计考虑等,有一个标准为,凡是页面原型、需求规格说明书所不能反映的设计决策,而开发人员又需要了解的,都要写入文档 。
其次是文档所面向的读者,主要为模块开发人员、后期维护人员,模块开发人员通过详细设计文档和页面原型来了解所开发的功能,后期维护人员通过实际系统、模块代码、详细设计文档来了解一个功能 。
再有就是谁来写文档,因为文档主要考虑的是设计上的决策,所以写文档的人应该为负责、参加设计的技术经理、资深程序员,根据团队情况和项目规模、复杂度的不同,也有所不同 。
还需要保证文档的可读性、准确性、一致性,要建立严格的文档模板及标准,保证文档的可读性及准确性,同时建立审核及设计评审制度,来保障设计及文档的质量,另外在工作流程中要强调,要先设计、先写文档,再进行开发 。
3.做软件项目设计文档怎么写啊按照以下格式填就好了,不过是我自己写的,有不好的地方大家互相学习修改一下~
详细设计文档规范
1.0概述
这部分提供对整个设计文档的概述 。描述了所有数据,结构,接口和软件构件级别的设计 。
1.1 目标和对象
描述软件对象的所有目标 。
1.2 陈述范围
软件描述 。主要输入,过程功能,输出的描述,不考虑详细细节 。
1.3 软件内容
软件被置于商业或者产品线中,讨论相关的战略问题 。目的是让读者能够对“宏图”有所了解 。
1.4 主要系统参数
任何商务软件或者产品线都包含软件规定、设计、实现和测试的说明和规范 。
2.0 数据设计
描述所有数据结构包括内部变量,全局变量和临时数据结构 。
2.1 内部软件数据结构
描述软件内部的构件之间的数据传输的结构 。
2.2 全局数据结构
描述主要部分的数据结构 。
2.3 临时数据结构
为临时应用而生成的文件的描述 。
2.4 数据库描述
作为应用程序的一部分,描述数据库结构 。
3.0 结构化和构件级别设计
描述程序结构 。
3.1 程序结构
详细描述应用程序所选定的程序结构 。
3.1.1 结构图
图形化描述结构 。
3.1.2 选择性
讨论其它可供考虑的结构 。选定3.1.1中结构类型的原因 。