全部科目 > 软件评测师 >
2010年下半年 上午试卷 综合知识
第 28 题
知识点 安全性   开发阶段   配置管理   建设单位   评审   软件评审   信息系统建设   质量管理   质量控制  
关键词 安全   内部评审   配置管理   软件开发   信息系统   质量管理   质量控制   开发   评审  
章/节 软件工程基础  
 
 
软件评审作为质量控制的一个重要手段,已经被业界广泛使用。评审分为内部评审和外部评审。关于内部评审的叙述,正确的包括(28)。
①对软件的每个开发阶段都要进行内部评审
评审人员由软件开发组、质量管理配置管理人员组成,也可邀请用户参与
评审人数根据实际情况确定,比如根据软件的规模等级和安全性等级等指标而定
④内部评审由用户单位主持,由信息系统建设单位组织,应成立评审委员会
 
  A.  ①②④
 
  B.  ①②③
 
  C.  ②③④
 
  D.  ①②③④
 
 




 
 
相关试题     软件工程基础 

  第37题    2014年下半年  
在各种不同的软件需求中, (37)描述了产品必须要完成的任务,可以在用例模型中予以说明。

  第21题    2014年下半年  
在数据库逻辑结构设计阶段,需要 (20 ) 阶段形成的( 21)作为设计依据。

  第33题    2020年下半年  
某软件项目的活动图如下图所示,其中顶点表示项目里程碑,连接顶点的边表示包含的活动,边上的数字表示活动的持续时间(天)。完成该项目的最短时间是(33)天。设活动A-E的最早开始时间为第1天..

 
知识点讲解
· 安全性
· 开发阶段
· 配置管理
· 建设单位
· 评审
· 软件评审
· 信息系统建设
· 质量管理
· 质量控制
 
        安全性
        安全性是指软件产品在指定使用环境下,获得可接受的对人类、事务、软件、财产或环境有害的风险级别的能力。
 
        开发阶段
               单元测试
               单元测试又称模块测试,是针对软件设计的最小单位——程序模块,进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
               . 单元测试的内容。
               在进行单元测试时,测试者需要依据详细设计说明书和源程序清单,了解该模块的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)所示的一次性组装方式系统结构为例,可以用如下图二说明自底向上组装和测试的顺序。
               
               一次性组装方式
               
               自底向上的增殖方式
               . 混合增殖式测试。自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲,一种方式的优点是另一种方式的缺点。
               自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难,因为,桩模块在接收了所测模块发送的信息后,需要按照它所代替的实际子模块功能返回应该回送的信息,这必将增加建立桩模块的复杂度,而且导致增加一些附加的测试。同时,涉及复杂算法和真正输入/输出的模块一般在底层,它们是最容易出问题的模块,到组装和测试的后期才遇到这些模块,一旦发现问题,就会导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。
               自底向上增殖方式的缺点是“程序一直未能作为一个实体存在,直到最后一个模块加上去后才形成一个实体”。就是说,在自底向上组装和测试的过程中,对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块,而建立驱动模块一般比建立桩模块容易,同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试,可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试,提高测试效率。因此,通常是把以上两种方式结合起来进行组装和测试。
               在进行集成测试时,测试者应当确定关键模块,对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一:
               . 满足某些软件需求;
               . 在程序的模块结构中位于较高的层次(高层控制模块);
               . 较复杂、较易发生错误;
               . 有明确定义的性能要求。
               在做回归测试时,也应该集中测试关键模块的功能。
               . 集成测试的组织和实施。
               集成测试是一种正规测试过程,必须精心计划,并与单元测试的完成时间协调起来。在制定测试计划时,应考虑如下因素:
               ①采用何种系统组装方法来进行集成测试。
               ②集成测试过程中连接各个模块的顺序。
               ③模块代码编制和测试进度是否与集成测试的顺序一致。
               ④测试过程中是否需要专门的硬件设备。
               解决了上述问题之后,就可以列出各个模块的编制、测试计划表,标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。
               在缺少软件测试所需要的硬件设备时,应检查该硬件的交付日期是否与集成测试计划一致。例如,若测试需要数字化仪和绘图仪,则相应的测试应安排在这些设备能够投入使用之时,并要为硬件的安装和交付使用保留一段时间,以留下时间余量。此外,在测试计划中需要考虑测试所需软件(驱动模块、桩模块、测试用例生成程序等)的准备情况。
               . 集成测试完成的标志。
               集成测试完成的标志主要有以下几项。
               ①成功地执行了测试计划中规定的所有集成测试。
               ②修正了所发现的错误。
               ③测试结果通过了专门小组的评审。
               集成测试应由专门的测试小组来进行,测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。
               在完成预定的集成测试工作之后,测试小组应负责对测试结果进行整理、分析,形成测试报告。测试报告中要记录实际的测试结果在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题,提供测试评审和最终决策,以提出处理意见。
               集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。
               确认测试
               确认测试的任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明中明确规定。确认测试一般包括有效性测试和软件配置复查,确认测试一般由独立的第三方测试机构进行。
               . 进行有效性测试。
               有效性测试是在模拟的环境下,运用黑盒测试的方法,验证所测软件是否满足需求规格说明书列出的需求。为此,需要制定测试计划、测试步骤以及具体的测试用例。通过实施预定的测试计划和测试步骤,确定软件的特性是否与需求相符,确保所有的软件功能需求都能得到满足,所有的软件性能需求都能达到。所有的文档都是正确且便于使用的。同时,对其他软件需求,例如可移植性、可靠性、易用性、兼容性、可维护性等,也都要进行测试,确认是否满足。
               在全部软件测试的测试用例运行完后,所有的测试结果可以分为两类。
               ①测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合,从而接受了这部分程序。
               ②测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致,因此要为它提交一份问题报告。
               . 软件配置复查。
               软件配置复查的目的是保证软件配置的所有成分都齐全,各方面的质量都符合要求,具有维护阶段所必须的细节,而且已经编排好分类的目录。
               在确认测试的过程中,还应当严格遵守用户手册和操作手册中规定的使用步骤,以便检查文档资料的完整性和正确性。
               系统测试
               系统测试是将通过集成测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起,在实际或者模拟运行(使用)环境下,对计算机系统进行一系列测试。
               系统测试的目的在于通过与系统的需求定义作比较,发现软件与系统定义不符合或与之矛盾的地方。
               验收测试
               验收测试是以用户为主的测试。软件开发人员和质量保证人员也应参加。由用户参加设计测试用例。使用用户界面输入测试数据,并分析测试的输出结果。一般使用生产中的实际数据进行测试。
               目前在国内实际软件开发,特别是系统集成的过程中,验收测试往往在系统测试完成后、项目最终交付前进行。验收测试的测试计划、测试方案与测试案例一般由开发方制定,由用户方与监理方联合进行评审。验收小组由开发方、用户方、监理方代表、主管单位领导及行业专家构成。与确认测试及系统测试不同的是,验收测试往往不是对系统的全覆盖测试,而是针对用户的核心业务流程进行的测试;同时,测试的执行人员也不是开发方的测试组成员,而是由用户方的使用人员完成。
               近年来,越来越多的开发方及用户方认识到对项目进行最终验收测试的重要意义,因此,由第三方完成的专业化全覆盖型技术测试得到了广泛应用。由专门从事测试工作的第三方机构,根据系统的需求分析、用户手册、培训手册等,在开发人员及最终使用人员的配合下,完成对系统全面的测试工作。
 
        配置管理
        如果应用程序提供了可配置的管理界面,要检查确保管理界面安全的方法。此外,还要检查如何确保敏感配置数据的安全。下表显示了常见的配置管理漏洞。
        
        常见的配置管理漏洞
        测试时考虑下列问题,帮助验证应用程序设计在配置管理方面的方法。
        . 是否支持远程管理。
        如果设计指定了远程管理,必须确保管理界面和配置存储的安全,因为这些操作本身非常敏感,而且通过管理界面访问的数据也很敏感。考虑与远程管理设计相关的下列问题。
        ①是否使用强身份验证。
        必须要求对所有管理界面用户进行身份验证。使用强身份验证,如Windows或客户端证书身份验证。
        ②是否加密网络通信数据。
        使用经过加密的信道,如IPSec或虚拟专用网络(VPN)连接提供的通道。不支持不安全通道中的远程管理。IPSec允许对可用来管理服务器的客户计算机的身份和数量进行限制。
        . 是否保证配置存储的安全。
        明确应用程序的配置存储,然后检查限制访问这些存储的方法,以及确保存储中数据安全的方法。
        ①配置存储是否在Web空间中。
        对于保存在Web空间文件中的配置数据,其安全性要低于保存在Web空间之外的数据。主机配置错误或未发现的Bug都可能导致攻击者通过HTTP检索,并下载配置文件。
        ②配置存储中的数据是否安全。
        确保在存储中加密关键的配置数据项(如数据库连接字符串、加密密钥和服务账户凭据)。
        ③如何限制对配置存储的访问。
        确保管理界面提供必要的授权,只有经过验证的管理员才可访问并操作这些数据。
        . 是否隔离管理员特权。
        如果管理界面支持不同的功能(如站点内容更新,服务账户重新配置和数据库连接详细信息),要确认管理界面支持基于角色的授权,从而区分内容开发人员和操作员或系统管理员。例如,不必许可更新静态Web站点的人改变客户的信用额度或重新配置数据库连接字符串。
 
        建设单位
        建设方是建设项目的主要投资者,有时也是项目的最终使用者,是在工程建设阶段的全权代表,建设项目的经济效益,如投资额度、工程质量、投入使用时间和使用寿命直接关系着建设方的切身利益。虽然承建方、监理方与建设方是平等的市场主体,但由于建设方是投资方,掌握着项目的最终资源——决定了其他方为从属地位,所以说建设方对工程项目管理起着主导性作用。建设方加强和改善对项目的管理是从根本上实现项目按质如期完成的最有效的途径之一。
        作为项目管理集体中的主要负责人,建设方的作用是阐明本项目的目标并确认各项工作的轻重缓急,组织协调参与各方为此目标而通力合作,在管理决策过程中做出决策。但在某些具体的项目管理事务中,建设方并不总是处于主要负责人的地位,还要作为裁判、支持者、服务员及督促员的角色。
 
        评审
        对设计部分是否完整地实现了需求中规定的功能、性能等要求,设计方法的可行性,关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等都一一进行评审。
 
        软件评审
        通常把"质量"理解为"用户满意程度"。为了使得用户满意,有以下两个必要条件。
        (1)设计的规格说明书符合用户的要求,这称为设计质量。
        (2)程序按照设计规格说明所规定的情况正确执行,这称为程序质量。
        设计质量评审的对象是在需求分析阶段产生的软件需求规格说明、数据需求规格说明,在软件概要设计阶段产生的软件概要设计说明书等。
        程序质量评审通常是从开发者的角度进行评审,与开发技术直接相关。它是着眼于软件本身的结构、与运行环境的接口以及变更带来的影响而进行的评审活动。
 
        信息系统建设
               信息系统的生命周期
               信息系统建设的内容主要包括设备采购、系统集成、软件开发和运维服务等。
               信息系统的生命周期可以分为四个阶段:立项、开发、运维和消亡。
                      立项阶段
                      立项阶段即概念阶段或需求阶段,这一阶段根据用户业务发展和经营管理的需要,提出建设信息系统的初步构想,然后对企业信息系统的需求进行深入调研和分析,形成《需求规格说明书》并确定立项。
                      开发阶段
                      以立项阶段所做的需求分析为基础进行总体规划,然后通过系统分析、系统设计、系统实施及系统验收等工作实现并交付系统。
                      .总体规划:系统开发的起始阶段,以立项阶段所做的需求分析为基础,明确信息系统在企业经营战略中的作用和地位,指导信息系统的开发,优化配置并利用各种资源,通过规划过程规范或完善用户单位的业务流程。一个比较完整的总体规划应当包括信息系统的开发目标、总体结构、组织结构、管理流程、实施计划、技术规范等。
                      .系统分析:为系统设计阶段提供系统的逻辑模型,内容包括组织结构及功能分析、业务流程分析、数据和数据流程分析及系统初步方案等。
                      .系统设计:根据系统分析的结果设计出信息系统的实施方案,主要内容包括系统架构设计、数据库设计、处理流程设计、功能模块设计、安全控制方案设计、代码设计等。
                      .系统实施:将设计阶段的成果在计算机和网络上具体实现,即将设计文本变成能在计算机上运行的软件系统。由于系统实施阶段是对以前全部工作的检验,因此用户的参与特别重要。
                      .系统验收:系统实施后经过试运行,就进入系统验收阶段,这也是系统交付的必经阶段。
                      运维阶段
                      信息系统通过验收,正式移交给用户以后进入运维阶段。系统的运行维护可分为更正性维护、适应性维护、完善性维护和预防性维护等类型。
                      .更正性维护:更正系统交付后发现的错误。
                      .适应性维护:使信息系统能在变化后或变化中的环境中继续使用。
                      .完善性维护:改进交付后系统的性能和可维护性。
                      .预防性维护:在信息系统中的潜在错误成为实际错误前进行更正。
                      消亡阶段
                      信息系统不可避免地会遇到更新改造、功能扩展,甚至废弃重建等情况,因此,在信息系统建设的初期就应注意系统消亡的条件和时机,以及由此花费的成本。
               信息系统开发方法
               信息系统常用的开发方法有结构化方法、原型法、面向对象方法等。
                      结构化方法
                      结构化方法是应用最为广泛的一种开发方法。按照信息系统生命周期,应用结构化系统开发方法,把整个系统的开发过程分为若干阶段,然后依次进行,前一阶段是后一阶段的工作依据,按顺序完成。
                      结构化方法具有如下特点:
                      .严格区分工作阶段,每个阶段有明确的任务和取得的成果。
                      .强调系统开发过程的整体性和全局性。
                      .系统开发过程工程化,文档资料标准化。
                      结构化方法的缺点有:
                      .开发周期长。
                      .文档、设计说明烦琐,工作效率低。
                      .要求在开发之初全面认识系统的需求,充分预料各种可能发生的变化,但这并不十分现实。
                      原型法
                      原型法在很难全面准确提出用户需求的情况下,本着对用户需求的初步理解,先快速开发一个原型系统,然后通过反复修改来实现用户的最终系统需求。
                      原型法的特点如下:
                      .对用户的需求动态响应,逐步纳入。
                      .系统分析、设计与实现都是随着对原型的不断修改而同时完成的,相互之间并无明显界限,也没有明确分工。
                      原型可以分为:
                      .抛弃型原型:此类原型在系统真正实现以后就放弃不用了。
                      .进化型原型:此类原型的构造从目标系统的一个或几个基本需求出发,通过修改和追加功能的过程逐渐丰富,演化成最终的系统。
                      面向对象方法
                      用对象表示客观事物,对象是一个严格模块化的实体,在系统开发中可被共享和重复利用,以达到复用的目的。面向对象方法的关键是利用面向对象的信息建模概念,建立一个全面、合理、统一的模型,既能反映需求对应的问题域,又能被计算机系统对应的求解域所接受。
                      面向对象方法的特点:
                      .开发过程的分析、设计和实现三个阶段使用同一套工具。
                      .分析、设计和实现三个阶段都是对面向对象的三种模型的建立、补充和验证,三个阶段的界限并不十分明确。
                      在系统开发实际工作中,往往根据需要将多种开发方法进行组合应用,以完成系统开发的全部任务。
 
        质量管理
        ISO将质量定义为:“质量是反映实体满足明确和隐含需要的能力的特性总和”。我国国家标准GB/T1900—2000将质量定义为:“质量是一组固有特性满足要求的程度”。这些定义表明质量是通过实体来体现的,质量的实体可以是产品,也可以是某项活动或过程的工作质量,还可以是质量管理体系运行的质量。
        ISO将质量管理定义为:“在质量方面指挥和控制组织的协调活动”。我国国家标准GB/T1900-2000对质量管理的定义是:“在质量方面指挥和控制组织的协调的活动”。在质量方面的指挥和控制活动,通常包括制定质量方针和质量目标以及质量策划、质量控制、质量保证和质量改进。
        我国国家标准GB/T1900—2000对质量保证的定义是:“质量保证是质量管理的一部分,致力于增强满足质量要求的能力”。也就是,质量保证是为了提供足够的信任表明实体能够满足质量要求,而在质量体系中实施并根据需要进行全部有计划和有系统的活动。
        我国国家标准GB/T 1900—2000对质量控制的定义是:“质量管理的一部分,致力于满足质量要求”。质量控制的目标就是确保产品的质量能满足顾客、法律法规等方面所提出的质量要求,如适用性、可靠性和安全性。质量控制的范围涉及产品质量形成全过程的各个环节,如设计过程、采购过程、生产过程和安装过程。
        项目质量管理是为了保证项目最终能够达到预期的质量目标而进行的一系列的管理过程。项目的质量管理可以分解为质量计划编制、质量保证与质量控制三个过程。
        (1)质量计划编制。是指确定与项目相关的质量标准,并决定如何达到这些质量标准。
        (2)质量保证。是定期评估总体项目绩效的活动之一,以树立项目能满足相关质量标准的信心。
        (3)质量控制。是指监控具体的项目结果以判断其是否符合相关的质量标准,并确定方法来消除绩效低下的原因。
        质量管理与项目管理是相辅相成的,例如质量管理和项目管理这两门学科都认识到以下几方面的重要性:
        (1)顾客的满意程度。强调对顾客的需求深刻理解、认真评估、准确定义和严格管理,以便与顾客的期望相符。这就要求既符合要求(项目交付的产品要与它宣布将交付的产品相符)又适于使用(交付的产品或服务要满足实际需求)。
        (2)预防胜于检查。强调预防比检查更重要。防患于未然的代价总是小于检查所发现错误的纠正代价。
        (3)管理层的责任。成功需要项目团队全体成员的参与,然而提供取得成功所需的资源却仍然是管理层的职责。
        (4)持续改进。计划、执行、检查和改进循环是质量改进的基础。执行组织采取的质量改进措施,不仅会改善项目管理的质量,而且也会改进项目产品的质量。
 
        质量控制
        质量控制是监督并记录质量活动执行结果,以便评估绩效,并推荐必要的变更过程,其主要作用包括:
        .识别过程低效或产品质量低劣的原因,建议并采取相应措施消除这些原因。
        .确认项目的可交付成果及工作满足主要干系人的既定需求,足以进行最终验收。
               输入
                      项目管理计划
                      项目管理计划中包含质量管理计划,用于控制质量。质量管理计划描述将如何在项目中开展质量控制。
                      质量测量指标
                      质量测量指标描述了项目或产品属性及其测量方式。质量测量指标的例子包括功能点、平均故障间隔时间(MTBF)和平均修复时间(MTTR)。
                      质量核对单
                      质量核对单是结构化清单,有助于核实项目工作及其可交付成果是否满足一系列要求。
                      工作绩效数据
                      工作绩效数据包括实际技术性能(与计划比较)、实际进度绩效(与计划比较)和实际成本绩效(与计划比较)。
                      批准的变更请求
                      实施整体变更控制过程中批准的变更请求,可包括各种修正,如缺陷补救、修订的工作方法和修订的进度计划。需要核实批准的变更是否已得到及时实施。
                      可交付成果
                      可交付成果是任何独特并可核实的产品、成果或能力,最终将成为项目所需的、确认的可交付成果。
                      项目文件
                      项目文件可能包括协议、质量审计报告和变更日志(附有纠正行动计划)、培训计划和效果评估、过程文档。
                      组织过程资产
                      可能影响质量控制过程的组织过程资产包括组织的质量标准和政策、标准化的工作指南、问题与缺陷报告程序及沟通政策。
               工具与技术
                      七种基本质量工具
                      七种基本质量工具包括因果图、流程图、核查图、帕累托图、直方图、控制图和散点图,如本章第1张图所示。
                      统计抽样
                      统抽样是指按照质量管理计划中的规定,抽取和测量样本。
                      检查
                      检查是指检验工作产品,以确定是否符合书面标准。检查的结果通常包括相关的测量数据。检查也可称为审查、同行审查、审计或巡检等。
                      审计已批准的变更请求
                      对所有已批准的变更请求进行审查,以核实它们是否已按批准的方式得到实施。
               输出
                      质量控制测量结果
                      质量控制测量结果是对质量控制活动结果的书面记录。应该以制订质量管理计划过程中所确定的格式加以记录。
                      确认的变更
                      对变更或补救过的对象进行检查,做出接受或拒绝的决定,并把决定通知干系人。被拒绝的对象可能需要返工。
                      核实的可交付成果
                      质量控制过程的一个目的就是确定可交付成果的正确性。核实的可交付成果是范围确认过程的一项输入,以便正式验收。
                      工作绩效信息
                      工作绩效信息是从各控制过程收集,并结合相关背景和跨领域关系进行整合分析而得到的绩效数据。
                      变更请求
                      如果推荐的纠正措施、预防措施或缺陷补救导致需要对项目管理计划进行变更,则应按既定的整体变更控制过程的要求,提出变更请求。
                      项目管理计划更新
                      项目管理计划中可能需要更新的内容包括质量管理计划和过程改进计划。
                      项目文件更新
                      可能需要更新的项目文件包括质量标准、协议、质量审计报告和变更日志(附有纠正行动计划)、培训计划和效果评估、过程文档。
                      组织过程资产更新
                      可能需要更新的组织过程资产包括完成的核对单和经验教训文档。



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

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