项目实施方案模板

.XX平台项目实施 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 XXX有限公司2017年10月目录4第1章项目概述41.1项目建设内容及范围41.1.1项目总体建设范围41.1.2项目内容5第2章项目实施方案52.1项目实施62.1.1项目启动阶段72.1.2需求调研、需求分析阶段82.1.3设计阶段92.1.4客户化开发、实施与测试阶段92.1.5系统实施部署阶段102.1.6上线试运行阶段102.1.7验收阶段122.2项目管理132.2.1项目组织架构152.2.2进度计划和管理212.2.3项目管理方法302.2.4质量管理322.2.5需求管理342.2.6沟通和监控机制352.2.7风险管理372.2.8配置管理41第3章培训方案413.1人员培训方案413.1.1培训目标413.1.2培训方式413.1.3培训内容423.1.4培训内容433.2培训方案设计433.2.1标准规范体系培训433.2.2基础知识培训433.2.3应用系统培训443.2.4现场培训443.2.5培训资料45第4章软硬件部署454.1系统部署结构464.2系统网络拓扑结构464.3设备部署机房环境要求464.3.1电压和频率变动范围要求464.3.2电源插座类型要求474.3.3接地电阻要求474.3.4温度湿度要求474.4平台系统部署软件需求474.5平台系统服务器需求474.5.1正式部署环境要求484.5.2开发测试部署环境要求484.6其他需求484.6.1办公场所需求494.6.2网络环境第1章项目概述1.1项目建设内容及范围1.1.1项目总体建设范围1、服务对象1）2）1家典型重点工控企业。2、主要用户包括信党政机关和重点工控系统运营单位。1.1.2项目内容 序号 名称 1 XXX系统 2 XXX平台 3 4 其中：1、风险防范系统系统包括采购一套监测设备、一套风险分析设备，并将互联网监测系统整体纳入监控平台管理，提供3年监控技术服务及升级服务。2、XXX平台主要包含。。第2章项目实施方案项目实施方案包括项目实施和项目管理。2.1项目实施从项目实施的角度详细描述了主要实施阶段的主要参与人员、工作内容和相应的工作方法。依据我们对相关领域的经验提出对本项目建设计划。我方在项目管理方面有着自己一套科学而先进的项目管理方法论，这套方法论已经在实施的所有的项目中得到了检验。项目管理方法论是公司最重要的一项核心竞争能力，是我们能够对客户承诺项目成功的信心所在。我方项目管理方法论建立在如下5项重要原则的基础上：·与客户共同探讨对项目成功衡量标准的定义，并以此作为双方工作的共同标准和价值观。·制定细致的项目计划，明确定义项目阶段和阶段交付成果。将一个大型的复杂的任务分解为可以量化和可以具体执行的分解工作任务，并明确定义每一个分解任务所需要达到的工作成果，使得项目总体目标得以有效的保证。·与客户的充分沟通，通过各项例会制度，周报和月报制度等使客户可以全面了解项目进展情况，保证项目的交付始终与客户的预期保持一致。·明确定义项目组织结构和工作职责，并设定相应的考核标准和方法，保证项目各方能够有效的协同工作。·建立明确的文档管理，人员管理，配置管理，风险管理，预算管理，进度管理，采购管理，集成管理和变更管理规范与制度以保证项目的整体质量和各环节的配合。针对平台实施工作，将其分为了如下图所示的6个阶段：图2‑1项目实施阶段示意图说明：考虑到本系统的建设周期，设计、实现、实施以及试运行部分将出现迭代：·第一次迭代过程保证系统主要功能能够正常使用。·第二次迭代过程保证工信厅安全综合服务平台项目其余辅助功能能够使用。下面首先对各阶段的工作进行说明：2.1.1项目启动阶段·阶段工作目标本阶段的工作目标是从项目目标、项目范围、项目工作方法以及后勤保障方面为系统建设项目的顺利进行建立基础。·阶段工作内容本阶段的工作内容包括：组织项目所需的各项资源，包括：人员确定、办公环境、网络及通讯环境、个人工作设备、开发环境、现场工作环境及生活环境；确认工作范围：针对项目投标方案中对工作范围的描述，进一步与工信厅安全综合服务平台项目负责人讨论确定项目工作范围；制定项目计划：根据项目投标方案中制定的项目计划，与工信厅安全综合服务平台项目负责人重新审核和进一步建立细致的项目主计划；确定项目管理规范：根据项目管理规范要求，针对本系统建设项目进行适当裁剪，以满足本项目管理的要求；确定质量规范－明确定义项目各阶段工作成果的格式、审核流程和验收标准。召开项目启动会：召集项目组全体成员、相关实施厂商及工信厅安全综合服务平台项目组成员，通过项目启动会的形式进一步明确上述各部分要求。·阶段工作成果：《项目施工实施方案》2.1.2需求调研、需求分析阶段·阶段工作目标本阶段的工作目标是通过对工信厅相关业务、周边业务和现有系统和软硬件环境的的深入细致的分析，并结合行业先进做法，为项目顶层设计建立基础。·阶段工作内容有效需求管理的关键在于维护需求的明确阐述、每种需求类型所适用的属性，以及与其它需求和其他项目工作产品之间的可追踪性。1．管理不同层次的需求项目前期，客户提出的需求一般不是直接面向软件需求的，是从业务的角度描述他们的问题或者是需要。根据这些需要定义软件系统的解决方案，确定系统提供哪些服务，也就是软件系统的特征。在与客户取得一致的特征集上可以定义出更为特定的软件需求。软件需求包括功能性需求和非功能性需求。不同的客户以及在项目不同时期也可能提出特征或软件需求层次的需求。管理这些不同抽象级别和目的需求，确保需求是完备的。2．建立可追踪性通过需求的属性、需求之间的依赖关系以及需求与其它工作产品之间的依赖关系，管理需求的可追踪性。用来了解需求的来源、管理项目的规模、管理需求的变更、评估需求变更对项目的影响、评估测试故障对需求的影响、核实所有需求都已实现、核实应用程序仅仅执行了预期的任务。3．管理需求变更定义需求时无论怎样谨慎小心，也总会有可变因素。对需求变更进行管理，使团队的工作受到控制，以便它能够高效的发现变更、进行影响分析并且系统地把那些既必要又可接受的变更集成到系统中。4．需求定义·细化业务和系统目标；·定义清晰、简明、一致、可测试、无二义性的业务需求；·基于对业务需求排列优先级：必须有，应该有，可以有，将会没有。5．需求分析·建立业务数据模型，精确描述信息和过程需求；·检验提供业务所需的信息的数据和业务数据模型中的数据元素在源系统中的是可用的并且具备必须的特性。·阶段工作成果此阶段的项目工作成果将包括：《系统业务调研报告》《系统需求规格说明书》设备采购及到货验收、上架；2.1.3设计阶段·阶段工作目标本阶段的工作目标是对系统进行总体设计，并对各相关子系统进行详细设计，从而为系统的实现阶段建立依据。·阶段工作内容本阶段的工作内容包括：顶层初步设计系统总体设说明书数据接口及数据同步设计·阶段工作成果本阶段的工作成果包括：《顶层设计》《管理机制建设》《概要设计方说明书》《详细设计说明书》2.1.4客户化开发、实施与测试阶段·阶段工作目标本阶段的工作目标是根据系统总体设计及各模块设计方案，进行系统的建设、开发和部署。·阶段工作内容系统配置＆部署；系统接口实现；项目顶层初步设计评审；应用系统接口开发和测试。·阶段工作成果本阶段的工作成果包括：各第三方软硬件及文档及《平台实施方案》2.1.5系统实施部署阶段·阶段工作目标本阶段的工作目标是对系统进行部署实施，以保证系统的试运行。·阶段工作内容本阶段的工作包括：软硬件的安装部署；系统数据初始化；编制用户 手册 华为质量管理手册 下载焊接手册下载团建手册下载团建手册下载ld手册下载 ；技术培训；用户培训；·阶段工作成果本阶段的工作成果包括：《用户培训计划》《用户操作手册》《实施报告》《验收报告》2.1.6上线试运行阶段·阶段工作目标本阶段的工作目标是通过一段时间的系统试运行，帮助用户熟悉系统，发现并解决系统产生的问题，为系统正式投入使用打下基础。·阶段工作内容本阶段的工作内容包括：组织系统各方面用户使用系统；建立系统问题发现、跟踪和解决机制；问题发现和处理；2.1.7验收阶段2.1.7.1验收对象项目名称：平台（一期）（以下简称“项目”）。验收对象为该项目的相关文档技术文档，系统运行情况、顶层设计等建设内容。2.1.7.2项目验收的前提条件·所有建设项目按照 合同 劳动合同范本免费下载装修合同范本免费下载租赁合同免费下载房屋买卖合同下载劳务合同范本下载 要求全部建成，并满足使用要求；·已通过软件系统测试评审；·软件已部署在生产环境上；·各种技术文档和验收资料完备，符合合同的内容；2.1.7.3验收步骤·编写验收方案（计划书）·成立项目验收小组实施测试验收工作时，应当成立项目验收小组，具体负责验收事宜。·项目验收的实施严格按照验收方案对项目应用软件、系统文档资料等进行全面的测试和验收。·提交验收报告项目验收完毕，对项目系统设计、建设质量、设备质量、软件运行情况等做出全面的评价，得出结论性意见，对不合格的项目不予验收，对遗留问题提出具体的解决意见。2.1.7.4验收内容和标准1、验收的内容包括以下几个部分：·验收内容包括：按功能要求的可执行软件、开发计划文档、设计文档、使用说明书等。·验收评测工作主要包括：文档分析、方案制定、现场测试、问题单提交、测试报告。·文档验收标准一般包括：文档完备性、内容针对性、内容充分性、内容一致性、文字明确性、图表详实性、易读性、文档价值等。2、需要评审的资料包括以下几部分：·需求规格说明书、概要设计说明书、系统维护手册、用户操作手册。·软件开发管理文档：项目计划书、用户培训计划、开发进度月报。2.1.7.5验收结论验收结果分为：验收合格、需要复议和验收不合格三种。符合项目建设标准、系统运行安全可靠，视为验收合格；由于提供材料不详难以判断，或目标任务完成不足80%而又难以确定其原因等导致验收结论争议较大的，视为需要复议。1、项目凡具有下列情况之一的，按验收不合格处理：·所提供的验收材料不齐全或不真实的；·实施过程中出现重大问题，尚未解决和作出说明，或项目实施过程及结果等存在纠纷尚未解决的；·没有对系统进行试运行，或者试运行不合格；·违反法律、法规的其他行为。2、验收结论确认和处理·由工信厅和我方共同根据验收意见和相关资料得出结论，并进行确认。2.1.7.6项目交接项目竣工验收合格后,应办理项目交接手续。项目的移交包括项目实体移交和项目文档移交部分。2.2项目管理本章描述了项目的管理特点和管理要求，并根据本项目的特点给出了工信厅拟实施项目的组织架构，管理方案和初步的进度计划，列出了项目的成果交付物。并介绍了相关的项目管理方案，包括：质量管理，需求管理，配置管理，软件发布与部署，项目跟踪与监控，风险管理等内容。2.2.1项目组织架构2.2.1.1组织结构我们建议项目采用如下的组织形式：图2‑2项目组织结构图项目的组织结构将分为三个层次：领导层、管理层和执行层，每个层次负责不同的项目职能。 XXX（业主单位） XXX（承建单位） XXX（承建单位） 领导层 项目领导小组 管理层 项目负责人 项目经理 项目负责人 执行层 业务层 业务负责人各业务部门的业务专家 咨询顾问业务专家需求分析师 咨询顾问业务专家需求分析师 技术层 实施人员 应用系统开发经理系统分析师架构设计师安全分析师开发工程师测试工程师实施人员 规划编制员1、领导层·项目领导层项目领导层将负责对项目整体方向的控制，并通过项目领导委员会的形式对项目过程中产生的重要问题进行讨论分析和决策。2、执行层负责项目核心业务需求分析与设计、技术路线以及核心技术的设计，起草业务需求文档项目执行层将在项目管理层的领导下完成对项目的规划设计、系统需求分析、系统整体设计、系统开发、系统测试、文档整理、系统配置等各方面的具体工作。分为业务组和技术组，包含规划设计组、项目实施组、甲方实施组和应急小组。涵盖的角色如上表。·规划设计组规划设计组包含顶层设置编制组、综合管理服务机制建设编制组，负责本项目的顶层设计方面的业务需求了解、规划编制、标准规范编制等工作。·项目实施组项目实施组包含系统研发组、测试组、现场实施组，负责整个项目系统需求调研、系统设计开发、上线功能测试测试、现场实施及培训相关工作。·甲方实施组负责项目实施日常工作跟踪、协调、功能测试、问题反馈跟踪等相关工作。2.2.1.2项目主要成员甲方成员 序号 项目组角色 姓名 工作职责 1 领导、专家成员 领导成员，负责项目总体协调。 2 项目实施负责人 负责项目具体实施、实施进度监督、现场工作具体协调等。乙方成员 序号 项目组角色 姓名 工作职责 1 领导、专家成员 项目领导专家成员，负责总体项目协调及专家咨询。 2 领导、专家成员 研究中心专家成员，负责总体项目协调及专家咨询。 3 项目经理 负责总体实施、项目进度控制及协调。 4 项目副经理 协助项目经理，负责项目实施、现场项目进度、项目汇报等。 5 项目副经理 协助项目经理，负责系统研发、实施及相关现场工作等。 6 软件工程师 负责软件部分开发实施 7 系统集成工程师 负责硬件设备部署以及相关中间件数据库等部署 8 规划编制 研究中心规划编制负责人，协助项目经理，负责对总体规划、机制体制等编制等工作。监理成员 序号 项目组角色 姓名 工作职责 1 项目总监 XXX 负责项目总体监理及进度监督工作。 2 监理工程师 XXX 负责现场项目实施监理工作。 3 监理工程师 XXX 负责现场项目实施监理工作。2.2.2进度计划和管理2.2.2.1项目进度计划： 序号 阶段 内容 起始/截至 工作日 文档 1 1、系统设备采购及环境部署 2 设备采购 设备采购 2014年10月20日/2014年11月7日 15 　 3 设备到货验收 设备到货验收 2014年11月10日/2014年11月10日 1 设备到货验收文档 4 设备环境部署 开发环境部署 2014年10月28日/2014年10月30日 3 　 5 采购设备部署 2014年11月10日/2014年11月10日 2 系统部署及配置文档 6 系统联调 设备网络联调 2014年11月11日/2014年11月12日 2 　 7 设备与系统联调 2014年12月18日/2015/1/3 15 系统接口配置文档 8 2、软件开发 9 计划阶段 计划编制 2014年10月8日/2014年10月8日 1 项目实施计划表 10 计划阶段 项目启动会 2014年10月9日/2014年10月9日 1 计划表细项讨论 11 计划阶段小计 2014年10月8日/2014/10/9 2 　 12 需求阶段 需求调研、分析 2014年10月10日/2014/10/21 9 需求规格说明书 13 需求评审 2014年10月22日/2014/10/22 1 14 需求阶段小计 2014年10月9日/2014/10/22 10 　 15 设计阶段 概要设计 2014年10月23日/2014/10/27 3 概要设计说明书 16 　 17 数据库设计 2014年10月28日/2014/10/29 2 数据库详细说明书 18 详细设计 2014年10月30日/2014/11/5 5 系统详细设计说明书 19 设计阶段小计 2014年10月23日/2014/11/5 10 　 20 实现阶段 数据库实现 2014年11月6日/2014/11/6 1 相关代码 21 XXX系统 2014年11月7日/2014/11/18 8 22 XXX系统 2014年11月19日/2014/11/28 8 23 XXX系统 2014年11月19日/2014/12/23 25 24 XXX系统 2014年11月19日/2014/12/16 20 25 XXX系统 2014年12月17日/2015/1/13 20 26 实现阶段小计 2014年11月6日/2015/1/13 49 　 27 测试阶段 测试准备 2015年1月14日/2015/1/14 1 系统使用说明书系统测试方案书 28 功能测试 2015年1月15日/2015/1/21 5 测试报告 29 性能测试 2015年1月15日/2015/1/21 5 项目初步验收报告 30 BUG修正 2015年1月22日/2015/1/28 5 　 31 测试阶段小计 2015年1月14日/2015/1/28 11 　 32 试运行阶段 安装 2015年1月29日/2015/1/29 1 系统培训报告 33 试运行 2015年1月30日/2015/2/19 15 系统试运行报告 34 BUG修正 2015年2月20日/2015/2/26 5 　 35 投运 2015年2月27日/2015/2/27 1 　 36 3、顶层设计、机制建设 37 编制阶段 编制 2014年10月23日/2014/12/3 30 顶层设计文档、机制建设文档 38 评审 2014年12月4日/2014/12/5 2 　 39 修订 2014年12月8日/2014/12/12 5 　 40 整体项目合计 2014年10月23日/2014/12/12 37 　 41 4、工控实施 42 需求阶段 需求调研、分析 2014年12月13日/2014/12/16 4 需求规格说明书 43 需求评审 2014年12月17日/2014/12/17 1 44 需求阶段小计 2014年12月13日/2014/12/17 5 　 45 实现阶段 接口开发 2014年12月18日/2015/1/8 20 相关代码 46 实现阶段小计 2014年12月18日/2015/1/8 20 　 47 整体项目合计 2014年12月13日/2015/1/8 25 注:测试、试运行阶段与“一、软件开发”同步进行。 48 5、监控接口开发 49 需求阶段 需求调研、分析 2014年11月6日/2014/11/10 4 需求规格说明书 50 需求评审 2014年11月11日/2014/11/11 1 51 需求阶段小计 2014年11月6日/2014/11/11 5 　 52 实现阶段 接口开发 2014年12月18日/2015/1/3 15 相关代码 53 实现阶段小计 2014年12月18日/2015/1/3 15 　 54 整体项目合计 2014年11月6日/2015/1/3 20 注:测试、试运行阶段与“一、软件开发”同步进行。图2‑3项目实施计划2.2.2.2主要里程碑成果物 序号 阶段 成果物 1 合同签订 2 项目启动 3 项目小组成立、项目实施计划确定 《项目实施方案》 4 一、XXX顶层设计 5 需求调研、需求分析 6 顶层设计编制 《顶层设计》讨论稿 7 顶层设计初审 《顶层设计》初审稿 8 顶层设计初稿修订编制 9 顶层设计终审及终审编制 《顶层设计》 10 二、XXX机制建设 11 需求调研、需求分析 12 XXX机制编制 《XXX机制》讨论稿 13 XXX机制初审 《XXX机制》初审稿 14 XXX机制初稿修订编制 15 XXX机制终审及终审编制 《XXX机制》 16 三、XXX平台 17 需求调研、需求分析 《需求规格说明书》 18 系统概要设计及评审 《系统概要设计说明书》《系统数据库设计说明书》《技术开发规范》 19 系统开发设计 《系统详细设计说明书》《系统操作手册》 20 系统测试 《系统测试方案》《系统测试报告》 21 系统培训 《系统培训计划》 22 项目初步验收 《初验报告》 23 项目试运行 《试运行报告》 24 系统功能完善 25 系统正式运行 26 四、XXX系统 27 设备采购、供货 28 设备上架、到货验收 《到货验收报告》 29 系统安装、入网联调 《系统接入方案》 30 培训 31 正式运行 32 五、项目整体验收 33 项目验收资料整理 34 项目整体验收 《验收申请》《验收方案》《验收报告》2.2.2.3进度管理方法计划是项目管理的基准，现代质量管理认为“计划胜于检验”，“过程决定质量”，对于项目执行来讲同样是这样。计划是项目执行的指导，计划是控制的基准，计划是项目各方沟通的平台。计划制定的过程强调渐进明细和分解。通常应用软件开发过程中项目计划容易出现的问题有：1．项目计划凌乱、无序，也就是说不能从项目计划中看到项目执行全貌。对项目执行指导意义不大。2．项目计划只是在项目开始时进行制定，在执行过程中不对计划进行及时管理，导致项目计划失效，同时失去对项目执行的指导意义。3．项目计划不完整，只是在当前所关注的环节存在计划，导致项目执行工作不能整体上全面协调的推进。本项目项目计划跟踪和控制建议：1．项目计划层次划分项目计划可分为：项目里程碑计划、子项目计划、周项目计划3个层次。充分体现项目管理中渐进明细和分解的原则。项目里程碑计划作为项目各参与方均认可的项目阶段目标指导性文件，项目各参与方均需对其负责。对里程碑计划进行渐进明细形成子项目计划，子项目计划要说明里程碑计划中阶段目标的实现步骤和方法。在子项目计划的指导下形成项目各参与方的周项目计划，周项目计划作为项目进度风险控制的最小单元，根据周项目计划的执行情况进行考核，并及时形成调整措施。2．项目计划有效性和完整性“计划赶不上变化”，在项目执行的过程中必然会发生各种各样的情况变化，如各个层次的项目计划不能得到及时的变更控制和管理，项目计划将逐渐与项目执行情况脱节并失效。项目计划有效性的丧失必然导致项目工作陷入无序状态，最终导致项目目标不能如期实现，甚至造成项目失败。在形成各个阶段或维度的子项目计划时，非常重要的一点是要保证项目计划的完整性。如果子项目计划存在缺失，会造成项目执行中的重大缺陷，对整体项目执行产生重大影响。针对项目计划的有效性和完整性问题提出本项目中相关项目管理建议：（1）项目管理组承担项目计划的变更控制和管理职能，对项目计划的有效性负全面责任。（2）建立项目计划变更控制流程。在项目执行情况发生重大变更时，相关方必须向本项目管理组提出变更申请；项目管理组根据情况及时组织项目相关方审查项目变更，并进行风险分析，更新项目计划并通知项目各方。（3）项目总体计划和子项目计划制定，要进行相关评审，在评审通过后方可生效。（4）建立项目计划标识体系，包括项目计划版本标识。每次项目计划的变更均需更新标识，并说明变更原因和进行相关风险的说明。3．项目计划的执行情况跟踪本着及早发现问题的原则，定期的对项目计划的执行情况进行跟踪，并对跟踪结果进行公布。跟踪的频度与项目执行情况相关，可以每周、双周等频度进行。2.2.3项目管理方法2.2.3.1项目评审评审主要包括里程碑评审、同行评审和跟踪，其中里程碑评审是管理评审，同行评审和跟踪属于同行评审的两种形式。（1）里程碑评审里程碑评审的主要活动包括以下内容[第1步]项目经理负责组织里程碑评审活动[第2步]讨论里程碑报告、评估报告[第3步]项目经理负责形成项目里程碑报告[第4步]确定下一个阶段的计划是否需要修改里程碑评审后，质量保证员依据评审记录，监督问题改正和变更的执行情况。（2）项目进度及问题跟踪跟踪的主要步骤如下：[第1步]项目经理负责项目整体进度以及实施过程中具体问题的的跟踪，一般来讲，参与跟踪人员可选择项目组内的人员，但应注意跟踪时避免跟踪自己完成的工作产品部分。[第2步]项目经理负责将要跟踪的工作产品及相关资料在跟踪前一天发送给参与跟踪的人员[第3步]参与跟踪的人员按计划进行跟踪，并将跟踪出的问题形成评审记录[第4步]项目经理汇总评审记录，并对跟踪出的问题进行分工，同时跟踪问题的解决情况，直至问题解决结束。[第5步]项目经理负责形成评审报告，记录本次跟踪的结论，参与跟踪的人员，统计本次跟踪的工作量、发现的问题类型个数、修改的问题个数等。2.2.3.2进度监控项目要制定合理的进度安排，并确保项目能够按计划进行。项目经理以及各组负责人根据项目特点、客户需求、识别的风险、可能存在的限制安排项目进度；在项目执行过程中定期对所属范围内的项目进展情况进行监控，识别与分析实际进展与计划的偏离原因，采取纠正措施进行调整，必要时进行正式的计划变更。1．进度安排进行合理的进度安排是进行监控的前提，考虑迭代的生命周期模型，项目采取分阶段细化项目进度的策略。在项目初始策划阶段，项目制定总进度表，内容包括各主要里程碑和各迭代点；在每主要里程碑结束，细化下一里程碑的计划；在每次迭代策划阶段，制定本次迭代的进度表，细化本次迭代内的项目活动。进度安排时可以按照以下步骤进行：·确定可用的资源。在编制进度表时，知道在何时以何种形式取得何种资源是必要的，这种对资源可用性的了解程度是需要不断进化的。·确定项目日历和资源日历。项目日历和资源日历标明了在该项目中或者对于某一资源来说哪些日期是用于工作的时间。·根据任务的依赖关系和估计工期列出项目的关键路径，为关键路径上的各个关键任务分配资源，为非关键路径上的其它任务分配资源。·进度的安排可以使用表格形式或者图形形式进行表示。2．进度调整项目依据进度表的安排执行并控制项目进度，并根据项目状态对进度进行调整。使用进度表监控项目进展，进度控制的内容有：·对造成进度变化的因素施加影响，以保证这种变化朝着有利的方向发展。·收集项目实际进度状态数据，与计划进度数据进行比较，确定项目进度是否已发生变化。·当在实际变化发生和正在发生时，对这种变化实施管理。根据项目状态对进度进行调整，进度调整包括两种类型，即日常调整、定期调整和项目进度发生重大变更时的调整。日常调整指项目各级负责人日常对进度表的更新活动，可以是每天或者每周进行，一般包括对以下内容的调整：·调整某个任务的工期、计划开始时间或结束时间。在调整时要注意与该任务具有依赖关系的其他任务的变化，特别是要注意关键路径的变化，检查所进行的调整是否导致项目里程碑结束日期或者项目日期发生变化。·根据人员负荷和进度变化调整资源的分配，为某个任务重新指定资源。·收集并记录进度实际数据，一般包括任务的实际开始时间、实际结束时间等。·定期调整是指项目经理在迭代内里程碑、迭代结束和阶段结束通过正式评审项目进展，根据项目完成状况对项目进度的调整。当项目进度发生重大变更时，如需求变更引起的，需要调整项目进度表，此时需要对剩余工作进行重新估计，重新制定后续任务的进度表，包括调整迭代计划以及项目总体计划。2.2.3.3资源监控资源是指在项目运行过程中所需要的人力资源。资源监控是指项目充分、有效地利用所涉及人员的过程，包括识别并管理这些资源以及在不同阶段需要的数量、状态等信息，确保项目的正常开展。在项目策划阶段，策划合适的资源安排到各项项目任务中，形成完整的人员配备管理计划；在项目实施过程中，通过邮件、周例会和里程碑总结等正式和不正式的手段对人员的状态进行监控。一旦出现不可避免的人员变更问题，按照规定的流程进行工作交接。本项目的资源监控有两个主要特点：·工作匹配原则：保证为项目配备符合项目活动能力要求的工程和管理人员；·动态人员结构：根据不同阶段项目对人员的不同需求考虑投入不同能力和不同数量的人员。1．人员策划需要识别为完成项目所涉及的所有人员角色、所需的经验技能、数量要求以及投入时间等信息，建立人员需求表。基于以上需求，获取符合项目以上需求的技术和管理人员；获取的途径包括本事业部内部、公司内部其他事业部或社会招聘。获取人员的主要考虑人员的工作能力和熟练程度，具有类似项目的技术和管理经验背景优先，同时也要考虑个人爱好和个人特点以及时间上可能性。根据项目进度的要求和任务的安排，为每项任务分配人力资源以及每项资源在各个时间段内（天、周、月或者其它时间间隔）完成的工时，形成完整的人员配备管理计划。在人员配备管理计划中，以图或表的形式描述了资源分配和人员负荷等情况。2．人员变更项目经理跟踪人员配备管理计划以监控项目人员的投入状况，并在每周和每里程碑上进行总结，监控的主要内容包括：·人员投入的数量以及投入的人员技能是否可以满足项目实施要求；·是否需要为项目人员提供必要的培训；·人员负荷是否不平衡；·人员是否流失或有流失的可能；在项目周会和里程碑会议上，高级管理者、客户方和项目经理评审以上人员状况，制定合理的措施以处理人员管理中遇到的一些问题。由于人员离职或工作变动会引起项目中人员的变更。项目经理会分析人员变更所带来的影响，尽量控制人员变动，对于不可避免的人员变动要处理好工作交接，以使工作能够全面、顺利的交接，降低工作交接对项目工作带来的风险和问题。下图描述了人员变更主要活动的流程：SHAPE\*MERGEFORMAT图2‑4项目实施人员变更流程对于以上人员变更活动需要注意以下内容：·新负责人应尽量选择在相关领域有经验的人员（由于是中途接手，难度较大）；·如果选择本项目中已承担其他工作任务的人员作为新负责人，则一定要准确度量其负荷，并要明确其接手后的责任；·交接期限的确定应以工作能够有效交接为中心，可能的情况下部门应在工作交接结束后，才最终同意原担当离职或变动工作；·交接计划要与项目经理和被交接者商讨制定，计划中应包含要进行哪些交接活动、时间、内容及相关人员安排等，应该包括相关培训和自学的内容。·项目经理要对工作交接的结果进行检查，判断相关工作是否都已经顺利交接；如果存在问题，需要与相关人员商讨后续计划。2.2.3.4风险管理在软件开发中，风险是某种不确定因素，在其正常分布范围内，它可以危及项目成功或导致项目失败。因此有效的管理项目风险是项目成功的关键。1．风险管理策略根据风险发生的可能性和对项目影响的严重程度，定义风险等级：高、重大、中等、较小、低。风险对策：主要描述应对风险的策略。风险管理的核心思想不是被动地等待（等到风险变成现实、成为问题或导致项目失败），而是决定如何对付风险。对于每个风险，有3种主要的可行措施：·风险规避：重新组织项目，使风险无法影响项目；·风险转移：重新组织项目，让其他方承担该风险（客户、厂商、银行、其他主题等）；·风险接受：决定接受这种可能发生的风险。监视风险征兆，如果风险出现，则制订应急计划，决定要采取的措施。如果接受风险，还要采取两种措施及：风险减轻：采取一些及时的、正面主动的步骤来减小风险发生的可能性或影响。制定应急计划：如果风险变成实际问题，应当采取的措施。3．项目风险和对策以下提出项目可能的风险及应对策略：（1）软件需求涉及业务的软件系统，经常会出现这样的问题：系统开发完成了，但没有满足客户的业务需求；需求经常发生变化，导致开发范围的蔓延。避免软件需求的风险，才能项目成功。化解风险的策略：·理解客户需要解决的问题：通过业务建模，了解客户的业务流程和业务需求；·增强与客户的沟通：用例建模立足用户角度描述，为具体的需求提供了充分的上下文信息，是衔接用户和开发者的纽带和沟通方式；·及早收集客户的反馈：每次迭代都会产生系统可执行的部分，通过及早部署演示来挖掘用户的反馈意见，改进对于需求理解的偏差；·控制需求变更：变更请求可能来自于客户和最终用户、设计人员、开发人员、测试人员、技术支持部门等，建立变更控制流程管理变更。（2）架构/技术风险可执行构架指的是系统的部分实施，该构架用于演示选定的系统功能和特征，尤其是那些满足非功能性需求的功能和特征。利用该构架可以降低性能、吞吐量、容量、可靠性以及其他方面的风险。迭代开发在精化阶段的关键活动是确定架构并为构架建立基线，在该阶段经过几次的迭代和测试修改，到精化结束时稳定的架构基线已经建立，性能等主要技术风险尽早的被发现和解决。从而在构建阶段可以在一个稳固的基础上完成系统功能的全面添加，而不用担心破坏系统。2.2.3.5质量管理软件质量保证过程的目的是为项目组的软件开发过程提供指导，为管理层就软件项目过程提供管理信息，为提升软件质量提供手段。由于开发软件系统或软件产品的过程是决定项目成功与否的关键因素，因此软件质量保证的工作是评审和审计软件活动和软件产品。软件质量保证过程需要达到的目标包括：·软件质量保证活动是有计划的活动；·软件产品和活动与适用的标准、过程和需求的一致性需经客观验证；·软件质量保证活动及成果应及时通知到受影响的组织和个人；·软件项目内部未能解决的有争议问题，由上级管理部门处理；软件质量保证过程定义如下：·由质量保证员负责向项目组人员进行PPQA定向培训；·由质量保证员负责编写质量保证计划；·由质量保证员负责对软件项目过程及其他公司规范及过程进行质量保证，软件项目过程包括：软件销售管理过程、需求开发过程、需求管理过程、项目计划和跟踪过程、软件设计过程、软件编码过程、软件测试过程、项目实施过程、配置管理过程、变更过程、评审过程，其他过程包括：培训管理过程、组织过程焦点过程、组织过程定义过程；对于项目内部不能解决的问题，由质量保证员汇报给高层管理者；2.2.3.6沟通管理项目沟通管理的目的是能够及时、适当地产生、收集、发布、存储项目信息。沟通管理是人、意见和信息之间的关键纽带，是成功所必须的。参与项目的每一个人都必须做好以项目“语言”方式传达和接收信息的准备，同时还必须明白他们以个人身份涉及的信息将如何影响整个项目。1．沟通原则为了确保及时有效地进行沟通，本项目确定以下沟通原则：·确保客户可以最大程度地参与项目工程和管理活动；·确保与客户及早沟通需求，以消除需求中的不确定性；·定期与客户沟通项目各里程碑和各迭代的进度和进展状况；·确保各阶段的主要成果物及时提交给客户，以便客户评审；·对于项目出现的重大问题，及早报告给客户以便客户了解项目。2．存在沟通需求的组织一般包括：·项目与客户；·项目合作方；·项目组内部，当项目成员工作位置不在同一地点时，要事先确定异地开发的沟通机制，确保项目信息的沟通顺畅。3．沟通的方式一般包括：·报告，例如周报、里程碑总结等；·会议，包括评审、讨论等。4．沟通的程度一般包括参与和了解，具体参与程度需要根据具体项目需求进行调整：·参与：参与内容的制定和检验，例如项目计划的编制和评审；·了解：不参与跟内容有关的制定和检验活动，对信息内容了解即可。5．沟通的内容，分为三类：·计划：包括项目计划和迭代计划的制定与评审；·进展：包括每个迭代状态和里程碑状态的评审；·工程文档：包括每个工程阶段主要输出物的评审。6．项目沟通机制项目的沟通管理机制如下表所示： 分类 沟通内容 组织/发布方 沟通方式 项目 客户 报告 会议 计划 项目计划 项目 -- 参与 项目计划 项目计划评审会 相关方配合计划 项目 -- 参与 协作项目计划 协作计划评审会 人员计划 项目 -- 参与 项目成员和角色规划 监理计划 监理方 -- -参与 监理计划 监理计划评审 计划变更 项目 -- 参与 最新项目计划 最新项目计划评审会 周报 项目周进展和存在问题分析 项目 -- 了解 项目周报 -- 里程碑总结报告 项目里程碑总结 项目 -- 参与 项目里程碑总结 里程碑总结与评审会 状态评估 渐进的进展状态 项目 -- 参与 状态评估 状态评估会 需求 需求规格 项目 -- 参与 需求相关报告 需求讨论 分析规划 架构设计\设计模型\数据库设计 项目 -- 参与 分析设计报告 分析设计讨论 开发实现 源代码\编码规范 项目 -- 参与 -- 实现功能测试 功能测试 测试计划\测试用例\测试环境\测试数据\缺陷报告 项目 -- 参与 测试相关文档 功能测试讨论 部署 部署计划\数据迁移\用户培训\系统集成\上线割接\验收测试 项目 -- 参与 部署相关文档 部署讨论 阶段总结会 按商务合同规定的阶段 项目 -- 参与 阶段总结报告 部署评审会2.2.4质量管理2.2.4.1质量控制质量控制的目的是确保：·完成项目内容并达到预定的目标·最终的系统是稳定的和可用的·确保项目按预定计划完成因此，在项目进行中，需要设立若干控制点，以确保项目的质量可控。质量控制队伍独立于项目实施小组，作为项目成功的重要因素和保障，在项目执行过程中始终与项目实施小组保持密切联系。从另一个角度观察和监督项目的开展，帮助PMO发现和解决项目执行中的问题确保项目的成功。可以采取以下步骤实施全面质量控制：1．建立标准化工作流程项目启动时，项目组应根据项目范围、项目要求，首先组织人力编制项目流程、工作标准及相应工作手册，形成工作方法体系，实现项目工作的流程化、标准化，并对项目人员进行培训，使他们了解和遵守项目流程和要求。2．实行阶段性成果提交与变更控制项目具有生命周期，这就为我们划分项目阶段提供了依据。一个大项目可分成若干阶段，每个阶段有自已的任务和成果。这样一方面便于管理和控制项目进度，另一方面可以增强项目人员和用户的信心。在每个阶段末要提交部分成果物，作为下一阶段开发的基础。成果物提交之后不是不能修改，而是其修改要经过一定的审批程序，并且涉及到项目计划的调整。3．实行里程碑式的审查与版本控制里程碑式审查就是在项目生命周期每个阶段结束之前，都正式使用结束标准对该阶段提交的成果进行严格技术审查，如果发现问题，应及时在阶段内解决。版本控制是保证软件项目顺利进行的重要手段。版本控制的含义是通过给文档和程序文件编上版本号，记录每次的修改信息，使项目部的所有成员都了解文档和程序的修改过程。4．测试要采用适当的手段，对需求调查、系统分析、系统设计、实现和文档进行功能测试。5．用户单位加强监督为进一步加强项目质量控制，要加强用户单位对项目质量的监督。2.2.4.2质量保证软件质量保证过程的目的是为软件项目组的软件项目过程提供指导，为管理层就软件项目过程提供管理信息，为提升软件质量提供手段。由于开发软件系统或软件产品的过程是决定项目成功与否的关键因素，因此软件质量保证的工作是评审和审计软件活动和软件产品。软件质量保证过程需要达到的目标包括：·软件质量保证活动是有计划的活动；·软件产品和活动与适用的标准、过程和需求的一致性需经客观验证；·软件质量保证活动及成果应及时通知到受影响的组织和个人；·软件项目内部未能解决的有争议问题，由上级管理部门处理；软件质量保证过程定义如下：·由质量保证员负责向项目组人员进行PPQA定向培训；·由质量保证员负责编写质量保证计划；·由质量保证员负责对软件项目过程及其他公司规范及过程进行质量保证，软件项目过程包括：软件销售管理过程、需求开发过程、需求管理过程、项目计划和跟踪过程、软件设计过程、软件编码过程、软件测试过程、项目实施过程、配置管理过程、变更过程、评审过程，其他过程包括：培训管理过程、组织过程焦点过程、组织过程定义过程；·由质量保证员对软件工作产品进行质量保证，依照工作产品规范/模板检查项目工作产品；·质量保证员应参加项目的管理评审和技术评审；·由质量保证员定期与不定期地将检查结果报告给有关人员；·对于项目内部不能解决的问题，由质量保证员汇报给高层管理者；2.2.5需求管理在软件项目中，所有的项目相关方都感兴趣的就是需求分析阶段。这部分工作若处理好了，能开发出很出色的产品，同时会使项目各方感到满意。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有项目相关方必须重视需求分析过程。软件需求包括四个层次：业务需求、用户需求、功能需求、非功能需求。优秀需求所具有的特性：完整性、正确性、可行性、必要性、划分优先级、无二义、可验证。需求分为需求开发和需求管理。需求开发包括：问题获取、分析、编写规格说明和验证四个阶段。需求管理包括建立和维护软件需求。·甲方在需求活动中的权利和义务。通常来说，甲方在需求活动中有如下权利：1．要求分析人员使用符合客户语言习惯的表达。2．要求分析人员了解客户系统的业务及目标。3．要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。4．要求开发人员对需求过程中所产生的工作结果进行解释说明。5．要求开发人员在整个交流过程中保持和维护一种合作的职业态度。6．要求开发人员对产品的实现及需求都要提供建议，拿出主意。7．描述产品使其具有易用、好用的特性。8．可以调整需求，允许重用已有的软件组件。9．当需要对需求进行变更时，对成本、影响、得失有个真实可信的评估。10．获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。甲方在需求活动中有如下义务：1．给分析人员讲解业务及说明业务方面的术语等专业问题。2．抽出时间清楚地说明需求并不断完善。3．当说明系统需求时，力求准确详细。4．需要时要及时对需求做出决策。5．要尊重开发人员的成本估算和对需求的可行性分析。6．对单项需求、系统特性或使用实例划分优先级。7．评审需求文档和原型。8．一旦知道要对项目需求进行变更，要马上与开发人员联系。9．在要求需求变更时，应遵照开发组织确定的工作过程来处理。10．尊重需求项目中开发人员采用的流程（过程）。·需求变更控制流程软件需求作为系统功能的范围界定和说明，其变更必须进行严格的变更控制管理。本项目中，建议建立如下需求变更控制流程：1．成立需求变更控制委员会，由项目管理组、项目业务技术组组成，并向项目领导组负责。2．软件开发面对初始经评审后的需求。3．在项目执行过程中，如发生需求变更，需求变更提出者需提交所在单位业务技术组该维度负责人员，由该维度负责人员签字确认后提交需求变更控制委员会，并通知项目组。4．如项目组对需求变更无异议，该需求将进行开发实施。5．如项目组对需求变更有异议或该变更的评估分析结果对项目造成重大影响，该需求将提交需求变更控制委员会集体讨论，根据讨论结果决定该需求的处理方式。6．需求建立统一的标识体系，以方便其管理。2.2.6沟通和监控机制在项目执行过程中，可以通过以下手段对项目执行情况进行跟踪和监控：1.召开项目例会a)项目负责人在每周召开项目例会，项目周报、项目实施计划进度跟踪情况是例会的重要输入，例会的主要内容包括但不限于：i.项目状态检查及进度跟踪；ii.当周重要事项的汇报；iii.下周详细 工作计划 幼儿园家访工作计划关于小学学校工作计划班级工作计划中职财务部门工作计划下载关于学校后勤工作计划 ；iv.变更请求状态检查；v.近期需提交的工作产品状态检查；vi.项目成员工作情况检查b)其他各组负责人在每周提前召开本组项目例会，参与项目负责人召开的项目例会。2.编制项目周报a)各组负责人每周编制“项目周报”，提交给项目负责人；b)项目负责人汇总各组负责人周报，定期或不定期向客户方、监理方汇报项目进展。3.编制里程碑总结a)各组负责人在每个里程碑结束，编制“里程碑总结报告”，提交项目负责人；b)项目负责人汇总各组里程碑总结，向客户方汇报项目里程碑进展。4.召开管理评审会议项目负责人在重要里程碑结束或项目进展异常时，组织各组负责人和必要人员，召开管理评审会议，安排项目进展工作，对重大问题进行解决。管理评审会议侧重关注项目状态和管理协调问题，技术问题不作为管理评审的主要内容，“里程碑总结报告”、“项目管理问题管理表”是管理评审的重要输入。5、项目会议纪要项目会议是整个项目实施过程中项目组常态的共同方式，会议纪要统一由监理方记录和形成最终会议纪要，作为项目实施过程的组成部分，发给项目组主要成员。2.2.7风险管理2.2.7.1风险管理过程风险管理作为项目重要的预防活动，将会比出现问题后的纠正更为有效的提高项目质量，降低项目成本，确保项目按期完成。项目各阶段开始前识别该阶段存在的各种风险，预先进行缓解，并制定应急方案，将项目风险对项目造成的影响降低到最低。1.风险分析项目任务书下达后，在项目策划阶段由项目经理组织项目组成员、项目总监、公司项目管理人员以及部门相关资深人员召开风险评估会议；在会议上发给会议成员项目前期的有关资料，参照组织文件的“风险类型与示例”识别出开发/实施过程中的全部风险，明确风险类型，制定风险控制措施。项目经理负责按照会议结果填写《项目风险管理表》；项目的各阶段开始前，或项目发生重大变更时，由项目经理协同项目组成员识别新的风险，修正前期识别出的不准确的风险，调整风险控制措施，关闭已消失或已发生的风险，进一步完善《项目风险管理表》，按照评审要求进行适当等级、形式的评审；注意事项：·为确保风险控制与风险监管的有效执行，制定的风险控制措施应清晰描述时间、人员、活动，不要简单描述概述性风险控制策略；·在项目实施过程中如有需与客户协商的重要活动（例如产品交付、系统割接等），项目经理必须会同客户代表在实施前进行风险分析，以保证该项活动的顺利实施；·《项目风险管理表》建立以及每次更新后，项目经理必须将风险管理的相关信息以适当形式告知项目组成员，并负责将《项目风险管理表》发送给全部项目组成员及公司受风险影响的各级相关人员，确保风险管理过程的全员参与。2．风险控制项目经理组织项目组成员按照已确定的风险控制措施实施风险控制；项目经理负责风险控制措施实施后按照实际执行情况完善《项目风险管理表》的“控制措施”列信息。3．风险监管部门项目管理人员根据已制定的控制措施对项目风险进行跟踪监管，以保证风险控制措施的确实实施。将对控制措施的验证信息实时填写入《项目风险管理表》；部门项目管理人员在项目总结阶段，以完成的《项目风险管理表》为依据，协同项目经理对该项目进行过程中的风险进行整理总结，填写“项目风险总结分析”，负责对组织文件的“风险示例”进行更新，为其他项目的风险管理提供有用的信息。2.2.7.2项目风险分析项目各阶段开始进行风险识别与控制，并对应不同阶段总结出各自典型的风险，给出相应的风险级别和风险值计算方法。本项目建设过程中可能存在的主要风险有： 序号 风险名称 控制措施 1 需求未能明确，比如需求不统一，需求模糊等 业务部门需要全力参与到数据中心的建设中，加强沟通渠道，扩大需求调研在整个工程安排的比例。双方分专业设立需求和设计负责人，归口统一管理。 2 设备配置不能满足系统的设计要求 在需求调研完成以后，根据系统设计需要提出硬件配置要求，并对现有设备进行评估，最大限度的利用现有设备和网络环境。如果必要，提前执行补充硬件设备的采购 3 内部多部门配合，外部厂商、单位协调 由于本项目的建设涉及多个部门，的数据来源于各个业务专业信息不同的系统，如何协调相关资源成为项目建设中重中之重。因此建立项目领导小组，指定专人协调，筹措必要的项目配合费用。 4 业务数据质量较差 业务数据质量如果较差，将会严重影响系统分析及展现功能的可用性，需要向业务部门和人员进行说明。 5 开发、测试的环境及工具无法及时到位 合理安排进度计划，加强与供应方的沟通，寻找内部替代资源。 6 项目实施过程中最终用户有抵触情绪 提前进行最终用户培训，争取客户领导支持，合理制定实施计划。 7 开发过程中有待研究解决的技术难点 制定弹性进度计划，寻求软件平台提供商的支持，与客户进行协商。2.2.8配置管理2.2.8.1版本控制工具的使用版本控制是项目管理中直接涉及开发人员代码开发效率的重要问题。我们选用SVN(Subversion)来控制系统版本。2.2.8.2集中式管理工作流程集中式代码管理的核心是服务器，所有开发者在开始新一天的工作之前必须从服务器获取代码，然后开发，最后解决冲突，提交。所有的版本信息都放在服务器上。日常开发人员工作流程如下:1、开始新一天的工作，从服务器下载项目组最新代码。2、开始工作，每隔一个小时向服务器自己的分支提交一次代码。3、下班时间前将自己的分支合并到服务器主分支上，一天的工作完成。2.2.8.3文档编制工具主要用到以下几种工具：MSWord、MSExcel、MSVisio、MSPowerPoint、MSProject、RationalRose。1、MSWord：主要用来编写描述性文档，例如项目章程、管理流程、需求报告、业务蓝图、项目状态报告、项目总结报告等；2、MSExcel：主要用来编制检测表、各种项目计划、数据准备表、问题及变更日志等；3、MSVisio：主要用来绘制业务流程图；4、MSPowerPoint：主要用来编制各种报告、培训性文档；5、MSProject：主要用来制订项目进度计划、资源计划、预算计划，并跟综项目，生成各种汇报结果；6、RationalRose：主要用来绘制与UML相关的用例图、序列图、活动图、状态图等。2.2.8.4版本管理软件有版本的区别，文档也一样：对于每一份文档的版本号管理，以下面的规则为准：说明：版本号分总号与子号，例如Vl.0，其中的1为总号，0为子号。1、创建文档时为V1.0版；2、在未经客户方审阅前的内部审阅和修改。版本总号不变、子号递增，如：V1.1、Vl.2；3、经项目经理或客户方的审阅或修改后，则版本号升级，如：V2.0；4、当文档最终确定后，统一提交项目经理或文档管理员存档，若需要修改须通过变更流程。在每一份文档的开头，就会有类似这样一个表格说明了版本控制的信息：表1‑1：版本控制信息说明表 版本/修订版 修改确认日期 修改内容概述 修改人 批准人 备注 2.2.8.5文档管理原则所有的项目文档应严格按照文档控制标准进行：1、从项目经理接手项目开始就指定专人建立负责项目文档管理，归集项目所有电子和书面文档，并建立文档目录。文档起草、修改人应标注编写日期和主要修改内容。文档编制时，要严格按照项目规定的标准操作，例如页眉、页脚、标题、内容编排、字体字号等，是否按标准进行，作为项目质量检测的一部分；2、文档须通过双方相关责任人和项目经理的会签；最终版本的文档须经过双方项目总监的签署并作为交付文档保存；3、文挡的发放去向应准确记录收件人的姓名。对于电子文档，收件人应及时回复审阅意见。对于阶段性交付成果应同时保存具备签字的书面介质的文档原件，对于重要的邮件也要作为文档进行存档备份；4、对于失效版本的文档，要单独放置在一个目录中，并设置屏蔽权限防止误用；5、所有文档均适用于服务合同约定的保密条款；6、项目结束后，整理归集所有项目文档，电子文档存放在专门的文件服务器上，或刻盘保存；将书面文档按项目进度分类整理，扉页档案目录整理，装订成册，交项目档案管理人员保存。第3章培训方案3.1人员培训方案3.1.1培训目标为保证本项目的建设运行质量，更好地满足应用需求，应提高项目管理、建设、运维、应用人员的业务、技术水平，在本项目的实施中组织多方面、多层次的培训。通过培训使应用部门的管理人员和技术人员等系统应用人员、系统运维人员以及指定的相关人员能够熟练掌握业务流程和软件系统的操作流程，熟练操作各系统的功能模块，独立承担系统维护等工作。3.1.2培训方式培训方式主要包括：1、采用集中讲解、系统演示、同步实际操作相结合的方式。2、根据不同使用对象进行贴心的个性化培训。3、配备《用户培训手册》，学员可以随时根据需要学习。3.1.3培训内容培训内容主要包括以下两个方面：1、对相关系统应用人员培训使之能够了解系统的主要功能和应用范围，能够熟练应用系统进行工作，并能结合实际工作需要提出各种改进意见。培训内容主要包括计算机、网络、安全基础知识培训，提高管理人员在信息化环境下的管理能力、应用水平，提高工作效率和业务管理水平。2、系统运行维护人员的培训系统运维人员培训主要包括以下几个方面：IT技术培训、IT服务管理的培训、项目管理的培训、业务系统的培训。通过培训使系统运维队伍能够充分掌握各种先进的IT技术和经验，从技术上和管理上保证系统的正常运行，从而保障各项业务的顺利运行。为了保障系统安全稳定运行，还应对系统运行维护人员进行设备特性、系统功能、故障诊断、安全技术与操作、系统备份与恢复以及 管理制度 档案管理制度下载食品安全管理制度下载三类维修管理制度下载财务管理制度免费下载安全设施管理制度下载 等方面的培训。3.1.4培训内容具体培训内容需要在项目开展过程中视具体情况而定，但至少包含以下四种类型的培训：·标准规范体系培训内容：应用系统的体系规范标准。·应用系统培训内容：各个应用子系统的使用。·IT、网络安全的基础知识培训内容：网络方面、安全方面的基础知识。·安全的基础知识，内容：安全方面的基础知识。培训对象：省系统管理和运行维护人员。·应用支撑平台软件培训内容：了解和掌握数据库、应用中间件、应用支撑平台开发、开发工具的使用。培训对象：省级系统管理和运行维护人员。3.2培训方案设计3.2.1标准规范体系培训培训内容：业务标准规范体系、技术标准规范体系。培训对象：本部及其他相关管理人员。 序号 培训内容 学时 地点 教材 承担培训的机构和人员安排 备注 1 顶层设计标准体系规范 4 待定 自编 培训讲师 2 XXX机制标准体系规范 4 待定 自编 培训讲师 3 应急管理流程及处置规范 4 待定 自编 培训讲师 3.2.2基础知识培训培训内容：本项目本次涉及到的相关基础知识，如网络、互联网监测、工控安全等。培训对象：本部相关人员。 序号 培训内容 学时 地点 教材 承担培训的机构和人员安排 备注 1 IP网络持基础培训 4 待定 自编 培训讲师 2 互联网安全知识基础培训 4 待定 自编 培训讲师 3 工控网络、工控企业及工控安全培训 4 待定 自编 培训讲师 3.2.3应用系统培训培训内容：互联网安全监控系统使用及维护、综合管理服务平台使用及维护培训。培训对象：系统使用相关人员培训。培训方式：授课、演示、讨论，上机实际操作、考核。 序号 培训内容 学时 地点 教材 承担培训的机构和人员安排 备注 1 互联网安全监控系统使用及维护 4 待定 自编 培训讲师 2 综合管理服务平台使用及维护培训 16 待定 自编 培训讲师 3.2.4现场培训现场培训是实施方的工程师到现场安装调试相关设备和系统，用户有关技术人员在现场观看和学习，并给予适当实际操作机会，对学习产生的问题随即解答，具有很强的实践和交互性，但人数不能过多。这种方式的培训在所有设备的安装和调试中都将积极予以实现。3.2.5培训资料根据不同的培训层次和培训对象，提供不同的培训资料，培训资料以纸质文档和相应的电子文档方式予以提供。培训资料的来源是原厂商提供的技术文献等相关资料。第4章软硬件部署4.1系统部署结构图4‑1系统部署架构将XXX系统部署在海南省高级法院内网系统，既能够海南省政府数据中心机房部署的电子政务网站监测，也可通过互联网对部署在各党政机关的重要电子政务网站监测；XXX系统通过本地电子政务网对电子政务应用系统及系统的相关对象进行扫描分析。信息安全监管部门、信息安全技术支撑单位通过互联网，在安全用户认证的方式下访问本平台系统。4.2系统网络拓扑结构图4‑2系统内部网络部署结构图XXX系统设备采用旁路部署平台服务器去的汇聚交换机上，对工信厅提供的专有对外访问通道进行对外访问与监测。4.3设备部署机房环境要求本项目涉及新增采购两台设备，设备对机房环境要求如下：4.3.1电压和频率变动范围要求电压：单相交流，220V+4％，-8％（198～232V）频率：50Hz+/-0.5Hz瞬间电压波动不能超过220V+/-15%，且必须在25个周期(0.5秒)内恢复，对用于磁盘存储设备的，则需在三个周期内恢复。总谐波（Harmonic）成分不得高于5%。4.3.2电源插座类型要求由机柜配备的16或10安培电源分配板（PDU）,由配电盘给每一个机柜引出若干条数的容量16或10的电缆及对应套数的16安培的插头插座。需要分配2-4个PDU插口。4.3.3接地电阻要求电源保护地线的专用接地线电阻应小于1欧姆。测量零-地电压值应小于1V。4.3.4温度湿度要求机房内最佳作业环境A)温度：10℃～35℃最佳：22℃B)相对温度：20%～80%最佳55%C)机房最大温度变化率<5℃/h，不结露4.4平台系统部署软件需求 工具 名称 用途 操作系统 Windows2008 企业级服务器操作系统。 数据库 SQLServer2008  功能完备的数据库管理系统。它包括支持开发的引擎、标准的SQL语言、扩展的特性(如复制、OLAP、分析)等功能。4.5平台系统服务器需求4.5.1正式部署环境要求针对本项目需提供满足如下性能指标的服务器设备或虚拟服务器资源，存储空间的要求。·应用服务器 指标 技术要求 CPU Intel®Xeon4核2.G以上 处理器数量 2 内存 ≥8GBPC2-3200ECCDDR2内存 硬盘 300G 网卡 2×10/100/1000M网卡 电源 配置冗余电源·数据库服务器 指标 技术要求 CPU Intel®Xeon4核2.G以上 处理器数量 2 内存 ≥8GBPC2-3200ECCDDR2内存，最大支持64G 硬盘 300G 网卡 2×10/100/1000M网卡 电源 配置冗余电源·存储需公共存储划拨1.2TB空间归属本项目。 服务器 存储要求 应用服务器存储空间 100GB 应用服务器存储空间 100GB 数据存储空间 1TB4.5.2开发测试部署环境要求 服务器名称 数量 主要安装软件 CUP、内存 服务器类型 备注 应用系统服务器 1 Windowsserver2008及以上版本、IIS7.0及以上版本 4核CPU、8G以上内存、500G硬盘 服务器 数据库服务器 1 Windowsserver2008、MicrosoftSQLServer2008及以上版本 4核CPU、8G以上内存、500G硬盘 服务器 项目文档管理服务器 1 Windowsserver2008 2核CPU、2G以上内存、500G硬盘 服务器 4.6其他需求4.6.1办公场所需求甲方需提供乙方可容纳6人的办公场所，为现场实施人员、开发人员、监理人员现场办公场所。4.6.2网络环境·开发环境局域网办公网络建议提供可连接至省党政中心分配的部署系统环境网络，保证开发人员统一的网络环境。·互联网接入提供互联网接入点，供实施人员通过互联网获取相关的技术资料、收发邮件及远程协助支持等。（全文完）变更请求分析影响确定新负责人明确交接期限召开交接短会对当前工作内容和产品进行整理和完善制定交接计划按计划交接工作交接评审变更结束PAGE可编辑协议范本！_1234567890.vsd���_1234567891.vsd�����