《软件项目管理计划书》最佳模板.docxVIP

软件项目管理计划书 项目名称： 时间： 年 月 日 目录1.简介31.1.项目概述31.2.项目主要功能及性能31.3.项目交付产品31.4.参考资料32.项目组织32.1.过程模型32.2.团队的分工与合作43.管理过程43.1.管理目标及优先级43.2.风险管理53.3.监督及控制机制53.4.人员计划53.5.培训计划63.6.风险管理计划63.7.项目配置计划73.8.计划更新策略73.9.项目沟通计划83.9.1.项目组会议83.9.2.项目报告机制83.10.项目的重用计划93.11.质量保证活动93.11.1.内部审核93.11.2.阶段审核94.技术过程104.1.开发工具、方法和技术104.2.软件需交付的文档105.开发进度安排及预算115.1.进度表格描述115.2.开发过程中的资源需求115.3.软件管理过程中预算及资源分配125.4.项目进度及关键工期设置12简介项目概述项目主要功能及性能项目交付产品 （1）提交文档：项目管理计划、需求规格说明，设计报告、测试报告、用户使用手册和项目个人总结。其中项目总结为每人一份，每个小组所有成员的总结装订在一起；其余文档每组提交一份。每个团队可将各小组的文档综合到一起，各小组也可自行分开提交，具体方式由团队内部协商确定。所有文档需要提交电子版和打印稿。（2）源程序检查：一共参考资料项目组织过程模型关键时间任务要求团队的分工与合作主程序员负责制。本团队组织关系图如下。成员角色职责管理过程管理目标及优先级 风险管理监督及控制机制报告机制：1. 要求各组员以周为单位记录工作进展，形成开发日志，并以电子文档的形式提交给秘书进行整理，最后由文档维护员进行维护。2.每周例会上各位组员积极对当前的开发工作进行积极的评审和建言，由组长做最后的作口头总结，由秘书主持会议并记录和整理会议的内容。文档维护员修改和维护相应的文档。并交由小组进行会议评审并给出意见。3. 组成员都要密切监控风险状态，发现风险后提交风险报告。由秘书定期提交风险报告。必要时将突发风险通知所有组员，并由组长做出临时处理决定。然后在该周的例会上由组成员共同讨论对风险的处理意见。并形成风险处理的日志做为以后的经验。报告格式：报告主题，时间段，发现人，报告内容，审核意见评审机制：每周例会上小组讨论形成一致意见后即为通过，相关负责人针对改进意见开展下一周工作，严格执行例会上锁制定的决策。小组会议持续评估其成效。每一项目阶段结束之前（里程碑前后），组织一次阶段评审会，评估整个阶段的工作效率和成果质量。尽量与项目例会合并，并邀请组长和其他组成员参加评议。亦可询问领导的意见。对于重大的风险处理意见，应该由组长及其他组组长组成评审团对处理意见进行审议和评估。并以评审团的决议（亦可根据老师的建议）作为重要参考来制定决策。人员计划java程序员： 要求：熟悉java编程和jsp开发平台界面设计员： 要求：熟悉CSS、Photoshop数据库设计员：要求：熟悉SQL语句，熟练使用SQL Sever 2005文档维护员：要求：熟悉使用Word及Powerpoint沟通交流员：要求：较强的沟通能力，能及时调解组内以及组与组之间的矛盾。软件测试人员： 要求：熟练使用开发工具的debug工具，有耐性。培训计划在本节中，明确说明相应人员现有的水平、需要的技能 、培训方式和培训效果评估方式信息。举例如下：培训计划No培训领域需要的技能水平项目组成员已具备的技能水平培训方式培训效果评估方式123风险管理计划（可根据项目选择来写，没有也可不写）在此详细说明项目的风险项、风险描述、风险级别、规避措施、应急计划、触发条件。存在哪些技术、市场和财务风险？已确认的风险和假设是否已解决？有无遗留问题？有无新的风险和假设？提供简洁的风险管理计划。为了减少风险，在各阶段必需做些什么？如果在计划的时间范围内，这些风险不能解决，有没有准备其它的计划？如果没有这些风险，对项目会有哪些影响？与产品包相关的各方面的风险包括：市场/客户风险；技术风险；财务风险；制造风险；采购风险；技术支持风险；项目风险项目配置计划（可根据项目选择来写，没有也可不写）计划更新策略在本节中，应描述项目计划的更新策略，明确说明项目计划更新的发布方法。还要说明对项目计划进行变更控制和管理的机制以及其载体。以下文字仅供参考：在发生如下事件时，修订项目计划和参考文档：到达某里程碑，在每个阶段结束后如果必要的话修订项目计划。项目的范围发生变化当风险成为现实时采取了相应的行动当进度、工作量超出控制的范围并需要采取纠正行动时。当与上阶段规模变化超过+/-15%。内部或外部审核导致的纠正活动对修订后的项目计划按照项目管理规程来批准和签发。项目计划的更新，存在阶段驱动性更新和事件驱动性更新两种类型。阶