系统架构设计师分类模拟2

《系统架构设计师分类模拟2》由会员分享，可在线阅读，更多相关《系统架构设计师分类模拟2（32页珍藏版）》请在金锄头文库上搜索。

1、 模拟 系统架构设计师分类模拟 2单项选择题第 1 题：用户文档主要描述所交付系统的功能和使用方法。下列文档中， 属于用户文档。A. 需求说明书B. 系统设计文档C. 安装文档D. 系统测试计划 参考答案： C用户文档主要描述所交付系统的功能和使用方法， 并不关心这些功能是怎样实现 的。用户文档是了解系统的第一步，它可以让用户获得对系统准确的初步印象。 用户文档一般包括以下内容。 功能描述： 说明系统能做什么。 安 装文档：说明怎样安装这个系统， 以及怎样使系统适应特定的硬件配置。使用手册：简要说明如何着手使用这个系统 （ 通过丰富的例子说明怎样使用常用 的系统功能，并说明用户操作错误是怎样恢

2、复和重新启动的 ） 。 参考手 册：详尽描述用户可以使用的所有系统设施以及它们的使用方法， 并解释系统可 能产生的各种出错信息的含义 （ 对参考手册最主要的要求是完整，因此通常使用 形式化的描述技术 ）。操作员指南 （如果需要有系统操作员的话 ） ：说明操作员应如何处理使用中出现的各种情况。试题中只有安装文档属于用户文档，其他的需求说明书、系统设计文档、系统测试计划均属于开发文档。不属于配置项第 2 题： 配置项是构成产品配置的主要元素，其中A. 设备清单B .项目质量报告C. 源代码D. 测试用例 参考答案： A信息系统在其开发、 运行、维护的过程中会得到许多阶段性的成果， 在开发和运 行过

3、程中还需要用到多种工具软件， 所有这些信息项需要得到妥善的管理， 决不 能出现混乱， 以便在提出某些特定的要求时， 将它们进行约定的组合来满足使用 的目的。这些信息项是配置管理的对象，称为配置项。IEEE对配置项的定义为： 硬件、软件或两者兼有的集合， 为配置管理指定的， 在配置管理过程中作为一个 单独的实体对待。配置项的类型以下内容可以作为配置项进行管理：外部交付的软件产品和数据、 指定的内部软件工作产品和数据、 指定的用于 创建或支持软件产品的支持工具、 供方/ 供应商提供的软件和客户提供的设备 /软件。配置项通常可以分成下列 6种类型。环境类。软件开发、运行和维护的环境，例如，编译器、操

4、作系统、编辑软件、管理系统、开发工具、测试工 具、项目管理工具和文档编制工具等。定义类。需求分析与系统定义阶段结束后得到的成果，例如，需求规格说明书、项目管理计划、设计标准和验收 测试计划等。设计类。设计阶段得到的成果，例如，系统设计说明书、程序规格说明、数据库设计、编码标准、用户界面设计、测试标准、系统测试计 划和用户手册等。编码类。编码及单元测试结束后得到的成果，例如，源代码、目标码、单元测试用例、数据和测试结果等。测试类。系统测试完成后的成果，例如，系统测试用例、测试结果、操作手册和安装手册。维护类。维护阶段产品的成果，以上任何需要变更的配置项。配置项的描述 确定了配置项后，还需要对配置

5、项进行合理、科学的命名。配置项的命 名绝不能随意为之， 必须满足唯一性和可追溯性。 一个典型的实例是采用层次式 的命名规则来反映树状结构，树状结构上节点之间存在着层次的继承关系。 由于配置项除了名称外还有一些其他属性和与其他配置项的关系， 因此，它可以 采用描述对象的方式来进行描述。每个配置项用一组特征信息 （ 名字、描述、一 组资源、实现 ）唯一地标识。配置项之间的关系有整体和部分的关系及层次关系， 也有关联关系。 配置项间的关系可以用 MIL（Module Interconnection Language， 模块连接语言 ） 表示， MIL 描述的是配置项间的相互依赖关系，可自动构造系统

6、的任何版本。识别配置项的步骤识别配置项的主要步骤如下。识别配置项。为每个配置项指定唯一性的标识代号。确定每个配置项的重要特征。 配置项的特征主要包括作者、 日期、类型等。确定配置项进入配置管理的时间。确定每个配置项的拥有者及责任。填写配置管理表。审批配置管理表。CCB审查配置管理表是否符合配置管理计划的规定，审批配置管理表。第 3 题： 一个大型软件系统的需求通常是会发生变化的。以下关于需求变更策略的叙述 中，错误的是 。A. 所有需求变更必须遵循变更控制过程B. 对于未获得核准的变更，不应该做变更实现工作C. 完成对某个需求的变更之后，可以删除或者修改变更请求的原始文档D. 每一个集成的需求

7、变更必须能追溯到一个经核准的变更请求参考答案： C第 4 题：以下关于需求管理的叙述中，正确的是 。A. 需求管理是一个对系统需求及其变更进行了解和控制的过程B. 为了获得项目，开发人员可以先向客户做出某些承诺C. 需求管理的重点在于收集和分析项目需求D. 软件开发过程是独立于需求管理的活动参考答案： A软件需求开发的最终文档经过评审批准后， 则定义了开发工作的需求基线。 这个 基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定 (Agreement) 。需求约定是需求开发和需求管理之间的桥梁。 需求管理是一 个对系统需求变更、了解和控制的过程。 需求管理过程与需求开发过程相互

8、关联， 当初始需求导出的同时就启动了需求管理规划， 一旦形成了需求文档的初稿， 需 求管理活动就开始了。 需求管理强调： 控制对需求基线的变动； 保持项目计划与需求一致； 控制单个需求和需求文档的版本情况； 管理需求和联系链， 或者管理单个需求和其他项目可交付产品之间的依赖关系； 跟踪基线中的需求状态。CMMI描述了软件处理能力的5个成熟级别。为了达到过程能力成熟度模型的第二级，组织机构必须具有6 个关键过程域KPA(Key Process Areas) 。需求管理是其中之一，它的目标是：为软件需求建立一个基线，提供给软件工程和管理使用；软件计划、产品和活动与软件需求保持一致。关于需求管理过程

9、域内的原则和策略，可以参考如下。需求管理的关键过程领域不涉及收集和分析项目需求，而是假定已收集了软件需求， 或者已由更高一级的系统给定了需求。 一旦需求获得并且文 档化了，软件开发组和有关的团队 (例如质量保证和测试组 ) 需要评审文档。 发现 问题应与客户或者其他需求源协商解决。软件开发计划是基于已确认的需求。 开发人员在向客户以及有关部门承诺(Commitment)某些需求之前，应该确认需 求和约束条件、风险、偶然因素、假定条件等。也许不得不面对由于技术因素或 者进度等原因承诺一些不现实的需求，但是决不要承诺任何无法实现的需求。 关键处理领域同样建议通过版本控制和变更控制来管理需求文档。版

10、本控制确保随时能知道在项目开发和计划中正在使用的需求的版本情况。 变更控制提供了 支配下的规范的方式来统一需求变更， 并且基于业务和技术的因素来同意或者反 对建议的变更。当在开发中修改、增加、减少需求时，软件开发计划应该随时更 新，确保与新的需求保持一致。第5题：方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化， 比较适合需求变化较大或者开发前期对需求不是很清晰的项目。A. 信息工程B. 结构化C. 面向对象D. 敏捷 参考答案： D敏捷方法是从 20世纪 90 年代开始逐渐引起广泛关注的一些新型软件开发方法， 以应对快速变化的需求。虽然它们的具体名称、理念、过程、术语都不尽相同，

11、 但相对于“非敏捷”而言，它们更强调开发团队与用户之间的紧密协作、面对面 的沟通、频繁交付新的软件版本、 紧凑而自我组织型的团队等， 也更注重人的作 用。 敏捷宣言 2001 年， Kent Beck 等人组织了敏捷联盟，阐述了敏 捷开发的原则， 试图强调灵活性在快速且有效地开发软件中所发挥的作用。 他们共同签署了敏捷软件开发宣言， 该宣言认为， 个体和交互胜过过程和工具； 可工 作的软件胜过大量的文档；客户合作胜过合同谈判；响应变化胜过遵循计划。 敏捷方法强调： 让客户满意和软件尽早增量发布、 小而高度自主的项目团队、 非 正式的方法、 最小化软件工程工作产品以及整体精简开发。 产生这种情况

12、的原因 是，在绝大多数软件开发过程中， 提前预测哪些需求是稳定的和哪些需求会变化 非常困难； 对于软件项目构建来说， 设计和实现是交错的； 从指定计划的角度来 看，分析、设计、实现和测试并不容易预测；可执行原型和部分实现的可运行系 统是了解用户需求和反馈的有效媒介。 目前，主要的敏捷方法有极限编程 (extreme Program min g, XP)、自适应软件开发(Adaptive Software Developme nt, ASD)水晶方法(Crystal)、特性驱动开发(Feature Driven Development, FDD) 动态系统开发方法(Dynamic Systems

13、Development Method , DSDM测试驱动开发 (Test-Driven Development , TDD)、 敏 捷 数 据 库 技 术 (Agile Database Techniques，ADT)和精益软件开发(Lean SoftwareDevelopment)等。虽然这些过 程模型在实践上有差异， 但都是遵循了敏捷宣言或者是敏捷联盟所定义的基本原 则。这些原则包括客户参与、增量式移交、简单性、接受变更、强调开发人员的 作用和及时反馈等。敏捷方法的特点 敏捷方法是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷方法中, 软件项目的构建被切分成多个子项 目,各个子项目成

14、果都经过测试,具备集成和可运行的特征。在敏捷方法中,从 开发者的角度来看,主要的关注点有短平快的会议、小版本发布、较少的文档、 合作为重、 客户直接参与、自动化测试、适应性计划调整和结对编程；从管 理者的角度来看,主要的关注点有测试驱动开发、持续集成和重构。近年来,虽然敏捷方法发展得较快,但在实施的过程中,也暴露出来很多问题,一些 敏捷方法的基本原则很难实施，主要体现在以下四个方面。客户参与往往依赖于客户参与的意愿和客户自身的代表性。团队成员的性格可能不适合激烈的投入，可能无法做到与其他成员之间的良好沟通。对系统的变更做出优先级排序可能是极端困难的。维护系统的简洁性往往需要额外的工作， 但迫于

15、时间表的压力， 可能没有时间执行系统简化过程。与 RUP相比，敏捷方法的周期可能更短。 敏捷方法在几周或几个月的时间内完成相对较 小的功能， 强调的是能尽早将尽量小的可用的功能交付使用， 并在整个项目周期 中持续改善和增强， 并且更加强调刚队中的高度协作。 相对而言， 敏捷方法主要 适用于以下场合：项目团队的人数不能太多，适合于规模较小的项目。项目经常发生变更。 敏捷方法适用于需求萌动并且快速改变的情况，如果系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适 合。高风险项目的实施。从组织结构的角度看， 组织结构的文化、人员、沟通性决定了敏捷方法是否适用。 与这些相关联的关键成功因素有组织文 化必须支持谈判、人员彼此信任、人少但是精干、开发人员所做的决定得到认可、 环境设施满足团队成员之间快速沟通的需要。项目管理工具用来辅助项目经理实施软件开发过程中的项目管理活动， 它不 能。 就是一种典型的项目管理工具。第 6 题：A. 覆盖整个软件生存周期B. 确定关键路径、松弛时间、超前时间和滞后时间C. 生成固定格式的报表和裁剪项目报告D. 指导软件设计人员按软件生存周期各个阶段的适用技术进行设计工作参考答案： D第 7 题：A. 需求分析工具B. 成