??xml version="1.0" encoding="utf-8" standalone="yes"?> l承 指的是一个类Q称为子cR子接口Q承另外的一个类Q称为父cR父接口Q的功能Qƈ可以增加它自q新功能的能力Q承是cMcL者接口与接口之间最常见的关p;在Java中此cdp通过关键字extends明确标识Q在设计时一般没有争议性; 实现 指的是一个classcd现interface接口Q可以是多个Q的功能Q实现是cM接口之间最常见的关p;在Java中此cdp通过关键字implements明确标识Q在设计时一般没有争议性; 依赖 可以单的理解Q就是一个类A使用C另一个类BQ而这U用关pLh偶然性的、、时性的、非常弱的,但是Bcȝ变化会媄响到AQ比如某q河Q需要借用一条船Q此时h与船之间的关pd是依赖;表现在代码层面,为类B作ؓ参数被类A在某个methodҎ中用; 兌 他体现的是两个类、或者类与接口之间语义别的一U强依赖关系Q比如我和我的朋友;q种关系比依赖更强、不存在依赖关系的偶然性、关pM不是临时性的Q一般是长期性的Q而且双方的关pM般是q等的、关联可以是单向、双向的Q表现在代码层面Qؓ被关联类B以类属性的形式出现在关联类A中,也可能是兌cA引用了一个类型ؓ被关联类B的全局变量Q?/p>
聚合 聚合是关联关pȝ一U特例,他体现的是整体与部分、拥有的关系Q即has-a的关p,此时整体与部分之间是可分ȝQ他们可以具有各自的生命周期Q部分可以属于多个整体对象,也可以ؓ多个整体对象׃nQ比如计机与CPU、公怸员工的关pȝQ表现在代码层面Q和兌关系是一致的Q只能从语义U别来区分; l合 l合也是兌关系的一U特例,他体现的是一Ucontains-a的关p,q种关系比聚合更强,也称为强聚合Q他同样体现整体与部分间的关p,但此时整体与部分是不可分的,整体的生命周期结束也意味着部分的生命周期结束;比如你和你的大脑Q表现在代码层面Q和兌关系是一致的Q只能从语义U别来区分; 对于l承、实现这两种关系没多疑问,他们体现的是一U类与类、或者类与接口间的纵向关p;其他的四者关pd体现的是cMcR或者类与接口间的引用、横向关p,是比较难区分的,有很多事物间的关p要惛_备定位是很难的,前面也提刎ͼq几U关p都是语义别的Q所以从代码层面q不能完全区分各U关p;但ȝ来说Q后几种关系所表现的强q度依ơؓQ组?gt;聚合>兌>依赖
需求说明书Q是Ҏ与现场实际客戯行沟通,把客L需求进行整理,CMMI中有标准的模板,我就不细说了Q重Ҏ站在客户的角度讲产品功能?
需求规D明书Q是从业务规则讲LQ细一点偏向于软g的概要设计。是从开发、测试的角度去讲产品功能Q里面要包含原型界面、业务接口、活动图{?
]]>
]]>
]]>
CRPQCapacity Requirment Planning 能力需求计?/p>
MRPQMaterials Requirement Planning 物料需求计?/p>
CRMQCustomer Relationship Management 客户关系理
ERMQEnterprise Relationship Management 企业关系理
SCMQSupply Chain Management 供应铄?/p>
ESBQEnterprise Services Bus 企业服务ȝ
开发文档包括:《功能要求》、《投标方案》、《需求分析》、《技术分析》、《系l分析》、《数据库文档》、《功能函数文档》、《界面文档》、《编译手册》、?QA 文档》、《项目ȝ》等?
产品文档包括Q《品简介》、《品演C》、《疑问解{》、《功能介l》?《技术白皮书》、《评报告》、《安装手册》、《用手册》、《维护手册》?《用h告》、《销售培训》等?
一、开发文?
1. 《功能要求?-- 来源于客戯求和市场调查Q是软g开发中最早期的一个环节。客hZ个模p的功能概念Q或者要求解决一个实际问题,或者参照同cY件的一个功能。有软gl验的客戯会提供比较详l的技术规范书Q把他们的要求全部列表书写在文档中,必要时加以图表解说。这份文档是需求分析的基础?
2. 《投标方案?-- Ҏ用户的功能要求,l过与招标方沟通和认Q技术h员开始书写《投标方案》,Ҏ书一般包括以下几个重要的章节Q?
前言 -- 目背景、公司背景和业务、技术h员结构、公司的成功案例介绍{?
需求分?-- 目要求、Y件结构、功能列表、功能描q、注意事等?
技术方?-- M要求和指导思想、技术解x案、Y件开发^台、网l结构体pȝ?
目理 -- 描述公司的Y件开发流E、工E实施服务、组l和人员分工、开发进度控制、Y件质量保证、项目验收和人员培训、Y件资料文档等?
技术支?-- 公司的技术支持和服务介绍、服务宗旨和目标、服务别和响应旉、技术服务区域、技术服务期限、授权用戯pMh{?
pȝ报h -- 软、硬件^台报价列表、Y件开发费用、系l维护费用等?
目q度 -- 整个目的进度计划,包括{v合同、项目启动、需求分析、系l分析、程序开发、测试维护、系l集成、用户验收、用户培训等步骤的时间规划?
3. 《需求分析?-- 包括产品概述、主要概c操作流E、功能列表和解说、注意事V系l环境等。以《功能要求》ؓ基础Q进行详l的功能分析 ( 包括客户提出的要求和Ҏ开发经验徏议的功能 ) Q列出本产品是什么,有什么特D的概念Q包括那些功能分c,需要具备什么功能,该功能的操作如何Q实现的时候该注意什么细节,客户有什么要求,pȝq行环境的要求等。这里的功能描述跟以后的使用手册是一致的?/p>
4. 《技术分析?-- 包括技术选型、技术比较、开发h员、关键技术问题的解决、技术风险、技术升U方向、技术方案评P竞争Ҏ技术分析等。以《需求分析》ؓ基础Q进行详l的技术分?( 产品的性能和实现方?) Q列出本目需要用什么技术方案,Z么,有哪些技术问题要解决 Q估计开发期间会到什么困难,技术方案以后如何升U,Ҏ目的技术有什么评L?/p>
5. 《系l分析?-- 包括功能实现、模块组成、功能流E图、函数接口、数据字典、Y件开发需要考虑的各U问题等。以《需求分析》ؓ基础Q进行详l的pȝ分析 ( 产品的开发和实现Ҏ ) Q估计开发期间需要把什么问题说明白Q程序员Ҏ《系l分析》,开始在目ȝ的带领下q行~码?/p>
6. 《数据库文档?-- 包括数据库名U、表名、字D名、字D늱型、字D说明、备注、字D|D公式等。以《系l分析》ؓ基础Q进行详l的数据库设计。必要时可以用图表解_特别是关pL据库?/p>
7. 《功能函数文档?-- 包括变量名、变量初植、功能,函数名,参数Q如何调用、备注、注意事等。以《系l分析》ؓ基础Q进行详l的说明Q列出哪个功能涉及多个函数Q以便以后程序员修改、接手和扩展?
8. 《界面文档?-- 包括软g外观、界面素材、编辑工兗文件名、菜单、按钮和其它界面部g的要求,q里与Y件完成后的运行界面是一致的?
9. 《编译手册?-- 包括服务器编译环境、操作系l、编译工兗?GNU ?C++ ~译器版本信息、目录说明、程序生成、源E序文g列表?Makefile 配置及其相关E序的对应关pd表。客L的编译过E、编译结果、编译示例、编译环境、操作系l、编译工兗源文g列表和制作安装程序的q程?
10. ?QA 文档?-- 包括产品介、品原理、品功能列表、功能描q、功能流E、执行结果、数据库l构、测试要求等Q提供给软g试人员使用?
11. 《项目ȝ?-- 包括目介、项目参与h员和开发时间、项目风险管理过E、项目功能列表、项目结构特炏V技术特炏V对目的升U徏议、对以后的项目的、h员素质情늭?
二、品文?
1. 《品简介?-- 包括公司背景、品概c适用范围、品功能、功能特炏V运行要求和公司联系地址?
2. 《品演C?-- 包括公司介、品背景、品描q、品特炏V品作用、适用范围、用分析、功能模块、解决问题、合作伙伴、成功案例等。一般用 Power
point 或?VCD 录制软g实现?
3. 《疑问解{?-- 列出用户兛_的问题和处理Ҏ。用于解{Y件的操作功能和解决用L疑难问题?
4. 《功能介l?-- 以《需求分析》ؓ书写基础Q包括Y件介l、Y件结构、功能列表、功能描q和公司联系地址?
5. 《技术白皮书?-- 以《技术分析》ؓ书写基础Q包括功能实现、技术选型、关键技术问题的解决、技术方案特炏V技术升U方向等?
6. 《评报告?-- W三Ҏ威评报告。包括评目的、评范围、评环境、评内宏V实数据、性能表现、结果分析和评测ȝ{?
7. 《安装手册?-- 包括pȝ环境、运行^台、品安装过E、初始环境设|、安装记录等?
8. 《用手册?-- 包括产品介、功能列表、功能描q和解释、功能操作、客h务和联系方式{?
9. 《维护手册?-- 包括产品介、系l须知、初始环境设|、系l配|、数据管理和备䆾、技术问题解{和联系方式{?
10. 《用h告?-- 包括产品介、购买时间、用目的、用时间、用地炏V实施过E、出现问题和解决、品ȝ和徏议等?
11. 《销售培训?-- 包括目介、品功能、品特炏V商业优ѝ系l运行环境、适用范围、目标客L?/p>
1Q引a
1.1~写目的
【阐明编写详l设计说明书的目的,指明读者对象。?
1.2目背景
【应包括目的来源和ȝ部门{。?
1.3定义
【列出文档中所用到的专门术语的定义和羃写词的原文。?
1.4参考资?
【列出有兌料的作者、标题、编受发表日期、出版单位或资料来源Q可包括Q?
a. 目的计划Q务书、合同或ҎQ?
b. 目开发计划;
c. 需求规D明书Q?
d. 概要设计说明书;
e. 试计划Q初E)Q?
f. 用户操作手册Q初E)Q?
g. 文档中所引用的其他资料、Y件开发标准或规范。?
2QM设计
2.1需求概q?
2.2软gl构
【如l出软gpȝ的结构图。?
3Q程序描q?
【逐个模块l出以下的说明:?
3.1功能
3.2性能
3.3输入目
3.4输出目
3.5法
【模块所选用的算法。?
3.6E序逻辑
【详l描q模块实现的法Q可采用Q?
a. 标准程图;
b. PDL语言Q?
c. NQS图;
d. PADQ?
e. 判定表等描述法的图表。?
3.7接口
3.8存储分配
3.9限制条g
3.10试要点
Ҏ工作性质和内容的不同QY件设计分为概要设计和详细设计。概要设计实现Y件的M设计、模块划分、用L面设计、数据库设计{等Q详l设计则Ҏ概要设计所做的模块划分Q实现各模块的算法设计,实现用户界面设计、数据结构设计的l化Q等{?/p>
概要设计是详l设计的基础Q必d详细设计之前完成Q概要设计经复查认后才可以开始详l设计。概要设计,必须完成概要设计文档Q包括系l的M设计文档、以及各个模块的概要设计文档。每个模块的设计文档都应该独立成册?/p>
详细设计必须遵@概要设计来进行。详l设计方案的更改Q不得媄响到概要设计ҎQ如果需要更Ҏ要设计,必须l过目l理的同意。详l设计,应该完成详细设计文档Q主要是模块的详l设计方案说明。和概要设计一P每个模块的详l设计文档都应该独立成册?/p>
概要设计里面的数据库设计应该重点在描q数据关pMQ说明数据的来龙去脉Q在q里应该l合我们的一下结果数据,说明q些l果数据的源点,我们q样设计的目的和原因。详l设计里的数据库设计应该是一份完善的数据l构文档Q就是一个包括类型、命名、精度、字D说明、表说明{内容的数据字典?/p>
概要设计里的功能应该是重点在功能描述Q对需求的解释和整合,整体划分功能模块Qƈ对各功能模块q行详细的图文描qͼ应该让读者大致了解系l作完后大体的结构和操作模式。详l设计则是重点在描述pȝ的实现方式,各模块详l说明实现功能所需的类及具体的Ҏ函数Q包括涉及到的sql语句{?/p>
http://blog.csdn.net/skyly84/archive/2009/06/02/4236569.aspx
概要设计与详l设计的区别
概要设计是设计软g的结构,包括l成模块Q模块的层次l构Q模块的调用关系Q每个模块的功能{等。同Ӟq要设计该项目的应用pȝ的M数据l构和数据库l构Q即应用pȝ要存储什么数据,q些数据是什么样的结构,它们之间有什么关pR?
详细设计阶段是为每个模块完成的功能q行具体的描qͼ要把功能描述转变为精的、结构化的过E描q?/p>
概要设计阶段通常得到软gl构?/font>
详细设计阶段常用的描q方式有Q流E图、N-S图、PAD图、伪代码{?/p>
概要设计和详l设?/p>
在Y件设计中Q大家经帔R到的一个问题是Q概要设计应该怎样一个概要法Q详l设计应该怎样一个详l法Q?
q个问题在公司内部经常有人问。现在陈qC下?
我们公司的研发流E是瀑布型的Q这个模型中的分析、设计阶D|Zl典的结构化Ҏ?
l构化设计方法的基本思\是:按照问题域,Y仉l化Q分解ؓ不必再分解的的模块,每个模块完成一定的功能Qؓ一个或多个父模块服务(x受调用)Q也接受一个或多个子模块的服务Q即调用子模块)。模块的概念Q和~程语言中的子程序或函数是对应的?/font>
q样一来,设计可以明显地划分成两个阶段Q?
概要Q结构)设计阶段Q把软g按照一定的原则分解为模块层ơ,赋予每个模块一定的dQƈ定模块间调用关pd接口?/font>
详细设计阶段Q依据概要设计阶D늚分解Q设计每个模块内的算法、流E等?/p>
概要设计阶段Q?/p>
在这个阶D,设计者会大致考虑q照模块的内部实现Q但不过多纠~于此?font color="#0000ff">主要集中于划分模块、分配Q务、定义调用关pR模块间的接口与传参在这个阶D要定得 十分l致明确Q应~写严}的数据字典,避免后箋设计产生不解或误解?/font>概要设计一般不是一ơ就能做CQ而是反复地进行结构调整?/font>典型的调整是合ƈ功能重复的模块,或者进一步分解出可以复用的模块。在概要设计阶段Q应最大限度地提取可以重用的模块,建立合理的结构体p,节省后箋环节的工作量?
概要设计文档最重要的部分是分层数据图、结构图、数据字总及相应的文字说明{?/font>以概要设计文档ؓ依据Q各个模块的详细设计可以ƈ行展开了?/p>
详细设计阶段: 在这个阶D,各个模块可以分给不同的hdƈ行设计。在详细设计阶段Q设计者的工作对象是一个模块,Ҏ概要设计赋予的局部Q务和对外接口Q设计ƈ表达出模块的法、流E、状态{换等内容。这里要注意Q如果发现有l构调整Q如分解出子模块{)的必要,必须q回到概要设计阶D,调整反应到概要设计文档中,而不 能就地解冻I不打招呼。详l设计文档最重要的部分是模块的流E图、状态图、局部变量及相应的文字说明等。一个模块一详l设计文档?/p>
概要设计文档相当于机械设计中的装配图Q而详l设计文档相当于机械设计中的零g图。文档的~排、装订方式也可以参考机械图U的Ҏ? 我们公司Ҏ块的认识和传l定义有所不同Q认为是较大的Y件功能单元才可以UC模块。这U认识大家Ҏ要设计和详细设计的分工生了混ؕ的理解,降低了文档的可用性,应该予以U正? 概要设计中较层的部分便是所谓的Ҏ。方案文档的作用是在宏观的角度上保持设计的合理性?/font> 有的目采用面向对象的分析、设计方法。可能在概要设计、详l设计的分工上疑问更多。其实,面向对象的分析、设计方法ƈ没有l构化方法那L阶段性,因此一般不引入概要、详l设计的概念。如果按照公司的文档体系Q非要有q种分工的话Q?font color="#0000ff">可以包的划分、类及对象间的关pR类的对外属性、方法及协作设计看做 概要设计Q类属性、方法的内部实现看做详细设计?/font> 1.需求分?-产生软g功能规格说明?需要确定用户对软g的需?要作到明、无歧义。不涉及具体实现Ҏ。用戯看得明白Q开发h员也可据此进行下面的工作Q概要设计)? 2.概要设计--产生软g概要设计说明书,说明pȝ模块划分、选择的技术\U等Q整体说明Y件的实现思\。ƈ且需要指出关键技术难点等?nbsp; 3.详细设计--产生软g详细设计说明书,Ҏ要设计的q一步细化,一般由各部分的担当人员依据概要设计分别完成Q然后在集成Q是具体的实现细节。理Z要求可以照此~码?/p>
概要设计和详l设计的区别与联p?/p>
软g设计采用自顶向下、逐次功能展开的设计方法,首先完成M设计Q然后完成各有机l成部分的设计?/p>
Ҏ工作性质和内容的不同QY件设计分为概要设计和详细设计。概要设计实现Y件的M设计、模块划分、用L面设计、数据库设计{等Q详l设计则Ҏ概要设计所做的模块划分Q实现各模块的算法设计,实现用户界面设计、数据结构设计的l化Q等{?/p>
概要设计是详l设计的基础Q必d详细设计之前完成Q概要设计经复查认后才可以开始详l设计。概要设计,必须完成概要设计文档Q包括系l的M设计文档、以及各个模块的概要设计文档。每个模块的设计文档都应该独立成册?/p>
详细设计必须遵@概要设计来进行。详l设计方案的更改Q不得媄响到概要设计ҎQ如果需要更Ҏ要设计,必须l过目l理的同意。详l设计,应该完成详细设计文档Q主要是模块的详l设计方案说明。和概要设计一P每个模块的详l设计文档都应该独立成册?/p>
概要设计里面的数据库设计应该重点在描q数据关pMQ说明数据的来龙去脉Q在q里应该l合我们的一下结果数据,说明q些l果数据的源点,我们q样设计的目的和原因。详l设计里的数据库设计应该是一份完善的数据l构文档Q就是一个包括类型、命名、精度、字D说明、表说明{内容的数据字典?/p>
概要设计里的功能应该是重点在功能描述Q对需求的解释和整合,整体划分功能模块Qƈ对各功能模块q行详细的图文描qͼ应该让读者大致了解系l作完后大体的结构和操作模式。详l设计则是重点在描述pȝ的实现方式,各模块详l说明实现功能所需的类及具体的Ҏ函数Q包括涉及到的sql语句{?/p>
概要设计Q详l设计之间的关系是什么? Q: 我的看法Q?/p>
概要设计只说明系l有多少个模块,各模块之间的接口和个模块本n的功?/font> 详细设计说明某个具体模块如何实现Q粒度应该比E序略高一?/p>
但是问题来了Q各个模块之间是有层ơ关pȝQ也有先后逻辑关系。这p明,在概要设计中Q还必须考虑模块的实现细节,否则Q你怎么知道q个模块下面要划分子模块Q你怎么知道各子模块的调用顺序? q就说明Q概要设计和详细设计是重叠进行的Q而Y件工E书上说的确是顺序进行的Q不知道是不是我的理解有问题?/p>
举个例子Q例如排序程序,如果设计2个模块: 一个主模块用于排序子模块用于交?个变量,L块调用子模块Q但是子模块是怎么设计出来的呢Q肯定是你先惛_了用冒{排序方式的时候需要交换数据,q已l考虑了主模块_多的l节Q似乎属?详细设计"了,但是目前q行的是概要设计Q这׃生了我所说的重叠的情c?/p>
A: 看看上面的帖子,有意思的居多?/p>
上面也有朋友说到用徏{的例子来比喅R?/p>
软g的概要设计,主要是徏立Y件系l的整体架构Q?/font>也就是我们在盖房子时候,需要先房子的整个架子构徏h?/p>
软g的详l设计,主要是将软gpȝ的各个部分的具体设计Ҏ、逻辑、功能采用文字方式进行表q。这样在实现q程中,Coding人员原则上严格按此进行代码实现即可?/p>
q样的一个最为简单的例证Q我们可以将代码交付W三Ҏ做。验证与跟踪采取设计来?/p>
我看上面q有一个朋友说Q快速做代码。这个本w没有值得批评之处。但只要想一下,你写的代码没有Q何设计思想、文档留下的情况Q一旦你dQ如何维护?重新设计吗?q是p几倍h力去研究你写的几?万,甚至几十万行代码Q如果是q样的,你没错,关键是你们老板太对了,q什么?/p>
另外的一个问题是Q中国h如此聪明Q但中国Z么没有出现巨型Y件品呢Q个雄主义依然很严重Q老板的短视利益行为大行其道?/p>
说明~写q䆾详细设计说明书的目的Q指出预期的读者?/span>
说明Q?/span>
aQ?span style="font: 7pt Times New Roman"> 待开发Y件系l的名称Q?/span>
bQ?span style="font: 7pt Times New Roman"> 本项目的d提出者、开发者、用户和q行该程序系l的计算中心?/span>
列出本文件中用到专门术语的定义和外文首字母组词的原词l?/span>
列出有关的参考资料,如:
aQ?span style="font: 7pt Times New Roman"> 本项目的l核准的计划d书或合同、上U机关的ҎQ?/span>
bQ?span style="font: 7pt Times New Roman"> 属于本项目的其他已发表的文gQ?/span>
cQ?span style="font: 7pt Times New Roman"> 本文件中各处引用到的文g资料Q包括所要用到的软g开发标准。列些文件的标题、文件编受发表日期和出版单位Q说明能够取得这些文件的来源?/span>
用一pd图表列出本程序系l内的每个程序(包括每个模块和子E序Q的名称、标识符和它们之?/span> 的层ơ结构关pR?/span>
从本章开始,逐个地给出各个层ơ中的每个程序的设计考虑。以下给出的提纲是针对一般情늚。对于一个具体的模块Q尤其是层次比较低的模块或子E序Q其很多条目的内容往往与它所隶属的上一?/span> 模块的对应条目的内容相同Q在q种情况下,只要单地说明q一点即可?/span>
l出对该E序的简要描qͼ主要说明安排设计本程序的目的意义Qƈ且,q要说明本程序的特点Q如 是常d存还是非帔RQ是否子E序Q是可重人的q是不可重h的?有无覆盖要求Q是序处理q是q发处理{)?/span>
说明该程序应h的功能,可采?/span>IPO图(卌入一处理一输出图)的Ş式?/span>
说明对该E序的全部性能要求Q包括对_ֺ、灵zL和旉Ҏ的要求?/span>
l出Ҏ一个输入项的特性,包括名称、标识、数据的cd和格式、数据值的有效范围、输入的方式。数量和频度、输入媒体、输入数据的来源和安全保密条件等{?/span>
l出Ҏ一个输出项的特性,包括名称、标识、数据的cd和格式,数据值的有效范围Q输出的形式、数量和频度Q输出媒体、对输出囑Ş及符L说明、安全保密条件等{?/span>
详细说明本程序所选用的算法,具体的计公式和计算步骤?/span>
用图表(例如程图、判定表{)辅以必要的说明来表示本程序的逻辑程?/span>
用图的Ş式说明本E序所隶属的上一层模块及隶属于本E序的下一层模块、子E序Q说明参数赋值和调用方式Q说明与本程序相直接兌的数据结构(数据库、数据文P?/span>
Ҏ需要,说明本程序的存储分配?/span>
说明准备在本E序中安排的注释Q如Q?/span>
aQ?span style="font: 7pt Times New Roman"> 加在模块首部的注释;
bQ?span style="font: 7pt Times New Roman"> 加在各分枝点处的注释Q?/span>
cQ?span style="font: 7pt Times New Roman"> 对各变量的功能、范围、缺省条件等所加的注释Q?/span>
dQ?span style="font: 7pt Times New Roman"> 对用的逻辑所加的注释{等?/span>
说明本程序运行中所受到的限制条件?/span>
说明ҎE序q行单体试的计划,包括Ҏ试的技术要求、输入数据、预期结果、进度安排、h员职责、设备条仉动程序及桩模块等的规定?/span>
说明在本E序的设计中未解决而设计者认为在软g完成之前应解决的问题?/span>
用类?/span>FQ?/span>3的方式,说明W?/span>2个程序乃至第N个程序的设计考虑?/span>
[目名称]
详细设计说明?/font>
版本P[版本号]
受控~号Q[受控~号]
~写部门Q[~写部门]
~写人:[~写人]
审核人:[审核人]
审核日期Q?005q??0?/font>
批准人:[批准人]
日期Q?005q??0?/font>
??br />1Q引a……………………………………………………………………….. 1
~写目的
背景
定义
参考资?br />2Q程序系l结?#8230;………………………………………………………….. 1
3Q元素烦引表……………………………………………………………….. 1
4Q程序设?#8230;……………………………………………………………….. 1
元素?br />元素?br />==================请用本模板者自p充此目录==================
1Q引a
1.1) ~写目的
[在此说明~写q䆾概要设计说明书的目的Q指出预期的读者。]
1.2) 背景
[pȝ名称]
[目提出者、开发者、用戗运行地点]
1.3) 定义
[术语和羃写说明]
1.4) 参考资?br />[本项目的计划d书或合同、上U机x文]
[本项目已发布文档]
[本文引用的其它文档资料(包括各种开发标准)]
2Q程序系l结?br />[用一pȝ图表列出模块内名元素的名U、标识及怺间的层次l构关系]
3Q元素烦引表
[元素索引Q元素名Q及其详l说明部分在本文中的h늠Q?/font>
4Q程序设?br />4.1) [元素?与烦引表中对?]
a) E序描述
[元素的目?意义/帔R内存/可重?q发/覆盖要求{等]
b) 功能
[该元素应h的功?可用IPO?]
c) 性能
[对元素性能的要?_ֺ/灉|?旉Ҏ等)]
d) 输入?br />[每一输入的Ҏ?名称/标识/cd/取D?输入方式/来源/安全{?]
e) 输出?br />[每一输出的Ҏ?名称/标识/cd/取D?输入方式/来源/安全{?]
f) 法
[元素使用的算?具体计算公式及计步骤]
g) 程逻辑
[元素的完整流E图(必须有完整的说明)]
h) 接口
[用图形方式说明本元素在系l中的定位及赋?参数/数据{信?/font>
i) 存储分配
[若有需?说明元素的存储分配方式]
j) 注释设计
[元素首部的注释内容]
[各节点的注释(变量功能/变量范围/~省条g{?]
[为所使用的逻辑加的注释内容]
k) 限制条g
[本元素正常运行所必需的条??必需有某文g)]
l) 试计划
[本元素的详细试计划(人员/环境/标准/反馈机制/评h方式/目标{?
m) 未解决的问?br />[元素设计中尚未解决需pȝ完成前必需解决的问题]
4.2) [元素?与烦引表中对?]
……内容与格式同 4.1
……同上Q直x有元素描q完?/font>
那到底应不应该写详细设计文档呢,怎么使详l设计文档vC应有的作用呢Q下面就让我们来认识一下详l设计及写详l设计文档的好处和问题?/span>
· 什么是详细设计
详细设计是相Ҏ要设计而言的,是瀑布开发流E的一个重要环节,在概要设计的高层设计的基上,从逻辑上实C每一模块的功能,是编码阶D늚主要参考资料,是从高层C层、逐步_思想的具体实现?/span>
详细设计文档的内容包括各个模块的法设计Q?/span> 接口设计Q?/span> 数据l构设计Q交互设计等。必d清楚各个模块/接口/公共对象的定义,列明各个模块E序?/span>各种执行条g与期望的q行效果Q还要正处理各U可能的异常?
· Z么要作详l设?/span>
在开发过E中Q由需求及设计不正、不完整所D的问题是目q度拖g、失败的一个主要因素,而Y件系l的一个重要特性就是需求和设计的不断构建和改进Q在写详l设计文档过E中Q?/span> 详细设计实际上是对系l的一ơ逻辑构徏Q可以有效验证需求的完整性及正确性?/span>
如果不写详细设计文档Q一般就从概讄接进入编码阶D,q时开发h员所能参考的资料是需求规D明书及页面原型、数据库设计{,不能直接q行开发,需要进行信息的沟通,把页面原型不能体现的设计讲清楚,q样既容易遗忘,也容易发生问题,详细设计文档可以作ؓ需求h员、M设计人员与开发h员的沟通工P把静态页面无法体现的设计体现出来Q包含整体设计对模块设计的规范,体现对设计上的一些决{,例如选用的算法,对一些关键问题的设计考虑{等Q开发h员能快速进入开发,提高沟通效率,减少沟通问题?/span>
对于pȝ功能的调_后期的维护,详设文档提供了模块设计上的考虑、决{,包括模块与整体设计的关系、模块所引用的数据库设计、重要操作的处理程、重要的业务规则实现设计{等信息Q提供了Ҏ块设计的概述性信息,阐明了模块设计上的决{,配合代码注释Q可以相对轻松读懂原有设计?/span>
· 存在的问?/span>
要由专门的h写,是比较麻烦的Q也是很需要时间的Q会对进度造成压力Q也Ҏ形成工作瓉Q设计人员负担q重Q而开发h员无事可作。对于现在一般的以数据库Z心的理pȝ而言Q这个工作始l是要作的,区别只不q是不是形成专门文档QŞ成文档可能会多花一两周旉Q但相对于规避的风险和问题来_也是值得的,另外׃现在高语言的流行,所以更详细的设计应该直接体现在代码的设计上Q而文档则只体现设计上的一些决{,协调整体设计与模块设计的关系Q把面原型所不能体现的设计情冉|档化Q所以所p的时间是有限的?/span>
设计内容Ҏq细Q但设计阶段是不能考虑特别清楚圎ͼ旉也不允许?/span>
对于q个问题Q一个对{是上边所提到的,文档只体现设计上的决{,面原型所不能反映的信息,详细设计只体现M设计Ҏ块设计的一些考虑Q例如对功能的数据库设计{等Q而具体的实现实现Q则C码中再去实现Q相关的设计也仅体现在代码中?/span>
需求、设计需要不断的被更新、构建,则设计文档需要不断的重新调整Q文档的l护需要跟上,否则文档和系l的同步很隑־C障了Q且造成多余的工作量。文档的内容易流于Ş势,质量p糕Q不能成为开发h员的参考手册,一是要建立L兛_度,如有修改Q先Ҏ档,后作开发,从工作流E上切实保障文档与系l的同步Q二是要规范文档质量Q对文档该写什么,不该写什么,标准是什么,_度是什么,语法应该如何l织Q有明确的标准和考虑Q同Ӟ建立审计文档评审、审核制度,充分保障pȝ的用?/span>
· 应该如何写详l设计文?/span>
下面讨论如何写出一个符合要求、实用的详细设计文档?/span>
首先是文档的内容Q根据项目和团队的不同,详细设计文档的内容也有所不同Q一般说来,_度不宜q细Q不能代替开发h员的设计和思考,但要把有兌计的决策考虑q去Q包括与其他模块、整体设计的关系、操作的处理程Q对业务规则的设计考虑{,有一个标准ؓQ凡是页面原型、需求规D明书所不能反映的设计决{,而开发h员又需要了解的Q都要写入文档?/span>
其次是文档所面向的读者,主要为模块开发h员、后期维护h员,模块开发h员通过详细设计文档和页面原型来了解所开发的功能Q后期维护h员通过实际pȝ、模块代码、详l设计文档来了解一个功能?/span>
再有是谁来写文档,因ؓ文档主要考虑的是设计上的决策Q所以写文档的h应该责、参加设计的技术经理、资q序员Q根据团队情况和目规模、复杂度的不同,也有所不同?/span>
q需要保证文档的可读性、准性、一致性,要徏立严格的文档模板及标准,保证文档的可L及准确性,同时建立审核及设计评审制度,来保障设计及文档的质量,另外在工作流E中要强调,要先设计、先写文档,再进行开发?/span>