软件工程概述
SE 的目的和方法
目的：生产出高质量软件
方法：面向对象开发的各种模式、结构化开发的模式、基于过程的模式、分布式的开发模式
说明错误、故障、失效的含义与联系
当人们在进行软件开发活动的过程中出错时（称为错误），就会出现故障
单个错误可能产生多个故障，并且故障可能驻留在任何开发或维护的产品中
失效是指系统违背了它应有的行为
故障是系统的内部视图，这是从开发人员的角度看待系统；而失效是系统的外部视图，它是用户所看到的问题
软件质量应从哪几个方面来衡量
产品的质量、过程的质量、商业价值
现代软件工程大致包含的几个阶段及各个阶段文档
需求分析：SRS（软件需求规格说明书）
系统设计：SAD（系统结构图）
程序设计：功能模块算法与数据描述
程序实现：源代码和注释
单元测试：功能模块与性能测试测试报告
集成测试：SAD 测试报告
系统测试：SRS 测试报告
系统交付：用户手册和操作手册
维护：维护报告
重用、抽象的概念
重用：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去
抽象：是在某种概括层次上对问题的描述，使得我们能够集中于问题的关键方面而不会陷入细节
过程和生命周期的建模
什么是软件过程
可以将一组有序的任务称为过程：它设计活动、约束和资源使用的一系列步骤，用于产生某种想要的输出
软件过程的重要性
通用性：在一系列活动中保持一致性和结构性
自我指导性：分析、检查、了解、控制和改进活动
软件生命周期
问题定义及规划阶段
需求分析/评审阶段
软件设计阶段
软件编码阶段
软件测试阶段
软件运行维护阶段
瀑布模型的各阶段文档
需求分析：《SRS》软件需求规格说明书
系统设计：《SAD》系统设计文档
程序设计：模块功能算法和数据描述文档
编码：源程序和注释
单元测试和集成测试：单元测试报告
系统测试：系统测试报告
验收测试：验收测试报告
运行与维护：维护报告
瀑布模型的优缺点
优点：简单
缺点：它不能反映实际的代码开发方式
原型的概念
一个部分开发的产品，它使客户和开发人员能够对计划开发的系统的相关方面进行检查，以决定它对最终产品是否合适或恰当
分阶段开发模型的含义
系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中
分阶段开发模型的基本分类及特点
增量式开发：系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集
迭代式开发：系统开始就提供了整体功能框架，后续版本陆续增强各个子系统，最后版本使各个子系统的功能达到最强性能
螺旋模型四个象限的任务
第一象限：评估可选方案及风险
第二象限：确定目标、可选方案及约束
第三象限：计划
第四象限：开发与测试
什么是UP、 RUP、进化式迭代等市场流行的过程模型
UP：统一过程，用例驱动的、以基本架构为中心的、迭代式和增量性的软件开发过程框架。重复一系列生命期（开始阶段、确立阶段、构建阶段和移交阶段），这些生命期构成了一个系统的开发期寿命。每个生命期都以向客户推出一个产品版本而结束
RUP：是 IBM 提供支持和包装的 UP 系统。
进化式迭代：开发被组织成一系列固定的短期小项目；每次迭代都产生经过测试、集成并可执行的局部系统；每次迭代都具有各自的需求分析、设计、实现和测试；随着时间和一次次迭代，系统增量式完善
计划和管理项目
什么是项目进度？活动？里程碑？
项目进度：通过列举项目的各个阶段，把每个阶段分解成离散的任务或活动，来描述特定项目的软件开发周期
活动：项目的一部分，它在一段时间内发生
里程碑：活动的完成，某一特定的时刻
如何计算软件项目活动图的关键路径？
活动图：描述活动和相互依赖关系，其中节点是项目的里程碑，线条代表所涉及的活动
根据每个活动持续时间的估算, 关键路径将能够标明或计算出完成整个项目所需的最少时间的路径
冗余时间 = 最迟开始时间 - 最早开始时间
关键路径上的冗余时间为 0，项目完成时间受关键路径上的活动影响
软件项目团队组织的基本结构
首席程序员
助理首席程序员
高级程序员、资料管理员、行政部门、测试团队
初级程序员
COCOMO 模型的三个阶段
阶段一：项目建立原型以解决涉及用户界面、软件和互动、性能或技术成熟度的高风险问题
阶段二：设计者必须探索替代性的结构和操作概念
阶段三：项目正在开发中，软件已部分实施
什么是软件风险？
在软件生产过程中不希望看到的、有负面结果的事件
主要的风险管理活动有哪些？
风险评价：风险识别、风险分析、风险优先级分配
风险控制：风险降低、风险管理计划、风险化解
降低风险的策略
通过改变性能或功能需求，避免风险
通过把风险分配到其他系统中，或者购买保险以便在风险成为事实时弥补经济上的损失，从而转移风险
假设风险会发生，接受并用项目资源控制风险
获取需求
需求的含义是什么？
是对期望的行为的表达
确定需求的过程是什么？
引发：收集用户需求
分析：理解和建模期望的行为
规格说明：文档化要开发的软件系统的行为
确认：检查我们的规格说明是否与用户的需求向匹配
输出——>软件需求规格说明书（SRS）
获取需求时，若有冲突发生时，如何根据优先级进行需求分类
绝对要满足的需要（必需的）
非常值得要的但并非必需的需求（值得要的）
可要可不要的需求（可选的）
需求文档分类
需求定义：客户想要的每一件事情的完整列表
需求说明（SRS）：将需求重新陈述为关于要构建的系统将如何运转的规格说明
功能性需求与非功能性需求的区别
功能需求：根据要求的活动（如对输入的反应、活动发生时每一个实体之前的状态和之后的状态）来描述需要的行为
非功能性需求/质量需求：描述一些软件解决方案必须拥有的质量特性，如快速的响应时间、易使用性、高可靠性或低维护代价
如何区分设计约束和过程约束？
设计约束：已经做出的设计决策或限制问题解决方案集的设计决策
过程约束：对用于构建系统的技术和资源的限制
DFD 图的构成及画法
建模功能以及从一个功能到另一个功能的数据流
一个泡泡表示一个加工或功能，它转换数据
箭头表示数据流，其中，进入泡泡的箭头表示其功能的输入，从泡泡出去的箭头表示其功能的输出
单个计算使用之外的持久性数据保存在数据存储中，它是一个正式的库或信息库，标识未两个平行的条
数据源或者数据接收器表示为矩形，称为参与者：提供输入数据或接收输出结果的实体
设计体系结构
什么是软件体系结构？设计模式？设计公约？设计原则？
体系结构：用以解释如何将系统分解为单元以及这些单元又如何关联，还描述这些单元的所有外部可见特性
设计模式：一种针对单个软件模块或少量模块而给出的一般性解决方案，它提供较低层次的设计决策
设计公约：一系列设计决策和建议的集合，用于提高系统某方面的设计质量
设计原则：描述的是一些良好设计的特征，而不是如何进行设计的说明性建议
软件设计过程模型的几个阶段
建模：尝试可能的分解
分析：分析初步的体系结构
文档化：记录体系结构决策
评审：检查体系结构是否满足需求
输出——>软件体系结构文档（SAD）
设计用户界面应考虑的问题
确定谁将与系统进行交互
开发系统可能执行任务的每种方式的场景
设计用户命令的层次
细化用户与系统交互的时序
设计层次中相关的类，以实现用户界面设计决策
把用户界面类集成到整个系统的类层次中
耦合与内聚的概念
耦合：两个软件部件之间的相互关联程度
内聚：软件部件内部各组成成分的关联程度
耦合的基本分类
非直接耦合：模块相互之间没有信息传递
数据耦合：模块间传递的是数据
特征耦合：模块间传递的是数据结构
控制耦合：模块间传递的是控制量
公共耦合：不同模块访问公共数据
内容耦合：一个模块直接修改另一模块
内聚的基本分类
偶然性内聚：不相关的功能，过程，数据等出现在同一个部件中
逻辑性内聚：逻辑上相关或相似的功能或数据放置在同一个部件内
时间性内聚：部件各部分要求在同一时间完成
过程性内聚：各部分有特定次序
通讯性内聚：各个部分访问共享数据
顺序性内聚：各部分有输入输出关系
功能性内聚：各部分组成单一功能
复审的概念
概念设计复审：与客户和用户一起审查概念设计
技术设计复审：向开发者介绍技术设计
程序设计复审：程序员在实施前获得对其技术设计的反馈
设计复审的重要性
加强和鼓励在项目中使用一种共同的编码风格，发现自动测试发现不了的错误
设计模块
什么是设计原则
把系统功能和行为分解成模块的指导方针
OO 设计的基本原则
单一职责原则（SRP）
开闭原则（OCP）
里氏替换原则（LSP）
依赖倒置原则（DIP）
接口分隔原则（ISP）
OO 开发的优势
从描述语言的角度：用相同的术语（类、对象、接口、方法、属性和行为）描述问题和解决方案
从软件过程的角度：从提出需求、高层设计、低层设计、编码到测试，所有过程都使用相同的语义结构
OO 开发过程的步骤
OO 需求分析
OO 高层设计
OO 底层设计
OO 程序设计
OO 测试
用例图的组成和画法
UML 用例图类似于顶层的数据流图，它根据系统和系统的环境之间的交互，描述可观察到的、用户发起的功能
大的方框表示系统的边界
方框外的小人描绘的是参与者，包括人和系统
方框之内的椭圆是用例，表示必需的主要功能及其变种
参与者和用例之前的线表明参与者参与了该用例
如果存在一个若干用例共有的步骤序列，则可以将该序列抽取出来，形成一个子用例，以备基用例调用，如同过程调用一样。我们从基用例到它的所有子用例都画一条虚线箭头，并且用构造型 <<include>> 来注解这些箭头
一个用例还可以附加上一个扩充的子用例，他在该用例的后面增加功能。我们从扩充子用例到基用例或一条虚线箭头，并用构造型 <<extend>> 注释
绘制类图的步骤
确定类和属性
确定行为
绘制
类图的结构
类名：定义一个类
属性：用名称、类型、初始值来描述它
操作：用名称、参数列表、返回类型来描述它
类图中各个类之间的基本关系以及画法
继承：直线 + 空心三角箭头，子类指向超类
包含：直线 + 折线箭头，指向被包含的类（可能是双向的甚至指向本身）
聚合（成员对象可以脱离整体对象存在）：在包含箭头的尾部加一个空心菱形
组合（整体对象不存在时，成员对象也会消失）：在包含箭头的尾部加一个实心菱形
依赖（某个类的方法使用另一个类的对象作为参数）：虚线 + 折线箭头
接口实现：虚线 + 空心三角，类指向接口
UML 图示结构的基本用途
需求过程：
工作流程图：建立对象模型——概念类图
用例图：通过描述系统必须执行的一般过程对系统进行描述
类图：完善或细化或重写概念类图
对象图：解释每一个对象
活动图：描述了业务活动的工作流过程模型
状态图：显示一个对象可以采取的所有状态
顺序图：展示了对象之间的消息流，将需求中事件的非正式描述形式化
协作图：使用对象和序列信息来显示对象之间的事件流
包图：显示类是如何被划分为模型的
构建图：说明了运行时的构件以及它们之间的交互
部署图：说明了如何为构件分配计算资源
编写程序
一般性的编程原则应该从哪三个方面考虑？
控制结构，算法，数据结构
在编写程序内部文档时，应添加什么注释信息？
头注释块：摘要信息（用于识别程序，并描述数据结构、算法、控制流）
其他程序注释：其他解释（不包括HCB）以帮助读者理解源代码的所有意图。
有意义的变量名和语句标记：表达特定的意义或用途
安排格式以增强理解：缩进和间距等
数据文档化：包括数据结构及其用途的说明
什么是极限编程（XP）？什么是派对编程？
极限编程：适应环境变化和需求变化，充分发挥开发人员的主动精神
派对编程：两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色
测试程序
产生软件缺陷的原因？
规格说明可能是错误的，或者遗漏了某个需求
对于指定的硬件和软件，规格说明中可能包含不可能实现的需求
系统设计中可能包含故障
程序设计中可能包含故障
程序代码可能是错误的
故障类型有哪些？
算法故障：由于处理步骤中的某些错误，使得对于给定的输入，构件的算法或逻辑没有产生适当的输出
计算故障和精度故障：一个公式的实现是错误的，或者计算结果没有达到要求的精度
文档故障：文档与程序的实际做的事情不一致
压力故障或过载故障：填充数据结构时超过了它们规定的能力
能力故障或边界故障：系统活动到达指定的极限时，系统性能会变得不可接受
计时故障或协调故障：协调事件的代码不适当
吞吐量故障或性能故障：系统不能以需求规定的速度执行
恢复故障：系统遇到失效时，不能从失效中恢复
硬件和系统软件故障：所提供的硬件或系统软件实际上并没有按照文档中的操作条件和步骤运作
标准和过程故障：不遵循组织机构的标准和过程
什么是正交缺陷分类
故障被分类不同类别，这些类别共同勾画出开发过程的哪些部分需要关注，因为它们是产生很多故障的原因
测试的各个阶段及其任务
单元测试：针对设计预期的输入类型，构件能否能适当的运作
集成测试：验证系统构建是否能够按照系统和程序设计规格说明中描述的那样共同工作的过程
功能测试：对系统进行评估，以确定集成的系统能否确实执行了需求规格说明中描述的功能
性能测试：将系统与这些软件和硬件需求的剩余部分进行比较
验收测试：根据客户的需求描述对系统进行检查
安装测试：确保系统将按照它应该的方式来运行
黑盒、白盒的概念
黑盒测试：测试人员在完全不了解程序内部的逻辑结构和内部特性的情况下，只依据程序的需求规格及设计说明，检查程序的功能是否符合它的功能说明
白盒测试：以测试对象的内部结构为基本依据，手工或自动的展开各种测试
集成测试主要方法的分类
由底向上集成测试
自顶向下集成测试
一次性测试
三明治测试
驱动模块、桩模块的概念
如驱动模块: 代替上级模块传递测试用例的程序
桩模块：代替下级模块的仿真程序，用于模拟测试时缺少构件时的活动
传统测试和 OO 测试有何不同？
传统测试：系统改变→原测试案例+新测试案例
OO测试：单元测试比较容易，集成测试涉及面更广
OO 测试有何困难
需求验证缺乏工具支持。（很多时候依赖人工）
测试工具生成的测试用例，处理 OO 模型中的对象和方法时，其针对性不强。（某些 OO 关系是测试工具本身搞不清楚其内在逻辑关系的）
传统的测试方法（如环路复杂度等）在评价 OO 系统的规模和复杂性时，还不是很有效。
对象的交互是 OO 系统复杂性的根源，传统的测试方法和根据作用有限。
测试系统
系统测试的主要步骤
功能测试
性能测试
验收测试
安装测试
什么是回归测试？
用于新的版本或发布的一种测试，以验证与旧版本或发布相比，它是否仍然以相同的方式执行相同的功能
功能测试的含义
检查集成的系统是否按照需求中指定的那样执行它的功能
功能测试的基本指导原则
功能测试的测试用例是由需求定义的功能说明部分转化而来.
测试用例不应产生冗余
测试用例应能发现需求中不完整和不明确的方面
性能测试的含义
将集成的构件与非功能系统需求进行比较。这些需求包括安全性、精确性、速度和可靠性，它们约束了系统功能的执行方式
性能测试的主要分类
压力测试：在短时间内加载极限负荷, 以验证系统能力
容量测试：验证系统处理巨量数据的能力
配置测试：构建测试用例对系统软硬件的各种配置进行测试
兼容性测试：测试接口
回归测试
安全性测试
计时测试
环境测试
质量测试
恢复测试
维护测试
文档测试
人为因素测试
验收测试概念
客户也要测试系统，以确保它符合他们对需求的理解
验收测试的分类
基准测试：客户准备一组代表实际安装后系统运作的典型情况的测试用例
试验性测试：在试验的环境中安装系统，依赖系统的日常工作来测试所有的功能
并行测试：新系统与先前版本并行运转，用户逐渐地适应新系统，但是继续使用与新系统的功能相同的老系统
什么是 α 测试和 β 测试？
在客户进行实际的试验性测试之前先“试验”这个系统，这样的内部测试称为 α 测试，而客户的试验称为 β 测试。
什么是安装测试？
在用户环境中测试（解决由开发环境和用户环境之间的差异引起的问题）