金财工程应用支撑平台.docx
《金财工程应用支撑平台.docx》由会员分享，可在线阅读，更多相关《金财工程应用支撑平台.docx（26页珍藏版）》请在冰豆网上搜索。
金财工程应用支撑平台
金财工程应用支撑平台
部署实施监理需求
一、项目概述
（一）项目背景
近年来，随着财政改革的不断深化，“金财工程”建设取得了较大进展，初步形成了以预算管理为源头，以国库收支管理为预算执行主线的系统框架，并在中央财政和地方财
政部门逐步得到推广应用，为财政改革顺利推进、加强财政管理提供了较有力的技术支撑。
但是“金财工程”建设也存在一些问题，如信息系统繁多、技术规范不统一、系统间口径
及编码不一致、编制与执行没有实现无缝链接等问题。
为了解决存在的问题，财政部于2005年开始组织建设了“金财工程”应用支撑平台（简称支撑平台），启动了大系统的建设工作。
根据《财政部关于金财工程应用支撑平台在地方推广实施工作的通知》（财办[2009]3号）
要求，天津市财政局于2009年正式启动支撑平台的推广实施工作，立足于天津市现有财政业务的整体性，按照平台建设思路，规划构建财政主体业务全面贯通、处理自动化的财政管理信息系统。
（二）实现目标
通过“金财工程”应用支撑平台，整合目前我市财政应用，构建以跟踪和控制资金运行过程为核心，完善的、与公共财政职能相适应的一体化财政管理信息系统，解决当前系统间存在的流程割裂、信息孤岛问题，实现信息共享和互联互通，为建立公共财政框架体系，实现财政管理的科学化、规范化、现代化提供技术保障。
具体的建设目标如下：
1、覆盖财政主体业务
一体化系统包括部门预算管理系统、预算指标管理系统、国库集中支付管理系统、非税收入收缴管理系统、财政总账管理系统、财税库联网系统等。
完整描述财政往来资金的来源、数量、用途等要素，为政府财政管理提供结构化数据基础。
2、遵循规范标准
按照财政部颁发的《财政业务基础数据规范》（中华人民共和国财政部标准[CZ0001-2008]），梳理天津市财政业务系统，形成规范的天津市财政业务基础数据标准，结合平台对标准数据的实现方式，在平台中进行配置，并在系统中得以应用。
通过平台实
现市本级和各区县级业务系统的数据共享、工作协同。
3、实现三通
1
一体化应用之后要实现财政系统内部、财政系统上下级之间、财政与相关其他部门通
过一体化系统进行信息共享和数据交换。
4、适应未来扩展，提供数据依据
一体化系统要从结构上适应未来财政改革，系统根据管理的需要能较快速做出调整，
适应财政业务和管理的需要。
同时，为财政决策提供完整准确、及时合理的数据依据，充
分发挥数据资源的作用。
二、监理项目要求
（一）监理期包括项目设计、实施并验收合格全过程，监理阶段及监理对象如下：
1、项目设计阶段：
项目计划制定、系统需求分析、系统结构设计、系统硬件设计、
系统网络设计、系统安全设计；
2、项目实施阶段：
软件需求分析、软件结构设计、软件详细设计、软件编码和测试、
软件集成、软件合格性测试、硬件安装、网络部署、安全部署、系统集成；
3、项目验收阶段：
培训、系统初验、系统试运行、系统终验、工程移交；
4、项目支持过程：
文档编制过程、配置管理过程、质量保证过程、变更控制过程；
5、监理范围：
包括所有天津支撑平台建设相关项目，直至市级支撑平台建设完成，
包括运行支撑平台所需硬件的部署实施、测试联调，软件接入、生长开发等。
（二）监理项目具体内容
1、项目设计阶段监理
1.1主要监理目标
1.1.1监理方需协助天津市财政局审查承建单位的项目计划，确保项目计划的合理性、
可行性，并满足服务合同要求。
1.1.2监理方需监督承建单位系统需求分析过程,督促承建单位和天津市财政局共同合
作建立系统需求，并纳入配置管理，促使系统需求的正确性、完备性、准确性、可测试性和
一致性。
1.1.3监理方需协助天津市财政局评审承建单位的项目的总体设计方案，促使总体设计
方案满足项目的系统需求和有关的法规、标准，并符合服务合同要求。
1.2项目计划制订的监理
1.2.1监理方需要求承建单位制定项目计划并形成文档、提交天津市财政局，计划中应
包含的项目主要包括下列：
a）项目的组织结构（包括外部组织）、人员职责及其能力要求；
b）项目环境，包括测试环境、程序库、设备、设施、标准、规程和工具；
c）任务分解安排，连同预算、人员、物理资源、软件规模和相关的任务进度安排；
2
d）进度安排、跟踪和报告方法；
e）软件产品或服务的质量特性的管理，可以制订独立的质量保证计划；
f）软件产品或服务的安全、保密安全和其他关键需求的管理，可以制订独立的安全、保密安全计划；
g）如分包，分包单位的管理；
h）如分包，验证和确认方式和条件；
i）风险管理；
j）用户培训计划。
1.2.2监理方需评价工程计划，评价时要考虑如下准则，并形成监理意见、提交天津市
财政局。
a）与服务合同的可追溯性；
b）系统范围及工作任务分解的完整性；
c）项目生存周期过程及重要里程碑划分的合理性，包括适宜的软件生存周期模型；
d）项目估计方法的正确性，对项目任务和工作产品规模、时间安排、资源的估计；
e）项目进度计划的合理性，包括项目质量保证计划、配置管理计划等；
f）项目计划中硬件部分的协调和实施的可行性；
g）对项目风险进行了必要的识别、分析、处理和跟踪。
1.2.3监理方需督促天津市财政局和承建单位适时对项目计划及有关附属计划进行评
审，并及时取得各方对项目划的书面批准和承诺。
1.2.4监理方需在了解系统内容和项目计划的基础上，根据如下准则制定监理实施细则，
并提交天津市财政局。
a）与监理规划的可追溯性、一致性；
b）与业务目标的符合性；
c）与专业工程的符合性；
d）监理工作流程、控制要点、监理方法的可行性。
1.3系统需求分析阶段的监理
1.3.1监理方需要求天津市财政局实施部门及承建单位（下称承建单位）为系统需求分
析过程的实施制定详细的计划并提交天津市财政局。
1.3.2监理方需监督承建单位按照计划的要求开展系统需求分析活动。
1.3.3监理方需要求天津市财政局单位及承建单位定义并分析系统建设目标。
监理方需
要求天津市财政局和承建单位定义并分析业务流程再造、业务持续改进、信息资源规划及业
务指标评价体系。
1.3.4监理方需要求承建单位分析系统需求，并形成系统需求文档。
对系统需求规格说
明书编制及其变更的监理参照文档管理监理和配置管理监理过程。
系统需求文档应包含以下
3
内容，监理方应形成对系统需求和对天津市财政局组织评价系统需求的监理意见，并提交天
津市财政局。
a）系统的功能和性能；
b）业务、组织和用户的需求及相关方的需要；
c）接口要求；
d）运行和维护的需求；
e）系统设计限制因素；
f）系统评审和验收测试方面的需求；
g）安全和保密的需求；
h）法律法规要求、合同要求、以及有关技术标准要求。
1.3.5监理方需协助天津市财政局单位组织通过评审、确认、联合评审等方式评价系统
需求。
评价时要考虑下列准则：
a）与合同的可追溯性、一致性；
b）业务目标及系统建设目标的可追溯性、一致性；
c）基于信息资源规划和业务指标评价体系的可测试性；
d）业务流程再造、业务持续改进、信息资源利用的可行性；
e）系统结构设计的可行性；
f）运作和维护的可行性。
1.3.6监理方需要求承建单位编制系统验收初步方案，并提交天津市财政局。
1.3.7监理方需监督承建单位解决系统需求分析中发现的问题和不合格项，并形成监理
意见、提交天津市财政局。
1.4系统结构设计阶段的监理
1.4.1监理方需要求承建单位为系统结构设计过程的实施制定详细的计划，并提交天津
市财政局。
1.4.2
监理方需监督承建单位按照计划的要求开展系统结构设计活动。
1.4.3
监理方需协助天津市财政局制定相应业务指标评价体系，监督承建单位对系统结
构开展合理的方案设计。
监理方需协助天津市财政局制定计划并按照计划的要求开展业务流
程再造、业务持续改进、信息资源利用的设计活动。
1.4.4监理方需要求承建单位依据计划进行系统结构设计，并形成系统结构设计文挡。
对系统结构设计书编制及其变更的监理参照文档管理监理和配置管理监理过程。
监理方需检
查系统结构设计书包含如下内容，并形成监理意见、提交天津市财政局：
a）应建立系统的顶层结构；
b）系统结构应标出硬件、软件和人工操作项；
c）应保证所有系统需求分配到各项中；
4
d）应顺序标出硬件配置项、软件配置项和手工操作项；
e）分配到各项中的系统结构和系统需求应形成文档。
1.4.5监理方需协助天津市财政局单位组织通过审核、确认、联合评审等方式评价系统
结构设计。
评价时要考虑下列准则。
a）与合同的可追溯性、一致性；
b）与业务目标的符合性；
c）系统需求的可追溯性、一致性；
d）所使用的设计标准和方法的适宜性；
e）软件项满足指定需求的可行性；
f）基于信息资源规划和业务指标评价体系的可测试性；
g）业务流程再造、业务持续改进、信息资源开发的可行性；
h）运作与维护的可行性。
1.4.6监理方需监督承建单位解决系统结构设计中发现的问题和不合格项，并形成监理
意见、提交天津市财政局。
2、软件工程实施阶段监理
2.1主要监理目标
2.1.1监理方需协助天津市财政局评审承建单位的软件需求分析文档，确保软件需求分
析文档满足系统需求和系统设计方案的要求；
2.1.2监理方需检查、评审、督促承建单位的软件结构设计活动和文档满足软件需求分
析文档的要求；
2.1.3监理方需督促承建单位的软件详细设计活动和文档满足软件需求分析文档的要
求；
2.1.4监理方需检查、评审、督促承建单位的软件编码活动和结果满足软件设计文档的
要求；
2.1.5监理方需监督承建单位的软件集成活动，验证软件集成符合软件设计的要求；
2.1.6监理方需协助软件合格性测试的活动，验证软件符合软件需求的要求；
2.1.7监理方需监督承建单位的系统集成活动，验证系统集成符合系统设计的要求。
2.2软件需求分析阶段的监理
2.2.1监理方需要求承建单位为软件需求分析过程的实施制定详细的计划。
2.2.2监理方需监督承建单位按照计划的要求开展软件需求分析活动。
2.2.3监理方需要求承建单位分析软件需求并形成文档，对软件需求说明书编制及其变
更的监理参照文档管理监理和配置管理监理过程。
系统需求文档应包含以下内容，监理方需
形成对软件需求和对天津市财政局组织评价软件需求的监理意见并提交天津市财政局。
a）功能与能力规格说明，包括性能、物理特性和软件项执行的环境条件；
5
b）软件项的外部接口；
c）鉴定需求；
d）安全规格说明，包括那些与运作、维护相关的方法、环境影响和人为损坏；
e）保密安全规定，包括那些与敏感信息相关的泄露；
f）数据定义和数据库需求；
g）在运作和维护场所，对已交付的软件产品的安装与验收需求；
h）用户文档；
i）用户操作与执行需求；
j）用户维护需求。
2.2.4监理方需协助天津市财政局通过审核、联合评审、确认等方式评价软件需求，评
价时宜考虑下列准则：
a）与合同的可追溯性和一致性；
b）与业务目标和系统建设目标的一致性；
c）系统需求和系统设计的可追溯性、一致性；
d）内部一致性；
e）基于信息资源规划和业务指标评价体系的可测试性；
f）业务流程再造、业务持续改进、信息资源开发的可行性；
g）软件设计的可行性；
h）运作和维护的可行性。
2.2.5监理方需监督承建单位解决软件需求分析中发现的问题和不合格项，并形成监理
意见、提交天津市财政局。
2.3软件结构设计阶段的监理
2.3.1监理方需要求承建单位为软件结构设计过程的实施制定详细的计划。
2.3.2监理方需监督承建单位按照计划的要求开展软件结构设计活动。
2.3.3监理方需要求承建单位把软件项的需求转变为一种描述其顶层结构的结构图，并
且标识出软件的各个部件，并形成文档、提交天津市财政局。
对此文档编制及其变更的监理
参照文档管理监理和配置管理监理过程。
2.3.4监理方需检查承建单位编制的接口的顶层设计和数据库的顶层设计。
2.3.5监理方需检查承建单位编制用户文档的最初版本。
2.3.6监理方需检查承建单位规定软件集成的初步测试需求和进度安排。
2.3.7监理方需评价软件项接口和数据库设计结构，评价时宜考虑下列准则，评价结果
应形成监理意见，并提交天津市财政局。
a）软件项需求的可追溯性；
b）与软件项需求的外部一致性；
6
c）软件部件之间的内部一致性；
d）所采用的设计方法和标准的适宜性；
e）详细设计的可行性；
f）运作与维护的可行性。
2.3.8监理方需监督承建单位解决软件结构设计中发现的问题和不合格项，并形成监理
意见、提交天津市财政局。
2.4软件详细设计阶段的监理
2.4.1监理方需要求承建单位为软件详细设计过程的实施制定详细的计划。
2.4.2监理方需监督承建单位按照计划的要求开展软件详细设计活动。
2.4.3监理方需要求承建单位编制软件项的每一软件部件的详细设计，并形成文档、提
交天津市财政局。
对详细设计编制及其变更的监理参照文档管理监理和配置管理监理过程。
2.4.4监理方需检查承建单位编制的接口的详细设计和数据库的详细设计。
2.4.5监理方需检查承建单位及时更新的用户文档、测试需求和软件集成进度安排。
2.4.6监理方需要求承建单位规定要测试的软件单元的测试需求和进度安排。
测试需求
宜包括对软件单元在需求边界的强化要求。
2.4.7监理方需评价软件详细设计和测试需求，评价时宜考虑下列准则，评价结果应形
成监理意见，并提交天津市财政局。
a）软件项需求的可追溯性；
b）与结构设计的外部一致性；
c）所采用的设计方法和标准的适宜性；
d）测试的可行性；
e）运作与维护的可行性。
2.4.8监理方需监督承建单位解决软件详细设计中发现的问题和不合格项，并形成监理
意见，提交天津市财政局。
2.5软件编码和测试阶段的监理
2.5.1监理方需要求承建单位为软件编码过程的实施制定详细的计划。
2.5.2监理方需监督承建单位按照计划的要求开展软件编码活动。
2.5.3监理方需监督承建单位按照测试需求和进度安排进行单元测试。
2.5.4监理方需检查承建单位单元测试过程中的错误的记录及其改正。
2.5.5必要时，监理方需检查承建单位及时更新的用户文档。
2.5.6必要时，监理方需检查承建单位及时更新的测试需求和软件集成进度安排。
2.5.7必要时，监理方需评价软件编码和测试结果，评价时宜考虑下列准则，评价结果
应形成监理意见，提交天津市财政局。
a）软件项需求和设计的可追溯性；
7
b）与软件项的需求及设计的外部一致性；
c）所采用的编码方法和标准的适宜性；
d）软件集成与测试的可行性；
e）运作与维护的可行性。
2.6软件集成阶段的监理
2.6.1监理方需要求承建单位制订集成计划。
计划宜包括测试需求规程、数据、职责和
进度安排。
2.6.2监理方需监督承建单位按照计划的要求开展软件集成活动。
2.6.3监理方需要求承建单位按照集成计划将软件单元和软件部件作为集合体进行集
成，并测试，并形成文档、提交天津市财政局。
对集成和测试结果的编制及其变更的监理参
照文档管理监理和配置管理监理过程。
2.6.4监理方需检查承建单位及时更新的用户文档。
2.6.5监理方需评价集成和测试结果，评价时宜考虑下列准则。
评价结果应形成监理意
见，并提交天津市财政局。
a）系统需求的可追溯性；
b）与系统需求的外部一致性；
c）内部一致性；
d）软件项需求的测试范围；
e）所采用的测试标准和方法的适宜性；
f）与预期结果的符合程度；
g）软件合格性测试的可行性；
h）运作与维护的可行性。
2.6.6监理方需监督承建单位解决软件集成中发现的问题和不合格项，并形成监理意见、
提交天津市财政局。
2.7软件合格性测试阶段的监理
2.7.1监理方需要求承建单位为实施软件合格性测试而对软件项的每一鉴定需求，开发
确定的测试集、测试用例（输入、输出、测试准则）以及测试规程。
2.7.2监理方需监督承建单位按照计划的要求开展软件合格性测试活动。
2.7.3监理方需要求承建单位按照软件项鉴定需求实施合格性测试，并形成文档、提交
天津市财政局。
对此测试文档编制及其变更的监理参照文档管理监理和配置管理监理过程。
2.7.4监理方需检查承建单位及时更新的用户文档。
2.7.5监理方需评价设计、编码、测试、测试结果和用户文档，评价时宜考虑下列准则。
评价结果应形成监理意见，并提交天津市财政局。
a）与合同的一致性；
8
b）软件项需求的测试范围；
c）与预期结果的符合程度；
d）如果实施时系统集成和测试的可行性；
e）运作与维护的可行性。
2.7.6当要获取现货软件产品时，监理方需验收现货软件产品是否满足下述条件，结果
形成监理意见，并提交天津市财政局：
a）满足合同的要求；
b）满足系统建设目标和系统需求；
c）具有有效的文档；
d）满足知识产权的要求；
e）有此软件产品的未来支持计划。
2.7.7监理方需监督承建单位解决软件合格性测试中发现的问题和不合格项，并形成监
理意见，并提交天津市财政局。
2.8系统集成阶段的监理
2.8.1监理方需要求承建单位制订的集成计划。
计划应包括测试需求规程、数据、职责
和进度安排。
计划应形成文档。
2.8.2监理方需监督承建单位按照集成计划集成、测试并形成文档。
对此测试文档编制
及其变更的监理参照文档管理监理和配置管理监理过程。
2.8.3监理方需评价已集成的系统，评价时宜考虑下列准则。
评价的结果应形成监理意
见，并提交天津市财政局。
a）与合同的一致性；
b）与系统需求的一致性；
c）业务目标的符合性
d）所采用的测试方法和标准的适宜性；
e）与预期结果的符合程度，包括但不仅限于与信息资源规划、业务流程再造需求及业务持续改进需求和业务指标评价体系的符合程度；
f）系统合格性测试的可行性；
g）运作与维护的可行性。
2.8.4监理方需监督承建单位解决系统集成中发现的问题和不合格项，并形成监理意见，
并提交天津市财政局。
3、项目验收阶段监理
3.1主要监理目标
3.1.1监理方需跟踪培训过程，评价培训效果，促使培训达到合同的要求。
3.1.2监理方需明确工程初验方案的符合性及可行性；协助天津市财政局单位进行系统
9
初验，验证是否符合系统的需求。
3.1.3监理方需监督试运行的过程，促使发现的问题得到解决。
3.1.4监理方需协助天津市财政局单位进行最终验收，验证软件系统的最终功能和性能
符合项目需求以及承建合同、法律、法规和标准的要求。
3.1.5监理方需协助天津市财政局单位进行项目的移交工作，促使软件系统顺利投入正
式运行。
3.2培训阶段的监理
3.2.1监理方需要求承建单位确定培训的类型、水平以及需要培训人员的类别。
应制订
实施进度安排、资源需求和培训需求的培训计划，并形成文档、提交天津市财政局。
3.2.2监理方需监督承建单位按照计划的要求开展培训阶段的活动。
3.2.3监理方需要求承建单位确保拥有合理搭配的、各种类别的、拥有相关培训能力的
合格的培训的讲员。
3.2.4监理方需要求承建单位对培训进行记录并保存，并将有关文档提交天津市财政局。
3.2.5监理方需依据培训的需求、培训的计划和培训的记录评价培训效果。
评价结果应
形成监理意见，并提交天津市财政局。
3.3系统初验阶段的监理
3.3.1监理方需对承建单位的初验申请进行审查。
初验条件应符合合同规定的初验条件，
还宜包括如下内容：
a）软件实施工作已经结束；
b）合同规定的各类文档齐全；
c）软件产品已置于配置管理之下；
d）监理方应要求承建单位提交第三方测试机构出具的测试报告；第三方测试机构经天津市财政局招标后确认。
3.3.2监理方需审查承建单位提交的验收方案的符合性（验收目标、责任双方、验收提
交清单、验收标准、验收方式、验收流程、验收环境等）及可行性。
3.3.3监理方需对承建单位提交的文档进行审核，并形成文档、提交天津市财政局。
3.3.4监理方需协助天津市财政局通过测试软件产品在目标环境的选定区域中的适用
性，以确认软件产品满足它的预期用途，评价时应参考业务指标评价体系并宜考虑下列准则。
评价结果应形成文档并提交天津市财政局。
a）与合同的一致性；
b）与系统需求的一致性；
c）与预期结果的符合程度，包括但不仅限于与信息资源规划、业务流程再造需求及业务持续改进需求和业务指标评价体系的符合程度；
d）与业务需求的符合程度；
10
e）运作和维护的可行性。
3.3.5监理方需监督承建单位解决系统初验中发现的问题和不合格项，并形成监理意见、
提交天津市财政局。
3.4系统试运行阶段的监理
3.4.1监理方需要求承建单位为系统试运行过程的实施制定详细的计划。
3.4.2监理方需监督承建单位协助天津市财政局的系统安装活动。
安装活动和结果应形
成文档，并提交天津市财政局。
3.4.3当安装的软件产品正在代替现有系统时，监理方需检查承建单位支持合同要求的
并行运行活动。
3.4.4监理方需协助承建单位和天津市财政局单位按照计划实施试运行活动。
3.4.5监理方需要求承建单位配合天津市财政局单位试运行过程中的测试，测试的结果
应形成文档。
3.4.6监理方需监督承建单位解决系统试运行中发现的问题和不合格项，并形成监理意
见，并提交天津市财政局。
3.5系统终验阶段的监理
3.5.1监理方需要求承建单位按合同中的规定提供评价、评审、审核、测试和解决问题
的报告、提交天津市财政局。
并审核是否达到合同规定的验收条件，验收条件还宜应包括如
下内容：
a）满足初验的条件；
b）初验合格；
c）试运行正常并且出现的问题已经得到解决；
3.5.2监理方需协助天津市财政局根据已确定的验收策略和准则准备验收，宜包括准备
测试用例、测试数据、测试规程和测试环境。
需确定承建单位参与的程度。
3.5.3监理方需协助天津市财政局对可交付软件产品或服务进行验收评审和验收测试，
并形成文档，提交天津市财政局。
3.5.4监理方需协助天津市财政局验收系统，评价时应参考业务指标评价体系并宜考虑
下列准则。
评价结果应形成监理意见，并提交天津市财政局。
a）与合同的一致性；
b）与系统需求的一致性；
c）与业务需求的符合程度；
d）与预期结果的符合程度，包括但不仅限于与信息资源规划、业务流程再造需求及业务持续改进需求和业务指标评价体系的符合程度；
3.5.5监理方需监督承建单位解决系统终验中发现的问题和不合格项，并形成监理意见、
提交天津市财政局。
11
3.6项目移交阶段的监理
3.6.1监理方需要求承建单位提交交付文书，交付文书宜包括软件交付清单、相关工程
文档和
升级会员 