A系统架构设计师系统开发基础软件架构设计知识产权与标准化一Word文档格式.docx
- 文档编号:15786564
- 上传时间:2022-11-16
- 格式:DOCX
- 页数:44
- 大小:60.43KB
A系统架构设计师系统开发基础软件架构设计知识产权与标准化一Word文档格式.docx
《A系统架构设计师系统开发基础软件架构设计知识产权与标准化一Word文档格式.docx》由会员分享,可在线阅读,更多相关《A系统架构设计师系统开发基础软件架构设计知识产权与标准化一Word文档格式.docx(44页珍藏版)》请在冰豆网上搜索。
B.
C.
√
D.
解析:
[解析]用户文档主要描述所交付系统的功能和使用方法,并不关心这些功能是怎样实现的。
用户文档是了解系统的第一步,它可以让用户获得对系统准确的初步印象。
用户文档一般包括以下内容。
①功能描述:
说明系统能做什么。
②安装文档:
说明怎样安装这个系统,以及怎样使系统适应特定的硬件配置。
③使用手册:
简要说明如何着手使用这个系统(通过丰富的例子说明怎样使用常用的系统功能,并说明用户操作错误是怎样恢复和重新启动的)。
④参考手册:
详尽描述用户可以使用的所有系统设施以及它们的使用方法,并解释系统可能产生的各种出错信息的含义(对参考手册最主要的要求是完整,因此通常使用形式化的描述技术)。
⑤操作员指南(如果需要有系统操作员的话):
说明操作员应如何处理使用中出现的各种情况。
试题中只有安装文档属于用户文档,其他的需求说明书、系统设计文档、系统测试计划均属于开发文档。
2.配置项是构成产品配置的主要元素,其中______不属于配置项。
A.设备清单B.项目质量报告
C.源代码D.测试用例
A.
C.
[解析]信息系统在其开发、运行、维护的过程中会得到许多阶段性的成果,在开发和运行过程中还需要用到多种工具软件,所有这些信息项需要得到妥善的管理,决不能出现混乱,以便在提出某些特定的要求时,将它们进行约定的组合来满足使用的目的。
这些信息项是配置管理的对象,称为配置项。
IEEE对配置项的定义为:
硬件、软件或两者兼有的集合,为配置管理指定的,在配置管理过程中作为一个单独的实体对待。
①配置项的类型
以下内容可以作为配置项进行管理:
外部交付的软件产品和数据、指定的内部软件工作产品和数据、指定的用于创建或支持软件产品的支持工具、供方/供应商提供的软件和客户提供的设备/软件。
配置项通常可以分成下列6种类型。
·
环境类。
软件开发、运行和维护的环境,例如,编译器、操作系统、编辑软件、管理系统、开发工具、测试工具、项目管理工具和文档编制工具等。
定义类。
需求分析与系统定义阶段结束后得到的成果,例如,需求规格说明书、项目管理计划、设计标准和验收测试计划等。
设计类。
设计阶段得到的成果,例如,系统设计说明书、程序规格说明、数据库设计、编码标准、用户界面设计、测试标准、系统测试计划和用户手册等。
编码类。
编码及单元测试结束后得到的成果,例如,源代码、目标码、单元测试用例、数据和测试结果等。
测试类。
系统测试完成后的成果,例如,系统测试用例、测试结果、操作手册和安装手册。
维护类。
维护阶段产品的成果,以上任何需要变更的配置项。
②配置项的描述
确定了配置项后,还需要对配置项进行合理、科学的命名。
配置项的命名绝不能随意为之,必须满足唯一性和可追溯性。
一个典型的实例是采用层次式的命名规则来反映树状结构,树状结构上节点之间存在着层次的继承关系。
由于配置项除了名称外还有一些其他属性和与其他配置项的关系,因此,它可以采用描述对象的方式来进行描述。
每个配置项用一组特征信息(名字、描述、一组资源、实现)唯一地标识。
配置项之间的关系有整体和部分的关系及层次关系,也有关联关系。
配置项间的关系可以用MIL(ModuleInterconnectionLanguage,模块连接语言)表示,MIL描述的是配置项间的相互依赖关系,可自动构造系统的任何版本。
③识别配置项的步骤
识别配置项的主要步骤如下。
识别配置项。
为每个配置项指定唯一性的标识代号。
确定每个配置项的重要特征。
配置项的特征主要包括作者、日期、类型等。
确定配置项进入配置管理的时间。
确定每个配置项的拥有者及责任。
填写配置管理表。
审批配置管理表。
CCB审查配置管理表是否符合配置管理计划的规定,审批配置管理表。
3.一个大型软件系统的需求通常是会发生变化的。
以下关于需求变更策略的叙述中,错误的是______。
A.所有需求变更必须遵循变更控制过程
B.对于未获得核准的变更,不应该做变更实现工作
C.完成对某个需求的变更之后,可以删除或者修改变更请求的原始文档
D.每一个集成的需求变更必须能追溯到一个经核准的变更请求
[解析]在软件项目中,需求的变化是不可避免的。
需求变更可能来自解决方案提供商、用户或产品供应商等外部因素,也可能来源于项目团队内部。
对于项目团队而言,无法阻止需求发生变更,他们只能正确地对待变更,按照既定流程管理变更,尽量降低变更对项目成本、进度和质量的负面影响。
①需求基线
需求开发的结果应该有项目视图和范围文档、用例文档和SRS,以及相关的分析模型。
经评审批准,这些文档就定义了开发工作的需求基线。
这个基线在用户和开发人员之间构成了软件需求的一个约定,它是需求开发和需求管理之间的桥梁。
基线是一个软件配置管理的概念,它帮助开发人员在不严重阻碍合理变化的情况下来控制变化。
根据IEEE的定义,基线是指已经通过正式评审和批准的规约或产品,它可以作为进一步开发的基础,并且只能通过正式的变更控制系统进行变化。
在软件工程范围内,基线是软件开发中的里程碑,其标志是有一个或多个软件配置项的交付,且已经经过正式技术评审而获得认可。
例如,SRS文档通过评审,其中的错误已经被发现并纠正,则变成一个基线。
根据国家标准《计算机软件配置管理计划规范》(GB/T12505-1990)的规定,基线可以分为功能基线、指派基线和产品基线三种,通过评审后的SRS属于指派基线。
开发团队可以根据已知的需求基线来区分“旧需求”和“新需求”。
一旦建立了需求基线,很容易对新需求进行识别和管理,可以把新需求和已有的基线加以比较,确定适合它的位置以及它是否会与其他需求产生冲突。
如果接受新需求,就可以管理它的变更过程。
②需求的状态
从需求的整个生命周期来看,其状态的变化如图所示。
在需求状态的变化中,项目管理人员首先需要关注的是那些被拒绝和被丢弃的需求。
因为这些需求有可能是应该被接受和并被实现的需求,如果不是通过有管理的处理过程,就有可能因为疏忽而被遗漏。
同时,也应关注被交付的需求,因为可交付物是项目的成果体现,而可交付物的主要内容是对需求的实现。
③需求变更
在各种有关理论书籍中,都会介绍一些如何减少需求变更的方法和技术。
在项目实践中,项目管理人员也会花大量的精力去实践这些方法和技术,以避免需求变更。
遗憾的是,“是祸躲不过”,需求变更因各种因素而依然发生,不可避免。
当然,这并不是说不应该做避免变更的工作,恰恰相反,在需求变更之前尽量减少变更,以将需求变更带来的风险降到最低,这是对项目进展十分有利的。
需求变更通常意味着新需求的增加和对已有需求的修改,一般不会减少需求,而且减少需求的问题也比较容易处理。
需求变更是需要代价的,包括时间、人力、资源等方面。
既然需求变更是不可避免的,那么,项目管理人员应该采取规范的流程去管理变更,而不是一味地避免变更和拒绝变更。
在进行需求变更时,可以参考以下的需求变更策略:
所有需求变更必须遵循变更控制过程;
对于未获得批准的变更,不应该做设计和实现工作;
变更应该由项目变更控制委员会决定实现哪些变更;
项目风险承担者应该能够了解变更数据库的内容;
决不能从数据库中删除或者修改变更请求的原始文档;
每一个集成的需求变更必须能跟踪到一个经核准的变更请求。
4.以下关于需求管理的叙述中,正确的是______。
A.需求管理是一个对系统需求及其变更进行了解和控制的过程
B.为了获得项目,开发人员可以先向客户做出某些承诺
C.需求管理的重点在于收集和分析项目需求
D.软件开发过程是独立于需求管理的活动
[解析]软件需求开发的最终文档经过评审批准后,则定义了开发工作的需求基线。
这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定(Agreement)。
需求约定是需求开发和需求管理之间的桥梁。
需求管理是一个对系统需求变更、了解和控制的过程。
需求管理过程与需求开发过程相互关联,当初始需求导出的同时就启动了需求管理规划,一旦形成了需求文档的初稿,需求管理活动就开始了。
需求管理强调:
①控制对需求基线的变动;
②保持项目计划与需求一致;
③控制单个需求和需求文档的版本情况;
④管理需求和联系链,或者管理单个需求和其他项目可交付产品之间的依赖关系;
⑤跟踪基线中的需求状态。
CMMI描述了软件处理能力的5个成熟级别。
为了达到过程能力成熟度模型的第二级,组织机构必须具有6个关键过程域KPA(KeyProcessAreas)。
需求管理是其中之一,它的目标是:
①为软件需求建立一个基线,提供给软件工程和管理使用;
②软件计划、产品和活动与软件需求保持一致。
关于需求管理过程域内的原则和策略,可以参考如下。
①需求管理的关键过程领域不涉及收集和分析项目需求,而是假定已收集了软件需求,或者已由更高一级的系统给定了需求。
一旦需求获得并且文档化了,软件开发组和有关的团队(例如质量保证和测试组)需要评审文档。
发现问题应与客户或者其他需求源协商解决。
软件开发计划是基于已确认的需求。
②开发人员在向客户以及有关部门承诺(Commitment)某些需求之前,应该确认需求和约束条件、风险、偶然因素、假定条件等。
也许不得不面对由于技术因素或者进度等原因承诺一些不现实的需求,但是决不要承诺任何无法实现的需求。
③关键处理领域同样建议通过版本控制和变更控制来管理需求文档。
版本控制确保随时能知道在项目开发和计划中正在使用的需求的版本情况。
变更控制提供了支配下的规范的方式来统一需求变更,并且基于业务和技术的因素来同意或者反对建议的变更。
当在开发中修改、增加、减少需求时,软件开发计划应该随时更新,确保与新的需求保持一致。
5.______方法以原型开发思想为基础,采用迭代增量式开发,发行版本小型化,比较适合需求变化较大或者开发前期对需求不是很清晰的项目。
A.信息工程B.结构化
C.面向对象D.敏捷
D.
[解析]敏捷方法是从20世纪90年代开始逐渐引起广泛关注的一些新型软件开发方法,以应对快速变化的需求。
虽然它们的具体名称、理念、过程、术语都不尽相同,但相对于“非敏捷”而言,它们更强调开发团队与用户之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队等,也更注重人的作用。
①敏捷宣言
2001年,KentBeck等人组织了敏捷联盟,阐述了敏捷开发的原则,试图强调灵活性在快速且有效地开发软件中所发挥的作用。
他们共同签署了敏捷软件开发宣言,该宣言认为,个体和交互胜过过程和工具;
可工作的软件胜过大量的文档;
客户合作胜过合同谈判;
响应变化胜过遵循计划。
敏捷方法强调:
让客户满意和软件尽早增量发布、小而高度自主的项目团队、非正式的方法、最小化软件工程工作产品以及整体精简开发。
产生这种情况的原因是,在绝大多数软件开发过程中,提前预测哪些需求是稳定的和哪些需求会变化非常困难;
对于软件项目构建来说,设计和实现是交错的;
从指定计划的角度来看,分析、设计、实现和
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统 架构 设计师 开发 基础 软件 设计 知识产权 标准化