北方电信业务支撑系统二期工程技术规范书(1).docx

《北方电信业务支撑系统二期工程技术规范书(1).docx》由会员分享，可在线阅读，更多相关《北方电信业务支撑系统二期工程技术规范书(1).docx（65页珍藏版）》请在三一办公上搜索。

1、北方电信业务支撑系统二期工程技术规范书（综合客服、生产调度应用软件部分）中国电信集团公司北方电信事业部二OO三年一月 目 录第一章 总则11.1 概述11.1.1 规范定义11.1.2 规范内容11.1.3 规范依据11.1.4 规范要求11.1.5 规范书有关内容的澄清21.2 对卖方建议书的要求21.2.1 技术规范书点对点应答书要求21.2.2 建议书的内容格式要求31.2.3 其他一些要求31.3 报价体系要求41.3.1 总体要求41.3.2 报价体系要求41.3.3 服务报价要求51.3.4 培训报价要求51.4 系统文档要求51.5 保密要求6第二章 工程说明62.1 工程概况6

2、2.2 北方电信网络现状72.2.1 交换网72.2.2 智能网72.2.3 数据网72.2.4 业务支撑网现状82.3 工程建设方案82.3.1 总体框架82.3.2 系统建设实施92.4 工程建设规模92.5 本期工程所需软件说明10第三章 业务支撑系统技术要求113.1 总体要求113.1.1 质量性能要求113.1.2 技术性能要求123.1.3应用指导原则123.1.4数据指导原则133.1.5技术指导原则133.2 安全性要求143.2.1 系统级安全143.2.2 应用级安全143.3 系统技术路线要求153.4 与相关系统的接口技术要求183.4.1 北方电信事业部与相关系统的

3、接口技术要求193.4.2 北方9省（区、市）与相关系统的接口技术要求203.5 软件开发要求223.6 网络带宽需求22第四章 业务功能需求224.1 业务支撑系统软件体系结构224.2 综合客服功能需求244.2.1 销售管理过程254.2.2 客户管理264.2.3 客户经理管理294.2.4 业务受理304.2.5 收费管理324.2.6 故障受理344.2.7回复344.2.8 业务咨询354.2.9 投诉建议354.2.10 业务查询364.2.11 主动服务364.2.12 销帐管理384.2.13 系统管理394.2.14 统计分析404.3 生产调度管理功能需求424.3.1

4、 用户界面424.3.2 系统要求424.3.3 功能需求444.4网络资源配置管理494.4.1网络资源数据管理494.4.2网络资源配置494.4.3与其他系统的关系50第五章 售后服务要求505.1 系统服务要求505.2 售后服务要求51第六章 软件开发、项目组织、技术培训要求516.1 工程计划及进度516.2 项目组织要求526.3 技术培训要求52第七章 其他要求52第一章 总则1.1 概述1.1.1 规范定义本文件为北方电信业务支撑系统二期工程（综合客服、生产调度和网络资源配置管理功能应用软件部分）的技术规范书。提供本期工程相关应用软件的公司（以下称卖方）应向中国电信集团公司北

5、方电信事业部（以下称买方）就系统所需的应用软件作出详细答复。 回答：满足。1.1.2 规范内容本规范书针对本次项目所需要的综合客服、生产调度和网络资源配置管理功能应用软件部分提出相应的技术规范要求。本规范给出了买方中国电信集团公司北方电信事业部对北方电信业务支撑系统二期工程在应用软件的技术、性能、服务等方面应满足的各项要求，这些要求将在以后的各章节中列出，以供卖方编写方案建议书、软件配置、供货及报价书之用。请卖方根据自己所能提供的软件，给出详细的方案建议书和商务报价书。回答：满足。1.1.3 规范依据（1）ISO、ITU-T、ETSI、IMTC、IETF等软硬件技术标准；（2）信息产业部、原邮

6、电部、中国电信集团关于业务支撑系统的相关技术体制和技术规范；（3）中国电信集团公司北方电信业务支撑系统技术规范V1.0；（4）中国电信集团公司北方电信业务支撑系统业务规范V1.0；（5）中国电信集团北方电信事业部交换网、传输网、数据网的建设方案及相关业务量分析和预测结果；回答：满足。1.1.4 规范要求（1）卖方应承诺所提供的软件在产品性能、技术指标、服务内容等方面满足本规范的要求；回答：满足。（2）当买方有新建议，而本规范又尚未包括或和本规范不符时，则应符合买方新建议的要求；对于买方尚未有标准的，而本规范又未提及的部分，卖方提出其标准，留待双方认可后执行；回答：满足。（3）当卖方的设备中包含

7、自己的专用标准，应在建议书中具体说明，并附上相应的详细资料。回答：满足。（4） 卖方应列出其建议书中所提供设备和系统在世界范围内和国内的应用情况，诸如最大规模、业务类型及开展方式、用户数量等。回答：满足。1.1.5 规范书有关内容的澄清（1）卖方对于规范书的疑问可以通过书面材料与买方联系。在规定的建议书提交最后期限以前，买方将以书面材料给予答复，有关买方答复材料的复印件也将递交所有得到技术规范书的卖方。回答：满足。（2）在技术谈判的各个阶段，买方将以书面形式要求卖方对有关问题进行进一步的技术澄清，卖方应以书面资料给予正式应答；所有各阶段的技术澄清文件都将作为合同附件。回答：满足。（3）未经买方

8、许可，卖方不得以任何形式向第三方提供本文件的全部或部分内容。回答：满足。（4）买方在任何时候保留和拥有对本文件的解释权和修改权。买方有权在签定合同前，根据需要修改和补充本技术规范书，修改补充后的最终技术规范书将作为合同的附件。回答：满足。（5）本工程技术规范书要求针对本规范书描写的综合客服、生产调度和网络资源配置管理功能应用软件部分进行详细应标，并要求符合业务支撑系统总体软件体系结构。回答：满足。1.2 对卖方建议书的要求卖方在收到本文件后，应提供的资料包括以下几部分：（1）对本文件的点对点应答书（2）技术建议书（3）报价书回答：满足。1.2.1 技术规范书点对点应答书要求卖方的应答书中，要求

9、对本文件的技术规范部分和商务合同部分所提出的各项条款进行逐项答复、说明和解释，首先对实现或满足程度明确作出“满足”、“部分满足”、“不满足”等应答。在答复中，凡采用“详见”、“参见”方式说明的，应指明参见文档的具体章节或页码。请卖方特别注意：凡采用“详见”、“参见”方式说明的条款，必须在点对点应答书中注有适当的总结性文字，简洁、明了地回答相应的条款。对于规范书中要求列举的条款，必须在点对点应答书中进行列举，不得简单答复“满足”等，否则视该条款的应答为“不满足”。如果回答“部分满足”，需要详细说明哪些部分满足，哪些部分不满足，并且详细说明原因。回答：满足。1.2.2 建议书的内容格式要求卖方所提

10、供的建议书应按照以下内容格式进行编制：（一）综述；（二）工程技术规范书；（三）技术规范书点对点应答；（四）总体方案及综合客服、生产调度和网络资源配置管理功能部分方案建议；（五）应用软件详细配置清单；软件的详细配置原则或配置说明、相关计算方法和依据，包括必要的公式、表格或图表。（六）应用软件功能详细说明；（七）硬件配置要求说明；即软件运行环境说明，卖方所提供的应用软件对硬件的具体要求，包括所需要的硬件组织结构图、硬件处理能力估算、硬件配置要求说明及推荐硬件配置。需要说明的是，本次工程硬件将由买方根据卖方所提供的应用软件的需要进行自主采购，但卖方必须提出对硬件处理能力、配置要求等各方面的需求，并对

11、最终结果进行确认。（八）系统软件详细配置清单及功能详细说明；即软件运行环境说明，卖方所提供的应用软件对系统软件的具体要求，包括所需要的数据库、中间件的具体配置要求说明，以及卖方所提供的应用软件运行所必须要的其它系统软件、测试软件、开发软件等需要向第三方采购的通用性系统软件。并详细列出所需要的这些系统软件的种类、推荐使用的具体产品（如果必须采用某种产品的需要特别说明）、License数量等，以及这些软件的报价并对最终结果进行确认。需要说明的是，这些软件的报价将作为可选项单独报价，不计入总价。（九）供货计划及工程进度安排详细说明；（十）分工界面，要求图示并加以说明；（十一）测试及验收；（十二）培训

12、计划；（十三）技术服务、支持；（十四）所提供软件的技术文档；（十五）相关资质或许可证。回答：部分满足。因为本款中对建议书格式与投标要求中对格式要求不一致，按照本规范与投标要求不一致的地方以投标要求为准的原则，我方将按照投标要求进行格式编排，但内容会覆盖以上条款所含内容。1.2.3 其他一些要求北方电信业务支撑系统二期工程的需求由买方提出，软、硬件的配置由买方协助卖方进行。卖方在进行业务支撑系统设置和设备配置时应遵循以下原则：（1） 卖方应以技术先进、经济合理，有利于今后发展的原则进行业务支撑系统二期工程的设计和软、硬件设备的配置。（2）根据买方的建议和要求，卖方应向买方提供优化的设计方案。（3

13、） 卖方在给出业务支撑系统二期工程的优化方案时，应以书面材料解释其业务支撑系统优化设计的思想、原则、步骤及利弊。（4） 对于由卖方提供的硬件设备，该设备应是以至少十年使用期设计的，卖方要保证不论提供的设备是否还生产，在使用期内买方可得到备件。（5）卖方应根据本规范书的要求在规定时间2003年2月10日下午4:00之前提供技术建议书（中文）和报价书（中文），其中建议书要求提供8套，报价书3套（单独密封包装），并同时提供建议书和商务报价书的电子文档（MS OFFICE文档形式的光盘）。回答：部分满足，因为在投标要求中提供的建议书为套，而在投标要求中的要求是套，根据买方提供的投标人的问题答复（综合客

14、户部分）的答复“以投标要求为准”，因此将提供套建议书。1.3 报价体系要求1.3.1 总体要求（1）报价应包括根据系统要求的所有必须的软件、安装材料、技术文件及安装调测、培训、技术支持等；（2）报价应包括软件的名称、版本号、配置模块、数量等详细内容；（3）报价应分别以美元或人民币为单位；（4）报价应按目录价、折扣价和折扣率分项列清；（5）如果卖方提供的设备有多种可选配套软件，卖方可以建议买方采用某些业务或功能，同时应详细描述和说明这些业务或功能并作为可选项提出报价，可供买方选择的设备和功能报价单列，但不计入总价；（6）卖方在报价中应明确标注采用的第三方硬件、软件产品，凡第三方软件产品不由卖方直

15、接供应，应注明其供应商。回答：满足。1.3.2 报价体系要求请卖方按照以下各项要求分别报价：（1）本次配置所有软件总价；（2）所有软件配置清单及报价；（3）以省（区、市）为单位，本次配置的各省（区、市）所有软件清单及报价，以及北方电信9省（区、市）汇总价；（4）系统所有必须配置的软件清单、功能说明；（5）系统所有可选配置的软件清单、功能说明及相应各项报价，此部分报价不计入总价；（6）根据本规范书要求其他不计入总价的相关配置清单及报价（如硬件配置清单、系统软件配置清单等，具体内容参见后续章节）。回答：满足。1.3.3 服务报价要求卖方应对下述服务项目进行报价：（1）安装卖方负责所提供硬件、软件的

16、安装。（2）二次开发和客户化卖方负责根据北方电信的需求对所提供的软件进行相应的剪裁、客户化和二次开发工作。（3）系统调测卖方应负责所提供硬件、软件的调测，并负责配合系统内相关设备的调测。（4）技术服务技术服务分为基本技术服务和可选技术服务，基本技术服务应列出单价和合价，并列入必选报价及总价中；可选技术服务列入选项报价中，只列单价，并且不记入总价。基本技术服务包括技术支持，时限为系统终验完成后的两年，卖方应提供技术支持时限内7*24小时的技术支持。回答：满足。我方已对上述服务内容进行报价，详见技术服务附件和报价清单。1.3.4 培训报价要求请卖方根据本规范书对于技术培训要求的内容，列出培训人员的

17、费用单价及详细的培训计划（包括时间、地点、课程等），并作为可选项单独报价，不计入总价。 回答：满足。1.4 系统文档要求要求卖方提供详细的文档资料，对所提供的系统文档资料要求如下：（1）提供的技术文件应与提供的软件相一致，技术文件应该全面、完整、详细；（2）提供的技术文件应能够满足软件安装、使用、维护、应用开发的需要；（3）应用软件文档应该包括： 软件需求说明书 系统总体设计说明书 系统概要设计说明书 数据库设计说明书 详细设计文档 应用软件清单 测试计划、测试方案 测试报告 试运行报告 维护手册 操作手册 版本说明 API说明（4）应提供完整的、准确的源代码，源代码文档要求有详尽的说明和注释

18、；（5）文档和资料应提供电子文档和纸面文档，电子文档格式为MS Word文档。回答：满足。根据商务规范书的协定，我方将开放应用软件的全部源代码（应用软件中的乙方自有软件模块除外）。1.5 保密要求卖方除以下情况外，非经北方电信事业部书面许可，不得将本文件的任何内容透露给除北方电信事业部以外的第三方。经北方电信事业部书面许可，应标商才允许将本文（限于必要部分）透露给其合作伙伴，并保证其合作伙伴不将本文透露给其它人。 未经书面许可将本文件透露给第三方的应标商，将被剥夺中标资格。回答：满足。第二章 工程说明2.1 工程概况在本期工程建设前期，北方电信事业部已经组织建设北方电信事业部业务支撑系统一期工

19、程的建设。一期工程建设了北方电信事业部（地点设置在天津）业务支撑中心。北方9省（区、市）未建设应用平台。一期建设了一套统一集中的结算系统，完成了北方9省（区、市）的南方21省长途来话收敛、北方去话等业务涉及到的与其他运营商之间的结算，以及中国电信省间的网内摊分；一期工程还建设了一套网上营业厅系统，为北方电信事业部及北方9省（区、市）电信公司完成企业宣传、业务开展宣传、客户查询、咨询、投诉等相关的客户服务的Web接入工作。对于前期的交换、数据专业的业务开展，则通过相应的专业网后台系统实现，在业务支撑系统一期工程中未考虑。本期工程需要在一期工程的基础上，更加完善北方电信业务支撑系统，主要建设北方9

20、省（区、市）的业务支撑系统，包括业务支撑系统的综合客服、号线资源管理、综合计费、综合帐务、生产调度和网络资源配置管理管理等功能模块。本期工程建设容量满足2004年年底的业务量需求。在本次招标之前，北方电信组织各省开始了各省呼叫中心平台的建设，计划于2003年3月完成北方9省（区、市）的呼叫中心平台的建设。各省呼叫中心平台的建设将作为各省业务支撑系统的接入层，完成各省话音接入服务，而呼叫中心所需要的所有后台数据和业务流程，包括所有用户数据、所有业务流程都需要在本次应用软件中统一建设、统一管理、统一实现，而呼叫中心仅仅需要调用本次应用软件的各种数据和业务流程。本期工程北方电信事业部将在北方电信范围

21、内定义统一的共享核心数据模型。同时将定义流程模型，与业务结合转化成具体的业务流程。共享核心数据模型和业务流程将被部署到各省的应用承载平台上，各省的应用承载平台负责实施数据模型和业务流程，建立本地化服务和具体的工作流程以及与应用系统的适配器。回答：满足。我方已理解上述内容。2.2 北方电信网络现状2.2.1 交换网从2002年年底交换网络一期工程建设完成后，交换网络将主要承担南方21省来话收敛业务。即在交换网络一期工程建设完成后，在北方9省（区、市）的省会城市分别建TS与LS/GW，在发达城市建立TLS/GW，其它本地网不设交换机，采用省会LS/GW软覆盖的方式。其中省会LS/GW负责与省会城市

22、所在本地网相关的互联互通业务量。已建交换机的本地网由该交换机负责与该本地网相关的互联互通业务量。一期建设的交换网络建设北方20个本地网，共建设22套本地网交换机。在本期工程建设期间，交换网络二期工程也将同时展开，将缩小省会LS/GW软覆盖的覆盖范围，在一些中等发达城市建立TLS/GW。回答：满足。我方已理解上述内容。2.2.2 智能网从2002年年底智能网一期工程建设完成后，智能网将主要承担北方9省（区、市）的新业务开展。根据北方电信事业部智能网建设情况，北方电信事业部智能网业务主要为卡类业务、智能公话等业务。根据智能网建设思路及业务开展的思路以及北方电信事业部关于智能网的建设，在各本地网新建

23、的LS/GW交换机同时具有区域智能网业务交换点SSP的功能，负责所辖区域智能网业务的触发，其中已设置交换机的各个本地网，由该交换机兼作SSP负责本地网内的区域智能网业务（不含国家骨干智能业务），未设置交换机的其他本地网，其区域智能业务由各省省会LS/GW交换机兼作SSP负责。同时北方9省（区、市）统一在郑州设置一套SCP，负责北方9省（区、市）的所有智能网业务的控制和管理。回答：满足。我方已理解上述内容。2.2.3 数据网北方电信事业部IP网一期工程共设20个省域节点，地点设置和交换网相同，在这20个省域节点，每个节点新增2台路由器和1台局域网交换机。在本期工程建设期间，数据网二期工程也将同时

24、展开，将在一些中等发达城市建立省域节点，地点设置和交换网相同，每个节点新增1台路由器和1台局域网交换机。回答：满足。我方已理解上述内容。2.2.4 业务支撑网现状在本期工程建设前期，北方电信事业部已经组织建设北方电信业务支撑系统一期工程的建设。一期工程建设完成了以下主要硬件平台：（1）完成了交换网络一期建设的20个本地网的所有交换机的采集部分的硬件平台建设；（2）完成了北方电信事业部结算系统及网上营业厅的功能的建设，而各省没有业务支撑系统的硬件平台，仅通过远程操作终端完成相应的结算功能。回答：满足。我方已理解上述内容。2.3 工程建设方案2.3.1 总体框架北方9省（区、市）业务支撑系统总体结

25、构采用北方电信事业部中心和9省（区、市）公司两级结构。即所谓的“19”模式，在北方电信事业部和北方9省（区、市）分别建立业务支撑系统平台，在应用层面实现省级集中，在核心数据层面实现9省（区、市）的大集中。北方电信事业部业务支撑中心主要完成综合营销管理、综合结算、生产调度管理、资源管理、统计分析和系统管理等6个功能模块；而省级业务支撑系统主要完成综合客服、综合营销管理、综合计费、综合帐务、SLA管理、生产调度管理、资源管理等8个功能模块。图2.3-1 北方电信业务支撑系统网络框架图在此总体框架下，由北方电信事业部统一定义北方9省（区、市）的核心数据结构，包括用户数据、帐务数据、产品数据、资费结构

26、和资源结构等。在北方电信事业部建立业务支撑系统核心数据的数据库平台，并在其上建立负责北方9省（区、市）全局的应用系统。而在北方9省（区、市）分别建立本省集中的数据库平台和应用平台，省业务支撑系统的数据结构必须与北方电信事业部的定义保持一致，省公司在此基础上建立适应本省实际业务开展情况的应用系统。北方电信事业部和各省级业务支撑平台则通过企业内部通信网DCN网进行相关的数据信息的传输。回答：满足。我方已理解上述内容。2.3.2 系统建设实施北方电信业务支撑系统二期工程的建设实施要遵循“总体规划、滚动建设”的原则。作为全新的电信企业，北方电信9省（区、市）不仅具有中国电信南方21省建设业务支撑系统的

27、丰富的经验，而且扔掉了历史的包袱。因此，北方电信业务支撑系统更应该站在一个更高的高度，充分吸收南方21省“九七”系统、计费帐务系统、1000号客服系统等系统建设的丰富经验，对系统进行合理的总体规划，尽可能避免“信息孤岛”，确保新建设的电信业务支撑系统能够融合以前各系统的各种优点，同时避免以前各系统由于当时技术的局限而带来的不足，真正建设一个高效、完善的业务支撑系统。同时，建设北方电信业务支撑系统二期工程也是一个非常紧迫的工程，要满足业务开展的需要、市场开拓的需要、建设周期的短促，不允许有太多的时间进行充分的准备。因此，在总体规划的前提下，进行滚动建设，确保在保证一个完整的总体规划的基础上，不断

28、完善该系统。回答：满足。我方自主研发的EOS基础平台可以从应用软件架构上满足“总体规划、滚动建设”的需要。2.4 工程建设规模北方电信业务支撑系统二期工程主要是为了解决北方电信9省（区、市）业务网络建设完成后，更好地为电信用户服务，更好地提供对开展业务的支撑。而且本期工程主要满足到2004年，对各个业务系统进行支撑，其建设规模为：本期工程省级业务支撑系统平台包括综合客服、综合计费、综合账务、生产调度管理和网络资源配置管理等功能模块，采用全省集中模式将所有实现这些功能模块的数据库服务器、应用服务器、存储设备、备份设备全部集中在一个省业务支撑中心，考虑到保护投资和以后系统扩容的方便，许多功能模块需

29、要合设同一套服务器。本期工程事业部中心业务支撑系统，根据北方电信实际业务需求，对一期工程建设的结算系统和网上营业厅功能，进行适当扩容或改造。本技术规范书要求卖方在理解北方电信业务支撑系统二期工程建设规模和内容的基础上，就二期工程的综合客服、生产调度和网络资源配置管理功能部分作详细应答。回答：满足。我方已理解上述内容。2.5 本期工程所需软件说明根据北方电信业务支撑系统二期工程建设要求，本工程技术规范书将对该工程的整体情况进行简要描述，并对本工程的应用软件进行整体描述，但请卖方注意，本工程的应用软件共包括事业部业务支撑平台应用软件（共6大功能）和省级业务支撑平台应用软件（共8大功能），但本工程技

30、术规范书只针对其中的省级业务支撑平台应用软件8大功能中的综合客服、生产调度和网络资源配置管理功能提出具体要求。请卖方在理解工程应用软件整体结构的基础上，针对以下方面进行应答和报价：（1）应答范围包括对应用软件整体结构的理解，以及综合客服、生产调度和网络资源配置管理功能在整体结构中的作用及与其他模块之间的关系；回答：满足。我方在技术建议书中详细描述了对应用软件结构的理解，以及综合客服、生产调度和网络资源配置管理功能在整体结构中的作用及与其他模块之间的关系，详见技术建议书2.2.4.1（2）报价范围包括实现综合客服、生产调度和网络资源配置管理功能所需要的设计、开发、服务等方面的费用，具体方式参见对

31、报价体系的要求；回答：满足。我方对此作了详细列举，详见商务报价。（3）为了确保完成综合客服、生产功能和网络资源配置管理功能，请卖方针对所需要的主机存储、备份等硬件种类、配置、处理能力，各类系统软件的种类、各项性能指标的要求进行详细描述，确保买方能够提供足够的应用软件运行环境，以满足卖方提供的综合客服、生产调度和网络资源配置管理功能的正常运行，以及和其他部分功能共同组成一个有机的应用系统。但此部分作为可选项报价，不计入总价；回答：满足。我方不仅从主机的性能、容量方面作了比较详细阐述，而且根据各省的实际业务情况对硬件系统做了相应的配置，保证系统的建设即经济、实用并有很强的扩展性，详见技术建议书6的

32、描述（4）卖方开发的软件如果是事业部业务支撑平台所需要的功能，则只需要在事业部平台使用，如果是省级业务支撑平台所需要的功能，则需要在北方9省（区、市）分公司的9个业务支撑平台使用，因此卖方的应用软件报价必须包括所有需要的软件数量。回答：满足。我方已根据这些要求对系统进行报价，详见商务报价。（5）由卖方所开发的软件，在系统验收之前，卖方须根据买方的要求及时作出设计修改，以保证系统功能的完整性和可靠性；并保证在服务期内免费负责软件的更新、维护以及版本的升级。回答：满足。（6）由卖方所开发的软件，须提供数据和API接口，软件本身应具有灵活的配置文件，以方便维护。回答：满足。综合客服、生产调度和网络资

33、源配置管理应用软件功能需求将在本规范书的后续章节将详细给出具体技术要求。回答：满足。第三章 业务支撑系统技术要求3.1 总体要求（1）应用软件的设计应严格符合本规范三层体系结构的要求，使系统具有良好的灵活性、可操作性和可扩展性，并遵循中国电信集团公司、北方电信的相关接口规范；回答：满足。参见技术建议书的。我方应用系统建立在J2EE标准基础之上，采用三层体系结构。如果原有业务流程发生变化，直接通过修改流程图即可完成；如果业务框架中某些业务属性发生变化，通过数据字典的管理进行配置即可；如果需要开发新业务，则可以利用我方的快速开发工具进行快速开发。我方系统完全采用面向对象技术，具有很强的灵活性、可操

34、作性和可扩展性。我方应用系统遵循中国电信集团公司、北方电信的相关接口规范，详见技术建议书2.2.4.2的描述。（2）为了向客户提供灵活多样的服务，快速适应新业务的开展，应用软件的设计应采用灵活的结构，应采用面向对象、中间件等技术；回答：满足。参见上点答复。（3）整个应用软件系统应能够连续724小时不间断工作，应用软件中的任一模块更新、加载时，在不更新与上下模块的接口的前提下，不影响业务运转和服务；回答：满足。我方整个应用软件系统部署在两台支持负载均衡的应用服务器上，加上数据库和网络设备的冗余备份，能够支持7*24小时不间断运行，软件模块可以动态更新和加载。（4）应用软件应具有较高的自动化程度，

35、如：自动任务调度、自动故障告警、自动任务恢复等；回答：满足。我方应用软件构建在EOS平台基础上，EOS平台本身提供自动任务调度、故障告警、任务回复等机制，同时我方将提供应用网管代理对应用承载平台进行自动故障告警。详见技术建议书的5.1.17.5描述。（5）应具有完整的操作权限管理功能和完善的系统安全机制，能够对每个操作员的每次操作有详细的记录，对每次非法操作产生告警；回答：满足。（6）应能为系统管理员提供多种发现系统故障和非法登录的手段；回答：满足。（7）应采用简洁、直观、友好的图形化中文界面，支持鼠标操作；回答：满足。（8）对于业务处理界面，应保证操作人员能够完全利用键盘操作；回答：满足。（

36、9）对于常用环节，系统应设置快捷键以方便功能间的切换；操作及选择键（热键、菜单选择等）的功能定义在全系统保持一致；回答：部分满足。由于我方采用100B/S结构，对快捷键的支持会相对较弱。（10）应具备相应容错手段，允许操作人员有限范围的误操作；回答：满足。（11）应具有在线帮助功能，并能方便管理员修改帮助信息；回答：满足。（12）支持中文字符集等相关国家标准规定的汉字字符处理，可进行处理、显示和打印。回答：满足。3.1.1 质量性能要求业务支撑系统的建设必须符合如下质量要求：（1）技术先进性：系统设计应采用当前先进而成熟的技术，充分吸收国际厂商的先进经验，并考虑到北方电信9省（区、市）的特殊性

37、，不仅可以满足本期工程的需求，也应把握未来的发展方向。回答：满足。网上营业厅系统数据库采用Orcale 8i，中间件采用基于J2EE标准的BEA Weblogic或 IBM Websphere，数据交换基于XML技术，应用软件采用基于B/S三层体系结构，主要编码语言采用Java，这些都是在业界被广泛使用并经过验证的先进而成熟的技术，在应用软件上，我方基于J2EE平台开发的具有完全独立自主版权的技术支撑平台（包括组件组合技术，数据字典管理，基于XML的数据总线技术，用于页面逻辑和业务逻辑开发的可视化开发环境，多维数据仓库，OLAP分析工具和其他公共服务设施）和以客户为中心的业务框架平台是充分吸取

38、了国际厂商的先进经验，其中技术支撑平台经过BEA、HP、Orcale和我方的联合测试，性能指标超过同类产品主流国际厂商水平（主要是因为我方采用的独特的动态EJB组合技术），整个平台已经有在证券行业有多个大容量运行的案例，属于成熟的技术。在已有的原子服务上开发新的业务逻辑无需编程，并且因为如下原因使得本系统不仅可满足本期工程的要求，也能符合未来技术和业务的发展：1、建立在EOS平台和客户细分基础上的应用系统适应未来以客户为中心的市场分析、营销和服务系统的变化。2、基于J2EE、XML的数据交换能够很好与其他系统进行集成。3、具有新业务快速开发能力。（2）可扩充性：在系统设计时应充分考虑可扩充性，

39、从而确保新功能、新业务的增加应可以在不影响原系统运行的情况下实现。回答：满足。详见技术建议书的2.2.7.4描述，系统在多个层次上都具有良好的扩展性。（3）安全性：系统应保证数据不被非法入侵者破坏和盗用，并保证数据的一致性，对欺诈行为应采取多种检查和处理手段。回答：满足。详见技术建议书的2.2.2.2的描述，系统通过对各个层次的安全策略保障数据的一致性和完整性并采取多种检查和处理手段防止欺诈行为。（4）可靠性及稳定性：应采用相应的故障检查、告警和处理机制，保证数据不会因意外情况丢失或损坏；采用灵活的任务调度机制实现负载均衡，防止“瓶颈”产生，在任何情况下，都应该保持可预见的回答：满足。系统通过

40、设备冗余、数据备份、负载均衡、容错、网络管理的等多种手段保证系统的可靠性和稳定性。（5）准确性：应该能够提供多种稽核手段，保证系统数据的准确性。回答：满足。系统通过基于MAC、HASH、记录数等多种数据稽核手段保证系统数据准确性。（6）成熟性：应尽量选用经过大量运用、成熟可靠的系统。回答：满足。详见技术建议书的2.2.7.3，系统软硬件都选用目前业内的主流厂家和型号。（7）经济性：在满足上述的前提下，选择经济、实用的系统配置。回答：满足。因为系统基于J2EE系统之上的EOS平台我方具有完全自主知识产权，EOS的主要特性是适应变化和业务组件重用性，长期来看能够极大地降低设计、开发、维护成本，所以

41、在能够充分适应未来变化的基础上，极大降低应用系统投资成本。3.1.2 技术性能要求（1）系统应具有较强的安全性和保密性。回答：满足，详见技术建议书2.2.2.2的描述，系统通过多种手段从多个层次加以保障。（2）系统不易崩溃或被破坏，具有良好的恢复能力。回答：满足，关键设备采用冗余配置，通过防火墙实现和公网的隔离，数据存储采用RAID5技术，并定时进行磁带备份，应用软件系统具有流量控制、拥塞控制功能，一般不会崩溃或被破坏。（3）系统应提供多级密码口令或使用硬件钥匙。回答：满足，详见技术建议书2.2.2.2的描述，系统能提供完善的系统控制管理。如需要，系统可以提供使用硬件钥匙。（4）系统有完善的用

42、户组管理，控制不同用户的权限。回答：满足。系统有完善的角色管理，每个角色可以定制权限，用户可以通过映射一个或多个角色控制不同用户的权限。（5）网络及数据库系统可进行访问控制。回答：满足，详见技术建议书的6.2.5以及7.2，系统采用多个层次的访问控制。（6）系统应提供详细的记录日志。回答：满足。系统不仅提供运行日志、操作日志、异常日志等多个方面的日志记录，并且还提供用于跟踪故障的日志跟踪手段。（7）系统必须能够提供完善的业务告警系统。回答：满足，我方系统通过各种日志、声音提供告警，还提供基于SNMP的应用层网管进行业务告警。3.1.3应用指导原则应用应遵循的标准：（1）所有的应用需能够与EAI

43、架构标准（XML, CORBA, Java/JSP/J2EE）接口。回答：满足。（2）应用应是支持消息的 (message based)。回答：满足。（3）所有的应用应是基于UNIX的 (Unix based)。回答：满足。（4）应用必须是支持SMP的（SMP based）。回答：满足。（5）在应用软件管理和监控的功能方面应提供SNMP MIB。回答：满足。以下原则作为中国电信IT战略的组成部分，是所有应用都必需遵守的。卖方应根据本期工程的建设要求，说明所提供的应用将如何去遵守这些原则。（1）符合北方电信对核心应用标准化的需求。计费帐务系统，作为核心应用，允许根据北方电信的特殊要求作有限度的客

44、户化定制。但所有更改必须保证与北方电信核心应用平台的相关标准和技术规范（SDK/API）保持一致回答：满足。我方应用通过EAI平台与计费帐务系统连接，我方开放的应用软件体系结构可以快速适应北方电信对核心应用标准化的需求。（2）模块化的应用架构。应清楚的定义每个模块/应用的功能和业务覆盖范围，避免在一个模块中实现多种功能，保持单个模块/应用与具体业务应用系统的相对独立性，保证系统的统一性和一致性。回答：满足。我方建立在EOS上的应用架构，可以从应用构架上极大地保证模块之间地松散耦合；另外我们从应用功能划分和组织上上也尽可能满足上述要求。（3）核心应用系统架构的标准化。系统建设初期，北方电信将对应

45、用系统架构的实施进行监控，逐渐形成一个北方电信的标准化应用架构。回答：满足。我方将通过设计沟通尽力配合贵方做好该项工作。（4）应用系统应支持集中的版本控制与升级管理。回答：满足9.4.5。（5）系统应可以灵活地扩展以支持业务增长和新业务需求的引入。卖方应从交易、数据量和通信量等角度，基于业务的短期和长期增长潜力对应用的扩展性做出充分的考虑，同时还应在兼顾短期和长期运营需求的基础上考虑目前和未来系统上潜在的扩展能力，如对外联网能力等。回答：满足。详见技术建议书3的描述，系统在多个层次上都具有良好的扩展性，完全可以支持业务增长和新业务需求的引入。（6）北方电信将通过一套通用的评估标准对所有系统是否

46、达到预期目标进行评估。卖方首先应保证所提供的应用功能上是能够满足北方电信的业务需求的，性能上是经过验证的，能够满足业务处理方面的非功能需求的。同时还应保证应用所采用的技术必须符合中国电信的IT基础设施结构和技术标准 ，并提供完整而详尽的技术文档及用户手册。回答：部分满足。目前，我方尚不清楚通用的评估标准，但我方会尽力配合北方电信，已完全满足本条要求。3.1.4数据指导原则卖方应说明所提供的应用是如何去遵守以下描述数据架构的指导性原则的：（1）在北方电信建立统一的共享数据来提供计费帐务方面的数据与应用的对应和单一的客户视图。回答：满足。（2）遵守北方电信所定义和控制的共享核心数据的逻辑模型和接口访问标准，共享核心数据如客户资料、资产数据、系统配置数据集中存储，统一维护，在北方电信内部具有协同操作的功能。所有应用系统不得再独立拥有其与核心共享数据模型相同或重复的数据模型。回答：满足。我方应用将通过EAI平台对北方电信所定义和控制的共享核心数据的逻辑模型进行访问。（3）应用系统在提交（或放置）数据前，应将其过滤或转换为符合北方电信相关数据标准的格式。回答：满足。一般EAI平台中会提供数