通飞ta600数字化协同研制平台

1、数码科技公司通飞 TA600 数字化协同研制一期实施技术服务协议（固定价格工作说明书）日期：2014 年 1 月 4 日版本：V3.0数码科技公司（“数码”，以下简称“甲方”）和参数技术（）（“PTSH”，以下简称“乙方”）一致同意，有关本文所述服务的完整协议由这份工作确认书（“SOW”）和 PTSH 与数码间签署的服务合作伙伴协议（“SPA”）两部分共同组成。若 SOW 与 SPA 间存在异议，则以本 SOW 条款为准。PTSH 在收到来自数码的订单后，将开始执行此工作确认书。签字：数码科技公司日期：参数技术（）全球服务部日期：项目代表文档属性变更审核者职务日期作者版本描述2013-12-1

2、6V1.0初稿，依照项目建设建议方案编制2013-12-27V2.0修正稿2014-1-4V3.0修正稿文件名称状态通飞 TA600 数据化协同研制.docx目录1.项目实施概述12.项目实施内容2项目目标及应用范围2项目目标2项目应用范围3项目实施内容3设计制造协同环境3制造协同管理环境5与其他应用的集成113.项目实施计划、组织和策略14实施计划14项目组织14实施策略154.项目实施方法17项目管理17应用设计18应用开发18质量管理19系统部署195.前提条件和假定215.1一般假定215.2硬件和. 21实施场地22项目资源和进度管理226.项目验收标准和流程237.和付款条件268

3、.项目变更27项目变更控制流程27项目变更乙方职责28项目变更甲方职责28附录 A：甲方职责29附录 B：项目管控模型30附录 C：阶段确认书模板( TEMPLATE OFTONE). 31附录 D：签署阶段确认书. 321. 项目实施概述兹有甲方委托乙方进行“TA600 数字化协同研制好协商，达成以下技术协议：一期项目”的实施。经双方友作为、国防科工局、财政部、工业和信息化部等部门联合批准立项的国家重大项目和国家应急救援能力建设的重要内容之一，“蛟龙-600”（以下简称“TA600”）型飞机是单船身四发涡轮螺旋桨式综合救援飞机，将成为世界上最大的一款水陆两用飞机之一。TA600 的研制将按照

4、“水陆两栖、一机多型、系列发展”的设计，在满足森林灭火和水上救援要求的同时，兼顾海洋环境监测和保护及货物等用途，飞机总体技术水平和性能将达到当前国际同类飞机的先进水平。通过项目研制，能够填补我国大型水陆两栖飞机的研制空白，形成具有知识的设计研发体系，我国水面飞行器的设计制造能力和能力。TA600 型号复杂、研制时间紧迫、任务艰巨、风险性大，为了确保研制目标节点，必须利用航空工业的整体优势，在机制、管理和技术上进行创新，充分借鉴国外飞机先进研制的经验，更深入全面地采用数字化设计、制造、管理技术，建立数字化协同研制环境，使数字化协同研制技术在型号研制应用中发挥最大的支撑作用。考虑到型号研制进度的要

5、求，本期项目将面向 TA600 型号的全面试制阶段。乙方注意到甲方以上各方面的具体需求，经双方友好协商，达成以下技术协议。甲方和乙方需要共同召开一次实施前的会议，进行实施的各项准备工作，并定义初步的实施计划。通常乙方全球服务团队将在收到订单的 2开始履行此合约。2. 项目实施内容2.1 项目目标及应用范围2.1.1 项目目标根据目前TA600 研制的迫切需求，本期项目建设内容将重点支撑 TA600 全面试制阶段的主要业务。该期项目的目标设定如下：通过本期项目建设，建立 TA600 数字化协同研制的基础框架，重点面向华南公司，搭建设计制造协同环境、制造协同管理环境，实现设计制造的及相关数据的化管

6、理，并确保协同和管理过程中的构型状态正确、有效，为TA600全面试制阶段的业务提供最大化支撑。根据以上建设目标，本期项目的具体建设内容包括：(1) 设计制造协同环境EBOM 数据接收与分发工程更改技术协调单管理现场单据管理(2) 制造协同管理环境PBOM/MBOM 管理工艺文件管理工装管理流程工艺协调数据集管理技术文件管理（含设计和制造）(3) 与其他应用的集成VPM 集成金叶CAPP 的集成兰台管理系统集成2.1.2 项目应用范围一期项目的应用范围：通飞、华南公司。其中，通飞利用该进行EBOM 设计数据发送（含更改单及更改数据发送）、技术协调、现场单据协同等；华南公司以该作为TA600 型号

7、的制造管理进行与设计的协同、PBOM/MBOM 管理、工艺数据管理、工装管理流程等。一期项目的数据范围：TA600 型号的详细设计数据（含更改单等）、工艺文件、工艺协调数据集、技术文件（设计及制造端）、现场单据（代料单、不合格问题单、重量超差单、工艺偏离单）等。2.2 项目实施内容乙方将以本技术协议定义的工作范围为依据，针对甲方数字化协同研制本期实施内容，进行与 TA600 型号相关的业务方案定义、方案开发、系统部署和上线支持工作。下面对各项内容的实施范围和具体要求进行描述。2.2.1 设计制造协同环境2.2.1.1 EBOM 数据接收及分发本期项目中将通过与 VPM 系统的集成实现 EBOM

8、 数据的接收以及 EBOM 产品结构和有效性信息在Windchill 系统中的重现。实现内容包括：EBOM 数据接收：在制造端，通过数据接收流程进行设计数据的接收，并重现 EBOM。该流程可以设定为：数据设计在 Windchill 协前，由通飞同研制中创建数据发送通过流程通知华南公司数据接收进行数据预览，确认后由系统集成接口将 VPM 中的数据同步至Windchill 协同研制定义的工艺预分工信息也通过集成接口导入至Windchill 系统中。中。VPM 系统中设计数据二次分发：确认接收设计数据后，制造端可以通过流程进行数据的二次分发，分发可以根据分发路线进行流程驱动的自动分发，各个环节的数据

9、接收还可以继续分发给本部门的其他相关。2.2.1.2 工程更改为了确保设计更改在制造相应的业务部门得到和，例如设计更改导致的工艺、工装等方面的更改，在中应实现设计更改的闭环管理。在中将通过对设计更改指令的管理，设计更改引起的工艺、工装等环节的工程更改闭环管理。实施内容包括：闭环更改流程管理：建立闭环更改流程，确保发生设计更改时，相关的工艺、工装等更改都得到了，实现更改归零管理；闭环更改过程实时：可以对设计更改的情况进行实时动态统计，方便质量管理监督更改执行的闭环。2.2.1.3 技术协调单管理在华南公司进行生产准备的过程中，需要大量的技术协调工作，这些协调工作包括华南公司的技术协调以及华南公司

10、与通飞的技术协调。从规范化技术协调单管理，确保技术协调过程闭环和可追溯的角度出发，需要对技术协调单及其协调过程进行化管理。实施内容如下：技术协调单管理：实现技术协调单的创建及管理，技术协调单创建后系统可以自动启动技术协调过程，并由创建指定协调接口人进行答复。技术协调过程管理：通过流程对技术协调过程及答复过程进行管理，根据实际协调流程进行系统定制。技术协调过程：对技术协调单及其行动项状态进行动态，并可以输出为报表。2.2.1.4 现场单据管理对生产现场相关数据及工作流程进行管理、控制、追踪等。包括对代料单、不合格问题单、重量超差单、工艺偏离单等数据及相关处理流程的管理。此外，对各种试制现场问题的

11、处理过程进行，以便于以后的追溯，同时提供各种统计汇总的能力。实施内容包括：单据结构化管理：提供单据的结构化录入、查询和管理界面，能够输出 Word 格式的文件，并支持这些单据结构化信息的导出、导入，以实现与其他协作之间的交互；单据流程管理：实现单据处理过程的管理，能够对处理过程、处理状态和处理结果进行实时和过程追溯；单据统计报表：提供各种统计汇总的能力，可以按照单据类型、处理日期、处理状态、处理等进行统计汇总，并可以按照指定格式输出为 Excel 等文档。2.2.2 制造协同管理环境2.2.2.1 PBOM/MBOM 管理(1) PBOM 的建立和管理PBOM 数据的主要信息包括：面向工艺计划

12、、工艺路线和工艺分工的产品结构；产品结构中的属性信息（例如零件版本、组别等）；产品结构中零的有效性信息及装配关系属性信息（例如数量、工艺路线、成套件号、工艺路线备注等）；产品结构中各关联的工艺计划资料更改单、工艺计划等；产品结构中各对应的更改信息（包括更改单、更改指令、更改流程等）。基于 EBOM，可以进行 PBOM 的重构和管理，其实施内容包括：PBOM 重构：支持基于 EBOM 进行 PBOM 的重构，即在结构中增加工艺组合件等；添加工艺路线、制造属性（成套件、制造商信息等）等，从而形成完整的 PBOM；可以不基于 EBOM 进行 PBOM 构建，支持EBOM 与PBOM 的对比；PBOM

13、 签审及更改流程管理：可以基于 PBOM 中的某一节点，对 PBOM 进行电子化签审，系统根据模版驱动各个流程环节，PBOM 签署完成后，其状态将要修改，需要启动更改流程。如(2) MBOM 的建立和管理MBOM 数据信息主要包括：产品结构中的属性信息（例如工位、相关分厂等）；产品结构中零的有效性信息及装配关系属性信息（例如数量、等）；产品结构中各关联的试飞工艺指令、交接情况单、样板订货单、AO/TO/FO、工艺规程、拒收单及其它相关文档；产品结构中各对应的（包括更改单、更改指令、更改流程等）。收到 PBOM 中本车间负责装配的组件、对于装配车间来说，通过，还需根据的装配情况确定某一个下的工艺

14、组件，划分出工艺组件中包含的零组件，再编制 AO、交接单等工艺文件。在中，工艺组件以及工艺组件与所包含零组件之间的结构关系可以在 PBOM 产品结构基础上重构建立，工艺大组件及其包括的零组件装配关系建立以后，全机底层级MBOM 产品结构也就建立了。实施内容如下：MBOM 的建立：可采用自顶向下设计和自底向上设计两种模式。根据公司业务情况，MBOM 的顶层结构在确定工艺总方案和进行 AO 规划时即可确定下来， MBOM 底层产品结构在编写 AO 等工艺文件时建立。这样经过自顶向下和自底向上的迭代和递归，全机 MBOM 的产品结构也就建立了。 提供 MBOM 顶层结构数据导入工具，将 MBOM 顶

15、层产品结构信息按照模版（Excel 格式）收集完成以后，导入至协同 中。对于导入系统的MBOM 数据，应该在数据文件完成审核后，再由系统执行导入，以加强对导入过程的控制；基于MBOM 的 AO/FO 关联管理：通过与 CAPP 集成，可以将 AO/FO 等工艺文档与 MBOM 建立关联关系，由 MBOM 进行管理；的、层次化的工艺设计结果的组织和MBOM 签审及更改流程管理：可以基于 MBOM 中的某一节点，对 MBOM 及其相关数据进行电子化签审，系统根据模版驱动各个流程环节，MBOM 签署完成后，其状态将。如要修改，需要启动更改流程。(3) 有效性管理与设计端基于架次的有效性信息保持一致，

16、构建制造端的架次有效性管理及应用模式。具体实施内容包括：有效性标识：在 PBOM/MBOM 产品结构中，能够基于有效性管理要求，对PBOM/MBOM 的有效性进行标识，确保 EBOM/PBOM/MBOM 中相同零次中的有效性信息的一致性；在同一架有效性更改：设计更改引起的有效性调整应进行 PBOM/MBOM 的有效性调整贯彻，制造端的更改引起的有效性变化应在制造端的更改管理流程中进行控制；基于有效性的过滤：能够基于架次信息对PBOM/MBOM 数据进行过滤和浏览。(4) 统计报表在各相关业务部门编制工艺文件、组织生产制造等过程中，需要使用到各种统计报表。协同研制应提供生成工艺、制造所需要的各种

17、统计报表的能力。这些统计报表主要有：EBOM/PBOM/MBOM 差异性基于 PBOM 分工路线的车间零件MBOM（部组件、架次、版次、路线、材料等信息可选择性导出报表）标准件汇总报表工艺装备工具装配指令（AO）零件制造指令（FO）成品汇总报表2.2.2.2 工艺文件管理TA600 数字化协同研制将对工艺部门编制的 AO、FO 等工艺文件进行的管理和控制，并可以自动根据 AO 的零件清册生成 MBOM 中 AO 件下的零件，实现与MBOM 的有效结合。主要实施内容如下：工艺文件编制分工：根据零的工艺路线自动进行 AO/FO 分工，并通过分工流程，实现 AO/FO 编制任务从工艺管理室到车间工艺

18、室，再到车间工艺员的分工AO/FO 的漏编；电子化流转工作，以提高工作效率，避免零工艺文件集成化编辑环境：在 AO/FO 编制任务页面，可以直接启动 CAPP 编辑器，自动传递相关零信息至 CAPP 中。编辑完成后，可以通过集成接口提交编辑完成的工艺文件至协同研制中进行管理；工艺文件签署及更改管理：实现 AO/FO 的电子化签审及更改流程管理，确保工艺文件的状态可控、可追溯。工艺文件需要具备有效性信息，以实现基于架次的工艺文件管理。2.2.2.3 工装管理流程在中实现工装申请、报废等过程的电子流程化管理，并可以实时查询流程执行状态，提高工装管理流程的执行效率。实施内容如下：工装管理流程：对工装

19、申请、报废、故障请修等过程涉及到的单据进行管理，并对这些单据的流务流程实现电子化的签审管理；工装流程执行：可以对工装上述流程执行状态进行实时、动态，提高工装流程管理的精细化程度。2.2.2.4 工艺协调数据集管理在工艺设计过程中，将产生大量工艺协调中间数据模型，在系统中需要对其进行统一化管理，以方便数据查询和追溯。工艺协调数据集主要包括：工装设计结果、工艺设计数模、NC 代码、装配协调数据集、检验数据集。实现内容包括：数据集基本管理：包括数据集分类、创建及、版本、权限、生命周期、可视化、综合查询、统计汇总等；数据集状态控制：对数据集的电子化签署过程进行有效的管理和控制。其中，电子化签署流程管理

20、可以根据实际需求定义流程模板。2.2.2.5 技术文件管理在 TA600 研制过程中，会产生大量的产品技术文件，需要建立的技术文件管理库对这些文件进行规范化集中管理，支持研制过程中业务对技术文件的维护、查询、分发共享和重用。主要实施内容如下：(1) 技术文件基本管理技术文件基本管理包括技术文件分类、创建及、版本、权限、生命周期、可视化、综合查询、统计汇总等，分别描述如下：分类管理：对技术文件的类型进行整理，确定技术文件的详细分类，如技术规定、计算文件、技术、技术条件、试验文件、设计任务书、文件工程指令等。根据具体的文档类别，定义文档的属性、规划技术文件的位置。其中，文档类型及属性可以根据通飞公

21、司的实际业务需求进行动态扩展。创建及：具有相应权限的业务可以将技术文件创建至中相应的位置，创建过程中，可以选择具体的分类并定义相应的属性，可以添加附件和建立文档之间的关联。系统可以根据文档类别，自动创建至相应的位置。文档创建后，具有权限的业务可对其进行修改、删除、提交电子化签署、作废处理等工作。版本控制：技术文件创建及过程中，系统按照“大版本+小版本”的原则进行版本和控制。其中，大版本代表签署后进行更改产生的新版，小版本则代表修改过程中更新的历史过程。系统默认显示的版本，可查看具体的历史版本。权限控制：可基于文件夹、类别、文档状态、具体文档对象进行静态权限定义，包括修改、修订（换版）、删除、浏

22、览等。也可以定义技术文件在流程控制中的动态权限，即流程执行后，权限将自动收回。生命周期管理：定义文档的生命周期状态，以代表其状态演变的生命周期过程，例如可定义其生命周期状态为：工作中、修改中、签审中、已发布、已作废等。可根据实际需求进行生命周期状态的定制。可视化浏览：系统可以实现与 Office 的集成，并能够将 Office 文档自动转换为PDF 格式的文件，Office/PDF/JPG/TXT 等格式的文件检入系统后，可以基于 Creo View可视化浏览工具进行浏览圈阅，无须再重新至本地用源编辑工具进行打开浏览。综合查询：可以根据技术文件类别、属性等条件进行组合查询，并可以保存常用的查询

23、条件，以提高查询效率。可以将查询结果输出为 Excel 表格。统计汇总：可以根据通飞公司实际需求定义技术文件统计报表，如全机技术文件有效版本目录、全机技术文件汇总目录等。(2) 技术文件编码管理按照技术文件编码管理规范的要求，在系统中实现技术文件的编码自动生成功能。业务可输入技术文件的类别、所属系统、分系统等属性，提交编码申请，编码申请通过后，系统根据编码规则自动生成相应文档编码，业务基于该编码进行技术文件创建及工作。(3) 技术文件签署及更改流程控制对技术文件的电子化签署及更改过程进行有效的管理和控制，在签署及更改过程完成后系统可实现向技术文件的自动电子签名，详细描述如下：电子化签署流程管理

24、：根据实际需求定义技术文件的签署流程模板，工作流程设定中可以提供流程任务之间的前后约束关系，支持分支路由和条件判断，可以根据设定的条件或者事件自动触发或跳转流程，并可以对流程和流程的环节进行说明。工作流的启动可以是手工方式，也可以自动启动。在签署过程中，系统完整地签审过程信息，可以通过签审单实时查看签审进度信息，以便于和追溯。技术文件更改管理：实现技术文件临时更改、正式更改的流程管理，确保技术文件更改前后状态的正确性、有效性和可追溯性。可以方便地根据更改单或临时更改单，对改前和改后的技术文件进行查询，并可以对技术文件更改的情况进行统计汇总。电子化签名：对于 Office 格式的技术文件，签署或

25、更改后可以将签署人的电子签名写入其 PDF 格式的附件中（PDF 为系统自动从Office 转换）。(4) 技术文件分发及归档管理技术文件签署完整后，可以按照分发路线进行分发，并完成向兰台管理信息系统的自动归档，详细描述如下：分发处理：文档提交签署时，可指定分发路线，系统经过签署后，自动将电子文件通过邮件或系统通知发送给相应分发部门的接口人，该接口人可以将其继续分发给部门的相关；归档管理：技术文件签署完整后，系统可以通过与兰台管理信息系统的集成接口将技术文件属性信息和带有电子签名的 PDF 格式的技术文件自动归档至信息系统，以避免信息的重复录入和物理文件的不一致问题。管理2.2.3 与其他应用

26、的集成2.2.3.1 VPM 集成VPM 与 Windchill 需要实现集成，以支持数据向下游制造环节的力包括：。主要集成能设计数据的同步：VPM 中管理的设计数据（主要是 CATIA 3D 模型或 2D 图样），在 VPM 中后，由人工查询提交并同步至协同研制中；设计数据的更改：当更改完成后，由 VPM 将更改单、改前和改后数据同步至协同研制中。实施前提和假设：基于Web Service 技术，采用中间数据库表或 XML 文件方式进行。以上本阶段工作只实现 VPM 向协同研制的单向数据传递。乙方负责集成接口部分涉及协同研制导入部分的方案设计、开发和部署工作。甲方（或甲方协调第）负责集成接口

27、部分涉及 VPM 导出部分的方案设计、开发和部署工作。2.2.3.2 金叶 CAPP 的集成根据通飞公司对 TA600 飞机工艺文件编辑的当前应用定位（未来将逐步实现和三维工艺），暂时由金叶 CAPP 进行工艺文件的编辑，并以二维或二维半（三维工艺简图作为贴图）工艺管理模式为主。工艺文件的、版本、状态、权限等则统一由协同研制进行管控。具体集成能力包括：工艺集成化编辑环境：将工艺编辑任务分工过程与工艺编辑环境启动过程紧密结合起来，当工艺编辑在协同研制中收到工艺文档编辑任务时，系统可以自动启动CAPP 并进行初始化；设计数据传递：协同研制可以将工艺文件编辑所需的设计数据（BOM 等数据）传递至CA

28、PP 编辑环境中，以方便工艺文件的编辑；工艺设计结果传递：工艺文件编辑完成后，选择“提交”，系统自动将工艺文件及其属性结构化信息进行导出，协同研制自动将工艺文件及其属性信息创建至中；工艺文件浏览：通过集成，可以基于协同研制实现工艺文件的可视化浏览。实施前提和假设：基于Web Service 技术，采用中间数据库表或 XML 文件方式进行。以上端 BOM 数据导出、工艺文件检入/更新、乙方负责集成接口部分涉及协同研制工艺文件浏览功能调用等部分的方案设计、开发和部署工作。）负责集成接口部分涉及 CAPP 端 BOM 数据接收、工艺甲方（或甲方协调第文件检入/更新菜单、工艺文件检入/更新功能调用、工

29、艺文件浏览等部分的方案设计、开发和部署工作。2.2.3.3 兰台管理系统集成数据归档过程集成：协同研制基于流程驱制实现数据条目信息和物理文件的提取、导出功能，属性信息导出为 XML 格式。导出后通过Web Service 调用兰台管理系统的接口。兰台管理系统则将物理文件和 XML 格式的属性信息导入至系统的数据库中。归档的数据内容：技术文件的属性信息及其物理文件（带有签名的 PDF 格式文件）将导出给管理系统存档；由于数模数据量大且关联性强，因此只将数模等属性信息传递至管理系统。实施前提和假设：以上采用中间数据库表或 XML 文件方式进行。本接口是协同研制向管理系统的单向数据传递。甲方（或甲方

30、协调第）负责集成接口中管理系统端的方案设计、开发及配置工作。3. 项目实施计划、组织和策略3.1 实施计划本项目预计启动日期为 2014 年 1 月，方案定义、方案开发、部署上线和后续支持的总计实施周期为 9 个月，如果项目启动时间变化，项目节点时间将据此依次顺延。项目实际执行时间表以最终商定的计划为准。每个里程碑完成后，甲方需要在“阶段确认书”中签字确认，作为阶段验收标志。系统交付验收将在试运行期完成后，由甲方召集各应用进行验收。项目实施节点计划如下表所示：3.2 项目组织甲方和乙方将建立一个联合的项目管理，确保通过预定项目流程评估和支持。指导的责任包括：整体项目状态的评估项目实施期间重要问

31、题决策项目管理应在整个项目过程中由个人担任，其成员必须是甲方和乙方各自的代表，有能力决定项目相关问题。项目管理委员将会负责本项目的关键决策，并在必要时尽早做出决定，以便指导项目的正常运行。在此SOW 开始执行之前，甲方需要委派经验丰富的项目经理，负责所有与乙方的项目里程碑实施工作预计 开始时间预计 结束时间里程碑 1：项目启动及方案定义召开项目，进行基础培训、业务调研、方案设计及方案评审工作2014/1/62014/2/28里程碑 2：系统开发配置及测试进行详细设计，实施内容开发、配置及集成测试工作2014/2/172014/4/25里程碑 3：用户测试验证及上线试运行进行用户测试、培训、上线

32、部署及上线试运行2014/4/142014/5/30里程碑 4：系统正式推广及项目结案进行系统正式推广，并提供上线支持，完成项目验收2014/6/22014/9/30交流工作，并在项目各个方面代表甲方。甲方项目经理将与乙方项目经理合作建立项目团队（包括项目管理PMO 和工作组），项目团队需要包括保证项目成功交付的必须角色。有关每个角色的定义及责任请参考附录A。有关于项目管控模型，请参考附录B。3.3 实施策略以下将从产品应用范围、实施目标定义、基础架构、质量管理（测试验证及确认）、推广应用和数据等方面定义甲方系统实施策略。1.应用产品在本期项目范围内，将基于TA600 型号飞机数据进行实施，如

33、下表所示：表：产品概述2.实施基础架构策略在本期项目范围内，将基于以下基础架构进行实施，如下表所示：表：基础架构列表3.实施测试验证及确认策略为了确保系统能够稳定运行，满足既定的各项业务需求，将对系统进行严格的测试验证和确认工作。表：系统测试验证及确认测试类型测试说明测试实施测试基础架构详细说明协同研制 测试服务器乙方负责开发测试环境 Windchill 安装和部署；协同研制 生产服务器乙方将构建一个基于Windchill 10.1 版本的协同研制生产服务器。乙方负责协同研制测试及生产服务器 Windchill 的部署工作，并提供相关的部署文档。地点产品产品概述甲方（市）TA600 型号飞机本

34、期项目中，为满足型号全面试制阶段的业务需求进行实施测试类型测试说明测试实施测试1. 单元测试该测试过程将保证，程序运行和设计规格一致。编制单元测试用例（Use Case）对需求规格要求的各项功能进试。按照用例进行单元测试对代码完成与相关的变更后，需要重新进行单元测试乙方实施顾问2. 集成测试集成测试将进行系统各个开发组件的联调测试，保证各个开发模块的可用性。编制业务场景和测试用例（Use Case）按照业务场景和测试用例，执行集成测试；对代码完成与相关的变更后，需要重新进行集成测试；甲方开发团队乙方实施顾问3. 用户可接受性测试用户可接受性测试将按照实际业务场景，由甲方关键用户进行的可用性测试

35、，保证系统与实际业务方案的一致性，满足实际业务的需求。编制业务场景和测试用例（Use Case）按照业务场景和测试用例，由甲方团队执行完成用户可接受性测试；对代码完成与相关的变更后，需要 重 新 进 行用 户可 接 受 性（UAT）测试；甲方开发团队甲方关键用户乙方业务顾问4. 项目实施方法乙方全球服务部门通过“实现价值”（Realized Value Platform，RVP）实施方法进行项目的实施交付，实现价值包括乙方在项目实施管理、流程、系统实施以及推广应用等层面的内容，以实现本期项目预期目标。项目管理项目初始化和规划本工作的目标是确保项目准备就绪，可以进行项目实施。表：项目活动和交付2

36、.项目执行项目执行包括项目执行过程协调、管理和项目进展状态，以及解决出现的项目问题。表：项目活动和交付3.项目监督及控制本模块用于收集和评价项目的执行状况信息和风险信息，并确定是否需要采取修正或预防行动。项目活动交付责任方集成变更控制变更申请表（如果存在）Change Request Form乙方风险及问题管理风险及问题日志Risk and Ies Log乙方项目活动交付责任方项目协调/团队沟通项目状态Project Sus Report乙方项目执行过程中的修正-预防行动变更申请表（如果存在）Change Request Form风险和问题日志Risk and Ies Log乙方项目活动交付责

37、任方项目管理计划项目管理计划Project Management Plan乙方项目实施计划项目实施计划Project Schedule乙方4.项目结案项目结案包括：核实项目的交付是否满足了工作说明书的要求，是否正确归档了项目文件。并进行项目总结，完成乙方结案行活动及项目结案审计。在管理结案阶段，举行结案会议，存档项目和文件。在合同结案时，获得甲方在项目结案上的签字，表明所有交付已经完成，并与工作说明书（SOW）一致。4.2 应用设计应用设计工作包括获取、分析和确定甲方的业务需求，评估甲方现有业务流程，设计满足项目目标的业务流程、最佳实践的相关活动。同时基于业务设计方案，完成系统设计工作。1.业

38、务设计：业务流程分析和设计该工作用于保证甲方的业务流程的成功优化，以及准确定义应用开发框架。2.系统设计：应用和实践设计定义和设计系统中的客制化组件。4.3 应用开发应用开发包括代码开发和技术管理。1.开发开发涉及到相关组件设计定制代码的开发和配置。开发的目标是交付满足需求的可执行。项目活动交付责任方定制组件开发部署组件及安装及配置说明DeployableComponentandInstallation&乙方项目活动交付责任方定制组件设计系统设计文档System Design乙方项目活动交付责任方流程分析/流程设计未来流程描述和实践设计Future Pros Description and P

39、ractice Design乙方项目活动交付责任方管理结案存档项目和文件Archived Project Item ands乙方/甲方合同结案签署的结案文件Signed Closure乙方/甲方2.技术管理通过技术管理，对开发活动中参与团队、输出代码进行有效管理，保证系统的有效配置管理。对代码应采用通用的配置管理工具进行管理，以便追溯。4.4 质量管理通过对于的测试验证，确保通过测试成果的目标满足甲方的需求。质量保证1.制定测试计划、提供测试数据、配置测试环境、编写测试，并进试验证的工作，并编写测试。4.5 系统部署系统架构包括支持系统实施所需要的设置、配置和管理工作。1.系统部署规划规划定义

40、系统部署的目标、关键要素和部署步骤任务，并制定部署计划。2.系统架构设置系统架构设置包括乙方相关及所需要的第的安装、配置。在本项目中，将完成测试系统及生产系统的部署工作。项目活动交付责任方部署计划系统部署计划Deployment Schedule乙方项目活动交付责任方测试计划方案测试计划Solution Test Plan乙方测试用例开发测试用例Test Case乙方/甲方提供测试数据测试数据Test Data甲方测试执行测试Test Report乙方/甲方项目活动交付责任方技术团队管理无乙方/甲方Build 管理Build及部署步骤管理文档 Build and Deployment Proc

41、edure乙方配置管理无甲方Configuration Instructions项目活动交付责任方Windchill 服务器配置安装及配置文件Installation and Configuration乙方5. 前提条件和假定本工作说明书基于下列假定。在本项目的实施过程中，如果实际情况与以下假定不同，则双方项目经理友好协商解决。必要，则启用项目变更控制流程。5.1 一般假定1.此工作说明书经甲方和乙方签字认可后，将取代有关本项目以前任何口头和书面的承诺。2.本项目实施将基于本文要求和Windchill已有的缺省(Out Of The Box，OOTB)功能。如系统功能与期望有较大的出入，由双方

42、项目经理商量后决定是否提请变更。3.实施所涉及的业务管理事项，乙方提供详细技术方案建议，甲方需要及时做出决策，以保证项目的如期执行。4.甲方需要在方案定义阶段开始进行相关规范标准的规划和编制工作。为保证项目实施内容的推广应用，甲方需要基于评审通过的业务解决方案，编制相关的业务规范，并在系统正式部署之前就绪。5.部分实施工作，需要相关业务/部门及第供应商的支持和协助，甲方需要完成相关的沟通和协调工作，以保证在规定的实施周期内完成该项目的实施工作。任何可能影响项目计划的非乙方的应由甲方控制和管理。6.本期项目实施将会基于 Windchill 10.1版本进行实施，方案设计、代码开发和系统部署都将基

43、于该版本进行，Windchill 的后续升级不列入本期项目实施的范畴。7.乙方在项目实施期间使用甲方的现有、程序、资料或应用时，应得到甲方的，遵循甲方的相关规章、制度和条例。5.2 硬件和1.硬件、的成本及其、交付和安装不属于本工作说明书的范围。由于本项目的顺利实施需要依赖甲方方面现成的硬件和条件。甲方应及时提供实项目所需要的硬件和条件，包括：硬件服务器，Windchill 安装和配置指南中要求的证，所需要的第应用的所有版本，及要求与此相兼容的第应用。乙方不对甲方因知识产生的任何法律纠纷负责或承担连带责任。2.甲方的网络和硬件环境应能满足详细技术方案实际运行的要求，对由于网络或硬件不能到位或其

44、它甲方，引起的项目延期或需求变更，需双方根据本文规定的变更程序，友好协商后决定处理办法。3.在项目开始之前，甲方应负责维持一种与其实际生产环境区分开来、能充分代表甲方所希望达到的目标生产环境的开发及测试环境。硬件和操作系统的安装、支持和管理由甲方团队完成。5.3 实施场地1.2.项目方案定义工作，可在甲方或乙方现场完成。项目开发及单元测试工作可在甲方或乙方现场完成，集成测试、用户可接受性测试在甲方现场完成。3.项目实施培训工作在甲方现场完成。5.4 项目资源和进度管理1.乙方及甲方组成合作团队，双方应根据本工作说明书中所约定的内容完成各自的任务、承担各自的责任，密切配合、协调工作。2.培训材料

45、准备及用户培训由甲方负责完成。在项目规划阶段，双方需要明确参与项目的、角色。对于乙方实施的3.短期或长期变动，需要通知甲方项目经理。4.乙方所有的项目交付文档将基于中文格式提交，甲方对于乙方提交的正式交付，需要在 5 个工作日内给出反馈建议。对于已批准交付的任何更改，将视为项目变更，通过项目变更控制流程处理。6. 项目验收标准和流程甲方需要对于本SOW 中规定的每个里程碑进行验收，每个里程碑验收合格则标志着该阶段工作的成功完成并意味着下一里程碑工作可以启动。每个里程碑验收完成后，甲方需要在阶段确认书（参见附录 C）中签字确认，作为阶段验收标志。以下为每个里程碑的验收标准：里程碑 2：系统开发及

46、配置预计完成日期项目起始日 + 10 个工作周实施内容项目执行、监督与控制技术管理应用开发系统部署（测试系统）集成测试验证里程碑 1：项目启动及方案定义预计完成日期项目起始日 + 7 个工作周实施内容项目初始化项目执行、监督与控制业务设计：业务方案设计系统设计：系统方案设计交付项目实施计划Project Schedule业务方案Future Pros Description and Practice Design系统方案System Design验收标准列举在阶段确认交付内容(a) 已交付并被接受；(b) 已交付但被有条件接受；或者(c) 甲方放弃。对已交付文档的验收标准：经甲方签署上述交付文

47、档和阶段确认书以验收这些交付成果验收者甲方项目经理投入百分比30%里程碑 4：系统正式推广及项目结案预计完成日期项目起始日 + 18 个工作周实施内容项目执行、监督与控制系统运行支持里程碑 3：用户测试验证及上线试运行预计完成日期项目起始日 + 7 个工作周实施内容项目执行、监督与控制用户测试验证系统部署（生产系统）上线试运行支持交付测试用例Test Case测试Test Case生产系统部署文档Production System Installation and Configuration验收标准列举在阶段确认交付内容(b) 已交付并被接受；(b) 已交付但被有条件接受；或者(c) 甲方放弃

48、。对已交付文档的验收标准：甲方签署上述交付文档和阶段确认书以验收这些交付成果验收者甲方项目经理投入百分比20%交付开发代码包Code Package客制化代码部署指导手册Customization CodeDeployment验收标准列举在阶段确认交付内容(a) 已交付并被接受；(b) 已交付但被有条件接受；或者(c) 甲方放弃。对已交付文档的验收标准：甲方签署上述交付文档和阶段确认书以验收这些交付成果验收者甲方项目经理投入百分比30%3.项目结案交付问题及解决日志Ie Log项目移交Customer Handover Checklist项目总结Project Closure验收标准列举在阶段

49、确认交付内容(a) 已交付并被接受；(b) 已交付但被有条件接受；或者(c) 甲方放弃。对已交付文档的验收标准：经甲方验收评审通过后，签署上述交付文档和阶段确认书以验收这些交付成果对生产环境的验收标准：验收生产环境旨在验证能否安装以及所有基础功能的运行是否正常。当达到下列标准时，生产环境就可算是通过验收。无阻碍业务流程的故障验收者甲方项目经理投入百分比20%7.和付款条件对于本工作说明书中规定的实施内容（详细参考本工作说明书第 2 章节），以固定价格方式执行。甲方理解报价是以本工作说明书中所描述的要求、职责、假设、交付和活动为基础。根据合同规定，对于本工作说明书的改动，经双方另行协商决定是否需

50、要对和日程表进行调整。甲方未签名接收，本工作说明书 30 天后失效。8. 项目变更项目的启动以本工作说明书所描述的内容为开发前提，大量或频繁的项目变更会导致项目无法按时完成。原则上在项目实施过程中，各阶段达成后的内容不再容许变更。任何变更都必须经双方认可后方可执行。8.1 项目变更控制流程凡是对已经确认的工作范围、项目计划、设计方案、项目成果的变更，均称之为项目变更。当更改对本文档实施范围、进度或职责的实质性变更的情况下，必须采用项目变更控制流程中的描述。乙方尝试在本工作说明书中提供足够的细节以清楚地描述本项目中包括及不包括的范围。乙方也尝试在本工作说明书中包含所有目前已知的需求。然而，随着项

51、目的进行，乙方和甲方可能需要用额外的信息补充本工作说明书。项目变更需要甲方和乙方共同签署才能将修改并添加到本工作说明书。项目变更控制流程定义如下：任何对已同意的实施范围的变更或与该范围的偏离，或对本工作说明书中同意的时间或费用的变更都将遵循项目变更控制流程。无论何时，在需要变更而该变更将影响工作合同（如日程表、功能或费用）时，乙方或甲方都可以提出变更的要求同意变更意味着同意一个关于总体的费用、范围和进度的变更。提出变更需首先填写变更申请表（REQUEST FOR CHANGE，以下简称 RFC）。RFC组成的评审小组。评审小组将就 RFC 的技术可靠性以及对整需提交由甲方和乙方个项目的影响作出

52、评估。经批准的 RFC 将转给乙方，未被批准的 RFC 将退还给提出变更的本人。双方需要对变更可能对、进度、资源等造成的影响进行评估、批准和存档，并决定是否需提交双方进行批准。其中凡涉及到整个项目进展，费用成本调整较大的变更，必须交由双方批准通过。变更批准后，甲方和乙方需要按照变更对项目、进度、资源的影响调整相应计划，并指定相应执行变更。并指定相应、整个变更的过程，并对变更执行的结果进行验收、上报和存档。项目变更控制流程基本描述如下:甲方或乙方任何一方均可以提出RFC将RFC 提交评审小组作技术可行性评定乙方以形式接受RFC 并给出PCP 的准备时间和所需费用4.评审小组乙方时间和费用以及是否

53、批准RFC并确认所需费用和进度5.乙方负责做出项目变更6.评审小组项目变更并提出实施建议甲方对项目变更更具项目变更提出认可，并同意乙方对合同进行变更的内容，变更内容。8.2 项目变更乙方职责乙方将在接到 RFC 的 10 天内给出收讫说明以及分析 RFC 所需的时间，做出相应。乙方可对 RFC 分析标准，乙方将于甲方同意的项目变更以及项目变更进行并以形标准后 10 天内或规定时间内，对 RFC 进式告知甲方行研究并做相应的项目变更。乙方项目经理需要：建议的变更对于范围、进度和费用的影响。1.评价不做变更会产生的影响。2.准备对该变更的响应。3.如果就采用该项变更达成一致，获取RFC 需要的签名

54、。如果不同意该项变更：4.5.乙方项目经理将与甲方项目经理进行并将意见存档。可能，该建议的变更将被重新；或者收回该变更建议。在这些情况下，相应的原因应该写在RFC 上并归档。8.3 项目变更甲方职责本协议有关费用或进展的变更，需由甲方的代表以形式提出并批准。批准后的项目变更内容将列入本工作说明书。如果该变更需要额外的，甲方必须保证在变更开始前获得。附录A：甲方职责在项目开始实施前，建议甲方成立专职的实施团队，并分配以下角色：项目经理在开始本工作说明书前，甲方应任命一名项目经理。与乙方的所有沟通都将通过该项目经理来完成，而且该项目经理应就本项目中的各个方面都做出反应，包括与甲方项目组协调，根据全

55、球服务协议管理特殊变更，签署所有项目的交付。甲方项目经理需要在项目的进展过程中全程参与。Windchill 系统管理员系统管理员负责系统的运行、和管理，包括用户与团队的管理，系统安全，故障维修，系统的，安装和备份。该管理员在本工作说明书的进展过程中将以半职参与项目。Windchill 系统开发系统开发接受系统开发培训，管理客制化代码，并全程参与开发过程。并在项目结束后，具备面向系统需求调整的代码开发能力。进而建立甲方系统的技术支撑体系。对于每个模块的开发代码，都需要由专门的开发负责。业务流程对乙方在特殊业务流程或流程组中遇到进行指导。担任此角色的人能对现有的流程提供准确的信息，并能定义未来流程

56、的需求。作为顾问，他们能指导变更管理问题，如将组织转换到新流程。对于特殊的流程，业务流程不是必须设置的，而对于在其权限内的一些决策，必须有业务流程参与。表：以下角色说明了项目计划的甲方资源甲方角色角色参与阶段项目经理所有阶段Windchill 系统管理员所有阶段Windchill 系统开发所有阶段业务流程所有阶段附录B：项目管控模型以下是一个的项目管控模型，标识了实施项目的项目组织架构。（Executive Steering Committee）项目管理定期或按需召开项目管理会议，听取项目汇报，指导项目方向，决策项目变更。甲方乙方业务部门销售部门管理部门全球服务部门IT 部门乙方提供的角色如下

57、表所示：乙方角色乙方 角色职责项目经理负责项目计划、项目、资源分配，以及时间、程序问题的解决，并负责与甲方的日常沟通和交流。业务顾问准备调研提纲，对业务部门进行业务访谈，对业务流程现状进行分析，协助甲方定义未来业务流程，并定义业务解决方案。系统架构顾问提供系统架构的设计和技术规格的定义实施顾问负责安装与配置系统、代码开发、测试、调试、技术实施和支持工作，并负责技术方面的培训工作。培训顾问完成标准培训课程的培训工作，对需要的开发课程进行课件定义，并培训。工作团队业务流程组技术开发组系统架构组推广应用组甲方团队乙方团队甲方团队乙方团队甲方团队乙方团队甲方团队乙方团队项目管理（PMO）定期或按需召开项目管控会议，组织项目例会，协调项目事宜会议监督项目，解决问题并确定要提交甲方乙方甲方项目经理乙方项目经理附录 C：阶段确认书模板( Template oftone)- PTC Proprietary完成确认书 Completion 阶段确认