信息系统开发项目管理手册

信息系统开发项目管理指导书

1、项目建设总体目的

系统应当根据甲方顾客H勺既有业务需求及发展规划的扩延规定，

提供功能完善、界面友好、流程清晰、智能高效，配置维护以便日勺系

统功能，满足系统运行稳定、安全、可靠、高效等技术规定。提供电

脑版和版2个版本，

2、项目开发建设过程及规定

为了保证项目能按照甲乙双方到达的目的规定顺利开展，甲乙双

方应当联合成立项目组，由乙方编制《项目执行计划》（式样见附件

1）并有甲方确认同意.

2.1系统需求分析

1、开发商必须对甲方企业日勺业务需求进行深入调研，搜集汇总

客户的详细需求，出具《业务需求阐明书》（式样见附件2）,并保证

《业务需求阐明书》中包括了所有的业务需求°《业务需求阐明书》

经甲方企业（顾客）负责人签字确认，作为业务需求基线。

2、开发商在获得甲方签字确认U勺《业务需求阐明书》后，提出

技术需求和处理方案，并对系统进行定义，出具《系统需求规格阐明

书》（式样见附件3）。《系统需求规格阐明书》需详细列出业务对系

统的规定（界面、输入、输出、管理功能、安全需求、运作模式、关

键指标等）。《系统需求规格阐明书》需经甲方企业（顾客）负责人签

字确认。

3、当业务需求发生变更时，应由甲方企业提交《需求变更申请》

（式样见附件4）给乙方开发商实行。

2.2系统设计

为简化流程，本项目提议将概要设计和详细设计合二为一，统一

遵照完备性、一致性、扩展性、可靠性、安全性、可维护性等原则。

1、在该阶段确定总体构造和软件开发架构，文献命名规范，编

码规范。按软件需求划提成子系统，定义目的系统的功能模块及各个

功能模块的关系。

2、确定软件模块构造，给出每个功能模块日勺功能描述、数据接

口描述，各模块之间的详细接口信息、，并完毕《系统设计阐明书》（式

样见附件5）。

3、《系统设计阐明书》应当包括所有顾客界面的原型图。

4、完毕数据库的设计，并编写《数据库设计阐明书》。

5、在设计阶段，顾客应充足参与，保证设计能满足系统需求。

6、甲方应对组织对开发商提交日勺《系统设计阐明书》进行评审,

设计评审均以《业务需求阐明书》和《系统需求规格阐明书》为根据,

保证系统设计满足所有需求，并出具《系统设计评审汇报》（式样见

附件6）。

2.3系统开发

1、系统开发包括程序编码、单元测试和集成测试。开发商根据

《系统设计阐明书》制定系统开发计戈IJ,并提交给甲方对计划进行监

督。

2、开发商有条件的状况下尽量开发、测试和生产环境独立。选

择软件工具，明确项目组员的职责分工，按照编码规范和详细设计实

现软件功能。

3、代码应满足构造良好，清晰易读，且与设计一致，符合编码

规范。

4、开发人员需要软件实现过程中编写软件功能阐明，源代码阐

明。软件功能阐明文档应阐明项目名称、编号、软件名称和版本号，

软件功能、重要功能实现过程。源代码阐明应阐明项目编号、软件名

称、功能，全局变量、数据库字典、函数功能、接口。该文档包括在

源代码文献中，以注释形式存在。

5、开发商进行单元测试和集成测试。开发人员处理测试人员反

馈的测试问题，并以书面形式反馈重要问题及处理措施，直至系统运

行稳定。测试组出具《系统测试汇报》，测试人员签字确认测试成果。

2.4顾客测试

1、开发商编制《顾客测试计划》（式样见附件7）,测试计划必

须定义测试原则，并明确多种测试H勺测试环节和需要的系统设置规

定，并提交甲方准备。

2、甲方应当按照开发商测试组规定配合原则测试数据，测试用

数据要足够模拟使用环境中U勺实际数据。对已评估为敏感信息U勺数据

进行敏感性处理和保护。

3、按照测试计划完毕顾客测试后，测试组应当出具《顾客测试

汇报》（式样见附件8）,甲乙双方必须在顾客测试汇报中签字确认。

4、完毕测试后，开发商完毕系统协助文档（其中包括《顾客操

作手册》和《安装维护手册》）日勺编写。凡波及应用系统的变更，应

对系统协助文档及时更新。

2.5系统试运行

1、项目组必须制定《试运行计划》（式样见附件9）,并制定试

运行验收指标。《试运行计划》中应包括问题应对机制，明确问题沟

通渠道和职责分工。

2、项目组联合甲方企业进行有关系统布署工作，准备培训资料,

对有关顾客和信息技术人员进行培训。

3、项目组根据《试运行计戈D负责对顾客的破旧系统进行系统

转换和数据迁移。系统转换前，检查系统环境，保证运行环境能满足

新应用系统的需要。系统转换时必须详细记录原系统中时重要参数、

设置等系统信息，并填写试运行汇报有关内容。

4、系统转换和数据迁移完毕后，正式启动试运行。在试运行过

程中，项目组应把系统运行状况（系统资源使用，反应速度等）记录

到试运行汇报中。必要时，项目组应根据系统运行状况对应用系统进

行优化。

5、试运行到达试运行计划规定的终止条件时，开发商编写《试

运行汇报》（式样见附件10）。此汇报应由开发商和甲方单位签字确

认，试运行结束。

2.6系统验收与正式上线

1、系统验收重要顾客单位及开发商联合构成独立系统验收小组,

由验收小组共同约定验收日勺原则和措施。验收小组从功能需求及技术

需求层面对系统进行综合评估，系统验收内容包括但不限于移交给甲

方的系统测试汇报、系统安装文档、配置文档、源代码、操作手册、

维护手册、系统应急预案、系统“回退”计划等。

2、验收小组应根据验收状况整顿形成《系统验收汇报》（式样见

附件11）,验收汇报必须甲乙双方签字，并提交甲方作为付款根据。

3、系统验收合格且问题整改完毕并经甲乙双方重要领导同意后

系统转入正式上线运行。

3售后服务及保密规定

开发商应当保证系统技术支持人员队伍（、J稳定，明确售后服务内

容与责任，按照协议规定安排维护人员对系统进行技术支持。

系统需求变更或调整，记录变更原因和软件及源代码口勺版本控

制，按照软件变更规定对系统进行维护。

为了保护甲乙双方日勺商'也、技术秘密等权益，开发商与甲方、开

发商与其有关员工必须签订保密协议。

附件L项目执行计划

文献状态：文献标识：

[V]草稿目前版本：

[]正式公布作者：

[]正在修改完毕日期：

版本历史

版本/状态作者参与者起止日期备注

1文档简介

1.1文档目的

1.2文档范围

1.3参照文献

提醒：

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

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

例如：

［AAA］作者，《立项提议书》，机构名称，日期

1.5术语与缩写解释

缩写、术语解释

2项目简介

2.1项目范围

提醒：

（1）用简洁的语言阐明本项目“是什么”，“阐明用途”。

（2）阐明本项目“应当包括的内容”和''不包括的内容”。

2.2项目目的

提醒：给出“清晰的”、“可实现”、“可验证”的目的。

2.3客户与最终顾客简介

提醒：请阐明本项目H勺客户、顾客及其有关负责人是谁，描述最终顾客的特性。

2.4约束

提醒:

（1）请阐明在项目开发过程中应当遵照日勺原则或规范

（2）请阐明有关项目也许对本项目导致的影响。

（3）阐明某些假设和依赖。

3项目过程定义

3.1软件生命周期模型

提醒：简要描述、绘制本项目日勺软件生命周期模型。

3.2项目规范

提醒：描述项目需遵照的规范，例如：编码规范。此处可以体现为编码规范的链接。

3.3措施与工具

提醒：阐明在过程中将采用的措施与工具。例如采用RationalRose进行面向对象

分析与设计，采用VisualSourceSafe进行配置管理,采用MicrosoftOffice制作文

档。

措施与工具用途

VisualSourceSafe配置管理

•••

4里程碑计划

序号里程碑名称开始日期结束日期工作成果备注

5资源计划

5.1人力资源计划

提醒：制定本项目日勺角色职责表，并为已知的项目组员分派角色（一种人可以兼多

种角色）。

角色职责人员姓名工作阐明

高层领导

项目经理

需求分析员

系统设计员

程序员

测试员

♦••

5.2软硬件资源计划

提醒：分析项目开发、测试、运行所需的软硬件资源和关键计算机资源（会影响软

件产品的性能的CPU、内存、带宽等内容），重要内容包括：

•资源级别（分为“关键”、“一般”两种）

•详细配置

•获取方式（如“已经存在”、“可以借用”或“需要购置”等）与获取时间

•使用阐明（如“谁”在“什么”时候使用）

软硬件资源名级别详细配置获取方式与时间使用阐明

称

关键

关键

一般

•••

6文档交付列表

序号交付文档名称交付日期备注

7风险管理计划

提醒：如卜是各个列标题的解释。

约定在项目中的风险管理方案，例如：风险识别频度、风险跟踪频度等。

风险级别：确定风险时严重性、也许性、风险系数

风险描述：缓和方案或者应急计划。

风险级别

风险编号严重性也许性风险系数风隆描述缓和方案应急计划

(1-5)(%)(严重性*也许性)

8沟通计划

甲方代表乙方代表沟通方式沟通频率/时间期望成果

9附件

•项目进度计划

■进度表

提醒:制定项目开发的进度表(提议给出项目里程碑计划)。例如:

编号里程碑名称估计结束时间备注

需求调研完毕

项目计划完毕

需求分析完毕

系统设计完毕

.........

开发完毕

集成测试完毕

系统测试完毕

顾客验收测试完毕

试运行结束

项目验收

附件2：业务需求阐明书

文献状态：文献标识：

[V]草稿目前版本：

[]正式公布作者：

[]正在修改完毕日期：

版本历史

版本/状态作者参与者起止日期备注

1概述

1.1业务调研人员名单

【可选】

序号职能部门姓名主管联络备注

1.2业务范围

此处描写总体业务的概要分类。

1.3业务目的

从甲方高层或商务利益的角度提出本业务系统H勺期望目的，以及评价原则。

1.4有关文档

阐明：列出本文档的所有参照文献（可以是非正式出版物），包括既有规范、原则、批

文、引用到的文献、资料等，

1.5业务词汇表

阐明：列出本文档时所引用的专属领域词汇、术语等，以便于业务需求H勺提供者和接受

者是建立在一致的业务理解恭础之上的。

2组织构造及业务

2.1业务有关组织构造、人员组织构造

阐明：假如顾客岗位设置复杂可分别设置，业务组织构造和人员组织构造

2.2组织机构描述

2.3角色职责

阐明：将业务波及时详细人员进行一定程度的分类利抽象，描述该抽象角色的操作职货。

2.4管理综述

【可选】

阐明：重要描述该业务的管理特点和管理模式。例如：

2.5既有业务流程清单

【可选】

阐明：既有业务流程需要考虑，诸多新的业务是在已经有业务流程基础上进行重组时。

流程编号流程名称责任部门辅助部门

3业务流程及业务处理描述

阐明：针对每一项详细的目的业务，描述详细H勺业务流程，以及有关业务的详细描述。

3.1详细业务流程（系统名称+编号）

对于详细业务流程的命名有规范，对详细流程进行编号，便于形成需求矩阵，同步形成

需求的管理和跟踪。

3.1.1业务流程

3.1.2业务描述

阐明：描述详细的业务流程C

3.1.3有关业务对象

阐明：业务对象：业务流程中波及时单据、报表等。

业务对象使用部门对应电子档案编号

3.1.4业务规则及关键算法

阐明：描述业务环节关键算法体系。

4假定和约束

阐明：列出进行本软件开发工作的假定和约束，例如开发期限等。

4.1运行环境约束

4.2设计约束

【可选】

阐明：开发过程中必须使用内软件语言、软件进程需求、重要开发匚具、关键技术、第

三方产品等。

4.3产品应当遵照的原则或规范

【可选】

阐明：论述本产品应当遵照什么原则、规范或业务规则，违反原则、规范或业务规则H勺

产品一般不太也许被接受。

5其他

5.1目前关键问题和困难

5.2业务对项目实行的需求却期望

【可选】

5.3其他未尽事宜

附件3:系统需求规格阐明书

文献状态：文献标识：

[V]草稿目前版本：

[]正式公布作者：

[]正在修改完毕日期：

版本历史

版本/状态作者参与者起止日期备注

1引言

1.1目的

例如：规定系统H勺边界和目的，描述系统H勺功能性需求和非功能性需求。

1.2读者对象及阅读提议

阐明：指明本文档面向的读考群，及对应H勺阅读意见。

1.3文档范围

【可选】

阐明：对本文日勺范围做论述，本文档改动时，受到影响的范玉，例如，本文引用到的用

例模型，系统原型，系统测试用例等文档。

1.4参照文档

阐明：列出本文档的所有参照文献（可以是非正式出版物），包括计划任务书、协议、

批文、引用到的文献、资料及软件开发原则等。

1.5术语与缩写解释

阐明：列出本文献中用到的专门术语的定义和缩写词H勺原诃组，并予以解释，以便于所

有读者到达共识。

2综合描述

2.1系统背景

【可选】

阐明：简介系统的预期效果、历史原因。

2.2问题阐明

【可选】

提供一段阐明，总结此项目需要处理的问题。可以采用如下格式:

问题是［对问题进行阐明］

影响［问题影响的干系人］

问题日勺后果［该问题会导致什么后果］

成功的处理方案［应列出成功处理方案的某些重要长处］

2.3系统范围

阐明：论述本项目“合用的业务领域”和“不合用的业务领域”，本产品“应当包括的

内容”和“不包括的内容”。说清晰系统范围日勺好处是：（1）有助于判断什么是需求，

什么不是需求；（2）可以将开发精力集中在产品范围之内；（3）有助于控制需求的变更。

•完整而精确的定义本产品的干系人；

•明确本产品所影响到的部门和业务；

•用图表或者文字描述产品的范围，概要H勺定义产品的功能。

2.4干系人与顾客阐明

【可选】

2.4.1顾客环境

【可选】

详细阐明目的顾客的工作环境。如下是几项提议：

该任务由多少人来完毕？与否总在变化？

一种任务周期需要多长时间？执行每项活动要用多长时间？与否总在变化？

与否有特殊的环境约束：移动、户外、乘机旅行等？

目前使用H勺是哪些系统平台？后来会使用哪些平台？

还在使用哪些应用程序？您H勺应用程序与否需要和这些应用程序集成？

在此处可以从业务模型中摘录某些内容来概述所波及的任务和角色等等。

2.4.2干系人简档

【可选】

通过在下表中填写各干系人的有关信息来阐明系统中的各个干系人，详尽的简档应包括

多种干系人在如下方面的信息：

代表［谁是此产品的干系人代表？（如在他处已作记录，则此处为可选。）

此处只需填写姓名。］

阐明［对干系人类型的简要阐明。］

类型［简介干系人啊技能专长、技术背景和纯熟程度（即权威顾客、业务顾

客、专家顾客、初级顾客等）］

职责［列出干系人对所开发的系统负有的关键职责，即他们作为干系人的利

益。］

使用频率［该干系人使用系统的频率］

意见/问题［在此处列出会阻碍成功的问题以及任何其他有关信息。］

2.4.3关键的干系人/顾客需要

列出「系人认为既有处理方案存在的关键问题。对于列出的每个问题，需澄清如下要点:

­为何会出现这一问题？

•目前怎样处理该问题？

•干系人需要什么样日勺处理方案？

务必要理解干系人或顾客对处理各个问题H勺相对重视程度。分级和累积投票措施表明，

必须处理H勺问题与干系人或顾客但愿处理的问题大有不一样。

2.5目的业务模型

【可选】

阐明：新系统业务模型描述，如有对应业务模型材料了，可专为需求规格阐明书日勺输入

参照资料。

2.6功能摘要

总结该产品将提供依J重要长处和特性，而不必波及每个功能的细节。对功能加以组织，

使客户或初次阅读该文档H勺其他人可以理解此功能列表。

2.7功能清单及重要程度阐明

阐明：功能名称、功能描述、重要程度。

重要程度，以ABC三类来表达：A：关键功能；B：辅助功能；C：外围功能；

级别，按照继承关系分为：一级，二级，三级；

编号级别重要程度功能名称功能描述备注

2.8功能与业务对照关系表

阐明：业务组为主编写业务需求，业务需求提交至信息技术组后，由信息技术组建立目

的系统业务模型并与业务组进行确认（本操作可选，也可由信息技术组与开发商合作建

立），目的业务模型作为系统需求的输入，由信息技术组与开发商合作撰写和评审《系

统需求规格书明书》。

业务需求目口勺系统业务活动（可选）功能名称

2.9假定和约束

阐明：列出进行本软件开发工作的假定和约束，例如：开发语言、开发期限等。

格式限制阐明：本项将指定由既有的原则或规则派生的规定。例如：

报表格式：数据命名：财务处理；审计追踪，等等。

硬件限制阐明：本项包括在多种硬件约束卜运行的软件规定，例如，应当包括:

硬件配置的特点（接口数，指令系统等）；内存储器和辅助存储器H勺容量。

2.9.1运行环境约束

阐明：硬件设备，支持软件，接口，控制等方面的约束

名称详细规定

2.9.2设计约束

【可选】

阐明：开发过程中必须使用内软件语言、软件进程需求、重要开发工具、关键技术、第

三方产品等。

2.9.3产品应当遵照H勺原则或规范

阐明：论述本产品应当遵照什么原则、规范或业务规则，违反原则、规范或业务规则的

产品一般不太也许被接受。

3详细需求

3.1功能需求

3.1.1详细功能

3.1.1.1内容

阐明：对于每一类功能或者有时对于每一种功能，需要详细描述其输入、加工和输出的

需求。

3.2非功能需求

3.2.1外部接口

3.2.1.1顾客接口

阐明：提供顾客使用软件产品时的接口需求。例如，假如系统的顾客通过显示终端进行

操作，就必须指定如下规定：

a对屏幕格式日勺规定

阐明：对界面上的各对象、类型、宽度、取值范围、数据来源、能否为空等属性进

行描述。

b报表或菜单H勺页面打印格式和内容

c输入输出时需求

阐明：解释各输入输出数据类型，并逐项阐明其媒体、格式、数值范围、精度等。

对软件日勺数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝汇报

（正常成果输出、状态输出及异常输出）以及图形或显示汇报的描述。

d程序功能键口勺可用性

阐明：快捷键定义等。

3.2.1.2硬件接口

【可选】

阐明：要指出软件产品和系统硬部件之间每一种接口H勺逻辑特点。还也许包括如下事宜:

支撑什么样用J设备，怎样支撑这些设备，有何约定。

3.2.1.3软件接口

【可选】

阐明：在此要指定需使用的其他软件产品(例如，数据管理系统、操作系统或数学软件

包)，以及同其他应用系统之间的接口。对每一种所需的软件产品，要提供如下内容：

名字、助记符、规格阐明号、版本号、来源。

对于每一种接口，这部分应阐明与软件产品有关的接口软件为目的，并根据信息的内容

和格式定义接口，但不必详细描述任何已经有完整文献的接口，只要引用定义该接口的

文献即可。

【接口定义】

下表是对某些接口的详细描述：

接口名称

接口描述填写接口完毕的任务

接口类型填写是输入接口(inbound)还是输出接口(outbound)

源系统填写接口输入方系统或部件

目的系统填写接口输出方系统或部件

厂商提供/客户化开发

文献类型填写文献类型；若通过数据库表来交互，请指明数据库及

表名

文献数量

峰值数据量

频度填写数据处理的频度

复杂度

批处理/人工填写接口数据的驱动模式是人工(manual)还是自动

(automatic),还是都支持

接口类型填写是实时接口还是批量接口等

【其他系统详细信息】

阐明：列出所有与接口交互的外围系统的详细信息。包括输入、输出系统等

系统填写与接口交互的系统名称

系统类型填写是接口的数据源系统(source)还是目的系统(object)

数据库填写交互系统使用的数据库及版本

软件填写交互系统日勺软件名称

架构类型交互系统II勺架构类型是B/S还是C/S。

位置填写该软件在交互软件体系中所出的位置

技术支持填写交互系统的开发商和支持商

功能支持填写详细的1支持商或技术团体

数据归属

【接口从属系统的详细信息［可选］］

系统填写接口从属系统的名称

模块从属于详细的模块名称

数据库从属系统日勺数据库及版本

负责人

控制汇报

【接口配置】

(1)接口基础信息配置

阐明：接口基础信息日勺配置项n,描述配置的)方式。

(2)接口运行参数配置

阐明：接口运行参数口勺配置方式和环节。

【其他配置［可选］］

阐明：外围系统或有关模块日勺配置。

3.2.1.4通信接口

【可选】

阐明：指定多种通信接口。例如，局部网络的协议等等。

3.2.2其他非功能性需求

阐明：下表中的多种需求，可根据实际状况进行选择其中的一种或者几种进行描述，在

表的背面是多种需求的详细解释。

名称详细规定

静态数值需求

动态数值需求

精度

时间特性规定

可用性

可靠性

可维护性

安全性

可移植性

可扩展性

兼容性

3.2.2.1静态数值需求

阐明：支持的终端数；支持并行操作时顾客数。

3.2.2.2动态数值需求

阐明：欲处理的事务和任务向数量，以及在正常状况下和峰值工作条件下一定期间周期

中处理的数据总量。

3.2.2.3精度

阐明:对该软件的输入、输出数据精度的规定，也许包括传播过程中的精度。

3.2.2.4时间特性规定

阐明：对于该软件的时间特性规定，如对：

a.响应时间；

b.更新处理时间：

c.数据n勺转换和传送时间；

d.解题时间等规定。

3.2.2.5数据管理规定

【可选】

阐明：需要管理日勺文卷和记录日勺个数、表和文卷H勺大小规模，要按可预见的增长对数据

及其分量的存储规定做出估算。

3.2.2.6可用性

指出一般顾客和高级顾客要高效地执行特定操作所需的培训时间，指出经典任务的可评

测任务次数或根据顾客已知或喜欢的其他系统确定新系统的可用性需求

性能

3.2.2.7可靠性

指出可用时间比例（xx.xx%）、使用小时数、维护访问权、降级模式操作等。平均故障

间隔时间（MTBF）。平均修复时间（MTTR）一系统在发生故障后可以暂停运行口勺时间。指

出系统输出规定具有的精密度（辨别率）和精确度（按照某一已知H勺原则）。

3.2.3文档需求

阐明：重要是在线顾客手册与协助系统，也包括其他的文档

3.2.4第三方产品

【可选】

阐明：使用到日勺第三方产品芍关的使用许可、使用限制、接口原则。

3.3数据字典

阐明：把有关的数据抽取出来统一维护，在其他章节如有类似信息描述，则关联到数据

字典H勺有关部分并加辅助阐明，如：引用到的字段等。

4补充资料

【可选】

4.1待确定口勺问题列表

【可选】

需求标题1

调查方式

调查人

调查对象

时间、地点

需求信息记录

附件4：需求变更申请

记录号:

项目：类型：开发项目

项目负责人：变更申请人：

申请部门：申请日期：

变更内容

变更的内容阐明变更的内容及变更的理由,

及其理由假如变更为业务组提出,则业务组填写;

假如变更为为信息技术组提出,则信息技术组填写;

变更的系统及阐明变更所波及的工作产品及其目前版本,

版本假如变更为业务组提出,则业务组填写;

假如变更为为信息技术组提出,则信息技术组填写;

对业务及其接分析需求变更引起的业务变更、业务接口的变更,

口的影响业务组填写

甲方业务负责同意不一-样意

人意见：

签字：日期；

变更成果

变更分析

对有关的资源影响分析需求变更对人员、开发设备和目的设备的影响,

仅信息技术组填写

风险分析分析需求变更的风险,

仅信息技术组填写

对其他系统或接口分析需求变更引起的J系统变更、其他系统或接口的变更,

的影响仅信息技术组填写

对开发工作量、进估计需求变更对开发工作量和进度的影响,需阐明本次变更工作量/

度和成本影响成本与否超过本项目总开发工作量/总成本的1%?

仅信息技术组填写

开发商意见

开发商负贡人意同意不一样意

见：

指定验证人员：

签字：日期：

变更成果

变更H勺系统及版本阐明变更后的工作产品

签字：日期：

变更验证

完整性是否

对的性是否

验证变更成果

附加变更是否

版本和名称是否

甲方验证人意见：符合规定不符合规定

签字：日期：

附件5：系统设计阐明书

文献状态：文献标识：

[V]草稿目前版本：

[]正式公布作者：

[]正在修改完毕日期：

版本历史

版本/状态作者参与者起止日期备注

i引言

1.1编写日H勺

阐明编写这份详细设计阐明书口勺FI的，指出预期的读者。

1.2背景

阐明：

待开发软件系统口勺名称；

本项目的任务提出者、开发者、顾客和运行该程序系统的计算中心。

1.3定义

列出本文献中用到专门术语的定义和外文首字母组词的原词组。

1.4参照资料

列出有关I为参照资料，如：

本项目的经核准日勺计划任务书或协议、上级机关的批文;

属于本项目的其他已刊登的文献；

本文献中各处引用到的文献资料，包括所要用到的软件开发原则。列出这些文献n勺

标题、文献编号、刊登日期即出版单位，阐明可以获得这些文献।肉来源。

2程序系统的构造

用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）的名称、标

识符和它们之间的层次构造关系。

3程序1（标识符）设计阐明

从本章开始，逐一地给出各个层次中叫每个程序的设计考虑。如下给出的提纲是针

对一般状况的.对于一种详细的模块，尤其是层次比较低的模块或子程序，其诸多条目

的।内容往往与它所从属的上一层模块时对应条目日勺内容相似，在这种状况下，只要简

朴地阐明这一点即可。

3.1程序描述

给出对该程序的简要描述，重要阐明安排设计本程序的H的意义，并且，还要阐明

本程序的特点（如是常驻内存还是非常驻？与否子程序？是可重人的还是不可重人

日勺？有无覆盖规定？是次序处理还是并发处理等）。

3.2功能

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

3.3性能

阐明对该程序的所有性能规定，包括对精度、灵活性和时间特性的规定。

3.4输入项

给出对每一种输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效

范围、输入的方式。数量和频度、输入媒体、输入数据的来源和安全保密条件等等。

3.5输出项

给出对每一种输出项欧I特性，包括名称、标识、数据欢I类型和格式，数据值的有效

范围，榆出的形式、数量和频度，输出媒体、对输出图形及符号的J阐明、安仝保密条件

等等。

3.6算法

详细阐明本程序所选用的算法，详细的计算公式和计算环节。

3.7流程逻辑

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

3.8接口

用图的形式阐明本程序所从属的上一层模块及从属于本程序口勺下一层模块、子程

序，阐明参数赋值和调用方式，阐明与本程序相直接关联的数据构造（数据库、数据文

卷）。

3.9界面原型图

按照系统各功能模块的逻辑次序，提供界面原型图的跳转展示，各项人机互动组件

及数据显示必须基本完善，界面直观友好。

3.10存储分派

根据需要，阐明本程序的存储分派。

3.11注释设计

阐明准备在本程序中安排的注释，如:

加在模块首部的注释；

加在各分枝点处H勺注释：

对各变量的功能、范围、缺省条件等所加口勺注释；

对使用的逻辑所加的注释等等。

3.12限制条件

阐明本程序运行中所受到II勺限制条件。

3.13尚未处理的问题

阐明在本程序的设计中尚未处理而设口•者认为在软件完毕之前应处理的问题。

4程序2（标识符）设计阐明

用类似F.3的方式，阐明第2个程序乃至第N个程序II勺设计考虑。

附件6：系统设计评审汇报

文献状态：文献标识：ProjectName-

[V]草稿目前版本：X.Y

[]正式公布作者：

[]正在修改完毕日期：Year-Month-Day

版本历史

版本/状态作者参与者起止日期备注

1.基本信息

提醒:由评审主持人或评审员填写此表格。

待评审的工作成果工作成果名称，标识符，版本，作者，时间…

技术评审方式（正式评审）或者（走查）

评审时间

评审地点

参与技术评审的人员

类别名字工作单位职称、职务：

主持人

计申

/I、如

狙贝

记录员

2.缺陷识别和跟踪

评审问题跟踪表

编问题问题严重提交提交问题处理措施/问实问备

号描述类型性者日期处理原因阐明题际题注

负责处关关

人理闭闭

状日验

态*证

人

1

2

3

3.评审结论与意见

提醒:由主持人或评审员填写此表格。

[]工作成果合格，''无需修改”或者“需要轻微修改但不必再审核二

评审结论[V]工作成果基本合格，需要作少许的修改，之后通过审核即可。

[]工作成果不合格，需要作比较大H勺修改，之后必须重新对其评审。

意见

负责人签字：

签字日期：

附件7：顾客测试计划

文献状态：文献标识：

[V]草稿目前版本：

[]正式公布作者：

[]正在修改完毕日期：

版本历史

版本/状态作者参与者起止日期备注

1.测试范围与重要内容

提醒：系统测试小组应当根据项目日勺特性确定测试范围与内容。一般地，系统测试

的重要内容包括功能测试、强健性测试、性能测试、顾客界面测试、安全性(security)

测试、安装与反安装测试等,

2.测试措施

提醒：例如黑盒测试和白盒测试。

3.测试环境与测试辅助工具

环境

设备配置名称/类型备注

服务器软件

硬件

客户端软件

硬件

网络

工具

类型工具开发商版本

测试管理

缺陷跟踪

用于功能性测试的二具

用于性能测试的工具

测试覆盖监测器或评测器

4.测试进度计划

任务人员任务开始日期结束日期

制定测试计划

设计测试

实行测试

执行测试

对测试进行评估

5.测试完毕准则

提醒：

对于非严格系统可以采用“基于测试用例”的准则：

（1）功能性测试用例通过率到达100%;

（2）非功能性测试用例通过率到达95%时。

对于严格系统，应当补充“基于BUG密度”的规则：

相邻n个CPU小时内“测试期BLG密度”所有低于某个值mo例如n不小于10,m

不不小于等于1。

最终一次回归测试二类缺陷数量为零，用例外非常规缺陷数量不不小于等于2个/

万行程序：

测试用例功能点覆盖率100%；

6.BUG管理与改错计划

提醒：根据所采用口勺BIG管理工具确定：（1）BUG管理流程，（2）BUG修改流程。

定义BUG修改约定，例如：不一样级别的BUG必须在几日内处理完毕。

7.附录.本计划审批意见

测试组审批意见:

签字日期

附件8：顾客测试汇报

1.基本信息

测试根据例如：参照原则、客户需求、需求规格阐明书、测试用例等

测试范围

测试验收原则

测试环境描述

测试驱动程序描述提醒：可以把测试驱动程序当作附件

测试人员

测试时间

须注明每次回归测试

的时间

测试工具

2.实况记录

模块测试用例编号期望成果测试成果缺陷密度与否执行了回归测试

3.测试总评价

根据对测试成果提出一种有关软件能力的全面分析，需标明遗留的重要缺