软件项目管理培训课程之软件过程管理
软件过程与管理
风险的不利性
风险的可变性
风险的相对性
风险同利益的对称性
风险分类——参与者、技术、结构、任务
风险管理框架——
软件项目常见十大风险——
德尔菲法（Delphi method），是采用背对背的通信方式征询专家小组成员的预测意见，经过几轮征询，使专家小组的预测意见趋于集中，最后做出最终的预测
风险影响= (可能的危害)×(发生概率)
风险定义——
一个不确定的事件或者情况，若其一旦发生，会对项目的目标，例如，范围、进度、成本和质量，产生积极或消极的影响。
风险是未来可能发生的问题，而不是当前已经发生的事情
风险的产生一般是有原因的，例如，开发人员离职导致项目延期
风险的三要素——
事件
事件发生的概率
事件的影响
风险的基本性质——
风险的客观性
内部和外部质量(internal and external quality)
功能性，可靠性，有效性，可维护性，可移植性，和可使用性
使用质量(quality-in-use)
有效性，生产率，安全和满意度
有效性：软件产品在指定使用环境下，使用户准确、完整地获得规定目标的能力；
生产率：软件产品在指定使用环境下，使用户花费合适的与有效性相关的资源数量的能力；
项目庞大或复杂
项目管理(PM)就是在项目活动中运用相关知识,技能,工具和技术满足项目的要求。
项目管理的十大知识领域——
项目集成管理、项目范围管理、项目时间管理、项目成本管理、项目质量管理
项目人力资源管理、项目沟通管理、项目风险管理、项目采购管理、项目利益相关者管理
项目管理的五个过程组——启动、计划、过程、控制、收尾
软件产品目标的三要素：
软件过程管理 (10)
chapter_9
பைடு நூலகம்
57
小结
配置管理的基本概念
配置项 基线 sccb
配置管理过程， 配置管理计划的基本内容
chapter_9
58
3.
制定规则和（配置管理）工具：实现配置管 理1. 2.
3.
大企业，大项目 异地开发模式 配备专门的配置管理人员
chapter_9 55
本章要点
一、软件项目配置管理基本概念 二、软件项目配置管理过程 三、软件项目配置管理计划 四、案例分析
chapter_9
56
案例分析
School项目案例说明：
配置管理计划
chapter_9 53
常用配置管理的工具
1. 2. 3. 4. 5.
ClearCase&ClearQuest PVCS Harvest CVS VSS
chapter_9
54
配置管理建议
1.
制定规则：实现版本管理
1.
小企业，小项目
2.
制定规则和（版本管理）工具：实现部分配 置管理
1.
中小企业，中小项目
决策
（若批准）
（若批准）
（若批准）
（若批准）
实施变更
验证变更
发布、 安装变 更
版本更新
chapter_9
39
SCCB对变更做出决策
直接实现变更 挂起或者延迟变更 拒绝变更（应通知变更请求人，并且保存所有 的相关记录）
n n n
chapter_9
40
变更接受时，实现进度形式
尽可能快地实现变更：期望的变更是修改开发 基线中的一个配置项，只有解决这个变更，其 他工作才能展开。 按照一个特定的日期实现变更：确定合适的日 期实现变更。 在另外的版本中实现，出于技术或者运行等原 因，期望与另外的变更一起发布。
软件过程管理
软件过程管理总结报告要求：①字数不少于1200字；②内容包括：涵盖课程的重要性、通过本门课程的开设都学到了哪些知识、有哪些感悟等方面。
正文：软件过程管理为快速地开发高质量软件、有效地维护软件运行等软件工程实施提供了指导性框架、实施方法和最佳实践方案。
软件过程管理体现在过程模型、规范、问题处理方法和具体实践等一系列内容之上，但首先体现在组织文化中，即建立过程管理的先进理念。
——（1）以客户为导向、以过程为中心。
（2）好的过程就能产生好的产品。
（3）尊重流程。
自上而下，依赖流程。
（4）只关注质量过程而不是质量结果。
软件过程管理一旦在组织中建立起来，其他问题就迎刃而解。
而且，软件过程管理的关键是建立正确的过程管理文化。
随着时代的发展，新的技术不断更新，新软件商业模式和开发模式不断变化。
所以，软件过程管理模式也应该是在不断发展的，就每个具体的软件组织和企业，应该选择适合自己的模式，而是选择多种模式，以一种模式为主，对其它模式兼收并蓄，形成更有效的软件过程自定义模式。
软件项目管理过程是对软件项目过程经行计划、监控/管理、总结的辅助过程，包括需求、配置、成本、进度、质量和风险等的管理。
软件开发过程是软件过程中的基本过程，负责开发和定义用户需求，设计、构建和测试满足这些需求的软件并最终将其交付给客户的过程。
目前常用的软件过程模型主要有：迭代模型、V模型、原型模型和螺旋模型等。
根据公司的业务模式、项目特点和团队能力等实际因素，决定选择基于迭代模型的RUP过程模型，进行合理的剪裁和修改，使其成为公司自定义的软件开发过程。
而且，在开发过程中，阶段的划分并不是把各项工作各路开来，而是工作焦点的转移，正如RUP所描述的，需求分析、测试等工作贯穿整个软件生命周期，例如在项目立项之前有许多需求沟通的工作，在架构设计、测试阶段和维护阶段，需求可能发生变化，需要继续开发需求和定义需求。
通过《软件过程管理》的学习，我们知道软件过程就是人们用来开发和维护软件和相关文档以及相关产品的活动、方法、实践和变革的集合。
软件过程管理 (4)
用户测试 运行原型
chapter__3
32
原型开发过程
建立原 型目标
定义原 型功能
开发 原型
评估 原型
原型规划
框架ห้องสมุดไป่ตู้义
可执行原型
评估报告
chapter__3
33
原型模型分类
原型是项目系统中的一个方面或者多个方 面的工作模型。 l 抛弃型原型：用于试验某些概念，试 验完系统将无用处 l 进化型原型：原型系统不断被开发和 被修正，最终它变为一个真正的系统。
当你对一个定义得很好的版本进行维护或将一个产品移植到一 个新的平台上，可以采用瀑布模型。 在质量需求高于成本需求和进度需求的时候，可以采用瀑布模 型。
n
n
chapter__3
24
瀑布模型的缺陷
n
n n
n
n
在项目开始的时候，用户常常难以清楚地给出所有需求；用户与 开发人员对需求理解存在差异。 很少软件项目按照顺序模型进行，不能很好地支持迭代。 缺乏灵活性，因为瀑布模型确定了需求分析的绝对重要性，但是 在实践中要想获得完善的需求说明是非常困难的，导致“阻塞状 态”。反馈信息慢，开发周期长。 只有到了整个项目的后半段时间，客户才能看到软件的模样。一 个没有及时发现的错误，可能导致灾难。 虽然存在不少缺陷，瀑布模型经常被嘲笑为“旧式的”，但是在 需求被很好地理解的情况下，仍然是一种合理的方法。
一、生存期模型定义 二、常用生存期模型 三、案例分析
chapter__3
3
建筑工程类项目典型生存期模型
chapter__3
4
制药项目典型生存期模型
chapter__3
5
生存期模型选择
软件过程管理
软件过程管理引言：随着科技的不断发展，软件在各行各业中的应用越来越广泛，因此软件过程管理也变得越来越重要。
软件过程管理是指对软件生命周期中的各个阶段、活动、流程进行规划、组织、控制和评估的过程。
本文将讨论软件过程管理的重要性、过程管理的基本原则和主要方法，并探讨软件过程管理在提高软件开发效率和质量方面的作用。
一、软件过程管理的重要性1. 提高软件开发效率软件过程管理可以帮助团队建立科学、规范的开发流程，合理分配资源，提高工作效率。
通过合理的过程管理，可以确保软件开发过程中的任务分配、协作、沟通等方面的顺利进行，避免重复工作，减少资源的浪费，提高软件开发速度。
2. 提高软件开发质量通过软件过程管理，可以确保软件开发过程中的每一个环节都得到合理的控制和管理，从而提高软件开发质量。
合理的过程管理可以确保测试、评估、修复等流程的顺利进行，避免潜在的bug和错误，提高软件的稳定性、性能和可靠性。
3. 降低软件开发风险软件过程管理可以帮助团队在软件开发过程中及时发现和解决问题，降低项目风险。
通过项目管理、风险评估和控制等方法，可以及时解决软件开发过程中的各种问题，减少项目的失败风险，保证软件开发进度和成果的可控性。
二、软件过程管理的基本原则1. 适应性原则软件过程管理应根据不同的项目、团队和环境，采用不同的管理方法和工具。
过程管理应能够适应不同的需求和情况，灵活地调整和优化管理流程。
2. 参与性原则软件过程管理需要全员参与，尤其是开发团队成员。
只有通过团队协作和全员的参与，才能确保软件开发过程的顺利进行和优化。
3. 持续改进原则软件过程管理应持续改进和优化。
通过收集和分析软件开发过程的数据和指标，及时发现问题和改进的空间，并采取相应的措施进行改善，以提高软件开发效率和质量。
三、软件过程管理的主要方法1. 项目管理项目管理是软件过程管理的核心方法之一。
通过项目管理，可以规划、组织、控制和评估软件开发项目的全过程。
软件项目管理课程PPT113页
计算程序控制结构的V(G)值
E = 4 E = 3 N = 4 N = 3 V = 2 V = 2
计算程序控制结构的V(G)值
E = 6 N = 5 V = 3
例3.1 计算如图所示程序控制结构图的V(G)值。 (a) e=1,n=2,v=1; (b) e=3,n=3,v=2; (c) e=4,n=4,v=2； (d) e=3,n=3,v=2; (e) e=6,n=5,v=3.
过程的内部属性 工作量 计划和进度 一段时间内某类事件发生的次数 过程的外部属性 成本 可控制性 可观察性 稳定性 资源的内部属性 人 软硬件环境 方法 经验 资源的外部属性 成本 时间
3.1.1.2 面向规模的度量
代码行数 LOC或KLOC 生产率 Pl=L/E 其中 L 软件项目代码行数 E 软件项目工作量（人月 PM） Pl 软件项目生产率（LOC/PM） 代码出错率 EQRl=Ne/L 其中 Ne 软件项目的代码错误数 EQRl 每千行代码的错误数
每行代码平均成本 Cl=S/L 其中 S 软件项目总开销（元／美元） Cl软件项目每行代码的平均成本 文档与代码比 Dl=Pd/L 其中 Pd 软件项目文档页数 Dl 每千行代码的平均文档数
软件的外部属性和内部属性 外部属性 软件产品、过程、资源与环境的关系 如，成本、效益、劳动生产率、可靠性、可维护性 内部属性 软件产品、过程、资源、环境自身的属性 如，产品结构、模块化程度、复杂性、程序长度等。
产品-过程-资源
产品的内部属性 程序代码长度 程序功能 模块化 重用性 控制流 数据流 模块耦合度与内聚度 产品的外部属性 程序的可靠性 可用性 可维护性 软件的可理解性 有效性 可移植性
例3.1计算程序控制结构的V(G)值
培训课件软件过程的管理与改进ppt
质量管理工具
MantisBT
01
提供缺陷跟踪和管理功能，确保软件质量。
SonarQube
02
进行代码质量检查和自动化测试，提高代码质量和减少缺陷。
Quality Center
03
提供测试计划、测试用例和测试执行管理功能，确保软件质量
。
风险管理工具
1 2
对每个模块进行单元测试，确保模 块功能正常。
集成测试
将各模块集成在一起进行测试，确 保整个系统运行正常。
测试阶段
功能测试
对课件的各项功能进行测试，确 保满足需求规格说明书的要求。
性能测试
测试课件在不同负载下的性能表 现，确保系统能够承受实际运行
的压力。
安全测试
检测课件的安全漏洞，确保用户 数据和隐私的安全。
在此添加您的文本16字
4. 灵活调整：根据用户反馈和市场变化，灵活调整开发 计划和内容，保持软件竞争力。
最佳实践二
总结词：DevOps是一种集开发与运维于一体的软件交 付方法，适用于需要快速迭代和持续优化的培训课件软 件开发。 1. 自动化部署：通过自动化工具实现软件的自动化部署 和升级，减少人工干预和错误。
降低培训成本
通过有效的管理和改进， 可以降低培训课件的制作 成本和时间成本。
提升组织竞争力
优质的培训课件能够提升 组织的整体素质和竞争力 。
培训课件软件过程的历史与发展
历史回顾
从早期的简单PPT课件到现在的交互 式多媒体课件，培训课件软件过程经 历了多个阶段的发展。
发展趋势
随着数字化、网络化和智能化的快速 发展，未来的培训课件软件过程将更 加注重个性化和智能化。
软件过程与项目管理
软件过程与项目管理在信息技术快速发展的时代，软件开发已成为各行各业不可或缺的一部分。
为了高效地完成软件开发项目，软件过程和项目管理成为至关重要的环节。
本文将介绍软件过程与项目管理的基本概念和作用，以及它们在软件开发中的应用。
一、软件过程概述软件过程是指按照一定的方法和规范进行软件开发和维护的一系列活动。
它涵盖了需求分析、设计、编码、测试、部署和维护等环节。
软件过程的目标是确保软件项目按时、按质、按成本完成，同时满足用户的需求和期望。
软件过程包含了几个重要的概念，例如软件生命周期、开发模型和软件度量等。
软件生命周期描述了软件项目从概念到废弃的全过程，包括需求分析、设计开发、系统测试、运行维护等不同阶段。
开发模型是按照一定的规则组织和进行软件开发的方法，常见的开发模型包括瀑布模型、迭代模型和敏捷开发等。
软件度量则是通过定量的指标来评估软件开发过程和产品的质量，以便进行改进和优化。
二、项目管理概述项目管理是一种规范和有序地组织和管理项目活动的方法。
它涉及项目计划、进度控制、资源管理、风险管理等方面。
项目管理的核心是在给定的时间、成本和质量目标下，合理分配和利用资源，确保项目按预期目标进行。
项目管理包括项目计划、项目执行、项目控制和项目收尾几个主要阶段。
项目计划阶段主要确定项目的目标和范围，制定详细的项目计划和进度安排。
项目执行阶段是根据项目计划组织和分配工作，进行具体的任务执行。
项目控制阶段则是对项目进行监控和调整，确保项目不偏离原定目标。
项目收尾阶段包括项目验收、总结和交接等活动，以使项目圆满结束。
三、软件过程与项目管理的关系软件过程和项目管理相辅相成，二者相互依赖，共同为软件开发项目的顺利进行提供保障。
首先，软件过程是实施项目管理的基础。
项目管理需要有明确的目标和规划，而软件过程为项目管理提供了规范和方法。
通过定义和执行软件过程，项目管理可以更好地掌握软件开发的全过程，准确把握项目的进度和质量。
其次，项目管理促进软件过程的持续改进。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件过程评估和软件能力评价之间的不同
软件过程评估是在一个开放的、互相协作的环 境下进行的。而软件能力评价往往是在有较大 阻力的环境中进行的。（过程评估是为了提高 管理者和工程师的工作水平，而能力评价是为 了表明一个软件组织的实际软件过程能力，为 选择承包者和减少费用服务）。
CMMI评估的注意事项
PSP过程
PSP不依赖于任何技术（语言、工具和设计方 法），它： 示范了软件过程原则； 帮助工程师做正确的计划； 告诉工程师怎样提高软件质量； 建立个人软件过程提升的度量标准； 确定过程改进在工程师表现中的影响。
PSP过程改进
PSP0（个人过程基线）
PSP0是过程基线，目的是为了在个人的工作 中引入表格和脚本，以便工程师按照测量和报 告格式记录软件过程。 PSP0-1.目前过程：记录软件工程师在工程 中使用的具有代表性的软件开发方法。 PSP0-2.时间记录：记录软件工程师在不同 的软件开发阶段（计划、设计、编码、编译 和测试、维护）所花费的时间。
软件过程评估方法
判断一个组织当前的软件过程的能力状态，并 发现过程中的缺陷。 判断并确定一个组织面对的与软件过程相关的 改进策略。 利用组织的支持来对该组织的软件过程进行有 效的改进。
软件能力评价方法
判断有意承担某个软件项目的软件组织（投标 者）的过程能力。 利用评价结果确定选择某一承包者的风险。 判断已进行的软件过程所处的状态是否正确或 是否正常。 推动承包者在工作过程中改进他们的软件过程。
第五节 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模型继承而来，已经过多 年的实践检验。它提供了一个明确的、被证实 的过程改进路径，遵循这条路径不需要过多的 讨论和争论。而且由于它的明确性和统一性， 有助于进行跨组织的比较。 连续表示的优点是提供了灵活性。用户可根据 具体的业务目标来选择需要实现的过程域及其 实现次序。
PSP关注点
如何制订计划 如何控制质量 如何与其他人相互协作 如何预防缺陷(PSP重点)
关键是如何提高设计质量
PSP中的个人任务
பைடு நூலகம்
为每一个项目/模块制订开发计划； 记录开发时间； 跟踪错误； 在工程摘要报表中保留数据； 使用已有的数据计划以后的项目/模块； 分析已有的数据以改进开发过程，不断提高开 发水平。
过程评估和能力评价步骤
评估小组完成KPA基本概况的描述文件，给出 组织已经满足的KPA目标和尚未满足的KPA目 标。
软件过程评估和软件能力评价之间的不同
软件过程评估和软件能力评价的结果可能不同 （主要是因为评估和评价的侧重点不一样，而 且被评估和被评价的组织、项目、软件产品都 会发生变化，因此，应该考虑评估和评价的 Context）。 软件过程评估和软件能力评价在出发点和目标 上是不同的（导致成熟度提问单的内容组织不 一样，收集的信息不一样，结论的评价不一 样）。
PSP0.1（个人过程基线）
PSP0.1-3.过程优化计划：针对已经记录的软 件过程中的问题和经验教训，帮助软件工程师 给出软件过程能力的改进建议，并以结构化的 方式表达软件过程、问题、建议教训、改进建 议等项目。
PSP1（个人计划过程）
PSP1在PSP0的基础上增加了计划步骤： PSP1-1.规模估计：分为代码规模估算、时 间估算、资源估算。 （1）代码规模估算：软件工程师可以凭借 PSP0级代码规模测量经验预测他们将要写 的任务模块或算法的可能规模。 （2）时间估算：PSP0级时间测量过程可以 总结出不同复杂度模块的编写时间，凭借这 些经验，软件工程师可以针对当前系统的模 块结构层次给出完成每个模块的估算时间 （乐观时间、最可能时间、悲观时间）。
CMMI评估的注意事项
确定范围 部门：哪些部门参加。 项目：选择合适的项目。 KPA：确定对那些KPA进行评估。 人数：为了保证评估取证有足够的可信度， 人数总和应该超过组织人数的20％。 约束 对不参加的部门，评估组无权进行访谈或取 证。
CMMI评估的注意事项
对不参加的人员，评估组无权进行访谈或取 证。 经费和预算不得超过某个限度。 进度安排应该在一个适当的期限内。 期望 要求评估师签署结论性证明文件。 要求评估组指明每个KPA的优缺点，哪些实 践有待改进。 要求评估组提出下一步过程改进的计划和大 致的日程安排。
PSP2（个人质量管理）
PSP2强调提高质量，引入了缺陷管理。 PSP2-1.代码审查。对代码进行检查和分析， 以发现程序缺陷。 PSP2-2.设计审查。设计审查要求提供一些 评估设计质量的指标，如：代码重用率、代 码冗余、代码完整性和协作性。设计的一致 性检查主要涉及：结构化（控制和数据）一 致性、耦合一致性、可移植和互用一致性。
PSP的使用效果
参加PSP培训的104位软件人员在应用了PSP后: 软件中总的差错数减少了58.0％； 在测试阶段发现的差错减少了71.9％； 生产效率提高了20.8％
PSP过程
PSP是一个软件过程的描述、测量和改进方法 的结构化集合，它可以为软件工程师带来更少 的错误代码、更好的预算和计划以及更高的生 产率，从而能够帮助软件工程师改善其个人性 能。 PSP提供了帮助软件工程师开发软件的表格、 脚本和标准，以估算和计划软件工程师的工作， 以便软件工程师可以更加清楚自己的个人技术 并且提升个人表现。PSP显示了如何定义过程 及如何测量其质量和生产率。
CMMI评估的注意事项
-项目级文档 软件开发计划 软件质量保证计划 软件配臵管理计划 项目在实施中遵循的规程 测量计划 培训教材
CMMI评估的注意事项
-实现级文档 会议概要：评审会等 项目管理过程的状态报告：月度报告等 各类变更申请 测试记录 开发过程中产生的各类工作产品：设计文档， 源代码清单等。
过程评估和能力评价步骤
现场调查：从响应分析的结果出发，评估小组 进行提问、检查、协商等，以获取专业性的结 论，说明软件过程的 KPA是否达到了应有的 目标。 评估小组提供一个定义软件过程优缺点的结果 清单。对于软件过程评估来说，这些结果将成 为过程改进的基础和参考； 对于软件能力评价 来说，这些结果为决策者提供风险分析的技术 基础。
PSP1.1在PSP1的基础上引入了任务计划和安 排。 PSP1.1-1.任务计划及安排：基于PSP1中的 规模估计数据制订软件项目的需要完成的任 务计划，并将任务按时间段分配给不同的人 力资源。一般采纳网络安排技术，如 PERT(Program Evaluation and Review Techniques)和CPM(Critical Path Method)，软件工程师应该理解网络安排技 术和计划策略。
过程评估和能力评价步骤
挑选队伍：成员必须具有专业的软件工程和管 理方面的知识，并接受过基本CMM/CMMI概 念和特定评估及评价方法的训练。 问卷调查：让来自被评估单位的代表完成软件 过程成熟度问卷并回答评估评价组提出的诊断 性问题。 响应分析：明确哪些回答与问题的答案相吻合， 并确定须进一步调查的领域。
CMMI评估的注意事项
承诺 组织主管保证参加评估的人员不会影响评估 活动的正常进展。 保证为评估工作提供相应的后勤服务。 向评估组授权“开工令”（从某日起开始工 作）。
CMMI评估的注意事项
准备待审文档 -组织级文档 软件生存期模型 研发过程的各种方针 项目遵循的规程 选用的标准 裁剪指南 标准报表 标准测量集
PSP0（个人过程基线）
PSP0-3.失误记录：按照一致的格式记录软 件工程师引入软件中的缺陷，并记录软件工 程师尝试解决问题的方法和步骤。 PSP0-4.错误分类标准：一方面为软件工程 师提供在系统中可观察到的典型缺陷种类列 表，有助于软件工程师把典型缺陷标准化； 另一方面提供一种预定义的步骤和工具方便 软件工程师对新的缺陷进行归类和记录。
PSP1（个人计划过程）
（3）资源估算：对于软件开发的一段生存期， 软件工程师预测所需要的软件、硬件和人力资 源，其中人力资源预测包括人力需求、人力成 本估算和项目管理标准。 PSP1-2.状态报告：对软件工程师的工作进行 跟踪，检查规模估计与实际状态之间的差异。
PSP1.1（个人计划过程）
CMMI评估
一般有两种类型的评估：软件过程评估和软件 能力评价。 软件过程评估用于确定机构当前过程的状态， 决定一个机构所面临的高优先级的过程相关问 题，并且获得机构对软件过程改进的支持。 软件能力评价用来确定合格的软件项目承制方， 或用来监督在目前的软件项目中正在进行软件 过程的状态。
筹备必备机构 SEPG：负责过程的定义和策划。 SQA：负责审核软件过程的实施情况；产品 质量的审核和控制。 确定合适的目标 对指定的KPA作评估或诊断，2级时也可要 求对3级的KPA进行评估。 有些组织一开始可能并不想进行评分和评级， 而是希望评估组从其现有的实践中确定最佳 实践，作为组织的标准实践进行推广。