SPI-第一章备课：软件危机及CMMI
软件危机及CMMI的推出
CMMI(Capability Maturity Model Integration For Software,软件能力成熟度模型集成）是在CMM (Capability Maturity Model For Software,软件能力成熟度模型）的基础上发展而来的。是由美国卡耐基梅隆大学软件工程研究所(Software Engineering Institute,SEI)组织全世界的软件过程改进和软件开发管理方面的专家历时年而开发出来，并在全世界推实施的一种软件能力成熟度评估标准，主要用于指导软件开发过程的改进和进行软件开发能力的评估。
一、软件危机
（一）两个时期的软件概况
1.20世纪60年代中期以前
在计算机系统发展的早期时代（20世纪60年代中期以前），通用硬件相当普遍，软件却是为每个具体应用而专门编写的，那时的软件通常是规模较小的程序，编写者和使用者往往是同一个（或同一组）人。这种个体化的软件环境，使得软件设计通常是在人们头脑中进行的一个隐含的过程，除了程序清单之外，没有其他文档资料保存下来。
2. 20世纪60年代中期到70年中期
计算机系统发展的第二代时期（20世纪60年代中期到70年中期）：这个时期的一个重要特征是出现了“软件作坊”，当时的微软就是这种软件生产方式的一个代表。此时，尽管软件的生产是作坊式生产，但还是生产了一些很有代表性的产品，使得产品软件的使用广泛起来。然而，“软件作坊”仍然沿用早期形成的个体化软件开发方法。随着计算机应用的日益普及，软件数量急剧膨胀。在程序运行时发现的错误必须设法改正；用户有了新的需求时必须相应地修改程序；硬件或操作系统更新时，通常需要修改程序以适应新的环境。上述软件维护工作，以令人吃惊的比例耗费着资源。甚至许多程序的个体化特性使它们最终成为不可维护的。“软件危机”就这样开始出现了！
（二）为什么会出现软件危机
1.为什么会出现“软件危机”呢？
软件不同于一般程序，它是由许多实现各自功能的程序组成的。它的一个显著特点是规模庞大。例如，美国四代宇宙飞船的软件规模呈指数增长，世纪年代末穿梭号宇宙飞船的软件包含4000万行目标代码。假设一个人一年可以开发出一个一万行的程序，为了开发一个4000万行的软件，是
否集中4000人的力量一年就可以完成呢？绝对做不到！
（1）因为如果代码的长度增加了4000倍，代码复杂的程度则会远远超过4000倍。
（2）而且如何保证每个人完成的工作合在一起确实能构成一个高质量的大型软件系统，更是一个极端复杂困难的问题，不仅涉及许多技术问题，例如分析方法、设计方法、形式说明方法、版本控制等，更重要的是必须进行严格而科学的管理。
2.软件本身独有的特点
确软件本身独有的特点实给开发和维护带来一些客观困难，但是人们在开发和使用计算机系统的长期实践中，也确实积累和总结出了许多成功的经验。如果坚持不懈地使用经过实践考验证明是正确的方法，许多困难是完全可以克服的，过去也确实有一些成功的范例。但是，目前相当多的软件专业人员对软件开发和维护还有不少错误观念。在实践过程中或多或少地采用了错误的方法和技术，这可能是使软件问题发展成软件危机的一个主要原因。
3.错误的认识
与软件开发和维护有关的许多错误认识的形成，可以归因于在计算机系统发展中，早期软件开发的个体化特点。错
误认识主要表现为忽视软件需求分析的重要性，认为软件开发就是写程序，并设法使之运行，轻视软件维护等。
4.正确的认识
事实上，对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。只有用户才真正了解他们自己的需要，但是许多用户在开始时并不能准确具体地叙述他们的需要，软件开发人员需要做大量深入细致的调查研究工作，反复多次地和用户交流信息，才能真正全面、准确、具体地了解用户的要求。对问题和目标的正确认识是解决任何问题的前提和出发点。
一个软件从定义、开发、使用和维护，直到最终被废弃，要经历一个漫长的时期。通常把软件经历的这个过程称为生命周期。软件开发最初的工作应是问题定义，然后要进行可行性研究，决定该问题是否存在一个可行的解决办法；接下来应该进行需求分析，也就是深入具体地了解用户的要求，在所要开发的系统（不妨称之为目标系统）必须做什么这个问题上和用户取得完全一致的看法。经过上述软件定义时期的准备工作才能进入开发时期，而在开发时期首先需要对软件进行设计（通常又分为总体设计和详细设计两个阶段），然后才能进入编写程序的阶段，程序编写完之后还必须经过大量的测试工作（所需的工作量通常占软件开发全部工作量
的40%——50%）才能最终交付使用。所以，编写程序只是软件开发过程中的一个阶段，而且在典型的软件开发工程中，编写程序所需的工作量只占软件开发全部工作量的10%~20%。
另一方面还必须认识到程序只是完整的软件产品的一个组成部分，在上述软件生命周期的每个阶段都要得出最终产品的一个或几个组成部分（这些组成部分通常以文档资料的形式存在）。软件专家曾经指出“：软件是程序以及开发、使用和维护程序需要的所有文档。”这也就是对软件的定义。所以，一个软件产品必须由一个完整的配置组成，应该清除只重视程序而忽视软件配置其余成分的错误观念。
做好软件定义时期的工作，是降低软件成本提高软件质量的关键。如果软件开发人员在定义时没有正确全面地理解用户需求，直到测试阶段或软件交付使用后才发现“已完成的”软件不完全符合用户的需要，这时再修改就为时已晚了。
严重的问题是，在软件开发的不同阶段进行修改需要付出的代价是很不相同的，在早期引入变动，涉及的面较小，因而代价也比较低：而在开发中期软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改，不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增。根据美国一些软件公司统计资料，在后期引入一个变动比在早期进入相同变动所需付出的代价高2—3个数量
级。
5.得出的结论
通过上面的论述不难认识到，轻视维护是一个最大的错误。许多软件产品的使用寿命是10年甚至20年，在这样漫长的时期中不仅改正使用过程中发现的每一个潜伏的错误，而且当环境变化时（例如硬件或系统软件更新换代）还必须相应地修改软件以适应新的环境，特别是必须经常改进或扩充原来的软件以满足用户不断变化的需要。所有这些改动都属于维护工作，而且是在软件已经完成之后进行的，因此是极端艰巨复杂的工作，需要花费很大代价。统计数据表明，实际上用于软件维护的费用占软件总费用的55%～57%。二、CMM的提出
（一）软件危机越来越突出
尽管人们在软件工程原理的指导下，对软件项目进行了工程化尽管人们在软件的管理，取得了一定的成效，但令人遗憾的是软件工程的实践令人非常不满意。大量的软件项目不能按照人们的计划实施和完成，持续了二三十年的软件危机变得更加突出。
（二）软件技术的突飞猛进的发展
软件作为一种强有力的工具得到了广泛使用，而且软件技术也取得了突飞猛进的发展。尽管如软件涉及问题的复杂程度增长更快。现在仍然困扰着绝大多数软件机构的问题是：无法开发符合预算和进度要求的高可靠性和可用性软件。软件开发速度和软件维护能力远远赶不上人们对软件要求的增长。
（三）美国国防部着手组织研究软件工程的管理方法
1986年美国国防部开始组织软件工程专家对软件工程的管理方法进行研究，并资助美国卡耐基梅隆大学成立了软件工程研究所（Software Engineering Institute,SEI），改研究所的任务是领导改进软件工程实践的当前状况，并提高以软件为主的系统质量。
经过专家们多年的共同努力，SEI已于1991年，提出的软件能力成熟度模型（CMM）。该模型描述了严格定义的以及能有效测量的软件过程单元的框，其目的是在成本和进度要求条件下提交高质量的软件。CMM为软件机构描述了从混乱的、不成熟的软件过程向成熟的、有纪律的软件过程改进的一条途径。
三、CMMI的推出
（一）CMM的贡献
CMM模型自20世纪80年代末推出，并在20世纪90年代广泛应用于软件过程的改进以来，极大的促进了软件生产率的提高和软件质量的提高，为软件产业的发展和壮大作出了巨大的贡献。
（二）开发学科的类似模型
然而，CMM模型主要用于软件过程的改进，促进软件企业软件能力成熟度的提高，但它对于系统工程、集成化产品和过程开发、供应商管理等领域的过程改进都存在缺陷，因而人们不得不分别开发软件以外其他学科的类似模型。
自从引入基于模型的过程改进之后，工程界至少在三个重要领域已经有了变化。
首先，执行工程的环境已经变得更加复杂。工程量更大，需要更多的人员，需要跨越公司界限，发布范围又宽又广，而且必须继续加快实现的进度，以满足客户的需要。这样导致各种协调工作的大量增加。
其次，执行工程任务的方式已经有了进化。交叉学科群组、并行工程、高度自动化的过程以及多国标准等都影响到工程实践。这样一来，一个工程项目可能要涉及到几个国际
标准。
第三，软件工程研究所的软件能力成熟度模型（CMM）的成功，导致了各种模型的衍生，而每一种模型都探讨了某一特定领域中的过程改进问题。各机构也已采用多种改善模型分别处理各自的关键过程问题。在工程组织中模型的繁衍导致了过程改进目标和技术的冲突，要求的培训工作也随之增长，而且也导致了实践人员在应用各种不同的模型来实现特定的需求时产生混淆。
所有这些变化都表明，有必要将各种过程改进工作集成起来。包含在当代工程中各种各样的学科和过程是密切交叉在一起的。在应用不同模型时，效率低下且容易混淆，常常要付出极其昂贵的代价。因而需要有一种单一的过程改进框架而又能跨越多种学科的工具。软件能力成熟度模型集成（CMMI）就是用来解决这类问题的。
四、CMMI的基本思想
众所周知，CMM的过程改进对于提高软件开发的质量和生产效率是极其有效的手段，并推动了软件产业的发展。开发和应用CMMI的主要原因有三点：一是软件项目的复杂性的快速增长使过程改进的难度增大；二是软件工程的并行与多学科组合；三是实现过程改进的最佳效益。
（一）解决软件项目过程改进难度增大问题
CMM成功实施以后，极大地提高了软件企业的开发效率和软件产品的质量，从而也提高了软件产品的可靠性和软件产业的信誉，这样人们对软件寄予了更大的希望。人们希望软件能够完成更多、更大、更复杂的任务。
众所周知，20世纪60年代，美国曾进行过为期10年的登活动，并最终将人类送上了月球。当时的登月舱是由计算机和软件控制的，但它的软件规模却远远比不上现在电话系统中的软件的规模。这种现象表明，软件的规模正在变得越来越大。据美国国防部估计，在可以预见的将来各种领域的控制系统很快需要2000万行代码的软件。
随着软件系统复杂性的增加，用于开发系统的过程也随之复杂。过程的复杂性不可避免地增加了执行该过程的人员的数量。过程改进的理论和概念是可以理解的，但当将过程应用于日益复杂的系统时，随着软件系统复杂性的增加，导致组织的过程改进活动很容易迷失在任务、日程和繁杂事务中。组织内部的不同的群组及其主管可能争夺过程改进资源。过程组可能选用不同的、有时甚至是相互冲突的过程改进模型。组与组之间可能会进行竞争，也可能激烈争夺过程改进的所有权。最后的结果是导致人们把更多的精力用于过程改进的边缘活动，而不是放在过程改进活动本身。
（二）实现软件工程的并行与多学科组合
CMM模型的成功实践，促进了工程和产品开发的组织发生了巨大的变革，变革的目标主要是为了消除与分段开发有关的低效。在分段开发时，中间产品传给下一阶段的工作人员，有可能要进行大量的返工，以纠正原先的理解错误。并行工程、交叉学科群组、交叉功能群组、集成化产品群组以及集成化产品和过程开发等，都代表了在产品或服务的整个生命周期的合适时间处理这类问题的不同方法。这种倾向意味着设计人员和客户要与制造人员、测试人员和用户共同工作，以支持开发需求的制造组织。这种工作方式蕴含着所有关键的相关人员要支持产品或服务开发的所有阶段。
另外，在工程界实行过程改进时，使交叉学科群组或交叉功能群组的普遍接受与迅速采用是一个棘手的问题。功能部门的概念与交叉学科群组的高度交互工作风格严重抵触，因为每一个功能部门都拥有各自的过程并在各自的控制之下。
实践表明，一个个分离的过程改进模型已经不能有效地支持并行工程这种“混合”环境。如果硬件工程部门采用某种过程改进模型，软件开发人员采用另一种模型，而外界与合同部门采用第三种模型，则不可避免地会产生问题。交叉学科群组采用互不相关的模型很难提供过程改进的机会，因为此时在大多数过程中，每一个成员都是执行者，学科之间
的分离就不会存在了。
相对于经典软件工程严格划分阶段的开发方法来说，交叉学科群组采用集成过程将会与生命周期的涨落匹配得更加紧密。这里需要的不仅是集成学科，而且需要集成过程本身，以便对各个相关人员、功能部门的全体人员和管理部门提供有效的支持。
（三）实现过程改进的最佳效益
尽管过程改进存在复杂化的因素，但软件管理专家们相信，其中的许多障碍可以通过一个集成过程改进的公共模型的办法来克服。这种信念反映了我们在集成方面所进行的工作和CMMI项目的作者和评审人员的经验。人们相信，正如通过CMM的过程改进能够产生显著效益一样，集成过程改进也能产生更大的效益。
从根本上来说，过程改进集成主要影响四个领域：成本、侧重点、过程集成和灵活性。其中某些变化可能比另一些变化容易量化，但所有这些都体现了过程改进集成的真正优势。
1.成本效益
成本改善是人们最容易理解的效益。集成总需要费用，但从过程改进集成所得到的节省是显而易见的。相对采用多
个模型来说，一个组织如果采用了一个单一的模型，则可减少多种费用。
由集成过程改进引发更多的成功机会、较高的质量、更好的可预测性以及其他各种改善过程的效益都节省了过程改进的成本。
2.重点明确
在各种多样的工程组织内部，特别是当项目要跨越组织的界限时，要在某个单个组织中实现真正的过程改进以满足大量的关键需求是困难的。可以认为，这个问题是由于缺乏重点以及需要将全然不同的任务统一起来所造成的。预算发生变更，其商务环境、内部策略以及合并和收购都需要消耗哪些可能用于过程改进的资源。
一个集成过程改进计划可以将组织的各种初始目标和商业目的弄得很清楚。将跨越一大批不同学科的各种过程改进活动集成起来，就比较容易把实践人员和经理人在过程改进的旗帜下重新整顿好。有了一个单一的过程改进重点，就能统一和加强构想，高效地使用匮乏的资源，并为跨越不同学科的过程改进提供一种共同语言。尤其是，一个具有公共术语和公共评估方法的单一模型提供了这类重点。
注意：并不是每一种模型都能够成为过程改进的重点。如果其重点没有包括使组织成功的所有关键学科，则将不能
覆盖在过程改进一个集成化模型允许各个中所需要的广度。一个集成化模型允许各个学科的人们去标识其过程，并感到与有重点的过程改进计划息息相关。
3.过程集成和组织精简
集成过程改进的一个不太明显的效益是其对组织产生的“集成”影响。当跨越组织和学科的边界定义过程时，通常会有新的理解并进行相互教育，从而产生关键工作流的流水线，并消除冗余的或不需要的活动。
4.灵活性与新科学的扩展
由集成所提供的最后一个效益是随着业务或工程环境的变化具有增加学科的能力。如果增加一个单独的模型，往往会产生大量冗余，并通常与公共的过程改进实践的表示相冲突。如果在一个集成计划中增加一个学科，仅仅意味着增加一些过程域，或许还要对另一些过程域作出新的解释，但是其基本的过程改进结构及其术语并没有改变。这样，就便于继承以往过程改进的成果，加快新增过程的改进速度，从而降低过程改进的成本。
cmmi软件生产过程标准
何谓CMM? CMM是由美国卡内基-梅隆大学的软件工程研究所(SEI)推出的评估软件能力与成熟度的一套模型。它侧重于软件过程开发的管理及软件工程能力的改进与评估，是目前国际上最流行、比较实用的一种软件生产过程标准，成为当今企业从事规模软件生产不可缺少的一项内容。CMM模型共分为五个级别：初始级、可重复级、定义级、管理级和优化级。 软件工程：什么是CMMI? CMMI全称是Capability Maturity Model Integration, 即软件能力成熟度模型集成模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。CMMI是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进 CMMI分为五个等级，二十五个过程区域（PA）（如图所示）。 1．初始级软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。 2．已管理级建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。 3．已定义级已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 4．量化管理级分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。5．优化管理级过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。 每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性： 每个等级都有几个过程区域组成，这几个过程域共同形成一种软件过程能力。每个过程域，都有一些特殊目标和通用目标，通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施，就能实现该过程域的目标。 CMMI的原则、目标和方法 一、CMMI的原则： 1．强调高层管理者的支持。过程改进往往也是由高层管理者认识和提出的，大力度的、一致的支持是过程改进的关键。 2．仔细确定改进目标，首先应该对给定时间内的所能完成的改进目标进行正确的估计和定义并制定计划。选择能够达到的目标和能够看到对组织的效益。 3．选择最佳实践，应该基于组织现有的软件活动和过程财富，参考其他标准模型，取其精华去其糟粕，得到新的实践活动模型。 4．过程改进要与组织的商务目标一致，与发展战略紧密结合。 二、CMMI目标:
cmmi软件开发流程
软件开发流程软件项目生命周期模型
需求分析 需求分析流程图 过程描述 1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、 供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方 案。 关于自行开发和采购复用的分析， 如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接 受范围内，可考虑采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 工作量、工期、日程、人数 成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预 算的管理等同于计划工作量的管理。） 质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。
cmmi软件开发流程
c m m i软件开发流程 Prepare d on 24 November 2020
软件开发流程软件项目生命周期模型
需求分析 需求分析流程图 过程描述 1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 ?对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。 ?关于自行开发和采购复用的分析， ?如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用； ?本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购； ?否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 ?工作量、工期、日程、人数 ?成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预算的管理等同于计划工作量的 管理。） ?质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。
cmmi软件开发流程
c m m i软件开发流程 公司内部编号：（GOOD-TMMT-MMUT-UUPTY-UUYY-DTTI-
软件开发流程软件项目生命周期模型
需求分析需求分析流程图
过程描述
1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。 2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事 先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠 性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨 论表决的方法选择并确定最终的技术方案。 关于自行开发和采购复用的分析， 如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、 测试用例等)，一般应进行复用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本 在项目可接受范围内，可考虑采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。
CMMI体系简介及软件工作流程
CMMI体系简介及软件工作流程 质量管理部 2009年03 月 华丽娜主题 第一部分:CMMI基础知识 CMMI是什么 CMMI发展和厉史 CMMI模型组件概述 第二部分:公司质量体系文件综述 公司软件过程概述 公司过程文件概述 公司体系文件导读 CMMI是什么？ ◆Capability Maturity Model Integration(能力成熟度模型综合) 它综合了以下几方面: System engineering Software engineering Integrated Product and Process Development Supplier Sourcing ◆该模型提供一套可供公众使用的准则；这些准则描述那些成功地 实施了过程改进的组织的特性。
◆该模型用“软件能力成熟度”来衡量这种软件综合能力 CMMI是什么？ ?美国卡内塞一梅隆大学软件工程研究所(SEI)研制。 ?CMMI的前身是SW-CMM和SE-CMM ?CMMI有专门认证评估方法一SCAMPI 发展简史 草案于1997年制定(未广泛应用)。 到2000年，CMM演化成为 Software Engineering)于2002年1月正式推出。 CMMI的诞生（1） 版，经历了十多年，在这期间，IT产业有了长足的发展，相应的工 业标准或规范必然要不断地改进。 不再局限于纯粹软件的范崎。虽然人们了解和应用CMMI需要一定的 时间，但走CMMI将取代CMM这走必然的趋势。 CMMI的诞生（2） ◆CMMI为工业界和政府部门提供了一个集成的产品集，其主要目的 是消除不同模型之间的不一致和重复，降低基于模型改善的成本。 CMMI将以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。 CMMI模型组件概述 CMMI分级（阶段）模型 CMMI阶段式模型的结构
汽车电子CMMI软件开发流程
汽车电子软件开发流程 ——CMMI篇 作者:朱忠安 版本: 1.0 状态:草版
1历史记录
2索引 1历史记录 (2) 2索引 (3) 3概要 (4) 4一般嵌入式系统开发简介 (5) 4.1嵌入式系统定义 (5) 4.2嵌入式系统的开发组织架构 (5) 4.3嵌入式系统软件开发流程图 (6) 4.4流程图简介 (7) 5CMMI软件团队解析 (8) 5.1CMMI软件开发流程标准 (8) 5.2软件研发组织架构解析 (9) 5.3软件项目开发过程 (9) 5.4系统测试组织结构 (9) 6CMMI软件项目变更管理 (10) 6.1软件变更控制工具介绍 (10) 6.2软件变更控制流程 (10) 7软件开发知识简介 (11) 7.1软件开发的特点 (11) 7.2如何做好软件开发 (11) 7.2.1客户角度 (11) 7.2.2供应商角度 (11)
3概要 本着为客户服务的宗旨，让更多的想进入汽车研发团队的工程师们了解和熟悉的软件开发流程，减少项目开发过程中不必要的误解，故做此介绍抛砖引玉。
4一般嵌入式系统开发简介 4.1嵌入式系统定义 对于嵌入式系统，一般教科书上面有这样定义：以应用为中心，以计算机技术为基础，软硬件可裁剪，系统对功能、可靠性、成本、体积、耗电量和应用环境，有特殊要求的专用计算机系统，是将应用程序、操作系统和计算机硬件集成在一起的系统。 其实这句话不难理解，概括起来只有两点： <1>计算机系统 任何一个嵌入式系统必定是一个计算机系统,而最基本的计算机系统无外乎CPU,内存,输入设备,输出设备;嵌入式系统也是如此. 谈到这里,就必须要说到两个概念:微处理器和微控制器. 所谓微处理器很容易理解,就是中央处理器CPU,比如所ARM9,它的为处理器就是ARM920T.换句话说就是嵌入式系统的核心控制单元. 所谓微控制器,其实也不难理解;我们现在大部分的电子产品所使用的都是集成芯片,也就是一块芯片中不仅仅包含的是CPU,还把许多的外围设配都集成在一块芯片中,比如把PWM控制器，把flash，把音频处理器，把内存，把输入输出设备等都集成在一块芯片中，这样的一块集成多功能的芯片就是微控制器。基本上一块IC就是一个小型的嵌入式系统。这样的做的好处也是显而易见的：<1>可以减少嵌入式系统设计的复杂度；<2>节省成本,因为一块集成多功能的IC,比你去用一块CPU搭建外围设备的成本要少的多。 <2>特定应用 对于嵌入式产品的开发，一般都是具有特定的应用；根据特定的需求去定制的。比如仪表，一套完整的仪表系统，都是只适合与特定款型的车。因为电子产品的性质各有不同，嵌入式系统的开发也很难有一套统一的标准，没有一个国际标准组织或学术单位，规定嵌入式系统一定要用什么CPU，用什么开发语言，一定要用什么操作系统，一定要用哪一套开发工具。只会根据特定的需求去定制。 4.2嵌入式系统的开发组织架构 一般的研发团队都有很严谨漂亮的组织架构，嵌入式系统的研发团队也是如是；至少应该有以下小组。 <1>项目管理组 <2>硬件组 <3>产品外观和结构设计组 <4>软件组 1）软件项目管理组 2）固件组 3）系统组
CMMI需求开发
成熟度3级的工程过程域 目的 需求开发(Requirements Development, RD)的目的，在于产出并分 析客户、产品及产品组件的需求。 业界注释 本过程域描述客户、产品及产品组件等三种需求，这些需求说明相 关关键人员的需要，包括与产品生命周期各阶段 (如，验收测试准 则)及产品属性 (如，安全性、可靠性、与维护能力等) 有关的需 要。需求也包括选择某设计解决方案而产生的限制条件。例如：与 现成品整合的需求。 所有开发项目都有需求，从项目于维护活动的项目案例来看，产品 或产品组件的变更，是基于现有需求、设计、或实作的变更。需求 变更可能来自顾客或用户所记载的变更请求单，或来自于需求开发 过程的新需求形式。不论需求来源或型式，变更所驱动的维护活动 也要加以管理。 需求是设计的基础，需求的开发包括下列活动： 引导、分析、验证，以及沟通客户的需要、期望及限制，以获 得客户需求，并达成关键人员的共识 搜集和协调关键人员的需要 开发产品的生命周期需求 建立客户需求 建立与客户需求一致的原始产品及产品组件需 因为客户也可能提出特定的设计需求，本过程域讨论所有客户的需 求，而非局限于产品层次的需求。 客户需求可进一步细化为产品及产品组件需求。除客户需求外，选 定的解决方案也可能衍生产品及产品组件需求。整个过程域中，产 品及产品组件的意涵也包括服务及其组件。 在整个产品生命周期中识别并修订需求。对设计决策、后续的纠正 措施，以及产品生命周期各阶段所产生的回馈进行分析，以了解它 们对衍生及已配置需求的影响。 需求开发过程域包括三项特定目标。”开发客户需求」特定目标说 明如何定义完整的客户需求，以使用于产品需求开发。”开发产品 需求」特定目标说明如何定义完整的产品和产品组件需求，以使用 于产品和产品组件设计。”分析并确认需求」特定目标说明客户、 产品及产品组件需求须执行的必要分析，以定义、衍生及了解需求。 第三项特定目标的特定执行方法，用以辅助前两项特定目标的特定
cmmi软件开发流程
cmmi软件开发流程
软件开发流程软件项目生命周期模型
需求分析 需求分析流程图 需求分析 客户 部门经理 临时项目组 输入/输出 EPG QA 测试负责人 PM 开始6、确定项目管理机制 14、协调人员及资源 项目日程表 15、建立工作环境 项目计划书 17、编制项目日程表 5、审批裁剪 16、编制项目计划书 4、申请裁剪 1、组建临时项目组 11、确定项目目 标范围 13、确定项目关键参数 结束 项目裁剪表 2、制定需求阶段日程表 12、项目估算 规模估算表/项目 估算表 3、建立配置库 18、评审项目计划书 19、建立阶段 基线 20、阶段总结 需求分析阶段总 结报告 需求分析阶基线 7、编写需求清单 列表 需求清单列表 10、确认需求规格书 8、确定系统架构/编写需求规格书 架构设计书/需求规格书 9、评审架构设计书/需求规格书 过程描述
1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。 2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 ?对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优 先级，采用讨论表决的方法选择并确定最终的技术方案。 ?关于自行开发和采购复用的分析， 如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复 用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑 采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 ?工作量、工期、日程、人数 ?成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预算的管理等同于计划工作量的管 理。）
cmmi软件开发流程
软件开发流程软件项目生命周期模型 需求分析 需求分析流程图
过程描述 1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。 2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成
项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 ?对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。 ?关于自行开发和采购复用的分析，如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 ?工作量、工期、日程、人数 ?成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预 算的管理等同于计划工作量的管理。） ?质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。 设计 设计流程图
CMMI流程之总结
从CMM软件开发流程的理念、流程这两个方面概括介绍一下CMM。 CMM软件开发流程试图将几十年来风险比较不可控的软件开发用一个规范的流程控制起来，变成一个类似传统工业化生产流程的工业。 CMM理念 CMM主要理念之一就是加强过程控制，认为只要开发的过程按照规定动作执行，就可以很大程度上降低软件开发的质量、进度风险。而过程质量控制的主要手段就是检视。 CMM的理念之二是根据经验数据指导新的软件开发项目。CMM定义了监控软件开发过程 是否规范的一系列指标，如软件生产率、检视缺陷密度、遗留缺陷密度等，并总结了同业的一些经验数据。当执行实际项目时，以这些经验数据指引开发过程，尽量使开发的关键质量指标落入经验数据区间。同时进行进一步分析总结，对质量目标进行修正，用以指导后续的新项目。通过在一个个的项目逐渐总结修正，最终得到一套适合自己的质量目标。 CMM的理念之三，也可以说是本质，是基于传统的瀑布软件开发模型的。 CMM全流程 CMM软件开发规范的流程。CMM规范基于瀑布软件开发模型，没有体现基于原型逐步求 精的思想，这也是近年来在实施中为人所诟病的一个方面。下面结合IPD流程阐述一下CMM 流程在公司实际的应用。 CDP-Charter CDP即Charter开发项目，主要的责任主体是Marketing团队和SE，目标是定义一个产品版本所要解决的主要目标和时间点，交付件是Charter。Charter要通过BMT，即业务管理团队的批准。Charter需要回答这些问题：版本的Top N需求和主要竞争需求，主要目标客户，完整的包需求，版本的里程碑时间点，应用的时间窗口以及在版本火车中所处的位置。 Charter-TR1 TR1即产品概念完成里程碑，主要的责任主体是SE团队，同时Marketing配合完成需求的细化、澄清和修订。这个阶段的目标是输出设计需求。相比包需求，设计需求粒度更细，能够清晰的描述每一个需求，包括每个需求的输入、输出参数，并输出低保真界面原型。 CDCP CDCP即Concept Decision Check Point，近年来大部分项目都裁剪，具体作用不明。 TR1-TR2 TR2即产品设计完成里程碑，主要的责任主体是SE团队。这个阶段的输出是设计规格。相
CMMI3访谈问题列表 for
EPG访谈 1.想问一下你们有专门的过程改进组吗由哪些人员组成 2.关于组织过程改进方面，是否有相关的方针方针是谁写的组织过程定义和组织过程焦点方针分别什么 有相关的方针,这个方针是我们的高层蔡总制订初稿的,我进行了修改，然后提交给蔡总再次审核。审核通过后，这个方针就做为公司进行CMMI三级过程改进的指导思想。 在这个方针里，对于组织过程定义和组织过程焦点的要求是：过程改进工作是有计划，并被跟踪的，且过程改进工作是一个持续进行的。 成立专让的过程改进小组（EPG）负责此项工作，EPG组的主要职责建立并维护组织级标准软件过程，并在全公司推广这套体系。收集项目中应用比较好的过程，做为最佳实践，为组织建立并维护财富库，供以后项目参考。 3.你了解公司目前公司的商业目标吗你是如何将公司商业目标体现在你的过程改进计划或活动中呢 我们能够有效识别客户的业务需求，并提供高质量的客户解决方案，同时秉承服务于客户需求，与客户共同发展的商业理念。 我们在公司进行CMMI过程改进的目的也就是征对公司的这一商业目标，改善软件开发过程，为公司的软件开发提供丰富的模板，并要求项目组按照已定义的过程来执行软件开发过程，提高阶段产品的质量，将问题发现在平时，解决在平时，从而提高产品的质量，提高客户的满意度。 4.你了解公司在过程改进方面投入情况吗具体提供了哪些资源 了解，公司提供的强有力的人力资源，成立了过程改进组。提供了有关CMMI的培训，并准备了很多CMMI的资料供大家学习。（可以扩充）
5.过程改进计划是如何制定的（由谁来审批） 过程改进计划是由我来制定的，我是根据差距分析报告中公司现状与CMMI三级的差距而制定的CMMI过程改进计划，计划主要内容由WBS任务分解，过程改进的成员，组间协调计划，配置管理计划，质量保证计划等等，我组织了一次对《过程改进计划》的评审，这次评审邀请了老总和所有的EPG组成员。评审中我们将发现的问题记录在问题跟踪表中，会后由我来进行修改，然后提交给周总，进行再次审核。 6.过程改进计划是否发生过变更，你是如何来处理的 过程改进计划发生过变更，我们EPG小组对变更的内容修改的增加，并重新对《过程改进计划》进行评审，评审通过后，由配置管理人员提交基线库，发布《基线发布报告》通知所有人员。 7.过程改进计划一般包括哪些方面的内容 过程改进计划里包括培训计划，质量保证计划，配置管理计划，组间协调计划，试点推广计划，过程改进进度表，风险计划，项目的组织架构图等等。 8.你是否清楚项目如何来对组织的标准过程进行裁剪的你们公司有这方面的裁剪规定吗你们裁剪后的结果，是否需要经你们小组来评审 清楚， 项目经理根据项目具体情况，按照组织级裁剪规，邀请项目组，高层，PPQA召开裁剪会议，项目经理将裁剪结果记录《裁剪表》里，并提交给我进行审核。 智多星学习软件项目是中型产品的项目，根据《裁剪规程》的要求，项目计划，项目估计不可以裁剪，角色指定、项目规划、立项会议、规划确定可以合并简化。学生自动化测试平台项目是中型产品的项目，根据《裁剪规程》的要求，项目计划，项目估计不可以裁剪，角色指定、项目规划、立项会议、规划确定可以合并简化。 兆和客户关系管理系统是中型产品的项目，根据《裁剪规程》的要求，项目计划，项目估计不可以裁剪，角色指定、项目规划、立项会议、规划确定可以合并简化。 9.你是否清楚公司未来几年对于过程改进方面的一些目标是什么 是的，公司计划用3年的时间来执行CMMI L3,解决目前存在的软件开发过程中存在的软件开发过程难以控制，产品质量难以保证的问题。 在这三年里，EPG组要根据公司的发现，除了及时的解决过程改进中发生的问题，还要定期的组织体系执行的评审活动，发现弱项与强项，并对弱项进行改进。 10.你作为EPG的代表，你受过哪些方面的培训 我接受过CMMI 17个过程域的培训 11.其他角色或成员是否接受过你们EPG组织的培训 接受过，EPG组在OSSP体系发布后，立即组织了一个连续一个星期对公司所有员工进行了OSSP体系的培训，主要内容是讲解OSSP体系中的所有过程，规程，模板，检查表的使用方法。
CMMI体系文件-OPD-标准软件过程裁剪指南
****信息系统有限公司 标准软件过程裁剪指南 文件编号：版本号： 编制：日期： 审核：日期： 批准：日期：
****信息系统有限公司 标准软件过程裁剪指南 文件编号：版本号： 编制：日期： 审核：日期： 批准：日期：
文件修订记录
目录 1目的........................................... 错误!未定义书签。2适用范围....................................... 错误!未定义书签。3资源和工具..................................... 错误!未定义书签。4定义和缩写..................................... 错误!未定义书签。5职责........................................... 错误!未定义书签。6指南........................................... 错误!未定义书签。 启动条件.................................... 错误!未定义书签。 输入........................................ 错误!未定义书签。 活动........................................ 错误!未定义书签。 确定项目特点............................ 错误!未定义书签。 裁剪要求................................ 错误!未定义书签。 裁剪对象.............................. 错误!未定义书签。 裁剪原则.............................. 错误!未定义书签。 裁剪产物.............................. 错误!未定义书签。 软件生命周期的裁剪指导.................. 错误!未定义书签。 过程裁剪指导............................ 错误!未定义书签。 概要裁剪.............................. 错误!未定义书签。 详细裁剪.............................. 错误!未定义书签。 需求开发与需求管理................ 错误!未定义书签。 技术解决过程...................... 错误!未定义书签。 验证.............................. 错误!未定义书签。 测试........................... 错误!未定义书签。 评审........................... 错误!未定义书签。 项目计划.......................... 错误!未定义书签。 项目监控.......................... 错误!未定义书签。 配置管理.......................... 错误!未定义书签。