软件项目监控规程 (1).doc

软件项目监控规程 (1).doc

《软件项目监控规程 (1).doc》由会员分享，可在线阅读，更多相关《软件项目监控规程 (1).doc（9页珍藏版）》请在冰豆网上搜索。

XXX股份有限公司

统一过程管理体系

软件项目监控规程

版本号2.0

修订历史

版本

发布日期

生效日期

修订说明

作者

审核人

批准人

当前状态

目录

1.目的范围 4

2.角色职责 4

3.术语定义 4

4.活动规程 5

4.1任务分配 5

4.2状态监控 5

4.3分析纠正 6

4.3.1问题分析 6

4.3.2采取措施 6

4.4定期检查 6

4.4.1迭代审查 6

4.4.2里程碑评审 7

4.4.3阶段性验收 7

4.5信息收集 7

4.6状态报告 8

5.裁剪指南 8

6.层次关系 9

6.1主控文件 9

6.2支持文件 9

6.3相关文件 9

7.附录 9

1.目的范围

l目的作用：

为软件项目监督和控制活动提供规范指导，以便更好地控制项目进展情况及趋势，当项目实际运行与计划偏差超过一定范围时及时采取适当的纠正措施。

l应用范围：

事业中心、项目中心。

l读者对象：

事业中心、项目中心相关人员。

2.角色职责

角色名称

职责描述

高级经理

1.检查软件项目监控活动。

2.参与里程碑评审，并担任评审组长。

项目经理

1.工作任务分配。

2.定期或事件驱动监控项目状态。

3.分析问题、制定纠正措施，并组织实施。

4.主持项目里程碑评审会议。

5.每月定期汇报项目状态。

QA工程师

1.指导并评审项目监控活动。

2.参与里程碑评审会议。

软件工程师、CM工程师、测试工程师

参与里程碑评审会议。

3.术语定义

l里程碑：

由相关人负责、按计划预定、具有零历时的重要事件，通常用于测量工作进度。

l阶段里程碑：

指在项目阶段结束时设置的里程碑点，如“精化阶段”结束时标志着“架构里程碑”的到达。

l关键事件里程碑：

指不是阶段里程碑，但又非常关键的重要事件，如完成需求调研、设备采购到位、通过内部验收、通过专家评审等。

l高级经理：

指项目归属部门的负责人，一般为项目经理的直接上级经理，可以是事业部总经理、研发部经理等。

l同望项目管理实施专区：

用于展示同望项目风采，介绍和发布同望项目实施动态的页面。

地址为:

9079。

4.活动规程

1.项目计划是项目监控的基础，项目状态的跟踪与控制有助于项目沿着预定的轨道运行，同时便于项目经理在发现项目性能明显偏离计划时及时采取纠正措施。

2.纠正措施可能涉及到对项目重新策划，其中包括对原计划的修订、建立新的协定或者在现行计划中补充一些过渡性的活动。

4.1任务分配

1.项目经理应当依据计划将任务或工作安排具体落实到人，并和相关人员进行沟通协调以达成一致，任务安排形式不限，可以用邮件、口头、RTX等形式。

2.在项目任务分配过程中，项目进度计划跟踪部分应不断根据实际情况细化、更新。

4.2状态监控

1.项目状态监控主要是将项目计划、预定目标等与项目实际运行情况进行对照比较。

以便将项目状态控制在允许的范围内。

2.项目状态监控的内容应与项目计划的内容相配套，避免实际和计划脱节。

3.根据项目状态、发展趋势及风险影响等因素，项目经理应按《软件项目计划》中所约定的跟踪频率定期或事件驱动地监控和调整项目估计数据，使之不断趋于精确。

4.项目经理监控的项目状态应记录在《软件项目管理工作表》中。

监控的方面可包括但不局限于以下方面：

a）项目范围；

b）软件需求；

c）产品规模；

d）工作量；

e）任务进度；

f）成本；

g）风险；

h）质量、缺陷情况；

i）项目定量目标实现情况；

j）相关承诺、资源到位情况。

5.风险监控的内容具体详见《风险管理规程》。

6.QA工程师应按《项目质量保证计划》规定定期或事件驱动地评审项目监控情况。

4.3分析纠正

4.3.1问题分析

项目经理定期或事件驱动地组织问题收集，并分析以确定是否需要采取纠正措施。

问题可包括但不局限于以下方面：

1.通过同行评审和测试活动发现的问题；

2.项目参数实际值明显偏离估计值；

3.内部或外部承诺未得到满足；

4.风险状态发生重大变化；

5.客户或相关涉众发生重大变更。

4.3.2采取措施

1.当项目实际数据调整超过《软件项目计划》中所允许的控制范围时，以至于对顺利实现项目目标带来影响时，应采取纠正措施。

2.对所识别出的问题采取纠正措施。

纠正措施可包括但不局限以下方法：

a）重新估计、计划变更；

b）变更合同、约定或承诺；

c）修改需求或范围；

d）补充资源、增加熟练人员；

e）加班、延长工作时间；

f）改变相应的过程；

g）采用合适的新技术或方法；

h）重新确定项目风险。

3.QA工程师应协助项目经理对项目偏差进行影响分析；当纠正措施需要变更计划时请遵循《软件项目策划规程》和《变更控制规程》。

4.纠正措施的制定应与项目相关涉众达成一致。

4.4定期检查

4.4.1迭代审查

项目可在每个阶段内设置迭代审查，可采用非正式形式。

审查步骤可以在阶段里程碑的基础上进行简化。

但至少应采以邮件方式将相关资料发送给参与审查人员，如在指定的时间内无人提出异议，则该迭代视为通过，可以进入下一个迭代，审查结论处理参见“4.4.2里程碑评审”。

项目可根据实际情况决定是否召开迭代审查。

4.4.2里程碑评审

1.重要的阶段里程碑结束时应进行里程碑评审，以确定在完成该阶段最后一个迭代时项目是否可以进入下一阶段。

里程碑评审应关注进度、规模、需求、质量、成本、风险、基线等方面。

2.阶段里程碑评审的内容应与项目状态监控的内容相配套，避免评审和监控脱节。

3.里程碑评审通常采用正式评审会议的形式，参加者可包括本项目的高级经理、项目组成员代表、QA工程师、CM工程师、测试工程师等，具体参与人员的确定应依据该项目的《软件项目计划》执行。

4.在会议召开之前，应当将评审材料分发给评审人员。

务必要在会议召开之前及早地将这些材料分发出去，让评审人员有充足的时间对其进行评审，评审材料可直接使用《软件项目管理工作表》和相关工件，也可将《软件项目管理工作表》单独制作成PPT文件和相关工件进行演示，评审材料在正式演示之前应通过QA检查核实数据。

5.在会议结束时，评审组长（通常由高级经理担任）应根据项目阶段完成情况以及参与评审人员的意见应做出是否批准的决定。

6.里程碑评审会议可能会得到以下三种结果：

a）无条件通过：

项目实现了该阶段的预期目标或者所发现问题不影响本阶段的目标实现，可以进入下一阶段。

b）有条件通过：

项目可以进入下一阶段，但需将相关问题处理措施放入下一个阶段中及时解决。

c）不通过：

项目没有实现该阶段的预期目标，需要在本阶段新增新的迭代完成直至通过为止，同时应修订项目相关计划，或者终止本项目。

7.评审会议结束后应完成《会议记录》，其中需包括重要的讨论或行动，以及阶段里程碑评审的结果。

4.4.3阶段性验收

1.通过内部里程碑评审后，项目经理可以根据需要和客户协商是否需要召开阶段性验收。

2.阶段性验收不需要采用正式的验收报告，只需留下相关经过客户签字确认的《会议记录》、《项目服务确认单》、验收照片等客观记录即可。

主要目的是为了获得客户在项目开发过程中的逐步确认，积累客户在项目整体验收时让我方顺利通过的信心。

3.阶段性验收结论可参见“4.4.2里程碑评审”。

4.通过阶段性验收后，CM工程师将信息发布到“同望项目实施专区”页面中。

5.对于符合回款条件的，项目经理要及时跟进回款事宜。

4.5信息收集

1.项目经理平时要注意维护、收集和挖掘本项目后续可发展的客户关系，并于每月1-3号主动提交最新的《项目客户信息表》到项目配置库中，并通知CM工程师受控。

2.项目经理如未按时提交《项目客户信息表》，CM工程师应及时督促。

3.《项目客户信息表》要注意保证有效性、真实性、及时性。

4.6状态报告

1.项目经理除了定期监控并记录项目状态外，还应定期将项目监控状态的结果通知相关涉众。

2.项目状态报告的内容应与项目状态监控的内容相配套，避免监控和报告脱节。

3.《软件项目状态报告》建议按月提交，项目组也可以根据实际情况选择按周、旬、半月、迭代等频率来提交，但至少应保证提交的最大间隔时间不超过一个月。

如按月提交，则应每月1-3号提交，如遇休息日则顺延。

4.每次状态报告的内容应包括上周期的相关状态信息、本周期工作任务、当前存在的风险和问题等。

5.《软件项目状态报告》（内部）：

a）面向对象：

由项目经理报送给本项目高级经理、项目成员、QA工程师、测试工程师、CM工程师，并抄送给测试部经理、质保部经理。

b）采用形式：

Excel模板形式，一个周期的报告采用一行记录表示，不断累加报告。

c）报告要求：

必选定期提交。

6.《软件项目状态报告》（外部）：

a）面向对象：

由项目经理报送给客户方相关涉众，并抄送给本项目内部相关涉众。

b）采用形式：

Word表单形式，一个周期的报告采用一张记录表示，一次性流水报告。

c）报告要求：

可以选择性是否向客户提交。

5.裁剪指南

1.当项目计划周期小于1个月时，无需采用《软件项目管理工作表》、《软件项目状态报告》进行管理，但必须提交《项目客户信息表》。

无需进行“4.2状态监控”、“4.4定期检查”、“4.6状态报告”，但必须进行“4.1任务分配”、“4.3分析纠正”、“4.5信息收集”。

2.当项目计划周期大于等于1个月，小于3个月时，无需采用《软件项目管理工作表》进行管理，但必须提交《软件项目状态报告》、《项目客户信息表》。

无需进行“4.2状态监控”、“4.4定期检查”，但必须进行“4.1任务分配”、“4.3分析纠正”、“4.5信息收集”、“4.6状态报告”。

3.当项目计划周期大于等于3个月，小于6个月时，本规程下属的所有工件都必须提交，除“4.4.1迭代审查”、“4.4.2里程碑评审”外，所有活动均不能裁剪。

4.如果项目计划周期大于等于6个月，小于12个月时，本规程下属的所有工件都必须提交，除“4.4.1迭代审查”外，所有活动均不能裁剪。

5.如果项目计划周期大于等于12个月，所有活动均不能裁剪。

6.层次关系

6.1主控文件

程序文件：

《软件项目管理程序》

6.2支持文件

《软件项目管理工作表》、《软件项目状态报告》（内部）、《软件项目状态报告》（外部）、《项目客户信息表》。

6.3相关文件

l作业指导书：

《风险管理规程》、《软件项目策划规程》、《变更控制规程》。

l记录格式：

《会议记录》、《项目质量保证计划》、《软件项目计划》。

7.附录

无

第9页共9页