第一章软件工程ppt课件.ppt

第一章软件工程 一 软件工程概述二 软件需求分析三 软件设计四 编程语言的选择和编码五 软件测试与维护六 面向对象的软件工程七 传统设计方法和面向对象设计方法 重点内容软件的概念 软件工程的概念 软件生存周期 几种软件开发模型的思想及其优缺点 面向对象程序设计的思想 面向对象的软件工程和传统软件工程的区别 软件的概念 为了弄清软件的概念 首先要知道什么是程序 一般认为 程序是计算机为完成特定的任务而执行的指令的有序集合 更通俗的讲 面向过程的程序 算法 数据结构面向对象的程序 对象 消息面向构件的程序 构件 构架通常 软件可定义为 软件 程序 数据 文档 一 软件工程概述 1 1软件的发展阶段程序设计阶段特点 小型源程序 结构简单 功能单一 可靠性差且由设计者自行维护软件系统阶段特点 规模大 结构复杂 软件可靠性随着规模的增大而下降 软件工程阶段特点 规模越来越大 结构越来越复杂 大型的程序设计已变成了工程项目1 2软件危机从软件发展的第二个阶段开始 就出现了软件危机 软件的生产不能满足日益增长的软件需求 更严重的是 软件的生产率随着软件规模的扩大以及复杂程度的提高而下降 导致了软件成本在计算机系统构成中所占比例进一步加大 系统实际功能与用户实际需求不符由于软件开发人员缺乏对用户需求的深入了解 具体的实现的功能和用户相差太远 开发人员和用户未能及时交换意见 使得一些问题不能及时解决而隐蔽下来 造成开发后期矛盾的集中暴露 给将来的调试和维护工作带来了更大的困难 软件的维护费用急剧上升软件的费用不仅花费在开发上 尤其要花费 软件危机的表现 在维护上 由于开发阶段有一定的隐患 维护最重要的事就是纠正软件中遗留的错误 软件的规模越大 维护的成本也越高 对软件文档配置没有足够的重视软件文档主要是开发过程中的说明书 数据字典 程序清单 软件使用与维护手册 软件测试报告及测试用例 由于开发过程没有统一的 公认的方法论和规范作指导 软件文档不规范 不健全 参加人员各行其是 忽略人与人的接口部分 发现 问题后修修补补 这样的软件很难维护 提交给用户的软件质量较差 文档的不完整是造成软件开发进程 成本不可控 软件维护与管理困难的主要因素 基于以上因素 需要一套完整的理论来指导软件的开发和维护整个过程 1 3软件工程软件工程是为了解决20世纪60年代开始出现的软件危机逐步形成而发展起来的 软件工程 一词 是1968年北大西洋公约组织 NATO 在联邦德国召开的一次会议上提出的 软件工程是大 型软件开发所必须采用的一种重要手段 1993年 权威杂志IEEE对软件工程的定义 软件工程是将系统化的 严格约束的 可量化的方法 应用于软件开发 运行和维护中去 2001年 软件工程大师RogerS Pressman对软件工程的定义 软件工程是一个过程 一组方法和一系列工具 软件工程是研究软件开发与软件管理的一门工程科学 软件工程定义的内涵 是指导计算机软件开发与维护的工程学科 可用工程的概念 原理 技术和方法来开发和维护软件 把经过时间考验而证明是正确的管理技术和当前能够得到的最好技术方法结合起来 软件工程的目的 追求软件产品的正确性 可用性及软件生产的效率 1 4软件开发模型1 4 1软件的生命周期软件生命周期是一个软件系统从目标提出 定义 开发 使用和维护 直到最后丢弃的整个过程 把整个生存期划分成较小的阶段 是实现软件工程化的重要步骤 阶段的划分使得人员分工职责清楚 项目进度控制和软件质量得到确认 原则上 前一阶段任务的完成是后一阶段工作的前提和基础 而后一阶段的任务是对于前一问题求解方法的具体化 一般说来 软件生命周期包括计划 开发和运行三个阶段 三阶段划分如下图 图1软件生命周期 计划时期计划时期的主要任务是分析用户的需求 确定软件开发的总目标 给出系统功能 性能结构 可靠性以及接口等方面的要求 由分析员和用户合作 研究完成该项软件任务的可行性 制定出软件开发的计划 并对可利用的资源 成本 可取的效益 开发的进度作出估计 制定出完成任务的计划 连同可行性报告 提交管理部门审查 为软件设计提供依据 因此 软件定义可分为问题定义和可行性研究 1 问题定义这是计划时期的第一步 根据用户或市场需求 提出软件项目目标和规模 即确定用户需要解决什么问题 由系统分析员根据对问题的理解 提交关于系统目标和范围说明书 2 可行性研究问题求解目标一经提出 分析员必须对它进行可性研究 目的是为前一步提出的问题寻求在技术上的可行性 且经济有效的解决办法 为此 系统分析员应在高层次上简化需求分析和概要分析 并写出可行性报告 开发时期开发时期要完成设计和实现两大任务 其中设计任务包括需求分析 概要设计和详细设计三个阶段 实现任务由编码和测试两个阶段完成 1 需求分析需求分析的任务是完整定义系统必须 做什么 并用开发人员和用户均能理解的语言表达出来 需求分析文挡描述了经过用户确认的系统逻辑模型 它既是软件实现的依据 也是项目最后验收交付的依据 需求分析阶段必须提出完整的系统逻辑模型 经过用户确认后进入下一阶段 2 概要设计主要任务是建立软件的总体结构 包括系统功能设计和系统结构设计 系统功能设计的任务是确定系统其外部规格和内部规格 所谓外部规格包括 系统运行环境 用户可见性功能 性能一览表 系统输入及输出格式 所谓内部规格是指主要处理的基本 系统文档种类和规格 系统测试总方案 系统结构设计的任务是确定系统模块结构 确定各模块功能划分和接口规范 调用关系 确定主要模块算法和主要数据结构 3 详细设计详细设计是针对单个模块的设计 目的是确定模块的过程结构 详细说明实现该模块功能的算法和数据结构 有时也称算法设计 详细设计的完成是用图形或伪代码描述的模块设计说明书 3 编码编码的任务是根据模块设计说明书 用指定的程序设计语言把模块的过程性描述翻译成源代码 与 需求分析 和 设计 相比 编码 要简单得多 4 测试测试是开发时期的最后一个单元 其任务是通过各种类型的测试使软件达到预期的要求 按照不同的层次 可分为单元测试 综合测试 确认测试和系统测试等步骤 大型软件的测试通常由独立的部门和人员进行 通过对测试结果的分析 要求建立系统可靠性模型 对系统可以达到的各项功能 性能指标进行量化确定 最后测试的文档为测试报告 包括 测试计划 测试用例和测试结果等 运行时期运行时期是软件生命周期的最后一个时期 其主要工作是做好软件维护 维护的目的事使软件在整个生命周期内保证能满足用户的需求和延长软件的使用寿命 软件维护的具体活动包括纠错维护 适应性维护 功能性维护和预防性维护 1 4 2软件开发模型 1 瀑布模型 流水式过程模型 软件生命周期模型 瀑布 Waterfall 模型也称为软件生存周期模型 由W Royece于1970年首先提出 根据软件生存周期各个阶段的任务 瀑布模型从系统分析 逐步进行阶段性变换 直到通过确认测试并得到用户确认的软件产品为止 瀑布模型上一个阶段的变换结构是下个阶段的输入 一个阶段工作的将影响以后各个阶段 为了保证软件开发的正确性 每个阶段任务完成后 都必须对它的阶段性产品进行审评 确认后再转入下个阶段 流程如下 可行性研究与计划 需求分析 设计 编码 运行维护 测试 定义阶段 开发阶段 维护阶段 图2瀑布模型 瀑布模型的特点 阶段间具有顺序性和依赖性 推迟实现的观点 每个阶段必须完成规定的文档 每个阶段结束前完成文档审查 及早改正错误 瀑布模型的优点 开发阶段清晰 便于评审 审计 跟踪 管理和控制 瀑布模型的缺点 不能对付含糊不清和不完整的用户需求 由于开销的逐步升级 它不希望存在早阶段的反馈 在一个系统完成以前 它无法预测一个新系统引入一个机构的影响 它不能恰当地研究和解决使用系统时的人为因素 最终产品将更多的反映用户在项目开始时的需求 而不是最后的需求 一旦用户开始使用最终的系统 并对系统有更多的学习以后 观点和意向会发生很大的变化 用户这种变化常常是无法预测的 选择瀑布模型的条件 在开发时间内需求没有或很少有变化 分析设计人员对应用领域很熟悉 低风险项目 对目标 环境很熟悉 用户使用环境很稳定 用户除提出需求外 很少参与开发工作 2 原型化开发模型 瀑布模型的缺陷在于开发阶段推进是直线型的 从工程实践来看这个是一个 理想化 的模型 不完全符合人们认识问题的规律 按着这一模型来开发软件 只有当分析员能够作出正确的需求分析时 才能够得到预期的结果 鉴于瀑布开发模型的缺陷 研究人员得出这样的结论 软件开发 特别是早期阶段 应该是一个学习和实践的过程 其活动应该包括开发人员和用户两个方面 为了使其更有效 不仅要求开发人员要与用户紧密合作 而且还要有一个实际的工作系统 建造 修改原型 用户测试运行原型 听取用户意见 图3原型范型 原型化模型的特点 原型驱动 因此必须先有一个模型 至少要有一个原型的核心 原型化模型的优点 开发速度快 用户意见反馈时 有利于开发商在短时间内推广并实施多个客户 原型化模型的缺点 事先有个展示性的产品原型 所以在一定程度上不利于开发人员的创新 选择原型化模型的条件 已有产品或产品的原型 只需客户化的工程项目 简单而熟悉的行业或领域 有快速原型开发工作 进行产品移植或升级 3 增量模型 增量模型是遵循递增的方式来进行软件开发的 软件产品被作为一组增量构件 模块 每次设计 实现 集成 测试和交互一块构件 直到所有构件实现为止 分析 设计 编码 测试 分析 设计 编码 测试 分析 设计 编码 测试 分析 设计 编码 测试 增量1 增量2 增量3 增量n 时间 增量1交付用户 增量2交付用户 增量3交付用户 增量n交付用户 图4增量模型 增量模型的特点 任务或功能模块驱动 可分阶段提交产品 有多个任务单 这些多个任务单的集成构成项目的一个总 任务书 或总 用户需求报告 需求规格说明书 模型选择的条件 在整个项目开发过程中 需求都可能发生变化 客户接受分阶段交付 分析人员对领域不熟悉 中等或高风险项目 用户参与到整个开发过程程中 使用面向对象语言或第四代语言 软件公司自己有较好的类库 构件库 增量模型的优点 能将一个大系统分解成多个小系统 这就等于将一个大风险分解为小风险 从而降低了难度 增量模型的缺点 若软件系统的组装和拆卸性不强 或者开发人员全局把握水平不高 或者客户本身就不同意分阶段提交产品 或者开发人员过剩 不易采用这种模型 选择增量模型的条件 在整个项目开发过程中 需求可能发生变化 客户接受分阶段交付 分析设计人员对应用领域不熟悉 难以一步到位 中等或高风险项目 工期过紧且分阶段提交的系统或目标 环境不熟悉 用户参与到整个软件开发过程中 软件公司自己有较好的类库 构建库 4迭代模型针对瀑布模型所存在的缺陷 人们提出了迭代模型 在许多问题中 很我们需要的真值可能是求不出来的 这就是迭代思想得来源 在计算方法中 迭代是一种逼近我们所要真值的方法 迭代式生存周期模型即为 多次执行各个开发流程 从而更好的理解需求 设计出更壮的软件构架 逐步提高开发组织能力 最终交付一系列逐步完善的实施结果 迭代模型的特点 迭代或迭代循环驱动 每一次迭代或迭代循环 均要走完初始 精化 构建 移交四个阶段 迭代模型的优点 在迭代之初 它不要求一个相近的原型 而且适合范围广 几乎可以使用于所有的项目开发 迭代模型的缺点 传统的项目组织方法按顺序 一次且仅一次 完成每个工作流程 即瀑布开发模型 迭代模型采取循环的工作方式 每次循环均使工作产品更加靠近目标产品一次 这就要求项目组成员具有很高的水平并掌握先进的开发工具 反之 就会存在较大的技术风险 选择迭代模型的条件 在项目开发早期需求有可能变化 分析设计人员对应用领域很熟悉 高风险项目 用户不同程度的参与到整个项目的开发过程 具有高素质的项目管理者和软件开发团队 5 螺旋模型 螺旋模型是Boehm于1988年提出来的 它是生存周期模型和原形的结合 体现了两个模型的优点 并在此基础上增加了新的成分 风险分析 它由需求定义 风险分析 工程实现 评审四个部分组成的迭代模型 软件开发过程每迭代一次 螺旋线就会增加一周 软件开发又前进一个层次 系统又生成一个新版本 而软件开发的时间和成本又有了新的投入 这样我们可以得出 软件开发过程是沿螺旋线的路径前进的 最后总能得到用户满意的系统 理论上 迭代可以无休止的进行下去 是个无休止过程 那迭代在什么条件下就可以结束 用户允许或可接受的目标范围内 螺旋模型 螺旋模型不仅保留了生存周期中系统地 按阶段逐步地进行软件开发和 边开发 边评审 的风格 而且还引入了风险分析 并把制作原型作为风险分析的主要措施 客户始终关心 参与软件开发 并对阶段性的软件产品提出评审意见 这对保证软件产品的质量是非常有利的 软件开发模型虽然多种多样 但在本质上可以归纳为两种类型 即瀑布类型和迭代类型 从上面介绍 可以看出属于前一种的有瀑布模型和增量模型 属于后一类型的有迭代模型 原型模型和螺旋模型 而最常用的是瀑布模型和原型模型 其次是增量模型 最难掌握的是迭代模型 1 5软件计划软件计划作为软件生命周期的第一步 其任务是进行问题求解 可行性分析 制定软件项目计划 一个软件是否值得开发 需要多长的时间和多少投资 都要在开发前前预先研究 才能减少失误 1 问题定义问题定义是计划时期的第一个阶段 其目的是弄清楚用户要计算机解决什么问题 以及项目所需的资源和经费 系统分析员要深入到问题现场 了解用户单位各层次人员对系统的要求 调查开发背景 通过问题定义阶段的工作 系统分析员应该提出关于问题性质 工程项目和规模的书面报告 并在用户和使用部门负责人的会议上认真讨论这份书面报告 双方进行沟通 澄清函发含糊不清的地方 改正不正确的地方 最后得出一份双方都满意的文档 例 某高校教务处提出开发学生选课注册系统要求 经初步调查 提出了关于学生选课注册系统的 目标和范围说明书 系统目标和范围说明书1 项目 学生选课注册系统 2 问题 在学分实行过程中 学生选课进行人工注册效率低 容易冲突 任课老师难以获得及时有效的课程选修学生名单 3 项目目标 建立一个基于教学管理计算机网络的学生学期选课注册系统 4 项目范围 硬件主要利用现存计算机教学管理网络 增配少量专用设备 软件开发费用预期x元 5 初步设想 为学生提供选课卡片和计算机网络终端查询两种选课方式 教学管理科能够对选课冲突学生进行随机查询 确定调整 系统主要输出课程注册数据库 学生课程表 课程成绩记录表 6 可行性研究 由分析员和教学管理科进行 主要对系统实施方案和学校学生选课管理规程进行研究 建议进行大约10天的可行性研究 研究费用不超过x元 二 软件立项和合同 软件项目 或产品 一般有两个渠道 一个是通过市场调研之后 认为某产品会巨大的市场空间 而软件公司在在人力 设备 资金和时间上都具备开发该产品的能力 于是立项 这类软件产品的开发称为 非订单软件 另一渠道是与固定的用户签订软件的开发合同 由软件公司启动该项目的开发 这类产品被称为 订单软件 开发 非订单性软件 需要立项 开发 订单软件 需签订合同 1 立项方法立项的具体表现形式是在市场调研的基础上 分析立项的必要性和可能性 也就是可行性研究 并具体列出系统的功能 性能 接口和运行环境等方面的需求 当前用户和潜在客户的情况 以及投入产出分析 然后按着编写立项建议书 并对它进行评议 评议通过后才正式立项 2 立项文档立项文档就是立项建议书 它有专门的书写格式 3 签订合同的方法与合同文档一个小型软件项目的开发和实施 一般可由销售人员直接签订合同即可 对于一个大中型软件项目 在签订合同之前 一般由发标单位进行公开发标 软件开发公司获取招标信息后 组织相关人员制定 提交标书 并参与竞标 竞标成功即可签订合同 并下达任务书 合同书 标书和任务书都有专门的文门格式 三 需求分析 3 1需求分析的任务需求分析的基本任务是准确回答 系统必须做什么 这个问题 在项目立项的阶段已经粗略地了解了用户的需求 甚至还提出了一些可行的方案 但在项目立项阶段的基本目的是用较小的成本在短时间内确定是否存在可行的解法 许多细节被忽略了 所以项目立项不能替代需求分析 3 1 1确定系统的综合要求对系统的综合要求有下述四个方面 1 系统功能要求2 系统性能要求3 运行要求这类要求主要表现在对系统所处环境的要求 例如 支持系统运行的系统软件是什么 采用哪种数据库管理系统 需要什么样的外部存储器和数据通信接口等 4 将来可能提出的要求 3 2需求分析的重要性需求分析的输入是软件 合同 或项目 建议书 以及对用户现场的调研 分析和确认 输出是 用户需求报告 需求规格说明书 1 需求为什么重要许多大型的应用项目的失败 最后均归结为需求分析的失败 需求分析的输出文档是 用户需求报告 是客户 软件开发者和项目管理人员必须遵守的一根基线 需求分析要占用整个软件开发时间或工作量的30 需求获取中的错误属于软件开发过程中的早期错误 它会在后续的设计和实现中进行发散式的传播 2 需求分析为什么难用户具有动态性 即需求的不稳定性 在整个生存周期内 应用软件需求会随时间的进展而有所变化 用户需求的模糊性 开发者和用户要对需求达成完全一致的认识 用户要在需求报告上签字 承担责任 企业所处的外部环境变化 增加了需求分析的难度 3 3需求的理论基础 1 什么软件需求从根本上讲 软件需求就是为了解决现实世界中的特定问题 软件必须展现的属性 软件需求的属性是 可验证性 优先性和唯一性 3 4需求分析的目的软件需求分析 其目的是用于说明软件产品或软件项目需要满足的条件和限制 在软件工程项目中首先要获取用户需求 通过对需求的提取 分析 文档化和验证 为进一步的设计和实现提供依据 需求分析就是对提取的需求进行分析整理 完成以下工作 需求分类 将相关需求组织成一个子集 检查需求是否准确 是否存在二义性 检查和解决不同需求间的冲突 分析软件的边界 以及软件与环境是如何相互作用的 从系统需求推导软件需求 3 5需求分析的方法总结前人需求分析的经验 系统分析师应对用户进行需求分析培训 用户应参加业务需求的全过程 向用户发放需求调查表格 召开需求调研