2-1 软件过程模型
软件过程模型(瀑布,原型,增量,螺旋)的原理及优缺点
典型的开发模型有：瀑布模型(waterfall model)、渐增模型/演化/迭代(incremental model)、原型模型(prototype model)、螺旋模型(spiral model)、喷泉模型(fountain model)、智能模型(intelligent model)、混合模型(hybrid model)1、边做边改模型（Build-and-Fix Model）遗憾的是，许多产品都是使用“边做边改”模型来开发的。
在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。
在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。
在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：1）缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；2）忽略需求环节，给软件开发带来很大的风险；3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
2、瀑布模型（Waterfall Model）1970年温斯顿·罗伊斯提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。
当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。
瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。
简述软件过程模型
简述软件过程模型
软件过程模型是指在软件开发过程中，按照一定的规范和流程组织、管理和实施软件开发活动的模式。
常见的软件过程模型包括：
1. 瀑布模型：将软件开发过程划分为需求分析、设计、编码、测试和运维等阶段，各阶段之间严格按顺序进行，每个阶段完成后才进入下一个阶段。
2. 原型模型：通过快速开发原型来帮助用户明确需求，并不断迭代改进原型，直到最终满足用户需求为止。
3. 增量模型：将整个软件开发过程分成若干个增量，每个增量都包含完整的软件功能，每个增量先进行开发、测试、部署和运行，然后再逐渐添加新的增量，不断完善和改进系统。
4. 敏捷模型：强调通过反复迭代和持续交付来快速响应用户需求，并随时根据用户反馈进行调整和优化。
5. 螺旋模型：结合了瀑布模型和原型模型的优点，通过不断的风险评估和迭代开发，逐步完善系统。
不同的软件过程模型适用于不同的开发场景和需求，选择合适的模型可以帮助开发团队更好地组织和管理开发活动，提高开发效率和质量。
第1讲 软件过程模型-xu
1.4 软件过程
软件生存期模型是跨越整个生存期的系统开发 、运作和维护所实施的全部过程、活动和任务 的结构框架 瀑布模型 原型模型 螺旋模型 喷泉模型 增量模型
1.4 软件过程
1.
瀑布模型 （传统的软件过程）
特点：
阶段间具有顺序性和依赖性
必须等前一阶段的工作完成之后，才能开始后一阶段的工作
1.1软件工程简述
7. 承认不断改进软件工程实践的必要性
遵循前6条基本原理，就能够按照当代软件工
程基本原理实现软件的工程化生产，但不能保 证赶上时代前进的步伐。
积极主动采纳新的软件技术，且不断总结经验。
1.2 软件工程
软件工程的目标
研制、开发与生产出具有良好软件质量和费
用合算的产品。（正确、可靠、可维护、可 重用；可追踪、可移植、可操作、有效性）
1.3 软件生命周期
5.详细设计/模块设计
详细设计阶段的任务就是把解法具体化，也就
是回答“应该怎样具体地实现这个系统”这个 关键问题。 详细地设计每个模块，确定实现模块功能所需 要的算法和数据结构
编写设计说明书，提交评审
1.3 软件生命周期
6.编码和单元测试
这个阶段的关键任务是写出正确的容易理解
1.3 软件生命周期
8.软件维护
维护阶段的关键任务是，通过各种必要的维护活动使系统持
久地满足用户的需要
通常有四类维护活动：
改正性维护 适应性维护 完善性维护 预防性维护
—— 生命周期模型规定了把生命周期划分成哪些阶段及各个阶段
的执行顺序，因此也称为过程模型
1.4 软件过程
经统计表明，不成功的软件项目中有一半左右是
软件工程-软件过程模型
软件工程-软件过程模型软件工程-软件过程模型1.引言在软件开发过程中，软件过程模型是一种指导开发团队进行软件项目管理、开发、测试和维护的方法。
选择合适的软件过程模型能够提高开发效率和质量。
本文将介绍几种常见的软件过程模型及其特点。
2.瀑布模型2.1 概述瀑布模型是最经典的软件过程模型，它将软件开发过程划分为需求分析、设计、编码、测试和维护等阶段，各阶段按序依次进行，并且每个阶段的输出作为下一个阶段的输入。
该模型适用于需求明确、变动较少的项目。
2.2 优点●易于理解和使用●各个阶段有明确的任务和输出●开发进度容易掌握2.3 缺点●特别注重文档，过程较为刻板●不适应需求较为灵活和易变的项目●需求变更较困难3.增量模型3.1 概述增量模型是一种迭代的软件过程模型，它将软件开发过程分解为多个增量部分，每个增量部分都是可执行的，具有独立的功能。
每个增量都经过开发、测试和维护等阶段，最终形成完整的软件系统。
3.2 优点●提高开发效率，快速交付可用的软件●适用于需求变更频繁的项目●早期发现和解决问题，降低风险3.3 缺点●需要多次集成和测试，增加了工作量和成本●每个增量都需要经过完整的开发流程，开发时间可能较长4.原型模型4.1 概述原型模型是一种以用户需求为中心的软件过程模型。
它将软件系统分为前端界面和后端逻辑实现，开发团队先为用户构建原型界面，根据用户反馈进行迭代修改，最终实现满足用户需求的系统。
4.2 优点●高度交互性，能够及时反馈用户需求●提高用户满意度，减少需求变更●可提前发现和解决问题4.3 缺点●需要与用户之间的密切合作●前期投入较大●需求不够明确时，开发团队容易走偏5.敏捷模型5.1 概述敏捷模型是一种以迭代和增量为特点的软件过程模型。
它注重团队合作、需求变更和持续交付的原则，以客户满意为最终目标。
5.2 优点●满足需求变更的灵活性●提高开发团队的工作效率和满意度●客户参与度高，减少需求风险5.3 缺点●依赖团队协作和沟通●需求变更较多时，可能影响开发进度和成本控制●关注点放在短期交付上，对长期计划较弱6.结论根据不同项目的需求和特点，选择合适的软件过程模型对项目的成功非常重要。
软件工程基础之02软件过程模型
软件工程基础之02软件过程模型软件工程基础之02 软件过程模型1\引言软件过程模型是软件开发过程中的一个重要概念，用于指导软件项目的组织和管理。
本文将介绍软件过程模型的基本概念、分类、优缺点以及常见的几种软件过程模型。
2\软件过程模型的基本概念2\1 软件过程软件过程是指在软件开发过程中，按照一定的方法论和流程执行的一系列活动。
它包括需求分析、设计、编码、测试、部署等一系列环节，以及相关的管理活动。
2\2 软件过程模型软件过程模型是对软件开发过程的一个抽象描述，它定义了软件开发过程中各个阶段的顺序、交互和活动。
软件过程模型可以帮助团队更好地理解、管理和改进软件开发过程。
3\软件过程模型的分类3\1 瀑布模型瀑布模型是最传统也是最经典的软件过程模型，它将软件开发过程划分为需求分析、设计、编码、测试和部署等几个阶段，每个阶段都有明确的输入和输出。
3\2 原型模型原型模型适用于需求不明确或变化频繁的项目。
它通过快速构建一个初步版本的软件原型，与用户进行反复的交互和验证，以快速收集需求并逐步完善软件。
3\3 增量模型增量模型将软件开发过程划分为多个迭代的增量，每个增量都是对之前版本的扩展和改进。
相比于瀑布模型，增量模型能够更早地交付可用的软件，并且逐步完善。
3\4 螺旋模型螺旋模型是一种风险驱动的软件开发过程模型，它强调风险的评估和管理。
螺旋模型将软件开发过程划分为多个循环，每个循环都包括风险评估、规划、开发和评估等活动。
4\软件过程模型的优缺点4\1 瀑布模型的优缺点瀑布模型的优点是结构清晰、易于理解和控制，适用于需求稳定的项目。
缺点是缺乏灵活性，需求变更困难，容易导致项目延期。
4\2 原型模型的优缺点原型模型的优点是快速、灵活，能够及早与用户进行交互并获取反馈。
缺点是可能会导致需求变更频繁，进而增加开发成本。
4\3 增量模型的优缺点增量模型的优点是能够快速交付可用的软件，并逐步完善。
缺点是每个增量的设计和开发都需要经过完整的软件开发流程，增加了开发成本。
软件过程模型案例
软件过程模型案例软件过程模型是指在软件开发过程中，将软件开发过程分为若干阶段和活动，并规定每一阶段和活动的输入、输出、各种文档的编制方法和文档的审核和审定的内容、具体要求、合格标准以及项目组织管理的方法和质量控制的方法等的一种软件开发操作规范。
下面将以一个实际案例来介绍一个典型的软件过程模型。
假设公司决定开发一个新的在线电影票购买系统来满足用户的购票需求，下面将以这个案例为例来介绍软件过程模型。
1.需求收集和分析阶段：在这个阶段，软件团队与项目的利益相关者进行会议，了解他们的需求和期望。
通过讨论和调查，软件团队收集到以下需求：-用户可以浏览不同影院的上映电影信息。
-用户可以查看每部电影的放映时间和价格。
-用户可以选择座位并购买电影票。
-系统需要提供在线支付功能。
-系统需要发送电子票给用户。
2.需求规格说明书编制阶段：根据收集到的需求，软件团队开始编制需求规格说明书，该文档详细描述了软件系统的功能、性能要求以及用户界面和交互设计等。
在这个阶段，软件团队还与利益相关者进行讨论，以确保需求的完整性和准确性。
3.设计阶段：在设计阶段，软件团队根据需求规格说明书开始设计系统的架构和模块。
他们使用UML（统一建模语言）创建类图、序列图和状态图等。
同时，团队还着手开发数据库设计和用户界面设计。
4.编码和单元测试阶段：在这个阶段，程序员开始根据设计文档编写源代码，并进行单元测试来验证每个模块的正确性。
他们还使用版本控制工具来管理源代码的版本。
5.综合测试和验收测试阶段：在这个阶段，软件团队进行综合测试和验收测试来验证整个系统的功能和性能。
他们通过模拟实际用户使用系统的场景来测试系统的稳定性和可靠性。
6.部署和维护阶段：在软件系统通过验收测试后，团队将其部署到生产环境中，并提供相关的文档和培训来帮助用户使用系统。
同时，团队会定期监测系统的性能并进行必要的维护和修复。
需要注意的是，上述过程是迭代和增量式的。
即使在开发和测试过程中，可能会发现一些需求的变化或改进的机会，开发团队应该做出相应的调整。
软件测试 第2章软件测试过程模型及标准
第2章软件测试过程模型及标准第一节回顾1.软件过程模型：软件开发全部过程、活动和任务的结构框架也称软件开发模型或软件生存周期模型2.典型的软件过程模型：瀑布模型，演化模型，增量模型，原型模型，螺旋模型，喷泉模型，基于构件的开发模型，形式方法模型3.瀑布模型（包含计算机系统工程）（如图所示）将软件放在计算机系统工程中，考察软件在计算机系统扮演什么角色，软件做什么，区分哪些事情由硬件完成，哪些事情软件完成，哪些事情由人完成。
4.瀑布模型（不包含计算机系统工程）（如图所示）第二节软件测试过程模型1.模型：描述软件测试全部过程、活动和任务的结构框架2.典型的软件测试模型：2.1V模型2.2W模型2.3H模型2.4TMap模型第三节V模型1.V模型描述软件开发各阶段与软件测试类别的关系2.V模型的左分支展示了软件开发的活动（和传统瀑布模型的开发步骤相一致），右分支展示了软件测试的类别特点：3.可根据V模型确定各软件测试阶段的测试要求4.可针对开发活动的不同特点为不同的测试类别设计不同的测试用例5.体现测试人员参与开发的全过程6.V模型（含计算机系统工程）（如图所示）7.V模型（不含计算机系统工程）（如图所示）8.V模型右侧的测试级别随软件开发程度的加深而对应不同级别的测试阶段a)单元测试：主要针对详细设计和编码的测试b)集成测试：主要针对概要设计的测试c)系统测试：主要针对软件系统或计算机系统的测试d)验收测试：主要由用户进行的测试缺点：V模型把测试过程作为在需求定义、需求分析、系统概要设计、系统详细设计及编码之后的一个阶段。
容易使人理解为测试是软件开发的最后阶段，测试主要针对程序进行，而需求定义、需求分析、系统概要设计、详细设计阶段隐藏的问题一直到后期的系统测试和验收测试才被发现。
第四节W模型1.V模型中增加各开发阶段应同步进行的验证和确认活动，演化成W模型2.W模型由两个V组成，一个V代表开发过程，另一个V代表测试过程优点：3.体现了尽早地、不断地进行软件测试4.体现了测试对象不仅是程序代码，还包括需求分析、设计等阶段的工作产品，测试与开发同步进行。
软件工程第二章软件过程
第二章：软件过程目标：软件工程和软件过程模型的概念；了解3个一般的软件过程模型及何时使用它们；了解软件需求工程，软件开发，测试和进化中所涉及的基本过程活动；理解为什么软件过程要有效地组织以应对软件需求和设计上的变更；了解Rational统一过程是如何集成好的软件过程实践来产生一个可适应的软件过程。
所有的软件过程都必须具有4种对软件工程来说是基本的活动。
它们是：1.软件描述：必须定义软件的功能以及软件操作上的约束。
2.软件设计和实现：必须生产符合描述的软件。
3.软件有效性验证：软件必须得到有效性验证，即确保软件是客户所想要的。
4.软件进化：软件必须进化以满足不断变化的客户需要。
2.1软件过程模型一软件过程模型一般有1.瀑布模型：该模型将基本的过程活动，描述，开发，有效性验证和进化，看成是一些界限分明的独立的过程阶段，例如，需求描述阶段，软件设计阶段，实现阶段，测试阶段，等等。
2.增量式开发：该方法使得描述活动，开发活动和有效性验证活动交织在一起。
系统的开发是建立一系列的版本（增量），每个版本添加部分功能到先前的版本中。
3.面向复用的软件工程：该方法使得描述活动，开发活动和有效性验证活动交织在一起。
系统开发过程着重于集成这些组件到新系统中，而非从头开发。
2.1.1瀑布模型一瀑布模型中的主要阶段直接映射基本的开发活动：1.需求分析和定义2.系统和软件设计3.实现和单元测试4.集成和系统测试5.运行和维护二适合采用瀑布模型的时候瀑布模型是与其他工程过程模型相一致的，在它的每个阶段都要生成文档。
这使得过程是可见的，项目经理能够根据项目计划监控项目的过程。
它的主要问题在于它将项目生硬地分解成这些清晰的阶段。
关于需求的责任和义务一定要在过程的早期阶段清晰界定，而这又意味它对用户需求变更的响应较困难。
所以只有在对需求了解的好，而且在系统开发过程中不太可能发生重大改变的时候，适合采用瀑布模型。
瀑布模型的一个重要变形是形式化系统开发。
SPP模型简介
“精简并行过程”（Simplified Parallel Process，SPP）是基于CMMI以及软件工程和项目管理知识而创作的一种“软件过程改进方法和规范”，它由众多的过程规范和文档模板组成。
SPP主要用于指导国内IT企业持续地改进其软件过程能力。
此处“精简并行”的含义是：（1）对CMMI 3级以内各过程域的内容和要求作了“精简”处理。
（2）在产品生命周期之内，项目管理过程、项目研发过程和机构支撑过程“并行”开展。
本章是SPP的综述文章，它对SPP的思想方法以及企业的软件过程改进政策作了全面介绍。
阅读本章有助于读者更好地理解和应用SPP的所有过程规范和文档模板。
建议用户（企业）根据自身情况（如发展战略、研发实力等）适当地修改SPP，然后推广使用。
2.1SPP模型SPP模型把产品生命周期划分为6个阶段，分别为：²产品概念阶段，记为PH0。
²产品定义阶段，记为PH1。
²产品开发阶段，记为PH2。
²产品测试阶段，记为PH3。
²用户验收阶段，记为PH4。
²产品维护阶段，记为PH5。
在SPP模型中，软件项目的过程有三大类：项目管理过程、项目研发过程和机构支持过程。
上述三类过程可以细分为19个主要过程域，分布在PH0到PH5的各个阶段。
项目管理过程包含6个过程域，分别为：²立项管理²结项管理²项目规划²项目监控²风险管理²需求管理项目研发过程包含8个过程域，分别为：²需求开发²技术预研²系统设计²实现与测试²系统测试²Beta测试²客户验收²技术评审机构支撑过程包含5个过程域，分别为：²配置管理²质量保证²培训管理²外包与采购管理²服务与维护SPP模型如图2-1所示。
软件工程之过程模型
软件⼯程之过程模型如同任何事物都有⼀个发⽣、发展、成熟，直⾄衰亡的全过程⼀样，软件系统或软件产品也有⼀个定义、开发、运⾏维护，直⾄被淘汰这样的全过程，我们把软件将要经历的这个全过程称为软件的⽣命周期。
为了使软件⽣命周期中的各项任务能够有序地按照规程进⾏，需要⼀定的⼯作模型对各项任务给以规程约束，这样的⼯作模型被称为软件过程模型，或软件⽣命周期模型。
它是⼀个有关项⽬任务的结构框架，规定了软件⽣命周期内各项任务的执⾏步骤与⽬标。
本章将介绍瀑布模型、原型模型、螺旋模型、喷泉模型和组件模型等过程模型。
需要注意的是，这些模型并不是有关软件开发进程的固定格式，⽽只是⼀种参考标准。
实际上，不同的软件项⽬需要不同的过程模型提供⽀持，并且还需要根据项⽬的具体情况，软件开发机构⼯作⽅式、管理模式等，对⼀些标准模型进⾏适当的调整与补充，以适应项⽬应⽤的需要。
⼀、软件⽣命周期根据我国国家标准《计算机软件开发规范》（GB 8566—8），软件⽣命周期包含：软件定义、软件开发、软件运⾏维护三个时期，并可以细分为可⾏性研究、项⽬计划、需求分析、概要设计、详细设计、编码实现与单元测试、系统集成测试、系统确认验证、系统运⾏与维护等⼏个阶段。
应该说，这是软件⽣命周期的基本构架，在实际软件项⽬中，根据所开发软件的规模、种类，软件开发机构的习惯做法，以及软件开发中所采⽤的技术⽅法等，可以对各阶段进⾏必要的合并、分解或补充。
1.软件定义期软件定义是软件项⽬的早期阶段，主要由软件系统分析⼈员和⽤户合作，针对有待开发的软件系统进⾏分析、规划和规格描述，确定软件是什么，为今后的软件开发做准备。
这个时期往往需要分阶段地进⾏以下⼏项⼯作。
（1）软件任务⽴项软件项⽬往往开始于任务⽴项，并需要以“软件任务⽴项报告”的形式针对项⽬的名称、性质、⽬标、意义和规模等作出回答，以此获得对准备着⼿开发的软件系统的最⾼层描述。
（2）项⽬可⾏性分析在软件任务⽴项报告被批准以后，接着需要进⾏项⽬可⾏性分析。
软件过程模型（软件开发模型）
软件过程模型（软件开发模型）软件过程模型也称为软件开发模型，它是软件开发全部过程、活动和任务的结构框架。
典型的软件过程模型有瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件的开发模型、形式化⽅法模型、统⼀过程（UP）模型、敏捷⽅法等。
1、瀑布模型（Waterfall Model）瀑布模型是将软件⽣存周期中各个活动规定为依线性顺序连接的若⼲阶段的模型，包括需求分析、设计、编码、测试、运⾏与维护。
它规定了由前⾄后、相互衔接的固定次序，如同瀑布流⽔逐级下落。
如下图所⽰。
瀑布模型为软件的开发和维护提供了⼀种有效的管理模式，根据这⼀模式来制订开发计划，进⾏成本预算，组织开发⼒量，以项⽬的阶段评审和⽂档控制为⼿段有效的对整个开发过程进⾏指导，因此它是以⽂档为驱动，适合于软件需求很明确的软件项⽬的模型。
优点是容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试。
缺点是客户必须完整、正确和清晰的表达他们的需要，⽽这往往⼜不可能；在后期很难评估项⽬的进度状态；对项⽬的风险控制能⼒弱。
2、增量模型（Incremental Model）增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为⼀系列增量产品，每⼀增量可以分别开发。
该模型采⽤随着⽇程时间的进展⽽交错的线性序列，每⼀个线性序列产⽣软件的⼀个可发布的“增量”，如下图所⽰。
当使⽤增量模型时，第⼀个增量往往是核⼼的产品。
客户对每个增量的使⽤和评估都作为下⼀个增量发布的新特征和功能，这个过程在每⼀个增量发布后不断重复，直到产⽣了最终的完善产品。
增量模型强调每⼀个增量均发布⼀个可操作的产品。
增量模型作为瀑布模型的⼀个变体，具有瀑布模型的所有优点。
此外还具有如下优点：第⼀个可交付版本所需要的成本和时间很少；开发由增量表⽰的⼩系统所承担的风险不⼤；由于很快发布了第⼀个版本，因此可以减少⽤户需求的变更；运⾏增量投资，即在项⽬开始时，可以仅对⼀个或两个增量投资。
软件过程模型的演化与发展
软件过程模型的演化与发展软件过程模型是一种软件开发过程的框架和方法，它通常涵盖项目计划、需求分析、设计、编码、测试等过程，并且有明确的阶段和相应的文档。
随着软件开发的不断发展，软件过程模型也发生了各种改变和演化。
本文将从历史上软件过程模型的发展、目前主流的软件过程模型以及未来软件过程模型的趋势等方面进行讨论。
历史上软件过程模型的发展软件过程模型最早可以追溯到20世纪70年代的瀑布模型。
瀑布模型是一种基于阶段划分的步骤性软件开发方法，它的特点是各个阶段之间严格顺序不可逆。
但是瀑布模型的缺陷也逐渐显露出来，比如它不能应对变化频繁的需求以及对客户需求的不敏感，无法应对灵活的软件开发环境。
为了解决瀑布模型的问题，20世纪80年代出现了许多新的软件过程模型，如快速原型法、融合模型、增量模型等。
具体而言，快速原型法用于快速制作模型以进行交互式需求分析和确认；融合模型结合不同的软件过程模型来达到平衡；增量模型则通过分阶段交付，每个阶段都可以进行前一阶段已经完成的悄然和证明，从而改进了瀑布模型。
到了90年代，软件工程领域出现了更加灵活的敏捷软件开发模型。
敏捷模型的特点是强调响应变化、需求频繁演化以及迭代反馈等。
它的发展激励了更多的软件开发模型的探索，如极限编程、Scrum等。
这些敏捷模型的出现不仅让软件开发过程更灵活，还提高了开发质量。
主流的软件过程模型目前，主流的软件过程模型主要是瀑布模型和敏捷模型。
瀑布模型是适合于需求比较稳定、开发周期较长以及需求可以明确的软件项目。
敏捷模型则更适合于需求不确定、周期短、迭代反馈频繁等软件项目。
瀑布模型通常具有以下几个阶段：需求分析、设计、编码、测试和维护。
这些阶段通常需要在开发生命周期内严格按照顺序进行。
每个阶段会产生相应的文档并进行相关的验证和测试。
瀑布模型的优点是流程可控，开发过程分明，有很好的任务计划，每个阶段可以进行流程、质量、进度和成果的控制与管理。
缺点则是无法适应需求变更大和客户需求不明确的情况，调整难度非常大。
软件工程1-2.软件过程
2.2 过程框架
下面的通用过程框架（generic process framework）可适于绝大多数软件项目： 1. 沟通 这个框架活动包含了与客户之间大量 的交流和协作，还包括需求获取及其他相 关活动。 2. 策划 为后续软件工程工作制定计划 3. 建模 包括创建模型和设计（analysis、 design）两方面工作。 4. 构建 包括编码（手工或自动生成）和测试 （发现编码中的错误） 5. 部署 软件交付到用户，用户评测并反馈。
对这个定义分解开来理解，就是： 应用计算机科学、数学及管理科学等原理，借鉴传 统工程的原则和方法，来创建软件，从而达到提高 质量、降低成本的目的。 其中，采用的方法包括： 计算机科学和数学用于构造模型、分析算法； 工程科学用于制定规范、明确风险、评估成本和 确定权衡； 管理科学用于进度、资源、质量、成本的管理。 因此，软件工程是计算机科学、工程和管理三个学科 的综合。
如，建模活动包括分析、设计两个动作。分析包括 一组任务（如需求获取、细化、协商、规格说明 和确认），最终产生需求分析模型（和/或需求 规格说明）。设计包括一组任务（如数据设计、 体系结构设计、接口设计、构件层设计），最终 产生设计模型（和/或设计规格说明）。
2.2 过程框架
任务集。任务集定义了为达到一个软件工程动 作的目标所需要完成的工作。如“需求获取” 就是发生在沟通活动中一个重要的软件工程动 作。 对小型、简单的项目，需求获取的任务集和大 型、复杂的项目就有较大差异。P20
软件工程模型与方法 02、软件生命周期模型
9
运行维护
改正性维护：运行中发现了软件中的错误 需要修正； 适应性维护：为了适应变化了的软件工作 环境，需做适当变更； 完善性维护：为了增强软件的功能需做变 更。
10
2.3 软件过程模型
模型是实际事物、实际系统的抽象。
模型的表示形式是可以多种多样的，可以是数学表达式、 物理模型或图形文字描述等等。只要能回答所需研究问题 的实际事物或系统的抽象表达式，都可称为模型。
不适用原型法
批处理系统 基于大量算法和逻辑结构的 系统 在线运行系统的补充
系统结构 联机事务处理系统、相互关 逻辑结构 用户特征 应用约束 项目管理 项目负责人愿意使用原型方 项目环境
法 需求复杂易变、性能要求高
需求明确固定
26
2.4.3 原型方法
原型方法的应用过程
初步的需求 不同的系统架构 不同的功能实现算法 明确的需求 合适的系统架构 性能较好的功能实现算法
工作流（work flow）模型：描述软件过程中各种活动的序列、输 入和输出，以及各种活动之间的相互依赖性。它强调软件过程中 活动的组织控制策略。 数据流（data flow）模型：描述将软件需求变换成软件产品的整 个过程中的活动，这些活动完成将输入工件变换成输出工件的功 能。它强调软件过程中的工件的变换关系，对工件变换的具体实 现措施没有加以限定。 角色/动作模型：描述了参与软件过程的不同角色及其各自负责 完成的动作，即根据参与角色的不同将软件过程应该完成的任务 划分成不同的职能域（function area）。
从复用的内容角度可以划分其类型为：
29
软件复用的实现机制
SPP模型简介
“精简并行过程”（Simplified Parallel Process，SPP）是基于CMMI以及软件工程和项目管理知识而创作的一种“软件过程改进方法和规范”，它由众多的过程规范和文档模板组成。
SPP主要用于指导国内IT企业持续地改进其软件过程能力。
此处“精简并行”的含义是：（1）对CMMI 3级以内各过程域的内容和要求作了“精简”处理。
（2）在产品生命周期之内，项目管理过程、项目研发过程和机构支撑过程“并行”开展。
本章是SPP的综述文章，它对SPP的思想方法以及企业的软件过程改进政策作了全面介绍。
阅读本章有助于读者更好地理解和应用SPP的所有过程规范和文档模板。
建议用户（企业）根据自身情况（如发展战略、研发实力等）适当地修改SPP，然后推广使用。
2.1SPP模型SPP模型把产品生命周期划分为6个阶段，分别为：²产品概念阶段，记为PH0。
²产品定义阶段，记为PH1。
²产品开发阶段，记为PH2。
²产品测试阶段，记为PH3。
²用户验收阶段，记为PH4。
²产品维护阶段，记为PH5。
在SPP模型中，软件项目的过程有三大类：项目管理过程、项目研发过程和机构支持过程。
上述三类过程可以细分为19个主要过程域，分布在PH0到PH5的各个阶段。
项目管理过程包含6个过程域，分别为：²立项管理²结项管理²项目规划²项目监控²风险管理²需求管理项目研发过程包含8个过程域，分别为：²需求开发²技术预研²系统设计²实现与测试²系统测试²Beta测试²客户验收²技术评审机构支撑过程包含5个过程域，分别为：²配置管理²质量保证²培训管理²外包与采购管理²服务与维护SPP模型如图2-1所示。
软件工程讲义_第二章
演化过程模型评述[NOG00]
首先，原型开发（和其他更加复杂的演化过程） 由于构建产品需要的周期数目不确定，给项目策 划带来了困难。 其次，演化软件过程没有确定演进的最快速度。 如果演进的速度太快，完全没有间歇时间，项目 肯定会陷入混乱；反之，如果演进速度太慢，则 会影响生产率…… 再次，软件过程应该侧重于灵活性和可扩展性， 而不是高质量。为了追求高质量而延长开发时间 势必造成产品推迟交付，从而失去进入市场的良 机。
过程模式
过程模式提供了一种有效的机制来描述各 种软件过程。模式使得软件工程组织能够 从高层抽象开始，开发层次化的过程描述。 高层抽象描述又进一步细化为一系列步骤 模式以描述框架活动，然后每一个步骤模 式又进一步逐层细化为更详细的任务模式。 过程模式一旦建立起来，就可以在过程变 体的定义中复用——即软件开发队伍可以 将模式作为过程模式的构建模块，定制特 定的过程模型。
演化过程模型评述
演化模型的初衷是采用迭代或者增量的方式开 发高质量软件。可是，用演化模型也可以做到强 调灵活性、可扩展性和开发速度。软件开发团队 及其经理所面临的挑战就是在这些严格的项目和 产品参数与客户（软件质量的最终仲裁者）满意 度之间找到一个合理的平衡点。
专用过程模型
专用过程模型具有传统过程模型的一些特 点，但是，专用过程模型往往应用面较窄， 只适用于某些特定的软件工程方法。 在某些情况下，这些专用过程也许更确切 地应该称为技术的集合或方法论，是为了 实现某一特定的软件开发目标而制定的。 但它们确实也提出了一种过程。
模式名称：应能清楚地表述该模式在软件过程中的功能。 驱动力：模式使用环境及主要问题， 以明确主要难点 并可能影响解决方案。 类型：定义模式类型。 启动条件：描述模式应用的前提条件。 问题：描述模式将要解决的问题。 解决办法：描述模式的实现。 结束条件：描述模式成功执行之后的结果。 相关模式：以层次或其他图的方式列举与该模式相关的 其他模式。 已知应用实例：介绍该模式的具体实例。
软件过程模型
软件过程模型随着信息时代的到来，人们对软件的需求越来越大。
为了让软件开发变得更加有条理和规范化，软件过程模型应运而生。
本文将就软件过程模型进行探讨和分析。
一、什么是软件过程模型？软件过程模型是指一种用于指导软件开发过程的特定方法，它包括软件开发中的所有活动和任务，并在整个过程中提供了一系列的标准和规范。
软件过程模型的核心思想是将软件开发过程分为一系列的步骤，并且在每个步骤中设置相应的输入、输出和控制流程，从而使得整个软件开发过程变得更加可靠和高效。
二、常见的软件过程模型1. 瀑布模型瀑布模型是一种传统的软件过程模型，将整个软件开发过程分为五个阶段，分别是需求分析、设计、实现、测试和维护。
瀑布模型的优点是结构简单，易于理解和使用，同时缺点也很明显，比如缺乏灵活性、周期较长、迭代困难等。
2. 增量模型增量模型是一种将软件开发过程分为若干个增量，对每个增量进行开发和测试，最后再进行集成的过程模型。
增量模型的优点是可以快速地得到一个基本功能完整的软件系统，同时也可以逐步完善和优化软件系统。
缺点是增量之间的集成会存在较大的风险，需要注意控制。
3. 螺旋模型螺旋模型是一种基于风险管理的软件过程模型，将软件开发过程分为四个阶段，分别是计划、风险分析、工程实施和评估。
螺旋模型的优点是可以快速地发现和控制风险，同时也可以在开发过程中逐步完善和优化软件系统。
缺点是需要更多的资源和时间来进行风险分析和控制。
三、如何选择合适的过程模型在选择软件过程模型的时候，需要考虑以下几个方面：1. 项目的规模和复杂度。
如果项目规模较大，应该选择一种较为成熟和完善的软件过程模型，比如RUP或者敏捷开发等；如果项目规模较小，则可以选择更加简单的模型，比如瀑布模型或增量模型。
2. 团队成员的经验和技能。
如果团队成员经验丰富且具备较高的技能水平，则可以选择一种较为灵活和动态的软件过程模型，比如敏捷开发等；如果团队成员水平较为一般，则需要选择一种更加规范和标准的软件过程模型，比如RUP或瀑布模型。
软件过程框架与软件过程模型PPT课件
SRD
22
7.软件工程管理
项目管理是过程管理的主要体现： (1)建立与客户的沟通渠道； (2)制订计划，定义资源、时限、落实到开发组； (3)风险分析，评估所采用的技术和管理带来的风险； (4)技术过程监控； (5)客户评审，获得客户的反馈。
23
24
25
8.软件质量保证
软件质量保证SQA活动，贯穿于软件过程始终。开发单位 成立SQA小组负责全面质量管理。在开发项目计划时就要做出 SQA计划。其工作： - 各种测试：测试软件是否满足规格说明要求。 - 各种评审/审计：为多种人员参与的讨论会，以规格说明或各 种标准、规范为准评价各项软件工作。 - 报告和记录：所有测试、评审、审计都要详细记录并写出报 告，报告和记录均要整理、归档。
以上活动均应在软件质量保证计划中列出。
26
27
传统软件生命周期模型
1. 瀑布模型 Winston Royce在软件生命周期概念的基础上，于1970年提出了著名
的“瀑布模型”（waterfall model）。
28
瀑布模型中的每一个开发活动具有下列特征： - 本活动的工作对象来自于上一项活动的输出，这些输出一般是代表 本阶段活动结束的里程碑式的文档。 - 根据本阶段的活动规程执行相应的任务。 - 产生本阶段活动相关产出——软件产品，作为下一活动的输入。 - 对本阶段活动执行情况进行评审。
37
原型法的适用范围和局限性： - 对于一个大型系统，如果不经过系统分析得到系统的整体划分， 而直接用原型来模拟是很困难的。 - 对于原有应用的业务流程、信息流程混乱的情况，原型构造与 使用有一定的困难。 - 对于一个批处理系统，由于大部分活动是内部处理的，因此应 用原型方法会有一定的困难。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
原型需求
系统需求
沟通 快速策划 建模 快速设计
提交系统
部署交付 及反馈
构建原型
2-1 软件过程模型
快速原型法的步骤
Step 1：双方通过沟通，明确已知的需求，并大致勾画出以后 再进一步定义的东西。 Step 2：迅速策划一个原型开发迭代并进行建模，主要集中于 那些最终用户所能够看到的方面，如人机接口布局或者输出
2-1 软件过程模型
瀑布模型
也叫做鲑鱼模型(Salmon model)：向前一阶段回溯，很难。
2-1 软件过程模型
瀑布模型
优点——追求效率 – 它提供了一个模板，这个模板使得分析、设计、编码、测试和 支持的方法可以在该摸板下有一个共同的指导；
– 简单、易懂、易用、快速；
– 为项目提供了按阶段划分的检查点，项目管理比较容易；每个
2-1 软件过程模型
增量模型
举例1：开发一个类似于Word的文字处理软件 – 增量1：提供基本的文件管理、编辑和文档生成功能； – 增量2：提供高级的文档编辑功能； – 增量3：实现拼写和语法检查功能；
– 增量4：完成高级的页面排版功能；
举例2：开发一个教务管理系统 – 增量1：提供基本的学籍管理和成绩管理功能； – 增量2：提供选课功能； – 增量3：提供查询教室使用情况的功能；
– 增量4：提供课表生成、上课名单生成、成绩录入等功能。
2-1 软件过程模型
增量模型
优点：
– 在时间要求较高的情况下交付产品：在各个阶段并不交付一 个可运行的完整产品，而是交付满足客户需求的一个子集的 可运行产品，对客户起到“镇静剂”的作用； – 人员分配灵活：如果找不到足够的开发人员，可采用增量模 型：早期的增量由少量人员实现，如果客户反响较好，则在 下一个增量中投入更多的人力； – 逐步增加产品功能可以使用户有较充裕的时间来学习和适应 新产品，避免全新软件可能带来的冲击；
– 多个团队并行进行开发，但启动时间有先后，先启动团队的 提交物将作为后启动团队的输入； 缺点： – 需要大量的人力资源来创建多个相对独立的RAD团队； – 如果没有在短时间内为急速完成整个系统做好准备，RAD项 目将会失败； – 如果系统不能被合理的模块化，RAD将会带来很多问题； – 技术风险很高的情况下(采用很多新技术、软件需与其他已有 软件建立集成、等等)，不宜采用RAD。
2-1 软件过程模型
软件开发需要过程吗？
写了再改(Code-and-Fix)，不挺好吗？
– 不需要太多其他准备或相关知识，无需文档，无需规划，无 需质量保障，上来就写代码；
– 也许就能写出来，写不出来就改，也许能改好。
适用场合： – “只用一次”的程序 – “看过了就扔” 的原型 – 一些不实用的演示程序
客户要等到开发周期的晚期才能看到程序运行的测试版本，而 在这时发现大的错误时，可能引起客户的惊慌，而后果也可能 是灾难性的。 采用这种线性模型，会经常在过程的开始和结束时碰到等待其 他成员完成其所依赖的任务才能进行下去，有可能花在等待的 时间比开发的时间要长。我们称之为“堵赛状态”。
2-1 软件过程模型
显示格式等；
Step 3：快速设计产生原型，对原型进行部署，由客户和用户 进行评价； Step 4：根据反馈，进一步细化需求并调整原型； Step 5：原型系统不断调整以逼近用户需求。
2-1 软件过程模型
“原型”的类型
Throwaway prototyping(抛弃式原型)
– 最初的原型在完成并得到用户认可之后，将不会作为交付给 用户的最终系统的一部分，而是被抛弃，其目的只是为了收 集与验证需求； – 该类原型可能是不可执行的(例如，只包含用户界面)；
– 因为具有较高优先权的模块被首先交付，而后面的增量也不 断被集成进来，这使得最重要的功能肯定接受了最多的测试， 从而使得项目总体性失败的风险比较低。
2-1 软件过程模型
增量模型
困难：
– 每个附加的增量并入现有的软件时，必须不破坏原来已构造
好的东西。
– 同时，加入新增量时应简单、方便 ——该类软件的体系结
– 快速应用程序开发(RAD)
演化过程模型 (Evolutionary model) – 螺旋模型 (Spiral)
– 原型模型 (Prototype)
其他过程模型 – 形式化过程 (Formal model)
– 基于复用的软件过程
– 敏捷过程模型(Agile)
2-1 软件过程模型
(1) 瀑布模型
2-1 软件过程模型
增量模型
软件被作为一系列的增量来设计、实现、集成和测试，每一 个增量是由多种相互作用的模块所形成的提供功能的代码片 段构成。 本质：以迭代的方式运用瀑布模型
– 第一个增量往往是核心产品：满足了基本的需求，但是缺少 附加的特性；
– 客户使用上一个增量的提交物并进行自己评价，制定下一个 增量计划，说明需要增加的特性和功能； – 重复上述过程，直到最终产品产生为止。
很好的理解和核心产品与系统需求，但对其他扩展的细节问题 却没有定义。
在上述情况下，需要一种专门应对不断演变的软件过程模型， 即“演化过程模型”。 本质：循环、反复、不断调整当前系统以适应需求变化； 包括两种形态：
– 快速原型法
– 螺旋模型
2-1 软件过程模型
快速原型法
待修改列表 顾客 评审 修订 原型 原型设计 原型系统实现 原型系统测试 待修改列表 待修改列表
2-1 软件过程模型
增量模型
沟通 策划 建模(分析、设计) 构建(编码、测试) 部署(交付、反馈) 交付第n个增量 第n个增量
软 件 功 能 和 特 征
第2个增量 交付第2个增量 第1个增量 交付第1个增量
项目时间
增量模型采用随着日程时间的进展而交错的线性序列。每 一个线性序列产生软件的一个可发布的“增量”。
– 要求开发之前需求被充分理解
– 与客户的交互只在开始(需求)和最后(发布)——类似于产品制 造过程（如汽车制造等，用户不参与制造过程）
– 而实际情况完全不是这样
2-1 软件过程模型
黑盒过程与白盒过程
Informal Requirements
Process Product
feedback
优点： – 通过改进可见性来减少风险
证/ 确 认 问题空间
需求分析方法
需求模型
系统设计方法
需求建模语言
设计模型
程序设计方法
设计建模语言
实现模型
部署与维护方法
编程语言
部署与运行模型
部署与运行配置语言
软件(解)空间
软件工程
2 典型的软件过程模型
2-1 软件过程模型
典型的软件过程模型
瀑布模型 (Waterfall)
增量过程模型 (Incremental process model) – 增量模型 (Incremental)
软件工程
1 软件过程
2-1 软件过程模型
2-1 软件过程模型
软件过程
软件过程定义以下内容：
– 人员与分工
– 所执行的活动 – 活动的细节和步骤 软件过程通过以下方式组织和管理软件生命周期： – 定义软件生产过程中的活动
– 定义这些活动的顺序及其关系
软件过程的目的： – 标准化(可模仿)、可预见性(降低风险)、提高开发效率、得到 高质量产品 – 提升制定时间和预算计划的能力
– 在开发过程中，通过不断地获得顾客的回馈允许变更—— 类似于服务过程（用户参与与交互）
2-1 软件过程模型
软件过程的典型阶段
Dream(提出设想) Investigation(深入调研) Software Specification(需求规格说明) Software Design(软件设计) Software Implementation(软件实现) 验 Software Deployment (软件部署) Software Validation(软件验证) Software Evolution(软件演化)
软件工程
软件工程 第二章 敏捷开发过程
2-1 软件过程模型
初佃辉 2019年3月8日
2-1 软件过程模型
主要内容
1 软件过程 2 典型软件过程模型 – 瀑布模型 – 增量过程模型 ― 演化过程模型 螺旋模型 原型模型 ― * 其他过程模型 形式化过程 软件复用过程
• 增量模型 • 快速应用程序开发(RAD) 3 案例分析
1970年，Winston Royce，是软件开发的系统化的、顺序的方法
定义阶段
计划 需求分析
开发阶段
设计 编码 测试
运行、维护阶段
运行维护
•上一个阶段结束，下一个阶段才能开始； •每个阶段均有里程碑和提交物； •上一阶段的输出是下一阶段的输入； •每个阶段均需要进行V&V； •侧重于文档与产出物；
Evolutionary prototyping(演化式原型)
– 最初构造的原型将具备较高的质量，包含了系统的核心功能， 然后通过收集需求对其进行不断的改善和精化；
– 该类原型是可执行的，将成为最终系统的一部分；
2-1 软件过程模型
快速原型法的优缺点
优点：
– 提高和改善客户/用户的参与程度，最大程度的响应用户需 求的变化；
2-1 软件过程模型
(2) 增量过程模型
在很多情况下，由于初始需求的不明确，开发过程不宜采用 瀑布模型； 因此，无须等到所有需求都出来才进行开发，只要某个需求 的核心部分出来，即可进行开发；
另外，可能迫切需要为用户迅速提供一套功能有限的软件产 品，然后在后续版本中再细化和扩展功能。
在这种情况下，需要选用增量方式的软件过程模型。 – 增量模型 – RAD模型