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

全套CMMi软件质量管理体系

136
2020年4月19日
文档仅供参考
XXXXX计算机软件有限公司
XX软件质量管理体系

V1.0

XX软件研发部
/12/1

目录
第一篇 总则 4
一、 《XX软件质量管理体系》的实施 4
二、 目的 4
三、 背景介绍 4
四、 体系总体介绍 5
第二篇 项目管理 7
一、 立项管理 7
二、 结项管理 14
三、 项目计划 18
四、 项目监控 27
五、 风险管理 33
六、 需求管理 37
第三篇 技术实现过程 43
一、 技术预研 43
二、 SCRUM过程 46
三、 用户验收 52
四、 技术评审 55
第四篇 支撑过程 61
一、 配置管理 61
二、 质量保证 67
三、 培训管理 73
四、 服务与维护 78

第一篇 总则
一、 《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实施时更加关注组织的实际价值、关注客户、关注创新。
四、 体系总体介绍
XX软件质量管理体系将项目的生命周期划分为以下14个控制域。
项目管理过程域
目的
立项管理
采纳符合机构最大利益的立项建议，经过立项管理使该建议成为正式的项目。杜绝不符合机构最大利益的立项建议被采纳，避免浪费机构的资源、资金、时间等。
结项管理
在项目开发工作结束后，对项目的有形资产和无形资产进行清算、对项目进行综合评估以及总结经验教训等。
项目规划
为项目的研发和管理工作制定合理的行动纲领（即项目计划），以便所有相关人员按照该计划有条不紊地开展工作。
项目监控
周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源等，不断地了解项目的进展情况，以便当项目实际进展显著偏离计划时能够及时采取纠正措施。
风险管理
在风险产生危害之前识别它们，从而有计划地消除或削弱风险。
需求管理
在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
项目研发过程域
目的
技术预研
在立项之后到开发工作完成之前的时间内，对项目将采用的关键技术提前学习和研究，尽可能早地发现并解决开发过程中将会遇到的技术障碍。
Scrum过程
设计软件系统的体系结构。分Scrum小组，使用敏捷方法实现软件产品，在每次迭代都产生能够交付的产品。最后在巩固过程中确保产品符合用户的需求。
客户验收
客户依据合同对产品进行审查和测试，确保产品满足客户需求。
技术评审
尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。
机构支撑过程域
目的
配置管理
经过执行版本控制、变更控制等规程，以及使用配置管理软件来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。
质量保证
提供一种有效的人员组织形式和管理方法，经过客观地检查和监控“过程质量”与“产品质量”，从而实现持续地改进质量。
培训管理
根据机构（或项目）的需求来制定培训计划，并监督该计划的实施，确保培训取得预期效果。
服务与维护
是指产品销售之后的客户服务和产品维护，其宗旨是提高客户对产品以及对开发方的满意度。

第二篇 项目管理
一、 立项管理
立项管理（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-1 立项管理流程

立项管理过程域产生的主要文档有：
² 《立项调查报告》
² 《立项可行性分析报告》
² 《立项建议书》
² 《立项评审报告》
2 立项建议阶段
2.1 目的
l 立项建议小组充分地进行立项调查、产品构思和可行性分析，撰写相应文档并申请立项。
2.2 角色与职责
l 立项建议小组一般由产品创作者（构思者）和商务部人员组成。该小组开展立项调查、产品构思、可行性分析等活动，在深思熟虑之后撰写《立项建议书》、《立项调查报告》和《立项可行性分析报告》并申请立项。
2.3 启动准则
l 立项建议小组已经成立。
2.4 输入
l 与目标产品有关的任何信息
2.5 主要步骤
l [Step1] 立项调查
n 立项建议小组开展立项调查，主要工作包括：
² 市场调查
² 政策调查
² 同类产品调查
² 竞争对手调查
² 用户调查
² 其它相关的调查
n 立项调查应当遵循以下原则：
² 调查者应当客观地对待被调查的事物，不可有意往“好处”或者“坏处”写。
² 调查报告中的数据、图表要真实而且有据可查，不可凭空捏造。
² 调查报告应通俗易懂，不可写成学术性的文章。
l [Step2] 产品构思
n 立项建议小组进行产品构思，主要内容包括：
² 待开发产品的主要功能
² 待开发产品的技术方案
² Make-or-Buy决策（确定哪些产品部件应当采购、外包开发或者自主研发。）
² 开发计划
² 市场营销计划
² 其它相关的计划
l [Step3] 可行性分析
n 立项建议小组开展可行性分析，主要内容包括：
² 市场可行性分析
² 政策可行性分析
² 竞争实力分析
² 技术可行性分析
² 时间和资源可行性分析
² 知识产权分析
² 其它相关的可行性分析
l [Step4] 撰写并完善立项建议相关文档
n 在进行了充分的立项调查、产品构思和可行性分析之后，立项建议小组撰写并完善《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及相关文档。
l [Step5] 申请立项
n 立项建议小组向机构领导递交《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及相关材料，申请立项。
2.6 输出
l 《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及相关文档。
2.7 结束准则
l 立项建议小组按照指定的模版撰写了《立项建议书》、《立项调查报告》和《立项可行性分析报告》，并做了内部审查（消除拼写、排版等错误）。
2.8 度量
l 立项建议小组统计工作量和上述文档的规模，将来汇报给项目经理。
3 立项评审
3.1 目的
l 机构领导组织立项评审委员会，对《项目建议书》进行评审，决定是否同意立项。
3.2 角色与职责
l 机构领导根据项目的特征组织立项评审委员会，并确定一位主席。主席应当具备比较丰富的评审经验，能够控制评审会议的进程。主席除了主持评审会议之外，还要负责撰写《立项评审报告》。
l 一般地，立项评审委员会由机构领导、各级经理、市场人员、技术专家、财务人员等组成。委员会按少数服从多数原则投票决定是否同意立项（此时机构领导只是一名委员，不具有一票否决权）。
l 立项建议小组陈述《立项建议书》的主要内容，并答复评审委员会的问题。
l 评审会议的记录员能够任意指定。记录员记录评审会议中的一些重要问答。
l 立项评审委员会决议之后，机构领导作最终审批（此时机构领导具有一票否决权）。
3.3 启动准则
l 立项建议小组已经申请立项，机构领导同意进行立项评审。
3.4 输入
l 《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及相关材料。
3.5 主要步骤
l [Step1] 准备
n 机构领导根据项目特征组织立项评审委员会，并确定一位主席。
n 主席确定评审会议的时间、地点、设备和参加会议的人员名单（包括评委、记录员、立项建议小组、旁听者等），并通知所有相关人员。
n 主席将《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及相关材料发给所有评委。各评委必须在举行评审会议之前阅读完上述材料，并及时与立项建议小组交流。
l [Step2] 举行评审会议
n [Step2.1] 主席宣讲本次评审会议的议程、重点、原则、时间限制等。
n [Step2.2] 立项建议小组陈述《立项建议书》的主要内容。
n [Step2.3] 答辩
² 评审委员会提出疑问，立项建议小组解答。双方应当对有争议的内容达成一致的处理意见。
² 记录员记录答辩过程的重要内容（问题、结论、建议等）。
n [Step2.4] 评估
² 评审委员会根据“立项评审检查表”认真地评估该项目。
² 评审委员会给出评审结论和意见：
² 主席撰写《立项评审报告》并递交给机构领导，本次评审会议结束。
l [Step3] 机构领导终审
n 机构领导在《立项评审报告》中签注最终审批结论和意见。
3.6 输出
l 《立项评审报告》
3.7 结束准则
l 评审委员会和机构领导已经在《立项评审报告》中签注结论和意见。
3.8 度量
l 评审委员会统计工作量和上述文档的规模，将来汇报给项目经理。
4 项目筹备
4.1 目的
l 任命一位合适的项目经理，并协助项目经理获取经费、人力资源、软件硬件资源等，以便顺利启动项目。
4.2 角色与职责
l 任命一位合适的项目经理，并协助项目经理获取经费、人力资源、软件硬件资源等。
l 项目经理组建团队，开始执行项目研发和管理工作。
4.3 启动准则
l 机构领导已经批准立项。
4.4 输入
l 评审、修正后的《立项建议书》
4.5 主要步骤
l [Step1] 任命项目经理
n 机构领导参考立项建议小组和评审委员会的意见，任命一位合适的项目经理。
l [Step2] 获取经费与资源
n 由于机构的资金和资源是有限的，机构可能难以完全按照《立项建议书》的要求给项目分配充分的资金和资源。机构领导和项目经理应当设法和财务部门、人力资源部门协商，尽可能为项目争取必要（充分）的资金和资源。
l [后续活动]
n 如果必要的资金和资源已经到位，项目经理和核心成员根据实际情况撰写《项目计划》，开始执行研发和管理工作。详见SPP 的项目计划过程域[SPP-PROC-PP]和需求开发过程域[SPP-PROC-RD]。
4.6 输出
l 项目经理使用经费和资源的凭证，例如经费本等。
4.7 结束准则
l 项目经理已经被任命，必要的资金和资源已经到位。
4.8 度量
l 项目经理统计工作量。
5 补充
l 对立项管理过程域产生的所有有价值的文档如《立项建议书》、《立项调查报告》、《立项可行性分析报告》、《立项评审报告》进行配置管理。
l 做好必要的保密工作。
l 由于每个项目都要占用机构的资金和资源，立项评审一定要严格。建议对机构高层管理人员进行必要的立项管理培训。
l 对于客户委托开发的项目，立项建议工作能够适当地简化。

二、 结项管理
结项管理（Project Closing Management, PCM）是指在项目开发工作结束后，对项目的有形资产和无形资产进行清算；对项目进行综合评估；总结经验教训等。
本规范阐述了结项管理的规程，该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
1 介绍
立项管理与结项管理是前后呼应的两个过程域，使得项目管理过程“有始有终”。
项目结束有两种状况：一是正常结束，二是异常结束。前者是指项目按预定计划结束。后者原因有多种，归根结底都是由于该项目不再符合机构的最大利益。例如有些项目因不适应市场而被中途淘汰，有些项目在执行过程中大大因偏离计划（如进度延误、费用超支）而被取消。
不论项目属于正常结束还是异常结束，都要按照结项管理规范处理。
结项管理包括三项内容：
² 对项目的有形资产和无形资产进行清算，既要防止资产流失，又要及时地利用这些资产。
² 对项目进行综合评估。例如评估项目完成情况、项目质量、投入产出分析、项目的市场价值、项目对企业的贡献等等。该评估报告能够作为考核项目人员业绩的重要依据。
² 总结经验教训，使整个机构受益。
综合评估
经验总结
结项评审
结项申请
机构领导审批
机构领导指示
资产检查

图2-1 结项管理流程图

结项管理的流程如图1所示，产生的主要文档有：
² 《结项申请书》，模板见 [SPP-TEMP-PCM-REQUEST]。
² 《结项评审报告》，模板见 [SPP-TEMP-PCM-REVIEW]。
2 结项管理规程
2.1 目的
l 对项目的有形资产和无形资产进行清算；对项目进行综合评估；总结经验教训等。
2.2 角色与职责
l 项目经理撰写《结项申请书》，申请结项。
l 机构领导对“是否结束项目”具有决定权。
l 机构领导根据项目的特征成立结项评审委员会。一般地，结项评审委员会由机构领导、各级经理、市场人员、技术专家、财务人员等组成。
2.3 启动准则
l 对于那些按照计划执行的项目而言，当项目已经开发完成时，能够进入结项管理流程。
l 对于那些不再符合机构最大利益的项目而言，如果机构领导明确指示结束项目，能够进入结项管理流程。
2.4 输入
l 《立项建议书》、《项目计划》等文档
2.5 主要步骤
l [Step1] 机构领导指示
n 对于那些不再符合机构最大利益的项目而言，机构领导应当明确指示该项目经理，确定何时结束项目。
n 对于那些按照计划执行的项目而言，当项目开发工作接近尾声时，机构领导和项目经理根据机构的现状，协商并确定何时结束项目。
l [Step2] 结项申请
n 遵照机构领导的指示，在预定的时间内，项目经理撰写《结项申请书》，并递交给机构领导。《结项申请书》主要内容包括：
u 项目介绍
u 计划与实际情况对比
u 主要工作成果
u 专利与版权情况
u 项目主要资产及处理意见
l [Step3] 机构领导审批
n 机构领导审阅《结项申请书》。如果该申请书符合机构的规章制度和企业利益，那么批准进入“结项评审”阶段，转向[Step4]。否则返回[Step1]或[Step2]。
l [Step4] 结项评审
n [Step4.1] 准备
u 机构领导根据该项目的特征，成立一个结项评审委员会，确定一位主席。
u 评审委员会主席和项目经理共同确定结项评审的时间、地点等等，并通知所有相关人员。
n [Step4.2] 项目资产检查与处理
u 结项评审委员会检查该项目的有形资产和无形资产，并和项目经理共同商讨如何有效地利用这些资产。
n [Step4.3] 项目综合评估
u 结项评审委员会对该项目进行综合评估，主要内容包括：
u 项目完成情况
u 项目质量
u 投入产出分析
u 项目的市场价值
u 项目对机构的贡献
n [Step4.4] 总结经验教训
u 结项评审委员会和项目成员们共同总结经验教训，并以文档的形式保存下来，在机构内共享，使集体受益。
n [Step4.5] 机构领导终审
u 结项评审委员会撰写《结项评审报告》，并交付给机构领导。
u 机构领导签注最终意见，项目正式结束。
l [后续活动]
n 举行集体活动、座谈会、宴会等等，原项目成员们交流思想，增进感情。
n 机构领导和人力资源部考核项目经理和项目成员们的业绩，努力做到赏罚分明。
2.6 输出
l 《结项申请书》
l 《结项评审报告》
2.7 结束准则
l 《结项评审报告》已经撰写完毕，机构领导签注最终意见。
2.8 度量
l 项目经理统计工作量和上述文档的规模。
3 补充
l 对结项管理过程域产生的所有有价值的文档进行配置管理。
l 做好必要的保密工作。
l 对于客户委托开发的项目，[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]。
2 项目估计
2.1 目的
l 估计项目的范围、产品规模、工作量、成本等，为制定《项目计划》提供依据。
2.2 角色与职责
l 项目规划小组由项目经理和核心成员组成，所有人员共同参与项目估计。
2.3 启动准则
l 机构领导已经批准立项。
l 项目规划小组已经成立。
2.4 输入
l 《立项建议书》和一些用户需求文档。
l 用于项目估计的一些经验数据。
2.5 主要步骤
l [Step1] 估计项目范围
计划小组首先估计本项目的范围，能够用产品的WBS来表示。计划小组根据用户需求，分解产品的功能，制定产品的WBS，如图3-2所示。由于此处WBS仅用于项目估计而非用于系统设计，其细分程度由计划小组决定。

产品（系统）

组件C3
组件C2
组件C1
组件B1
组件B3
组件B2
组件A3
组件A2
组件A1
子系统A
子系统C
子系统B

图3-2 用于项目估计的产品WBS示意图
l [Step2] 估计产品规模
n 产品规模的主要度量单位有：
² 代码行
² 类（对象）个数
² 文档页数
n 产品规模估计方法如下：
I. 规划小组各成员根据产品的WBS，独立地估计产品的规模，填写“产品规模估计表格”（如表3-1所示）。
II. 汇总每个成员的“产品规模估计表格”，进行对比分析。如果各人估计的差额小于10％，则取平均值。如果差额大于10％，则转向第I.步，规划小组各成员重新估计产品的规模，直到各人估计的差额小于10％为止。

产品的组件
新开发组件的规模
（代码行、类、文档页数）
复用或自动生成的组件的规模
（代码行、类、文档页数）
组件1

组件2

组件3

…

总和

表3-1 产品规模估计表
l [Step3] 估计工作量
n 项目的工作量是“项目研发工作量”、“项目管理工作量”、“机构支撑工作量”三者之和。工作量的度量单位能够是“人小时”、“人天”、“人月”或“人年”。

l [Step4] 估计成本
n 规划小组估计人力资源成本、软硬件资源成本、商务活动成本等。
2.6 输出
l 《项目估计表》
2.7 结束准则
l 规划小组已经按照本规程进行了项目估计，并产生了《项目估计表》。
2.8 度量
l 项目经理记录本规程产生的所有估计数据。
3 制定项目计划
3.1 目的
l 根据项目估计产生的数据，制定《项目计划》。
3.2 角色与职责
l 项目规划小组由项目经理和核心成员组成，所有人员共同制定《项目计划》。
3.3 启动准则
l 项目估计已经完成。
3.4 输入
l 《立项建议书》和一些用户需求文档
l “项目估计表”
3.5 主要步骤
l [Step1] 确定目标与范围
n 规划小组首先确定本项目的目标与工作范围。目标必须是“可实现的”和“可验证的”。工作范围包括“做什么”和“不做什么”。
l [Step2] 确定过程模型
n 规划小组根据项目的特征，确定过程模型，包括项目研发过程、项目管理过程、机构支撑过程等。例如裁剪SPP模型。
n 规划小组确定（描述）过程模型中采用的方法与工具。例如采用Rational Rose进行面向对象分析与设计，采用Visual SourceSafe进行配置管理，采用Microsoft Office制作文档等等。
l [Step3] 制定人力资源计划
n 规划小组制定本项目的角色职责表，并为已知的项目成员分配角色（一个人能够兼多个角色），如表3-2所示。

角色
职责
人员
工作说明

…

表3-2 人力资源计划

l [Step4] 制定软硬件资源计划
n 规划小组分析项目开发、测试以及用户使用产品所需的软硬件资源，制定软硬件资源计划，如表3-3所示。主要内容包括：
² 资源级别（分为“关键”、“普通”两种）
² 详细配置
² 获取方式（如“已经存在”、“能够借用”或“需要购买”等）与获取时间
² 用途（如“谁”在“什么”时候使用）

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

关键

关键

…
普通

表3-3 软硬件资源计划
l [Step5] 制定财务计划
n 规划小组制定财务计划，如表3-4所示。

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

表3-4 财务计划
l [Step6] 分配任务并制定进度表
n 规划小组分配任务并制定进度表，建议采用Microsoft Project制作Gantt 图，附在《项目计划》中。
l [Step7] 确定下属计划
n 规划小组确定本《项目计划》主要的下属计划，如表5-6所示。

下属计划的名称
建议负责人
预计产生时间
《配置管理计划》
配置管理员

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

《技术评审计划》

一些开发计划

一些测试计划

…

表5-6 主要的下属计划
3.6 输出
l 《项目计划》
3.7 结束准则
l 规划小组已经按照指定的模版撰写了《项目计划》，并做了内部审查（消除拼写、排版等错误）。
3.8 度量
l 项目经理统计工作量以及文档规模。
4 审批项目计划
4.1 目的
l 机构领导审批《项目计划》，确保该计划是合理的、符合机构现实的。
4.2 角色与职责
l 机构领导审批《项目计划》。
l 如果《项目计划》有不合理之处，规划小组应根据机构领导的意见修正《项目计划》。
4.3 启动准则
l 规划小组已经制定了《项目计划》。
4.4 输入
l 《项目计划》
4.5 主要步骤
l [Step1] 申请审批
n 项目经理将《项目计划》提交给机构领导，申请审批。申请书能够采用电子邮件或书面报告等形式。
l [Step2] 审批与修正
n 机构领导根据“项目计划检查表”认真审批《项目计划》。
n 如果《项目计划》有不合理之处，规划小组应根据机构领导的意见及时修正《项目计划》。
l [Step3] 批准生效
n 机构领导签字批准后，该《项目计划》正式生效，此后规划小组不能随意修改《项目计划》。
4.6 输出
l 机构领导的审批意见（见 《项目计划》的附录）。
l 按评审意见修正后的《项目计划》。
4.7 结束准则
l 机构领导签字批准了该《项目计划》。
4.8 度量
l 项目经理统计工作量。
5 项目计划变更控制
5.1 目的
l 修改原《项目计划》中不合理的内容，产生新的《项目计划》。
l 控制《项目计划》的变更，防止发生混乱。
5.2 角色与职责
l 机构领导审批变更申请。
l 项目经理更新《项目计划》。
5.3 启动准则
若下列之一发生，应当变更原《项目计划》：
l 进度偏差超过了容许的误差，如20％；
l 费用偏差超过了容许的误差，如20％；
l 项目过程模型发生了显著的变化；
l 用户需求发生了重大的变化；
l 发生了对项目小组而言不可抗拒的变化，例如公司裁员、机构调整、产品发展战略调整等。
5.4 输入
l 原《项目计划》
5.5 主要步骤
l [Step1] 变更申请
n 项目经理向机构领导申请变更《项目计划》。变更申请书中应当说明：
² 变更原因
² 变更的内容
² 此变更对项目造成的影响
l [Step2] 审批变更申请
n 机构领导审批变更申请：
² 如果不同意变更，则退回变更请求，项目按照原计划执行。
² 如果同意变更，转向 [Step3]。
l [Step3] 修改项目计划
n 项目经理修改原《项目计划》，产生新的《项目计划》。
l [Step4] 审批新的项目计划
n 机构领导审批新的《项目计划》，参见规程 [SPP-PROC-PP-APPROVE]。
5.6 输出
l 《项目计划变更控制报告》
l 新的《项目计划书》
5.7 结束准则
l 变更申请以及新的《项目计划》都得到了机构领导的批准。
5.8 度量
l 项目经理统计工作量。
6 补充
l 对项目规划过程域产生的所有有价值的文档进行配置管理。
l 《项目计划》被机构领导批准之后，有关人员即可撰写下属计划如《配置管理计划》、《质量保证计划》、一些开发计划和测试计划等。
l 选用合适的软件工具，尽量减少项目规划过程域的工作量。
对于客户委托开发的项目，客户在项目规划过程域的介入程度视具体情况而定

四、 项目监控
项目监控（Project Monitoring and Control, PMC）的目的是经过周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源、工作成果等，不断地了解项目的进展情况，以便当项目实际进展状况显著偏离计划时能够及时采取纠正措施。
项目监控过程域是SPP模型的重要组成部分。本规范阐述了项目监控过程域的三个主要规程：
² 项目计划跟踪 [PASS-PROC-PMC-TRACKING]
² 控制偏差 [PASS-PROC-PMC-CONTROL]
² 项目进展汇报 [PASS-PROC-PP-REPORT]
上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。