文件给制实施规定的实例（GB8567-88）1
文件给制实施规定的实例（GB8567-88） 尽管在文件编制中存在着很多灵活性，然而，文件的编制确实是非常必要的，其意义 如前所述。为了控制这种灵活性，保证文件编制能达到应该达到的目的，对于具体的软 件开发任务，应编制的文件的种类、详细程度应取决于承担开发单位的管理能力、任务 的规模、复杂性和成败风险等因素。一个软件开发单位应该根据本单位经营承包的应用 软件的专业特点和本单位的管理能力，制定一个文件编制实施规定，说明在什么情况下 应该编制哪些文件。由于国内目前在这方面还缺乏成熟的经验，这里提供参考国外经验 制定的两个例子，用以向国内软件开发单位说明如何建立这种实施规定，使项目负责人 能确定本项目开发过程中应编制的文件的种类。当然，例子毕竟只是例子，这两个例子 各自都不免有其片面性，它们两者之间也不免有不一致之处，之所以列出来无非是供国 内软件开发单位参考。 例1： 此例规定用求和法来确定应编制的文件。该方法的要点是提出十二个考虑因素来衡量 一个应用软，件，每个因素可能取值的范围是互至5。任务负责人可用这十二个因素对所 要开发的程序进行衡量，确定每个因素的具体值。把这十二个因素的值相加，得到一个 总和。然后由这个总和的值来确定应该编制的文件的种类。使用这个方法的具体过程如 下： a. 按表OI中的十二个因素衡量所要开发的程序，得到每个因素的值； b. 把衡量所得的各个因素的值相加，得总和之值； c. 根据总和之值，从表OZ查出应编制的文件的种类。 表1文件编制的十二项衡量因素 |序 |因素 |因素取值准则 | |号 | | | | | |1 |2 |3 |4 |5 | |1 |创造性要求|没有——在 |很少——具 |有限——具 |相当多—— |重大的—— | | | |不同的设 |有严格的 |有新的接 |应用现有 |应用先进 | | | |备上重编 |要求 |口 |的技巧 |的技巧 | | | |程序 | | | | | |2 |通用程度 |很强的限 |有限制—— |有限的灵 |多用途， |很灵活—— | | | |制——单一 |功能的范 |活性允许 |灵活的格 |能在不同 | | | |目标 |围是参量 |格式上有 |式有一个 |的设备上 | | | | |化的 |某些变化 |主题领域 |处理范围 | | | | | | | |广泛的主 | | | | | | | |题 | |3 |工作范围 |局部单位 |分指挥部 |单个指挥 |多个指挥 |国防部， | | | | | |部 |部 |世界范围 | |4 |目标范围的|没有 |极少 |偶尔有 |经常 |不断 | | |变化 | | | | | | |5 |设备复杂性|单机，常 |单机，常 |多机，标 |多机，复 |主机控制 | | | |规处理 |规处理， |准外设系 |杂的外设 |系统，多 | | | | |扩充的外 |统 |系统 |机，自动I| | | | |设系统 | | |/O和显示 | |6 |人员 |1～2人 |3～5人 |5～10人 |10～18人 |18人以上 | |7 |开发投资 |6人月以下|6人月至3 |3人年至10|10人年至3|30人年以 | | | | |人年 |人年 |0人年 |上 | |8 |重要程度 |数据处理 |常规过程 |人身安全 |单位成败 |国家安全 | | | | |控制 | | | | |9 |对程序改变|2周以上 |1～2周 |3～7天 |1～3天 |24小时以 | | |的完成时间| | | | |内 | | |要求 | | | | | | |10 |对数据输入|2周以上 |1～2周 |1～7天 |1～24小时|60分钟内 | | |的响应时间| | | | | | | |要求 | | | | | | |11 |程序语言 |高级语言 |高级语言 |高级语言 |汇编语言 |机器语言 | | | | |带一些汇 |带相当多 | | | | | | |编 |的汇编 | | | |12 |并行的软件|没有 |有限 |中等程度 |很多 |完全的并 | | |开发 | | | | |行开发 | 表1文件编制的十二项衡量因素 因素总和 |可行性研究报告 |项目开发计划 |软件需求说明书 |数据要求说明书 |概要设计说明书 |详细设计说明书 |数据库设计说明书 |用户手册（使用说明） |操作手册 |模块开发卷宗 |测试设计 |测试分析报告 |项目开发总结报告 |开发制度月报 | |12～18* 14～24 24～38 38～50 48～60 | √ √ √ |√ √ √ √ √ | √ √ √ √ | *** *** *** *** | √ √ | √ | *** *** *** *** |√ √ √ √ √ | √ √ √ | √ √ √ √ | √ √ √ √ | ** ** √ √ |√ √ √ √ √ | √ √ √ √ | |*在因素总和较低的情况下,项目开发总结报告的内容应包括：程序的主要功能、基本 流程、测试结果和使用说明。 **测试分析报告应该写，但不必很正规。 ***数据要求说明和数据库设计说明是否需要编写应根据所开发软件的实际需要来决定。 例2： 为了避免在软件开发中文件编制的不足或过分，一个简便的办法是把对软件文件的编 制要求同软件的规模大小联系起来，这就是本例的出发点。软件的规模不妨分为四级： 1. 小规模软件源程序行数小于5000的软件； 2. 中规模软件源程序行数为10000～50000的软件； 3. 大规模软件源程序行数为100000—500000的软件； 4. 特大规模软件源程序行数大于500000的软件。 对上述的四级软件的文件编制要求分别列于表3。 至于源程序行数为5000～10000，50000～100000的软件，其文件编制要求介于两级之 间，可根据一个软件产品的具体情况，由项目负责人参照表3的规定，确定需要编制的文 件种类。 对于源程序行数大于500000的特大规模软件，可进一步把本指南规定的十四种文件按 实际需要扩展成更多种类，这一点在本指南5.3.3已经提到。 表3产品文件体系 ----------------------- 可行性报告 项目开发计划 对应大规模软件所规定的文件可进一步细分 软件需求说明 数据要求说明 测试计划 项目开发计划 软件需求说明 测试计划 软件需求与开发计划 概要设计说明 详细设计说明 数据库设计说明 软件设计说明 软件设计说明 使用说明 使用说明 用户手册 操作手册 模块开发卷宗 测试分析报告 测试分析报告 模块开发卷宗 测试分析报告 开发进度月报 项目开发总结 开发进度月报 项目开发总结 项目开发总结 小规模软件 中规模软件 大规模软件 超大规模软件
文件给制实施规定的实例（GB8567-88）1