系统分析师软件工程师3Word文档下载推荐.docx
《系统分析师软件工程师3Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《系统分析师软件工程师3Word文档下载推荐.docx(18页珍藏版)》请在冰豆网上搜索。
细化阶段的任务是分析问题领域,建立健全的架构基础,淘汰项目中最高风险的元素。
在细化阶段,必须在理解整个系统的基础上,对架构做出决策,包括其范围、主要功能和诸如性能等非功能需求,同时为项目建立支持环境。
在构建阶段,要开发所有剩余的构件和应用程序功能,把这些构件集成为产品,并进行详细测试。
从某种意义上说,构建阶段是一个制造过程,其重点放在管理资源及控制操作,以优化成本、进度和质量。
构建阶段的主要任务是通过优化资源和避免不必要的报废和返工,使开发成本降到最低;
完成所有所需功能的分析、开发和测试,快速完成可用的版本;
确定软件、场地和用户是否已经为部署软件作好准备。
在构建阶段,开发团队的工作可以实现某种程度的并行。
即使是较小的项目,也通常包括可以相互独立开发的构件,从而使各团队之间实现并行开发。
当基线已经足够完善,可以安装到最终用户实际环境中时,则进入交付阶段。
交付阶段的重点是确保软件对最终用户是可用的。
交付阶段的主要任务是进行B测试,制作产品发布版本;
对最终用户支持文档定稿;
按用户的需求确认新系统;
培训用户和维护人员;
获得用户对当前版本的反馈,基于反馈调整产品,如进行调试、性能或可用性的增强等。
根据产品的种类,交付阶段可能非常简单,也可能非常复杂。
例如,发布现有桌面产品的新发布版本可能十分简单,而替换一个国家的航空交通管制系统可能就非常复杂。
交付阶段结束时还要进行技术评审,评审目标是否实现,是否应该开始演化过程,用户对交付的产品是否满意等。
1.敏捷软件过程强调:
让客户满意和软件尽早增量发布;
小而高度自主的项目团队;
非正式的方法;
最小化软件工程工作产品以及整体精简开发。
(4)不是采用这种软件开发过程的原因。
1.00)
A.难以提前预测哪些需求是稳定的和哪些需求会变化
B.对于软件项目开发来说,设计和实现可以做到基本分离
C.从制订计划的角度来看,分析、设计、实现和测试并不容易预测
D.可执行原型和部分实现的可运行系统是了解用户需求和反馈的有效媒介
[分析]敏捷软件过程主要有4大价值观:
个体和交互胜过过程和工具;
可以工作的软件胜过面面俱到的文档;
客户合作胜过合同谈判;
响应变化胜过遵循计划。
这种价值观的前提是软件需求是难以提前确定的,会不断地发生变化,可以采用可执行原型和部分实现的可运行系统来了解用户需求,通过用户的反馈来明确需求。
从制订计划的角度来看,分析、设计、实现和测试并不容易预测。
2.软件的逆向工程是一个恢复设计的过程,从现有的程序中抽取数据、体系结构和过程的设计信息。
逆向工程的完备性可以用在某一个抽象层次上提供信息的详细程度来描述,在大多数情况下,抽象层次越高,完备性就越低。
下列可以通过逆向工程恢复的制品中,完备性最低的是(5)。
A.过程的设计模型
B.程序和数据结构
C.对象模型、数据和控制流
D.UML状态图和部署图
[分析]根据试题1的分析,在本题给出的4个选项中,UML状态图和部署图可以用来描述实体之间的关系,因此,其层次最高,完备性最低。
3.条件测试是检查程序模块中所包含逻辑条件的测试用例设计方法,注重于测试程序中的条件。
BRO(BranchandRelationalOperator)测试保证能发现布尔变量和关系操作符只出现一次且没有公共变量的条件中的分支和条件操作符错误。
考虑条件C1:
(E1>E2)&(E3<E4),其中E1,E2,E3,E4是数学表达式,“&
”表示逻辑“与”,“>”和“=”是关系运算符,则C1的条件约束至少为(6)时,就可以检查C1中的关系操作符错误。
A.(>,=),(>,>),(>,<),(<,<),(=,<)
B.(<,<),(<,=),(<,>),(=,<),(=,=),(=,>),(>,<),(>,=),(>,>)
C.(>,<),(=,<),(>,=)
D.(>,<),(=,<),(>,=),(<,<)
[分析]BRO测试保证能发现布尔变量和关系操作符只出现一次而且没有公共变量的条件中的分支和条件操作符错误。
BRO策略利用条件C的条件约束。
有n个简单条件的条件C的条件约束定义为(D1,D2,…,Dn),其中Di(0<f≤n)表示条件C中第i个简单条件的输出约束。
如果C的执行过程中其每个简单条件的输出都满足D中对应的约束,则称条件C的条件约束D由C的执行所覆盖。
对于布尔变量B,B输出的约束说明B必须是真(t)或假(f)。
类似地,对于关系表达式,符号<、=、>用于指定表达式输出的约束。
作为简单的例子,考虑条件C0:
B1&
B2,其中B1和B2是布尔变量。
C0的条件约束式如(D1,D2),其中D1和D2是“t”或“f”,值(t,f)是C0的条件约束,由使B1为真B2为假的测试所覆盖。
BRO测试策略要求约束集{(t,t),(f,t),(t,f)}由C0的执行所覆盖,如果C0由于布尔算子的错误而不正确,至少有一个约束强制C0失败。
作为第二个例子,考虑C2:
(E3=E4),其中B1是布尔表达式,而E3和E4是算术表达式。
C2的条件约束形式如(D1,D2),其中D1是“t”或“f”,D2是<、=或>。
除了C2的第二个简单条件是关系表达式以外,C2和C0相同,所以可以修改C0的约束集{(t,t),(f,t),(t,f)},得到C2的约束集,注意(E3=E4)的“t”意味着“=”,而(E3=E4)的“f”意味着“>”或“<”。
分别用(t,=)和(f,=)替换(t,t)和(f,t),并用(t,<)和(t,>)替换(t,f),就得到C2的约束集{(t,=),(f,=),(t,<),(t,>)}。
上述条件约束集的覆盖率将保证检测C2的布尔和关系算子的错误。
我们再来看试题中的例子,考虑C1:
(E1>E2)&
(E3<E4),其中E1,E2,E3,E4是数学(算术)表达式。
C1的条件约束形式如(D1,D2),其中D1和D2是<、=或>。
我们可以直接从C0的约束集推导出C1的约束集。
(E1>E2)的“t”意味着“>”,“f”意味着“=”或“<”。
首先,根据(E1>E2)把((t,t),(f,t),(t,f))替换为{(>,t),(=,t),(<,t),(>,f)}。
而(E3<E4)的“t”意味着“<”,“f”意味着“=”或“>”,然后,我们再把{(>,t),(=,t),(<,t),(>,f))替换为{(>,<),(=,<),(<,<),(>,=),(>,>)},这就是C1的约束集,能够保证检测C1的关系操作符的错误。
4.服务组件体系结构(ServiceComponentArchitecture,SCA)是基于面向服务体系结构(ServiceOrientedArchitecture,SOA)的思想描述服务之间组合和协作的规范。
以下关于SCA的叙述,不正确的是(7)。
A.SCA定义了语言中立的服务组合方式,能够进行跨语言的服务调用
B.SCA加强组件的接口与传输协议的关联,提高组件的内聚性
C.SCA实现服务组件和其传输协议的绑定,这种绑定是可扩展的
D.SCA主要是为了满足软件集成的需要而创建的架构
[分析]服务组件体系结构(SCA)是一个规范,它描述用于使用SOA构建应用程序和系统的模型。
它可简化使用SOA进行的应用程序开发和实现工作。
SCA提供了构建粗粒度组件的机制,这些粗粒度组件由细粒度组件组装而成。
SCA将传统中间件编程从业务逻辑分离出来,从而使程序员免受其复杂性的困扰。
它允许开发人员集中精力编写业务逻辑,而不必将大量的时间花费在更为底层的技术实现上。
SCA方法的优势包括:
简化业务组件开发;
简化作为服务网络构建的业务解决方案的组装和部署;
提高可移植性、可重用性和灵活性;
通过屏蔽底层技术变更来保护业务逻辑资产;
提高可测试性。
SCA服务组件与传统组件的主要区别在于:
服务组件往往是粗粒度的,而传统组件以细粒度居多;
服务组件的接口是标准的,主要是WSDL接口,而传统组件常以具体API形式出现;
服务组件的实现与语言是无关的,而传统组件常绑定某种特定的语言;
服务组件可以通过组件容器提供QoS的服务,而传统组件完全由程序代码直接控制。
5.希赛公司欲实现一个数据处理软件,该软件需要从网络接收一组复杂的数据,然后分步进行解析和处理。
在这种情况下,采用(8)的体系结构风格比较适合。
A.远程过程调用
B.层次化
C.管道/过滤器
D.共享数据
[分析]层次系统组织成一个层次结构,每一层为上层服务,并作为下层客户。
例如,四层的分层式体系结构可以分为应用软件、业务软件、中间件和系统软件。
这种风格支持基于可增加抽象层的设计。
这样,允许将一个复杂问题分解成一个增量步骤序列的实现。
由于每一层最多只影响两层,同时只要给相邻层提供相同的接口,允许每层用不同的方法实现,同样为软件复用提供了强大的支持。
层次系统最广泛的应用是分层通信协议。
在这一应用领域中,每一层提供一个抽象的功能,作为上层通信的基础。
较低的层次定义低层的交互,最低层通常只定义硬件物理连接。
在管道/过滤器风格的软件体系结构中,每个构件都有一组输入和输出,构件读输入的数据流,经过内部处理,然后产生输出数据流。
这个过程通常通过对输入流的变换及增量计算来完成,所以在输入被完全消费之前,输出便产生了。
因此,这里的构件被称为过滤器,这种风格的连接件就像是数据流传输的管道,将一个过滤器的输出传到另一过滤器的输入。
此风格特别重要的过滤器必须是独立的实体,它不能与其他的过滤器共享数据,而且一个过滤器不知道它上游和下游的标识。
一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。
根据以上介绍,在本题中,希赛公司欲实现一个数据处理软件,该软件需要从网络接收一组复杂的数据,然后分步进行解析和处理,适合采用的是管道/过滤器风格。
6.希赛公司欲开发一个图像处理系统,在项目初期,开发人员对算法的效率、操作系统的兼容性和人机交互的形式等情况并不确定。
在这种情况下,采用(9)方法比较合适。
A.瀑布式
B.形式化
C.协同开发
D.快速原型
[分析]很多时候,客户提出了软件的一些基本功能,但是没有详细定义输入、处理和输出需求:
另一种情况下,开发人员可能对算法的效率、操作系统的兼容性和人机交互的形式等情况不确定。
在这种情况下,原型开发方法是最好的解决方法。
螺旋模型是一种演进式的软件过程模型,结合了原型开发方法的系统性和瀑布模型可控性特点。
它有两个显著特点,一是采用(10)的方式逐步加深系统定义和实现的深度,降低风险;
二是确定一系列(11),确保项目开发过程中的相关利益者都支持可行的和令人满意的系统解决方案。
2.00)
A.逐步交付
B.顺序
C.循环
D.增量
A.实现方案
B.设计方案
C.关键点
D.里程碑
[分析]螺旋模型是瀑布模型与快速原型模型相结合,并加入两者所忽略的风险分析所建立的一种软件开发模型。
螺旋模型是一种演化软件过程模型,它将原型实现的迭代特征与线性顺序模型中控制的和系统化的方面结合起来,使软件的增量版本的快速开发成为可能。
在螺旋模型中,软件开发是一系列的增量发布。
螺旋模型沿着螺线进行若干次迭代,每次迭代都包括制订计划、风险分析、实施工程和客户评估四个方面的工作。
它有两个显著特点,一是采用循环的方式逐步加深系统定义和实现的深度,同时降低风险:
二是确定一系列里程碑,确保项目开发过程中的相关利益者都支持可行的和令人满意的系统解决方案。
螺旋模型强调风险分析,使得开发人员和用户对每个演化层出现的风险有所了解,继而做出应有的反应。
因此,特别适用于庞大、复杂并具有高风险的系统。
与瀑布模型相比,螺旋模型支持用户需求的动态变化,为用户参与软件开发的所有关键决策提供了方便,有助于提高软件的适应能力,并且为项目管理人员及时调整管理决策提供了便利,从而降低了软件开发的风险。
在使用螺旋模型进行软件开发时,需要开发人员具有相当丰富的风险评估经验和专门知识。
另外,过多的迭代次数会增加开发成本,延迟提交时间。
7.极限编程是一种重要的敏捷开发方法,包含策划、设计、编码和测试四个框架活动的规则和实践。
下面关于极限编程的叙述,错误的是(12)。
A.极限编程中使用的重要技术是重构,既包括设计技术的重构,也包括构建技术的重构
B.极限编程提倡在基本设计完成后,立即进行编码实现,并进行测试
C.极限编程活动中的关键概念之一是“结对编程”,推荐两个人面对同一台计算机共同开发代码
D.极限编程过程中建立的单元测试应当使用一个可以自动实施的框架,支持代码修改后即时的回归测试策略
[分析]极限编程是一种重要的敏捷开发方法,包含规划、设计、编码和测试4个框架活动的规则和实践。
极限编程中使用的重要技术是重构,既包括设计技术的重构,也包括构建技术的重构;
极限编程提倡在基本设计完成后,团队不应该直接开始编码,而是开发一系列用于检测本次发布的包括所有故事(story)的单元测试:
极限编程活动中的关键概念之一是“结对编程”,推荐两个人面对同一台计算机共同开发代码;
极限编程过程中建立的单元测试应当使用一个可以自动实施的框架,支持代码修改后即时的回归测试策略。
8.需求工程帮助软件工程师更好地理解要解决的问题。
下列开发过程中的活动,不属于需求工程范畴的是(13)。
A.理解客户需要什么,分析要求,评估可行性
B.与客户协商合理的解决方案,无歧义地详细说明方案
C.向客户展现系统的初步设计方案,并得到客户的认可
D.管理需求以至将这些需求转化为可运行的系统
[分析]需求工程为以下工作提供了良好的机制:
理解客户需要什么,分析要求,评估可行性,协商合理的解决方案,无歧义地详细说明方案,确认规格说明,管理需求以至于将这些需求转化为可运行的系统。
需求工程并不关心采用何种设计方案解决问题。
9.面向团队的需求收集方法能够鼓励合作,为解决方案的各个要素提供建议,协商不同的方法,以及说明初步的需求方案。
下列关于面向团队的需求收集方法叙述,不恰当的是(14)。
A.举行团队需求收集会议,会议由软件工程师、客户和其他利益相关者共同举办和参加
B.拟定一个会议议程,与会者围绕需求要点,畅所欲言
C.会议提倡自由发言,不需要特意控制会议的进度
D.会议目的是识别问题,提出解决方案的要点,初步刻画解决方案中的需求问题
[分析]在进行面向团队的需求分析时,通常会举行团队需求收集会议,会议由软件工程师、客户和其他利益相关者共同举办和参加;
为会议拟订一个会议议程,既要涵盖所有的重要点,又要鼓励思维的自由交流;
会议由一位主持人控制会议进度,并保证会议主题不被偏离;
会议目的是识别问题,提出解决方案的要点,初步刻画解决方案中的需求问题。
10.质量功能部署(QFD)是一种将客户要求转化成软件需求的技术。
QFD的目的是最大限度地提升软件工程过程中客户的满意度。
为了这个目标,QFD确认了三类需求,常规需求、(15)和意外需求。
A.期望需求
B.基础需求
C.显式需求
D.功能需求
[分析]QFD确认了三类需求,分别是基本需求(常规需求)、期望需求和意外需求(兴奋需求)。
其中期望需求指的是那些隐含在产品或系统中,可能由于非常基础以至于用户没有显式说明的需求。
11.在软件需求工程中,需求管理贯穿整个过程。
需求管理最基本的任务是明确需求,并使项目团队和用户达成共识,即建立(16)。
A.需求跟踪说明
B.需求变更管理文档
C.需求分析计划
D.需求基线
[分析]需求是软件项目成功的核心所在,它为其他许多技术和管理活动奠定基础。
在软件需求工程中,需求管理贯穿整个过程。
需求管理最基本的任务是明确需求,并使项目团队和用户达成共识,即建立需求基线。
12.某大型移动通信运营商欲开发一个新的应用系统以替换原有系统。
在需求分析阶段,为尽快从已有系统文档资料和用户处获取整体系统需求,采用(17)的方法捕获需求最为合适。
A.用户访谈
B.联合需求计划
C.抽样
D.头脑风暴
[分析]需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。
常见的需求获取方式有用户访谈、问卷调查、抽样、联合需求计划、阅读文档、跟踪实践等。
根据题干描述,为尽快从已有系统文档资料和用户处获取整体系统需求,应该采用抽样的方法。
软件开发模型大体上可以分为三种类型:
第一种是以完全确定软件需求为前提的(18);
第二种是在软件开发初始阶段只能提供基本需求时采用的(19);
第三种是以形式化为基础的变换模型。
A.协同模型
B.瀑布模型
C.交互式模型
D.迭代式模型
B.瀑布模型
D.迭代式模型
[分析]软件开发模型大体上可以分为三种类型。
第一种是以软件需求完全确定为前提的瀑布模型;
第二种是在软件开发初始阶段只能提供基本需求时采用的迭代式或渐进式模型,例如,喷泉模型、螺旋模型、统一开发过程和敏捷方法等;
13.希赛公司欲开发一个基于web的考勤管理系统,客户对系统的基本功能、表现形式等要求并不明确,在这种情况下,采用(20)比较合适。
A.瀑布模型
B.螺旋模型
C.V模型
D.原型化模型
[分析]由于客户对系统的基本功能、表现形式等要求并不明确,在这种情况下,采用原型化模型比较合适。
可以通过开发原型,让用户运行原型来进一步明确系统的功能和表现形式。
净室软件工程是软件开发的一种(21)方法,可以开发出具有较高质量的软件。
它使用盒结构规约进行分析和建模,并将(22)作为发现和排除错误的主要机制,采用统计测试来获取验证软件可靠性所需要的信息。
A.形式化
B.迭代式
C.瀑布式
D.交互式
A.测试
B.仿真
C.实验
D.正确性验证
[分析]净室软件工程是软件开发的一种形式方法,它可以生成质量非常高的软件。
它使用盒结构规约(或形式化方法)进行分析和设计建模,并且强调将正确性验证,而不是测试,作为发现和消除错误的主要机制。
使用统计的测试来获取认证被交付软件的可靠性所必需的出错率信息。
净室方法从使用盒结构表示的分析和设计模型入手,一个“盒”在某特定的抽象层次上封装系统(或系统的某些方面)。
黑盒用于表达系统的对外可观测行为,状态盒封装状态数据和操作,清晰盒用于对某状态盒中的数据和操作所蕴涵的过程设计进行建模。
一旦完成了盒结构设计,则运用正确性验证。
软件构件的过程设计被划分为一系列子函数,为了证明每个子函数的正确性,要为每个函数定义出口条件并实施一组子证明。
如果每个出口条件均被满足,则设计一定是正确的。
一旦完成了正确性验证,便开始统计的使用测试。
和传统测试不同,净室软件工程并不强调单元或集成测试,而是通过定义一组使用场景、确定对每个场景的使用概率及定义符合概率的随机测试来进行软件测试。
将产生的错误记录和取样、构件和认证模型相结合使得可以数学地计算软件构件的可靠性。
净室哲学是一种严格的软件工程方法,它是一种强调正确性的数学验证和软件可靠性认证的软件过程模型,其目标和结果是非常低的出错率,这是使用非形式化方法难以或不可能达到的。
软件架构评估中,评估人员主要关注系统的质量属性,并确定采用何种架构更为合适。
在对某个应用软件进行评估时,该应用软件采用的web服务器所支持的并发连接数是整个系统性能的一个(23);
改变加密级别可能会对安全性和操作性均产生重要影响,则加密级别是系统的一个(24)。
A.检查点
B.敏感点
C.权衡点
D.风险点
B.敏感点c.权衡点D.风险点
[分析]软件架构评估可以只针对一个架构,也可以针对一组架构。
在架构评估中,评估人员主要关注系统的质量属性,并确定采用何种架构更为合适。
敏感点是一个或多个构件的特性,权衡点是影响多个质量属性的特性,是多个质量属性的敏感点。
在本题中,在对某个应用软件进行评估时,该应用软件采用的web服务器所支持的并发连接数是整个系统性能的一个敏感点;
改变加密级别可能会对安全性和操作性均产生重要影响,则加密级别是系统的一个权衡点。
14.以下关于敏捷开发原则的叙述中,错误的是(25)。
A.强调通过尽早地、持续地交付有价值的软件来使客户满意
B.经常交付可以工作的软件,但是每次都必须交付具有完整功能的系统
C.在团队内部,最具有效果并富有效率的信息传递方法是面对面的交谈
D.强调应对需求的持续变更,即使在项目后期也可灵活应对需求变更
[分析]敏捷开发的主要原则如下:
·
最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。
即使到了开发的后期,也欢迎改变需求。
敏捷过程利用变化来为客户创造竞争优势。
经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好。
但不要求每次交付的都是系统的完整功能。
在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
围绕被激励起来的人来构建项目,给他们提供所需要的环境和支持,并且信任他们能够完成工作。
在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。
工作的软件是首要的进度度量标准。
责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
不断地关注优秀的技能和好的设计会增强敏捷能力。
简单——使未完成的工作最大化的艺术——是根本的。
最好的架构、需求和设计出自于自组织的团队。
每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
15.以下敏