和国内很多大型软件开发组织一样，到目前为止，我们在大型软件项目开发中，主要采用的是结构化方法和瀑布模型.项目开发中已采用的面向对象技术仅仅局限在面向对象编程，虽然采用面向对象语言在项目开发中取得了成功，但如何将开发组织从传统开发方法过渡到面向对象开发方法仍面临着很多困难，其中重要的一点是缺少面向时象软件过程的支持。

原有的软件过程.是针对结构化开发方法制定的，因此，采用面向对象开发方法后，在组织内部需要通过一系列工程活动来实现对原有软件过程的改进。

1 软件过程模型改进

软件过程模型是对软件过程的抽象描述与定义.软件组织的过程模型概括了一类过程的共同点，为其内部各项目开发团队规定一个基本过程框架，说明过程中的活动、任务和执行顺序，指导具体的工程开发。

对软件过程模型的改进主要表现为对相关活动的改进.在面向对象开发环境中，传统的软件过程有些能与面向对象开发相适应，有些则不能.以下从迭代式过程和分析设计建模过程两部分说明。

1.1 迭代式过程

原有的软件开发过程采用的是瀑布模型，软件开发从需求分析、设计、编码、测试到交付维护是一个线形、顺序过程.这种过程顺利运作的前提足需求不能经常变动，但是，在实际软件项目开发中，需求的易变性使各项活动并非完全按照自上而下、线性进行.采用面向对象开发方法后，分析和设计的顺序也会发生变动，有些分析活动需要在其它部分设计之后进行，分析设计之间很难有明确的界线，此外，面向对象的项目开发也不再是从无开始，可以重用已有的模型、类库和体系结构等.为了满足这些要求，应该采用一种迭代、增量的过程.迭代过程保持传统阶段划分方法不变，在阶段结束处建立里程碑、评审标准等.迭代过程和原有顺序过程的不同点在于阶段的内部，每个阶段的工作由一个或多个迭代组成，每个迭代可以理解为一个小的瀑布模型，包含了分析、设计、编码、测试等活动。

在每个迭代中，分析、设计、编码、测试等活动遵循瀑布模型的执行顺序，软件配置管理、项目管理、质量管理等管理方面的活动贯穿于其中.每次迭代完成软件开发的一个子集，后序迭代在前一次的基础上增量开发.从软件开发的阶段来看，需求分析、设计、编码、测试等活动不再局限在某个具体阶段，而是分布在各个阶段之中，只是活动的工作比重有所不同。阶段内迭代的次数需要根据具体的项目来确定，例如，分析阶段的任务往往通过一次迭代就可以完成，但是，在某些情况下，系统需求复杂，需要多次开发原型来帮助分析，则需要多次迭代才能完成。

采用迭代、增量式过程，软件开发组织内部对软件过程的管理应分为两个层次.开发组织和具体的项目开发团队共同负责各开发阶段的管理;项目开发团队负责阶段内迭代的管理‘在每次迭代之前，开发团队制定迭代的前呈条件、计划、输入、任务、检验准则、输出结果和后置条件等.只有在迭代的前置条件得到满足后才能进入本次迭代，后置条件如果不能满足，迭代也无法结束.迭代内部的活动可以采用不同的技术来实现，就采用面向对象技术而言，分析、设计也存茬多种方法，因此，该迭代过程只定义了一个基本过程框架。

1.2 分析设计建模过程。

迭代过程说明面向对象的分析设计活动分布于各个阶段，活动由任务构成，任务说明需要做什么.面向对象分析设计的主要任务是为系统建模，但是，对于习惯于传统结构方法而缺少面向对象分析设计经验的开发人员来说，仅仅了解分析、设计活动的任务是不够的，任务没有说明怎么去，他们需要的是可以指导实戏的过程指南，详细地描述怎使用面向对象技术进行建模.因此，软件开发组织需要寻一种适合自己开发特点的方法来解决这一问题，在切以UML一建模语言被OMG组织确定为标准的面向对象建模语言后，”面向对象方法之争”似乎已经结束，但实际UML只是一种标记语言，没有过程的概念，采用UML进行面向象分析设计建模仍需要过程的指导，面向对象建模过程和统的结构化方法是完全不同的，所以，过程模型改进的一重要书壬务是制定面向对象分析设计建模的过程框架。

一般认为分析、设计建模琦任难区分，但是，工程开发有阶段划分的要求，分析阶段的任务和设计阶段是完全不同的，所以，分析、设计建模应划分为一些可以区分的主要建模活动，并确定活动的任务.采用UML语言进行面向对象建模可以从不同侧面用多种图形描述系统，为了指导实际开发，主要建模活动可细化为一系列子建模活动，每个子建模活动完成系统建模的一部分任务，并附上相应的指南.例如，在分析建模时，建立用例模型这一主要活动就可划分为识别角色活动、识别用例活动、建立用例图活动等.由于系统开发的特殊性，应该定义一些核心建模活动和一些补充建模活动，核心建模活动是组织内部项目开发团队必须遵循的活动，而补充建模活动是供项目开发团沙诱民据实际需要选择的活动。

在采用UML建模过程中，需要用到用例分析、用例描述、体系结构设计、类设计等专业技能.有些工程开发人员经过学习具备了多项专业技能，而原来擅长结构化分析设计的工程开发人员可能不具备这些技能，为了便于工程管理，不应以开发人员作为活动的执行者，而为每个建模活动确定相应的工作角色，并说明应有的技能。

为了描述建模过程，定义了活动、子活动和活动的执行者，最后还必须定义完成活动后产生的文档.采用UML建模语言进行面向对象建模，最终文档的表现形式上与传统的结构化方法有所不同，为此，需要做两个方面的工作：

1)定义力部文档 内部文档是完成相应建模活动后编制的文档，作为检验建模活动完成与否的依据。例如:用例模型文档、序列图文档等；

2)定义赤准丈秽时君种与面丙对家图召时对龙差不标准文档主要是指符合国家标准、军用标准的文档，作为阶段完成处评审的依据.但是，由于目前的标准文档隐含了结构化思想，和面向对象思想不能直接对应，组织内部需要建立对应关系。

2 工具引进和培训

为了保证软件过程改进的实现，需要CASE工具来支持新软件过程中的某些活动.例知，采用UML语言进行面向对象建模时，建模活动的工作量非常大，没有工具的支持，建模活动很难按计划完成.此外，采用迭代式过程，对配置管理、需求管理的要求有所增加，也需要工具的支持。为了引进CASE工具，支持过程的改进与实施，在开发组织内部应成立专门的技术小组，负责工具的选型、研究、培训和技术支持工作，制定工具的使用过程和与软件过程集成的方法，具体任务如下：

1)工弄选型 根据项目特点和软件过程的需要，对国内外相关的CASE工具进行比较和选购.目前，我们已购买了覆盖分析、设计、编码、测试、配置管理和文档制作等方面的CASE工具。

2)技术培训 技术培训有两部分内容:①向有关工程技术人员，介绍改进后的软件过程模型以及面向对象分析、设计方法;②针对新引进的工具，向项目开发团队中的工程技术人员介绍工具的使用方法和与软件过程集成的方法。

3)技术支持 项目开发团队在软件过程的具体运作过程中，如果遇到有关CASE工具方面的问题，由隶属于软件开发组织的技术支持小组来帮助解决。

3 软件过程配置

为了将改进后的软件过程模型应用到具体的项目开发中，需要对软件过程进行配置.本文的配置工作就是根据项目的目标和特点，对过程…模型进行裁剪和实例化，定制具体项目的软件过程.软件过程的配置工作由项目经理和软件过程工程师完成。在实际应用中这两个角色可以由具有相应技能和职责的人员担任，例如，我们在原有项目人员配置上增加了软件工程化师，其中一个重要任务就是和项目负责人一起，配置本项目的软件过程.过程配置工作分为选择活动、映射工作角色和选择文档3个部分。

1)选择活动 项目开始之初的活动有选择CASE工具、定义目标环境、选择各类过程指南、制定各类计划等.软件过程模型说明了软件过程中的一些主要活动，以及构成主要活动的每一个子活动，这些活动是否适用于具体项目，需要根据项目的特点而定，为了实现质量管理，在每个主要活动结束后，都应该选择相应的评审活动；

2)映射工作角色 对于软件过程的各项活动，在过程模型中已明确了具体的工作角色，不同的工作角色需要具有不同的技能.项目开始时，项目经理和过程工程师有两项工作要做.首先，确定开发团队中是否具有相应的技术人员，哪些角色是必须的哪些是可选的.另一项重要工作是为团队中的开发人员分西幼目应的工作角色，有些工程技术人员具备多项技能，可以担任多个工作角色。但是，由于很多熟悉传统结构化技术的工程人员不能立即胜任面向对象分析设计工作，需要在项目中引进一些面向对象专家，不断地进行技术培训.否则，会因为缺乏相应的人才，使软件开发活动无法顺利地展开；

3)选择文件 我们在软件过程模型中将文档分为标准文档和内部文档.标准文档采用的标准由开发方和使用方共同确定，内部文档的选择主要根据.项目的管理要求和选择的活动来确定.例如，采用UML进行建模，需求描述可以只采用用例模型，也可以增加活动图作为补充说明.内部文档的形式也很丰富，对每个用例进行分析后，可以产生相应的序列图、类图，设计建模还要产生组件图、部署图等.此外，由于用式，原的划理档也所扩充，例如，每次迭代的进度、任务、评枯准则等.项目开发团队应根据实际需要进行文档的选择。

在配置具体的项目软件过程之后，进行实际的工程运作，运作过程中得到的反债信息可应用于本项目的过程改进，由项目经理和过程工程师对本项目或后序项目进行重新配置。

4 结束语

在软件组织内部实现软件过程改进是一项复杂的工程，涉及到人员、方法、技术、管理、工具和文档等诸多因素，并且与软件组织的特点和需要开发的项目类型也密切相关.对于项目开发团队而言，过程改进的成功与否直接关系到项目开发的成败，本文提出的方法在我们软件组织内部已进行了实践，解决了一些实际问题，取得了较好的效果。