软件工程案例开发与实践 第2章 软件开发过程概述.ppt

第2章软件开发过程概述 2 1软件生命周期软件生存周期一般划分为三个阶段 1 问题定义与规划 2 开发时期 3 软件维护时期 2 1 1问题定义与规划 这个时期的任务是 1 确定软件开发工程必须完成的总目标 2 确定工程的可行性 3 导出实现工程目标应该采用的策略及软件必须具有的功能 4 估算完成该项开发工程需要的资源和成本 并且制定工程进度表 2 1 2软件开发阶段 一个软件的开发包括四个步骤 1 需求分析 2 概要设计 3 详细设计 4 编码和测试 这两个过程是同步进行的 5 系统测试 2 2软件开发方法综述 2 2 1结构化方法结构化开发方法是由E Yourdon和L L Constantine提出的 即所谓的SASD方法 也可称为面向功能的软件开发方法或面向数据流的软件开发方法 Yourdon方法是80年代使用最广泛的软件开发方法 它首先用结构化分析 SA 对软件进行需求分析 然后用结构化设计 SD 方法进行总体设计 最后是结构化编程 SP 它给出了两类典型的软件结构 变换型和事务型 使软件开发的成功率大大提高 2 2 2面向数据结构的软件开发方法 Jackson方法是最典型的面向数据结构的软件开发方法 Jackson方法把问题分解为可由三种基本结构形式表示的各部分的层次结构 三种基本的结构形式就是顺序 选择和重复 三种数据结构可以进行组合 形成复杂的结构体系 这一方法从目标系统的输入 输出数据结构入手 导出程序框架结构 再补充其它细节 就可得到完整的程序结构图 2 2 3面向问题的分析法 PAM 面向问题的分析法 PAM ProblemAnalysisMethod 是80年代末由日立公司提出的一种软件开发方法 它的基本思想是考虑到输入 输出数据结构 指导系统的分解 在系统分析指导下逐步综合 这一方法的具体步骤是 从输入 输出数据结构导出基本处理框 分析这些处理框之间的先后关系 按先后关系逐步综合处理框 直到画出整个系统的PAD图 2 2 4面向对象的开发方法 面向对象系统采用了自底向上的归纳 自顶向下的分解的方法 它通过对对象模型的建立 能够真正建立基于用户的需求 而且系统的可维护性大大改善 当前业界关于面向对象建模的标准是UML 2 2 5可视化开发方法 可视化开发并不能单独的作为一种开发方法 更加贴切的说可以认为它是一种辅助工具 比如 S Design PowerDesigner PowerBuilder VB DELPHI C Builder等 2 3软件开发模型 2 3 1瀑布模型将软件生命周期划分为制定计划 需求分析 软件设计 程序编写 软件测试和运行维护等六个基本活动 并且规定了它们自上而下 相互衔接的固定次序 如同瀑布流水 逐级下落 2 3 2螺旋模型 螺旋模型沿着螺线进行若干次迭代 图2 5中的四个象限代表了以下活动 螺旋模型沿着螺线旋转 每个螺旋推进的过程都是渐进的实现过程 整个过程的实现 按照 制定计划 风险分析 实施工程和客户评估 四个步骤循环实施 1 制定计划 确定软件目标 选定实施方案 弄清项目开发的限制条件 定义资源 进度及其他相关项目信息所需要的任务 以调整项目的目标和改善系统实施的效率 2 风险分析 分析评估所选方案 考虑如何识别和消除风险 从风险角度分析方案的开发策略 努力排除各种潜在的风险 有时需要通过建造原型来完成 如果某些风险不能排除 该方案立即终止 否则启动下一个开发步骤 基于上述目标 评估技术及管理的风险 以决定如何实施项目 3 实施工程 实施软件开发和验证 包括系统需求分析 概要设计 详细设计 编程 单元测试 系统测试和验证测试等项目具体实施的各种任务 4 客户评估 评价开发工作 提出修正建议 制定下一步计划 螺旋模型的缺点是 1 它可能难以使用户相信演化方法是可控的 2 瀑布模型要求在软件开发的初期就完全确定软件的需求 这在很多情况下往往是无法实现的 螺旋模型加入了瀑布模型所忽略的风险分析 从而弥补了瀑布模型的不足 螺旋模型也有一定的限制条件 这些限制条件是 1 螺旋模型强调风险分析 但要求许多客户接受和相信这种分析 并做出相关反应是不容易的 因此 这种模型往往适应于内部的大规模软件开发 2 如果执行风险分析将大大影响项目的利润 那么进行风险分析毫无意义 因此 螺旋模型只适合于大规模软件项目 3 软件开发人员应该擅长寻找可能的风险 准确地分析风险 否则将会带来更大的风险 2 3 3增量模型 增量模型和瀑布模型之间的本质区别是 瀑布模型属于整体开发模型 它规定在开始下一个阶段的工作之前 必须完成前一阶段的所有细节 而增量模型属于非整体开发模型 它推迟某些阶段或所有阶段中的细节 从而较早的产生工作软件 增量模型是在项目的开发过程中以一系列的增量方式开发系统 增量方式包括增量开发和增量提交 增量模型也存在以下缺陷 1 由于各个构件是逐渐并入已有的软件体系结构中的 所以加入构件必须不破坏已构造好的系统部分 这需要软件具备开放式的体系结构 2 在开发过程中 需求的变化是不可避免的 增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型 但也很容易退化为边做边改模型 从而是软件过程的控制失去整体性 2 3 4喷泉模型 该模型表明软件刻画活动需要多次重复 例如 在编码之前 实践之后 再次进行分析和设计 其间添加有关功能 使系统得以演化 同时 该模型还表明活动之间没有明显的间隙 例如在分析和设计之间没有明显的界限 2 4快速原型开发 软件原型化方法是指 在获得一组基本需求说明后 经过快速分析构造出一个小型的软件系统 原型系统 满足用户的基本要求 用户试用该原型系统 从中得到感受和启发 并对该原型系统做出反映和评价 然后开发者根据用户的意见对原型加以改进 随着不断地实验 纠错 使用 评价和修改 不断获得新的原型版本 如此反复 逐步减少分析和通信中的误解 弥补不足 进一步确定各种需求细节 适应需求的变更 从而提高最终产品的质量 2 4 2 软件原型的分类 1 废弃型也称为快速建立需求规格原型RSP法 先构造一个功能简单而且质量要求不高的模型系统 针对这个模型系统反复进行分析修改 从而形成较好设计思想 2 追加型也称为快速建立渐进原型RCP法 采用循环渐进的开发方式 对系统模型作连续精化 即先构造一个功能简单而且质量要求不高的模型系统 作为最终系统的核心 将系统需要具备的性质逐步添加上去 通过不断地扩充修改 逐步追加新的要求 直至所有性质全部满足 此时的原型模型也就是最终的产品 2 4 3 原型软件的周期 1 原型分析原型分析是指在分析者和用户的紧密配合下 快速确定软件系统的基本要求 根据原型所要体现的特性 或总体结构 处理功能 模拟性能 界面形式等 描述基本需求规格说明 以满足开发原型的需要 当在分析阶段使用原型化方法时 必须从系统结构 逻辑结构 用户特征 应用约束 项目管理和项目环境等多方面来考虑 以决定是否采用原型化方法 2 原型构造在原型分析的基础上 根据基本需求规格说明 忽略细节 只考虑主要特性 快速构造一个可运行的系统 为此需要强有力的软件工具的支持 3 原型运行与评价原型运行与评价阶段是软件开发人员与用户频繁通讯 发现问题 消除误解的重要阶段 其目的是验证原型的正确程度 进而开发新的并修改原有的需求 4 原型修正对于原型系统 一定要根据修改意见进行修正 如果原型运行的结果没能满足需求规格说明中的需求 那么就反映出对需求规格说明存在着不一致的理解或实现方案不够合理 若因为严重的理解错误而使正常操作的原型与用户要求相违背时 就有可能产出废品 因此应当立即放弃 5 判定原型完成如果原型经过修正或和改进 获得了参与者的一致认可 那么原型开发的迭代过程可以结束 为此 应判断有关应用的实质是否已经掌握 迭代周期是否可以结束等 判定的结果有两个不同的转向 一个是继续迭代验证 另一个是进行详细说明 比如将需求转化为报表 给出统计数字等 对于那些不能通过模型进行说明的成分 如果必要 须提供说明 并利用屏幕等进行讨论和确定 6 判定原型效果考察用户新加入的需求信息和细部说明信息 看其对模型效果有何影响 是否会影响模块的有效性 如果使模型效果受到影响 甚至导致模型实效 则要进行修正和改进 7 整理原型和提供文档整理原型的目的是为进一步开发提供依据 原型的初期需求模型是一个自动的文档 2 4 4快速原型的优点 1 增进了软件开发人员和用户对系统需求的理解 便于将用户模糊的功能需求明确化 2 为用户提供