[计算机软件及应用]第2章 软件开发过程管理.ppt

结束 软件项目管理 第2章 软件开发过程管理 信息学院 2013年3月 结束 7 2.1 软件生命周期 软件生命周期是“从设计软件产品开始到软件产品 不能再使用为止的时间周期。 典型的软件生命周期包括：需求阶段、设计阶段 、实现阶段、测试阶段、安装和验收阶段、运行和 维护阶段，有时还包括引退阶段”。 软件生命周期可以划分成若干个相互独立而又相 互联系的阶段，每一阶段工作以上一阶段工作的结 果为依据，并为下一阶段工作提供基础。 结束 7 2.2 软件过程 1. 软件过程的定义 软件过程是指软件生命周期中的一系列相关过程，是将用 户需求转化为可执行系统的演化过程所进行的软件工程的全部 活动，是用于生产软件产品的工具、方法和实践的集合。 软件过程是关系复杂的软件活动的集合，各活动之间有着 严格密切的关系，有的是异步并行，有的是互为条件，因此实 际软件过程中的软件活动存在复杂的网状关系。 软件过程是改进软件质量和组织性能的主要因素之一。 结束 7 2.2 软件过程 2. 软件过程管理的必要性 u提高软件企业的开发效率和产品质量； u有效地对软件开发项目进行管理； u有帮助软件机构做出正确决策； u提高软件的可重用性和组间协作； u改善软件机构对软件的维护； u不断采用新的、更好的软件开发经验。 结束 7 2.2 软件过程 3. 软件过程管理的组成 结束 7 2.3 软件开发过程 软件开发过程是以生命周期各阶段的活动划分为 基础，将用户需求转化为软件系统活动集合的过程 。 1. 开发计划和可行性研究阶段 2. 需求分析阶段 3. 软件设计阶段 4. 编写代码阶段 5. 软件测试阶段 结束 7 2.4 软件开发过程模型 由于这种方法是从一个阶段成瀑布流入下 一个阶段，所以称为“瀑布模型”。 瀑布模型是从时间角度对软件开发和维护 的复杂问题进行分解。按软件生命周期依次划 分为六个阶段： 可行性研究、需求分析、软件设计、软件 编码、软件测试、运行与维护。 2.4.1 瀑布模型 结束 7 2.4 软件开发过程模型 1. 理论的瀑布模型 2. 实际的瀑布模型 2.4.1 瀑布模型 结束 7 2.4 软件开发过程模型 3. 瀑布模型总结 运用瀑布模型应坚持做到以下两点： （1）每个阶段都完成规定的文档，没有交 出合格的文档就没有完成阶段性工作。 （2）每个阶段结束前都要对提交的文档进 行评审，以便尽早发现问题，改正错误。 2.4.1 瀑布模型 结束 7 2.4 软件开发过程模型 3. 瀑布模型总结2.4.1 瀑布模型 结束 7 2.4 软件开发过程模型 2.4.2 V模型 V模型是瀑 布模型的一种 变体，由于整 个开发过程构 造成一个V字 形而得名。 结束 7 2.4 软件开发过程模型 1. 从水平方向看 垂直虚线左边是分析和设计，是软件设计实现的过程，同时 伴随着质量保证活动审核的过程，也就是静态的测试过程 ；垂直虚线右边是对左边结果的验证，是动态测试的过程， 即对分析和设计的结果进行测试，以确认是否满足用户需求 。左右两边的对应关系如下： （1）需求分析对应验收测试。 （2）概要设计对应系统测试。 （3）详细设计对应集成测试。 （4）软件编码对应单元测试。 2.4.2 V模型 结束 7 2.4 软件开发过程模型 2. 从垂直方向看 水平虚线上部，需求分析、系统定义和验收测试等工 作主要是面向用户。水平虚线下部是技术工作，主要由 工程师、技术人员完成。 从垂直方向看，越在下面，白盒测试方法使用越多， 中间部分是灰盒测试方法。在验收测试过程中，使用黑 盒测试方法。 2.4.2 V模型 结束 7 2.4 软件开发过程模型 为解决瀑布模型需求理解困难、开发周期 长、见效慢等问题，借助第4代程序开发语言 而产生的一种软件开发方法。 软件开发人员先根据用户提出的软件定义 ，快速开发一个原型，向用户展示。然后用户 根据这个原型提出修改意见，再进一步修改、 完善，确认软件系统的需求并达到一致的理解 。 2.4.3 原型模型 结束 7 2.4 软件开发过程模型 2.4.3 原型模型 1. 原型模型的基本过程 结束 7 2.4 软件开发过程模型 2.4.3 原型模型 2. 原型模型的软件支撑环境 u 方便灵活的关系数据库系统； u 完整的程序生成软件； u 与数据库对应的、方便灵活的数据字典； u 可以快速抽象或者容易提炼的原型。 结束 7 2.4 软件开发过程模型 2.4.3 原型模型3. 原型模型的优缺点和适用情况 结束 7 2.4 软件开发过程模型 2.4.4 螺旋模型 勃姆（Boehm， B.W）将瀑布模型与 快速原型模型结合起 来提出了螺旋模型。 要求不断迭代， 同时要象螺旋一样不 断前进，即每次迭代 都不是在原水平上进 行，是对整个开发过 程进行迭代，而不仅 仅对编码、测试进行 迭代。 结束 7 2.4 软件开发过程模型 2.4.4 螺旋模型 1. 工作步骤和内容 （1）确定下一阶段目标、开发方案及约束条件。 （2）风险分析、构造原型。 （3）开发、验证阶段软件产品。 （4）制订下一阶段计划。 结束 7 2.4 软件开发过程模型 2.4.4 螺旋模型 2. 螺旋模型对经常遇见问题提供的解决方案 结束 7 2.4 软件开发过程模型 2.4.4 螺旋模型 3. 螺旋模型的优缺点和适用情况 结束 7 2.4 软件开发过程模型 2.4.5 增量模型 首先创建一组核心功能，或者是项目至关重要的最 高优先级的系统，或者是能够降低风险的系统。随后基 于核心功能反复扩展，逐步增加功能以提高性能。 增量模型降低了取得初始功能之前的成本，强调采 用构建方法来控制更改需求的影响，提高了创建可操作 软件系统的速度。 增量模型综合了瀑布模型和原型模型，提倡以功能 渐增方式开发软件。 结束 7 2.4 软件开发过程模型 2.4.5 增量模型 增量模型结构 结束 7 2.4 软件开发过程模型 2.4.5 增量模型 1. 增量开发必须注意的问题 u 良好的可扩展性架构设计，是增量开发成功的基础； u 由于一些模块必须在另一个模块之前完成，所以必须定义良好的接 口； u 与完整系统相比，增量方式正式评审更难于实现，所以必须定义可 行的过程； u 要避免把难题往后推，首先完成的应该是高风险和重要的部分； u 客户必须认识到总体成本不会更低； u 分析阶段采用总体目标而不是完整的需求定义，可能不适应管理； u 需要良好的计划和设计，管理必须注意动态分配工作，技术人员必 须注意相关因素的变化。 结束 7 2.4 软件开发过程模型 2.4.5 增量模型 2. 增量模 型的优缺 点和适用 情况 结束 7 2.4 软件开发过程模型 是增量型的软件开发过程模型，强调极短的开发 周期，是瀑布模型的一个“高速”变种，通过大量使用 可复用构件，采用基于构件的建造方法进行快速开发 2.4.6 RAD模型 结束 7 2.4 软件开发过程模型 1. RAD模型各个活动期要完成的任务 如果一个业务能够被模块化使得其中每一个主要功能 均可以在不到3个月的时间内完成，则是RAD的一个候选。 一个主要功能可由一个单独的RAD组来实现，最后集成起来 形成一个整体。 （1）业务建模。 （2）数据建模。 （3）过程建模。 （4）应用生成。 （5）测试交付。 2.4.6 RAD模型 结束 7 2.4 软件开发过程模型 2. RAD模型的缺陷 （1）并非所有应用都适合RAD。 （2）开发人员和客户必须在很短时间内完成一系列 的需求分析，任何一方配合不当都会导致RAD项目失败。 （3）RAD不适合技术风险很高的软件项目。 2.4.6 RAD模型 结束 7 2.4 软件开发过程模型 2.4.7 软件包模型 主要 用于开发 依赖于外 购（协） 软件产品 和可重用 软件包的 系统。 结束 7 2.4 软件开发过程模型 2.4.7 软件包模型 1. 软件包模型的开发步骤 （1）需求分析和软件包标识。 （2）结构定义和软件包选择。 （3）系统集成和测试。 （4）技术修改和系统维护。 结束 7 2.4 软件开发过程模型 2.4.7 软件包模型 2. 软件包模型的优缺点和适用情况 结束 7 2.4 软件开发过程模型 2.4.8 遗留系统维护模型 主要用 于纠错性维 护或者稍加 改进一个运 行系统。 结束 7 2.4 软件开发过程模型 2.4.8 遗留系统维护模型 结束 喷泉模型 维护进一步 开发 程序使用 系统测试 系统组装 构件设计 系统设计 分析 需求分析与可行性研究 软件平台 真实世界 基于复用的面向对象软件生命周期“喷泉”模型 结束 喷泉模型中每个活动阶段用一个圆圈表示。说明每个活动相对独 立地完成一定的任务。圆圈之间的重叠显示了面向对象 方法各阶段是比较平稳地过渡且反复进行的。每个圆圈中的一对向下 的小箭头表示各个活动均可将信息返回到前面的活动，这又体现了原 型化的思想。 从图中可以看出，喷泉模型有以下特征： 各项活动的步进性 步进性指明了活动的先后顺序，强调软件的增量开发，它体现了 设计一点，开发一点的原则。 覆盖性 覆盖性指明了能同时进行的活动，反映了软件开发的并行性。不 与其它任何活动发生覆盖的活动（如系统测试），只有在以前的活动 完成之后方能进行。 反复性 喷泉的每次“喷射”都是对系统的一次提炼，一次逼近，也就是说开 发过程的任何点只要需要都可以反复到它以前的任何活动继续步进地 开发，这又反映软件开发的原型化思想 结束 7 2.5 软件开发过程模型选择 目前，大多数软件开发项目都采用瀑布模型 作为规范化开发的基础，主要原因如下： （1）软件开发单位的软件工程工作尚处于初级阶段， 软件开发人员和管理人员既缺乏经验，又无历史数据可供借 鉴，因此，需要一种简单易行的组织方式。 （2）结构化方法学是系统工程中最成熟的方法学，目 前大多数软件开发都以结构化开发方法学为基础。在与结构 化方法学相适应的软件开发过程模型中，瀑布模型最为简单 实用，行之有效。 （3）有关软件开发的现行国家标准和国家军用标准都 是以瀑布模型为基础制定的。 结束 7 2.5 软件开发过程模型选择 选择开发过程模型时，一般应遵循下述原则： u 开发过程模型应与软件项目的特点相适应； u 开发过程模型应与采用的软件开发技术相适应； u 开发过程模型应满足整个应用系统的开发进度要求 ； u 开发过程模型应有助于控制和消除软件开发风险； u 开发过程模型应有可用的计算机辅助工具的支持； u 开发过程模型应与用户和软件开发人员的知识和技 能水平相适应； u 开发过程模型应有利于软件开发的管理和控制。 结束 7 2.6 传统开发过程存在的问题 传统开发过程基本是 单纯的技术实施过程，既 没有定义必要的项目过程 管理，也没有定义技术过 程如何与项目管理相结合 。这种软件开发过程模式 产生的结果很难预测，极 容易造成管理上的失控。 结束 7 2.6 传统开发过程存在的问题 2.6.1 管理方面 1. 忽视软件过程管理 （1）没有规范和切实可行的管理体系。 （2）不能真正区分技术实施和过程管理的工作任务。 2. 计划过程粗略，执行控制不力 （1）项目管理计划粗略。 （2）开发计划不充分。 3. 缺乏需求基准 4. 缺乏成本控制体系和过程 5. 质量保证过程薄弱 （1）开发过程不规范。 （2）测试过程不规范。 （3）缺少SQA相关质量保证过程。 结束 7 2.6 传统开发过程存在的问题 2.6.2 技术方面 1. 需求分析 问题1：客户并不知道自己需要什么。 问题2：需求在项目进行过程中发生改变。 2. 软件设计 （1）僵化设计难以改变。 （2）脆弱性设计易于遭到破坏。 （3）牢固性设计难以重用。 （4）粘滞性难以做正确的事情。 （5）不必要的复杂性过度设计。 结束 7 2.6 传统开发过程存在的问题 2.6.2 技术方面 3. 代码编写 （1）程序员各自为战，缺乏分工合作。 （2）对于编程语言及工具不能准确掌握。 （3）不必要的重复。 （4）晦涩混乱的表达。 4. 测试 （1）认为规范化软件测试是增加项目成本。 （2）期望短期通过增加软件测试投入，迅速达到零Bug率。 （3）期望用测试自动化代替大部分手工劳动。 （4）忽视前期需求分析和设计阶段的参与。 （5）忽视用户操作密集及核心功能的回归测试。 （6）忽视软件测试文档。 结束 7 2.7 实施软件开发过程管理 2.7.1 管理方面 1. 加强对技术过程的管理控制 2. 完备的计划过程，严格的执行控制 3. 建立需求基准和项目范围基准 4. 基于WBS的成本控制体系，基于进度 的成本控制过程 5. 质量保证过程贯穿项目始终 结束 7 2.7 实施软件开发过程管