软件工程

1.瀑布模型给出了软件生存周期各阶段的固定顺序，上一阶段完成后才能进入下一阶段。是一种结构化方法线性模型。适用于需求明确、且无大的需求变更的软件开发。

2.增量模型可以快速构造核心产品。系统功能在增量中不断完善或者增加。核心产品往往首先开发，因此经历最充分的”测试”。难点在于模块的划分。

3.螺旋模型，它将瀑布模型和快速原型模型（演化模型）结合起来。特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。螺旋模型有两个显著特点，一是采用循环的方式逐步加深系统定义和实现的深度，同时降低风险;二是确定一系列里程碑，确保项目开发过程中的相关利益者都支持可行的和令人满意的杀统解决方案。

4.演化模型是在快速开发一个原型的基础上进行改进，获得原型的新版本。重复这一过程，直到演化成最终的软件产品。

5.原型模型允许开发人员快速地构造整个系统或系统的一部分以理解或澄清问题。

水平原型通常只是功能的导航，但未真实实现功能。水平原型主要用在界面上。

垂直原型也称为结构化原型，实现了一部分功能。垂直原型主要用在复杂的算法实现上。

抛弃式原型也称为探索式原型，是指达到预期目的后，原型本身被抛弃。抛弃式原型主要用在解决需求不确定性、二义性、不完整性、含糊性等。

演化式原型为开发增量式产品提供基础，逐步将原型演化成最终系统，主要用在必须易于升级和优化的场合，适合于Web项目。

6.喷泉模型主要用来描述面向对象的开发过程。它体现了面向对象开发过程的迭代和无间隙特征。

7.信息系统开发方法：

结构化法：适用于系统规模简单，需求变化不大的开发。

原型法   ：适用于系统规模简单，需求不明确且多变的开发。

面向对象方法

面向服务方法

Jackson：面向数据结构的方法，适用于小规模的项目。

8.敏捷开发方法：以人为核心、迭代、循序渐进。

极限编程(XP)，是一种轻量级(敏捷)、高效，低风险、柔性、可预测的、科学的软件开发方法，它由价值观、原则、实践和行为4个部分组成。

4大价值观为沟通、简单性、反馈和勇气。XP提倡结对编程，代码所有权是归于整个开发队伍。XP主要解决代码质量低的问题，编码速度不能改变。

5个原则:快速反馈、简单性假设、逐步修改、提倡更改和优质工作。交付的间隔可以从几周到几个月，交付的时间间隔越短越好。但不要求每次交付的都是系统的完整功能。

12个最佳实践:计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结队编程、集体代码所有制、持续集成、每周工作40个小时、现场客户和编码标准。

水晶法(Crystal):每一种不同的项目都需要一套不同的策略、约定和方法论。

并列争球法(Scrum):用迭代的方法，其中把每30天一次的迭代称为一个”冲刺”，并按需求的优先级来实现产品。多个自组织和自治小组并行地递增实现产品。

自适应软件开发(ASD):ASD的核心是三个非线性的、重迭的开发阶段:预测，协作与学习。

FDD功用驱动方法:开发人员分类。分为指挥者(首席程序员)、类程序员。

开放式源码:虚拟团队，开发成员分布各地。

9.语句覆盖要求被测程序中的每一条语句至少执行一次，这种覆盖对程序执行逻辑的覆盖很低。条件覆盖要求每一判定语句中每个逻辑条件的各种可能的值至少满足一次。判定/条件覆盖要求判定中每个条件的所有可能取值(真/假)至少出现一次，并使得每个判定本身的判定结果(真/假)也至少出现一次。路径覆盖则要求覆盖被测程序中所有可能的路径。

路径>条件>语句。

10.在软件设计的模块划分需要遵循原则： 讲究高内聚，低耦合。

模块大小适中。

模块的扇入扇出合理。

深度和宽度适当。

11.业务用例和参与者一起描述组织支持的业务过程，而业务对象模型描述业务结构以及结构元素如何完成业务用例。

12.McCabe度量法计算环路复杂性为：边-点+2。

开始、结束、判断都当做结点，两条线合并成一条线的情况也算两条线。

13.功能内聚、顺序内聚、通信内聚、过程内聚、瞬时内聚、逻辑内聚、偶然内聚。

通信内聚：一个模块的所有成分都操作同一数据集或生成同一数据集。如某模块有两个处理A和B，分别对数据结构x写数据和读数据。

偶然内聚：一个模块的各成分之间毫无关系。也影响模块间的耦合关系。

巧合内聚：模块间有着相同的程序块，块内的语句之间没有任何联系，把该程序块取出来，形成新的模块。

过程内聚：模块内涉及多个功能，这些功能必须以特定的次序执行。

14.CMMI模型等级：

CL0——未完成的：未执行或未达到CL1定义的所有目标。

CL1——已执行的：将输入转换成输出。

CL2——已管理的

CL3——已定义级的

CL4——定量管理的

CL5——优化的：使用量化手段改变和优化过程域，以应对客户要求的改变和持续改进计划中的过程域的功效。

15.统一过程(UP)

以用例和风险为驱动，以架构为中心，受控的迭代式的增量开发。每次迭代都包含计划、分析设计构造、集成、测试以及内部和外部发布。每个迭代有五个核心工作流。

起始阶段的里程碑是生命周期目标。

精化阶段的里程碑是生命周期构架。

构建阶段的里程碑是初始运作功能。

移交阶段的里程碑是产品发布。

在每一轮迭代中都要进行测试与集成。

16.事务

原子性表示事务执行过程中的任何失败都将导致事务所做的任何修改失效。

一致性表示当事务执行失败时，所有被该事务影响的数据都应该恢复到事务执行前的状态。

隔离性表示在事务执行过程中对数据的修改，在事务提交之前对其他事务不可见。

持久性表示已提交的数据在事务执行失败时，数据的状态都应该正确。

17.进度管理工具Gantt图

不能清晰地确定影响进度的关键任务和各任务之间的依赖关系。但能清晰地获得任务并行信息。

18.使用PERT图

不能清晰地描述各任务并行情况。能清晰地描述各个任务之间的依赖情况。

19.在屏蔽软件错误的容错系统中，冗余附加技术的过程包括：冗余备份程序的存储及调用、实现错误检测和错误恢复的程序、实现容错软件所需的固化程序。

20.ISO/IEC软件质量模型

使用质量是从用户观点出发而不是开发者、维护者的观点。软件质量包括内部质量、外部质量和使用质量。

21. 计算机系统的可靠性可以用MTBF/(1+MTBF)来度量，其中MTBF为平均失效间隔时间。

22.COCOMO用3个不同层次的模型来反映不同程度的复杂性。它们分别为:

基本模型，一个静态单变量模型，它用一个以已估算出来的源代码行数(LOC)为自变量的函数来计算软件开发工作量。

中级模型，则在用LOC为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。

详细模型，包括中级COCOMO型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中分析、 设计等各步骤的影响。

COCOMO II包含了三个阶段模型。

应用组装模型

早期阶段设计模型

体系结构阶段模型

产业界最广泛使用和讨论的成本估算模型之一，在模型层次有三种不同的规模估算选择:对象点、功能点、代码行，其中功能点是可以转换为代码行的。

成本估算工具就是一种典型的项目管理工具。

23.归纳法是指从测试所暴露的问题出发收集所有正确或不正确的数据。

24.仓库风格包括：数据库系统、黑板系统、超文本系统。

优点：

支持可更改性和可维护性。

具有可复用的知识源。

支持容错性和健壮性。

缺点：测试困难，效率低，成本高。

25.管道过滤器体系结构：高内聚低耦合、支持重用和支持并行执行，但不提高性能。

26.软件测试配置管理中最基本的活动包括：配置项标识、配置项控制、配置状态 告、配置审计。

软件配置管理包括版本控制、变更控制及过程支持，不包括质量控制和风险管理。

27.DDP即缺陷探测率。DDP越高，说明测试者发现的Bugs数目越多，发布后客户发现的Bugs就越少，降低了外部故障不一致成本，达到了节约总成本的目的。

28.确认测试包括：内部确认测试以及Alpha测试与Beta测试。

29.采用决策表表示基本加工，则条件取值的组合数最少是3。

30. 开发小组沟通路径

31. 耦合取决于各个模块之间接口的复杂程度、调用模块的方式以及通过接口的信息类型。

32.软件质量

33.在一个项目中，最长的路径所需的天数(关键路径)就是完成该项目最短的天数。

假设A在关键路径上的活动，压缩A的工期，可以缩短整个项目的完成时间。

34.软件维护

正确性维护，是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误；

适应性维护，是指使应用软件适应新技术变化和管理需求变化而进行的修改；

完善性维护，是指为扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征；

预防性维护，是指为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，主动增加预防性的新功能，以使应用系统适应各类变化而不被淘汰。

35.软件结构图中的模块类型

传入模块:从下属模块取得数据，经过某些处理，再将其结果传给上级模块。

传出模块:从上级模块取得数据，经过某些处理，再将其结果传给下属模块。

变换模块:也叫加工模块。它从上级模块取得数据，进行特定的处理，转换成其他形式，再传回上级模块。它加工的数据流称作变换数据流。

协调模块:对所有下属模块进行协调和管理的模块。在系统的输入输出部分或数据加工部分可以找到这样的模块。在一个好的模块结构图中，协调模块应在较高层出现。

36.OLAP工具是针对特定问题的联机数据访问与分析。它通过多维的方式对数据进行分析、查询和 表。

37.根据被测代码是否可见分为白盒测试和黑盒测试。

白盒测试就是对多逻辑值透明化处理，将实例放入测试，多次实验确保每条代码都会执行。

常见的黑盒测试技术：等价类划分、边界值分析、错误推测和因果图等。黑盒测试一般用来确认软件功能的正确性和可操作性。

38.静态测试和动态测试

静态测试主要是对软件的编程格式结构等方面进行评估。

动态测试指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。

39.软件工程的基本要素：方法、工具、过程。

40.软件测试的对象为：程序、数据和文档。

41.采用面向对象方法进行软件开发，分析阶段，架构师主要关注系统的行为，即系统应该做什么。

42.系统方案建议书是系统分析阶段结束后得到的工作产品，操作手册、单元测试数据是系统测试阶段完成后的工作产品。系统测试计划是在需求分析阶段完成的。

43.面向结构化的设计阶段先后分为概要设计和详细设计。

概要设计阶段将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。包含系统架构、模板划分、系统接口、数据设计，不包含模块内算法设计。

详细设计阶段对概要设计阶段得出的各功能模块进行详细描述成精确的、结构化的过程描述，即各个功能模块具体怎么实现，用相应的工具把模块的控制结构表示出来，但还未进行编码。

如， 络设计、代码设计、输入/输出设计、处理流程设计、数据存储设计、用户界面设计、安全性和可靠性设计等。

44. 程序质量评审通常是从开发者的角度进行评审，内容包括功能结构、功能通用性和模块层次等，不包括与硬件的接口。

45.软件维护工具主要有：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。

46.软件开发过程中，需求分析阶段的输出包括数据流图、数据字典、E-R图和需求说明文档。

需求是应该分等级的，不能把所有需求都视为同等重要。

47.测试环节

单元测试-集成测试-系统测试-确认测试-验收测试。

48.单元测试内容:模块接口、局部数据结构、执行路径、错误处理和边界。

代码审查通常在单元测试阶段进行。确认测试的任务是进一步检查软件的功能和性能是否与用户要求一致。可靠性测试在确认测试阶段进行。

49.软件开发过程中，系统测试阶段的测试目标来自需求分析阶段。

50.集成测试

集成测试计划应该在概要设计阶段制定非渐增式集成测试。目前在进行集成测试时已普遍采用渐增式集成测试。

集成测试的依据是概要设计规格说明，因此在概要设计完成后即开始制定集成测试计划。

软件的集成测试最好由不属于该软件开发组的软件设计人员承担，以提高集成测试的效果。

驱动模块用来模拟被测试模块的上一级模块，相当于被测模块的主程序，它接收数据，将相关数据传送给被测模块，启动被测模块，并打印出相应的结果。

桩模块用来模拟被测模块工作过程中所调用的模块，它们一般只进行很少的数据处理。

常见的集成测试方法包括自顶向下、自底向上、Big- Bang等。

自底向上的集成测试不需要编写桩模块，但需要编写驱动模块，而自顶向下的集成测试需要编写桩模块，不需要编写驱动模块。

51.用决策树能够清楚地表示复杂的条件组合与应做的动作之间的对应关系。

52.风险控制活动目的是辅助项目组建立处理风险的策略，有效的策略应考虑风险避免、风险监控、风险管理及意外事件计划。

风险的优先级通常是根据风险暴露决定。

53.在软件设计阶段就应该考虑软件的可维护性。

54.正式技术评审是一种由软件工程师和其他人进行的软件质量保障活动。

其目标包括:

发现功能、逻辑或实现的错误；

证实经过评审的软件的确满足需求；

保证软件的表示符合预定义的标准；

得到一种一致的方式开发的软件；

使项目更易管理。

55.三明治方法的缺点是测试工作量大。

56.验收测试由用户主导，开发方参与。

57.软件过程主要包括软件描述、软件开发、软件有效性验证和软件进化活动。这些活动主要由软件人员来完成。

软件开发的基本目标是开发高质量的软件。

58.软件设计遵循的基本原则：模块化、抽象和信息隐蔽。

59.软件修改后要进行退化测试，因为在修改过程中纠正了老的错误又会引入新的错误，退化测试就是用来防止出现新错误的。

60.软件复杂性的度量参数主要包括规模、难度、结构、智能度等。

61.需求工程活动产生软件运行特征的规约，指明软件和其他系统元素的接口并建立软件必须满足的约束条件。

62.需求管理变更的过程：识别出问题、问题分析与变更描述、变更分析与成本计算、变更实现。

64.质量功能部署(QFD)的三类需求：基本需求(常规需求)、期望需求和意外需求(兴奋需求)。

65.在各种不同的软件需求中，功能需求描述了用户使用产品必须要完成的任务，可以用UML建模语言的用例图表示。

66.在uml2.0中，组合结构图描述结构化类(例如，构件或类)的内部结构。定时图强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序。制品图包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。交互概览图是活动图和顺序图的混合物。

67.质量审计(包括软件评审)和过程分析是软件质量保证的主要活动。

68.静态绑定和动态绑定

静态绑定在编译时进行。

动态绑定在运行时进行，支持多态。

69.配置项是构成产品配置的主要元素，配置项主要有以下两大类:

属于产品组成部分的工作成果:如需求文档、设计文档、源代码和测试用例等；

属于项目管理和机构支撑过程域产生的文档:如工作计划、项目质量 告和项目跟踪 告等。这些文档虽然不是产品的组成部分，但是值得保存。

70.项目范围管理中，范围定义的输入包括：项目章程、项目范围管理计划、组织过程资产和批准的变更申请。

71.确认系统边界和关系规范化分别在数据库设计的需求分析和逻辑设计阶段进行。

72.可以通过加强软件测试的配置管理来降低测试的维护成本。

73.项目时间管理的过程包括：活动定义、活动排序、活动的资源估算、活动历时估算、制定计划和进度控制。

74.系统分析

75.广义的软件测试由确认-验证-测试三个方面组成。其中，确认是想证实在一个给定的外部环境中软件的逻辑正确性，检查软件在最终的运行环境上是否达到预期的目标。 

76.企业信息化方法

77.测试 

数据字典：数据流、数据项、数据存储和基本加工。

79.接口设计的主要依据是数据流图，接口设计的任务主要是描述软件与外部环境之间的交互关系，软件内模块之间的调用关系。

80.定义软件的主要结构元素及其之间的关系是架构阶段的任务;确定软件涉及的文件系统的结构及数据库的表结构是数据存储设计阶段的任务;确定软件各个模块内部的算法和数据结构是详细设计阶段的任务。

81.顶层数据流图描述了系统的输入与输出。