全部科目 > 信息系统项目管理师 >
2011年上半年 上午试卷 综合知识
第 12 题
知识点 产品基线   功能基线   基线   配置管理   软件工程   软件工程术语   审核  
关键词 产品基线   开发   配置管理   软件工程术语   基线   软件工程  
章/节 标准  
 
 
根据《软件工程术语GB/T11457-2006》,基线是业已经过正式审核与同意,可用作下一步开发的基础,并且只有通过正式的修改管理步骤方能加以修改的规格说明或产品。对于配置管理,有以下三种基线功能基线、(12)和产品基线
 
  A.  编码基线
 
  B.  测试基准
 
  C.  里程碑
 
  D.  分配基线
 
 




 
 
相关试题     信息技术 软件工程术语GB/T 11457-2006 

  第9题    2012年下半年  
根据GB/T11457-2006的规定,使客户能确认是否接受系统的正式测试为(9)。

  第12题    2017年下半年  
依据标准GB/T 11457-2006《信息技术软件工程术语》,( )是忽略系统或部件的内部机制只集中于响应所选择的输入和执行条件产生的输出的一种测试,是有助于评价系统或部分与规定的功能需求遵循性..

  第12题    2018年下半年  
《信息技术软件工程术语》(GB/T 11457-2006)规定了软件工程领域的术语。其中()指的是为评估是否符合需求、规格说明、基线、标准、过程、指令、代码以及合同和特殊要求而进行的一种独立的检查..

 
知识点讲解
· 产品基线
· 功能基线
· 基线
· 配置管理
· 软件工程
· 软件工程术语
· 审核
 
        产品基线
        产品基线是指在软件组装与系统测试阶段结束时,经过正式评审和批准的有关开发软件产品全部配置项的规格说明。产品基线是最初批准的产品配置标识。
 
        功能基线
        功能基线是指在系统分析与软件定义阶段结束时,经过正式评审和批准的系统设计规格说明书中对待开发软件系统的规格说明;或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明;或是指由下级申请上级同意,或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。
 
        基线
        基线(baseline)是项目生存期各开发阶段末尾的特定点,也称为里程碑(milestone),在这些特定点上,阶段工作已结束,并且已经形成了正式的阶段性产品。
        建立基线的概念是为了把各开发阶段的工作划分得更加明确,使得本来连续开展的开发工作在这些点上被分割开,从而更加有利于检验和肯定阶段工作的成果,同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果,并且认为建立了里程碑,有些完成的阶段成果已被冻结。
        作为阶段工作的正式产品,基线应该是稳定的,如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿,就不能作为基线,不能被冻结。
        如果把软件看作是系统的一个组成部分,以下3种基线最受人们关注的:功能基线、分配基线、产品基线。
        (1)功能基线:指在系统分析与软件定义阶段结束时,经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明;或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明;或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。
        (2)分配基线(指派基线):指在软件需求分析阶段结束时,经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。
        (3)产品基线:指在软件组装与系统测试阶段结束时,经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。
        另外,交付给外部顾客的基线一般称为发行基线,内部使用的基线称为构造基线。释放是指在软件生存周期的各个阶段结束时,由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付。
        :提出基线的概念本来是为了更好地实现变更控制,但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及基线的很小部分。例如,假定某个大型软件中的一个模块修改了,如果将这一变更当做整个软件产品基线的变更,就很不方便。
 
        配置管理
        随着信息系统软件版本不断变化,开发时间的紧迫以及多平台开发环境的采用,使得软件开发、维护面临越来越多的问题,其中包括对当前多种软件的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等。
        信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。界定软件的组成项目,对每个项目的变更进行管控(版本控制),并维护不同项目之间的版本关联,以使软件在开发过程中任一时间的内容都可以被追溯。其关键活动包括:配置管理计划、配置项管理、版本控制、变更控制、配置审计、状态报告等。
               配置管理计划
               根据信息系统软件运维制度和规范、标准,制定配置管理计划,主要包括以下内容。
               (1)该项目对配置管理的要求。
               (2)实施配置管理的责任人、组织及其职责。
               (3)需要开展的配置管理活动及其进度安排。
               (4)采用的方法和工具等。
               配置与配置项
               “配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性,及其内容及相关文档,软件版本,变更文档,软件运行的支持数据,以及其他一切保证软件一致性的组成要素。
               为了方便对“配置”进行管理,“配置”经常被划分为各类配置项,这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合,在配置管理过程中,配置项被作为一个单一的实体对待。配置项包括各种管理文档和技术文档,源程序与目标代码,以及运行所需的各种数据等。同时,应该建立配置库来管理所有的配置项。
               版本控制
               版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加,修改或删除,配置项的版本随之演变。应当记录每个软件配置项的所有历史记录,并记录该软件配置项由何人创建,何人在何时因何原因进行了修改等信息,以及对这些软件配置项版本的进行检索和信息查询等活动。
               变更控制
               变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部分,包含评估、协调、批准/拒绝、实施对配置项的变更。
               配置审计
               配置审计是对配置管理的独立的查检过程,确认受控软件配置项满足需求并就绪。其内容如下。
               (1)功能审计:配置项的变更控制是否和配置管理计划中的描述相一致。
               (2)物理审计:配置项的完整性、正确性、一致性和可跟踪性。
               状态报告
               状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单,变更请求当前的处理状态,以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程,它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。
 
        软件工程
        1)软件工程的概念
        为了消除软件危机,通过认真研究解决软件危机的方法,人们认识到软件工程是使计算机软件走向科学的途径,逐渐形成了软件工程的概念,并开辟工程学的新兴领域,即软件工程学。
        2)软件工程的要素
        软件工程具有以下3个要素。
        (1)方法。完成软件工程项目的技术手段。
        (2)工具。支持软件的开发、管理、文档生成。
        (3)过程。将方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。
        3)软件生命周期
        软件生命周期是指软件产品从考虑其概念开始到该软件产品交付使用,直至最终退役为止的整个过程,包括计划阶段、分析阶段、设计阶段、实现阶段、测试阶段和运行维护阶段。
        4)软件开发模型
        比较经典的软件开发模型有瀑布模型、快速原型模型、演化模型、增量模型、螺旋模型、喷泉模型等。
        5)软件开发方法
        软件开发方法有以下几种。
        (1)结构化软件开发(SASD)方法:采用结构化技术来完成软件开发的各项任务。它把软件生命周期划分成若干个阶段,依次完成每个阶段的任务。它与瀑布模型有很好的结合度,是与其最相适应的软件开发方法。
        (2)面向数据结构的软件开发方法:从目标系统的输入、输出数据结构入手,导出程序框架结构,再补充其他细节,从而可得到完整的程序结构图。有Jackson方法和Warnier方法。
        (3)面向对象的软件开发方法:随着OOP(面向对象编程)向OOD(面向对象设计)和OOA(面向对象分析)的发展,最终形成面向对象的软件开发方法OMT(Object Modelling Technique)。这是一种自底向上和自顶向下相结合的方法,而且它以对象建模为基础,从而不仅考虑了输入、输出数据结构,实际上也包含了所有对象的数据结构。
        (4)基于构件化的开发方法:用预先建立的构件和模板,像"搭积木"一样进行建造。
 
        软件工程术语
        《GB/T 11457—2006信息技术软件工程术语》定义了软件工程领域中通用的术语,适用于软件开发、软件维护、科研、教学和出版等方面。
        .抽象:对某一问题的概括,它抽取于某一特定目标相关的本质内容而忽略其非本质内容。
        .验收准则:系统或部件必须满足的准则,其目的是用户、客户或其他授权实体能够予以接受。
        .验收测试:确定一系统是否符合其验收准则,使客户能确定是否接收此系统的正式测试。
        .活动:一个过程的组成元素。对基线的变更要经有关机构的正式批准。
        .活动图:用于对涉及一个或多个类目的进程建模的状态机的一种特例。
        .适应性:使不同的系统约束条件和用户需求得到满足的容易程度。
        .关联:规定其实例件连接的多个类目之间的语义联系。
        .审计:为评估工作产品或工作产品集是否符合软件需求、规格说明、基线、标准、过程、指令、代码以及合同和特殊要求而进行的一种独立检查。
        .可用性:软件(系统或部件)在投入使用时可操作和可访问的程度或能实现其指定的系统功能的概率。
        .基线:业已经过正式审核与同意,可以作下一步开发的基础,并且只能通过正式的修改管理工程方能加以修改的规格说明或产品。在配置项目生存周期的某一特定时间内,正式指定或固定下来的配置标识文件。基线加上根据这些基线批准同意的改动构成了当前配置标识。对于配置管理,有三种基线:功能基线(最初通过的功能配置)、分配基线(最初通过的分配的配置)、产品基线(最初通过的或有条件地通过的产品配置)。
        .边界值:相应于为系统或部件规定的最小或最大的输入、内部、输出的数据值。
        .代码审计:由某人、某小组或借助某种工具对源代码进行的审查,目的是验证其是否符合软件设计文件和程序设计标准,还可能对正确性和有效性进行估计。
        .代码评审:把软件代码呈现给项目人员、管理人员、用户、客户或其他感兴趣的人员用于评论或批准的会议。
        .数据字典:软件系统中使用的所有数据项的名字及与这些数据项有关的特性(例如数据项长度、表示等)的集合。
        .依赖:两个建模元素之间的一种关系,对其中一个建模元素(独立元素)的更改,将影响另一建模元素(依赖元素)。
        .验证:确定软件开发周期中的一个给定阶段的产品是否达到在上一阶段确立的需求的过程。
        .确认:在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程。
        .测试:通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一。
        .软件开发方法:是指软件开发过程中所遵循的办法和步骤。软件开发活动的目的是有效地得到一些工作产物,也就是一个运行的系统及其支持文档,并且满足有关的质量要求。
        .鉴定:是一个正式的过程,通过这个过程决定产品是否符合它的规格说明,是否可在目标环境中使用。
 
        审核
        依据知识库内容加入的审核标准,由资深技术人员审核内容的正确性和完整性,避免与原有的知识库内容重复或冲突,给出审核意见后提交批准加入知识库中。



更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5
京公网安备 11010502032051号 | 营业执照
 Copyright ©2000-2023 All Rights Reserved
软考在线版权所有