软件工程复习提纲(附答案)

软件工程第一章软件工程介绍1、软件的特性：P3软件是设计开发的，而不是传统意义上的生产制造；软件不会磨损；大多数软件仍是根据实际的客户需求制定的。

2、计算机软件的七大分类：P5系统软件、应用软件、工程/科学软件、嵌入式软件、产品线软件、Web应用软件、人工智能软件。

3、遗留系统发生系统演化的原因：P6软件需要修改其适应性，从而可以满足新的计算环境或技术的需求软件必须根据新的业务需求进行升级软件必须扩展以具有与更多现代系统和数据库的协作能力软件架构必须进行改建以适应多样化的网络环境4、软件神话：管理者，用户，从业者P135、软件的定义：P3软件是：指令的集合，通过执行这些指令可以满足预期的特征，功能和性能需求；数据结构，它使得程序可以充分利用信息；描述程序操作和使用的文档。

第二章过程综述1、软件工程的三个要素：工具，过程，方法P8过程：软件过程将各个技术层次结合在一起，并实施合理地，及时地开发计算机软件方法：为建造软件提供技术上的解决方法。

工具：为过程和方法提供自动化或半自动化的支持。

2、通用软件过程框架：沟通，策划，建模，构建，部署P9沟通：这个框架活动包含了与客户之间大量的交流和协作，还包括需求获取以及其他相关活动策划：指为后续的软件工程工作制定计划。

建模：它包括创建模型和设计两方面。

创建模型有助于客户和开发人员更好得理解软件需求；设计可以实现它。

构建：它包括编码和测试。

部署：软件交付到用户，用户对其进行评测并给出意见3、能力成熟度模型：P22 ???第0级：不完全级；第1级：已执行级；第2级：已管理级；第3级：已定义级；第4级：已定量管理级；第5级：优化级；第三章过程模型1、简述惯例框架包含的主要活动：P19沟通、策划、建模、构建、部署2、简述瀑布模型所包含的主要框架活动：P24沟通、策划、建模、构建、部署3、简述瀑布模型在实际运用中所面临的问题（缺点）：P24实际的项目很少遵守瀑布模型提出的顺序客户通常难以清楚地描述所有的需求客户必须有耐心，因为只有在项目的后期，他们才能看到可执行的程序。

4、演化过程模型生产的背景：P26在开发工程中，业务和产品需求经常发生变化，直接导致最终的产品难以实现；严格的交付时间使得开发团队不可能圆满完成软件产品，但是必须交付功能有限的版本以应对竞争或商业压力；很好地理解了核心产品和系统需求，但是产品或系统扩展的细节问题却没有定义。

5、简述基于原型开发模型的软件开发过程：P26原型开发范型开始于沟通，定义软件的整体目标，明确已知的需求，迅速策划一个原型开发迭代并进行建模，快速设计产生一个原型，对原型进行部署，然后由客户或者用户进行评价。

根据反馈，进一步细化软件的需求。

6、原型开发的缺点：P27为了尽快完成软件，开发者没有考虑整体软件质量和长期的可维护性。

为了使一个原型尽快运行起来，往往在实现过程采用折衷的手段。

7、统一过程的三个特点：P34用例驱动，以架构为核心，迭代并且增量8、简述统一过程（UP）的5个阶段的主要内容：P34起始，细化，构建，转换和生产UP的起始阶段包括客户沟通和策划活动UP的细化阶段包括用户沟通和通用过程模型的建模活动UP的构建阶段与通用软件过程中的构建活动相同UP的转换阶段包括通用构建活动的后期阶段以及第一部分通用部署活动UP的生产阶段与通用过程的部署活动一致9、螺旋模型强调了其他模型均忽略了的风险分析。

P2910、横切关注点的定义：P33如果某个关注点设计系统多个方面的功能，特性和信息，这些关注点通常称为横切关注点。

第四章敏捷视角下的过程1、软件工程的敏捷理念强调4个关键问题：P57具有控制力的自我组织团队对所开展工作的重要性；团队成员之间、开发参与者与客户之间的交流与合作；对“变更代表机遇”的认识；强调快速软件交付以让客户满意。

2、简述极限编程（XP）过程模型所包含的4个主要框架活动：策划，设计，编码，测试P45 策划：策划活动开始于建立一系列描述待开发软件必要特征与功能的“故事”设计：XP设计严格遵循KIS（Keep It Simple，保持简洁）原则，即使用简单而不是复杂的表述。

编码：XP推荐在故事开发和基本设计完成之后，团队不应该直接开始编码，而是开发一系列用于检测本次发布的包括所有故事的单元测试，一旦建立起单元测试，开发者就可以更集中精力于必须实现的内容以通过单元测试。

测试：在编码之前开始建立单元测试是XP方法关键因素。

第五章系统工程？？？1、计算机系统的6个系统要素：P73软件、硬件、人员、数据库、文档、规程2、Hatley-Pirbhai建模：用户界面、输入、系统功能和控制、输出、维护和自检P813、系统环境图的表示方法P81第六章需求工程1、需求工程的过程：P63起始、导出、精化、协商、规格说明、确认和管理2、在项目起始阶段，软件工程师会询问一些视乎与项目无直接关系的问题，目的是对问题、方案需求方、期望方案的本质、客户和开发人员之间初步的交流合作的效果建立基本的谅解。

P643、为什么导出需求这么困难：范围问题、理解问题、易变问题P89范围问题：系统的边界不清楚，或客户/用户的说明带有多余的技术细节，这些细节可能会混淆而不是澄清系统的整体目标理解问题：客户/用户并不完全确定需要什么，对其计算环境的能力和限制所知甚少，对问题域没有完整的认识，与系统工程师在要求沟通上有问题，省略那些他们认为是“明显的”信息，确认的需求和其他客户/用户的需求相冲突，需求说明有歧义或不可测试。

易变问题：需求随时间变化。

4、用例的定义：讲述了能表达场景的故事：最终用户如何在一特点环境下和系统交互P735、在需求工程的导出阶段，三个主要的需求收集活动是：主持人会议、QFD和用户场景开发P71、P816、常用的需求工程描述工具：用例图、数据流程图第七章构建分析模型（注：需求模型即分析模型，为同义词，详见P76下面注释）0、分析模型在系统描述和设计模型之间建立桥梁：P851、需求模型必须实现的目标：P85①客户描述需要什么②为软件设计奠定基础③定义在软件完成后可以被确认的一组需求2、分析模型的所有元素都可以直接跟踪到设计模型P853、分析模型必须实现的目标：基于计算机系统提供必要的信息、功能和行为域的说明P764、分析模型的4个元素：基于场景的元素，面向信息流的元素，基于类的元素，行为元素P1275、UML泳道图是活动图的一种变形，可以让建模人员表示用例所描述的活动流，同时指示哪个参与者或分析类对是由活动矩形所描述的活动负责。

P946、UML状态图为每个类表现活动状态和导致这些活动状态变化的事件7、UML顺序图说明事件如何引发一个对象到另一个对象的转移8、简述CRC（类-职责-协作者）建模的内容P103CRC模型实际上表示类的标准索引卡片的集合。

这些卡片被分为三部分，顶部写类名，下面左侧部分列出类的职责，右侧部分列出类的协作关系。

9、使用UML类图来举例说明组合聚合之间的区别10、使用UML类图举例说明关联和依赖之间的区别P102、P10811、系统分析的经验原则P86①模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高点。

②需求模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域，功能和系统行为的深入理解。

③关于基础结构和其他非功能的模型应推延到设计阶段再考虑。

④最小化整个系统内的关联。

⑤确认需求模型为所有共利益者都带来价值。

⑥尽可能保持模型简洁。

第八章设计工程1、简述良好设计的三个特征：P129①设计必须实现所有包含在需求模型中的明确需求，而且必须满足客户希望的所有隐含需求。

②对于那些生成代码的人和那些进行测试以及随后维护软件的人而言，设计必须是可读的、可以理解的指南。

③设计必须提供软件的全貌，从实现的角度说明数据域、功能域、和行为域。

2、设计模型包含的四种元素是什么：数据、体系结构、构件和接口。

P1273、软件体系结构的定义：软件的整体结构和这种结构为系统提供概念上完整性的方式P1464、模块应该详细说明且精心设计以求在某个模块中包含的信息不被不需要这些信息的其他模块访问P133信息隐蔽：每个模块对其他所有模块都隐蔽自己的设计决策。

P134隐蔽意味着通过定义一系列独立的模块可以得到有效的模块化，独立模块相互之间只交流实现软件功能所必须的那些信息。

隐蔽定义并加强了模块内的过程细节和模块所使用的任何局部数据结构的访问约束。

5、重构的定义：是使用这样一种方式改变软件系统的过程：不改变代码设计的外部行为而是改进其内部结构P1366、举例说明逐步求精P1357、框架和设计模式之间的区别P136 ？？？8、PDL语言P185第九章进行体系结构设计1、简述软件体系结构的作用：P146分析设计在满足规定需求方面的有效性；在设计变更相对容易的阶段，考虑体系结构可能的选择方案；降低与软件构造相关联的风险2、软件体系结构的典型分类：以数据为中心的体系结构，数据流体系结构，调用和返回体系结构，面向对象体系结构，层次体系结构（以图例来说明）P1513、体系结构环境图所包含的要素，以图例来说明P155第十一章软件测试策略1、简述软件测试策略的螺旋模型：单元测试、集成测试、确认测试、系统测试P258单元测试：侧重于以源代码形式实现的每个单元（例如，构件、类或Web应用内容对象）。

集成测试：测试重点在于软件体系结构的设计和构造。

确认测试：依据已经建立的软件，对需求（作为软件需求建模的一部分而建立）进行确认系统测试：将软件与系统的其他成分作为一个整体来测试。

2、简述单元测试中驱动程序和桩程序的作用P262驱动程序：只是一个“主程序”，它接受测试用例数据，将这些数据传递给构件并打印相关结果。

桩程序的作用：是替换那些从属于将要测试的构建或被其调用的构建。

3、集成测试的两种方式：增量集成与一步到位P2634、试以图例描述自顶向下集成测试的方法过程P264(图)5、简述确认测试的两种主要方法：α测试和β测试P269α测试是由有代表性的最终用户在开发者的场所进行β测试在一个或多个最终用户场所进行6、系统测试的主要方法：恢复测试、安全测试、压力测试、性能测试P2707、三种调试方法：蛮力法，回溯法，原因排除法P274第十二章测试战术1、好的测试所具有的特性P279好的测试具有较高的发现错误的可能性好的测试是不冗余的好的测试应该是“最佳品种”好的测试应该既不太简单也不太复杂2、黑盒测试的定义P278-----采用外部观察黑盒测试，也称行为测试，侧重于软件的功能需求3、白盒测试的定义P271-----需要内部观察白盒测试，有时也成为玻璃盒测试，是一种测试用例设计方法，它利用作为构件层设计的一部分而描述的控制结构来生成测试用例。