计算机论文：卫勤模拟训练系统软件质量控制

    摘　要:卫勤模拟训练系统软件是一个多子系统复杂系统,由多个研究团队合作开发,进行质量控制是课题组的重点工作之一。本文应用软件开发工程化方法将软件开发作为一个系统工程进行管理、引入CMMI开发策略,建立软件工程过程组及CMMI规范,强调过程管理;尽早发现严重BUG、及时弥补缺陷,测试人员从需求阶段就开始进行软件测试,通过整体测试策略、里程碑技术、黑盒测试方法对软件进行测试,确保软件功能实现;通过用户试用,验证了系统可用性;最后结合开发实践指出了软件质量控制存在的不足。
　　关键词:软件质量;质量控制;控制策略
　　卫勤模拟训练系统软件是一个多子系统复杂系统,由多个研究团队合作开发,进行质量控制是课题组的重点工作之一。软件质量是指软件产品满足明确或隐含需要的有关特征和特性的总和。按照软件质量的基本要素,衡量软件质量的一级指标通常有功能性、可靠性、易用性、效率、可维修性、可移植性等。本文应用软件开发工程化、CMMI开发策略、软件测试及用户试用等方法从软件需求分析、概要设计、详细设计、编程实现、测试、部署等各个阶段对软件开发质量进行控制,取得较好效果。
　　1　软件开发工程化软件开发工程化是指按照工程化的规范要求进行软件的设计与开发,并利用工程的方法和标准对软件的整个开发过程实施管理,保证软件的正确性、安全性、可靠性与可维护性。为了确保卫勤模拟训练系统软件工程质量,课题组将软件开发作为一个系统工程进行管理,确立了工程质量方针、质量目标及过程、指南、规程等,按照项目管理、工程过程、支持过程3个阶段进行管理,每个阶段根据工作进程作了详细的规划和要求(图1)。在工程过程中,选用了"迭代生命周期模型"来降低开发风险。在软件迭代生命周期中,课题组根据主要风险列表选择要在迭代中开发的新的增量内容,每次迭代完成时都会产生一个经过测试的可执行文件,这样就可以尽早暴露风险并核实下一步工作是否已经降低了目标风险。在软件开发中,坚持软件开发人员与专业人员共同参与共同研究,不断把开发成果物与需求进行比对与讨论,修正软件开发过程中遇到的不一致情况,从而使软件功能与实际需求一致,确保软件开发质量。
　　即软件能力成熟度模型集成。CMMI有5个等级:一级即完成级、二级即管理级、三级即定义级、四级即量化管理级、五级即优化级。CMMI2(管理级)建立了基本的项目管理过程来跟踪费用、进度和功能特性,制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验。卫勤模拟训练系统软件开发工程管理体系2.1　建立软件工程过程组(SEPG )　该组织是一个独立于软件开发组织的质量小组,其人员配置为8~10人,其中负责人一名,兼任软件质量师;软件总体3~4人,参加过一次以上大型软件工程化开发过程,有丰富的软件工程化设计和项目管理经验;软件配置管理和质量保证人员4~5人,主要负责软件配置管理、版本控制、产品审核等工作。SEPG职能为全面负责软件质量工作,制定软件项目开发计划,定义软件开发、测试和维护过程,制定软件过程规范和实施细则,评估软件项目过程质量,控制软件过程进度,指导测试组织和评估测试结果,通过配置管理实现软件版本控制和版本发布。该组织具有否决权,即一旦软件过程未通过该小组评估,开发组不得转入下一过程,同时不能组织软件评审工作。
开发组在开发过程中通过日志、阶段报告和阶段成果向SEPG报告过程工作情况,主动接受软件质量监督和评估。在维护阶段开发组从SEPG获取初始版本,通过日志报告软件更动情况,同时上报软件版本。维护工作通过配置项测试、评估、评审后, SEPG负责制作下发正式软件版本。SEPG在开发过程中不断与开发组进行技术交流,制定和不断优化软件过程细则与质量标准,通过过程的优化达到提高软件质量的目标。
　　2.2　建立CMM I规范　建立以下5个关键的管理过程域(KPA):需求管理(RM)、软件项目计划(SPP)、软件项目跟踪与监控(SPTO)、软件质量保证(SQA)、软件配置管理(SCM),并通过这5个KPA对软件开发中的需求、开发活动和产品进行规范化管理,使开发过程可控且可重复。需求管理:一是通过设置一个可用于软件工程过程和管理过程的基线;控制和管理需求在开发过程中发生的变化;二是保证软件开发的概要设计、详细设计、编码等步骤始终与软件需求一致。软件项目计划:建立一个合理有效的软件项目计划,对软件项目规模、资源要求和风险等做出规范的合理的估算;制定所有软件活动和所有参加方(领导小组、评审委员会、主管机关、SEPG、开发组、质保组、用户等)的责任及其监督措施,并形成文档,以保证有效地传达。软件项目跟踪与监控:对所有软件活动设定适当的跟踪检查点和具体措施,在检查点上将执行结果、执行状态与SPP进行比较与评估,若发现较大的偏离,则报告软件领导小组并采取适当的步骤和方法进行调整。软件质量保证: SEPG制定质量保证计划,确立质量指标和评估标准,及时评审和审计软件活动和软件产品。定期向软件领导小组报告质量保证活动和结果,软件领导小组负责解决质量保证活动中所发现的重大问题。软件配置管理: SEPG制定配置管理计划,标识软件配置项,建立产品基线库,对配置项的修改加以系统的控制。同时, SEPG根据软件配置管理计划定期进行配置状态审计,并报告软件领导小组。
　　3　软件测试为了尽可能早的找到严重bug,及时补缺陷,必须在开发周期内进行软件测试。
　　3.1　测试策略　使用里程碑技术在测试过程中验证每个模块,测试人员在需求阶段参与测试工作,进行需求review、设计review、测试案例设计和测试开发,在系统开发完成之后,正式执行测试。产品达到软件产品质量要求和测试要求后发布,并提交相关的测试文档。
　　3.2　测试类型及内容　本系统采用的测试类型及内容如表1所示。
　　3.3　测试方法　采用黑盒手工用例测试方法:黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试,实际上是站在最终用户的立场上,检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。
　　进入准则:单元测试覆盖率100%;单元测试达成率95%以上;无死机bug,无影响结合测试的严重bug;结合测试设计完成。退出准则:测试达成率95% ~100%,无影响系统测试的严重级别bug,无死机bug。
　　测试类型及内容测试类型是否采用主要测试内容功能测试采用根据系统需求文档和设计文档,检查产品是否正确实现了功能流程测试采用按操作流程进行的测试,主要有业务流程、数据流程、逻辑流程、正反流程,检查软件在按流程操作时是否能够正确处理边界值测试采用选择边界数据进行测试,确保系统功能正常,程序无异常容错性测试采用检查系统的容错能力,错误的数据输入不会对功能和系统产生非正常的影响,且程序对错误的输入有正确的提示信息异常测试采用检查系统能否处理异常启动停止测试采用检查每个模块能否正常启动停止、异常停止后能否正常启动安装测试采用检查系统能否正确安装、配置易用性测试采用检查系统是否易用友好界面测试采用检查界面是否美观合理安全性和访问控制测试采用应用程序级别的安全性:检查Actor只能访问其所属用户类型已被授权访问的那些功能或数据系统级别的安全性:检查只有具备系统和应用程序访问权限的Actor才能访问系统和应用程序性能测试采用提取系统性能数据,检查系统是否满足在需求中所规定达到的性能文挡测试采用检查文档是否足够、描述是否合理回归测试采用检查程序修改后有没有引起新的错误、是否能够正常工作以及能否满足系统的需求
        3.4　测试结果3.4.1　测试执行情况　用RELEASE版本及TEST版本,由第三方专业人员进行了5次全面测试。
　　3.4.2　缺陷汇总及分布说明　缺陷主要集中在功能上,因为测试重点在程序的功能实现上,所以属于正常情况;对文档和其他两个类型没有进行测试,导致缺陷比例为零;测试人员在程序打包之前撤出项目,导致联编打包的缺陷统计也是零;语法错误占第二比例,因为代码评审及自测时间不够,导致语法错误也较多。
　　3.4.3　测试结论　所有的功能已经实现;BUG修复率超过95%;程序运行基本稳定;性能上达到了用户要求;结论为测试通过。
　　4　用户试用结果分析系统开发完成后,在发布前分别请学员、教员和管理员进行了试用,并根据试用结果进行了必要调整和完善。
　　4.1　学员试用结果　选了40个学生进行试用,并对系统使用的便捷性、系统界面的友好性、系统资料的丰富性、系统模块设置的合理性、系统流程的科学性、系统内容合理性进行调查分析,结果显示:认为系统使用方便的同学占67. 5%,认为界面友好的占82. 5%,认为资料丰富的占90%,设置合理的占85%,流程合理的77.5%,能达到训练要求的占92. 5%。大部分同学认为系统能起到辅助教学作用,尤其在演练前应用系统学习,对野战医疗的组织与工作有一个全面的了解和回顾,对提高演练质量有很大的帮助。主要问题:部分窗口关闭按键不醒目,每套练习课必须全部做完才能退出系统,其它组室不应训练救护所布局等,课题组根据这些意见作了进一步的修改完善。
　　4.2　教员和管理员试用结果　参与试用的教员和管理员有4名。调查的主要内容主要是系统的易用性、数据管理以及教学效果,结果,试用的教员认为系统配备了详细的用户手册,能很快就掌握使用方法,并教会学员使用,使用方便。后台数据库管理也较方便,许多数据都是自动生成,数据的备份较便捷。教员使用了本系统后,感觉学员能更牢固的掌握相关知识。
　　5　讨　论质量控制是确保软件质量重点工作之一,结合卫勤模拟训练系统软件开发的质量控制实践,认为目前在软件质量控制中还存在一些不足:一是缺乏成熟的软件开发管理体系。有的团队将软件开发的成败,聚焦到个别优秀的开发人员身上,没有全员参与意识。二是部分开发人员有太多的随意性。由于开发人员没有经过严密的评审和考虑,给开发的软件带来质量隐患。三是缺少必要的软件测评手段。特别是在一层一层交付使用时,缺乏可以量化的单元质量测试、以及可以量化的评估办法,导致系统集成后乃至交付用户后仍存在质量问题。
　　参　考　文　献[1]　周　韬.软件开发中的质量控制[J].新疆气象, 2006, 29(5):
　　40-41.
　　[2]　保新贵.软件能力成熟度模型[M].北京:清华大学出版社,2000: 11.
　　[3]　王　涛.软件质量保证与软件质量控制[J].电脑知识与技术, 2005(3): 62-64.
　　[4]　PaulC. Jorgensen着,韩　柯,杜旭涛译.软件测试[M].北京:
　　机械工业出版社, 2003: 7.
　　[5]　丁　斌.软件测试浅谈[J].科技咨询导报, 2007, 30: 22.