软考在线  |  计算机技术与软件专业技术资格(水平)考试   |   [请选择科目]
[ 成为 VIP会员 ]        登录  |  注册      我的  购物车
0
 
科目切换  联系我们 
    
  |   [请选择科目]

VIP:有效提升20分!  真题  历年真题 (可免费开通)/  百科全书/ 机考模拟平台/  最难真题榜/  自测/  攻打黄金十二宫/  真题检索/  真题下载/  真题词库
知识   必会知识榜/  最难知识榜/  知识点查询/      文档   学习计划/  精华笔记/  试题文档     纸质图书   《百科全书》HOT!!/         /        首页/  专区/  手机版/ 
免费智能真题库 > 历年试卷 > 信息系统监理师 > 2021年下半年 信息系统监理师 上午试卷 综合知识
  第46题      
  知识点:   信息系统建设   分析模型   开发阶段   开发人员   数据分析
  关键词:   分析模型   开发   数据分析   信息系统   数据        章/节:   信息系统建设       
  错误率: 54%      难度系数:      

 
信息系统建设项目进入开发阶段,由于数据分析模型开发人员能力欠缺,相关系统的开发任务未能按时完成。这种情况是由于()造成的。
 
 
  A.  技术不成熟
 
  B.  质量控制不到位
 
  C.  需求频繁变更
 
  D.  资源投入不足
 
 
 确定 并 查看答案解析     知识点讲解  我要标记      有奖找茬      上一题        下一题 
 

 
  第49题    2024年下半年  
   0%
某信息系统建设项目进入开发阶段,由于数据分析模型的开发人员能力欠缺,相关系统的开发任务未能按时完成。这种情况是由于()造成..
  第3题    2019年下半年  
   38%
为确保系统正式运行后发生问题时有稳妥可行的解决方案,承建商应制定( )。
  第30题    2017年上半年  
   64%
( )是软件生存期中的一系列相关软件工程活动的集合,它由软件规格说明、软件设计与开发、软件确认、软件改进等活动组成。
   知识点讲解    
   · 信息系统建设    · 分析模型    · 开发阶段    · 开发人员    · 数据分析
 
       信息系统建设
        信息系统建设周期长、投资大、风险大,比一般技术工程有更大的难度和复杂性。这是因为技术手段复杂;内容复杂,目标多样;投资密度大,效益难以计算;环境复杂多变。
        信息系统在使用过程中,随着其生存环境的变化,要不断维护、修改,当它不再适应的时候就要被淘汰,就要由新系统代替旧系统,这种周期循环称为信息系统的生命周期,如下图所示。
        
        信息系统的生命周期
        从上图可见,信息系统的生命周期可以分为系统规划、系统分析、系统设计、系统实施、系统运行和维护5个阶段。
        系统规划阶段的任务是对企业的环境、目标及现行系统的状况进行初步调查,根据企业目标和发展战略确定信息系统的发展战略,对建设新系统的需求做出分析和预测,同时考虑建设新系统所受的各种约束,研究建设新系统的必要性和可能性。根据需要与可能,给出拟建系统的备选方案。对这些方案进行可行性分析,写出可行性分析报告。可行性分析报告审议通过后,将新系统建设方案及实施计划编写成系统设计任务书。
        系统分析阶段的任务是根据系统设计任务书所确定的范围,对现行系统进行详细调查,描述现行系统的业务流程,指出现行系统的局限性和不足之处,确定新系统的基本目标和逻辑功能要求,即提出新系统的逻辑模型。这个阶段又称为逻辑设计阶段。这个阶段是整个系统建设的关键阶段,也是信息系统建设与一般工程项目的重要区别所在。系统分析阶段的工作成果体现在系统说明书中,这是系统建设的必备文件。它既是给用户看的,也是下一个阶段的工作依据。因此,系统说明书既要通俗,又要准确。用户通过系统说明书可以了解未来系统的功能,判断是不是所要求的系统。系统说明书一旦讨论通过,就是系统设计的依据,也是将来验收系统的依据。
        简单地说,系统分析阶段的任务是回答系统“做什么”的问题,而系统设计阶段要回答的问题是“怎么做”。该阶段的任务是根据系统说明书中规定的功能要求,考虑实际条件,具体设计实现逻辑模型的技术方案,也就是设计新系统的物理模型。这个阶段又称为物理设计阶段。这个阶段又可分为总体设计和详细设计两个阶段。这个阶段的技术文档是系统设计说明书。
        系统实施阶段是将设计的系统付诸实施的阶段。这一阶段的任务包括计算机等设备的购置、安装和调试、程序的编写和调试、人员培训、数据文件转换、系统调试与转换等。这个阶段的特点是几个互相联系、互相制约的任务同时展开,必须精心安排、合理组织。系统实施是按实施计划分阶段完成的,每个阶段应写出实施进展报告。系统测试之后写出系统测试分析报告。
        系统投入运行后,需要经常进行维护和评价,记录系统运行的情况,根据一定的规格对系统进行必要的修改,评价系统的工作质量和经济效益。
 
       分析模型
        9.3.1节从用户的观点对系统进行了用例建模,但获得了用例并不意味着分析的结束,还要对需求进行深入研究,获取关于问题域本质内容的分析模型。分析模型描述系统的基本逻辑结构,展示对象和类如何组成系统(静态模型),以及它们如何保持通信实现系统行为(动态模型)。
        为了使模型独立于具体的开发语言,需要把注意力集中在概念性问题上而不是软件技术问题上,这些技术的起始点就是领域模型。领域模型又称为概念模型或域模型,也就是找到代表那些事物与概念的对象,即概念类。概念类可以从用例模型中获得灵感,经过完善将形成分析模型中的分析类。在迭代开发过程中,每一个用例对应一个类图,描述参与这个用例实现的所有概念类,用例的实现主要通过交互图来表示。
        建立分析模型包括以下基本活动:
        (1)发现领域对象,定义概念类。发现类的方法有很多种,其中最广泛应用的莫过于“名词动词法”。它的主要规则是从名词与名词短语中提取对象与属性;从动词与动词短语中提取操作与关联;而所有格短语通常表明名词应该是属性而不是对象。
        (2)识别对象的属性。属性是描述对象静态特征的一个数据项。可以与用户进行交谈,提出问题来帮助寻找对象的属性。属性是概念类所拥有的特性,从概念建模的角度看,属性越简单越好,要保持属性的简单性,应该做到4个方面:仅定义与系统责任和系统目标有关的属性;使用简单数据类型来定义属性;不使用可由其他属性导出的属性(冗余属性);不为对象关联定义属性。最后,要对属性加以说明,包括名称和解释、数据类型,以及其他的一些要求。
        (3)识别对象的关系,包括建立类的泛化关系、对象的关联关系。理清类之间的层次关系,决定类之间的关系类型,确定关系的多重性和角色的导向性。多重性指定所在类可以实例化的对象数量(重数),即该类的多少个对象在一段特定的时间内可以与另一个类的一个对象相关联;导向性表示可以通过关联从源类导向到目标类,也就是说给定关联一端的对象就能够容易并直接地得到另一端的对象。
        (4)为类添加职责。找到了反映问题域本质的主要概念类,而且还理清它们之间的协作关系之后,我们就可以为这些类添加其相应的职责。类的职责包括两个主要内容,分别是类所维护的知识、类能够执行的行为。可以使用状态图来描述系统中单个对象的行为。
        (5)建立交互图。多个对象的行为通常采用对象交互来表示,UML 2.0提供的交互图有顺序图、交互概览图、通信图和定时图。每种图出于不同视点对行为有不同的表现能力,其中最常用的是顺序图,几乎可以用在任何系统的场合。顺序图的基本元素有对象、参与者、生命线、激活框、消息和消息路线,其中消息是顺序图的灵魂。
        :在整个开发的过程中,分析模型是不断演变的,最初的分析模型主要是围绕着领域知识进行的,对现实的事物进行建模。而后,则不断地加入设计的元素,演变成为运行于计算机上的架构和结构。其演变过程中最主要的变化体现在以下3个方面:
        (1)根据鲁棒分析和交互分析的结果,补充类的属性和操作,不断地细化其内容,更细致地刻化类之间的关联关系,以便体现代码的核心。
        (2)添加许多与计算机实现相关的技术类,以体现系统的实现结构。
        (3)利用分析模式、设计模式对类模型进行优化。
 
       开发阶段
               单元测试
               单元测试又称模块测试,是针对软件设计的最小单位——程序模块,进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
               . 单元测试的内容。
               在进行单元测试时,测试者需要依据详细设计说明书和源程序清单,了解该模块的I/O条件和模块的逻辑结构,主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例,使之对任何合理的输入和不合理的输入,都能鉴别和响应。这要求对所有的局部的和全局的数据结构、外部接口和程序代码的关键部分,都要进行桌面检查和严格的代码审查。
               在单元测试中进行的测试工作如下图所示,需要在五个方面对所测模块进行检查。
               
               单元测试的工作
               ①模块接口测试。
               在单元测试的开始,应对通过所测模块的数据流进行测试。如果数据不能正确地输入和输出,就谈不上进行其他测试。为此,对模块接口可能需要如下的测试项目:调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配;所测模块调用子模块时,它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配;是否修改了只作输入用的形式参数;输出给标准函数的参数在个数、属性、顺序上是否正确;全局量的定义在各模块中是否一致;限制是否通过形式参数来传送。
               当模块通过外部设备进行输入/输出操作时,必须附加如下的测试项目:文件属性是否正确;OPEN语句与CLOSE语句是否正确;规定的I/O格式说明与I/O语句是否匹配;缓冲区容量与记录长度是否匹配;在进行读写操作之前是否打开了文件;在结束文件处理时是否关闭了文件;正文书写/输入错误,以及I/O错误是否检查并做了处理。
               ②局部数据结构测试。
               模块的局部数据结构是最常见的错误来源,应设计测试用例以检查以下各种错误:不正确或不一致的数据类型说明;使用尚未赋值或尚未初始化的变量;错误的初始值或错误的缺省值;变量名拼写错或书写错;不一致的数据类型。可能的话,除局部数据之外的全局数据对模块的影响也需要查清。
               ③路径测试。
               由于通常不可能做到穷举测试,所以在单元测试期间要选择适当的测试用例,对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。对基本执行路径和循环进行测试,可以发现大量的路径错误。
               常见的不正确计算有:运算的优先次序不正确或误解了运算的优先次序;运算的方式错,即运算的对象彼此在类型上不相容;算法错;初始化不正确;运算精度不够;表达式的符号表示不正确。
               常见的比较和控制流错误有:不同数据类型的相互比较;不正确的逻辑运算符或优先次序;因浮点数运算精度问题而造成的两值比较不等;关系表达式中不正确的变量和比较符;“差1”错,即不正确地多循环一次或少循环一次;错误的或不可能的循环中止条件;当遇到发散的迭代时不能中止的循环;不适当地修改了循环变量等。
               ④错误处理测试。
               比较完善的模块设计要求能预见出错的条件,并设置适当的出错处理,以便在一旦程序出错时,能对出错程序重做安排,保证其逻辑上的正确性。这种出错处理也应当是模块功能的一部分。若出现下列情况之一,则表明模块的错误处理功能包含有错误或缺陷:出错的描述难以理解;出错的描述不足以对错误定位,不足以确定出错的原因;显示的错误与实际的错误不符;对错误条件的处理不正确;在对错误进行处理之前,错误条件已经引起系统的干预等。
               ⑤边界测试。
               在边界上出现错误是常见的。例如,在一段程序内有一个n次循环,当到达第n次重复时就可能会出错。另外,在取最大值或最小值时也容易出错。因此,要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例,认真加以测试。
               此外,如果对模块运行时间有要求的话,还要专门进行关键路径测试,以确定最坏情况下和平均意义下影响模块运行时间的因素。这类信息对进行性能评价是十分有用的。
               虽然模块测试通常是由编写程序的人自己完成的,但是项目负责人应当关心测试的结果。所有测试用例和测试结果都是模块开发的重要资料,必须妥善保存。
               总之,模块测试针对的程序规模较小,易于查错;发现错误后容易确定错误的位置,易于排错,同时多个模块可以并行测试。做好模块测试可为后续的测试打下良好的基础。
               . 单元测试的步骤。
               通常单元测试是在编码阶段进行的。在源程序代码编制完成,经过评审和验证,确认没有语法错误之后,就开始进行单元测试的测试用例设计。利用设计文档,设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入,应有预期的正确结果。
               模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的联系,用一些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种:
               驱动模块(driver)——相当于所测模块的主程序。它接收测试数据,把这些数据传送给所测模块,最后再输出实测结果。
               桩模块(stub)——也叫做存根模块。用以代替所测模块调用的子模块。桩模块可以做少量的数据操作,不需要把子模块所有功能都带进来,但不允许什么事情也不做。
               所测模块、与它相关的驱动模块及桩模块共同构成了一个“测试环境”,如下图所示。驱动模块和桩模块的编写会给测试带来额外的开销。因为它们在软件交付时不作为产品的一部分一同交付,而且它们的编写需要一定的工作量。特别是桩模块,不能只简单地给出“曾经进入”的信息。为了能够正确地测试软件,桩模块可能需要模拟实际子模块的功能,这样,桩模块的建立就不是很轻松了。
               
               单元测试的测试环境
               模块的内聚程度高,可以简化单元测试过程。如果每一个模块只完成一种功能,则需要的测试用例数目将明显减少,模块中的错误也容易被预测和发现。
               当然,如果一个模块要完成多种功能,且以程序包(package)的形式出现的也不少见,这时可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作,对关键模块还要做性能测试。对支持某些标准规程的程序,更要着手进行互联测试。有人把这种情况特别称为模块测试,以区别单元测试。
               集成测试
               集成测试也叫做组装测试或联合测试。通常,在单元测试的基础上,需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。
               . 组装时需要考虑的问题。
               ①在把各个模块连接起来的时候,穿越模块接口的数据是否会丢失;
               ②一个模块的功能是否会对另一个模块的功能产生不利的影响;
               ③各个子功能组合起来,能否达到预期要求的父功能;
               ④全局数据结构是否有问题;
               ⑤单个模块的误差累积起来,是否会放大,以至达到不能接受的程度。
               因此,在单元测试的同时可进行集成测试,发现并排除在模块连接中可能出现的问题,最终构成要求的软件系统。
               子系统的集成测试称为部件测试,它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。
               选择什么方式把模块组装起来形成一个可运行的系统,直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序以及生成测试用例的费用和调试的费用。
               . 模块组装成为系统的方式。
               模块组装成为系统的方式有两种:一次性组装方式和增殖式组装方式。
               ①一次性组装方式(big bang)。
               它是一种非增殖式组装方式,也叫做整体拼装。使用这种方式,首先对每个模块分别进行模块测试,再把所有模块组装在一起进行测试,最终得到要求的软件系统。例如,有一个模块系统结构,如下图(a)所示。其单元测试和组装顺序如下图(b)所示。
               
               一次性组装方式
               在如上图(b)中,模块d1,d2,d3,d4,d5是对各个模块做单元测试时建立的驱动模块,s1,s2,s3,s4,s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下,在分别完成模块单元测试的基础上,将所测模块连接起来进行测试。但是由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题,所以一次试运行成功的可能性并不很大。其结果是,发现有错误,却茫然找不到原因。查错和改错都会遇到困难。
               ②增殖式组装方式。
               这种组装方式又称渐增式组装,是首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统,在组装的过程中边连接边测试,以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。
               . 自顶向下的增殖方式。这种组装方式是将模块按系统程序结构,沿控制层次自顶向下进行组装。其步骤如下:首先以主模块作为所测模块兼驱动模块,所有直属于主模块的下属模块全部用桩模块代替,对主模块进行测试。再采用深度优先(如下图所示为自顶向下的增殖方式)或广度优先的策略,用实际模块替换相应的桩模块,再用桩模块代替它们的直接下属模块,与已测试的模块或子系统组装成新的子系统。然后,进行回归测试(即重新执行以前做过的全部测试或部分测试),排除组装过程中引入新的错误的可能。最后,判断是否所有的模块都已组装到系统中。是,则结束测试;否则,转到B去执行。
               
               自顶向下的增殖方式
               自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序模块结构中,判断常常出现在较高的层次里,因而,能够较早地遇到这种问题。如果主要控制有问题,尽早发现它能够减少以后的返工,这是十分必要的。如果选用按深度方向组装的方式,可以首先实现和验证一个完整的软件功能,可先对逻辑输入的分支进行组装和测试,检查和克服潜藏的错误和缺陷,验证其功能的正确性,就为其后对主要加工分支的组装和测试提供了保证。此外,功能可行性较早地得到证实,还能够增强开发者和用户成功的信心。
               . 自底向上的增殖方式。这种组装方式是从程序模块结构的最底层模块开始组装和测试。因为模块是自底向上进行组装的,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)已经组装并测试完成,所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。自底向上增殖的步骤如下:首先由驱动模块控制最底层模块的并行测试;也可以把最底层模块组合成实现某一特定软件功能的簇,由驱动模块控制它进行测试。再用实际模块代替驱动模块,与它已测试的直属子模块组装成为子系统。然后,为子系统配备驱动模块,进行新的测试。最后判断是否已组装到达主模块。是,则结束测试;否则,执行B。
               以如下图一(a)所示的一次性组装方式系统结构为例,可以用如下图二说明自底向上组装和测试的顺序。
               
               一次性组装方式
               
               自底向上的增殖方式
               . 混合增殖式测试。自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲,一种方式的优点是另一种方式的缺点。
               自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难,因为,桩模块在接收了所测模块发送的信息后,需要按照它所代替的实际子模块功能返回应该回送的信息,这必将增加建立桩模块的复杂度,而且导致增加一些附加的测试。同时,涉及复杂算法和真正输入/输出的模块一般在底层,它们是最容易出问题的模块,到组装和测试的后期才遇到这些模块,一旦发现问题,就会导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。
               自底向上增殖方式的缺点是“程序一直未能作为一个实体存在,直到最后一个模块加上去后才形成一个实体”。就是说,在自底向上组装和测试的过程中,对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块,而建立驱动模块一般比建立桩模块容易,同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试,可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试,提高测试效率。因此,通常是把以上两种方式结合起来进行组装和测试。
               在进行集成测试时,测试者应当确定关键模块,对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一:
               . 满足某些软件需求;
               . 在程序的模块结构中位于较高的层次(高层控制模块);
               . 较复杂、较易发生错误;
               . 有明确定义的性能要求。
               在做回归测试时,也应该集中测试关键模块的功能。
               . 集成测试的组织和实施。
               集成测试是一种正规测试过程,必须精心计划,并与单元测试的完成时间协调起来。在制定测试计划时,应考虑如下因素:
               ①采用何种系统组装方法来进行集成测试。
               ②集成测试过程中连接各个模块的顺序。
               ③模块代码编制和测试进度是否与集成测试的顺序一致。
               ④测试过程中是否需要专门的硬件设备。
               解决了上述问题之后,就可以列出各个模块的编制、测试计划表,标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
               在缺少软件测试所需要的硬件设备时,应检查该硬件的交付日期是否与集成测试计划一致。例如,若测试需要数字化仪和绘图仪,则相应的测试应安排在这些设备能够投入使用之时,并要为硬件的安装和交付使用保留一段时间,以留下时间余量。此外,在测试计划中需要考虑测试所需软件(驱动模块、桩模块、测试用例生成程序等)的准备情况。
               . 集成测试完成的标志。
               集成测试完成的标志主要有以下几项。
               ①成功地执行了测试计划中规定的所有集成测试。
               ②修正了所发现的错误。
               ③测试结果通过了专门小组的评审。
               集成测试应由专门的测试小组来进行,测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。
               在完成预定的集成测试工作之后,测试小组应负责对测试结果进行整理、分析,形成测试报告。测试报告中要记录实际的测试结果在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题,提供测试评审和最终决策,以提出处理意见。
               集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。
               确认测试
               确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中明确规定。确认测试一般包括有效性测试和软件配置复查,确认测试一般由独立的第三方测试机构进行。
               . 进行有效性测试。
               有效性测试是在模拟的环境下,运用黑盒测试的方法,验证所测软件是否满足需求规格说明书列出的需求。为此,需要制定测试计划、测试步骤以及具体的测试用例。通过实施预定的测试计划和测试步骤,确定软件的特性是否与需求相符,确保所有的软件功能需求都能得到满足,所有的软件性能需求都能达到。所有的文档都是正确且便于使用的。同时,对其他软件需求,例如可移植性、可靠性、易用性、兼容性、可维护性等,也都要进行测试,确认是否满足。
               在全部软件测试的测试用例运行完后,所有的测试结果可以分为两类。
               ①测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合,从而接受了这部分程序。
               ②测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致,因此要为它提交一份问题报告。
               . 软件配置复查。
               软件配置复查的目的是保证软件配置的所有成分都齐全,各方面的质量都符合要求,具有维护阶段所必须的细节,而且已经编排好分类的目录。
               在确认测试的过程中,还应当严格遵守用户手册和操作手册中规定的使用步骤,以便检查文档资料的完整性和正确性。
               系统测试
               系统测试是将通过集成测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起,在实际或者模拟运行(使用)环境下,对计算机系统进行一系列测试。
               系统测试的目的在于通过与系统的需求定义作比较,发现软件与系统定义不符合或与之矛盾的地方。
               验收测试
               验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。由用户参加设计测试用例。使用用户界面输入测试数据,并分析测试的输出结果。一般使用生产中的实际数据进行测试。
               目前在国内实际软件开发,特别是系统集成的过程中,验收测试往往在系统测试完成后、项目最终交付前进行。验收测试的测试计划、测试方案与测试案例一般由开发方制定,由用户方与监理方联合进行评审。验收小组由开发方、用户方、监理方代表、主管单位领导及行业专家构成。与确认测试及系统测试不同的是,验收测试往往不是对系统的全覆盖测试,而是针对用户的核心业务流程进行的测试;同时,测试的执行人员也不是开发方的测试组成员,而是由用户方的使用人员完成。
               近年来,越来越多的开发方及用户方认识到对项目进行最终验收测试的重要意义,因此,由第三方完成的专业化全覆盖型技术测试得到了广泛应用。由专门从事测试工作的第三方机构,根据系统的需求分析、用户手册、培训手册等,在开发人员及最终使用人员的配合下,完成对系统全面的测试工作。
 
       开发人员
        ①多媒体软件:项目负责人、学科教学专家、教学设计专家、软件工程师、多媒体素材制作专家和多媒体课件制作专家。
        ②多媒体电子出版物:策划编导、文字编辑、美术编辑、音乐编辑和多媒体编辑。
 
       数据分析
        数据分析是大数据处理过程中的重要组成部分,是大数据价值体现的核心环节。经典的机器学习方法是最常见的数据智能分析方法,近年来迅速发展的深度学习在某些领域取得了惊人的效果。在应用开发上,也形成了几种主流的大数据处理框架。
        机器学习中算法很多,也有很多不同种类的分类方法,一般分为监督学习和非监督学习(或无监督学习)。其中,监督学习是指利用一组已知类别的样本调整分类器的参数,使其达到所要求性能的过程,也称为监督训练,是从标记的训练数据来推断一个功能的机器学习任务。根据训练集中的标识是连续的还是离散的,可以将监督学习分为两类:回归和分类。
        回归是研究一个或一组随机变量对一个或一组属性变量的相依关系的统计分析方法。线性回归模型是假设自变量和因变量满足线性关系。Logistic回归一般用于分类问题,而其本质是线性回归模型,只是在回归的连续值结果上加了一层函数映射。
        分类是机器学习中的一个重要问题,其过程也是从训练集中建立因变量和自变量的映射过程,与回归问题不同的是,分类问题中因变量的取值是离散的,根据因变量的取值范围,可将分类问题分为二分类问题、三分类问题和多分类问题。根据分类采用的策略和思路的不同,分类算法大致包括:基于示例的分类方法,如K最近邻(K-Nearest Neighbor,KNN)方法;基于概率模型的分类方法,如朴素贝叶斯、最大期望算法EM等;基于线性模型的分类方法,如SVM;基于决策模型的分类方法,如C4.5、AdaBoost、随机森林等。
        在实际应用中,缺乏足够的先验知识,因此难以人工标注类别或进行人工类别标注的成本太高,学习模型是为了推断出数据的一些内在结构。因此,根据类别未知(没有被标记)的训练样本解决模式识别中的各种问题,称为无监督学习。常见的算法有:关联规则挖掘,是从数据背后发现事物之间可能存在的关联或联系。比如数据挖掘领域著名的“啤酒-尿不湿”的故事。K-means算法,基本思想是两个对象的距离越近,其相似度越大;相似度接近的若干对象组成一个簇;算法的目标是从给定数据集中找到紧凑且独立的簇。
        近年来发展起来的深度学习算法是基于原有的神经网络算法发展起来的,包括BP神经网络、深度神经网络。
        BP神经网络是一种反向传播的前馈神经网络,所谓前馈神经网络就是指各神经元分层排列,每个神经元只与前一层的神经元相连,接收前一层的输出,并输出给下一层。所谓反向传播是指从输出层开始沿着相反的方向来逐层调整参数的过程。BP神经网络由输入层、隐含层和输出层组成。
        深度神经网络主要包括卷积神经网络、循环神经网络等,也包括它们的各种改进模型。
        (1)卷积神经网络(Convolutional Neural Network,CNN)是一种前馈神经网络,其结构包括输入层、卷积层、池化层、全连接层以及输出层等。该算法在图像处理、模式识别等领域取得了非常好的效果。在CNN的发展过程中,最经典的模型是AlexNet,针对不同的应用需要,又产生了全卷积模型(FCN)、残差神经网络模型(ResNet)、DeepFace等模型结构。
        (2)循环神经网络(Recurrent Neural Network,RNN)是一种人工神经网络,在该网络中,除了层间的连接以外,同层各单元之间连接构成了一个有向图序列,允许它显示一个时间序列的动态时间行为。RNN可以使用它们的内部状态来处理输入序列,这使得它们适用于诸如未分割的、连续的手写识别或语音识别等任务。传统的RNN是很难训练的,往往会出现梯度消失或梯度爆炸等情况,因此又出现了多个扩展版本,如BiRNN、LSTM等。
        随着深度学习的快速发展和应用的普及,开始出现了一些深度学习框架。深度学习框架是一种界面、库或工具,可以使用户在无需深入了解底层算法的细节的情况下,能够更容易、更快速地构建深度学习模型。深度学习框架利用预先构建和优化好的组件集合定义模型,为模型的实现提供了一种清晰而简洁的方法。常见的深度学习框架有:Caffe,是一个广泛使用的开源深度学习框架,支持常用的网络模型,比如Lenet、AlexNet、ZFNet、VGGNet、GoogleNet、ResNet等;TensorFlow,是一个使用数据流图进行数值计算的开源软件库,图中的节点表示数学运算,而图边表示节点之间传递的多维数据阵列(又称张量),其为大多数复杂的深度学习模型预先编写好了代码,比如递归神经网络和卷积神经网络,灵活架构使我们能够在一个或多个CPU(以及GPU)上部署深度学习模型;Keras,是一个由Python编写的开源人工神经网络库,可以作为TensorFlow、Microsoft-CNTK和Theano的高阶应用程序接口,进行深度学习模型的设计、调试、评估、应用和可视化,Keras完全模块化并具有可扩展性,并试图简化复杂算法的实现难度。
        随着大数据技术的广泛深入,大数据应用已经形成了庞大的生态系统,很难用一种架构或处理技术覆盖所有应用场景。下文介绍几种当前主流的大数据分布式计算架构。
        Apache Hadoop是用于开发可靠、可伸缩、分布式计算的开源软件,是一套用于在由通用硬件构建的大型集群上运行应用程序的框架。包含的模块有:Hadoop分布式文件系统(HDFS),提供对应用程序数据的高吞吐量访问的分布式文件系统;Hadoop YARN,作业调度和集群资源管理的框架;Hadoop MapReduc,一个用于大型数据集并行处理的基于YARN的系统;Hadoop Ozone,Hadoop的对象存储;Hadoop Submarine,Hadoop的机器学习引擎。
        Apache Spark是加州大学伯克利分校的AMP实验室所开源的类Hadoop MapReduce的通用并行框架。Spark是一个分布式的内存计算框架,是专为大规模数据处理而设计的快速通用的计算引擎。Spark的计算过程保持在内存中,不需要读写HDFS,减少了硬盘读写,提升了计算速度。除了Map和Reduce操作外,Spark还延伸出如filter、flatMap、count、distinct等更丰富的操作。同时通过Spark Streaming支持处理数据流。
        Apache Storm是一个免费的开源分布式实时计算系统,可以可靠地处理无边界的数据流变,可以实现实时处理。Apache Storm速度很快,它是可扩展的,容错的,并且易于设置和操作。Apache Storm应用于实时分析、在线机器学习、连续计算、分布式RPC、ETL等等。Storm的核心是拓扑(Topology),拓扑被提交给集群,由集群中的主控节点分发代码,将任务分配给工作节点执行。
   题号导航      2021年下半年 信息系统监理师 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第46题    在手机中做本题
    在线人数   共计 8245人 在线 
    guxunmin@s..     zjyhsm@163..     sys7618@16..     mengxc042@..     sddzzhangk..     lml69@sohu..
    cxsz111111..     alence_122..     wangxinjsd..     nhchang@ma..     lqy800708@..     chunglj200..
    wurong_ycs..     ljl7883256..     ygzgz74309..     zibowp@163..     mahao606@1..     hydrogen24..
    zhao_si_xi..     tangxiongy..     741953038@..     luhaibin00..     jiayingtin..     liumh@zhen..
    sd-changyu..     lilujun.20..     412225214@..     hanxin1335..     306056356@..     631357578@..
    yanglirong..     plsco@163...     99908265@q..     54zephyrsu..     sxl5409@so..     huangyan85..
    guyazhe200..     czc318@163..     happy88888..     zxd123008@..     wangweijun..     jiaruihz@v..

本网站所有产品设计(包括造型,颜色,图案,观感,文字,产品,内容),功能及其展示形式,均已受版权或产权保护。
任何公司及个人不得以任何方式复制部分或全部,违者将依法追究责任,特此声明。
本站部分内容来自互联网或由会员上传,版权归原作者所有。如有问题,请及时联系我们。



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