完整word版概要设计.docx
- 文档编号:30093081
- 上传时间:2023-08-04
- 格式:DOCX
- 页数:18
- 大小:50.08KB
完整word版概要设计.docx
《完整word版概要设计.docx》由会员分享,可在线阅读,更多相关《完整word版概要设计.docx(18页珍藏版)》请在冰豆网上搜索。
完整word版概要设计
系统概要设计说明书
项目名称:
XXXXXX
实施项目
广州市财政信息中心
****年**月
文档控制页
版本记录
版本号
版本描述
责任人
修订日期
V0.1
草稿
2008-12-01
……
……
……
……
V0.4
2008-12-6
……
……
……
……
V1.0
2008-12-10
本文件由广州市财政局编写,并享有版权。
任何人或组织不得违反「版权法」,在未经同意的情况下,以任何形式(包括但不限于电子版、印刷版、微缩版、复印、录制等)复制本文件、将其储存于可读取的系统或发送出去。
本文件中出现的产品或公司名称是其各自拥有者的商标或注册商标。
非广州市财政局读者请注意:
本文件的内容不得有任何更改。
要保证本文件内容的准确性。
否则广州市财政局对后果不负责任。
第一章引言
一.1目的
提示:
简要说明编写这份概要设计说明书的目的,指出预期的读者。
概要设计说明书的编写目的是为了说明系统总体设计的技术方案,从程序系统的设计考虑,包括系统的基本处理流程、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等内容,以向整个设计期提供关于程序系统的逻辑和数据功能实现方式的总体描述,从而作为程序详细设计或编码的基础。
设计阶段将以本文档为核心文档。
应包括一下几个方面:
将系统需求转换为未来系统的设计
逐步功能需求逐步分解为模块和库,开发强壮的系统构架
使设计适合于实施环境,为提高性能而进行设计
概要设计说明书的适用读者为:
系统开发者、测试人员、工程监理等
一.2背景
1.说明待开发的软件系统的名称
2.列出本项目的任务委托单位、开发单位、协作单位、用户单位
3.说明项目背景,叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。
如果本次开发的软件系统是一个更大的系统的一个组成部分,则要说明该更大系统的组成和介绍本系统与其它相关系统的关系和接口部分
4.保密说明:
本项为可选项,一般的软件公司都会要求对软件开发的概要设计文档进行保密,不允许被复制、使用和扩散到公司之外的范围,如果需要强调则允许做相关的保密说明
5.版权说明:
本项为可选项,若有必要,才要作有关的描述。
一.3术语定义
提示:
对文档中的专业术语进行解释说明
序号
术语名称
术语定义
1
2
3
一.4参考资料
列出所本文档所使用的参考资料,包括:
1本软件开发所经核准的合同或标书或可行性报告等文档
2软件开发计划书
3需求分析报告
4测试方案(若存在初稿的话)
5与本项目有关的已发表的文件或资料
6本文件中各处引用的文件、资料,所采用的软件开发标准和规范
注意:
必须列出文件、资料的作者、标题、编号、发表日期和出版单位,以说明这些文件资料的来源。
若某些文档有保密要求的,则要说明其保密级别。
序号
文档名称
作者
版本/日期
1
2
3
第二章系统环境
一.5运行环境
一.1.1系统支撑环境
提示:
图、表形式给出为实现用户功能需求,而所涉及的软件、硬件环境以及网络环境。
1.XXX服务器
硬件配置要求
CPU
内存
磁盘空间
……
软件配置要求
操作系统
WebServer
数据库系统
应用服务器
……
2.客户端
硬件配置要求
CPU
内存
显示器
磁盘剩余空间
……
软件配置要求
操作系统
浏览器
……
一.1.2部署图
提示:
应清晰明确的给出用户和系统各功能以及系统物理结构和连接关系图。
应当符合UML建模规则。
一.1.3系统接口
提示:
系统、模块内部和系统、模块之间的接口规范。
图、表方式描述个功能模块间的接口定义、物理特性、软硬件特性等。
一.1.4系统安全控制
提示:
应设定系统安全保密体系和控制关系。
一.6运行模块组合
提示:
为可选项,说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合,说明每种运行所历经的内部模块和支持软件。
可以用图、表方式表现描述。
一.7运行环境的配置
提示:
说明本系统应当在什么样的环境下运行,有什么强制要求和建议?
类别
标准配置
最低配置
备注
计算机硬件
计算机软件
网络通信
其它
一.8条件与限制
提示:
为可选项,只要当软件系统的设计或开发受到某种特定的限制,或者可能直接能影响系统设计的某种因素,这些因素可能成为系统的设计约束,他们的改变可能会影响某些需求的实现时,才需要做概要介绍。
若存在以下方面的系统约束或条件限制时,可以进行相关的阐明:
(但不限于这些)
为完成本软件系统应具备的特定条件、开发单位已具备的条件以及尚需创造的条件,如:
现阶段还未到位的设备、资源等需要做出相应的约束说明。
必要时,还应说明用户及分合同承包者承担的工作、完成期限及其他条件与限制,如果用户及分合同承包者对系统的实现起到的某些作用会直接影响系统设计的成败则要特别说明。
本系统的设计规范需要受到某些特定的行业规范的限制。
本系统的开发需要受到用户对系统的工程化管理的某些特别的要求,包括用户规定对系统实现的全过程的变更规定。
本系统设计工作所需的一些假定条件和必须满足的约束,如本功能的开发假定用户会熟练使用SQL语言,本功能的实现应该在某功能实现前开发完成等。
本系统的设计可能需要使用的所有购入构件、所有适用的许可或使用限制,以及所有相关的兼容性及互操作性或接口标准的有关限制和规定。
第三章系统总体结构设计
一.9系统结构设计描述
结构设计是指定义软件系统各主要部件之间的关系。
总体结构设计就是将系统按照功能逻辑划分成多个子系统,各子系统再细划分第二层次结构——模块。
总体设计要遵循“开闭原则(Open-ClosedPrinciple)”——一个软件实体应当对扩展开放,对修改关闭。
具体来说,“开”就是扩展性要好,后面增加功能应该不需要修改到原来的结构或代码;“闭”就是与其它模块的调用通过封装成接口进行。
总体设计的基本步骤如下:
1.用选定的设计工具、计划中设定的交付方式(如小版本渐进交付)及团队已经掌握的设计方法,结合一些适当的设计原则(如功能模块化等),将系统分解为若干子系统,明确子系统中包含的功能模块。
2.确定子系统、功能模块间的约束、假设和依赖(如系统运行环境和开发、测试环境等,并考虑系统并发性和分布性要求)。
子系统之间的依赖关系在设计时尽量以接口的方式进行交互。
3.结合以上内容,对系统的模块逻辑实现和集成方法进行设计,降低使软件难于实现、测试(必要时测试人员参与讨论)、维护的因素,形成高内聚、低耦合的系统体系结构;
4.通过以上对系统的模块或子系统的设计、划分之后,形成系统总体结构图。
【编写实例参见如下:
】
系统设计主要是基于MVC设计模式,M代表模型Model,V代表视图View,C代表控制器Controller。
MVC模式将系统分为三层,层与层之间通过又一定的模式联系,使数据实体与业务逻辑、业务逻辑与页面展现分离。
MVC设计模式主要由三部分组成。
模型M是应用对象,没有用户界面。
视图V表示它在屏幕上的显示,代表流向用户的数据。
控制器C定义用户界面对用户输入的响应方式,负责把用户的动作转成针对Model的操作。
Model通过更新View的数据来反映数据的变化。
采用MVC模式的目的是增加代码的重用率,减少数据表达,数据描述和应用操作的耦合度。
同时也使得软件可维护性,可修复性,可扩展性,灵活性以及封装性大大提高,以满足系统设计原则。
关系如图:
图三-1模型关系图
一.10总体结构图
提示:
用模块图表达出系统的总结组成,结构,力求能够表达出从最高点看出系统的组成模块或子系统的分布与关系,力求简单、准确。
该图的模块或子系统的划分应该能够映射到最终实现的代码的工程项目或组件上。
一.11功能需求与程序的关系
提示:
对应需求说明书中描述各功能模块和系统模块对应功能描述。
功能需求
系统模块
功能简述
模块间的关系
一.12子系统清单
如果本系统划分了子系统,应该列出所有子系统来,按以下内容列出,子系统之间的划分应该有一定的原则,如按业务功能、按部署环境等,要统一一种原则。
编号
子系统名称
功能简述
子系统之间的关系
SS1
SS2
SS3
第四章模块功能分配
具有功能独立、能被调用的信息单元叫模块。
模块功能分配,分为公用模块和专用模块。
公用模块:
将具有相同功能的模块合并,从中提取公用模块,形成公用部件,作为本系统的公用资源,甚至作为总体的公用资源,从而优化系统设计,加快开发速度,提高开发质量。
专用模块:
专门用于实现用户特定需要或要求的模块,专用模块之间共性很低。
应该在系统概要设计阶段就充分考虑模块的重构与划分设计。
一.13系统划分及功能描述
提示:
说明本系统的系统元素(即各层模块、子程序、公用程序等)的划分,扼要说明每个系统元素的标识符和功能说明,分层次地给出各元素之间的控制与被控制的关系。
系统划分允许采用各种形式(如:
系统功能模块列表等)进行描述,建议用系统模块结构图表示,再附上简单的文字说明,以说明模块的层次结构以及相应的接口控制关系,有必要时需要介绍模块之间的调用关系,要求相应的功能模块最好要有一定的模块编号进行标识。
一.14专用模块功能概述
提示:
从本节开始描述各个功能模块的处理流程,建议每一个功能模块为单独一节,标题可以根据模块结构图中的模块划分情况自行决定。
描述系统中各个功能模块相应功能的全部细节,要求对每一个模块的设计都可以被实现,并能够被验证的,主要就是描述每一个模块的输入、输出和处理流程,必要时,可以借助业务流程图来描述。
建议采用活动图形式来描述模块内部和模块间的业务流程。
一.15公用模块功能概述
提示:
公共模块的部分与专用模块的描述形式相同,但这部分功能一般是多个模块都可以调用的,因此将其单独提出来进行描述,可以对系统进行更好的功能模块划分。
建议也是采用业务流程图描述。
版本控制管理
提示:
可选项,大中型系统设计模块众多,系统派生出来的个性化的半定制软件的升级需求,此时需要事先考虑有关软件产品升级班本的控制办法以及版本号的升级原则。
帮助模块
功能:
填写该模块实现的功能。
界面:
可用Visio画界面。
如果有原型可以统一在前面说明,不必每个模块填写。
输入:
填写模块输入信息。
(无输入可以省略)
输出:
填写模块输出信息。
(无输出可以省略)
处理逻辑:
填写模块业务处理流程,必要时使用流程图
数据结构:
该模块所涉及的数据结构,一般会列出业务处理所涉及到的库表清单
备注:
第五章数据库设计
数据库设计(DatabaseDesign)是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求(信息要求和处理要求)。
数据库是信息系统的核心和基础,把信息系统中大量的数据按一定的模型组织起来,提供存储、维护、检索数据的功能,使信息系统可以方便、及时、准确地从数据库中获得所需的信息。
数据库设计包括总体的数据库规划,各数据表的定义,字段(属性)定义,数据约束,表与表之前关系,主要数据算法的设计等内容。
确定项目数据库设计规则以便于系统统一,其中包括:
库命名,逻辑设计,物理设计,安全性设计及优化,管理规则等。
本节要说明了数据库设计的E-R图;数据库逻辑视图;数据库主要业务对象的表、属性(字段)以及关键外键。
数据库设计一般要经过“逻辑设计→物理设计→安全性设计→优化”等步骤,通常要迭代进行,包括:
1.逻辑设计
分析软件系统模块及其之间的数据操作,使用抽象数据类型设计,转换数据对象的属性及其关联、接口等内容,设计并完善数据字典及其约束条件,实现数据的变量封装结构设计。
面向结构设计方法中为创建与数据库相关的数据流图或实体关系图;若采用面向对象方法,则分析类信息传递内容,并创建类图;
2.物理设计
设计表结构,与实体关系图或类图相结合;对表结构进行规范化处理;
3.安全性设计
考虑数据库的登陆访问限制,用户密码加密,操作访问权限等系统安全设计;
4.优化
分析并优化数据库的“时—空”(即性能,容量等)效率,尽可能“提高处理速度”并且“降低数据占用空间”;
分析“时—空”效率的瓶颈,找出优化对象(目标),并确定优先级;
消除对象(目标)间的对抗性,必要时给出折中方案;
给出优化的具体措施,如逐步评估、优化数据库环境参数,对表格进行反规范化处理等,坚持信息隐蔽等原则,加强数据设计可维护性。
如果利用了某些工具(如PowerDesigner)能够自动生成一些物理文件,这里可以写明引用关系,而不需按照以下章节的表格来说明。
可以在对应章节中说明引用的物理文件。
如果设计的系统比较庞大(篇幅内容可能超过20页以上),可以将本章内容单独设立一个《数据库设计》文档,方便参考
建议使用PowerDesigner编写数据设计。
一.16逻辑视图
提示:
用UML语言表达出数据库各对象的逻辑关系图,可以通过RationalRose生成各个模块的类图来进行描述。
一.17数据库表关系图
提示:
将业务对象的逻辑视图转换成可以通过数据库进行实施的物理视图,一般用E--R图表示,也可以用其它能够表达的方式表达,例如表格。
一.18数据表清单
对(全局)数据结构进行具体设计,以确定具体的数据项及其数据属性,如:
数据类型、长度及各种数据的约束条件等等,包括各种常量所用到的代码或常数信息,并详细描述各种代码的编码规则,以及有效值中只有有限的几个,则需要一一罗列,如果存在数据库,则要详细说明数据库的表划分以及各个字段的数据结构说明,必要时允许借助有关数据库设计CASE工具描述ER图模型的方式进行说明,也允许通过CASE工具自身的模板格式转成DOC文档后加入本章节内容,还可以用CASE工具产生的文档做为附件进行保存。
本章内容可以按照接口用数据结构和系统内部数据结构进行分节,也可以根据具体的数据库库表结构进行分节,标题根据设计需要自行确定。
关于数据结构的设计建议参照以下编写格式:
当前库:
XXXXXXXXX
备份库:
XXXXXXXXX
历史库:
XXXXXXXXX
下面是库表的总体列表,用来简述各个库表的具体功能
序号
中文表名
英文表名
表功能说明
1
2
3
最后是对库表字段的描述
表名:
(这里直接用英文表名描述即可)
字段名称
类型
长度
字段说明
索引
主键
外键
默认值
取值范围
一.19主要算法设计
提示:
列出一些主要或关键的算图的思路,可以用文字表达,也可以使用伪码表达。
一.20其它数据结构设计
提示:
可以补充有关数据库设计本节以上所列之外的内容。
第六章接口设计
提示:
接口设计是指系统内部,系统和操作系统间、多个系统间以及系统和人之间如何通信。
与在需求阶段与客户交流有关现存系统的运行情况以及获取数据的需求,得到系统外部接口;在概要设计阶段,通过子系统划分、模块划分中抽象、归纳出各子系统的接口、模块之间通讯的重要接口,加以定义形成设计文档的中接口设计。
接口设计时要考虑扩展子系统或功能模块及其之间的关系和限制条件,实施系统所需的接口设计。
结合系统错误处理和数据验证方法,验证接口设计结果,并逆向需求求证接口正确性。
接口设计为可选项,若存在有关的接口则是必选项,否则容易产生开发者对系统设计的二义性时需要详细描述。
本章若存在N个接口,则可分为N节来描述。
一.21用户接口
提示:
确认用户界面、人机操作之间的接口。
设备上的按钮、系统中的界面元器件图的功用等等。
一.22内部接口
提示:
模块内部的接口协议,数据交换以及其能力支持。
一.23外部系统接口
提示:
描述内容包括如下:
接口名称:
方法:
内容简介:
输入参数:
返回结果:
接口调用要求:
第七章安全保密设计
提示:
包括了系统故障预防与恢复,系统使用安全,例如用户权限等方面的考虑。
如果项目系统对于系统安全保密性要求较高的情况下,必须在设计时,充分考虑这一部分内容,包括故障发生如何预防或处理。
如何管理用户的合法登录或权限等。
本节为可选项,如果系统设计对安全保密性有特别的要求,则需要详细描述,主要可以从以下几方面进行考虑:
系统故障预防与恢复、用户管理和权限控制、数据备份和恢复等
一.24用户管理和权限控制
提示:
说明在数据库的设计中,将如何通过区分不同的访问者、不同的访问类型和不同的数据对象,进行分配权限并分别对待而获得的数据库安全保密的设计考虑。
第八章维护及出错处理设计
提示:
应罗列系统维护的方便而在程序内部设计中作出的安排。
系统可能的出错或故障情况出现的各种出错处理信息,包括系统出错信息提示的形式(包括出错对话框的设计)、含义及处理方法等。
在操作出错或数据出错等情况下,系统显示或记录的有关出错代码/信息
系统运行出错时,提示语言要友好,并以用户习惯为基础,使用户能够理解发生的问题,并能够根据提示采取正确的操作方式。
一.25系统维护设计
提示:
图、表方式描述在设计过程中考虑到的系统交付运行后可能的维护特性和方式方法等。
包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。
各个程序之间的对应关系。
一.26出错信息
提示:
用表格形式列出每种可能的出错或故障情况出现时,系统输出信息的形式、含义及处理方法。
一.27出错处理
提示:
表格形式明确描述系统出错后,应采取的补救措施,需要提供的备用系统、设备、数据库等,以保证系统平稳运行。
一.28系统故障预防与恢复
提示:
为可选项,如果存在可能出现的系统故障需要恢复的情况,则要进行设计描述,主要说明将使用的恢复再启动技术,使软件从故障点恢复执行或使软件从头开始重新运行的方法,建议可按照以下格式进行说明:
为恢复系统(包括软硬件)故障和人为因素引起的数据错,特设计以下措施:
出错现象
可能原因
措施
一.29数据备份与恢复
提示:
为可选项,如果存在数据备份与恢复的需求要求,则要做相应的设计描述。
对数据备份与恢复的设计,主要说明在适当的时间点上,如何设计系统的数据备份和数据恢复功能,以便在系统失效、出现意外及数据出错、或有充分的需要的时候,可以在可接受的时间内得以恢复到最近或以前某个时间点的数据备份上,要求描述清楚实现数据备份和恢复的整个设计思想以及实现方法。
第九章设计约束
提示:
本节描述客观存在或客户需求的某些约定,或条件限制不能按常规设计要求。
如,指定某些编程语言不支持的操作系统、数据库系统、用户指定必须购买某些第三方子系统或组件等。
一.30字节集编码约束
提示:
清晰明确标注项目采用的字符集类型,以免发生编码冲突。
一.31操作系统约束
提示:
为可选项,在运行、维护系统设置等环境中需要对操作系统设置的约束条件。
一.32其他约束
第十章附件
提示:
罗列与本概要设计报告相关的文档资料,可包括以下内容:
●数据库设计的有关文档资料
●用户界面有关约定、相关报表或模板格式、各种常规底稿模板等
●各种设计规范,可包括屏幕设计规范、程序设计规范、存储过程设计规范、出错处理设计规范等等
●其它相关资料
评审意见
提示:
在举行评审之后,根据评审决议,由主持人组织填写以下内容,评审“综合意见”由主持人总结评审情况下决论性的表述;“结论”则是根据《评审指南》中的相关要求,对照选择;评审参与人,如实填写相关的人员。
评审意见
综合意见:
本文档经过大家评审讨论,最后一致认为:
可以通过/修改***些问题之后直接通过/存在较多问题,如***,请修改后举行第二次评审/或进行网站评审/或进行邮件评审。
结论:
一致同意通过
保留部分意见,通过
问题较多,不能通过
评审参与人员
角色
人员
个人意见
主持人
【个人保留的意见填写,完全同意或不同意,本栏都不写。
】
记录人
主要作者
评审人1
评审人2
评审人…
QA人员
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 完整 word 概要 设计
![提示](https://static.bdocx.com/images/bang_tan.gif)