军用软件外包

军用软件外包（精选7篇）

军用软件外包 篇1

摘要：军用WebE (也称为Web工程) 外包作为军方获取信息服务的主要方式之一, 在显示出巨大优势的同时, 也可能伴随着很大的风险。因此, 研究军用WebE外包的风险管理及其规避策略, 是必须面对的现实问题。本文列示了军用WebE外包项目可能存在的各种风险, 并对各种风险可能造成的影响进行了可能性分析, 然后针对各种可能性较大的风险提出了规避策略。

关键词：军用WebE,外包,风险管理,风险规避策略

军用WebE外包, 作为应对快速技术变革和降低军队信息化建设管理成本与风险、提高WebE质量、满足军事要求、防止预算严重超支、项目延期或中途下马的重要措施, 越来越受到军队各类单位的认同和重视。但是, 军用WebE外包风险是工作实践中不可忽视的一个方面。如何识别外包风险, 并采取切实可行的措施规避风险的产生, 是需要研究的一个重要且现实的问题。

一、军用Web E外包风险的识别与评估

军用WebE外包的风险管理包括一系列任务, 用来帮助WebE项目管理团队 (以WebE委托方为主, 吸纳外包服务商和最终用户参加的一个工作组) 理解和管理那些将可能破坏一个WebApp (读作Web应用) 项目的各种问题。风险是一个潜在的问题, 既可能发生, 也可能不发生。但是, 不管发生与否, 我们都应该识别它, 评估它发生的可能性, 估算它的影响, 并制定一个应急规避策略来应对问题的真正发生。

1、军用WebE外包风险的识别

军用WebE外包的风险识别, 是指识别并纪录可能对WebE项目外包造成不利影响的因素。要进行军用WebE项目外包的风险识别, 就要考虑外包会给军方带来什么竞争优势和风险?如果外包活动失败, 军方会承担什么风险?军方又该如何应对这些风险?科学、客观地预测风险会在外包活动的哪个环节出现、以哪种方式出现、出现的时候对军方有什么影响, 既是风险识别的主要内容, 也是搞好风险规避的前提。

关于信息系统和服务外包的风险来源, 国内外的学者有过不少研究。比如Roger S.Pressman在论述软件风险时, 认为风险来源可以从项目风险、技术风险和商业风险三方面来分析。本文将结合WebE项目本身的特点、外包过程中的各个环节和WebE项目利益相关者 (WebE委托方、外包服务商和最终用户) 等方面, 进行风险分析与识别。

风险识别的方式既可以由WebE委托方具有项目管理经验的管理者承担, 也可以由WebE项目管理团队以集体讨论的形式来完成。风险识别阶段的主要任务是发现WebE项目可能存在的风险。为避免遗漏, 通常按照机构、人员、技术、需求、产品和估算等六大关键性的风险类型进行列示归类 (如表1所示) , 然后再由WebE项目管理团队集中对这些潜在风险进行评估。

表1中对风险的分类方式并不是绝对的。比如, 富有经验的首席设计师的离职, 不仅可能带来人员风险, 同时也可能带来技术风险, 因为继任者可能缺乏某种技术技能。最后, 还可能带来产品风险, 因为产品的交付可能会延期。

2、军用WebE外包风险评估

一旦形成了合并的风险列表, 就可以进行风险评估了。WebE项目管理团队可以根据风险值测定法, 逐一对已识别的每一个风险出现的可能性和严重性做出主观判断, 据此再进行风险度的计算, 以利于实际的管理操作。其计算公式为:V=C×P。其中:V表示风险大小;C指风险发生的项目成本;P指风险发生的概率。通常, 对每个已识别的风险, 是按如下步骤来评估其可能性和影响的。

(1) 该风险变为现实的可能性或概率有多大。可将风险发生的可能性按百分比分为四个级别, 分别是:小型 (10%—25%) 、中型 (25%—50%) 、大型 (50%—75%) 和非常大 (>75%) 。

(2) 如果该风险发生, 与其相关的问题所造成的后果。可能的结果有:灾难性的 (>75%) 、严重的 (50%—75%) 、可容忍的 (25%—50%) 和可忽略的 (10%—25%) 。

(3) 由于WebE项目的开发是以迭代方式进行的, 在每一次迭代过程中每一项风险出现的可能性及其影响后果都可能发生改变。因此, 必须在风险评估的每一次迭代中, 更新风险评估结果。

(4) 风险一经分析和排序, 接着就要判断哪些风险是在项目期间必须考虑的。一般而言, 要根据项目自身的情况确定要进行监控的风险数量, 所选接受监控的风险数目要以便于管理为原则。通常, 中型以上的风险都必须加以考虑。表2是WebE项目风险评估结果。

二、军用Web E外包风险规避策略

对优先级较高的每一个风险, WebE项目管理团队都要回答三个方面的问题, 一是如何能够完全避免这个风险;二是影响这个风险变大或变小的可能因素有哪些;三是一旦某个风险变为现实我们可以做些什么。下面具体探讨如何规避一些优先级较高风险的策略。

1、WebApp项目需求和项目选择错误导致的风险

一个WebApp项目的起点称为项目需求。军用WebE外包的项目需求, 通常是需要一个支持军方当前和未来业务需求的全新信息系统。项目的需求风险, 可能导致开发了一个并不能达到军事目的或完成军事任务所应具备的功能的系统, 或者, 所开发的WebApp不再符合军队信息化建设的整体战略要求。

通常, 为避免项目需求风险, 需要对拟开发的WebApp系统, 在系统所提供的改进的服务、更好的性能、更丰富的信息、更安全的控制、更低的成本和对新装备和新服务的支持等六个方面进行仔细的分析研究, 才能使项目需求的理由更充分。一个新的WebApp启动, 至少必须在上述六个方面之一达到用户的要求。

鉴于目前IT系统的功能越来越强大, 技术越来越复杂, 应用领域越来越广, 应用效果千差万别, 资金投入也不同, 这就要求军方对各种项目机会作出充分的比较和选择。国内外大量IT实施案例表明, 正确的项目选择, 往往比正确的项目计划和项目实施更具战略意义。在进行项目选择时, 需要注意如下几个方面:一是项目本身要与军队信息化发展战略相一致, 并符合本单位当前和未来业务发展需求;二是大型WebApp项目的上马, 一定要先在内部进行充分的沟通, 定义并评估总体目标, 对目标WebApp项目给出定性和定量指标;三是在进行项目选择的同时, 要搞好自身业务流程的梳理、资源的调查和技术能力的摸底;四是要评估WebApp项目的收益。

2、外包市场的成熟度导致难以选择合适的外包服务商风险

近几年来, 随着Web技术逐渐成为企业级信息技术应用的主流, 出现了数以千计的Web设计公司专门提供建立Web站点和电子商务的服务。由于Web技术相对传统软件的开发在技术上要复杂得多, 不同的公司由于技术力量的差别所提供的产品质量相差甚远。对委托方而言, 希望外包服务商能提供真实的信息, 诚实地展示其竞争实力, 以便客观地对外包服务商进行选择, 而外包服务商则可能对项目成本、技术实力和领域经验等提供虚假信息。外包市场的不成熟, 加上委托方和外包服务商之间信息的不对称, 是导致军用WebE外包失败的重要原因之一, 需要加以认真对待。

在选择外包服务商时, 需要进行广泛深入的市场调研, 以选择合适的外包模式和外包服务商。首先, 要走访过去的客户, 以确定候选Web服务商的服务水准、技术水平、技术方案、项目报价、进度控制、服务模式, 以及合作和有效沟通的能力;其次, 要认真评审Web服务商已完成的典型案例成品, 该成品最好能与拟委托项目在业务领域、外观等方面具有相似性;再次, 可以采用招标方式在更广的范围内确定Web服务商, 以掌握候选Web服务商的足够信息 (包括Web服务商的历史和财务状况) , 尽量打破信息不对称的局面, 然后成立评审委员会 (包括邀请外部专家) 对Web服务商进行全面评审;最后, 在可能的情况下, 应联系过去成功的项目中Web服务商的首席WebE工程师, 并与之进行沟通, 最好是能以合同约束的方式确保这位首席WebE工程师参与到项目中来。

3、标准、规范体系不符合军用WebE开发要求的风险

尽管近几年来Web技术和应用得到了迅猛发展, 但至今国家和军队有关方面还没有发布WebApp软件工程和WebE外包的标准或规范。如果说WebApp软件的开发还勉强可以参考传统软件开发所依据的国家、军队标准的话, 那么WebE外包则几乎是无章可循的, 可依据的材料仅仅是国外一些技术领先的公司的最佳实践。

建议有关方面尽快建立、完善与WebApp软件开发和WebE外包有关的国家、军队标准规范。首先, 应尽快制定WebApp软件开发标准, 以便为软件的开发提供过程、方法和工具的指导。比如, 美国就已颁布了五部法律法规来规范对纪录信息的管理 (此外, 许多知名的大公司还开发了大量的WebApp质量标准和准则) , 其中美国防部法规5015.2-STD (Department of Defense R ule 5015.2-STD) 就规定, 美军军事机构必须遵守系统的流程来纪录正式文档和文件。其次, 要制定WebApp软件质量标准 (内容包括:可用性、功能性、可靠性、高效性、可维护性、保密性、实用性和可伸缩性等) , 以便为软件项目立项论证、需求分析和软件测评提供参考依据。最后, 要制定WebE外包的政策法规, 规范WebE外包市场, 维护委托方、外包服务商和独立的具有合法资质的软件测评单位三方的合法权益, 为WebE外包这一新兴的产业提供完善的法律保障。

4、WebApp技术平台、开发工具选择错误风险

WebApp技术平台的选择, 主要考虑功能性、扩展性、技术演化方向、支持能力和成本等方面的因素。随着WebApp变得越来越复杂和强大, 目前已有大量的工具可用, 这些工具包括:内容描述和建模语言、编程语言、基于组件的开发资源、浏览器、多媒体工具、网站编写、管理和分析工具、数据库链接工具、安全工具以及服务器和服务器实用工具等。

技术平台和开发工具的作用是非常重要的, 它们会威胁到WebE的质量和交付时间, 有时甚至是决定项目成败的主要因素。大量的应用案例和经验告诉我们, 国内的软件开发商所提供的自主企业级开发平台, 在功能性、标准化、工程化等方面, 与国际知名企业平台产品相比还有很大差距, 需要加以认真分析比较, 作出明智的选择。其次, 要根据WebApp种类帮助确定可以应用的WebE技术类型, 再根据WebE技术类型确定可以使用的实现工具。最后, 平台和开发工具只有当用在WebE增量过程模型的敏捷框架内, 且与问题理解、方案设计、质量测试和风险管理等联合使用时, 才可以增强一个技术工程团队构建基于计算机的系统的能力, 创造出高质量的WebApp程序产品。

5、信息泄漏或WebApp技术限制导致存在安全隐患风险

为了让外包服务商全面深入地理解WebApp项目的运行机制, 委托方往往难免会将核心业务流程和涉密资料传递或展示给外包服务商, 因而机密或敏感性资料可能外泄, 军事安全有可能存在潜在的风险。

信息安全是开展军用WebE外包的基础工程, 也是重中之重。开发军用WebApp的过程, 实际上就是摒弃已经陈旧的管理理念, 树立起反映新军事变革要求的全新军事管理理念, 完成管理模式和管理制度的创新, 重新梳理与部队组织体制结构与任务相适应的业务流程, 并用先进的软件技术和网络技术进行重构。因此, 在选择外包服务商时应该严格执行市场准入制度, 只有那些具备涉密软件开发资质的外包服务商才能承接军用WebApp的开发。其次, 对项目参与人员要进行严格的保密审查, 在合同中必须明确所有人员的角色、工作职责、保密义务和保密期限。最后, 要委托具有合格资质第三方机构切实搞好WebApp的安全性测试。安全性测试是一个非常复杂的主题, 涉及到客户端环境、服务器端环境和客户端与服务器端之间的通信链接通路等三大技术领域, 这些领域中的每一个都可能会存在着安全威胁, 只有深入了解每一种安全机制的内部工作情况, 才能设计出有效的安全性测试用例。显然, 不具备合格资质的机构无法做到这一点。

6、削减项目预算、低估了软件的规模或潜在费用失控风险

众所周知, 由于WebApp的范围是易变的, 且很难找到WebE相关报价作为参考, 所以估算成本本质上讲就有风险。因此, 首先事先确定预期成本, 明确合同范围, 搞好费用估算, 是避免预算风险的前提条件。其次, 要形成详细的项目费用管理计划, 充分考虑所需的资源、必要的开支和各种环境因素对项目预算的影响, 在可能的情况下考虑余留一定的备用金。再次, 在与外包服务商签订合同前, 应该尽可能从两个或更多的外包服务商那里询问固定报价, 严格界定外包服务商的责任、义务与权力, 保证项目能够按预期完成。最后, 日常费用的开支, 要杜绝把计划外支出列入到成本价格中。

三、结论

尽管军用WebE外包, 在使军方以较低的成本引进较新的信息化技术、快速掌握一些先进的技术知识、有效解决问题的方法以及迅速提升军队信息化水平等方面有着十分明显的作用, 但确实存在着诸多不确定的风险因素。因此, 军方在实施军用WebE外包前, 需要根据自身组织机构状况、项目特点等方面的情况, 选择适当的外包方式, 组建作风和技术过硬的WebE项目管理团队, 在敏捷、有效的WebE过程框架约束下, 配合高质量的问题理解、方案设计、技术平台与工具、质量测试, 建立健全风险管理机制, 制定有效的风险规避策略, 才能使军用WebE外包达到预期的目标。

参考文献

[1]Roger S.Pressman:Web工程—实践者的研究方法[M].机械工业出版社, 2010.

[2]Roger S.Pressman:软件工程—实践者的研究方法[M].机械工业出版社, 2007.

[3]Ian Sommerville:软件工程[M].机械工业出版社, 2007.

[4]赵苹、陈守龙、郭爽:企业信息战略管理[M].清华大学出版社, 2006.

[5]Bill English:Microsoft Office Share Point Server 2007 Adminis-trator's Companion[M].Microsoft Corporation, Redmond, Wash-ington, U.S.A, 2007.

[6]吕登明:信息化战争与信息化军队[M].解放军出版社, 2004.

浅谈军用软件可靠性管理 篇2

军用软件可靠性管理是保证军用软件可靠性的重要方面。由于军用软件的可靠性与软件研制、实现、使用、升级维护直至淘汰的全寿命周期的各个工作环节都有密切关系, 任何环节的工作失误或考虑不周全, 都会影响到实现软件的可靠性。所以驻厂 (所) 军事代表应通过计划、组织、协调、控制好军用软件全寿命周期内各个环节的可靠性工作, 以保证军用软件达到预定的可靠性指标。这五项内容是互相、互相渗透、相辅相成的。从具体的管理角度, 军用软件可靠性管理可以分为军用软件可靠性的组织管理和军用软件可靠性技术管理。

1 军用软件可靠性的组织管理

驻厂 (所) 军事代表室应建立独立的军用软件可靠性管理职能机构。同时督促负责生产军用软件的厂 (所) 设立软件可靠性的管理机构, 这一机构可以独立设置, 也可明确归于质量管理部门, 其应具有明确的职责、权限, 并与质量管理部门一起行使质量的否决权。厂 (所) 还应设置军用软件的可靠性主管师, 对军用软件可靠性是否满足合同要求负直接责任。驻厂 (所) 军事代表室和厂 (所) 软件可靠性管理部门应起到组织、审查、监督、协调、指导和服务的作用。

2 军用软件可靠性技术管理

在军用软件研制和实现过程中, 技术工作与管理工作常常是交替的, 互相渗透的。因此驻厂 (所) 军事代表室的软件可靠性技术管理工作应从以下7个方面进行管理:

2.1 军用软件可靠性计划管理

军用软件可靠性计划是军用软件可靠性保证管理的核心, 是组织军用软件可靠性技术活动和管理活动的具体实施方案。军用软件可靠性计划应根据军用软件可靠性保证大纲确定的要求和工作项目, 进行分解和分配, 以保证军用软件可靠性各项工作得到全面落实。因此驻厂 (所) 军事代表应对军用软件可靠性工作计划进行监控, 并设立必要的评审点, 进行跟踪管理。

2.2 军用软件可靠性标准化管理

根据军用软件可靠性要求等级, 驻厂 (所) 军事代表可选用国家军用标准、国际IEC标准、国家标准等做为军用软件设计的依据标准。军用软件可靠性标准是依据科学, 经过长期实践和验证的可靠性管理与技术经验的总结。执行标准是提高军用软件可靠性的重要途径。驻厂 (所) 军事代表应严格按照可靠性标准来监督厂 (所) 整个军用软件的设计、实现过程, 这是保证军用软件靠性的最佳方法。

2.3 军用软件可靠性设计管理

军用软件可靠性设计是保证武器装备固有可靠性的首要环节。军用软件可靠性设计必将贯穿于军用软件设计的各个方面和全过程。军用软件可靠性设计实施过程必须与军用软件可靠性管理紧密结合。驻厂 (所) 军事代表应监督厂 (所) 军用软件可靠性设计是否按照规定的军用软件可靠性设计程序实施。驻厂 (所) 军事代表应确认软件可靠性设计指标的必要性、可行性、科学性、先进性和经济性等论证完成, 参与该方案的论证评审及最终软件可靠性设计评审并确认该软件设计定型。

2.4 军用软件实现的可靠性管理

军用软件实现过程的可靠性管理是指从编码到模块组合、封装形成最终软件的整个过程的可靠性保证管理。这是保证实现军用软件可靠性的关键。驻厂 (所) 军事代表应通过制定有关的质量控制准则和可靠性管理要求, 最大限度地排除和控制各种不可靠因素, 最大限度地保证实现军用软件设计的固有可靠性。

2.5 军用软件可靠性试验管理

军用软件可靠性试验是保证军用软件质量的关键步骤, 也是军用软件可靠性管理的关键环节。驻厂军事代表应从以下几项准则对厂 (所) 进行监督:

A、厂 (所) 应明确软件测试的标准、规范、指南。

B、厂 (所) 应明确软件测试过程的规定。

C、厂 (所) 在测试过程中发现的缺陷应按规定报告、分析, 按配置管理规定才去更正, 核对更正后, 记入文档、归档。

D、厂 (所) 应对测试结果进行全面分析。

E、厂 (所) 正式测试必须经过评审, 通过后才能正式测试。

F、厂 (所) 对军用软件所进行的最终测试应在最终的使用环境上进行。

2.6 军用软件可靠性信息管理

信息是进行管理活动的基础。军用软件良好的可靠性信息管理工作, 可以及时向设计部门、实现部门、试验部门、管理部门以及软件的使用方提供高质量的信息, 从而减少大量的重复性劳动, 缩短并提高军用软件可靠性的进程和水平。所以, 驻厂 (所) 军事代表应督促厂 (所) 建立军用软件可靠性信息管理部门, 并制定具体的军用软件可靠性信息管理要求, 并协同其积极进行可靠性信息的收集、加工和传递工作, 使其保证信息达到准确性和完整性。

2.7 军用软件可靠性教育管理

在实现军用软件条件基本具备的情况下, 编写人员的可靠性素质是软件可靠性的决定因素。可靠性教育是人员可靠性素质提高的重要手段。因此驻厂 (所) 军事代表应督促厂 (所) 对于不同层次的人员, 如操作人员、技术人员和管理人员, 结合他们的工作情况和接受水平, 制定不同的可靠性教学内容和教育计划。

综上所述, 驻厂 (所) 军事代表在软件的研制、实现、使用、升级维护直至淘汰的全寿命周期的各个工作环节, 都要贯彻以软件可靠性为中心的质量管理。同时, 驻厂 (所) 军事代表与厂 (所) 间的相互配合也是保障软件的质量和可靠性的重要条件。

军用软件外包 篇3

军用电子装备仿真训练软件 (Military Electronic Equipments Training Simulation Software, 以下简称METS) 是一类在商业货架计算机软硬件平台上运行的, 以装备训练为主要目的的计算机软件[1]。该类软件主要通过对武器装备的人机交互界面、行为逻辑的仿真, 实现人在回路式的操作训练功能, 是当今训练领域提高受训人员掌握窝气装备操作水平的一种重要手段。作为一种典型的军事训练应用系统, 其开发和研制面临着模型重用性不高、开发效率低等问题。这些问题已成为严重影响METS设计与开发周期和质量的瓶颈。

因此, 考虑开发一套能够解决上述问题的METS集成开发环境就显得尤为重要。随着软件工程的不断发展, 领域工程、模型驱动开发等相关技术为软件复用提供了基本的技术支持, 能使特定领域的软件复用活动相对容易的取得成功。虽然在这些技术的理论研究方面已经取得了不少成绩, 但将其应用于软件开发的实例[2,3,4]仍较为有限。而领域分析是能否成功应用领域工程方法实现软件复用的关键。FODA (Feature Oriented Domain Analysis) [5,6]是目前较为成熟的一种面向特征的领域分析方法。该方法支持某领域中各具体应用中共性和个性的发现。因此, 本文研究的重点内容是采用面向特征的领域分析方法建立METS开发领域的特征模型。即以实现METS集成开发环境为目标, 从建立METS开发领域的需求模型入手, 通过提取METS开发领域的共性和变化性特征, 构建出该领域的特征模型, 最后结合领域工程和模型驱动的软件开发方法构建出METS集成开发环境, 以满足各类METS软件的开发需求。

一、特征模型和FODA方法

从实施过程来看, 领域工程包含领域分析、领域设计和领域实现等三个阶段。领域分析是的输出产品是领域模型, 即获取领域需求, 它是针对领域的需求规约模型。特征是从用户角度对系统的感知, 文献[7]提出把特征作为系统需求规约的组织方式。因此, 对系统需求规约提取特征, 并将其进行模块化组织, 是构建领域模型的一种有效手段, 从而形成领域特征模型。

领域特征模型通过记录领域内的特征以及特征之间的关系来反映整个领域的软件需求。这组特征分属于两种类型:共性特征和变化性特征。共性特征存在于领域内的每个具体系统中, 是使领域特征模型能够复用的关键。例如, 在各类METS中, 存在着大量相同行为特征的操作元件 (多波段开关、旋钮、灯、数码管等) , 同时还有行为特征不同的能如显示器元件。变化性特征反映了领域内的不同应用系统中的差异[8]。特征模型通过特征的可选性和变化性来表示领域变化性的机制。其中, 特征的可选性是指部分特征相对于整体特征的可选性, 如视图缩放为仿真对象操作的可选行为特征。此外, 还通过维度 (dimension) 和值 (value) 的概念来描述特征具有的变化性[9]。把具有变化性的特征称为一个维度, 把其涵盖了不同细节的变化性特征称为该维度上的一个值。对于一组同一维度变化特征可采用多选一和多选多两种剪裁方式, 如元件等仿真对象的尺寸设置就是一个维度特征, 这个维度上具有精确设置和概略设置两个值, 同时该维度特征具有多选一特点。与传统软件需求规约的组织结构相比, 特征模型具有可复用性、结构良好、易于图形化建模等诸多优点[10]。

FODA是一种将特征模型引入领域工程中的较为成熟的领域分析方法。随着的领域工程研究的不断深入, 还发展了其它一些以特征模型为核心的领域分析方法 (FORM[11], Featu RSEB[12], PLA[13]) 。运用FODA等领域工程方法, 在开发领域新系统时, 可根据领域模型, 选择确定需求规约, 进而选用合适的系统架构, 并以此为基础选择构件进行组装, 形成新系统。其优点是新系统的开发是建立在对需求、构件等模型复用的基础上。也就是说, FODA正是通过捕捉领域设计阶段的共性和变化性特征, 建立特征和特征之间的关系, 以此来实现以领域特征模型为核心的领域模型。本文的重点将关注于如何建立METS开发领域的特征模型。

二、FODA特征建模过程

领域特征的分析活动的输入是各类领域应用, 输出是领域特征模型。建立特征模型的过程主要包括:服务分析活动、功能分析活动和行为分析活动三个层次, 同时, 每一层次的分析活动内都会伴随着领域术语分析、共性变化性分析、交互过程分析等并发活动, 具体分析活动流程如图1所示。需要特别说明的是, 其建模过程不是一个严格的顺序过程, 各层之间的活动可以出现交替。因此, 实际的建模过程是在这三个层次对应的分析活动之间不断迭代、反复进行的。

服务分析活动的主要内容是识别领域具有服务的特征。其目的就是为每一种典型的业务能力定义领域内统一的名称和说明, 并将其作为特征模型服务层内的特征。如在METS中将模型设计及驱动机制可统一为模型驱动服务。

功能分析活动的主要工作是识别服务具有的功能特征。首先, 分析系统为完成特定的服务必须具有的功能。然后, 为每个功能定义领域内一致的名称和说明, 并将其作为功能层内的特征, 同时建立与服务层特征的整体部分关系。例如, 在各类METS中, 用户需要对多波段开关、数码管等仿真对象进行增、删、改等编辑和位置、尺寸设置等操作, 从而确定出仿真对象管理服务的功能特征。

行为分析活动的主要工作是识别功能具有的行为特点。该层活动主要是为每一种行为特征建立领域内一致的名称和说明, 并将其放入特征模型的行为特征层, 同时建立与功能层特征的整体部分关系。该项活动主要包括分析功能执行的条件特征, 如前置条件、准备工作等;分析功能主体行为的特点, 发现其具有的显著特点和可能的变化性;分析功能的后期行为特点, 如功能执行的后置条件、善后处理工作、功能执行完毕后的控制权转移等。

三、METS特征模型建模

3.1 METS开发领域。

METS集成开发环境主要应用于军用电子装备的行为建模、用户界面可视化编程、软件系统集成等方面。从用户角度来看, 该平台是一种允许用户直接操纵具有特定语义或表示特定物理对象的图形符号进行METS开发的软件系统。例如, 用图像图元或特殊形状的图元表示一个特定的电子元件类型, 用线形图元表示元件之间的接口连接, 用户可以随时操纵这些元件和图元进行建模或设计活动。从功能角度来看, 该平台构成了声纳、雷达、指控等不同专业领域的一个通用军用电子装备仿真训练软件开发领域, 专门负责为用户提供直观、简便的软件开发。虽然在不同的专业领域中, 人机界面上元件表示的语义以及元件之间存在的约束关系有很大的不同, 但是, 在对这些专业领域的变化性进行抽象、隔离和封装的基础上, 我们可以得到一个具有相同行为特征的功能区域, 如元件模版 (多波段开关、数码管等) 。METS集成开发环境具有的直观性、虚拟性、易修改性等特点, 可以极大地提高其在该领域的建模或设计工作的效率。

3.2 METS特征建模

3.2.1 服务层特征模型。

用户通过操纵面板、元件、图元等仿真对象可完成METS的人机交互界面设计, 仿真对象所对应的参数被存储在系统参数库中, 通过仿真模型设计完成用户业务模型的开发, 通过仿真引擎提供的参数模型注册服务完成系统参数与仿真模型的注册信息。在软件发布运行后, 用户操作界面元件, 仿真引擎在采集到此类操作信息后更新系统参数库中对应的参数值, 同时, 仿真引擎以此参数地址为输入在仿真模型注册信息表中找到对应的仿真模型, 并驱动仿真模型的执行, 模型的输出仍通过仿真引擎提交给人机界面进行显示或提交给网络接口进行发送, METS具有各种特征的逻辑结构如图2所示, 从中可以看出, METS是以仿真引擎服务为核心, 将其它服务有机地联系到了一起。从上述METS的开发过程可得出, 其集成开发环境应所具有的服务特征应包括仿真对象管理、模型驱动、运行时管理三部分。限于篇幅, 本文仅介绍前两部分的功能特征模型和行为特征模型, 对于运行时管理的服务特征、功能特征及其行为特征将另撰文描述。

3.2.2 功能层特征模型。

仿真对象管理用于给用户提供面板、元件、图元等仿真对象的编辑及管理操作。其中, 元件对应于实装操作界面的基本物理元素, 除具备可视化图元外, 还具备相应的显示、操作方法;图元是组成元件的基本元素, 同时具备相应的操作方法;面板是元件的管理容器, 用来实现元件对象的创建、初始化以及元件与元件参数的对应关系注册等功能, 同时完成界面布局。从中可以看出, 图元与元件作为用户的设计构件具有可重用性。仿真对象管理服务的功能特征实质上就是面板设计, 其中对象编辑和对象操作是多选特征。

模型驱动服务是METS集成开发环境中最核心的部分, 通过模型设计和参数管理功能能够为METS提供仿真模型的设计、系统参数管理, 以及二者之间的注册信息。通过共性变化性分析, 认为系统仿真模型除了具有属性特征外, 还应包括两种模型:系统回调模型和用户模型。因此, 应给用户提供自定义属性、自定义方法和回调接口编辑功能。其中, 系统回调接口是模型设计的必选功能特征, 自定义属性和方法是模型设计的可选功能特征, 其中参数管理包括参数编辑和参数注册两个必选功能特征。

运行时管理服务通过仿真引擎的驱动功能来实现METS运行时的模型调度。

METS集成开发环境的功能层特征模型如图3所示。

3.2.3 行为层特征模型。

在服务分析和功能分析的基础上, 可对每个系统功能的行为特点进行分析。通过考察用户对面板、元件、图元等仿真对象的编辑操作可以发现, 仿真对象编辑功能层的行为特征应包括:元件/图元对象的增加、删除、修改。通过考察用户对面板、元件、图元等仿真对象的典型操作可以发现, 仿真对象操作功能的必选行为特征应包括:元件/图元的组合、选择、撤销/重复、图层设置、设置位置、设置尺寸等。由于显示设备物理尺寸的限制或对局部细节的要求, 用户可能需要缩小或放大视图以便能够观察到视图的整体布局或局部细节, 因此视图缩放应作为可选行为特征。其中, 对象选择维度上有单选和多选两个值, 位置设置特征维度上有精确设置和概略设置两个值, 并且对象选择和位置设置的行为特征为多选一模式。

系统回调接口是指METS仿真引擎提供给用户的通用系统回调接口, 如面板初始化、状态变化相应等, 在系统回调接口中用户可处理这些系统响应。从模型的表示形式上看, 系统回调接口与用户的仿真模型都具有一些共性特征, 即都由模块编号、输入参数、输出参数、计算单元四部分组成。但系统回调接口的模块编号、输入参数、输出参数为系统定义, 用户只需处理计算单元。因此, 在METS集成开发环境中, 系统回调接口功能层的必选行为特征为回调接口编辑。自定义方法的行为必选特征包括:设置输入参数、设置输出参数、设置方法名称。系统提供默认的返回类型, 同时允许用户根据自身需求进行修改, 即设置返回类型为可选行为特征。自定义属性的必选行为特征为设置属性名称, 可选行为特征为设置属性类型, 设置属性类型纬度有整形、字符串等值, 且为多选一模式。

对于METS中的系统参数来说, 每个参数具有唯一标识, 用户除了能对参数进行基本编辑操作外, 更重要的是能够将参数与面板、元件、图元、仿真模型进行关联注册, 此操作是实现模型驱动的核心操作。通过交互过程分析, 可发现系统参数编辑功能的行为必选特征包括:增加、删除、设置名称、设置初始值, 设置类型、修改唯一标识号为其行为可选特征。系统参数注册功能的行为必选特征包括:参数选择、注册类型选择、模型IO参数选择, 其中选择注册类型维度上有两个值, 且为多选一模式, 表示既可通过鼠标拖动实现, 又可通过向导创建。

通过上述分析, 可得到图3所示的METS集成开发环境的行为特征模型。具体符号语义参见文献[9]。

四、结论

军用软件外包 篇4

在国防信息化程度的不断提高的今天, 军事领域中的软件产品已经成为了和硬件产品比肩而立的重要存在, 军用软件的质量高低也成为了决定军事和武器系统质量的关键因素。随着武器装备系统中的软件规模迎来爆炸式增长, 只有对过程质量的全面控制, 才有可能最大程度的降低风险, 提高软件产品质量。我单位从2011年开始试推行GJB5000A软件研制过程管理, 到如今已实现了军用软件研制能力二级管理的全面覆盖, 期间为兼顾不同专业领域、不同项目类型、不同规模和军兵种的要求, 对体系进行了持续改进。改进焦点在执行GJB5000A标准的大框架下尽可能解决特异性问题上, 同时在开发方法及操作层面上鼓励项目组团队在现有质量体系策略要求下进行创新式探索。其中利用敏捷开发的方法与GJB5000A管理体系的融合就是一种有益思考。

二、GJB5000A质量管理体系结合敏捷方法在科研院所的适应性

2.1 GJB5000A在科研院所的落地实施

GJB5000A-2008《军用软件研制能力成熟度模型》作为框架模型, 体现了业内软件研制过程最佳实践集, 其采用分级表示的方法, 按预先确定的过程域来定义组织的改进路径, 同时规定了软件研制和维护活动中的主要软件管理过程和工程过程的实践。模型五个级别中共定义了22个过程域, 每个过程域由不同个数的专用目标和相同个数的共用目标组成, 每个目标又推荐了不同的实践。在GJB5000A的定义中, 目标是必需的部件, 实践是期望的部件, 我们用满足所有目标来确定过程域的实现, 用实践来指导过程改进和评估。换句话说, GJB5000A标准允许我们用规定的实践或可接受的替代实践来满足目标。所以科研院所要想真正实现标准落地就必须按照单位自身产品特点和用户要求将实践本地化。

在实现本地化过程中, 组织会按照大多数项目的模式定义标准过程, 但却无法确保所有过程适用于所有项目, 同时在执行自由度上也遇到了很大困扰, 强约束导致了项目缺乏灵活性, 而降低约束度则可能带来质量和进度的双重风险。此外, 即使组织开放了项目组利用替代实践实现目标, 但由于团队人员的经验不足, 也很难找到恰当的替代实践, 组织还必须承担面对评估时替代实践有效性的质疑, 所以在组织层面上定义多种开发方法供项目选择就显得尤为重要。

2.2敏捷开发方法在军用软件研制过程中的适用性

软件敏捷开发是一种相对于传统软件开发而言的轻型开发方法, 它改变了传统开发中以文档为驱动的开发模式, 以人为主要驱动核心, 目前常用的基本敏捷实践方法有很多, 如极限编程 (XP) 、Scrum方法、特征驱动开发 (FDD) 等, 每种方法的实践过程都有不同, 但基础都是基于增量和迭代的过程。软件敏捷开发有四大价值观:个体和交互胜过过程和工具;可以工作的软件胜过面面俱到的文档;客户合作胜过合同谈判;响应变化胜过遵循计划。这些特点使得敏捷开发方法灵活、适用多变需求, 可快速交付, 但应用在军用软件研制过程中可能会带来以下问题:1、敏捷开发方法应用的是需求的快速迭代, 每一个迭代作为一个计划阶段, 很难对项目的整体目标有完整计划。2、敏捷开发方法更注重有效代码的快速交付, 而非文档, 这对有严格军标约束下的文档编制提出了更高的要求。3、敏捷开发最重要的开发方式是与客户一起开发, 因军用软件的需方往往是部队使用方, 面对面开发的形式较难实现。4、敏捷开发方法对开发人员的能力要求极高, 人员要不但要精通设计、编码、测试相关工作, 而且要能参与项目的需求分析和架构设计, 能对频繁变更的需求做出快速响应。

既然敏捷方法会带来以上问题, 我们为何还要考虑在军用软件承研单位引入敏捷开发过程呢?这是因为随着军用软件研制领域中引入的竞争机制, 出现了越来越多需要直接进行代码交付的PK项目, 如果再应用传统研发方式, 就失去了市场竞争优势。所以, 对于规模小、周期短、需求变动频繁、现场开发为主要形式且已经具备了较稳定的开发技术架构的项目而言, 敏捷开发方法既能让项目组在短时间内针对需求拿出有效代码, 而且在快速迭代中能总结大量有用的文档信息。只要我们可以偏重组建成员技术水平在同一层面上的成熟开发团队来承接这样的项目, 必然起到事半功倍的效果。

三、GJB5000A质量管理体系下的敏捷开发方法实施

3.1用敏捷开发方法定义过程

在组织级, GJB5000A三级过程域中的组织过程定义 (OPD) 可以帮助组织建立起自己的敏捷开发方法下的过程定义, 包括过程和过程元素的说明, 过程剪裁指南, 敏捷开发方法下的生命周期, 标准工作环境、组织测量库、组织资产库等。有了组织级定义, 项目组就可以按照集成项目管理 (IPM) 实现方法对组织标准过程进行剪裁, 形成项目的已定义过程 (P’DP) , 这个过程就可以直接指导项目的过程实施。从项目级的角度看, GJB5000A的过程管理关注的是项目做了什么, 而敏捷开发方法正是提供了该怎么做的具体开发方法, 敏捷开发方法中的活动经过合理替代和剪裁的实践方法以实现GJB5000A目标是完全可行的。

3.2敏捷开发方法实践

1. 实践方法的选择。

在敏捷开发的众多方法中, 我们选择了以Scrum为基本敏捷实践, 以持续集成 (CI) 和测试驱动开发 (TDD) 为扩展方法的敏捷开发架构。Scrum方法是敏捷开发中最典型的模型框架, 它把产品需求的实现分为若干个Sprint来完成, 每个Sprint完成后进行产品演示, 收集、细化直至实现用户需求, 整个过程为一个迭代式增量过程。持续集成提倡利用一个全自动的过程, 在一天中根据代码变化进行多次构建 (包括编译、发布和自动化测试) 来验证集成结果和发现集成错误。测试驱动开发技术 (TDD) 基本原理是在开发功能代码之前, 先编写单元测试用例代码是持续集成的验证手段。

2. 项目定义过程。

Scrum结合CI与TDD的过程可以简单描述为:一开始先由项目负责人确定一个Product Backlog (产品需求列表) , 而后召集项目团队召开Sprint计划会议对列表中的需求进行工作量预估和安排, 从中挑选出一个story作为本次迭代完成的目标, 形成Sprint Backlog (迭代需求列表) 分配给项目组成员, 每个成员接收到任务后将任务进一步细化, 在每日例会上汇报自己的完成情况和对下一步工作作出承诺, 同时在公示板上标注出自己的工作情况 (燃尽图法等方法) 。每个项目组成员对工作进行每日集成, 集成后利用测试驱动开发构建测试来快速评估集成结果, 如果发现问题马上修改, 再次集成测试, 反复循环, 直到一个迭代结束形成可用的代码。

3. 用GJB5000A过程管理敏捷开发方法下的研制。

从项目层面看, Scrum方法可以结合GJB5000A过程域中的需求开发, 项目策划、项目监控等, CI与TDD可以结合产品集成、配置管理等, 当敏捷开发的方法在GJB5000A的过程管理方法约束下, 可以得到更精确的控制和工作产品反馈。下表我们就给出了部分实践的实施方案。

四、总结

GJB5000A体系结合敏捷开发方法有别于传统研制方法中以文档为驱动的顺序研制过程, 它充分强调了消除冗余、减少返工、缩短周期, 提高效率的理念, 同时用过程记录的方法收集重要的项目信息, 可以在一轮迭代完成后一次输出成可用的文档和经过测试的可交付代码。于项目而言, 这种研制方式给项目提供了更多的灵活性选择。于组织而言, 因总装备部和军标的强制要求, 承研军用软件的单位必须要在GJB5000A及相关配套军标的要求下建立质量管理体系和规范项目研制过程。通过合理剪裁那些能提高产品质量、提高生产率的方法和模型后, 通过验证和确认方法形成组织标准过程, 必然能增强组织标准框架的适应性和实用性, 提升组织管理能力目标。

参考文献

[1]GJB5000A-2008军用软件研制能力成熟度模型[S].

[2]Mike Cohn.Scrum敏捷软件开发[M].北京:清华大学出版社, 2010.

[3]石柱.军用软件研制能力成熟度模型及其应用[M].北京:中国标准出版社, 2009.

军用软件外包 篇5

随着国际关系局势日益严峻,近年来,军用型号软件项目数量剧增,且功能不断扩充,但军用软件运行的高可靠性、安全性仍是保证部队作战的首要战略指标。在软件研发团队人员及水平相对固定的情况下,按照以往过多依赖于个人能力和“游击队”式的开发模式,不但不能满足型号软件工程化管理要求,并且为软件后期运行维护带来了极大隐患,故需要对软件研制过程各项活动进行分析及把关,提高交付软件质量,保证交付进度。通过梳理,近年来军用型号研制过程中出现的质量问题,主要原因有如下几方面:第一,部分软件后期由于与相关系统的接口需求分析不明确造成软件运行错误;第二,开发方过度承诺,后期需求变更无法控制且版本混乱; 第三,大多数系统和软件项目的投入,有一半以上纯属浪费;第四, 用户提供给开发方的需求清单不能反映真实需求;第五,系统测试阶段发现的错误,80% 是由不正确的需求或遗漏的需求造成的;第六,项目主管对需求分析和定义的基本原理和重要性缺乏认识,忽视对需求的投入;第七,缺乏有效的需求分析工具支持需求分析和需求管理。

与传统的、有形的、可描述清晰的以及可具体检测的硬件生产制造需求相比,软件需求具有模糊性、变化性和主观性的特点。正因为软件需求的这些特点,对于一个软件项目的开发来讲,最困难的部分就是准确说明软件需求,在用户和开发团队之间建立对需求的共同理解,维护需求与各阶段工作产品达到一致性,并控制需求的变更。由此可见,软件需求分析及实现作为项目研制最重要的一个组成部分,对其过程管理的好坏很大程度上决定了软件开发的成败。

1基于GJB5000A建立本地化的需求管理模型

通过多年探索和研究发现,在运用GJB 9001B实现对软件研制各阶段产品进行有效考核的基础上,借助GIB 5000A可帮助军工单位加强软件研制过程管控,满足软件工程化要求,确保软件研发进度及质量。GJB 5000A-2008《军用软件研制能力成熟度模型》是参照《软件能力成熟度模型》(CMMI)1.2版制定的。其目的是帮助军用软件研发组织对软件研制过程进行管理和改进,增强开发与改进能力,它为改进一个组织的软件开发过程提供了单一的集成化框架,二级分为7个过程域,各域继相互独立又相辅相成。其中需求管理是一个单独的过程域,主要由5个专用实践来描述。这5个专用实践围绕着“管理需求”这个专用目标开展,如图1所示是基于GJB 5000A的需求管理模型。

1.1软件需求管理基本过程定制

根据我所型号软件工程化大纲要求及软件研制具体流程,对需求管理过程进行了本地化定制,其中,专用实践SP1.1和SP1.2在实际执行过程中关联性较强,且时间较集中,采用“需求的理解和承诺”活动来描述,重点细化明确了需求提供者准则,将型号项目组定位为用户方,软件研究室定位为开发方,系统总体及软件生产人员定位为软件部署和维护人员;考虑到以往软件研制过程“重代码轻文档”的弊端,对系统需求的颗粒度划分原则进行了定义,并将其细化入《软件任务书评审要素表》及《软件任务书检查表》具体条目,为确保软件需求的可追溯落到实处奠定了基础。在订制过程中,随着对体系的理解不断加深,也采用了使用替代实践的方式简化本地化执行步骤,如为了简化需求承诺的流程使其具有可操作性,裁剪掉了软件需求承诺单,用软件评审结论报告签署页及软件任务书审签流程替代;将需求管理计划并入软件项目开发计划,确保需求管理过程策划与项目开发主计划的一致性。

SP1.4和SP1.5所关注的内容,贯穿软件研制过程的各个阶段, 且存在前后依赖关系,执行时间点为阶段工作完成时和需求发生变更时,故采取用“需求跟踪”活动来描述,航天科技集团北京航天发射技术研究所(以下简称我所)软件多为非独立工作模式,主要运行于整个CAN总线通信网络或以太网通信网络中,与其他软件有频繁的数据交互,故在需求跟踪实践中,除了关注软件本身的功能、 性能在各级工作产品中完成情况,也强调与相关联软件的通信接口即横向需求的追踪,对于软件需求输入中非技术类条目的追踪,在项目管理PMC过程域中通过项目例会及相关评审活动实现。对于需求追踪的形式制定了需求正反向追踪记录表—需求跟踪矩阵— 项目问题追踪表—项目问题报告及纠正单的统一化流程处理方式。 并明确需求追踪不一致性的发现渠道,除软件项目组成员,还包括第三方测试人员、利益相关方、项目QA人员及同行专家。

由于SP1.3需求的变更对后续软件质量、顾客满意度、批产及运行维护过程都有很大影响,故对需求变更活动,进行了强化说明,并细分具体的操作步骤。通过软件需求变更情景划分定义了不同的软件需求变更流程,对于研制过程中产生的变更,按照软件更改申请单提交—型号指挥批准(SCCB组长)—软件更改研制—软件回归测试—版本升级受控流程来实现,对于软件外场参加大型试验及运行维护时发生地变更,按照填写软件需求沟通备忘录,填写外场软件状态更改记录单—例外放行情况确认—补录技术偏离单、软件更改申请单及更改单—入库受控流程实现。

1.2适用于不同生存周期模型的需求管理过程

随着软件编程语言、运行环境的扩展,结合型号研制进度紧、用户需求变更频繁的特点,传统的瀑布模型已经不能满足目前多型号软件并行开发的局面,通过梳理我所型号软件研制特点,结合《QJA 30A (2013)航天型号软件工程化要求》中定义的航天软件研制类型,对新研软件进行了分类,除传统瀑布模型外,充分借鉴敏捷开发方法,结合航天企业文化特点,新增原型开发模型、迭代模型及增量模型,可单独使用也可组合使用,并可在定义模型基础上根据型号研制阶段特点对模型进行衍生及细分,覆盖各型号软件研制任务,可根据软件开发人员能力梯度及项目组成员组成选用不同的开发模型。

对于迭代模型及原型开发模型中迭代阶段的需求开发及实现,采用需求沟通备忘录及需求正反向追踪表确保需求的可追踪性,弱化需求变更的流程控制,迭代过程中软件版本入开发库管理,当迭代阶段完成后,回归瀑布模型研制模式,严格遵守软件需求变更流程,必要时需形成软件更改影响域分析报告,并通过会议评审,确保需求更改的可行性。

1.3软件需求过程管理过程与其他过程域的集成

基于GJB 5000A的软件工程化建设是一个各个过程域相互影响、共同促进的过程,软件需求管理过程的不断推进也离不开相关过程域的支持。主要有:需求变更对项目策划过程的影响,将需求的变更转化为进度偏差,根据进度偏差超阈值的多少来进行合适的计划变更;需求变更需要依赖测量与分析过程统计相关数据,方便项目研制过程中项目负责人宏观把握需求状态的情况,也为组织级生存周期模型选型指南及决策支持提供了保证;配置管理过程为需求承诺及变更输入的有效性提供了支持,确保了软件需求追踪及变更活动不是无源之水。

2软件需求管理平台建设

由于软件规模庞大造成的需求颗粒较多,对需求追踪及变更的有效性带来了实际执行困难,采用以往的Excel表格填写方式,不但严重耗费一线技术人员的时间和精力,而且不能保证追踪的有效性,久而久之,需求管理的执行有效性下降,以往项目运行的各种弊端重新凸显。我所与相关单位合作,尝试研发订制了软件需求管理工具,经试用,对提高人员效率,确保需求管理执行落到实处起到了促进作用。如:采用需求影响域分析,自动对变更工作产品的需求追踪关系进行分析,对于未变更的需求项,工具自动继承与上级工作产品的追踪关系,对于变更的功能项,用红色在需求跟踪矩阵中标注出来,需求管理人员只需根据红色标注索引即可对更改需求项的追踪关系重新定义,即可完成新一轮的需求追踪活动,工具会自动生成新版本的需求跟踪矩阵;针对表格化的需求跟踪矩阵不直观分析困难的特点,采取需求追踪关系图的表现形式,一列代表一个阶段的工作产品,列与列之间通过连线表现相关工作产品的追踪关系,当需求发生变更时,需求管理人员只需直接拖动并改变连线即可实现对追踪关系的重新定义。当发生需求追踪不一致情况时,只需根据本阶段需求实现要素与之前各阶段工作产品的需求项关联情况,逐级检查出中间环节未追踪上或未实现的需求条目。效果如图2所示。

3结语

通过为期1年的GJB 5000A二级全面运行,我所型号软件工程化水平有了显著提高,并实现了各型号软件均能够按期交付,靶场无低层次质量问题出现,EPG组对本地化流程及管理模式也有了更深层次的理解。在现有本地化需求管理过程的基础上,深化体系的本地化订制,使其与本单位实际情况更加贴合,促进执行力度。

第一,简化需求正反向追踪记录表,在各阶段软件设计文件中体现,无需再生成表单,简化设计人员的工作量,避免了多处产生同一张表带来内容不一致的隐患;

第二,对不同生存周期模型的需求管理活动的测量项进行梳理和定义,对于采用敏捷方法开发的软件弱化对需求变更情况的统计,加强对软件质量问题及研制进度的测量与分析;

第三,区分使用不同编程语言实现的软件需求跟踪力度,对于非代码行实现的软件可根据项目实际情况只追踪至模块和线程;

军用软件外包 篇6

随着武器装备的现代化发展, 嵌入式软件在武器装备中大量应用, 并且比例越来越大, 很多功能是由软件或软件驱动硬件来完成, 软件已无处不在, 正在成为战斗力生成的新的驱动力。近年来, 嵌入式软件的质量不论是同硬件相比还是同装备的质量相比, 都还存在着一定的差距, 嵌入式软件的可靠性对发挥武器装备的作战能力的影响越来越大, 软件可靠性已成为制约武器系统可靠性的瓶颈。

1 军用嵌入式软件概念

在中国嵌入式系统领域, 比较认同的嵌入式系统概念是:它是以应用为中心, 软硬件可裁减的, 适应应用系统对功能、可靠性、成本、体积、功耗等综合性严格要求的专用计算机系统。嵌入式系统一般指非PC系统, 主要由嵌入式处理器、相关支撑硬件、嵌入式操作系统及应用软件系统等组成。它的操作系统和应用软件集成于计算机硬件系统之中, 简单的说就是系统的应用软件与系统的硬件一体化。它是可独立工作的“器件”, 有计算机功能但又不称之为计算机的设备或器材。主要用于实现对其他设备的控制、监视或管理等功能, 具有软件代码小、自动化程度高、响应速度快等特点。

军用嵌入式软件就是武器装备嵌入式系统中的软件部分, 是装备中不可缺少的一部分;应用程序控制着系统的运作和行为, 而操作系统控制着应用程序与硬件的交互作用。其应用软件的开发基于嵌入式操作系统, 开发出来的应用软件也只是运行在嵌入式操作系统之上, 因此嵌入式软件与嵌入式操作系统是分不开的。有时也可以把嵌入式操作系统也归入嵌入式软件的范畴, 它是嵌入式系统软件。

2 军用嵌入式软件可靠性内涵

软件可靠性与软件缺陷有关, 也与系统输入和系统使用有关。从理论上说, 可靠的软件系统应该是完整、正确和一致的, 但是实际上任何软件都不可能达到百分之百的正确。对于软件可靠性有许多不同的定义, GJB 5236-2004中定义为:在指定条件下使用时, 软件产品维持规定的性能级别的能力。其中包含: (1) 软件产品为避免由软件中故障而导致失效的能力; (2) 在软件出现故障或者违反指定接口的情况下, 软件产品维持规定的性能级别的能力; (3) 在失效发生的情况下, 软件产品重建规定的性能级别并恢复受直接影响的数据的能力。

军用嵌入式软件的特点: (1) 与硬件耦合度较高, 通常只执行特定功能; (2) 嵌入式软件一般都固化在存储器芯片或单片机中, 而不是存贮于磁盘等载体中; (3) 大部分嵌入式系统具有较高的实时性, 因此对程序的时序和可靠性要求严格。

3 影响军用嵌入式软件可靠性的因素

嵌入式软件在实质上是一种信息处理载体, 无论是诸如飞机火控系统的控制软件, 还是如指挥自动化系统软件, 都是接收外界的输入信息, 根据一定的规则向外界输出一定的信息。如设计人员对用户的需求失察或者误解、或对软件的设计和测试考虑不全等原因都有可能引入错误。其中包括: (1) 需求分析错误:由于对用户需求的理解有偏差, 或用户的需求频繁改动以至于无法准确把握, 会引入错误; (2) 设计错误:一是如果在需求分析错误结果的基础上, 对软件系统的体系结构和算法进行描述, 那么, 即使是高质量的设计也是错误的;二是需求分析是正确的, 但设计的方法是错误的, 如结构化程度不好, 模型有误等, 都会导致错误; (3) 编码错误:这与系统开发所选用的编程式工具和编程技术人员的能力经验密切相关。嵌入式软件的开发通常是由相关有经验的工程师完成的, 他们对相关武器装备富有经验, 但对于计算机的认识尚达不到计算机专家的水平, 写出的程序代码可能存在隐患; (4) 测试错误:主要包括测试计划不够完善、测试不全面, 测试数据不能反映软件使用的真实环境, 测试用例过于局限甚至错误, 以及测试人员对测试结果的错误分析等错误因素; (5) 运行和维护过程中的错误:操作人员的误操作、或者操作规程本身是错误的, 都会在使用时引入错误。据统计, 在软件生存周期的需求分析和软件设计阶段发生错误或故障的比重各占55%和17%, 明显高于软件生存周期的其他各个阶段, 是影响软件可靠性的关键阶段, 所以要尽量把错误消除在开发前期。

4 提高可靠性方法

军用嵌入式软件的可靠性主要是在软件开发过程中, 应用各种必须的方法和技术, 使程序的设计在兼顾各种需求的同时, 全面满足软件的可靠性要求。

(1) 加强软件的需求分析:软件的需求分析对整个软件的研制起着决定性的作用, 需求分析做好了, 软件研制就成功了一半。因此, 需求分析应严格按照流程进行。如图1所示:

目前有许多不同的用于需求分析的分析方法, 但是, 所有这些分析方法都应遵循以准则: (1) 必须理解并描述问题的信息域, 根据这条准则应该建立数据模型; (2) 必须定义软件应完成的功能, 这条准则要求要求建立功能模型; (3) 必须描述作为外部事件结果的软件行为, 这条准则要求建立行为模型; (4) 必须对描述信息、功能和行为的模型进行分解, 用层次的方式展示细节。

(2) 采用避错技术:利用合理的结构和算法, 使得软件尽可能的不产生歧义和错误。比如MISRA (Motor Industry Software Reliability Association设在英国的汽车工业软件可靠性协会) 对汽车电子用嵌入式软件的安全可靠性做了大量研究, 在编程的语言设计结构上提出了安全性标准。

很多写法在ANSI的C以及相应的C编译器看来并没有什么不可以, 但在MISRA看来, 在安全可靠性方面存在着隐患。例如, 以下的一个写法在C语言中完全合法:

在if (a=b&&c=d&&e=f&&g=h) 中, 4个条件看起来是并列的, 但在编译和执行中, 存在着随意性和不确定性;而第二个写法, 结果是唯一的。

(3) 综合运用测试技术:主要对软件缺陷进行排错的测试技术。软件测试是软件开发过程中重要内容之一, 也是软件质量保证的关键和有效手段, 软件测试贯穿软件开发的整个生命周期。白盒测试和黑盒测试是软件测试设计的基本方法, 也可以采用软件和硬件相结合的测试方法: (1) 白盒测试也称结构测试或逻辑驱动测试, 它是指导产品内部工作过程, 按照程序内部的结构对程序进行测试, 通过测试来检测产品内部动作是否按照规格说明书的规定正常进行, 检验程序中的每条通道是否都能按预定要求正常工作。常用的白盒测试方法有两大类:静态测试方法和动态测试方法, 白盒测试通常在软件编码阶段中使用; (2) 黑盒测试又称为数据驱动测试或基于规格说明的测试, 是一种常用的测试方法, 其主要检验输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。按照测试内容划分, 一般可分为功能测试和非功能测试。具体黑盒测试设计方法包括:等价类划分法、边界值分析法、因果图法、判定表驱动法、正交试验设计法等; (3) 软件和硬件相结合的方法, 它是结合硬件的软件插装技术, 综合以往纯软件和纯硬件测试方法的优点, 采用硬件直接从目标机的总线上跟踪嵌入式代码的实时运行情况。这种方法的优点是一边测试, 一边可以观察到覆盖率的情况, 可以及时增加测试用例, 提高测试覆盖率。

(4) 采取容错技术:容错技术就是使软件在软件缺陷存在的条件下也能正常运行。大多数的软件不论采用什么技术和什么方法, 软件中仍然会存在错误。采用新的语言、先进的开发方式、完善的开发过程, 可以减少错误的引入, 但是不可能完全杜绝错误。因此, 软件容错技术成为提高软件可靠性的一种很重要的方法。在军事系统 (例如舰船武器控制系统、飞机控制系统) 同样适宜采用软件容错技术提高软件的可靠性, 容错设计技术可以分为两类: (1) 避免故障, 在开发过程中, 尽可能不让缺陷潜入软件, 这类常用的技术有:算法模型化, 把可保证正确实现需求规格的算法模型化;模拟模型化, 为保证在确定的资源条件下的预测性能的发挥, 使软件运行时间、内存使用量及控制执行模型化;可靠性模型, 使用可靠性模型, 从差错发生频度出发, 预测可靠性。正确性证明, 使用形式符号及数学归纳法等证明算法的正确性;软件危险分析与故障树分析, 从设计或编码结构出发, 追踪软件开发过程中潜入系统缺陷的原因;分布接口需求规格说明, 在设计的各阶段使用形式接口需求规格说明, 以便验证需求的分布接口实现可能性与完备性; (2) 冗余容错技术。屏蔽冗余和动态冗余是两种有效的方法。屏蔽冗余是冗余的"静态"形式, 系统能容忍某些故障的出现, 是提高可靠度的重要方法;动态冗余是按照动态方式利用冗余, 系统出现故障时系统器件可以重组, 来消除故障对系统的影响。

5 结束语

军用嵌入式软件的可靠性是技术和管理问题, 也只有将两者结合起来, 严格按照国军标的标准和各种技术方法来开发软件, 加强软件管理和测试工作, 军用嵌入式软件的可靠性才能提高到一个新的水平。

摘要：在阐述了军用嵌入式软件定义及可靠性内涵的基础上, 分析了影响军用嵌入式软件可靠性因素, 介绍了4种提高军用嵌入式软件方法的应用。

关键词：军用,嵌入式软件,可靠性

参考文献

[1]杨艳妮, 彭道勇, 张仕念, 等.军用软件可靠性问题研究[C].第十三届全国可靠性物理学术讨论会论文集, 2009.

[2]张海潘.软件工程导论[M].北京:清华大学出版社, 2008.

[3]邵贝贝.嵌入式软件的安全可靠性控制[J].电子产品世界, 2005.

[4]丁旭, 崔吉岗, 刘春裕.军用嵌入式软件覆盖测试技术[J].指挥控制与仿真, 2008 (10) .

[5]刘刚.军用嵌入式软件可靠性及其保证[J].兵工自动化, 2008 (1) .

军用软件外包 篇7

随着计算机软件在武器装备中的核心地位逐步加大, 软件产品的质量与可靠性已成为人们首要关心的问题, 因为一旦软件失效, 将可能导致装备系统失效, 引起严重后果。软件的质量直接取决于其开发过程, 不同的开发过程生产出软件产品的质量不尽相同[1]。各军用软件承制单位的软件工程化发展很不平衡, 大部分虽然建立了基本的软件过程, 领导和型号总师对软件开发和管理也已开始重视, 但仍存在沿用管理硬件的方法管理软件, 质量程序文件不到位, 抓不住软件开发过程中影响软件质量的关键因素。总体来看, 在军用软件开发中主要存在着质量文件不齐全、文档编制不规范、配置管理不严格、软件测试不到位等问题, 这些状况与我国武器装备发展的需要相差较远, 亟须改进。国内外的经验说明, 为了克服上述问题, 最根本的是“树立软件产品的概念”和“用软件工程方法组织软件开发”, 并按照软件工程方法的基本原则不断改进软件过程[2]。

1软件能力成熟度模型的基本内容

1.1 基本概念[3,4,5]

(1) 软件过程能力。

一个组织的软件过程能力提供预测该组织承担下一个软件项目时最可能的预期结果的一种方法。

(2) 软件过程成熟度。

一个软件过程的成熟意味着由于开发组织运用该软件过程, 使得各个开发项目执行该软件过程的纪律性一致增强, 并导致软件生产率和质量随着时间的推移而不断得到改进。随着软件组织的软件过程成熟度提高, 开发组织通过其方针、标准规范和组织机构等的制定和建立将其软件过程规范化和具体化。使得开发组织明确定义的一套有关管理和工程的方法、实践和规程等在现有人员离去后仍能继续下去。

(3) 关键过程域。

互相关联的若干软件实践活动和有关基础设施的集合。除初始级外每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程域, 它们对达到该成熟度登记的目标起保证作用, 这些过程域就称为该成熟度等级的关键过程域。

1.2 CMM的定义

美国卡内基梅隆大学软件工程研究所 (SEI) 将统计质量控制原理应用于软件开发, 建立软件过程成熟度模型, 并将其定义为[5]:对于软件组织在定义、实现、度量、控制和改善其软件过程中各个发展阶段的描述模型。该模型为软件过程定量控制建立了项目管理和项目工程的基本原则, 并成为软件过程不断改进的基础。CMM描述了软件过程不断改进的途径, 使软件开发组织具备自我分析、自我完善的能力, 这个模型便于确定软件组织的现有过程能力和查找出软件质量及过程改进方面的最关键的问题, 从而为选择过程改进提供依据。

CMM 将软件开发组织的能力成熟度分为5个可能的等级[6]。除第一级外, 其他每一级都由不同的关键过程域组成, 每个关键过程域设定了具体的目标, 并且为了实现这些目标, 还规定了对应的关键实践, 包括执行承诺类:为了保证过程得以建立并保持下去, 组织必须采取的一些基础性行为, 一般涉及组织方针的建立和高层管理者的承诺和支持等;执行能力类:为了有效地实施软件过程, 组织必须存在的一些必备条件, 一般涉及资源、组织机构和培训等;执行活动类:这类实践描述实施关键过程域所必须的角色和规程, 一般包括制定计划和规程, 照此执行, 并跟踪他们, 在必要时对他们进行修正;测量分析类:对过程进行测量并对测量结果进行分析等活动量;验证实施类:为了保证活动能按照已建立的过程执行的措施, 这些措施一般包括管理者和软件质量保证组所作的评审和审核工作。CMM的组成结构如图1所示。如果对应目标中的基本实践和活动都已有效执行, 则认为该目标已实现, 从而达到软件过程定量控制的目的。若组织中工程活动都是严格按照此框架下的步骤有序进行, 则认为该组织开发出来的软件是可信的, 产品的质量能够得到保障。

1.3 CMM的三个层次

从图1中可以看出, CMM结构分为3个层次。

第一层次:成熟度等级。它是软件组织在实现成熟过程进化途中逐步向上前进时的台阶式的一个个平台。每一等级包含1组与所含各关键过程域相对应的过程目标, 当这些目标都满足时, 就表明这一等级上各个软件过程域相应的重要成分或方面得到了稳定, 一方面说明这个组织过程能力增长的实际情况, 另一方面也说明了这个组织具备了向上一个成熟度等级进化的基础[6]。

第二层次:关键过程域。每个关键过程域只与特定的成熟度等级直接相关, 它指明1组目标和一串相关的活动, 当这些活动全部完成时, 就能达到这组规定的目标, 从而增强过程能力。仅当一个关键过程域的全部目标均以达到时, 该关键过程域才可实现。

第三层次:每个关键过程域包含若干关键实践, 当实施了这些关键实践时, 就能实现该关键过程域的目标。关键过程域的目标是对该关键过程域中全部关键实践的概括, 而关键过程域的某个目标必须通过一组实践去实现。

2CMM的实施基础

CMM致力于软件开发过程的管理及工程能力的提高与评估, 在规范开发步骤, 提高软件质量方面非常突出, 但是在具体的执行过程中往往容易陷入思路僵化、行为教条的困境。CMM规定了组织应该或需要做什么, 但并没有规定如何去做, 也就是在具体活动的实现上, 需要根据组织自身的特点来实施, 不能千篇一律, 这也是所有实施CMM的组织首要面临的一个问题, 即CMM本地化。在应用CMM 理论进行软件过程改进中, 要根据组织的发展情况及系统开发环境, 从中找出制约组织开发效率和能力的关键因素, 提出可行的标准和实践的步骤。根据组织的实力确定过程改进的各个阶段目标, 不断总结、改进、提高, 找出一条适合组织的CMM 实施路线[7]。

要想在组织内部推行CMM, 首先, 只有最高管理者意识到开展CMM的必要性后, 并且有决心改变现有状况的条件下, 组织才有实施的保障。改进过程本身就是一个规范的过程, 需要循序渐进、逐步改进, 因为软件过程成熟度的升级本身就是一个有生命周期的过程, 而且全面引进CMM 所涉及的范围非常广, 要求人力、财力与设备资源的投入能跟得上[8]。其次, 需要有一支具坚强有力的主导力量来推进CMM的实施活动, 由于CMM只是一个框架, 就好比一棵笔直的树干, 至于如何让它枝繁叶茂, 则需要过程推进组大量耐心细致的修剪工作。最后, 由于过程改进涉及到组织中的每一个成员, 所有的活动、数据的记录都需要靠个人来实现, 所以, 组织培训也是非常重要的一步, 只有统一思想, 提高认识, 才能提升组织合力。在最初实施CMM 时, 组织可以建立几个项目进行试点, 待条件成熟后再全面推开。并逐步规划出软件过程建立与改进的短、中、长期目标, 循序渐进, 逐步提升组织能力。

3CMM实践应注意的问题

作者参与实施CMM已近两年, 并且经历了CMM过程二级评价, 在实施过程中积累了一些经验如下:

(1) 培训要注重实效。培训是一项长期而细致的工作, 不只是在项目初期搞几次讲座、签几个名字留下记录那么简单, 重点是要通过培训, 提高组织内部的认知能力, 从而转化为实际的工作效率。CMM认证审核组对本单位的审核报告中对各个关键过程域的评价中都存在培训效果较差的待改进项, 这也反映了培训容易形式化, 缺失力度。

(2) 与现有质量体系的融合问题。由于大部分的组织在实施CMM之前都有一套质量管理体系, 在推行CMM试点时许多都是在既有的项目上开展, 遇到的主要问题就CMM试点项目如何与实际工程很好地相结合。比如在制定开发计划时, 项目软件经理制定的开发计划往往受制于科研管理部门制定的科研计划, 致使项目策划过程域执行不力。

(3) 工具的选择很重要。由于实施CMM需要记录大量的过程数据, 而增加工作量的一个重要原因就是工具的实用性不够, 所以, 选择一款优秀的开发工具能够减少繁琐的事务性工作, 提升内部积极性, 使组织更加专注于软件开发;

(4) 剪裁规则不可少。所谓过程剪裁就是通过增加、删除、修改一个过程的活动, 以达到结果过程较好地适合于本项目的实际情况。对于CMM 的模型与标准, 不能生搬硬套, 而应将其作为参考, 需要对CMM 过程进行适当裁剪, 结合单位的特点、要求与现实条件, 制订软件过程和选择实行改进的部分, 形成自己的管理体系。必须结合项目的情况和自身的特点、要求与现实条件, 制订软件过程和选择实行改进的部分。在引进、消化、吸收的基础上需要自主创新, 让CMM 更实用化, 形成自己的管理模式[9]。另外, 对于单位内部形成的体系文件, 也需要建立适当的剪裁规则, 以适应不同规模的软件项目, 对于开发周期较短的小项目, 可以剪裁或简化一些实施活动, 以减少管理成本, 比如软件项目策划过程域, 无须在软件生命周期的每个阶段开始时再制定二级计划, 以一份涵盖整个周期的开发计划进行任务分派与跟踪, 这样既避免了频繁地出入库操作又省去了大量的评审时间。

4CMM实施的体会

通过实施CMM, 规范了软件生产和管理流程, 使组织规范化程度提到, 能够按照计划为用户提供高质量的软件产品。做CMM以前, 组织在进行软件开发时往往很少去考虑项目的规模、工作量究竟有多大, 需要投入多少人力, 所制定的计划也都缺少客观依据, 尤其缺少对风险的预见性, 这样制定出来的计划缺乏指导性, 没有实际意义。通过实施CMM, 组织加深了对软件开发过程的认识, 掌握了工作分解的方法, 尤其是软件策划能力得到了提高, 开发能力稳步提升;而且在实施CMM中, 用制度替代管理者, 固化并规范了管理过程;另外, 项目组内部各成员分工明确, 权责清晰, 便于各自最大发挥自身特点, 做到人尽其才, 提升了组织的竞争力。

4.1 实施CMM取得的效果

应用CMM在项目的需求管理、项目策划、项目跟踪与监督、质量保证、配置管理等方面进行改进, 取得了明显的效果:

(1) 需求管理方面。需求管理的目的是针对顾客对软件项目的需求, 在顾客和软件项目之间建立共同的理解。与顾客间的一致的共同理解是计划和管理软件项目的基础, 为了开发出顾客满意的软件产品, 对顾客需求的理解是非常必要的, 与顾客 (内、外) 进行磋商, 评审软件需求等。由于顾客需求会频繁的改变, 所以需求变更控制也是非常重要的。组织通过建立良好的需求管理机制, 规范需求管理过程, 对需求建立及变更严格控制。在用户和组织之间建立了有效的沟通机制, 为最大限度地获取正确的需求提供了保障。从整个软件开发生命周期中看, 正确而有效的需求是后续设计开发的依据, 完善的需求管理提高了开发效率, 缩短了开发时间和成本, 提高了产品质量, 提升了用户满意度。

(2) 项目策划方面。软件项目策划始于项目早期, 贯穿整个软件项目生命周期, 在项目进行过程中估计逐步精确、计划逐步细化。为软件项目实施软件工程和管理制定合理的计划。制定这个计划的主要依据一方面是对要完成的工作有一个比较切合实际的估计, 另一方面是为完成该工作所做出的必要承诺。要做好这项工作, 应该估计软件工作产品的大小和所需的资源, 制定进度计划, 确定并评估软件风险以及协商承诺等。这个计划是管理软件项目的必要基础, 没有切合实际的计划就不可能实施有效的项目管理, 实际的开发过程越来越靠近计划和预测结果, 从而降低了风险, 提高了发展和改进的可预测性, 确保软件开发工作按计划进行。

(3) 项目跟踪和监督方面。对软件项目的实际进展情况提供适当的可视性, 以便管理者在软件项目的性能与计划有重大偏离时能采取有效纠正措施, 随时掌握软件项目的实际开发过程, 使软件项目能按计划进行, 通过对项目定期跟踪, 能够保证计划的严肃性及适用性。

(4) 软件质量保证方面。对软件项目使用的过程和构造的产品为管理者提供适当的可视性。在软件项目开发的初期阶段, 软件质量保证组与软件工程组一起制定软件项目的计划、标准 (准则、规范) 和规程等, 帮助保证所制定的计划、标准 (准则、规范) 和规程符合项目的需求, 验证所制定的计划、标准 (准则、规范) 和规程适用于整个软件生存周期中的审核。软件质量保证组在整个软件生存周期中依据计划、标准 (准则、规范) 和规程审核软件过程活动和工作产品, 并定期向软件工程组通报其活动的结果, 通过评审和审核软件产品和活动, 验证它们是否与应用的标准和规程一致, 从这个角度提供可视性。对出现的不符合性问题, 首先要考虑在软件项目内部解决, 对内部不能解决的问题, 及时报请适当的上级予以解决, 以期获得最佳的解决途径。时刻保证软件产品的质量, 提高审查率, 降低产品发生错误的概率, 减少了因为修改和改进所花费的工作量。

(5) 配置管理方面。在整个项目的软件生存周期内, 建立和维护项目产品的完整性, 并完成有关的基线审核、变更处理、配置项状态报告等工作。项目启动后应建立项目配置库, 包括受控库和产品库, 分别存储项目实施过程中产生的配置项、基线和产品, 通过对配置库进行管理, 协助控制基线变更和由配置库生成软件产品。通过确定在给定时间点上的软件配置, 系统地控制配置变更以及在整个软件生存周期中维护配置的完整性和可追溯性。

4.2 CMM的主要用途

归纳总结起来, CMM主要有以下几点用途[10]:

软件过程评估 (software process assessment, SPA) :在评估中, 一组经过培训的软件专家确定出一个组织软件过程的现状, 找出组织面对的与软件过程有关的、急需解决的问题, 取得组织领导层对软件过程改进的支持。就好比一面镜子, 可以对照该模型, 检查本单位的软件过程的强项和弱项, 从而了解需要改进之处。

软件过程改进 (software process improvement, SPI) :帮助组织对其软件过程向更好的方向转变, 并进行计划、制定以及实施。犹如一副梯子, 可以按照该模型, 明确每一步应突出抓好的少数几个方面, 特别是可以突出当前的重点或主攻方向, 引导组织向着过程改进的最佳途径成长, 逐步提升组织的过程能力。

软件能力评价 (software capability evaluation, SCE) :在软件能力评价中, 一组经过培训的专家通过对该组织软件开发过程各相关过程域的评判, 对该组织的软件过程能力给出一个科观的评价。犹如一把尺子, 确定组织的能力。作为镜子, 清晰明了;作为梯子, 重点突出;作为尺子, 尺度明确。所以说, CMM是提升软件过程能力的最佳途径。

5结语

实施CMM 对软件企业的发展有着重要的作用, CMM 过程本身就是对软件企业发展历程的一个完整而准确的描述[9]。软件企业通过实施CMM, 可以更好地规范软件生产和管理流程, 使企业组织规范化, 提高软件企业的能力成熟度, 改进软件的开发、维护过程, 按时、按预算为用户提供高质量的软件, 提高产品和企业的竞争力。纵观整个CMM的发展, 软件企业提高自身成熟度的历程是一个从无序到有序, 从特殊到一般, 从定性到定量, 最后不断自我完善的过程。通过CMM 对软件过程的合理控制, 可以有效控制软件开发的流程, 开发出来的软件产品质量明显提高。

我军制定了新的软件开发规范, 基本沿用CMM的管理思想, 并且制定了军用软件能力评价工作程序, 申请CMM认证的企业逐年增多, 且总装备部每年举办一次软件能力评估与评价技术培训班, 不断扩大实施基础。

军用软件能力成熟度模型CMM集中关注软件管理问题, 是评估软件过程和评价软件能力的重要工具, 它的贯彻实施对软件开发组织提高软件研制开发能力, 保证软件质量具有十分重要的意义[11]。因此, 军用软件开发组织引进并实施军用软件能力成熟度模型CMM既是必要的, 也是必须的。

目前, CMM认证已成为承接军用软件的重要资质, 将来所有承接军用软件项目的企业都将必须通过相应的CMM等级认证, 在软件开发领域, CMM将逐步取代旧的开发过程而成为新的标准。

摘要：针对军用软件的开发现状进行分析, 指出了目前存在的主要问题及软件开发过程在提高软件质量方面所起到的保障作用, 提出引入CMM进行软件开发的必要性;随后对CMM的基本内容进行简要介绍, 阐述了其作为一种软件过程不断改进的途径, 使软件开发组织具备自我分析、自我完善的能力, 便于确定软件组织的现有过程能力和查找出软件质量及过程改进方面的关键问题, 从而为选择过程改进提供依据。重点说明了CMM的实施基础, 讨论了实施CMM需要注意的问题及实施CMM后的体会。最后对CMM的发展方向进行了展望。

关键词：CMM,成熟度等级,关键过程域,软件过程改进

参考文献

[1]石柱.军用软件能力成熟度模型及其应用[M].北京:中国标准出版社, 2003.

[2]石柱.航天型号软件工程化十年回顾与展望[J].航天控制, 2006, 24 (4) :66-72.

[3]郑仁杰, 王玮, 王方德, 等.基于软件能力成熟度模型 (CMM) 的软件过程改进——方法与实施[M].北京:清华大学出版社, 2003.

[4]何新贵.软件能力成熟度模型[M].北京:清华大学出版社, 2001.

[5]王世锦, 蔡愉祖.CMM实施指南[M].北京:机械工业出版社, 2003.

[6]章常永, 刘育.CMM的结构和基本内容[M].武汉:武汉大学出版社, 2004.

[7]刘文威, 宁传成.CMMLevel2实战[M].北京:电子工业出版社, 2004.

[8]孟迎霞, 唐琦.CMM布道中国:一切刚刚开始[J].计算机技术与发展, 2003 (3) :46-48.

[9]王艳慧.基于CMM的软件过程改进实践[J].计算机技术与发展, 2008 (18) :141-143.

[10]李磊.基于CMM的软件过程改进方法的研究[D].西安:西北工业大学, 2007.