怎么写界面软件的详细设计文档
在大多数软件项目中,要末不作详细设计,要么开发完成后再补详细设计文档,质量也不容乐观,文档与系统往往不能同步,使详细设计文档完全流于形式,对工作没有起到实际的帮助。
·
详细设计是相对概要设计而言的,是瀑布开发流程的一个重要环节,在概要设计的高层设计的基础上,从逻辑上实现了每一模块的功能,是编码阶段的主要参考资料,是从高层到低层、逐步精化思想的具体实现。
详细设计文档的内容包括各个模块的算法设计,
接口设计,
数据结构设计,交互设计等。必须写清楚各个模块/接口/公共对象的定义,列明各个模块程序的
各种执行条件与期望的运行效果,还要正确处理各种可能的异常。
·
在开发过程中,由需求及设计不正确、不完整所导致的问题是项目进度拖延、失败的一个主要因素,而软件系统的一个重要特性就是需求和设计的不断构建和改进,在写详细设计文档过程中,
详细设计实际上是对系统的一次逻辑构建,可以有效验证需求的完整性及正确性。
如果不写详细设计文档,一般就从概设直接进入编码阶段,这时开发人员所能参考的资料就是需求规格说明书及页面原型、数据库设计等,不能直接进行开发,需要进行信息的沟通,把页面原型不能体现的设计讲清楚,这样既容易遗忘,也容易发生问题,详细设计文档可以作为需求人员、总体设计人员与开发人员的沟通工具,把静态页面无法体现的设计体现出来,包含整体设计对模块设计的规范,体现对设计上的一些决策,例如选用的算法,对一些关键问题的设计考虑等等,使开发人员能快速进入开发,提高沟通效率,减少沟通问题。
对于系统功能的调整,后期的维护,详设文档提供了模块设计上的考虑、决策,包括模块与整体设计的关系、模块所引用的数据库设计、重要操作的处理流程、重要的业务规则实现设计等等信息,提供了对模块设计的概述性信息,阐明了模块设计上的决策,配合代码注释,可以相对轻松读懂原有设计。
·存在的问题要由专门的人写,是比较麻烦的,也是很需要时间的,会对进度造成压力,也容易形成工作瓶颈,使设计人员负担过重,而开发人员无事可作。对于现在一般的以数据库为中心的管理系统而言,这个工作始终是要作的,区别只不过是不是形成专门文档,形成文档可能会多花一两周时间,但相对于规避的风险和问题来说,也是值得的,另外由于现在高级语言的流行,所以更详细的设计应该直接体现在代码的设计上,而文档则只体现设计上的一些决策,协调整体设计与模块设计的关系,把页面原型所不能体现的设计情况文档化,所以所花费的时间是有限的。
设计内容容易过细,但设计阶段是不能考虑特别清楚地,时间也不允许。
对于这个问题,一个对策是上边所提到的,文档只体现设计上的决策,页面原型所不能反映的信息,详细设计只体现总体设计对模块设计的一些考虑,例如对功能的数据库设计等等,而具体的实现实现,则到代码中再去实现,相关的设计也仅体现在代码中。
需求、设计需要不断的被更新、构建,则设计文档需要不断的重新调整,文档的维护需要跟上,否则文档和系统的同步就很难得到保障了,且造成多余的工作量。文档的内容易流于形势,质量糟糕,不能成为开发人员的参考手册,一是要建立起相关制度,如有修改,先改文档,后作开发,从工作流程上切实保障文档与系统的同步,二是要规范文档质量,对文档该写什么,不该写什么,标准是什么,粒度是什么,语法应该如何组织,有明确的标准和考虑,同时,建立审计文档评审、审核制度,充分保障系统的使用。·
首先是文档的内容,根据项目和团队的不同,详细设计文档的内容也有所不同,一般说来,粒度不宜过细......余下全文>>
软件系统的详细设计文档该怎么写
按照以下格式填就好了,不过是我自己写的,有不好的地方大家互相学习修改一下~
详细设计文档规范
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中结构类型的原因。
3.2 构件描述
详细描述结构中的每个软件构件。
3.2.1 构件过程叙述(PSPEC)
描述构件的过程。
3.2.2 构件接口描述
详细描述构件的输入和输出。
3.2.3 构件执行细节
每个构件的详细演算描述。
3.2.3.1 接口描述
3.2.3.2 演算模型(e.g., PDL)
3.2.3.3 规范/限制
]3.2.3.4 本地数据结构
3.2.3.5 在3.2.3.6设计中包含的执行结果
3.3 软件接口描述
软件对外界的接口描述
3.3.1机器对外接口
与其他机器或者设备的接口描述。
3.3.2系统对外接口
对其它系统、产品和网络的接口描述。
3.3.3与人的接口
概述软件与任何人的界面。
4.0 用户界面设计
描述软件的用户界面设计。
4.1 描述用户界面
详细描述用户界面,包括屏幕显示图标、图片或者类型。
4.1.1 屏幕图片
从用户角度描述界面。
4.1.2 对象和操作
所有屏幕对象和操作的定义。
4.2 界面设计规范
用户界面的设计和实现的规范和标准。
4.3 可见构件
实现的GUI可见构件说明。
4.4 UIDS描述
用户界面开发系统描述。
5.0约束、限制和系统参数
会影响软件的规格说明、设计和实现的特殊事件。
6.0测试标准
测试策略和预备测试用例描述。
6.1 测试的类别
......余下全文>>
软件详细设计说明书
面向对象软件设计说明书模板
1 概述
1.1 系统简述
对系统要完成什么,所面向的用户以及系统运行的环境的简短描述,这部分主要来源于需求说明书的开始部分。
1.2 软件设计目标
这部分论述整个系统的设计目标,明确地说明哪些功能是系统决定实现而哪些时不准备实现的。同时,对于非功能性的需求例如性能、可用性等,亦需提及。需求规格说明书对于这部分的内容来说是很重要的参考,看看其中明确了的功能性以及非功能性的需求。
这部分必须说清楚设计的全貌如何,务必使读者看后知道将实现的系统有什么特点和功能。在随后的文档部分,将解释设计是怎么来实现这些的。
1.3 参考资料
列出本文档中所引用的参考资料。(至少要引用需求规格说明书)
1.4 修订版本记录
列出本文档修改的历史纪录。必须指明修改的内容、日期以及修改人。
2 术语表
对本文档中所使用的各种术语进行说明。如果一些术语在需求规格说明书中已经说明过了,此处不用再重复,可以指引读者参考需求说明。
3 用例
此处要求系统用用例图表述(UML),对每个用例(正常处理的情况)要有中文叙述。
4 设计概述
4.1 简述
这部分要求突出整个设计所采用的方法(是面向对象设计还是结构化设计)、系统的体系结构(例如客户/服务器结构)以及使用到的相应技术和工具(例如OMT、Rose)
4.2 系统结构设计
这部分要求提供高层系统结构的描述,使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离,对前者进行描述珐别忘了说明图中用到的俗语和符号。
4.2.1 顶层系统结构
4.2.2 子系统1结构
4.2.3 子系统2结构
4.3 系统界面
各种提供给用户的界面以及外部系统在此处要予以说明。如果在需求规格说明书中已经对用户界面有了叙述,此处不用再重复,可以指引读者参考需求说明。如果系统提供了对其它系统的接口,比如说从其它软件系统导入/导出数据,必须在此说明。
4.4 约束和假定
描述系统设计中最主要的约束,这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。
另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助,那么系统可能还受到其它的约束。这种情况下,要求清楚地描述与本系统有交互的软件类型(比如某某某数据库软件,某某某EMail软件)以及这样导致的约束(比如只允许纯文本的Email)。
实现的语言和平台也会对系统有约束,同样在此予以说明。
对于因选择具体的设计实现而导致对系统的约束,简要地描述你的想法思路,经过怎么样的权衡,为什么要采取这样的设计等等。
5 对象模型
5.1 系统对象模型
提供整个系统的对象模型,如果模型过大,按照可行的标准把它划分成小块,例如可以把客户端和服务器端的对象模型分开成两个图表述。
对象图应该包含什么呢?
在其中应该包含所有的系统对象。这些对象都是从理解需求后得到的。要明确哪些应该、哪些不应该被放进图中。
所有对象之间的关联必须被确定并且必须指明联系的基数(一对一、一对多还是多对多,0..1,*,1..*)。聚合和继承关系必须清楚地确定下来。每个图必须附有简单的说明。
可能经过多次反复之后才能得到系统的正确的对象模型。
6 对象描述
在这个部分叙述每个对象的细节,它的属性、它的方法。在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好。
为每......余下全文>>
详细设计说明书的使用技巧
对详细设计说明书的内容要求如下:1 引言1.1编写目的1.2背景1.3定义1.4参考资料2 程序系统的组织结构3 程序(标识符)设计说明3.1程序描述3.2功能3.3性能3.4输入项3.5输出项3.6算法3.7流程逻辑3.8接口3.9存储分配3.10注释设计3.11限制条件3.12测试计划.3.13尚未解决的问题4 程序2(标识符)设计说明......
详细设计说明书的程序注释
a. 加在模块首部的注释;b.加在各分枝点处的注释;c. 对各变量的功能、范围、缺省条件等所加的注释;d.对使用的逻辑所加的注释等等。F.3.11限制条件说明本程序运行中所受到的限制条件。F.3.12测试计划说明对本程序进行单体测试的计划,包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。F.3.13尚未解决的问题说明在本程序的设计中尚未解决而设计者认为在软件完成之前应解决的问题。F.4程序2(标识符)设计说明用类似F.3的方式,说明第2个程序乃至第N个程序的设计考虑。......
linux 怎么写软件模块详细设计
概要设计阶段通常得到软件结构图
详细设计阶段常用的描述方式有:流程图、N-S图、PAD图、伪代码等
概要设计和详细设计
在软件设计中,大家经常问到的一个问题是:概要设计应该怎样一个概要法,详细设计应该怎样一个详细法?
这个问题在公司内部经常有人问。现在陈述一下。
我们公司的研发流程是瀑布型的,这个模型中的分析、设计阶段是基于经典的结构化方法。
结构化设计方法的基本思路是:按照问题域,将软件逐级细化,分解为不必再分解的的模块,每个模块完成一定的功能,为一个或多个父模块服务(即接受调用),也接受一个或多个子模块的服务(即调用子模块)。模块的概念,和编程语言中的子程序或函数是对应的。
这样一来,设计可以明显地划分成两个阶段:
概要(结构)设计阶段:把软件按照一定的原则分解为模块层次,赋予每个模块一定的任务,并确定模块间调用关系和接口。
详细设计阶段:依据概要设计阶段的分解,设计每个模块内的算法、流程等。
概要设计阶段:
在这个阶段,设计者会大致考虑并照顾模块的内部实现,但不过多纠缠于此。主要集中于划分模块、分配任务、定义调用关系。模块间的接口与传参在这个阶段要定得十分细致明确,应编写严谨的数据字典,避免后续设计产生不解或误解。概要设计一般不是一次就能做到位,而是反复地进行结构调整。典型的调整是合并功能重复的模块,或者进一步分解出可以复用的模块。在概要设计阶段,应最大限度地提取可以重用的模块,建立合理的结构体系,节省后续环节的工作量。
概要设计文档最重要的部分是分层数据流图、结构图、数据字典以及相应的文字说明等。以概要设计文档为依据,各个模块的详细设计就可以并行展开了。
详细设计阶段:
在这个阶段,各个模块可以分给不同的人去并行设计。在详细设计阶段,设计者的工作对象是一个模块,根据概要设计赋予的局部任务和对外接口,设计并表达出模块的算法、流程、状态转换等内容。这里要注意,如果发现有结构调整(如分解出子模块等)的必要,必须返回到概要设计阶段,将调整反应到概要设计文档中,而不 能就地解决,不打招呼。
详细设计文档最重要的部分是模块的流程图、状态图、局部变量及相应的文字说明等。一个模块一篇详细设计文档。
概要设计文档相当于机械设计中的装配图,而详细设计文档相当于机械设计中的零件图。文档的编排、装订方式也可以参考机械图纸的方法。
我们公司对模块的认识和传统定义有所不同,认为是较大的软件功能单元才可以称作模块。这种认识使大家对概要设计和详细设计的分工产生了混乱的理解,降低了文档的可用性,应该予以纠正。
概要设计中较顶层的部分便是所谓的方案。方案文档的作用是在宏观的角度上保持设计的合理性。
有的项目采用面向对象的分析、设计方法。可能在概要设计、详细设计的分工上疑问更多。其实,面向对象的分析、设计方法并没有强调结构化方法那样的阶段性,因此一般不引入概要、详细设计的概念。如果按照公司的文档体系,非要有这种分工的话,可以将包的划分、类及对象间的关系、类的对外属性、方法及协作设计看做 概要设计;类属性、方法的内部实现看做详细设计。
1.需求分析--产生软件功能规格说明书,需要确定用户对软件的需求,要作到明确、无歧义。不涉及具体实现方法。用户能看得明白,开发人员也可据此进行下面的工作(概要设计)。
2.概要设计--产生软件概要设计说明书,说明系统模块划分、选择的技术路线等,整体说明软件的实现思路。并且需要指出关键技术难点等。
3.详细设计--产生软件详细设计说明书,对概要设计的进一步细化,一般由各部分的担当人员依据概要......余下全文>>
详细设计说明书的说明书
1引言1.1编写目的说明编写这份详细设计说明书的目的,指出预期的读者。1.2背景a.待开发软件系统的名称;b.本项目的任务提出者、开发者、用户和运行该程序系统的计算中心。1.3定义列出本项目中用到专门术语的定义和外文首字母组词的原词组。
android app 详细设计文档怎么写
数字内容的存储,分发和娱乐服务。用户为资源社区的注册用户。
1.1. 编写目的
本文档的目的,旨在规范软件开发,推动项目有序正常的进行,使相关人员遵守统一的规范。节省制作相关文档的时间,降低系统实现的风险,加快项目实施进度,做到系统设计的规范性和全面性,以利于系统的设计、实现、测试、维护和版本升级。
1.2. 项目范围
本文档用于软件设计阶段的概要设计,它的上游(依据的基线)是项目需求分析书,它的下游是项目详细设计说明书,并为详细设计说明书提供测试的依据。
软件概要设计的范围是:客户端软件系统总体结构、外部接口、主要部件功能分配、全局数据结构以及部件之间的接口等方面的内容。
2. 软件概述
2.1. 爱私货概括
本文档用于软件设计阶段的概要设计,它的上游(依据的基线)是项目需求分析书,它的下游是项目详细设计说明书,并为详细设计说明书提供测试的依据。
2.2. APP功能
本文档用于软件设计阶段的概要设计,它的上游(依据的基线)是项目需求分析书,它的下游是项目详细设计说明书,并为详细设计说明书提供测试的依据。
软件建设方案和软件详细设计说明书一样吗?
肯定不一样。建设方案是从宏观上说明客户的问题怎么解决,软件详细设计说明书从微观上说明,包括有那些对饥,对象有那些公有方法等都要说明。