搜狐首页 科技 法医秦明

手机搜狐

SOHU.COM

测量分析源于工程需要而非管理需要

测量分析(MA)是GJB5000A标准中一个基本的支持类过程域(PA),它从所有过程域获取测量需求,同时它的测量数据和分析结果又反过来指导所有过程域的实施。可以说,测量分析做得好不好,在一定程度上决定了软件工程做得好不好。

可是,测量分析这样的软件工程基石一般的过程域在实际的实话过程中却是乱象频出。

有了GJB5000A二级资质的单位,都会有个“测量分析过程/规程文件”,里面会给出一堆测量项,而项目组就不管有用没用全部原封不动地照搬过来。虽然有计划评审,但这种评审从来不把测量计划当作评审的重点,测量项是否适宜也无人关注。结果就是采集了一堆无人问津的数据丢在那里。这些数据唯一的用处就是完成了标准中的专家实践2.1——采集测量数据而已。

同时,为了完成的另外一条专用实践——分析测量数据,项目组会利用平台工具罗列出测量数据,给个曲线图,讲上几句朴实的话——“进展正常”,基本上没有什么实质性的分析内容。

这样做的结果就是“看起来”符合标准而已。

由于采集的数据无人使用,所以其中充斥了大师的虚假数据也没有人知道。比如工作量数据。

对于一个没有数据积累的组织,项目估计的工作量与实际的工作量会有较大的偏差,这会造成安排的计划工作量也不符合实际。计划工作量可能比实际的多或者比实际的少。而出于自我保护的心理,项目组成员在提交实际工作量时,对于低于实际的工作量就会如实提交;而对于高于实际的工作量,就会按计划值提交。这就导致采集的工作量数据中存在部分虚假的数据。而这些数据被工具无差别的采集上来,测量分析人员以及QA人员也不去验证数据的准确性,最终会造成很多组织级的测量数据也出现虚假(比如,生产率)。这些组织级数据出现虚假,会进一步造成项目估计的偏差,虚假的数据会被逐步放大,最终测量数据没有任何意义。

管理层的人员都应该知道“基于事实做决策”。可是,实际上并没有多少管理者真正理解其内涵。这里的“事实”不是一个定性的模糊的描述,而应是一个定量的统计结果。

比如说,“该程序的缺陷率低,可以交付使用”,你很难据此做出同意的决策;而如果说,“该程序的缺陷率为1.2Bug/kLOC,优于业内2~4Bug/kLOC,可以交付使用”,你会很容易做出决策的。

要改变上述乱象,不妨从以下几个方面着手:

精选