高级软件工程(第三章)几种典型的开发模型实例(2017课件)
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2
瀑布模型的特点
➢ 强调阶段的严格性:严格按照生存周期各个阶段的目 标、任务、文档和要求来进行开发。
➢ 强调阶段复审与确认:通过严格的阶段性复审与确认， 得到该阶段的一致、 完整、准确和无二义性的良好 文档。
➢ 以文档形式驱动:以文档形式驱动的，为合同双方最 终确认产品规定了蓝本， 为管理者进行项目开发管 理提供了基础，为开发过程施加了“政策”或纪律 限制， 约束了开发过程中的活动。
10
MSF的特点
1. Code Review 原则：程序员定期向其他人讲解自己源 程序的活动，这个方法被众多公司采用并被认为是一 个行之有效的方法。
2. 版本管理方法：采用统一的版本管理服务器管理项目 源程序，每个人的程序，必须经另外一个程序员检查 后才能Check in， 每天晚上都有build所有程序，如 果build不能通过，程序员必须立即修改自己的程序。 每隔一段时间配合进度里程碑发布一个内部版本。
➢ 每个迭代有明确的目标和评估标准； ➢ 整个项目划分为3次目标明确的增量开发，每次
增量作为一个可执行版本，提交用户使用。
9
微软开发模型（ MSF ）
MSF(微软解决方案框架结构)是一组建立、
开发和实现分布式企业系统应用的工作模型、 开发准则和应用指南。它帮助企业融合商业 和技术的目标，降低采用新技术后系统整体 的费用，以及成功的应用微软技术整合商业 过程的方法。
14
MSF团队角色的职责范围
➢产品经理：了解客户特征，尤其是商业特征，明确客 户的需求以及需求的期望值。 ➢程序经理：负责制定计划，每天找出完成该计划的风 险所在，排除风险，每天交付应该完成的内容，确保 计划按质、按量实施。 ➢用户体验：设计友好的用户界面，对用户进行培训， 确保用户能够并且愿意和喜欢使用开发出的产品。 ➢开发：开发者在开发前期就参与用户需求分析和项目 计划制定，他最清楚具体的开发过程。 ➢测试：负责开发出的代码的测试。 ➢发布管理：平稳地部署，为日常运营作好准备。
3. 文档管理：MSF的文档崇尚实用简洁，尽量避免事后 没人看的文档，资料的积累和经验的继承通过加强程 序员的交流来解决（如Code Review, Check in 前的 互相检查）。
11
续
4. 人员招聘培训：人员招聘首先注重人格因素，其次是 技术因素。人员的培训最有效最方便的手段是利用网 络以多媒体、电子文档的方式提供。
第三章 几种典型的 开发模型实例简介
瀑布模型
➢瀑布模型规定了由前至后、相互衔接的固定 次序，如同瀑布流水，逐级下落。瀑布模型为 软件开发提供了一种有效的管理模型。根据这 一模式制定开发计划，进行成本预算，组织开 发力量，以项目的阶段评审和文档控制为手段 的效地对整个开发过程进行指导。因此它是文 档驱动的、适合于需求很明确的软件项目开发 的模型。
15
MSF的组队原则
➢ 以产品发布为中心 ➢ 明确的目标 ➢ 客户的主动参与 ➢ 分享产品的前景 ➢ 所有人参与设计 ➢ 认真从过去的项目中吸取经验 ➢ 共同管理，共同决策 ➢ 项目组成员在同一地点办公 ➢ 大型项目组也像小型项目组一样运转
Infosys公司在软件过程改进方面取得的成
绩为其企业的良性发展奠定了基础。
该公司采用的标准过程模型是对瀑布模型的
细化，称之为Infosys模型。该模型每年被 成功地应用于500多个软件项目的开发。
7
UP的特点
由用例和风险驱动：用例是捕获需求的方法， UP通过对风险分析预测并关注软件构造。
以构架设计为中心：开发软件系统的UP方法是 开发和演进一个健壮的系统构架。
12
续
7. 强调进行风险管理：对项目风险进行确认并全 程跟踪。
8. 项目开发过程进行里程碑的建立和管理。 9. 项目总结制度：每个项目完成后，对其失败和
成功的地方进行总结。
13
MSF团队模型
➢MSF组队模型展示了如何组织项目队伍，在时 间控制和连续不断发展计划的要求下，有效的 交付系统的解决方案。它描述了六种基本的角 色（程序管理、产品管理、开发、测试、用户 体验和发布管理）。
➢ 当一个项目有稳定的产品定义且很容易被理 解的技术解决方案时，可以使用瀑布模型。
➢ 对于那些容易理解但很复杂的项目，采用纯 瀑布模型比较合适。
瀑布模型适合于功能和性能明确、 完整、
无重大变化的软件开发。
6
Infosys过程模型
Infosys公司其内部采用面向过程管理软件
开发，同时不断进行过程改进。1993年获 得ISO认证，1999年通过CMM5级认证。
迭代和增量的过程：UP的迭代表示把项目划分 成小的子项目，迭它代提交系统的功能块或者 增量，最终产生完整的功能系统。
8
协同过程模型概述
➢ 它是对RUP过程的剪裁，是基于风险的增量和迭 代的开发；
➢ 这一过程是经过实践检验的适合C/S、B/S结构的 软件开发模型；
➢ 它分为四个阶段，每个阶段至少通过3次迭代过 程完成阶段目标；
➢ 以里程碑开发原则为基础:提供各阶段的检查点， 确保用户需求，满足预算和时间限制。
3
瀑布模型的优点
✓ 容易理解、管理成本低。 ✓ 文档产生并提供了贯穿生命期的进展过程的
充分说明。允许基线和配置早期接受控制。 ✓ 可强迫开发人员采用规范的方法，例如结构
化方法。
4
瀑布模型的局限性
➢ 客户必须能够完整、正确和清晰地表达他们的需要。 ➢ 可能要花费更多的时间来建立一些用处不大的文档。 ➢ 在开始的两个或三个阶段中，很难评估真正的进度
5. 项目角色的组成：程序管理、产品管理、开发、测试、 部署、用户培训，但微软并不是每个项目都配全了这 些角色，尤其是小的项目角色会有重叠。强调最好由 用户来充当产品管理角色。
6. 测试人员和开发人员的比例：项目测试人员和开发人 员的比例为1:1，微软通常是2:1，微软通常会雇用大 量的学生等临时人员来进行开发和测试。
状态。 ➢ 在一个项目的早期阶段，过分地强调了基线和里程
碑处的文档。 ➢ 开发人员一开始就必须理解其应用。 ➢ 当接近项目结束时，出现了大量的集成和测试工作。 ➢ 直到项目结束之前，都不能演示系统的能力。
5Fra Baidu bibliotek
瀑布模型的应用考虑
➢ 瀑布模型是传统过程模型的典型代表，因为 管理简单，常被获取方作为合同上的模型。
瀑布模型的特点
➢ 强调阶段的严格性:严格按照生存周期各个阶段的目 标、任务、文档和要求来进行开发。
➢ 强调阶段复审与确认:通过严格的阶段性复审与确认， 得到该阶段的一致、 完整、准确和无二义性的良好 文档。
➢ 以文档形式驱动:以文档形式驱动的，为合同双方最 终确认产品规定了蓝本， 为管理者进行项目开发管 理提供了基础，为开发过程施加了“政策”或纪律 限制， 约束了开发过程中的活动。
10
MSF的特点
1. Code Review 原则：程序员定期向其他人讲解自己源 程序的活动，这个方法被众多公司采用并被认为是一 个行之有效的方法。
2. 版本管理方法：采用统一的版本管理服务器管理项目 源程序，每个人的程序，必须经另外一个程序员检查 后才能Check in， 每天晚上都有build所有程序，如 果build不能通过，程序员必须立即修改自己的程序。 每隔一段时间配合进度里程碑发布一个内部版本。
➢ 每个迭代有明确的目标和评估标准； ➢ 整个项目划分为3次目标明确的增量开发，每次
增量作为一个可执行版本，提交用户使用。
9
微软开发模型（ MSF ）
MSF(微软解决方案框架结构)是一组建立、
开发和实现分布式企业系统应用的工作模型、 开发准则和应用指南。它帮助企业融合商业 和技术的目标，降低采用新技术后系统整体 的费用，以及成功的应用微软技术整合商业 过程的方法。
14
MSF团队角色的职责范围
➢产品经理：了解客户特征，尤其是商业特征，明确客 户的需求以及需求的期望值。 ➢程序经理：负责制定计划，每天找出完成该计划的风 险所在，排除风险，每天交付应该完成的内容，确保 计划按质、按量实施。 ➢用户体验：设计友好的用户界面，对用户进行培训， 确保用户能够并且愿意和喜欢使用开发出的产品。 ➢开发：开发者在开发前期就参与用户需求分析和项目 计划制定，他最清楚具体的开发过程。 ➢测试：负责开发出的代码的测试。 ➢发布管理：平稳地部署，为日常运营作好准备。
3. 文档管理：MSF的文档崇尚实用简洁，尽量避免事后 没人看的文档，资料的积累和经验的继承通过加强程 序员的交流来解决（如Code Review, Check in 前的 互相检查）。
11
续
4. 人员招聘培训：人员招聘首先注重人格因素，其次是 技术因素。人员的培训最有效最方便的手段是利用网 络以多媒体、电子文档的方式提供。
第三章 几种典型的 开发模型实例简介
瀑布模型
➢瀑布模型规定了由前至后、相互衔接的固定 次序，如同瀑布流水，逐级下落。瀑布模型为 软件开发提供了一种有效的管理模型。根据这 一模式制定开发计划，进行成本预算，组织开 发力量，以项目的阶段评审和文档控制为手段 的效地对整个开发过程进行指导。因此它是文 档驱动的、适合于需求很明确的软件项目开发 的模型。
15
MSF的组队原则
➢ 以产品发布为中心 ➢ 明确的目标 ➢ 客户的主动参与 ➢ 分享产品的前景 ➢ 所有人参与设计 ➢ 认真从过去的项目中吸取经验 ➢ 共同管理，共同决策 ➢ 项目组成员在同一地点办公 ➢ 大型项目组也像小型项目组一样运转
Infosys公司在软件过程改进方面取得的成
绩为其企业的良性发展奠定了基础。
该公司采用的标准过程模型是对瀑布模型的
细化，称之为Infosys模型。该模型每年被 成功地应用于500多个软件项目的开发。
7
UP的特点
由用例和风险驱动：用例是捕获需求的方法， UP通过对风险分析预测并关注软件构造。
以构架设计为中心：开发软件系统的UP方法是 开发和演进一个健壮的系统构架。
12
续
7. 强调进行风险管理：对项目风险进行确认并全 程跟踪。
8. 项目开发过程进行里程碑的建立和管理。 9. 项目总结制度：每个项目完成后，对其失败和
成功的地方进行总结。
13
MSF团队模型
➢MSF组队模型展示了如何组织项目队伍，在时 间控制和连续不断发展计划的要求下，有效的 交付系统的解决方案。它描述了六种基本的角 色（程序管理、产品管理、开发、测试、用户 体验和发布管理）。
➢ 当一个项目有稳定的产品定义且很容易被理 解的技术解决方案时，可以使用瀑布模型。
➢ 对于那些容易理解但很复杂的项目，采用纯 瀑布模型比较合适。
瀑布模型适合于功能和性能明确、 完整、
无重大变化的软件开发。
6
Infosys过程模型
Infosys公司其内部采用面向过程管理软件
开发，同时不断进行过程改进。1993年获 得ISO认证，1999年通过CMM5级认证。
迭代和增量的过程：UP的迭代表示把项目划分 成小的子项目，迭它代提交系统的功能块或者 增量，最终产生完整的功能系统。
8
协同过程模型概述
➢ 它是对RUP过程的剪裁，是基于风险的增量和迭 代的开发；
➢ 这一过程是经过实践检验的适合C/S、B/S结构的 软件开发模型；
➢ 它分为四个阶段，每个阶段至少通过3次迭代过 程完成阶段目标；
➢ 以里程碑开发原则为基础:提供各阶段的检查点， 确保用户需求，满足预算和时间限制。
3
瀑布模型的优点
✓ 容易理解、管理成本低。 ✓ 文档产生并提供了贯穿生命期的进展过程的
充分说明。允许基线和配置早期接受控制。 ✓ 可强迫开发人员采用规范的方法，例如结构
化方法。
4
瀑布模型的局限性
➢ 客户必须能够完整、正确和清晰地表达他们的需要。 ➢ 可能要花费更多的时间来建立一些用处不大的文档。 ➢ 在开始的两个或三个阶段中，很难评估真正的进度
5. 项目角色的组成：程序管理、产品管理、开发、测试、 部署、用户培训，但微软并不是每个项目都配全了这 些角色，尤其是小的项目角色会有重叠。强调最好由 用户来充当产品管理角色。
6. 测试人员和开发人员的比例：项目测试人员和开发人 员的比例为1:1，微软通常是2:1，微软通常会雇用大 量的学生等临时人员来进行开发和测试。
状态。 ➢ 在一个项目的早期阶段，过分地强调了基线和里程
碑处的文档。 ➢ 开发人员一开始就必须理解其应用。 ➢ 当接近项目结束时，出现了大量的集成和测试工作。 ➢ 直到项目结束之前，都不能演示系统的能力。
5Fra Baidu bibliotek
瀑布模型的应用考虑
➢ 瀑布模型是传统过程模型的典型代表，因为 管理简单，常被获取方作为合同上的模型。