8软件工程考试重点

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体系结构软件的整体结构和这种结构为系统提供概念完整性的方式属性：结构特性、外部功能特性、相关系统族。

rmation Hiding信息隐蔽模块中包含的信息（算法和数据）不被不需要这些信息的其他模块访问。Why减少“负效应”的可能性.限制全局影响局部的设计决策.强调通过控制接口通信.不提倡使用全局数据.导致封装——高质量设计的属性.导致高质量软件

10.Functional Independence功能独立可以通过两条定性的标准进行评估：内聚性和耦合性。内聚性显示了某个模块相关功能的强度。耦合性显示了模块间的相互依赖性。

11.refactoring重构重构是使用这样一种方式改变软件系统的过程：不改变代码[设计的外部行为而是改进其内部结构。当重构软件时，检查现有设计：冗余性没有使用的设计元素低效的或不必要的算法拙劣的或不恰当的数据结构其他设计不足，修改这些不足以获取更好的设计。12.Design Classes设计类高内聚性cohesion和低耦合性coupling一个内聚的设计类具有小的、集中的职责集合，并且专注于使用属性和方法来实现那些职责。协作保持在一个可以接受的小范围内。13.设计模型的元素design model elements1.数据设计元素：数据结构、数据库体系结构 2.体系结构设计元素：来源：应用领域、特定的需求模型元素（数据流图、分析类、现有问题中的关系和协作）、风格和模式 3.接口设计元素interface4.构件级设计元素 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)]x100%

24.software testing软件测试:测试是在交付产品给最终用户之前，带着特定的目的在运行程序的过程中发现错误。25.验证与确认verification and validation:验证是指确保软件正确地实现某一特定功能的一系列活动。确认指的是确保开发的软件可追溯到客户需求的另外一系列活动。25.testing strategy测试策略：系统测试（整体）、确认测试（需求）、集成测试（体系结构的设计和构造）：（主要自底向上、自顶向下、三明治次要回归测试、冒烟测试）、单元测试（源代码形式实现的每个单元）。26.单元测试：通常被认为是编码阶段的附属工作。由于构件并不是独立的程序，因此，必须为每个测试单元开发驱动程序和桩程序。驱动程序只是一个主程序，接受数据并传递给构件，并打印结果。桩程序的作用是替换那些从属于被测构件的模块。桩程序使用从属模块的接口，可能做少量的数据操作，提供入口的验证，并将控制返回到被测模块。27.regression testing回归测试回归测试重新执行已测试过的某些子集，以确保变更没有传播不期望的副作用。

无论什么时候修正软件，软件配置的某些方面（程序、文档或支持数据）也发生变更。

回归测试有助于保证变更（由于测试或其他原因）不引入无意识行为或额外的错误。

回归测试可以手工进行，方法是重新执行所有测试用例的子集，或者利用捕捉/回放工具自动进行。28.smoke testing冒烟测试步骤：将已经转换为代码的软件构件集成到“构建”中去。（一个构建包括所有的数据文件、库、可复用的模块以及实现一个或多个产品功能所需的工程化构件。）

设计一系列测试以暴露影响构建正确地完成其功能的错误。（其目的是为了发现极有可能造成项目延迟的“业务阻塞”错误）。

每天将该构建与其他构建及整个软件产品（以其当前的形式）集成起来进行冒烟测试。

（这种集成方法可以是自顶向下，也可以自底向上。）

29.system testing系统测试：恢复测试、安全测试、压力测试、性能测试、部署测试。