软件开发与应用软件工程学概述PPT课件_第1页
软件开发与应用软件工程学概述PPT课件_第2页
软件开发与应用软件工程学概述PPT课件_第3页
软件开发与应用软件工程学概述PPT课件_第4页
软件开发与应用软件工程学概述PPT课件_第5页
已阅读5页,还剩69页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1 软件开发与应用 胡俊敏Email wingoner 2009 2 集美大学工商管理学院信息管理与信息系统系 2 课程总体安排 第一章软件工程学概述第二章可行性研究第三章需求分析第四章形式化说明技术第五章总体设计第六章详细设计第七章实现第八章维护第九章面向对象方法学引论第十章面向对象分析第十一章面向对象设计第十二章面向对象实现第十三章软件项目管理 3 本章导读 引言 一个盖房问题引发的思考第一章软件工程学概述软件危机软件工程软件生命周期软件过程小结 4 引言 一个盖房问题引发的思考 问题讨论 盖不好的屋顶 5 盖不好的屋顶 有人要挣钱没 有 有 6 这是我的房子 少个屋顶盖 7 材料我都准备好了 给我安上就好 能做的来么 这么容易 没问题 8 你看你们都怎么做的 一个屋顶搞得坑坑洼洼 你们到底做过没 会不会做啊 9 这个 要有个工序 不是光有力气就可以的 钱 不给了 之前没做过 不过这个有把子力气不是就可以 10 干这么辛苦竟然没有钱 11 讨论问题 一 应该给工人工钱么 二 这个工程为什么失败了 三 你能从中得到什么样的经验 12 软件开发与应用 课程教学的目标 转变对软件的认识 上升程序系统转变思维定式 上升程序员系统工程师 系统分析员 工程化训练 13 第1章软件工程学概念 软件危机软件工程软件生命周期软件过程小结 软件的发展过程软件危机的表现软件危机产生的原因消除软件危机途径 14 软件的发展 软件发展的四个阶段1950 1965没有系统的软件开发方法和管理机制 自定义软件 批处理 有限分布 1965 1975产生人机交互的新概念 新技术软件产品 多用户 实时 数据库 15 软件的发展 软件发展的四个阶段1973 1988微处理器的出现并广泛应用分布式系统 嵌入智能 低成本硬件 消费者的影响 1986 2000广域和局域网络迅速普及强大的桌面系统 面向对象技术 专家系统 人工智能 神经网络 并行计算 网络计算机 16 软件的发展 软件发展存在的问题软件开发能力不能满足人们的需要 社会对软件的依赖程度加大 人们普遍关注软件的安全和可靠性 建造高可靠性 高质量软件的任务任重路远 17 软件的发展 软件发展存在的问题若干年前开发的应用软件经过几十次修改已无人认识它的内部结构 己经不可维护 遗留软件 由于经济原因 嵌入式系统存在许多怪现象 企业不愿意投入资源再生产 而采取打补丁 时髦界面的方法 18 软件 软件是计算机系统的重要组成部分 软件是逻辑产品 需要计算机硬件和系统软件的支撑 软件是计算机控制系统的指挥中枢 软件是信息转换器 它能对信息进行加工 处理或变换 软件是工具 在人们的生活 工作 休闲 在社会的经济 军事 政治 文化 科学技术 教育中发挥具大作用 19 软件 计算机世界的软件软件是能够完成预定功能和性能 并对相应数据进行加工的程序和描述程序及其操作的文档 软件 程序 数据 文档程序 算法 数据结构 思考 软件 程序 20 软件 软件与硬件的相比的特点 21 软件 软件与硬件的失效率比较 22 1 2软件 软件分类 按功能划分按规模划分按工作方式划分按服务对象划分 系统软件支撑软件应用软件 微型 小型 中型 大型等 分时处理 实时处理 批处理 交互处理 项目软件和产品软件 23 软件 关于软件的几个认识问题你同意以下几种说法么 需求分析和写需求文档不重要 可以程序都写好了 再回头补充 既然需求分析很困难 不管三七二十一先把软件做了再说 反正软件是灵活的 随时可以修改 软件编写完成以后就万事大吉了 如果我们落后于计划 可以增加更多的程序员来解决 24 人月神话 开篇 史前史中 没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼 上帝见证着恐龙 猛犸象 剑齿虎在焦油中挣扎 它们挣扎得越是猛烈 油纠缠得越紧 没有任何猛兽足够强壮或具有足够的技巧 能够挣脱束缚 它们最后都沉到了坑底 过去几十年的大型系统开发就犹如这样一个焦坑 很多大型和强壮的动物在其中剧烈地挣扎 他们中大多数开发出了可运行的系统 不过 其中只有非常少数的项目满足了目标 时间进度和预算的要求 各种团队 大型的和小型的 庞杂的和精干的 一个接一个淹没在了焦油坑中 表面上看起来好像没有任何一个单独的问题会导致困难 每个都能被解决 但是当它们相互纠缠和累积在一起的时候 团队的行动就会变得越来越慢 对问题的麻烦程度 每个人似乎都会感到惊讶 并且很难看清问题的本质 不过 如果我们想解决问题 就必须试图先去理解它 25 软件危机 软件危机 软件开发中遇到的问题找不到解决的办法 致使问题积累起来 形成了日益尖锐的矛盾 研究表明 每6个新的大型软件系统投入运行 就有2个系统被取消 软件开发项目的开发时间平均超出计划时间的50 所有大型系统中 大约有3 4的系统有运行问题 要么不像预料的那样起作用 要么根本不能使用 26 软件危机 例如1 Therac 25事件 1985 87年 带有软件控制器的放射线疗法仪器抛弃了硬件互锁 但软件没有互锁 由于程序员对并发编程没有经验 软件不能维持必要的不变量 电子束模或是强烈的光线和金属板干扰 产生X射线 因为灼伤导致了几起死亡 例如2 1996年Atlantic奥运会 IBM赞助的名为Info 96网络 由于数据传输只有9600位 秒 经常因为设计时的考虑不周而使下图 大塞车 造成比赛中断 27 软件危机 软件危机的典型表现对软件开发成本 进度以及工作量的估计常常很不准确用户对 已完成的 软件系统不满意的现象经常发生软件产品的质量往往靠不住软件常常是不可维护的软件通常没有适当的文档资料软件成本在计算机系统总成本中所占的比例逐年上升软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的趋势 28 软件危机 软件危机原因软件的规模加大 复杂性提高 性能增强 软件是逻辑产品 尚未完全认识其本质和特点 缺乏有效的 系统的开发 维护大型软件项目的技术手段和管理方法 29 软件危机 软件危机原因用户对软件需求的描述和软件开发人员对需求的理解往往存在差异 用户经常要求修改需求 开发人员很难适应 软件开发的技术人员和管理人员缺乏软件工程化的素质和要求 对工程化的开销认识不足 30 软件危机 软件危机仍在继续 影响软件质量的糊涂认识在项目的初始阶段对系统若明若暗就开始写程序 认为软件是灵活的容易修改 对软件需求的改变不以为然 程序调试成功标志着工作的结束 31 软件危机 软件危机仍在继续 影响软件质量的糊涂认识程序运行前无法评价程序的质量 一个软件项目给客户提交的主要是程序 而软件文档则认为可有可无 可多可少等等 虽然发布了软件标准和规范 但在实践中执行需要额外的开销 划不来 32 软件危机 软件危机仍在继续 影响软件质量的糊涂认识虽然开发了许多软件工具 但很多开发者对使用这些工具兴趣不大 为了开发软件人们不惜用重金购买最新型号的主机和工作站而不愿意购买软件工具 在软件开发过程中 进度迟后就增派更多的程序员突击 赶进度 33 消除软件危机的途径 正确认识 管理 工具 提出你的意见 34 软件工程 一种层次化技术 软件工程1968年北大西洋公约组织NATO的计算机科学家在联邦德国召开国际会议 讨论软件危机问题 在这次会议上正式提出并使用了 软件工程 这个名词 一门新兴的工程学科就此诞生了 35 软件工程 一种层次化技术 软件工程的定义1968年第一届NATO会议 软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件 而建立和使用完善的工程原理 1993年IEEE 软件工程是 把系统的 规范的 可度量的途径应用于软件开发 运行和维护过程 也就是把工程应用于软件 研究 中提到的途径 概括来说 软件工程就是 采用工程的概念 原理 技术和方法来开发与维护软件 把经过时间考验证明正确的管理技术和当前能够得到的最好的技术方法结合起来 以经济地开发出高质量的软件并有效地维护它 36 软件工程 一种层次化技术 软件工程的本质以工程化的思想来约束软件本身特点所带来的不规范 两个基本点 控制协调 变化性 复杂性 效率 团队 用户 产品 37 软件工程 一种层次化技术 软件工程的基本原理著名的软件工程专家B W Boehm于1983年综合了软件工程专家学者们的意见并总结了开发软件的经验 提出了软件工程的7条基本原理 这7条原理被认为是确保软件产品质量和开发效率的原理的最小集合 又是相互独立 缺一不可 相当完备的最小集合 38 软件工程 一种层次化技术 软件工程的基本原理 用分阶段的生存周期计划严格管理这条基本原理是应该把软件生存周期划分成若干个阶段 并相应地制定出切实可行的计划 然后严格按照计划对软件开发与维护工作进行管理 应该制定的计划有项目概要计划 里程碑计划 项目控制计划 产品控制计划 验证计划和运行维护计划等 各级管理人员都必须严格按照计划对软件开发和维护工作进行管理 据统计 不成功的软件项目中 有一半左右是由于计划不周造成的 39 软件工程 一种层次化技术 软件工程的基本原理 坚持进行阶段评审据统计 在软件生存周期各阶段中 编码阶段之前的错误约占63 而编码错误仅占37 另外 错误发现并改正得越晚 所花费的代价越高 坚持在每个阶段结束前进行严格的评审 就可以尽早发现错误 从而可以最小的代价改正错误 因此 这是一条必须坚持的重要原理 40 软件工程 一种层次化技术 软件工程的基本原理 实行严格的产品控制决不能随意改变需求 只能依靠科学的产品控制技术来顺应用户提出的改变需求的要求 为了保持软件各个配置成分的一致性 必须实行严格的产品控制 其中主要是实行基准配置管理 又称为变动控制 即凡是修改软件的建议 尤其是涉及基本配置的修改建议 都必须按规程进行严格的评审 评审通过后才能实施 这里的 基准配置 是指经过阶段评审后的软件配置成分 即各阶段产生的文档或程序代码等 41 软件工程 一种层次化技术 软件工程的基本原理 采用现代程序设计技术实践表明 采用先进的程序设计技术既可以提高软件开发与维护的效率 又可以提高软件的质量 多年来 人们一直致力于研究新的 程序设计技术 比如 20世纪60年代末提出的结构程序设计技术 后来又发展出各种结构分析 SA 和结构设计 SD 技术 之后又出现了面向对象分析 OOA 和面向对象设计 OOD 技术等等 42 软件工程 一种层次化技术 软件工程的基本原理 结果应能清楚地审查软件产品是一种看不见 摸不着的逻辑产品 因此 软件开发小组的工作进展情况可见性差 难于评价和管理 为了更好地进行评价与管理 应根据软件开发的总目标和完成期限 尽量明确地规定软件开发小组的责任和产品标准 从而使所得到的结果能清楚地审查 43 软件工程 一种层次化技术 软件工程的基本原理 开发小组的人员应少而精软件开发小组人员素质和数量是影响软件质量和开发效率的重要因素 实践表明 素质高的人员与素质低的人员相比 开发效率可能高几倍甚至几十倍 而且所开发的软件中的错误也要少得多 另外 开发小组的人数不宜过多 因为随着人数的增加 人员之间交流情况 讨论问题的通信开销将急剧增加 这不但不能提高生产率 反而由于误解等原因可能增加出错的概率 44 软件工程 一种层次化技术 软件工程的基本原理 承认不断改进软件工程实践的必要性遵循上述六条基本原理 就能够较好地实现软件的工程化生产 但是 软件工程不能停留在已有的技术水平上 应积极主动地采纳或创造新的软件技术 要注意不断总结经验 收集工作量 进度 成本等数据 并进行出错类型和问题报告的统计 这些数据既可用来评估新的软件技术的效果 又可用来指明应优先进行研究的软件工具和技术 案例分析 45 软件工程 一种层次化技术 软件工程是一种层次化的技术将系统的 规范的 可量化的方法运用到软件工程的始终 渗透到软件工程的过程 方法和工具三个要素中 质量是软件工程的生命线 软件工程以质量保证为基础 质量管理促进了过程的改进 创造了许多行之有效的软件开发方法和工具 46 软件工程 一种层次化技术 47 软件工程 一种层次化技术 软件工程的过程软件工程的基础是过程层 过程贯穿软件开发的各个阶段 环节 各阶段之间建立里程碑 过程是粘结剂 把方法和工具粘结在一起 过程定义了方法使用的顺序 可交付产品的要求 帮助确保质量和变更的控制 使软件管理人员能对它们进行评价 管理者在软件工程过程中对软件开发的质量 进度 成本进行评估 管理和控制 48 软件工程 一种层次化技术 软件工程的方法软件工程方法是完成软件工程项目的技术手段 它支持项目计划和估算 系统和软件需求分析 设计 编程 测试和维护 软件工程方法依赖一组原则 它贯穿软件工程的各个环节 软件工程方法分两类 传统方法和面向对象方法 49 软件工程 一种层次化技术 软件工程的工具它为软件工程的过程和方法提供自动化或半自动化的工具支持 将若干工具集成起来 与软件工程数据库和计算机系统构成一个支持软件开发的系统称 计算机辅助软件工程 CASE 系统中某一工具的信息加工结果可以作为另一工具的输入 集成的软件工程工具再加上人的因素构成了软件工程环境 50 软件生命周期 软件从定义到开发 运行维护 直到废弃的过程称为软件的生命周期 生命周期的划分 计划时期 开发时期 运行时期 51 问题定义 可行性研究 需求分析 概要设计 详细设计 编码 测试 运行 计划时期 开发时期 运行时期 52 软件过程 软件开发模型 注意每种模型的特点 瀑布模型快速原型增量模型螺旋模型其它一些模型 53 软件开发模型 瀑布模型 问题定义 可行性研究 需求分析 概要设计 详细设计 编码 测试 运行 计划时期 开发时期 运行时期 54 概要设计 详细设计 编码 测试 测试 编码 设计 评价 计划 分析 运行 瀑布模型 55 原型法 先建立一个能够反应用户需求的原型 通过原型和用户交流 不断改进原型 直到系统完全符合用户要求为止 最终建立系统 特点 强调 快 56 原型法 需求分析 原型开发与建模 原型评价 系统设计 系统实现 57 融合了线性顺序模型的基本成分和原型实现的迭代特征 增量模型以小的但可用的片断来交付软件 当使用增量模型时 第一个增量往往是核心的产品 增量模型 58 增量模型的优点 人员分配灵活 刚开始不用投入大量人力资源 当核心产品很受欢迎时 可增加人力实现下一个增量 当配备的人员不能在设定的期限内完成产品时 它提供了一种先推出核心产品的途径 这样就可以先发布部分功能给客户 对客户起到镇静剂的作用 具有一定的市场 增量模型 59 螺旋型 螺旋模型是B Boehm于1988年提出的 它是线性顺序模型与原型模型的结合 不仅体现了两个模型的优点 还增加了新的成分 风险分析 在螺旋模型中 软件开发是一系列的增量发布 在早期的迭代中 发布的增量可能是一个纸上的模型或原型 在以后的迭代中 被开发系统的更加完善的版本逐步产生 由制订计划 风险分析 工程实现 评审四个阶段组成 60 螺旋型 评审约定线 累计成本 各步骤进度 风险分析 原型1 原型2 原型3 可运行的模型 风险分析 风险分析 风险分析 初步软件需求 有效软件需求 需求计划 开发计划 集成测试计划 客户评估 制订计划 确定目标选择方案设定约束 风险分析 评价方案明确风险排除风险 实施工程 软件产品设计 设计确认 验证 详细设计 编码与单元测试 集成测试 系统测试 实现 61 螺旋模型的优点符合人们认识现实世界和软件开发的客观规律 支持软件整个生命周期 保持瀑布模型的系统性 阶段性 利用原型评估降低开发风险 开发者和用户共同参与软件开发 尽早发现软件中的错误 不断推出和完善软件版本 有助于需求变化 获取用户需求 加强对需求的理解 螺旋型 62 螺旋模型的缺点需要相当的风险分析评估的专门技术 且成功依赖于这种技术 很明显一个大的没有被发现的风险问题 将会导致问题的发生 可能导致演化的方法失去控制 这种模型相对比较新 应用不广泛 其功效需要进一步的验证 螺旋模型案例 螺旋型 63 面向对象开发模型 面向对象分析OOA 面向对象设计OOD 面向对象实现OOP 面向对象测试OOT OO分析 识别问题域的对象分析关系 建立模型 OO设计 将分析结果转换成逻辑的系统实现 OO实现 把设计的结果翻译成具体的某种程序 64 软件工程 一门实践的科学 出发点和最终目的是指导实践从时间上 实践是发展的 基于实践的软件工程学科也必然是发展的 RogerS Pressman说 软件工程将发生变化 对此我们可以肯定 从内容上 软件实践的差异是巨大的 我们不能生搬硬套 正如AlistairCockburn所说 不同的项目需要不同的方法 软件过程 合适的才是最好的 65 几种开发模型的比较 几种开发模型各有特点 没有绝对的优劣 有各自适用的情况应该根据实际情况选择 模型在使用时候完全可以融合几种方法 达到最好的效果 开发模型在实践中不断地成熟 更新 均具有一系列共同的一般阶段 使得我们能够实现在本书的其余部分将要一一探讨的过程的原则 概念和方法 66 讨论1 假设你被指派为一个小型软件产品公司的项目经理 你

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论