第2章 软件生命周期模型
合集下载
软件生命周期模型
7. 软件生存周期原型模型
开始 结束 初步需求 分析 快速设计
开发产品 建造原型
对原型加工 用户评估原 新需求） 型（新需求）
又称演化模型：用主动的正常的迭代避免被迫 的不正常的反复 原型(prototype) ：可以演示的试验性产品、重 点为系统功能、用户界面 必要性、可行性：
并非所有需求都可以精确定义 项目参加者之间存在通信障碍 已有快速原型开发工具 恰当使用原型法可以减少软件总成本
开发过程：分析、设计、编码、集成、测试、安 装、验收等 管理过程：项目管理计划、实施和控制、评审和 评价等 供应过程 获取过程 操作过程 维护过程 支持过程
2. 软件生存周期
什么是软件生存周期
Software Life Cycle 软件产品从形成概念开始，经过开发、使用和维 护，直到退役的全过程。 软件定义、软件开发、软件使用与维护
软件的使用
软件发行：份数越多越好 客户(维护人员)：收集软件错误，撰写“软件问题 报告”和“软件修改报告”
软件的维护
可维护性：可理解性、可测试性、可修改性 改正性维护 适应性维护 完善性维护 预防性维护
软件的退役
6. 软件生存周期瀑布模型
线性开发序列：每一阶段任务必须通过评 审才能进入下一阶段，直线前进 避免大的返工，允许局部的返工：有反馈 的迭代（返工在所难免 ） 非常适合于数据处理类软件开发 局限性：明确全部需求困难甚至不现实、 开发周期过长、用户不能及时提出修改意 见、不适合交互式软件开发等
4. 软件开发
概要设计（总体设计）
划分功能模块 定义各功能模块的接口 设计全局数据结构（数据库） 制定测试计划 设计原则：自顶向下、逐步求精、抽象、模块化、局部化、 信息隐藏等
第2章软件生命周期模型PPT课件
➢ 周期内有可行性分析、需求分析、概要设计、 详细设计、编码、测试和维护等阶段
➢ 这种按时间分程的思想方法是软件工程中的一 种思想原则，即按部就班、逐步推进，每个阶 段都要有定义、工作、审查、形成文档以供交 流或备查，以提高软件的质量。
2020/11/23
2
软件生命周期各阶段的主要任务:
（1） 可行性分析和项目开发计划 ➢ “要解决的问题是什么”
➢ 该问题有行得通的解决办法吗？
➢ 若有解决问题的办法，则需要多少费用？需要 多少资源？需要多少时间？
（2） 需求分析
需求分析阶段的任务不是具体地解决问题，而 是准确地确定“软件系统必须做什么？”确定 软件系统必须具备哪些功能。
2020/11/23
3
（3） 概要设计
在概要设计阶段，开发人员要把确定的各项功 能需求转换成需要的体系结构，概要设计就是 设计软件的结构，该结构由哪些模块组成，这 些模块的层次结构是怎样的，这些模块的调用 关系是怎样的，每个模块的功能是什么。
2020/11/23
11
（4）缺点：
➢ 缺乏灵活性，不能适应用户需求的改变。
➢ 开始阶段的小错误被逐级放大，可能导致软 件产品报废。
➢ 返回上一级的开发需要十分高昂的代价。
➢ 随着软件规模和复杂性的增加，软件产品成 功的机率大幅下降。
2020/11/23
12
2.3 原型模型
原型模型(Prototype Model)在初步需求分析之 后，马上向客户展示一个软件产品原型，对客 户进行培训，让客户试用，在试用中收集客户 意见，根据客户意见立刻修改原型，之后再让 客户试用，反复循环几次，直到客户确认为止。
2020/11/23
13
停止
➢ 这种按时间分程的思想方法是软件工程中的一 种思想原则，即按部就班、逐步推进，每个阶 段都要有定义、工作、审查、形成文档以供交 流或备查，以提高软件的质量。
2020/11/23
2
软件生命周期各阶段的主要任务:
（1） 可行性分析和项目开发计划 ➢ “要解决的问题是什么”
➢ 该问题有行得通的解决办法吗？
➢ 若有解决问题的办法，则需要多少费用？需要 多少资源？需要多少时间？
（2） 需求分析
需求分析阶段的任务不是具体地解决问题，而 是准确地确定“软件系统必须做什么？”确定 软件系统必须具备哪些功能。
2020/11/23
3
（3） 概要设计
在概要设计阶段，开发人员要把确定的各项功 能需求转换成需要的体系结构，概要设计就是 设计软件的结构，该结构由哪些模块组成，这 些模块的层次结构是怎样的，这些模块的调用 关系是怎样的，每个模块的功能是什么。
2020/11/23
11
（4）缺点：
➢ 缺乏灵活性，不能适应用户需求的改变。
➢ 开始阶段的小错误被逐级放大，可能导致软 件产品报废。
➢ 返回上一级的开发需要十分高昂的代价。
➢ 随着软件规模和复杂性的增加，软件产品成 功的机率大幅下降。
2020/11/23
12
2.3 原型模型
原型模型(Prototype Model)在初步需求分析之 后，马上向客户展示一个软件产品原型，对客 户进行培训，让客户试用，在试用中收集客户 意见，根据客户意见立刻修改原型，之后再让 客户试用，反复循环几次，直到客户确认为止。
2020/11/23
13
停止
02-第二章-软件开发模型-软件工程教案-海南大学(共15章)
值得注意的是，首先必须有由单位领导签发
的系统开发任务书，任务书的内容应简洁明了、
全面完整而具体，以作为系统需求分析和开发工作 的依据。 可行性研究报告批准之后，便可着手进行软件 计划工作。对软件作用范围、工作环境和基本功能、 特性加以研究，确定要做什么，不要做什么，做到 什么程序。同时，估算出所需的资金、工作量、费 用和进度。编制系统开发初步进度计划表。
瀑布模型各个阶段的任务与文档
瀑布模型法明确规定了每个阶段的任务。 上一阶段完成确定的任务后就产生一定格式 的文档交给下一阶段。不同阶段的任务一般 由不同级别的软件人员来承担。 瀑布模型法适合于在软件需求比较明确、 开发技术比较成熟、工程管理比较严格的场 合下使用。 例如工资管理、会计系统软件的需求比较 明确，就适合于使用瀑布模型法进行开发。
快速原型模型包含的内容 ⑴ 功能选择 要恰当选择原型实现的功能。根据 用户基本需求，对系统给出初步定义。 用户的基本需求包括各种功能的要求、 数据结构、菜单和屏幕、报表内容和格 式等要求。这些要求虽是概略的，但是 最基本的，易于描述和定义。原型和最 终的软件系统不同，两者在功能范围上 的区别主要有以下两个方面：
• 问题定义——系统解决什么问题、目标、范围 • 可行性分析——了解用户要求及观察环境、收集资料、数据流程、技术、
经济、操作可行性、组织、人力、物力、效益
开发时期 • 需求分析——弄清用户的全部需求，用“需求规格说明书”准确地表达出来；
建立系统目标逻辑模型——即“做什么”
• 软件设计——分为总体设计与详细设计，产生软件结构、数据结构、用户界
快速原型模型的基本思想
在获得用户基本需求说明的基础上，投入少量人 力和物力，快速建立一个原始模型，使用户及时运 行和看到模型的概貌和使用效果，并对需求说明进 行补充和精化，提出改进意见，开发人员进一步修 改完善，如此循环迭代，直到得到一个用户满意的 模型为止。 从原型法的基本思想中可以看到，用户能及早 看到系统模型，在循环迭代修改和完善过程中，使 用户的需求日益明确，从而消除了用户需求的不确 定性，同时从原型到模型的生成，周期短、见效 快，对环境变化的适应能力较强。
的系统开发任务书，任务书的内容应简洁明了、
全面完整而具体，以作为系统需求分析和开发工作 的依据。 可行性研究报告批准之后，便可着手进行软件 计划工作。对软件作用范围、工作环境和基本功能、 特性加以研究，确定要做什么，不要做什么，做到 什么程序。同时，估算出所需的资金、工作量、费 用和进度。编制系统开发初步进度计划表。
瀑布模型各个阶段的任务与文档
瀑布模型法明确规定了每个阶段的任务。 上一阶段完成确定的任务后就产生一定格式 的文档交给下一阶段。不同阶段的任务一般 由不同级别的软件人员来承担。 瀑布模型法适合于在软件需求比较明确、 开发技术比较成熟、工程管理比较严格的场 合下使用。 例如工资管理、会计系统软件的需求比较 明确，就适合于使用瀑布模型法进行开发。
快速原型模型包含的内容 ⑴ 功能选择 要恰当选择原型实现的功能。根据 用户基本需求，对系统给出初步定义。 用户的基本需求包括各种功能的要求、 数据结构、菜单和屏幕、报表内容和格 式等要求。这些要求虽是概略的，但是 最基本的，易于描述和定义。原型和最 终的软件系统不同，两者在功能范围上 的区别主要有以下两个方面：
• 问题定义——系统解决什么问题、目标、范围 • 可行性分析——了解用户要求及观察环境、收集资料、数据流程、技术、
经济、操作可行性、组织、人力、物力、效益
开发时期 • 需求分析——弄清用户的全部需求，用“需求规格说明书”准确地表达出来；
建立系统目标逻辑模型——即“做什么”
• 软件设计——分为总体设计与详细设计，产生软件结构、数据结构、用户界
快速原型模型的基本思想
在获得用户基本需求说明的基础上，投入少量人 力和物力，快速建立一个原始模型，使用户及时运 行和看到模型的概貌和使用效果，并对需求说明进 行补充和精化，提出改进意见，开发人员进一步修 改完善，如此循环迭代，直到得到一个用户满意的 模型为止。 从原型法的基本思想中可以看到，用户能及早 看到系统模型，在循环迭代修改和完善过程中，使 用户的需求日益明确，从而消除了用户需求的不确 定性，同时从原型到模型的生成，周期短、见效 快，对环境变化的适应能力较强。
第二章软件生命周期
gaoying@ 7
软件生命周期模型 软件生存期模型是跨越整个生存期的系统开发、 软件生存期模型是跨越整个生存期的系统开发、运 作和维护所实施的全部过程、 作和维护所实施的全部过程、活动和任务的结构框 也称软件过程模型。 架。也称软件过程模型。 软件过程模型体现的是开发策略，并覆盖过程、 软件过程模型体现的是开发策略，并覆盖过程、方 法和工具三个层次。 法和工具三个层次。 软件工程过程模型代表了一种将本质上无序的活动 有序化的企图。 有序化的企图。 • •瀑布模型（线性顺序模型） 喷泉模型 瀑布模型（ 瀑布模型 线性顺序模型） • 并发开发模型 •原型模型 原型模型 • 形式化方法模型 •RAD模型 RAD模型 RAD • 第四代技术 •增量模型 增量模型 • 过程技术 •螺旋模型 螺旋模型
gaoying@ 20
面向对象模型
gaoying@ 21
喷泉模型 维护期 运行状态 实现和集成阶段 实现阶段 面向对象设计阶段 计划阶段 面向对象分析阶段 需求阶段
gaoying@ 22
进一步开发
喷泉模型特点
主要用于支持面向对象开发过程体现了 软件创建所固有的迭代和无间隙的特征。 软件创建所固有的迭代和无间隙的特征。
gaoying@ 15
演化模型
gaoying@ 16
1
增量模型(递增模型) 增量模型(递增模型)
先完成一个系统子集的开发，再按同样的 先完成一个系统子集的开发， 系统子集) 开发步骤增加功能 (系统子集)，如此递增下 去直至满足全部系统需求。 去直至满足全部系统需求。 系统的总体设计在初始子集设计阶段就应 作出设想。 作出设想。
gaoying@ 23
可重用部件组装模型
使用重用技术的软件工程模型 •构件(components): 可重用的软件成份 构件(components): 构件 •可复用性（Reusability） 可复用性（Reusability） 可复用性 （可重用性） 可重用性） •集成化软件开发环境（ISEE） 集成化软件开发环境（ISEE） 集成化软件开发环境
软件生命周期模型 软件生存期模型是跨越整个生存期的系统开发、 软件生存期模型是跨越整个生存期的系统开发、运 作和维护所实施的全部过程、 作和维护所实施的全部过程、活动和任务的结构框 也称软件过程模型。 架。也称软件过程模型。 软件过程模型体现的是开发策略，并覆盖过程、 软件过程模型体现的是开发策略，并覆盖过程、方 法和工具三个层次。 法和工具三个层次。 软件工程过程模型代表了一种将本质上无序的活动 有序化的企图。 有序化的企图。 • •瀑布模型（线性顺序模型） 喷泉模型 瀑布模型（ 瀑布模型 线性顺序模型） • 并发开发模型 •原型模型 原型模型 • 形式化方法模型 •RAD模型 RAD模型 RAD • 第四代技术 •增量模型 增量模型 • 过程技术 •螺旋模型 螺旋模型
gaoying@ 20
面向对象模型
gaoying@ 21
喷泉模型 维护期 运行状态 实现和集成阶段 实现阶段 面向对象设计阶段 计划阶段 面向对象分析阶段 需求阶段
gaoying@ 22
进一步开发
喷泉模型特点
主要用于支持面向对象开发过程体现了 软件创建所固有的迭代和无间隙的特征。 软件创建所固有的迭代和无间隙的特征。
gaoying@ 15
演化模型
gaoying@ 16
1
增量模型(递增模型) 增量模型(递增模型)
先完成一个系统子集的开发，再按同样的 先完成一个系统子集的开发， 系统子集) 开发步骤增加功能 (系统子集)，如此递增下 去直至满足全部系统需求。 去直至满足全部系统需求。 系统的总体设计在初始子集设计阶段就应 作出设想。 作出设想。
gaoying@ 23
可重用部件组装模型
使用重用技术的软件工程模型 •构件(components): 可重用的软件成份 构件(components): 构件 •可复用性（Reusability） 可复用性（Reusability） 可复用性 （可重用性） 可重用性） •集成化软件开发环境（ISEE） 集成化软件开发环境（ISEE） 集成化软件开发环境
软件生命周期模型
7
迭代模型的优点
• a.任何功能一经开发就能进入测试以便验证是否符合产品需求。 • b.帮助导引出高质量的产品要求。如果没有可能在一开始就弄清楚所有的产品
需求，它们可以分批取得。而对于已提出的产品需求，则可根据对现阶段原型 的试用而作出修改。 • c.风险管理可以在早期就获得项目进程数据，可据此对后续的开发循环作出比 较切实的估算。提供机会去采取早期预防措施，增加项目成功的机率。 • d.大大有助于早期建立产品开发的配置管理，产品构建（build ），自动化测 试，缺陷跟踪，文档管理。均衡整个开发过程的负荷。 • e.开发中的经验教训能反馈应用于本产品的下一个循环过程，大大提高质量与 效率。 • f.如果风险管理发现资金或时间已超出可承受的程度，则可以决定调整后续的 开发，或在一个适当的时刻结束开发，但仍然有一个具有部分功能的，可工作 的产品。 • g.心理上，开发人员早日见到产品的雏型，是一种鼓舞。 • h.使用户可以在新的一批功能开发测试后，立即参加验证，以便提供非常有价 值的反馈。 • i.可使销售工作有可能提前进行，因为可以在产品开发的中后期取得包含了主 要功能的产品原型去向客户作展示和试用。
Desig n
Del iver to cli ent
Implementati on, integr ation
Del iver to cli ent
11
增量模型的优缺点
• 优点
– 短期交付,增量交付 – 现金流量比较低,快速的投资回报 – 并行节省了时间 – 关注核心价值 – 在早期发现软件中的缺陷 – 在早期检验结构的稳定性
Buil d 1:
Speci ficati ons
Desig n
Implementati on, integr ation
迭代模型的优点
• a.任何功能一经开发就能进入测试以便验证是否符合产品需求。 • b.帮助导引出高质量的产品要求。如果没有可能在一开始就弄清楚所有的产品
需求，它们可以分批取得。而对于已提出的产品需求，则可根据对现阶段原型 的试用而作出修改。 • c.风险管理可以在早期就获得项目进程数据，可据此对后续的开发循环作出比 较切实的估算。提供机会去采取早期预防措施，增加项目成功的机率。 • d.大大有助于早期建立产品开发的配置管理，产品构建（build ），自动化测 试，缺陷跟踪，文档管理。均衡整个开发过程的负荷。 • e.开发中的经验教训能反馈应用于本产品的下一个循环过程，大大提高质量与 效率。 • f.如果风险管理发现资金或时间已超出可承受的程度，则可以决定调整后续的 开发，或在一个适当的时刻结束开发，但仍然有一个具有部分功能的，可工作 的产品。 • g.心理上，开发人员早日见到产品的雏型，是一种鼓舞。 • h.使用户可以在新的一批功能开发测试后，立即参加验证，以便提供非常有价 值的反馈。 • i.可使销售工作有可能提前进行，因为可以在产品开发的中后期取得包含了主 要功能的产品原型去向客户作展示和试用。
Desig n
Del iver to cli ent
Implementati on, integr ation
Del iver to cli ent
11
增量模型的优缺点
• 优点
– 短期交付,增量交付 – 现金流量比较低,快速的投资回报 – 并行节省了时间 – 关注核心价值 – 在早期发现软件中的缺陷 – 在早期检验结构的稳定性
Buil d 1:
Speci ficati ons
Desig n
Implementati on, integr ation
软件工程(概论)生存期和开发模型-作业2
发散性传播的原理，所以逆转将会延误工期，增加成本，造成重大损失。
2.3 软件开发模型
4．模型的优点 开发阶段清晰，便于评审、审计、跟踪、管理和控制。
5．模型的缺点 传统的项目组织方法是按顺序完成每个工作流程，即瀑布式生命周期。瀑布
只能一个个台阶地往下流，不可能倒着往上流，这就是它致命的缺点。 瀑布式生命周期通常会导致在项目后期，出现“问题堆积”，更可怕的是，错
一阶段（活3）动用的户输使入用，环继境续很进稳行定下；一阶段的活动，否则返回上一阶段修改。 （4）用户除提出需求以外，很少参与开发工作。
2．模瀑型布的模特型点认为：项目经理或软件管理人员，只要控制好每级台阶的高度 （和1宽）度里，程在碑每或个基台线阶驱处动设，立或里者程说碑文或档基驱线动，；并组织好对基线的评审与审 （计2，）就过可程以逆控转制性好很项差目或的者开说发不成可本逆、转进，度因和为质根量据。上游的错误会在下游进行
误的传递会采取发散扩大的方式。
瀑布模型反馈环
CMM/CMMI采取阶段评审和不符合项(Noncompliance Items)的动态跟踪制度， 只有前一阶段不符合项全部改正，才允许开发人员进入后一阶段工作。
不符合项，就是在评审中发现的问题项，它不同于Bug。对于这些不符合项，软 件管理部门要列出表格，记录在案，确定责任人，限定改正时间，动态跟踪到底 。
可行性研究的结果是负责人作出是否继续进行这项工程的决定的重要依据。 可行性研究以后的各个阶段，将需要投入多少相应的人力物力。 及时终止不值得投资的工程项目，可以避免更大的浪费。
2.2 软件工程过程
3. 需求分析
这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须 具备哪些功能。产生《需求规格说明书》。
2.3 软件开发模型
4．模型的优点 开发阶段清晰，便于评审、审计、跟踪、管理和控制。
5．模型的缺点 传统的项目组织方法是按顺序完成每个工作流程，即瀑布式生命周期。瀑布
只能一个个台阶地往下流，不可能倒着往上流，这就是它致命的缺点。 瀑布式生命周期通常会导致在项目后期，出现“问题堆积”，更可怕的是，错
一阶段（活3）动用的户输使入用，环继境续很进稳行定下；一阶段的活动，否则返回上一阶段修改。 （4）用户除提出需求以外，很少参与开发工作。
2．模瀑型布的模特型点认为：项目经理或软件管理人员，只要控制好每级台阶的高度 （和1宽）度里，程在碑每或个基台线阶驱处动设，立或里者程说碑文或档基驱线动，；并组织好对基线的评审与审 （计2，）就过可程以逆控转制性好很项差目或的者开说发不成可本逆、转进，度因和为质根量据。上游的错误会在下游进行
误的传递会采取发散扩大的方式。
瀑布模型反馈环
CMM/CMMI采取阶段评审和不符合项(Noncompliance Items)的动态跟踪制度， 只有前一阶段不符合项全部改正，才允许开发人员进入后一阶段工作。
不符合项，就是在评审中发现的问题项，它不同于Bug。对于这些不符合项，软 件管理部门要列出表格，记录在案，确定责任人，限定改正时间，动态跟踪到底 。
可行性研究的结果是负责人作出是否继续进行这项工程的决定的重要依据。 可行性研究以后的各个阶段，将需要投入多少相应的人力物力。 及时终止不值得投资的工程项目，可以避免更大的浪费。
2.2 软件工程过程
3. 需求分析
这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须 具备哪些功能。产生《需求规格说明书》。
第2章 软件生存期模型
➢ 每个构件由多个相互作用的模块构成，并且能够 完成特定的功能。
2.3 增量模型
➢ 增量模型如图所示。
2.3 增量模型
• 增量模型的优点
(1)能在较短时间内向用户提交可完成一些有用的工作产品， 即从第1个构件交付之日起，用户就能做一些有用的工作。
(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适 应新产品，从而减少一个全新的软件可能给用户组织带来 的冲击。
在维护和开发之间并没有本质区别。
2.4 螺旋模型
• 螺旋模型的缺点
➢ 螺旋模型是风险驱动的，因此要求软件开发人员 必须具有丰富的风险评估经验和这方面的专门知 识，否则将出现真正的风险：当项目实际上正在 走向灾难时，开发人员可能还以为一切正常。
2.4
➢ 多数场合，软件开发过程是沿螺旋线的路径连 续进行的。
2.6 统一过程
• 统一过程的阶段
③ 构造阶段。构造阶段是建立系统，构造信息系统 的第1个具有操作质量的版本，以能够交付给客户 进行测试的版本结束，有时称为测试版本。
④ 移交阶段。移交阶段包含测试时期，以发布完 整的系统而终止，其目标是确保信息系统真正满 足客户的需求。
2.6 统一过程
• 主要工作产品
➢ 原型建造模型和螺旋模型既是迭代模型，又是进 化模型。
➢ 实践中，客户利用迭代或增量模型尽快开发第一 个版本的软件制品，占领市场的有利商机，然后 再逐步扩展系统功能，不断推出后续版本。
2.5 喷泉模型
• 喷泉模型是典型的面向 对象生命周期模型。
➢ “喷泉”一词体现了迭 代和无间隙特性。图中 代表不同阶段的圆圈相 互重叠，这明确表示两 个活动之间存在重叠。
2.3 增量模型
• 采用增量模型需注意的问题
2.3 增量模型
➢ 增量模型如图所示。
2.3 增量模型
• 增量模型的优点
(1)能在较短时间内向用户提交可完成一些有用的工作产品， 即从第1个构件交付之日起，用户就能做一些有用的工作。
(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适 应新产品，从而减少一个全新的软件可能给用户组织带来 的冲击。
在维护和开发之间并没有本质区别。
2.4 螺旋模型
• 螺旋模型的缺点
➢ 螺旋模型是风险驱动的，因此要求软件开发人员 必须具有丰富的风险评估经验和这方面的专门知 识，否则将出现真正的风险：当项目实际上正在 走向灾难时，开发人员可能还以为一切正常。
2.4
➢ 多数场合，软件开发过程是沿螺旋线的路径连 续进行的。
2.6 统一过程
• 统一过程的阶段
③ 构造阶段。构造阶段是建立系统，构造信息系统 的第1个具有操作质量的版本，以能够交付给客户 进行测试的版本结束，有时称为测试版本。
④ 移交阶段。移交阶段包含测试时期，以发布完 整的系统而终止，其目标是确保信息系统真正满 足客户的需求。
2.6 统一过程
• 主要工作产品
➢ 原型建造模型和螺旋模型既是迭代模型，又是进 化模型。
➢ 实践中，客户利用迭代或增量模型尽快开发第一 个版本的软件制品，占领市场的有利商机，然后 再逐步扩展系统功能，不断推出后续版本。
2.5 喷泉模型
• 喷泉模型是典型的面向 对象生命周期模型。
➢ “喷泉”一词体现了迭 代和无间隙特性。图中 代表不同阶段的圆圈相 互重叠，这明确表示两 个活动之间存在重叠。
2.3 增量模型
• 采用增量模型需注意的问题
第二讲软件生命周期模型
3、软件运行和维护
在软件运行期间，当发现了软件中潜藏的错误或需要增 加新的功能或使软件适应外界环境的变化等情况出现时 对软件进行修改。
软件生存周期的作用?(思考) 软件生存周期的作用?(思考) ?(思考
图1
软件开发的各阶段的成本比例
二、软件生存周期模型（SLCM SLCM）（1/4 1/4） SLCM 1/4
• 从表1中可以看出，错误发现的越晚，排除错误所花的代价越大。 。 需求分 析 10%-10%-20% 软件设 计 50% 程序编 码 100% 单元测 试 200% 验收测 试 500% 维护 2000% 阶段 相对修复 代价
表1 错误发现阶段与修复代价间的关系
二、软件生存周期模型（续）
瀑布模型的适用情况： 瀑布模型一般是用于结构化开发，前一阶段的输出是后 一阶段的输入。 随着软件开发和管理的不断发展，瀑布 模型就不太适用所有软件的开发。现在面向对象软件开 发要多于结构化开发，采用迭代型、增量型、螺旋型。 在瀑布模型模型中增加迭代应该是一种比较适用的方法 1.需求是预知的 2.软件实现方法是成熟的 3.项目周期较短
二、软件生存周期模型（续）
2、快速原型SLCM（PSLCM：特点： 快速 特点：
a. 强调尽早建立可工作的系统原型； b. 强调迭代的处理过程。
听取用户意见 建造/修改原型
用户评价原型
图4 快速原型模型
二、软件生存周期模型（续）
2、快速原型SLCM（PSLCM）（80s中期）
优点： 优点：
a.为用户提供了可供讨论的真实系统； b.保证了新系统主体的正确性； c.促进了用户和开发者的合作。
缺点： 缺点：
a. 开发过程难以管理和控制； b. 对大型系统难以建立原型； c. 需要强大、灵活的硬件和软件支持。 d: 原型实现模型的缺点是产品原型在一定程度上限制了 开发人员的创新，没有考虑软件的整体质量和长期的 可维护性。由于达不到质量要求产品可能被抛弃。 原型模型不适用于嵌入式 、数值处理、实时控制
软件工程的开发模型
运营,维护
图 2-12 软件重用模型
14
构件集成模型
图 2-13
顾客通信 顾客评估
计划
风险分析
候选构件
进行下一次 迭代
在构件库中 查找构件
提取构件
是
将新构件 存入库中
是否存在 构件？
否
15
产品开发与公布
智能模型
获取 需求
需求分析
详细描述
验证
维护
优化
程序
调整
图 图2-124-9智智能能模模型型
知识库/ 教授系统/
规格阐明 可运营原型
原型评价
最终系统设计
最终系统实现
图2-7 迅速原型模型
8
原型模型旳种类: 抛弃式原型、进化式原型、可操作式原型
计划 需求分析
设计 编码 测试 运营
计划 需求分析
设计 编码 测试 运营
计划 需求分析
设计 编码 测试 运营
图 2-8 进化式原型
9
操作模型 (Operational Model)
16
小结
软件开发模型是 软件开发全过程、活 动、任务旳构造框架
软件生命周期各个 阶段及各阶段旳任务
软件开发模型： 瀑布模型-懂得做什么 原型模型-迅速开发 增量模型-并行开发 螺旋模型-风险驱动 喷泉模型-重用
各模型优点、缺陷
17习题Biblioteka 1. 什么是软件旳生命周期？ 2. 软件生命周期分哪几种阶段？各阶段旳任务是
第2章 软件开发模型
软件工程研究室
1
基本内容
系统开发生命周期 软件开发生命周期模型
目旳: 指导软件开发旳全过程
2
2.1 系统开发生命周期
《软件工程》课件 第二章-软件生存周期及模型
模型适合的项目：
项目开始，明确了需求的大部分，但是需
求可能会发生变化
对于市场和用户把握不是很准，需要逐步
了解
对于有庞大和复杂功能的系统进行功能改
进，就需要一步一步实施的。
银行业务系统的生存期实例
项目规划
．银行业务需求 ．原形系统源代码 业务需求分析 产品阶段1设计 项目规划
产品阶段n设计
加工原型 客户评价原型
建造原型
原型开发过程
▲快速分析：分析人员与用户配合，迅速确定系统的基 本要求。要根据原型所要体现的特征，描述基本需求。 关键是要注意分析描述内容的选取。 ▲构造原型：在软件工具支持下尽快实现一个可运行的 系统。 ▲运行原型：是发现问题、消除误解、开发者与用户充 分协调的一个步骤。 ▲评价原型：评价原型的特性，纠正误解与错误，增添 新要求或提出要求变动，提出全面的修改意见。 ▲修改：原型开发的循环。
确认系统
把软件产品分解成一系列的增量构件，在增量开发迭代 中逐步加入。
每个构件由多个相互作用的模块构成，并且能够完成特
定的功能。 增量开发方法的新演进版本叫做 “极限程序设计 （eXtreme Programming）”。
增量模型
第一增量 第二增量 第三增量
……
核心功能
核心功能
核心功能
1
1
2
V模型:瀑布模型的细化－－对测试的展开
适合的项目
项目的需求在项目开始前很明确
解决方案在项目开始前也很明确
对系统的性能安全很严格的项目 类似的项目如：
航天飞机等 公司的财务系统
2.增量模型
定义 基本需求
将需求赋予 增量构件
软件生命周期模型
A 快速迭代
敏捷开发采用短周期的迭代方式进 行开发，每个迭代周期结束都能交
付可运行的软件。
B
C
D
持续改进
敏捷开发注重持续改进和优化，通过每个 迭代周期的反馈来不断完善软件产品。
自我组织团队
敏捷开发要求团队成员具备自我组织能力， 能够自主安排工作进度和任务分配。
敏捷开发模型适用场景
需求变化快
当需求变化较快时，敏捷开发能够快速适应 变化并满足客户需求。
03
• 对于小型简单系统可能过于复 杂，成本较高。
04
04 迭代模型
迭代模型定义
• 迭代模型是一种软件开发过程模型，它将整个软件开发过程划分为一系列迭代 阶段。在每个迭代阶段，开发团队会根据预先设定的需求和目标，进行需求分 析、设计、编码、测试等工作，并逐步构建和改进软件系统。
迭代模型特瀑布模型
顺序且线性的开发过程，强调文 档和需求分析的重要性，适用于 需求稳定、变更较小的项目。
迭代模型
开发过程反复进行，逐步完善， 强调需求调研、系统架构设计和 早期测试。
敏捷开发模型
快速响应变化，强调团队合作、 客户需求和迭代开发，适用于需 求变化快、产品复杂度高的项目。
软件生命周期模型
目 录
• 软件生命周期模型概述 • 瀑布模型 • 螺旋模型 • 迭代模型 • V模型
01 软件生命周期模型概述
定义与特点
定义
软件生命周期模型描述了软件开发和 演进的全过程，包括从需求分析、设 计、编码、测试到维护和支持等阶段 。
特点
软件生命周期模型强调软件开发过程 中的整体性和阶段性，有助于确保软 件质量、控制开发成本和合理分配资 源。
需求明确
迭代模型强调在不断迭代中 完善软件，每个迭代周期都 实现部分功能，并在后续迭
软件工程各章节重要知识点按考试大纲总结
软件工程各章节重要知识点按考试大纲总结LELE was finally revised on the morning of December 16, 20202014软件工程各章节重点知识点（按考试大纲总结）第1章：软件工程的范畴THE SCOPE OF SOFTWARE ENGINEERING1掌握软件工程、软件危机、生命周期的概念 1%Software engineering is a discipline学科 aim is the production生产 of software.fault-free;delivered on time ;within budget;satisfies the client’s needs;be easy to modify when the needs changeSoftware crisis:the quality of software was unacceptably low,deadlines and budgets were not being met.Life-cycle model:The steps to follow遵循 when building构建 software,A theoretical description理论描述 of what should be done.Life cycle:The actual steps实际步骤 performed执行 on a specific具体 product.2掌握维护的3种分类并能够结合具体例子进行判断 1%Postdelivery maintenance:Corrective纠错性 maintenance;Perfective完善性maintenance;Adaptive适应性 maintenanceCorrective纠错性 maintenance:removal去除 of residual faults残留错误 ;leaving the specifications规格说明文档 unchangedPerfective完善性 maintenance:additional functionality额外功能;decreased response time减少响应时间Adaptive适应性 maintenance:changes made in response to changes in the environment3掌握为什么没有计划、文档和测试阶段 1%Why There Is No Planning Phase计划阶段, Testing Phase测试阶段 or Documentation Phase文档阶段?Planning, continual持续的 testing and documentation activities活动 are carried out执行throughout贯穿于 the life cycle.There is no separate独立的 planning, testing or documentation phase.This testing is the responsibility职责 ofEvery software professional专业人员, and The software quality assurance group软件质量保证小组(SQA group)Documentation Must Always be Current:Key individuals may leave before the documentation is complete.We cannot perform a phase without having the documentation of the previous phase.We cannot test without documentation.We cannot maintain without documentation.4掌握软件工程的传统生命周期模型（瀑布模型）的阶段划分和各阶段的主要任务1%Classical(Waterfall瀑布) Life-Cycle Model1. Requirements phaseExplore研究 the concept概念;Elicit提取 the client’s requirements客户需求2. Analysis (specification) phaseAnalyze分析 the client’s requirements;Draw up制定 the specification document规格说明文档(specifications);Draw up the software project management plan软件项目管理计划(SPMP);“What the product is supposed期望 to do”3. Design phaseArchitectural design结构设计, followed by;Detailed design详细设计;“How the product does it”4. Implementation phaseCoding编码;Unit testing单元测试;Integration集成;Acceptance testing验收测试5. Postdelivery maintenanceCorrective纠错性 maintenance;Perfective完善性 maintenance;Adaptive适应性 maintenance6. Retirement5掌握传统的维护观念与现代的维护观念之间的区别1%Classical maintenance is Development-then-maintenance model开发-维护模型This is a temporal时间性 definition,Classification归类 as development or maintenance depends on取决于 when an activity is performed.Modern Maintenance is nowadays defined as:The process过程 that occurs when a software artifact软件制品 is modified被修改 because of a problem or because of a need for improvement改善 or adaptation适应.Maintenance occurs whenever software is modified修改.Regardless of不管 whether this takes place before or after installation of the software product.Modern maintenance is corrective, perfective, or adaptive maintenance performed at any time.第2章：软件生命周期模型SOFTWARE LIFE-CYCLE MODELS1 掌握编码-修补模型、瀑布模型、快速原型开发模型、开源模型、敏捷过程模型、同步-稳定模型、螺旋模型等这些模型的模型图（如果有图的话）以及优缺点和适用场合，并能绘制。
第二章软件生命周期过程
9.软件合格测试：制定并执行确认测试计划，检查测试的 覆盖程度，测试的结果是否符合预期结果。
10.系统集成：将交付的软件与整个系统中的其它软件进行 集成。
11.系统合格测试 12.软件安装 13.验收支持：支持获取者对软件的验收评审和测试（需要
提供培训）。
2.2.4 运行过程
过程执行者：用户和操作人员（为了使系 统或产品投入运行而在用户的业务运行环 境中进行的一系列有关的活动）
R(apid)A(pplication)D(evelopment)
有以下步骤:
#1小组
(1)业务模型：以什么信息驱动业务过程运
作? 要生成什么信息? 谁生成它? 数据流图。
(2)数据模型：为支持业务过程的数据流， 找数据对象集合,定义数据对象属性,与其 它数据对象的关系构成数据模型，可辅之 以E-R图。
1、软件生命周期：指软件产品从考虑其 概念开始，到该软件产品不再能使用为止 的整个时期。
一般包括：概念阶段、需求阶段、设计阶 段、实现阶段、测试阶段、安装阶段以及 交付使用阶段、运行阶段和维护阶段。有 时还有退役阶段。
这些阶段可以有重复，执行时也可以有迭 代。
2.1.1 软件生命周期定义
2、软件开发生命期：指软件产品从考虑 其概念开始到该软件产品交付使用为止的 整个时期。
软件过程的规划由不同开发机构针对不同应用项目确定， 包括一些有组织的活动：1)对用户的要求（need）进行 分析、2)解释成软件需求（requirement）、3)把需求变 换成设计、4)把设计用代码来实现、5)测试该代码，5)有 时还要进行代码安装和把软件交付运行使用。进一步可 以抽象为： 1.软件规格说明：规定软件的功能及其运行限制； 2.软件开发：产生满足规格说明的软件； 3.软件确认：确认软件能够完成客户提出的要求； 4.软件演进：为满足客户的变更要求而进行演进。
10.系统集成：将交付的软件与整个系统中的其它软件进行 集成。
11.系统合格测试 12.软件安装 13.验收支持：支持获取者对软件的验收评审和测试（需要
提供培训）。
2.2.4 运行过程
过程执行者：用户和操作人员（为了使系 统或产品投入运行而在用户的业务运行环 境中进行的一系列有关的活动）
R(apid)A(pplication)D(evelopment)
有以下步骤:
#1小组
(1)业务模型：以什么信息驱动业务过程运
作? 要生成什么信息? 谁生成它? 数据流图。
(2)数据模型：为支持业务过程的数据流， 找数据对象集合,定义数据对象属性,与其 它数据对象的关系构成数据模型，可辅之 以E-R图。
1、软件生命周期：指软件产品从考虑其 概念开始，到该软件产品不再能使用为止 的整个时期。
一般包括：概念阶段、需求阶段、设计阶 段、实现阶段、测试阶段、安装阶段以及 交付使用阶段、运行阶段和维护阶段。有 时还有退役阶段。
这些阶段可以有重复，执行时也可以有迭 代。
2.1.1 软件生命周期定义
2、软件开发生命期：指软件产品从考虑 其概念开始到该软件产品交付使用为止的 整个时期。
软件过程的规划由不同开发机构针对不同应用项目确定， 包括一些有组织的活动：1)对用户的要求（need）进行 分析、2)解释成软件需求（requirement）、3)把需求变 换成设计、4)把设计用代码来实现、5)测试该代码，5)有 时还要进行代码安装和把软件交付运行使用。进一步可 以抽象为： 1.软件规格说明：规定软件的功能及其运行限制； 2.软件开发：产生满足规格说明的软件； 3.软件确认：确认软件能够完成客户提出的要求； 4.软件演进：为满足客户的变更要求而进行演进。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
敏捷过程
原则
不强调分析和设计 很早开始实现的工作，认为能工作的软件远比文档重要 对变更能快速响应 与客户的紧密协作
特点
频繁提交软件版本，理想情况是每2到3周提交一次 站立会议（为了缩短开会时间），成员一次回答
从昨天的会议到现在，我做了什么？ 今天我要做什么？ 完成今天的工作将遇到什么问题？ 我们忘记了什么？ 我可以与小组成员分享的经验是什么？
软件产品是现实世界的反应，而现实世界是不断变化的 软件专业人员是人，会出错
2.4 野鸭拖拉机公司小型实例研究
公司的业务拓展到加拿大 需要做下列变化
新的销售区域要添加进来 软件要能够处理例如加拿大税率等相关的业务问题 软件要能够处理不同的货币，例如美元和加元
变更影响
有利于公司 但是对于软件开发来讲，造成了很大的麻烦
早期可见的进展 早期反馈，用户参与调整，会更接近用户需求 可控复杂性；团队不会被长期且复杂的步骤所淹没 一次迭代中的经验可以被系统的用于改进开发过程 本身，并反复进行下去
Hale Waihona Puke 代-递增模型的优点CHAOS （Standish）1994 - 2004
Figure 2.7
2.8 其他生命周期模型
外围小组
用户选择不时的提交缺陷报告
2.8.5敏捷过程（Agile Processes）
是一种颇有有争议的新的软件开发方法 情节（客户期望的特性）
评估每个特性所需要的时间和费用 使用成本-效益分析方法选择下一次要构造的特性 每一个特性分成更小的任务 首先制定出任务的测试用例
结对编程（两个程序员在一台计算机前一起工作） 任务的连续集成（结对的程序员并行地实现任务） 每天更换小组成员的编码同伴； 各任务所使用的测试用例保留下来并应用到所有进一 步的集成测试中
需求流 分析流 设计流 实现流 测试流 ( Requirements workflow ） (Analysis workflow) (Design workflow) (Implementation workflow) (Test workflow)
工作流
五个核心工作流在软件产品的整个生命周期中进行
迭代和递增
每个迭代可以看作是一个较小但是完整的瀑布模型 每次迭代均选择了软件产品的某一个特定部分，经 历了
传统的需求阶段 传统的分析阶段 传统的设计阶段 传统的实现阶段
迭代-递增模型的优点
减少项目失败可能性，提高生产率，降低缺陷率 在早期（而不是晚期）缓解高风险（技术、需求、 目标、可用性等）
第1幕 : 软件第1版实现 第2幕: 存在问题
产品对美元图像的识别响应时间没有达到要求 开始着手更改
第3幕: 新设计被采用
快速算法
第4幕: 需求变化
准确度已经被提升
结尾: 几年以后，这些问题重现
进化树生命周期模型
Winburg 小型案例
Figure 2.2
进化树生命周期模型
Figure 2.12
完整的螺旋生命周期模型
每一阶段确定目标
可选择办法 风险分析限制条件
每一阶段后
评估目标策略 下一阶段的计划
径坐标代表迄今累积的成本 角坐标代表螺旋形的进展
螺旋模型
风 险 驱 动 是 长 处 也 是 短 处
Figure 2.13
螺旋模型
优点
支持重用现有软件，把软件质量作为特定的目标结合其中 螺旋模型能根据测试时间太多或太少带来的风险来确定什 么时候已经对某一阶段的产品充分测试完毕 开发与交付后维护无明显区别
表达出了事件的顺序 在每一幕的结束
有一个基线，一个完成的制品集
举例
在第3慕结尾:
Requirements1, Analysis1, Design3, Implementation3
2.3 Winburg 小型实例研究心得
实践中，其它项目的软件开发会比Winburg 小型实 例更为混乱无序 改变总是存在
编码—修补生命周期模型 瀑布生命周期模型 快速原型开发生命周期模型 开源生命周期模型 敏捷过程 同步—稳定生命周期模型 螺旋生命周期模型
2.8.1编码—修补生命周期模型
缺乏需求、分析和设计； 对于小程序可以操作很好； 对于一定规模的软件可能导致开 销增大； 常见于以代码行唯一度量项目进 展的组织内； 是最简单的软件开发方式，也是 最糟糕的方式； 应在开发之前，选择一个合适的 生命周期模型
风险驱动 只能用于大型的内部软件产品，开 发者必须精通风险分析和风险排除
Figure 2.14
作业
P44
2.1, 2.3, 2.4, 2.5, 2.6
The End
Thank you!
野鸭拖拉机公司需求变更问题
需求变更可能造成软件的回归错误 需求变更可能造成整个软件产品重新设计，重新实 现 需求变更是不可避免
对于需求变更，没有很好的办法
移动目标问题
2.5 迭代和递增
在实际中，谈论独立的“分析阶段”没有太多意义
分析阶段的操作散布在生命周期的各个阶段
软件开发的基本过程是迭代的
螺旋模型
缺点
只适合大规模软件 内部开发，开发者和用户是同一组织 必须是小组成员能够胜任风险分析时才能使用 如果风险分析的成本和整个项目成本相当，或者进行风险 分析会大大影响潜在的收益，则没有必要进行风险分析
螺旋模型的主要缺点与瀑布模型和快速原型开发模型一样，在 于它假定软件是在各个分离的阶段开发的
第2章
软件生命周期模型
目录
理论上的软件开发 Winburg 实例研究 野鸭拖拉机公司小型实例研究 迭代和递增 其他生命周期模型 生命周期模型的比较
2.1理论上的软件开发
理论上：
线性 由零开始
实践中：
错误 客户需求会发生变换
Figure 2.1
2.2 Winburg 小型案例研究
通过互联网提供下载(e.g., ) 接着, 如果有人感兴趣 初始版本被下载 合作开发 产品被扩展
第二阶段的活动
报告并纠正缺陷（纠正性维护） 增加额外的功能（完善性维护） 移植软件到新的环境（适应性维护） 第二阶段仅仅包括交付后维护（“co-developers” 更应 该称为“co-maintainers）
螺旋模型
软件开发中存在各种风险 构建原型是最小化某些类型风险的一个途径 概念证明原型 通过使用原型或其他方法最小化风险是螺旋生命周 期模型中蕴含的概念 可简单地将简版螺旋生命周期模型看作是每个阶段 之前带有风险分析的瀑布模型 原型可提供关于某类风险的信息，但原型不能完全 解决问题
敏捷过程
极限编程XP是敏捷过程范型中的一个 2001年2月17个软件开发者（后来称为敏捷联盟）提 出了“Manifesto for Agile Software Development”，与 会者分享了自己的软件开发方法，包括XP, Crystal， Scrum等 严格来讲，不是特定的生命周期模型，只是推出一组 根本的原则，对于他们个人的软件开发方法通用。
敏捷过程
已在一些小型项目中得到成功应用，但对于大型项 目，一般并不适用
搭积木做狗窝 做高层商品房
适用于需求模糊和变更频繁的情况 交付后软件维护成本可能很大 现在做一个全面的评估，为时尚早
2.9.6同步—稳定模型
Microsoft’s 生命周期模型 潜在客户会谈 提取出对顾客具有最高优先级的特性列表，拟制规格说明文档 划分为3-4个构件，第一个构件包含最重要的特性，第二个构件 包含次重要的特性 每个构件由小组并行开发 工作同步，每天将所有组件集成在一起进行测试和调试得到的 产品 稳定化，在组件开发结束时进行，检测遗留差错并修改，然后 冻结，即规格说明不再修改，同步步骤保证各个组件总能一起 工作。
2.8.4 开源生命周期模型
不开源的软件由拥有该软件的公司雇员小组进行维 护和测试
用户可以提交故障（failure）报告，但因为没有源码，不 能提交缺陷（fault）报告
开源软件由不拿报酬的志愿者维护
鼓励用户提交故障报告和缺陷报告
核心小组
提交缺陷报告 管理开源项目 负责纠正缺陷
开源运动的格言是“尽早发 布、经常发布”；
Figure 2.8
2.8.2瀑布生命周期模型
把软件开发过程划分成若干阶段 ，每个阶段的任务相对独立; 在软件生存期的每个阶段都采用 科学的管理技术和良好的方法与 技术。每个阶段结束之前，都从 技术和管理两个角度进行严格的 审查，经确认之后才开始下一阶 段的工作。 瀑布模型是文档驱动的，各个阶 段不交叉。 客户只能在整个产品完成编程后 才首次看到能够工作的产品缺乏 需求、分析和设计。
Figure 2.4
2.5 迭代和递增
迭代和递增相互结合使用
没有单独的需求和设计阶段 存在多个阶段的实例
Figure 2.2 (again)
传统阶段（Classical Phases ）和 工作流（Workflows）之间的关系
理想化的过程链，连续的阶段在现实中并不存在 在整个生命周期中存在五个核心工作流
短处
迭代-递增生命周期模型 编码-修补生命周期模型 瀑布生命周期模型 快速原型开发生命周期 模型 开源生命周期模型 敏捷过程