点点滴滴在心头：软件开发度量思想(2).docx

《点点滴滴在心头：软件开发度量思想(2).docx》由会员分享，可在线阅读，更多相关《点点滴滴在心头：软件开发度量思想(2).docx（12页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、点点滴滴在心头：软件开发度量 思想(2)PSP的度量思想：由定性走向定量个体软件过程框架 个体软件过程(PSP0： personal software process)由美国卡 内基梅隆大学软件工程研究所的汉弗莱(Watts S. Humphrey) 等人开发而成，并于1995年推出，着重于软件开发人员的个 人培训、品质改善和工数估算，既是软件能力成熟度从组织 转向个人的飞跃，也是软件工程从定向转为定量的标志。CMM 难以适用于小规模的软件开发组织，而PSP为软件开发者提 供了控制、管理和改进个人工作方式的个人过程框架，弥补 了 CMM并未提供的有关实现CMM关键过程域所需的具体知识 和技能，

2、与CMM、TSP (team software process)构成比拟完善 的CMM PSP TSP体系。PSP过程由一系列方法、表单、脚本 等组成，指导软件开发人员如何确保自己的工作品质，如何 估算和规划自身的工作，如何度量和跟踪个人的表现，如何 改善自身的软件流程和品质。PSP能够提供：说明个体软件过 程的原那么；软件工程师作出准确的计划；软件工程师为改善 产品质量需要采取的步骤；度量个体软件过程改善的基准;流程的改变对软件工程师能力的影响。PSP进化框架概要如图5-2所示，其中个体度量过程(PSPO)是PSP的开始。图5-2个体软件过程的进化框架个体软件过程的基本原理PSP基于以下计划

3、和质量原理加以设计，以期改善个体软件开 发人员的过程效能。编译前75%以采用可靠设计方法为前 提单体测试前 85%以审查时采用逻辑检查为 前提结合测试前97. 5%对于小型产品，一个缺陷 为最大值系统测试前 99%对于小型产品，一个缺陷 为最大值6。的度量思想：用数据说话 六西格玛（6。）是一个全面的柔性系统，通过充分理解客户需求，严谨地使用事实和数据,勤奋地注意改善和创新程序，最大程度的实现商务的成功。六西格玛是以数据为依据的管理方法，用数据说话是六西格 玛的精髓。没有切实的数据度量，六西格玛仅仅是天方夜 谭。“我们不知晓我们不了解的事物, 我们对不了解的事务不能有所作为, 直到我们度量之后

4、才能有所了解, 我们不度量没有价值的东西, 我们不重视我们不度量的东西。” 六西格玛管理特别强调度量的作用，强调用顾客满意的方 式，用提高竞争力和追求卓越的方法度量我们的业绩。只有 解决了 “度量什么”和“怎样度量”的问题，才能发现在竞争力上的差距和改进空间。这是实施六西格玛管理首先要解 决的问题。六西格玛是一种基于数据的决策方法，强调用数 据说话，而不是凭直觉、经验办事，六西格玛不能成功地运 用于不能用数据来表示的过程中。六西格玛的中心思想是， 如果能“度量”过程中的缺陷，就能系统地分析出怎样消除 这些缺陷并尽可能地接近“零缺陷”。六西格玛管理不仅仅是一种理念，同时也是一套业绩突破的 方法。

5、这套方法就是六西格玛改进方法DMAIC和六西格玛设 计方法 DFSS (design process six sigma) o DMAIC 是指定 义、度量、分析、改善、控制5个阶段构成的过程改进方 法，一般用于对现有流程的改进，包括制造过程、服务过程 以及工作过程等等。六西格玛设计方法DFSS有两种主要方 式，一种是DMADV,即界定(define)、度量(measure)、分析 (analyze) 设计(design)和验证(verify)；另一种是 IDDOV,即识别(identify)、界定(define)、展开 (develop) 优化(optimize)和验证(verify) o因

6、为每位软件开发人员各不相同，要追求最大效 率，软件开发人员必须计划其工作并将计划建立在个人 的数据基础上；要坚实地改善个体软件开发人员的表现，需要采 用经过良好定义和度量的过程；要生产高质量的产品，软件开发人员必须对其产 品质量负责。良好的产品不能经由错误而产生，软件开 发人员必须为他们的工作质量而奋斗；发现并修正缺陷的时间越早，其付出的代价本钱越低；集中于预防缺陷的植入比集中于发现以及修正缺陷更加 有效；正确的工作方式通常也是最快和最廉价的工作方式。个体软件过程的度量数据PSP的基本度量数据包括：软件开发规模、各阶段所需时间、 各阶段发现的缺陷以及各阶段植入的缺陷。在这些数据工程 中需要收集

7、计划数据和实际数据。表5-8是PSP的软件度量 的尺度、目标和问题列表：表5-8 PSP中的软件度量尺度目标问题规模尺 度定义统一的规模 尺度确立时间和缺 陷尺度的正式化基自己计划的软件开 发规模是多少？自己的规模估算准础帮助实现更佳规 模尺度估算确程度是多少？完全记述了规模的 完成品是什么？时间尺 度确定PSP各个阶 段的使用时间帮助实现更佳的 时间估算 PSP各阶段实际使用 了多长时间？ PSP各阶段中计划使 用多长时间？缺陷尺 度提供缺陷数据的 历史基线理解植入缺陷的 数目和类型理解PSP各阶 段消除缺陷的相对 本钱自己在各阶段植入 的缺陷数是多少？自己在各阶段消除 的缺陷数是多少？发现

8、及修改各缺陷 需要了多长时间？TSpSM的度量思想：质量度量元团队软件过程概要卡内基梅隆大学软件工程研究所于1994年开始研究并于 1998年在其召开的过程工程年会上第一次介绍团队软件过程 (TSPsm： team software process)草案，于 1999 年发表有关 TSP的书籍，使软件过程框架形成一个包含CMMPSPTSP的 整体，即从组织、团队和个人3个层次进行良好的软件工程 改善模式。团队软件过程是一个已被良好定义并被证明的支 持 IPPD (integrated product and processdevelopment)建和管理团队的最正确实践，指导跨功能团队中的成员

9、如何有 效地规划和管理所面临的工程开发任务，告诉管理人员如何 指导软件开发队伍。TSP能够提供：一个已经定义的团队构建 过程；一个团队作业框架；一个有效的管理环境。TSP包括: 一个完整定义的团队作业过程；已经定义的团队成员的角 色；一个结构化的启动与跟踪过程；一个团队和工程师的支 持工具。TSP的最终目的在于指导开发人员如何在最短时间内 以预定的本钱开发出高质量的软件产品，所采用的方法是对 团队开发过程的定义、度量和改善。TSP的原那么与方法汉弗莱在团队软件过程中指出TSP的原那么包括：软件工 程师最大可能地了解作业并能制定最好的计划；当软件工程 师计划其工作的时候，他们对计划做出承诺；准确

10、的工程跟 踪需要详细的计划和精确的数据；要最大限度地缩短周期时 间，软件工程师必须平衡工作量；要最大限度地提高生产 率，首先必须聚焦质量。汉弗莱还指出，实施TSP的方法 是：在承当工作或者着手工作之前，首先要计划工作；使用 已经定义的过程；度量并跟踪开发的时间、工作量和缺陷； 计划、度量并跟踪工程质量；从工作一开始就强调质量；分 析各项工作并将分析结果用于改善过程。TSP的质量度量元TSP在进行设计、制造和维护软件或提供服务的过程中，很重视对质量进行度量。在团队软件过程中，其质量重点在于无 缺陷管理，包括制定质量计划、识别质量问题以及探寻和防 范质量问题。在TSP启动准备期间，团队需要根据预估

11、的产 品规模和缺陷率历史性材料，估算出各阶段会产生的缺陷 数。如果没有缺陷率历史性材料，可以使用TSP质量计划纲 要(TSP quality guidelines),这可以协助团队制定质量目 标和质量计划。汉弗莱在团队软件过程中阐述的TSP质 量计划纲要的度量工程以及目标如表5-9所示。质量计划制 定出来以后，工程管理者需要根据质量计划，通过TSP-SUMQ 表协助团队成员跟踪绩效。如果发现问题，就需要对团队提 出改善建议。在识别质量问题的时候，TSP导入了无缺陷百分 比、缺陷去除资料组合、质量资料组合以及过程质量指标等 质量度量元来跟踪识别质量问题的来源。TSP的设计在于对质 量问题防范于未

12、然，通过质量计划和过程跟踪，使软件开发 人员对质量问题更加敏感和小心，以便开发出高质量的软件 产品。表5-9 TSP的质量度量元及目标度量元目标备注无缺陷百分比：Percent Defect Free编译 10%单体测试 50%结合测试 70%系统测试 90%缺陷/KLOC： Defects/KLOC产生的总缺陷数75150假设未受过PSP培训，使用100- 200编译 10所有缺陷单体测试 5所有的主要缺陷（以源代 码L0C计算）结合测试0.5所有的主要缺陷（以源代 码L0C计算）系统测试 2.0所有的主要缺陷（以源代 码L0C计算）代码审查缺陷/编译 缺陷2.0所有的主要缺陷（以源代 码L

13、0C计算）开发时间比率：Development Time Ratios需求检视/需求时间0. 25需求推导时间概要设计检视/概要 设计时间 0.5 仅计设计工作时间，不计 研究时间详细设计/编码时间1.00详细设计审查/详细 设计时间 0.5代码检视/编码时间 0.5审查与检视率：Review and Inspection Rates需求式样书页数/小 时 2单行间距文字页数概要设计书页数/小 时 5经过格式化的设计逻辑详细设计文字行数/ 小时 100伪代码等于3 L0C代码L0C/小时 200逻辑的L0C缺陷产生与去除率：Defect Injection and Removal Rates需

14、求产生的缺陷/小 时0. 25仅计主要缺陷需求检视去除的缺 陷/小时0.5仅计主要缺陷概要设计产生的缺 陷/小时0. 25仅计主要缺陷概要设计检视去除 的缺陷/小时0.5仅计主要缺陷详细设计产生的缺 陷/小时0. 75仅计设计缺陷详细设计审查去除 的缺陷/小时1.5仅计设计缺陷详细设计检视去除 的缺陷/小时0.5仅计设计缺陷编码产生的缺陷/小 时2.0所有缺陷代码审查去除的缺 陷/小时4.0以L0C列计所有缺陷编译产生的缺陷/小 时0.3列计任何缺陷代码检视去除的缺 陷/小时1.0以L0C列计所有缺陷度量元单体测试产生的缺 陷/小时0. 067列计任何缺陷阶段收益率：Phase Yields团队需求检视不列计编辑人员的注释设计审查与检视70%使用状态分析、跟踪表代码审查与检视70%使用个人检查表编译50%语法缺陷的90 %以上单体测试-.于少于 5个缺陷/KL0C90%对高缺陷/KL0C - 50-75%结合与系统测试- 于 1.0个缺陷 /KL0C80%对高缺陷/KL0C - 30-65%