Petrel软件实例操作流程
目录
第一章Petrel简介 (1)
一、安装并启动Petrel (1)
二、界面介绍 (2)
第二章Petrel处理流程介绍 (7)
一、数据准备 (7)
二、断层建模 (15)
三、Pillar Gridding (23)
四、Make Horizon (28)
六、Layering (35)
七、建立几何建模 (36)
八、离散化测井曲线 (37)
八、数据分析 (38)
九、相建模 (43)
十、属性建模 (55)
十一、体积计算 (64)
十二、绘图 (68)
十三、井轨迹设计 (70)
十四、油藏数值模拟的数据输入和输出 (73)
第一章Petrel简介
一、安装并启动Petrel
把安装盘放入光驱，运行Setup.exe程序，根据提示就可以顺利完成安装，在安装的过程中同时安装DONGLE的驱动程序，安装的过程中不要把DONGLE插入USB插槽，安装完毕，再插入DONGLE，如果LICENSE过期，请和我们技术支持联系。然后按下面的顺序打开软件。
1. 双击桌面上的Petrel图标启动Petrel。
2. 如果是第一次运行Petrel，在执行Petrel运行前会出现一个Petrel的介绍窗口。
3. 打开Gullfaks_Demo项目。点击文件>打开项目，从项目目录中选择
Gullfaks_2002SE.pet。
二、界面介绍
（一）、菜单条/ 工具条
与大多数PC软件一样，Petrel软件菜单条有标准的“文件”、“编辑”、“视图”、View等下拉菜单，以及一些用于打开、保存project的标准工具，在菜单条下面的工具条里还有更多工具。在Petrel里，工具条还包含显示工具。此外在第二个工具条里还有位于Petrel 项目窗口的右端的按钮，它具有附加的Petrel相关的功能。后面的工具条称为功能条，这些工具是否有效取决于选择进程表中的哪个进程。
操作步骤
1.点击上面工具条中的每一项看会出现什么。你可以实践一些更感兴趣的选项。
2.将鼠标在第二个工具条中的按钮上慢慢移动。将会出现描述每一个按钮功能的文本出现。
3.点击“What's This”按钮，然后再点击其它的某个按钮。将会现该按钮的功能的更详细的描述。
（二）、Petrel资源管理器
Petrel资源管理器(左上角)跟任何PC机上的windows资源管理器一样工作。通过点击加号、减号可以打开和关闭文件夹。注意Petrel资源管理器下面的卡片，这些卡片可以从一个文件夹移到另一个文件夹。
操作步骤
1. 点击输入卡片。
2. 展开文件夹显示其内容。
3. 右键点击文件夹有效的选项，从选项列表中选择设置，弹出一个窗口，支持文件夹的几个有效功能选项。
4. 右键点击一个文件并选择设置，出现这个文件有关信息。
5. 点击Petrel资源管理器下面的Models卡片并浏览卡片下的文件。右键点击其他项目并试验点击其他选项。
（三）、进程表
进程列表是Petrel中可以被激活运行的处理命令。
操作步骤
1.点击列表功能的某些功能，注意显示窗口右边的工具条如何变化。工具条上的一个或两个按钮将发生变化。你也可以注意到功能的名称是高亮显示的，意思是那个功能是被激活的。
2. 双击一个功能可以看到那个功能的对话框，这些对话框错综复杂地依赖于该功能。浏览这个对话框的所有卡片。查看其他进程的对话框。
（四）、显示窗口
显示窗口是所有的图形显示的地方。各种窗口都能够显示这部分内容。例如3D、2D窗口、井剖面窗口（井相关）、解释窗口(地震解释), Map/Intersection窗口(绘图),等等。
操作步骤
1.点击工具条上面的window菜单，一系列显示窗口类型被列在列表上。在列表下面是当前被激活的显示窗口。
（五）、数据信息
建立任何模型最重要的方面之一是理解这些数据和检查建模用的那些数据的质量。在Petrel中有很多方法可以检查数据。它们很多都是可视化的，可是有些是文本的也非常有用。这些包含文件内容的清单，用编辑器可以浏览top picks 和统计表。
编辑Well Tops操作步骤
1. Petrel有一个Well tops的编辑器。
2. 在Petrel资源管理器下的输入卡片下右键单击Well Tops文件夹并选择编辑器。弹出一个包含Well tops所有有效信息的窗口。
3. 改变文件夹浏览所有数据，不要保存你的改变，浏览完毕关闭窗口。
4.部分或所有信息都可以被选择后直接复制粘贴到Excel中。选择所要复制的行或列的对象然后点击copy按钮。
检查统计表
不论输入数据，建立的新文件或检查别人的其他项目，你都应该检查重要文件的统计表，避免出现那些意想不到的错误。
操作步骤
软件开发流程图 项目前期 需 求 变 化项目启动 需 要系统实变现 更系统调测 开始 获取用户需 编制初步方 编制进度 / 跟踪 需求基本确定 编制详细预 配置内部资 分配开发任 系统实现 控制/调 无需变更 技术调测 PM：获取 EU主要的关键性需求 PM：根据 GM安排编制简略 / 详细的建设方案 PM：基于内部预算对 EU提供费用报价 PM：与 EU确认需求变动及方案、费用调整 PM：完成详细内部预算并提交给GM PM：通过内部项目管理系统配置详细人员、进度安排 PM：移交 EU需求给PG，安排 PG开发任务 PG：根据 EU需求及 PM要求，执行开发任务 PM：通过内部项目管理系统审核PG工作日志， 确认 EU需求变动，执行进度控制，必要时变 更人员安排及内部预算 PG：技术调测及修改；根据TE 测试文档调试修改集成测
部署试
TE：进行集成测试，编制测试文档，提交PM，送达PG 未 通 过通过 通过项目后期 系统验收 结束PG：部署至外部服务器 PM：系统初验 EU：试用 PG ： 部署正式上线，编制开发字典，提交PM M 获得试用意见 TE：编制系统操作手册、功能列表，提交PM PM：提交开发字典、操作手册、功能列表给EU,通过内部项目管理系统结项，向 GM汇报 备注： PM (Project Manager)：项目经理PG (Programmer)：程序员EU (End-User)：最终用户TE (Test Engineer)：测试工程师GM (General Manager)：总经理 硬件开发流程图
产品调研 / 新产品立设计开发执行子项目分支执 首样评审业务部主导 研发部 研发部主导 业务部 研发部主导 研发部主导 业务部 采购部 研发部主导 业务部 工程部 1、资料搜集并拟定产品需求表 ① 预期的用途，特定的功能、性能和安全要求； ② 类似产品的名称，型号或参考实物样板； ③ 细化客户对产品的外观、功能、价格等要求； ④拟定《产品需求表》展开评审会议 , 并形成《技术可行性分 析报告》同时交总经理审批。 2、研发经理组织结构、电子与ID 协调定义，进行3D 图形设计 与修改，形成《产品外观效果图》《产品3D 图》、《产品规 格书》会同业务、总经理展开评审会议，若评审通过，由业 务形成《立案通知书》和《产品研发任务书》交总经 理审批，输出交研发部进行设计开发工作。 注： B 类项目可直接评估形成《产品研发任务书》 3、研发部签收《产品研发任务书》 , 项目负责人根据《产品外 观效果图》、《产品 3D 图》、《产品规格书》、《产品研发 任务书》的要求对设计工作进行策划形成《项目进度表》，包括： ① 设计过程中各阶段时间和工作内容的安排； ② 设计评审、设计验证、设计确认的安排； ③ 设计过程中各项工作的分工及各小组之间的接口及工 作顺序等； 4、项目负责人根据《项目进度表》推进设计，每设计阶段 必须与研发部经理进行设计评审，设计评审完成后研发部 完成硬件打样，首样制作由该项目各负责工程师共同制作， 并完成《样机测试记录表》、《操作说明》、《首样评审表》， 并填写《线路板通知书》、《开模申请表》交研发经理审核。研发 部根据设计评审结论编制 BOM、电路原理图、贴片图的PDF电子 版、结构爆炸图、《样机测试记录表》、《软件测试 记录表》、《样机测试记录表》并存档。 5、结构电子依《首样评审表》内容，对需要做设计变更的 尤其产品外观改动的，需经总经理批准的《设计变更表》， 才能对其模具设计修改，并填写《改模记录表》。首样评审完 成修改通过后，发放至工程部由工程部汇总完成《工程 样机测试汇总表》，3 个工作日后由项目负责人组织电子、 结构、工程、品质、业务进行项目首样评审。
软件产品开发流程 软件开发流程（Software development process）即软件设计思路和方法的一般过程，包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。 第一步：需求调研分析 1相关系统分析员和用户初步了解需求，然后用WORD列出要开发的系统的大功能模块，每个大功能模块有哪些小功能模块，对于有些需求比较明确相关的界面时，在这一步里面可以初步定义好少量的界面。 2 系统分析员深入了解和分析需求，根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚例用系统大致的大功能模块，大功能模块有哪些小功能模块，并且还例出相关的界面和界面功能。 3 系统分析员和用户再次确认需求。 第二步：概要设计 首先，开发者需要对软件系统进行概要设计，即系统设计。概要设计需要对软件系统的设计进行考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。 第三步：详细设计 在概要设计的基础上，开发者需要进行软件系统的详细设计。在详细设计中，描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系，需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑，以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足
够详细，能够根据详细设计报告进行编码。 第四步：编码 在软件编码阶段，开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等方面的设计要求，开始具体的编写程序工作，分别实现各模块的功能，从而实现对目标系统的功能、性能、接口、界面等方面的要求。 第五步：测试 测试编写好的系统。交给用户使用，用户使用后一个一个的确认每个功能。 第六步：软件交付准备 在软件测试证明软件达到要求后，软件开发者应向用户提交开发的目标安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等双方合同约定的产物。 《用户安装手册》应详细介绍安装软件对运行环境的要求、安装软件的定义和内容、在客户端、服务器端及中间件的具体安装步骤、安装后的系统配置。 《用户使用指南》应包括软件各项功能的使用流程、操作步骤、相应业务介绍、特殊提示和注意事项等方面的内容，在需要时还应举例说明。 第七步：验收 用户验收。
属性建模： 一、相模型的建立： 1、测井曲线离散化 双击：Process ——Proerty modelding——Scall up well logs； 弹出对话框：
在Select里选择需要离散化的相曲线数据facies(input到wells的沉积相数据)，点击all可以对需要离散的井进行选择，剔除没有曲线或者曲线数据不正确的井）。 在相模型建立时：Average选择“most of”、method选择“Simple”。单击“Apply”或“OK”确定。完成沉积相数据的离散化，离散化后，沉积相数据赋给井轨迹所通过的网格。离散化后models里的properties里新增了沉积相属性“facies”，可在3D视图里进行查看。
2、沉积相模型建立; 双击：Process ——Proerty modelding——Facies modeling。 弹出对话框：
对话框右上角选择离散化后的沉积相数据，依次选择各小层（zone）进行属性控制；点击解锁进行编辑控制。 目前的沉积相建模算法很多；通常，纵向上细分网格后用序贯高斯的算法，纵向上未细分用经典算法（此处的“纵向细分“是指layering里把zone细分为不同个数的网格。 ⑴、序贯高斯的算法； “Method for zone /facie”选项单击下拉菜单， 选择序贯高斯算法：“Sequential indicator simula”，在左侧选择该小层所以相类型（可从 左侧出现的百分比统计中看出）单击箭头，相 类型移动到右侧。
下侧空白区域新增两个选项卡“Variogram”，“Fraction”，点击按钮，弹 出对话框：
快视信息软件开发流程规范： 用户需求：软件项目首先由客户经理(CM，Custom Management)接洽客户的较大的需求。这时的需求叫市场需求（或叫用户需求），客户经理会进行各个项目的安排，即对项目的启动时间和发布时间进行规划和设置。 项目经理(PM，Project Management)对客户经理负责。项目经理的需求是根据客户经理给的，项目经理不和用户（客户）直接接触（通过客户经理接触），负责和用户进行需求洽谈和沟通的是客户经理。一个项目的需求在一般情况下是不准变更的，如果有需求理解方面的不清楚可以进行沟通，但是需求是不变更的。如果用户有新的需求，一般规划在下一个版本中。因为需求变更了，这个目的时间就要进行调整，就不能按计划进行和完成。客户经理提交给项目经理的是需求规格说明书。 一、项目开工会 在项目经理领到客户经理分配给的需求后，做项目计划，具体做项目人员的确定、需求的分解（需求分解到每个人）、代码量的估计，项目各个阶段时间的划分和工作量的计划、质量指标的设定。这时项目经理需要输出的文档是项目需求分解任务书、项目计划PPT、及做好整个项目需要填写的一系列表格。然后组织项目组成员和客户经理CM、QA(质量审计经理)进行项目开工会。这时这个项目就算真正启动，计算工作量时，即计算这个项目总共花了多少个工时，工时是项目经理做计划的时间也算在内，再加上项目开工会和后续各个阶段总共花的总工时数，还有各个阶段开会所花的时间。在项目开工会上，各个成员就明确了这个项目是属于增强型项目，还是其他项目的项目性质，增强型项目的意思是说在原来上一版本的基础上又根据新的需求进行增强型开发。还有要明确项目最后开发出的新增代码量有多少，最后要明确每个人的需求任务，接下来着手进行SRS的写作。 二、SRS阶段：System/Software Requirment Specification 软件需求规格说明 在项目开工会后，项目组就开始按照在项目开工会上项目经理的需求任务分解的任务开始进行SRS的写作。 一般项目经理给你的一个子需求任务，你这时需要分解为更小的需求。一般一个需求的写作是按这样进行的。先简单介绍这个需求，然后把这个需求设计成黑盒的形式，即输入，处理过程、输出。这些都需要写详细，任何一个需求都写成这种形式，输入是什么，处理过程是什么，输出结果是什么。处理过程需要用Visio或者PPT画出处理流程图，流程图要很详细。每一步的各种情况都要表示和考虑到。对异常情况也要考虑和进行处理。还有要说明在原来的基础上怎么改动，具体方法要进行说明。设计的数据库表结构，要给出脚本，SQL语句，表结构需说明每个字段，哪些是主键，你在这个需求处理过程中哪里使用了哪些表，需要进行哪些操作，都需要说明。这里需要设计和编制《数据库设计说明书》文档。该文档中描述该系统中设计出的所有的数据库表结构和各字段类型。还有多个操作对象要画序列图表示出按时序的处理过程。这个SRS文档就相当于我们平时毕业设计或者一个题目的详细设计阶段达到的水平，甚至比它更详细。每个项目组成员都把自己的需求的SRS文档写出来之后放到配置库中，然后每个人对项目组其他成员的（非自己的）SRS文档进行Review（评审）,对每个SRS文档在每页发现或者纠正的错误数不能低于一定的数目，而且要保留批注记录，经过Review的（保留批注的）文档要放到配置库的Review文件夹下，这是进行项目质量指标收集的重要依据，是QA 进行调阅和审计的资料。项目经理要对SRS文档、SRS Review文档进行汇总。在汇总后组织项目组全体成员进行SRS阶段会议，对每个人写的SRS进行评审会议（讨论和提意见），对别人给你提的修改意见你要一一进行说明，说明为什么不改，怎么改的，是什么问题，问题严重程度属于什么级别，而且都要填表，也是QA进行审计的内容。开完会后如果每个人完成的都差不多，然后安排半天或者一天的时间进行返工，主要是进行修改文档，按在会上讨论的结果和别人给你的Review 文档结果（评审结果）进行准一修改和完善。然后再进行SRS阶段开会，如果都做的比较到位和具体、符合要求，即关闭SRS阶段。这时SRS阶段的花费的工时数和一些质量活动指标就出来了，比如你这个SRS文档写了几页，每页的错误数是多少，返工修改用了多少时间，然后这些这个比率也会自动计算出来。进而可以判断这个阶段的质量。每个项目组成员在每天工作完毕后都要进行Time Sheet 的填写，必须具体到半个小时，这是统计和分析的需要。填写必须真实。 三、UTP、STP阶段（UTP、STP写作） UTP Unit Test Plan 单元测试计划 STP System Test Plan
软件项目开发工作流程 一、简述 对于一个新项目，从可行性研究到产品交货整个生存阶段将经历如下十大流程： 1、项目可行性研究阶段 2、立项阶段 3、需求分析阶段 4、开发策划阶段 5、设计阶段 6、编码实现阶段 7、测试阶段 8、验收阶段 9、产品交付使用 10、维护阶段 二、项目组基本组成及岗位职责 新项目立项时会成立项目组，不同的项目组成员有不同的职责，一个项目组成员也可以身兼多职，但不可身兼全职。 a项目负责人：负责项目的管理、组织、对技术、进度、质量全面负责。 b质量保证人员：负责质量保证工作计划的落实和软件的质量保证。 C配臵管理人员：负责本项目的配臵管理工作，对本项目的文档、程序是否符合规程文件的要求进行形式化的检查。 D分析人员：主要负责本项目的需求分析工作。 E设计人员：主要负责本项目的设计工作。 F程序员：按设计要求和有关标准进行编程工作。 G测试人员：负责单元测试、组合测试和总装测试工作。 H文档人员：负责本项目有关文档的编写工作。 I产品经理：协助进行产品研制计划制定、产品发布与产品推广等,在产品开发中，充分代表用户的利益，提供建议,负责在产品功能与出品日期二者之间的权衡;负责产品市场营销、产品销售和市场推广过程。（通常由营销部门或中试部门人员担任） 三、软件开发流程 3．1 可行性研究阶段 如果是公司自主开发项目，可行性研究通常是由公司技术负责人根据公司产品规划和市场需求，在要开展新项目前通过部门负责人指定人员进行的前期调研工作，可行性研究负责人员对产品的市场需求、技术发展、市场定位、功能需
求、经济效益、进度需求、风险分析等进行可行性研究，提供产品立项建议，拟制可行性研究报告，由部门负责人指定营销部门配合可行性分析人员，技术负责人协助安排。可行性分析完毕后由总工办组织对可行性研究报告进行评审，评审通过后，总工办组织进行立项工作。 如果是系统集成部外接的系统集成项目，在系统集成部与客户签订合同之前，均应对将签项目进行资源、技术、市场的可行性分析，可行性分析通过后、签订合同前由总工办组织相关人员对合同条款进行评审，评审通过后，总工办组织进行立项工作。 本阶段提交的文档：项目可行性研究任务书（技术负责人或部门负责人下达） 项目可行性研究报告（可行性研究人员编写） 系统集成项目合同 质量记录：可行性分析评审报告 3．2立项阶段 可行性分析评审通过后，由开发部门经理下达立项任务，指定相关人员填写立项申请报告报批。报批通过后，由部门经理与技术负责人协商，下达开发任务书，经技术负责人审核确认后，报公司批准。批准立项后项目进度应以立项申请报告中的阶段进度为准，如果进度要调整，需填写进度调整申请报告报批。 本阶段提交的文档：项目立项申请报告 开发任务书 3．3 需求分析阶段 承办单位根据交办单位提出的技术要求和相应的软件任务书以及其它有关文件，与交办单位协作，确定详细的软件需求，该阶段完成的软件需求规格说明经审定和批准后将作为整个软件开发工作的基础列入配臵管理的基线，在本阶段可利用快速原型法使比较含糊的具有不确定性的软件需求（主要是功能）明确化。能给本公司开发的软件的“需求基线”确定提供一个讨论、进一步完善的基础。在本阶段，由产品经理负责，其他人员配合，编写产品规格说明书，此说明书面向最终用户和领导，主要描绘产品的形状以及功能、性能、功能特性、性能特性。由项目经理负责编写系统技术方案书，描述公司初次使用的技术的详细解决方案。本阶段完毕后对需求分析进行评审，出具需求分析评审报告。 本阶段提交的文档：软件需求规格说明书。 原型分析说明书 产品规格说明书 系统技术方案书 质量记录：需求分析评审报告 提交的软件：产品的原型（注：如果时间有限，可以只编写原型分析说明书而不作原型） 3．4开发策化阶段
Petrel建模常用术语 Petrel引入了一些新的术语和公式表达式，现简要地解释如下。 3D Grid –是一个用来描述三维地质模型的由水平线和垂直线组成的网格。Petrel中应用了角点三维网格技术。 Artificial method –用于make surface进程中，意思是在建surface 时不用任何输入数据。 Attribute map –是一张地震属性图。可以从地震体中通过提取穿过某一层面的属性值来获得（分两种：一种是从某一表面开始的一定偏移量内的平均属性；另一是两个面之间的平均属性）。 Automatic legend - 一个预先确定好的用于显示窗口中目标体色标的模板 Bitmap image - 输入的位图，例如BMP和JPG格式的位图文件，它们都可以在UTM（通用横轴墨卡托投影坐标系）中显示出来。 Bulk Volume - 总的岩石体积 Cell Volume –三维网格中单位网格的体积。 Connected Volume –在离散的3D属性中计算相连体积的进程，可用来查找相连的河道。 Contact Level –油水或油气界面，通常是一个固定深度值。Contact Set –由用户自己定义的一组接触界面，用作储量计算的输入值，也可用作显示使用。 Cropping –通过定义主线、联络线和时间范围，创建真实的地震体。Crossline intersection –垂直于主测线方向的垂向地震切面。
Cross plot –两个或两个以上的数据相互间形成的交会图（也叫做scatter plot（散点图））。 Datum –在测定海拔时用到的一个固定深度、时间值或是一个层面。Depth Contours –层面的等高线，描述相同的深度或时间值。Depth Conversion –将Z值在深度域和时间域间相互转换。 Depth panel –井上的垂向深度标尺。 Display Window –用于显示模型的窗口，分为二维、三维两种类型。Dongle –硬件加密锁（hardware key），也叫做软件防盗锁(software protection key)，它控制着软件模块的使用时间。 Drainage Area –流域，指的是可能产生烃的区域。 Erosion Line –剥蚀线，用于定义层面间的相互削截。 Fault Center Line –3D网格中用于连接断层Pillar中点的线。 Fault Modeling - 在三维空间骨架中建立断面的过程。其第一步就是建立Key Pillar（主要断层柱子）。 Fault Polygon –断层平面和层面间的交线。 Fault Stick (fault dip line) –描述断层的线，通常是贯穿顶部和底部。Fluid Constants （流体常量）–地层体积系数，油Bo，气Bg。GOR：气油比。严格讲采收率不是流体常量，但在Petrel中将其列入了储量计算的流体常量菜单中。 Formation Volume Factor –地层体积系数。地表情况下的烃体积与油藏中的体积之比（油和气的分别为Bo和Bg）。 Function Bar –在微软术语中叫作工具栏（toolbar）。不同的进程中，
一般来说，制造PFD、P&ID，相关专业从事人员都是运用Visio或许AutoCAD、PIDCAD这些软件。软件都各有其长处和缺陷。AutoCAD、PIDCAD这样的纯专业软件，在软件的操作与使用上的 一般都需求花费必定的学习时间，而Visio这样的操作简略便当、又支撑制造多种图表的工艺流程 图制造软件，关于大部分人来说，是相对正确的挑选。但，Visio颇高的价格有时也会让人犹豫是否购买。那有没有类似于Visio这样操作简略、价格又适中的工艺流程图制造软件呢？答案是肯定的。 无需绘图技巧 使用这个功能丰富的流程图软件，您就不必在如何才能创建视觉上很有吸引力的流程图问题很 专业了。您只需输入您的数据，剩下就交给亿图就行了，亿图会自动为您排列所有形状，为获得专 业设计应用专业设计主题等。这个软件让任何层次的用户都能用更短的时间创建更好的流程图。此外，亿图为您节省更多资金，免费为您进行科技支持和升级。 智能地创建视觉流程图
亿图也可以帮助您将文本和图表中的复杂信息翻译成为视觉图表。用这种方式用户就能够识别 瓶颈和低效现象，这些也是过程需要精简的地方。亿图提供智能连接线和高级的文本设计和矢量符号，通过显示浮动对话框告诉你该怎么做。 几分钟获得一个专业的流程图 亿图赋予您能力，简简单单，有效地使用特殊工具，免费的模板和精简的工作流示例就能够创 建出有专业水准的流程图，帮助您快速建立新的流程图、工作流程图、NS图、BPMN图、跨职能 流程图、数据流图和高光流程图等。所有这些图形的绘制仅需短短几分钟即可。 轻松创建交互流程图 插入超链接和插画功能同样包括在内。您可以将图表和基础数据连接起来展示更多地细节信息，这样能够增强效率、影响和交流。为了更加具体一些，你可以通过增加链接到网站、插入附件、添 加注释或者链接到亿图其他视图工具等方式把任何图表转换成信息关口。它们是交互图形，任何人 都可以轻松使用亿图轻松创建。 无缝地分享与合作
一个完整的软件开发流程 一、开发流程图 二、过程产物及要求 本表主要列出开发阶段需要输出的过程产物，包括产物名称、成果描述、负责人及备注，即谁、在什么时间、应该提供什么内容、提供内容的基本方向和形式是什么。 三、过程说明 (一)项目启动 1、产品经理和项目干系人确定项目方向，产品型项目的干系人包括公司领导、产品总监、技术总监等，项目的话则包括客户方领导、主要执行人等。
2、公司领导确认项目组团队组成，包括产品经理、研发项目经理、研发工程师、测试团队等。 3、明确项目管理制度，每个阶段的成果产物需要进行相应的评审，评审有相应的《会议纪要》;从项目启动起，研发项目经理每周提供《项目研发周报》;测试阶段，测试工程师每周提供《项目测试周报》。 4、产品经理进行需求调研，输出《需求调研》文档。需求调研的方式主要有背景资料调查和访谈。 5、产品经理完成《业务梳理》。首先，明确每个项目的目标;其次，梳理项目涉及的角色;再来，每个角色要进行的事项;最后，再梳理整个系统分哪些端口，要有哪些业务模块，每个模块再包含哪些功能。 (二)需求阶段 1、进入可视化产物的输出阶段，产品经理提供最简单也最接近成品的《产品原型》，线框图形式即可。在这个过程中还可能产生的包括业务流程图和页面跳转流程图。业务流程图侧重在不同节点不同角色所进行的操作，页面跳转流程图主要指不同界面间的跳转关系。项目管理者联盟 2、产品经理面向整个团队，进行需求的讲解。 3、研发项目经理根据需求及项目要求，明确《项目里程碑》。根据项目里程表，完成《产品开发计划》，明确详细阶段的时间点，最后根据开发计划，进行《项目任务分解》，完成项目的分工。 4、研发工程师按照各自的分工，进入概要需求阶段。《概要需求》旨在让研发工程师初步理解业务，评估技术可行性。 (三)设计阶段 1、UI设计师根据产品的原型，输出《界面效果图》，并提供界面的标注，最后根据主要的界面，提供一套《UI设计规范》。UI设计规范主要是明确常用界面形式尺寸等，方便研发快速开发。UI设计常涵盖交互的内容。 2、研发工程师在界面效果图，输出《需求规格》，需求规格应包含最终要实现的内容的一切要素。 3、研发工程师完成《概要设计》、《通讯协议》及《表结构设计》，及完成正式编码前的一系列研发设计工作。 (四)开发阶段项目经理博客 1、研发工程师正式进入编码阶段，这个过程虽然大部分时间用来写代码，但是可能还需要进行技术预研、进行需求确认。
软件开发流程规范 目录 目录 0 一、概述 (2) 二、开发流程规范 (3) 2.1系统软硬件开发环境 (3) 2.2系统架构（系统组成） (5) 2.3系统功能模块设计 (6) 2.4系统功能开发流程图 (7) 2.5开发修改记录 (8) 三、开发代码规范 (9) 3.1文件结构 (9) 3.1.1 文件信息声明 (10) 3.1.2头文件的结构 (12) 3.1.3定义文件的结构 (15) 3.1.4 头文件的作用 (17) 3.1.5 目录结构 (18) 3.2命名规则 (18) 3.2.1 共性原则 (19) 3.2.2 Windows变量命名规则 (21) 3.3程序风格 (24) 3.3.1 空行 (25) 3.3.2代码行 (26) 3.3.3代码行内的空格 (29) 3.3.4 对齐 (31) 3.3.5 长行拆分 (33) 3.3.6修饰符的位置 (35) 3.3.7 注释 (35) 3.4函数设计 (40) 3.4.1 参数的规则 (40) 3.4.2返回值的规则 (42) 3.4.3函数内部实现的规则 (47) 3.4.4其它建议 (50) 3.4.5使用断言 (50) 3.4.6 引用与指针的比较 (52) 3.5变量类型定义 (56)
四、软件测试规范 (56) 4.1单元测试 (57) 4.2 系统测试 (57) 4.6 业务测试 (59) 4.7 验收测试 (59) 4.8 用户现场测试 (59) 五、软件版本管理 (60) 4.1 版本管理的必要性 (60)
、概述 本文制定烟台开发区德联软件有限责任公司计算机软件开发规范文档。本规范的目的是使公司软件开发项目阶段清晰、要求明确、任务具体、编写的代码规范，使之规范化、系统化和工程化，向公司内从事软件开发的工程师和管理人员提出一系列规范和要求，从而有利于开发过程的控制和管理，提高所开发软件系统的质量，缩短开发时间，减少开发和维护费用，以保证项目高质量、顺利进行。 本规范包含：开发流程规范和开发代码规范等，开发流程规范需要技术开发人员编写相关内容，希望每个技术人员形成习惯，如有新的内容更新会及时通知大家，如有好的规范要求也可通知编制人员及时更新。 本规范为烟台开发区德联软件有限责任公司内部材料，严禁其他商业应用。
目录 1.加载数据 (4) 1.1 井位数据 (4) 1.2 井斜数据 (4) 1.3 测井曲线加载 (5) 1.4 分层数据加载 (9) 1.5 测井解释成果加载 (13) 1.6 断层加载 (14) 1.7 地震数据加载 (15) 1.8 制作地震子体 (17) 1.9 地震解释 (23) 2.Make surface (32) 2.1 圈定边界 (32) 2.2 做面 (32) 3.调节断层 (37) 3.1 双击加载的断层.TXT文件 (37) 3.2 删掉断层一盘 (37) 3.3 将断层赋给一个面 (38) 4.断层模型 (39) 4.1 初步调整 (39) 4.2 pillar Giidding (45) 4.3 Make horizons (47) 4.4 Make zones (50)
4.5 调节断层上下盘 (51) 4.6 补缺口/horizon (52) 4.7 做垂向网格/layering (56) 5.砂孔建模 (58) 5.1砂体模型（确定性） (58) 5.2砂体模型（指示建模） (66) 5.3夹层模型 (66) 6.沉积相模型—确定性 (70) 6.1 创建沉积相模型 (70) 6.2 相图加载 (71) 6.3 数字化位图 (72) 6.4 生成相多边形曲面/对每个相做surface (74) 6.5 生成相分布曲面 (76) 6.6 相建模 (77) 7.沉积相建模—随机性 (79) 7.1 PPT--序贯指示 (79) 7.2 阳光石油相模型建立--序贯指示 (80) 7.3 沉积相模型建立—聚类分析方法 (86) 8.沉积相相控属性建模 (103) 8.1 孔隙度模 (103) 8.2 渗透率模拟 (112) 8.3 含油饱和度模拟 (118) 9.计算储量 (126) 10.模型粗化 (134) 11 离散化测井曲线 (138)
一个完整的软件开发流程一、开发流程图
二、过程产物及要求 本表主要列出开发阶段需要输出的过程产物，包括产物名称、成果描述、负责人及备注，即谁、在什么时间、应该提供什么内容、提供内容的基本方向和形式是什么。 三、过程说明 (一)项目启动 1、产品经理和项目干系人确定项目方向，产品型项目的干系人包括公司领导、产品总监、技术总监等，项目的话则包括客户方领导、主要执行人等。 2、公司领导确认项目组团队组成，包括产品经理、研发项目经理、研发工程师、测试团队等。
3、明确项目管理制度，每个阶段的成果产物需要进行相应的评审，评审有相应的《会议纪要》;从项目启动起，研发项目经理每周提供《项目研发周报》;测试阶段，测试工程师每周提供《项目测试周报》。 4、产品经理进行需求调研，输出《需求调研》文档。需求调研的方式主要有背景资料调查和访谈。 5、产品经理完成《业务梳理》。首先，明确每个项目的目标;其次，梳理项目涉及的角色;再来，每个角色要进行的事项;最后，再梳理整个系统分哪些端口，要有哪些业务模块，每个模块再包含哪些功能。 (二)需求阶段 1、进入可视化产物的输出阶段，产品经理提供最简单也最接近成品的《产品原型》，线框图形式即可。在这个过程中还可能产生的包括业务流程图和页面跳转流程图。业务流程图侧重在不同节点不同角色所进行的操作，页面跳转流程图主要指不同界面间的跳转关系。项目管理者联盟 2、产品经理面向整个团队，进行需求的讲解。 3、研发项目经理根据需求及项目要求，明确《项目里程碑》。根据项目里程表，完成《产品开发计划》，明确详细阶段的时间点，最后根据开发计划，进行《项目任务分解》，完成项目的分工。 4、研发工程师按照各自的分工，进入概要需求阶段。《概要需求》旨在让研发工程师初步理解业务，评估技术可行性。 (三)设计阶段 1、UI设计师根据产品的原型，输出《界面效果图》，并提供界面的标注，最后根据主要的界面，提供一套《UI设计规范》。UI设计规范主要是明确常用界面形式尺寸等，方便研发快速开发。UI设计常涵盖交互的内容。 2、研发工程师在界面效果图，输出《需求规格》，需求规格应包含最终要实现的内容的一切要素。 3、研发工程师完成《概要设计》、《通讯协议》及《表结构设计》，及完成正式编码前的一系列研发设计工作。 (四)开发阶段项目经理博客 1、研发工程师正式进入编码阶段，这个过程虽然大部分时间用来写代码，但是可能还需要进行技术预研、进行需求确认。 2、编码过程一般还需进行服务端和移动端的联调等。
技术部业务流程 技术部业务流程图 技术部业务流程图 订单接单、设计、审核、下发及存档过程详解
1、技术接单 1.1订单初审 1.1.1技术部根据市场部生产通知单上所下规格型号和基本技术要求及客户来图，初步判断是否为常规订单，分为两种情况： ①若为常规订单则进一步审阅确认图纸资料是否符合要求： 1.1.2检验订单内容 标准如下： Ⅰ、生产通知单上产品名称，型号规格准确清晰； Ⅱ、单位、数量、区域特点标注具体； Ⅲ、技术规范中所勾选内容清晰完善； Ⅳ、技术要求描述清楚到位； Ⅴ、如需要：附有客户来图或技术协议等相关客户资料须有客户签字确认按此方案或要求生产。 1.1.3审阅订单时发现订单图纸资料上有标注不完善或不明确的，返还市 场部让其确认并在订单上注明。 ②若判定为非标订单，则由电气和机械工程师共同评审订单，用订单评审表的形式列出疑难问题，交予市场部，若由市场部与客户进一步沟通后能够解决以上问题，便确定方案能够实施，则可签署订单。若问题还是不能够得到解决，就由技术经理组织相关人员评审订单，讨论出可行性方案，并把此方案传达客户，若客户接受则可签署订单。若客户不能接受则拒签，返还订单到市场部。 1.2订单签收 1.2.1确定以上条件全部准确无误，由技术经理签署订单。
1.2.2签单后应记录本部门签单时间并计划下单时间，同时将订单基本情况录入到跟踪表。 1.2.3复印分发订单到相应的电气、工艺、机械工程师。 2、订单设计 2.1责任工程师接收到订单后根据订单要求及公司规范设计图纸，出具技术材料， 2.2在设计订单过程中电气和机械工程师相互沟通设计上的交叉问题，双方设计意见不一致的，上报到技术经理协商处理，共同配合设计工作的顺利进行，并最终在设计上达成一致， 2.3在设计过程中如果遇到需要与客户商榷或确认的，由责任工程师直接与客户或业务员沟通，仍不能解决问题则提报到技术经理再次沟通，情节复杂或影响重大则上报到公司，由公司出面协商直至问题解决。 2.4订单已确认无疑议后，保证设计工作按时保质保量的进行 3、审核设计 3.1设计初审 3.1.1设计完成后，电气和机械程师相互核对设计上的交叉问题是否处理协调一致，有误则提出问题继续改正，直至完全正确后后交给对应工程师初审设计。 3.1.2交叉问题达成一致后，分别将电气和机械设计材料交予相应工程师审核 审核要求： Ⅰ.订单设计一次系统图、平面布置图与客户确定方案一致,各部分结
一个综合Barnett页岩气藏的工作流程的建模与仿真 C. Du, SPE, X. Zhang, SPE, B. Melton, D. Fullilove, B. Suliman, SPE, S. Gowelly, SPE, D. Grant, SPE,J. Le Calvez, SPE, Schlumberger 这篇文章是准备在2009年5月31日至6月3号在哥伦比亚卡塔赫纳举行的拉丁美洲和加勒比石油工程会议上作为（会议）报告用的。 这篇文章根据作者所提出的包含在摘要中的信息被程序委员会选择出来作为一篇会议上的报告。石油工程师协会没有对本文的内容进行检查，需要作者自己进行校正。该文章不反映石油工程师协会、工作人员和会员的任何态度。电子复制品、分发品，没有经过石油工程师协会的书面同意，任何文件的一部分的存储都是禁止的。允许复制的（范围）限定在不超过300字的摘要，插图可能不能被复制。（被）复制印刷的摘要必须包含显眼的石油工程协会的版权信息。 摘要 密西西比Barnett页岩储层开辟了美国的天然气生产的新时代。做的许多油藏描述方面的努力和完成的一些实际生产，以帮助更加深刻的了解Barnett页岩储层。钻孔图像解译，钻井诱导产生的裂缝和连通的/闭合的裂缝，揭示（地层）应力方向，断层的形貌和方向等解释结果指导水平井设计，控制水力压裂方向和强度。常规测井和岩心分析已经用于对岩相的分类和评价油层物性和地球物理性质，以用于井的定位和储量计算。地震调查不仅用于水平层位和断层的解释，也用于3D物性的评价分析，如岩相分布，离散裂隙网络和应力场。在实际施工方面，多钻较长的水平井和进行大规模的多级、多层次水力压裂处理。大量的井的钻探和水力压裂都被广泛实施。微震（MS）对评价水力压裂所波及到的油藏的体积和压裂产生的断裂强度估算的起到重要作用。 尽管在这个方面巨大的努力和进展，但现有的文献中仍然缺乏一个系统
功能模块主干业务子流程 业务域(LEVEL-2)备注价值链 (LEVEL-1) (LEVEL-0) SBU 总部 股东会议管理流程 董事会会议管理董事会议管理流程 监事会议管理流程 董事会事务工商登记管理流程 董事会事务处理 印章管理流程 股东、董事、监事关系维护流程 参控股公司董事会事务处理流程 公司理念及愿景制定流程 公司战略制定流程 业务战略制定流程 组织与人力资源战略制定流程 战略研究与制定 资本运营战略制定流程 品牌战略制定流程 信息化战略制定流程 金融战略制定流程 战略管理 文化战略战略制定流程 质量战略制定流程 战略预算制定流程 战略计划制定流程 战略预算与战略计 划
战略预算与战略计 新业务开发计划制定流程 划 投资战略计划制定流程 并购战略计划制定流程 战略战略战略评价流程 战略评价与战略绩 战略沟通与推动流程 效管理 战略绩效管理及调整流程 国际合作研究全球整合资源研究与动态监控流程 国际合作国际合作事务管理流程 国际合作管理 国际合作项目管理流程 经营目标管理经营目标制定流程经营目标分解流程 经营计划制定流程经营计划制定流程 经营计划管理 经营过程控制流程经营过程控制流程 运营分析及调整运营分析及调整流程运营分析及调整流程运营管理经营绩效考核体系设计流程事业部绩效管理体系建设流程 经营绩效统计平台设计流程 运营绩效管理经营绩效数据收集与统计流程 经营完成情况评价流程 经营目标执行激励流程 目标市场和消费者研究流程目标市场和消费者研究流程 市场研究 标杆及竞争者研究流程标杆及竞争者研究流程 产品技术路线及资源分析流程 制定产品规划流程 产品规划 关键技术与资源规划流程 产品规划
市场环境与客户需求不断变化，如何建立以市场/客户为导向的快速响应机制？ 随着外界环境和内部人事的变化，分工要不断调整，总感觉管理的变化赶不上业务的变化，无论怎么反复调整职责分工方案，仍存在盲点、重叠、推诿、扯皮... “公司已经建立过ISO9000、内控、HSE等多个管理体系，这些管理体系最终变成一个个手册、制度规范，放在不同的文件柜里，执行起来相互不一致，久而久之，制度和业务变成两张皮。” 各职能部门在工作目标和推进计划上各自为战，跨部门扯皮多、协同难。 制度多，无执行，精细化和量化管理只是口号，没法落实。 构建企业流程框架和流程清单：建立企业端到端的流程框架和分类分级的流程清单，为全面的流程梳理和优化建立起清晰的结构框架，解决管理交叉或真空地带;明确各级流程的责任人，落实流程监控与持续优化的责任主体。 关键流程梳理优化：选择关键流程进行梳理优化，明晰跨部门的职责和接口/协同关系，打破部门壁垒，推动部门间共识形成(做正确的事)。建立流程运作的标准规范和方法工具，形成指导业务的标准化手册，使企业过去的成功经验得以有效的积累和传承，提升组织运作效率（正确的做事）。 建立流程制度文件管理体系，整合企业各类管理体系和制度标准。 建立流程治理体系，以及流程的执行保障措施，形成流程管理长效机制。 清晰化流程制度框架，解决管理交叉或真空地带。 沉淀企业管理经验，形成标准化规范化业务运作。 形成流程长效机制，保障流程持续优化和执行落地。
●流程是对业务的一种表述方式，流程的先进性决定了业务的先进性和企业的竞争地位。企业应该建立以客户为导向的业务流程，保证企业战略目标的有效落地。 ●问题导向的流程优化，是见到效益与效率的关键。 ●流程梳理是提升企业基础管理水平的关键;与企业核心成员一起开展流程管理工作，是建立企业内部流程管理顾问的关键。
主要模块介绍 一、数据准备 本实例中的数据整理如下： wellhead井位坐标文件 jinghao X Y kb topdepth bottomdepth X21-233973816364714261433.0821502195 X21-243974070364716291433.082156.12193.1 X21-253974257364718491433.082154.42190.4 X21-263974480364720961436.52154.82189.8 X22-193972535364705161407.562120.32152.3 X22-203972803364707951417.462139.12165.1 X22-213973010364710401379.72102.62135.6 welltop分层文件 X Y hb wellpoint surface jinghao 397381636471426-716.92Horizon c811X21-23 397381636471426-724.92Horizon c8121X21-23 397381636471426-735.92Horizon c8122X21-23 397381636471426-755.92Horizon c813X21-23 397381636471426-761.92Horizon c821X21-23 397407036471629-723.02Horizon c811X21-24 397407036471629-731.02Horizon c8121X21-24 397407036471629-742.02Horizon c8122X21-24 397407036471629-754.02Horizon c813X21-24 397407036471629-760.02Horizon c821X21-24 测井文件准备 DEPTH PERM_K POR_K SW_K VSH_K NTG 2140.1250.00590100 2140.250.0059010 1 2140.3750.00590100 2140.50.005900 1 0 二、数据输入 1 输入WellHeader（井位坐标文件） 右键点击输入Well Header:
软件开发过程规范范文 1. 前言 1.1 目的 本规范的目的是使整个软件产品开发及项目工程阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化。有利于提高软件生命周期的控制及管理，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。 1.2 对象 本规范面向产品生命周期的所有相关人员，包括管理人员、开发人员、质管人员。 1.3 要求 具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。 1.4 适用范围 适用于产品开发生命周期中的除产品提交外的其他全部过程；规范分为两部分：技术过程规范和管理过程规范，分别适用于软件开发过程中的技术性活动和管理性活动。 1.5 软件开发过程模型 本规范所采用的软件开发过程模型为简化的RUP开发过程模型；软件开发过程是体系结构为中心，用例驱动和风险驱动相结合的过程迭代。 1.6 开发过程划分 开发过程包括多次迭代，每次迭代的目标和侧重点不同；较早的迭代侧重于业务建模和需求建模；而后的迭代则侧重于分析设计和编码。 2. 技术过程规范部分 2.1 概述 本规范中将软件开发的整个技术过程分为四个顺序实施的阶段，分别为业务建模阶段、需求阶段、分析设计阶段和实现阶段。在对技术过程规范的描述，按阶段内部的活动和产物对四个阶段分别说明。 在本规范中对阶段内活动的说明，是按顺序性活动和持续性活动两类分别进行说明。
对于顺序性活动是按该阶段中活动的总体顺序进行的描述，而在实际工作中，从各活动的具体实施的细节来看，各活动之间的顺序是不断交叉变化的。对于持续性活动主要是对贯穿该阶段过程始终的技术活动进行说明。 规范中所提到的可选文档是指在其所属阶段，可根据具体情况灵活掌握，开发团队自主决定是否开发的文档产物。而提交文档则是指在项目开发过程中必须开发的文档产物，但可根据具体项目情况，在软件开发计划中明确规定是否要形成正式文档并提交。 规范中各阶段提到的技术评审，具体参见《评审规范》中所对应技术性评审的详细描述。 2.2 业务建模阶段 2.2.1 顺序性活动描述 1)开始初步调研，获取初始业务需求，进行问题定义，形成《业 务概览》并建立《术语表》； 2)制定《调研记录表册》，实施详细的业务调研，建立初始的 业务用例模型和《业务用例规格》； 3)分析业务过程，取出可以实现自动化的用例，分析业务部门 和实体对象，形成初始的业务对象模型； 4)根据初始业务对象模型和初始业务用例模型，分析并提取与 系统实现相关的用例和模型，建立系统域模型； 5)精化域模型中的初始用例，详细描述业务流程，分析业务规 则，建立精化的业务用例模型，形成《业务规则》和《业务 用例规格》； 6)精化域模型中的初始对象，进行详细的对象描述，分析对象 职责和对象间关系，建立精化的业务对象模型，形成《业务 对象纵览》； 7)分析业务上的非功能性需求，形成《增补业务规格》； 8)应用业务对象，实现业务用例，制定《业务用例实现规格》， 以验证业务对象与业务用例的正确性，根据验证结果，修正 业务对象、业务用例及相关文档； 9)汇总《业务规则》《业务用例规格》《业务对象纵览》《增 补业务规格》和《业务用例实现规格》形成《业务架构文档》。 2.2.2 持续性活动描述 1)《业务概览》在业务建模阶段，根据对项目理解的不断加深， 随时进行改进； 2)《术语表》的更新维护； 2.2.3 提交文档 1)《业务概览》 2)《术语表》 3)《调研记录表册》 4)《业务架构文档》其附件包括：《业务规则》《业务用例规