软件开发模式

软件开发模式第一页，共五十九页，编辑于2023年，星期三内容大纲导论编码与修正模式阶段模式瀑布模式渐增模式原型模式螺旋模式同步模式RUP模式第四代技术快速应用软体开发结论第二页，共五十九页，编辑于2023年，星期三导论「软件开发模式」是描述软件开发过程的一系列步骤及其执行程序。开发的过程依循系统化、逻辑化的步骤进行时，将有利于标准、规范与政策之推行和建立，而且开发过程将更有效率，更能确保品质量，也更容易管理。不同的开发模式，选用于不同情况的系统开发。第三页，共五十九页，编辑于2023年，星期三软件开发模式编码与修正模式阶段模式瀑布模式渐增模式雏型模式螺旋模式同步模式RUP模式第四页，共五十九页，编辑于2023年，星期三各种开发模式之演进第五页，共五十九页，编辑于2023年，星期三编码与修正模式无方法论可言，主要包含两个步骤：先写部分程序，再修正程序中之问题。

第六页，共五十九页，编辑于2023年，星期三编码与修正模式(c.2)主要之问题：过程中没有规划(plan)、分析及设计，故经过几次修正之后，程序代码的逻辑变得难以理解。无使用者需求分析与确认，软件虽设计得很好，但可能并不符合使用者的需求。第七页，共五十九页，编辑于2023年，星期三阶段模式具有方法论之雏型。

改善了编码与修正模式之问题，强调系统开发前要有规划(plan)，程序编码(coding)前要有分析与设计，系统上线前要有测试(testing)等。第八页，共五十九页，编辑于2023年，星期三阶段模式(c.2)第九页，共五十九页，编辑于2023年，星期三阶段模式(c.3)虽已改善了编码与修正模式之问题，但使用上仍衍生以下之问题：不论系统之大小或复杂程度均需经历八阶段，各阶段之进行是循序的且阶段间没有回馈，各阶段均需考虑完整的系统范围，不可仅考虑部份系统，假设使用者需求可完整且清楚的描述。

第十页，共五十九页，编辑于2023年，星期三瀑布模式开发的过程分成几个阶段，且划分上较有弹性。每个阶段清楚定义要做那些工作及交付那些文件，使系统开发之工作更明确及容易掌握。可允许阶段间之回馈，若在各阶段发现错误，能尽早修正以减少系统修改或重做之成本。各阶段循序的执行且仅循环一次。第十一页，共五十九页，编辑于2023年，星期三瀑布模式(c.2)当系统较小或较单纯，划分的阶段可能少至三个，例如分析、设计、实作(Implementation)等阶段。第十二页，共五十九页，编辑于2023年，星期三瀑布模式(c.3)分析實作設計第十三页，共五十九页，编辑于2023年，星期三瀑布模式(c.4)若面对较大或复杂之系统时，其阶段可再被细分成更多个阶段：第十四页，共五十九页，编辑于2023年，星期三瀑布模式(c.5)第十五页，共五十九页，编辑于2023年，星期三瀑布模式(c.6)瀑布模式的一些问题：假设在项目开始时，需求可完整且清楚描述，所有需求在各阶段均需同时考虑，且系统开发在一个周期内完成，在程序编辑前过于强调完整的分析与设计文件，故一但需求变更，文件需大幅修改，程序编辑于系统开发周期之后段才开始，故风险较高，且失败之成本亦较高，第十六页，共五十九页，编辑于2023年，星期三瀑布模式(c.7)(5)系统开发周期较长且过程中使用者参与不足。明確的、完整的需求最終系統使用者使用者第十七页，共五十九页，编辑于2023年，星期三渐增模式把需求分成几个部分，然后将每个部分的需求之开发订为一个开发周期，每个周期可依序或平行开发。每个周期之阶段清楚定义要做那些工作及交付那些文件，每个周期内，各阶段循序进行且仅循环一次。第十八页，共五十九页，编辑于2023年，星期三渐增模式(c.2)第十九页，共五十九页，编辑于2023年，星期三渐增模式(c.3)特色：系统被分成几个子系统或功能，各子系统可独立依序或平行开发。系统开发可由多个周期完成，每个周期均有分析设计、程序编辑及测试，每个周期完成不同版本之系统。使用者参与程度高，每个周期均参与，故相较于瀑布模式，渐增模式之风险较低。

第二十页，共五十九页，编辑于2023年，星期三渐增模式(c.4)渐增模式适用之情况：(1)目标与需求可完全与清楚描述。(2)预算需分期编列。(3)需要时间来熟悉和接受新科技。第二十一页，共五十九页，编辑于2023年，星期三雏型模式此方法先针对使用者需求较清楚的部分或信息人员较能掌握之部份，依分析、设计与实施等步骤快速进行雏型系统开发。过程中，强调尽早以雏型系统做为使用者与信息人员需求沟通与学习之工具，双方透过雏型之操作与回馈，以厘清、修改及扩充需求，并藉以修改与扩充雏型系统。上述步骤反复进行，直到系统符合双方约定为止。雏型系统有时是一个：只有使用者界面，而没有核心部分的软件。第二十二页，共五十九页，编辑于2023年，星期三雏型模式(c.2)第二十三页，共五十九页，编辑于2023年，星期三雏型模式(c.3)主要特性与原则：强调雏型之尽早开发及使用者高度的参与。强调以雏型作为使用者及系统开发者之需求沟通与学习机制。从需求最清楚部分着手开发雏型，并透过使用者对雏型之操作与回馈，反复修改与扩充，每次反复之周期要尽可能缩短。第二十四页，共五十九页，编辑于2023年，星期三雏型模式(c.4)其它适用情形：当无法立即获得解决问题的方法。当软／硬件之技术与支持不确定。第二十五页，共五十九页，编辑于2023年，星期三雏型模式(c.5)雏型模式的潜在问题：系统文件较不完备，程序亦较难维护。短期可能较能满足使用者需求，但长期而言系统较易失败。因缺乏整体之规划、分析与设计，故较不适合于大型及多人参与之系统开发项目。第二十六页，共五十九页，编辑于2023年，星期三雏型模式(c.6)有两种常见之应用策略：演进式雏型(EvolutionaryPrototyping)

用后丢弃雏型(RapidThrowawayPrototyping)

第二十七页，共五十九页，编辑于2023年，星期三演进式雏型策略(c.7)将所有需求看成一个整体，从需求最清楚的部分快速的经历一开发周期，以完成初版雏型系统，再利用该雏型与使用者沟通以确定、修改和扩充需求，并藉以做为下一周期雏型演进之依据，该周期不断的反复进行，一直到雏型系统符合双方约定为止。

第二十八页，共五十九页，编辑于2023年，星期三演进式雏型策略(c.8)第二十九页，共五十九页，编辑于2023年，星期三用后丢弃式雏型策略(c.9)以一种快而粗糙(QuickandDirty)的方式建立雏型，以促使使用者能够尽快藉由与雏型之互动来决定需求项目，或信息人员藉以研发问题之解决方法与信息科技之应用。应用该策略开发之雏型，不需考虑系统之运用效率、可维护性与容错能力等。

第三十页，共五十九页，编辑于2023年，星期三用后丢弃式雏型策略(c.10)雏型丢弃之原因，如开发工具不同，操作系统不兼容，设计方法不兼容，…第三十一页，共五十九页，编辑于2023年，星期三用后丢弃式雏型策略(c.11)仅实施在风险程度最高的地方，例如需求或解决问题之知识、概念与信息科技整合最不清楚的情况。因为雏型之丢弃也意味着成本的浪费。其它情况则尽可能的采用演进式雏型策略。第三十二页，共五十九页，编辑于2023年，星期三螺旋模式导入项目管理的概念与方法，为一风险导向的模式。由三个步骤形成一周期：(1)找出系统的目标、可行之实施方案与限制。(2)依目标与限制评估方案，解决风险。(3)并由剩下之相关风险，决定该步骤该如何进行。此周期反复进行，直到系统开发完成为止。第三十三页，共五十九页，编辑于2023年，星期三螺旋模式(c.2)第三十四页，共五十九页，编辑于2023年，星期三螺旋模式(c.3)步骤一、找出系统的目标、可行之实施方案与限制(1)找出系统的目标系统目标之评核因素很多，例如系统的绩效、功能与容忍改变之能力等。(2)找出系统之实施方案系统实施方案会因问题而异，例如找出之方案有设计A、设计B、重用、购买等。(3)实施方案之限制实施方案之限制可能为项目之成本、时程、系统接口等。

第三十五页，共五十九页，编辑于2023年，星期三螺旋模式(c.4)步骤二、依目标与限制评估方案，解决风险主要是找出各方案之不确定处，并设法解决，其步骤如下：(1)找出项目风险之重要来源。(2)解决风险来源：可用雏型、模拟、标竿(Benchmarking)、参考点检查(ReferenceChecking)、问卷、分析模式、上述之综合或其它技术以解决风险。第三十六页，共五十九页，编辑于2023年，星期三螺旋模式(c.5)步骤三、由剩下之风险决定该步骤若系统的绩效或使用者接口风险将强力影响程序开发或内部接口控制，则此步骤可能是采取演进式雏型。若该雏型使用性佳且够强韧（Robust），足以当做未来系统发展之基础，则往后将是一系列的雏型演进。假如先前之雏型努力已解决了所有的绩效或使用者接口之风险，则此一步将遵循基本的瀑布模式，亦可适当的修饰以整合渐增模式。

第三十七页，共五十九页，编辑于2023年，星期三螺旋模式(c.6)特色与应用原则：在高风险部分之设计尚未稳定前，规格之发展不需要一致、详尽或正式，以避免不必要之设计修改。在开发之任一阶段，螺旋模式可选择整合雏型模式以降低风险。不同周期，可能采用不同的开发模式。当更吸引人之方案被找出，或新风险需被解决时，可整合重做或回到前面之阶段。第三十八页，共五十九页，编辑于2023年，星期三螺旋模式(c.7)包含了现有模式之大部分优点，其风险导向之方法解决了许多模式之问题。在某些条件下，螺旋模式相当于某一现有之模式。例如：(1)若项目在系统的绩效或使用者接口需求方面属于低风险，且在预算及时程控制方面属于高风险，则这些风险之考虑会使螺旋模式之执行相当于瀑布模式或渐增模式。(2)若项目在预算及时程控制、大型系统之整合或需求变动方面之风险较低，且在系统的绩效、使用者接口或使用者决策支持需求方面之风险较高，则这些风险之考虑会使螺旋模式之执行类似于雏型模式。第三十九页，共五十九页，编辑于2023年，星期三同步模式主要是为了缩短系统开发时间，加速版本之更新，因应商业软件包的市场竞争。适用情形：需求可明确与完整的描述。有足够的人力参与。团队间有良好的沟通、信息交换与项目管理。第四十页，共五十九页，编辑于2023年，星期三同步模式(c.2)优点：开发时间的缩短可提高产品的竞争力。缺点：紧凑的步骤及频繁的信息沟通，使得项目管理的复杂度大幅提高，人力成本也相对提高。若没有辅以良好的工具及管理方法，则不易达成目标。

第四十一页，共五十九页，编辑于2023年，星期三同步模式(c.3)基于三个主要的构想来达到时程缩短的目标：多个团队同时开发。这种多组人同时工作的方式称为活动同步（ActivityConcurrency）。第四十二页，共五十九页，编辑于2023年，星期三同步模式(c.4)第四十三页，共五十九页，编辑于2023年，星期三同步模式(c.5)信息同步。不同团队的信息互相交流与共享称为信息同步（InformationConcurrency）。

信息同步有三个技巧：(1)向前传递(FrontLoading)(2)向后传递(Flying)(3)建立有效的信息交换网络及群体工作的支持环境整合性的管理系统。同步开发方法的管理方法比一般的系统开发复杂，必须开发一个管理系统以协调人员、资源、过程和产品间复杂的互动关系。

第四十四页，共五十九页，编辑于2023年，星期三同步模式(c.6)第四十五页，共五十九页，编辑于2023年，星期三同步模式(c.7)第四十六页，共五十九页，编辑于2023年，星期三RUP模式RUP(RationalUnifiedProcess)模式于1998由IvarJacobson、GradyBooch和JamesRumbaugh提出。以架构为中心(Architecture-Centric)的开发模式。结合螺旋模式的概念，以「反复式」(Iterative)与「渐增式」(Incremental)的软件开发原理进行软件开发。反复式意指重复用相同的的一系列操作或步骤以进行软件开发。渐增式意指每一次在软件产品上新增工功能、模块、组件或子系统等。第四十七页，共五十九页，编辑于2023年，星期三RUP模式(c.2)每一次的反复需产出一个可运作的系统版本，并在每一个反复周期评估风险，以尽早发现问题。不需假设项目开始时，使用者需求可完整且清楚描述。可由动态与静态两个构面来说明系统开发项目之实施阶段与核心工作。第四十八页，共五十九页，编辑于2023年，星期三RUP模式(c.3)动态构面把软件开发依序分成四个主要阶段：初始、详述、建构与转移。这四个阶段构成一个周期，周期可反复进行，每个周期内之各阶段也可以视情况反复进行。静态构面主要表达成九个核心工作流程(Workflows)或过程(Processes)：有六项属于软件工程工作：企业模型、需求、分析与设计、实作、测试、配置(Deployment)三项属于管理支持工作：项目管理、组态管理与变动管理、环境第四十九页，共五十九页，编辑于2023年，星期三RUP模式(c.4)第五十页，共五十九页，编辑于2023年，星期三第四代技术*第四代技术(4thGenerationTechniques,4GT)指的是输入图形(diagrams)或特殊语言，可以自动产生原始程序代码的技术。图形(diagrams)或特殊语言主要是用来描述软件的特性与行为，4GT根据这些描述来产生原始程序代码。这些输入就是所谓的第四代语言(4GL)。第五十一页，共五十九页，编辑于2023年，星期三第四代技术(c.2)采用4GT开发软件，还是要经过分析、设计、编码、测试、维护等阶段。采用4GT开发的方式，必须使得软件易于维护。使用4GT开发小型软件，有时可直接从需求撷取的阶段跳到实施(Implementation)的阶段。若和组件开发方式合用，4GT可能便变成软件开发的主要方法。第五十二页，共五十九页，编辑于2023年，星期三第四代技术(c.3)优点支持者声称可加快开发的速度，提升生产力。缺点反对者声称4GT的工具不比程序语言简单，产生的原始程序代码执行效率差，4GT产生的大型软件，其维护仍然是个问题。第五十三页，共五十九页，编辑于2023年，星期