搜档网
当前位置:搜档网 › 全套CMMi软件质量管理体系

全套CMMi软件质量管理体系

全套CMMi软件质量管理体系
全套CMMi软件质量管理体系

X X X X X计算机软件有限公司

XX软件质量管理体系

V1.0

XX软件研发部

2010/12/1

目录

第一篇总则

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

二、目的

三、背景介绍

四、体系总体介绍

第二篇项目管理

一、立项管理

二、结项管理

三、项目计划

四、项目监控

五、风险管理

六、需求管理

第三篇技术实现过程

一、技术预研

二、SCRUM过程

三、用户验收

四、技术评审

第四篇支撑过程

一、配置管理

二、质量保证

三、培训管理

四、服务与维护

总则

《XX软件质量管理体系》的实施

XX计算机软件有限公司依据CMMi(软件能力成熟度模型集成)框架,结合公司多年来实施“敏捷开发”的开发方法的经验,以及公司的实际情况,编写的《XX软件质量管理体系》V1.0版已经编写完成。

本体系文档是公司质量管理体系法规性文件,是指导公司建立并实施质量管理体系的行动准则。公司全体员工必须遵照执行。

目的

本文档的目的在于:

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

务目标的实现。

?基于精简的CMMi 3级管理体系,结合企业实际情况和经验积累,结合敏捷开发

的SCRUM方法。开发适合XX软件有限公司发展的软件过程管理体系。

?使得XX软件的软件开发过程管理基本满足CMMi 3级要求。

背景介绍

CMMI-DEV

CMMI是个了不起的规范,但是仍然有很多不足之处。CMMI对于项目管理很有指导

价值,但是它对技术开发过程的论述却不够深入。对于大多数软件项目而言,技术开发占总工作量的70%以上,而项目管理占总工作量的30%以下。对大多数企业而言,技术开

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

软件开发是如此的灵活,如果没有规范来指导与制约,就容易因无序而导致混乱。但是规范如果不切实际或者太严密了,就容易畸变成为死板的教条,会扼杀开发人员生机勃勃的创造力。软件过程规范应当力求简单实用。

Scrum

由Ken Schwaber和Jeff Sutherland 提出,旨在寻求充分发挥面向对象和构件技术的开发方法,是对迭代式面向对象方法的改进,名称来自英式橄榄球(在比赛中每个队员都应时刻保持对场上全局的判断,然后通过集体行动,奋力实现同一目标──胜利)。SCRUM

方法最初实践于Easel公司(1993年),现已被数十家公司数百个项目开发中应用,适用于需求难以预测的复杂商务应用产品的开发[11]。SCRUM提出的SCRUM Meeting、Sprint、Backlog、SCRUM Master、SCRUM Team、Demo等模式已被PLOP作为组织和过程模式(Organizational and Process Pattern)的标准。

SCRUM将工业过程控制中的概念应用到软件开发中来,认为软件开发过程更多是经验性过程(Empirical Process),而不是确定性过程(Defined Process)。确定性过程是可明确描述的、可预测的过程,因而可重复(Repeatable)执行并能产生预期的结果,并能通过科学

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

箱的输入输出不断进行度量,在此基础上,结合经验判断对黑箱进行调控,使其不越出设定的边界,从而产生满意的输出。SCRUM方法将传统开发中的分析、设计、实施视为一个黑箱,认为应加强黑箱内部的混沌性,使项目组工作在混沌的边沿,充分发挥人的创造力。

总而言之,CMMI和敏捷开发能够很好地相互补充、相互支持。首先在关注点上CMMI 关注组织级或企业级改进,关注回答项目应该做什么,而不是具体怎么做的方法,而敏捷开发则更关注项目级改进,关注项目具体怎么做的方法和最佳实践,这使双方在定位方面形成很好的相互补充的态势。

一方面CMMI为敏捷提供组织级扩展的能力和必须的组织治理框架,便于组织级对敏捷最佳实践的推广和重用;另一方面,敏捷为CMMI提供了项目级的具体实践方法,确保

团队在CMMI框架下能够快速响应,不断创新,持续交付价值。两者的有效结合,能够有效实现个人绩效向团队绩效、向组织绩效的转变过程。同时,也可以通过敏捷实践,规避CMMI实施过程中重文档、重流程的不良倾向,使CMMI实施时更加关注组织的实际价值、关注客户、关注创新。

体系总体介绍

项目管理

一、立项管理

立项管理(Project Initialization Management, PIM)的目的是:(1)采纳符合机构最大利益的立项建议,通过立项管理使该建议成为正式的项目(即合法化)。(2)杜绝不符合机构最大利益的立项建议被采纳,避免浪费机构的人力资源、资金、时间等。

立项管理是决策行为,其目标是“做正确的事情”(do right things)。而立项之后的研发活动和管理活动的目标是“正确地做事情”(do things right)。只有“正确的决策”加上“正确地执行”才可能产生优秀的产品。

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

?立项建议[PASS-PROC-PIM-PROPOSAL]

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

?项目筹备[PASS-PROC-PIM-PREPARE]

上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。

本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况(如商业目标、研发实力等)适当地修改本规范,然后推广使用。

介绍

立项管理流程分三个阶段:“立项建议阶段”、“立项评审阶段”和“项目筹备阶段”,如图1所示。

一、立项建议阶段

立项建议小组应反复地进行立项调查、产品构思和可行性分析。在深思熟虑之后,立项建议小组撰写《立项建议书》,并申请立项。

要注意的是,由于立项调查和可行性分析通常比较费时费力,往往被人忽视。而草率撰写的《立项建议书》会有比较多的主观臆断,这对项目是有危害的。产品构思通常不可能快速完成,切不可闭门造车。深入地进行立项调查与可行性分析不仅对产品构思有帮助,而且对立项评审也有帮助。

二、立项评审阶段

机构领导组织一个评审委员会进行立项评审。评审委员会根据《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及立项建议小组的答辩,投票决定是否同意立项(按少数服从多数原则)。评审委员会应根据机构的实际情况(发展战略、资金、人力资源等),对《立项建议书》提出改进意见。

机构领导对立项具有最终审批权。如果机构领导赞同评审委员会的决策,那么他们将共同分担决策责任。如果机构领导行使“一票否决权”,那么他将对该决策负全部责任。

三、项目筹备阶段

机构领导任命一位项目经理。通常情况下,立项建议小组的负责人将被任命为项目经理,这样有利于激发员工的工作热情。但是如果此人不适合于任项目经理,那么机构领导应该另外任命一位合适的项目经理。

项目经理被任命之后,机构领导协助项目经理获取项目经费、人力资源、软硬件资源等。要注意的是,如果项目所需的资金和资源难以按时到位,此时项目经理不可老在等待或只是抱怨,应当主动设法克服困难,尽早行动起来。很多时候,资金和资源是争取来的,而不是等来的。

如果必要的资金和资源已经到位,项目经理和项目核心成员根据实际情况撰写《项目计划》,执行项目研发和管理工作。

图1-1 立项管理流程

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

?《立项调查报告》

?《立项可行性分析报告》

?《立项建议书》

?《立项评审报告》

立项建议阶段

目的

●立项建议小组充分地进行立项调查、产品构思和可行性分析,撰写相应文档并申请立

项。

角色与职责

●立项建议小组一般由产品创作者(构思者)和商务部人员组成。该小组开展立项调查、

产品构思、可行性分析等活动,在深思熟虑之后撰写《立项建议书》、《立项调查报告》和《立项可行性分析报告》并申请立项。

启动准则

●立项建议小组已经成立。

输入

●与目标产品有关的任何信息

主要步骤

●[Step1] 立项调查

?立项建议小组开展立项调查,主要工作包括:

?市场调查

?政策调查

?同类产品调查

?竞争对手调查

?用户调查

?其他相关的调查

?立项调查应当遵循以下原则:

?调查者应当客观地对待被调查的事物,不可有意往“好处”或者“坏处”写。

?调查报告中的数据、图表要真实并且有据可查,不可凭空捏造。

?调查报告应通俗易懂,不可写成学术性的文章。

●[Step2] 产品构思

?立项建议小组进行产品构思,主要内容包括:

?待开发产品的主要功能

?待开发产品的技术方案

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

?开发计划

?市场营销计划

?其他相关的计划

●[Step3] 可行性分析

?立项建议小组开展可行性分析,主要内容包括:

?市场可行性分析

?政策可行性分析

?竞争实力分析

?技术可行性分析

?时间和资源可行性分析

?知识产权分析

?其他相关的可行性分析

●[Step4] 撰写并完善立项建议相关文档

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

善《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及相关文档。

●[Step5] 申请立项

?立项建议小组向机构领导递交《立项建议书》、《立项调查报告》、《立项可行性分

析报告》以及相关材料,申请立项。

输出

●《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及相关文档。

结束准则

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

性分析报告》,并做了内部审查(消除拼写、排版等错误)。

度量

●立项建议小组统计工作量和上述文档的规模,将来汇报给项目经理。

立项评审

目的

●机构领导组织立项评审委员会,对《项目建议书》进行评审,决定是否同意立项。角色与职责

●机构领导根据项目的特征组织立项评审委员会,并确定一位主席。主席应当具备比较

丰富的评审经验,能够控制评审会议的进程。主席除了主持评审会议之外,还要负责撰写《立项评审报告》。

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

组成。委员会按少数服从多数原则投票决定是否同意立项(此时机构领导只是一名委员,不具有一票否决权)。

●立项建议小组陈述《立项建议书》的主要内容,并答复评审委员会的问题。

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

●立项评审委员会决议之后,机构领导作最终审批(此时机构领导具有一票否决权)。启动准则

●立项建议小组已经申请立项,机构领导同意进行立项评审。

输入

●《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及相关材料。

主要步骤

●[Step1] 准备

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

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

员、立项建议小组、旁听者等),并通知所有相关人员。

?主席将《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及相关材料

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

建议小组交流。

●[Step2] 举行评审会议

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

?[Step2.2] 立项建议小组陈述《立项建议书》的主要内容。

?[Step2.3] 答辩

?评审委员会提出疑问,立项建议小组解答。双方应当对有争议的内容达成一

致的处理意见。

?记录员记录答辩过程的重要内容(问题、结论、建议等)。

?[Step2.4] 评估

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

?评审委员会给出评审结论和意见:

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

●[Step3] 机构领导终审

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

输出

●《立项评审报告》

结束准则

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

度量

●评审委员会统计工作量和上述文档的规模,将来汇报给项目经理。

项目筹备

目的

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

以便顺利启动项目。

角色与职责

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

●项目经理组建团队,开始执行项目研发和管理工作。

启动准则

●机构领导已经批准立项。

输入

●评审、修正后的《立项建议书》

主要步骤

●[Step1] 任命项目经理

?机构领导参考立项建议小组和评审委员会的意见,任命一位合适的项目经理。

●[Step2] 获取经费与资源

?由于机构的资金和资源是有限的,机构可能难以完全按照《立项建议书》的要求

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

资源部门协商,尽可能为项目争取必要(充分)的资金和资源。

●[后续活动]

?如果必要的资金和资源已经到位,项目经理和核心成员根据实际情况撰写《项目

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

需求开发过程域[SPP-PROC-RD]。

输出

●项目经理使用经费和资源的凭证,例如经费本等。

结束准则

●项目经理已经被任命,必要的资金和资源已经到位。

度量

●项目经理统计工作量。

补充

●对立项管理过程域产生的所有有价值的文档如《立项建议书》、《立项调查报告》、《立

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

●做好必要的保密工作。

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

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

●对于客户委托开发的项目,立项建议工作可以适当地简化。

结项管理

结项管理(Project Closing Management, PCM)是指在项目开发工作结束后,对项目的有形资产和无形资产进行清算;对项目进行综合评估;总结经验教训等。

本规范阐述了结项管理的规程,该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。

1介绍

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

项目结束有两种状况:一是正常结束,二是异常结束。前者是指项目按预定计划结束。后者原因有多种,归根结底都是由于该项目不再符合机构的最大利益。例如有些项目因不适应市场而被中途淘汰,有些项目在执行过程中大大因偏离计划(如进度延误、费用超支)而被取消。

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

结项管理包括三项内容:

?对项目的有形资产和无形资产进行清算,既要防止资产流失,又要及时地利用这

些资产。

?对项目进行综合评估。例如评估项目完成情况、项目质量、投入产出分析、项目

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

重要依据。

?总结经验教训,使整个机构受益。

图2-1结项管理流程图

结项管理的流程如图1所示,产生的主要文档有:

?《结项申请书》,模板见[SPP-TEMP-PCM-REQUEST]。

?《结项评审报告》,模板见[SPP-TEMP-PCM-REVIEW]。

结项管理规程

目的

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

角色与职责

●项目经理撰写《结项申请书》,申请结项。

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

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

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

启动准则

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

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

进入结项管理流程。

输入

●《立项建议书》、《项目计划》等文档

主要步骤

●[Step1] 机构领导指示

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

确定何时结束项目。

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

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

●[Step2] 结项申请

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

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

◆项目介绍

◆计划与实际情况对比

◆主要工作成果

◆专利与版权情况

◆项目主要资产及处理意见

●[Step3] 机构领导审批

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

么批准进入“结项评审”阶段,转向[Step4]。否则返回[Step1]或[Step2]。

●[Step4] 结项评审

?[Step4.1] 准备

◆机构领导根据该项目的特征,成立一个结项评审委员会,确定一位主席。

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

有相关人员。

?[Step4.2] 项目资产检查与处理

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

如何有效地利用这些资产。

?[Step4.3] 项目综合评估

◆结项评审委员会对该项目进行综合评估,主要内容包括:

◆项目完成情况

◆项目质量

◆投入产出分析

◆项目的市场价值

◆项目对机构的贡献

?[Step4.4] 总结经验教训

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

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

?[Step4.5] 机构领导终审

◆结项评审委员会撰写《结项评审报告》,并交付给机构领导。

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

●[后续活动]

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

?机构领导和人力资源部考核项目经理和项目成员们的业绩,努力做到赏罚分明。输出

●《结项申请书》

●《结项评审报告》

结束准则

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

度量

●项目经理统计工作量和上述文档的规模。

补充

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

●做好必要的保密工作。

●对于客户委托开发的项目,[Step1]至[Step3]可以适当地简化,但是结项评审工作不能

简化。

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

项目计划

项目规划(Project Planning)的目的是为项目的研发和管理工作制定合理的行动纲领(即《项目计划》),以便所有相关人员按照该计划有条不紊地开展工作。

为了避免词义混淆,这里把动词Planning译为规划,把名词Plan译为计划(或计划书)。

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

?项目估计[PASS-PROC-PP-ESTIMATE]

?制定项目计划[PASS-PROC-PP-ESTABLISH]

?审批项目计划[PASS-PROC-PP-APPROVE]

?项目计划变更控制[PASS-PROC-PP-CHANGE]

上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。

1介绍

在立项管理过程域的项目筹备阶段(参见[SPP-PROC-PIM]),机构领导首先任命一位项目经理,之后机构领导协助项目经理筹备项目经费、人力资源、软件硬件资源等。如果必要的资金和资源已经到位,那么项目经理和核心成员即可组成一个项目规划小组,着手制定《项目计划》,并按计划执行研发和管理工作。

项目计划过程域有4个主要规程:“项目估计”、“制定项目计划”、“审批项目计划”和“项目计划变更控制”,流程如图3-1所示。

一、项目估计

项目估计是否准确将直接影响《项目计划》的有效性。项目估计要尽量做到“知己知彼”。“知彼”是指了解产品的需求,“知己”是指了解本项目的实力(即本项目实际能够拥有的经费、人力资源、软件硬件资源、技术水平等)。项目估计的重点内容是“产品范围估计”、“产品规模估计”、“工作量估计”和“成本估计”等。

在项目刚开始时,人们对产品需求的了解还比较肤浅,而项目实际能够拥有经费和资源很大程度上是靠项目经理争取的,不确定因素比较多。在这种情况下人们很难作出准确的估计。但是“估计”显然比“不估计”要好,否则《项目计划》就没有依据了。

二、制定项目计划

根据项目估计得到的数据,规划小组制定《项目计划》。《项目计划》的重点内容是“人力资源计划”、“软硬件资源计划”、“开支(财务)计划”、“任务与进度计划”、“下属计划”等。

由于需求开发花费的时间比较长(一般约占整个项目开发周期的20%),人们一般不会等到需求开发完成之后才开始制定《项目计划》。否则在那么长的时间里没有《项目计划》,众人不知如何开展活动,显然有害于项目。所以通常项目规划和需求开发是并行开展的(请参见SPP 模型图)。

三、审批项目计划

规划小组将《项目计划》递交给机构领导审批。如果机构领导批准了《项目计划》,那么该计划书可以正式发布(文件状态为Released),不可以被随便修改。项目的所有成员按照《项目计划》执行研发与管理工作。

四、项目计划变更控制

在项目执行过程中如果发现《项目计划》与实际情况有比较大的偏差,应当及时更新《项目计划》。变更《项目计划》必须按照指定的规程(即变更控制)执行,防止发生混乱。

图3-1项目规划流程图

项目规划过程域产生的主要文档有:

?《项目估计表》,模板见[SPP-TEMP-PP-ESTIMATE]。

?《项目计划》,模板见[SPP-TEMP-PP-PLAN]。

?《项目计划变更控制报告》,模板见[SPP-TEMP-PP-CONTROL]。

项目估计

目的

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

角色与职责

●项目规划小组由项目经理和核心成员组成,所有人员共同参与项目估计。

启动准则

●机构领导已经批准立项。

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

输入

●《立项建议书》和一些用户需求文档。

●用于项目估计的一些经验数据。

主要步骤

●[Step1] 估计项目范围

计划小组首先估计本项目的范围,可以用产品的WBS来表示。计划小组根据用户需求,分解产品的功能,制定产品的WBS,如图3-2所示。由于此处WBS仅用于项目估计而非用于系统设计,其细分程度由计划小组决定。

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

●[Step2] 估计产品规模

?产品规模的主要度量单位有:

?代码行

?类(对象)个数

?文档页数

?产品规模估计方法如下:

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

表格”(如表3-1所示)。

II.汇总每个成员的“产品规模估计表格”,进行对比分析。如果各人估计的差额小于10%,则取平均值。如果差额大于10%,则转向第I.步,规划小组各成员重新估

表3-1 产品规模估计表

●[Step3] 估计工作量

?项目的工作量是“项目研发工作量”、“项目管理工作量”、“机构支撑工作量”三

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

●[Step4] 估计成本

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

输出

●《项目估计表》

结束准则

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

度量

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

制定项目计划

目的

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

角色与职责

●项目规划小组由项目经理和核心成员组成,所有人员共同制定《项目计划》。

启动准则

●项目估计已经完成。

输入

●《立项建议书》和一些用户需求文档

●“项目估计表”

主要步骤

●[Step1] 确定目标与范围

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

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

●[Step2] 确定过程模型

?规划小组根据项目的特征,确定过程模型,包括项目研发过程、项目管理过程、

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

?规划小组确定(描述)过程模型中采用的方法与工具。例如采用Rational Rose进

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

Office制作文档等等。

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

?规划小组制定本项目的角色职责表,并为已知的项目成员分配角色(一个人可以

表3-2 人力资源计划

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

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

资源计划,如表3-3所示。主要内容包括:

?资源级别(分为“关键”、“普通”两种)

?详细配置

?获取方式(如“已经存在”、“可以借用”或“需要购买”等)与获取时间

表3-3 软硬件资源计划

●[Step5] 制定财务计划

表3-4 财务计划

●[Step6] 分配任务并制定进度表

?规划小组分配任务并制定进度表,建议采用Microsoft Project制作Gantt 图,附

在《项目计划》中。

●[Step7] 确定下属计划

表5-6 主要的下属计划

输出

●《项目计划》

结束准则

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

等错误)。

度量

●项目经理统计工作量以及文档规模。

审批项目计划

目的

●机构领导审批《项目计划》,确保该计划是合理的、符合机构现实的。

角色与职责

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

●如果《项目计划》有不合理之处,规划小组应根据机构领导的意见修正《项目计划》。启动准则

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

输入

●《项目计划》

主要步骤

●[Step1] 申请审批

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

或书面报告等形式。

●[Step2] 审批与修正

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

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

目计划》。

●[Step3] 批准生效

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

目计划》。

输出

●机构领导的审批意见(见《项目计划》的附录)。

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

结束准则

●机构领导签字批准了该《项目计划》。

度量

●项目经理统计工作量。

项目计划变更控制

目的

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

●控制《项目计划》的变更,防止发生混乱。

角色与职责

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

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

启动准则

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

●进度偏差超过了容许的误差,如20%;

●费用偏差超过了容许的误差,如20%;

●项目过程模型发生了显着的变化;

●用户需求发生了重大的变化;

●发生了对项目小组而言不可抗拒的变化,例如公司裁员、机构调整、产品发展战略调

整等。

输入

●原《项目计划》

主要步骤

●[Step1] 变更申请

?项目经理向机构领导申请变更《项目计划》。变更申请书中应当说明:

?变更原因

?变更的内容

?此变更对项目造成的影响

●[Step2] 审批变更申请

?机构领导审批变更申请:

?如果不同意变更,则退回变更请求,项目按照原计划执行。

?如果同意变更,转向[Step3]。

●[Step3] 修改项目计划

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

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

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

输出

●《项目计划变更控制报告》

●新的《项目计划书》

结束准则

●变更申请以及新的《项目计划》都得到了机构领导的批准。

度量

●项目经理统计工作量。

补充

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

●《项目计划》被机构领导批准之后,有关人员即可撰写下属计划如《配置管理计划》、

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

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

对于客户委托开发的项目,客户在项目规划过程域的介入程度视具体情况而定

项目监控

项目监控(Project Monitoring and Control, PMC)的目的是通过周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源、工作成果等,不断地了解项目的进展情况,以便当项目实际进展状况显着偏离计划时能够及时采取纠正措施。

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

?项目计划跟踪[PASS-PROC-PMC-TRACKING]

?控制偏差[PASS-PROC-PMC-CONTROL]

?项目进展汇报[PASS-PROC-PP-REPORT]

上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。

本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况(如商业目标、研发实力等)适当地修改本规范,然后推广使用。

1介绍

项目监控至少有以下几个好处:

(1)避免原本合理的计划在实施时落空;

(2)避免“执迷不悟”地按照不合理的计划行事;

(3)将监控过程产生的数据保存起来,为机构持续的过程改进提供有价值的数据。

项目监控过程域有3个主要规程:“项目计划跟踪”、“偏差控制”、“项目进展汇报”,流程如图4-1所示。

一、项目计划跟踪

项目经理周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源、工作成果等,从而及时了解项目的实际进展情况。

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

二、偏差控制

项目经理将跟踪得到的数据和《项目计划》中的数据进行对比,分析偏差,如果发现项目进展显着偏离计划,应当及时采取纠正措施。

三、项目进展汇报

项目经理周期性地召开会议,讨论项目进展情况,撰写“项目进展报告”并通报给机构领导和所有项目成员。

项目监控过程域产生的主要文档有:

?《项目监控数据表》,模板见[SPP-TEMP-PMC-DATA]。

?《项目偏差控制报告》,模板见[SPP-TEMP-PMC-CONTROL]。

?《项目进展报告》,模板见[SPP-TEMP-PP-REPORT]。

图4-1 项目监控流程

项目计划跟踪

目的

●周期性的跟踪任务(含进度和工作量)、费用、资源、工作成果等,及时了解项目的实

际进展情况。

●为持续过程改进提供有价值的数据。

角色与职责

●项目经理跟踪项目的实施。

●项目成员协助项目经理采集有关数据。

启动准则

●《项目计划》已经制定

输入

●《项目计划》

主要步骤

●[Step1] 任务跟踪

项目经理(或其指定的项目成员)周期性地(如每周一次)跟踪每个重要的任务,将

表4-1 任务跟踪表

●[Step2] 费用跟踪

项目经理(或其指定的项目成员)周期性地跟踪项目费用,将采集的数据保存在《项

表4-2 费用跟踪表

●[Step3] 资源跟踪

项目经理(或其指定的项目成员)周期性地跟踪软硬件资源,将采集的数据保存在《项

表6-3 资源跟踪表

●[Step4] 工作成果及其规模跟踪

项目经理(或其指定的项目成员)周期性地跟踪工作成果及其规模,将采集的数据保

表6-4 工作成果及其规模跟踪表

输出

●《项目监控数据表》

结束准则

●任务跟踪、费用跟踪、资源跟踪、工作成果跟踪所产生的数据已经保存在《项目监控

数据表》之中。

度量

●项目经理记录本规程产生的所有度量数据。

控制偏差

目的

●对比“项目实际进展”和“项目计划”,分析偏差,如果发现项目实际进展显着偏离计

划,则及时采取纠正措施。

角色与职责

●项目经理分析偏差,采取纠正措施。

启动准则

●周期性地跟踪进度、工作量、费用、资源、工作成果等,及时了解项目的实际进展情

况。

输入

●《项目计划》

●《项目监控数据表》

主要步骤

●[Step1] 找出显着偏差

?项目经理根据任务跟踪、费用跟踪、工作成果跟踪所产生的数据,对比“项目实

际进展”与“项目计划”,找出显着偏差项(例如进度或费用偏差大于20%)。

●[Step2] 分析原因

?项目经理分析产生显着偏差的原因,以便采取正确的纠正措施。

●[Step3] 给出纠正偏差的措施

?项目经理给出纠正显着偏差的措施:

?如果偏差主要是由于《项目计划》不合理导致的,则要变更项目计划,见规程

[SPP-PROC-PP-CHANGE]。

?如果《项目计划》本身是合理的,偏差主要是由于项目成员在执行时产生的,那

么要求项目成员弥补偏差,避免原本合理的计划在实施时落空。

●[Step4] 跟踪纠正偏差的过程

?项目经理跟踪纠正偏差的过程,直到该偏差被消除为止。

输出

●《项目偏差控制报告》

结束准则

●已发现的显着偏差被消除。

度量

●项目经理统计工作量。

项目进展汇报

目的

●周期性地汇报项目进展情况。

角色与职责

●项目经理周期性地总结项目进展情况,撰写《项目进展报告》并通报给机构领导和所

有项目成员。

启动准则

●已经开展“项目计划跟踪”和“偏差控制”。

输入

●《项目计划》

●《项目监控数据表》

●《项目偏差控制报告》

主要步骤

[Step1] 举行项目进展会议

相关主题