个体软件过程(PSPSM:personal software process)由美国卡内基·梅隆大学软件工程研究所的汉弗莱(Watts S.Humphrey)等人开发而成,并于1995年推出,着重于软件开发人员的个人培训、品质改善和工数估算,既是软件能力成熟度从组织转向个人的飞跃,也是软件工程从定向转为定量的标志。CMM难以适用于小规模的软件开发组织,而PSP为软件开发者提供了控制、管理和改进个人工作方式的个人过程框架,弥补了CMM并未提供的有关实现CMM关键过程域所需的具体知识和技能,与CMM、TSP(team software process)构成比较完善的CMM·PSP·TSP体系。PSP过程由一系列方法、表单、脚本等组成,指导软件开发人员如何确保自己的工作品质,如何估算和规划自身的工作,如何度量和跟踪个人的表现,如何改善自身的软件流程和品质。PSP能够提供:说明个体软件过程的原则;软件工程师作出准确的计划;软件工程师为改善产品质量需要采取的步骤;度量个体软件过程改善的基准;流程的改变对软件工程师能力的影响。PSP进化框架概要如图5-2所示,其中个体度量过程(PSP0)是PSP的开始。
图5-2 个体软件过程的进化框架
PSP基于以下计划和质量原理加以设计,以期改善个体软件开发人员的过程效能。
—— 因为每位软件开发人员各不相同,要追求最大效率,软件开发人员必须计划其工作并将计划建立在个人的数据基础上;
—— 要坚实地改善个体软件开发人员的表现,需要采用经过良好定义和度量的过程;
—— 要生产高质量的产品,软件开发人员必须对其产品质量负责。良好的产品不能经由错误而产生,软件开发人员必须为他们的工作质量而奋斗;
—— 发现并修正缺陷的时间越早,其付出的代价成本越低;
—— 集中于预防缺陷的植入比集中于发现以及修正缺陷更加有效;
—— 正确的工作方式通常也是最快和最廉价的工作方式。
PSP的基本度量数据包括:软件开发规模、各阶段所需时间、各阶段发现的缺陷以及各阶段植入的缺陷。在这些数据项目中需要收集计划数据和实际数据。表5-8是PSP的软件度量的尺度、目标和问题列表:
表5-8 PSP中的软件度量
尺 度 |
目 标 |
问 题 |
规模尺度 |
•定义统一的规模尺度 • 确立时间和缺陷尺度的正式化基础 •帮助实现更佳规模尺度估算 |
•自己计划的软件开发规模是多少? •自己的规模估算准确程度是多少? •完全记述了规模的完成品是什么? |
时间尺度 |
•确定PSP各个阶段的使用时间 •帮助实现更佳的时间估算 |
•PSP各阶段实际使用了多长时间? •PSP各阶段中计划使用多长时间? |
缺陷尺度 |
•提供缺陷数据的历史基线 •理解植入缺陷的数目和类型 • 理解PSP各阶段消除缺陷的相对成本 |
•自己在各阶段植入的缺陷数是多少? •自己在各阶段消除的缺陷数是多少? •发现及修改各缺陷需要了多长时间? |
卡内基·梅隆大学软件工程研究所于1994年开始研究并于1998年在其召开的过程工程年会上第一次介绍团队软件过程(TSPSM:team software process)草案,于1999年发表有关TSP的书籍,使软件过程框架形成一个包含CMM·PSP·TSP的整体,即从组织、团队和个人3个层次进行良好的软件工程改善模式。团队软件过程是一个已被良好定义并被证明的支持IPPD(integrated product and processdevelopment)的构建和管理团队的最佳实践,指导跨功能团队中的成员如何有效地规划和管理所面临的项目开发任务,告诉管理人员如何指导软件开发队伍。TSP能够提供:一个已经定义的团队构建过程;一个团队作业框架;一个有效的管理环境。TSP包括:一个完整定义的团队作业过程;已经定义的团队成员的角色;一个结构化的启动与跟踪过程;一个团队和工程师的支持工具。TSP的最终目的在于指导开发人员如何在最短时间内以预定的成本开发出高质量的软件产品,所采用的方法是对团队开发过程的定义、度量和改善。
汉弗莱在《团队软件过程》中指出TSP的原则包括:软件工程师最大可能地了解作业并能制定最好的计划;当软件工程师计划其工作的时候,他们对计划做出承诺;准确的项目跟踪需要详细的计划和精确的数据;要最大限度地缩短周期时间,软件工程师必须平衡工作量;要最大限度地提高生产率,首先必须聚焦质量。汉弗莱还指出,实施TSP的方法是:在承担工作或者着手工作之前,首先要计划工作;使用已经定义的过程;度量并跟踪开发的时间、工作量和缺陷;计划、度量并跟踪项目质量;从工作一开始就强调质量;分析各项工作并将分析结果用于改善过程。
TSP在进行设计、制造和维护软件或提供服务的过程中,很重视对质量进行度量。在团队软件过程中,其质量重点在于无缺陷管理,包括制定质量计划、识别质量问题以及探寻和防范质量问题。在TSP启动准备期间,团队需要根据预估的产品规模和缺陷率历史性材料,估算出各阶段会产生的缺陷数。如果没有缺陷率历史性材料,可以使用TSP质量计划纲要(TSP quality guidelines),这可以协助团队制定质量目标和质量计划。汉弗莱在《团队软件过程》中阐述的TSP质量计划纲要的度量项目以及目标如表5-9所示。质量计划制定出来以后,项目管理者需要根据质量计划,通过TSP-SUMQ表协助团队成员跟踪绩效。如果发现问题,就需要对团队提出改善建议。在识别质量问题的时候,TSP导入了无缺陷百分比、缺陷去除资料组合、质量资料组合以及过程质量指标等质量度量元来跟踪识别质量问题的来源。TSP的设计在于对质量问题防范于未然,通过质量计划和过程跟踪,使软件开发人员对质量问题更加敏感和小心,以便开发出高质量的软件产品。
表5-9 TSP的质量度量元及目标
度 量 元 |
目 标 |
备 注 |
无缺陷百分比:Percent Defect Free |
||
编译 |
> 10% |
|
单体测试 |
> 50% |
|
结合测试 |
> 70% |
|
系统测试 |
> 90% |
|
缺陷/KLOC:Defects/KLOC |
||
产生的总缺陷数 |
75~150 |
若未受过PSP培训,使用100- 200 |
编译 |
< 10 |
所有缺陷 |
单体测试 |
< 5 |
所有的主要缺陷 (以源代码LOC计算) |
结合测试 |
< 0.5 |
所有的主要缺陷 (以源代码LOC计算) |
系统测试 |
< 0.2 |
所有的主要缺陷 (以源代码LOC计算) |
度 量 元 |
目 标 |
备 注 |
缺陷比率:Defect Ratios |
||
详细设计审查缺陷/单体测试缺陷 |
> 2.0 |
所有的主要缺陷 (以源代码LOC计算) |
代码审查缺陷/编译缺陷 |
> 2.0 |
所有的主要缺陷 (以源代码LOC计算) |
开发时间比率:Development Time Ratios |
||
需求检视/需求时间 |
> 0.25 |
需求推导时间 |
概要设计检视/概要设计时间 |
> 0.5 |
仅计设计工作时间,不计研究时间 |
详细设计/编码时间 |
> 1.00 |
|
详细设计审查/详细设计时间 |
> 0.5 |
|
代码检视/编码时间 |
> 0.5 |
|
审查与检视率:Review and Inspection Rates |
||
需求式样书页数/小时 |
< 2 |
单行间距文字页数 |
概要设计书页数/小时 |
< 5 |
经过格式化的设计逻辑 |
详细设计文字行数/小时 |
< 100 |
伪代码~ 等于3 LOC |
代码LOC/小时 |
< 200 |
逻辑的LOC |
缺陷产生与去除率:Defect Injection and Removal Rates |
||
需求产生的缺陷/小时 |
0.25 |
仅计主要缺陷 |
需求检视去除的缺陷/小时 |
0.5 |
仅计主要缺陷 |
概要设计产生的缺陷/小时 |
0.25 |
仅计主要缺陷 |
概要设计检视去除的缺陷/小时 |
0.5 |
仅计主要缺陷 |
详细设计产生的缺陷/小时 |
0.75 |
仅计设计缺陷 |
详细设计审查去除的缺陷/小时 |
1.5 |
仅计设计缺陷 |
详细设计检视去除的缺陷/小时 |
0.5 |
仅计设计缺陷 |
编码产生的缺陷/小时 |
2.0 |
所有缺陷 |
代码审查去除的缺陷/小时 |
4.0 |
以LOC列计所有缺陷 |
编译产生的缺陷/小时 |
0.3 |
列计任何缺陷 |
代码检视去除的缺陷/小时 |
1.0 |
以LOC列计所有缺陷 |
度 量 元 |
目 标 |
备 注 |
单体测试产生的缺陷/小时 |
0.067 |
列计任何缺陷 |
阶段收益率:Phase Yields |
||
团队需求检视 |
~ 70% |
不列计编辑人员的注释 |
设计审查与检视 |
~ 70% |
使用状态分析、跟踪表 |
代码审查与检视 |
~ 70% |
使用个人检查表 |
编译 |
~ 50% |
语法缺陷的90 % 以上 |
单体测试– 于少于5个缺陷/KLOC |
~ 90% |
对高缺陷/KLOC - 50-75% |
结合与系统测试– 于< 1.0个缺陷/KLOC |
~ 80% |
对高缺陷/KLOC - 30-65% |
编译前 |
>75% |
以采用可靠设计方法为前提 |
单体测试前 |
> 85% |
以审查时采用逻辑检查为前提 |
结合测试前 |
> 97.5% |
对于小型产品,一个缺陷为最大值 |
系统测试前 |
> 99% |
对于小型产品,一个缺陷为最大值 |
“我们不知晓我们不了解的事物,
我们对不了解的事务不能有所作为,
直到我们度量之后才能有所了解,
我们不度量没有价值的东西,
我们不重视我们不度量的东西。”
六西格玛管理特别强调度量的作用,强调用顾客满意的方式,用提高竞争力和追求卓越的方法度量我们的业绩。只有解决了“度量什么”和“怎样度量”的问题,才能发现在竞争力上的差距和改进空间。这是实施六西格玛管理首先要解决的问题。六西格玛是一种基于数据的决策方法,强调用数据说话,而不是凭直觉、经验办事,六西格玛不能成功地运用于不能用数据来表示的过程中。六西格玛的中心思想是,如果能“度量”过程中的缺陷,就能系统地分析出怎样消除这些缺陷并尽可能地接近“零缺陷”。
六西格玛管理不仅仅是一种理念,同时也是一套业绩突破的方法。这套方法就是六西格玛改进方法DMAIC和六西格玛设计方法DFSS(design process six sigma)。DMAIC是指定义、度量、分析、改善、控制5个阶段构成的过程改进方法,一般用于对现有流程的改进,包括制造过程、服务过程以及工作过程等等。六西格玛设计方法DFSS有两种主要方式,一种是DMADV,即界定(define)、度量(measure)、分析(analyze)、设计(design)和验证(verify);另一种是IDDOV,即识别(identify)、界定(define)、展开(develop)、优化(optimize)和验证(verify)。
温馨提示:因考试政策、内容不断变化与调整,信管网网站提供的以上信息仅供参考,如有异议,请以权威部门公布的内容为准!
信管网致力于为广大信管从业人员、爱好者、大学生提供专业、高质量的课程和服务,解决其考试证书、技能提升和就业的需求。
信管网软考课程由信管网依托10年专业软考教研倾力打造,官方教材参编作者和资深讲师坐镇,通过深研历年考试出题规律与考试大纲,深挖核心知识与高频考点,为学员考试保驾护航。面授、直播&录播,多种班型灵活学习,满足不同学员考证需求,降低课程学习难度,使学习效果事半功倍。
发表评论 查看完整评论 | |