螺旋模式 (c.7)
• 包含了现有模式之大部分优点，其风险导向之方法解决了 许多模式之问题。在某些条件下，螺旋模式相当于某一现 有之模式。例如： – (1) 若项目在系统的绩效或使用者接口需求方面属于低 风险，且在预算及时程控制方面属于高风险，则这些 风险之考虑会使螺旋模式之执行相当于瀑布模式或渐 增模式。 – (2)若项目在预算及时程控制、大型系统之整合或需求 变动方面之风险较低，且在系统的绩效、使用者接口 或使用者决策支持需求方面之风险较高，则这些风险 之考虑会使螺旋模式之执行类似于雏型模式。
需 求 分 析
教 育 訓 練
操 作 與 維 護
瀑布模式 (c.6)
• 瀑布模式的一些问题：
– 假设在项目开始时，需求可完整且清楚描述， – 所有需求在各阶段均需同时考虑，且系统开发 在一个周期内完成， – 在程序编辑前过于强调完整的分析与设计文件， 故一但需求变更，文件需大幅修改， – 程序编辑于系统开发周期之后段才开始，故风 险较高，且失败之成本亦较高，
螺旋模式
• 导入项目管理的概念与方法，为一风险导 向的模式。 • 由三个步骤形成一周期：
– (1) 找出系统的目标、可行之实施方案与限制。 – (2) 依目标与限制评估方案，解决风险。 – (3) 并由剩下之相关风险，决定该步骤该如何进 行。
• 此周期反复进行，直到系统开发完成为止。
螺旋模式 (c.2)
螺旋模式 (c.6)
• 特色与应用原则：
– 在高风险部分之设计尚未稳定前，规格之发展 不需要一致、详尽或正式，以避免不必要之设 计修改。 – 在开发之任一阶段，螺旋模式可选择整合雏型 模式以降低风险。 – 不同周期，可能采用不同的开发模式。 – 当更吸引人之方案被找出，或新风险需被解决 时，可整合重做或回到前面之阶段。
• 虽已改善了编码与修正模式之问题，但使 用上仍衍生以下之问题：
– 不论系统之大小或复杂程度均需经历八阶段， – 各阶段之进行是循序的且阶段间没有回馈， – 各阶段均需考虑完整的系统范围，不可仅考虑 部份系统， – 假设使用者需求可完整且清楚的描述。
瀑布模式
• 开发的过程分成几个阶段，且划分上较有 弹性。 • 每个阶段清楚定义要做那些工作及交付那 些文件，使系统开发之工作更明确及容易 掌握。 • 可允许阶段间之回馈，若在各阶段发现错 误，能尽早修正以减少系统修改或重做之 成本。 • 各阶段循序的执行且仅循环一次。
– (3) 实施方案之限制
• 实施方案之限制可能为项目之成本、时程、系统接 口等。
螺旋模式 (c.4)
• 步骤二、依目标与限制评估方案，解决风 险
– 主要是找出各方案之不确定处，并设法解决， 其步骤如下： – (1) 找出项目风险之重要来源。 – (2) 解决风险来源：
• 可用雏型、模拟、标竿 (Benchmarking)、参考点检 查 (Reference Checking)、问卷、分析模式、上述之 综合或其它技术以解决风险。
雏型模式 (c.4)
• 其它适用情形：
– 当无法立即获得解决问题的方法。 – 当软／硬件之技术与支持不确定。
雏型模式 (c.5)
• 雏型模式的潜在问题：
– 系统文件较不完备，程序亦较难维护。短期可 能较能满足使用者需求，但长期而言系统较易 失败。 – 因缺乏整体之规划、分析与设计，故较不适合 于大型及多人参与之系统开发项目。
用后丢弃式雏型策略(c.10)
• 雏型丢弃之原因，如
– – – – 开发工具不同， 操作系统不兼容， 设计方法不兼容， …
用后丢弃式雏型策略(c.11)
• 仅实施在风险程度最高的地方，例如需求 或解决问题之知识、概念与信息科技整合 最不清楚的情况。因为雏型之丢弃也意味 着成本的浪费。 • 其它情况则尽可能的采用演进式雏型策略。
Ö n ¨ » ² ¿ ¦ ¥ g L U B J i i ¸ ¹ ¦ ¨ Æ ¶ ® M w Ø Ð B i æ è × Î ¨ © ¥ ¼ ¡ ¥ ¦ ¤ ® ¤ ­ ¨ î è × û ô B · À Ñ O P Ñ R ¤ ® µ ¦ ¡ ­ I Ã § » ¸ ª ­ · ­ · ­ · Ó Õ © ¿ ^ U ¦ Å À Î ¤ ³ Ý D p e » ¨ ­ µ Í R g Á p e ¥ © ¶ ´ ­ µ o i p e µ ® ­ µ ã X P ú Õ p e ¾ ¦ » ´ ¸ ­ µ · I ­ À À R ¤ ª À I ¤ À À I ª R ú ¬ Â « 2 ú ¬ Â « 3 i Þ @ ¥ ¾ § ú ¬ Â « À I ¤ À ¤ À ª R ª R
同步模式
• 主要是为了缩短系统开发时间，加速版本 之更新，因应商业软件包的市场竞争。 • 适用情形：
– 需求可明确与完整的描述。 – 有足够的人力参与。 – 团队间有良好的沟通、信息交换与项目管理。
同步模式(c.2)
• 优点：
– 开发时间的缩短可提高产品的竞争力。
• 缺点：
– 紧凑的步骤及频繁的信息沟通，使得项目管理 的复杂度大幅提高，人力成本也相对提高。 – 若没有辅以良好的工具及管理方法，则不易达 成目标。
软件开发模式
内容大纲
• • • • • • • • • • • • 导论 编码与修正模式 阶段模式 瀑布模式 渐增模式 原型模式 螺旋模式 同步模式 RUP模式 第四代技术 快速应用软体开发 结论
导论
• 「软件开发模式」是描述软件开发过程的 一系列步骤及其执行程序。 • 开发的过程依循系统化、逻辑化的步骤进 行时，将有利于标准、规范与政策之推行 和建立，而且开发过程将更有效率，更能 确保品质量，也更容易管理。 • 不同的开发模式，选用于不同情况的系统 开发。
渐增模式 (c.2)
需 求分 析 漸 增開 發規 劃
週期1 週期2 週期n
其他 發展 階段
其他 發展 階段
其他 發展 階段
漸增系 統 1
漸增系 統2
最終系 統
使 用者
：新發展 的
பைடு நூலகம்
：再使用 的
：未完成 的
渐增模式 (c.3)
• 特色：
– 系统被分成几个子系统或功能，各子系统可独 立依序或平行开发。 – 系统开发可由多个周期完成，每个周期均有分 析设计、程序编辑及测试，每个周期完成不同 版本之系统。 – 使用者参与程度高，每个周期均参与，故相较 于瀑布模式，渐增模式之风险较低。
ú ¬ Â « 1
Ò ¼ À ¡ ¼ « ¡ ¤ · ¼ ° B Ò ¬ B ô Ç Ð O @ ~ [ À § · Æ © n é Ý D ³ Å » ¨ Ý D ç Ò » ¨ Å Ã ] p T { Î ç Ò ³ ­ ½ » ¤ Å Ã ç ¬ Å ¦ ú Õ ´ ¸ n é £ ³ Å ² ~ ] p « ³ ­ æ ¸ ³ ¤ ú Õ ã X ¾ ¦ & ´ ¸ ú Õ ´ ¸ o i B ç Ò U ¥ h § £ « µ ® ¡ Å Ã ¤ ¶ ¼ ¤ ² ª Ó ¡ ² ³ ] p ³ ­ s X ½ ½
同步模式(c.3)
• 基于三个主要的构想来达到时程缩短的目 标：
– 多个团队同时开发。这种多组人同时工作的方 式称为活动同步（Activity Concurrency）。
同步模式 (c.4)
} ¶ l © \ ¥ à ¯ Õ ² º ¹ À ¤
瀑布模式 (c.7)
– (5)系统开发周期较长且过程中使用者参与不足。
明確的、 完整的 需求 最終系統 使用者 使用者
渐增模式
• 把需求分成几个部分，然后将每个部分的 需求之开发订为一个开发周期，每个周期 可依序或平行开发。 • 每个周期之阶段清楚定义要做那些工作及 交付那些文件， • 每个周期内，各阶段循序进行且仅循环一 次。
演进式雏型策略 (c.8)
週 期N 週 期2
週 期1
系 統 開 發 各 階 段
系 統 開 發 各 階 段
系 統 開 發 各 階 段
版 本1
版 本2
最 終版 本
使用者
用后丢弃式雏型策略(c.9)
• 以一种快而粗糙(Quick and Dirty)的方式建 立雏型，以促使使用者能够尽快藉由与雏 型之互动来决定需求项目，或信息人员藉 以研发问题之解决方法与信息科技之应用。 • 应用该策略开发之雏型，不需考虑系统之 运用效率、可维护性与容错能力等。
螺旋模式 (c.5)
• 步骤三、由剩下之风险决定该步骤
– 若系统的绩效或使用者接口风险将强力影响程 序开发或内部接口控制，则此步骤可能是采取 演进式雏型。 – 若该雏型使用性佳且够强韧（Robust），足以 当做未来系统发展之基础，则往后将是一系列 的雏型演进。 – 假如先前之雏型努力已解决了所有的绩效或使 用者接口之风险，则此一步将遵循基本的瀑布 模式，亦可适当的修饰以整合渐增模式。
瀑布模式 (c.2)
• 当系统较小或较单纯，划分的阶段可能少 至三个，例如分析、设计、实作 (Implementation) 等阶段。
瀑布模式 (c.3)
分 析
設 計
實 作
瀑布模式 (c.4)
• 若面对较大或复杂之系统时，其阶段可再 被细分成更多个阶段：
瀑布模式 (c.5)
可 行 性 分 析
雏型模式 (c.6)
• 有两种常见之应用策略：
– 演进式雏型 (Evolutionary Prototyping) – 用后丢弃雏型 (Rapid Throwaway Prototyping)
演进式雏型策略(c.7)
• 将所有需求看成一个整体，从需求最清楚 的部分快速的经历一开发周期，以完成初 版雏型系统， • 再利用该雏型与使用者沟通以确定、修改 和扩充需求，并藉以做为下一周期雏型演 进之依据， • 该周期不断的反复进行，一直到雏型系统 符合双方约定为止。
ê I ¹ ¬ p º U ¥ q ­ ¹ ¤ ¶ ¬