北方电信业务支撑系统二期工程技术规范书模板.doc

北方电信业务支撑系统二期
工程技术规范书
（综合客服、生产调度应用软件部分）

中国电信集团企业北方电信事业部

目 录
第一章 总则 1
1.1 概述 1
1.1.1 规范定义 1
1.1.2 规范内容 1
1.1.3 规范依据 1
1.1.4 规范要求 1
1.1.5 规范书相关内容澄清 2
1.2 对卖方提议书要求 2
1.2.1 技术规范书点对点应答书要求 2
1.2.2 提议书内容格式要求 3
1.2.3 其它部分要求 3
1.3 报价体系要求 4
1.3.1 总体要求 4
1.3.2 报价体系要求 4
1.3.3 服务报价要求 5
1.3.4 培训报价要求 5
1.4 系统文档要求 5
1.5 保密要求 6
第二章 工程说明 6
2.1 工程概况 6
2.2 北方电信网络现实状况 7
2.2.1 交换网 7
2.2.2 智能网 7
2.2.3 数据网 7
2.2.4 业务支撑网现实状况 8
2.3 工程建设方案 8
2.3.1 总体框架 8
2.3.2 系统建设实施 9
2.4 工程建设规模 9
2.5 本期工程所需软件说明 10
第三章 业务支撑系统技术要求 11
3.1 总体要求 11
3.1.1 质量性能要求 11
3.1.2 技术性能要求 12
3.1.3应用指导标准 12
3.1.4数据指导标准 13
3.1.5技术指导标准 13
3.2 安全性要求 14
3.2.1 系统级安全 14
3.2.2 应用级安全 14
3.3 系统技术路线要求 15
3.4 和相关系统接口技术要求 18
3.4.1 北方电信事业部和相关系统接口技术要求 19
3.4.2 北方9省（区、市）和相关系统接口技术要求 20
3.5 软件开发要求 22
3.6 网络带宽需求 22
第四章 业务功效需求 22
4.1 业务支撑系统软件体系结构 22
4.2 综合客服功效需求 24
4.2.1 销售管理过程 25
4.2.2 用户管理 26
4.2.3 用户经理管理 29
4.2.4 业务受理 30
4.2.5 收费管理 32
4.2.6 故障受理 34
4.2.7回复 34
4.2.8 业务咨询 35
4.2.9 投诉提议 35
4.2.10 业务查询 36
4.2.11 主动服务 36
4.2.12 销帐管理 38
4.2.13 系统管理 39
4.2.14 统计分析 40
4.3 生产调度管理功效需求 42
4.3.1 用户界面 42
4.3.2 系统要求 42
4.3.3 功效需求 44
4.4网络资源配置管理 49
4.4.1网络资源数据管理 49
4.4.2网络资源配置 49
4.4.3和其它系统关系 50
第五章 售后服务要求 50
5.1 系统服务要求 50
5.2 售后服务要求 51
第六章 软件开发、项目组织、技术培训要求 51
6.1 工程计划及进度 51
6.2 项目组织要求 52
6.3 技术培训要求 52
第七章 其它要求 52

第一章 总则
1.1 概述
1.1.1 规范定义
本文件为北方电信业务支撑系统二期工程（综合客服、生产调度和网络资源配置管理功效应用软件部分）技术规范书。提供本期工程相关应用软件企业（以下称卖方）应向中国电信集团企业北方电信事业部（以下称买方）就系统所需应用软件作出具体回复。
回复：满足。

1.1.2 规范内容
本规范书针对此次项目所需要综合客服、生产调度和网络资源配置管理功效应用软件部分提出对应技术规范要求。本规范给出了买方中国电信集团企业北方电信事业部对北方电信业务支撑系统二期工程在应用软件技术、性能、服务等方面应满足各项要求，这些要求将在以后各章节中列出，以供卖方编写方案提议书、软件配置、供货及报价书之用。请卖方依据自己所能提供软件，给出具体方案提议书和商务报价书。
回复：满足。

1.1.3 规范依据
（1）ISO、ITU-T、ETSI、IMTC、IETF等软硬件技术标准；
（2）信息产业部、原邮电部、中国电信集团相关业务支撑系统相关技术体制和技术规范；
（3）中国电信集团企业北方电信业务支撑系统技术规范V1.0；
（4）中国电信集团企业北方电信业务支撑系统业务规范V1.0；
（5）中国电信集团北方电信事业部交换网、传输网、数据网建设方案及相关业务量分析和估计结果；
回复：满足。

1.1.4 规范要求
（1）卖方应承诺所提供软件在产品性能、技术指标、服务内容等方面满足本规范要求；
回复：满足。
（2）当买方有新提议，而本规范又还未包含或和本规范不符时，则应符合买方新提议要求；对于买方还未有标准，而本规范又未提及部分，卖方提出其标准，留待双方认可后实施；
回复：满足。
（3）当卖方设备中包含自己专用标准，应在提议书中具体说明，并附上对应具体资料。
回复：满足。
（4） 卖方应列出其提议书中所提供设备和系统在世界范围内和中国应用情况，诸如最大规模、业务类型及开展方法、用户数量等。
回复：满足。

1.1.5 规范书相关内容澄清
（1）卖方对于规范书疑问能够经过书面材料和买方联络。在要求提议书提交最终期限以前，买方将以书面材料给回复，相关买方回复材料复印件也将递交全部得到技术规范书卖方。
回复：满足。
（2）在技术谈判各个阶段，买方将以书面形式要求卖方对相关问题进行深入技术澄清，卖方应以书面资料给正式应答；全部各阶段技术澄清文件全部将作为协议附件。
回复：满足。
（3）未经买方许可，卖方不得以任何形式向第三方提供本文件全部或部分内容。
回复：满足。
（4）买方在任何时候保留和拥有对本文件解释权和修改权。买方有权在签定协议前，依据需要修改和补充本技术规范书，修改补充后最终技术规范书将作为协议附件。
回复：满足。
（5）本工程技术规范书要求针对本规范书描写综合客服、生产调度和网络资源配置管理功效应用软件部分进行具体应标，并要求符合业务支撑系统总体软件体系结构。
回复：满足。

1.2 对卖方提议书要求
卖方在收到本文件后，应提供资料包含以下几部分：
（1）对本文件点对点应答书
（2）技术提议书
（3）报价书
回复：满足。

1.2.1 技术规范书点对点应答书要求
卖方应答书中，要求对本文件技术规范部分和商务协议部分所提出各项条款进行逐项回复、说明和解释，首先对实现或满足程度明确作出“满足”、“部分满足”、“不满足”等应答。在回复中，凡采取“详见”、“参见”方法说明，应指明参见文档具体章节或页码。请卖方尤其注意：凡采取“详见”、“参见”方法说明条款，必需在点对点应答书中注有合适总结性文字，简练、明了地回复对应条款。对于规范书中要求列举条款，必需在点对点应答书中进行列举，不得简单回复“满足”等，不然视该条款应答为“不满足”。假如回复“部分满足”，需要具体说明哪些部分满足，哪些部分不满足，而且具体说明原因。
回复：满足。

1.2.2 提议书内容格式要求
卖方所提供提议书应根据以下内容格式进行编制：
（一）综述；
（二）工程技术规范书；
（三）技术规范书点对点应答；
（四）总体方案及综合客服、生产调度和网络资源配置管理功效部分方案提议；
（五）应用软件具体配置清单；
软件具体配置标准或配置说明、相关计算方法和依据，包含必需公式、表格或图表。
（六）应用软件功效具体说明；
（七）硬件配置要求说明；
即软件运行环境说明，卖方所提供给用软件对硬件具体要求，包含所需要硬件组织结构图、硬件处理能力估算、硬件配置要求说明及推荐硬件配置。需要说明是，此次工程硬件将由买方依据卖方所提供给用软件需要进行自主采购，但卖方必需提出对硬件处理能力、配置要求等各方面需求，并对最终止果进行确定。
（八）系统软件具体配置清单及功效具体说明；
即软件运行环境说明，卖方所提供给用软件对系统软件具体要求，包含所需要数据库、中间件具体配置要求说明，和卖方所提供给用软件运行所必需要其它系统软件、测试软件、开发软件等需要向第三方采购通用性系统软件。并具体列出所需要这些系统软件种类、推荐使用具体产品（假如必需采取某种产品需要尤其说明）、License数量等，和这些软件报价并对最终止果进行确定。。需要说明是，这些软件报价将作为可选项单独报价，不计入总价。
（九）供货计划及工程进度安排具体说明；
（十）分工界面，要求图示并加以说明；
（十一）测试及验收；
（十二）培训计划；
（十三）技术服务、支持；
（十四）所提供软件技术文档；
（十五）相关资质或许可证。
回复：部分满足。因为本款中对提议书格式和投标要求中对格式要求不一致，根据本规范和投标要求不一致地方以投标要求为准标准，我方将根据投标要求进行格式编排，但内容会覆盖以上条款所含内容。

1.2.3 其它部分要求
北方电信业务支撑系统二期工程需求由买方提出，软、硬件配置由买方帮助卖方进行。卖方在进行业务支撑系统设置和设备配置时应遵照以下标准：
（1） 卖方应以技术优异、经济合理，有利于以后发展标准进行业务支撑系统二期工程设计和软、硬件设备配置。
（2）依据买方提议和要求，卖方应向买方提供优化设计方案。
（3） 卖方在给出业务支撑系统二期工程优化方案时，应以书面材料解释其业务支撑系统优化设计思想、标准、步骤及利弊。
（4） 对于由卖方提供硬件设备，该设备应是以最少十年使用期设计，卖方要确保不管提供设备是否还生产，在使用期内买方可得到备件。
（5）卖方应依据本规范书要求在要求时间2月10日下午4:00之前提供技术提议书（汉字）和报价书（汉字），其中提议书要求提供8套，报价书3套（单独密封包装），并同时提供提议书和商务报价书电子文档（MS OFFICE文档形式光盘）。
回复：部分满足，因为在投标要求中提供提议书为８套，而在投标要求中要求是３套，依据买方提供《投标人问题回复（综适用户部分）》回复“以投标要求为准”，所以将提供３套提议书。

1.3 报价体系要求
1.3.1 总体要求
（1）报价应包含依据系统要求全部必需软件、安装材料、技术文件及安装调测、培训、技术支持等；
（2）报价应包含软件名称、版本号、配置模块、数量等具体内容；
（3）报价应分别以美元或人民币为单位；
（4）报价应按目录价、折扣价和折扣率分项列清；
（5）假如卖方提供设备有多个可选配套软件，卖方能够提议买方采取一些业务或功效，同时应具体描述和说明这些业务或功效并作为可选项提出报价，可供买方选择设备和功效报价单列，但不计入总价；
（6）卖方在报价中应明确标注采取第三方硬件、软件产品，凡第三方软件产品不由卖方直接供给，应注明其供给商。
回复：满足。

1.3.2 报价体系要求
请卖方根据以下各项要求分别报价：
（1）此次配置全部软件总价；
（2）全部软件配置清单及报价；
（3）以省（区、市）为单位，此次配置各省（区、市）全部软件清单及报价，和北方电信9省（区、市）汇总价；
（4）系统全部必需配置软件清单、功效说明；
（5）系统全部可选配置软件清单、功效说明及对应各项报价，此部分报价不计入总价；
（6）依据本规范书要求其它不计入总价相关配置清单及报价（如硬件配置清单、系统软件配置清单等，具体内容参见后续章节）。
回复：满足。

1.3.3 服务报价要求
卖方应对下述服务项目进行报价：
（1）安装
卖方负责所提供硬件、软件安装。
（2）二次开发和用户化
卖方负责依据北方电信需求对所提供软件进行对应剪裁、用户化和二次开发工作。
（3）系统调测
卖方应负责所提供硬件、软件调测，并负责配合系统内相关设备调测。
（4）技术服务
技术服务分为基础技术服务和可选技术服务，基础技术服务应列出单价和合价，并列入必选报价及总价中；可选技术服务列入选项报价中，只列单价，而且不记入总价。基础技术服务包含技术支持，时限为系统终验完成后两年，卖方应提供技术支持时限内7*二十四小时技术支持。
回复：满足。我方已对上述服务内容进行报价，详见技术服务附件和报价清单。

1.3.4 培训报价要求
请卖方依据本规范书对于技术培训要求内容，列出培训人员费用单价及具体培训计划（包含时间、地点、课程等），并作为可选项单独报价，不计入总价。
回复：满足。

1.4 系统文档要求
要求卖方提供具体文档资料，对所提供系统文档资料要求以下：
（1）提供技术文件应和提供软件相一致，技术文件应该全方面、完整、具体；
（2）提供技术文件应能够满足软件安装、使用、维护、应用开发需要；
（3）应用软件文档应该包含：
Ø 软件需求说明书
Ø 系统总体设计说明书
Ø 系统概要设计说明书
Ø 数据库设计说明书
Ø 具体设计文档
Ø 应用软件清单
Ø 测试计划、测试方案
Ø 测试汇报
Ø 试运行汇报
Ø 维护手册
Ø 操作手册
Ø 版本说明
Ø API说明
（4）应提供完整、正确源代码，源代码文档要求有详尽说明和注释；
（5）文档和资料应提供电子文档和纸面文档，电子文档格式为MS Word文档。
回复：满足。依据《商务规范书》协定，我方将开放应用软件全部源代码（应用软件中乙方自有软件模块除外）。

1.5 保密要求
卖方除以下情况外，非经北方电信事业部书面许可，不得将本文件任何内容透露给除北方电信事业部以外第三方。
经北方电信事业部书面许可，应标商才许可将本文（限于必需部分）透露给其合作伙伴，并确保其合作伙伴不将本文透露给其它人。
未经书面许可将本文件透露给第三方应标商，将被剥夺中标资格。
回复：满足。

第二章 工程说明
2.1 工程概况
在本期工程建设前期，北方电信事业部已经组织建设北方电信事业部业务支撑系统一期工程建设。一期工程建设了北方电信事业部（地点设置在天津）业务支撑中心。北方9省（区、市）未建设应用平台。一期建设了一套统一集中结算系统，完成了北方9省（区、市）南方21省长途来话收敛、北方去话等业务包含到和其它运行商之间结算，和中国电信省间网内摊分；一期工程还建设了一套网上营业厅系统，为北方电信事业部及北方9省（区、市）电信企业完成企业宣传、业务开展宣传、用户查询、咨询、投诉等相关用户服务Web接入工作。对于前期交换、数据专业业务开展，则经过对应专业网后台系统实现，在业务支撑系统一期工程中未考虑。
本期工程需要在一期工程基础上，愈加完善北方电信业务支撑系统，关键建设北方9省（区、市）业务支撑系统，包含业务支撑系统综合客服、号线资源管理、综累计费、综合帐务、生产调度和网络资源配置管理管理等功效模块。本期工程建设容量满足年底业务量需求。
在此次招标之前，北方电信组织各省开始了各省呼叫中心平台建设，计划于3月完成北方9省（区、市）呼叫中心平台建设。各省呼叫中心平台建设将作为各省业务支撑系统接入层，完成各省话音接入服务，而呼叫中心所需要全部后台数据和业务步骤，包含全部用户数据、全部业务步骤全部需要在此次应用软件中统一建设、统一管理、统一实现，而呼叫中心仅仅需要调用此次应用软件多种数据和业务步骤。
本期工程北方电信事业部将在北方电信范围内定义统一共享关键数据模型。同时将定义步骤模型，和业务结合转化成具体业务步骤。共享关键数据模型和业务步骤将被布署到各省应用承载平台上，各省应用承载平台负责实施数据模型和业务步骤，建立当地化服务和具体工作步骤和和应用系统适配器。
回复：满足。我方已了解上述内容。

2.2 北方电信网络现实状况
2.2.1 交换网
从年底交换网络一期工程建设完成后，交换网络将关键负担南方21省来话收敛业务。即在交换网络一期工程建设完成后，在北方9省（区、市）省会城市分别建TS和LS/GW，在发达城市建立TLS/GW，其它当地网不设交换机，采取省会LS/GW软覆盖方法。其中省会LS/GW负责和省会城市所在当地网相关互联互通业务量。已建交换机当地网由该交换机负责和该当地网相关互联互通业务量。
一期建设交换网络建设北方20个当地网，共建设22套当地网交换机。
在本期工程建设期间，交换网络二期工程也将同时展开，将缩小省会LS/GW软覆盖覆盖范围，在部分中等发达城市建立TLS/GW。
回复：满足。我方已了解上述内容。

2.2.2 智能网
从年底智能网一期工程建设完成后，智能网将关键负担北方9省（区、市）新业务开展。依据北方电信事业部智能网建设情况，北方电信事业部智能网业务关键为卡类业务、智能公话等业务。依据智能网建设思绪及业务开展思绪和北方电信事业部相关智能网建设，在各当地网新建LS/GW交换机同时含有区域智能网业务交换点SSP功效，负责所辖区域智能网业务触发，其中已设置交换机各个当地网，由该交换机兼作SSP负责当地网内区域智能网业务（不含国家骨干智能业务），未设置交换机其它当地网，其区域智能业务由各省省会LS/GW交换机兼作SSP负责。同时北方9省（区、市）统一在郑州设置一套SCP，负责北方9省（区、市）全部智能网业务控制和管理。
回复：满足。我方已了解上述内容。

2.2.3 数据网
北方电信事业部IP网一期工程共设20个省域节点，地点设置和交换网相同，在这20个省域节点，每个节点新增2台路由器和1台局域网交换机。
在本期工程建设期间，数据网二期工程也将同时展开，将在部分中等发达城市建立省域节点，地点设置和交换网相同，每个节点新增1台路由器和1台局域网交换机。
回复：满足。我方已了解上述内容。

2.2.4 业务支撑网现实状况
在本期工程建设前期，北方电信事业部已经组织建设北方电信业务支撑系统一期工程建设。一期工程建设完成了以下关键硬件平台：
（1）完成了交换网络一期建设20个当地网全部交换机采集部分硬件平台建设；
（2）完成了北方电信事业部结算系统及网上营业厅功效建设，而各省没有业务支撑系统硬件平台，仅经过远程操作终端完成对应结算功效。
回复：满足。我方已了解上述内容。

2.3 工程建设方案
2.3.1 总体框架
北方9省（区、市）业务支撑系统总体结构采取北方电信事业部中心和9省（区、市）企业两级结构。即所谓“1＋9”模式，在北方电信事业部和北方9省（区、市）分别建立业务支撑系统平台，在应用层面实现省级集中，在关键数据层面实现9省（区、市）大集中。北方电信事业部业务支撑中心关键完成综合营销管理、综合结算、生产调度管理、资源管理、统计分析和系统管理等6个功效模块；而省级业务支撑系统关键完成综合客服、综合营销管理、综累计费、综合帐务、SLA管理、生产调度管理、资源管理等8个功效模块。

图2.3-1 北方电信业务支撑系统网络框架图

在此总体框架下，由北方电信事业部统一定义北方9省（区、市）关键数据结构，包含用户数据、帐务数据、产品数据、资费结构和资源结构等。在北方电信事业部建立业务支撑系统关键数据数据库平台，并在其上建立负责北方9省（区、市）全局应用系统。而在北方9省（区、市）分别建立本省集中数据库平台和应用平台，省业务支撑系统数据结构必需和北方电信事业部定义保持一致，省企业在此基础上建立适应本省实际业务开展情况应用系统。
北方电信事业部和各省级业务支撑平台则经过企业内部通信网DCN网进行相关数据信息传输。
回复：满足。我方已了解上述内容。

2.3.2 系统建设实施
北方电信业务支撑系统二期工程建设实施要遵照“总体计划、滚动建设”标准。作为全新电信企业，北方电信9省（区、市）不仅含有中国电信南方21省建设业务支撑系统丰富经验，而且扔掉了历史包袱。所以，北方电信业务支撑系统更应该站在一个更高高度，充足吸收南方21省“九七”系统、计费帐务系统、1000号客服系统等系统建设丰富经验，对系统进行合理总体计划，尽可能避免“信息孤岛”，确保新建设电信业务支撑系统能够融合以前各系统多种优点，同时避免以前各系统因为当初技术局限而带来不足，真正建设一个高效、完善业务支撑系统。
同时，建设北方电信业务支撑系统二期工程也是一个很紧迫工程，要满足业务开展需要、市场开拓需要、建设周期短促，不许可有太多时间进行充足准备。所以，在总体计划前提下，进行滚动建设，确保在确保一个完整总体计划基础上，不停完善该系统。
回复：满足。我方自主研发EOS基础平台能够从应用软件架构上满足“总体计划、滚动建设”需要。

2.4 工程建设规模
北方电信业务支撑系统二期工程关键是为了处理北方电信9省（区、市）业务网络建设完成后，愈加好地为电信用户服务，愈加好地提供对开展业务支撑。而且本期工程关键满足到，对各个业务系统进行支撑，其建设规模为：
本期工程省级业务支撑系统平台包含综合客服、综累计费、综合账务、生产调度管理和网络资源配置管理等功效模块，采取全省集中模式将全部实现这些功效模块数据库服务器、应用服务器、存放设备、备份设备全部集中在一个省业务支撑中心，考虑到保护投资和以后系统扩容方便，很多功效模块需要合设同一套服务器。
本期工程事业部中心业务支撑系统，依据北方电信实际业务需求，对一期工程建设结算系统和网上营业厅功效，进行合适扩容或改造。
本技术规范书要求卖方在了解北方电信业务支撑系统二期工程建设规模和内容基础上，就二期工程综合客服、生产调度和网络资源配置管理功效部分作具体应答。
回复：满足。我方已了解上述内容。

2.5 本期工程所需软件说明
依据北方电信业务支撑系统二期工程建设要求，本工程技术规范书将对该工程整体情况进行简明描述，并对本工程应用软件进行整体描述，但请卖方注意，本工程应用软件共包含事业部业务支撑平台应用软件（共6大功效）和省级业务支撑平台应用软件（共8大功效），但本工程技术规范书只针对其中省级业务支撑平台应用软件8大功效中综合客服、生产调度和网络资源配置管理功效提出具体要求。请卖方在了解工程应用软件整体结构基础上，针对以下方面进行应答和报价：
（1）应答范围包含对应用软件整体结构了解，和综合客服、生产调度和网络资源配置管理功效在整体结构中作用及和其它模块之间关系；
回复：满足。我方在《技术提议书》中具体描述了对应用软件结构了解，和综合客服、生产调度和网络资源配置管理功效在整体结构中作用及和其它模块之间关系，详见《技术提议书》2.2.4.1
（2）报价范围包含实现综合客服、生产调度和网络资源配置管理功效所需要设计、开发、服务等方面费用，具体方法参见对报价体系要求；
回复：满足。我方对此作了具体列举，详见《商务报价》。
（3）为了确保完成综合客服、生产功效和网络资源配置管理功效，请卖方针对所需要主机存放、备份等硬件种类、配置、处理能力，各类系统软件种类、各项性能指标要求进行具体描述，确保买方能够提供足够应用软件运行环境，以满足卖方提供综合客服、生产调度和网络资源配置管理功效正常运行，和和其它部分功效共同组成一个有机应用系统。但此部分作为可选项报价，不计入总价；
回复：满足。我方不仅从主机性能、容量方面作了比较具体叙述，而且依据各省实际业务情况对硬件系统做了对应配置，确保系统建设即经济、实用并有很强扩展性，详见《技术提议书》6描述
（4）卖方开发软件假如是事业部业务支撑平台所需要功效，则只需要在事业部平台使用，假如是省级业务支撑平台所需要功效，则需要在北方9省（区、市）分企业9个业务支撑平台使用，所以卖方应用软件报价必需包含全部需要软件数量。
回复：满足。我方已依据这些要求对系统进行报价，详见《商务报价》。
（5）由卖方所开发软件，在系统验收之前，卖方须依据买方要求立即作出设计修改，以确保系统功效完整性和可靠性；并确保在服务期内无偿负责软件更新、维护和版本升级。
回复：满足。
（6）由卖方所开发软件，须提供数据和API接口，软件本身应含有灵活配置文件，以方便维护。
回复：满足。

综合客服、生产调度和网络资源配置管理应用软件功效需求将在本规范书后续章节将具体给出具体技术要求。
回复：满足。

第三章 业务支撑系统技术要求
3.1 总体要求
（1）应用软件设计应严格符合本规范三层体系结构要求，使系统含有良好灵活性、可操作性和可扩展性，并遵照中国电信集团企业、北方电信相关接口规范；
回复：满足。参见《技术提议书》。我方应用系统建立在J2EE标准基础之上，采取三层体系结构。假如原有业务步骤发生改变，直接经过修改步骤图即可完成；假如业务框架中一些业务属性发生改变，经过数据字典管理进行配置即可；假如需要开发新业务，则能够利用我方快速开发工具进行快速开发。我方系统完全采取面向对象技术，含有很强灵活性、可操作性和可扩展性。我方应用系统遵照中国电信集团企业、北方电信相关接口规范，详见《技术提议书》2.2.4.2描述。

（2）为了向用户提供灵活多样服务，快速适应新业务开展，应用软件设计应采取灵活结构，应采取面向对象、中间件等技术；
回复：满足。参见上点回复。
（3）整个应用软件系统应能够连续7×二十四小时不间断工作，应用软件中任一模块更新、加载时，在不更新和上下模块接口前提下，不影响业务运转和服务；
回复：满足。我方整个应用软件系统布署在两台支持负载均衡应用服务器上，加上数据库和网络设备冗余备份，能够支持7*二十四小时不间断运行，软件模块能够动态更新和加载。

（4）应用软件应含有较高自动化程度，如：自动任务调度、自动故障告警、自动任务恢复等；
回复：满足。我方应用软件构建在EOS平台基础上，EOS平台本身提供自动任务调度、故障告警、任务回复等机制，同时我方将提供给用网管代理对应用承载平台进行自动故障告警。详见《技术提议书》5.1.17.5描述。
（5）应含有完整操作权限管理功效和完善系统安全机制，能够对每个操作员每次操作有具体统计，对每次非法操作产生告警；
回复：满足。
（6）应能为系统管理员提供多个发觉系统故障和非法登录手段；
回复：满足。
（7）应采取简练、直观、友好图形化汉字界面，支持鼠标操作；
回复：满足。
（8）对于业务处理界面，应确保操作人员能够完全利用键盘操作；
回复：满足。
（9）对于常见步骤，系统应设置快捷键以方便功效间切换；操作及选择键（热键、菜单选择等）功效定义在全系统保持一致；
回复：部分满足。因为我方采取100％B/S结构，对快捷键支持会相对较弱。
（10）应含有对应容错手段，许可操作人员有限范围误操作；
回复：满足。
（11）应含有在线帮助功效，并能方便管理员修改帮助信息；
回复：满足。
（12）支持汉字字符集等相关国家标准要求汉字字符处理，可进行处理、显示和打印。
回复：满足。

3.1.1 质量性能要求
业务支撑系统建设必需符合以下质量要求：
（1）技术优异性：系统设计应采取目前优异而成熟技术，充足吸收国际厂商优异经验，并考虑到北方电信9省（区、市）特殊性，不仅能够满足本期工程需求，也应把握未来发展方向。
回复：满足。网上营业厅系统数据库采取Orcale 8i，中间件采取基于J2EE标准BEA Weblogic或 IBM Websphere，数据交换基于XML技术，应用软件采取基于B/S三层体系结构，关键编码语言采取Java，这些全部是在业界被广泛使用并经过验证优异而成熟技术，在应用软件上，我方基于J2EE平台开发含有完全独立自主版权技术支撑平台（包含组件组合技术，数据字典管理，基于XML数据总线技术，用于页面逻辑和业务逻辑开发可视化开发环境，多维数据仓库，OLAP分析工具和其它公共服务设施）和以用户为中心业务框架平台是充足吸收了国际厂商优异经验，其中技术支撑平台经过BEA、HP、Orcale和我方联合测试，性能指标超出同类产品主流国际厂商水平（关键是因为我方采取独特动态EJB组合技术），整个平台已经有在证券行业有多个大容量运行案例，属于成熟技术。在已经有原子服务上开发新业务逻辑无需编程，而且因为以下原因使得本系统不仅可满足本期工程要求，也能符合未来技术和业务发展：1、建立在EOS平台和用户细分基础上应用系统适应未来以用户为中心市场分析、营销和服务系统改变。2、基于J2EE、XML数据交换能够很好和其它系统进行集成。3、含有新业务快速开发能力。

（2）可扩充性：在系统设计时应充足考虑可扩充性，从而确保新功效、新业务增加应能够在不影响原系统运行情况下实现。
回复：满足。详见《技术提议书》2.2.7.4描述，系统在多个层次上全部含有良好扩展性。

（3）安全性：系统应确保数据不被非法入侵者破坏和盗用，并确保数据一致性，对欺诈行为应采取多个检验和处理手段。
回复：满足。详见《技术提议书》2.2.2.2描述，系统经过对各个层次安全策略保障数据一致性和完整性并采取多个检验和处理手段预防欺诈行为。
（4）可靠性及稳定性：应采取对应故障检验、告警和处理机制，确保数据不会因意外情况丢失或损坏；采取灵活任务调度机制实现负载均衡，预防“瓶颈”产生，在任何情况下，全部应该保持可预见
回复：满足。系统经过设备冗余、数据备份、负载均衡、容错、网络管理等多个手段确保系统可靠性和稳定性。
（5）正确性：应该能够提供多个稽核手段，确保系统数据正确性。
回复：满足。系统经过基于MAC、HASH、统计数等多个数据稽核手段确保系统数据正确性。
（6）成熟性：应尽可能选择经过大量利用、成熟可靠系统。
回复：满足。详见《技术提议书》2.2.7.3，系统软硬件全部选择现在业内主流厂家和型号。
（7）经济性：在满足上述前提下，选择经济、实用系统配置。
回复：满足。因为系统基于J2EE系统之上EOS平台我方含有完全自主知识产权，EOS关键特征是适应改变和业务组件重用性，长久来看能够极大地降低设计、开发、维护成本，所以在能够充足适应未来改变基础上，极大降低应用系统投资成本。

3.1.2 技术性能要求
（1）系统应含有较强安全性和保密性。
回复：满足，详见《技术提议书》2.2.2.2描述，系统经过多个手段从多个层次加以保障。
（2）系统不易瓦解或被破坏，含有良好恢复能力。
回复：满足，关键设备采取冗余配置，经过防火墙实现和公网隔离，数据存放采取RAID5技术，并定时进行磁带备份，应用软件系统含有流量控制、拥塞控制功效，通常不会瓦解或被破坏。
（3）系统应提供多级密码口令或使用硬件钥匙。
回复：满足，详见《技术提议书》2.2.2.2描述，系统能提供完善系统控制管理。如需要，系统能够提供使用硬件钥匙。
（4）系统有完善用户组管理，控制不一样用户权限。
回复：满足。系统有完善角色管理，每个角色能够定制权限，用户能够经过映射一个或多个角色控制不一样用户权限。
（5）网络及数据库系统可进行访问控制。
回复：满足，详见《技术提议书》6.2.5和7.2，系统采取多个层次访问控制。
（6）系统应提供具体统计日志。
回复：满足。系统不仅提供运行日志、操作日志、异常日志等多个方面日志统计，而且还提供用于跟踪故障日志跟踪手段。
（7）系统必需能够提供完善业务告警系统。
回复：满足，我方系统经过多种日志、声音提供告警，还提供基于SNMP应用层网管进行业务告警。

3.1.3应用指导标准
应用应遵照标准：
（1）全部应用需能够和EAI架构标准（XML, CORBA, Java/JSP/J2EE）接口。
回复：满足。
（2）应用应是支持消息 (message based)。
回复：满足。
（3）全部应用应是基于UNIX (Unix based)。
回复：满足。
（4）应用必需是支持SMP（SMP based）。
回复：满足。
（5）在应用软件管理和监控功效方面应提供SNMP MIB。
回复：满足。

以下标准作为中国电信IT战略组成部分，是全部应用全部必需遵守。卖方应依据本期工程建设要求，说明所提供给用将怎样去遵守这些标准。
（1）符合北方电信对关键应用标准化需求。
计费帐务系统，作为关键应用，许可依据北方电信特殊要求作有程度用户化定制。但全部更改必需确保和北方电信关键应用平台相关标准和技术规范（SDK/API）保持一致
回复：满足。我方应用经过EAI平台和计费帐务系统连接，我方开放应用软件体系结构能够快速适应北方电信对关键应用标准化需求。
（2）模块化应用架构。
应清楚定义每个模块/应用功效和业务覆盖范围，避免在一个模块中实现多个功效，保持单个模块/应用和具体业务应用系统相对独立性，确保系统统一性和一致性。
回复：满足。我方建立在EOS上应用架构，能够从应用构架上极大地确保模块之间地松散耦合；另外我们从应用功效划分和组织上上也尽可能满足上述要求。
（3）关键应用系统架构标准化。
系统建设早期，北方电信将对应用系统架构实施进行监控，逐步形成一个北方电信标准化应用架构。
回复：满足。我方将经过设计沟通尽力配合贵方做好该项工作。

（4）应用系统应支持集中版本控制和升级管理。
回复：满足9.4.5。

（5）系统应能够灵活地扩展以支持业务增加和新业务需求引入。
卖方应从交易、数据量和通信量等角度，基于业务短期和长久增加潜力对应用扩展性做出充足考虑，同时还应在兼顾短期和长久运行需求基础上考虑现在和未来系统上潜在扩展能力，如对外联网能力等。
回复：满足。详见《技术提议书》3描述，系统在多个层次上全部含有良好扩展性，完全能够支持业务增加和新业务需求引入。
（6）北方电信将经过一套通用评定标准对全部系统是否达成预期目标进行评定。
卖方首先应确保所提供给用功效上是能够满足北方电信业务需求，性能上是经过验证，能够满足业务处理方面非功效需求。同时还应确保应用所采取技术必需符合中国电信IT基础设施结构和技术标准 ，并提供完整而详尽技术文档及用户手册。

回复：部分满足。现在，我方尚不清楚通用评定标准，但我方会尽力配合北方电信，已完全满足本条要求。

3.1.4数据指导标准
卖方应说明所提供给用是怎样去遵守以下描述数据架构指导性标准：
（1）在北方电信建立统一共享数据来提供计费帐务方面数据和应用对应和单一用户视图。
回复：满足。
（2）遵守北方电信所定义和控制共享关键数据逻辑模型和接口访问标准，共享关键数据如用户资料、资产数据、系统配置数据集中存放，统一维护，在北方电信内部含有协同操作功效。全部应用系统不得再独立拥有其和关键共享数据模型相同或反复数据模型。
回复：满足。我方应用将经过EAI平台对北方电信所定义和控制共享关键数据逻辑模型进行访问。
（3）应用系统在提交（或放置）数据前，应将其过滤或转换为符合北方电信相关数据标准格式。
回复：满足。通常EAI平台中会提供数据转换服务，我方完全遵从我方应用在提交数据前，将数据过滤或转换为符合北方电信相关数据标准格式。
（4）数据和应用并存应有清楚主从关系以确保数据定义一致性。交易数据和分析数据应分开进行存放。
回复：满足。我方应用从数据字典、应用架构多个方面确保数据定义一致性；交易数据和分析数据也是分开存放。

3.1.5技术指导标准
卖方应说明所提供给用将怎样去遵守以下描述技术指导性标准：
（1）各应用系统应支持总集成商采取EAI (包含集成中间件、共享关键数据模型、应用界面定义和工作流引擎) 技术进行应用整合，各应用系统间接口须符合总集成商确定接口规范。
（2）为每个用户群，包含用户，提供一个一致、个性化定制和易于使用界面，该界面应提供对全部相关应用、数据和服务集成访问接口。
（3）应制订一致用户界面标准，并说明是B/S架构还是C/S架构。

回复：满足。我方应用系统在J2EE上进行开发，是100%B/S构架，我方提供接口能够基于JMS、RMI或WebService，数据交换基于XML，很方便地支持和现在各主流