[网站开发文档]如何写程序维护手册

每次总是绞尽脑汁，但是感觉写出来的维护手册效果不是很好。而往往一本好的程序维护手册对于程序将来的使用和维护都是很重要的。因为我们不能要求使用者或者是后来看此程序的人再花很多时间来研究这个程序，必须通过该程序的维护手册，让后续人员阅读以后能快速的掌握该程序的大体。 我现在提供一种比较通用的程序维护手册书写格式。希望能给大家带来方便。 ------------------------------------------------------------------------ 文档编号 版本号 密级 文档名称 XXXX程序维护手册 项目编号： 项目名称： 开发部门： 项目负责人： 编写 年月日 校对 年月日 审核 年月日 批准 年月日 程序维护手册 1引言 1．1 编写目的 [ 阐明编写维护手册的目的，简述其内容。指出读者对象（程序维护人员、研发人员）。] 1．2 开发单位 [说明项目的提出者、项目的委托单位、开发单位和使用场所。] 1．3 定义 [ 列出本文挡中用到的专业术语的定义和缩写词的原文。] 1．4 参考资料 [ 可包括：a.用户 *** 作手册；b.于本项目有关的文档。列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源以及保密级别。] 2 系统说明 2．1 系统用途 [ 说明系统具备的功能，输入和输出。] 2．2 安全保密 [ 说明系统安全保密方面的考虑。] 2．3 总体说明 [ 说明系统的总体功能、对子系统和作业作出综合性的介绍，并用图表方式给出系统主要部分的内部关系。] 2．4 程序说明 [ 说明系统中每一程序、分程序的细节和特性。] 2．4．1 程序1的说明 2．4．1．1 功能 [ 说明程序的功能。] 2．4．1．2 方法 [ 说明实现方法。] 2．4．1．3 输入 [ 说明程序的输入、媒体、运行数据记录、运行开始时使用的输入数据的类型和存放单元、与程序初始化有关的入口要求。] 2．4．1．4 处理 [ 处理特点和目的，如：a. 用图表说明程序的运行的逻辑流程b. 程序主要转移条件；c. 对程序的约束条件；d. 程序结束时的出口要求；e.与下一个程序的通信与联结（运行、控制）f. 由该程序产生并供处理使用的输出数据类型和存放单元。g.程序运行所用存储量、类型及存储位置等。] 2．4．1．5 输出 [ 程序的输出。] 2．4．1．6 接口 [ 本程序与本系统其他部分的接口。] 2．4．1．7 表格 [ 说明程序内部的各种表、项的细节和特性。对每张表的说明至少包括：a. 表的标识符；b. 使用目的；c. 使用此表的其他程序；d. 逻辑划分，如块或部，不包括表项；e. 表的基本结构；f. 设计安排，包括表的控制信息。表目结构细节、使用中的特有性质及各表项的标识、位置、用途、类型、编码表示。] 2．4．1．8 特有的运行性质 [ 说明在用户 *** 作手册中没有提到的运行性质。] 2．4．2 程序2 的说明 [ 与程序1 的说明相同。以后其他各程序的说明相同。] 3 *** 作环境 3．1 设备 [ 逐步说明系统的设备配置极其特性 ] 3．2 支持文件 [ 列出系统使用的支持软件、包括他们的名称和版本号。] 3．3 数据库 [ 说明每个数据库的性质和内容，包括安全考虑。] 3．3．1 总体特征 [ 如：a. 标识符 b. 使用这些数据库的程序；c. 静态数据；d. 动态数据；e. 数据库的存储媒体；f. 程序使用数据库的限制。] 3．3．2 结构及详细说明 3．3．2．1 说明该数据库的结构，包括其中的记录和项； 3．3．2．2 说明记录的组成，包括首部或或控制段、记录体； 3．3．2．3 说明每个记录结构的字段，包括：标记或标号、字段的字符长度和位数该字段的允许值范围。 3．3．2．4 扩充：说明为记录追加字段的规定； 4 维护过程 4．1 约定 [ 列出该软件系统设计中所使用全部规则和约定，包括：a. 程序、分程序、记录、字段和存储区的标识或标号助记符的使用规则；b. 图表的处理标准、卡片的连接顺序、语句和记号中使用的缩写、出现在图表中的符号名；c. 使用软件的技术标准；d. 标准化的数据元素极其特征。] 4．2 验证过程 [ 说明一个程序修改后，对其进行验证的要求和过程（包括测试程序和数据）及程序周期性验证的过程。] 4．3 出错及纠正方法 [ 列出出错状态及其纠正方法。] 4．4 专门维护过程 [ 说明文档其他地方没有提到的专门维护过程，如：a. 维护该软件系统的输入部分（如数据库）的要求、过程和验证方法；b. 运行程序库维护系统所必须的要求、过程和验证方法；c. 对闰年、世纪变更所需要的临时性修改等。] 4．5 专用维护程序 [ 列出维护软件系统使用的后备技术和专用程序（如文件恢复程序、淘汰过时文件的程序等）的目录，并加以说明，内容包括：a. 维护作业的输入输出要求；b. 输入的详细过程及硬件设备上建立、运行并完成维护作业的 *** 作步骤。] 4．6 程序清单和流程图 [ 引用资料或提供附录给出程序清单和流程图。] ------------------------------------------------------------------------- 希望对家有所帮助。谢谢你的阅读。

如何对外包的项目进行验收测试 随着当今技术和市场环境的变化，越来越多的企业选择将软件项目外包，同时也有更多成熟的大型软件企业加入到软件项目的承包队伍中。外包的软件项目越来越多，如何对这些外包的项目进行验收测试日益成为企业的一个关键问题。 用户验收测试的总体思路 用户验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划，进行软件配置评审、功能测试、性能测试等多方面检测。 用户验收测试可以分为两个大的部分：软件配置审核和可执行程序测试，其大致顺序可分为：文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、可执行程序测试。 要注意的是，在开发方将软件提交用户方进行验收测试之前，必须保证开发方本身已经对软件的各方面进行了足够的正式测试(当然，这里的“足够”，本身是很难准确定量的)。 用户在按照合同接收并清点开发方的提交物时(包括以前已经提交的)，要查看开发方提供的各种审核报告和测试报告内容是否齐全，再加上平时对开发方工作情况的了解，基本可以初步判断开发方是否已经进行了足够的正式测试。 用户验收测试的每一个相对独立的部分，都应该有目标(本步骤的目的)、启动标准(着手本步骤必须满足的条件)、活动(构成本步骤的具体活动)、完成标准(完成本步骤要满足的条件)和度量(应该收集的产品与过程数据)。在实际验收测试过程中，收集度量数据，不是一件容易的事情。 软件配置审核 对于一个外包的软件项目而言，软件承包方通常要提供如下相关的软件配置内容： . 可执行程序、源程序、配置脚本、测试程序或脚本。 . 主要的开发类文档：《需求分析说明书》、《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》、《测试计划》、《测试报告》、《程序维护手册》、《程序员开发手册》、《用户 *** 作手册》、《项目总结报告》。 . 主要的管理类文档：《项目计划书》、《质量控制计划》、《配置管理计划》、《用户培训计划》、《质量总结报告》、《评审报告》、《会议记录》、《开发进度月报》。 . 在开发类文档中，容易被忽视的文档有《程序维护手册》和《程序员开发手册》。 《程序维护手册》的主要内容包括：系统说明(包括程序说明)、 *** 作环境、维护过程、源代码清单等，编写目的是为将来的维护、修改和再次开发工作提供有用的技术信息。 《程序员开发手册》的主要内容包括：系统目标、开发环境使用说明、测试环境使用说明、编码规范及相应的流程等，实际上就是程序员的培训手册。 不同大小的项目，都必须具备上述的文档内容，只是可以根据实际情况进行重新组织。对上述的提交物，最好在合同中规定阶段提交的时机，以免发生纠纷。 通常，正式的审核过程分为5 个步骤：计划、预备会议(可选)、准备阶段、审核会议和问题追踪。预备会议是对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是最终确定工作产品中包含的错误和缺陷。 审核要达到的基本目标是：根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。 在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。 可执行程序的测试 在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成，就可以进行验收测试的最后一个步骤——可执行程序的测试，它包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量等五部分。 要注意的是不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。 在真正进行用户验收测试之前一般应该已经完成了以下工作(也可以根据实际情况有选择地采用或增加)： . 软件开发已经完成，并全部解决了已知的软件缺陷。 . 验收测试计划已经过评审并批准，并且置于文档控制之下。 . 对软件需求说明书的审查已经完成。 . 对概要设计、详细设计的审查已经完成。 . 对所有关键模块的代码审查已经完成。 . 对单元、集成、系统测试计划和报告的审查已经完成。 . 所有的测试脚本已完成，并至少执行过一次，且通过评审。 . 使用配置管理工具且代码置于配置控制之下。 . 软件问题处理流程已经就绪。 . 已经制定、评审并批准验收测试完成标准。 具体的测试内容通常可以包括：安装(升级)、启动与关机、功能测试(正例、重要算法、边界、时序、反例、错误处理)、性能测试(正常的负载、容量变化)、压力测试(临界的负载、容量变化)、配置测试、平台测试、安全性测试、恢复测试(在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行)、可靠性测试等。 性能测试和压力测试一般情况下是在一起进行，通常还需要辅助工具的支持。在进行性能测试和压力测试时，测试范围必须限定在那些使用频度高的和时间要求苛刻的软件功能子集中。由于开发方已经事先进行过性能测试和压力测试，因此可以直接使用开发方的辅助工具。也可以通过购买或自己开发来获得辅助工具。具体的测试方法可以参考相关的软件工程书籍。

Alpha测试和Beta测试都是由用户来进行测试，但是目的并不是项目或者产品的验收，而是属于系统测试的范畴，一般Alpha测试 也可认为是实验室测试由非专业人士参加，但是一般有专业的测试工程师配合指导，测试问题马上能的到反馈，定位准确，但是代价比较大，这种测试方法适合项目级应用； Beta测试则是开放型测试，使用于产品的测试，内部测试稳定后，发布Beta版本软件让公共用户测试，公司一般不能准确知道是哪些人使用了软件，并且他们发现的软件缺陷也不能准确有效的反馈给开发部门，需要将收集的信息经过整理得到有用的缺陷报告。这种测试方法得到的BUG数量不可预测，但是成本较低，一般只需做信息的收集整理工作！验收测试：仅限于做项目的公司，部门内部测试稳定后，根据合同中需求由发包商进行验收测试。如何对外包的项目进行验收测试 随着当今技术和市场环境的变化，越来越多的企业选择将软件项目外包，同时也有更多成熟的大型软件企业加入到软件项目的承包队伍中。外包的软件项目越来越多，如何对这些外包的项目进行验收测试日益成为企业的一个关键问题。 用户验收测试的总体思路 用户验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。需要根据事先制订的计划，进行软件配置评审、功能测试、性能测试等多方面检测。 用户验收测试可以分为两个大的部分：软件配置审核和可执行程序测试，其大致顺序可分为：文档审核、源代码审核、配置脚本审核、测试程序或脚本审核、可执行程序测试。 要注意的是，在开发方将软件提交用户方进行验收测试之前，必须保证开发方本身已经对软件的各方面进行了足够的正式测试(当然，这里的“足够”，本身是很难准确定量的)。 用户在按照合同接收并清点开发方的提交物时(包括以前已经提交的)，要查看开发方提供的各种审核报告和测试报告内容是否齐全，再加上平时对开发方工作情况的了解，基本可以初步判断开发方是否已经进行了足够的正式测试。 用户验收测试的每一个相对独立的部分，都应该有目标(本步骤的目的)、启动标准(着手本步骤必须满足的条件)、活动(构成本步骤的具体活动)、完成标准(完成本步骤要满足的条件)和度量(应该收集的产品与过程数据)。在实际验收测试过程中，收集度量数据，不是一件容易的事情。 软件配置审核 对于一个外包的软件项目而言，软件承包方通常要提供如下相关的软件配置内容： . 可执行程序、源程序、配置脚本、测试程序或脚本。 . 主要的开发类文档：《需求分析说明书》、《概要设计说明书》、《详细设计说明书》、《数据库设计说明书》、《测试计划》、《测试报告》、《程序维护手册》、《程序员开发手册》、《用户 *** 作手册》、《项目总结报告》。 . 主要的管理类文档：《项目计划书》、《质量控制计划》、《配置管理计划》、《用户培训计划》、《质量总结报告》、《评审报告》、《会议记录》、《开发进度月报》。 . 在开发类文档中，容易被忽视的文档有《程序维护手册》和《程序员开发手册》。 《程序维护手册》的主要内容包括：系统说明(包括程序说明)、 *** 作环境、维护过程、源代码清单等，编写目的是为将来的维护、修改和再次开发工作提供有用的技术信息。 《程序员开发手册》的主要内容包括：系统目标、开发环境使用说明、测试环境使用说明、编码规范及相应的流程等，实际上就是程序员的培训手册。 不同大小的项目，都必须具备上述的文档内容，只是可以根据实际情况进行重新组织。对上述的提交物，最好在合同中规定阶段提交的时机，以免发生纠纷。 通常，正式的审核过程分为5 个步骤：计划、预备会议(可选)、准备阶段、审核会议和问题追踪。预备会议是对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是最终确定工作产品中包含的错误和缺陷。 审核要达到的基本目标是：根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。 在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。 可执行程序的测试 在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成，就可以进行验收测试的最后一个步骤——可执行程序的测试，它包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量等五部分。 要注意的是不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。 在真正进行用户验收测试之前一般应该已经完成了以下工作(也可以根据实际情况有选择地采用或增加)： . 软件开发已经完成，并全部解决了已知的软件缺陷。 . 验收测试计划已经过评审并批准，并且置于文档控制之下。 . 对软件需求说明书的审查已经完成。 . 对概要设计、详细设计的审查已经完成。 . 对所有关键模块的代码审查已经完成。 . 对单元、集成、系统测试计划和报告的审查已经完成。 . 所有的测试脚本已完成，并至少执行过一次，且通过评审。 . 使用配置管理工具且代码置于配置控制之下。 . 软件问题处理流程已经就绪。 . 已经制定、评审并批准验收测试完成标准。 具体的测试内容通常可以包括：安装(升级)、启动与关机、功能测试(正例、重要算法、边界、时序、反例、错误处理)、性能测试(正常的负载、容量变化)、压力测试(临界的负载、容量变化)、配置测试、平台测试、安全性测试、恢复测试(在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行)、可靠性测试等。 性能测试和压力测试一般情况下是在一起进行，通常还需要辅助工具的支持。在进行性能测试和压力测试时，测试范围必须限定在那些使用频度高的和时间要求苛刻的软件功能子集中。由于开发方已经事先进行过性能测试和压力测试，因此可以直接使用开发方的辅助工具。也可以通过购买或自己开发来获得辅助工具。具体的测试方法可以参考相关的软件工程书籍。

---