软件项目管理培训课程之软件过程管理
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
筹备必备机构 SEPG：负责过程的定义和策划。 SQA：负责审核软件过程的实施情况；产品 质量的审核和控制。 确定合适的目标 对指定的KPA作评估或诊断，2级时也可要 求对3级的KPA进行评估。 有些组织一开始可能并不想进行评分和评级， 而是希望评估组从其现有的实践中确定最佳 实践，作为组织的标准实践进行推广。
软件过程评估和软件能力评价之间的不同
ຫໍສະໝຸດ Baidu
软件过程评估是在一个开放的、互相协作的环 境下进行的。而软件能力评价往往是在有较大 阻力的环境中进行的。（过程评估是为了提高 管理者和工程师的工作水平，而能力评价是为 了表明一个软件组织的实际软件过程能力，为 选择承包者和减少费用服务）。
CMMI评估的注意事项
PSP过程
PSP不依赖于任何技术（语言、工具和设计方 法），它： 示范了软件过程原则； 帮助工程师做正确的计划； 告诉工程师怎样提高软件质量； 建立个人软件过程提升的度量标准； 确定过程改进在工程师表现中的影响。
PSP过程改进
PSP0（个人过程基线）
PSP0是过程基线，目的是为了在个人的工作 中引入表格和脚本，以便工程师按照测量和报 告格式记录软件过程。 PSP0-1.目前过程：记录软件工程师在工程 中使用的具有代表性的软件开发方法。 PSP0-2.时间记录：记录软件工程师在不同 的软件开发阶段（计划、设计、编码、编译 和测试、维护）所花费的时间。
CMMI评估的注意事项
-项目级文档 软件开发计划 软件质量保证计划 软件配臵管理计划 项目在实施中遵循的规程 测量计划 培训教材
CMMI评估的注意事项
-实现级文档 会议概要：评审会等 项目管理过程的状态报告：月度报告等 各类变更申请 测试记录 开发过程中产生的各类工作产品：设计文档， 源代码清单等。
PSP1（个人计划过程）
（3）资源估算：对于软件开发的一段生存期， 软件工程师预测所需要的软件、硬件和人力资 源，其中人力资源预测包括人力需求、人力成 本估算和项目管理标准。 PSP1-2.状态报告：对软件工程师的工作进行 跟踪，检查规模估计与实际状态之间的差异。
PSP1.1（个人计划过程）
PSP的使用效果
参加PSP培训的104位软件人员在应用了PSP后: 软件中总的差错数减少了58.0％； 在测试阶段发现的差错减少了71.9％； 生产效率提高了20.8％
PSP过程
PSP是一个软件过程的描述、测量和改进方法 的结构化集合，它可以为软件工程师带来更少 的错误代码、更好的预算和计划以及更高的生 产率，从而能够帮助软件工程师改善其个人性 能。 PSP提供了帮助软件工程师开发软件的表格、 脚本和标准，以估算和计划软件工程师的工作， 以便软件工程师可以更加清楚自己的个人技术 并且提升个人表现。PSP显示了如何定义过程 及如何测量其质量和生产率。
PSP2（个人质量管理）
PSP2强调提高质量，引入了缺陷管理。 PSP2-1.代码审查。对代码进行检查和分析， 以发现程序缺陷。 PSP2-2.设计审查。设计审查要求提供一些 评估设计质量的指标，如：代码重用率、代 码冗余、代码完整性和协作性。设计的一致 性检查主要涉及：结构化（控制和数据）一 致性、耦合一致性、可移植和互用一致性。
过程评估和能力评价步骤
现场调查：从响应分析的结果出发，评估小组 进行提问、检查、协商等，以获取专业性的结 论，说明软件过程的 KPA是否达到了应有的 目标。 评估小组提供一个定义软件过程优缺点的结果 清单。对于软件过程评估来说，这些结果将成 为过程改进的基础和参考； 对于软件能力评价 来说，这些结果为决策者提供风险分析的技术 基础。
软件过程评估方法
判断一个组织当前的软件过程的能力状态，并 发现过程中的缺陷。 判断并确定一个组织面对的与软件过程相关的 改进策略。 利用组织的支持来对该组织的软件过程进行有 效的改进。
软件能力评价方法
判断有意承担某个软件项目的软件组织（投标 者）的过程能力。 利用评价结果确定选择某一承包者的风险。 判断已进行的软件过程所处的状态是否正确或 是否正常。 推动承包者在工作过程中改进他们的软件过程。
影响CMMI过程改进成败的因素
过程改进必须有高级主管的支持与委托，并积 极地管理过程改进的进展。 获取中层管理的支持，以方便地获取过程改进 的资源（人员、时间、经费和设备）。 基层技术人员的参与和支持极端重要。 利用定量的可观察数据尽快使过程改进的成果 可见，从而激励参与者的兴趣。 按照软件过程改进对企业文化的要求进行变革， 要求软件过程改进为商业利益服务，并与企业 其他部分协调。
过程评估和能力评价步骤
挑选队伍：成员必须具有专业的软件工程和管 理方面的知识，并接受过基本CMM/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是一种可用于控制、管理和改进软件工程 师个人工作方式的自我改善过程，是一个包括 软件开发表格、指南和规程的结构化框架。
连续表示（Continuous Representation）支 持单个过程域的改进，可理解为一个过程域接 着一个过程域实施改进。在每个过程域上从能 力等级0到能力等级5逐级增加。
阶段表示和连续表示的对比
阶段表示是从CMM模型继承而来，已经过多 年的实践检验。它提供了一个明确的、被证实 的过程改进路径，遵循这条路径不需要过多的 讨论和争论。而且由于它的明确性和统一性， 有助于进行跨组织的比较。 连续表示的优点是提供了灵活性。用户可根据 具体的业务目标来选择需要实现的过程域及其 实现次序。
CMMI评估
成熟度等级的评估由美国卡内基梅隆大的软件 工程研究所授权的主任评估师领导一个评审小 组进行，其成员大部分来自企业内部。 评估过程包括员工培训（企业的高层领导也要 参加）、问卷填写和统计、文档审查、数据分 析、与企业的高层领导讨论和撰写评估报告等。 评估结束由主任评估师签字生效。 评估结果报告给SEI，但SEI不会发“认证”证 书。
PSP0.1（个人过程基线）
PSP0可以通过增加下列过程而扩展到 PSP0.1。 PSP0.1-1.代码规范：通过对设计过程、开 发过程和设计语言结构进行规范，约束具有 不同技术背景和软件开发风格的软件工程师。 由组织统一制订设计方法和编码标准。 PSP0.1-2.代码规模度量：测量代码的长度、 功能、复杂度、再利用数、冗余数等。一般 基于某种测量标准进行，如LOC，软件工程 师应该了解 LOC及相关测量概念。
CMMI评估的注意事项
确定范围 部门：哪些部门参加。 项目：选择合适的项目。 KPA：确定对那些KPA进行评估。 人数：为了保证评估取证有足够的可信度， 人数总和应该超过组织人数的20％。 约束 对不参加的部门，评估组无权进行访谈或取 证。
CMMI评估的注意事项
对不参加的人员，评估组无权进行访谈或取 证。 经费和预算不得超过某个限度。 进度安排应该在一个适当的期限内。 期望 要求评估师签署结论性证明文件。 要求评估组指明每个KPA的优缺点，哪些实 践有待改进。 要求评估组提出下一步过程改进的计划和大 致的日程安排。
PSP0.1（个人过程基线）
PSP0.1-3.过程优化计划：针对已经记录的软 件过程中的问题和经验教训，帮助软件工程师 给出软件过程能力的改进建议，并以结构化的 方式表达软件过程、问题、建议教训、改进建 议等项目。
PSP1（个人计划过程）
PSP1在PSP0的基础上增加了计划步骤： PSP1-1.规模估计：分为代码规模估算、时 间估算、资源估算。 （1）代码规模估算：软件工程师可以凭借 PSP0级代码规模测量经验预测他们将要写 的任务模块或算法的可能规模。 （2）时间估算：PSP0级时间测量过程可以 总结出不同复杂度模块的编写时间，凭借这 些经验，软件工程师可以针对当前系统的模 块结构层次给出完成每个模块的估算时间 （乐观时间、最可能时间、悲观时间）。
CMMI模型支持两种实施过程改进的方法，一 种称为阶段表示，一种称为连续表示。 阶段表示（Staged Representation）为过程 改进提供了一个预定义的路线图，即从成熟度 等级1到成熟度等级5逐级增加，要达到某一成 熟度等级，必须满足该等级（及其以下等级） 上所有过程域的目标。
实施CMMI过程改进的两种方法
软件项目管理
第六章 软件过程管理
本章内容提要
软件过程与过程管理 CMMI概述 CMMI的成熟度等级及其过程域 CMMI的应用 PSP，TSP与CMMI 敏捷软件开发方法
第四节 CMMI的应用
实施CMMI过程改进的两种方法 阶段表示 连续表示
CMMI评估
实施CMMI过程改进的两种方法
过程评估和能力评价步骤
评估小组完成KPA基本概况的描述文件，给出 组织已经满足的KPA目标和尚未满足的KPA目 标。
软件过程评估和软件能力评价之间的不同
软件过程评估和软件能力评价的结果可能不同 （主要是因为评估和评价的侧重点不一样，而 且被评估和被评价的组织、项目、软件产品都 会发生变化，因此，应该考虑评估和评价的 Context）。 软件过程评估和软件能力评价在出发点和目标 上是不同的（导致成熟度提问单的内容组织不 一样，收集的信息不一样，结论的评价不一 样）。
PSP1.1在PSP1的基础上引入了任务计划和安 排。 PSP1.1-1.任务计划及安排：基于PSP1中的 规模估计数据制订软件项目的需要完成的任 务计划，并将任务按时间段分配给不同的人 力资源。一般采纳网络安排技术，如 PERT(Program Evaluation and Review Techniques)和CPM(Critical Path Method)，软件工程师应该理解网络安排技 术和计划策略。
PSP0（个人过程基线）
PSP0-3.失误记录：按照一致的格式记录软 件工程师引入软件中的缺陷，并记录软件工 程师尝试解决问题的方法和步骤。 PSP0-4.错误分类标准：一方面为软件工程 师提供在系统中可观察到的典型缺陷种类列 表，有助于软件工程师把典型缺陷标准化； 另一方面提供一种预定义的步骤和工具方便 软件工程师对新的缺陷进行归类和记录。
PSP关注点
如何制订计划 如何控制质量 如何与其他人相互协作 如何预防缺陷(PSP重点)
关键是如何提高设计质量
PSP中的个人任务
为每一个项目/模块制订开发计划； 记录开发时间； 跟踪错误； 在工程摘要报表中保留数据； 使用已有的数据计划以后的项目/模块； 分析已有的数据以改进开发过程，不断提高开 发水平。
CMMI评估的注意事项
承诺 组织主管保证参加评估的人员不会影响评估 活动的正常进展。 保证为评估工作提供相应的后勤服务。 向评估组授权“开工令”（从某日起开始工 作）。
CMMI评估的注意事项
准备待审文档 -组织级文档 软件生存期模型 研发过程的各种方针 项目遵循的规程 选用的标准 裁剪指南 标准报表 标准测量集
CMMI评估
一般有两种类型的评估：软件过程评估和软件 能力评价。 软件过程评估用于确定机构当前过程的状态， 决定一个机构所面临的高优先级的过程相关问 题，并且获得机构对软件过程改进的支持。 软件能力评价用来确定合格的软件项目承制方， 或用来监督在目前的软件项目中正在进行软件 过程的状态。
软件过程评估和软件能力评价之间的不同
ຫໍສະໝຸດ Baidu
软件过程评估是在一个开放的、互相协作的环 境下进行的。而软件能力评价往往是在有较大 阻力的环境中进行的。（过程评估是为了提高 管理者和工程师的工作水平，而能力评价是为 了表明一个软件组织的实际软件过程能力，为 选择承包者和减少费用服务）。
CMMI评估的注意事项
PSP过程
PSP不依赖于任何技术（语言、工具和设计方 法），它： 示范了软件过程原则； 帮助工程师做正确的计划； 告诉工程师怎样提高软件质量； 建立个人软件过程提升的度量标准； 确定过程改进在工程师表现中的影响。
PSP过程改进
PSP0（个人过程基线）
PSP0是过程基线，目的是为了在个人的工作 中引入表格和脚本，以便工程师按照测量和报 告格式记录软件过程。 PSP0-1.目前过程：记录软件工程师在工程 中使用的具有代表性的软件开发方法。 PSP0-2.时间记录：记录软件工程师在不同 的软件开发阶段（计划、设计、编码、编译 和测试、维护）所花费的时间。
CMMI评估的注意事项
-项目级文档 软件开发计划 软件质量保证计划 软件配臵管理计划 项目在实施中遵循的规程 测量计划 培训教材
CMMI评估的注意事项
-实现级文档 会议概要：评审会等 项目管理过程的状态报告：月度报告等 各类变更申请 测试记录 开发过程中产生的各类工作产品：设计文档， 源代码清单等。
PSP1（个人计划过程）
（3）资源估算：对于软件开发的一段生存期， 软件工程师预测所需要的软件、硬件和人力资 源，其中人力资源预测包括人力需求、人力成 本估算和项目管理标准。 PSP1-2.状态报告：对软件工程师的工作进行 跟踪，检查规模估计与实际状态之间的差异。
PSP1.1（个人计划过程）
PSP的使用效果
参加PSP培训的104位软件人员在应用了PSP后: 软件中总的差错数减少了58.0％； 在测试阶段发现的差错减少了71.9％； 生产效率提高了20.8％
PSP过程
PSP是一个软件过程的描述、测量和改进方法 的结构化集合，它可以为软件工程师带来更少 的错误代码、更好的预算和计划以及更高的生 产率，从而能够帮助软件工程师改善其个人性 能。 PSP提供了帮助软件工程师开发软件的表格、 脚本和标准，以估算和计划软件工程师的工作， 以便软件工程师可以更加清楚自己的个人技术 并且提升个人表现。PSP显示了如何定义过程 及如何测量其质量和生产率。
PSP2（个人质量管理）
PSP2强调提高质量，引入了缺陷管理。 PSP2-1.代码审查。对代码进行检查和分析， 以发现程序缺陷。 PSP2-2.设计审查。设计审查要求提供一些 评估设计质量的指标，如：代码重用率、代 码冗余、代码完整性和协作性。设计的一致 性检查主要涉及：结构化（控制和数据）一 致性、耦合一致性、可移植和互用一致性。
过程评估和能力评价步骤
现场调查：从响应分析的结果出发，评估小组 进行提问、检查、协商等，以获取专业性的结 论，说明软件过程的 KPA是否达到了应有的 目标。 评估小组提供一个定义软件过程优缺点的结果 清单。对于软件过程评估来说，这些结果将成 为过程改进的基础和参考； 对于软件能力评价 来说，这些结果为决策者提供风险分析的技术 基础。
软件过程评估方法
判断一个组织当前的软件过程的能力状态，并 发现过程中的缺陷。 判断并确定一个组织面对的与软件过程相关的 改进策略。 利用组织的支持来对该组织的软件过程进行有 效的改进。
软件能力评价方法
判断有意承担某个软件项目的软件组织（投标 者）的过程能力。 利用评价结果确定选择某一承包者的风险。 判断已进行的软件过程所处的状态是否正确或 是否正常。 推动承包者在工作过程中改进他们的软件过程。
影响CMMI过程改进成败的因素
过程改进必须有高级主管的支持与委托，并积 极地管理过程改进的进展。 获取中层管理的支持，以方便地获取过程改进 的资源（人员、时间、经费和设备）。 基层技术人员的参与和支持极端重要。 利用定量的可观察数据尽快使过程改进的成果 可见，从而激励参与者的兴趣。 按照软件过程改进对企业文化的要求进行变革， 要求软件过程改进为商业利益服务，并与企业 其他部分协调。
过程评估和能力评价步骤
挑选队伍：成员必须具有专业的软件工程和管 理方面的知识，并接受过基本CMM/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是一种可用于控制、管理和改进软件工程 师个人工作方式的自我改善过程，是一个包括 软件开发表格、指南和规程的结构化框架。
连续表示（Continuous Representation）支 持单个过程域的改进，可理解为一个过程域接 着一个过程域实施改进。在每个过程域上从能 力等级0到能力等级5逐级增加。
阶段表示和连续表示的对比
阶段表示是从CMM模型继承而来，已经过多 年的实践检验。它提供了一个明确的、被证实 的过程改进路径，遵循这条路径不需要过多的 讨论和争论。而且由于它的明确性和统一性， 有助于进行跨组织的比较。 连续表示的优点是提供了灵活性。用户可根据 具体的业务目标来选择需要实现的过程域及其 实现次序。
CMMI评估
成熟度等级的评估由美国卡内基梅隆大的软件 工程研究所授权的主任评估师领导一个评审小 组进行，其成员大部分来自企业内部。 评估过程包括员工培训（企业的高层领导也要 参加）、问卷填写和统计、文档审查、数据分 析、与企业的高层领导讨论和撰写评估报告等。 评估结束由主任评估师签字生效。 评估结果报告给SEI，但SEI不会发“认证”证 书。
PSP0.1（个人过程基线）
PSP0可以通过增加下列过程而扩展到 PSP0.1。 PSP0.1-1.代码规范：通过对设计过程、开 发过程和设计语言结构进行规范，约束具有 不同技术背景和软件开发风格的软件工程师。 由组织统一制订设计方法和编码标准。 PSP0.1-2.代码规模度量：测量代码的长度、 功能、复杂度、再利用数、冗余数等。一般 基于某种测量标准进行，如LOC，软件工程 师应该了解 LOC及相关测量概念。
CMMI评估的注意事项
确定范围 部门：哪些部门参加。 项目：选择合适的项目。 KPA：确定对那些KPA进行评估。 人数：为了保证评估取证有足够的可信度， 人数总和应该超过组织人数的20％。 约束 对不参加的部门，评估组无权进行访谈或取 证。
CMMI评估的注意事项
对不参加的人员，评估组无权进行访谈或取 证。 经费和预算不得超过某个限度。 进度安排应该在一个适当的期限内。 期望 要求评估师签署结论性证明文件。 要求评估组指明每个KPA的优缺点，哪些实 践有待改进。 要求评估组提出下一步过程改进的计划和大 致的日程安排。
PSP0.1（个人过程基线）
PSP0.1-3.过程优化计划：针对已经记录的软 件过程中的问题和经验教训，帮助软件工程师 给出软件过程能力的改进建议，并以结构化的 方式表达软件过程、问题、建议教训、改进建 议等项目。
PSP1（个人计划过程）
PSP1在PSP0的基础上增加了计划步骤： PSP1-1.规模估计：分为代码规模估算、时 间估算、资源估算。 （1）代码规模估算：软件工程师可以凭借 PSP0级代码规模测量经验预测他们将要写 的任务模块或算法的可能规模。 （2）时间估算：PSP0级时间测量过程可以 总结出不同复杂度模块的编写时间，凭借这 些经验，软件工程师可以针对当前系统的模 块结构层次给出完成每个模块的估算时间 （乐观时间、最可能时间、悲观时间）。
CMMI模型支持两种实施过程改进的方法，一 种称为阶段表示，一种称为连续表示。 阶段表示（Staged Representation）为过程 改进提供了一个预定义的路线图，即从成熟度 等级1到成熟度等级5逐级增加，要达到某一成 熟度等级，必须满足该等级（及其以下等级） 上所有过程域的目标。
实施CMMI过程改进的两种方法
软件项目管理
第六章 软件过程管理
本章内容提要
软件过程与过程管理 CMMI概述 CMMI的成熟度等级及其过程域 CMMI的应用 PSP，TSP与CMMI 敏捷软件开发方法
第四节 CMMI的应用
实施CMMI过程改进的两种方法 阶段表示 连续表示
CMMI评估
实施CMMI过程改进的两种方法
过程评估和能力评价步骤
评估小组完成KPA基本概况的描述文件，给出 组织已经满足的KPA目标和尚未满足的KPA目 标。
软件过程评估和软件能力评价之间的不同
软件过程评估和软件能力评价的结果可能不同 （主要是因为评估和评价的侧重点不一样，而 且被评估和被评价的组织、项目、软件产品都 会发生变化，因此，应该考虑评估和评价的 Context）。 软件过程评估和软件能力评价在出发点和目标 上是不同的（导致成熟度提问单的内容组织不 一样，收集的信息不一样，结论的评价不一 样）。
PSP1.1在PSP1的基础上引入了任务计划和安 排。 PSP1.1-1.任务计划及安排：基于PSP1中的 规模估计数据制订软件项目的需要完成的任 务计划，并将任务按时间段分配给不同的人 力资源。一般采纳网络安排技术，如 PERT(Program Evaluation and Review Techniques)和CPM(Critical Path Method)，软件工程师应该理解网络安排技 术和计划策略。
PSP0（个人过程基线）
PSP0-3.失误记录：按照一致的格式记录软 件工程师引入软件中的缺陷，并记录软件工 程师尝试解决问题的方法和步骤。 PSP0-4.错误分类标准：一方面为软件工程 师提供在系统中可观察到的典型缺陷种类列 表，有助于软件工程师把典型缺陷标准化； 另一方面提供一种预定义的步骤和工具方便 软件工程师对新的缺陷进行归类和记录。
PSP关注点
如何制订计划 如何控制质量 如何与其他人相互协作 如何预防缺陷(PSP重点)
关键是如何提高设计质量
PSP中的个人任务
为每一个项目/模块制订开发计划； 记录开发时间； 跟踪错误； 在工程摘要报表中保留数据； 使用已有的数据计划以后的项目/模块； 分析已有的数据以改进开发过程，不断提高开 发水平。
CMMI评估的注意事项
承诺 组织主管保证参加评估的人员不会影响评估 活动的正常进展。 保证为评估工作提供相应的后勤服务。 向评估组授权“开工令”（从某日起开始工 作）。
CMMI评估的注意事项
准备待审文档 -组织级文档 软件生存期模型 研发过程的各种方针 项目遵循的规程 选用的标准 裁剪指南 标准报表 标准测量集
CMMI评估
一般有两种类型的评估：软件过程评估和软件 能力评价。 软件过程评估用于确定机构当前过程的状态， 决定一个机构所面临的高优先级的过程相关问 题，并且获得机构对软件过程改进的支持。 软件能力评价用来确定合格的软件项目承制方， 或用来监督在目前的软件项目中正在进行软件 过程的状态。