1、Software Engineering 2.1软件生命周期模型概论软件生命周期模型概论2.2 软件过程模型软件过程模型 2.2.2原型模型原型模型2.2.3增量模型增量模型2.2.4迭代模型迭代模型2.2.5螺旋模型螺旋模型第第2 2章章 软件生命周期与开发模型软件生命周期与开发模型 2.2.1瀑布模型瀑布模型2.2.6喷泉模型喷泉模型2.2.7 XP模型模型本章小结本章小结2.2.8其它模型其它模型2.3 各种模型之间的关系各种模型之间的关系研究软件开发的本质，消除研究软件开发的本质，消除 错误的错误的认识、概念和做法；认识、概念和做法；研究先进的软件开发技术和方法，研究先进的软件开发技术
2、和方法，推广推广 使用成功的开发技术和方法；使用成功的开发技术和方法；研制使用研制使用 软件工具和软件工程支持环软件工具和软件工程支持环境；境；加强软件加强软件 管理管理。l“软件软件”是计算机系统中与硬件相互依存的是计算机系统中与硬件相互依存的另一部分。另一部分。它包括程序、数据及其相关文它包括程序、数据及其相关文档的完整集合档的完整集合.l软件工程软件工程：软件工程指规范地应用各：软件工程指规范地应用各种工程的科学的和数学的原理与方法种工程的科学的和数学的原理与方法以经济地生产高质量的软件。以经济地生产高质量的软件。l软件工程软件工程层次化技术层次化技术质量焦点质量焦点过程过程方法方法软件
3、工程三要素：方法、工具、过程软件工程三要素：方法、工具、过程工具工具l软件生命周期包含：软件定义、软件开发、软件生命周期包含：软件定义、软件开发、软件运行维护三个时期。软件运行维护三个时期。l并可以细分为可行性研究、项目计划、需并可以细分为可行性研究、项目计划、需求分析、概要设计、详细设计、编码实现求分析、概要设计、详细设计、编码实现与单元测试、系统集成测试、系统确认验与单元测试、系统集成测试、系统确认验证、系统运行与维护等证、系统运行与维护等 几个阶段。几个阶段。l根据软件的规模、种类、复杂的程度、软根据软件的规模、种类、复杂的程度、软件开发组织的经验方法等，各阶段可合并、件开发组织的经验方
4、法等，各阶段可合并、分解。分解。2023-8-3l1.任务立项与可行性分析 软件项目开始于立项，必须确定待开发软件系统的总目标，给出它的功能、性能、约束、接口以及可靠性等方面的要求；软件立项工作完成之后，需要对软件项目进行可行性分析，针对准备进行开发的软件项目进行风险性评估。技术可行性、经济可行性和操作可行性2023-8-3 2.软件需求分析 软件定义期需要达到的目标，要求以用户需求为基本依据，从功能、性能、数据、操作等多个方面，对软件系统给出完整、准确、具体的描述，用于确定软件规格。需求分析是软件定义到软件开发的最关键步骤。3.制定项目计划 针对项目的开展，从人员、组织、进度、资金、设备等多
5、个方面合理规划。2023-8-3l1.概要设计 针对软件系统的结构设计，用于从总体上对软件的构造、接口、全局数据结构和数据环境等给出设计说明，形成“概要设计说明书”。l2.详细设计 以概要设计为依据，用于确定软件结构中每个模块的内部细节，为编写程序提供最直接的依据。2023-8-33.编码和单元测试 在基于软件工程的软件开发过程中，编码往往只是是一项语言转译工作，即把详细设计中的算法描述语言转译成某种适当的高级或者汇编语言。单元测试 用于检验每个基本模块在功能、算法与数据结构上是否符合设计要求。4.软件集成与测试 根据概要设计中的软件结构，把经过测试的模块，按照某种选定的集成策略将系统组装起来
6、。在组装过程中，进行集成测试。2023-8-3l5.软件发布与实施l 在完成对系统的集成与测试之后，接着就要对系统进行验收、发布与实施。l软件的维护过程，也就是修正软件错误，完善软件功能，由此使软件不断进化升级的过程，以使系统更加持久地满足用户的需要。主要涉及三方面的任务：改正性维护、适应性维护和完善性维护。2023-8-3l软件过程是软件过程是“为了获得软件所需要完成的为了获得软件所需要完成的一系列任务的工作步骤一系列任务的工作步骤”。l软件过程定义了运用方法的顺序、各阶段软件过程定义了运用方法的顺序、各阶段应交付的文档资料、为保证软件质量所要应交付的文档资料、为保证软件质量所要采取的管理措
7、施，以及标志软件开发各个采取的管理措施，以及标志软件开发各个阶段任务完成的结果形式。阶段任务完成的结果形式。l通常用使用生命周期模型来简洁地描述软通常用使用生命周期模型来简洁地描述软件过程，也称为过程模型。件过程，也称为过程模型。软件开发模型是软件开发全部过程、活动和软件开发模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和过程，明确规定要完成的主要活动、任务和开发策略。开发策略。软件开发模型也常称为：软件开发模型也常称为：软件过程模型软件过程模型 软件生存周期模型软件生存周期模型 软件工程范型软件工
8、程范型q软件开发模型（又称为软件生存周期模型）软件开发模型（又称为软件生存周期模型）软件项目开发和维护的总体过程思路的框架软件项目开发和维护的总体过程思路的框架。q它指出了软件开发过程各阶段之间的关系和顺它指出了软件开发过程各阶段之间的关系和顺序，是软件开发过程的概括。它为软件开发过序，是软件开发过程的概括。它为软件开发过程提供原则和方法，并为软件工程管理提供里程提供原则和方法，并为软件工程管理提供里程碑和进度表。因此，软件开发模型也是软件程碑和进度表。因此，软件开发模型也是软件工程的重要内容。工程的重要内容。2.2 软件开发模型软件开发模型q软件开发模型的几种类型：软件开发模型的几种类型：以
9、软件需求完全确定为基础的瀑布模型；以软件需求完全确定为基础的瀑布模型；在开发初期仅给出基本需求的渐进式模型，如原型在开发初期仅给出基本需求的渐进式模型，如原型模型、螺旋模型、喷泉模型等；模型、螺旋模型、喷泉模型等；以形式化开发方法为基础的变换模型、基于四代技以形式化开发方法为基础的变换模型、基于四代技术的模型；术的模型；基于知识的智能模型等等。基于知识的智能模型等等。在实际开发时，应根据项目的特点和现有的条件选在实际开发时，应根据项目的特点和现有的条件选取合适的模型，也可以把几种模型组合起来使用以取合适的模型，也可以把几种模型组合起来使用以便充分利用各模型的优点。便充分利用各模型的优点。l典型
10、的软件过程模型有：典型的软件过程模型有：瀑布模型（瀑布模型（waterfall model）原型模型（原型模型（prototyping model)增量模型（增量模型（incremental model）演化模型（演化模型（evolutionary model）螺旋模型（螺旋模型（spiral model）喷泉模型（喷泉模型（water fountain model）基于构件的开发模型（基于构件的开发模型（component-based development model）形式方法模型（形式方法模型（formal methods model）智能模型智能模型(Intelligent Model
11、)2.2.1 瀑布模型瀑布模型 瀑布模型（瀑布模型（waterfall model）是由）是由W.Royce于于1970年提出来的。又称为软件生存周期模年提出来的。又称为软件生存周期模型。型。q瀑布模型严格按照软件生存周期各个阶段来瀑布模型严格按照软件生存周期各个阶段来进行开发，上一阶段的输出即是下一阶段的进行开发，上一阶段的输出即是下一阶段的输入，并强调每一阶段的严格性。它规定了输入，并强调每一阶段的严格性。它规定了各阶段的任务和应提交的成果及文档，每一各阶段的任务和应提交的成果及文档，每一阶段的任务完成后，都必须对其阶段性产品阶段的任务完成后，都必须对其阶段性产品（主要是文档）进行评审，通
12、过后才能开始（主要是文档）进行评审，通过后才能开始下一阶段的工作。因此，它是一种以文档作下一阶段的工作。因此，它是一种以文档作为驱动的模型。为驱动的模型。(维护报告维护报告)开发开发时期时期运行时期运行时期计划计划时期时期(可行性分析报告可行性分析报告)(项目开发计划书项目开发计划书)(集成与验集成与验收报告收报告)(源程序清单源程序清单)(软件设计说明书软件设计说明书)(需求规格说明书需求规格说明书)l 传统的瀑布模型过于理想化，事传统的瀑布模型过于理想化，事实上，人在工作过程中不可能不实上，人在工作过程中不可能不犯错误，评审也并不能保证发现犯错误，评审也并不能保证发现所有错误，潜伏的错误将
13、在后续所有错误，潜伏的错误将在后续阶段被陆续发现。在设计阶段可阶段被陆续发现。在设计阶段可能发现规格说明文档中的错误，能发现规格说明文档中的错误，而设计上的缺陷或错误可能在实而设计上的缺陷或错误可能在实现过程中显现出来，在综合测试现过程中显现出来，在综合测试阶段将发现需求分析、设计或编阶段将发现需求分析、设计或编码阶段的许多错误。发现错误就码阶段的许多错误。发现错误就必须及时改正，因此，实际的瀑必须及时改正，因此，实际的瀑布模型是带布模型是带“反馈环反馈环”的。（图的。（图中实线箭头表示开发过程，虚线中实线箭头表示开发过程，虚线箭头表示维护过程）。箭头表示维护过程）。1)1)把生存期划分成明确
14、的、把生存期划分成明确的、严格的顺序阶段；严格的顺序阶段；2)2)只有在前阶段的阶段性只有在前阶段的阶段性产品完成后，才能开始产品完成后，才能开始下一阶段的工作；下一阶段的工作；3)3)每一阶段都要配合生成每一阶段都要配合生成相应的具体文档；相应的具体文档；4)4)每个阶段的结束都要经每个阶段的结束都要经过严格的复审和确认。过严格的复审和确认。l瀑布模型要点瀑布模型要点把生存期划分成明确的、严格的顺序阶段；把生存期划分成明确的、严格的顺序阶段；只有在前阶段的阶段性产品完成后，才能只有在前阶段的阶段性产品完成后，才能开始下一阶段的工作；开始下一阶段的工作；每一阶段都要配合生成相应的具体文档，它每
15、一阶段都要配合生成相应的具体文档，它们类似于其它工程中的图纸资料，是下一阶们类似于其它工程中的图纸资料，是下一阶段工作的依据，极为重要；段工作的依据，极为重要；每个阶段的结束都要经过一个每个阶段的结束都要经过一个h定性或定定性或定量的复审和确认。量的复审和确认。q瀑布模型优点瀑布模型优点q提供了软件开发的基本框架，有利于大型软件开发提供了软件开发的基本框架，有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，因此，在软件工程中占有重要工具的研究与使用，因此，在软件工程中占有重要的地位。的地位。q瀑布模型是软件工程中应用最广
16、泛的过程模型。瀑布模型是软件工程中应用最广泛的过程模型。q严格规定了每一阶段必须提交的文档。严格规定了每一阶段必须提交的文档。q要求每一阶段交付之产品都必须经过质量保证小组要求每一阶段交付之产品都必须经过质量保证小组的仔细审查。的仔细审查。l致命缺点致命缺点是工作流程只能一个个台阶地往下流是工作流程只能一个个台阶地往下流动，不可能倒着向上流动。动，不可能倒着向上流动。l只有做出精确的需求分析，才能取得预期的结只有做出精确的需求分析，才能取得预期的结果。由于各种客观、主观的原因，需求分析往果。由于各种客观、主观的原因，需求分析往往不很精确，常常给日后的开发带来隐患。往不很精确，常常给日后的开发带
17、来隐患。l项目开始阶段用户很难精确的提出产品需求，项目开始阶段用户很难精确的提出产品需求，由于技术进步，用户对系统深入的理解，修改由于技术进步，用户对系统深入的理解，修改需求十分普遍。需求十分普遍。l项目开发晚期才能得到程序的运行版本，这时项目开发晚期才能得到程序的运行版本，这时修改软件需求和开发中的错误代价很大。修改软件需求和开发中的错误代价很大。q瀑布模型缺点瀑布模型缺点瀑布模型的适用范围瀑布模型的适用范围l1.1.在软件项目开发期间需求没有变化或很少变化在软件项目开发期间需求没有变化或很少变化l2.2.开发者对应用领域很熟悉（例如，开发任务是开发者对应用领域很熟悉（例如，开发任务是扩充一
18、个已存在的系统）扩充一个已存在的系统）l3.3.低风险项目（例如，开发者对目标和开发环境低风险项目（例如，开发者对目标和开发环境非常熟悉）非常熟悉）l4.4.用户使用软件的环境很稳定用户使用软件的环境很稳定l5.5.用户提出需求以后，很少参与开发工作用户提出需求以后，很少参与开发工作l6.6.软件系统编程要求使用面向过程的程序设计语软件系统编程要求使用面向过程的程序设计语言言2023-8-3u瀑布模型瀑布模型的变形：瀑布模型瀑布模型的变形：b 模型模型需求分析需求分析设计设计编码编码测试测试运行运行评价评价计划计划循环模型循环模型2.2.2 原型模型原型模型q原型模型（原型模型（prototy
19、ping model）的基本框）的基本框架是软件开发人员根据用户提出的软件基架是软件开发人员根据用户提出的软件基本需求快速开发一个原型本需求快速开发一个原型/“样品样品”，以便，以便向用户展示软件系统应有的部分或全部功向用户展示软件系统应有的部分或全部功能和性能，在征求用户对原型的评价意见能和性能，在征求用户对原型的评价意见后，进一步使需求精确化、完全化，并据后，进一步使需求精确化、完全化，并据此改进、完善原型，如此迭代，直到软件此改进、完善原型，如此迭代，直到软件开发人员和用户都确认软件系统的需求并开发人员和用户都确认软件系统的需求并达成一致的理解为止。达成一致的理解为止。快速分析快速分析快
20、速快速设计设计建造建造原型原型运行运行评价原型评价原型对原型修对原型修改完善改完善产品样品产品样品(需求确认需求确认)开始开始停止停止使用原型的过程使用原型的过程l原型是软件的一个早期原型是软件的一个早期可运行可运行的版本，它的版本，它反映了最终系统的部分重要特性。反映了最终系统的部分重要特性。l原型化方法的基本思想是原型化方法的基本思想是花费少量代价快花费少量代价快速速建立一个可运行的系统，使用户及早获建立一个可运行的系统，使用户及早获得学习的机会，原型化方法又称快速原型得学习的机会，原型化方法又称快速原型法（法（Rapid Prototyping）。）。l强调的是软件开发人员与用户的不断交
21、互，强调的是软件开发人员与用户的不断交互，通过原型的演进不断适应用户任务改变的通过原型的演进不断适应用户任务改变的需求。需求。1.1.快速分析快速分析 快速确定软快速确定软件系统的基本要求，确定原型件系统的基本要求，确定原型所要体现的特征所要体现的特征(界面，总体界面，总体结构，功能，性能结构，功能，性能)2.2.构造原型构造原型 在快速分析在快速分析的基础上，根据基本规格说明，的基础上，根据基本规格说明，忽略细节，只考虑主要特征，忽略细节，只考虑主要特征，快速构造一个可运行的系统。快速构造一个可运行的系统。3.3.运行和评价原型运行和评价原型 用户用户试用原型并与开发者之间频繁试用原型并与开
22、发者之间频繁交流，发现问题，目的是验证交流，发现问题，目的是验证原型的正确性。原型的正确性。4.4.修改与改进修改与改进 对原型进对原型进行修改，增删。行修改，增删。快速分析快速分析快速设计快速设计建造原型建造原型运行评价原型运行评价原型修改完善修改完善原型原型产品样品产品样品(需求确认需求确认)开开始始停停止止使用原型的过程使用原型的过程l快速原型的用途有：快速原型的用途有：1）模拟软件系统的人机界面和人机交）模拟软件系统的人机界面和人机交互方式；互方式；2）开发一个工作原型，对软件系统中）开发一个工作原型，对软件系统中重要的或容易产生误解的功能和其他需重要的或容易产生误解的功能和其他需求进
23、行验证；求进行验证；3）用于导出更多更准确的用户需求；）用于导出更多更准确的用户需求；4）对没有把握的技术、方案等进行验）对没有把握的技术、方案等进行验证。证。l原型的开发原型的开发/构造构造软件原型（软件原型（prototype）是可执行；）是可执行；强调强调“快速快速”和低成本。和低成本。因而因而l应尽量采用有效的软件工具和环境。例如应尽量采用有效的软件工具和环境。例如采用软件重用技术、釆用基于构件的软件采用软件重用技术、釆用基于构件的软件开发方法。开发方法。l或利用一个或几个类似的正在运行的软件或利用一个或几个类似的正在运行的软件向用户展示软件需求中的部分或全部功能。向用户展示软件需求中
24、的部分或全部功能。l其初始版本和中间版本在运行效率方面可其初始版本和中间版本在运行效率方面可做出让步，以便尽快提供。做出让步，以便尽快提供。用户测试用户测试运行原型运行原型建造建造/修改修改 原型原型 听取用听取用 户意见户意见？l原型模型原型模型(Rapid Prototype Model)？l原型的使用策略：原型的使用策略：废弃（废弃（throw away）/抛弃式策略抛弃式策略l主要用于探索型和实验型原型的开发。这些原型主要用于探索型和实验型原型的开发。这些原型关注于目标系统的某些特性，而不是全部特性，关注于目标系统的某些特性，而不是全部特性，开发这些原型时通常不考虑与探索或实验目的无开
25、发这些原型时通常不考虑与探索或实验目的无关的功能、质量、结构等因素，这种原型通常被关的功能、质量、结构等因素，这种原型通常被废丢，然后根据探索或实验的结果用良好的结构废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目标系统。和设计思想重新设计目标系统。追加追加(add on)策略；进化策略；进化/演化型演化型(evolutionary)l主要用于演化型原型的开发。这种原型通常是实主要用于演化型原型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，现了目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，通过对它的不断修改和扩充，逐步追加新
26、的要求，最后使其演化成最终的目标系统。最后使其演化成最终的目标系统。l抛弃式原型模型的特点抛弃式原型模型的特点抛弃式原型模型建立原型的目的是，评价目抛弃式原型模型建立原型的目的是，评价目标系统的某一个或某一些特性，以便更准确标系统的某一个或某一些特性，以便更准确地确定需求，或者更严格地验证设计方案。地确定需求，或者更严格地验证设计方案。使用完之后就把该原型系统抛弃掉，然后再使用完之后就把该原型系统抛弃掉，然后再重新构造正式的目标系统。重新构造正式的目标系统。抛弃式原型模型本质上仍属于瀑布模型，建抛弃式原型模型本质上仍属于瀑布模型，建立原型系统只不过是立原型系统只不过是“需求分析需求分析”和和“
27、有效有效性验证性验证”的一种辅助手段，需求分析阶段结的一种辅助手段，需求分析阶段结束时原型系统的生存周期也就终止。束时原型系统的生存周期也就终止。用户测试用户测试运行原型运行原型建造建造/修改修改 原型原型 听取用听取用 户意见户意见u抛弃式原型模型抛弃式原型模型l抛弃式原型模型抛弃式原型模型需求分析需求分析软件维护（运行时期）软件维护（运行时期）抛弃式原型模型抛弃式原型模型退退 役役原型开发原型开发原型评价原型评价软件设计软件设计软件实现软件实现用户反馈用户反馈l抛弃式原型模型抛弃式原型模型通常，用户试用原型系统之后会提出许多修通常，用户试用原型系统之后会提出许多修改意见，开发人员按照用户的
28、意见快速地修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用改原型系统，然后再次请用户试用。一。一旦用户认为这个原型系统确实能做他们所需旦用户认为这个原型系统确实能做他们所需要的工作，开发人员便可据此书写规格说明要的工作，开发人员便可据此书写规格说明文档，根据这份文档开发出的软件可以满足文档，根据这份文档开发出的软件可以满足用户的真实需求。用户的真实需求。当快速原型的某个部分是利用软件工具由计当快速原型的某个部分是利用软件工具由计算机自动生成的时候，可以把这部分用到最算机自动生成的时候，可以把这部分用到最终的软件产品中。终的软件产品中。l进化式原型模型：进化式原型模型：目标
29、系统是对实验性原型不断扩充、完目标系统是对实验性原型不断扩充、完善送代的结果。每次迭代都要求再分析、善送代的结果。每次迭代都要求再分析、再设计、再实现以及再测试评价。当认再设计、再实现以及再测试评价。当认为问题求解基本满意时就可以交付系统为问题求解基本满意时就可以交付系统的初始版本了。演化原型法的实施要求的初始版本了。演化原型法的实施要求用户和开发人员在一个相当长的时期中用户和开发人员在一个相当长的时期中对信息交流和系统修改持一种开放的态对信息交流和系统修改持一种开放的态度。许多面向市场的软件产品采用所谓度。许多面向市场的软件产品采用所谓版发布，就是施行演化原型法开发的版发布，就是施行演化原型
30、法开发的一种策略。一种策略。l进化式原型模型进化式原型模型建立原建立原型系统型系统修改修改原型原型符合用符合用户需要户需要的应用的应用系统系统用 户用 户试用试用反 馈反 馈意见意见l进化式原型模型存在的问题：进化式原型模型存在的问题：要求软件具有开放的结构是这种模型固有的要求软件具有开放的结构是这种模型固有的困难。困难。1、没有考虑软件的整体质量和长期的可维护、没有考虑软件的整体质量和长期的可维护性。性。2、大部分情况是不合适的操作算法被采用目、大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工具被采用的为了演示功能，不合适的开发工具被采用仅仅为了它的方便，还有不合适的操作系
31、统仅仅为了它的方便，还有不合适的操作系统被选择等等。被选择等等。3、由于达不到质量要求产品可能被抛弃，而、由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计。采用新的模型重新设计。q原型模型的适应场合原型模型的适应场合q原型模型比瀑布模型更符合人们认识事物原型模型比瀑布模型更符合人们认识事物的过程和规律，是一种较实用的开发框架。的过程和规律，是一种较实用的开发框架。q它适合于那些不能预先确切定义需求的软它适合于那些不能预先确切定义需求的软件系统的开发，更适合于那些项目组成员件系统的开发，更适合于那些项目组成员（包括分析员、设计员、程序员和用户）（包括分析员、设计员、程序员和用户）不能很好
32、交流或通信有困难的情况。不能很好交流或通信有困难的情况。q小型或中等规模的交互式系统，例如用户小型或中等规模的交互式系统，例如用户界面。界面。l增量模型也称为渐增模型。增量模型也称为渐增模型。l增量模型是一种非整体开发的模型。根据增量增量模型是一种非整体开发的模型。根据增量的方式和形式的不同，分为的方式和形式的不同，分为基于瀑布模型的渐基于瀑布模型的渐增模型增模型和和基于原型的渐增模型基于原型的渐增模型。l该模型具有较大的灵活性，适合于软件需求不该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。明确、设计方案有一定风险的软件项目。l增量模型和瀑布模型之间的本质区别是：
33、瀑布增量模型和瀑布模型之间的本质区别是：瀑布模型属于整体开发模型，它规定在开始下一个模型属于整体开发模型，它规定在开始下一个阶段的工作之前，必须完成前一阶段的所有细阶段的工作之前，必须完成前一阶段的所有细节。而增量模型属于非整体开发模型，它推迟节。而增量模型属于非整体开发模型，它推迟某些阶段或所有阶段中的细节，从而较早地产某些阶段或所有阶段中的细节，从而较早地产生工作软件。生工作软件。l增量模型（增量模型（Incremental Model）把软件描）把软件描述、设计、实现活动分解成一系列相互有述、设计、实现活动分解成一系列相互有联系的增量构件的迭代开发，是瀑布模型联系的增量构件的迭代开发，是
34、瀑布模型顺序特征和快速原型模型迭代特征相结合顺序特征和快速原型模型迭代特征相结合的一种软件构件化的模型。的一种软件构件化的模型。l增量式的开发过程，首先根据客户需要提增量式的开发过程，首先根据客户需要提供的服务的优先次序，确定一系列交付增供的服务的优先次序，确定一系列交付增量，每个增量提供系统功能的一个子集。量，每个增量提供系统功能的一个子集。随着开发过程的进展，每次迭代产生一个随着开发过程的进展，每次迭代产生一个可发布的（可执行的）软件增量构件。可发布的（可执行的）软件增量构件。2023-8-3定义定义 设计设计 框架需求框架需求 体系结构体系结构 增量增量 1 分析分析 设计设计 编码编码
35、 测试测试 交付交付（核心产品）（核心产品）增量增量 2 分析分析 设计设计 编码编码 测试测试 交付交付 增量增量n 分析分析 设计设计 编码编码 测试测试 交付交付 最终最终 软件系统软件系统 l软件被作为一系列的增量构件来设计、实现、集成软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成成的提供特定功能的代码片段构成l第一个增量往往是实现基本需求的核心产品。核心第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的产品交付用户使用后，经过评价形
36、成下一个增量的开发计划，它包括对核心产品的修改和一些新功能开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。到产生最终的完善产品。l增量模型融合了线性顺序模型的基本成分增量模型融合了线性顺序模型的基本成分（重复地应用）和原型实现的迭代特征。（重复地应用）和原型实现的迭代特征。l增量模型采用随着日程时间的进展而交错增量模型采用随着日程时间的进展而交错的线性序列。的线性序列。l每一个线性序列产生软件的一个可发布的每一个线性序列产生软件的一个可发布的“增量增量”。l第一个增量往往是核心的产品。第一
37、个增量往往是核心的产品。l客户对每一个增量的使用和评估，都做为客户对每一个增量的使用和评估，都做为下一个增量发布的新特征和功能。下一个增量发布的新特征和功能。分析分析 设计设计 编码编码测试测试 分析分析 设计设计 编码编码测试测试 分析分析 设计设计 编码编码测试测试 分析分析 设计设计 编码编码测试测试 增量增量1 1增量增量2 2增量增量3 3增量增量n n 增量增量1 1交付客户交付客户 增量增量2 2交付客户交付客户 增量增量3 3交付客户交付客户 增量增量n n交付客户交付客户日历时间日历时间.2023-8-3 在软件项目开发的实际工作中，针对瀑布模型的在软件项目开发的实际工作中，
38、针对瀑布模型的缺陷，人们提出了迭代模型（缺陷，人们提出了迭代模型（Iterative ModelIterative Model）。迭代包括产生产品发布（稳定、可执行的产品版迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有本）的全部开发活动和要使用该发布必需的所有其他外围元素。其他外围元素。l1.模型的主要阶段l（1）初始阶段l（2）精化阶段l（3）构建阶段l（4）产品化阶段2023-8-3l2.模型的核心流程模型的核心流程l（1）业务建模）业务建模l（2）获取需求）获取需求l（3）分析设计）分析设计l（4）实施）实施l（5）测试）测试l（7）配置与变更管理）
39、配置与变更管理l（8）项目管理）项目管理l（9）环境）环境2023-8-3l模型的优缺点模型的优缺点l优点优点：在开发的早期或中期，用户需求可以变化。在开发的早期或中期，用户需求可以变化。在迭代之初，不要求有一个近似的产品原型。模在迭代之初，不要求有一个近似的产品原型。模型的适用范围很广，几乎适用于所有软件项目的型的适用范围很广，几乎适用于所有软件项目的开发工作。开发工作。l缺点：迭代模型采取循环工作方式，每次循环都缺点：迭代模型采取循环工作方式，每次循环都使工作产品更靠近目标产品，这要求项目组成员使工作产品更靠近目标产品，这要求项目组成员具备很高的技术水平，掌握先进的开发工具。否具备很高的技
40、术水平，掌握先进的开发工具。否则会存在较大的技术和技能风险。则会存在较大的技术和技能风险。2023-8-3螺旋模型螺旋模型q螺旋模型（螺旋模型（spiral model）是）是B.Boehm于于1988年提出的。它综合了年提出的。它综合了瀑布模型瀑布模型和和原型原型模型模型的优点，即将两者结合，并加入了的优点，即将两者结合，并加入了风风险分析险分析机制。机制。q进化进化(演化演化)软件过程模型软件过程模型p螺旋模型的应用螺旋模型的应用1四个组成部分，七个步骤四个组成部分，七个步骤l5 余金山，软件开发过程及其模型余金山，软件开发过程及其模型2适用于大型软件的开发；能结合多种适用于大型软件的开发
41、；能结合多种软件开发方法，如面向规格说明的，面软件开发方法，如面向规格说明的，面向过程的和面向对象的。向过程的和面向对象的。螺旋模型螺旋模型 螺旋模型将瀑布模型和增量模型结合起来，并加入螺旋模型将瀑布模型和增量模型结合起来，并加入了风险分析。了风险分析。螺旋模型将开发过程螺旋模型将开发过程分为几个螺旋周期，分为几个螺旋周期，每个螺旋周期可分为每个螺旋周期可分为4 4个工作步骤：个工作步骤：1.1.确定目标、方案确定目标、方案和限制条件；和限制条件；2.2.评估方案、标识评估方案、标识风险和解决风险；风险和解决风险；3.3.开发确认产品；开发确认产品；4.4.评价开发工作，评价开发工作，提出修正
42、意见，制定提出修正意见，制定下一步计划。下一步计划。螺旋模型螺旋模型l模型的特点模型的特点：l1.将开发过程组成一个逐步细化的螺旋周期，将开发过程组成一个逐步细化的螺旋周期，每每经过一个周期，系统就得到进一步的细化完善。经过一个周期，系统就得到进一步的细化完善。l2.整个模型紧密围绕开发中的风险分析，推动软整个模型紧密围绕开发中的风险分析，推动软件产品向深层扩展和求精。件产品向深层扩展和求精。l3.强调持续的判断、确定和修改用户的任务目标，强调持续的判断、确定和修改用户的任务目标，并按成本、效益来分析软件产品对任务目标的贡并按成本、效益来分析软件产品对任务目标的贡献。献。2023-8-3模型的
43、优缺点模型的优缺点：l1.螺旋模型的优点螺旋模型的优点l（1）螺旋模型支持用户需求的动态变化）螺旋模型支持用户需求的动态变化l（2）螺旋模型对可选方案和约束条件的强调）螺旋模型对可选方案和约束条件的强调l（3）减少了过多测试或测试不足的情况所带来的）减少了过多测试或测试不足的情况所带来的风险。风险。l（4）螺旋模型中维护只是模型的一个周期）螺旋模型中维护只是模型的一个周期，软件软件维护得到了重视。维护得到了重视。2023-8-3l2.螺旋模型的缺点螺旋模型的缺点l（1）螺旋模型强调风险分析，但要求许多客户接）螺旋模型强调风险分析，但要求许多客户接受和相信这种分析并做出相应的反应是不容易的，受和
44、相信这种分析并做出相应的反应是不容易的，因此这种模型往往适应于内部的大规模软件开发。因此这种模型往往适应于内部的大规模软件开发。l（2）如果执行风险分析会大大影响项目的利润，）如果执行风险分析会大大影响项目的利润，那么进行风险分析便毫无意义，因此螺旋模型只那么进行风险分析便毫无意义，因此螺旋模型只适用于大规模软件项目。适用于大规模软件项目。l（3）过多的迭代次数会增加开发成本，延迟软件）过多的迭代次数会增加开发成本，延迟软件交付时间。交付时间。2023-8-3l由由B.H.Sollers和和J.M.Edwards于于1990年提出。年提出。l喷泉模型对软件复用和生存期中多项开发喷泉模型对软件复
45、用和生存期中多项开发活动的集成提供了支持，主要支持面向对活动的集成提供了支持，主要支持面向对象的开发方法。象的开发方法。喷泉喷泉一词本身体现了迭一词本身体现了迭代和无间隙特性。系统某个部分常常重复代和无间隙特性。系统某个部分常常重复工作多次，相关功能在每次迭代中随之加工作多次，相关功能在每次迭代中随之加入演进的系统。所谓无间隙是指在开发活入演进的系统。所谓无间隙是指在开发活动，即分析、设计和编码之间不存在明显动，即分析、设计和编码之间不存在明显的边界。的边界。喷泉模型喷泉模型 它是以面向对象的它是以面向对象的软件开发方法为基软件开发方法为基础，以用户需求为础，以用户需求为动力，以对象来驱动力，
46、以对象来驱动的模型。动的模型。图图 喷泉模型喷泉模型维维 护护测测 试试实实 现现设设 计计分分 析析演演 化化维维 护护测测 试试实实 现现设设 计计分分 析析演演 化化1软件系统可维护性较好；软件系统可维护性较好；2各阶段相互重叠；各阶段相互重叠；3整个模型是一个迭代的过程；整个模型是一个迭代的过程；4模型具有增量开发特性，即能模型具有增量开发特性，即能做到分析一点、设计一点、实做到分析一点、设计一点、实现一点，测试一点，使相关功现一点，测试一点，使相关功能随之加入到演化的系统中。能随之加入到演化的系统中。5模型是对象驱动的；模型是对象驱动的；6该模型很自然地支持软部件的该模型很自然地支持
47、软部件的重用。重用。2023-8-3 XPXP模型（模型（eXtreme Programming ModeleXtreme Programming Model）极限编程）极限编程模型，本来是敏捷企业文化现象，但是现在不少模型，本来是敏捷企业文化现象，但是现在不少人将它当做一种软件开发模型。人将它当做一种软件开发模型。l可重用构件组装模型可重用构件组装模型l变换模型变换模型/形式化方法模型形式化方法模型l基于四代技术的模型基于四代技术的模型l基于知识的智能模型基于知识的智能模型l使用重用技术的软件工程模型使用重用技术的软件工程模型可重用部件组装模型可重用部件组装模型(构件集成模型构件集成模型)/
48、基基于构件的开发模型于构件的开发模型构件构件(components)：可重用的软件成份：可重用的软件成份可复用性（可复用性（Reusability）l基于构件的开发模型基于构件的开发模型利用已有的软件构件（包括组织内部开利用已有的软件构件（包括组织内部开发的构件和现存商品化构件发的构件和现存商品化构件COTS）来）来构造应用系统。构造应用系统。l基于组件的开发技术是使用可重用的组件基于组件的开发技术是使用可重用的组件或商业组件或商业组件 建立复杂的软件系统。建立复杂的软件系统。组件选取组件选取 l优点优点具有相当多、相当突出的优点！被具有相当多、相当突出的优点！被称为是解决软件危机的称为是解决
49、软件危机的“银弹银弹”。l存在问题存在问题如何获取符合要求的软构件？如何获取符合要求的软构件？构件的组装和修改？构件的组装和修改？构件的版权、责任、构件的版权、责任、。2、变换模型、变换模型/形式化方法模型形式化方法模型变换模型（变换模型（transformational model）是基于形式化）是基于形式化规格说明语言以及程序变换技术的软件系统开发模规格说明语言以及程序变换技术的软件系统开发模型，它主要用于软件的形式化开发方法。型，它主要用于软件的形式化开发方法。在软件需求分析确定以后，便用形式化的规格说明在软件需求分析确定以后，便用形式化的规格说明语言将其描述为语言将其描述为“形式化软件
50、规格说明形式化软件规格说明”，然后对，然后对其进行一系列自动或半自动的变换，最终得到软件其进行一系列自动或半自动的变换，最终得到软件系统的目标程序。系统的目标程序。图图 变换模型变换模型形式化软件规形式化软件规格说明格说明(M0)模型检查模型检查需求分析需求分析形式化软件设形式化软件设计说明计说明(M1)（M2）目标程序目标程序(M)变变 换换 变变 换换 变变 换换2、变换模型、变换模型/形式化方法模型形式化方法模型l形式化方法模型是采用形式化的数学方法形式化方法模型是采用形式化的数学方法将系统描述将系统描述 转换成可执行的程序。转换成可执行的程序。l适用适用特别适合于那些对安全性、可靠性和
