CMMI 软件工程

1、第一章第一章 软件工程基础软件工程基础张张 可可 电子科技大学电子科技大学1本课程预备知识学习过软件开发相关基础知识学习过软件开发相关基础知识至少一门高级程序语言（如至少一门高级程序语言（如C+、C#）学习过UML系统分析与设计相关课程较为熟悉.NET/Java开发平台和工具学习过数据库设计，例如 SQL Server或Oracle简介本课程将以CMMI1.3 /CMMI1.2版本相关过程管理思路为基础，提炼出CMMI中各过程域（简称PA）的精髓，结合当前国内企业实际开发需求及CMMI推行情况，对CMMI及软件工程相关理论、思想、实践进行介绍 。以CMMI中的工程过程、项目管理、支撑过程、过程

2、管理四大领域中的相关PA为知识点，以国内企业实际使用的模式来编写，考虑到学生的实际接受能力，每个领域中均提供了简化后并能充分体现CMMI精髓的模板及表单。课程内容第一部分第一部分 授课环节授课环节第1章 软件工程基础 第2章 案例机构设置及岗位职责 第3章 立项管理 第4章 项目评审管理 第5章 项目初步计划 第6章 需求开发及管理 第7章 风险管理项目第8章 估算及详细计划第9章 项目跟踪及控制 第10章 系统设计第11章 软件配置管理第12章 产品及过程质量保证 第13章 软件测试简介 第14章 系统实现与测试过程 第15章 制订测试方案及编写测试用例 第16章 系统测试第17章 项目总结

3、第二部分第二部分 项目实训环节项目实训环节 各章节内容（续）第一章 软件工程基础中国软件企业生命周期模型软件工程基本原理 质量管理体系ISO9001 项目管理知识体系PMBOK 软件能力成熟度模型集成CMMI 软件过程管理标准化国内动态 中国软件企业发展趋势图7到达A点的条件产品定位准确有高效创业团队低的资金投入8到达B点时的表现内部管理瓶颈创业团队的决策问题有限空间内的市场竞争加剧9发展时间到达A点：一两年即可，可以叫创业期A-B点：3、5年，企业在B点很容易死掉，老板可能还不知道是怎么死的B点时重点解决的是内部管理问题，包括决策的流程化。10第一章 软件工程基础中国软件企业生命周期模型软件

4、工程基本原理 质量管理体系ISO9001 项目管理知识体系PMBOK 软件能力成熟度模型集成CMMI 软件过程管理标准化国内动态 软件开发中存在的问题硬件的发展一直超过软件，难以发挥硬件的所有潜能建造新程序的能力远远不能满足人们对新程序的需求，同时开发速度不能满足商业和市场的要求计算机的普遍使用对可靠性要求越来越高，如果软件出错，会造成巨大的经济损失，甚至可能给人类带来灾难拙劣的设计和资源的缺乏使得我们难以支持和增强已有软件12为什么？为什么需要那么长时间才能结束开发？为什么成本如此之高？为什么我们不能在把软件交给客户之前就发现所有的错误？为什么在软件开发过程中难以度量其进展？从软件企业生命周

5、期模型来看，这些为什么能否解决好，关系到一个企业生命的长短。13软件的特征软件是由开发而形成的，而不是传统意义上的制造产生的。软件不会“磨损”。大多数软件是自定的，而不是通过已有的构件组装而来的。“更快、更好、更便宜”1968年北约科技委员会(NATO)在联邦德国Garmisch提出“软件工程”这个术语。著名的软件工程专家波汉姆（Boehm）总结了多年开发软件的经验，于1983年在一篇论文中提出了软件工程的7条基本原理。7条原理是确保软件产品质量和开发效率的原理的最小集合。人们虽然不能用数学方法严格证明它们是一个完备的集合，但是，事实证明在此之前已经提出的100多条软件工程原理都可以由这7条原

6、理的适当组合所蕴含或派生所得到。软件工程软件工程7条基本原理条基本原理 1、按照软件生命周期的阶段划分制定计划，严格依据计划进行管理2、坚持进行阶段评审3、实行严格的产品控制4、采用现代程序设计技术5、结果应能清楚地审查6、开发小组的人员应该少而精7、承认不断改进软件工程实践的必要性软件过程概念：当开发产品或构建系统时，遵循一系列可预测的步骤（即路线图）是非常重要的，它有助于及时交付高质量的产品。软件开发中所遵循的路线图就称为“软件过程”。人员：软件工程师及其管理人员根据需要调整开发过程，并遵循该过程。除此之外，软件的需求方也需要参与过程的定义、建立和测试。重要性：软件过程提高了软件工程活动的

7、稳定性、可控性和有组织性，如果没有过程约束，软件活动将失控并变得混乱。但是，现代软件工程方法必须是“灵活的”也就是要求软件工程活动、控制以及文档的编制适合于项目团队和要开发的产品。软件过程（续）步骤：采用的过程依赖于所构造软件的特点。工作产品：从软件工程师的观点来看，工作产品就是过程定义的一系列活动和任务的结果，即程序、文档和数据。质量保证措施：有大量的软件过程评估机制，开发机构可以评估其软件过程的“成熟度”。然而，评价所采用过程的有效性，最好的指标还是所构建产品的质量、适时性和长期生存能力。CMMCapability Maturity Model，能力成熟度模型；，能力成熟度模型；CMMIC

8、apability Maturity Model Integration，能力成熟度模型集成；，能力成熟度模型集成；PMProject management，项目管理；项目管理；PMBOK（A Guide to the Project Management Body Of Knowledge项目管理知识体系指南项目管理知识体系指南) 三种产品质量管理的标准体系三种产品质量管理的标准体系第一章 软件工程基础中国软件企业生命周期模型软件工程基本原理 质量管理体系ISO9001 项目管理知识体系PMBOK 软件能力成熟度模型集成CMMI 软件过程管理标准化国内动态 ISO9001简介简介ISO900

9、1规定了企业质量管理体系的基本要求，它是通用的，适用于所有行业或经济领域，不论其提供何种类别的产品。ISO9001质量管理8原则以顾客为中心高层管理者推动全员参与采用过程方法系统的管理持续改进基于事实的决策互利的供方关系建立和实施质量管理体系的步骤：确定顾客的需求和期望；建立企业的质量方针和质量目标；确定实现质量目标所必需的过程和职责；对每个过程实现质量目标的有效性确定测量方法；通过测量，确定每个过程的现行有效性；确定防止不合格项并消除产生原因的措施；寻找提高过程有效性和效率的机会；确定并优先考虑那些能提供最佳结果的改进；为实施已确定的改进，对战略、过程和资源进行策划；实施改进计划；监控改进效

10、果；对照预期效果，评价实际结果；评审改进活动，确定必要的纠正、跟踪措施。ISO9001简介（续）简介（续）过程方法任何“得到输入并将其转化为输出”的序列活动均可视为过程。为使组织有效运行，必须识别和管理许多内部相互联系的过程。通常，一个过程的输出将直接形成下一个过程的输入。系统识别和管理组织内所使用的过程，特别是这些过程之间的相互作用，称为“过程方法”。ISO9001标准鼓励采用过程方法建立和实施质量管理体系。ISO9001简介（续）简介（续）质量体系文件的分层结构质量手册质量手册：质量体系文件中的纲领性文件。阐明公司质量方针、质量目标和质量策略；描述影响和参与质量活动的部门、岗位职责、权限和

11、相互关系，同时概要描述了质量体系的主体文件即程序文件（规程）。程序文件程序文件：质量手册的支持性文件，具体描述质量活动各个过程、子过程以及各阶段中所采取的措施和必需遵循的流程。规范和指导书规范和指导书：结合公司的具体情况而颁布的各类技术规范、工作条例及其配套考核细则。表单模板表单模板：包括质量记录模板、文档模板等。某IT企业的质量体系示例第一章 软件工程基础中国软件企业生命周期模型软件工程基本原理 质量管理体系ISO9001 项目管理知识体系PMBOK 软件能力成熟度模型集成CMMI 软件过程管理标准化国内动态 项目基本属性整体性，是一系列活动的有序组合。唯一性，每个项目均是具体的、特殊的，没

12、有二个完全相同的项目。一次性，目标一旦完成，项目即告结束。目标性，一个项目有确定的成果性目标。多约束性，在多种约束条件下完成项目的成果性目标，约束包括时间、资源、质量以及其他非技术性约束。依赖性，项目活动的进行涉及多个方面的因素，有对内部各级各部门的依赖，有对用户条件的依赖，有对标准的依赖和对各类变更的依赖等等。冲突性，项目内部会有多种冲突，需要沟通、协调和培训。周期性，项目不同，但都有其基本的生命周期属性，都会经历大体相同的阶段。项目参数范围进度资源成本质量项目生命周期定义立项管理、需求管理策划项目策划实施软件设计、编码、测试收尾发布、提交、运行维护、技术支持和产品退役项目管理基本过程启动过

13、程策划过程执行过程控制过程结束过程项目管理领域项目整体管理项目整体管理项目计划制订项目计划实施整体变更控制项目范围管理项目范围管理启动范围计划编制范围定义范围核定范围变更控制项目管理领域（续）项目时间管理项目时间管理活动定义活动排序历时估算进度计划编制进度计划控制项目成本管理项目成本管理资源计划编制费用估算费用预算费用控制项目管理领域（续）项目质量管理项目质量管理质量计划编制质量保证质量控制项目人力资源管理项目人力资源管理组织的计划编制人员获取班子组建项目管理领域（续）项目沟通管理项目沟通管理沟通计划编制信息发布绩效报告管理收尾项目风险管理项目风险管理风险识别风险量化定性风险分析定量风险分析风

14、险应对计划编制风险监控项目管理领域（续）项目采购管理项目采购管理采购计划编制询价计划编制询价供方选择合同管理合同收尾第一章 软件工程基础中国软件企业生命周期模型软件工程基本原理 质量管理体系ISO9001 项目管理知识体系PMBOK 软件能力成熟度模型集成CMMI 软件过程管理标准化国内动态 什么叫CMM/CMMI？软件能力成熟度模型的英文全名是Capability Maturity Model for Software，缩写为SW_CMM，简称CMM；1993年推出第一版v1.1。CMMI（Capability Maturity Model Integration）是一套包括多个学科、可扩充

15、的模型系列，其前身主要包括4个成熟度模型（称CMMI的源模型），它们分别是：面向软件开发的SW-CMM、面向系统工程的SE-CMM、面向产品集成的IPD-CMM以及涉及外购协作的SS-CMM；2000年推出第一版，最新的是2010年的1.3版本。37CMMI历史历史CMMI发展历史图（发展历史图（v1.2） CMM for SoftwareV1.1(1993)INCOSE SECAM(1996)Systems Engineering CMM V1.1(1995)CMMI Software V2draft C(2007)EIA 731 SECM(1998)Integrated Product D

16、evelopment (1997)CMM for Acquisition V1.1(2007)CMMI for Services V1.2(2007)V1.02(2000)V1.1(2002)CMMI for DevelopmentV1.2(2006)CMMI和过程改进 启动（Initiating） 诊断（Diagnosing）建立（Establishing）行动（Acting）推进（Leveraging）激励改进设定改进范围提出改进倡议设立实施改进的组织机构和岗位职责描述并评价当前的过程实践提出改进建议并将阶段性结果形成文档设定改进策略和优先排序建立过程改进行动小组策划改进活动策划与执行指南

17、计划、执行和跟踪定义过程和度量修订机构一级的相关规定分析经验教训并形成文档CMMI结构框架 模型的全部描述就是按过程域作为基本构件而展开的，针对每个过程域分别规定了应达到什么目标（目标（Goals）以及为了达到这些目标应该做些什么“实践实践”（Practices），但模型并不规定这些实践由谁做、如何做等等。 在V1.2/V1.3版本中，共计22个过程域（PA）P.S. 1.2与1.3的区别，取消了IPPD条款，机构改进与部署OID过程域改进为机构性能管理OPMCMMI的结构图41从机构和项目组、项目管理、过程管理三个方面加以从机构和项目组、项目管理、过程管理三个方面加以考察，则可以将上列考察，

18、则可以将上列22个过程域分成如下四大类：个过程域分成如下四大类： 过程域之间的主要关系表过程域之间的主要关系表 CMMI分级初探通过一个“吃饭”的例子，让大家感受CMMI 1级到5级。你会如何组织这个的活动？某个时间，公司进行聚餐活动。请你组织这次活动，目的是用合理的经费让大家高高兴兴地吃一顿！两人一组讨论，5分钟时间。请各位讲解用CMMI1-5级如何管理？第1级：初始级第2级：可重复级/受管理级第3级：已定义级第4级：定量管理级第5级：持续优化级Level 1：初始级不用做什么计划，只提前一点点去订座位当天下班大家一哄而去现场点菜，然后大吃一顿这样做会有什么结果？定不到位？菜不合大家口味？经

19、费超出？大家心情变得很沮丧？有没有可能取得比较好效果呢？Level2:受管理级-1怎样才能办好事情呢？大家想吃什么？老板有什么期望呢？预算是多少呢？要做个计划才行？酒水需要另外买啊！要督促大家按照计划进行？要统计一下出席情况以及各菜式的“吃剩”情况！需求管理需求管理(RM)项目计划项目计划(PP)项目计划跟踪项目计划跟踪(PMC)采购采购(SAM)度量度量(MA)Level2:受管理级-2就这样够了吗？菜式统计、买酒的协议、计划等文档要统一管理起来。老板对我不放心，还派个人来监督我工作！哼！配置管理配置管理(CM)质量保证质量保证(PPQA)这样做会有什么结果？大家吃得满意？预算控制得好？老板

20、高兴？真的能这样吗？2级做法遗留的一些问题不需要进行风险管理吗？用什么方法调查大家喜欢吃什么菜式呢？有指南就好了？如何组织聚餐活动，是不是应该有个指导？或者有成功经验可供参考？Level 3：已定义级经过一段时间积累，以下活动都有明确的指导文档：如何写计划如何组织吃饭现场活动如何确定餐单.对于确定餐单、选定酒水供应商方面采用决策分析的办法。进行风险管理。建立了相应的培训制度。另外，为了让组织聚餐活动越做越好，成立了专门的SEPG（软件工程过程小组）来维护文档。RD TS VER VAL PIIPM DARRSKMOTOPF OPD这样做会有什么结果？这次活动成功的几率大大提高了？但谁能拍胸口说

21、：一定能成功？3级遗留的问题感觉成功机会会提高很多，但没有一个底？最好有个数字能说明问题。Level 4：定量管理级积累了大量聚餐活动的CPI、SPI数据。积累了大量的聚餐满意度数据。当前反应聚餐活动能力的数据CPI、SPI、满意度等在一定范围内波动。根据当前CPI、SPI，可预测聚餐活动的最终成本。通过这些数据对活动进行监控。CPI成本绩效指数SPI进度绩效指数Level 4 的特点根据历史数据，算出了性能基线、性能模型。聚餐活动进行时，利用性能基线、性能模型进行定量管理。组织过程性能(OPP)定量项目管理(QPM)这样做会有什么结果？聚餐活动进展情况了如指掌比较准确的估计到最后的结果成功的

22、几率极大提高Level 4的遐想哇！Level4已经很厉害了！更厉害的Level5会是怎样呢？请猜？Level 5：持续优化级如何持续改进？原因分析采用新技术公司定下新的目标Level 5 之 原因分析通过数据，我们发现由A君组织聚餐活动时，满意度总能在基线范围内。但由B君组织时，满意度异常的高，超出了基线上限。于是我们进行原因分析，发现B君进行抽奖活动之前，做了一个调查，知道每个人最想要什么。故抽奖活动做得很出色，满意度就高了。Level 5 之 原因分析抽奖活动前先进行调查这个工作，在过程文档里面并没有规定的，是B君的特殊做法。SEPG异常高兴，把B君的做法写入过程中。于是全部人都按照这个

23、做法去做了，结果满意度性能基线上升了。Level 5 之 原因分析对一些特殊问题、特殊情况进行分析，可以得到改进过程的机会。对过程进行改进后，我们的性能会提高。Level 5 之 采用新技术 出现了这样的一些问题：发现难以统计到场的人员，需要经常去问。很多人不知道如何去聚餐地点。为了解决这个问题，采取以下新技术：每人配一台带有GPS的IPad，里面有地图活动组织者用IPad能见到各位位置。Level 5 之 采用新技术采用新技术后，大家准时出席率提高，并且满意度也提高。Level 5 之 公司定下新的目标预算的偏差率当前值是-20%到20%，老板觉得不满意，要求改进为-10%到10%。SEPG

24、就非常紧张了，投入大量人力物力分析如何改进。SEPG发现导致预算偏差大的地方主要在于酒水采购方面，供应商的价钱浮动太厉害。Level 5 之 公司定下新的目标SEPG定下改进计划，修改了采购方面的过程，对供应商的选择加强了标准。在某次聚餐中试行新的采购过程，结果发现成本偏差果然控制在-10%到10%范围内。分析试行结果后，SEPG把过程正式推行，最终满足了老板的要求。Level 5的两个PA原因分析(CAR)组织革新与部署(OID)技术改进公司定下新目标CMMI的级别一级，初始级（一级，初始级（Initial）：）：在初始级，企业不具备稳定的软件开发与维护环境。 项目成功与否在很大程度上取决于

25、是否有杰出的项目经理和经验丰富的开发团队。项目经常超出预算和不能按期完成，企业软件过程能力不可预测。 此级不评估二级，可重复级二级，可重复级(Repeatable)/受管理级受管理级: 在可重复级，企业建立了管理软件项目的方针以及为贯彻执行这些方针的措施。企业基于同类项目的经验对新项目进行策划和管理。企业的软件过程能力可描述为有纪律的，并且项目开发过程处于项目管理体系的有效控制之下。 三级，已定义级（三级，已定义级（Defined）：）：在已定义级，企业形成了管理软件开发和维护活动的机构标准软件过程，包括软件工程过程和软件管理过程。项目组可以依据机构的标准，定义项目的软件过程并进行管理和控制。

26、企业的软件过程能力可描述为标准的和一致的，过程是稳定的和可重复的，并且高度可视。72CMMI的级别（续）四级，受管理级（四级，受管理级（Managed）/定量管理级：定量管理级：在已管理级，企业对软件产品和过程都设置定量的质量目标。通过把过程性能的变化限制在可接受的范围内，从而实现对产品和过程的控制。企业的软件过程能力可描述为可预测的，软件产品具有可预期的高质量。 五级，持续优化级（五级，持续优化级（Optimizing）：）：在优化级，企业通过预防缺陷、技术创新和改进过程等多种方式，不断提高项目的过程性能以持续改善企业软件过程能力。企业的软件过程能力可描述为持续改进的。73第一章 软件工程基

27、础中国软件企业生命周期模型软件工程基本原理 质量管理体系ISO9001 项目管理知识体系PMBOK 软件能力成熟度模型集成CMMI 软件过程管理标准化国内动态 软件过程管理标准化国内动态软件过程管理标准化国内动态 信息产业部科技司于2000年9月主持成立了软件体系评估标准特别工作组 提出了“依据我国软件政策，利用国际先进经验，结合我国国情，制定出有助于指导和促进我国软件企业发展的评估模型标准”的原则 深入研究了CMM、CMMI、ISO/IEC TR 15504、ISO 9000-3以及其他有关的资料和文件，结合国情，确定了以CMMI作为主要参考文件来制定标准 ，中华人民共和国电子行业标准（SJ

28、/T 11235-2001）软件能力成熟度模型，中华人民共和国电子行业标准（SJ/T 11234-2001）软件过程能力评估模型 ，但当前推行效果不是很好。讨论讨论1 软件质量软件质量7个致命问题个致命问题对产品满足用户需求不进行系统策划，只靠对员工的命令式管理。关注短期进度，担心项目被取消或裁员。绩效考核，年度评审。软件工程师和经理的流动性。单纯依据可见的数字管理。过高的开发阶段的人力成本。过高的维护成本。76讨论讨论2 软件质量软件质量15个障碍个障碍希望有一个快速见效的解决方案。相信新的硬件、工具和方法会改变开发过程。“我们的问题很特殊” 。落后的教育，仅仅热衷于技术，不进行质量教育。糟

29、糕的统计方法教育。“已经可以了，没有时间做得更好”。由质量控制人员解决所有质量问题。（质量是管理者的责任）“都是程序员的错误” 。“质量改进早就抓过了” 。“我们已建立了质量控制制度”。过分重视神奇的工具而忽视了软件工程基础知识。只要满足标准或规格就够了。持续改进的结果不是零缺陷，没有缺陷也未必能让用户满意。测试原型不足。“任何一个帮助我们的人都必须懂得我们的系统”。77二、案例机构设置及岗位职责第二章 案例机构设置及岗位职责软件企业组织结构研发团队与其他部门之间的关系研发团队岗位设置各岗位职责企业文化对研发团队的影响一个典型的企业组织结构图组织结构图说明对于做集成类的软件公司，采供部一般都会

30、设置，但可能会与财务部或行政部合起来；一些公司会把测试部从研发部单独出来，也有可能与质量管理部同设为一个部门；中小型公司，人力资源部一般是与行政部合设；产品经理角色，有些公司放置在市场部，有些公司放置在研发部；部分公司的质量管理部为直接对总经理负责，而不是由技术副总分管；对于ISO9001的企业，还应当设置管理者代表一职。组织结构图说明组织级配置管理，一般都放置在研发部；股份制公司还设为监事会；规模梢大一些的企业，还会设置发展规划部，以负责公司新方向的发展规划相关业务拓展；根据产品线的不同，市场部或营销部设置以产品线来命名的事业部来负责相关产品的推广、营销，比如证券事业部、呼叫中心事业部等；工

31、程部或项目部有时也会根据产品线来设置。人力资源部审计部企业发展部营销管理部通用产品本部物流中心区域平台：华东平台、华南平台 普通平台：武汉、西安、沈阳、成都、香港 简易平台：南京、深圳、济南 地方办事处：杭州、福建、昆明、青岛等软件集成本部系统集成事业一部技术服务中心系统集成事业二部网络集成事业部服务与培训事业部软件产品部技术工程部电信事业部政府事业部金融事业部业务管理部业务发展部系统集成本部业务管理部业务发展部项目管理部业务管理部业务发展部电子商务部客户服务部产品部销售部业务管理部业务发展部企业解决方案本部SUN事业部IBM事业部增值软件事业部通用软件事业部存储事业部HP事业部新产品事业部网

32、络业务本部业务管理部产品部市场部华东大区华南大区北区西区移动通讯本部业务管理部业务发展部个人通讯事业部新业务事业部客户服务部市场部产品管理部分销业务部行业销售部研发一部研发二部业务管理部网络公司华东区总部企管部研发运控中心市场发展部北方区总部华南区总部SAP事业部DCMSIT集成服务事业部软件工程事业部客服中心财务部集团办第二章 案例机构设置及岗位职责软件企业组织结构研发团队与其他部门之间的关系研发团队岗位设置 各岗位职责企业文化对研发团队的影响研发与市场部门间的关系研发的需求大部分来自于市场，市场部门能接触到第一手的客户需求问题：销售人员不理解技术，研发人员不理解客户，怎么解决？研发的产品不

33、能很好的解释给用户或给用户提供合适的解决方案，怎么办？研发与工程部门间的关系工程实施的两种类型产品安装型现场不能修改程序客户定制型在研发部门提供的核心功能基础之上，在现场根据客户需求调整程序产品安装型，培训及用户需求收集反馈客户定制型用户需求收集反馈，现场调整程序纳入新版产品培训及技术传递研发与质量管理部间的关系共同提高研发产品的质量质量管理部关注的是产品研发过程及结果是否符合公司目标及规范，并根据研发部门反馈，参与或主导对软件开发过程进行改进研发部类似于运动员，质量管理部类似于裁判员，EPG类似于立法部门。负责公司研发类项目度量数据的收集与分析EPGEPG工程过程组，一般由技术总监、总工程师

34、、研发部工程过程组，一般由技术总监、总工程师、研发部经理、质量管理部经理及主要成员、资深系分工程师、资深经理、质量管理部经理及主要成员、资深系分工程师、资深程序员、配置管理经理、产品经理等人员组成程序员、配置管理经理、产品经理等人员组成研发与客户服务部间的关系客户服务部负责用户需求收集及问题，并及时反馈给研发部门研发部门分析各类用户需求及问题，根据公司产品规划，及时更新版本。第二章 案例机构设置及岗位职责软件企业组织结构研发团队与其他部门之间的关系研发团队岗位设置 各岗位职责企业文化对研发团队的影响软件生命周期图新产品需求开发需求开发软件需求需求规格说明书项目策划项目策划估算项目开发计划系统设

35、计系统设计概要设计详细设计系统测试系统测试系统测试验收测试 / 用户试用实现与测试实现与测试单元代码单元测试系统测试服务与维护服务与维护退役退役升级建议和限期维护通知产品升级项目总结项目总结项目分析发布基线生成技术交接产品发布 / 提交编码方案测试需求发放合同合同/产品项目产品项目立项立项客户验收客户验收验收测试 / 用户试用阶段工作内容和常见工作产品列表阶段工作内容和常见工作产品列表阶段阶段工作内容工作内容工作产品工作产品立项1.可行性研究/合同评审、签订2.立项评审1. 立项可行性分析报告3.立项报告5.立项通知书6. 项目任务书2.用户需求说明书（初稿）4.需求和项目计划阶段工作计划需求

36、1.编制并完善用户需求说明书2.软件需求规格说明书编写3.工作产品评审4.需求跟踪及管理1.用户需求说明书3.用户需求跟踪矩阵2.软件需求规格说明书4. 需求变更申请表计划1.项目范围分析、工作分解3.编制进度表5.编写配置管理计划7.计划评审、批准2.估计规模、工作量等4.评估项目风险6.编写项目开发计划1.项目开发计划含：质量保证计划、CM计划、风险管理计划和培训计划2.评审记录设计1.概要设计3.数据库设计2. 模块计工作产品评审1.概要设计说明书3.数据库设计说明书2.模块设计4.评审记录实现与测试1.编码 2.编制各类用户手册2.单元测试1.单元代码3.单元缺陷管理列表2.单元测试用

37、例列表4.单元测试报告测试集成测试1.集成测试计划编制、评审3.集成测试2.集成测试用例编制、评审4.集成测试报告编制、确认1.集成测试计划3.缺陷管理列表5.评审记录2.集成测试用例4.集成测试报告系统测试1.系统测试计划编制、评审3.系统测试2.系统测试用例编制、评审4.系统测试报告编制和确认1.系统测试计划3.测试记录、缺陷记录2.系统测试用例4.系统测试报告项目总结1.代码复用总结3.项目总结报告编制和评审5.项目总结会议2.各类手册评审和批准4.产品/项目归档6.项目结项/产品发布1.产品及各类手册3.产品基线建立和审计2. 项目总结报告4.评审记录研发岗位设置PI过程改进，一般负责

38、公司各类过程改进的，不只是研发过程，还包括业务过程、物流过程等。CM配置管理，一般包含四块职责，版本管理、变更管理、工作空间管理、发布管理。EPG工程过程组，以研发类过程改进、过程资产库管理为主CCB配置控制委员会，对产品研发过程中重大的变更进行评审QA质量保证研发全貌图项目管理RSKM风险管理PIM项目立项管理PP项目计划MR管理评审PMC项目监控与控制SAM供应商协议管理PCM项目结项管理研发全貌图工程过程RDM需求开发及管理SD系统设计TR技术评审IT实现与测试ST系统测试CA客户验收SM服务与维护研发全貌图支撑过程DAR决策分析与解决QA质量保证，包含对过程及工作产品的质量保证CM配置

39、管理MA度量分析研发全貌图组织过程OPM机构过程管理，包括机构过程的定义、关注焦点等等。TM培训管理第二章 案例机构设置及岗位职责软件企业组织结构研发团队与其他部门之间的关系研发团队岗位设置 各岗位职责企业文化对研发团队的影响研发团队中岗位职责为了适合CMMI软件过程改进的需要，根据上一节的研发团队岗位设置，我们在本课中分为五大类角色过程管理角色公司级的，对整个公司的软件开发过程负责的相关角色项目管理角色项目级的，对项目主管或负责的角色工程过程角色项目级的，在具体某个项目中负责各个阶段相关工作的角色支撑过程角色项目级或产品级的，在具体某个项目或产品中负责CMMI支撑过程域相关工作的角色临时角色

40、根据项目阶段的需要，临时设立的角色具体人员建议组成及职责如下：过程管理角色过程管理角色工 程过 程组（E P G）由相关业务部门的部门经理、质量保证经理、配置管理经理、技术专家组成，有一位组长。EPG职责：1.制定适合于本机构的过程规范；2.在机构范围内推广该规范（如培训、考核），评估机构过程能力等。EGP组长职责：1.制定过程改进计划并跟踪执行；2.向总经理提交EPG过程改进活动的报告（如进展报告、工作周报等）；3.向总经理汇报过程改经工作的问题，争取总经理的协助。质 量保 证小组（Q A G）由质量保证经理(QA经理)和质量保证工程师组成。质量保证经理职责：1.质量保证经理为每个项目指定一

41、名质量保证工程师；对质量保证工程师提交的项目组内无法解决的不符合问题进行协调；2.监督规范的实施，确保所有项目以及相关部门准照规范开展工作；3.分析机构内共性的质量问题，给出质量改进建议和措施，协组EPG完善规范。4.对过程改进项目执行质量保证相关活动。配 置管 理小组（C M G）由配置管理经理(CM经理)和配置管理员组成。配置管理经理职责：1.维护机构级配置管理库及过程资产；为每个项目指定一名配置管理员；2.依据文档化的规程，协助配置管理员制订CM计划，并审核CM计划；审计各阶段的配置管理活动报告；3.根据项目需要选择合理的配置管理工具，报EPG批准纳入过程资产库，定期组织培训；4.根据配

42、置管理员提交的配置管理活动报告，定期进行度量、分析，形成分析结果，给出改进措施，实现配置管理过程持续改进；5.组织协调配置管理员与软件工程师或技术服务部门之间的工作交流与问题处理； 项目管理角色项 目管 理角色总工程师1.是机构内所有项目的主管，对立项管理和结项管理有最终决策权；2.对QA经理提交的无法解决的不符合问题进行协调。3.审查所有的对机构外部的个人和组所作的软件项目承诺；4.组织协调跨部门或与客户的工作交流与问题处理；研发部经理1.监督项目经理的工作，审批项目经理的各种申请；2.参加评审会并审阅评审报告；3.负责监督软件过程规范的实施；4.参与软件、硬件、技术服务等软件相关阶段的工作

43、产品、使用技术、工具的评审和审批，并给予必要的支持；项目经理（PM）1.向研发部经理或总工程师汇报工作；2.对项目进行规划、对进度实施监控、进行风险管理和需求管理；3.监督项目成员的工作，审批项目成员的各种申请及子计划；4.制定编码与单元测试、系统集成的阶段性计划5.参加评审会并审阅评审报告；6.配合质量保证工程师不合格问题的解决及跟踪，支持其工作；7.负责项目的度量工作。工程过程角色工程过程角色项目组成员1.项目组内除项目经理外的其他所有人员，包括以下人员：需求开发人员、系统设计人员、开发人员、测试人员。需求开发人员1.调查、分析并定义需求，撰写相应的需求文档，尽最大努力使需求文档能够正确无

44、误地反映用户的真实意愿。系统设计人员1.根据需求文档设计软件系统的体系结构、用户界面、数据库、模块等，并撰写相应的设计文档。开发工程师1.根据系统设计文档，编写软件系统的代码；2.随时测试和检查自己的代码，及时消除代码中的缺陷。测试经理1.依据文档化的规程，为每一个软件项目制定测试计划，并按得到批准的计划开展活动；2.组织编写测试用例；3.根据项目需要选择合理的测试工具，报EPG批准纳入机构资产库，并定期组织培训；测试工程师1.从事集成测试、系统测试，负责参与项目开发各个过程工作产品的可测试性的审查和验证，及时发现、记录缺陷并验证缺陷等关闭活动；2.为项目编写集成测试及系统测试用例，并执行软件

45、测试过程；3.项目测试结束后，编写测试报告提交测试经理；支撑过程角色支撑过程角色配置管理员（CM工程师）1.依据文档化的规程，为每一个软件项目制定配置管理计划，从机构资产库中选择合理的配置工具，并按得到批准的计划开展活动；2.根据软件项目CM计划，建立配置库系统，识别将置于配置管理之下的所有软件工作产品；3.依据文档化的规程，对基线更改进行控制，定期形成更改请求摘要与状态报告，提交项目经理；4.依据文档化的规程，由软件基线库生成产品，并控制其发布；5.依据文档化的规程，记录配置项/单元的状态；6.编写标准的报告，记录CM活动和产品基线的内容，定期整理配置数据，形成CM活动报告提交项目经理及配置

46、管理经理；培训组1.根据机构发展战略，总结出将来可能要有培训需求；2.定期或不定期地从项目组获得培训需求，从以上两种方式收集培训需求、确定培训计划，并实施该计划，撰写培训评估报告；3.维护培训资料库。产品维护人员1.为客户提供与产品相关的服务（如技术咨询），快速响应客户的要求，给客户一个满意的解答。2.纠错性维护：及时解决用户遇到的技术故障和消除产品中的缺陷；3.完善性维护：在资源允许的情况下，不断改善产品功能与质量。质量保证工程师（QA工程师）1.根据项目计划制定质量保证计划；2.遵循已制定的计划、标准和规程，按照经过评审的质量保证计划，从第三方的角度周期性的监控软件开发任务的执行；3.通过

47、QA审计报告给项目经理和开发人员提供已识别出的质量问题并跟踪问题的解决过程，与项目组协商不符合问题的解决措施，给出质量改进的建议；4.向QA经理汇报项目组内不能解决的不符合问题；5.撰写并向QA经理和项目经理发布QA周报，提供反映产品和过程质量的信息和数据；6.协助收集项目度量数据；7.参与项目相关评审活动。临时性角色临时角色临时角色职责说明职责说明立项小组由产品创作者（构思者）、业务专家、技术专家、市场人员组成；应有一位主席或组长；1.开展立项调查、产品构思、可行性分析等活动，全面考虑公司战略、效率、成本等各方面因素，撰写立项报告或可行性分析报告；2.申请立项，并在立项评审会议上答辩。立 项

48、 决 策委员会由机构领导、各级经理、市场人员、技术专家、财务人员等组成，应有一位主席或组长；1.对立项活动进行评审，委员会投票决定是否同意立项。评审小组由机构领导、项目组成员，项目组以外的技术专家等组成；应有一位主席或组长；1.对工作成果进行正式技术评审，尽早地发现工作成果中的缺陷；2.对项目过程进行管理评审，给出决策建议。配 置 控 制委 员 会 （CCB）由一组负责评估和审批配置项的变更的人员（CM）组成，本案例中是由总工程师、市场部产品经理、研发部长、配置管理工程师、配置管理经理、项目经理等人组成；1.对配置管理各项活动拥有决策权；2.审批配置管理计划；3.对递交进来的所有变更请求进行审

49、查、分析，从而决定如何处理这些变更请求，审批变更请求；4.基线建立的审批；产品发布的审批；第二章 案例机构设置及岗位职责软件企业组织结构研发团队与其他部门之间的关系研发团队岗位设置 各岗位职责企业文化对研发团队的影响以客户为中心案例：某公司产品通过四五年的研发，还是常出现问题，各个部门之间相互抱怨非常多；原因分析：研发过程虽然非常规范，但与其他非技术部门之间的接口没有通过流程来规范研发人员缺乏以客户为中心的意识，自我为中心意识严重团队精神成败偕团队共有互教互学互相奉献和支持遇到困难，互相鼓励，及时沟通，用团队智慧来解决问题承认并感谢队友的工作和帮助甘当配角欣赏队友的工作有这样一个故事，大家在喝

50、酒，总共喝了两瓶，如果让人分开说自己喝了解多少，加起来总数肯定大于两瓶。树立正确的人才观敬业精神团队精神责任心工作热情解决问题能力快速学习能力创新精神独立工作能力管理风格？以人为本、团队精神、有效交流构成了企业文化的三大支柱，而艺术的管理则是培育并维护企业文件的根本保证领导要有远见卓识没有永远的主管我不同意你，但我支持你不事必躬亲：好领导的标志之一员工忠诚：好领导的结果三、立项管理三、立项管理电子科技大学电子科技大学第三章立项管理立项管理简述立项管理流程立项管理活动立项管理实训 l通过规范企业里的研发立项过程，主要是想达到如下目的：通过规范企业里的研发立项过程，主要是想达到如下目的：l降低项目

51、投入的风险，避免研发项目的随意性；l加强项目的目标、成本和进度考核，提高项目成功比例；l杜绝不实际的研发项目展开，避免公司资源浪费。l对于销售立项则不是如此，通过销售立项的审批，是想达到如下目的：对于销售立项则不是如此，通过销售立项的审批，是想达到如下目的：l不放过可以赢利并且能做或可以做的项目，拒绝亏本并且不值得亏本或者暂时做不了或不值得做的项目；l比较清楚地了解用户需求和客户信用状况，减少合同签订后的变更；l确定一个比较合理的报价。为什么要进行立项管理?为了做出正确的立项决策，应当拿出一个比较全面的项目陈述，比如：立项报告、立项可行性分析报告等。在其中尽可能全面的考虑方方面面的因素，权衡得

52、失。例如：l这个产品研发到底有多大把握？l这个项目可以做吗？技术积累够吗？现有人力调度得过来吗？l项目需求明确吗？合理吗?l研发人员说至少要半年，用户或公司希望要求2个月，怎么办？抽调人员，别的项目用户会怎么反应？l这个产品值得研发吗？成本要100万，而市场销售可能只有80万，最后亏本，谁买单？l工作由谁负责，哪些人去做？如何做？立项要解决的问题第三章立项管理立项管理简述立项管理流程立项管理活动立项管理实训 立项管理流程图第三章立项管理立项管理简述立项管理流程立项管理活动立项管理实训 谁提出项目立项?合同类项目市场部门若有定制开发类的业务，根据公司确定的市场管理相关规定提出需要技术部门给予配合

53、的申请（一般为销售立项通知单，在该单据里会写明将要跟踪的业务基本情况，需要什么样的技术人员配合等内容）。然后，由总工程师从研发部门指定专门的技术人员，配合业务人员做技术方案。 注意：在此时选择技术人员时，应当考虑到该人员的综合能力，因为如果该业务合同一旦签订，此人就是该项目的项目经理。例如 某省电力公司设备巡检系统谁提出项目立项?（续）新产品研发类项目在两种情况下可以提出新产品研发，一是公司对某一产品有研发意向；二是市场部门与技术部门通过讨论，要开发某一新产品。此时，则由总工程师确定立项方式，并指定专人或亲自负责，做立项的前的准备工作。注意，此人通常会为项目立项之后的项目经理，所以在指定人选时

54、需要考虑综合能力。主要是完成立项的可行性分析，并且根据项目的类型确定是否进行技术预研，对于需要用到新技术、新工具及新平台的产品研发，应当进行技术预研。例如 iPad的研发谁提出项目立项?（续）产品升级类项目根据市场及用户的反馈，由研发部经理或总工程师确定是否进行升级研发，由自己或指定专人负责，做立项准备工作。【说明：市场及用户反馈一般来源于公司对产品已有用户做的使用情况调查、对本公司产品及同类产品进行的市场调研分析、公司售后服务部门从客户处得到已有产品的使用报告或问题（故障）报告等。】例如 iPhone 5后推出iPhone 5S怎样提出项目立项?合同类项目，由总工程师指定的技术人员参与业务的

55、商务谈判，并撰写技术方案书，然后按公司合同评审管理流程，提出评审。新产品研发类项目，由总工程师指定的负责人为主来撰写立项可行性分析报告或立项报告，该立项负责人通过协调技术部门、市场部门、财务部门等共同来完成资料的编写。根据项目的规模来确定，对于投资比较大或者风险比较大的项目，建议编写立项可行性分析报告。产品升级类项目，由研发部经理或总工程师指定的负责人为主来撰写立项报告；若升级规模比较小或研发周期比较短，也可以由总工程师直接下达项目任务书。至少应明确：项目范围及目标、验收标准、技术规划、计划进度、成本预算、风险预计等。可行性分析报告内容目的：确定问题是否值得去解决技术可行性经济可行性操作可行性

56、说明：具体请参见给定的立项可行性分析报告模板可行性分析报告编写过程复查系统规模和目标研究目前正在使用的系统导出新系统的高层逻辑模型进一步定义问题导出和评价供选择的解法推荐行动方针形成可行性分析报告立项报告内容项目背景项目范围及目标项目验收标准项目资源及费用预算项目进度控制项目风险控制市场推广及工程实施相关建议或措施具体请参见立项报告谁进行立项评审？合同类项目根据合同管理里的合同评审办法进行评审，作为公司管理的一个重要环节，合同管理各公司会有比较明确的规定，在签订合同之前，会对合同的技术内容、可能的风险、违约责任、己方履约能力、收款条款等进行评审。其他项目立项负责人在完成立项可行性分析报告或立项

57、报告后，向总工程师或研发部经理提出评审要求。总工程师或研发部经理确定参加评审的人员，评审两天前立项负责人把相关资料交到评审人员手中。具体是评审前两天，还是几天，可以根据项目的规模、项目的重要度、项目整体周期来确定。然后召开评审会议，具体评审会议怎么召开？怎么组织？公司里一般有管理评审的相关规定 怎么进行立项评审？合同类项目，按照各公司自己确定的合同评审办法执行。只要合同评审通过，对于研发来说，就认为立项通过，即可进入一下环节（总工程师根据与客户签订的合同填写并签发项目任务书）。其他类项目，参加评审的人员收到相关立项评审资料后（立项报告或立项可行性分析报告），仔细阅读并填写预审问题清单，在评审前

58、交给立项负责人；立项负责人根据预审问题清单中提出的问题进行修改或准备答辩资料；举行评审会议，具体评审会议召开的规定请参见第4章 项目评审管理相关内容。谁签发项目任务书？如果立项评审通过则需要签发立项通知书，若未通过，则在项目评审表中写明处理方式，一般分为不接受和变更两种情况，具体请参见项目评审表的内容。对评审中出现的问题，根据项目评审表中的内容进行跟踪修订情况，其中对每个问题的修改情况，必须由验证人进行跟踪，并把修改及验证所花的工作量记录进该表。立项申请人编制立项通知书，报总工程师批准，由总工程师根据项目规模和费用的大小上报公司总裁或自己审批。总工程师根据立项通知书填写并签发项目任务书，合同类

59、项目根据与客户签订的合同填写并签发项目任务书。立项管理要点应该估计整个生命周期每个阶段、各项活动、各类相关人员必须为该项目投入的工作量和成本；工作量和成本估计，如果涉及多个部门，应由相关部门分别估计然后由总工程师汇总，不能一个人说了算，也不能全由研发人员或市场人员说了算，更不能随便估算就交差。既要计入直接成本和工作量，也要考虑间接成本和工作量。为项目开发的需要而购买的软硬设备，或者项目交付后项目成果可以进一步作为公司的新产品或新版本，或者已经有了初步成果而通过新项目则可以节省产品开发所需的投入等。在这些情况下，应妥善分割成本和工作量，全部成本和工作量完全分摊在一个项目头上，显然不合理。比如：在

60、项目研发期间需要购买一台服务服，但该服务器在此项目结束之后还可以继续使用，那么把成本全部算到该项目上显然不合理。工作量到成本的折算，可用上一个年度整个部门全年人均开支，也可用上一个季度的人均开支，也可用各类人员的人均开支。业务费、项目奖金以及其他必须的特殊开支，应计入（工作量之外的）成本应考虑风险储备以及项目相关各方沟通协调所可能必需的工作量和成本。要为必然会有的需求变更引起的工作量增加留有余地。立项管理要点（续）立项时的风险考虑事项：应从思想深处树立风险意识，“风险与机会同时存在，收益和风险始终相伴”。项目风险管理与项目本身的工作同样重要；风险管理是任何项目所必然包含的一项工作内容。不能为躲