第5章、ERP统实施的可选方案.pptVIP

增量模型（Incremental Model） 与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷： 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。 螺旋模型 1988年，Barry Boehm正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。 螺旋模型是对原型法的反复应用。这一方法是为高风险的软件项目设计的。所以它多半能适用于要进行大量内部开发的ERP实施项目。 供应商的ERP软件实施过程基本上是一个反复的过程，每一次反复都包括修改、重新实施和升级。在螺旋模型中，要对系统的每一部分进行风险分析。 螺旋模型 螺旋模型迭代 螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动： （1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件； （2） 风险分析：分析评估所选方案，考虑如何识别和消除风险； （3） 实施工程：实施软件开发和验证； （4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。 螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下： （1） 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。 （2） 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。 （3） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险 表5.3 软件开发的螺旋模型 第一个周期 第二个周期 第三个周期 第四个周期 风险分析 风险分析 风险分析 风险分析 原型模型 原型模型 原型模型 运行原型 运行概念 软件需求 软件产品设计 详细设计 编码 需求计划 需求确认 设计确认和检验 单位测试 生命周期规划 开发计划 整合和测试计划 整合和测试 接收程度测试 实施 各种模型的比较 模型 优点 缺点 瀑布模型 文档驱动 系统可能不满足客户的需求 快速原型模型 关注满足客户需求 可能导致系统设计差、效率低，难于维护 增量模型 开发早期反馈及时，易于维护 需要开放式体系结构，可能会设计差、效率低 螺旋模型 风险驱动 风险分析人员需要有经验且经过充分训练 系统开发的其他可选方案－ASP 最普遍的外包ERP及其相关系统的方法是利用应用服务提供商（application service provider, ASP）。 ERP系统只是ASP所提供的服务中的一种。 采用ASP能够给企业带来较低的成本，并提高系统的灵活性。比起企业内部建立的系统，ASP的服务往往更为可靠，价格也比较便宜。可以节约软件开发和升级的费用。 企业通常选择从ASP那里获取部分的ERP服务，而不是让它们开发完整的ERP系统。 ASP的不足 走ASP路线来获得ERP服务，存在以下几种风险： 安全问题。 服务失效。 机密性失效。 表现不佳。 表5.4不同实施方法工作量之比较 方法 内部开发 供应商 咨询人员 单一供应商产品 重大 负担重 负担重 单一供应商产品加以修改 重大＋ 负担重 负担重＋ 单项最优 重大＋ 一般 负担重＋ 多个供应商不同模块加以修改 重大＋＋ 一般 负担重＋ 内部开发 极度艰难 无 也许有用 内部开发加上模块 比较费力 一般 也许有用 应用程序服务提供商 相当轻松 无 可以选择 表5.5不同实施方法的相对优缺点 方法 优点 缺点 单一供应商产品 在可控制的方法中实施速度最快 并发问题最少 采用的业务流程经过实践检验 受到供应商对系统更改的限制 实质上失去了内部开发可能带来的竞争优势 单一供应商产品加以修改 更能适应组织的工作方法 对系统的修改带来了不能按时完成的风险 单项最优 能够为各部门职能选择最好的方法 风险很高，不同模块的协作存在问题 多个供应商不同模块加以修改 最