软件工程课程思维导图

结构如下

• 软件工程
  • 什么是软件工程
    • 方法
      • 系统的
      • 规范的
      • 可量化的
    • 过程
      • 软件开发
      • 运行
      • 维护
  • 构成的主要要素
    • 人
    • 项目
    • 过程
    • 方法
    • 工具
    • 软件制品
  • 影响软件工程进步的动力
    • 硬件能力
    • 软件技术
    • 社会需求
    • 科学技术水平
  • 软件的8个质量要素
    • 正确性
      • 软件满足需求规约的程度
      • 完成用户目标的程度
    • 可用性
      • 学习、使用成本
        • 操作软件
        • 输入数据
        • 解释软件输出结果
    • 可靠性
      • 完成预期功能概率
      • 成功运行概率
    • 有效性
      • 利用计算机空间资源完成系统功能的能力
      • 利用计算机时间资源
    • 可维护性
      • 交付使用后，通过修改，以达到
        • 改正潜伏的缺陷
        • 改进性能
        • 其他属性
    • 可移植性
      • 安装在不同的计算机的难度
      • 安装在不同的环境
    • 安全性
      • 控制/保护程序和数据不受破坏的机制，防止受到
        • 存取
        • 使用
        • 修改
        • 毁坏
        • 泄密
    • 可复用性
      • 软构件可以再多种场合应用的程度
        • 概念相对独立
        • 或则功能相对独立的一个或一组相关模块
  • 通用软件开发过程
    • 活动
      • 沟通
      • 策划
      • 建模
      • 构建
      • 部署
    • 优点
      • 增强了软件的开发能力
      • 突出了软件工程特色
      • 具有较大的灵活性
      • 具有较大的适应性
  • 各阶段使用的UML图
    • 立项
    • 初始
      • 用例图：描述软件需求的用例
      • 活动图：表示业务处理过程
      • 交互图：表示用例内部实现过程
    • 细化
      • 包图：表示软件体系结构
      • 构件图：表示软件体系结构
      • 部署图：表示软件体系结构
    • 构造
      • 类图：软件详细设计模型
      • 交互图：软件详细设计模型
      • 活动图：软件详细设计模型
      • 状态图：软件详细设计模型
      • 构件图：软件详细设计模型
  • 需求工程过程的工作流
    • 需求工程策划
    • 需求获取
    • 需求分析
    • 需求规范化
    • 需求验证
    • 总结
  • 用例驱动的需求获取过程
    • 定义软件问题
    • 创建框架用例
    • 精化用例
    • 评审用例模型
  • 需求分析的任务
    • 在需求获取阶段的基础上
    • 获得对软件需求的理解
      • 更深入
      • 更完整
    • 软件需求表示分析模型
      • 面向软件设计人员
      • 易于修改
      • 维护
  • 用例驱动的需求分析过程
    • 需求优先级分析
    • 用例分析
    • 分析模型评审
    • 为辅助需求分析而构建的快速原型
  • 软件设计应遵循的原则
    • 抽象与逐步求精
    • 强内聚及松耦合
    • 信息隐藏及关注点分离
  • 用UML活动图表示的软件设计过程的工作流
    • 设计策划
    • 体系结构设计
    • 人机交互设计
    • 详细设计
    • 设计整合与验证
    • 总结
  • 用户界面设计过程的主要活动
    • 用户分析
    • 任务分析及建模
    • 概念设计
    • 界面流设计
    • 界面精化
  • 详细设计过程的主要活动
    • 用例设计
    • 子系统设计
    • 构件设计
    • 类设计
    • 数据模型设计
    • 设计整合与验证
  • 软件测试的测试与原则
    • 任务
      • 检查软件是否满足需求规约
      • 在软件制品交付前尽可能发现软件中潜伏的缺陷
      • 减轻交付后软件改正性维护的开销
    • 原则
      • 测试是一个持续进行的过程，而不是一个阶段
      • 测试一定有计划，受控制，并提供足够的时间和资源
      • 测试应当分优先级
      • 测试应当有重点
      • 测试不是为了证明程序的正确性。而是为了证明不能工作
      • 测试是不可能穷尽的，当测试充分性满足时就可以停止测试
      • 测试是开发的朋友，不是开发的敌人
      • 测试人员应公正的测试，如实地记录和报告缺陷
      • 测试自动化能解决一部分问题，但不是全部
      • 测试不能仅仅包括功能性验证，还应包括这几方面的验证
        • 性能
        • 可靠性
        • 可维护性
        • 安全性
  • 测试用例
    • 概念
      • 测试设计的输入数据
    • 内容
      • 生成输入数据
      • 程序执行条件
      • 测试步骤
      • 预期的输出
  • α和β测试
    • α测试：系统开发者进行的测试，用户不参与
    • β测试：用户的测试，通常是开发人员不在场
  • 软件维护的分类
    • 纠错性维护
    • 完整性维护
    • 适应性维护
    • 预防性维护
  • 软件重构包括哪几个层次的工作
    • 文档重构
    • 重组
    • 逆向工程
    • 再工程
  • 用户界面设计的因素
    • 可实用性
    • 灵活性
    • 界面的复杂性与可靠性

整理了一下思维导图，如下