学习资料:软件工程(第三版)齐治昌等

学习计划:30h内

题型:选择题,填空题,判断题,简答题

update:2019/01/08补充了一些

update:2019/01/09国防科大的pdf版,在网页上看体验差

  • 链接: https://pan.baidu.com/s/1RD_aN-nZcaf6Sc1vgPwoqA
  • 提取码: 8new 

第一章 软件与软件工程

  • 软件危机
    • 原因
      • 软件规模越来越大,结构越来越复杂
      • 开发管理困难
      • 开发费用增大
      • 开发技术落后
      • 生产方式落后
      • 开发工具落后
    • 解决方法
      • 采用先进的技术和开发方法
      • 采用先进的开发工具
      • 团队配合,管理严谨
    • 软件开发阶段
      • 程序设计阶段
      • 程序系统阶段
      • 软件工程阶段
  • 软件生存周期
    • 定义:软件从概念形成→进化→运行→退役的全过程,具体如下
    • 阶段:需求→设计→编码调试→软件测试→运行维护→退役
    • 其中软件进化,包括软件开发和维护
  • 软件工程常用的八个质量要素及其定义
    1. 正确性:软件满足需求规约及完成用户目标的程度
    2. 可用性:是否符合人们的使用方法和思维,学习和使用软件的难易程度
    3. 可靠性:软件完成预期功能,成功运行的概率
    4. 有效性:软件系统利用时间和空间资源的能力。简单理解为操作系统的吞吐率
    5. 可维护性:便于以后修改维护
    6. 可移植性:将软件装在不同操作系统的难易程度
    7. 安全性:保护程序和数据不被病毒、黑客破坏
    8. 可复用性:软件构建可以在多个场合使用
  • 瀑布模型(软件生存周期模型)
    • 阶段:可行性研究→需求→设计→编码调试→软件测试→运行维护→退役
    • 优点
      1. 瀑布模型思路简洁明确,上一阶段的开发结果是下一阶段的输入,相邻阶段有因果关系,紧密联系
      2. 瀑布模型的各个阶段规范了软件开发活动,有利于开发人员的管理和组织
      3. 瀑布模式适合单主机下的软件开发过程,是软件开发和项目管理的基础
    • 缺点
      1. 只有客户和需求分析员确定需求后才能进行后续的开发活动
      2. 软件项目负责人得到初始版本后,如果客户需求改变,将会承受人力、财力、时间上的损失
      3. 开发人员在瀑布模型上游隐藏的bug可能会到下游爆发
  • 增量过程模型
    • 基本思想:开发人员和用户协商将需求分解,划分为一系列增量,并为增量排序,急需的增量排在前面
    • 优点
      1. 按照增量持续发布软件新版本,可及时获得用户的反馈
      2. 能保持良好的软件体系结构
    • 缺点
      1. 增量规模不要超过20k行代码,否则会退化为瀑布模型
      2. 分解需求的过程中,必须对系统需求十分了解
      3. 多数系统需要基本服务,如何定义增量,何时实现这些增量处理起来比较困难
  • 螺旋模型
    • 思想:从里到外迭代模型
      • 定义目标:指定过程计划
      • 风险分析:采取措施规避风险
      • 开发和验证:为系统选择合适的开发模型
      • 规划:给出下一阶段的任务和计划
    • 螺旋模型=瀑布模型+增量模型集成
  • 通用软件过程模型
    • 沟通→策划→建模→构建→部署(1)
    • 初始→细化→构造→移交→生产(2)
    • 书上两个差不多的描述,(2)是课文原话,(1)是图
  • 小知识点
    • 软件=知识+程序+数据+文档
    • IEE93软件工程定义:①将系统、规范、可量化的方法应用于软件开发、运行和维护中;②对上述方法的研究

第二章 UML与RUP统一过程

  • UML(统一建模语言)概述
    • 用例视图:包括用例图,从外部用户的角度描述系统的功能,并指出参与者
    • 结构视图:包图(包和包之间的关系)、类图(类图的边表示类之间的关系,包括继承,聚合,关联)、对象图(对象图是类图的一个实例)
    • 行为视图:交互图、状态图、活动图
    • 构建视图:构建图,描述各构建之间的依赖关系
    • 部署视图:部署图,描述各工件在物理环境中的分布情况
  • RUP:统一软件的开发过程
    • RUP过程分为软件支持过程和软件生产过程
      • 软件支持过程:业务建模、需求设计和实现
      • 软件生产过程:陪着和变更管理、项目管理

第三章 需求工程概论

  • 软件需求
    • 定义:利益相关方(stakehoder)对目标软件系统在功能、质量等方面的期望,以及对目标软件系统在运行环境、资源消耗等方面的要求和约束
    • 分类
      • 功能需求:利益相关方要求目标软件系统应具有的功能
      • 质量需求:利益相关方对目标软件系统的质量要求
      • 约束性需求:利益相关方对目标软件系统在项目预算、完成时间、技术选型、必须遵守的标准与规范
    • 过程模型

第四章 需求获取

  • 需求获取定义和目标
    • 完整地收集、整理利益相关方对目标软件系统的需求,并以其容易理解的业务语言阐述这些需求,形成文档
  • 动态建模机制
    • 状态图、顺序图、合作图、活动图
  • 软件需求的初始表示
    • 用例:一个用例是执行者与目标软件系统之间的一次典型交互作用,效果是执行者在操作系统的帮助下完成了某项业务。相对独立性和完整性是两项特征
    • 用例图:每个节点只有执行者和用例
      • 执行者-执行者关系:继承(字面意思)
      • 用例-用例:包含(A包含B的所有动作)、扩展(A在B的基础上加了一些要求和功能)、继承(和扩展很类似,但有区别,扩展只加东西,继承要改原来的东西再加或者减)
    • 类图
      • 组合和聚合的区别:组合,整体类必须具备完整的管理职责;聚合,多个整体类对象的组成部分,被删除了也没关系。用例子描述一下,国破家亡中“国”和“家”这两个对象是组合关系。计算机和键盘来说,就是聚合关系。

第五章 需求分析与验证

  • 需求分析过程如下
    • 需求优先级分析、用例分析、分析模型审评、构建快速原型
    • 需求优先级分析:由于交付时间、人力资源和预算成本的限制,软件项目难易一次性、高质量地完成用户所有需求。因此需要算出优先级,确保最紧迫、最有价值的需求早日完成(很像上面的增量模型)
      • 计算公式:
  • 设置分析类
    • 边界类:接口
    • 控制类:分解任务,将子任务分配给其他类。检测器
    • 实体类:保存信息
  • 扩展机制
    • 约束:用语言表达式来约束语义
    • 标记值:有点像注释
    • 构造型:晦涩难懂。先跳
  • 需求规约:需求规约是需求分析的的结果
    • 主要内容
      • 系统概述
      • 功能性需求
      • 质量需求
      • 约束性需求

 


第六章 软件设计概念

  • 内聚度:表示一个模块内部各成分彼此关联的紧密程度
    • 偶然性、逻辑性、时间性、过程性、通信性、顺序性、功能性
  • 耦合度:指软件结构中多个模块之间的关联程度
    • 非直接耦合
    • 数据耦合与控制耦合:两个模块间通过数据来通信,但这些信息仅参与计算,不影响执行顺序。反之是控制耦合。来个例子理解一下,如果main函数有2个整型变量,调用函数fun,fun函数存在if else的语句并且和这个变量有关,那么就是控制耦合。必要时要分解模块,消除控制耦合。
    • 外部耦合:若干模块与同一外部设备关联(I/O处理使所有I/O模块与特定设备、通信协议关联)
    • 公共耦合:全局变量
    • 内容耦合:GOTO语句
    • 尽量使用非直接耦合和数据耦合,减少控制耦合,限制外部耦合和公共耦合,杜绝内容耦合(也是GOTO被禁用的原因,让代码结构非常混乱)。
  • 要求强内聚,低耦合。因为强内聚是针对一个模块的概念,一个模块功能越纯粹,越集中,复用性越强。低耦合是为了各个模块之间联系要少一点,如果某个模块发生了改变,其他模块要跟着改变会导致不可维护

第八章 人机交互设计

  • 用户界面设计模式的表示
    • 涉及屏幕内容的表示、屏幕直接跳转关系的表示
    • 出于屏幕中的界面元素有四种
      • 静态元素:不会变化的文本
      • 动态元素:随系统的运行状态而改变
      • 用户输入元素:预留空位给用户输入
      • 用户命令元素:按钮、菜单、超链接

第十一章 结构化软件开发

  • 数据流图
    • 定义:用来刻画数据流和转换的信息系统建模技术,任何软件系统都可以用数据流图表示

第十二章 软件测试

  • 软件测试目的:运行程序或模拟系统的执行,发现程序缺陷的过程,检测系统是否满足需求
  • 软件测试的方法
    • 白盒测试
      • 定义:基于产品内部结构来规划测试,检查内部程序操作是否按规定运行
      • 检查内容:路径覆盖测试、逻辑覆盖测试(真假if)、控制流测试(循环、边界)、数据流测试(测试内部数据的有效性)
      • 设计方法:逻辑覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖及路径覆盖
    • 黑盒测试
      • 定义:只依据程序的需求和规定功能,检查程序功能是否符合它的功能说明

第十三章 软件维护

  • 软件维护分类
    • 纠错性维护:诊断和改正软件中潜藏的BUG
    • 适应性维护:适应软件运行环境的变化
    • 完善性维护:根据用户在使用过程中提出新需求而实施的维护活动
    • 预防性维护:优化软件系统结构和可理解性,改善可维护性和可靠性

第十四章 Web软件工程

  • 模型-视图-控制器模式(MVC模式)
    • 该模式是被广为推崇的合适Web软件特点的体系结构模式

第十五章 软件度量与估算

  • 软件规模度量:代码行度量、功能点度量、对象点度量
    • 代码行度量
      • 生产率=代码行数/软件工作量
      • 平均成本=开发成本/代码行数
      • 文档与代码比=文档页数/总代码行
      • 代码出错率=缺陷数/代码总行数
      • 优点:直观、简单
      • 缺点:初期预算十分困难、依赖程序的设计
    • 功能点度量
      • 优缺点:功能点度量没有涉及复杂度,因此只适合一般的事务处理。不适合比较复杂的软件系统。
      • FP(function point):功能点
      • UFC:未调整功能点数
      • TCD:复杂性调节值
      • 也有和代码行度量一样的公式,但是把代码总量替换成FP
    • 对象点度量
      • 参考对象:实体(类、操作、屏幕)的个数,元素链的长度,交付给客户的系统功能
  • 提高软件质量
    • 一致性:整个软件系统使用一致的概念、符号和术语
    • 模块化:模块有助于信息的隐藏和抽象
    • 完全性:软件系统要完全实现所需功能
    • 安全性:控制或保护程序和数据不被破坏
    • 容错率:系统在各种异常条件下继续操作的能力
    • 执行效率:程序效率

第十六章 软件项目管理与过程改进

  • 进度安排方法
    • 程序评估与审查技术(PERT)和关键路径方法(CPM)
  • 基线技术
    • 使用原因:在软件开发过程中,需要变更需求、预算和设计方案等,大部分的请求是合理的,但是在不同的时机做不同的变更其难以程度和造成的影响差别很大,为了有效控制变更,引入基线概念。基线标志软件开发过程的各个里程碑,通过复审的SCI是构成基线的重要内容
  • CMM分级
    • L1初始级:无序工作状态,无规范
    • L2可重复级:软件质量保证
    • L3已定义级:软件制品工程
    • L4已管理级:软件质量管理
    • L5优化级:技术更新管理