免费智能真题库 > 历年试卷 > 信息系统监理师 > 2019年下半年 信息系统监理师 下午试卷 案例
  第1题      
  知识点:   成本控制   承建单位   监理单位   检验   建设单位   软件配置管理   设计阶段   数据说明   需求分析   编码   编码规范   测试计划   开发人员   配置管理   配置管理计划   软件配置   软件系统   软件需求   软件质量保证   数据报   系统设计阶段   需求分析阶段   有效性   预算   质量保证   注释

 
【说明】
为提升金融机构现金处理效率,降低现金综合运营成本,某省级银行拟建设区域现金中心管理系统,以实现现金处理集约化、数据集中化和监管全程化。建设单位承建单位A签订了建设合同,与监理单位B签订了监理合同。在项目建设过程中发生了如下事件;
【事件1】系统需求分析阶段结束后,承建单位A向监理工程师提交了项目需求小组编制并签章的《应用软件系统开发计划(初稿)》、《软件需求规格说明(初稿)》、《软件质量保证计划》、《软件配置管理计划》、《测试计划(初步)》、《用户使用说明 (初稿)》,申请进入系统设计阶段
【事件2】建设单位对项目的成本控制特别关心,要求在成本、技术、进度三者之间综合平衡,保证各项工作在各自的预算范围内进行。
【事件3】为提高代码质量,承建单位A的开发小组编制了《软件编码规范》,内容包括:
(1)变量名称应完全体现变量用途,需使用英文完整单词,不得缩写;
(2)为提高程序运行效率,不要在程序中写注释
(3)程序中数据说明的次序与语法无关,可以是任意的;
(4)为了体现项目的编程水平,程序编写要做到效率第一,清晰第二;
(5)输入输出的方式、格式应尽可能方便用户使用;
(6)对所有的输入数据都要进行检验,保证每个数据的有效性
【事件4】数据报表子系统预计代码规模500000行。开发人员完成250000行代码时,承建单位A项目负责人上报该子系统开发进度完成50%。
 
问题:1.1   (3分)
针对事件1,如果你是监理工程师,请依据需求分析阶段的监理控制要点,向承建单位提出你在监理过程中发现的问题。
 
问题:1.2   (5分)
针对事件2,作为监理工程师,你认为成本控制内容包括哪些方面?
 
问题:1.3   (6分)
针对事件3,作为监理工程师,请逐一指出这份《软件编码规范》的要求是否正确,不正确的请写出正确的做法。
 
问题:1.4   (6分)
针对事件4,作为监理工程师,你认为A单位的进度评估是否合理,为什么?
 
 
 

   知识点讲解    
   · 成本控制    · 承建单位    · 监理单位    · 检验    · 建设单位    · 软件配置管理    · 设计阶段    · 数据说明    · 需求分析    · 编码    · 编码规范    · 测试计划    · 开发人员    · 配置管理    · 配置管理计划    · 软件配置    · 软件系统    · 软件需求    · 软件质量保证    · 数据报    · 系统设计阶段    · 需求分析阶段    · 有效性    · 预算    · 质量保证    · 注释
 
       成本控制
        项目成本控制是一项重要的监理工作,其目的是在批准的预算范围内保质、按期地完成信息系统工程项目。成本控制是指根据成本预算所确定的成本基线,对项目执行中各阶段、各单项工程的实际成本进行监控及分析,与预算值进行对比,发现偏差并进行纠正和控制的一系列活动。
        信息系统工程的成本控制应当遵循以下原则。
        (1)以批准预算确定的费用基准线为基准。
        (2)对实施执行过程进行跟踪监督,记录并整理详细的实施执行报告。这是成本控制的基础,实施执行报告通常包含了项目各工作的所有费用支出。将实际的费用发生情况与批准的预算进行比较是发现问题的基本途径。
        (3)规范费用变更流程,费用变更通常与项目范围变更、质量变更、进度变更和环境变更直接相关联。变更请求可能是口头或书面的,可能是直接或间接的,可能是正式或非正式的。变更可能导致增加预算,也可能导致减少预算。不规范的变更可能带来项目执行的混乱,给成本控制造成困难。
        (4)要全面考虑,执行成本控制,并不是越节约越好,还应当综合考虑项目质量及进度方面的因素。不能因为节约成本而牺牲项目的质量,还应当考虑系统建设的连续性,以及与其他相关项目之间的统筹规划,同时从纵向和横向长远考虑整个单位的信息系统建设。
 
       承建单位
        负责具体实施的承建方应该有自己的项目管理,监理方代表项目建设方对承建方提出的工程计划进行监督和协调,对一些关键点进行控制。这些关键点主要属于进度、资金及质量的范畴,但不能涉及管理细节。工程项目管理主要以承建方为主,并强调在项目中组织并制定相关计划。
        在一个大型信息系统工程项目的建设中,承建方可能有多个,比如硬件提供商、软件开发商和系统集成商等。而在市场竞争日益激烈的今天,专业化能促进生产效率和提高生产质量,故而承建方常常分解成一定的层次结构,如总承包商和分包商等,从而使一部分人或企业专注于项目管理的科学化。
        从市场的角度看,总承包商既是买方又是卖方;从工程合同的角度来讲,他既要对建设方负全部法律责任,又要根据分包合同对分包商进行管理并履行义务,所有的主合同都会限定总承包商可以分包的最大范围。总承包商只能将某些具体的工程施工分包给分包商,但不能分包合同的责任和义务。总承包商不能期望通过分包逃避自己在合同中的法律和经济责任。
        作为分包商,一般情况下不与建设方直接发生合同关系。分包商只接受总承包商的统筹安排和调度,它只对总承包商承担分包合同内规定的责任并履行规定的义务。
        如果总承包商违反分包合同,则应该赔偿分包商的经济损失;分包商违反分包合同并造成建设方对总承包商的罚款或制裁,则分包商应该赔偿总承包商的损失。分包商是从总承包商处按分包合同索回其应得部分的,如果总承包商无力偿还债务,则分包商也同样蒙受损失,因此分包商的利益通常与总承包商的利益密切相关。
 
       监理单位
        项目监理方服务于信息系统建设合同的建设方与承建方。接受建设方委托后,监理方作为工程承包合同的监督者,所执行的原则是使工程承包合同成为“平等条约”;作为工程承包合同管理和工程款支付的签认者,所执行的原则是等价交换。因此监理方是为双方的利益服务的,而不仅仅为委托方服务。
        根据工程监理的深入程度不同,信息系统工程监理可分为如下三种。
        (1)咨询式监理。只解答用户方就企业信息化过程中提出的问题,其性质类似于业务咨询或方案咨询。这种方式费用最少,监理方的责任最轻,适合于对信息化有较好把握,并且技术力量较强的用户方采用。
        (2)里程碑式监理。将信息系统的建设划分为若干个阶段,在每一个阶段结束都设置一个里程碑,在里程碑到来时通知监理方进行审查或测试。一般来讲,这种方式比咨询式监理的费用要多,监理方也要承担一定的责任。不过,里程碑的确定需要承建方的参与,或者说监理合同的确立需要开发方的参与,否则就会因对里程碑的界定不同而引起纠纷。
        (3)全程式监理。一种复杂的监理方式,不但要求对系统建设过程中的里程碑进行审查,还应该派相应人员全程跟踪并收集系统开发过程中的信息,不断评估承建方的开发质量和效果。这种方式费用最高,监理方的责任也最大,适合于那些对信息系统的开发不太了解且技术力量偏弱的用户采用。
        监理单位的主要作用如下。
        (1)信息系统工程监理可以帮助建设单位更合理地保证工程的质量、进度和投资,并合理且客观地处理好它们之间的关系。监理由独立的第三方依据相关技术标准来对工程建设进行监督,这样对信息系统工程的建设质量更能起到保驾护航的作用。在项目建设全过程中,监理单位要依据国家有关法律和相关技术标准,遵循守法、公平、公正、独立的原则,对信息系统建设的过程进行监督和控制。即在确保质量、安全和有效性的前提下,合理安排进度和投资。监理单位要帮助建设单位对工程有关方面控制进行再控制,对承建单位项目控制过程进行监督管理。
        (2)在信息系统工程建设中,建设单位和承建单位有许多问题存在争议,双方都希望由第三方在工程的立项、设计、实施、验收及维护等各个阶段的效果都给予公正、恰当且权威的评价,这就需要监理单位来协调和保障这些工作的顺利进行。
        (3)由于建设单位在信息技术等相关领域普遍存在缺乏人才和经验不足的问题,实践证明建设单位自行管理对于提高项目投资的效益和建设水平是无益的。通过第三方的专业服务,帮助建设单位对项目实施控制,并对建设单位和承建单位都做出约束,是监理作用一个重要体现。
 
       检验
        检验(检查)包括测量、检查和测试等活动,目的是确定项目成果是否与要求相一致。检验可以在任何管理层次中开展,例如,一个单项活动的结果和整个项目的最后成果都可以检验。检验有各种名称,如复查、产品复查、审查及评审等。
        检查表(核对表)是常用的检验技术,检查表通常是由详细的条目组成的,用于检查和核对一系列必须采取的步骤是否已经实施的结构化工具,其具体内容因应用的不同而不同。检查表是一种有条理的工具,可简单可烦琐,语言表达形式可以是命令式,也可以是询问式。
        例如,下表是一个确认测试工具属性的检查表例子。
        
        一个确认测试工具属性的检查表例子
 
       建设单位
        建设方是建设项目的主要投资者,有时也是项目的最终使用者,是在工程建设阶段的全权代表,建设项目的经济效益,如投资额度、工程质量、投入使用时间和使用寿命直接关系着建设方的切身利益。虽然承建方、监理方与建设方是平等的市场主体,但由于建设方是投资方,掌握着项目的最终资源——决定了其他方为从属地位,所以说建设方对工程项目管理起着主导性作用。建设方加强和改善对项目的管理是从根本上实现项目按质如期完成的最有效的途径之一。
        作为项目管理集体中的主要负责人,建设方的作用是阐明本项目的目标并确认各项工作的轻重缓急,组织协调参与各方为此目标而通力合作,在管理决策过程中做出决策。但在某些具体的项目管理事务中,建设方并不总是处于主要负责人的地位,还要作为裁判、支持者、服务员及督促员的角色。
 
       软件配置管理
        在软件配置管理方面,监理的主要工作如下。
        (1)确保应用软件系统建设承建单位的配置管理组织和环境按照软件项目计划的要求成立并配备。
        (2)控制承建单位依据书面规程,为应用软件系统建设项目制定软件配置管理计划。
        (3)监督承建单位使用审批通过的、文档化的软件配置管理计划作为实施软件配置管理活动的基础。
        (4)控制承建单位依据的书面规程,对所有配置项/单元的更改请求和问题报告实施初始准备、记录、评审、批准和跟踪。
        (5)监督承建单位依据书面规程,控制对基线的更改。
        (6)控制承建单位编制软件配置管理报告,证明软件配置管理活动和软件基线库的内容,并提供给建设单位。
        (7)监督承建单位依据书面规程进行软件基线库的审核,进行软件配置管理活动状态的跟踪和记录。
        (8)定期审查软件配置管理活动和软件配置管理基线,以验证它们与文档定义的一致性。
        (9)审核软件配置管理活动及其工作产品,并给出软件配置管理监理报告。
 
       设计阶段
        设计阶段监理进行质量控制的要点如下。
        (1)了解建设单位的建设需求和对信息系统安全性的要求,协助建设单位制定项目质量目标规划和安全目标规划。
        (2)对各种设计文件提出设计质量标准。
        (3)进行设计过程跟踪,及时发现质量问题,并及时与承建单位协调解决。审查阶段性成果,并提出监理意见。审查承建单位提交的总体设计方案,审查承建单位对关键部位的测试方案。
        (4)协助承建单位建立质量保障体系。
        (5)协助承建单位完善现场质量管理制度。
        (6)组织设计文件及设计方案交底会,制定质量要求标准。
 
       数据说明
        在编写程序时,需注意数据说明的风格。为了使程序中的数据说明更易于理解和维护,必须注意以下几点。
        (1)数据说明的次序应当规范化,使数据属性容易查找。
        (2)当多个变量名用一个语句说明时,应当对这些变量按字母的顺序排列。
        (3)如果设计了一个复杂的数据结构,应当使用注释来说明在程序实现时这个数据结构的固有特点。
 
       需求分析
        软件需求分析监理的主要任务和目的是对软件需求分析的相关内容(重点是工程需求、功能需求、性能需求和设计约束等)、需求分析过程、需求分析活动及文档格式进行审查,确认是否满足要求,并确定其可否作为软件开发的前提和依据。
        (1)参与用户需求调研,尤其是关键业务及有甲乙双方决策人物参与的大型交流会等。
        (2)组织有关单位参加《需求规格说明书》技术联合评审会议,并根据国家相关标准、软件工程理论、用户需求及工程建设合同等进行审查并提出监理意见。
        (3)根据项目管理的理论,审核承建单位递交的《项目开发计划》。审核的重点是项目参与人员的技术工作背景是否适应本项目、工作分配及进度计划是否合理,以及软件开发风险因素分析、风险防范措施是否到位等。
        (4)审核承建单位提交的软件开发的质量保证及配置管理计划等软件生存周期支持过程的文档。
        (5)审核承建单位针对本工程投入的软硬件资源是否满足工程需要并及时到位。
        (6)审核承建单位在开发过程中使用的软件工具的合法性。
        (7)主持监理例会,做好监理日记,定期将项目进展情况及发现的问题汇总,并以项目月报的形式向项目建设单位做书面汇报。
        (8)做好项目往来文档的整理及存档工作。
        在需求分析阶段,监理工作的重点是对软件需求规格说明书和项目开发计划的审核。
 
       编码
               编码过程
               在给定了软件设计规格说明书后,下一步的工作就是编写代码。一般来说,编码工作可以分为四个步骤:
               (1)确定源程序的标准格式,制订编程规范。
               (2)准备编程环境,包括软硬件平台的选择,包括操作系统、编程语言、集成开发环境等。
               (3)编写代码。
               (4)进行代码审查,以提高编码质量。为提高审查的效率,在代码审查前需要准备一份检查清单,并设定此次审查须找到的bug数量。在审查时,要检查软件规格说明书与编码内容是否一致;代码对硬件和操作系统资源的访问是否正确;中断控制模块是否正确等。
               编码准则
               在嵌入式系统中,由于资源有限,且实时性和可靠性要求较高,因此,在开发嵌入式软件时,要注意对执行时间、存储空间和开发/维护时间这三种资源的使用进行优化。也就是说,代码的执行速度要越快越好,系统占用的存储空间要越小越好,软件开发和维护的时间要越少越好。
               具体来说,在编写代码时,需要做到以下几点:
               .保持函数短小精悍。一个函数应该只实现一个功能,如果函数的代码过于复杂,将多个功能混杂在一起,就很难具备可靠性和可维护性。另外,要限制函数的长度,一般来说,一个函数的长度最好不要超过100行。
               .封装代码。将数据以及对其进行操作的代码封装在一个实体中,其他代码不能直接访问这些数据。例如,全局变量必须在使用该变量的函数或模块内定义。对代码进行封装的结果就是消除了代码之间的依赖性,提高了对象的内聚性,使封装后的代码对其他行为的依赖性较小。
               .消除冗余代码。例如,将一个变量赋给它自己,初始化或设置一个变量后却从不使用它,等等。研究表明,即使是无害的冗余也往往和程序的缺陷高度关联。
               .减少实时代码。实时代码不但容易出错、编写成本较高,而且调试成本可能更高。如果可能,最好将对执行时间要求严格的代码转移到一个单独的任务或者程序段中。
               .编写优雅流畅的代码。
               .遵守代码编写标准并借助检查工具。用自动检验工具寻找缺陷比人工调试便宜,而且能捕捉到通过传统测试检查不到的各种问题。
               编码技术
                      编程规范
                      在嵌入式软件开发过程中,遵守编程规范,养成良好的编程习惯,这是非常重要的,将直接影响到所编写代码的质量。
                      编程规范主要涉及的三方面内容:
                      .命名规则。从编译器的角度,一个合法的变量名由字母、数字和下画线三种字符组成,且第一个字符必须为字母或下画线。但是从程序员的角度,一个好的名字不仅要合法,还要载有足够的信息,做到“见名知意”,并且在语意清晰、不含歧义的前提下,尽可能地简短。
                      .编码格式。在程序布局时,要使用缩进规则,例如变量的定义和可执行语句要缩进一级,当函数的参数过长时,也要缩进。另外,括弧的使用要整齐配对,要善于使用空格和空行来美化代码。例如,在二元运算符与其运算对象之间,要留有空格;在变量定义和代码之间要留有空行;在不同功能的代码段之间也要用空行隔开。
                      .注释的书写。注释的典型内容包括:函数的功能描述;设计过程中的决策,如数据结构和算法的选择;错误的处理方式;复杂代码的设计思想等。在书写注释时要注意,注释的内容应该与相应的代码保持一致,同时要避免不必要的注释,过犹不及。
                      性能优化
                      由于嵌入式系统对实时性的要求较高,因此一般要求对代码的性能进行优化,使代码的执行速度越快越好。以算术运算为例,在编写代码时,需要仔细地选择和使用算术运算符。一般来说,整数的算术运算最快,其次是带有硬件支持的浮点运算,而用软件来实现的浮点运算是非常慢的。因此,在编码时要遵守以下准则:
                      .尽量使用整数(char、short、int和long)的加法和减法。
                      .如果没有硬件支持,尽量避免使用乘法。
                      .尽量避免使用除法。
                      .如果没有硬件支持,尽量避免使用浮点数。
                      下图是一个例子,其中两段代码的功能完全一样,都是对一个结构体数组的各个元素进行初始化,但采用两种不同的方法来实现。下图(a)采用数组下标的方法,在定位第i个数组元素时,需要将i乘以结构体元素的大小,再加上数组的起始地址。下图(b)采用的是指针访问的方法,先把指针fp初始化为数组的起始地址,然后每访问完一个数组元素,就把fp加1,指向下一个元素。在一个奔腾4的PC上,将这两段代码分别重复10 700次,右边这段代码需要1ms,而左边这段代码需要2.13ms。
                      
                      算术运算性能优化的例子
 
       编码规范
        编码规范是程序编写过程中必须遵循的规则,一般会详细规定代码的语法规则、语法格式等,如下表所示。
        
        编码规范
        
        
        
 
       测试计划
        制定一个全面的测试计划是负载测试成功的关键。定义明确的测试计划将确保制定的方案能完成负载测试目标。这部分内容描述负载测试计划过程,包括分析应用程序、定义测试目标、计划方案实施、检查测试目标。在任何类型的系统测试中,制定完善的测试计划是成功完成测试的基础。负载压力测试计划有助于:
        ①构建能够精确地模拟工作环境的测试方案。负载测试指在典型的工作条件下测试应用程序,并检测系统的性能、可靠性和容量等。
        ②了解测试需要的资源。应用程序测试需要硬件、软件和人力资源。开始测试之前,应了解哪些资源可用并确定如何有效地使用这些资源。
        ③以可度量的指标定义测试成功条件。明确的测试目标和标准有助于确保测试成功。仅定义模糊的目标(如检测重负载情况下的服务器响应时间)是不够的。明确的成功条件应类似于“50个客户能够同时查看他们的账户余额,并且服务器响应时间不超过1分钟”。
        下面详细论述负载压力测试计划过程的4个步骤。
               分析应用程序
               负载测试计划的第一步是分析应用程序。应该对硬件和软件组件、系统配置以及典型的使用模型有一个透彻的了解。应用程序分析可以确保使用的测试环境能够在测试中精确地反映应用程序的环境和配置。
                      确定系统组件
                      绘制一份应用程序结构示意图。如果可能,从现有文档中提取一份示意图。如果要测试的应用程序是一个较大的网络系统的一部分,应该确定要测试的系统组件。确保该示意图包括了所有的系统组件,例如客户机、网络、中间件和服务器等。
                      如下图所示说明了一个由许多Web用户访问的联机银行系统。各Web用户连接到同一数据库以转移现金和支票余额。客户使用不同的浏览器,通过Web方式连接到数据库服务器。
                      
                      联机银行系统应用布署
                      描述系统配置
                      增加更多详细信息以完善示意图。描述各系统组件的配置。应当掌握以下信息:
                      . 连接到系统的用户数;
                      . 应用程序客户端计算机的配置情况(硬件、内存、操作系统、软件、开发工具等);
                      . 使用的数据库和Web服务器的类型(硬件、数据库类型、操作系统、文件服务器等);
                      . 服务器与应用程序客户端之间的通信方式;
                      . 前端客户端与后端服务器之间的中间件配置和应用程序服务器;
                      . 可能影响响应时间的其他网络组件(调制解调器等);
                      . 通信设备的吞吐量以及每个设备可以处理的并发用户数。
                      例如,在如上图所示的示意图中,多个应用程序客户端在访问系统。客户端的配置如下表所示。
                      
                      客户端配置内容
                      分析使用模型
                      定义系统的典型使用方式,并确定需要重点测试的功能。考虑哪些用户使用系统、每种类型用户的数量,以及每个用户的典型任务。此外,还应考虑任何可能影响系统响应时间的后台负载。
                      例如,假设每天上午有200名员工登录记账系统,并且该办公室网络有固定的后台负载:50名用户执行各种字处理和打印任务。可以创建一个200个虚拟用户登录访问记账数据库的方案,并检测服务器的响应时间。要了解后台负载对响应时间的影响,可以在运行方案的网络中再模拟员工执行字处理和打印活动的负载。
                      任务分布
                      除定义常规用户任务外,还应该查看这些任务的分布情况。例如,假设银行用户使用一个中央数据库为跨越多个州和时区的客户提供服务。250个应用程序客户端分布在两个不同的时区,全都连接到同一个Web服务器中。其中150个在芝加哥,另外100个在底特律。每个客户端从上午9点开始工作,但由于处于不同的时区,因此在任何特定时间内都不会有超过150个的用户同时登录。可以分析任务分布,以确定数据库活动峰值期的发生时间,以及负载峰值期间的典型活动。
               定义测试目标
               开始测试之前,应精确地定义想要实现的目标。
                      以可度量的指标制定目标
                      确定了负载测试的一般性目标后,应该以可度量指标制定更具针对性的目标。为了提供评估基准,应精确地确定、区分可接受和不可接受测试结果的标准。
                      例如:
                      . 一般性目标产品评估:选择Web服务器的硬件。
                      . 明确目标产品评估:在一台HP服务器和一台NEC服务器上运行同一个包含300个虚拟用户的组。当300个用户同时浏览Web应用程序页面时,确定哪一种硬件提供更短的响应时间。
                      . 测试目标
                      ①度量最终用户的响应时间,完成一个业务流程需要多长时间;
                      ②定义最优的硬件配置,哪一种硬件配置可以提供最佳性能;
                      ③检查可靠性,系统无错误或无故障运行的时间长度或难度;
                      ④查看硬件或软件升级对性能或可靠性有何影响;
                      ⑤评估新产品,应选择哪些服务器硬件或软件;
                      ⑥度量系统容量,在没有显著性能下降的前提下,系统能够处理多大的负载;
                      ⑦确定瓶颈,哪些因素会延长响应时间。
                      确定测试的时间
                      负载测试应贯穿于产品的整个生命周期。如下表说明了在产品生命周期的各个阶段有哪些类型的测试与之相关。
                      
                      产品生命周期与测试类型
               计划方案实施
               下一步是确定如何实现测试目标。
                      定义性能度量的范围
                      可以度量应用程序中不同点的响应时间。根据测试目标确定在哪里运行Vuser(虚拟用户)以及运行哪些Vuser。
                      . 度量端到端的响应时间。
                      可以在前端运行GUI Vuser(图形用户界面用户)或RTE Vuser(终端用户)来度量典型用户的响应时间。GUI Vuser可以将输入提交给客户端应用程序并从该应用程序接收输出,以模拟实际用户;RTE Vuser则向基于字符的应用程序提交输入,并从该应用程序接收输出,以模拟实际用户。
                      可以在前端运行GUI或RTE Vuser来度量跨越整个网络(包括终端仿真器或GUI前端、网络和服务器)的响应时间。如下图所示为端到端的响应时间。
                      
                      端到端的响应时间
                      . 度量网络和服务器响应时间。
                      可以通过在客户机运行Vuser(非GUI或RTE Vuser)来度量网络和服务器的响应时间(不包括GUI前端的响应时间)。Vuser模拟客户端对服务器的进程调用,但不包括用户界面部分。在客户机运行大量Vuser时,可以度量负载对网络和服务器响应时间的影响。如下图所示为网络和服务器的响应时间。
                      
                      网络和服务器的响应时间
                      . 度量GUI响应时间。
                      可以通过减去前两个度量值,来确定客户端应用程序界面对响应时间的影响。GUI响应时间=端到端响应时间-网络和服务器响应时间。如下图所示为GUI响应时间。
                      
                      GUI响应时间
                      . 度量服务器响应时间。
                      可以度量服务器响应请求(不跨越整个网络)所花费的时间。通过在与服务器直接相连的计算机上运行Vuser,可以度量服务器性能。如下图所示为服务器响应时间。
                      
                      服务器响应时间
                      . 度量中间件到服务器的响应时间。
                      如果可以访问中间件及其API,便可以度量服务器到中间件的响应时间。可以使用中间件API创建Vuser,来度量中间件到服务器的性能。如下图所示为中间件到服务器响应时间。
                      定义Vuser活动
                      根据对Vuser类型的分析以及它们的典型任务和测试目标来创建Vuser脚本。由于Vuser模拟典型最终用户的操作,因此Vuser脚本应包括典型的最终用户任务。例如,要模拟联机银行客户端,应该创建一个执行典型银行任务的Vuser脚本。需要浏览经常访问的页面,以转移现金或支票余额。
                      
                      中间件到服务器响应时间
                      根据测试目标确定要衡量的任务,并定义这些任务的事务。这些事务度量服务器响应Vuser提交的任务所花费的时间(端到端时间)。例如,要查看提供账户余额查询的银行Web服务器的响应时间,则应在Vuser脚本中为该任务定义一个事务。
                      此外,可以通过在脚本中使用集合点来模拟峰值期活动。集合点指示多个Vuser在同一时刻执行任务。例如,可以定义一个集合点,以模拟70个用户同时更新账户信息的情况。
                      选择Vuser
                      确定用于测试的硬件配置之前,应该先确定需要的Vuser的数量和类型。要确定运行多少个Vuser和哪些类型的Vuser,请综合考虑测试目标来查看典型的使用模型。以下是一些一般性规则:
                      . 使用一个或几个GUI用户来模拟每一种类型的典型用户连接;
                      . 使用RTE Vuser来模拟终端用户;
                      . 运行多个非GUI或非RTE Vuser来生成每个用户类型的其余负载。
                      例如,假设有五种类型的用户,每种用户执行一个不同的业务流程,如下表所示。
                      
                      Vuser的数量和类型
                      选择测试硬件和软件
                      硬件和软件应该具有强大的性能和足够快的运行速度,以模拟所需数量的虚拟用户。
                      在确定计算机的数量和正确的配置时,请考虑以下事项。
                      . 建议在一台单独的计算机上运行测试工具主控台。
                      . 在一台Windows计算机只能运行一个GUI Vuser;而在一台UNIX计算机上则可以运行几个GUI Vuser。
                      . GUI Vuser测试计算机的配置应该尽量与实际用户的计算机配置相同。
                      关于每个测试组件的硬件要求,请参考下表一和下表二。要获得最佳性能,应满足表中所列要求。
                      
                      测试机硬件与软件要求(Windows配置要求)
                      注意:对于一个要运行许多事务的长方案,结果文件需要几个MB的磁盘空间。负载生成器计算机还需要几个MB的磁盘空间来存储临时文件(如果没有NFS)。有关运行时文件存储的详细信息,请参阅第10章“配置方案”。
                      有关最新的安装要求,请访问
                      http://www.mercuryinteractive.com/products/loadrunner/technical/
                      
                      测试机硬件与软件要求(UNIX配置要求)
                      注意:对于一个要运行许多事务的长方案,结果文件需要几个MB的磁盘空间。负载生成器计算机还需要几个MB的磁盘空间来存储临时文件(如果没有NFS)。有关运行时文件存储的详细信息,请参阅第10章“配置方案”。
               检查测试目标
               测试计划应该基于明确定义的测试目标。下面概述了常规的测试目标。
               ①度量最终用户响应时间。
               ②定义最优的硬件配置。
               ③检查可靠性。
               ④查看硬件或软件升级。
               ⑤评估新产品。
               ⑥确定瓶颈。
               ⑦度量系统容量。
                      度量最终用户响应时间
                      查看用户执行业务流程以及从服务器得到响应所花费的时间。例如,假设想要检测:系统在正常的负载情况下运行时,最终用户能否在20秒内得到所有请求的响应。如下图显示了一个银行应用程序的负载和响应时间度量之间的关系。
                      
                      负载和响应时间度量关系
                      定义最优的硬件配置
                      检测各项系统配置(内存、CPU速度、缓存、适配器、调制解调器)对性能的影响。了解系统体系结构并测试了应用程序响应时间后,可以度量不同系统配置下的应用程序响应时间,从而确定哪一种设置能够提供理想的性能级别。
                      例如,可以设置三种不同的服务器配置,并针对各个配置运行相同的测试,以确定性能上的差异。
                      . 配置1:200MHz、64MB RAM。
                      . 配置2:200MHz、128MB RAM。
                      . 配置3:266MHz、128MB RAM。
                      检查可靠性
                      确定系统在连续的高工作负载下的稳定性级别。可以创建系统负载:强制系统在短时间内处理大量任务,来模拟系统在数周或数月的时间内通常会遇到的活动类型。
                      查看硬件或软件升级
                      执行回归测试,以便对新旧版本的硬件或软件进行比较。可以查看软件或硬件升级对响应时间(基准)和可靠性的影响。应用程序回归测试需要查看新版本的效率和可靠性是否与旧版本相同。
                      评估新产品
                      可以运行测试,以评估单个产品和子系统在产品生命周期中的计划阶段和设计阶段的表现。例如,可以根据评估测试来选择服务器的硬件或数据库套件。
                      确定瓶颈
                      可以运行测试以确定系统的瓶颈,并确定哪些因素导致性能下降,例如,文件锁定、资源争用和网络过载。使用负载压力测试工具,以及网络和计算机监视工具以生成负载,并度量系统中不同点的性能。如下图所示为系统不同点的性能。
                      
                      系统不同点的性能
                      度量系统容量
                      度量系统容量,并确定系统在不降低性能的前提下能提供多少额外容量。要查看容量,可以查看现有系统中性能与负载间的关系,并确定出现响应时间显著延长的位置。该处通常称为响应时间曲线的“拐点”。确定了当前容量后,便可以确定是否需要增加资源以支持额外的用户。如下图所示为响应时间与负载关系。
                      
                      响应时间与负载关系
 
       开发人员
        ①多媒体软件:项目负责人、学科教学专家、教学设计专家、软件工程师、多媒体素材制作专家和多媒体课件制作专家。
        ②多媒体电子出版物:策划编导、文字编辑、美术编辑、音乐编辑和多媒体编辑。
 
       配置管理
        随着信息系统软件版本不断变化,开发时间的紧迫以及多平台开发环境的采用,使得软件开发、维护面临越来越多的问题,其中包括对当前多种软件的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等。
        信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。界定软件的组成项目,对每个项目的变更进行管控(版本控制),并维护不同项目之间的版本关联,以使软件在开发过程中任一时间的内容都可以被追溯。其关键活动包括:配置管理计划、配置项管理、版本控制、变更控制、配置审计、状态报告等。
               配置管理计划
               根据信息系统软件运维制度和规范、标准,制定配置管理计划,主要包括以下内容。
               (1)该项目对配置管理的要求。
               (2)实施配置管理的责任人、组织及其职责。
               (3)需要开展的配置管理活动及其进度安排。
               (4)采用的方法和工具等。
               配置与配置项
               “配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性,及其内容及相关文档,软件版本,变更文档,软件运行的支持数据,以及其他一切保证软件一致性的组成要素。
               为了方便对“配置”进行管理,“配置”经常被划分为各类配置项,这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合,在配置管理过程中,配置项被作为一个单一的实体对待。配置项包括各种管理文档和技术文档,源程序与目标代码,以及运行所需的各种数据等。同时,应该建立配置库来管理所有的配置项。
               版本控制
               版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加,修改或删除,配置项的版本随之演变。应当记录每个软件配置项的所有历史记录,并记录该软件配置项由何人创建,何人在何时因何原因进行了修改等信息,以及对这些软件配置项版本的进行检索和信息查询等活动。
               变更控制
               变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部分,包含评估、协调、批准/拒绝、实施对配置项的变更。
               配置审计
               配置审计是对配置管理的独立的查检过程,确认受控软件配置项满足需求并就绪。其内容如下。
               (1)功能审计:配置项的变更控制是否和配置管理计划中的描述相一致。
               (2)物理审计:配置项的完整性、正确性、一致性和可跟踪性。
               状态报告
               状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单,变更请求当前的处理状态,以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程,它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。
 
       配置管理计划
        主要内容
        配置管理计划的主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。由配置控制委员会审批该计划。
        主要步骤
        制订配置管理计划的主要步骤如下:
        (1)建立并维护配置管理的组织方针。
        (2)确定配置管理所需要的资源。
        (3)分配责任。
        (4)培训计划。
        (5)确定和配置管理有关的项目干系人并确定其介入时机。
        (6)制订识别配置项的准则。
        (7)制订配置项管理表。
        (8)制订基线计划。
        (9)制订配置库备份计划。
        (10)制订变更控制流程。
        (11)制订审批计划。
 
       软件配置
        软件配置是指一个软件产品在软件生存周期各个阶段所产生的各种形式(机器可读和人工可读)和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项。
 
       软件系统
        网络系统软件包括网络操作系统和网络协议等。网络操作系统是指能够控制和管理网络资源的软件,是由多个系统软件组成,在基本系统上有多种配置和选项可供选择,使得用户可根据不同的需要和设备构成最佳组合的互联网络操作系统。网络协议是保证网络中两台设备之间正确传送数据的约定。
 
       软件需求
        在进行需求获取之前,首先要明确需要获取什么,也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常,这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等,并预先估计以后系统可能达到的目标。此外,还需要注意其他非功能性的需求。具体内容如下。
        (1)功能需求。
        (2)性能需求。
        (3)用户或人的因素。
        (4)环境需求。
        (5)界面需求。
        (6)文档需求。
        (7)数据需求。
        (8)资源使用需求。
        (9)安全保密要求。
        (10)可靠性要求。
        (11)软件成本消耗与开发进度需求。
        (12)其他非功能性要求。
               需求分析的任务
               需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体来说有下面几点。
               (1)确定软件系统的综合要求,包括系统界面、功能、性能、安全性、保密性、可靠性、运行等方面的要求。
               (2)分析软件系统的数据要求,包括基本数据元素、数据元素之间的逻辑关系、数据量、峰值等。
               (3)导出系统的逻辑模型,在结构化方法中可用数据流图来描述;在面向对象分析方法中可以用类模型来描述。
               (4)修正项目开发计划。
               (5)如有必要,可开发一个原型系统以验证用户的需求。
               软件需求的分类
               下面介绍软件需求的分类。
               (1)功能需求。所开发的软件必须具备什么样的功能。
               (2)非功能需求。它是指产品必须具备的属性或品质,如可靠性、性能响应时间、容错性和可扩展性等。
               (3)设计约束。其也称为限制条件、补充规约,这通常是对解决方案的一些约束说明。
               软件需求分析方法
               需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。它定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的,数据域具有数据流、数据内容和数据结构3种属性。通常一种需求分析方法总要利用其中一种或几种属性。
 
       软件质量保证
        软件质量保证包括与以下7个主要活动相关的各种任务。
        (1)应用技术方法。软件质量保证首先从一组技术方法和工具开始,这些方法和工具帮助分析人员形成高质量的规格说明和高质量的设计。
        (2)进行正式的技术评审。这是一种由技术人员实施的程式化会议,其唯一的目的是揭露质量问题。
        (3)测试软件。软件测试组合了多种测试策略,这些测试策略带有一系列有助于有效地检测错误的测试用例及设计方法。
        (4)标准的实施。多数情况下,标准由客户或某些章程确定。与标准是否一致的评估可以被软件开发者作为正式技术评审的一部分来进行。
        (5)控制变更。变更控制过程通过对变更的正式申请、评价变更的特性和控制变更的影响等直接提高软件的质量。变更控制应用于软件开发期间和较后的软件维护阶段。
        (6)计量。其包括某些技术上的和面向管理的计量。
        (7)记录保存和报告。为软件质量保证提供收集和传播软件质量保证信息的过程。评审、监察、变更控制、测试和其他软件质量保证活动的结果必须变成项目历史记录的一部分,并且应当把它传播给需要知道这些结果的开发人员。
 
       数据报
        对于短报文来说,一个报文分组就足够容纳所传送的数据信息。一般单个报文分组称数据报(Datagram)。数据报的服务以传送单个报文分组为主要目标。原CCITT研究组把数据报定义为,能包含在单个报文分组数据域中的报文,且传送它到目标地址与其他已发送或将要发送的报文分组无关,这样报文分组号可以省略。也就是说,每个分组的传送是被单独处理的,它本身携带有足够的信息。
        数据报的一般格式如下表所示:
        
        数据报格式
        发送数据报与发送信件和邮包一样。在数据报服务控制下,网络接受来自源的单一报文分组,并独立地传到目的点。数据报服务是无连接的服务。
 
       系统设计阶段
        系统设计工作应该自顶向下地进行。首先设计总体结构,然后再逐层深入,直至进行每一个模块的设计。总体设计主要是指在系统分析的基础上,对整个系统的划分(子系统)、设备(包括软、硬设备)的配置、数据的存储规律以及整个系统实现规划等方面进行合理的安排。
 
       需求分析阶段
        . 确定软件的可靠性目标;
        . 分析可能影响可靠性的因素;
        . 确定可靠性的验收标准;
        . 制定可靠性管理框架;
        . 制定可靠性文档编写规范;
        . 制定可靠性活动初步计划;
        . 确定可靠性数据收集规范。
 
       有效性
        有效性是指软件产品在指定的使用环境下,使用户获得满足准确度和完整性要求的规定目标的能力。
 
       预算
        预算是指组织按照一定的业务量水平及质量水平,估计各项成本、计算预算成本,并以预算成本为控制经济活动的依据,衡量其合理性。当实际状态和预算有了较大差异时,要查明原因并采取措施加以控制。编制预算是以预算项目的成本预测及IT服务工作量的预测为基础的。
        预算的编制方法主要有增量预算和零基预算,其选择依赖于企业的财务政策。增量预算是以去年的数据为基础,考虑本年度成本、价格等的期望变动,调整去年的预算。在零基预算下,组织实际所发生的每一活动的预算最初都被设定为零。为了在预算过程中获得支持,对每一活动必须就其持续的有用性给出有说服力的理由。即详尽分析每一项支出的必要性及其取得的效果,确定预算标准。零基预算方法迫使管理当局在分配资源前认真考虑组织经营的每一个阶段。这种方法通常比较费时,所以一般几年用一次。
        .预算项目的成本预测。预算项目一般按照成本项目划分,一旦确定一般要保持稳定,这样一是可以使企业了解其成本变动趋势,进行纵向比较,也可以与其他企业之间进行横向比较,二是为成本管理活动提供了一个简单的处理基础,如折旧可以按照成本类型的不同分别进行处理。
        在预算编制时,各预算项目的成本一般都是未知的,如加班工资、外部网收费等,因此必须对其进行预测。预测这些成本是以从前IT会计年度的成本数据为基础或以未来工作量的预测为基础进行的。IT成本管理必须谨慎地估计不可控制的成本的变化。
        .IT服务工作量预测。IT工作量是成本变化的一个主要原因之一,因此,在编制预算的时候,要预测未来IT工作量。不仅成本管理活动需要估计工作量,在服务级别管理和容量管理中也需要对工作量进行预测。工作量预测将以工作量的历史数据为基础,考虑数据的更新与计划的修改,得出未来的IT工作量。
 
       质量保证
        系统质量是指反映系统或产品满足规定或隐含需求的能力的特征和特性全体。软件质量管理是指对软件开发过程进行的独立的检查活动,由质量保证、质量规划和质量控制三个主要活动构成。质量保证是指为保证系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动,其目的是开发高质量的系统。
               质量特性
               讨论系统质量首先要了解系统的质量特性。已经有多种软件质量模型来描述软件质量特性,目前较多采用的如ISO/IEC 9126软件质量模型和Mc Call软件质量模型。ISO/IEC 9126已经被ISO/ICE 25010系统和软件质量模型所取代,其主要改进包括将兼容性作和安全性作为质量特性,ISO/IEC 25012数据质量模型与ISO/IEC 25030使用质量模型作为补充。
                      ISO/ICE 25010系统和软件质量模型
                      ISO/ICE 25010系统和软件质量模型包含8个质量特性,每个特性由一组相关的质量子特性组成,如下图所示。该产品质量模型既可以用于软件,又可以用于任何包含软件的计算机系统。
                      
                      产品质量模型
                      其中,各质量特性和质量子特性的含义如下。
                      (1)功能适合性(functional suitability)。与一组功能及其指定的性质的存在有关的一组属性。功能是指满足规定或隐含需求的那些功能。
                      .功能完整性(functional completeness):与对规定任务和用户目标加以实现的功能是否完整有关的属性。
                      .功能适当性(functional appropriateness):与对规定任务和用户目标能否提供一组功能以及这组功能是否适合有关的属性。
                      .功能正确性(functional correctness):与能够得到正确或相符的结果或效果有关的产品或系统属性。
                      (2)性能效率(performance efficiency)。在规定条件下,系统的性能水平与所用资源量之间的关系有关的一组属性。
                      .时间特性(time behavior):与响应和处理时间以及软件执行其功能时的吞吐量有关的属性。
                      .资源利用率(resource utilization):与系统执行其功能时所使用的资源量以及使用资源的类型有关的属性。
                      .容量(capacity):与系统满足特定需求时指标参数的最大限制有关的属性。
                      (3)兼容性(compatibility)。与系统或组件与其他系统或组件进行信息交换,或在不同软硬件环境中执行所需功能有关的一组属性。
                      .共存性(co-existence):与同其他系统运行在同一环境使用相同的资源而不相互影响的能力相关的属性。
                      .互操作性(interoperability):与同其他指定系统进行交互操作的能力相关的属性。
                      (4)易用性(usability)。与为使用所需的努力和由一组规定或隐含的用户对这样使用所作的个别评价有关的一组属性。
                      .可识别性(appropriateness recognizability):与用户识别系统是否满足需求有关的属性。
                      .易学性(learnability):与用户为学习使用产品(例如操作控制、输入、输出)的有效性、效率、风险和满意度相关的属性。
                      .易操作性(operability):与用户为进行操作和操作控制所付出的努力有关的属性。
                      .错误防御(user error protection):与阻止用户错误输入有关的属性。
                      .界面美观性(user interface aesthetics):与系统用户界面使用户进行愉快满意交互有关的属性。
                      .可访问性(accessibility):与用户可访问系统完成特定目标的范围和能力有关的属性。
                      (5)可靠性(reliability)。与在规定的一段时间内和规定的条件下,系统维持在其性能水平有关的能力。
                      .成熟性(maturity):与正常操作情况下满足可靠性需求有关的属性。
                      .可用性(availability):与系统运行可用使用能力有关的属性。
                      .容错性(fault tolerance):与在系统错误或违反指定接口的情况下,维持指定的性能水平的能力有关的属性。
                      .易恢复性(recoverability):与在故障发生后,重新建立其性能水平并恢复直接受影响数据的能力,以及为达到此目的所需的时间和努力有关的属性。
                      (6)安全性(security)。与避免对程序及数据的非授权故意或意外访问的能力有关的系统属性。
                      .机密性(confidentiality):与系统确保只有授权才能访问其数据能力有关的属性。
                      .完整性(integrity):与系统防止未经授权对数据和程序进行访问和修改能力有关的属性。
                      .不可抵赖性(non-repudiation):与对系统使用行为及发生时间真实性有关的属性。
                      .可审计性(accountability):与对系统使用行为进行追踪有关的属性。
                      .真实性(authenticity):与证明主体或资源身份是所声称的身份有关的属性。
                      (7)可维护性(maintainability)。与进行规定的修改所需要的努力有关的一组属性。
                      .模块性(modularity):与所组成系统的模块独立性有关的属性。
                      .可复用性(reusability):与模块用于其他系统有关的属性。
                      .易分析性(analyzability):与为诊断缺陷或失效原因,或为判定待修改的部分所需努力有关的属性。
                      .易修改性(modifiability):与进行修改、排错或适应环境变换所需努力有关的属性。
                      .易测试性(testability):为确认经修改系统所需努力有关的属性。
                      (8)可移植性(portability)。与系统可从某一环境转移到另一环境的能力有关的一组属性。
                      .适应性(adaptability):与系统转移到不同环境时的处理或手段有关的属性。
                      .易安装性(installability):与在指定环境下对系统进行安装/卸载所需努力有关的属性。
                      .易替换性(replaceability):与一产品在该软件环境中用来替代指定的其他软件的可能和努力有关的属性。
                      Mc Call软件质量模型
                      Mc Call软件质量模型从软件产品的运行、修正、转移三个方面确定了11个质量特性,如下图所示。Mc Call也给出了一个三层模型框架,第一层是质量特性,第二层是评价准则,第三层是度量指标。
                      
                      Mc Call软件质量模型
               质量保证
               质量保证是指为保证系统或产品充分满足用户要求的质量而进行的有计划、有组织的活动,其目的是生产高质量的产品。在系统质量方面强调三个要点:首先系统必须满足用户规定的需求,与用户需求不一致的系统,就无质量可言;其次系统应遵循规定标准所定义的一系列开发准则,不遵循这些准则的系统,其质量难以得到保证;最后系统还应满足某些隐含的需求,例如希望有好的可理解性、可维护性等,而这些隐含的需求可能未被明确地写在用户规定的需求中,如果系统只满足它的显性需求而不满足其隐含需求,那么该系统的质量是令人担忧的。
               质量保证包括7个主要活动相关的各种任务,分别是应用技术方法、进行正式的技术评审、测试系统、标准的实施、控制变更、度量(metrics)、记录保存和报告。
 
       注释
        与C语言相同。多行注释:/*…*/。单行注释://。
   题号导航      2019年下半年 信息系统监理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
 
第1题    在手机中做本题