以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx

上传人:b****2 文档编号:1465362 上传时间:2023-04-30 格式:DOCX 页数:20 大小:323.08KB
下载 相关 举报
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第1页
第1页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第2页
第2页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第3页
第3页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第4页
第4页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第5页
第5页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第6页
第6页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第7页
第7页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第8页
第8页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第9页
第9页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第10页
第10页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第11页
第11页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第12页
第12页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第13页
第13页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第14页
第14页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第15页
第15页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第16页
第16页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第17页
第17页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第18页
第18页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第19页
第19页 / 共20页
以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx_第20页
第20页 / 共20页
亲,该文档总共20页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx

《以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx(20页珍藏版)》请在冰点文库上搜索。

以持续验证为核心的全程协同监理模式探究刘文志1221Word文档下载推荐.docx

(4)协调管理难度大:

信息产品成失败的信息工程90%是由于业主和承包商的沟通造成的,因为双方的沟通语言是不一致的;

开发人员重视代码,忽视设计,缺乏高层次上的抽象能力,直接导致开发人员之间的沟通也只能在代码一层有共同点,影响了所开发的正确性和规模。

(5)工程后期维护复杂,要通过较长时间的实际使用后才被得到真正的认可。

(6)信息不对称作为一种常态出现:

从信息系统工程的委托方和承包方的角度看,前者对信息技术大多不了解,而后者可能对前者的需求和业务不了解;

从承包方内部来看,每一个开发流程的输入方和接受方的都存在信息的不对称的情况;

使用者对信息系统工程的内部构成和实质性的信息绝大多数一无所知,而这一切可能连备查的记录都没有。

(7)不同于一般建设项目,信息系统工程的实施包含了信息系统工程的设计这个环节,设计和实施不是相互独立的环节;

实施者同时是设计者;

设计环节与实施环节会出现同时进行的情景。

信息系统工程的设计、施工、系统集成和开发是密不可分的。

1.3软件工程监理的问题

我国的软件工程监理还处于起步阶段,虽然有了一定的发展、取得了一定的成绩,但也暴露出了很多问题,主要有:

(1)软件工程监理的依据缺乏。

虽然我国重视软件工程监理工作,也出台了相应的政策、法规和相关监理工程规范,但是这些规范仅仅是实施软件工程监理的框架参考。

软件工程是一个技术含量高的系统工程,软件开发可以说还停留在一个手工工艺生产的过程,软件的质量在很大程度上还依赖于开发人员的水平,且软件开发的技术、平台多种多样,在软件工程实施过程中缺乏系统建设的详细规范和标准,软件工程监理人员在实施质量控制方面缺乏依据。

(2)软件工程监理人才队伍尚不完善。

软件系统建设的实际情况较为复杂,技术更新快,标准规范常常滞后,如何坚持按软件工程的思想对项目进行有力的控制,需要监理人员有很高的创新性。

而由于软件工程监理是一个新发展行业,在我国比较缺乏具有丰富实施软件工程监理的监理工程师。

同时在软件工程监理的实施方面,也缺乏比较成功的软件工程监理案例,专业从事软件工程监理的单位不多,目前国内具有软件监理资产的单位,主要是从软件质量测试和评测起家,在软件质量测试和评测方面积累了一定的经验,但是在实施全过程监理方面尚存在明显不足。

(3)“四控三管一协调"

的理论不太适合软件工程监理。

软件工程监理忽视了软件工程和建筑工程有巨大的差别,缺乏对软件工程本身特点的了解和掌握。

“四控三管一协调”是在建筑工程监理基础上提出的,实践证明应用在软件工程监理中并不完全适合。

(4)不重视对软件工程风险和需求的控制管理。

信息工程技术含量高,建设周期长,投资规模大,建设风险加大,对项目风险和需求的控制更加重要。

现行的监理方法却忽视了对风险和需求的控制,有很多项目失败,很多项目投资超出预计。

针对上述的问题,软件工程监理迫切需要寻求一种科学有效的措施来解决。

经过仔细地分析软件工程本身的特点,引入一种先进的、有效的、适用的理论,理清软件工程监理工作中的重点和难点,建立一种新型的软件工程监理模式,显然是解决软件工程监理存在问题的途径。

2.传统软件工程监理模式介绍

软件项目参与各方包括业主方、开发方和监理方,根据信息经济学“委托人一代理人”理论,业主方处于信息不对称地位,故需聘请监理方来约束开发方。

传统的“四控三管一协调”监理模式主要包括两种:

委托型监理模式和顾问型监理模式。

2.1委托型监理模式

委托型项目监理是由业主委托监理单位负责软件工程项目全过程的监理工作,如图2.1所示。

监理单位根据软件项目的特点和规模,由监理总负责人(简称总监)主持全面监理工作,领导项目监理班子承担成本控制、进度控制、质量控制、变更控制、合同管理、信息管理、安全管理和组织协调沟通等工作,根据监理合同的授权范围,由总监向承建单位发布指令,并定期向业主提供监理情况报告。

图2.1委托型监理模式框架

委托型监理提供的是一种“全程”监理服务,全面负责监理“四控、三管、一协调”的全面工作,具有决策权和指挥权,直接代表建设单位向承建单位发布指令,定期向项目建设单位汇报工程建设情况,权力大,责任也大,对工程实施的成败承担主要责任。

2.2顾问型监理模式

顾问型项目监理组织模式是由业主聘请总监组建项目监理的顾问班子,监理顾问班子对业务负责,为业务提供软件工程项目的咨询服务,包括对成本控制、进度控制、质量控制、变更控制、合同管理、信息管理、安全管理和组织协调沟通等出谋划策,但对软件工程项目过程不具有决策权和指挥权。

软件工程项目过程由业主参考监理顾问的咨询信息自行负责监督。

顾问型监理提供的主要是一种咨询服务,在监理活动过程中,协助建设单位收集项目资料、进度等信息,结合监理单位本身的经验和方法,提出项目管理的建议。

顾问型监理主要承担的是一种“谋生”的角色,其性质本身并不参与到项目的管理和控制,在项目执行过程中不进行决策和指挥,仅对建设单位提出建议,当然也不承担项目实施质量的责任。

2.3两种传统软件工程监理模式在实施中存在的问题

1.委托型监理模式存在的问题:

(1)变更比较频繁,尤其是需求变更多,采用传统的监理模式,监理工程师很难针对频繁的变更进行灵活处理和应对。

软件工程也和传统的建筑工程一样,是从需求分析、设计、编码、测试、运行维护逐个阶段完成,是一种类似与甘特图布局的阶段化流程,是基于所有的错误都发生在编码阶段这一理想的假设。

而实际上,软件开发工作知识高度密集,开发过程复杂多变,多年的实践经验表明,软件开发的需求分析、设计、编码、测试等活动之间并非完全是自上而下,呈线性图式,每个活动之间都是不断反馈和优化的循环过程,因此在软件开发过程中,经常发生变更,尤其是需求变更会导致设计、编码的变更,对整个工程的进度有直接影响。

(2)缺乏质量技术标准,无法对工程质量进行量的衡量。

合同和技术标准是监理单位进行质量确认的重要依据,而技术标准针对软件工程监理方面只是一个原则上的框架指导,缺乏可操作的指导性文件,技术标准的严重滞后也成为软件工程监理机制全面引入的瓶颈。

(3)缺乏监理经验丰富的专业工程师,监理人员的水平尚停留在软件测试和评测阶段。

目前从事软件工程监理的人员多数是原来从事软件开发和系统集成的计算机技术人员,他们虽然具有丰富的软件开发和集成经验,但是在监理方面缺乏专业管理知识和监理工作经验,在实际的监理工作中,监理工作人员主要依赖自己的计算机技术和开发经验,借助一些测试管理工具,对开发单位提交的软件进行测试和评价。

工作仍然停留在“技术层面”,在项目的管理和控制方面,在监理工作的实施方面明显经验不足。

“人才队伍”的匮乏成为实施软件工程监理最大的桎梏。

2.顾问型监理模式存在的问题:

(1)需要建设单位具有较强的技术力量,一般适合于规模较小的软件工程。

(2)项目的组织和建设还是一种业主和承建单位的二元组织机制,监理方作为业主的“军师”,为业主出谋划策,与社会化专业化分工的趋势相违背,与国家有关实施监理的规定有冲突。

综上所述,委托型监理作为一种通用的监理模式,在建设工程中得到了普遍应用,并取得了良好的效果。

但是由于软件工程特有的变更性强、可检查性差,软件监理行业刚刚起步不规范、软件监理人才队伍不完善等多种原因,委托型监理模式在软件工程监理的实施过程中,碰到了许多具体的问题,在监理效果上离实施监理工作的预期管理目标相差甚远。

顾问型监理模式操作性强,但是其提供的主要是一种咨询服务,在软件工程监理的适用范围比较窄。

因此在目前软件工程监理法规尚待完善,相关技术标准严重滞后信息技术发展,监理人才队伍严重缺乏的大环境下,探索一种合理、高效的监理模式,对软件工程监理的全面实施具有较大的指导意义。

3.以持续验证为核心的全程协同监理模式提出

通过对传统监理模式分析,我们可以发现:

采用委托型监理模式,业主将监理工作委托给监理方,由监理方全面负责软件工程“四控、三管、一协调”的监理活动,业主不直接介入日常监理活动,重点处理宏观方面的协调,使得职责清晰明确。

但是委托型监理缺乏对微观方面的掌控,不能适应软件工程变更频繁的固有要求;

采用顾问型监理模式,业主全面负责软件工程“四控、三管、一协调”的监理活动,能够充分、直接地控制工程建设的宏观方面和微观方面,但是项目管理人员投入大,要求高,在软件开发的质量控制等专业技术方面,不能充分发挥专业监理人员的作用,又容易出现形式监理等不规范的现象。

在对两种传统监理模式研究分析的基础上,从软件工程监理的体系、模型、方法三方面,我们提出了由监理方主导,业主和承建单位参与的以持续验证为核心的全程协同监理模式。

3.1全程协同监理体系

全程系统监理体系大体由四部分组成,如图3.3所示。

图3.3全程协同监理体系结构图

3.1.1监理单位

监理单位是软件工程监理的实体,项目监理和咨询服务的提供者。

监理单位是指具有法人资格,具备监理职能的信息系统工程项目监理公司、监理事务所及兼承监理业务的软件咨询单位。

监理单位的任务是接受用户的委托和授权,向用户提供技术和管理服务,通过一定的组织与管理,对软件项目的投资、进度和质量三大目标进行控制,以确保用户单位开发软件的预期目标。

3.1.2监理组织结构

监理组织结构包括监理单位如何构建监理组织,如何组织监理工程师进行有效的监理工作。

进行软件工程项目的监理,首先应当完成的是监理单位的组织工作。

监理工程师和各级的监理人员不是分散单独工作的,而是通过一定的组织来完成监理任务的。

1.建立监理组织。

(1)明确监理任务,列出各级监理目标明确监理任务,是制定各级监理目标以及制订监理工作考核标准的前提。

而各级监理目标的确定,又是监理任务顺利完成的方法和手段。

(2)监理工作内容的合并为提高监理工作效率,便于管理监理工作和内容,需要适当细化合并监理目标。

合并时主要考虑的因素有:

项目的规模、性质、工期、具体内容,监理单位的人员数量、业务水平,承包方可能的项目组织、计划等。

(3)组织结构设计按照监理组织设计原则,合理确定项目监理组织结构形式。

(4)制订规章制度及考核标准为了使监理工作科学、规范的进行,还应制订监理部门和监理人员的岗位职责标准、监理工作流程和监理信息流程等有关规章制度。

监理人员岗位职责标准应规定各类监理人员的工作职责和考核标准与时间。

2.监理组织的人员配备。

监理组织的人员由总监理工程师、专业监理工程师、监理员、专业测试工程师和综合保障人员所组成。

项目监理组应由与监理项目的性质及对项目监理的要求相适应的专业人员组成。

项目监理组织人员数量主要是依据项目的性质、规模以及监理人员的业务范围和业务水平来确定的。

一般来说,项目复杂程度越大,工期要求越短,监理人员的业务水平越低,要求投入的监理人员就越多。

但也不是说,投入的监理人员越多越好。

监理人员数量投入过多,会增加监理费用的支出,严重的还会降低组织的监理效率。

综合保障人员负责项目监理小组的后勤保障、文档管理及日常事务处理等工作。

因此,监理单位应根据项目和自身的实际情况制定出合理的人员结构和数量。

3.监理组织中各类人员的职责。

监理人员在项目实施监理过程中承担的职责,应在监理组织设计过程中明确规定。

各类监理人员也必须掌握在监理组织及监理合同条款规定的范围内应有的职责权限,严格按照规定的各项工作内容执行。

3.1.3监理方案

监理方案是指导监理工程师监理活动的指令性文件,监理方案编制的好坏直接影响监理工作的成败。

监理方案的有关文件包括监理大纲、监理规划和监理细则三个,它们组成相互联系的整体,都是由监理单位编制的、为监理工作服务的监理文件。

监理大纲是监理单位为承揽监理业务而编制的方案性文件,它是监理单位投标书的重要组成部分。

监理大纲通常要包括的内容有:

监理单位的资质介绍、主要监理人员和资质情况介绍,拟采用的监理方案(监理组织方案、各目标控制方案等)。

监理规划是监理单位与用户单位签订监理委托合同之后而编制的指导项目监理部开展监理工作的技术组织文件。

从内容上讲,监理大纲是监理规划编写的直接依据,监理规划的内容比监理大纲要全面详细,更具指导项目监理工作的实际意义。

监理细则则根据监理规划要求及项目具体内容和监理工作开展的需要,编写。

监理细则是由专业监理工程师根据本专业技术要求,在监理规划的基础上,针对所承担的具体监理任务,结合自身具体情况(人员数量和质量等情况)和项目环境、特点编制的具有可操作性的专业性监理文件。

3.1.4监理内容

软件工程监理的目标是:

质量好、进度快、投资少。

监理的工作内容主要围绕软件工程项目的质量、进度、投资三方面展开。

监理工程师在招标期、建设期、运维期三个不同阶段,针对质量、进度、投资的目标,开展以持续验证为核心的全程协同监理工作。

1.质量方面

质量是项目建设的核心,也是进度和资金控制的基础和前提。

所以“四控三管一协调”中把质量放在了首位。

软件项目监理中质量方面主要包括:

承建单位的资质评审;

持续地项目设计方案评审;

持续地项目实施方案评审:

对软硬件产品及服务进行验收;

持续地对项目的实施和变更进行监控;

处理项目中出现的质量问题;

持续地参与并监督项目的测试、试运行和验收;

持续地对项目的运行、维护以及售后的服务进行监理。

2.进度方面

进度方面主要是通过项目管理的一系列方法,对项目各个阶段进度计划进行审核、使项目实施阶段的进度按照预定的计划进行。

进度是系统进展情况的反应,它贯穿于项目建设的整个生命周期中,进度不仅是一个时间概念,还包括任务、时间、成本等因素,只有全方位地考查进度才不至于顾此失彼,既保证预定时间,又能使项目保质保量完成。

时间、成本、质量是项目成功的基本要素,而这三者之间相互矛盾,不可能使三个控制目标同时达到最优。

提高质量意味着投资增加或者延长进度,压缩进度就会出现盲目赶工,势必影响成本与质量。

因此,合理的进度计划对于控制成本和质量,以及对项目的成败起着至关重要的作用也具有十分重要的意义。

监理人员主要是对进度管理的全过程进行持续的动态监控,包括审查进度计划的合理性、可行性,进度进程的完成情况,以及进度的调整与改进对策等。

3.投资方面

投资方面主要工作是成本控制,通过核实设备价格、审查决策阶段投资概算、审查工程设计阶段投资预算、招标阶段投资控制、施工阶段工程计量与投资动态跟踪控制、审核工程变更的投资以及索赔、验收阶段工程决算审核等来控制整个工程建设过程中的资金、资源等的使用。

软件工程监理应当站在项目全生命周期的高度为系统的建设提出综合决策建议,不仅要考虑项目的建设过程,还要有长远的眼光,要预见到项目运行维护过程中的成本投入。

3.2全程协同监理模型

全程协同监理模型以持续验证为核心,对项目招标期、建设期、运维期三个阶段进行全系产品、全生命周期、全面质量控制手段的协同监管。

3.2.1招标期

在业主决策建设系统后,应根据自身的信息技术水平,与监理单位签订监理合同。

应在确定项目承建方之前,首先选择确定监理方,让监理方从项目的开始就介入,这样有利于分析项目建设中涉及的各种关键要素,有利于纠正项目建设前、中、后期计划的不足,有利于项目建设的规范化,从而确保项目建设的顺利进行,成功实现企业信息化的目标。

业主与监理方进行项目需求的交流,让监理方了解业主的项目需求。

监理方据此对系统利用自己的技术、经济、管理、法律、社会等各方面的人才,进行专业化的、全面的可行性分析,提出可行性报告,并制定初步的软件监理计划。

配合业主进行招投标的工作,确定承建方。

在选择承建方时,监理方不仅要评判承建方在该项目投标书中的技术实力,还要考虑投标单位的资质背景等信息,及是否有过类似项目的开发经验以及过去项目的客户反馈等非技术方面。

3.2.2建设期

项目启动过程的监理。

项目启动阶段的监理内容,主要是召开项目启动会议;

对承建方提交的项目组成人员、项目实施方案与实施计划进行审核;

现场检查开发环境和工具的配置情况,包括:

项目管理工具和系统分析与设计工具,以及协同工作所需要的网络环境、通信软件等等。

项目需求过程的监理。

监理方在需求分析阶段,要督促业主安排需求调查联络人,提出详细、合理的要求。

监理方应全程跟进,三方协同,深入详细地了解和挖掘业主的需求,当业主和承建方由于知识背景不同而在访谈过程中沟通不顺畅的时候,监理方应利用自身优势使得双方顺利沟通,监督确认承建方按照约定的规范编写需求分析文档,并协同组织有关各方进行阶段评审。

项目概要设计过程的监理。

监理方主要对承建方是否根据《用户需求规格说明书》,采用结构化设计或面向对象设计规范,对系统体系架构的设计、功能模块和业务逻辑的划分、数据库逻辑和物理设计(包括表结构、表间关联、存储模式、视图、触发器和存储过程等)、对象类和对象接口设计(过程和函数接口设计)、权限分配机制、界面设计等工作进行监督,对生成的设计图表和文档进行审核,确定项目概要设计文档的完整性和可操作性,并协同组织有关各方进行阶段评审。

项目详细设计过程的监理。

详细设计过程的直接目标是编写详细设计说明书,监理方在此阶段主要是在进度上进行控制,主要手段是定期与承建方沟通,检查文档,确认每个模块的算法,用工具表达算法的过程,写出模块的详细过程性描述,确认每一模块的数据结构和模块接口细节,提交详细设计说明书的确认报告,并协同组织有关各方进行阶段评审。

项目编码过程的监理。

编码是将详细设计阶段的设计用计算机语言实现的过程。

监理方应从采用的程序设计原则来进行编码工作的监理,如在结构程序设计中,使用顺序、选择、循环等三种基本控制结构表示程序逻辑,程序结构只准许有一个人口和一个出口等;

深入对单元模块的编写、具有特殊要求的过程和函数的实现算法等进行代码审查监理,重点控制好开发进度、代码优化、编码说明和程序注释等,并协同组织有关各方进行阶段评审。

项目测试过程的监理。

测试一般包括:

单元调试、综合测试、确认测试和系统测试。

监理方应依据测试原则对承建方的测试进行监督,审核开发方的测试计划和测试用例,定期检查测试记录。

同时监理方也根据项目实际情况制定自身的测试计划和测试用例,对承建方提交的成果进行阶段验证和验收。

监理方根据测试结果估算错误数,确认符合约定,并协同组织有关各方进行阶段评审。

项目验收上线过程的监理。

监理方首先要审核上线运行方案,并根据方案,进行进度控制。

并跟进到各部门收集反馈意见,提出意见后,监理方要跟进检查改进情况,最后,还要审核竣工文档资料的完整性、可读性及其与工程实际的一致性,并审核操作系统、应用系统等软件配置与设计方案的符合性,检测验证系统功能性能与合同的符合性。

3.2.3运维期

项目运维过程的监理。

监理方在这个阶段的主要工作有:

检查人员培训计划落实情况;

帮助用户制定系统运行管理规章制度;

在保修期内定期或不定期对项目进行质量检查、督促承建方按合同要求进行维护。

针对用户的增量需求,进一步开展增量开发的全程协同监管,进行持续的验证。

3.2.4模型框架图

以持续验证为核心的全程协同监理模型框架图参见图3.2.3。

图3.2.4以持续验证为核心的全程协同监管模型

3.3全程协同监理方法

软件工程监理内容主要是围绕质量、进度、投资三方面。

监理工程师为了保障软件工程项目在质量、进度、投资三方面达到预期的目标,将持续验证的思想贯穿于全程协同监理全过程,从质量保障、进度保障、投资保障三方面明确定义了持续验证的全程协同监理方法。

3.3.1质量保障方法

1.持续评审

评审是对系统元素或者项目状态的一种评估手段,以确定其是否与计划的目标保持一致,并使其得到改进。

持续评审是全程协同监理模式中质量控制的重要措施,可分为需求评审、总体设计评审、详细设计评审、试运行评审等。

评审活动的输入,即评审对象,可以是承建单位的阶段性工作成果也可以是某个项目工作模块。

比如《项目实施计划》、《需求分析报告》、《概要设计》、《用户手册》、《验收方案》等阶段性且直接关系项目质量的文档,以及试运行的软件产品等都属于前者。

而软件测试工作的安排、系统试运行以及项目管理的组织工作等则属于后者。

评审的依据主要有:

·

国家和行业的相关标准、技术规范及其它有关规定。

有关部门对本项目的文件和批示。

己经确定的本方案的承前性文件。

监理工程师搜集到的监理信息。

监理方的评审一般由总监理工程师组织,监理工程师、有关专家和业主方代表参加,必要时可要求承建单位技术负责人现场答辩。

输出则是《评审会议纪要》和《监理意见》。

后者用于正式向承建单位提出评审中发现的问题,并要求其改正。

2.持续测试

测试是软件工程质量控制重要的手段之一。

在整个质量控制过程中,可能存在着业主、承包单位、监理单位对工程进行的各种形式的持续测试,其中承建单位的测试是为了保证工程质量和进度,业主的测试主要是验证系统是否满足业务需求,监理单位的持续测试是检查和确认工程质量。

监理参与进行的测试活动有以下三种:

持续监督评审承建单位的测试计划、测试方案、测试实施以及测试结果。

督促承建单位建立项目测试体系,成立独立的测试小组。

督促承建单位制定全过程的持续的测试计划,从项目

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 总结汇报 > 学习总结

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2