数据库设计说明书编写目的（数据实时分析系统的概要设计文档怎么写）

本文目录

• 数据实时分析系统的概要设计文档怎么写
• 软件著作权申请中的文档（设计说明书或用户手册）怎么写
• 数据库设计说明书,由谁编写,写给谁看
• 详细设计说明书详细设计说明书编写目的
• 软件开发整体方案详解
• 简述GIS工程中的文档种类及作用
• 软件开发方案的软件开发方案
• 详细设计的说明书

数据实时分析系统的概要设计文档怎么写

软件文档中概要设计也称“总体设计”，是开发人员在明确用户需求（要什么）后对系统的一个总体考虑（明确系统目标、设计原则，初步考虑数据库设计和功能设计），国家关于这方面有相关标准（概要设计说明书（GB8567-88））。在具体实践中可以按下列提纲撰写内容：1．引言1.1编写目的

软件著作权申请中的文档（设计说明书或用户手册）怎么写

中国版权保护中心接收登记的文档包含两种：操作说明书或设计说明书。  

设计说明书适合没有界面的嵌入式软件，插件软件，后台运行软件以及游戏软件。一般包含结构图，软件流程图，函数说明，模块说明，数据接口，出错设计等。
操作说明书适合管理类软件，有操作界面，一般应包含登录界面，主界面，功能界面截图，截图之间有相应的文字说明，能全面展示软件的主要功能。
格式要求：

一、说明书应提交前、后各连续30页，不足60页的，应当全部提交。 

二、说明书页眉应标注软件的名称和版本号，应当与申请表中名称完全一致，页眉右上应标注页码，说明书每页不少于30行，有图除外，另外截图应该清晰完整。

(1)引言

①编写目的：阐明编写手册的目的，指明读者对象。

②项目背景：说明项目的来源、委托单位、开发单位及主管部门。

③定义：列出手册中用到的专门术语定义和缩写词的原意。

④参考资料：列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源。

包括项目的计划任务书，合同或批文；项目开发计划；需求规格说明书；概要设计说明书；详细设计说明书；测试计划；手册中引用的其他资料、采用的软件工程标准或软件工程规范。

(2)软件概述

①目标。

②功能。

③性能。包括数据精确度(包括输入、输出及处理数据的精度)，时间特性(如响应时间、处理时间、数据传输时问等)，灵活性(在操作方式、运行环境需做某些变更时软件的适应能力)。

(3)运行环境

①硬件：列出软件系统运行时所需的硬件最小配置，如计算机型号、主存容量；外存储器、媒体、记录格式、设备型号及数量；输入、输出设备；数据传输设备及数据转换设备的型号及数量。

②支持软件：操作系统名称及版本号；语言编译系统的名称及版本号；数据库管理系统的名称及版本号；其他必要的支持软件。

(4)使用说明

①安装和初始化：给出程序的存储形式、操作命令、反馈信息及其含义、表明安装完成的测试实例以及安装所需的软件开发工具等。

②输入：给出输入数据或参数的要求。

③输出：给出每项输出数据的说明。

④出错和恢复：出错信息及其含义、用户应采取的措施，如修改、恢复、再启动等。

⑤求助查询：说明如何操作。

(5)运行说明

①运行表：列出每种可能的运行情况，说明其运行目的。

②运行步骤：按顺序说明每种运行的步骤，应包括运行控制；操作信息(运行目的、操作要求、启动方法、预计运行时间、操作命令格式及说明、其他事项)；输入/输出文件(给出建立和更新文件的有关信息。

如文件的名称及编号、记录媒体、存留的目录、文件的支配)；启动或恢复过程。

(6)非常规过程：提供应急或非常规操作的必要信息及操作步骤，如出错处理操作、向后备系统切换操作以及维护人员须知的操作和注意事项。

(7)操作命令一览表：按字母顺序逐个列出全部操作命令的格式、功能及参数说明。

(8)程序文件(或命令文件)和数据文件一览表：按文件名字母顺序或按功能与模块分类顺序逐个列出文件名称、标识符及说明。

(9)用户操作举例。

数据库设计说明书,由谁编写,写给谁看

开发团队

如果你们对于数据库和应用程序的开发有分工的话,那么所有关于数据库方面的都有数据库那边的人写,如果没有分工,就你们自己写

存档的目的一个是便于团队之间的沟通,再一个就是方便事后对程序或者数据库进行修正\升级等, 会有一定记录来告诉你数据库中各个表\字段等都是什么含义,以及他们之间的关系, 尤其对一些年久失修的应用程序来说,就不用全部看代码了

详细设计说明书详细设计说明书编写目的

1、软件详细设计说明书2、详细设计说明书到底怎么写？3、详细设计说明书的参考资料

软件详细设计说明书

面向对象软件设计说明书模板

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 对象描述

在这个部分叙述每个对象的细节，它的属性、它的方法。在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好。

为每个对象做一个条目。在系统对象模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。如果对象是存储在持久的数据容器中，标明它是持久对象，否则说明它是个临时对象（transient object）。

对每个对象的每个属性详细说明：名字、类型，如果属性不是很直观或者有约束（例如，每个对象的该属性必须有一个唯一的值或者值域是有限正整数等）。

对每个对象的每个方法详细说明：方法名，返回类型，返回值，参数，用途以及使用的算法的简要说明（如果不是特别简单的话）。如果对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明。列出它或者被它调用的方法需要访问或者修改的属性。最后，提供可以验证实现方法的测试案例。

6.1 子系统1中的对象

6.1.1 对象：对象1

用途：

约束：

持久性：

6.1.1.1 属性描述：

1. 属性：属性1

类型：

描述：

约束：

2. 属性：属性2

6.1.1.2 方法描述：

1. 方法：方法1

返回类型：

参数：

返回值：

Pre-Condition：

Post-Condition：

读取/修改的属性：

调用的方法：

处理逻辑：

测试例：用什么参数调用该方法，期望的输出是什么

7 动态模型

这部分的作用是描述系统如何响应各种事件。例如，可以建立系统的行为模型。一般使用顺序图和状态图。

确定不同的场景（Scenario）是第一步，不需要确定所有可能的场景，但是必须至少要覆盖典型的系统用例。不要自己去想当然地创造场景，通常的策略是描述那些客户可以感受得到的场景。

7.1 场景（Scenarios）

对每个场景做一则条目，包括以下内容：

场景名：给它一个可以望文生义的名字

场景描述：简要叙述场景是干什么的以及发生的动作的顺序。

顺序图：描述各种事件及事件发生的相对时间顺序。

7.1.1 场景：场景1

描述：

动作1

动作2

7.2 状态图

这部分的内容包括系统动态模型重要的部分的状态图。可能你想为每个对象画一个状态图，但事实上会导致太多不期望的细节信息，只需要确定系统中一些重要的对象并为之提供状态图即可。

7.2.1 状态图1：

8 非功能性需求

在这个部分，必须说明如何处理需求文档中指定的非功能性需求。尽可能客观地评估系统应付每一个非功能性的需求的能力程度。如果某些非功能性需求没有完全在设计的系统中实现，请务必在此说明。另外，你也需要对系统将来的进化作一个估计并描述本设计如何使系统能够适应这些可预见的变化。

9 辅助文档

提供能帮助理解设计的相应文档。

10 词汇索引

文章录入

详细设计说明书到底怎么写？

详细设计，这是考验技术专家设计思维的重要关卡，详细设计说明书应当把具体的模块以最’干净’的方式(黑箱结构）提供给编码者，使得系统整体模块化达到最大；一份好的详细设计说明书，可以使编码的复杂性减低到最低，实际上，严格的讲详细设计说明书应当把每个函数的每个参数的定义都精精细细的提供出来，从需求分析到概要设计到完成详细设计说明书，一个软件项目就应当说完成了一半了。换言之，一个大型软

件系统在完成了一半的时候，其实还没有开始一行代码工作。

那些把作软件的程序员简单理解为写代码的，就从根子上犯了错误了。

详细设计说明书的参考资料

列出有关详细设计说明书的参考资料，如：

a．本项目的经核准的计划任务书或合同、上级机关的批文详细设计说明书；

b．属于本项目的其他已发表的文件；

c.本文件中各处引用到的文件资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。

F.2程序系统的结构

用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）的名称、标识符和它们之间 的层次结构关系。

F.3程序1（标识符）设计说明

从本章开始，逐个地给出各个层次中的每个程序的设计考虑。以下给出的提纲是针对一般情况的。 对于一个具体的模块，尤其是层次比较低的模块或子程序，其很多条目的内容往往与它所隶属的上一层 模块的对应条目的内容相同，在这种情况下，只要简单地说明这一点即可。

F.3.1程序描述

给出对该程序的简要描述，主要说明安排设计本程序的目的意义，并且，还要说明本程序的特点（如 是常驻内存还是非常驻？是否子程序？是可重入的还是不可重入的？有无覆盖要求？是顺序处理还是并发 处理卜..等）。

F.3.2功能

说明该程序应具有的功能，可采用IPO图（即输入一处理一输出图）的形式。

F.3.3性能

说明对该程序的全部性能要求，包括对精度、灵活性和时间特性的要求。

F.3.4输入项

给出对每一个输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式。 数量和频度、输入媒体、输入数据的来源和安全保密条件等等。

F. 3. 5输出项

给出对每一个输出项的特性，包括名称、标识、数据的类型和格式，数据值的有效范围，输出的形式、 数量和频度，输出媒体、对输出图形及符号的说明、安全保密条件等等。

F．3．6算法

详细说明本程序所选用的算法，具体的计算公式和计算步骤。

F．3．7流程逻辑

用图表（例如流程图、判定表等）辅以必要的说明来表示本程序的逻辑流程。

F．3.8接口

用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序，说明参数赋值和调用方式，说明与本程序相直接关联的数据结构（数据库、数据文卷）。

F．3.9存储分配

根据需要，说明本程序的存储分配。

F．3．10注释设计

软件开发整体方案详解

软件开发整体方案详解

　　软件开发是根据用户要求建造出软件系统或者系统中的软件部分的过程。软件开发是一项包括需求捕捉、需求分析、设计、实现和测试的系统工程。下面是我整理的关于软件开发整体方案详解，欢迎大家参考!

　　第一章引言

　　1.1 编写目的

　　说明编写详细设计方案的主要目的。

　　说明书编制的目的是说明一个软件系统各个层次中的每个程序(每个模块或子程序)和数据库系统的设计考虑，为程序员编码提供依据。

　　如果一个软件系统比较简单，层次很少，本文件可以不单独编写，和概要设计说明书中不重复部分合并编写。

　　方案重点是模块的执行流程和数据库系统详细设计的描述。

　　1.2 背景

　　应包含以下几个方面的内容：

　　A. 待开发软件系统名称;

　　B. 该系统基本概念， 如该系统的类型、从属地位等;

　　C. 开发项目组名称。

　　1.3 参考资料

　　列出详细设计报告引用的文献或资料，资料的作者、标题、出版单位和出版日期等信息，必要时说明如何得到这些资料。

　　1.4术语定义及说明

　　列出本文档中用到的可能会引起混淆的专门术语、定义和缩写词的原文。

　　第二章设计概述

　　2.1 任务和目标

　　说明详细设计的任务及详细设计所要达到的目标 。

　　2.2 需求概述

　　对所开发软件的概要描述, 包括主要的业务需求、输入、 输出、主要功能、性能等，尤其需要描述系统性能需求。

　　2.3 运行环境概述

　　对本系统所依赖于运行的硬件，包括操作系统、数据库系统、中间件、接口软件、可能的性能监控与分析等软件环境的描述，及配置要求。

　　2.4 条件与限制

　　详细描述系统所受的内部和外部条件的约束和限制说明。包括业务和技术方面的条件与限制以及进度、管理等方面的限制。

　　2.5 详细设计方法和工具

　　简要说明详细设计所采用的方法和使用的工具。如HIPO图方法、IDEF(I2DEF)方法、E-R图，数据流程图、业务流程图、选用的CASE工具等，尽量采用标准规范和辅助工具。

　　第三章系统详细需求分析

　　主要对系统级的需求进行分析。首先应对需求分析提出的企业需求进一步确认，并对由于情况变化而带来的需求变化进行较为详细的分析。

　　3.1 详细需求分析

　　包括：详细功能需求分析、详细性能需求分析、详细资源需求分析、详细系统运行环境及限制条件分析

　　3.2 详细系统运行环境及限制条件分析接口需求分析

　　包括：系统接口需求分析、现有硬、软件资源接口需求分析、引进硬、软件资源接口需求分析

　　第四章 总体方案确认

　　着重解决系统总体结构确认及界面划分问题。

　　4.1 系统总体结构确认

　　对系统组成、逻辑结构及层次进行确认，对应用系统、支撑系统及各自实现的功能进行确认，细化集成设计及系统工作流程，特别要注意因软件的引进造成的系统本身结构和公司其他系统的结构变化。包括：系统组成、逻辑结构及层次确认、应用系统结构确认、支撑系统结构确认、系统集成确认、系统工作流程确认

　　4.2 系统详细界面划分

　　4.2.1 应用系统与支撑系统的详细界面划分

　　应用系统与支撑系统之间的界面包括系统主服务器与其他服务器的服务范围及访问方式，网络及数据库对应用系统的支撑方式，全局数据的管理与存取方式等。

　　4.2.2系统内部详细界面划分

　　系统各功能之间的界面包括覆盖范围，模块间功能调用涉及到的系统模块及方法，全局数据格式，系统性能要求等。

　　第五章　系统详细设计

　　5.1 系统结构设计及子系统划分

　　对系统的组成及逻辑结构进行设计前确认。

　　划分系统功能模块或子系统(如果有或者有必要，特别是大型的软件系统)。

　　5.2 系统功能模块详细设计

　　按结构化设计方法，在系统功能逐层分解的基础上，对系统各功能模块或子系统进行设计。此为详细设计的主要部分之一。

　　用层次图描述系统的总体结构、功能分解及各个模块之间的相互调用关系和信息交互，用IPO图或其他方法描述各模块完成的功能。 以上建议采用HIPO图进行功能分解与模块描述，更高的要求建议采用IDEF0方法进行功能模型设计。

　　详细设计应用系统的各个构成模块完成的功能及其相互之间的关系，用IPO或结构图描述各模块的组成结构、算法、模块间的接口关系，以及需求、功能和模块三者之间的交叉参照关系。

　　每个模块的描述说明可参照以下格式：

　　模块编号：

　　模块名称：

　　输入：

　　处理：

　　算法描述：

　　输出：

　　其中处理和算法描述部分主要采用伪码或具体的`程序语言完成。

　　对详细设计更高的要求建议用IDEF0图进行各功能模块的设计。

　　如果对软件需进行二次开发(包括功能扩展、功能改造、用户界面改造等)，则相应的设计工作应该设立子课题完成。

　　5.3 系统界面详细设计

　　系统界面说明应用系统软件的各种接口。整个系统的其他接口(如系统硬件接口、通讯接口等)在相应的部分说明。

　　5.3.1 外部界面设计

　　根据系统界面划分进行系统外部界面设计，对系统的所有外部接口(包括功能和数据接口)进行设计。

　　5.3.2 内部界面设计

　　设计系统内部各功能模块间的调用关系和数据接口。

　　5.3.3 用户界面设计

　　规定人机界面的内容、界面风格、调用方式等，包括所谓的表单设计、报表设计和用户需要的打印输出等设计。此部分内容可能比较多。

　　第六章 数据库系统设计

　　此数据库设计可单独成册，尤其对大型的数据库应用系统，即有一个单独的《数据库设计说明书》。

　　6.16.1 设计要求

　　6.26.2 信息模型设计

　　确定系统信息的类型(实体或视图)，确定系统信息实体的属性、关键字及实体之间的联系， 详细描述数据库和结构设计，数据元素及属性定义，数据关系模式，数据约束和限制。

　　6.3 数据库设计

　　6.3.1 设计依据

　　说明数据被访问的频度和流量，最大数据存储量，数据增长量，存储时间等数据库设计依据。

　　6.3.2 数据库种类及特点

　　说明系统内应用的数据库种类、各自的特点、数量及如何实现互联，数据如何传递。

　　6.3.3 数据库逻辑结构

　　说明数据库概念模式向逻辑模式转换所采用的方法论及工具，完成数据库概念模式向逻辑模式的转换。 详细列出所使用的数据结构中每个数据项、记录和文件的标识、定义、长度及它们之间的相互关系。此节内容为数据库设计的主要部分。

　　6.3.4 物理结构设计

　　列出所使用的数据结构中每个数据项的存储要求、访问方法、存取单位和存取物理关系等。建立系统程序员视图，包括： 数据在内存中的安排，包括对索引区、缓冲区的设计; 所使用的外存设备及外存空间的组织，包括索引区、数据块的组织与划分;访问数据的方式方法。

　　6.3.5 数据库安全

　　说明数据的共享方式，如何保证数据的安全性及保密性。

　　6.3.6 数据字典

　　编写详细的数据字典。 对数据库设计中涉及到的各种项目，如数据项、记录、系、文卷模式、子模式等一般要建立起数据字典，以说明它们的标识符、同义名及有关信息。

　　第七章 非功能性设计

　　第八章 环境配置

　　开发。测试、运行环境

简述GIS工程中的文档种类及作用

（1）总体设计说明书，包括系统目标、总体设计、数据设计、处理方式设计、运行设计等；
◆引言：编写的目的、背景、意义、参考资料
◆总体设计：需求规定、运行环境、基本设计概念和处理流程、软件结构
◆接口设计：用户接口、外部接口、内部接口
◆运行设计：运行模块组合、运行控制、运行时间
◆系统数据结构设计：逻辑结构设计、物理结构设计、数据结构与程序的关系
◆系统出错处理设计：出错信息、补救措施、系统恢复设计
（2）数据库设计说明书，包括所用数据库简介、数据模式设计、物理设计等。
（主要给出所使用的数据库管理系统DBMS简介，数据库的概念模型、逻辑设计和结果。）
（3）用户手册，对需求分析阶段编写的初步的用户手册进行审订；
（4）制定初步的测试计划，对测试的策略、方法和步骤提出明确的要求。

软件开发方案的软件开发方案

软件开发的标准过程包括六个阶段，而六个阶段需要编写的各类文件达14种之多，在每个阶段需要编写哪些文件，根据软件开发的标准流程制定软件开发方案： 可行性研究报告：在可行性研究与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资一收益分析、制订开发计划，并完成应编制的文件。
项目开发计划：编制项目开发计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度、所需经费预算、所需软、硬件条件等问题作出的安排记载下来，以便根据本计划开展和检查本项目的开发工作。 软件需求说明书：软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。内容包括对功能的规定对性能的规定等。
数据要求说明书：数据要求说明书的编制目的是为了向整个开发时期提供关于被处理数据的描述和数据采集要求的技术信息。
初步的用户手册：用户手册的编制是要使用非专门术语的语言，充分地描述该软件系统所具有的功能及基本的使用方法。使用户（或潜在用户）通过本手册能够了解该软件的用途，并且能够确定在什么情况下，如何使用它。 概要设计说明书：概要设计说明书又可称系统设计说明书，这里所说的系统是指程序系统。编制的目的是说明对程序系统的设计考虑，包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计。运行设计、数据结构设计和出错处理设计等，为程序的详细设计提供基础。
详细设计说明书：详细设计说明书又可称程序设计说明书。编制目的是说明一个软件系统各个层次中的每一个程序（每个模块或子程序）的设计考虑，如果一个软件系统比较简单，层次很少，本文件可以不单独编写，有关内容合并入概要设计说明书。
数据库设计说明书：数据库设计说明书的编制目的是对于设计中的数据库的所有标识、逻辑结构和物理结构作出具体的设计规定。
测试计划初稿：这里所说的测试，主要是指整个程序系统的组装测试和确认测试。本文件的编制是为了提供一个对该软件的测试计划，包括对每项测试活动的内容、进度安排、设计考虑、测试数据的整理方法及评价准则。 模块开发卷宗（开始编写）：模块开发卷宗是在模块开发过程中逐步编写出来的，每完成一个模块或一组密切相关的模块的复审时编写一份，应该把所有的模块开发卷宗汇集在一起。编写的目的是记录和汇总低层次开发的进度和结果，以便于对整个模块开发工作的管理和复审，并为将来的维护提供非常有用的技术信息。
用户手册完工
操作手册：操作手册的编制是为了向操作人员提供该软件每一个运行的具体过程和有关知识，包括操作方法的细节。
测试计划终稿 模块开发卷宗(此阶段内必须完成)
测试分析报告：测试分析报告的编写是为了把组装测试和确认测试的结果、发现及分析写成文件加以记载。
项目开发总结报告：项目开发总结报告的编制是为了总结本项目开发工作的经验，说明实际取得的开发结果以及对整个开发工作的各个方面的评价。 开发进度月报的编制目的是及时向有关管理部门汇报项目开发的进展和情况，以便及时发现和处理开发过程中出现的问题。一般地，开发进度月报是以项目组为单位每月编写的。如果被开发的软件系统规模比较大，整个工程项目被划分给若干个分项目组承担，开发进度月报将以分项目组为单位按月编写。
对于一项软件而言，有些文件的编写工作可能要在若干个阶段中延续进行。
鉴于软件开发是具有创造性的脑力劳动，也鉴于不同软件在规模上和复杂程度上差别极大，本指南认为在文件编制工作中应允许一定的灵活性，并不是14种文件每种都必须编写。

详细设计的说明书

1、引言
1.1、编写目的　说明编写这份详细设计说明书的目的，指出预期的读者。
1.2、背景说明：
a． 待开发软件系统的名称；
b． 本项目的任务提出者、开发者、用户和运行该程序系统的计算中心。
1.3、定义　列出本文件中用到专门术语的定义和外文首字母组词的原词组。
1.4、参考资料
列出有关的参考资料，如：
a． 本项目的经核准的计划任务书或合同、上级机关的批文；
b． 属于本项目的其他已发表的文件；
c． 本文件中各处引用到的文件资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。
2、程序系统的结构
用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）的名称、标识符和它们之间 的层次结构关系。
3、程序1（标识符）设计说明
从本章开始，逐个地给出各个层次中的每个程序的设计考虑。以下给出的提纲是针对一般情况的。对于一个具体的模块，尤其是层次比较低的模块或子程序，其很多条目的内容往往与它所隶属的上一层 模块的对应条目的内容相同，在这种情况下，只要简单地说明这一点即可。
3.1、程序描述
给出对该程序的简要描述，主要说明安排设计本程序的目的意义，并且，还要说明本程序的特点（如 是常驻内存还是非常驻？是否子程序？是可重入的还是不可重入的？有无覆盖要求？是顺序处理还是并发处理等）。
3.2、功能
说明该程序应具有的功能，可采用IPO图（即输入一处理一输出图）的形式。
3.3、性能
说明对该程序的全部性能要求，包括对精度、灵活性和时间特性的要求。
3.4、输入项
给出对每一个输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式。数量和频度、输入媒体、输入数据的来源和安全保密条件等等。
3.5、输出项
给出对每一个输出项的特性，包括名称、标识、数据的类型和格式，数据值的有效范围，输出的形式、数量和频度，输出媒体、对输出图形及符号的说明、安全保密条件等等。
3.6、算法
详细说明本程序所选用的算法，具体的计算公式和计算步骤。
3.7、流程逻辑
用图表（例如流程图、判定表等）辅以必要的说明来表示本程序的逻辑流程。
3.8、接口
用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序，说明参数赋值和调用方式，说明与本程序相直接关联的数据结构（数据库、数据文卷）。
3.9、存储分配
根据需要，说明本程序的存储分配。
3.10、注释设计
说明准备在本程序中安排的注释，如：
a． 加在模块首部的注释；
b． 加在各分枝点处的注释；
c． 对各变量的功能、范围、缺省条件等所加的注释；
d． 对使用的逻辑所加的注释等等。
3.11、限制条件
说明本程序运行中所受到的限制条件。
3.12、测试计划
说明对本程序进行单体测试的计划，包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。
3.13、尚未解决的问题
说明在本程序的设计中尚未解决而设计者认为在软件完成之前应解决的问题。
4、程序2（标识符）设计说明
用类似F．3的方式，说明第2个程序乃至第N个程序的设计考虑。