概要设计模板

 

 

 

 

 

XXX项目

概要设计说明书

 

 

 

 

 

 

 

 

 

XXXXXXXXXX股份有限公司

 

拟制：	文档编号：
审核：
批准：	文档版本号：
生效日期：	机密等级：

 

 

 

修改记录

修订号	作者	日期	简要说明

 

 

此页由EPG编写，项目实施人员不用更改任何地方

 

模板编写及修订记录

拟制：	模板编号：
审核：
批准：	版本号： V2.0
生效日期：2019年7月30日	机密等级：内部公开
修订号	作者	日期	简要说明
V0.1		2019年4月15日	新制作
V0.2		2019年5月8日	评审版
V1.0		2019年6月1日	正式发布
V1.1		2019年6月29日	修改文档格式
V2.0		2019年7月30日	正式发布

此页由EPG编写，项目实施人员不用更改任何地方

 

 

 

 

目 录

XXX项目_概要设计书... 1

1     引言... 2

1.1      编写目的... 2

1.2      参考文献... 2

1.3      术语与缩写解释... 2

2     总体设计... 2

2.1      系统概述... 2

2.2      系统设计原则... 2

2.3      设计中应用的关键技术... 3

2.4      系统结构图... 3

2.5      网络结构图... 3

2.6      系统功能模块图... 3

2.7      数据流向图（或称为时序图）... 3

2.8      模块构成... 3

3     环境设计... 4

4     硬件设备... 4

5     支持软件... 4

6     接口设计... 4

6.1      用户接口... 4

6.2      外部接口... 4

6.3      内部接口... 4

7     数据库设计... 4

7.1      数据库环境说明... 4

7.2      数据库命名规则... 4

7.3      逻辑设计... 5

7.4      物理设计... 5

7.5      安全性设计... 6

8     公用结构... 7

9     界面设计... 7

10       出错处理设计... 7

11       开发工具... 7

12       附录... 7

 

1引言

1.1编写目的

 

[说明编写这份概要设计说明书的目的,指出预期的读者]

例如：

   本设计说明书简单阐明了XXX系统的XXX模块的基本设计思想、基本功能、模块划分以及模块间接口。以便于各模块开发人员能更好地了解该系统的基本情况及各模块详细功能。

1.2参考文献

提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：

[标识符] 作者，文献名称，出版单位（或归属单位），日期

例如：

[AAA] 作者，《立项调查报告》，机构名称，日期

[BBB] 作者，《立项可行性分析报告》，机构名称，日期

[SPP-PROC-PIM] EPG，立项管理规范，机构名称，日期

1.3术语与缩写解释

缩写、术语	解 释
SPP	精简并行过程，Simplified Parallel Process
PIM	立项管理，Project Initialization Management
…

2总体设计

 

2.1系统概述

[说明对本系统或模块的设计思想：模块划分原则、网络设计原则、开发模型等。]

2.2系统设计原则

[说明本文件设计应遵循的原则等。]

2.3设计中应用的关键技术

［说明本文件设计应用的关键技术，如多类型空间数据集成技术、海量图库管理技术、国土资源信息管理的多级服务器组建技术、国土资源信息WEB发布技术、工作流驱动技术、时域GIS管理技术］

2.4系统结构图

[说明系统的内部结构，子系统/模块间的联系等，必须以图示和文字说明相结合]

2.5网络结构图

[说明本系统在整体网络中的地位，及其和外界网络的关系，必须以图示和文字说明相结合]

2.6系统功能模块图

[说明本系统的功能模块组成，及其各模块间的数据接口，各模块之间的控制与被控制关系，必须以图示和文字说明相结合]

2.7数据流向图（或称时序图）

[说明系统和外界的数据交互流程，并注明数据类型

或是模块和其它模块的数据交互流程，并注明模块间交互的数据类型]

【可参考《需求开发指南5.2》】

2.8模块构成

系统划分模块：

对系统(或模块)中每一个功能，用图示或文字详细描述：

• 概述 --- 叙述功能名称、目标和作用；
• 输入 --- 叙述该功能输入的消息；
• 处理 --- 描述该功能做什么，如何对输入信息进行加工并转换成输出信息；
• 输出 --- 详述该功能输出的信息；
• 自主开发、复用、外包、采购方案---详述该模块的设计方案，包括自主开发、复用、外包、采购的选项。

 

模块名称	概述	输入	输出	处理	自主开发、复用、外包、采购方案

3环境设计

[简要地说明对本系统的运行环境的规定]

4硬件设备

[列出运行该软件所需要的硬设备.说明其中的新型设备及其专门功能.]

5支持软件

[列出支持软件,包括要用到的操作系统、编程语言、编译(或汇编)程序、测试支持软件等及各软件的版本。]

6接口设计

接口设计原则

取得一致性

类似的情况应该有让使用者有一致性的操作。在提示、选单与说明文件中，应该采用同样的名词。并且保持命令的一贯性。

让重度使用者使用快捷方式

当使用频率增加时，使用者会希望减少互动的次数、让每次的互动能够一次做更多的动作。缩写、功能键、隐藏功能与综观全局的功能，对专家来说非常有用。

提供有意义的回馈

当使用者做出一些动作时，系统应该提供回馈。越频繁的动作，其回馈的强度可以低一些。越重要或不寻常的动作，其回馈强度应该要显著一些。

设计对话产生结束

一连串的动作应该被组织成开始、中间、结束三部份。当动作结束的时候，要提供回馈让使用者知道动作已经完成。在做下个一连串的动作之前，先告知使用者整个流程，能够减轻使用者的压力、提高满意度。

提供简单的错误处理

最好不要让系统有严重错误的可能性。如果还是造成错误，系统应该能够侦测出来，并提供一个简单、使用者可以理解的错误处理方式。

允许回到上一步

这个功能可以减低使用者的焦虑，因为使用者只到做错了可以重来。这个功能鼓励使用者探索不熟悉的选项。回到上一步的功能，可以包含一个、或是一连串的动作。

 满足使用者控制的需求

有经验的使用者强烈的感觉到他们在控制系统，做出动作之后，系统提供回馈。系统设计上要让使用者作为动作的处发者，而不是响应者。

减少短期记忆需求

人类的短期记忆有限，因此显示上要保持简单、能同时显示多页数据以减少窗口切换频率，减少记忆指令和动作顺序的时间。

 

设计方法

接口是提供给其他模块或者系统使用的一种约定或者规范。因此接口必须要保证足够的稳定性和易用性。这是设计接口的基本要求。

1.稳定性

接口必须相对稳定，否则将导致接口的使用者和提供者为了适应新接口而不断修改接口的实现，可能重复进行无用功，严重时影响整个软件开发进度。那么如何保证设计的接口相对稳定呢？

首先，接口的语义必须明确。包括接口调用方法、接口名称、参数的类型和名称。抽象的接口名称或者参数名称使人困惑或者理解错误。如下例：

History::SetAttribute   

设置历史记录的属性，初看不知道该接口要做什么。除非History的属性很多否则没有必要设计这样的接口。

ioctl

C库中的ioctl，其实很难用原因是需要设置项太多，每个项的参数又不太一致，接口使用者的压力就较大了。但是接口设计者也是不得已而为之，由于IO的设置接口的应用情况较多，如果每个设置接口都单独提供一个接口则会导致非常多的接口，另外就是保证接口的相对稳定，采用抽象的数据的接口便于移植和稳定。

因此，明确的接口语义例外情况就是对于辅助功能，如果需要较多接口，则可以合成一个接口，采用不同参数区分（如windows中的窗口处理过程类型的定义也是这种情况）。   

其次，采用版本定义来区分接口的差异。比如提供接口版本查询功能，接口实现着提供接口版本的查询功能。

2.易用性

 接口是提供给第三方使用的，较难用的接口会导致接口使用者的抱怨。    如： SetCookie(void* handle, const CookieParam& param); GetCookie(void* handle, CookieParam& param);此接口名称的意义还是比较明确的，但是参数CookieParam过于抽象，将导致接口的调用者在使用接口时，需要将基本数据类型的值组成一个CookieParam类型，然后才能调用接口。这是一种糟糕的接口设计。既不便于使用又不便于编译器优化（待确认） 如果该为下面的接口则较容易使用 SetCookie(void* handle, const URL& url, const String& cookie); GetCookie(void* handle, const URL& url, String cookie);除非接口的参数个数超过5个，否则最好采用基本数据类型作为参数。超过5个参数的函数一方面给调用者带来困难，参数排列组合的情况过多，另一方面就是不利于编译器优化时采用寄存器传递参数。

6.1用户接口

[说明将向用户提供的命令和它们的语法结构，以及相应的回答信息。]

    [说明提供给用户操作的用户界面采用的形式，如屏幕格式、报表格式、菜单格式等]

6.2外部接口

[说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持系统之间的接口关系。]，配置文件。

6.3内部接口

[说明本系统之内的各个系统元素之间的接口的安排。]，配置文件等。

7制作购买重用分析

软件复用有三个基本原则：　

（1）必须有可以复用的对象；

（2）所设计的可复用对象必须是有用的；

（3）复用者需要知道如何使用被复用的对象。

　软件复用包括两个相关过程：即可复用软件（构件）或软件的可复用部分的开发(Development for Reuse)和基于可复用软件（构件）或软件可复用的部分的应用系统构造（集成和组装）（Development with Reuse）。

 

采用软件复用技术主要有以下优点：

（1）提高软件生产率、减少开发时间；

（2）提高软件质量，开发出来的软件可靠性高；

（3）降低开发风险；

（4）简化软件开发流程，使得软件开发易于管理；

（5）降低维护难度、工作量和费用，提高了软件系统效益；

（6）便于学习系统结构和建立好的系统，促进软件开发过程的标准化；

（7）易于提供文档资料等。

软件外购的原则

（1）外购费用小于开发人力成本。

（2）外购软件能大量缩短工期。

（3）外购软件集成成本小于项目成本的1%。

（4）外购软件技术是本公司急切需要的。

7.1外购模块的设计

[简要地说明本系统的需要外购的模块及外购原因，存在的问题和注意事项]

7.2复用模块的设计

[简要地说明本系统的需要复用的模块及复用的原因，存在的问题和注意事项]

8数据库设计

[客户化开发类、维护类项目可将数据库设计独立一份文档，见《数据库设计说明书》]

8.1数据库环境说明

[说明所采用的数据库系统，设计工具，编程工具等。]

8.2数据库命名规则

[提示：

（1）完整并且清楚的说明本数据库的命名规则。

1. 数据库表的命名规则
2. 列的命名规则
3. 存储过程的命名规则
4. 触发器的命名规则

（2）如果本数据库的命名规则与机构的标准不完全一致的话，请作出解释。 ]

8.3逻辑设计

[数据库设计人员根据需求文档，创建与数据库相关的那部分实体关系图（ERD）。如果采用面向对象方法（OOAD），这里实体相当于类（class）。]

8.4物理设计

[主要是设计表结构。一般地，实体对应于表，实体的属性对应于表的列，实体之间的关系成为表的约束。逻辑设计中的实体大部分可以转换成物理设计中的表，但是它们并不一定是一一对应的。

对表结构进行规范化处理（第三范式）。]

 

8.4.1表汇总

表名	功能说明
Sys_dict	数据字典表
……	……

8.4.2Sys_dict（数据字典表）

表名：Sys_dict 用户模式： 分区：无 索引：group_id+dict_id（key） 实体存放： 用途说明： 维    护：
字段名	数据类型	NULL	中文说明
group_id	Number(8)	NN	组编码
Group_name	Varchar2(80)	NN	组名称
dict_id	Number(8)	NN	字典编码
dict_name	Varchar2(80)	NN	字典名称
Dict_value	Varchar2(255)	NN	字典值
Dict_index	Number(3)	N	字典顺序
remark	Varchar2(255)	N	备注

8.5安全性设计

​

8.5.1防止用户直接操作数据库的方法

[提示：用户只能用帐号登陆到应用软件，通过应用软件访问数据库，而没有其它途径操作数据库。]

 

 

8.5.2用户帐号密码的加密方法

[提示：对用户帐号的密码进行加密处理，确保在任何地方都不会出现密码的明文。]

​​

8.5.3角色与权限

[提示：确定每个角色对数据库表的操作权限，如创建、检索、更新、删除等。每个角色拥有刚好能够完成任务的权限，不多也不少。在应用时再为用户分配角色，则每个用户的权限等于他所兼角色的权限之和。]

 

角色	可以访问的表与列	操作权限
角色A
角色B

9界面设计

［本文档是对应遵循的界面设计的基本原则进行描述。］

10出错处理设计

［本文档是对应遵循的出错处理的基本原则进行描述。］

11附录

[把其他与设计相关的文档放在这里，可以直接写在文档中，也可以放到其他文档中，在这里进行索引。比如利用其他工具所做的各种模型文件等。]