软件工程：理论、技术及实践 课件 第3章 软件过程

第3章软件过程软件生命周期模型1统一过程2敏捷开发3开源软件4软件过程的改进5软件过程软件过程是生产软件的方式，不同的软件组织有不同的软件生产过程。例如：初创公司的资本和人力条件有限，因此为开发出能迅速响应市场需求的软件产品，会更关注完成产品的核心功能并尽早发布，新功能的加入以及产品质量的提高往往放在软件交付以后。长期开发行业应用软件的公司对同类产品需求的把握更精准，对设计和实现软件所需要花费的工作量和时间的估算更准确，从而能更“有秩序”地进行相关软件生产，提交给用户稳定、可靠的软件产品。

软件生命周期模型：对构建软件所应遵循的步骤的理论性描述。

软件生命周期模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。

瀑布模型快速原型模型

增量模型 螺旋模型

喷泉模型

可以用过程流来描述组织框架活动、动作和任务的次序，分为线性、迭代、演化和并行。软件过程瀑布模型（waterfallmodel）是在1970年由WinstonRoyce提出的，其过程流是线性的。瀑布模型的关键是每个阶段要完成指定的文档并且该阶段的产品被软件质量保证小组认可之后，才能进入下一个阶段。3.1软件生命周期模型3.1.1瀑布模型图3-1瀑布模型软件生命周期模型3.1瀑布模型被称为经典的软件生命周期模型。在有明确需求并且需求保持稳定的情况下，它是一个非常有效的过程模型。瀑布模型不适应软件需求不明确或者在开发过程中需求经常变化的情况。软件生命周期模型3.1.1瀑布模型3.1快速原型模型通过使用原型来辅助软件开发。在需求分析阶段要得到准确、合理的需求说明可能比较困难，用户可能并不清楚自己需要的是什么样的系统。快速原型模型适合预先不能确切定义需求的软件系统的开发。

软件生命周期模型3.1.2快速原型模型3.1图3-2快速原型模型

软件产品的开发基本上是线性顺序进行的。

软件生命周期模型3.1快速原型模型最大的特点在于“快速”。对于采用何种形式、何种策略运用快速原型主要取决于软件项目的特点、团队成员素质、可供支持的原型开发工具和技术等，需要根据实际情况来做出决定。软件生命周期模型3.1.2快速原型模型3.1如果软件有明确需求，整个开发过程不要求按照线性过程流执行，同时要求团队迅速为用户提供一套功能有限的软件产品，并允许在后续版本中再进行细化和扩展，在这种情况下，可采用增量模型比较适用。

软件生命周期模型3.1.3增量模型3.1图3-3增量模型

软件生命周期模型3.1增量模型的最大特点就是将待开发的软件系统模块化和组件化。增量式开发有利于从总体上降低软件项目的技术风险。但增量模型对软件设计有更高的技术要求：软件体系结构具有良好的开放性与稳定性，能够顺利地实现构件集成；同时增量构件应具有很强的功能独立性，能够方便地与系统集成。软件生命周期模型3.1.3增量模型3.1为了让软件开发能更适应风险的控制，Barry

Boehm在1988年提出软件系统开发的螺旋模型，将瀑布模型和快速原型模型结合起来，强调风险分析。螺旋模型以快速原型法为基础，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。它的基本做法是在每一个开发阶段前引入风险识别、风险分析和风险控制。软件生命周期模型3.1.4螺旋模型3.1图3-4螺旋模型软件生命周期模型3.1B.H.Sollers和J.M.Edwards在1990年提出的喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。软件生命周期模型3.1.5喷泉模型3.1图3-5喷泉模型1994年10月，JamesRumbaugh和GradyBooch开始合作致力于建模语言工作，于1995年10月发布了统一方法UM0.8（UnitiedMethod0.8）。1995年，经过Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分别发布了UML0.9和UML0.91，并将UM重新命名为统一建模语言（UnifiedModelingLanguage，UML）。UML是现今较为成熟的软件建模技术和语言。3.2.1RUP的产生3.2统一过程在创建UML开始阶段，UML的三位创始人就认识到软件开发除了需要建模技术和语言之外，还需要一个更高层次、能够指导软件开发人员进行开发活动的开发过程方法学。1998年，统一过程（RationalUnifiedProcess，RUP）正式发布，并且将UML作为其建模语言。RUP并不是具体的一系列步骤，而应被视为一种自适应的方法学，可以根据实际开发的软件产品进行修改。3.2.1RUP的产生3.2统一过程图3-6RUP发展过程

3.2.1RUP的产生统一过程3.2图3-7RUP过程模型

RUP软件过程模型是一个二维的软件开发模型，也是一种用例驱动、以体系结构为核心、迭代递增的软件过程框架。3.2.2RUP的过程模型统一过程3.2RUP包含了软件开发积累下来的六大经验：1.迭代和递增式开发2.管理需求3.基于组件的体系结构4.可视化建模5.验证软件质量6.控制软件变更

3.2.3RUP的特点统一过程3.22001年，17位在当时被称为“轻量级方法学家”的软件开发者、软件工程作家以及软件咨询师（敏捷联盟）共同签署了“敏捷软件开发宣言”。3.3.1敏捷原则3.3敏捷开发敏捷软件开发宣言个体和交互胜过过程和工具可以工作的软件

胜过

面面俱到的文档

客户合作

胜过

合同谈判

响应变化

胜过

遵循计划“我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认识到：虽然右项也具有价值，但我们认为左项具有更大的价值。”敏捷开发3.3敏捷联盟制定了12项原则，将敏捷理念落实到具体可操作的层面。敏捷软件开发项目以12项原则为基石，但并不是每一个敏捷模型都同等使用这12项原则，一些模型可以选择忽略或淡化其中的一项或多项原则的重要性。敏捷开发3.33.3.1敏捷原则（1）最优先要做的是通过尽早、持续地交付有价值的软件来使客户满意。（2）即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。（3）经常交付可运行软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。（4）在整个项目开发期间，业务人员和开发人员必须每天都在一起工作。（5）激发个体的斗志，以他们为核心搭建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。（6）不论团队内外，传递信息效果最好和效率最高的方式是面对面的交谈。敏捷开发3.3（7）可工作的软件是进度的首要度量标准。（8）敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。（9）不断地关注优秀的技能和好的设计会增强敏捷能力。（10）要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。（11）最好的架构、需求和设计来自于自组织团队。（12）每隔一定时间，团队要反思如何才能更有效地工作，并相应调整自己的行为。敏捷开发3.3极限编程（XP）Scrum精益开发（Lean）OpenUP3.3.2敏捷过程应用最广泛的敏捷开发方法框架有：敏捷开发3.3极限编程（ExtremeProgramming，XP）是目前敏捷软件开发使用最为广泛的方法之一，其主要目标在于降低因需求变更而带来的成本。极限编程的创始人KentBeck为XP的实施确定了五个基础要素：沟通、简明、反馈、鼓励和尊重。3.3.3极限编程敏捷开发3.3图3-8

XP过程

3.3.3极限编程敏捷开发3.3Scrum最早由JeffSutherland在1993年提出，KenSchwaber在1995年OOPSLA会议上形式化了Scrum开发过程，并向业界公布。Scrum已经是业界常用的敏捷开发方法之一。使用Scrum的产品生命周期一般包含三个阶段：●产品定义（计划）：进行迭代所需要的项目准备、项目计划和技术分析。●迭代开发（执行）：在固定时间的迭代中实现需求（产品待办列表中的条目）。●结束：准备最终的发布，结束项目。3.3.4Scrum敏捷开发3.3图3-9Scrum过程敏捷开发3.3每个过程模式定义了一系列开发活动：●待办列表（Backlog）：能为用户提供商业价值的项目需求或者特征的优先级列表。●冲刺（sprint）：是由一系列必须在规定时间完成的工作单元组成，这些工作单元是为了实现待定需求而必需的。在冲刺过程中，不允许进行任何变更，以确保短期内的稳定性●Scrum例会：团队每天召开短会，帮助团队尽早发现问题。●演示：向客户交付软件增量，由客户对其进行评价。3.3.4Scrum敏捷开发3.31.产品负责人2.ScrumMaster3.Scrum团队1.产品代办列表2.发布燃尽图3.Sprint代办列表4.Sprint燃尽图1.Sprint2.发布计划会议3.Sprint计划会议4.每日例会5.Sprint评审会6.Sprint回顾会议Scrum敏捷过程由三个角色、四个工件、六个时间箱组成。三个角色四个工件六个时间箱敏捷开发3.3图3-10

Scrum中的燃尽图敏捷开发3.31998年，BrucePerens和EricRaymond创立了开放源代码促进会（OpenSourceInitiative），发起了“开放源代码”运动。开源已经成为软件领域技术、产品创新的一种重要模式，也是驱动信息产业变革、强化信息产业基础的关键要素。在云计算、大数据等新兴领域，基于开源模式的技术创新对产业发展的影响力日益提升。移动网络、云计算、大数据等技术的不断创新，带动了OpenStack、Hadoop等开源软件的迅速发展。3.4.1开源软件的发展3.4开源软件针对开源软件开发的特点，Raymond提出两种开源软件开发模型的概念。一种是在每个软件版本之中源代码均可以获得，但是能够开发不同版本代码的人员仅限于项目开发组内部。另一种是指通过Internet来组织代码开发，它允许有很多底层的变化，代码经常可以得到修正，对于来自外部的代码也来者不拒。大部分的开源开发属于第二种模型。开发者和软件的使用者构成了开源社区。形成开源社区的两个基本特征是：①社区成员有一个共同目标，即所要开发的软件；②基于这个共同目标，社区成员遵循一些标准和原则执行各自的开发任务。3.4.2开源软件的开发过程开源软件3.4开源软件过程与传统不开源软件过程比较有以下不同：需求的确定性设计意图更容易取得团队认可。分散开发、配置管理严格。积极查找与改进缺陷的态度。代码实现与测试交替进行。3.4.2开源软件的开发过程开源软件3.4表3-1软件过程特性3.5.1软件过程特性3.5软件过程的改进能力成熟度模型（CMM）是美国卡内基·梅隆大学软件工程研究所（SEI）在美国国防部资助下建立的，是一组用于改进软件过程的相关策略。该模型最初是为了提供一种评价软件承接方能力的方法，为大型软件项目的招投标活动提供一种全面而客观的评审依据，后来同时被软件组织用于改进其软件过程。3.5.2能力成熟度模型软件过程的改进3.5表3-2CMM的五个等级软件过程的改进3.5图3-11IDEAL过程改进模型3.5.3IDEAL模型美国卡内基·梅隆大学软件工程研究所提出了IDEAL过程改进模型。软件过程的改进3.53.5.4个人软件过程美国卡内基·梅隆大学软件工程研究所的WattsS.Humphrey主持开发了个人软件