全套CMMi软件质量管理体系

XXXXX计算机软件有限公司

XX软件质量管理体系

V1.0

XX软件研发部

2010/12/1

目录

第一篇总则 (5)

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

二、目的 (5)

三、背景介绍 (5)

四、体系总体介绍 (7)

第二篇项目管理 (9)

一、立项管理 (9)

二、结项管理 (19)

三、项目计划 (24)

四、项目监控 (36)

五、风险管理 (44)

六、需求管理 (49)

第三篇技术实现过程 (57)

一、技术预研 (57)

二、SCRUM过程 (61)

三、用户验收 (70)

四、技术评审 (74)

第四篇支撑过程 (82)

一、配置管理 (82)

二、质量保证 (90)

三、培训管理 (99)

四、服务与维护 (106)

第一篇总则

一、《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个控制域。

第二篇项目管理

一、立项管理

立项管理（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所示。

一、立项建议阶段

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

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