高级软件工程(第三章)几种典型的开发模型实例
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2
瀑布模型的特点
➢ 强调阶段的严格性:严格按照生存周期各个阶段的目 标、任务、文档和要求来进行开发。
➢ 强调阶段复审与确认:通过严格的阶段性复审与确认， 得到该阶段的一致、 完整、准确和无二义性的良好 文档。
➢ 以文档形式驱动:以文档形式驱动的，为合同双方最 终确认产品规定了蓝本， 为管理者进行项目开发管 理提供了基础，为开发过程施加了“政策”或纪律 限制， 约束了开发过程中的活动。
➢ 指明了需求、进度以及项目成本的合同 存在根本上的缺陷。
➢ 成功的项目需要频繁有序的客户反馈。 为开发团队和客户的协同工作方式提供 指导的合同才是最好的合同。
23
如何理解敏捷宣言？（续）
响应变化胜过遵循计划
➢ 计划赶不上变化。响应变化的能力决定 一个项目的成败。
➢ 较好的做计划策略是：为下两周做详细 的计划，为下三个月做粗略的计划，再 以后就做极为粗糙的计划。
20
如何理解敏捷宣言？
个体和交互胜过过程和工具
➢ 人是获得成功的最为重要的因素。 ➢ 合作、沟通以及交互能力要比单纯的编
程能力更为重要。
21
如何理解敏捷宣言？（续）
可用的软件胜过面面俱到的文档
➢ 没有文档的软件是一种灾难。 ➢ 过多的文档比过少的文档更糟。
22
如何理解敏捷宣言？（续）
客户合作胜过合同谈判
24
敏捷过程12条基本原则
1. 最优先要做的是通过尽早、持续地交付有价值的 软件来使客户满意。
2. 即使到了开发后期，也欢迎需求变化。 3. 经常性地交付可以工作的软件。 4. 在项目的整个开发期间，业务人员和开发人员必
须天天在一起工作。可以工作的软件是主要的进 度度量标准。 5. 围绕被激励起的个体来构建项目，为他们提供所 需的环境和支持，并信任他们能胜任工作。 6. 在团队内部，最有效果和最有效率的传递信息的 方法是面对面地交流。
度（尤其是大型项目），比较好的做法是对第一个迭代 周期的任务进行比较详细的划分（基于WBS），而对后 面迭代周期的适当放宽--计划应是由粗到细的。
18
敏捷开发方法
➢ 敏捷开发（Agile Development）是一种以人 为核心、迭代、循序渐进的开发方法。在敏捷 开发中，软件项目的构建被切分成多个子项目 ，各个子项目的成果都经过测试，具备集成和 可运行的特征。简言之，就是把一个大项目分 为多个相互联系，但也可独立运行的小项目， 并分别完成，在此过程中软件一直处于可使用 状态。
3. 文档管理：MSF的文档崇尚实用简洁，尽量避免事后 没人看的文档，资料的积累和经验的继承通过加强程 序员的交流来解决（如Code Review, Check in 前的 互相检查）。
11
续
4. 人员招聘培训：人员招聘首先注重人格因素，其次是 技术因素。人员的培训最有效最方便的手段是利用网 络以多媒体、电子文档的方式提供。
28
敏捷开发方法的核心思想
敏捷开发方法的核心思想概括起来就是 “适应变化”和“以人为本”。
（1）敏捷开发方法是面向人的百度文库非面向过程的。 敏捷开发认为人是软件开发中最重要的因素，
而且人工作的环境很复杂。它希望使软件开发工作 顺应人的天性而非逆之，强调软件开发应当是一项 令人愉悦的活动，因此它们注重调动人的积极性、 主动性和创造性，并培养人在工作中的自豪感。敏 捷开发的理念就是信任开发团队能够很好地完成任 务，所有的管理都是围绕这个理念展开的。
14
MSF团队角色的职责范围
➢产品经理：了解客户特征，尤其是商业特征，明确客 户的需求以及需求的期望值。 ➢程序经理：负责制定计划，每天找出完成该计划的风 险所在，排除风险，每天交付应该完成的内容，确保 计划按质、按量实施。 ➢用户体验：设计友好的用户界面，对用户进行培训， 确保用户能够并且愿意和喜欢使用开发出的产品。 ➢开发：开发者在开发前期就参与用户需求分析和项目 计划制定，他最清楚具体的开发过程。 ➢测试：负责开发出的代码的测试。 ➢发布管理：平稳地部署，为日常运营作好准备。
5. 项目角色的组成：程序管理、产品管理、开发、测试、 部署、用户培训，但微软并不是每个项目都配全了这 些角色，尤其是小的项目角色会有重叠。强调最好由 用户来充当产品管理角色。
6. 测试人员和开发人员的比例：项目测试人员和开发人 员的比例为1:1，微软通常是2:1，微软通常会雇用大 量的学生等临时人员来进行开发和测试。
10
MSF的特点
1. Code Review 原则：程序员定期向其他人讲解自己源 程序的活动，这个方法被众多公司采用并被认为是一 个行之有效的方法。
2. 版本管理方法：采用统一的版本管理服务器管理项目 源程序，每个人的程序，必须经另外一个程序员检查 后才能Check in， 每天晚上都有build所有程序，如 果build不能通过，程序员必须立即修改自己的程序。 每隔一段时间配合进度里程碑发布一个内部版本。
29
敏捷开发方法的核心思想（续）
（2）敏捷开发方法是“主动适应的”而不是“预先 设定的”。 瀑布模型等传统软件开发过程试图对一个软件 开发项目在很长的时间跨度内作出详细的计划，并 形成详细的文档，然后依照计划进行开发。这类方 法在计划制定完成后拒绝变化，后期的需求变化将 会花费极大的代价。而敏捷开发方法则乐于迎接变 化，其实，它的目的就是成为适应变化的过程。
➢极限编程中的“Extreme”（极限）是指将有效的 软件开发原理和实践应用到极限。
31
极限编程的核心价值观
沟通(Communication)
简
反
单
馈
(Feedback) (Simplicity)
勇气(Courage)
32
沟通
XP认为项目成员之间的沟通是项目成功的 关键，并把沟通看作项目中间协调与合作的 主要推动因素。
迭代和增量的过程：UP的迭代表示把项目划分 成小的子项目，迭它代提交系统的功能块或者 增量，最终产生完整的功能系统。
8
协同过程模型概述
➢ 它是对RUP过程的剪裁，是基于风险的增量和迭 代的开发；
➢ 这一过程是经过实践检验的适合C/S、B/S结构的 软件开发模型；
➢ 它分为四个阶段，每个阶段至少通过3次迭代过 程完成阶段目标；
17
微软过程的特点
➢ 使用迭代+渐进式提交的方式可以保持系统良好的可预 见性，也可使客户对项目组实施能力更加信任；
➢ 迭代周期的选择一定是对一组业务用例的实现而不是其 它。即每一个迭代周期都可以交付一个可以完成一定业 务功能的系统--迭代是针对业务用例的；
➢ 尽早实现困难的用例（如对服务水平要求高的用例）； ➢ 不要使一个迭代周期超过5周（1个月）； ➢ 不要试图在这个阶段就确定下来整个开发过程的详细进
25
敏捷过程12条基本原则（续）
7. 工作的软件是首要的进度度量标准。 8. 敏捷过程提倡可持续的开发速度。 9. 不断地关注最优秀的技术和良好的设计能增强敏
捷能力。 10. 简单是根本的。 11. 最好的架构、需求和设计来自于自组织的团队。 12. 每隔一定时间，团队都会对如何能有效地工作进
行反省，然后相应地对自己的行为进行调整。
30
什么是极限编程XP？
极限编程是一种适用于中小型团队在需求不
明或快速多变的情况下进行软件开发的轻量级
方法学。
——《解析极限编程》，Kent Beck.
➢XP是一种轻量、高效、低风险、柔性、可预测、 科学而且充满乐趣的软件开发方式。
➢XP是一种软件开发规则或最佳实践，说它是一种 规则是因为有些东西是XP中必须做的。
Infosys公司在软件过程改进方面取得的成
绩为其企业的良性发展奠定了基础。
该公司采用的标准过程模型是对瀑布模型的
细化，称之为Infosys模型。该模型每年被 成功地应用于500多个软件项目的开发。
7
UP的特点
由用例和风险驱动：用例是捕获需求的方法， UP通过对风险分析预测并关注软件构造。
以构架设计为中心：开发软件系统的UP方法是 开发和演进一个健壮的系统构架。
第三章 几种典型的 开发模型实例简介
瀑布模型
➢瀑布模型规定了由前至后、相互衔接的固定 次序，如同瀑布流水，逐级下落。瀑布模型为 软件开发提供了一种有效的管理模型。根据这 一模式制定开发计划，进行成本预算，组织开 发力量，以项目的阶段评审和文档控制为手段 的效地对整个开发过程进行指导。因此它是文 档驱动的、适合于需求很明确的软件项目开发 的模型。
27
敏捷需求分析方法应用情境
➢ 项目系统需求非常急迫，要求开发时间尽可能 的短。
➢ 软件项目计划开发时间只有短短的4个月。 ➢ 初步开发出来的产品需要立即拿到用户现场去
做演示，而在这时候用户会针对产品提出更多 的需求，结果是系统不能满足用户需求，项目 不得不做多次的需求变更。 ➢ 频繁的需求变更导致项目开发时间往往较长。
19
敏捷宣言
我们正在通过亲身实践以及帮助他人实践，揭示
更好的软件开发方法。通过这项工作，我们认为 （形成如下价值观）：
注重个体和交互 胜过 过程和工具 注重可用的软件 胜过 面面俱到的文档
注重客户合作 胜过 合同谈判 注重响应变化 胜过 恪守计划
也就是说，虽然右边的条目有价值，但我们更
看重左边的条目。 ——
状态。 ➢ 在一个项目的早期阶段，过分地强调了基线和里程
碑处的文档。 ➢ 开发人员一开始就必须理解其应用。 ➢ 当接近项目结束时，出现了大量的集成和测试工作。 ➢ 直到项目结束之前，都不能演示系统的能力。
5
瀑布模型的应用考虑
➢ 瀑布模型是传统过程模型的典型代表，因为 管理简单，常被获取方作为合同上的模型。
➢ 以里程碑开发原则为基础:提供各阶段的检查点， 确保用户需求，满足预算和时间限制。
3
瀑布模型的优点
✓ 容易理解、管理成本低。 ✓ 文档产生并提供了贯穿生命期的进展过程的
充分说明。允许基线和配置早期接受控制。 ✓ 可强迫开发人员采用规范的方法，例如结构
化方法。
4
瀑布模型的局限性
➢ 客户必须能够完整、正确和清晰地表达他们的需要。 ➢ 可能要花费更多的时间来建立一些用处不大的文档。 ➢ 在开始的两个或三个阶段中，很难评估真正的进度
26
敏捷开发的特点
敏捷方法强调以人为本，专注于交付对客户有价
值的软件。在高度协作的开环境中，通过快速、 短迭代式的开发，不断产出和演化可运行软件， 根据用户的反馈信息作适应性调整，然后进入下 一轮快速短迭代式开发。敏捷开发可以灵敏、快 捷地应对软件需求变化的特性，其特点包括：
➢能迅速交付可工作的软件 ➢能适应需求的不断变化 ➢能保护和维持软件开发团队的积极性 ➢通过延期决策来减小风险
15
MSF的组队原则
➢ 以产品发布为中心 ➢ 明确的目标 ➢ 客户的主动参与 ➢ 分享产品的前景 ➢ 所有人参与设计 ➢ 认真从过去的项目中吸取经验 ➢ 共同管理，共同决策 ➢ 项目组成员在同一地点办公 ➢ 大型项目组也像小型项目组一样运转
16
MSF过程模型
➢MSF过程模型解释了如何基于：范围、进度和资 源，规划和控制面向结果的项目。它是基于四个 可见里程碑交互的、允许修改的过程模型。
➢ 每个迭代有明确的目标和评估标准； ➢ 整个项目划分为3次目标明确的增量开发，每次
增量作为一个可执行版本，提交用户使用。
9
微软开发模型（ MSF ）
MSF(微软解决方案框架结构)是一组建立、
开发和实现分布式企业系统应用的工作模型、 开发准则和应用指南。它帮助企业融合商业 和技术的目标，降低采用新技术后系统整体 的费用，以及成功的应用微软技术整合商业 过程的方法。
➢ 当一个项目有稳定的产品定义且很容易被理 解的技术解决方案时，可以使用瀑布模型。
➢ 对于那些容易理解但很复杂的项目，采用纯 瀑布模型比较合适。
瀑布模型适合于功能和性能明确、 完整、
无重大变化的软件开发。
6
Infosys过程模型
Infosys公司其内部采用面向过程管理软件
开发，同时不断进行过程改进。1993年获 得ISO认证，1999年通过CMM5级认证。
12
续
7. 强调进行风险管理：对项目风险进行确认并全 程跟踪。
8. 项目开发过程进行里程碑的建立和管理。 9. 项目总结制度：每个项目完成后，对其失败和
成功的地方进行总结。
13
MSF团队模型
➢MSF组队模型展示了如何组织项目队伍，在时 间控制和连续不断发展计划的要求下，有效的 交付系统的解决方案。它描述了六种基本的角 色（程序管理、产品管理、开发、测试、用户 体验和发布管理）。
瀑布模型的特点
➢ 强调阶段的严格性:严格按照生存周期各个阶段的目 标、任务、文档和要求来进行开发。
➢ 强调阶段复审与确认:通过严格的阶段性复审与确认， 得到该阶段的一致、 完整、准确和无二义性的良好 文档。
➢ 以文档形式驱动:以文档形式驱动的，为合同双方最 终确认产品规定了蓝本， 为管理者进行项目开发管 理提供了基础，为开发过程施加了“政策”或纪律 限制， 约束了开发过程中的活动。
➢ 指明了需求、进度以及项目成本的合同 存在根本上的缺陷。
➢ 成功的项目需要频繁有序的客户反馈。 为开发团队和客户的协同工作方式提供 指导的合同才是最好的合同。
23
如何理解敏捷宣言？（续）
响应变化胜过遵循计划
➢ 计划赶不上变化。响应变化的能力决定 一个项目的成败。
➢ 较好的做计划策略是：为下两周做详细 的计划，为下三个月做粗略的计划，再 以后就做极为粗糙的计划。
20
如何理解敏捷宣言？
个体和交互胜过过程和工具
➢ 人是获得成功的最为重要的因素。 ➢ 合作、沟通以及交互能力要比单纯的编
程能力更为重要。
21
如何理解敏捷宣言？（续）
可用的软件胜过面面俱到的文档
➢ 没有文档的软件是一种灾难。 ➢ 过多的文档比过少的文档更糟。
22
如何理解敏捷宣言？（续）
客户合作胜过合同谈判
24
敏捷过程12条基本原则
1. 最优先要做的是通过尽早、持续地交付有价值的 软件来使客户满意。
2. 即使到了开发后期，也欢迎需求变化。 3. 经常性地交付可以工作的软件。 4. 在项目的整个开发期间，业务人员和开发人员必
须天天在一起工作。可以工作的软件是主要的进 度度量标准。 5. 围绕被激励起的个体来构建项目，为他们提供所 需的环境和支持，并信任他们能胜任工作。 6. 在团队内部，最有效果和最有效率的传递信息的 方法是面对面地交流。
度（尤其是大型项目），比较好的做法是对第一个迭代 周期的任务进行比较详细的划分（基于WBS），而对后 面迭代周期的适当放宽--计划应是由粗到细的。
18
敏捷开发方法
➢ 敏捷开发（Agile Development）是一种以人 为核心、迭代、循序渐进的开发方法。在敏捷 开发中，软件项目的构建被切分成多个子项目 ，各个子项目的成果都经过测试，具备集成和 可运行的特征。简言之，就是把一个大项目分 为多个相互联系，但也可独立运行的小项目， 并分别完成，在此过程中软件一直处于可使用 状态。
3. 文档管理：MSF的文档崇尚实用简洁，尽量避免事后 没人看的文档，资料的积累和经验的继承通过加强程 序员的交流来解决（如Code Review, Check in 前的 互相检查）。
11
续
4. 人员招聘培训：人员招聘首先注重人格因素，其次是 技术因素。人员的培训最有效最方便的手段是利用网 络以多媒体、电子文档的方式提供。
28
敏捷开发方法的核心思想
敏捷开发方法的核心思想概括起来就是 “适应变化”和“以人为本”。
（1）敏捷开发方法是面向人的百度文库非面向过程的。 敏捷开发认为人是软件开发中最重要的因素，
而且人工作的环境很复杂。它希望使软件开发工作 顺应人的天性而非逆之，强调软件开发应当是一项 令人愉悦的活动，因此它们注重调动人的积极性、 主动性和创造性，并培养人在工作中的自豪感。敏 捷开发的理念就是信任开发团队能够很好地完成任 务，所有的管理都是围绕这个理念展开的。
14
MSF团队角色的职责范围
➢产品经理：了解客户特征，尤其是商业特征，明确客 户的需求以及需求的期望值。 ➢程序经理：负责制定计划，每天找出完成该计划的风 险所在，排除风险，每天交付应该完成的内容，确保 计划按质、按量实施。 ➢用户体验：设计友好的用户界面，对用户进行培训， 确保用户能够并且愿意和喜欢使用开发出的产品。 ➢开发：开发者在开发前期就参与用户需求分析和项目 计划制定，他最清楚具体的开发过程。 ➢测试：负责开发出的代码的测试。 ➢发布管理：平稳地部署，为日常运营作好准备。
5. 项目角色的组成：程序管理、产品管理、开发、测试、 部署、用户培训，但微软并不是每个项目都配全了这 些角色，尤其是小的项目角色会有重叠。强调最好由 用户来充当产品管理角色。
6. 测试人员和开发人员的比例：项目测试人员和开发人 员的比例为1:1，微软通常是2:1，微软通常会雇用大 量的学生等临时人员来进行开发和测试。
10
MSF的特点
1. Code Review 原则：程序员定期向其他人讲解自己源 程序的活动，这个方法被众多公司采用并被认为是一 个行之有效的方法。
2. 版本管理方法：采用统一的版本管理服务器管理项目 源程序，每个人的程序，必须经另外一个程序员检查 后才能Check in， 每天晚上都有build所有程序，如 果build不能通过，程序员必须立即修改自己的程序。 每隔一段时间配合进度里程碑发布一个内部版本。
29
敏捷开发方法的核心思想（续）
（2）敏捷开发方法是“主动适应的”而不是“预先 设定的”。 瀑布模型等传统软件开发过程试图对一个软件 开发项目在很长的时间跨度内作出详细的计划，并 形成详细的文档，然后依照计划进行开发。这类方 法在计划制定完成后拒绝变化，后期的需求变化将 会花费极大的代价。而敏捷开发方法则乐于迎接变 化，其实，它的目的就是成为适应变化的过程。
➢极限编程中的“Extreme”（极限）是指将有效的 软件开发原理和实践应用到极限。
31
极限编程的核心价值观
沟通(Communication)
简
反
单
馈
(Feedback) (Simplicity)
勇气(Courage)
32
沟通
XP认为项目成员之间的沟通是项目成功的 关键，并把沟通看作项目中间协调与合作的 主要推动因素。
迭代和增量的过程：UP的迭代表示把项目划分 成小的子项目，迭它代提交系统的功能块或者 增量，最终产生完整的功能系统。
8
协同过程模型概述
➢ 它是对RUP过程的剪裁，是基于风险的增量和迭 代的开发；
➢ 这一过程是经过实践检验的适合C/S、B/S结构的 软件开发模型；
➢ 它分为四个阶段，每个阶段至少通过3次迭代过 程完成阶段目标；
17
微软过程的特点
➢ 使用迭代+渐进式提交的方式可以保持系统良好的可预 见性，也可使客户对项目组实施能力更加信任；
➢ 迭代周期的选择一定是对一组业务用例的实现而不是其 它。即每一个迭代周期都可以交付一个可以完成一定业 务功能的系统--迭代是针对业务用例的；
➢ 尽早实现困难的用例（如对服务水平要求高的用例）； ➢ 不要使一个迭代周期超过5周（1个月）； ➢ 不要试图在这个阶段就确定下来整个开发过程的详细进
25
敏捷过程12条基本原则（续）
7. 工作的软件是首要的进度度量标准。 8. 敏捷过程提倡可持续的开发速度。 9. 不断地关注最优秀的技术和良好的设计能增强敏
捷能力。 10. 简单是根本的。 11. 最好的架构、需求和设计来自于自组织的团队。 12. 每隔一定时间，团队都会对如何能有效地工作进
行反省，然后相应地对自己的行为进行调整。
30
什么是极限编程XP？
极限编程是一种适用于中小型团队在需求不
明或快速多变的情况下进行软件开发的轻量级
方法学。
——《解析极限编程》，Kent Beck.
➢XP是一种轻量、高效、低风险、柔性、可预测、 科学而且充满乐趣的软件开发方式。
➢XP是一种软件开发规则或最佳实践，说它是一种 规则是因为有些东西是XP中必须做的。
Infosys公司在软件过程改进方面取得的成
绩为其企业的良性发展奠定了基础。
该公司采用的标准过程模型是对瀑布模型的
细化，称之为Infosys模型。该模型每年被 成功地应用于500多个软件项目的开发。
7
UP的特点
由用例和风险驱动：用例是捕获需求的方法， UP通过对风险分析预测并关注软件构造。
以构架设计为中心：开发软件系统的UP方法是 开发和演进一个健壮的系统构架。
第三章 几种典型的 开发模型实例简介
瀑布模型
➢瀑布模型规定了由前至后、相互衔接的固定 次序，如同瀑布流水，逐级下落。瀑布模型为 软件开发提供了一种有效的管理模型。根据这 一模式制定开发计划，进行成本预算，组织开 发力量，以项目的阶段评审和文档控制为手段 的效地对整个开发过程进行指导。因此它是文 档驱动的、适合于需求很明确的软件项目开发 的模型。
27
敏捷需求分析方法应用情境
➢ 项目系统需求非常急迫，要求开发时间尽可能 的短。
➢ 软件项目计划开发时间只有短短的4个月。 ➢ 初步开发出来的产品需要立即拿到用户现场去
做演示，而在这时候用户会针对产品提出更多 的需求，结果是系统不能满足用户需求，项目 不得不做多次的需求变更。 ➢ 频繁的需求变更导致项目开发时间往往较长。
19
敏捷宣言
我们正在通过亲身实践以及帮助他人实践，揭示
更好的软件开发方法。通过这项工作，我们认为 （形成如下价值观）：
注重个体和交互 胜过 过程和工具 注重可用的软件 胜过 面面俱到的文档
注重客户合作 胜过 合同谈判 注重响应变化 胜过 恪守计划
也就是说，虽然右边的条目有价值，但我们更
看重左边的条目。 ——
状态。 ➢ 在一个项目的早期阶段，过分地强调了基线和里程
碑处的文档。 ➢ 开发人员一开始就必须理解其应用。 ➢ 当接近项目结束时，出现了大量的集成和测试工作。 ➢ 直到项目结束之前，都不能演示系统的能力。
5
瀑布模型的应用考虑
➢ 瀑布模型是传统过程模型的典型代表，因为 管理简单，常被获取方作为合同上的模型。
➢ 以里程碑开发原则为基础:提供各阶段的检查点， 确保用户需求，满足预算和时间限制。
3
瀑布模型的优点
✓ 容易理解、管理成本低。 ✓ 文档产生并提供了贯穿生命期的进展过程的
充分说明。允许基线和配置早期接受控制。 ✓ 可强迫开发人员采用规范的方法，例如结构
化方法。
4
瀑布模型的局限性
➢ 客户必须能够完整、正确和清晰地表达他们的需要。 ➢ 可能要花费更多的时间来建立一些用处不大的文档。 ➢ 在开始的两个或三个阶段中，很难评估真正的进度
26
敏捷开发的特点
敏捷方法强调以人为本，专注于交付对客户有价
值的软件。在高度协作的开环境中，通过快速、 短迭代式的开发，不断产出和演化可运行软件， 根据用户的反馈信息作适应性调整，然后进入下 一轮快速短迭代式开发。敏捷开发可以灵敏、快 捷地应对软件需求变化的特性，其特点包括：
➢能迅速交付可工作的软件 ➢能适应需求的不断变化 ➢能保护和维持软件开发团队的积极性 ➢通过延期决策来减小风险
15
MSF的组队原则
➢ 以产品发布为中心 ➢ 明确的目标 ➢ 客户的主动参与 ➢ 分享产品的前景 ➢ 所有人参与设计 ➢ 认真从过去的项目中吸取经验 ➢ 共同管理，共同决策 ➢ 项目组成员在同一地点办公 ➢ 大型项目组也像小型项目组一样运转
16
MSF过程模型
➢MSF过程模型解释了如何基于：范围、进度和资 源，规划和控制面向结果的项目。它是基于四个 可见里程碑交互的、允许修改的过程模型。
➢ 每个迭代有明确的目标和评估标准； ➢ 整个项目划分为3次目标明确的增量开发，每次
增量作为一个可执行版本，提交用户使用。
9
微软开发模型（ MSF ）
MSF(微软解决方案框架结构)是一组建立、
开发和实现分布式企业系统应用的工作模型、 开发准则和应用指南。它帮助企业融合商业 和技术的目标，降低采用新技术后系统整体 的费用，以及成功的应用微软技术整合商业 过程的方法。
➢ 当一个项目有稳定的产品定义且很容易被理 解的技术解决方案时，可以使用瀑布模型。
➢ 对于那些容易理解但很复杂的项目，采用纯 瀑布模型比较合适。
瀑布模型适合于功能和性能明确、 完整、
无重大变化的软件开发。
6
Infosys过程模型
Infosys公司其内部采用面向过程管理软件
开发，同时不断进行过程改进。1993年获 得ISO认证，1999年通过CMM5级认证。
12
续
7. 强调进行风险管理：对项目风险进行确认并全 程跟踪。
8. 项目开发过程进行里程碑的建立和管理。 9. 项目总结制度：每个项目完成后，对其失败和
成功的地方进行总结。
13
MSF团队模型
➢MSF组队模型展示了如何组织项目队伍，在时 间控制和连续不断发展计划的要求下，有效的 交付系统的解决方案。它描述了六种基本的角 色（程序管理、产品管理、开发、测试、用户 体验和发布管理）。