中华人民共和国国家标准
G8／T14079—93
软件维护指南
GUNel5量e o量80『twa『e ma5nte量Qnce
1 主题内容与适用范围
本标准描述软件维护的内容和类型、维护过程及维护的控制和改进。
本标准适用于软件生存周期的运行和维护阶段，主要供软件管理人员和维护人员使用。
2 引用标准
GB 8567 计算机软件产品开发文件编制指南
GB／T l1457 软件工程术语
3 术语
本标准使用GB／T11457中的术语及下列术语：
3.1 自底向上法
在层次结构的软件中，一种从最低层成份开始逐级向上扩展，直到最高层成份的开发方法。
3.2 自顶向下法
在层次结构的软件中，一种从最高层成份开始逐级向下扩展，直到最低层成份的开发方法。
3.3 编译扩展
一种程序设计语言的特征。这种特征超越了该语言的标准特征，但仍可以为一专门的编译程序所接受并加以编译。
3.4 同级评审
一种质量保证方法，由两个或多个同级程序员互相检查、评估，以确保被检查内容正确，且与软件的其他部分相一致。
3.5软件维护管理机构
为评审修改带来的影响、制订维护计划、复查修改结果、管理维护工作等而设立的机构。
3.6软件维护主管
组织、管理和协调维护工作的负责人。
3.7维护管理人员
管理一个或几个软件的维护工作的技术人员。
3.8软件维护人员
具体完成软件维护的工作人员。
4 软件维护的内容与类型
软件维护是在软件产品交付使用之后，为纠正故障，改善性能和其他属性，或使产品适应改变了的环境所进行的修改活动。
4.1 完善性维护
完善性维护是为扩充功能和改善性能而进行修改和扩充，以满足用户变化了的需求。主要内容包括：
s. 为扩充或增强功能而作的修改(如扩充解题范围和算法优化)；
b. 为提高性能而作的修改(如提高精度，节省存储空间等)；
c. 为便于维护而作的修改(如增加注释，改进易读性)。
4.2适应性维护
适应性维护是为适应软件运行环境的变化而作的修改，变化的主要内容包括：
a. 影响系统的规定、法律和规则的变化；
b. 硬件配置的变化，如机型、终端、打印机等的变化；
c. 数据格式或文卷结构的变化；·
d. 系统软件的变化，如操作系统、编译系统或实用程序的变化。
4.3改正性维护
改正性维护是为维持系统操作运行，对在开发过程产生而在测试和验收时没有发现的错误而进行的改正。所必需改正的错误包括：
s. 设计错误；
b. 逻辑错误；
c. 编码错误；
d. 文档错误；
e. 数据错误。
5软件维护过程
软件生存周期中的维护阶段通常起始于软件产品交付给用户、用户验收之时。软件维护活动通常可定义成软件生存周期中前几个阶段的重复。软件维护与软件开发有许多相同的活动，但也有其独特之处：
a. 维护活动限定在已有系统的框架之内完成，维护人员必须在已有的设计和编码结构的约束下作出修改，一般系统越旧，软件维护越困难和越费时。
b. 通常软件维护阶段的时间比软件开发的时间长得多，但一项具体的软件维护一般比该软件的开发时间短得多。
c. 软件开发必须从无到有产生所有测试数据，而软件维护通常可以便用现有的测试数据进行回归测试。有时还要产生新的数据，对软件修改及修改后的影响进行必要的测试。
完成一项软件维护的过程是复杂的。下面按顺序列出完成一项软件维护过程的步骤：
a. 确定修改类型；
b. 确定修改的需要；
c. 提出修改请求；
d. 需求分析；
e. 认可或否决修改请求；
f. 安排任务进度；
g. 设计；
h. 设计评审；
5. 编码修改和排错；
j. 评审编码修改i
k. 测试；
I. 更新文档；
m. 标准审计；
n. 用户验收；
o. 安装后评审修改及其对系统的影响。
其中有几个步骤会经常发生循环，但并不是每次修改都要执行所有的步骤。
6软件维护的控制和改进
软件维护必须有控制地进行，使整个过程中都处于适当的管理和控制之下。除了控制预算、进度和人员，关键在于要由软件维护主管来负责控制和修改系统。
大量的编码在开发过程中并非都考虑到了维护。即使原来是良好设计及良好实现的编码和逻辑，也会因无休止的”决速排错”和修补工作受到破坏。所以一个系统不仅在开发时要考虑到维护，还要在维护时考虑到将来的维护。
6.1 软件维护的控制
软件系统的可维护性常常随着时间的推移而降低，这是许多因素综合的结果。如果没有为软件维护管理制定严格的条例，或条例贯彻不力，许多系统都将蜕变到无法继续维护的地步。
软件维护的目标是保持系统功能和及时、满意地响应用户的请求。
软件维护的控制是保持一个有秩序的维护过程，在这个过程中所有的维护请求要正式提出、评审，给予一个优先级并安排进度。
6.1.1 确立软件维护的策略
软件维护策略的确定是软件维护控制的一个关键步骤。软件维护策略应充分地描述软件维护组织的责任、权利、职能及操作，它应全面地考虑到软件系统和它的环境的任何类型变化。该策略应由软件维护管理机构制定和支持。
软件维护策略必须具体地阐述修改的需要和理由、修改的责任和步骤。规定控制修改软件的过程和步骤，使请求的修改从提议到完成有控制地进行。
为保证维护策略的贯彻执行，需进行评审和审计。
6.1.2 评审和评价所有修改请求
a. 所有的修改要求应先提出正规的书面请求；
b. 评审所有修改请求；
c. 分析和评价修改请求的类型和额度；
d. 考虑对修改的需要程度和它可预见的使用，所有修改都需有充足的理由；
e. 评价修改，以确保与原来的系统设计和用意不冲突，对每个修改都应该仔细考虑其影响；
『. 应特别强调确定所建议的修改是增强还是降低系统的性能；
g·仅当修改的效益超过其成本时方可修改。
6.1.3 为维护安排进度
a. 给每个修改请求分配一个优先级；
b. 为每个认可的修改请求安排进度；
c. 遵守安排的进度。
6.1.4 将代码修改限制于批准的工作范围内
软件维护主管必须监督维护人员的工作，确保只在授权的工作范围内作修改。为有效实行监督，必须将所有的维护活动记入文档，包括修改请求报告和完成修改后的源程序清单，并为系统复原做好安月6。
6.1.5 强制实施文档标准和编码约定
必须贯彻编码约定和文档标准，以对软件维护人员的所有工作进行经常不断的强制性评审和检查。在开始一项新的维护工作之前，应当为更新文档分配足够的时间。
6.2软件维护的改进
可维护性是对软件进行修改的难易程度。一个系统的可维护性必须放在系统的整个生存周期中加以考虑。在系统最初的设计和开发阶段就应考虑到可维护性。
由于维护阶段的处理过程同开发阶段相似，因此许多技术和开发工具也可用在维护阶段。为提高软件可维护性，应在系统的整个生存周期中综合地使用下列技术和原理。
6.2.1 编码指南
编码指南和标准提供了一种提高系统可维护性的结构和框架，它使得系统以一种共同的、更易理解的方式进行开发和维护。编码应遵循下列基本原则。
6.2.1.1 单一高级语言
尽可能只用一种符合标准的高级语言。
6.2.1.2 编码约定
维护人员首先必须克服的困难是编码本身，开发人员和维护人员编写大量源码时很少考虑到以后的维护人员，结果使得源码的可读性很差。源码一定要加注解并用结构化格式编写。下列技术可提高程序的可读性：
n. 尽量采用较简单的方法；
b. 代码的每节开始行使用行首空格把一系列代码分成段。行首空格和字间的间隔是显示从属关系的两种方法；
c. 用有意义的注释来适当地为代码加说明；
d. 使用有意义的变量名，以表达此数据项是什么以及为何要使用它；
e. 避免使用相似的变量名；
『. 在程序的过程／函数之间用参数来传递数据；
g·在变量名中使用数字时，应放在末端。用作程序序标签或标号的数字应按顺序给出；
h.·逻辑上相关的功能应集中安排在同一模块或模块集，尽可能使逻辑流向自顶向下；
5. 避免使用程序语言版本的非标准特征。
6.2.1.3 结构化和模块化
应采用自顶向下的程序设计方法，使程序的静态结构与执行时的动态结构相一致。
模块化是指用一组小的层次结构的单元或例行程序构成程序，其中每个单元或例行程序集完成特定的单一功能。模块性不是仅仅将程序分段，模块的结构必须遵循下列设计原则：
a. 一个模块应只完成一个主要功能；
b. 模块间的相互作用应最少；
c. 一个模块应只有一个入口和一个出口。
6.2.1.4 标准数据定义
一定要为系统制定一组数据定义的标准。这些数据定义可汇集于数据字典。字典项定义了系统中使用的每个数据元素名字、属性、用途和内容。这些名字要尽可能具有描述性和意义。正确一致地定义数据标准，就会大大简化阅读和理解各模块，并确保各模块问的正确通信。
6.2.1.5 良好注释的代码
好的注释可增强源码的可理解性。除了提高程序可读性，注释还有两个重要用途，即提供程序的用途和历史信息、它的起源(作者、生成和修改日期)、子程序名和个数以及输入／输出需求和格式，其次也提供操作控制信息、指示和建议来帮助维护人员理解代码中不清楚的部分。
6.2.1.6编译程序扩展
使用编译程序的非标准特征会严重影响系统的可维护性。如果编译程序更改了，或如果系统必须移至新机器，则以前的编译程序扩展很可能与新的编译程序相冲突。因此最好限制语言的扩展和保留语言基本特征的一致。如果需要使用编译程序扩展，应编制良好文档加以说明。
6.2.2 文档编写指南
一个系统的文档是良好维护的基础，文档编写工作应贯穿系统的整个生存周期。应有计划地建立和及时地更新文档，使维护人员能很快地找到所需的信息。应参照GB 8567编制文档。
文档合格的关键不仅是将必需的信息记录下来，以保持文档的及时更新和一致；而且必须使维护人员能迅速地获得它。对于维护人员来说，具有受控的存取和修改能力的联机文档是文档的最佳形式，如果不能提供联机文档，应保证有一机制使维护人员在任何时候能取用
硬拷贝的文档。
6.2.3 编码和评审技术
本条列出有助于提高软件可维护性的设计和评审技术。
6.2.3.1 自顶向下／自底向上法
应将自顶向下与自底向上的方法组合起来使用。
6.2.3.2 同级评审
同级评审是一种质量保证方法。参加评审人员务必明白他们不是要评价其他程序员的能力或表现，而是分析和评价编码。评审内容应包括可维护性。
6.2.3.3 审查
审查是一种质量评估技术，在软件生存周期中检查各阶段工作，然后产生一个报告指出发现的错误和提出错误改正要求。
6.2.3.4 走查
简单的走查方式是让两个维护人员一起讨论正在进行的工作，复杂的走查方式可以有一份日程表、报告书和一位记录秘书。不论何种方式，目标是通过公开直接的交流，提炼好的主意，修改原来的方案。
6.2.4 测试标准和过程
测试是软件维护的关键部分，因此测试过程必须强调一致性，并以合理的原则为基础，测试计划要定义预期的输入，测试有效的、无效的、预期的和出乎意料的情况。测试要检查程序是否执行预期任务，测试的目的是发现错误，而不是证明错误不存在。
只要有可能，测试过程和测试数据均需由其他人完成，而不是由做系统实际维护的人来完成。
6.3 软件维护人员的管理
管理是改进软件维护过程的主要因素之一。管理必须指导怎样维护软件，行使对整个过程的控制，并保证使用高效的软件维护技术和工具。
为确保实现成功的维护，在维护过程中要有效使用良好的管理技术和方法，必须建立软件维护组织机构。
软件维护机构由维护主管、维护管理机构、维护管理员和维护人员组成。
软件维护机构的主要任务是审批维护请求，制订并实施维护策略，控制和管理维护过程，负责软件维护的审查，组织评审和验收，确保软件维护任务的完成。
软件维护人员的素质对于有效地进行维护是十分重要的，因此应为维护项目选择合格的各级人员。
下面列出挑选软件维护人员和进行维护管理的要点：
a. 维护与开发同等重要，同样具有难度；
b. 维护人员应是合格的、有责任心的人；
c. 维护不能当作初级人员“放任自流”式的培训；
d. 全体人员应轮流分配去做维护和开发工作；
e. 出色的维护工作应同出色的开发工作一样受到奖励；
『. 必须强调对维护人员进行良好的培训；
g·轮换分配，不应让一个系统或一个系统的主要部分成为某个人的专有领地。
7 软件维护与软件宣新设计
维护是一种不断进行的过程，但有时也应考虑是否要重新设计一个软件系统。当一个软件已变得易出差错、效率降低和耗费增大，再对其继续维护的成本／效益比可能会超出重新设计一个系统时，应考虑是否要重新设计一个软件系统。下列特征可帮助管理人员决定是否应重建软件。
7.1 软件经常出错与性能恶化
代码越久，则经常的更新、新的需求和功能增强就越会引起系统的故障和性能恶化。
7.2 程序结构和逻辑流过分复杂
具有部分或全部下列属性的软件通常很难维护，需重新设计：
a. 过多使用DO循环；
b. 过多使用IF语句；
c. 使用不必要的GOTO语句；
d. 过多使用嵌入的常数和文字；
eo 使用不必要的全程变量；
『. 使用自我修改的代码；
g·使用多入口或多出口的模块；
h. 使用相互作用过多的模块；
5. 使用执行同样或相似功能的模块。
7.3过时的代码
过时的代码严重影响新系统的性能发挥。
7.4 在仿真方式下运行
采用仿真方法，常阻止系统发挥全部能力和所有功能。仿真系统往往介于功能上尚可实用，但效率较低这二者之间。
7.5 模块或单个子程序非常大
此时，大模块结构应重新构造，分成较小的、功能上相关的部分，这可增强系统的可维护性。
7.6 过多的资源需求
需要过多资源的系统会成为用户的沉重负担，因此需考虑是增加更多的计算机设备还是重新设计和实现该系统。
7.7 将易变的参数编在代码中
尽可能对程序进行更新，以使它们能从输入模块或一个数据表中读入参数。
7.8 难于拥有维护人员
用低级语言编写的程序，尤其是汇编，需大量的时间和人力去维护。一般这类语言不为人们广泛了解，因此要寻找了解这类语言的维护人员日益困难。
7.9 文档严重不全或失真
文档不全、过时或失真，将造成维护工作极其困难。
7 软件维护与软件宣新设计
维护是一种不断进行的过程，但有时也应考虑是否要重新设计一个软件系统。当一个软件已变得易出差错、效率降低和耗费增大，再对其继续维护的成本／效益比可能会超出重新设计一个系统时，应考虑是否要重新设计一个软件系统。下列特征可帮助管理人员决定是否应重建软件。
7.1 软件经常出错与性能恶化
代码越久，则经常的更新、新的需求和功能增强就越会引起系统的故障和性能恶化。
7.2 程序结构和逻辑流过分复杂
具有部分或全部下列属性的软件通常很难维护，需重新设计：
a. 过多使用DO循环；
b. 过多使用IF语句；
c. 使用不必要的GOTO语句；
d. 过多使用嵌入的常数和文字；
eo 使用不必要的全程变量；
『. 使用自我修改的代码；
g·使用多入口或多出口的模块；
h. 使用相互作用过多的模块；
5. 使用执行同样或相似功能的模块。
7.3过时的代码
过时的代码严重影响新系统的性能发挥。
7.4 在仿真方式下运行
采用仿真方法，常阻止系统发挥全部能力和所有功能。仿真系统往往介于功能上尚可实用，但效率较低这二者之间。
7.5 模块或单个子程序非常大
此时，大模块结构应重新构造，分成较小的、功能上相关的部分，这可增强系统的可维护性。
7.6 过多的资源需求
需要过多资源的系统会成为用户的沉重负担，因此需考虑是增加更多的计算机设备还是重新设计和实现该系统。
7.7 将易变的参数编在代码中
尽可能对程序进行更新，以使它们能从输入模块或一个数据表中读入参数。
7.8 难于拥有维护人员
用低级语言编写的程序，尤其是汇编，需大量的时间和人力去维护。一般这类语言不为人们广泛了解，因此要寻找了解这类语言的维护人员日益困难。
7.9 文档严重不全或失真
文档不全、过时或失真，将造成维护工作极其困难。
一、工程建设行业标准《建筑地基处理技术规 范》JGJ79-2002 ３．０．５按地基变形设计或应作变形验算且需进行地基处理的建筑物或构筑物，应对处理后的地基进行变形验算。 ３．０．６受较大水平荷载或位于斜坡上的建筑物及构筑物，当建造在处理后的地基上时，应进行地基稳定性验算。 ４．４．２垫层的施工质量检验必须分层进行。应在每层的压实系数符合设计要求后铺填上层土。 ５．４．２预压法竣工验收检验应符合下列规定： １排水竖井处理深度范围内和竖井底面以下受压土层，经预压所完成的竖向变形和平均固结度应满足设计要求。 ２应对预压的地基土进行原位十字板剪切试验和室内土工试验。 ６．１．２强夯置换法在设计前必须通过现场试验确定其适用性和处理效果。 ６．３．５当强夯施工所产生的振动对邻近建筑物或设备会产生有害的影响时，应设置监测点，并采取挖隔振沟等隔振或防振措施。６．４．３强夯处理后的地基竣工验收时，承载力检验应采用原位测
试和室内土工试验。强夯置换后的地基竣工验收时，承载力检验除应采用单墩载荷试验检验外，尚应采用动力触探等有效手段查明置换墩着底情况及承载力与密度随深度的变化，对饱和粉土地基允许采用单墩复合地基载荷试验代替单墩载荷试验。 ７．４．４振冲处理后的地基竣工验收时，承载力检验应采用复合地基载荷试验。 ８．４．４砂石桩地基竣工验收时，承载力检验应采用复合地基载荷试验。 ９．４．２水泥粉煤灰碎石桩地基竣工验收时，承载力检验应采用复合地基载荷试验。 １０．４．２夯实水泥土桩地基竣工验收时，承载力检验应采用单桩复合地基载荷试验。对重要或大型工程，尚应进行多桩复合地基载荷试验。 １１．１．２水泥土搅拌法用于处理泥炭土、有机质土、塑性指数Ｉｐ大于２５的粘土、地下水具有腐蚀性时以及无工程经验的地区，必须通过现场试验确定其适用性。 １１．３．１５水泥土搅拌法（干法）喷粉施工机械必须配置经国家计量部门确认的具有能瞬时检测并记录出粉量的粉体计量装置及搅拌深度自动记录仪。 １１．４．３竖向承载水泥土搅拌桩地基竣工验收时，承载力检验应采用复合地基载荷试验和单桩载荷试验。 １２．４．５竖向承载旋喷桩地基竣工验收时，承载力检验应采用复
GB 8567－88软件开发主要文档编写规范 本附录中列出了《计算机软件产品开发文件编制指南》GB 8567－88中主要软件文档的编写说明，供编写时参考。这些文档主要是：可行性研究报告、项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、模块开发卷宗、测试计划、测试分析报告、项目开发总结报告。 一、可行性研究报告 l 引言 1.1 编写目的 说明：说明本可行性研究报告的编写目的，指出预期的读者。 1.2 背景 说明： a．所建议开发的软件系统的名称。 b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络。 c．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4 参考资料 列出用得着的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文。 b．属干本项目的其他已发表的文件。 c. 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2 可行性研究的前提 说明对建议开发项目进行可行性研究的前提，如要求、目标、条件、假定和限制等。 2.1 要求 说明对所建议开发软件的基本要求，如： a．功能。 b．性能。 c．输出如报告、文件或数据，对每项输出要说明其特征，如用途、产生频度、接口以及分发对象。 d. 输入说明。系统的输入包括数据的来源、类型、数量、数据的组织以及提供的频度。 e．处理流程和数据流程。用图表的方式表示出最基本的数据流程和处理流程，并输之以叙述。 f. 在安全与保密方面的要求。 g. 同本系统相连接的其他系统。 h. 完成期限。 2.2 目标 说明所建议系统的主要开发目标，如： a. 人力与设备费用的减少。 b. 处理速度的提高。 c. 控制精度或生产能力的提高。
软件设计文档国家标准GB8567-88 一、文档编写标准化 在整个项目开发及使用过程中，应该有完备的文档支持，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性和可追溯性。 完备的文档对软件的开发及使用起了很大的作用。一般要求编写好十三种文档。 1、可行性分析报告 说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。 2、项目开发计划 为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 3、软件需求说明书（软件规格说明书） 对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 4、概要设计说明书 是概要设计阶段的工作总结。主要包括功能分配、模块划分、程序总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理等，为详细设计作好准备。 5、详细设计说明书 着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 6、用户操作手册 详细描述了该软件的功能、性能和用户界面，使用该软件的具体方法等。 7、测试计划 包括测试内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。8、测试分析报告 测试计划的执行情况，对测试结果的分析，提出测试结论。 9、开发进度月报 按月提交的项目进展情况报告。包括计划与实际执行情况的对比、阶段成果、遇到的问题、解决的方法以及下一步的打算。 10、项目开发总结报告 项目完成以后，总结实际执行情况。如进度、成果、资源利用、成本和投入的人力，对项目开发作出评价，总结经验与教训。 11、软件维护手册 主要包括软件系统说明、程序模块说明、操作环境、支持软件说明、维护过程说明等。12、软件问题报告 记录软件出现问题的日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。13、软件修改报告 软件产品投入使用后，发现了需修改、更正的问题，要将出现的问题、修改意见、修改可能出现影响作出详细描述，提交审批。 二、可行性分析报告的撰写要求 可行性研究报告的编写内容要求如下： 1 引言
十一、程序维护手册 1．引言 (1) 1.1编写目的 (1) 1.2开发单位 (1) 1.3定义 (2) 1.4参考资料 (2) 2．系统说明 (2) 2.1系统用途 (2) 2.2安全保密 (2) 2.3总体说明 (2) 2.4程序说明 (2) 3．操作环境 (3) 3.1设备 (3) 3.2支持软件 (3) 3.3数据库 (4) 4．维护过程 (4) 4.1约定 (4) 4.2验证过程 (4) 4.3出错及纠正方法 (5) 4.4专门维护过程 (5) 4.5专用维护程序 (5) 4.6程序清单和流程图 (5) 1．引言 1.1编写目的 【阐明编写手册的目的，指明读者对象。】 1.2开发单位 【说明项目的提出者、开发者、用户和使用场所。】
1.3定义 【列出报告中所用到的专门术语的定义和缩写词的原文。】 1.4参考资料 【列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，以及保密级别，可包括： a.用户操作手册； b.与本项目有关的其他文档。】 2．系统说明 2.1系统用途 【说明系统具备的功能，输入和输出。】 2.2安全保密 【说明系统安全保密方面的考虑。】 2.3总体说明 【说明系统的总体功能，对系统、子系统和作业做出综合性的介绍，并用图表的方式给出系统主要部分的内部关系。】 2.4程序说明 【说明系统中每一程序、分程序的细节和特性。】 2.4.1程序1的说明 2.4.1.1功能 【说明程序的功能。】 2.4.1.2方法 【说明实现方法。】 2.4.1.3输入 【说明程序的输入、媒体、运行数据记录、运行开始时使用的输入数据的类型和存
放单元、与程序初始化有关的入口要求。】 2.4.1.4处理 【处理特点和目的，如： a.用图表说明程序中的运行逻辑流程； b.程序主要转移条件； c.对程序的约束条件； d.程序结束时的出口要求； e.与下一个程序的通信与联结（运行、控制）； f.由该程序产生并供处理程序段使用的输出数据类型和存放单元； g.程序运行所用存储量、类型及存储位置等。】 2.4.1.5输出 【程序的输出。】 2.4.1.6接口 【本程序与本系统其他部分的接口。】 2.4.1.7表格 【说明程序内部的各种表、项的细节和特性。对每张表的说明至少包括： a.表的标识符； b.使用目的； c.使用此表的其他程序； d.逻辑划分，如块或部，不包括表项； e.表的基本结构； f.设计安排，包括表的控制信息。表目结构细节、使用中的特有性质及各表项的 标识、位置、用途、类型、编码表示。】 2.4.1.8特有的运行性质 【说明在用户操作手册中没有提到的运行性质。】 2.4.2程序2的说明 【与程序1的说明相同。以后其他各程序的说明相同。】 3．操作环境 3.1设备 【逐项说明系统的设备配置及其特性。】 3.2支持软件 【列出系统使用的支持软件，包括它们的名称和版本号。】
第一部分系统管理员操作说明 1.1 管理员操作说明 1.1.1管理员登录 功能概述： 管理员登录窗口：管理员通过该步操作才可进入系统进行系统操作 操作方法： 1.打开IE浏览器，输入配送优化大赛软件的访问地址：http://IP:915/，进入之后如图 所示： 2.输入用户名和密码，点击【登录】进入系统选择页面。
3.选择【配送优化大赛软件V1.0】进入系统首页。 1.1.2地图上传 功能概述： 管理员上传一张地图。
操作方法： 1.系统管理员进入主系统，点击【地图上传】按钮进入【地图上传】页面。 2.点击浏览，选择需要上传的地图，点击上传。（下图为上传好的地图） 功能按钮说明： 【浏览】：点击浏览选择地图图片。 【上传】：上传选择的地图。 1.1.3站点维护 功能概述： 管理员对站点进行维护。 操作方法： 1.系统管理员进入主系统，点击【站点维护】按钮进入【站点维护】页面。 2.选定某个客户或支点进行拖动，可随意放置客户和支点的位置，并对支点进行删除（只
能删除未保存的支点）。 3.可对站点添加多个支点（添加支点是为了方便后续线路维护）。 注：红色图标表示：配送中心；绿色图标表示：配送客户；蓝色图标表示：支点。 点击重置所有点，可将之前维护好的站点全部重置。
重置之后的所有站点需要重新部署。 4.站点维护好之后点保存可直接跳转到线路维护页面。 功能按钮说明： 【帮助】：显示帮助信息； 【重置所有点】：点击重置所有点，之前维护好的站点将重置。 【添加支点】：可添加多个支点。 【删除支点】：可删除支点（只能删除未保存的支点）。 【保存】：保存维护好的站点。 1.1.4线路维护 功能概述： 管理员进行线路维护。 操作方法： 1.系统管理员进入主系统，点击【线路维护】按钮进入【线路维护】页面。
工程建设标准简介和工程建设国家标准 一、工程建设标准有什么特点 工程建设标准的特点，取决于工程建设所具有的特殊性。主要包括这样几个方面： 一是建设工程本身的固定性和建设活动的流动性。建设工程只能固定在某个特定的地点，不可移动，建设活动只能围绕这一特定的位置展开，不同的工程决定了从事建设活动的人员和机械设备，不可能永久地围绕在一个地点活动，必然要进行迁移或流动。 二是建设工程的单一性和整体性。绝大多数建设工程因使用功能不同、所处环境不同、建设的目的不同等而各不相同，不可能批量生产，都需要单独设计、单独施工、分别验收等，因此，无论是咨询、设计、施工还是使用管理等，其目标都只能针对单一的工程。而且，在建设活动各方的交易中，投资方不可能通过前期检查工程来确定是否符合自身的投资意图，只能根据自身的投资意图，选择合适的合作者或建设方案来实现，而且实现自身投资意图的 - 1 -
建设工程，无论是一个住宅小区、一座电站、一条高速公路，还是一幢办公大楼，甚至是一次家庭装饰装修，都是一个不可分割的整体，都需要从整体的角度综合考虑其布局、设计和建造等。 三是企业的专业性和建设活动的相对独立性。由于建设工程自身的复杂性，建设企业的专业性特点十分明显，工程勘察、规划、设计、施工、监理、维修等大部分都是由专业性企业分别完成的，虽然我国的工程总承包单位逐渐增多，但实际运作过程中，工程的各建设环节也都分别是由其合作的或内部的专业企业或机构分别完成的。建设工程具有阶段性，不同的阶段，建设工程具有不同的形态，例如：在可研阶段，特定的建设工程表现为咨询机构的可行性研究报告，或其他的咨询论证材料等；在招标阶段，表现的是招标代理单位提供的招标书、评标定标的分析报告、合同文本或咨询机构的标底、造价估算报告等；在勘察设计阶段，可以是勘察报告或设计方案、设计图纸；在施工阶段，可以是一幢建筑物、一个住宅小区、工业群体建筑、一段铁路等。不同的建设阶段，不仅建设活动的特点和人员差别很大，而且都是由不同实施主体分别独立完 - 2 -
软件工程国家标准、行业标准一览摘自计算机软件工程规范国家标准汇编2003 DZ/T 0169-1997 物探化探计算机软件开发规范 GB 17917-1999 商场管理信息系统基本功能要求 GB 8566-1988 计算机软件开发规范(已为GB/T8566-1995替代) GB/T 11457-1995 软件工程术语 GB/T 12504-1990 计算机软件质量保证计划规范 GB/T 12505-1990 计算机软件配置管理计划规范 GB/T 14079-1993 软件维护指南 GB/T 14085-1993 信息处理系统计算机系统配置图符号及约定 GB/T 15532-1995 计算机软件单元测试 GB/T 15538-1995 软件工程标准分类法 GB/T 15853-1995 软件支持环境 GB/T 16260-1996 信息技术软件产品评价质量特性及其使用指南 GB/T 16680-1996 软件文档管理指南 GB/T 17544-1998 信息技术软件包质量要求和测试 GB/T 17917-1999 商场管理信息系统基本功能要求 GB/T 18234-2000 信息技术C ASE工具的评价与选择指南 GB/T 18491.1-2001 信息技术软件测量功能规模测量第1部分：概念定义 GB/T 18492-2001 信息技术系统及软件完整性级别 GB/T 18905.1-2002 软件工程产品评价第1部分: 概述 GB/T 18905.2-2002 软件工程产品评价第2部分: 策划和管理 GB/T 18905.3-2002 软件工程产品评价第3部分: 开发者用的过程 GB/T 18905.4-2002 软件工程产品评价第4部分: 需方用的过程 GB/T 18905.5-2002 软件工程产品评价第5部分: 评价者用的过程 GB/T 18905.6-2002 软件工程产品评价第6部分: 评价模块的文档编制 ★GB/T 8566-1995 信息技术软件生存期过程(已为GB/T8566-2001替代) GB/T 8566-2001 信息技术软件生存周期过程 GB/T 9385-1988 计算机软件需求说明编制指南 GB/T 9386-1988 计算机软件测试文件编制规范 GB/Z 18493-2001 信息技术软件生存周期过程指南 GB/Z 18914-2002 信息技术软件工程CASE工具的采用指南 GJB 1091-1991 军用软件需求分析 GJB 1419-1992 军用计算机软件摘要 GJB 2115-1994 军用软件项目管理规程 GJB 2255-1994 军用软件产品 GJB 3181-1998 军用软件支持环境选用要求 GJB 437-1988 军用软件开发规范 GJB 438-1988 军用软件文档编制规范 GJB 438A-1997 武器系统软件开发文档 GJB 439-1988 军用软件质量保证规范 GJB/Z 102-1997 软件可靠性和安全性设计准则 GJB/Z 115-1998 GJB 2786《武器系统软件开发》剪裁指南 GJB/Z 117-1999 军用软件验证和确认计划指南
系统中涉及的所有规范、标准或材料规格（包括一切有效的补充或附录）均采用最新版本，即以招标方与投标方签订供货合同之日作为采用最新版本的截止日期。若发现本规范书与参照的文献之间有不一致之处，我方向贵方书面指明，并由贵方确定采用哪一个规范。 我方所有设备的设计，制造，检查，试验及特性除木规范中规定的特别标准外，都遵照适用的最新版中国国家标准（GB）以及国际单位制（SI） O 我方提出的等同标准应不低于贵方要求的标准并征得贵方的认可，我方应遵循的标准至少包括： 《中华人民共和国计算机信息系统安全保护条例》 GB2887-89 计算站场地技术条件 GB/T 9361-1988 计算机场地安全要求 GB4943 —90 信息技术设备（包扌舌电气事务设备）的安全 GB/T -1995 中华人民共和国计算机信息安全保护条例 GB18030-2000 信息交换用汉字编码字符集基本集的扩充 GB1526-89信息处理一数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文字编制符及约定
GB8566计算机软件开发规范 GB9385计算机软件需求说明编制指南 GB9386计算机软件测试文件编制规范 GB/T13502信息处理、程序构造及其表示法的约定 GB/T14085信息处理系统计算机系统配置图符号及约定GB10112确立术语的一般原则与方法 GB/T13725确立术语数据库的一般原则与方法 SJ/T11293企业信息化技术规范 GB/T12504-90计算机软件配置管理计划规范 GB/T13702-92计算机软件分类与代码 GB/T14079-93软件工程术语 GB/T15532-1995计算机软件单元测试 GB/T 14394-1993《计算机软件可靠性和可维护性规范》GB/T 2887-1989《计算机软件质量保证规范》 GB/T 8566-2000《信息技术软件生成期过程》
软件维护手册 主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。 1 引言 1.1 编写目的 阐明编写手册的目的并指明读者对象。 1.2 项目背景 说明项目的提出者、开发者、用户和使用场所。 1.3 定义 列出报告中所用到的专门术语的定义和缩写词的原意。 1.4 参考资料 列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，及保密级别，可包括：用户操作手册；与本项目有关的其他文档。
2 系统说明 2.1 系统用途 说明系统具备的功能，输入和输出。 2.2 安全保密 说明系统安全保密方面的考虑。 2.3 总体说明 说明系统的总体功能，对系统、子系统和作业做出综合性的介绍，并用图表的方式给出系统主要部分的内部关系。 2.4 程序说明 说明系统中每一程序、分程序的细节和特性。 2.4.1 程序 1 的说明 ? 功能：说明程序的功能。 ? 方法：说明实现方法。 ? 输入：说明程序的输入、媒体、运行数据记录、运行开始时使用的输入数据的类型和存放单元、与程序初始化有关的入口要求。 ? 处理：处理特点和目的，如：用图表说明程序的运行的逻辑流程；程序主要转移条件；对程序的约束条件；程序结束时的出口要求；与下一个程序的通信与联结（运行、控制）；由该程序产生并茶馆处理程序段使用的输出数据类型和存放单元；程序运行存储量、类型及存储位置等。 ? 输出：程序的输出。 ? 接口：本程序与本系统其他部分的接口。 ?表格：说明程序内部的各种表、项的细节和特性。对每张表的说明至少包括：表的
标识符；使用目的；使用此表的其他程序；逻辑划分，如块或部，不包括表项；表的基本结构；设计安排，包括表的控制信息。表目结构细节、使用中的特有性质及各表项的标识、位置、用途、类型、编码表示。 ? 特有的运行性质：说明在用户操作手册中没有提到的运行性质。 2.4.2 程序 2 的说明 与程序1 的说明相同。以后的其他各程序的说明相同。
系统运维手册
1、目的 (3) 2、适用围 (3) 3、服务器及数据库概述 (3) 3.1 服务器概述 (3) 3.2 数据库概述 (3) 4、系统服务程序的详细说明 (3) 4.1系统服务程序的构成 (3) 4.2 系统服务程序的启动、关闭及维护管理 (4) 4.2.1 dhcp主服务 (4) 4.2.2 dhcp从服务 (5) 4.2.3 web管理模块 (5) 5、服务器硬件维护（略） (6) 6、windows 2003系统的日常维护 (6) 6.1 定期检查磁盘空间 (6) 6.2 维护系统注册表 (7) 6.3 定期备份系统注册表 (7) 6.4清理system路径下的无用的dll文件 (7) 7、备份策略 (8) 7.1 备份方式 (8) 7.2 备份计划 (8) 7.3 常见故障恢复 (8) 9、数据库的日常维护 (11) 9.1 检查数据库的基本状况 (11) 9.2 检查数据库日志文件 (11) 9.4监控数据库表空间的使用情况（字典管理表空间） (11) 9.4.1 判断是否需要碎片整理 (11) 10、命令解释 (12)
1、目的 楚天行消费卡管理系统运营支撑系统使用的服务器中，服务器均采用windows xp操作系统,数据库版本为：sql server 2000，随着业务的开展， sql server 数据库中存储的数据量也不断增大，这样操作系统和数据库的日常维护就显得十分重要。 本手册详细描述了程序模块，windows xp操作系统，负载平衡及sql server 数据库等日常检查的主要步骤，指导现场工程师对其进行监控和维护。 2、适用围 使用者为网e通宽带网络运营支撑系统维护工程师 3、服务器及数据库概述 3.1 服务器概述 3.2 数据库概述 数据库软件分别安装在主服务器上。 4、系统服务程序的详细说明 4.1系统服务程序的构成
工程建设国家标准管理办法 建设部令第24号 《工程建设国家标准管理办法》已于一九九二年十二月二十九日经第二十八次部常务会议通过，现予发布，自发布之日起施行 总则 第一条为了加强工程建设国家标准的管理，促进技术进步，保证工程质量，保障人体健康和人身、财产安全，根据《中华人民共和国标准化法》《中华人民共和国标准化法实施条例》和国家有关工程建设的法律、行政法规，制定本办法。 第二条对需要在全国范围内统一的下列技术要求，应当制定国家标准： （一）工程建设勘察、规划、设计、施工（包括安装）及验收等通用的质量要求； （二）工程建设通用的有关安全、卫生和环境保护的技术要求； （三）工程建设通用的术语、符号、代号、量与单位、建筑模数和制图方法； （四）工程建设通用的试验、检验和评定等方法； （五）工程建设通用的信息技术要求； （六）国家需要控制的其他工程建设通用的技术要求。 法律另有规定的，依照法律的规定执行。 第三条国家标准分为强制性标准和推荐性标准。 下列标准属于强制性标准： （一）工程建设勘察、规划、设计、施工（包括安装）及验收等通用的综合标准和重要的通用的质量标准； （二）工程建设通用的有关安全、卫生和环境保护的标准； （三）工程建设重要的通用的术语、符号、代号、量与单位、建筑模数和制图方法标准； （四）工程建设重要的通用的试验、检验和评定方法等标准； （五）工程建设重要的通用的信息技术标准； （六）国家需要控制的其他工程建设通用的标准。
强制性标准以外的标准是推荐性标准。 国家标准的计划 第四条国家标准的计划分为五年计划和年度计划。五年计划是编制年度计划的依据；年度计划是确定工作任务和组织编制标准的依据。 第五条编制国家标准的计划，应当遵循下列原则： （一）在国民经济发展的总目标和总方针的指导下进行，体现国家的技术、经济政策； （二）适应工程建设和科学技术发展的需要； （三）在充分做好调查研究和认真总结经验的基础上，根据工程建设标准体系表的要求，综合考虑相关标准之间的构成和协调配套； （四）从实际出发，保证重点，统筹兼顾，根据需要和可能，分别轻重缓急，做好计划的综合平衡。 第六条五年计划由计划编制纲要和计划项目两部分组成。其内容应当符合下列要求： （一）计划编制纲要包括计划编制的依据、指导思想、预期目标、工作重点和实施计划的主要措施等； （二）计划项目的内容包括标准名称、制订或修订、适用范围及其主要技术内容、主编部门、主编单位和起始年限等。 第七条列入五年计划的国家标准制订项目应当落实主编单位、主编单位应当具备下列条件： （一）承担过与该国家标准项目相应的工程建设勘察、规划、设计、施工或科研任务的企业、事业单位； （二）具有较丰富的工程建设经验、较高的技术水平和组织管理水平，能组织解决国家标准编制中的重大技术问题。 第八条列入五年计划的国家标准修订项目，其主编单位一般由原国家标准的管理单位承担。 第九条五年计划的编制工作应当按下列程序进行： （一）国务院工程建设行政主管部门根据国家编制国民经济和社会发展五年计划的原则和要求，统一部署编制国家标准五年计划的任务；
国家标准(GB 8567－88)软件开发主要文档编写规范 本附录中列出了《计算机软件产品开发文件编制指南》GB 8567－88中主要软件文档的编写说明，供编写时参考。这些文档主要是：可行性研究报告、项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、模块开发卷宗、测试计划、测试分析报告、项目开发总结报告。 一、可行性研究报告 l 引言 1.1 编写目的 说明：说明本可行性研究报告的编写目的，指出预期的读者。 1.2 背景 说明： a．所建议开发的软件系统的名称。 b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络。 c．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4 参考资料 列出用得着的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文。 b．属干本项目的其他已发表的文件。 c. 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2 可行性研究的前提 说明对建议开发项目进行可行性研究的前提，如要求、目标、条件、假定和限制等。 2.1 要求 说明对所建议开发软件的基本要求，如： a．功能。 b．性能。 c．输出如报告、文件或数据，对每项输出要说明其特征，如用途、产生频度、接口以及分发对象。 d. 输入说明。系统的输入包括数据的来源、类型、数量、数据的组织以及提供的频度。 e．处理流程和数据流程。用图表的方式表示出最基本的数据流程和处理流程，并输之以叙述。 f. 在安全与保密方面的要求。 g. 同本系统相连接的其他系统。 h. 完成期限。 2.2 目标 说明所建议系统的主要开发目标，如： a. 人力与设备费用的减少。 b. 处理速度的提高。 c. 控制精度或生产能力的提高。
【最新整理，下载后即可编辑】 密级：内部公开 文档编号：LANDUNTEC_SD_TEMP_08 版本号：V1.0 分册名称：第1册/共1册 系统维护手册 中国普天信息产业股份有限公司 --------------------------------------------------------------------- 中国普天信息产业股份有限公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。 文件更改摘要：
目录 1. 适用范围 (2) 2. 系统运行环境 (2) 2.1. 数据库环境 (2) 2.2. Web环境 (2) 3. 系统运维计划 (3) 3.1. 运维目标 (3) 3.2. 运维内容 (3) 3.3. 运维服务 (3) 4. 各个设备工作状态判断标准及疑问 (4) 4.1. 慧瑞通楼宇呼叫单元机，对讲分机状态监控 (4) 4.2. Ipc广播设备状态监控 (4) 4.3. 电梯运行状态监控 (4) 4.4. 摄像头运行状态监控 (4) 4.5. 停车场系统系统实时控制及监控 (5)
1.适用范围 该手册适用于系统管理员及系统维护人员适用。 2.系统运行环境 2.1.数据库环境 服务器信息： 安装软件：
数据库配置： Jdk及mysql软件是分别安装在22服务器和26 服务器上的。Mysql的数据库管理信息配置如下： 全局数据库名：cms 数据库IP:10.1.8.26 数据库别名：cms 数据库管理员用户：root 密码： 2.2.Web环境 Web服务器为虚拟操作系统。 系统信息： 服务器网络配置： IP地址：10.1.8.22 IP的子网掩码：255.255.255.0 默认网关：10.1.8.1
动物园动物管理系统软件维护手册 一:引言 1.1：目的 由于动物园动物管理调度大，软件工作量大，日常维护必不可少，该手册向客户提供系统存在的问题及原因或解决方法。 1.2：项目背景 该项目由中国国家动物园管理层提出，由东北大学秦皇岛分校控制工程学院负责软件的开发和调试。用户群体为全国各动物园，使用于实时统计动物园动物调度，安排。 1.3：定义 下面的定义将被用于该文档。 缩写或术语定义或全名 二：系统说明 2.1：系统用途 系统具有各种动物数据实时采集，实时控制决策，实时控制输出，对所有动物的信息同一管理。 2.2：安全保密 为使系统安全保密采用最新保密技术，绝对具有专利唯一性。 2.3：总体说明 说明系统的总体功能，对系统、子系统和作业做出综合性的介绍，并用图表的方式给出系统主要部分的内部关系。 三：操作环境 网络版版服务器 操作系统：Windows 2000 server中文版、W2ksp4_cn(Windows 2000 pack4 包)数据库：SQL Server 2000企业版 硬件板卡驱 动： 主板驱动、显示卡驱动、声卡驱动、网卡驱动 支持软件：OFFICE2000、Winrar3.0、五笔字型输入法、微软拼音输入法3.0（或其他拼音输入法） 网络版工作站 操作系统：Windows 2000 Professional中文版、W2ksp4_cn(windows 2000 pack4 包) 硬件板卡驱动： 主板驱动、显示卡驱动、声卡驱动、网卡驱动、采集器安装、采集卡驱动、加密狗驱动 支持软件：Directx 9、OFFICE2000、Mdplayer 9、Winrar3.0、Acrobat5.1、DivX(图
工程建设标准编写规定 第一章总则 第一条为加强工程建设标准编制工作的管理, 统一工程建设标准编写要求, 确保工程建设标准编写质量, 有利于正确理解和使用标准, 制定本规定。 第二条本规定适用于工程建设国家标准、行业标准和地方标准( 以下统称为标准) 的编写。工程建设企业标准的编写, 可参照本规定执行。 第三条标准编写应做到格式规范, 逻辑严谨, 结构清晰, 用词简明, 规定明确。 第四条在编写标准条文的同时, 应编写标准的条文说明, 并应同时出版, 配套使用。 第五条标准的正式文本应由标准批准部门指定的出版机构出版。标准局部修订内容和强制性条文的正式文本, 可在标准批准部门指定的媒体上刊登。
第二章标准构成 第一节一般规定 第六条标准应由前引部分、正文部分和补充部分构成。 第七条标准各部分的构成包括下列内容: 一、前引部分 １、封面; ２、扉页; ３、公告; ４、前言; ５、目次。 二、正文部分 １、总则; ２、术语和符号; ３、技术内容。 三、补充部分 １、附录; ２、标准用词说明; ３、引用标准名录。 第二节前引部分 第八条标准封面应包括标准类别、检索代号、分类符号、标准编
号、标准名称、英文译名、发布日期、实施日期、发布机构等要素。行业标准和地方标准的封面还应包括标准备案号。 第九条标准编号由标准代号、发布标准的顺序号、发布标准的年号组成。同一类或同一领域标准的代号应统一。当标准中无强制性条文时, 标准代号后应加”/T”表示。例如: 某项有强制性条文的国家标准编号采用”GB 50×××-20××”表示, 某项无强制性条文的国家标准编号采用”GB/T 50×××-20××”表示。 第十条标准名称应符合下列规定: 一、标准名称应简练明确地反映标准的主题内容; 二、标准名称宜由标准的对象、用途和特征名三部分组成; 例如: 钢结构设计规范 ( 对象) ( 用途) ( 特征名) 三、标准应根据其特点和性质, 采用”标准”、”规范”或”规程”作为特征名; 四、标准名称应有对应的英文译名。 第十一条标准发布公告应包括下列主要内容: 一、标题及公告号; 二、标准名称和编号; 三、标准实施日期; 四、有强制性条文的, 应列出强制性条文的编号; 全文强制的, 用文字表明; 五、全面修订的标准应列出被替代标准的名称、编号和废止日期;
软件维护手册主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。 引言 编写目的 阐明编写手册的目的并指明读者对象。 项目背景 定义 说明系统的总体功能，对系统、子系统和作业做出综合性的介绍，并用图表的方式给出系统主要部分的内部关系。 程序说明 说明系统中每一程序、分程序的细节和特性。 程序1的说明 ● 功能：说明程序的功能。 ● 方法：说明实现方法。
● 输入：说明程序的输入、媒体、运行数据记录、运行开始时使用的输入数据的类型和存放单元、与程序初始化有关的入口要求。 ● 处理：处理特点和目的，如：用图表说明程序的运行的逻辑流程；程序主要转移条件；对程序的约束条件；程序结束时的出口要求；与下一个程序的通信与联结（运行、控制）；由该程序产生并茶馆处理程序段使用的输出数据类型和存放单元；程序运行存储量、类型及存储位置等。 ● 输出：程序的输出。 ● 接口：本程序与本系统其他部分的接口。 ●表格：说明程序内部的各种表、项的细节和特性。对每张表的说明至少包括：表的标识符； 表示。 ● 程序2 设备 总体特征 如标识符、使用这些数据库的程序、静态数据、动态数据；数据库的存储媒体；程序使用数据库的限制。 结构及详细说明 ● 说明该数据库的结构，包括其中的记录和项。 ● 说明记录的组成，包括首部或控制段、记录体。
● 说明每个记录结构的字段，包括：标记或标号、字段的字符长度和位数、该字段的允许值范围。 ● 扩充：说明为记录追加字段的规定。 维护过程 约定 列出该软件系统设计中所使用全部规则和约定，包括：程序、分程序、记录、字段和存储区的标识 出现在 过程。 的 的目录， 程序清单和流程图 引用或提供附录给出程序清单和流程图。
湖南省地方税务局规费管理系统 维护手册 长沙海蝶计算机科技开发有限公司
一、适用范围 该手册适用于系统管理员及系统维护人员适用。 二、系统运行环境 2.1数据库环境 使用刀片3和刀片4这两块配置一模一样硬件来作为 ORACEL RAC 环境的两个物理节点。 在刀片系统配置两块物理千兆网卡作为数据库RAC实用网卡。 服务器信息： 网络配置： 其中公共IP的子网掩码： 安装软件： 数据库配置： grid 及 database 软件的安装操作全部都在 RAC1 服务器上进行，RAC2 服务器上的软件都是通过RAC1 通过局域网共享来完成安装。其数据库管理信息配置如下： 全局数据库名：orcl
数据库IP: 数据库别名： 所有账户统一管理口令： Asm专用的ASMSNNP口令： 数据库创建用户：密码： 网络拓扑图 2.2 Web环境 Web服务器为虚拟操作系统。 网络配置： 主机名： IP地址： IP的子网掩码： 默认网关： 安装软件： Weblogic配置： Weblogic管理用户：管理密码： 三、系统运维计划 3.1运维目标 地方税务局规费管理系统运维管理的目标是保证系统平台的正常、可靠、高速运行，保证对突发事
件、需求变更进行快速响应，保证规费管理系统的信息完整。 3.2运维内容 系统平台维护： 保证操作系统、数据库系统、中间件、其他支撑系统应用的软件系统及网络协议等安全性、可靠性和可用性而实施的维护与管理；及时排除系统故障；每月对系统平台进行一次巡检，及时消除故障隐患，保障系统的安全、稳定、持续运行。 应用系统管理和维护： 在系统维护过程中采取各种技术手段及时排除系统故障，保证系统及相应接口的安全性、可靠性和可用性。及时消除系统可能存在的安全隐患和威胁、根据需求更新或变更系统功能。 数据储存设施管理和维护： 为保证数据存储设施、如服务器设备、集群系统、存储网络及支撑数据存储设施运行的软件平台的安全性、可靠性和可用性，保证存储数据的安全。定期对系统的性能，确认数据存储的安全，及时消除故障隐患，保障系统安全、稳定、持续运行。 数据管理和维护： 数据管理是系统应用的核心。为保证数据存储、数据访问、数据通信、数据交换的安全，每月对数据的完整性、安全性、可靠性进行检查。 3.3 运维服务 在维护期间，具备灵活、多样的通信手段，提供5*8小时的响应服务，保证用户能及时得到技术支持。对于影响系统运行的故障，3小时内派人到现场解决，对于一般性故障，提供电话或E-Mail等方式解决；在维护期之外，由于软件原因引起的故障，由开发商提供升级解决； 技术支持热线为用户提供全面的技术服务，负责记录、解答用户的问题。 （1）公司不断地向用户传递最新的技术和产品，主动提供版本升级，并保证签定合同规定的期限内的系统维护及版本更新，同时向用户提供长期的技术咨询和服务。 （2）在系统的正常运行中出现的严重问题需现场解决的做到： ?公司做到1小时内响应，3小时内到现场服务。 ?其它情况根据距离远近尽快到现场服务。 （3）负责为用户到现场安装并调试公司的应用软件，直到系统能正常运行。
CreatMap 地理信息共享服务云平台软件工程标准规范 河北省制图院 2015年1月30日
1.前言 1.1项目背景 当前，我国国家信息化建设与应用不断深入，网络化地理信息应用如同雨后春笋，政府部门和社会大众使用地理信息的方式与频率正发生翻天覆地的变化。针对这一重大应用需求，国家测绘局认真学习和贯彻落实科学发展观，做出了建设国家地理信息公共服务平台（以下简称“公共服务平台”）的战略性决策。 CreatMap 地理信息共享服务云平台是河北省地理信息局下属的河北省制图院自主研发的并拥有自主知识产权的新一代地理信息公共服务平台，平台以促进地理信息服务大局、服务社会、服务民生为目标，为政府、企事业单位、社会公众提供统一、高效的基础地理信息服务。 1.1.1软件系统名称 CreatMap 地理信息共享服务云平台，是依托地理信息数据，通过在线方式满足政府部门、企事业单位和社会公众对地理信息和空间定位、分析的基本需求，具备个性化应用的二次开发接口和可扩展空间，是实现地理信息应用服务功能的数据、软件及其支撑环境的总称。 1.1.2政策依据 1) 《国务院关于加强测绘工作的意见》（国发[2007]30号）：要切实提高测绘保障能力和服务水平，构建基础地理信息公共平台，更好地满足政府、企业及人民生活等方面对基础地理信息公共产品服务的迫切需要。 2) 《全国基础测绘中长期规划纲要》（2006年国务院批准发布）：到2010年，我国形成一批具有影响力的基础测绘公共产品；到2020年，要实现服务网络化社会化。国家测绘局在《测绘事业发展第十一个五年规划纲要》中指出要以地理信息为基础平台整合社会、经济和人文等信息，促进各类信息资源的共享和高效开发利用，到2010年初步实现基础地理信息服务网络化。
1、《建筑设计防火规范》GBJ50016-2006； 2、《高层民用建筑设计防火规范》GB50045-2005； 3、《汽车库、修车库、停车场设计防火规范》GB50067-1997； 4、《村镇建筑设计防火规范》GBJ39-1990； 5、《火力发电厂与变电所设计防火规范》GB50229-2006； 6、《石油化工企业设计防火规范》GB50160-1999； 7、《石油天然气工程设计防火规范》GB50183-2004； 8、《人民防空工程设计防火规范》GB50098-2001； 9、《建筑内部装修设计防火规范》GB50220-2001； 10、《飞机库设计防火规范》GB50284-98； 11、《自动喷水灭火系统设计规范》GB50084-2005； 12、《火灾自动报警系统设计规范》GB50116-98； 13、《建筑灭火器配置设计规范》GB J140-2005； 14、《低倍数泡沫灭火系统设计规范》GB50151-2000； 15、《气体灭火系统施工及验收规范》GB50163-97； 16、《二氧化碳灭火系统设计规范》GB50193-1999； 17、《高倍数、中倍数泡沫灭火系统设计规范》GB50196-93； 18、《水喷雾灭火系统设计规范》GB50219-95； 19、《固定消防炮灭火系统设计规范》GB50338-2003； 20、《汽车加油加气站设计与施工规范》GB50156-2006； 21、《泡沫灭火系统施工及验收规范》GB50281-2006； 22、《消防通讯指挥系统设计规范》GB50313-2000；
23、《干粉灭火系统设计规范》GB50347-2004； 24、《储罐区防火堤设计规范》GB50351-2005； 25、《建筑内部装修防火施工及验收规范》GB50354-2005； 26、《城市消防站建设标准》（修订）建标[2006]42号； 27、《石油库库设计规范》GB50074-2002； 28、《城镇燃气设计规范》GB50028-2006； 29、《爆炸和火灾危险环境电力装置设计规范》GB50058-1992； 30、《地铁设计规范》GB50157-2003； 31、《火灾自动报警系统施工及验收规范》GB50166-1992； 32、《自动喷水灭火系统施工及验收规范》GB50261-2005； 33、《气体灭火系统设计规范》GB50370-2005
合同编号：WU-PO-9183-607 软件开发合同标准样本 In Order T o Protect The Legitimate Rights And Interests Of Each Party, The Cooperative Parties Reach An Agreement Through Common Consultation And Fix The Responsibilities Of Each Party, So As T o Achieve The Effect Of Restricting All Parties 甲方：_________________________ 乙方：_________________________ 时间：________年_____月_____日 A4打印/ 新修订/ 完整/ 内容可编辑
软件开发合同标准样本 使用说明：本合同资料适用于协作的当事人为保障各自的合法权益，经过共同协商达成一致意见并把各方所承担的责任固定下来，从而实现制约各方的效果。资料内容可按真实状况进行条款调整，套用时请仔细阅读。 软件开发合同 合同编号：____________ 甲方：__________ 法定住址：_____________ 法定代表人：___________ 职务：__________ 委托代理人：___________ 身份证号码：___________ 通讯地址：_____________ 邮政编码：_____________ 联系人：_______________
电话：__________ 电挂：__________ 传真：__________ 帐号：__________ 电子信箱：_____________ 乙方：__________ 法定住址：_____________ 法定代表人：___________ 职务：__________ 委托代理人：___________ 身份证号码：___________ 通讯地址：_____________ 邮政编码：_____________ 联系人：_______________ 电话：__________