文档详情

全套CMMi软件质量管理体系

cn****1
实名认证
店铺
DOCX
121.46KB
约75页
文档ID:465804727
全套CMMi软件质量管理体系_第1页
1/75

X计算机软件####软件质量管理体系V1.0##软件研发部2010/12/177 / 77目录第一篇总则4一、《##软件质量管理体系》的实施4二、目的4三、背景介绍4四、体系总体介绍5第二篇项目管理7一、立项管理7二、结项管理14三、项目计划18四、项目监控27五、风险管理33六、需求管理37第三篇技术实现过程43一、技术预研43二、SCRUM过程46三、用户验收52四、技术评审55第四篇支撑过程61一、配置管理61二、质量保证67三、培训管理73四、服务与维护78第一篇 总则一、 《##软件质量管理体系》的实施##计算机软件##依据CMMi〔软件能力成熟度模型集成〕框架,结合公司多年来实施"敏捷开发"的开发方法的经验,以与公司的实际情况,编写的《##软件质量管理体系》V1.0版已经编写完成.本体系文档是公司质量管理体系法规性文件,是指导公司建立并实施质量管理体系的行动准则.公司全体员工必须遵照执行.二、 目的本文档的目的在于:² 通过建立软件过程管理体系,提高企业的软件过程能力,保证软件质量,保证商务目标的实现.² 基于精简的CMMi 3级管理体系,结合企业实际情况和经验积累,结合敏捷开发的SCRUM方法.开发适合##软件##发展的软件过程管理体系.² 使得##软件的软件开发过程管理基本满足CMMi 3级要求.三、 背景介绍CMMI-DEVCMMI是个了不起的规范,但是仍然有很多不足之处.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将工业过程控制中的概念应用到软件开发中来,认为软件开发过程更多是经验性过程,而不是确定性过程.确定性过程是可明确描述的、可预测的过程,因而可重复〔Repeatable〕执行并能产生预期的结果,并能通过科学理论对其最优化.经验性过程与之相反,应作为一个黑箱〔Black box〕来处理,通过对黑箱的输入输出不断进行度量,在此基础上,结合经验判断对黑箱进行调控,使其不越出设定的边界,从而产生满意的输出.SCRUM方法将传统开发中的分析、设计、实施视为一个黑箱,认为应加强黑箱内部的混沌性,使项目组工作在混沌的边沿,充分发挥人的创造力.总而言之,CMMI和敏捷开发能够很好地相互补充、相互支持.首先在关注点上CMMI关注组织级或企业级改进,关注回答项目应该做什么,而不是具体怎么做的方法,而敏捷开发则更关注项目级改进,关注项目具体怎么做的方法和最佳实践,这使双方在定位方面形成很好的相互补充的态势.一方面CMMI为敏捷提供组织级扩展的能力和必须的组织治理框架,便于组织级对敏捷最佳实践的推广和重用;另一方面,敏捷为CMMI提供了项目级的具体实践方法,确保团队在CMMI框架下能够快速响应,不断创新,持续交付价值.两者的有效结合,能够有效实现个人绩效向团队绩效、向组织绩效的转变过程.同时,也可以通过敏捷实践,规避CMMI实施过程中重文档、重流程的不良倾向,使CMMI实施时更加关注组织的实际价值、关注客户、关注创新.四、 体系总体介绍##软件质量管理体系将项目的生命周期划分为以下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] 撰写。

下载提示
相似文档
正为您匹配相似的精品文档