工程电力监控及环控集成系统投标书.doc

H:精品资料建筑精品网原稿ok（删除公文）建筑精品网5未上传百度某地铁工程电力监控与环控集成系统投标文件 目 录1. 前言12. 组织分解结构( OBS) 12.1. 组织的目标12.2. 项目管理计划23. 工作分解结构( WBS) 33.1. 和合作投标伙伴工作分工43.2. 分阶段描述43.2.1. 系统和接口设计43.2.2. 软/硬件开发, 制造与采购93.2.3. 在工厂中集成检验/测试103.2.4. 工厂验收检验( FAT) 103.2.5. 运输113.2.6. 安装123.2.7. 安装测试123.2.8. 初步验收133.2.9. 功能测试133.2.10. 综合测试( 联调) 和试运行133.2.11. 保修144. 项目管理154.1. 项目计划164.2. 工作分配164.3. 预算分配和管理164.4. 需求与配置管理164.4.1. 需求管理164.4.2. 系统配置管理184.4.3. 软件配置管理184.5. 复查、 汇报、 会议及审核194.5.1. 内部月进度审查会194.5.2. 内部季度预算审查会194.5.3. 内部进度会194.5.4. 项目月进度会194.5.5. 阶段性审查204.5.6. 配置审核204.5.7. 质量系统管理审查和预防性措施204.6. 协调与沟通204.7. 接口设计计划214.7.1. 接口设计214.7.2. 沟通与交流214.7.3. 接口文件224.7.4. 接口变更管理254.7.5. 接口测试264.8. 与公共管理部门的协调264.9. 文件控制274.9.1. 规则与流程274.9.2. 文件发放274.10. 采购和分包合同管理284.10.1. 采购284.10.2. 分包合同管理284.11. 设备交货后的管理284.12. 现场组织与资源284.13. 综合后备支持284.14. 质量管理294.15. 风险管理294.15.1. 风险管理规则294.15.2. 风险管理活动294.15.3. 风险表305. 附件1: 工作与组织分解结构316. 附件2: 风险管理表的格式45A. 前言本项目管理计划基于综合监控系统成功的实施经验, 和科学的项目管理体系, 还借鉴了其它项目如广州地铁三、 四、 五号线综合监控系统项目计划和实际执行情况, 这对于成功实施*地铁综合监控系统具有非常重要的意义。项目计划是项目顺利实施并保证项目质量的前提, 是项目组织开展工作的依据, 而且要适应项目的特点和特殊要求。根据用户需求书, 总结该项目具有以下几个鲜明的特点: *地铁综合监控系统工程为国内领先的大规模综合监控系统工程, 对成熟的解决方案和综合技术实施水平的要求较高; 采取国外软件平台和技术解决方案为主导, 国内系统集成商提供工程服务的项目实施形式; 面正确技术接口数量与种类较多; 工作接口与协调任务较多; 项目工期较为紧张。*公司和合作投标伙伴公司将发挥各自在轨道交通行业系统工程实施管理经验, 共同制定本文件。本文件的目的是初步阐述*地铁综合监控系统项目的实施管理思路, 主要包括以下两方面内容: 工作范围和工作分解结构( WBS) ; 项目管理计划。其中, 项目管理计划的基础是组织分解结构( OBS) 和工作分解结构( WBS) 。本文件是与组织结构有关的质量计划的一个补充, 而且会在项目后期进行必要的修改或修正。B. 组织分解结构( OBS) 组织的目标即将参与实施该项目的组织将实现如下目标: 在北京设立项目组, 以便及时了解和掌握业主的需求; 依靠*公司和合作投标伙伴公司双方现有的组织和技术, 提供最新的、 最可靠的系统和优质的服务; 根据其它综合监控系统项目中已经成功实施的方案, 提供一个经过充分证明的系统。为了实现这三个目标, 我们将成立下面的组织: *公司将在北京建立一个( 现场) 协调小组, 在设计、 开发及制造阶段, 及时和北京地铁沟通, 了解需求, 同时和合作投标伙伴公司接口设计小组一起协调同接口设备商之间的设计工作。该小组重点工作是加强与项目干系组织之间的信息沟通; 在本项目的开发、 制造阶段, 合作投标伙伴公司将在北京成立一个项目小组, 以方便ISCS和接口设备之间接口的设计和协调; 在本项目的现场安装、 集成和测试阶段, 合作投标伙伴公司将在北京成立一支当地技术和协调小组( LTCT) 。小组将每天与业主进行协调并为业主和合作投标伙伴公司之间的沟通提供便利。该小组将特别关注让尽可能多的人员利用汉语进行交流。当来自法国的工程师不会讲汉语时, 合作投标伙伴公司将成立一些由一位法国和一位中国工程师组成的小组; 依靠*公司和合作投标伙伴公司现有的组织分解各种不同的工作, 这些不同工作的详细描述见下文的”工作分解结构( WBS)”一节。项目组织结构以及每个小组及其成员的任务与责任详见B13-1 项目管理组织机构。项目管理计划项目管理计划的构成如下所示: 组织分解结构( OBS) : 提供了项目组织的详细结构( 参见B13-1 项目管理组织机构) ; 工作范围和工作分解结构( WBS) : 提供*地铁综合监控系统项目所需的全部工作范围; 工作分配: 为不同的项目小组分配工作。WBS的每一项被指定给OBS的至少一个小组; 系统配置管理计划: 本计划描述了用来管理系统配置的方法与过程。它也涉及”需求管理”的内容, 以确保适当地管理用户的需求并确保所有交付使用的设备和服务都能满足合同的要求; 软件配置管理计划: 本计划用来管理系统配置的方法和过程; 协调和沟通: 确定项目团队内部外部之间的信息沟通途径、 方式和方法, 如审查、 汇报和召开会议; 接口管理计划: 用来制定并计划接口开发、 测试及协调的方式、 方法等; 文件控制计划: 用于文件控制和发放的规则与程序; 采购和分包合同管理计划: 描述了采购和分包工作的程序; 设备交货管理; 现场组织和结构: 包括现场办公室、 车间及库房; 综合后勤支持: 包括备用件、 特殊工具和测试设备、 文件、 培训等; 质量保证计划: 用来确保系统、 软件、 硬件、 安装活动以及相关问题的质量的程序与方法; 风险管理计划: 包括风险识别、 评估以及风险预防措施; 其它的杂项计划, 例如: 健康和安全计划以及环保计划等。C. 工作分解结构( WBS) WBS的目的是对工作项中的活动进行细分, 由项目小组或分包商的合格的小组或个人承担不同的责任。最终的结构形成了一个共同的参考系统, 该系统允许将项目各个时期的成本、 进度以及责任汇总在一起。具体见”Error! Reference source not found.”所示内容。WBS中各工作项具有如下特点: 能够由一个小组进行管理; 公布的成果能够根据输入/输出标准进行检查; 能够经过自己与其它工作项的接口来定义; 能够定义开工与完工日期; 由项目主管与工作项/小组经理共同协商批准必须的工作量( 总工时) 和资源。根据现阶段可得到的信息, 我们总结出下面初步的WBS: 管理; 系统与接口设计; 软、 硬件的开发、 制造/采购; 在工厂中的集成与验证/测试; 工厂验收检验( FAT) ; 现场交货; 安装; 接口测试; 培训; 现场验收( SAT) , 包括点对点的测试; 试运行与初步验收; 保修期或故障保修期与最终验收。和合作投标伙伴工作分工详见A10 软件采购合同。分阶段描述系统和接口设计系统及接口设计将分三个阶段完成( 即, 设计阶段1、 2、 3) 。在每个阶段, *公司和合作投标伙伴公司将完成设计和准备系统及接口设计文件的工作。这些文件将送给业主或接口系统供应商进行检查和评审。系统及接口设计文件是: 系统需求规范 ( SRS) SRS的主要目的是按照用户的需求, *公司和合作投标伙伴公司编制最终的系统规范, 最终版本的系统规范经用户审核并确认。本文件提供了适合系统特点的要求, 并规定了相关的验证方法。SRS包含下列信息: u 系统需求列表; u 需求的限定方法定义; u 要求的可追溯性定义; u 软件需求规范( SWRS) 和硬件需求规范( HWRS) 。根据软件和硬件配置项目描述了系统的详细结构, 以及系统不同部分之间的接口和数据流情况。它也在各种软件和硬件配置项目中分配了系统需求。 人机界面接口( HMI) 设计HMI的主要目的是定义操作员工作站的图形用户界面, 包括全部即将应用的人机界面( HMI) 设计。HMI详细资料将在各自的软件设计规范( SWDS) 中提供。 软件设计规范( SWDS) SWDS的目的如下所示: u 解释软件要求, 并将其用一种功能性、 操作员可理解的方式陈述出来; u 为相关软件包的初步、 详细设计收集所有的有用信息; u 操作员相关系统任务的定义; u 相关系统环境和由该系统管理的主要对象的描述; u 相关系统不同功能的详细描述; u 测试计划; u 需求的可追溯性; u 降级模式; u 参考系统的HMI描述。 硬件设计规范( HWDS) HWDS将详细描述所提供硬件设备的有关内容, 如制造商和主要技术特点等, 包括: u 计算机系统及外围设备; u FEP; u IBP; u 网络设备; u 大屏幕。 详细的接口规范( DIS) 与其它接口系统( 包括通信协议、 I/O点以及进度表) 接口的定义。根据经验, 为了实现下述目的: u 满足本项目紧迫的施工进度要求; u 方便10号线未来的系统扩展。建议使用开放、 标准的协议( 例如基于TCP/IP的Modbus) , 在每个设计阶段结束时, 都会召开设计和接口联络会以便进行讨论、 决策和设计验收、 检验的方式方法。在本项目的设计阶段, *公司和合作投标伙伴公司将实施的审查工作, 见Error! Reference source not found.: 表 C1设计阶段审查表项目计划ISCS 责任范围对业主、 设计单位、 接口供货商的约束条件第一次设计联络会启动第一次设计联络会, 所有接口商将参加并讨论详细接口规范(DIS)。第一次设计联络会的目标如下: 理解工程化方法( V字软件工程实施模型) 和质量管理体系、 提交文件管理体系; 经过项目概念演示, 使业主、 设计方能更好地理解ISCS系统; 所有与会方讨论接口设计, 讨论并确定接口设计方案( DIS详细接口规范、 协议、 冗余方案、 设备图符、 设备类表点表、 测试方案、 子系统的相关工程计划、 所需资料列表等) 并书面签字( 里程碑) 。 经过DIS将使所有接口商明确实现共同目标所需要的工作列表。 根据合同及澄清文件, 对用户需求( UR) 进行详细分析及细化, 得到系统需求规范( SRS) 、 软件需求规范( SWRS) 、 硬件需求规范( HWRS) 。 初步讨论并确定图形用户界面(HMI)设计原则, 包括用户权限表、 设备编序法等等。 IBP盘初始设计。 HOLLYSYS要求所有与会方遵循设备类表、 点表、 图形的版本基线控制管理方法、 变更与修改方法, 以期减少不必要的、 不符合修改规范的变更。 业主确认在工程方法、 质量系统方面没有异议; 业主有必要向各接口商及其对应的业主、 设计方, 多次强调: 各方必须遵循设备类表、 点表、 图形的版本基线控制管理方法、 变更与修改方法, 以期减少不必要的、 不符合修改规范的变更。 接口设计联络会议的重要先决条件: 为了讨论接口方案, 业主应在通知并协调接口会议时接口商。在该方面的任何延迟均会导致项目的延迟; 接口商应出席接口联络会议, 并在会议期间将其书面意见提交给HOLLYSYS; 在会议期间, 当接口商同HOLLYSYS之间出现争议时, 由业主进行调停; 设计方、 接口商应向ISCS提供设备类表、 点表。会议结束时, 接口商应签署接口文件( DIS、 协议、 冗余方案、 测试方案) , 并签署设备类表、 点表、 图符的设计文件。 业主应让设计方、 接口商明确工作流程、 工作关系、 各自职责。业主对上述设计工作及签署文件进行确认, 并协助ISCS供应商获得尚缺少资料。 建议业主安排运营相关骨干人员, 直接全程参与设计联会及后续的重要设计会议, 以完成需求分析、 反馈及评估等重要工作。第二次设计联络会在第二设计阶段结束前, 将召开第二次设计联络会。第二次设计联络会的目标如下: 更新并冻结图形用户界面(HMI)设计原则, 包括用户权限表、 设备编序法、 图符库等等。 所有与会方更新、 冻结并书面签字: 用户需求( UR) 系统需求规范( SRS) 软件需求规范( SWRS) 硬件需求规范( HWRS) 讨论并经过系统设计规范( SDS) , 如数据流设计等。 讨论并经过软件设计规范( SWDS) , 如: 系统功能设计, 如: 报警 雪崩 SOC 时间表 报表 历史库、 事件 趋势 用户权限表 权限管理 图形原则( 设备编序 颜色定义 图符) 计算事件 联动功能设计 配置管理 打印管理 在线帮助等等。 子系统功能设计, 包括: PSCADA、 BAS、 PA 、 CCTV、 PIS 、 TCC的功能设计; 接口测试规范程序文件( ITSP) ; NMS DMS TMS的功能设计; 讨论并冻结硬件设计规范( HWDS) , 固化设备的硬件配置, 固化IBP设计。 提供并讨论初版施工图 业主审核HOLLYSYS提供的所有文档, 并在第二次设计联络会议之前或在会议期间将意见提交给HOLLYSYS。 业主核准所有的系统设计( 见左侧的责任范围内容) 。 业主应完成并完善第二次设计联络会要求的所有的相关工作。 接口商应参加均席设计联络会议, 并在会议期间将其书面意见提交给HOLLYSYS。 接口商应完成第二阶段设计联络会要求的相关工作。 在会议期间, 当接口商同HOLLYSYS之间出现争议时, 由业主进行调停。 业主应对上述设计工作及签署文件进行确认, 并协助ISCS供应商获得尚缺少的资料。 经过本次会议, 务必最终确定并固化设计方案, 确定并固化各接口子系统的设备类表、 点表的版本基线。否则,在后续工作中, 过多的变更会大大增加制造阶段的返工量, 导致项目进度延迟。 本次会议所确定的设备类表、 点表版本基线, 将做为软件FAT、 P2P测试的软件基础版本基线。第三次设计联络会在第三阶段设计联络结束前, HOLLYSYS将召集第三次设计联络会。第三次设计联络会的目标, 是讨论并确认如下: 明确工程总体及各子系统的计划与调试进度, 并倒排ISCS的工程进度计划; 最终版施工出图: 系统图、 材料表 网络连接图 管线图 供电图、 配电图 接地图 IBP结构设计图、 端子图 支架设计图 柜体设计图 车控室布置图 设备房布置图 设备编号说明 安装督导说明等等 讨论并确定以前设联会未尽事宜; 回顾工程进度, 重申重要原则, 评估并预测工程执行风险, 统一各方思想、 工作方式及工作重点。 业主审核HOLLYSYS提供的所有文档, 并在第三次设计联络会议之前或在会议期间将意见提交给HOLLYSYS。 业主应完成并完善以前设计联络会要求的所有的相关工作。 在会议期间, 当与其它专业调试进度等与ISCS之间出现争议时, 业主应进行调停。 会议结束时, 业主、 设计等与会各方应签署会议纪要。 软/硬件开发, 制造与采购软件开发本阶段与典型软件部件的实现阶段相对应, 合作投标伙伴有责任利用这些软件来构建整个系统。软件开发主要在香港( 部分工作在法国) 完成, 具体包括: 人机界面接口( HMI) 的模型化、 数据库的设计和实现以及测试计划; 软件的初步和详细设计; 编码和单元测试, 包括: u 时间表, 图形动画、 窗口和HMI的编码; u 数据库配置; u 接口编码; u 具体功能编码( 将保存一份软件配置表) ; u 软件集成和集成测试。在本阶段一开始, 其它的接口设备/系统供应商需提供接口模拟器。与模拟器的初步接口测试将同接口系统/设备供应商一起在北京完成。硬件采购一般来说, 该工作包括定义和发布采购本项目所需设备的文件。本阶段的目的是: 详细定义需采购的硬件; 详细定义需采购软件包; 采购硬件和软件包。根据分工, 由*公司和合作投标伙伴公司合作完成硬件系统的采购, 而由*公司负责相关的安装及布置设计, *公司和合作投标伙伴共同负责软件设计, 因此*公司和合作投标伙伴公司将时刻保持联络, 沟通必要的设备数据。根据系统需求, *公司和合作投标伙伴公司将编制并保存硬件配置表。部件测试在进行系统集成和检验之前, 系统的每项内容都将在工厂进行测试。这种测试包括所有项, 作为子系统测试中的组成, 有使用前的检查、 硬件测试和软件测试。项目测试证明一个项目满足了它的特定的物理和功能要求。必要时, 能够进行特定测试。各种工厂制造的电气装置要进行检验和验收。对这种硬件的检验可能包括: 这种设备是否符合制造商规范; 设备是否齐全; 正确操作测试; 一致性检查( 元件布置图、 配线图) ; 协议测试; 冗余测试; 点对点检查; 绝缘检测; 检测接地连续性。在工厂中集成检验/测试在本阶段开始, 业主或其代表须确认并批准由*公司和合作投标伙伴公司制定的工厂测试规范和现场测试规范。开发阶段会伴随着一系列的设备和子系统测试。经过进行与接口设备/系统供应商的协议测试, 集成测试允许对硬件/软件模块以及它们在适当系统中的集成进行测试。检验测试允许按照工厂验收计划对系统进行测试。这些测试及测试结果会记录在测试报告中。工厂验收检验( FAT) 工厂验收检验的目的是为了验证在现场配置和安装前, 系统是否与规范相符。为了进行高效的检验, 工厂验收检验将分两个阶段进行: 第一个阶段的FAT将对有代表性的部分进行检验。目的是验证各个部分在进行完全配置和安装前的功能和性能。第二阶段的FAT将对完全配置但未安装的系统进行检验, 它将检验数据库、 图形界面以及系统的综合性能。工厂功能验收测试( FAT) 系统中进行工厂验收的主要部分是: 计算机系统( 服务器和工作站) ; 软件和参数设置。它们将在合作投标伙伴的香港工厂中进行单独的工厂验收检验。测试软件、 硬件与其它接口商提供的系统互连, 能够确保软硬件与其它系统的兼容性。接口商应提供模拟设备以便进行FAT测试, 最后测试将在现场进行。其它硬件设备的FAT在*公司完成。工厂综合验收测试 ( iFAT) 工厂综合验收检验结合了ISCS系统中的所有项目并模拟那些由其它接口系统/设备供应商提供的部分。利用模拟器、 仿真器或真实设备检查以确保所有接口都正确, 而且确保系统的功能是完备的。然后, 将系统当成一个整体来测试以证明它满足了功能、 容量、 可维护性和可操作性的各方面要求。进行测试以证明项目或整个系统的操作都是正确的, 测试包括: 验证在整个集成系统、 设备和软件配置中所有应用软件功能的综合测试; 验证系统可靠性; 与接口系统的协议测试、 冗余测试、 点对点测试: 在测试时点的覆盖率达到了100%。运输根据包装运输计划完成包装、 装卸和运输程序, 将设备运到业主提供的存储地或最终安装地, 库房由业主提供并管理。*公司当地技术与协调小组将完成的工作包括: 在用户到场的情况下进行包装和装箱检查; 将设备发运到库房区; 给设备贴标签; 开包/开箱进行设备检查。按照装箱单以及采购文件进行验收; 与安装小组进行协调, 将设备运往最后的安装现场。安装只有在完成土建工程后才能进行设备的现场安装。这样做能够确保灰尘不会进入设备的内部、 不会引起严重的硬件损害。ISCS必须安装在干净、 有空调设备的房间中。*公司和合作投标伙伴公司将派遣安装督导小组在北京以监督、 指导安装过程。安装工作由业主完成。这包括现场电缆敷设安装以及所有的硬件设备的物理安装。控制系统计算机和FEP硬件安装在最终位置上, 并与必要的、 经过测试过的线缆连接在一起。根据*公司和合作投标伙伴公司或其它供货商提供的安装手册并在业主批准的情况下进行设备安装。安装手册包括: 安装计划; 安装图纸( 布置图、 电缆表、 单元接线图等) ; 施工图; 安装程序; 安装督导指导书( 详细描述设备安装的技术要点) 。电缆安装过程由业主安装队完成电缆的安装。安装工作的时间顺序如下所示: 安装用于电缆敷设( 电缆托架、 电缆保护套管以及电缆管道) 的辅助设备; 敷设电缆; 电缆联接/电缆终端处理; 初步检查( 导通性及绝缘检查, 等等) 。安装人员安装人员由业主组织, 可分成若干个小组, 每个小组有一个负责人, 负责管理和协调工作。安装计划将有条件地与下面的合同保持协调: 土建工程; 配电专业( 为综合监控系统提供电源) ; 经过FEP采集数据的各子系统。为了按计划好的施工进度表完成施工, 根据业主批准的物理接口进度表安装人员将允许在安装工作的每一步与接口工作人员进行协调。安装测试安装测试小组由*公司硬件安装经理、 督导工程师和分包商相关人员组成。硬件设备的安装测试在现场完工后进行, 这包含如下所示的步骤: 初步检查; 功能测试; 试运行。安装测试按照安装测试手册进行。安装测试手册包括: 初步检查程序; 功能测试程序; 试运行程序。初步验收在设备安装结束时, 将对系统的机械和电源部分做初步检查和测试工作。这包括: 目视检查是否与批准的图纸相符; 是否符合质量标准; 检查电缆连接完整性、 标签与型号; 检查设备标签; 对设备进行点对点检查, 以检查是否与接线图一致; 接地和电源检测。这项检测应该在装配完工后进行。将检测情况记录在完整的检测报告中。这些检测应该在通电的情况下进行。功能测试包括每个设备的有效试运行。它们将在初步检查结束后进行。按照地铁系统中的其它设备的情况预先确定好检测程序。这些检测包括: 逻辑自动系统的检验; 验证是否与规定的要求相符; 检验交付给用户使用的备用件。测试程序的基础是工厂验收检验。当所有由其它的接口系统/设备供应商提供和安装的子系统都运行工作后, 再进行功能测试。综合测试( 联调) 和试运行这包括整个系统的有效试运行而且这些测试将在功能测试完成后进行。为了让整个合同系统投入运行, 这些测试的顺序与由其它接口系统/设备供应商实施的系统测试保持一致。综合测试和试运行包括: 综合测试, 包括测试其它接口系统/设备供应商的特殊应用; 端到端的功能测试以检查数据交换情况; 每个接口与其它接口系统/设备供应商工作之间的通信和有效数据传送的功能测试; 故障模拟; 响应时间测量; 系统与其它接口系统/设备供应商设备的集成测试; 144小时稳定性测试; 3个月的试运行。试运行的结束使*公司能够向用户证明项目已经成功完工。试运行期间进行的测试能够证明该系统是完全可交付使用的, 这是测试的最后阶段。在完成测试规范中所规定的测试项目后, 再公布测试结果。保修保修期为2年, 包括: 硬件保修; 软件保修。在保修期内解决问题的程序以*公司提供并经用户批准的故障通知单或用户请求电话、 传真为基础。用户请求电话或传真通知*公司的现场技术与协调人员, 或由用户的维修代表填写表格, 用来记录由用户发现的故障, 并将表格递交给*公司的现场技术与协调人员, 以便*公司及时采取相应的保修措施。硬件保修来自*公司的硬件保修代表或用户的维修人员对现场硬件进行检查以便确认故障是否存在。将由*公司的现场技术与协调人员或用户的维修人员鉴别并除掉有故障的硬件。业主将把故障部件递交给*公司以便进行维修/更换新部件。在故障排除后, 业主的维修代表会签署故障通知并解决该问题。软件保修软件保修包括电话技术支持以及修正软件的任意缺陷。这种保修将由合作投标伙伴的保修代表现场进行。软件保修代表必须对故障进行鉴定, 而且能够要求用户到场进行调查以便确定故障情况。如果认为故障属于异常情况, 则软件小组将准备修正软件, 需要时还会更新相关的文件。在用户到场的情况下, 在测试平台上进行的这种修正是有效的。一旦进行了修正, 就要填写软件异常修正表。由用户确认该修正工作并批准该表格。D. 项目管理项目管理活动包括以下16个方面: 项目计划和商业/合同管理; 工作分配: 为工作包或小组经理定义工作对象/范围; 预算分配和预算管理; 要求和配置管理; 经过报告、 会议、 复查进行进度监控( 包括协调并向用户汇报) ; 协调和沟通; 接口管理; 与政府部门/管理当局的协调; 文件控制; 采购和分包商管理; 设备交货后的管理; 工地组织和结构; 综合后勤支持; 培训管理; 质量管理; 风险管理。下面将详细描述项目管理的16个方面: 项目计划*公司将制定总体项目计划, 具体由项目计划与合同管理组完成。下列文件提供了详细的项目计划: 设计和制造计划; 软件开发计划; 安装测试计划。合作投标伙伴将在软件开发、 安装测试方面单独制定详细计划, 并提交*公司, *公司形成总体计划送交业主。工作分配目的是为不同的项目小组分配工作。根据工作分工, *公司和合作投标伙伴公司将分别制定各自的WBS, WBS的每项工作都被分配给OBS的至少一个小组。每位小组经理对自己小组的工作结果负责, 并向项目经理/主管汇报工作。因此每位小组经理都必须对分配给自己小组成员的工作以及她/她的工作范围的任务负责。关于人力资源, 每个小组必须明确自己的需要以便能够独立处理自己工作范围内的工作。如果要增加资源, 小组经理必须向项目经理/主管请示。预算分配和管理项目经理分配给每一位小组经理一份预算以便其完成自己的工作。成本管理员定期跟踪小组经理的预算以更新她们的预算状况。每位小组经理都必须考虑在合适的技术和组织选择方面分配其预算。每三个月要求每位小组经理向成本管理员提供一份包含如下内容的预测报告: 完成工作所需的资源; 未付费用/采购费。然后, 成本管理员会更新预测的工作预算。在超支的情况下, 小组经理必须向项目管理小组提供一份恢复计划。为了满足用户的进度的要求, 进度要求的满足将优先成本方面的考虑, 即将不计较成本, 首先满足进度要求。需求与配置管理需求管理需求管理是开发综合监控系统软件, 完成综合监控系统工程的一个主要的组成部分。下面几节的目的在于提供已经定义好的特别是软件功能需求方面的一般规则, 并描述组织结构情况以便具备一个有效的需求管理系统。该项任务由*公司和合作投标伙伴公司共同完成, 管理工具将由合作投标伙伴提供。一般规则DOORS套装软件是一套公认的软件包, 它用于管理复杂系统的需求而且已经被合作投标伙伴集团采用。合作投标伙伴集团已经开发了一个应用层并将其与DOORS集成在一起。这一应用层被称为TREK。为了用一种精确、 有效的方法跟踪合同的要求, THALES集团已经决定在整个项目期间使用DOORS/TREK软件包作为需求管理工具。一般过程一般过程如下所述: 将用户所有的技术要求输入到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工具的管理由系统配置工程师执行。系统配置管理配置管理计划中规定了整个项目期间都要遵循的与系统配置管理有关的规则。当项目管理计划和配置管理计划之间发生冲突时, 将按照下面的优先次序执行: 1.项目管理计划; 2.配置管理计划。为了能够根据清晰设计而开发系统, 及为了拥有一套一致的文件和DOORS模块, 将定期更正系统基准。在整个项目期间, 该过程都会进行。配置控制委员会( CCB) 将负责在整个项目周期中定义各种基准。系统配置工程师将负责跟踪并监督将投入使用的基准系统。将遵循的一般规则如下所示: 在给定的参考系中, 系统基准与一套基准的DOORS模块对应; 对应于给定基准的文件将储存在DOORS模块中; 将有两类基准: u 正式基准: 它们对应一套模块包括基准和正式提交给用户的基准; u 非正式基准: 它们对应一套于DOORS模块的基准, 但未包含在正式提交给用户的基准。 无论是什么原因要求变更文件, 都必须向负责确认并决定何时执行变更的CCB提交一份变更建议: 在CCB做出正式决定之前, 任何人都不能擅自变更作为基准的模块; 当CCB做出执行变更的决定时, 变更及其相关影响将输入到DOORS中去。进行变更后, 所有修改过的文件都必须进行基准变更, 而且系统基准也必须进行相应地变动; 正式文件基准按照文件的修订版进行命名; 非正式文件基准按照正式最新的修订版参考号并后加一个字母命名; 正式系统基准的名称由字母”S”后接199的数字构成; 非正式系统基准由字母”S”后接199的数字以及一个小写字母构成; 为了检查是否正确执行了变更情况, 必须使用一个跟踪系统。这种监督工作由系统配置工程师负责; 在项目的任何阶段, 任何活动都必须按照当前批准的系统基准进行。软件配置管理软件配置管理计划中规定了软件配置管理的规则和程序。在配置管理计划和软件配置管理计划发生冲突时, 将按照下面的优先顺序执行: 1.配置管理计划; 2.软件配置管理计划。复查、 汇报、 会议及审核除了设计联络会, 将执行下面的复查、 汇报、 会议和审核: 内部月进度审查会合作投标伙伴项目主管每月经过月项目审查会向*公司项目经理汇报工作。*公司和合作投标伙伴公司每位小组经理都必须在审查会之前至少一周向各自的项目主管提供与其工作有关的信息以便进行汇总。成本管理员负责将各种报告汇总到审查会报告中去, 以便项目经理在审查会前进行分析。成本管理员负责组织这些会议并通知相关的与会人员。内部季度预算审查会项目主管经过季度预算审查会每年向法国的项目部主管和成本管理员汇报4次工作。每位小组经理在季度预算审查会前至少3周向项目经理提供与其工作有关的预算信息用于信息汇总。成本管理员负责将各种数据汇总到项目季度预算审查会中去, 以便项目经理在季度预算审查会前进行分析。成本管理员负责组织这些会议并通知相关与会人员。内部进度会*公司和合作投标伙伴公司每周将各举行一次公司内部进度会。所有的小组经理都必须参加。对于某些会议来说, 可能会邀请额外的项目小组成员参加。这些会议将在每周一下午4点举行。如遇公共假期, 则会议自动顺延至第二天的同一时间举行。如遇特殊情况, 会议能够延期举行。项目月进度会*公司和合作投标伙伴公司每月举行月进度会, 该会议是*公司和合作投标伙伴公司基于项目管理层面, 小组经理也参加会议。对于某些会议, 可能会邀请额外的项目小组成员参加。这些会议由*公司组织并主持。对于相关的每月进度报告: 将在每月5号提交; 每位小组经理都必须填写部分与其工作范围相关的报告; 秘书负责组织收集各种报告并将其编入每月进度报告。必须在每月5号前至少两天将报告草案提交给项目经理审阅。阶段性审查在项目施工期间, 在每个重要阶段结束时都要进行内部审查, 内容包括: 系统设计审查( SDR) : 目的是审查详细接口规范( DIS) 、 系统需求规范( SRS) 、 系统设计规范( SDS, 包括SWDS和HWDS) 以及接口需求规范( IRS) ; 部件设计复查( CDR) : 目的是检查各子系统和系统组成部分的设计文件是否适合生产; 系统测试准备就绪复查( STRR) : 目的是检查与系统测试相关的文件是否允许在工厂进行系统测试以及在现场以一种控制方式进行系统测试。配置审核配置审核能够用来验证系统和配置项目与其基准是否相符。质量系统管理审查和预防性措施*公司和合作投标伙伴公司将审查本项目中执行的质量系统的适宜性和有效性。由计划经理准备预防性措施分析报告以分析内部审核、 用户审核和日常操作中发现的非一致性问题。然后将在每年至少举行一次的质量系统的管理复查会上审阅预防性措施分