软件开发模式.pptVIP

用后丢弃式雏型策略(c.11) 仅实施在风险程度最高的地方，例如需求或解决问题之知识、概念与信息科技整合最不清楚的情况。因为雏型之丢弃也意味着成本的浪费。 其它情况则尽可能的采用演进式雏型策略。 螺旋模式 导入项目管理的概念与方法，为一风险导向的模式。 由三个步骤形成一周期： (1) 找出系统的目标、可行之实施方案与限制。 (2) 依目标与限制评估方案，解决风险。 (3) 并由剩下之相关风险，决定该步骤该如何进行。 此周期反复进行，直到系统开发完成为止。 螺旋模式 (c.2) 螺旋模式 (c.3) 步骤一、找出系统的目标、可行之实施方案与限制 (1) 找出系统的目标 系统目标之评核因素很多，例如系统的绩效、功能与容忍改变之能力等。 (2) 找出系统之实施方案 系统实施方案会因问题而异，例如找出之方案有设计A、设计B、重用、购买等。 (3) 实施方案之限制 实施方案之限制可能为项目之成本、时程、系统接口等。 螺旋模式 (c.4) 步骤二、依目标与限制评估方案，解决风险 主要是找出各方案之不确定处，并设法解决，其步骤如下： (1) 找出项目风险之重要来源。 (2) 解决风险来源： 可用雏型、模拟、标竿 (Benchmarking)、参考点检查 (Reference Checking)、问卷、分析模式、上述之综合或其它技术以解决风险。 螺旋模式 (c.5) 步骤三、由剩下之风险决定该步骤 若系统的绩效或使用者接口风险将强力影响程序开发或内部接口控制，则此步骤可能是采取演进式雏型。 若该雏型使用性佳且够强韧（Robust），足以当做未来系统发展之基础，则往后将是一系列的雏型演进。 假如先前之雏型努力已解决了所有的绩效或使用者接口之风险，则此一步将遵循基本的瀑布模式，亦可适当的修饰以整合渐增模式。 螺旋模式 (c.6) 特色与应用原则： 在高风险部分之设计尚未稳定前，规格之发展不需要一致、详尽或正式，以避免不必要之设计修改。 在开发之任一阶段，螺旋模式可选择整合雏型模式以降低风险。 不同周期，可能采用不同的开发模式。 当更吸引人之方案被找出，或新风险需被解决时，可整合重做或回到前面之阶段。 螺旋模式 (c.7) 包含了现有模式之大部分优点，其风险导向之方法解决了许多模式之问题。在某些条件下，螺旋模式相当于某一现有之模式。例如： (1) 若项目在系统的绩效或使用者接口需求方面属于低风险，且在预算及时程控制方面属于高风险，则这些风险之考虑会使螺旋模式之执行相当于瀑布模式或渐增模式。 (2)若项目在预算及时程控制、大型系统之整合或需求变动方面之风险较低，且在系统的绩效、使用者接口或使用者决策支持需求方面之风险较高，则这些风险之考虑会使螺旋模式之执行类似于雏型模式。 同步模式 主要是为了缩短系统开发时间，加速版本之更新，因应商业软件包的市场竞争。 适用情形： 需求可明确与完整的描述。 有足够的人力参与。 团队间有良好的沟通、信息交换与项目管理。 同步模式(c.2) 优点： 开发时间的缩短可提高产品的竞争力。 缺点： 紧凑的步骤及频繁的信息沟通，使得项目管理的复杂度大幅提高，人力成本也相对提高。 若没有辅以良好的工具及管理方法，则不易达成目标。 同步模式(c.3) 基于三个主要的构想来达到时程缩短的目标： 多个团队同时开发。这种多组人同时工作的方式称为活动同步（Activity Concurrency）。 同步模式 (c.4) 同步模式(c.5) 信息同步。不同团队的信息互相交流与共享称为信息同步（Information Concurrency）。 信息同步有三个技巧： (1) 向前传递(Front Loading) (2) 向后传递(Flying) (3) 建立有效的信息交换网络及群体工作的支持环境 整合性的管理系统。同步开发方法的管理方法比一般的系统开发复杂，必须开发一个管理系统以协调人员、资源、过程和产品间复杂的互动关系。 同步模式 (c.6) 同步模式 (c.7) RUP 模式 RUP (Rational Unified Process) 模式于1998由Ivar Jacobson、Grady Booch和James Rumbaugh提出。 以架构为中心(Architecture-Centric)的开发模式。 结合螺旋模式的概念，以「反复式」(Iterative)与「渐增式」(Incremental)的软件开发原理进行软件开发。 反复式意指重复用相同的的一系列操作或步骤以进行软件开发。 渐增式意指每一次在软件产品上新增工功能、模块、组件或子系统等。 RUP 模式(c.2) 每一次的反复需产出一个可运作的系统版本，并在每一个反复周期评估风险，以尽早发现问题。 不需假设项目开始时，使用者需求可完整且清楚描述。 可由动态与静态两个构