软件危机与软件工程教材(PPT 51页).ppt

2020 3 6 1 第一章绪论 软件危机与软件工程 软件工程 SoftwareEngineering 2020 3 6 2 本章主要内容 软件开发过程软件危机的产生解决软件危机的途径软件工程 2020 3 6 3 计算机硬件与软件 任何计算机系统都包含硬件 hard 和软件 software 两大部分 硬件只是提供了计算的可能性必须有支持和管理计算机的软件 系统才能实现计算 软件开发过程 2020 3 6 4 软件的三层含义 个体含义 指计算机中的程序及其文档 整体含义 指在特定计算机系统中所有上述个体含义下的软件的总称 即计算机系统中硬件除外的所有成分 学科含义 指在研究 开发 维护以及使用前述含义下的软件所涉及的理论 方法 技术所构成的学科 软件开发过程 2020 3 6 5 软件开发过程的演化 第一个时期 40 60年代 个体时期 程序时期 第二个时期 60 70年代 软件作坊时期 程序 文档 第三个时期 70年代以后 软件工程时期 软件开发过程 2020 3 6 6 软件开发过程的演化 计算机软件的数量以惊人的速度急剧膨胀 计算机硬件的性能 价格比 每10年提高2个数量级 且质量稳步提高 软件生产跟不上计算机应用的要求 开发成本增加 质量没有保证 已成制约计算机发展的关键因素 软件开发过程 2020 3 6 7 软件危机 软件危机 crisis 是指在计算机软件开发和维护过程中所遇到的一系列的严重问题 软件危机的产生 2020 3 6 8 软件危机的具体表现 对软件开发成本和进度估计不准确 用户对已完成的 软件系统 不满意 软件产品的质量不可靠 软件维护困难 维护的人员与费用不断增加 缺乏完整 正确的文档资料 软件成本在计算机系统中所占比例逐年上升 软件的发展跟不上硬件的发展和用户的要求 软件危机的产生 2020 3 6 9 产生软件危机的原因 客观原因 软件需求大 规模大主观原因 软件本身的特点与开发 维护方法不当 软件是一种逻辑部件不是物理部件 其进展情况和质量难以控制 难维护 软件的规模非常庞大 多人共同开发 必须有严格和科学的管理 软件开发过分依赖于个人的智力劳动和经验 在对用户需求没有完整 准确的认识 匆忙开发 软件危机的产生 2020 3 6 10 软件工程 软件工程是一门指导计算机软件开发和维护的工程学科 是一类求解软件包的工程 它应用计算机科学 数学及管理科学等原理 借鉴传统工程的原则 方法 创建软件以达到提高质量 降低成本的目的 解决软件危机的途径 2020 3 6 11 软件工程 计算机科学 数学用于构造模型与算法 工程科学用于制定规范 设计范型 评估成本及确定权衡 管理科学用于计划 资源 质量 成本等管理 解决软件危机的途径 2020 3 6 12 软件工程的本质特性 软件工程关注于大型程序的构造 软件工程的中心课题是控制复杂性 软件经常变化 开发软件的效率非常重要 和谐地合作是开发软件的关键 软件必须有效的支持他的用户 在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造产品 解决软件危机的途径 2020 3 6 13 软件工程基本原理 1968年在联邦德国召开的国际会议正式提出并使用 软件工程 的概念和术语 众多专家提出100多条关于软件工程的准则 1983年 B W Boehm归纳提出了七条基本原则 解决软件危机的途径 2020 3 6 14 软件工程基本原理 1 用分阶段的生命周期计划严格管理有人统计 在不成功的软件项目中有50 左右是由于计划不周造成的 应该把软件生命周期划分为若干阶段 并制定出相应的切实可行的计划 严格按照计划对开发和维护进行管理 B W Boehm认为 应制定和严格执行6类计划 项目概要计划 里程碑计划 项目控制计划 产品控制计划 验证计划 运行维护计划 解决软件危机的途径 2020 3 6 15 软件工程基本原理 2 坚持进行阶段评审设计的错误占软件错误的63 编码错误只占37 而且在后期纠正错误的代价非常高 因此 必须严格坚持阶段评审 及早发现和纠正错误 解决软件危机的途径 2020 3 6 16 软件工程基本原理 3 实行严格的产品质量控制在现实中由于外部原因要求对需求等进行修改是难免的 但必须有严格的管理制度和措施 其中主要是实行基准配置管理 解决软件危机的途径 2020 3 6 17 软件工程基本原理 4 采用现代程序设计技术和软件工程技术如结构化程序分析 StructuredAnalysis 和结构化设计 StructuredDesign 等 5 结果应能清楚地审查由于软件是一种看不见摸不着的逻辑产品 对它的检验和审查很困难 因此 应提供可视化的检验标准和方法 解决软件危机的途径 2020 3 6 18 软件工程基本原理 6 开发人员应少而精软件开发小组的人员应该是素质高 人员不宜过多 人员素质低和人员过多 都会导致软件的错误率高 且开发效率下降 成本增加 7 承认不断改进软件工程的必要性软件工程是一门不断迅速发展的学科 必须学习和跟踪先进的技术和方法 也要不断总结经验 改进方法 要不断进行技术创新 解决软件危机的途径 2020 3 6 19 解决软件危机的传统方法 用生命周期把软件划分为若干阶段 每个阶段相对独立的任务 分阶段逐步完成 每一阶段的开始和结束都有严格的标准 前一个阶段的结果就是下一阶段设计和开发的依据 每个阶段的工作都有严格的技术和管理审查 通过之后才方可开始进行下一阶段 每个阶段都要形成详尽 规范 完整的文档 提供下一阶段以及本阶段评审之用 解决软件危机的途径 2020 3 6 20 软件工程方法学 通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学 Methodology 软件工程方法学3要素 方法 完成开发的技术 解决 怎样做 工具 为运用方法提供的软件工程环境 过程 任务的框架 规定了完成各项任务的步骤 2020 3 6 21 软件工程方法学 1 传统方法学也称为生命周期方法学或结构化范型 把软件生命周期的全过程依次划分为若干阶段 然后顺序地完成每个阶段的任务 传统方法学应用十分广泛 2020 3 6 22 软件工程方法学 2 面向对象方法学该方法把数据和行为看成同等重要 它是一种以数据为主线 把数据和对数据的操作紧密地结合起来的方法 2020 3 6 23 软件工程方法学 比较 传统方法学强调自顶向下顺序地完成软件开发的各阶段任务 面向对象方法学开发软件的过程 是一个主动地多次反复迭代的演化过程 2020 3 6 24 软件的生命周期 软件的生命周期 lifecycle 是指软件产品或软件系统 从生产 投入使用到被淘汰的全过程 把软件生命周期依次划分为若干阶段 每个阶段有相对独立的任务 逐步完成各个阶段的任务后 软件的生命周期向前推进 解决软件危机的途径 2020 3 6 25 软件的生命周期 软件计划 planning 阶段问题定义 要解决的问题是什么 可行性研究 在时间和资源的约束条件下 能否完成指定的任务 包括 技术可行性 经济可行性 法律可行性 社会可行性 解决软件危机的途径 2020 3 6 26 软件的生命周期 软件开发 development 阶段需求分析总体设计详细设计编码测试运行 解决软件危机的途径 2020 3 6 27 软件的生命周期 软件维护 maintenance 阶段在不同的阶段对软件修改而付出的代价是不同的 在后期引入一个变动的代价比在早期引入要高的多 甚至高达2 3个数量级 解决软件危机的途径 2020 3 6 28 生命周期各阶段的任务 1 问题定义本阶段需要明确回答 要解决的问题是什么 系统分析员应该提出问题的性质 目标和规模的书面报告 通过对实际用户和使用部门的调查 研究 以及讨论 交流 得出一份双方都满意的文档 2020 3 6 29 生命周期各阶段的任务 2 可行性分析本阶段需要回答的是 上一阶段确定的问题有无可行的解决方案 是否值得解决 更进一步明确项目的规模和目标 从技术可行性 经济可行性 操作可行性 法律可行性 社会可行性等方面进行研究 确定是否开发本项目 2020 3 6 30 生命周期各阶段的任务 3 需求分析本阶段确定为解决该问题 目标系统必须应具备哪些功能 系统分析员在本阶段必须与用户密切配合 充分交流 得到经用户确认的系统逻辑模型 用数据流图 数据字典等描述系统的逻辑模型 需求分析阶段所确定的系统逻辑模型是以后设计和实现目标系统的基础 必须准确 完整的体现用户的需求 2020 3 6 31 生命周期各阶段的任务 4 总体设计本阶段确定目标系统的主要功能如何完成 采用流程图或其他工具描述出每种可能的系统 推荐出一个最佳的方案 并制定出实现该系统的详细计划 本阶段的另一个主要任务是设计软件的结构 确定软件应由哪些模块构成 以及模块之间的关系 还应考虑系统的开发和应用环境 如计算机系统的配置 计算机网络等 2020 3 6 32 生命周期各阶段的任务 5 详细设计详细设计阶段的任务就是把问题的求解具体化 设计出程序的详细规格说明 通常用HIPO图 层次图 输入 处理 输出 或PDL语言 过程设计语言 描述详细设计的结果 2020 3 6 33 生命周期各阶段的任务 6 编码和单元测试本阶段的任务是编写软件程序 程序员应根据目标系统的要求 选取适合的程序设计语言 把详细设计的结果编制成程序 并对每一个模块进行单元测试 需要考虑软件平台 开发工具等等 2020 3 6 34 生命周期各阶段的任务 7 综合测试本阶段的任务是通过各种测试以及相应的调试 使软件达到预定的要求 应该把测试计划 测试方案 测试结果等以文档的形式保存下来 作为软件配置的一个组成部分 2020 3 6 35 生命周期各阶段的任务 8 软件维护软件维护的任务是 通过各种必要的维护活动使系统持久地满足用户的需要 通常有4类维护活动 改正性维护 适应性维护 完善性维护 预防性维护 每一项维护活动都应该准确地记录下来 作为正式的文档保存 2020 3 6 36 软件过程 软件过程 为了获得高质量软件所需要完成的一系列任务的框架 它规定了完成各项任务的工作步骤 过程定义了运用方法的顺序 应交付的文档资料 为保证软件质量和协调变化所需要采取的管理措施 以及标志软件开发各个阶段任务完成的里程碑 使用生命周期模型简洁地描述软件过程 2020 3 6 37 软件过程模型 1 瀑布模型 WaterfallModel 一直是唯一被广泛采用的生命周期模型 传统的生命周期方法学可以用瀑布模型来模拟 犹如瀑布 各个阶段从上到下 奔流不息 2020 3 6 38 软件工程开发模式 系统需求 综合测试 设计 编码 规格说明 维护 2020 3 6 39 软件工程开发模式 按照传统的瀑布模型来开发软件 有如下几个特点 各阶段具有顺序性和依赖性 必须等上一阶段结束后 才能开始下一阶段 前一阶段的输出文档就是下一阶段的输入 2020 3 6 40 软件工程开发模式 推迟实现的观点 不要急于求成 对于规模较大 较复杂的系统 过早地急于编程实现 往往导致大量返工 甚至开发失败 应该把前面几个阶段的工作做得比较扎实 再进行后续的工作 2020 3 6 41 软件工程开发模式 质量保证的观点 1 每个阶段都必须交出合格的文档 这是下一阶段开发设计的依据和开发交互的媒介 也是对软件进行维护的重要依据 2 每个阶段完成前都要对完成的文档进行评审 以便及时发现和改正错误 对错误的修改越早越好 越晚代价越高 2020 3 6 42 软件工程开发模式 瀑布模型的优缺点 优点 强迫采用规范化的方法 每个阶段必须提交文档 产品都要经过验证 缺点 该模型几乎完全依赖书面的规格说明 很可能导致最终的软件产品不能真正满足用户的需要 2020 3 6 43 软件工程开发模式 2 快速原型 prototyping 开发模型快速原型 快速建立起来的可以在计算机上运行的程序 它所能完成的功能往往是最终产品功能的一个子集 如图1 4 当用户试用原型模型后会提出修改意见 开发人员按照该意见修改原型模型 然后用户再试用 2020 3 6 44 软件工程开发模式 原型模型优点 软件产品的开发基本上是线性顺序进行的 能够线性开发的原因 多次与用户交互 产生的规格说明文档正确地描述了用户的需要 开发人员在建立原型的过程中增长经验 在开发最终产品时减少错误 提高效率 2020 3 6 45 软件工程开发模式 3 增量模型把软件产品作为一系列的增量构件来设计 编码 集成和测试 每个构件由多个相互作用的模块构成 并完成特定的功能 特点 在较短时间内向用户提交可完成部分工作的产品 同时为用户提供充足的时间来学习和使用软件产品 缺点 设计时要考虑软件构件的扩充 2020 3 6 46 软件工程开发模式 4 螺旋 spiral 模型使用原型及其他方法尽量降低风险 可以看作每个阶段之前都增加了风险分析过程的快速原型模型 2020 3 6 47 软件工程开发模式 按照计划 风险分析 工程 用户评价 象螺旋线一圈一圈地向外发展 最终建立起运行的系统 主要是为了控制开发风险 其工程开发仍采用生命