项目管理过程规范.docx
- 文档编号:10724446
- 上传时间:2023-02-22
- 格式:DOCX
- 页数:37
- 大小:31.94KB
项目管理过程规范.docx
《项目管理过程规范.docx》由会员分享,可在线阅读,更多相关《项目管理过程规范.docx(37页珍藏版)》请在冰豆网上搜索。
项目管理过程规范
项目管理过程规范
目录
1目的和范围6
2职责定义6
3项目开始过程6
3.1目的和范围6
3.2目标6
3.3进入标准6
3.4有效输入6
3.5活动7
3.5.1制定软件项目任务书7
3.6输出7
3.7退出标准7
4项目策划过程7
4.1目的和范围7
4.2目标7
4.3进入标准7
4.4有效输入7
4.5活动8
4.5.1确定项目组织结构8
4.5.2建立任务细分结构8
4.5.3建立项目定义的软件过程8
4.5.4建立项目度量(可选)9
4.5.5估计软件工作产品规模9
4.5.6估计项目工作量10
4.5.7估计项目关键计算机资源10
4.5.8计划项目软件工程设施和支持工具11
4.5.9制定项目进度表11
4.5.10制定软件培训计划12
4.5.11识别并分析项目风险12
4.5.12制定项目计划12
4.5.13记录计划数据13
4.6度量13
4.7验证13
4.8输出13
4.9退出标准13
5项目监督和控制14
5.1目的和范围14
5.2目标14
5.3进入标准14
5.4有效输入14
5.5活动14
5.5.1项目计划跟踪14
5.5.2项目定义的软件过程的更改15
5.5.3文档量跟踪15
5.5.4工作量跟踪15
5.5.5关键计算机资源跟踪16
5.5.6软件工程设备跟踪16
5.5.7项目进度跟踪16
5.5.8风险跟踪17
5.5.9软件工程技术活动跟踪17
5.5.10项目承诺跟踪17
5.5.11非正式项目评审17
5.5.12正式里程碑评审18
5.5.13月例项目/质量评审18
5.6度量18
5.7验证18
5.8输出19
5.9退出标准19
6项目结束过程19
6.1目的和范围19
6.2目标19
6.3进入标准19
6.4有效输入19
6.5活动和规程19
6.5.1收集项目经验19
6.5.2组织项目总结会议20
6.5.3建立项目档案20
6.5.4组织项目结束会议(必要时)20
6.6度量20
6.7验证20
6.8输出20
6.9退出标准21
7项目管理规程21
7.1代码量估计21
7.2工作量估计21
7.3关键计算机资源估计22
7.4开发项目进度表22
7.5风险管理规程23
7.5.1风险识别23
7.5.2风险管理计划23
7.5.3风险跟踪25
7.6项目评审会26
7.6.1项目状态周报26
7.6.2非正式周项目评审会26
7.6.3里程碑评审27
目的和范围
本文档是软件项目管理的指南,包括项目启动、项目策划、项目监督和控制和项目结束等过程的管理,其适用于项目经理管理软件项目、也可作为第三方监理公司审核项目管理活动的一个基础。
职责定义
在确定项目后,需要定义好项目中相关的角色并赋予角色相应的职责和权力;需要定义的角色包括如下:
Ø高级经理(企业高层项目决策人)
Ø商务经理
Ø项目经理
Ø系统架构师
Ø系统设计师
Ø软件开发工程师
Ø测试工程师
Ø质量协调员
Ø配置管理代表
项目开始过程
目的和范围
项目启动过程的目的是使研发团队内部和市场对系统本身的开发问题达成一致。
目标
制定软件项目任务书
制定系统功能说明书
进入标准
产品或市场需求
项目启动通知(既产品研发立项通知)
有效输入
用户需求说明书或等效的用户需求文档(其它部外获得的产品研发需求)
组织目标
历史项目信息
活动
制定软件项目任务书
软件产品研发任务书是产品管理部和软件项目组之间建立的高层工作协议。
进行可行性研究
确定项目必要的特性列表
确定项目假设、依赖和约束
估计项目所需的关键资源
制定、评审并签字批准软件项目任务书
将软件项目任务书纳入配置管理之下
输出
项目任务书
产品功能说明书
退出标准
软件产品研发任务书和产品功能说明书已确认,并形成基线
项目策划过程
目的和范围
项目策划过程的目的建立可行的计划,用于开发软件产品和监控软件项目。
项目策划包括选择软件生命周期模型、分解工作任务、估计工作量、分析软件项目风险、建立必要的承诺和制定项目计划。
项目计划是执行和管理软件项目活动的基础,同时根据软件项目的资源、约束和能力做出承诺。
目标
对软件规模进行估计,用于制定软件项目计划和进行项目跟踪
计划软件项目活动和承诺
相关组和个人同意他们对软件项目的承诺(包括测试,质量管理,市场和销售)
进入标准
软件项目任务书和产品功能说明书已确认,并形成基线
有效输入
产品目标
业务流程
项目策略
软件产品需求
初步的项目计划(可能有)
历史项目的经验
活动
确定项目组织结构
确定项目组织结构、角色与职责,其间沟通机制和问题的上报机制;
建立任务细分结构
一旦明确了系统需求,则必须完成产品规模的估计。
多数情况下,估计产品规模就是估计产品的代码量。
估计的前期工作是将系统需求分解成为多个任务,对每个任务定义它的工作过程并估计它的大小,并且可以由个人或小组完成。
任务分解的目的是精确地估计代码量并建立详细的进度表。
任务细分结构要求如下:
体现软件项目任务书要求,从而达到产品目标
用图形方式描述要完成的工作
任务细分应达到能有效计划和控制每一工作元素的程度
描述工作元素之间的内部关系
为每个工作元素指派负责人
促使管理者和其他人员考虑项目的所有工作元素
根据分配给软件的需求,项目经理必须制定项目任务细分结构,并详细定义软件活动和工作产品。
在项目开发过程中,必要时可以修改任务细分结构。
任务细分结构把整个软件项目分解为可独立安排、易实施、易跟踪的工作元素。
任务细分结构作为计划、组织和控制项目工作的基本框架。
建立项目定义的软件过程
设计项目定义的软件过程基于:
客户需求
软件产品需求
承诺
商业环境和目标
运行环境
建立项目定义的软件过程的步骤为:
选择组织确认的软件生命周期模型
从标准软件过程库中选择最适用项目要求的软件过程
把当前项目和历史项目的经验融合到本项目中
根据软件过程剪裁指南,从标准软件过程库和其它过程资源中剪裁项目定义的软件过程
在适当情况下,使用组织软件过程相关文档库中的已有的工作成果
在项目计划中描述项目定义的软件过程
对项目定义的软件过程进行同行评审
对影响项目定义的软件过程的问题达成一致
对项目定义的软件过程进行配置控制
必要可修改项目定义的软件过程
建立项目度量(可选)
项目经理必须建立并维护用于项目控制的度量值。
软件质量工程师帮助项目经理完成此任务,并在项目的软件质量保证计划中进行描述。
选择和定义度量方法,此度量能够适用检查软件项目的活动和工作产品
定义测量数据的收集策略
与相关人员评审选择的测量方法,并达成一致
在必要时修改度量方法
估计软件工作产品规模
任务细分结构极其工作元素为软件工作产品规模的估计提供了一个框架,在估计过程中主要考虑以下几点:
以一个详细的任务细分结构为基础进行估计
精确定义度量标准
估计每个工作元素的大小
每个元素估计大小的总和为整个工作产品的估计值
申请适当的费用
在代码量估计中用到的度量值应该是合理的、容易使用和测量的。
比较代码量估计大小与实际大小,研究比较结果并保存在组织数据库中,作为今后项目的历史数据。
多数项目规模估计采用代码行数估计的方法。
软件规模是估计工作量、成本和进度的主要输入,这些估计基于软件的相似性、复杂度和结构。
软件工作产品大小估计指南:
1.软件工作产品估计基于分配的软件需求
2.将软件工作产品分解成能实现精确估计的较小部分,任务细分结构是软件工作产品分解基础
3.必要时明确软件外部需求
4.明确软件是否能被复用
5.估计所有主要软件工作产品大小或变更大小,使用适当的历史数据验证估计结果
6.软件质量工程师必须评审软件工作产品大小估计的步骤
7.应用软件工作元素大小估计的附加因素识别软件风险
8.确定能够影响软件工作产品大小的主要因素
9.在项目策划过程中,评审影响软件规模估计的问题,并达成一致
估计项目工作量
完成项目规模估计后,应该确定完成这些工作需要的时间。
项目经理应该使用模型、历史数据和软件工作产品大小来确定项目工作量。
工作量的估计是在明确产品需求与产品规模的基础之上,由项目经理组织相关人员,采用估计方法与经验值来完成的。
工作量估计指南如下:
10.明确执行软件工作的关键能力和角色
11.工作量(成本)估计的基础
软件产品需求与系统需求
任务细分结构
软件工作产品大小估计的结果(考虑变更的大小)
软件外部需求
可复用的软件
完成工作的管理者和个人的技能水平
培训需求
选择的软件生命周期和软件过程
在软件工程环境中所提供的软件工具的性能
需要的办公设施(如:
办公室、会议室、投影仪、工作站等)
需要的软件工程设备
12.估计软件项目总工作量和总成本
基于每项软件工作产品的工作量和成本统计出项目的生产力和成本
13.使用适当的历史数据验证工作量、成本估计结果
14.估计工作量/成本和人员在整个软件生命周期中的分布
15.建立每项任务工作量/成本
16.与相关组评审工作量/成本估计的结果,并达成一致
17.必要时,修改工作量/成本的估计值
估计项目关键计算机资源
项目经理应该明确项目关键计算机资源,并进行关键计算机资源估计。
关键计算机资源可以是服务器环境、测试环境、目标环境等。
确定影响产品开发的关键计算机资源的内存容量、硬盘容量和处理器(数量/频率)内容,项目经理负责监督资源消耗的资源数量,并且当资源有限时进行适当的调整。
关键的计算机资源可以是以下的一种或几种:
内存容量
处理器频率
硬盘容量
网络容量
外围设备容量
关键计算机资源估计基于:
软件需求
软件工作产品规模估计
处理器负载估计
网络环境
项目关键计算机资源估计可以运用历史项目经验、原型和项目分析等方法。
调整计划的计算机资源、系统需求、分配给软件的需求、软件需求和软件设计等以获得关键计算机资源需求。
为各软件组件分配计算机资源,并确保关键计算机资源能够提供其可利用的能力。
建立关键计算机资源的上下限,当项目需求超出此范围时,要采取相应措施。
评审影响关键计算机资源估计的问题,并达成一致。
在必要时修改关键计算机资源估计值。
计划项目软件工程设施和支持工具
设备资源、设施和支持工具必须在项目进度表完成之前进行估计,获得或升级软件开发工具,提高网络容量,明确需要的许可证数量,以及关键设备等。
关键资源估计基于软件开发和测试需求、任务描述和组织标准数据库的历史数据。
项目经理负责详细说明所需的资源,并且协调影响项目进度和成本等的资源。
计划软件工程设施和支持工具的过程如下:
18.软件工程设施的估计基于分配的软件需求、软件工作产品大小及其变化量、工作量/成本估计、组织经验和其它项目特征。
19.在项目计划中描述需要的设施,如果项目需要使用实验室设备,则必须制定实验室使用计划,并通过实验室支持组的评审。
20.为获得软件工程设施指派负责人进行协商,并达成一致。
21.评审影响提供软件工程设施的问题,并达成一致。
22.必要时,修改项目计划。
制定项目进度表
项目进度表的制定应该基于:
分配的软件产品需求
任务细分结构
选择的软件生命周期模型和过程
软件规模/工作量/成本的估计
承诺或预期的资源和设施的可用性
里程碑、关键依赖日期和其它进度约束
项目进度表包括:
项目进度表制定的依据
确定里程碑、任务、承诺、关键依赖、人员及工作量
确定各活动的时间段
确定软件活动时间和里程碑以支持度量的精确性及是否符合承诺
确定向客户交付软件产品的里程碑
确定适当的里程碑
确定各里程碑期间的项目活动
使用适当的历史数据验证时间进度表
确定并协商软件进度表中的关键依赖,包括在软件工程组内(例如:
子工作组之间)和软件工程组与其它相关组之间的关键依赖
在软件进度表中确定进度表关键路径
为每个关键路径建立上下线,当项目超出此范围时,要采取相应措施
评审影响项目进度的问题,并达成一致
在必要修订项目时间进度表
制定软件培训计划
项目组必须明确项目开发中需要的知识和技能,对其进行评估,并选择提供需要的知识和技能的培训机制(内部培训、外部培训等)。
软件项目技术方面培训和指导要求在项目的开始阶段实施,参与人员包括项目经理、开发人员、项目支持人员、维护和测试人员。
项目经理负责安排技术培训。
如果任何项目组成员需要另外的培训,或项目组成员必须为其他小组提供培训,这些培训活动要求预先计划。
项目经理应该为这些培训活动制定时间表,并在项目计划中的培训计划章节和任务细分结构/进度表中进行描述。
识别并分析项目风险
风险是在项目过程中可能发生的事件,它的发生将对产品结果产生不利影响。
项目计划模板要求项目经理去识别、分析、制定优先级、降低、消除并跟踪项目风险,使其不影响项目目标的实现。
在确定项目风险时,项目经理组织尽可能多的项目成员进行讨论,以获得多方面的意见。
完成项目风险的识别后,项目经理制定风险列表,为项目风险跟踪提供依据。
参考项目风险管理规程。
制定项目计划
此处项目计划包括项目计划、软件质量保证计划、软件配置管理计划、实验室使用计划等。
项目经理负责制定项目计划,包括:
23.描述项目目的、范围、目标等
24.确定项目组织结构及问题处理机制,组间协调关系及渠道
25.详细描述选定的软件生命周期模型
26.确定遵循的过程、标准、规程和方法等
27.详细描述项目的任务细分结构
28.描述培训安排
29.描述估计的内容,包括:
软件工作产品的大小的估计和软件工作产品变更的大小
工作量和成本的估计
关键计算机资源估计
软件项目进度表,包括确定的活动和里程碑
30.描述软件项目需要的设备
31.描述软件项目风险
32.相关人员对项目计划进行评审并达成一致
33.对项目计划进行配置管理
34.在必要是修改项目计划
制定的项目计划必须获得个人、项目组和组织相互的理解和承诺,并支持项目计划的执行。
制定项目计划时,请参考《项目计划模板》。
记录计划数据
项目经理应该记录初始计划的数据和每次重新计划的数据,并保存在项目信息管理数据库中。
度量
在软件项目计划活动中,里程碑的实际完成情况与计划的比较
在软件项目计划活动中,实际工作量与计划工作量的比较
输出
项目计划(任务细分、估计、项目进度表、风险管理计划、项目培训计划等等)。
软件配置管理计划和软件质量的审核计划
如果涉及到实验室的使用,需要制定实验室使用计划
退出标准
项目计划通过评审、正式批准,并形成基线。
项目监督和控制
目的和范围
项目监控的目的是为软件项目开发过程提供足够的可见性,以便当项目严重偏离计划时及时采取纠正措施。
项目监控包括根据估计、承诺和进度表跟踪软件计划执行情况,监控软件项目风险,当实际工作与计划有严重偏离时及时采取纠正措施。
项目计划是软件活动跟踪、汇报项目状态和项目计划修改的基础。
项目经理负责软件活动跟踪。
项目经理监控软件活动,主要通过在所选出的软件工作产品完成时和在所选择的里程碑处,将实际的软件工作产品大小、工作量、成本和进度与计划相比较,来确定进展情况。
当确定软件项目计划没有得到满足时,采取纠正措施。
这些措施可以包括修订软件开发计划以反映实际的完成情况,以及重新策划遗留的工作或者采取措施改进性能。
目标
根据计划跟踪实际结果和性能
当实际结果和性能明显偏离软件计划时,采取纠正措施并加以管理,直到完成
更改的承诺需得到相关组和个人的认可
进入标准
项目计划(项目计划、软件配置管理计划、软件质量保证计划等)被正式批准
有效输入
项目计划(项目计划、软件配置管理计划、软件质量保证计划等)
实际的项目数据
活动
项目计划跟踪
项目计划用于跟踪项目活动和通报项目状态。
项目计划的修改反映实际完成情况,其有效协调软件工程组、项目经理、高层管理者和其他相关组的活动。
项目计划跟踪的内容至少包括:
人员状态跟踪
任务细分结构
项目定义的软件过程
软件规模跟踪
项目进度跟踪(里程碑、甘特图)
工作量跟踪
风险跟踪
修改项目计划的规程如下:
当计划有明显改变时,或软件项目任务书的要求与项目不符时,需修改项目计划
计划的修订需反映所有新的软件项目承诺和承诺的变更
对修改的项目计划版本进行评审
项目计划受配置管理的控制,这表明在某一时间点上使用的项目计划的版本是已知的,并且项目计划的更改是按更改控制规程进行的
项目估计的变更是在事件驱动的情况下进行的,例如额外的项目特征增加了原始估计的代码量,因此需要更新估计的代码量
项目经理应该定期的组织项目评审,其评审的主要内容是确认计划的执行情况,评审会议要有会议纪要
项目定义的软件过程的更改
项目经理必须根据以下情况确认项目定义的软件过程的更改:
从项目活动监控中获得的经验
项目范围或项目任务要求发生大的变化
过程和工作产品的度量数据
组织标准软件过程的改变
如果发生没有计划的活动并严重影响了项目的进展,项目经理需要评审项目定义的软件过程,确认是否需要修改项目定义的软件过程。
当需要修改项目定义的软件过程时,项目经理要与质量管理部质量管理人员对修改需求进行评审,遵循过程剪裁指南,并在项目计划中修改项目定义的软件过程。
同时其它与项目定义的软件过程相关的文档需作相应的修改。
在必要时,修改了项目定义的软件过程的项目计划需高层管理者正式批准。
文档量跟踪
在项目策划阶段,进行项目文档量估计,并填写在项目计划中。
根据所选的软件工作产品完成情况和选择的里程碑,跟踪、精炼、调整和重新估计项目文档量。
跟踪和修改文档量估计的步骤如下:
35.从完成的项目文档中获得实际的文档量
36.注意:
在文档没有完成之前,也要进行项目文档量跟踪。
37.从还没有完成的文档中获得新的估计结果
38.注意:
不要忘记去掉近期完成的文档的估计结果
39.文档量估计将为以后的项目所使用,因此建议在项目计划中进行维护
40.修改项目计划,反映最新的文档量估计
工作量跟踪
将实际的工作量/成本、人员、培训和项目计划中工作量估计进行比较
确定与项目计划中工作量估计的偏离程度
评价影响偏离工作量估计的因素
评审软件项目工作量/成本状态。
修改工作量/成本的估计值时,比较实际超出的工作量和项目计划中工作量估计值,从而使以后工作量估计更准确
监控工作量/成本的上下限,超出时要采取相应的措施
人员配备和工作量/成本的改变影响到软件承诺时,要与相关组达成一致
必要时,修改项目计划。
关键计算机资源跟踪
跟踪项目关键计算机资源,必要时采取纠正措施。
关键计算机资源的跟踪可以通过非正式的项目评审会(如周例项目会议)进行。
将实际提供的关键计算机资源与项目计划中估计的关键计算机资源进行比较
确定与项目计划中估计的偏离程度
评价偏离造成的影响
监控关键计算机资源提供的上下限,超出时要采取相应的措施
计算机资源的改变影响到软件承诺时,要与相关组达成一致
必要时,修改项目计划
软件工程设备跟踪
跟踪项目软件工程设备,必要时采取纠正措施。
项目软件工程设备的跟踪可以通过非正式的项目评审会(如周例项目会议)进行。
评审提供软件工程设备,根据项目需要在项目计划中明确
确定与项目计划中明确要求的偏离
评估偏离造成的影响
软件工程设备的改变影响到软件承诺时,要与相关组达成一致
必要时,修改项目计划。
项目进度跟踪
跟踪项目进度,必要时采取纠正措施。
比较活动的实际完成情况、里程碑和其它约束
确定与项目计划中明确要求的偏离
估计软件活动、里程碑是否延期和提前的工作量,其它的约束是否影响以后的活动和里程碑等
软件进度表的修改影响软件约束时,要与相关组商议并达成一致
若开发的软件分为几个功能单元或子系统,要跟踪每个阶段单元的完成百分比,也就是说要跟踪每个单元的设计、编码、单元测试、集成测试和系统测试等
定期跟踪项目的关键依赖和关键路径
监控项目进度时间上下限,超出时要采取相应的措施
必要时,修改项目计划
风险跟踪
跟踪与成本、资源、项目进度、项目技术有关的软件项目风险,参考项目风险管理过程。
在项目周评审会和项目总体报告会议上评审项目风险状态
当有其它信息可利用时(如:
附加的风险和消除的风险等)修改风险的优先级和发生的可能性
必要时,修改项目计划
软件工程技术活动跟踪
项目经理负责跟踪软件工程技术活动,必要时采取纠正措施。
在周工作报告中描述软件工作中的问题
跟踪所有的问题,直到问题被解决
在每个阶段(从需求阶段到测试阶段)收集所有软件的错误和缺陷
跟踪软件的错误和缺陷,直到被解决
跟踪解决错误和缺陷花费的工作量
项目承诺跟踪
项目经理应该监控内部/外部的承诺是否符合项目计划中的内容。
项目启动后新增加的承诺以及改变的承诺涉及到组织外部的个人和小组时,需要遵循下列步骤同高级管理者评审:
评审内部和外部的承诺。
可以通过非正式的项目周例会评审内部承诺,项目里程碑评审会和项目总体报告会上评审内部和外部的承诺
明确没有被满足的承诺,或没有被满足而带来风险的承诺
估计项目进度、成本、工作量和资源对项目承诺的影响
基于估计结果,提出修改承诺建议,此建议包括估计的结果和项目经理的建议
必要时,修改项目计划
非正式项目评审
项目组需定期评审项目技术进展、结果和问题,建议每周进行非正式的项目评审。
41.项目组成员要以项目计划为基础执行活动
42.定期(建议每周进行)与项目经理和个人交流某一项目活动和软件工作产品的技术状态
43.收集并分析用于控制软件项目的度量数据
44.识别严重问题和偏离项目计划的问题
45.记录对软件工作产品和过程的更改请求和问题报告单
46.以会议纪要的形式记录评审结果,并分发给所有的参与人员
47.跟踪变更请求和问题报告,直到问题被解决
48.必要时,修改项目计划
正式里程碑评审
在里程碑处必须组织软件产品评审,提供的证据和考虑的问题如下:
软件工作产品已经完成
软件工作产品符合规范
软件活动符合项目的进度要求
项目组准备进行下一步的活动
项目开发和维护活动按照项目计划、进度表、标准和项目定义的过程的要求进行
项目经理负责组织并领导正式的评审(如:
设计准备评审、编码准备评审、测试准备评审、发布准备评审等),评审项目计划中指定的里程碑处项目的结果和完成情况。
项目组成员、软件质量保证员、软件配置管理代表应参加里程碑评审会议。
49.在项目进度表中的某一时间点组织评审,如可以选择在阶段(需求、设计、编码/单元测试、集成测试、系统测试等)完成时进行。
在主要的里程碑处,客户方相关人员参加评审会。
50.评审会涉及项目承诺、计划、状态和项目风险等内容
51.明确严重问题
52.估计解决问
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 管理 过程 规范