软件项目监控规程

统一过程管理体系软件项目监控规程

版本号 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.目的范围

●目的作用：为软件项目监督和控制活动提供规范指导，以便更好地控制项目进展情况及趋势，当

项目实际运行与计划偏差超过一定范围时及时采取适当的纠正措施。

●应用范围：事业中心、项目中心。

●读者对象：事业中心、项目中心相关人员。

2.角色职责

3.术语定义

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

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

的到达。

●关键事件里程碑：指不是阶段里程碑，但又非常关键的重要事件，如完成需求调研、设备采购到

位、通过内部验收、通过专家评审等。

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

研发部经理等。

●同望项目管理实施专区：用于展示同望项目风采，介绍和发布同望项目实施动态的页面。地址为

: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工程师受控。