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