第二章软件过程.ppt

1、1,第二章 软件过程,2,引子什么是过程？,过程是为了达到一个目标所进行的一系列活动，或者说是为达到一个目标而设计的“路线图”。,3,体操运动员培养过程,例如，为了培养一名世界体操冠军，需要研究训练的方法、运用先进的训练器械、不断改进训练过程，最终有可能培养出世界体操冠军,4,软件工程有过程成功？,为了开发出优秀的软件，能够总结出一套“开发过程”？ 在开发软件的时候，严格按照这套“开发过程”的要求去做，增加软件开发成功的机会？,5,软件工程：过程-工具-方法,成功目标： 软件开发和维护工作的目标是按时交付高质量的、满足需求的、低成本的软件。例子： 过程：RUP过程或者敏捷过程 工具：设计Rat

2、ional ROSE、开发Jbuilder 方法：面向对象方法。,6,定义1：计算机科学技术百科全书中指出，软件过程是软件生存周期中的一系列相关过程。过程是活动的集合，活动是任务的集合。定义2：软件过程是人们开发和维护软件及相关产品（如软件项目计划，设计文档、代码、测试用例及用户手册）的活动、方法、实践和改进的集合。,2.1软件过程概念,7,1995年国际标准化组织公布ISO/TEC 12207 信息技术软件生存期过程 5个主要过程 8个支持过程 4个组织过程 每个过程包含一组活动，每项活动又进一步划分了一组任务,9,主要过程：,获取过程需方获取系统、软件产品或软件服务的活动。 由需方定义需求

3、，委托供方或双方一起进行需求分析，其结果由需方确认。 需方应该准备招标书、合同以及验收条款。,10,供应过程由供方向需方提供系统、软件产品或软件服务的活动。 供方要对需求进行研究，准备投标，中标后签订合同。 制定项目计划、实施计划、开展评审、交付产品。,11,开发过程开发者定义并且开发软件产品的活动。 由开发者参与进行系统分析和系统结构设计，然后进行软件分析、软件结构设计和软件详细设计。 在设计的基础上着手编码和测试，将通过单元测试的软件集成在一起，进行系统集成和系统测试，最后进行安装，并且提供验收支持。,12,运行过程供方协助需方制定运行计划并进行运行测试； 最终由运行支持者运行系统。,13

4、,维护过程维护者提供系统维护服务的活动。 用户对系统运行中出现的问题进行记录，维护者分析维护记录，实施变更； 对维护结果做维护评审。,14,支持过程,文档编制制定文档标准； 确认文档信息的来源和适宜性； 进行文档的评审及编辑； 批准文档发布； 文档的生产、提交、存储和访问控制； 进行文档维护。,15,配置管理过程实施配置管理过程. 配置标识； 配置控制； 记录配置状态； 评价配置； 发行管理。,16,质量保证过程为确保软件产品和软件过程符合规定的需求并能按计划完成所需的活动。,17,18,验证过程为证明一个产品符合规格要求所进行的工作。验证包括：合同、过程、需求、设计、编码、集成和文档的验证。

5、 确认过程为确保最终产品满足使用要求的活动。包括对测试结果、软件产品用途的确认，测试软件产品的适用性。 联合评审过程实施项目管理评审，包括项目计划、进度、标准、指南等的评价；技术评审，包括评价软件产品的完整性、是否符合标准等。 审核过程检验项目是否符合需求、计划、合同、规格说明和标准。 问题解决过程分析和解决开发、运行、维护或其它相关过程中出现的问题，提出响应对策，使问题得到解决。,19,管理过程制定计划、监控计划的实施，评价计划实施情况；包括产品管理、项目管理和任务管理等内容。 基础设施过程为开发、运行和维护等其它过程所需的硬件、软件、工具、技术、标准，建立基础设施，并提供维护服务。 改进过

6、程对整个软件生存周期过程进行评估、度量、控制和改进。 培训过程对人员进行相关培训所需的活动，包括制订培训计划；编写培训资料；培训计划的实施。,20,注:1：,ISO/IEC 12207给出了一个软件过程的公共框架，提供了一组标准的过程、活动和任务。 目前还没有最佳的软件过程！,21,注意2：,三类过程中分别包含了许多活动，每个活动还有任务，太复杂了！ 这么多过程应该何时用？如何使用？为了便于使用软件过程，软件工程的前辈给我们提供了一些常用的软件过程模型。,22,注意3：,提倡软件过程不断改进。吸取典型软件过程模型的精华，根据开发机构和软件项目的特点，制定适合的软件过程。 选择软件过程模型时通常

7、要考虑软件项目的规模和应用的性质、采用的方法、需要的控制以及特点等因素，对这个公共框架进行适当的裁减，以符合实际的需要。,23,2.2 软件过程能力成熟度模型,选择工程承担着没有合理、统一的标准！软件开发组织的开发和维护过程中，组织能力和过程规范性等方面存在很大的差异，需要有一个公平、有效和规范的评价标准。,24,在20世纪80年代末美国的卡耐基梅隆大学软件工程研究所（SEI）研究了一个能力成熟度模型（CMM）。 专门用于评价软件开发组织的软件过程能力。-初衷是为大型软件项目招投标活动提供全面而客观的评价依据，目前它已成为业界评价软件开发组织软件过程能力的公认标准。,25,CMM划分了五个能力

8、成熟度等级： 初始级 可重复级 已定义级 已管理级 优化级 为软件项目招投标活动提供了评判依据； 为软件机构过程改进提供了方向和目标。,26,第1级：初始级 特征 软件过程的特征是无序的、偶然的，有时甚至是混乱的。 几乎没有过程定义，成功完全取决于个人的能力。 关键域：无,27,第2级：可重复级。 特征： 建立了基本的项目管理过程，能够跟踪费用、进度和功能。 有适当的和必要的过程规范，可以重复以前类似项目成果。 关键域： 软件配置管理、软件质量管理、软件合同管理、软件项目跟踪和监督、软件项目计划、需求管理。,28,第3级：定义级。 特征： 包含第2级所有特征。 用于管理工程活动的软件过程已经文

9、档化、标准化并与整个组织的软件过程相集成。 所有项目都使用统一的、文档化的、组织认可的版本来开发和维护软件。 关键域：包括第2级所有KPA，还有同级评审、组内协调、软件产品工程、集成的软件管理、培训计划、组织过程定义、组织过程焦点,29,第四级：管理级。 特征： 包含第3级所有特征。 软件过程和产品质量的详细度量数据被收集，通过这些度量数据，软件过程和产品能够被定量地理解和控制。 关键域：包括第3级所有KPA，还有软件质量管理、定量的过程管理。,30,第五级：优化级。 特征： 包括第四级的所有特征。 通过定量反馈进行不断的过程改进，这些反馈来自于过程或通过试验新的想法和技术得到。 关键域：包括

10、第4级的所有KPA，还有缺陷预防，过程变更管理和技术变更管理。,31,评估表：,上面的模型从低级到高级定义了每个级别应该达到的标准，如何判定一个软件开发组织是否达到了某个级别呢？ SEI同时还研究了一个评估调查表，表中列出了一系列问题，被调查机构填写调查表，根据结果分析确定开发组织的软件过程能力成熟度。,32,2.3几个典型的软件过程模型,主要过程、支持过程和组织过程包含了许多活动，每个活动还有任务，太复杂了！ 这么多过程应该何时用？如何使用？ 为了便于使用，软件工程的前辈提供了一些常用的软件过程模型,33,1、瀑布模型,由W.Royce于1970年首先提出的。 瀑布模型规定了软件生命周期的各

11、项活动：问题定义、可行性研究、需求分析、软件设计、编码、测试、运行和维护。 各项活动自顶向下、相互衔接如同瀑布一样。一个活动结束，进入到下一个活动后，很难再回到前一个活动中去，也就是工作不可逆转。,34,瀑布模型的优缺点：,为项目提供了按阶段划分的检查点；当前一活动完成后，只需要去关注后续活动。 缺点： 由于模型是线性的，用户只有等到整个过程的末期才能见到开发成果，增加了风险； 阶段划分完全固定，阶段之间产生大量的文档，增加了工作量； 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。,35,2、快速原型化模型,基本思想： 在需求分析时，以较小代价快速建立能够反映用户主要需求

12、的原型系统。 用户在原型系统上进行基本操作，提出改进意见。 分析人员根据用户的意见完善原型，再由用户评价，提出建议，如此往复，直到开发的原型系统满足用户的需求为止。,36,快速原型化模型的优缺点,通过原型快速对需求达成一致；克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。 缺点： 选用的技术和工具不一定符合主流的发展； 快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。抛弃原型可避免此缺点,37,3、增量模型,从一组给定的需求开始，通过构造一系列可执行的软件构件来实施开发活动，以增量方式逐步完善待开发的软件。 当一个新的构件被编码和测试后，并入到软件系统结构中，然后将该结构

13、作为一个整体进行测试。这个过程不断循环往复直到软件系统达到要求的功能为止。,38,增量模型的优缺点：,人员分配灵活，刚开始不用投入大量人力资源，当核心产品受欢迎时，可增加人力实现下一个增量；它提供了一种先推出核心产品的途径；具有一定的市场运作的灵活性。 至始至终开发者和客户必须在一起，直到完全版本出来。,39,4、迭代模型,由于多种因素的影响，人们很难一下子对所要认知的事物有一个全面的了解。 初期客户对想要什么可能并没有明确的想法 软件开发者在短时间内很难弄清所有问题 开发者和客户一起探索需求，逐步确认和实现这些需求，通过不断的检查和反馈，使得那些不适合的内容在早期被暴露出来，迭代的核心：检查

14、和反馈,40,1、迭代所关注的第一个问题是变化。 无论是需求、设计还是编码，不可能一次性就把它们做到完美，只能通过不断的修正，让它们趋近于完美。 “冻结需求”的问题； 迭代思想适应变化。,41,2、迭代的周期： 一个迭代周期意味着对一些特定功能的探索。 一个迭代周期应该有多长呢？-不确定！ -应该视目标和可用的资源而定。 -周期过长会延缓反馈的时间，许多问题堆积起来 -迭代周期过短，会让人身心疲劳，难有大的成效。 -周期应该在2-6周之间,42,3、每次迭代的目标必须明确。 “如何检查该目标是否已经达到”，这就是所谓的“里程碑”。,43,4、及时获得反馈。 例子-衣服穿反了： 一是得到反馈是重

15、要的：软件中各种功能和模块的相互依赖性，问题可能被放大数倍，越到后来，问题可能就越大； 每次迭代之后，应该总结存在问题，如组织结构不合理，角色分配不明确之类。这些问题记录下来，在下次迭代中进行改善，如果相同的问题连续出现在几次迭代中，可能就说明项目管理出了问题。 二是要想得到正确的、有价值的反馈，需要其他人的配合。团队内部的协作、开发者与客户的合作。,44,区别：,在实际应用中迭代和增量模型往往相伴使用 开发A、B、C、D四个大的业务功能，每个功能都需要开发两周的时间： 对于增量模型而言将四个功能分为两次完成，第一次完成A、B功能，第二次完成C、D功能。 对于迭代模型，第一次完成A、B、C、D

16、四个基本业务功能但不含复杂的业务逻辑，而第二次迭代再逐渐细化补充相关的业务逻辑。 两周过后，采用增量模型开发，A、B全部开发完成而C、D还一点都没有动；而采用迭代模型开发的时候A、B、C、D四个的基础功能都已经完成。但并不完善，还需要再次迭代来完成。,45,增量和迭代模型的区别,增量模型是逐渐增加新的组件，每个模型是完善的,迭代模型是逐渐完善各个组件，每个模块是不完善的，逐步完善,46,5、螺旋模型：,基本思想：通过建立原型、划分开发阶段来降低风险，一旦在开发过程中风险过大就停止继续开发。 螺旋模型一般被划分为26个框架活动，沿着顺时针布局，如图所示。,47,48,螺旋模型解释：,沿螺旋线自内

17、向外每旋转一圈便开发出更为完善的一个新的软件版本。 左上象限:确定初步的目标、制定方案和限制条件。右上象限:风险分析。右下象限:开发原型，理解需求，左下象限:对原型进行评价，修正需求。根据用户提出的建议进入螺旋的第二层，又与用户交谈，再次执行计划和实施方案，然后再一次分析实施的风险，如果风险过大，可以就此终止，否则再次进入实施阶段，用户评价这一轮的实施结果，并提出修改建议。然后进入第三层螺旋，如此下去，逐步延伸，最终用户获得完整的系统。,49,螺旋模型的优缺点：,对于大型系统及软件的开发，这种模型是一个很好的方法。开发者和客户能够较好地对待和理解每一个演化级别上的风险。 需要相当的风险分析评估

18、专门技术，比较复杂。,50,注意：,软件机构并不一定要严格遵循某个软件过程； 提倡的是软件过程不断改进。即根据开发机构或项目的特点，不断改进软件过程，使得软件开发的效率更高、成本更低、质量更好、工作更加有序。,51,2.3 RUP软件开发过程,RUP（Rational Unified Process，统一软件开发过程）是一个二维的软件开发过程模型： 一维反映过程展开的生命周期特征，主要包括周期、阶段、迭代和里程碑； 另一维是展开的逻辑活动，主要包括活动、产品、工作者和工作流,52,RUP过程模型,53,六个关键活动,1）迭代开发 迭代开发通过确立一个个小目标，经常性的提交可执行版本使最终用户持

19、续介入和不断反馈，有效地控制风险。 RUP的生命周期分为初始、细化、构造和交付四个阶段，每个阶段都包含了需求、设计、编码和测试等相关活动，只是活动主体不同而已。每次迭代里面仍然需要遵循需求设计编码的小瀑布过程，只是过程可以是些轻量化过程。与瀑布式开发比较，迭代开发更能规避风险，更好的获取用户需求。,54,2）管理需求 需求是动态变化的，对需求的管理应贯穿于软件生命周期的所有环节。需求管理包括三个活动：获取需求，并将它们写成文档估计需求变化产生的影响跟踪需求变化，记录每次对需求变化所作的决策。有效的需求管理可以更好地控制复杂的软件项目，提高软件质量和客户的满意度，降低项目的成本和延迟的风险，加强

20、项目成员之间的交流。,55,3）使用构件的体系框架 一个应用系统结构稳定、可扩展性强、可维护性好等诸多特性都是通过稳定的系统架构来实现的。RUP支持基于构件的软件体系结构，基于构件的构架由于其柔性的结构、对复用的支持被认为是最佳的实践。,56,4）可视化的建模 建立一组可视的系统模型，每一个模型强调不同视点。这些模型可以使开发人员更好的理解系统，在团队成员之间建立良好的沟通。UML可视化建模语言提供了5个视图，10种图，能够对任何复杂的系统建立模型。,57,5）持续的质量检验 软件工程中的缺陷越早被发现和解决其成本越低，因此需要在每个迭代周期内进行功能和性能测试。在RUP中软件质量评估不在是事

21、后进行，而是嵌入在软件过程的所有活动中，目的是及早发现软件中的缺陷。,58,6）管理变更 一个软件项目从始到终，可能的变更包括：需求变更、资源变化、技术更新、平台变换等等。在多人参加、位置分散的开发环境下，如何控制变更是项目成败的关键因素。对于变更要管理的内容包括：谁提出了变更？什么时间提出？变更的内容是什么？变更的影响是什么？变更的结果如何？,59,2.4 敏捷开发,“敏捷”一词意味着快速、简单、灵活。敏捷开发过程重点强调以人为本，注重编程中人的自我特长发挥。 强调软件开发的主体是程序，文档是为软件开发服务的，不是开发的主体。 敏捷开发特别重视客户参与开发，因为开发者不是客户业务的“专家”，

22、所以一定要客户来阐述实际的需求细节。 编制周密的计划是为了最终软件的质量，但是为了要适应客户需求的不断变化，计划和设计要不断调整。,60,总结敏捷开发与瀑布模式的不同，主要是下面几个“敏捷”的关注点： 迭代：软件的功能是客户的需求，界面的操作是客户的“感觉”，迭代缩短了需求到“感觉”的周期。 客户参与：以人为本，客户是软件的使用者和业务专家，没有客户的参与，开发者很难理解客户的真实需求。 小版本：快速展现功能，合理地分割。,61,1）任务板把要做的任务，正在做的任务和已经完成的任务，贴在白板上，不同的颜色表示不同的重要程度。可以画一些泳道来表明任务应该是谁来完成。,62,2）需求特性板需求特性

23、是软件大的功能需求，通常按照月份来进行归类。敏捷开发需要把软件设计分成三个部分：特性用例任务，特性是对最终用户有意义的一个功能，用例是由特性分解而来的一个可以用来做功能测试的小情节，任务是由用例分解而来，它是开发人员需要完成的一个最小的工作单元。,63,3）敏捷过程中，时间分为：发布迭代每日 发布的周期通常为1至6个月 迭代的周期通常是1到4周 每天为完成任务进行编程。 把任务和时间对应起来就是在每个发布周期过程中要完成的“特性”，在每个迭代周期中要实现的“用例”，每天要完成的“任务”。更形象一点，准备三块黑板： 特性黑板：每一列标识一个发布需要完成的特性 用例黑板：每一列标识一个迭代周期需要完成测试的用例 任务黑板：每一天要做的任务。,64,2.5极限编程,XP（ExtremeProgramming，极限编程），一提起“极限”人们马上就想到马拉松长跑，喜马拉雅山的登山者，总之是强调把事情做到极限、做到最好。 支持敏捷开发过程的极限编程强调交流、简单、反馈和勇气。,