02 软件生命周期与开发模型(1)

nullnull软件生命周期模型概论 瀑布模型（waterfall model） 增量模型（incremental model） 原型模型（prototyping model) 迭代模型（iterative model) 螺旋模型（spiral model） 喷泉模型（fountaiin model） XP模型（eXtreme Progamming model）学习目标学习目标掌握软件生命周期的阶段 掌握常用的软件生命周期模型的本意、特点、选用条件一、软件生命周期模型概论 一、软件生命周期模型概论 生命周期 软件生命周期 软件生命周期模型 １生命周期１生命周期任何生命或事物从出现到消失的全过程。 任何有生命的动物、植物和人，都有一个生命周期（Life Cycle）。例如，人的生命周期如表2-2 所示。 即使是没有生命的事物或实体，例如，PC机、路由器、家具、房子、汽车，它们也有一个生命周期，这个生命周期就是使用寿命，即使用周期。２软件生命周期２软件生命周期软件开发过程有时称为软件生命周期（software life cycle），因为它描述了一件软件产品的生命：从它的概念到实现、交付、使用、维护、退役。 软件生命周期分为如下几个阶段：立项与 合同 劳动合同范本免费下载装修合同范本免费下载租赁合同免费下载房屋买卖合同下载劳务合同范本下载 、需求分析、软件设计（概要设计＋详细设计）、编码实现、软件测试、软件发布与实施、软件维护、版本更新或退役 ３软件生命周期模型３软件生命周期模型软件生命周期模型是指在整个软件生命周期中，软件开发活动应遵循的开发路线图。或：软件生命周期模型是软件开发全部过程、活动和任务的结构框架。 描述软件开发的过程及其活动和任务。 常见的软件生命周期模型： 瀑布模型 原型模型 迭代模型 增量模型null不同的软件生命周期模型，可能对应着不同的生命周期。为什么？ 因为生命周期不同，该软件的开发阶段划分、评审次数、基线 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 、产品发布、维护方式都有所不同。 二、瀑布模型二、瀑布模型null 1970年W.Royce提出瀑布模型 1.模型的本意：阶段间具有顺序性和依赖性 2.模型的特点： 文档驱动 过程不可逆转 3.模型的选择条件： （1）在开发时间内需求没有或很少变化。 （2）分析设计人员对应用领域很熟悉。 （3）低风险项目（对目标、环境很熟悉）。 （4）用户使用环境很稳定。 （5）用户除提出需求以外，很少参与开发工作。null4.模型的优点 :开发阶段清晰，便于评审、审计、跟踪、管理和控制。 5.模型的缺点 传统的项目组织方法是按顺序完成每个工作流程，即瀑布式生命周期。瀑布只能一个个台阶地往下流，不可能倒着往上流，这就是它致命的缺点。 瀑布式生命周期通常会导致在项目后期，出现“问题堆积”，更可怕的是，错误的传递会采取发散扩大的方式。 null6.改进措施 为了克服该模型的缺陷，微软采取严格的里程碑 管理制度 档案管理制度下载食品安全管理制度下载三类维修管理制度下载财务管理制度免费下载安全设施管理制度下载 。 CMM/CMMI则采取阶段评审和不符合项(Noncompliance Items)的动态跟踪制度，只有前一阶段的不符合项全部改正后，才允许开发人员进入后一阶段的工作。 所谓不符合项，就是在评审中发现的问题项，它与Bug既有联系，又有区别。对于这些不符合项，软件管理部门要列出表格，记录在案，确定责任人，限定改正时间，动态跟踪到底。 三、增量模型三、增量模型null1．模型的本意 要开发一个大的软件系统，先开发其中的一个核心模块（或子系统），然后再开发其他模块（或子系统），这样一个个模块（或子系统）地增加上去，就像搭积木一样，直至整个系统开发完毕为止。 在每增加一个模块前，先要对该模块进行模块测试。通过后再将此模块加入到系统中，然后还要进行系统集成测试。系统集成测试成功后，再增加新的模块。 这样多次循环，直到系统搭建完毕为止。 null2．模型的特点 （1）任务或功能模块驱动，可以分阶段提交产品。 （2）有多个任务单，这些多个任务单的集合，构成项目的一个总《任务书》，或总《用户需求报告》/《需求规格说明书》。 null3．选择模型的条件 （1）在整个项目开发过程中，需求都可能发生变化，客户接受分阶段交付。 （2）分析设计人员对应用领域不熟悉，难以一步到位。 （3）中等或高风险项目（工期过紧且可分阶段提交的系统或目标、环境不熟悉）。 （4）用户可参与到整个软件开发过程中。 （5）使用面向对象语言或第四代语言。 （6）软件公司自己有较好的类库、构件库。null4．模型的优点 （1）由于将一个大系统分解为多个小系统，这就等于将一个大风险分解为多个小风险，从而降低了开发难度。 （2）人员分配灵活，刚开始不用投入大量人力资源。如果核心模块产品很受欢迎，则可增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。即可先发布部分模块给客户，对客户起到镇静剂的作用。 null5．模型的缺点 如果软件系统的组装和拆卸性不强，或开发人员全局把握水平不高（没有数据库设计专家进行系统集成），或者客户不同意分阶段提交产品，或者开发人员过剩，就不宜采用这种模型。 四、原型模型四、原型模型原型的解释: 预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。 一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建。原型模型 原型模型 许多软件公司在生产软件产品与实施软件项目时，经常采用一种“原型法”，它来源于原型模型，下面就介绍这种模型。 1．模型的本意 原型模型（Prototype Model）的本意是：在初步需求分析之后，马上向客户展示一个软件产品原型(样品)，对客户进行培训，让客户试用，在试用中收集客户 意见 文理分科指导河道管理范围浙江建筑工程概算定额教材专家评审意见党员教师互相批评意见 ，根据客户意见立刻修改原型，之后再让客户试用，反复循环几次，直到客户确认为止。 null原型模型很适合于企业资源规划ERP（Enterprise Resource Planning）系统，尽管市场上推出了许多公司的分行业ERP“产品”，但是这些“产品”的产品化程度相当低，都必须在实施中做大量的客户化工作。 有些公司的分行业ERP“产品”称作“分行业解决方案”，这个“分行业解决方案”就是分行业的原型，即快速原型法中的原型。 null2．模型的特点 原型驱动。因此，开发者必须先有一个原型(样品)，至少要有一个原型的核心。 原型模型与迭代模型相同点是：反复循环几次，直到客户确认为止。不同点是：原型模型事先有一个展示性的产品原型(样品)，而迭代模型可能没有。 null3．选择模型的条件 （1）已有产品或产品的原型(样品)，只需客户化的工程项目。 （2）简单而熟悉的行业或领域。 （3）有快速原型开发工具。 （4）进行产品移植或升级。 由于上述条件不太苛刻，所以凡是有软件产品的IT企业，在他们熟悉的业务领域内，当客户招标时，他们都会以原型模型作为软件开发模型，去制作投标书，去讲解标投标。 null4．模型的优点 开发速度快，用户意见反馈实时，有利于开发商在短时间内推广并实施多个客户。 正因为原型模型具有这些优点，所以它一直是软件企业界的主流开发模型。凡是有软件产品积累的软件公司，他们在投标、开发、实施项目的过程中，都非常喜欢用原型模型。 5．模型的缺点 因为事先有一个展示性的产品原型，所以在一定程度上，不利于开发人员的创新。 null6．快速原型法 由于原型模型的开发速度较快，有时也将它称作快速原型法（Rapid Prototyping）。 在开发工具和开发环境迅速发展的今天，在信息系统开发中，原型法和快速原型法又被赋予新的内容：事先没有原型产品，也可以采取这种办法。 基本思路是：采用以面向元数据为主的方法，在需求分析的基础上，利用Power Designer等数据库分析和设计工具，快速建立信息系统的概念数据模型CDM和物理数据模型PDM；然后利用面向对象的编程工具，快速地实现需求分析中确认的流程、功能、性能和接口；之后交付给用户试用，反复循环几次，直到客户确认满意为止。 null【例2-1】 1996年8月，当时的某高级工程师，带领一个熟练的程序员，来到营口港务局通信中心，开发该中心的电话业务信息管理系统。 当时，虽然这两个人手中并无什么“原型”，但是他俩一个是数据库设计高手，一个是编程高手，所以俩人分工负责，一人设计数据库，一人编写程序，双方配合默契，只用一个多月时间，就圆满地完成了开发任务，收回了全部开发费用，获得了客户的好评。 这是一个典型的“快速原型法”例子。 null快速原型法选择的条件之一是：项目组中有数据库分析和设计的专家，有面向对象编程的专家，文档制作有成熟的模板，而且系统或项目又不是非常大。 快速原型法选择的条件之二是：项目组的开发环境为分行业的业务基础平台(比如Justep X3业务基础平台)，该业务基础平台又完全适合所需开发的系统或项目，而且系统或项目又不是非常大。 以上两个条件，只要符合一个，就可以采用快速原型法。 null原型的类型： 探索型：弄清要求，确定特性，并探讨多种方案的可行性 实验型：大规模开发和实现前，验证方案或算法的合理性。 演化型：原型作为目标系统的一部分。 原型的使用策略： 废弃（throw away）策略：用于探索型和实验型原型。 追加（add on）策略：用于演化型原型。 原型可作为单独的过程模型，也常被作为一种方法或实现技术应用于其它过程模型中。 五、 迭代模型 （Iterative Model）五、 迭代模型 （Iterative Model）代表：RUP（Rational Unified Process）模型 null所谓迭代，是指活动的多次重复。从这个意义上讲，原型不断完善和增量不断产生，都是迭代的过程。但这里所讲的迭代模型是RUP推出的一种“逐步求精”的面向对象的软件开发过程模型，被认为软件界迄今为止最完善的、商品化的开发过程模型。null1．模型的本意 多次执行各个开发工作流程，从而更好地理解需求，设计出更为强壮的软件构架，逐步提高开发组织能力，最终交付一系列逐步完善的实施成果，这就是迭代式生命周期模型。 每次按顺序完成这一系列工作流程就叫做一次迭代，每次迭代，均以次要里程碑结束，按照特定的迭代成功标准，对迭代的结果进行评估。每个阶段都可以进一步细分为迭代。 迭代是产生可执行的产品发布的完整开发循环，所发布的产品是开发过程最终产品的子集，它将通过一次又一次的迭代，实现递增成长，最后形成最终的软件系统或产品。 null2．模型的特点 迭代或迭代循环驱动，每一次迭代或迭代循环，均要走完初始（先启）、精化、构建、产品化(移交)这四个阶段。RUP的主要特征如下： 1.采用迭代的、增量式的开发过程； 2.采用UML语言描述软件开发过程； 3.有功能强大的软件工具Rational Rose支撑。 null3．模型的选取条件 （1）项目组的管理人员和核心成员，应对迭代的开发方式比较熟悉。 （2）管理人员和核心成员应对软件工程的核心过程：系统建模、需求分析、系统设计、系统实现、项目管理、配置管理、测试等比较熟悉。 （3） 采用面向对象技术（如OOA，OOD等）的项目组，建议使用迭代式生命周期。 （4）项目组的核心设计人员，应具备一定程度的软件架构的知识，并熟练掌握软件架构设计技能。 （5）项目组全体成员应熟悉UML，并能利用建模工具（如Rational Rose等）进行分析、策划、设计、测试等。 （6）项目组的管理人员应具备风险管理的知识和技能。 （7）拥有实施软件产品开发、组装的软件组织。null4．模型的四个阶段 （1）初始阶段。本阶段主要工作是确定系统的业务用况和定义项目的范围。 （2）精化阶段。本阶段主要工作是分析问题域、细化产品定义，定义系统的构架并建立基线，为构建阶段的设计和实施工作提供一个稳定的基础。 （3）构建阶段。本阶段主要工作是反复地开发，以完善产品，达到用户的要求。 （4）产品化(移交)阶段。本阶段主要工作是将产品交付给用户，包括安装、培训、交付、维护等工作。 null5．模型的九个核心流程 （1）业务建模。 （2）需求获取。 （3）分析设计。 （4）实施。 （5）测试。 （6）部署。 （7）配置与变更管理。 （8）项目管理。 （9）环境。 null6．模型的优点 在开发早期或中期，用户需求可以变化；在迭代之初，它不要求有一个相近的产品原型；模型的适用范围很广，几乎适用于所有的项目开发。 7．模型的缺点 传统的项目组织方法是按顺序（一次且仅一次）完成每个工作流程，即瀑布式生命周期。迭代模型是采取循环的工作方式，每次循环均使工作产品更靠近目标产品一次，这就要求项目组成员具有很高的水平并掌握先进的开发工具。 六、 螺旋模型 六、 螺旋模型 1．模型的本意 螺旋模型将瀑布模型和快速原型模型结合起来，强调了其它模型所忽视的风险分析，特别适合于大型复杂的系统。 螺旋模型基本做法是在瀑布模型的每一个开发阶段前，引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。如图2-4所示。 nullnull螺旋模型沿着螺线顺时针方向进行若干次迭代，图中的四个象限代表了以下迭代活动： （1）制定 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 ：确定软件目标，选定实施方案，弄清项目开发的限制条件； （2）风险分析：分析评估所选方案，考虑如何识别和消除风险； （3）实施工程：实施软件开发和验证； （4）客户评估：评价开发工作，提出修正建议，制定下一步计划。 null2．模型的特点 （1）把软件开发过程组成为一个逐步细化的螺旋周期，每经历一个周期，系统就得到进一步的细化和完善； （2）整个模型紧密围绕开发中的风险分析，推动软件设计向深层扩展和求精； （3）强调持续的判断、确定和修改用户的任务目标，并按成本、效益来分析候选的软件产品对任务目标的贡献。 null3．选择模型的条件 螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。null4．模型的优点 （1）与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，从而降低了软件开发风险。 （2）螺旋模型对可选方案和约束条件的强调，有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。 （3）减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险。 （4）螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。null5．模型的缺点 （1）很难让用户确信这种演化方法的结果是可以控制的。由于建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。 （2）采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。 （3）过多的迭代次数会增加开发成本，延迟提交时间。 七、 喷泉模型 七、 喷泉模型 null1．模型的本意 喷泉模型(Fountain Model)认为，软件开发过程自下而上的各阶段是相互重叠和多次反复进行的，就像喷泉中的水喷上去，又可以落下来，所以叫做喷泉模型。 各个开发阶段没有特定的次序要求，而且可以交互进行，在每个开发阶段中，还可以随时补充其它任何开发阶段中的遗漏。采用喷泉模型的软件过程，如图2-5所示。 null2．模型的特点 喷泉模型是一种以用户需求驱动的模型，主要用于描述面向对象的软件开发过程。 由于各阶段的活动之间无明显界线，所以喷泉模型也称为“喷泉无间隙性模型”。 3．选择模型的条件 喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。 null4．模型的优点 喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。 该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间。 5．模型的缺点 由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。 这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息。 八、 XP模型 八、 XP模型 1．模型的本意 XP模型，即极限编程模型，它本来是敏捷企业文化现象，但是不少人将它当作一种软件开发模型。 XP模型属于轻量级开发模型，它由一组简单规则(需求、实现、重构、测试、发布)组成，既保持开发人员的自由创造性，又保持对需求变动的适应性，即使在开发的后期，也不怕用户需求的变更。XP模型的迭代开发过程，如图2-6所示。 nullnull2．模型的特点 在需求、实现、重构、测试、发布的迭代过程中，XP模型有四条核心原则：“交流” 、“简单” 、“反馈” 和“进取” 。 XP开发小组不仅包括开发人员，还包括管理人员和客户。 XP模型强调小组内成员之间要经常进行“交流”，结对编程，在尽量保证质量的前提下力求过程和代码的“简单”化。 来自客户、开发人员和最终用户的具体“反馈”意见，可以提供更多的机会来调整设计，保证把握正确的开发方向。 在XP模型中，采取讲“用户场景故事”的方法，来代替传统模型中的需求分析。 null3．选择模型的条件 XP模型克服了传统模型不灵活机动的缺陷，是一种面向客户场景的轻量级模型。它只适合于中小型开发小组。实践表明，XP模型特别适合于情投意合的青年人群的小项目。 4．模型的优点 (1).由于采用简单策略，不需要长期计划和复杂管理，因而开发周期短； (2).由于采用迭代增量开发、反馈修正和反复测试的方法，因而软件质量有保证； (3).由于适应用户需求的变化，因而与用户关系和蔼。 null5．模型的缺点 XP模型作为一种新的模型，在实际应用中还存在着一些问题，引起了许多争议。 它只适用于小型项目、小型项目组，不大适用于大型项目、大型项目组。 同时，它与ISO9001、CMMI的精神也存在冲突。 八、 各种模型之间的关系 八、 各种模型之间的关系 1．瀑布模型与迭代模型之间的关系 在宏观上，迭代模型是动态模型，瀑布模型是静态模型。迭代模型的每一次迭代，实质上都是执行一次瀑布模型，都要经历初始、精化、构造、移交四个阶段，走完瀑布模型的全过程。 在微观上，迭代模型与瀑布模型都是动态模型。迭代模型与瀑布模型在每一个开发阶段(初始、精化、构造、移交)的内部，都有一个小小的迭代过程，只有经历这个小小的迭代过程，该阶段的开发工作才能做细做好。 可见：迭代中有瀑布，瀑布中有迭代。即你中有我、我中有你。null2．瀑布模型与增量模型之间的关系 增量模型首先开发核心模块，之后再开发其他模块，这样一个一个地开发下去，直至所有模块开发完毕为止。 在开发每一个模块时，开发者一般都是采用瀑布模型，从需求、设计、编程、测试一个阶段接着一个阶段地实现。所以增量模型中有瀑布模型思想，即宏观上是增量模型，微观上是瀑布模型。 增量模型也体现了迭代思想，每增加一个模块，就进行一次迭代，执行一次瀑布模型，所以，增量模型本质上是迭代的。 null3．瀑布模型与原型模型之间的关系 原型模型开始有一个原型，在此基础上以后的每一次迭代，都可能是一次瀑布模型的开发方式。 原型模型中不但包涵了迭代模型的思想，而且包涵了瀑布模型的思想。 null4．瀑布模型与螺旋模型之间的关系 螺旋模型是瀑布模型和快速原型模型的结合，快速原型模型是原型模型的简化，原型模型又是迭代模型和瀑布模型的组合，这些模型之间是相互依存的、彼此有关的。 螺旋模型每一次顺时针方向旋转，相当于顺时针方向迭代一次，都是走完一次瀑布模型，这就是它们之间的关系。null5．XP模型与迭代模型之间的关系 XP模型是一个自由式迭代模型，它比传统的迭代模型简单、自由，甚至毫无约束。船小好调头，这就是XP模型。 6．生命周期模型之间的关系总结 软件工程虽然来源于机器制造工程、建筑工程、计算机硬件工程，但是又与这些工程不完全相同。 在软件开发的过程中，软件工程不可能百分之百地按照事先设计好的软件蓝图进行，而是一边施工、一边修改软件蓝图、一边再按照修改的软件蓝图继续施工，即按照“软件蓝图--软件开发--软件蓝图--软件开发”这个顺序多次循环，循环中又包涵着各种生命周期及开发模型，最后才能到达胜利的彼岸。本章小结 本章小结 本章介绍了软件生命周期模型：瀑布模型、增量模型、迭代模型、原型模型、螺旋模型和喷泉模型。 最常用的是瀑布模型和原型模型，其次是增量模型，最难掌握的是迭代模型。 七个模型的比较如表2-4所示。 nullnull软件企业选取软件生命周期模型的方法： 软件企业在创业时期，由于没有项目或产品的积累，所以他们常常会选取瀑布模型和增量模型。 一旦越过创业时期，由于积累了一些了项目或产品，他们就会选取原型模型。 至于迭代模型，只有当他们掌握了UML及其工具Rational Rose之后，才会加以考虑。 null关于软件组织定制“软件生命周期模型裁剪指南” 在一个成熟的IT企业或软件组织内部，根据上述通用的六个模型的普遍原则，结合本单位的开发经验和行业特点的具体实际，还需要定制适合本单位的“软件生命周期模型裁剪指南”，有针对性地对选定模型中定义的生命周期，进行恰当的裁剪，使它完全适合于本单位的需求。 所谓裁剪，就是对原模型中定义的内容进行增加、修改、删除，去掉对本单位不适用的部分，增加对本单位适用的内容，同时进一步细化，从而构成了完全适合本单位的“软件生命周期模型裁剪指南”。