测量分析(MA)是GJB5000A标准中一个基本的支持类过程域(PA),它从所有过程域获取测量需求,同时它的测量数据和分析结果又反过来指导所有过程域的实施。可以说,测量分析做得好不好,在一定程度上决定了软件工程做得好不好。
可是,测量分析这样的软件工程基石一般的过程域在实际的实话过程中却是乱象频出。
乱象一:只为对标无人睬
有了GJB5000A二级资质的单位,都会有个“测量分析过程/规程文件”,里面会给出一堆测量项,而项目组就不管有用没用全部原封不动地照搬过来。虽然有计划评审,但这种评审从来不把测量计划当作评审的重点,测量项是否适宜也无人关注。结果就是采集了一堆无人问津的数据丢在那里。这些数据唯一的用处就是完成了标准中的专家实践2.1——采集测量数据而已。
同时,为了完成的另外一条专用实践——分析测量数据,项目组会利用平台工具罗列出测量数据,给个曲线图,讲上几句朴实的话——“进展正常”,基本上没有什么实质性的分析内容。
这样做的结果就是“看起来”符合标准而已。
乱象二:数据虚假谁人问
由于采集的数据无人使用,所以其中充斥了大师的虚假数据也没有人知道。比如工作量数据。
对于一个没有数据积累的组织,项目估计的工作量与实际的工作量会有较大的偏差,这会造成安排的计划工作量也不符合实际。计划工作量可能比实际的多或者比实际的少。而出于自我保护的心理,项目组成员在提交实际工作量时,对于低于实际的工作量就会如实提交;而对于高于实际的工作量,就会按计划值提交。这就导致采集的工作量数据中存在部分虚假的数据。而这些数据被工具无差别的采集上来,测量分析人员以及QA人员也不去验证数据的准确性,最终会造成很多组织级的测量数据也出现虚假(比如,生产率)。这些组织级数据出现虚假,会进一步造成项目估计的偏差,虚假的数据会被逐步放大,最终测量数据没有任何意义。
乱象三:事实决策假大空
管理层的人员都应该知道“基于事实做决策”。可是,实际上并没有多少管理者真正理解其内涵。这里的“事实”不是一个定性的模糊的描述,而应是一个定量的统计结果。
比如说,“该程序的缺陷率低,可以交付使用”,你很难据此做出同意的决策;而如果说,“该程序的缺陷率为1.2Bug/kLOC,优于业内2~4Bug/kLOC,可以交付使用”,你会很容易做出决策的。
要改变上述乱象,不妨从以下几个方面着手:
对管理层培训
管理层的培训不一定是GJB5000A标准的培训,因为培训的目的不是让他们了解标准了解MA过程域,而是让其理解“基于事实决策”,理解数据采集和分析对于管理和决策的重要性。
领导重视对于测量分析的推动力是巨大的。举个例子:某项目的技术负责人看到软件测试数据提了2个问题:
我们项目的测试问题数与其它项目比较处于什么样的水平?
我们如何在后续研制过程中避免软件出现类似的问题?
这两个问题就带来了新的测量需求。要回答第一个问题,就需要有项目级测试数据的测量项,而不仅仅是针对软件配置项的测试问题测量项。而第二个问题就对测试数据的原因分析提出要求。只有通过问题归因,找到缺陷产生的症结,才能对症下药,预防缺陷的产生。
可见,有了高层管理者对测量数据和分析结果的需求,就会带来新的测量需求,而且是能够在工程实践中使用的测量需求。反之,没有这样的高层需求,项目组可能就会应付了事。
建立数据管理和数据决策机制
要治理乱象,就必须要建立制度。建立起组织的数据管理和数据决策机制,是解决上述乱象的基础。
数据管理机制
数据管理机制应明确测量分析计划的制订、评审规程,明确测量项的定义以及采集原因,要求采取必要手段确保数据采集的及时性和全面性,验证数据的准确性,规定数据的分析和存储,以及数据的保护和维护。
数据决策机制
建立并维护组织内种类决策所需的绩效基线,比如基于评审缺陷率的评审质量基线(用于决策评审是否通过),基于项目投入产出比的项目费效比基线(用于决策项目是否立项)。这些绩效基线都要定期维护,持续高速,以满足组织的实际情况。通过数据决策机制,使“基于事实做决策”成为组织的文化。
其它方面
数据的采集成本是非常昂贵的。经验数据表明,数据采集成本占15%的开发费用(来自NASA软件工程实验室的数据)。所以数据采集要使用简单易用的工具,要与组织的信息化工作结合起来,统一规划,统一部署。
为了鼓励凳参与数据采集和使用,可以考虑结合绩效考核手段。但是,要注意考核的上的是引导基层人员提供真实有效的数据,引导管理人员使用数据决策。不要简单地以数据的好坏评估个人的celt能力和成绩,那样可能会带来适得其反的效果。
综上所述,只有工程需要都是测量分析推进的最大动力,而且测量分析的推进是一项全员参与的活动,高层的重视是做好测量分析的关键。
微信号:IdeaofSE