项目测试验收方案469.pdf

《项目测试验收方案469.pdf》由会员分享，可在线阅读，更多相关《项目测试验收方案469.pdf（24页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、17.16 项目测试验收方案 17.16.1 验收流程 在验收阶段，平台系统所有应用系统将按照用户和我公司都认可的系统需求分析，组织验收小组，进行功能和性能的验收测试。从系统的实用性、稳定性、可维护性、灵活性、可操作性、和安全性及系统文档、代码、规范及注释说明等方面组织全面验收。验收测试安 排分为系统初验和系统终验。17.16.1.1 系统初验 经过系统内部试运行，我公司对内部试运行期间发现的问题改正后，提出系统初验书面 申请。验收标准将按照“需求说明书”和双方认可的有关系统设计文档所提的要求进行。用户在收到我公司验收申请后，尽快组织系统初验。初验前我公司提供全部的工程文档 和安装测试报告，并

2、提供初验测试文档，在用户认可后进行初验测试，初验通过后，系统进 入正式试运行期。我公司应解决试运行期间所反映出的问题，若系统达不到合同规定要求，试运行期将继续顺延，直到系统完善，但试运行期最长不得超过三个月。17.16.1.2 系统试运行 初验合格后，经用户同意，系统进入试运行阶段，试运行周期不超过三个月。在试运行 期间，我公司按用户要求提供培训和技术支持，保证用户能够正确理解和使用系统；我公司 对试运行中出现的任何问题及用户提出的修改意见将及时做出响应，并提交解决方案，在用 户确认后实施。试运行期间如出现重大故障，则试运行期从故障排除之日起重新计算。17.16.1.3 系统终验标准 正式试运

3、行期结束后，如系统无功能缺陷，能够正常运行，在具备终验条件下进行系统 终验，由我公司提出终验书面申请，用户在收到我公司验收申请后，尽快组织系统终验。成 立项目全面验收小组，由用户、我公司以及外部专家等组成，对项目进行全面验收。系统终 验前，我公司提交终验测试标准和终验测试计划，内容包括：测试对象及应达到的测试指标、测试方法和测试条件、测试资料和数据，并以图表说明每一测试对象或过程的功能输入输出 测试进度。17.16.1.4 系统终验内容 1)系统实用性：项目验收最关键的指标，检查系统是否符合当前业务的需要，特别是 业务流的整体性和数据流的一致性，并前瞻性提供未来业务接口。2)系统稳定性：硬件环

4、境的稳定性、软件运行异常处理和正常运行情况。3)系统可维护性：含网络系统管理与维护、服务器系统平台管理与维护、操作系统管 理与维护、应用系统软件管理与维护、数据库管理与维护以及数据库备份、应用系统备份，灾难事件处理与解决实施方案等。4)系统文档：验收文档是否齐全、规范、准确、详细，主要的文档包括：需求分析报 告，框架设计报告，数据库物理及逻辑设计报告，详细设计报告，编码规范及技术选型报告，测试报告，系统部署和发布报告，集成方案，软件用户使用手册，系统维护方案和操作文档 等。5)代码规范及注释说明：程序代码编写是否规范；注释说明或代码文档是否详细全面；接口定义是否符合局信息系统规划一致性的要求。

5、6）系统灵活性：系统是否方便客户进行维护；系统是否在先进性的基础上具备未来升 级和可扩充性；是否利于系统平台迁移和部署等。7）系统可操作性：界面是否友好性；是否实现傻瓜化操作和智能化数据检索功能。8）系统安全性：是否有完善的安全机制保证系统的安全性，如软件方面的安全防范（加 密措施、相关认证、数据库安全防范），硬件方面（防火墙、物理隔离和逻辑隔离）的安全 设置。9）其他验收标准：其他的与本系统相关的验收标准。17.16.1.5 系统终验过程 1）我公司按照项目验收计划完成验收准备工作 2）用户代表运行验收测试用例集，记录运行结果 3）如果发现没有通过的验收测试用例，则我公司立即解决问题 4）用

6、户主持项目验收会 5）我公司向用户报告项目实施结果 6）用户代表向用户报告试运行结果 7）用户评议项目实施和试运行结果，起草和审定项目验收报告。经中国疾病预防控制 中心精神卫生中心确认系统终验通过后，双方签署终验证书。17.16.1.6 终验技术文档资料 我公司在软件开发和系统集成中将严格按照国家软件工程有关要求提供的文档来提供,验收的技术文档至少包含以下内容:序 名称 内容 提交时间 号 1 系统需求分析 描述用户需求及分析结果（含用例 图,类图等）需求分析结束 2 系统概要设计 描述系统模型及系统体系架构等 初步设计内容 概要设计结束 3 系统详细设计说明术 描述系统各个子模块的接口和详

7、细设计流程 详细设计结束 4 应用程序设计说明书 描述系统各程序模块的接口和实 现流程 详细设计结束 5 数据库详细设计说明 书 描述数据库物理规划，数据表字 段，存储过程设计内容 详细设计结束 6 应用系统集成实施说 明 描述系统上线实施的详细过程和 步骤 开发过程中，部件 开发结束 7 系统测试大纲 描述系统测试的详细测试用例和 测试方法 组装测试结束 8 系统测试报告 描述系统测试的详细测试结果和 分析 系统测试结束 9 系统验收报告 描述软件综合评价，汇总所有软件 开发相关文档 系统验收完毕 10 系统用户使用手册 描述系统详细使用说明 应用集成结束 11 系统安装维护管理手 nn 册

8、 描述系统日常管理和维护的详细 内容 系统测试结束 17.16.1.7 终验报告 验收小组将在终验结束后提交一份由专家签名的验收报告。验收报告附平台系统和整体 系统测试结果报告，同时给出以下明确结论之一：（1）通过验收；（2）基本通过验收，要求在七天内完善后再次进行验收；（3）未通过验收，要求在十天内改正后再次进行验收；如再次验收后仍然不能全部通过，用户有权终止合同，并要求我公司承担违约责任。验收结束时，我公司将平台系统相关产品说明书、系统安装手册、技术文档、资料及安 装、测试、验收报告等文档汇集成册交付用户。17.16.2 测试方法 17.16.2.1 单元测试 单元测试目的 单元测试的对象

9、是软件设计中的最小单元模块。单元测试人员根据单元测试计划对已 完成的系统单元进行测试，确保已完成的系统单元符合相应部分系统详细设计说明书所规 定的要求。如果单元测试发现系统单元与其相应的详细设计说明书不符，则此系统单元必 须修改以最终符合说明书的规定。单元测试采用的方法、技术与内容 单元测试主要采用白盒测试技术，用控制流覆盖和数据流覆盖等测试方法设计测试用 例；主要测试内容包括单元功能测试、单元性能测试和异常处理测试等。单元测试流程 单元测试流程分为单元测试设计、单元测试准备、单元测试实施和记录、单元测试错 误跟踪。单元测试设计即单元测试用例设计，由系统设计人员在详细设计的同时完成。单元测试准

10、备为按照测试用例的要求，准备单元测试驱动数据和驱动模块，由开发人 员在开发过程中完成。单元测试实施和记录由开发人员在编码完成以后进行。单元测试问题跟踪由开发人员和系统设计人员共同完成，根据引起问题的不同原因进 行不同处理。如果测试问题为编码错误，则由开发人员完成纠错后重新测试。如果测试问 题为设计阶段引起的问题，则需要进行设计变更。通过单元测试的程序，进入配置管理系统。单元测试用例 编程组组长组织、指导开发人员根据 系统设计说明书 ，编写所负责代码设计模块的 单元测试用例，设计单元测试脚本。17.16.2.2 代码评审 编程组组长组织人员进行代码检查。若所写的代码不符合编码规范，即便已实现了系

11、 网络、数据库、应用服务器等以及测试 统功能，仍然认为不合格的，需要重写。代码检查的意义 保证代码编写的规范 保证代码编写的过程不产生 BUG 代码检查的依据 检查代码是否有更新 检查存在问题是否有更新 检查存在问题是否已解决 问题已解决，则填写代码检查记录 17.16.2.3 集成测试 集成测试目的 集成测试是指根据系统概要设计 及系统集成与开发详细设计，对系统的各单元 进行组装。把分离的系统单元组装为完整的可执行的计算机软件。集成测试的目的是检查 软件单元部件是否能够集成为一个整体，完成一定的功能，并找出单元测试中没有发现的 错误，包括数据定义有没有重合与冲突，接口会不会产生错误，组合以后

12、的模块功能会不 会互相影响，组合的系统是不是达到预期的效果等。集成测试采用的方法、技术和内容 集成测试采用白盒测试和黑盒测试相结合的测试技术和渐增式的测试策略，用数据流 等测试方法设计测试用例。主要测试内容包括单元之间的接口测试、全局数据结构测试 等。集成测试流程 集成测试包括集成测试设计、集成测试准备、集成测试实施和测试记录、集成测试问 题跟踪和结束测试等阶段。集成测试设计由测试组组长根据项目计划和开发计划编制 集成测试计划，设计 测 试用例。测试计划和测试用例应当通过项目经理的审查。集成测试准备需要系统测试组组长建立独立的测试环境。测试环境包括测试硬件环境、集成测试实施和测试记录是由系统测

13、试组组长组织人员按照测试计划和测试用例要求 进行测试，并且记录测试过程和测试结果。集成测试问题跟踪是在测试过程中发现的问题由系统测试组组长根据测试记录提交测 试问题报告，并由系统设计人员和开发人员解决每一个问题的过程。测试结束指测试问题报告中的问题解决后，进行回归测试。当测试问题降低到一定程 度并通过测试通过准则时，系统测试组组长提交测试总结报告结束测试。17.16.3 功能测试 功能测试包括两大部分，一是包括基本业务功能、业务测试、接口测试和可用性测试等 方面的功能测试，二是包括：安全性测试、故障恢复测试、数据库测试、配置测试、安装测 试的产品化测试。验收测试主要从系统的实用性、稳定性、可维

14、护性、灵活性、可操作性、和安全性方面进行测试。（1）测试目标 当国家重性精神疾病管理报表直报系统开发结束时，就要面临着推广使用的问题。在整 个的软件开发过程中，由于各种原因应用系统会有不完善的问题，这些问题会体现在开发后 发布的软件产品中，并在产品中极大的影响着产品的使用，对于用户，这些缺陷阻碍着完成 他们的既定目标和工作。所以我们要组织并执行测试，以降低软件产品中存在的缺陷，保证 产品的质量和可用性，测试工作的目标就是降低 BUG 率,从各个方面提高软件产品的质量和 可用性，为用户提供优质的国家重性精神疾病管理报表直报系统。计划进度表和测试计划对 业务系统测试进行了时间和内容上的定义与约束。

15、（2）测试流程 下图是功能测试的流程，概要描述了测试过程中所涉及的角色，测试阶段，以及各阶段 不同角色需要完成的任务。il.C iW 开览tL；r1 7每个测试用例的描 忖；苗|匕 业务测试流程 在准备测试用例这一活动中，我们所执行的具体任务如图所示，在确定具体的测试范围 及内容后，进行测试分类，并根据分类的结果确定需要设计的测试用例。机 准霽剑迢m冋 执h燕决 述如图中下半部分的描述。MCIHM T 胡 raw 呼目诙Propel HJ 顶目名辱PrejwtNi 开空an 叶眸血m WSffiffAPt Module ID L 卵应 MOduSr aw?Levels 号 Caw ID Til

16、l 口斛!1 連:叱Hi曲 m Fr 心 Tfl|SI毎 用阿讥 r*t CAM FecM 电 M Wttst a T*it 0M UTt 准备测试用例 测试用例是测试工作中重要的指导性文件。国家重性精神疾病管理报表直报系统的测试 用例主要是按照测试类型做划分，测试用例的输入为国家重性精神疾病管理报表直报系统 测试需求，测试需求的输入是系统需求规格说明书。在整个测试过程中，我们将用缺陷管理工具 BugBase 对测试大纲、测试用例、测试问题 等进行管理，并可对问题进行统计。（3）关键步骤 输入 项目开发计划 业务需求说明、系统需求规格说明 测试数据 关键步骤 定义测试需求与策略 开发测试脚本和

17、用例 准备测试环境 执行测试 输出 测试计划 测试用例、脚本 测试结果 关键成功因素 确定系统需求的可靠方法 认可了整体测试计划 测试脚本开发与执行有足够资源与时间 支持测试脚本开发与执行的工具，包括适当的配置环境 开发以业务过程驱动为基础的测试脚本 测试环境的可靠、及时（转换）的测试数据 所有业务系统和系统集成测试的全面执行 独立的质量保证测试和对所有测试活动的合格终止（4）测试完成标准 实现功能完全符合功能列表。所有的功能页面均可达。TD 上的问题得到妥善处理，不含有 A,B,C 类问题。定义的测试项目完成。产品化测试的约束达成。（5）缺陷管理追踪工具 在上节描述中提到的 TD,可以应用于

18、测试的全过程，也可以用于管理各类评审的缺陷 等。TD 还提供一些模板，例如测试计划、测试总结、测试大纲、测试问题卡，因此可以通 过 BugBase 实现从测试计划到总结的各测试活动管理。我们以需求说明书、软件需求规格说明为输入编写测试大纲，对应测试大纲中的内容和 测试需求编写测试用例，测试人员可以根据测试大纲和用例执行测试，发现问题后，记录在 TD 中，测试负责人通过查看缺陷问题列表将问题分配给对应的开发人员，开发人员通过查 看问题列表修改问题，TD 还提供了各种统计功能，例如根据问题的发现日期、问题等级、问题的分布、问题引入阶段等进行统计，这些统计结果可用来进行分析和总结 测试过程中使用 T

19、D 管理工具的益处在于：提高了测试的生产率 工具自动进行统计和分析 能够将问题卡输出到 Excel 文件中，便于与相关人员进行交流和确认。17.16.4性能测试 性能测试总体流程与业务系统测试的流程基本相同。验收测试主要从系统的实用性、稳 定性、可维护性、灵活性、可操作性、和安全性方面进行测试。性能测试的内容源于用户对 国家重性精神疾病管理报表直报系统的性能要求，此外就是针对国家重性精神疾病管理报表 直报系统业务多、范围广、层次多、用户量大的特点，对关键业务、关键流程进行性能测试。（1）测试目标 性能测试的目标是在整个系统或一个系统的特定组件上定义、建立和执行性能测试。验 证系统是否满足中国疾

20、病预防控制中心精神卫生中心的性能要求，如不能满足，要进行相应 的优化。（2）测试流程 根据国家重性精神疾病管理报表直报系统的性能要求，我们首先对性能测试进行策划，确定性能测试的类别和测试方法。然后开发性能测试的用例，确定测试环境并准备就绪后执 行性能测试，确定测试中的系统或组件的性能，并使用其结果决定性能是否可以被业务所接 受。如果在测试中度量的性能特性证明是不能被接受的，我们可以通过对业务的改进、数据 库、应用服务器等进行调优，以提高性能质量，在进行系统调优前，我们同样要进行调优的 设计与分析。性能测试与应用和技术架构紧密相关并且两者互相影响。性能测试类别与方法举例 测试类别 测试方法 大数

21、据量测试 导入大量数据到系统中，检查单用户操作时系统的性能表 现，对于较慢的操作进行分析、查找原因直到最后修改 多用户并发操作测试 用 loadrunner 模拟并发用户操作，通过 loadrunner 及 servertrace 等工具进行问题杳找和跟踪 不同带宽下的测试 用 loadrunner 模拟不同带宽进行测试 疲劳测试 用 loadrunner 模拟进行测试 （3）关键步骤 输入 性能需求 关键步骤 定义性能测试策略 设计性能测试脚本 准备测试环境和性能测试数据 性能测试执行 输出 性能测试脚本 性能测试报告 关键成功因素 性能测试的清晰的范围定义。性能测试限制的识别作为性能质量工

22、具和现实的专有技术可形性的风险评估，以定义和 解释性能测试。关于当前和未来业务量的质量信息的有效性，使能够定义测试模拟速度和容量。自动化测试工具的有效性和使用它们的技术，或用户提供人工测试事务处理的有效性。性能测试能够建立和运行的控制环境的有效性。（4）性能测试指标 1、响应时间 响应速度在用户心理所能承受的范围内。无论是客户端还是管理端，当用户登陆，进行 任何操作的时候，系统应该及时进行反映，系统应能检测出各种非正常情况，并及时提示用 户。功能名称 性能要求 并发数 支持 100 次/秒并发 页面加载 页面加载时间 5 秒 目录树加载 目录树加载时间 5 秒；数据列表加载 数据列表加载时间

23、5 秒；录入数据检查提醒 录入数据检查提醒时间 2 秒 数据查询 简单查询处理时间 5 秒；复杂查询处理时间15 秒；数据统计 简单统计处理时间 5 秒；复杂统计处理时间15 秒；数据上载/下载 1M 及以下文件上载/下载时间20 秒；10M 及以下文件上载/下载时间5 分钟；数据汇总 简单汇总处理时间30 秒钟；复杂汇总处理时间3 分钟；2、可扩展性 在设计上必须具有适应变化的能力，当系统新增业务功能或现有业务改变时，应保证业 务在整体框架不变的基础上，业务变化造成的影响局部化。3、易用性 所有的业务功能界面风格和操作流程一致，业务表单做到所见即所得，录入能够完全通 过键盘完成。4、可靠性

24、系统应保证 7*24 小时内不宕机，保证在正常情况下和极端情况下业务逻辑的正确性。5、可用性 必须避免由于单点故障或系统升级而影响整个系统的正常运行。6、可维护性 系统能够简单方便的修改和升级，包含可度性、可修改性、可测试性等。7、可管理性和服务支持能力 每个层次、每个构件都提供标准的管理接口。实现统一的、一致的日志功能。每个构件 都提供应用架构总体设计规定的必要的标准外部接口。我们通过 Loadruner 等性能测试工具可以得到资源使用状况、响应时间等结果，见下图:a&wact.OCZDO DDlQS 00:10 an 15 QIS aQ3D DO：亞 OT：4O 00：45 I1O：5D

25、Mffi Dfl：E|01：05 IJ1：IIO 01:15 D1：2D 01:25 QI：50 01:55 E aped 百匚enario timp mms Wimhjws：U3DD 口 D D O 秒间时应响 88604廿26 51*初 网络带宽+登录界面 登录 PT 展开组织结构 自定义查询 T计算和发放 生成报表 资源使用情况（示例）单点用户响应时间基准数据曲线图 响应时间（示例）17.16.5用户测试 为保证系统适合业务管理的功能要求，除了我公司组织测试外，还积极配合中国疾病预 防控制中心精神卫生中心组织最终用户对系统进行测试。（1）用户测试流程 用户测试流程如下：明确测试内容，其中

26、包括功能、性能、可用性、安全性、兼容性、与其他系统集成 确定测试范围：确定业务情况类型是是非常重要的。每一种业务情况类型都对应一 个实际商业业务。业务情况类型可以被表达成多种状况（例如，简单情况、或需要进 行复杂处理的例外情况）。测试小组成员确定：由管理人员、业务人员、技术人员等组成，我方提供验收测试 过程中的技术支持。明确问题分类标准 系统的功能通过功能测试进行验证。在功能测试过程中发现的问题根据其严重程度 进行分类。下表列出了功能测试问题的分类。功能测试问题严重程度分类 严重程度 问题说明 严重程度 问题说明 A 类：非常严 重性错误 足以造成系统崩溃，造成文件不可靠或潜在的数据丢失 造成

27、非正常地返回操作系统（系统崩溃或显示系统错误信息）。Bug 造成程序越或要求 Reboot 系统。造成缺乏关键的程序功能并无法逾越。B 类：严重性 错误 由于设计问题，使系统存在严重隐患。Bug 可能不会削弱系统，但将造成严重问题（如：严重的格式化错误等）。功能缺乏给用户带来极大不方便。存在不明确或不完整的错误信息提示，极大地影响产品使用。由于 Bug 的存在使产品其它部分不能测试。由于计算方法问题，使数据错误。由于设计原因，造成前后不一致，但问题可恢复。容错性方面存在不足。由于精度问题造成数据不一致。C 类：一般性 错误 这个 Bug 在将来是严重的，但比主要问题（Major Problem

28、）要轻。Bug 可以绕过，但将会很不方便或很难实现。可以有一个比较简单的绕过 Bug 的解决方案。操作界面错误（包括数据窗口内列名定义、含义是否一致）。打印内容、格式错误。简单的输入限制未放在前台进行控制。删除操作未给出提示。数据库表中有过多的空字段。存在不明确或不完整的错误信息提示，但对产品使用影响较小。将相应的 严重程度 问题说明 D 类：轻微和 建议性错误 界面不规范。辅助说明描述不清楚。输入输出不规范。长操作未给用户提示。提示窗口文字未采用行业术语。可输入区域和只读区域没有明显的区分标志。对系统运行没有影响，提出可以使系统从可移植性、兼容性、错误恢复能力 和可维护性、易用性方面的意见

29、明确功能测试标准 功能测试标准 测试标准 测试成果 验收标准 将测试结果与测试计划和功能描述进行对照 检查，确定系统满足功能描述的要求 新系统可执行程序 功能描述 接口描述 操作手册 不存在 B 及以上级别 的问题（2）用户测试设计 设计测试用例：确定每个功能的测试用例，明确系统输入信息和期望的输出结果。针对 需求规格说明书的每一条测试内容，确定测试用例。每个测试用例包括测试条件（包括生成 测试条件需要的测试数据类型）和期望的结果。每个测试用例都应该是唯一确定的（例如，赋一个数值）。设计测试大纲：依据测试范围生成测试大纲。对每一种业务情况类型，生成尽可能多的 测试用例来完善测试大纲。为了保证测

30、试大纲包含所有的测试用例，将测试用例的条件映射 为测试大纲是非常必要的。测试大纲中测试用例的顺序安排是非常重要的，它应考虑多种方 面的因素，主要考虑的因素是按照系统产生的数据，在测试大纲中安排测试用例的顺序，使 得一个测试的结果作为另一个测试前提。测试环境准备：为了预防出现问题，如数据损坏或对系统资源的争用，需要建立一个独 立的测试环境。在进行测试之前，根据测试计划中确定的时机建立一个独立的测试环境。准备工作包括：技术活动：如建立不同的服务器或在一台服务器上建立多个数据库实例，程序迁移到适 当的程序库中；准备活动：包括加载数据表，建立用户访问权限；建立版本控制程序，保证有效的控制对系统的修改；

31、建立文档控制程序，保证随着系统的修改，有效地控制文档的修改（如，培训文档、联机帮助和用户手册）。3）用户测试结果 测试结束后，测试小组根据测试数据，制定并向验收工作领导小组提交 用户测试 报告。测试报告结果说明软件满足下列要求：在认可的外部设计文档中表述的功能要求 在认可的系统描述文档中表述的非功能要求 此外，测试报告中还包括对系统提出的改进意见。测试过程中产生的工作成果：测试计划 测试方案 测试需求分析 功能测试用例 业务测试案例 测试报告 各阶段评审 系统测试方案 系统测试案例 系统测试报告 试运行测试报告 工作周报月报 评审文档相关 缺陷数据和分析 系统设计方案(包括概要 技术文档和信息

32、予以保 密。我公司严格遵守与用户签订的保密协议，未经用户书面许可，绝不以任何形式向第三方 17.17 文档管理方案 17.17.1 文档管理承诺 针对本项目提供详细科学的文档管理方案。项目文档是项目执行的重要指标，完善的文档管理可以规范项目执行人员的进度和任务，可以为用户和用户间搭建沟通的桥梁，可以为工作的进展铺设阶梯，还可以为系统的升级和 维护提供依据。我公司郑重承诺：1)我公司在系统初验前向用户提交完整的技术文档，内容与所开发的系统相一致，并 尽可能详细。所提交的技术文档为正式版本。2)我公司提供所开发系统的各项技术指标的测试报告、第三方软件产品的用户使用授 权书。3)我公司提供技术文件包

33、括但不限于系统需求规格说明书、设计和详细设计)、系统用户手册、系统维护手册等。4)我公司提供详细验收文档等。5)我公司对本项目的所有技术文件以及用户提供的内部资料、透露本标书以及本项目的任何内容。一旦因我公司的原因造成泄密，我公司承担相应责任。17.17.2 文档管理依据 所有技术文档内容满足：GB8567计算机软件产品开发文件编制指南 GB/TI1457-89 软件工程术语 软件工程文档管理办法 国家档案管理标准汇编 国家二级档案管理标准 国家重点项目档案管理办法(档发安【1997】15 号)国家档案局关于印发科学技术研究档案管理暂行规定 中华人民共和国环境保护行业标准环境保护档案管理数据采

34、集规范 的要求。提供的文档和资料均应以纸张和光盘为载体，文件格式为 Word 文档或其他可 视化、未加密的文件。涉及图纸规格和质量符合 ISO 标准的 A4 标准格式。17.17.3文档管理工具 在本项目中，利用 Visual SourceSafe 进行项目文档管理，系统(软件)项目开发进程中 将提交的文档进行收集管理。通常，文档管理在项目开发中不是很受重视，当发现其重要性 时，往往为时已晚。整个项目可能因此变得管理混乱，问题产生后无据可查。文档管理对于 一个项目的顺利进行有着至关重要的作用，其关键性不容忽视。项目文档管理涉及范围广泛，其内容会根据项目的不同而有所变化。首先要了解在本项目中文档

35、管理要遵循的行业标准。目前软件系统开发提供了通用的管 理规定和行业标准，它涉及文档管理的整个生命周期。细分文档的生命周期，一般包括：创 建、审批、发布、修改、分发、签收、追缴、归档、废止与恢复这样几个环节。就目前软件项目的开发情况来看，电子文档使用较纸质文档更为方便、灵活、广泛。对 于电子文档，我们管理其整个生命周期。VSS(Visual Source Safe)作为一种电子文档管理 工具给我们提供了完整的文档管理功能，它覆盖了文档管理全生命周期各环节的管理要求。VSS 通过客户端/服务器(C/S)架构收集整个项目组成员的各类文档，通过管理员合理规划管 理，将电子文档按目录保存并同时提供给整个

36、项目组的不同成员使用。17.17.4文档分类 我公司承诺在整个项目的执行过程中，为方便用户的维护和管理，并且为今后系统升级 和维护提供可靠的依据，向用户提供如下几类文档：项目管理文档 项目管理方案 进度实施计划 质量管理计划 项目实施方案 项目进度报告 需求变更文件 系统应用设计文档 系统需求分析 系统需求规格说明书 系统集成与开发详细设计 系统详细设计方案 应用程序设计说明书 数据库详细设计说明书 系统测试类文档 系统测试大纲 使用类文档 系统操作手册 用户手册 系统验收类文档 设备到货验收报告 系统验收计划 系统初验报告 系统试运行报告 总体验收报告 系统培训类文档 培训计划 培训教材 培

37、训过程纪录 培训考核纪录 系统安全性文档 安全操作手册 突发事件处理与灾难恢复计划 17.17.5文档清单 向用户提交两套纸质文档及两套电子文档，提交给用户的文档清单如下:项目管理方案 进度实施计划 质量管理计划 项目进度报告 需求变更文件 系统需求规格说明书 系统详细设计说明书 数据库详细设计说明书 系统验收计划 培训计划 培训教材 培训过程纪录 系统操作手册 突发事件处理与灾难恢复计划 会议记录 变更记录 系统维护手册 方案变更记录 系统测试报告 系统初验报告 系统试运行记录 系统试运行报告 整改记录 系统终验报告 顾客满意度调查表 技术服务文档 系统升级记录 系统巡检记录 资料及变更、补

38、 故障维修报告 系统源代码 同时提交给用户的文档还包括项目实际执行中产生的清单外其他文档、充文件、备忘录、承诺函等。17.17.6 文档管理要求 一致性：系统初验前向用户提交完整详细的技术文档，内容与所开发的系统一致。提交的技 术文档为正式版本，纸质文档与电子文档的内容一致。保密性：对本项目的所有技术文件以及中国疾病预防控制中心精神卫生中心提供的内部资料、技术文档和信息予以保密。我公司遵守与中国疾病预防控制中心精神卫生中心签订的保密协议，未经中国疾病预防控制中心精神卫生中心书面许可，不得以任何形式向第三方透露本标书以及本 项目的任何内容。知识产权：由开发本系统而形成的产品知识产权归中国疾病预防控制中心精神卫生中心所有，完成开发集成任务后，所有相关文件与源程序代码等完整移交给中国疾病预防控制中心精神卫生 中心。17.17.7 文档质量标准 完备性：提供系统进展各环节的文档，包括阶段性鉴定文档和日常工作文档，保证提供的文 档是齐全的。正确性：提供的文档真实反映各阶段工作，与该阶段需求是一致的。简明性：文档语言力求清晰、准确、简练。规范性：文档的格式具有统一的标准规范，术语的含义以及图示符号等都符合行业相关规定。