第1章 软件工程概述.ppt

1 第1章软件工程概述 2 1 1软件的概念 特点和分类 3 软件的概念 程序 软件与软件产品独唱小合唱 合唱 万人大合唱 简单程序较复杂程序软件软件是计算机系统中与硬件相互依存的另一部分 它包括程序 数据 相关文档的完整集合以及完善的售后服务 软件 程序 数据 文档 服务注 程序并不是软件 程序只是软件的组成部分 4 什么是软件 软件是计算机系统中与硬件相互依存的另一部分 它是包括程序 数据及其相关文档的完整集合程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵信息的数据结构文档是与程序开发 维护和使用有关的图文材料 5 软件的特点 1 软件是一种逻辑实体 而不是具体的物理实体 不占空间2 软件的生产于硬件不同 仿造与盗版3 在软件的运行和使用期间 没有硬件那样的机械磨损 老化问题 6 软件的特点 4 软件的开发和运行常常受到计算机系统的限制 对计算机系统有着不同程度的依赖 5 软件的开发至今尚未完全摆脱手工业的开发方法 6 软件是复杂的 人类能够创造的最复杂的产物是计算机软件 游戏7 软件成本相当昂贵 Vista5年时间 过百亿美元微软2009年的研发经费高达70亿美元 大笔研发经费运用在Windows7操作系统8 相当多的软件工作涉及到社会因素 如ERP软件 自动化软件 7 软件的分类 1 按软件的功能划分 系统软件 支撑软件 应用软件2 按软件规模划分 微型软件 小型软件 中型软件 大型软件 甚大型软件 极大型软件如winXP包含4千万行代码 win7核心开发人员2500名 8 软件的分类 3 按软件工作方式划分 实时处理软件 交互式软件 分时软件 批处理软件4 按软件服务对象的范围划分 项目软件定制软件 产品软件 9 软件的分类 5 按软件使用的频度划分 仅供一次使用的软件 频繁使用的软件6 按软件的失效 可靠性等质量要求高 常与完成重要功能的大系统的处理部件相联 含有可能对以下各项造成影响的程序 10 1 2软件的发展和软件危机 11 软件的发展 一 软件的发展历程第一代 20世纪60年代中期以前 程序设计阶段 第二代 从20世纪60年代中期到70年代中期 程序系统阶段 软件工程 学科诞生 第三代 从20世纪70年代中期到80年代中期 软件工程阶段 第四代 从20世纪80年代中期至今 软件产业在世界经济中已经占有举足轻重的地位 12 13 计算机软件发展的三个时期及特点 14 计算机软件发展的三个时期及特点 15 软件工程的发展的四个重要阶段 1 第一代软件工程 传统的软件工程2 第二代软件工程 对象工程3 第三代软件工程 过程工程4 第四代软件工程 构件工程 60年代末到70年代为了克服 软件危机 Softwarecrisis 提出 软件工程 的名词 将软件开发纳入工程化的轨道 基本形成软件工程的概念 框架 技术和方法 称为传统的软件工程 16 软件工程的发展的四个重要阶段 1 第一代软件工程 传统的软件工程2 第二代软件工程 对象工程3 第三代软件工程 过程工程4 第四代软件工程 构件工程 80年代中到90年代 面向对象的方法与技术得到发展 研究的重点转移到面向对象的分析与设计 演化为一种完整的软件开发方法和系统的技术体系 称为对象工程 17 软件工程的发展的四个重要阶段 1 第一代软件工程 传统的软件工程2 第二代软件工程 对象工程3 第三代软件工程 过程工程4 第四代软件工程 构件工程 80年代中开始 人们在软件开发的实践过程中认识到 提高软件生产率 保证软件质量的关键是 软件过程 是软件开发和维护中的管理和支持能力 逐步形成软件过程工程 18 软件工程的发展的四个重要阶段 1 第一代软件工程 传统的软件工程2 第二代软件工程 对象工程3 第三代软件工程 过程工程4 第四代软件工程 构件工程 90起年代 基于构件 Component 的开发方法取得重要进展 软件系统的开发可通过使用现成的可复用构件组装完成 而无需从头开始构造 以此达到提高效率和质量 降低成本的目的 称为构件工程 19 软件开发方法的模型 随意编程 面向过程 面向对象 面向组件 面向配置组件 面向WebService 20 什么是软件危机 定义 软件危机是计算机软件在它的开发和维护过程中所遇到的一系列严重问题 20世纪60年代末70年代初 西方工业发达国家经历了一场 软件危机 这场软件危机表现在 一方面软件十分复杂 价格昂贵 供需差日益增大 另一方面软件开发时又常常受挫 质量差 指定的进度表和完成日期很少能按时实现 研制过程很难管理 即软件的研制往往失去控制 主要包含两方面的问题 如何开发软件 怎样满足对软件日益增长的需求 如何维护数量不断膨胀的已有软件 21 软件危机 美国IBM公司在1963年至1966年开发的IBM360机的操作系统 这一项目花了5000人一年的工作量 最多时有1000人投入开发工作 写出了近100万行源程序 据统计 这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果 这个项目的负责人F D Brooks事后总结了他在组织开发过程中的沉痛教训时说 正像一只逃亡的野兽落到泥潭中做垂死的挣扎 越是挣扎 陷得越深 最后无法逃脱灭顶的灾难 程序设计工作正像这样一个泥潭 一批批程序员被迫在泥潭中拼命挣扎 谁也没有料到问题竟会陷入这样的困境 IBM360操作系统的历史教训成为软件开发项目的典型事例为人们所记取 22 软件危机的现象 对软件开发成本和进度的估计常常很不准确 用户对 已完成的 软件系统不满意的现象经常发生 软件产品的质量往往靠不住 软件常常是不可维护的 软件通常没有适当的文档资料 计算机软件不仅仅是程序 还应该有一整套文档资料 软件成本在计算机系统总成本中所占的比例逐年上升 软件开发生产率提高的速度 远远跟不上计算机应用迅速普及深入的趋势 23 软件危机的原因 客观 软件本身特点软件的规模庞大 复杂性高 主观 不正确的开发方法 软件开发和维护有许多错误的认识和作法 忽视需求分析软件开发 程序编写轻视软件维护 24 软件危机 项目没有被很好地理解 计划不周 最终导致进度拖延 例在20世纪60年代后期 一位热情的年青工程师受命为一个自动化制造应用项目 编写 计算机程序 选择他的理由非常简单 因为在整个技术小组中他是唯一参加过计算机编程培训的人 这位工程师对汇编语言的IN和OUT指令以及Fortran语言有所了解 但是却根本不懂软件工程 更不要说项目进度安排和跟踪了 他的老板给了他一大堆相关的手册 以及需要做些什么的口头描述 年轻人被告知该项目必须在两个月之内完成 他阅读了这些手册 想好了解决方法 就开始编写代码 两周后 老板将他叫到办公室询问项目进展情况 问题出在哪里 25 软件危机 非常好 工程师以年轻人的热情回答道 这个项目远比我想像的简单 我差不多已经完成了75 的任务 老板笑了 说道 真是太棒了 然后他嘱咐年轻人继续努力工作 准备好一周后再汇报一次工作进度 一周后老板将年轻人叫到办公室 问他说 现在进度如何 一切顺利 年轻人回答说 但是我遇到了一些小麻烦 我会排除这些困难 很快就可以回到正轨上来 你觉得在最后期限之前能否完成 老板问道 没有问题 工程师答道 我差不多已经完成了90 如果读者在软件领域中工作过几年 你一定可以将这个故事写完 毫不奇怪 年轻工程师在整个项目工期内始终停留在90 的进度上 在别人的帮助下 直到交付期限之后一个月才做完 26 软件危机 没有充分的文档资料 documentation 人与人的交流比写程序困难得多 27 软件危机 软件可靠性 reliability 缺少度量的标准 质量无法保证 如何保证软件产品的质量 是非常复杂困难的问题 特别对于规模庞大的软件 软件难以维护 maintainability 不易升级 evolvability 28 软件的神话 管理者的神话 负责软件的管理者像大多数其他管理者一样 都有巨大的压力 要维持预算 保持进度和提高质量 神话 我们已经有了关于建造软件的标准和规程的书籍 难道它们不能给人们提供所有其需要知道的信息吗 事实 不错 关于标准的书籍已经存在 但真正用到了它们吗 软件实践者知道它们存在吗 它们是否反映了现代软件开发的过程 它们完整吗 很多情况下对于这些问题的答案是 否 29 软件的神话 管理者的神话 神话 我们已经有了很多很好的软件开发工具 而且 我们为它们买了最新的计算机 事实 为了使用最新型号的计算机 工作站和PC机去开发高质量的软件 我们已经投入了太多的费用 实际上 计算机辅助软件工程 CASE 工具比起硬件而言 对于获得高质量和高生产率更为重要 但大多数软件开发者并未使用它们 30 软件的神话 管理者的神话 神话 如果我们已落后于计划 可以增加更多的程序员来赶上进度 事实 软件开发并非像制造一样是一个机械过程 用Brooks的话来说 给一个已经延迟的软件项目增加人手只会使其更加延迟 看起来 这句话与人的直觉正好相反 但实际上 增加新人 原来正在工作的开发者必须花时间来培训新人 这样就减少了他们花在项目开发上的时间 人手可以增加 但只能在计划周密 协调良好的情况下 31 软件的神话 用户的神话 需要计算机软件的用户可能就是邻桌 或是另一个技术组 也可能是市场 销售部门 或另一个公司 在许多情况下 用户相信关于软件的神话 因为负责软件的管理者和开发者很少去纠正用户的错误理解 神话导致了用户过高的期望值 并引起对开发者的极端不满 神话 有了对目标的一般描述就足以开始写程序了 我们可以以后补充细节 事实 不完善的系统定义是软件项目失败的主要原因 关于待开发项目的应用领域 功能 性能 接口 设计约束及确认标准的形式化的 详细的描述是必需要的 这些内容只有通过用户和开发者之间的通信交流才能确定 32 软件的神话 用户的神话 神话 项目需求总是在不断变化 但这些变化能够很容易地满足 因为软件是灵活的 事实 软件需求确实是经常变化的 但这些变化产生的影响会随着其引入的时间不同而不同 如果我们很注重早期的系统定义 这时需求变化就可很容易地适应 用户能够复审需求 并提出对修改建议 这时对成本的影响会相对较小 当在软件设计过程中才要求修改时 对成本的影响就会提高的很快 资源已经消耗了 设计框架已经建立了 这时的变化可能会引起大的改动 需要额外的资源和大量的设计修改 如额外的花费 实现阶段 编码和测试阶段 功能 性能 接口及其它方面的改变对成本会产生更大的影响 当软件已投入使用后再要求修改 这时所花费的代价比起较早阶段做同样修改所花的代价可能是几何级数级的增长 33 例子 某公园有一游船码头 负责人请一位软件开发人员实现计算机系统辅助游船管理系统 要求如下 当游客向租船处租船时 向租船处查询是否有可租用的船只 如果租船处有空船 管理员就准备好船只 帮助游客上船 并在联机终端上打入一个信息 S 表示租船周期开始 计算机自动把当时时钟值送入信息域 当游客还船时 管理员打入另一个信息 E 表示租船周期结束 由管理员向游客结算租船时间及费用 一天结束时 管理员要用一些管理信息总结每天工作状况 要求系统打印出租船次数 NNN平均租船时间 MMM显然 这样一个系统的功能包括二个部分 计算输入流的信息 打印输出 34 确定算法 我们知道平均租船时间就是总的时间除以租船次数总的时间 第一条船结束时间 第一条船开始时间 第二条船结束时间 第二条船开始时间 或总的时间 第一条船结束时间 第二条船结束时间 第一条船开始时间 第二条船开始时间 35 编写系统程序 BEGINOPENMESSAGE STREAMNUMBER 0TOTALTIME 0GETMESSAGEDOWHILENOTEND OF STREAMIFCODE STHENNUMBER NUMBER 1TOTAL TIME TOTAL TIME START TIMEELSETOTAL TIME TOTAL TIME END TIMEENDIFPRINT NUMBEROFSESSION NUMBERIFNUMBER0THENPRINT AVERAGESESSIONTIME TOTAL TIME NUMBERENDIFCLOSEMASSAGE STREAMEND 36 系统提出修改 找出一天中最长租用时间 LONGGEST SESSION TIME PPP 要求把每天的报告分成两个 一个是上午情况 另一个是下午情况 通信线路出了毛病 丢掉了一些信息 要求修改系统 从计算报告中删除一切不完整的租船信息 对于上述的修改 除了把原系统废弃之外 实在无法对其作什么修改来满足这一新的要求 而时间及经费都不允许他这么做了 结论 并不是任意设计出来的软件都能够适应在软件寿命期内变化的要求 即软件的灵活性不是绝对的 37 软件的神话 开发者的神话 那些至今仍被软件开发者相信的神话是由几十年的程序设计文化培植起来的 而这种旧的观念和方式是很难改变的 神话 一旦我们写出了程序并使其正常运行 我们的工作就结束了 事实 有人说过 越早开始写程序 就要花越长的时间完成它 大量的数据表明在一个程序上所投入的50 到70 的努力是花在第一次将程序交给用户之后 38 软件的神话 开发者的神话 神话 在程序真正运行之前 没有办法评估其质量 事实 从项目一开始就可以应用的最有效的软件质量保证机制之一是正式的技术复审 软件复审是 质量的过滤器 比起通过测试找到某类软件错误要有效的多 神话 一个成功的项目唯一应该提交的就是运行程序 事实 运行程序仅是仍软件配置的一部分 软件配置包括 程序 文档和数据 文档是成功开发的基础 更重要的是 文档为软件维护提供了指导 39 软件危机解决途径 组织管理工程项目管理方法技术措施软件开发技术与方法软件工具 40 我国软件业的现状 我国软件业的规模目前 我国从事软件开发 研制 销售 维护和服务的软件企业总数大约有20000多家 其中具有自主软件研发能力的软件企业约5700家 已经通过双软认定的有2300余家 从事软件销售 维护和服务的企业5000多家 在这里面 营业规模超过一亿元的软件企业达到100家以上 超过5亿元的达到18家 超过10亿元的达到12家 41 我国软件业的现状 蓝皮书提供的数据显示 2010年 我国实现软件业务收入13364亿元 同比增长31 产业规模比2000年扩大22倍 年均增长率约为36 在全球所占份额由不足5 上升到15 软件业从业人数由不足30万人提高到超过200万人 42 我国软件业的现状 蓝皮书同时指出 尽管中国软件业取得了令人瞩目的成就 但仍然存在着许多问题 首先是中国国产软件和服务仍然不大 不强 虽然中国软件业的市场规模按单个国家计算 欧盟是多个国家 已仅次于美国 但其中包括了外国软件公司在华销售收入与外资软件公司的销售收入 真正的国产软件和服务的销售收入所占比重不大 其次是中国软件业还不能自成体系 重要的基础软件几乎都依赖于进口 在系统集成 软件技术服务等领域 中国企业也往往是从事低端业务 此外 中国软件企业数量虽多 但规模普遍很小 在竞争中明显处于劣势 43 我国软件业的现状 新出炉的软件业务收入前百家企业数据显示 排名前10位的软件企业收入总计不足100亿美元 目前 我国软件产业仍以中小企业为主 软件企业对细分领域的市场开拓还不够 由于研发能力较为薄弱 目前我国软件产业在全球软件产业链中基本处于中下游环节 基础软件的开发能力缺乏技术的积累 企业加大研发投入 推进技术创新的意识有待加强 与此同时 我国软件产业的支撑体系仍有待完善 44 它山之石 印度软件业能够这么迅速地发展起来 除了有政府支持 英语程度 人才储备等原因外 最重要的是从标准化与产品流程入手 重视管理 印度的软件开发管理的特点是流程重于项目 流程管理人员独立于研发部门 专门检查研发部门的开发流程是不是按照既定流程走 如果流程不对 项目肯定就此停止 另外 所谓的项目经理一般都是从编码人员升上来的 至少有四年以上的经验 而公司所有的东西 包括草稿 都有文档 其详细文档要求达到只有这个文档就可以编码的程度 45 我国软件业发展不理想的原因除了政策和盗版外 最大的问题是我国绝大多数软件企业对其软件开发工作过程缺乏有效的管理和控制 多数软件企业开发和生产基本上处于 技术少标准 开发缺规范 生产无检验 质量无保证 的状态 在这方面印度软件业的发展能够给我们以启发 46 它山之石 于是 印度软件公司开发出来的软件整个体系架构非常清晰 而且相当稳定 由于印度企业不是靠一两个软件英雄搞研发 而是靠一大批软件技术人员的分工协作 所以 他们必须注重标准化 注重开发的流程管理 以与国际接口 47 它山之石 目前印度软件公司中有170家公司获得ISO9000质量标准认证 是世界上获得质量认证软件企业最多的国家 在得到卡内基 梅隆大学软件工程学会最高级别的全球23家计算机软件公司中 有15家是印度公司 48 1 3软件工程 49 软件工程的提出 软件工程 一词是1968年北大西洋公约组织 NATO 在联邦德国召开的一次会议上首次提出的 这个会议专门讨论了软件危机问题 它反映了软件人员认识到软件危机的出现及谋求解决这一危机的努力 因此 这次会议被看作是软件发展史上一个重要的里程碑 50 软件工程是指研究软件生产的一门学科 也就是将完善的工程原理应用于经济地生产既可靠又能在实际机器上有效运行的软件 1983年美国 IEEE软件工程标准术语 对软件工程下的定义为 软件工程是开发 运行 维护和修复软件的系统方法 其中 软件 的定义为 计算机程序 方法 规则 相关的文档资料以及在计事机上运行时所必需的数据 软件工程定义 51 工程学 研究自然科学应用在各行业中的应用方式 方法的一门学科 同时也研究工程进行的一般规律 并进行改良研究 52 软件工程定义 采用工程的概念 原理 技术和方法来计划 开发与维护软件 把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来 以较经济的手段获得能在实际机器上运行的可靠软件的一系列方法 简言之 工程方法 管理技术 技术方法注 传统方法学和面向对象方法学是目前使用得最广泛的两种软件工程方法学 53 软件工程原理 著名的软件工程专家B W Boehm提出了软件工程的七条基本原理 这七条原理是确保软件产品质量和开发效率的原理的最小集合 这七条原理是互相独立的 其中任意六条原理的组合都不能代替另一条原理 因此 它们是缺一不可的最小集合 然而这七条原理又是相当完备的 人们虽然不能用数学方法严格证明它们是一个完备的集合 但是 可以证明在此之前已经提出的100多条软件工程原理都可以由这七条原理的任意组合蕴含或派生 54 软件工程原理 用分阶段的生命周期计划严格管理不成功的软件项目中有一半左右是由于计划不周造成的 坚持进行阶段评审软件的质量保证工作不能等到编码阶段结束之后再进行 实行严格的产品控制在软件开发过程中不应随意改变需求 因为改变一项需求往往需要付出较高的代价 采用现代程序设计技术采用先进的技术既可提高软件开发的效率 又可提高软件维护的效率 55 软件工程原理 结果应能清楚地审查根据软件开发项目的总目标及完成期限 规定开发组织的责任和产品标准 从而使得所得到的结果能够清楚地审查 开发小组的人员应该少而精 承认不断改进软件工程实践的必要性不仅要积极主动地采纳新的软件技术 而且要注意不断总结经验 56 软件工程学的范畴 软件工程学 软件工程技术 软件工程管理 软件开发方法学 软件工具 软件工程环境 软件经济学 软件管理学 57 软件工程三要素 软件工程包括三要素 方法 工具和过程 软件工程方法为软件开发提供了 如何做 的技术 软件工具为软件工程方法提供了自动的或半自动的软件支撑环境 软件工程的过程则是将软件工程的方法和工具综合起来以达到合理 及时地进行计算机软件开发的目的 58 什么是软件工程过程 定义 软件工程过程是为获得软件产品 在软件工具的支持下由软件工程师完成的一系列软件工程活动 针对不同类型的软件产品 同一软件开发机构也可能采用多个不同的软件工程过程 59 软件工程过程的基本活动 软件规格说明 规定软件的功能及其运行的限制 软件开发 产生满足规格说明的软件 软件确认 确认软件能够完成客户提出的要求 软件改进 为满足客户的变更要求 软件必须在使用的过程中改进 60 软件工程过程的特性 易理解性 可见性 每个过程活动均能以明确的结果告终 使过程的进展对外可见 可支持性 易得到计算机辅助软件工程 CASE 工具的支持 可接受性 易于为软件工程师接受和使用 可靠性 不会出现过程错误 或发现在产品出现故障之前 健壮性 不受意外发生的问题干扰 可维护性 过程可随软件机构需求的变更或随认定的过程改进而演进 速度 从规格说明起 就能较快地完成开发而交付 61 软件工程项目的基本目标 付出较低的成本 达到要求的软件功能 取得较好的软件性能 开发的软件易于移植 需要较低的维护费用 能按时完成开发工作 及时交付使用 62 软件工程目标之间的关系 63 软件工程框架及原则 1 选取适宜的开发模型 2 采用合适设计方法 3 提供高质量工程支持 4 重视开发过程管理 64 软件工程面临的问题 1 软件费用 2 软件可靠性 3 软件维护 4 软件生产率 5 软件重用 65 1 4软件生命周期lifecycle如同任何其他事物一样 软件也有一个孕育 诞生 成长 成熟 衰亡的生存过程 一般称之为计算机软件的生存期 66 软件生命周期的定义 定义 软件生命周期是指软件产品从考虑其概念开始到该软件产品不再能使用为止的整个时期 软件生命周期可分为三个阶段 即定义阶段 开发阶段和运行维护阶段 每个阶段需完成几个任务 67 划分软件生命周期的目的和实质 便于控制开发工作的复杂性 通过有限的步骤 把用户的需求从抽象的逻辑概念逐步转化为具体的物理实现 68 工作流程图 69 软件生命周期各阶段的基本任务 定义阶段 定义阶段主要集中于 做什么 即在定义过程中 软件开发人员试图弄清楚要处理什么信息 预期完成什么样的功能和性能 希望有什么样的系统行为 建立什么样界面 有什么设计约束 以及定义一个成功系统的确认标准是什么 在本阶段需完成三项任务 70 系统定义 系统定义必须回答的关键问题是 要解决的问题是什么 如果不知道问题是什么就试图解决这个问题 显然是盲目的 只会白白浪费时间和金钱 最终得出的结果很可能是毫无意义的 尽管确切地定义问题的必要性是十分明显的 但是在实践中它却可能是最容易被忽视的一个步骤 系统定义是软件生命周期中最简短的任务 一般只需要一天甚至更少的时间 71 可行性研究 可行性研究要回答的关键问题是 对于上一个阶段所确定的问题有行得通的解决办法吗 为了回答这个问题 系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程 也就是在较抽象的高层次上进行的分析和设计的过程 可行性研究应该比较简短 这个阶段的任务不是具体解决问题 而是研究问题的范围 探索这个问题是否值得去解 是否有可行的解决办法 72 需求分析 需求分析的任务仍然不是具体地解决问题 而是准确地确定 为了解决这个问题 目标系统必须做什么 主要是确定目标系统必须具备哪些功能 系统分析员在需求分析阶段必须和用户密切配合 充分交流信息 以得出经过用户确认的系统逻辑模型 通常用数据流图 数据字典和简要的算法表示系统的逻辑模型 73 软件生命周期各阶段的基本任务 开发阶段 开发阶段集中于 如何做 即在开发过程中 软件工程师试图定义数据如何结构化 功能如何转换为软件体系结构 过程细节如何实现 界面如何表示 设计如何转换成程序设计语言 测试如何运行 在本阶段需完成四项任务 74 总体设计 总体设计必须回答的关键问题是 概括地说 应该如何解决这个问题 通常至少应该考虑下述几类可能的方案 低成本的解决方案 系统只能完成最必要的工作 不能多做一点额外的工作 中等成本的解决方案 这样的系统不仅能够很好地完成预定的任务 使用起来很方便 而且可能还具有用户没有具体指定的某些功能和特点 虽然用户没有提出这些具体要求 但是系统分析员根据自己的知识和经验断定 这些附加的能力在实践中将证明是很有价值的 高成本的 十全十美 的系统 这样的系统具有用户可能希望有的所有功能和特点 75 详细设计 总体设计以比较抽象概括的方式提出了解决问题的办法 详细设计的任务就是把解法具体化 也就是回答下面这个关键问题 应该怎样具体地实现这个系统呢 通常用HIPO图 层次图加输入 处理 输出图 PAD图或PDL语言 过程设计语言 描述详细设计的结果 76 编码和单元测试 编码和单元测试的关键任务是写出正确的容易理解 容易维护的程序模块 77 综合测试 综合测试的关键任务是通过各种类型的测试 及相应的调试 使软件达到预定的要求 最基本的测试是集成测试和验收测试 所谓集成测试是根据设计的软件结构 把经过单元测试检验的模块按某种选定的策略装配起来 在装配过程中对程序进行必要的测试 所谓验收测试则是按照规格说明书的规定 通常在需求分析阶段确定 由用户 或在用户积极参加下 对目标系统进行验收 必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验 为了使用户能够积极参加验收测试 并且在系统投入生产性运行以后能够正确有效地使用这个系统 通常需要以正式的或非正式的方式对用户进行培训 78 软件生命周期各阶段的基本任务 运行维护 维护阶段的关键任务是 通过各种必要的维护活动使系统持久地满足用户的需要 通常有四类维护活动 改正性维护 也就是诊断和改正在使用过程中发现的软件错误 适应性维护 即修改软件以适应环境的变化 完善性维护 即根据用户的要求改进或扩充软件使它更完善 预防性维护 即修改软件为将来的维护活动预先做准备 每一项维护活动都应该准确地记录下来 作为正式的文档资料加以保存 79 软件生命周期各阶段任务一览表 80 1 5软件开发模型 81 软件开发模型 在整个软件开发的发展过程中 为了要从宏观上管理软件的开发和维护 就必须对仍旧的发展过程有总体的认识和描述 即要对软件过程建模 几十年来 软件开发生命周期模型的发展有了很大的变化 提出了一系列的模型以适应软件开发发展的需要 82 编码 修正模型 在软件开发早期 开发只有两个阶段 被简单的分成编写程序代码和修改程序代码 拿到项目 马上就根据需要 开始编写程序 编完代码 调试通过 就算基本完成任务 拿给用户用 如果应用中有什么错误 或有什么新的要求 要重新修改代码 83 编码 修正模型的弊端 1 代码缺少统一规划 低估了设计的重要性 使得代码结构随着修改的次数增加变得越来越坏 以至错误越来越难改 甚至无法改 2 即使有的软件计划很好 但往往其结果并非用户所需要的 造成软件开发的风险非常大 这主要是没有重视需求而造成的 3 由于对测试 维护修改方面考虑不周 使得代码维护修改非常困难 84 瀑布模型 由于吸取了开发早期的教训 人们开始将软件开发视为工程来管理 类似于其他的工程管理 软件开发也具有一定的工序 软件生命周期 这一概念真正被提了出来 并将软件生命周期划分成 制定计划 需求分析 软件设计 程序编写 软件测试 运行与维护等六个部分 将软件生存周期的各项活动规定为依照固定顺序连接的若干阶段工作 形如瀑布流水 最终得到软件产品 85 瀑布模型 86 瀑布模型的特点 从上一项开发活动接受该项活动的工作对象 作为输入 利用这一输入 实施该项活动应完成的工作内容 给出该项活动的工作成果 作为输出传给下一项活动 对该项目活动实施的工作成果进行评审 若工作得到确认 则继续进行下一次开发活动 否则返回前一项 甚至更前项的活动 87 瀑布模型优点 消除非结构化软件 降低软件的复杂度 促进软件开发工程化 88 毕业后七年 总算接了个大工程 造一根三十米烟囱 工期两个月 造价三十万 不过要垫资