软件工程-外挂(格式完结版)Word格式文档下载.docx

软件工程-外挂(格式完结版)Word格式文档下载.docx

《软件工程-外挂(格式完结版)Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《软件工程-外挂(格式完结版)Word格式文档下载.docx（2页珍藏版）》请在冰豆网上搜索。

是用来模拟被测试模块的上一级模块，相当于被测模块的主程序

桩模块：

软件测试技术的一种，是指模拟被测试的模块所调用的模块，而不是软件产品的组成的部分。

黑盒测试：

在软件接口处进行测试，不需了解内部结构。

（也称行为测试，通过测试来检测每个功能是否都能正常使用，侧重于软件的功能需求）

白盒测试：

也称玻璃测试，按程序内部结构测试程序，是一种测试用例设计方法；

检查软件的过程细节

冒烟测试：

一种滚动集成测试方法，与每日构建紧密相连（自由测试中的一种，在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程）

α测试:

由代表性的最终用户在开发者的场所进行的测试

β测试：

在一个或多个最终用户场所进行的测

——————————————————————————————————————————————————————————————

●遗留软件的特点？

开发年代久远;

一直在使用;

在使用过程中被不断地修改以满足商业需要和算平台的变化;

可能仍然支持着核心业务;

质量差

●软件工程过程框架的基本模型，简要介绍其5种最基本的框架活动和普适性的活动？

基本模型有：

瀑布模型；

增量模型；

RAD模型；

原型模型；

螺旋模型；

协同开发模型；

基于构件模型；

形式化方法模型；

面向方面模型等。

5种基本框架活动：

沟通：

技术工作之前和客户沟通协作，理解利益相关者的项目目标，收集需求以定义软件特性和功能。

策划：

描述了需要执行的技术任务、可能的风险、资源需求，工作产品和工作进度计划。

建模：

创建模型（有助于客户和开发人员更好的理解软件需求）和设计（实现需求）。

构建：

包括编码和测试。

部署：

软件交付给用户，用户对其进行评测并给出反馈意见

普适性的活动：

软件项目跟踪和控制；

风险管理；

软件质量保证；

正式技术评审；

测量；

软件配置管理；

可复用管理；

工作产品的准备和生产

●软件工程整体实践的一般原则有哪些？

存在价值；

保持简洁；

保持愿景；

关注使用者；

面向未来；

计划复用；

认真思考

●瀑布模型的基本过程与特点？

基本过程：

从用户需求规格说明开始，通过计划、建模、构建和部署的过程，最终提供一个完整的软件并提供持续的技术支持。

项目启动、需求获取。

项目估算、进度计划、项目跟踪。

分析、设计。

编码、测试。

交付、支持、反馈

特点：

阶段间的顺序性和依赖性；

文档驱动性；

严格阶段评估；

开发初期需要清楚全部需求；

开发周期长、风险大。

●什么是增量过程模型？

它的优缺点是什么？

增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。

优点：

能在较短时间内向用户提交可完成部分工作的产品，用户有较充裕的时间学习和适应新产品，易于保证核心功能正确，可以基于早期版本来获取需求，项目完全失败的风险小。

可以为那些创新的功能开拓市场。

规避了资源缺乏的风险

缺点：

把用户需求转化为功能递增的不同版本可能比较难，难以确定所有版本共需的公用模块。

●原型开发模型的基本过程与特点？

又称为演化模型，主要针对实现不能完整定义需求的软件项目开发而言。

它是以一个“样品”为雏形，通过不断改进、完善样品，使得最后得到的产品就是客户所需要的。

主要思想：

先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。

体现主要的功能；

提供基本的界面风格；

展示比较模糊的部分，以便于确定或进一步明确，防患于未然；

原型最好是可以运行的，最少要在各主要功能模块之间能够建立相互连接。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

简述统一过程5个阶段的工作任务？

起始阶段：

包括客户沟通和策划活动。

细化阶段：

包括沟通和通用过程模型和建模活动。

构建阶段：

与通用软件过程中的构建活动相同，采用体系结构模型作为输入，开发或是获取软件构件，使得最终用户能够操作用例。

转换阶段：

包括通用构件活动的后期阶段以及通用部署活动的第一部分。

生产阶段：

与通用过程的部署活动一致。

监控软件的持续使用，提供运行环境的支持，提交并评估缺陷报告和变更请求。

●敏捷开发的基本原则是什么？

目的是尽快、尽好地交付软件产品；

2）变更是常事，并且欢迎；

3）经常有阶段性的成果提交，类似增量开发；

业务人员和开发人员紧密团结；

充分相信个人；

团队经常交流；

衡量进度的标准是有可见的成果；

保持稳定的但较快的速度；

时刻注意新技术；

简单，必须的；

软件的核心内容出自本团队的手笔；

团队经常开展自我总结，并对工作安排适时调整

●什么是XP的“Spike解决方案”。

严格遵循KIS（Keepitsimple）原则；

鼓励使用CRC卡；

在某个故事设计中遇到困难时，立即建立这部分设计的可执行原型，实现；

并评估设计原型（Spike解决方案）；

鼓励“重构”；

如果在某个故事设计中碰到困难，XP推荐立即建立这部分设计的可执行原型。

实现并评估设计原型被称为Spike解决方案，其目的是在真正的实现开始时降低风险。

对可能存在设计问题的故事确认其最初的估计。

●用自己的语言描述XP重构和结对编程的概念。

重构是以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。

这是一种净化代码以尽可能减少引入错误的严格方法。

实质上，重构就是在编码完成之后改进代码设计。

结对编程是这样一种程序设计实践：

两名程序员并肩同坐在同一台计算机前，共同探讨设计方案、共同设计算法、共同编写程序代码、共同完成各种测试。

（同一个算法、同一段代码或同一组测试、与两位程序员各自独立工作相比．结对编程往往只需花费大约一半的时间就能编写出质量更高的代码）

●简述Scrum敏捷过程模型？

Scrum原则与敏捷宣言是一致的，应用Scrum原则指导过程中的开发活动，过程由“需求、分析、设计、演化和交付”等框架性活动组成。

每一个框架活动中，发生于一个过程模式中的工作任务称为一个冲刺。

冲刺中进行的工作适应于当前的问题，由Scrum团队规定并常常作实时修改。

●简述需求工程的7个基本活动及各自的任务。

起始—询问一系列问题，建立问题的基本理解：

对问题谁需要解决方案、所期望方案的性质和客户与开发者之间初步交流和合作的有效性。

导出—从所有利益相关者（stakeholders）处获取需求。

精化—创建一个精确的需求模型，用于说明软件的功能、特征和信息的各个方面。

协商—确定一个开发者与客户均能接受的可提交系统。

规格说明—需求分析师的工作产品，为以下一种或几种:

写好的文档、图形化的模型、形式化的数学模型、一组用户场景（用例）、原型。

确认—通过评审机制，寻找：

内容或解释上的差错、可能需要进一步澄清的地方、丢失的信息、不一致（开发大型系统时的主要问题）和冲突或不现实的需求。

管理—在项目执行过程中标识、控制和跟踪需求以及变更需求

●简述需求模型到设计模型的转换模式

需求模型的每个元素都提供了创建4种设计模型所必需的信息，这四种设计模型是完整的设计规格说明所必需的软件设计过程中的信息流由基于场景的元素，基于类的元素，面向流的元素和行为元素所表示的需求模型是设计任务的输入。

●简述软件模块化和软件成本之间的关系。

模块数量增加时，只是使各个子模块的工作量之和有所减小，然而开发工作量还有很大一部分来自于模块间的接口和集成。

随着模块数增加，模块间的关系也随之增加，接口和集成的工作量也随之增加。

所以需要寻找最佳模块化程度平衡点。

如图：

●软件接口设计的三个重要元素。

1、用户界面（UI）；

2、和其他系统、设备、网络或其他的信息生产者或使用者的外部接口；

3、各种设计构件之间的内部接口.

●简述五种基本的软件体系结构。

以数据为中心的体系结构——数据存储驻留在这种体系结构的中心，其他构件会经常访问该数据存储，并对存储中的数据进行更新、增加、删除或者修改。

数据流体系结构——当输入数据经过一系列的计算构件和操作构件的变换形成输出数据时，可以应用这种体系结构。

调用和返回体系结构——该体系结构风格能够设计出一个相对易于修改和扩展的程序结构。

面向对象体系结构——系统的构建封装了数据和必须用于控制该数据的操作，构件间通过信息传递进行通信与合作。

层次体系结构——定义了一系列不同的层次，每个层次各自完成操作，这些操作逐渐接近机器的指令集。

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

●简述构件设计的基本原则。

开闭原则——模块应该对外延具有开放性，对修改具有封闭性

Liskov替换原则——子类可以替换它们的基类

依赖倒置原则——依赖于抽象，而非具体实现

接口分离原则——多个用户专用接口比一个通用接口要好

●:

简述构件设计中要完成的任务集

1、标识处所有与问题域相对应的设计类；

2、确定所有与基础设施域相对应的设计类；

3、细化所有不能作为复用构件的设计类：

3a、在类或构件的协作时说明消息的细节；

3b、为每一个构件确定适当的接口；

3c、细化属性并且定义相应的数据类型和数据结构；

3d、详细描述每个操作中的处理流；

；

4、说明持久数据源（数据库或文件）并确定管理数据源所需要的类；

5、开发并且细化类或构件的行为表示；

6、细化部署图以提供额外的实现细节；

7、考虑每一个构件级设计表示，并且时刻考虑其他选择

简述人机界面设计的黄金规则。

1置用户于控制之下：

不强迫用户进入不必要或不希望的交互模式；

提供灵活的交互；

允许用户交互被中断和撤；

当技能级别增长时可以使交互流线化并允许定制交互；

使用户与内部技术细节隔离；

2减少用户的记忆负担：

减少对短期记忆的要求；

建立有意义的缺省；

定义直观的快捷方式；

界面视觉布局应该基于真实世界的象征；

以不断进展的方式揭示信息；

3保持界面一致:

允许用户将当前任务放入有意义的环境中；

在应用系统家族内保持一致性；

如果已经建立起用户期望，轻易不要改变它。

简述人机