质谱仪自问世以来,因其能够方便快捷地提供被分析样品的大量信息,在现场环境监测、国防、刑侦、安检、产品检测等许多科学研究和生产领域已发挥十分重要的作用[1]。随着软件在质谱仪中应用范围和实现功能的迅速拓展,软件的规模、复杂度都在大幅度增长,呈现出多样化、复杂化和智能化的特点,而软件面临的问题也越来越多。软件质量在某种程度上已经成为制约质谱仪质量、效能完好性的瓶颈问题,直接影响产品的可靠性和可维护性。提高和保证软件质量成为十分重要和紧迫的任务。
美国军方为评估软件供应商的能力,委托美国卡内基梅隆大学软件工程研究所(SEI)建立CMMI模型。CMMI模型继承与发展了制造业百多年积累的、行之有效的质量管理方法,特别是Deming,Crosby,Juran等著名质量大师的管理理论;同时吸收了许多组织软件开发的最佳实践。国外经验表明,推进CMMI是改变软件开发工作模式,实施精细管理,追求高标准的软件质量,谋求又好又快发展的一种必然选择。因此,要将此项工作纳入企业的中长期的发展战略,通过软件产品创造更多的效益。本文基于CMMI的思想,通过选择合适的生命周期模型,WBS分解软件产品后进行估计,对质谱仪软件研制的过程进行可视化监控,最终在实现软件功能的基础上,提高了研制生产率和管理水平。
1 生命周期模型的选择根据质谱仪软件的规模等级、关键等级,结合项目的实际情况,选择“瀑布模型”作为该项目的生命周期模型。
1970年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型[2]。瀑布模型是一种线型顺序模型,项目自始至终按照一定顺序的步骤从需求分析进展到系统测试直到提交用户使用。它提供了一种结构化的、自顶向下的软件开发方法,如同瀑布流水,逐级下落。每阶段主要工作成果从一个阶段传递到下一个阶段,必须经过严格的评审或测试,以判定是否可以开始下一阶段工作,各阶段相互独立、不重叠。瀑布模型是所有软件生命周期模型的基础,适用于小型、用户需求稳定的项目。基于瀑布模型的阶段活动描述见表 1。
工作分解结构(WBS)将一个软件项目可交付成果和项目工作分解成易于管理的几个部分或几个子项,以确保找出完成项目工作范围所需要的所有工作元素。WBS通常可以采用3种方法来标识项目的软件工作产品或软件过程:
1)基于活动的分解结构:由软件项目生命周期中所需的所有活动组成;
2)基于产品的分解结构:由项目的可交付成果及其子单元组成(项目文档、软件构件、产品、服务等);
3)基于活动加基于产品混合分解结构:结合生命周期所需的活动以及活动阶段所对应的可交付成果,以生命周期活动为高层节点,可交付成果分解为底层节点,形成混合分解结构。
根据用户需求,分解软件产品的功能,制定软件产品模块分解。质谱仪软件产品的模块分解见图 1。
软件项目估计从项目的功能需求定义开始,是一个贯穿整个项目生命周期的持续不断的过程,随信息的增加应修订估计。
Delphi法是一种最流行的专家评估技术,在没有历史数据的情况下,这种方式可以减小估算的偏差,获得较为客观的结果[3]。Delphi法需要由多名有相关经验的人员组成估计组进行估计,遇到较大分歧时就问题相互讨论,集思广益,避免由个人进行估计的局限性和片面性,使得估计结果尽可能接近实际。
改进Delphi法的步骤如下:
1)估计工作主持人组织3~5人(可包括主持人),召开估计会议,进行Delphi法估计;
2)主持人介绍项目软件实际情况、明确估计对象和内容,包括:软件产品需求、待估计的软件产品功能模块的功能和性能、WBS分解的软件研制任务等。如果本次估计会议是在项目软件执行中途召开,还应提供已获得的项目软件实际数据和信息;
3)主持人明确估计目标,说明估计的假设和约束条件,确保估计人员基于相同的假设进行工作。
质谱仪软件规模估计结果见表 2。
安排软件项目进度时应遵循下列原则:
1)软件进度安排应考虑下列因素:项目工程工作量、人员数量、人均生产率及每天可用于该项目的平均人时数;
2)使软件进度表中的活动有合适的持续期,并使里程碑有合适的间隔时间,以保证进展测量的精度;
3)主要节点的安排,应留有一定的余量;
4)将软件进度安排写进软件开发计划,并对其进行评审。
根据以上原则形成进度表(见表 3)。
项目监控的目的是对一个已批准的软件项目计划的执行进行跟踪与监控,从而为软件项目的实际进展提供足够的可见度,使得能够在实际情况显著偏离计划时,及时采取纠正措施。软件项目负责人定期对分派任务的完成情况进行跟踪、汇总,将工作量、资源、进度、已完成软件规模、数据管理等记录到跟踪报告。
3.1 规模偏离跟踪规模是软件项目的基本测量项,是决定软件项目成本的最基本因素,是估算工作量和进度、计算生产率、缺陷密度及其它项目评估指标的基础。对规模的有效估算、跟踪和控制,一方面使得项目得以按照预定计划顺利开展,另一方面也保证本单位盈利目标的实现。
在里程碑处(如需求阶段、设计阶段)以及大的需求变更发生时,或进行项目情况汇总时,项目负责人需要分析规模变化率并监控产品有效规模的偏差。
如果规模偏差在±20%范围内,则测量结果是可以接受的;如果规模偏差超出±20%范围,则分析原因并采取相应措施。
规模偏差超过控制限的可能原因和措施见表 4。
关于偏差的可能原因和采取的措施,参见表 5。
保证软件项目的进度是控制项目成本,赢得用户满意的关键。软件项目容易在进度上发生偏差,对项目的进度进行定量的高透明度的管理,可以尽早发现进度的延误,迅速做出相应的调整。
如果进度偏差超出控制界限,则分析原因,采取措施,跟踪进度,直至进度得到控制。进度偏差不超过20%。
4 结语图 2给出了软件的主要界面:谱峰解算和浓度测量。该软件具备微量气体浓度的在线监测功能,提供了友好的人机界面,方便操作,并能对数据进行存储。
在研制过程中,依据CMMI体系要求,根据式(1)和式(2),对软件项目的规模、进度偏差的测量结果进行分析。从图 3和图 4可看出,2种偏差的数据均在±20%的范围内;且软件实现阶段后,进度偏差逐渐收敛,说明对软件项目实施CMMI管理后,质谱仪软件研发过程可视,结果可测试,提升了软件研制过程能力。为满足随后的软件升级、售后工作需求,可将软件生命周期模型拓展至适应性改进型和维护型。
$\begin{array}{*{20}{l}} {{\rm{规模偏差}}(\% ) = ({\rm{软件实际规模}} - {\rm{软件计划规模}})}\\ {\qquad {\mkern 1mu} \qquad {\mkern 1mu} {\mkern 1mu} \qquad {\mkern 1mu} {\rm{软件计划规模}} \times 100\% ,} \end{array}$ | (1) |
$\begin{array}{*{20}{l}} {{\rm{进度偏差}}(\% ) = }\\ {({\rm{软件开发实际结束日期}} - {\rm{软件开发计划结束日期}})/}\\ {({\rm{软件开发计划结束日期}} - }\\ {{\rm{软件开发计划开始日期}} + 1) \times 100\% 。} \end{array}$ | (2) |
[1] |
王文锦, 严奉轩, 李芳, 等. 基于PC104的实时质谱仪真空监测系统[J]. 仪表技术与传感器 , 2015 (12):26–28, 31.
WANG Wen-Jin, YAN Feng-Xuan, LI Fang, et al. Real-time vacuum monitoring system for mass spectrometer based on PC104[J]. Instrument Technique and Sensor , 2015 (12) :26–28, 31. |
[2] |
BROOKS JR F P.人月神话[M].李琦, 译.北京:清华大学出版社, 2007.
BROOKS JR F P. The mythical man-month[M]. LI Qi, trans. Beijing:Tsinghua University Press, 2007. |
[3] |
刘明友. 基于CMMI模型的软件规模估计方法研究[J]. 软件导刊 , 2013, 12 (3):22–24.
Liu Ming-You. Study on the method of software size estimation based on CMMI[J]. Software Guide , 2013, 12 (3) :22–24. |