基于SOA 的软件过程管理在中小企业中的应用
摘要: 本论文通过分析中小型软件企业的软件过程管理与改进状况,从改进对象、过程模型、开发对象、辅助工具等方面的分析,提出了一些适合中小型软件企业的过程管理与改进建议,并且,针对中小型企业的软件过程现状,提出了一种基于RUP和SOA的软件过程管理模型,并且可以将该模型应用到中小软件企业的软件过程改进与管理中。
关键字:软件过程改进与管理、SOA、中小型软件企业、RUP
Abstract: Aiming at actualcondition of software process of our country's medium and small softwarecompanies,this paper putforward several strategies of objects to be improved,developmentunit,self assessment and assistant tools.It also
studied simpledesign idea for software process management&assessment system.We expected toprovide some suggestions to software process management and assessment.What has been discussed above, we proposed a softwareprocess management model based on RUP. According to the thinking method of SOAconstruction system, this paper analyzes the service classification of softwareprocess management model step by standards, the software process managementsystem is of a certain scientific and standardization.
Key Words: software process improvement、RUP、 SOA、medium and small-sized enterprises。
0 引言:
中小规模的软件企业或软件开发机构在我国软件产业中占据较大比例,具有灵活机动、响应速度快,组织结构简洁、管理清晰快捷、执行力高,把握优势业务领域、熟悉行业需求等明显优势。与此同时,人力资源不足、人员流动性高,规范程度不高、制度约束度低,对于人的依赖性较高,经验到制度的转化程度较低,软件销售收入占总收入的比重较低、维护成本较高也是中小软件企业或开发机构在管理过程中不容忽视的重要问题。
具体到软件过程来讲,软件开发组织经常会遇到诸如项目经常会延期,任务完成进度难以控制、开发人员不会编写和利用软件文档,需求难以控制,疲于应付需求的变更、软件质量难以保证、软件版本混乱、没有有效的项目管理方法和实践指导等问题,从而影响软件质量与交付,引发客户抱怨,满意度降低。
根据SOA(Service-oriented Architecture)的理念,把一个整体事务看作是由多个小事务组成,因此不论使用的是什么软件流程管理模型,都可以把它拆分成许多个小任务[1] ,并确定每个任务的输入和输出,一旦流程被划分成一个个小任务的时候,系统就可以按照一种特定的需求去重组或者改进流程。本文借鉴RUP(Rational Unified Process)模型为基础,吸收瀑布模型和极限编程等其他模型的优点[2-3],对软件流程管理进行系统分析,使其SOA化。
基于SOA的软件流程管理按照RUP流程,包含了所有的软件开发所应用到的文档及详细过程,根据RUP 流程,软件过程管理模型如图1 所示。整个软件开发分为3个阶段,在第一阶段,项目组成员对项目进行需求调研,直到内部评审通过后,对项目目标、项目范畴进行确定,并对项目进行初步估计[4]。第二阶段,对软件项目进行选择软件过程管理模型,选择范围有RUP、瀑布、原型法等[5],并根据管理模型确定各个阶段的目标,制定里程碑时间,编写人力资源计划,开始在公司寻找相应资源,明确开发环境和软件框架。第三阶段就是项目的正式开始,项目的执行和项目测试。
1小规模企业软件过程管理现状
1.1小规模软件企业特点。
小规模的软件企业或软件开发机构的数量在我国软件产业中占据很大的比重,其突出的特点主要表现在具有灵活机动、响应速度快,组织结构简洁、管理清晰快捷、执行力高,把握优势业务领域、熟悉行业需求等方面。但具备这些优势的同时,兼具有人力资源不足、人员流动性高,规范程度不高、制度约束度低,对于人的依赖性较高,经验到制度的转化程度较低,软件销售收入占总收入的比重较低、维护成本较高等缺点,这也是小规模软件企业在管理过程中不容忽视的重要问题。
1.2小规模软件企业应对策略。
如何最大限度地避免这些问题的产生呢,除了一些不能改变的客观因素外,软件过程管理与改进策略研究在其中占得分量也越来越重,也越来被人重视和研究。提升软件过程的管理水平日益成为工业界和学术界共同的关注点,软件过程管理是提高生产效率和保证软件质量的一个重要方法。在产品开发的整个生命周期中包括一系列复杂的活动,和其他管理过程类似,现代软件过程管理工作也逐渐趋向复杂。根据企业的实际情况和发展需求,优化流程,努力提升人们在过程中的工作能力,从而提升产品质量、提高生产率并降低成本,这是软件过程改进的目的。
具体到软件过程来讲,软件开发组织经常会遇到诸如项目经常会延期,任务完成进度难以控制、开发人员不会编写和利用软件文档、需求难以控制,疲于应付需求的变更、软件质量难以保证、软件版本混乱、没有有效的项目管理方法和实践指导等问题,从而影响软件质量与交付,引发客户抱怨,满意度降低。针对普遍存在的这些管理与技术问题,大多数软件开发组织已意识到应当在软件过程规范、管理、改进方面采取一系列改进措施和辅助手段,如当前业界比较流行的建立质量管理体系、进行CMM/CMMI认证等。
1.3我国小规模软件企业的现状。
目前国内专门从事软件开发的企业有数千家,而这些软件企业主要以中小规模为主。根据有关统计数据结果分析,主要组成结构为:50人以下的企业占55%;50~200人的企业占42%;1000人以上的企业为数不到3%。这些中小软件企业一般具有一些共同的特点,这些特点将直接影响中小软件企业采取什么样的方式来实施软件过程改进活动。软件过程是指软件开发人员开发和维护软件以及相关产品(如项目计划、设计文档、代码、测试用例和顾客手册)的一套行为、方法、实践以及变化过程软件过程管理的重要前提是:软件产品质量的好坏主要取决于开发和维护该产品所使用的软件过程质量。有效的软件过程可将人员、工具和方法进行有机结合。作用对象:软件及其相关产品包括:活动、方法实践和革新。
2 软件过程管理及其改进策略
1.1选择重点,优先突破。
软件过程改进应选择重点领域,循序渐进。因为软件过程改进是要在一定程度上颠覆软件企业现有的软件开发和管理过程,因此对于已经习惯了固有的工作模式的项目经理、开发人员甚至是企业管理者来说,大规模的改动相反会起到适得其反的效果。因此应该从企业的软肋出发,逐渐突破,在一些重点领域,让企业尝到过程改进的“甜头”,从而更好的推进组织级的软件过程改进。
从软件开发过程的角度来讲,不同的软件企业都有不同的开发过程,而且不同的软件项目也会采用不同的开发过程,而开发过程中的需求、设计、编码等阶段,较大程度上依赖于企业自身的技术实力和开发人员的知识、经验及综合能力。而软件过程改进的核心和重点在于管理,因此本文建议将以下几个方面作为软件过程改进的
重点领域。
2.1.1注重项目计划与软件测试工作。
项目计划是项目成功的关键,许多项目的失败都是由于计划制定得不合理或者计划执行不到位而引起的。项目计划应对项目进行合理的规模、成本、工作量等方面的估算,正确的估算是制定项目计划的前提;根据项目自身特点与项目组人力资源状况进行一定粒度的分解。确保每项分解后的任务均可对应到相对比较适合完成这项任务的项目成员;项目任务要充分并行,提高人力资源的利用率;计划安排应留有一定余地,避免出现前松后紧的情况;面对项目计划变更应进行合理评估,考虑到所有可能会受到影响的因素。软件质量是软件企业核心竞争力的首要体现,而软件测试则是软件质量的重要控制措施。规范软件测试过程,将对软件质量的提高起到重要作用。软件测试应由独立的软件测试团队执行,只有这样才能保证软件测试的公正与客观;软件测试计划应尽早制定,软件测试应尽早进行,软件需求确定之后,就应该开始制定软件测试计划;软件缺陷应规范管理,确保所有缺陷都分配到人;结合使用各种软件测试方法;不应忽视软件性能方面的测试与调优。
2.1.2注重配置管理与质量保证。
一个软件项目的所有相关资料,如文档、代码、工具、安装程序等均可作为该项目的配置项。良好的配置管理可以确保软件的一致性。而对于规模较大的并行开发项目来讲,配置管理尤为重要。应做好配置管理计划,选择合适的配置管理软件;对于软件版本进行统一管理,确保多个开发人员协同开发不发生冲突;对于基线配置项的变更应制定变更控制流程,使整个开发与管理过程可追溯可跟踪。软件测试侧重于对软件产品的质量检查和控制,质量保证则侧重于对软件过程进行质量检查和控制。产品和过程是一个软件项目成功的必不可少的两个重要因素,其中产品质量是短期、项目级的影响因素,而过程质量是长期、组织级的影响因素。质量保证也应由专门的人员进行;主要对项目计划、项目里程碑、阶段成果等进行质量检查,记录和跟踪质量问题;质量保证人员可以由软件测试人员兼任,以平衡人力资源的使用;质量保证人员应客观、公正的进行工作。对于以上四个过程领域的改进方法,本文建议首先从建立规范人手,然后在规范的实施过程中,逐步进行修订和完善。一个规范通常由角色职责、工作流程、文档模板、工具支持等四部分组成:具有不同职责、权限的执行人员,按照既定的工作流程进行相关的工作活动,并将T作过程记录以文档的形式保存下来,辅以一定的管理工具,方可保证其工作产品的质量并使其具有延续性和可维护性,这也正是建立规范的主要目标。同时,在规范的范畴内,所有人员遵循同样的行为准则,能够更好的进行沟通。
2.2结合优秀的软件过程元素。
CMM/CMMI是目前业界进行软件过程改进的首选模型,其实CMM/CMMI已成为事实上的标准。世界各国的软件企业纷纷遵循CMM/CM—MI建立起软件过程规范,积极进行CMM'/CMMI的认证。然而如前文所述,我国的中小软件企业未必适合完全按照CMM/CMMI来进行软件过程改进,反而可以结合众多软件过程模型,从自身的实践中总结出一套适合自己的软件过程改进模式。RUP(Rational Unified Process,统一过程)的迭代思想和XP(Extreme Programming,极限编程)的测试驱动开发方法即可以尝试引用到企业当前的软件过程中来。
2.3重视个体软件过程改进。
开发人员是一个软件企业组中最小的开发主体,开发人员编码质量的高低、工作计划是否恰当、时间利用率的高低、缺陷率的高低等均会对软件质量以及组织的软件过程产生重要影响。因此,个体软件过程(PSP,Personal Software Process)的概念被提了出来,相应的也出现了个体软件过程改进这一概念。PSP是一种用于控制、管理和改进软件开发人员的个人工作方式的过程,它包含一套完整的方法、表格和规程,用来指导开发人员如何计划、度量和管理自己的工作。个体软件过程改进可以首先从计划管理、缺陷管理、时间管理等几个方面人手,同时可以配合任务检查单等工具。通过锻炼个人工作估算和计划能力,提高对工作任务的驾驭程度;通过管理缺陷,提高个人以及整个项目对于软件缺陷的控制程度;通过记录和分析时间利用情况,来掌握工作效率以及时间利用率等方面的一些基础指标;任务检查单,则可以与计划管理和缺陷管理搭配使用,有利于个人工作任务的管理。
2.4重视自评估。
软件企业经常会盲目地进行软件过程改进,在没有明确自身软件过程处于何种阶段、何种水平的情况下,贪大求全地建立了一整套软件过程规范,而实施效果却差强人意。因此,在进行软件过程改进之前,以及在进行持续改进的过程中,对自身软件过程进行自评估是非常必要的。软件过程自评估主要采用调查问卷的方式,另外可以结合某磐软件度量的方法,通过定性和定量相结合的方式,形成当前软件过程状态的评价。调查问卷方式,需要设计关于软件过程现状的调查问卷,这些问卷可以是针对某个过程领域的,也可以是针对整个软件过程的。然后在组织内部选择不同岗位的人员参与一次评估,根据问卷调查结果,得出相应的结论。
2.5适当利用辅助工具。软件过程管理与改进的本质是一个管理的过程,管理就需要遵守规则。利用软件工具进行软件过程管理是软件企业普遍采用的方式。目前在软件企业应用较多的软件类别有项目管理工具、配置管理工具、软件测试工具、缺陷管理工具等,这些工具一般都是针对某一个过程领域,具有强大、完善的功能,企业可以根据自身需要选择相应的工具进行辅助管理。但美中不足的在于,适合于中小软件企业进行整个软件过程管理的轻量管理工具还不多见,有些厂商的工具配置复杂、价格高昂,令中小企业望而却步。
3软件过程特点分析
在工业生产领域,一个优质良好的生产线基本能够生产出有质量保证的产品,因为所有的原材料、加工过程都是可控的,最终必然会形成一件合格品。而在软件领域,要想顺理成章的实现这种生产线则比较艰难,因为这是由软件产品本身的特点决定的。软件产品是无形的且具有较高复杂性的逻辑产品,其研制过程是依赖于人的脑力劳动,且需要根据需求、环境及硬件进行修改,而且软件工作牵涉到机构、体制、管理方式、人的观念和心理等社会因素,这些因素常常成为软件开发的困难所在,直接影响到产品或项目的成败[I]。
从19世纪60年代开始,软件产品的这些特性导致了软件危机的产生,软件危机引出了软件工程。软件工程三要素(过程、方法、工具)中比较重要的一个就是软件过程,软件过程是软件工程的精髓所在。软件过程是企业设计、研制和维护软件产品及相关资料文档的全部生产活动和工程管理活动。软件过程贯穿于软件开发的各个环节。软件过程定义了方法使用的顺序、可交付产品(文档、报告以及格式)的要求、为保证质量和协调变化所需要的管理,以及软件开发过程各个阶段完成的标志[1]。随着软件危机的出现,软件开发者们将更多的注意力投向了软件过程,试图通过类似于工业生产过程控制的软件过程控制,来保证软件产品的质量。这也就是软件过程改进的产生原因。
从20世纪80年代起,对于软件过程改进及评估的研究层出不穷,多种过程模型相继出现,将软件过程研究推向了一个高潮。这些模型中最负盛名的也最广泛被全世界软件企业所接受的便是CMM/CMMI,即软件能力成熟度模型/能力成熟度集成模型。除CMM/CMMI之外,加拿大的Trillum模型、欧洲的Bootstrap方法、6Sigma等也都比较著名,这些不同的模型既有共性,也各具特点,其强调的重点不尽相同。客观的说各个模型是互补的,不存在本质冲突,然而就具体软件开发商而言,面对不同的客户,必须按其特殊的要求,建立不同的管理和评估系统,势必增加企业运营成本,很难适应。因此国际标准化组织(ISO)和国际电
工委员会(IEC)开始联手制订“信息技术过程评估”标准(ISO/IEC 15504),该项标准包括五个标准,对评估模型、评估要求、评估实施、评估范例等进行了详细的规定。ISO/IEC 15504标准已于2006年正式完成,它不仅是一个过程评估模型,更是一个过程评估的框架,对其他模型的开发起到了指导性的作用,必将逐渐成为国际上软件和信息技术过程评估标准的主流。
综观国内外关于软件过程改进方法、模型、工具等的研究和开发,我们不难发现,中国绝大部分中小软件企业的软件过程尽管存在较大的改进空间,但考虑到企业文化、技术水平、业务领域等因素,在过程改进之初便完全采用基于西方管理思想的CMM/CMMI标准却未必适合。我国目前针对中小软件企业过程改进研究的一般模式是:对CMM/CMMI进行适度裁减,形成一个轻量的框架,或者基于CMM/CMMI对软件过程中的某个关键过程领域进行研究,如项目管理、质量管理、配置管理等,相应的软件工具也是基于这样的模式进行研发。
这样做仍然全部将中小软件企业的软件过程置于CMM/CMMI范畴之内,而对企业个性有所忽略,而且摒弃了其他优秀的软件过程模型的精华,导致软件企业在软件过程改进中存在灵活性和过渡性较差、持续改进力度较小等局限性。另外由于软件企业对软件过程改进的认识普遍存在偏差,通常以通过CMM/CMMI认证为目的,而未将过程改进作为持续的组织策略进行推广和贯彻,从而使中小软件企业的软件过程管理与改进陷入尴尬局面。
4 基于RUP的软件过程管理模型
根据RUP 流程,软件过程管理模型如图1 所示。整个软件开发分为3个阶段,在第一阶段,项目组成员对项目进行需求调研,直到内部评审通过后,对项目目标、项目范畴进行确定,并对项目进行初步估计[4]。第二阶段,对软件项目进行选择软件过程管理模型,选择范围有RUP、瀑布、原型法等[5] ,并根据管理模型确定各个阶段的目标。制定里程碑时间,编写人力资源计划,开始在公司寻找相应资源,明确开发环境和软件框架。第三阶段就是项目的正式开始,项目的执行和项目测试。
在这个软件过程流中,只有在需求调研时期,公司组织有内部评审,当项目不符合,或者公司无法完成项目的时候,在这个阶段可以通过内部评审的机制结束或修订软件项目,而当通过内部评审后,从项目立项到项目执行结束期间,再没有任何修正机制,这是一般软件企业所使用的软件过程方法。众所周知,软件项目固有的复杂性、易变性和不可见性,尤其是在软件项目开发过程中的易变性致使软件开发周期长、代价高和质量低等问题。因此基于这些问题,本文提出一个改进的软件过程管理模型。如图2所示。改进后的模型在原来的基础上,在项目执行和项目测试之间增加了一个评估的模块,这个模块在项目执行当中,以项目实施各阶段的时间表为基准,对项目实施进行监控,当项目开发出现问题的时候,可以调整软件过程管理,重新部署,使之适应软件项目的开发。
5基于SOA 的软件过程管理流程改进
这种需要企业业务灵活应对外部环境变化的行为正迎合了SOA 的思想,因此要达到对软件过程的这种改进,就需要在这个基础上对软件过程进行SOA化建模。建模是面向服务体系结构项目,不同于传统的建模方式,第一步是选取的所有事项都和具体的业务相关。基于SOA 建模要确定这些业务所执行的活动或流程实际是什么[6]。对业务体系结构进行记录后,这些记录不仅可以用于规划SOA,还可以用于对实际业务流程进行优化。
依据SOA 思想构建系统的步骤,首先把软件开发过程5 大阶段(需求阶段,环境配置阶段,设计阶段,编码阶段以及测试阶段)进行服务分类分析,并规定每个任务模块有相应的输入和输出以及判定标准[7]。使用SOA 的思想,首先对软件过程的每个阶段进行服务鉴别和服务分类,提取出关键的组件,以构件化服务的形式对其进行实现。
5.1 需求分析阶段改进
在软件过程中,需求分析指的是在建立一个新的或改变一个现存的系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。需求分析是软件过程中的一个关键过程[8]。在需求分析阶段,项目的任务还是比较少的,主要是收集需求、分析需求和管理需求3个任务,可以作为SOA 思想中所描述的关键组件。这3个任务是整个需求分析阶段的关键工作流,在一些软件公司里还有其他的附加的流程,例如需求阶段审核,但本文认为这样的任务流可作为需求阶段的可选任务,即非关键工作流。需求阶段关键服务流分析结果如表1所示。
5.2 环境配置阶段改进
完成需求分析后,软件项目进入到环境配置阶段,环境配置和需求分析都属于软件开发的前期准备阶段,还不算真正的展开项目[9]。在环境配置阶段中最重要的任务就是根据现有软件项目的种类、规模决定对现有的模型进行裁减,这个阶段同时会影响接下来各个阶段的实施情况。环境配置阶段的任务只有一个就是裁减模型[10]。这个阶段是整个软件过程管理改进模型的核心部分,因为在这个阶段中,是对软件项目管理模型进行筛选和改进,是整个项目开发中首次对管理框架进行调整,也称为软件过程管理系统实现SOA化的第
一步。项目经理可以根据之前所做的项目需求报告,得到项目的范畴、大小以及完成时间要求,并根据这些要求对项目所采用的管理开发模式进行选择改进。环境配置阶段服务流分析如表2 所示。
5.3 设计阶段改进
设计阶段承接了需求分析阶段的要求,对软件项目的框架、技术、数据库及接口进行了从言语描述到程序实现的设计[11]。这个阶段主要由软件设计师完成,前台设计人员根据需求文档实现用户界面接口,高级程序员再根据需求设计选择框架以及确认技术风险,然后确定用户行为细节和数据库设计。根据SOA思想对其过程进行服务组件鉴别,可以得到关键服务组件——构建框架、软件行为详细设计、数据库设计、用户接口设计、开发平台设计和设计检验。设计阶段关键服务流分析结果如表3所示。
5.4 编码阶段改进
编码阶段是整个软件过程流中真正开始编写代码的时段。该流程任务包括明确项目按计划完成的情况和测试阶段的前期准备。此任务开始的标志是,程序员编码开始、管理计划正在进行中[12]。其主要分为3个同时进行的工作流:构建代码、检查代码、发布版本。在每个工作流中包含的关键组件有:建立流程、系统集成、集成计划和构建发布版本。编码阶段关键服务流如表4所示。
5.6 测试阶段改进
测试是保障软件质量的重要途径,是针对软件这一特殊产品的一道生产工序,是软件质量保证的重要一环。也就是说,软件测试不是项目管理过程的需要,而是软件过程的需要。软件测试阶段的关键过程有执行开发测试、代码检查、软件测试准备、测试计划、设计测试、执行测试。测试阶段关键服务流如表5所示。
6 结束语
现在的市场已经不允许企业再花大量的时间去适应瞬息万变,因此企业需要做到灵活应对。尤其是对于软件服务的需要,将来的系统应该是非原子性的,是可以分割的,这种系统组合可以随着市场需求的变化而做出相应的变化,而不是单一地针对某一方面的市场,或者制作庞大的期望能涵盖所有功能的系统。把软件过程管理模型分块进行分析,进而划分成各个小任务,并对每个任务实施进行输入输出控制,使整个管理过程SOA化,这样基于SOA 软件过程管理就形成了初步的框架,然后明确什么时候、什么状态下管理人员需要对本身的软件过程管理进行裁减、修正,有助于企业避免重复工作,真正地实现软件服务的灵活性,同时还可以支持在各个领域彼此关联的服务,增强对元数据的管理。
软件过程改进不是一蹴而就的过程,软件企业需要在不断的积累中持续改进。通过实践总结,分析了中小软件企业的特点与困境,软件巨头使用的软件过程改进与管理的方法获取很先进,但是并不一定适应中小企业的情况,中小企业在软件过程改进的进程中一味的适用这些方法,可能会导致一些不便甚至会带来一些问题。
本文提出的基于SOA的软件过程改进与管理流程方法,可以将此方法应用到中小软件企业中,提高企业的软件过程改进与管理的能力。当然,对于每种策略的具体实施,本文并未提出深入的方法,如基于RUP、XP、CMMI等软件过程模型相结合的软件项目实践、PSP中的软件度量方法、软件过程管理与评估系统的试用与持续完善等,均是我们下一阶段的重点研究和方向。
参考文献
[1]钟珞.软件工程EM].北京:清华大学出版社
[2]郑栋,谭玲,顾庆,陈道蓄.基于CMMI的小型软件过程自评估工具[J].计算机科学,2006,33(2):263~265,276
[3]李惠,陶陪基,李文锋.XP、RUP结合起来开发小型项目[J].计算机工程与设计,2005,26(6):1678~1680
[4]王丹华,尹俊,潘金贵.基于PSP/TSP的软件过程改进框架[J].计算机应用研究,2006,(12):206~208
[5]郑蕾娜,潘铁军.基于CMMI的中小企业软件研发集成平台[j].浙江万里学院学报,2004,17(5):22~26
[6]黄常宝,沈备军.一种PSP工具的研究和实现[J].计算机应用与软件,2007,24(4):10~12
[7]杨昌锋,王冠,司建辉.基于SOA 构建新一代的企业应用集成[j].计算机应用与软件,2005,22(10):122-133.
[8] 徐赛华.软件需求分析研究[j].吉林师范大学学报:自然科学版, 2006,27(1):104-105,110.
[9]倪晓峰,赵文耕,张婕.构件软件配置管理及其版本控制技术研究[j].计算机工程与应用,2005(2):94-96,145
[10]李娜,钱乐秋,赵文耘,等.可变粒度及面向过程的软件配置管理系统[j].计算机工程,2006,32(10):64-66,150.
[11] 方滔.需求变更管理中的可视性问题及其解决方法[j].自然杂志,2003,25(6):332-334.
[12]楚书来,于文新.小规模软件企业软件过程管理与改进策略研究⋯ .黑龙江科技信息,2O1 2,02:1 99—2O0.