经过3天的项目启动过程之后,项目组应该产生以下结果:项目组的目标;项目组各成员的明确角色;过程开发计划;项目组的质量计划;全面的开发计划和进度计划;下一阶段每个成员的详细工作计划;项目的风险分析结果以及项目的状态报告。
TSP过程质量度量元
软件开发小组按群组软件过程TSP进行生产、维护软件或提供服务,其质量可用两组元素来表达,一组元素用以度量开发小组的素质,称之为开发小组素质度量元,另一组用以度量软件过程的质量,称之为软件过程质量度量元。
开发小组素质的基本度量元有以下五项:所编文档的页数;所编代码的行数;花费在各个开发阶段或花费在各个开发任务上的时间(以分为度量单位);在各个开发阶段中注入和改正的缺陷数目;在各个阶段对最终产品增加的价值。应该指出,这五个度量元是针对软件产品的开发来陈述的,对软件产品的维护或提供其它服务,可以参照这些条款给出类似的陈述。
软件过程质量的基本度量元有以下五项:设计工作量应大于编码工作量;设计评审工作量至少应占一半以上的设计工作量;代码评审工作量应占一半以上的代码编制的工作量;每千行源程序在编译阶段发现的差错不应超过10个;每千行源程序在测试阶段发现的差错不应超过5个。
表1
比较条款 | 项目 | 项目 | 项目 | tsp |
a | b | c | 项目 | |
源程序规模(千行数) | 67.30 | 8.00 | 86.50 | 25.80 |
测试花费(工作日) | 63.00 | 23.00 | 92.00 | 6.00 |
测试花费(工作日/kloc) | 0.94 | 2.89 | 1.06 | 0.23 |
单元测试缺陷发现率(缺陷数/kloc) | 2.21 | 9.78 | 2.06 | 0.54 |
无论是开发小组的素质,还是软件过程的质量,都可用一个等五边形来表示,其中每一个基本度量元是该等五边形的一个顶。基本度量元的实际度量结果,落在其顶点与等五边形中心的连线上,其取值可以根据事先给出的定义来确定。在应用TSP时,通过对必要数据的收集,项目组在进入集成和系统测试之前能够初步确定模块的质量。如果发现某些模块的质量较差,就应对该模块进行精心地复测,有时甚至有必要对质量特别差的模块重新进行开发,以保证生产出高质量的产品,且能节省大量的测试和维护时间。
早期应用结果
1996年,美国CMU/SEI建立了两个TSP项目,其中一个成功,另一个失败。1997年,CMU/SEI建立了9个TSP项目,并先举办了TSP技术培训班,其中两个很成功,两个相当成功,一个失败,时至1998年9月,另外4个尚在进行之中。1998年,CMU/SEI建立了6个TSP项目,并先对TSP项目组组长进行了培训,时至1998年9月,其中一个很成功,所获得的数据如表1所示;另外5个尚未完成,但根据进展情况来看,4个进展情况良好,一个看来存在问题。
三者有机结合
迄今为止,学术界和产业界公认CMM是当前最好的软件过程,然而它的成功与否与软件开发单位内部有关人员的积极参加和创造性活动密不可分。而且由于CMM中并未提供有关实现子过程域所需要的具体知识和技能,因此进行个体软件过程PSP的研究与实践以填补这一空白,且为基于个体和小型群组软件过程的优化提供了具体、有效的途径。群组软件过程TSP结合了CMM的管理方法和PSP的工程技能,建立、管理、授权并且指导项目小组如何在满足计划费用的前提下,在承诺的期限范围内,不断生产并交付高质量的产品。从公布的TSP实验数据来看,结果是令人鼓舞的。但由于尚未在巨型项目中进行TSP试验,因而尚难断定在巨型项目中实施TSP会出现什么问题,目前认为TSP比较适合规模为3~20人的开发小组。
CMM、PSP和TSP为软件产业提供了一个集成化的、三维的软件过程改革框架。TSP指导项目组中的成员如何有效地规划和管理所面临的项目开发任务,而且告诉管理人员如何指导软件开发队伍,始终以最佳状态来完成工作。在此应着重指出,单纯实施能力成熟度模型CMM,永远不能真正做到能力成熟度的升级,而需要将实施CMM与实施PSP和实施TSP有机地结合起来,才能达到软件过程持续改善的效果。
文章来源于领测软件测试网 https://www.ltesting.net/