第2章软件生命周期模型PPT课件
合集下载
第二章 软件生存周期与软件过程_PPT幻灯片
4. 采用增量模型比采用瀑布模型和快速原型 模型需要更精心的设计，但在设计阶段多 付出的劳动将在维护阶段获得回报。
2.3.2螺旋模型(Spiral Model)
螺旋模型为目前软件开发中最常 用的软件快发模型，是在结合瀑布模 型与快速原型模型基础上演变而成的， 尤其适用于大型软件的开发。
1.典型的迭代模型
验证
风险分析 设计 验证
风险分析 编码 测试
风险分析 综合测试
简化的螺旋模型
维护
可看作在每个 优点 –对可选方案和约束条件的强调有利于 已有软件的重用，也有助于把软件质 量作为软件开发的一个重要目标； –减少了过多测试或测试不足； –维护和开发之间并没有本质区别。
• ……
原型模型可能是最好的选择
2.3软件演化周期
2.3 软件演化模型
原型开发模型的出现，使人们 逐渐熟悉非线性的开发模型。随着 软件规模的不断增长，复杂软件开 始采用渐增式或迭代式的开发方式 。于是，一种称为演化模型（ evolutionary mode）的渐进式的开 发模型应运而生。
2.3.1 增量模型（渐增模型） (Incremental Model)
交付客房
增量模型图
增量模型的优点
1. 在较短时间内向用户提交可完成部分工作 的产品，并分批、逐步地向用户提交产品。 从第一个构件交付之日起，用户就能做一 些有用的工作。
2. 整个软件产品被分解成许多个增量构件， 开发人员可以一个构件一个构件地逐步开 发。
3. 逐步增加产品功能可以使用户有较充裕的 时间学习和适应新产品，从而减少一个全 新的软件可能给客户组织带来的冲击。
2.1软件生存周期
2.1 软件生存周期
一切的工业产品都有自己的生 存周期,软件(产品)也不例外。一个 软件从开始立项起，到废弃不用止， 统称为软件的生存周期（life cycle）。
2.3.2螺旋模型(Spiral Model)
螺旋模型为目前软件开发中最常 用的软件快发模型，是在结合瀑布模 型与快速原型模型基础上演变而成的， 尤其适用于大型软件的开发。
1.典型的迭代模型
验证
风险分析 设计 验证
风险分析 编码 测试
风险分析 综合测试
简化的螺旋模型
维护
可看作在每个 优点 –对可选方案和约束条件的强调有利于 已有软件的重用，也有助于把软件质 量作为软件开发的一个重要目标； –减少了过多测试或测试不足； –维护和开发之间并没有本质区别。
• ……
原型模型可能是最好的选择
2.3软件演化周期
2.3 软件演化模型
原型开发模型的出现，使人们 逐渐熟悉非线性的开发模型。随着 软件规模的不断增长，复杂软件开 始采用渐增式或迭代式的开发方式 。于是，一种称为演化模型（ evolutionary mode）的渐进式的开 发模型应运而生。
2.3.1 增量模型（渐增模型） (Incremental Model)
交付客房
增量模型图
增量模型的优点
1. 在较短时间内向用户提交可完成部分工作 的产品，并分批、逐步地向用户提交产品。 从第一个构件交付之日起，用户就能做一 些有用的工作。
2. 整个软件产品被分解成许多个增量构件， 开发人员可以一个构件一个构件地逐步开 发。
3. 逐步增加产品功能可以使用户有较充裕的 时间学习和适应新产品，从而减少一个全 新的软件可能给客户组织带来的冲击。
2.1软件生存周期
2.1 软件生存周期
一切的工业产品都有自己的生 存周期,软件(产品)也不例外。一个 软件从开始立项起，到废弃不用止， 统称为软件的生存周期（life cycle）。
第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 增量模型
• 采用增量模型需注意的问题
第二章软件生命周期过程ppt课件
目的：使软件过程和软件产品符合规定的质量要求。 要求：实施质量保证的人员不能是直接负责软件产品开
发的人员，并应在组织上给予独立的权限。 内容：
软件产品质量保证：保证产品及其相关文档与合同的要求一致。 软件过程质量保证：保证软件开发过程按合同要求的计划完成。
保证开发单位的软件工程支持按合同要求完成。 保证开发环境、测试环境及资料等与合同要求一致。 保证软件度量符合所建立的标准和步骤。 保证项目组成员接受必要的培训以达到软件开发必需的知识和技
对于大型项目而言，事先不能完整清晰地 定义需求是常事，而且开发一个原型是远 远不能解决问题的，需要开发内容逐步丰 富的多个原型。
大型项目的规模和复杂性增加，软件开发 过程中必然存在着许多风险问题，风险分 析是保证项目成功的必要手段。
2021/8/12
精选课件ppt
17
2.1.2.3 螺旋模型
2021/8/12
2021/8/12
精选课件ppt
4
2.1.1 软件生命周期定义
软件开发生命期：指软件产品从考虑其概念开 始到该软件产品交付使用为止的整个时期。
一般包括：概念阶段、需求阶段、设计阶段、实现 阶段、测试阶段、安装阶段，以及交付阶段。
这些阶段可以有重叠，执行时也可以有迭代。
2021/8/12
精选课件ppt
运行过程 用户
运行准备；运行测试；产品转移；运行；运行支持；运 行评价。
维护过程 维护人员 过程实施准备；问题分析和修改设计；修改实施；对维 护的评审和验收；软件移植；软件退役。
2021/8/12
精选课件ppt
28
2.3 支持过程
定义：为了提供系统或软件产品的质量而在软 件基本过程的各个活动中使用的支持手段。
发的人员，并应在组织上给予独立的权限。 内容：
软件产品质量保证：保证产品及其相关文档与合同的要求一致。 软件过程质量保证：保证软件开发过程按合同要求的计划完成。
保证开发单位的软件工程支持按合同要求完成。 保证开发环境、测试环境及资料等与合同要求一致。 保证软件度量符合所建立的标准和步骤。 保证项目组成员接受必要的培训以达到软件开发必需的知识和技
对于大型项目而言，事先不能完整清晰地 定义需求是常事，而且开发一个原型是远 远不能解决问题的，需要开发内容逐步丰 富的多个原型。
大型项目的规模和复杂性增加，软件开发 过程中必然存在着许多风险问题，风险分 析是保证项目成功的必要手段。
2021/8/12
精选课件ppt
17
2.1.2.3 螺旋模型
2021/8/12
2021/8/12
精选课件ppt
4
2.1.1 软件生命周期定义
软件开发生命期：指软件产品从考虑其概念开 始到该软件产品交付使用为止的整个时期。
一般包括：概念阶段、需求阶段、设计阶段、实现 阶段、测试阶段、安装阶段，以及交付阶段。
这些阶段可以有重叠，执行时也可以有迭代。
2021/8/12
精选课件ppt
运行过程 用户
运行准备；运行测试；产品转移；运行；运行支持；运 行评价。
维护过程 维护人员 过程实施准备；问题分析和修改设计；修改实施；对维 护的评审和验收；软件移植；软件退役。
2021/8/12
精选课件ppt
28
2.3 支持过程
定义：为了提供系统或软件产品的质量而在软 件基本过程的各个活动中使用的支持手段。
《软件工程》第2课 软件生存周期与软件过程PPT幻灯片
6.软件可行性研究
• 目的
–研究项目是否可能实现和值得进行。
• 研究的内容
–经济可行性 –技术可行性 –运行可行性 –法律可行性
可行性研究的步骤
• 对当前系统进行调查和研究
– 弄清当前系统 – 导出新系统逻辑模型
• 导出新系统的解决方案
– 设计不同的解决方案
• 提出推荐的方案
– 本项目的开发价值 – 推荐这个方案的理由
形式化开发记录 变换n
形式化 规格说明
系统需求
变换2 变换1
测试 目标系统
净室模型
• 净室思想
–在分析和设计阶段消除错误。 –在“洁净”状态下实现软件制作。
• 增量模型
–把软件看成一系列的增量。
• 形式化
–每一个增量用形式化表示—盒，表示分析和 设计。
–正确性验证。
净室模型
盒结构 形式化 正确性 代码生成
• 编写可行性论证报告
– 系统概述 – 可行性分析 – 结论意见
软件风险分析
• 软件开发存在风险。 • 风险识别
–项目风险（进度、人力、资源、客户） –技术风险（设计、实现、接口、维护） –商业风险（市场、策略、推销）
• 建立风险项目检测表
–产品规模 –商业影响 –客户关系 –人员 –技术
例：人员配备风险检测表
5. 统一过程和敏捷过程
• 统一过程
–Rational Unified Process（RUP）描述了软 件开发中各个环节应该做什么、怎么做、什么 时候做以及为什么要做，描述了一组以某种顺 序完成的活动。
• 敏捷过程
–Agile Development是一种以人为核心、迭 代、循序渐进的开发方法，其软件开发过程称 为“敏捷过程”。
《软件生命周期》课件
软件设计的主要目的是创建和维护软件系统的架构，以确保软件系统的可 维护性、可扩展性和可重用性。
软Hale Waihona Puke 设计的原则模块化原则将软件系统划分为独立的模块，每个模块具 有明确定义的输入和输出。
抽象化原则
通过抽象来隐藏实现细节，使软件设计更加 简单明了。
单一职责原则
每个模块只负责一个功能，避免模块之间的 耦合。
软件维护技术
包括代码重构、单元测试、持续集成/持续 部署（CI/CD）等。
软件维护的注意事项
建立完善的文档
详细记录软件的架构、功能、接口等信息， 方便后续维护。
定期进行代码审查
及时发现和修复潜在的错误和漏洞。
遵循最佳实践
如代码规范、命名规范等，提高代码质量和 可维护性。
保持与开发人员的沟通
确保维护工作的顺利进行。
需求规格说明
将分析后的需求编写成需求规格说明 文档，明确需求的细节和验收标准。
需求分析
对收集到的需求进行整理、分类和评 估，明确软件的功能和非功能需求。
需求评审
邀请相关人员对需求规格说明进行审 查和评估，以确保需求的准确性和完 整性。
需求分析的工具
原型开发工具
用于快速构建软件原型，帮助用户更好地理解软件的 功能和界面设计。
软件测试的目的是发现软件 中存在的缺陷和错误，并提 供相应的反馈和建议，帮助 开发人员修复和改进软件。
软件测试贯穿于整个软件开 发生命周期，包括需求分析 、设计、编码、集成和部署 等阶段。
软件测试的方法和步骤
单元测试
对每个模块或函数进行测试，确保它们正常工作并满足设计要求。
集成测试
将多个模块或组件组合在一起进行测试，确保它们能够协同工作。
软Hale Waihona Puke 设计的原则模块化原则将软件系统划分为独立的模块，每个模块具 有明确定义的输入和输出。
抽象化原则
通过抽象来隐藏实现细节，使软件设计更加 简单明了。
单一职责原则
每个模块只负责一个功能，避免模块之间的 耦合。
软件维护技术
包括代码重构、单元测试、持续集成/持续 部署（CI/CD）等。
软件维护的注意事项
建立完善的文档
详细记录软件的架构、功能、接口等信息， 方便后续维护。
定期进行代码审查
及时发现和修复潜在的错误和漏洞。
遵循最佳实践
如代码规范、命名规范等，提高代码质量和 可维护性。
保持与开发人员的沟通
确保维护工作的顺利进行。
需求规格说明
将分析后的需求编写成需求规格说明 文档，明确需求的细节和验收标准。
需求分析
对收集到的需求进行整理、分类和评 估，明确软件的功能和非功能需求。
需求评审
邀请相关人员对需求规格说明进行审 查和评估，以确保需求的准确性和完 整性。
需求分析的工具
原型开发工具
用于快速构建软件原型，帮助用户更好地理解软件的 功能和界面设计。
软件测试的目的是发现软件 中存在的缺陷和错误，并提 供相应的反馈和建议，帮助 开发人员修复和改进软件。
软件测试贯穿于整个软件开 发生命周期，包括需求分析 、设计、编码、集成和部署 等阶段。
软件测试的方法和步骤
单元测试
对每个模块或函数进行测试，确保它们正常工作并满足设计要求。
集成测试
将多个模块或组件组合在一起进行测试，确保它们能够协同工作。
《软件工程》课件 第二章-软件生存周期及模型
模型适合的项目：
项目开始，明确了需求的大部分，但是需
求可能会发生变化
对于市场和用户把握不是很准，需要逐步
了解
对于有庞大和复杂功能的系统进行功能改
进，就需要一步一步实施的。
银行业务系统的生存期实例
项目规划
．银行业务需求 ．原形系统源代码 业务需求分析 产品阶段1设计 项目规划
产品阶段n设计
加工原型 客户评价原型
建造原型
原型开发过程
▲快速分析：分析人员与用户配合，迅速确定系统的基 本要求。要根据原型所要体现的特征，描述基本需求。 关键是要注意分析描述内容的选取。 ▲构造原型：在软件工具支持下尽快实现一个可运行的 系统。 ▲运行原型：是发现问题、消除误解、开发者与用户充 分协调的一个步骤。 ▲评价原型：评价原型的特性，纠正误解与错误，增添 新要求或提出要求变动，提出全面的修改意见。 ▲修改：原型开发的循环。
确认系统
把软件产品分解成一系列的增量构件，在增量开发迭代 中逐步加入。
每个构件由多个相互作用的模块构成，并且能够完成特
定的功能。 增量开发方法的新演进版本叫做 “极限程序设计 （eXtreme Programming）”。
增量模型
第一增量 第二增量 第三增量
……
核心功能
核心功能
核心功能
1
1
2
V模型:瀑布模型的细化－－对测试的展开
适合的项目
项目的需求在项目开始前很明确
解决方案在项目开始前也很明确
对系统的性能安全很严格的项目 类似的项目如：
航天飞机等 公司的财务系统
2.增量模型
定义 基本需求
将需求赋予 增量构件
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
➢ 周期内有可行性分析、需求分析、概要设计、 详细设计、编码、测试和维护等阶段
➢ 这种按时间分程的思想方法是软件工程中的一 种思想原则，即按部就班、逐步推进，每个阶 段都要有定义、工作、审查、形成文档以供交 流或备查，以提高软件的质量。
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
停止
开始
需求的采集 和细化
产生样品
快速设计
对原型加工
20型模型
14
（1）特点
– 立项以后先提交原型给用户，在用户试用 的基础上进行需求调查与原型修改。
– 强调用户对软件功能和使用性能的评价。 – 设计、修改原型与试用交替进行。
一次迭代中的开发步骤：
➢ 为了保障软件开发的正确性，每一阶段任务完成后，都必
须对它的阶段性产品进行评审，确认之后再转入下一阶段
的工作。评审过程发现错误和疏漏后，应该反馈到前面的
有关阶段修正错误、弥补疏漏，然后再重复前面的工作，
20直20/1至1/23某一阶段通过评审后再进入下一阶段。
6
可行性研 究与计划
可行性研究报告
需求分析
需求说明书
系统设计
设计文档
编码
程序
测试
测试报告
运行与 维护
图2.1 瀑布模型
2020/11/23
7
瀑布模型的阶段任务、工作结果及参与人员
阶段
基本任务
工作结果
参加者
计划期
可行性研究 与计划
研究开发该项目的可行性
可行性研究报告
用户、高级程序员
需求分析
开发期
系统设计 编程
测试
理解和表达用户的要求 建立系统的结构 编写程序 发现错误和排除错误
尽管上述条件比较苛刻，但是软件企业在开发 新产品或新项目时，往往还是采用瀑布模型。
系统软件和工具软件也常常采用瀑布模型。
2020/11/23
10
（3） 优点：
➢ 通过设置里程碑，明确每阶段的任务与目标。
➢ 可为每阶段制定开发计划，进行成本预算， 组织开发力量。
➢ 通过阶段评审，将开发过程纳入正确轨道。 ➢ 严格的计划性保证软件产品的按时交付。
➢ 瀑布模型过程逆转性很差或者说不可逆转，因为 根据上流的错误会在下流进行发散性传播的原理， 所以逆转将会延误工期，增加成本，造成重大损 失。
2020/11/23
9
（2） 适用条件 不是任何软件都可采用瀑布模型的，软件项目 或产品选择瀑布模型必须满足下列条件：
➢ 在开发时间内需求没有或很少变化。 ➢ 分析设计人员对应用领域很熟悉。 ➢ 低风险项目（对目标、环境很熟悉）。 ➢ 用户使用环境很稳定。 ➢ 用户除提出需求以外，很少参与开发工作。
第2章 软件生命周期模型
【本章重点】软件生命周期的概念及各个阶段 的任务、软件生命周期的若干模型
【本章用途】软件生命周期模型是软件工程研 究的四大内容之一，它虽然不是软件工程研究 的重点，但是在宏观上特别重要。
2020/11/23
1
2.1 软件生命周期
➢ 软件生命周期(Software Life Cycle，SLC)是软 件的产生直到报废的生命周期
需求说明书
用户、高级程序员
模块、数据说明书 用户、高级程序员
程序
高级程序员、初级程序 员
测试报告
另一独立的部门
运行期 运行与维护 维护
改进的系统
用户、高级程序员
2020/11/23
8
（1） 特点 ➢ 瀑布模型是以文档驱动的，为管理者进行项目开
发管理提供了基础，约束了开发过程中的活动。
➢ 瀑布模型是一种整体开发模型，在开发过程中， 用户看不见系统是什么样，只有开发完成向用户 提交整个系统时，用户才能看到一个完整的系统。
（4） 详细设计
详细设计阶段就是为每个模块完整的功能进行
具体描述，把功能描述转变为精确的、结构化
的过程描述。即该模块的控制结构是怎样的，
先做什么，后做什么，有什么样的条件判定，
有些什么重复处理等，并用相应的表示工具把
2020这/11/2些3 控制结构表示出来。
4
（5） 编码
编码阶段就是把每个模块的控制结构转换成计 算机可接受的程序代码，即写成以某特定程序 设计语言表示的“源程序清单”。当然，写出 的程序应该结构好，清晰易读，并且与设计相 一致。
– 了解用户/设计者的基本信息需求 – 开发初始原型系统 – 用户/设计者试用和评估原型系统
（6） 测试
测试是保证软件质量的重要手段，其主要方式 是在设计测试用例的基础上检验软件的各个组 成部分。
（7） 维护
软件维护是软件生存周期中时间最长的阶段。
已交付的软件投入正式使用后，便进入软件维
2020护/11/2阶3 段，它可以持续几年甚至几十年。
5
2.2 瀑布模型
➢ 瀑布模型(waterfall model)由W. Royce于1970年首先提出。
➢ 瀑布模型是由可行性研究、需求分析、系统设计、编码、 测试、运行与维护等阶段所组成的。
➢ 瀑布模型规定了各项关键软件工程活动，自上而下、相互 衔接、逐级下落，如同瀑布的固定次序一样。瀑布模型上 一阶段的变换结果是下一阶段变换的输入，相邻两个阶段 具有因果关系，紧密相联。一个阶段工作的失误将蔓延到 以后的各个阶段。
➢ 这种按时间分程的思想方法是软件工程中的一 种思想原则，即按部就班、逐步推进，每个阶 段都要有定义、工作、审查、形成文档以供交 流或备查，以提高软件的质量。
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
停止
开始
需求的采集 和细化
产生样品
快速设计
对原型加工
20型模型
14
（1）特点
– 立项以后先提交原型给用户，在用户试用 的基础上进行需求调查与原型修改。
– 强调用户对软件功能和使用性能的评价。 – 设计、修改原型与试用交替进行。
一次迭代中的开发步骤：
➢ 为了保障软件开发的正确性，每一阶段任务完成后，都必
须对它的阶段性产品进行评审，确认之后再转入下一阶段
的工作。评审过程发现错误和疏漏后，应该反馈到前面的
有关阶段修正错误、弥补疏漏，然后再重复前面的工作，
20直20/1至1/23某一阶段通过评审后再进入下一阶段。
6
可行性研 究与计划
可行性研究报告
需求分析
需求说明书
系统设计
设计文档
编码
程序
测试
测试报告
运行与 维护
图2.1 瀑布模型
2020/11/23
7
瀑布模型的阶段任务、工作结果及参与人员
阶段
基本任务
工作结果
参加者
计划期
可行性研究 与计划
研究开发该项目的可行性
可行性研究报告
用户、高级程序员
需求分析
开发期
系统设计 编程
测试
理解和表达用户的要求 建立系统的结构 编写程序 发现错误和排除错误
尽管上述条件比较苛刻，但是软件企业在开发 新产品或新项目时，往往还是采用瀑布模型。
系统软件和工具软件也常常采用瀑布模型。
2020/11/23
10
（3） 优点：
➢ 通过设置里程碑，明确每阶段的任务与目标。
➢ 可为每阶段制定开发计划，进行成本预算， 组织开发力量。
➢ 通过阶段评审，将开发过程纳入正确轨道。 ➢ 严格的计划性保证软件产品的按时交付。
➢ 瀑布模型过程逆转性很差或者说不可逆转，因为 根据上流的错误会在下流进行发散性传播的原理， 所以逆转将会延误工期，增加成本，造成重大损 失。
2020/11/23
9
（2） 适用条件 不是任何软件都可采用瀑布模型的，软件项目 或产品选择瀑布模型必须满足下列条件：
➢ 在开发时间内需求没有或很少变化。 ➢ 分析设计人员对应用领域很熟悉。 ➢ 低风险项目（对目标、环境很熟悉）。 ➢ 用户使用环境很稳定。 ➢ 用户除提出需求以外，很少参与开发工作。
第2章 软件生命周期模型
【本章重点】软件生命周期的概念及各个阶段 的任务、软件生命周期的若干模型
【本章用途】软件生命周期模型是软件工程研 究的四大内容之一，它虽然不是软件工程研究 的重点，但是在宏观上特别重要。
2020/11/23
1
2.1 软件生命周期
➢ 软件生命周期(Software Life Cycle，SLC)是软 件的产生直到报废的生命周期
需求说明书
用户、高级程序员
模块、数据说明书 用户、高级程序员
程序
高级程序员、初级程序 员
测试报告
另一独立的部门
运行期 运行与维护 维护
改进的系统
用户、高级程序员
2020/11/23
8
（1） 特点 ➢ 瀑布模型是以文档驱动的，为管理者进行项目开
发管理提供了基础，约束了开发过程中的活动。
➢ 瀑布模型是一种整体开发模型，在开发过程中， 用户看不见系统是什么样，只有开发完成向用户 提交整个系统时，用户才能看到一个完整的系统。
（4） 详细设计
详细设计阶段就是为每个模块完整的功能进行
具体描述，把功能描述转变为精确的、结构化
的过程描述。即该模块的控制结构是怎样的，
先做什么，后做什么，有什么样的条件判定，
有些什么重复处理等，并用相应的表示工具把
2020这/11/2些3 控制结构表示出来。
4
（5） 编码
编码阶段就是把每个模块的控制结构转换成计 算机可接受的程序代码，即写成以某特定程序 设计语言表示的“源程序清单”。当然，写出 的程序应该结构好，清晰易读，并且与设计相 一致。
– 了解用户/设计者的基本信息需求 – 开发初始原型系统 – 用户/设计者试用和评估原型系统
（6） 测试
测试是保证软件质量的重要手段，其主要方式 是在设计测试用例的基础上检验软件的各个组 成部分。
（7） 维护
软件维护是软件生存周期中时间最长的阶段。
已交付的软件投入正式使用后，便进入软件维
2020护/11/2阶3 段，它可以持续几年甚至几十年。
5
2.2 瀑布模型
➢ 瀑布模型(waterfall model)由W. Royce于1970年首先提出。
➢ 瀑布模型是由可行性研究、需求分析、系统设计、编码、 测试、运行与维护等阶段所组成的。
➢ 瀑布模型规定了各项关键软件工程活动，自上而下、相互 衔接、逐级下落，如同瀑布的固定次序一样。瀑布模型上 一阶段的变换结果是下一阶段变换的输入，相邻两个阶段 具有因果关系，紧密相联。一个阶段工作的失误将蔓延到 以后的各个阶段。