设计文档

在大多数软件项目中,要末不作详细设计,要么开发完成后再补详细设计文档,质量也不容乐观,文档与系统往往不能同步,使详细设计文档完全流于形式,对工作没有起到实际的帮助。

那到底应不应该写详细设计文档呢,怎么使详细设计文档起到他应有的作用呢,下面就让我们来认识一下详细设计及写详细设计文档的好处和问题。

什么是详细设计

详细设计是相对概要设计而言的,是瀑布开发流程的一个重要环节,在概要设计的高层设计的基础上,从逻辑上实现了每一模块的功能,是编码阶段的主要参考资料,是从高层到低层、逐步精化思想的具体实现。

详细设计文档的内容包括各个模块的算法设计, 接口设计, 数据结构设计,交互设计等。必须写清楚各个模块/接口/公共对象的定义,列明各个模块程序的各种执行条件与期望的运行效果,还要正确处理各种可能的异常。

为什么要作详细设计

在开发过程中,由需求及设计不正确、不完整所导致的问题是项目进度拖延、失败的一个主要因素,而软件系统的一个重要特性就是需求和设计的不断构建和改进,在写详细设计文档过程中, 详细设计实际上是对系统的一次逻辑构建,可以有效验证需求的完整性及正确性。

如果不写详细设计文档,一般就从概设直接进入编码阶段,这时开发人员所能参考的资料就是需求规格说明书及页面原型、数据库设计等,不能直接进行开发,需要进行信息的沟通,把页面原型不能体现的设计讲清楚,这样既容易遗忘,也容易发生问题,详细设计文档可以作为需求人员、总体设计人员与开发人员的沟通工具,把静态页面无法体现的设计体现出来,包含整体设计对模块设计的规范,体现对设计上的一些决策,例如选用的算法,对一些关键问题的设计考虑等等,使开发人员能快速进入开发,提高沟通效率,减少沟通问题。

对于系统功能的调整,后期的维护,详设文档提供了模块设计上的考虑、决策,包括模块与整体设计的关系、模块所引用的数据库设计、重要操作的处理流程、重要的业务规则实现设计等等信息,提供了对模块设计的概述性信息,阐明了模块设计上的决策,配合代码注释,可以相对轻松读懂原有设计。

存在的问题

要由专门的人写,是比较麻烦的,也是很需要时间的,会对进度造成压力,也容易形成工作瓶颈,使设计人员负担过重,而开发人员无事可作。对于现在一般的以数据库为中心的管理系统而言,这个工作始终是要作的,区别只不过是不是形成专门文档,形成文档可能会多花一两周时间,但相对于规避的风险和问题来说,也是值得的,另外由于现在高级语言的流行,所以更详细的设计应该直接体现在代码的设计上,而文档则只体现设计上的一些决策,协调整体设计与模块设计的关系,把页面原型所不能体现的设计情况文档化,所以所花费的时间是有限的。

设计内容容易过细,但设计阶段是不能考虑特别清楚地,时间也不允许。 
 对于这个问题,一个对策是上边所提到的,文档只体现设计上的决策,页面原型所不能反映的信息,详细设计只体现总体设计对模块设计的一些考虑,例如对功能的数据库设计等等,而具体的实现实现,则到代码中再去实现,相关的设计也仅体现在代码中。 
     需求、设计需要不断的被更新、构建,则设计文档需要不断的重新调整,文档的维护需要跟上,否则文档和系统的同步就很难得到保障了,且造成多余的工作量。文档的内容易流于形势,质量糟糕,不能成为开发人员的参考手册,一是要建立起相关制度,如有修改,先改文档,后作开发,从工作流程上切实保障文档与系统的同步,二是要规范文档质量,对文档该写什么,不该写什么,标准是什么,粒度是什么,语法应该如何组织,有明确的标准和考虑,同时,建立审计文档评审、审核制度,充分保障系统的使用。

应该如何写详细设计文档

下面讨论如何写出一个符合要求、实用的详细设计文档。

首先是文档的内容,根据项目和团队的不同,详细设计文档的内容也有所不同,一般说来,粒度不宜过细,不能代替开发人员的设计和思考,但要把有关设计的决策考虑进去,包括与其他模块、整体设计的关系、操作的处理流程,对业务规则的设计考虑等,有一个标准为,凡是页面原型、需求规格说明书所不能反映的设计决策,而开发人员又需要了解的,都要写入文档。

其次是文档所面向的读者,主要为模块开发人员、后期维护人员,模块开发人员通过详细设计文档和页面原型来了解所开发的功能,后期维护人员通过实际系统、模块代码、详细设计文档来了解一个功能。

再有就是谁来写文档,因为文档主要考虑的是设计上的决策,所以写文档的人应该为负责、参加设计的技术经理、资深程序员,根据团队情况和项目规模、复杂度的不同,也有所不同。

还需要保证文档的可读性、准确性、一致性,要建立严格的文档模板及标准,保证文档的可读性及准确性,同时建立审核及设计评审制度,来保障设计及文档的质量,另外在工作流程中要强调,要先设计、先写文档,再进行开发。

时间: 2024-10-05 23:58:14

设计文档的相关文章

《团队-科学计算器-设计文档》

设计文档: 项目:科学计算器 编辑器:python 所运用知识: 1.字符串的处理 2.正则表达式的运用 3.函数递归 基本思路: 需要优先处理内层括号运算--外层括号运算--先乘除后加减的原则: 1.正则处理用户输入的字符串,然后对其进行判断,判断计算公式是否有括号,有就先将计算公式进行正则处理,先获取最里层的每一个数据,然后一一计算 2.把有括号的计算公式计算出来的结果替换原来初始公式的位置,计算之前分别对重复运算符进行处理需要处理的重复运算 3.然后依次从里到外去除括号并进行计算,和位置替

《结对编项目作业名称-设计文档》

项目:关灯游戏,所用软件,pygame 成员:祁昊,刘孝东 关灯游戏设计文档: pygame作为一种游戏编程语言,以其简单性.可移植性等优点,得到了广泛地应用,特别是py使用比c,c++等语言简便,使其成为网络编程首选编程语言.,Pygame是跨平台Python模块,专为电子游戏设计.基于这样一个设想,所有需要的游戏功能和理念都(主要是图像方面)都完全简化为游戏逻辑本身,所有的资源结构都可以由高级语言提供,如Python.工具tile编辑器和一个关卡编辑器.得到广大程序员的接受和认可. "关灯游

Storm项目:流数据监控1《设计文档…

该文档为实实在在的原创文档,转载请注明作者及出处. 类型 详细 备注 2 该文档为原创模拟项目:流数据监控<1>文档<流数据监控设计文档>,相继会给出流数据监控<2>文档<流数据监控代码解析>及其他文档 2  该部分有源码(熬夜写出来的哦) CSDN中相应项目CODE链接:戳这里     相关描述 2  有任何其他想法,可以邮件[email protected] 2 文档及相关资料下载请到个人360云盘http://yunpan.cn/QGf2GDaRFpc

Atitit.atiagent &#160;agent分销系统 代理系统 设计文档

Atitit.atiagent  agent分销系统 代理系统 设计文档 1. 启动项目1 2. 首也2 3. 登录功能2 4. 用户中心2 5. 充值查询3 6. 授权下级代理4 7. 我的提成5 8. 查看下级玩家6 9. 查看下级代理7 10. 数据库文档 agent7 10.1. Acc 用户帐号以及上级代理id关联字段7 10.2. 充值记录表8 1. 启动项目 C:\0workspace\AtiPlatf_cms\resin run q2b_game.bat Prj::cms 数据库

《结对-自然语言进行数据库查询系统-设计文档》

二〇一七年九月十四日十点一刻少两分钟 关于结对编程的设计文档: 题目:自然语言进行数据库查询系统 编程语言:C# 数据库:MySql ,其他逐渐扩展 软件所要实现的功能: 用户打开软件之后可以连接到数据库,并且通过自然语言进行数据库的查询,例如我想知道小明的学号,如果在数据库中查询需要输入 select ID from 学生表 where name = "小明"才能实现,我们要做的是,输入查询小明的学号,软件就可以将自然语言转换成sql语句进行数据库的查询. 所要实现的功能: 1.进行

为什么要写设计文档

日趋一日,程序员能够在更少的时间内完成更多的事情.使用今日的高级编程语言,开发环境,工具和“快速应用开发”思想,程序员和经理都已经习惯于急速的开发周期.今日的程序员更倾向于直接跳入到编码之中,害怕花费在非编码工作中的每一小时,都会导致项目截止日期前的周末多加一个小时班. 编码之前做设计这一过程已经变得过时了,将设计文档化就更罕见了.很多程序员从来没有写过设计文档,面对要写设计文档这一想法都畏缩不前.即使被要求写,通常来说也只是产出了一大堆的交互图和类图,这些图表大多没有表达程序员在设计阶段的思考

Chrome设计文档-多进程资源加载

原文:Multi-process Resource Loading 背景 浏览器主进程及browser process处理所有的网络通信.原因有三点: Browser process可以控制每一个renderer进程的网络访问 Browser process可以在进程间管理session状态,保持其一致性 Browser process可以针对每个host管理最大链接数 概述 作为一个多进程应用,Chrome分为三层.最底层的是webkit库,它主要负责页面渲染工作.之上是渲染进程Rendere

??怎样写具体设计文档

怎样写具体设计文档是一个非常头疼的话题,简单的说是需求文档的升华,也能够说是开发者开发程序的根据,当然根据具体设计文档的粒度进行.好的具体设计文档是需求人员和开发者之间的桥梁,只是眼下好多程序开发都是先开发后,然后为了应付审核,公司制度,文档规范,开发完毕后兴许补上该文档.假设这种方式,具体设计文档的的作用就忽略了. 在大多数软件项目中,要末不作具体设计,要么开发完毕后再补具体设计文档,质量也不容乐观,文档与系统往往不能同步,使具体设计文档全然流于形式,对工作没有起到实际的帮助. 那究竟应不应该

DDD领域驱动设计 - 设计文档模板

设计文档模板: 系统背景和定位 需求描述 系统用例图 关键业务流程图 领域语言整理,主要是整理领域中的各种术语的定义,名词解释 领域划分(分析出子域.核心域.支撑域) 每个子域的领域模型设计(实体.值对象.聚合.领域事件,需要注意的是:领域模型是需要抽象的,要分析业务本质,而不是简单的直接对需求进行建模) 领域模型详细说明(如为什么这样设计的原因.模型内对象的关系.各种业务规则.数据一致性规则等) 领域服务.仓储.工厂设计 Saga流程设计 场景走查(讲述如何通过领域模型.领域服务.仓储.Sag