《{项目管理项目报告}过程和项目度量概述PPT62页》由会员分享，可在线阅读，更多相关《{项目管理项目报告}过程和项目度量概述PPT62页（62页珍藏版）》请在金锄头文库上搜索。
1、Software Project Management,第2 讲 过程和项目度量,主讲：张纲强,过程领域和项目领域中的度量,主要内容,软件测量,软件质量度量,有软件过程中集中度量,小型组织的度量,制定软件度量大纲,通过提供目标评估的机制，测量使我们能够对项目和过程有更深入的了解。LordKelvin曾经说过： 当你能够测量你所说的事物，并能用数字表达它时，你就对它有了一定的了解；但当你不能测量它，也不能用数字表达时，就说明你对它的了解还很贫乏，不令人满意：这可能是知识的开始，但你在思想上还远远没有进入科学的境地。 测量可以应用于软件过程中，目的是持续地改进软件过程。 测量也可以应用于整个软件项
2、目中，辅助进行估算、质量控制、生产率评估及项目控制。 最后，软件工程师还可以使用测量来帮助评估工作产品的质量，并在项目进展过程中辅助进行战术决策。,进行测量的理由： 刻画通过刻画而获得对过程、产品、资源和环境的了解，并建立同未来评估进行比较的基线； 评价通过评价来确定相对于计划的状况； 预测通过理解过程和产品间的关系，并构造这些关系的模型来进行预测； 改进通过识别障碍、根本原因、低效率和其他改进产品质量和过程性能的机会来进行改进。 测量是一个管理工具，如果能正确地使用，它将为项目管理者提供洞察力。因此，测量能够帮助项目管理者和软件团队制定出使项目成功的决策。,测度、度量和指标,6,测度、度量和
3、指标,虽然术语“measure”(测量)、“measurement”(测度)和“metrics”(度量)经常被互换地使用，但注意到它们之间的细微差别是很重要的。因为“measure”(测量)和“Measurement”(测度)既可以作为名词也可以作为动词，所以它们的定义可能会混淆。在软件工程领域中， “measure”(测量)对一个产品过程的某个属性的范围、数量、维度、容量或大小提供了一个定量的指示。 “Measurement”(测度)则是确定一个测量的行为。 IEEE的软件工程术语标准辞典(IEEEStandardGlossaryofSoftwareEngineeringTerms)IEE9
4、3中定义“metric”(度量)为“对一个系统、构件或过程具有的某个给定属性的度的一个定量测量”。,7,测度、度量和指标,当获取到单个的数据点(如在一个模块的复审中发现的错误数)时，就建立了一个测量。 测度的发生是收集一个或多个数据点的结果(如调研若干个模块的复审，以收集每一次复审所发现的错误数的测量)。 软件度量在某种程度上与单个的测量相关(如每一次复审所发现的错误的平均数，或复审中每人/小时所发现的错误的平均数)。 软件工程师收集测量结果并产生度量，这样就可以获得指标“indicator”。指标是一个度量或度量的组合，它对软件过程、软件项目或产品本身提供了更深入的了解RAG95。指标所提供
5、的更深入的理解，使得项目管理者或软件工程师能够调整开发过程、项目或产品，这样使事情进行得更顺利，能被更好地完成。,过程领域和项目领域中的度量,9,过程领域和项目领域中的度量,测量在工程界中是常事。我们测量动力消耗、重量、物理体积、温度、电压、信号噪音比 不胜枚举。 过程度量的收集涉及所有的项目，而且要经历相当长的时间，目的是提供能够引导长期的软件过程改进的一组过程指标。 项目度量使得软件项目管理都能够：(1)评估正在进行的项目的状态；(2)跟踪潜在的风险；(3)在问题造成不良影响之前发现它们；(4)调整工作流程或任务；(5)评估项目团队控制软件工程工作产品质量的能力。 测量数据由项目团队收集，
6、然后被转换成度量数据在项目期间使用。测量数据也可传送给那些负责软件过程改进的人员。因此，很多相同的度量既可以用于过程领域，又可用于项目领域。,10,过程领域和项目领域中的度量,过程度量和软件过程改进,改进任何过程的唯一合理的方法是测量该过程的特定属性，再根据这些属性建立一组有意义的度量，然后使用这组度量提供的指标来导出过程改进策略。 但是，在我们讨论软件度量及它们对软件过程改进的影响之前，必须注意到过程仅是众多“改进软件质量和组织性能的控制因素”中的一种PAU94。,图21 软件质量和组织有效性的决定因素,在图21中，过程位于三角形的中央，连接了三个对软件质量和组织绩效有重大影响的因素。人员的
7、技能和激励被认为是对质量和绩效最有影响的因素BOE81。产品复杂性对质量和团队绩效也有相当大的影响。过程中采用的技术(如软件工程方法)也有影响。另外，过程三角形存在于环境条件的圆圈之内，环境条件包括：开发环境(如CASE工具)、商业条件(如交付期限，业务规则)、客户特性(如通信的容易程度)。,11,过程领域和项目领域中的度量,过程度量和软件过程改进,我们可以间接地测量一个软件过程的功效。也就是说，我们可以根据从过程中获得的结果导出一组度量。这些结果包括： 在软件发布之前发现的错误数的测量， 交付给最终用户并由最终用户报告的缺陷的测量， 交付的工作产品的测量， 花费的工作量的测量， 花费的时间的
8、测量， 与进度计划是否一致的测量，以及其他测量。 我们还可以通过测量特定软件工程任务的特性来导出过程度量。如测量一般软件工程活动所花费的工作量和时间。,12,过程领域和项目领域中的度量,过程度量和软件过程改进,不同类型的过程数据的使用可以分为“私有的和公用的”。因为某个软件工程师可能对在其个人基础上收集的度量的使用比较敏感，这是很自然的，这些数据对此人应该是私有的，是仅供此人参考的指标。私有度量的例子有据： 个人缺陷率 软件构件缺陷率 开发过程中发现的错误数。 私有过程数据是软件工程师个人改进其工作的重要驱动力。,13,过程领域和项目领域中的度量,过程度量和软件过程改进,某些过程度量对软件项目
9、团队是私有的，但对所有团队成员是公用的。例如： 主要软件功能(由多个开发人员完成)的缺陷报告、 正式技术复审中发现的错误、 以及每个构件或功能的代码行数或功能点数。 这些数据可由团队进行复查，以找出能够改善小组性能的指标。 公用度量一般吸取了原本是个人的或团队的私有信息。收集和评估项目级的缺陷率(肯定不能归因于某个个人)、工作量、时间及相关的数据，以找出能够改善组织过程性能的指标。,14,过程领域和项目领域中的度量,过程度量和软件过程改进,软件度量规则： 解释度量数据时使用常识，并考虑组织的敏感性。 向收集测量和度量的个人及团队定期提供反馈。 不要使用度量去评价个人。 与开发者和团队一起设定清
10、晰的目标，并确定为达到这些目标需要使用的度量。 不要用度量去威胁个人或团队。 指出问题区域的度量数据不应该被“消极地”看待，这些数据仅仅是过程改进的指标。 不要在某一个别的度量上纠缠，而无暇顾及其他重要的度量。,15,过程领域和项目领域中的度量,项目度量,软件过程度量主要用于战略的目的。软件项目度量则是战术的。即，项目管理者和软件项目组经过使用项目度量及从其中导出的指标，可以改进项目工作流程和技术活动。 在大多数软件项目中，项目度量的第一个应用是在估算阶段。从过去的项目中收集的度量可以作为估算当前软件工作工作量及时间的基础。随着项目的进展，可以将花费的工作量及时间的测量与最初的估算值(及项目进
11、度)进行比较。项目管理者可以使用这些数据来监控项目的进展。 随着技术工作的启动，其他项目度量也开始有意义了。生产率可以根据创建的模型、评审的时间、功能点以及交付的源代码行数来测量。此外，对每个软件工程任务中所发现的错误也要进行跟踪。在软件从需求到设计的演化过程中，需要收集技术度量来评估设计质量，并提供若干指标，这些指标将会影响代码生成及测试所采用的方法。,16,过程领域和项目领域中的度量,项目度量,项目度量的目的是双重的。 首先，这些度量能够指导进行一些必要的调整以避免延迟，并减少潜在问题及风险，从而使得开发时间减到最少。 其次，项目度量可在项目进行的基础上评估产品质量，并且可在必要时修改技术
12、方法以改进质量。 随着质量的提高，错误会减到最小，而随着错误数的减少，项目中所需的修改工作量也会降低。这就导致整个项目成本的降低。,软 件 测 量,18,软件测量,测量在现实世界中可分为两类：直接测量(如螺钉的长度)和间接测量(如生产的螺钉的“质量”，由计算其次品率来测量)。 软件测量也有两种分类方法： 软件工程过程的直接测量，包括花费的成本和工作量；产品的直接测量，包括产生的代码行( linesofcode，LOC )、运行速度、内存大小及某段时间内报告的缺陷。 产品的间接测量，包括功能、质量、复杂性、有效性、可靠性、可维护性及许多其他的“产品特性”。,19,软件测量,将项目度量联合起来可以
13、得到整个软件组织公用的过程度量。但是，一个组织如何将来自不同个人或项目的度量结合起来呐？ 为了说明这个问题，我们看一个简单的例子： 两个不同项目团队中的人将他们在软件工程过程中所发现的所有错误进行了记录和分类。然后，将这睦个人的测量结合起来就产生了团队的测量。 在软件发布前，团队A在软件过程中发现了342个错误，团队B发现了184个错误。所有其他情况都相同，那么在整个过程中哪个团队能更有效地发现错误呢？ 因为不知道项目的规模或复杂性，所以我们不能回答这个问题。不过，如果度量采用规范化的方法，就有可能产生能够在更大的组织范围内进行比较的软件度量。如此说来，面向规模的度量和面向功能的度量都是规范化
14、的方法。,20,软件测量,面向规模的度量,面向规模的软件度量是通过规范化质量和（或）生产率的测量值而得到的，这些测量都基于已经开发的软件的“规模”。 如果软件组织一直在做简单的记录，就会产生一个如图22所示的面向规模测量的表。该表列出了在过去几年中完成的每一个软件开发项目及其相关的测量数据。 查看alpha项目的数据(图22)：花费了24个人月的工作量，成本为168 000美元，产生了12 100行代码。 应该注意到表中记录的工作量和成本涵盖了所有软件工程活动(分析、设计、编码及测试)，而不仅仅是编码。 alpha项目更进一步的信息包括：产生了365页的文档；在软件发布之前，发现了134个错误
15、；软件发布给客户之后运行的第一年中遇到了29个缺陷；有3个人参加了alpha项目的软件开发工作。,图22 面向规模的度量,22,软件测量,面向规模的度量,为了产生能和其他项目中同类度量进行比较的度量，我们选择代码行作为规范化值。根据表中所包含的基本数据，每个项目都能产生一组简单的面向规模度量： 每千行代码(KLOC)的错误数。 每千行代码(KLOC)的缺陷数。 每千行代码(KLOC)的成本。 每千行代码(KLOC)的文档页数。 除此之外，还能够计算出其他有意义的度量： 每人月错误数。 每人月千代码行( KLOC )。 每页文档的成本。,23,软件测量,面向规模的度量,面向规模的度量并不被普遍认
16、为是测量软件开发过程的最好方法JON86。大多数的争议都是围绕着使用代码行(LOC)作为关键的测量是否合适。 LOC测量的支持者们声称LOC是所有软件开发项目的“生成品”，并且很容易进行计算；许多现有的软件估算模型使用LOC或KLOC作为关键的输入，并且已经有大量的文献和数据涉及到LOC。 另一方面，反对者们则认为LOC测量依赖于程序设计语言；它们对设计得很好，但较小的程序会产生不利的评判；它们不适用于非过程语言；而且它们在估算时需要一些可能难以得到的信息(如，早在分析和设计完成之前，计划者就必须估算出要产生的LOC)。,24,软件测量,面向功能的度量,面向功能的软件度量使用功能（由应用系统提供）测量数据作为规模化值。应用最广泛的面向功能的度量是功能点（Function Point,FP）。功能点是根据软件信息域的特性及复杂性来计算的。 与LOC测量一样，功能点测量也是有争议的。支持者们认为FP与程序设计语言无关，对于使用传统语言和非过程语言应用系统来说，它都比较理想的；而且它所依据的数据是在项目开发初期就可能得到的数据。因此，作为一种估算方法，FP更有吸引力。 反对者们则声称这种
