第六章软件过程管理

软件项目管理 第六章软件过程管理

本章内容提要 • 软件过程与过程管理 • CMMI概述 • CMMI的成熟度等级及其过程域 • CMMI的应用 • PSP，TSP与CMMI • 敏捷软件开发方法

第四节 CMMI的应用 • 实施CMMI过程改进的两种方法 • 阶段表示 • 连续表示 • CMMI评估

实施CMMI过程改进的两种方法 • CMMI模型支持两种实施过程改进的方法，一种称为阶段表示，一种称为连续表示。 • 阶段表示（Staged Representation）为过程改进提供了一个预定义的路线图，即从成熟度等级1到成熟度等级5逐级增加，要达到某一成熟度等级，必须满足该等级（及其以下等级）上所有过程域的目标。

实施CMMI过程改进的两种方法 • 连续表示（Continuous Representation）支持单个过程域的改进，可理解为一个过程域接着一个过程域实施改进。在每个过程域上从能力等级0到能力等级5逐级增加。

阶段表示和连续表示的对比 • 阶段表示是从CMM模型继承而来，已经过多年的实践检验。它提供了一个明确的、被证实的过程改进路径，遵循这条路径不需要过多的讨论和争论。而且由于它的明确性和统一性，有助于进行跨组织的比较。 • 连续表示的优点是提供了灵活性。用户可根据具体的业务目标来选择需要实现的过程域及其实现次序。

CMMI评估 • 成熟度等级的评估由美国卡内基梅隆大的软件工程研究所授权的主任评估师领导一个评审小组进行，其成员大部分来自企业内部。 • 评估过程包括员工培训（企业的高层领导也要参加）、问卷填写和统计、文档审查、数据分析、与企业的高层领导讨论和撰写评估报告等。评估结束由主任评估师签字生效。 • 评估结果报告给SEI，但SEI不会发“认证”证书。

CMMI评估 • 一般有两种类型的评估：软件过程评估和软件能力评价。 • 软件过程评估用于确定机构当前过程的状态，决定一个机构所面临的高优先级的过程相关问题，并且获得机构对软件过程改进的支持。 • 软件能力评价用来确定合格的软件项目承制方，或用来监督在目前的软件项目中正在进行软件过程的状态。

软件过程评估方法 • 判断一个组织当前的软件过程的能力状态，并发现过程中的缺陷。 • 判断并确定一个组织面对的与软件过程相关的改进策略。 • 利用组织的支持来对该组织的软件过程进行有效的改进。

软件能力评价方法 • 判断有意承担某个软件项目的软件组织（投标者）的过程能力。 • 利用评价结果确定选择某一承包者的风险。 • 判断已进行的软件过程所处的状态是否正确或是否正常。 • 推动承包者在工作过程中改进他们的软件过程。

过程评估和能力评价步骤 • 挑选队伍：成员必须具有专业的软件工程和管理方面的知识，并接受过基本CMM/CMMI概念和特定评估及评价方法的训练。 • 问卷调查：让来自被评估单位的代表完成软件过程成熟度问卷并回答评估评价组提出的诊断性问题。 • 响应分析：明确哪些回答与问题的答案相吻合，并确定须进一步调查的领域。

过程评估和能力评价步骤 • 现场调查：从响应分析的结果出发，评估小组进行提问、检查、协商等，以获取专业性的结论，说明软件过程的 KPA是否达到了应有的目标。 • 评估小组提供一个定义软件过程优缺点的结果清单。对于软件过程评估来说，这些结果将成为过程改进的基础和参考；对于软件能力评价来说，这些结果为决策者提供风险分析的技术基础。

过程评估和能力评价步骤 • 评估小组完成KPA基本概况的描述文件，给出组织已经满足的KPA目标和尚未满足的KPA目标。

软件过程评估和软件能力评价之间的不同 • 软件过程评估和软件能力评价的结果可能不同（主要是因为评估和评价的侧重点不一样，而且被评估和被评价的组织、项目、软件产品都会发生变化，因此，应该考虑评估和评价的Context）。 • 软件过程评估和软件能力评价在出发点和目标上是不同的（导致成熟度提问单的内容组织不一样，收集的信息不一样，结论的评价不一样）。

软件过程评估和软件能力评价之间的不同 • 软件过程评估是在一个开放的、互相协作的环境下进行的。而软件能力评价往往是在有较大阻力的环境中进行的。（过程评估是为了提高管理者和工程师的工作水平，而能力评价是为了表明一个软件组织的实际软件过程能力，为选择承包者和减少费用服务）。

CMMI评估的注意事项 • 筹备必备机构 • SEPG：负责过程的定义和策划。 • SQA：负责审核软件过程的实施情况；产品质量的审核和控制。 • 确定合适的目标 • 对指定的KPA作评估或诊断，2级时也可要求对3级的KPA进行评估。 • 有些组织一开始可能并不想进行评分和评级，而是希望评估组从其现有的实践中确定最佳实践，作为组织的标准实践进行推广。

CMMI评估的注意事项 • 确定范围 • 部门：哪些部门参加。 • 项目：选择合适的项目。 • KPA：确定对那些KPA进行评估。 • 人数：为了保证评估取证有足够的可信度，人数总和应该超过组织人数的20％。 • 约束 • 对不参加的部门，评估组无权进行访谈或取证。

CMMI评估的注意事项 • 对不参加的人员，评估组无权进行访谈或取证。 • 经费和预算不得超过某个限度。 • 进度安排应该在一个适当的期限内。 • 期望 • 要求评估师签署结论性证明文件。 • 要求评估组指明每个KPA的优缺点，哪些实践有待改进。 • 要求评估组提出下一步过程改进的计划和大致的日程安排。

CMMI评估的注意事项 • 承诺 • 组织主管保证参加评估的人员不会影响评估活动的正常进展。 • 保证为评估工作提供相应的后勤服务。 • 向评估组授权“开工令”（从某日起开始工作）。

CMMI评估的注意事项 • 准备待审文档 -组织级文档 • 软件生存期模型 • 研发过程的各种方针 • 项目遵循的规程 • 选用的标准 • 裁剪指南 • 标准报表 • 标准测量集

CMMI评估的注意事项 -项目级文档 • 软件开发计划 • 软件质量保证计划 • 软件配置管理计划 • 项目在实施中遵循的规程 • 测量计划 • 培训教材

CMMI评估的注意事项 -实现级文档 • 会议概要：评审会等 • 项目管理过程的状态报告：月度报告等 • 各类变更申请 • 测试记录 • 开发过程中产生的各类工作产品：设计文档，源代码清单等。

影响CMMI过程改进成败的因素 • 过程改进必须有高级主管的支持与委托，并积极地管理过程改进的进展。 • 获取中层管理的支持，以方便地获取过程改进的资源（人员、时间、经费和设备）。 • 基层技术人员的参与和支持极端重要。 • 利用定量的可观察数据尽快使过程改进的成果可见，从而激励参与者的兴趣。 • 按照软件过程改进对企业文化的要求进行变革，要求软件过程改进为商业利益服务，并与企业其他部分协调。

第五节 PSP，TSP与CMMI PSP的产生 • CMM/CMMI只关注“做什么”，而不关注“怎么做”，未提供实现各过程域所需要的知识和方法。为了解决上述问题，CMU-SEI在CMM1.1基础上提出了PSP/TSP。

PSP的产生 • 1995年，CMU-SEI的Watts s. Humphrey领导开发出PSP（Personal Software Processes），被认为是由定性软件工程走向定量软件工程的标志。 • PSP是一种可用于控制、管理和改进软件工程师个人工作方式的自我改善过程，是一个包括软件开发表格、指南和规程的结构化框架。

PSP关注点 • 如何制订计划 • 如何控制质量 • 如何与其他人相互协作 • 如何预防缺陷(PSP重点) 关键是如何提高设计质量

PSP中的个人任务 • 为每一个项目/模块制订开发计划； • 记录开发时间； • 跟踪错误； • 在工程摘要报表中保留数据； • 使用已有的数据计划以后的项目/模块； • 分析已有的数据以改进开发过程，不断提高开发水平。

PSP的使用效果 参加PSP培训的104位软件人员在应用了PSP后: • 软件中总的差错数减少了58.0％； • 在测试阶段发现的差错减少了71.9％； • 生产效率提高了20.8％

PSP过程 • PSP是一个软件过程的描述、测量和改进方法的结构化集合，它可以为软件工程师带来更少的错误代码、更好的预算和计划以及更高的生产率，从而能够帮助软件工程师改善其个人性能。 • PSP提供了帮助软件工程师开发软件的表格、脚本和标准，以估算和计划软件工程师的工作，以便软件工程师可以更加清楚自己的个人技术并且提升个人表现。PSP显示了如何定义过程及如何测量其质量和生产率。

PSP过程 • PSP不依赖于任何技术（语言、工具和设计方法），它： • 示范了软件过程原则； • 帮助工程师做正确的计划； • 告诉工程师怎样提高软件质量； • 建立个人软件过程提升的度量标准； • 确定过程改进在工程师表现中的影响。

PSP过程改进

PSP0（个人过程基线） • PSP0是过程基线，目的是为了在个人的工作中引入表格和脚本，以便工程师按照测量和报告格式记录软件过程。 • PSP0-1.目前过程：记录软件工程师在工程中使用的具有代表性的软件开发方法。 • PSP0-2.时间记录：记录软件工程师在不同的软件开发阶段（计划、设计、编码、编译和测试、维护）所花费的时间。

PSP0（个人过程基线） • PSP0-3.失误记录：按照一致的格式记录软件工程师引入软件中的缺陷，并记录软件工程师尝试解决问题的方法和步骤。 • PSP0-4.错误分类标准：一方面为软件工程师提供在系统中可观察到的典型缺陷种类列表，有助于软件工程师把典型缺陷标准化；另一方面提供一种预定义的步骤和工具方便软件工程师对新的缺陷进行归类和记录。

PSP0.1（个人过程基线） • PSP0可以通过增加下列过程而扩展到 PSP0.1。 • PSP0.1-1.代码规范：通过对设计过程、开发过程和设计语言结构进行规范，约束具有不同技术背景和软件开发风格的软件工程师。由组织统一制订设计方法和编码标准。 • PSP0.1-2.代码规模度量：测量代码的长度、功能、复杂度、再利用数、冗余数等。一般基于某种测量标准进行，如LOC，软件工程师应该了解 LOC及相关测量概念。

PSP0.1（个人过程基线） • PSP0.1-3.过程优化计划：针对已经记录的软件过程中的问题和经验教训，帮助软件工程师给出软件过程能力的改进建议，并以结构化的方式表达软件过程、问题、建议教训、改进建议等项目。

PSP1（个人计划过程） • PSP1在PSP0的基础上增加了计划步骤： • PSP1-1.规模估计：分为代码规模估算、时间估算、资源估算。（1）代码规模估算：软件工程师可以凭借PSP0级代码规模测量经验预测他们将要写的任务模块或算法的可能规模。（2）时间估算：PSP0级时间测量过程可以总结出不同复杂度模块的编写时间，凭借这些经验，软件工程师可以针对当前系统的模块结构层次给出完成每个模块的估算时间（乐观时间、最可能时间、悲观时间）。

PSP1（个人计划过程） （3）资源估算：对于软件开发的一段生存期，软件工程师预测所需要的软件、硬件和人力资源，其中人力资源预测包括人力需求、人力成本估算和项目管理标准。 • PSP1-2.状态报告：对软件工程师的工作进行跟踪，检查规模估计与实际状态之间的差异。

PSP1.1（个人计划过程） • PSP1.1在PSP1的基础上引入了任务计划和安排。 • PSP1.1-1.任务计划及安排：基于PSP1中的规模估计数据制订软件项目的需要完成的任务计划，并将任务按时间段分配给不同的人力资源。一般采纳网络安排技术，如PERT(Program Evaluation and Review Techniques)和CPM(Critical Path Method)，软件工程师应该理解网络安排技术和计划策略。

PSP2（个人质量管理） • PSP2强调提高质量，引入了缺陷管理。 • PSP2-1.代码审查。对代码进行检查和分析，以发现程序缺陷。 • PSP2-2.设计审查。设计审查要求提供一些评估设计质量的指标，如：代码重用率、代码冗余、代码完整性和协作性。设计的一致性检查主要涉及：结构化（控制和数据）一致性、耦合一致性、可移植和互用一致性。

PSP2.1（个人质量管理） • PSP2.1在PSP2.0基础上增加了设计模板。设计模板提供了设计过程的完全标准化，并且连同缺陷预防、过程分析和过程基准一起形成了各种设计检验技术。可类似地将此方法应用到许多过程阶段之中去，包括：需求说明、文档和测试等。

PSP3（循环个人过程） • PSP3将个人软件过程的应用拓展到大规模程序开发当中。将开发大型程序的个体过程细分为可以应用PSP2的片段，遵照PSP2过程循环增量地开发大型程序，从而支持迭代式的开发。在任何时间点，只有一个PSP2级过程是活动的。

TSP • 软件开发通常是以团队形式进行的，因此仅有PSP是不够的。CMU-SEI又以PSP为基础，开发了TSP（Team Software Processes），即小组软件过程。 • TSP指导项目组中的成员如何有效规划和管理所面临的项目开发任务，并且使软件开发队伍始终以最佳状态来完成工作。

TSP • TSP实施集体管理与自我管理相结合的原则，最终目的在于指导开发人员如何在最少的时间内，以预定的费用生产出高质量的软件产品，所采用的方法是对小组开发过程进行定义、度量和改进。 • 小组远不只是一群有才能的个人的集合。为了建立并保持高效率的工作关系，小组需要共同的目标，大家一致同意的行动计划和适当的领导，小组成员要在需要的时候乐于寻求帮助。

TSP实施条件 • 需要有高层主管和各级经理的支持，以取得必要的资源。 • 整个软件开发小组至少应在CMM的第二级（已管理级）。 • 全体软件开发人员必须经过PSP的培训，并有按TSP工作的愿望和热情。 • 开发小组成员应在2到20个人之间。经验表明，4~8个人的小组工作效率最高。

TSP的管理原则 • TSP遵循集体管理和自己管理自己相结合的原则。 • 在每一项目阶段开始要作好工作计划。 • 要有明确定义的目标，努力完成已经接受的委托任务。 • 应定期追踪项目进展状态并进行定期汇报。 • 按自己管理自己的原则管理软件过程。 • 按集体管理的原则进行管理，全体成员都要参加和关心小组工作的规划、进展的追踪和决策的制订等项工作。

TSP的循环开发策略 • TSP通过循环开发策略完成产品。先在第一个周期中开发出最小的合理产品，再决定在接下来的每一个周期中要加进去的功能。这样的步骤可以保证得到一系列最终产品的可运行的前期版本。每个周期包括7个步骤：决定策略、进行计划、考虑需求、设计、实现、测试和最终检查。

TSP度量要素 • 对软件开发小组进行度量的基本要素： • 所编文档页数； • 所编代码行数； • 花费在各个开发阶段或各个开发任务上的时间； • 在各个开发阶段中注入和改正的差错数目； • 在各个阶段对最终产品增加的价值。

TSP度量要素 • TSP有关质量度量的经验原则： • 软件设计时间应大于软件实现时间； • 设计评审时间至少应占一半以上的设计时间； • 代码评审时间应大于编制代码的时间； • 每千行源程序在编译阶段发现的差错不应超过10个； • 每千行源程序在测试阶段发现的差错不应超过5个。

PSP、TSP与CMMI之间的关系 • PSP、 TSP 和CMMI为软件产业提供了一个集成化的、三维的软件过程改革框架。

PSP、TSP与CMMI之间的关系 • PSP注重于个人的技能，能够指导软件工程师保证自己的工作质量，估计和规划自身的工作，度量和追踪个人的表现，管理自身的软件过程和产品质量。经过PSP的学习和实践，软件工程师们能够在他们参与的项目中更为高效和高质量地完成工作，从而保证了项目整体的进度和质量。

第六章 软件过程管理