1.What is Software? (1)指令的集合(计算机程序)，通过执行这些指令来满足预期的特征、功能和性能需求； (2)数据结构，使得程序可以合理的利用信息; (3)文档描述，用来描述程序操作和使用。2. Software Engineering 软件工程是）建立和使用一套合理的工程原则，以便经济地获得可靠的、可以在实际机器上高效运行的软件。IEEE定义（1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。（2）在(1)中所述方法的研究。3. Process framework过程框架 沟通communication、策划planning、建模modeling、构建construction、部署deployment 4.Prescriptive Models惯用过程模型 瀑布模型（系统的、顺序的、V模型是变体） 增量过程模型（每个阶段运用线性序列、每个增量提交产品） 演化过程模型（原型开发、螺旋模型）协同开发模型。5.统一过程unified process UML统一建模语言 一种用例驱动，以架构为核心，迭代并且增量的软件过程与统一建模语言的紧密结合。6. Requirements Engineering需求工程 起始、导出、精化、协商、规格说明、确认、需求管理。7. Class-responsibility-collaborator (CRC) modeling CRC建模 CRC模型实际上是表示类的标准索引卡的集合。这些卡片分为三部分，顶部写类名，卡片主体左侧部分列出类的职责，右侧部分列出类的协作者。职责：系统智能应用分布在所有类中以求最佳地满足问题的需求。每个职责的说明应尽可能具有普遍性。信息和与之相关的行为应放在同一个类中。某个事物的信息应局限于一个类中而不要分布在多个类中。适合时，职责应由相关类共享。 简单地说：职责就是类所知道或能做的任何事、协作者是提供完成某个职责所需要信息的类、通常，协作意味着信息请求或某个动作请求。8. Architecture 体系结构 软件的整体结构和这种结构为系统提供概念完整性的方式 属性：结构特性、外部功能特性、相关系统族。9. Information Hiding 信息隐蔽 模块中包含的信息（算法和数据）不被不需要这些信息的其他模块访问。 Why 减少“负效应”的可能性.限制全局影响局部的设计决策.强调通过控制接口通信.不提倡使用全局数据.导致封装——高质量设计的属性.导致高质量软件
10. Functional Independence功能独立 可以通过两条定性的标准进行评估：内聚性和耦合性。 内聚性显示了某个模块相关功能的强度。耦合性显示了模块间的相互依赖性。
11.refactoring重构 重构是使用这样一种方式改变软件系统的过程：不改变代码[设计的外部行为而是改进其内部结构。当重构软件时，检查现有设计：冗余性 没有使用的设计元素 低效的或不必要的算法 拙劣的或不恰当的数据结构 其他设计不足，修改这些不足以获取更好的设计。12. Design Classes设计类 高内聚性cohesion和低耦合性coupling 一个内聚的设计类具有小的、集中的职责集合，并且专注于使用属性和方法来实现那些职责。 协作保持在一个可以接受的小范围内。13.设计模型的元素 design model elements 1.数据设计元素：数据结构、数据库体系结构 2.体系结构设计元素：来源：应用领域、特定的需求模型元素（数据流图、分析类、现有问题中的关系和协作）、风格和模式 3.接口设计元素interface 4.构件级设计元素 5.部署级设计元素 14.软件体系结构architecture 什么是软件体系结构？程序或计算机系统的软件体系结构是指系统的一个或多个结构，它包括软件构件、构件的外部可见属性以及他们之间的相互关系。 软件体系结构为什么重要？软件体系结构的表示有助于对计算机系统开发感兴趣的各方（利益相关者）开展交流。 体系结构突出了早期的设计决策，这些决策对随后所有的软件工程工作有深远影响，同时对系统作为一个可运行实体的最后成功有重要作用。 体系结构“构建了一个相对小的、容易理解的模型，该模型描述了系统如何构成以及其构件如何一起工作”。 15.Architectural style 体系结构风格 以数据为中心的体系结构、数据流体系结构、调用和返回体系结构、面向对象体系结构、层次体系结构。
16. What is a Component? 什么是构件？系统模块化的、可部署的和可替换的部件，该部件封装了实现并暴露一组接口。 OO 观点：构件包含一组协作的类
传统观点：一个构件包含处理逻辑，实现处理逻辑所需的内部数据结构以及能保证构件被调用和实现数据传递的接口。
17.Cohesion 内聚性：传统观点：构件的专一性、面性对象观点：内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作。分类：功能内聚、分层内聚、通信内聚。 18.coupling 耦合性 传统观点：构件之间彼此联系、构件和外部世界联系程度的一种度量、OO观点：类之间彼此联系程度的一种定性度量。分类：内容 、共用、控制、标记、数据、历程调用、类型使用、包含或者导入、外部。
19.software quality 软件质量：在一定程度上应用有效的软件过程，创造有用的产品，为生产者和使用者提供明显的价值。20.quality dimension质量维度：性能质量、特性质量、可靠性、符合性、耐久性、适用性、审美、感知。21. Software Quality Assurance软件质量保证：标准、评审和审核、测试、错误/缺陷的收集和分析、变更管理、教育、供应商管理、安全管理、安全、风险管理。22.软件质量保证目标：需求质量。需求模型的正确性、完整性和一致性将对所有后续工作产品的质量有很大的影响。、设计质量。软件团队应该评估设计模型的每个元素，以确保设计模型显示出高质量，并且设计本身符合需求。、代码质量。源代码和相关的工作产品（例如，其他说明信息）必须符合本地的编码标准，并显示出易于维护的特点。、质量控制有效性。软件团队应使用有限的资源，在某种程度上最有可能得到高品质的结果。23.measure reliability and availability 可靠性和可用性测量：可靠性的简单测量是“平均失效间隔时间”(MTBF)， 其中
MTBF = MTTF + MTTR
首字母缩略词MTTF和MTTR 分别是 “平均失效时间”和“平均维修时间”。
软件可靠性是指在某个给定时间点上程序能够按照需求执行的概率。其定义为： 可用性= [MTTF/(MTTF + MTTR)] x 100%
24.software testing 软件测试: 测试是在交付产品给最终用户之前，带着特定的目的在运行程序的过程中发现错误。25.验证与确认verification and validation: 验证是指确保软件正确地实现某一特定功能的一系列活动。 确认指的是确保开发的软件可追溯到客户需求的另外一系列活动。25.testing strategy 测试策略：系统测试（整体）、确认测试（需求）、集成测试（体系结构的设计和构造）：（主要 自底向上、自顶向下、三明治 次要 回归测试、冒烟测试）、单元测试（源代码形式实现的每个单元）。 26.单元测试：通常被认为是编码阶段的附属工作。由于构件并不是独立的程序，因此，必须为每个测试单元开发驱动程序和桩程序。驱动程序只是一个主程序，接受数据并传递给构件，并打印结果。桩程序的作用是替换那些从属于被测构件的模块。桩程序使用从属模块的接口，可能做少量的数据操作，提供入口的验证，并将控制返回到被测模块。 27.regression testing回归测试 回归测试重新执行已测试过的某些子集，以确保变更没有传播不期望的副作用。
无论什么时候修正软件，软件配置的某些方面（程序、文档或支持数据）也发生变更。 回归测试有助于保证变更（由于测试或其他原因）不引入无意识行为或额外的错误。
回归测试可以手工进行，方法是重新执行所有测试用例的子集，或者利用捕捉/回放工具自动进行。28.smoke testing冒烟测试步骤：将已经转换为代码的软件构件集成到“构建”中去。 （一个构建包括所有的数据文件、库、可复用的模块以及实现一个或多个产品功能所需的工程化构件。）
设计一系列测试以暴露影响构建正确地完成其功能的错误。（其目的是为了发现极有可能造成项目延迟的“业务阻塞”错误）。
每天将该构建与其他构建及整个软件产品（以其当前的形式）集成起来进行冒烟测试。 （这种集成方法可以是自顶向下，也可以自底向上。）
29.system testing系统测试：恢复测试、安全测试、压力测试、性能测试、部署测试。
30.debugging techniques调试方法：蛮干、回溯、归纳、原因排除。
31. Internal and External Views内部视角和外部视角 任何工程化的产品（以及大多数其他东西）都可以采用以下两种方式之一进行测试：
（黑盒测试）了解已设计的产品要完成的指定功能，可以执行测试以显示每个功能是可操作的，同时，查找在每个功能中的错误；
（白盒测试）了解产品的内部工作情况，可以执行测试以确保“所有的齿轮吻合”——即内部操作依据规格说明执行，而且对所有的内部结构已进行了充分测试。
32.white box method 白盒测试 （1）保证一个模块中的所有独立路径至少被执行一次 （2）对所有的逻辑判定均需测试取真和取假两个方面 (3)在上下边界及可操作的范围内执行所有的循环 （4）检验内部数据结构以确保其有效性。
33. Deriving Test Cases导出测试用例 （1）以设计或源码为基础，画出相应的流图。
（2）确定所得流图的环复杂性。（3）确定线性独立路径的基本集合。（4）准备测试用例，强制执行基本集合中的每条路径。
34.简单循环Simple Loops （1）跳过整个循环（2）只有一次通过循环（3）两次通过循环（4）m次通过循环，m
35.等价类划分equivalence partitioning 等价类划分是一种黑盒测试方法，它将程序的输入划分为若干个数据类，从中生成测试用例。
36. SCM元素 配置管理系统元素 （1）构件元素 ——是一组具有文件管理系统 (如，数据库) 功能的工具，使我们能够访问和管理每个软件配置项。（2）过程元素 ——是一个动作和任务的集合，它为所有参与管理、开发和使用计算机软件的人员定义了变更管理 (以及相关活动) 的有效方法。（3）构造元素 ——是一组自动软件构造工具，用以确保装配了正确的有效构件 (即，正确的版本) 集。（4）人员元素 ——为有效实施SCM，软件团队使用的一组工具和过程特性 (包括其他 CM 元素) 。
37.基线baseline IEEE是这样定义基线的：已经通过正式评审和批准的规格说明或产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制规程才能修改它。
基线是软件开发中的里程碑，其标志是正式技术评审中已经获得批准的一个或多个软件配置项的交付。
38. Version Control版本控制的4个功能：（1）存储所有相关配置对象的 项目数据库 (中心存储库)； （2）存储配置对象所有版本(或能够通过与先前版本间的差异来构造任何一个版本)的 版本管理功能；(3)使软件工程师能够收集所有相关配置对象和构造软件特定版本的制作功能； (4)问题跟踪 (也叫做错误跟踪) 使团队能够记录和跟踪与每个配置对象相关的所有重要问题的状态。
39.SCM中心存储库SCM Repository SCM中心存储库是一组机制和数据结构，它使软件团队可以有效地管理变更。 中心存储库具有以下功能[For89]：
数据完整性、信息共享、工具集成、数据集成、方法执行、文档标准化。
中心存储库特征：Repository Features
（1）版本控制：保存所有这些版本，以便有效地管理产品发布，并允许开发者在测试和调试过程中可以返回到早先的版本。
（2）依赖性跟踪和变更管理：中心存储库要管理所存储的配置对象之间的各种关系。
（3）需求跟踪：跟踪由特定需求规格说明产生的所有设计构件、架构构件以及可交付产品。
（4）配置管理：跟踪表示特定项目里程碑或产品发布的一系列配置。 版本管理提供了所需的版本，而链接管理负责跟踪其相互依赖性。
（5）审核跟踪：了解变更是在什么时候、什么原因以及由谁完成等信息。
1.What is Software? (1)指令的集合(计算机程序)，通过执行这些指令来满足预期的特征、功能和性能需求； (2)数据结构，使得程序可以合理的利用信息; (3)文档描述，用来描述程序操作和使用。2. Software Engineering 软件工程是）建立和使用一套合理的工程原则，以便经济地获得可靠的、可以在实际机器上高效运行的软件。IEEE定义（1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。（2）在(1)中所述方法的研究。3. Process framework过程框架 沟通communication、策划planning、建模modeling、构建construction、部署deployment 4.Prescriptive Models惯用过程模型 瀑布模型（系统的、顺序的、V模型是变体） 增量过程模型（每个阶段运用线性序列、每个增量提交产品） 演化过程模型（原型开发、螺旋模型）协同开发模型。5.统一过程unified process UML统一建模语言 一种用例驱动，以架构为核心，迭代并且增量的软件过程与统一建模语言的紧密结合。6. Requirements Engineering需求工程 起始、导出、精化、协商、规格说明、确认、需求管理。7. Class-responsibility-collaborator (CRC) modeling CRC建模 CRC模型实际上是表示类的标准索引卡的集合。这些卡片分为三部分，顶部写类名，卡片主体左侧部分列出类的职责，右侧部分列出类的协作者。职责：系统智能应用分布在所有类中以求最佳地满足问题的需求。每个职责的说明应尽可能具有普遍性。信息和与之相关的行为应放在同一个类中。某个事物的信息应局限于一个类中而不要分布在多个类中。适合时，职责应由相关类共享。 简单地说：职责就是类所知道或能做的任何事、协作者是提供完成某个职责所需要信息的类、通常，协作意味着信息请求或某个动作请求。8. Architecture 体系结构 软件的整体结构和这种结构为系统提供概念完整性的方式 属性：结构特性、外部功能特性、相关系统族。9. Information Hiding 信息隐蔽 模块中包含的信息（算法和数据）不被不需要这些信息的其他模块访问。 Why 减少“负效应”的可能性.限制全局影响局部的设计决策.强调通过控制接口通信.不提倡使用全局数据.导致封装——高质量设计的属性.导致高质量软件
10. Functional Independence功能独立 可以通过两条定性的标准进行评估：内聚性和耦合性。 内聚性显示了某个模块相关功能的强度。耦合性显示了模块间的相互依赖性。
11.refactoring重构 重构是使用这样一种方式改变软件系统的过程：不改变代码[设计的外部行为而是改进其内部结构。当重构软件时，检查现有设计：冗余性 没有使用的设计元素 低效的或不必要的算法 拙劣的或不恰当的数据结构 其他设计不足，修改这些不足以获取更好的设计。12. Design Classes设计类 高内聚性cohesion和低耦合性coupling 一个内聚的设计类具有小的、集中的职责集合，并且专注于使用属性和方法来实现那些职责。 协作保持在一个可以接受的小范围内。13.设计模型的元素 design model elements 1.数据设计元素：数据结构、数据库体系结构 2.体系结构设计元素：来源：应用领域、特定的需求模型元素（数据流图、分析类、现有问题中的关系和协作）、风格和模式 3.接口设计元素interface 4.构件级设计元素 5.部署级设计元素 14.软件体系结构architecture 什么是软件体系结构？程序或计算机系统的软件体系结构是指系统的一个或多个结构，它包括软件构件、构件的外部可见属性以及他们之间的相互关系。 软件体系结构为什么重要？软件体系结构的表示有助于对计算机系统开发感兴趣的各方（利益相关者）开展交流。 体系结构突出了早期的设计决策，这些决策对随后所有的软件工程工作有深远影响，同时对系统作为一个可运行实体的最后成功有重要作用。 体系结构“构建了一个相对小的、容易理解的模型，该模型描述了系统如何构成以及其构件如何一起工作”。 15.Architectural style 体系结构风格 以数据为中心的体系结构、数据流体系结构、调用和返回体系结构、面向对象体系结构、层次体系结构。
16. What is a Component? 什么是构件？系统模块化的、可部署的和可替换的部件，该部件封装了实现并暴露一组接口。 OO 观点：构件包含一组协作的类
传统观点：一个构件包含处理逻辑，实现处理逻辑所需的内部数据结构以及能保证构件被调用和实现数据传递的接口。
17.Cohesion 内聚性：传统观点：构件的专一性、面性对象观点：内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作。分类：功能内聚、分层内聚、通信内聚。 18.coupling 耦合性 传统观点：构件之间彼此联系、构件和外部世界联系程度的一种度量、OO观点：类之间彼此联系程度的一种定性度量。分类：内容 、共用、控制、标记、数据、历程调用、类型使用、包含或者导入、外部。
19.software quality 软件质量：在一定程度上应用有效的软件过程，创造有用的产品，为生产者和使用者提供明显的价值。20.quality dimension质量维度：性能质量、特性质量、可靠性、符合性、耐久性、适用性、审美、感知。21. Software Quality Assurance软件质量保证：标准、评审和审核、测试、错误/缺陷的收集和分析、变更管理、教育、供应商管理、安全管理、安全、风险管理。22.软件质量保证目标：需求质量。需求模型的正确性、完整性和一致性将对所有后续工作产品的质量有很大的影响。、设计质量。软件团队应该评估设计模型的每个元素，以确保设计模型显示出高质量，并且设计本身符合需求。、代码质量。源代码和相关的工作产品（例如，其他说明信息）必须符合本地的编码标准，并显示出易于维护的特点。、质量控制有效性。软件团队应使用有限的资源，在某种程度上最有可能得到高品质的结果。23.measure reliability and availability 可靠性和可用性测量：可靠性的简单测量是“平均失效间隔时间”(MTBF)， 其中
MTBF = MTTF + MTTR
首字母缩略词MTTF和MTTR 分别是 “平均失效时间”和“平均维修时间”。
软件可靠性是指在某个给定时间点上程序能够按照需求执行的概率。其定义为： 可用性= [MTTF/(MTTF + MTTR)] x 100%
24.software testing 软件测试: 测试是在交付产品给最终用户之前，带着特定的目的在运行程序的过程中发现错误。25.验证与确认verification and validation: 验证是指确保软件正确地实现某一特定功能的一系列活动。 确认指的是确保开发的软件可追溯到客户需求的另外一系列活动。25.testing strategy 测试策略：系统测试（整体）、确认测试（需求）、集成测试（体系结构的设计和构造）：（主要 自底向上、自顶向下、三明治 次要 回归测试、冒烟测试）、单元测试（源代码形式实现的每个单元）。 26.单元测试：通常被认为是编码阶段的附属工作。由于构件并不是独立的程序，因此，必须为每个测试单元开发驱动程序和桩程序。驱动程序只是一个主程序，接受数据并传递给构件，并打印结果。桩程序的作用是替换那些从属于被测构件的模块。桩程序使用从属模块的接口，可能做少量的数据操作，提供入口的验证，并将控制返回到被测模块。 27.regression testing回归测试 回归测试重新执行已测试过的某些子集，以确保变更没有传播不期望的副作用。
无论什么时候修正软件，软件配置的某些方面（程序、文档或支持数据）也发生变更。 回归测试有助于保证变更（由于测试或其他原因）不引入无意识行为或额外的错误。
回归测试可以手工进行，方法是重新执行所有测试用例的子集，或者利用捕捉/回放工具自动进行。28.smoke testing冒烟测试步骤：将已经转换为代码的软件构件集成到“构建”中去。 （一个构建包括所有的数据文件、库、可复用的模块以及实现一个或多个产品功能所需的工程化构件。）
设计一系列测试以暴露影响构建正确地完成其功能的错误。（其目的是为了发现极有可能造成项目延迟的“业务阻塞”错误）。
每天将该构建与其他构建及整个软件产品（以其当前的形式）集成起来进行冒烟测试。 （这种集成方法可以是自顶向下，也可以自底向上。）
29.system testing系统测试：恢复测试、安全测试、压力测试、性能测试、部署测试。
30.debugging techniques调试方法：蛮干、回溯、归纳、原因排除。
31. Internal and External Views内部视角和外部视角 任何工程化的产品（以及大多数其他东西）都可以采用以下两种方式之一进行测试：
（黑盒测试）了解已设计的产品要完成的指定功能，可以执行测试以显示每个功能是可操作的，同时，查找在每个功能中的错误；
（白盒测试）了解产品的内部工作情况，可以执行测试以确保“所有的齿轮吻合”——即内部操作依据规格说明执行，而且对所有的内部结构已进行了充分测试。
32.white box method 白盒测试 （1）保证一个模块中的所有独立路径至少被执行一次 （2）对所有的逻辑判定均需测试取真和取假两个方面 (3)在上下边界及可操作的范围内执行所有的循环 （4）检验内部数据结构以确保其有效性。
33. Deriving Test Cases导出测试用例 （1）以设计或源码为基础，画出相应的流图。
（2）确定所得流图的环复杂性。（3）确定线性独立路径的基本集合。（4）准备测试用例，强制执行基本集合中的每条路径。
34.简单循环Simple Loops （1）跳过整个循环（2）只有一次通过循环（3）两次通过循环（4）m次通过循环，m
35.等价类划分equivalence partitioning 等价类划分是一种黑盒测试方法，它将程序的输入划分为若干个数据类，从中生成测试用例。
36. SCM元素 配置管理系统元素 （1）构件元素 ——是一组具有文件管理系统 (如，数据库) 功能的工具，使我们能够访问和管理每个软件配置项。（2）过程元素 ——是一个动作和任务的集合，它为所有参与管理、开发和使用计算机软件的人员定义了变更管理 (以及相关活动) 的有效方法。（3）构造元素 ——是一组自动软件构造工具，用以确保装配了正确的有效构件 (即，正确的版本) 集。（4）人员元素 ——为有效实施SCM，软件团队使用的一组工具和过程特性 (包括其他 CM 元素) 。
37.基线baseline IEEE是这样定义基线的：已经通过正式评审和批准的规格说明或产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制规程才能修改它。
基线是软件开发中的里程碑，其标志是正式技术评审中已经获得批准的一个或多个软件配置项的交付。
38. Version Control版本控制的4个功能：（1）存储所有相关配置对象的 项目数据库 (中心存储库)； （2）存储配置对象所有版本(或能够通过与先前版本间的差异来构造任何一个版本)的 版本管理功能；(3)使软件工程师能够收集所有相关配置对象和构造软件特定版本的制作功能； (4)问题跟踪 (也叫做错误跟踪) 使团队能够记录和跟踪与每个配置对象相关的所有重要问题的状态。
39.SCM中心存储库SCM Repository SCM中心存储库是一组机制和数据结构，它使软件团队可以有效地管理变更。 中心存储库具有以下功能[For89]：
数据完整性、信息共享、工具集成、数据集成、方法执行、文档标准化。
中心存储库特征：Repository Features
（1）版本控制：保存所有这些版本，以便有效地管理产品发布，并允许开发者在测试和调试过程中可以返回到早先的版本。
（2）依赖性跟踪和变更管理：中心存储库要管理所存储的配置对象之间的各种关系。
（3）需求跟踪：跟踪由特定需求规格说明产生的所有设计构件、架构构件以及可交付产品。
（4）配置管理：跟踪表示特定项目里程碑或产品发布的一系列配置。 版本管理提供了所需的版本，而链接管理负责跟踪其相互依赖性。
（5）审核跟踪：了解变更是在什么时候、什么原因以及由谁完成等信息。