《国家标准》文件给制实施规定的实例(GB8567-88)
文件给制实施规定的实例（GB8567-88）
尽管在文件编制中存在着很多灵活性，然而，文件的编制确实是非常必要的，其意义如前所述。
为了控制这种灵活性，保证文件编制能达到应该达到的目的，对于具体的软件开发任务，应编制的文件的种类、详细程度应取决于承担开发单位的管理能力、任务的规模、复杂性和成败风险等因素。
一个软件开发单位应该根据本单位经营承包的应用软件的专业特点和本单位的管理能力，制定一个文件编制实施规定，说明在什么情况下应该编制哪些文件。
由于国内目前在这方面还缺乏成熟的经验，这里提供参考国外经验制定的两个例子，用以向国内软件开发单位说明如何建立这种实施规定，使项目负责人能确定本项目开发过程中应编制的文件的种类。
当然，例子毕竟只是例子，这两个例子各自都不免有其片面性，它们两者之间也不免有不一致之处，之所以列出来无非是供国内软件开发单位参考。
例1：
此例规定用求和法来确定应编制的文件。
该方法的要点是提出十二个考虑因素来衡量一个应用软，件，每个因素可能取值的范围是互至5。
任务负责人可用这十二个因素对所要开发的程序进行衡量，确定每个因素的具体值。
把这十二个因素的值相加，得到一个总和。
然后由这个总和的值来确定
应该编制的文件的种类。
使用这个方法的具体过程如下：
a.按表OI中的十二个因素衡量所要开发的程序，得到每
个因素的值；
b.把衡量所得的各个因素的值相加，得总和之值；
c.根据总和之值，从表OZ查出应编制的文件的种类。
表1文件编制的十二项衡量因素
表1文件编制的十二项衡量因素
*在因素总和较低的情况下,项目开发总结报告的内容应包括：程序的主要功能、基本流程、测试结果和使用说明。
**测试分析报告应该写，但不必很正规。
***数据要求说明和数据库设计说明是否需要编写应根据所开发软件的实际需要来决定。
例2：
为了避免在软件开发中文件编制的不足或过分，一个简便的办法是把对软件文件的编制要求同软件的规模大小联系起来，这就是本例的出发点。
软件的规模不妨分为四级：
1.小规模软件源程序行数小于5000的软件；
2. 中规模软件源程序行数为10000～50000的软件；
3. 大规模软件源程序行数为100000—500000的软件；
4. 特大规模软件源程序行数大于500000的软件。
对上述的四级软件的文件编制要求分别列于表3。
至于源程序行数为5000～10000，50000～100000的软件，其文件编制要求介于两级之间，可根据一个软件产品的具体情况，由项目负责人参照表3的规定，确定需要编制的文件种类。
对于源程序行数大于500000的特大规模软件，可进一步把本指南规定的十四种文件按实际需要扩展成更多种类，这一点在本指南5.3.3已经提到。
表3产品文件体系
对应大规模软件
所规定的文件可进一步细分
测试分析报告
小规模软件 中规模软件
大规模软件 超大规模软件。
GB-T 8567-1988-12：测试分析报告
此处插入公司LOGO目录1.引言 (4)1.1.编写目的 (4)1.2.背景 (4)1.3.定义 (4)1.4.参考资料 (4)2.测试概要 (5)3.测试结果及发现 (5)3.1.测试1（标识符） (5)3.2.测试2（标识符） (5)4.对软件功能的结论 (6)4.1.功能1（标识符） (6)4.1.1.能力 (6)4.1.2.限制 (6)4.2.功能2（标识符） (6)5.分析摘要 (6)5.1.能力 (6)5.2.缺陷和限制 (7)5.3.建议 (7)5.4.评价 (7)6.测试资源消耗 (7)使用说明：测试分析报告的编写是为了把组装测试和确认测试的结果、发现及分析写成文件加以记载。
（注意：蓝字部分在正式文档中删掉）1.引言1.1.编写目的提示：说明这份测试分析报告的具体编写目的，指出预期的阅读范围。
（此处填写正文，注意：蓝字部分在正式文档中删掉）1.2.背景提示：a.被测试软件系统的名称；b.该软件的任务提出者、开发者、用户及安装此软件的计算中心，指出测试环境与实际运行环境之间可能存在的差异以及这些差异对测试结果的影响。
（此处填写正文，注意：蓝字部分在正式文档中删掉）1.3.定义提示：列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
（此处填写正文，注意：蓝字部分在正式文档中删掉）1.4.参考资料提示：列出要用到的参考资料，如：a．本项目的经核准的计划任务书或合同、上级机关的批文；b．属于本项目的其他已发表的文件；c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。
列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
（此处填写正文，注意：蓝字部分在正式文档中删掉）2.测试概要提示：用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。
（此处填写正文，注意：蓝字部分在正式文档中删掉）3.测试结果及发现3.1.测试1（标识符）提示：把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。
[计算机软件产品开发文件编制指南]GB8567-88
![[计算机软件产品开发文件编制指南]GB8567-88](https://360docs-1393072327.cos.ap-beijing.myqcloud.com/25fe07f387c24028905fc340.webp)
引言1目的一项计算机软件的筹划、研制及实现，构成一个软件开发项目。
一个软件开发项目的进行，一般需要在人力和自动化资源等方面作重大的投资。
为了保证项目开发的成功，最经济地花费这些投资，并且便于运行和维护，在开发工作的每一阶段，都需要编制二定的文件。
这些文件连同计算机程序及数据一起，构成为计算机软件。
文件是计算机软件中不可缺少的组成部分，它的作用是：a •作为开发人员在一定阶段内的工作成果和结束标志；b.向管理人员提供软件开发过程中的进展和情况，把软件开发过程中的一些不可见的”事物转换成可见的”文字资料。
以便管理人员在各个阶段检查开发计划的实施进展，使之能够判断原定目标是否已达到，还将继续耗用资源的种类和数量；C •记录开发过程中的技术信息，便于协调以后的软件开发、使用和修改；d •提供对软件的有关运行、维护和培训的信息，便于管理人员、开发人员、操作人员和用户之间相互了解彼此的工作；e.向潜在用户报导软件的功能和性能，使他们能判定该软件能否服务于自己的需要。
换言之，本指南认为：文件的编制必须适应计算机软件整个生存周期的需要。
计算机软件所包含的文件有两类：一类是开发过程中填写的各种图表，可称之为工作表格；另一类则是应编制的技术资料或技术管理资料，可称之为文件。
本指南规定软件文件的编制形式，并提供对这些规定的解释。
本指南的目的是使得所编制的软件文件确实能够起到软件文件应该发挥的作用。
2范围本指南是一份指导性文件。
本指甫建议，在一项计算机软件的开发过程中, 般地说，应该产生十四种文件。
这十四种文件是：可行性研究报告；项目开发计划；软件需求说明书；数据要求说明书；概要设计说明书；详细设计说明书；数据库设计说明书；用户手册；操作手册；模块开发卷宗；测试计划；测试分析报告；开发进度月报；项目开发总结报告。
本指南将给出开发过程中建议产生的这十四种文件的编制指导，同时，本指南也是这十四种文件的编写质量的检验准则。
但是，本指南并未涉及软件开发过程中如何填写工作表格的问题。
测试分析报告(GB8567——88)
测试分析报告（GB8567——88）1引言1.1编写目的本报告为校园二手交易平台系统开发的测试分析报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求。
测试分析报告是在测试分析的基础上，对测试的结果以及测试的数据等加以记录和分析总结。
它也是测试过程中的一个重要环节，同时，它也是对软件性能的一个总的分析和认可及对不足之处的说明。
因此，测试分析报告对于今后对软件的功能的增强，不足之处的弥补等都起着十分重要的提纲作用，另外，它还有利于今后软件开发者的阅读原程序，根据测试提供的数据和结果，分子源代码，掌握个函数的功能和局限性。
从而缩短软件开发者的再开发时间和所耗费的精力、资金。
测试工作完成后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。
本分析报告的预期读者为用户、业务或需求分析人员、测试人员、开发人员、用户文档编写者、项目管理人员和其他质量管理人员。
1.2背景被测试软件系统的名称：校园二手交易平台；该软件的任务提出者：计科1205班学生六名学生，刘悦，李国婷，朱亚南，安冬冬，王娜开发者：计科1205班学生六名学生，刘悦，李国婷，朱亚南，安冬冬，王娜测试环境与实际环境之间的差异：1.3定义WEB技术：World wide web是英国人TimBerners-Lee1989年在欧洲共同体的一个大型科研机构2发明的。
通过WEB，互联网上的资源，可以在一个网页里比较直观的表示出来；而且资源之间，在网页上可以相互连接，互相访问。
它是一系列技术的复合总称（包括网站的前台布局、后台程序、美工、数据库领域等等的技术概括性的总称）。
JA V A EE: JA V A EE（Java Platform,Enterprise Edition）是sun公司推出的企业级应用程序版本。
这个版本以前称为J2EE，能够为我们帮主开发和部署可移植、健壮、可伸缩且安全的服务器端JA V A应用程序。
[计算机软件产品开发文件编制指南]GB8567-88
![[计算机软件产品开发文件编制指南]GB8567-88](https://360docs-1393072327.cos.ap-beijing.myqcloud.com/f66c638e04a1b0717fd5ddf5.webp)
引言1 目的一项计算机软件的筹划、研制及实现，构成一个软件开发项目。
一个软件开发项目的进行，一般需要在人力和自动化资源等方面作重大的投资。
为了保证项目开发的成功，最经济地花费这些投资，并且便于运行和维护，在开发工作的每一阶段，都需要编制二定的文件。
这些文件连同计算机程序及数据一起，构成为计算机软件。
文件是计算机软件中不可缺少的组成部分，它的作用是：a．作为开发人员在一定阶段内的工作成果和结束标志；b．向管理人员提供软件开发过程中的进展和情况，把软件开发过程中的一些“不可见的”事物转换成“可见的”文字资料。
以便管理人员在各个阶段检查开发计划的实施进展，使之能够判断原定目标是否已达到，还将继续耗用资源的种类和数量；C．记录开发过程中的技术信息，便于协调以后的软件开发、使用和修改；d．提供对软件的有关运行、维护和培训的信息，便于管理人员、开发人员、操作人员和用户之间相互了解彼此的工作；e．向潜在用户报导软件的功能和性能，使他们能判定该软件能否服务于自己的需要。
换言之，本指南认为：文件的编制必须适应计算机软件整个生存周期的需要。
计算机软件所包含的文件有两类：一类是开发过程中填写的各种图表，可称之为工作表格；另一类则是应编制的技术资料或技术管理资料，可称之为文件。
本指南规定软件文件的编制形式，并提供对这些规定的解释。
本指南的目的是使得所编制的软件文件确实能够起到软件文件应该发挥的作用。
2 范围本指南是一份指导性文件。
本指甫建议，在一项计算机软件的开发过程中，一般地说，应该产生十四种文件。
这十四种文件是：可行性研究报告；项目开发计划；软件需求说明书；数据要求说明书；概要设计说明书；详细设计说明书；数据库设计说明书；用户手册；操作手册；模块开发卷宗；测试计划；测试分析报告；开发进度月报；项目开发总结报告。
本指南将给出开发过程中建议产生的这十四种文件的编制指导，同时，本指南也是这十四种文件的编写质量的检验准则。
测试分析报告(GB8567——88)
1.引言 (1)1.1编写目的 (1)1.2背景 (1)1.3定义 (1)1.4参考资料 (1)2.测试概要 (2)3.测试结果及发现 (2)3.1测试1（标识符） (2)3.2测试2（标识符） (2)3.3测试3（标识符） (2)3.4测试4（标识符） (3)4.分析摘要 (4)4.1能力 (4)4.2缺陷和限制 (4)4.3评价 (4)5.测试资源消耗 (4)测试分析报告（GB8567——88）1引言1.1编写目的通过测试，确保本系统的功能、互操作性等符合软件的设计要求，分析测试的过程，产品，资源，信息，为以后指定测试计划提供参考。
分析系统存在的缺陷，为修复和预防bug 提出建议，满足用户的使用要求。
1.2背景说明：a.软件系统名称：Dota2小秘书。
b.软件项目的任务提出者：徐彦哲开发者：柳畅、宋雪岩、徐彦哲、卿茂杰、沙露露c.用户：Dota2玩家d.应用平台：PC win xp/ win 7 64位/ win 7 32位1.3定义Dota:Denfese of The Ancients.最初是《魔兽争霸3》的一个地图，它采用了英雄角色可以升级、学习新技能还能装备道具的概念。
不同于把可升级的英雄混入即时战略框架。
DotA 强调了操作体验，这样你操控的不再是一支军队，而是一个英雄。
你不需要建造基地，你就是你，你选中英雄和少量的升级技能就行了。
DOTA2是脱离了War3的引擎，由美国Valve公司研发运营，完美世界代理，并由DotA 的地图作者IceFrog（冰蛙）联手Valve开发的多人联机在线RPG。
DOTA2整个游戏将会保持原有风格不变，DotA中的100多位英雄正在逐步的移植到DOTA2中。
从某种程度上来说，DOTA2是现有DotA的新引擎版。
完美正式宣布DOTA2于2013年4月28日开始测试，已发布中文名“刀塔”。
1.4参考资料a．《软件工程》齐治昌高等教育出版社b．《深入体验C#项目开发》扶松柏清华大学出版社c．《C#程序设计案例教程》蔡朝晖清华大学出版社2测试概要Dota2小秘书主要有四个模块，我们预先设想的是建立一个联网数据库，这样软件中不仅囊括了“英雄出装”这样固定不变的数据，还能实时更新“热点推荐”等实时数据。
附录5：详细设计说明书(GB8567——88)
详细设计说明书（GB8567—— 88）1引言1.1 编写目的本次的目的是从总体上把握系统设计框架，说明了用户需求和应用系统实现之间的关系，在设计过程中起到了提纲挈领的作用。
包括设计模式，数据库设计等模块，将这个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口。
建立目标系统的一个逻辑模型。
随着计算机及互联网的普及，传统的教务人工管理已经很难适应新环境。
传统的选课方式是随堂报名，无法预见上课人数，浪费教学资源。
以现代网络技术环境为依托，将传统选课模式转换为利用现代网络技术进行选课操作和管理的网上选课系统已经成为一项重要的改革。
网上选课管理系统作为管理员与用户的选课关系的主要管理系统平台，其对应的读者是企业用户，因此，不仅要处理管理员与用户之间的信息，还要处理用户个人信息。
导致网上选课系统中的数据不论是结构，类型还是彼此间的关联都是复杂多变的；对这种数据处理也是多种多样的。
因此，要实现对网上选课管理系统数据的及时，准确的处理和有效利用。
借助这个系统，学校可以实现一站式选修课网上选课管理，流程包括：系统设置--选课任务设置 --学生选课—选课结果审查—生成选课报名表（包括：学生本人的选课列表、课程表和给上课教师的报名单） --选课查询和统计报表。
整个选课的流程方便快捷，省时省力。
本文档的预期读者是：设计人员开发人员测试人员用户1.2 背景本软件系统名称为高校学生网上选课系统。
随着学校规模的不断扩大专业、班级学生的数量急剧增加有关学生选课的各种信息量也成倍增长而且目前许多高校的学生选课管理仍停留在复杂的人工操作上重复工作较多工作量大效率低。
因此迫切需要开发学生网上选课系统来提高管理工作的效率。
本项目的任务提出者是：李江（201296074040 ）1开发者：是李江（ 201296074040） 朱豪飞（ 2012960274004 ）王雨欣（ 201296074019） 喻晓（ 201296074036 ）因为传统的选课方式都是手工的， 教务处通知各班进行选课， 各班班长再通知每个同学， 经过统计在上交教务处，这样比较浪费时间。
测试分析报告(GB8567——88)
测试分析报告（GB8567——88）1引言1.1编写目的软件测试是为了在软件投入生产性运行之前，尽可能多地发现软件的错误，该文档的读者对象是软件测试部门，以指导软件测试过程。
1.2背景随着学校的规模不断扩大，学生数量急剧增加，有关学生的各种信息量也成倍增长。
面对庞大的信息量需要有学生管理系统来提高学生管理工作的效率。
通过这样的系统可以做到信息的规范管理、科学统计和快速查询、修改、增加、删除等，从而减少管理方面的工作量。
本系统主要用于学校学生信息管理，总体任务是实现学生信息关系的系统化、规范化和自动化，其主要任务是用计算机对学生各种信息进行日常管理，如查询、修改、增加、删除，另外还考虑到学生选课，针对这些要求设计了学生信息管理系统本系统主要用于学校学生信息管理，总体任务是实现学生信息关系的系统化、规范化和自动化，其主要任务是用计算机对学生各种信息进行日常管理，如查询、修改、增加、删除。
1.3定义Visual C#——C#是微软开发的一种面向对象的编程语言，是微软.NET 开发环境的重要组成部分。
而Microsoft Visual C# 2005是微软开发的C#编程集成开发环境（同种产品还有Borland 公司的C# Builder）它是为生成在.NET Framework 上运行的多种应用程序，而设计的。
1.4参考资料[1] 张海藩，《软件工程导论》，清华大学出版社，2008[2] 陆丽娜，《软件工程》，经济科学出版社,2008[3] 萨师煊，《数据库系统概论》，高等教育出版社，2006[4] 薛华成，《管理信息系统》清华大学出版社，20072测试概要2.1系统登录页面的测试该测试的目的是保证登陆主页面的正确性与在错误发生时的容错与纠错性。
具体通过在登陆框中输入空用户名，和错误的用户名来检测系统的出错运行情况。
要求系统在遇到这些情况时能给出正确的错误提示。
2.2 管理员成绩管理页面的测试该测试的目的是保证在添加、修改、删除、查询学生信息、班级、课程、成绩时系统的正确性与在数据输入不正确时的容错与纠错性。
详细设计说明书(GB8567——88)
1引言 (2)1.1编写目的 (2)1.2背景 (2)1.3定义 (2)1.4参考资料 (2)2程序系统的结构 (2)3程序1（标识符）设计说明 (2)3.1程序描述 (3)3.2功能 (3)3.3性能 (3)3.4输人项 (3)3.5输出项 (3)3.6算法 (3)3.7流程逻辑 (3)3.8接口 (3)3.9存储分配 (4)3.10注释设计 (4)3.11限制条件 (4)3.12测试计划 (4)3.13尚未解决的问题 (4)4程序2（标识符）设计说明 (4)详细设计说明书1引言1.1编写目的说明编写这份详细设计说明书的目的，指出预期的读者。
1.2背景说明：a．待开发软件系统的名称；b．本项目的任务提出者、开发者、用户和运行该程序系统的计算中心。
1.3定义列出本文件中用到专门术语的定义和外文首字母组词的原词组。
1.4参考资料列出有关的参考资料，如：a．本项目的经核准的计划任务书或合同、上级机关的批文；b．属于本项目的其他已发表的文件；c．本文件中各处引用到的文件资料，包括所要用到的软件开发标准。
列出这些文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。
2程序系统的结构用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）的名称、标识符和它们之间的层次结构关系。
3程序1（标识符）设计说明从本章开始，逐个地给出各个层次中的每个程序的设计考虑。
以下给出的提纲是针对一般情况的。
对于一个具体的模块，尤其是层次比较低的模块或子程序，其很多条目的内容往往与它所隶属的上一层模块的对应条目的内容相同，在这种情况下，只要简单地说明这一点即可。
3.1程序描述给出对该程序的简要描述，主要说明安排设计本程序的目的意义，并且，还要说明本程序的特点（如是常驻内存还是非常驻？是否子程序？是可重人的还是不可重人的？有无覆盖要求？是顺序处理还是并发处理等）。
3.2功能说明该程序应具有的功能，可采用IPO图（即输入一处理一输出图）的形式。
[计算机软件产品开发文件编制指南]GB8567-88
[计算机软件产品开发文件编制指南]GB8567-88 GB8567-88Guidelines for computer software product development documentation UDC6813黎宇 (转自国家计算机标准和文件模板) 2002-4-151一项计算机软件的筹划、研制及实现，构成一个软件开发项目。
一个软件开发项目的进行，一般需要在人力和自动化资源等方面作重大的投资。
为了保证项目开发的成功，最经济地花费这些投资，并且便于运行和维护，在开发工作的每一阶段，都需要编制二定的文件。
这些文件连同计算机程序及数据一起，构成为计算机软件。
文件是计算机软件中不可缺少的组成部分，它的作用是：a．作为开发人员在一定阶段内的工作成果和结束标志；b．向管理人员提供软件开发过程中的进展和情况，把软件开发过程中的一些“不可见的”事物转换成“可见的”文字资料。
以便管理人员在各个阶段检查开发计划的实施进展，使之能够判断原定目标是否已达到，还将继续耗用资源的种类和数量；C．记录开发过程中的技术信息，便于协调以后的软件开发、使用和修改；d．提供对软件的有关运行、维护和培训的信息，便于管理人员、开发人员、操作人员和用户之间相互了解彼此的工作；e．向潜在用户报导软件的功能和性能，使他们能判定该软件能否服务于自己的需要。
换言之，本指南认为：文件的编制必须适应计算机软件整个生存周期的需要。
计算机软件所包含的文件有两类：一类是开发过程中填写的各种图表，可称之为工作表格；另一类则是应编制的技术资料或技术管理资料，可称之为文件。
本指南规定软件文件的编制形式，并提供对这些规定的解释。
本指南的目的是使得所编制的软件文件确实能够起到软件文件应该发挥的作用。
2本指南是一份指导性文件。
本指甫建议，在一项计算机软件的开发过程中，一般地说，应该产生十四种文件。
这十四种文件是：可行性研究报告；项目开发计划；软件需求说明书；数据要求说明书；概要设计说明书；详细设计说明书；数据库设计说明书；用户手册；操作手册；模块开发卷宗；测试计划；测试分析报告；开发进度月报；项目开发总结报告。
模块开发卷宗(GB8567——88)
模块开发卷宗（GB8567——88）1标题软件系统名称和标识符模块名称和标识符（如果本卷宗包含多于一个的模块，则用这组模块的功能标识代替模块名）程序编制员签名卷宗的修改文本序号修改完成日期卷宗序号（说明本卷宗在整个卷宗中的序号）编排日期（说明整个卷宗最近的一次编排日期）2模块开发情况表3功能说明扼要说明本模块（或本组模块）的功能，主要是输入、要求的处理、输出。
可以从系统设计说明书中摘录。
同时列出在软件需求说明书中对这些功能的说明的章、条、款。
4设计说明说明本模块（或本组模块）的设计考虑，包括：a．在系统设计说明书中有关对本模块（或本组模块）设计考虑的叙述，包括本模块在软件系统中所处的层次，它同其他模块的接口；b．在程序设计说明书中有关对本模块（或本组模块）的设计考虑，包括本模块的算法、处理流程、牵涉到的数据文卷设计限制、驱动方式和出错信息等；c．在编制目前已通过全部测试的源代码时实际使用的设计考虑。
5原代码清单要给出所产生的本模块（或本组模块）的第一份无语法错的源代码清单以及已通过全部测试的当前有效的源代码清单。
6测试说明说明直接要经过本模块（或本组模块）的每一项测试，包括这些测试各自的标识符和编号、进行这些测试的目的、所用的配置和输入、预期的输出及实际的输出。
7复审的结论把实际测试的结果，同软件需求说明书、系统设计说明书、程序设计说明书中规定的要求进行比较和给出结论。
一、上机目的：掌握黑盒测试中的基于系统级别的各种测试方法。
二、上机内容：1、不按班级,按小组的顺序排座位,一组的成员尽量坐在一块，分组情况和位置尽量保持连贯性。
1到10组在4B413，11到19组在4B414；2、参考和理解第4章第2节的内容，根据本小组之前选的或开发好的系统，进行更加充分的讨论和分工；3、进一步完善案例说明、测试分析和测试用例的设计。
在测试用例设计中，要求每小组分别完成基于模块的功能测试、基于场景的业务流程测试和基于界面的用户界面测试。