软件工程复习知识点

第一章 软件工程概述

1、四种图

测试用例图：设计一个场景，软件在场景内运行，获得设计的执行结果。
类图：用图形显示模型的静态结构以及之间的关系。
时序图：通过图形描述对象之间发送消息的时间顺序，来显示他们之间的动态协作。
流程图：用图形描述算法和思路等。

2、计算机系统

是指适当的组织在一起的一系列系统元素的集合，这些系统元素互相配合、相互协作，通过对信息的处理而完成预先定义的目标。

计算机系统组成：

软件、硬件、人员、数据库、文档、过程。

计算机分为四个发展阶段:

	1．电子管计算机
	2．晶体管计算机
	3．中小规模集成电路计算机
	4．超大规模集成电路计算机

3、软件危机：

用户和开发人员信息不对等，计算机更新换代等问题引起软件开发目标和结果不匹配等问题。

产生原因：

（1）与软件本身的特点有关
（2）与软件开发与维护的方法不正确有关
1.忽视软件需求分析的重要性
2.认为软件开发就是写程序并设法使之运行（程序、文档和数据等）
3.轻视软件维护
解决办法：促进沟通交流和协作，将目标与结果尽可能匹配，用工程的角度看待软件开发的过程。

4、软件工程：

是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，是解决软件危机的方法方式，将正确的开发经验和技术以及维护方法结合起来。(PS：一套有效的开发软件和维护软件的方法)
IEEE：软件工程是（1）将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中；（2）（1）中所述方法的研究。

软件工程的基本原理 ：

（分阶段，监督和控制质量，写文档，现代软件技术应用，高效，软件开发是动态发展的。）
用分阶段的生命周期计划严格管理
坚持进行阶段评审
实行严格的产品控制
采用现代程序设计技术
结果应能清楚地审查
开发小组的人员应该少而精
承认不断改进软件工程实践的必要性

软件工程包括两方面的内容：

1.技术（软件工程方法学）：通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称为范型。
2.管理：通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。

软件工程方法学3要素：

（1）方法：是完成软件开发的各项任务的技术方法，回答“怎样做”的问题；
（2）工具：是为运用方法而提供的自动的或半自动的软件工程支撑环境
（3）过程：需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

1. 传统方法学(生命周期方法学或结构化范型)——强调自顶向下
2. 面向对象方法学——强调主动地多次反复迭代（4个要点：对象，类，继承（关系重用），消息（数据的传递））
   面向对象与传统方法学对比：面向对象是迭代执行而传统的则是从顶向下依次执行不可反复。
   传统方法和面向对象是软件工程的程序设计方法中最本质的思想方法。
   传统方法以过程为中心，强调过程，功能和模块化，适用于数据少而操作多的问题；面向对象以对象为中心，强调对象，适用于以数据为主而操作较少的系统。

5、软件生命周期三个时期八个阶段：

软件定义（问题定义，可行性研究，需求分析）；软件开发（概要设计，详细设计，编码和单元测试，综合测试）；软件维护（运行维护）

6、软件过程：

开发的步骤，运用方法的顺序（思想）和各种文档资料的书写（思想的总结实现）等。（软件过程：是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。
为获得高质量的软件产品，软件过程必须科学、有效。）

7、瀑布模型:

（顺序，规范，文档）
优点：采用规范的方法；严格规定每个阶段提交的文档；要求每个阶段交出产品必须经过验证。
a、按照软件工程的生命周期，自上而下依序完成，并且严格的检验每个阶段。
b、特点：自上而下的顺序性和依赖性；代码的推迟实现；严格的文档规范来保证质量。
c、优缺点和适用性：优点是保证开发文档的规范性，有质量保证和正确性的保证。
缺点是缺少实践检验。适用需求相对确定，周期短，技术成熟的软件工程。

8、快速原型模式：

a、无回溯，把大的功能模块细分子集模块，快速建立原型，完成软件开发。
b、本质特点是：快速。快速原型模型不带反馈环，软件产品的开发基本上是线性顺序进行的。

根据原型的不同作用，有三类原型模型：
探索型原型——用于开发的需求分析阶段
实验型原型——主要用于设计阶段
演化型原型——用于及早向用户提交一个原型系统
快速原型模型的运用方式：
抛弃策略——探索型和实验型采用此策略
附加策略——演化型快速原型采用此策略

9、增量模型：

a、把相互作用的模块按照时间顺序依次完成。
b、优点和难点：人员灵活成本低，核心功能可提前产品化，用户使用过程可学习培养。难点是架构复杂，整体和增量模块独立化之间的矛盾，集成难度高。
c、适用范围：开始成本低人员少，增量功能多，需求经常改变的软件开发过程

10、螺旋模型：

a、综合各种模型降低风险。（基本思想：使用原型及其他方法来尽量降低风险。把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。）
b、优点和缺点：风险低，提前预测。软件原型可重用，减少测试，并且维护和开发整合在一起。缺点是需要较高的风险预测经验，迭代复杂时开发周期加长。
c、适用范围：大型高风险项目或内部大型项目。

11、其他模型：

喷泉模型和形式化方法模型，RUP统一过程等。

第二章 可行性研究

1、可行性研究报告

找到问题计算成本（计算效益率）

2、可行性研究目的：

不是解决问题，而是确定问题是否值得去解决。（实质：进行一次大大压缩简化了的系统分析和设计的过程， 也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。）（系统分析员需要具备抽象（得到模型）分析的能力。）

3、可行性包括：

技术，经济，操作，运行和法律等方面的可行性。

4、可行性研究过程（循环）：

（1）复查系统规模和目标(问题定义)
（2）研究当前系统
（3）导出新系统的高度逻辑模块（目标系统逻辑研究）
（4）进一步定义问题
在循环完1234后 （5）导出和评价供选择的解法（得出结论，包括剔除不可行的和计算成本效益后保留结论及进度表）
（6）推荐行动方针
（7）草拟开发计划
（8）书写文档提交审查

5、可行性分析报告之系统流程图

图形化系统逻辑模型。

6、数据流图

是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。（对信息的加工处理的图形化描述，包括输入，传输和输出。）
（补充：数据流图中的事务应该具有独占性，防止产生冲突——数据库事务管理的来源）
数据源点/终点：通常是人或部门，可重复表示；
处理：一个处理框可以代表一系列程序、单个程序或程序的一个模块；
数据存储：可以表示一个文件、文件的一部分、数据库的元素或记录的一部分等，数据存储是处于静止状态的数据；
数据流：描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件 ，数据流是处于运动中的数据。

7、数据字典：

数据信息的集合，也就是对数据流图中包含的所有元素的定义的集合。（数据流图和数据字典共同构成系统的逻辑模型）
组成：数据流、数据流分量(即数据元素)、数据存储、处理
记录数据元素的下列信息：一般信息、定义、使用特点、控制信息、分组信息
定义数据方法：对数据指定向下分解
数据组成方式(三种基本类型)：
顺序 以确定次序连接两个或多个分量；
选择 从两个或多个可能的元素中选取一个；
重复 即把指定的分量重复零次或多次。
附加类型：可选 即一个分量是可有可无的(重复零次或一次)。
符号： =意思是等价于(或定义为)； +意思是和(即，连接两个分量)；
［ ］意思是或(即，从方括弧内列出的若干个分量中选择一个)，通常用“|”号隔开供选择的分量；
{ }意思是重复(即，重复花括弧内的分量)；常常使用上限和下限进一步注释表示重复的花括弧。
( )意思是可选(即，圆括弧里的分量可有可无)。

8、 成本/效益分析的目的

正是要从经济角度分析开发一个特定的新系统是否划算，从而帮助客户组织的负责人正确地作出是否投资于这项开发工程的决定。
成本估计法：代码行技术，任务分解技术，自动估计成本技术（成本工具计算软件的使用）

9、成本/效益分析：

三个组成部分——成本估计，运行费用，经济效益；用来计算开发成本效益是否值得进行开发。

10、成本/效益分析方法：

1、货币的时间价值2、投资回收期3、纯收入4、投资回收率

第三章 软件需求分析

（一、重要性）

1、软件需求分析决定软件开发是否成功。（最重要的）

a、是开发人员理解业务的前提条件。
b、项目进度估算的前提条件。
c、是用户和开发人员之间的桥梁，必须双方都确定才进行后续开发。
d、需求分析是基线，是开发的前提条件。（房子的地基）
e、也是软件测试阶段的前提条件。

（前提条件和桥梁）
（软件需求是决定软件开发是否成功的一个关键因素
需求分析可以帮助开发人员真正理解业务问题
需求分析是估算成本和进度的基础
需求分析可以避免建造错误的系统，从而减少不必要的浪费
软件规格说明有助于开发人员与客户在“系统应做什么”问题上达成正式契约
需求分析形成了软件开发的基线，有助于管理软件的演化和变更
软件需求是软件质量的基础，为系统验收测试提供了标准。 ）
（项目经理，程序员，测试员都需要看需求分析文档，整个开发过程起点是需求分析文档）（开发人员和用户之间的桥梁，沟通的结果通过需求分析文档确定）（软件需求分析是软件生存期决定性的一步，是软件开发的基础。）

（二、定义和概念）

2、软件需求分析

就是确定用户问题的解决条件或能力，以及达到文档（合同等）规定的内容的条件或能力（定义）
软件需求分析：将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的需求规格说明的过程。

3、需求分析的任务

是准确的回答“系统必须做什么？”——用户的核心需求怎么满足。

（三、具体的过程）

4、需求分析基本流程：

a、问题分析
b、功能性需求（业务需求、用户需求、功能需求）
c、非功能性需求（过程需求、产品需求、外部需求）
~以上一般用户看的懂~
d、系统需求分析（结构化语言和UML等形式），面向开发人员，专业人员阅读。

（四、过程中的要求）

5、系统的综合要求：

1。功能需求，2.性能需求，3.可靠性、可用性、安全性、保密性等需 求，4.出错处理需求（容错性），5.接口需求（扩展性)，6.约束，7.逆向需求（软件不可 做的），8.将来可能提出的要求（功能预测）

6、分析系统的数据要求：

图形化(层次方框图HIPO和Warnier图)和数据结构规范化

7、逻辑模型：

图形化（系统图，数据流图,E-R，UML等），常用的抽象方法：面向结构化分析方法（SA），面向数据结构(JSP)方法，面向对象分析方法（OOA）；注意一般是总分形式（功能，子功能，继续细分）

8、需求获取的关键

在于通过与用户的沟通和交流，收集和理解用户的各项要求。
用户沟通方式：访谈，需求讨论会，问卷调查，现场考察，快速建立软件原型（原型化方法），设计用例等

（五、过程的详细步骤）

9、需求规格说明书（开发人员文档的起点）

内容包括：功能性描述，外部接口(UI，开放接口等)，非功能性描述——性能，特性，设计约束，运行环境要求
编写原则如下：(做什么，自然语言，明确的，非主观的)
1、只写做什么，不写怎么做
2、必须说明运行环境(客观条件)
3、明确的，用户和开发人员都可理解的语言描述。
4、详细到功能可编写测试用例进行测试。
5、应该是简短的非模糊的，不能有和，或，等等等词汇。
6、不应该由开发者主观确定功能。（用户需求确定）

10、实体-联系图（E-R图）：三要素

数据对象（矩形框），数据对象的属性（椭圆框），关系（菱形框，1:1,1:n,m:n）用直线连接（必考题）

11、数据规范化：

（减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程）
1、第一范式，在同一表无重复字段
2、第二范式，在同一表无重复字段且有唯一关键字(索引)
3、第三范式，在同一表无重复字段且有唯一关键字，而且非关键字字段之间无联系。

12、层次方框图（H图）：

用树状多层次矩形框描述数据的层次结构（功能结构）

13、HIPO图：H图+IPO图

H图描述整个系统的设计结构和模块之间的关系，H图画n层，每层根据经验一般为3—10个模块，层次（n层）按具体情况定；IPO图描述某一特定模块内部的处理过程和输入输出关系。（HIPO图一般有1张H图，多张 IPO图组成 ）
IPO图四种属性：输入输出，逻辑功能（业务处理），运行程序和内部数据

14、需求分析验证软件需求正确的四方面：

一致性，完整性，现实性，有效性。
需求规格说明要求：正确性，无二义性，完整性，可验证性，一致性，可修改性和可跟踪性。

第四章 形式化说明技术

1、形式化方法：

数学化方法进行系统规格说明书的描述。
(非形式（自然语言），半形式（数据流图、实体-联系图），形式化（有穷状态机、 Petri网、 Z语言）三种方法应该混合并且综合使用，选择合适的，而不是选择唯一的)

2、有穷状态机：

利用数学化方法描述有限的状态转换集合。（三大元素：（当前）状态、事件、谓词(复杂条件描述)==》下个状态）（主要用于在系统规格说明书中描述系统的状态转换）
有穷状态机包括下述5个部分：状态集J、输入集K、由当前状态和当前输入确定下一个状态(次态)的转换函数T、初始态S和终态集F
PS：思维方式——抽象状态，事件（动作方法），谓词（补充的状态）“状态和事件动作都由特定实体产生”，因此有穷状态机的第一个抽象步骤一定是先找到实体——也就是OOP思想的应用之一了。
PS2：三大抽象元素：对象（实体），状态（属性），事件（方法）

3、Petri网：

用来描述并发活动（多个操作一起执行）的，解决并发系统遇到的定时问题。包括：最基本（P位置，T转换，I输入,O输出）、带权标（M）和带禁止线的Petri网三种。

4、Z语言：

利用数学符号描述4步骤：给定集合，状态定义，初始状态，操作。
PS: ∧且,∨或

第五章 总体设计

总体设计包括概要设计和详细设计

三种阶段划分方式：

工程管理（软件工程），技术角度，OOP角度（从工程管理的角度，可以将软件设计分为概要设计阶段和详细设计阶段。从技术的角度，传统的结构化方法将软件设计划分为体系结构设计、数据设计、接口设计和过程设计4部分。面向对象方法则将软件设计划分为体系结构设计、类设计/数据设计、接口设计和构件级设计4部分）

1、总体设计的目的

就是从宏观角度设计出软件的不同解决方案，提供给用户和开发人员等进行最佳方案的选择。

2、总体设计分两个阶段：

（概要设计）系统功能设计阶段和（详细设计）软件结构设计阶段。

3、总体设计详细过程9步：

多方案设计–筛选合理方案–确定最佳方案–功能设计–软件结构设计–数据库设计–测试设计–文档书写–审查和检查

4、功能设计时设计模块

模块是对各个子功能的描述，通常要独立完成一定的任务，解决用户一部分需求，多个模块整合解决用户全部需求。

5、模块化作用：

软件结构清晰，可测试和调试，易于管理，易于维护更改。
PS：模块化是功能总的划分，一个模块又往往包含多个子功能，在程序中往往每个子功能测试设计一个TestCase,多个子功能又会封装成一个测试集合TestSuite

6、模块化方式

抽象，就是抽出事物的本质但不考虑细节。（只想干什么，不想怎么干）

7、一般抽象过程就是层次分析的过程。

			软件抽象过程就是精化软件的过程，层次过程
				1--可行性分析中整体软件描述
				2--需求分析中软件功能分析（细化子功能）
				3--概要总体设计过渡到详细设计来把抽象的具体化
				4--源代码实现。

8、原则：

a、逐步求精可以让开发者在适当时候解决当前所必须解决的问题。
b、信息隐藏和局部化，类似于OOP中的封装。
c、模块独立要求耦合度要低，内聚度要高。（合衡量不同模块彼此间互相依赖(连接)的紧密程度，内聚衡量一个模块内部各个元素彼此结合的紧密程度）

9、耦合程度：

非直接耦合/完全独立–>数据耦合（系统中至少必须存在）–>控制耦合（往往多余）–>特征耦合–>公共环境耦合–>内容耦合
（设计原则：尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合）

10、内聚程度:

偶然内聚–逻辑内聚–时间内聚（低内聚）–过程内聚–通信内聚（中内聚）–顺序内聚–功能内聚（高内聚）（ps：设计时力争做到高内聚）

模块化：

1、低耦合和高内聚
2、做到以上要求的经验总结：两种操作分解和合并，应大小适中，复杂度适中，并且有合理的作用域和控制域，以及其他原则

（启发规则：1. 改进软件结构提高模块独立性；2. 模块规模应该适中；3. 深度、宽度、扇出和扇入都应适当；4. 模块的作用域应该在控制域之内；5. 力争降低模块接口的复杂程度；6. 设计单入口单出口的模块；7. 模块功能应该可以预测。）
（行为模式，是动作）
1、模块化应该有分解和合并两种操作：（拆积木，组积木——先拆后组）
a、分解对应OOP中精粒度，对象尽可能的小，甚至最好指包括一个方法函数。（对象越小越容易重用）
PS：缺点就是结构过度复杂，不易维护。
b、内聚对应OOP中功能接口定义功能，封装以及继承多态。
c、MVC为了让耦合度低，接口定义（框架应用DispatcherServlet）为了让内聚性强。
（ 是按照不同的角度来强调耦合度和内聚度要适中）
2、模块化应该大小适中（很难有统一的标准）—模块大小
3、模块四大要素：深度（层次），宽度（同一层的模块数,最大的数），扇入（父模块），扇出(子模块)—-—模块复杂度（模块级别）
4、模块有作用域和控制域两个概念———-模块独立性（范围或域）
作用域：关联的模块，被谁（模块）用——一个对象被依赖的对象的范围
控制域：关联的模块，用谁（模块）——一个对象依赖的对象的范围
5、其他原则：接口（例如程序中的方法，包含参数和结果等信息）复杂度（方法级别）要低，单入单出，可预测（确定的）

6、HIPO图：

包括H图层次结构图，IPO图输入处理输出图

7、结构图：

类似于H图的层次结构图，但包括了IPO图中的输入输出。（方框代表一个模块；方框之间的直线表示模块的调用关系；尾部是空心圆箭头表示传递的是数据；尾部实心圆箭头表示传递的是控制信息。菱形选择判断，弧形循环）

8、面向数据流的设计

就是依据流程图设计软件结构,简称SD方法。(需求分析----->概要设计---->详细设计的过程)（面向数据流的设计方法把信息流映射成软件结构，信息流的类型决定了映射的方法）
PS:用户提交的功能需求，实际上就是用户的工作流程或业务流程，此流程一般就先使用流程图描述。

9、数据流即信息流分为变换流和事务流。

a、变换流：外部和内部数据流状态的转换
b、事务流：统一的事务控制器T管理不同事务的调用。

10、变换流步骤：

a、复查需求和流程图正确性，
b、确定变换或事务类型，确定输入输出边界，
c、确定输入中心Ca,变换控制中心Ct,输出中心Ce(完成“第一级分解”)
d、确定Ca子模块，Ct子模块，Ce子模块（完成“第二级分解”注意方向从Ct向外推）
e、依据低耦合高内聚原则进行精华。

11、事务流步骤

类似于变化流，相同的是都有接收（变化中的输入）和发送（变化中的输出），同时接收和输入的方式类似，但发送和输出的结构不同，发送时有调度模块控制后续活动模块的分发。

第六章 详细设计

1、详细设计

就是具体实现的描述，关键技术是结构程序设计。

2、结构程序设计：

只有一个入口一个出口，并且仅有顺序，选择和循环控制语句。

3、常见的语句：

顺序，分支（范围或个例），循环（先判断后循环，先循环语句后判断），

4、人机界面设计

就是软件的交互界面或UI设计

5、三大黄金原则：

1、界面控制用户操作，2、易懂易用，3、多界面主题风格统一（置用户于控制之下。减少用户记忆负担。保持界面一致。）

6、四大问题：

a、系统响应时间：
	1、时间的长短以及友好的进度提示等。（也不易过短）
	2、易变性是指操作的时间不宜变化过大。（用户习惯与预期问题）
b、用户帮助设施：系统内部帮助提示与外部用户手册等。
c、出错信息处理：友好易用，可解决问题
d、命令交互：菜单或键盘命令。

7、用户界面设计的过程

是迭代的，初步设计–>建立原型–>审查（用户评估界面）–>修改设计–>建立原型–>审查…（循环）

8、程序流程图（程序框图）：

（程序流程图不易表示数据结构）
a、N-S盒图

b、PAD图

9、判定表：

能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。可以弥补流程图中不能描述的多重嵌套问题（多条件）

10、判定树

比判定表更加清晰易读

11、过程设计语言PDL（伪码）：

用正文形式表示数据和处理过程的设计工具。
伪代码的基本控制结构：
简单陈述句结构：避免复合语句。
判定结构：IF_THEN_ELSE或CASE_OF结构。
选择结构：WHILE_DO或REPEAT_UNTIL结构。

12、面向数据结构的设计方法:

Jackson图（既能表示数据结构也能表示程序结构）
五个步骤：
(1)分析并确定输入数据和输出数据的逻辑结构，用Jackson图描绘数据结构。
(2)找出输入数据结构和输出数据结构中有对应关系的数据单元
(3)从描绘数据结构的Jackson图导出描绘程序结构的Jackson图
(4)列出所有操作和条件(包括分支条件和循环结束条件)，并且把它们分配到程序结构图的适当位置。
(5)用伪码表示程序。

13、程序复杂度度量方式:

a、McCabe方法，流图
b、Halstead方法：根据程序中运算符和操作数的总数来度量程序的复杂程度。

第七章 实现

1、实现：

编码和测试

2、编码：

用程序语言实现软件功能。

3、测试：

编码完成后进行单元测试和综合测试。

4、计算机语言：

机器语言，汇编语言，高级语言

5、高级语言选择标准：

易测试，易调试，独立编译

6、编码基本要求：

标识符有意义符合规范，需要加注释，缩进换行等要规范（视觉组织）， 最终要求可读性高。
输入要求：输入要求必须检验合格后才可以应用，格式确定，且有提示信息等。
输出要求：格式化输出，例如报表，并且应该有注释信息，易阅读。
效率要求：在保证程序可读性的条件下，保证程序的运行效率和存储效率。

7、编码风格：

a、注释应语义明确，不应该拿变量名作为注释词汇，应该用变量的实际含义描述。
b、编码关键词应该有空格分格
c、编码应换行缩进
d、变量数据应该有序，例如字母序，如有主次之分，则先主后次。
e、一条一句占一行，分行明确。
f、逻辑清晰简洁，易读。
g、逻辑简单，易读
h、避免使用空的else
i、少用否定(!)，多用肯定。

8、软件测试目的

就是发现程序中的问题及错误。
测试基本准则：根据需求分析提前设计测试计划，从小范围到大范围依次测试，不可能穷举测试，并且应该由第三方综合测试。

9、常用测试方法：

黑盒测试（功能测试）和白盒测试（结构测试）（都不能实现穷尽测试）
a、黑盒不关心逻辑结构，只负责功能接口测试（输入和输出结果是否匹配）
（综合测试）（判断开发结果的正确性） （一种确认技术）
b、白盒是在了解逻辑结构的情况下，检查逻辑结构的流程是否正确达到预定要求。
（单元检测）（判断开发过程的正确性）（一种验证技术）

10、测试步骤：

单元测试（模块测试），子系统测试，系统测试（综合测试），验收测试（确认测试），平行测试（老版新版同步运行测试，比较）。
单元–>子系统–>集成–>线下–> 线上
测试阶段输入数据有软件配置（需求设计分析文档等）和测试配置（测试计划和方案）两部分

11、单元测试

利用白盒测试并行测试每个模块的正确性。
a、测试接口（输入输出），数据结构（实体数据），流程（业务和容错）和边界条件（极限值）。
b、审查小组进行代码审查，小组一般由项目经理，设计，开发，测试构成
c、开发单元测试驱动(例如：junit框架开发的TestCase及组合TestSuite)和存根程序（相关模块调用程序）

12、集成测试

就是组装并测试软件系统，找出接口（输入输出）问题，有非渐增式测试方法和渐增式测试方法两种。（集成测试是测试和组装软件的系统化技术，主要目标是发现与接口有关的问题。）
渐增测试分两种集成策略：自顶向下——需要存根程序，自底向上–需要驱动程序。
最佳测试方案是混合策略，自顶向下（存根程序，功能接口测试）和自底向上（驱动程序，核心模块单元测试）混合使用，

13、回归测试：

当调整完成后，重新进行测试的过程。（重新执行已经做过的测试的某个子集，以保证测试过程中的变化没有带来非预期的副作用）

14、确认测试/验收测试：

确认软件结果是否与需求规格说明书中的用户需求一致，进而让软件符合有效性（功能和性能符合预期）要求。（目标是验证软件的有效性）

15、软件测试分类10个：

接口测试，路径测试，功能测试，健壮性测试（容错与恢复），性能测试（绝对，相对），用户界面测试（友好易用），信息安全测试，压力测试，可靠性测试，安装/反安装测试

16、白盒测试：

目的，数据（输出），结果（输出）
a、逻辑覆盖：语句覆盖（不合适），判定覆盖（分支覆盖），条件覆盖， 判定/条件覆盖，条件组合覆盖，点覆盖，边覆盖，路径覆盖
（判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖。满足条件组合覆盖标准的测试数据，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。）

b、控制结构测试：
a、基本路径测试：计算环形复杂度，按照环形复杂度设计测试路径。
b、循环测试：简单循环，嵌套循环，串接循环。

17、黑盒测试：

功能正确与否，功能缺失等等（着重测试软件功能）
a、等价划分：有效和无效进行归类
b、边界值分析：选取的测试数据应该刚好等于、刚刚小于和刚刚大于边界值。
C、错误推测：很大程度上靠自觉和经验进行

18、调试：

在测试发现错误之后排除错误的过程
a、蛮干法（最低效）
b、回溯法：从发现症状的地方开始，人工沿程序的控制流往回追踪分析源程序代码，直到找出错误原因为止
c、原因排除法：对分查找法、归纳法、演绎法

19、软件可靠性：

程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。
软件的可用性：程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。
软件可靠性计算公式：
a、可靠性=正常运行时间/(正常运行时间和+故障运行时间和)
b、可靠性=平均无故障时间/(平均无故障时间+平均维修时间)

20、 相关量的符号

ET——测试之前程序中错误总数；
IT——程序长度(机器指令总数)；
τ——测试(包括调试)时间；
Ed(τ)——在0至τ期间发现的错误数；
Ec(τ)——在0至τ期间改正的错误数。

21、估计错误总数的方法：

植入错误法：N=n/ns×Ns 分别测试法：B0 =B2/bc×B1

第八章 维护

1、软件开发八大阶段：

问题定义，可行性分析，需求分析， 概要设计，详细设计，编码和单元测试，综合测试，运行维护。

2、软件维护：

在软件已经交付使用之后，为保证软件在相当长的时期能够正常运作所进行的软件活动。（维护过程本质上是修改和压缩了的软件定义和开发过程）
四类维护：改正性维护，适应性维护，扩充与完善性维护，预防性维护（提高软件的可维护性、可靠性等）。

3、软件维护的工作量

与软件开发的过程和技术选择有直接关系。
影响维护工作量的因素：系统大小，程序设计语言，系统年龄，数据库技术的应用，先进的软件开发技术等 工作量的数学计算模型：M=P+Ke(c-d)次方

4、维护过程：

建立维护机构–申明提出维护申请报告的过程及评价的过程（维护报告文档）–为每一个维护申请规定标准的处理步骤（维护处理流程）–维护记录和复审。

5、维护机构构成：

a、维护管理员——维护工程师，b、系统管理员——软件开发工程师，c、变化授权人——项目经理

（每个维护要求都通过维护管理员转交给相应的系统管理员去评价后由变化授权人决定应该进行的活动。）

8、程序的修改步骤：

分析和理解程序，修改程序，重新验证程序
修改程序的副作用3种：修改代码的副作用、修改数据的副作用、文档的副作用

9、软件的可维护性保证

就是软件开发过程中编码的规范要求。
（软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度）
决定软件可维护性的基本要素：可理解性，可测试性，可修改性，可移植性，可重用性

10、文档是影响软件可维护性的决定因素。

用户文档和系统文档要符合软件工程学要求。
a、用户文档：功能描述，安装文档，使用手册，参考手册，操作员指南（要描述系统功能和使用方法）
b、系统文档：需求分析等（描述系统设计、实现和测试等）（指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档）
选课系统：
a、查询选定科目速度慢。（查询同一张表，并且同一时间人数多）——少数人从数据库查询，多数人从已经查询的结果中获取数据（缓存数据）
b、选定科目后注册科目反应慢。（写一张表，并且同一时间人数多）——异步处理，增加用户后续操作选择。

第9章 面向对象方法学引论

1、面向对象

就是根据需求分析出对象，构造类描述对象，通过继承等重用类，进而实现类或对象之间的通信（对象间的互相调用）

2、四个要点：

对象，类，继承，通信

3、面向对象方法论三个组成部分：

OOA面向对象的分析，OOD面向对象的设计，OOP面向对象的实现（编码）

4、优点：

符合人类思维方式，稳定，可重用，易于开发大型系统（重用），可维护。

5、对象

是具有属性和方法的客观实体(或抽象概念Service，Dao)（将一组数据和使用该数据的一组基本操作或过程封装在一起的实体。）（对象的特点：以数据为中心。 对象是主动的。实现了数据封装。本质上具有并行性。模块独立性好。）

6、类

是描述和封装对象的属性和方法。

7、实例

是由类创建的，就是对象在计算机中映射。（对象是脑中的，实例是计算机模拟的）
（先分析出对象–封装成类–用类创建实例，完成任务，实例就是对象在计算机中的虚拟化）

8、消息

是对象调用方法，发送和接收信息。

9、方法

是函数，就是对象的功能描述（方法描述了对象执行操作的算法，响应消息的方法）

10、属性

就是对象的数据信息。

11、封装

就是封装对象的数据（属性）及操作（方法）。

12、继承

就是子类直接获取父类属性及方法重用。

13、多态：

子类重写父类方法——动态多态。类的重载——静态多态。

14、面向对象建模

就是用面向对象思想完成需求分析建模的过程。

15、OMT

就是面向对象的模型技术，是一种方法学（解决问题的方式和技术）。

16、三种模型：

对象模型：数据结构，动态模型：（控制结构）流程（执行操作），功能模型：运算（数值变化）

17、UML统一建模语言：

统一标准，面向对象，可视化，无关语言（独立于过程），易用

19、对象模型使用UML的类图：

a、类基本结构，类，属性，方法（矩形框包裹的）
b、关系：关联，聚集，继承（泛化），依赖，细化

20、动态模型：

状态图，时序图（顺序图）等（描述系统控制结构。通常用状态图表示）

21、功能模型：

流程图，一个功能的详细操作流程。

22、功能模型和对象模型：

对象构成功能，功能是对象的操作过程。

23、动态模型和对象模型：

对象构成动态模型，动态是对象操作过程描述。

24、动态模型和功能模型：

功能就是动态模型中的具体操作。

第十章 面向对象分析

1、面向对象分析OOA:

抽象用户需求建立需求模型的过程。

2、要求：

要让开发和用户等相关人员容易理解，完成需求规格说明书，没有二义性且具有完善性。

3、核心是：

对象模型（最基本，最重要，最核心）

4、OOA三个子模型：

静态结构——对象模型，
交互次序–动态模型，
数据变换——功能模型

5、五个层次：

主题层，类与对象层，结构层，属性层，服务层（功能方法）

6、OOA的过程：

寻找类与对象–>识别结构–>识别主题–>定义属性–>建立流图（动态模型和功能模型）–>定义服务(方法)

7、OOA过程详解：

a、类与对象分析：先找所有的名词和概念，后筛选，筛选掉冗余，无关，笼统，属性，操作以及实现（具体的过程）。
b、关联关系分析：先找所有的的动态或隐含的关联等，后筛选，筛选掉无关的等关联，绘制关联关系图。
c、主题划分：模块划分，低耦合高内聚，具有良好的独立性（不同主题内对象相互依赖和交互最少原则）。
d、确定属性：分析和选择两个步骤。
e、分析继承：自底向上或自顶向下
f、反复修改：简化类图。
~类图中具有了类名和属性基础,缺少方法设计
g、动态模型建立（状态图和时序图）：
	a、利用脚本完成，正常，异常，和特殊三种情况。b、简单设计用户界面，保证正常的输入输出。c、画事件跟踪图-->时序图-->状态图。d、检查。h、功能模型建立（数据流图）——描述功能，确定映射约束和依赖。i、定义服务：从功能中总结出共同的行为方法，和属性操作。

8、三大模型关系：

a、对象模型是功能模型的动作者，数据流，数据存储的结构描述者。
b、动态模型是功能模型的执行次序描述者。
c、功能模型是对象模型的关系描述者
d、动态模型是对象模型的方法描述者
e、功能模型是动态模型的动作描述者和动作补充者。
f、对象模型是动态模型的操作动作执行者的描述者。