软件工程复习提纲
PS：蓝色部分 大题
Chapter 1 软件
- 什么是软件？（程序、数据、相关文档的集合，再具体解释一下三者）
- 软件的特点？（3个【和硬件对比定义】：抽象性——逻辑实体；没有明显的制造过程——着重软件开发；没有机器磨损、老化问题）
- 软件存在退化问题，退化缘于修改
- 软件发展的3个阶段：程序设计阶段、程序系统阶段、软件工程阶段（软件定义、主要程序设计语言——软件语言、软件工作范围——软件生命周期、需求者——市场用户、软件开发组成——开发小组及大中型软件开发机构、决定质量的因素——管理水平、开发技术和手段、维护责任者——专职维护人员、硬件特征、软件特征）
- 软件危机的定义（在计算机软件的开发和维护过程中所遇到的一系列严重问题)
- 软件危机的主要表现（7）
（1）对软件开发成本和进度的估计不准确
（2）用户对“已完成的”软件不满意
（3）质量
（4）维护
（5）没有适当的文档资粮
（6）成本——在计算机系统总成本——up
（7）软件开发生产率提高到速度，赶不上计算机应用普及深入趋势 - 产生软件危机的原因（软件本身特点；软件开发和维护方法不正确）
- 软件工程包括管理和技术两方面的内容
- 两种软件工程方法学的对比
| 软件工程方法学 | 优点 | 缺点 |
|---|---|---|
| 生命周期方法学/传统/结构化范型 | 分阶段——降低了整个开发过程的难度；每阶段结束前严格审查保证了软件质量，提高可维护性 | 软件规模庞大、对软件需求模糊、软件需求随时间变化；切割了数据和操作 |
| 面向对象方法学 | 降低了软件产品的复杂性；提高了软件的可理解性；简化了软件的开发和维护工作；促进了软件重用 |
-
面向对象方法学的要点（4）
对象（数据和操作）；所有对象划分成类；父类和子类的关系类层次处理——继承；对象之间只能互发消息联系
-
软件生命周期（3个时期） ：软件定义、软件开发、运行维护
-
软件定义时期（问题定义阶段——界定问题；可行性研究阶段——是否值得解、有哪些可行解；需求分析阶段——功能需求；制订工程进度表）
-
软件开发时期（总体设计阶段；详细设计阶段；编码和单元测试阶段；综合测试阶段）
-
运行维护时期/软件维护时期（改正性维护；适应性维护——适应环境的变化；完善性维护——根据用户需要扩充功能；预防性维护）
-
软件开发团队中的各种角色（8:需求分析师；设计师；程序员；测试员；培训人员；维护人员；文档库管理人员；配置管理小组）
-
改变软件工程实践的7大因素
Chapter 1 补充
- 程序设计方法时代，人们提出了结构化程序设计和模块化程序设计等程序设计方法
- 软件开发技术不再仅仅是程序设计技术，而是包括了与软件开发的各个阶段，如需求定义、设计、编码、单元测试、综合测试、使用和维护及其整体有关的各种管理技术。
- 个体手工劳动是程序设计时代的软件生产方式（程序系统时代的生产方式——手工作坊；软件工程时代的生产方式——工程化）
- 计算机科学着重于理论和原理，软件工程着重于建造系统软件
- 软件开发个阶段任务的划分应尽可能相对独立，同一阶段任务的性质应尽可能相同
- 软件的特点（6）——依赖性（依赖硬件）；可移植性；复用性；复杂性；昂贵性；社会性
- B.W.Boehm有七条准则是确保软件产品质量和开发效率的原理的最小集合，简述。
（1）用分阶段的生命周期计划严格管理
（2）坚持进行阶段评审
（3）实行严格的产品控制
（4）采用现代程序设计技术
（5）结果应能清楚地审查
（6）开发小组的成员要少而精
（7）承认不断改进软件工程实践的必要性
- 软件开发费用只占软件生存期全部费用的1/3
- 在软件开发过程中大约要花费40%的工作量进行测试和调试
- 为提高软件开发的过程的可见性，有效地进行管理，应当根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准。
Chapter 2 软件过程
- 过程的特性（7）
（1）过程规定了所有主要过程活动
（2）过程使用资源、服从于一组约束（比如进度约束），产生中间结果和最终产品
（3）可由子过程组成，这些子过程用某种方式链接起来；过程可以定义为分层的过程等级结构，以便每个子过程具有自己的过程模型
（4）每个过程活动具有有入口和出口标准，这样可以知道活动何时开始及何时结束
（5）活动以一定顺序组织，因此，一个活动相对于其他活动何时完成是很清楚的
（6）每个活动具有一系列的指导原则，以解释每个活动的目标
（7）约束和控制可以应用到任何活动、资源或产品中
- 软件过程：为建造高质量软件所需完成的任务的框架，它规定了完成各项任务的工作步骤
- 软件过程与软件工程的关系（2点：软件工程实践是在软件过程中进行的；软件过程定义了软件开发采用的方法、软件工程包含过程中应用的其他技术和工具）
- 软件过程与软件生命周期的关系（2点：软件过程是在软件生命周期中所实施的一系列活动的集合；软件生命周期与选择的软件过程有关，不同的软件过程对应不同的软件生命周期）
- 经典软件过程模型比对
需求分析；规格说明；设计验证；编码；综合测试；维护 外加验证
阶段式开发（演化模型）——渐增式开发（增量模型）；迭代式开发（螺旋式开发）
| 软件过程模型 | 瀑布模型 | V模型 | 原型模型 | 增量模型 | 螺旋模型 | 喷泉模型 |
|---|---|---|---|---|---|---|
| 特点 | 1. 阶段间具有顺序性和依赖性；2. 推迟实现的观点（逻辑和物理区分）；3. 质量保证（前一阶段ok下一阶段继续） | 强调测试活动与分析和设计之间的关联：1. 单元测试和集成测试——校验程序设计；2. 系统测试——校验系统设计；3. 验收测试——确认需求 | 1. 不带反馈环；快速分析先不考虑质量 | 第一个增量构建实现软件的基本需求，提供最核心的功能，再补充其他产品特征 | 使用原型及其他方法来尽量降低风险；每个阶段之前增加了风险分析过程的快速原型模型 | 开发软件时开发过程过于无序，应该把一个线形过程作为总目标 |
| 优点 | 1. 强迫开发人员 采用规范方法 ；2. 严格规定每个阶段必须提交的文档；每个阶段交出的所有产品必须经过质量保证小组的仔细验证 | 1. 把瀑布模型中一些隐含的迭代过程明确出来；2. 使抽象等级的概念也更明显 | 1. 软件开发过程基本上是顺序进行的；2. 能够统一客户和开发人员的对软件项目需求的理解，有助于需求的定义和确认 | 1. 使用人员不充裕、不能在期限前完成的项目；2. 有计划地管理技术风险；每个增量都发不来一个高质量版本，用户能在较短时间内使用；3. 逐步增加产品功能可以使用户有比较充裕的时间学习和使用新产品 | 1. 对于保证软件产品十分有利；2. 测试活动的确定性增强了；3. 使维护得到与开发同样的重视 | |
| 缺点 | 1. 不经实践提出完整准确要求，不切实际；2. 静态规格说明，难以认识动态软件产品；3. 非线性软件开发过程线性化；4. 开发耗时长，付出代价大 | 1. 和瀑布模型一样，都是对软件开发过程过分简单和理想化的抽象 | 1. 不可能面面俱到；2. 不能当作正式运行版本；3. 牢记没有考虑质量因素 | 1. 无缝集成到现有软件体系结构中；2. 软件体系结构必须开放的；3. 本身具有矛盾性——要求开发人员把软件看成一个整体又要求把软件看作构建序列且构建间彼此独立 | 1. 主要适合内部开发；2. 只适合大型软件项目的开发；对开发人员风险分析能力是很大的考验 | 本身要求经常对开发活动进行迭代或求精 |
| 驱动 | 文档驱动模型 | 活动驱动模型 | 原型只是模型而已；可以考虑结合瀑布模型，快速模型作为需求额分析的技术，然后把客户满意的 原型再作为瀑布模型的输入，从而达到优势互补 | 以用户要求为动力，以对象为驱动，适用于面向对象开发方法 |
- 软件项目中的风险（人员；硬件设备；项目的生存能力等）
- 螺旋模型的4个任务区域：制订计划；风险分析；实施工程；客户评估
- 现代软件过程模型
| 现代软件过程模型 | RUP软件过程模型 | 敏捷过程 | 微软过程 |
|---|
- 敏捷过程的价值观（4：个体和加护胜过过程和工具；可以工作的软件胜过面面具到的文档；客户合作胜过合同谈判；响应变化胜过遵循计划）
- 敏捷过程的原则
- 极限编程是敏捷过程中最负盛名的一个
Chapter 2 补充
- 软件工程过程有哪几个基本过程活动？试说明
P（Plan）：软件规格说明。规定软件的功能及其运行的限制
D（Do）：软件开发。产生满足规格说明的软件
C（Check）：软件确认。确认软件能够完成客户提出的要求
A（Action）：软件演进。为满足客户的变更要求，软件必须在使用过程中演进。
- 软件产品的质量一直都是用户高度重视的问题，简述有哪些评论质量的观点
（1）用户的观点：质量是恰好达到目的
（2）制造的观点：质量是和需求说明的一致
（3）产品的观点：质量是与产品的内在特性相联系的
（4）基于价值的观点：质量取决于顾客愿意支付的金额
（5）超越的观点：质量是可以定义
- 六个质量特性——功能性、可靠性、可维护性、效率、可使用性、可移植性
- 软件产品质量评价金三角“产品运行、产品修改、产品变迁”
- 系统：系统是一组事务的集合：实体的集合、活动的集合、实体和活动之间的关系的描述以及系统边界的定义
- 为保证软件开发过程能够跟上技术的进步，必须不断地灵活地改进软件工程过程
- 软件生存期的概念（6个阶段）
（1）软件项目计划（工作范围、风险分析、资源、成本和进度、项目可行性）
（2）软件需求分析和定义（正式的信息域分析；软件原型化方法）
（3）软件设计（概要设计；详细设计）
（4）程序编码
（5）软件测试
（6）软件维护
- 要成功地完成软件开发工作的一个主要的决定性因素是软件项目管理
- 所有软件开发都可以看成一个问题循环解决的过程，其中包括4个截然不同的阶段：状态捕获、问题定义、技术开发和方案综合
- 软件质量的事后度量包括：正确性、可维护性、完整性、可使用性
- 软件范围包括功能、性能、限制、接口和可靠性
- 风险估计从两方面估计风险：一是风险发生的可能性；二是估价与风险相关的 问题出现后将会产生的结果
- 在与软件成本相关的影响因素中，人员的能力是最大影响因素
- 软件开发所需的人力随开发的进展逐渐增加，在编码与单元测试阶段达到高峰，以后又逐渐减少
- 用各种不同的方法对风险进行分类是可能的。从宏观上看，可将风险分为项目风险、技术风险和商业风险
- 软件范围标明了软件要实现的基本功能，并尽量以定量的方式界定这些功能
- 只要事先建立特定的度量规程，很容易做到直接度量开发软件所需要的成本和工作量、产生的代码行数等
- 软件的 完整性是度量一个系统抗拒对它的安全性攻击（事故的和人为的）能力
- 业务系统计划工具借助特定的元语言建立一个组织的战略信息需求的模型，导出特定的信息系统
- 对每一种软件资源，应说明4个特性：资源的描述，资源的有效性说明，资源在何时开始需要，使用资源的持续时间。最后两个特性统称为时间窗口。
- 软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价。
- 自顶向下估算软件成本的方法主要是从项目的整体出发进行类推；自底向上主要是分解
- Putnam是一种动态多变量成本模型，它是假定在软件开发的整个生存期中工作量有特定的分布
- Boehm提出的结构化成本估算模型是一种精确、易于使用的成本估算方法
Chapter 3 可行性研究
- 可行性研究的目的：用最小的代价，在尽可能短的时间内确定问题是否能够解决
- 可行性研究的实质：就是一次压缩、简化了的系统分析和设计的过程
- 可行性研究的任务（可行性研究应该着重考虑的5个方面——技术可行性；经济可行性；操作可行性；法律可行性；开发方案的选择性研究）
- 可行性研究最根本的任务： 对以后的行动方针提出建议（预期总成本的5%～10%）
- 成本（4:购置；开发；安装、运行及维护；培训）
- 收益（2：增加收入和节省开支；心理效益）
- 可行性研究的步骤（9）
复查系统规模和目标
研究目前正在使用的系统
导出新系统的高层逻辑模型
重新定义问题
导出和评价供选的方案
推荐一个方案并说明理由
推荐行动方针
书写计划任务书
提交审查 - 系统流程图绘制方法
- 成本效益分析方法
- DFD图绘制方法
- 数据字典：数据字典是对数据流图中包含的所有元素的定义的集合。
- 数据字典应该由对下列4类元素的定义组成：数据流、数据流分量（数据元素）、数据存储、处理
Chapter 4 需求分析
- 需求分析的任务（4点——数据模型；功能模型；行为模型；分解）
（1）必须理解并描述问题的信息域，根据这条准则建立数据模型；
（2）必须定义软件应该完成的功能——功能模型；
（3）必须描述作为外部事件结果的软件行为——行为模型；
（4）必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节 - 需求难以建立的原因
（1）误解
（2）交流障碍
（3）“完整性”问题
（4）需求永远都不会稳定
（5）用户意见不统一
（6）错误的要求
（7）认识混淆 - 需求分析的任务（4点）
4.与用户沟通获取需求的方法（4点）
（1）访谈
（2）面向数据流自顶向下求精
（3）简易的应用规格说明技术（起草完整的软件需求规格说明书）
（4）快速建立软件原型（构建和修改原型的方法和工具——第四代技术；可重用的软件构件；形式化规格说明和原型环境）
5.概念性数据模型是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，而且与在软件系统中的实现方法无关。
6.数据模型中包含3种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系
7.数据对象只封装了数据而没有对施加于数据上的操作
8. 联系也可能有属性
9. 联系的3种类型（一对一；一对多；多对多）
10. 数据规范化的目的：减少数据冗余；避免出现插入异常或删除异常；简化数据修改的过程
11. 1NF：原子性
12. 2NF：每个非关键字由整个关键字决定（part不行）
13. 3NF：不存在函数依赖
14. 状态转换图的绘制方法
15. 状态：状态是任何可以被观察到的事物的行为模式，规定了系统对事件的相应方式。
16. 事件：在某个特定时刻发生的事情，它是对引起系统做动作或从一个状态转换到另一个状态的外界事件的抽象
17. 状态迁移图/层次方框图/Warnier图/IPO图/时序图（描述事件、状态等的一些图形工具）
18. 扩充时序图——表示进程间的通信流，用于分析几个事件的交错现象
19.Petri图绘制方法
20.从哪些方面验证软件的正确性（4个——一致性；完整性；现实性；有效性）
Chapter 4 补充
- 在软件需求分析阶段，分析人员要确定对软件的综合要求，其中最重要的是功能要求
- 需求分析阶段产生的最主要的文档需求分析说明书
- 实体-关系图用于数据建模，它最初用于数据库的设计
- 数据词典中有四类条目，分别为数据流、加工、数据存储、外部实体
- 状态-迁移图用于行为建模，状态中包含活动，状态因事件发生转移
- 需求分析应该从问题的信息域和功能域出发。信息域应包括信息流、信息内容和信息结构
- 软件需求分析阶段的工作可以划分4个方面：对问题的识别、分析与综合、制订需求规格说明和需求分析评审
- 研究开发资源的有效性属于技术可行性的一部分
- 在可行性研究过程中，对每一个合理的候选方案，分析人员都应准备“系统流程、组成系统的物理元素清单、成本-效益分析、实现该系统的进度计划
- 软件需求分析的任务不应包括结构化程序设计
- 分层数据流图是一种比较严格又易于理解的描述方式，它的顶层数据流图描述了系统的输入与输出
- 对于分层的数据流图，父图与子图的平衡是指子图的输入、输出数据流同父图的输入输出数据流必须一致
- 一个局部数据存储当它作为某些加工的数据接口或某个加工的特定输入/输出
- 快速原型化思想是在研究需求分析阶段的方法技术中产生的
- 用于整个开发阶段，及早提供一个原型系统的是演化型原型
- 用于软件设计阶段，考察实现方案是否可行的是实验型原型
- 进行需求分析的多种工具可以有：数据流图、判定表、数据字典，但是没有PAD图
- 在需求分析中，分析员要从用户那里解决的最重要的问题是要让软件做什么
Chapter 5 总体设计
- 软件设计是在软件开发中形成质量的地方；设计提供了可用于质量评估的软件表示；是将需求准确转换为完整的软件产品或系统的唯一方法
- 概要设计：将软件需求转化为数据结构和软件的系统结构，即系统的模块划分。
- 详细设计：通过对系统的结构表示（每个模块的内部工作）进行细化，得到软件的详细的数据结构和算法
- 软件设计过程通常由2个主要阶段构成：
（1）系统设计阶段——确定系统的具体实现方案
（2）结构设计阶段——确定软件结构 - 典型的总体设计过程（9个步骤）
（1）设想供选择的方案
（2）选择合理的方案（3种方案、4份资料：至少选取低成本、中等成本和高成本的3种方案）
（3）推荐最佳方案
（4）功能分解（对程序的设计通常分为2个阶段：结构设计、过程设计；根据是「数据流图」）
（5）设计软件结构
（6）设计数据库（数据结构的设计从某种意义上讲是设计活动中最重要的一个）
（7）制订测试计划
（8）书写文档
（9）审查和复审 - 书写文档（5点）——系统说明；用户手册；测试计划；详细的实现计划；数据库设计结果
- 软件设计的原理：
（1）模块化
（2）抽象
（3）信息隐藏和局部化
（4）逐步求精
（5）模块独立性（便于开发；便于测试和维护） - 模块化的好处
（1）软件结构清晰，容易设计、阅读和理解
（2）软件容易测试和调试，因而有助于提高软件的可靠性
（3）能够提高软件的可修改性
（4）有助于软件开发工程的组织管理 - 过程抽象：把完成一个特定功能的动作序列抽象为一个过程名和参数表，以后通过指定过程名和实际参数调用此过程。(function)
- 数据抽象：把一个数据对象的定义抽象为一个数据类型名，用此类型名可以定义多个具有相同性质的数据对象。(class)
- 逐步求精：为了能集中精力解决主要问题而尽量推迟对问题细节的考虑
- 信息隐藏的好处：
（1）支持模块的并行开发
（2）使得软件易修改，减少后期测试和维护的工作量
（3）系统易于扩充 - 模块独立是模块化、抽象、信息隐蔽和局部化概念的直接结果
- 模块独立性的定性标准度量：耦合和内聚
- 耦合的强弱取决于模块间接口的负责程度，进入或访问一个模块的点，以及通过接口的数据
- 各种耦合的比较（7个）
弱---->强
| 耦合种类 | 非直接耦合 | 数据耦合 | 标记耦合 | 控制耦合 | 外部耦合 | 公共耦合 | 内容耦合 |
|---|---|---|---|---|---|---|---|
| 特点 | 两模块️直接联系，通过主模块联系 | 通过简单参数交换IO | 通过参数表传递记录信息，记录是一个数据结构 | 一个模块通过开关、标志、名字等控制信息明显控制另一模块的功能，需要指导被控制模块的内部逻辑信息 | 一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递这一参数信息 extern | 访问同一公共数据环境（全局数据结构、共享的通信区、内存的公共覆盖区）Fortran语言中的common区 | 4️情况：直接访问；不正常转入；代码重叠（只可能出现在汇编中）；一个模块多个入口 |
| 设计指导原则 | 尽量使用 | 少用 | 少用 | 限制 | 限制 | 完全不用 |
-
降低耦合度的方法
（1）根据问题特点，选择适当的耦合类型
（2）降低模块接口的复杂性（信息数量；联系方式；信息结构）
（3）把模块的通信信息放在缓冲区中 -
各种内聚的比较
弱---->强
| 内聚类型 | 偶然内聚 | 逻辑内聚 | 时间内聚 | 过程内聚 | 通信内聚 | 顺序内聚 | 功能内聚 |
|---|---|---|---|---|---|---|---|
| 特点 | 模块内各部分之间联系不大 | 单接口多功能模块，由参数决定使用哪个功能 | 大多为多功能模块，这些功能需要在同一时间段内执行 | 程序流程图的一部分 | 通过数据流图来定义的，各功能使用了相同的输入或产生了相同的输出 | 一个模块内的处理元素和同一个功能相关且顺序执行 | 只做一件事：一个模块中的各个部分就是为了完成某一具体功能且均必不可少 |
| 实例 | eg：初始化和终止模块 | eg：程序流程图中的循环部分、判定部分、计算部分分成3个模块 | eg：根据数据流图划分模块时，通常得到顺序内聚模块 |
- 启发规则的内容
（1）改进软件结构提高模块独立性
（2）模块规模应该适中（过大分解）
（3）深度、宽度、扇入和扇出都应该适当（追求椭圆的结构）
（4）模块的作用域应该在控制域之内
（5）力争降低模块接口的复杂程度
（6）设计单入口单出口的模块
（7）模块功能应该可以预测，避免对模块施加过多限制 - 模块分解和合并，力求降低耦合提高内聚；消除重复；
- 控制域：以A为根结点的上的节点均是；作用域：受该模块内一个判定影响的所有模块的集合。可以通过调整的结构，通过节点上将作用域和控制域统一
- 描绘软件结构的图形工具——层次图/HIPO图/结构图（SC）
- 在系统结构图中，不能再分解的底层模块称为【原子模块】
- 完全因子分解系统： 原子模块——全部实际加工；非原子模块——仅执行控制和协调功能（理想化）
- 系统结构图中4种类型模块（传入模块；传出模块；变换模块；协调模块）
- 结构化设计方法（SD方法）/基于数据流的设计方法——把信息流映射成软件结构，信息流（分为变换流——变换中心和事务流——事务中心）的类型决定了映射的方法
- 变换分析和事务分析问题
- 软件体系结构是对子系统、软件系统构件以及他们之间相互关系的描述
- 4+1视图模式
- 构件间的关系：连接器（connector）eg：过程调用机制
- 软件系统结构风格根据软件系统的结构定义了软件系统族。它通过施加于构件上的限制及组成与设计规则来飙戏呐构件和构件间的关系（SA styles）
- 每种体系结构风格定义的内容（4个：一组构件；一组连接件；约束；语义模型）
- SA styles分类
- 软件结构图，映射步骤的画法
Chapter 6 详细设计
- 结构程序设计经典定义：如果一个程序的代码块仅仅通过顺序、选择和循环这3种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。
- 对经典定义的扩充“结构程序设计是尽可能少用GOTO语句的程序设计方法。最好仅在检测出错误的时候才使用GOTO语句，而且应该是总是使用向前GOTO语句。”
- 出错信息处理：用户可理解的术语描述问题；有助于从错误恢复的建设性意见；指出错误可能导致哪些负面后果；视觉和听觉上的提示；不能带有指责色彩（定义出错代码
#define error1 1；定义出错具体信息char* ermsg[]={"No error","Open file error",...,};；声明表示错误代码的全局变量long error = 0;；catch和throw错误信息) - 过程设计技术和工具
- 表达过程规格说明的工具叫做详细设计工具：
图形工具、表格工具、语言工具 - 程序流程图本质上不是逐步求精的好工具，它诱使程序猿过早的考虑程序的流程控制，而不去考虑程序的全局结构
- 必须限制程序流程图只能使用5种基本的控制结构
- PAD图、判定表、判定树的绘制
- 程序复杂程度的定量度量——主要掌握McCabe方法
- McCabe方法根据程序流的复杂程度定量度量程序的复杂程度，这样度量处理的结果称为程序的环形复杂度。
- 流图的绘制方法和环形复杂度的计算
Chapter 6 补充
- 通常选用程序设计语言的因素有项目的应用领域、软件开发的方法、软件执行的环境、算法和书数据结构的复杂性和软件开发人员的知识
- 为开发一个特定的项目选择程序设计语言时，必须从心理特性、工程特性和技术性能特性等几个方面考虑
- 提高程序效率的根本途径在于选择良好的设计方法、良好的数据结构和算法、而不是靠编程时对语句进行调整
- 语句构造的原则是简单直接，不能因为追求效率而使代码复杂化。
Chapter 7 实现
- 【编码风格】好程序的代码逻辑简明清晰、易读易懂——程序内部文档；数据说明；语句构造；IO方法；效率问题
- 编码和测试统称为实现；软件测试在软件生命周期中横跨两个阶段；测试的目标是发现错误，调试的目的是诊断并改正错误；测试是确定可靠性模型的依据
- 注释分为序言性注释每个程序模块的开头部分和功能性注释
- 功能性注释嵌在源程序体中，用以描述其后的语句或程序段在做什么工作，或是执行了下面的语句会怎么样，而不要解释下面怎么做
- 源程序的效率直接由详细设计阶段决定的算法的效率决定，也受程序的风格
- 软件测试目标（3个）
（1）测试是程序的执行过程，目的在于发现错误
（2）一个好的测试用例在于能发现至今未发现的错误
（3）一个成功的测试是发现了至今未发现的错误的测试 - 软件测试方法（黑盒测试和白盒测试）
- 如果已经知道了产品应该具有的功能，可以通过测试检验是否每个薄嫩那个都能正常使用；如果已经知道了产品内部同坐过程，可以通过测试来检验产品内部动作是否按照规格说明书的规定正常进行。
- 黑盒测试（功能测试/数据驱动测试）：依据程序的需求规格说明书,检查程序能否满足功能需求
- 白盒测试（结构测试/玻璃盒测试/逻辑驱动测试）：利用层序内部的逻辑结构；对程序的所有逻辑路径进行测试，检查内部的数据结构和运行状态是否有错，程序的语句或条件与预期的状态是否一致。
- 软件测试步骤（5）
（1）模块测试/单元测试：每个模块作为一个单独的实体来测试，发现的往往是编码和详细设计的错误
（2）子系统测试/集成测试：着重测试模块的接口，经过单元测试的模块组合
（3）系统测试/集成测试：子系统装配。发现软件设计中的错误，也可能发现需求说明中的错误
（4）验收测试/确认测试：软件系统作为单一的实体进行测试，有用户参与，使用实体数据（系统将来要处理的数据）；发现系统需求说明书中的
（5）平行运行：新旧系统同时处理 - 测试阶段的信息流程：
软件配置（需求说明书、设计说明书、源程序）和测试配置（测试计划、测试方案）---->测试（测试结果）---->评价（和预期结果一起进行）
----->排错（错误）
----->可靠性模型（错误率数据）----->可靠性预测 - 测试重点（5个）
（1）模块接口
（2）局部数据结构
（3）重要的执行通路（选择最有代表性、最可能发现错误的执行通路进行测试）
（4）出错处理通路
（5）边界条件 - 计算机测试（3点）
（1）需要编写驱动程序（driver）和存根程序（stub）
（2）驱动程序实际上是测试当前模块的接口和输入的数据；存根程序是模拟在当前测试模块中调用的其他模块 - 集成测试是测试和组装软件的系统化技术；由模块组装成程序时有两类方法：非渐增式测试——先单独然后所有集合；渐增式测试——1+1=2；2+1=3；依此类推
- 集成测试的集成策略
- 回归测试：重新执行已经做过的测试的某个子集，以保证由于测试或其他原因引起的变化，不会导致由于调试或其他原因引起的变化，不会导致非预期的软件行为或额外错误
- 确认测试也叫验收测试，目标是验证软件的有效性；确认测试以用户为主来进行
- 软件有效性：如果软件的功能和性能如同用户所合理期待的那样，软件就是有效的（需求规格说明书/类似文档——软件有效性的标准/确认测试的基础）
- Alpha测试——受控环境和Beta测试——不受控的真实应用
- 白盒测试技术（逻辑覆盖——以程序内部的逻辑结构为基础；控制结构测试——根据程序的控制结构设计）
- 给出符合某些逻辑覆盖的测试方案
- 基本路径测试首先计算程序的环形复杂度，并用该复杂度为指南定义执行路径的基本集合，从该基本集合导出的测试用例可以保证程序中每条语句至少执行一次，而且每个条件在执行时都将分别取真、假两种值
- 在基本路径测试中，某些独立路径不能以独立的方式测试，必须作为另一个路径的一部分来测试
- 设计基本路径测试用例
- 黑盒测试的主要方法（3种）——等价划分；边界值分析；错误推测
- 等价划分方法
- 等价划分例题
- 软件可靠性：程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率
- 软件可用性：程序在给定的时间点，按照规格说明书的规定成功地运行的概率
- 软件可靠性计算
Chapter 7 补充
- 软件测试阶段的基本任务应当是根据软件开发各阶段的文档资料和程序的内部结构，精心设计一批“高产”的测试用例，利用这些测试用例执行程序，找出软件中潜藏的各种错误和缺陷 。
- 测试用例不仅要选用合理的测试输入数据，还需要选用不合理的测试输入数据，这样能更多地发现错误，提高程序的可靠性。对于不合理的测试输入数据，程序应拒绝执行，并给出相应的提示。
- 动态测试指通过运行程序发现错误，对软件产品进行动态测试时使用黑盒测试法和白盒测试法。
- 静态测试指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测
- 在单元测试中，驱动模块的作用时用来模拟被测模块的上层调用模块。它的工作时接受为测试输入数据，以上层模块调用被测试模块的形式驱动被测模块，接受被测模块的实测结果并输出
- 错误的群集现象是指模块错误发现率与模块的残留错误数成正比关系
- 软件测试用例主要由测试输入数据和测试的预期结果两部分组成
- 与设计测试用例无关的文档是项目开发计划
- 测试成本已超过软件开发成本的30%以上
- 如果想要进行成功的测试，为其设计测试用例主要依赖于测试人员的经验
- 使用白盒测试方法时，确定测试数据应根据程序的内部结构和制定的覆盖标准
- 路径覆盖是最强的覆盖准则
- 等价类划分是用的最多的 一种黑盒测试方法
- 在黑盒测试中，着重检查输入条件的组合的测试用例设计方法是因果图法
- 单元测试将根据详细设计阶段中产生的规格说明进行
- 组装测试计划是在概要设计阶段制定的
- 确认测试计划是在需求分析阶段制定的
- 软件的组装测试最好是由不属于该开发组的人员承担，以提高组装测试的效果
- 桩是简化了的模拟较低层次模块功能的虚拟子程序
- 静态测试最多可查出==70%==的错误
- 等价类划分完成后，就可得出等价类表，它是确定测试用例的基础
- 由因果转换出来的判定表是确定测试用例的基础
- 白盒测试的缺点：不能发现功能需求中的错误；无法检测软件的外部特性
- 软件测试的指导原则（10个）
Chapter 8 软件维护
- 软件维护就是在软件已经交付使用之后为了改正错误或满足新的需要而修改软件的过程
- 软件维护的类型（4）——改正性；适应性；完善性；预防性
- 与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点
- 维护要求表或称软件问题报告表,由申请维护的用户填写
- 软件修改报告，由软件组织内部制订，需要指明的内容：
（1）满足某个维护要求表中提出的 要求所需要的工作量
（2）维护要求的性质
（3）这项要求的优先级
（4）与修改有关的事后数据 - 软件的可维护性是指维护人员理解、改正、改动或改进这个软件的难易程度
- 决定软件可维护性的因素（4）——可理解性；可测试性；可修改性；可移植性；可重用性
- 用户文档至少包含5方面内容：
（1）功能描述——系统能做什么
（2）安装文档
（3）使用手册——如何使用系统常用功能；操作错误时如何恢复和启动
（4）参考手册——用户可以使用的设施及使用方法；解释系统出错信息的含义；最主要的要求是完整，通常使用形式化的描述技术
（5）操作员指南——如何处理使用中出现的各种情况 - 系统文档（3）
（1）从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档
（2）描述系统设计、实现和测试的文档对于理解程序和维护程序极端重要
（3）从概貌到每个方面每个特点，从抽象到具体，有逻辑的介绍系统 - 可维护性复审
（1）在需求分析阶段的复审过程中，应该对将来要改进的部分和可能会修改的部分加以注意并指明；应该讨论软件的可移植性问题，并且考虑可能影响软件维护的系统界面
（2）在正式和非正式的设计复审期间，应该从容易修改、模块化和功能独立的目标出发，评价软件的结构和过程；设计中应该对将来可能修改的部分预做准备 - 测试结束时进行最正式的可维护性复审，称配置复审 。
- 代码复审强调编码风格和内部说明文档这两个影响可维护性的因素
- 软件再工程过程（6）
（1）库存目录分析
（2）文档重构
（3）逆向工程（重新抽象）
（4）代码重构
（5）数据重构
（6）正向工程
Chapter 8 补充
- 为什么软件需要维护？在软件开发完成交付用户使用后，为了保证软件在一个相当长的时期内能够正常运行，就需要对软件进行维护。
- 改正性维护与“排错（调试）”是否是一回事？为什么？不是一个概念。
（1）首先解释调试和改正性维护的定义（调试是作为测试的后继工作而出现的，是当测试发现软件中的错误后，进一步诊断和改正程序中潜在的错误的活动）
（2）调试实际上是一种工具或手段，是可以在程序编码阶段、测试阶段、运行和维护阶段发挥作用。涉及的范围一般是程序本身，程序本省经过调试而发现问题。而但是改正性维护涉及的范围不只包括程序，还有文档和数据，不仅可能修改程序代码，而且可能需要修改设计，甚至需求。
（3）结论：所以改正性维护是在更大范围内工作 - 软件演化与软件衰退的分界点是什么？
（1）维护的成本太高
（2）系统的可靠性不可以接受
（3）在一个合理的时间内，系统不能再适应进一步的变化了
（4）系统性能仍旧超出预先规定的约束条件
（5）系统功能的作用有限
（6）其他的系统能更高、更快、更廉价的做同样的工作
（7）维护硬件的成本高得足以用更便宜、更新的硬件来取代 - 简述软件演化规则的内容
（1）连续的变化
（2）递增的复杂性
（3）程序演化的基本法则
（4）组织稳定性的守恒
（5）熟悉程度的守恒 - 各类维护的优先级：
（1）改正性维护：必须做
（2）适应性维护：做，但可以不必马上做
（3）完善性维护：可根据自身情况决定做否
（4）预防性维护：可以不做 - 软件再工程包括理解软件、改进软件和获取、保存和扩充软件知识等三种
- 用于软件再工程的重构技术有结构化设计技术和软件复用技术
- 软件再工程的风险主要包括过程风险、人员风险、应用问题风险、技术风险、工具风险和策略风险。
- 影响维护工作量的程序特征有系统大小、系统年龄、程序设计语言、数据库技术的应用、先进的软件开发技术、应用的类型、数学模型、任务的难度等。
- 在整个软件维护阶段，以完善性维护所花费的工作量占比最大
- 一个软件产品开发完成投入使用后，常常由于各种原因需要对它做适当的变更。通常把软件交付使用后所做的变更叫做维护。
- 软件工程对维护工作的主要目标是提高软件可维护性，降低维护的成本
- 软件可维护性是指软件能够被理解、改正、适应及增强功能的容易程度
- 可维护性的特性中相互矛盾的是效率和可修改性
- 可维护性的特性中相互促进的是可理解性和可测试性
- 软件可维护性可用下面7个质量特性来衡量，即可理解性、可测试性、可修改性、可靠性、可移植性、可用性和效率
- 在软件维护实施过程中，为了正确、有效地修改程序，需要经历以下3个步骤：分析和理解程序、修改程序和重新验证程序
- 修改程序是决定维护成败和质量好坏的关键。
- 重新验证程序包括静态确认、计算机确认和维护后的验收
- 在软件维护工作的过程中，第一步先确认维护类型
- 不管维护类型如何，大体上要开展相同的技术工作。这些工作包括修改软件设计、修改代码、单元测试、集成测试、确认测试以及验收
- 软件生存期的每个阶段的工作与软件可维护性有密切的关系
- 软件维护困难的主要原因是开发方法缺陷
- 软件维护费用高的主要原因是生产率低
【有些选择题直接提炼出答案识记效果较好，有些选择题则需要所有选项对比，识记效果才好】 - 维护阶段的文档是软件问题报告
- 软件维护的副作用是指因修改软件造成的错误
- 软件可靠性和可使用性的区别：可使用性是在投入使用的点能使用；可靠性是在一段时间内
- 在虚拟存储器的计算机系统上开发软件和减少程序中对文件的读写次数不能提高软件的可移植性
- 使用结构化程序方法和尽量使用高级语言编写程序中对效率要求不高的部分可以提高软件的可移植性
Chapter 9 软件项目管理
- 软件规模估算的两种方法（代码行技术——由历史记录估计实现一个功能所需的源程序行数；功能点
function point技术——交付软件的总功能有多少，功能点和对象点是常用指标） - 工作分解结构（WBS）
明确了 项目范围；确定了项目包含的活动；指明活动对应的里程碑；没有指明活动间的相互依赖关联；无法表示项目中可以并行的部分；还需要其他手段才能产生可行的项目进度计划 - Gantt图能很形象地描绘任务分解情况，以及每个子任务（作业）的开始时间和结束时间，因此是进度集合和进度管理的有力工具
- Gantt图优点：直观简明、容易掌握、容易绘制
- Gantt图缺点（3）：
（1）不能显式描绘各项作业彼此之间的依赖关系
（2）进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象
（3）计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费 - 工程网络（一种图形工具）：能将描绘任务分解情况以及每项活动/作业的开始时间和结束时间；显式地描绘各个作业彼此间的依赖关系
- 工程网络图要求绘制者理解项目中哪些部分可以并行：活动的并行执行还取决于其执行者是否是一个人/单位
- 活动是项目的一部分；里程碑是某个活动完成的标志
- 工程网络的相关计算——估算工程进度；关键路径；机动时间等
- 人员组织：为了成功地完成软件开发工作，项目组成成员必须以一种有意义且有效的方式彼此交互和通信 ——民主制程序员组；主程序员组（专业性，层次性；主程序猿、后备程序猿、编程秘书）；层次式小组【注意对应图形和名称的mapping】
- 软件开发项目的产品数量急剧增加且易被修改和变化。——需要软件配置管理SCM
- 软件配置管理的目的是针对变化、控制变化；
软件配置管理的目标：标识变更；控制变更；确保变更正确地实现；像其他有关人员报告变更
软件配置管理是软件系统发展过程中管理和控制变化的规范 - 基线baseline：已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。（就是通过了正式复审的软件配置项）
- 项目数据库：（1）一旦一个SCI成为基线，就被存放到项目数据库中；（2）项目数据库和变更控制规程相结合，保护着项目的基线
- 风险管理的内容（4）——风险识别；风险分析；风险规划（风险优先级划分/制订风险管理对策）；风险控制
- 软件项目的核心风险
（1）进度安排的先天错误：安排时间和工作量时犯下的错误。对规模的判断失误、预算的彻底失败
（2）需求膨胀：在开发的过程当中，客户的业务领域不可能始终静止不变；从项目的角度来看，需求总是向着膨胀的方向变化；合理的开发逻辑应该考虑到需求变化的可能程度在制订的计划中允许一定限度的改变 - 能力成熟度模型CMM
持续的过程改进基于许多细小的、逐渐发展的步骤，而不是革命性的革新。CMM提出的框架中，将这些步骤组织称为5个成熟度等级，为持续的过程改进提供了基础：（目标是希望软件机构能持续地改进自己的过程）
（1）等级1:初始级（Initial）
（2）等级2：可重复级（Repeatable）
（3）等级3：已定义级（Defined）
（4）等级4：已管理级（Managed）
（5）等级5：优化级（Optimizing）
Chapter 9 补充
- 软件项目组织的原则是尽早落实责任、减少接口、权责均衡；一般有按课题划分的模式、按职能划分的模式；矩阵式形式三种组织结构的模式。
- 软件开发小组的规模不能太大，人数不能太多，一般在2～8人左右为宜
- 软件项目管理的主要职能：制订计划、建立组织、配备人员、指导和检验
- 软件项目的特有性质，使得项目管理存在一定困难（5点）
（1）智力密集，可见性差
（2）单件生产
（3）劳动密集，自动化程度低
（4）使用方法繁琐，维护困难
（5）软件工作渗透了人的因素 - 最常使用的进度管理工具是PERT图；当某一开发项目的进度有可能推迟时，应该分析拖期原因加以补救。
- 软件开发项目配比分析
| 分析条目 | 需求分析 | 设计 | 编码 | 测试 |
|---|---|---|---|---|
| 投入工作量 | 15 | 30 | 15 | 40 |
| 技术人员水平 | 初级 | 高级 | 高级 | 高级 |
| 管理人员数量 | 多 | 中 | 少 | 中 |
Chapter 10 面向对象建模基础
- UML有9种图
- UML类图绘制方法
- 时序图绘制方法
- 协作图绘制方法
- 状态图绘制方法
- 活动图绘制方法
- UML3种扩展机制（标记值；约束；构造型）
- 构造型机制是指在已有的模型元素基础上建立一种新的模型元素，它与现有元素要像差不多，只是多一些特别语义
- 用UML描述系统的5个视图
- Use Case：是用户与计算机之间为达到某个目的的一次典型交互应用
- 场景的特点（4个）
（1）场景是Use Case的真实例子
（2）场景通过举例说明情况，帮助理解问题域，进而归纳Use Case
（3）具体执行一次Use Case，得到一个场景
（4）场景重在可理解性，Use Case重在完整性 - Use Case之间的关系（3个）
（1）包含：两个Use Case ，如果其中一个在其事件流种包含了另一个，那么它们间就有包含关系
（2）扩展：将常规动作放在一个基本Use Case中，将非常规动作放在其扩展Use Case中
（3）泛化：对一般性Use Case做特殊化、细化 - 面向对象分析方法