软件过程改进范文

软件过程改进范文（精选12篇）

软件过程改进 第1篇

关键词：中小型软件企业,CMMI,软件过程改进

国际上采用的软件过程改进模型如CMM/CMMI是软件过程改进领域的重要成果,它是适用于软件企业质量管理和过程改进的重要标准。但是,这些模型主要是针对大型软件企业的,对于国内为数众多的中小型软件企业并不完全适合。因此,寻找一种适合国内中小型软件企业的软件过程改进框架显得非常重要。以下在分析和借鉴CMMI和SPP理论基础上,研究出了一个面向国内中小型软件的软件过程改进框架(Software Process Improvement Framework,SPIF)。

1 构建SPIF的理论基础

1.1 CMMI的过程域(KPA)

CMMI过程域分为四类,过程管理类,项目管理类,工程类和支持类。

过程管理类的过程域包括组织过程焦点(OPF)、组织过程定义(OPD)、组织培训(OT)、组织过程性能(OPP)和组织革新和部署(OID)。

项目管理类过程域包括项目策划(PP)、项目监督与控制(PMC)、供应商协议管理(SAM)、集成项目管理(IPM)、风险管理(RSKM)、集成团队(IT)和定量项目管理(QPM)。

工程类过程域包括需求开发(RD)、需求管理(REQM)、技术解决(TS)、产品集成(PI)、验证(VER)和确认(VAL)。

支持类过程域包括度量与分析(MA)、过程和产品质量保证(PPQA)、配置管理(CM)、组织集成环境(OEI)、原因分析和解决(CAR)、决策分析和解决(DAR)。

1.2 SPP理论

SPP(Simplified Parallel Process),“精简并行过程”是林锐博士于2002年提出来的。SPP是对CMMI3级以内各过程域的内容和要求作了“精简”处理而创作出一种“软件过程改进方法和规范”。它由众多的过程规范和文档模板组成,主要用于指导国内软件企业进行软件过程能力的持续地改进。CMMI是SPP的主要参考标准,但是SPP并不是对CMMI进行简化处理后的结果。两者都是用于指导软件过程改进的方法论,CMMI主要论述“应当做什么才能使软件过程能力达到CMMI某种等级”,而SPP则论述“应当怎样做才能使软件过程能力达到CMMI3级水平”。

2 面向国内软件企业软件过程改进框架(SPIF)的建立

2.1 SPIF中的过程域(KPA)组成

SPIF(Software Process Improvement Framework)的建立是基于CMMI2、CMMI3级中的KPA,SPIF中的KPA分别是需求管理、需求开发、系统设计、代码实现与测试、项目策划、项目监督与控制、立项管理、结项管理、度量与分析、过程与产品质量保证、配置管理,本框架结合了中小型软件企业的特点,具有较强的针对性。

2.2 SPIF中各KPA的分析

2.2.1 需求管理过程域

需求管理过程域是许多过程域实施的前提,其目的是管理项目的产品和产品构件的需求,标识哪些需求与项目计划及工作产品之间不一致。通过适当的步骤,确保需求在项目的各个层面上动态地保持一致,一旦出现不一致,则启动相关的处理过程域,使其调整到一致。

2.2.2 需求开发过程域

需求开发是一个重要的过程域,它的质量决定了研发产品的方向。如果需求没有把握准确,不仅产品在研发过程中需要返工,而且上市后不能满足客户的需求,那么必然使企业利润的获取大打折扣,从而影响企业的发展。其目的是产生和分析用户需求、产品需求和产品组件需求。

2.2.3 系统设计过程域

系统设计过程域是对产品的体系结构、用户界面、模块、数据库等进行设计,从而在需求和代码之间建立桥梁,指导开发人员去开发产品。

2.2.4 代码实现与测试过程域

代码实现与测试过程域的目的是根据的用户需求,系统架构,系统设计的要求编写并测试整个系统的代码,确保产品最终满足用户的需求。

2.2.5 项目策划过程域

项目策划是对人员角色、任务进度、经费、设备资源、工作成果等等做出合适的安排,制定出一些计划(包括高层的和细节的),使大家按照计划行事,最终顺利地达到预定的目标。其目的是为项目的开发和管理工作制定合理的行动纲领(即项目计划),使所有人员按照该计划有条不紊地开展工作。

2.2.6 项目监督和控制过程域

为了保证软件系统在预期的工作量内按时保质的完成,需要定期地对其主要项目进行跟踪、监测和调整,跟踪的对象通常有规模、工作量和成本、计算机资源、进度、风险和软件工程技术活动等。其目的是通过周期性的跟踪项目计划的各种参数,不断了解项目的进展情况,以便当项目实际进展状况明显偏离计划时能够及时适当地采取纠正措施。

2.2.7 立项管理过程域

通过规范化的流程,判断并采纳符合企业根本目标的立项建议,提供合适的资金和资源,使立项建议成为正式的项目,并进行相应的筹备活动。反之,拒绝不能给企业带来利益的立项建议,避免浪费人力资源、资金和时间。

2.2.8 结项管理过程域

结项管理过程域是对项目的有形资产和无形资产进行清算,以利用可复用的软件成果;对项目进行综合评估,如评估项目完成情况、项目质量、项目对企业的贡献等,评估报告可作为考核项目人员业绩的重要依据;总结经验教训,将产品入库,形成组织财富。

2.2.9 度量与分析过程域

现代软件工程理论认为,要想控制软件质量就必须进行软件度量,软件度可分为产品度量、项目度量和过程度量。它们分别对软件产品质量、软件项目实施质量和软件过程质量进行量化,软件度量是成功实施过程改进的保障。其目的是在于发展和维持度量能力,以便支持对管理信息的需要。

2.2.1 0 过程和产品质量保证过程域

过程和产品质量保证过程域引入的动机是为了有一个相对独立于项目的成员,能够以第三方角色保证项目组成员遵守事先的约定,遵守作业流程以及对产品制定的标准和规则,这就好像社会中的司法部门,起监督执行的作用。其目的是使工作人员和管理者能客观了解过程和相关的工作产品,确保所策划的过程得以实施,从而支持交付高质量的产品和服务。

2.2.1 1 配置管理过程域

配置管理过程域目的是运用配置标识、配置控制、配置状态统计和配置审计,建立和维护工作产品的完整性。

2.3 SPIF各KPA与CMMI2、CMMI3的对应关系

表1为SPIF的KPA与CMMI2、CMMI3级KPA的对应关系。

2.4 SPIF的评价

为了检验SPIF效果,特设置了一个评分规则,列出一系列评分指标及权重,并通过对中小型软件企业进行调研和邀请几位专家进行评价。具体评价过程如下:

1)列出10个评分指标,每个指标的分值满分为10分,这些指标是:(1)能否产生符合软件规格说明的软件;(2)软件过程能否完成客户提出的要求;(3)是否易于被软件工程师理解;(4)是否易于被软件工程师接受和使用;(5)每个过程是否能取得明确的结果且对外可见;(6)是否会出现过程错误;(7)能否受意外发生问题的干扰;(8)是否易于得到计算机辅助软件工程的支持;(9)过程可否随软件组织需求的变更而演进;(10)能否较快地完成软件开发而交付。

2)设定效果基准值:不及格(60分以下);及格(60-70);良好(70-85);优秀(85-100)。

3)邀请5位专家,针对评分表进行打分,最后得到五位专家的评分分别为75分、85分、90分、88分和78分。

4)综合专家打分结果,进行加权平均,计算最终评分结果为83.2分,与基准值进行比较,确定效果为良好。

通过以上评分过程及评分结果,说明SPIF确实能为中小型软件企业的软件过程能力的提高以较大的帮助,能够为软件组织带来科学的、合理的软件过程,从而为产生高质量的软件产品提供有力的保障。

3 结束语

SPIF是在综合考虑国内中小型软件企业特点的基础上以CMMI和SPP理论为基础构建的,其目的是帮助国内中小型软件企业的软件过程能力。今后的工作需要在更多实践的基础上对SPIF进一步规则化和细化,以提高其可操作性。

参考文献

[1]Dennis M.Ahern,Aaron Clouse,Richard Turner著.CMMI精粹—集成化过程改进实用导论[M].第二版.北京:清华大学出版社,2005.

[2]Neil S.Potter,et al.软件过程改进简明实践[M].北京:机械工业出版社,2003.

[3]Capability Maturity Model-Integration(CMMISM)Version1.1for Software Engineering[S].Staged Representation,2002.

[4]林锐,王慧文,董军.CMMI3级软件过程改进方法与规范[M].北京:电子工业出版社,2003.35-210.

[5]罗运模,谢志敏.CMMI软件过程改进与评估[M].北京:电子工业出版社,2004.22-118.

航天软件过程改进实践 第2篇

航天软件过程改进实践

为了改进软件过程,提高软件开发效率,保证软件产品质量,北京航天自动控制研究所在6月启动了基于GJB 5000-《军用软件能力成熟度模型》等级2的软件过程改进工作,于9月通过了军用软件能力评价组的`评价.本文介绍了北京航天自动控制研究所的软件过程改进实践,阐述了软件过程改进实践中取得的成绩和教训.

作 者：石柱 Shi Zhu 作者单位：北京航天自动控制研究所,北京,100854刊 名：航天控制 ISTIC PKU英文刊名：AEROSPACE CONTROL年，卷(期)：24(2)分类号：V448关键词：软件 软件工程 软件过程改进 软件能力成熟度模型

软件过程改进 第3篇

摘 要：随着计算机的迅猛发展，网络技术的不断进步，在自身硬件组成与软件设计方面取得了突破性的成就，极大地便利了人们的工作与生活。计算机在发展的过程中，除了重视自身硬件性能的提升之外，逐渐将系统软件的开发作为一项重要的内容，以此从系统软件构成方面来满足多样化的使用需求，为了保证计算机系统软件的科学开发，该文旨在从软件工程技术的角度出发，在相关科学理论的指导下，对其在系统软件开发过程中的科学高效运用进行全面探索，以期提升系统软件开发的质量与水平，促进计算机产业的健康发展。

关键词：系统软件开发 软件工程技术 原则 运用方式

中图分类号：TP311.52 文献标识码：A 文章编号：1674-098X（2016）06（c）-0083-02

计算机技术以及互联网技术的快速发展，使得计算机应用的范围日益广泛，逐渐成为现阶段社会生产与生活中重要的工具。系统软件作为计算机软件系统的核心构成，通过自身的逻辑语言与数学算法，在很大程度上满足了计算机使用者的使用需求，实现了经济生产与社会生活的智能化[1]。为了进一步提升系统软件开发的质量与水平，使得系统软件能够满足越来越多样化与专业化的使用需求，我们将软件工程技术引入到系统软件的开发过程中，通过这种方式促进系统软件开发的效率，实现系统软件开发的人性化与信息化。因此在现有的技术条件下，探究软件工程技术在系统软件开发中的科学高效应用就有着十分重大的现实意义。

1 传统软件应用程序与软件开发分析

对传统软件应用程序与软件开发的客观分析，能够帮助参与系统软件设计的相关工作人员进一步厘清传统软件应用程序中存在的不足，并以此为基础为软件工程技术在系统软件开发中的运用准备条件。

1.1 传统软件应用程序开发工程分析

在传统软件应用程序开发工程中，为了保证程序开发有序进展，在软件应用程序开发之前需要进行模型的构建，并根据软件应用程序的设计需求与使用环境，在相关软件开发理论的指导下，对软件开发模型进行多次计算与修改，形成生存期模型，而生存期模型在实际的开发过程中又产生了诸如演化型、螺旋型以及增量型等多种形式[2]。从实际情况来看，无论是何种形式，这些模型在软件应用程序开发的实际操作中，都表现出一定的不足，存在缺陷。例如演化型模型能够对软件开发流程进行科学的优化与调整，从而便于软件应用程序的有效管理，大大降低了软件应用程序开发过程中出现错误的几率，但是如果其中的某一个环节出现了差错，将会造成整个软件开发流程的紊乱，对软件应用程序开发的稳定性带来极为消极的影响。随着社会经济的不断发展，互联网技术以及计算机技术的日益成熟，虽然现阶段大多数的软件程序仍是以WWW为构建进行设计与开发，但是为了满足经济快速发展的要求，相关企业不断进行软件开发与管理流程的优化，以期使得软件开发工作能够适应国民经济发展与社会生活的客观要求。但是我们必须看到传统软件应用程序的开发模式已经越来越难以满足实际要求，这就要求相关企业要立足于软件应用程序设计开发的实际，进行全新模式的科学探索。

1.2 软件应用系统分析

传统软件的开发周期较长，应用程序日益复杂，在很大程度上难以满足社会经济发展对软件应用程序更新换代速度的客观要求。系统软件开发作为一种新的软件开发模式，以软件作为构建的基础，对于数据信息有着较强的处理能力，并且以页面作为主要的展现形式，在一定程度上满足了不同软件应用程序使用者的不同使用需求，并且凭借着自身对各类技术与软件功能的科学整合，其能够在很大程度上缩短软件应用程序开发周期，提升应用程序的简洁性与使用性[3]。

2 系统软件工程技术在系统软件开发运用中应遵循的原则

（1）系统软件工程技术在系统软件开发中的运用必须要遵循科学性的原则。系统软件工程技术在系统软件开发中应用目标的实现，要充分体现科学性的原则，只有从科学的角度进行系统软件工程技术重要性、系统软件开发流程以及相关工作人员的职业素质与技能进行细致而全面的考量，才能够最大限度地保证系统软件工程技术在系统软件开发中的应用满足实际的系统设计需求与企业应用的要求，只有在科学精神、科学手段、科学理念的指导下，我们才能够以现有的技术条件为基础，进行系统软件工程技术在系统软件开发过程中的科学高效运用。

（2）系统软件工程技术在系统软件开发中的运用必须要遵循实用性的原则。系统软件开发相关工作的科学高效运行，需要雄厚资金的支持，从实际来看，资金的稳定供应与否直接影响到系统软件开发工作的质量与水平，因此系统软件开发在进行系统软件工程技术应用的过程中，必须要遵循实用性的原则，最大限度降低系统开发企业在设计与构建过程中系统软件的开发建设与应用成本，降低系统软件开发企业在软件开发方面的资金投入，从而能够将更多的资金利用于其他方面，促进系统软件开发企业自身的健康快速发展，提升其经济收益。

3 软件工程技术在系统软件开发过程中运用的途径与方法

软件工程技术在系统软件开发过程中的运用是一个复杂的过程，需要相关软件设计人员充分认识到传统软件应用程序开发中存在的不足，并在相关原则的指导下，从多个方面入手，采取多种方式，实现软件工程技术在系统软件开发过程中的科学高效运用。

3.1 软件开发模型的科学构建

软件工程的特殊性使得软件应用系统的设计与开发与传统的软件开发工作有着极为明显的区别。而为了保证软件工程技术在系统软件开发中的科学高效运用，就需要进行软件开发模型的科学构建，通过对整个系统软件应用程序的科学解读，对开发周期、基本流程以及软件开发管理工作的重点进行梳理，以此为基础进行软件开发模型的构建，同时为了保证模型构建的质量与效果，还需要进行项目管理模型以及组织公共模型的建立，通过这种方式及时发现软件开发模型中存在的不足，并对其原因进行考察，找出应对差错的方式，从而保证开发流程的有序进行[4]。

3.2 软件应用程序的开发

通常情况下，软件应用程序的开发会以系统软件的迭代升级作为自身的组织框架，在软件一次次地更新中，对软件的性能以及潜在的发展方向进行准确判断，也就是说软件应用程序涵盖了软件开发的各个方面。所以为了充分发挥软件应用程序开发的作用，就需要对软件使用者的使用需求进行客观分析，并以此为基础，组织相关技术人员对相关数据进行分析，从而为下一阶段的软件应用程序的使用需求、设计重点以及性能测试提供有效参考[5]。同时我们也必须看到软件应用程序开发的最终目的在于满足用户的使用需求，因此在进行软件的开发设计中，要对软件应用界面进行科学的优化，并在这一原则的指导下，对用户的使用习惯进行全面了解，对于用户感兴趣的内容、重要资讯以及核心内容安排应用界面的合理位置，通过这种优化能够让用户在满足使用需求的同时，充分满足自身的审美体验，从而大大提升用户使用软件的频率，实现高效开发与合理利用。

3.3 软件工程管理的有效运用

立足于计算机硬件加速升级的趋势，以硬件为支撑，不断提升软件工程管理的效率。软件工程管理与软件开发技术有着较为密切的联系，因此软件工程管理水平的提升，就需要不断进行软件开发技术的完善与调整，使其能够满足实际的管理需求。

参考文献

[1]邱恩海.软件工程技术在系统软件开发过程的应用[J].信息化建设，2016（4）：129-130.

[2]王楠.系统软件开发过程中的软件工程技术[J].中国科技博览，2015（45）：90.

[3]周敏.系统软件开发过程中的软件工程技术[J].电子制作，2015（8）：85-86.

[4]郑彦平.系统软件开发过程中的软件工程技术[J].电子测试，2014（24）：122-123.

软件过程改进 第4篇

从最初作为硬件的附属物开始,软件已经发展到当今作为硬件设计的标准之一的时代。它有三个要素最为重要:应用,开发技术和开发管理。如何提高软件的质量将是所有软件企业所要面对及需要解决的问题。

2 如何界定项目的成功与否

2.1 项目失败的原因

项目被迫取消、不能按时交付使用、超过预算、质量低。

失败的原因可以是:人的因素、技术因素、政策因素、资金因素、方法因素。

人为因素――很少有项目管理人既能100%地满足项目的业务需求又能解决问题。此类问题包括了诸如人员流动、业务需求的稳定、业务需求的理解以及技能等因素,这些因素每一个都足以毁掉整个项目。

技术因素――技术因素也可能造成项目的失败。这些因素包括了诸如响应时间太长、数据传送带宽不够,以及不能在硬件平台上采用某种软件。

政策因素――政策因素是个人在公司中为了自身获得利益,或者至少从别人那里得到这些利益而进行的。它有4个等级,有公司级的政策、开发小组级的政策、个人级的政策何业务与IS的竞争政策。

资金因素――如果资金不足,那么项目注定要失败的。这个不是秘密,资金不足会挫伤项目小组成员的信心,他们可能会想抄近路,可能会忽略细节,并且设计出内容不够完整、结构松散的项目计划,最终导致项目的失败。荒谬的是,一个有充足资金的项目也会因为一些其他的原因而失败。过多的资金也会造成一系列的低效率和冗余的行为,这种情况也会分散项目管理人成功提交项目的注意力。

方法学――方法学对于项目的成功与否非常重要,然而过于的依靠方法学,或者要么完全抛弃它,最终也可能导致项目的失败。

2.2 成功的项目

人们都认为如果一个项目能够在预算内及时地完成所有的项目目标,那么这个项目就是成功的。项目也可以说是各种利益、条件、因素、行为和效果同时作用的产物,我们可以用预算、用户需求、时限、产品质量和用户的满意度来衡量项目是否成功。

项目成功的因素:

1)招募技术熟练、经验丰富的人员。

2)应用前沿的、但非极端前沿的技术。

3)运用正确的开发流程。

4)提供适当的工具。

5)应用源文档控制管理。

6)应用有效的评估方法。

7)将工作细化为小的目标。

8)应对不断出现的变化。

9)项目领导。

10)创新的氛围和文化。

3 有利于成功的前期过程

要成功的完成项目,首先要对项目的失败的原因进行分析,通过合理选择和裁剪软件过程,提高软件项目的成功率。

3.1 角色裁剪

风险决策的一般过程如图1。

决策过程中用到的数据如图2所示。

回避风险的主要责任者包括如下几种角色。

1)产品经理:极有可能导致市场失败;

2)项目经理:极有可能导致进度、成本失败;

3)架构角色:极有可能导致技术失败;

4)系统分析角色:极有可能导致需求失败;

5)质量角色:极有可能导致质量失败。

不同角色的主要责职如图3所示。

不同角色的主要能力要求如下所述:

1)产品经理:市场预测能力(市场营销能力);

2)项目经理:项目估计、项目组织、控制;

3)系统分析角色:系统分析能力(一般的技术能力);

4)架构角色:高的技术能力;

5)质量角色:中等的技术能力。

角色裁剪,即低可行性兼任,见表1。

需要重点声明的是:一个项目团队,团队的知识结果非常重要。

3.2 过程的裁剪

过程裁剪,即是指过程的内容可以进入下一个过程。例如:

1)裁剪“市场风险决策”,一般用于投标的项目;

2)裁剪“项目估算”,适合于约定可以迅速达成(比如:重复的项目)的场合。

有些不恰当的过程裁剪,比如市场风险较大的产品,裁剪“市场风险决策”,则可能会浪费“项目估算”或者“约定”花费的工作量。

也可把增加过程看做一种裁剪,比如增加估算过程1,估算过程2.

我们可以把增加的评审也当做一种过程的增加,或者反之。太长时间(比如2个月)不做项目管理评审,可能导致项目管理的低效;太短时间(比如1周)进行项目管理评审,可能导致评审不经济。

3.3 约定的说明

《需求规格说明书》和《项目计划》是主要记录约定的地方,而《合同》是衍生物,因为:1)外部合同的签订时机取决于多种因素,比如市场战略的需要等;2)外部合同的形式和内容,取决于双方的要求。而《需求规格说明书》和《项目计划》是软件组织项目管理的真正需要。

需要注意的是,合同一般会在约定完成期间签署,否则,合同会有较大的风险。

4 有利于成功的后期过程

4.1 软件过程

1)与所有失败相联系的过程。同行评审,正式技术评审,正式管理评审;SQA;SCM;培训。

2)技术失败相联系的软件过程。系统分析、软件架构。

3)需求失败相联系的软件过程。需求开发、需求管理

4)质量失败。软件架构、测试过程、bug管理、Release过程。

5)进度失败/成本失败。进度估计、成本估计。

6)项目计划、项目监控、组间协调。CMM模型针对这些过程,都提出了重要的评价准则。

4.2 裁剪

1)过程裁剪:评审类型的选择;改变需求的过程。

2)模板定制:需求工作产品;设计工作产品。

3)工具选择:正如制定计划用Project98或Ms Office一样,进行工具的选择。

4.3 过程改进

过程对需求失败的影响曲线如图4所示。

改进产生缺陷的过程如图5所示。

提前缺陷的排除阶段如图6所示。

手段:同行评审、细化需求、设计阶段、细化测试阶段;采用迭代/增量的过程。

4.4 过程管理是项目管理的重要部分

理解了裁剪,才真正理解了软件过程。依据数据来裁剪过程会比较好,这是CMM4的要求。

裁剪过程,是基于经济性考虑的,而不是质量。

4.5 成功的因素和过程

根据Standish Group 1995,项目成功的因素如表2所示。

从以上资料可以得出应该优先关注的过程是:

1)优化需求工程,保证用户参与;

2)优化高层经理的支持过程;

3)优化项目管理的过程。

每个组织均有的过程数据,基于这种过程数据,才可以更好的进行过程改进。

4.6 过程管理的公理系统

1)过程不能无限细化。

公理的使用:裁剪软件过程,使得在过程质量与过程效率之间有一个较好的权衡。

2)风险决策尽可能提前。

公理的使用:采用Spiral模型和快速原型法。

3)尽可能实行并开发定律。

公理的使用:V模型;迭代/增量模型。

4)减少变更(返工)的发生。

公理的使用:工作产品的质量评价(比如,评审)。

5)质量在过程中。

公理的使用:CMM2级的SQA过程。

5 结束语

软件技术可以提高软件过程的性能,比如重用技术,可以有效地改善成本/质量/进度。软件过程不能解决技术创新不足,导致项目失败,但可以减少这种失败造成的损失。

归根到底,人的能力是导致失败的深层原因。过程的入口准则之一:过程执行者必须具备相应的能力。

在过程这方面,注意真是管理原理的应用,有助于提高一次性SPI软件过程改进的成功率;设立技术委员会,专家知识共享;加强技能管理;保证上岗人员的能力。基于以上的分析,建立“项目性能评价体系”,作为项目管理咨询的核心部分,将有益于过程改进工作。真正改进软件项目的过程,提高软件过程的效率与有效性,进而做到按期、质量、不超预算地开发出满足客户需求的软件产品才是软件企业真正所想要的。

参考文献

[1]SPIN.软件过程改进实践[M].北京:电子工业出版社,2004.

[2]Persse J.CMMI成功项目管理[M].李晓丽,李虎,刘东懿,译.北京:机械工业出版社,2008.

[3]Purba S,Shah B.如何成功管理一个软件项目[M].陈明,译.北京:中国铁道出版社,2003.

软件过程改进 第5篇

忽然一想，既然大家对软件绿化有这么大的兴趣，何不来个全民参与呢？

于是，决定将绿化 CorelDRAW 的整个绿化过程同步记录下来，并希望大家参与和发表高见，由于本人时间有限，办事拖拖拉拉，可能这个过程会走走停停，也不知何时结束，更有可能以失败而告终，因此，你要有

足够的思想准备啊......

（第一步）：

工具准备：两个

1、Uninstall Manager 4.2 绿色汉化版：用来监视系统文件的变化。

下载：Soft_Show.asp?SoftID=324

教程：Article_Show.asp?ArticleID=206

2、RegSnap  3.0 绿色汉化版：用来监视注册表的变化。

下载：Soft_Show.asp?SoftID=118

教程：Article_Show.asp?ArticleID=205

原版准备：CorelDRAW 9.0 简体中文零售版

www.kingti.com/soft/7926.htm

系统准备：

Article_Show.asp?ArticleID=204

第二步）

进入纯净的 WINDOWS ，运行Uninstall Manager 4.2，点击工具栏最后一个按钮，为 C 盘文件做一个快照：

此主题相关图片如下：

运行 RegSnap 3.0，为系统注册表做第一个快照，并保存为“cd9-1.rgs”：

此主题相关图片如下：

（第三步）安装 CorelDRAW 9.0

这是英文安装界面的简体中文COREL 9.0，因为我的WINDOWS2000是安装在C盘的，因此把COREL 9.0安装在D盘，在安装选项里选第二个“压缩安装”：

高速公路收费软件系统的改进 第6篇

关键词:Linux;收费;图像

中图分类号:U417.9文献标识码:A文章编号:1000-8136(2010)11-0149-03

1 平台的变迁

从1988年上海至嘉定高速公路建成通车以来,我国高速公路经过21年的持续快速发展,覆盖率逐年增大,大大缩短了时空距离,有效降低了生产运输成本,对国民经济发展和社会进步都起到了重要的作用,高速公路的便利正日益改变人们的时空观念和生活方式。与此同时,Windows系统以其友好的图形界面、先进的技术在全球获得霸权地位。我国高速公路收费系统大多建立在Windows平台基础之上,经过多年来的发展矛盾逐渐呈现出来。

1.1建设成本昂贵

随着国家加大对知识产权的保护,使收费系统的建设成本加大,每台计算机需购买一套操作系统。以Windows2000 Professional为例,每套1 988元,以XX省130各收费站588条车道计算,大约购买成本为1 988×588=1 168 944元。而采用开源Linux,可以免费下载获得,无限制安装在所有的计算机,极大降低购买操作系统的费用。

1.2系统硬件要求高、稳定性差

Windows系统开机后,由于其为通用操作系统,运行大量系统级别的服务,占用计算机的资源,所以通常对硬件有较高的要求。这些服务有些用户根本不需要,很可能存在BUG,还会导致系统的崩溃。相比之下,Linux可以根据用户优化配置,精简内核,降低硬件要求。

1.3病毒侵害

随着互联网技术的发展,“黑客”利用Windows操作系统的漏洞编写病毒,迫使Windows补丁加补丁,在此平台上运行的系统随时都有可能崩溃,收费系统的稳定性和可靠性越来越受到威胁,稍有疏忽,后果不堪设想。而Linux以其开源的特点,用户可以根据需求对系统内核重新编译,减少系统漏洞、抵抗病毒。

1.4国产数据库更安全

目前,大多数收费系统采用ORACLE,SQL SERVER,DB2,MY SQL等,这些数据库软件均可实现故障切换,对实时数据处理要求高、数据量大的环境作出优化,系统管理完善、稳定性和可靠性得到认可,具备完善的开发工具,但是,收费系统具备自身的特点,业务功能单一、数据处理复杂度低、数据密集度高、数据种类简单,对数据的安全性有较高要求。当前,国产数据库产品的安全性级别达到B1级,功能完全满足高速公路收费业务的要求,因此,从数据库安全性和支持我国民族软件的政策考虑,价格便宜,应该选用自主知识产权的国产数据库。

2 收费软件优化

目前,各省高速公路联网收费系统已经运行多年,从运营情况看,普遍工作界面友好,用户操作方便,各项功能在一定程度上都满足了用户的需求。但是,随着高速公路管理要求的提高,经营向现代服务业转型,以信息化推进管理现代化,以精细化推进行业规范化,全面建设畅通、形象、阳光、温馨、素质等“五大”工程,积极打造科技、人文、诚信的高速品牌。从操作实用、提升工作质量、工作效率的角度考虑,收费软件的功能设计还有待不断完善、加以优化。

2.1收费员终端功能

(1)温馨问候和路况信息提示。当用户车辆驶入车道,车辆触发感应器,系统语言问候“你好,XXX路欢迎您”。入站收费岛醒目提示“路况信息”,出站提示“本地气候信息”,充分体现人文关怀,而不是单从的收费经营。

(2)收费信息提示。通常,用户只看到“X类车”、“XXX元”。在收费员疲劳或车流高峰期时,容易找错钱,跟司乘人员发生误会。系统优化措施是:在收费窗口外接显示器,收费员刷卡后显示“车号XXXXXX,XX站进入,车类、金额”等信息以及电子线路图,收到司机的现金并输入,点击“确认”按钮后,打印票据,同时外接显示器提示收到“XXX元”,“找零XXX元”。

通过提示,直观、准确、防逃费,司机消费明明白白,也提醒收费员不容易疏忽出错。

(3)票据规范。票据规范有两层含义:其一,收费员上下班、中途、缺票、换票等情况,系统应提醒“核对票据”、“无票”、“还剩X张”等信息。系统要求输入自己所持票据的首尾编号,加以系统核对。如果有误,系统拒绝收费员操作,并自动语音联报票据室人员,直到解除锁定为止才可继续。其二,票据备注栏打印时标明沿途所经过的关键路线,解决多路径明确消费问题。

(4)车辆白名单。随着多元化投资,为了解决多家高速公司并网运行的统一操作,减少人为干预,在收费员终端增加查询功能,对于白名单车辆,可以显示“XX路段免费”、“XX路段收费、金额XXX元”。

(5)现场挂失。为了解决司机丢卡后的繁琐事宜,有效堵塞中途换卡、倒卡等人为逃费漏洞,在收费员终端增加挂失功能,车辆“丢卡”时,必须核实是否领过卡,查到领卡记录的由入口站提供卡号和车辆信息,出口挂失卡号。相同卡号再次通过出口时,提示已注销,该车就应接受经济处罚。

(6)车道图像抓拍。车道图像抓拍不仅可以辅助公安调查各类社会事件,对过往车辆进行记录和监控,更重要的是满足日常稽查需要。随着我国高速公路联网收费的里程日益加长,车辆换卡逃费的手段不断更新,车道图像抓拍成为后期图像存储、查询的基础和保障,意义重大。通常,出口比对不一致时,需要核查入口抓拍图像。

普遍采取的处理方式是车道抓拍、车道保存,并上传至收费站、分中心。随着社会经济的发展,私家车数量增多,各车道的车流量猛增,尤其是节假日,车道每天通行量超过5 000车次/道,车道工控机频繁读写硬盘,降低业务流水工作效率,同时也容易发生故障。

为了解决上述问题,推荐采用如下方式:

(1)模式保存切換。当车流量较少时段,各车道抓拍图像分散保存在车道工控机的较大硬盘分区,并在空闲时上传;节假日、车流量较大时段,为了减少本地读写次数,可以通过车道“图像数据井服务”与站级轮询“数据泵服务”,将抓拍图像数据直接上传到指定IP服务器群的设定目录中,集中保存。时间段、模式切换状态由收费站统一管理。车道数据井服务需要增加分散保存模式下图像搜索功能。

(2)目录和图像命名及保存格式。目录命名推荐为“XXX站年份月份日车道号”,如“武宿D20103278”。图像命名推荐为“班号+下划线+员工号+下划线+时间+下划线+流水号+车牌号”,如“02_1357_091825_4328_晋A5B318”代表02班1357号收费员09:18:25第4328台车晋A5B318。通过加装补光设备,得到清晰画面,图像以JPG格式保存,根据图像质量调整压缩为40～60%。

(3)提高抓拍可靠性。采用一辆车两照片(一张全景、一张车牌特写)进行保存。为了减轻车道工控机的负荷,可以采用外置式USB接口或10/100M局域网接口,将图像传入计算机。

2.2站级、分中心管理

(1)数据科学统计。通过多年运营,全国各省高速公路公司都有自己行之有效的统计方法,满足自己数据统计需求。但是,从省际乃至全国联网的发展需求看,有必要统一统计报表的标准格式,更加科学化、人性化、标准化。一方面,减少人工统计的劳动量、口径不一致产生的误差;另一方面,便于互相交流、核对数据、统一存档保存。比如,增加任意时段的统计功能。

(2)特情記录。根据运营经验,进一步细化特情类别,规范名称、说明原因等用词,使监控稽查人员就像大夫开电子病历一样,勾选类别、项目、原因等,简洁准确,为事后领导的决策分析提供更加科学、真实、快捷的依据。

(3)票证管理。建立票证的统一管理,形成分中心、站票务室、车道三级联网模式。既可以远程实时监管票证的流通环节,又可以及时处理票证错误问题。在站级票务室增加票证编号图像识别模块,当收费员下班交回废票时,通过识别,如果票证库中存在该编号则自动调出当时的废票记录,进行确认;否则需要查明原因,再做记录。这样可以对“重打”和“调整”的废票自动核查,加快流程,加强科学管理。

(4)图像稽查。稽查默认设置为站级集中模式查询,提供指定条件的组合查询,并准确显示记录信息,提供打印和导出图像功能。

2.3精确路径收费

随着高速公路规模和密度的扩大,必然形成环形路网,车辆自主选择行使路径,精确计费和拆分势在必行。采用的方法有最短路径法、全牌照识别法、RFID标识法等,目前多数采用最短路径法。

2.3.1 RFID标识法

近几年来,由于RFID识别距离远、抗干扰能力强、数据存储安全等广泛应用于高速公路多路径识别。车辆在入口领取RFID复合通行卡(卡内有RFID有源电子标签和非接触IC卡),车辆通过高速路标识点,路测系统将标识点编号记录在卡内,出口读出入口和标识信息,从而确定路径完成多路径识别和费收拆分。

虽然目前改造读写器成本较高,但从长远发展看,对精确拆账、保护投资方利益,软件设计逻辑简单意义重大。对于省际之间联网收费,底层读写卡的接口标准、数据结构、密钥等应该有交通运输部统一规划,才能保证后期拆账精确。

2.3.2 全牌照识别法

随着图像识别技术的发展,在高速公路全路段安装抓拍系统,出口比对车牌号来识别沿途路径。其缺点是,车速较快、车牌模糊等往往图像识别准确率有限。

3 存在技术难题

随着高速公路规模的发展,社会需求不断提高,由各省联网走向全国联网,由单一人工收费走向ETC不停车收费,收费系统也在不断创新。遇到的技术问题有:

(1)Linux环境下配套设备驱动不成熟。虽然Linux功能非常强大,但是收费系统所用设备均为工业级,如车道控制机内置的输入/输出接口卡、多串口卡、图像抓拍卡、票据打印机等生产厂家没有提供很好的软件接口支持,这在一定程度上给车道软件的模块化编码、标准化配置产生困难。

(2)数据存储和传输编码困难。高速公路收费系统要求数据可靠、准确,这对数据的存储和备份及传输所采取的技术手段提出了更高的要求。目前,编码方面还存在技术层面的困难。

通过优化软件,使之成为解决实际问题的有力工具,并尽可能减少人为工作失误,尽可能提高统计分析能力,为领导决策提供更加科学、真实、快捷的依据。

4 结束语

为了降低新建和改造成本,对现有基于Windows平台的高速公路收费软件进行技术创新,实现高速公路收费系统可靠、稳定、准确地运行,在全国实现联网后运营更加安全有保障,开发基于Linux平台的高速公路收费软件是一个必然趋势。虽然在Linux平台进行软件开发存在诸多难点,但通过中国人努力采用先进的技术手段都可以予以实现。在收费软件开发过程中,应结合“人文”、“诚信”不断改进流程,提供更好的服务。

参考文献:

[1]姬建岗,吕扬.基于LINUX平台高速公路联网收费软件开发分析[J].中国交通信息产业.2006,6

[2]何奕.高速公路收费系统架构变革[J].中国交通信息产业.2009,1

[3]孙国杰.高速公路联网收费热点问题探讨[J].中国交通信息产业.2009,10

[4]徐振华,邱伟明.车道抓拍图像存储与查询优化方案[J].中国交通信息产业.2009,11

[5]苏浩然,杨光,袁莉.图像抓拍技术在公路收费系统中的应用[J].公路交通科技.2003,6

Highway Charge Software System’s Improvement

Han Ying,Yao Wenli

Abstract: Along with the social informationization’s fast development, the highway charge system for does not stop by the artificial semiautomatic transformation with ETC the charge coexistence way,various provinces networking moves toward the region and even the national Internet gradually,is being open to traffic the scale,the scientific management,aspects and so on operation service have the progressing by leaps and bounds development.

软件过程改进工程研究综述 第7篇

关键词：软件项目管理,软件过程,软件过程改进,软件过程改进工程,软件改进模型

1 引言

软件项目管理在经历了从结构化生产时代，到CMM(Capability Maturity Model for software)模型，已经进入以过程为中心的时代。而软件发展第三个时代，从软件过程技术的成熟和面向对象技术、构件技术的发展为基础，已经渐露端倪。软件改进工程就是把软件改进从单独的软件项目中提取出来，单独作为一个工程项目，对企业组织的所有软件项目的过程改进进行努力和负责。

2 软件过程改进工程（SPI Project）的提出

当前软件的生产和软件项目的管理已经转变为以过程为中心。软件过程改进也出现了CMM、CMMI成熟度模型和ISO系列标准，称这些模型和标准为最好实践。软件过程改进工程的提出把工程的思想和管理理论方法应用到软件过程改进中，把软件过程改进作为一个单独的工程项目来看待，使得它能集中专业的人员和专门的资源，使得软件过程改进可以像一般的工程一样做到可计划、可控制、可管理。

作为一个工程，软件过程改进工程具有一般工程的特点，它适用一般项目管理的理论和方法，需要高层领导的支持，需要一个忠实、专业的团队，受诸多资源的限制、受诸多因素的影响。

3 软件过程改进工程（SPI Project）的结构和特点

3.1 软件过程改进工程的终极目标

软件过程改进项目的目标是改善组织软件过程，促进组织级软件能力的提高。软件过程改进不是一个一蹴而就的事情，是一个持续的、迭代的过程。同样，软件过程改进工程也是一个持续的工程，它不像一般的软件项目有明确的产品或服务，有一定的期限，有相对明确的完工日期。软件改进年工程没有一个可视的产品或服务，它的目标是一个不断完善的过程，因此也要求软件过程改进工程本身的持久性和连续性。因此它的最终目标是组织级软件能力成熟度的持续提高。

3.2 软件过程改进工程的结构

如图1顶层是质量模型，也可以理解为上文提到的最好实践，包括一些成熟度改进模型和ISO标准，使实施软件过程改进和质量管理的理论依据，指导软件过程改进的全过程。中间层是一些影响因素，这是在组织软件过程改进中不可忽略的因素。下层是一系列的软件项目，是软件过程改进工程的工作重点，软件过程改进项目通过对一系列软件项目的作用使得软件过程得到改进，使组织级的软件过程得到持续改进，提高组织软件能力成熟度。

从图1可以看到三层之间的联系。质量模型是依据，以优良的软件工程方法、详尽技术、成熟的测度方法和合理的组织结构等为依托对组织的各个软件项目提供软件过程改进的支持、监督和考核。同时，软件过程改进工程的实施还需要各个软件项目的配合，需要各个项目团队成员对软件过程改进项目的理解和支持，需要各个软件项目组在软件过程改进工程的协调下能做到人力、知识资源的共享。

3.3 软件过程改进项目的特点

软件过程改进工程作为一个工程来说有工程的一般特点，对于软件过程改进工程来说有其独特的解释：

1)就独特的产品或服务来讲，它并没有任何的产品或服务，它的最终目标是得到一个持续的过程，即组织级软件过程得到持续改进、组织级软件能力成熟度得到持续提高;2)就临时的努力来讲，它所进行的工作时间并不短、涉及的人员并不少、任务并不轻。它所进行的努力要比任何一个软件项目都要大，所耗费的时间比任何一个软件项目都要多。但是它的成功是有巨大意义的，也许任何一个软件项目都不能比。

此外，软件过程改进项目还有其特有特征：1)和其他一系列软件工程相互依赖;2)人员和其他软件工程的人员有交叉。

4 软件过程改进工程的改进模型体系

4.1 几种常用的软件改进模型介绍

4.1.1 CMM/PSP/TSP概要

CMM(the Capability Maturity Model for Software)也称能力成熟度模型，是由美国卡内基梅隆大学软件工程研究所(CMU-SEI)组织开发,并于20世纪90年代初正式发表的软件过程模型。SEI将CMM定义为：一种将软件组织对于软件过程的定义、实现、度量、控制以及改进划分为不同阶段的方法。CMM的核心是把软件开发视为一个过程,并根据这一原则对软件开发和维护进行过程监控和研究,以使其更加科学化,标准化。

PSP(Personal Software Process)为软件人员进行软件开发提供了一个规范的个人过程框架，它由一系列帮助软件工程师改善其个人表现的过程描述、度量和方法组成。它提供了表单、指导及流程用以帮助工程师估计和规划其工作，为基于个体的软件过程的优化提供了具体而有效的途径，例如如何制订计划，如何控制质量，如何与其他人相互协作等等。软件过程改进能够并且应该开始于个人级。

群组软件过程TSP(Team Software Process)结合了CMM的管理方法和PSP的工程技能，实施集体管理与自己管理自己相结合的原则，告诉软件工程师如何将个体过程融入小组软件过程，并将小组软件过程与组织进而整个管理系统相联系;通过告诉管理层如何支持和授权项目小组，坚持高质量的工作，并且依据数据进行项目的管理，向组织展示如何应用CMM的原则和PSP的技能去生产高质量的产品。

4.1.2 CMM和PSP/TSP是一个统一的软件过程改进框架

CMM和PSP/TSP是一个统一的软件过程改进框架。首先，PSP/TSP是CMM的发展，PSP使用自底向上的方法来改进软件工程，解决了CMM中存在的只说明“做什么”而没有说明“如何做”得问题，填补了的空白;TSP将CMM的方法进行了扩展以适用于组织级，来指导软件组织CMM的工作。其次，CMM/PSP/TSP相互补充，CMM提供了高效工程所需的整体改进框架;PSP提供了开发人员所需的工程训练，以使他们使用一个详细定义且标准的过程;TSP帮助软件开发组更有效地开发并维护软件系统。为了使软件过程帮助改进软件生产，应该将CMM、TSP和PSP组成一个完整体系进行工作，即从组织、群组和个人3个层次来实施软件过程改进。软件过程框架应该是的有机集成。

4.2 几个改进模型相互联系，共同组成一个体系

虽然上述各种改进模型是在不同的时期，在不同的背景下出现，但其也有共同之处：它们的目的都是改进组织软件过程，为企业软件过程改进提供参考。比如：CMM中关键过程域的概念也得到了ISO15504:2004的引用，PSP/TSP的关键过程域几乎覆盖了CMM所有的关键过程域，CMMI是符合ISO15504的等等。

这些模型和标准大体上分为三个部分：质量管理体系要求、软件过程评价指南和说明、IT过程改进模型。质量管理体系主要是ISO 9000质量体系，软件过程评价指南是指使用模型进行软件过程评价和改进时，指导如何操作的标准文件，IT过程改进模型就是指CMM、CMMI、ISO12207等软件成熟度评价模型。

5 实施软件过程改进工程

5.1 影响软件过程改进工程的因素

软件过程改进项目在实际的实施过程中要充分考虑环境、文化、企业组织结构、员工技能、当前技术水平等影响因素。影响软件过程改进工程成功与否的因素很多，包括技术水平、领导支持、项目管理的水平、度量模型的使用等。图2描述了影响软件过程改进工程的相关因素。其中高层领导的支持和参与、项目管理的水平、可度量的目标和员工的理解和积极参与起到了十分重要的作用。

因此，在实施软件过程改进工程的时候要充分考虑到影响其成功的重要因素，尤其是高层领导的支持和参与。因为软件过程改进工程是整个组织级的改进，它涉及的方方面面比较多也很复杂，没有高层领导的支持是举步维艰。其次是项目管理的技术水平，因为软件过程改进工程的推进在技术上主要侧重在项目管理水平，有高水平的项目管理专家、软件过程改进专家和优秀的项目经理的参与，才能为工程的进行提供技术保证。

5.2 SPI工程和软件项目相互依赖

软件过程改进工程和其他软件项目是相互依赖的。主要表现在：软件项目的软件过程改进需要软件过成改进工程的支持;软件过程改进工程的目标实现需要通过软件项目的软件过程持续改进来一步一步实现。

由于SPI工程和软件工程的高依赖性，要求管理层把管理重心放在软件项目上，通过软件项目的有序进行带动SPI工程，如果没有可行的、成功的软件项目SPI工程也无任何意义。而软件项目过程的改进势必需要SPI工程的技术支持，SPI工程就直接负责各软件项目的过程改进。这样，管理层直接管理软件项目的开发，SPI工程组负责软件项目过程改进并为其提供必要的支持。在双动力的拉力下，企业组织的整体软件能力成熟度得到提高。

5.3 SPI的人员组织形式

SPI人员组织具有交叉性。人员的交叉性表现在软件项目的软件过程改进工作需要软件过程改进工程为其培训人员甚至直接提供专家参与项目;软件过程改进工程的工作也需要有经验的软件项目开发者和管理者参与。

5.4 使用迭代的方法执行软件过程改进

软件过程改进是一个持续的、迭代的过程。其持续性是指它的改进过程没有明确的终点。持续的改进要求不断的识别薄弱环节加以加强和改进。迭代过程是指软件的改进过成不是一个线形的、按部就班的。它允许而且要求有返回。以TSP为例，TSP团队阶段性地进行重新启动。因为TSP遵循反复演进的开发策略，阶段性的重新启动是必须的，这样每一个阶段或周期可以基于根据上一个周期获得数据总结的知识进行计划。

重新启动同样要求更新工程师的详细计划，通常这些计划仅仅在几个月内是精确的.在TSP启动的时候，团队要编制今后三、四个月的总体和详细计划。当团队成员完成一个项目阶段或周期的所有或大部分的工作，他们将根据需要修订总体计划并为以下三、四个月编制新的计划。

5.5 选择CMMI作为改进模型

建议使用CMMI作为改进模型，因为：CMMI改进了CMM，在软件领域集成了SW-CMM和SE-CMM。它提供了更多的改进指南，不仅指出了“做什么”而且对“如何做”也作出了一些指导。

然而，CMMI也有两种不同的实施方法，其级别表示不同的内容。CMMI的一个实施方法为连续式，主要是衡量一个企业的项目能力。企业在接受评估时可以选择自己希望评估的项目来进行评估。因为是企业自己挑选项目，其评估通过的可能性就较大一点。但是，它反映的内容也比较窄一点。它仅仅表示企业在该项目或类似项目的实施能力达到了某一等级。

另一种实施方法为阶段性，它主要是衡量一个企业的成熟度，即企业在项目实施上的综合实力。企业在进行评估时，一定要由评估师来挑选企业内部的任何项目，甚至于任何项目的任何部分。一般地讲，一个企业要想在阶段性评估中得到三级，其企业内部的大部分项目要达到三级，小部分项目可以在二级，但绝不能够有一级。

虽然CMMI的表述方式不同，但其实质内容是完全一样的，是同一种方法的两种不同的表述方式。因此，不管企业需要做什么样的评估，企业所获取的实惠差别并不大，具体要做连续性评估还是阶段性评估，则要看企业对等级评估证书的具体要求。

6 结束语

软件过程改进工程的提出和实施可以极大地提高组织级软件能力成熟度，对软件外包服务获得者来讲，可以对它的提供商进行客观的现时和预期的评价;对软件工程来讲，客观评价当前的或可能的软件开发能力，识别软件开发中各种行为并给他们安排合理的次序，这样可以提高软件开发水平规划软件过程改进行为;对软件开发商来讲，可以展示软件开发商的软件开发能力，形成自己优势，有利于开拓市场。

参考文献

[1]吕晓辉,吴健,胡正国.基于CMM/PSP/TSP的软件过程改进[J].计算机工程,2003,29(4):11-13.

[2]张月强,唐胜群,刘伟.基于CMM/PSP/TSP的软件开发模型[J].计算机工程与应用,2003,39(1):132-134.

[3]许江林,刘景梅.IT项目管理最佳历程[M].北京:电子工业出版社,2004

[4]李琳.基于CMM/PSP/TSP和XP的软件开发过程方法研究:[D].四川:四川大学,2004.

基于度量的软件过程改进研究 第8篇

基于此,本文将软件度量深入到每一个具体的软件过程中去,给出基于度量的软件过程改进模型SPIM。确定要实现该软件过程所需采集的度量数据,然后对采集的数据进行分析,量化地了解该软件开发过程的优势和弱点,根据度量结果采取相应的改进措施,从而提高软件开发的质量。

1 基于度量的过程改进模型SPIM

过程度量是实施过程改进的基础。过程改进是利用过程运作所获得的反馈信息,发现当前软件过程存在的问题和缺陷,提出改进的意见,进而实现软件过程的改进和完善。

过程度量与过程运作紧密相关,是一个由多个角色,在一定的条件和约束下,按计划进行的一系列活动。

过程度量的主要活动

软件过程度量的过程由数据获取和度量分析组成,其中数据获取包含数据采集、数据验证两个活动。而度量分析包括数值转换、数据分析和度量决策三个活动。

数据采集,是过程度量的基础,用于收集与所要求的度量值相关的基础数据。合理选取数据来源,开发各种各样的标准化的报表,使用有效的数据收集工具是实现数据获取的重要手段。

数据验证,包括两个方面的活动内容。一方面是检查数据采集的过程是否按计划执行,另一方面要验证每个度量活动的输入和输出是否是正确的、满足要求的。

数值转换,数据获取阶段得到的数据杂乱无章,必须经过加工处理即进行适当的数值转换才能用于度量分析。数值转换的任务是进行数据标度,实现从观察得到的状态到一个数值范围的映射。

数据分析,利用适当的工具和方法,将经过数值转换汇总或计算的度量结果进行比较分析,并发现所度量的过程存在的问题。

度量决策,管理者在清晰地了解到当前过程存在的问题或需要改进的内容后,提出相应的过程改进意见,同时按照一定的决策分析处理(DAR)方法做出下一阶段过程度量的目标和内容,从而引发在新的软件过程周期中实施新的过程度量与改进。

2 模型的应用实例

2.1 需求数据的采集

针对某软件公司的八个项目的跟踪,得到项目的需求数据在不同开发阶段分布记录如表1和表2:

表1和表2是在对这八个项目采集到的数据,经整理得到。

2.2 需求工作过程分析

根据表1和表2中采集的需求分布数据,针对所采集的这八个软件项目的需求工作量分布数据,将其按阶段计算出平均值。

那么,从表中这些数据,我们可以看出:

1)需求工作量与完成情况分布在项目生命周期各阶段,反映了实际的项目状况,但没有一个项目的需求工作计划与此一致。

2)在需求开发阶段,投入了超过40%的需求工作量,所能获得的稳定需求成果不足35%,成效不足。

3)在需求开发之后,投入了51%多的需求工作量,所能获得的稳定需求成果超过59%,时效不足。

4)编码、测试、试运行所获取的需求工作成果超过30%,并且呈递增趋势,说明需求阶段工作质量存在问题,这也是实际的项目状况的客观体现:编码时间长、试运行时间长、迟迟达不到验收要求。

2.3 需求工作改进措施

1)原需求管理过程

通过以上的数据分析以及在公司的调研,我们发现公司的需求管理过程存在着如下问题。需求表述与客户理解不一致导致返工;忽视对客户高层需求的获取引发问题;过程对需求分析的要求不明确,缺少分析活动;没有开展需求跟踪活动,对开发工作的真实进展以及是否达到交验状态缺乏管理审核,也缺乏相应的报告信息;需求变更记录不完整、方式随意,缺乏审核审批手续,对变更工作量管理失控;因需求变更导致需求、设计、编码文件的一致性差。

2)需求管理过程改进措施

针对公司原来的需求管理过程存在的问题,我们对需求工作提出如下改进策略及改进措施:

需求过程问题的改进:

改进的主体是公司的软件研发中心,质管部协助支持。改进的主要内容要求是将需求开发与需求管理合并为“需求工程”过程;重新定义需求开发与管理控制活动,重点加强需求开发支持和指导(模板、指南),以及加强需求管理控制的需求评审、审批、变更控制;尽可能在图形表达、文字表述、表格模板等方面进行统一要求对需求工作成果进行量化管理。

需求获取问题的改进:

改进的主要内容要求,总结好的需求获取方法、经验及问题教训,形成需求获取工作指南、知识库、或标准过程;加强需求获取前的准备工作;明确需求调研阶段性完成标准,评估需求获取的“量与质”,并为澄清需求问题、沟通达成理解一致留足时间。

需求分析问题的改进:

改进的主要内容要求,总结好的需求分析方法、经验及问题教训,形成需求分析工作指南、知识库、或标准过程;采用统一的需求规格表达样式,实现需求工作量化,支持项目规模描述、计划与监控、需求变更与跟踪;加强需求的同行评审,落实评审资源及责任。

3)改进后的结果

我们将提出的需求工作改进措施应用到具体的公司的项目中,那么从公司质量管理部门反馈的信息中,在需求开发阶段的需求工作完成较好,而在后面的设计、编码、试运行阶段的需求工作逐步减少,取得了一定的效果。

3 结束语

本文以软件过程改进为目标,给出一个基于度量的软件过程改进模型SPIM和度量信息框架,本文只对需求过程进行了深入的研究分析,给出改进措施,所以要进一步对其他的过程进行深入的研究分析。

摘要：该文以软件过程改进为指导方向,给出一个基于度量的软件过程改进模型SPIM和度量信息框架;依据SPIM和软件过程度量数据模型,针对在某软件公司的实际项目中采集的8个项目的相关数据,对需求管理方面的数据进行了度量和分析。通过度量和分析,提出过程改进意见和措施。

关键词：软件过程改进,软件过程改进模型,过程数据分析

参考文献

[1]Zahran S.软件过程改进[M].陈新,译.北京:中信出版社,2002.

[2]何新贵,王纬,王方德.软件能力成熟度模型[M].北京:清华大学出版社,2000.

[3]吴洪丽.支持软件过程改进的软件过程度量研究[D].重庆:重庆大学,2004.

中小型企业软件过程改进方法研究 第9篇

过去几十年中,软件的规模和复杂度不断提高,软件开发变得越来越复杂和难以管理,软件项目经常出现质量不高、进度拖延、成本超支等问题。研究和实践表明,70%的软件项目失败不是由于技术实力不够而是因为管理不善造成的。产品的质量很大程度上取决于生产和维护产品的过程的质量,这一结论已在全世界范围内获得认可[1]。20世纪80年代末期,Humphrey等率先将过程改进理念引入到软件项目管理当中,并进而形成能力成熟度模型CMM(Capability Maturity Model)及能力成熟度模型集成CMMI(Capability Maturity Model Integration)[2]。目前,CMM/CMMI已经被广泛应用于现代软件企业的过程改进和评估当中。以北京为例,在实施过程改进的企业中,64.94%采用了CMMI作为过程改进的指导框架,远远高于其他质量标准,如ISO9000(50.65%)、PMBOK(16.98%)等[3]。

但是,CMM/CMMI的提出主要源于大型组织的开发经验,而我国软件企业中大多数是中小型企业,以软件从业人员的数量为标准,人数在1000人以上的大型企业只有少数几家,50人以下的企业则占到全行业的55%以上。对于这些中小型企业来说,CMMI过于庞大和复杂,实施起来存在很多困难,致使众多中小型企业缺乏组织软件过程改进或向更高成熟度级别迈进的动力[4]。一直以来,业界和学术界都在尝试和探索适合中小型企业的软件过程改进方法。林锐等在对CMMI3级以下过程域进行“精简”处理的基础上提出精简并行过程SPP[5],龚波等从文档、管理、评审、资源、培训等方面讨论了小型企业裁减CM-MI模型的一般原则[6],朱卫平、孙晓海、邢敏等各自分享了自身在中小型企业的过程改进案例[7,8,9]。从本质上讲,这些方法的研究重点都是侧重于如何裁减CMMI来定义适合中小型企业的过程模型。但是,要实施过程改进,只有过程模型还不够,还需要有一定的方法步骤来说明过程改进活动到底如何实施和持续推进。卡内基梅隆大学软件工程研究所建议采用IDEAL方法[10]。但是,IDEAL只是一个关于如何引入新技术的宏观框架,需要过程改进人员实例化为具体的策略和方法,即使在大型企业也通常需要在专业咨询机构的引导下使用,对于缺乏足够资金实力而过程基础又比较薄弱的中小型企业来说,IDEAL方法很难实施。

本文结合一个典型中小型企业的软件过程改进实践提出了一种软件过程改进方法。该方法与IDEAL相比,对每个步骤及活动究竟应如何实施定义得更为具体、更容易理解,更为清晰地描述了如何通过反复的迭代增量实现过程改进的持续推进。

1 中小型软件企业的特点

什么样的企业属于中小型软件企业,业内一直没有统一的标准,一般认为,软件从业人员小于50人的企业为中小型软件企业。中小型软件企业通常具有如下特点:(1)软件过程都是临时拼凑,管理多凭经验,没有统一、规范的过程标准,开发过程随时在变,缺乏有效的计划;(2)组织结构和管理分散,各项目组各自为政,彼此间缺乏资源、技术以及经验的共享;(3)角色和职责定义不明确,经常是一人多职,可能既做管理,又负责需求、设计、编码,甚至测试和维护;(4)资金少,难以组织正式的过程评估和相关的培训活动;(5)人员少,并且流动性大,难以建立专职的过程改进团队;(6)重技术多于重管理,软件开发活动通常由技术精英主导,“黑客文化”色彩较浓。由此可见,中小型企业过程基础更为薄弱,其过程改进需要以更低的成本、更为渐进的方式来实施。

2 中小型企业软件过程改进方法

本文实例是一家处于快速发展期的中小型软件企业(文中称为A公司),有员工30多人。A公司的软件过程改进首先从M项目组开始,M项目组人员配置由一名项目经理和4~5名程序员组成。

针对中小型企业的特点,本文提出如图1所示软件过程改进方法。

该方法定义了一个持续的、迭代增量式的软件过程改进框架。框架中每一轮改进包括5个主要活动:准备软件过程改进、定义软件过程标准、软件过程试运行、软件过程优化和软件过程固化。每一轮改进针对一组特定的实践,这组实践经反复的实施和优化逐渐稳定,之后将其固化,再增加新的实践进入下一轮改进。

2.1 准备软件过程改进

全面实施软件过程改进工作之前,首先要完成一些准备工作。其中,进行组织结构上的准备和对企业过程现状进行评估是两项最重要的准备工作,其他可视企业具体情况而定,如营造过程改进氛围、准备设备工具等。

组织结构准备是指建立过程改进组织、确定相关责任人。中小型企业虽然由于资源限制可能无法成立专门的软件工程过程组SEPG(Software Engineering Process Group),但仍要指定专人负责软件过程和质量管理,此人应直接对高层领导负责,可随时向高层领导汇报过程改进的进展和问题,吸引高层对过程改进的持续关注和兴趣。可以说,企业高层持续不断地关注和资源投入,以及专人坚持不懈、恒心如一地持续推动是保证过程改进成功的关键因素之一。

企业过程现状评估是指收集关于企业软件过程执行情况的信息,了解企业现有软件过程的真实状况,找出其存在的主要问题,确定改进的目标和重点。中小型软件企业由于资金和人员的限制通常难以组织实施正式的软件评估,尤其是改进之初,企业在未体验到过程改进的好处之前一般不愿投入太多的人员参与过程改进活动。中小型企业可以采用一些非正式的方法进行内部自评估,如过程实际跟踪、问卷调查、访谈等,或引入一些小型的过程评估方法[11]。其中,过程实际跟踪是指指派一名软件工程专业人员参与一个项目周期(历时3~6个月)的实际开发,通过亲身的过程体验来洞悉组织现有软件过程的运作方式,进而找出现有过程中存在的主要问题。这种方式虽然带有较强的主观性,但对初步开始过程改进的中小企业来说,却简便易行,并能获得较真实的评估结果。这种方式的缺点是周期较长,这在一定程度上可通过“将问题有意放大”使其尽早突出暴露的方式来加以弥补。

A公司在对M项目组的开发过程进行了一个项目周期的跟踪后,得出如下评估结论:

1)过程能力M项目组的过程能力处于典型CMMI初始级别,项目组没有统一的、可执行的软件过程标准。开发过程由技术精英主导(通常是项目经理),过程表现出随机和不确定。整个过程除了需求规格说明文档,几乎没有其他文档输出。

2)项目管理项目启动方式比较随意,主要由技术主管口头传达,并根据心理可接受度指定期望的完成时间。项目组几乎不做任何的技术和进度可行性分析,即根据主管期望的完成时间草拟一个里程碑式的概要计划,粗略设定需求、设计、编码、测试几项主要开发活动的起止时间,之后便匆忙开始需求分析活动。

3)需求开发系统的原始需求主要是在项目会议上由业务人员以“头脑风暴”的形式提出,缺乏有效的诱导手段,需求的获取基本依赖于业务人员的即兴发挥,需求的内容零散、发散,常常是花费了很长的需求分析时间,却仍然难以捕捉到全面的需求,以致在编码和测试阶段后,需求的变动仍然相当频繁,似乎需求永远无法集中和收敛。需求开发结束后有需求规格说明文档输出,但对需求规格的描述不够严谨,存在内容缺失,难以建立真正的需求确认机制。

4)需求管理没有需求跟踪措施,很多原始需求被非正式地记录在会议纪要中,没有专人负责整理和跟踪。如果不是非常迫切,这些原始需求在提出一段时间后通常就被遗忘。即使原始需求已被确认为正式的需求,在项目开发过程中也常常由于技术能力、进度压力等因素,在不经任何变更控制的情况下被随意简化、修改、甚至丢弃。

5)项目计划只制定里程碑节点的概要计划,进度通常是“拍脑袋”方式确定,几乎不做任何规模和工作量的估计,项目开发从来都难以按计划执行。

6)项目跟踪和监控研发经理和高层经理主要通过项目组周例会上开发人员对上周工作的陈述了解项目进展和存在的问题。由于项目计划中没有把工作安排细化到合理的粒度,所以研发经理很难掌握项目进展的真实状况,只能获得“差不多”、“完成80%”等模糊数据,对项目的跟踪控制能力很弱。

7)配置管理建立了软件配置库,配置管理主要以代码为主,没有配置项变更控制流程。

8)过程和产品质量保证软件质量保证手段仅限于系统测试,而且执行得很弱,多数情况是开发人员互相进行交叉测试,没有测试大纲和测试用例,测试执行得相当不充分。

9)同行评审项目主管和项目组成员都了解和承认评审的重要性,但由于技术文档质量不高,常常使得评审会议转化为技术方案的讨论会议,不能形成真正的评审制度。

10)项目结尾项目没有明确的结束标志和验收准则,导致项目总是草草收尾,难以进行正式的成果移交。

根据此评估结果,确定本轮的改进重点如下:

1)加强项目立项管理,确保项目目标明确、有始有终;

2)规范项目中各种管理和技术文档的签署流程,确保阶段产品的完整输出;

3)提高研发经理和高层经理对项目执行过程的控制能力,建立对项目执行情况的跟踪机制,使管理者随时掌握项目的进展情况;

4)建立需求管理机制,提高对需求进行跟踪和变更控制的能力;

5)完善配置管理机制,建立有效的软件版本控制机制;

6)引入科学的评审方法,提高评审效率和评审质量。

2.2 定义软件过程标准

中小型企业的软件过程基础一般都比较薄弱,改进前通常没有统一、规范的过程标准,所以,中小型企业实施软件过程改进首先要做的就是建立起这样一套标准,使项目在开发过程中有章可循,这才构成过程改进的基础,同时也是决定过程改进成败的关键因素。

定义软件开发过程标准主要包括如下内容:

1)首先是选择软件生命周期模型,确定软件开发的执行模式,如瀑布、原型、迭代增量等。由于A公司的业务处于高速发展期,需求还不十分稳定,所以,选择以迭代增量模型作为首选生命周期模型。

2)确定过程中要实施的管理、支持及其他工程类过程域。根据上述改进重点,A公司在首轮改进中选择实施的管理过程域为立项管理、项目规划、项目监督和控制,支持和其他工程类过程域包括配置管理、需求管理和同行评审。

3)对过程域进行裁减。中小企业一般难以在一轮改进迭代中执行所选过程域的所有实践,例如项目监督和控制,不要期望通过一轮改进实现风险、资源、规模、质量、工作量、成本、进度等所有内容的监控,可以在首轮改进中只做进度管理,下一轮再加入工作量的监控,之后再加入质量管理等等。要选择对于解决当前问题最有效、最实用的内容来做。由于各个企业改进目标和重点不同,本文不详细讨论每个过程域的裁减。关于一般裁剪原则,可参考文献[6]。

4)最后,将开发过程文档化,详细描述每个活动的目的、角色及职责、输入、输出、执行流程、结束准则等,并编制相关模板和表格。

A公司的软件开发过程模型如图2所示。根据该模型,A公司初步建立了软件过程质量管理体系,过程资产包括5个流程定义文件、6个工作指引和22个文档模板和表格。

定义软件过程标准应注意的一些原则:

1)软件过程标准的建立不是一次完成的,而是随着改进过程的推进循序渐进完成的。每次根据改进的目标和重点,确定本次实施的内容,对其进行定义,成为过程标准的一部分。随着过程改进的推进,软件过程标准逐步完善。

2)每轮迭代中改进的过程实践要尽可能的少而精,一组实践相对成熟和稳定之后再在下一轮改进中加入新的实践。

3)为了便于项目人员学习和掌握,每类模板要给出相应的示例。

2.3 软件过程试行

选择试点项目,推行软件过程标准。软件过程试行阶段,过程改进人员要进行全程的跟踪,以随时引导开发人员正确地、一丝不苟地执行标准中规定的内容。同时,观察和记录执行过程中发现的各种问题,以便实施对过程的优化。

软件过程标准试行阶段,一定要通过行政力量介入来强制开发过程完全按照标准执行,理解的要执行,不理解的也要执行。这是因为,新的标准如果还没有经过实践就允许大家“优化”,由于每个人以前的开发经历和经验不同,所以必然会产生不同的认识,从而导致新的标准还未实践就被改得“面目全非”。只有通过“僵化”式的推行,才能确切找出标准中存在的问题,同时达到使项目组成员熟悉和掌握过程标准的目的。

试点项目应具备如下特点:项目类型在企业中具有代表性;项目周期最好为6~8个月,最短不少于3个月,最长不超过一年;项目技术风险低,进度压力小。

2.4 软件过程优化

软件过程优化包括两个层次:

1)对软件过程的试行结果进行评估,征求开发人员的意见,识别哪些活动适合本企业,哪些不适合,哪些比较琐碎需要进一步精简,哪些不够细致需要进一步完善,从而进一步修订软件开发过程标准;

2)对开发人员进行技能培训,进一步提高每个活动的执行效率和质量。试行阶段,开发人员主要在质量保证人员的引导下完成每一步开发活动,开发人员更多的是通过模仿学习和了解软件开发过程,目的是使开发人员知道如何做。优化阶段,开发人员由模仿提高为能够更主动地发挥创造力,目的使他们知道如何做得更好。

软件过程优化阶段相对于本轮的软件过程试行阶段来说一般不增加过程实践的数量,只是在过程试运行结果的基础上对已有过程及实践实施质量的进一步提高。

完成过程优化后产生两方面的结果,一方面产生新的改进需求,从调整和定义软件过程标准开始进入下一轮改进迭代;另一方面,对于已经稳定的过程实践,则进入软件固化流程,纳入软件过程资产库进行正式的推行。

2.5 软件过程固化

软件过程固化是指将已稳定的软件过程实践纳入软件资产库,并通过行政审批使其制度化,进而在全企业范围内推行。推行一段时间后,再对软件过程能力进行新一轮评估,从而进入新一轮过程改进迭代。

3 结束语

本文所提方法建立在A公司的过程改进实践基础之上。截至目前,A公司已结束首轮的改进迭代,并表现出初步的改进成效,最为突出的是:

1)项目组建立起了初步的研发秩序,项目组的项目开发不再是随机和无规则的执行,而是有了可参照的过程标准,过程执行更为透明;

2)建立了需求管理机制,减少了需求被反复提出和讨论所花费的工作量;

3)项目组成员养成了实施配置管理的习惯,改善了软件版本混乱和难以查找的问题;

4)规范了文档编制和签署流程,保证了阶段成果的输出;

5)实现了按周对项目进度和工作量进行跟踪和检查,提高了管理层对软件开发过程的控制能力。

A公司的过程现状在中小型软件企业中具有很强的代表性,本文提出的方法和过程可以为中小型软件企业进行过程改进提供很好的示范和借鉴。

摘要：软件质量很大程度上取决于生产和维护软件的过程的质量,这一结论已被广泛认可。我国自20世纪90年代开始关注软件过程改进,先后引入ISO9000、CMM/CMMI等过程模型。但这些模型主要源于大型组织的过程经验,在中小型企业中实施起来存在诸多困难。中小型企业如何实施软件过程改进这一问题在业界和学术界一直倍受关注。结合一个典型中小型企业的软件过程改进实践提出了一个持续的、迭代增量的软件过程改进方法,可满足中小型企业希望以较低成本达到良好改进效果的需求。

关键词：软件过程改进,能力成熟度模型,持续,迭代

参考文献

[1]Mary B Chrissis,Mike Konrad,Sandy Shrum.CMMI(R):Guidelines for Process Integration and Product Improvement[M].NJ:Pearson Ed-ucation2,003.

[2]CMMI Product Team.CMMI for Development[M].Version 1.2(CM-MI-DEV,V1.2).CMU-SEI-2006-TR-008,2006.

[3]北京软件与信息服务业促进中心.北京软件产业发展蓝皮书[R].2006.

[4]Zhanchun Wu,David Christensen,Mingshu Li,et al.A Survey of CMM/CMMI Implementation in China[C].Beijing:International Soft-ware Process Workshop,2005:507-520.

[5]林锐,王慧文,董军.CMMI3级软件过程改进方法与规范[M].北京:电子工业出版社2,003.

[6]龚波,于自跃,何新贵.小型软件企业实施CMMI过程改进研究和分析[J].计算机应用研究,2004(8):64-67.

[7]朱卫平.基于CMMI的国内中小型软件企业软件过程改进研究[D].长沙:中南大学2,006.

[8]孙晓海.针对中小软件企业软件过程改进的研究与实现[D].上海:同济大学,2007.

[9]邢敏.中小软件企业基于CMMI的软件过程改进研究[D].西安:西北工业大学2,007.

[10]Robert McFeeley.IDEAL:A User's Guide for Software Process Im-provement[R].Software Engineering Institute,Carnegie Mellon Uni-versity,1996.

软件过程改进 第10篇

作为软件开发过程中的重要工作, 对其软件缺陷管理进行研究占据着关键的地位。该项课题的研究, 将会更好地提升软件开发过程中软件缺陷管理的实践水平, 从而有效优化软件开发的整体效果。

2 概述

软件缺陷分类主要是软件缺陷的度量以及分析的基础, IEEE/ANSI标准里把缺陷认定是产品中的一种非常规现象。主要是, 缺陷的检测以及清理可以对最终开发的软件产品的质量进行保障;再者, 缺陷里有着非常丰富的信息, 对缺陷去进行分析能够帮助软件组织得到开发过程的质量, 跟踪同时对项目的进程进行控制, 实现对实施过程中的改进。缺陷的度量可以说是软件产品度量以及过程度量利的主要环节;缺陷的分析不但能够评估软件产品质量, 同时还能够帮助掌握以及评价软件开发过程质量。

当前有一些比较成熟的对于缺陷的分类方法, 这些方法在侧重点上不一致, 其复杂程度以及适用的具体条件也不一致。本文主要提出了一种面向开发过程中的每个阶段去实施的缺陷分类的分类方法Phase DC。这一方法可以辅助软件项目的开发人员以及测试人员准确的对缺陷的属性值进行定位, 建设缺陷以及开发阶段的相关的联系, 并分析每个阶段产生的缺陷排除有效性;按照缺陷的去描述信息寻找改进软件过程的参照, 从而有效的去改进活动。和现有的缺陷分类方法不同, 该一方法主要是对缺陷关联的开发阶段进行注意, 对每个缺陷的引入阶段和发现阶段进行确认;运用阶段的信息去对缺陷进行分析, 寻找到开发过程里出现的问题以及应该进行改进的地方。

3 软件缺陷的来源

软件的缺陷是多种多样的, 从理论上看, 软件中的任何一个部分都可能产生缺陷, 而这些缺陷的来源不外乎是下列四个方面:

疏忽造成的错误、不理解造成的错误、二义性造成的错误、遗漏造成的错误。其中MD、AD、SD三类缺陷主要存在于软件开发的前期阶段, 如需求分析阶段、设计阶段、编码阶段。在实施第三方测试时, 一般不会存在这三类缺陷, 其原因是这三类缺陷的检测概率都比较大, 一般是容易测试的。在笔者所分析的多个例子中, 第三方测试所测试出来的95个缺陷, 只有1个缺陷是AD类缺陷。

因为疏忽产生的错误是一定的, 也是非常多样的, 这种错误是不可能够去预计的。就编码来讲, 可能会产生的疏忽为:

(1) 显式约束产生的错误。例如A是程序里面的一个元素, 因为在A之前或是之后应该去和另外的一个动作B进行合作, 也就是被叫做是显式约束;例如B不存在或者是B并不是A需要的, 那么就全部是错误的。如果存储器产生故障 (在某条路径上没有去释放内存) 或者是资源泄露出现错误 (在路径上未进行资源的释放) 。

(2) 潜在约束产生的错误。假如A是程序里面的一个元素 (一条语句或者是在语句中的一部分, 又或者是语句的集合) , 按照程序的语义, A就一定应该满足某些约束, 不然就是出现了错误, 如非法去计算类的错误和空指针运用错误以及数组越界的错误和指针使用错误等。从结果上分析, 软件缺陷主要是来自于软件过程的任何一个阶段。

4 软件产生缺陷的问题分析

4.1 技术上的问题

技术问题主要为:算法上出现的错误, 在特定条件下未能够进行得出正确结果。语法上的错误问题, 对于编译性语言程序, 编译器能够发现这写问题, 可是对解释性语言的程序, 只有在进行测试运行的时候发现;计算以及精度问题, 计算的结果不能够满足精度;接口参数不匹配, 造成模块集成上有问题出现。

4.2 团队工作出现的问题

团队工作出现的问题主要有:进行系统需求分析的时候没有理解客户的需求, 再由就是和客户在沟通上有困难;每一个阶段的开发人员彼此之间对客户的意图理解不一。比如, 软件设计人员对需求分析的理解上出现问题, 编程人员对系统设计规格说明书某些内容没有产生重视;对于设计编程上的假定产生依赖, 有关设计人员未进行及时沟通;项目组成员技术水平不一致, 新员工过多, 或培训力度不足等一些原因也会使问题出现。

4.3 软件自身出现的问题

软件自身出现的问题主要有:文档的错误以及内容不准确或者拼写上的错误;或者是并未考虑用户使用的场合, 还有就是会产生强度以及负载上的问题;对程序概念路径以及数据的范围边界思考的不全面, 互利某一些边界的条件, 产生容量以及边界上的失误;对一些实时应用, 需要去细致的设计并且处理, 以此保障时间的同步, 不然就会产生时间上的不协调以及不一致的问题;未去考虑系统崩溃之后的恢复以及数据的异地备份和灾难性的恢复等相关问题, 从而存在系统的安全性以及可靠性上的隐患;硬件以及系统软件上出现的错误还有在软件开发标准上出现的错误。

4.4 项目管理中的一些问题

项目管理上出现的问题主可以被分为:缺少质量的文化, 以及对质量计划的忽视, 还有对质量以及资源和任务与成本平衡性的把握, 经常会排挤掉需求分析和评审以及测试的时间, 留下的缺陷经常很多;再由就是开发的周期短, 需求分析以及设计还有编程与测试等工作没有去按照设定好的流程来去完成, 工作进行的不充分, 所以结果并不完整和准确, 出现的错误也很多;因为周期短, 同时也给相关的开发人员产生了极大的压力, 从而出现一些人为的错误。

5 结束语

通过对基于软件开发过程软件缺陷管理的研究分析, 我们可以发现, 在当前各种条件下, 要想获得最为理想的软件开发效果, 有关人员应该立足于软件开发的客观实际需求, 研究制定最为符合实际的软件缺陷管理实施策略。

摘要：近年来, 基于软件开发过程的软件缺陷管理研究得到了业内的高度关注, 研究其相关内容有着重要意义。本文首先对相关内容做了概述, 分析了软件缺陷的来源, 在探讨软件缺陷原因的基础上, 从多方面研究了其严重性与优先级的关联性。

关键词：软件开发,过程,缺陷管理,研究

参考文献

[1]鞠秀娟, 赵明.基于CMM的缺陷管理系统的设计及应用[J].四川大学学报:工程科学版, 2010 (23) :88-89.

[2]陈文海, 秦晓.软件测试管理工具的研究与实现[D].中国科学院研究生院, 2013.

软件过程改进 第11篇

关键词：CMMI；软件测试过程；度量分析

中图分类号：TP311.52

近几年来，随着我国信息技术的迅猛发展，软件行业得到大幅度提高，使得软件项目的功能等复杂度在逐步壮大，与此同时，软件的成本和质量也很难得到控制。那么，如何提高软件产品的质量成为当前软件行业普遍关注的问题。而软件度量分析是改进软件过程中的关键所在，最终为软件过程提供量化测试结果。因此，基于CMMI的软件测试过程度量分析的研究，对提高软件产品的质量具有重要的实际意义。

1 CMMI软件测试和度量之间的关系

1.1 CMMI和软件测试

CMMI的提出的目的是为了提高软件产品的质量，有利于改进软件过程，可以说，CMMI是一个广泛使用的过程改进模型。由于在软件过程中，软件测试是其中关键性内容，基于CMMI的软件测试能够为软件过程的改进提供重要的指导性方针。尤其在CMMI连续表示中，软件测试和验证域和过程域紧密相连，对改进软件测试过程提供了重要支持。其中，常见的过程域有风险分析过程、量化项目管理过程等。

1.2 CMMI和度量

CMMI为软件开发提供了重要度量和分析过程域，有效提高了管理信息所需要的度量能力。通常情况下，度量能够提取软件过程或产品的表征数据，而分析则主要对数据进行分析，一旦发现不一致及其他问题，为及时采取措施进行处理，促使软件企业免受损失。度量分析执行流程如图1所示。从中可以发现，CMMI的度量分析流程主要由计划、收集和分析这三部分构成。对于计划过程来说，它主要是确定并细化度量目标。对于收集过程来说，它主要是采集并存储数据，进而实现对数据的收集和检查过程。而分析过程主要是按照相应分析原则对数据进行分析和存储，甚至还能够报告结果的过程。所以，CMMI的度量分析过程比较严格，但具有明确的目标，流程十分清楚，实现对软件测试过程的指导和度量活动。

图1 度量和分析执行流程

2 软件测试过程模型

2.1 软件测试阶段划分

在软件投入运行之前需要对软件进行测试，软件测试目的就是确认软件需求和设计说明以及编码的是否合理。因此，软件测试直接影响着软件的生存周期。通常情况下，软件程序中的故障不一定由代码错误引起，还可以能是详细设计过程、需求分析阶段等出现问题造成，总之，软件问题可以存在于软件开发的整个环节。基于此，这就要求软件测试贯穿于软件定义和开发的整个阶段，其中包括单元测试、集成测试、确认测试等各个阶段。对于单元测试来说，它是软件开发过程中最低级别的测试活动，和传统的C语言相比，其单元测试的对象一般是函数。但在类似C++语言中，其单元测试的对象还可以能是类或类的成员函数。对于集成测试而言，当每个模块能够单独工作之后，将这些模块组装在一起，同时还要验证其是否正常，一旦出现问题，将会给影响功能的发挥。当每个模块进行单元测试完毕之后，则需要按照相应的设计结构程序图进行组装，为集成测试提供重要依据。当各个单元测试中的各个模块组合在一起之后，利用集成测试就可以对接口相关的不同故障进行检测。对于确认测试来说，当在完成集成测试之后，可以连接分散开发的模块，从而构成一个完整的程序，待各个模块之间的故障消除之后，就可以直接进行确认测试。在确认测试过程中，主要按照软件需求说明书作为主要依据，评估软件产品的质量等，从而满足软件需求过程，并及时对软件功能、接口等方面做出严格评价。

2.2 基于CMMI的软件测试过程模型

基于CMMI的软件测试过程需要遵循多个原则，第一，软件测试应贯穿于整个软件生命周期中；第二，软件测试需要具有严格的过程定义，同时还要严格按照相应的规范进行输入、输出和过程本身，且每一个测试阶段都有多种任务；第三，软件测试过程中拥有不同的测试对象，为不同开发阶段提供不同类型的测试；第四，软件测试应及时进行，一旦满足测试环境就可以实行软件测试过程；第五，软件测试除了和软件开发周期息息相关，还和风险管理以及成本管理等有着直接联系。第六，软件测试活动应将确认和验证作为重点。软件测试过程模型左边从需求分析开始直至软件运行和维护都需要测试，进而将测试需求递交至右边的软件测试基本流程中。在这个过程中，测试计划、测试设计等每个阶段都有一系列的任务，而这些任务均和整个测试流程有着密切联系，比如，在测试计划中，它主要以测试需求为依据，计划测试包括单元测试和集成测试等。

3 度量元的选取和细化

3.1 度量元的选取模型

基于CMMI软件测试过程为软件开发提供更多的实践指导，因此，根据CMMI的要求和原则，引入度量分析是十分必要的。而利用GOM方法能够有效确保度量元选取以及细化的有效性。由于GOM有效利用了目标驱动，使得软件开发具有较高的效率。也就是说在利用GOM方法时，要先对一组目标进行确定，然后针对各个目标提出极有可能出现的问题，这便是对目标的定义，待定义完目标之后，应针对每一个问题设计出相应的测量方法，这样就可以用这一组的测量方法所得出的度量元解决这一问题。在这个过程中，利用GOM方法最主要的是确保问题转化的完整性和匹配性。

3.2 度量元的选取原则

度量元的选取原则具有多种，其中有过程域裁剪原则、实践剪裁性原则、文档剪裁性原则等，对于过程域裁剪原则来说，每个STPA均有几个相关过程域，如果几个STPA同时拥有一个确定的过程域，那么就应该实行保留并合并下来，如果涉及软件测试关系性不强，那么则可以完全删除，如此一来就可以确保软件测试实践的有效性和完整性。对于实践剪裁来说，基于CMMI的整个软件过程改进中，需要对整个软件过程的实践性进行及时关注，尤其是置换软件测试过程。通常情况下，如何和软件测试无关的某些实践，都可以直接剪裁掉。如果针对某些零散的实践，如果表示的同一目标，那么可以直接进行合并。对于文档剪裁性原则来说。通常情况下，每个STPA均拥有大量且繁琐的文档，这给管理和维护带来一定困难。针对此，应保留和测试输入或输出相关的文档资料，为整个度量分析提供重要依据。

4 结束语

综上所述，基于CMMI的软件测试过程度量分析是软件行业中重点内容，尤其是近几年来，我国软件行业得到大幅度发展，使得软件成本和质量出现失控的状态，针对此，基于CMMI的软件测试过程度量分析有效改善了这一问题。因此，文中基于CMMI的軟件测试过程度量分析进行探讨，不仅为度量分析的应用起到了良好的指导作用，还具有一定辅助作用。相信，在未来，CMMI的软件测试过程度量分析将会更加完善，进一步推动软件行业的稳健发展。

参考文献：

[1]张少岗.基于CMMI的软件过程度量研究与应用[D].郑州大学，2010：5-10.

[2]方炯华.基于CMMI的软件度量模型研究与应用[D].厦门大学，2011：26-28.

[3]万邦睿，丁晓明.基于CMMI的软件测试过程度量研究[D].计算机工程与设计，2007（11）：2530-2546.

作者简介：包玮琛（1984-），男，蒙古族，辽宁大连人，讲师，硕士，研究方向：软件工程。

CMM在军用软件过程改进中的作用 第12篇

20世纪40年代, 美国研制了世界上第一台计算机, 并编制了用于计算导弹弹道的军用软件。经过60多年的发展, 军用软件已经渗透到军事领域的各个方面, 成为武器装备不可或缺的组成部分, 甚至软件本身就成为一类重要的装备。军用软件的水平成为军队信息化程度的重要标志, 甚至在某种程度上代表了一个国家的军事实力。因此, 世界各主要国家都把军用软件作为推进军队信息化建设的重要途径。

随着我军信息化程度的不断提高, 军用软件已经成为武器装备和指挥系统中不可或缺的组成部分。高新武器装备中由软件实现的功能甚至超过硬件, 利用软件技术进行武器装备的信息化改造已经成为武器装备信息化的主要模式, 计算机病毒和网络攻防软件正在成为信息战的重要工具。军用软件已成为高新武器装备的灵魂, 构筑信息化装备体系的关键。指挥信息系统通过软件将指挥控制、情报侦察、预警探测、通信和信息对抗各部分连成一个有机整体, 为现代军事指挥提供全方位的信息保障, 成为武器装备效能的倍增器。

软件是用计算机语言表示的与计算机操作有关的程序、进程和数据的集合。软件产品难以描述和理解, 由此带来了固有的高复杂性、抽象性和易变性, 并导致了研制上的高风险和管理上的高难度, 出现了以软件质量无法满足需求、开发预算严重超支、软件交付时间难以保证为主要特征的“软件危机”。

军用软件又有一些特殊性, 表现在: (1) 规模巨大 (一架战斗机的软件源代码超过2000万行, 一艘舰艇的软件源代码超过5000万行) ; (2) 嵌入式军用软件的开发常常受到严格的硬件和软件条件的约束; (3) 由于用于军事目的, 对军用软件有高可靠、高安全、高生存、高保密、高实时、高互操作等方面的要求; (4) 这些特殊性使军用软件的质量保证面临更大挑战。

2 软件开发中的问题

随着各级领导对软件开发规律和军用软件质量重要性认识的提高, 我军军用软件开发能力正在进步, 但也存在一些问题。目前, 一些软件承制单位已经建立或正在建立基本的软件过程, 能够按照软件开发规律进行软件开发, 软件质量因此处于可控状态。但多数单位尚未建立基本的软件过程, 对影响软件质量的原因认识不足, 往往采用“自编、自导、自演”的手工作坊式的软件开发方式, 从而造成软件质量失控。

这些问题集中表现为: (1) 将软件当作硬件的附件而不是独立的产品, 没有按照基本的软件过程模型进行软件开发, 无法保证软件的开发周期和质量; (2) 软件开发文档及编制过程不规范, 失去了文档对开发过程的指导作用, 更失去了软件验收和维护的依据; (3) 软件测试没有作为一个独立的过程进行实施, 测试过程难以发现软件中存在的问题。

这些问题导致的必然结果是:软件开发进度失控, 成本失控, 质量失控, 软件生产率越来越低, 可维护性越来越低, 可靠性越来越低。进而, 直接影响我军战斗力的提升和信息化的进程。

3 CMM原理

软件是关于计算机操作的计算机语言的逻辑表示。因此, 软件产品本身具有零磨损特性, 其质量取决于开发过程。国内外的经验表明, 清晰和完善的软件过程是软件产品质量的根本保证。

1995年发布的ISO/IEC 12207《信息技术软件生存周期过程》国际标准将软件过程定义为一个周期性的过程, 对软件全生命周期进行了明确的划分。规定软件开发过程要按阶段制定计划并实施, 每个阶段都要进行评审和确认。在此基础上, 对开发过程进行不断的改进。

CMM (Capability Maturity Model:能力成熟度模型) 源于美国卡内基梅隆大学软件工程学院W.S.Humphney 1987年的论文“承包商软件过程能力的评估方法”, 这也是2003年发布的国际标准ISO/IEC TR 15504《信息技术软件过程评估》的基础。

CMM将软件过程能力成熟度分为5个等级, 描述了每个等级的软件过程的特点: (1) 第1级是初始级。处在初始级的软件开发组织尚未建立基本的软件过程, 开发过程处于无序甚至混乱状态。不考虑软件生命周期过程, 软件质量完全依赖于开发者的个人素质。开发进度、预算、产品功能特性和质量难以预测。其软件过程能力被认为是不可预测的; (2) 第2级是可重复级。处于可重复级的软件开发组织, 其软件过程能力被认为是有纪律的。表现为:软件开发过程处于有效的制度管理下, 已有的成功实践可重复应用于新项目的开发; (3) 第3级是已定义级。软件开发组织已经定义了组织级的标准软件过程, 这些标准软件过程可用于为新项目开发定义一致的软件过程。在整个软件组织中, 软件过程稳定且可重复, 成本、进度和功能特性都处于可控状态, 软件质量可跟踪。称其软件过程能力是标准和一致的。 (4) 第4级是定量管理级。在此级别上, 软件开发组织的软件过程能力是可预测的。其特征是:制定了软件产品和过程的定量质量目标, 软件开发风险可以进行定量估算, 开发过程中的不确定性可以限定在可接受的范围内, 软件产品因此具有可预测的高质量; (5) 第5级是优化级。软件开发组织能够利用实施过程中的定量反馈信息, 分析软件过程中存在的缺陷以及这些缺陷产生的原因, 不断改进软件开发过程, 防止已知缺陷重现。因此, 其软件过程能力被称为是不断改进的。

由此, CMM模型为软件开发组织描绘了一个循序渐进的改进过程。

4 CMM的作用

作为一个软件过程能力成熟度评价模型, CMM的作用主要体现在以下两个方面: (1) 为软件委托方或采办者提供一个评价标准, 对软件承包商进行软件过程能力评估, 对风险进行控制; (2) 为软件开发组织提供一面镜子和一架梯子, 帮助软件开发组织进行对照检查, 找出自身的强项和弱点, 制定改进计划, 逐步提升软件过程能力。

5 CMM的应用

美军将CMM作为其选择军用软件承包商的工具, 在招标过程中对投标者的软件过程能力进行评价, 以降低军用软件采办风险, 包括资金、进度、功能、性能和质量等方面的风险。

美国宇航局的报告指出, 随着软件能力成熟度从1级提高到5级, 软件开发周期缩短38%, 成本降低55%, 缺陷密度从每千行11.95个缺陷降低为0.32个, 软件可靠性明显提高。

运用CMM的实践表明, 软件能力成熟度越高, 软件过程越透明, 软件性能越稳定, 软件质量越高。

6 结束语

目前, 我国军用软件过程能力水平大多处于CMM初始级, 提升空间很大, 也很急迫。为此, 2003年发布了GJB5000-2003《军用软件能力成熟度模型》军用标准, 要求全军各部队和全国所有军用软件承制单位贯彻执行, 在规定时限内达到与所研发的软件相应的成熟度等级。

然而, 软件过程能力的提高不是一蹴而就的。建议:深刻理解CMM模型, 掌握其内容实质。结合实际情况, 制定相应的改进措施。循序渐进, 不因差距大而失去信心。

参考文献

[1]GJB5000-2003《军用软件能力成熟度模型》实施指南[M].北京:国防工业出版社, 2004.