全套CMMi软件质量管理体系.docx
- 文档编号:27197250
- 上传时间:2023-06-28
- 格式:DOCX
- 页数:93
- 大小:377.28KB
全套CMMi软件质量管理体系.docx
《全套CMMi软件质量管理体系.docx》由会员分享,可在线阅读,更多相关《全套CMMi软件质量管理体系.docx(93页珍藏版)》请在冰豆网上搜索。
全套CMMi软件质量管理体系
XXXXX计算机软件有限公司
XX软件质量管理体系
V1.0
XX软件研发部
2010/12/1
第一篇总则
一、《XX软件质量管理体系》的实施
XX计算机软件有限公司依据CMMi(软件能力成熟度模型集成)框架,结合公司多年来实施“敏捷开发”的开发方法的经验,以及公司的实际情况,编写的《XX软件质量管理体系》V1.0版已经编写完成。
本体系文档是公司质量管理体系法规性文件,是指导公司建立并实施质量管理体系的行动准则。
公司全体员工必须遵照执行。
二、目的
本文档的目的在于:
通过建立软件过程管理体系,提高企业的软件过程能力,保证软件质量,保证商务目标的实现。
基于精简的CMMi3级管理体系,结合企业实际情况和经验积累,结合敏捷开发的SCRUM方法。
开发适合XX软件有限公司发展的软件过程管理体系。
使得XX软件的软件开发过程管理基本满足CMMi3级要求。
三、背景介绍
CMMI-DEV
CMMI是个了不起的规范,但是仍然有很多不足之处。
CMMI对于项目管理很有指导价值,但是它对技术开发过程的论述却不够深入。
对于大多数软件项目而言,技术开发占总工作量的70%以上,而项目管理占总工作量的30%以下。
对大多数企业而言,技术开发过程的规范化比项目管理过程的规范化尤为重要与迫切。
软件开发是如此的灵活,如果没有规范来指导与制约,就容易因无序而导致混乱。
但是规范如果不切实际或者太严密了,就容易畸变成为死板的教条,会扼杀开发人员生机勃勃的创造力。
软件过程规范应当力求简单实用。
Scrum
由KenSchwaber和JeffSutherland提出,旨在寻求充分发挥面向对象和构件技术的开发方法,是对迭代式面向对象方法的改进,名称来自英式橄榄球(在比赛中每个队员都应时刻保持对场上全局的判断,然后通过集体行动,奋力实现同一目标──胜利)。
SCRUM方法最初实践于Easel公司(1993年),现已被数十家公司数百个项目开发中应用,适用于需求难以预测的复杂商务应用产品的开发[11]。
SCRUM提出的SCRUMMeeting、Sprint、Backlog、SCRUMMaster、SCRUMTeam、Demo等模式已被PLOP作为组织和过程模式(OrganizationalandProcessPattern)的标准。
SCRUM将工业过程控制中的概念应用到软件开发中来,认为软件开发过程更多是经验性过程(EmpiricalProcess),而不是确定性过程(DefinedProcess)。
确定性过程是可明确描述的、可预测的过程,因而可重复(Repeatable)执行并能产生预期的结果,并能通过科学理论对其最优化。
经验性过程与之相反,应作为一个黑箱(Blackbox)来处理,通过对黑箱的输入输出不断进行度量,在此基础上,结合经验判断对黑箱进行调控,使其不越出设定的边界,从而产生满意的输出。
SCRUM方法将传统开发中的分析、设计、实施视为一个黑箱,认为应加强黑箱内部的混沌性,使项目组工作在混沌的边沿,充分发挥人的创造力。
总而言之,CMMI和敏捷开发能够很好地相互补充、相互支持。
首先在关注点上CMMI关注组织级或企业级改进,关注回答项目应该做什么,而不是具体怎么做的方法,而敏捷开发则更关注项目级改进,关注项目具体怎么做的方法和最佳实践,这使双方在定位方面形成很好的相互补充的态势。
一方面CMMI为敏捷提供组织级扩展的能力和必须的组织治理框架,便于组织级对敏捷最佳实践的推广和重用;另一方面,敏捷为CMMI提供了项目级的具体实践方法,确保团队在CMMI框架下能够快速响应,不断创新,持续交付价值。
两者的有效结合,能够有效实现个人绩效向团队绩效、向组织绩效的转变过程。
同时,也可以通过敏捷实践,规避CMMI实施过程中重文档、重流程的不良倾向,使CMMI实施时更加关注组织的实际价值、关注客户、关注创新。
四、体系总体介绍
XX软件质量管理体系将项目的生命周期划分为以下14个控制域。
项目管理过程域
目的
立项管理
采纳符合机构最大利益的立项建议,通过立项管理使该建议成为正式的项目。
杜绝不符合机构最大利益的立项建议被采纳,避免浪费机构的资源、资金、时间等。
结项管理
在项目开发工作结束后,对项目的有形资产和无形资产进行清算、对项目进行综合评估以及总结经验教训等。
项目规划
为项目的研发和管理工作制定合理的行动纲领(即项目计划),以便所有相关人员按照该计划有条不紊地开展工作。
项目监控
周期性地跟踪项目计划的各种参数如进度、工作量、费用、资源等,不断地了解项目的进展情况,以便当项目实际进展显著偏离计划时能够及时采取纠正措施。
风险管理
在风险产生危害之前识别它们,从而有计划地消除或削弱风险。
需求管理
在客户与开发方之间建立对需求的共同理解,维护需求与其它工作成果的一致性,并控制需求的变更。
项目研发过程域
目的
技术预研
在立项之后到开发工作完成之前的时间内,对项目将采用的关键技术提前学习和研究,尽可能早地发现并解决开发过程中将会遇到的技术障碍。
Scrum过程
设计软件系统的体系结构。
分Scrum小组,使用敏捷方法实现软件产品,在每次迭代都产生可以交付的产品。
最后在巩固过程中确保产品符合用户的需求。
客户验收
客户依据合同对产品进行审查和测试,确保产品满足客户需求。
技术评审
尽早地发现工作成果中的缺陷,并帮助开发人员及时消除缺陷,从而有效地提高产品的质量。
机构支撑过程域
目的
配置管理
通过执行版本控制、变更控制等规程,以及使用配置管理软件来保证所有配置项的完整性和可跟踪性。
配置管理是对工作成果的一种有效保护。
质量保证
提供一种有效的人员组织形式和管理方法,通过客观地检查和监控“过程质量”与“产品质量”,从而实现持续地改进质量。
培训管理
根据机构(或项目)的需求来制定培训计划,并监督该计划的实施,确保培训取得预期效果。
服务与维护
是指产品销售之后的客户服务和产品维护,其宗旨是提高客户对产品以及对开发方的满意度。
第二篇项目管理
五、立项管理
立项管理(ProjectInitializationManagement,PIM)的目的是:
(1)采纳符合机构最大利益的立项建议,通过立项管理使该建议成为正式的项目(即合法化)。
(2)杜绝不符合机构最大利益的立项建议被采纳,避免浪费机构的人力资源、资金、时间等。
立项管理是决策行为,其目标是“做正确的事情”(dorightthings)。
而立项之后的研发活动和管理活动的目标是“正确地做事情”(dothingsright)。
只有“正确的决策”加上“正确地执行”才可能产生优秀的产品。
立项管理过程域是SPP模型的重要组成部分。
本规范阐述了立项管理过程域的三个主要规程:
立项建议[PASS-PROC-PIM-PROPOSAL]
立项评审[PASS-PROC-PIM-REVIEW]
项目筹备[PASS-PROC-PIM-PREPARE]
上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内IT企业的软件研发项目。
建议用户根据自身情况(如商业目标、研发实力等)适当地修改本规范,然后推广使用。
1介绍
立项管理流程分三个阶段:
“立项建议阶段”、“立项评审阶段”和“项目筹备阶段”,如图1所示。
一、立项建议阶段
立项建议小组应反复地进行立项调查、产品构思和可行性分析。
在深思熟虑之后,立项建议小组撰写《立项建议书》,并申请立项。
要注意的是,由于立项调查和可行性分析通常比较费时费力,往往被人忽视。
而草率撰写的《立项建议书》会有比较多的主观臆断,这对项目是有危害的。
产品构思通常不可能快速完成,切不可闭门造车。
深入地进行立项调查与可行性分析不仅对产品构思有帮助,而且对立项评审也有帮助。
二、立项评审阶段
机构领导组织一个评审委员会进行立项评审。
评审委员会根据《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及立项建议小组的答辩,投票决定是否同意立项(按少数服从多数原则)。
评审委员会应根据机构的实际情况(发展战略、资金、人力资源等),对《立项建议书》提出改进意见。
机构领导对立项具有最终审批权。
如果机构领导赞同评审委员会的决策,那么他们将共同分担决策责任。
如果机构领导行使“一票否决权”,那么他将对该决策负全部责任。
三、项目筹备阶段
机构领导任命一位项目经理。
通常情况下,立项建议小组的负责人将被任命为项目经理,这样有利于激发员工的工作热情。
但是如果此人不适合于任项目经理,那么机构领导应该另外任命一位合适的项目经理。
项目经理被任命之后,机构领导协助项目经理获取项目经费、人力资源、软硬件资源等。
要注意的是,如果项目所需的资金和资源难以按时到位,此时项目经理不可老在等待或只是抱怨,应当主动设法克服困难,尽早行动起来。
很多时候,资金和资源是争取来的,而不是等来的。
如果必要的资金和资源已经到位,项目经理和项目核心成员根据实际情况撰写《项目计划》,执行项目研发和管理工作。
图1-1立项管理流程
立项管理过程域产生的主要文档有:
《立项调查报告》
《立项可行性分析报告》
《立项建议书》
《立项评审报告》
2立项建议阶段
2.1目的
立项建议小组充分地进行立项调查、产品构思和可行性分析,撰写相应文档并申请立项。
2.2角色与职责
立项建议小组一般由产品创作者(构思者)和商务部人员组成。
该小组开展立项调查、产品构思、可行性分析等活动,在深思熟虑之后撰写《立项建议书》、《立项调查报告》和《立项可行性分析报告》并申请立项。
2.3启动准则
立项建议小组已经成立。
2.4输入
与目标产品有关的任何信息
2.5主要步骤
[Step1]立项调查
立项建议小组开展立项调查,主要工作包括:
市场调查
政策调查
同类产品调查
竞争对手调查
用户调查
其他相关的调查
立项调查应当遵循以下原则:
调查者应当客观地对待被调查的事物,不可有意往“好处”或者“坏处”写。
调查报告中的数据、图表要真实并且有据可查,不可凭空捏造。
调查报告应通俗易懂,不可写成学术性的文章。
[Step2]产品构思
立项建议小组进行产品构思,主要内容包括:
待开发产品的主要功能
待开发产品的技术方案
Make-or-Buy决策(确定哪些产品部件应当采购、外包开发或者自主研发。
)
开发计划
市场营销计划
其他相关的计划
[Step3]可行性分析
立项建议小组开展可行性分析,主要内容包括:
市场可行性分析
政策可行性分析
竞争实力分析
技术可行性分析
时间和资源可行性分析
知识产权分析
其他相关的可行性分析
[Step4]撰写并完善立项建议相关文档
在进行了充分的立项调查、产品构思和可行性分析之后,立项建议小组撰写并完善《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及相关文档。
[Step5]申请立项
立项建议小组向机构领导递交《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及相关材料,申请立项。
2.6输出
《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及相关文档。
2.7结束准则
立项建议小组按照指定的模版撰写了《立项建议书》、《立项调查报告》和《立项可行性分析报告》,并做了内部审查(消除拼写、排版等错误)。
2.8度量
立项建议小组统计工作量和上述文档的规模,将来汇报给项目经理。
3立项评审
3.1目的
机构领导组织立项评审委员会,对《项目建议书》进行评审,决定是否同意立项。
3.2角色与职责
机构领导根据项目的特征组织立项评审委员会,并确定一位主席。
主席应当具备比较丰富的评审经验,能够控制评审会议的进程。
主席除了主持评审会议之外,还要负责撰写《立项评审报告》。
一般地,立项评审委员会由机构领导、各级经理、市场人员、技术专家、财务人员等组成。
委员会按少数服从多数原则投票决定是否同意立项(此时机构领导只是一名委员,不具有一票否决权)。
立项建议小组陈述《立项建议书》的主要内容,并答复评审委员会的问题。
评审会议的记录员可以任意指定。
记录员记录评审会议中的一些重要问答。
立项评审委员会决议之后,机构领导作最终审批(此时机构领导具有一票否决权)。
3.3启动准则
立项建议小组已经申请立项,机构领导同意进行立项评审。
3.4输入
《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及相关材料。
3.5主要步骤
[Step1]准备
机构领导根据项目特征组织立项评审委员会,并确定一位主席。
主席确定评审会议的时间、地点、设备和参加会议的人员名单(包括评委、记录员、立项建议小组、旁听者等),并通知所有相关人员。
主席将《立项建议书》、《立项调查报告》、《立项可行性分析报告》以及相关材料发给所有评委。
各评委必须在举行评审会议之前阅读完上述材料,并及时与立项建议小组交流。
[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主要步骤
[Step1]任命项目经理
机构领导参考立项建议小组和评审委员会的意见,任命一位合适的项目经理。
[Step2]获取经费与资源
由于机构的资金和资源是有限的,机构可能难以完全按照《立项建议书》的要求给项目分配充足的资金和资源。
机构领导和项目经理应当设法和财务部门、人力资源部门协商,尽可能为项目争取必要(充分)的资金和资源。
[后续活动]
如果必要的资金和资源已经到位,项目经理和核心成员根据实际情况撰写《项目计划》,开始执行研发和管理工作。
详见SPP的项目计划过程域[SPP-PROC-PP]和需求开发过程域[SPP-PROC-RD]。
4.6输出
项目经理使用经费和资源的凭证,例如经费本等。
4.7结束准则
项目经理已经被任命,必要的资金和资源已经到位。
4.8度量
项目经理统计工作量。
5补充
对立项管理过程域产生的所有有价值的文档如《立项建议书》、《立项调查报告》、《立项可行性分析报告》、《立项评审报告》进行配置管理。
做好必要的保密工作。
由于每个项目都要占用机构的资金和资源,立项评审一定要严格。
建议对机构高层管理人员进行必要的立项管理培训。
对于客户委托开发的项目,立项建议工作可以适当地简化。
六、结项管理
结项管理(ProjectClosingManagement,PCM)是指在项目开发工作结束后,对项目的有形资产和无形资产进行清算;对项目进行综合评估;总结经验教训等。
本规范阐述了结项管理的规程,该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
6介绍
立项管理与结项管理是前后呼应的两个过程域,使得项目管理过程“有始有终”。
项目结束有两种状况:
一是正常结束,二是异常结束。
前者是指项目按预定计划结束。
后者原因有多种,归根结底都是由于该项目不再符合机构的最大利益。
例如有些项目因不适应市场而被中途淘汰,有些项目在执行过程中大大因偏离计划(如进度延误、费用超支)而被取消。
不论项目属于正常结束还是异常结束,都要按照结项管理规范处理。
结项管理包括三项内容:
对项目的有形资产和无形资产进行清算,既要防止资产流失,又要及时地利用这些资产。
对项目进行综合评估。
例如评估项目完成情况、项目质量、投入产出分析、项目的市场价值、项目对企业的贡献等等。
该评估报告可以作为考核项目人员业绩的重要依据。
总结经验教训,使整个机构受益。
图2-1结项管理流程图
结项管理的流程如图1所示,产生的主要文档有:
《结项申请书》,模板见[SPP-TEMP-PCM-REQUEST]。
《结项评审报告》,模板见[SPP-TEMP-PCM-REVIEW]。
7结项管理规程
7.1目的
对项目的有形资产和无形资产进行清算;对项目进行综合评估;总结经验教训等。
7.2角色与职责
项目经理撰写《结项申请书》,申请结项。
机构领导对“是否结束项目”具有决定权。
机构领导根据项目的特征成立结项评审委员会。
一般地,结项评审委员会由机构领导、各级经理、市场人员、技术专家、财务人员等组成。
7.3启动准则
对于那些按照计划执行的项目而言,当项目已经开发完成时,可以进入结项管理流程。
对于那些不再符合机构最大利益的项目而言,如果机构领导明确指示结束项目,可以进入结项管理流程。
7.4输入
《立项建议书》、《项目计划》等文档
7.5主要步骤
[Step1]机构领导指示
对于那些不再符合机构最大利益的项目而言,机构领导应当明确指示该项目经理,确定何时结束项目。
对于那些按照计划执行的项目而言,当项目开发工作接近尾声时,机构领导和项目经理根据机构的现状,协商并确定何时结束项目。
[Step2]结项申请
遵照机构领导的指示,在预定的时间内,项目经理撰写《结项申请书》,并递交给机构领导。
《结项申请书》主要内容包括:
项目介绍
计划与实际情况对比
主要工作成果
专利与版权情况
项目主要资产及处理意见
[Step3]机构领导审批
机构领导审阅《结项申请书》。
如果该申请书符合机构的规章制度和企业利益,那么批准进入“结项评审”阶段,转向[Step4]。
否则返回[Step1]或[Step2]。
[Step4]结项评审
[Step4.1]准备
机构领导根据该项目的特征,成立一个结项评审委员会,确定一位主席。
评审委员会主席和项目经理共同确定结项评审的时间、地点等等,并通知所有相关人员。
[Step4.2]项目资产检查与处理
结项评审委员会检查该项目的有形资产和无形资产,并和项目经理共同商讨如何有效地利用这些资产。
[Step4.3]项目综合评估
结项评审委员会对该项目进行综合评估,主要内容包括:
项目完成情况
项目质量
投入产出分析
项目的市场价值
项目对机构的贡献
[Step4.4]总结经验教训
结项评审委员会和项目成员们共同总结经验教训,并以文档的形式保存下来,在机构内共享,使集体受益。
[Step4.5]机构领导终审
结项评审委员会撰写《结项评审报告》,并交付给机构领导。
机构领导签注最终意见,项目正式结束。
[后续活动]
举行集体活动、座谈会、宴会等等,原项目成员们交流思想,增进感情。
机构领导和人力资源部考核项目经理和项目成员们的业绩,努力做到赏罚分明。
7.6输出
《结项申请书》
《结项评审报告》
7.7结束准则
《结项评审报告》已经撰写完毕,机构领导签注最终意见。
7.8度量
项目经理统计工作量和上述文档的规模。
8补充
对结项管理过程域产生的所有有价值的文档进行配置管理。
做好必要的保密工作。
对于客户委托开发的项目,[Step1]至[Step3]可以适当地简化,但是结项评审工作不能简化。
对结项评审委员会进行必要的培训,使他们树立正确的观念,从而严格把关。
七、项目计划
项目规划(ProjectPlanning)的目的是为项目的研发和管理工作制定合理的行动纲领(即《项目计划》),以便所有相关人员按照该计划有条不紊地开展工作。
为了避免词义混淆,这里把动词Planning译为规划,把名词Plan译为计划(或计划书)。
项目规划过程域是SPP模型的重要组成部分。
本规范阐述了项目规划过程域的四个主要规程:
项目估计[PASS-PROC-PP-ESTIMATE]
制定项目计划[PASS-PROC-PP-ESTABLISH]
审批项目计划[PASS-PROC-PP-APPROVE]
项目计划变更控制[PASS-PROC-PP-CHANGE]
上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
9介绍
在立项管理过程域的项目筹备阶段(参见[SPP-PROC-PIM]),机构领导首先任命一位项目经理,之后机构领导协助项目经理筹备项目经费、人力资源、软件硬件资源等。
如果必要的资金和资源已经到位,那么项目经理和核心成员即可组成一个项目规划小组,着手制定《项目计划》,并按计划执行研发和管理工作。
项目计划过程域有4个主要规程:
“项目估计”、“制定项目计划”、“审批项目计划”和“项目计划变更控制”,流程如图3-1所示。
一、项目估计
项目估计是否准确将直接影响《项目计划》的有效性。
项目估计要尽量做到“知己知彼”。
“知彼”是指了解产品的需求,“知己”是指了解本项目的实力(即本项目实际能够拥有的经费、人力资源、软件硬件资源、技术水平等)。
项目估计的重点内容是“产品范围估计”、“产品规模估计”、“工作量估计”和“成本估计”等。
在项目刚开始时,人们对产品需求的了解还比较肤浅,而项目实际能够拥有经费和资源很大程度上是靠项目经理争取的,不确定因素比较多。
在这种情况下人们很难作出准确的估计。
但是“估计”显然比“不估计”要好,否则《项目计划》就没有依据了。
二、制定项目计划
根据项目估计得到的数据,规划小组制定《项目计划》。
《项目计划》的重点内容是“人力资源计划”、“软硬件资源计划”、“开支(财务)计划”、“任务与进度计划”、“下属计划”等。
由于需求开发花费的时间比较长(一般约占整个项目开发周期的20%),人们一般不会等到需求开发完成之后才开始制定《项目计划》。
否则在那么长的时间里没有《项目计划》,众人不知如何开展活动,显然有害于项目。
所以通常项目规划和需求开发是并行开展的(请参见SPP模型图)。
三、审批项目计划
规划小组将《项目计划》递交给机构领导审批。
如果机构领导批准了《项目计划》,那么该计划书可以正式发布(文件状态为Released),不可以被随便修改。
项目的所有成员按照《项目计划》执行研发与管理工作。
四、项目计划变更控制
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 全套 CMMi 软件 质量管理 体系
![提示](https://static.bdocx.com/images/bang_tan.gif)