《软件技术基础软件工程(自学引导)》由会员分享，可在线阅读，更多相关《软件技术基础软件工程(自学引导)（51页珍藏版）》请在金锄头文库上搜索。
1、第三章第三章软件工程软件工程 ( (自学引导自学引导) )目录 概述 软件生存周期 需求分析 软件设计 软件编程 面向对象的分析和设计 软件测试 软件维护3.1 概述 程序设计时期（19461960年代中期）程序设计是个人行为，没有软件的概念 软件时期（60至70年代中期）软件危机出现，结构化思想的提出u软件工程时期如何适应大型软件的生产1968年提出“软件工程”这一术语软件危机 表现 软件开发代价高 难于控制开发进度 工作量估计困难 软件质量低 软件修改维护困难 原因 规模大（大系统的定义：50万行1000万行） 复杂性高 软件灵活可变 影响因素多：个人能力、团队联系、产品复杂度、 符号方式
2、、时间、其它软件危机的例子 IBM 360系统 开发时间：1963-1966年 投入人力：5000人年 代码量：100万行 每个版本都是从上一个版本找出1000个错误而修 订的结果 正像一只逃亡的野兽落到泥潭中做垂死的挣扎， 越是挣扎，陷的越深，最后无法逃脱灭顶的灾难 。软件工程(Software Engineering) 软件工程指导计算机软件开发和维护的工 程学科。它应用计算机科学，数学以及管理科 学等原理，借鉴传统工程的原则、方法，创建 软件以达到提高质量，降低成本的目的。其中 计算机科学、数学用于构造模型与算法，工程 科学用于制定规范、设计范型、评估成本以及 确定权衡，管理科学用于计划
3、、资源、质量、 成本等管理。软件工程框架开发范型设计方法支持过程管理过程可用性正确性合算性需 求设 计实 现确 认维 护软件开发工具与环境计算机辅助软件工程CASE（Computer-Aided Software Engineering）CASE工具：狭义地说，是一类特殊的软件工具，用于 辅助开发、分析、测试、维护计算机程序和/或文档。广 义地说，是除了OS之外的所有软件工具的总称。软件开发环境：支持软件产品开发的软件系统。它由软 件工具和环境集成机制构成，前者用以软件开发的相关 过程、活动和任务；后者为工具集成和软件开发、维护 及管理提供统一的支持。软件工程自动化工具CASE =+3.2 软
4、件生存周期 定义：是指软件产品从用户提出要求开始，到该软 件产品不再能够使用的全过程。 包括三个阶段： 制定计划，包括问题定义和可行性研究； 开发，包括需求分析、设计、编程和测试； 维护，包括安装交付、维护和升级等。 需求 做什么？ 设计 怎么做？ 编程实现 完成系统 测试 质量保证 维护 安装后的进一步完善软件开发模型 定义 软件开发全部过程、活动和任务的结构框架。 瀑布模型 P.170 图3.1（见后） 具有反馈的瀑布模型 特点：适用于小型系统的开发，不够灵活 演化模型 多次分析和设计 针对事先不能完成定义需求的软件开发 原型系统的重要性 螺旋模型 考虑风险因素，由Boehm提出 喷泉模型
5、 多次重复，无间隙 适用于面向对象技术 增量模型 完整的体系结构的实现确定 多次迭代 RUP ROPES问题定义可行性研究需求分析设 计编 码测 试运行与维护其中：每一阶段具 有以下特征：从上一阶段接受工 作对象，即输入；对这一输入实施本 阶段的工作 给出本阶段的结果 作为输出。一、瀑布模型一、瀑布模型二、快速原型二、快速原型在分析员和用户的紧密配合下，快速确定软件系 统的基本要求。根据原型所要体现的特征(或界面形 式、或处理功能、或总体结构、或模拟性能等)，描 述基本规格说明，以满足开发原型的需要。 主要有三种不同的类型： (1)探索型：目的是要弄清对目标系统的要求，确 定所希望的特征，并探
6、讨多种方案的可行性。 (2)实验型：用于大规模开发和实现之前，考核方 案是否合适，规格说明是否可靠。 (3)进化型：进化型原型的目的不在于改进规格说 明，而是将系统建造成容易变化，在改进原型的过程 中，逐步将原型进化成最终系统。 原型快速分析或修 改构 造运 行评 价(a)原型开发模型N快速分析，确定初步规格说明构造原型运行/评价原型严格说明细部整理原型提供文档(b)模型的细化过程原型完成否细部说明否效果满意否修改与改进原型NNYYY二、快速原型二、快速原型3.3 需求分析 有关软件错误的一些事实 在软件生命周期中，一个错误发现得越晚， 修复的费用也越高 许多错误是潜伏的，并且在错误产生后很长
7、 一段时间才被检查出来 在需求过程中会产生很多错误 在需求阶段，代表性的错误为疏忽，不一致 和二义行 需求错误是可以被检查出来的需求涉及人员 需求者：客户和使用者 系统分析员：分析阶段活动的主体 开发者：包括设计，编程和项目管理者组成 分析员的素质： 能力（总体，抽象，本质） 过程（保证整个过程的善始善终） 交流 技术（了解问题域）需求获取 目的：了解用户的对软件的要求 途径： 了解系统的需求 市场调查 访问用户和领域专家 考察现场 内容： 物理环境、界面、用户或人的因素、功能、文档、 数据、资源、安全性、质量需求分析 目的： 解决需求获取阶段得到的需求的不一致性和 二义性 方法： 结构化 面
8、向对象 实体关系 软件需求说明书（SRS） 需求分析的结果文档SRS 要求 正确性 无二义性 完整性 一致性 可验证性 可理解性 可修改性 可跟踪性 与设计无关结构化分析方法（SA） 结构化分析（Structured Analysis） 提出人：Yourdon 提出的概念有： 数据流 数据源 数据潭 加工 存储 建模过程（1）建立系统的功能模型使用的工具为数据流图DFD首先：建立系统环境图，确定系统边界继之：自顶向下，逐层分解（2）建立数据字典定义数据流定义数据存储定义数据项（3）给出加工小说明（描述数据的加工）使用的工具为结构化语言、判定表、判定树3.4 软件设计 设计阶段的任务：解决怎么做
9、的问题，即将SRS转换为计算机 中可实现的系统，得到软件设计说明书。 软件设计可分为：总体设计、详细设计 设计复审：每个设计完成后，都应进行复审， 以尽早发现软件设计的缺陷。 表示形式有：层次图、 HIPO图、结构图等好的设计准则 模块化（Modularity） 抽象（Abstraction） 独立性 耦合不同模块之间相互依赖程度的度量 内容耦合（直接操作另一个模块的数据） 公共耦合（全局数据结构） 外部耦合（全局数据项） 控制耦合 标记耦合 数据耦合（参数传递） 内聚模块之内各成分之间相互依赖程度的度量 偶然内聚（模块内各部分关系松散） 逻辑内聚（模块将几种相关功能组合） 时间内聚（模块将同
10、一时刻要执行的任务组合） 过程内聚（模块的几个任务按特定次序执行） 通讯内聚（模块所有功能通过数据关联） 顺序内聚（一个成分的输出作为另一成分的输入 ） 功能内聚（模块只包含单一功能任务）启发性规则（1）改进软件结构，提高模块独立性；（2）模块规模适中-每函数类图顺序图: 学生 : 选课表单 : 课程登记管理器: 课程目录: 课程打开取课程列表 取课程列表显示课程列表选择4门主课和2门选修课把课程加入课程计划添加学生重复4门课协作图：完成课程登记状态图初始化entry/ 创建表单 do/ 初始化表单保存do/ 保存表单提交do/ 提交表单用于处理课程选择选主修课entry/ 接受课程 do/
11、增加记数选辅修课entry/ 接受课程 exit/ 增加记数H选主修课entry/ 接受课程 do/ 增加记数选辅修课entry/ 接受课程 exit/ 增加记数挂起do/ 等待30秒输入课程 count=2 count=4 / set count=0Quit输入课程输入课程挂起H恢复3.7 软件测试 目标：发现错误，保证软件质量 方式：人工测试、动态测试、自动测试 过程： 单元测试、集成测试、确认测试、系统测试 常用方法： 白盒测试、黑盒测试、回归测试、强度测试 软件测试并不等于程序测试。软件测试应贯穿 于软件定义与开发的整个期间。用户要求 用户： 我要什么？运行结果 计算机： 程序运行得到
12、 的结果源程序 程序员： 我要让计算机 怎么做？设计说明书 设计员： 我要让软件 做什么？需求说明书 分析员： 我可以提供什 么？理解正确性 表达正确性理解正确性 设计正确性 表达正确性理解正确性 编码正确性运行正确性输 入正确性相符吗？软件测试策略 被测被测 模块模块被测被测 模块模块被测被测 模块模块单元单元 测试测试单元单元 测试测试单元单元 测试测试组装组装 测试测试确认确认 测试测试系统系统 测试测试设设 计计 信信 息息软软 件件 需需 求求系统系统 其它其它 元素元素可交付可交付 的软件的软件已确认已确认 的软件的软件已集成已集成 的软件的软件软件测试过程 单元测试：单元测试：是
13、发现模块的子程序或过程的实际功能与该 模块的功能和接口的描述是否相符，以及是否有编码错误 存在。 组装测试：组装测试：目的是为了发现程序结构的错误。 确认测试确认测试：是验证软件的功能和性能及其它特征是否与 用户的要求一致。 测试：测试：是由一个用户在开发者的陪同下，在开发环 境下进行的测试，也可以是开发机构内部的用户在模 拟实际操作环境下进行的测试。 测试：测试：是由软件的多个用户在一个或者多个用户的 实际使用环境下进行的测试。 系统测试：系统测试：是将通过确认测试的软件，作为整个基于计 算机系统的一个元素，与计算机硬件、外设、某些支持软 件、数据和人员等其它系统元素组合在一起，在实际运行
14、（使用）环境下，对计算机系统进行一系列的组装测试和 确认测试。 白盒测试逻辑驱动测试 语句覆盖 判定覆盖 条件覆盖 判定-条件覆盖 条件组合覆盖黑盒测试功能测试 等价分类法 边缘值分析法 因果图法 错误推测法3.8 软件维护 进行软件维护是必不可少的。 可维护性： 可理解性、可测试性、可修改性、可靠性、 可移植性、可使用性、效率 维护种类：纠错性维护、适应性维护、完善 性维护、预防性维护 维护的副作用版本控制和管理程序复杂性度量与错误之间的关系 代码行度量 以源代码的行数-度量程序的复杂性。 Thayer指出，程序出错率为100行源程序中可能存在0.04 7个错误，出错率与源程序行数之间不存在
15、简单的线性关系 Lipow指出，对于小程序，每行代码（执行部分）的出错率为1.3%-1.8%；对于大程序，每行代码（执行部分）的出错率为2.7%-3.2%；对于少于100个语句的程序，出错率与源程序行数之间是线性关系的；随着程序的增大，出错率以非线性方式增长。小结：软件开发过程 开发过程是软件开发者所从事的一系列活动，包括：过程的实施准备 系统需求分析系统结构设计 软件需求分析软件体系结构设计 软件详细设计软件编码和测试 软件集成软件合格测试 系统集成系统合格测试 软件安装 一些新的开发方法和技术，对提高计算机软件的生产率 和质量起到了很大的作用，但问题并没得到很好解决。 关键在于软件开发组织不能很好地定义和控制其软件开 发过程。 软件开发过程应明确定义、管理、度量和控制CMM
