软件危机与软件工程课件(PPT 58页).ppt

软件危机与软件工程 软件危机 0美元支票一位主管收到了一张由计算机开出的0美元的账单 在嘲笑了 愚蠢的计算机 后他将账单丢进了垃圾桶 一个月后 又一张账单寄来了 还标志着30天的逾期 这样的情形持续了4个月 最后还带来了一封信 警告如果再不付账的话 将会采取法律行动 由于担心自己的信用度 这个主管在一个软件工程师的建议下 寄出了一张0美元的支票 最后一张0美元的收据送到了 该主管小心翼翼地将这张不同寻常的收据保存起来以备将来查询 软件危机 续 有错误的爱国者导弹1991年海湾战争中 一枚飞毛腿导弹穿过了爱国者反导弹的防御 击中了沙特阿拉伯的Dhahran附件的一个兵营 造成28名美国人死亡 98人受伤 这个错误是由累积的定时错误引起的 爱国者导弹每次只能工作几小时 超过这个时间后 系统时钟就会复位 可悲的是新的软件第二天才运到 软件危机 续 美国国内税收处20世纪年代让Sperry公司建立一套联邦税收表格自动处理系统 该系统被证明不适合当前的工作量 花费几乎是预算的2倍 到1996年 共花费了40亿美元 但情况并没改善 原因是 没有充分计划就错误行事 软件危机的表现 超出预算时间和成本研究表明 每8个新的大型软件中就有2个会被取消 软件开发时间平均超出计划的50 而软件开发中的主要成本是人力资源成本 进度的落后意味着成本的增加用户对生产出的软件不满意开发人员往往不注重或不善于和客户交流 找出客户真正需要的东西 匆忙地进行开发 在开地过程中又不能从客户那里得到反馈信息 最后生产出的软件和客户想要的相差很远 难免出现纠纷 软件危机的表现 续 软件有残存的错误研究表明 所有的大型系统中 大约有3 4的系统有运行问题 要么不是像预料的工作 就是根本不能使用软件产品不可维护不能改正错误在原有模块上不能增加新的功能不能增加新的模块 软件危机的表现 续 文档资料不完整软件文档是交流平台 管理工具 必须和软件同步更新软件生产率的提高跟不上硬件的发展速度摩尔定律 每隔18个月计算机硬件的运算速度提高一倍 价格下降一半软件 手工开发为主 软件危机的表现 续 软件成本在计算机系统总成本中的比例不断提高而软件维护的成本占软件的成本也越来越高 引起软件危机的原因 软件开发无计划性没有经过仔细考虑就匆忙开发 出现问题才想办法补救 不能保证软件开发进度和预算 不能保证软件质量 在进度落后时 盲目增加人手 结果适得其反 引起软件危机的原因 续 软件需求不充分没有将问题搞清楚就匆忙上马 在开发过程中又不能和客户有效地沟通 许多问题在交付软件时才集中地爆发出来 这时候已经是大势已去 难以挽回了 和数值计算软件和平时学习语言编写的程序不同 在实际的软件开发中 首先应该满足的是客户的需要 开发软件不是为了展示个人的技巧 引起软件危机的原因 续 软件开发过程无规范开发过程没有统一的方法和规范不重视文档各开发人员之间的接口没有统一规划 引起软件危机的原因 续 软件产品无评测手段个人提交产品时没有进行测试模块之间接口没有测试整个系统没有进行整体测试忽略压力及性能测试 软件危机解决之道 软件工程 1968年北大西洋公约组织的计算机科学家在联邦德国召开的国际学术会议上第一次提出了 软件危机 softwarecrisis 这个名词 1968年秋季 北约的科技委员会召集了近50名一流的编程人员 计算机科学家和工业界巨头 讨论和制定摆脱 软件危机 的对策 在那次会议上第一次提出了软件工程 softwareengineering 这个概念用工程化的理念 方法进行软件开发 软件工程的定义 软件工程 IEE93 将系统的 规范的 可度量的方法应用于软件的开发 运行和维护的过程 上述方法的研究 软件工程基本原理 B W Boehm提出7条原理 互相独立 最小集合其他软件工程原理在此基础上组合 蕴含 派生 软件工程基本原理 1 用分阶段的生命周期计划严格管理不成功的软件中有一半左右是由于计划不同造成的应该将软件生命周期划分成若干个阶段 并相应制定出切实可行的计划 并按计划对软件的开发和维护进行管理六类计划 项目概要计划 里程碑计划 项目控制计划 产品控制计划 验证计划 运行维护计划 软件工程基本原理 2 坚持进行阶段评审统计表明 大部分错误是在编码之前造成的错误发现与改正越晚 所需付出的代价也越高 见下页 坚持阶段评审 可以避免错误的 水波效应 各阶段改正错误的相对花费 软件工程基本原理 3 实行严格的产品控制尽量避免修改需求修改需求必须在严格的管理下进行 配置管理 软件工程基本原理 4 采用现代程序设计技术结构化程序设计技术 自顶向下 逐步求精面向对象设计技术 思想而非仅为技术 软件工程基本原理 5 结果应能清楚地审查度量是管理的基础形成自己的管理数据资料库 尽量精确地对系统进行计划 测量 修正 软件工程基本原理 6 开发小组人员应少而精IBM的纽约时报项目 1971 22个月内写了83000行程序 在1年的运行过程中只找出了25个错误 主要的程序员平均每年编写1个错误和10000行代码成功原因 该项目是IBM的样本项目每个程序员都是尖子中的尖子技术支持极为强大 编译器作者随叫随到项目领导F TerryBaker是一个极好的管理者和领导者 天才程序员 软件工程基本原理 6 续 一个好的程序员的效率是普通程序员的4 5倍开发小组人员增多 由于交流讨论问题所造成的通信开销急剧增加 特别是程序员使用其他程序员所开发的模块 软件工程基本原理 7 不断改进软件工程实践发展和采用新技术收集相关数据 软件生产中的问题 本质的和偶发的 硬件限制光传播速度制造工艺 电子能通过的最窄的宽度为3个原子的直径软件 没有银弹 软件开发中的困难 困难 本质的 固有的 和偶发的 非固有的 软件的本质困难 每一种的原因及后果 复杂性一致性可变性不可见性 软件开发中的困难 复杂性 1 原因 1 如果程序占N个字 则可能的状态有216 N种 非线性增长产品的不同块之间是要相互影响 如全局变量 软件开发中的困难 复杂性 2 后果 软件产品很难理解 开发小组成员间不能进行良好的沟通 造成开发超时和超支 并且造成说明文档中出现的错误 影响对软件过程的管理维护过程变得很复杂 除非维护人员对产品真正理解 软件开发中的困难 复杂性 3 对策 结构化方法 自顶向下 逐步求精面向对象方法 封装 消息驱动 继承 复用能够减少复杂性 从而提高可维护性 但并不能将软件复杂性完全消除 软件开发中的困难 一致性 1 设计软件时与现有系统的接口一致性在设计新系统时 软件设计师与其它设备的设计师之间的一致性 软件开发中的困难 一致性 2 原因 普遍存在的误解 软件是系统中一种最容易与别的设备进行接口的成分后果 软件获得了一种不必要的复杂性 而这种复杂性不是由软件自身的结构引起的 软件开发中的困难 可变性 1 软件需要改变的原因 1 软件是现实世界的模拟 软件要随着现实世界的改变而改变用户对软件功能的扩展要求 超越原来的设计软件改变的最有吸引力的地方是软件比硬件更容易改变成功的软件能够超越支持其运行的硬件的生存期 在更换硬件后继续使用 软件开发中的困难 可变性 2 后果 从长远来看 对产品进行大面积的维护是不明智的 从头开始对软件重新编码有进成本更低 但人们对软件本质的忽视而常常要求对软件进行在的改动 软件开发中的困难 不可见性 1 原因 难以将代码与实际的软件对应起来 目前不存在一种普遍接受的方法来对一个完整的软件产品进行描述 或者对产品做出某种概述 现有的各种说明工具 如UML 数据流图 程序结构图 极少有平面的 更别说是分层的 图表中有太多的交叉 难以一下子给出软件的全貌 软件开发中的困难 不可见性 2 后果 1 没有一种图表能将软件的各个方面都体现出来 并且也没有一种方法能够确定在使用一种形象化描述方法对产品进行描述时 我们遗漏了哪些2 不能对软件进行形象化描述不仅使软件难于理解 而且极大地阻碍了软件专家之间的沟通 没有银弹 1 对于软件的本质问题 我们无法解决 无法找到一种在生产上快速取得大数量级提高的方法 即银弹 没有银弹 2 对于软件的偶发问题是可以解决的Brooks认为生产软件的最困难的部分在需求阶段 规格说明和设计阶段 而不是实现阶段 建议我们改变软件的生产方式 在任何可能的情况下购买已经开发好的软件 而不是定制开发使用快速原型和增量式建造技术培养伟大的设计者 改进软件过程 1 软件开发的根本问题在于人们不能对软件过程进行管理 美国国防部在位于匹兹堡的卡耐基 梅隆大学成立了软件工程研究所 softwareengineeringInstitute SEI SEI的一个最主要的成功是建立了能力成熟度模型 CapabilityMaturityModel CMM 国际标准化组织 ISO 也制定了相应的ISO 9000系列标准 ISO IEC15504等 改进软件过程 2 能力成熟度模型CMM是一组用于改进软件过程的相关策略 它与实际使用的软件生命周期模型没有关系 成熟度是对软件过程本身的度量 CMM模型包括 1 用于软件的SW CMM2 用于人力资源管理的P CMM3 用于系统工程的SE CMM4 用于集成产品开发的IPD CMM5 用于软件收集的SA CMM为避免不一致和冗余 1997年将前4个模型统一为CMMI 改进软件过程 3 软件过程不仅包括软件生产的各种技术和工具 也包括技术方面和管理方面的内容SW CMM是基于以下观点的 新技术本身并不能导致产量和利润的增加 我们的问题主要出现在软件过程管理上SW CMM模型的策略是改进软件过程的管理 相信技术的提高是一个自然的结果 软件过程做为一个整体所获得的改进将导致较高质量的软件的产生 并且将会有较少项目超时或超支 CMM 软件过程改进不可能在一夜之间实现 SW CMM模型对过程的改变是逐步的 该模型定义了5个成熟度级别 一个软件组织通过每一步的细微演变 将自己的成熟度级别提高到更高一级上 成熟度级别1 初始级 有效的软件过程管理方法在本质上没有获得使用 软件开发成功与否依赖于当前的软件开发人员整个开发过程没有计划 不可预测 软件开发经常超时和超支许多措施都是在软件开发遇到困难进采取的 而不是事先计划好的 在这样的组织里 高技术 只能引起更大的混乱 成熟度级别2 可重复级 使用了基本的软件项目管理措施1 根据从类似产品中获得的经验对新的产品进行计划和管理2 使用了基本的测量技术 包括对花费和工作进度表的仔细跟踪 3 项目中的测量为以后项目时间和费用表的制定提供现实的依据4 通过测量 管理人员能够及时发现问题 并立刻采取措施阻止这些问题演化成大的危机 成熟度级别3 已定义级 软件开发过程的完全文档化1 软件开发过程在所有的管理的技术方面都有明确的定义2 在任何可能的地方不断努力改进软件开发过程3 以评审方式来保证软件质量4 引进CASE技术来进一步提高软件质量的软件生产力 成熟度级别4 已管理级 为每个项目设计了质量目标和生产目标1 在软件开发过程中对这两项指标不断进行测量 当与目标有不可接受的偏离时 则能够纠正措施对其进行纠正2 设立统计质量控制 如每千行代码的错误数 确保管理者能够区别质量和生产标准的随机偏离及有意的违背 成熟度级别5 优化级 持续改进软件过程1 人们用静态质量和过程控制技术对软件组织进行指引 在每个项目中获取的知识在以后的项目中可得到利用2 开发过程形成了一个回馈性的良性循环 从而使软件生产和软件质量获得不断提高 CMM总结 1 软件组织改进自己的软件过程 需要 1 努力对组织当前的软件过程有一个理解2 对想要获得的软件过程进行明确的阐述3 确定为实现过程提高要采取的措施 并确定措施实现的先后顺序4 制定一个实现过程提高的计划并实施该计划 CMM总结 2 CMM总结 KPA 1 关键过程区 KPA 组织在努力实现下一个级别进要努力实现的目标成熟度级别2的KPA 1 配置控制2 软件质量保证3 项目计划4 项目追踪5 需求管理 CMM总结 KPA 2 级别5的KPA1 错误预防2 技术更新3 过程变化管理级别2与级别5的KPA比较级别2 错误发现与纠正级别5 错误预防 CMM提升经验 1 花费时间 从级别1到级别2 3到5年从级别2到级别3 1 5年到3年SEI开发出一系列的调查表 做为评估的基础 评估的目的是指出软件组织当前软件过程中的不足 并且指明软件组织改进其过程应采用的方法 CMM提升经验 2 最初目标 美国国防部生产软件的合同商的软件过程进行评估 到1998年为止 任何想与空军签订合同的软件商必须达到CMM3级以上 软件过程改进的其他努力 1 ISO9000 ISO90011 ISO9000的原则是 与该标准保持一致并不能保证生产出高质量的产品 但这样可以减少生产出质量低劣的产品的可能2 和CMM有部分重叠 但并不完全相同3 不是过程改进 而强调使用文字和图片对整个过程进行记录以确保整个过程的一致性和可理解性 重量在测量方法和节奏4 与欧洲公司签定合同必通过ISO9000认证 越来越多的美国公司也要求该认证 如通用公司 软件过程改进的其他努力 2 ISO IEC155041 软件过程提高能力测定 SPIE 由英国国防部门提出 1997年由国际标准化组织委