软件生命周期模型
软件工程过程
工程项目的PDCA循环（戴明环）
美国质量管理专家戴明博士针对工程项目的质量目标，将全面质量管理思想引入工程项目过程，提出了PDCA循环，也称为戴明环.
即Plan（规划）、Do（执行）、Check（检查）、Action（处理）等抽象活动的循环。
软件工程过程(Software Engineering Process)
软件工程过程是为获得软件产品，在软件工具支持下由软件工程师完成的一系列软件工程活动。软件工程过程遵循PDCA抽象活动，包含四种基本的过程活动：
- P (Plan) : 软件规格说明。规定软件的功能及其使用的限制；
- D (Do) : 软件开发。产生满足规格说明的软件；
- C (Check) : 软件确认。通过有效性验证以保证软件能够满足客户的要求；
- A (Action) : 软件演进。为满足客户的变更要求，软件必须在使用的过程中不断地改进。
事实上，软件工程过程是一个软件开发机构针对某一类软件产品为自己规定的工作步骤，它应当是科学的、合理的，否则必将影响到软件产品的质量。
软件生命周期
软件生命周期(software life cycle )是指软件产品从考虑其概念开始，到该软件产品不再使用为止的整个时期，一般包括概念阶段、分析与设计阶段、构造阶段、移交阶段等不同时期。
在整个软件生命周期中贯穿了软件工程过程的六个基本活动:
- 制定计划 P
- 制定计划: 确定要开发软件系统的总目标，给出它的功能、性能、可靠性以及接口等方面的要求；研究完成该项软件任务的可行性，探讨解决问题的可能方案；制定完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查。
- 需求分析 D
- 需求分析和定义:对待开发软件提出的需求进行分析并给出详细的定义。编写出软件需求说明书及初步的用户手册，提交管理机构评审。
- 设计 D
- 软件设计:设计是软件工程的技术核心。把已确定了的各项需求转换成一个相应的体系结构。进而对每个模块要完成的工作进行具体的描述。编写设计说明书，提交评审。
- 程序编码 D
- 程序编写:把软件设计转换成计算机可以接受的程序代码。
- 测试 C
- 软件测试:在设计测试用例的基础上检验软件的各个组成部分。
- 运行维护 A
- 运行／维护:已交付的软件投入正式使用，并在运行过程中进行适当的维护。
传统软件生命周期模型
软件过程模型有时也称软件生命周期模型，即描述从软件需求定义直至软件经使用后废弃为止，跨越整个生存期的软件开发、运行和维护所实施的全部过程、活动和任务的结构框架，同时描述生命周期不同阶段产生的软件工件，明确活动的执行角色等。
九个传统软件生命周期模型：
瀑布模型、螺旋模型、V模型和W模型、喷泉模型、原型方法、构件组装模型、演化模型、快速应用开发模型、增量模型
瀑布模型(waterfall model)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-10m4pD6g-1669013372016)(./软件生命周期模型.assets/waterfall.png)]
- 瀑布模型将软件开发活动中的各项活动规定为线性顺序连接的若干阶段，形如瀑布流水，最终得到软件产品。
特点
- 他将软件开发过程划分为若干相互区别而又彼此联系的阶段，每个阶段以上一个阶段为基础，同时该阶段工作结果又是下一个阶段的开始的依据。
- 每个阶段完成任务产生相应的文档，且评审。
瀑布模型优点：
⑴ 软件生命周期的阶段划分不仅降低了软件开发的复杂程度，而且提高了软件开发过程的透明性，便于将软件工程过程和软件管理过程有机地融合在一起，从而提高软件开发过程的可管理性。
⑵ 推迟了软件实现，强调在软件实现前必须进行分析和设计工作。
⑶ 瀑布模型以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，保证了阶段之间的正确衔接，能够及时发现并纠正开发过程中存在的缺陷，从而能够使产品达到预期的质量要求。
瀑布模型缺点:
⑴ 软件开发是一个充满回溯的过程，模型是线性开发过程，缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。
⑵ 模型的风险控制能力较弱。成品时间长；体系结构的风险和错误只有在测试阶段才能发现，返工导致项目延期。
⑶软件活动是文档驱动的，文档过多会增加工作量，文档完成情况会误导管理人员。
原型方法(prototyping)
- 完整准确的需求规格说明很难得到
- 早期用户对系统只有一个模糊的想法；
- 开发过程中用户可能提出新的需求；
- 环境的变化也要求开发过程中的系统随之改变；
- 预料之外的实际困难使得开发人员不得不改变需求来适应。
- 通过加强评审和确认、全面测试也不能从根本上解决需求不稳定带来的问题。
- 为了解决这些问题，逐渐形成了软件系统的原型建设思想
(1) 原型方法概述
- 原型：是指模拟某种产品的原始模型。软件原型是一个早期可以运行的版本，它反映最终系统的部分重要特性。
原型方法构造软件系统
-
获得一组基本的需求说明，快速分析构造出一个小型的软件系统，满足用户的基本要求；
-
用户试用原型系统，对其进行反应和评价；
-
开发者根据用户意见对原型进行改进，获得新的原型版本；周而复始，直到产品满足用户的要求。
-
原型化方法是在研究需求分析技术的过程中产生的，但也可以用于软件开发的其他阶段
原型的种类（目的）
- 探索型：弄清对目标系统的要求
- 实验型：系统实现前考察系统的可行性
- 进化型：将原型扩展到开发过程，通过原型开发逐步实现所有系统功能。
原型的使用策略
原型方法的优点
- 有助于增进软件人员和用户对系统服务需求的理解
- 提供了一种有力的学习手段
- 容易确定系统的性能、服务的可应用性、设计的可行性和产品的结果
- 原型的最终版本可作为最终产品或最终系统的一部分
原型方法的缺点
- 文档容易被忽略
- 建立原型的许多工作会被浪费掉
- 项目难以规划和管理
(2) 原型方法应用过程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aEzwVP1y-1669013372019)(./软件生命周期模型.assets/prototyhpe.png)]
- 快速分析
- 快速构造
- 尽快实现一个可运行的系统，可忽略目标系统在某些细节（如安全性、健壮性、异常处理等）上的要求 。
- 用户使用
- 评价反馈
- 是否满足规格说明的要求；纠正分析过程中的一些误解和错误；增补新的要求
- 修改
(3) 原型方法支持的软件生命周期
原型方法可以支持软件生命周期的不同阶段
- 辅助或代替分析阶段 (确定需求)
- 辅助设计阶段 (确定设计方案的合理性)
- 代替分析与设计阶段
- 代替分析、设计和实现阶段
- 代替全部开发阶段 (典型的演化模型 )
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7tJ70hpq-1669013372020)(./软件生命周期模型.assets/prototype2.png)]
演化模型
- 项目开发初始阶段对需求的认识不够清晰，使得开发工作出现再开发在所难免。经验告诉我们：开发“两次”后的软件能较好地满足用户的要求。
- 第一次：试验开发，目的是探索可行性，弄清楚项目的需求。第一次得到的试验性产品称为“原型”。
- 第二次：在第一次的原型基础上进行开发，从而获得较为满意的软件产品。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5x0pdiiZ-1669013372021)(./软件生命周期模型.assets/演化模型.png)]
- 演化模型主要针对需求不是很明确的软件项目
- 演化模型缺点
- 可能会抛弃瀑布模型的文档控制优点，开发过程不透明
- 探索式演化模型可能会导致最后的软件系统的系统结构较差
- 可能会用到一些不符合主流、不符合要求或者不成熟的工具和技术
增量模型
- 增量模型首先由Mills等人于1980年提出，结合了瀑布模型和演化模型的优点。
- 允许客户的需求可以逐步提出来；每一次“增量”需求的划分与“增量”实现的集成是以不影响系统体系结构为前提的。
- 在增量模型中，客户定义需求框架，确定系统需求实现的优先级；此后针对核心需求以及系统的性能要求确定系统的体系结构，并以此体系结构指导增量的集成，保证在整个开发过程中体系结构的稳定性。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xfGJqp83-1669013372022)(./软件生命周期模型.assets/增量模型示意图 .png)]
- 增量模型优点
- 增强了客户使用系统的信心，逐步提出对后续增量的需求
- 项目总体失败的风险较低
- 增量从高到低的优先级确定保障了系统重要功能部分的可靠性
- 同一个体系结构提高了系统的稳定性和可维护性
- 增量模型缺点
- 增量的粒度选择问题
- 确定所有的基本业务服务比较困难
螺旋模型
螺旋模型是Boehm于1988年针对大型软件项目的特点提出来的
- 对于复杂的大型软件而言，事先不能完整清晰地定义需求是常事，而且设计方案、技术实现方案不允许出现问题，也需要经过多次试验才能明确下来，开发一个只明确需求的原型是远远不能解决问题的，需要开发内容逐步丰富的多个原型。
- 大型软件项目往往存在着诸多风险因素，螺旋模型将瀑布模型与演化模型结合起来，并加入了两种模型均忽略了的风险分析。因为大型项目的规模和复杂性增加，软件开发过程中必然存在着许多风险问题，风险分析是保证项目成功的必要手段。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QZ31rzlb-1669013372023)(./软件生命周期模型.assets/螺旋模型示意图.png)]
螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面的活动，即：
- 制定计划──确定软件目标，选定实施方案，弄清项目开发的限制条件
- 风险分析──分析所选方案，考虑如何识别和消除风险
- 实施工程──实施软件开发
- 客户评估──评价开发工作，提出修正建议
螺旋模型适合于大型软件的开发;然而风险分析需要相当丰富的评估经验，风险的规避又需要深厚的专业知识，这给螺旋模型的应用增加了难度。
喷泉模型(迭代模型)
喷泉模型认为软件开发过程具有两个固有的本质特征：
- 迭代 多次重复、演进。
- 无间隙 各阶段间无明显的界限。支持分析和设计结果的自然复用。
- 适用：面向对象的软件开发过程。对象概念的引入，对象及对象关系在分析、设计和实现阶段的表达方式的统一，使得开发活动之间的迭代和无间隙性能够容易地实现。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-v02RZjyB-1669013372025)(./软件生命周期模型.assets/喷泉模型示意图.png)]
- 喷泉模型开发过程
- 优点
- 支持软件冲用和多项开发活动集成
- 分析和设计等各项活动之间没有明显的边界
- 喷泉模型强调增量开发，他依据分析一点设计一点的原则，并不要求一个阶段的彻底完成，整个过程是迭代逐步提炼的过程
- 缺点
- 由于喷泉模型在各个开发阶段是重叠的,因此在开发过程中需要大量的开发人员,因此不利于项目的管理.
- 此外这种模型要求严格管理文档,使得审核的难度加大,尤其是面对可能随时加入各种信息、需求与资料的情况.
构件组装模型
- 构件组装模型本质上是演化的，开发过程是迭代的。
- 构建组装模型由五个阶段组成：
- 需求定义和分析
- 软件体系结构设计
- 构件开发
- 应用软件构造
- 测试和发布
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PhXcFghA-1669013372026)(./软件生命周期模型.assets/构件组装模型.png)]
软件的开发过程步骤如下：
- (1)定义和分析需求；
- (2)标识本项目需要什么构件；
- (3)从库中查找构件或相似的构件；
- (4)如果可用转(5)，否则自行开发或修改，确认后入库；
- (5)构造为新系统作第m次迭代；
- (6)测试、确认。
快速应用开发(RAD)模型
- 快速应用开发(Rapid Application Development，RAD)是一个增量型的软件开发过程模型，采用构件组装方法进行快速开发。
- RAD模型包含如下阶段：
- (1)业务建模：通过捕获业务过程中信息流的流动及处理情况描述业务处理系统应该完成的功能。回答以什么信息驱动业务过程运作? 要生成什么信息? 谁生成它? 信息流的去向? 由谁处理? 可以辅之以数据流图。
- (2)数据建模：对于支持业务过程的数据流，建立数据对象集合,定义数据对象属性,与其它数据对象的关系构成数据模型，可辅之以E-R图。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PIA5h71i-1669013372027)(./软件生命周期模型.assets/RAD模型示意图.png)]
新型软件生命周期模型
统一软件开发过程 (RUP)
(1) RUP的基本结构
- RUP是一个二维的软件开发模型。
- 横轴在时间上将生命周期过程展开成四个阶段（Phase），每个阶段特有的里程碑（Milestone）是该阶段结束的标志，每个阶段里又划分为不同的迭代（Iteration），体现了软件开发过程的动态结构。
- 纵轴按照活动的内容进行组织，包括活动（activity）、活动产出的工件（artifact）、活动的执行角色（worker）以及活动执行的工作流（workflow），体现软件开发过程的静态结构。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KVV9s84q-1669013372028)(./软件生命周期模型.assets/RUP二维软件开发模型.png)]
RUP中的软件生命周期的四个顺序阶段：
- 初始阶段
- 阶段目标：通过业务用例（Business Case）了解业务并确定项目的边界，包括项目的验收规范、风险评估、所需资源估计、阶段计划等。
- 要确定项目边界，需识别所有与系统交互的外部实体，主要包括识别外部角色（actor）、识别所有用例并详细描述一些重要的用例。
- Milestone：软件目标里程碑。包括一些重要的文档，如项目愿景（vision）、原始用例模型、原始业务风险评估、一个或者多个原型、原始业务场景等。
- 需要对这些文档进行评审，以确定正确理解用例需求、项目风险评估合理、阶段计划可行等。
- 细化阶段
- 阶段目标：分析问题领域，建立适合需求的软件体系结构基础，编制项目计划，完成项目中技术要求高、风险大的关键需求的开发。
- Milestone：体系结构里程碑。包括风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。
- 通过评审确定软件体系结构的稳定性、确认高风险的业务需求和技术机制已经解决、修订的项目计划可行等。
- 构造阶段
- 阶段目标：将所有剩余的技术构件和稳定业务需求功能开发出来，并集成为产品，所有功能被详细测试。从某种意义上说，构造阶段只是一个制造过程，其重点放在管理资源及控制开发过程以优化成本、进度和质量。
- Milestone：运行能力里程碑。包括可以运行的软件产品、用户手册等，它决定了产品是否可以在测试环境中进行部署。
- 要确定软件、环境、用户是否可以开始系统的运行。
- 移交阶段
- 阶段目标：软件产品正常运行并交付用户使用。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。
- Milestone：产品发布里程碑。包括维护和售后支持文档手册等。
- 要确定最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。
(2) RUP的迭代增量开发思想
- RUP是以用例为驱动，软件体系结构为核心，应用迭代及增量的新型软件生命周期模型
- RUP的每一个阶段可以进一步划分为一个或多个迭代过程，从一个迭代过程到另一个迭代过程增量形成最终的系统。
- RUP是融合了喷泉模型和增量模型的一种综合生命周期模型 。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AnmYBiRg-1669013372029)(./软件生命周期模型.assets/RUP中的迭代增量开发.png)]
- RUP将整个项目的开发目标划分成一些更易于完成和达到的阶段性小目标。每一次迭代就是为了完成一定阶段性小目标而从事的一系列开发活动，包含需求、设计、实施（编码）、部署、测试等。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-sHWPFZ1D-1669013372030)(./软件生命周期模型.assets/RUP中的迭代过程.png)]
(3) RUP的核心工作流
(4) RUP的最佳实践
- 短时间分区式的迭代
- 适应性开发
- 在早期迭代中解决高技术风险和高业务价值的问题
- 不断地让用户参与迭代结果的评估
- 在早期迭代中建立内聚的核心架构
- 不断地验证质量；尽早、经常和实际地测试
- 使用用例驱动软件建模
- 可视化软件建模：使用UML进行软件建模
- 仔细地管理需求
- 实行变更请求和配置管理
敏捷开发
(1) 敏捷宣言
2001年2月由17位当时称之为“轻量级方法学家”所编写签署的“敏捷宣言”（Agile Manifesto）
-
个体和交互 胜过 过程和工具
-
可以工作的软件 胜过 面面俱到的文档
-
客户合作 胜过 合同谈判
-
响应变化 胜过 遵循计划
-
敏捷方法的主要特点就是具有快速及灵活的响应变更的能力
-
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
-
敏捷方法很多,包括极限编程(XP)、 Scrum、功能驱动开发(FDD)、水晶、净室开发等多种方法，这些方法本质实际上是一样的，都遵循“敏捷宣言”原则。
(2) 极限编程 (eXtreme Programming )
- 1996年三月，Kent Beck在为Daimler Chrysler所做的一个项目中引入了新的软件开发观念：XP。
- XP是一种轻量级的软件开发方法，是一种以实践为基础的软件工程过程和思想。
- 它使用快速的反馈，大量而迅速的交流，经过保证的测试来最大限度的满足用户的需求。
- XP强调用户满意，开发人员可以对需求的变化作出快速的反应。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-L4dEn6g1-1669013372031)(./软件生命周期模型.assets/极限编程的处理流程.png)]
XP的工作环境
- 每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利和义务。用户也是项目组的一部分。
- 为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务，XP要求把工作环境也做得最好。
- 所有人都在同一个开放的开发环境中工作
- 最好是所有人在同一个大房子中工作，还有茶点供应；每周40小时，不提倡加班；
- 每天早晨，所有人一起站着开个短会；
- 墙上有一些大白板，所有的Story卡、CRC卡等都贴在上面，讨论问题的时候可以在上面写写画画；
- 下班后大家可以一起玩电脑游戏……。
XP的需求分析
- 开发人员和客户一起，把各种需求变成一个个小的需求模块（User Story）；
- 这些模块又会根据实际情况被组合在一起或者被分解成更小的模块，且它们都被记录在一些小卡片（Story Card）上；
- 客户根据每个模块的商业价值来指定它们的优先级；
- 然后，开发人员确定每个需求模块的开发风险；
- 经过开发人员和客户的评估后，它们被安排在不同的开发周期里，客户将得到一个尽可能准确的开发计划；
- 客户为每个需求模块指定验收测试（功能测试）。
XP的设计
- 从开发的角度来看，XP内层的过程是一个基于Test Driven Development周期，每个开发周期都有很多相应的单元测试。
- 随着这些测试的进行，通过的单元测试也越来越多。通过这种方式，客户和开发人员都很容易检验，是否履行了对客户的承诺。
- 同时，XP还大力提倡设计复核（Review）、代码复核以及重整和优化（Refectory），所有的这些过程其实也是优化设计的过程；
XP的编程
- XP提倡配对编程（Pair Programming），而且代码所有权是归于整个开发队伍（Collective Code Ownership）。
- 程序员在写程序和重整优化程序的时候，都要严格遵守编程规范。
- 任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。
XP的测试
- XP提倡在开始写程序之前先写单元测试。
- 开发人员应该经常把开发好的模块整合到一起（Continuous Integration，持续集成），每次整合后都要运行单元测试；
- 做任何的代码复核和修改，都要运行单元测试；
- 发现了BUG，就要增加相应的测试。
- 除了单元测试之外，还有整合测试，功能测试、负荷测试和系统测试等。
- 所有这些测试，是XP开发过程中最重要的文档之一，也是最终交付给用户的内容之一。
几点建议：
- 软件生命周期模型不是“死”的标准和原则，软件开发团队可以根据项目的具体要求对其进行剪裁。
- 软件开发过程具有很强的实践性和发展性，需要在不同项目实践中进行扩展和完善。
