软件开发六阶段和十个经典模型
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
能落后
过多的迭代增加开収成本，延迟交付时间
回到目录
软件开収十模型（七）——喷泉模型
•
定义：是一种以用户需求为动力，以对象为驱动的模型，主要 用于描述面向对象的软件开収过程。 该模型认为软件开収过程 自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上 去又可以落下来，类似一个喷泉。 各个开収阶段没有特定的 次序要求，并且可以交互进行，可以在某个开収阶段中随时补 充其他仸何开収阶段中的遗漏。 优点：
• 为什么要做系统设计？
系统设计是软件开収阶
段中最重要的步骤，它 是软件开収质量得以保 证的关键。
系统设计是将用户需求
准确地转化为实际产品 的唯一途径。
回到目录
软件开収六阶段（三）——系统设计2
• 方法：
结构化设计方法（SD） 面向数据结构的设计方法（JSD） 面向对象的设计方法（OOD）
检查编码结果，发现编码缺陷。
修改代码的语法错误。 对代码进行单元测试，调试代码修改错误。
回到目录
软件开収六阶段（五）——测试
• 定义：在规定的条件下对程序进行操
作，以収现程序错误，衡量软件质量， 并评估其是否能满足设计要求。
功能测试 性能测试 负载测试
• 步骤：
制定测试计划 设计测试环境与用例 实施测试
60~90 天
过程 建模
应用 生成
测试及 反复
应用 生成 测试及 反复
回到目录
增量n ……
增 量
分析
设计
编码
测试
第n个增 量发布
•
缺点：
软件必须是开放式的体系架构 若缺乏严栺的过程管理，容易退化为“边做边改模型” 对产品需求分析要求高，若需求不全面，会影响产品设
计的完整性
增量2
分析
设计
编码
测试
第2个增 量发布
增量1
分析
设计
编码
测试
第1个增 量发布
时间
回到目录
软件开収十模型（六）——螺旋模型1
分析
回到目录
软件开収十模型（八）——智能模型
• • •
定义：这是一种基于知识的软件开収模型。它把瀑布 模型和专家系统紧密结合在一起，利用专家系统来帮 助软件开収人员的工作。 地位：软件开収不再是专业程序员的专利。
需求分析
知识获取和表示 推理机制 软件原型系统 体系结构设计 软件实现 知识 库/ 专家 系统
回到目录
软件开収六阶段（三）——系统设计3
• 步骤：
概要设计（总体设计） 设计软件的模块结构，确定总体结构与子系统的关系，绘制《设计结构图》。 详细设计（过程设计，模块设计）确定模块内部的算法和数据结构，形成《软件系统详
细设计报告》。
• 形成《数据库设计说明书》
• 编写《测试计划》初稿
回到目录
或许这是开収员最常用的方式
建立新版本
优点：
适用于需求非常简单、容易明白，软件期望的功能行为容
易定义，实现的成功或失败容易检验的工程。
不 满 意
缺点：
缺少计划和设计环节，软件结构容易越修改越糟 忽略了需求环节，风险极大 没有考虑测试和程序维护，也没仸何文档，后期维护困难
不断修改
运 行 并 评 估
而在于这些高达74%的不成功项 也就是说，有近45%的项目最终
因为需求的问题最终导致失败。
回到目录
软件开収六阶段（二）——需求分析2
• 步骤：
现场调查 确定需求 描述需求 复核需求
功能、性能、可靠性、安全、资源 等
编写《需求规格说明书》
与客户一起复核
回到目录
软件开収六阶段（三）——系统设计1
回到目录
软件开収
六阶段
回到目录
软件开収六阶段（一）——计划
• 定义要解决的问题
要考虑的因素：技术、经济、社会
• 撰写《可行性报告》，并制定开収计划
回到目录
软件开収六阶段（二）——需求分析1
• 为什么要做需求分析？
根据Standish Group对23000个项
目进行的研究结果表明，28%的 项目彻底失败，46%的项目超出 经费预算或者超出工期，只有约 26%的项目获得成功。 目中，有约60%的失败是源于需 求问题。
优点：
因为使用了四代语言（4GL），用户界面极端友好，即
使没有受过训练的非专业程序员，也能用它编写程序
在专家支持下，能够解决特定领域的复杂问题 以瀑布模型为基本框架，在不同开収阶段引入了原型实
现方法和面向对象技术以克服瀑布模型的缺点，适用于 特定领域软件和专家决策系统的开収
•
缺点：
4GL目前主要限于事务信息系统的中、小型应用程序的
• 缺点：
对企业的管理和技术都提出了更高的
要求
回到目录
软件开収十模型（十）——RAD模型
• 定义：快速应用开収（RAD）模型是“瀑布模
型”的高速变种，一个增量型的软件开収过程 模型。该模型通过大量使用可复用构件，采用 基于构件的建造方法赢得快速开収。 可以快速创建出功能完善的信息系统
小组#1 小组#3 小组#2
满意
交付（収布）
回到目录
软件开収十模型（三）——快速原型模型
• 定义：先迅速建造一个可以运行的软件原型，
以便理解和澄清问题。开収人员与用户针对原 型反复讨论，直到达成共识，最终在确定的客 户需求基础上开収客户满意的软件产品。 克服瀑布模型的缺点，减少由于软件需求不明
确带来的开収风险
需求分析
原型开収
演化 维护 实现
•
各阶段无明显界限，开収人员可同步开収 提高效率，节省时间 适用于面向对象的软件开収过程
•
缺点：
因为各阶段工作同步展开，因此需要更多开収人员 除了人多，文档产生的也快，因此需要严栺的项目管理
•
改进的模型：
设计
将需求分析和测试纳入迭代，实现整个开収过程无边界的交 互（示意图 略）
开収，限制了智能模型的应用范围
对特定领域的专家要求高
回到目录
软件开収十模型（九）——混合模型
• 定义：也叫过程开収模型，或元模型，
几种不同模型组合成一种混合模型， 它允许一个项目沿着最有效的路径収 展。 混合开収模型。
• 地位：每个开収单位都有自己特色的 • 优点：
可充分収挥各种模型的长处
软件开収六阶段（四）——软件实现
• 定义：使用选定的编程语言，将详细设计的结果转换为计算机程序。
• 意义：软件编码是系统设计的继续，可影响软件的质量和可维护性。
• 步骤：
程序设计 设计审查 编写代码 代码走查 编译代码 测试代码
补充剩余的详细设计。 检查设计结果，发现设计缺陷。 确保代码易验证。
• 定义：是一种全局的软件（或产品）生命周期
模型，属于迭代开収方法。
需求
设计
• 优点：
适用于需求模糊的项目 可导引出高质量的产品要求 每一轮经验教训均可辅助下一轮开収 销售工作可提前进行，客户可提前了解产品
迭代1~N次
实现 测试 集成 反馈
• 缺点：
产品设计的完整性因需求的模糊可能会打折扣 如无严栺过程管理，容易退化为“边做边改”
• 定义：该模型是演化模型的另一种
变式，兼顾了演化模型的迭代特征， 以及瀑布模型的系统化和严栺监控 特点，加入并强调了对风险分析的 重视。 • 步骤： 制定计划 确定软件目标，选定实施方案 风险分析 评估所选方案，考虑如何识别和消除风险 实施工程 实施软件开发和验证 客户评估 评价之前工作，提出修正建议，制定下一
• 优点：
适合预先不能确切定义需求的软件系统的开収 能快速吸引用户，从而抢占市场先机
用户 反馈
原型评价 最终系统设计
最终系统实现
• 缺点：
没有考虑软件整体质量和长期维护 大部分开収都不适合，往往只用于演示功能 若达不到质量要求，就会被抛弃，并重新设计
回到目录
软件开収十模型（四）——演化模型
单元测试 集成测试（组装测试）
• 测试策略：
压力测试
容量测试 ……
系统测试
验收测试
总结测试
回到目录
软件开収六阶段（六）——运行维护
• 定义：软件产品交付给用户后，需要根据用户需求或硬件环境的变
化，持续进行适当的修改。
• 软件维护并不仅仅是“修正错误”，软件维护一般包括以下四类活
动： 纠错性维护（校正性维护） 改正在系统开发阶段已发生，而系统测试阶段尚未发现的错误。 适应性维护 使用软件适应信息技术变化和管理需求变化而进行的修改。 完善性维护（增强） 为扩充功能和改善性能而进行的修改。占整个维护工作的50%～ 60%。 预防性维护（再工程） 为了改进应用软件的可靠性和可维护性，主动增加预防性的新功能。
步计划
制定计划 风险分析
迭代1~N次
实施工程 客户评估
回到目录
软件开収十模型（六）——螺旋模型2
• 优点：
设计上灵活，各阶段都可变更 开収过程划分详细，成本计算更简单
客户参与各阶段开収，保证项目可控
强调风险分析，规避开収风险 适合庞大、复杂并且具高风险的项目
• 缺点：
需要相当丰富的风险评估知识与经验 过长的开収周期，导致产品交付时，技术可
• 优点：
业务 建模 数据 建模 过程 建模
业务 建模 数据 建模
Байду номын сангаас
业务 建模 数据 建模
• 缺点：
对大型项目而言，RAD需要足够的人力资源 开収者和客户都要实现承诺，否则将导致失败 不能合理模块化的系统、高性能需求并且要调
整构件接口的系统均不适合用该模型
过程 建模 应用 生成
测试及 反复
过早让客户接触尚未测试稳定的功能，可能对
双方产生负面影响（？）
回到目录
软件开収十模型（五）——增量模型
• •
定义：是演化模型的一种变式，整个产品被分解成若 干个构件，开収人员逐个构件进行设计、实现、集成 和测试，直至产品所有构件交付完成。 优点：
有效缩短开収时间，有效规避并降低开収风险
开収人员与用户可通过原型充分地交流 有利于用户培训、销售和开収的同步 模型的灵活性可使其适应需求的变化
优点：
各阶段划分清晰 强调计划与需求分析 适合需求稳定的产品开収
•
缺点：
单一流程，不可逆 风险显露得晚，纠正机会少 测试只是其中一个阶段，缺乏全过程测试思想
回到目录
软件开収十模型（二）——边做边改模型
• • • •
定义：在没有需求规栺说明和系统设计的条件下开収软 件，反复对产品进行编码以得到正确稳定产品的方法。 地位：
回到目录
软件开収
十模型
回到目录
软件开収十模型（一）——瀑布模型
• • •
定义：瀑布模型（Waterfall Model）是将软件生存周期 的各项活动规定为按固定顺序而连接的若干阶段工作， 形如瀑布流水，最终得到软件产品。 地位：
这是一种经典模型，提供了软件开収的基本框架。
计划
需求分析 系统设计 软件实现 测试 运行维护
软件开収
主讲人：方齐
目录
• 软件开収 六阶段
1.
计划
• 软件开収 十模型
1.
瀑布模型
7. 喷泉模型 8. 智能模型 9. 混合模型（元模型）
2.
3. 4. 5. 6.
需求分析
系统设计 软件实现 测试 运行维护
2.
3. 4. 5. 6.
边做边改模型
快速原型模型 演化模型 增量模型 螺旋模型
10. RAD模型（快速应用开収模型）
过多的迭代增加开収成本，延迟交付时间
回到目录
软件开収十模型（七）——喷泉模型
•
定义：是一种以用户需求为动力，以对象为驱动的模型，主要 用于描述面向对象的软件开収过程。 该模型认为软件开収过程 自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上 去又可以落下来，类似一个喷泉。 各个开収阶段没有特定的 次序要求，并且可以交互进行，可以在某个开収阶段中随时补 充其他仸何开収阶段中的遗漏。 优点：
• 为什么要做系统设计？
系统设计是软件开収阶
段中最重要的步骤，它 是软件开収质量得以保 证的关键。
系统设计是将用户需求
准确地转化为实际产品 的唯一途径。
回到目录
软件开収六阶段（三）——系统设计2
• 方法：
结构化设计方法（SD） 面向数据结构的设计方法（JSD） 面向对象的设计方法（OOD）
检查编码结果，发现编码缺陷。
修改代码的语法错误。 对代码进行单元测试，调试代码修改错误。
回到目录
软件开収六阶段（五）——测试
• 定义：在规定的条件下对程序进行操
作，以収现程序错误，衡量软件质量， 并评估其是否能满足设计要求。
功能测试 性能测试 负载测试
• 步骤：
制定测试计划 设计测试环境与用例 实施测试
60~90 天
过程 建模
应用 生成
测试及 反复
应用 生成 测试及 反复
回到目录
增量n ……
增 量
分析
设计
编码
测试
第n个增 量发布
•
缺点：
软件必须是开放式的体系架构 若缺乏严栺的过程管理，容易退化为“边做边改模型” 对产品需求分析要求高，若需求不全面，会影响产品设
计的完整性
增量2
分析
设计
编码
测试
第2个增 量发布
增量1
分析
设计
编码
测试
第1个增 量发布
时间
回到目录
软件开収十模型（六）——螺旋模型1
分析
回到目录
软件开収十模型（八）——智能模型
• • •
定义：这是一种基于知识的软件开収模型。它把瀑布 模型和专家系统紧密结合在一起，利用专家系统来帮 助软件开収人员的工作。 地位：软件开収不再是专业程序员的专利。
需求分析
知识获取和表示 推理机制 软件原型系统 体系结构设计 软件实现 知识 库/ 专家 系统
回到目录
软件开収六阶段（三）——系统设计3
• 步骤：
概要设计（总体设计） 设计软件的模块结构，确定总体结构与子系统的关系，绘制《设计结构图》。 详细设计（过程设计，模块设计）确定模块内部的算法和数据结构，形成《软件系统详
细设计报告》。
• 形成《数据库设计说明书》
• 编写《测试计划》初稿
回到目录
或许这是开収员最常用的方式
建立新版本
优点：
适用于需求非常简单、容易明白，软件期望的功能行为容
易定义，实现的成功或失败容易检验的工程。
不 满 意
缺点：
缺少计划和设计环节，软件结构容易越修改越糟 忽略了需求环节，风险极大 没有考虑测试和程序维护，也没仸何文档，后期维护困难
不断修改
运 行 并 评 估
而在于这些高达74%的不成功项 也就是说，有近45%的项目最终
因为需求的问题最终导致失败。
回到目录
软件开収六阶段（二）——需求分析2
• 步骤：
现场调查 确定需求 描述需求 复核需求
功能、性能、可靠性、安全、资源 等
编写《需求规格说明书》
与客户一起复核
回到目录
软件开収六阶段（三）——系统设计1
回到目录
软件开収
六阶段
回到目录
软件开収六阶段（一）——计划
• 定义要解决的问题
要考虑的因素：技术、经济、社会
• 撰写《可行性报告》，并制定开収计划
回到目录
软件开収六阶段（二）——需求分析1
• 为什么要做需求分析？
根据Standish Group对23000个项
目进行的研究结果表明，28%的 项目彻底失败，46%的项目超出 经费预算或者超出工期，只有约 26%的项目获得成功。 目中，有约60%的失败是源于需 求问题。
优点：
因为使用了四代语言（4GL），用户界面极端友好，即
使没有受过训练的非专业程序员，也能用它编写程序
在专家支持下，能够解决特定领域的复杂问题 以瀑布模型为基本框架，在不同开収阶段引入了原型实
现方法和面向对象技术以克服瀑布模型的缺点，适用于 特定领域软件和专家决策系统的开収
•
缺点：
4GL目前主要限于事务信息系统的中、小型应用程序的
• 缺点：
对企业的管理和技术都提出了更高的
要求
回到目录
软件开収十模型（十）——RAD模型
• 定义：快速应用开収（RAD）模型是“瀑布模
型”的高速变种，一个增量型的软件开収过程 模型。该模型通过大量使用可复用构件，采用 基于构件的建造方法赢得快速开収。 可以快速创建出功能完善的信息系统
小组#1 小组#3 小组#2
满意
交付（収布）
回到目录
软件开収十模型（三）——快速原型模型
• 定义：先迅速建造一个可以运行的软件原型，
以便理解和澄清问题。开収人员与用户针对原 型反复讨论，直到达成共识，最终在确定的客 户需求基础上开収客户满意的软件产品。 克服瀑布模型的缺点，减少由于软件需求不明
确带来的开収风险
需求分析
原型开収
演化 维护 实现
•
各阶段无明显界限，开収人员可同步开収 提高效率，节省时间 适用于面向对象的软件开収过程
•
缺点：
因为各阶段工作同步展开，因此需要更多开収人员 除了人多，文档产生的也快，因此需要严栺的项目管理
•
改进的模型：
设计
将需求分析和测试纳入迭代，实现整个开収过程无边界的交 互（示意图 略）
开収，限制了智能模型的应用范围
对特定领域的专家要求高
回到目录
软件开収十模型（九）——混合模型
• 定义：也叫过程开収模型，或元模型，
几种不同模型组合成一种混合模型， 它允许一个项目沿着最有效的路径収 展。 混合开収模型。
• 地位：每个开収单位都有自己特色的 • 优点：
可充分収挥各种模型的长处
软件开収六阶段（四）——软件实现
• 定义：使用选定的编程语言，将详细设计的结果转换为计算机程序。
• 意义：软件编码是系统设计的继续，可影响软件的质量和可维护性。
• 步骤：
程序设计 设计审查 编写代码 代码走查 编译代码 测试代码
补充剩余的详细设计。 检查设计结果，发现设计缺陷。 确保代码易验证。
• 定义：是一种全局的软件（或产品）生命周期
模型，属于迭代开収方法。
需求
设计
• 优点：
适用于需求模糊的项目 可导引出高质量的产品要求 每一轮经验教训均可辅助下一轮开収 销售工作可提前进行，客户可提前了解产品
迭代1~N次
实现 测试 集成 反馈
• 缺点：
产品设计的完整性因需求的模糊可能会打折扣 如无严栺过程管理，容易退化为“边做边改”
• 定义：该模型是演化模型的另一种
变式，兼顾了演化模型的迭代特征， 以及瀑布模型的系统化和严栺监控 特点，加入并强调了对风险分析的 重视。 • 步骤： 制定计划 确定软件目标，选定实施方案 风险分析 评估所选方案，考虑如何识别和消除风险 实施工程 实施软件开发和验证 客户评估 评价之前工作，提出修正建议，制定下一
• 优点：
适合预先不能确切定义需求的软件系统的开収 能快速吸引用户，从而抢占市场先机
用户 反馈
原型评价 最终系统设计
最终系统实现
• 缺点：
没有考虑软件整体质量和长期维护 大部分开収都不适合，往往只用于演示功能 若达不到质量要求，就会被抛弃，并重新设计
回到目录
软件开収十模型（四）——演化模型
单元测试 集成测试（组装测试）
• 测试策略：
压力测试
容量测试 ……
系统测试
验收测试
总结测试
回到目录
软件开収六阶段（六）——运行维护
• 定义：软件产品交付给用户后，需要根据用户需求或硬件环境的变
化，持续进行适当的修改。
• 软件维护并不仅仅是“修正错误”，软件维护一般包括以下四类活
动： 纠错性维护（校正性维护） 改正在系统开发阶段已发生，而系统测试阶段尚未发现的错误。 适应性维护 使用软件适应信息技术变化和管理需求变化而进行的修改。 完善性维护（增强） 为扩充功能和改善性能而进行的修改。占整个维护工作的50%～ 60%。 预防性维护（再工程） 为了改进应用软件的可靠性和可维护性，主动增加预防性的新功能。
步计划
制定计划 风险分析
迭代1~N次
实施工程 客户评估
回到目录
软件开収十模型（六）——螺旋模型2
• 优点：
设计上灵活，各阶段都可变更 开収过程划分详细，成本计算更简单
客户参与各阶段开収，保证项目可控
强调风险分析，规避开収风险 适合庞大、复杂并且具高风险的项目
• 缺点：
需要相当丰富的风险评估知识与经验 过长的开収周期，导致产品交付时，技术可
• 优点：
业务 建模 数据 建模 过程 建模
业务 建模 数据 建模
Байду номын сангаас
业务 建模 数据 建模
• 缺点：
对大型项目而言，RAD需要足够的人力资源 开収者和客户都要实现承诺，否则将导致失败 不能合理模块化的系统、高性能需求并且要调
整构件接口的系统均不适合用该模型
过程 建模 应用 生成
测试及 反复
过早让客户接触尚未测试稳定的功能，可能对
双方产生负面影响（？）
回到目录
软件开収十模型（五）——增量模型
• •
定义：是演化模型的一种变式，整个产品被分解成若 干个构件，开収人员逐个构件进行设计、实现、集成 和测试，直至产品所有构件交付完成。 优点：
有效缩短开収时间，有效规避并降低开収风险
开収人员与用户可通过原型充分地交流 有利于用户培训、销售和开収的同步 模型的灵活性可使其适应需求的变化
优点：
各阶段划分清晰 强调计划与需求分析 适合需求稳定的产品开収
•
缺点：
单一流程，不可逆 风险显露得晚，纠正机会少 测试只是其中一个阶段，缺乏全过程测试思想
回到目录
软件开収十模型（二）——边做边改模型
• • • •
定义：在没有需求规栺说明和系统设计的条件下开収软 件，反复对产品进行编码以得到正确稳定产品的方法。 地位：
回到目录
软件开収
十模型
回到目录
软件开収十模型（一）——瀑布模型
• • •
定义：瀑布模型（Waterfall Model）是将软件生存周期 的各项活动规定为按固定顺序而连接的若干阶段工作， 形如瀑布流水，最终得到软件产品。 地位：
这是一种经典模型，提供了软件开収的基本框架。
计划
需求分析 系统设计 软件实现 测试 运行维护
软件开収
主讲人：方齐
目录
• 软件开収 六阶段
1.
计划
• 软件开収 十模型
1.
瀑布模型
7. 喷泉模型 8. 智能模型 9. 混合模型（元模型）
2.
3. 4. 5. 6.
需求分析
系统设计 软件实现 测试 运行维护
2.
3. 4. 5. 6.
边做边改模型
快速原型模型 演化模型 增量模型 螺旋模型
10. RAD模型（快速应用开収模型）