Final Review

1. Final Review Software Process Management and Improvement Chen Gang sharepool@yahoo.com.cn chenzuolin@yahoo.cn International School of Software, WHU

2. 软件过程管理与改进 Final Review 期末总复习 陈刚 武汉大学国际软件学院

3. 目录 Final Review 一、绪论 二、软件过程成熟度框架 三、能力成熟度模型的结构 四、可重复级 五、已定义级 六、已管理级 七、优化级 八、个体软件过程 九、群组软件过程 十、CMMI

4. 一、绪论(1) Final Review 1. 软件与软件产业的发展过程 • 软件管理工程的发展，经历了从20世纪70年代开始以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征的结构化生产时代，到90年代中期，以CMM模型的成熟和日益为市场接受为标志，已经进入以过程成熟度模型CMM、个体软件过程PSP和团队软件过程TSP为标志的以过程为中心的时代，而软件发展第三个时代，即软件工业化生产时代，以90年代中期软件过程技术的成熟和面向对象技术、构件技术的发展为基础，已经渐露端倪。

5. 一、绪论(2) Final Review 2. 软件危机及其原因 • 软件特殊性：软件成本高；软件开发的进度难于控制；估计软件工作量很困难；软件质量难于保证；修正维护软件困难。 • 软件企业的4个困难：需求的完全识别；软件产品需求的完全传递；软件产品相关的变更控制；软件产品相关技术的快速变化。 • 软件构建的核心就是管理复杂度 。软件是由人开发的，人的智力与软件的复杂度之间存在矛盾。 • 软件复杂度与软件的规模有很大关系，另外也与模块间的耦合度、模块内的内聚性等因素有关。

6. 一、绪论(3) Final Review 3. 过程及其要素 • 软件开发项目是在规定的成本和时间内，开发和提交满足客户某些需求的软件产品。 • 项目的三个基本特征是:成本、进度和质量（代表软件在多大程度上满足客户的要求）。 • 对于机构而言，包含多个项目，而实现机构的高质量和生产率，依赖于三个因素:过程、人和技术。 • 其中过程不仅仅是一系列步骤，还包含了机构所积累的经验，包含了机构可以从已成功的项目中所学到的一切。

7. 一、绪论(4) Final Review 4. CMM与软件产业 • 管理是影响软件研发项目全局的因素，而技术只影响局部。 • 1987年9月，美国卡内基-梅隆大学软件工程研究所发布了软件过程成熟度框架，并提供了软件过程评估和软件能力评价两种评估方法和软件成熟度提问单。 • 4年之后，SEI将软件过程成熟度框架进化为软件能力成熟度模型（Capability Maturity Model For Software，简称SW-CMM）。1991年8月，SEI发布了最早的SW-CMM v1.0。经过两年的试用，1993年SEI正式发布了SW-CMM v1.1，这是目前使用最为广泛的版本。

8. 一、绪论(5) Final Review 5. ISO9001与CMM的异同 • ISO9000系列包括3个第三方认证标准（ ISO9001 、 ISO9002 和ISO9003 ）和一个质量管理标准ISO9004。 • CMM和ISO9001标准系列都着眼于质量和过程管理，二者都为了解决同样的问题。 • CMM是动态的、开放的和持续改进的，强调没有最好只有更好，强调不断改进，强调人在软件开发方面的思想认识和主动性，适用于软件过程的改进；CMM模型只关注软件，它能解决“软件危机” 这个世界性的问题；ISO9001是静态的质量控制，只要达到几个关键指标就能完成质量控制，更适用于硬件制造生产线的质量控制。ISO 9001的适应范围更广，包括硬件、软件和服务。

9. 二、软件过程成熟度框架(1) Final Review 1. CMM基本知识 • CMM为软件企业的过程能力提供了一个阶梯式的进化框架，阶梯共有五级。 • 初始级：无序、混乱的软件过程。依赖个别人的努力和机遇。 • 可重复级：建立基本的项目管理过程。相似项目，重复以往成果。 • 已定义级：文档化、标准化和标准的软件过程。 • 已管理级：软件过程和产品质量有详细的度量标准。 • 优化级：持续的对过程进行改进。

10. 二、软件过程成熟度框架(2) Final Review 2. 成熟度级别的行为特征 • 从效果而言，在上述不同阶段，软件开发生产的成熟程度给软件企业带来了完全不同的效果。第一阶段到第五个阶段，软件开发生产的计划精度越来越高，每单位工程的生产周期越来越短，每单位工程的成本越来越低。 • 各关键过程域中规定了执行约定、执行能力、执行活动、质量和验证的标准等。 • 管理者：经理、各级经理、领导、职员和个人。 • 软件小组：软件工程组、软件工程过程组、软件相关组等。

11. 二、软件过程成熟度框架(3) Final Review 3. 成熟度级别的跳跃 • CMM每个成熟度级别都是下一级别的必要基础。 • 机构可以选择合适的时机，着手进行特定的过程改进。 • 过程改进工作应该在其业务环境内侧重机构的需求。 • 实施软件过程改进的差异是由定义关键过程域引起的。

12. 二、软件过程成熟度框架(4) Final Review 4. 软件过程可视性 • 等级1―――一个黑盒 • 等级2――― 项目里程碑处具有管理可视性 • 等级3―――盒子的内部结构可视 • 等级4―――软件过程被配备上度量，并得到定量地控制 • 等级5―――对过程不断改进

13. 三、能力成熟度模型的结构(1) Final Review 1. CMM的内部结构 • CMM由5个成熟度级别组成。 • 每个成熟度级别（除级别1）包含了实现该级别的若干个关键过程域（KPA）。 • 每一个KPA进一步被分为称为公共特征的5个部分。 • 这些公共特征包括了关键实践（KP），即每一个KPA包括5类KP。 • 实现了这些KP后，就实现了关键过程域的目标。

14. 三、能力成熟度模型的结构(2) Final Review 2. 关键过程域 • 一系列相互关联的操作活动。 • 某一级别的一组目标，用以衡量是否具有此级别的能力。 • 每个KPA的目标总结了它的关键实践（KP），目标说明了每一个KPA的界限、范围、内容和关键实践。 • 不同级别的KPA（项目、数目、内容）是不同的，但其中很多项都有深层次的联系（上级是下级的深化和延伸）。 • 18个关键过程域，分布在2~5级。

15. 三、能力成熟度模型的结构(3) Final Review 3. 关键实践 • 每一个关键过程域都是用关键实践的概念进行描述。 • 描述了对关键过程域的有效实施和制度化起最重要作用的基础设施和活动。 • 达到一个KPA而要做的事。 • 描述了“做什么”，但没有规定“如何做” 。

16. 三、能力成熟度模型的结构(4) Final Review 4. 共同特性 • 无论哪个KPA，它们的关键实践都统一按五个公共属性进行组织，即每一个KPA都包含五类KP。 • 执行约定：组织为保证过程得以建立和持续发挥作用所必须采取的行动，主要包括制定企业范围的政策和高层管理的责任。 • 执行能力：达到的前提条件，一般包括资源保证、人员培训等内容。 • 执行活动 ：必须执行的任务和步骤，一般包括计划、执行的任务、任务执行的跟踪等。 • 度量和分析：度量的基本原则，用以确定、改进和控制过程的状态。 • 验证实施：验证所开展的关键实践与确立的过程是否遵循已制定的步骤。

17. 三、能力成熟度模型的结构(5) Final Review 5. CMM的应用 • CMM的两种主要用途归结为两种评定方法。 • 软件过程评估: 用于确定组织目前的软件过程状态，确定组织面临的突出软件过程问题，从而求得组织的软件过程改进的支持。 • 软件能力评价: 用于识别合格的软件工作承包商，或用于监控现行软件工作项目上用的软件过程的状态。 • CMM是软件过程评估和软件能力评价的公共基础。不过，两种用法的目的不同，而且具体用法也有很大差异。软件过程评估侧重于确定本组织软件过程改进的轻重缓急；软件能力评价侧重于确定在选择软件项目承包商时可能碰到的风险，或者说是确定软件组织在软件能力方面的置信程度。后面这一点正是许多软件组织看好按CMM评定等级的原因。

18. 四、可重复级(1) Final Review 1. 可重复级的基本特征 • 关注项目一级的软件过程。 • 已建立了项目管理的方针和规定。 • 对项目已设置基本的软件管理控制。 • 组织的过程能力体现在有纪律。 • 当有转包商时，通过转包合同建立有效的供求关系。 • 缺陷：依赖经验管理项目。

19. 四、可重复级(2) Final Review 2. 需求管理（ RM, Requirements Management） • 分配需求是指分配给软件的系统需求，包括：软件项目活动中的非技术性需求、软件技术性需求、接收标准。它是制定软件开发计划的根据，是整个软件生命周期中估算、计划、执行和跟踪软件项目活动的基础。 • 目标：建立基线；软件开发计划、产品和活动与分配给软件的系统需求保持一致。即，需求确定的管理、需求实现的管理、需求变更的管理。 • 执行活动：评审分配需求；将分配需求作为软件开发的基础；评审需求变更并纳入到项目中。 • 由上级主管部门和软件质量保证组实施验证。

20. 四、可重复级(3) Final Review 3. 软件项目计划（SPP,Software Project Planning） • 目标：对软件估计建立文档；项目活动和约定是有计划的，并已形成文档；相关小组和个人对约定达成共识。 • 执行活动：软件项目的策划、建议与评审；确定易于管理的软件生命周期；制定项目的软件开发计划（SDP）；识别软件工作产品；作出软件估计并形成文档；记录软件计划数据。 • 由高级管理者和软件质量保证组实施验证。

21. 四、可重复级(4) Final Review 4. 软件项目跟踪和监控(SPTO，Software Project Tracking and Oversight) • 目标：对照SDP，跟踪实际结果和性能；发生明显偏离时采取纠正措施；对软件约定的更改应得到相关小组和个人的认可。 • 执行活动：利用SDP跟踪活动并修订项目的开发计划；跟踪实际的开发过程，必要时采取纠正措施；记录软件项目的实际度量数据，并重新计划数据；定期进行内部审查和在项目里程碑处进行审查。 • 由上级主管部门和软件质量保证组实施验证。

22. 四、可重复级(5) Final Review 5. 软件转包合同管理（SSM，Software Subcontract Management） • 目标：主承制方选择合格的软件分承制方；主承制方与软件分承制方确认他们相互间的约定；主承制方和软件分承制方保持工作联系；主承制方根据约定跟踪软件分承制方的实际结果和性能。 • 执行活动：选择合格的转包商，并与之签订合同；主承包商审查转包商的软件开发计划，并用于跟踪其软件活动；评审、评价转包商；监督、验收转包商的软件活动。 • 由上级主管部门和软件质量保证组实施验证。

23. 四、可重复级(6) Final Review 6. 软件质量保证（SQA，Software Quality Assurance） • 目标：SQA活动是有计划的；客观地验证软件产品和活动是否遵守所用的标准、规程和需求；SQA组所进行的活动和结果及时通知到相关的组和个人；高层管理者及时处理在软件项目内部不能解决的不一致性问题。 • 创建一个SQA小组是开展软件质量保证的必要条件。 • 执行活动：制定软件项目的SQA计划；按照SQA计划来开展活动；评审软件工程活动，以检验一致性；审核制定的软件工作产品，以检验一致性。 • 由上级主管部门和独立于SQA组的专家进行审查。

24. 四、可重复级(7) Final Review 7. 软件配置管理（SCM，Software Configuration Management） • 目标：软件配置管理活动是有计划的；所选用的软件工作产品是经过标识、受控和可用的；对已标识的软件产品的变更是受控的；相关组和个人能及时得到软件基线的状态和内容。 • 创建一个有权力管理项目软件基线的委员会（SCCB）和一个SCM小组是开展SCM的必要条件。 • SCM活动主要解决四个方面的问题：配置识别；变更控制、配置状态统计、配置审核（正式审核和非正式审核）。 • 由上级主管部门和SQA组进行审查。

25. 五、已定义级(1) Final Review 1. 概述 • 关注组织一级的软件过程。 • 用于开发、维护软件的过程已经得到了系统的阐述并能付诸于实施。 • 有两种“已定义”的软件过程：组织标准软件过程(OSSP)、项目定义软件过程。 • 软件过程能力可概括为标准的和一致的。 • 七个关键过程域。

26. 五、已定义级(2) Final Review 2. 组织过程焦点（OPF，organization process focus） • 目标：在整个组织内，有关软件过程的活动是协调的；识别出一个具体软件过程与一个过程标准相比较的强处和弱处；在组织层上，有关软件过程的活动是有计划的。 • 创建一个负责组织软件过程活动的组（如SEPG组）开展OPF的必要条件。 • OPF的主要活动：定期评估软件过程并制定相应的更改计划；协调组织的标准软件过程和项目定义软件过程的制定和改进活动。 • 由高级管理者进行审查。

27. 五、已定义级(3) Final Review 3.组织过程定义（OPD，Organization Process Definition） • 目标：开发和维护组织的标准软件过程；收集和评审软件项目使用组织的标准软件过程的信息，并使其可用。 • 软件过程体系结构是对组织标准软件过程的高层次描述。它描述了OSSP中的软件过程元素的排序、接口、相互依赖关系及其他关系。 • OPD活动产生软件过程财富，包括：组织批准的软件生命周期、组织标准软件过程、裁减指南、组织的软件过程数据库、软件过程相关的文档库。 • 由软件质量保证组实施验证。

28. 五、已定义级(4) Final Review 4.培训程序（TP，Training Program） • 目标：培训活动是有计划的；为培训组提供实施管理和技术职责所需要的技能和知识的培训；软件工程组和软件相关组的成员接受所需的培训。

29. 五、已定义级(5) Final Review 5.集成软件管理（ISM，Integrated Software Management） • 目标：项目定义的软件过程是组织的标准软件过程经裁减的版本；按照项目定义的软件过程对项目进行计划和管理。

30. 五、已定义级(6) Final Review 6.软件产品工程（SPE，Software Product Engineering） • 目标：定义和集成软件工程任务，并一致地执行它们；软件工作产品间保持一致。

31. 五、已定义级(7) Final Review 7.组间协调（Intergroup Coordination） • 目标：客户需求得到所有相关组的认同；工程组之间的约定得到相关组的认同；各工程组识别、跟踪和解决组间存在的问题。 • 组间协调的目的是为了建立一种工作方式，使软件工程组能和其他工程组积极协调地工作，从而使项目能够更有效地满足客户的需要。

32. 五、已定义级(8) Final Review 8.同行评审（ Peer Reviews ） • 目标：同行评审活动是有计划的；识别并消除软件工作产品中存在的缺陷。

33. 六、已管理级(1) Final Review 1.概述 • 组织为软件产品和软件过程定了量化的质量标准 • 量化控制将使软件开发真正成为一种工业生产活动 • 两个关键过程域 • 定量过程管理 • 软件质量管理

34. 六、已管理级(2) Final Review 2. 定量过程管理 • 目标：定量过程管理活动是有计划的；定量地控制项目定义的软件过程的过程性能；组织的标准软件过程的过程能力是定量已知的。

35. 六、已管理级(3) Final Review 3. 软件质量管理 • 目标：项目的软件质量管理活动是有计划的；软件产品质量的可测目标和目标的优先级被定义；对达到软件产品质量目标的实际进展进行了量化管理。

36. 七、优化级(1) Final Review 1.概述 • CMM中的最高层次 • 工作重点 • 对已有的软件过程进行深层次的改进和过程成熟能力的不断提高 • 企业以“预防”、“改革”和“完善”为目标 • 三个关键过程域 • 缺陷预防 • 技术改革管理 • 过程变更管理

37. 七、优化级(2) Final Review 2.缺陷预防 • 目标：缺陷预防活动是有计划的；缺陷产生的共同原因已经找出且被标识；缺陷产生的共同原因已按优先级排序并被系统地消除。

38. 七、优化级(3) Final Review 3.技术改革管理 • 目标：有计划地进行技术革新；评价新技术，确定他们对软件质量和生产率的影响；将合适的新技术引入到全组织的正常实践中。

39. 七、优化级(4) Final Review 4.过程变更管理 • 目标：持续的过程改进是有计划的；组织内的人员都参与组织的软件过程改进活动；组织的标准软件过程和项目定义的软件过程是不断改进的。

40. 八、个体软件过程(1) Final Review • 个体软件过程(Personal Software Process，PSP)是一种可用于控制、管理和改进个人工作方式的自我持续改进过程，是一个包括软件开发表格、指南和规程的结构化框架。PSP与具体的技术（程序设计语言、工具或者设计方法）相对独立，其原则能够应用到几乎任何的软件工程任务之中。PSP能够说明个体软件过程的原则； 帮助软件工程师作出准确的计划；确定软件工程师为改善产品质量要采取的步骤；建立度量个体软件过程改善的基准；确定过程的改变对软件工程师能力的影响。 • 阶段计划是基于时间段的计划，产品计划是基于活动的计划。一个产品计划需要一个阶段计划的支持。

41. 八、个体软件过程(2) Final Review • 缺陷是指程序中存在的错误，例如语法错误、标点符号错误或者是一个不正确的程序语句，是任何影响程序完整而有效的满足用户要求的东西，是可以表示、描述和统计的客观事物。 • 通过缺陷分类，可以迅速找出哪一类缺陷的问题最大，然后集中精力预防和排除这一类缺陷，这就是缺陷管理的关键。PSP将缺陷分为10类。 • 代码复查是PSP提倡的查找缺陷的方法。在编译之前进行代码复查，是完成目标最好的方法。

42. 九、群组软件过程(1) Final Review • 在设计TSP过程时，需要遵循以下七条原则： • 循序渐进的原则，首先在PSP的基础上提出一个简单的过程框架，然后逐步完善； • 迭代开发的原则，选用增量式迭代开发方法，通过几个循环开发一个产品； • 质量优先的原则，对按TSP开发的软件产品，建立质量和性能的度量标准； • 目标明确的原则，对实施TSP的群组及其成员的工作效果提供准确的度量； • 定期评审的原则，在TSP的实施过程中，对角色和群组进行定期的评价； • 过程规范的原则，对每一个项目的TSP规定明确的过程规范； • 指令明确的原则，对实施TSP中可能遇到的问题提供解决问题的指南。

43. 十、CMMI(1) Final Review • CMMI 的全称为：Capability Maturity Model Integration，即能力成熟度模型集成。CMMI是CMM模型的最新版本。早期的CMMI（CMMI-SE/SW/IPPD）1.02版本是应用于软件业项目的管理方法，SEI在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展，演绎成为一种被广泛应用的综合性模型。 • CMMI 与CMM 最大的不同点在于： CMMISM-SE/SW/IPPD/SS 1.1 版本有四个集成成分，即：系统工程(SE)和软件工程(SW)是基本的科目，对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容，如果涉及到供应商外包管理可以相应的应用SS(Supplier Sourcing)部分 。

44. 十、CMMI(2) Final Review • CMMI 有两种表示方法，一种是大家很熟悉的，和软件CMM 一样的阶段式表现方法，另一种是连续式的表现方法。这两种表现方法的区别是：阶段式表现方法仍然把CMMI 中的若干个过程区域分成了5 个成熟度级别，帮助实施CMMI 的组织建议一条比较容易实现的过程改进发展道路。而连续式表现方法则通过将CMMI 中过程区域分为四大类：过程管理、项目管理、工程以及支持。对于每个大类中的过程区域，又进一步分为基本的和高级的。这样，在按照连续式表示方法实施CMMI的时候，一个组织可以把项目管理或者其他某类的实践一直做到最好，而其他方面的过程区域可以完全不必考虑。

45. 十一、例题（1） Final Review （）1. CMM2（可重复级）重点关注的是下列哪一个级别的软件过程。 A. 个人 B. 机构C. 项目D. 小组 C

46. 十一、例题（2） Final Review （）2. 下面有关CMM模型的描述中，不正确的是。 A. CMM模型定义了成熟的软件过程的实践活动 B. CMM模型提供了改进软件开发过程的结构化模型 C. CMM模型给出了适用于各种应用范围的专门技术 D. 按照CMM模型改进软件过程需要相当可观的费用 C

47. 十一、例题（3） Final Review （）3. 以下哪一个KPA不是CMM2（可重复级）关键过程域。 A. 软件需求管理B. 软件质量保证 C. 软件配置管理D. 定量过程管理 D

48. 十一、例题（4） Final Review （）4. 直接在测试环境中修改源代码违反了下列哪一个KPA的规定。 A. 需求管理B. 配置管理C. 项目计划D. 过程变更 B

49. 十一、例题（5） Final Review （）5. 以下哪一项是实施OPF（组织过程焦点）活动的前提条件。 A. 成立SEPG组B. 进行同行评审 C. 制定软件项目计划D. 识别软件工作产品 A

50. 十一、例题（6） Final Review （）6. “定期地评估过程，理解过程的强项和弱项”是哪一个KPA的活动。 A. SQA（软件质量保证）B. OPD（组织过程定义） C. OPF（组织过程焦点）D. SCM（软件配置管理） C