软件开发模式教学课件.ppt

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

2、与修正模式(c.2)主要之问题：过程中没有规划(plan)、分析及设计，故经过几次修正之后，程序代码的逻辑变得难以理解。无使用者需求分析与确认，软件虽设计得很好，但可能并不符合使用者的需求。阶段模式 具有方法论方法论之雏型。改善了编码与修正模式之问题，强调 系统开发前要有规划(plan)，程序编码(coding)前要有分析与设计，系统上线前要有测试(testing)等。阶段模式(c.2)作業規劃編碼程式規格描述作業規格描述系統評估上線測試整合測試參數測試阶段模式(c.3)虽已改善了编码与修正模式之问题，但使用上仍衍生以下之问题：不论系统之大小或复杂程度均需经历八阶段，各阶段之进行是循序的且阶段

3、间没有回馈，各阶段均需考虑完整的系统范围，不可仅考虑部份系统，假设使用者需求可完整且清楚的描述。瀑布模式 开发的过程分成几个阶段，且划分上较有划分上较有弹性。弹性。每个阶段清楚定义要做那些工作及交付那每个阶段清楚定义要做那些工作及交付那些文件些文件，使系统开发之工作更明确及容易掌握。可允许阶段间之回馈可允许阶段间之回馈，若在各阶段发现错误，能尽早修正以减少系统修改或重做之成本。各阶段循序的执行且仅循环一次。瀑布模式(c.2)当系统较小或较单纯，划分的阶段可能少至三个，例如分析、设计、实作(Implementation)等阶段。瀑布模式(c.3)分 析實 作設 計瀑布模式(c.4)若面对较大或复

4、杂之系统时，其阶段可再被细分成更多个阶段：瀑布模式(c.5)可行性分析操作與維護教育訓練需求分析瀑布模式(c.6)瀑布模式的一些问题：假设在项目开始时，需求可完整且清楚描述，所有需求在各阶段均需同时考虑，且系统开发在一个周期内完成，在程序编辑前过于强调完整的分析与设计文件，故一但需求变更，文件需大幅修改，程序编辑于系统开发周期之后段才开始，故风险较高，且失败之成本亦较高，瀑布模式(c.7)(5)系统开发周期较长且过程中使用者参与不足。明確的、完整的需求最終系統使用者使用者渐增模式 把需求分成几个部分需求分成几个部分，然后将每个部分的部分的需求需求之开发订为一个开发周期，每个周期可依序或平行开发

5、。每个周期之阶段清楚定义要做那些工作及交付那些文件，每个周期内，各阶段循序进行且仅循环一次。渐增模式(c.2)需求分析漸增開發規劃其他發展階段其他發展階段其他發展階段漸增系統1最終系統漸增系統2使用者：新發展的：未完成的：再使用的週期1週期2週期n渐增模式(c.3)特色：系统被分成几个子系统或功能，各子系统可独立依序或平行开发。系统开发可由多个周期完成，每个周期均有分析设计、程序编辑及测试，每个周期完成不同版本之系统。使用者参与程度高，每个周期均参与，故相较于瀑布模式，渐增模式之风险较低。渐增模式(c.4)渐增模式适用之情况：(1)目标与需求可完全与清楚描述。(2)预算需分期编列。(3)需要时

6、间来熟悉和接受新科技。雏型模式 此方法先针对使用者需求较清楚的部分或信息人员较能掌握之部份，依分析、设计与实施等步骤快速进行雏型系统开发。过程中，强调尽早以雏型系统做为使用者与信息人员需求沟通与学习之工具，双方透过雏型之操作与回馈，以厘清、修改及扩充需求，并藉以修改与扩充雏型系统。上述步骤反复进行，直到系统符合双方约定为止。雏型系统有时是一个：只有使用者界面，而没有核心部分的软件。雏型模式(c.2)需求擷取分析主要參與人員開發程序雛型開發操作及檢討雛型和需求是否完全符合雙方約定結束是否雙方資訊人員雙方雙方雏型模式(c.3)主要特性与原则：强调雏型之尽早开发及使用者高度的参与。强调以雏型作为使用

7、者及系统开发者之需求沟通与学习机制。从需求最清楚部分着手开发雏型，并透过使用者对雏型之操作与回馈，反复修改与扩充，每次反复之周期要尽可能缩短。雏型模式(c.4)其它适用情形：当无法立即获得解决问题的方法。当软硬件之技术与支持不确定。雏型模式(c.5)雏型模式的潜在问题：系统文件较不完备，程序亦较难维护。短期可能较能满足使用者需求，但长期而言系统较易失败。因缺乏整体之规划、分析与设计，故较不适合于大型及多人参与之系统开发项目。雏型模式(c.6)有两种常见之应用策略：演进式雏型(Evolutionary Prototyping)用后丢弃雏型(Rapid Throwaway Prototyping)

8、演进式雏型策略(c.7)将所有需求看成一个整体，从需求最清楚的部分快速的经历一开发周期，以完成初版雏型系统，再利用该雏型与使用者沟通以确定、修改和扩充需求，并藉以做为下一周期雏型演进之依据，该周期不断的反复进行，一直到雏型系统符合双方约定为止。演进式雏型策略(c.8)系統開發各階段系統開發各階段系統開發各階段週期1週期N週期2使用者版本1版本2最終版本用后丢弃式雏型策略(c.9)以一种快而粗糙(Quick and Dirty)的方式建立雏型，以促使使用者能够尽快藉由与雏型之互动来决定需求项目，或信息人员藉以研发问题之解决方法与信息科技之应用。应用该策略开发之雏型，不需考虑系统之运用效率、可维护

9、性与容错能力等。用后丢弃式雏型策略(c.10)雏型丢弃之原因，如 开发工具不同，操作系统不兼容，设计方法不兼容，用后丢弃式雏型策略(c.11)仅实施在风险程度最高的地方，例如需求或解决问题之知识、概念与信息科技整合最不清楚的情况。因为雏型之丢弃也意味着成本的浪费。其它情况则尽可能的采用演进式雏型策略。螺旋模式 导入项目管理的概念与方法，为一风险导向的模式。由三个步骤形成一周期：(1)找出系统的目标、可行之实施方案与限制。(2)依目标与限制评估方案，解决风险。(3)并由剩下之相关风险，决定该步骤该如何进行。此周期反复进行，直到系统开发完成为止。螺旋模式(c.2)回顧承諾分割決定目標、可行方案及限

10、制累積成本經過各步驟進展風 險 分 析風 險 分 析風 險 分 析雛型 1雛型 2雛型 3可操作 雛型計劃下階段發展、驗證下階層之產物實施驗收測試整合&測試單元測試編碼細部設計需求驗證軟體需求設計確認及驗證軟體產品設計需求計畫生命週期計畫發展計畫整合與測試計畫方案評估、風險識別與解析風險分析模擬、模型、水準標記作業觀念螺旋模式(c.3)步骤一、找出系统的目标、可行之实施方步骤一、找出系统的目标、可行之实施方案与限制案与限制(1)找出系统的目标 系统目标之评核因素很多，例如系统的绩效、功能与容忍改变之能力等。(2)找出系统之实施方案 系统实施方案会因问题而异，例如找出之方案有设计A、设计B、重用

11、、购买等。(3)实施方案之限制 实施方案之限制可能为项目之成本、时程、系统接口等。螺旋模式(c.4)步骤二、依目标与限制评估方案，解决风步骤二、依目标与限制评估方案，解决风险险 主要是找出各方案之不确定处，并设法解决，其步骤如下：(1)找出项目风险之重要来源。(2)解决风险来源：可用雏型、模拟、标竿(Benchmarking)、参考点检查(Reference Checking)、问卷、分析模式、上述之综合或其它技术以解决风险。螺旋模式(c.5)步骤三、由剩下之风险决定该步骤步骤三、由剩下之风险决定该步骤 若系统的绩效或使用者接口风险将强力影响程序开发或内部接口控制，则此步骤可能是采取演进式雏型

12、。若该雏型使用性佳且够强韧（Robust），足以当做未来系统发展之基础，则往后将是一系列的雏型演进。假如先前之雏型努力已解决了所有的绩效或使用者接口之风险，则此一步将遵循基本的瀑布模式，亦可适当的修饰以整合渐增模式。螺旋模式(c.6)特色与应用原则：在高风险部分之设计尚未稳定前，规格之发展不需要一致、详尽或正式，以避免不必要之设计修改。在开发之任一阶段，螺旋模式可选择整合雏型模式以降低风险。不同周期，可能采用不同的开发模式。当更吸引人之方案被找出，或新风险需被解决时，可整合重做或回到前面之阶段。螺旋模式(c.7)包含了现有模式之大部分优点，其风险导向之方法解决了许多模式之问题。在某些条件下，螺

13、旋模式相当于某一现有之模式。例如：(1)若项目在系统的绩效或使用者接口需求方面属于低风险，且在预算及时程控制方面属于高风险，则这些风险之考虑会使螺旋模式之执行相当于瀑布模式或渐增模式。(2)若项目在预算及时程控制、大型系统之整合或需求变动方面之风险较低，且在系统的绩效、使用者接口或使用者决策支持需求方面之风险较高，则这些风险之考虑会使螺旋模式之执行类似于雏型模式。同步模式 主要是为了缩短系统开发时间，加速版本之更新，因应商业软件包的市场竞争。适用情形：需求可明确与完整的描述。有足够的人力参与。团队间有良好的沟通、信息交换与项目管理。同步模式(c.2)优点：开发时间的缩短可提高产品的竞争力。缺点

14、：紧凑的步骤及频繁的信息沟通，使得项目管理的复杂度大幅提高，人力成本也相对提高。若没有辅以良好的工具及管理方法，则不易达成目标。同步模式(c.3)基于三个主要的构想来达到时程缩短的目标：多个团队同时开发。这种多组人同时工作的方式称为活动同步（Activity Concurrency）。同步模式(c.4)開 始功能組劃分第一團隊開發第 團隊開發n獨立整合獨立測試結束下一版本下一版本同步模式(c.5)信息同步。不同团队的信息互相交流与共享称为信息同步（Information Concurrency）。信息同步有三个技巧：(1)向前传递(Front Loading)(2)向后传递(Flying)(3

15、)建立有效的信息交换网络及群体工作的支持环境 整合性的管理系统。同步开发方法的管理方法比一般的系统开发复杂，必须开发一个管理系统以协调人员、资源、过程和产品间复杂的互动关系。同步模式(c.6)基本系統:版本1功能組:1.1功能組:1.2功能組:1.3整合系統測試功能組:2.1功能組:2.2整合系統測試功能組:版本1功能組:版本1.1功能組:版本1.2功能組:版本1.3同步開發循序開發版本1版本2版本3交貨交貨版本1版本2同步模式(c.7)版本 n分析整合前之測試系統整合整合/系統測試功能組 1(次要)設計團隊A功能組 2(次要)功能組 i(次要)系統整合團隊測試團隊設計團隊B設計團隊C 版本

16、n+1分析整合前之測試系統整合整合/系統測試功能組 k(主要)設計團隊D設計團隊D和A功能組m(次要)功能組 j(次要)設計團隊C設計團隊B系統整合團隊測試團隊 版本 n+2分析整合前之測試系統整合整合/系統測試功能組 p(次要)設計團隊CRUP 模式 RUP(Rational Unified Process)模式于1998由Ivar Jacobson、Grady Booch和James Rumbaugh提出。以架构为中心(Architecture-Centric)的开发模式。结合螺旋模式的概念，以反复式(Iterative)与渐增式(Incremental)的软件开发原理进行软件开发。反复式

17、意指重复用相同的的一系列操作或步骤以进行软件开发。渐增式意指每一次在软件产品上新增工功能、模块、组件或子系统等。RUP 模式(c.2)每一次的反复需产出一个可运作的系统版本，并在每一个反复周期评估风险，以尽早发现问题。不需假设项目开始时，使用者需求可完整且清楚描述。可由动态与静态两个构面来说明系统开发项目之实施阶段与核心工作。RUP 模式(c.3)动态构面把软件开发依序分成四个主要阶段：初始、详述、建构与转移。这四个阶段构成一个周期，周期可反复进行，每个周期内之各阶段也可以视情况反复进行。静态构面主要表达成九个核心工作流程(Workflows)或过程(Processes)：有六项属于软件工程工

18、作：企业模型、需求、分析与设计、实作、测试、配置(Deployment)三项属于管理支持工作：项目管理、组态管理与变动管理、环境RUP 模式(c.4)第四代技术*第四代技术(4th Generation Techniques,4GT)指的是输入图形(diagrams)或特殊语言，可以自动产生原始程序代码的技术。图形(diagrams)或特殊语言主要是用来描述软件的特性与行为，4GT根据这些描述来产生原始程序代码。这些输入就是所谓的第四代语言(4GL)。第四代技术(c.2)采用4GT开发软件，还是要经过分析、设计、编码、测试、维护等阶段。采用4GT开发的方式，必须使得软件易于维护。使用4GT开发

19、小型软件，有时可直接从需求撷取的阶段跳到实施(Implementation)的阶段。若和组件开发方式合用，4GT可能便变成软件开发的主要方法。第四代技术(c.3)优点 支持者声称可加快开发的速度，提升生产力。缺点 反对者声称4GT的工具不比程序语言简单，产生的原始程序代码执行效率差，4GT产生的大型软件，其维护仍然是个问题。快速应用软件开发*快速应用软件开发(Rapid Application Development,RAD)强调以极短时间(约60-90天)完成软件的开发。程序的产生尽可能使用组件开发方式及第四代技术缩短开发时间。主要用于开发需求可完整且清楚描述的信息系统。分数个周期平行开发，

20、每一周期由一个团队完成一功能组(模块)。快速应用软件开发(c.2)一个周期包含：商业塑模(business modeling)资料塑模(data modeling)处理塑模(processing modeling)程序的产生(application generation)测试及修改(testing and turnover)快速应用软件开发(c.3)缺点 大型软件需有足够的人力参与。不适合开发技术风险高的软件。只适合能模块化的软件。使用者与信息人员双方都必须要有决心，互相配合，以便在极短时间内完成软件的开发。六个系统开发模式之比较信息系统特性与适用之开发模式结论 软件开发模式之发展，依其被提出之时间顺序，依序是阶段模式、瀑布模式、渐增模式、雏型模式、螺旋模式与同步模式。由于被提出之先后顺序不同，后来提出的模式大多针对前面模式之问题提出修正。