免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2017年上半年 信息系统项目管理师 下午试卷 案例
  第2题      
  知识点:   项目组织   编码   编码规范   单元测试   开发人员   响应时间   需求分析   运维   质量保证   中标   总体设计

 
【说明】
某系统集成公司A中标某信息中心IT运维平台开发项目,公司A任命小李为项目经理。小李在项目启动阶段确定了项目团队和项目组织架构,项目团队分为三个小组:研发组、测试组和产品组。各组成员分别来自研发部、测试部以及产品管理部。
小李制定了项目整体进度计划,将项目分为需求分析、设计、编码、试运行和验收五个阶段。为保证项目质量,小李请有着多年的编码、测试工作经历的测试组组长张工兼任项目的质量保证人员。
在项目启动会上,小李对张工进行了口头授权,并要求张工在项目的重要阶段(如完成需求分析、完成总体设计、完成单元编码和测试等)必须对项目交付物进行质量检查。在检查时,张工可以根据自己的经验提出要求,对于不满足要求的工作,必须立即进行返工。
项目在实施过程中,遇到一些问题,具体如下:
在项目组完成编码单元测试工作,准备进行系统集成前,张工按照项目经理小李的要求进行了质量检查。在检查过程中,张工凭借多年开发经验,认为某位开发人员负责的一个模块代码存在响应时间长的问题,并对其开具了不符合项报告。但这位开发人员认为自己是严格按照公司编码规范编写的,响应时间长不是自己的问题。经过争吵,张工未能说服该开发人员,同时考虑到该模块对整体项目影响不大,张工没有再追究此事,该代码也没有修改。
在项目上线前,信息中心领导组织技术专家到项目现场进行调研和考察。专家组对已完成的编码进行了审查,发现很多模块不能满足甲方的质量要求。
 
问题:2.1   (10分)
请指出该项目在质量管理方面可能存在哪些问题?
 
问题:2.2   (8分)
请指出张工在质量检查中可能存在的问题。
 
问题:2.3   (6分)
针对上述问题,如果你是项目经理,你会采取哪些措施?
 
问题:2.4   (5分)
在(1)~(5)中填写恰当内容(从候选答案中选择一个正确选项,将该选项编号填入答题纸对应栏内)。
在质量控制中,可以使用的工具和技术有(1)、(2)、(3)、(4)、(5)。
候选答案:
A、趋势分析 B、试验设计 C、因果图 D、统计抽样
E、帕累托图 F、质量成本 G、成本/效益分析 H、控制图
 
 
 

   知识点讲解    
   · 项目组织    · 编码    · 编码规范    · 单元测试    · 开发人员    · 响应时间    · 需求分析    · 运维    · 质量保证    · 中标    · 总体设计
 
       项目组织
        组织结构一般有三种类型:职能型、矩阵型和项目型。矩阵型可进一步划分为弱矩阵、平衡矩阵和强矩阵。不同组织结构的区别如下表所示。
        
        组织机构的三种类型
        组织文化
        大多数组织已经形成了自己独特的、可描述的文化。这些文化体现在:
        .组织的共同价值观、行为准则、信仰和期望。
        .组织的方针、办事程序。
        .组织对于职权关系的观点。
        .众多其他的因素。
        .组织文化常常会对项目产生直接的影响。
 
       编码
               编码过程
               在给定了软件设计规格说明书后,下一步的工作就是编写代码。一般来说,编码工作可以分为四个步骤:
               (1)确定源程序的标准格式,制订编程规范。
               (2)准备编程环境,包括软硬件平台的选择,包括操作系统、编程语言、集成开发环境等。
               (3)编写代码。
               (4)进行代码审查,以提高编码质量。为提高审查的效率,在代码审查前需要准备一份检查清单,并设定此次审查须找到的bug数量。在审查时,要检查软件规格说明书与编码内容是否一致;代码对硬件和操作系统资源的访问是否正确;中断控制模块是否正确等。
               编码准则
               在嵌入式系统中,由于资源有限,且实时性和可靠性要求较高,因此,在开发嵌入式软件时,要注意对执行时间、存储空间和开发/维护时间这三种资源的使用进行优化。也就是说,代码的执行速度要越快越好,系统占用的存储空间要越小越好,软件开发和维护的时间要越少越好。
               具体来说,在编写代码时,需要做到以下几点:
               .保持函数短小精悍。一个函数应该只实现一个功能,如果函数的代码过于复杂,将多个功能混杂在一起,就很难具备可靠性和可维护性。另外,要限制函数的长度,一般来说,一个函数的长度最好不要超过100行。
               .封装代码。将数据以及对其进行操作的代码封装在一个实体中,其他代码不能直接访问这些数据。例如,全局变量必须在使用该变量的函数或模块内定义。对代码进行封装的结果就是消除了代码之间的依赖性,提高了对象的内聚性,使封装后的代码对其他行为的依赖性较小。
               .消除冗余代码。例如,将一个变量赋给它自己,初始化或设置一个变量后却从不使用它,等等。研究表明,即使是无害的冗余也往往和程序的缺陷高度关联。
               .减少实时代码。实时代码不但容易出错、编写成本较高,而且调试成本可能更高。如果可能,最好将对执行时间要求严格的代码转移到一个单独的任务或者程序段中。
               .编写优雅流畅的代码。
               .遵守代码编写标准并借助检查工具。用自动检验工具寻找缺陷比人工调试便宜,而且能捕捉到通过传统测试检查不到的各种问题。
               编码技术
                      编程规范
                      在嵌入式软件开发过程中,遵守编程规范,养成良好的编程习惯,这是非常重要的,将直接影响到所编写代码的质量。
                      编程规范主要涉及的三方面内容:
                      .命名规则。从编译器的角度,一个合法的变量名由字母、数字和下画线三种字符组成,且第一个字符必须为字母或下画线。但是从程序员的角度,一个好的名字不仅要合法,还要载有足够的信息,做到“见名知意”,并且在语意清晰、不含歧义的前提下,尽可能地简短。
                      .编码格式。在程序布局时,要使用缩进规则,例如变量的定义和可执行语句要缩进一级,当函数的参数过长时,也要缩进。另外,括弧的使用要整齐配对,要善于使用空格和空行来美化代码。例如,在二元运算符与其运算对象之间,要留有空格;在变量定义和代码之间要留有空行;在不同功能的代码段之间也要用空行隔开。
                      .注释的书写。注释的典型内容包括:函数的功能描述;设计过程中的决策,如数据结构和算法的选择;错误的处理方式;复杂代码的设计思想等。在书写注释时要注意,注释的内容应该与相应的代码保持一致,同时要避免不必要的注释,过犹不及。
                      性能优化
                      由于嵌入式系统对实时性的要求较高,因此一般要求对代码的性能进行优化,使代码的执行速度越快越好。以算术运算为例,在编写代码时,需要仔细地选择和使用算术运算符。一般来说,整数的算术运算最快,其次是带有硬件支持的浮点运算,而用软件来实现的浮点运算是非常慢的。因此,在编码时要遵守以下准则:
                      .尽量使用整数(char、short、int和long)的加法和减法。
                      .如果没有硬件支持,尽量避免使用乘法。
                      .尽量避免使用除法。
                      .如果没有硬件支持,尽量避免使用浮点数。
                      下图是一个例子,其中两段代码的功能完全一样,都是对一个结构体数组的各个元素进行初始化,但采用两种不同的方法来实现。下图(a)采用数组下标的方法,在定位第i个数组元素时,需要将i乘以结构体元素的大小,再加上数组的起始地址。下图(b)采用的是指针访问的方法,先把指针fp初始化为数组的起始地址,然后每访问完一个数组元素,就把fp加1,指向下一个元素。在一个奔腾4的PC上,将这两段代码分别重复10 700次,右边这段代码需要1ms,而左边这段代码需要2.13ms。
                      
                      算术运算性能优化的例子
 
       编码规范
        编码规范是程序编写过程中必须遵循的规则,一般会详细规定代码的语法规则、语法格式等,如下表所示。
        
        编码规范
        
        
        
 
       单元测试
        单元测试是通过对每个最小的软件模块进行测试,对源代码的每一个程序单元实行测试,检查各个程序模块是否正确地实现了规定的功能,确保其能正常工作。
        单元测试由开发人员执行,一般由模块单元开发者设计测试用例并修改缺陷。单元测试具有如下三种行为:
        (1)单元测试是一种验证行为。验证程序中的每项功能的正确性为代码的重构提供了保障。
        (2)单元测试是一种设计行为。软件设计阶段考虑如何实现软件的功能、性能和用户界面等,而不考虑实现的代码。单元测试关注于软件的具体功能实现是否符合需求设计,而不仅仅定位于代码的实现。
        (3)单元测试是一种文档的行为。单元测试是函数或类等软件模块如何设计、实现和使用的最佳文档。
               单元测试的特性
               单元测试具有如下特性:
               (1)单入测试是覆盖代码区间的最小单元。
               (2)单元测试支持组包测试。
               (3)单元测试的执行率为100%。
               (4)单元测试确定变动后的代码对原代码的功能未做修改。
               (5)单元测试提升了软件系统整体的可信赖度。
               (6)单元测试包含对可能出现问题的代码进行排查。
               (7)单元测试支持开发人员先测试后编码的行为。
               (8)单元测试支持变化,任何变化导致的失败情况均会被反映出来。
               (9)单元测试准确地反映了代码设计,便于后期维护。
               单元测试的认识误区
               (1)单元测试是全部规范。单元测试本质上是种特定的测试方式,是系统的实现方法规范的补充,而不是整个规范。
               (2)单元测试浪费时间。单元测试不会浪费太多的时间,反而会节省项目时间。
               (3)单元测试只需使用测试工具就可完成。单元测试工具生成的测试用例往往无法对被测试的程序进行有效覆盖,必须进行人工检查。
               (4)单元测试是针对代码进行的测试。单元测试依据详细设计报告设计测试用例,不仅仅只是对代码的测试。
               单元测试的原则
               单元测试需要遵守如下原则。
               (1)单元测试遵循《软件单元测试计划》和《软件单元测试说明》文档,根据详细设计编写单元测试用例,而不能根据代码编写单元测试用例。
               (2)单元测试执行前先检查单元测试入口条件是否全部满足。
               (3)单元测试必须满足一定的覆盖率,重要的接口函数必须做单元测试。
               (4)单元测试在修改代码后修改测试用例,将全部单元测试用例进行回归测试。
               (5)单元测试必须满足预定的出口条件才能结束。
               (6)在单元测试完成后,记录《单元测试报告》,分析问题的种类和原因。
               (7)单元测试始终在配置管理控制下进行,软件问题的修改必须符合变动规程的要求。
               (8)单元测试文档、测试用例、测试记录和被测程序等齐全,符合规范。
               单元测试的主要任务
               单元测试主要针对程序模块进行测试,主要有5个任务:模块接口、局部数据结构、执行路径、出错处理和边界条件。
                      模块接口测试
                      通过对被测模块的数据流进行测试,检查进出模块的数据是否正确。因此,必须对模块接口,包括参数表、调用子模块的参数、全局变量、文件I/O操作进行测试。具体涉及以下内容:
                      .模块接受输入的实际参数个数与模块的形式参数个数是否一致。
                      .输入的实际参数与模块的形式参数的类型是否匹配。
                      .输入的实际参数与模块的形式参数所使用的单位是否一致。
                      .调用其他模块时,所传送的实际参数个数与被调用模块的形式参数的个数是否相同。
                      .调用其他模块时,所传送的实际参数与被调用模块的形式参数的类型是否匹配。
                      .调用其他模块时,所传送的实际参数与被调用模块的形式参数的单位是否一致。
                      .调用内部函数时,参数的个数、属性和次序是否正确。
                      .在模块有多个入口的情况下,是否引用有与当前入口无关的参数。
                      .是否修改了只读型参数。
                      .全局变量是否在所有引用它们的模块中都有相同的定义。
                      局部数据结构测试
                      测试用例检查局部数据结构的完整性,如数据类型说明、初始化、默认值等方面的问题,并测试全局数据对模块的影响。
                      在模块的工作过程中,必须测试模块内部的数据能否保持完整性,包括内部数据的内容、形式及相互关系不发生错误。
                      局部数据结构应注意以下几类错误:不正确或不一致的类型说明;错误的初始化或默认值;错误的变量名,如拼写错误或书写错误;下溢、上溢或者地址错误。
                      执行路径测试
                      测试用例对模块中重要的执行路径进行测试,其中对基本执行路径和循环进行测试往往可以发现大量的路径错误。测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。
                      常见的错误有误解或不正确的算术优先级;混合模式的运算;错误的初始化;精确度不够精确;表达式的不正确符号表示。
                      针对判定和条件覆盖,测试用例能够发现的错误有:不同数据类型的比较;不正确的逻辑操作或优先级;应当相等的地方由于精确度的错误而不能相等;不正确的判定或不正确的变量;不正确的或不存在的循环终止;当遇到分支循环时不能退出;不适当地修改循环变量。
                      出错处理测试
                      测试出错处理的重点是模块在工作中发生了错误,其中的出错处理设施是否有效。
                      检验程序中的出错处理可能面对的情况有以下几种:
                      .对运行发生的错误描述难以理解。
                      .所报告的错误与实际遇到的错误不一致。
                      .出错后,在错误处理之前就引起系统的干预。
                      .例外条件的处理不正确。
                      .提供的错误信息不足,以致无法找到错误的原因。
                      边界条件测试
                      边界条件测试是单元测试的最后一步,必须采用边界值分析方法来设计测试用例。在为限制数据处理而设置的边界处,测试模块是否能够正常工作。
                      一些与边界有关的数据类型,如数值、字符、位置、数量、尺寸等,以及边界的第一个、最后一个、最大值、最小值、最长、最短、最高和最低等特征。
                      在边界条件测试中,应设计测试用例检查一下情况。
                      .在n次循环的第0次、第1次、第n次是否有错误。
                      .运算或判断中取最大值、最小值时是否有错误。
                      .数据流、控制流中刚好等于、大于、小于确定的比较值是否出现错误。
               单元测试的执行过程
               通常,单元测试在编码阶段进行,在源程序代码编制完成,经过评审和验证,确认没有语法错误之后,开始设计单元测试用例。
               由于模块并不是一个独立的程序,在考虑测试模块时,同时要考虑与其有关的外界联系,因此使用一些辅助模块去模拟与被测模块相关的其他模块。辅助模块分为以下两种:
               (1)驱动(Drive)模块。用于模拟被测试模块的上一级模块,相当于被测模块的主程序,用于接收测试数据,并把这些数据传送给被测模块,启动被测模块,最后输出实测结果。
               (2)桩(Stub)模块。用于模拟被测模块工作过程中所调用的模块。桩模块一般只进行很少的数据处理,不需要把子模块的所有功能都带进来,但不允许什么事情也不做。
               单元测试停止的条件
               单元测试停止的条件如下。
               (1)单元测试用例设计已经通过评审。
               (2)按照单元测试计划完成了所有规定单元的测试。
               (3)达到了测试计划中关于单元测试所规定的覆盖率的要求。
               (4)被测试的单元每千行代码必须发现至少3个错误。
               (5)软件单元功能与设计相一致。
               (6)在单元测试中发现的错误已经得到修改,各级缺陷修复率达到标准。
 
       开发人员
        ①多媒体软件:项目负责人、学科教学专家、教学设计专家、软件工程师、多媒体素材制作专家和多媒体课件制作专家。
        ②多媒体电子出版物:策划编导、文字编辑、美术编辑、音乐编辑和多媒体编辑。
 
       响应时间
        系统响应时间是指用户发出完整请求到系统完成任务给出响应的时间间隔。处于系统中不同的角色的人,对响应时间的关注点是不一样的。从系统管理员的角度来看,系统响应时间指的是服务器收到请求的时刻开始计时,到服务器完成执行请求,并将请求的信息返回给用户这一段时间的间隔。这个“服务器”包含的范围是给用户提供服务的接口服务器,中间的一些业务处理的服务器和排在最后面的数据库服务器。这里并不包含请求和响应在网络上的通信时间。
        从用户的角度来看,响应时间是用户发出请求开始计时,(如按下“确认”或Enter键的时刻),到用户的请求的相应结果展现在用户机器的屏幕的时候的这一段时间的间隔。这个时间称为“客户端的响应时间”,它等于客户端的请求队列加上服务器的响应时间和网络的响应时间的总和。可以看出,从用户角色感受的“响应时间”是所有响应时间中最长的,很多影响因素不在应用系统的范围内,如数据包在网络上的传输时间、域名解析时间等。
        响应时间超出预期太多的应用系统会导致用户的反感,因为系统在让他们等待,这样会降低他们的工作效率,延长他们的工作时间。位于互联网上的Web网站也存在同样的问题,有调查表明,如果一个Web网页不能在8秒钟内下载到访问的用户端,访问者就会失去耐性,他们有的尝试其他同类型的网站,有的可能访问竞争者的网站,并且可能影响他们圈子里面的人访问这个网站的兴趣和取向。对于一个指望这些访问者变为客户的网站站点而言,响应时间带来的后果等同于销售额的损失。
        系统的响应时间对每个用户来说都是不一样的,以下因素会影响系统的平均响应时间:
        (1)和业务相关,处理不同的业务会有不同的响应时间。
        (2)和业务组合有关,业务之间可能存在依赖关系或其他,也会相互影响。
        (3)和用户的数量有关,大并发量会严重影响应时间。
        有多种方法可以用来测试响应时间,常用的有两种方法,分别是首字节响应时间和末字节响应时间。首字节响应时间是指向服务器发送请求与接收到响应的第一个字节之间的时间,末字节响应时间是指向服务器发送请求与接收到响应的最后一个字节之间的时间。通过测量响应时间,可以知道所有客户端用户完成一笔业务所用的时间以及平均时间、最大时间。
        米勒曾经给出了3个经典的有关响应时间的建议,至今仍有参加价值:
        (1)0.1秒:用户感觉不到任何延迟。
        (2)1秒:用户愿意接受的系统立即响应的时间极限。即当执行一项任务的有效反馈时间在0.1~1秒之内时,用户是愿意接受的。超过此数据值,则意味着用户会感觉到有延迟,但只要不超过10秒,用户还是可以接受的。
        (3)10秒:用户保持注意力执行本次任务的极限,如果超过此数值时仍然得不到有效的反馈,用户会在等待计算机完成当前操作时转向其他的任务。
 
       需求分析
        需求分析的方法种类繁多,不过如果按照分解的方式不同,可以很容易地划分出几种大类型:
        (1)结构化分析方法。本节后续内容将详细讨论SA的内容。
        (2)面向对象分析方法。将在10.3节中进行详细介绍。
        (3)面向问题域的分析(Problem Domain Oriented Analysis, PDOA)方法。PDOA更多地强调描述,而少强调建模。它的描述大致分为关注问题域和关注解系统的待求行为这两个方面。问题框架是PDOA的核心元素,是将问题域建模成为一系列相互关联的子域。也可以把问题框架看作是开发上下文图,但不同的是上下文图的建模对象是针对解系统,而问题框架则是针对问题域。也就是说,问题框架的目标就是大量地捕获更多有关问题域的信息。PDOA方法现在还在研究阶段,并未广泛应用。
               业务流程分析
               业务流程分析的目的是了解各个业务流程的过程,明确各个部门之间的业务关系和每个业务处理的意义,为业务流程的合理化改造提供建议,为系统的数据流程变化提供依据。
               业务流程分析的步骤如下:
               (1)通过调查掌握基本情况。
               (2)描述现有业务流程(绘制业务流程图)。
               (3)确认现有业务流程。
               (4)对业务流程进行分析。
               (5)发现问题,提出解决方案。
               (6)提出优化后的业务流程。
               在业务流程图中使用的基本符号如下图所示。
               数据流图
               DFD是结构化分析中的重要方法和工具,是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型,在信息系统开发中,一般将它作为需求说明书的组成部分。
               
               业务流程图符号
               DFD从数据传递和加工的角度,利用图形符号通过逐层细分地描述系统内各个部件的功能和数据在它们之间传递的情况,来说明系统所完成的功能。具体来说,DFD的主要作用如下:
               (1)DFD是理解和表达用户需求的工具,是系统分析的手段。由于DFD简明易懂,理解它不需要任何计算机专业知识,因此通过它同客户交流很方便。
               (2)DFD概括地描述了系统的内部逻辑过程,是系统分析结果的表达工具,因而也是系统设计的重要参考资料,是系统设计的起点。
               (3)DFD作为一个存档的文字材料,是进一步修改和充实开发计划的依据。
               在DFD中,通常会出现4种基本符号,分别是数据流、加工、数据存储和外部实体(数据源及数据终点)。数据流是具有名字和流向的数据,在DFD中用标有名字的箭头表示。加工是对数据流的变换,一般用圆圈表示。数据存储是可访问的存储信息,一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者,是不能由计算机处理的成分,它们分别表明数据处理过程的数据来源及数据去向,用标有名字的方框表示。下图是一个典型的DFD示例。
               
               办理取款手续的DFD
               为了表达数据处理过程中的数据加工情况,用一个DFD是不够的。稍微复杂的实际问题,在DFD中常常出现十几个甚至几十个加工。这样的DFD看起来很不清楚。层次结构的DFD能很好地解决这一问题。按照系统的层次结构进行逐步分解,并以分层的DFD反映这种结构关系,能清楚地表达整个系统。
               下图给出分层DFD的示例。数据处理S包括3个子系统1、2、3。顶层下面的第一层DFD为DFD/L1,第二层的DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说,它的上层图称为父图,在它下一层的图则称为子图。
               
               分层数据流图
               概括地说,画DFD的基本步骤,就是“自顶向下,逐层分解”。检查和修改的原则如下:
               (1)DFD中的所有图形符号只限于前述4种基本图形元素。
               (2)顶层DFD必须包括前述4种基本元素,缺一不可。
               (3)顶层DFD中的数据流必须封闭在外部实体之间。
               (4)每个加工至少有一个输入数据流和一个输出数据流。
               (5)在DFD中,需按层给加工框编号。编号表明了该加工处在哪一层,以及上下层的父图与子图的对应关系。
               (6)规定任何一个数据流子图必须与它上一层的一个加工对应,两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。
               (7)可以在DFD中加入物质流,帮助用户理解DFD。
               (8)图上每个元素都必须有名字。
               (9)DFD中不可夹带控制流。
               数据字典
               数据字典是关于数据的信息的集合,也就是对DFD中包含的所有元素的定义的集合。DFD和数据字典共同构成系统的逻辑模型。没有DFD,数据字典难以发挥作用;没有数据字典,DFD就不严格。只有把DFD和对DFD中每个元素的精确定义放在一起,才能共同构成系统的规格说明。
               数据字典的设计包括:数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息:名称、别名或编号、分类、描述、何处使用。
               对加工的描述是数据字典的组成内容之一,常用的加工描述方法有结构化语言、判定树及判定表。
               (1)结构化语言:介于自然语言和形式语言之间的一种半形式语言,在自然语言基础之上加了一些限度,使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允许3种基本结构。结构化语言也只允许3种基本语句,即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定,与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用3类词汇:祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。
               (2)判定树:若一个动作的执行不只依赖一个条件,而与多个条件有关,那么这项策略的表达就比较复杂。如果用结构化语言的判断语句,就有多重嵌套,层次一多,可读性就会下降。用判定树来表示,可以更直观一些。
               (3)判定表:一些条件较多、在每个条件下取值也较多的判定问题,可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系,判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑,是在某种条件取值组合情况下可能的结果,它不能表达加工的顺序,也不能表达循环结构,因此判定表不能成为一种通用的设计工具。
 
       运维
        运维是运行维护的简称,是一种IT服务形态。在《信息技术服务分类与代码》(GB/T 29264-2012)中,对运行维护服务(operation maintenance service)给出的定义是“采用信息技术手段及方法,依据需方提出的服务级别要求,对其信息系统的基础环境、硬件、软件及安全等提供的各种技术支持和管理服务”。
        运维是信息系统全生命周期中的重要阶段,也是内容最多、最繁杂的部分,是对信息系统提供维护和技术支持以及其他相关的支持和服务。运维服务的主要对象包括基础设施、硬件平台、基础软件、应用软件以及依赖于IT基础设施的数据中心、业务应用等信息系统,其范围可以是单个IT基础设施的运维,也可以是整体IT基础设施和业务应用的总体运维。运维服务交付内容主要包括咨询评估、例行操作、响应支持和优化改善。
        在《信息技术服务分类与代码》(GB/T 29264-2012)中,将运行维护服务分成基础环境运维、硬件运维服务、软件运维服务、安全运维服务、运维管理服务和其他运行维护服务六类,每类运维服务及其说明见下表。
        
        运维服务分类与代码
        
        任何组织和个人提供运维服务需要依据需方提出的服务级别要求,并确保提供的运行维护服务符合与需方约定的质量要求。因此,具备相应运维服务能力是服务组织提供服务的必要条件,比如规范和明确运维人员的岗位职责和工作安排、提供绩效考核量化依据、提供解决事故和问题经验、提供知识的积累和共享手段、实现完善的IT运维管理、提高组织经营水平和服务水平等等。在《信息技术服务运行维护第1部分:通用要求》(GB/T 28827.1-2012)中给出了供方运维服务的能力模型,该模型定义了运行维护服务能力的四个关键要素:人员、资源、技术和过程,每个要素通过关键指标反映应具备的条件和能力。模型也给出了供方为持续提升运维能力的管理方法。
 
       质量保证
        系统质量是指反映系统或产品满足规定或隐含需求的能力的特征和特性全体。软件质量管理是指对软件开发过程进行的独立的检查活动,由质量保证、质量规划和质量控制三个主要活动构成。质量保证是指为保证系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动,其目的是开发高质量的系统。
               质量特性
               讨论系统质量首先要了解系统的质量特性。已经有多种软件质量模型来描述软件质量特性,目前较多采用的如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)、记录保存和报告。
 
       中标
        中标人的投标应当符合下列条件之一:
        (1)能够最大限度地满足招标文件中规定的各项综合评价标准。
        (2)能够满足招标文件的实质性要求,并且经评审的投标价格最低。但是投标价格低于成本的除外。
        评标委员会经评审,认为所有投标都不符合招标文件要求的,可以否决所有投标。依法必须进行招标的项目的所有投标被否决的,招标人应当重新招标。
        在确定中标人前,招标人不得与投标人就投标价格、投标方案等实质性内容进行谈判。评标委员会成员应当客观、公正地履行职务,遵守职业道德,对所提出的评审意见承担个人责任。评标委员会成员不得私下接触投标人,不得收受投标人的财物或其他好处。评标委员会成员和参与评标的有关工作人员不得透露对投标文件的评审和比较、中标候选人的推荐情况,以及与评标有关的其他情况。
        中标人确定后,招标人应当向中标人发出中标通知书,并同时将中标结果通知所有未中标的投标人。中标通知书对招标人和中标人具有法律效力。中标通知书发出后,招标人改变中标结果的,或者中标人放弃中标项目的,应当依法承担法律责任。招标人和中标人应当自中标通知书发出之日起30日内,按照招标文件和中标人的投标文件订立书面合同。招标人和中标人不得再行订立背离合同实质性内容的其他协议。招标文件要求中标人提交履约保证金的,中标人应当提交。
        依法必须进行招标的项目,招标人应当自确定中标人之日起15日内,向有关行政监督部门提交招标投标情况的书面报告。
 
       总体设计
        总体设计也被称为概要设计,是系统开发过程中关键的一步。系统的质量及一些整体特性基本上是由这一步的成果所决定的。总体设计的主要任务是完成对系统总体结构和基本框架的设计。系统总体结构设计包括两方面的内容,系统总体布局设计和系统模块化结构设计。
        模块化设计的工作任务包括如下内容。
        .按需求和设计原则将系统划分为若干功能模块。
        .决定每个模块的具体功能和职责。
        .分析和确定模块间的调用关系。
        .确定模块间的信息传递。
        系统总体布局方案包括系统网络拓扑结构设计和系统资源配置设计方案。
   题号导航      2017年上半年 信息系统项目管理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
 
第2题    在手机中做本题