GBT 8567-2006 计算机软件文档编制规范

收藏

编号:20190728154037545166    类型:共享资源    大小:15.85MB    格式:PDF    上传时间:2019-07-28
  
5
积分
关 键 词:
GBT 8567-2006 计算机软件文档编制规范 8567 2006 计算机软件 文档 编制 规范
资源描述:
ICS 35.080 L77 哥国 中华人民共和国国家标准 GB/T 8567一2006 代替GB/T8567-1988 计算机软件文档编制规范 Specification for computer software documentation 2006-03-14发布 中华人民共和国国家质量监督检验检菇总局 中国国家标准化管理委员会 2006-07-01实施 发布 中华人民共和国 国家标准 计算机软件文档编制规范 GB/T 8567 2006 开 中国标准出版社出版发衍 北京复兴门外_里问I~街16号 邮政编码100045 网挝www.bzcbs.com 电话,6852394668517548 中国标础出版材秦皇岛印刷f印刷 各地新华书店经销 法 开本880X12301/16 印张8字数256千字 2006年9月第版2012年11}j第二次印刷 去 书号155066.1-27917寇价98.00元 如有印装差错由本社发行中心调换 版权专有侵权必究 举报电话,(010)68533533 飞 A / GBjT 8567一2006 目次 前言………………………………………………………………………………‘………………………E I 范围… 2 规范性引用文件- 3 术语和定义………… 4 缩略语· 5 文档过程…………………………………………………………1……………………………………6 5. 1 概述- 5.2 源材料准备……………………………………………………………………………………………7 5.3 文档计划………………………………………………………………….……………………….8 5.4 文档开发· 5. 5 评审……………………………………………………………………………………………………9 5. 6 与其他公司的文档开发子合同………………………………………………………………………10 6 文档编制要求……………………………………………………………………………………………10 6. 1 软件生存周期与各种文档的编制……………………………………………………………………10 6. 2 文档编制中的考虑因素…………………………………… .,. ••• '“ ••• ••• ••• ••• ••• ••• ••• ••• '“ ••• ••• 12 7 文档编制格式……………………………………………………………………………………………14 可行性分析(研究)报告(FAR)…………………………………………………………………… u 软件开发计划。DP) 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 7. 15 7. 16 7.17 7.18 7.19 7.20 7.21 7.22 软件测试计划(STP)…· 软件安装计划(SIP)…………………………………………………………………………………27 软件移交计划。TrP)………………………………………………………………………………30 运行概念说明(OCD) 系统/子系统需求规格说明(SSS)………………………………………………………………… 36 接口需求规格说明。RS)………………. . . . . .,. ••• ••• •••••• ••• ••• ••• •••••• ••• ••• ••• ••• 42 系统/子系统设计(结构设计)说明(SSDD)…………………………………………………………46 接口设计说明(IDD)………………………………………………………………………………51 软件需求规格说明(SRS)…………………………………………………………………………M 数据需求说明(DRD) 61 软件(结构)设计说明(SDD)………………………………………………………………………63 数据库(顶层)设计说明(DBDD)………… . . . .,. ••• '“ •••••• ••• ••• ••• •••••• ••• ••• ••• ••• 68 软件测试说明(STD).…………………………………………… 72 软件测试报告(STR)………………………………………………………………………………76 软件配置管理计划(SCMP)……………………………………………………………………… 78 软件质量保证计划。QAP)………………………………………………………………………的 开发进度月报(DPMR)……………………………………………………………………………“ 项目开发总结报告σDSR)…………'“. . . . '“ . . . , . . . . . . . . . . . , . 101 软件产品规格说明(SPS)…………………………………………………………………………106 软件版本说明(SVD)…………………………………………………………………………… 108 Gß/T 8567-2006 7.23 软件用户于册。UM)……………………………………………………………………………110 7.24 计算机操作手册(COM)…………………………………………………………………………113 7.25 计算机编程手册(CPM)………………………………………………………………………… 115 附录A(规范性附录)面向对象软件的文档编制……………………………………………………118 A. 1 综述…………………………………………………………………………………………………118 A.2 总体说明文档………………………………………………………………………………………118 A.3 用况图文档…………………………………………………………………………………………118 A.4 类图文档……………………………………………………………………………………………119 A.5 顺序图文档…………………………………………………………………………………………121 A.6 协作图文档…………………………………………………………………………………………121 A.7 状态图文档…………………………………………………………………………………………122 A.8 活动图文档…………………………………………………………………………………………123 A.9 构件图文档…………………………………………………………………………………………124 A. 10 部署图文档………………………………………………………………………………………124 A.11 包图文档…………………………………………………………………………………………125 参考文献………… . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 H GB/T 8567-2006 前言 本标准是GB/T8567-1988((计算机软件产品开发文件编制指南》的修订版,并改名为《计算机软 件文档编制规范》。本标准从实施之日起代替GB/T8567-1988。 本标准与GB/T8567-1988相比,主要变化如下: a) 本标准增加了文档编写过程。其内容参考了ISO/IECJTCl/SC7 N2106 1999/04/15((软件工 程用户文档过程》。 b) 本标准主要从软件开发与管理的角度,规定相应的文档及规范。其内容依据GB/T8566- 2001((软件生存周期过程》。 c) 在编写本标准时,综合了在软件开发与管理中的经验及中软网络技术股份有限公司有关 CMM中拟订的一些文档规范。 d) 本标准与S]20778-2000((软件开发与文档编制》很好地链接。 e) 本标准在规定软件需求规格说明、软件测试文件、软件质量保证计划与软件配置管理计划等文 档时,既依据相应的国标,又根据发展与实践经验作了相应的扩展。 f) 本标准把SJ/T11291-2003((面向对象的软件系统建模规范第3部分:文档编制》中的文档 编制规范作为本标准的规范性附录。 本标准的附录A是规范性附录。 本标准由中华人民共和国信息产业部提出。 本标准由信息产业部电子工业标准化研究所归口。 本标准起草单位:中软网络技术股份有限公司、信息产业部电子工业标准化研究所、北京联想软件 有限公司、用友软件股份有限公司。 本标准主要起草人:周明德、冯惠、韩乃平、欧阳春生、殷树勋、黄万锤、强学锋、韩振江、邓适宜。 mM GB/T 8567-2006 计算机软件文档编制规范 1 范围 本标准根据GB/T8566-2001((信息技术软件生存周期过程》的规定,主要对软件的开发过程和 管理过程应编制的主要文档及其编制的内容、格式规定了基本要求。 本标准原则上适用于所有类型的软件产品的开发过程和管理过程。 使用者可根据实际情况对本标准进行适当剪裁(可剪裁所需的文档类型,也可对规范的内容作适当 裁剪)。软件文档从使用的角度大致可分为软件的用户需要的用户文档和开发方在开发过程中使用的 内部文档(开发文档)两类。供方应提供的文档的类型和规模,由软件的需方和供方在合同中规定。 2 规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件,其随后所有 的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究 是否可使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准。 GB/T 8566-2001 信息技术软件生存周期过程CidtISO/IEC 12207: 1995) GB/T 11457-2006 软件工程术语 3 术语和定义 GB/T 11457-2006确立的以及下列术语和定义适用于本标准。 3. 1 验收acceptance 需方授权代表的一项活动,通过该活动,需方接受履行合同的部分或全部的软件产品的所有权。 3.2 需方acquirer 为自己或为另一个组织采购软件产品的组织。 3.3 批准approval 需方的授权代表或开发方的上级组织对开发方的项目计划、设计或其他方面表示满意并可以作为 F一阶段工作基础而签署的书面文件。 3.4 体系结构architecture 一个系统或CSCICComputerSoftware Configuration Item 计算机软件配置项)的组织结构,标 明它的组成,这些组成的接口和它们之间的操作概念。 3.5 相关开发方associate developer 一个既不是主承包方也不是开发方的分承包方的组织,但它在同一个或相关的系统或项目中承担 开发工作。 3.6 行为设计behavioral design 从用户观点出发,对整个系统或CSCI的行为进行的设计,它只考虑满足用户需求而不考虑系统或 GB/T 8567-2006 CSCI的内部实现。这种设计与体系结构设计不同,日者要标明系统或CSCI的内部部件,并有这些部 件的详细设计。 3. 7 构建版;开发阶段build (1) 软件的一个版本,它满足完整的软件所要满足的全部需求的一个特定的子集。 (2) 开发满足特定需求子集的软件版本所经历的时间。 注:术语“开发阶段“和“版本“之间的关系依赖于开发方:例如,可以通过几个版本来实现一个开发阶段,一个开发 阶段也可以友行几个并行的版本(如友往不同的地点).或者将它们用作为同义词. 3.8 3. 10 3. 11 3. 12 3.13 计算机数据库computer database 见3.14数据库。 计算机 能使 计算 见3. 计算 满足 配置项 能满足最终使 置管理。 3.14 数据库database 以一种能被用户或计算机程序通 机文件中的相关数据的集合。 3.15 数据库管理系统database management system 生控制输出的设 诸因素中 是一整套计算机程序,它提供为建立、修改、使用和完整性维护一个数据库所需的功能。 3. 16 可交付的软件产品deliverable software product 合同要求交付给需方或其他指定的接受方的软件产品。 3.17 i盘i十design 开发方为响应一定的需求而对一个系统或CSCI选取的一些性能/规格。这些特性中有些是与需 2 GB/T 8567一2006 求相匹配的:有一些是需求的精细化,如为了响应显示错误信息这-需求而定义所有的错误信息;有一 些则是与实现有关的,如为满足需求,决定选用哪些软件配置项和逻辑。 3. 18 开发方developer 开发软件产品的组织(“开发“包括新的软件开发、修改、重用、再工程、维护或产生软件产品的任何 其他活动)。开发方可以是一个承制方或者政府机构。 3. 19 文档/文档编制document/ documentation 能供人或机器阅读的,一般具有永久性的-套资料(不管它们记录在什么媒体上)。 3.20 评价evaluation 确定一个项或一个活动是否满足指定准则的过程。 3.21 固件firmware 硬件设备和以只读软件的形式驻留在硬件设备上的计算机指令和/或计算机数据的组合。 3.22 硬件配置项hardware configuration item(HWCI) 满足最终使用功能并由需方指定进行单独配置管理的一套硬件。 3.23 独立验证与确认independent verification and validation (IV 接口只是这些实体间的→种关系。 3.25 联合评审joint review 由需方和开发方双方的代表参加的对项目状态、软件产品和/或项目中的问题进行检查和讨论的活 动或会议。 3.26 非交付的软件产品Non-deliverable software product 不是合同中要求交付给需方或其他指定接受方的软件产品。 3.27 过程process 为实现某个既定目的而进行的一组有组织的活动,例如,软件开发过程。 3.28 合格性测试qualification testing 为了向需方表明一个CSCI或系统满足其指定的需求而进行的测试。 3.29 再工程reengineering 为了以一种新的形式重组一个现有的系统而对其进行检查和改造的过程。再工程可包括逆向工程 3 GB/T 8567-2006 (分析一个系统并产生更高一级的抽象来表示它,如从代码到设计)、重构(在同一个抽象级上把系统从 一种表示形式转换到另一种表示形式)、重编文挡(分析一个系统并产生用户文档式支持文档〉、正向工 程(从现有的系统的软件产品结合新的需求,产生新系统)、重定目标系统(对系统进行转换以便将其安 装到不同的目标系统上)和翻译(将源码从一种语言转换到另一种语言或者从一种语言的某个版本转换 成另一种版本〉。 3. 30 3. 31 需求requirement (1) 为了使需方能够接受一个系统或CSCI所必需具备的特性。 (2) 本标准或合同中规定的必须遵守的陈述。 可重用的软件产品reusab 为一个用途开发但还昌,驯的 件产品,重用库中 部分,也可以涉 软件本身。 3. 32 软件 计算a 产生 软件产品- 3. 34 3.35 软件开 与特定软 软件开发库 一组受控的软件、文也寻 续支持的工具和方法。 3. 36 软件开发过程software development process 为了把用户的需求转换成软件产品而进行的一系列有组织的活动。 3. 37 软件工程software engineering e何会产生 一般情况下,它是软件开发的同义词。在本标准中,软件工程是软件开发的一个子集,它包含除了 合格性测试之外的全部活动。本标准之所以加以这种区分只是为了给软件工程和软件测试环境以不同 的命名。 3.38 软件工程环境software engineering environment 实施软件工程所需要的设施、硬件、软件、固件、方法和文档。它可以包括(但不限于〉计算机辅助软 4 GB/T 8567-2006 件工程CCASE)的工具、编译程序、汇编程序、连接程序、装载程序、操作系统、排错程序、仿真程序、模拟 程序、文档工具和数据库管理系统。 3.39 软件产晶software product 为了满足一个合同而建立、修改或组合的软件及相关资料。例如包括计划、需求、设计、代码、数据 库、测试资料和手册。 3.40 软件质量software quality 软件满足所规定的需求的能力。 3.41 软件支持software support 为保证软件安装后能继续按既定目标持续运行而且在系统的运行中能起到既定的作用而实施的一 系列活动。软件支持包括软件维护、用户支持和有关的活动。 3.42 软件系统software system 只由软件组成的系统,有时可能还包括该软件赖以运行的计算机设备。 3.43 软件测试环境software test environment 为完成软件合格性测试和可能的其他测试所需的设施、硬件、软件、固件、方法和文档。其要素可以 包括(但不限于)仿真程序、代码分析程序、测试用例生成程序和路径分析程序,还可能包括在软件工程 环境下用到的要素。 3.44 软件移交software transition 使软件开发的责任从一个组织转交给另一个组织的一系列活动。一般说,前一个组织是实现初期 软件开发,而后一个组织是进行软件支持。 3.45 软件单元software unit CSCI设计中的一个基本单位:例如,CSCI的一个主要分支,该分支的一个组成部分、一个类、对象、 模块、函数、子程序或者数据库。软件配置项可以出现在层次结构的不同层上并可以由其他的软件配置 项组成。设计中的软件配置项与实现它们的代码和数据实体(例程、过程、数据库、数据文件等)及或包 含这些实体的计算机文件之间不一定有一一对应的关系。 4 缩略语 CASE CO岛f CP肌4 CSCI DBDD DID DPMR DRD FAR HWCI 计算机辅助软件工程CComputer Assistant Software Engineering) 计算机操作手册CComputerOperation ManuaD 计算机编程手册CComputer Programming Manual) 计算机软件配置项CComputerSoftware Configuration ltem) 数据库(顶层)设计说明CDatabaseDesign Description) 资料条日说明CDataItem Description) 开发进度月报CDevelopmentPlan Month Report) 数据需求说明CDatarequirement Description) 可行性分析报告CFeasibilityanalysis Report) 硬件配置项CHardware Configuration ltem) 5 GB/T 8567一2006 IDD IRS IV b) 若可用,软件的操作副本; 7 GB/T 8567-2006 c) 软件的分析员和程序员,以及及时和确切地解答由文档开发人员提出的问题; d) 若可能,访问典型的用户(为了做读者分析和可用性测试)。 为了增加对产品和它的读者的了解,对软件开发人员的访问是必要的但使这样的访问保持到最小 是文档管理者的责任。 不管文档管理者是否是软件的开发者,需方应提供适用的标准、风格和格式指南和其他相关的材 料。文档管理者应分发这些材料至需要它的文档开发人员。 保证需方交付给文档管理者的所有材料,当交付时,是完整的和正确的且在交付后保持是最新的, 这是需方的责任。 需方保证,提供的材料没有一个违反任何其他部门的知识产权。 文档管理者应采取所有有理由的步骤,以保证由需方提供的材料保持在很好的状态,应保证需方要 求的信息安全并在文档项目完成后,所有材料返回给需方。 注:在某些情况下,不是所有材料需要返回;这应在合同中定义。在某些情况下,由需方传送给文档管理者的材料 要求保持机密和安全。合同宜规定对于传送给文档管理者的材料,需方要求文档管理者的机密和安全等级。 5.3 文档计划 5.3.1 概要 文档管理者应准备一份文档计划,此计划规定在文档创建中要执行的工作。此文档计划应经需方 正式同意,以预示它完全覆盖了需方的要求。 注:文档计划通常将覆盖整个文档系列。 文档计划应正式地描述计划的文档的范围和限制,以及重要的文档分析和设计决定。也应规定在 文档开发期间实现的过程和控制。 8 文档计划应包括(但不限于)以下内容: a) 计划的文档的工作名称、目的、范围和限制z b) 文档的预定的读者,和使用的目的; c) 文档内容的草案表,带有估计的页数和其他媒体的等效细节; d) 交付:打印副本数,是否提供电子副本,磁盘和文件格式(包括软件版本)和在何处交付; e) 版权的拥有者和任何其他所有权; 注:这是复杂的问题,应在合同中规定。 f) 适当处,包括每个文档的安全或机密级; g) 管理文档开发过程的步骤和控制,包括存储、检索、后备、处理和质量保证(若要求); h) 所用的生产方法、工具和工具版本; i) 文档开发人员所在的队伍的结构,可包括队伍选择计划; 注:在文档编写和生产的不同阶段中的工作人员,需要不同的技巧。编写人员可能要求对正在编写的系统有好的 知识加上编写文档的经验;编辑人员可能要求有编辑经验而对系统知识元要求;版面艺术家可能对所用的版面 工具外,无任何知识要求。 j) 项目依赖; k) 所要求的人时和戚本; 1) 项目资源需求,包括需方提供的信息和其他资源; rr.) 在软件开发期间,软件变更传送信息给文档管理者的方法; n) 文档的变更控制和维护的计划(任选h 0) 实现后评审的计划(任选); p) 显示适当的里程碑的时间表,包括: 1) 文档计划批准; 2) 每个草案的准备、评审和改正; GB/T 8567-2006 3) 可用性测试; 4) 打印、装订和发布。 若适当,这些活动的每一个对于文档的每一项应重复。 注:文档计划宜在文档的开发开始以前准备与批准,以保证所有部门同意目标和所用的方法。批准后,计划宜尽可 能广泛地分发;分发宜包括所有文档开发人员和可能包括需方人员及子合同方。 5.3.2 文档计划控制 在正式批准后,文档管理者应控制文档计划和它的发布。文档管理者应保持一份文档计划副本的 分发的清单。若以后文档计划变更了(得到文档管理者和需方的同意),文档管理者应保证所有获得文 档计划副本的人员得到变更通知。 注:因为,过时的计划副本可能引起问题,文档管理者宜杜绝计划副本的失控,并制订计划的所有副本已经更新的审 核过程。 5.4 文档开发 按文档计划规定进行文档开发。通常,在进行文档开发前,要规定文档的格式(风格)。在软件的开 发和管理过程中需要那些文档,每种文档的规范在下面说明。 5.5 评审 5.5. 1 概述 本条规定文档评审的要求和相关活动。本条主要以用户文档的评审为例说明。对于开发文档的评 审,由供方组织和实施。而批准由开发组织的上级技术机构实施。更要着重经常性的、非正式的注重实 效的评审。 用户文档的评审应由需方实现,包括当需要时与文档管理者讨论。 注:评审的目的是保证提交的材料是完整的和正确的并满足了在合同和文裆计划中定义的需方的需要。 评审宜由合适的有资格的人员执行,这些人员被授权请求变更和批准文挡的内容。 注:需方宜限制评审人员数,满足评审功能所必需的那些即可。 需方在批准每个用户文档草案之前,应保证文档的安全和合法。 为评审交付的文档应包括从文档管理者来的说明书,说明评审的目的和评审员的职责。 注1:在需方和文档管理者之间在整个开发过程期间维持良好的沟通会提高文档的质量并利于评审成功。这宜包 括非正式的讨论和尽早地提供样板或初始材料给需方。 注2:在要求的变更超出了合同和文档计划的范围时,需要变更合同。 注3:评审过程不排除文挡管理者,他们的责任是试图尽可能保证文档的精确和完整。 注4:宜采用作为评审结果的需方的评论,或在草案上加上标记,或写有适当的参考的评论。需方宜保持变更的副 本为了与下一草案相比较。评论应使文档开发人员能实现所要求的变更而不需要评审人员的进一步解释。 注5:对于大的、复杂的系统或正在写文档时系统仍在开发,可能需要多于两次草案和一次校样。在这样情况下,最 多的草案数宜在需方和文档管理者之间同意并在文档计划中规定。 5.5.2 文档计划评审 此评审的日的应保证文档计划定义的文档,当完成时,既满足开发过程的需要也满足需方在合同中 规定的文档目标。需方同意文档计划,是同意在计划中定义的用户文档的所有可交付的特征。 注:需方宜把注意放在内容的草案表中展示的文档的结构、完整性和可用性。只要适当,文档计划宜在第一个草案 开始工作之前评审和批准。 5.5.3 第一个草案评审 第一个草案应包含如在文档计划中描述的文档主体,加上内容表、附录和词汇。在使用自动索引工 具处,生成的索引包含位置参照。标点符号、风格和版面应如在文档计划中描述的。 文档的第一个草案的评审目的是核查文档的技术正确性和完整性,以保证草案满足文档计划的目 标。标点符号、风格和版面应如在文档计划中定义的。 在批准第一个草案中,除了要求的变更外,要评审批准技术的正确性、结构清楚性和文档的完整性。 GB/T 8567-2006 注1第一个草案宜在交付前编辑。这有两个理由: a) 这保证评审者不分心于改正印刷的和版面的错误; b) 保证由编辑过程引起的任何技术错误被评审者捕获。 注2:草案应针对在文档计划中批准的目标、读者定义、内容表和其他特征进行评审。在带有评论的第一个草案返 回前,宜确认,若草案完全改正了,将满足文档计划的要求。 5. 5.4 第二个草案评审 第二个草案应包括在第一个草案评审中同意的所有变更,且应以尽可能接近最后的形式,包括在文 档计划中定义的可交付的内容。 此评审的目的是核查在第一个草案中的内容已经正确实现。 在第二个草案的批准中,除了草案的物理主:;tÔ7h ;ttt滥文档的所有方面。草案的物理形式可能与可 交付的不精确相同。 注:在批准第二个草案前, 5. 5. 5 校样评审 校样应包括在 a) b) c) d) 系统/子系 。软件(结构)设计E g) 接口设计说明; h) 数据库(顶层〉设计说明; (软件)用户手册; j) 操作手册; k) 测试计划; 1) 测试报告; m) 软件配置管理计划; n) 软件质量保证计划; 0) 开发进度月报; p) 项目开发总结报告; q) 软件产品规格说明; 软件版本说明等。 10 GB/T 8567一2006 本标准将给出这些文档的编制规范,同时,本标准也是这些文档的编写质量的检验准则。一般地 说,一个软件总是一个计算机系统(包括硬件、固件和软件)的组成部分。鉴于计算机系统的多样性,本 标准一般不涉及整个系统开发中的文档编制问题,本标准仅仅是软件开发过程中的文档编制指南。 对于面向对象的软件开发,其文档编制要求,参见附录A。 对于使用文档的人员而言,他们所关心的文件的种类随他们所承担的工作而异。 管理人员:可行性分析(研究)报告, 项目开发计划, 软件配置管理计划, 软件质量保证计划, 开发进度月报, 项目开发总结报告; 开发人员:可行性分析(研究)报告, 项目开发计划, 软件需求规格说明, 接口需求规格说明, 软件(结构)设计说明, 接口设计说明书, 数据库(顶层)设计说明, 测试计划, 测试报告; 维护人员:软件需求规格说明, 接口需求规格说明, 软件(结构)设计说明, 测试报告, 用户:软件产品规格说明, 软件版本说明, 用户手册, 操作手册。 本标准规定了在软件开发过程中文档编制的要求,这些文档从使用的角度可分为用户文档和开发 文档两大类。其中,用户文档必须交给用户。用户应该得到的文档的种类和规模由供应者与用户之间 签订的合同规定。 如前所述,软件,从出现一个构思之日起,经过软件开发成功投入使用,直到最后决定停止使用并被 另一项软件代替之时止,被认为是该软件的一个生存周期,一般地说这个软件生存周期可以分成以下6 个阶段: a) 可行性与计划研究阶段; b) 需求分析阶段; c) 设计阶段; d) 实现阶段; e) 测试阶段; f) 运行与维护阶段。 在可行性分析(研究)与计划阶段内,要确定该软件的开发目标和总的要求,要进行可行性分析、投 资收益分析、制订开发计划,并完成可行性分析报告、开发计划等文档。 在需求分析阶段内,由系统分析人员对被设计的系统进行系统分析,确定对该软件的各项功能、性 GB/T 8567-2006 能需求和设计约束,确定对文档编制的要求,作为本阶段工作的结果,一般地说软件需求规格说明(也称 为:软件需求说明、软件规格说明)、数据要求说明和初步的用户手册应该编写出来。 在设计阶段内,系统设计人员和程序设计人员应该在反复理解软件需求的基础上,提出多个设计, 分析每个设计能履行的功能并进行相互比较,最后确定一个设计,包括该软件的结构、模块(或CSCI)的 划分、功能的分配,以及处理流程。在被设计系统比较复杂的情况下,设计阶段应分解成概要设计阶段 和详细设计阶段两个步骤。在一般情况下,应完成的文档包括:结构设计说明、详细设计说明和测试计 划初稿。 在实现阶段内,要完成源程序的编码、编译(或汇编)和排错调试得到元语法错的程序清单,要开始 编写进度日报、周报和月报(是否要有日报或周报,取决于项目的重要性和规模),并且要完成用户手册、 制。 关引言、说明等同其他文““ 作告告报报二、 凸丁 析 发 分 开 试'HHJR 口 制颅院 E T Y 月 在运行和维护 充和删改、更新手啤级 编制中要 6.2. 3 灵活性 鉴于软件开发是具有创造性的脑力劳动,也鉴于不同软件在规模上和复杂程度上差别极大,在文档 编制工作中允许一定的灵活性。这种灵活性如下所述。 a) 应编制的文档种类 尽管本标准认为在一般情况下,一项软件的开发过程中,应产生如上所述的各种文档,然而针对一 项具体的软件开发项目,有时不必编制这么多的文挡,可以把几种文档合并成一种。一般地说,当项目 的规模、复杂性和失败风险增大时,文档编制的范围,管理手续和详细程度将随之增加,反之,则可适当 减少。为了恰当地掌握这种灵活性,本标准要求贯彻分工负责的原则,这意味着: 1) 一个软件开发单位的领导机构应该根据本单位经营承包的应用软件的专业领域和本单位的管 理能力,制定一个对文档编制要求的实施规定,主要是:在不同的条件下,应该形成哪些文档? 这些文挡的详细程度?该开发单位的每一个项目负责人,必须认真执行这个实施规定。 12 GB/T 8567一2006 2) 对于一个具体的应用软件项目,项目负责人应根据上述实施规定,确定一个文档编制计划(可 以包含在软件开发计划中),其中包括: (1) 应该编制哪几种文档,详细程度如何? (2) 各个文档的编制负责人和进度要求; (3) 审查、批准的负责人和时间进度安排; (4) 在开发时间内,各文档的维护、修改和管理的负责人,以及批准手续。 每项工作必须落实到人。这个文件编制计划是整个开发计划的重要组成部分。 3) 有关的设计人员则必须严格执行这个文档编制计划。 b) 文档的详细程度 从同一份提纲起草的文件的篇幅大小往往不同,可以少到几页,也可以长达几百页。对于这种差 别,本标准是允许的。此详细程度取决于任务的规模、复杂性和项目负责人对该软件的开发过程及运行 环境所需要的详细程度的判断。 c) 文档的扩展 当被开发系统的规模非常大〈例如源码超过一百万行〉时,一种文档可以分成几卷编写,可以按其中 每一个系统分别编制;也可以按内容划分成多卷,例如: 项目开发计划可能包括:质量保证计划, 配置管理计划, 用户培训计划, 安装实施计划; 系统设计说明可分写成:系统设计说明, 子系统设计说明; 程序设计说明可分写成:程序设计说明, 接口设计说明, 版本说明; 操作手册可分写成:操作手册, 安装实施过程; 测试计划可分写成:测试计划, 测试设计说明, 测试规程, 测试用例: 测试分析报告可分写成:综合测试报告, 验收测试报告; 项目开发总结报告亦可分写成项目开发总结报告和资源环境统计。 d) 章、条的扩张与缩并 在软件文档中,一般宜使用本标准提供的章、条标题。但所有的条都可以扩展,可以进一步细分,以 适应实际需要。反之如果章条中的有些细节并非必需,也可以根据实际情况缩井。此时章条的编号应 相应地变更。 e) 程序设计的表现形式 本标准对于程序的设计表现形式并未作出规定或限制,可以使用流程图的形式,判定表的形式,也 可以使用其他表现形式,如程序设计语言(PDL)、问题分析图(PALb)等。 f) 文档的表现形式 本标准对于文档的表现形式亦未作出规定或限制。可以使用自然语言,也可以使用形式化语言。 也可以使用各种图、表。 13 Gß/T 8567-2006 g) 文档的其他种类 当本标准中规定的文档种类尚不能满足某些应用部门的特殊需要时,他们可以建立一些特殊的文 档种类要求,例如软件质量保证计划、软件配置管理计划等,这些要求可以包含在本单位的文件编制实 施规定中。 7 文档编制格式 7. 1 可行性分析(研究)报告(FAR) 说明: 1. ((可行性分析(研究)报告))(FAR)是项目初期策划的结果,它分析了项目的要求、目标和环 境;提出了几种可供选择的方案;并从技术、经济和法律各方面进行了可行性分析。可作为 项目决策的依据。 2. FAR也可以作为项目建议书、投标书等文件的基础。 可行性分析报告的正文格式如下: 1 引言 本章分为以下几条。 1. 1 标识 本条应包含本文档适用的系统和软件的完整标识,(若适用)包括标识号、标题、缩略词语、版本 号和发行号。 1. 2 背景 说明项目在什么条件下提出,提出者的要求、目标、实现环境和限制条件。 1.3 项目概述 本条应简述本文档适用的项目和软件的用途,它应描述项目和软件的一般特性;概述项目开发、 运行和维护的历史;标识项目的投资方、需方、用户、开发方和支持机构;标识当前和计划的运行现 场;列出其他有关的文档。 1.4 文档概述 本条应概述本文档的用途和内容,并描述与其使用有关的保密性和私密性的要求。 2 引用文件 本章应列出本文档引用的所有文档的编号、标题、修订版本和日期,本章也应标识不能通过正常 的供货渠道获得的所有文档的来源。 3 可行性分析的前提 3.1 项目的要求 3.2 项目的目标 3.3 项目的环境、条件、假定和限制 3.4 进行可行性分析的方法 4 可选的方案 4. 1 原有方案的优缺点、局限性及存在的问题 4.2 可重用的系统,与要求之间的差距 14 4.3 可选择的系统方案1 4.4 可选择的系统方案2 4.5 选择最终方案的准则 5 所建议的系统 5. 1 对所建议的系统的说明 5.2 数据流程和处理流程 5.3 与原系统的比较(若有原系统) 5. 4 影晌(或要求) 5.4. 1 设备 5.4.2 软件 5.4.3 运行 5.4.4 开发 5.4.5 环境 5.4.6 经费 5.5 局限性 6 经济可行性(成本-效益分析) 6.1 投资 GB/T 8567-2006 包括基本建设投资(如开发环境、设备、软件和资料等),其他一次性和非→次性投资(如技术管 理费、培训费、管理费、人员工资、奖金和差旅费等)。 6.2 预期的经济效益 6.2.1 一次性收益 6.2.2 非一次性收益 6.2.3 不可定量的收益 6.2.4 收益/投资比 6.2.5 投资回收周期 6.3 市场预测 7 技术可行性(技术风险评价) 本公司现有资源(如人员、环境、设备和技术条件等)能否满足此工程和项目实施要求,若不满 足,应考虑补救措施(如需要分承包方参与、增加人员、投资和设备等),涉及经济问题应进行投资、戚 本和效益可行性分析,最后确定此工程和项目是否具备技术可行性。 8 法律可行性 系统开发可能导致的侵权、违法和责任。 9 用户使用可行性 用户单位的行政管理和工作
展开阅读全文
  赶蛙网所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
关于本文
本文标题:GBT 8567-2006 计算机软件文档编制规范
链接地址:http://www.gwye.com/p-136681.html

copyright@ 2018-2028 赶蛙网版权所有
 ICP备案编号:蜀ICP备19008733号-2

1
收起
展开