I、结构化方法
一、需求分析
1．需求分析的概念 第III部分__第11章（需求分析的概念与原则）
1.1 需求的层次
软件需求包括三个不同的层次-业务需求、用户需求和功能需求-也包括非功能需求。
业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，他们在项目视图与范围文档中予以说明。
用户需求（user requirement）文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（scenario）说明中予以说明。
功能需求（functional requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系。
1.2 需求工程
把所有与需求直接相关的活动通称为需求工程。
需求工程中的活动可以分为两大类：需求开发和需求管理。
需求开发包括需求调查、需求分析、需求定义。
需求管理包括需求确认、需求跟踪，需求变更控制。
1.3 需求分析的任务
就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。
通俗的说，需求分析的任务就是准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用《需求规格说明说》规范的形式准确地表达用户的需求。
2．需求分析建模 第III部分__第12章(需求分析建模1)
2.1 ER图 考：画图
2.2 DFD图(L0，L1) 考：画图（画第0与第一层）
数据流图
2.3 DD
数据词典
数据词典与数据流图配合，能清楚地表达数据处理的要求
数据词典精确地、严格地定义了每一个与系统相关的数据元素，并以字典式顺序将它们组织起来，使得用户和分析员对所有的输入、输出、存储成分和中间计算有共同的理解。
词条描述-对于在数据流图中每一个被命名的图形元素，均加以定义，其内容有：名字，别名或编号，分类，描述，定义，位置，其他等。
2.4 加工逻辑说明
对数据流图的每一个基本加工，必须有一个基本加工逻辑说明。
基本加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则
加工逻辑说明必须描述实现加工的策略而不是实现加工的细节。
加工逻辑说明中包含的信息应是充足的，完备的，有用的，无冗余的
用于写加工逻辑说明的工具
结构化英语
结构化英语词汇表由：英语命令动词，数据词典中定义的名字，有限的自定义词，逻辑关系词 IF then else，case of，while do，repeat until等组成
判定表
判定树
3．需求规格说明书（SRS）的主要内容和作用 第III部分__第12章(需求分析建模2)
4．需求分析的评审
二、概要设计
1．设计的概念和原则 第III部分__第13章(软件系统设计1)
1.1 信息隐藏
1.2 抽象化
1.3 模块化（模块的独立性）
1.4 耦合（数据偶合）
1.5 内聚（功能内聚）
2．设计的任务
3．程序的一般结构
4．软件体系结构（变换型、事务型）
三、软件测试
1．测试的目的、原则和对象
2．测试用例设计（测试的策略，为什么？与面向对象测试方法有什么区别？）第III部分__第17章(软件测试)
2.1 白盒测试（语句覆盖、判定覆盖）
2.2 黑盒测试（等价类划分、边界值分析）
3．软件测试策略 第III部分__第18章(软件测试策略)
3.1 单元测试
3.2 集成测试
3.3 确认测试
3.4 系统测试
测试过程按4个步骤进行，即单元测试、组装测试、确认测试和系统测试。
开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
组装测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。
单元测试又称模块测试，是针对软件设计的最小单位-程序模块，进行正确性检验的测试工作。其目地在于发现各模块内部可能存在的各种差错。
单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
1单元测试的内容
在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。
（1）模块接口测试
内部检查：传输参数的数目、属性、单位、次序是否匹配；全程变量的定义是否一致；只做输入的变元有无被修改，等等。
外部检查：打开、结束、关闭文件的操作；文件和属性；I/O错误处理；输出拼写，等等。
（2）局部数据结构测试
数据说明；初始化与缺省值的设置；变量名拼写；数据类型的相容性；上/下溢出及地址异常，等等。
（3）路径测试
重要的执行通路
计算次序问题
不同类型混合运算
初值设置错误
精度问题
表达式错误
循环终止条件错误
（4）错误处理测试
预见出现错误的条件，设置处理。较常见的问题有
输出的错误信息难以理解，不能确定错误位置
描述的错误与实际错误不符
处理之前系统已经干预
处理不正确
（5）边界测试
2单元测试的步骤
模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。
驱动模块，桩模块（存根模块）
组装测试（集成测试、联合测试）
通常，在单元测试的基础上，需要将所有模块安装设计要求组装成为系统。如需要考虑以下问题：
一个模块的功能是否会对另一个模块的功能产生不利的影响。
各个子功能组合起来，能否达到预期要求的父功能。
通常，把模块组装成为系统的方式有两种
一次性组装方式
增殖式组装方式
这种组装方式又称渐增式组装
首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统
在组装的过程中边连接边测试，以发现连接过程中产生的问题
通过增殖逐步组装成为要求的软件系统
自顶向下的增殖方式
自底向上的增殖方式
混合增殖式测试
确认测试又称为有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。
确认测试应交付的文档有：
确认测试分析报告，最终的用户手册和操作手册，项目开发总结报告
1进行有效性测试
有效性测试是在模拟的环境下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。
首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。
通过实施预定的测试计划和测试步骤，确定
软件的特性是否与需求相符；
所有的文档都是正确且便于使用；
同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试。
2软件配置复查
目的是保证
软件配置的所有成分都齐全；
各方面的质量都符合要求；
具有维护阶段所必需的细节；
而且已经编排好分类的目录。
应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。
系统测试
是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
目的在于通过与系统的需求定义作比较，发现软件与系统的定义不符合或与之矛盾的地方。
α测试，β测试
测试种类
功能测试：可靠性测试，强度测试
性能测试
恢复测试
启动，停止测试
配置测试
安全性测试
可使用性测试
可支持性测试
安装测试
过程测试
互联测试
兼容性测试
容量测试
文档测试
II、面向对象方法
一、需求分析
1. 面向对象分析与结构化分析的异同
2．基于场景的建模
2.1 用例图 第IV部分__第20章(面向对象软件工程)
2.2 活动图
3．基于类的建模
3.1 类图 第IV部分__第20章(面向对象软件工程)
3.2 协作图
4．基于行为的建模
4.1 状态图
4.2 时序图
二、概要设计
1. 设计的四个层次
2．子系统的设计方法
2.1水平分解
2.2 垂直分解
3．C/S架构与P2P架构的特点与应用 第IV部分__第22章(面向对象设计1)
子系统层。包含每个子系统的表示，这些子系统使得软件能够满足客户定义的需求
，并实现支持客户需求的技术基础设施。
类和对象层。包含类层次，它们使得系统能够以通用化方式创建并不断逼近特殊需
求，这层也包含了每个对象的设计表示。
消息层。包含使得每个对象能够和其协作者通信的细节，本层建立了系统的外部和
内部接口。
责任层。包含针对每个对象的所有属性和操作的数据结构和算法的设计。
子系统设计通过考虑整体客户需求(用使用实例表示)和外部可观察的事件和状态(
对象—行为模型)而导出;
类和对象设计通过对包含在CRC 模型中的属性、操作和协作的描述的映射得来的；
消息设计由对象—关系模型导出；
责任设计利用CRC 模型中的属性、操作和协作导出。
Peer-to-Peer relationship
Each of the subsystems may call on the others
Response not necessarily immediate不一定立即响应
More complicated than client/server更复杂的
Deadlocks are possible:”Communication cycles” 死锁是可能的:通讯周期
Client/server architectures easier to build
Layered systems do not provide peer-to-peer communication
Peer-to-peer communication is often needed
Example: Database receives queries from application but also sends
notifications to application when data have changed
Most important in peer-to-peer architectures: Protocol between
subsystems
分层系统不提供点对点通信点对点通信往往需要例如：数据库收到查询申请，但还
发出通知时，数据的应用已经改变最重要的点对点架构：子系统间议定书
Often used in database systems:
Frontend: User application (client)
Back end: Database access and manipulation (server)
Functions performed by client:
Customized user interface
Front-end processing of data
Initiation of server remote procedure calls
Access to database server across the network
经常使用的数据库系统： 前端：用户应用程序（客户端） 后端：数据库访问和操
纵（服务器） 履行职能的客户端： 定制用户界面前端处理的数据启动服务器的远
程过程调用访问数据库服务器的整个网络
4．子系统并发问题的处理
4.1 物理并发
4.2 软件并发
5．从分析类过度到设计类的主要方法和步骤
5.1 增加可视性
5.2 增加数据类型
5.3 增加约束条件
6. 软件重用的几种基本形式的比较 第IV部分__第22章(2) 59页
6.1 类库
6.2 框架
6.3 设计模式
库复用的问题是库通常以一组可复用的子例程的形式存在,而不是可复用的设计.
工具包通常也只是促进代码复用,而不是设计复用.
库和工具包复用的关键特征是设计者负责整个产品的控制逻辑.
库或工具包通过提供结合进产品的特定操作的部分设计,对软件开发过程提供帮助.
框架: 构成软件的一个特定类的可复用设计的一组协同类.
应用框架与库或工具包相反,它提供控制逻辑,开发者负责特定操作的设计.
特定应用操作插入的地方通常称为”热点”.
复用一个框架比复用工具包更能使产品开发得更快. 因为:
–多数设计随着框架一起被复用;
–框架的控制逻辑比操作更难设计;
–框架的控制逻辑已得到测试.
框架通常是针对某个特定的问题领域或者某个特定的应用类型而特别设计的.
框架在本质上注重的是总体软件设计的复用.
设计模式是普通设计问题的解决方案,
这类问题以一组交互类的形式出现,
需要由用户根据需要定制这些交互类以形成专门的设计.
带阴影的方框通过线连接起来代表交互类.
阴影的方框内白色方框代表为专门的设计定制的类.
三、软件测试 第IV部分__第23章(面向对象测试)
1．面向对象单元测试与结构化单元测试的比较
2．面向对象集成测试与结构化集成测试的比较
3．面向对象测试用例的设计
传统的测试计算机软件的策略是从“小型测试”开始，逐步走向“大型测试”。
即，从单元测试开始，然后逐步进入集成测试，最后是确认测试和系统测试。
在传统应用中，单元测试集中在最小的可编译程序单位——子程序(如，模块、子
例程、进程)，
一旦这些单元均被独立测试后，它被集成进程序结构中，这时要进行一系列的回归
测试以发现由于模块的接口所带来的错误和新单元加入所导致的副作用，
最后，系统被作为一个整体测试以保证发现在需求中的错误。
在OO 语境中的单元测试
考虑面向对象软件时，单元的概念发生了变化。
封装驱动了类和对象的定义，这意味着每个类和类的实例(对象)包装了属性(数据)
和操纵这些数据的操作(方法或服务)，而不是个体的模块。
最小的可测试单位是封装的类或对象，
类包含一组不同的操作，并且某特殊操作可能作为一组不同类的一部分存在;
不再孤立地测试单个操作(传统的单元测试观点)，而是将操作作为类的一部分。
OO 软件的类测试等价于传统软件的单元测试
和传统软件的单元测试不一样，它往往关注模块的算法细节和模块接口间流动的数
据，
OO 软件的类测试是由封装在类中的操作和类的状态行为所驱动的。
如果类的实现正确，则类的每个实例的行为也应该是正确的。
在OO 语境中的集成测试
因为面向对象软件没有层次的控制结构，传统的自顶向下和自底向上集成策略就没
有意义，
此外，一次集成一个操作到类中(传统的增量集成方法)经常是不可能的，这是由于
“构成类的成分的直接和间接的交互”
对OO 软件的集成测试有两种不同策略:
第一种称为基于线程的测试(thread－based testing)：
集成响应系统的一个输入或事件所需的一组类，每个线程被集成并分别测试，应用
回归测试以保证没有产生副作用。
第二种称为基于使用的测试(use－based testing)：
（1）通过测试那些几乎不使用服务器类的类(称为独立类)来开始系统的构造，
（2）在独立类测试完成后，下一层的使用独立类的类，称为依赖类，被测试。
（3）这个依赖类层次的测试序列一直持续到构造完整个系统。
与传统集成不同，尽可能避免使用驱动程序和桩(stubs)作为替代操作。
OO 软件的测试用例设计
和传统测试用例设计不同，传统测试是由软件的输入—加工—输出视图或个体模块
的算法细节驱动的；
面向对象测试关注于设计合适的操作序列以测试类的状态。
构建独立类的测试用例
没有任何交互的单个类称为原始类,
可以将原始类实例化,并且不必创建其他类的实例就可以使用该原始类的实例.
这样的对象代表了系统中最简单的组件.
测试要在这样的独立类的实现中发现错误.
通常从类的说明中确定测试用例.
类说明可以用多种方式进行描述，包括: OCL、自然语言和状态转换图。
根据前置条件和后置条件 构建测试用例
总体思想：为所有可能出现的组合情况确定测试用例需求。在这些可能出现的组合
情况下，可以满足前置条件，也能够达到后置条件。
创建测试用例来表达这些需求.
根据这些需求，可以创建拥有特定输入值（包括常见值和边界值）的测试用例，并
确定它们的正确输出。
再增加测试用例来阐述违反前置条件时所发生的情况。
根据状态转换图 构建测试用例
状态转换图以图例的形式说明了与一个类的实例相关联的行为。
状态图中每一个转换都描述了一个或多个测试用例需求。
状态的边界值取决于状态相关的属性值的范围。
可以根据属性值来定义每一个状态。
III、软件工程过程
一． 目标
1． 掌握软件工程过程的基本概念
1) 软件工程是一种层次化的技术。
2) 支持软件工程的根基就在于对质量的关注。
3) 软件工程的基础是过程层。
4) 软件工程过程是将技术层结合在一起的凝聚力，使得计算机软件能够合理和及时地开发。
5) 过程定义了一组关键过程区域的框架。
与软件工程相关的工作可分为三个一般的阶段：
（1）定义阶段：集中于“做什么”；
三个主要任务：系统工程、项目计划、 需求分析
（2）开发阶段：集中于“如何做”；
三个特定任务：设计、编码、测试
（3）支持阶段：关注于“变化”
四类可能遇到的变化：纠错、适应、增强、预防
2． 掌握几种常见的软件开发过程模型、特点及应用
编码修复模型
它几乎不执行任何预先的计划，该模型的使用者很快就进入了所开发产品的编码阶段。
典型的情况是，完成大量的编码，然后测试产品并且纠正所发现的错误。
编码和测试工作一直持续到产品开发工作全部完成并将产品交付给客户。
线性顺序模型
线性模型也称为传统生存周期或瀑布模型。
传统生存模型是软件工程中应用最广泛的过程模型，在软件工程中占有肯定和重要的位置。
它提供了一个模板，使得分析、设计、编码、测试和支持的方法可以在该模板的指导下应用。
原型实现模型
从需求收集开始，开发者和客户在一起定义软件的总体目标，标识已知的需求并且规划出需要进一步定义的区域。
然后是“快速设计”，它集中于软件中那些对客户可见的部分的表示，这将导致原型的创建。
由客户评估并进一步精化待开发软件的需求。
逐步调整原型使其满足客户的需求，这个过程是迭代的。
快速应用开发（RAD）模型
快速应用开发（RAD）是一个增量型的软件开发过程模型，强调极短的开发周期。
RAD模型是线性顺序模型的一个“高速”变种，通过使用构件的建造方法赢得了快速开发。
RAD过程强调的是复用，复用已有的或开发可复用的构件。
实际上RAD采用第四代技术。
演化软件过程模型
瀑布方法假设当线性序列完成之后就能够交付一个完善的系统。
原型实现模型设计成帮助客户（或开发者）理解需求，它并不是交付一个最终的产品。
演化模型是迭代的，它的特征是使软件工程师逐渐地开发逐步完善的软件版本。
3． CMM的基本概念及软件过程改进
CMM（Capability Maturity Model）是用于衡量软件过程能力的事实上的标准，同时也是目前软件过程改进最好的参考标准。
美国卡内基-梅隆大学软件工程研究所（SEI）研制.
1) 软件工程研究所(SEI)提出了-个综合模型，定义了当一个组织达到 不同的过程成熟度时应该具有的软件工程能力。
2) 为了确定一个组织目前的过程成熟度，SEI 使用了一个五级的评估方案，即能力成熟度模型CMM.
3) 该模型定义了在不同的过程成熟度级别上所需要的关键活动.
4) CMM重要概念
a) 5个成熟度等级：Initial, Repeatable, Defined, Managed, Optimizing
提高软件过程能力的实践通称为软件过程改进（Software Process Improvement）。软件过程改进的根本目的是：提高质量、提高生产率并且降低开发成本。
二． 主要知识点 第I部分__第2章
1) 瀑布模型
1) 阶段间的顺序性和依赖性；
2) 文档驱动性；
3) 严格阶段评估；
4) 开发初期需要清楚全部需求；
5) 开发周期长、风险大。
2) 原型模型
1. 原型可以作为标识软件需求的一种机制；
2. 原型作为第一个系统，常常是抛弃的；
3. 开发过程的交互性和迭代性 ；
4. 充分发挥用户在软件开发初期的作用；
5. 开发周期较短、成本较低、风险较小。
3) 增量模型
1) 过程渐进性：每次提交一个满足用户需求子集的增量构件；
2) 增量模型强调每一个增量均发布一个可操作的产品。
3) 能在短时间内向用户提交可使用的软件；
4) 软件系统的体系结构必须具有高度的开放性和可扩充性；
5) 在逐步增加产品功能的过程中有充裕的时间学习和适应新的功能。
4) 螺旋模型
1) 螺旋模型的每一个周期都应用了原型模型排除风险，在确定了原型之后，又启动生命周期模型继续过程的演化；
2) 软件开发的每个阶段都是一次迭代，每旋转一个圈就前进一个层次，得到一个新的版本；
3) 强调可选方案和约束条件有利于软件重用；
4) 减少测试过多或不足带来的风险；
5) 维护看成是模型的另一个周期；
6) 需要开发人员有丰富的风险评估经验和相关专门知识。
5) 并发模型
1) 并发模型定义了一系列事件，对于每一个软件工程活动，它们触发从一个状态 到另一个状态的变迁。
2) 并发模型常常被用于作为客户/服务器应用的开发范型。
6) 构件模型
1) 基于构件的开发模型融合了螺旋模型的许多特征。
2) 它本质上演化型，要求软件创建的迭代方法。
3) 利用预先包装好的软件构件（或称类）来构造应用的。
4) 它导致软件复用。
7) MSF模型
MSF(Microsoft solution framework)是一套大型系统开发指南,它描述了如何用组队模型、过程模型和应用模型来开发Client/Server结构的应用程序,是在微软的工具和技术的基础上建立并开发分布式企业系统应用的参考。
8) RUP模型
1) 开发复用。减少开发人员的工作量，并保证软件质量；
2) 项目初期可降低风险；
3) 对需求进行有效管理；
4) 可视化建模；
5) 使用组件体系结构，使软件体系架构更具弹性；
6) 贯穿整个开发周期的质量核查；
7) 对软件开发的变更控制。
9) 敏捷模型
敏捷软件开发宣言，认为：
1) 个体和交互 胜过 过程和工具
2) 可以工作的软件 胜过 面面俱到的文档
3) 客户合作 胜过 合同谈判
4) 响应变化 胜过 遵循计划
虽然右项也具有价值，但我们认为左项具有更大的价值。
IV 软件项目管理
一、 软件项目规模的度量
1． 基于代码行
1.1 LOC
1.2 KLOC
2． 基于功能点
二、 软件项目计划和跟踪
1. 任务网络图
2. WBS
3. 甘特图
4. PERT估算、基于FP的估算
5. 挣值分析
5.1 BCWS
5.2 ACWP
5.3 BCWP
5.4 项目费用偏差CV
5.5 项目进度偏差SV
三、 软件项目的配置管理
1. 版本控制
2. 配置项的概念
3. 基线的概念