软件工程概论

建议收藏！下图为软件工程体系的思维导图，包括章节小节等内容，含有软件需求、软件设计、软件构造、软件测试、软件维护、软件配置管理等要点。跟着本图一起学习，轻松通过期末考！

软件工程概论

• 第五章 结构化设计与分析
  • 结构化分析方法（基于DFD）
    • 抽象和分解
    • 结构化分析过程
      • 理解当前的现实环境，获得当前系统的具体模型
      • 从当前系统的具体模型中抽象出当前系统的逻辑模型
      • 分析目标系统与当前系统逻辑上的差别，建立目标系统逻辑模型
      • 为目标系统的逻辑模型做补充
    • 结构化分析的描述形式
  • 数据流图
  • 数据字典
• 第七章 面向对象方法基础
  • OOA（面向对象分析）
    • 完成对所解问题的分析，确定待建系统要做什么，并建立系统模型（做什么）
  • OOD（面向对象设计）
    • 将OOA所创建的分析模型转化为设计模型 （如何做）
  • 往往反复迭代进行，没有明显分界线
  • UML（统一建模语言）
    • 视图
      • 系统可以从不同角度进行观察 从一个角度观察到的系统，构成系统的一个视图，说明了系统的一个特殊侧面
      • 视图是由若干幅图组成的一种抽象
    • 图
      • 包含系统某一特殊方面的信息，阐述系统的一个特定部分或方面
      • 由若干个模型元素组成
    • 模型元素
      • 表示图中的概念
        • 如类，对象，用况，结点（node），接口（interface），包（package），注解（note），构件（component）等
      • 表示模型元素之间相互连接的关系
        • 关联，泛化，依赖，实现等
• 第八章 面向对象建模
  • 用况建模
    • 描述一个系统应该做什么
  • 静态建模
    • 描述系统中包含的类以及类之间的关系，展现了软件系统的静态结构
  • 动态建模
    • 描述系统的动态行为，显示对象在系统运行期间不同时刻的动态交互
  • 应用题
    • 类图
      • 关于用况规约的描述
    • 用况图
    • 状态机图
      • 描写状态、事件
      • 从文字描述中找到状态、事件。
• 第10章 敏捷软件开发
  • 极限编程
    • 探索阶段
      • 产生用户故事列表的初始版本，发现对系统实现影响重大的体系结构决策
    • 制定软件发布计划
    • 开发阶段
      • 建模、编码、测试和集成
      • 如果验收测试发现错误，回到开发阶段，否则开始新一轮迭代
    • （通过测试）产品化阶段
    • 维护是极限编程的常态
  • XP方法
    • XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式
• 第13章 软件测试
  • 软件测试的基本概念
    • 在规定条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程
  • 白盒测试
    • 基本概念
      • 又称结构测试，主要用于对程序模块的测试
    • 特点
  • 黑盒测试
    • 基本概念
      • 又称行为测试，根据软件需求规约，检查功能是否符合要求
  • 逻辑覆盖（白盒测试中）
    • 含义
      • 主要考查使用测试数据运行被测程序时对程序逻辑的覆盖程度。主要覆盖标准有：语句覆盖，判定覆盖，条件覆盖，条件/判定覆盖，条件组合覆盖，路径覆盖。
  • 基本路径测试法（白盒测试）设计测试用例
    • 测试难以做到覆盖程序中的所有路径，把测试的程序路径数压缩到一定范围
    • 1、根据程序或设计图画出程序流图，并计算其区域数。
    • 2、确定一组独立的程序执行路径（称为基本路径），最后为每一条基本路径设计一条测试用例
  • 等价类划分方法（黑盒测试）设计测试用例
    • 将所有可能的输入数据划分成若干个等价类，在每个中选取一个代表性的数据作为测试数据
    • 1、确定等价类
    • 2、利用等价类设计测试用例
  • 7.3.2
  • 7.4.1
• 第15章 软件维护
  • 概念
    • 指软件系统交付使用以后，为了改正错误或满足新的需求而修改软件的过程
  • 分类
    • 纠错性维护
    • 适应性维护
      • （适应数据环境的变化）
    • 改善性维护
    • 预防性维护
      • 为进一步改善软件打下基础
  • 过程
    • 建立维护组织
    • 确定维护过程
    • 保管维护记录
    • 进行维护评价
  • 提高软件可维护性的方法
    • 确定质量管理目标和优先级
    • 使用提高软件质量的技术与工具
    • 选择可维护性高的程序设计语言
    • 完善程序文档
    • 进行质量保证审查
• 第16章 软件项目管理
  • P359
    • 什么是软件项目管理
      • 通过项目经理和项目组织的努力，运用系统理论的方法对项目及其资源进行计划、组织、协调、控制，旨在实现项目的特定目标的管理办法体系
      • 基本内容
        • 项目定义
        • 项目计划
        • 项目执行
        • 项目控制
        • 项目收尾
    • 和传统的不同点和相同点
• 第四章 设计工程
  • 软件设计原则
    • 抽象与具体求精
    • 模块化
      • 把软件按照规定原则，划分为一个个较小的，相互独立但又相互关联的部件
    • 信息隐藏
      • 模块中所包含的信息不允许其他不需要这些信息的模块使用
    • 功能独立
      • 内聚
      • 耦合
  • 模块独立性度量方式
    • P66
      • 4.4 简述模块、模块化及模块化设计的概念
        • 模块
          • 具有名字，参数，功能等外部特征以及完整模块功能的程序代码和模块内部数据
        • 模块化
          • 把软件按照规定原则，划分为一个个较小的，相互独立但又相互关联的部件
        • 模块化设计
          • 程序编写不是逐条录入计算机语句和指令 首先用主程序、子程序、子过程等框架把软件的主要结构和流程描述出来，并定义和调试好各个框架之间的输入输出链接关系
      • 4.5 举例说明每种类型的模块耦合度和每种类型的模块内聚度
        • 内聚
          • 巧合内聚
            • 几个模块中没有明确表现出独立功能的相同代码段独立出来建立模块
          • 逻辑内聚
            • 完成一组相关任务的模块，调用时由传送给模块的控制性参数确定执行哪一功能
          • 时间内聚
            • 一个模块中所有任务必须在同一时间段内执行
          • 过程内聚
            • 模块中的任务必须按照制定过程执行
          • 通信内聚
            • 模块内所有处理元素集中在某个数据结构一块区域中
          • 功能内聚
            • 模块各个部分为了完成某一功能协同工作
        • 耦合
          • 内容耦合
            • 一个模块直接操作或修改另一个模块的数据，或直接插入另一个模块
          • 公共耦合
            • 一组模块都访问同一个公共数据环境
          • 外部耦合
            • 一组模块都访问统一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该局部变量的信息
          • 控制耦合
            • 一个模块通过传达开关、标志、名字等控制信息，明显的控制另一模块的功能
          • 标记耦合
            • 一组模块通过参数表传递记录信息
          • 数据耦合
            • 一个模块访问另一模块时，彼此之间通过简单数据参数来交换输入、输出信息
          • 非直接耦合
            • 两个模块之间没有直接关系
      • 4.7 描述信息隐蔽的概念，讨论信息隐藏与模块独立两概念之间的关系
        • 1，信息隐蔽指在设计和确定模块时，使得一个模块内包含信息对于不需要这些信息的其他模块来说是不可访问的，在面向对象方法中，信息隐蔽是通过对象的封装性来实现的。
        • 2，信息隐蔽的概念与模块独立性直接相关
      • 4.8 什么是模块独立性，设计中为什么模块要独立，如何度量独立性，模块功能独立有何优点
        • 模块独立性指每个模块只完成系统要求的独立的子功能，并且与其他模块的联系最少且接口简单。
        • 独立的模块比较容易测试和维护
        • 由内聚和耦合度量
        • 优点：具有独立模块的软件比较容易开发出来，这是由于能够分割功能而且接口可以简化。
• 第二章 系统工程
  • 系统工程的任务
    • 识别用户的需求
    • 系统建模和模拟
    • 成本估算及进度安排
    • 可行性分析
    • 生成系统规格说明
  • 可行性分析
    • 含义
      • 开发一个基于计算机的系统通常都收到资源和时间上的限制，可行性分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成
    • 目的
      • 用最小的代价在尽可能短的时间内确定该软件项目是否能够开发，是否值得开发
    • 内容
      • 经济可行性
        • 进行成本效益分析，从经济角度，确定系统是否值得开发
      • 技术可行性
        • 根据系统的功能、性能、约束条件等，分析现有资源和技术条件下系统能否实现
      • 法律可行性
        • 主要研究系统开发过程中可能涉及到的合同、侵权、责任以及各种与法律相抵触的问题
    • 任务
      • 分析和澄清问题（现实与期望的距离）定义
      • 分析员应该导出系统的逻辑模型
      • 探索若干种可供选择的主要解法（即系统解决方案）
      • 研究每种解法的可行性，给出选择建议
• 第一章 概论
  • 软件
    • 概念
      • 指计算机系统中的程序及其文档
        • 程序
          • 计算任务的处理对象和处理规则的描述
            • 计算任务
              • 任何以计算机为处理工具的任务
            • 处理对象
              • 数据或信息
            • 处理信息
              • 指处理的动作和步骤
        • 文档
          • 便于了解程序所需的阐述性资料
    • 分类
      • 系统软件
        • 最靠近硬件层，系统软件与应用层领域无关，如编译程序，操作系统
      • 支撑软件
        • 支持软件开发维护与运行的软件。如数据库管理系统，网络软件，软件工具
      • 应用软件
        • 特定应用领域的软件，如嵌入式应用软件
  • 软件工程
    • 概念
      • 为了经济地获得可靠地和能在机器上高效运行的软件，而建立和使用的健全的工程规则
    • 基本原理
      • 用分阶段的软件生命周期计划严格管理
      • 坚持进行阶段评审
      • 采用现代程序设计技术
      • 结果应能清楚地审查
      • 开发小组的人员应该少而精
      • 承认不断改进软件工程实践的必要性
    • 软件工程框架
      • 目标
        • 生产具有正确性，可用性和开销合宜的产品
      • 活动
        • 生产一个最终满足需求且达到工程目标的软件产品所需要的活动
      • 原则
        • 选取适宜的开发风范
        • 采用合适的设计方法
        • 提供高质量的工程支持
        • 有效的软件工程管理
    • 软件生存周期
      • 概念
        • 软件产品或软件系统从生产、投入使用到被淘汰的全过程
      • 阶段
        • 计算机系统工程
        • 需求分析
        • 设计
        • 编码
        • 测试
        • 运行和维护
  • 软件过程
    • 软件过程是生产一个最终满足需求且达到工程目标的软件产品所需的步骤
    • 软件生存周期过程模型（详见右侧）
    • 能力成熟度模型（CMM）等级
      • 初始级
        • 软件过程的特点是无序的，有时甚至是混乱的，没有什么是经过定义的
      • 可重复级
        • 已经建立基本的软件项目管理过程去跟踪成本、进度、质量，必要的过程纪律已经就位，可以重复以前类似项目的成功
      • 已定义级
        • 管理过程和工程过程均已文档化和标准化，并已收入到组织标准软件过程中，全部项目都采用组织标准软件过程中的一个经过批复的普及剪裁版本
      • 已管理级
        • 已采集详细的有关软件过程和产品质量的度量，软件过程和产品都得到了定量的了解和控制。
      • 优化级
        • 利用来自过程和来自新思想、新技术的先导性实验的定量反馈信息，使持续的过程开发成为可能
    • 能力成熟度模型集成
      • 阶段式模型
        • 关注组织的程序度
      • 连续式模型
        • 关注每个过程域的能力
  • 软件危机
    • 概念
      • 软件开发和维护过程中遇到的一系列严重问题
• 关于考试
  • 时间： 6月9日晚7、8节
  • 地点：J7-108
  • 时长：两小时
• 题型
  • 选择
  • 简答
  • 应用
    • 三题（50）
      • DFD
      • OOA.OOD
      • 不用画图
      • 测试
        • 设计测试用例
• 考试方式
  • 读懂
  • 小规模建模
  • 涉及数据字典的内容
  • 不考映射
  • 读懂、分析案例数据模型
  • 20分左右
• 类图 内部结构图 协作图 构件图 用况图 状态机图 活动图 顺序图 通信图 部署图 包图
• 静态视图 设计视图 用况视图 状态机视图 活动视图 交互视图 部署视图 模型管理视图 剖面
• 软件生命周期模型（基本原理、优缺点、适用场景）
  • 瀑布模型
    • • 给出了软件周期活动的固定顺序，上一阶段的活动完成后向下一阶段的活动过渡，最终得到所开发的软件产品
      • 优点
        • 确保软件开发的顺利进行
        • 提高软件项目质量和开发效率
      • 缺点
        • 用户难以清晰地描述所有需求，使得不少软件需求存在不确定性
        • 实际软件开发容易出现“瀑布倒流”，很少能按瀑布模型的顺序没有回流的顺利流下
        • 修改软件代价巨大
      • 适用范围
        • 需求明确
        • 小规模软件开发
  • 演化模型
    • 先构造一个初始可运行版本，称之为“原型”，用户在试用原型过程中提出意见和建议，或增加新需求，对原型进行改造，获得原型的新版本，重复这一过程，最终得到令客户满意的软件产品
    • 适用场景
      • 对软件需求缺乏准确认识
    • 典型演化模型
      • 增量模型
      • 原型模型
      • 螺旋模型
  • 增量模型
    • • 将软件开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量“版本，后一个版本是对前一个版本的修改和补充，重复增量发布过程，直至产生最终的完善产品
      • 优点
        • 能够在较短的时间内向用户提交可完成部分工作的产品
        • 逐步增加产品功能可以使用户有较充裕的时间学习适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击
      • 缺点
        • 较难把每个新的增量构件集成到现有的软件体系结构中，而又不破坏原来已经开发出的产品。
        • 增量模型本身是自相矛盾的，它一方面要求开发人员把软件当做一个整体，另一个方面又要求开发人员把软件构件序列，每个构件本质上都独立于另一个构件，除非开发人员有足够的技术能力协调好这一明显的矛盾，否则增量模型开发出来的产品可能并不能令人满意
      • 适用范围
        • 需求经常发生变化的软件开发
        • 市场急需而开发人员和资金都不能在设定的市场期限之间实现一个完善的产品时
  • 原型模型
    • • 不必满足目标软件的所有约束，其目的是能快速，低成本地构建原型
      • 特征
        • 跌代
      • 分类
        • 探索型
        • 实验型
        • 演化型
      • 原型使用策略
        • 废弃策略
        • 追加策略
      • 适用范围
        • 用户需求不明确，需要通过构建原型来清楚的了解用户的真实需求
  • 螺旋模型
    • • 使用原型及其他方法来尽量降低风险，即是在每个阶段之前都增加了风险分析过程。
      • 优点
        • 增加了风险分析
        • 将原型的跌代特征和瀑布模型中控制和系统化的方面结合起来
      • 适用范围
        • 内部软件开发的大规模软件项目
  • 喷泉模型
    • • 基本原理
        • 分析阶段
          • 标识类及对象，定义类之间的关系，建立对象-关系模型和对象-行为模型。
        • 设计阶段
          • 从实现的角度对分析模型进行调整和扩充
        • 编码阶段
          • 用面向对象语言实现类及对象，通过消息机制实现对象之间的通信，完后软件功能。
      • 特征
        • 跌代
          • 开发活动需要多次重复
        • 无间隙
          • 开发活动之间不存在明显边界
      • 适用范围
        • 面向对象的软件开发
  • 基于构件的开发模型
    • • 利用预先包装的构件来构造应用系统
      • 分类
        • 领域工程
          • 构建领域模型、领域基准体系结构和可复用构件库
        • 系统工程
          • 使用可复用构件组装应用系统
  • 形式化方法模型
    • 净室软件工程
      • 希望在缺陷可能产生眼中的危险前消除缺陷
      • 采用增量模型