(软件工程理论、方法与实践)第15章软件过程改善.ppt

　　　　　15.1 软件过程类型　　IEEE定义过程(Process)是针对目标的一系列步骤。软件过程(Software Process)是人们用于开发和维护软件及其相关产品的一系列活动、方法、实践和转换。其中的相关产品可能包括项目计划、设计文档、代码、测试用例、用户手册等。　　当前的软件开发机构和组织中所采用的软件过程，通常可分为四种类型：非正式的过程(Informal Process)、已管理的过程(Managed Process)、有方法的过程(Methodical Process)和改善的过程(Improving Process)。 　　非正式的过程没有严格定义好的过程模型，所用过程的选择取决于开发团队。非正式的过程可能使用规范的软件活动和规程，例如配置管理，但是所用的规程以及规程间的关联关系并没有事先定义。非正式的过程仅适合原型系统、短生命周期系统、中/小规模的软件和用4GL语言构建的系统的开发。　　已管理的过程有定义好的过程模型，用来驱动开发过程。过程模型定义了所用的活动和规程、它们的进度以及规程间的关联关系。已管理的过程适合中、大型和长生命周期系统的开发。 　　有方法的过程具备很多定义了的开发方法，如系统的面向对象设计方法。有方法的过程适合于对应用域有很好理解的系统以及进行再工程的系统等。这些过程具备有效的方法和工具的支持，如分析和设计工作平台、原型建立工具、测试工具等。　　改善的过程有其固有的改善目标。开发机构对过程改善设立了专门预算，具有不断改善过程的自觉意识，并引入了改善的活动。很多时候，作为过程改善基础，常引入对过程度量的量化活动。 　　当然，一个过程可能属于多个类型。比如，过程可以是非正式的，因为它是开发团队选择的结果。团队可能选择使用一个特别的设计方法，他们也可能有过程改善的能力。因此过程分别属于非正式的、有方法的和改善的类型。　　目前绝大多数软件过程都有CASE工具的支持，因此它们是有方法支持的过程。工具对过程支持的有效性依赖于过程分类。举例来说，非正式的过程能使用通用工具，如原型建立语言、编译器、调试器、字处理器等，但一般很少持续使用更专业化的工具。图15.1给出了在软件开发当中可以使用的各种工具。特定工具的效力取决于使用它的过程类型。 图15.1 过程工具的支持 　　　　15.2 过程改善活动15.2.1 过程改善　　虽然开发机构在开发相同类型的软件时明显地有很多相同之处，但许多软件机构也会因自身的因素、规程和标准影响着过程。因此，对其他或通用过程改善方法的简单引进并不适合开发机构自身的特点。不断地分析、总结和评估自身软件过程，并加以改善应该是软件机构的一项明确、持久的活动。　　过程改善的通用模型如图15.2所示。 图15.2 过程改善的通用模型 　　在过程改善的过程中有以下几个关键阶段：　　(1) 过程分析。过程分析包括检查已有的过程并建立过程模型并以文档记录和理解过程。尽可能量化地分析过程，这可以为过程改善提供有力的依据。在变更的前后所做的量化分析可以对过程变更的利与弊做出客观的评估。　　(2) 识别改善。这个阶段的活动是要利用过程分析的结果，发现影响质量、进度或成本的因素，以利于在后面的活动中提出新方法和工具来解决这些问题。 　　(3) 引入过程变更。引入过程变更就是要加入新的规程、方法和工具，将它们和其他的过程活动加以集成。同时要保证这些变更不和其他的过程活动以及机构已有的规程和标准发生冲突。　　(4) 训练工程师。对软件工程师进行培训，让他们能理解、适应并完成变更。　　(5) 调整变更。过程变更需要有一个调整阶段，其间会有问题的出现和对过程不断修改、执行的反复工程。调整阶段往往会持续数月，直到工程趋于稳定且能让开发工程师很好地适应。 15.2.2 过程分析和建模　　软件过程改善活动中，过程分析极为重要，正确、有效地分析现有的过程，抽取的过程关键特征并度量是过程改善的基础。因此，过程分析人员需要通过调查问卷和向项目中的工程人员询问实际过程中执行的情况，自动收集或手工收集各种过程数据(如程序员的编码进度、每千行代码测试出的错误数等)，对过程进行详细的分析，并建立过程模型。 　　过程模型既可以用很详细的形式表达，也可以用精简的形式描述。第2章所阐述的通用过程模型为本章讨论过程改善打下了基础，但这些模型并不包括足够的、用于过程分析和改善的信息。过程改善需要有关过程活动、可交付内容、人员、通信、进度以及其他的机构过程等能对软件开发过程带来影响的各方面信息。表15.1说明了一个详细的过程模型应该包括哪些内容。 　　另外，时间安排以及活动、可交付内容和通信之间的依赖关系也必须要在过程模型中体现出来。同一个工程师可能参与到几个交替或并行的活动，可交付内容也会依