金融电子化系统建设及必备文件
1 金融电子化系统的建设
1．1 金融电子化系统的建设
金融电子化系统的建设同其他行业电子化系统的建设一样，主要是采用“生命周期法”进行。“生命周期法”有时也叫做分阶段建设法或分步骤建设法，其主要思想是将一个庞大复杂的系统按照时间顺序和所采用的工程方法分解成若干个容易实现的阶段或任务，一个阶段一个阶段或一个任务一个任务的去实现。通常，前一个阶段是后一个阶段的工作基础，后一个阶段只有在前一个阶段圆满完成后才能正式开始。因此，通过这种系统工程方法，无论多么大的工程或多么复杂的系统，都可以有条不紊的，分步骤分阶段建设成功。
系统建设的周期，通常可划分为项目起动、可行性研究、系统分析、系统设计、程序设计、系统测试、投产应用和运行维护等八个阶段。如果将生命周期中的保个阶段分布在时间横坐标上，而将工作量、人力需求、计算机资源或资金需求等，以垂直方向的纵坐标表示，可以画出如图1-1所示的系统建设分阶段控制图。
工作量 工作量曲线
人力
计算机资源 人力曲线
计算机资源
起动 可行性 系统 系统 程序 系统 应用 维护 （时间阶段）
研究 分析 设计 设计 测试 投产
图1-1 系统建设分阶段控制图
图中的各种曲线表明：系统建设每个阶段任务所需的人力、计算机资源等都可以给出定量化的估计。所以，每个阶段都可以在可控制的范围内进行，从而保证了任何大系统建设任务的高效完成。
银行管理信息系统自身，由于其业务特点所致，可以划分成柜台业务处理子系统、联行清算业务处理子系统、内部管理子系统和新型服务子系统，每个子系统同样还可以进一步划分为若干个子系统。如柜台业务处理子系统又可以再次划分为存款、代款、储蓄、汇兑等多种业务处理系统。而对于每种电子化业务处理系统的建设，都可以采用生命周期法进行管理，它是保质保量完成金融电子化系统建设的科学方法。
1．2 金融电子化系统建设必备文件的含义及作用
科学的方案管理法是电子化系统建设顺利完成的重要食品店，与生命周期法配套的方案管理的核心是整个周期中的各种文件。按照生命周期法要求，每个阶段的开始都必须以前阶段形成的文件为依据。任何阶段的结束，必须以产生该阶段所规定的文件为结果。仅当这些文件被管理部门批准通过后，才能认为该阶段工作的结束，也才可以开始下阶段的工作。因此，金融电子化系统建设中的必备文件，是具体组织系统实施部门在建设过程中必须向其管理部门提交的重要信息文件，它是开发人员之间、或者技术人员与业务部门之间互相沟通的一组“通信工具”和管理工作“蓝图”，通过这组文件对金融电子化系统建设实施科学的方案管理。因此，金融电子化系统建设必备文件的编写，必须严格遵照标准、规范的规定，它是系统建设的重要的基础工作之一。
在金融电子化系统建设中，需要形成的文件很多，且系统建设必备文件又不同于一般的技术文件，它们要从管理的角度，反映系统建设的过程。在系统建设的各个阶段，为动手术总结及协调的需要，还必须产生许多详细的技术文件，而系统建设必备文件则是在这些技术文件的基础上，总结系统建设各阶段工作的管理文件，文件对象主要是系统建设的各级管理部门及人员。通过系统建设的必备文件，银行有关管理部门可以审查系统设计方案、检查系统建设进展情况、监督系统的建设部门按照科学的、规范的步骤和方法进行系统建设。
2 金融电子化系统建议阶段划分及必备文件
2．1金融电子化系统建设阶段划分
本书所采用的系统建设各个阶段的划分方法，系根据系统工程的基本方法及目前国内有关单位从事金融电子化系统建设的经验而进行的。金融电子化系统从计划建设到建成投产，划分为下述六个阶段：
（1） 系统起动阶段；
（2） 可行性研究阶段；
（3） 系统分析阶段；
（4） 系统设计阶段；
（5） 系统实施阶段；
（6） 系统投产应用阶段。
根据金融电子化系统的工程规模和建设周期的长短，为了管理方便，对具体系统建设阶段的划分有时可能有些差别，如当系统规模很大时，又将系统实施阶段再划分成程序设计和系统测试两个阶段；而当系统规模很小时，又可能将系统分析和系统设计两个阶段合并。但是，系统建设所经历的全过程是基本相同的。因此，这里所述的阶段划分只是指一般而言，各部门应根据各系统的情况，在具体建设时根据实际情况进行适当调整。
2．2 系统起动阶段
任何系统项目的起步，通常由三种因素决定：一是领导直接批示，二是业务部门的需求经领导批准后要求执行，三是技术部门提出要求。对于前二者，领导的有关批示就是系统起动的重要文件。对于后者，技术人员应根据金融电子化系统建设的需求，选择那些社会和经济效益显著，具有生命力的系统项目，结合银行内外环境条件实际，进行广泛的调查研究，全面地收集资料，在基本了解项目建设所具备的基本技术和经济条件后，提出《项目建设书》，向领导推荐建设项目。
上级领导的有关批件或经领导批准的《项目建议书》是系统建设进行各项准备和安排计划的依据，是系统建设的第一个必备文件。
2．3 可行性研究阶段
可行性研究阶段，是以系统建设的《项目建议书》或领导的有关批件为出发点，对所要建设的项目在技术上、经济上是否可行进行的一系列科学分析，是要深入进行各种可行性论证的阶段，该阶段的目的是通过对现行金融业务制度的调查和研究，探讨金融电子化的方法和途径，并估计出使用电脑的投资和将来的效益，以决定系统建设的可行性。应从技术、经济以及营运管理等各方面提出多个可行的候选的方案，并分析各个方案的利弊，为上级管理人员的决策提出科学的依据。
可行性研究的结果必须总结形成《可行性研究报告》，作为系统建设的该阶段的一个重要必备文件。
在可行性研究的基础上，应以《可行性研究报告》为依据组织有关专家进行方案论证工作，对可行性研究报告中提出的各项技术指标进行分析比较，落实各项假设的前提条件，决定系统建设方案，并根据该方案及其实施计划编写成《系统设计任务书》，作为系统建设在该阶段的又一个必备文件。
系统设计任务书经上级主管部门批准后，正式作为系统建设的依据，可行性研究阶段基本结束。应当指出，可行性研究只适用于那些无现成经验可以借鉴或建设投资很大、非常复杂的项目。对金融行业中，国际上已普遍采用的方案，一般不再进行可行性研究，在这种情况下，领导的有关批示或经过批准的《项目建议书》就可以作为下一阶段——系统分析阶段的工作依据。
2．4 系统分析阶段
系统分析是在系统设计任务书所确定的范围内，根据计划安排，对现行金融业务制度进行全面的调查分析，对现行业务中各种工作流程以及处理功能给出逻辑的描述，即给出现行系统的逻辑模型；同时，从调查研究的结果分析提炼出新系统的功能需求，给出新系统功能需求的逻辑描述。这些需求除包括业务处理的各种功能外，还应包括新系统运行的硬件环境，如所需硬件环境为新增设备，还应提交一份〈计算机系统选型报告〉，供批准后订货用。
系统分析阶段的基本任务就是通过调查分析，从逻辑上分析现行银行制度并设计出新的系统，这一阶段是整个系统建设的关键阶段，其工作质量的好坏，将对整个系统建设产生决定性的影响。
系统分析阶段结束后，新系统的功能基本确定，这时必须将系统分析的结果编写成〈系统功能说明书〉，作为系统建设的必备文件，它主要是从业务处理的角度，对系统的逻辑结构进行描述。因此，它是业务部门和技术部门共同承诺的一份文件，也是上级管理部门审查及外部协调的依据。
2．5 系统设计阶段
系统设计是为实现系统分析提出的系统功能所进行的各种技术设计工作的总称，是设计结果产生出新系统的详细技术设计方案。针对不同系统的规模和复杂程度，系统技术设计方案可能由若干个子系统技术设计方案所组成。
系统设计的主要内容包括：确定支持系统运行的计算机硬设备环境、原始数据的组织和输入、输出信息的方式和管理、标准化设计方案、数据库系统、应用软件系统、通讯网络、系统安全保密、主要建筑物以及详细的实施计划等。
系统设计的结果必须总结成〈〈系统规格说明书〉〉，作为系统建设的必备文件，它从系统设计的诸方面说明系统设计的指导思想及采用的技术方法，是上级管理部门审查和协调的依据，是下阶段工作的基础性文件。
2．6 系统实施阶段
系统设计方案经上级管理部门批准后，即可组织力量进行实施，也就是系统逻辑结构和技术设计方案的具体实现。系统建设是一项复杂的组织管理和技术管理工作，整个系统实施过程必须严格按照系统规格说明书中实施计划分阶段进行，每一阶段都必须写出《实施进度报告》，它也是系统建设的必备文件。编制实施进度报告的目的是向上级管理部门报告实施进展情况，反映实施过程中遇到的各种新情况、新问题，以便上级管理部门对整个系统开发的进程进行有效控制。
一般来讲，系统实施是一个子系统一个子系统的分别实现 ，或一个程序一个程序甚至是一个模块一个模块逐步完成。在每个子系统、程序或模块完成以后，都要对该阶段的工作成果进行全面的测试，并将测试结果编写成单元测试报告，仅当所有工作全部完成后，再对系统参数或指标进行一次全面的测试，以确定系统是否达到设计要求和能否进行试运行。因此，《系统测试报告》是审查系统实施阶段能否告一段落的系统必备文件。只有通过综合测试的系统才能进入系统应用投产阶段。
2．7 系统应用投产阶段
系统实施阶段完成后，经过测试达到设计要求的系统，还不能立刻就取代旧系统投入政党运行，还必须经过试运行，验证系统的有效性，使操作人员适应新系统。只有圆满通过试运行的新系统才能最后取代旧系统，投入正式使用。应用投产作为系统建设的一个环节，通常包括验收、转换、双线操作和大面积推广使用四个阶段。
在系统开始试运行之前，首先要由业务部门对新系统进行全面的验收，以检查系统的功能是否达到系统功能说明书中规定的要求。验收的方法，可以通过系统功能示范表演，也可以通过用户在验收环境下的实际振作，甚至大量的业务模拟，以便用户了解和检查新系统的功能，在用户确认了新系统的功能后，以所提交的书面《系统验收报告》为系统开始试运行的依据。
为了进行系统试运行，还必需做好大量准备工作，如人员培训、早系统数据的转换、新旧系统双线操作等。所有这一切都应在《新旧系统转轨计划报告》中标示清楚，以使新系统的试运行在有条不紊的条件下顺利进行。因此，新旧系统转轨计划报告也是系统建设中的重要必备文件。
经过系统试运行，业务部门掌握了新系统的特点，熟悉了新系统的环境。又通过技术人员的不断维护，系统秩序趋于稳定，新系统的功能日趋完善，在业务人员和技术人员有了使用经验的基础上，大面积推广应用新系统的条件就完全具备了。在系统建设宣告结束前，需完成最后一个必备文件——《系统建设总结报告》，并对整个系统建设过程进行总结。系统建设总结报告经上级管理部门批准后，系统建设正式结束。
2．8 小结
为对系统建设进行科学管理，金融电子化系统建设全过程，必须完成以下十个系统必备文件：
（1） 项目建议书；
（2） 可行性研究报告；
（3） 系统设计任务书；
（4） 系统功能说明书；
（5） 系统规格说明书；
（6） 实施进度报告；
（7） 系统测试报告；
（8） 系统验收报告；
（9） 新旧系统转轨计划报告；
（10） 系统建设总结报告。
若所需硬件环境为新增设备，还应编写《计算机系统选型报告》。
3 金融电子化系统建设必备文件内容概述
3．1 项目建议书
项目建议书是系统建设起动阶段完成的必备文件，它是选择建设项目的依据。建设项目的选择必须完全符合金融电子化工程的需求，具有显著的社会、经济效益，并结合现行金融系统实际进行。
项目建议书的编写提纲和内容要求见“项目建议书”。
3．2 系统设计任务书
系统设计任务书是在系统可行性研究的基础上，对选定的系统建设的最佳方案进行更为深入的研究、分析，进一步明确系统建设的目标和规模，并制定系统建设的初步计划。
系统设计任务书的编写提纲和内容要求见“系统设计任务书”。
3．3 可行性研究报告
可行性研究报告要求根据实际需要和可能，对几种可能的系统建设方案从技术可行性、经济可行性和运营维护可行性等三个方面进行论证，并分析利弊，提出建议性结论。可行性研究报告的其编写提纲和内容要求见“可行性研究报告”。
3．4 系统规格说明书
系统规格说明书从系统总体角度对系统建设的主要技术设计方案进行说明，以便系统建设有一个可遵循的技术规范。此外，系统规格说明书还要对系统指导思想和所采用的技术方法进行阐述。它是上级主管部门审查和协调系统建议过程的依据，是下一阶段工作的基础。其编号提纲和内容见“系统规格说明书”。
3．5 系统功能说明书
在系统分析阶段，用户和系统分析人员充分理解和认真分析用户要求，共同制定的系统功能、系统逻辑结构的说明书，称系统功能说明书。它准确的描述用户要求系统的功能全貌，其主要内容和书写格式见“系统功能说明书”。
3．6 实施进度报告
在执行计划过程中按实施阶段或季度、半年度、年度等定期向上级主管部门申报计划实施过程中的情况，使上级部门在布置、检查工作时有据可依，需要编制实施进度报告，其编写提纲和内容提要见“实施进度报告”。
3．7 系统测试报告
所谓系统测试是对系统功能和性能进行测试的过程，要分别对系统硬设备、软件等，按系统规格说明书所要求的系统功能和性能，进行严格的测试，并对测试的结果，进行分析研究形成系统测试报告。系统测试报告的编写方式和内容提要见“系统测试报告”。
3．8 系统验收报告
编制系统验收报告的目的是系统用户从营运的角度对所建成的新系统进行评价验收，验收时要调查系统实施后是否达到了设计时提出的预期目标，并给出了是否可以通过验收的结论。其编写提纲和内容提要见“系统验收报告”
3．9 新旧系统转轨计划报告
编写新旧系统转轨计划报告的目的是陈述本系统设计、测试完成的情况及新系统投入试运行的准备工作情况，其编写提纲和内容概要见“新旧系统转轨计划报告”。
3．10 系统建设总结报告
编制系统建设总结的目的，是对整个系统的开发工作进行全面评价，其编写提纲和内容要求见“系统建设总结报告”。
3．11 计算机系统选型报告
金融电子化系统建设对计算机系统的选型就是从金融电子化系统建设确定的功能目标出发，经过周密的环境分析和功能分析，并对市场提供的计算机系统的性能与价格认真比较，确定出满足需要的计算机系统。选型过程结束时，应形成计算机系统选型报告，它是各级领导决策的重要依据，计算机系统选型报告编写提纲和内容见“计算机系统选型报告”。
项目建议书
1． 引言
1． 1统简介
简要介绍新建系统的名称、目标和功能，说明该系统建设的组织单位、服务对象及其与其他系统或机构的联系。
1．2 参考和引用资料
列出有关文件资料的标题、编号、发表日期和制定单位，说明这些文件资料的来源。
1． 2 专门术语定义
列出本文件所使用的专门术语、英译名、缩略语和定义。
2． 现行系统分析
2．1 现行系统的组织结构
2．2 现行系统的业务流程
2．3 现行系统的工作负荷
2．4 现行系统的运行费用
2．5 现行系统的人员设备状况
2．6 现行系统的计算机应用情况
分析现行系统的计算机硬件配置、软件配置、使用效率和效益等。
2．7 现行 系统的局限性分析
通过对现行系统的分析，论述其主要的局限性，提出问题和改进建议。
3． 系统建设的必要性
首先，系统的建设应当在金融电子化工程中占有一定地位，完成相应职能，并符合金融电子化的总体发展战略。
其次，系统的选择应当考虑国内外同类系统的现状、水平和发展趋势，一般应居于先进地位，并注意避免重复开发。
最后，系统的建设应当形成一定的社会效益和经济效益。
通过新建系统与现行系统的目标功能对比，阐述新建系统在上述三个方面的优越性，说明其建设的必要性。
4． 系统概况
简要说明新建系统的建设规模、组织机构和初步的建设实施计划。
5． 系统的投资概算
对于系统建设所需投资进行估算，提出投资概算和初步的资金筹措设想。计划利用外资的项目需说明利用外资的可能性及偿还能力测算。
6 附件
附上与文件有关的其他文件、资料。
系统设计任务书
1． 系统目标和任务
1．1 系统建设背景
论述社会经济的发展和金融电子化工作对新建信息系统的需要。
1．2 系统建设的目标和功能及达到这些目标和功能的衡量标准，并描述系统的主要任务。
2． 系统结构
简述系统的组织机构和逻辑结构。
3． 系统建设规模和计划
3．1 系统规模
收集信息的范围、服务对象和服务内容、数据处理能力和投资规模。
3．2 系统建设初步实施计划
3．3投资计划
3．4人员计划
人员需求、培训、新增人员等计划。
4． 问题和措施
系统建设的组织保证，对可能出现的问题拟采取的措施。
可行性研究报告
1 引言
1．1 系统简介
简要介绍新建系统的名称、目标和功能，说明该系统建设的组织单位，服务对象及其与其他系统或机构的联系。
1．2 参考和引用资料
列出有关文件资料的标题、编号发表日期和制定单位，说明这些文件资料的来源。
1．3 专门
列出本报告所使用的专门术语、英译名和定义。
2 系统的可行性研究
根据实际需要和可能，设计几种可能的系统建设候选方案。针对每种方案分别从技术、经济和运营维护三个方面进行可行性分析和评价。为主管部门决策提供科学的依据。
2．1 系统建设的技术可行性
2．1．1 现有技术估价
分析国内外相关技术的发展水平和国家现行技术政策，重点是系统建设所需采用的可用技术的估价和使用这些技术进行系统建设的可行性。涉及引进技术的项目应当研究技术引进的可行性。
2．1．2 技术发展及其影响分析
对系统建设和运营的整个生命周期内的相关技术，特别是实用技术可能取得的进展作出预测，分析这种进展对系统可能产生的影响，避免开发和引进相对过时技术。
2．1．3 应用技术的选择原则
参照国外先进的金融电子信息系统的经验，考虑其技术发展趋势，结合我国金融电子化工程实际，注重技术的先进性和成熟性，是金融电子化应用技术选择的基本原则。
同时，应用技术的选择应完全符合金融电子化总体发展战略。
2．2 系统建设的经济可行性
2．2．1 现有经济条件分析
主要包括现有的组织机构、人员配备、公共设施、软硬件环境分析，重点是可提供资金的分析。
2．2．2 系统费用分析
2．2．2．1 系统建设费用
包括所需的土建费用、计算机软硬件购置、应用技术开发、人员培训、系统建设计划实施等的费用分析。
2．2．2．2 系统运营维护费用
包括人员工资、软硬件维护费用、公共设施费用、数据采集和录入费用、通讯费用和其他费用等。
2．2．3 系统效益估价
对系统建成后将产生的直接或间接经济效益进行估价。
2．2．4 经济可行性分析
现有经济条件对于系统建设和运营维护的满足程度和系统建成产生的社会效益的综合平衡是估价系统是否具备经济可行性的主要因素。经济可行性分析还应当包括通过效益/费用比，分析投资的可能性。
2．3 系统运营维护可行性
2．3．1 系统建立对组织机构的影响
2．3．2 系统建立对人中的需求
分析现有人员对系统运营维护的适应性，人员培训的可行性，还应考虑人员补充计划的可行性。
2．3．3 系统维护费用保证
系统建成后，其运行维护需要相当数量的费用开支，才能保证系统对外进行良好的服务。金融电子化工程建设应对此有充分的估计，以避免在系统建成后由于数据无法更新或配套工程不齐备，影响系统的正常运行，甚至无法运行，失去其系统建设的意义。
3．方案比较研究
对各种候选方案的技术、经济、运营维护可行性进行比较、分析，对各种方案的优缺点，给出结论性意见，并推荐优选方案。
4 附件
附上与文件有关的其他文件、资料。
系统规格说明书
1 引言
1．1 系统简介
摘要说明所设计系统的名称、目标和功能。列出项目的承担者、用户、本项目和其他系统或机构的关系和联系，简述工作条件和相关约束限制条件。
1．2 参考和引用资料
列出有关文件资料的标题、编号、发表日期和制定单位，说明这些文件资料的来源。
1．3 专门术语定义
列出本文件所用到的专门术语、英译名、缩略语和定义。
2 系统总体技术方案
2．1 模块设计
在模块设计阶段，首先划分系统内部基础模块结构，然后确定系统的总体结构。它是程序编写的依据。
2．1．1 模块结构图
模块结构图，是采用IPO图（即输入—处理—输入图）形式绘制而成的系统结构框图。图中要简述模块的名称、功能和接口关系。
2．2 代码设计
代码设计是信息系统设计的重要设计内容之一。它是进行信息分类、校对、总体和检查的关键，也用于指定数据的处理方法，区别数据类型和指定计算机处理的内容。
2．2．1 代码
简单说明代码的方式和种类，从编码的原则要求去简单说明所体现的功能。
2．3 输入设计
输入设计担负着将系统外的数据以一定的格式送入计算机的任务，它直接影响到人工系统和机器系统的工作质量。输入设计的原则是确保系统输入信息的正确无误。输入必须有必要的介质和设备为基础。
2．3．1 输入
说明系统的主要输入信息，以及对输入承担者的安排和主要功能要求。简单说明各主要输入数据的类型、来源及所采用的设备、介质、格式、数值范围、精度等。简述所用的数据校验方法及其效果。如果输入数据同某一接口软件有关，还应说明该接口软件的来源。
2．4 输出设计
所谓输出，是指计算机将原始输入数据进行处理，将其加工成满足用户使用要求的格式，并提供给用户。输出不仅有一定的格式要求，而且还必须有必要的介质和设备支撑。
2．4．1 输出
说明本系统产主要输出项目、输出项目的数据接受者、主要功能。并简述输出数据类型及所用的设备介质、格式、数据范围和精度等。
2．5 数据库设计说明
数据库设计，是指数据库应用系统的设计。编制数据库说明的目的，是对所设计数据中数据的逻辑结构和物理结构作出具体的设计规定。
2．5．1 概述
说明设计开发数据库的意图，应用目标、作用范围、主要功能以及有关数据库开发的背景材料。
2．5．2 需求规定
主要描述数据库性能规定，包括对数据精度、存取数据的有效性、响应时间、数据的转换和传送时间以及其他专门要求。
2．5．3 运行环境要求
简述运行数据库系统的硬设备及其专门功能，列出支撑软件并说明测试用的软件，说明在安全保密以及其他有关方面的要求。
2．5．4 设计考虑
简要说明本系统或子系统内所使用的数据结构中，有关数据项、记录、文件的标识、定义、长度及它们之间的相互关系。简要说明本系统或子系统内所使用的数据结构中有关数据项的存储要求、访问方法、存取单位、存取的物理关系（索引、设备、存储区域）、设计考虑和保密处理。
2．6 模型库及方法设计
2．7 网络设计
系统的网络结构和网络功能设计
2．8 安全保密设计
2．9 评价、验收
对系统的每部分设计都应有相应的评价，评价的结果是重要标准。
2．10 实施方案说明书
系统设计（总体结构和实施设计）阶段完成以后就要确定系统实施方案，书写实施方案说明书，实施方案说明书是系统实施阶段的依据和出发点。
2．10．1 实施方案说明
对系统名称、子系统名称、程序名称、程序语言、使用的设备等逐项说明；对数据长度、文件名称和形式、编号、构成记录的各数据项的名称和内容等逐项说明；对进行程序设计的处理内容进行详细说明。
2．10．2 实施总计划
对于项目开发中需完成的各项工作，包括文件编制、审批、打印、用户培训工作、使用设备的安排工作等，按层次进行分解，指明每项任务的要求。
给出每项工作任务（包括文件编制）的预定开始日期和完成日期，规定各项工作任务完成的先后顺序以及每项工作任务完成的标志。
逐项列出本开发项目所需要的费用（包括办公费、差旅费、机时费、资料费、通讯齐备和专用设备的租金等）。
2．10．3 实施方案的审批
由于实施方案是下一阶段工作依据，所以待报批的实施方案要经过用户、系统研制人员、程序员、操作员、专家和管理人员审议。而一经审批的实施方案就不能随意改动。
2．11 附件
附上与文件有关的其他文件、资料。
系统功能说明书
1 引言
1．1 系统简介
简要介绍新系统的名称、目标和功能，说明该系统建设的组织单位、服务对象及其与其他系统或机构的联系。
1．2 参考和引用资料
列出有关文件资料的标题、编号、发表日期和编制单位，说明这些资料的来源。
1．3 专门术语定义
列出本文件所使用的专门术语、英译名、缩略语和定义。
2 系统需求分析
系统建设一般是在现行系统的基础上进行的，所以在系统设计工作开展前，必须对现行系统进行深入细致的调查研究工作，掌握真实情况，尤其要弄清用户的需求和存在的问题，写出系统需求说明。
2．1 现行系统调查
现行系统实现的目标、完成的功能、组织机构、用户需求，需要解决的问题。
2．2 现行系统的业务流程
分析现行系统的业务流程，如有可能，绘制其业务流程图。
3 新系统功能定义
3．1 新系统功能综述
经过现行系统的调查，分析其信息流程，按照用户实际需要，拟定系统建设的功能要求，综述新建系统的各项功能。
3．2 新系统逻辑结构
在系统分析的基础上建立可满足系统功能设计的系统逻辑结构。这主要包括外部输入/输出、屏幕、报表和文件格式及内部处理的功能逻辑等。
3．3 系统运行环境
陈述系统建成后的运行条件和用户环境。
4 附件
附上与文件有关的其他文件、资料。
实施进度报告
1 引言
1．1 系统简介
摘要说明该系统的名称、结构和总的进度要求；列出任务的提出者、开发者和用户。
1．2 参考和引用资料
列出有关文件资料的标题、编号、发表日期和制定单位，说明这些文件资料的来源。
1．3 专门术语定义
列出本文件所使用的专门术语、英译名、缩略语和定义。
2 进度情况
2．1 工程进度
提供应用软件开发进度计划；硬件配置进度计划；土建施工进度计划等本阶段工程进展情况。
2．2 投资进度
提供资金开支计划；资金筹集计划等本阶段的执行情况。
2．3 人员计划执行情况
提供本阶段所用各类人员的数目、来源及人员培训等计划执行情况。
3 问题和措施
陈述实施计划过程中遇到的资金、人员、技术和环境等方面的问题；列出解决问题的措施和建议。
4 附件
附上与文件有关的其他文件、资料。
系统测试报告
1 引言
1．1 系统简介
摘要说明被测试系统的名称、基本功能及所要进行测试的主要目的和简要过程；列出本项任务的提出者、开发者和用户。指出测试环境与实际运行环境可能存在的差异以及这些差异对测试结果的影响。
1．2 参考和引用资料
列出有关文件资料的标题、编号、发表日期和制定单位，说明这些文件资料的来源。
1．3 专门术语定义
列出本文件所使用的专门术语、英译名、缩略语和定义。
2 测试情况
2．1 简述使用的测试手段和过程，列出经过测试证实已实现的功能，指出未完成的功能和缺陷以及局限性。
3 测试分析
陈述经过测试证实的缺陷和限制，说明这些缺陷、限制对系统可能造成的影响。
4 结论
4．1 评价
说明被测试系统是否达到一定的目标，并对未能达到的预期目标进行分析说明。
4．2 建议
说明被测系统是否事投入试运行，提出解决缺陷和限制的建议。
5 附件
附上与文件有关的其他文件、资料。
系统验收报告
1． 引言
1．1 系统简介
摘要说明系统的名称、结构和功能，列出该系统任务的提出者、开发者和用户。
1．2 参考和引用资料
列出有关文件资料的标题、编号、发表日期和制定单位，说明这些文件资料的来源。
1．3 专门术语定义
列出本文件所使用的专门术语、英译名、缩略语和定义。
2 系统验收
2．1 系统验收的环境
列出参加系统验收工作的有关人员、工作单位、职称等情况，给出系统验收所采用的方法及与验收有关的其他环境。
2．2 系统验收的步骤
对照系统设计任务书和系统功能说明书，列出验收系统各个组成部分的步骤。
2．3 系统验收的主要内容
系统验收主要是检查实施系统是否完全达到了功能需求、结果是否正确、操作是否方便、程序可维护性如何、安全性及可靠性怎样、各种技术文件是否齐全等内容。
3 结论
根据系统验收结果，给出系统是否能够通过验收的结论。
4 附件
附上与文件有关的其他文件、资料。
新旧系统转轨计划报告
1 引言
1．1 系统简介
摘要说明系统的名称、结构和功能，列出该系统任务的提出者、开发者和用户。
1．2 参考和引用资料
列出有关文件资料的标题、编号、发表日期和制定单位，说明这些文件资料的来源。
1．3 专门术语定义
列出本文件所使用的专门术语、英译名、缩略语和定义。
2 系统运行的准备情况
2．1 操作规程准备情况
向操作人员和管理人员提供该系统的有关情况和操作步骤，包括系统硬设备和软件的操作规程、系统运行的每一步骤的详细过程、各种人员所需操作信息、启动和故障的恢复过程、非常规过程（如故障等）的操作和信息。
2．2 运行管理的各项规章制度的准备情况
给管理系统的部门提供有关运行营运的规范，包括运行管理、输入输出数据管理、操作管理、程序管理等制度的准备情况。
2．3 系统维护手册准备情况
提供系统维护人员维护本系统所需文件，其内容包括程序的维护、数据文件的维护、代码维护、机器的维护等。
2．4 营运经费的落实情况
提供营运过程中经费支出和经费来源的情况，经费包括劳务费、线路使用费、维修费、水电费、消耗品费、机房房租、设备折旧费、保险费和税金、软件租金等。
2．5 外部环境的协调情况
给出本系统与系统外环境之间的协调情况，如系统内外的业务接口关系、外界条件寻本系统的约束的协调、本系统对外界条件的影响的协调等。
2．6 历史数据的准备情况
给出系统运行所需历史数据的整理工作完成的情况。
2．7 人员的准备情况
给出系统运行时所要增加的系统运行维护人员的数量、技术素质和人员来源情况。
3 试运行及转轨计划
在试运行及转轨条件成熟的情况下，进行试运行及转轨的工作。本计划经出试运行及转轨工作的具体安排，包括进度的安排和人员的安排等。
4 附件
附上与文件有关的其他文件、资料。
系统建设总结报告
1 引言
1．1 系统简介
摘要说明系统的名称和开发目的，列出该系统的任务提出者、开发者和用户。
1．2 参考和引用资料
列出有关文件资料的标题、编号、发表日期和制定单位，说明这些文件资料的来源。
1．3 专门术语定义
列出本文件所使用的专门术语、英译名、缩略语和定义。
2 实际开发结果
2． 1系统构成
说明实际开发系统的结构。
2．2 主要功能和性能
列出本系统实际具有的主要功能和性能，对照可行性研究报告和系统设计任务书的有关内容，说明原定开发目标是否已经达到。
2．3 进度
列出原定计划和实际进度，度加以对比分析。
2．4 费用
列出原定的计划费用和实际费用，并加以对比分析。
3 开发工作评价
3．1 系统质量评价
说明主要功能与原设计预期要求的差距。
3．2 技术方法评价
给出在开发中使用的技术、方法、工具和手段的评价。
3．3 出错原因分析
给出对开发中出现的错误的原因分析。
3．4 经验与教训
列出本项任务开发工作过程中所取得的最主要的经验与教训，以及对今后开发工作的建议。
4 附件
附上与文件有关的其他文件、资料。
计算机系统选型报告
1 引言
1．1 系统简介
简要介绍所选计算机系统的名称和市场概况，提供计算机系统的市场价格和保价，明确主要技术性能指标，以及性能/价格比和所建系统的客观要求等选择因素，确定选择的目标。
1．2 参考和引用资料
列出有关文件资料的标题、编号、发表日期和制定单位，说明这些文件资料的来源。
1．3 专门术语定义
列出本文件所使用的专门术语、英译名、缩略语和定义。
2 选型依据
2．1 市场情况
市场提供的能够进行选型的计算机设备的名称，性能和价格；供应商在资金、质量、服务等方面的信用情况。
2．2 国家或行业政策
国家或行业在现阶段对计算机设备购置的管理政策和法规，计算机系统出口国政策和法律方面的限制。
2．3 可用资金的技术条件
说明用户现有经济能力和开发单位的技术条件。
2．4 计算机系统要求
所建系统的功能要求、容量要求、性能要求、外部设备配置要求、通讯和网络要求等。
2．5 环境
硬件/软件/运行所需环境要求。
2．6 其他制约
基建、电力、通讯等方面的限制，系统建设要求时间的限制，一些重要的信息通道和资源条件的制约限制等。
3 计算机系统配置
配置要求是根据设计要求应达到的功能而选定所需的硬设备、软件的数量和种类及人员等。
确定配置要说明当前目标与中长期目标的需要，考虑主机与外设配套、硬件与软件协调以及尽量与当代先进水平的硬件和软件兼容等。同时要考虑硬设备的添置、软件的兼容性、可扩充性以及其它有必要说明的问题。
4 费用预算
对提供的每一种可选择方案需要的资金进行说明，说明要分别列出一次性支出和非一次性支出。
4．1 一次性支出
房屋和设施、硬设备、系统软件和应用软件开发、培训和差旅费等。
4．2 非一次性支出
按月或季度、年度支出的用于运行和维护的费用以及合同性开支等。
5 结论
5．1 可选方案的评价
对性能/价格比和其他环境要求等综合因素进行比较，说明选择和未选择方案的原因。
5．2 建议
依据可选方案评价结果提出意见
1） 可以立即开始进行选择购置；
2） 推迟到某些条件落实之后才能开始进行选择购置；
3） 对某些指标进行调整之后才能开始进行选择购置；
4） 不能进行或不必进行选型。
6 附件
附上与文件有关的其他文件、资料。
第11章 金融电子化系统软件工程规范
11．1 概述
软件工程采用生存周期方法学、结构分析、结构设计技术和先进的软件管理办法，指导软件的开发和维护。软件工程的主要作用是：把工程的概念引入软件开发全过程，提高软件开发效率和软件产品质量，方便软件维护，以满足社会日益增长的软件需求。
随着我国金融行业经营管理电子化水平的迅速提高，其对计算机的需求量急剧增长，一大批已经投入运行的计算机软件必须维护，大量急需的应用软件系统等待开发。而“自编自用”的软件开发方式和低水平重复开发软件的现象，又使得软件生产率极低，难以满足软件需求。致使金融待业的各个部门都不同程度地出现了“软件危机”。其表现形式是“软件需求不明确；通讯与开发者之间的信息交流不充分；软件可维护性差。特别是开发与维护阶段界线不清；开发人员，维护人员与用户的职责不明确；软件文档不齐备；用于金融业务及信息管理软件开发的语言不符合国家标准或国际标准，严重阻碍应用软件系统的商品化生产、开发和软件产品的安全、可靠性。面对如此现实，虽然我国金融业务部门，都根据各自的现状和特点，制定了一些应用软件系统开发规程、文档要求及相应的管理规范，逐步对已开发的软件进行优化、统一，在一定程度上控制了软件低水平重复开发的现象，提高了软件的可维护性。但由于缺乏规范化软件工程方法的指导、约束，已经出现的”软件危机“还没有明显好转。因此，为了有效保证软件产品质量，提高软件可维护性，使软件生产适应电子化系统的急剧发展的需求，只有在金融系统的软件开发、应用和管理中全面采用软件工程方法，才能彻底克服”软件危机“所造成的被动局面。
金融电子化系统建设是一项庞大的系统工程，在这一工程建设过程中，必须遵循一系列的规范和标准，才能保证金融软件的开发取得丰硕成果。因此，借鉴国家及国务院各部委所制定的各项软件工程规范和标准，结合金融电子化系统建设实际，对金融软件的开发及管理，制定相应的规范、标准，是金融电子化系统建设过程中最重要的技术基础工作之一。
本金融电子化系统软件工程规范，包括以下内容：
（1） 软件开发规范；
（2） 软件文档编制；
（3） 软件维护；
（4） 软件管理；
（5） 软件开发费用估算与管理；
（6） 软件产品优选登录。
11．2 软件开发规范
11．2．1 软件开发规范的作用和使用范围
本规范是参照国家标准G B8566—88《计算机软件开发规范》，结合金融电子化系统软件开发的现状和发展，提供一整套软件开发的准则、方法和规定。其作用是明确的划分软件开发全过程的各个阶段，并对每阶段开发任务提出明确的要求，以提高软件开发过程的能见度，使软件开发过程得到有效的控制和管理，使得软件开发过程系统化、规范化和工程化。严格遵守本规范，将能保证软件具有高度的可靠性、可维护性和开发过程的科学必性、有效性。
本规范适用于金融电子化系统建设过程中各种类型、各种规模软件的开发活动，适用于金融行业各级从事软件开发、管理和使用的技术人员、管理人员、业务人员及其他与金融电子化系统计算机软件有密切关系的人员。
11．2．2 软件开发规范的主要内容
软件开发规范主要包括如下内容：
11．2．2．1 阶段划分
按照软件生存周期方法学，软件开发过程通常被划分为八个阶段：
（1） 可行性研究与计划；
（2） 需求分析；
（3） 概要设计；
（4） 详细设计；
（5） 实现；
（6） 组装测试；
（7） 确认测试；
（8） 使用和维护。
11．2．2．2 软件开发各阶段的任务及要求
（1） 可行性研究与计划
要求：充分了解用户的要求及现实环境，从技术、环境以及经济和社会因素等方面研究并论证本软件项目的可行性，准确、具体地确定工程规模和系统目标，对建议的系统进行仔细的成本/效益分析，写出可行性研究报告，制定初步项目开发计划。本阶段应交付的文档有：
a 可行性分析报告；
b 初步项目开发计划。
（2） 需求分析
要求：确定被开发软件的运行环境，功能和性能要求。编写用户手册概要，软件质量保证计划，软件配置管理计划，软件确认测试准则。详细说明被开发系统与其他硬件、软件及人员的接口情况，为概要设计提供用户确认的需求说明书。本阶段应交付的文档有：
a 软件需求说明书；
b 修改后的项目开发计划；
c 用户手册概要；
d 确认测试计划；
e 数据要求说明书；
f 软件质量保证计划；
g 软件项目配置管理计划。
（3） 概要设计
要求：根据软件需求说明，建立目标系统的总体结构（对不同规模的系统总体结构可参照GB8566—88《计算机软件开发规范》中的有关条目建立）和模块间的关系，定义各功能模块的接口和控制接口。设计全局数据库/数据结构，规定设计限制，制定组装测试计划。本阶段应交付的文档有：
a 概要设计说明书；
b 数据库/数据结构设计说明书；
c 模块测试计划。
（4） 细设计
要求：对概要设计中产生的功能模块进行过程描述，设计功能模块的内部细节，包括算法和数据结构。详细规定各程序模块间的接口，包括参数的形式和传递方式，上下层调用关系等。为编写源代码提供必要的说明，画出程序流程图（流程图中使用的图形符号应符合GB1526—79 《信息处理流程图图形符号》），建立“模块开发卷宗”。本阶段应交付的文档有：
a 详细设计说明书；
b 模块开发卷宗。
（5） 实现
要求：按照详细设计说明，对每个程序模块用所选定的程序设计语言（应尽可能采用已有国家标准或国际标准的程序设计语言或数据库语言编写程序；对编写好的源程序进行单元测试，验证，程序模块接口与详细设计说明的一致性。程序模块的测试用例、预期结果及测试结果应存档保留。本阶段应交付的文档有：
a 模块开发卷宗；
b 组装测试计划。
（6） 组装测试
要求：根据概要设计中各功能模块的说明入制定的组装测试计划，将经过单元测试的模块逐步进行组装和测试，分析测试结果，找出产生错误的原因。本阶段应交付的文档有：
a 可运行的源程序清单；
b 组装测试分析报告；
c 确认测试计划。
（7）确认测试
要求：根据软件需求说明书中定义的全部功能、性能要求及确认测试计划，首先在最终用户的环境中进行强度测试，以检查该软件有无严重错误；然后执行测试计划中提交的所有确认测试，验证整个软件系统是否达到了要求。修改并提交最终的用户手册和操作手册。预期结果、测试结果和测试数据应全部存档保留。编写项目开发总结报告。本阶段应交付的文档有：
a 确认测试分析报告；
b 最终的用户手册和操作手册
c项目开发总结报告。
（8）使用和维护
要求：对投入运行后的软件进行修改是软件维护阶段的任务。这个阶段周期长，工作量大，成本高，因此必须在严格的管理控制下进行，维护组织与维护要求及应交付的文档，依照本章11。4节执行。
11．3 软件文档编制
11．3．1 软件文档编制
11．3．1．1 编制软件文档的作用
为了保证计算机软件项目开发的成功，节省项目投资，提高项目开发质量，便于运行和维护，在软件开发工作的每一阶段，都需要编制一定的文档。这些文档是计算机软件不可缺少的组成部分。它和计算机程序及数据一起构成计算机软件。
软件文档的作用是：
（1） 作为开发人员在一定阶段内工作成果的反映和工作结束的标志；
（2） 把软件开发过程中一些“不可见”的事物转变为“可见”的文字资料。便于检查开发工作的进展情况，判断原定目标是否已经达到；
（3） 记录开发过程中的技术信息，便于协调软件的开发、使用，以及软件的维护、个性或进一步开发；
（4） 提供有关该软件运行、维护和培训方面的技术信息，向潜在用户报导软件的功能和性能，便于管理人员，开发人员、操作人员、用户之间的沟通和了解。
11．3．1．2 编制软件文档应考虑的因素
文档编制，需要付出艰巨的劳动。为保证文档编制质量，使之能适应不同使用对象的要求，而又使所花费的劳动与不同项目对文件的需求相适应，应根据下列因素确定文档的编制要求。
（1） 每一种文档都有其特定的使用者。这些使用者包括软件开发单位（一个或几个）的技术人员、管理人员和领导干部；使用和维护这些软件的用户；社会上的公众等。这些不同的人员对文档的内容，详尽程度以及侧重点有不同的要求。因此，文档的编写者必须了解文档使用者的特点、水平和需要，以及该文档提供的广泛程度等，有针对性地编写成各种文档。
（2） 编制的各种文档的某些内容上不可避免会有重复，这是为了使文档的使用者能比较方便地了解某些共性的内容，而不必频繁地去参阅另外一些文档或章节，这样的重复是必要的，但在行文的详尽程度上可根据该文档的使用对象不同而有所侧重。
（3） 根据软件的规模和复杂程度的不同，在确定文档的种类、详尽程度、种类与章节的扩展压缩、程序设计和文档的表现形式等方面时可灵活掌握，使其更符合实际需要。这包括：
A 应编制的文档种类
本规范建议应编制的软件文档有16种。但针对一项具体的软件开发项目，以把某几种文档合并成一种，以减少文档的种类。
当本规范所编制的文档种类尚不能满足某些单位或部门的特殊需要时，还可根据需要再规定若干种增补编制的文档。
应编制的文档种类和详尽程度取决于承担开发单位的管理能力、软件的专业特点、开发项目的规模、复杂性和成败风险等因素。因此，软件开发单位应制定一个文档编制实施规定，说明在什么情况下应编制哪些文档（包括本单位规定应增补的文档）。
对每个具体的软件项目，应确定一个文档编制计划，规定应编制的文档种类；详尽程度；编制、审查、批准人员和进度要求；以及开发期间各文档的维护、修改、管理人员和批准手续，文档编制计划是整个开发计划的重要组成部分。
B 文档的详尽程度
文档编制的详尽程度取决于任务的规模、复杂性以及该文档的使用者对文档内容的需求。
C 文档种类以及章节的扩张和缩并
当一种文档的内容非常多或有必要分卷时，则可将其分卷编写。各种文档编写时，一般应符合本规范所规定的章节及其大致相同。但各章节的内容可根据实际情况扩展（细分）或缩并。在这种情况下，章节的编号应相应改变。
D 程序设计和文档的表达形式
本规范对程序设计的表现形式以及文档的表现形式不作具体的规定或限制。设计开发人员和文档的编制者可根据实际情况，以最方便和最有利于表达并为文档使用者接受的形式来设计和编写。
为了便于管理和统一，各单位可参照有关标准对文件的编写格式等作出具体规定。
11．3．1．3 软件开发过程文档明细表
本规范建议规范软件开发过程中一般应编制以下16种文档：
（1） 可行性研究报告
（2） 项目开发计划
（3） 质量保证计划
（4） 配置管理计划
（5） 软件需求说明书
（6） 数据要求说明书
（7） 概要设计说明书
（8） 详细设计说明书
（9） 数据库设计说明书
（10） 用户手册
（11） 操作手册
（12） 模块开发卷宗
（13） 测试计划
（14） 测试分析报告
（15） 开发进展月报
（16） 项目开发总结报告
对于一项具体的软件开发项目，可以把上述某几种文档合并成一种，以减少文档的种类。
除了本规范建议的16种文档外，开发单位还可以根据实际需要规定增补编制的文档种类。
对于一项软件开发项目而言，其生存周期各阶段与各种文档编写工作的关系如表11-3-1所示，其中有些文档的编写工作可能要在若干个阶段中延续进行。
表11-3-1 软件生存周期各阶段中的文档编制
阶段
文件 可行性研究与计划阶段 需求分析阶段 概要设计
详细设计
实现阶段 组测试
确认测试 运行与维护阶段
可行性研究报告
项目开发计划
软件需求说明书
数据要求说明书
软件质量保证计划
软件配置管理计划
测试计划
概要设计说明书
详细设计说明书
数据库设计说明书
模块开发卷宗
用户手册
操作手册
测试分析报告
开发进度月报
项目开发总结
对于不同规模的软件而言，文档编制的种类及详细程度也有所不同。因此，应根据软件的规模、重要性、复杂性等因素，制定出实施规定。软件规模一般分为四级：
（1） 小规模软件：源程序行数小于5000的软件；
（2） 中规模软件：源程序行数为10000 ~ 50000的软件；
（3） 大规模软件：源程序行数为100000 ~ 500000的软件；
（4） 特大规模软件：源程序行数大于500000的软件。
软件文档的编制可参照表11-3-2制定实施规定。
表11-3-2 软件文档编制表
小规模软件 中规模软件 大规模软件 特大规模软件
可行性研究报告 对应于大规模软件 项目开发计划 所规定的文件可进
一步细分项目开发
软件需求与开发计划 软件需求说明 计划
软件需求说明 数据要求说明
测试计划—— 测试计划
概要设计说明
软件设计说明—— 软件设计说明 详细设计说明
数据库设计说明
使用说明—— 使用说明 用户手册
操作手册
测试分析说明 模块开发卷宗——模块开发卷宗
测试分析报告——测试分析报告
项目开发总结 开发进度月报——开发进度月报
项目开发总结——项目开发总结
11．3．1．4 软件文档内容提要
（1） 可行性研究报告
可行性研究报告用于说明软件系统的实现在技术上、经济上和社会条件等方面的可行性；详述为了合理地达到开发目标可选择的各种方案；说明并论证所选定的方案。主要内容应包括：引言；开发管理概要；对现有系统的分析；所建议的系统可选择的其他方案；投资及效益分析；社会条件方面的可行性结论。详细编写格式参照GB8567—88《计算机软件产品开发文件编制指南》。
(2) 项目开发计划
项目开发计划用于确定开发过程中各项工作的负责人员、开发进度、经费预算、所用的软硬件条件等方面的管理性安排，以便根据本计划开展和检查项目的开发工作。主要内容应包括：引言；项目概述；实施总计划；支持条件；专题计划要点等。编写格式参见GB8567—88。
（3） 软件质量保证计划
软件质量保证计划的编写参见本章11。3。2软件质量保证计划。
（4）软件配置管理计划
软件配置管理计划的编写参见本章11。3。3软件配置管理计划。
（5）软件需求说明书
软件需求说明书是为了确定一个反映用户与开发者双方共同理解的该软件系统的具体开发目标，使之作为整个开发工作的基础。主要内容应包括：引言；任务概述；需求规定；运行环境规定。编写格式参见GB8567—88和GB9385—88《计算机软件需求说明书编制指南》。
（6）数据要求说明书
数据要求说明书是为了向整个开发过程提供关于被处理数据的描述和采集要求等的技术信息，以便生成和维护这些数据。主要内容应包括：引言；数据的逻辑描述及数据采集。详细内容及编写格式参见GB8567—88。
(7) 概要设计说明书
概要设计说明书也可称为“系统（或子系统）设计说明书”。其目的是说明一个软件系统的设计考虑，包括该软件系统的基本处理流程、系统的组织结构设计、接口设计、运行设计、数据结构设计和出错处理设计等。为程序的详细设计提供基础。
当一个软件系统的规模相当大时，往往划分成几个子系统。此时，应编制各子系统的概要设计说明书。
详细内容及编写格式参见GB8567—88。
（8）详细设计说明书
详细设计说明书也可称为“程序设计说明书”。其目的是说明软件系统中各个层次的每一个程序（每个模块或子程序）的设计考虑。如果一个系统比较简单，层次很少，则本文件可与概要设计说明书合并编写。主要内容应包括：引言；程序系统的组织结构及各程序模块的设计说明。编写格式参见GB8567—88。
（9） 数据库设计说明书
数据库设计说明书的目的是为设计软件系统所使用的数据库，以便具体建立这个数据库。如果该软件系统要使用的数据库不止一个，则应对每一个待建立的数据库编制一份数据库设计说明。主要内容应包括：引言；外部设计；结构设计；运用设计。编写格式参见GB8567—88。
（10）用户手册
用户手册应使用非专门术语的语言充分描述本软件系统所具有的功能及基本使用方法。使得用户（或潜在用户）能通过本手册了解本软件的用途，并能确定在什么情况下应如何使用它。主要内容应包括：引言；用途；运行环境；使用过程等。编写格式参见GB8567—88。
（11）操作手册
操作手册的作用是向操作人员提供本软件系统的每一个运行的具体过程和有关知识，包括操作方法的细节。主要内容有：引言；软件概述；安装与初始化；运行说明；非常规过程及远程操作。编写格式参见GB8567—88。
（12）模块开发卷宗
模块开发卷宗是在开发过程中逐步编写出来的。每审查完一个模块或一组密切相关的模块后编写一份。应该把所有的模块开发卷宗汇集在一起。编写本文件的目的是记录和汇总低层次开发的进度和结果，以便对整个模块开发工作进行管理和复审，并为将来的维护工作提供有用的技术信息。主要内容应包括：引言；模块开发情况表；功能说明；设计说明；源代码清单及本模块的修改历史；测试说明及复审。详细编写格式参见GB8567—88。
（13） 测试计划
为提高检测出错几率，使测试能有计划地、有条不紊地进行，必须编写测试文档标准化的测试文档就如同一种通用的参照体系，是为软件管理人员、开发人员、维护人员、质量保证人员、审计人员及用户提供的便于交流的工具和手段。测试文档主要包括：
1、 测试计划
2、 测试分析报告
测试计划文档是进行软件系统组装测试和确认测试的计划。包括每项测试活动的内容、进度和安排、设计考虑、测试数据的整理方法及评价准则等。编写格式参见GB9386—88《计算机软件测试文件编制规范》和GB8567—88。
（14）测试分析报告
测试分析报告以文件形式记载组装测试和确认测试的结果、发两年问题及其分析。内容应包括：引言；测试概要；测试结果及发现；对软件功能的结论；分析摘要及测试资源消耗。编写格式参见GB9386—88和GB8567—88。
（15） 开发进度月报
开发进度月报的目的是及时向有关管理部门汇报项目开发的进度和情况，以便及时发现和处理开发过程中的问题。开发进度月报一般以项目组为单位（当软件系统规模比较大时，则以分项目组为单位）编写。内容应包括：标题；工程进度与状态；资源耗用状态；经费开支状态；下个月的工作计划及建议。编写格式参见GB8567—88。
（16）项目开发总结报告
项目开发总结报告是为了总结本软件项目开发工作的经验与教训，说明实际取得的开发结果以及对整个开发工作各个方面的评价。主要内容应包括：引言；实际开发结果；开发工作评价；经验教训等。编写格式参见GB8567—88。
11．3．2 软件质量保证计划
11．3．2．1 软件质量保证计划的作用
软件是计算机程序、数据及其相关文档的总称。软件质量是指这些计算机程序、数据及其文档满足预定的需求说明的程度，以及它们的完备性和相互之间的一致性情况。为便于制定软件质量保证计划，表11-3-3给出了决定软件质量的质量因素及定义。
表11-3-3 软件质量因素定义
质量因素 定义
功能度 是指软件执行一系列与用户所说明及同说明有关需求相一致的功能的能力
可靠性 是指在规定条件下，在规定时间内，不引起系统失效的概率
可理解性 是指软件具有使用户容易理解、掌握、使用或评价该软件的能力
时间经济性 是指在规定或隐含的条件下，软件在适当的时间范围内，完成规定功能的能力
资源经济性 是指在规定和隐含的条件下，软件能用适当的资源完成规定功能的能力
可维护性 是指对已交付的软件进行修改的方便程度
可移植性 是指从一个环境转到另一个环境运行的能力。环境包括组织环境、硬件环境与软件环境
保密性 是指软件系统内部信息，不被非授权人误用、盗用或破坏的能力
完整性 是指对软件或数据所受到的未经获准的存取或修改可加以控制的程度
可再用性 是指整个软件或软件的一部分，可以被其他软件利用的能力
可连接性 是指整个软件或软件的一部分与其他软件或其他系统进行连接的难易程度
风险 是指按预定的成本和进度把系统开发出来，并且为用户所满意的程序（概率）
健壮性 是指硬件发生故障、输入的数据无效或操作错误等意外环境下，系统都能做出适当响应的程度
可用性 是每时系统在完成预定应该完成的功能时令人满意的程度
适应性 是指修改或改进正在运行的系统需要的工作量的多少
可测试性 是指软件容易测试的程度
互运行性 是指把该系统和另一个系统结合起来需要的工作量的多少
软件质量保证是采用系统工程方法评审或检查软件产品是否满足需求说明所要求的软件系统的功能和性能。主要由评审、测试和管理决策等三方面的工作组成。
要保证软件质量，就必须在软件开发/生产全过程的任何阶段全面注意、有效控制软件产品的各种性能。因此，必须制定科学的易于执行的软件质量保证计划，把确保软件产品最后质量的要求变成一步步可以控制、可以具体执行的各项工作，以便尽早发现影响产品质量的隐患，防止直到最后才发现软件产品不能满足需求而推倒重来的被动局面。
在编制软件质量保证计划中，采用下列缩写词：
（1） DDR详细设计评审（detailed Design Review）
（2） PDR概要设计评审 (Preliminmary Design Review)
（3） SDS软件设计说明 (Software Design Specification)
（4） SQA软件质量保证 (Software Quality Assurance)
（5） SQAP软件质量保证计划 (Software Quality Assurance Plan)
（6） SRR软件需求评审 (Software Requirements Review)
（7） SRS软件需求说明 (Software Requirements Specification)
（8） SVVP软件验证与确认计划 (Software Verification and Validation Plan)
（9） SVVR软件验证与确认报告 (Software Verification and Validation Report)
11．3．2．2 软件质量保证计划大纲及描述
软件质量保证计划规定项目承办单位必须准备一个包括下列各条内容的SOAP（简称计划）。以确保按项目或合同要求开发软件或以其他方式提供软件。计划中各条必须按给定的顺序排列，如有增删，应在相应的位置上附上增删的理由。
SQAP应当有一个封面，在封面上必须写明文档是“软件质量保证计划”，并写明该计划所属的软件项目的名称、计划拟定者、计批准人及批准日期。下面分别描述计划每一部分的详细需求。
（1） 引言
本条必须写明计划的总意图。
1、 目的：必须指明特定的SQAP的具体目的。
2、 范围：必须描述计划所针对的软件项目的名字和该软件的预期用途。
3、 定义和缩写词：应该列出计划中用到的、需要恰当解释的或在国家标准GB/T11457—89《软件工程术语》中尚未包含的术语和定义，必要时，还要给出它们的英文和缩写词。
4、 参考资料：必须提供SQAP中引用的所有资料的清单及这些参考资料的来源。
（2） 管理
本条必须描述SQA的机构、任务、职责和权限。
1、 机构：必须列出与SQA有关的机构的名称、组成、分工以及各部门之间的相互关系。
2、 任务：必须描述计划所涉及的软件生存周期中有关阶段的任务和这些阶段中的软件质量保证活动。
3、 职责和权限：必须指明负责每一个任务的机构，以及具体职责和权限。表11-3-4简述一个软件产品在开发过程中为保证软件产品质量的管理机制。
表11-3-4 软件产品在开发过程中的管理机制
职责 机构
与权限
任务
工程负责人
软件负责人
开发人员
用户
专家
报告书 提出
可行性报告 审批 提出 讨论 复审
需求分析 审批 提出 复审 复审
概要设计 审批 提出 提出 复审
详细设计 审批 提出
实现 参加 参加
测试 复审 参加 参加 复审 复审
注：工程负责人应该是SQA的负责人，其他人可以是SQA的成员。
（3） 文档
必须给出在软件的开发、验证和确认、以及使用和维护各阶段所用到的文档的定义，并描述核实这些文档适用性的办法。
1、 最小文档需求：为了确保软件的实现满足预定需求，规定至少需要下列文档：
A 软件需求说明（SRS）：SRS必须清楚、准确地按照国家标准GB9385《计算机软件需求说明编制指南》编写。
B 软件设计说明（SDS）：SDS包括概要设计和详细设计说明。SDS必须清楚、准确地按照国家标准GB8566—88和GB8567—88编写。
C 软件验证和确认计划（SVVP）：SVVP必须描述用来验证SRS中的需求已由SDS表达的设计所实现、SDS表达的设计已由编码所实现的方法。SVVP还必须描述用以确认编码的执行与SRS表达的需求相一致的方法。
D 软件验证和确认报告（SVVP）：SVVP必须描述SVVP的执行结果，包括SQAP所需要的所有评审、检查和测试结果。
E 用户手册和操作手册：必须清楚、准确地按照国家标准GB8567—88编写。
2、 其他文档。本条应列出可能包括的能够反映软件质量的其他文档。
（4） 评审和检查。本条必须制定评审和检查的规程。规定评审和检查的内容、组织形式、进度安排以及评审组织和项目承办单位的职责。评审是由有关专业人员或用户通过正式会议，评价软件需求，软件设计等文档。检查是由专业人员检查程序、文档等是否符合有关的技术规程或约定。
1、 在SQAP中应制定审查基线（结束标准）。
2、 在SQAP中应确定审查小组成员。
3、 在SQAP中应至少包括下列可能的步骤；
A 计划：组织审查组，分发材料，安排日程等。
B 概貌介绍：对该软件项目的功能、性能的简介。
C 准备：评审员阅读材料取得有关项目的知识。
D 评审会：目的是发现和记录错误。
E 返工：作者修正已经发现的问题。
F 复查：判断返工是否真正解决了问题。
4、 在SQAP中应制定复查和管理复查的计划：
A 复查：检查已有的材料，以断定各阶段的工作是否能够开始或继续。
B 管理复查：向开发组织或用户的管理人员，提供有关项目的总体状况、成本和进度等方面的情况。
5、 要进行的评审和检查的最小需求是：
A 软件需求评审（SRR）。进行SRR的目的是确保在SRS中的需求的合适性。
B 概要设计评审（PDR）。进行PDR的目的是确保SDS中软件概要设计部分在技术上的合理性。
C 详细设计评审（DDR）。进行DDR的目的是确保SDS中软件详细设计部分模块功能的正确性；控制结构、数据结构和算法的合理性；以及设计的程序与需求的一致性。
D 软件验证和确认评审。本评审是评价SVVP中定义的验证和确认方法的合适性与完备性。
E 功能检查。确认要交付的软件已经满足在SRS中规定的所有需求。
F 物理检查。对软件产品的各个部件的设计进行抽样的综合检查，以验证编码与设计文档的一致性、接口说明的一致性、设计实现与功能需求的一致性、以及功能需求与测试描述的一致性。
G 综合检查。对软件产品的各个部件的设计进行抽样的综合检查，以验证编码与设计文档的一致性、接口说明的一致性、设计实现一功能需求的一致性、以及功能需求与测试描述的一致性。
H 管理评审。定期地进行管理评审，以评价计划的执行情况。这些评审必须由独立于被评审单位的机构或授权的第三方进行。
6、 基本测试。本条必须制定要做的基本测试。测试过程中要产生如下文档：
A 测试计划
B 测试分析报告
（5） 问题报告、修正活动和配置管理。本条必须制定对软件的问题和缺陷进行检测、记录和修改的规程，并说明执行规程的机构和职责。规定应当包括如下内容：
A 向有关管理部门提交问题和缺陷的报告；
B 分析问题和缺陷的影响范围及产生原因；
C 评审修改结果；
D 分析或评审修改活动对项目或合同条款的影响。
E 实施软件配置管理计划。
（6） 质量记录和质量报告。
1、 项目承办单位必须准备和维护各阶段质量评价记录，并把这些记录妥善保存。
2、 项目承办单位必须准备各种质量报告，以使能对质量评价的结果和推荐意见进行管理。质量报告是质量评价的结果和推荐意见的总结报告。应视为一种文档保存。
3、 各阶段的质量记录和质量报告是最终质量检查的依据。
（7） 工具、技术和方法。本条必须描述支持特定项目的SQA的专用软件工具、技术和方法。
（8） 代码控制。本条必须定义用以维护和存储软件受控版本的方法和设施。
（9） 介质控制。本条必须指出用于保护存放计算机程序、数据及其文档的物理介质的方法和设施。
（10） 对项目承办单位的控制。如果项目承办单位用购买软件或委托子承办单位去获取软件，则本条必须列出确保软件销售单位提供的、或子承办单位获得的软件满足规定的技术需求的条款。软件销售单位或子承办单位至少必须准备一个与本规范一致的SQA计划。
（11） 记录的收集、维护和保存。本条必须指明要保留的SQA文档；必须指出用于汇总、保护和维护这些文档的方法和设施；并指明要保留的时间。
（12） 交付的准备工作。本条必须引用或制定一个规程，以确保软件产品在处理、存贮、保管、包装和运输过程中的安全和完整性。
图11-3-1 给出在软件开发生存周期各个阶段机构之间关系的例子。
工程负责人———— 用户
总控 集成
SQA 测试
SCM 管理
软件负责人
开发人员 开发人员
图11-3-1 工程机构图
11．3．3 软件配置管理计划
11．3．3．1 软件配置管理
在软件生存周期的各个基线上，都有一定的、规定要交付的文档、数据或程序，并对它们规定了格式和内容。这些已经规定好格式和内容的文档、数据或程序称之为软件配置项。而在软件生存周期各个阶段中某一时刻的文档、数据或程序的物理表达，则概括地称之为软件配置。
对软件配置的管理，就是采用系统方法保持不同阶段的软件配置的一致性和完备性。控制对软件配置的必要修改。设立机构对软件配置管理工作实施评审和检查。
在编制软件配置管理计划时，采用下列缩写词。
CCB配置控制委员会（Configuration Control Board）
SCM软件配置管理（Software Configuration Management）
SCMP软件配置管理计划（Software Configuration Management Plan）
有关SCM方面的名词定义参见国家标准GB/T11457—89《软件工程术语》。
11．3．3．2 软件配置管理计划大纲及描述
软件配置管理计划规定在开发各类软件，进行需求分析时，必须准备包括下列内容的软件配置管理计划（简称计划）。计划中的各条款都必须按以下给定的顺序排列，如有增删，应在相应的位置上附上增删的理由。
SCMP应当有一个封面，在封面上必须写明文档是：“软件配置管理计划”；并写明该计划所属的软件项目的名称、计划拟定者、计划批准人及批准日期。
SCMP正文部分分别描述计划各有关内容的详细需求。
（1） 引言
本条款必须写明计划总的意图。
1、 目的：必须指明特定的SCMP的具体目的。
2、 范围：必须描述要开发或要使用的软件项目、机构、活动和本计划适用的软件生存周期的各个阶段。由本计划控制的软件配置项至少要包括：
测试程序；
测试数据集；
验收程序；
诊断软件（可选）；
支持软件；
程序包；
文档集；
应用软件系统。
对于不同规模的软件项目，可选取以上所列软件配置项中若干项作为该计划的软件配置项。
表11-3-5给出了一个例子。供具体制定SCMP时参考。
表11-3-5 机构中各成员的职责
职责 工程负责人 软件负责人 SCM主管 SQA 开发人员
配置标识 提出
批准/释放技术文档 批准 提出 评审 评审
修改准备 提出
修改控制 批准
修改实现 批准 评审 提出
文档维护 批准
状态审计 提出 评审
正规检查 批准 提出 评审
基线定义 批准 提出 评审 评审
3、 定义和缩写词：应该列出计划中用到的、需要恰当解释的或在国家标准GB/T11457—89中尚未包括的术语和定义，必要时，还要给出它们的英文和缩写词。
4、 参考资料：必须提供SCMP中引用的所有资料的清单及这些参考资料的来源。
（2） 管理
本条描述负责软件配置管理的机构、任务及职责。
1、 机构：必须描述在开发、运行和维护各阶段中涉及SCM的组织机构。
2、 SCM职责：必须描述：
A 负责每个SCM任务的组织责任。如表11-3-5所列。
B 与软件质量保证、软件开发、以及其它用来确保交付经过批准的最终产品配置的那些机构的关系。如图11-3-1所示。
C 软件生存周期每一阶段的评审、检查和审批过程中用户的职责及开发/维护活动。
D 参加产品开发的各个单位的SCM职责。
E CCB的全部职责。
F 任何特殊职责。
G 对配置标识的描述。
H 对基线的描述（功能基线、指派基线、开发基线、产品基线）。
3、 控制接口：控制接口的处理方式与软件或文档的处理方式相同。必须在建立各种基线之前解决SQAP和SCMP之间的任何不一致的问题。所描述的内容是：
A 用以标识接口说明和控制文档的方法。
B 对已交付的接口说明和文档的修改进行处理的方法。
C 对要完成的SCM活动进行跟踪的方法。
D记录和报告接口规格说明和控制文档状态的方法。
E 控制软件和它赖以运行的硬件之间接口的方法。
4、 SCMP的实现：SCMP在领导批准之后，在用户参与评审之前实现。在SCMP制定之后，如发现问题，应在建立任何基线之前解决。为实现SCMP必须进行的主要工作是：
A 建立CCB；
B 各个配置基线的确定（表11-3-6）（详见SCM活动）；
C 接口控制协议的建立；
D 评审和检查SCM的计划和规程；
E 有关软件开发、测试和支持工具的配置管理。
表11-3-6 基线的目标
基线名称 目的 评审和检查
功能基线 分配功能 软件需求规格说明
指派基线 定义需求 软件规格说明
开发基线 完成概要设计
完成详细设计 概要设计
详细设计
产品基线 批准产品规格说明 功能配置检查
物理配置检查
5、 适用的政策、指令和规程：本条必须指明所有适用于SCM的、作为本计划要实现的政策、指令和规程；并且必须说明这些政策、指令和规程所要实现的程度；还必须详细描述要在本项目中编写和实现的有关SCM的政策、指令和规程。
（3） SCM的活动
本条必须描述如何满足配置标识、配置控制、配置状态记录和报告，以及检查和评审等方面的SCM需求。
1、 配置标识：在配置标识中必须详细说明软件项目在各个基线（最初批准的配置标识）上的文档、数据或程序的标识方法。必须描述下列内容：
A 每个基线的项。
B 与每个基线有关的评审和批准事项以及验收标准。
C 在建立基线的过程中用户和开发者的参与情况。
D 在软件生存周期中，主要有四种基线要描述：
功能基线（Functional Baseline）
是在系统分析与软件定义阶段结束时，开发者和用户就定义系统级功能和系统测试准则所达成的协议。功能基线按照经过批准的软件系统/子系统规格说明标识。
指派基线（Allocated Baseline）
是在需求分析阶段结束时，开发者和用户就定义软件的需求所达成的协议。指派基线按照经过批准的软件需求规格说明标识。
开发基线（Development Baseline）
在开发技术文档批准时建立开发基线，这些文档定义了该软件的概要设计和详细设计，其中包括接口和数据库方面的文档。对应于概要设计评审和详细设计评审这一段时间。开发基线按照经过批准的定义概要设计和详细设计的技术文档标识。
产品基线（Product Baseline）
是在软件完成和系统测试阶段结束时，开发者和用户就定义将要验收的软件产品的各个配置项的准确版本所达成的协议。产品基线按经批准的软件产品规格说明标识。这个规格说明包括概要设计规格说明、详细设计规格说明。
E 描述本项目所有软件代码源程序或目标程序和文档的标题、代号、编号、分类规程以及生成日期。
F 软件成分（软件配置项、部件和单元）标识。
2、 配置控制：配置控制是通过配置标识CCB、修改控制和状态审计等功能的实现完成。
A 必须描述在软件生存周期中每一阶段使用的修改批准权限的级别。
B 必须定义对已有配置的修改以及进行处理的步骤。
C 描述实现已批准修改建议的方法
D如果有必要修补目标代码，则要描述其标识和控制的方法。
E 对于每个CCB和其它管理修改的机构，必须定义它们的作用、权限和职责，任命领导人及其成员；必须说明CCB与开发者和用户的关系。
F 必须说明对超出本SCMP范围的程序/项目的接口进行配置控制的方法。
G 当本软件产品用到非交付的软件、现存软件、用户提供的软件和内部用的支持软件时，还必须说明对这些软件的配制控制规程。
3、 配置状态记录和报告
A 必须指明收集、验证、存储、处理和报告配置项目状态信息的办法。
B 必须说明要定期提供的报告的标识和分发办法。
C 指出应提供的动态查询的能力。
D 描述实现用户说明的特殊状态记录需求的手段。
4、 检查和评审：本条指出在SCMP中所定义的软件生存期的特定点上进行评审和检查时SCM的作用；标识每次检查和评审所包含的配制项目；指出用于标识和解决在检查和评审期间所出现的问题的规程。
A 功能配置检查。当完成验收测试后，由软件配置小组执行功能配置检查。查校验测试结果的完备性和准确性。记录检查日期、结果、问题、对解决问题的结果和评审的结果，记录应视同文档保存。
B 物理配置检查。是对配置项进行物理考察，以验证它的各个技术文档是前后一致的。在完成物理配置检查之后，用户要提出书面报告，表明用户对配置项及配置项产品规格说明是接受还是拒绝。
5、 软件配置复查。验收测试的一个重要内容是复查软件配置。复查的目的是保证软件配置的所有成分都齐全、各方面的质量都符合要求，具有维护阶段所必须的条件，而且已经编排好目录。
（4） 工具、技术和方法
本条描述支持特定项目的SCM的专用软件工具、技术和方法，指明其目的，描述在开发者所有权范围内的用途。
（5） 对项目承办单位的控制
本条描述确保软件销售单位提供的、或子承办单位获得的软件满足规定的SCM需求的条款；必须准备并实现一个与本规范一致的SCM计划。
（6） 记录的收集和保存
本条必须指出要保留的SCM文档，指明用于汇总、保护和维护这些文档的方法和设施（其中包括要使用的后备设施）。还必须清楚说明要保留的时间。
11．4 软件维护规范
11．4．1 软件维护定义
软件维护是软件生存周期中最后一个，也是持续时间最长、代价最大的阶段。强调指出软件维护的重要性，明确软件维护阶段的任务，清楚了解软件维护的定义和软件维护阶段必须遵循的一系列方法和要求，是重要的。
所谓软件维护，是指软件已正式交付使用之后，为了改正软件错误或满足新的软件需要，而对软件所进行的修改、扩充，从提出维护申请到完成维护的全过程。
11．4．2 软件维护的主要类型
软件维护通常主要包括改正性维护、适应性维护、完善性维护和预防性维护等四项维护活动 。
（1） 改正性维护
为了纠正在软件使用过程中暴露出来的软件错误而对软件进行的修改，称为改正性维护。
（2） 适应性维护
为了适应外部环境变化（包括软件工具、硬件环境或业务流程修改）而进行的软件修改称为适应性维护。
（3） 完善性维护
为了对原有软件中的功能进行扩充、完善的修改，称为完善性维护。
（4） 预防性维护
是对软件可能出现的“故障”所进行的预防性维护活动。
11．4．3 软件维护的申请与组织
软件维护过程，实质上是简化、压缩了的从软件定义到软件测试验收的软件开发的全过程，必须遵守严格的维护程序，进行严格的维护管理，才能确保维护活动的正确性、及时性。
（1） 维护申请
软件需要进行维护时，应首先提出维护申请，说明软件问题的发现时间、问题类型、维护目标等。交维护主管签署维护处理意见作为进行维护的依据。
（2） 维护的组织与实施
软件维护申请在得到批准后必须在严格的管理控制下实施。为此，在进行软件维护工作时，必须建立软件维护组织，该组织由维护主管、维护管理员、软件修改人员及用户代表组成。维护主管负责审批和下达软件维护任务；维护管理员则通过分析和评估维护申请报告，拟定维护方案，制定维护计划，组织或委派软件修改小组（或人员）；软件修改小组（或人员），根据维护主管和维护管理员提出的维护方案和计划，具体执行维护修改。
软件维护的实施与软件开发工作一样，按分析、设计、编码、测试和验收等步骤，遵循软件开发规范，生成与新的需求相一致的软件及与修改后编码相一致的文档。
软件维护结束后，要填写软件维护报告，作为一个维护过程完成的标志。软件维护报告的主要内容应包括：维护项目名称，版本号，软件变动描述，变动影响，测试及验收意见，并详细记录维护人员姓名及软件修改日期。
11．4．4 软件版本的更新和控制
（1） 软件版本的更新由软件开发或软件维护的主管部门控制。
（2） 软件维护主管应根据软件维护内容，向主管部门提出版本更新的申请。
（3） 由主管部门批准下发新的软件及相应的版本号。
11．5 软件管理
软件工程学包括软件方法、软件工具和软件管理等三个领域，每个软件项目从立项到验收、维护动贯着大量的管理工作。因此，软件管理是保证先进的技术和良好的软件工具能够充分发挥作用的关键。软件管理包括软件项目管理，软件验收规程，软件项目开发费用评估及软件产品登录等几个方面。
11．5．1 软件项目管理
为确保金融电子化系统建设中软件项目各阶段的任务能够顺利、正确地完成，必须严格遵守以下规定。
11．5．1．1 软件立项
（1） 立项论证报告
软件项目的提出，应在调查研究的基础上，写出“立项论证报告”。主要内容为：
1、 项目来源
2、 项目的目的和作用。
3、 国内外（或系统内外）同类项目的发展水平。
4、 项目的技术可行性。
5、 开发计划和费用。
6、 项目所必需的技术支撑。
7、 预期的经济和社会效益。
（2） 审批手续
立项论证报告提出后，一般项目由开发单位的技术负责人或技术委员会审议，并签署意见后，报上一级主管部门审批。
国家级攻关项目，在本单位涉及多个部门，技术上又有一定难度的大型软件系统开发，还应在上述审议审批之后，上报更高一级的主管部门审批备案。
11．5．1．2 主程序员组
每个软件项目还应根据项目规模的不同设立一个或几个程序设计小组。程序设计小组应在主程序员组的指导和参与下，进行具体开发工作。主程序员组的成员包括主程序员、辅助程序员和项目管理员。主程序员是由那些较有经验的程序员担任的，负责全系统的设计、编码、测试和安装；辅助程序员负责配合主程序员的工作，参加所有的具体工作，并能在必要时接替主程序员的工作；项目管理员负责与本项目有关的全部事务性工作。主程序员组的成员 ，应按软件开发过程中各阶段应遵循的规范及要求，负责该项目具体计划的制定和实施，负责指导并直接参与由他们负责的程序设计小组成员进行工作。
11．5．1．3 项目管理的任务
软件项目管理的任务是：
（1） 进度管理。对该软件项目的每个子项目（或每个阶段）到高层项目组制定计划，并按要求进行检查和调整。
（2） 资源管理。对整个项目所需的人力、经费、机时等方面的资源进行估计，充分掌握余量（一般余量应为需用资源的20%~40%），作出合理配置。
（3） 经费管理，对项目的经费管理，应按本规范11。5。3软件开发费用评估与管理进行管理。
（4） 质量保证工作。软件质量保证工作是确保软件产品质量，保证软件生产率的必要工作。软件质量保证计划的编制应按本远东11。3。2软件质量保证计划进行。
（5） 软件配置管理。软件项目的配置管理应按本规范11。3。3软件配置管理的要求制定该项目的软件配置管理计划，并对该项目各阶段的配置情况进行调整、记录，以适应该软件的最基本需求。
（6） 人员组织。软件项目立项后，应按本规范11。5。1。2的要求进行人员组织。
11．5．1．4 软件项目管理工具
（1） 利用软件生存周期中各阶段产生的文档进行管理。
（2） 利用通用的软件项目管理系统、故障分析报告系统进行管理。
11．5．2 软件验收
软件验收提出了金融电子化系统软件验收的基本规程及要求，强调软件验收的申请与组织。软件验收为软件开发各阶段建立了明确的结束标志，为软件的维护提供了必要的保证。
11．5．2．1
软件验收必须履行正式手续，由专门的软件验收组织遵循软件验收规程，按照软件需求说明书及合同，对开发单位完成的软件进行验收。验收规程如下：
（1） 开发单位向委托单位（用户）提交软件验收申请报告；
（2） 成立软件验收小组；
（3） 对文档进行验收；
（4） 功能演示；
（5） 验收测试；
（6） 对测试结果进行评审；
（7） 写软件验收报告。
11．5．2．2 软件验收的申请与组织
软件开发单位在开发任务完成之后，向委托单位（用户）提交由技术负责人签字的正式的软件验收申请报告。报告内容应包括：项目名称，软件功能和性能的描述，应交付的文档及这些文档是否通过了相应的评审。
软件验收小组由委托单位（用户）选派的人员，邀请的专家及开发单位的代表组成。
软件验收工作的全过程要有详细记录，包括：开发单位对验收小组提出的所有问题的解答；验收小组对该软件的评价及对该软件提出的修改建议是否被采纳和未被采纳的理由等。以上记录与被验收软件的验收测试结果，文档验收结果及验收评审结果，验收项目评价及意见，连同验收申请报告一起，作为本阶段产生的文档保留。
11．5．3 软件开发费用评估与管理
11．5．3．1 作用
软件开发费用评估是进行开发费用预算的科学方法；是确保软件产品质量养活经济损失和浪费，保证软件项目能够顺利进行的基础；并为投资单位进行投资决策提供依据。
本规范适用于项目委托单位、项目承办单位、软件开发单位和用户在洽谈软件开发费用及其管理办法时使用。
本规范要求经费预算者采用如下软件评估应用工具或软件估算技术。但也不排除采用更为先进的工具、技术和用户自定义的预算（评估）办法，但必须给出其评估依据和评估模式。
与本规范相关的主要名词术语定义如下：
（1） 软件产品的价值（Software Product Value）
是指开发该软件产品所耗费的设备折旧及其他物质消耗的价值、软件开发人员和有关的管理人员为自己劳动所创造的价值和他们为社会劳动所创造的价值之总和。
（2） 软件开发的人员的费用（Personal Cost For Software Development）
是指直接与软件开发有关的人员为自己劳动所创造的价值以及他们为社会所创造价值总和。
（3） 软件开发机时费用（Computer Hours Cost For Software Development ）
是指直接与软件开发有关所消耗的计算机终端机时费用、处理机时费用以及其他有关消耗器材费用之和，或指直接与软件开发有关消耗的折算计算机终端机时费用以及其他有关消耗器材费用之和。
11．5．3．2 软件开发费用的评估方法
（1） 评估依据（成本因素）
可以把成本因素划分成如下的生产因素、计算机因素、人员因素和项目因素等。
1、 生产因素
A 要求的软件可靠性；
B 数据库规模；
C 软件产品复杂程度。
2、 计算机因素
A 执行时间的约束；
B 存储约束；
C 环境变更率（软件外部环境在开发期间变动的频率和范围）；
D 计算机换向时间（程序设计环境的响应时间）。
3、 人员因素
A 系统分析员的能力；
B 应用经验；
C 程序员的能力；
D 环境知识；
E 语言知识。
4、 项目因素
A 程序设计实践；
B 软件工具；
C 进度约束；
D 软件程式规模。
5、 其他因素
A 语言；
B 实时应用；
C 软件类型；
D 经验
E文档数量；
F 用户要求和开发环境的稳定程度；
G 管理。
（2） 软件开发费用的评估公式（估算技术）
1、 Loc(Line of code )标准值法
L=(a+4m+b)/6
Ld={(∑[( b – a )/ b]2)1/2
工作量=修正量×（L/ 标准生产率）（人天）
其中：L——最佳期望行数；
Ld——行数的误差；
‘a’——最小规模（可能最小行数）；
‘b’——最大规模（可能最大的行数）；
‘m‘——最可能的规模（最可能的行数）；
注：‘a,b,m’是估算小组每个成员分别作出的估算。
上式中划横线表示为‘a,b,m’的平均值；
标准生产率——每人一天可能性开发的程序长度；
修正系数——其他因素对开发工作量的影响。
2、 CoCoMo(构造性成本模型)模型（Constructive Cost Model）
Y=CΣaiΧβ（‘i’从1到P）
其中：Y——工时数（开发工作量；以人月为单位）；
C——常数（模型系数）；
X——估算的代码行数（以千行为单位）；
P——成本因素个数（以个为单位，成本因素见估算依据）；
β——模型指数；
ai——成本因素。
3、 按人员费用和机时费用的估算法
在软件开发费用中分别算出开发软件的人年费用A和机时费用B。A可参考表11-5-1。B可参考表11-5-2。如果不是表中的机型，可以参照折算。
表11-5-1 软件开发人年费用
软件工种 金额（元/人年）
系统分析员，软件总体设计人员和系统测试人员 12000 ~ 15000
软件设计人员和综合测试人员 9000 ~ 12000
编程人员和程序单元测试人员 6000 ~ 9000
操作人员和数据录入人员 4000 ~ 6000
表11-5-2 软件开发中的机时费用
计算机类型 机时费用（元/H）
中、大型计算机 7 ~ 10
小型计算机 5 ～７
微型计算机 ３～５
注：表11-5-1，表11-5-2参照电子工业部1985年11月发布的《软件开发费用暂行结算办法》。
则：软件开发费用基础值C0=A+B
C0指包括交付软件后一年内正确性维护费用在内的软件基本开发费用。
由于各工种在整个开发项目中所占工时比例随项目性质而有所差异，所以有时需要计算出平均每个人月工作量所需要费用。一般来说：
系统分析，总体设计和系统测试约占总工时的20%
软件设计，综合测试约占总工时的40%
编码与调试约占总工时的40%
则软件开发的人月费用（平均）为
1/12 {（12000~15000）×20% +（9000~12000）×40% + （6000 ~ 9000）×40%}=（700 ~950）元/人月
软件开发费用C=K1K2K3K4C0
其中C0如前所述：
K1：物化因素。它是综合考虑了经营管理、固定资产折旧和水电消耗等费用后的修正系数，目前可取1.2—1.3。
K2：技术因素.它是考虑了资料、旅差、评审和咨询等费用后的修正系数。目前可取1.10-1.20。
K3：开发方式因素。它是考虑了软件产品的开发方式后的修正系数，目前可参照表11-5-3确定。
K4：质量等级。它是考虑了软件产品的质量后的修正系数，目前可参照表11-5-4确定。
表11-5-3 开发方式因素
软件产品的开发方式 K3
自行开发型 1.0
引进消化型 0.7~0.9
适应性改型 0.5~0.7
软件移植型 0.3~0.5
表11-5-4 软件质量等级
软件质量等级 K4
国际先进水平 1.5
国内先进水平 1.2
通过项目鉴定 1.0
除了上述三种软件费用评估方法外，目前应用比较多的还有人力（工作量）推算法；自顶向下估算法；自底向上估算法；相似比较估算法；规范法；比率估计算法（经验估算法）等。有关方法可以查阅《软件工程导论》和《软件工程规范选编》。
上述成本估算方法当前还不是精确的定量计算方法，它仅仅是基本定性的预算，为了达到准确的预算效果，可采用几种不同的估算技术相互校验。
（3） 估算应用工具
目前软件成本估算为国内外越来越多的人重视，不仅有软件成本估算技术，还有用软件成本估算技术编制的估算应用工具，使用估算应用工具，就可直接算出开发所需费用，但由于计算机系统之间的差异，使得估算应用工具的使用具有局限性。在此简单介绍几种目前国际上比较成熟的软件成本结算应用工具。
1、 适用于PC系列机的估算应用工具。
A SLCM (Software Life Cycle Mangement)
B SM10 (Software Model 10)
C PA2 (Planning Aid No.2)
2、 适用于小型机的估算应用工具
P3 (Programmer’s Personal Planner；P3)
上述估算应用工具的主要功能是：
A 估算开发软件的最低工期和相应的成本；
B 评估特定软件环境的生产力状况；
C 协助开发者投标。
（4） 经费支付方法和所有权
1、 软件开发费用的支付方法：见表11-5-5软件项目开发经费分期支付表
表11-5-5 软件项目开发经费分期支付表
金额支付时刻 支付合同金额初值的百分比
签订合同、项目开始 30%
概要设计完成进入详细设计 40%
通过司局院校所级鉴定 30%
合同结算在最终鉴定后进行 经过评审和协商确定
2、 软件产品的所有权
A 如果任务委托单位按本远东音乐会全部软件开发费用，则软件产品的所有权原则上完全属于任务委托单位。
B 如果任务委托单位所支付的软件开发费用比按本规范计算出来的软件开发费用要少，则该软件产品的所有权应按其投资比例分别属于软件开发单位和业务委托单位。
11．5．4 软件产品登录
11．5．4．1 作用
建立软件产品登录制度，是统一管理一有金融软件，准确、适时地安排软件项目开发，克服软件产品的质量差、成本高、维护困难和不易管理等弱点，解决金融系统研制软件过程中的重复开发和混乱局面的有效手段，对已成熟的金融软件产品，提供了扩大应用面的推广渠道。
软件产品登录数据库的建立将推动金融软件产品的流通和金融软件成果的技术转让，增进软件产品的信息交流。
11．5．4．2 软件产品登录资格
凡经过审定的金融软件产品均可登录。
11．5．4．3 登录内容
登录内容应是下述二十项条款的子集，当然也可根据情况增加登录条款，但增加的条款应设为附录。
（1） 软件名称：名称；源程序长度（KB）；目标程序长度（KB）；
（2） 登录者姓名或单位；
（3） 开发或协作单位；
（4） 开始使用时间：第一个用户正式投入非实验性业务运行的日期；
（5） 鉴定情况：鉴定部门或单位，鉴定日期，鉴定评语摘要；
（6） 获奖情况：授奖部门或单位，获奖日期，获奖等级；
（7） 更新情况：软件产品版本号，版权归属；
（8） 使用情况：现有用户总数，用户评价；
（9） 联系人情况：姓名或单位，地址，电话等；
（10） 硬件配置：采用的主要机型，其他机型，内存要求，外存要求，外部设备要求；
（11） 软件配置：操作系统，应用软件包（其他支持软件），数据库，文件系统，编程语言，所配汉字系统；
（12） 网络通讯配置：采用的网络技术，使用的网络结构，通讯手段；
（13） 软件产品类型：系统软件，应用软件，工具软件，其他软件；
（14） 软件产品适用范围：软件产品所能完成的主要功能；
（15） 处理方式：联机或脱机，实时或分时；
（16） 文档资料：软件产品生产过程中产生的全部文档清单，包括用户手册和使用手册；
（17） 设计特点、功能简介；
（18） 使用的主要软件技术；
（19） 效益：经济效益，社会效益；
（20） 其他：补充项目和说明。
11．5．5 软件产品的版权
登录后的软件产品的版权，参照国家有关软件产品版权法规或条例执行。
参考资料
（1） 张海藩编，《软件工程导论》，清华大学
（2） 《国家经济信息系统设计与应用标准化规范》
（3） 航空工业间软件工程工作小组编，《软件工程规范汇编》，航空工业部科学技术局印
（4） 周伯生编，《软件工程规范选编》，北京航空学院出版
更多内容:
麻省理工算法导论翻译
http://blog.csdn.net/ctu_85/archive/2007/06/08/1643179.aspx
浙江大学ACM试题解答(四月)
http://blog.csdn.net/ctu_85/archive/2007/04/24/1576831.aspx
浙江大学ACM试题解答(三月)
http://blog.csdn.net/ctu_85/archive/2007/03/20/1535556.aspx
华容道游戏与算法
http://blog.csdn.net/ctu_85/archive/2007/05/15/1610722.aspx
中国象棋对战程序C语言源代码
http://blog.csdn.net/ctu_85/archive/2007/05/04/1596351.aspx
三维建筑物图像的二维建模
http://blog.csdn.net/ctu_85/archive/2006/12/20/1451106.aspx
分段线性骨架
http://blog.csdn.net/ctu_85/archive/2006/06/15/799847.aspx
基于图论的图像分割技术
http://blog.csdn.net/ctu_85/archive/2006/06/15/799857.aspx
Linux文件系统
http://blog.csdn.net/ctu_85/archive/2006/06/12/791644.aspx
分层模型
http://blog.csdn.net/ctu_85/archive/2006/06/07/777997.aspx
汉语编程企业管理应用软件可行性研究报告
http://blog.csdn.net/ctu_85/archive/2007/01/22/1490139.aspx
汉语编程企业管理应用软件需求说明书
http://blog.csdn.net/ctu_85/archive/2007/01/22/1490136.aspx
计算机专业操作系统课程设计报告
http://blog.csdn.net/ctu_85/archive/2007/01/22/1490130.aspx
软件可行性报告
http://blog.csdn.net/ctu_85/archive/2006/06/06/775894.aspx
软件需求分析报告
http://blog.csdn.net/ctu_85/archive/2006/06/06/775892.aspx
两种计算Ack(m,n)的非递归算法
http://blog.csdn.net/ctu_85/archive/2006/11/29/1419396.aspx
浙江大学计算机复试解答1
http://blog.csdn.net/ctu_85/archive/2006/10/15/1334936.aspx
浙江大学计算机复试解答2
http://blog.csdn.net/ctu_85/archive/2006/10/16/1336101.aspx
浙江大学计算机复试解答3
http://blog.csdn.net/ctu_85/archive/2006/11/02/1363159.aspx
C++Primer 第四版 部分习题解答
http://blog.csdn.net/ctu_85/archive/2007/07/04/1677834.aspx
发表于 @ 2007年11月30日 15:23:00|