CMMI体系文件项目计划过程文件.docx
《CMMI体系文件项目计划过程文件.docx》由会员分享,可在线阅读,更多相关《CMMI体系文件项目计划过程文件.docx(16页珍藏版)》请在冰豆网上搜索。
CMMI体系文件项目计划过程文件
枯藤老树昏鸦,小桥流水人家,古道西风瘦马。
夕阳西下,断肠人在天涯。
XXXX有限公司
项目计划过程文件
文件编号:
版本号:
1.0
编制:
日期:
审核:
日期:
批准:
日期:
受控编号:
实施日期
文件修订记录
时间
作者
主要修订内容
1目的
本文件的目的是描述项目计划过程,指导制定合理的项目计划。
2适用范围
本过程适用于公司的所有软件开发项目。
3资源和工具
引用标准:
CapabilityMaturityModel®Integration(CMMISM),Version1.1
工具:
MicrosoftWord
MicrosoftExcel
MicrosoftVisio
MicrosoftVisualSourceSafe
4定义和缩写
表1定义和缩写表
术语/缩写词
定义
工作分解结构/WBS
工作任务的安排及其彼此之间的关系,以及与最终产品之间的关系。
5职责
表2角色职责表
角色
职责
研发部门经理
审核项目计划
项目经理
制定项目计划
项目组成员
协助项目经理制定项目计划及下属计划
配置管理员
管理项目计划变更
客户/客户代表
参与制定项目计划
6过程
6.1项目总计划
6.1.1启动条件
《项目立项审批表》审批通过。
6.1.2输入
《项目论证报告》
《项目立项审批表》
6.1.3活动
●根据《项目论证报告》、《立项审批表》初步定义项目目标和范围。
●识别项目类型,确定验收标准。
合同类项目以用户合同验收为标准。
其它类型项目,以定版作为验收标准。
●确定项目的定义、设计、实现、测试、发布阶段的任务和时间。
定义阶段需要说明需求获取方式、需求收集时间、需求评审时间及评审参与人。
●项目经理确定已知项目成员,并指定系统分析员。
6.1.4输出
《项目总计划》
6.1.5关闭标准
《项目总计划》审批通过
6.2项目计划
6.2.1过程流程图
图1项目计划过程流程图
6.2.2启动条件
《用户需求说明书》审批通过
6.2.3输入
《项目论证报告》
《项目立项审批表》
《项目总计划》
《用户需求说明书》
6.2.4活动
6.2.4.1确定项目目标和范围
●根据《项目论证报告》、《立项审批表》、《用户需求说明书》对已定义的项目目标和范围进行细化。
●确定的项目目标必须是“可实现的”和“可验证的”。
如果本项目是作为子项目存在,应对总项目进行概述,并指明本项目在总项目中的作用及与其他子项目之间的关系。
●确定的项目范围,应说明构成项目的基本框架,明确定义项目边界,即指明“做什么”和“不做什么”。
对于非特定客户项目,需要说明“适用领域”和“不适用领域”。
6.2.4.2确定项目组织
图2项目组织图
表3项目角色与职责
角色
职责
高级管理层
具有项目最高决策权;处理部门间不能达成一致的问题;参与评审QA活动结果;
配置控制委员会
负责审核和批准对配置项所提出的更改;保证已批准的更改能得到实施;
评审组
评审工作产品;
研发部门经理
项目组织行政管理;协调处理项目组内不能达成一致的问题;项目监控
质量部门经理
分配和协调QA、测试工程师工作;组织评审QA的活动;组织评审测试相关文档;
项目经理
制定并维护项目计划;分配和协调项目成员工作;组织评审项目工作产品;保证项目执行进度,制作项目进度报告;发现项目偏差,提出纠正措施并执行;与客户沟通;汇总度量数据,进行度量分析;
系统分析工程师
用户需求收集与分析;系统分析与概要设计;指导详细设计;
软件工程师
详细设计;代码编写;单元测试;编写用户手册;收集度量数据;
美术工程师
美术方案设计;
配置管理员
制定配置管理计划;标识配置项,建立并维护项目配置库、基线库;
定期地审计配置项;记录配置管理活动;
测试工程师
编写测试相关文档;进行集成测试、系统测试;
QA
编写QA的相关文档;负责质量审计与评审工作
6.2.4.3确定项目的技术方法
根据《项目论证报告》、《立项审批表》、《用户需求说明书》确定项目系统体系结构。
包括技术架构、运行平台、网络环境、实现工具等。
6.2.4.4确定项目目标和范围
--确定项目的目标:
客户需求、技术指标、质量目标等;
--由项目经理根据需求并按照《任务分解结构(WBS)指南》制定粗略的WBS。
--WBS分解后作为估算的基础。
--WBS分解在后续活动中可以继续分解,逐步细化。
6.2.4.5确项目生命周期模型
按照《软件生命周期模型选择指南》来选择项目的生命周期模型。
6.2.4.6项目过程及活动的裁剪
--由项目经理根据裁剪指南进行项目过程裁剪,定义项目必须执行的过程和活动,QA可以提供帮助和咨询。
--《裁剪报告》应报EPG审核并通过后才能执行。
--按照《标准软件过程裁剪指南》进行裁剪。
6.2.4.7项目估算
项目经理组织项目组成员进行需求的分析、根据公司财富库中的历史数据、按照《估算指南》对项目进行估算,估算结果要记录在《项目估算表》中。
--估算规模:
根据《估算指南》选择估算方法,在WBS分解(产品结构分解)的基础上,自底向上估算各模块的规模;
--确定难度系数:
为规模估算结果选择难度系数。
难度系数或称复杂度是指在实现当前模块(系统)时考虑的实现难度、人员水平、复杂程度等因素的综合系数,目的是调整团队、项目特点等与估算数据,特别是使用的历史数据之间的差异。
--估算工作量:
采用生产率计算方法估算工作量,其中生产率系数取自公司财富库的历史数据。
在估算模块的规模及难度系数的基础上,通过公式--工作量=规模/生产率,并乘以难度系数得到各模块的估计工作量,汇总各模块的工作量,即得到总工作量。
--估算开发成本:
项目成本应包括开发人力成本以及采购、费用等其它成本,这里仅估计项目开发人力成本。
开发成本=工作量*人员平均成本。
其中人员平均成本取自公司财富库的历史数据。
--估计进度:
根据公司财富库给出的工作量分布数据,计算得到项目各阶段的工作量,在项目人员、项目总工期等约束条件下,估计各阶段的工期,即各里程碑到达时间。
6.2.4.8确定项目里程碑
确定里程碑到达时间、工作产品、完成标准以及里程碑允许的偏差。
里程碑
时间及偏差
工作产品
完成标准
必要性
需求管理
20%
软件需求规格说明书
评审通过
必须
系统设计
20%
设计说明书
评审通过
必须
系统实现
20%
源代码、单元测试报告(可选)、集成测试报告(可选)
评审通过
必须
系统测试
20%
系统测试报告
评审通过
必须
系统交付
20%
验收报告、手册等
客户确认通过
必须
表4瀑布模型里程碑列表
6.2.4.9制定项目进度计划
●项目工作分解:
项目工作包含分析、设计、编码、测试、评审等。
分解方法:
首先根据项目阶段划分三级工作任务,定义各阶段要完成的工作任务。
其次逐层细化下一级的工作任务。
定义、设计阶段可以根据工作产品进行细分;实现阶段可以根据项目模块进行细分;测试与发布阶段根据执行活动进行细分。
根据《任务分解结构(WBS)指南》分解项目的工作任务,建议使用Project工具,如:
《项目进度计划.mpp》。
●项目进度计划中应包括任务名称、任务开始与结束日期、持续时间、责任人、进度图、与其他任务的依赖关系。
●持续时间根据项目规模可以设置为天、周、月。
●根据项目需要,在项目的各个阶段可制定项目阶段进度表。
●识别项目关键路径。
●确定出现进度偏差时必须进行决策的偏差门限。
6.2.4.10制定项目监控计划
●项目监控可以采用每周简报、定期监控、里程碑监控、事件驱动四种方式进行项目监控活动。
●由项目经理根据项目属性(规模、复杂度、周期等)选择一种或几种项目监控方式,制定项目监控计划。
6.2.4.11制定项目风险计划
制定项目风险计划,参见风险管理相关文件。
6.2.4.12制定数据管理计划
●识别需要纳入数据管理计划的范围。
如:
合同、参考资料、原始资料、书籍、标准等资料。
资料借阅可以到配置管理员处进行借阅,由配置管理员记录借阅信息。
定义关键数据的内容、格式或模版。
●确定不同项目数据的表现形式,如电子文件、纸制文件。
●制定数据的存放机制,定义存放数据的目录结构。
●定义数据的责任人及相关人员的使用、查阅范围。
●定义数据的收集时间或收集间隔。
6.2.4.13制定软硬件资源计划
●硬件资源
硬件是作为软件开发项目的一种工具而投入的。
在软件项目计划期间,应考虑以下三种硬件资源:
主机器:
服务器和客户端机器
外围设备:
与计算机相联系的设备,如打印机等
其它硬件设备:
专用软件开发时需要的特殊硬件资源软件资源
软件工具:
在软件开发期间用到的软件工具,如管理工具、编程工具、测试工具、支持工具等。
软件库:
指在软件开发中用到的软件部件库,可能是现成的可复用的软件库或外购的软件库。
●软硬件资源计划
分析项目开发、测试及用户使用产品所需的软硬件资源,制定软硬件资源计划,主要内容包括:
资源级别(分为“关键”、“普通”二种)、详细配置、获取方式(如“已经存在”、“可以借用”或“需要购买”等)、计划获取时间、用途(如“谁”在“什么时候”用);
6.2.4.14制定人力资源计划
●根据执行项目需要的知识与技能,确定项目参与人。
●指定项目参与人的职责,识别项目的关键人员。
●为已知的项目成员分配角色(一个人可以兼多个角色)。
●制定项目相关人员的参与、接口、交互计划。
表5项目角色职责
角色
项目阶段和活动
定义
设计
实现
测试
发布
需求收集
需求分析
概要设计
详细设计
编码
单元测试
集成测试
系统测试
生产
实施
确认
项目经理
Δ
Δ
Δ
Δ
Δ
Δ
Δ
Δ
Δ
Δ
Δ
系统分析工程师
Δ
Δ
Δ
Ο
Ο
Ο
软件工程师
Δ
Δ
Δ
配置管理员
Ο
Ο
Ο
Ο
Ο
Ο
Ο
Ο
Ο
Ο
Ο
美术工程师
Ο
Ο
试工程师
Ο
Δ
Δ
QA
Ο
Ο
Ο
Ο
Ο
Ο
Ο
Ο
Ο
Ο
Ο
售后工程师
Δ
Δ
Δ
注:
Δ责任人;Ο参与人
6.2.4.15制定干系人介入计划
●确定项目干系人名单、参与理由。
●根据项目阶段识别干系人与介入时间。
6.2.4.16制定评审计划
●确定项目需要评审的内容。
如:
里程碑评审、进度评审等。
●识别评审活动的级别,如必须的、可选的。
●根据评审内容定义评审类型。
●确定评审活动的时间与参与人。
6.2.4.17制定决策计划
●项目进度、工作量、成本差异等执行偏差超过门限时,确定需要决策的内容、时间、参与人。
●决策活动参见决策相关的过程文件。
6.2.4.18制定培训计划
●根据执行项目必须的知识与技能分析项目参与人需要培训的内容。
●按照项目参与人的技能欠缺情况和项目进度表安排培训时间、培训讲师、培训人员。
6.2.4.19制定验收计划
●对于合同类项目,根据用户合同,制定验收计划。
●对于以定版为验收标准的项目,根据定版要求,制定验收计划。
6.2.4.20确定下属计划
下属计划是对《项目计划》的补充。
包括:
●配置管理员制定《配置管理计划》
●测试工程师制定《测试计划》
●QA制定《质量保证计划》
●项目经理制定《度量分析计划》
6.2.4.21编写项目计划
项目经理汇总上面的信息后整理出《项目计划》并提交评审。
参见《项目计划》模板。
6.2.4.22评审项目计划
●由项目经理组织协调项目计划的评审工作。
●参与评审成员为项目成员、测试人员、配置管理员、QA、研发部门经理、质量部门经理、客户或客户代表。
●项目经理负责提交《项目计划》进行评审,下属计划可以同项目计划一同进行评审,所有计划评审通过后才能进行项目的具体工作。
项目计划的所有任务都要和任务的相关人员协商并达成一致意见,评审结论记录到评审报告中。
●高层经理批准《项目计划》。
●具体评审细节按照《评审工作规范》有关要求执行。
6.2.5计划修订
在《概要设计》完成后,项目组进行第二次估算,估算过程参照项目估算过程。
6.2.6计划变更
当计划执行过程中,项目经理需要及时对计划进行调整,若下列情况之一发生,应当变更原《项目计划》:
●当项目计划参数发生显著偏差并预计对里程碑目标的影响超过阈值时;
●项目过程模型发生了显著的变化;
●用户需求发生了重大的变化,使得项目计划参数发生偏差且预计对里程碑目标的影响超过阈值时;
●发生了对项目小组而言不可抗拒的变化,例如公司裁员、机构调整、产品发展战略调整等。
审批变更申请变更申请
项目经理填写《项目变更申请》,申请变更项目计划。
变更申请书中应当说明:
●变更原因
●变更的内容
●此变更对项目造成的影响
●如果是合同项目,可能还要向客户提出变更申请,视具体情况而定。
6.2.6.1审批变更申请
项目经理组织项目计划变更评审,参加评审的人员包括项目组成员、相关小组成员、QA、高层经理等,必要时,可邀请客户参加项目计划变更评审。
具体细节按照管理评审规范执行。
项目计划变更申请评审结果需经高层经理批准后方可执行。
如果审批结论不同意变更,则退回变更申请,项目按原计划执行,如果审批结论同意变更,由项目经理组织修改项目计划及相关下属计划,生成新的项目计划。
新的项目计划应按照项目计划评审流程进行项目计划评审并批准后方可执行。
6.2.7输出
《项目估算记录》
《项目计划》及下属计划
6.2.8关闭标准
《项目计划》审批通过。
7验证
●将所有工作产品纳入配置管理。
●项目经理负责对此过程进行管理。
●QA对过程实施进行审计,检查该过程是否按照规范执行。
●高层经理应了解该过程的活动、状态和结果,并解决问题。
●EPG收集过程改进建议,对过程进行持续改进。
8度量
●完成项目计划的工作量。
●项目估计规模
●项目估计工作量
●项目估计进度
●项目估计成本
9培训
对项目经理、项目组成员进行工作分解、项目估算、数据管理、时间安排等的培训。