正确答案: C

原型开发模型

题目：博学网软件开发团队欲开发一套管理信息系统，在项目初期，用户提出了软件的一些基本功能，但是没有详细定义输入、处理和输出需求。在这种情况下，该团队在开发过程应采用（）

解析：瀑布模型也称为生命周期法，是生命周期法中最常用的开发模型，它把软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型主要用于需求明确或很少变更的项目。原型法适合于用户没有肯定其需求的明确内容的时候。它是先根据已给的和分析的需求，建立一个原始模型，这是一个可以修改的模型（在生命周期法中，需求分析成文档后一般不再进行修改）。在软件开发的各个阶段都把有关信息相互反馈，直至模型的修改，使模型渐趋完善。在这个过程中，用户的参与和决策加强了，最终的结果是更适合用户的要求。这种原型法成败的关键及效率的高低，关键在于模型的建立及建模的速度。增量模型融合了瀑布模型的基本成分（重复地应用）和原型的迭代特征。采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的"增量"。当使用增量模型时，第一个增量往往是核心的产品，即实现了基本的需求，但很多补充的特性还没有发布。核心产品交用户使用，使用和/或评估的结果是下一个增量的开发计划。该计划包括对核心产品的修改，使其能更好地满足用户的需要，并发布一些新增的特点和功能。这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。RAD是一个线性顺序的软件开发模型，强调极短的开发周期和可复用程序构件的开发。RAD模型是瀑布模型的一个高速变种，通过使用基于构件的建造方法获得了快速开发。如果需求理解得很好，且约束了项目范围，RAD模型使得一个开发组能够在很短时间内创建出功能完善的系统。RAD方法主要用于信息系统应用软件的开发，它包含业务建模、数据建模、处理建模、应用生成、测试及反复5个阶段。

查看原题 查看所有试题

学习资料的答案和解析：

[单选题]软件（）是指改正产生于系统开发阶段而在系统测试阶段尚未发现的错误。

正确性维护

解析：本题考查软件维护相关知识。 　　软件维护的类型包括改正性维护（正确性维护）、适应性维护、完善性维护、预防性维护。 　　改正性维护：在软件交付使用后，必然会有一部分隐藏的错误被带到运行阶段来。这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程，就叫做改正性维护。 　　适应性维护：随着计算机的飞速发展，外部环境（新的硬、软件配置）或数据环境（数据库、数据格式、数据输入输出方式、数据存储介质）可能发生变化，为了使软件适应这种变化，而去修改软件的过程就叫做适应性维护。 　　完善性维护：在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。 　　预防性维护：为了提高软件的可维护性、可靠性等而提出的一种维护类型，它为以后进一步改进软件打下良好基础。通常，预防性维护定义为：“把今天的方法学用于昨天的系统以满足明天的需要”。也就是说，采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。

[单选题]以下关于需求管理的叙述中，正确的是（）

需求管理是一个对系统需求及其变更进行了解和控制的过程

解析：需求管理是一个对系统需求变更、了解和控制的过程。需求管理过程与需求开发过程相互关联，当初始需求导出的同时就启动了需求管理计划，一旦形成了需求文档的初稿，需求管理活动就开始了。关于需求管理过程域内的原则和策略，可以参考：①需求管理的关键过程领域不涉及收集和分析项目需求，而是假定已收集了软件需求，或者已由更高一级的系统给定了需求。②开发人员在向客户以及有关部门承诺某些需求之前，应该确认需求和约束条件、风险、偶然因素、假定条件等。③关键处理领域同样建议通过版本控制和变更控制来管理需求文档。

[单选题]系统输入设计中应尽可能考虑人的因素，以下关于输入设计的一般原理中，错误的是（）

使用创新的模式吸引用户的眼球

解析：本题考查软件界面设计中的系统输入设计。人的因素在系统输入设计中扮演了很重要的角色。输入应该尽可能地简单，以降低错误发生的可能性，如对于范围可控的数据，使用选择的方式替代用户输入；只输入变化的数据等。输入应该尽可能使用已有含义明确的设计，需要采用模仿的方式而非创新。为了避免用户理解的二义性，应该对表格中输入的数据给出提示信息。

[单选题]在实际的项目开发中，人们总是希望使用自动工具来执行需求变更控制过程。下列描述中，（）不是这类工具所具有的功能。

定义变更控制计划，并指导设计人员按照所制定的计划实施变更

解析：对许多项目来说，系统软件总需要不断完善，一些需求的改进是合理的而且不可避免，要使得软件需求完全不变更，也许是不可能的，但毫无控制的变更是项目陷入混乱、不能按进度完成或者软件质量无法保证的主要原因之一。一个好的变更控制过程，给项目风险承担者提供了正式的建议需求变更机制。可以通过需求变更控制过程来跟踪已建议变更的状态，使已建议的变更确保不会丢失或疏忽。在实际中，人们总是希望使用自动工具来执行变更控制过程。有许多人使用商业问题跟踪工具来收集、存储、管理需求变更；可以使用工具对一系列最近提交的变更建议产生一个列表给变更控制委员会开会时做议程用。问题跟踪工具也可以随时按变更状态分类包裹变更请求的数目。挑选工具时可以考虑以下几个方面：①可以定义变更请求的数据项。②可以定义变更请求生存期的状态转换图。③可以加强状态转换图使经授权的用户仅能做出所允许的状态变更。④记录每一种状态变更的数据，确认做出变更的人员。⑤可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员。⑥可以根据需要生成标准的或定制的报告和图表。

[单选题]需求管理是CMM可重复级中的6个关键过程域之一，其主要目标是（）

对于软件需求，必须建立基线以进行控制，软件计划、产品和活动必须与软件需求保持一致

解析：过程能力成熟度模型(Capability Maturity Model，CMM)在软件开发机构中被广泛用来指导软件过程改进。该模型描述了软件成立能力的5个成熟级别，每一级都包含若干关键过程域(Key Process Areas，KPA)。 CMM的第二级为可重复级，它包括6个关键过程域，分别是：需求管理、软件项目计划、软件项目跟踪和监督、软件分包合同管理、软件质量保证和软件配置管理。需求管理的目标是为软件需求建立一个基线，提供给软件工程和管理使用；软件计划、产品和活动与软件需求保持一致。

[单选题]在RUP中采用"4+1"视图模型来描述软件系统的体系结构。在该模型中，最终用户侧重于（1），系统工程师侧重于（2）。

[单选题]在基于构件的软件开发中，（1）描述系统设计蓝图以保证系统提供适当的功能；（2）用来了解系统的性能、吞吐率等非功能性属性。

解析：在基于构件的软件开发中，逻辑构件模型用功能包描述系统的抽象设计，用接口描述每个服务集合，以及功能之间如何交互以满足用户需求，它作为系统的设计蓝图以保证系统提供适当的功能。物理构件模型用技术设施产品、硬件分布和拓扑结构，以及用于绑定的网络和通信协议描述系统的物理设计，这种架构用于了解系统的性能、吞吐率等许多非功能性属性。

[单选题]系统测试由若干个不同的测试类型组成，其中（1）检查系统能力的最高实际限度，即软件在一些超负荷情况下的运行情况；（2）主要是检查系统的容错能力。

解析：本题考查测试的相关概念，我们只要了解每一种测试的主要工作，就能解答此题。恢复测试：恢复测试监测系统的容错能力。检测方法是采用各种方法让系统出现故障，检验系统是否按照要求能从故障中恢复过来，并在约定的时间内开始事务处理，而且不对系统造成任何伤害。如果系统的恢复是自动的（由系统自动完成），需要验证重新初始化、检查点、数据恢复等是否正确。如果恢复需要人工干预，就要对恢复的平均时间进行评估并判断它是否在允许的范围内。强度测试：是对系统在异常情况下的承受能力的测试，是检查系统在极限状态下运行时，性能下降的幅度是否在允许的范围内。因此，强度测试要求系统在非正常数量、频率或容量的情况下运行。强度测试主要是为了发现在有效的输入数据中可能引起不稳定或不正确的数据组合。例如，运行使系统处理超过设计能力的最大允许值的测试例子；使系统传输超过设计最大能力的数据，包括内存的写入和读出等。性能测试：检查系统是否满足系统设计方案说明书对性能的要求。性能测试覆盖了软件测试的各阶段，而不是等到系统的各部分所有都组装之后，才确定系统的真正性能。通常与强度测试结合起来进行，并同时对软件、硬件进行测试。软件方面主要从响应时间、处理速度、吞吐量、处理精度等方面来检测。可靠性测试：通常使用以下两个指标来衡量系统的可靠性：平均失效间隔时间（MeanTimeBetweenFailures，MTBF）是否超过了规定的时限，因故障而停机时间（MeanTimeToRepairs，MTTR）在一年中不应超过多少时间。

[单选题]UML采用4+1视图来描述软件和软件开发过程，其中（1）描绘了所设计的并发与同步结构；（2）表示软件到硬件的映射及分布结构；UML中的类图可以用来表示4+1视图中的（3）。

解析：UML采用4+1视图来描述软件和软件开发过程。①逻辑视图：以问题域的语汇组成的类和对象集合。②进程视图：可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描绘了所设计的并发与同步结构。③实现视图：对组成基于系统的物理代码的文件和组件进行建模。④部署视图：把构件部署到一个组物理的、可计算的节点上，表示软件到硬件的映射及分布结构。⑤用例视图：最基本的需求分析模型。