IT项目计划清单实用模板

word密级 Confidentiality Level报告版本Report Version页数Total Pages报告编号：项 目 开 发 计 划项目号：项目名称：编制人：部门：日期：初审Pre-Reviewed by日期Date复审Reviewed by日期Date批准Approved by日期Date所有侵权必究All Copyright Reserve19 / 19目 录1 容简介4文档目的4文档围42 项目概况43 项目组织结构44 项目依赖关系分析55.1 项目关键路径分析与保障措施55.2 项目依赖关系分析55.3 项目关键成功因素65.3 技术方法和工具65 交付件66 项目计划76.1 项目的里程碑计划76.2 项目WBS计划highlevel计划97 人力资源和技能需求98 项目所需其它资源10关键物料需求计划10实验设备和环境资源计划119 资料开发计划1110 对外合作计划1211 外包任务12子承包商资料12外包任务的围12里程碑、交付件1212 预算/分配可选1213 验收标准可去掉1214 质量计划(也可单独成文档)1312.1 项目过程定义1312.2 质量目标1312.3 通过技术手段保证质量1412.4 质量控制活动1412.5 质量保证活动1515 项目沟通计划1614.1 项目组会议1614.2 项目报告机制1616 项目的重用计划16现有重用构件16新增重用构件1717 配置管理计划1718 问题1719 风险管理计划1720 客户的参与1821 培训计划1822 计划更新策略191 容简介1.1 文档目的这局部要描述文档的目的，应该指明读者。1.2 文档围简要描述本计划需要在该产品项目中完成的工作活动与其工作目标、项目采用的生命周期、项目交付物、相关人员的角色和职责、主要里程碑、进度计划、质量计划、配置管理计划、风险计划等。2 项目概况简要描述本项目的类型新产品/改良/维护类、项目的目的、围、目标例如：项目的市场定位，产品需求等。3 项目组织结构PDT组织结构图PDT与系统分析与设计组成员建议，产品开发成员建议在决策评审点前与适当的PRB成员与相关资源部门经理对这些列表进展沟通的结果描述项目的组织结构，建议采用图表的表示方式。也可参考下例：下表定义了项目成员的角色和职责。l 在审核之前项目经理需指定所有文档和代码的审核人。l 对于各个角色的职责定义可根据项目实际情况进展补充。l 下表容应当至少在项目的每个阶段完毕时进展更新。对于项目阶段中/ 阶段间发生的组织结构的变化，项目经理应当通过周知所有相关人员，然后更新项目计划。表4 项目的组织结构 No.角色向谁报告备份资源1客户代表2产品QAPQA3PDT经理版本经理1版本经理14市场代表MKTPDT5技术支持代表TSEPDT6制造代表MNFPDT7采购代表PROPDT8财务代表FPDT9开发代表(RDPDT)系统工程师(SE)软件经理硬件经理结构经理开发组长PL1开发组长PL210变更控制委员会CCB11技术评审专家Reviewer4 项目依赖关系分析5.1项目关键路径分析与保障措施在本节中，分析影响项目进度的关键步骤/环节、关键因素，并提出保障措施5.2项目依赖关系分析在本节中，说明项目的部依赖关系(如：开发测试工具、人力资源等)和对外部的依赖如项目之间、与客户之间的技术、资源等方面。可用依赖性列表、活动网络图的方法描述。列出所有影响项目计划的假设因素(相对于的因素)。如果这些假设因素有误，或者没有利用到假设因素，或者假设因素发生变化都会使项目受到影响。另外还要描述项目对外部因素的依赖关系，例如，如项目作为整个大系统的一局部，需要其他局部提供接口定义或者PDT提供正在开发的仿真性能测试工具以代替实际环境测试等等请参考下例：表1 项目依赖关系Sl. No依赖于通常指接口等责任人状态OPEN正在进展/CLOSE已经关闭最早提供日期验收条件(如果有)1235.3项目关键成功因素关键成功因素影响高/中/低依赖关系行动计划5.3技术方法和工具在本节中，描述对产品项目进展需求分析、设计、实现、测试、文档写作、发布、修改、或维护过程中采用的开发方法、组织结构和其他标记、工具、技术和方法。此外，对使用的技术标准、方针和流程也要用直接描述或参考到其它文档的方式进展说明。参考下例，对于产品项目所需要的硬件、软件和其他工具设备用下表描述：表2 技术方法和工具分类名称型号数量开始使用日期完毕使用日期仪表专用仪表开发工具5 交付件在本节中，应描述需要交付给下游部门的工作产品与其需求。这些交付工作产品应包括各种设计文件、图纸、文档等。交付工作产品应分解成可管理的大小粒度。这局部容如在配置管理计划或文档计划中给出，如此可以指出相关文档名称或者给予即可。可以采用列表方式。举例如下：表3 项目交付工作产品交付工作产品名称产品描述质量保证活动验收标准交付件形式总体设计文档XXX项目XX总体设计方案正规检视与评审归档/发布文档详细设计文档XXX项目XX详细设计归档/发布文档归档/发布归档/发布文档归档/发布文档归档/发布文档归档/发布文档6 项目计划6.1项目的里程碑计划 关键里程碑计划可采用图形方式。将项目的所有里程碑和关键活动标注在下面的时间轴上。注意：如果存在早期功能子集Beta和/或ESP交付件，PDT 需要对交付件进展TR4A/TR5评审，以与对GA层产品交付件进展TR4A和TR5评审。PDT不需要对每一个构件标注TR4，只需要标示第一个TR4的日期。如果需要将所有里程碑和关键活动标注出来，可将时间轴划分成阶段，如上所示。 也可采用如下例子的形式描述里程碑计划。表5 项目里程碑计划阶段估计完毕日期交付件验收准如此可去掉TR1需求评审和概念DR市场调研报告立项阶段输出市场需求清单立项阶段输出初始业务计划立项阶段输出产品需求规格书TR2总体方案评审和计划DR产品可行性分析报告/产品业务计划产品开发计划总体设计方案书/产品设计说明书产品测试与验证计划工艺总体方案装备总体方案初始物料清单供给商和物料选择计划物料认证计划提前采购决策TR3模块级概要设计评审模块级概要设计/总体设计各模块级测试报告目标本钱跟踪表市场教育和培训计划测试方案TR4原型机评审原型机原型机测试报告TR5设计定型评审中试样机验证报告制造系统验证报告BETA测试完毕BETA测试报告外部认证完毕系统认证和标杆测试报告TR6转产评审和发布DR产品可行性分析报告/产品业务计划优化后市场发布材料清单受控销售阶段评估报告试产验证测试报告制造系统验证报告量产点GA量产检查点确认通知6.2项目WBS计划highlevel计划参见项目的WBS计划，请指出具体存放位置。7 人力资源和技能需求 也可采用下表格式：对项目组人员提出可能会影响项目进度的技能要求，例如：CPU应用技能、VxWorks BSP技术等。Sl. No.资源名称阶段1人数、技能要求阶段2人数、技能要求阶段3人数、技能要求阶段4人数、技能要求说明1项目经理2XX业务代表3硬件组4软件组结构组测试组 也可采用下表格式：Sl. No.资源名称人数起始日期完毕日期技能要求说明12348 项目所需其它资源9.1 关键物料需求计划详细描述在不同阶段对关键物料的需求计划。可单独形成关键物料需求计划。或 可单独形成供给商物料选择计划也可采用下表：表6 关键物料需求计划关键物料描述计划采购到货时间预期最长采购周期计划采购数量概念、计划阶段物料 XXX器件开发阶段物料 XXX器件验证与发布阶段物料 XXX器件注：项目组应充分估计各物料的采购周期，在各关键点应提前下达采购需求给采购部门。增加提前采购，供给商选择参见提前采购计划表模板：新物料提前采购清单，局部物料可以从该表COPY过来项目组应该计划好首次量产前包括工程样机、中试样机、首次量产的所有物料，并根据后续量产的数量、时间结合市场的计划等给出建议。9.2 实验设备和环境资源计划详细描述在不同阶段对不同的环境的需求计划。如特殊的硬件平台、测试设备、软件工具等。标准的办公硬件不必在这里列。举例如下：表6 实验设备和环境资源计划阶段描述数量计划使用时间区段说明概念分析计划阶段开发阶段验证阶段9 资料开发计划表7资料开发计划资料类别资料名称责任人计划完成时间验收准如此1. 用户类资料用户手册客户产品布XXX评审2. 营销类资料市场部YYY评审3技术支持类资料开发/ 测试评审4应用开发资料开发/测试10 对外合作计划参照总体设计文档“外包外购的相应规格列出需要对外合作的局部。包括合作容，进度要求等11 外包任务10.1 子承包商资料子承包商名联系人通讯地址10.2 外包任务的围10.3 里程碑、交付件里程碑分配给子承包商的工作产品计划开始日期计划完成日期给公司的交付件12 预算/分配可选估计产品的预算与分配讨论主要的未解决问题，包括资金投入的与时性与性质。将实际日期的项目资源、本钱和时间进度与估计的整个项目的资源、本钱和时间进度进展比拟。13 验收标准可去掉客户的验收标准就是产品应满足在需求规格文档中描述的需求。系统测试和验收测试将证实产品与需求规格保持了一致。14 质量计划(也可单独成文档)12.1 项目过程定义1） 选择开发模型开发类，增强类，维护类 2并可在此根底上进一步流程裁剪：提供与标准开发流程的偏差，并说明裁剪原因。12.2质量目标可以定性或定量描述，为提高可控制性，尽量采用定量质量指标描述。假如能定量描述，请参考下表：参考或直接引用项目度量表中质量目标局部的数据。表9 项目质量目标NO.项目质量目标目标基线暂不填上限暂不填下限暂不填说明1进度偏差率80%2需求稳定性903硬件第一次样机制作完成前缺陷发现数目=34样机投板次数20%5软件发布前缺陷发现密度6编码缺陷发现密度7硬件/软件总体设计缺陷发现数目8硬件/软件详细设计缺陷发现数目9需求更改/设计更改/工程更改数10文档齐套性11返修率.12.3 通过技术手段保证质量通过哪些技术手段可以保证质量目标和关键性能指标的达成。 例如：通过静态代码分析工具和自动化软件测试工具可以有效提高软件质量。12.4质量控制活动罗列执行的质量控制活动。12.4.1技术评审活动产品开发过程中需要哪些技术评审活动，哪些技术评审点可以合并？各技术评审点的评审要素的裁剪说明tw 技术评审1和技术评审2合并 TR1与TR2的评审要素合并，并裁剪，评审要素重点放。，而。方面要素可免去。w 技术评审3TR3的评审要素需裁剪，评审要素重点放。，而。方面要素可免去。w 技术评审4TR4的评审要素需不裁剪；w 技术评审5TR4的评审要素需不裁剪；w 技术评审6TR4的评审要素需不裁剪；12.4.2 正规检视活动同行评审产品开发过程中需要设置对哪些输出的正规检视活动？w 软件模块测试计划w 软件概要设计w 软件代码w 软件测试报告w 硬件总体设计w 硬件电路原理图和PCB图w 硬件测试报告12.4.3 测试对测试策略和测试活动进展说明：也可合入文档产品测试与验证计划l 测试活动合并裁剪例如：增强类项目，集成测试和系统测试可以合并。l 单元测试测试质量目标测试依赖关系分析测试停止准如此l 集成测试测试质量目标测试依赖关系分析测试重点回归测试策略测试停止准如此l 系统测试测试质量目标测试依赖关系分析测试重点回归测试策略12.5 质量保证活动罗列应该执行的质量保证活动。举例如下：12.5.1 部审计每个项目在开发生命周期中至少进展一次部审计。12.5.2交付件审计(按阶段)w 技术评审1之后w 技术评审2之后w 技术评审3之后w 技术评审4之后w 技术评审5之后w 技术评审6之后12.5.3基线审计规划在哪些阶段点需要进展基线审计。w 技术评审1之后w 技术评审2之后w 技术评审3之后w 技术评审4之后w 技术评审5之后w 技术评审6之后15 项目沟通计划14.1 项目组会议列举项目跟踪、监控的会议类型、频率以与参加人员，可以采用列表形式。参考下例：表7 项目组会议No会议频度参加人跟踪机制1.阶段完毕会议2.项目总结会议3.14.2 项目报告机制列举项目跟踪、监控过程中需要出示的报告类型、频率、报告人、汇报人信息。参考下例：表8 项目报告机制No.报告准备人频度向谁汇报1.项目状态报告2.项目阶段完毕报告3.项目总结报告4.16 项目的重用计划需要对公司其他产品在本产品中实现重用进展分析以与本产品可以共享给公司的其他产品以供重用，可以直接相应的文档或者在此加以说明。15.1 现有重用构件Sl. No构件/文档名采用阶段(If applicable)重用构件的资产ID1215.2 新增重用构件序号构件/文档名需求/文档id说明12注：资产库中已有的重用构件2项目产生的新的重用构件17 配置管理计划项目的配置管理活动应该按照配置管理计划来执行。参见XXX项目配置管理计划。18 问题列出项目初期任何其他已经发现的问题，包括组间协调、实验环境、工作场所等问题。Sl. No问题责任人状态打开/关闭最早关闭日期1219 风险管理计划按照风险管理规程来管理项目的风险。祥见XXX项目风险管理计划。在此详细说明项目的风险项、风险描述、风险级别、躲避措施、应急计划、触发条件。具体操作方法请参考风险评估和管理相关文档。存在哪些技术、市场和财务风险？已确认的风险和假设是否已解决？有无遗留问题？有无新的风险和假设？提供简洁的风险管理计划。为了减少风险，在各阶段必需做些什么？如果在计划的时间围，这些风险不能解决，有没有准备其它的计划？如果没有这些风险，对项目会有哪些影响？与产品包相关的各方面的风险包括：市场/客户风险；技术风险；财务风险；制造风险；采购风险；技术支持风险；项目风险20 客户的参与Sl. No序号在哪些方面阶段、工作产品等参与期望客户承当的职责最大响应时间说明123421 培训计划在本节中，明确说明相应人员现有的水平、需要的技能、培训方式和培训效果评估方式信息。举例如下：表10 培训计划No培训领域需要的技能水平项目组成员已具备的技能水平培训方式培训效果评估方式123导师计划也应包含在本培训计划中，该类计划在“培训方法一栏需标识“导师培训。22 计划更新策略在本节中，应描述项目计划的更新策略，明确说明项目计划更新的发布方法。还要说明对项目计划进展变更控制和管理的机制以与其载体。以下文字仅供参考：在发生如下事件时，PM修订项目计划和参考文档：到达某里程碑，在每个阶段完毕后如果必要的话修订项目计划。项目的围发生变化当风险成为现实时采取了相应的行动当进度、工作量超出控制的围并需要采取纠正行动时。当与上阶段规模变化超过+/-15%。部或外部审计导致的纠正活动对修订后的项目计划按照项目管理规程来批准和签发。项目计划的更新，存在阶段驱动性更新和事件驱动性更新两种类型。阶段驱动性更新是指在每一阶段完毕时，如果计划或者工作量估计的变动超过10，就需要对项目计划进展更新；事件驱动性更新是指在计划执行过程中遇到项目突然变动或者其他影响项目正常运行的事件发生，需要对项目的计划进展更新。项目计划更新需要对计划文档更新和项目里程碑计划的更新。不论是阶段驱动性更新还是时间驱动性更新都需要对项目的更新计划进展评审，评审需要PDT经理、PQA以与功能领域代表参加。