【电子行业标准(SJ)】 信息处理－计算机应用系统文件编制指南

中华人民共和国电子工业推荐性部标准SJ/Z9060-87
信息处理计算机应用系统文件编制指南1SO6592-1985
Information procassingwGuidelines for the documentatlonof computer-baSed application systems范围和应用领域
本标准为计算机应用系统的文件编制提供指南。它还包含一些内容提纲，以支持系统整个生存周期内的有效活动。编制该指南的目的是；
）获得为计算机应用系统开发各方所必需的协议，b）有助于产生详尽规划和标准化的系统文档e）使系统文档能和系统开发工作平行地顺序产生。系统开发过器中对文件编制有明确的规则有助于，a）文件本身的编写
b）完成项目所需时间及资源的估算，c）有关各方之间的信息交换，以产生一对某个系统来讲可达到的目标的选择，一个更完整、更周密的功能设计d）在系统开发工作期间，对有关人员作出判定和提出简要报告。按照本标准产生的系统文档
a）使得管理部门能对开发过程加以控制，b）使系统用户能正确有效地使用该系统；）使计算机操作员能安排和运行该系统，d）有助于诊断和校正错误或故障；e）提供有关系统信息以支持系统维护。本标准不适用于计算机应用系统的硬件设计中的文件编制。文件编制的原则
2.1总的考虑
尽管计算机系统应用的多样性，但存在一些基本的相似之处，例如，明显的特征是计算机总是须经输入、处理和输出三个阶段，并且总需要确定和论证为开发和实现一个计算机项目（无论大小）所需资源如人员，材料和资金，并将所建的系统的各方面用文件充分地表达。
中华人民共和国电子工业部1987-1020批准.1.
SJ/Z9060-87
提出本标准所确定的指南，其目的是要帮助建立文件编制的基本框架，它作为任何项目开发的坚实基础，通过适当的进度安排和控制机制进行有效的开发和实现，使整个开发工作按预定的和被批准的方式进行。对本标准的应用应随具体系统的类型不同而有所区别。例如，操作方法在一个过程控制环境中比在一个商业批处理系统中更为重要。一个特定文件或一些特定信息可能与某个系统毫无关联。但它对于另一个系统却是很重要的。虽然本标准中给出了文件内容提纲，但编写者经过深思熟虑，可对内容的取舍作出决定。
随着开发工作的逐步深入，有可能要对以前产生的文件进行修订。2.2信息的类型
本标准明确区分两种信息，即管理信息和技术信息。管理信息是项目控制管理方面信息，它记录所批准和做过的事情。对这种信息应加以保存，但实施一且完成后，不必对其修改。技术信息是对系统所有方面的当前情况的描述，包括软件、硬件和数据。在系统生存周期内需不断对其进行修改。两类信息可能同时出现在某些文件中，但建议将它们分别置于不同的章节，这样更便于对技术信息进行维护。
2.3项目阶段和文档的关系
本标准所给的指南将项目开发阶段与所产生的文件对应起来。一般来说，每个阶段都起始于一个文件，并由一个文件来总结。尽管各主要阶段是按顺序进行的，某些阶段和某些文件的编制是互相重叠的。例如，系统支持手册的编写是在系统设计和开发阶段中开始。对于不同的应用系统，阶段数目和所产生的文件数目都可能不同；本标准列出了文件编制的基本成份，这些成份通常出现在开发过程每一阶段所产生的文件中。2
可行性研究
（见第8章）
系统设计研究
(见第4率）
系统设计和开发
（见第5章）
系统支持
（贝第6）
系统实器
(见第7年）
实现府的评市
(m第s率）
SJ/Z9060-87
注，在不器进行可行性研究的地方：政变起始点产生的文件
可行丝研究请求
可行性研究报告
系统设计研究请求
（见4·2）
系统设计研究报告
（见4.8)
系统设计文件
系统总体文件和部件文件
（见6.8、5.4和附录
A、B、C)
实现文件：计划和试
（见7.2.1和7.2.2)
系统支持文件：
用户、操作、程序、数据、
系统技术和修改手册
（见6.2)
验收报告见7.3，8）
评价报告（见8，2）
图项目开发各阶段之间关系的概貌可行性研究
3.1目的
进行可行性研究的目的是
）确定在初步研究后所需要的是什么b）研究可能的解决方法，选定一种较好的方法c）用文件表达新系统的需求和约束条件。3.2可行性研究请求
该文件批准使用一些资源来研究具体的要求，设计目标或问题，并选择一种可能解3
SJ/Z9060-87
法。本文件是在项目工作开始之前，由用户提出或受用户委托提出。绵制该文件需要专家的帮助，以确定可行性研究所需的时间和费用指标。对可行性研究请求的批准导致此项研究工作的开展，并最终编写一个可行性研究报告。
3.3可行性研究报告
3.3.1目的
可行性研究报告使用户能够决定是否继续进行下一个阶段，邸系统设计阶段。3.3.2系统问题及信息的分析
a）系统问题：
1）定义，包括背景和当前情况
2）技术和财政上的限制条件。
b）系统目标：
1）定义和说明，
2）界限，
3）提要。
c）系统信息：
1）定义和说明，
2）关系，
3）规范。
d）系统处理：
1）说明，
2）输入、需存储的数据和输出，3）数据间的关系；
4）周期性；
5）数据容量。
3.3.3项目组织和需求：
a）人员要求，
b）培训和教育
e）主要活动的时间表，wwW.bzxz.Net
d）人力，
e）硬件，
f）软件，
g）公用设施。
3.3.4投资和收益：
a）财务支出；
b）收益。
3.3.5所建议的系统：
a）功能描述，
b）确保精确性的控制，
c）保密性；
d）接口，
e）数据流；
SJ/Z9060--87
f）增长的允许范围：数据容量，新的功能9）进度/时间安排，
h）非计算机功能；
1）人力；
J）硬件，
k）软件，
1）公用设施。
3.3.6实现、质量和验收方面的考虑，a）系统测试；
b）文卷的建立/转换
c）与现有系统的联接，
d）用户教育和培训，
e）仿真，
f）建议的切换方法
9）服务的改变
h）质量保证要求，
1）产品可靠性要求，
J）系统验收准则。
3.3.7支持设施：
a）失效后的恢复，
b）维护
c）备件的可利用性
3.3.8词汇表
新的或非常用的术语的解释。
3.3.9结论和建议：
a）系统要求：
1）用户的需要，
2）能满足的程度。
b）可选择的方案：
1）说明所考虑的可选择的方案，.5.
2）陈述落选的原因。
4系统设计研究
4.1目的
SJ/Z9060-87
本阶段目的是详细规定所选择的设计方案。4.2系统设计研究请求
此文件陈述在仔细考虑可行性研究报告之后要执行的步骤。作为它最简单的形式，仅仅是表示接受可行性研究报告提出的建议，并批准进行系统设计研究。4.3系统设计研究报告
4.3.1目的
系统设计研究报告应写得足够详细，使得o）用户得到一个系统的作用的明确描述（储存的输入、处理、输出信息，时间安排等）。
b）用户知道为运行该系统究竟要做些什么，c）为实现和运行该系统所必需的机构变化或调整得以确定，并能作为独立的任务来进行
d）对于要在下一阶段产生的系统设计文档来说，系统功能需求是非歧义的。4.3.2计划：
o）组织机构；
b）时间表；
）主要的资源要求，
d）质量保证，
e）要使用的标准。
4.3.3投资和收益：
a）开发费用；
b）安排费用；
c）培训和教育费用
d）运行费用
e）可统计的和不可统计的收益。4.3.4：系统描述：
a）系统应用的功能概述；
b）硬件要求，
c）通信要求，如终端、连线、调制-解调器、集中器等，d）对语言，数据库、操作系统等软件的要求，e）数据描述，
f）数据流，包括数据的最大容量和正常容量6
9）数据容量改变的允许范围，
h）确保数据精度的控制，
SJ/Z9060-87
）保密性、系统整体性、数据保护、物理安全性、有效性J）环境和能源要求（包括所有备用的安排）k）与其它系统（现有的或建议中的系统）的接口，1）进度要求，
m）增加功能的允许限度，
n）非计算机过程。
4.3.5实现、质量和验收计划：
a）用户教育／培训；
b）文卷的建立/转换，
c）系统测试和性能估价
d）仿真；
e）服务的改变，
f）与现有系统的联接；
9）变换方法；
h）质量保证要求，
1）产品的可靠性程度；
J）系统验收准则。
4.3.6支持设施：
a）失效后的恢复，
b）维护的职责和可靠性；
c）备件和后援的可利用性。
4.3.7应用系统的概述
a）问题定义及解法
b）建议；
c）系统运行：
1）人力；
2）硬件；
3）软件；
4）公用设施，
5）财务预算；
6）保密性
7）进度／时间安排；
d）新的或非常用的术语表。
4.3.8管理概述：
a）人，
b）硬件，
c）质量保证要求，
d）公用设施的要求，
e）费用估算：
SJ/Z9060—87
1）项目的下一阶段所需费用的估算，2）整个项目所需费用的估算，
f）收益的估算，
9）时间表。
系统设计和开发
系统设计和开发的目的是
）详述自动的和人工的处理过程，确定它们的界面，b）产生便于编写程序的文件，
e）提供为完成新系统的测试和实现工作所需的信息，d）制订实现阶段要执行的所有活动的详细计划，e）给出编写系统支持手册的考虑。5.2系统设计文件
该文件的作用是根据下述原则提供系统的一个完整的设计记录，a）系统的每个部分都有一个加以说明的功能，b）一个完整系统的所有功能可这样来充分地描述：将系统分解为若干个部分，描述各个分解部分及它们之间的相互作用和关系，该文件一般至少包含两个层次，即系统总体文件（见5.3）3
一部件文件（见5.4）。
5.3系统总体文件
在本文件中，对系统描述的详细程度依赖于系统的要求。可能要将该文件作为系统支持手册的基础。
系统总体文件应详细列出：
の）项目标题；
b）目标，
c）说明（文字和图表说明）：
子系统的标识符，
一与其它系统的接口；
d）保密性；
e）控制（包括审计要求）：
f）运行环境；
g）失效后的恢复，
h）运行该系统所需的支持设施，f）数据要求，
J）测试过程；
k）变换过程，
5.4部件文件
SJ/Z9060-87
该文件给出程序、文卷和人工操作的详细规格说明。可能要将其作为系统支持手册的基础。
5.4.1程序规范
见附录A。
5.4.2文卷和数据库规范
见附录B。
5.4.3人工过程规范
见附录C。
系统支持
6.1目的
本阶段的目的是要支持被用户所接受的系统，它包括下述内容a）系统的正常使用，
b）查错和改错
）可能的修改和增强。
应该了解到可能不是由开发该系统的人员来进行此项活动。6.2系统支持文件
系统支持文件应从系统设计和开发阶段中产生的文件中形成。对那一阶段产生的文件所作的任何更改应反映在系统支持文件中。具体提供哪些文件要依特定的系统要求、维护方针和文件标准而定。但为了达到系统支持的目的，建议按下列标题给出此类文件）用户手册
本手册应清晰、简要地描述系统的用户和供应者的权利和职责。下面举出这种权利和职责的例子：1）
用户的权利包括：
获得关于系统使用的信息的权利，一获得关于理解系统结果及改正数据错误的信息的权利。2）用户的职责包括：
一正确地准备输入数据；
SJ/Z9060--87
一将在系统中发现的任何错误通知供应者。3）供应者的权利包括：
对所提供系统进行修改的权利；执行连续的测试，以保证系统继续正确运行的权利。4）
供应者的职责包括：
进行精确性维护并更新文件；
积累和传播用户使用系统的经验。所有这些权利和职责须经供应者和顾客的一致同意，并遵循国家的和国际的有关法规和／或标准。本手册还应给出有关质量保证和产品可靠性法规的信息。b）操作手册
本手册描述在该系统的所有操作模式下，怎样使用计算机和有关设备操作该系统。程序手册
程序手册描述每个程序的作用，给出诸如使用的数学表达式和算法、出错处理措施和时间安排之类的信息。它应包括各程序的列表（应有注解，它对修改和增强有用）。测试数据和结果。
d）数据手册
本手册应按系统要求所规定的详细程度描述系统数据结构。e）系统技术手册
本手册使技术人员能了解系统工作的方式，帮助他们查找和改正错误，进行修改和增强。必要时，应引用硬件说明资料。f）系统更改记录
它记录在何时、怎样、为什么、由谁对系统哪些部分进行了何种更改并得到批准。7系统实现
7.1目的
本阶段的目的是要在系统操作环境下进行完全的系统验收测试，并证明所有定义的需求都已得到满足。
7.2文件要求
本阶段的输入文件包括系统的一个实现计划和验收测试计划。输出文件是一个验收报告。
7.2.1实现计划
尽管实现在项目开发的最后进行，但实现的规划应在较早阶段开始。并且在系统开发过程中，要对此计划进行必要的修改。此计划应详述：
）公用设施和环境
b）人员组织，
用户教育和培训，
文卷建立，
SJ/z9060-87
文件的更改、汇集和分发，
维护过程的验证，
实现的时间安排和实现方法
系统更换过程，
恢复过程。
7.2.2验收测试计划
此文件规定在确定的操作环境下，怎样进行测试。还应提供一份预期结果的检验表，必要时给出容差。
7.2.3验收报告
该报告是一个体现验收测试结果的文件。它应由所有的有关部门签署，并被复制给这些部门。
如果验收合格，可能的话应提供一份有关系统的各种缺陷和补救建议的正式文件。8实现后的评审
8.1目的
本阶段的目的是定期地做以下工作，a）研究系统目标的履行情况，
b）监督资源的配备情况和费用估算，c）列出系统的难以确定的积极和消极作用，d）分析、记录在系统开发期间获得的经验。8.2评价报告
评价报告
a）评定初始的系统自标是否正确，它们在多大程度上已得到实现，b)
精确地确定能改进的部分；
确认被实践证实的成功之处，
确认和评定所遇到的操作问题；e）
说明所要求得到的收益是否已获得，f）
总结记录有助于以后开发项目的经验教训。9文件的管理
9.1文件的产生和处理
文件编制的一个重要方面是产生满足文件用户要求的文件。需要清晰地定义这些要求，并以读者易于接受和理解的方式表达文件的内容。对系统开发的一个阶段里生成的每个文件，应规定个唯一的标识符或代码，以利..
SJ/Z9060—87
于它的保存和随后的检索。这个标识符或代码应明确地表示出该系统或项目及文件所属的类别。各单位所决定的系统和子系统标识的原则可能不一样，但应按照各单位自已的规则来说明。
为了便于引用和控制各种修改或更新，采用清晰的、无歧义的按页索引方法是十分重要的。
经验表明，使用一个能满足下述要求的文件编制系统会产生积极的效果：o）每一页具有关于系统、阜、章内的页、发行号和启用日期的唯一标识b）具有每一章得到完成的标识，c）明确标识各种插入和删除。
建议采用活页的方式。
应该约定并明确定义修改系统文档要遵循的规程。必须使所有的项目人员和用户都正确地了解该规程。
9.2核心文件的原则
核心文件应包含与系统整个生存周期活动有关的全部信息。每当一个决定、成果、修改通过时，要更新核心文件内的信息，因此它总是有效的。
为便于进行这种更新，信息的每一项一般应仅在核心文件中出现一次。9.3对文件分发的建议
将集中存放的全部文件集合和不同部门、不同人员所需的汇编子集合明确区分开是十分重要的。
子集一般包括从全部文件集合的不同部分中复制和编辑得到的文件。对每个文件要给出根据各部门要求确定的发行清单，注明文件接受者名字或部门的代码。，12
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。