ProcessModelChoice项目管理进行模式选择.pptVIP

* 并行开发模型 None Awaiting changes Under revision Under review Baselined Done Under development Analysis activity * 并行开发模型 并行过程模型经常被用于开发C/S系统。该系统的活动可以被分为系统维和部件维。系统维包含了设计，装配和使用三个活动，而部件维包含了设计和实现两个活动。并发性表现在两个方面： 系统和部件的活动同时发生 各个部件可以并行设计和开发 * 原型法 原型法 原型是项目系统中的一个方面或者多个方面的工作模型。 抛弃型原型：用于试验某些概念，试验完系统将无用处 进化型原型：原型系统不断被开发和被修正，最终它变为一个真正的系统。 * 原型法 原型的好处 从实践中学习(Learning by doing) 改善的通信 改善的用户参与 使部分已知的需求清晰化 展示描述的一致性和完整性 可能可以减少文档 减少了维护成本 特征约束（利用工具构造原型可以将某些特性落到实处，而非在纸上写的那样容易失误） 试验是否能产生期待的结果 * 原型法 原型法的缺点 用户有时误解了原型的角色，例如他们可能误解原形应该和真实系统一样可靠 缺少项目标准，进化原型法有点像编码修正 缺少控制，由于用户可能不断提出新要求，因而原型迭代的周期很难控制 额外的花费：研究结果表明构造一个原型可能需要10%额外花费 运行效率可能会受影响 原型法要求开发者与用户密切接触，有时这是不可能的。例如外包软件。 * 从另外的角度看待原型 从中学到什么？ 学生经常会做一些软件作业，这些作业也被称为原型 问题：这些原型和软件系统原型是否相同？ 作为一个原型必须：描述他们希望从中学到的东西，规划原型评价的方法，报告从原型中真正学到的内容。 在不同的阶段，原型具有不同的作用。 原型起作用的程度 实物模型（Mock-ups） 仿真交互 部分模型：水平，垂直（某些特性构造详细的原型） * 构造原型的对象 人机接口 系统的功能 * 练习：何时引入原型系统 保险公司的经理需要通过个人计算机上的一个系统来访问管理信息。该系统价格必须合适。很多人怀疑是否经理真需要使用该系统。 可行性研究阶段，采用实物模型的方法 支持客户销售人员通过电话回答有关客户询问汽车保险价格的系统 设计用户对话界面时 保险公司考虑实施一个基于MS Access的电话销售系统，他们不知道Access是否能够开发出相应界面的系统并具备足够快的相应时间。 方案设计阶段 * 阶段交付 阶段交付持续地在确定的阶段向用户展示软件。 和渐进原型不同，在阶段交付的时候，你明确地知道下一步要完成什么工作。阶段交付的特点是不会在项目结束的时候一下交付全部软件，而是在项目整个开发过程中持续不断地交付阶段性成果。 * 阶段交付 软件概念 需求分析 构架设计 阶段1：详细设计，编码，调试，…… 阶段2：详细设计，编码，调试，…… * 阶段交付 阶段交付的优点是项目结束交付全部成果前，分阶段将有用的功能交付给用户。 阶段交付的主要缺点是，如果管理层面和技术层面上缺乏仔细的规划，工作就无法进行。 使用阶段交付的注意点是： 必须确定每一阶段的交付是对用户有用的 必须确保考虑了不同产品组成部分的技术依赖关系 * 面向进度的设计 类似于阶段交付，但是面向进度的设计生命周期模型在开始的时候不必知道究竟能达到何目标，但是要确保最后的期限。 该模型的关键是要按优先级别划分系统特性并规划开发阶段，保证前面的阶段具有高优先级的特性，低特性具有低优先级别。 是否采用这种方法决定于你是否对系统目标具有足够的信心，如果有信心，则没必要采用这种方法。 * 渐进交付 渐进交付是一种跨越了渐进原型和阶段交付两种模型的过程模型。 基本过程：开发一个产品的版本，展示给用户，根据反馈改善产品。 如果计划满足用户的绝大部分需求，渐进交付与渐进原型差不多，如果计划满足少量的需求，渐进交付就和阶段交付差不多。 渐进原型，强调的是系统看得见的样子，再回来堵漏洞，渐进交付中，最初的重点是系统核心和底层系统功能。 * 渐进交付 软件概念 需求分析 构架和内核设计 开发一个版本 并入用户反馈 交付该版本 开发一个版本 交付最终版本 * 确定渐进交付目标的一种方法 价值成本比 * 面向开发工具的设计 只在现有软件工具直接支持的情况下增强产品的功能，如果它不支持，就放弃这些功能。 当时间成为主要约束时，采用该模型能够比其他模型能够更完整地实现功能。 该方法的缺点是你失去了很多对产品的控制能力。 * 商品软件 商品软件也许未必满足你所有的要求，但是自己开发也需要一个周期，到那个时候，商品软件可能已经满足了你的要求。 商品软件可能存在不足，但是，你自己开发的产品也未必那么完美，当你补充了商