选择合适的项目方法（PPT33页)

1、第四章 选择合适的项目方法1本章目的在策划项目时考虑待开发系统的特征选择合适的过程模型在合适的场合最佳地使用“瀑布”过程模型通过创建合适的原型来降低风险通过增量式地实现项目来降低其它风险使用“敏捷”开发方法消除组织级障碍24.1 引言选择合适的项目方法对应的是步进式方法中的步骤3：分析项目的特征。选择特定的过程模型会增加新的产品到项目分解结构中，或者增加新的活动到活动网络中。这将创建步骤4的输入：标识项目的产品和活动。3 4.2 选择技术项目分析的输出是选择最合适的方法学和技术。方法包括OO、SSADM等；技术可能包括合适的应用程序构造和自动化测试环境。影响范围：开发人员的培训需求要招聘的员工

2、类型开发环境系统维护安排4 4.2.1 目的/产品驱动目的驱动的项目优先于产品驱动的项目，需要选择通用的软件解决方案来实现。项目经理的理想情况是有明确的目的，但尽可能非常自由地选择满足目的的方法。5 4.2.2 分析项目其它特征要实现的系统是面向数据的还是面向过程的将产生的软件是通用工具还是应用领域特定的要实现的应用程序是否是特殊类型的并发？基于知识？计算机图形？要创建的系统是不是有安全性需求的系统要在其上运行的系统环境的特点是什么64.2.3 标识高级别项目风险在开始时项目的不确定性越大，项目不成功的风险越大。产品不确定性(需求)过程不确定性(开发过程与模型)资源不确定性(人力)74.2.4

3、 考虑与实现有关的用户需求当用户的需求影响到系统的实施方法的时候，项目策划人员应该努力确保不必要的假设或约束不会影响满足项目目的的方法，同时，也要尽力采用能够满足用户需求的项目实施方案。(用户的组织特征和用户采用的标准)8控制系统信息系统通用工具:Face to market专用技术：KRM硬件环境安全性关键的系统不准确的需求4.2.5 选择通用的生命周期方法9介绍和概括约束条件系统特征、风险、用户需求推荐的方法方法学、过程模型、软件工具、目标环境实现开发环境、维护环境、需要的培训有关问题产品和活动、财务4.3 技术计划内容清单10系统开发要着手进行许多相关的活动来创建最终的产品。这些活动可按

4、许多不同的方法来组织并称之为“过程模型”策划人员不仅需要选择方法，而且必须规定每种方法如何应用。学生项目4.4 过程模型的选择11快速应用开发（rapid application development, RAD）强调的是快速产生供用户评价的软件原型。RAD采用联合应用开发（joint application development, JAD）研讨会策略。RAD压力：快速廉价、健壮性4.5 结构与交付速度124.6 瀑布模型134.7 V过程模型144.8 螺旋模型15原型分类：抛弃型原型：只验证某些想法，然后在真正开发系统是抛弃进化型原型：开发和修改原型，直至它最终成为可运行的系统。4.9

5、软件原型开发16采用原型进行开发理由：在实践中学习改进沟通改进用户参与澄清部分已知的需求验证规格说明的一致性和完整性减少文档的需要降低了维护成本特征约束产生期望的结果17原型的缺点和危险：用户可能曲解原型的作用可能缺乏项目标准缺乏控制额外的费用机器效率与开发人员密切接近18要从原型中学到什么详细说明希望从原型中学到什么计划如何评价原型报告实际从原型中学到什么4.10 分类原型的其它方法194.10 分类原型的其它方法原型要做到什么程度实验模型模仿模型部分工作模型纵向的横向的20那些要进行原型化人机界面系统的功能4.10 分类原型的其它方法214.11 增量式交付22这个方法包括将应用程序分解为

6、小的构件，然后按顺序实现和交付构件。每个要交付的构件应该给用户带来一些效益。时间盒通常与增量式方法相关联。每个增量可交付产品的时机严格受已批准的最终期限的约束，即使删掉一些功能，这个最终期限也必须满足。4.11 增量式交付23举例：ERP系统生产计划管理模块生产排程管理模块销售管理模块采购管理模块库存管理模块系统管理模块质量管理模块设备管理模块质量追溯管理模块产品召回管理模块4.11 增量式交付24优点：从早期增量得到的反馈来改进后面的阶段减少需求变更的可能性用户在早期就能受益早期可以得到回报易于控制与管理开发过程控制可以更灵活如果出现紧急工作，该项目可以临时放弃开发人员增加了成就感4.11

7、增量式交付25缺点：软件变更量:后面的增量可能要求更改前面的构件程序员效率低降低了系统的可扩展性:可扩展性与全局性的矛盾4.11 增量式交付26SSADM: Structured Systems Analysis & Design MethodDSDM: Dynamic Systems Development Method4.12 动态系统开发方法27用户主动参与DSDM组做出决策经常交付产品满足业务目标迭代式和增量式交付变更是可逆的需求从高层次来基线化测试要集成到整个生命周期中项目相关人员之间的协作方法是通用的4.12 动态系统开发方法28DSDM鼓励使用时间盒。建议典型的时间盒是26周。需求优先级分类：Must haveShould haveCould haveWont have4.12 动态系统开发方法29极限编程（Extreme Programming, XP）原理： 代码应该简单的开发来满足现有的需求，而不是考虑对应用程序的未来扩展，因为未来的需求是不确定的。4.14 极限编程30极限编程是增量式开发的扩展更强调交流（与用户和组织内）强调测试在开发中的作用只满足现有的需求，不考虑未来的需要和重用性结对编程31进化式方法：不确定性较高的情况增量式方法：需