投标技术方案建议书模板

XXXXXXXXXX2013.102013.10目录目录 1第一部分项目综述 21. 项目目标 22. 业务功能需求 32.1 业务需求概述 32.2 具体需求 3第二部分项目需求分析 41. 移动后台服务架构 42. 企业移动应用开发平台 4第三部分项目总体设计 51. 项目总体设计描述 51.1. 产品说明： 51.2. 方案设计描述： 52. 项目方案设计优势 62.1. 平台技术的统一性 62.2. 方案的优势 6第四部分技术实现方案 71 移动后台服务架构（MobileBackendService） 71.1. 架构的必要性 71.2. 架构逻辑拓扑 71.3. XXXXX架构技术规范 72 部署架构 8第五部分项目实施计划 91. 人员配置方案及工作量估算 92. 项目实施进程规范 9第六部分技术支持与售后服务 101. 乙方技术支持承诺 101.1. 故障响应处理流程 111.2. 现场日常维护流程 111.3. 维护性开发流程 111.4. 巡检流程 112. 售后服务承诺 123. 新需求服务 12第七部分其他说明 131. 保密 132. 知识产权转移 133. 培训流程 134. 培训评估和管理 13第一部分项目综述项目目的本项目作为XXXXX的初始阶段，重要目的是打造XXXX的能力，涉及技术的、应用的和团体力量的，因此该项目的重要目的涉及：一种平台——搭建含有服务整合（系统集成）、移动应用开发（MADP）、移动应用运行监控/运行分析/顾客体验优化、移动应用基础技术能力框架、移动设备和应用管理（MDM&MAM）、高扩展性和高可用性的公司级移动应用平台；一组B2E应用——提供涵盖XX主营核心业务范畴、一站式、对旅客有用并易用、覆盖主流移动操作系统的移动App；针对XX一线服务人员和运行保障人员、提供服务信息和生产信息及时获取及传递的公司应用；一系列B2C的支撑：为新版B2C应用整合后台服务，建立API接口，支撑B2C各项新功效。一支团体——打造含有移动应用规划设计，技术研究及应用实施、测试和系统运行分析及优化的专业技术能力团体；业务功效需求业务需求概述项目需求普通是对现在问题的分析导出的，通过前期的调研和观察，我们能够提炼出以下重要问题：解决现在XX多个B2C移动应用彼此独立、风格迥异、数据孤岛及业务系统竖井建设的问题；解决移动应用快速交付的问题；现在，不管是市场销售营销，还是生产运行或公司管理，各业务领域均提出移动化的规定；同时，随着大家对移动应用的依赖增强，提出移动应用的需求和改善建议将越来越多和频繁，且不管是时间进度规定，还是质量和顾客体验规定都将越来越高；具体需求通过对问题的梳理和分解，有四条业务需求和一条技术需求以解决现在面临的问题：支撑新版B2C应用，整合XXX各后台业务系统的服务，提供原则的API接口。第二部分项目需求分析我方根据“XXX公司级移动应用平台RFI”文档阐明，将本次项目需求分析分为下列几类：移动后台服务架构参考并结合XXX现有后台系统特点，对即将进行或开发的移动平台进行整合。其中涉及：公司服务总线（ESB）调用、移动后台服务整合、移动后台服务监控、移动后台与ESB的同时、移动后台API原则的建立、为其它应用提供API。最后成为一种面对服务的架构-SOA原则。公司移动应用开发平台解决移动应用中的开发问题，这涉及到：多个类型设备、多个操作系统及版本、大量应用开发及维护、统一应用风格、应用界面适配等问题。因此，需要通过一种跨渠道的移动应用开发工具来实现其最后成果。以缩短开发周期、减少开发成本，真正做到“一次代码编写、随意运行”的目的。达成灵活开发、快速布署的目的，以适应灵活的业务需求变化。第三部分项目总体设计项目总体设计描述根据以上项目需求分析，我方将采用美国XXX产品解决方案、美国产品解决方案，来协助客户建立并完毕该项目。产品阐明：XXX其重要致力于开发与移动有关的应用技术，是专门从事开发、销售、服务和交付平台。其核心开发团体由经验丰富的架构师和开发人员构成，含有专业的知识，并开发高性能的分布式在线系统、移动设备编程、网络安全产品、以及其它复杂的软件系统。涉及全部重要的移动设备操作系统、服务器功效的安全软件、网络应用集成和数据库的开发。方案设计描述：该方案重要分为两个核心部分：移动后台服务重要负责各个业务系统的衔接，多个后台服务服务的调度、服务整合、原则统一、为其它应用提供服务接口，同时与客户原先的后台系统同时等工作。公司移动应用开发平台该功效将重要解决在移动应用开发时所碰到的诸多问题。众所周知，随着移动应用种类的多样性、移动应用实施方式的多样性、移动操作系统的多样性、以及移动应用设计、布署、维护等问题将呈几何级数的增加，这会大大的消耗开发、管理、维护效能，而应当采用一种“一次代码编写、随意运行”的工具或平台，来简化应用开发过程中碰到的全部问题势在必行。项目方案设计优势平台技术的统一性众所周知，近些年移动应用正在被公司大量的开发、布署，并在公司的运行中起到至关重要的作用。相较于过去的公司应用而言，移动应用品有其本身的诸多特性，如从设计、定义、开发、测试、布署、管理等诸多环节，这不仅给公司的运行提出更高的规定，同时对移动平台本身也提出诸多规范。方案的优势后台架构优势传统的后端集成办法，开发人员的任务是理解和精心安排任意数量的内部或外部系统之间的细微差别和数据合同。不管是公司级应用：如SAP、Oracle、Salesforce，或是公共应用：如Yammer、Facebook、LinkedIn都需要极力建立安全通路，从而规定集成开发人员必须考虑服务的精确性。XXX所提供的管道，优于上述这些更耗时，更加错综复杂的细节流程。通过提供一种途径，基于云的数据存储，并提供了一套统一的基于RESTful的API，MBaaS提供一种安全且含有成本效益的后端系统的基础架构，同时建立核心功效，如认证、推送告知、同时服务、存储和第三方的集成。其成果是一种更安全，更有效的办法来管理后端的开发：开发平台优势对于XXXX的价值基础体现在：从一种单一的JavaScript代码库实现，针对布署和维护全部的移动应用，不会产生任何后续编辑。一次代码编写、随意运行的平台（WriteOnce,RunEverywhere）。完全自给自足尽量广泛的移动到移动客户和代理商大幅缩短产品上市时间大大减少需要保持现有的布署时间和资源熟悉的脚本环境，能够很容易地通过你的员工采用更低的总拥有成本最快的投资回报第四部分技术实现方案移动后台服务架构（MobileBackendService）架构的必要性对于一种能够提供真正有价值移动应用时，其应用的后端必须安全地与任何数量的公有云服务或公司系统的集成。对于开发者来说，其重点始终是发明卓越的前端体验，这个过程将会逐步的消耗其有限的资源。如何让开发者在开发后台而不牺牲应用的功效，同时确保应用的安全性、质量？移动后端作为一种服务，称为XXXX，解决方案已经能够满足这一需求。作为一种预构建，云布署基础架构，XXXX为开发者提供了一种服务API的交钥匙解决方案，并集成他们的应用程序的后端。XXXX能够用作应用的后端，并为前端提供服务，涉及：桌面端，Web和移动应用程序等任意应用，以及越来越多的用于物联网的强大应用。其重要解决以下问题：采用智能手机，平板电脑和不停发展的技术，如可穿戴设备的快速增加。技术堆践和服务正在变得越来越复杂。公司需要快速，高效的应用开发和布署。应用安全和性能是对于公司而言同样重要。公司需要能够快速，可靠地进行扩展。架构逻辑拓扑XXXXX架构技术规范布署架构XXXX是基于J2EE架构布署的原则应用服务器。该原则的实施布署采用TomcatWeb和应用程序服务器功效，其使用的JBossJMS队列的消息服务。其它重要服务器组件是Memcache，同时提供会话状态和ApacheDerby数据库优化数据访问。XXX移动服务器能够实现布署在任何符合J2EE规范的应用服务器上，并且能够与任何JMS提供者想配合。其执行后端数据库是MySQL。布署体系构造的逻辑视图，以下图所示。使用者通过移动设备访问应用服务器；与内存缓存服务器为现有会话进行应用检查（如果没有则新建）；应用首先会检查与否有存在于本地缓存的设备信息。如果没有找到，那么会从设备数据库中进行信息加；应用连接到公司数据源（如果服务调用涉及其它本地页面也同样被送达）；在返回时更新的状态存储在内存缓存服务器中。与此同时，错误或性能指标都放在JBoss的消息队列中；报告代理从消息队列中读取消息；报告代理存储消息到报告数据库中；第五部分项目实施计划人员配备方案及工作量估算项目参加人员状况以下表所示，在项目实施过程中可能根据实际状况进行微调，但项目核心组员(项目经理、高级程序员)不会调节。人员构成人员数量项目经理XX系统架构师XX高级程序员XX程序员XX软件测试人员XX项目实施进程规范项目启动任务责任阐明责任方项目启动动员大会1、介绍项目的状况，明确任务。2、时间进度安排、资源调配；实施方甲方安排需求调研1、与客户商定调研的时间、方式、部门等；2、准备调研提纲；实施方与甲方系统后台设计任务责任阐明责任方后台设计计划制订1、重点讨论实施方后台设计规范制订1、参考甲方设计规范规定针对该项目制订设计规范v1.02、设计规范贯彻实施方后台逻辑设计1、分析需求分析报告v1.3和系统设计报告v1.0的匹配2、形成后台逻辑设计规范v1.03、送交内部评审实施方后台逻辑设计规范评审1、对后台逻辑设计规范v1.0提出改善意见2、形成后台逻辑设计规范v1.1甲方实施方后台接口设计原则1、根据系统最后运行模式，调节接口设计2、结合后台逻辑设计规范v1.1，及后台接口原则，形成后台逻辑设计规范v1.2实施方接口标精确认1、实施方与甲方一起评审后台逻辑设计规范v1.2，最后形成《后台逻辑设计规范v1.3》并对项目需求变更的解决双方的商定，形成备忘录（《需求变更备忘录》）甲方实施方应用需求分析任务责任阐明责任方需求调研根据项目规划到客户现场进行需求调研实施方需求整顿根据调研状况，整顿出需求分析报告v1.0实施方需求报告内部评审甲方对需求分析报告进行内部评审，形成需求分析报告v1.1实施方需求报告客户评审实施方与甲方一起就需求分析报告进行评审，初步明确项目的具体范畴和功效，最后形成需求分析报告v1.2实施方甲方需求报告确认实施方与甲方一起拟定需求分析报告v1.2，明确项目的具体范畴和功效，形成《需求分析报告v1.3》；并对项目需求变更的解决双方的商定，形成备忘录（《需求变更备忘录》）实施方甲方第六部分技术支持与售后服务乙方技术支持承诺将对本次项目上线后，按合同商定时间内进行技术支持与售后服务，其内容涉及：故障响应解决流程现场日常维护流程甲方提出服务请求，现场服务工程师对服务请求分类，拟定优先级别，并登记到维护日志中，全部问题按照事件号进行跟踪。服务工程师进行问题现场解决，对于A类问题要能够紧急解决，如果超出4小时需要将问题进行升级到甲方高级经理，由甲方协调资源解决，B/C类问题按照服务规定执行；服务工程师每天监控系统运行状况统计到服务日志中，每天进行数据备份并统计到服务日志中。服务工程师定时填写工作周报，报甲方负责人。服务工程师每月报服务月报，报给甲方负责人，甲方对服务月报要签字确认。维护性开发流程甲方提出并按照《维护性开发申请单》填写需求申请，提交现场服务工程师。现场服务工程师将《维护性开发申请单》提交甲方，由甲方会同乙方进行方案、工作量和计划评定，正常状况下24小时反馈给甲方（工作日内），碰到特殊状况双方协商。甲方负责人进行审批，审批同意后，由项目经理下任务单按照计划进行开发。由现场服务工程师或开发工程师提交成果，甲方进行确认。维护任务关闭。维护性开发由维护工程师登记维护台帐。巡检流程由现场服务工程师与甲方拟定巡检计划，提交甲方审批。甲方协调资源。现场巡检。提交巡检报告。售后服务承诺乙方针对本项目，成立本地化服务中心，为甲方提供及时的响应和服务。乙方承诺，项目上线后的时间内（根据合同而定），提供系统维护和升级服务。项目经理每月向甲方提交一份系统运行状况和分析报告。继续为甲方提供长久信息化咨询服务。新版本公布后，承诺在及时向甲方通报，并接到甲方请求起一种月内提供并安装新版本；新版本公布后，同时提供老版本的技术支持。新需求服务对于新功效需求、新业务需求的开发将按照人天进行计算，并参考投标方案报价表。甲方提出并按照《新功效开发申请单》填写需求申请，提交乙方服务工程师。乙方服务工程师将《新功效开发申请单》提交甲方，由甲方会同乙方进行方案、工作量和计划评定，正常状况下24小时反馈给甲方（工作日内），碰到特殊状况双方协商。甲乙双方签定新合同。甲方负责人进行审批，审批同意后，由项目经理下任务单按照计划进行开发。由现场服务工程师或开发工程师提交成果，甲方进行确认。新功效开发任务关闭。第七部分其它阐明保密本项目所涉及到的全部XXXX背景资料、公司制度和政策、人员背景资料、研究原始统计、工作流程及分析成果，项目期间及项目结束后，未经书面确认，不会向第三方提供或用作其它商业用途。知识产权转移我司承诺项目的最后研究和开发成果的知识产权归XXXXXX全部。最后的软件源码、软件的设计文档及撰写的研究报告将在指定的交接日之前提交给XXXXXXX。培训流程环节培训准备阶段培训实施阶段培训评定阶段1理解培训需求实施授课质量评定2拟定培训方略实施服务确保学员测试3编制培训方案实施关心服务跟进培训需求4安排培训诸事宜质量跟踪调查双方沟通培训评定和管理在培训实施过程中，实施方将运用调查问卷形式实施“课程首日调查”和“培训中调查”，以针对出现和可能出现的问题进行及时有效的调节和解决，确保良好的培训效果。具体执行方式以下：通过与讲师沟通，根据技术人员的适应性对课程内容做出调节；通过与技术人员沟通，使得讲师的课程内容更加富有吸引力和实效；通过收集的调查问卷对课程内容和服务环节的其它内容做出调节，技术人员的满意度。出师表两汉：诸葛亮先帝创业未半而中道崩殂，今天下三分，益州疲弊，此诚危急存亡之秋也。然侍卫之臣不懈于内，忠志之士忘身于外者，盖追先帝之殊遇，欲报之于陛下也。诚宜开张圣听，以光先帝遗德，恢弘志