软件过程管理4PPT课件

1、1RoadMapRoadMap合同管理 生存期需求管理 任务分解项目进度规模估算质量计划 配置计划风险计划团队管理项目度量集成项目跟踪控制 项目结束第1页/共88页2软件开发项目管理软件开发项目管理第三章软件项目生存期模型第2页/共88页3本章要点本章要点q 一、生存期模型定义一、生存期模型定义q 二、常用生存期模型q 三、案例分析第3页/共88页4建筑工程类项目典型生存期模型建筑工程类项目典型生存期模型第4页/共88页5制药项目典型生存期模型制药项目典型生存期模型第5页/共88页6生存期模型选择生存期模型选择 Productrealization InputOutput ProductCus

2、tomerRequirementsCustomerSatisfaction第6页/共88页7软件生存期模型软件生存期模型q软件开发的一种框架。q说明了软件的活动和进行软件开发的过程。q这个模型可以是以活动为中心，可以以产品为中心的。第7页/共88页8软件生存期模型特征软件生存期模型特征q 描述了开发的主要阶段q 定义了每一个阶段要完成的主要过程和活动q 规范了每一个阶段的输入和输出q 提供了一个框架，可以将必要的活动映射到该框架中。第8页/共88页9本章要点本章要点q 一、生存期模型定义q 二、常用生存期模型二、常用生存期模型q 三、案例分析第9页/共88页10常用生存期模型常用生存期模型q

3、瀑布Waterfallq V模型V-shapedq 原型Prototypingq 增量Incrementalq 螺旋式Spiralq 快速应用开发RADq 渐近式阶段第10页/共88页11本章要点本章要点q一、生存期模型定义q二、常用生存期模型q瀑布qV模型q原型q增量q螺旋式q快速应用开发q渐近式阶段q三、案例分析第11页/共88页12WaterFall modelWaterFall model需求分析设计实施测试维护第12页/共88页13第13页/共88页14 所有过程模型的鼻祖。- Royce,1970 基本思想是把软件开发过程划分成若干阶段，各个阶段相当于瀑布中的一个台阶，把软件过程比

4、喻成瀑布中的流水，暖流，在这些台阶中由上向下奔流。 瀑布模型每个阶段的任务相对独立，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度。 在软件的生存期的每个阶段都采用科学的管理技术和良好的方法与技术，而且每个阶段结束之前，都从技术和管理两个角度进行严格的审查，经确认之后才开始下一阶段工作。 瀑布模型适合于结构化开发方法。第14页/共88页15结构化分析过程第15页/共88页16 确定要开发软件系统的总目标。 给出功能、性能、接口等方面的要求，完成该软件任务的可行性研究。 估计可利用的资源(计算机硬件，软件，人力等)、成本、效益、开发进度。 制定出完成开发任务的实施计划,连同可行性研究

5、报告，提交项目管理部门审查。第16页/共88页17 对待开发软件提出的需求进行分析并给出详细的定义。 编写软件需求说明书或系统功能说明书及初步的系统用户手册。 提交管理机构评审。第17页/共88页18 总体设计 “如何解决问题”o可以列出多种解决方案进行比较o把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应 详细设计 对每个模块要完成的工作进行具体的描述，为源程序编写打下基础 编写设计说明书，提交评审。第18页/共88页19 把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”。 写出的程序应当是结构良好、

6、清晰易读的，且与设计相一致的。第19页/共88页20 单元测试：查找各模块在功能和结构上存在的问题并加以纠正。 组装测试：将已测试过的模块按一定顺序组装起来。 按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用。第20页/共88页21 改正性维护：运行中发现了软件中的错误需要修正。 适应性维护：为了适应变化了的软件工作环境，需做适当变更。 完善性维护：为了增强软件的功能需做变更。第21页/共88页22 里程碑或基线驱动，或者说是文档驱动。每个阶段必须完成规定的文档；每个阶段结束前完成文档审查,及早改正错误。 是一种严格线性的、按阶段顺序的、逐步细化的过程模型（开发

7、模式），阶段间具有顺序性和依赖性。过程逆转性很差或者说不可逆转，因为上流的错误会在下流进行发散性传播，逆转会延误工期，增加成本。第22页/共88页23 开发时间内需求没有或很少变化。 分析设计人员对应用很熟悉。 低风险项目，对目标和环境很熟悉。 用户使用环境很稳定。第23页/共88页24 当有一个稳定的产品定义和很容易被理解的技术解决方案时，可以采用纯瀑布模型。 当你对一个定义得很好的版本进行维护或将一个产品移植到一个新的平台上，可以采用瀑布模型。 在质量需求高于成本需求和进度需求的时候，可以采用瀑布模型。第24页/共88页25 在项目开始的时候，用户常常难以清楚地给出所有需求；用户与开发人员

8、对需求理解存在差异。 很少软件项目按照顺序模型进行，不能很好地支持迭代。 缺乏灵活性，因为瀑布模型确定了需求分析的绝对重要性，但是在实践中要想获得完善的需求说明是非常困难的，导致“阻塞状态”。反馈信息慢，开发周期长。 只有到了整个项目的后半段时间，客户才能看到软件的模样。一个没有及时发现的错误，可能导致灾难。 虽然存在不少缺陷，瀑布模型经常被嘲笑为“旧式的”，但是在需求被很好地理解的情况下，仍然是一种合理的方法。第25页/共88页26WaterFall modelWaterFall model适合的项目适合的项目q 项目的需求在项目开始前很明确q 解决方案在项目开始前也很明确q 类似的项目如：

9、q 公司的财务系统q 库存管理系统q 短期项目短期项目第26页/共88页27本章要点本章要点q一、生存期模型定义q二、常用生存期模型q瀑布qV模型q原型q增量q螺旋式q快速应用开发q渐近式阶段q三、案例分析第27页/共88页28V V模型模型接收测试集成测试系统测试项目规划 需求分析总体设计详细设计编码和调试集成测试单元测试第28页/共88页29V V模型模型适合的项目模型模型适合的项目q 项目的需求在项目开始前很明确q 解决方案在项目开始前也很明确q 对系统的性能安全很严格的项目q 类似的项目如：q 航天飞机等q 公司的财务系统 实例第29页/共88页30本章要点本章要点q一、生存期模型定义

10、q二、常用生存期模型q瀑布qV模型q原型q增量q螺旋式q快速应用开发q渐近式阶段q三、案例分析第30页/共88页31PrototypePrototype第31页/共88页32听取用户意见建造/修改原型用户测试运行原型第32页/共88页33建立原型目标开发原型定义原型功能评估原型原型规划框架定义可执行原型评估报告第33页/共88页34 原型是项目系统中的一个方面或者多个方面的工作模型。原型是项目系统中的一个方面或者多个方面的工作模型。 抛弃型原型：用于试验某些概念，试验完系统将无用抛弃型原型：用于试验某些概念，试验完系统将无用处处 进化型原型：原型系统不断被开发和被修正，最终它进化型原型：原型系

11、统不断被开发和被修正，最终它变为一个真正的系统。变为一个真正的系统。第34页/共88页35 有一个原型，描述了系统的主要功能。有一个原型，描述了系统的主要功能。 通过人机交互，让双方了解目标系统的操作。通过人机交互，让双方了解目标系统的操作。 有一个可运行的子集，用户可以评价需求和有一个可运行的子集，用户可以评价需求和设计。设计。 利用线性系统，不断演化形成最终系统。利用线性系统，不断演化形成最终系统。 降低了成本，及早发现错误、修改量小、开降低了成本，及早发现错误、修改量小、开发周期短。发周期短。第35页/共88页36 原型驱动。原型驱动。 优点：优点：o从实践中学习从实践中学习o改善沟通和

12、用户参与改善沟通和用户参与o使部分已知需求清晰化使部分已知需求清晰化o展示描述的一致性和完整性展示描述的一致性和完整性o提高系统的实用性、可维护性提高系统的实用性、可维护性第36页/共88页37 适用于用户驱动的系统，即需求模糊或随适用于用户驱动的系统，即需求模糊或随时间变化的系统。时间变化的系统。 已有产品或产品的原型，只需客户化的工已有产品或产品的原型，只需客户化的工程项目程项目 简单而熟悉的行业或领域简单而熟悉的行业或领域 有快速原型开发工具有快速原型开发工具 进行产品移植或升级进行产品移植或升级第37页/共88页38o用户有时误解了原型的角色，例如他们用户有时误解了原型的角色，例如他们

13、可能误解原型应该和真实系统一样可靠。可能误解原型应该和真实系统一样可靠。o缺少项目标准，进化原型方法有点像编缺少项目标准，进化原型方法有点像编码修正。码修正。o缺少控制，由于用户可能不断提出新要缺少控制，由于用户可能不断提出新要求，因而原型迭代的周期很难控制。求，因而原型迭代的周期很难控制。o额外的花费：研究结果表明构造一个原额外的花费：研究结果表明构造一个原型可能需要型可能需要10%10%额外花费。额外花费。o原型法要求开发者与用户密切接触，有原型法要求开发者与用户密切接触，有时这是不可能的。例如外包软件。时这是不可能的。例如外包软件。第38页/共88页39 虽然有问题存在，但是原型仍是软件

14、开发的一个有效范虽然有问题存在，但是原型仍是软件开发的一个有效范型。型。 关键是定义开始的游戏规则，即用户与开发者两方面必关键是定义开始的游戏规则，即用户与开发者两方面必须达成一致：原型被建造仅是为了定义需求，之后被抛须达成一致：原型被建造仅是为了定义需求，之后被抛弃（或至少部分被抛弃），实际的软件在充分考虑了质弃（或至少部分被抛弃），实际的软件在充分考虑了质量和可维护行之后才被开发。量和可维护行之后才被开发。第39页/共88页40Prototype Prototype 模型适合的项目模型适合的项目q 项目的需求在项目开始前不明确q 需要减少项目需求的不确定性q 类似的项目如：q 确定显示界面

15、q 第一次开发的产品，验证可行性第40页/共88页41本章要点本章要点q一、生存期模型定义q二、常用生存期模型q瀑布qV模型q原型q增量q螺旋式q快速应用开发q渐近式阶段q三、案例分析第41页/共88页42Incremental ModelIncremental Model核心功能核心功能112123第一增量第二增量第三增量核心功能112123第42页/共88页43第43页/共88页44增量模型 第一个增量模型往往是核心部分的产品，它实现了软件的基本要求。 核心产品交由用户使用或进行详细复审，结果是制定下一个增量开发计划（包括对核心产品的修改及增加新的功能）此过程在每一个增量发布后迭代地进行，

16、直到产生最终产品。 每一个增量是一个可操作的产品，不妨称之为“产品扩充迭代”。第44页/共88页45增量模型特点第45页/共88页46增量模型适合的项目增量模型适合的项目q 项目开始，明确了需求的大部分，但是需求可能会发生变化q 对于市场和用户把握不是很准，需要逐步了解q 对于有庞大和复杂功能的系统进行功能改进，就需要一步一步实施的。增量模型实例第46页/共88页47本章要点本章要点q一、生存期模型定义q二、常用生存期模型q瀑布qV模型q原型q增量q螺旋式q快速应用开发q渐近式阶段q三、案例分析第47页/共88页48Spiral ModelSpiral Model第48页/共88页49Spir

17、al ModelSpiral Model第49页/共88页50Spiral ModelSpiral Model适合的项目适合的项目q 风险是主要的制约因素q 不确定因素和风险限制了项目进度q 用户对自己的需求也不是很明确q 需要对一些基本的概念进行验证q 可能发生一些重大的变更q 项目规模很大q 项目中采用了新技术第50页/共88页51本章要点本章要点q一、生存期模型定义q二、常用生存期模型q瀑布qV模型q原型q增量q螺旋式q快速应用开发q渐近式阶段q三、案例分析第51页/共88页52RADRAD规划分析设计构建测试规划后置传统开发快速应用开发后置压缩第52页/共88页53快速应用开发模型特点

18、快速应用开发模型特点第53页/共88页54RADRAD模型适合的项目模型适合的项目q 很小并且具有探索性质的项目q 适合一个复杂度从小到大变化的项目，例如重整企业的信息系统第54页/共88页55本章要点本章要点q一、生存期模型定义q二、常用生存期模型q瀑布qV模型q原型q增量q螺旋式q快速应用开发q渐近式阶段q三、案例分析第55页/共88页56最常用的渐进式阶段模型最常用的渐进式阶段模型综合了增量模型和螺旋式模型的一个实用模型q 渐进式前进q 阶段式提交第56页/共88页57渐进式迭代模型 57第57页/共88页58阶段性完成规划阶段性完成规划第58页/共88页59渐进式阶段模型的特点渐进式阶

19、段模型的特点q 阶段式提交一个可运行的产品q 关键的功能更早出现q 早期预警问题，避免软件缺陷不知不觉的增长q 减少报告负担q 阶段性完成可以降低估计失误q 阶段性完成均衡了弹性与效率第59页/共88页60渐进式阶段模型适合的项目渐进式阶段模型适合的项目q可以适合任何规模的项目，主要是中型或大型项目q希望随时看到未来的项目第60页/共88页61银行业务系统的生存期实例银行业务系统的生存期实例产品阶段1设计业务需求分析原形系统分析项目规划集成测试产品阶段1开发产品阶段n设计产品阶段n开发确认测试产品提交银行业务需求原形系统源代码项目规划项目规划第61页/共88页62产品阶段1设计q 阶段目标：设

20、计公共控制系统功能模块q输入：系统设计文件q数据库结构定义q过程：详细设计q输出：详细设计文件q时间计划：2001/1/15-2001/2/15（暂定） 第62页/共88页63其它模型其它模型q 其他q 例如:Code and fixq 自定义第63页/共88页64 从一个大致的想法开始工作，然后经过非正规的设计、编码和测试，最后完成全部工作。可能有或可能没有规格发布（可能）第64页/共88页65 好处：好处： 成本可能很低。 只需要很少的专业知识，任何写过程序的人都可以。 适用于一些非常小的、开发完后就会很快丢弃的软件。 缺点：缺点： 对于规模稍大的项目，采用这种模型使项目难以控制。第65页/共88页66Code and fixCode and fix需求了解编码、走查编译、检错修正编写文档提交修正测试第66页/共88页67选择生存期的步骤选择生存期的步骤q 熟悉各种生存期模型q 评审、分析项目的特性q 选择适合项目的生存期模型q 标识生存期模型与项目不一致地方,并进行裁减第67页/共88页68All =All =第68页/共88页69RationalRational统一开发过程统一开发过程初始细化构造移