选择合适的项目方法(PPT33页)
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
并发？基于知识？计算机图形？
➢ 要创建的系统是不是有安全性需求的 ➢ 系统要在其上运行的系统环境的特点是什么
4.2.3 标识高级别项目风险
在开始时项目的不确定性越大，项 目不成功的风险越大。
➢产品不确定性(需求) ➢过程不确定性(开发过程与模型) ➢资源不确定性(人力)
4.2.4 考虑与实现有关的用户需求
极限编程
是增量式开发的扩展 更强调交流（与用户和组织内） 强调测试在开发中的作用 只满足现有的需求，不考虑未来的需要
4.12 动态系统开发方法
➢ 用户主动参与 ➢ DSDM组做出决策 ➢ 经常交付产品 ➢ 满足业务目标 ➢ 迭代式和增量式交付 ➢ 变更是可逆的 ➢ 需求从高层次来基线化 ➢ 测试要集成到整个生命周期中 ➢ 项目相关人员之间的协作方法是通用的
4.12 动态系统开发方法
DSDM鼓励使用时间盒。建议典型的时间 盒是2~6周。
原型的缺点和危险：
用户可能曲解原型的作用 可能缺乏项目标准 缺乏控制 额外的费用 机器效率 与开发人员密切接近
4.10 分类原型的其它方法
要从原型中学到什么
详细说明希望从原型中学到什么 计划如何评价原型 报告实际从原型中学到什么
4.10 分类原型的其它方法
原型要做到什么程度
4.3 技术计划内容清单
介绍和概括约束条件
系统特征、风险、用户需求
推荐的方法
方法学、过程模型、软件工具、目标环境
实现
开发环境、维护环境、需要的培训
有关问题
➢ 产品和活动、财务
4.4 过程模型的选择
系统开发要着手进行许多相关的活动来创 建最终的产品。这些活动可按许多不同的 方法来组织并称之为“过程模型”
需求优先级分类： Must have Should have Could have Won’t have
4.14 极限编程
极限编程（Extreme Programming, XP） 原理：
代码应该简单的开发来满足现有的需 求，而不是考虑对应用程序的未来扩展， 因为未来的需求是不确定的。
策划人员不仅需要选择方法，而且必须规 定每种方法如何应用。
学生项目
4.5 结构与交付速度
快速应用开发（rapid application development, RAD）强调的是快速产生 供用户评价的软件原型。
RAD采用联合应用开发（joint application development, JAD）研讨 会策略。
4.11 增量式交付
缺点：
软件变更量:后面的增量可能要求更改前 面的构件
程序员效率低 降低了系统的可扩展性:可扩展性与全局
性的矛盾
4.12 动态系统开发方法
SSADM: Structured Systems Analysis & Design Method
DSDM: Dynamic Systems Development Method
➢ 实验模型 ➢ 模仿模型 ➢ 部分工作模型
➢ 纵向的 ➢ 横向的
4.10 分类原型的其它方法
那些要进行原型化
人机界面 系统的功能
4.11 增量式交付
4.11 增量式交付
这个方法包括将应用程序分解为小的构件， 然后按顺序实现和交付构件。每个要交付 的构件应该给用户带来一些效益。
时间盒通常与增量式方法相关联。每个增 量可交付产品的时机严格受已批准的最终 期限的约束，即使删掉一些功能，这个最 终期限也必须满足。
4.11 增量式交付
举例：ERP系统 生产计划管理模块 生产排程管理模块 销售管理模块 采购管理模块 库存管理模块 系统管理模块 质量管理模块 设备管理模块 质量追溯管理模块 产品召回管理模块
4.11 增量式交付
优点：
从早期增量得到的反馈来改进后面的阶段 减少需求变更的可能性 用户在早期就能受益 早期可以得到回报 易于控制与管理 开发过程控制可以更灵活 如果出现紧急工作，该项目可以临时放弃 开发人员增加了成就感
RAD压力：快速廉价、健壮性
4.6 瀑布模型
பைடு நூலகம்
4.7 V过程模型
4.8 螺旋模型
4.9 软件原型开发
原型分类：
抛弃型原型：只验证某些想法，然后在真 正开发系统是抛弃
进化型原型：开发和修改原型，直至它最 终成为可运行的系统。
采用原型进行开发理由：
在实践中学习 改进沟通 改进用户参与 澄清部分已知的需求 验证规格说明的一致性和完整性 减少文档的需要 降低了维护成本 特征约束 产生期望的结果
第四章 选择合适的项目方法
本章目的
在策划项目时考虑待开发系统的特征 选择合适的过程模型 在合适的场合最佳地使用“瀑布”过程
模型 通过创建合适的原型来降低风险 通过增量式地实现项目来降低其它风险 使用“敏捷”开发方法消除组织级障碍
4.1 引言
选择合适的项目方法对应的是步进式方法 中的步骤3：分析项目的特征。
4.2.1 目的/产品驱动
目的驱动的项目优先于产品驱动的项目， 需要选择通用的软件解决方案来实现。
项目经理的理想情况是有明确的目的，但 尽可能非常自由地选择满足目的的方法。
4.2.2 分析项目其它特征
➢ 要实现的系统是面向数据的还是面向过程的 ➢ 将产生的软件是通用工具还是应用领域特定
的 ➢ 要实现的应用程序是否是特殊类型的
选择特定的过程模型会增加新的产品到项 目分解结构中，或者增加新的活动到活动 网络中。这将创建步骤4的输入：标识项 目的产品和活动。
4.2 选择技术
项目分析的输出是选择最合适的方法学和 技术。方法包括OO、SSADM等；技术可 能包括合适的应用程序构造和自动化测试 环境。
影响范围：
➢ 开发人员的培训需求 ➢ 要招聘的员工类型 ➢ 开发环境 ➢ 系统维护安排
当用户的需求影响到系统的实施方法的时 候，项目策划人员应该努力确保不必要的 假设或约束不会影响满足项目目的的方法， 同时，也要尽力采用能够满足用户需求的 项目实施方案。(用户的组织特征和用户采 用的标准)
4.2.5 选择通用的生命周期方法
控制系统 信息系统 通用工具:Face to market 专用技术：KRM 硬件环境 安全性关键的系统 不准确的需求
➢ 要创建的系统是不是有安全性需求的 ➢ 系统要在其上运行的系统环境的特点是什么
4.2.3 标识高级别项目风险
在开始时项目的不确定性越大，项 目不成功的风险越大。
➢产品不确定性(需求) ➢过程不确定性(开发过程与模型) ➢资源不确定性(人力)
4.2.4 考虑与实现有关的用户需求
极限编程
是增量式开发的扩展 更强调交流（与用户和组织内） 强调测试在开发中的作用 只满足现有的需求，不考虑未来的需要
4.12 动态系统开发方法
➢ 用户主动参与 ➢ DSDM组做出决策 ➢ 经常交付产品 ➢ 满足业务目标 ➢ 迭代式和增量式交付 ➢ 变更是可逆的 ➢ 需求从高层次来基线化 ➢ 测试要集成到整个生命周期中 ➢ 项目相关人员之间的协作方法是通用的
4.12 动态系统开发方法
DSDM鼓励使用时间盒。建议典型的时间 盒是2~6周。
原型的缺点和危险：
用户可能曲解原型的作用 可能缺乏项目标准 缺乏控制 额外的费用 机器效率 与开发人员密切接近
4.10 分类原型的其它方法
要从原型中学到什么
详细说明希望从原型中学到什么 计划如何评价原型 报告实际从原型中学到什么
4.10 分类原型的其它方法
原型要做到什么程度
4.3 技术计划内容清单
介绍和概括约束条件
系统特征、风险、用户需求
推荐的方法
方法学、过程模型、软件工具、目标环境
实现
开发环境、维护环境、需要的培训
有关问题
➢ 产品和活动、财务
4.4 过程模型的选择
系统开发要着手进行许多相关的活动来创 建最终的产品。这些活动可按许多不同的 方法来组织并称之为“过程模型”
需求优先级分类： Must have Should have Could have Won’t have
4.14 极限编程
极限编程（Extreme Programming, XP） 原理：
代码应该简单的开发来满足现有的需 求，而不是考虑对应用程序的未来扩展， 因为未来的需求是不确定的。
策划人员不仅需要选择方法，而且必须规 定每种方法如何应用。
学生项目
4.5 结构与交付速度
快速应用开发（rapid application development, RAD）强调的是快速产生 供用户评价的软件原型。
RAD采用联合应用开发（joint application development, JAD）研讨 会策略。
4.11 增量式交付
缺点：
软件变更量:后面的增量可能要求更改前 面的构件
程序员效率低 降低了系统的可扩展性:可扩展性与全局
性的矛盾
4.12 动态系统开发方法
SSADM: Structured Systems Analysis & Design Method
DSDM: Dynamic Systems Development Method
➢ 实验模型 ➢ 模仿模型 ➢ 部分工作模型
➢ 纵向的 ➢ 横向的
4.10 分类原型的其它方法
那些要进行原型化
人机界面 系统的功能
4.11 增量式交付
4.11 增量式交付
这个方法包括将应用程序分解为小的构件， 然后按顺序实现和交付构件。每个要交付 的构件应该给用户带来一些效益。
时间盒通常与增量式方法相关联。每个增 量可交付产品的时机严格受已批准的最终 期限的约束，即使删掉一些功能，这个最 终期限也必须满足。
4.11 增量式交付
举例：ERP系统 生产计划管理模块 生产排程管理模块 销售管理模块 采购管理模块 库存管理模块 系统管理模块 质量管理模块 设备管理模块 质量追溯管理模块 产品召回管理模块
4.11 增量式交付
优点：
从早期增量得到的反馈来改进后面的阶段 减少需求变更的可能性 用户在早期就能受益 早期可以得到回报 易于控制与管理 开发过程控制可以更灵活 如果出现紧急工作，该项目可以临时放弃 开发人员增加了成就感
RAD压力：快速廉价、健壮性
4.6 瀑布模型
பைடு நூலகம்
4.7 V过程模型
4.8 螺旋模型
4.9 软件原型开发
原型分类：
抛弃型原型：只验证某些想法，然后在真 正开发系统是抛弃
进化型原型：开发和修改原型，直至它最 终成为可运行的系统。
采用原型进行开发理由：
在实践中学习 改进沟通 改进用户参与 澄清部分已知的需求 验证规格说明的一致性和完整性 减少文档的需要 降低了维护成本 特征约束 产生期望的结果
第四章 选择合适的项目方法
本章目的
在策划项目时考虑待开发系统的特征 选择合适的过程模型 在合适的场合最佳地使用“瀑布”过程
模型 通过创建合适的原型来降低风险 通过增量式地实现项目来降低其它风险 使用“敏捷”开发方法消除组织级障碍
4.1 引言
选择合适的项目方法对应的是步进式方法 中的步骤3：分析项目的特征。
4.2.1 目的/产品驱动
目的驱动的项目优先于产品驱动的项目， 需要选择通用的软件解决方案来实现。
项目经理的理想情况是有明确的目的，但 尽可能非常自由地选择满足目的的方法。
4.2.2 分析项目其它特征
➢ 要实现的系统是面向数据的还是面向过程的 ➢ 将产生的软件是通用工具还是应用领域特定
的 ➢ 要实现的应用程序是否是特殊类型的
选择特定的过程模型会增加新的产品到项 目分解结构中，或者增加新的活动到活动 网络中。这将创建步骤4的输入：标识项 目的产品和活动。
4.2 选择技术
项目分析的输出是选择最合适的方法学和 技术。方法包括OO、SSADM等；技术可 能包括合适的应用程序构造和自动化测试 环境。
影响范围：
➢ 开发人员的培训需求 ➢ 要招聘的员工类型 ➢ 开发环境 ➢ 系统维护安排
当用户的需求影响到系统的实施方法的时 候，项目策划人员应该努力确保不必要的 假设或约束不会影响满足项目目的的方法， 同时，也要尽力采用能够满足用户需求的 项目实施方案。(用户的组织特征和用户采 用的标准)
4.2.5 选择通用的生命周期方法
控制系统 信息系统 通用工具:Face to market 专用技术：KRM 硬件环境 安全性关键的系统 不准确的需求