CMMi软件质量管理全程攻略与实践精要

XXXXX计算机软件有限企业

XX软件质量管理体系

V1.0

XX软件研发部

/12/1

目录

第一篇总则...............................................................3

一、《XX软件质量管理体系》的实行.....................................3

二、目的..............................................................3

三、背景简介..........................................................3

四、体系总体简介......................................................4

第二篇项目管理...........................................................6

一、立项管理..........................................................6

二、结项管理.........................................................13

三、项目计划.........................................................17

四、项目监控.........................................................26

五、风险管理.........................................................32

六、需求管理.........................................................36

第三篇技术实现过程......................................................42

一、技术预研.........................................................42

二、SCRUM过程.......................................................45

三、顾客验收.........................................................51

四、技术评审.........................................................54

第四篇支撑过程..........................................................60

一、配置管理.........................................................60

二、质量保证.........................................................66

三、培训管理.........................................................72

四、服务与维护.......................................................77

2

第一篇总则

一、《XX软件质量管理体系》的实行

XX计算机软件有限企业根据CMMi（软件能力成熟度模型集成）框架，结合企业数年

来实行“敏捷开发”的开发措施的经验，以及企业的实际状况，编写的《XX软件质量管埋

体系》V1.0版已经编写完毕。

本体系文档是企业质量管理体系法规性文献，是指导企业建立并实行质量管理体系的

行动准则。企业全体员工必须遵照执行。

二、目的

本文档的目的在于：

y通过建立软件过程管理体系，提高企业的软件过程能力，保证软件质量，保证商

务目的的实现。

令基于精简的CMMi3级管理体系，结合企业实际状况和经验积累，结合敏捷开发

的SCRUM措施。开发适合XX软件有限企业发展的软件过程管理体系。

令使得XX软件的软件开发过程管理基本满足CMMi3级规定。

三、背景简介

CMMI-DEV

CMMI是个了不起的规范，不过仍然有诸多局限性之处。CMMI对于项目管理很有指

导价值，不过它对技术开发过程的论述却不够深入。对于大多数软件项目而言，技术开发

占总工作量的70%以上，而项目管理占总工作量的30%如下。对大多数企业而言，技术

开发过程的规范化比项目管理过程的规范化尤为重要与迫切。

软件开发是如此的灵活，假如没有规范来指导与制约，就轻易因无序而导致混乱。不

过规范假如不切实际或者太严密了，就轻易畸变成为死板的教条，会扼杀开发人员生机勃

勃的发明力。软件过程规范应当力争简朴实用。

Scrum

由KenSchwaber和JeffSutherland提出，意在寻求充足发挥面向对象和构件技术的开

发措施，是对迭代式面向.忖象措施的改善，名称来自英式橄榄球（在比赛中每个队员都应

时刻保持对场上全局的判断，然后通过集体行动，奋力实现同一目的一胜利）。SCRUM

措施最初实践于Easel企业（1993年），现已被数十家企业数百个项目开发中应用，合用于需

求难以预测的复杂商务应用产品的开发口1].SCRUM提出的SCRUMMeeting、Sprint、Backlog、

SCRUMMaster^SCRUMTeam.Demo等模式已被PLOP作为组织和过程模式（Organizational

andProcessPattern）的原则。

SCRUM将工业过程控制中的概念应用到软件开发中米，认为软件开发过程更多是经验

3

性过程(EmpiricalProcess),而不是确定性过程(DefinedProcess)o确定性过程是可明确描述

的、可预测的过程，因而可反复(Repeatable)执行并能产生预期的成果，并能通过科学

理论对其最优化。经验性过程与之相反，应作为一种黑箱(Blackbox)来处理，通过对黑

箱的输入输出不停进行度量，在此基础上，结合经验判断对黑箱进行调控，使其不越出设

定的边界，从而产生满意的输出。SCRUM措施将老式开发中的分析、设计、实行视为一种

黑箱，认为应加强黑箱内部的混沌性，使项目组工作在混沌的边缘，充足发挥人的发明力。

综上所述，CMMI和敏捷开发可以很好地互相补充、互相支持。首先在关注点上CMMI

关注组织级或企业级改善,关注问答项目应当做什么，而不是详细怎么做的措施，而敏捷

开发则更关注项目级改善，关注项目详细怎么做的措施和最佳实践，这使双方在定位方面

形成很好的互相补充的态势。

首先CMMI为敏捷提供组织级扩展的能力和必须的组织治理框架，便于组织级对敏捷

最佳实践的推广和重用；另首先，敏捷为CMMI提供了项目级的详细实践措施，保证团体

在CMMI框架下可以迅速响应，不停创新，持续交付价值。两者的有效结合，可以有效实

现个人绩效向团体绩效、向组织绩效的转变过程。同步，也可以通过敏捷实践，规避CMMI

实行过程中重文档、重流程的不良倾向，使CMMI实行时愈加关注组织的实际价值、关注

客户、关注创新。

四、体系总体简介

XX软件质量管理体系将项目的生命周期划分为如下14个控制域。

项目管理过程域目的

采纳符合机构最大利益的立项提议，通过立项管理使该提议成为正式的项目。杜绝不

立项管理

符合机构最大利益的立项提议被采纳，防止挥霍机构的资源、资金、时间等。

在项目开发工作结束后，对项目的有形资产和无形资产进行清算、对项目进行综合评

结项管理

估以及总结经验教训等“

为项目的研发和管理工作制定合理的行动大纲(即项目计划)，以便所有有关人员按照

项目规划

该计划有条不紊地开展工作。

周期性地跟踪项目计划的多种参数如进度、工作量、费用、资源等，不停地理解项目

项目监控

的进展状况，以便当项目实际进展明显偏离计划时可以及时采用纠正措施。

风险管理在风险产生危害之前识别它们，从而有计划地消除或减弱风险。

在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并

需求管理

控制需求的变更。

项目研发过程域目的

在立项之后到开发工作完毕之前的时间内，对项目将采用的关键技术提前学习和研究，

技术预研

尽量早地发现并处理开发过程中将会碰到的技术障碍。

设计软件系统的体系构造。分Scrum小组，使用敏捷措施实现软件产品，在每次迭代

Scrum过程

都产生可以交付的产品。最终在巩固过程中保证产品符合顾客的需求。

客户验收客户根据协议对产品进行审查和测试，保证产品满足客户需求。

尽早地发现工作成果中的缺陷，并协助开发人员及时消除缺陷，从而有效地提高产品

技术评审

的质量。

机构支撑过程域目的

配置管理通过执行版本控制、变更控制等规程，以及使用配置管理软件来保证所有配置项的完

整性和可跟踪性。配置管理是对工作成果的一种有效保护。

提供一种有效的人员组织形式和管理措施，通过客观地检查和监控“过程质量”与“产

质量保证

品质量”，从而实现持续地改善质量。

根据机构（或项目）的需求来制定培训计划，并监督该计划的实行，保证培训获得预

培训管理

期效果。

是指产品铛售之后的客户服务和产品维护，其宗旨是提高客户对产品以及对开发方的

服务与维护

满意度。

第二篇项目管理

一、立项管理

立项管理（ProjectInitializationManagement,PIM）的目的是：（1）采纳符合机构最大

利益的立•项提议，通过立项管理使该提议成为正式的项目（即合法化）。（2）杜绝不符合

机构最大利益的立项提议被采纳，防止挥霍机构的人力资源、资金、时间等。

立项管理是决策行为，其目的是“做对•的的事情"（d。rightthings）。而立项之后的研

发活动和管理活动的目的是“对的地做事情“（d。thingsright的只有“对的的决策”加上

“对的地执行”才也许产生优秀的产品。

立项管理过程域是SPP模型的重要构成部分。本规范论述了立项管理过程域的三个重

要规程：

令立项提议[PASS-PROC-PIM-PROPOSAL]

<立项评审[PASS-PROC-PIM-REVIEW]

◊项目筹办[PASS-PROC-PIM-PREPARE]

上述每个规程的“目的”、“角色与职责”、“启动准则”、“输入”、“重要环节”、“输出”、

“完毕准则”和“度量”均已定义。

本规范合用于国内H企业的软件研发项目。提议顾客根据自身状况（如商业目的、研

发实力等）合适地修改本规范，然后推广使用。

1简介

立项管理流程分三个阶段：“立项提议阶段”、“立项评审阶段”和“项目筹办阶段”，

如图1所示。

一、立项提议阶段

立项提议小组应反复地进行立项调查、产品构思和可行性分析。在深思熟虑之后，立

项提议小组撰写《立项提议书》，并申请立项。

要注意的是，由于立项调查和可行性分析一般比较费时费力，往往被人忽视。而草率

撰写的《立项提议书》会有比较多的主观臆断，这对项目是有危害的。产品构思一般不也

许迅速完毕，切不可闭门造车。深入地进行立项调查与可行性分析不仅对产品构思有协助，

并且对立项评审也有协助，

二、立项评审阶段

机构领导组织一种评审委员会进行立项评审。评审委员会根据《立项提议书》、《立项

调查汇报》、《立项可行性分析汇报》以及立项提议小组的答辩，投票决定与否同意立项（按

少数服从多数原则）。评审委员会应根据机构的实际状况（发展战略、资金、人力资源等），

对《立项提议书》提出改善意见。

机构领导对立项具有最终审批权。假如机构领导赞同评审委员会的决策，那么他们将

共同分担决策责任。假如机构领导行使“一票否决权”，那么他将对该决策负所有贲任。

三、项目筹办阶段

机构领导任命一位项目经理。一般状况下，立项提议小组的负责人将被任命为项目经

理，这样有助于激发员工的工作热情,不过假如此人不适合于任项目经理，那么机构领导

6

应当此外任命一位合适的项目经理。

项目经理被任命之后，机构领导协助项目经理获取项目经费、人力资源、软硬件资源

等。要注意的是，假如项目所需的资金和资源难以准时到位，此时项目经理不可老在等待

或只是埋怨，应当积极设法克服困难，尽早行动起来。诸多时候，资金和资源是争取来的，

而不是等来的。

假如必要的资金和资源已经到位，项目经理和项目关键组员根据实际状况撰写《项目

计划》，执行项目研发和管理工作。

立项管理过程域产生的重要文档有:

<《立项调查汇报》

◊《立项可行性分析汇报》

<《立项提议书》

<《立项评审汇报》

2立项提议阶段

2.1目的

•立项提议小组充足地进行立项调查、产品构思和可行性分析，撰写对应文档并申请立

项。

2.2角色与职责

•立项提议小组一般由芦品创作者（构思者）和商务部人员构成。该小组开展立项调查、

产品构思、可行性分析等活动，在深思熟虑之后撰写《立项提议书》、《立项调查汇报》

和《立项可行性分析汇报》并申请立项。

2.3启动准则

•立项提议小组已经成立。

2.4输入

•与目的产品有关的任何信息

2.5重要环节

•[Stepl]立项调查

■立项提议小组开展立项调查，重要工作包括：

令市场调查

＜政策调查

＜同类产品调查

令竞争对手调查

令顾客调查

令其他有关的调查

■立项调查应当遵照如下原则：

令调查者应当客观地看待被调查的事物，不可故意往“好处”或者“害处”写。

◊调查汇报中的数据、图表要真实并且有据可查，不可凭空捏造。

令调查汇报应通俗易懂，不可写成学术性的文章,.

•[Step2]产品构思

■立项提议小组讲行产品构思，重要内容包括：

令待开发产品的重要功能

＜待开发产品的技术方案

令Make-or-Buy决策（确定哪些产品部件应当采购、外包开发或者自主研发。）

弋开发计划

＜市场营销计划

。其他有关的计划

•[Step3]可行性分析

■立项提议小组开展可行性分析，重要内容包括：

令市场可行性分析

令政策可行性分析

令竞争实力分析

Q技术可行性分析

今时间和资源可行性分析

◊知识产权分析

☆其他有关的可行性分析

•[Step4]撰写并完善立项提议有关文档

■在进行了充足的立项调查、产品构思和可行性分析之后，立项提议小组撰写并完

善《立项提议书》、《立项调查汇报》、《立项可行性分析汇报》以及有关文档。

•[Step5]申请立项

■立项提议小组向机构领导递交《立项提议书》、《立项调查汇报》、《立项可行性分

析汇报》以及有关材料-，申请立项。

2.6输出

•《立项提议书》、《立项调查汇报》、《立项可行性分析汇报》以及有关文档。

2.7结束准则

•立项提议小组按照指定的模版撰写了《立项提议书》、《立项调查汇报》和《立项可行

性分析汇报》，并做了内部审查（消除拼写、排版等错误）。

2.8度量

•立项提议小组记录工作量和上述文档的规模，未来汇报给项FI经理。

3立项评审

3.1目的

•机构领导组织立项评审委员会，对《项目提议书》进行评审，决定与否同意立项。

3.2角色与职责

•机构领导根据项目的特性组织立项评审委员会，并确定一位主席。主席应当具有比较

丰富的评审经验，可以控制评审会议的进程。主席除了主持评审会议之外，还要负责

撰写《立项评审汇报》。

•一般地，立项评审委员会由机构领导、各级经理、市场人员、技术专家、财务人员等

构成。委员会按少数服从多数原则投票决定与否同意立项（此时机构领导只是一名委

员，不具有一票否决权）。

•立项提议小组陈说《立项提议书》的重要内容，并答复评审委员会的问题。

•评审会议的记录员可以任意指定。记录员记录评审会议中的某些重要问答。

•立项评审委员会决策之后，机构领导作最终审批（此时机构领导具有一票否决权）。

3.3启动准则

•立项提议小组已经申请立项，机构领导同意进行立项评审。

3.4输入

•《立项提议书》、《立项调查汇报》、《立项可行性分析汇报》以及有关材料。

3.5重要环节

•[Stepl]准备

■机构领导根据项目特性组织立项评审委员会，并确定一位主席。

■主席确定评审会议的时间、地点、设备和参与会议的人员名单（包括评委、记录

员、立项提议小组、旁听者等），并告知所有有关人员。

■主席将《立项提议书》、《立项调查汇报》、《立项可行性分析汇报》以及有关材料

发给所有评委。各评委必须在举行评审会议之前阅读完上述材料，并及时与立项

提议小组交流。

•[Step2]举行评审会议

■[Step2.1]主席宣讲本次评审会议的议程、重点、原则、时间限制等。

■[Step2.2]立项提议小加陈说《立项提议书》的重要内容。

■[Step2.3]答辩

令评审委员会提出疑问，立项提议小组解答，双方应当对有争议的内容达到一

致的处理意见。

◊记录员记录答辩过程的重要内容（问题、结论、提议等）。

■[Step2.4]评估

。评审委员会根据“立项评审检查表”认真地评估该项目。

◊评审委员会给出评审结论和意见：

◊主席撰写《立项评审汇报》并递交给机构领导，本次评审会议结束。

机构领导终审

•[SteP3]

■机构领导在《立项评审汇报》中签注最终审批结论和意见。

3.6输出

•《立项评审汇报》

3.7结束准则

•评审委员会和机构领导已经在《立项评审汇报》中签注结论和意见。

3.8度量

•评审委员会记录工作量和上述文档的规模，未来汇报给项目经理。

4项目筹办

4.1目的

•任命一位合适的项目经理，并协助项目经理获取经费、人力资源、软件硬件资源等，

以便顺利启动项目。

4.2角色与职责

•任命一位合适的项目经理，并协助项目经理获取经费、人力资源、软件硬件资源等。

•项目经理组建团体，开始执行项目研发和管理工作.

4.3启动准则

•机构领导已经同意立项。

4.4输入

•评审、修正后的《立项提议书》

4.5重要环节

•［Stepl］任命项目经理

■机构领导参照立项提议小组和评审委员会的意见，任命一位合适的项目经理。

•［Step2］获取经费与资源

■由于机构的资金和资源是有限的，机构也许难以完全按照《立项提议书》的规定

给项目分派充足的资金和资源。机构领导和项目经理应当设法和财务部门、人力

资源部门协商，尽量为项目争取必要（充足）的资金和资源。

•［后续活动］

■假如必要的资金和资源已经到位，项目经理和关键组员根据实际状况撰写《项目

计划》，开始执行研发和管理工作。详见SPP的项目计划过程域［SPP-PROC-PP］和

需求开发过程域［SPP-PROC-RD］。

4.6输出

•项目经理使川经费和资源的凭证，例如经费本等0

4.7结束准则

•项Fl经理已经被任命，必要的资金和资源已经到位.

4.8度量

•项目经理记录工作量，

5补充

•对立项管理过程域产生的所有有价值的文档如《立.项提议书》、《立项调查汇报》、《立

项可行性分析汇报》、《立项评审汇报》进行配置管理。

•做好必要的保密工作，

•由于每个项目都要占用机构的资金和资源，立项评审一定要严格。提议对机构高层管

理人员进行必要的立项管理培训。

•对于客户委托开发的项目，立项提议工作可以合适地简化。

二、结项管理

结项管理(ProjectClosingManagement,PCM)是指在项目开发工作结束后，对项目的

有形资产和无形资产进行清算；对项目进行综合评估；总结经验教训等。

本规范论述了结项管理的规程，该规程的“目的”、“角色与职货”、“启动准则”、“输

入”、“重要环节”、“输出”、“完毕准则”和“度量”均已定义。

1简介

立项管理与结项管理是前后呼应的两个过程域，使得项目管理过程“有始有终”。

项目结束有两种状况：一是正常结束，二是异常结束。前者是指项目按预定计划结束。

后者原因有多种，归根结底都是由于该项目不再符合机构的最大利益。例如有些项目因不

适应市场而被中途淘汰，有些项目在执行过程中大大因偏离计划(如进度延误、费用超支)

而被取消。

不管项目属于正常结束还是异常结束，都要按照结项管理规范处理。

结项管理包括三项内容：

令对项目的有形资声和无形资产进行清算，既要防止资产流失，又要及时地运用这

些资产。

。对项目进行综合评估。例如评估项目完毕状况'项目质量、投入产出分析、项目

的市场价值、项目对企业的奉献等等。该评估汇报可以作为考核项目人员业绩的

重要根据。

◊总结经验教训，使整个机构受益。

机构领导指示结项中请机构领导审批

图2-1结项管理流程图

结项管理的流程如图1所示，产生的重要文档有；

令《结项申请书》，模板见[SPP-TEMP-PCM-REQUEST]o

<《结项评审汇报》，模板见[SPP-TEMP-PCM-REVIEW]o

2结项管理规程

2.1目的

•对项目的有形资产和无形资产进行清算：对项目进行综合评估；总结经验教训等。

2.2角色与职员

•项目经理撰写《结项申请书》，申请结项。

•机构领导对“与否结束项目”具有决定权。

•机构领导根据项目的特性成立结项评审委员会。一般地，结项评审委员会由机构领导、

各级经理、市场人员、技术专家、财务人员等构成,

2.3启动准则

•对于那些按照计划执行的项目而言，当项目已经开发完毕时，可以进入结项管理流程。

•对于那些不再符合机构最大利益的项目而言，假如机构领导明确指示结束项目，可以

进入结项管理流程。

2.4输入

•《立项提议书》、《项目计划》等文档

2.5重要环节

•[Stepl]机构领导指示

■对于那"不再符合机构最大利益的项目而言，机构领导应当明确指示该项目经理,

确定何时结束项目。

■对于那些按照计划执行的项目而言，当项FI开发工作靠近尾声时，机构领导和项

目经理根据机构的现实状况，协商并确定何时结束项目。

•[Step2]结项申请

■遵照机构领导的指示，在预定的时间内，项目经理撰写《结项申请书》，并递交给

机构领导。《结项申请书》重要内容包括：

♦项目简介

♦计划与实际状况对比

♦重要工作成果

♦专利与版权状况

♦项目重要资芦及处理意见

•[Step3]机构领导审批

■机构领导审阅《结项申请书》。假如该申请书符合机构的规章制度和企业利益，那

么同意进入“结项评审”阶段，转向［Step4］。否则返回［Stepl］或［Step2］.

•［Step4］结项评审

■［Step4.1］准备

♦机构领导根据该项目的特性，成立一种结项评审委员会，确定一位主席。

♦评审委员会主席和项目经理共同确定结项评审的时间、地点等等，并告知所

有有关人员，

■(Step4.2)项目资产检查与处理

♦结项评审委员会检查该项目的有形资产和无形资产，并和项目经理共同商讨

怎样有效地运用这些资产。

■［Step4.3］项目综合评估

♦结项评审委员会对该项目进行综合评估，重要内容包括：

♦项目完毕状况

♦项目质量

♦投入产出分析

♦项目的市场价值

♦项目对机构为奉献

■［Step4.4］总结经验教训|

♦结项评审委员会和项目组员们共同总结经验教训，并以文档的形式保留下来,

在机构内共享，使集体受益。

■［Step4.5］机构领导终审

♦结项评审委员会撰写《结项评审汇报》，并交付给机构领导。

♦机构领导签注最终意见，项目正式结束。

•［后续活动］

■举行集体活动、座谈会、宴会等等，原项目组员们交流思想，增进感情。

■机构领导和人力资源部考核项目经理和项目组员们的业绩，努力做到赏罚分明。

2.6输出

•《结项申请书》

•《结项评审汇报》

2.7结束准则

•《结项评审汇报》已经撰写完毕，机构领导签注最终意见。

2.8度量

•项目经理记录工作量和上述文档的规模。

3补充

•对结项管理过程域产生的所有有价值的文档进行配置管理。

•做好必要的保密工作，

•对于客户委托开发的项目，［Stepl］至［Step3］可以合适地简化，不过结项评审工作不能

简化。

对结项评审委员会进行必要的培训，使他们树立对的的观念，从而严格把关。

三、项目计划

项目规划（ProjectPlanning）的目的是为项目的研发和管理工作制定合理的行动大纲

（即《项目计划》），以便所有有关人员按照该计划有条不紊地开展工作。

为了防止词义混淆，这里把动词Planning译为规划,把名词Plan译为计划（或计划书）。

项目规划过程域是SPP模型的重要构成部分。本规范论述了项目规划过程域的四个重

要规程：

令项目估计fPASS-PROC-PP-ESTIMATE］

令制定项目计划［PASS-PROC-PP-ESTABLISH］

令审批项目计划［PASS-PROC-PP-APPROVE］

<项H计划变更控制［PASS-PROC-PP-CHANGE］

上述每个规程的“目的”、“角色与职责”、“启动准则”、“输入”、“重要环节”、“输出”、

“完毕准则”和“度量”均已定义。

1简介

在立项管理过程域的项目筹办阶段（参见［SPP-PROC-PIM］）,机构领导首先任命一位项

目经理，之后机构领导协助项H经理筹办项忖经费、人力资源、软件硬件资源等。假如必

要的资金和资源已经到位，那么项目经理和关键组员即可构成一种项目规划小组，着手制

定《项目计划》，并按计划执行研发和管理工作。

项目计划过程域有4个重要规程：“项目估计”、“制定项目计划”、“审批项目计划”

和“项目计划变更控制”，流程如图3-1所示。

一、项目估计

项目估计与否精确将直接影响《项目计划》的有效性,项目估计要尽量做到“知己知

彼”。“知彼”是指理解产品的需求,“知己”是指理解本项目的实力（即本项FI实际可以拥

有的经费、人力资源、软件硬件资源、技术水平等）。项目估计的重点内容是“产品范围估

计”、“产品规模估计”、“工作量估计”和“成本估计”等。

在项目刚开始时，人们对产品需求的理解还比较肤浅，而项目实际可以拥有经费和资

源很大程度上是靠项目经理争取的，不确定原因比较多。在这种状况下人们很难作出精确

的估计。不过“估计”显然比“不估计”要好，否则《项目计划》就没有根据了。

二、制定项目计划

根据项H估计得到的数据，规划小组制定《项目计戈I》。《项目计划》的重点内容是“人

力资源计划”、“软硬件资源计划”、“开支（财务）计划”、“任务与进度计划”、“下属计划”

等。

由于需求开发花费的时间比较长（一般约占整个项目开发周期的20%）,人们一般不

会等到需求开发完毕之后才开始制定《项目计划》。否则在那么长的时间里没有《项目计划》,

众人不知怎样开展活动，显然有害于项目。因此一般项目规划和需求开发是并行开展的（请

参见SPP模型图）。

三、审批项目计划

规划小组将《项目计划》递交给机构领导审批。假如机构领导同意了《项目计划》，那

么该计划书可以正式公布（文献状态为Released）,不可以被随便修改。项目的所有组员按

照《项目计划》执行研发与管理工作。

四、项目计划变更控制

在项目执行过程中假如发现《项目计划》与实际状况有比较大的偏差，应当及时更新

《项目计划》。变更《项目计划》必须按照指定的规程（即变更控制）执行，防止发生混乱。

图31项目规划流程图

项目规划过程域产生的重要文档有：

<《项目估计表》，模板见［SPP-TEMP-PP-ESTIMATE］（>

e《项目计划》，模板见［SPP-TEMP-PP-PLAN］6

令《项目计划变更控制汇报》，模板见［SPP-TEMP-PP-CONTROL］o

2项目估计

2.1目的

•估计项目的范围、产品规模、工作量、成本等，为制定《项目计划》提供根据。

2.2角色与职责

•项目规划小组由项目经理和关键组员构成，所有人员共同参与项目估计。

2.3启动准则

•机构领导已经同意立项。

•项目规划小组已经成立。

2.4输入

•《立项提议书》和某些顾客需求文档。

•用于项目估计的某些经验数据。

2.5重要环节

•[Stepl]估计项目范围

计划小组首先估计本项目的范围，可以用产品的WBS来表达。计划小组根据顾客需求,

分解产品的功能，制定产品的WBS,如图3-2所示。由于此处WBS仅用于项目估计而非用

于系统设计，其细分程度由计划小组决定。

图3-2用于项目估计的产品WBS示意图

•[Step2]估计产品规模

■产品规模的重要度量单位有：

。代码行

◊类（对象）个数

令文档页数

■产品规模估计措施如下：

I.规划小组各组员根据产品的WBS,独立地估计产品的规模，填写“产品规模传计

表格”（如表3-1所示）。

II.汇总每个组员的“产品规模估计表格”，进行对比分析。假如各人估计的差额不不

小于10%,则取平均值。假如差额不小于10%,则转向第I.步，规划小组各组员

重新估计产品的规模，直到各人估计的差额不不小于10%为止。

产品的组件新开发组件的规模复用或自动生成的组件的规模

（代码行、类、文档页数）（代码行、类、文档页数）

组件1

组件2

组件3

・・・

总和

表3-1产品规模估计表

•[Step3]估计工作量

■项日的工作星是“项日研发工作星”、“项日管理工作星”、“机构支撑工作星”三

者之和。工作量的度量单位可以是“人小时”、“人天”、“人月”或“人年，

•[Step4]估计成本

■规划小组估计人力资源成本、软硬件资源成本、商务活动成本等。

2.6输出

•《项目估计表》

2.7结束准则

•规划小组已经按照本规程进行了项目估计，并产生了《项目估计表》。

2.8度量

•项FI经理记录本规程产生的所有估计数据。

3制定项目计划

3.1目的

•根据项目估计产生的数据，制定《项目计划》。

3.2角色与职责

•项FI规划小组由项目经理和关键组员构成，所有人员共同制定《项目计划》。

3.3启动准则

•项目估计已经完毕。

3.4输入

《立项提议书》和某些顾客需求文档

“项目估计表”

3.5重要环节

•[Stepl]确定目的与范围

■规划小组首先确定本项目的目的与工作范围。目的必须是“可实现的”和“可验

证的”。工作范围包括“做什么”和“不做什么”。

•[Step2]确定过程模型

■规划小组根据项目的特性，确定过程模型，包括项目研发过程、项目管理过程、

机构支撑过程等、例如裁剪SPP模型C

■规划小组确定（描述）过程模型中采用的措施与工具。例如采用RationalRose进

行面向对象分析与设计,采用VisualSourceSafe进行配置管理,采用Microsoft

Office制作文档等等。

•[Step3]制定人力资源计划

■规划小组制定本项目的角色职责表，并为已知的项目组员分派角色（一种人可以

兼多种角色），如表3-2所示。

角色职责人员工作阐明

—

表3-2人力资源计划

•[Step4]制定软硬件资源计划

■规划小组分析项目开发、测试以及顾客使用产品所需的软硬件资源，制定软硬件

资源计划，如表3-3所示。重要内容包括：

令资源级别（分为“关键”、“一般”两种）

令详细配置

令获取方式（如“已经存在”、“可以借用”或“需要购置”等）与获取时间

◊用途（如“谁”在“什么”时候使用）

软硬件资源名称级别详细配置获取方式与时间用途

关键

关键

…一般

表3-3软硬件资源计划

•[Step5]制定财务计划

■规划小组制定财务计划，如表3-4所示。

开支类别重要开支项、用途金额时间

表财务计划

•[Step6]分派任务并制定进度表

■规划小组分派任务并制定进度表，提议采用MicrosoftProject制作Gantt图，附

在《项目计划》中。

•[Step7]确定下属计划

■规划小组确定本《项目计划》重要的下属计划，如表5-6所示。

下属计划的名称提议负责人估计产生时间

《配置管理计划》配置管理员

《质量保证计划》质量保证员

《技术评审计划》

某些开发计划

某些测试计划

•••

表5-6重要的下属计划

3.6输出

•《项目计划》

3.7结束准则

•规划小组已经按照指定的模版撰写了《项目计划》，并做了内部审查（消除拼写、排版

等错误）。

3.8度量

•项目经理记录工作量以及文档规模。

4审批项目计划

4.1目的

•机构领导审批《项目计划》，保证该计划是合理的、符合机构现实的。

4.2角色与职责

•机构领导审批《项目计划》。

•假如《项目计划》有不合理之处，规划小组应根据机构领导的意见修正《项目计划》。

4.3启动准则

•规划小组已经制定了《项目计划》。

4.4输入

•《项目计划》

4.5重要环节

•[Stepl]申请审批

■项FI经理将《项目计划》提交给机构领导，申请审批。申请书可以采用电子邮件

或书面汇报等形式。

•[Step2]审批与修正

■机构领导根据“项目计划检查表”认真审批《项目计划》。

■假如《项目计划》有不合理之处，规划小组应根据机构领导的意见及时修正《项

目计划》。

•[Step3]同意生效

■机构领导签字同意后，该《项目计划》正式生效，此后规划小组不能随意修改《项

目计划》。

4.6输出

•机构领导的审批意见（见《项目计划》的附录）。

•按评审意见修正后的《项目计划》。

4.7结束准则

•机构领导签字同意了该《项目计划》。

4.8度量

•项目经理记录工作量,

5项目计划变更控制

5.1目的

•修改原《项目计划》中不合理的内容，产生新的《项目计划》。

•控制《项目计戈|J》的变更，防止发生混乱。

5.2角色与职责

•机构领导审批变更申请。

•项目经理更新《项目计划》。

5.3启动准则

若下列之一发生，应当变更原《项目计划》：

・进度偏差超过了容许的误差，如20%；

•费用偏差超过了容许的误差，如20%；

•项目过程模型发生了明显的变化；

•顾客需求发生了重大的变化；

•发生了对项目小组而言不可抗拒的变化，例如企业裁员、机构调整、产品发展战略调

整等。

5.4输入

•原《项目计划》

5.5重要环节

•[Stepl]变更申请

■项目经理向机构领导申请变更《项目计划》。变更申请书中应当阐明：

<变更原因

弋变更的内容

令此变更对项目导致的影响

•[Step2]审批变更申请

■机构领导审批变更申请：

<假如不一样意变更，则退回变更祈求，项目按照原计划执行。

。假如同意变更，转向

[Step3]o

•[Step3]修改项目计划

■项目经理修改原《项目计划》，产生新的《项目计划》。

•[Step4]审批新的项目计划

■机构领导审批新的《项目计划》，参见规程[SPP-PROC-PP-APPROVE]o

5.6输出

•《项目计划变更控制汇报》

•新的《项目计划书》

5.7结束准则

•变更申请以及新的《项目计划》都得到了机构领导的同意。

5.8度量

•项目经理记录工作量，

6补充

•对项目规划过程域产生的所有有价值的文档进行配置管理。

•《项目计划》被机构领导同意之后，有关人员即可撰写下属计划如《配置管理计划》、

《质量保证计划》、某些开发计划和测试计划等。

・选用合适的软件工具，尽量减少项目规划过程域的工作量。

对于客户委托开发的项目，客户在项目规划过程域的介入程度视详细状况而定

四、项目监控

项目监控（ProjectMonitoringandControl,PMC）的目的是通过周期性地跟踪项目计划

的多种参数如进度、工作量、费用、资源、工作成果等，不停地理解项目的进展状况，以

便当项目实际进展状况明显偏离计划时可以及时采用纠正措施。

项目监控过程域是SPP模型的重要构成部分。本规范论述了项目监控过程域的三个重

要规程：

令项目计划跟踪［PASS-PROC-PMC-TRACKING1

令控制偏差［PASS-PROC-PMC-CONTROL］

令项目进展汇报［PASS-PROC-PP-REPORT］

上述每个规程的“目的”、“角色与职责”、“启动准则”、“输入”、“重要环节”、“输出”、

“完毕准则”和“度量”均已定义。

本规范合用于国内“企业的软件研发项目。提议顾客根据自身状况（如商业目的、研

发实力等）合适地修改本规范，然后推广使用。

1简介

项目监控至少有如下几种好处：

（1）防止原本合理的计划在实行时落空；

（2）防止“执迷不悟”地按照不合理的计划行事；

（3）将监控过程产生的数据保留起来，为机构持续的过程改善提供有价值的数据。

项目监控过程域有3个重要规程：”项目计划跟踪”、“偏差控制”、“项目进展汇报”,

流程如图4-1所示。

一、项目计划跟踪

项FI经理周期性地跟琮项FI计划的多种参数如进度、工作量、费用、资源、工作成果

等，从而及时理解项目的实际进展状况。

从数据分析角度讲，计划是基于估计的，而跟踪则是基于度量的。

二、偏差控制

项目经理将跟踪得到的数据和《项目计划》中的数据进行对比，分析偏差，假如发现

项目进展明显偏离计划，应当及时采用纠正措施。

三、项目进展汇报

项目经理周期性地召开会议，讨论项目进展状况，撰写“项目进展汇报”并通报给机

构领导和所有项目组员。

项目监控过程域产生的重要文档有：

令《项目监控数据表》，模板见［SPP-TEMP-PMC-DATA］o

令《项目偏差控制汇报》，模板见［SPP-TEMP-PMC-CONTROL］,

<《项目进展汇报》，模板见［SPP-TEMP-PP-REPORT］c

周期性地开展

图4-1项目监控流程

2项目计划跟踪

2.1目的

•周期性的跟踪任务（含进度和工作量）、费用、资源、工作成果等，及时理解项目的实

际进展状况。

•为持续过程改善提供有价值的数据。

2.2角色与职责

•项目经理跟踪项目的实行。

•项目组员协助项目经理采集有关