1、金航数码科技有限责任公司中航工业通飞TA600数字化协同研制平台一期实施技术服务协议（固定价格工作说明书）日期：2014年1月4日版本：V3.0金航数码科技有限责任公司（“金航数码”，以下简称“甲方”）和参数技术（上海）软件有限公司（“PTSH”，以下简称“乙方”）一致同意，有关本文所述服务的完整协议由这份工作确认书（“SOW”）和PTSH与金航数码间签署的服务合作伙伴协议（“SPA”）两部分共同组成。若SOW与SPA间存在异议，则以本SOW条款为准。PTSH在收到来自金航数码的订单后，将开始执行此工作确认书。签字：金航数码科技有限责任公司 日期：参数技术（上海）软件有限公司全球服务部项目代表2、 日期：文档属性文件名称状态通飞TA600数据化协同研制平台SOW_V3.0_CN.docx变更记录日期作者版本描述2013-12-16吕维瑛V1.0初稿，依照项目建设建议方案编制2013-12-27吕维瑛V2.0修正稿2014-1-4吕维瑛V3.0修正稿审核者姓名职务TA600数字化协同研制平台一期项目技术服务协议（工作说明书）目 录1.项目实施概述12.项目实施内容22.1项目目标及应用范围22.1.1项目目标22.1.2项目应用范围32.2项目实施内容32.2.1设计制造协同环境32.2.2制造协同管理环境52.2.3与其他应用的集成113.项目实施计划、组织和策略143.1实施计划143、3.2项目组织143.3实施策略154.项目实施方法174.1项目管理174.2应用设计184.3应用开发184.4质量管理194.5系统部署195.前提条件和假定215.1一般假定215.2硬件和软件215.3实施场地225.4项目资源和进度管理226.项目验收标准和流程237.收费和付款条件268.项目变更278.1项目变更控制流程278.2项目变更乙方职责288.3项目变更甲方职责28附录A：甲方职责29附录B：项目管控模型30附录C：阶段确认书模板( TEMPLATE OF MILESTONE CERTIFICATE)31附录D：授权签署阶段确认书名单32TA600数字化协同研制平台一4、期项目技术服务协议（工作说明书）1. 项目实施概述兹有甲方委托乙方进行“TA600数字化协同研制平台一期项目”的实施。经双方友好协商，达成以下技术协议：作为国务院、国防科工局、财政部、工业和信息化部等部门联合批准立项的国家重大项目和国家应急救援能力建设的重要内容之一，“蛟龙-600”（以下简称“TA600”）型飞机是单船身四发涡轮螺旋桨式综合救援飞机，将成为世界上最大的一款水陆两用飞机之一。TA600的研制将按照“水陆两栖、一机多型、系列发展”的设计思想，在满足森林灭火和水上救援要求的同时，兼顾海洋环境监测和保护及远程货物运输等用途，飞机总体技术水平和性能将达到当前国际同类飞机的先进水平。通过5、项目研制，能够填补我国大型水陆两栖飞机的研制空白，形成具有自主知识产权的设计研发体系，提升我国水面飞行器的设计制造能力和产业化能力。TA600型号复杂、研制时间紧迫、任务艰巨、风险性大，为了确保研制目标节点，必须利用航空工业的整体优势，在机制、管理和技术上进行创新，充分借鉴国外飞机先进研制的经验，更深入全面地采用数字化设计、制造、管理技术，建立数字化协同研制环境，使数字化协同研制技术在型号研制应用中发挥最大的信息平台支撑作用。考虑到型号研制进度的要求，本期项目将面向TA600型号的全面试制阶段。乙方注意到甲方以上各方面的具体需求，经双方友好协商，达成以下技术协议。甲方和乙方需要共同召开一次实施6、前的会议，进行实施的各项准备工作，并定义初步的实施计划。通常乙方全球服务团队将在收到订单的2周内开始履行此合约。2. 项目实施内容2.1 项目目标及应用范围2.1.1 项目目标根据目前TA600研制的迫切需求，本期项目建设内容将重点支撑TA600全面试制阶段的主要业务。该期项目的目标设定如下：通过本期项目建设，建立TA600数字化协同研制平台的基础框架，重点面向华南公司，搭建设计制造协同环境、制造协同管理环境，实现设计制造的一体化及相关数据的统一化管理，并确保协同和管理过程中的构型状态正确、有效，为TA600全面试制阶段的业务提供最大化支撑。根据以上建设目标，本期项目的具体建设内容包括：(1)7、 设计制造协同环境l EBOM数据接收与分发l 工程更改贯彻l 技术协调单管理l 现场单据管理(2) 制造协同管理环境l PBOM/MBOM管理l 工艺文件管理l 工装管理流程l 工艺协调数据集管理l 技术文件管理（含设计和制造）(3) 与其他应用的集成l VPM集成l 金叶CAPP的集成l 兰台档案管理系统集成2.1.2 项目应用范围l 一期项目的应用范围：通飞研究院、华南公司。其中，通飞研究院利用该平台进行EBOM设计数据发送（含更改单及更改数据发送）、技术协调、现场单据协同等；华南公司以该平台作为TA600型号的制造管理平台进行与设计的协同、PBOM/MBOM管理、工艺数据管理、工装管理8、流程等。 l 一期项目的数据范围：TA600型号的详细设计数据（含更改单等）、工艺文件、工艺协调数据集、技术文件（设计及制造端）、现场单据（代料单、不合格问题审理单、重量超差单、工艺偏离单）等。2.2 项目实施内容乙方将以本技术协议定义的工作范围为依据，针对甲方数字化协同研制平台本期实施内容，进行与TA600型号相关的业务方案定义、方案开发、系统部署和上线支持工作。下面对各项内容的实施范围和具体要求进行描述。2.2.1 设计制造协同环境2.2.1.1 EBOM数据接收及分发本期项目中将通过与VPM系统的集成实现EBOM数据的接收以及EBOM产品结构和有效性信息在Windchill系统中的重现。9、实现内容包括：l EBOM数据接收：在制造端，通过数据发放接收流程进行设计数据的接收，并重现EBOM。该流程可以设定为：数据发放前，由通飞研究院设计人员在Windchill协同研制平台中创建数据发送单并通过流程通知华南公司数据接收人员进行数据预览，确认后由系统集成接口将VPM中的数据同步至Windchill协同研制平台中。VPM系统中定义的工艺预分工信息也通过集成接口导入至Windchill系统中。l 设计数据内部二次分发：确认接收设计数据后，制造端可以通过流程进行数据的二次分发，分发可以根据内部分发路线进行流程驱动的自动分发，各个环节的数据接收人员还可以继续分发给本部门的其他相关人员。2.210、.1.2 工程更改贯彻为了确保设计更改在制造相应的业务部门得到贯彻和落实，例如设计更改导致的工艺、工装等方面的更改，在平台中应实现设计更改的闭环管理。在平台中将通过对设计更改指令的贯彻管理，落实设计更改引起的工艺、工装等环节的工程更改闭环管理。实施内容包括：l 闭环更改流程管理：建立闭环更改流程，确保发生设计更改时，相关的工艺、工装等更改都得到了落实，实现更改归零管理；l 闭环更改过程实时监控：可以对设计更改的贯彻落实情况进行实时动态统计，方便质量管理人员监督更改执行的闭环。2.2.1.3 技术协调单管理在华南公司进行生产准备的过程中，需要大量的技术协调工作，这些协调工作包括华南公司内部的技术11、协调以及华南公司与通飞研究院的技术协调。从规范化技术协调单管理，确保技术协调过程闭环和可追溯的角度出发，需要对技术协调单及其协调过程进行统一化管理。实施内容如下：l 技术协调单管理：实现技术协调单的创建及维护管理，技术协调单创建后系统可以自动启动技术协调过程，并由创建人员指定协调接口人进行答复。l 技术协调过程管理：通过流程对技术协调过程及答复过程进行管理，根据实际协调流程进行系统定制。l 技术协调过程监控：对技术协调单及其行动项状态进行动态监控，并可以输出为报表。2.2.1.4 现场单据管理对生产现场相关数据及工作流程进行管理、控制、追踪等。包括对代料单、不合格问题审理单、重量超差单、工艺偏12、离单等数据及相关处理流程的管理。此外，对各种试制现场问题的处理过程进行记录，以便于以后的追溯，同时提供各种统计汇总的能力。实施内容包括：l 单据结构化管理：提供单据的结构化录入、查询和管理界面，能够输出Word格式的文件，并支持这些单据结构化信息的导出、导入，以实现与其他协作单位之间的交互；l 单据流程管理：实现单据处理过程的管理，能够对处理过程、处理状态和处理结果进行实时监控和过程追溯；l 单据统计报表：提供各种统计汇总的能力，可以按照单据类型、处理日期、处理状态、处理单位等进行统计汇总，并可以按照指定格式输出为Excel等文档。2.2.2 制造协同管理环境2.2.2.1 PBOM/MBOM13、管理(1) PBOM的建立和管理PBOM数据的主要信息包括：面向工艺计划、工艺路线和工艺分工的产品结构；产品结构中的属性信息（例如零件版本、组别等）；产品结构中零部件的有效性信息及装配关系属性信息（例如数量、单位、工艺路线、成套件号、工艺路线备注等）；产品结构中各部件关联的工艺计划资料更改单、工艺计划等；产品结构中各部件对应的更改信息（包括更改单、更改指令、更改流程记录等）。基于EBOM，可以进行PBOM的重构和管理，其实施内容包括：l PBOM重构：支持基于EBOM进行PBOM的重构，即在结构中增加工艺组合件等；添加工艺路线、制造属性（成套件编号、制造商信息等）等，从而形成完整的PBOM；可14、以不基于EBOM进行PBOM构建，支持EBOM与PBOM的对比；l PBOM签审及更改流程管理：可以基于PBOM中的某一节点，对PBOM进行电子化签审，系统根据模版驱动各个流程环节，PBOM签署完成后，其状态将固化。如要修改，需要启动更改流程。(2) MBOM的建立和管理MBOM数据信息主要包括：产品结构中的属性信息（例如工位、相关分厂等）；产品结构中零部件的有效性信息及装配关系属性信息（例如数量、单位等）；产品结构中各部件关联的试飞工艺指令、交接情况单、样板订货单、AO/TO/FO、工艺规程、拒收审理单及其它相关文档；产品结构中各部件对应的更改信息（包括更改单、更改指令、更改流程记录等）。对15、于装配车间来说，通过平台收到PBOM中本车间负责装配的组件、部件，还需根据部件的装配情况确定某一个部件下的工艺组件，划分出工艺组件中包含的零组件，再编制AO、交接单等工艺文件。在平台中，工艺组件以及工艺组件与所包含零组件之间的结构关系可以在PBOM产品结构基础上重构建立，工艺大组件及其包括的零组件装配关系建立以后，全机底层部件级MBOM产品结构也就建立了。实施内容如下：l MBOM的建立：可采用自顶向下设计和自底向上设计两种模式。根据珠海公司业务情况，MBOM的顶层结构在确定工艺总方案和进行AO规划时即可确定下来，MBOM底层产品结构在编写AO等工艺文件时建立。这样经过自顶向下和自底向上的迭代16、和递归，全机MBOM的产品结构也就建立了。平台提供MBOM顶层结构数据导入工具，将MBOM顶层产品结构信息按照模版（Excel格式）收集完成以后，导入至协同平台中。对于导入系统的MBOM数据，应该在数据文件完成审核后，再由系统执行导入，以加强对导入过程的控制；l 基于MBOM的AO/FO关联管理：通过与CAPP集成，可以将AO/FO等工艺文档与MBOM建立关联关系，由MBOM进行统一的、层次化的工艺设计结果的组织和管理；l MBOM签审及更改流程管理：可以基于MBOM中的某一节点，对MBOM及其相关数据进行电子化签审，系统根据模版驱动各个流程环节，MBOM签署完成后，其状态将固化。如要修改，需17、要启动更改流程。(3) 有效性管理与设计端基于架次的有效性信息保持一致，构建制造端的架次有效性管理及应用模式。具体实施内容包括：l 有效性标识：在PBOM/MBOM产品结构中，能够基于有效性管理要求，对PBOM/MBOM的有效性进行标识，确保EBOM/PBOM/MBOM中相同零部件在同一架次中的有效性信息的一致性；l 有效性更改：设计更改引起的有效性调整应进行PBOM/MBOM的有效性调整贯彻，制造端的更改引起的有效性变化应在制造端的更改管理流程中进行控制；l 基于有效性的过滤：能够基于架次信息对PBOM/MBOM数据进行过滤和浏览。(4) 统计报表在各相关业务部门编制工艺文件、组织生产制造等18、过程中，需要使用到各种统计报表。协同研制平台应提供生成工艺、制造所需要的各种统计报表的能力。这些统计报表主要有：l EBOM/PBOM/MBOM差异性报告l 基于PBOM分工路线的车间零件清单l MBOM（部组件、架次、版次、路线、材料等信息可选择性导出报表）l 标准件汇总报表l 工艺装备清单l 工具清单l 装配指令（AO）清单l 零件制造指令（FO）清单l 成品汇总报表2.2.2.2 工艺文件管理TA600数字化协同研制平台将对工艺部门编制的AO、FO等工艺文件进行统一的管理和控制，并可以自动根据AO的零件清册生成MBOM中AO件下的零件，实现与MBOM的有效结合。主要实施内容如下：l 工艺19、文件编制分工：根据零部件的工艺路线自动进行AO/FO分工，并通过分工流程，实现AO/FO编制任务从工艺管理室到车间工艺室主任，再到车间工艺员的分工电子化流转工作，以提高工作效率，避免零部件AO/FO的漏编；l 工艺文件集成化编辑环境：在AO/FO编制任务页面，可以直接启动CAPP编辑器，平台自动传递相关零部件信息至CAPP中。编辑完成后，可以通过集成接口提交编辑完成的工艺文件至协同研制平台中进行统一管理；l 工艺文件签署及更改管理：实现AO/FO的电子化签审及更改流程管理，确保工艺文件的状态可控、可追溯。工艺文件需要具备有效性信息，以实现基于架次的工艺文件管理。2.2.2.3 工装管理流程在平20、台中实现工装申请、报废等过程的电子流程化管理，并可以实时查询流程执行状态，提高工装管理流程的执行效率。实施内容如下：l 工装管理流程：对工装申请、报废、故障请修等过程涉及到的单据进行管理，并对这些单据的流转业务流程实现电子化的签审管理；l 工装流程执行监控：可以对工装上述流程执行状态进行实时、动态监控，提高工装流程管理的精细化程度。2.2.2.4 工艺协调数据集管理在工艺设计过程中，将产生大量工艺协调中间数据模型，在系统中需要对其进行统一化管理，以方便数据查询和追溯。工艺协调数据集主要包括：工装设计结果、工艺设计数模、NC代码、装配协调数据集、检验数据集。实现内容包括：l 数据集基本管理：包括21、数据集分类、创建及维护、版本、权限、生命周期、可视化、综合查询、统计汇总等；l 数据集状态控制：对数据集的电子化签署过程进行有效的管理和控制。其中，电子化签署流程管理可以根据实际需求定义流程模板。2.2.2.5 技术文件管理在TA600研制过程中，会产生大量的产品技术文件，需要建立统一的技术文件管理库对这些文件进行规范化集中管理，支持研制过程中各部门业务人员对技术文件的维护、查询、分发共享和重用。主要实施内容如下：(1) 技术文件基本管理技术文件基本管理包括技术文件分类、创建及维护、版本、权限、生命周期、可视化、综合查询、统计汇总等，分别描述如下：l 分类管理：对技术文件的类型进行整理，确定技22、术文件的详细分类，如技术规定、计算文件、技术报告、技术条件、试验文件、设计任务书、文件工程指令等。根据具体的文档类别，定义文档的属性、规划技术文件的存储位置。其中，文档类型及属性可以根据通飞公司的实际业务需求进行动态扩展。l 创建及维护：具有相应权限的业务人员可以将技术文件创建至平台中相应的存储位置，创建过程中，可以选择具体的分类并定义相应的属性，可以添加附件和建立文档之间的关联。系统可以根据文档类别，自动创建至相应的存储位置。文档创建后，具有权限的业务人员可对其进行修改、删除、提交电子化签署、作废处理等维护工作。l 版本控制：技术文件创建及维护过程中，系统按照“大版本+小版本”的原则进行版本23、记录和控制。其中，大版本代表签署后进行更改产生的新版，小版本则代表修改过程中更新的历史过程。系统默认显示最新的版本，可查看具体的历史版本。l 权限控制：可基于文件夹、类别、文档状态、具体文档对象进行静态权限定义，包括修改、修订（换版）、删除、浏览等。也可以定义技术文件在流程控制中的动态权限，即流程执行后，权限将自动收回。l 生命周期管理：定义文档的生命周期状态，以代表其状态演变的生命周期过程，例如可定义其生命周期状态为：工作中、修改中、签审中、已发布、已作废等。可根据实际需求进行生命周期状态的定制。l 可视化浏览：系统可以实现与Office的集成，并能够将Office文档自动转换为PDF格式的24、文件，Office/PDF/JPG/TXT等格式的文件检入系统后，可以基于Creo View可视化浏览工具进行浏览圈阅，无须再重新下载至本地用源编辑工具进行打开浏览。l 综合查询：可以根据技术文件类别、属性等条件进行组合查询，并可以保存常用的查询条件，以提高查询效率。可以将查询结果清单输出为Excel表格。l 统计汇总：可以根据通飞公司实际需求定义技术文件统计报表，如全机技术文件最新有效版本目录、全机技术文件汇总目录等。(2) 技术文件编码管理按照技术文件编码管理规范的要求，在系统中实现技术文件的编码自动生成功能。业务人员可输入技术文件的类别、所属系统、分系统等属性，提交编码申请，编码申请通过25、后，系统根据编码规则自动生成相应文档编码，业务人员基于该编码进行技术文件创建及维护工作。(3) 技术文件签署及更改流程控制对技术文件的电子化签署及更改过程进行有效的管理和控制，在签署及更改过程完成后系统可实现向技术文件的自动电子签名，详细描述如下：l 电子化签署流程管理：根据实际需求定义技术文件的签署流程模板，工作流程设定中可以提供流程任务之间的前后约束关系，支持分支路由和条件判断，可以根据设定的条件或者事件自动触发或跳转流程，并可以对流程和流程的环节进行说明。工作流的启动可以是手工方式，也可以自动启动。在签署过程中，系统完整地记录签审过程信息，可以通过签审单实时查看签审进度信息，以便于跟踪和26、追溯。l 技术文件更改管理：实现技术文件临时更改、正式更改的流程管理，确保技术文件更改前后状态的正确性、有效性和可追溯性。可以方便地根据更改单或临时更改单，对改前和改后的技术文件进行查询，并可以对技术文件更改的情况进行统计汇总。l 电子化签名：对于Office格式的技术文件，签署或更改后可以将签署人的电子签名写入其PDF格式的附件中（PDF为系统自动从Office转换）。(4) 技术文件分发及归档管理技术文件签署完整后，可以按照分发路线进行内部分发，并完成向兰台档案管理信息系统的自动归档，详细描述如下：l 内部分发处理：文档提交签署时，可指定内部分发路线，系统经过签署后，自动将电子文件通过邮件27、或系统通知发送给相应分发部门的接口人，该接口人可以将其继续分发给部门内部的相关人员；l 归档管理：技术文件签署完整后，系统可以通过与兰台档案管理信息系统的集成接口将技术文件属性信息和带有电子签名的PDF格式的技术文件自动归档至档案管理信息系统，以避免信息的重复录入和物理文件的不一致问题。2.2.3 与其他应用的集成2.2.3.1 VPM集成VPM与Windchill需要实现集成，以支持数据向下游制造环节的发放。主要集成能力包括：l 设计数据的同步：VPM中管理的设计数据（主要是CATIA 3D模型或2D图样），在VPM中审批后，由人工查询提交并同步至协同研制平台中；l 设计数据的更改：当更改完28、成后，由VPM将更改单、改前和改后数据同步至协同研制平台中。实施前提和假设：l 以上数据交换基于Web Service技术，采用中间数据库表或XML文件方式进行。l 本阶段工作只实现VPM向协同研制平台的单向数据传递。l 乙方负责集成接口部分涉及协同研制平台导入部分的方案设计、开发和部署工作。l 甲方（或甲方协调第三方）负责集成接口部分涉及VPM导出部分的方案设计、开发和部署工作。2.2.3.2 金叶CAPP的集成根据通飞公司对TA600飞机工艺文件编辑的当前应用定位（未来将逐步实现平台一体化和三维工艺），暂时由金叶CAPP进行工艺文件的编辑，并以二维或二维半（三维工艺简图作为贴图）工艺管理模29、式为主。工艺文件的存储、版本、状态、权限等则统一由协同研制平台进行管控。具体集成能力包括：l 工艺集成化编辑环境：将工艺编辑任务分工过程与工艺编辑环境启动过程紧密结合起来，当工艺编辑人员在协同研制平台中收到工艺文档编辑任务时，系统可以自动启动CAPP并进行初始化；l 设计数据传递：协同研制平台可以将工艺文件编辑所需的设计数据（BOM等数据）传递至CAPP编辑环境中，以方便工艺文件的编辑；l 工艺设计结果传递：工艺文件编辑完成后，选择“提交”，系统后台自动将工艺文件及其属性结构化信息进行导出，协同研制平台自动将工艺文件及其属性信息创建至平台中；l 工艺文件在线浏览：通过集成，可以基于协同研制平台30、实现工艺文件的在线可视化浏览。实施前提和假设：l 以上数据交换基于Web Service技术，采用中间数据库表或XML文件方式进行。l 乙方负责集成接口部分涉及协同研制平台端BOM数据导出、工艺文件检入/更新、工艺文件浏览功能调用等部分的方案设计、开发和部署工作。l 甲方（或甲方协调第三方）负责集成接口部分涉及CAPP端BOM数据接收、工艺文件检入/更新菜单、工艺文件检入/更新功能调用、工艺文件浏览等部分的方案设计、开发和部署工作。2.2.3.3 兰台档案管理系统集成l 数据归档过程集成：协同研制平台基于流程驱动机制实现数据条目信息和物理文件的提取、导出功能，属性信息导出为XML格式。导出后通31、过Web Service调用兰台档案管理系统的接口。兰台档案管理系统则将物理文件和XML格式的属性信息导入至档案系统的数据库中。l 归档的数据内容：技术文件的属性信息及其物理文件（带有签名的PDF格式文件）将导出给档案管理系统存档；由于数模数据量大且关联性强，因此只将数模编号等属性信息传递至档案管理系统。实施前提和假设：l 以上数据交换采用中间数据库表或XML文件方式进行。l 本接口是协同研制平台向档案管理系统的单向数据传递。l 甲方（或甲方协调第三方）负责集成接口中档案管理系统端的方案设计、开发及配置工作。3. 项目实施计划、组织和策略3.1 实施计划本项目预计启动日期为2014年1月，方案32、定义、方案开发、部署上线和后续支持的总计实施周期为9个月，如果项目启动时间变化，项目节点时间将据此依次顺延。项目实际执行时间表以最终商定的计划为准。每个里程碑完成后，甲方需要在“阶段确认书”中签字确认，作为阶段验收标志。系统交付验收将在试运行期完成后，由甲方召集各应用单位进行验收。项目实施节点计划如下表所示：项目里程碑实施工作预计开始时间预计结束时间里程碑1：项目启动及方案定义召开项目启动会，进行基础培训、业务调研、方案设计及方案评审工作2014/1/62014/2/28里程碑2：系统开发配置及测试进行详细设计，实施内容开发、配置及集成测试工作2014/2/172014/4/25里程碑3：用户33、测试验证及上线试运行进行用户测试、培训、上线部署及上线试运行2014/4/142014/5/30里程碑4：系统正式推广及项目结案进行系统正式推广，并提供上线支持，完成项目验收2014/6/22014/9/303.2 项目组织甲方和乙方将建立一个联合的项目管理委员会，确保通过预定项目流程评估和支持。指导委员会的责任包括：l 整体项目状态的评估l 项目实施期间重要问题决策项目管理委员会应在整个项目过程中由个人兼职担任，其成员必须是甲方和乙方各自的授权代表，有能力决定项目相关问题。项目管理委员将会负责本项目的关键决策，并在必要时尽早做出决定，以便指导项目的正常运行。在此SOW开始执行之前，甲方需要委34、派经验丰富的项目经理，负责所有与乙方的交流工作，并有权在项目各个方面代表甲方。甲方项目经理将与乙方项目经理合作建立项目核心团队（包括项目管理办公室PMO和核心工作组），项目团队需要包括保证项目成功交付的必须角色。l 有关每个角色的定义及责任请参考附录A。l 有关于项目管控模型，请参考附录B。3.3 实施策略以下将从产品应用范围、实施目标定义、基础架构、质量管理（测试验证及确认）、推广应用和数据等方面定义甲方系统实施策略。1. 应用产品在本期项目范围内，将基于TA600型号飞机数据进行实施，如下表所示：表：产品概述地点 产品产品概述甲方（珠海市）TA600型号飞机 本期项目中，为满足型号全面试制35、阶段的业务需求进行实施2. 实施基础架构策略在本期项目范围内，将基于以下基础架构进行实施，如下表所示：表：基础架构列表基础架构详细说明协同研制平台测试服务器 乙方负责开发测试环境Windchill安装和部署；协同研制平台生产服务器 乙方将构建一个基于Windchill 10.1版本的协同研制平台生产服务器。 乙方负责协同研制平台测试及生产服务器Windchill的部署工作，并提供相关的部署文档。3. 实施测试验证及确认策略为了确保系统能够稳定运行，满足既定的各项业务需求，将对系统进行严格的测试验证和确认工作。表：系统测试验证及确认测试类型测试说明测试实施测试人员1. 单元测试该测试过程将保证，36、程序运行和设计规格一致。 编制单元测试用例（Use Case） 对需求规格要求的各项功能进行测试。按照用例进行单元测试 对代码完成与相关的变更后，需要重新进行单元测试 乙方实施顾问2. 集成测试集成测试将进行系统各个开发组件的联调测试，保证各个开发模块的可用性。 编制业务场景和测试用例（Use Case） 按照业务场景和测试用例，执行集成测试； 对代码完成与相关的变更后，需要重新进行集成测试； 甲方开发团队 乙方实施顾问3. 用户可接受性测试用户可接受性测试将按照实际业务场景，由甲方关键用户进行的可用性测试，保证系统与实际业务方案的一致性，满足实际业务的需求。 编制业务场景和测试用例（Use 37、Case） 按照业务场景和测试用例，由甲方团队执行完成用户可接受性测试； 对代码完成与相关的变更后，需要重新进行用户可接受性（UAT）测试； 甲方开发团队 甲方关键用户 乙方业务顾问4. 项目实施方法乙方全球服务部门通过“实现价值平台”（Realized Value Platform，RVP）实施方法进行项目的实施交付，实现价值平台包括乙方在项目实施管理、流程咨询、系统实施以及推广应用等层面的内容，以实现本期项目预期目标。4.1 项目管理1. 项目初始化和规划本工作的目标是确保项目准备就绪，可以进行项目实施。表：项目活动和交付项目活动交付责任方项目管理计划 项目管理计划Project Mana38、gement Plan乙方项目实施计划 项目实施计划Project Schedule乙方2. 项目执行项目执行包括项目执行过程协调、管理和报告项目进展状态，以及解决出现的项目问题。表：项目活动和交付项目活动交付责任方项目协调/团队沟通 项目状态报告Project Status Report乙方项目执行过程中的修正-预防行动 变更申请表（如果存在）Change Request Form 风险和问题日志Risk and Issues Log乙方3. 项目监督及控制本模块用于收集和评价项目的执行状况信息和风险信息，并确定是否需要采取修正或预防行动。项目活动交付责任方集成变更控制 变更申请表（如果存在39、）Change Request Form乙方风险及问题管理 风险及问题日志Risk and Issues Log乙方4. 项目结案项目结案包括：核实项目的交付是否满足了工作说明书的要求，是否正确归档了项目文件。并进行项目总结，完成乙方内部结案行活动及项目结案审计。在管理结案阶段，举行结案会议，存档项目记录和文件。在合同结案时，获得甲方在项目结案报告上的签字，表明所有交付已经完成，并与工作说明书（SOW）一致。项目活动交付责任方管理结案 存档项目记录和文件Archived Project Item and Documents乙方/甲方合同结案 签署的结案文件Signed Closure Docu40、ment 乙方/甲方4.2 应用设计应用设计工作包括获取、分析和确定甲方的业务需求，评估甲方现有业务流程，设计满足项目目标的业务流程、最佳实践的相关活动。同时基于业务设计方案，完成系统设计工作。1. 业务设计：业务流程分析和设计该工作用于保证甲方的业务流程的成功优化提升，以及准确定义应用开发框架。项目活动交付责任方流程分析/流程设计 未来流程描述和实践设计Future Process Description and Practice Design 乙方2. 系统设计：应用和实践设计定义和设计系统中的客制化组件。项目活动交付责任方定制组件设计 系统设计文档System Design Docume41、nt 乙方4.3 应用开发应用开发包括代码开发和技术管理。1. 开发开发涉及到相关组件设计定制代码的开发和配置。开发的目标是交付满足需求的可执行软件。项目活动交付责任方定制组件开发 部署组件及安装及配置说明Deployable Component and Installation & Configuration Instructions乙方2. 技术管理通过技术管理，对开发活动中参与团队、输出代码进行有效管理，保证系统软件的有效配置管理。对软件代码应采用通用的软件配置管理工具进行管理，以便追溯。项目活动交付责任方技术团队管理无乙方/甲方Build管理 Build及部署步骤管理文档Build a42、nd Deployment Procedure乙方软件配置管理无甲方4.4 质量管理通过对于软件的测试验证，确保通过测试成果的目标证据满足甲方的需求。1. 软件质量保证制定测试计划、提供测试数据、配置测试环境、编写测试脚本，并进行测试验证的工作，并编写测试报告。项目活动交付责任方测试计划 方案测试计划Solution Test Plan乙方测试用例开发 测试用例Test Case Document乙方/甲方提供测试数据 测试数据Test Data甲方测试执行 测试报告Test Report乙方/甲方4.5 系统部署系统架构包括支持系统实施所需要的设置、配置和管理工作。1. 系统部署规划规划定义43、系统部署的目标、关键要素和部署步骤任务，并制定部署计划。项目活动交付责任方部署计划 系统部署计划Deployment Schedule乙方2. 系统架构设置系统架构设置包括乙方软件相关及所需要的第三方软件的安装、配置。在本项目中，将完成测试系统及生产系统的部署工作。项目活动交付责任方Windchill服务器配置 安装及配置文件Installation and Configuration Document乙方5. 前提条件和假定本工作说明书基于下列假定。在本项目的实施过程中，如果实际情况与以下假定不同，则双方项目经理友好协商解决。如有必要，则启用项目变更控制流程。5.1 一般假定1. 此工作说明44、书经甲方和乙方签字认可后，将取代有关本项目以前任何口头和书面的承诺。2. 本项目实施将基于本文要求和Windchill已有的缺省(Out Of The Box，OOTB)功能。如系统功能与期望有较大的出入，由双方项目经理商量后决定是否提请变更。3. 实施所涉及的业务管理事项，乙方提供详细技术方案建议，甲方需要及时做出决策，以保证项目的如期执行。4. 甲方需要在方案定义阶段开始进行相关规范标准的规划和编制工作。为保证项目实施内容的推广应用，甲方需要基于评审通过的业务解决方案，编制相关的业务规范，并在系统正式部署之前就绪。5. 部分实施工作，需要相关业务单位/部门及第三方软件供应商的支持和协助，甲45、方需要完成相关的沟通和协调工作，以保证在规定的实施周期内完成该项目的实施工作。任何可能影响项目计划的非乙方的因素应由甲方控制和管理。6. 本期项目实施将会基于Windchill 10.1最新版本进行实施，方案设计、代码开发和系统部署都将基于该版本进行，Windchill的后续升级不列入本期项目实施的范畴。7. 乙方在项目实施期间使用甲方的现有软件、程序、资料或应用时，应得到甲方的许可，遵循甲方的相关规章、制度和条例。5.2 硬件和软件1. 硬件、软件的成本及其购买、交付和安装不属于本工作说明书的范围。由于本项目的顺利实施需要依赖甲方方面现成的硬件和软件条件。甲方应及时提供实施本项目所需要的硬件46、和软件条件，包括：硬件服务器，Windchill安装和配置指南中要求的软件许可证，所需要的第三方应用的所有软件版本，及要求与此软件相兼容的第三方应用。乙方不对甲方因软件知识产权产生的任何法律纠纷负责或承担连带责任。2. 甲方的网络和硬件环境应能满足详细技术方案实际运行的要求，对由于网络或硬件不能到位或其它甲方因素，引起的项目延期或需求变更，需双方根据本文规定的变更程序，友好协商后决定处理办法。3. 在项目开始之前，甲方应负责维持一种与其实际生产环境区分开来、能充分代表甲方所希望达到的目标生产环境的开发及测试环境。硬件和操作系统的安装、支持和管理由甲方团队完成。5.3 实施场地1. 项目方案定义47、工作，可在甲方或乙方现场完成。2. 项目开发及单元测试工作可在甲方或乙方现场完成，集成测试、用户可接受性测试在甲方现场完成。3. 项目实施培训工作在甲方现场完成。5.4 项目资源和进度管理1. 乙方及甲方组成合作团队，双方应根据本工作说明书中所约定的内容完成各自的任务、承担各自的责任，并保证密切配合、协调工作。2. 培训材料准备及用户培训由甲方负责完成。3. 在项目规划阶段，双方需要明确参与项目的人员、角色。对于乙方实施人员的短期或长期变动，需要书面通知甲方项目经理。4. 乙方所有的项目交付文档将基于中文格式提交，甲方对于乙方提交的正式交付，需要在5个工作日内给出反馈建议。对于已批准交付的任何48、更改，将视为项目变更，通过项目变更控制流程处理。6. 项目验收标准和流程甲方需要对于本SOW中规定的每个里程碑进行验收，每个里程碑验收合格则标志着该阶段工作的成功完成并意味着下一里程碑工作可以启动。每个里程碑验收完成后，甲方需要在阶段确认书（参见附录C）中签字确认，作为阶段验收标志。以下为每个里程碑的验收标准：里程碑1：项目启动及方案定义预计完成日期项目起始日 + 7个工作周实施内容1. 项目初始化2. 项目执行、监督与控制3. 业务设计：业务方案设计4. 系统设计：系统方案设计交付1. 项目实施计划Project Schedule2. 业务方案Future Process Descripti49、on and Practice Design 3. 系统方案System Design Document验收标准列举在阶段确认书中的交付内容(a) 已交付并被接受；(b) 已交付但被有条件接受；或者(c) 甲方放弃。对已交付文档的验收标准：经甲方签署上述交付文档和阶段确认书以验收这些交付成果验收者甲方项目经理投入百分比30%里程碑2：系统开发及配置预计完成日期项目起始日 + 10个工作周实施内容1. 项目执行、监督与控制2. 技术管理3. 应用开发4. 系统部署（测试系统）5. 集成测试验证交付1. 开发代码包Code Package2. 客制化代码部署指导手册Customization Co50、de Deployment Document验收标准列举在阶段确认书中的交付内容(a) 已交付并被接受；(b) 已交付但被有条件接受；或者(c) 甲方放弃。对已交付文档的验收标准：甲方签署上述交付文档和阶段确认书以验收这些交付成果验收者甲方项目经理投入百分比30%里程碑3：用户测试验证及上线试运行预计完成日期项目起始日 + 7个工作周实施内容1. 项目执行、监督与控制2. 用户测试验证3. 系统部署（生产系统）4. 上线试运行支持交付1. 测试用例Test Case Document2. 测试报告Test Case Document3. 生产系统部署文档Production System In51、stallation and Configuration Document验收标准列举在阶段确认书中的交付内容(b) 已交付并被接受；(b) 已交付但被有条件接受；或者(c) 甲方放弃。对已交付文档的验收标准：甲方签署上述交付文档和阶段确认书以验收这些交付成果验收者甲方项目经理投入百分比20%里程碑4：系统正式推广及项目结案 预计完成日期项目起始日 + 18个工作周实施内容1. 项目执行、监督与控制2. 系统运行支持3. 项目结案交付1. 问题跟踪及解决日志Issue Log2. 项目移交清单Customer Handover Checklist3. 项目总结报告Project Closure52、 Document验收标准列举在阶段确认书中的交付内容(a) 已交付并被接受；(b) 已交付但被有条件接受；或者(c) 甲方放弃。对已交付文档的验收标准：经甲方验收评审通过后，签署上述交付文档和阶段确认书以验收这些交付成果对生产环境的验收标准：验收生产环境旨在验证软件能否安装以及所有基础功能的运行是否正常。当达到下列标准时，生产环境就可算是通过验收。 无阻碍业务流程的故障验收者甲方项目经理投入百分比20%7. 收费和付款条件对于本工作说明书中规定的实施内容（详细参考本工作说明书第2章节），以固定价格方式执行。甲方理解报价是以本工作说明书中所描述的要求、职责、假设、交付和活动为基础。根据合同规定53、，对于本工作说明书的改动，经双方另行协商决定是否需要对收费和日程表进行调整。甲方未签名接收，本工作说明书30天后失效。8. 项目变更项目的启动以本工作说明书所描述的内容为开发前提，大量或频繁的项目变更会导致项目无法按时完成。原则上在项目实施过程中，各阶段达成后的内容不再容许变更。任何变更都必须经双方认可后方可执行。8.1 项目变更控制流程凡是对已经确认的工作范围、项目计划、设计方案、项目成果的变更，均称之为项目变更。当提出的更改对本文档构成实施范围、进度或职责的实质性变更的情况下，必须采用项目变更控制流程中的描述。乙方尝试在本工作说明书中提供足够的细节以清楚地描述本项目中包括及不包括的范围。乙54、方也尝试在本工作说明书中包含所有目前已知的需求。然而，随着项目的进行，乙方和甲方可能需要用额外的信息补充本工作说明书。项目变更需要甲方和乙方共同签署才能将修改并添加到本工作说明书。项目变更控制流程定义如下：l 任何对已同意的实施范围的变更或与该范围的偏离，或对本工作说明书中同意的时间或费用的变更都将遵循项目变更控制流程。l 无论何时，在意识到需要变更而该变更将影响工作合同（如日程表、功能或费用）时，乙方或甲方都可以提出变更的要求l 同意变更意味着同意一个关于总体的费用、范围和进度的变更。提出变更需首先填写变更申请表（REQUEST FOR CHANGE，以下简称RFC）。RFC需提交由甲方和乙55、方人员组成的评审小组。评审小组将就RFC的技术可靠性以及对整个项目的影响作出评估。经批准的RFC将转给乙方，未被批准的RFC将退还给提出变更的本人。双方需要对变更可能对预算、进度、资源等造成的影响进行评估、批准和内部存档，并决定是否需提交双方领导进行批准。其中凡涉及到整个项目进展，费用成本调整较大的变更，必须交由双方领导批准通过。变更批准后，甲方和乙方需要按照变更对项目预算、进度、资源的影响调整相应计划，并指定相应人员执行变更。并指定相应人员监控、记录整个变更的过程，并对变更执行的结果进行验收、上报和内部存档。项目变更控制流程基本描述如下:1. 甲方或乙方任何一方均可以提出RFC2. 将RFC56、提交评审小组作技术可行性评定3. 乙方以书面形式接受RFC并给出PCP的准备时间和所需费用4. 评审小组讨论乙方提出的时间和费用以及是否批准RFC5. 乙方负责做出项目变更建议书并确认所需费用和进度6. 评审小组讨论项目变更建议书并提出实施建议7. 甲方对项目变更建议书提出认可，并同意乙方对合同进行变更8. 更具项目变更建议书的内容，落实变更内容。8.2 项目变更乙方职责乙方将在接到RFC的10天内给出收讫说明以及分析RFC所需的时间，做出相应的项目变更建议书。乙方可对RFC分析报告以及项目变更建议书进行收费并以书面形式告知甲方收费标准，乙方将于甲方同意收费标准后10天内或规定时间内，对RFC57、进行研究并做相应的项目变更建议书。乙方项目经理需要：1. 调查建议的变更对于范围、进度和费用的影响。2. 评价不做变更会产生的影响。3. 准备对该变更的响应。4. 如果就采用该项变更达成一致，获取RFC需要的授权签名。5. 如果不同意该项变更：l 乙方项目经理将与甲方项目经理进行讨论并将反对意见存档。l 如有可能，该建议的变更将被重新讨论；或者收回该变更建议。在这些情况下，相应的原因应该写在RFC上并归档。8.3 项目变更甲方职责本协议有关费用或进展的变更，需由甲方授权的代表以书面形式提出并批准。批准后的项目变更内容将列入本工作说明书。如果该变更需要额外的资金，甲方必须保证在变更开始前获得资金58、。附录A：甲方职责在项目开始实施前，建议甲方成立专职的实施团队，并分配以下角色：l 项目经理在开始本工作说明书前，甲方应任命一名项目经理。与乙方的所有沟通都将通过该项目经理来完成，而且该项目经理应就本项目中的各个方面都有权做出反应，包括与甲方项目组协调，根据全球服务协议管理特殊变更，签署所有项目的交付。甲方项目经理需要在项目的进展过程中全程参与。l Windchill系统管理员系统管理员负责系统的运行、维护和管理，包括用户与团队的管理，系统安全，故障维修，系统的维护，安装和备份。该管理员在本工作说明书的进展过程中将以半职参与项目。l Windchill系统开发人员系统开发人员接受系统开发培训，59、管理客制化代码，并全程参与开发过程。并在项目结束后，具备面向系统需求调整的代码开发能力。进而建立甲方系统的技术支撑体系。对于每个模块的开发代码，都需要由专门的开发人员负责。l 业务流程专家对乙方在特殊业务流程或流程组中遇到的问题进行指导。担任此角色的人能对现有的流程提供准确的信息，并能定义未来流程的需求。作为顾问，他们能指导变更管理问题，如将组织转换到新流程。对于特殊的流程，业务流程专家不是必须设置的，而对于在其权限内的一些决策，必须有业务流程专家参与。表：以下角色说明了项目计划的甲方资源甲方角色角色参与阶段项目经理所有阶段Windchill系统管理员所有阶段Windchill系统开发人员所有60、阶段业务流程专家所有阶段附录B：项目管控模型以下是一个推荐的项目管控模型，标识了实施项目的项目组织架构。项目管理委员会（Executive Steering Committee）定期或按需召开项目管理委员会会议，听取项目汇报，指导项目方向，决策项目变更。甲方乙方业务部门领导销售部门领导管理部门领导全球服务部门领导IT部门领导项目管理办公室（PMO）定期或按需召开项目管控会议，组织项目例会，协调项目事宜会议监督项目，解决问题并确定要提交的问题甲方乙方甲方项目经理乙方项目经理工作团队业务流程组技术开发组系统架构组推广应用组甲方团队乙方团队甲方团队乙方团队甲方团队乙方团队甲方团队乙方团队乙方提供的人61、员角色如下表所示：乙方角色乙方 角色职责项目经理负责项目计划、项目监控、资源分配，以及时间、程序问题的解决，并负责与甲方的日常沟通和交流。业务顾问准备调研提纲，对业务部门进行业务访谈，对业务流程现状进行分析，协助甲方定义未来业务流程，并定义业务解决方案。系统架构顾问提供系统架构的设计和技术规格的定义实施顾问负责安装与配置系统、代码开发、测试、调试、技术实施和支持工作，并负责技术方面的培训工作。培训顾问完成标准培训课程的培训工作，对需要的开发课程进行课件定义，并落实培训。附录C：阶段确认书模板( Template of Milestone Certificate)附录D：授权签署阶段确认书名单A62、ppendix: List of Authorized Signature on Milestone Certificate:_ (公司名称) 授权以下人员签署阶段确认书:_(Company Name) authorized the following person(s) to sign off the Milestone Certificate:姓名:Name:职务:Title:手机:Phone No.:电子邮箱:E-mail Address签名Signature上述名单中的被授权人任何一个或者多个对阶段确认书的签署，将被PTC公司所接受。如Any one or more signature63、s of the authorized persons on the Milestone Certificate from the above list will be accepted by PTC,果上述名单为空白或者签署人不在上述名单之中，则PTC只能接受下述两种情形之一：If the above list is blank or the signatory is not in the above list, PTC can accept either following situations:1） 阶段确认书的签字人与本工作范围说明书的签字人为同一个人； The signatory on the Milestone Certificate is the same with the one on Statement of Work (SOW);若上述授权名单需要发生更改，则需要通过本工作范围说明书中规定的变更流程进行更改。Any changes in the above authorized list will be processed through Project Change Control Procedure (PCCP) prescribed in the SOW第 32页