下载掌阅APP，畅读海量书库
立即打开
软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
换句话说，就是要深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求，导出目标系统逻辑模型，解决目标系统“做什么”的问题。
而具体在进行需求分析工作时，不能靠想象力行事，更不能完全站在开发方的角度上考虑，而应注意一切信息与需求都是站在实际应用的角度上考虑。
（1）B
软件体系结构是具有一定形式的结构化元素，即构件的集合。
可以做个简单的比喻，结构化程序设计时代是以砖、瓦、灰、沙、石、预制梁、柱、屋面板盖平房和小楼，而面向对象时代以整面墙、整间房、一层楼梯的预制件盖高楼大厦。构件怎样搭配才合理？体系结构怎样构造容易？重要构件有了更改后，如何保证整栋高楼不倒？每种应用领域需要什么构件（医院、工厂、旅馆）？有哪些实用、美观、强度、造价合理的构件骨架使建造出来的建筑（即体系结构）更能满足用户的需求？如同土木工程进入到现代建筑学一样，软件也从传统的软件工程进入到现代面向对象的软件工程，研究整个软件系统的体系结构，寻求建构最快、成本最低、质量最好的构造过程。
软件体系结构虽脱胎于软件工程，但其形成同时借鉴了计算机体系结构和网络体系结构中很多宝贵的思想和方法，最近几年软件体系结构研究已完全独立于软件工程的研究，成为计算机科学的一个最新的研究方向和独立学科分支。软件体系结构研究的主要内容涉及软件体系结构描述、软件体系结构风格、软件体系结构评价和软件体系结构的形式化方法等。解决好软件的重用、质量和维护问题是研究软件体系结构的根本目的。
综上所述，只有选项C不是软件体系结构研究的内容。
（2）C
“项目存在很多不确定性因素且项目的参与人员还不能完全理解项目开发的范围和需求的情况”就意味着项目的需求不明确、项目的风险较大，因此采用增量迭代模型或螺旋模型是比较适合的。
至于其他几种模型，均不太适合或完全不适合题干中所描述的情景。
（3）A
软件过程改进SPI（Software Process improvement）帮助软件企业对其软件（制作）过程的改变（进）进行计划、（措施）制订以及实施。其实施对象就是软件企业的软件过程，也就是软件产品的生产过程，当然也包括软件维护之类的维护过程，而对于其他的过程并不关注。
SPI的五条核心原则分别是：注重问题、强调知识创新、鼓励参与、领导层的统一、计划不断地改进。
“问题的解决是过程改进的核心，实践不仅是SPI组的目标也是它的起点。”这条原则为过程改进人员指明了目标，明确了方法。SPI就是要在实践中发现软件过程中的问题，并在实践中寻找和找到解决问题的办法，可以说过程改进就是在不断发现问题和解决问题的过程中不断向前发展的。
“改进是一种知识的创新，SPI是受知识的驱动的”。这条原则强调了知识创新在SPI中的作用，提醒了SPI人员在注重知识创新的同时更要注重知识的传播和扩散。
通常从事SPI工作的做法是，过程改进仅仅是过程改进人员的事情，其他人员只是被动地接受。而“合作促使改进产生”这条原则给予了我们很好的启发和提示。它告诉我们，过程改进不仅仅是一个人或几个人的事情，而是整个组织的事情。只有鼓励大家都积极参与，让这些人基于自身的经验和职业的判断力来实实在在地设计和开发新的过程，才能使设计出来的过程真正为他们所理解，为他们所用，从而实现过程的成功。这也是我们在过程改进工作中容易疏忽的地方。
“改进必须是综合了各个层次的人的力量。”SPI人员一定要保证SPI的目标与组织的整体目标是一致的，因为只有这样才能保证SPI工作得到各个领导层的赞同、支持和投入，才能综合利用各个层次的力量来推动SPI工作的前进。这是预防过程改进项目风险的重要手段。
“改进应该是一个不断持续的过程。”这一原则进一步提示和告诫SPI人员一定要认识到改进的不断持续的特性。到达顶点并不重要，关键的是，你现在处在一个上升过程中，达到一个目标就创造了另一个更高的目标，这个目标对我们的过程和环境都具有重要的意义。
这五条原则是从实践中发展而来、相互关联的SPI哲学，对开展SPI工作具有非常重要的指导作用。
显然，软件过程改进是项目开发人员需要参与的工作，但不是其主要工作。
（4）C
软件体系结构评估方式主要有以下三种。
①基于调查问卷或检查表的评估方式
调查问卷列出一系列可以应用到各种体系结构评估的相关问题，其中有些问题可能涉及体系结构的设计决策，有些问题涉及体系结构的文档，有的问题针对体系结构描述本身的细节问题。检查表中也包含一系列比调查问卷更细节和具体的问题，它们更趋向于考察某些关心的质量属性。
这一评估方式比较自由灵活，可评估多种质量属性，也可以在软件体系结构设计的多个阶段进行。但是由于评估的结果很大程度上来自评估人员的主观推断，因此不同的评估人员可能会产生不同甚至截然相反的结果，而且评估人员对领域的熟悉程度、是否具有丰富的相关经验也成为评估结果是否正确的重要因素。
尽管基于调查问卷与检查表的评估方式相对比较主观，但由于系统相关的人员的经验和知识是评估软件体系结构的重要信息来源，因而它仍然是进行软件体系结构评估的重要途径之一。
②基于场景的评估方式
这种软件体系结构评估方式分析软件体系结构对场景（也就是对系统的使用或修改活动）的支持程度，从而判断该体系结构对这一场景所代表的质量需求的满足程度。例如，用一系列对软件的修改来反映易修改性方面的需求，用一系列攻击性操作来代表安全性方面的需求等。
③基于度量的评估方式
度量是指为软件产品的某一属性所赋予的数值，如代码行数、方法调用层数、构件个数等。传统的度量研究主要针对代码，但近年来也出现了一些针对高层设计的度量，软件体系结构度量即是其中之一。代码度量和代码质量之间存在着重要的联系，类似地，软件体系结构度量应该也能够作为评判质量的重要的依据。
赫尔辛基大学提出的基于模式挖掘的面向对象软件体系结构度量技术、Karlskrona和Ronneby提出的基于面向对象度量的软件体系结构可维护性评估、西弗吉尼亚大学提出的软件体系结构度量方法等都在这方面进行了探索，提出了一些可操作的具体方案。我们把这类评估方式称为基于度量的评估方式。
综上所述，题干描述的是基于场景的软件体系结构评估方式。
（5）B
此题主要是考察软件测试工作的原则。
①尽早、不断地进行测试；
②程序员避免测试自己设计的程序；
③既要选择有效、合理的数据，也要选择无效、不合理的数据；
④修改后应进行回归测试；
⑤尚未发现的错误数量与该程序已发现错误数成正比。
依据以上原则可知：应尽量避免由程序员或开发小组测试自己的程序；在设计测试用例时，既要考虑合理的输入与输出条件，也要考虑不合理的输入与输出条件。
而软件验证与确认的对象包括软件开发各个阶段性的交付成果在内，所以自然是要贯穿到整个软件开发的全过程中的。
（6）D
GCC（GNU Compiler Collection，GNU编译器套装），是一套由GNU开发的编程语言编译器。GCC是Linux平台下最常用的编译程序，亦是自由的类UNIX及苹果电脑Mac OSX 操作系统的标准编译器。GCC除了支持C语言外，还支持多种其他语言，例如C++、Ada、Java、FORTRAN、Pascal等。
Visual Studio.NET是流行的Windows 平台应用程序开发环境，但它无法支持Java语言。
Project是项目管理软件。
Visio是一个制图软件。
（7）D
阶段管理评审依据定义好的每个开发阶段的开始和结束边界，检查该阶段的过程与工作成果是否符合质量标准，并且决定是否可以启动下一个阶段的工作。
而其他三项都是属于软件测试中的静态测试的范畴（桌前检查是程序员自己检查自己写的代码，代码走查与代码审查都是由一些同行专业人士来进行检查），明显与题意不符（题干中的相关干系人不一定是专业人士，而且题干中描述的并非开展测试工作）。
（8）A
软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组合连接起来。
（9）B
螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中的控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。螺旋线中的每个开发周期的四个象限分别是制订计划、风险分析、实施工程和客户评估，螺旋模型强调了分险分析，因此特别适用于庞大而复杂的、高风险的系统开发。
（10）D
结构化方法是强调开发方法的结构合理性以及所开发软件的结构合理性的软件开发方法。结构是指系统内各个组成要素之间的相互联系、相互作用的框架。程序流程图、数据流程图都是典型的结构化开发方法所需要使用的工具。
原型法是在投入大量的人力，物力之前，用最经济的方法开发出一个可实际运行的系统模型，用户在运行使用整个原型的基础上，通过对其评价，提出改进意见，开发人员根据这些意见对原型进行修改，该评价过程反复进行，使原型逐步完善，直到完全满足用户的需求为止。题干中的“项目组采用了先开发一个简化系统，待用户认可后再开发最终系统的策略”说明该项目采用了原型开发方法。
面向对象方法是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法，简称OO方法，是建立在“对象”概念基础上的方法学。对象是由数据和容许的操作组成的封装体，与客观实体有直接对应关系，一个对象类定义了具有相似性质的一组对象。而继承性是对具有层次关系的类的属性和操作进行共享的一种方式。所谓面向对象就是基于对象概念，以对象为中心，以类和继承为构造机制，来认识、理解、刻画客观世界和设计、构建相应的软件系统。从题干中看不出采用了面向对象开发方法。
用于开发计算机系统的形式化方法是描述系统性质的基于数学的技术，这样的形式化方法提供了一个框架，可以在框架中以系统的而不是特别的方式刻画、开发和验证系统。如果一个方法有良好的数学基础，那么它就是形式化的，典型地以形式化规约语言给出。从题干中看不出采用了形式化方法。
（11）C
2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的“敏捷宣言”，传递给世界，宣告了敏捷开发运动的开始。敏捷宣言的主要内容为：“个体和交互胜过过程和工具；可以工作的软件胜过全面的文档；客户合作胜过合同谈判；响应变化胜过遵循计划。在每对比对中，后者并非全无价值，但我们更看重前者”。
综上所述，正确答案应选A。
（12）A
软件维护是生命周期的一个完整部分。可以将软件维护定义为需要提供软件支持的全部活动。这些活动包括在交付前完成的活动，以及交付后完成的活动。交付前完成的活动包括编制交付后运行的计划和维护计划等。交付后的活动包括软件修改、培训和帮助资料等。软件维护包括如下类型：（1）更正性维护；（2）适应性维护；（3）完善性维护；（4）预防性维护。
综上可知，软件维护不仅仅是在软件交付之后为保障软件运行而要完成的活动，还包括软件交付前应该完成的活动。因此应选D。
（13）D
在软件测试工作中，应尽早地和不断地进行软件测试，因为软件错误发现得越早，纠正错误所需付出的代价就越低；在软件修改后要及时进行回归测试（指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。）；另外要充分注意软件测试中的群集现象，也可以认为是“80-20原则”。不要以为发现几个错误并且解决这些问题之后，就不需要测试了。反而这里是错误群集的地方，对这段程序要重点测试，以提高测试投资的效益。
综上所述，选项C和D不符合尽早测试的基本原则，由于模块一和模块二是相互关联的模块，修改其中任意一个模块后都要对两个模块进行再测试；选项A不符合第“80-20原则”，模块二中发现的错误比模块一多，因此模块二应该是回归测试的重点。选项B最符合题意，因此应选B。
（14）B
软件复用是指将已有的软件及其有效成分用于构造新的软件或系统。组件技术是软件复用实现的关键。模式是一条由三部分组成的规则，它表示了一个特定的环境，一个问题和一个解决方案之间的关系。
接口是对操作规范的说明。接口只说明了操作应该做什么（WHAT），但没有定义操作如何做（HOW）。接口在面向对象分析和设计过程中起到了至关重要的桥梁作用，系统分析员通常先把有待实现的功能封装并定义成接口，而后期程序员依据此接口进行编码实现。
继承可分为单继承与多继承。其中Java是单继承的语言。
（15）C
软件维护是指在软件运行维护阶段对软件产品所进行的修改。要求进行软件维护的原因主要可归纳为3种类型。
①改正在特定的使用条件下暴露出来的一些潜在程序错误或设计缺陷。
②因在软件使用过程中数据环境发生变化或处理环境发生变化，对软件进行的修改。
③用户和数据处理人员在使用时常提出改进现有功能、增加新的功能，以及改善总体性能的要求，为了满足这些要求需要进行软件修改。
与上述原因相对应，可将维护活动归纳为：改正性维护、适应性维护和完善性维护。
除了上述3类维护外，还有一类维护活动叫预防性维护。
④预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础的维护活动。预防性维护可定义为：“用今天的技术修改昨天的软件，以满足明天的需要”。
本题题干中描述的维护方式属于顶防性维护。
（16）A
DFD即数据流图或称数据流程图（Data Flow Diagram）是一种便于用户理解、分析系统数据流程的图形工具。它摆脱了系统的物理内容，精确地在逻辑上描述系统的功能、输入、输出和数据存储等，是系统逻辑模型的重要组成部分。
DFD应由数据流、加工、数据存储和外部实体4个要素构成。外部实体是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地和系统所产生数据的归宿地。
另外需注意：分层数据流图中的父图与子图需保持平衡（子图的输入输出数据流同父图相应加工的输入/输出数据流必须一致（不是数目必须相等），此即父图与子图的平衡。）
（17）D（18）D
极限编程技术XP（Extreme Programming）是一种开发软件的轻量级的方法，也是敏捷开发方法的代表之一。XP适用于中小型软件开发团队、并且客户的需求模糊或需求多变的情况。
XP是一种近似于螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期。通过积极的交流和反馈，可以根据实际情况及时地调整开发过程。
（19）A
软件系统可以划分为若干个小的简单的功能模块，每个模块可以独立开发、测试。模块独立是软件设计开发的基本原则之一。
耦合是指多个模块之间联系的紧密程度，耦合越高则模块的独立性越差；内聚是指同一模块内部各元素之间联系的紧密程度，内聚度越低，模块的独立性越差。
耦合性和内聚性是模块独立性的两个定性标准，将软件系统划分模块时，应尽量做到高内聚、低耦合，提高模块的独立性。
（20）A
结构化方法是一种传统的软件开发方法，它是由结构化分析、结构化设计和结构化程序设计三部分有机组合而成的。它的基本思想：把一个复杂问题的求解过程分阶段进行，而且这种分解是自顶向下，逐层分解（求精），使得每个阶段处理的问题都控制在人们容易理解和处理的范围内。
结构化方法的基本要点是：自顶向下、逐步求精、模块化设计、结构化编码。
结构化分析方法是以自顶向下，逐步求精为基点，以一系列经过实践的考验被认为是正确的原理和技术为支撑，以数据流图，数据字典，结构化语言，判定表，判定树等图形表达为主要手段，强调开发方法的结构合理性和系统的结构合理性的软件分析方法。
结构化设计方法是以自顶向下，逐步求精，模块化为基点，以模块化，抽象，逐层分解求精，信息隐蔽化局部化和保持模块独立为准则的设计软件的数据架构和模块架构的方法学。
结构化方法是一种面向数据流的开发方法，是软件工程中最早出现的开发方法，特别适合于数据处理领域。
（21）A
在建立抽象模型时，我们会发现很少有类会单独存在，大多数都将会以某种方式彼此协作，因此我们还需要描述这些类之间的关系。关系是事物间的连接，在面向对象建模中，有4个很重要的关系值得关注。
①依赖关系
有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖于元素X。在UML（Unified Modeling Language）中，使用带实心箭头的虚线表示依赖关系。
在类中，依赖由各种原因引起，如：一个类向另一个类发消息；一个类是另一个类的数据成员；一个类是另一个类的某个操作参数。如果一个类的界面改变，它发出的任何消息可能不再合法。
②泛化关系
泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说子类是从父类中继承的，而父类则是子类的泛化。在UML中，使用带空心箭头的实线表示，箭头指向父类。
在UML中，对泛化关系有3个要求。
a．子类应与父类完全一致，父类所具有的关联、属性和操作，子元素都应具有；
b．子类中除了与父类一致的信息外，还包括额外的信息；
c．可以使用子父类实例的地方，也可以使用子类实例。
③关联关系
关联表示两个类之间存在某种语义上的联系。例如，一个人为一家公司工作，一家公司有许多办公室。我们就认为人和公司、公司和办公室之间存在某种语义上的联系。
关联关系提供了通信的路径，在UML中，使用一条实线来表示关联关系。有两种特殊的关联关系值得重视。
a．聚合关系：聚合表示类之间的关系是整体与部分的关系。例如一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘，就是聚合的一个例子。在UML中，使用一个带空心菱形的实线表示，空心菱形指向的是代表“整体”的类。聚合关系中的整体与部分的生命周期可以不同，即当整体的生命终止时，部分的生命可以继续存在。
b．组合关系：如果聚合关系中的表示“部分”的类的存在，与表示“整体”的类有着紧密的关系，例如“公司”与“部门”之间的关系，那么就应该使用“组合”关系来表示。在UML中，使用带有实心菱形的实线表示。聚合关系中的整体与部分的生命周期必定不同，即当整体的生命终止时，部分的生命也不再存在。
④实现关系
实现关系是用来规定接口和实现接口的类或构件之间的关系。接口是操作的集合，这些操作用于规定类或构件的服务。在UML中，使用一个带空心箭头的虚线表示。
（22）A （23）D
逆向工程（Reverse Engineering）又叫反向工程，其概念来自于硬件。硬件厂商总想弄到竞争对手产品的设计和制造的“奥秘”，但是又得不到现成的档案，只好拆卸对手的产品并进行分析，导出该产品的一个或多个设计与制造的规格说明。
软件的逆向工程是完全类似的，由于受到法律的约束，进行逆向工程的程序常常不是竞争对手的，而是自己开发的程序，有些是多年以前开发出来的。这些程序没有规格说明，开发人员可能早已流失，导致对软件的了解很模糊。因此，软件的逆向工程是分析程序，力图在比源代码更高的抽象层次上建立程序表示的过程。逆向工程是一个设计恢复的过程，其工具可以从已有的程序中抽取数据结构、体系结构和程序设计信息。
因此，逆向工程可以从源程序抽取出设计信息，但是，抽象的层次、文档的完整性、工具和分析员一起工作的程度、以及过程的方向性却是高度可变的。
逆向工程过程及用于实现该过程的工具的抽象层次，是指可从源代码中抽取出来的设计信息的精密程度。理想地，抽象层次应该尽可能高，即逆向工程过程应该能够导出过程的设计表示（一种低层的抽象）；程序和数据结构信息（稍高一点层次的抽象）；数据和控制流模型（一种相对高层的抽象）；以及实体—关系模型（一种高层抽象）。随着抽象层次增高，软件工程师获得更有助于理解程序的信息。
（24）C
用例可以被通俗地理解为信息系统的功能，用例之间的关系主要包括包含关系、扩展关系和泛化关系。
①包含关系（Include）
要点如下。
a．一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这称为包含关系。
b．如果两个以上的用例有大量一致的功能，则可以将这个功能分解到另一个用例中（作为包含关系的提供者用例）。
c．一个用例的功能太多时，可以用包含关系建模两个或多个用例。
表示方法：在UML中，包含关系表示为带<<include>>字样虚线箭头，箭头指向被包含的用例。
②扩展关系（Extend）
要点如下。
a．一个用例（扩展用例）可以被定义为基础用例的增量扩展，这称为扩展关系。
b．一般基础用例的执行不会涉及扩展用例，只有特定的条件下扩展用例才被执行。
c．扩展关系为处理异常或构建灵活的系统框架提供了一种十分有效的办法。
表示方法：在 UML中，扩展关系表示为带<<extend>>字样虚线箭头，箭头指向被扩展的用例（即基础用例）。
③泛化关系（Generalization）
要点如下。
a．一个用例被特别列举为一个或多个用例，这被称作用例泛化。
b．子用例表示父用例的特殊形式。子用例从父用例处继承属性和行为，还可以添加、覆盖或改变继承的行为。
c．父用例被使用时，任何子用例也可以被使用。
d．如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。
表示方法：在 UML中，用例泛化表示为一个三角的实线箭头，从子用例指向父用例。
综上所述，题目中描述的用例间的关系为包含关系，即用例UC2包含了用例UC1。
（25）D
在B/S（即Browser/Server）模式下，把所有应用功能（业务逻辑）和数据库都放在了服务器端，客户端只需一个浏览器就可以使用系统功能，无须安装专用软件，因此在客户端也就无须进行专门的维护（即“零维护）。但B/S模式下的传输速率和运算能力没有C/S模式下效果好。而C/S模式的主要缺点是客户端的维护工作量大、无法把软件系统拓展到因特网上等。
（26）C
选项A、B、C、D对应的分别是活动图、用例图、部署图和顺序图。
（27）C
常见的信息系统开发方法结构化法、原型法、面向对象方法。其中原型法也称原型化法、快速原型法，原型法的基本思想与结构化方法不同，原型法认为在很难一下子全面准确地提出用户需求的情况下，首先不要求一定要对系统做全面、详细的调查、分析，而是本着开发人员对用户需求的初步理解，先快速开发一个原型系统，然后通过反复修改来实现用户的最终系统需求。系统分析、设计与实现都是随着对一个工作模型的不断修改而同时完成的，相互之间并无明显界限，也没有明确分工。
（28）A
Alpha测试（又名α测试）是指软件开发公司组织内部人员模拟各类用户行为对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。紧随其后的Beta测试（又名β测试）是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。
冒烟测试：术语源自硬件行业。对一个硬件或硬件构件进行更改或修复后，直接给设备加电。如果没有冒烟，则该构件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
静态测试是指被测程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态测试一般采用桌前检查、代码走查、代码审查。
（29）A
边界值分析：经验表明，软件在处理边界情况时最容易出错。设计一些测试用例，使软件恰好运行在边界附近，暴露出软件错误的可能性会更大些。每一个等价的边界，都应该着重测试，选取的测试数据应该恰好等于、稍小于或稍大于边界值。
（30）A