企业电商服务平台（投标书技术部分）

正文 投 标 文 件 投标书二（技术部分）
招标编号：**号 招标项目：**平台 招标单位：**有限公司 招标代理:**有限公司 投标单位:**有限公司 二〇一六年X月X日 一、 技术部分 1.1. 项目概述 1.1.1. 项目背景 1.1.2. 产业现状分析 1.2. 系统总体架构设计 1.2.1. 总体设计思路 基于当前纺织服装产业转型升级的需要、“互联网+服装时尚产业”公共服务升级的需要，以服务纺织服装品牌、渠道、交易等商业模式转型为目标，为市“互联网＋服装时尚”产业提供平台支撑，为企业提供完善的线上功能服务，平台力争在创新、服务、交易、标准、规范等方面走在行业前列，提升纺织服装产业的整体竞争力。

基于我公司构建智慧城市的成熟技术体系，确保平台无论在性能、可扩展性、稳定性、技术先进性、业务适配能力等各方面具有强有力的保障。平台整体基于业界最常用的Jave EE技术体系，同时结合SOA、微服务等先进设计思想综合构建。

具体建设内容如下：
（1）
平台业务建设（业务分类）：
电子商务全网营销类服务：通过构建标准化的服务接口，实现第三方电子商务平台（如淘宝等）与平台的对接，帮助企业电子商务平台上实现商品信息的“一键式”发布，从而实现全网式营销。

政务服务：通过与市企业融合服务平台的对接，或者与政务部门系统的对接，能够迅速便捷的为服装企业提供一站式的相关部门的政务服务，包括：社保办理（社保局）、社保查询（社保局）等服务。

公共服务：通过构建标准化的服务接口，实现第三方服务机构系统与平台的对接，为企业提供专业的、定向的公共类服务，包括：法律服务、人员招聘服务、投融资服务等。

政企沟通服务：构建以企业为主体，并引入政府部门、园区管理部门、行业协会等参与者的合作社交网络，解决企业之间，企业与相关机构之间信息不通畅，难对接的问题，支持WEB、即时通讯、APP等多种沟通模式与相关部门可对交流信息有效监管的能力。

信息资讯服务：帮助企业获得应知、须知、要知的资讯信息，结合用户行为和属性为用户精确定位资讯，挖掘信息与信息的关联关系，为用户呈现更多有价值的资讯，帮助企业快速把握发展方向和市场动向。提供国家政策资料、招商引资、行业动态、商业趋势等信息服务，并能实现定向推送。

商家评级系统：包含商家信用查询，评级权限管理等。

（2）平台基础建设（能力支撑）
平台基础服务：邮件服务：邮件服务是平台所提供的，能够实现邮件通讯功能的服务组件。

检索服务：能够提供对平台上的可公开信息能够采用关键词检索。

统一认证服务：使平台具有对平台用户的登录进行统一认证管理的能力。实现了用户只需要登录一次，即可访问所有相互信任的应用系统。

文件服务：提供平台的文件上传、下载服务组件。所有通过服务上传的文件都集中存储在文件服务器上。

（3）平台服务资源管理框架建设 信息类服务能力：汇聚各类资讯信息，解决企业获取资讯不及时，信息杂乱无章，无重点的问题，并通过多种技术对接模式实现用户资讯获取。能够提供提供各类用户应知、须知、要知的资讯信息，并通过融合化展现、个性化引导、智能化推荐，挖掘潜在信息、提升用户信息获取效率。

业务类服务能力：能够提供各类线上线下相结合的业务服务，满足不同发展阶段不同规模服装企业的需求，实现服务定制化，个性化应用。能够实现服务定制化，个性化应用，实现用户获取服务行为的大数据挖掘与智能分析，实现在线服务，实现兼容与扩展目前已存在的各类企业服务的平台能力。

交流类服务能力：构建以企业为主体，并引入政府部门、园区管理部门、行业协会等参与者的合作社交网络，解决企业之间，企业与相关机构之间信息不通畅，难对接的问题，支持WEB、即时通讯、APP等多种沟通模式与相关部门可对交流信息有效监管的能力。

管理类服务能力：提供企业内部管理的服务，帮助企业建立线上虚拟的办公场所与员工工作空间，解决企业内容信息化管理水平不一，自建投入较大的问题，实现企业云服务所需的通用型信息化管理服务。

（4）业务支撑平台建设 包含业务运营管理系统，平台运维管理系统，访问渠道管理系统，服务资源聚集系统。

1.2.1.1. 平台业务阐述 **平台将以企业电商服务为业务基础，以政务服务，公共服务，资讯服务，政企沟通服务，商家评级服务为助力服务，共同打造新一代互联网模式的信息化平台。

其业务形态层级模型为：
l 底层数据资源汇聚 利用平台微服务组件，并结合微服务平台对应的一系列标准规范，将市民融合平台，企业平台，征信平台，服装在线，智慧政务等多方平台的基础数据资源汇聚，打破信息孤岛的局面，为**平台丰富的应用展示提供基础数据支撑。

l 中间数据整合，统一管理 将用户与基础数据关联，将有一定关联的数据之间做标签关联，根据个性化需求将用户的行为数据做智能分析并打上标记，将一些有价值的业务数据做深度挖掘，将所有信息数据做统一的智能管理，形成一个全面管理的平台数据资源池。

l 上层构建丰富的应用 在统一数据池的基础之上，构建满足业务需求的，以及运营拓展的个性化服务。诸如：电子商务营销类服务，社保服务，资讯服务，沟通服务，法律服务、人员招聘服务、投融资等。

并可以根据需要，通过数据资源池，为其他第三方平台，以服务的形式提供优质的数据资源服务，体现平台的额外价值。

1.2.1.2. TOGAF方法论 为了给企业信息化架构开发提供了一个详细的方法和相关支持资源的集合，确立系统构架的国际权威组织——开放组（the open group）提出开放组体系结构框架（TOGAF）。开放组体系结构框架是300多家开放组的会员单位在美国国防部的信息管理技术架构的基础上，共同努力提出的一种自上而下、由任务和项目迭代驱动的顶层设计方法。

开放群组体系架构框架TOGAF支持四层的企业架构子集：  第一层的业务（或业务流程）架构：定义商业策略、管理、组织和关键业务流程。  第二层的技术架构：描述支持核心部署和关键任务应用的软件基础设施，包括IT安全架构、网络架构、通信架构、服务器等以及中间件。  第三层的数据架构：描述一个组织逻辑的和物理的数据模型以及数据管理资源（内容管理和知识管理）。  第四层的应用架构：描述支持业务架构所需要、所要求的应用和应用架构，这种结构为待配置的个人应用系统提供了一个蓝图，从他们的交互关系到该组织核心的业务流程，以适应信息化建设项目的在线方式和自我服务方式的数据获取和服务获取。

**平台将基于TOGAF方法论及相应工具进行架构开发阐述，下文会详细介绍**平台的架构。

1.2.1.3. IRM（信息资源管理）方法 信息资源管理是70年代末80年代初在美国首先发展起来然后渐次在全球传播开来的一种应用理论，是现代信息技术特别是以计算机和现代通信技术为核心的信息技术的应用所催生的一种新型信息管理理论。  信息资源管理包括数据资源管理和信息处理管理。数据资源管理强调对数据的控制，后者关心管理人员在一条件下如何获取和处理信息，且强调企业信息资源的重要性。

信息资源管理是企业管理的新职能，产生这种新职能的动因是信息与文件资料的激增、各级管理人员获取有序信息和快速简便处理信息的迫切要求。

信息资源管理的目标是通过增强企业处理动态和静态条件下内外信息需求的能力来提高管理的效益。以期达到“高效（Efficient）、实效（Effective）和经济（Economical）“的最佳效果，也称3E原则，三者关系密切，互相制约。

**平台将基于上述方法理论，结合平台定制化需求，从架构层面出发充分考虑IRM的管理性，包括数据权限控制，文件访问控制，个性化的资源操作控制等。应需满足平台对资源管理的需求。

1.2.1.4. 整体架构 平台整体基于Jave EE技术体系，基于微服务设计理念构建，所有应用、服务基于Docker容器引擎部署，具备非常完备的安全体系、管理体系，同时由于整体基于分布式架构设计，有着极其强大的性能扩展机制。

平台整体架构主要分为四大大部分：
PASS平台：用于部署、管理所有应用 微服务平台：用于监管所有服务和API 平台组件：管理平台开发所用到的所有技术组件，便于重复利用。

运维监控平台：是对基础设施、数据库、应用、服务、监控的一体可视化管理系统。

（整体架构结构图）
1.2.1.5. 功能架构 1.2.1.6. 业务流程 1.2.1.6.1. 设计原则 本系统的设计遵循以下原则：
（1）统一规划：本平台体系架构和总体架构的设计，必须是以全平台利益为中心，面向纺织服装产业的**平台的整体框架，以应用一体化为总体技术思路。

（2）可实施性：**平台的建设必须是在目前的应用框架下可以运营的。业务功能的实现可以分布实施快速见效。

（3）可扩展性：考虑到信息化建设是一个循序渐进、不断扩充的过程，系统采用分层设计和构件化开发方法，整体构架考虑与现有系统的连接，为今后系统扩展和集成留有扩充余量。

（4）先进性：系统在设计思想、系统架构、采用技术、选用平台上均具有一定的先进性、前瞻性、扩充性，考虑一定时期内的业务的增长。在充分考虑技术上先进性的同时，采用成熟的技术和普及的技术，保证建成的系统具有良好的稳定性、可扩展性和安全性。

（5）标准化：通过本项目的实施，建立**平台的数据规范和基础平台标准，以及未来新应用系统开发的技术规范和开发框架。

（6）开放性：可以实现异构系统的互联互通，通过基础类子系统组建**平台总体框架。

（7）高可用性：数据交换平台、应用服务器平台以及中心数据库等将成为**平台的基础平台和各个应用之间的关键枢纽，因此，应有适量冗余及其他保护措施，平台和应用软件应具有容错性、健壮性等，保证7×24连续服务。

（8）可管理性：采用集中管理模式，配备与各个实施阶段相适应的实用的系统管理手段，对系统设备、系统资源、应用软件、数据实行全面的管理。

（9）可维护性：系统设计应标准化、规范化，分层设计，组件化实现，降低应用整合平台的维护成本。

（10）统一管理 系统应能实现基础实施、数据库、应用、服务、监控、安全、性能等方面的统一运维管理。

（11）兼容性 选择符合国家、省、市和新区标准的软、硬件平台。系统实施要在形成高度统一和集成的系统解决方案基础上，整合现有的网络资源和数据资源，对已经建成的基础设施和数据资源，在本系统建设中要加以充分利用。在基础数据库和业务系统建设中，要注重系统之间的衔接，切实保障系统之间的信息资源共享，避免重复建设，最大程度发挥现有各类资源的效益，保护已有的投资。

（12）规范性 进行全面需求分析，把握业务实质，遵守业务操作规范，遵照国家规范标准和有关行业规范标准，设计标准的信息分类编码体系，规范系统数据库，形成全局统一的操作模式、报表表式，建立开放式、标准化的系统数据输入、输出格式等。

（13）稳定性 系统必须有足够的健壮性，在发生意外的软硬件故障、操作错误等情况下，一方面能够保证回退，减少不必要的损失；
另一方面能够很好地处理并给出错误报告。系统能抵抗可预知的安全、大数据量访问等因素并稳定运行。

1.2.1.6.2. 设计规范 (1)交互总体验要求 引入前后端分离技术，结合SSO单点登录技术，以统一的用户界面提供给用户，使组织可以快速地建立中心对用户、中心对内部成员和中心对其他第三方机构的信息通道。各类操作人员只需通过一个统一的登录入口，就会得到他们所需要的工作视图，真正实现了一站式的操作体验。界面要求简洁、直观，默认的配置符合大多数用户的审美观点和使用习惯，一般鼠标点击次数不超过三次可以到达目标页面。

(2)用户体验设计 交互设计的目的就是要在技术、功能与人之间架起桥梁，将软件与交互这两个概念结合起来才能给大家提供既简单又有意义的方案体验。在交互设计中，关键的就是对人的理解，要理解人们的行为还有他们要做到的事情。同时还要将这些理解运用到设计界面以及功能上，满足人们的需求。在每一次设计的过程中，都需要遵循完整的流程，从分析直到最终的设计。只有这样才能获得有效的、长久的成果。

在这次建设中我们提供专业UI设计师和前端工程师，提供简洁、便捷、与用户需求更贴切的界面设计和交互设计，注重业务模块之间的搭配和灵活性。

(3)页面结构及界面设计 网站结构设计与优化的关键在于首先要把内容进行正确分类，然后再让整个结构尽量均衡。采用多维结构方法，帮助用户在使用系统时可以准确定位，迅速找到所需的服务信息。

1.2.1.6.3. 设计思路 通过研究分析服装服务平台得设计，充分挖掘各类用户提供与之相关得需求、服务、人脉、资讯等各类自有空间管理功能，掌握全方位得在线服务功能（虚拟商务地址、多功能虚拟会议室租赁服务、金融服务、企业培训服务、知识产权、IT服务、众包服务、平台扶持券管理），将各部门原来线下的服务事项从打造集约管理网的视角和需求出发，以服务主题、服务对象等多个维度进行逻辑关联、集聚重组，使用户获得高效化、规范化、便捷化的后勤服务，实现平台管理服务效能的提升和办事管理模式的创新。

具体说来，即紧紧围绕 “平台管理功能“、“线上 企业管理功能“ 、“活动管理功能“、“联系人管理功能”、“服务管理功能”、“需求管理功能”、“资讯管理功能”和“企业展台功能”等管理要素，着重从服务模型细分、服务个性体现以及服务监管支持等几个维度入手，通过对服务对象进一步细分(如，首页、商品服务、服务需求、政务办事、企业社交、我的空间)，并在此基础上归纳整合，形成具有代表性的用户服务对象人群，明确不同纬度用户群体的特征，针对平台内容的不同需求，以及对不同需求渠道的差异偏好，作为后期内容梳理和服务渠道整合的基础；
并且可以通过渠道的组合，充分发挥不同渠道的优势，形成协同服务的模式，提高平台有效性、及时性和针对性。

(设计思路图) 通过开放式的PAAS平台，提供丰富的基础性服务，保障服务的低成本快速开发、部署与运行。提供以人为中心整合集成各种服务，集中有效管理个人活动产生的信息，一体会整合不同的互动沟通方式。针对不同的对象将专项服务、个人信息和互动沟通自然融合。

1.2.2. 平台架构设计 整体架构组件图如下：
w 基础设施：
采购市面可靠的IAAS服务，将网络，硬件设施等托管于可靠的IAAS服务之上，或基于架构模型，分别采购对应硬件设施，做本地化集成管理。在这基础之上部署关系型数据库，非关系型数据库，消息队列，存储Docker镜像，文件，以及构建网络分布等，以满足和支撑上层微平台的运作。

w PAAS平台：
基于流行并强大的Docker技术（集装箱模式）构建应用的多实例集群环境，并结合PAAS中其他组件，保证运行容器的稳定，高效，安全，以及7*24小时的基本能力。

w 微服务平台：
微服务平台作为平台和外部接口数据的中控层，在这里所有的数据都通过该平台扭转，平台负责数据格式的统一化输入输出，以及平台级服务治理（包含服务注册，服务发现，服务鉴权，访问控制，黑白名单等）。以保证数据进出的安全，稳定，高效等需求。

w 增值组件：
增值组件或叫个性化组件，该模块除了基础的服务组件（单点登录）以外还会根据业务的需要弹性拓展，与个性化定制，以满足平台不同发展时期的个性需求，诸如：基于沟通的即时通讯，基于运营方法的短信推送，基于用户体系的实名认证，权限管理等，基于电商平台的线上支付组件等。

w 支撑系统（运营/运维）：
从运维角度：配合业务对应的运维管理系统，完善方便平台的业务建设与维护，其中包含诸如：基础平台设施监控，用户管理系统，审核系统等。

从运营角度：可以配合运营方案，做一些运营方面的个性化技术系统，诸如：访问分析，渠道访问统计，注册统计，交易统计等。

另外，平台可定制建设“开发者门户”系统，开发者门户系统主要面向第三方企业或平台公司，让他们可以借助平台的资源以及整合价值发布推广企业的有价值服务，满足营销需求。

w 标准体系：
主要针对微服务平台，对数据接入接出做出标准规范，诸如：数据格式规范，协议规范，服务治理规范，权限安全规范等，文档接口等，对接部分后续会详细阐述。

另外如果提供第三方企业发布价值应用的功能，则会有相应的服务发布标准以及服务上传，程序编码等对应的规范流程。

w 多端展示：
可以根据平台需要，个性化定制包括PC端以及之外的多端使用方式，诸如：手机APP， PAD等满足多元化访问需求，提升用户使用体验。

1.2.2.1. 应用架构阐述 业务系统只需要关心业务本身，应用系统与应用系统之间非常松的耦合，用户只关心当前应用的业务本身，而不会影像到其他的应用业务，所有用到的应用之外的数据资源均可以通过微服务平台获得，同时微服务平台是一次建设，多系统复用的状态，这里的多系统当然也包括外部的第三方平台系统。

应用本身的资源数据获取均约束于微服务平台制定的一系列规范流程，诸如：交互协议:http/webservice，报文格式：json/xml等。

平台的应用模块描述：
平台应用将分类部署，分类开发，将从属一类，或有紧密关联关系的列为同一类应用整合独立出来。

l 电子商务全网营销类：
包含商品的发布，商品的评级，商品的信用，商品的图片展示，商品的描述，以及与其他平台的对接实现全网类营销等功能。该模块应用会将核心公共的功能抽离并统一封装，灵活的体现与其他模块的耦合。

如下图该应用模块的架构展现：
l 政务类：
提供诸如：社保，公积金等政务类查询以及定制化办理服务，该类应用主要以查询为主，并做本地化缓存服务，以提升应用使用效率，并和本地用户体系做关系关联以达到数据关联性，为数据整合，个性化分析做基础铺垫。

如下图：
l 公共服务类：
提供诸如：法律服务，物流服务，人员招聘服务，投融资服务，协同制造服务等，均作为一类模块发开并部署。

如下结构图：
l 政企沟通类：
沟通模块单独封装，平台内部对其他应用模块提供通讯API，所有平台沟通统一走沟通模块，该模块统一对沟通信息做存储与管理（结合管理系统做信息筛选与审核），应个性化需求可以对沟通结果，或通过用户行为分析结果，对用户做对应智能推送，以做到沟通及时相应以及辅助运营策略。

另外，针对定制化开发的其他展示端，如APP，PAD等，单独部署/开发即时通讯系统，以完善平台的沟通机制，真正做到信息通畅，沟通及时。同时即时通讯模块需和用户体系做管控管理。

l 信息资讯类：
信息资讯模块将通过两种方式，支撑其他模块的信息资讯展现。

外系统接口：该模块通过微服务平台接入必要信息资讯，并做部分资讯入库操作，来实现信息的展现在。

定制化的CMS系统：其他模块通过连接CMS系统发布的资讯信息完成展现，同时CMS系统需要根据情况做线下运维，来保证信息的及时与有效。

l 商家评级类：
该模块分为商家信用查询，评级权限管理。

商家评级核心模块封装信用查询，API暴露到微服务功能，另外评级权限管理则会从平台管理层面统一把控评级的权限分配。

1.2.2.2. 技术架构阐述 **平台技术架构规划重点放在整体、高层次技术体系架构规划，确定整体的技术框架布局、选型和发展方向，确保技术体系有足够的能力来支撑**平台信息化的整体IT发展战略。平台技术实现架构重点在关注如何满足应用系统的技术性，安全性要求、性能要求、可伸缩性要求，部署要求、灵活性要求，平台采用当前流行的关键技术，采取相关技术路线和关键技术可实现的快速横向扩展和弹性伸缩，能够支持资源和服务的灵活接入和动态加载；
确保系统的高并发和访问要求；
建设投运后有效支撑平台的持续运营。其技术架构如下图所示：
**平台技术架构由以下几部分组成：
1)云基础设施 考虑到系统的外围环境包括各种服务商和政府部门，网络层的设计支持互联网、移动互联网和专网的接入模式。

硬件层采用云计算IAAS的架构，将主机和存储作为资源池管理，应用虚拟化技术动态地创建虚拟主机环境支撑软件系统运行，使系统具有高度的可扩展性。

2)数据存储 信息资源是**平台建设的其中关键要素，它涵盖所有的结构化和非结构化数据。平台采用关系型数据库（MySQL）、NOSQL（HBase）技术和分布式存储（HDFS）技术实现各类数据的存储和访问。平台通过对用户在平台上的数据以及活动信息的记录、梳理和抽象，利用建模技术形成整个平台的数字化映像。

3)基础服务 平台为运行于其上的应用和服务提供底层的平台服务，通过这些服务，应用和服务可以完成复杂的逻辑。基础服务包括缓存、消息和任务调度等。平台基于Spark和Flume实现对用户访问的大数据处理计算。

4)服务运行引擎 在服务运行引擎的设计中，平台采用稳定高效的Linux作为操作系统，通过docker技术实现系统资源（CPU、内存、硬盘）的应用隔离，提高资源利用率，降低TCO（整体IT投入成本）；
在之上支持Java、PHP和Ruby等主流开发语言的应用运行环境，实现对各种类型应用的统一运行管理和动态弹性伸缩特性。

在应用框架方面，平台支持Spring、iBatis/Hibernate、ThinkPHP和Rails等框架的应用开发和运行。

应用的运行容器，平台支持Tomcat、Equinox（OSGi容器）和Apache/Nginx。

5)渠道平台 渠道管理平台采用了以下技术：
负载均衡：采用DNS、LVS和Nginx实现应用系统访问的负载均衡，提高系统的负载能力和可靠性。

缓存系统和CDN系统：通过对静态内容的缓存，提高系统的性能和处理能力，并可大幅节约系统网络带宽。

单点登录：采用CAS单点登录系统，实现平台内部系统间以及平台与外部系统的单点登录，提高用户体验。

6)终端 平台采用两种终端实现技术：基于浏览器的终端和基于本地客户端的终端。

基于浏览器的终端采用HTML5/CSS3技术，运用响应式布局设计，实现多种终端的自适应。

基于本地客户端的终端支持iOS/Android等智能设备。

7)安全 为保障平台的安全，平台在各层都采用了相应的安全技术：
云基础设施安全：采用防火墙、入侵检测和防病毒等技术保障基础设施安全。

数据安全：采用数字签名和加密技术保障数据存储和访问的安全与隐私保护。

应用安全：采用RBAC授权模型实现对用户权限的控制，保障应用访问安全。

客户端安全：采用U盾、证书和令牌等技术，提高用户认证的安全性。

1.2.2.3. 数据架构阐述 l 数据负载：
首先对平台采用集群部署的方式，通过4层和7层负载均衡设备自动分发用户请求。

静态页面数据缓存 对静态数据如html页面、图片、css、js等内容进行缓存，大幅度提升用户访问体验，缩减响应时间。

应用集群部署 根据性能、业务量和业务性质、规模、响应速度、安全等因素，合理分开和共用，通过横向扩展和弹性伸缩技术建立一个或多个实现负载均衡的应用服务器群组。

动态数据缓存 采用缓存技术，对用户动态请求的数据进行必要缓存。也可以大大降低流转到数据库层的请求数量，从而大幅提高响应时间。

数据库集群部署（分布式数据库）
采用分布式数据库的部署方式，建立集群，确保对流转到数据库层面上的请求的快速响应。

l 数据缓存 Memcached是高性能的分布式内存缓存服务器。一般的使用目的是，通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的速度、提高可扩展性。

Memcached是以Key/Value的形式单个对象缓存。

查询数据：
首先通过指定的Key查询(get)Memcache中间缓存层数据，如果存在，则直接获取出数据结果，查询过程完全不需要查询数据库。如果不存在，则查询数据库，并以key对应value的形式将查询结果存储在Memcache缓存数据中，然后将结果返回给查询语句。

图:数据查询流程图 更新数据：
首先更新数据库数据，然后删除相关的Memcache数据。

增加数据：
首先删除相关Memcache缓存数据，然后增加数据库数据。

删除数据：
删除数据库数据，并删除Memcache数据。

自主开发的内存数据缓存服务 独立进程方式的缓存服务 对于一些常用的动态数据通过开发程序服务缓存在内存中，提供给其他子系统调用，如下面的数据就可以通过这样方式进行缓存。

用户基本信息及状态的信息缓冲。

列表缓存，就像论坛里帖子的列表。

记录条数的缓存，比如一个论坛板块里有多少个帖子，这样才方便实现分页。

复杂一点的group，sum，count查询，比如积分的分类排名。

集成在WEB应用中的内存缓存。

在web应用中对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存(多个可以采用负载均衡)，减轻数据库的压力，比如：很多配置信息，操作员信息等等。

l 分布式存储 互联网应用的数据库架构发展历程，从单一DB server，到Master/salve，再到垂直分区（分库），然后再到水平分区（分表，sharding）。

Master/salve以及垂直分区相对比较容易，对应用的影响也不是很大，但是分表会引起一些棘手的问题，比如不能跨越多个分区join查询数据，如何平衡各个shards的负载等等，这个时候就需要一个通用的框架来屏蔽底层数据存储对应用逻辑的影响，使得底层数据的访问对应用透明化。

平台的分布式数据库设计思路是: Ø 合理分布各种数据，减少资源的竞争 Ø 从设计上较少大表关联和全表扫描 Ø 方便数据多种复制方式 1) 数据分布 Ø OLTP：存放1~2年的数据，历史数据划分专门的空间进行存放，不参与业务 Ø ODS：数据从OLTP中进行同步，并进行数据的轻度汇总和重组，主要用于查询统计 Ø OLAP：决策支持类的应用，数据高度汇总；

2) 数据库性能考虑因素 Ø 较少大表关联，消除全表扫描，减轻数据空间的交换机会 Ø 分散热表，较少锁的产生和集中 Ø 适量冗余，减少表关联 Ø 读写分离 Ø 垂直分区 Ø 水平分片 1.2.3. 平台业务模块设计 1.2.3.1. 平台业务服务、业务管理需求分析 A)服务形式 （1）多元化的服务模式 创新企业服务模式，根据服务的现状和特点，为企业提供包括线上线下的电子商务、企业内部管理的SAAS服务、专业服务的代理中介、服务预约等多种模式在内的各项服务。

（2）多维度融合，形成企业所需的完整环境 以企业实名制为基础，以信息服务消费为目标，通过数据融合、应用融合、服务融合的手段，集中企业所需的政务、公共和商业资源进行融合，按照企业生命周期中的各种实际需求提供服务，不是建设一个单一系统，而是形成区域内真实可信、线上线下相结合的完整市场经济环境，拓展在线交易范围、推动地区经济发展。

（3）以企业为视角 改变以往从服务提供者的视角为企业提供服务的现状，平台以服务对象为出发点，通过对服务流程进行梳理、整合等手段，根据用户的直接诉求设计合理的业务流程和使用场景，满足用户的直接需求，提升用户的办事效率。

（4）智能服务 转变服务模式，改变以往单向、广播、被动的对企服务，利用大数据技术，根据企业用户的个人属性（如部门、岗位）、企业属性（如企业类型、行业、经验范围等）、用户行为（如浏览、收藏、咨询等），智能挖掘用户潜在喜好或需求，预测用户下一步将要采取的行为，主动推送企业所需的各类社交活动、信息资讯和服务，让所有的外部资源根据企业自身特点和发展阶段精准供应，帮助用户快速定位需要的信息，提高企业的经营效率，促进企业发展。

（5）多渠道灵活接入 基于核心技术平台，提供PC、手机、移动终端、自助系统、热线等渠道的灵活接入，实现一个平台，一个身份，一个目标，多种访问渠道。前端依托移动互联网和智能终端在多媒体数据采集及服务获取的优势，提供最便捷的移动应用。后台的数据中心充分应用云计算，提供云服务，服务效果既高效又经济。

B)服务资源 （1）融合各类资讯信息，拓展信息获取渠道 面对目前信息分散、不全面的现状，大多中小企业都是通过互联网主动搜索与自己相关的资讯信息，这样不仅造成企业获取资讯不及时，也容易使企业错失很多与自己相关的政策扶持机会。面对这种情况我们提出了以下建议：
建立统一渠道整合各类资讯信息，分别按照产业、行业、地域将资讯信息合理分类，方便企业准确、及时地获取需要的资讯信息。

权威机构主动帮助企业传递相关信息，将不同资讯分别分发给相关所有企业；
同时能够根据企业的需求帮助企业寻找相关资讯。

根据企业自身的行业特性及兴趣偏好，主动帮助企业推荐可能需要的各类资讯。

（2）整合服务能力，面向企业直接诉求提供融合服务 从企业直接诉求分析，企业服务市场总体发育不充分，服务产品少、范围窄、层次低，与中小企业成长需求不相适应等问题。基于这种现状我们提出了以下建议：
建议由政府信息化部门牵头，面对中小企业的直接政务需求，变分散服务为协同服务；
并对复杂的服务事项减少审批环节、进行流程改造，最终使企业能够使用更便捷、透明、高效地获取并使用政务服务。

以市场化手段汇集各类企业在经营发展过程中需要的服务，统一满足企业经营发展所需的各种资源需求。从调研情况分析，目前中小企业主要面临融资及人才方面的困难，针对融资困难我们建议政府建立健全的担保准入制度、风险评估制度、信用评级制度、资金资助制度和行业运行规则等，切实为中小企业提供合法、便捷、高效的投融资服务。针对人才方面的困难，建议拓宽市场招聘渠道、合理整合招聘信息，帮助企业及时找到合适的人才；
同时加大人才培训力度，根据中小企业对培训的不同需求提供不同培训课程，满足企业人才使用、人才提升的需求。

（3）构建授信评级机制，形成安全有保障的商业环境 目前市场缺乏对服务质量的统一评价标准，建议设立服务提供商准入机制，同时引入政府/权威机构提供的授信评级信息，构建服务提供商的授信评级机制，形成安全有保障的商业环境，促进企业之间的经营和交易。

（4）打通信息沟通渠道，建立企业社交网络 目前企业的社交关系主要局限在企业自身的社交圈及协会范围内，拓展社交关系存在一定的困难，并且与外部各方之间主要通过传统方式沟通，沟通渠道有限。特提出以下建议: 基于实名制汇集企业在经营发展中涉及的各类干系人，通过挖掘干系人与企业之间的关系，帮助企业快速响应市场机遇、挖掘潜在客户，建立全新的以企业直接诉求为出发点的社交网络。

打通企业与政府、企业与协作单位、企业与上下游企业、企业与竞争对手的信息沟通渠道，实现企业与社交关系的交流、分享、互动及协作，通过各类关系的聚集促进产业协作、政企互动。

构建企业之间的自服务体系，形成产业聚集的规模效应，促进产业协作，从而提升产业集群的整体竞争力。

信息服务，当前企业想便捷、快速获取所需的资讯，但资讯分散在网络、电视、报纸、杂志等多渠道中，企业难以便捷、快速获取。

服装平台通过聚合整理的方式把资讯有效进行分类，方便企业获取。分成行业动态、政府政策、招商引资、行业趋势、园区企业等。通过加色提醒哪些是应该知道的信息，哪些是须要知道的信息，哪些要知道的信息；
我们可以根据用户的搜索习惯，点击过的服务，以及通过获取网页浏览的历史记录甄别出关键字，在用户使用我们平台之后查看资讯，根据关键字索引首先为用户展示与之相关的资讯信息。精准的为用户提供有用的资讯信息，减少用户获取有效信息成本，提供获取效率，更好的提供用户的使用体验。此外信息服务还提供企业方面的信息查询，方便企业之前更好了解企业概况，有利于对合作企业进行初步的甄选。也会为企业提供相关技术文档、市场分析文档、各类培训文档的下载。主页设置功能模块可设置宣传栏、扶持力度、产业定位、特色服务、园区空间等业务内容。设置好模块之后，后台即可对其进行信息维护，信息的内容包含标题、简介、文章的来源、发布的日期，具体的信息设置功能包含修改、增加、删除、置顶排序、加特别标示，发布的信息可以添加附件下载等。

政务服务，通过和智慧实现接口对接，打通两方的用户体系。用户在平台上办理政务，数据传输到政务平台的后台，后台处理反馈再同步到服装平台，实现双方数据同步和集成服务统一出入口的目标，减少企业跨平台享受才能服务的周折；
另外，平台根据最近服务被使用的频次，优先推荐展示使用频次多的服务，利用数据分析达到方便用户更好的获取服务入口的目的，让平台实现想用户所想；
进入服务，服务提供该服务的办事指南说明，在线办理和申请，也可以在线预约，现场直接办理；
线上办理完成可直接在线上查看办理进度，省去企业往来与各委办局的时间。

企业社交，企业推荐板块，通过推荐本地优秀的服装企业，让其他企业更好的熟悉和了解这些好企业，其他企业通过对了解明星企业的发展历程和里程碑等信息，鼓励企业望更好的方向发展。通过不同类目商脉的创建，为企业快速找到志同道合的商业伙伴，为企业之间的信息交换和互通扩展渠道；
通过人脉广场栏目，可以有效的提高平台人与人之间的互动。

需求发布，企业在个人管理空间发布的消息集中展示此页面，企业可以根据关键字搜索到自己需要的需求，同时企业在发布需求的时候时候也可以定向精准的推送企业需要推荐的人群，通过对平台人员或者企业信息的筛选过滤根据不同的人员和企业属性来精准定向的推送消息，保证消息推送的精准性，同时对接受者而言也减少是垃圾消息的可能性。

第三方电商整合服务，根据第三方已开发的接入接口，做到一键式发布，即在平台发布一次商品，将自动推送到各第三方电商平台发布，提高企业电商经营效率。

我的空间，集合个人的基本信息设置、服务密码修改、消息管理，企业的基本信息管理、企业的人员管理、企业的人员分组和架构调整、企业的认证管理等，我的服务包含交易的服务历史记录、交易管理和发布的服务状态，发布功能以及和第三方对接数据实现商品服务同步的功能，对接入平台的资源服务，分成分为信息类服务、业务类服务、交流类服务与管理类服务；
接入之前围绕平台的整个服务体系需要建立完善的标准，对第三方接入企业要进行一定的资质审查，在平台接入展示的第三方的服务应当作出标示。我的需求，可以对需求进行管理：新建需求、关闭需求等，企业通过搜索出需求，和发布需求者对接，实现提供服务，从而完成服务的闭环。我的社交，对好友的管理：删除好友、添加好友、好友分组等，前台页面根据名称即可搜索到对应的用户，添加申请，申请之后对方验证。

我的商脉，对商脉管理：退出商脉、加入商脉、申请加入自己创建的商脉、创建商脉等。我的文件，企业可以统一上传文件到企业自己的空间，可对文件进行分类展示，对查看进行权限管理，可以设置哪些人可以看，哪些人不可以看。

短信服务，用户在注册时候通过短信认证，后期定向营销服务可以对不同企业或人群发送营销短信。同时对后续的密码修改，密码找回都可以使用短信验证。对需求服务也可以接受提醒。

邮件服务，用户在注册时候可通过邮箱验证，后续需求服务也可以通过邮箱接受其它企业发布的需求提醒。密码修改或者找回也可通过邮箱验证进行操作。

检索服务，全平台，通过对服务、资讯、人员、企业和需求进行分类，根据用户不同使用场景下搜索出不同类目的结果。

统一认证服务，建立统一的认证标准，可以根据法人身份证、企业三证合一等信息进行统一的认证服务，打通双方平台的用户体系，同时实现双方数据的同步。

园区信息管理功能可添加园区信息与子园区信息，对园区的信息内容进行编辑修改，对园区信息页面的展示模块进行增加删除，同事建立园区和子园区信息关系。

产业信息管理功能可添加产业信息、已入驻企业信息、设置龙头企业信息与产业详情的查看。

特色服务管理功能可添加园区内的特色服务分类并关联服务资源。

空间管理功能模块可对园区地产空间进行宣传，提供包括空间名称、空间结算、所属园区、空间地址、建设进度、空间类型、物业信息、入驻企业信息、硬件配套、软件配套等信息。

政策管理功能提供本地园区特色的企业扶持政策的宣传公告，同事公告可以提供给企业下载，用户也可以收藏到自己的企业空间里，同事企业也可以通过第三方（QQ、微博等）工具分享，也可以直接打印。

线上企业管理功能。提供对入驻企业申请审核，审核系统可以接入法人库，通过企业申请的信息和法人库作对比，让系统自动实现审核，减少人力审核成本。与已入驻企业管理的业务功能，提供可添加合作服务商与合作服务商管理的业务功能。

活动管理功能。提供发布活动：活动包括活动的主题、内容、举办时间、地点、活动报名费用，用户可以查看活动详情、报名参加活动：添加报名需要填写的信息，对发布的活动进行编辑，修改等功能，同时也可以通过qq＼weibo等工具分享出给朋友，前台用户通过关键字搜索出活动。

如图（业务模块介绍）：
平台业务将分模块划分，分类开发/部署，做到业务与技术合理规划，尽可能满足多方资源汇聚，信息及时知晓，以及以企业为主体的政企沟通机制。

1.2.3.2. 平台业务模块设计方案 以企业经营过程中的电子商务直接诉求为核心，整合多方服务资源，提供融合的一站式服务。平台考虑未来的业务发展，在业务和功能上具备灵活方便的扩展性。结合企业经营过程，平台应提供首页、商品服务、服务需求、政务办事、企业社交五大类服务。

1.2.4. 平台基础服务设计 如图（基础服务介绍）：
提供目前互联网平台通用性基础服务，包含短信服务，邮件服务，检索服务，统一认证服务，订阅服务，信息采集服务，文件服务等。

尽可能的完善与优化平台的的线上功能。

提供目前互联网平台通用性基础服务，包含且不限于短信服务、邮件服务、检索服务、统一认证服务、订阅服务、信息采集服务、文件服务等。具体要求如下：
邮件服务，邮件服务是平台所提供的，能够实现邮件通讯功能的服务组件。

检索服务，能够提供对平台上的可公开信息能够采用关键词检索。

统一认证服务，使平台具有对平台用户的登录进行统一认证管理的能力。实现了用户只需要登录一次，即可访问所有相互信任的应用系统。

文件服务，提供平台的文件上传、下载服务组件。所有通过服务上传的文件都集中存储在文件服务器上。

1.2.5. 平台服务资源基础管理框架设计 如图（服务资源基础管理介绍）：
对接入到平台的企业服务资源，按照信息化角度进行管理，通过将企业服务分为信息类服务、业务类服务、交流类服务与管理类服务，形成四大类服务基础管理框架，通过管理框架，对接入到平台的服务资源进行融合性的管理与应用。

对接入到平台的企业服务资源，按照信息化角度进行管理，通过将企业服务分为信息类服务、业务类服务、交流类服务与管理类服务，形成四大类服务基础管理框架，通过管理框架，对接入到平台的服务资源进行融合性的管理与应用，具体要求如下：
l 信息类服务能力 汇聚各类资讯信息，解决企业获取资讯不及时，信息杂乱无章，无重点的问题，并通过多种技术对接模式实现用户资讯获取。能够提供各类用户应知、须知、要知的资讯信息，并通过融合化展现、个性化引导、智能化推荐，挖掘潜在信息、提升用户信息获取效率。

l 业务类服务能力 能够提供各类线上线下相结合的业务服务，满足不同发展阶段不同规模服装企业的需求，实现服务定制化，个性化应用。能够实现服务定制化，个性化应用，实现用户获取服务行为的大数据挖掘与智能分析，实现在线服务，实现兼容与扩展目前已存在的各类企业服务的平台能力。

l 交流类服务能力 构建以企业为主体，并引入政府部门、园区管理部门、行业协会等参与者的合作社交网络，解决企业之间，企业与相关机构之间信息不通畅，难对接的问题，支持WEB、即时通讯、APP等多种沟通模式与相关部门可对交流信息有效监管的能力。

l 管理类服务能力 提供企业内部管理的服务，帮助企业建立线上虚拟的办公场所与员工工作空间，解决企业内容信息化管理水平不一，自建投入较大的问题，实现企业云服务所需的通用型信息化管理服务。

1.2.6. 平台支撑体系设计 如图（支撑体系介绍）：
通过对数据接口的统一管理，更好的支撑平台的信息化作业；

提供运营管理系统，支撑平台做运营信息采集与梳理；

运行环境方面提供运维监控系统，保证7*24的平台稳定性。

1.2.6.1. 基于微服务架构的平台支撑系设计方案 微服务架构（Microservice Architect）是一种架构模式，它提倡将单块架构的应用划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。随着市场的快速发展，业务的不断扩大，单块架构应用面临着越来越多的挑战，其改造与重构势在必行。而微服务架构的诞生，是互联网高速发展，虚拟化技术应用以及持续交付、DevOps深入人心的综合产物。随着用户需求个性化、产品生命周期变短，微服务架构是未来软件架构朝着灵活性、扩展性、伸缩性以及高可用性发展的必然方向。同时，以Docker为代表的容器虚拟化技术的盛行，将大大降低微服务实施的成本，为微服务落地以及大规模使用提供了坚实的基础和保障。

我公司微服务平台基于服务架构设计，革新软件开发模式和管理模式，将复杂的业务拆分为细粒度的模块和服务，并利用容器技术相互隔离，使系统解耦，降低开发、管理、运维风险。传统的企业服务总线模式中，服务调用者与服务提供者通过企业服务总线相连接,无论在性能上还是成本消耗上，ESB都会导致瓶颈出现。我公司微服务平台采用“去中心化”支撑分布式应用，为了让整个业务系统的扩展没有瓶颈，只需按照业务发展需要进行扩展。

平台帮助企业快获得构建企业级互联网平台的能力，帮助政府构建适应快速变化的区域级互联网服务平台，减少研发成本、降低运维成本、解决性能问题、应对快速变化。

（1）架构实现方式 我公司微服务平台是基于Docker的组件服务化、管理可视化的私有云平台。主要包含四个部分：应用系统运行平台（PAAS）、微服务运行平台、API治理平台、监控报警。

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）。几乎没有性能开销，可以很容易地在机器和数据中心中运行。最重要的是，他们不依赖于任何语言、框架包括系统。

(微服务体系架构图) a)平台主要提供以下能力：
应用系统的可视化配置管理, 全面兼容Apache Tomcat等容器. （应用系统管理截图）
b)API接口的开发、开放、安全、统计等全生命周期管理。

（服务治理流程图）
（服务管理截图）
（API统计截图）
c)数据库、业务指标、应用系统性能、操作系统性能和组件健康状况的全方位监控。

（监控报警管理截图）
（操作系统性能截图）
（JVM性能监控截图）
（数据库监控截图）
（系统访问压力监控截图）
（2）架构主要工作机制：
a)安全机制 --API调用鉴权: 采用Hmac_sha1不对称公私钥（Appkey/Secretkey）加密算法，公钥用于网络传输，私钥用于生成消息摘要，保证用户数据网络传输安全。

--黑名单设置: 支持三种类型黑名单设置：
Appkey黑名单：可禁止非法访问的用户。

API黑名单：可禁止不安全、性能差的api对外提供服务。

IP黑名单：可禁止非法的IP访问。

--IP白名单设置 将授信的客户端IP地址加入白名单。客户端可以无无需鉴权，直接访问指定的接口服务。

b)服务运行管控机制 --并发控制 可设置每个调用者对API接口发起的最大并发量（默认20），保护下游服务不被高并发冲垮。保障服务能够7x24小时不间断提供服务。

--服务调用次数控制 API每天的最大访问量控制（默认9999），防止恶意数据抓取；
API每秒访问次数的控制，保护API提供者的老旧系统。

--服务隔离 使用docker容器化技术。实现不同API服务之间在内存、cpu、网络、磁盘空间等硬件设备资源隔离。

c)灾备以及预警机制 --资源灾备：平台资源（文件、数据库）定期自动备份。

--服务/应用灾备：API服务或者是应用软件多节点（物理机器或者虚拟机器）自动部署、共同对外提供服务。

--平台组件/服务监控预警 平台组件、服务、应用自动健康检查。一旦发现组件异常将自动通知管理人员。

第三方服务健康检查。实现第三方接入服务监控检查与预警。

(d)管理维护机制 --一体化运维运营系统 用户只需登录一次，即可访问运维系统或者运营管理系统。

--基础设施管理 主机管理：物理主机可视化管理、存活状态检测等。

路由管理：平台路由信息查看、自定义路由表等功能。

数据库管理：支持对外提供mongodb、mysql数据库服务。

软件版本管理：平台应用/服务版本所有版本展示。

容器管理：可以启/停容器、查看日志、容器硬件资源等信息。

--应用管理 管理平台应用、独立部署应用以及第三方应用。包括：应用启/停、扩容、版本管理、下线等功能。

--服务管理 管理代理服务、独立部署服务以及穿透服务。包括：服务启/停、扩容、版本管理、下线、API接口管理等功能。

--任务管理 管理平台任务已经独立部署任务。包括：任务启/停、版本管理、下线、Job启/停、Job执行预警、Job执行历史查看、Job管理历史查看等功能。

--通用巡检 定制化监控指标。可实现http、telnet、mysql、mongodb、influxdb 5中类型监控。可自定义采样规则、预警规则、监控频率、预警联系人等信息。

--网关管理 黑白名单管理、流量控制等。

--资源管理 平台用户管理、角色管理、菜单/URL等资源管理。

--高可用 平台核心组件、自建服务/应用均可集群部署，实现7X24小时，不间断提供服务。

--可扩展 平台功能组件互相解耦，可根据需求，选择部署。

1.2.6.2. 平台服务资源设计特性说明 （1）服务资源的原子性 微服务平台是一个原子化的服务，也就是说服务不能再划分成更小的服务了。世界上的一些事物都是有原子构成的。它为什么能构成所有的物体，正是由于它足够的基础。如果一个服务还能划分成几个小的服务，那我们就不能称之为一个微服务，它其实可以通过几个微服务组合成的一个系统。所以，平台上每一个API即是一个原子服务，我们可以把复杂的应用拆分一个个原子服务，且互相独立。

（2）服务资源独立部署性 既然是一个个独立的原子服务，那必然是一个完整的自治系统，不依赖外部的东西就能够提供服务。有自己一整套的完整的运行机制，有和外部通讯的标准化接口。在Docker出现之前，虽然我们谈论微服务架构，但是其实是很难实现的。微服务要运行，首先需要一套执行的环境。这套环境不能对外部有依赖性。同时，执行环境的粒度又必须足够的小，否则必然是对资源的巨大浪费。一个微服务可以跑在一台虚拟机上面，但是虚拟机粒度太大，即使最小的虚拟机，也至少也有1个核。同时，虚拟机有没有一套方便的管理机制，能够快速的让这些服务之间能够组合和重构。Docker出现以后，我们看到了微服务的一个非常完美的运行环境，实现原子服务的独立部署性。

（3）服务资源的可组合性 如果是最原子的服务，那一定是没有任何用处的，微服务之所以神奇，在于它能快速的组合和重构。彼此组合成一个系统。系统里面所有的实体在概念上是对等的，因此它的结构相对简单化。是一种松散耦合的结构，这样的系统，往往具有更强的可扩展性。

同时，我公司提供一整套微服务平台管理工具，通过对API的综合管理，快速实现各种API组合的可能性和便捷性。

（4）服务资源属性的可扩展性 平台通过以下设计方案，保证服务资源属性的可扩展性：
纵向分解：是一个非常自然而通用的方法，以至于常常被开发者所忽略。相比于把所有的功能集中到单一的应用中，我们将应用分解成了多个小模块，它们相互独立，互不影响。

分布式计算：一个垂直模块依旧可能成为一个相对大型的一体化应用，因此我们需要继续对垂直模块进行拆分。一种方法是将一个垂直模块分解成更多的垂直模块，另外一种方法是通过分布式计算将系统分解成多个模块，不同的是这些模块运行在他们自己的进程中，并且通过REST来传递信息。在这种情况下，应用不仅仅被垂直分解，同时还会被水平分解。这种架构中，请求到达应用后，对请求的处理会被分布于多个模块中，然后每一模块产生的结果汇总成一个响应，发送回请求者。这些模块并不会共享一个数据库架构，因为这样做会导致模块间的紧密耦合：数据结构的改变会使得一个模块不能够被独立的部署。

分片：当系统需要处理大量的数据，或者当一个分布式的应用被操作时，分片是很恰当的选择。比如说，分片非常适合向较大范围提供服务的应用 负载均衡：每当服务器承受不了巨大的负载压力时，负载均衡就会容重登场。通过对一个应用拷贝多次，同时利用负载均衡器将负载分解来缓解压力。在负载均衡中，不同实例的应用通常会分时使用同一个数据库，数据库因此成为了系统的瓶颈，但是我们可以通过制定良好的扩展策略来避免这个问题。

1.2.6.3. 应用设计原则 l 遵循SOA设计原则，系统之间采用服务的形式进行互联，相互松散耦合；

l 采用分层的体系架构，分离中间业务逻辑，便于复用；

l 业务逻辑实现组件化，基于框架进行开发；

l 客户端基于浏览器设计，客户端与服务端基于HTTP/HTTPS协议进行交互；

l 设计开发基于开放标准；

l 使用可靠的框架，提高开发效率以及稳定程度；

1.2.6.4. 数据库设计原则 l 统一的数据库设计标准和规范；

l 以业务作为设计信息模型的根本依据。以业务为中心，同时综合考虑其他方面的因素（包括：技术、管理等方面），对数据库进行设计；

1.2.6.5. 安全设计原则 l 统一的身份认证机制；

l 统一的访问控制；

l 统一数据属主标识；

l 统一的数据权限控制；

1.2.6.6. 接口设计原则 l 使用XML、Json等规范化定义传输的数据，实现平台接口标准化 l 支持标准的接口实现方式，利于集成；
充分考虑系统整体和局部的开放性。

1.2.6.7. 数据要求原则 数据安全包括数据库安全、数据存储安全、备份容灾等。为保证系统数据安全，将对数据进行本地备份，异地容灾。

1、数据库管理系统安全 （1）能够通过对主体（人、进程）识别和对客体（数据表、数据分片）标注，划分安全级别和范畴，实现由系统对主、客体之间的访问关系进行强制性控制；

（2）具有增强的口令使用方式限制，用户必须按规定的格式设置口令，才能进行注册；

（3）能够按照最小授权原则，对数据库管理员、软件开发人员、终端用户授予各自完成自身任务所需的最小权限；

（4）能够对于数据库安全有关的事件进行跟踪、记录、报警和处理，供有关人员进行分析；

2、数据存储安全：
（1）平台系统主机的操作系统、应用软件要有存储在可靠介质的全备份，软件以及计算机和网络设备的配置和设置的全部参数也必须进行备份；
与系统安装和恢复相关的软硬件、资料等必须放置在安全的地方；

（2）平台系统的重要数据必须定期进行备份，备份的数据必须存储在可靠的介质中并与系统分开存放；
而且要制定详尽的使用数据备份以进行故障恢复的预案，并进行预演；

（3）对于需要保密的存储数据，应采取加密措施保证其机密性。

3、数据备份：在生产区部署自动备份系统，定期将数据备份到备份库中，并进行备份有效性检查。考虑到系统稳定性及安全性，建议采用一台额外服务器作为备份服务器存储备份数据。

1.2.6.8. 网络要求原则 网络安全具体包括：网络安全区域划分，网络设备的管理，网络安全访问措施（防火墙，VPN等），网络安全扫描（入侵检测系统等），不同级别网络的访问控制方式，识别／认证机制等。

网络安全管理首先要根据网络的结构和业务应用的分布情况划分网络安全区域。划分安全区域后，在不同信任级别的安全区域之间就形成了网络边界。跨边界的攻击种类繁多、破坏力强。所以必须采用防火墙、防病毒、IDS等安全防护手段，加强对网络边界的管理。

为了保证生产区核心网络的数据安全，实现终端系统与核心网络的互联，满足开发办公环境的上网需求，可通过防火墙制定访问控制策略和在不同安全区域间设置网闸实现不同网络区域之间的受限访问。

入侵检测系统可对网络和系统进行实时安全保护，运行敏感数据于需要保护的网络上，对来自内部和外部的非法入侵行为做到及时响应、告警和日志记录。

分布式入侵检测构架可最大限度地、全天候地实施监控，提供企业级的安全检测手段。在事后分析的时候，可以清楚地界定责任人和责任事件，为网络管理人员提供强有力的保障。

1.2.6.9. 性能要求原则 l 系统服务器的CPU忙时利用率平均不超过70%，内存忙时利用率平均不超过70%；

l 系统应支持双机热备，在集群方式下为N+1备份，在非集群方式下为1+1备份；

l 从数据库备份到备份系统的时间：每天的备份时间不多于3小时，而且不影响对数据库的少量查询；

l 从备份系统拷贝到数据库里的时间：数据恢复时长不多于3小时；

l 平台支持负载均衡，并发数大于1000 l 系统平均无故障时间不小于26280小时（3年）；
系统平均无故障率不低于99%；

（一）、高性能 平台支持千级并发，可以通过水平扩展节点机器实现更高的并发能力。

接口服务：
并发量：1000并发 平均响应时间：平均响应时间500ms；

TPS：1633 事务成功率：99.99% 应用：
并发：2500并发 平均响应时间：0.271秒；

吞吐率：2500个应用的平均吞吐率是3986853Byte每秒 测试环境要求：
硬件环境：
Nginx 4核8G * 1 PAAS 4核8G * 2 微服务2核4G * 2 基准测试：
以下数据以min|max|avg形式反映，例如响应时间数据（0.25|0.4|0.34）
序号 场景 响应时间 1 访问WEB资源 0.002|0.217|0.003 2 访问API资源 0.006|0.170|0.008 应用数据 序号 并发量 平均响应时间（s）
吞吐率（Byte/s）
1 1000 0.059 4533829 2 1500 0.159 4157545 3 2500 0.271 3986853 序号 并发量 Nginx服务器 应用服务器 CPU(MAX) 内存 CPU(MAX) 内存 1 1000 43.80% 消耗不大 65.30% 消耗不大 2 1500 58.50% 消耗不大 80.30% 消耗不大 3 2500 60.60% 300M 74.20% 300M 服务数据 序号 并发量 平均响应时间（s）
TPS 事务成功率 1 1000 0.61 1635 接近100% 2 1500 1.49 1685 0.9947 3 2000 1.79 1684 0.99 4 2500 2.044 1617 0.9535 序号 并发量 Nginx服务器 应用服务器 CPU(MAX) 内存 CPU(MAX) 内存 1 1000 100.00% 84M 73.30% 消耗不大 2 1500 100.00% 150M 74.00% 80M 3 2000 100.00% 150M 74.80% 80M 4 2500 100.00% 150M 99.40% 500M 平台服务对接设计 1.2.6.10. 平台服务对接需求分析 如图（服务对接介绍）：
平台针对服务对接会制定一套标准规范与流程，方便第三方服务接入与接出。

其中服务对接统一走服务聚集平台管理，依附于聚集平台的是一系列标准文档与对接流程，在聚集平台的统一治理下保证数据的安全与平台服务的稳定性。

1.3. 系统主要功能设计、实施方案等 1.3.1. 平台技术路线说明 1.3.1.1. 总体路线 开发语言：JAVA 数据库：DB2、SQL Server、Oracle、Informix、Sybase等 服务器：所有主流Windows、Linux、UNIX平台；

客户端：支持AIX、HP-UX、Solaris、Windows、Linux中间件：支持Tomcat、Weblogic、Jetty、Jboss、Resin、Glassfish 存储：支持各种类型的磁盘阵列（SAN，iSCSI，NAS等）、磁带机和虚拟带库，支持冗余的备份设备；
备份策略支持每周全备份，每天做增量备份，保存周期可以自由设定，支持任意时间点恢复。

WEB服务器：支持负载均衡、页面缓存的Nginx、Apache、Tomcat 平台架构特点：高可用、高并发、高性能、可伸缩，以及动态化、模块化的大型分布式Java应用的技术 其他特性：支持最新Web Services标准，包括SOAP 1.1/1.2、WSDL 1.1、MTOM/XOP、WS-I Basic Profile 1.1等， 支持Web Services自有的安全性WS-Security和寻址功能WS-Addressing，可以实现Web Services 同步和异步不同形式的调用。

*灵活的消息路由方式，支持基于消息内容的处理和路由；
而且 还可以执行一系列方式的消息交互，包括了过滤、充实、监视、分发、关联、拆分（一对多）和合成（多对一）等。

*标准XML数据的格式转换，并且可以通过图形化映射组件、XSLT、客户化Java程序等多种方式实现转换功能。

*非标准XML数据的格式转换，实现XML消息格式和其他数据格式之间的映射，包括了JSON、C Record、JMS、TDS分隔符、平文本、行业专有数据格式等多种格式，同时也要支持自定义数据格式。

易于使用和开发：
软件提供便捷的安装和部署模式，提供友好的安装和部署界面。

提供中文的安装文档和使用手册。

系统安全：
提供多种安全机制，用户级别的认证、授权。

1.3.1.2. 关键技术分析 面向服务的架构(SOA) 比较各种不同的主流技术架构体系，目前国际上达成一致的观点是：SOA是企业IT架构全面整合的最佳方法。因此，我们对平台的建设，总体上来说，遵循标准、开放、灵活的SOA架构方法。

遵循先进的SOA方法 面向服务架构（Service-Oriented Architecture，SOA）是一种创新的企业IT 架构风格（即IT架构模式），是企业在进行IT规划和IT架构建设或重构过程中可遵循的先进的架构路线，是帮助企业如何构建能快速适应业务变革的IT体系的思想体系。

通过导入SOA构建企业IT 架构，真正实现IT与业务对等，IT为业务快速响应变化提供基础支撑能力，帮助企业真正建立起随需应变的架构。

SOA的基本思想内涵是：以业务为中心，在标准化、松耦合和弹性组装的原则之下，改进软件互操作和复用能力，构建出灵活和随需应变的IT架构，以帮助企业建立可灵活快速的响应不断变化的市场和需求的变革能力，获取更多的竞争优势。SOA本身就体现了一种整合的理念，对企业架构设计来说，创建一个业务灵活的架构意味着创建一个可以满足当前还未知的业务需求的IT架构。目前，SOA是国际、国内最为流行的让业务和IT对齐的企业架构方法。

基于SOA的IT架构具有以下特性：
架构不是为某个或某几个独立的系统设计的系统架构，它是企业级的IT整体基础架构，企业内部各个应用系统都是在该架构之中运行。

该架构是在公认的标准规范和标准的指导下进行规划和构建的，它为企业各种IT资产提供了层次分明、职能划分清晰，以及管理有序的运行环境。

平台通过构建基于SOA的IT架构，将为企业搭建起夯实并具有强大兼容能力的IT支撑平台，使企业中各种风格的IT应用不再是一座座“空中楼阁”，而是依附在统一的基础设施之上，在统一的治理环境中，各尽其能与各尽其职。

在该架构中，各种企业应用不再是孤立存在，而是通过架构提供的公共基础设施有机的连接在一起，共享公共的功能、统一信息规范、灵活的组合、协同流程化运转、按需提供服务。

同时通过有效的管理和控制手段，对整个架构中运行的各种IT应用，以及架构本身的支撑系统进行全面系统的管理，并对业务运行的过程进行监控和评价，及时的发现问题和改进。

平台架构设计完全按照SOA的指导思想进行 采用先进的J2EE平台 经过15年的发展，Java凭借其优良特性：安全、分布式、健壮、动态、多线程、平台独立等等，已成为当今世界企业计算最重要的应用平台技术体系。作为Java在企业级应用的支撑平台，J2EE对SOA的支持非常完善，为其提供了可扩展性、可靠性、可用性以及高性能，是实现SOA架构最佳技术途径。J2EE出台了一系列支持SOA的技术规范，如 JAXB（Java API for XML Binding），用于将XML文档定位到Java类；
JAXR（Java API for XML Registry）用来规范对UDDI注册表的操作；
XML-RPC（Java API for XML-based Remote Procedure Call）在Java EE中用来调用远程服务，这使得开发和部署可移植的Web服务变得十分容易，与此同时，也实现了跨技术平台（如：.NET）的服务间互操作。

本项目建设中所涉及到的所有中间件平台的产品，将优先采用J2EE实现。

1.3.1.3. 性能说明 基于1.2.6.9平台性能要求原则，平台完全满足以下要求：
1）响应时间要求：系统平均响应时间应能够满足系统并发压力负载性能需要。在中等负载下，各种操作的响应时间要求如下：基本的数据查询：3秒；
复杂的数据统计分析计算类功能：60秒。

2）并发数要求：系统须满足1万注册用户的在线并发数需要。

1.3.2. 我公司微服务架构技术支撑产品功能说明 系统概况 系统概况 在单页中显示系统概况，例如应用数，服务数，监控数，报警数，待办事项数，服务接入数，服务调用次数，热门服务等 基础设施 主机管理 所有服务器CPU、内存等资产的管理，系统将实时收集服务器上运行的应用和服务数，同时监控服务器状态并显示 路由管理 为独立部署的应用和服务提供路由（负载均衡）功能 应用仓库 罗列应用和服务的仓库（模板）信息 容器管理 罗列服务器上运行的应用和服务，管理员可以启停这些应用和服务的全部或部分实例，同时可以查看这些应用和服务的状态、环境变量和日志信息 数据库申请 开发者可以为自己的应用和服务申请数据库资源，目前支持Mysql和MongoDB 数据库审核 系统管理员审核数据库资源的申请 字典管理 系统配置项 应用管理 应用申请 应用开发者申请在平台上部署和发布应用 应用维护 - 版本管理，上传部署应用，可以同时创建、删除多个应用版本 - 版本发布，可以实现多个版本的快速切换 - 容器管理，可以查看应用的全部实例的状态、环境变量和日志信息，以及这些实例运行在哪台服务器上，也可以根据需要启停指定实例 - 启停应用，启动或停止应用的所有实例 - 修改，修改应用的基本信息 - 资源变更，加大或减少应用的内存和实例数 - 应用下线，如果应用不再使用，可以下线这些应用，下线后，外部再也不能访问 应用审核 管理员审核开发者的部署和发布申请 服务管理 服务申请 应用开发者申请在平台上部署和发布服务 服务维护 - 版本管理，上传部署应用，可以同时创建、删除多个服务版本 - 版本发布，可以实现多个版本的快速切换 - 容器管理，可以查看应用的全部实例的状态、环境变量和日志信息，以及这些实例运行在哪台服务器上，也可以根据需要启停指定实例 - 启停应用，启动或停止应用的所有实例 - API管理，登记、修改、删除可以开放的服务 - 修改，修改服务的基本信息 - 资源变更，加大或减少应用的内存和实例数 - 应用下线，如果服务不再使用，可以下线这些应用，下线后，调用者再也不能访问 服务审核 管理员审核开发者的部署和发布申请 AppKey申请 服务调用者申请服务调用的AppKey，AppKey是调用者的身份标识 调用申请 服务调用者申请对API的调用 调用审核 审核调用者对API的调用申请 API检索 检索平台中开发的API，以及查看API的详细信息 监控报警 概况 罗列平台中发现的问题，例如数据库当机或某服务不能访问 监控项目 管理监控项目，例如外部服务是否可用，平台服务或应用是否可用，数据库是否可用等，系统性能是否异常，业务指标是否达标，一旦发现问题，将会发送邮件通知相关联系人 联系人 管理系统出现问题时需要通知的联系人 数据源 管理需要被监控的数据库连接信息 网关管理 黑名单 保护系统不受攻击。

- IP黑名单，拒绝指定IP的服务访问 - AppKey黑名单，当怀疑AppKey已泄露时，拒绝指定AppKey的服务访问 - API黑名单，临时拒绝指定API的访问 任务管理 任务申请 应用开发者申请在平台上部署和发布定时任务 任务维护 - 版本管理，上传部署应用，可以同时创建、删除多个应用版本 - 版本发布，可以实现多个版本的快速切换 - 容器管理，可以查看应用的全部实例的状态、环境变量和日志信息，以及这些实例运行在哪台服务器上，也可以根据需要启停指定实例 - 启停应用，启动或停止应用的所有实例 - 修改，修改应用的基本信息 - 资源变更，加大或减少应用的内存 - 应用下线，如果应用不再使用，可以下线这些应用，下线后，外部再也不能访问 任务审核 管理员审核开发者的部署和发布申请 Job管理 - 新增job,自定义job执行时间、执行器 - 启/停job,快速启动或者停止job执行 - 快速执行,可手工快速执行job,不用等待系统调度 - job执行监控,可查看job执行耗时,历史执行情况 - 快速job开发,提供sdk功能,业务人员执行管理业务job自身开发 系统管理 用户管理 平台用户管理，可以控制用户的访问权限 角色管理 平台用户的角色管理，例如平台管理者，应用开发者，服务开发者，服务调用者等 资源管理 系统提供的资源 1.4. 项目开发设计与实施方案：投标人根据招标文件要求制定本项目的详细开发设计和实施方案 我公司制定的项目实施方案，完全满足招标文件中规定的系统设计要求、项目建设要求，并根据招标人所设定的各项任务编写项目实施方案。按照项目组织机构进行项目组织实施，依据项目实施方案中的项目管理方法论建设各种工作机制及相关工作制度，制定工作流程流转，并严格按照工作计划进行项目实施。项目实施包括进行平台基础环境的建设，即平台系统安装调试、软硬件集成服务工作。

我公司在**平台项目承诺已在项目管理方案中已明确陈述工程组织与管理结构，项目管理体制、项目管理组织结构图、项目管理方法、项目管理所采用的工具。

1.4.1. 人员配置 1.4.1.1. 项目组织结构 **平台工程建设涉及全市各级政府及下属部门和相关单位，需要工程主管单位和建设单位提供强有力的组织保障体系方可保证项目成功实施。领导与实施的组织机构图示如下: 图:项目组织结构图 项目建设的组织结构及主要职责包括: 1）信息化领导小组 信息化领导小组由相关领导组成，是**平台工程建设和运营的最高管理与监督机构，主要负责**平台工程建设相关事宜的决策工作。

2）项目管理办公室 在信息化领导小组的领导下，由建设方牵头组成，负责项目建设工程的日常管理和协调工作，组织实施工程的各项建设工作，汇报项目进展情况，执行领导小组的各项决策，协调共建部门和公共服务机构推进相关工程共建工作，代表领导小组制定和审批工程建设相关机制和规范，保障工程建设工作的顺利进行。

3）项目监理QA 为了保证本工程项目的质量，在项目的整个过程中，引入质量管理和项目监理的角色进行整个项目的监督和督促，保障项目按质按量完成。

4）专家团队 本工程项目将引入有经验的技术专家和业务专家组成咨询团队，根据项目建设的需要，不定期的配合项目建设，对项目建设过程中的专题进行业务和技术咨询、指导、内部评审。

5）总体业务组 对业务需求进行调研、梳理、分析，跟踪和维护业务需求的变化等。在该组设置了业务顾问、技术顾问，对业务模型、架构进行总体设计。

6）架构组 对本工程项目进行系统架构设计、总体设计、概要设计、详细设计、数据库设计等，引入相应的架构师、设计师等进行项目整体IT架构的设计。

7）开发组 负责工程项目系统的开发与系统功能测试工作，在该组中设置公共框架与组件开发、系统功能整合开发、系统集成与完善开发、新建系统开发、数据迁移开发、系统功能测试等岗位，并选派框架开发工程师、系统开发工程师、系统集成开发工程师、数据迁移开发工程师、系统功能测试工程师负责这些岗位的工作。

8）实施组 负责项目系统技术实现及系统集成相关工作，负责系统的总体测试及实施部署和上线支持上线培训等。

9）运营组 项目建设完毕后，平台由系统试运行期进入系统正式运行阶段，需要相应的运营单位来保障**平台的正常运行。

1.4.1.2. 人员管理方案 我公司为确保**平台项目按期、保质的完成交付，对于人员管理遵循如下原则: 1）在本项目的执行过程中，安排的于本项目经理将专职于本项目，核心技术人员也百分之百地投入到本项目中，并且整个项目团队的人员要在项目实施周期内保持稳定。

**平台项目已配置相应的项目管理、系统设计、开发、测试、集成、培训、质量保证等人员，明确在项目组织中岗位的职责，可以确保工程顺利实施。

2）参与此项目的核心技术人员均具有丰富的项目经验，有承担过相关软件开发和相关项目建设经验，有关与政府用户进行良好的沟通的能力，掌握丰富的电子政务业务的相关基础知识，完全具备相关产品集成、应用和开发的能力。并且参与此项目的技术人员均具有强烈的服务意识和高度的责任感。

方案中“施工进度总体计划”中已列出详细实施计划。在本次项目中间投入完成项目所需人力资源，具体人员姓名、经验、学历和在本项目中的职责分工，详见商务部分“6 质量保证和售后服务承诺”、“售后服务机构情况表”和“11、项目实施技术力量”，以及技术部分“4.4.3 项目实施人员”中相关内容。

3）项目组在将现场客户指定地点办公。

1.4.1.3. 项目实施人员 我公司将在本项目的执行过程中，对项目实施人员进行严格管理，项目经理专职于本项目，核心技术人员全身心百分之百地投入到本项目中，采用多种措施保障整个项目团队的人员在项目实施交付以及后期运营均相对稳定。

按照项目实施的要求，必须配置相应的项目管理、系统设计、开发、测试、集成、培训、质量保证等人员，在项目组织中应明确各岗位的职责，确保工程顺利实施。

参与此项目的核心技术人员具有承担过相关软件开发和相关项目建设经验，能够与政府用户进行良好的沟通，具备相关产品集成、应用和开发的能力。参与此项目的技术人员必须具有强烈的服务意识和高度的责任感。

1.4.2. 平台实施策略 我公司将按照招标书要求进行周密安排，制定的项目实施内容包括：项目启动、需求调研、方案设计、开发设计、安装配置、测试、初始化、上线试运行、初步验收、最终验收、质保等阶段。

1.4.2.1. 项目启动 我公司将按照组建项目组，双方项目组成员将充分进行沟通、交流。

对项目的实施策略、实施范围、各阶段的目标、项目管理方式及项目总体计划做出明确定义，编制并提交《智慧公共服务平台框架项目工作说明书》。

1.4.2.2. 需求调研 我公司将在项目调研分析的基础上分析整理调研资料，编制并提交《**平台调研与需求分析报告》。

1.4.2.3. 方案设计 我公司将在需求调研的基础上，进行系统的分析和设计，编制并提交《**平台概要设计方案》。

1.4.2.4. 平台安装部署 我公司将根据招标要求，提供符合招标方要求的产品。提交软件和硬件的部署清单。根据招标要求，按时完成平台的安装部署，并提供《**平台系统安装与部署手册》。

1.4.2.5. 第三方资源接入 我公司将根据招标要求，提供科学合理的服务资源接入方案。具体内容详见本册技术文件中1.2.6.11-1.2.6.13章节。

1.4.2.6. 项目整体测试 我公司将搭建测试环境，进行系统整体测试联调。

测试工作符合软件测试标准的要求。

进行系统压力测试，使用专业的压力测试软件，保证系统的稳定性和响应速度在招标的要求之内。

按照软件测试标准，完成各项测试，通过招标方指定人员检查，提交《**平台整体测试报告》。

测试软件由我公司免费提供。

1.4.2.7. 上线、初始化 我公司将协助初始数据收集整理，完成系统初始化工作。

将根据业务管理现状，完成用户培训，在数据初始化完成后，编制并提交《**平台上线试运行方案》。

1.4.2.8. 平台实施计划 总体工期要求：项目整体计划在90天内完成上线试运行。

需求调研阶段，合同签订后10天内完成对业务的全面分析，了解信息系统现状，在理解需求的基础上，确定系统实现的目标。

系统设计阶段，在对用户的需求、信息系统现状等进行深入的了解的基础上，在需求调研完成后10天内完成系统的概念设计、逻辑设计和物理设计。

软件开发阶段，系统设计完成后55天内完成代码的编制和测试工作。

系统测试阶段，软件开发完成后15天内完成软件的整体测试工作。

系统测试完成后，即进入第三方测试、试运行阶段，以及后续的系统验收工作。

1.4.2.9. 工作任务分解（WBS）
平台软件开发工程建设项目和建设内容将按照面向对象的软件工程模式进行，项目实施的阶段划分如下表所示（甲方：业主 / 乙方：投标方）：
序号 任务名称 任 务 承担者 产生的结果 1. 项目启动 成立领导小组和工作小组 甲方 乙方 产生决策机构 成立工程项目部 乙方 产生实施机构 建立沟通机制、明确对口关系 甲方 乙方 建立沟通渠道 制定《项目开发计划》草案 乙方 项目开发计划 制定《质量保证计划书》草案 乙方 质量保证计划书 2． 系统开发 采用原型验证方法，完成需求分析、系统建模、开发和测试。

2.1 需求调研与分析 制定调研计划，编制调查表和调研问题清单 甲方 乙方 《需求调研计划》
进行现场访谈，召开联合需求设计会议 编写《需求调研报告》
甲方 乙方 《需求调研报告》
进行需求分析编写《软件需求规格说明书》，由业主方审核确认 乙方 《需求分析报告》
《软件需求规格说明书》
2.2 系统设计（概要设计和详细设计）
系统概要设计 乙方 《系统概要设计报告》
数据库设计 乙方 《数据字典》
《数据库设计.pdm》
系统详细设计（用户界面、 人机交互和业务流程）
乙方 《系统测试计划》
《系统测试用例》
2.3 编码和单元测试 程序编码 单元测试 乙方 业务源代码 《单元测试报告》
《阶段性用户使用手册》
2.4 系统使用手册及扩展性 详细描述系统操作、技术、构架 乙方 《软件使用操作手册》
2.5 系统测试 测试人员培训 系统测试 乙方 《系统培训教材》
《系统的测试报告》
《用户使用手册》
3 上线、初步验收 3.1 实施环境 检查实施现场的环境 。

乙方 3.2 现场安装调试 实施小组进行现场系统安装调试工作、现场培训工作 乙方 《数据库安装手册》
《程序安装维护手册》
《软件配置参数表》
3.3 初步验收 验收测试 交付产品 甲方 乙方 《项目验收计划》
《项目初步验收报告》
4. 试运行 制定试运行计划 最终用户培训 试运行管理措施的制定 系统试运行，错误和缺陷的报告、记录和评估 试运行纠错和消缺 纠错和消缺的验证 试运行效果评估，评估报告的编制 甲方 乙方 《试运行记录》
《试运行报告》
5. 项目终验 建立项目验收小组 项目组内自检，提交应交付的产品清单 进行终验评审 进行正式验收 甲乙 双方 《项目终验计划》
《应交付的产品清单》
《系统验收报告》
6. 交付及合同期内的维护 提供技术服务 乙方 《技术支持和售后服务计划》
1.4.3. 项目文档提交 为了保证应用系统的设计和开发过程严格按照软件工程学的步骤进行，使系统的开发建立在文档化的基础上，按照软件开发规范，对开发过程和提交文档做以下说明，如下表所示：
项目阶段 工作产品 需求分析 《需求规格说明书》
概要设计 《概要设计说明书》
详细设计 《详细设计说明书》
《数据库详细设计》
编码实现 《单元测试报告》
集成测试 《集成测试方案》
《集成测试总结报告》
系统测试 《可运行的源程序清单》
《系统测试计划》
《系统测试总结报告》
系统验收（试运行），使用和维护 《用户操作手册》
《系统安装手册》
《问题修改报告》
《项目总结报告》
其他 《每周工作计划》
《每周工作总结》
《会议纪要》
1.4.4. 项目管理计划 1.4.5. 项目管理要素 项目管理就是在项目活动中运用各种知识、技术、工具和方法，来计划、组织、指导和控制项目进度、成本、质量、人力资源等各个方面，来满足或超越用户的需求和期望，并实现项目目标的过程。

根据多年的实践经验，我们把项目管理过程划分为项目定义、项目计划、项目实施与控制、项目收尾四个大阶段。

项目管理阶段与项目实施进度计划阶段的对应关系如下图所示：
在项目管理生命周期的过程中，有一系列的工作需要事先规划，具体实施这些工作还要用到众多的工具、技术及管理方法：
项目管理阶段 工作内容 技术与工具 交付成果 项目定义 明确项目目标与范围 明确项目制约因素 明确项目假设前提 制定实施策略 建立项目核心团队 调查表 组织行为原理 项目章程 组织结构图 团队成员联系列表 项目计划 制定进度计划 制定资源计划 制定预算计划 制定沟通计划 制定风险控制计划 制定进度控制流程 制定质量控制流程 制定变更控制流程 制定问题解决流程 制定商务状况 工作分解结构（WBS）
责任分配矩阵 甘特图、网络计划技术 关键路径法 戴明质量管理（PDCA）
进度计划 资源计划 沟通计划 质量管理计划 变更控制流程 问题解决流程 项目实施与控制 项目会议 信息沟通 团队管理 冲突管理 项目跟踪与度量 质量控制 进度控制 文档管理 变更控制 问题控制 费用控制 S曲线、挣值法 里程碑控制 赶工期法、费用预算法 质量保证与控制程序 项目周报 会议纪要 问题提交表及日志 变更申请表及日志 阶段评审报告 项目收尾 产品验收 技术交接 项目验收 流程改进 项目总结 项目实施总结 项目验收报告 虽然项目管理的要素很多，但由于项目的不定性及特殊性决定了有些要素需要重点关注。下面是我们认为在本项目中需要重点管理的几点要素：变更管理、文档管理、进度管理、沟通管理、问题管理、质量管理、风险管理。

项目计划管理 项目进度管理 在项目的实施过程中，还要对项目的实施情况进行跟踪，确保项目的实施符合计划的要求。跟踪的方法可分为正规跟踪和非正规跟踪，正规跟踪就是定期召开项目进展情况汇报会、提交项目进展报告等，从而使项目利益相关者了解项目的执行情况。根据进展报告，与会者讨论项目遇到的问题，分析并找出问题的原因，研究、确定应对方案和预防措施，为控制项目提供依据。非正规跟踪则是项目经理频繁地到项目现场，通过观察、与现场人员交谈、收集数据等方式了解情况，发现问题。

在项目管理过程中，非正规跟踪比正规跟踪更加有效，原因是：
（1）了解的情况真实、及时；

（2）缩小了项目经理与成员之间的距离，使之关系更融洽，问题更易解决；

（3）现场的执行人员更容易沟通；

（4）项目经理更能亲身体会现场的工作气氛，掌握团队的士气；

（5）更容易获取解决问题的答案。

项目任务进度的度量：首先把每项工作分解到工期在一周以内，每周末进行进度评估，我们采取工时提交原则，即提交工作任务的完成工时。项目进度跟踪的工具可以使用PROJECT。项目进度信息采集的方式：项目周报、项目例会、阶段性评审、挣值法。

（1）项目周报 就是项目组向干系人提交每周的工作汇报，包括存在问题。

（2）项目例会 就是项目组定期举行工作会议，分析项目状态，落实下一步工作，其中包括对现有的问题进行讨论并解决。

（3）阶段性评审 就是在项目的阶段最后，召开项目小组成员、项目指导委员会、外部项目质量保证等人员对项目的阶段工作进行评审，包括进度、交付物的质量、阶段里程碑、项目中的重大问题、项目风险、分析项目中好的方法等。  （4）挣值法 这种方法提供了三个数据来跟踪项目的执行情况：计划做什么、实际做什么、以及做完的工作花了多少费用。这种方法交计划需完成的工作同实际已完成的工作进行比较，确定项目在费用支出与时间进度方面是否符合原计划的要求，从而跟踪项目执行的好坏。

项目进度控制 项目计划只是根据预测而对未来做出的安排，由于在编制计划时事先难以预见的问题很多，在计划执行过程中往往会发生或大或小的偏差，这就要求项目经理及其他管理人员对计划做出调整，消除与计划不符的偏差，以使预定目标按时和在预算范围内得以实现。项目计划的控制就是要经常对每项工作进度进行监督，然后，对那些出现“偏差“的工作采取必要措施，以保证项目按照原定计划进度执行，使预定目标按时和在预算范围内实现。

按照不同管理层次对进度控制的要求分为三类：
（1）项目总进度控制：项目指导委员会对项目中各里程碑事件的进度控制。

（2）项目主进度控制：项目经理针对项目进度计划中的关键路径进行控制，保证总进度的如期完成。

（3）项目详细进度控制：主要是各作业部门对各具体作业进度计划的控制。这是进度控制的基础，只有详细进度得到较强的控制才能保证主进度的按计划进行，最终保证项目总进度，使项目目标得以顺利实现。

进度控制的依据主要有：项目进度表、项目进展报告、变更请求等。

项目进度的控制方法如下：
（1）把能力强的成员放在关键路径工作上，把新手放在时差大，不重要的工作上。

（2）赶工期，包括通过加班加点来缩短关键路径上单项任务的持续时间；
调整关键路径上活动之间的逻辑关系；
分包等。

（3）重新谈判，即与项目利益相关者讨论增加预算或者延长时间基线。

（4）缩小项目范围，以便减少费用、节省时间。

（5）投入更多的资源，看看可否增加人力、设备到工作中，这需要平衡费用与进度孰重孰轻。

（6）接受替补方案，看看能否制定一个更省钱、更现实的方案。

（7）寻求其他资源。

（8）接受部分交付物，看看能否先接受部分交付物，使项目能继续进行。

（9）提供奖金，看看能否提供奖金或其他激励措施，促使按时完成任务。

进度控制的结果包括：项目时间表更新、补救的行动、经验教训。

项目文档管理 对于IT项目来说，交付物主要是文档，所以文档的管理非常重要；
另外在项目实施过程中，由于项目实施的复杂性，多方人员参加以及时间跨度长等因素，所以有关需求、建议、问题、技术方案和会议等都必须文档化、标准化，以便查阅和引用。这些文档伴随着项目实施的各个阶段逐渐充实、完善；
与此同时，它们亦记载跟踪了整个实施的过程和成果。

文档编制工具 主要用到以下几种工具：MS WORD、MS EXCEL、MS VISIO、MS POWERPOINT、MS PROJECT。

MS WORD：主要用来编写描述性文档，例如项目章程、管理流程、需求报告、业务蓝图、项目状态报告、项目总结报告等。

MS EXCEL：主要用来编制检测表、各种项目计划、数据准备表、问题及变更日志等。

MS VISIO：主要用来绘制业务流程图 MS POWERPOINT：主要用来编制各种报告、培训性文档。

MS PROJECT：主要用来制订项目进度计划、资源计划、预算计划，并跟踪项目，生成各种汇报结果。

文档分类和命名 文档都可以按以下情况分类：
目录 01_PM_项目管理 1.1_项目定义 1.2_项目计划 1.3_项目会议 1.3.1_项目组周例会 1.3.2_项目阶段评估会议 1.3.3_项目组工作交流会 1.3.3.1_内部 1.3.3.2_外部 1.3.4_会议附件 1.4_项目问题 1.5_项目变更 1.6_项目报告 1.6.1_项目进度周报 1.6.2_项目总结报告 1.6.3_其他报告 1.7_项目评估 1.7.1_项目阶段评估 1.7.2_项目培训评估 1.7.3_项目管理评估 1.8_其他 02_PI_项目实施 2.1_第一阶段_项目启动 2.2_第二阶段_系统设计 2.3_第三阶段_编码测试 2.4_第四阶段_系统模拟 2.5_第五阶段_系统试运行 2.6_第七阶段_系统验收 2.7_第八阶段_系统维护 03_PT_项目培训 3.0_培训用标准模板 3.1_高层研讨 3.2_项目组培训 3.3_最终用户培训 3.4_系统管理培训 3.5_其他培训 99_OT_其他 文档命名规则为“二级类别_内容摘要_版本（或日期）”，例如：PI_需求规格说明书_V1.0.doc。

版本管理 软件有版本的区别，文档也一样。对于每一份文档的版本号管理，以下面的规则为准：
说明：版本号分总号与子号，例如V1.0，其中的1为总号，0为子号。创建文档时为V1.0版 ；

在未经用户方审阅前的内部审阅和修改，版本总号不变、子号递增，如：V1.1、V1.2；

经项目经理或用户方的审阅或修改后，则版本号升级，如：V2.0；

当文档最终确定后，统一提交项目经理或文档管理员存档，若需要修改须通过变更流程。

在每一份文档的开头，就会有类似这样一个表格说明版本控制的信息：
版本/修订版 修改确认日期 修改内容概述 修改人 批准人 备注             文档管理原则 所有的项目文档应严格按照文档控制标准进行：
从项目经理接手项目开始就应指定专人建立负责项目文档管理，归集项目所有电子和书面文档，并建立文档目录。

（1）文档起草、修改人应标注编写日期和主要修改内容。

（2）文档编制时，要严格按照项目规定的标准操作，例如页眉、页脚、标题、内容编排、字体字号等，是否按标准进行，作为项目质量检测的一部分。

（3）文档须通过双方相关责任人和项目经理的会签；
最终版本的文档须经过双方项目总监的签署并作为交付文档保存。

（4）文档的发放去向应准确记录收件人的姓名。对于电子文档，收件人应及时回复审阅意见。对于阶段性交付成果应同时保存具备签字的书面介质的文档原件。对于重要的邮件也要作为文档进行存档备份。

（5）对于失效版本的文档，要单独放置在一个目录中，并设置屏蔽权限防止误用。

（6）所有文档均适用于服务合同约定的保密条款。

项目结束后，整理归集所有项目文档，电子文档存放在专门的文件服务器上，或刻盘保存；
将书面文档按项目进度分类整理，扉页档案目录整理，装订成册，交项目档案管理人员保存。

项目问题管理 项目问题主要是指系统的应用问题，一般在需求分析、系统实现设计、软件开发、软件测试、系统模拟、系统运行过程中表现出来。对于这些问题，一定要由当事人及时提交问题报告表，并由项目经理对问题进行判决，指定解决负责人并预计目标时间。

问题的跟踪方法 建立一个问题日志用来跟踪问题的解决状态。

在每周的工作例会上，项目经理都需要回顾检查一下存在问题的解决情况，对没有及时解决的重要问题进行分析并讨论生成解决方法。

项目风险管理 风险管理是项目进行中非常重要的部分，目前随着项目规模的不断扩大，项目的风险也越来越大，一旦项目失败造成的经济损失也越来越显著。

一、风险管理流程 风险管理包括5个步骤。依据这5步，小组通过识别风险并采取相应的措施来减少风险。这个过程应该是整个项目管理的一部分。

识别风险：把风险提到表面使小组能够在风险影响项目前处理它们。

分析风险：把风险数据转化成信息使小组能够做出决策。

计划风险：设计计划用来支持决策制定和行动。

跟踪风险：监控风险的状态和任何减轻它们的行动。

控制风险：把风险管理放入到每日的项目管理中，这对于保证风险管理保持一个具有远见的活动至关重要。

　　二、主要存在风险 综合项目实践和国内外先进思想，软件应用系统存在如下重要风险，需要进行慎重评估，采取适当应对措施：
（1）来自业务的风险 业务流程的不规范性和不确定性。

（2）项目管理风险 项目管理能力、管理组织的稳定性以及连续性上的风险；

项目资金上的风险；

用户、开发商关系协调的风险。

（3）功能上的风险 系统功能目标范围蔓延，无法控制；

功能需求不明确导致的风险；

功能需求变更过多的风险；

系统无法达到其预计的功能的风险。

（4）技术上的风险 选择了不恰当的技术；

缺乏对所选择的技术的足够的认识和理解；

缺乏掌握关键技术的资深人员；

核心技术人员流失的风险；

系统运行维护上的风险。

（5）外部风险 网络运营商提供的服务质量的风险；

硬件管理人员提供服务质量的风险。

三、风险解决措施 （1）变更控制 变更控制是风险控制中的重要环节。变更控制的关键是在项目初期，制定并通过变更控制流程。成立变更控制委员会，双方的最高领导参加。

（2）关键点审查 在项目实施的以下关键点，我公司规定要进行审查：
（1）软件合同、《工作说明书》；

（2）项目准备结束（审查要素：主计划、质量保证计划、测试计划、设计和开发规范、设计和开发培训、工作和管理流程、角色划分和分工等）；

（3）需求分析结束（审查《需求分析规格说明书》）；

（4）设计完成（审查《总体设计规格说明书》、抽样《详细设计总体规格说明书》）；

（5）开发和单元测试完成（抽样审查源代码）；

（6）测试基本完成（审查各阶段测试报告）；

（7）试运行（审查上线准备工作）；

（8）售后维护（审查维护计划及维护小组工作）。

四、企业风险 不可回避，企业的存在，企业的效益，企业的发展，都在很大程度上影响着项目的进展和实施。对于这样一种问题我们想从如下一些基本点来认识：我公司的总目标是办成一个长久的、上规模的高技术公司。绝不会采取短期行为，绝不止步于小规模、低档次。目前我公司在国内电子政务行业属领先地位。我公司继承老一辈创业者的成功经验。那就是：一个能统一意识的领导班子；
能制定正确的战略并有效实施；
一支特别能战斗的队伍。有了这三点，我公司就能立于不败之地。有了整个我公司作为后盾，就不怕资金不到位。

五、人员风险 人员流动，特别是主要技术人员流动，将对项目实施和项目维护带来一定的影响。我公司从一开始就对此类问题给予极大的关注，采取必要措施尽量避免人员的流动。但是，由于本人的原因必须调离时，我公司将有一套科学组织调配制度确保项目不受影响或极少受到影响。

项目的组织机构是严密的。人员分工适当考虑一定的交叉，我公司人才密集，素质高，消除了项目个别人员流动的冲击。

对项目的管理是面向过程而不是面向个人。设置专门机构对项目的进度和质量监控。实施阶段评审、阶段验收，加强文档管理，建立健全项目的技术档案、维护档案。

六、技术风险 技术方案代表了一种水平，代表了一种责任，方案可行与否关乎实施，导致成败。为确保技术方案的准确可行，我们采取如下一些措施：
（1）在项目投标之前，与客户有关的业务人员和技术人员进行大量的应用调查和技术切磋。我们对此已作认真总结，并将其作为制定技术方案的依据之一；

（2）将在方案实施过程中加强阶段评审，使得方案的不准确问题，能发现在早期，及时调整，及时补救。

正式运行后发现应用软件系统有重大错误 可能性非常小，但一旦发生应尽快确诊，尽快纠正。一般履行下列过程：
（1）用户填写错误报告单；

（2）由我公司技术人员组成的项目服务组派人确认错误所在和错误性质；

（3）服务组组织原有人员突击修改；

（4）如果原有人员已转向其它项目时，无条件调回项目。直至错误全部纠正；

（5）项目服务组提供纠错后的相应文档资料。

正式运行后用户提出应用软件系统的重大需求变更 一般这种情况应慎重对待，按正式程序进行：
（1）由用户方常设运行机构提出正式“需求变更说明”文件；

（2）由项目服务组与用户方常设运行机构共同确认可行性和完成期限；

（3）由项目服务组根据需求规模和期限组织相应人员（尽量包含原有人员）完成需求分析、设计、编程、测试等各阶段的任务；

（4）由用户方与项目服务组联合组织验收；

（5）此项任务的质量监控直接由我公司QA小组负责。

（6）风险跟踪表，该跟踪表由项目管理部跟踪检查。

风险跟踪 项目编号 项目名称 **平台 制表日期 风险 标识 风 险描述 发现日期 可能性 影响力 风险值 对策 监控负责人 状态 对应问题标识 备注 项目成本管理 项目成本管理是在项目的具体实施过程中为了保证完成项目所花费的实际成本不超过其预算成本而展开的项目成本估算、项目预算编制和项目成本控制等方面的管理活动。

项目实施过程中会遇到很大的不确定性，这就需要在项目成本管理方面树立正确的思想，采取适当的方法，遵循一定的程序，严格按照项目管理要求做好估算、预算和成本控制工作。

资源管理 完成任何项目，首要的是获取项目资源，这是项目实施的物质基础。资源是有限的，多数的项目资源不能够无限获得，而且获得项目资源需要付出代价，因此，要在确保项目目标能够实现的前提下，做好资源计划，做到物尽其用，力求节约。

项目资源计划是通过分析和识别项目的资源需求（包括人员、数量、材料和资金等），确定项目各种活动需要的资源类型、数量、投入时间等，从而确定项目的成本估算。

资源管理计划的编制依据为：
工作细分结构 历史项目信息 范围说明 项目资源库 项目组织策略 成本控制技术 项目成本控制是在变化的条件下实现项目预算成本，按照事先拟定的计划和标准，通过采取各种方法，使项目成本控制在预算范围内的过程。成本控制的主要内容主要包括：
识别可能引起成本基准计划发生变动的因素，并对这些因施加影响，以保证该变化朝着有利于项目的方向发展；

以工作包为单位，监督成本的实际实施情况，做好实际成本的分析评估工作，对发生偏差的工作包实施管理，采取针对性的纠正措施，必要时也可以调整基准计划，并保证所有变化都记录到成本基准计划中；

成本控制应与项目范围变更、进度计划变更、质量控制等结合，防止因单纯控制成本引起项目范围、进度、质量方面的问题。

成本控制的依据为：
各项工作任务或者活动的成本预算 基准成本计划 成本绩效报告 成本控制的关键是经常及时分析费用绩效，以便在情况变坏之前采取纠正措施加以解决，从而减小对项目的冲击。通常可以用下面六个基本指标来分析成本绩效：
项目计划作业的预算成本，是按照预算价格和预算工作量分配给每项作业活动的预算成本；

累计预算成本，将每一个工作包的总预算成本分摊到项目工期的各个区间，这样计算出截止到某期预算成本汇总的合计数，成为该时点的累计预算成本；

累计实际成本，已完工部分的实际成本，截止到某一时点的每期发生的实际成本额的合计数；

累计盈余量，已完工部分的预算成本，由每个工作包的总预算成本乘以该工作包的完工比例得到；

成本绩效指数，这是衡量成本效率的指标，是累计盈余量同累计实际成本的比值，反映的是多少实际成本才完成一单位预算成本的工作量；

成本差异，累计盈余量同累计实际成本之间的差异 项目管理工具 包括了项目管理使用的项目管理工具和软件过程自动化工具，主要包括：Project、版本管理软件SVN、测试跟踪、管理软件Redmine等，如下表所示：
项目名称 工具名称 版本 备注 项目管理 MSProject 2013 版本管理 SVN 1.8 系统建模 powerDesigner 15 系统开发 Eclipse/IDEA 10.0 单元测试 Junit 3.8.1 功能测试 WinRunner 7.6 性能测试 Loadrunner 7.5 测试管理 redmine -- 含缺陷和需求管理 缺陷统计析 MS Excel 2013 制表工具 其他 MS office 2013 1.4.6. 沟通计划 项目经理分析项目干系人的信息需求，制订项目沟通计划，沟通计划包括书面沟通计划和会议沟通计划两部分。

主要沟通类型 一、本项目的主要沟通方式 项目组每周必须召开内部工作例会，项目经理负责组织项目例会和汇总工作情况形成项目工作周报；

项目组每周与用户方召开工作例会，并汇总形成周例会会议纪要；

项目经理参加工程办定期召开的PMO例会；

项目组根据项目进度计划召开阶段工作总结会，项目经理负责组织总结会并汇总形成阶段工作总结报告；

项目组根据需要召开专题讨论会，项目经理负责组织专题会并形成专题会会议纪要；

项目组与其他组之间的沟通需求，由甲方项目经理负责协调。

二、本项目的会议类型 会议类型 会议目的 会议参加人员 会议频率 工程指导会议 对工程的整体指导。听取工程汇报，审核工程的进度下达指导委员会指示，解决工程中的问题和冲突，给出具体意见 主管领导，工程办人员，相关人员 每月 工程办会议 听取项目的详细汇报，审核项目的进度，解决项目中的问题和冲突，给出具体意见 工程办，重点项目乙方人员 两周一次 项目协调专题会议 解决相关项目之间的问题和冲突 工程办相关负责人，项目相关人员 根据需要 项目例会 项目内问题解决，进度跟踪，任务分配 项目组甲乙方骨干人员 每周一次 阶段总结会 对本阶段工作进行总结 项目组全体 阶段结束 项目会议类型表 沟通工具及模板 在本项目中将采用电子邮件、QQ、微信、电话等沟通工具。同时我们将制定一系列的标准化沟通模板，包括但不限于：
《沟通计划模板》；

《组间沟通申请模板》；

《工作周报模板》；

《会议纪要模板》。

1.4.7. 业务调整或新需求产生时对软件开发商的依赖度说明 在项目实施过程中，变更是不可避免的。对于本项目来说，可能发生变更的环节比较多，变更管理主要目的是对项目需求、进度发生重大变更的有序控制。

变更类型 在项目实施过程中，变更类型及产生变更的原因有很多，常见的变更类型及原因参见下表：
序号 常见变更类型 产生变更的原因 1 需求变更 用户业务或技术需求基线发生变化时。

2 设计变更 需求变更引发的设计变更；

采用新的技术、工具引发的设计变更。

3 进度变更 未能按照工作计划完成工作任务，或者产出物质量满足不了用户需求的进度变更；

存在优先级更高的工作任务或者原有工作任务优先级调整，需要对原有工作计划进行调整；

其他变更引发的进度变更。

常见变更类型与原因表 变更管理流程：
标准变更流程 （标准变更流程图）
流程说明：
本流程是一个通用的变更流程。

项目组设专门的变更接口人，负责接收项目变更。

根据变更类型的不同，由SCCB中不同的职能组负责组织评审 需求变更流程 本项目建议采用的需求变更流程如下图所示：
（需求变更流程图）
流程说明：
需求变更申请人按要求填写《变更申请表》，并将其提交给配置组，配置组在《变更状态跟踪表》中做相应记录；

项目组进行内部评审，如评审通过，则进一步进行影响分析评估。如果评审不通过，则将《变更申请表》返回给配置组，配置组在《变更状态跟踪表》中做相应记录，并将《变更申请表》返回给需求变更申请人，如果变更申请人也接受，则取消变更；
如果变更申请人坚持变更，则将《变更申请表》提交给SCCB，由SCCB中的需求组组织进行评审，决定变更与否；

项目组内部组织评审会，对成本、进度、设计等影响因素进行评估，然后将《变更申请表》（含成本评估）提交给SCCB进行批准；

配置组将《变更申请表》（含成本评估）提交给SCCB，由SCCB组的业务组组织相关人员对其进行评审；

如评审通过，由项目组填写《变更通知单》，连同SCCB签发的《变更申请表》返回给配置组，配置组在《变更状态跟踪表》中做相应记录后，再将《变更通知单》递交给变更执行人，执行变更；
如评审未通过，则将《变更申请表》返回给配置组，配置组在《变更状态控制表》中做相应记录后，再将《变更申请表》返回给需求变更申请人，取消变更。

需求变更模板示例 需求变更申请表模板如下图所示：
（需求变更申请表模板）
设计变更流程：
设计变更流程如下图所示：
（设计变更流程图）
流程说明：
项目组内的技术评审由技术经理负责组织；

提交SCCB的设计变更由SCCB的架构组负责组织评审。

1.4.8. 软件部署工作量、可维护性说明 软件部署工作量包括服务器环境搭建、软件环境搭建、程序部署调试，以及试运行。

维护体系包含的内容较多，主要目的是通过主动的服务来保证客户系统的稳定安全。其中必要的环节有客户系统评估、制定维护方案、优化升级系统等。

图 维护体系流程图 维护体系的工具包括：
1、维护服务技术手册 是技术服务中心十几年集成维护经验的积累，就常见的系统问题和预防等提出了合理的建议和模板。使维护服务工作减少了走弯路和犯相同错误的几率。

2、专家审核评估制度 是为保障重大系统维护改进方案真实可行而制定的。技术服务中心的专家组将对客户系统的改造、升级、优化等实施方案进行严格把关，以确保方案的严谨和安全执行。

3、客户服务知识库制度 是将在对客户服务的过程中，所有客户的服务记录和维护信息收集归档，建立客户的服务知识库，便于客户问题的分析。

4、维护体系的文档 维护体系向用户提交的文档很多，如定期的维护巡检报告、定期的服务汇总总结，在建议客户升级优化改造的时候，还会向用户提交实施报告和建议书。

1.5. 技术支持、人员培训、运行维护和售后服务：投标人需书面作出针对本项目的质量保证，技术开发维护工程师培训方案，对项目投入人员、管理方式的承诺，对培训与服务的承诺 1.5.1. 售后服务承诺 1.5.1.1. 服务体系 本系统建设项目的技术支持小组依托于我公司成熟完善的服务体系，针对本项目建设中的支持与服务需求以及信息化平台应用软件开发项目的特性，专门制定了一套技术支持及服务方案，力求真正做到“以客户为本，提供优质服务，快速积极响应”。

服务体系构成如下：
本系统技术服务小组的售后服务体系由响应体系、维护体系和质量监督体系构成，如下图所示。

1.5.1.2. 售后服务范围与承诺 1.5.1.2.1. 服务内容与承诺 售后服务说明 我公司保障整个平台的正常、安全运行。项目交付使用后12个月的试运营期间，如有细节调整，可免费进行开发实施。

1.1投标人提供的维护保障服务至少包括以下服务项目：
（1）软件故障修复服务(含远程技术支持、2小时现场技术支持) （2）电话技术支持服务 （3）版本管理和软件补丁服务 （4）培训服务 （5）应急方案设计与预演服务 售后服务具体要求 （1）交付使用后试运营12个月，试运营期结束并验收合格后，提供三年运行维护服务 （2）服务要求 投标人应根据招标人申告的故障级别，采取必要的服务措施(包括调整)，尽快修复故障，恢复系统正常运行。投标人可通过电话指导、远程登陆或现场服务等方式进行故障修复，并保证满足双方约定的服务等级中相应故障级别的处理时限。

根据故障的严重程度和影响程度的不同，故障级别由低到高分为三级故障、二级故障和一级故障。当故障没有在规定时限内恢复或解决时，故障级别将自动升级(如双方协商一致认为没有必要，也可不做升级处理)。

一级故障(重大故障)：指软件平台在运行中出现系统瘫痪或服务中断，导致软件平台的基本功能不能实现或全面退化的故障；
其他造成业务中断1个小时以上或导致关键业务数据丢失的故障。

二级故障(主要故障)：指软件平台在运行中出现的直接影响业务、并导致系统性能或业务部分退化的故障；
软件平台在运行中出现的故障具有潜在的系统瘫痪或服务中断的危险，并可能导致软件平台的基本功能不能实现或全面退化。

三级故障(次要故障)：指软件平台在运行中出现的，影响系统功能和性能，但关键业务不受影响的故障。

根据软件平台承载的业务以及重要性不同，投标人应提供不同服务等级的服务，至少应提供以下三个级别的服务，从服务水平由高到低分为A、B、C三级。

A、B、C等级服务的基本区别见下表。

服务等级 服务描述 A级 （7x24x4h）
7x24小时接受申告，4小时现场响应 B级 （5x9x4wh）
5x9小时（工作日）接受申告，4小时现场响应 C级 （5x9Next Day）
5x9小时接受申告，第二天现场响应 1.5.1.2.2. 响应时间与承诺 我们承诺向招标人提供良好的技术支持，设立专门队伍从事此项工作，并提供A级全天候（7*24小时）、B级5*9小时，C级5*9小时的热线技术支持服务，必须对任何地点用户所反映的问题都得到及时响应，A级问题4个小时之内得到现场响应、B级问题接受申告后4小时现场响应，C级问题5x9小时接受申告，第二天现场响应。

1.5.1.2.3. 软件变更及升级与承诺 我们理解招标人业务的复杂性和多样性的特征，因此我们承诺，在项目的质保期内，针对应用软件，在原需求设计整体不变的情况下提出修改意见，我们负责免费更新完善。同时免费提供自主开发的应用系统软件系统的版本升级服务。

1.5.1.2.4. 服务方式与承诺 我公司，对本项目至少提供热线电话、网站公告、电子邮箱、定期巡检、系统维护组维护支持、远程技术支持和维护专员现场支持等技术支持服务方式，并且在项目试运行和系统验收后一年内，提供免费现场售后技术支持服务。免费质保期后，提供有偿终身维护，有偿服务费用按当地标准由双方协商约定。

服务时间：7*24小时全方位服务支持，提供在线咨询、远程服务、邮件服务、热线电话、问题咨询、BBS、定期巡检、系统维护组维护支持等服务。

400服务电话：提供免费400电话服务，提供咨询电话支持服务，解答用户在系统使用中遇到的问题，及时提出解决问题的建议和操作方法。

系统版本升级服务：在免费维护期间，免费提供自主开发的应用系统软件系统的版本升级服务。

网站公告：在技术支持服务期内，通过指定的网站，对系统重大更新信息进行发布，便于用户及时掌握更新信息，发布的信息包括常见问题解决方法（FAQ）以及系统操作手册等辅助文档的最新版本下载。

电子邮箱：提供专门的技术服务电子邮箱，对用户反馈的技术问题进行收集。

维护专员：在技术服务期内，我公司将为项目提供工程师作为维护专员，负责第一时间解决现场问题。维护专员的主要职责包括现场指导、搜集用户反馈意见、改正软件缺陷。维护专员的调整由招标人和我公司双方共同协商确定。

远程技术支持：在用户许可的情况下，由专业的软件维护工程师采用电话、即时通讯、远程终端、互联网远程登录等手段对用户的系统进行调试、故障诊断和故障排除，确保第一时间内恢复系统运行。该远程技术支持将严格按照安全保密的要求，只在用户授权的情况下方可操作，并记录维护日志。

定期巡检：对于系统提供至少每月一次的定期巡检，巡检周期可根据用户要求调整 1.5.1.3. 售后服务 根据项目的特点和业主方提出的关于服务的要求，我公司做出如下郑重承诺：
1.5.1.4. 售后服务质量保证 涉及的质量记录有：
《客户档案》:记录客户详细信息。

《用户售后服务记录》：技术人员在顾客现场进行的售后服务活动记录于售后服务记录中，并由用户签字确认。以保证对用户的服务及时、完善、高质量。

回访用户制：每年两次走访用户，了解用户系统及设备运行情况。

用户直接投诉制：为了保证用户投诉的有效解决，设立用户投诉电话，由品质保证部负责登记顾客投诉、监督责任部门提出纠正措施并对纠正措施的有效性进行验证。公司品质保证部门负责定期进行顾客满意度调查，及时把顾客意见反馈给总经理和相关人员。

提供专业的运维服务 1）电话支持服务 拥有400 免费热线电话服务系统，为客户提供 7*24 小时不间断的电话技术支持服务。（固话或手机）400-820-5793 2）巡检服务 注重预防性维护，定期对客户的IT系统实施系统健康检查，并提交相应的系统健康检查报告，巡检报告将评估该IT系统的可用性、安全性、稳定性和性能现状，并就发现的问题或隐患提出解决方案。巡检结束后的三个工作日内向客户提交巡检报告，也将在ITSM系统中体现。

3）硬件保修维护服务 在承诺的保修时间内，对客户投保的设备提供风险式保修服务，包括设备预防性检查维护、硬件故障诊断、备件更换、以及相关的技术咨询服务，并针对保修的项目制定维护服务的实施方案和制度，以保证客户的硬件系统安全、可靠的运行。

4）系统加固服务 对客户的IT系统进行漏洞扫描、补丁升级、微码升级、系统性能调优等措施，确保客户IT系统健康运转。

5）紧急响应服务 对于客户IT系统的突发性故障或突发性性能下降等问题应客户请求，派遣工程师第一时间赶往客户现场，查找问题，排除故障。紧急响应支持7X24服务。

6)配备专职的项目经理 我公司将对每一个服务项目配备壹名项目经理。项目经理是我公司在服务全过程所有工作的负责人和协调人，是项目动态管理的体现者。项目经理既对项目的目标负责，又对我公司的效率性目标负责。

7)定期项目例会 定期与客户举行服务项目例会，例会内容可有：上次例会问题解决如何；
目前项目的进展情况向客户汇报（包括计划情况、实际完成情况、差异情况等）、对客户的疑问予以解答；
询问客户还存在什么问题；
客户的需求是否有变更；
对分歧或问题的讨论，得出解决的对策，并明确相应责任人；
明确下一阶段需要客户做哪些配合等等。

8)服务报告 定期（一般为季度）将一段时期内所有Case的相关信息形成报表，并生成PDF格式文档，方便用户查阅。服务报告内容包括报修的问题、解决过程、技术人员Report、设备维护日志等信息。使客户对服务过程有直观的了解。

1.5.1.5. 应急处理方案 除此之外，我们还将提供以下的服务：
1、故障迅速排除类服务及措施 通过一系列的预防性服务和措施，可以大大提升系统的稳定性、可靠性，降低系统故障发生的概率，但是在应对突发故障方面仍然不可忽视，为此，我们也采取一些针对性的措施和服务，以确保故障的迅速排除。

快速现场服务 设备故障如果无法通过电话或者远程诊断解决，我们将派遣维护专职工程师在约定时间内到现场为客户解决问题。

专家支持 在对本项目的系统维护过程中，我们将组织技术中心最核心的技术力量对其进行支持，以此提高客户问题的解决速度。

2、保证系统稳定、可靠、数据安全的服务及措施 本项目的特点决定了系统的稳定、可靠及数据安全极其重要，从专业运维的角度出发，防患于未然显得更为重要，基于这样的考虑，我们的日常服务将更多的精力和重点放在如何保证系统的稳定，可靠及数据的安全方面。为此，我们将有以下针对性的服务。

安全保密工作 我公司承诺将设立专门的保密管理员，遵循《中华人民共和国保密法》及有关法规，负责制定具体项目安全保密计划，协助项目经理进行安全保密管理，协同项目经理与项目协调领导小组和安全保密小组进行安全保密方面的沟通协调，在项目的实施过程中和售后服务过程中严守保密计划。

定期预防性巡检 除加强日常检测外，针对系统业务特点对系统进行定期巡检非常必要，我们将根据本项目的业务特点确定巡检内容和时间。

完善维护制度 依据运维服务的经验，来自人为的误操作对系统稳定可靠的运行是一个较大的威胁。我们将凭借多年来丰富的网络系统维护经验帮助本项目对已有的日常维护制度进行完善和充实。

培训客户维护队伍 除了协助制定系统的日常维护制度外，我们还将为本项目的网络维护人员做维护的培训。培训的形式包括巡检时的“传、帮、带”和不定期的技术交流、专项技术培训等。具体的内容以及时间与客户协商确定。

系统改进建议 随着系统应用的不断完善，原有的系统性能可能会有与应用不太匹配的问题，甚至是性能瓶颈，从而对整个应用系统造成影响。在IT系统的运维过程中，持续改进是永远的话题，我们会基于检测和巡检，定期向本项目领导提交系统升级、扩容的建议报告。

3、其他辅助类服务及措施 定期技术交流 为了更好的了解客户的技术需求，同时也是我们与客户互相学习、共同提高的机会，我们将不定期的进行技术交流。形式可以是座谈，也可以是讲座和培训。

知识库的建立 为加强对本项目维护服务的监控，及时总结支持服务的经验教训，对每次技术或故障的申告我们都将详细记录，归档到本项目的故障数据库之中，其中包括每次对于解决故障的方法、措施、进展以及结果等，从而形成本项目维护服务的知识库。

电话回访 为了及时的获知客户需求，我们将主动不定期的通过电话对本项目使用单位及管理单位进行电话回访，从而加强与客户的交流。

通知最新动态 为了让客户可以尽快掌握我们我公司售后服务的最新动态，了解新一轮的服务、培训等优惠政策，我们将会通过电话、邮件等方式告知客户。

满意度调查 为了提高我们的服务质量，我们将定时向客户征询满意度调查，使我们可以向客户提供更好的服务。

1.5.2. 质量保障措施 1.5.2.1. 质量管理 1.5.2.1.1. 制度规范保障 为加强项目组织成员之间的沟通，实现思想、技术共享，保证本项目的顺利开发，项目组必须制定严格的管理制度以保障项目的顺利实施。

项目实施管理制度 本项目建设采用面向目标、规范的管理模式，强调目标的严肃性。完善的项目工作制度是项目实施的基本保证，为确保此次系统建设的顺利实施，我们在项目管理过程中遵循以下制度：
决策制度 决策制度是对合同中没有涉及、或者有冲突的职责和权利进行决策的制度。决策内容包括各个方面，但是制定以下几个原则：
项目经理首先决策原则 对于不大的决定，一般由项目经理加以决策，然后提交给项目领导小组和项目管理办公室，一般在一周之内，如果没有任何一方提出异议，则该决定生效，此异议应以书面方式表达。

最高权力机构准则 项目管理办公室可以推翻项目经理和任何项目机构的决策。

项目经理可以推翻各个执行小组成员的决策。

发起决策原则 一切决策应有书面文件，并且在项目管理办公室双方代表处备案。

自主发起决策原则 一切需决策的问题，如果无章程可循，首先遇到此问题的项目成员，需拿出自己的建议，并且提交项目经理，如果项目经理在获得建议后三个工作日内没有口头或书面异议，则该决定生效 沟通汇报制度 晨会 各项目小组每天上班后用十分钟左右的时间召开小组会议，成员讲述自己当天工作以及需要其他人配合的工作，会后形成简单会议记录发给项目小组成员，达到提醒员工及时完成本职工作并配合好其他人的工作任务。

周例会 由项目经理组织项目组成员参加周例会。总结上周工作，形成项目周报。项目周报的内容包括：上周工作进展报告、本周工作计划、本周任务分派报告。

与会人员分别介绍上周计划的工作内容，实际完成的工作内容。如果出现进度延迟，项目小组长和具体开发人员要对进度延迟进行分析，提出弥补方法。周例会的目的是通过交流沟通，使项目组所有成员都了解其他项目组成员的工作内容及实现方式，为后续项目人员调整做储备。

月例会 每月月初，由项目管理办公室组织参建单位主要负责人召开项目例会，总结这段时间的工作，会后形成会议纪要、项目月报，呈交项目领导小组及监理等各成员。

季度例会 每个季度，由项目管理办公室组织召开由项目办公室及项目经理参加的季度例会。从宏观上总结这段时间的工作，会后形成会议纪要。

需求管理制度 需求指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。需求管理的过程，从需求获取开始贯于整个项目生命周期，力图实现最终产品同需求的最佳结合。

需求管理是完整管理模式中的一环，同其他特性诸如完整性、一致性等不可分割，彼此相关而成一体。需求管理应保证一套需求是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满足（甚至是充分满足），仅仅解决部分需求是没有意义的。

具体的需求开发过程包括：需求获取、需求分析、编写需求规格说明书、需求验证几大步骤。需求管理必须保证需求开发过程和产出物的质量，以及随后的系统开发活动（包括设计、编码、测试、维护等）正确、完整、一致地实现已定义的需求。具体来说，需求管理主要涉及以下几方面的工作：
（1）需求评审 （2）需求确认 （3）需求跟踪 （4）需求变更控制 变更管理制度 变更管理是软件项目的重要内容，无休止、随意的变更将严重影响产品的质量，带来更多的问题。变更管理一定要确定基线的概念，所谓基线就是经过评审、审批、测试后形成的工作产品。对基线的变更必须严格管理、严格受控。变更管理包括需求变更、设计变更、测试变更等环节。针对不同的特点应由不同人员来加以控制。

需求变更原则上由业务组的人员提出，业务组负责人审批，重大变更必须由业务组负责人和工程总监审批；

设计变更原则上由业务人员和开发人员和相关人员提出，项目经理审批；

内部测试变更原则上由测试人员提出，项目组内的项目经理或技术经理负责；

验收测试、试运行等测试问题由最终用户提出，经过业务负责人汇总审批后，实施组执行。

工作制度 工作时间 项目组工作时间分两段：早上9:00－11：30；
下午13：00－17：30。

项目组每周工作五天，按法定节假日休息。出差同事在周末有充足工作的前提下可以加班，并可在后续工作中申请调休。项目组工作安排会按照这个时间来考虑，但会依据工作进度安排适当进行调整。

工作纪律 工作时间不允许上网私聊。与公司同事之间的沟通，通过QQ、微信、电子邮件及sametime方式交流。

每周五下班前提交本周工作周报；
如果周五由于各种原因不能提交周报时，于下周一的十点前必须提交周报。

项目组内部每周一周例会制度，时间是每周一下午下班前一小时，总结上周工作，制定本周工作计划。每人只用2－3分钟描述自己目前的工作情况，未完成的工作，遇到的困难。个人的工作计划在例会结束以后制定，当天提交。

个人工作计划汇报到项目小组长处，由小组长制定小组周工作计划，提交到文件服务器相应的目录上。小组的计划必须落实到每个人本周的工作任务，相应的工作成果。

个人每天填写工作报告，下班后提交到配置管理工具。个人工作成果，两天内必须提交一次。采用配置管理工具做为开发成果管理工具时，任何人不允许以任何理由为借口覆盖别人的工作文件；
遇到提交冲突可以通过查看配置管理工具上的日志看到上一版本的提交人，协同解决冲突。

在工作中，所有遇到的项目问题，或者是管理上的问题，在每周例会中要及时提出，保持项目组内的问题沟通渠道的通畅，以保证及时完成工作，而不是发现问题后的相互推诿。

项目工作繁重，为保证项目组工作进度，事假申请至少要提前半个工作日。

在客户现场时不能够使用客户电话私人聊天，禁止打游戏。

每天个人负责清理自己周围的卫生，保证个人工作环境的清洁。项目组每周进行一次卫生清洁活动。

配置管理制度 配置管理的作用是建立和维护在整个软件生命周期中项目产品的完整性、一致性和可追踪性。它关注的不是软件的好坏，而是工件的有无。

良好的配置管理是变更控制的基础，它提供了配置项存储、版本管理、一致性控制、访问控制、工作区管理、备份及恢复等强有力的功能。

建议整个工程设置一个配置管理系统，所有的项目文档和交付物纳入配置库进行管理。这样便于统一进行配置管理，变更控制，防止不必要的变更给工程带来影响。

配置管理的主要活动有：编制、评审和批准SCM计划；
SCM人力组织；
建立配置环境；
发布配置状态报告；
基线发布；
变更申请、审核与实施；
发送变更结果给受影响方；
配置审计；
产品发布等。

问题管理制度 所谓问题就是那些必须采取行动去解决或纠正，否则可能对交付日期，预算或是交付成果的质量有负面影响的问题或是不确定性。典型的问题如：
（1）项目范围的变更 （2）项目交付成果发生了变化 （3）交付成果未达到规范定义的要求 （4）缺乏有经验的项目人员 （5）项目进度的推迟或是超过预算 问题管理就是通过识别、分析、解决、报告等手段，帮助工程和各个项目及时解决发生的问题，并与相关团队/部门沟通进行必要的沟通。

问题管理具有三个要点：
（1）早期识别问题，最小化问题对项目造成的影响；

（2）分析问题并执行合适的方法/手段解决问题；

（3）确保问题和问题的解决能得到连续的监控和评估。

文档管理制度 实施文档是项目成果的一个组成部分。在项目实施过程中，由于项目实施的复杂性，双方人员参加以及时间跨度长等因素，所以鼻息建立文档管理制度，将有关需求、建议、解决方案和结论都必须文档化、标准化，以便查阅和引用。

文档类别 收集的项目文档至少应包括：
（1）项目管理文档 （2）客户提交的需求文档 （3）实施开发方提交并由客户确认的解决方案文档 （4）客户需求改变报告和批准书 （5）开发文档 （6）测试方案和测试结果报告 （7）客户签署的阶段成果确认书 （8）项目总结报告等 （9）文档管理内容主要包括：
（10）文档的命名标准 （11）文档的版本控制 （12）文档的批准和存档 命名标准 文档按照：模块名-文档性质-日期命名 报告签收记录：对于双方提交的需要对方进行签字确认的报告或文档，在5个工作日内应签字批准，或者书面形式作出有保留意见的批准或拒绝。在双方提交和签字后应填写“报告签收记录”。

版本管理 所有的文档必须采用统一的版本标准，以便于质量审计和文档的验收工作。

起始版本为V1.0。

在未经对方审阅前的内部审阅和修改，版本总号不变、子号递增，如：V1.1、V1.2。

经对方的审阅或修改后，则版本号升级，如：从V2.3到V3.0。

当文档最终确定后，统一提交项目经理存档，若需要修改的须通过变更流程。

项目实施规范 项目标准规范 本项目建设有专门的项目标准规范体系，包括管理、技术、数据、安全等规范标准，作为项目实施过程中必须遵守的标准，在项目实施过程中需要组织项目成员认真学习该标准规范，以该标准规范为指导建设好本项目。

过程管理体系规范 我公司对信息化工程建设项目，拥有完整的规范体系，是本项目实施过程中质量管理必须遵守的规范，包括需求开发和管理、总体设计、详细设计、编码与单元测试、集成测试、评审等规范。

1.5.2.1.2. 质量审计 根据公司质量管理体系，对项目实施的各个环节进行质量监督。

定期的对项目的质量问题和重大的技术、问题进行评审，并且根据评审的内容给出修改或调整方案，监督并落实方案的执行情况。

1.5.2.1.3. 过程审计 对照检查单，以问卷、面谈或其它适用的形式对软件开发过程进行检查。在检查列表中记录评审发现工作过程审计清单。

1.5.2.1.4. 文档审计 文档审计是以计划的内容为基础，以目标和方法为依据、对所作的各种技术工作进行描述，同时提交执行文档，所有提交审查的记录都将保存作为审计线索。

按照项目文档计划的内容，定期对项目的文档进行审计，主要涉及到文档的内容，文档的格式，文档的发布范围，文档命名标准、文档的版本控制、文档的批准和存档等是否符合要求。

项目实施过程中产生的文档需要纳入到系统配置管理中来，确保各类文档的版本和状态有效，并且能够追溯到历史。

项目审计 （1）项目审计内容 包括项目计划、项目管理内容、实施方法、项目风险与健康性审计。

（2）项目审计分为三个层次 一是工程监理定期或不定期针对项目进度、项目计划，文档完备性、文档完善程度、文档格式等进行审计；
二是工程建设单位定期或不定期针对项目阶段性重要成果，关键方案等组织讨论、阶段性验收并进行审计；
三是承建单位负责人定期或不定期进行项目风险、健康性审计及争议控制等。

（3）项目审计的执行 检查由项目组成员提交的产品（如：项目计划、项目管理内容、实施方法、项目风险、项目成果物等）和工作产品审批表（证明该产品经过质量评审），审核结果记录在工作产品审批表和“SQA问题状态日志”中。

不合格项处理：
每1周（同项目周例会）SQA人员提交“SQA工作周期报告”，报告提交给项目经理、SQA主管。

在审计中，SQA人员将发现的问题记录在检查表内，并汇总到“SQA问题状态日志”（SQA问题状态日志）中。

问题尽可能在项目组内部解决。如果该问题严重且不能在项目内部满意解决，SQA负责人应将这项不符合报告给高层经理。

SQA负责人要进行判断，以便决定一个不相符项是否对项目造成风险。如果出现的风险很大，并且不能在项目组中得到满意的解决，SQA负责人要将“SQA不符合报告”(SQA不符合报告)给高层经理。

测试管理 概述 一、总体要求 测试计划阶段将制定明确的测试策略、测试范围和测试步骤等，提交工作项目管理组批准后进行。所有的测试过程和结果，应及时形成测试报告，并经由测试人员签署意见后汇总到工作项目管理组和监理进行审阅。在安装测试和系统联调测试期间，业主方有权派出技术人员参加, 我公司将提供技术咨询。

二、测试工作内容 工程的测试工作包括：
（1）硬件系统的安装调试与集成测试；

（2）单个软件系统的单元测试、集成测试、系统测试和跨系统之间的集成测试；

（3）软硬件系统整体的集成测试；

（4）软硬件系统在服务体系的部署测试；

（5）软硬件系统整体性能测试与调优。

本项目建设过程中的质量保证非常重要，除了开发商内部的测试外，业主方或用户有权对实施方检验与测试过的产品进行检验和测试，以确认产品是否能符合规定的目标与要求。此种情况下，采购方邀请第三方或专家进行的检验和测试，费用由业主方承担。

三、测试工作的重点 在上述测试中，重点是跨系统之间的集成测试和性能测试：
集成测试：由于项目承建单位较多，通过集成测试能“串起”所有的软硬系统建设。

性能测试：随着企业直报及各部门统计数据的增加，软件系统的性能压力将持续上升，为此需要通过性能测试和不断调优来强化系统的性能。

此外，从管理的角度，需要将测试过程中每个环节产生的问题和解决情况进行系统的跟踪与管理。

生命周期测试模型 软件测试是应用系统开发的一个重要环节，它贯穿整个应用系统开发的生命周期。

系统项目具有以下特点：
（1）系统复杂，需要与其他的业务系统进行交互 （2）系统性能要求高、质量要求高 （3）系统需要与其他业务系统进行数据交换 （4）系统需要对其他业务系统的数据进行迁移或同步，要求非常高 根据本项目的这些具体特点和要求，建议在完全生命周期测试模型基础上，根据项目具体情况和成本效率进行裁剪，形成本项目的测试策略、总体测试计划和详细测试计划。

下图是“完全生命周期测试”方法论模型，它直观描述了整个项目生命周期内所有的测试流程、测试内容、测试阶段及应用系统开发各环节与测试的关系。完全生命周期测试模型是经过实践证明的、结构化的测试方法。完全生命周期测试模型为一个大型项目的所有测试和与测试相关的活动提供一个全面的视图。

完全生命周期测试模型 测试策略 （1）制定恰当的测试原则和准则，以减轻管理项目风险 （2）为涉及多个组织和业务单位的测试提供公共的测试方法 （3）明确测试的总体方向 （4）兼顾成本效益和团队测试方法 （5）进行全生命周期的测试 （6）从高层面、系统的角度进行测试 测试计划 测试范围 （1）硬件系统的安装调试与集成测试；

（2）单个软件系统的单元测试、集成测试、系统测试和跨系统之间的集成测试；

（3）软硬件系统整体的集成测试；

（4）软硬件系统在服务体系的部署测试；

（5）软硬件系统整体性能测试与调优 测试总体目标 软件系统测试的总体目标：
（1）满足客户业务需求 （2）移植的数据通过一致和集成检测 （3）确保错误在早期测试中被发现，降低成本 （4）确保测试在预算和时程内执行 测试级别 每个开发阶段都代表着一定程度的物理集成和质量达到的级别。对应这些开发阶段可定义相应的测试级别。这些测试级别可作为机构或项目组的测试标准和沟通的公共术语。这些测试级别定义如下：
（1）单元测试 当建立或修改一个模块或程序的编码时就要进行最初的测试，即单元测试。单元测试验证新的或修改的功能是否正确，它一般不需要与其他应用接口。单元测试的目的是在模块或程序级消除编码中的错误。

（2）集成测试 集成测试验证应用组件的运行，以及模块与其他系统组件的运行。

（3）系统测试 系统测试验证所有应用组件的运行，包括与其他应用的接口运行。系统测试验证系统满足功能和架构的需求。

（4）系统集成测试 系统集成测试验证所有应用的集成，包括与外部和内部接口的集成，同时验证应用与硬件、软件及基础设施组件在类似生产环境下的集成。

（5）运行测试 运行测试验证应用是否能在生产环境中运行，并且能满足对可运行性的需求。运行测试在系统测试之后进行或同时进行。

（6）用户验收测试 用户验收测试将全面和系统地测试应用或系统的各个方面，以验证是否能满足业务和非功能需求。

测试工具 （1）单元测试工具 根据本系统开发的要求和特点，并结合各测试工具的特点，采用Junit、Cactus、EasyMock三种工具进行单元测试。

（2）Junit Junit是一个回归测试框架。用于Java开发人员单元测试之用。用于测试java类中方法的输入输出，可以自动捕获代码中的各种异常。Junit是一个测试框架，可以在它的基础上开发出各种类型的单元测试工具，如Cactus，EasyMock，Httpunit等都是基于Junit框架开发出来的测试工具。

（3）Cactus J2EE应用在很大程度上依赖于容器提供的服务，给测试带来很大不便。

Cactus提供对容器内的Servlets， JSP custom tags， Servlet Filters及EJB的测试服务。

（4）EasyMock EasyMock是创建那些模仿对象的快速的方法，同时它会保持单元测试的能力。

（5）性能测试工具 在本系统建设过程中，根据各性能测试工具的特点，拟采用LoadRunner工具进行性能测试。

测试步骤 完全生命周期测试模型包括五个阶段，如下图所示：
测试（项 目）开始 方案实施 和测试结 束 测试执行 和报告 测试 设计 测试评估 和计划 图 测试模型阶段划分 （1）测试开始 开始阶段的重点在定义项目方法和工作范围、准备项目计划、建立质量管理机制，同时准备好项目人力资源，开始启动工作。

（2）测试评估和计划 在测试评估和计划阶段，将评估、复审、整合和确认测试范围和目标，制定测试策略、测试总体计划，制定各个级别的详细测试计划，并且计划和执行静态测试。

在本项目中，测试评估主要源于双方制订的项目实施计划及需求分析报告。测试范围和目标必须得到项目各方的一致认可。测试管理小组必须了解应用系统业务和功能的需求及两者相互关系。

测试计划是项目测试成功最关键的环节，它应考虑到每一个测试任务的细节。测试策略和测试总体计划给出项目总的测试方针和策略，详细测试计划是总体测试计划的补充。

（3）测试设计 在这一阶段，将为每个级别的测试制定详细测试规格说明和测试执行计划，并且为每个级别的测试制定测试环境规格说明。

测试设计包括准备测试后勤、工具、技术、测试案例及各种层次的测试执行方法。

（4）测试执行和报告 在这一阶段，将建立测试环境，执行每个级别的测试，复审和确认测试结果，在测试结果中记录所产生的差异。在解决差异、完成调试工作、测试没有错误后，代码将转到下一级别的测试。在每个级别的测试完成后，将提交测试报告。

测试报告有效地沟通了测试状态和测试结果，以便为项目管理组提供是否终止或继续测试的决策。测试报告包括分析问题出现概率及测试中问题解决的状态，从而为项目管理组提供决策数据。在本阶段，测试报告非常关键，它将决定最终项目上线的签收。

测试报告经由测试人员签署意见后汇总到工作项目管理组和监理进行审阅。

（5）方案实施和测试结束 在这一阶段，通过了测试的方案将被实施。测试文档资产分类归档，供维护时使用。测试小组更新测试计划，向项目管理组反馈测试改善意见，改善测试流程，测试结束。

测试管理流程贯穿整个项目开发周期，并保证项目的实施质量。

1.5.2.1.5. 文档管理 文档管理要求 在项目实施过程中，由于项目实施的复杂性，双方人员参加以及时间跨度长等因素，所以有关需求、建议、解决方案和结论都必须文档化、标准化，以便查阅和引用。实施文档应作为项目成果的一个组成部分。

收集的项目文档至少应包括：项目管理文档、客户提交的需求文档、实施组提交并由客户确认的解决方案文档、客户需求改变报告和批准书、开发文档、测试方案和测试结果报告、客户签署的阶段成果确认书、项目总结报告等。

文档管理内容主要包括文档命名标准、文档的版本控制、文档的批准和存档。

文档管理执行 项目实施过程中产生的文档是项目建设成果的体现。公司有规范的项目文档提交计划。遵照招标文件要求，我们将为用户提供所有设备的技术文件，包括纸介质和电子介质。相关文件的格式为国际标准格式，并且文档的格式等将严格遵守ISO质量标准体系，采用各种工具软件的版本将提前与用户单位协商决定。在项目实施完成后，将向用户单位及有关方面提交以下文档，并以“项目文档与资料交接清单”的形式予以记录：
所有项目文档将由文档组统一负责，并及时向用户单位提交。

风险控制 在项目建设中，存在各种各样的风险，会遇到各类的困难，需要得到高度的关注和重视，采取多种措施加以预防，以保证工程成功实施。针对项目实施特点，主要风险包括：
（1）组织风险 （2）实施风险 （3）技术风险 （4）资源风险 （5）运维风险 针对不同的风险建议采取如下的风险控制措施。

组织风险 本工程中组织风险主要表现：
（1）各层人员在项目的意义和目标上没有达到完全的共识；

（2）部分关键问题无法得不到及时决策和解决。

此类风险主要解决措施：
（1）明确项目意义，要求各层次的负责人要全力支持；
定期召开项目沟通与协调会，让各层次人员认识并理解项目的意义和目标；

(2）建立明确的沟通协调机制，关键问题建立直报流程，日常问题通过各方项目管理办公室成员定期召开的项目周例会解决；

(3）将项目分阶段实施，以减少需求不确定性带来的风险。

实施风险 本期工程实施风险主要表现：
（1）需求有不确定性；

（2）项目参与方较多，沟通不畅可能带来进度及质量等多方面的风险。

此类风险主要解决措施：
（1）将建设目标分阶段实施，在减少需求不确定性带来的风险；

（2）建立明确的各方沟通机制及分工界面，定期召开沟通协调会以控制进度和质量风险。

技术风险 本期工程技术风险主要表现：
（1）软件报表类别较多，存在诸多不确定因素。

此类风险主要解决措施：
（1）明确需求，减少不确定因素。

资源风险 本期工程资源风险主要表现：
（1）实施人员不确定及人员投入不足风险；

（2）硬件资源无法完全可控存在风险；

此类风险主要解决措施：
（1）各建设方要提供明确的实施团队及责任人，主要核心成员未经甲方许可不得更换；

（2）甲方单位要严格把控环境及主机设备等部门的配合力度。

运维风险 本期工程运维风险主要表现：
（1）系统出现问题得不到及时解决；

（2）系统后续持续优化风险。

此类风险主要解决措施：
（1）高度重视运维问题，明确运维模式；

（2）由IT基础设施专业人员、应用系统开发人员、业务专家共同组成，负责系统运行的支持、维护和优化工作。

沟通管理 本软件项目不但包含软件应用开发工作，还包括系统集成部分，我们认为系统的顺利推广实施必须与相关的各机关和部门进行充分的沟通和协作，才能最大程度保证项目能够有条不紊地进行。

与用户单位的协作 我们非常欢迎用户单位的领导和工作人员随时对我们的工作提出建议和意见，也欢迎用户单位的工作人员及运维机构人员自实施工作开始即参与本项目的需求分析、测试、安装部署等工作。

在实施的过程中，我们与用户单位的合作行为是贯穿始终的。我公司将力求制定贴切的合作方案、选择恰当的合作方式，始终坚持“客户至上”的合作原则，在各个环节与用户单位保持良好的合作关系，为用户单位提供最细致的服务。

我们与用户单位将通过情况通报单的方式，建立信息交互机制，密切配合，保证项目建设的顺利进行。

情况通报单样式如下：
情况通报单 编号：
情况通报时间 年 月 日 时 分 信息重要性 紧急通报 重要通报 一般通报 报 告 单 位 报 告 人 通 报 对 象 信息内容：
信息反馈记录：
配置管理 建立配置管理小组，负责项目的配置管理策划、基线建立、变更管理和配置审计。制定专职的配置管理人员，全生命周期内对项目进行配置管理。

负责批准项目基线的建立和变更，对项目的成果物进行管理和发布。

制定专业的配置管理人员，建立项目的配置管理数据库，对项目进行配置管理，确保项目成果物和项目状态可控。

一、配置管理过程流程 配置管理过程流程如下：
图 配置管理过程流程 二、变更控制流程 变更控制流程如下：
变更控制流程 说明：
提交变更请求 提议对配置项进行变更的人，简称申请人。申请人首先填写一个配置变更申请表（SCMF01）。

申请表是文档化已提交变更的一种形式，申请者必须做到：
（1）清晰地描述变更 （2）陈述变更的原因 （3）描述变更的影响 （4）对于文档的变更，要附上原有的页面或草稿，并标出其改动部分 （5）向SCM管理员提交SCMF01 SCM管理员收到SCMF01后，应做到：
（1）将SCMF01记录到变更和问题（C&P）日志中，SCMF01状态为“提交” （2）审核SCMF01，确保提交的变更及理由已被清晰地描述 （3）将SCMF01转发给CCB CCB接到SCMF01后，可以拒绝申请，或提出评估申请，或批准。

如果SCMF01被拒绝，SCM管理员要做到：
（1）通知申请者 （2）更改C&P日志，SCMF01状态为“拒绝” 如果SCMF01要求评估，SCM管理员要做到：
（1）将SCMF01转发给变更权力机构指定的评审者 （2）更改SCMF01在C&P日志中的状态，SCMF01状态为“评估” 评估变更请求 变更评估者必须评估变更的影响，包括：
（1）受影响的项 （2）对技术和功能的影响 （3）对费用和计划的影响 评估者必须验证变更的理由。

评估结果要记录在SCMF01表中，并转发给SCM管理员。

审核和批准变更 当评估完成后，SCM管理员应做到：
（1）将SCMF01返回给CCB，进行审批。

（2）更改SCMF01在C&P日志中的状态，SCMF01状态为“已评估”。

CCB应审核评估结果并决定是否批准变更。如果变更被拒绝，SCM管理员要通知申请者，更改C&P日志，SCMF01状态为“拒绝”。如果变更被批准，项目经理必须更改软件项目计划，并将这一变更指派相应的项目组成员实现，另外，SCM管理员要记录更改的C&P日志，SCMF01状态为“被批准”。

实现变更 批准的SCMF01应按照项目工程的过程执行。变更对象被“提取”并实现变更。实际的变更必须由SQA审核，确保变更已经过所有的必要的审核和验证。

批准结果 在变更完成并由SQA审核后，SCM管理员应做到：
（1）将SCMF01返回给CCB，便于最终的审核，取得“检入”许可，以便更改适当的基线 （2）更改SCMF01在C&P日志中的状态， SCMF01状态为“验证” 更改基线 SCM管理员应做到：
（1）更新基线库中经认可的变更，登记变更摘要到配置库系统和相应文件上 （2）更新C&P日志以证实变更已完成，SCMF01状态为“完成” （3）提供变更记录来显示所有已提交变更的状态 定期提供关于未实现的变更请求的状态报告，以便于项目经理、CCB和受影响的各方跟踪并管理所提交的变更，直到其被解决或关闭。

三、配置库的备份和归档 整个配置库的备份机制采用周期备份+基线备份的方式，周期备份时间是每一周一次，基线备份的形式是当有一个新的基线产生时，所有被配置库全部备份一次。如果两次备份的时间重复，则只需做一次备份。备份机器为HI-FILE。

备份的步骤如下：
（1）确保所有的文件都处于“check in”状态；

（2）锁定数据库；

（3）选择全部的配置区；

（4）执行备份命令；

（5）产生的目标文件的命名方法采用backup+当天的日期组成，比如：backup2003-7-22；

（6）数据库解锁。

如果在工作之中需要进行备份恢复，则按照如下步骤进行：
（1）将将备份文件拷贝至CLEARCASE上；

（2）使用Restore命令，将文件恢复至根目录下；

（3）如果有必要，对所有配置区重新建立用户和设置权限分配；

四、配置审计 该项目的配置审计活动必须在发布正式基线之前进行，也就是说在发布需求基线和发布产品基线之前进行。

需要准备的工作有：
（1）CCB要负责指定执行审计人员和配置审核人员；

（2）项目经理和配置审核员决定审核范围；

（3）实施审计日程表，根据项目计划来确定。

配置审核时间：
（1）需求产品审批完成时，做需求基线配置审计；

（2）正式产品发布前，进行产品基线配置审计。

执行审计所需的特定步骤：
（1）配置审核员准备配置审核检查单。

（2）SCM管理员要负责审计的协调和准备。

（3）配置审核员安排时间审核文档和记录 （4）配置审核员在审核中发现不符合现象，并做记录。

（5）由项目经理负责消除不符合现象。

（6）配置审核员验证所有发现的不符合现象确已得到解决。

1.5.2.1.6. 系统测试 项目实施方结合软件研发经验，针对本项目，提出如下测试方案：
1、本项目测试分单元、集成、系统测试和以用户试用为主的测试四个阶段。其中单元测试、集成测试由项目组负责。测试部门负责指定测试经理和提供必要的资源和支持。由测试经理负责系统测试活动的策划实施或监督工作。系统测试和用户测试要求至少选择一种，只有通过系统测试或用户测试的产品，才可以最终放行。

2、单元测试：
单元测试在编码阶段由项目组完成，内容和实施详见下图：
3、集成测试 在编码开发完成，提交测试组进行系统测试之前，开发组可以根据需要进行集成测试。集成测试由开发经理负责，可以指定由测试经理或其他人员策划并实施，集成测试实施前应有经开发经理认可的《集成测试方案》，测试流程可参考系统测试。集成测试过程中，对发现的问题应形成《测试缺陷报告》。

集成测试完成后形成《集成测试总结报告》作为系统测试或用户测试的重要输入数据。

4、系统测试 确定测试经理和组建测试组，测试经理在产品立项评审时确定，在开发组提出测试申请时，由测试经理负责组建测试组和确定成员。

测试申请项目经理在完成系统的单元/集成测试后编写《系统测试申请报告》并提交给测试经理审查。项目经理还应提供相应的《需求规格说明书》。

《测试方案》的制定和评审测试经理应根据《系统测试申请报告》、《开发策划书》－测试计划、《需求规格说明书》、《用户手册初稿》，编制《测试方案》，作为测试的主要依据。测试经理负责组织项目经理/产品经理（PM）、开发经理（DM）、系统分析员（SA）等相关人员对《测试方案》进行评审，提出合理的意见和建议，整个评审活动要求有详尽的记录。（具体实施方法参见《评审控制程序》）
《测试记录》测试人员依据《测试方案》进行测试，测试经理对测试工作进行统筹管理，并对测试质量负责。测试过程中应形成《测试记录》，记录中要明显标识出《测试方案》中包括的所有测试内容是否得到了完整的执行以及测试状态。对于发现的问题应及时填写《测试缺陷跟踪报告》，测试经理对《测试缺陷跟踪报告》要进行审核，发现问题，及时督促相关人员进行纠正。测试结果正确的同样要进行记录。

版本控制，当项目组完成一个新版本的编译后，由开发经理或其指定人员提交《版本变更说明》，在其中说明新版本的功能变更情况以及所有改正错误的列表，并提交新版本。

所有非稳定期版本及对外发放的非发货版本中，logo或其他标识上面必须有字样区别于稳定期产品，例如test，β，build号等字样，测试组需要保留版本发放记录。

测试结束。系统测试完成后由测试经理编写《测试综合报告》，并负责组织产品经理（PM）、开发经理(DM)、系统分析员（SA）等相关人员对《测试综合报告》进行评审（具体实施方法参见《评审控制程序》）。评审通过后，测试经理负责制作母盘并将《测试综合报告》和母盘提交给研究发展部品质保证专员。整个测试活动结束后由测试经理根据实际情况决定是否需要编写《测试总结》，对测试过程进行总结。

5、 用户测试 测试申请 明确需要进行用户测试时，首先确定用户测试负责人。用户测试负责人可以由产品经理或项目经理和其他适合的人员担任。

用户测试负责人编写《用户测试申请报告》并提交测试经理审查。用户测试负责人还应提供相应的《用户需求规格说明书》和《开发策划书》。

《测试方案》的制定和评审用户测试负责人应根据《用户测试申请报告》、《测试计划》（参见《开发策划控制程序》）、《用户需求规格说明书》、《用户手册初稿》编制《测试方案》，作为测试的主要依据。用户测试负责人负责组织项目经理/产品经理（PM）、开发经理（DM）、系统分析员（SA）、测试经理等相关人员对测试方案进行评审，提出合理的意见和建议，整个评审活动要求有详尽的记录。（具体实施方法参见《评审控制程序》）
《测试记录》测试过程中应形成《测试记录》，记录中要明示《测试方案》中包括所有测试内容是否得到完整的执行及测试状态。

在用户测试中发现的问题，用户测试负责人应填写《测试缺陷跟踪报告》（无模板），或者根据用户反馈的问题形成问题反馈记录表，保证通过测试记录和更改记录能追踪到为改正该问题而进行的实际工作。

测试结果正确时同样要进行记录。

版本控制所有非稳定期版本及对外发放的非发货版本中，logo或其它标识上面必须有字样区别于稳定期产品，例如test，β，build号等字样。测试经理指定版本控制人员，负责控制向用户发放版本并记录版本发放的情况，同时负责提交《版本变更说明》说明新版本的功能变更情况以及所有改正错误的列表。

测试结束测试完成后由用户测试负责人编写《测试综合报告》，并负责组织测试经理（TM）、产品经理（PM）、开发经理（DM）、系统分析员（SA）等相关人员对《测试综合报告》进行评审（具体实施方法参见《评审控制程序》）。评审通过后，测试经理负责制作母盘，并将《测试综合报告》和母盘提交给研究发展部品质保证专员。

测试完成后由测试经理编写《测试综合报告》，并负责组织产品经理（PM）、开发经理(DM)、系统分析员（SA）等相关人员对《测试综合报告》进行评审（具体实施方法参见《评审控制程序》）。

评审通过后，测试经理负责制作母盘，并将《测试综合报告》、《母盘内容更改通知单》和母盘提交给研究发展部品质保证专员。

6、产品质量度量 在产品测试结束后，测试经理独立地对待发行产品的质量进行评价，评价依据是产品质量目标中的产品错误率。a. 按测试出的产品错误数（选用系统测试结果或集成测试结果），进行Bug密度的统计。b. 按测试产品的遗留错误数（选用系统测试结果或集成测试结果），进行Bug密度统计。

将产品质量的度量结果，填入《测试综合报告》中的“产品度量”部分。

1.5.2.2. 项目验收与评定 1.5.2.2.1. 项目验收 1、成立系统验收组：
由双方的主要技术业务人员、相关部门的负责人等组成，主要职责是：对系统整体运行情况进行总结评估，制定系统验收计划及内容。

2、制定系统验收步骤及内容 由系统验收组制定验收计划书，主要内容包括：
数据库及应用服务等应用软件的安装验收；

应用系统的功能验收；

应用系统集成验收；

系统整体并发处理能力验收等。

3、提交有关程序源代码及技术文件 由开发项目组的项目经理向系统验收组提交程序源代码介质及有关技术文件。

4、系统正式验收 由双方领导签订系统的最终验收报告，正式将系统移交给用户方。

1.5.2.2.2. 正式运行及系统维护 系统验收完毕即进入正式运行维护期，维护期的维护内容、职责由双方约定。

1.5.3. 知识产权承诺 本项目对知识产权有明确要求，除在本合同签订前已经存在的成果知识产权归属原权利人所有外，在本项目进行过程中，所产生的所有与本项目相关的，无论以任何载体形式出现的工作成果，其知识产权均属于采购人和供应商共有。

1.5.4. 人员培训方案 1.5.4.1. 培训要求与目标 根据本项目要求，我公司根据项目实施的进度及时安排培训和授课。我公司负责对建设单位相关部门及指定的用户进行应用性的培训。培训的主要内容侧重于对该系统的使用及系统的基本维护、常见问题及解决办法等问题，并提供实践性的操作，旨在使受训者熟悉系统设计的思路，掌握系统的操作和维护等。建设单位负责对培训质量的监控，并有权对培训内容提出改正意见。主要包括的培训有：
1. 使用培训 对服务体系使用人员、管理人员以及信息部门运维人员进行培训，使得这些相关角色的操作人员可以独立地、熟练地操作对应业务系统的内容。

2. 系统培训 组织系统维护人员熟悉系统硬件、软件环境，进行网络管理、系统管理、数据库管理、数据处理和安全管理的培训。需要提供详细的日常维护方法和工作流程。

3. 业务管理培训 针对与本项目相关的部门之间的工作流程制度，撰写培训教材，为业务管理人员进行包括工程管理在内的相关培训。

根据以上对项目培训需求的分析，我们认为本项目针对客户方的培训目标是为了使客户方的各类管理人员、业务人员能够快速熟悉本期系统的业务功能，使这些功能可以最大限度发挥作用，达到系统建设的目标；
使相关部门的领导能够充分认识到系统建设的重要性和紧迫性，了解系统建设的规划、总体设计的思想；
使IT人员使其可以迅速了解并掌握本期工程所用的核心技术，以保证将来系统验收后可以顺利交给客户方的IT人员自行或协助开发商对系统进行长期的维护；
使所有系统管理人员可以针对系统的运行的各种环境独立进行维护和管理，以保证系统的成功运行。

1.5.4.2. 培训策略 在进行培训之前一定要制定自己的培训策略，它是指导培训工作的基础，也是衡量培训工作效果的标准。科学的培训策略可以提大大的高培训的效率，因为培训的策略是整个培训过程的核心。

1. 有针对性的培训 由于本系统是一套功能完善的应用系统，涉及的人员众多，考虑到不同的人员对本系统使用不同的内容，所以培训需要针对性进行。

2. 采用授课结合练习的方式 每一期培训班的内容将设置多个环节，每一个环节都分为授课和练习两部分，授课部分将按照培训讲义对当期培训班所设置的内容进行详细的介绍，并配有培训教材以做参考。练习部分要求学员按照事先准备好的案例进行实际操作，以加强对所学知识的记忆和理解。并且在练习中还要实现教师和学员的互动，不但对学员的操作进行辅导，还将对学员们提出的疑问予以回答。

3. 提供多种形式的培训教材 提供多种形式、全面和标准的文档给用户，其形式包括：电子文档、印刷品、光盘，以成为其后续稳定应用系统的保障，其中电子文档将放在系统中供随时下载。

4. 利用考核验收加强学习效果 为保证最终的学习效果，将为每一期培训班布置考试题目，以验收学员的学习成果。保证培训质量 1.5.4.3. 培训类别 为了保障系统的顺利建设和高效运行，需要对各业务系统自上而下，针对不同对象，展开不同层次、不同方式的各种培训。

不同的培训对象，培训的侧重点也不相同。此次项目培训对象角色主要分为三种：
1. 领导干部 为了使系统顺利建设、高效运行，需要一只高素质的管理队伍。所以需要对领导开展一系列信息化培训。通过电子政务理论培训，使领导干部能够了解电子政务的内涵和外延，了解国家的大政方针，了解国家信息化发展规划，了解国际国内的发展动向，对系统总体有一个宏观的、全面的、深刻的理解。使领导能够站在一个宏观的角度上指导本部门的系统建设和应用，并使各部门之间能够更好地协作；
通过应用软件培训，使领导干部并能熟练使用相关系统的查询、监控、宏观决策等功能开展日常业务。

2. 各业务单位系统操作人员 系统再好，需要人来使用。因此需要对业务人员开展一系列应用软件和系统软件的培训。使业务人员对本部门业务相关子系统能够深刻了解并且可以熟练使用，充分发挥出应用软件的效能，更好地完成本部门的业务。

3. 技术人员 任何系统的顺利实施和高效运转都离不开技术人员的努力。通过对技术人员开展一系列培训。使技术人员对系统的总体有一个宏观、全面、深刻的了解，便于更好与其他部门的协作；
全面掌握系统的安装、配置，并且根据系统的运行情况进行管理，使系统稳定、安全、高效的运行，从而提高系统的运行质量和工作人员的办事效率，为今后系统的进一步建设培养一支专业技术过硬的队伍，打下良好的基础。

1.5.4.4. 培训方式 为了加强培训效果，提高培训效率，针对各业务系统不同的需求，有针对性的进行培训。将培训方式分为：集中场地培训（含课堂讲解和上机操作）、现场培训、城市建设经验学习考察。

1. 集中场地培训 国内集中培训是指在国内由相关正规培训机构、开发商或用户方提供的培训教室内实施，并在专门一段时间内进行的技术传授。这种培训方式的优点是，课程内容正规，授课教师队伍精良，教学环境优越。由于培训时间有保障，所以培训效果也会非常好。

2. 现场培训 现场培训旨在针对不同的用户、用户工作、用户环境提供大量小规模、有针对性甚至点对点的系统用户培训。在系统软件安装调试时，应用系统安装调试时工程实施方也会邀请用户的技术人员参与系统的安装、调试和配置管理，维护等工作。

这种培训的特点是针对性强、直观、方式灵活，而且与实际结合紧密，使用户维护人员在短时间内对系统的认识有了极大的飞跃，其系统维护技能快速提高，并具备了系统维护人员的资格。现场培训是为技术人员提供的培训。

3、本项目培训内容 主要采用现场人机结合的方式进行授课。

一、以班为形式集中授课为主，个人辅导和各类帮助文档为辅的方式进行培训。

二、本公司负责为培训人员提供培训用文字资料和讲义等相关用品。

三、提供本公司所在地考察培训。

四、提供系统安装现场培训。

五、教学方式：中文教材、国语讲授。

对于本项目中，上线阶段前给予至少2次集中培训，具体培训内容由业主方和我公司协商确定。

1.5.4.5. 培训对象 培训对象主要有以下两类人员：
本系统所涉及各级用户（用户级培训）
本系统所涉及系统管理员（系统管理级培训）
1.5.4.6. 培训阶段计划 由于本期工程涉及各业务单位的相关人员，人员众多，本项目需要进行全面的产品培训和软件使用培训，包括针对信息化管理部门人员和平台运营人员培训。为此，需要针对系统实施的不同阶段，提供不同人员的培训。

按照本期工程的要求，系统是分三个阶段实施，则培训的时间安排则以此三个阶段为准。

1. 系统开发阶段 在此阶段将对相关的管理人员、业务人员、技术人员等进行有关标准规范、需求开发方法、测试方法、有关应用技术的培训，以便项目组织和开发测试的顺利进行。

2. 试运行阶段 对进入试运行的试点单位的人员进行相关的培训，包括信息化管理部门人员和平台运营人员。对系统管理人员进行安装配置的培训，以帮助客户顺利完成系统安装配置工作；
对平台运营人员进行系统使用功能培训。

3. 系统上线前的培训 对其他单位的人员进行相关的培训，包括系统管理人员和业务人员。对系统管理人员进行安装配置的培训，以帮助客户顺利完成系统安装配置工作；
对相关业务人员进行系统使用功能培训。

1.5.4.7. 培训计划 用户级培训（初级培训）
用户级培训主要是针对各级使用人员对该系统的使用培训，包括系统的操作方法、操作流程等。

系统管理级培训（中级培训）
系统管理级培训主要是针对该系统的系统管理员的培训，包括数据库的安装配置与管理培训以及对系统的维护培训。

系统管理人员负责系统的安装、数据存放和安全等多种重要工作，是本系统能否健康运行的基础保障队伍。作为系统管理员，必须了解下述内容：
配置和管理平台的应用模式；

规划和维护数据库的复制；
数据库管理 计划和实现安全机制，包括认证和授权、口令、服务器访问以及加密等；

增加和删除用户；

维护和分析服务器运行日志；

1.5.4.8. 培训资源 培训资源是指培训场所、培训设备、培训师资等进行培训工作必备的元素。

1.5.4.9. 培训过程管理 在以上的培训计划实施的过程中，我们认为最复杂，风险最大的培训工作就是系统上线前阶段最终用户的培训。因为各位最终用户能否具备正常使用系统的操作技能直接影响系统能否上线。同时，由于参与培训的人员很多，为保证好此项培训工作质量，实现培训目标，我们制定了该项培训工作的过程实现方案。

我们把完成该项培训工作的过程分为三步：培训准备、培训实施、培训评估 1.5.4.10. 培训资料 我公司免费为培训人员提供培训所需的各类资料。

培训资料包括：
书面教材：用户使用手册，维护手册，FAQ集，突发事件处置预案。

用户使用手册包括每一个功能实现的详细的步骤操作说明，在用户使用系统前或者遇到问题是进行方便的查阅。

维护手册中包含了系统运行过程中可能出现的问题，以及问题发生后如何应对解决，提出了最基本的解决方案。

FAQ集中列举了最常见的问答供参考。

突发事件处置预案中针对一些可能出现的突发状况，给出解决方案，供客户在发生突发状况的时候第一时间采取措施进行解决。

现场模拟演示：
通过搭建模拟运行环境，进行培训现场实验。

提供了一个类似现场的环境，方便培训老师手把手的辅导，通过自己的亲身体验，用户也更有学习的信心和动力，能够提高培训的质量，获得更好的培训 1.6. 系统功能响应及偏离表 序号 招标系统功能要求 投标系统功能描述 有无偏离 偏离内容及原因 1 采用信息资源管理（IRM）的方法，从战略、规划、设计、建设到应用，对**平台进行整体架构设计 在章节1.2.1.3.IRM（信息资源管理）方法，有具体描述 无偏离 2 采用开放组体系结构框架（TOGAF）的方法和相关技术来实现整个平台的业务、数据、应用和技术架构的设计，以体现**平台长期发展规划的建设要求。

章节1.2.1.2.TOGAF方法论，有具体描述 无偏离 3 通过构建标准化的服务接口，实现第三方电子商务平台（如淘宝等）与平台的对接，帮助企业电子商务平台上实现商品信息的“一键式”发布 章节1.2.3.1中有相关描述。（第37页）
无偏离 4 通过与市企业融合服务平台的对接，或者与政务部门系统的对接，能够迅速便捷的为服装企业提供一站式的相关部门的政务服务，包括：社保办理（社保局）、社保查询（社保局）等服务 第10页，以及 章节1.2.6.11 章节1.2.6.12 章节1.2.6.13 有详细描述 无偏离 5 通过构建标准化的服务接口，实现第三方服务机构系统与平台的对接，为企业提供专业的、定向的公共类服务，包括：法律服务、人员招聘服务、投融资服务等 第10页，以及 章节1.2.6.1 章节1.2.6.6 有相关描述 无偏离 6 帮助企业获得应知、须知、要知的资讯信息，结合用户行为和属性为用户精确定位资讯，挖掘信息与信息的关联关系，为用户呈现更多有价值的资讯，帮助企业快速把握发展方向和市场动向。提供国家政策资料、招商引资、行业动态、商业趋势等信息服务，并能实现定向推送。

章节1.2.3.1中有相关描述（第34页开始）
无偏离 7 提供目前互联网平台通用性基础服务，包含且不限于短信服务、邮件服务、检索服务、统一认证服务、订阅服务、信息采集服务、文件服务等 章节1.2.3.1中有相关描述（第38页）
无偏离 8 对接入到平台的企业服务资源，按照信息化角度进行管理，通过将企业服务分为信息类服务、业务类服务、交流类服务与管理类服务，形成四大类服务基础管理框架，通过管理框架，对接入到平台的服务资源进行融合性的管理与应用 章节1.2.5有详细描述 无偏离 9 业务服务功能，包括但不仅限于：
（1）提供最新最全面的与园区企业相关的资讯动态，以及招商引资的展示等。

（2）提供全面畅通的沟通交流平台，包括园区活动、园区圈子、在线交流等。

（3）能够为各类用户提供与之相关的需求、服务、人脉、资讯等各类自有空间管理功能，业务内容包括园区管理空间、服务机构管理空间、企业管理空间、团队管理空间、个人管理空间。

（4）提供全方位的在线服务功能，包括包括虚拟商务地址、多功能虚拟会议室租赁服务、金融服务、企业培训、知识产权、IT服务、众包服务、平台扶持券管理等。

章节1.2.1.6 章节1.2.3.1 章节1.2.3.2. 有详细介绍 无偏离 10 平台业务管理功能，包括但不仅限于：
（1）平台管理功能。提供主页设置、园区信息管理、产业信息管理、特色服务管理、空间管理与政策管理等功能，具体如下：
Ø 主页设置功能模块可设置宣传栏、扶持力度、产业定位、特色服务、园区空间等业务内容。

Ø 园区信息管理功能可添加园区信息与子园区信息，并可查看详情。

Ø 产业信息管理功能可添加产业信息、已入驻企业信息、设置龙头企业信息与产业详情的查看。

Ø 特色服务管理功能可添加园区内的特色服务分类并关联服务资源。

Ø 空间管理功能模块可对园区地产空间进行宣传，提供包括空间名称、空间结算、所属园区、空间地址、建设进度、空间类型、物业信息、入驻企业信息、硬件配套、软件配套等信息。

Ø 政策管理功能提供本地园区特色的企业扶持政策的宣传公告。

（2）线上企业管理功能。提供对入驻企业申请审核与已入驻企业管理的业务功能，提供可添加合作服务商与合作服务商管理的业务功能。

（3）活动管理功能。提供发布活动、查看活动详情、参加活动、管理我发布的活动、分享、联系主办方、搜索活动等功能。

（4）联系人管理功能。提供发现潜在商业关系、建立关系、园区在线互动、查看商脉圈、发送/回复消息等功能。

（5）服务管理功能。提供发布服务、管理服务、找服务等子功能。

（6）需求管理功能。提供用户可发布和咨询需求信息，实现需求管理功能。

（7）资讯管理功能。提供栏目频道设置、资讯发布管理、资讯展示等功能。

（8）企业展台功能。提供包括优质企业推荐、查看企业主页等。

章节1.2.3.2.以及第19页、第20页有详细描述 无偏离 11 **平台的架构建设要求：为保障与企业融合服务平台及其他第三方产业平台的无缝对接，以及整个平台的可持续迭代版本能够满足未来需求的不断变化，整个**平台的架构设计须以微服务架构形式开展，使每个容器都能独立运行一个服务，以保证分布式系统的可伸缩性和高可用性，不断持续推进业务驱动架构、架构服务于业务的进程。

相关要求如下：能够充分理解微服务架构的理念和设计，可行性强，有详细的设计方案；
平台架构需实现组件服务化、管理可视化，且具备以下能力：
a) 应用系统的可视化配置管理；
b) API接口的开发、开放、安全、统计等全生命周期管理；
c) 数据库、业务指标、应用系统性能、操作系统性能和组件健康状况的全方位监控。组件可以云调用或本地部署。

章节1.2.6.1 章节1.2.6.2 有详细描述 无偏离 12 服装产业现状分析与市企业融合服务平台对接要求：“服装时尚产业公共服务平台”在总体架构设计上将充分利用市“智慧城市”公共服务平台的服务资源，在完善自身平台建设的基础上，专注于服装产业的定向服务与深度挖掘，投标人应阐述**平台与市公共信息服务平台、服装在线以及第三方专业的商业平台之间的关系，以及对接方案。其他要求如下：能充分了解业务现状，符合实际业务需求，方法论清晰，可行性强，有详细的对应关系说明；
方案能够详细说明整体架构、各类数据、接口以及相关业务流程与企业融合服务平台的对接方式；
清晰阐明本项目与已建企业公共服务平台的关联关系，资源利用关系，避免项目内容的重复建设；
建设周期、建设成本。

章节1.2.6.11 章节1.2.6.12 章节1.2.6.13 均有详细描述 无偏离 13 性能要求：1．响应时间要求：系统平均响应时间应能够满足系统并发压力负载性能需要。在中等负载下，各种操作的响应时间要求如下：基本的数据查询：3秒；
复杂的数据统计分析计算类功能：60秒。

2. 并发数要求：系统须满足1万注册用户的在线并发数需要。

完全满足以要求：1、基本的数据查询：3秒；
复杂的数据统计分析计算类功能：60秒。

2、并发数满足1万注册用户的在线并发数需要。

无偏离 14 技术要求：方案和产品成熟度: 产品在业界具有一定的知名度，技术路线明确，技术具有先进 性和延续性，在国内经过实际的项目验证，各个行业领域都有成熟稳定的客户案例。

支持SOA标准：
遵循SOA设计原则和技术标准，能够构建标准的企业服务总线 平台，提供松耦合模式，将业务逻辑和应用逻辑、数据逻辑等分离开， 提供一个满足企业的应用集成和信息调解需求的解决方案和产品。

支持最新Web Services标准，包括SOAP 1.1/1.2、WSDL 1.1、MTOM/XOP、WS-I Basic Profile 1.1等， 支持Web Services自有的安全性WS-Security和寻址功能WS-Addressing，可以实现Web Services 同步和异步不同形式的调用。

*灵活的消息路由方式，支持基于消息内容的处理和路由；
而且 还可以执行一系列方式的消息交互，包括了过滤、充实、监视、分发、关联、拆分（一对多）和合成（多对一）等。

*标准XML数据的格式转换，并且可以通过图形化映射组件、XSLT、客户化Java程序等多种方式实现转换功能。

*非标准XML数据的格式转换，实现XML消息格式和其他数据格式之间的映射，包括了JSON、C Record、JMS、TDS分隔符、平文本、行业专有数据格式等多种格式，同时也要支持自定义数据格式。

易于使用和开发：
软件提供便捷的安装和部署模式，提供友好的安装和部署界面。

提供中文的安装文档和使用手册。

系统安全：
提供多种安全机制，用户级别的认证、授权。

总体要求：
支持部署在所有主流Windows、Linux、UNIX平台；
客户端需支持AIX、HP-UX、Solaris、Windows、Linux等。

支持各种数据库平台（包括DB2、SQL Server、Oracle、Informix、Sybase等）。

支持各种类型的磁盘阵列（SAN，iSCSI，NAS等）、磁带机和虚拟带库，支持冗余的备份设备；
备份策略支持每周全备份，每天做增量备份，保存周期可以自由设定，支持任意时间点恢复。

章节1.2.1.1 章节1.2.2.2. 章节1.2.2.3. 有详细描述 无偏离 1.7. 所投项目的安装、调试、验收方案 1.7.1. 安装与调试 系统安装 根据系统安装手册中的步骤来执行系统安装：
确认硬件设备与网络环境已完备 对硬件设备与网络环境进行需要的配置 安装系统基础软件：包括操作系统，数据库，及必要的系统服务和相应的系统补丁。

配置系统参数和所需的系统服务，安装软件所需的底层框架。

安装Web应用程序和后台服务程序。

导入数据库初始化数据。

配置应用系统基础参数。

系统调试 系统安装部署完成后，进行基本的试操作，确认系统是否能正常运行，具体步骤如下：
测试网络环境是否通畅 测试系统底层服务是否正常工作 访问系统地址，进行试操作，确认系统可正常运行 发送和录入测试数据以验证系统正常运行。

在系统调试过程中，我公司将结合双方确定的需求说明书，对于未达到规定要求的部分，我公司将无条件调整、修改，以达到规定要求。而对于需求说明书没有明确说明的或在调试过程中业主提出的有别于需求规定要求的功能修改，我公司将本着“实事求是，认真做事”的原则，和客户充分沟通，共同寻找可行的修改方案。

试运行 经过系统联合调试和用户培训后，系统即进行试运行阶段，由于本系统的特殊性，在功能正确性、稳定性、系统性能、多用户并发负荷能力及其它相关方面都有着很高的要求，所以试运行是一个非常重要的阶段。试运行阶段将充分和全面地验证系统，并修复所有发现的问题，试运行结束后，将对试运行情况进行分析，以确定系统是否可以验收并正式上线。

为了保障系统能及早正式使用，试运行期间将按照以下内容执行，确保系统得到充分的验证和发现的所有问题都能得到修复：
试运行开始后，我公司将派技术支持工程师常驻现场，机动执行，有问题及时修复。

业主组织一定数量的用户对系统进行全面试用，确保使用的范围覆盖整个系统，发现的问题反馈给现场工程师解决。

如现场工程师不能解决问题，我公司将及时指派技术专家到场解决。

用户试用的同时，我公司还将在公司内部组织测试小组继续全力进行系统测试。

所有发现的问题都将在最短的时间内得到修正，具体为当天发现的问题能解决的当天解决，最晚不超过两天解决。

所有发现的问题及解决结果都将归入《软件试运行问题跟踪表》，便于问题的解决、确认与追溯。

试运行结束后，将形成《软件试运行报告》，对软件的功能、质量、性能、可靠性、易用性及其它相关方面进行全面和客观的评估，确定软件是否可以验收并正式上线。

1.7.2. 验收和交付 验收 我公司全部完成本项目程序开发、相关数据转换、用户操作手册和系统测试后，向客户提交相关工作成果、报告或相关文档，申请第三方测试。

系统的测试标准由买卖双方根据合同内容、系统业务需求文本、系统需求规格说明书等内容协商制定。

系统开发完成、卖方自测运行正常，由卖方提出书面系统测试申请。提交测试的系统应是成熟产品，并提交相应测试文档。买方组织的测试仅对系统的需求符合程度、技术状况、工程质量等给出测试结论。

系统测试工作完成后，卖方以书面形式提交系统验收申请书。

系统验收合格后，买方按照本合同规定的验收合格相关的付款条件，支付卖方相应款项。系统验收不合格时，卖方应负责修改系统，并在达到验收条件时，再次向买方提出书面验收申请。因卖方原因导致系统验收不合格产生的系统建设工作成本，由卖方承担。

交付 我公司按照CMMI3要求分阶段提交项目成果物。

项目阶段 工作任务 文档名称 提交频率 项目前期 项目开发总体计划 《项目总体计划》
《项目计划报审表》
开工流程审批 《项目计划书》
《项目进度计划》
《项目质量保证计划》
《开工令》
《开工申请》
系统实施阶段 需求调研 《需求调研计划》
需求分析阶段 《需求规格说明书》
《需求规格说明书评审报告》
《监理评估报告》
系统设计 《系统设计报告》
《监理评估报告》
测试计划安排 《测试计划》
数据库设计 《数据库设计报告》
编码阶段 《编码规范》
《单元测试报告》
测试阶段 《系统测试用例》
《系统测试分析报告》
《用户手册》
《部署手册》
系统验收阶段 系统试运行 《试运行计划》
《试运行问题修正列表》
系统培训 《培训计划》
《培训PPT》
《培训签到记录表》
竣工验收 《竣工验收申请》
《竣工验收文档清单》
《项目总结报告》
《项目验收意见表》
过程文档 项目周报 《项目周报》
项目例会 《会议纪要》
项目成员变更 变更申请 1、将新成员履历及项目任务提交给监理方审查通过后交业主方审批 2、对离开项目组成员任务交接情况交监理方审查通过后交业主方审批 我公司将向业主提交以下成果：
软件成果 **平台；

文档成果：
序号 阶段 产出成果 介质 1 准备阶段 《实施计划》
纸介、电子 2 调研安装部署阶段 《用户需求分析报告》、PRD文档（包括软件及硬件）
纸介、电子 3 测试阶段 《测试报告》
纸介、电子 4 上线阶段 《保障措施和应急预案》
纸介、电子 5 交付使用 《用户操作手册》、《软件清单》，可正常使用的软件 纸介、电子 6 验收阶段 《项目总结报告》
纸介、电子 7 售后服务 《售后服务规范》
纸介、电子 1.8. 运营服务方案 1.8.1. 平台的运营点和运营模式 为企业持续提供电子商务服务、政务服务、公共服务、沟通服务、咨询服务，在运营期间不断优化服务体系建设，不断丰富服务内容。从IT视角出发，将从信息类、业务类、交流类与管理类四个维度对服务内容进行运营。

信息类服务，针对服务栏目涉及的资讯内容进行采集、编辑和发布上线，针对企业想了解的政府政策类信息、产业动态类信息、行业指导类信息进行采集发布与主动推送。

业务类服务，针对服装纺织行业涉及的政务、公共服务和社会化服务内容和资源，提供从业务分析与产品设计工作、产品发布与管理工作、服务请求的受理与反馈工作、到服务的升级和优化工作等全生命周期服务。

交流类服务，组建线上和线下的各种关系并组织各种社交类活动，为企业提供沟通协作平台，有利于企业形成不同的圈子，强化进一步促进行业同盟组织建设，强化企业间协调合作。

管理类服务，在符合政府政策法规的基础下，将按照市场需求有偿提供服务。如：数据分析及金融投资等增值服务，向平台用户（如投资机构、社会服务机构）或者第三方提供数据信息（如人才分析报告、企业分析报告等）。

一条符合政府、企业及其他相关单位，多方共赢的，可持续发展的商业模式。

运营模式是为保障各服务的正常运行而为企业提供的客户服务，主要以热线电话方式开展。每年安排专业服务人员，依托客户服务知识库，通过互联网和热线电话等渠道向企业提供客户咨询、投诉和建议服务、服务满意度反馈服务、问题处理与回访服务。通过客户服务工作，快速了解用户的服务需求和投诉，及时解决存在的问题和意见。

1.8.2. 运营平台的设计 **平台的运营体系总体框架包括服务渠道，运营服务内容，运营服务参与者，运营服务平台，运营服务保障五个方面。标题中的运营平台只是运营体系中一小块内容。

运营体系大致框架如下：
渠道 服务对象 和渠道 服务内容 运营服务平台 运营参与者 运营服务保障 对象 企业 个人用户 政府 电脑 手机 自助终端 服务商 …… 呼叫中心 …… 电子商务 商品发布 商品交易 政务服务 许可办理 税务办理 法律服务 金融服务 公共服务 信息服务 政策新闻 培训文档 政企沟通 行业沙龙 投诉建议 商家信用 评级权限 商家评级 用户管理 内容管理 CRM 支付管理 综合管理 需求方 服务提供商 平台运营方 企业用户 个人用户 管理制度 业务规范 培训体系 技术保障 服务资源 服务对象和渠道：服务对象主要是指平台产品所服务的对象人群；
而服务渠道主要包括电脑PC端，手机端，呼叫中心（服务热线），后期或会拓展更多的企业自助终端等渠道。

服务内容：主要是指平台所涉及的几大服务类型，初期将会分为六大类。包括：电子商务，政务服务，公共服务，信息服务，政企沟通，商家评级。其大分类下的子分类仍有很多项目待拓展，上图仅为参考。

运营服务平台：主要是指为运营团队提供的，能够协助平台正常运作的后台操作系统。包括：用户管理，内容管理，CRM，支付管理，综合管理等其他项目。运营服务平台也将会根据具体业务的拓展不断丰富和完善。

运营参与者：上一章节已有说明，主要是指平台运营方面所涉及的角色对象，包括：需求方，服务提供商，平台运营方，企业用户，个人用户五大类。

运营服务保障：主要是运营工作正常运行所必备的保障体系。包括管理制度，业务规范，培训体系，技术保障，服务资源，还有上图中未列举的可能包括部门协同等方面。

1.8.3. 运营流程的描述 运营流程，指的是为运营方案的实施人员提供明确的指导方向和操作方法。也就是领导者在制定计划的过程中要考虑到运营流程中可能出现的问题，而制定一份能够将运营战略和人员及结果联在一起的运营方案。

下图为一般网站运营流程图：
对于**平台来说，涉及到运营流程的主要有两大块，分别是首发阶段流程，正式上线后流程。

1）首发阶段的流程：
商务确认 接入 运营准备 推广准备 上线日期 上线资源 论坛搭建 新闻预热 正式上线 （1）
商务合作，此次突出重点便在于如何争取产品利益，实现产品价值；
在此环节，一边接入软件开发，一边分析渠道各资源推荐的要求与行政。

接入，按照平台产品首发阶段的产品需求进行软件包的接入。

运营准备，运营在首发阶段是最繁复的一个工作步骤，需要多方资源与部门的配合。必要时候，需要组织多方会议进行运营细节项目的确认。

推广准备，市场推广很多时候是和运营是联系在一起的，需要在运营工作事项以及产品首发的信息确认之后，开始联络市场以及媒体渠道，进行多方面的推广，打开知名度。

2）正式上线后流程：
方案确定 职责分工 落地执行 监测效果 复盘原因 优化启动 正式上线后，运营的流程相对明确。运营工作需要整个运营团队的支持与配合。

此次的运营流程更多的是对阶段性运营方案的不断复盘与优化，对阶段性的运营目标负责。