软件工程0-1.软件工程介绍.ppt

软件工程 第1章软件工程介绍 1 1软件与软件的复杂度 什么是软件 站在软件工程的角度看 软件就是 一个或多个计算机程序 其执行时能提供所期望的功能和性能一个或多个数据结构 这些结构使得程序能够完全操纵信息一个或多个文档 这些文档描述了程序分析 设计 实现和维护的细节软件的定义 面向过程的程序 算法 数据结构面向对象的程序 对象 消息面向构件的程序 构件 构架 50年代 软件 程序60年代 软件 程序 文档 分析 设计 测试 维护 但不包括管理文档 70年代 软件 程序 文档 数据 初始化数据 测试数据 研发数据 运行数据 维护数据 工程数据 项目管理数据等 1984年美国开始认识到软件管理是一个过程管理 1991年出现CMM1 0 96年出现UML 软件工作产品 开发过程中产生的各种软件 软件产品 最后交付的软件 1 1软件与软件的复杂度 IEEEStandardGlossaryofSoftwareEngineeringTerminology给出了有关软件的定义 软件是计算机程序 规程以及运行计算机系统可能需要的相关文档和数据 计算机程序是计算机设备可以接受的一系列指令和说明 为计算机执行提供所需的功能和性能 数据是事实 概念或指令的结构化表示 能够被计算机设备接收 理解或处理 文档是描述程序研制过程 方法及使用的图文材料 1 1软件与软件的复杂度 IEEEStandardGlossaryofSoftwareEngineeringTerminology给出了有关软件的定义 英文版 Software Computerprograms procedures andpossiblyassociateddocumentationanddataperainingtotheoperationofacomputersystem 1 1软件与软件的复杂度 软件的分类 1 按功能分 系统软件 支撑软件 应用软件 2 按规模分 大型 中型 小型 3 按工作方式分 实时 分时 交互 批处理 4 按服务对象分 定制软件 产品软件 或称为通用软件 5 按销售方式分 定单软件 非定单软件 1 1软件与软件的复杂度 软件的特征软件是设计开发的 而不是传统意义上生产制造的软件不会磨损大多数软件仍然是定制的 而不是通过已有构件组装而成 虽然软件业内向着基于构件的构造模式发展从对比的角度理解这三点 软件是开发出来的 不是制造出来的软件可能被 废弃 但不会 用坏 软件大部分是定制的 而不是装配的 1 1软件与软件的复杂度 软件的特征抽象性 逻辑实体 可记录 但看不到可复制性 与开发成本相比 复制成本很低 1 1软件与软件的复杂度 软件的复杂度 计算机软件发展的四个阶段 1 早期时代 60年代中期之前 程序设计阶段硬件通用 软件专用 程序规模小 编写者和使用者为同一人 同组人 计算机的主要应用为快速计算 出现了Algol Fortran等编程语言 2 第二代 60年代中期 70年代中期 程序系统阶段出现 软件作坊 产品软件 个体化 开发方法 计算机的应用开始涉及到各种以非数值计算的商业业务领域 交互技术 数据库 操作系统等得到发展 出现了Pascal Cobol等编程语言和关系数据库管理系统为标志的结构化软件技术 瀑布模型得到普遍使用 3 第三代 70年代中期之后 80年代 软件工程阶段软件开发成为一门新兴的工程学科 软件工程 软件开发过程得到管理 工程化了 出现了COCOMO模型 CMM等 以Smalltalk C 为代表的面向对象技术崛起 传统的结构化技术受到严峻的考验 1 1软件与软件的复杂度 计算机软件发展的四个阶段 4 20世纪90年代 至今Internet技术的迅速发展使软件系统从封闭走向开放 异构环境下的分布式软件的开发成为一种主流需求 软件复用和构件技术成为技术热点 出现了J2EE COM CORBA为代表的3个分支 现在网格计算 WebService 云计算 普适计算 PervasiveComputing 等技术发展迅速 1 1软件与软件的复杂度 1 1软件与软件的复杂度 1 1软件与软件的复杂度 中国软件产业大事记1984年 中国软件行业协会成立 当时的电子工业部部长江泽民任名誉会长 杨天行任理事长 1985年 成立中国软件技术公司 中软总公司的前身 长城0520c微型机汉字处理软件HM和汉字排序软件SM向国外出口 1986年 电子工业部向国务院报送了 关于建立和发展我国软件产业的报告 1988年第一次全国软件会议召开 金山公司 用友公司成立 1989年 北大华光激光照排系统获中国发明专利金奖 1990年 原中国计算机软件技术公司与中国计算机服务公司合并 成立中国计算机软件与技术服务总公司 开始研发自主知识产权操作系统 1991年 中华人民共和国著作权法 正式实施 计算机软件保护条例 颁布 1992年 计算机软件著作权登记办法 颁布与实施 1994年 金山 巨人 王码480等20多种流行的字处理软件进入各类办公系统中 中国软件产业大事记1996年 希望公司UCDOS占有当时72 的中文平台市场 东软公司上市 1997年 第一届中国软件博览会召开1998年 Linux进入中国 国产财务软件占有65 的国内市场份额 2000年 国务院颁布 鼓励软件和集成电路产业发展的若干政策 的第18号文件 双软认证启动 2001年 信息产业部与原国家计委命名11个城市的软件园为 国家软件产业基地 金蝶 用友上市 2002年 国务院下发 振兴软件产业行动纲要 的47号文件 以作为对18号文精神的延续和细化 全国35所高校的示范性软件学院开始招生 2003年 国内软件行业共完成销售收入1633亿元 同比增长48 5 1 2软件与软件危机防不胜防的软件错误 例 例1 1963年 美国 飞往火星的火箭爆炸 损失 10million 原因 FORTRAN循环DO5I 1 3误写为DO5I 1 3 例3 1996年 ESA的火箭处女航失败 升空后仅飞行40秒就偏离了其预定轨道 该火箭被远程控制所毁并失去她携带的4个卫星 损失达5亿美元原因 惯性参考系方面的问题未经讨论和解决 例2 1996年 美国 飞往哥伦比亚城市Cali的客机失事 163人中仅4人生还原因 关于目的地坐标的 由一个字符构成的计算机命令的错误输入 两相距132英里的城市坐标在南美航空表中代码相同 1 2软件与软件危机防不胜防的软件错误 例5 1994年 英特尔奔腾浮点除法软件缺陷 导致为自己的行为道歉并花费4亿多美元更换坏芯片 原因 芯片发布前已发现问题 但管理层忽略了 软件缺陷被发现时 英特尔试图掩饰该问题的严重性 受到压力时 英特尔承诺更换芯片但要求用户证明自己受到软件缺陷的影响 4195835 3145727 3145727 4195835 0 例 例4 1994 1995年 迪斯尼的狮子王 第一个面向儿童的多媒体光盘游戏 投诉电话被打爆 原因 未对市场上的各种PC机型进行正确测试 软件在大众使用的常见系统中难以运行 1 2软件与软件危机防不胜防的软件错误 例7 1991年 美国爱国者导弹防御系统在几次对抗导弹战役中失利 多哈战误击毙28名美军士兵 原因 一个很小的系统时钟错误积累 可能拖延14小时并造成跟踪系统失去准确度 多哈战中系统拖延了100多个小时 例6 1999年 美国航天局火星基地登陆飞船在试图登陆火星表面时失踪 原因 为省钱而简化确定何时关闭推进器的装置 导致飞船着陆时误更改一个数据位 两个测试小组的独立工作做的很好 但从未走在一起 例 防不胜防的软件错误 软件开发成本 Cost Testing Requirements DesignandImplementation 1 2软件与软件危机 60年代 软件史前 的软件危机 1 对软件开发的进度和成本无法估计 2 用户对已经开发完成的软件的满意度非常低 3 软件质量无法保证 4 软件开发后的维护工作很难进行 5 软件通常没有合适的文档资料 6 软件成本在系统总成本中所占的比例越来越高 7 软件开发的生产率跟不上需求1962年美国水手 号因导航软件一个语句的语义错误 导致偏离航线 任务失败 阿波罗8号因计算机软件错误 造成存储器信息丢失 阿波罗14号在飞行的10天中 出现了18个软件错误 美国IBM公司的OS 360系统 花了几千人很多年的努力而失败 所以 在20世纪60年代 就开始提出所谓 软件危机 的概念软件危机 软件的可靠性没有保障 维护费用不断上升 进度无法预测 成本增长无法控制 程序员无限度增加等 形成软件开发局面失控的状态而另一方面 根据摩尔定律 硬件成本每隔18个月就降低一半 例如 存储器每年降低40 主机硬件的性价比每十年提高一个数量级软件人从60年代开始 就面临巨大的生存压力 而其中最具典型的是美国人佛雷德里克 布鲁克斯 FrederickP BrooksJR 和他的 人月神化 1 2软件与软件危机 软件危机的现实意义 为什么要担心软件危机 软件作为一个产业 什么时候可以开始赢利 与其他产品的历史发展不同 软件开发的历史 具有最典型的社会历史发展的特性 1 与建筑技术 制造技术 计算机硬件技术不同 2 虽然在工具 技术手段上 可以同步进步 3 方法 管理水平 不会自动进步手工作坊依然普遍存在 原因是什么 什么是手工作坊 1 个人对所负责的 局部 负责 在这个局部是完全个性化和自由的 系统就是由几个这样的 局部 构成的 2 没有任何设计文档和可用于维护的资料 3 没有评审和独立的系统测试 4 进度 成本 质量是不可预测的 1 2软件与软件危机 人月神话 TheMythicalMan Month 一本畅销20年经久不衰 具有深远影响的书 作者美国IBM公司 被认为是IBMSystem 360和OS 360之父 曾担任360系统项目经理的FrederickP Brooks博士 1975年 Brooks就在他的 没有神话 软件工程的根本和次要问题 NoSilverBullet EssenceandAccidentsofSoftwareEnginerring 中预言 在10年内 没有任何编程技巧能够给软件的生产率带来数量级上的提高 10年后 1986年 Brooks博士再次发表了 没有银弹 的经典文章 表明 情况没有什么根本的进展 而在1996年 既 人月神化 发表20年后 Brooks对20年前的推断 又提出了新的认识 我们简单地介绍一下 人月神化 和 没有银弹 1 2软件与软件危机 在 人月神话 的第一章 Brooks描绘了一幅可怕的图景 在史前史中 没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼 上帝见证着恐龙 猛犸象 剑齿虎在焦油中挣扎 它们挣扎得越是猛烈 焦油纠缠得越紧 没有任何猛兽足够强壮或具有足够的技巧 能够挣脱束缚 它们最后都沉到了坑底 Brooks认为 在过去几十年的大型系统开发就犹如这样一个焦油坑 很多大型和强壮的动物在其中剧烈地挣扎 他们中大多数开发出了可运行的系统 不过 其中只有非常少数的项目满足了目标 时间进度和预算的要求 各种团队 大型的和小型的 庞杂的和精干的 一个接一个淹没在了焦油坑中 表面上看起来好像没有任何一个单独的问题会导致困难 每个都能被解决 但是当它们相互纠缠和累积在一起的时候 团队的行动就会变得越来越慢 对问题的麻烦程度 每个人似乎都会感到惊讶 并且很难看清问题的本质 不过 如果我们想解决问题 就必须试图先去理解它 面对焦油坑 很多常用的办法就是人海战术 在 人月神话 的第2章里 Brooks提出了著名的人月神话法则 向进度落后的项目中增加人手 只会使进度更加落后 Brooks的著名观点 人月神话是不存在的 这就是人月神化的出处 反过来 软件开始是精英们的游戏 年轻的软件经理特别喜欢由头等人才组成的小型 精干的队伍 而不是那些几百人的大型团队 这里的 人 当然暗指平庸的程序员 Brooks认为 寻求精英团队的想法是幼稚的 与其回避困难 还不如现实地来讨论 如何在有意义的时间进度内创建大型的系统 Brooks借助法国城市兰斯 Reims 在建筑风格上的一致性的例子 说明 风格的一致和完整性来自8代拥有自我约束和牺牲精神的建筑师们 他们每一个人牺牲了自己的一些创意 以获得纯粹的设计 同样 这不仅显示了上帝的荣耀 同时也体现了他拯救那些沉醉在自我骄傲中的人们的力量 1 2软件与软件危机 同样 在系统刚刚开始设计时 结构师倾向于精炼和简洁 他知道自己对正在进行的任务不够了解 所以他会谨慎仔细地工作 在设计第一个项目时 他会面对不断产生的装饰和润色功能 这些功能都被搁置在一边 作为 下一个 项目的内容 第一个项目迟早会结束 而此时的结构师 对这类系统充满了十足的信心 熟练掌握了相应的知识 并且时刻准备开发第二个系统 第二个系统是设计师们所设计的最危险的系统 设计师就像后继的建筑师那样 如果不把前人的思想放在眼里 那么 他们将盖出 五花八门 的新教堂 假设一个项目经理已经拥有行事规范的结构师和许多编程实现人员 那么他如何确保每个人听从 理解并实现结构师的决策 对于一个由1000人开发的系统 一个10个结构师的小组如何保持系统概念上的完整性 在System 360硬件设计工作中 Brooks摸索出来一套实现上述目标的方法 它们对于软件项目同样适用 1 2软件与软件危机 那么 既然他们具备了所有的这些条件 为什么项目还会失败呢 他们还缺乏些什么 两个方面 交流 以及交流的结果 组织 他们无法相互交谈 从而无法合作 当合作无法进行时 工作陷入了停顿 通过史书的字里行间 我们推测交流的缺乏导致了争辩 沮丧和群体猜忌 很快 部落开始分裂 大家选择了孤立 而不是互相争吵 当一线经理发现自己的队伍出现了计划偏离时 他肯定不会马上赶到老板那里去汇报这个令人沮丧的消息 团队可以弥补进度偏差 他可以想出应对方法或者重新安排进度以解决问题 为什么要去麻烦老板呢 从这个角度来看 好像还不错 解决这类问题的确是一线经理的职责 老板已经有很多需要处理的真正的烦心事了 他不想被更多的问题打搅 因此 所有的污垢都被隐藏在地毯之下 以上的描述 是Brooks1975年在 人月神话 中做出的 1 2软件与软件危机 1986年 Brooks写了 没有银弹 软件工程中的根本问题和次要问题 一文 声称 在十年内 没有任何单独的软件工程进展 可以是软件生产率有数量级的提高 文章说 在所有民间恐怖传说的妖怪中 最可怕的是人狼 因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物 为了对付人狼 我们在寻找可以消灭它们的银弹 这就是银弹比喻的来源 大家熟悉的软件项目具有一些人狼的特性 至少在非技术经理看来 常常看似简单明了的东西 却有可能变成一个落后进度 超出预算 存在大量缺陷的怪物 因此 我们听到了近乎绝望的寻求银弹的呼唤 寻求一种可以使软件成本像计算机硬件成本一样降低的尚方宝剑 但是 我们看看近十年来的情况 没有银弹的踪迹 没有任何技术或管理上的进展 能够独立地许诺在生产率 可靠性或简洁性上取得数量级的提高 1 2软件与软件危机 在这本书的第十六章 也就是Brooks著名的文章 没有银弹 软件工程中的根本问题和次要问题 中 Brooks分析了各种可能成为银弹的技术 试图通过分析软件问题的本质和很多候选银弹的特征 来探索其为什么没有能够成为银弹的原因 我们花一点时间来看以下Brooks的分析 首先 Brooks对软件活动进行了一个根本性的假设 软件任务由根本性的任务 打造构成抽象软件实体的复杂概念结构 次要任务 使用编程语言表达这些抽象实体 在空间和时间限制内将它们映射成机器语言组成的 Brooks首先认为 次要任务对软件工程师而言 已经不是什么问题 解决它们所用的时间 应不到软件工程师工作任务的1 10 但当时的技术发展 主要在这些次要任务上 例如 硬件条件限制的打破 编译工具的提高 机器时间的突破等 但这些技术再提高 也不会给软件生产率带来数量级上的提高 因为他们占的比重太低 那么 对于根本性任务方面 没有银弹可以在软件开发和管理的生产率 可靠性 简洁性方面获得数量级上的提高 原因是什么 Brooks认为 软件开发不能像硬件那样获得生产率 可靠性 简洁程度的大幅提高 根本原因是因为软件开发的根本问题产生的 这是软件特性中的固有的困难 软件开发困难的部分是规格说明 设计和测试 以及数据结构 数据关系 算法 功能调用等要素之间的抽象的概念构造 这些困难体现在以下四个方面 复杂性 软件中没有任何部分是相同的 如果相同 我们就可以把它合并成可调用的子程序 软件的扩展是不同元素实体的扩展 不是相同元素的迭加 这使软件与建筑 汽车制造大不相同 后者有大量的重复部分 对复杂实体进行抽象提取 如数学和物理中 建立简单抽象模型 再反过来验证这些特性的研究方法 不适合软件 由于复杂性 导致了沟通的困难 产品瑕疵 成本超支 进度延误 测试不完全 共用困难 负作用的产生 等等 复杂性还导致管理的困难 学习和理解的困难等 1 2软件与软件危机 一致性 在物理学领域 面对复杂的统一场理论 爱因斯坦坚信 自然界一定存在简化的解释 因为上帝不是专横武断和变化无常的 但是 面对软件系统 软件工程师的复杂性是随心所欲 毫无规则的 是随接口的不同 时间的变化而改变的 这些变化无法事先规定 且是因人而异的 软件的复杂性是人设计的结果 而不是上帝 可变性 持续的变更压力 汽车也会变更 但汽车的变更只会整合到后续的产品中 没有什么现场调试 软件则不同 最主要的原因是它太容易被修改了 它是人类思维活动的产物 可以无限地扩展 修改的成本又很低 不可见性 软件是不可见的 与其他工业产品相比 建筑 机械 化学 生物等等 都有图纸 方程式等等 获得可视化的了解 软件的客观存在不具有空间的形体特征 没有它的几何表达方式 我们虽然有流程图 数据结构图 依赖关系 时间序列 名字的对应关系等 但这些都仅仅是为了建立一个概念 而把复杂的关系分割成一个抽象的层面或图形上 内部的不可见 限制了设计和使用者之间 设计者之间的交流和理解 在1986年的时候 Brooks认为次要问题已经取得了一些突破 主要包括 高级语言 减轻了一些次要问题的软件复杂度 特别是对某些问题要素 如 数据结构 数据类型和操作等 的抽象 使程序人员可不必过多地关注具体实现 而把注意力转向用户需求 但是 这些复杂的语言可能更增加程序员的脑力劳动负担 分时 分时保证了开发的及时性 减少开发在时间上的代价 但这只是一个次要困难 统一编程环境 提供集成库 统一文件格式 管道 过滤器等 解决了共同使用程序的次要困难 1 2软件与软件危机 但是 在根本问题方面 作为备选 银弹 情况任何呢 Ada和其他高级语言 通过更加抽象的语句来开发 降低了机器的次要复杂程度 面向对象编程 当时 有基于Ada包和Modula模块的类概念 Brooks对Ada寄予了很大的希望 面向对象的抽象主要包括对数据类型和对层次化类型的二种抽象 前者的主要表现是数据结构 定义和操作的隐蔽 后者是通过继承 实现对特定过程的精细化 二者都有利于设计人员集中精力于设计的内在特性而不需要表达大量句法上的内容 但这只能解决设计表达上的复杂性 次要问题 这类问题 只占软件产品设计的很小部分 因而不能解决软件内在的复杂性 根本问题 面向对象编程 能否成为 银弹 Brooks表示怀疑 这个问题在10年后 Brooks还会再次谈到 其他方面 还包括 人工智能 专家系统 自动编程 图形化编程 程序验证 开发环境与工具 工作站等 Brooks当时认为 有希望的方法还有 商品化 而不是完全自行开发 的软件工程方法 需求精炼和快速原型方法 增量开发 以及培养卓越的设计人员等 结论是 这些技术分别对软件工程都有帮助 但它们单独或结合应用 也不能成为 银弹 10年后 96年 的再认识Brooks说 我在 没有银弹 中声称和断定 在近十年内 没有任何单独的软件工程进展可以使软件生产率有数量级的提高 引自1986年的版本 现在已经是第九个年头 因此也该看看是否这些预言得到了应验 人月神话 一文被大量地引用 很少存在异议 相比之下 没有银弹 却引发了众多的辩论 编辑收到了很多文章和信件 至今还在延续 他们中的大多数攻击其核心论点和我的观点 没有神话般的解决方案 以及将来也不会有 他们大都同意 没有银弹 一文中的多数观点 但接着断定实际存在着杀死软件怪兽的银弹 由他们所发明的银弹 1 2软件与软件危机 10年后 1996年 的再认识现实问题 整个软件开发工作中的哪些部分与概念性结构的精确和有序表达相关 次要问题 哪些部分是创造那些结构的思维活动 根本问题 在我看来 开发的次要问题 已经下降到整个工作的一半或一半以下 次要问题占整个开发工作的比例 已经很小 因此 在次要问题上的进步 并没有给软件的生产率 带来数量级的提高 所以 还是必须着手解决开发的根本性问题 针对复杂性问题软件系统要表达的外部世界的复杂性 如何通过软件开发过程 来进行有效的应对 例如 需求工程 层次化方法 增量开发的方法等 Brooks本人没有做这方面的研究 但他认为 这些方法 可能是有效的 1 2软件与软件危机 针对不可见性问题 可视化建模技术 确实是针对软件的根本性困难 既概念性要素的设计和调试 Brooks认为 这种方法 可能是 革命性 的 在实际应用中 也确实是一种有效的方法 关注软件的生产率 更关注软件的质量 关注质量 生产率就自然会提高采用工程化方法开发软件的目标 是提高软件产品的质量 可测试性 稳定性以及可预见性 而不是软件产品的开发效率 在软件生产上应用工程