CMMI_3级软件过程改进方法与规范

内容提要

软件过程改进是目前IT 企业研发管理的重点与难点。为了提高软件过程能力，企业首先要研制软件过程规范，这是有一定难度并且费时费力的工作。

本书论述的是一套通用的CMMI 3级软件过程改进方法与规范，称为“精简并行过程”（SPP）。SPP 2.0共有19个关键过程域，分为项目管理过程、技术开发过程和支撑过程三大类：

?项目管理过程有7个关键过程域，分别为立项管理、结项管理、项目计划、项

目跟踪、风险管理、外包管理和需求管理。

?技术开发过程有8个关键过程域，分别为需求开发、技术预研、系统设计、实

现与测试、系统测试、用户验收、产品维护和技术评审。

?支撑过程有4个关键过程域，分别为配置管理、质量保证、采购管理和培训管

理。

SPP 2.0文档总数约500余页，包含了众多的过程规范和模板。采用SPP，用户可以在最短的时间内建立适合于本企业的软件过程规范，大大降低用户研制规范的代价和风险。

本书的主要读者对象是IT企业的研发主管、项目经理和软件开发人员，以及即将到企业工作的高校毕业生。

学习了，效果真不错。推荐大家学习。

一、背景介绍

在国内，绝大多数大中型IT企业几乎都面临着“研发管理混乱”的难题。“研发管理混乱”必将导致“产品质量低下”、“进度延误”、“费用超支”等问题。IT企业谋求发展，研发管理必须规范化，这是大中型IT企业的迫切需求。软件过程改进（Software Process Improvement, SPI）是目前国内大中型IT企业研发管理的重点与难点。

CMM（Capability Maturity Model）是用于衡量软件过程能力的事实上的标准，同时也是目前软件过程改进最好的参考标准。CMM是由美国卡内基-梅隆大学（Carnegie-Mellon）软件工程研究所（Software Engineering Institute, SEI）研制的，其发展简史如下：

?CMM 1.0于1991年制定。

?CMM 1.1于1993发布，该版本应用最广泛。

?CMM 2.0草案于1997年制定（未广泛应用）。

?到2000年，CMM演化成为CMMI（Capability Maturity Model Integration），CMM

2.0成为CMMI 1.0的主要组成部分。

?CMMI-SE/SW 1.1（CMMI for System Engineering and Software Engineering）于

2002年1月正式推出。

CMM将软件过程能力分为5个级别，最低为1级，最高为5级。目前国内只有几家IT企业达到了CMM 2级或CMM 3级。鉴于CMM 已经被美国、印度软件业广为采纳，并且取得了卓著成效，近两年来国内兴起了CMM 热潮。CMM受欢迎的程度远远超过了ISO同类标准。

国内IT企业采用CMM的目的大体有两种：

（1）主要想提高企业的软件过程能力，但并不关心CMM评估。

（2）既要提高企业的软件过程能力，又想通过CMM评估来提升企业的威望与知名度。

出于第一种考虑的企业占绝大多数，它们主要是一些中小型IT企业。出于第二种考虑的一般是实力雄厚的大型IT企业。无论是哪类IT企业，它们在实施CMM时遇到的共性问题是“费用高、难度大、见效慢”。

企业做一次比较完整的CMM 2-3级咨询和评估大约要花费60~100万元。然而CMM咨询师只能起到“参谋”的作用，解决实际问题还得靠自己。企业要组建软件工程过程小组（Software Engineering Process Group, SEPG）专门从事CMM研究与推广工作，SEPG 的成本并不比咨询费低。如果企业再购买一些昂贵的软件工程工具（例如Rational的产品），那么总成本会更高。

即使企业舍得花钱，也不意味着就能够容易地提高软件过程能力。目前国内通过CMM 2-3级评估的企业屈指可数，而这些企业的实际能力也没有宣传的那么好。因为参加CMM评估的项目都是精心准备的，个别项目或者事业部通过了CMM评估并不意味着整个企业达到了那个水平，这里面的水分相当大。

曾经有一段时间，IT人士经常争论“CMM好不好”、“值不值得推广CMM”等话题。现在业界关注的焦点则是“企业如何以比较低的代价有效地提高软件过程能力”，攻克这个难题必将产生巨大的经济效益和社会效益，这正是作者致力研究的课题。

二、SPP介绍

一般地，为了真正提高软件过程能力，企业至少要做三件最重要的事情：

?首先制定适合于本企业的软件过程规范。

?对员工们进行培训，指导他们依据规范来开发产品。

?购买一些软件工程和项目管理工具，提高员工们的工作效率。

本书作者根据上述需求，研制了一套“软件过程改进解决方案”（Software Process Improvement Solution, SPIS）。SPIS的主要组成部分有：

?基于CMMI 3级的软件过程改进方法与规范，命名为“精简并行过程”（Simplified

Parallel Process, SPP）。

?基于SPP的一些培训教材，包括软件工程、项目管理、高质量编程等。

?基于Web的项目管理工具，包括项目计划、项目监控、质量管理、配置管理、

需求管理等功能，命名为Future。

SPP是SPIS的方法论，它由众多的过程规范和模板组成。SPP 2.0共有19个关键过程域（如下表所示），基本满足CMMI 3级要求。SPP模型是三层结构（模型请见本书正文），上层是项目管理过程的集合，中层是技术过程的集合，下层是支撑过程的集合。这种模型很直观，高级经理、项目经理、开发人员、质量保证员等人根据SPP模型很容易

知道自己“应该在什么时候做什么事情，以及按照什么规范去做事情”。SPP 2.0文档总数约500余页，本书即根据这些文档改编而成。

SPP 采用CMMI 而不是CMM 作为参考标准，主要原因如下：

CMM的核心是十年前创作的，十年来IT产业有了长足的发展，相应的工业规范必然要不断地改进。在总结CMM应用的大量经验教训的基础之上，SEI推出了CMMI。CMMI重大的改进在于它不仅完善了CMM本身，而且充分考虑了软件工程与系统工程的集成，使得该规范不再局限于软件范畴。由于CMMI 1.1问世不久，人们了解和采用CMMI需要一定的时间，但是CMMI将取代CMM这是必然的趋势。

三、研究经历与出版目的

本书作者对上海贝尔软件工程和项目管理的深入研究为创作SPP 打下了良好的基础。近几年来，上海贝尔平均每年有100个研发项目，研发经费达数亿元。公司约有1500名研发人员，半数以上是软件开发人员。由于公司的研发管理能力不够强，特别是软件过程能力比较薄弱，大量以软件为主的项目开发过程比较混乱，导致新产品的质量问题严重，进度不断地被拖延，直接经济损失近亿元。痛定思痛，在2000年下半年，公司领导决定成立专门小组从事CMM的研究与推广工作。2001年初，林锐博士在网络应用事业部（试点单位）组建了SEPG，共有6名成员。SEPG撰写的规范累计达千页，陆续被公司千余名研发人员使用。SEPG在试点单位的推广力度相当大，仅对规范的培训就超过了600人天。在一年多的研究与实践中，SEPG取得了一些成功，也经历了不少挫折，积累了相当丰富的经验。

在和很多同行专家交流时我们发现，上海贝尔面临的软件工程和项目管理问题在很大程度上代表了国内IT业界面临的共性问题。这是因为：

上海贝尔虽然是合资企业，但是公司各级领导和员工们都是中国人。千余名研发人员接受的是中国的大学教育，他们都以“中国人的方式”开发产品。而软件工程和项目管理无疑是国内大学计算机教育最薄弱的环节，这是因为：（1）大部分学生甚至教师几乎不了解企业，（2）教科书几乎不讲如何解决企业面临的实际问题。所以这种教育模式下产生的大部分研发人员不懂得以规范化的方式开发产品。

上海贝尔的研发项目规模“小至几个人月大至150人年”，项目经费“小至几万元大

至数千万元”。所以国内IT企业面临的各种各样的软件工程和项目管理问题，在上海贝尔几乎都能找到相似之处。

我们曾与国内很多研发人员和各级经理交谈过，大家都对研发管理的混乱局面表示了不满和无奈。尽管“土匪游击队”的开发模式到处可见，但是没有人真的喜欢混乱，大家无不渴望以规范化的方式开发产品。这是现状、是需求、也是希望。

基于上述背景，本书作者及合作者决心创作一套切合国情的通用的“CMMI 3级软件过程改进方法与规范”（即SPP），这是件非常有意义的事情。我们对SPP倾注了热情，一年来草稿写了上千页，仅对SPP模型的修改就达上百次。

SPP 2.0是我们最新的作品，我们自己认为SPP不比RUP（Rational Unified Process）逊色。但是SPP 2.0尚未经过大规模应用，也没有经过权威认证。鉴于SPP的创作者们来自于不同的工作单位（企业和大学），SPP本身不涉及商业或技术机密。我们决定公布SPP 2.0，这样可以让更多的人使用SPP，从而不断完善SPP。

四、软件过程改进心得体会

?要想提高企业的软件过程能力，本质上是靠规范化的企业管理。而管理混乱向来是

中国企业最大的病痛，这是个非常复杂的问题。同时，软件过程改进不是一次性买卖，不能靠“革命”，只能靠持续地改良，不进则退。这些道理实践者一定要明白，并且要有心理准备。

?企业要根据自身实力（人力、物力、财力）和商业目标来改进软件过程能力，不可

为了追求CMMI高级别而过分加重开发人员和管理人员的负担。

?软件开发是如此的灵活，如果没有规范来指导与制约，就容易因无序而导致混乱。

但是规范如果不切实际或者太严密了，就容易畸变成为死板的教条，会扼杀开发人员生机勃勃的创造力。软件过程规范应当力求简单实用。

?要考虑中西方文化的差异。例如CMMI中的质量保证关键过程域并不能容易地在国

内IT企业中实施，因为质量保证员在国内企业中是个非常尴尬的角色。大部分项目经理不仅要管理项目，还要参加技术开发。这些都是不容忽视的国情。

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

价值，但是它对技术开发过程的论述却不够深入。对于大多数软件项目而言，技术开发占总工作量的70％以上，而项目管理占总工作量的30％以下。对大多数企业而言，技术开发过程的规范化比项目管理过程的规范化尤为重要与迫切，这个问题不是单靠CMMI能解决的。所以不要死搬硬套CMMI。

?实施CMMI时要对全员进行培训，不能对职务高的人“网开一面”。我们曾对试点

单位的所有项目经理和软件开发人员作了大量培训，并作了考核，群众基础相当好。

那些高级经理由于事务繁忙，不愿参加培训，导致他们不懂规范，依旧凭感觉指挥。

虽然他们口头上表示支持，但是有时反而起到了带头“破坏规矩”的作用。

?采用一些管理工具，帮助工作人员提高效率，降低负担。选择管理工具不必追求最

先进，简单实用就是“最好”。

五、本书导读

本书的主要读者对象是IT企业的研发主管、项目经理和软件开发人员，以及即将到企业工作的高校毕业生。由于是规范，本书读起来比较枯燥，但是SPP的培训教材如《软件工程与项目管理实践》、《C++/C高质量编程指南》很有趣，两者结合起来阅读效果比较好。

阅读SPP不是目的，把SPP用起来才有价值。建议用户根据自身情况（如商业目标、研发实力等）适当地修改SPP，然后推广使用。

六、致谢

首先感谢上海贝尔有限公司徐智群副总裁（CTO）和网络应用事业部各级领导，在他们的支持下，SEPG拥有了国内一流的研究与实践环境。

SEPG的成员是林锐、阙雪松、朱洪海、文少华、闵勇，外部合作人员是董军、王慧文、谢义军、顾晓刚、彭小澎。大家一起创作了SPP的各个版本。

在一年多的时间里，网络应用事业部的百余名研发人员以很大的热情迎接SEPG的反复折腾，并且欣然接受了哪些冗长乏味的规范，令我们感动之至。

我们与上海贝尔很多研发人员和各级经理有着广泛的交流，他们的建议与鼓励将促使我们不断创作出更好的作品。

对他们表示诚挚的感谢。

目录前言

第一部分综述

第1章软件过程改进与CMM综述

第2章CMMI 3级精简并行软件过程（SPP）综述

第二部分项目管理过程

第2章立项管理

第3章结项管理

第4章项目计划

第5章项目监控

第6章风险管理

第7章外包管理

第8章需求管理

第三部分技术开发过程

第9章需求开发

第10章技术预研

第11章系统设计

第12章实现与测试

第13章系统测试

第14章用户验收

第15章产品维护

第16章技术评审

第四部分支撑过程

第17章配置管理

第18章质量保证

第19章采购管理

第20章培训管理

第五部分文档模板

A.1

A.2

B.1

B.2

个人软件过程改进课程笔记

（SPI：software process improvement） 参考教材： Introduction to personal software process improvement Introduction to team software process improvement 特点： 采集数据:time时间defect缺陷 成绩： 期末60（PSP 英文）实践20 期中12 （TSP 中文四次课学完，第五次课期中考）平时8 实验： 6 8 11 次课及之后 期末： 第九周五一之后 L1 2018.3.6 Lecture 1: 一个体软件过程的定义: 软件工程师的任务：在预期的进度、费用下高质量地开发软件产品（3点） PSP: 控制、管理和改进个人开发工作的自我改进过程 结构化框架：开发表格、指南和规程 PSPi（I—>introduction） 时间管理—>计划过程 缺陷管理—>产品质量

二时间管理 1、时间管理的逻辑原理 ·制定计划，按照计划去做 ·跟踪现在时间使用情况 ·检查时间与计划的准确性，写成文档与实际情况作比较·检查存在的错误 2、了解时间使用情况 将数据保存在合适的地方 3、工程记事本 记录时间使用情况 ·纪录作业、跟踪所承诺的工作、作课堂笔记 ·工作实施方案的凭证 ·保护知识产权 *编号*终止日期每一页编号，前两页作为目录

三时间跟踪 目标：估算完成任务的时间以定义质量目标单位：分钟 工具：标准的时间记录日志 时间记录日志：C completed Unit 数据来源工程记事本 **及时总结记录的时间数据 四阶段计划 1.定义： ?阶段计划短时间的计划 ?产品计划基于活动的计划 二者互相包含 2.阶段计划： 工具：周活动总结表三个子表 数据来源于时间记录日志

CMMI3 过程改进分析报告

过程改进分析报告 XXXXX是一家以软件研发和解决方案销售的信息技术有限公司，公司以互联网技术和基于组件的软件开发技术为核心，为客户提供定制软件开发及维护服务。 公司组建了EPG过程改进小组、品质保证组，并正式启动了基于CMMI的软件过程改进进程。 EPG过程改进小组对公司软件开发过程与公司运营过程的分析和探讨，制定了一套适合于公司实际的组织标准过程定义。 组织标准过程定义选定项目中进行了样本试验，在包括研创中心内推广，取得了一定的成效。 公司按照CMMI3的标准对过程改进管理、并与外部咨询机构签订咨询合同聘请资深咨询顾问通过深入了解公司的过程改进目标及现状，帮助EPG过程改进小组制定相应的实施计划，跟进实施计划及现状提供相应的培训，并在定义或改进过程时提供有力的支持。 在CMMI过程改进之前需求频繁变更没有得到及时的记录，也缺乏对需求变更的分析和管理，导致项目的返工率增加，以至延误项目的进度并造成成本的增加，测试人员不能得到最新的完整的需求，因而造成测试的遗漏，最终引起提交给客户的产品品质低下测试缺陷不是总得到记录（特别是单体测试时的缺陷），导致缺陷遗漏和缺陷数据不准确。功能方面的测试点覆盖不全面，造成测试遗漏，提交给客户后被发现，质量低下客户投诉高、返工率高无法提高生产率，从而导致项目成本不断上升。

公司成立EPG过程改进小组，通过收集外部咨询机构人员、内部评审人员、QA和项目组成员的建议，制定了需求管理、品质管理、项目管理等改进计划： 1、需求管理 EPG过程改进小组制定了需求变更管理过程，在过程中要求使用表格来管理所有的需求变更，包括变更的内容、时间、原因、提出者、状态。使用Q&A来记录与客户的交互信息，这些Q&A 都得到了统一的保存。负责需求的人员在每次变更时要召集所有项目的相关人员，对其进行分析以确定其影响程度和范围，对于超过组织定义的阈值的大变更只有在评审通过后，才可以被纳入系统，对于小变更也要得到记录，整个过程得到QA人员的监察和审核以确保过程得到严格的实施。 2、品质管理 使用“缺陷列表”记录缺陷数据以减少缺陷遗漏，使用“项目度量数据”对缺陷进行分析，在测试结束时对缺陷的准确率进行评审。QA人员也要严格监察此活动改进评审方法，使用同级互查的方式，并在评审中使用“评审检查表”，尽早发现问题。建立测试用例和需求之间的追溯关系，确保所有的需求都被相应的测试用例所覆盖，并加强对测试用例的同级互查以确保充分的测试覆盖率。 3、项目管理 在公司的职责描述中，明确了项目经理需要掌握的管理技能，

软件过程改进与管理

软件过程改进与管理 The pony was revised in January 2021

软件过程改进与C M M I 第一章绪论 本课题研究的背景 21世纪是信息社会高速发展的世纪，软件作为信息技术的核心，将在其中起着至关重要的作用。随着信息经济、网络经济和科学技术的发展，各行各业已经越来越离不开软件的支持，软件产业的发展，各行各业已经越来越离不开软件的支持，软件产业的发展水平已经成为衡量信息技术发展水平的一个重要因素。 自出现软件危机以来，学术界和企业界对软件工程的研究都倾注了大量的人力、物力和财力，多年来也取得了一些成效。但就全世界而言，软件质量问题仍然非常严重，特别对于军方来说，更是一个致命的问题。正因为如此，美国国防部不惜花费重金，委托美国卡内基梅龙软件工程学院(SEI)研究制定软件质量保证规范。1991年，第一个软件保证规范能力成熟度模型(CMM:Capabiliy Maturity Model)制定完成并在美国应用，随后CMM作为一种软件能力成熟度评估标准在全世界推广实施，主要用于指导软件开发过程改进软件管理能力的提高，从而极大地提高了软件项目的控制能力和软件产品的质量，促进了全世界软件产业的健康发展。 CMM的应用虽然得到了很好的成效，但也存在一些缺陷，能力成熟度模型集成(CMMI:Capability Maturity Model Integration)应运而生，它是在CMM基础之上的发展和完善，2002年SEI正式推出CMMI,2005年开始逐步取代CMM. 从我国软件产业的发展现状来看，企业管理软件过程的能力还比较弱，过程混乱使得新技术、新工具的优势难以体现。究其原因，是因为我国的软件过程管理缺乏规范化和标

软件过程改进年度计划模板

XXXX软件项目过程改进年度计划 XXXX企业有限公司 ____年___月___日

文档信息 修改记录

目录 软件过程改进年度计划 (3) 1 引言 (3) 1.1 制定目的 (3) 1.2 项目背景 (3) 1.3 术语定义 (3) 1.4 参考资料 (3) 2 上一年度过程改进总结 (3) 2.1 与计划目标对比 (3) 2.2 工作量 (4) 2.3 过程改进效果 (4) 2.4 经验教训 (4) 3 改进目标 (4) 4 改进范围 (4) 5 角色与职责 (4) 5.1 过程改进领导小组 (4) 5.2 EPG组 (4) 5.3 QA组 (4) 5.4 其它 (4) 6 改进策略 (5) 7 进度计划 (5) 8 人力资源计划 (5)

9 沟通计划 (5) 10 QA计划 (5) 11 里程碑计划 (5) 12 过程改进项目列表 (5)

软件过程改进年度计划 1 引言 1.1 制定目的 说明编写本项目过程文件的目的，指出预期的读者 1.2 项目背景 1、待开发的系统名称 2、任务提出者、开发者、用户及实现系统的计算机中心或网络 3、该系统同其他系统或其他机构的基本的相互关系 1.3 术语定义 本文件中用到的专门术语的定义和外文首字母组词的原词组并解释 1.4 参考资料 1、本项目经核准的计划任务书、合同、上级批文等 2、属于本项目的其他已发表的文件 3、本文件各处引用的文件、资料包括所需用到的软件开发标准等 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些资料的来源 2 上一年度过程改进总结 2.1 与计划目标对比

软件CMMI3过程改进项目计划模板

XXXX软件项目CMMI3过程改进项目计划 XXXX企业有限公司 ____年___月___日

文档信息 修改记录

目录 软件CMMI3过程改进项目计划 (2) 1 引言 (2) 1.1 编写目的 (2) 1.2 背景 (2) 1.3 定义 (2) 1.4 参考资料 (2) 2 项目概述 (2) 2.1 项目目标 (2) 2.2 项目范围 (3) 2.3 客户与最终用户介绍 (3) 2.4 验收标准 (3) 2.5 项目限制和制约 (3) 3 项目组织架构 (3) 3.1 组织架构 (3) 3.2 人员及职责 (3) 4 人力资源计划 (4) 5 沟通计划 (5) 6 风险计划 (5) 7 进度计划 (6) 8 QA计划 (6) 9 配置管理计划 (6)

软件CMMI3过程改进项目计划 1 引言 1.1 编写目的 用于指导，规划整个过程改进过程。 1.2 背景 近年来，CMMI已经在众多软件公司得到成功实施，提高了软件公司的过程能力。鉴于此，公司决定在本公司范围内实施CMMI3级过程改进，旨在提高公司软件开发效率，保证软件研发项目能够有序进行。 1.3 定义 参见《CMMI3过程改进项目词汇表》 1.4 参考资料 《CMMI for Development Version 1.2》 《CMMI 精粹-集成化过程改进实用导论》 2 项目概述 2.1 项目目标 通过CMMI过程改进项目，在本公司建立符合CMMI3级要求的软件研发过程框架，并在本公司所有软件研发项目应用；能够根据组织建立的目标，对过程进行不断完善和改进；最终目的是规范化本公司软件研发过程，从而提高开发效率。

CMMI_3级软件过程改进方法与规范

内容提要 软件过程改进是目前IT 企业研发管理的重点与难点。为了提高软件过程能力，企业首先要研制软件过程规范，这是有一定难度并且费时费力的工作。 本文论述的是一套通用的CMMI 3级软件过程改进方法与规范，称为“精简并行过程”（SPP）。SPP 2.0共有19个关键过程域，分为项目管理过程、技术开发过程和支撑过程三大类： ?项目管理过程有7个关键过程域，分别为立项管理、结项管理、项目计划、项 目跟踪、风险管理、外包管理和需求管理。 ?技术开发过程有8个关键过程域，分别为需求开发、技术预研、系统设计、实 现与测试、系统测试、用户验收、产品维护和技术评审。 ?支撑过程有4个关键过程域，分别为配置管理、质量保证、采购管理和培训管 理。 SPP 2.0文档总数约500余页，包含了众多的过程规范和模板。采用SPP，用户可以在最短的时间内建立适合于本企业的软件过程规范，大大降低用户研制规范的代价和风险。 一、背景介绍 在国内，绝大多数大中型IT企业几乎都面临着“研发管理混乱”的难题。“研发管理混乱”必将导致“产品质量低下”、“进度延误”、“费用超支”等问题。IT企业谋求发展，研发管理必须规范化，这是大中型IT企业的迫切需求。软件过程改进（Software Process Improvement, SPI）是目前国内大中型IT企业研发管理的重点与难点。 CMM（Capability Maturity Model）是用于衡量软件过程能力的事实上的标准，同时也是目前软件过程改进最好的参考标准。CMM是由美国卡内基-梅隆大学（Carnegie-Mellon）软件工程研究所（Software Engineering Institute, SEI）研制的，其发展简史如下： ?CMM 1.0于1991年制定。 ?CMM 1.1于1993发布，该版本应用最广泛。 ?CMM 2.0草案于1997年制定（未广泛应用）。 ?到2000年，CMM演化成为CMMI（Capability Maturity Model Integration），CMM 2.0成为CMMI 1.0的主要组成部分。 ?CMMI-SE/SW 1.1（CMMI for System Engineering and Software Engineering）于 2002年1月正式推出。 CMM将软件过程能力分为5个级别，最低为1级，最高为5级。目前国内只有几家IT企业达到了CMM 2级或CMM 3级。鉴于CMM 已经被美国、印度软件业广为采纳，并且取得了卓著成效，近两年来国内兴起了CMM 热潮。CMM受欢迎的程度远远超过了ISO同类标准。 国内IT企业采用CMM的目的大体有两种： （1）主要想提高企业的软件过程能力，但并不关心CMM评估。

(完整版)CMMI过程改进计划

武汉中地数码科技有限公司 过程改进计划 Version x.x 文档名称：ZD-CMMI-Templates-过程改进计划-YYYYMMDD.doc 武汉中地数码科技有限公司 版权所有不得复制

过程改进计划 修订历史记录 序号日期版本号修改说明修改人评审人批准人 1.2014-4-15 0.1 初次撰写李叶繁王洪涛 2.2014-4-30 1.0 CMMI3级改进计划定稿王洪涛EPG 周顺平 3.2014-7-2 2.0 按公司实际情况，参考咨询师过程改进实施 计划调整结束日期至2015年3月 王洪涛EPG 周顺平 4. 5. 6. 7. 8. 9.

目录 1. 引言 (1) 1.1 文档目的 (1) 1.2 改进背景与总体目标 (1) 1.3 工作原则 (1) 1.4 术语及定义 (2) 1.5 参考文献 (2) 2. 改进目标 (2) 2.1 现状及问题分析 (2) 2.2 商业目标 (3) 2.3 近期目标 (3) 2.4 中长期目标 (4) 3 改进机构与职责 (5) 3.1 组织机构及范围 (5) 3.2 高层管理指导委员会（MSG） (5) 3.2.1 最高管理者 (5) 3.2.2 管理者代表 (6) 3.2.3 高层委员会 (6) 3.3 工程过程组（EPG） (6) 3.3.1 EPG Leader（EPG组长） (6) 3.3.2 EPG成员 (7) 3.4 过程改进顾问 (7) 3.4.1 外部顾问 (7) 3.4.2 内部顾问 (7) 3.5 过程改进项目QA (7)

3.6 工作组（Working Group） (8) 3.6.1 试点项目项目经理 (8) 3.6.2 配置管理员（CMO） (8) 3.6.3 培训专员（OT） (9) 3.7 沟通协调组 (9) 4 进度计划 (9) 5 成功标准及资源需求 (9) 5.1 成功标准 (9) 5.2 资源需求 (10) 6 沟通计划 (10) 6.1 工作例会 (10) 6.2 工作报告 (10) 6.3 工作审计 (10) 7 假设与风险管理 (11) 7.1 取得成功的条件假设 (11) 7.2 阻碍项目成员的风险因素 (11) 8 附录 (11)

软件质量管理体系建设方案

关于软件质量管理体系建设的 方案 参考资料: 《cmmi3级软件过程改进方法与规范》 《ISO9001:2000标准》 修改记录: 作者简介： 软件企业质量经理、高级项目经理，联系方式__qq:317974257 方案说明： 参考了《cmmi3级软件过程改进方法与规范》、《ISO9001:2000标准》。同时参考了业界同行写的相关方案或文章，吸收了他们的优秀见解。

1.引言 (3) 1.1软件质量概述 (3) 1.2公司软件质量现状分析 (3) 1.3软件质量管理的特点 (4) 1.4软件质量责任分配 (6) 2.软件质量管理体系建设总体方案 (6) 2.1进一步推动软件质量管理体系建设的原则 (6) 2.2软件质量管理体系完善需要解决的主要问题 (8) 2.3配置管理—实施软件质量管理的重要步骤 (8) 2.4进一步完善我们的测试管理体系 (10) 2.4.1.软件测试的组织与管理规划 (10) 2.4.2.测试管理体系过程控制 (12) 2.4.2.1测试流程模型 (13) 2.4.2.2测试流程控制 (13) 2.4.2.3测试小结 (15) 2.5软件质量保证（SQA）的实施 (16) 2.5.1.SQA概述 (16) 2.5.1.SQA实施 (16) 2.5.2.SQA与SQC区别与协作 (17) 2.6全面软件质量管理 (18) 2.6.1.全面软件质量管理 (18) 2.6.2.全面软件质量管理的方法---制定质量管理计划 (19) 2.6.3.全面软件质量管理的方法---技术评审 (19) 3.结束语 (19)

1.引言 1.1软件质量概述 随着信息技术的飞速发展，使软件产品应用到社会的各个领域，也造就了软件行业激烈竞争的生存环境，随着软件规模及复杂性急剧加大，软件质量已经成为人们共同关注的焦点。技术是软件企业的生命，而质量则是它的灵魂,软件企业要在竞争中占有一席之地，软件质量保证是第一要素。由此，软件质量的重要性是不言而喻的。 软件质量是指与软件产品满足规定的和隐含的需求的能力有关的特征和特性的总和。通常来说，软件质量应该包含六方面的特性: 功能性、可靠性、易使用性、效率、可维护性、可移植性。 软件质量管理包括：软件质量计划编制、软件质量保证和软件质量控制三个过程域。质量计划就是为了实现质量目标的计划,它主要结合各个公司的质量方针，产品描述以及质量标准和规则通过收益、成本分析和流程设计等工具制定出来实施方略，其内容全面反应用户的要求，为质量小组成员有效工作提供了指南，为项目小组成员以及项目相关人员了解在项目进行中如何实施质量保证和控制提供依据，为确保项目质量得到保障提供坚实的基础。质量保证（Quality Assurance ，QA）的目的是提供一种有效的人员组织形式和管理方法，通过客观地检查和监控“过程质量”与“产品质量”，从而实现持续地改进质量。质量保证是一种有计划的、贯穿于整个产品生命周期的质量管理方法。质量控制是对阶段性的成果进行检测、验证，为质量保证提供参考依据，它是一个PDCA循环过程。 1.2公司软件质量现状分析 公司的软件开发历经多个生产个环节，产生大量的中间产品，每个环节都有可能带来产品质量问题；同时由于软件产品是逻辑体，不具备实体的可见性，因而难以度量，质量也难以把控，因此如何有效地管理软件产品的质量一直是我们面临的挑战。

过程改进计划

过程改进计划 文档版本号：V1.0 文档编号：HOSLIC_OPF_TEMP_SPIP 文档密级：内部公开归属部门/项 目： 研发部 编写人：王宝珠生效日期：2015-09-30 版权信息 本文件涉及之信息，属内蒙古华昕立合科技有限公司所有。 未经内蒙古华昕立合科技有限公司允许，文件中的任何部分都不能以任何形式向第三方散 发。

文档修订记录 版本号修订日期修订人 修订说 明 修订 状态 审核日期审核人批准人 V1.0 2015-09-05 王宝珠正式版 A 2015-09-10 李志宏昭耐 修订状态：A--增加，M--修改，D--删除 日期格式：YYYY-MM-DD

目录 1.引言 (1) 1.1. 编写目的 (1) 1.2. 过程改进背景 (1) 1.3. 缩写定义 (1) 1.4. 现存问题 (1) 1.5. 总体强项 (2) 2.改进目标 (2) 2.1. 指导目标 (2) 2.2. 商业目标 (2) 2.3. 短期目标 (2) 2.4. 长期目标 (2) 3.组织和职责 (3) 3.1. 组织架构 (3) 3.2. 角色职责描述 (3) 3.2.1. MSG (3) 3.2.2. EPG (3) 3.2.3. OQA (4) 3.2.4. 项目经理 (4) 3.2.5. OCM (4) 4.过程改进计划 (4) 5.资源需求 (4) 6.沟通计划 (5) 6.1. 沟通组例会 (5) 6.2. 管理层汇报 (5) 6.3. QA审计 (5) 6.4. 宣传 (5) 7.度量计划 (5) 8.风险控制 (5) 9.对OPD和OPF的裁剪要求 (5)

CMMI 3级软件过程改进方法与规范

C M M I3级软件过程改进方法与规范 软件过程改进是目前IT 企业研发管理的重点与难点。为了提高软件过程能力，企业首先要研制软件过程规范，这是有一定难度并且费时费力的工作。 本书论述的是一套通用的CMMI 3级软件过程改进方法与规范，称为“精简并行过程”（SPP）。SPP 2.0共有19个关键过程域，分为项目管理过程、技术开发过程和支撑过程三大类： ?项目管理过程有7个关键过程域，分别为立项管理、结项管理、项目计划、 项目跟踪、风险管理、外包管理和需求管理。 ?技术开发过程有8个关键过程域，分别为需求开发、技术预研、系统设计、 实现与测试、系统测试、用户验收、产品维护和技术评审。 ?支撑过程有4个关键过程域，分别为配置管理、质量保证、采购管理和培训 管理。 SPP 2.0文档总数约500余页，包含了众多的过程规范和模板。采用SPP，用户可以在最短的时间内建立适合于本企业的软件过程规范，大大降低用户研制规范的代价和风险。 本书的主要读者对象是IT企业的研发主管、项目经理和软件开发人员，以及即将到企业工作的高校毕业生。

前言 一、背景介绍 在国内，绝大多数大中型IT企业几乎都面临着“研发管理混乱”的难题。“研发管理混乱”必将导致“产品质量低下”、“进度延误”、“费用超支”等问题。IT企业谋求发展，研发管理必须规范化，这是大中型IT企业的迫切需求。软件过程改进（Software Process Improvement, SPI）是目前国内大中型IT企业研发管理的重点与难点。 CMM（Capability Maturity Model）是用于衡量软件过程能力的事实上的标准，同时也是目前软件过程改进最好的参考标准。CMM是由美国卡内基-梅隆大学（Carnegie-Mellon）软件工程研究所（Software Engineering Institute, SEI）研制的，其发展简史如下： ?CMM 1.0于1991年制定。 ?CMM 1.1于1993发布，该版本应用最广泛。 ?CMM 2.0草案于1997年制定（未广泛应用）。 ?到2000年，CMM演化成为CMMI（Capability Maturity Model Integration），CMM 2.0成为CMMI 1.0的主要组成部分。 ?CMMI-SE/SW 1.1（CMMI for System Engineering and Software Engineering）于2002年1月正式推出。 CMM将软件过程能力分为5个级别，最低为1级，最高为5级。目前国内只有几家IT企业达到了CMM 2级或CMM 3级。鉴于CMM 已经被美国、印度软件业广为采纳，并且取得了卓著成效，近两年来国内兴起了CMM 热潮。CMM受欢迎的程度远远超过了ISO同类标准。 国内IT企业采用CMM的目的大体有两种： （1）主要想提高企业的软件过程能力，但并不关心CMM评估。 （2）既要提高企业的软件过程能力，又想通过CMM评估来提升企业的威望与知名

软件过程改进与管理

软件过程改进与CMMI 第一章绪论 1.1本课题研究的背景 21世纪是信息社会高速发展的世纪，软件作为信息技术的核心，将在其中起着至关重要的作用。随着信息经济、网络经济和科学技术的发展，各行各业已经越来越离不开软件的支持，软件产业的发展，各行各业已经越来越离不开软件的支持，软件产业的发展水平已经成为衡量信息技术发展水平的一个重要因素。 自出现软件危机以来，学术界和企业界对软件工程的研究都倾注了大量的人力、物力和财力，多年来也取得了一些成效。但就全世界而言，软件质量问题仍然非常严重，特别对于军方来说，更是一个致命的问题。正因为如此，美国国防部不惜花费重金，委托美国卡基梅龙软件工程学院(SEI)研究制定软件质量保证规。1991年，第一个软件保证规能力成熟度模型(CMM:Capabiliy Maturity Model)制定完成并在美国应用，随后CMM作为一种软件能力成熟度评估标准在全世界推广实施，主要用于指导软件开发过程改进软件管理能力的提高，从而极提高了软件项目的控制能力和软件产品的质量，促进了全世界软件产业的健康发展。 CMM的应用虽然得到了很好的成效，但也存在一些缺陷，能力成熟度模型集成(CMMI:Capability Maturity Model Integration)应运而生，它是在CMM基础之上的发展和完善，2002年SEI正式推出CMMI,2005年开始逐步取代CMM. 从我国软件产业的发展现状来看，企业管理软件过程的能力还比较弱，过程混乱使得新技术、新工具的优势难以体现。究其原因，是因为我国的软件过程管理缺乏规化和标准化。于是，越来越多的软件企业开始关注软件过程能力的提高，我们把这种用于提高软件过程能力的实践称为软件过程改进。有人将软件过程改进比喻成“练功”，作为软件企业，只有通过苦练功，加强软件过程改进，才能够参与到国际化的竞争中去。CMM和CMMI是软件过程改进领域的重要成果，也是适用于软件企业质量管理和过程改进的重要标准。近年来，国软件企业也兴起了认证热潮，CMM受欢迎的程度远远超过了ISO同类标准。 中央和地方政府也出台了一些优惠政策支持软件企业的CMM认证:国务院出台了《鼓励软件产业和集成电路产业发展若干政策》，第十七条鼓励软件企业出口型企业通过GB/T19000-ISO9000系列质量保证体系认证和CMM认证的软件出口企业，可向外经贸主管部门申请认证费用资助。 本论文正是在这样的背景下，研究分析了软件过程改进的CMM/CMMI理论，并理论联系实际，以某公司为对象，对软件企业基于CMMI的过程改进实践作了更为深入的研究和分析，以期为国其他软件企业实施软件过程改进、提高软件质量、提高企业管理水平提供思路和借鉴。

开发流程过程改进建议模板

修订历史记录

目录 1概述 (3) 1.1目前遇到的问题 (3) 1.2过程改进基础 (4) 2过程改进建议 (5) 2.1流程化说明 (5) 2.2变更管理 (7) 2.3BUG审核 (7) 3开发注意事项 (8) 3.1团队基本规则 (8) 3.2不能自己引用第三方包 (8) 3.3要注意区分使用单表和服务 (8) 3.4特定代码管理规则 (8) 3.5分支版本的应用 (9) 3.6对前台文件命名规定 (9) 3.7数据库设计规范 (9) 3.8与第三方技术支持规范 (10)

1概述 在经历了商城轻量化改造、专卖店轻量化改造、会员后台轻量化改造以及包括修改BUG在内的其他一系列项目型工作后，我对目前的开发环境及组织过程有了完整的认识，为了更好的完成以后的工作，结合我们组的工作经验及建议，我对开发流程提出过程改进建议。 首先，对项目有一个全面的认识，项目是为创造独特的产品、服务或成果而进行的临时性工作。这是对项目的定义，在我们的工作中，分配下来的任务都可以视为项目，商城轻量化改造是项目，新增智囊团功能是项目，修改一版BUG也是项目（修改BUG 是最简单的项目，因为目标明确、范围界定准确）。项目不分大小，都需要进行规划，都需要标准化的管理，这也是我提出过程改进建议的初衷。 项目的特点有三个：独特性、临时性和不确定性。独特性指每一个项目都是独特的，没有两个项目是相同的，有可能当前项目中某一块具体功能在以前的项目中有重复，这也只能说在项目实现时有一些经验借鉴。临时性指项目要有明确的起点和终点，即项目的时间约束条件，这是项目的重要制约因素，项目必须承诺在指定的时间内完成，而不是随着工作的完成而项目结束，这一点我们的认识不够深刻。项目的不确定性有两点，一是指项目在整个生命周期中会因环境变化、风险移动等因素而产生变化，这类变化成为变更；而是指由于项目的独特性而产生的项目结果认识不完整，这一点常常被忽视，我们在实际开发中，总是希望先把项目设计的足够完整足够详细足够全面，而实际上对绝大多数项目说这是不现实的，对项目的认识就像认识海上的冰山一样，项目经理必须全面认识水上部分，同时预测水下部分，并随着冰山的上浮不断重新认识重新预测，这就是规划项目的常用技术—渐进明细（指在项目进程中，随着信息越来越详细，估算越来越准确，持续改进和细化计划）。 基于以上的认识，得出的结论是：一次性完成项目的成本最低。把我们分派的工作视为项目，项目就要规划、评审、设计、实现，而不是直接上来就编代码。对于规模较大的项目（如商城轻量化改造），我们容易接受这个观点；对于规模小的项目（如添加媒体审核功能），很多时候我们不愿意接受这个观点，而导致多次返工。修改BUG工作，我认为是最简单的项目，因为目标明确，这类项目可以根据具体BUG内容进行适当剪裁。所谓一次性完成，主要指不要让我们的项目因缺少规划、着急开始、认识不全面等原因而导致的多次返工，同时还要认识到，规划、评审、设计是要消耗资源的（我们这里主要指时间），我们要为这些工作预留资源。 1.1目前遇到的问题

软件过程改进：经验和教训

软件过程改进：经验和教训 前言： 2001我开始慢慢关注起软件工程和CMM，也对CMM进行了学习。并且对其中的一些KPA在自己单位中进行了试验。可是一开始这些试验的结果并不令人愉快，甚至遭到了抵制和反对。开发和测试人员认为降低了开发速度和灵活性，加大了工作量，工作流程太烦琐。而质量的提高也不是一时可以反映出来的。于是在进行了2个小项目的试验后，我被迫停止了CMM在公司的实施。 因为公司并不从事外包服务，所以CMM对其没有生存的压力。高层也只是想通过一个可行的过程管理，一个提高软件质量，保证项目进度，有效控制项目成本。所以公司并不是要去过CMM等级，而是要一个有效的过程管理。 所以我此后开始以‘有效、简易、可行、低成本’为标准探索起适合起我们公司的过程改进的最佳实际。现在，我很高兴可以在文中和大家探讨我公司在过程改进过程中的一些经验和教训，也许你会从中得到一些启发，开发出适合你自己的最佳实际。 经验和教训： 在中小型的软件企业当中，软件过程的改进更容易半途而废 中小企业，特别是开发人员小于40个人的企业。一般不会有专门的人员可以组建‘软件过程组’，也很少会有专职的质量工程师和配置工程师。在进行过程改进中，对于这些职位基本上都是由原来的人员兼职完成。这无形中增加了人员的工作量。一旦过程定义的不是太完善，或是在试点中不是太成功。很容易让人去怀疑过程改进本身的可行性。同时中小企业接到的项目也比较小，成本压力是比较大的，而提高质量是必须以牺牲成本为代价的。所以有时从成本的角度出发，可能在高层管理人员的心目中，对于过程改进也是有成本的顾虑的，一方面希望，可以通过过程改进提供质量，并为企业的发展提供基础，另一方面，也面临成本压力，若过程是改进了，可是成本也大幅度提高了，则本事企业的生存就成问题了。 而在大的软件企业，一般可以有专职的人员进行质量保证和过程改进。同时由于大企业拿到的项目一般也比较大，项目组就比较大，客户要求也高。这也为过程改进增加了必要性。 持续的改进很重要，但频繁的改进会不利于过程的执行 CMM中定义了每个KPA的目标和一系列的KP，企业必须根据自己的实际情况去定义实现每个KPA的工作流程。但并不是每个企业都很幸运，在一开始就可以定义一个自己企业的最佳实践。一般的情况是，首先定义一个工作流程，并在一个试点项目中实行，而后对试点项目进行总结，并对此工作流程进行改进。再

软件项目管理方法和工具介绍

软件项目管理方法和工具介绍 1. 为什么需要软件项目管理方法和工具 软件开发和项目管理是软件企业最主要的工作，两者相辅相成，缺一不可。项目管理应当覆盖整个软件开发过程。 软件项目管理的主要工作有：立项与结项、项目规划与监控、风险管理和变更管理、需求管理、质量管理、软件配置管理等。 软件开发的主要过程域有：需求开发、软件设计、软件实现、软件测试、软件发布、客户验收、软件维护等。 由于软件开发和项目管理都是智力型工作，人们很难靠常识和直觉形成和谐的团队工作。如果企业没有统一的项目管理方法和工具，每个人都采用自己的做事方法的话，那么人越多就越乱，形成了“土匪、游击队”的工作方式。阻碍国内IT企业发展的瓶颈问题通常不是技术问题，而是杂乱无章的管理。 项目管理方法和工具对企业的主要贡献是：让所有项目成员有条不紊地开展工作，在预定的时间和成本之内，开发完成质量合格的产品，从而使企业和个人获得预定的利益。 2. 常见软件项目管理方法介绍 2.1 CMM/CMMI 1986年11月，美国联邦政府委托卡内基梅隆大学（Carnegie-Mellon）软件工程研究所（SEI）开发一套用于评估软件承包商能力的方法。SEI于1987年9月发布了一套软件过程成熟度框架和一套成熟度问卷。1991年，SEI将软件过程成熟度框架发展成为软件能力成熟度模型（Capacity Maturity Model，CMM），诞生了CMM 1.0。 十几年来，CMM的改进工作一直不断地进行。美国国防部希望把现在所有的、以及将被开发出来的各种能力成熟度模型，集成到一个框架中去。到2000年，CMM演化成为CMMI（Capability Maturity Model Integration，能力成熟度模型集成）。CMMI不仅适合软件，而且适合于软件硬件结合的系统，这是对CMM最大的改进。 CMM将能力成熟度分为5个级别，这5个成熟度等级为评价机构软件过程能力提供了一个有序的级别。同时也为机构的软件过程改进工作指明了方向，让人们分清轻重缓急，指导人们一步一步地改进过程能力而不是企图跳跃式地前进。 CMM有一个重要的概念是关键过程域（Key Process Area）。关键过程域指出为了达到某个成熟度等级必须要解决的一族问题。除了初始级（即CMM 1级）以外，每个成熟度等级都有若干个关键过程域。

cmmi,3级软件过程改进方法与规范

竭诚为您提供优质文档/双击可除cmmi,3级软件过程改进方法与规范 篇一：cmmi过程改进的两种方法 1、 2、cmmi过程改进的两种方法 阶段表示 为过程改进提供了一个预定义的路线图，即从成熟等级1到成熟度等级5逐渐增加，要达到一成熟度等级，必须满足该等级（及其以下等级）上所有的过程域的目标连续表示支持单个过程域的改进，可理解为一个过程域接着一个过程域实施改进。在每个过程域上能力等级0到能力等级5逐级增加 3、cmmi的全称，软件能力成熟度模型。 4、过程的作用 过程是决定产品成本、进度和质量的主要因素 5、过程改进的生命周期模型-ideal模型 5、cmmi过程改进流程 6、过程改进的目的 7、过程改进的好处

8、过程改进的原则 篇二：cmmi3级软件过程第18章质量保证 第18章质量保证 质量保证（qualityassurance，qa）的目的是提供一种有效的人员组织形式和管理方法，通过客观地检查和监控“过程质量”与“产品质量”，从而实现持续地改进质量。质量保证是一种有计划的、贯穿于整个产品生命周期的质量管理方法。 质量保证过程域是spp模型的重要组成部分。本规范阐述了质量保证过程域的3各主要规程： ☆制定质量保证计划[spp-pRoc-qa-planning]。 ☆过程与产品质量检查[spp-pRoc-qa-ppqc]。 ☆问题跟踪与质量改进[spp-pRoc-qa-tRacking]。 上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。 本规范适用于国内it企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。 18.1介绍 过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品”，而“差的过程”将产生“差

软件过程改进 敏捷软件过程及精益软件开发思想总结

敏捷软件过程及精益软件开发思想总结 敏捷软件开发 敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的新型软件开发方法，是一种能应对快速变化需求的软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。 敏捷软件开发四条原则： ?递增，而不是连续的：如果开发实践是真正的敏捷精神，那么交付的工作软件是一小部分一小部分递增的。不必等到一个阶段完全完成后才开始另一个，工作也不是向大的发布日期而努力。完成的工作，但并不是业务最终期限，驱动着敏捷交付。但敏捷精神也承认业务操纵着最后截止日期。 ?避免不必要的开销：如果实践仍然是真正的敏捷精神，那么团队就致力于尽可能多地减少项目计划和文档。与其讨论要做什么，然后再写下来，不如赶紧动手去做，否则，就是在浪费时间在工作的工作上。在工作对工作中，敏捷精神有利于实际的工——作交付工作软件。而且它也值面对面的交流通过邮件和其他书面文件。 ?协作：根据需求，团队成员一直与其它人进行交互，以及一些外部利益相关者。在敏捷教练世界中，整个团队的负责人能够解决所有问题，在问题出现之前。真正的敏捷精神团队是自助的。他们分配需要做的工作。虽然每个成员承担的任务都在他们的专业技能范围内，他们还是需要与团队协作的。没有人的工作是孤立的，也没有团队本身是独立工作的。没有业务利益相关者，以及诸如用户体验方面的外部专家的重大投入，团队就不可能使项目向前发展， ?说真话：为了保证真正的敏捷，团队探讨的与项目相关的一切都要是真实的。在一些至关重要的专业领域，如冲刺测试的编码技能，他们承认存在差距。关于实际生产力，他们的要讲事实；这也就是说，在y时间内，团队是否有能力做到x。他们承认错误。说真话是一项挑战，因为他们害怕承认缺点会让他们显得很弱。但敏捷精神知道说出事实需要勇气。承认问题需要信心，然后快速地去解决问题。 敏捷软件开发对比分析： 敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。 适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。

软件过程改进与管理

软件过程改进与C M M I 第一章绪论 1.1本课题研究的背景 21世纪是信息社会高速发展的世纪，软件作为信息技术的核心，将在其中起着至关重要的作用。随着信息经济、网络经济和科学技术的发展，各行各业已经越来越离不开软件的支持，软件产业的发展，各行各业已经越来越离不开软件的支持，软件产业的发展水平已经成为衡量信息技术发展水平的一个重要因素。 自出现软件危机以来，学术界和企业界对软件工程的研究都倾注了大量的人力、物力和财力，多年来也取得了一些成效。但就全世界而言，软件质量问题仍然非常严重，特别对于军方来说，更是一个致命的问题。正因为如此，美国国防部不惜花费重金，委托美国卡内基梅龙软件工程学院(SEI)研究制定软件质量保证规范。1991年，第一个软件保证规范能力成熟度模型(CMM:Capabiliy Maturity Model)制定完成并在美国应用，随后CMM作为一种软件能力成熟度评估标准在全世界推广实施，主要用于指导软件开发过程改进软件管理能力的提高，从而极大地提高了软件项目的控制能力和软件产品的质量，促进了全世界软件产业的健康发展。 CMM的应用虽然得到了很好的成效，但也存在一些缺陷，能力成熟度模型集成(CMMI:Capability Maturity Model Integration)应运而生，它是在CMM基础之上的发展和完善，2002年SEI正式推出CMMI,2005年开始逐步取代CMM. 从我国软件产业的发展现状来看，企业管理软件过程的能力还比较弱，过程混乱使得新技术、新工具的优势难以体现。究其原因，是因为我国的软件过程管理缺乏规范化和标准化。于是，越来越多的软件企业开始关注软件过程能力的提高，我们把这种用于提高软件过程能力的实践称为软件过程改进。有人将软件过程改进比喻成“练内功”，作为软件企业，只有通过苦练内功，加强软件过程改进，才能够参与到国际化的竞争中去。CMM和CMMI是软件过程改进领域的重要成果，也是适用于软件企业质量管理和过程改进的重要标准。近年来，国内软件企业也兴起了认证热潮，CMM受欢迎的程度远远超过了ISO同类标准。 中央和地方政府也出台了一些优惠政策支持软件企业的CMM认证:国务院出台了《鼓励软件产业和集成电路产业发展若干政策》，第十七条鼓励软件企业出口型企业通过GB/T19000-ISO9000系列质量保证体系认证和CMM认证的软件出口企业，可向外经贸主管部门申请认证费用资助。 本论文正是在这样的背景下，研究分析了软件过程改进的CMM/CMMI理论，并理论联系实际，以某公司为对象，对软件企业基于CMMI的过程改进实践作了更为深入的研究和分析，以期为国内其他软件企业实施软件过程改进、提高软件质量、提高企业管理水平提供思路和借鉴。 第二章软件过程与软件过程改进 2.1软件过程

过程改进组(EPG)访谈V1.1

EPG and PMO访谈 1.想问一下你们有专门的过程改进组吗？由哪些人员组成？OPF、OPD ：GP 2.4 有专门的改进组，由过程专家和领域专家组成，比如各个管理和工程组代表 2.关于组织过程改进方面，是否有相关的方针？方针是谁写的？组织过程定义和组织过程焦点方 针分别什么？ OPF、OPD ： GP2.1 有相关的方针，是由高层经理写的。组织过程定义的方针是：要建立和维护组织的过程资产，包括过程定义，文档库，数据库，生命周期模型和剪裁指南等 组织过程焦点的方针是：要识别过程改进的需求，并计划和实现对过程的改进活动。 3.你了解公司目前公司的商业目标吗？你是如何将公司商业目标体现在你的过程改进计划或活 动中呢？OPF、OPD ： GP2.2 了解，通过分析影响商业目标实现的过程因素，并对其进行评估，发现弱项，计划和实施改进。 4.你了解公司在过程改进方面投入情况吗？具体提供了哪些资源？ OPF、OPD ： GP2.3 了解，公司有相关的预算，并投入了一些专职和兼职的人员做这些事情，还会提供培训。 5.过程改进计划是如何制定的？（由谁来审批）OPF SP2.1、SP2.2 将过程弱项和改进目标做为输入，由EPG组长担当制定，他会协调各方面的意见来完成，最后由高层经理审批。 6.过程改进计划是否发生过变更，你是如何来处理的？OPF SP2.1 ； GP2.2、 GP2.10 发生过变更，我们对变更进行控制，并对计划进行版本管理。 7.过程改进计划一般包括哪些方面的内容？OPF SP2.1 ； GP2.2、 GP2.10 过程改进的目标，资源，体制，任务，日程，风险等。 8.你是否清楚项目如何来对组织的标准过程进行裁剪的？你们公司有这方面的裁剪规定吗？你 们裁剪后的结果，是否需要经你们小组来评审？IP M SP1.1、SP1.2 知道，有剪裁的指南和对项目剪裁过程的规定。需要我们的评审和批准。 1

成功实施软件过程改进的三个要素

成功实施软件过程改进的三个要素 2007-10-15网友评论0 条点击进入论坛 摘要：ISO9000、CMM和CMMI在国内软件企业已经实施了相当一段时间，目前实施后的软件公司CMM/CMMI等级都上去了，可是效果却各不相同。本文从软件过程改进整个过程来探讨成功实施软件过程改进要注意的方方面面，如何才能够让软件过程改进取得最佳效果。 关键字：软件过程改进，CMM，CMMI 1 引言： 软件开发是一种组织良好、管理严格、各类人员协调配合、共同完成的工程项目。软件开发的核心资源是人，这与那些自动化生产线主要靠机器来工作不同，软件开发有太多的可变因素，因此对软件开发的管理应该也是具有一定的柔性，以适合不断变化的开发过程。 软件过程是生产软件的一系列流程，是为了获取所需要的软件产品而需要完成的一系列有关软件工程的活动。他一方面与软件生命周期、软件开发方法和工具、软件开发人员等诸多方面都有着密切联系，另一方面被软件公司的传统习惯、文化氛围和企业领导人的领导风格所影响。 软件过程并不是一个单一体，他是由一个主过程和若干辅助过程共同构成。一般的主过程就是软件开发必须经过的一些过程，称为开发过程。此过程中的任何一个环节都不可缺少，如最传统的瀑布模型中的软件开发过程为：需求分析、总体设计、详细设计、编码、测试、部署和维护。辅助过程则一般指软件开发中的配制管理、文档管理、质量保证、项目管理等过程。虽然软件开发只需要开发过程就能开发出软件，但是缺少辅助过程则会让整个开发过程变得混乱，甚至失去控制，因此辅助过程也是软件过程改进中的重要内容。 2 软件过程改进概述 软件过程改进(Software Process improvement，SPI)帮助软件企业对其软件过程的改进进行计划、过程诊断、过程改进方案制定以及实施。他的实施对象就是软件企业的软件过程，也就是软件产品的生产过程，当然也包括配制管理、软件维护之类的辅助过程，而对于其他的过程并不关注。 在软件企业，软件开发是企业最重要、最复杂的过程。软件产品是软件企业的生命，对软件企业进行流程优化和改进，最主要的还是对其软件过程进行改进。一个软件企业的消耗与收益都在软件产品上，开发过程失败则会给企业带来致命的打击，开发成功则能给企业带来大量的收入，如何降低开发成本，多、快、好、省的开发出所需要的软件是企业立足于市场的根本。 当一个软件企业一步步成长的时候，会发现原来的开发方法、管理模式开始不适应目前的开发。需要开发的软件越来越大、越来越复杂，而不断的增加人手对开发的进度的帮助越来越小。由于开发人员数量越多，沟通成本就越高，使得总体开发效率反而下降，因此需要在管理方面进行提高、在流程上进行优化，才能够提高开发效率、缩短开发周期、降低开发