12366系统.docx
《12366系统.docx》由会员分享，可在线阅读，更多相关《12366系统.docx（23页珍藏版）》请在冰豆网上搜索。
12366系统
天津市地方税务局“12366纳税服务系统建设项目”
监理项目需求书
一、“12366纳税服务系统建设项目”项目概述
（一）项目介绍
“天津市地税局12366纳税服务系统”的建设是贯彻落实天津市委、市政府和国家税务总局建设服务型政府的要求，构建公正、公开和文明的税收法制环境，建立和完善以税收信息服务、纳税程序服务、纳税救济服务、纳税权益服务等为主体的纳税服务体系的重要举措。
通过应用先进的信息技术，使纳税服务系统成为天津地税为纳税人提供办税服务、涉税信息查询服务、税收征管引导服务、涉税投诉举报服务和实时在线咨询等服务内容的重要载体。
1.项目建设的指导思想
“天津市地税局12366纳税服务系统”的建设要牢固树立征纳双方法律地位平等的理念，公正、公开和文明执法是最佳服务的理念，纳税人正当需求应予合理满足的理念，做到依法、公平、文明服务。
要始终贯穿“一体化服务”的思想:
即通过系统的建设，使12366纳税服务系统成为天津市地税局规范纳税服务的统一入口、出口和窗口。
成为纳税人服务资源的统一调度平台。
要通过系统的建设，整合当前分散的服务资源打造一体化的服务品牌，形成12366集中座席和各区县局远端座席上下紧密互动，12366内部快速反应的扁平化的工作模式。
通过规范服务内容和服务渠道，切实提高天津地税12366的服务水平和影响力，促进纳税人自觉主动依法纳税，不断提高纳税人的满意度和税法遵从度。
2.项目建设的主要目标
12366纳税服务系统是天津地税建立的一个面向天津所有纳税人及社会公众，融合语音、信息门户、短信、传真、电子邮件等多种服务渠道，覆盖网上办税、语音咨询、在线技术支持和涉税信息查询等功能的全方位纳税服务系统。
依照总体规划、分步实施的建设原则，本期项目建设的目标确定为：
构建一个易于扩展的纳税服务系统。
本次建设的内容主要是包括语音、传真、短信、座席管理系统、报表管理系统、任务管理系统、知识库系统等功能的呼叫服务系统，同时还要建立一个包括留言板、在线交流、邮件服务、护航浏览等功能的网上12366服务管理系统。
在此基础上，根据纳税服务工作的总体要求和实际需要，逐步完善服务功能、丰富服务资源、扩展服务手段，构建全方位的纳税服务体系。
3.项目建设具体要求
天津市地方税务局作为政府职能部门，其服务的质量直接影响到政府的公众形象，直接影响到政府部门为社会提供高质量的公共服务。
因此，12366纳税服务系统的技术方案必须以提供高标准的呼叫服务为目标，必须采用高质量的、稳定、可靠的产品和技术，要充分考虑系统的安全性，要适应发展变化的信息技术和不断变化的服务业务，要本着超前、安全、稳定的原则实现天津地税信息化建设和纳税服务的全面提升。
由于12366纳税服务系统核心产品与软件开发和系统集成联系紧密，为满足天津地税12366系统的业务需求，减低系统建设的风险、便于系统集成和后期的维护工作，要求中标商统一负责核心设备的供货与软件开发、系统集成等工作，核心设备包括：
PBX、CTI、IVR、TTS、录音（含板卡、不含工控机）、传真（含板卡、不含工控机）、外呼管理、报表管理、座席电话。
投标商应在投标文件中提供包括系统架构、所有设备选型和配置、软件系统配置、项目实施规划、人员培训计划等内容在内的整体解决方案。
投标商须具备使用其所选产品的成功案例，且为便于项目实施工作，投标商需具备在副省级以上地税系统成功开发并应用推广的12366纳税服务系统案例。
4.项目建设时间安排
本期项目划分成两个阶段实施，2009年5月底前完成第一阶段功能的开发；2009年8月底前完成第二阶段功能的开发。
第一阶段主要内容为：
人工座席业务管理（含短信和传真管理）、自动语音管理、知识库管理等；第二阶段完成全部功能的开发。
（二）系统整体架构
1.天津市地方税局信息系统现状
我局目前在线运行的业务管理系统包括核心征管系统（内、外网）、税收管理员平台、个人所得税全员全额申报管理系统、稽查举报管理系统、外网门户网站等系统，行政管理系统主要包括公文处理等系统。
目前我局因特网邮件服务尚未建立。
我局现有覆盖全市地税系统各单位的内部城域网络，各区县局端主干网接入带宽为百兆，另有租用运营商的2兆带宽的备份网络。
目前，我局在因特网提供财税门户网站、网上申报纳税系统等业务应用系统，运行在独立的外部网络上，外部网络与内部网络之间按照国家税务总局的有关要求实行安全隔离。
目前应用系统和网络系统核心设备均部署在市局办公楼内。
天津市地方税务局12366纳税服务中心与市局办公楼核心机房相距约1.5公里，计划建有专业机房，通过内部城域网与市局连接，两点之间还有一条2兆带宽的备份线路。
2.12366系统整体架构
12366系统包括语音服务和网上12366服务两个主要部分。
语音服务包括电话语音、传真、知识库、座席管理等主要内容，是12366系统的核心系统；网上12366主要在因特网上为纳税人提供留言板、邮件等方式的纳税服务。
12366语音系统的建设以天津市财税城域网为依托，核心系统为语音服务，为社会公众提供政策咨询、信息查询、协助办税、投诉举报等纳税服务功能，需要与现有征管系统、管理员平台、稽查举报管理等业务系统进行信息交换、从信息安全和便于与业务管理系统交互的角度出发，语音系统部署在内部网络。
语音服务系统按照呼叫中心系统建设模式，提供人工语音、自动语音、传真服务、录音系统、座席管理、报表管理、知识库管理系统等功能。
语音服务系统设立50个语音座席，其中集中语音座席25个（普通座席20个、班长座席1个、督导座席4个），位于天津市地方税务局12366纳税服务中心办公楼内，从可靠性和语音质量方面考虑，要求集中座席使用2B+D数字电话。
远程二线支持座席25个，分别位于各区县地税局，有宽带城域网连接，可以采用IP电话，但由于备份线路只有2兆带宽，网络同时还承载其他业务，因此整体解决方案必须考虑语音数据压缩传输。
网上12366子系统作为纳税服务的一个重要渠道，在因特网上为社会公众提供留言板、在线交流、邮件等方式的咨询服务。
天津地税将安排5名座席人员为网上用户提供纳税咨询服务，知识库中的法规文件等部分数据需要实现内外网传递，内外网系统之间不再发生其他信息交互。
内外网系统之间必须按国家有关要求实现安全隔离，因此，网上12366系统需要具有独立的座席资源管理功能。
投标商提供的整体解决方案应详细描述网上12366系统的安全保障设计和在安全保障机制下的内外网数据传递方案。
知识库系统是支撑纳税服务中心工作的重要基础平台，提供知识采集、知识资源整合、知识管理、知识沉淀与利用、知识搜索、知识共享与交换等功能。
知识库系统与语音服务系统一同部署在内部业务网络，知识库系统采集的税收法规需要同步到外网网上12366系统，供外网座席人员使用。
集成商须在符合有关安全管理管理规定的前提下，提供内外网数据传递方案。
二、监理项目要求
（一）监理期包括项目招标、实施并验收合格全过程，监理阶段及监理对象如下：
1.项目招标阶段：
项目招标、合同准备、合同签订
2.项目设计阶段：
项目计划制定、系统需求分析、系统结构设计
3.项目实施阶段：
软件需求分析、软件结构设计、软件详细设计、软件编码和测试、软件集成、软件合格性测试、系统集成
4.项目验收阶段：
培训、系统初验、系统试运行、系统终验、工程移交
5.项目支持过程：
文档编制过程、配置管理过程、质量保证过程、变更控制过程
（二）监理项目具体内容
1.项目招标阶段监理
1.1主要监理目标
1.1.1监理方（下称乙方）需了解需方天津市地方税务局（下称甲方）业务目标和业务模式，认定甲方单位确定的系统需求。
1.1.2乙方需协助甲方单位进行项目的招标准备工作，编制适宜的招标文件。
1.1.3乙方需协助甲方单位做好项目的招标工作，选定合适的服务商。
1.1.4乙方需促使甲方单位与服务商执行有序和稳妥的合同签订过程，促使项目服务合同的合理性和有效性。
1.2招标过程的监理
1.2.1乙方需协助甲方单位建立选择服务商的规程，包括标书的评价准则和符合需求的程度。
1.2.2乙方需协助甲方单位对投标单位资质进行审查，审查应包含如下内容：
a）资质文件应该真实、齐全；
b）投标单位的技术资质及等级应与本项目需要的工程技术相符合，并符合相关特殊要求；
c）参与项目的人员资格应与本项目的需要相符合。
1.2.3如果项目涉及分包，乙方需协助甲方单位对服务商选择的分包单位进行审查。
1.2.4乙方需协助评标，协助甲方单位根据投标单位的标书、能力评价和其他需要考虑的因素选择合格的服务商。
1.3合同准备、签订阶段的监理
1.3.1乙方需要求在服务合同中明确服务商应接受乙方的监理。
1.3.2如果项目涉及分包，乙方需要求服务商对分包单位进行管理，并承担责任。
1.3.3乙方需参与甲方单位与服务商的合同签订过程，合同应包含如下内容：
a）功能要求；
b）技术要求；
c）测试标准和验收要求；
d）质量责任；
e）项目阶段划分；
f）质量和进度要求。
1.3.4乙方需协助甲方单位对准备签订的合同进行验证。
验证时需考虑如下准则，形成监理意见，并协调项目各方对合同予以修订，监理意见需提交甲方。
a）合同中的系统需求覆盖甲方的系统建设目标；
b）合同中的系统需求描述的一致性；
c）为处理变更问题规定适当的处理方法；
d）对于其他相关系统的接口关系与合作，规定了规程及其范围，包括所有权、批准权、版权和机密；
e）按照系统需求规定验收准则和规程；
f）明确乙方在项目付款中的权利；
g）项目的里程碑进行了划分和界定，并作为工程阶段性付款依据。
1.3.5乙方需协助甲方单位组织与合同执行、管理相关的部门（信息化处、行政处、需求部门、信息中心）参与合同见证工作。
1.3.6乙方需要求项目各方启动合同管理机制及其配套的文档管理和配置管理措施。
2.项目设计阶段监理
2.1主要监理目标
2.1.1乙方需协助甲方审查服务商的项目计划，确保项目计划的合理性、可行性，并满足服务合同要求。
2.1.2乙方需监督服务商系统需求分析过程,督促服务商和甲方共同合作建立系统需求，并纳入配置管理，促使系统需求的正确性、完备性、准确性、可测试性和一致性。
2.1.3乙方需协助甲方评审服务商的项目的总体设计方案，促使总体设计方案满足项目的系统需求和有关的法规、标准，并符合服务合同要求。
2.2项目计划制订的监理
2.2.1乙方需要求服务商制定项目计划并形成文档、提交甲方，计划中应包含的项目主要包括下列：
a）项目的组织结构（包括外部组织）、人员职责及其能力要求；
b）项目环境，包括测试环境、程序库、设备、设施、标准、规程和工具；
c）任务分解安排，连同预算、人员、物理资源、软件规模和相关的任务进度安排；
d）进度安排、跟踪和报告方法；
e）软件产品或服务的质量特性的管理，可以制订独立的质量保证计划；
f）软件产品或服务的安全、保密安全和其他关键需求的管理，可以制订独立的安全、保密安全计划；
g）如分包，分包单位的管理；
h）如分包，验证和确认方式和条件；
i）风险管理；
j）用户培训计划。
2.2.2乙方需评价工程计划，评价时要考虑如下准则，并形成监理意见、提交甲方。
a）与服务合同的可追溯性；
b）系统范围及工作任务分解的完整性；
c）项目生存周期过程及重要里程碑划分的合理性，包括适宜的软件生存周期模型；
d）项目估计方法的正确性，对项目任务和工作产品规模、时间安排、资源的估计；
e）项目进度计划的合理性，包括项目质量保证计划、配置管理计划等；
f）项目计划中硬件部分的协调和实施的可行性；
g）对项目风险进行了必要的识别、分析、处理和跟踪。
2.2.3乙方需督促甲方和服务商适时对项目计划及有关附属计划进行评审，并及时取得各方对项目划的书面批准和承诺。
2.2.4乙方需在了解系统内容和项目计划的基础上，根据如下准则制定监理实施细则，并提交甲方。
a）与监理规划的可追溯性、一致性；
b）与业务目标的符合性；
c）与专业工程的符合性；
d）监理工作流程、控制要点、监理方法的可行性。
2.3系统需求分析阶段的监理
2.3.1乙方需要求甲方实施部门及服务商（下称承建单位）为系统需求分析过程的实施制定详细的计划并提交甲方。
2.3.2乙方需监督承建单位按照计划的要求开展系统需求分析活动。
2.3.3乙方需要求甲方单位及承建单位定义并分析系统建设目标。
乙方需要求甲方和承建单位定义并分析业务流程再造、业务持续改进、信息资源规划及业务指标评价体系。
2.3.4乙方需要求承建单位分析系统需求，并形成系统需求文档。
对系统需求规格说明书编制及其变更的监理参照文档管理监理和配置管理监理过程。
系统需求文档应包含以下内容，乙方应形成对系统需求和对甲方组织评价系统需求的监理意见，并提交甲方。
a）系统的功能和性能；
b）业务、组织和用户的需求及相关方的需要；
c）人机工程学要求及其他接口要求；
d）运行和维护的需求；
e）系统设计限制因素；
f）系统评审和验收测试方面的需求；
g）如适用，安全和保密的需求；
h）法律法规要求、合同要求、以及有关技术标准要求。
2.3.5乙方需协助甲方单位组织通过评审、确认、联合评审等方式评价系统需求。
评价时要考虑下列准则：
a）与合同的可追溯性、一致性；
b）业务目标及系统建设目标的可追溯性、一致性；
c）基于信息资源规划和业务指标评价体系的可测试性；
d）业务流程再造、业务持续改进、信息资源利用的可行性；
e）系统结构设计的可行性；
f）运作和维护的可行性。
2.3.6乙方需要求承建单位编制系统验收初步方案，并提交甲方。
2.3.7乙方需监督承建单位解决系统需求分析中发现的问题和不合格项，并形成监理意见、提交甲方。
2.4系统结构设计阶段的监理
2.4.1乙方需要求承建单位为系统结构设计过程的实施制定详细的计划，并提交甲方。
2.4.2乙方需监督承建单位按照计划的要求开展系统结构设计活动。
2.4.3乙方需协助甲方制定相应业务指标评价体系，监督服务商对系统结构开展合理的方案设计。
乙方需协助甲方制定计划并按照计划的要求开展业务流程再造、业务持续改进、信息资源利用的设计活动。
2.4.4乙方需要求承建单位依据计划进行系统结构设计，并形成系统结构设计文挡。
对系统结构设计书编制及其变更的监理参照文档管理监理和配置管理监理过程。
乙方需检查系统结构设计书包含如下内容，并形成监理意见、提交甲方：
a）应建立系统的顶层结构；
b）系统结构应标出硬件、软件和人工操作项；
c）应保证所有系统需求分配到各项中；
d）应顺序标出硬件配置项、软件配置项和手工操作项；
e）分配到各项中的系统结构和系统需求应形成文档。
2.4.5乙方需协助甲方单位组织通过审核、确认、联合评审等方式评价系统结构设计。
评价时要考虑下列准则。
a）与合同的可追溯性、一致性；
b）与业务目标的符合性；
c）系统需求的可追溯性、一致性；
d）所使用的设计标准和方法的适宜性；
e）软件项满足指定需求的可行性；
f）基于信息资源规划和业务指标评价体系的可测试性；
g）业务流程再造、业务持续改进、信息资源开发的可行性；
h）运作与维护的可行性。
2.4.6乙方需监督承建单位解决系统结构设计中发现的问题和不合格项，并形成监理意见、提交甲方。
3软件工程实施阶段监理
3.1主要监理目标
3.1.1乙方需协助甲方评审承建单位的软件需求分析文档，确保软件需求分析文档满足系统需求和系统设计方案的要求；
3.1.2乙方需检查、评审、督促承建单位的软件结构设计活动和文档满足软件需求分析文档的要求；
3.1.3乙方需督促承建单位的软件详细设计活动和文档满足软件需求分析文档的要求；
3.1.4乙方需检查、评审、督促承建单位的软件编码活动和结果满足软件设计文档的要求；
3.1.5乙方需监督承建单位的软件集成活动，验证软件集成符合软件设计的要求；
3.1.6乙方需协助软件合格性测试的活动，验证软件符合软件需求的要求；
3.1.7乙方需监督承建单位的系统集成活动，验证系统集成符合系统设计的要求。
3.2软件需求分析阶段的监理
3.2.1乙方需要求承建单位为软件需求分析过程的实施制定详细的计划。
3.2.2乙方需监督承建单位按照计划的要求开展软件需求分析活动。
3.2.3乙方需要求承建单位分析软件需求并形成文档，对软件需求说明书编制及其变更的监理参照文档管理监理和配置管理监理过程。
系统需求文档应包含以下内容，乙方需形成对软件需求和对甲方组织评价软件需求的监理意见并提交甲方。
a）功能与能力规格说明，包括性能、物理特性和软件项执行的环境条件；
b）如适用，软件项的外部接口；
c）鉴定需求；
d）安全规格说明，包括那些与运作、维护相关的方法、环境影响和人为损坏；
e）保密安全规定，包括那些与敏感信息相关的泄露；
f）人机工程学规格需求；
g）数据定义和数据库需求；
h）在运作和维护场所，对已交付的软件产品的安装与验收需求；
i）用户文档；
j）用户操作与执行需求；
k）用户维护需求。
3.2.4乙方需协助甲方通过审核、联合评审、确认等方式评价软件需求，评价时宜考虑下列准则：
a）与合同的可追溯性和一致性；
b）与业务目标和系统建设目标的一致性；
c）系统需求和系统设计的可追溯性、一致性；
d）内部一致性；
e）基于信息资源规划和业务指标评价体系的可测试性；
f）业务流程再造、业务持续改进、信息资源开发的可行性；
g）软件设计的可行性；
h）运作和维护的可行性。
3.2.5乙方需监督承建单位解决软件需求分析中发现的问题和不合格项，并形成监理意见、提交甲方。
3.3软件结构设计阶段的监理
3.3.1乙方需要求承建单位为软件结构设计过程的实施制定详细的计划。
3.3.2乙方需监督承建单位按照计划的要求开展软件结构设计活动。
3.3.3乙方需要求承建单位把软件项的需求转变为一种描述其顶层结构的结构图，并且标识出软件的各个部件，并形成文档、提交甲方。
对此文档编制及其变更的监理参照文档管理监理和配置管理监理过程。
3.3.4乙方需检查承建单位编制的接口的顶层设计和数据库的顶层设计。
3.3.5乙方需检查承建单位编制用户文档的最初版本。
3.3.6乙方需检查承建单位规定软件集成的初步测试需求和进度安排。
3.3.7乙方需评价软件项接口和数据库设计结构，评价时宜考虑下列准则，评价结果应形成监理意见，并提交甲方。
a）软件项需求的可追溯性；
b）与软件项需求的外部一致性；
c）软件部件之间的内部一致性；
d）所采用的设计方法和标准的适宜性；
e）详细设计的可行性；
f）运作与维护的可行性。
3.3.8乙方需监督承建单位解决软件结构设计中发现的问题和不合格项，并形成监理意见、提交甲方。
3.4软件详细设计阶段的监理
3.4.1乙方需要求承建单位为软件详细设计过程的实施制定详细的计划。
3.4.2乙方需监督承建单位按照计划的要求开展软件详细设计活动。
3.4.3乙方需要求承建单位编制软件项的每一软件部件的详细设计，并形成文档、提交甲方。
对详细设计编制及其变更的监理参照文档管理监理和配置管理监理过程。
3.4.4乙方需检查承建单位编制的接口的详细设计和数据库的详细设计。
3.4.5乙方需检查承建单位及时更新的用户文档、测试需求和软件集成进度安排。
3.4.6乙方需要求承建单位规定要测试的软件单元的测试需求和进度安排。
测试需求宜包括对软件单元在需求边界的强化要求。
3.4.7乙方需评价软件详细设计和测试需求，评价时宜考虑下列准则，评价结果应形成监理意见，并提交甲方。
a）软件项需求的可追溯性；
b）与结构设计的外部一致性；
c）所采用的设计方法和标准的适宜性；
d）测试的可行性；
e）运作与维护的可行性。
3.4.8乙方需监督承建单位解决软件详细设计中发现的问题和不合格项，并形成监理意见，提交甲方。
3.5软件编码和测试阶段的监理
3.5.1乙方需要求承建单位为软件编码过程的实施制定详细的计划。
3.5.2乙方需监督承建单位按照计划的要求开展软件编码活动。
3.5.3乙方需监督承建单位按照测试需求和进度安排进行单元测试。
3.5.4乙方需检查承建单位单元测试过程中的错误的记录及其改正。
3.5.5必要时，乙方需检查承建单位及时更新的用户文档。
3.5.6必要时，乙方需检查承建单位及时更新的测试需求和软件集成进度安排。
3.5.7必要时，乙方需评价软件编码和测试结果，评价时宜考虑下列准则，评价结果应形成监理意见，提交甲方。
a）软件项需求和设计的可追溯性；
b）与软件项的需求及设计的外部一致性；
c）所采用的编码方法和标准的适宜性；
d）软件集成与测试的可行性；
e）运作与维护的可行性。
3.6软件集成阶段的监理
3.6.1乙方需要求承建单位制订集成计划。
计划宜包括测试需求规程、数据、职责和进度安排。
3.6.2乙方需监督承建单位按照计划的要求开展软件集成活动。
3.6.3乙方需要求承建单位按照集成计划将软件单元和软件部件作为集合体进行集成，并测试，并形成文档、提交甲方。
对集成和测试结果的编制及其变更的监理参照文档管理监理和配置管理监理过程。
3.6.4乙方需检查承建单位及时更新的用户文档。
3.6.5乙方需评价集成和测试结果，评价时宜考虑下列准则。
评价结果应形成监理意见，并提交甲方。
a）系统需求的可追溯性；
b）与系统需求的外部一致性；
c）内部一致性；
d）软件项需求的测试范围；
e）所采用的测试标准和方法的适宜性；
f）与预期结果的符合程度；
g）软件合格性测试的可行性；
h）运作与维护的可行性。
3.6.6乙方需监督承建单位解决软件集成中发现的问题和不合格项，并形成监理意见、提交甲方。
3.7软件合格性测试阶段的监理
3.7.1乙方需要求承建单位为实施软件合格性测试而对软件项的每一鉴定需求，开发确定的测试集、测试用例（输入、输出、测试准则）以及测试规程。
3.7.2乙方需监督承建单位按照计划的要求开展软件合格性测试活动。
3.7.3乙方需要求承建单位按照软件项鉴定需求实施合格性测试，并形成文档、提交甲方。
对此测试文档编制及其变更的监理参照文档管理监理和配置管理监理过程。
3.7.4乙方需检查承建单位及时更新的用户文档。
3.7.5乙方需评价设计、编码、测试、测试结果和用户文档，评价时宜考虑下列准则。
评价结果应形成监理意见，并提交甲方。
a）与合同的一致性；
b）软件项需求的测试范围；
c）与预期结果的符合程度；
d）如果实施时系统集成和测试的可行性；
e）运作与维护的可行性。
3.7.6当要获取现货软件产品时，乙方需验收现货软件产品是否满足下述条件，结果形成监理意见，并提交甲方：
a）满足合同的要求；
b）满足系统建设目标和系统需求；
c）具有有效的文档；
d）满足知识产权的要求；
e）有此软件产品的未来支持计划。
3.7.7乙方需监督承建单位解决软件合格性测试中发现的问题和不合格项，并形成监理意见，并提交甲方。
3.8系统集成阶段的监理
3.8.1乙方需要求
升级会员 