计算机软件文档编制规范课件

《计算机软件文档编制规范课件》由会员分享，可在线阅读，更多相关《计算机软件文档编制规范课件（244页珍藏版）》请在金锄头文库上搜索。

1、冯惠,GB/T 8567-2006计算机软件文档编制规范,目次,1修订背景 修订依据 新老版本的差异 新版标准结构 文档编制过程 文档编制要求 文档编制格式 小结,一、本标准修订的背景,版是参考英国某公司的文档标准，结合当时国内软件开发的经验，而且主要是针对瀑布模型的开发方法而制定的。该标准的发布与实施对我国上世纪八十年代、九十年代的软件开发发挥了重要作用。但随着时间的推移，软件工程技术的发展与提高，目前来看，版已经不适应软件产业发展的需要，因此修订版势在必行。,二、GB/T8567-2006制定的依据,主要依据： 信息技术软件生存周期过程 软件开发与文档编制 ：信息技术软件用户文档过程,三、

2、新老版本的主要差异,主要适用于瀑布模型开发方法 给出了种文档的编制格式要求： ）可行性研究报告 ）项目开发计划 ）软件需求说明书,新老版本的主要差异,）数据要求说明书 ）概要设计说明书 ）详细设计说明书 ）数据库设计说明书 ）用户手册 ）操作手册 ）模块开发卷宗 ）测试计划 ）测试分析报告 ）开发进度月报 ）项目开发总结报告,新老版本的主要差异,6原则上适用于各种类型的开发方法 6描述了文档编制过程 6给出种文档的编制格式要求 ）可行性分析（研究）报告 ）软件开发计划 ）软件测试计划 ）软件安装计划,新老版本的主要差异,）软件移交计划 ）运行概念说明 ）系统子系统需求规格说明 ）接口需求规格说

3、明 ）系统子系统设计（结构设计）说明 ）接口设计说明 ）软件需求规格说明 ）数据需求说明 ）软件（结构）设计说明,新老版本的主要差异,）数据库（顶层）设计说明 ）软件测试说明 ）软件测试报告 ）软件配置管理计划 ）软件质量保证计划 ）开发进度月报 ）项目开发总结报告,新老版本的主要差异,）软件产品规格说明 ）软件版本说明 ）软件用户手册 ）计算机操作手册 ）计算机编程手册 另外给出了面向对象的种文档的编制格式要求,四、6标准结构,、范围 、规范性引用文件 、术语和定义 、缩略语 、文档（编制）过程 、文档编制要求 、文档编制格式 附录面向对象软件的文档编制,五、文档（编制）过程5.1 概述,有

4、两种主要类型的标准： a. 产品标准，它规定产品的特征和功能需求； b. 过程标准，它规定开发产品的过程。 应用程序和计算机软件的复杂性日益增加，使得给使用计算机的用户提供完整的、正确的和易懂的文档的需要更加迫切。本标准通过规定影响软件文档的质量的活动（做什么和由谁做），提供达到这些目的的工具。,文档常常是关心在软件已经实现后做些什么。然而，为了质量，软件文档编制应作为整个软件生产过程的一部分。过程计划应把文档计划包括在内。本标准也给用户和客户提供工具以保证文档过程实施。 本标准的主要活动之一是建立开发文档的广泛计划。这是必须的，因为有计划，文档编制的质量会更好，过程的效率会更高。为遵循本标准

5、，计划必须包括风格规格说明。本标准不规定风格规格说明的内容（即不规定具体的布局和字体），但它规定风格规格说明必须覆盖什么。本标准也规定何种信息对于文档管理者是可用的和谁做评审和再生产文档。,5.2 文档（编制）过程的关注点,文档编制计划 文档开发（编制） 文档评审,5.3 文档计划,5.3.1 概要 文档管理者应准备一文档计划，此计划规定在文档创建中要执行的工作。此文档计划应经需方正式同意，以预示它完全覆盖了需方的要求。 l文档计划通常将覆盖整个文档系列。 文档计划应正式地描述计划的文档的范围和限制，以及重要的文档分析和设计决定。也应规定在文档开发期间实现的过程和控制。,文档计划应包括（但不限

6、于）以下内容： a）计划的文档的工作名称、目的、范围和限制。 b）文档的预定的读者，和使用的目的。 c）文档内容的草案表，带有估计的页数和其他媒体的等效细节。 d）交付：打印副本数，是否提供电子副本，磁盘和文件格式（包括软件版本）和在何处交付。 e）版权的拥有者和任何其他所有权。 l这是复杂的问题，应在合同中规定。,f）适当处，包括每个文档的安全或机密级。 g）管理文档开发过程的步骤和控制，包括存储、检索、后备、处理和质量保证（若要求）。 h）所用的生产方法、工具和工具版本。 i）文档开发人员所在的队伍的结构，任选地，包括队伍选择计划。 l在文档编写和生产的不同阶段中的工作人员，需要不同的技巧

7、。编写人员可能要求对正在编写的系统有好的知识加上写文档的经验；编辑人员可能要求有编辑经验而对系统知识无要求；版面艺术家可能对所用的版面工具外，无任何知识要求。,j）项目依赖。 k）所要求的人时和成本。 l）项目资源需求，包括需方提供的信息和其他资源。 m）在软件开发期间，软件变更传送信息给文档管理者的方法。 n）文档的变更控制和维护的计划（任选）。 o）实现后评审的计划（任选）。,p）显示适当的里程碑的时间表，包括： 1）文档计划批准； 对于文档的每一项应重复。 l文档计划宜2）每个草案的准备、评审和改正； 3）可用性测试； 4）打印、装订和发布。 若适当，这些活动的每一个在文档的开发开始以前

8、准备与批准，以保证所有部门同意目标和所用的方法。批准后，计划宜尽可能广泛地分发；分发宜包括所有文档开发人员和可能包括需方人员及子合同方。,5.3.2 文档计划控制 在正式同意后，文档管理者应控制文档计划和它的发布。文档管理者应保持一份文档计划副本的分发的清单。若以后文档计划变更了（得到文档管理者和需方的同意），文档管理者应保证所有得到文档计划副本的人员，应得到变更通知。 l 因为，计划的过时的副本可能引起问题，文档管理者宜禁止计划的未控制的副本并制订计划的所有副本已经更新的审核过程。,5.4 文档开发,按文档计划规定进行文档开发。通常，在进行文档开发前，要规定文档的格式（风格）。在软件的开发和

9、管理过程中需要那些文档，每种文档的规范在下面说明。,5.5 评审,5.5.1 概述 本节规定文档评审的要求和相关活动。本节主要以用户文档的评审为例说明。对于开发文档的评审，由供方组织和实施。而批准由开发组织的上级技术机构实施。更要着重经常性的、非正式的注重实效的评审。不是要追求形式。,用户文档的评审应由需方实现，包括当需要时与文档管理者讨论。 l评审的目的是保证提交的材料是完整的和正确的并满足了在合同和文档计划中定义的需方的需要。 评审宜由合适的有资格的人员执行，这些人员被授权请求变更和批准文档的内容。 l需方宜限止评审人员数为评审功能所必需的那些。 需方在批准每个用户文档草案之前，应保证文档

10、的安全和合法。 为评审交付的文档应包括从文档管理者来的说明书，说明评审的目的和评审员的职责。,l 注1：在需方和文档管理者之间在整个开发过程期间维持良好的通信会提高文档的质量并利于评审成功。这宜包括非正式的讨论和尽早地提供样板或初始材料给需方。 l注2：在要求的变更超出了合同和文档计划的范围时，需要变更合同。 l注3：评审过程不免除文档管理者，他们的责任是试图尽可能保证文档的精确和完整。 l注4：从评审的结果而来的需方的评论结果宜用或是加上标记的草案或用有适当的参考的方式写评论。需方宜保持变更的副本为了与下一草案相比较。评论应使文档开发人员能实现所要求的变更而不需要评审人员的进一步解释。 l注

11、5：对于大的、复杂的系统或正在写文档时系统仍在开发，可能需要多于两次草案和一次校样。在这样情况下，最多的草案数宜在需方和文档管理者之间同意并在文档计划中规定。,5.5.2 文档计划评审 此评审的目的应保证文档计划定义的文档，当完成时，既满足开发过程的需要也满足需方在合同中规定的的文档目标。需方同意文档计划，是同意在计划中定义的用户文档的所有可交付的特征。 l注：需方宜放注意至在内容的草案表中展示的文档的结构、完整性和可用性。只要适当，文档计划宜在第一个草案开始工作之前评审和批准。,5.5.3 第一个草案评审 第一个草案应包含如在文档计划中描述的文档主体，加上内容表，附录和词汇。在使用自动索引工

12、具处，生成的索引包含位置参照。标点符号、风格和版面应如在文档计划中描述的。 文档的第一个草案的评审目的是核查文档的技术正确性和完整性，以保证草案满足文档计划的目标。标点符号、风格和版面应如在文档计划中定义的。,在批准第一个草案中，除了要求的变更外，评审批准技术正确性、结构清楚性和文档的完整性。 l 注1：第一个草案宜在交付前编辑。这有两个理由： a）这保证评审者不分心于改正印刷的和版面的错误； b）保证由编辑过程引起的任何技术错误被评审者捕获。 l注2：草案应针对在文档计划中批准的目标、读者定义、内容表和其他特征进行评审。在带有评论的第一个草案返回前，宜确认，若草案完全改正了，将满足文档计划的

13、要求。,5.5.4 第二个草案评审 第二个草案应包在第一个草案评审中同意的所有变更且应以尽可能接近最后的形式包括在文档计划中定义的可交付的内容。 此评审的目的是核查在第一个草案中的内容已经正确实现。 在第二个草案的批准中，除了草案的物理形式外，批准文档的所有方面。草案的物理形式可能与可交付的不精确相同。 l注：在批准第二个草案前，宜确认草案（包含评审对草案的评论）已经准备好批准。,六、文档编制要求,6.1 软件生存周期与各种文档的编制,在计算机软件的生存周期中，一般地说，应该产生以下一些基本文档。 可行性分析（研究）报告； 软件（或项目）开发计划； 软件需求规格说明； 接口需求规格说明； 系统

14、子系统设计（结构设计）说明； 软件（结构）设计说明；,接口设计说明； 数据库（顶层）设计说明； （软件）用户手册； 操作手册； 测试计划； 测试报告；,软件配置管理计划； 软件质量保证计划； 开发进度月报； 项目开发总结报告； 软件产品规格说明； 软件版本说明等。,本标准将给出这些文档的编制规范，同时，本标准也是这些文档的编写质量的检验准则。一般地说，一个软件总是一个计算机系统（包括硬件，固件和软件）的组成部分。鉴于计算机系统的多样性，本标准一般不涉及整个系统开发中的文档编制问题，本标准仅仅是软件开发过程中的文档编制指南。 对于使用文档的人员而言他们所关心的文件的种类随他们所承担的工作而异。,

15、管理人员： 可行性分析（研究）报告， 项目开发计划， 软件配置管理计划， 软件质量保证计划， 开发进度月报， 项目开发总结报告；,开发人员： 可行性分析（研究）报告， 项目开发计划， 软件需求规格说明， 接口需求规格说明， 软件（结构）设计说明， 接口设计说明书， 数据库（顶层）设计说明， 测试计划， 测试报告；,维护人员： 软件需求规格说明， 接口需求规格说明， 软件（结构）设计说明， 测试报告，,用 户： 软件产品规格说明， 软件版本说明， 用户手册， 操作手册。 本标准规定了在软件开发过程中文档编制的要求，这些文档从使用的角度可分为用户文档和开发文档两大类。其中，用户文档必须交给用户。用

16、户应该得到的文档的种类和规模由供应者与用户之间签订的合同规定。,如前所述，软件，从出现一个构思之日起，经过软件开发成功投入使用，直到最后决定停止使用并被另一项软件代替之时止，被认为是该软件的一个生存周期，一般地说这个软件生存周期可以分成以下六个阶段：,可行性与计划研究阶段； 需求分析阶段； 设计阶段； 实现阶段； 测试阶段； 运行与维护阶段。,在可行性分析（研究）与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资一收益分析、制订开发计划，并完成应编制的文档。 在需求分析阶段内，由系统分析人员对被设计的系统进行系统分析，确定对该软件的各项功能、性能需求和设计约束，确定对文档编制的要求，作为本阶段工作的结果，一般地说软件需求规格说明（也称为：软件需求说明、软件规格说明）、数据要求说明和初步的用户手册应该编写出来。,在设计阶段内，系统设计人员和程序设计人员应该在反复理解软件需求的基础上，提出多个设计，分析每个设计能履行的功能