软件工程期末复习

博主软件工程所用教材如下：
软件工程：面向对象和传统的方法（原书第8版)

软件工程的范畴

• 软件工程是一门学科，目的是生产出没有错误的软件，按时并且在语算内交付，满足用户的需求；更进一步，当用户需求更改时，软件必须易于修改。
• 软件工程目的：生产出满足客户要求的、未超出预算的、按时交付的、没有错误的软件。
• 软件工程的范围非常广泛。数学、计算机科学、经济学、管理学、心理学。。。
• 软件工程概念的声明在1968年德国Garmisch召开的NATO软件工程会议上得到签署。
• 软件危机：指软件产品的质量低得通常不能接受，并且不能满足交付日期和预算限制。
• 考虑到软件危机的周期长且难以预测，可能应当将软件危机重新命名为软件萧条。
• 引入新技术：1.将新技术引入软件组织的花费 2.维护问题
• 生命周期模型：是对在构建一个产品时应当完成的步骤的描述
• 生命周期：一个产品的一系列实际步骤
• 传统模型（如瀑布模型）：
  • 需求阶段
  • 分析阶段（规格说明）：规格说明文档、软件项目管理计划
  • 设计阶段：结构设计（模块）、详细设计
  • 实现阶段：代码编写、测试、集成
  • 交付后维护：纠错性维护（软件修复）、增强型维护（软件改进：完善性维护、适应性维护）
  • 退役
• 传统开发方法可以描述为开发-维护模型
• 开发维护模型在今天不适用的原因：
• 开发周期长，客户需求改变，很早就开始维护
• 软件开发者要广泛重用，而不是从零开始
• 现代维护：在任何时候进行纠错性、完善性或适应性活动
• 交付后维护可减少重新开发，降低成本
• 提高需求、分析和设计技术是非常重要的，可以尽早发现错误且需求分析设计错误在整个错误数中占了很大的比例。
• 为什么没有计划阶段：不存在独立的计划阶段，计划活动贯穿了软件生命周期的始终，如初步计划、软件项目管理计划、计划的监督
• 为什么没有测试阶段：不存在独立的测试阶段，在每个阶段接近结束的时候（验证），在产品提交客户的时候（确认）
  • 软件的质量是指它满足规格说明的程度
  • SQA软件质量保证组
• 为什么没有文档阶段：不存在独立的文档阶段，在任何时候，软件的文档必须是完整、正确、最新的。
• 传统（结构化）范型 技术：结构化分析、数据流分析、结构化编程、结构化测试
  • 缺陷：
    • 不能解决产品规模越变越大的问题
    • 交付后维护是传统范型不能满足的
  • 原因：
    • 面向操作或者面向数据，没有结合起来
• 面向对象范型：看待对象的简单方法是把它看作统一的软件制品，结合了属性和操作。
  • 软件制品是软件产品的组成部分，如规格说明文档、代码模块或手册
  • 方法是操作的实现
  • 优点
    • 交付后维护：减少了回归错误（修改时不小心在与该处明显没有关联的另一处造成错误）
    • 与现实世界接近，抽象建模方便有效
    • 封装、信息隐藏
      • 出于这个原因，有时将面向对象设计称为职责驱动设计或按合同设计
    • 由小单元构成，降低了复杂度，简化开发和维护
    • 提高了重用度
• P14 表1-2 传统范型和面向对象范型的生命周期比较
• P14表1-3传统范型和面向对象范型的区别
• 术语
  • 客户-想建造（开发）某一产品的个体
  • 开发者-小组的成员，负责建造该产品
  • 内部软件开发-客户和开发者是同一组织的一部分
  • 合同软件-客户和开发者是完全独立的组织中的成员
  • 涉及软件的第三方是用户，将使用所开发的软件
  • 商用现货软件（用收缩薄膜包装的软件）-销售大量软件副本
  • COTS软件可通过万维网下载-点击软件
  • 开源软件-由一群自愿者开发和维护，任何人都可以下载和免费使用
    • Linus法制：如果足够多人给与关注，所有的软件错误都将一目了然。 相关法则：尽早发布，经常发布
    • 开源软件的开发者试图花较少时间用于测试，将更多发现错误的职责交给用户。
  • 软件-软件不仅由机器可识别的代码组成，而且包括作为每个项目固有组成部分的所有文档。
  • 程序员犯了过错，造成代码差错，差错累加成错误，执行软件故障。
• 道德工程师8个准则
• 公众、客户和雇主、产品、评判、管理、专业、同事、自我
• P18 本章回顾
• P19习题

软件生命周期模型

• 理想的软件开发：需求-分析-设计-实现
• 实际上：1.专业人员会犯错 2.需求会变化
• 进化树生命周期模型：每一幕的结尾有一个基准
• 米勒法则：在任何时候，人类最多只能将精力集中在7桩事情上
• 逐步求精法：集中精力于事情目前最重要的那些方面，把那些不那么紧急的方面往后拖延，然后进一步处理。
• 迭代、递增是软件工程的固有特性（瀑布模型是迭代不是递增？）
• 工作流：需求工作流、分析工作流、设计工作流、实现工作流、测试工作流
• 迭代-递增模型
  • 优点
    • 为检查产品是否正确提供很多个机会
    • 在生命周期早期可以确定蕴含结构的健壮性
      • 健壮性：软件越健壮，软件改变越有弹性，能够扩展和改变。
    • 较早地减轻风险
    • 总有该软件的一个工作版
    • 经验表明迭代-递增生命周期模型很有用
• 编码-修补生命周期模型：代码拼凑，为满足客户需求，多次改写
• 瀑布生命周期模型
  • 每个阶段需要完成文档并且产品被SAQ认可
  • 每个阶段包含测试
  • 反馈环
• 快速原型开发生命周期模型：快，第一步建造一个快速原型
• 开源生命周期模型
  • 故障报告：显现出来的非正确性的报告
  • 缺陷报告：描述哪里的源代码不正确并如何纠正它的报告
• 敏捷过程
  • 极限编程是一些新的统称为敏捷过程的范型中的一个
  • 时光盒：为任务设定一段时间，小组在这段时间内尽可能好地做工作
  • 站立会议：目的是提出问题而不是解决问题
  • TDD：测试驱动开发
  • 结对编程：2个程序员在一台计算机前一起工作
• 同步-稳定生命周期模型
• 螺旋生命周期模型：简单可以看作是每个阶段之前带有风险分析的瀑布模型
  • 适用于大型软件的内部开发
  • 螺旋模型-风险驱动
  • 主要缺点：假定软件在各个分离的阶段开发的
• P41表2-1生命周期模型的比较
• P41本章回顾
• P43习题

软件过程

• 软件工程是我们生产软件的方式
• 今天最主要的面向对象方法是统一过程
• UML统一建模语言
• 统一过程的五个核心工作流
  • 需求流：应用领域、最终期限、可靠性、成本。。。
  • 分析流：
    • 规格说明文档（模糊、不完备）
    • 项目管理计划：可交付的东西、里程碑（客户得到它们的时间）、预算
  • 设计流：结构设计-详细设计
  • 实现流
  • 测试流：测试流的性质随着被测试的制品的不同而不同。但对所有制品都至关重要一个特性是可跟踪性。
    • 单元测试
    • 集成测试：检查组件是否正确组合且满足规格说明要求
    • 产品测试：SQA 正确性和健壮性
    • 验收测试：用户使用真实数据
    • α/β，β更接近产品的最终版本
    • 回归测试：1.检查改变是否实现 2.确保无其它异常改变
• 统一过程的各阶段
  • 开始阶段：明确提出软件产品是否经济上可行
  • 细化阶段：细化最初的需求、细化体系结构、监控风险和细化它们的属性，细化商业案例，以及生成软件项目管理计划
  • 构建阶段：产生β版
  • 转换阶段：确保客户的需求切实得到满足
• 统一过程：
  • 1.将大问题拆小问题，解决大型软件的复杂性
  • 2.较好处理的另一个挑战是无法避免的改变
• 能力成熟度模型CMM
  • 初始级：缺乏有效管理和特殊计划
  • 可重复级：使用了基本的项目管理措施
  • 定义级：有充分的软件生成文档
  • 管理级：为每个项目设计了质量目标和生成目标
  • 最优级：持续改进软件过程
• P59 图3-3 5级成熟度模型以及它们的关键过程区（KPA）
• P61本章回顾
• P62习题

软件小组

• 布鲁克斯法则：向一个已经延期的软件项目增加人员会使该项目完成得更晚
• 民主小组
  • 无我编程：自我的延续
  • 对查找错误的积极态度
• 主程序员小组
  • 专业化、等级性
  • 主程序员、编程秘书、备程序员、程序员
  • 缺陷：主程序员是一个高水平程序员和管理者的结合，缺乏
  • 缺陷：编程秘书也难找
• 小组领导-技术性，小组经理-事务管理
• 分散决策-小组交互相互促进
• 同步-稳定小组：每天对部分完成的组件测试调试并同步上传
• 敏捷小组：一个超乎寻常的特点-结对编程
• 开源编程小组
• 人员能力成熟度模型:P-CMM，描述管理和开发一个组织的人力资源的最佳实践
• P72 表4-1 小组组织方法的比较以及各种方法所处的节
• P72 本章回顾
• P73 习题

软件工程工具

• 逐步求精法:尽可能将细节的定义推延到最后，以便集中精力在重要的事项上。 缺点：难以确定重要的事情
• 成本-效益分析法：确定客户是否应当进行业务计算机化的基本技术，如果确定使用计算机处理业务，应用何种方式来比较各种可选方案的成本和收益。
• 分治：大问题拆成小问题（重要性相同）
• 关注分离：将软件产品分成组件的过程，这些组件在功能上尽可能少地重叠。 高内聚和低耦合是关注分离的实例。
• 软件度量
  • 产品度量：测量产品本身的某个特性，例如规模或可靠性
  • 过程度量：开发者使用这些度量推断有关软件开发过程信息
  • 5种常用度量：规模、成本、持续时间、工作量、质量
• CASE计算机辅助软件工程
  • 最简形式是软件工具
  • 较早阶段帮助开发者的CASE工具有时称为高端CASE或前端工具，而帮助实现流和交付后维护的CASE工具称为低端CASE或后端工具
  • 编程工具：简化程序员任务，减少挫折，提高效率
    • 小编程：单模块的代码级
    • 大编程：模块级的软件开发
    • 多编程：结合小/大编程，指小组进行的软件开发
  • 结构编辑器：能够理解语言的文本编辑器
• 软件版本：新版本/新版本
  • 修订版：替代更新
  • 变种版：为共存而设计
• 配置控制：某个产品的给定版本所赖以建造的每个制品的特点版本称为该产品那个版本的配置
  • 基准：产品中所有制品的配置（版本集）
• P89本章回顾
• P90习题

测试

• 基本上，测试有两种类型的测试：基于执行的测试和基于非执行的测试
• 软件的质量是产品满足规格说明的程度
• 每个软件专业人员的任务是随时保证高质量的软件
• SQA的原则是确保软件过程的质量，从而保证软件产品的质量
• 开发小组和SQA保持管理独立很重要
• 走查：参加者驱动；文档驱动
• 审查：
• 审查和走查的对比：表面上，审查小组使用一览表来帮助找到错误；另一方面，走查过程有两步-准备、随后小组对文档进行分析，审查过程有五步概要、准备、审查、修订和跟踪，更深入。
• 评审（走查/审查）的两个主要优点
  • 检测错误的一个有效途径
  • 在软件过程的早期发现错误
  • 缺点：大型软件相当难评审
• 审查的度量：
  • 审查速率
  • 错误密度
  • 错误检测率：每小时检测到的主要和最小错误数
  • 错误检测效率：每人时检测到的主要和最小错误数
• 执行测试：推断某产品的特定行为特性的过程
• 如何测试一个实时系统：仿真器
• 实用性、可靠性、健壮性、性能、正确性
• 测试什么时候停止：只有在义无反顾废除软件的时候，才是停止测试的时候。
• 系统测试不应该由程序员进行，而是由SQA小组进行。
• P105 本章回顾
• P106习题

从模块到对象

• 模块：“模块是词汇上邻接的程序语句序列，由边界元素限制范围，有一个聚合标识符。” 特别的，传统范型的过程和函数都是模块。在面向对象范型中，一个对象是模块，对象内的方法也是模块。
  • 模块操作：指定模块做什么，也就是它的行为。
  • 模块逻辑：指模块如何完成它的操作
  • 模块背景：模块的特殊用途
• 模块内聚：模块内部交互的程度
  • 偶然性内聚（坏的）
    • 一个模块执行多个完全不相关的操作
    • 缺点：1.可维护性差 2.模块不可重用
  • 逻辑性内聚
    • 一个模块进行一系列相关的操作，每个操作由调用模块来选择
    • 问题：1.难于理解 2.代码纠错，维护困难
  • 时间性内聚
    • 模块执行一系列与时间相关的操作
    • 与其他模块的操作有很强的关联，且不易于重用
  • 过程性内聚
    • 模块执行一系列与产品要遵循的步骤顺序有关的操作
    • 缺点：操作之间弱连接，不易于重用
    • 解决方案：把过程性内聚模块分割为单独的模块，一个模块执行一个操作
  • 通信性内聚
    • 模块执行一系列与产品要遵循的步骤顺序有关的操作，并且所有的操作都对相同的数据进行，则该模块具有通信性内聚
    • 流程图内聚形容：时间性、过程性、通信性内聚
  • 功能性内聚
    • 只执行一个操作或只达到单一目标的模块
    • 通常可重用，但是并不是完全独立的
    • 易维护（错误隔离）、扩充产品功能时也很有价值
  • 信息性内聚（好的）
    • 模块进行很多操作，每个都有各自的入口点，每个操作的代码相对独立，而且所有操作都对相同的数据结构完成，则该模块具有信息性内聚。
  • 当可以分配两个或更多的不同级别的内聚给一个模块时，规则是分配最低级别的内聚给该模块。
  • 内聚例子P113
• 模块耦合：两个模块之间交互的程度
  • 内容耦合（坏的）
    • 两个模块中的一个直接引用了另一个模块的内容，则它们之间是内容耦合
  • 共用耦合
    • 可存取相同的全局数据
    • 缺点：1.与结构化编程相矛盾 2.必须阅读整个模块才能准确找出它做什么 3.所有的修改必须是一致的 4.难于重用 5.秘密共用耦合 6.潜在危机很大
  • 控制耦合
    • 两个模块中的一个模块给另一个模块传递控制要素，则它们具有控制耦合。即一个模块明确控制另一个模块的逻辑。
    • 难点：两个模块是非独立的，降低了重用的可能性
  • 印记耦合
    • 把数据结构作为参数进行传递，两个模块是印记耦合，但被调用的模块只对该数据结构的一些个别组件进行操作。
    • 潜在危机
  • 数据耦合（好的）
    • 两个模块的所有参数都是同类数据项
    • 数据耦合是关注分离的一个例子，数据耦合是理想目标
  • 耦合实例P117
• P118 图7-12本章的关键定义及所在的节*
• 数据封装：一个数据结构连同对该数据结构进行的操作
  • 数据封装是数据抽象的一个例子（C函数是过程抽象例子）
  • 提供了适应改变的一种方法-产品维护方面
• 抽象数据类型：一个数据类型连同对该数据类型的实例进行的操作
  • 抽象数据类型支持数据抽象和过程抽象
• 信息隐藏：建设一个设计，使得到的实现细节对其他模块是隐藏的
  • 可防止共用耦合
• 对象：类的一个实例
  • 特殊化和泛化
  • 聚合和关联：聚合指类的组件
  • 继承、多态与动态绑定的结合
• P128 图2-26 主要概念及其详略节
• 多态：open可应用与不同的对象，意思是很多形态
• 动态绑定：在运行时把对象和合适的方法连接起来的行为
• 多态和动态绑定的缺点：1.不能在编译时确定 2.不易于维护
• 继承的问题：
  • 脆弱的基类问题：对已存在的类修改会直接影响继承树子孙
  • 子类属性通常更多，引起存储问题
  • 多态和动态绑定。。。
  • 支持各种结构，更容易写出坏的代码
• P133本章回顾
• P144习题

可重用性和可移植性

• 如果比起从头开始编程，很容易修改修改产品使其在另一个环境中运行，那么该产品是可移植的。
• 重用是指使用一个产品中的组件来简化另一个功能不同的产品，可重用的组件不一定是一个模块或代码段-也可能是设计、文档之类
• 偶然重用=机会重用，有意重用=计划重用
• 重用障碍
  • NIH综合征：用自己编的代码才是好的，是一个管理问题
  • 注重软件质量
  • 重用会很昂贵
  • 合同软件产生法律问题
  • 开源问题
• 设计重用（如下是4种类型的设计重用）
  • 一个库或工具包：特定操作的部分设计
  • 一个框架：提供逻辑控制
  • 一个设计模式：是通常的设计问题的解决方案，这类问题以一组交互类的形式出现，需要用户根据需要制定这些交互类以形成专门的设计。
    • 外包装：封装一个类的部分属性
    • 解决两个类不兼容的解决方案是适配器模式
  • 包含框架、工具包和三种设计模式的软件体系结构
    • 应用于产品整体的设计
    • 实际中实现体系结构重用的一种方式是利用软件生产线。一个软件生产线是在相同应用领域下的一个产品集合集，通过重用核心资产（通用的软件制品）和其他制品一起建立。
    • 结构模式是实现结构性重用的另一种方式，如MVC模式，三层结构（表示逻辑层，业务逻辑层，数据存储层）
• 基于组件的软件工程目标是建造一个标准的可重用组件的集合
• 其他设计模式
  • FLIC（一个保险公司）
  • 适配器设计模式：实现不兼容接口的两个对象间通信 P145 图8-6 适配器设计模式
  • 桥设计模式：目的是从实现中剥离出抽象来，这样二者可以相互独立地修改。桥模式有时称为驱动
  • 迭代器设计模式
    • 聚合对象（容器或集合）包含组合一个单元的其他对象
    • 元素访问，元素遍历
    • 关键在于迭代器本身隐藏了元素的实现细节，因而我们可以使用迭代器处理集合中的元素，而独立于元素的容器的实现。
  • 抽象工厂设计模式
• 设计模式的种类
  • 创建类设计模式通过创建对象来解决设计问题，如抽象工厂模式
  • 结构类设计模式通过确定实现实体间关系的简单方式来解决设计问题，如适配器模式和桥模式
  • 动作类设计模式通过确定对象间通用交互模式来解决设计问题，如迭代器模式
  • P150 图8-12 23个设计模式
• 重用的组件通常经过了良好设计、全面测试并全面地形成文档，因此简化了所有三种类型的交互后维护，重用对交互后维护的影响多于对开发的影响。
• 可移植性
  • 硬件的不兼容
  • 操作系统的不兼容
  • 数值计算软件的不兼容
  • 编译器的不兼容
• 实现可移植的技术
  • 可移植的系统软件
    • 隔离任何必须依赖于实现的程序段
    • 使用抽象层次
  • 可移植的应用软件
    • 语言标准…
  • 可移植的数据
    • 移植数据最安全的方式是构建一个非结构的（顺序）的文件
  • 模型驱动结构：将产品的功能与实现相剥离
• P158 表8-2 重用和可移植性的长处和障碍
• P159 本章回顾
• P161习题

计划和估算

• 成本估算不是一项精确的科学-不确定锥区模型
• 预算是任何项目管理计划中的主要部分
  • 内部成本：针对开发者的成本
  • 外部成本：客户付的价格
• 计划的另一个重要的部分是估算项目的周期
• 产品规模的度量：通常可用代码行LOC和千行交付代码指令KDSI
• FFP度量：文件、信息量、过程
  • S=Fi+Fl+Pr C=d*S
  • S为产品的规模，C为成本，d是公司内部对软件开发过程的效率（生产力）的测量
• 功能点FP：FP=4Inp+5Out+4Inq+10Maf+7*Inf
  • 组件:输入项数Inp,输出项数Out,查询树Inq,主文件数Maf,接口数Inf
  • 所有组件归类简单的、一般的、复杂的
  • 根据功能点取值表给每个组件分配功能点
  • 每个组件功能点求和产生未经调整的功能点UFP
  • 计算技术复杂因子TCF
  • 对14个技术因子的影响进行测量，每个因子都分配一个0-5的值，然后得到累加得到总的影响度DI
  • TCF=0.65+0.01*DI （范围为0.65-1.35）
  • 计算功能点数FP=UFP*TCF
• 成本估算技术
  • 用类推法进行专家评判
    • Delphi技术可以协调多位专家的预测
  • 自底向上的方法：把产品分割成更小的组件，逐个评估
  • 算法成本估算模型：诸如功能点或UFP作为模型的输入
• 中间COCOMO（Constructive Cost Model）：中等复杂度和细节

  • 是一种层次模型，按照其详细程度分为三级：即基本的COCOMO模型、中间的COCOMO模型和详细的COCOMO模型。

  • 该模型主要对工作量ＭＭ（单位：PM）和进度TDEP（单位：月）进行估算。模型中考虑到估算量与开发环境有关，将开发项目分为三类：
    -组织型（Organic）
    程序规模<5万行，较简单,开发人员对产品目标理解充分，经验丰富，对软件开发环境熟悉。大多数应用软件及老的操作系统、编译系统属此类。

    • 嵌入型（Embadded)
      软件、硬件关系紧密,操作有限制条件,对接口、数据结构,算法要求较高。如大型复杂的事务处理系统、大型、超大型的操作系统、军事指挥系统、航天控制系统等
    • 半独立型（Semidetached)
      对项目要求界于上述两者之间,规模复杂度中等。如新操作系统、大型数据库、生产控制等软件属此类。

  • 基本的COCOMO模型（静态单变量模型）
    

  • 中间的COCOMO模型
    

  • COCOMO 工作量模型中 工作量 = a ×(size)b

    • 中间 COCOMO
      • 指数b有三个不同的值,取决于要建造的产品的模式(a, b)
    • COCOMO II
      • b 依赖于模型的各种参数,包括对某类产品的熟悉程度,过程成熟度,风险解决的程度和小组合作的程度
    • COCOMO II 考虑到对重用软件进行的小修改导致不成比例的巨大成本
• 软件项目管理计划的组成：要做的工作、工作所需资源、所需金钱
  • 软件开发所需资源：瑞利分布是资源消耗随时间变化的近似
  • 软件项目管理计划框架：最好的方法之一是IEEE标准
  • P172 图9-5IEEE项目管理计划框架
• P176本章回顾
• P177习题