《软件项目管理》课件第3章.ppt

1、第3章 开发方法选择 第3章 开发方法选择 3.1 选择技术选择技术 3.2 选择过程模型选择过程模型 3.3 交付速度交付速度 3.4 边做边改模型边做边改模型 3.5 瀑布模型瀑布模型 3.6 瀑布模型的变种瀑布模型的变种3.7 螺螺 旋旋 模模 型型3.8 原型开发原型开发 3.9 分类原型的其它方面分类原型的其它方面3.10 渐进原型渐进原型3.11 增量交付增量交付 3.12 阶段交付阶段交付3.13 面向进度的设计面向进度的设计 3.14 渐进交付渐进交付 3.15 快速应用开发模型快速应用开发模型 3.16 并发开发模型并发开发模型 3.17 面向开发工具的设计面向开发工具的设计

2、 3.18 动态系统开发方法动态系统开发方法 3.19 极限编程极限编程 3.20 领域驱动设计领域驱动设计 3.21 成品软件成品软件 3.22 管理迭代过程管理迭代过程 3.23 选择最合适的生命周期选择最合适的生命周期3.24 小结小结 第3章 开发方法选择 3.1 选选 择择 技技 术术内部软件开发通常意味着：开发人员和用户属于同一组织；将正在考虑的应用程序嵌入，使其成为现有计算机系统的一部分；要使用的方法学和技术不是由项目经理来选择，而是由组织内部的标准来规定。第3章 开发方法选择 但是软件公司在为不同的外部客户成功地实现的开发项目中，每个项目使用的方法学和技术都要进行单独的评审。这

3、样就需要在项目分析的基础上做出评价，有的组织将这类决策制定过程称为“技术规划”。因此即使是内部项目开发，也要考虑与先前的项目使用不同的方法进行开发的、新项目的具体特征。通过对项目的分析以选择最合适的方法学和技术。方法学包括像统一软件开发过程(Unified Software Development Process，USDP)、结构化系统分析和设计方法(Structured Systems Analysis and Design Method，SSADM)以及领域驱动的设计(Domain-Driven Design，DDD)等，这些技术包括相应的应用构造和自动测试环境。第3章 开发方法选择 与产

4、品和活动一样，选择的技术将影响：开发人员的培训需求；要招聘的员工类型；开发环境(包括硬件和软件环境)；系统维护安排。因此，要选择某项技术，需要从这几个方面，进行详细分析，下面将阐述如何分析项目以选择合适的技术。第3章 开发方法选择 3.1.1 识别项目是目的驱动还是产品驱动识别项目是目的驱动还是产品驱动要区别项目的目标是为了生产一种产品，还是为了满足一定目的。一方面，项目可能生产客户规定的产品，客户负责验证该产品；另一方面，项目也可能为了满足一定的目的，有多种方法实现该目的，例如可以开发一个新的信息系统，来改进组织提供的服务，这时作为目的的服务标准是协议的主题，而不是特定信息系统的特征。很多软

5、件项目有2个阶段。第1阶段是目的驱动项目，以验证该软件系统能满足需求，是一个推荐活动过程；第2阶段实际创建该软件产品，是产品驱动项目，经过第1阶段的验证，可以进行规模生产。第3章 开发方法选择 理想情况下，项目经理有明确的目的，可以尽可能自由地选择满足目的的方法。例如在一个刚起步的公司中目的可能是要可靠地、准确地给员工支付报酬，并具有较低的管理费用，那么就没有必要在开始时就使用特定的软件解决方案，当然可能存在例外情况。第3章 开发方法选择 有时，项目的目的是不确定的或是未达成一致意见的主题。人们可能会遇到各种问题，但没有人知道如何正确地解决这些问题。ICT(Information Commun

6、ication Technology)专家可能为解决某些问题提供帮助，但是有些问题则需要来自其他领域的专家的帮助，在这种情况下可能需要考虑软系统方法(Soft Systems Methodology,SSM。软系统方法是一项运用系统思考解决非系统问题的定性研究技术，主要用于解决包含大量社会的、政治的以及人为因素的问题)。识别项目是目的驱动还是产品驱动有助于选择合适的技术。第3章 开发方法选择 3.1.2 分析其他项目特征分析其他项目特征区别软件项目之间的差异非常重要，因为在某一环境下适用的技术和方法，在另外的情境下就可能不适用了。了解项目特征便于选择合适的技术，通常会回答下面的问题：要实现的系

7、统是面向数据的还是面向过程的？面向数据的(Data-Oriented)系统通常指的是有实际数据库的信息系统；面向过程的(Process-Oriented)系统指的是嵌入式控制系统；同时具备两个要素的系统很少见。前者的系统界面是与组织的接口，例如库存管理系统，是组织管理订购原材料的信息系统；后者的系统界面是与机器的接口，例如空调控制系统，控制建筑物空调设备的嵌入式系统；二者兼具的系第3章 开发方法选择 统，例如，上面的库存管理系统可以控制一个自动化仓库。有人认为OO(Object-Oriented)方法更适用于面向过程的系统，在这类系统中控制要比数据库系统重要。要开发的软件是通用工具还是面向特定

8、应用领域的？通用工具的例子有电子表格或字处理程序包，特定应用领域的程序包如航空公司机票预订系统等。第3章 开发方法选择 要实现的应用程序是否是特殊类型的(已为这类应用程序开发了特定的工具)？例如：是否包含并发处理？要考虑使用适合这类系统的分析和设计技术。要创建的系统是不是基于知识的？专家系统都有规则(在应用于某个问题时会产生“专家建议”)，而且有开发这类系统的特定方法和工具。要产生的系统大量使用计算机图形吗？要创建的系统是不是安全至上的？例如系统中的故障是否会危及人的生命？如果是，测试就非常重要。第3章 开发方法选择 要创建的系统是用来执行已定义好的服务还是作为一种兴趣和娱乐？如果软件用来娱乐

9、，那么设计和评价会有别于一般的软件产品。要运行的系统的硬件/软件环境的特点是什么？最终软件要运行的环境可以不同于其他开发环境。嵌入式软件可能在大型开发机(有许多支持软件工具，比如编译器、调试器和静态分析工具等)上开发，但是软件要下载到小型处理器上运行。独立的桌面应用程序需要不同于大型机或客户/服务器环境的方法。第3章 开发方法选择 3.1.3 识别重要的项目风险识别重要的项目风险项目开始时，即使忽略许多影响项目的重要因素，管理人员还是期待有详细描述的计划。但是只有在仔细调查用户需求的基础上，才能估计项目需要多少工作量。开始时项目的不确定性越大，项目的风险就越大。但是一旦识别了特定领域的不确定性

10、，就可以采取相应的措施来降低这些不确定性。项目的不确定性与项目的产品、过程和资源有关。产品不确定性(Product Uncertainty)。对需求的理解如何？用户可能不能确定要构造的信息系统究竟要做什么。例如有些环境变化非常快，以至于表面上准确和有效的需求陈述很快就过时了。第3章 开发方法选择 过程不确定性(Process Uncertainty)。要开发的项目可能会使用对组织来说完全崭新的方法，开发方法的任何变更都会引入不确定性。例如极限编程(XP)或新的应用开发环境。资源不确定性(Pesource Uncertainty)。这里主要指具有合适的能力和经验的人员的可获得性，需要的资源数越多

11、或项目周期越长，隐含的风险就越高。有些因素增加了不确定性，例如不断地变更需求；而另一些因素增加了复杂性，例如软件规模。因此，需要不同的策略来处理这些截然不同的风险。第3章 开发方法选择 3.1.4 考虑与实现有关的用户需求考虑与实现有关的用户需求项目计划人员要保证假设或约束不会影响项目目标，例如开发校园管理系统的确切的规格说明。但是有时这类约束不可避免，比如整个组织要求使用相同的程序包来确保兼容性。客户组织通常会规定软件承包商必须采用的标准。例如，软件供应商要通过ISO 9000或CMMI认证，这会影响项目的实施方法。第3章 开发方法选择 3.1.5 选择生命周期方法选择生命周期方法选择项目所

12、使用的开发方法学和生命周期方法会受到前面问题的影响。对很多软件开发人员来说方法的选择很明显，使用过去用过的方法需要注意当前项目与以前项目的异同，并及时做出调整。但是如果开发者开发过去没有接触过的项目，就很有必要研究该项目中要用到的典型方法，这有助于选择最佳解决方案进行软件开发实践。下面是典型系统的解决方案：控制系统(Control System)实时系统需要使用合适的方法学来实现，具有并发处理的实时系统可能要使用诸如Petri网的技术。第3章 开发方法选择 信息系统(Information System)类似地，信息系统需要诸如SSADM或信息工程这样与环境类型相称的方法学。SSADM特别适合

13、于有大量的开发人员需要协同工作的项目，该方法详细规定了每步需要的活动和产品。因此开发组成员要确切地知道期望的是什么。通用工具(General Tool)如果软件是针对通用市场的，而不是针对特定的应用领域或用户的，就需要考虑诸如SSADM这样的方法学。该方法的制定者做出了有特定用户存在的假设，该方法的有些部分还假设要分析已有的文档来产生新的基于计算机系统的逻辑特征。第3章 开发方法选择 专用技术(Specialized Technique)例如已经发明了专家系统外壳和基于逻辑的程序设计语言来促进基于知识系统的开发。类似地，许多专用技术和工具可用于辅助基于图形系统的开发。硬件环境(Hardware

14、 Environment)系统要在硬件上运行的环境会制约实现该系统的方法。例如快速响应时间或计算机内存受限的需求可能意味着只能使用低级编程语言。第3章 开发方法选择 安全至上的系统(Safety-critical System)在安全性和可靠性至关重要的情况下使用诸如Z或VDM之类表示法的形式化规格说明的额外费用被证明是适用的。实际上，关键的系统要考虑让独立的小组并行开发具有相同功能系统的费用。然后可运行的系统要并行运行并不断进行交叉检测，这称为n版本编程。不准确的需求(Imprecise Requirement)不确定性或新颖的硬件、软件平台意味着应该考虑原型开发方法。如果系统要在其上实现的

15、环境是快速变化的，就特别需要考虑使用增量式交付。如果用户有与项目有关的不确定的目的，也可以考虑使用软系统方法。第3章 开发方法选择 3.1.6 技术计划技术计划通过项目分析提出要使用的实际技术需求，这些需求包括额外的活动、软件或硬件的获取或特定人员的培训等。所有这些都隐含着一定的成本，应该正式地记录下来。软件公司可能会产生初步的技术计划来帮助准备合同的投标。有时将计划展示给客户，以便解释投标价格的依据，并使客户对要使用方法的合理性留下深刻的印象。技术计划主要包含下面内容，如图3.1所示。第3章 开发方法选择 图3.1 技术计划内容清单(将这些技术内容展示给客户，以便解释投标价格的依据，使客户对

16、要使用方法的合理性留下深刻的印象)第3章 开发方法选择 3.2 选择过程模型选择过程模型软件开发过程模型(Software Development Process Model)是指软件开发全部过程、活动和任务的框架。软件开发包括需求、分析、设计、实现和测试等阶段，有时也包括维护阶段。软件开发过程模型能清晰、直观地表达软件开发全过程，明确定义要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法，使用不同的程序设计语言以及各种不同技能的人员参与工作，运用不同的管理方法和手段，并允许采用不同的软件工具和不同的软件工程环境。第3章 开发方法选择 最早出现的软件

17、开发模型是1970年Winston Royce提出的瀑布模型。该模型给出了固定的顺序，将生存期活动从上一个阶段向下一个阶段逐级过渡，如同流水下泻，最终得到所开发的软件产品，从而投入使用。但是瀑布模型存在着缺乏灵活性、无法通过并发活动澄清本来不够确切的需求等缺点。第3章 开发方法选择 典型的开发模型有：瀑布模型(Waterfall Model)、渐增模型/演化/迭代(Incremental model)、原型模型(Prototype Model)、螺旋模型(Spiral Model)、喷泉模型(Fountain Model)、智能模型(Intelligent Model)、混合模型(Hybrid

18、 Model)等，下面会介绍相关的模型。计划的主要任务是选择开发方法并把其嵌入到过程模型中。第3章 开发方法选择 3.3 交交 付付 速速 度度在软件开发中客户更关心以较低的成本快速交付业务应用程序，应对的方法是快速应用开发(Rapid Application Development,RAD)，RAD强调快速产生供用户评价的软件原型。RAD方法不但使用一些传统开发的基本要素(如逻辑数据结构图)，而且采用联合应用开发(Joint Application Development,JAD)研讨会策略。在研讨会中开发人员和用户一起工作，例如35天，标识和认可完全文档化的业务需求，研讨会通常在远离常规的

19、业务和开发环境的净室(不受外部干扰的会议室，配备有合适的白板和其他辅助沟通的设备)中进行，这些条件的好处是可加速沟通和磋商，不像传统方法那样要花几周或几个月的时间。第3章 开发方法选择 在组织JAD会议之前，需要对项目范围定义，以及对包含访谈关键人员、创建初始数据和过程模型在内的初步工作进行计划和执行，JAD会议的结果可以使用非常传统的方法来实现。另一种加速交付的方法是减少交付内容，可以将大的项目分解成小的增量来实现，每个增量都快速交付一部分可用的功能。在软件项目中存在两种竞争压力。一是尽可能快速并廉价地完成工作，二是确保最终产品的结构是健壮的并能满足变化的需要。具体如何开发软件项目，不同的过

20、程模型在交付速度和软件质量方面的表现也各不相同。第3章 开发方法选择 3.4 边做边改模型边做边改模型边做边改模型(Build-and-Fix Model)比较常见，曾被说成是地狱式编程(Code-like-Hell Programming)，也称为编码修正(Code-and-Fix)模型。如果没有项目计划，也没有选择其他生命周期模型，配上一个简略的进度表，也许就不自觉地进行编码，然后修改。第3章 开发方法选择 当使用边做边改模型的时候，一般从一个大致的想法开始工作(可能有一个正式的规范，也可能没有)随着客户的需要一次又一次地不断修改软件。在这个模型中开发人员拿到项目立即根据需求编写程序，调试

21、通过后生成软件的第一个版本。在提供给用户使用后如果程序出现错误，或用户提出新的要求，开发人员重新修改代码，直到用户满意为止。图3.2说明了这种过程。第3章 开发方法选择 图3.2 边做边改模型(边做边改模型是一种不规范的模型，比较带见的原因是因为它简单，但是不能起到很好的作用)第3章 开发方法选择 边做边改模型有两个好处：第一，不需要什么成本。不需要在除了纯粹编码工作以外的项目计划、文档编制、质量保证、标准实施或任何其他活动中花费时间，直接进入编码阶段，能立即展示进展情况；第二，只需要极少的专业知识。写过计算机程序的人都非常熟悉边做边改模型，任何人都能使用它。对于一些非常小的、开发完以后会很快

22、丢弃的软件，例如一些小的验证程序、寿命很短的示例或要丢弃的原型，边做边改模型有一定的优势。第3章 开发方法选择 对于稍微大一点的项目，采用边做边改模型是很危险的。虽然不需要什么成本，但是也不提供评估项目进展情况的手段。如果干了3/4的工作才发现设计时就走错了路，那就别无选择，只能全部重做。使用其他模型可以及早发现这种根本性的错误，减少修改工作的成本。所以除非是无足轻重的小程序，这种生命周期模型在快速开发项目中毫无用处。第3章 开发方法选择 3.5 瀑瀑 布布 模模 型型瀑布生命周期模型是所有生命周期模型的原型，是其他生命周期模型的基础。在瀑布模型中项目从始至终按照一定的步骤从初始的软件概念进展

23、到系统测试。项目在每个阶段结束时进行检查，以判断是否可以开始下一阶段的工作。例如从需求分析到构架设计。如果检查的结果是项目还没有准备好进入下一阶段，那么就停留在当前阶段，直到当前阶段的工作完成为止。瀑布模型是文档驱动的，主要工作成果是将一个阶段的文档传递到下一个阶段。在纯瀑布模型中，各阶段不连续也不重叠。图3.3说明纯瀑布模型是如何工作的。第3章 开发方法选择 图3.3 纯瀑布模型(瀑布模型是最著名的生命周期模型，在某些情况下提供了很快的开发速度)第3章 开发方法选择 纯瀑布模型能够降低计划管理费用，可以预先完成所有计划。设计之前瀑布模型不提供有形的软件成果，只有到软件集成时，才得到可执行的软

24、件。熟悉的人都明白：文档提供了贯穿生命周期进展过程的充分说明。当有明确的产品定义和很容易理解的技术解决方案时，纯瀑布模型特别合适。在这种情况下，瀑布模型可以及早发现问题，降低项目的阶段成本，提供开发者渴望的稳定需求。如果要对定义得很好的版本进行维护或将产品移植到一个新的平台上，瀑布生命周期模型是快速开发的恰当选择。第3章 开发方法选择 对容易理解但很复杂的项目，采用纯瀑布模型比较合适，这样就可以用顺序的方法处理复杂的问题。在质量需求高于成本需求和进度需求的时候，其表现尤为出色。这样的项目在进展过程中基本不会产生需求变更，因此纯瀑布模型就避免了一个常见的、巨大的潜在错误源。当开发队伍的技术力量比

25、较弱或缺乏经验的时候，瀑布模型很合适，它为项目提供了一种节省开支、减少浪费的方法。纯瀑布模型的缺点是在项目开始的时候、在设计工作完成前和在代码写出来之前很难充分地描述需求。第3章 开发方法选择 因此，瀑布模型最主要的问题是缺乏灵活性。必须在项目开始时定义全部需求，这恰恰是最难的，也许在开始软件开发工作前就已经花了几个月甚至几年。对于现代商业需求，奖励常常会颁发给在项目结束时实现最主要功能的开发者。正如微软的Roger Sherman指出项目开始时确定的最终目标常常无法达到，只能在有限的时间和资源下尽可能地提高可能性。第3章 开发方法选择 有人抱怨瀑布模型不允许返回去改正错误，这不完全对。如图3

26、.3所示，允许回去，但是很困难。这就是瀑布模型的另一种表现形式鲑鱼生命周期模型，如图3.4所示。允许逆流而上，结果可能是死路一条！在构架设计的最后阶段，需要做几件事，说明正在完成的工作，如进行设计检查、在正式的构架设计文档上签字等。如果在编码和调试阶段发现一个构架设计的缺陷，很难逆流而上地进行构架改变。第3章 开发方法选择 图3.4 瀑布模型的另外一种形式鲑鱼生命周期模型(返回不是不可能，只是很困难)第3章 开发方法选择 瀑布生命周期模型有明显的弱点。例如如果某些工具、方法和活动跨越了瀑布模型的几个阶段，就很难适应瀑布模型不连续阶段的特性。对需要快速开发的项目，瀑布模型会导致过多的文档。如果保

27、留灵活性，更新文档会成为一项专门的工作。在开发过程中使用瀑布模型能看到的东西很少，直到后期阶段才能看到，这会给人一种开发速度缓慢的印象，用户喜欢看到实在的东西以保证项目能准时完成。因此纯瀑布模型的缺点是其在面对要求快速开发的项目时捉襟见肘，即便在项目中的优势大于弱点，而有时候经过修改的瀑布模型则表现得更出色。第3章 开发方法选择 3.6 瀑布模型的变种瀑布模型的变种3.6.1 生鱼片模型生鱼片模型Peter DeGrace把瀑布模型的一种改进叫做“生鱼片(Sashimi)模型”，是一种允许阶段重叠的瀑布模型，名字来源于日本硬件开发模型(富土通施乐)。图3.5表示了生鱼片模型的基本原理。传统的瀑

28、布模型在阶段结束时，通过检查就进入下个阶段，否则继续该阶段，阶段间存在最低限度的重叠，生鱼片模型则建议大幅度的重叠。例如，在系统分析完成之前可以进行构架设计和部分详细设计。对很多项目来说，生鱼片模型是一种合理的方法，将注意力集中在开发过程中要干什么，但是，它不太适合严格的、连续的开发计划。第3章 开发方法选择 图3.5 生鱼片模型(将瀑布模型的各个阶段重叠以克服其中的某些弱点，但产生了新问题)第3章 开发方法选择 纯瀑布模型中，任意两个阶段交接时，完整的文档从一个团队交给另一个完全隔离的团队。问题是“为什么要这样做？”，如果实施软件需求、系统分析、构架设计、详细设计、编码和测试等阶段的是同一组

29、开发人员，实际上就不需要那么多文档，这样，就可以采用修正后的瀑布模型，以充分减少文档需求。生鱼片模型也有问题，由于阶段重叠，里程碑很不明确，难以进行精确地过程跟踪。并行执行的活动可能导致无效的沟通、错误的想法以及低下的效率。如果做一个小的、定义的很好的项目，该模型是非常有效的模型。第3章 开发方法选择 3.6.2 包含子项目的瀑布模型包含子项目的瀑布模型从快速开发的观点来看，纯瀑布模型的另一个问题是必须在全部完成构架设计后才能开始详细设计，而在详细设计全部完成后才能进行编码和测试。实际工作中系统的某些部分可能在设计上有独特的地方，而且有些部分以前可能做过很多次，没有什么特别的，为什么仅仅因为在

30、等待一个困难部分的设计而延迟容易执行部分的设计呢？如果构架把系统分成几个逻辑上相对独立的子系统，就允许拆分项目，每个子项目就可以按自己的步调走。图3.6说明了这种模型的基本结构。第3章 开发方法选择 图3.6 包含子项目的瀑布模型(仔细地计划以允许并行地执行瀑布模型的任务)第3章 开发方法选择 3.6.3 可以降低风险的瀑布模型可以降低风险的瀑布模型瀑布模型的另一个弱点是要求在开始构架设计之前，完整地定义需求。虽然看起来很有道理，但在实际工作中是比较困难的。因此稍微改变一下瀑布模型，即在瀑布模型的顶端引入降低风险的螺旋(Spiral)以便处理需求风险。也可以先开发一个用户界面原型，或采用系统故

31、事板(System Story Board)，引导用户提出需求，记录用户与原系统的交互操作情况，或采用其他获取用户需求的方式。图3.7表明了能够降低风险的瀑布模型。软件需求、系统分析和构架设计用阴影表示，以指出它们是在降低风险阶段而不是在瀑布阶段。第3章 开发方法选择 图3.7 可以降低风险的瀑布模型(为了克服瀑布模型的风险问题，可以在使用瀑布模型的时候，对需求、分析和构架设计阶段采用降低风险的螺旋模型)第3章 开发方法选择 降低风险模型并不局限在需求和分析阶段，也可以用它降低构架风险或项目的其他任何风险。如果项目要开发一个高风险的系统内核，在交付项目前，就可以通过一个风险降低周期来进行开发。

32、第3章 开发方法选择 3.7 螺螺 旋旋 模模 型型螺旋模型是B.W.Boehm于1988年提出，是一种以风险为导向的生命周期模型，它把一个软件项目分解成一个个小项目，标识出每个小项目的一个或多个主要风险因素，直到确定所有的主要风险为止。“风险”可能是没有理解清楚需求或构架、潜在的性能问题、根本性的技术问题等。在确定所有的主要风险因素后，螺旋模型就像瀑布模型一样终止。第3章 开发方法选择 图3.8说明了螺旋模型，是个复杂的图形，值得研究。螺旋模型的基本思路是从一个小范围的关键中心地带开始寻找风险因素，制定风险控制计划，并交付给下一步骤，如此迭代，每次选代都把项目扩展到一个更大的规模。等到完成一

33、个螺旋，检查并确认之后，再开始进入下一螺旋。第3章 开发方法选择 图3.8 螺旋模型(在螺旋模型中，项目范围逐渐递增展开。项目范围展开的前提是风险降低到下一步扩展部分的可接受的水平)第3章 开发方法选择 每次迭代都包括下面六个步骤：(1)确定目标、备选方案和约束条件；(2)识别并解决风险；(3)评估备选方案；(4)开发本次迭代要交付的内容，并检查其正确性；(5)规划下一次迭代过程；(6)交付给下一步骤，开始新的迭代过程(如果想继续的话)。在螺旋模型中越早期的迭代过程成本越低，这样当发现项目不可行时所消耗的成本最低。因此，计划概念比需求分析的代价低，需求分析比开发设计、集成和测试的代价低。第3章

34、 开发方法选择 螺旋有精确的四个环并不重要，同样严格地执行上述六个步骤也不重要，虽然那是很好的工作顺序，也应该根据项目的实际需求调整螺旋的每次迭代过程。螺旋模型最重要的优势是随着成本的增加，风险程度随之降低。时间和资金花得越多，风险越小，这正是快速开发项目所需要的。螺旋模型提供至少和传统的瀑布模型一样多的管理控制。在每次迭代过程结束时都设置了检查点，因为模型是风险导向的，可以预知任何无法逾越的风险。如果项目因为技术和其他原因无法完成，就可以及早发现，而且不会增加太多的成本。第3章 开发方法选择 螺旋模型有一定的限制条件，具体如下：(1)螺旋模型强调风险分析，但要求许多客户接受和相信这种分析并做

35、出相关反应是不容易的，因此这种模型往往适应于内部的大规模软件开发；(2)如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此螺旋模型只适合于大规模软件项目；(3)软件开发人员应该擅长寻找可能的风险，并准确地分析风险，否则将会带来更大的风险。第3章 开发方法选择 因此螺旋模型的缺陷是比较复杂，需要有责任心、专注和管理方面的知识。通过确定目标和可验证的里程碑来决定是否准备在“螺旋”上再加一层是比较困难的。在有些项目中如果产品开发的目标明确、风险适中，就没有必要采用螺旋模型来进行风险管理。第3章 开发方法选择 3.8 原原 型型 开开 发发原型是已规划系统的一个或多个方面的工作模型。

36、建立原型的主要原因是为了解决在产品开发的早期阶段的不确定性，利用这些不确定性来判断系统中哪一部分需要建立原型和希望从用户对原型的评价中获得什么。原型可以使他们的想象更具体化，有助于说明和纠正这些不确定性，总的来说通过原型法可以很好的减少项目风险。用快速而又经济的方法来构建和测试原型，以检验各种设想。图3.9给出了软件开发中使用原型的一些方法。第3章 开发方法选择 图3.9 软件开发中使用原型的可能方法(建立原型可以解决在产品开发的早期阶段不确定的问题，原型有 助于说明和纠正这些不确定性，可以用快速而又经济的方法来构建和测试原型，以检验各种设想)第3章 开发方法选择 原型可以分为水平和垂直的原型

37、：水平原型。也叫做“行为原型”(Behavioral Prototype)。用来探索预期系统的一些特定行为，并达到细化需求的目的。当用户在考虑原型中所提出的功能能否使他们完成各自的业务时，原型使用户所探讨的问题更加具体化。它更多从业务需求着手，应用在需求阶段。垂直原型(Vertical Prototype)。也叫做结构化原型或概念的证明，实现了一部分应用功能。当预期实现阶段可能存在技术风险时可以开发一个垂直原型。垂直原型通常用在生产运行环境中的生产工具构造，使其结果一目了然(更有意义)。比起在软件的需求开发阶段，垂直原型更常用于软件的设计阶段以减少风险。第3章 开发方法选择 原型又可以分为抛弃

38、型或进化型：抛弃型原型。只用来检验某些想法，而后在真正开始开发可运行的系统时将其抛弃。由于在开发阶段最终将抛弃这些原型，所以不需要花太大力气去建立原型。原型可使用不同的软件环境来开发(如桌面应用程序构造工具，而不用像开发最终系统那样使用过程编程语言，机器效率对最终系统来说是重要的)，甚至可以在不同的硬件平台上开发。第3章 开发方法选择 进化型原型。开发并修改原型，直到它最终成为可运行的系统。这种情况下必须仔细考虑用于开发软件的标准。进化型原型是在已经清楚地定义了需求的情况下，作为产品的部分实现，为开发渐进式产品提供了坚实的开发基础。与抛弃型原型的快速、粗略的特点相比，进化型原型一开始就必须具有

39、健壮性和产品质量级的代码。一个进化型原型必须设计为易于升级和优化的，要达到进化型原型的质量要求并没有捷径。进化型原型一般在处理构架时会采用。第3章 开发方法选择 原型技术对软件项目的促进作用很明显。使用原型可以带来下面的好处：改进沟通。尽管用户确实阅读了系统规格说明，但他们可能并不知道系统实际上是如何工作的。改进用户参与。用户可以更主动地参与新系统的设计决策。澄清部分已知的需求。在没有现成的系统可模仿的情况下用户可以通过试验原型更好地理解什么对他们是有用的。验证规格说明的一致性和完整性。试图在计算机上实现规格说明的任何办法都可能发生歧义和遗漏。例如简易的电子表格可以检查计算是否已得到了正确的结

40、果，这是一种检验规格说明的方法。第3章 开发方法选择 减少文档的需要。由于可以检查工作原型，因此减少了对详细需求文档的需要。降低维护成本。如果没有原型阶段，用户不能有效地提出修改建议，那么就很可能在将来提出对可运行系统的变更。特征约束。如果使用应用程序构造工具，原型就具有该工具很容易实现的特征，而基于书面的设计可能带来实现费用昂贵的特征。产生期望的结果。与测试用例有关的问题一般不是创建测试输入，而是得到准确的期望结果，原型有助于做到这一点。第3章 开发方法选择 但是，软件原型开发并不是没有缺点和危险，主要体现在以下方面：用户可能曲解原型的作用。例如他们可能期望原型与可运行的系统一样有严格的输入

41、确认或很快的响应速度，即使这不是预期的。可能缺乏项目标准。进化型原型可能只是草率的“编写完并看看发生什么”的方法。可能缺乏控制。如果驱动力是用户爱好试验新事物，那么要控制原型开发的周期是很困难的。第3章 开发方法选择 额外的费用。构建和使用原型要花额外的费用，但是不应该过高估计，因为无论用什么方法都要承担许多分析和设计任务。机器效率。尽管通过原型开发构建的系统易于满足用户的需要，但是从机器效率的角度来讲它可能不如用常规的方法开发的系统。与开发人员密切接近。原型开发意味着开发人员在场地上要邻近用户。一种趋势是发达国家的组织以较低的成本将软件开发转移到发展中国家，如印度、中国等，原型开发可能阻碍这

42、种趋势。第3章 开发方法选择 3.9 分类原型的其它方面分类原型的其它方面3.9.1 要从原型中学到什么要从原型中学到什么原型开发最重要的目的是需要了解不确定的领域。因此重要的是要在开始时确定要从原型中学到什么。计算机领域的学生经常认为他们要编写的作为毕业设计项目的一部分软件不可能被实际的用户安全地使用，因而他们称这样的软件为“原型”。但是如果是实际的原型，他们应该：详细说明希望从原型中学到什么；计划如何评价原型；报告实际从原型中学到了什么。第3章 开发方法选择 在试验项目中使用原型，可以用于发现新的开发技术。开发方法可能是众所周知的，但应用程序的不确定性是本质的。不同的项目在不同的阶段有不确

43、定性。因此原型可在不同的阶段使用。例如原型可以用在需求收集阶段来弄清楚似是而非和变幻莫测的需求；另外，原型可能用在设计阶段来检验用户浏览一系列输入屏幕的能力。第3章 开发方法选择 3.9.2 原型要做到什么程度原型要做到什么程度对整个应用程序进行原型化是很少见的。原型开发通常只是模仿目标应用程序的某些方面。例如：实验模型。也许模仿的输入屏幕要在工作站上显示给用户看，而且这样的屏幕实际上是不能使用的，例如嵌入式开发中的界面设计。模仿交互。例如用户输入请求来访问记录，而系统显示记录的细节，但显示的记录总是一样的，而且不是对数据库进行访问。部分工作模型：纵向的。有一些但不是所有的特征彻底进行原型化。

44、横向的。所有的特征都要原型化，但不详细进行(也许输入没有完全验证)。第3章 开发方法选择 3.9.3 哪些要进行原型化哪些要进行原型化人机界面。对商业应用程序来讲，需求一般要在早期阶段处理，因此原型往往局限于为操作员提供交互操作上。这时原型的表现方式应该尽可能与可运行的系统保持一致。系统的功能性。这里并不知道系统内部运行的准确方式，例如正在开发的某些现实世界的计算机模型。除非模仿现实世界的行为令人满意，否则使用的算法可能需要反复调整，以达到预期的效果。第3章 开发方法选择 3.9.4 在原型开发期间控制变更在原型开发期间控制变更 原型开发的主要问题是遵循用户提出的建议来控制对原型的变更。下面的

45、方法把变更归为三种类型之一：表面的(约占变更的35%)。主要是对屏幕布局的简单变更。它们是：(1)已实现的；(2)已记录的。第3章 开发方法选择 局部的(约占变更的60%)。主要包括屏幕处理方法的变更，但不影响系统的其他部分。它们是：(1)已实现的；(2)已记录的；(3)已备份的，必要时在后期阶段可以删除；(4)已追溯审查的。全局的(约占变更的5%)。这些变更会影响多个部分的处理。毫无疑问这里的变更在实现之前是设计评审的主题，是关注的焦点。第3章 开发方法选择 3.10 渐渐 进进 原原 型型渐进原型是从基本需求开始项目开发的一种生命周期模型，通常从最明显的方面开始向用户展示完成的部分，然后根

46、据用户的反馈信息继续开发原型，并重复这一过程，直到用户认为原型已经“足够好”为止，然后结束开发工作，并交付作为最终产品的原型。图3.10描述了该过程。在需求变化很快，用户很难提出明确的需求，在开发人员和用户都不知道怎么才好的时候，当开发人员对最佳的构架或算法没有把握的时候，渐进原型特别有用。第3章 开发方法选择 渐进原型主要的缺点是：开发人员不可能在开始的时候知道开发一个令人满意的产品要花多长时间，甚至不知道究竟要反复多少次。不过由于用户能看见项目进展情况，对什么时候能最终得到产品不至于紧张，所以实际上缺点有所减轻。另外采用渐进原型有可能陷入“保持原型，直到延时、超支，并声称会做完”的困境中。

47、渐进原型的另一个缺点是该方法很容易成为采用边做边改模型的借口。真正的渐进原型，包括真正的需求分析、设计和可维护的代码，与采用传统的方法相比，可能会觉得每次重复时实际的进展较小。第3章 开发方法选择 图3.10 渐进原型模型(采用渐进原型，应从设计和实现原型程序中最明显的部分开始，然后增添、精炼原型，直到完成所有的工作，原型演化为最终可交付的软件)第3章 开发方法选择 3.11 增增 量量 交交 付付增量交付将应用程序分解为小的构件，然后按顺序实现和交付构件。每个要交付的构件应该给用户带来一些效益。图3.11描述了该方法的基本思想。时间盒(Time Boxing)通常用于增量式方法。增量交付随着

48、交付时间的限制不同，它的表现形式不同，例如阶段交付、面向进度的设计等。第3章 开发方法选择 图3.11 有目的的增量交付(增量交付将应用程序分解为小的构件，然后按顺序实现和交付构件)第3章 开发方法选择 3.11.1 优点优点下面是该方法的一些优点：早期增量得到的反馈可用来改进后面的阶段。由于构件设计与其实现之间的时间跨度较短，因此减少了需求变更的可能性。与常规的方法相比，用户在早期就能得到效益。一些有用构件的早期交付改进了现金流，因为早期就能得到一些投资回报。划分为较小型的子项目，更易于控制和管理。第3章 开发方法选择“镀金”(即对不需要的和事实上不使用的特征的要求)是不太重要的，因为用户知

49、道由此得到的效益是微不足道的。如果一个特征不在当前增量中，那么可以包含在下一个增量中。如果突然出现更多紧急的工作，那么项目可以临时放弃。增强了开发人员的工作成就感，能短时间地、定期地看到自己的劳动果实。第3章 开发方法选择 3.11.2 缺点缺点另一方面，该方法有以下缺点：软件变更量，也就是说后面的增量可能要求修改早期的增量。程序员在大型系统上工作，可能要比在一系列小型项目上工作有更高的效率。Grady Booch认为：“对于“需求驱动”的项目(等价于增量交付)来讲，有时会破坏概念上的完整性，因为除了可能隐含含糊的需求之外，几乎没有什么动机来处理可伸缩性、可扩充性、可移植性或可重用性。”Boo

50、ch还认为：“大量分散的功能可能会导致没有公共的基础设施。”第3章 开发方法选择 3.11.3 增量交付计划增量交付计划每个要交付给用户的增量特征和顺序必须在开始时就策划好。这个过程类似于战略规划，但要更详细一些。要注意用户应用程序的增量，而不是整个应用程序。增量计划的基本组成是系统目的、开放的技术计划和增量。第3章 开发方法选择 3.11.4 系统目标系统目标项目计划人员要有明确的目标，但如何满足这些目标则应该尽可能自由。然后将总体目标扩展为更明确的功能目标和质量目标。目标包括：想要实现的目标；系统要做的工作；实现这些目标的计算机和非计算机功能。第3章 开发方法选择 另外可度量的质量特性应该