IT项目实施与管理方案投标书Word文件下载.docx
《IT项目实施与管理方案投标书Word文件下载.docx》由会员分享，可在线阅读，更多相关《IT项目实施与管理方案投标书Word文件下载.docx（49页珍藏版）》请在冰点文库上搜索。
设计标准包含,但不限于，应用系统性能,对升级影响,应用系统维护,和数据模型相关问题和常规最好做法。
1.1.1.4项目开发阶段
在开发阶段，项目团体将开发应用系统,提供任何需要扩展功效和外部接口,为用户部门布署和连续支持处理方案做准备。
项目团体配置应用系统、全部需要扩展功效和外部接口。
关键交付技术结果有功效测试和系统测试。
这些步骤整合和测试活动愈加好地确保介入系统功效和用户组织业务需求协调一致。
教授服务顾问应该进行一个配置检验，来评定全部经过用户化改造实施文档。
在这个检验过程中,全部这么文件全部将被评定，以使应用系统性能,应用系统升级,系统维护工作量和常规最好实践最优。
1.1.1.5项目验证阶段
在验证阶段,将完成新系统全部功效测试。
这个阶段分两个部分。
第一部分,项目团体进行一个对有生产数据应用系统全部功效进行测试。
在这个检测完成后,关键用户然后进行一个代表性验收测试，以确保系统正确地处理用户需求。
一旦全方面功效测试结束,将进行一个使用系统工具，严格性能测试。
这一阶段关键交付技术结果为用户验收测试和性能测试结果,包含性能,容量和寿命测试。
适时性能调整审计，可确保整个企业架构环境性能最好。
在这个检验中,教授服务将主动性地识别任何性能问题,这么将降低在运行时出现问题风险，增加系统生产切换信心。
在有技术用户经理参与情况下,可实施一个实施准备就绪检验，以确定系统是否能够布署了。
这个实施准备就绪检验是用来评定实施风险,技术上是否准备停当和布署策略。
此时，应该召开管理人员定向协调研讨会，将责任转移给一线职员，这些职员将开始支持业务步骤和技术推出。
在管理人员定向协调研讨会上,项目团体和用户管理团体一起工作，以取得维持资助人内部负责，并把正确信号传达给组织其它组员。
1.1.1.6布署上线阶段
布署上线阶段内第一个活动是实施一个投产导航。
这个导航是被用来测试全方面生产布署,而且在用户业务环境中一部分部门中进行，比如一个地域或一个区域。
生产导航在机构业务环境中部分部门里，为用户提供全部系统特点。
来自于生产导航反馈信息指导整个布署。
一样在这个过程中,教授服务顾问应该进行生产准备就绪检验,经过主动地识别任何可能造成布署中止和使实施系统处理方案技术优点打折扣全部问题，来帮助系统顺利推出。
此时,要召开步骤实施研讨会，布署步骤最优实践，来优化人,步骤和技术配合。
目标是在用户全部一线机构中，使用变革和销售步骤最好实践，使最初赞助人和行政领导团体完全满意。
1.1.2项目管理方案
1.1.2.1项目管理概述
项目管理包含在项目生命周期中协调全部项目管理知识领域所包含过程。
它确保项目全部组成要素在正确时间结合在一起，以成功完成项目。
进行项目整体管理时，肯定包含项目标范围、质量、时间和成本管理和人力资源、沟通、风险管理等各个步骤，项目管理一个复杂工程，在此关键针对南京银行企业服务总线项目标项目进度管理、变更管理、沟通管理、质量管理、风险管理等相关策略进行描述。
1.1.2.2项目进度管理
经过项目进度管理最终明确项目开发阶段进度控制活动和关键步骤。
Ø
项目经理：
◆依据软件开发计划编制具体阶段开发计划和每项任务边界时间，并召集过程控制人员、专题小组责任人审核该计划；
◆审核各专题小组拟订每项任务日程安排；
◆检验和控制项目进度；
◆制订进度变更计划；
过程控制人员：
◆帮助审核具体阶段开发计划和任务边界时间；
◆监督项目进展；
专题小组责任人：
◆在听取小组组员意见基础上，拟订每一项任务日程安排；
◆负责检验和控制任务进度，并填写进度控制表；
◆负责制订任务变更计划。
1.1.2.2.1.进度安排步骤
项目经理依据项目计划，明确该阶段边界时间；
依据项目计划中任务PERT网络图，找出该阶段关键任务并深入分解、细化，在此基础上绘制更具体阶段任务PERT网络图；
拟订具体阶段计划；
确定每一关键任务边界时间；
召集各专题小组责任人审核拟订计划，并修改；
专题小组责任人确定任务日程安排；
对于大型或时间要求严格项目，进度安排应以天为单位；
征求小组组员意见；
交由项目经理和过程管理人员审核。
1.1.2.2.2.进度控制步骤
项目经理和过程管理人员根据阶段PERT图，标志阶段中被跟踪关键任务和里程碑，并将之通知专题小组责任人；
专题小组责任人根据任务日程安排，确定任务完成期间关键时间点，并将之通知专题小组组员；
专题小组责任人常常和组员沟通，了解任务进展；
并定时检验，填写任务进度表和下期计划表，立即发觉问题；
项目经理定时组织专题小组责任人，召开项目状态会议，了解任务进展，立即发觉问题；
项目过程管理人员参与会议或了解会议统计；
专题小组责任人在实施中发觉延迟，分析原因：
◆人员担心：
组内调配不了，找项目经了处理；
◆事先预估不足：
调整任务日程安排；
若处理不了，通知项目经理，会同过程管理人员，调整具体阶段计划；
假如阶段内消化不了问题，则项目经理根据《配置管理程序》，变更软件开发计划。
1.1.2.3项目变更管理
针对项目变更管理组织变更控制小组，由项目组经理、项目管理部人员、项目总监、用户、用户部组员组成，考虑并授权项目标重大修改（修改工作量超出一周）。
而项目经理负责项目标通常修改决议（修改工作量在一天以上，一周以内）。
变更管理活动包含修改请求、评定、经过、实施和跟踪。
变更管理关键点以下：
变更同意权限：
变更控制组负责讨论和决议项目标重大修改；
项目经理讨论和决议通常性修改；
并报项目管理部立案；
修改审批程序：
依据不一样地点用户有不一样审批程序。
1.1.2.3.1.变更状态登记
变更状态登记活动统计和汇报多种配置项状态，统计在项目生命周期中任何管理信息和历史信息。
包含：
全部变更请求表、全部变更汇报单、全部变更统计。
由项目管理人员存取状态登记。
变更状态登记目标是为了控制软件需求发生变更时处理过程，使之根据制订规程进行，以确保软件需求一致性。
1.1.2.3.2.变更管理步骤
用户方或高伟达提出变更请求，填写变更申请表；
将变更申请表交本项目组项目经理；
双方项目经理（或项目经理授权人，必需以书面形式确定）共同审阅，评定该需求变更技术有效性和对本项目标影响；
假如审阅同意该请求，则双方项目经理（或项目经理授权人，必需以书面形式确定）签字确定，变更申请表将被贵行文档管理员登记后，转发给高伟达。
假如未获同意，其原因将反馈给该需求变更提议人；
高伟达在收到经审阅同意需求变更申请后三个工作日内，发给贵行一份书面确定书，确定其收到，并给出分析和实施变更所需时间和工作量估算；
依据请求变更程度和复杂度，高伟达深入进行成本评定，若不需成本，则直接实施变更工作；
若需要增加成本，则以书面形式通知贵行文档管理员，贵行管理员登记后，根据项目管理措施中项目变更管理步骤处理。
1.1.2.4项目沟通管理
南京银行ESB项目是一个技术和业务互动项目，项目标成功很大程度上依靠于业务人员参与程度及技术人员对业务需求透彻分析，这就要求技术和业务人员确保充足交流，制订并遵守项目内部沟通管理计划。
1.1.2.4.1.项目沟通形式
依据本项目标组织形式及特点，我们提议采取以下多个方法沟通形式：
序号
沟通形式
责任人
沟通对象
内容
频度
输出文档
1
领导小组和项目组联络会议
领导小组组长
项目管理组、领导小组
项目实施状态汇报，问题汇报、提议方法并要求得到回复，项目组进行问题回复和传达领导组指示
每两周1次
会议纪要
2
总体组会议
项目总监、项目经理
总体组组员
总体组内部工作分工协调、部署，分析各专业组工作情况和提出问题决议，为和项目组联络会议作准备
每七天1次
3
专业组组长会议
各专业组组长、总体组
专业组进行进展汇报、问题汇报及提议方法；
总体组布署工作安排，决议，协调，分析进度、问题等
会议纪要*
4
专业组内部会议
专业组组长
专业组组员
专业组内部交流会议，任务部署、信息交流、问题讨论等
每2～3天1次
/
5
动员大会
总体组、领导小组
全体人员
在全体项目组员范围内宣告项目总体和阶段目标，回顾前阶段结果，激励士气
项目各阶段开始
6
简报
项目助理
反应项目动态，包含进展情况、问题及处理方案，本周工作结果、下周工作关键等
简报*
7
小组工作周报
总体组
反应各个专业组每七天实际工作情况及结果，包含依据计划实施情况和进度偏差。
小组工作周报*
8
个人工作周报
反应个人每七天实际工作情况及结果，包含依据计划实施情况和进度偏差。
9
电子邮件
当事人
需讨论问题非正式书面交流
按实际需求
10
日常交流
需讨论问题非正式口头交流
备注：
1、“责任人”为各类沟通形式组织者；
2、“沟通对象”为需参与各类沟通项目干系人；
3、“输出文档”为各类沟通所产生书面文件，由各类沟通“责任人”或其指定人员制作并派发“沟通对象”；
4、“输出文档”一栏中有“*”记号文件需由项目办公室作为项目文件进行存档。
1.1.2.4.2.会议管理制度
项目开始进行以后，要有效地控制项目，需要在各个关键时刻召开关键会议。
关键会议关键内容是总结上一阶段工作，分析问题、提出提议，并介绍下一阶段关键任务和目标，使各相关人员全部能做到心中有数，明确努力方向。
关键会议也是协调各不一样小组之间人员和工作任务关键手段。
除关键会议外，在项目进行全过程中，应定时召开例会，会上关键介绍项目进展情况，检验进度、是否存在问题等，会议时须做具体会议统计并在会后报送全部项目相关人员。
关键项目会议步骤要求以下：
会前准备：
◆做好准备工作，如明确会议目标和会议议程等；
◆把会议中要求讨论材料事先下发给开会组员；
◆提前两天通知各位和会组员；
◆准备会议环境、会议用设备等；
会议之中：
◆会议组员按时到会；
◆按会议议程逐项进行；
◆严格控制会议时间；
会后跟踪：
◆会议决议落实和检验。
1.1.2.5项目质量管理
为确保项目顺利实施及系统质量，必需在项目管理过程和项目实施过程上加大质量管理力度。
经过高伟达企业实施成功案例，我们深深体会到“质量是计划出来”这一现代质量学见解所蕴含深刻道理，所以，我们在项目开启及项目进展各个阶段全部会仔细制订各项工作计划，严格根据审核经过计划进行项目控制。
针对本项目，我们提议从QA及QC两方面保障项目标顺利实施，具体质量保障方法以下：
1.1.2.5.1.质量确保
本项目将设置质量确保小组，由南京银行和高伟达企业各出一名人员担任QA角色，其工作任务是依据项目总体组制订质量查对单，在项目进展过程根据质量查对单逐项审核项目是否根据计划约定实施和控制，并直接向南京银行相关领导汇报项目实施质量情况。
1.1.2.5.2.正式评审
依据本项目标特点，本项目中将对项目计划、软件需求规格说明书、系统设计说明书、测试规格说明书、测试汇报等文档，组织南京银行相关领导、教授进行正式评审，方便审核系统开发中各阶段所产生过程文档，以确保文档内容和上一阶段所产生软件文档内容一致，而且符合使用者需求。
1.1.2.5.3.交叉审查
除项目要求正式评审内容外，本项目还将对各模块软件代码实施交叉评审制度。
各模块责任人应依据总体组制订代码质量审核清单，对所负责检验其它模块软件代码进行仔细审查，对代码质量不能经过交叉评审则必需进行返工。
整体软件代码交叉评审总量不能少于60％。
1.1.2.5.4.变更控制
为确保软件产品质量，开发过程将严格采取配置管理工具进行变更控制，其目标是确保最终软件产品能够符合业务需求各项要求，并对开发过程进行监控、汇报和提供咨询支持，它包含下面质量属性要求：
软件产品和需求、说明书和设计一致；
根据说明标准建立文档；
可测试和可维护；
被识别、管理、评审和测试；
当变更发生时可管理。
1.1.2.6项目风险管理
任何项目开发实施过程中全部会碰到多种风险，在各方面全部会碰到不一样规模风险，所以需要了解工程本身风险、技术风险、新产品风险、工程资源风险、工程过程风险等全方位风险原因。
经过对风险量化提供一个计划来管理预防风险，同时对于潜在风险也应该建立意外事件应急计划，使其在必需时能够以可控及有效方法作出反应。
✓针对需求风险，南京银行应把握系统建设起点要高、规范运作为系统建设基础工程、采取构件化技术进行应哟软件开发、采取B/S技术降低信息点维护成本方法规避需求风险。
✓针对合作风险，选择一个长久、上规模、含有成熟行业经验、项目管理规范、技术优异、职员有归属感、真正站在用户立场上考虑问题企业作为后盾，高伟达集团是能为您最大程度地控制合作风险。
✓针对资源风险，拥有健全组织和管理，在避免人员流动基础上，即使因个人原因必需离职时，高伟达企业也因其规范、体系化管理和产品架构而使项目基础不受影响或极少受到影响。
✓针对技术风险，高伟达银行业务系统拥有多个成功实践经验，含有和国外接轨理念和技术，同时拥有不停调整、更新技术体系、和参考标准体系指定规范质量标准并在实施过程中加强阶段评审，使因为技术原所以可能造成风险降低到最小。
除此之外，为预防操作风险，在南京银行本身加强制度管理基础上，高伟达还提供培训考试合格上岗及定时培训定时总结分析模式来规避这类风险。
1.1.2.6.1.风险管理内容
风险管理内容以下：
项目实施前和实施中对风险发觉、识别、上报、分析及风险责任人指定；
风险应对计划制订和实施（应对计划包含两部分，一是在怎样降低风险发生机率规避计划；
一是当风险不幸变成现实时，怎样应正确应急预案）；
风险状态监控和更新；
定时对项目风险进行统计、分类和总体结构分析。
1.1.2.6.2.风险管理中相关角色和责任
参与方
角色
职责
备注
风险识她人
项目相关任何人
汇报发觉风险，填写风险记录表描述风险，注明风险严重度、风险发生机率和风险分类
假如是项目相关人员，提交至项目经理，假如是项目管理办公室人员，提交项目管理办公室主任
项目经理
项目内风险管理责任人
在项目进行中，管理项目内风险并提供项目内应对计划
对于无法在项目内处理风险，审核风险记录表，并确定风险描述、风险发生机率、风险责任人和风险发生后应急预案
口头确定或书面认可上报风险记录表,将风险记录表发往对应部门
项目管理办公室
项目整体风险管理实施监督机构
在项目开启前，组织定义项目等级风险登记、评定和应对计划
在项目实施阶段，对项目报送相关风险记录表和应对计划进行审核，关键审核跨项目标风险、严重度为中或中以上风险和发生机率为中或中以上风险,提议整个项目标应对计划
依据对项目全社考虑，更改项目上报风险之严重度、发生机率和风险责任人
对于无法处理、风险严重度为中或中以上风险，负责上报项目总监
跟踪风险进展，对异常进展风险进行预警
定时统计分析项目风险，在项目周报和月报中提交风险统计情况
项目总监
风险管理最终决议机构
对重大风险，进行决议，给出最终处理意见
风险责任人
风险规避、应急预案实施责任人
填写风险记录表风险分析和行动计划
负责风险应正确实施、并汇报风险状态改变
1.1.2.6.3.风险严重程度
灾难：
会因为无法满足需求而造成任务失败，会产生错误造成进度延迟和预算严重超支；
严重：
会因为无法满足需求而造成系统性能下降，使得项目能否成功受到置疑，严重影响项目里程碑范围、交付日期和交付质量和会影响其它项目进展风险；
轻微：
会因为无法满足要求而造成次要任务退化，影响项目里程碑范围、交付日期和交付质量和会影响其它项目进展但不严重风险；
可忽略：
不影响或轻微影响项目里程碑范围、交付日期和交付质量风险，只是无法满足要求而造成使用不方便或不易操作。
1.1.2.6.4.风险状态
已提交：
风险识她人已填写风险记录表，完成了风险号分配、风险描述并有项目经理提交；
拒绝：
项目管理办公室认为风险导入人所提出风险不属于项目风险；
已完成计划：
风险责任人得到风险记录表后，对其进行分析并完成应对计划；
规避计划：
风险责任人正在依据应对计划规避风险；
风险已规避：
风险责任人已成功规避风险并得到项目管理办公室认可；
发生进入应急计划：
风险责任人未成功规避风险，风险发生，实施应急预案。
1.1.2.6.5.风险分类
本项目中，风险关键分为以下几类：
管理类风险
项目管理没有遵照项目管理制度、时间、岗位要求。
出现项目标风险。
资源类风险
因为人力资源、设备环境等原因产生。
比如，ATM设备没有驱动程序，无法进行程序调试。
业务类风险
业务风险关键表现在业务需求不清楚，变动频繁。
技术类风险
技术风险关键表现在技术架构不合理，各个子系统、服务渠道无法进行整合。
1.1.2.6.6.风险管理步骤
风险管理步骤包含：
项目开启前风险识别和防范步骤
在各项目开启前，应该由项目管理办公室指导各个项目提交其项目风险原因识别、评定和应对方法计划；
项目管理办公室依据各项目标风险识别计划，和其对项目风险了解，完成项目风险原因识别、评定和规避项目风险规避计划和制订项目风险应急预案；
项目管理办公室将相关风险应对计划上报项目总监审批；
将项目总监审批过风险应对计划提交给领导领导组审批；
审批经过风险应对计划由项目管理办公室公布归档；
在项目实施过程中由项目经理管理风险应对计划实施，项目管理办公室经过项目周、月报跟踪监督。
以下图示：
项目运行中风险管理步骤
在项目实施过程中，全部项目组组员全部有责任汇报进程中发觉风险原因，并汇报项目经理；
项目经理在确定其确为风险后，定义风险发生机率和严重度并指定风险责任人，制订风险一旦发生应急预案，并将其填写风险记录表上报项目管理办公室；
项目管理办公室审核风险发生机率、严重度和风险责任人并负责风险状态监控；
风险责任人负责编制风险应对计划，并定时汇报风险状态；
项目管理办公室负责发觉跨项目标风险原因，并主持评定规避计划和应急预案；
项目管理办公室将相关风险评定汇报和规避计划、应急预案上报项目总监审批；
全部发觉风险原因和审批经过对应风险应对计划由项目管理办公室公布归档；
1.1.3项目实施计划
1.1.3.1.1.项目组织架构
有效组织结构，是项目成功有力确保。
对于一个银行服务总线项目，除了考虑项目标有效管理，也要考虑SOA类项目标实施特点；
依据此次项目标范围和要求，项目标参考组织结构以下
1.1.3.1.1.1项目管理委员会
项目管理委员会负责监督并指导项目标实施进程，定时审核项目经理就项目进展实施情况书面汇报，对项目中存在重大问题做出决议，协调处理重大问题和突发事件，决定对项目经理任免。
项目管理委员会由南京银行高层领导和本企业高层领导共同组成。
1.1.3.1.1.2服务总线管理组
向项目管理委员会负责，在项目实施过程中进行服务标准和标准控制，在未来项目实施完成后，由这个组织管理和同意新服务公布和渠道系统接入。
同时负责制订企业实施SOA项目标总体计划，从企业级高度而非项目级参与项目管理。
服务总线管理组由南京银行架构师和本企业企业架构师共同组成。
项目实施完成后职责交给用户实施。
1.1.3.1.1.3项目管理组
负责向项目管理委员会定时汇报项目进展情况，就项目中存在问题提出处理提议，对项目进行有计划地组织管理，并检验项目进展情况。
项目管理组由南京银行项目责任人和本企业项目经理和技术责任人共同组成。
1.1.3.1.1.4基础架构组
负责基础架构设计和步骤建模设计。
和企业架构师共同设计整体基础架构，完成本项目范围内计划，考虑本项目和整个企业范围IT架构一致性计划。
1.1.3.1.1.5质量管理组
直接隶属项目管理委员会，按制订标准及控制手段实施进度管理，风险管理，全方面实施各项局方及业内要求质量标准和工作步骤。
1.1.3.1.1.6服务定义公布组
负责在总线上公布服务和设定服务标准。
依据基础架构计划中服务架构，对服务进行归类，依据服务定
升级会员 