仓储运输安装调试方案Word文件下载.docx

仓储运输安装调试方案Word文件下载.docx

《仓储运输安装调试方案Word文件下载.docx》由会员分享，可在线阅读，更多相关《仓储运输安装调试方案Word文件下载.docx（23页珍藏版）》请在冰豆网上搜索。

每位项目副经理都必须考虑在合适的技术和组织选择方面分配其预算。

每三个月要求每位项目副经理向成本管理员提供一份包含如下内容的预测报告：

完成工作所需的资源；

未付费用/采购费。

然后，成本管理员会更新预测的工作预算。

在超支的情况下，项目副经理必须向项目管理小组提供一份恢复计划。

为了满足用户的进度的要求，进度要求的满足将优先成本方面的考虑，即将不计较成本，首先满足进度要求。

需求与配置管理

需求管理

需求管理是开发综合监控系统软件，完成综合监控系统工程的一个主要的组成部分。

下面几节的目的在于提供已经定义好的特别是软件功能需求方面的一般规则，并描述组织结构情况以便具备一个有效的需求管理系统。

一般规则

DOORS套装软件是一套公认的软件包，它用于管理复杂系统的需求并且已经被北京和利时公司采用。

北京和利时公司已经开发了一个应用层并将其与DOORS集成在一起，并在深圳地铁2号线和深圳地铁4号线成功应用此需求管理软件。

为了用一种精确、有效的方法跟踪本合同的要求，北京和利时公司已经决定在整个十四号线项目期间使用DOORS软件包作为需求管理工具。

一般过程

一般过程如下所述：

将用户所有的技术要求输入到DOORS；

将系统需求规范（SRS）的系统要求输入到DOORS模块中去；

将详细的接口规范（DIS）的要求输入到DOORS模块中去；

将上述SRS和DIS中包含的需求分配给DOORS模块中被称作系统设计规范（SDS）的工作分解项，该项列在工作分解结构中。

这些配置项目，既包含硬件配置项（HWCI）又包含软件配置项目（CSCI）；

根据系统需求以及SRS和DIS中规定的要求，将DOORS模块中的CSCI和HWCI撰写为软件需求规范（SWRS）和硬件需求规范（HWRS）；

将CSCI和HWCI的要求分配给工作分解结构DOORS模块中被称作软件设计规范（SWDS）和硬件设计规范（HWDS）的配置项目；

给对应于上述细分结构的不同层次的测试定义集成、验证和确认（IVV）模块；

对于变化跟踪来说，无论是出于什么原因（用户、设计约束、技术最优化的建议）引起的所有的技术变化都由工程变更控制系统管理。

需求管理组织

由于需求管理系统专门用于技术需求，因此它由系统工程经理和系统与集成小组负责。

DOORS工具的管理由系统配置工程师执行。

系统配置管理

配置管理计划中规定了整个项目期间都要遵循的与系统配置管理有关的规则。

当项目管理计划和配置管理计划之间发生冲突时，将按照下面的优先次序执行：

项目管理计划；

配置管理计划。

为了可以根据清晰设计而开发系统，及为了拥有一套一致的文件和DOORS模块，将定期更正系统基准。

在整个项目期间，该过程都会进行。

配置控制委员会（CCB）将负责在整个项目周期中定义各种基准。

系统配置工程师将负责跟踪并监督将投入使用的基准系统。

将遵循的一般规则如下所示：

在给定的参考系中，系统基准与一套基准的DOORS模块对应；

对应于给定基准的文件将储存在DOORS模块中；

将有两类基准：

♦正式基准：

它们对应一套模块包括基准和正式提交给用户的基准；

♦非正式基准：

它们对应一套于DOORS模块的基准，但未包含在正式提交给用户的基准。

无论是什么原因要求变更文件，都必须向负责确认并决定何时执行变更的CCB提交一份变更建议：

在CCB做出正式决定之前，任何人都不能擅自变更作为基准的模块；

当CCB做出执行变更的决定时，变更及其相关影响将输入到DOORS中去。

进行变更后，所有修改过的文件都必须进行基准变更，并且系统基准也必须进行相应地变动；

正式文件基准按照文件的修订版进行命名；

非正式文件基准按照正式最新的修订版参考号并后加一个字母命名；

正式系统基准的名称由字母“S”后接1~99的数字构成；

非正式系统基准由字母“S”后接1~99的数字以及一个小写字母构成；

为了检查是否正确执行了变更情况，必须使用一个跟踪系统。

这种监督工作由系统配置工程师负责；

在项目的任何阶段，任何活动都必须按照目前批准的系统基准进行。

软件配置管理

软件配置管理计划中规定了软件配置管理的规则和程序。

在配置管理计划和软件配置管理计划发生冲突时，将按照下面的优先顺序执行：

配置管理计划；

软件配置管理计划。

复查、汇报、会议及审核

除了设计联络会，将执行下面的复查、汇报、会议和审核：

内部月进度审查会

项目经理每月通过月项目审查会向项目管理部主管汇报工作。

每位项目副经理都必须在审查会之前至少一周向项目经理提供与其工作有关的信息以便进行汇总。

成本管理员负责将各种报告汇总到审查会报告中去，以便项目经理在审查会前进行分析。

成本管理员负责组织这些会议并通知相关的与会人员。

内部季度预算审查会

项目经理通过季度预算审查会每年向项目管理部主管和成本管理员汇报4次工作。

每位项目副经理在季度预算审查会前至少3周向项目经理提供与其工作有关的预算信息用于信息汇总。

成本管理员负责将各种数据汇总到项目季度预算审查会中去，以便项目经理在季度预算审查会前进行分析。

成本管理员负责组织这些会议并通知相关与会人员。

内部进度会

北京和利时公司每周将各举行一次公司内部进度会。

所有的项目副经理都必须参加。

对于某些会议来说，可能会邀请额外的项目小组成员参加。

这些会议将在每周一下午4点举行。

如遇公共假期，则会议自动顺延至第二天的同一时间举行。

如遇特殊情况，会议可以延期举行。

项目月进度会

北京和利时公司每月举行月进度会，该会议是北京和利时公司基于项目管理层面，项目副经理也参加会议。

对于某些会议，可能会邀请额外的项目小组成员参加。

这些会议由项目经理组织并主持。

对于相关的每月进度报告：

将在每月5号提交；

每位项目副经理都必须填写部分与其工作范围相关的报告；

秘书负责组织收集各种报告并将其编入每月进度报告。

必须在每月5号前至少两天将报告草案提交给项目经理审阅。

阶段性审查

在项目施工期间，在每个重要阶段结束时都要进行内部审查，内容包括：

系统设计审查（SDR）：

目的是审查详细接口规范（DIS）、系统需求规范（SRS）、系统设计规范（SDS，包括SWDS和HWDS）以及接口需求规范（IRS）；

部件设计复查（CDR）：

目的是检查各子系统和系统组成部分的设计文件是否适合生产；

系统测试准备就绪复查（STRR）：

目的是检查与系统测试相关的文件是否允许在工厂进行系统测试以及在现场以一种控制方式进行系统测试。

配置审核

配置审核可以用来验证系统和配置项目与其基准是否相符。

质量系统管理审查和预防性措施

北京和利时公司将审查本项目中执行的质量系统的适宜性和有效性。

由计划经理准备预防性措施分析报告以分析内部审核、用户审核和日常操作中发现的非一致性问题。

然后将在每年至少举行一次的质量系统的管理复查会上审阅预防性措施分析报告。

质量系统的管理复查会将由项目管理部主管主持，与会人员包括质量工程师、系统工程经理以及由会议主席确定的其他特别与会人员。

流程包括：

配置管理流程；

质量系统改进和控制流程；

质量保证流程；

预防性措施流程。

协调与沟通

项目信息的沟通在综合监控系统项目内显得非常重要，不仅是在团队内部各职能小组之间需要进行及时的沟通联络，同时该项目的一个突出特点已经决定了该项目需要大量的接口协调工作，即北京和利时公司需要同若干个项目组织之间建立通畅的信息沟通渠道和高效信息沟通流程，这对于保证综合监控系统项目的顺利进行和高质量的完成都具有重要的意义。

该项目管理将重点关注项目的沟通管理，将配合业主和监理建立一套基于该项目各相关组织之间的沟通计划。

北京地铁十四号线综合监控系统项目将需要与以下各方进行强有力的协调与频繁联络：

北京地铁公司（包含ISCS业主及其它专业业主）；

工程监理；

设计院；

土建承包商；

安装承包商；

其他的接口系统/设备供应商。

为了有效实现这种协调，在设计和开发阶段，工作人员将在北京工作，在现场安装/接口/测试阶段以及保修期内其工作人员将在北京工作。

协调活动包括两类：

接口设计；

现场协调。

接口设计计划

对于顺利完成像北京地铁十四号线综合监控系统这样的工程，接口管理是一个非常重要的问题。

对于项目开发来说，接口管理活动是主要的信息来源之一，并且在整个工程期间它都需要与其他各方进行强有力的协调。

本接口管理计划（IMP）定义了用来开发ISCS和接口系统之间详细接口要求的管理过程。

本计划的目的是为无缝集成提供方便，使其符合ISCS用户需求以及接口设备规范。

此外，IMP将提出北京和利时公司与接口承包商用来定义两个系统间接口的详细要求的过程。

接口管理将在接口文件中提出下面的属性：

电气、机械、软件协议以及功能数据接口；

检查、测试和试运行。

文件也将定义进行资源管理、文件变动控制、北京和利时公司和接口承包商之间沟通以及冲突解决所需的过程。

接口设计

详细的接口设计参见《B2-2综合监控专用技术册（下）》中的论述。

沟通与交流

接口会议

接口会议的工作范围如下所示：

了解各方的设计要求，开发并协商通过设计和接口要求以满足北京地铁合同中所规定的要求；

确定影响接口设计的关键性能参数和问题；

确定设计阶段、安装阶段以及试运行阶段的测试要求细节；

按照每个合同中的总规划协商通过设计和测试程序；

协商提交给北京地铁的接口文件。

接口会议的时间及地点安排将由接口双方协商。

我们建议在北京举行接口会议。

承包商之间的信息交流

承包商之间通过图纸和说明性文件这两种方法进行信息交流。

可以在接口会议期间或者通过正式公文交流信息。

通过图纸交流的信息包括结构图、机械详图、电器详图、接口电路图、接线图等等。

说明性文件用来描述程序、系统特点、电器特点、测试要求以及会议记录，包括行动表。

双方利用电子邮件、传真或电话经常保持沟通以明确设计和所有后勤安排的细节。

达成的协议将在接口会议后形成会议纪要或正式的可发布文件。

需要业主的支持

双方在接口会议期间通过正式文件解决问题。

当确认问题需要北京地铁介入时，双方或者在接口会议的纪要中或者通过书面通知业主。

当无法就关键问题达成协议或者对各方合同中的特殊需求或接口规范要求的解释持不同意见时，将立刻以书面形式向业主发出仲裁和确认请求。

业主出席会议将加速问题的解决。

接口文件

将为每位接口承包商准备下列文件：

详细的接口规范（DIS）

文件的目的

目的是规定并描述与ISCS和接口系统间接口相关的所有信息；

由于在系统设计阶段不可能获取所有的信息，本文件将在项目进行期间不断进行修正。

文件管理和提交

DIS是一种ISCS文件，由北京和利时公司制作和管理。

在向业主发布前，将由接口承包商复查本文件。

我们建议与其他的接口承包商正式签署DIS文件；

接口承包商也可以将DIS用于自己的接口文件。

我们建议使用没有改动过的文件，并且建议加上一个封皮，使接口承包商文件在参考上与接口承包商规范保持一致；

两个封面的重叠将表明文件修订版是如何与双方的合同保持同步的。

典型的文件格式见表31

表31典型文件格式

组成部分

内容

1.目的

本部分应叙述有关的接口及两个合同参考

2.参考文件

本部分将涉及ISCS规范的相关部分和附录。

本部分也包括参考标准或其他的应用文献。

3.术语表

任何使用过的首字母缩写词的含义。

解释相关或必要的词汇或技术用语。

4.接口规范

4.1接口图

接口图中指出了工作范围和责任范围。

4.2物理接口

4.2.1特性和位置

一张表表明每个接口的特性和准确位置。

位置可能是车站、车辆段、OCC（控制中心）或一座辅助建筑物内的一个房间。

4.2.2电气描述

本部分包括一张原理图，图中标明了成分、电缆以及接线安排的电压、电流或阻抗规格以及电源规格。

4.2.3机械描述

本部分包括：

-端子柜编组原则；

-机柜尺寸和安装；

-接线柱、插座和接线端子。

4.3功能接口

本部分的目的是提供两方面的要求了解。

接口设备及其监控数据和功能将按照ISCS和接口商的最初合同要求列出来。

4.4协议

本部分将提供用于接口的详细软件协议。

4.5命名惯例

本部分将说明用来识别ISCS和接口系统中的每种信息的命名惯例。

命名惯例将用来识别ISCS工作站中的信息和为设备、电缆以及接线端子加标签。

4.6设计约束条件

本部分将列出所有的设计约束条件，例如，特殊响应时间、通信软件版本，等等。

4.7EMC（电磁兼容性）

如果存在，则本部分将说明所有的电磁兼容性的约束或问题。

5.执行和安装

本部分将包括所有的执行和安装事件（如果存在）。

5.1限制条件

本部分的目的是尽早发现实施或安装方面存在的限制：

空间规定、接入日期和特殊工具，等等。

如果限制条件影响接口实施和安装程序，则该限制条件将包含在实施和安装程序中。

如果需要特别关注，则一个限制将被看成是一个特殊的接口问题。

5.2程序

本部分将提供一个接口实施和安装程序，该程序至少应该包含两位承包商所提供的信息和他们根据各自的目标开工和完工日期所采取的行动。

6.质量保证

6.1接口要求参考

本部分是一个基本的相互参照表，它为DIS中所规定的每条要求提供了它们相应最初的规范要求。

6.2验证和确认

本部分是一个基本的表格，它为DIS中所规定的每条要求提供了验证方法。

附录和图纸

详细的数据接口附录

对于每个接口位置来说，详细的数据接口表包括：

信息标识符（设备和数据）；

信息描述（设备状态）；

对应值；

点或信息位置（例如在一张表中列出）及地址。

电缆、接线端子和图纸

本附录包括所有的电缆路由选择、电缆终端、配置、机柜安排、结构规定以及空间规定和电路图。

系统启动参数

详细的接口测试计划（DITP）

本文件的目的是定义并描述如何在设计阶段实现接口测试，以达到如下目标：

首先，确认计划的测试是否必要和充分；

其次，组织单独测试，然后与接口承包商一起组织联合测试。

DITP是一种ISCS文件，由北京和利时公司制作和管理；

在提交给业主之前，将由接口承包商审查本文件；

我们建议接口承包商也可以将DITP用于自己的接口文件。

我们建议接口承包商使用没有改动过的文件，并且建议加上一个封皮带有与接口承包商规范保持一致；

两个封面的重叠将表明文件的修订版是如何与双方的合同保持同步的。

文件内容见表32

表32文件内容

本部分应叙述有关的接口及两个合同参考。

本部分将参考ISCS规范的相关部分和附录。

4.测试方法

本部分将描述在工厂测试阶段和现场测试阶段如何测试接口，并强调每个阶段接口测试的重叠部分。

5.接口测试规范

本部分将为工厂和现场测试总结出建议测试程序。

5.1测试标识符

对于每一种测试，都将分配一个测试标识符。

5.1.1测试的目的

简要描述测试的目的。

5.1.2需求参考

本部分将参考本程序所验证的接口要求。

5.1.3测试配置

本部分描述了完成测试所必需的硬件和软件配置。

5.1.4测试设备

本部分列出了所有必需的测试设备及他们个别的用途。

5.1.5测试程序

本部分包括用于相关的测试表的典型格式。

6.测试的逻辑顺序

本部分描述了完成测试的逻辑顺序。

7.质量保证

7.1接口要求参考

本部分是一个基本的相互参照表，它为DIS中的每条要求提供了它们相应最初的规范要求。

附录&

图纸

接口测试规范程序（ITSP）

文件目的

每个ITSP是一种测试程序，它描述了工厂接口测试、现场接口测试、现场端到端测试期间完成的每项测试；

在系统验收期间，测试程序将被ISCS工程师和接口承包商的工程师用作验收检验程序。

ITSP是一个ISCS和接口承包商的共同文件。

它将由ISCS和接口承包商共同制作、复查并向其各自的工程师发布；

本文件将被两位承包商同时参照，以管理它们各自的文件参考系统。

接口测试程序的内容

测试的所有细节、先决条件、测试行动以及预期的测试效果都将编入本文件。

测试表将在测试期间使用和填写。

因此，相关的测试表将由北京和利时公司和其他的承包商签署并编入测试报告。

接口文件的版本控制

文件版本控制将在每位承包商制定好质量程序之后进行。

该文本文件包括一张变动控制和签名页以识别以前版本的变动情况。

文本中可用下划线来识别复查过程中的具体变动。

在新版本中添加了工具条以表明变动情况。

接口变更管理

接口设计变更过程

在项目周期中，可能有变更接口要求以改进设计、改正错误并最小化风险。

接口设计变更过程确保：

所有建议的用于接口要求的硬件、软件或文件变更都必须汇报、记录、跟踪并解决；

用一种清晰、一致的方式提出变更说明书；

全面评估变更建议并接受正确的处理方案；

可以看到所有变更状态；

并且所有的传达和传达途径都进行了很好的定义。

将由ISCS和接口承包商共同制定详细接口规范。

在批准DIS时，将对接口设计（设计冻结）进行基准化。

在最初提交后，进行的任何变更都将按接口变更过程执行。

接口需求变更报告

接口需求变更报告是为重要接口问题或异常现象而编制的文件。

问题可能会与接口需求的任何一方有关。

接口变更报告可能会使用一种标准形式、用一种简洁的方式提出主题：

提供问题的描述并证明正确的变更建议。

接口需求变更报告将提出所有的相关事实以指出变更的重要性，例如所要求变更的细节、如果不变更的风险、建议的应用以及建议的优先水平等。

接口需求变更报告应该表明设计变更建议是否与规范要求和安全要求相符。

接口需求变更报告也应该识别正确设计变更是否偏离了这些要求。

承包商将决定是否需要召开会议。

变更建议的审查

接口需求变更报告将由业主和两位承包商共商复查以确保它描述了实际的问题并且附上到了所有相关的数据。

业主和承包商之间的正式、非正式文件将阐明或完成对所提出数据的理解。

如果有必要召开会议来讨论变更建议，那么在可能的情况下将在会议上把众多的变更建议进行讨论。

如果复查过程做出了变更结论，则将要求最初的承包商返工。

业主和承包商在复查过程中要求的内部安全和系统设计复查将按照它们各自的管理程序进行。

变更将通过与会的授权代表复查并记录于会议纪要中。

接口测试

为保证ISCS与各系统间接口的正确性，北京和利时公司采用不限于以下内容的测试方法检验系统间接口是否满足合同需求及相关技术规范。

技术要求

检验方法

物理接口

负责连接ISCS与各系统

目视检查，冗余测试，通讯测试

功能接口

ISCS与各系统之间实现的具体功能

点对点测试，端对端测试，功能测试，性能测试

协议

ISCS与各系统之间通讯采用的具体协议

协议测试

数据接口

各系统向ISCS提供的信息点

点对点测试，端对端测试

检验及确认

目视检查

为确保ISCS与各系统承包商提供的接口满足用户需求，可以采用目视检查或尺寸测量的方法进行检查，不需要专用的仪器设备，对各承包商提供的接口应进行100%的目视检查以确保接口安装的正确性。

目视检查测试的主要对象是所有物理接口的连接电缆及接口设备（包括：

电缆安装、端子排布置，转换器的安装位置等），目视检查将参照DIS中规定的ISCS与各系统接口划分及工艺图纸中来执行，目视检查不包括电缆的连接电气测试，该测试应该在安装阶段完成。

目视检查遵循以下步骤：

ISCS人员核对所有电缆是否已经在接口点处安装就绪，而且是否选择了最恰当的敷设路线。

ISCS人员核对所有电缆连接的正确性。

通讯测试

通讯测试确保各系统设备不同模块之间能正常通讯，测试将在现场进行。

通讯测试的目的是确保所有物理接口的两端通过电气连接测试，确保ISCS和各系统两端可以建立通讯连接。

通讯测试包括以下步骤：

ISCS人员使用万用表作为测试工具，测试接口双方的电气连接。

ISCS人员将便携机连接到ISCSFEP（该便携机可以监视局域网数据和连接状态）。

ISCS人员通过便携机检查连接状态。

通讯协议的测试目的是检验接口软件功能，确保ISCS和各系统承包商双方开发的协议及通讯机制达到设计规范；

同时检验软件接口部分是否遵守协议文件，并澄清在协议文本中没有描述清楚的内容。

协议测试应至少包含对所有命令和数据的格式、收发的机制和例外处理等的测试。

协议的测试应通过实际设备进行，除非北京地铁允许，一般不建议采用模拟器进行协议测试。

在详细接口规范中描述的接口协议被认可的情况下，ISCS和各系统应该履行协议测试，确保承包商双方正确实现接口协议，并澄清协议文件中未作规定的问题。

协议测试将测试以下功能：

系统初始化

消息格式的正确性

ISCS从各系统读取信息

ISCS向各系统写信息或命令

协议测试环境如下图所示：

图31协议测试环境示意图

冗余测试

冗余测试用来检查ISCS与接口系统间冗余机制是否满足合同要求及用户需求，冗余测试根据实际情况在工厂或工程现场进行，冗余测试应使用实际设备进行测试，不建议使用模拟器进行仿真测试，冗余测试至少包括以下内容：

正常情况下，ISCS与接口系统之间的冗余机制建立

ISCS冗余设备故障时，ISCS与接口系统之间连续通讯及故障隔离测试。

接口系统冗