软件过程改进研究

2024-05-07

软件过程改进研究（精选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篇

随着全球化的发展，传统的软件工程技术已经不再适用，为了更好地满足用户的需求，软件工程技术需要朝着全球化发展。全球化的发展，使得国内人不仅有更加优质的软件选择，还可以与国外的人分享该成果，以促进软件的更迭。

3.2 迭代化

迭代化软件开发将整个软件分成多个阶段性，并且进行阶段性评估，完成和达到目标。迭代化通过改进和精炼开发流程，保证项目开发进度，从而持续满足用户的需求变更，降低风险，以实现软件的高质量开发。

3.3 多态性

多态性是指不同的对象接受到相同的消息时，得到不同的结果。随着科技的发展，软件工程技术为满足更多用户需求，需要在动态变化的网络环境中，开发出一套软件相容于多个目标形态，为此多态性的特点将更加凸显。多态性使软件工程技术能更好的适应互联网的日益革新，具有满足个性需求的能力。

3.4 开放性

开放性是软件工程领域的新趋势。随着信息的不断普及，部分软件在国内已无法良好的进行下去，需要得到国外的帮助，共同完成。软件的开放性加上全球化的共同协作技术，才能使软件在未来发展的更好更快。

4 结语

随着互联网的快速发展和普及，计算机硬件的不断完善，以及软件的不断变革与更新，软件工程技术也将朝着开放性、动态性、多态性方向不断发展。但目前我国的部分核心技术来自于发达国家，在一定程度上，影响着我国计算机软件发展，为更好地实现科技强国的伟大目标，我们将致力于软件工程技术的研究，一路向前，继续深入。

参考文献：

[1]张海藩.软件工程导论[M].北京：清华大学出版社，.6.

[2]刘赛.浅谈软件工程技术的发展历程[J].湖北：信息通信，.3.

[3]刘小海.软件工程技术发展研究[J].北京：软件，2013.7.

[4]张虹.软件工程与软件开发工具[M].北京：清华大学出版社，.7.

[5]周苏.现代软件工程[M].北京：机械工业出版社，2016.2.

[6]杨芙清.软件工程技术发展思索[J].北京：软件学报，2005.1.

软件过程改进研究第3篇

关键词：成人高校；基于工作过程；排版软件

中图分类号：G642

基于工作过程的教学模式，源于德国的“双元制”职业教育经验，近年来在我国职业教育中得到重视。该教学模式是以培养学生职业技能为核心，以工作实践为主线，以工作过程为导向，以典型工作任务为载体的教学模式，体现了“学习内容是工作，通过工作实现学习”的职业教育理念。笔者认为，成人高校专业课程的教学也应采用基于工作过程的教学模式，以工作任务为中心，整合课程知识和技能，缩短学生就业距离。

我校是一所成人高校，《排版软件应用》是我校电脑艺术设计专业开设的一门专业技能课程，学习的软件是InDesign。几年来，笔者在该课程的教学中采用了基于工作过程的教学模式，教学效果良好，下面结合教学实践，对如何运用基于工作过程的教学模式进行课程设计做有益的探讨。

1 确定基于工作过程的教学任务

InDesign软件功能强大，命令繁多。《排版软件应用》课程又具有很强的理论性、操作性和应用性。传统的教学模式过于追求知识体系的完整性，偏重软件和理论知识的讲解，不利于学生设计排版岗位能力的培养。笔者在确定《排版软件应用》课程的教学任务时，运用了基于工作过程的教学理念，以理论够用，测重实践，突出应用为原则，强调构建工作过程的完整性，突出创新能力的培养。

出版物设计的基本工作流程是接单——客户沟通——资料收集——整理素材——设计制作——输出。根据工作流程，笔者确定课程的教学任务为：了解出版物设计的基础理论知识、基本工作流程、输出过程，培养学生运用InDesign软件的文本、表格、图形、图像、页面等元素设计和制作出版物的能力，为后续专业课程的学习和从事出版社、报社等单位的设计、排版工作奠定基础。

2 设计基于工作过程的教学内容

传统的教学模式强调学科知识体系的完整性，以学科知识逻辑为主线。而基于工作过程的教学模式是针对实际工作岗位的需要，以职业活动为主线，以培养职业能力为目标，重新组织和设计教学内容，合理安排理论和实践知识的比例，注重实践操作，强调专业技术应用能力的培养，理论知识以必需、够用为度。

在《排版软件应用》课程中，根据出版物设计排版岗位的工作过程，笔者将实际工作任务拿来做教学内容，将教学内容组织为4个工作任务，即4个教学任务，1个为实训项目，3个为小型案例。具体见下表：

理论知识以工作任务为载体，核心能力与工作任务实现过程密切相关。课程实践内容是实际项目和案例，排版理论知识的学习、软件操作技能的掌握围绕4个工作任务组织和展开，学生在学习中真正体验了工作过程，在实际工作任务的完成过程中掌握了理论知识和软件操作，变知识传授为能力培养，让每个学生都能体验到成功的快乐，充分发掘了学生的创造力，培养他们的实践能力、分析和综合能力，从而提高了学生的就业能力。

3 采用基于工作过程的教学方法

在《排版软件应用》课程的教学中，本着以工作需求为导向、突出应用、重视实践性教学环节的原则，笔者采用了项目实训、案例、任务驱动教学法。

3.1 项目实训教学法。设置一个课程实训项目，将整门课程零散的知识点进行整合，实训项目贯穿整门课的教学。在启始课上，引入实训项目，激发学生兴趣，使学生明确学习目标。实训项目要展现出版物设计制作的整个工作流程，使学生在完成一个具体实训项目的过程中，切身体验到排版工作的实际操作流程，有利于培养学生解决实际问题的能力。为了便于教学，将实训项目分解为若干子任务，分别融入到每次课中。

3.2 案例教学法。在文字、表格、图形、图像的教学中，使用3个教学案例，展现出版物设计制作的部分工作流程。文字、表格分别采用一个小型案例，考虑到成人学生基础等因素，不要涉及图形、图像应用等知识。图形、图像应用采用一个综合案例，学生通过案例任务的完成不仅掌握了图形、图像的应用，而且掌握了文本绕排和主页排版等功能，还复习了文字处理的相关知识。教学中，应以教师为主导，学生为主体，讲、练、学相结合。

3.3 任务驱动教学法。将案例、项目、子项目设置为教学任务，根据任务创设教学情境，引出任务，分析任务，在教师的引导下，学生自主学习或协作学习，完成任务，同时学生通过复习旧知识和应用新知识，完成自身知识体系的建构。

项目实训、案例、任务驱动三种教学方法各有利弊，实际教学中，应进行整合，取长补短，灵活运用。利用项目、案例、任务模拟工作过程，创设教学实践情境，将理论知识的学习、软件的使用融入到真实或接近真实的工作过程中，学生通过工作任务的完成达到知识体系的构建，激发了学习兴趣，切实提高了学生解决实际工作问题的能力。

4 引入基于工作过程的考核方式

传统的考试方式在评价学生学习成绩上存在弊端，不能科学、全面地评价学生的学习效果和能力水平。基于工作过程的考核方式应从注重知识考试转变为注重职业能力的考核，应从期末考试方式转变为基于学习过程的分阶段的形成性考核方式。在《排版软件应用》课程的教学中，笔者用四个工作任务的完成情况来综合评价学生的成绩，每完成一个任务，就给出一个成绩。根据任务的难易程度来设置分数权重，如：黑白书籍内页设计占20%、客户产品销售情况统计表占15%、保护动物宣传页占25%、企业杂志设计与制作占40%。

实训项目的评价，可先由学生展示作品，自评，再学生间互评，最后由教师总结评价。实践证明，此评价过程可以锻炼学生的表达能力，增强学生的成就感，学生间也可以相互借鉴学习。

基于工作过程的考核方式是一种过程性的评价方式，评价贯穿整个学习过程，结合教学任务分阶段考核，可以科学、全面地评价学生的学习效果和能力水平，大大激发了学生的学习主动性，达到了以考促学的目的。

5 应注意的问题

5.1 精心设计和使用案例、实训项目。随着教学的深入，应先易后难，由简单到复杂，从单一到综合，再到实训，循序渐进，这样符合学生的认知规律，利于学生建构知识。

5.2 案例、任务难度要适中，适合课堂教学。案例、任务过于简单，会降低学生积极性；过于复杂，不利于课堂实现，学生会产生受挫感，失去信心。选择难度适中的案例、任务，学生通过学习，完成了作品，具有成功感，增强了自信心。

5.3 案例、项目的选择要考虑到成人教育学生的特点。成人学生普遍工学矛盾严重，知识基础薄弱。案例、项目的选择，总体上不要过于复杂，涉及的知识点不要太多。

参考文献：

[1]丁琦，汪德宏.基于工作过程的高职课程教学模式探讨[J].职教论坛，2010，2.

[2]李淮.基于工作过程的项目式教学模式[J].中国建设教育，2012，1.

[3]冯伟.基于工作过程的高职教学模式探索[J].科技创新导报，2010，3.

软件过程改进研究第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篇

2010-05-19 来源：网络

随着软件系统的规模、复杂度日益上升，软件开发过程管理已经成为保证软件系统开发效率、质量、成本的关键性因素。作为软件开发过程中质量保障的重要组成部分，行之有效的软件配置管理（以下简称SCM，Software Configuration Management）能够显著提高软件开发组织的自身能力、提高软件开发过程的完整性，以及降低软件开发的风险。

软件配置管理的概念

ISO 9000、CMM、ISO/IEC 12207、IEEE 729-1983对SCM的定义有不同的描述。ISO9000定义SCM为“一个管理学科，它对配置项的开发和支持生命周期给予技术上和管理上的指导。配置管理取决于项目的规模、复杂程度和风险大小”。

CMM2将SCM定义为一个关键过程域KPA，是“贯穿于整个软件过程中的保护性活动，它被设计来（1）标识变化，（2）控制变化，（3）保证变化被适当的发现（4）向其他可能有兴趣的人员报告变化。”。SCM包括了配置项识别、工作空间管理、版本控制、变更控制、状态报告、配置审计等活动，其中以版本控制最为核心和关键。

数据集中工程软件配置管理策略

1、数据集中工程项目背景

中国建设银行数据集中工程的目标是通过建立总行级的数据中心，向全行38个一级分行、20000多个网点提供完整的核心金融服务。其核心应用系统DCC-CCBS包括主机、前置、前端三大部分。主机应用部分部署在总行级数据中心，前置应用部分部署在数据中心前置通信网关、各一级分行业务大前置，前端部分部署在网点。

DCC-CCBS项目的SCM需要实现开发、发布、部署的全过程软件配置管理。开发过程SCM的核心是系统源码版本管理；发布过程的SCM核心是系统目标码版本管理；部署过程以确保系统目标码版本在数据中心、一级分行、网点和外系统的正确部署为首要目标。

2、开发过程软件配置管理

系统源码版本除系统源程序、参数外，还包括需求规格说明书、系统总体架构设计说明书、主机/前置/前端系统结构设计说明书、各子系统的详细设计说明书、各子系统的对外接口规范、业务操作手册、系统使用手册、系统安装维护手册等文档。根据配置项的不同属性，经过评审，形成需求基线、设计基线和源代码基线等不同的基线。开发过程SCM按照子系统的性质，分为主机、前置、前端三部分独立管理。

DCC-CCBS项目总体组负责整个需求和变更的控制。通过审批的需求按照功能分布分解为主机、前置、前端的子需求，再由各部门分别管理和实现。环境及版本控制小组负责向各部门提出形成“系统基线”的要求，以同步主机、前置、前端的源码版本。

3、发布过程软件配置管理

发布过程的系统目标码版本包括系统目标码（执行码）、系统参数及相关文档等。按照用途，系统目标码版本可分为测试版和正式版。以前置平台为例，发布过程SCM的主要活动包括：构建环境管理，保证编译环境的纯净性和正确性；

构建过程管理，保证构建过程的自动化操作，及其正确性和完整性；

版本编号管理，统一版本命名规则，确保目标码版本号的唯一性和可追踪性；

目标码版本生成管理，从各版本管理工具系统收集、整理、打包相应的目标码、参数和文档，形成完整的或部分（补丁）的目标码版本；

配置状态检查，检查目标码版本包中内容的正确性、完整性和一致性；

4、部署过程软件配置管理

部署过程SCM的主要任务是：建立安全、可靠和迅速的传输流程和传输渠道；建立目标码版本记录和追踪机制、版本运行时刻检查机制和版本恢复机制；确保正确的版本、按照正确的渠道、在规定时间递交到正确的用户并生效。

在DCC-CCBS生产环境中，软件开发中心将通过数据中心版本管理系统发布各单位所需的目标码版本，各单位在版本管理系统和数据传输通道的支持下，实现版本/补丁的主动分发、查询、下载和生效。

软件配置管理实施经验

1、树立正确的企业配置管理意识

SCM是一门管理学科。归根结底，其关键是“管理”，然后才是“软件配置”。项目级SCM能否成功实施，与企业的软件配置管理目标、策略、能力、组织和资源息息相关。

2、提高全员的配置管理素质

SCM是规则和流程的集合，需要依靠流程中所有部门和人员共同的支持和努力。任何环节上的疏忽和懈怠，都将直影响SCM的实施效果。

3、采用合适的工具

功能强大的或昂贵的工具未必是合适的工具。往往20%的功能即可解决80％的配置管理问题。目前比较流行的版本管理工具包括CVS、PVCS、ClearCase、Harvest、VSS、Endeavor等。在选择具体工具时，往往需要考虑以下因素：（1）工具将要使用的范围；（2）工具自身的功能、稳定性、扩展行，以及对环境的要求；（3）工具使用的复杂度；（4）工具与其他流程和工具的集成度和交互性；（5）工具的投资和维护费用。

4、及时的检查和梳理

大系统开发过程中，配置管理往往采用分步离散管理方式，因此保证整个系统配置管理的完整性成为一件精密细致的工作，需要投入大量人力及时修订基线，防微杜渐，避免混乱，以满足对配置管理正确性、完整性和及时性的要求。

5、系统化思考、分步实施、持续改进

SCM不是一项孤立的管理活动。企业的战略目标、管理能力、文化背景、组织结构，项目的规模、性质、技术、人员等都是影响SCM决策的重要因素。因此需要在项目乃至企业的整体环境中系统的考虑SCM的实施策略和方法。

软件过程改进研究第6篇

关键词教学效果评价高职软件技术

重庆市职业教育学会课题《基于工作过程的高职软件技术专业课程改革与实践教学研究》[课题编号：2015-ZJXH-13224]阶段成果之一）

【分类号】TP391.44-4；TN929.5-4；G712.3

从课程教学效果评价方面来看，基于工作过程的高职软件技术专业课程与基于学科体系课程在评价主体、评价内容、评价方法等方面都有较大的差异。

为检验学生实际变化，课程目标达成程度、课程的应用效果是否是与课程设置的目标相一致，2012年软件技术专业课程借鉴国内外课程改革经验，实施基于工作过程的软件技术专业课程教学效果评价。

本为本文将从理论研究与实际应用角度，就如何有效地实施基于工作过程的高职软件技术专业课程教学效果评价进行研究。

一、基于工作过程的课程开发内涵

工作过程，是个体为完成一件工作任务而获得工作成果进行的完整的工作进程。基于工作过程的高职软件技术专业课程的开发，大致包括3个步骤，即软件行业岗位群/岗位典型工作任务分析、课程学习领域设计、课程学习情境（场景）设计。

二、基于工作过程的课程教学效果评价的基本特征

1.评价过程常态化

基于工作过程的课程教学效果评价关注结果，更加关注过程，其将终结性评价与形成性评价相结合起来，且评价工作常态化，以促成课程的转变与发展。基于工作过程的课程开发即是学习情境设计，然后每一个学习情境又设计为一个一个项目及典型工作任务来实施教学，每一个项目通常按照六个步骤来组织教学，即资讯、计划、决策、实施、检查、评估。每一个学习情境都包含评价环节，实现了评价工作的常态化，通过不断循环的教学评价，发现问题，分析原因，能及时解决遇到的问题。

2. 评价主体多元化

基于工作过程的课程教学效果评价，改变了教师作为唯一评价主体的情况。事实上，在基于工作过程的课程中，聘请的企业兼职教师参与实训/综合实训、实习等学习任务，因此增加了来自企业和社会的评价主体，加上学生对课程教学效果的评价、督导专家的评价、教师的自我评价及反思使得评价主体多元化，能及时发现教学中出现的问题，并改进课程开发及教学，最终使职业教育教学更满足企业和社会的要求。

3.评价的多维度

课程实施是多维度的，仅仅用单一的指标去评价是不全面的，需要多个指标从不同维度进行评价，一方面针对高职软件技术专业，构建一个包含课程目标、课程内容、学生评价、教师评价、企业专家评价的综合评价指标体系，借助多种评价工具从不同角度来搜集课程评价资料；另一方面，建立适应不同评价主体、针对不同课程及任课教师的分类指标体系也十分重要。

三、课程教学效果评价方法

课程教学效果评价是评价主体在课程教学过程中依据课程教学目标及要求，运用一定的评价指标和评价方法，对课程进行价值判断的活动过程。高职课程教学效果评价必须考虑职业教育与职业活动之间的关系，基于工作过程的高职软件技术专业课程教学效果评价包括三个层次，各層次的评价内容及指标不同，且评价内容及指标采用不同的评价方法。

1.反应评价

在课程结束后学生对课程的喜欢程度和满意程度进行调查，反应评价非常具有参考价值，主要是采用教师听课、学生座谈、调查问卷、学生评教等方法。通过反应评价，可了解学生对课程爱不爱好、满不满意，从而为课程设计及实施的改进提供直接依据。

2.综合素质评价

在课程进行中和结束时认定学生是否在知识、能力、职业素质等方面得到了提高，主要是通过对学生学习之前和学习之后的知识、能力、职业素质等方面的对比来实现的。评价学生对相关知识的理解及掌握程度，主要采用练习或作业、期末考试等方法；评价学生专业能力达到的水平，主要通过成果评价表或综合评价表等量化表来实现；评价学生职业素质等方面的状况，主要采用自评和团队互评等方法。

3.工作能力评价

为达到高等职业教育和课程教学的目的，学生须将课程中学习的知识、训练出来的能力、培养的职业素质等方面的学习成果应用于实际工作，工作能力评价是是在学生进入顶岗实习岗位及就业后实施，目的是对学生具备的工作能力的评价。主要采用毕业生座谈、跟踪调查、问卷调查、项目组长（同事）评价等方法。工作能力评价阶段是教学评价中一个非常重要的层次，可分析出课程内容不适应实际工作要求的原因，在基于工作过程的高职软件技术专业课程教学效果评价中，我们也在探索国内外通过第三方机构对课程教学效果进行评价的方式。

参考文献

[1] 陈移山.基于工学结合课程教学效果的评价[J ]. 职业教育研究2011（7）.

[2] 姜大源.工作过程导向的高职课程开发探索与实践[M ]. 北京：高等教育出版社， 2008 ： 136-145.

软件过程改进工程研究综述第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篇

软件性能测试作为软件质量保证必不可少的环节,指的是软件系统或构件对于其及时性要求符合程度的指标;它是一种规范,可以用来量化更改业务指标所产生的影响,进而说明部署软件的风险。一般用响应时间、吞吐量每秒点击数等参数指标进行衡量。软件测试广义上分为压力测试、负载测试、强度测试、并发(用户)测试、容量测试、配置测试和可靠性测试等。

性能测试工具一般通过Winsock和HTTP等协议记录用户操作。软件系统的架构不同,协议的选择也不同。不同的软件测试工具的脚本语言不同,每种测试工具都有自身的特点,在实际应用中应选择适合软件架构性能测试工具。常用的测试工具有很多,有用于服务器存储子系统读写性能测试的Iometer、用于Linux服务器下I/O性能测试的Iozone、用于服务器的网络性能测试的NetPerf以及用于应用系统的负载性能测试工具QALoad,LoadRunner和Webload等。这些工具的功能强大,能自动生成测试报告。

1 性能测试的一般步骤

LoadRunner是惠普公司的软件性能测试产品,主要由虚拟用户发生器(VuGen)、压力调度和监控中心(Controller)、压力生成器(Load Generator)和结果分析工具(Analysis)组成。本文以LoadRunner为例,说明性能测试的一般步骤:

(1)确定用户要测试的业务。也就是通过需求分析,确定测试的目的和测试的性能指标(响应时间,并发用户数,吞吐量和资源利用率等)。

(2)通过用户对软件的操作和Vugen的录制功能记录并生成虚拟用户脚本。

(3)修改脚本,确定脚本能够回放成功。

(4)在Controller中根据需求配置测试场景。包括虚拟用户数、运行参数、用户增长方式、测试循环方式、用户退出方式和需要监视的性能指标等。

(5)执行测试场景。Controller控制Load Generator对被测系统的加压方式和行为,同时搜集被测系统各个环节的性能数据。Load Generator记录最终用户响应时间和脚本执行日志,并将数据传送到Controller中,由其进行结果的汇总。

(6)借助Analysis分析测试数据,设计调优方案。

(7)进行调优测试,重复测试过程,直至符合系统性能测试的要求。

2 测试方案设计及实施

2.1 测试需求分析和脚本录制

通过分析用户对软件的性能要求和阅读软件的需求分析文档,了解软件的类型、应用领域、所需环境和系统功能,确定测试的目的和性能指标。测试目的包括性能符合性验证、性能能力验证和性能调优。性能指标主要包括响应时间、并发用户数、吞吐量和资源利用率等。对测试的需求分析以确保使用测试工具创建的测试环境能够在测试中精确地反映应用程序的环境和配置,以及系统性能瓶颈所在。

分析软件中的典型用户,通过VuGen记录业务的操作流程创建脚本,不需要依赖客户端软件。脚本录制好后,通过对录制后的脚本添加事务、集合点和参数等,强化脚本,确保回放成功。

2.2 设计测试方案

脚本录制好后,设计测试方案。测试方案的设计关乎测试结果的准确程度。方案包括如何模拟实际用户的信息:虚拟用户组、Vuser运行的脚本和负载生成器。分析用户使用模型,定义系统的典型使用方式,考虑哪些用户使用该软件,每种用户的数量和典型任务,还应考虑任何可能影响系统响应时间的负载。本文采用LoadRunner的Controller,建立持续的负载,管理负载方案,利用日程计划定义用户什么时候访问系统,实现测试过程的自动化。

本文测试某大学学报系统的登录功能的性能,模拟50个虚拟用户,同时登录本系统,如表1所示;并保持100个用户同时在线,如表2所示。

2.3 方案的实施

方案设计好后开始实施。本文的测试中,并发测试中实际在线的人数达到100人以上,且在线时间超过30分钟,测试结果软件达到要求。LoadRunner的压力调度和监控系统同时搜集被测软件的各个环节的性能数据,记录最终用户响应时间和脚本执行的日志。运行结束后,将数据传回监控系统,汇总测试数据。

LoadRunner的数据分析器Analysis读取测试数据,进行分析,确定瓶颈和软件系统的调优方案,对系统重复进行测试,确定软件系统的性能是否提高。本文同时对软件性能测试中的测试要点进行了分析,总结各测试指标对测试的影响以及它们之间的关系,给出测试报告。

3 结束语

软件系统性能测试是一项复杂的工作,有一定的偶然性。本文主要阐述了软件性能测试的主要过程和关键技术,并结合LoadRunner测试工具和实际软件进行测试实验,对提高软件产品的质量和可靠性提供了保障。本论文的不足之处在于没有对软件性能测试的各个指标以及它们之间的关系做出更详尽的分析,这是以后需要继续研究的内容。

参考文献

[1]陈江.软件性能测试研究与分析[J].福建质量管理,2009(03).

[2]韩明军.软件性能测试过程[J].信息技术与标准化,2007(11).

[3]朱怡雯,钱超,林勇.软件性能测试工具综述[J].中国金融电脑,2009(07).

[4]曹晋源.LoadRunner在软件性能测试中的应用[J].电脑开发与应用,2008(05).

[5]欧阳荣彬,郭陟,顾明.基于排队模型的软件性能测试框架研究[J].计算机工程,2006(03).

软件开发过程的持续集成探讨第11篇

【关键词】软件开发；持续集成；Jenkins

0.前言

持续集成是一种软件开发实践，对于提高软件开发效率并保障软件开发质量提供了理论基础。本文通过具体实例，介绍了如何借助持续集成工具提高软件生产力。

1.当前公司的版本发布工作

当前各个公司的版本发布工作差异很大，有些公司没有每日编译版本，等到正式发布时发布一下；有些公司则是写一个脚本每天晚上定时编译一下，第二天开发人员就可以使用前一晚上生成的版本；有些公司使用持续集成工具编译版本，代码有更改时就会触发编译；还有些公司根据每日编译的状态触发电子装备，亮红灯或绿灯来显示版本的状态，有些甚至利用发声装备发出导致版本编译失败的代码上传者的名字。

可见各个公司在持续集成方面的投入差异巨大，持续集成投入越多，软件版本交付能力就会越强，软件生产力也就越高。

2.持续集成的核心价值

（1）持续集成中的任何一个环节都是自动完成的无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量。

（2）持续集成保障了每个时间点上团队成员提交的代码是能成功集成的。换言之，任何时间点都能第一时间发现软件的集成问题，使任意时间发布可部署的软件成为了可能。

（3）持续集成还能利于软件本身的发展趋势，这点在需求不明确或是频繁性变更的情景中尤其重要，持续集成的质量能帮助团队进行有效决策，同时建立团队对开发产品的信心。

3.持续集成的原则包括

（1）需要版本控制软件保障团队成员提交的代码不会导致集成失败。常用的版本控制软件有IBM Rational ClearCase、CVS、SVN等。

（2）开发人员必须及时向版本控制库中提交代码，也必须经常性地从版本控制库中更新代码到本地。

（3）需要有专门的集成服务器来执行集成构建。根据项目的具体实际，集成构建可以被软件的修改来直接触发，也可以定时启动，如每1小时构建一次，还可以由上游项目编译成功后触发。

（4）必须保证构建的成功。如果构建失败，修复构建过程中的错误是优先级最高的工作。一旦修复，需要手动启动一次构建。

4.持续集成工具介绍

4.1持续集成工具主要分两大类，开源的和商用的

（1）开源工具。

CruiseControl、Hudson、LuntBuild

（2）商用工具。

TeamCity、AntHill Pro、Bamboo、QuickBuild

CruiseControl和LuntBuild在持续集成领域进入较早，Hudson作为OpenSource里持续集成的后起之秀，现在已经赶超了这两个前辈，目前恐怕是使用最多的一个CI Server了。国外使用商用的工具多些，而在国内用开源的多些，其中Hudson工具使用较为广泛，现在叫Jenkins，是基于Java开发的一种持续集成工具，它主要包括：

（1）持续的软件版本发布/测试项目。

（2）监控外部调用执行的工作。

4.2 Jenkins具有以下突出的特点

（1）开源免费，容易安装，只需要执行Java-jar jenkins.war即可。

（2）容易配置，可以通过友好的webGUI来配置，几乎每个配置都有帮助信息提示。

（3）跨平台，几乎支持所有的平台，例如Windows，Ubuntu/Debian，RedHat/Fedora/CentOS，MacOSX，openSUSE，FreeBSD，OpenBSD，Solaris/OpenIndiana.Gentoo。

（4）master/slave支持分布式的build，jenkins能够分发build/test的负载到多台机器，能够更好地利用硬件资源，提高build的时间。

（5）插件支持，已有200多个插件，可通过第三方的插件来扩展。

（6）Junit/TestNG测试报告，能够很好地显示各种测试的报告，且可以生成失败的趋向图。

5.应用举例

（1）某产品开发部有驱动、软件等小组，各小组的代码是各自管理的，但接口文件是共同的。假如软件小组的某个头文件修改的时候驱动小组也需要同步修改，该文件受软件小组管理，驱动小组需要同步，如果靠人工每天去看对方的头文件是否更改，比较费时，也容易漏掉。如果你使用Jenkins工具新建一线程，专门检测对方的接口文件，当然对方该部分代码需要给对方小组某成员开读权限，当检测到对方头文件有修改时则将该文件check到本地，然后再check自己的代码，将对方的接口文件上传到自己的库里。完成后再触发邮件系统将邮件发送到相关开发人员。这样开发人员能够把更多的精力花在关键事务上。

（2）上传代码到自动化测试一气呵成。某部门开发一套指纹识别项目，开发人员优化该项目时，由于优化过程是持续累积的过程，每天可能都能提高一点，当开发人员将阶段性的成果上传到代码库中，系统按设置的一定时间间隔完成编译并将编译库放到服务器，自动化测试程序也会每隔一定时间去取这个库，并运行程序，并将运行结果直接发送到开发人员工作信箱里。开发人员也能很快速方便地看到自己优化的结果。

6.结语

工欲善其事，必先利其器。软件开发也要借助于提高软件生产力的工具，持续集成工具能够把开发人员从繁琐的代码同步、版本发布、查找编译失败等工作中解脱出来，让开发人员把精力聚焦在核心业务上。

【参考文献】

软件成本估算方法的研究与改进第12篇

1.1 软件成本估算背景

无法准确估算出软件开发的成本和进度是软件危机的重要表现形式之一,于是各种估算软件成本的模型和方法作为软件度量的一个方向应运而生。何为软件成本估算呢?软件成本估算的含义就是指在软件开发以前对于其所需的工作量和时间等做出经验性的估计。一般而言,对于软件成本估算有两个要求:首先,要有一定的准确度。其次,模型或者方法对于使用者应该方便快捷。

软件成本估算一般需要估算三类数据:工作量;软件生产率;软件开发成本。

各国的软件工程研究者和研究机构已经对软件成本估算做了很多的研究和探索工作,并且总结出一些经验模型,如:Putnam1978年提出的一种动态多变量模型--Putnam模型,International Function Point Users Group(IFPTUG)的FPT(功能点)模型(Function Point)(以FPT作为工作量度量),Boehm提出的结构化成本估算模型一一COCOMO(constructive cost model)(以LOC———源代码行作为工作量度量)等。其中,Boehm在1994年发表的COCOM0Ⅱ模型在实践中估算的软件开发成本与实际成本相差不到20%,进度相差不到46%,已经成为世界上使用最广泛、估算最准确的模型之一。

1.2 软件成本估算模型分析

1.2.1 PUTNAM模型

1978年Putnam提出了一种动态多变量模型———PUTNAM模型。

计算公式:L=Ck*K*1/3*td*4/3

其中:L代表源代码行数(以LOC计),K代表整个开发过程所花费的工作量(以人年计),td表示开发持续时间(以年计),Ck表示技术状态常数,它反映“妨碍开发进展的限制”,取值因开发环境而异,见表1。

从上述方程加以变换,可以得到估算工作量的公式:K=3*L/(3*Ck*4*td)

还可以估算开发时间:td=1/4*[3*L/(3*Ck*K)]

1.2.2 功能点模型

与PUTNAM模型不同,功能点模型采用功能点(FPT)当作软件规模的度量.该模型可按两个元素来计算,分别是信息处理规模和技术复杂度调节因子。

1)信息处理规模

根据信息处理规模,可以把系统组成分成五类,即内部逻辑文件(ILF)、外部接口文件(EIF)、外部输入(EI)、外部输出(EO)、外部查询(EQ)。根据各自的特点,这些元素进一步按权重分成“简单”、“平均”和“复杂”三类。技术复杂度调节因子

2)技术复杂度因子

一般通过计算技术复杂度因子(TCF)来进行技术复杂度调节。TCF的计算方法为:考察一些特定问题,给出回答等级数,最后统计总和。这里回答等级数为:不明显影响;中等影响;平均性影响;显著影响;强烈的影响或必不可少。

考察的问题包括备份和恢复的可靠性、在线修改、安装简易性、数据通讯、可重用性等。

最后,功能点FPT可通过下面的经验公式计算:

1.2.3 COCOMO模型(COCOM081)

COCOMO模型(COCOM081)是由Boehm提出的结构化成本估算模型。是一种精确的、易于使用的成本估算方法。

COCOMO模型中主要会用到以下变量:

DSI———源指令条数。不包括注释,1KDSI二IOOODSI。

MM———开发工作量(以人月计),1MM=19人日=152人时=1/12人年(此处MM与上文提到的PM意义相同)。

TDKV———开发进度(以月计)

COCOMO模型中,必须考虑开发环境,软件开发项目的类型可以分为3种:

组织型(organic):相对较小、较简单的软件项目。开发人员对开发目标理解比较充分,与软件系统相关的工作经验丰富,对软件的使用环境很熟悉,受硬件的约束较小,程序的规模不是很大(<50000行)

嵌入型(embedded):要求在紧密联系的硬件、软件和操作的限制条件下运行,通常与某种复杂的硬件设备紧密结合在一起。对接口,数据结构,算法的要求高。软件规模任意。如大而复杂的事务处理系统,大型/超大型操作系统,航天用控制系统,大型指挥系统等。

半独立型(semidetached):介于上述两种软件之间。规模和复杂度都属于中等或更高。最大可达30万行。

基本COCOMO模型估算工作量和进度的公式如下

工作量:MM=r*(KDSI)c

进度:TDKV=a(MM)b

其中经验常数r,c,a,b取决于项目的总体类型。

COCOMO模型按其详细程度可以分为三级:基本COCOMO模型,中间COCOMO模型,详细COCOMO模型。其中基本COCOMO模型是一个静态单变量模型,它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量。中级COCO-MO模型在基本COCOMO模型的基础上,再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。详细COCOMO模型包括中间COCOMO模型的所有特性,但更进一步考虑了软件工程中每一步骤(如分析、设计)的影响。

表2通过统计63个历史项目的历史数据,得到基本COCO-MO模型的计算公式。

1.2.4 COCOMOⅡ模型

1994年Boehm重新研究和调整原有模型,根据未来软件市场的发展趋势,发表了COCOMOⅡ模型。相比于早期的COCOMO模型,COCOM0II主要做了以下变化:

COCOMO II中使用三个螺旋式的生命周期模型:applications composition,early design,post-architecture(应用构图、早期设计和后体系结构)。

使用五个规模因子计算项目规模经济性的幂指数B,代替了原来按基本、中期和详细COCOMO模型使用固定指数的方法。

扩展功能点测量,使用源代码行(SLOC)代替DSI。

新增加成本驱动因子:DOCU,RUSE,PVOL,PEXP,LTEX,PCON,SITE。

删除成本驱动因子:VIRT,TURN,VEXP,LEXP,MODP。

改变原有成本驱动因子的参考值,以适应当前的软件测度技术。

COCOMO II仍然使用人月来度量软件开发的工作量。人月是指除去节假日之后一个人在一月内所完成的项目工作量。在COCOMO II中,人月与项目进度不同,前者是指工作量,并从中计算开发成本,后者则是指完成项目所需的时间。工作量评估的基本模型如下:PM=A×(SIZE)B

其中,SIZE是估算的软件功能单元的代码行数(以千行为单位),指数B反映了项目的规模经济性,当它大于1时所需工作量(PM)的增加速度大于软件规模(SIZE)的增加速度,体现出规模非经济性。反之,B小于1则表示规模经济性。COCOMOII使用5个规模度因子Wi,采用公式B=0.91+0.01Wi计算指数B,5个规模度因子根据其重要性和价值,在6个级别上取值,由表3给出(来源于COCOMO II.1999软件包);常数A通常取值为2.94。

要计算项目的进度,使用公式:

2 软件成本估算模型研究与改进

2.1 软件成本估算模型研究

综合观察以上的几个常用的方法和模型,每种方法都有各自的优缺点。PUTNAM模型和COCOMO模型是比较早期的模型,只适用于当时瀑布模型的软件开发方式,20世纪90年代后期以后,软件项目管理和开发技术与工具发生了很大的变化,出现了快速应用开发模型、软件重利用工程、面向对象方法以及软件过程成熟度模型等一系列软件工程方法和技术。早期的模型已经不再适应新的软件成本估算和过程管理的需要,于是改进的COCOMOⅡ模型应运而生,这种模型在一定程度上改变了早期模型的一些缺陷,但是仍然存在着一个很严重的问题:成本估算的准确性很大程度上取决于对于源指令数目的准确估算。这在一个软件项目刚启动时是比较难以做到的;同时源指令的行数还在很大程度上取决于开发语言的选择;对于一些算法非常巧妙的程序来说,源指令行数与工作量的大小关系并不是很密切。而功能点方法可以做到与程序语言无关,并且它所依赖的数据,是在项目评估早期就能知道的。但是这种估算方法在计算中主要依靠的是主观因素,而不是客观实际,例如对于功能点复杂度的计算,就必须依靠经验数据。

2.2 软件成本估算模型的改进

考虑到COCOMOⅡ模型和功能点估算方法各自的优缺点,提出一种将功能点和COCOMOⅡ模型结合起来的方法,可以在FPT估算的优点之上再利用FPT本身所没有考虑到的又很重要的COCOMO的成本因素,去正确估算不同开发条件的软件开发成本。可以分为如下几步:

1)应用功能点模型计算出功能点数。

2)利用COCOMOⅡ模型的经验数据将功能点转化成LOC数。

3)通过LOC数,利用COCOMOⅡ模型估算出工作量。

图1给出了这种方法的基本流程示意示意图。

界定软件的范围:这是在提出成本估算问题之后的第一个步骤,对问题进行界定,界定软件的范围(或称为问题的作用域)。软件的范围包括功能、性能、限制、接口和可靠性。界定软件的范围的目的是减少软件开发过程中的不确定因素,以降低估算的难度和不准确性。

问题分解:用分解的技术将复杂问题分解成比较小的、相对简单的问题;为估算软件规模做准备。问题分解得越详尽、越细微,越有利于软件成本的准确估算。问题分解工作是估算软件规模的基础。如何分解必须与下一步中采用的估算软件规模的方法保持一致。

估算软件规模:在问题分解的基础上估算软件规模;如果是基于问题(功能)的估算,则得到UFPT(未经调整功能点);如果是基于过程的估算,则得到LOC。在这一个步骤上,用户可以自由选择采用哪种估算方法。当然,不同的估算方法必须对应相应的问题分解。

数据转换:如果估算软件规模得到UFPT,则按照COCOMOⅡ模型提供的历史经验数据转换得到KLOC;如果估算软件规模得到LOC,则LOC/1000,得KLOC。这一步的目的是得到软件规模的KLOC形式的估算,为下一步的估算提供估算依据。

估算工作量和时间:运用COCOMOⅡ模型,以KLOC为输入,估算软件工作量和时间进度。

这种集合功能点估算和COCOMOⅡ模型的方法具有两方面的优点:首先避免了功能点估算对于历史数据的硬性要求,对于刚起步的软件开发团体这是非常重要的,让更多的软件开发团体可以采用这种方法。二是采用了COCOMOⅡ模型中已经提供的一些参数因子,可以综合考虑各种影响软件开发的因素。