软件版本发布流程
目录
1、目的 (3)
2、范围 (3)
3、涉及的干系人 (3)
3.1 项目经理（PM，Project Manager） (3)
3.2配置管理员（CMO，Configuration Management
Officer） (3)
3.3测试人员（TP） (3)
4、版本发布流程 (4)
4.1版本发布流程图 (4)
4.2版本发布流程描述 (4)
5、涉及的表单和模板 (4)
1、目的
为了确保测试人员的版本和开发人员发布的版本一致，不会出现版本混乱，保证测试代码版本的稳定性，以及开发代码版本的可控性，使基线库完全的受控起来。通过版本发布、基线发布报告等规程来保证软件生命过程中所有产品的完整性、一致性、可追溯性，同时也保证测试人员的工作效率。若是要变更必须走变更流程。
2、范围
适用于整个高铁事业部纳入配置管理中的所有项目。
3、涉及的干系人
3.1 项目经理（PM，Project Manager）
项目经理是整个信息系统开发和维护活动的负责人，他批准配置管理的各项活动并控制他们的进程。具体职责如下：
1）在项目将要进行编码阶段，就要使用SVN库，根据代码包含的模块在src和release 下建立相应的文件夹，已明确区分，并每天要督促项目开发人员从SVN上上传和下载代码，并对每个重要的代码上传进行标注。
2）项目要开始测试时，需填写《版本发布报告》，交给配置管理人员；
3）将代码的可执行程序或代码上传到SVN目录结构下的code下相关的文件夹下；
4）Web类的测试程序需搭建服务器，并将访问的网址、用户名、密码等以书面的形式发给测试人员。
3.2配置管理员（CMO，Configuration Management Officer）
根据配置管理计划执行各项管理任务，其具体的工作职责如下：
1）根据项目经理提交的《版本发布报告》，将相关的内容打基线，确定测试版本；
2）发送《基线发布报告》给部门经理、开发人员、测试人员等，确定可以开始测试；
3）为测试人员增加SVN的库中该项目基线库的访问权限。
3.3测试人员（TP）
根据测试计划，执行测试任务，其具体工作职责如下：
1）根据《基线发布报告》在SVN基线库中获取代码或可执行程序；
2）W eb类型的根据项目经理的发的访问网址、用户名、密码等登录系统，进行测试；
3）将每一轮测试的bug提交到mantis上。
4、版本发布流程
4.1版本发布流程图
4.2版本发布流程描述
1）项目从将要开始编码起就要求要使用SVN,每天进行上传和下载代码，进行标记，对应的VS 和eclipse都有对应的SVN插件；
2）项目代码编写阶段结束后，要进入测试阶段进行测试，项目经理需向配置管理员提交《版本发布报告》并将代码上传到SVN；
3）配置管理员根据《版本发布报告》将代码打基线，并产生《基线发布报告》发送给项目组的开发、测试人员、以及与项目相关的领导；
4）测试人员可以从SVN中基线库取代码，进行第一轮测试，测试过程中产生Bug，开发人员修改Bug。
5）Bug修改结束后，进入第二轮测试阶段；
接下来的过程和上面从2）到5）描述的一样，直到测试人员通过测试为止。5、涉及的表单和模板
版本发布流程涉及《版本发布报告》和《基线发布报告》。
软件开发流程管理制度 （讨论稿） 为加强对定制软件开发工作管理，缩短开发周期，提高软件开发质量，降低开发成本，提高定开发效率和效益，特制定软件开发流程管理制度。 第一章、总则 为保证日常工作正常有序的进行，让开发中各个环境更紧凑，更可控，需要尽可能实现项目管理的正规化，工作过程的流程化，以便提高软件质量，按期交付。 1、软件开发总体遵循项目管理和软件工程的基本原则。 2、项目管理涉及项目立项、项目计划和监控、配置管理。 3、软件工程涉及需求分析、系统设计、软件实现、系统测试、用户测试、试运行、系统验收、系统上线和数据迁移、产品维护。 第二章、阶段成果 根据软件工程的过程，制定以下工作流程，并规定了各个重要环节需要提交的交付物。各阶段需提交的文档： 1、立项：项目申请表，软件需求报告或设计方案。 2、需求分析：项目研发主计划、需求规格说明书 3、总体设计：概要设计说明书或功能模块描述 4、详细设计：详细设计说明书，包括软件接口说明、单元测试计
划。 5、软件实现：软件功能说明、源代码说明或者注释 6、产品测试：测试报告 7、产品发布：产品说明书、使用手册 8、产品维护：问题反馈记录 9、项目总结：提交客户方的项目总结和公司项目汇报的PPT。软件过程成果表：
第三章、岗位设置 根据公司目前的开发过程主要分为分析、开发、测试三个阶段。分析阶段完成用户需求文档的编写，系统总体设计的编写；开发阶段完成设计文档的编写，代码的编写、代码的维护。测试阶段完成系统的测试，测试文档及其他材料。通过逐渐的调整岗位，明确工作职责，逐步实现项目经理，软件设计师，程序员，测试工程师的岗位设置。
1 / 5 1. 目的 制定软件产品开发运作管理程序，对软件开发过程的各个工作阶段予以识别和控制，实施过程管理程序和质量控制，使软件开发过程各阶段得以有序进行，不符 受 控 分发号
合项得到及时发现并纠正，确保软件开发项目的工程质量符合客户的要求。 2. 范围 适用于公司各种类型的软件产品开发活动：内部立项开发项目、客户委托开发项目、招投标项目等等包含软件产品开发的运作过程。 3. 职责 3．1中心副总经理：负责组织内部项目的立项申请、软件开发项目的项目任务定义、组织和软件开发技术评审，负责技术开发的外部联合有关事宜，指导开发部经理确定项目经理。 3．2软件开发部经理：协助中心副总经理进行项目任务定义和软件开发技术评审，确定软件开发项目经理，合理配置开发项目各种资源，监督项目经理执行软件开发运作程序及项目过程质量控制，并协同质量管理部人员对开发项目进行检查验收。与项目经理共同负责软件产品开发完成后的归档工作。 3．3项目经理：负责软件产品开发的执行过程：从项目任务书下达开始，对开发计划、需求开发、概要设计、测试设计与计划、数据库设计、详细设计、编码、测试、编写用户手册（或操作手册）、模块开发卷宗、试运行、验收等产品开发活动的全过程实施负责，对产品概要设计、数据库设计、详细设计的实施负责。并负责项目开发完成后的归档。 3．4开发人员（软件工程师）：配合项目经理，对指定任务的需求调研、详细设计、编码及单元测试、手册内容编写、测试任务、模块卷宗开发负责。配合项目经理进行开发文件、卷宗的编篡归档工作。 4. 程序内容 4. 1软件产品开发流程图 (左侧为工作阶段名称，右侧为工作相关产品，括号中的编号是文档的编号)
版本控制流程规范V HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】
版本控制流程规范文档 目录 一、编写目的 本文档主要目的是规范配置管理活动的过程，阐述了在项目开发、测试、实施的过程中SVN库的组成和使用规约，指导使用者正确地操作SVN 库，以保证项目中所产生的代码、文档各版本之间完整性、可追踪性和一致性。 二、适用范围 该规范适用于公司内部所有项目的配置管理过程。 三、环境资源 在整个项目过程或产品生命周期中,选择SVN作为配置管理工具。
四、职责 五、规范 1，用户命名及权限配置 1)SVN用户命名 项目组成员在各自的PC上安装SVN客户端，根据配置管 理员所分配的用户和权限登录配置库进行各项配置管理活 动。 初始用户命名规则： 用户名：公司邮箱@前的部分
密码：手机号后6位 2)访问约定 为了保证各个项目组开发成果的安全性，以项目为单位， 进行了精确权限划分，使得成员只能操作该项目组内的配 置项。 内网访问svn资源库地址： svn: ... /svn/项目名称 3)权限管理 各个项目组成员只能访问、操作各自的项目库，并具有特 定文件区域的读、写权限，配置管理员统一分配和管理权 限。 2，SVN库的划分 根据公司的项目，采用项目名—分区名—版本名—的主结构进行管理。 1)版本库名 根据项目名称由项目经理与配置管理员共同设定。各项目 统一建立2层目录，子目录根据实际情况建立。 2)文件结构 a)工作区：按版本存放提交测试阶段的相关程序、文档等 开发：开发相关 测试：测试相关
一个完整的软件开发流程 一、开发流程图 二、过程产物及要求 本表主要列出开发阶段需要输出的过程产物，包括产物名称、成果描述、负责人及备注，即谁、在什么时间、应该提供什么内容、提供内容的基本方向和形式是什么。 三、过程说明 (一)项目启动 1、产品经理和项目干系人确定项目方向，产品型项目的干系人包括公司领导、产品总监、技术总监等，项目的话则包括客户方领导、主要执行人等。
2、公司领导确认项目组团队组成，包括产品经理、研发项目经理、研发工程师、测试团队等。 3、明确项目管理制度，每个阶段的成果产物需要进行相应的评审，评审有相应的《会议纪要》;从项目启动起，研发项目经理每周提供《项目研发周报》;测试阶段，测试工程师每周提供《项目测试周报》。 4、产品经理进行需求调研，输出《需求调研》文档。需求调研的方式主要有背景资料调查和访谈。 5、产品经理完成《业务梳理》。首先，明确每个项目的目标;其次，梳理项目涉及的角色;再来，每个角色要进行的事项;最后，再梳理整个系统分哪些端口，要有哪些业务模块，每个模块再包含哪些功能。 (二)需求阶段 1、进入可视化产物的输出阶段，产品经理提供最简单也最接近成品的《产品原型》，线框图形式即可。在这个过程中还可能产生的包括业务流程图和页面跳转流程图。业务流程图侧重在不同节点不同角色所进行的操作，页面跳转流程图主要指不同界面间的跳转关系。项目管理者联盟 2、产品经理面向整个团队，进行需求的讲解。 3、研发项目经理根据需求及项目要求，明确《项目里程碑》。根据项目里程表，完成《产品开发计划》，明确详细阶段的时间点，最后根据开发计划，进行《项目任务分解》，完成项目的分工。 4、研发工程师按照各自的分工，进入概要需求阶段。《概要需求》旨在让研发工程师初步理解业务，评估技术可行性。 (三)设计阶段 1、UI设计师根据产品的原型，输出《界面效果图》，并提供界面的标注，最后根据主要的界面，提供一套《UI设计规范》。UI设计规范主要是明确常用界面形式尺寸等，方便研发快速开发。UI设计常涵盖交互的内容。 2、研发工程师在界面效果图，输出《需求规格》，需求规格应包含最终要实现的内容的一切要素。 3、研发工程师完成《概要设计》、《通讯协议》及《表结构设计》，及完成正式编码前的一系列研发设计工作。 (四)开发阶段项目经理博客 1、研发工程师正式进入编码阶段，这个过程虽然大部分时间用来写代码，但是可能还需要进行技术预研、进行需求确认。
一、确定工艺流程：供料—— 圈圆——高频焊接——补涂——烘干 （1） 供料 ① 用机械手将一摞铁皮放置于托盘之上，由带有传感器发射器的机械托盘 带动铁皮上抬运输。 ② 如图1和图2.1所示，将铁皮升高至光电管处（光电管与吸盘为同一高度， 未画出），由带有吸盘的机械手吸起，放置Z 字形轨道进行圈圆。 ③ 如图2.1所示，若铁皮高度低于光电管时，反馈信号。由控制系统控制托 盘继续上移，光电管失去信号后1s ，停止上移。 ④ 如图2.2所示，此时红外测距传感器检测到托盘侧面的信号，反馈至控制系统。此时托盘下降至最低位置，由机械臂将新铁皮装入托盘。 （2） 圈圆 图2.1 托盘工作 图1. 工艺流程图 图2.2 上料
进入“Z”字形轨道将铁皮圈圆。由槽轮带动含吸铁石的轨道吸引前进，送至焊接处。 （3）高频焊接 ①用铜丝辅助对单张圈圆的铁皮进行电阻高 频焊接。 图3 电阻焊 ②如图3，由侧面推杆推桶底进入焊接位置由光电管检测，当进入被圈 圆的铁皮时反馈信号，进行焊接。等到焊接结束，由传送带传 动送至补涂处。 （4）补涂 ①焊接结束后由传送带运输，使用光电管控制，对桶外（内）壁进行补涂。 ②如图4，由光电管检测，当有桶时，反馈信号，喷头喷漆并由毛刷刷平。 图4 补涂 （5）烘干 使用链传动，18L方罐采用回转式的电磁烘干机进行烘干。送入下一阶段进行胀方。 二、控制要求 （1）伺服电机1工作，带动机械手（吸盘）移动到铁皮上方后下降至光电检测器1失去信号（此位置即吸盘与铁皮接触）。 （2）机械手上的气动装置打开，使吸盘吸附铁皮。 （3）机械手运动到滚轮下方（经过一个单张检测仪），气动装置关闭。 （4）机械手吸住铁皮运动至圈圆处，进入“Z”字形轨道
XXXX 文件管理控制程序
文件修订履历 变化状态：新建，增加，修改,删除
目录 1目的 (4) 2适用范围 (4) 3职责 (4) 4术语和定义 (4) 4.1文件编写 (5) 4.2文件审批 (5) 4.3文件发放 (5) 4.4文件检查 (5) 4.5文件更改 (5) 4.6文件作废 (5) 5内容 (6) 5.1文件编码 (6) 5.2文件版本 (6) 5.3文件格式 (7) 6附则 (7) 7附录 (8) 附录 1 ISMS 文件清单 (8) 附录 2 文件更改记录 (11) 附录 3 文件签阅表 (13)
XXXX 文件管理控制程序 1目的 对信息安全管理体系文件的编制、审批、发放、检查、更改、废除等过程实施控制，保持体系运行各环节相关文件的有效性。 2适用范围 适用于XXXX的文件的编写、审批、颁发、版本升级以及失效文件的回收、留用和报废处理过程。 3职责 1、所有信息安全管理体系文件由信息安全管理委员会负责控制。 2、程序文件和记录文件由使用部门进行调用。 3、各部门负责管理本部门体系运行相关文件。 4术语和定义 1、单位内部文件：由单位内部（包括单位级、各部门和各项目组）编写、审批、颁发、版本更新和做失效处理的文件。 2、外来文件：来自于单位外部的文件，包括： 国家或行业的法令、法规； 从客户处正式收到的需求文件、设计书、开发规范和行业标准等； 设计所需的手册、技术资料或由合作伙伴提供的与单位业务相关的文件等。 3、受控文件：按照已批准的颁发范围颁发的文件。这些文件需要按照文件的编写、审批、标识、颁发、版本更新等过程管理规定进行控制和管理。 4、参考文件：为了研修、市场或者商务合作的需要，发放给颁发范围以外的人的文件。在版本更新时，通常不会通知这些文件的使用者。 5、失效文件：文件版本更新后不再使用的旧版文件。 6、废止文件：由于单位规章、规定的变更和调整而被废弃不用的文件。 7、基线化：基线是文档的一个稳定版本。它是进一步开发的基础。之后执行管理体系时将按照基线化的文档规定进行，如果文档需要变动，通过评审后需要重新基线，后续执行按照新的基线进行。 8、记录：日常工作中由于业务、行政、管理产生的包含某种结果或其他输出的文档。
软件发布流程1目的 为了规范软件产品的版本发布过程，提高软件发布的可控性。2范围 适用于公司所有软件产品的发布。 3角色与职责 4软件发布流程 公司软件产品发布的流程如下： 1.1发布准备 软件开发完成，开发人员完成自测，并确定发布日期。 自测应当完成对以下内容的确认： 1)原有BUG是否彻底解决； 2)增加的功能，修改的功能； 3)新增功能是否达到需求及设计要求； 4)所做的改变带来的影响； 1.2提交测试 软件负责人提出测试申请，并明确以下内容： 1)软件版本号； 2)新增或修改了哪些功能；
3)修复了哪些BUG； 4)更改后的影响分析及测试建议； 1.3执行测试 测试负责人接收测试申请后，启动软件测试，完成后反馈测试结果。 测试结果应包含以下内容： 1)原有BUG的解决情况； 2)BUG的新增情况； 3)测试用例执行情况； 1.4发布评审 软件经过全面测试后，由质量部SQA负责审核并判断软件是否达到发布要求。 发布评审中对软件缺陷的要求是：致命、严重级别缺陷为0，一般级别缺陷解决率为95%，轻微级别缺陷解决率为90%。 说明： 缺陷级别划分为四级：致命、严重、一般、轻微。 1.5源码、文档入库 软件负责人安排将软件源代码及文档入库。 源码包括软件所有源代码；文档包括需求、设计、测试文档，安装手册、使用手册等。 1.6程序打包 软件负责人安排将程序打包，标记源码、文档版本tag等。 1.7编写发布说明 软件负责人安排编写产品发布说明（或者release note）。 Readme的内容应该包括 1)产品版本说明； 2)产品概要介绍； 3)本次发布包含的文件包、文档说明； 4)本次发布包含或者新增的功能特性说明； 5)遗留问题及影响说明； 6)版权声明以及其他需要说明的事项。
生产工艺流程控制的规程（草稿） 一、目的 为加强企业的生产工艺流程控制，全面提升产品的制作质量，降低生产成本，各相关部门和人员按照优化5M1E（注1）的原则进行生产活动，增强企业的竞争力，特制订本规程。 ——注1：5M1E分别是英文-人员、机器、材料、方法、测量和环境的单词首位字母。 二、使用范围 本集团下属各公司的应依据本规程来制订、执改进行、生产工艺流程、对其结果进行考核、奖惩，除另有规定外，均以本规程执行； 三、规程的内容： 1、工艺流程涉及的部门（体系化） 工艺流程涉及的部门有：各公司的技术部、生产部、质检部、和集团采购部。 2、管理责任（制度化） （1）各公司技术部责任 a,制定合理的工艺流程文件 各公司的技术部依据产品任务单，制定生产工艺流程的文件，工艺流程文件的主要是以下三种类： ——工艺过程卡片；
——工序卡片； ——操作说明书； 工艺流程的卡片和操作说明书中应包含：图纸（加工的工件图纸以及关键步骤和重要环节都有图纸说明）、加工工序、加工方法及对环境的要求、检验及方法、产品的包装、工时定额、材料和物耗定额、使用的设备和工装、加工工具、对特殊工件的吊装位置及方法、包装方法、加工的起始时间、责任者的签名等，总之应当是实际工作中涉及的工序和各个工序中要点（5M1E）都要简约地反映在流程中；——注2：工时定额和物耗定额：在实际中灵活应用和执行，对于首件和单件生产可以是定性管理；对于3-5件的小批量生产应当是首件完成后，对出其余件进行的半定量管理，就是给个范围值；对于成熟的大批量生产件应当是定量管理，就是应当给出固定的定额；——注3：可以有空项，按实际生产中需要的项目编写，应当简要全面部不应当有漏项；各个公司在制定工艺流程时，可以是表格式、卡片式、文字表述式，只要能在实际生产中，对生产的产品有以下作用即可--加工的指导、检验指导、记录完整（可以追溯产品的加工历史）；b,根据生产出现的问题，可以用工艺流程附加单的形式进行补充及修改，必要时废除老工艺，重新制定新工艺； c,会同质检部门处理质量异常问题。 （2）各公司生产部责任
ISO9002-全套制度及业务流程之文件管理程序目的及范畴：建立公司文件制作、审核、批准、发放、回收及更新、储存等程序，确保公司文件得到及时准确的处理和安全有效的运转。该程序适用于以上环节所涉及的有关部门及个人。 职责： 总经理室负责公司文件治理的总和谐及总监督，并受理各部门有关文件延误的投诉； 各部室资料员负责文件治理的具体工作，即收发、登记、传递、用印、立卷、归档和销毁等。 工作流程： 3.1 文件分类： 3.1.1 通用文件：指公司在生产经营活动中普遍使用的文件，分为内部文件、外来文件和外送文件。 A. 内部文件：即公司制作的只在公司内部使用的文件。如请示单、报告、工作联系函、通知、会议文件、周记、制度文件等 B. 外来文件：即公司收到的由外单位制发的文件。如法律法规、政府来文、供方来文、顾客来文、公共事业单位来文等 C. 外送文件：即公司制作的对外发出的文件。如对政府、供方、顾客、公共事业单位发出的文件等 3.1.2 专用文件：指只在公司一定工作部门或业务范畴内使用的专门文件。分为技术文件、财务文件、人事资料、合同文件和签价单和决算资料等。 技术文件：即以图纸为核心的工程建设专用文件。如报批文件、标准图集、内业资料、图纸等。 财务文件：即在公司会计工作中形成和使用的会计核算专业材料。如会计凭证、帐簿、报表及有关的财务报告等。 人事资料：即公司职员在应聘、转正、考评等人事活动中形成的反映个人差不多情形、工作表现的个人资料。
合同文件：即在公司生产经营活动中与外单位签定的具有法律效力的文件。如各类工程合同、设计合同、售楼合同等。 签价单：即审计核算部在签价认价时专用的文件。 F．决算资料：即审计核算部在办理工程结算审核过程中产生的文件。 3.1.3 记录：即公司各项质量活动留下的记录，是一种专门类型的文件。如合格供应商名录、培训记录、各类签到表、登记表等 3.2 总要求： 3.2.1 文件处理必须做到及时、准确、安全。 3.2.2 内外行文要求做到格式统一、要素完整、文号分明。对外行文采纳国家公文格式，内部行文按公司惯例采纳英文格式。（格式及具体规定详见第三层次文件《**集团文件处理方法》之第二章“文件格式”） 3.2.3 各部室资料员为公司文件流转的进出口，文件不承诺由拟写人直截了当送领导者个人，因专门情形必须越过传递的，应于事后按程序补办登记。 3.2.4 各部室资料员要做好文书立卷工作。每年年初，按照以往本部门文件的运转情形，估量当年可能形成的文件，拟制或修订立卷类目。 3.2.5 各部室资料员要建立本部门的文件清单。即按照3.2.4订立的立卷类目，将空白的文件清单置于该类目的最前面；随时将已发放完毕的文件按已编好的类目归入卷内，并按文件收进顺序填写文件清单。 3.2.6 文件的治理一样要通过如下几个环节： 登记：收发文（除便条、介绍信、回执等）应登记在相应的收文发文登记本上或直截了当在文件上签收并及时整理文件名目。来图加盖受控分发号。 用印：公司印章由总经理秘书保管，部门公章由各部室资料员保管。用印时，应以有关部门主管签发的文字或经部门经理签字的盖章联系单为依据。 发放：各部室资料员按照批准的发放范畴进行分发。制度文件换版时，由总经理室或有关部门按照发放清单发出新版文件。
一、软件产品开发流程图：
二、软件产品发布流程 1、发布准备。发布之前，所有程序由测试人员进行确认测试；检查系统内登记的所有bug 都已经被解决，或者遗留的bug不影响系统的使用，如果有严重bug未解决，则不能发布；程序打包前做冒烟测试（冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。）。（测试） 2、测试负责人编写发布产品质量报告进行质量分析和总结。 3、源码、文档入库。源码包括数据库创建脚本（含静态数据）、编译构建脚本和所有源代码； 文档包括需求、设计、测试文档，安装手册、使用手册、二次开发手册、产品介绍（ppt）、使用demo等等。（按合同规定，或只提供部分文档）（产品、项目经理、研发、测试） 4、进行程序打包；标记源码、文档版本。（研发、运维） 5、填写发布基线通知，并通知相关人员；经理对发布基线进行审计检查。（项目经理） 6、在禅道系统上新建产品发布计划，填写配置项，发布产品。（项目经理） 7、传程序包、使用文档至Download站点。（运维） 8、编写发布说明。内容应该包括产品版本说明；产品概要介绍；本次发布包含的文件包、 文档说明；本次发布包含或者新增的功能特性说明；遗留问题、影响说明；版权声明以及其他需要说明的事项。（项目经理、测试） 9、正式发布通知。通知开发、测试、市场、销售各相关部门并附上产品发布说明和产品介 绍。（项目经理邮件通知） 10、后续工作。产品发布后，在使用过程中可能还会发现一些bug。在不影响正常使用 的情况下，这些bug将在下一版本发布时解决；如果bug严重影响使用，必须打patch 或者按照流程重新发布。（研发） 11、临时发布。软件产品未正式发布前，可能需要一个临时版本供开发人员或者用户应 急使用，这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员；研发人员需要为源码、文档打tag标记。 （研发） 12、附《常见问题排除手册》，内容简介：推荐硬件配置。（售后） 13、文件命名规则：惠朗_项目名_文件名称_版本号.xxx。如，惠朗_无锡银行_POC文档 _V1.0.doc。（ALL）。 14、写Readme，后有DEMO。（项目经理） 注意事项： 尽量使用Jekenis，如果没有，可将测试程序上传禅道。程序如果过大可以上传到文件服务器。 发版的程序一定要上传禅道或文件服务器。 Readme:（打到war包里，记录版本号，改进内容，项目名称，甲方，400电话等） 以下为DEMO =========================== ###########环境依赖 Mysql5.7+ redis ~
24．文件管理程序 1．目的及范围：建立公司文件制作、审核、批准、发放、回收及更新、保存等程序，确保公司文件得到及时准确的处理和安全有效的运转。该程序适用于以上环节所涉及的相关部门及个人。 2．职责： 2.1总经理室负责公司文件管理的总协调及总监督，并受理各部门有关文件延误的投 诉； 2.2各部室资料员负责文件管理的具体工作，即收发、登记、传递、用印、立卷、归 档和销毁等。 3．工作流程： 3.1 文件分类： 3.1.1 通用文件：指公司在生产经营活动中普遍使用的文件，分为内部文件、外来文 件和外送文件。 A. 内部文件：即公司制作的只在公司内部使用的文件。如请示单、报告、工作联 系函、通知、会议文件、周记、制度文件等 B. 外来文件：即公司收到的由外单位制发的文件。如法律法规、政府来文、供方 来文、顾客来文、公共事业单位来文等 C. 外送文件：即公司制作的对外发出的文件。如对政府、供方、顾客、公共事业 单位发出的文件等 3.1.2 专用文件：指只在公司一定工作部门或业务范围内使用的专门文件。分为技术 文件、财务文件、人事资料、合同文件和签价单和决算资料等。
A．技术文件：即以图纸为核心的工程建设专用文件。如报批文件、标准图集、内业资料、图纸等。 B．财务文件：即在公司会计工作中形成和使用的会计核算专业材料。如会计凭证、帐簿、报表及相关的财务报告等。 C．人事资料：即公司员工在应聘、转正、考评等人事活动中形成的反映个人基本情况、工作表现的个人资料。 D．合同文件：即在公司生产经营活动中与外单位签定的具有法律效力的文件。如各类工程合同、设计合同、售楼合同等。 E．签价单：即审计核算部在签价认价时专用的文件。 F．决算资料：即审计核算部在办理工程结算审核过程中产生的文件。 3.1.3 记录：即公司各项质量活动留下的记录，是一种特殊类型的文件。如合格供应 商名录、培训记录、各类签到表、登记表等 3.2 总要求： 3.2.1 文件处理必须做到及时、准确、安全。 3.2.2 内外行文要求做到格式统一、要素完整、文号分明。对外行文采用国家公文格 式，内部行文按公司惯例采用英文格式。（格式及具体规定详见第三层次文件《** 集团文件处理办法》之第二章“文件格式”） 3.2.3 各部室资料员为公司文件流转的进出口，文件不允许由拟写人直接送领导者个 人，因特殊情况必须越过传递的，应于事后按程序补办登记。 3.2.4 各部室资料员要做好文书立卷工作。每年年初，根据以往本部门文件的运转情 况，预计当年可能形成的文件，拟制或修订立卷类目。
一个完整的软件开发流程一、开发流程图
二、过程产物及要求 本表主要列出开发阶段需要输出的过程产物，包括产物名称、成果描述、负责人及备注，即谁、在什么时间、应该提供什么内容、提供内容的基本方向和形式是什么。 三、过程说明 (一)项目启动 1、产品经理和项目干系人确定项目方向，产品型项目的干系人包括公司领导、产品总监、技术总监等，项目的话则包括客户方领导、主要执行人等。 2、公司领导确认项目组团队组成，包括产品经理、研发项目经理、研发工程师、测试团队等。
3、明确项目管理制度，每个阶段的成果产物需要进行相应的评审，评审有相应的《会议纪要》;从项目启动起，研发项目经理每周提供《项目研发周报》;测试阶段，测试工程师每周提供《项目测试周报》。 4、产品经理进行需求调研，输出《需求调研》文档。需求调研的方式主要有背景资料调查和访谈。 5、产品经理完成《业务梳理》。首先，明确每个项目的目标;其次，梳理项目涉及的角色;再来，每个角色要进行的事项;最后，再梳理整个系统分哪些端口，要有哪些业务模块，每个模块再包含哪些功能。 (二)需求阶段 1、进入可视化产物的输出阶段，产品经理提供最简单也最接近成品的《产品原型》，线框图形式即可。在这个过程中还可能产生的包括业务流程图和页面跳转流程图。业务流程图侧重在不同节点不同角色所进行的操作，页面跳转流程图主要指不同界面间的跳转关系。项目管理者联盟 2、产品经理面向整个团队，进行需求的讲解。 3、研发项目经理根据需求及项目要求，明确《项目里程碑》。根据项目里程表，完成《产品开发计划》，明确详细阶段的时间点，最后根据开发计划，进行《项目任务分解》，完成项目的分工。 4、研发工程师按照各自的分工，进入概要需求阶段。《概要需求》旨在让研发工程师初步理解业务，评估技术可行性。 (三)设计阶段 1、UI设计师根据产品的原型，输出《界面效果图》，并提供界面的标注，最后根据主要的界面，提供一套《UI设计规范》。UI设计规范主要是明确常用界面形式尺寸等，方便研发快速开发。UI设计常涵盖交互的内容。 2、研发工程师在界面效果图，输出《需求规格》，需求规格应包含最终要实现的内容的一切要素。 3、研发工程师完成《概要设计》、《通讯协议》及《表结构设计》，及完成正式编码前的一系列研发设计工作。 (四)开发阶段项目经理博客 1、研发工程师正式进入编码阶段，这个过程虽然大部分时间用来写代码，但是可能还需要进行技术预研、进行需求确认。 2、编码过程一般还需进行服务端和移动端的联调等。
严格按照软件产品发布流程发布软件版本是建立和完善软件产品版本控制,保证软件产品质量的关键过程 之一。 参与软件产品发布的人员主要是测试负责人和BM(Build Master)。 公司软件产品发布的规程如下: 1、发布准备。发布之前,所有程序freezed由测试人员进行确认测试;检查qcs系统内登记的所有bug都已经被fixed,或者遗留的bug不影响系统的使用,如果有严重bug未解决(级别为must fixed)不能发布;程序打包前做冒烟测试。 2、测试负责人编写release产品质量报告进行质量分析和总结。 3、源码、文档入库。源码包括数据库创建脚本(含静态数据)、编译构建脚本和所有源代码;文档包括需求、设计、测试文档,安装手册、使用手册、二次开发手册、产品介绍(ppt)、使用demo等。 4、BM进行程序打包;标记源码、文档版本tag。 5、BM填写发布基线通知并通知相关人员;BM经理对发布基线进行审计。 6、在qcs系统上新建产品发布计划,填写配置项,执行发布计划(发布产品)。 7、上传程序包、使用文档至download站点。 8、编写发布说明readme.txt(或者release note)。Readme的内容应该包括产品版本说明;产品概要介绍;本次发布包含的文件包、文档说明;本次发布包含或者新增的功能特性说明;遗留问题及影响说明;版权声明以及其他需要说明的事项。 9、正式发布通知。通知开发、测试、市场、销售各相关部门并附上产品发布说明和产品介绍。
10、后续工作。产品发布后,在使用过程中可能还会发现一些bug。在不影响正常使用的情况下,这些bug将在下一版本发布时解决;如果bug严重影响使用,必须打patch或者按照流程重新发布。 11、临时发布。软件产品未正式发布前,可能需要一个临时版本供开发人员或者用户应急使用,这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员;BM需要为源码、文档打tag标记。 软件产品发布后,即建立了一条发布基线。所有用户安装及二次开发必须在此基线上进行,开发人员不能直接从cvs或vss上check 代码编译交付用户使用或者进行二次开发。
电气与自动化工程学院实训评分表 课程名称: PLＣ控制技术实训 实训题目: 机械滑台工艺流程控制系统设计 班级：电气101 学号：16０71０11８ 姓名: 陆敬博 指导老师:许仙珍 2０13年7 月 4 日
常熟理工学院电气与自动化工程学院 《PLC控制技术实训》 题目:机械滑台工艺流程控制系统设计 姓名: 陆敬博 学号: 160710１18 班级：电气101 指导教师: 许仙珍 起止日期: ２013.6.24----２013.7.2
目录 １.设计任务书…………………………………………………………１ 1.１设计任务 1.2设计目的及要求 1.3 设计内容及报告要求 2基础实训项目一: (2) 2.１I/Ｏ地址分配表 2．2程序 3基础实训项目二： (5) 3.1 I/O地址分配表 3.２程序 4．综合型自主实训项目 (10) 1．总体设计方案 1.1 方案的确定 1.2 设计方案 2.I/Ｏ地址分配表 ２.1 Ｉ／O模块的地址分配 ３.顺序功能图,梯形图及指令表 3.１顺序功能图 3.2 梯形图 3.３程序说明 4.程序的调试运行及其结果
４.1 手动控制的调试运行及结果 ４.2单步控制的调试运行及结果 ４.3 自动循环控制的调试运行及结果 5.个人小结......................................................2９6．参考文献 (30)
一．任务书 《ＰＬC控制技术》实训任务书 题目：机械滑台工艺流程控制系统设计（三) 实训学生需要完成2个基础实训项目和１个综合型自主实训项目的训练。 一、基础实训项目一：霓虹灯的PLＣ控制系统的设计 一）实训目的 １、进一步巩固掌握PLC基本指令功能的及其运用方法; 2、根据实训设备，熟练掌握ＰLＣ的外围Ｉ／O设备接线方法 ３、初步掌握ＰLC程序设计方法，养成良好的设计习惯,培养基本的设计能力; 二)实训设备： 三相交流电源模块3082２０0１、直流电源模块30８2４０01、PLC主机单元模块3086４002、数字量输入模块308２4０03、霓虹灯显示模块185０40０3、个人计算机PC、PC/ＭＰＩ编程电缆。 三)工艺控制要求: 按下启动按钮，灯Ａ亮1秒，接着灯B,Ｃ,D,E，F，G,H,I亮1秒,之后灯J1,J2,Ｋ1,K2,L1,L2，Ｍ1,M２, N１,N2,O１,O2也被点亮。1秒后,灯J1，Ｊ２,K1,K2,L1,L２,Ｍ1，M２，N1,Ｎ2,O1,O2熄灭,再过1秒,灯B,C,D,E，F,Ｇ,H,I熄灭，同样再过1秒后，灯A熄灭。紧接着过1秒灯Ａ再次被点亮,重复以上过程，循环往复。按下停止按钮后,所有灯都熄灭。 四)实训内容: 1、进行PＬC的I／Ｏ地址分配,并画出霓虹灯的PLC控制系统的接线图。 2、设计由ＰＬC 控制的霓虹灯梯形图程序。 3、输入自编程序，上机调试、运行直至符合动作要求。 二、基础实训项目二:模拟量采集与数据处理的综合应用 一) 实训目的 1、掌握PLＣ中模拟量输入、输出的基本工作原理。 ２、掌握数据处理指令的运用方法。 3、掌握功能、功能块的应用，中断组织块OB3５用法。 ４、掌握DB块建立与数据访问方法。 二)实训设备： 三相交流电源模块3０822００１、直流电源模块3０824001、PLC主机单元模块308６4002、数字量输入模块30８240０３、模拟量输入模块、模拟量输出模块、个人计算机ＰC、ＰC/MＰI 编程电缆。 三）实训项目原理与要求 1、用模拟量输入模块30８1400模拟温度测量变送器，假设当温度是0℃时,对应电位器输出0V电压,假设当温度是１00℃时,对应电位器输出电压10V电压。用ＰLC模拟量输入模块采集电位器电压,使用ＯB35实现采集温度数据，数据采集频率是１次/秒,进行标度变换,数据存储在共享数据块DB2相应
文件管理流程 文件号沪杭甬公司确定岗位关键业绩指程序文件版次标程序 编制审核批准共 1 页第 1 页 日期日期日期生效日期 更更标记处数更改单号更改人更改日期标记处数更改单号更改人更改日期 改改记记录录 1 目的、范围及适用 1.1 为了公司对工作过程的可控性，并为业绩评估提供的客观公正的标准，特制订本程 序。 1.2 本程序的适用范围为沪杭甬公司总部各部门及下属各管理处、分公司。 1.3 本程序由公司人力资源部拟订，其解释权及修改权归公司人力资源部。 1.4 本程序自2000年月日起执行。 2 职责 2.1 确定岗位关键业绩指标流程的总责任人是人力资源部经理。 2.2 人力资源部负责公司岗位关键业绩指标管理体系的建立与完善，并监督实施。 2.3 各业务主管负责制定下属的具体指标，并适时监控。 2.4 人力资源部负责考核的组织，协调平衡，并备案。 3 程序概要 3.1 公司在业务战略的指导下，在各部门预测的基础上，讨论确定下一年度的工作目标， 本项工作在12月份进行。
3.2 根据公司的年度目标，确定各部门的工作目标与计划。 3.3 根据公司及部门的业务计划，公司管理层与部门经理沟通，参照公司关键业绩指标体 系，确定部门经理关键业绩指标，并完成 FOCUS PLAN。 3.4 部门经理要求岗位责任人对下一年度该岗位的关键业绩指标进行预测。3.5 部门经理根据部门的工作目标，在公司关键业绩指标体系的基础上，参考岗位责任人 的预测，与岗位责任人讨论确定下属岗位的关键业绩指标，并完成 FOCUS PLAN。本项工作 在新年度的1月份完成。 3.6 人力资源部对业绩指标进行备案，并协助实施完成FOCUS PLAN中年度个人发展目 标。 3.7 主管关键确定的关键业绩指标对该岗位进行适时跟踪，及时解决发生的问题。 3.8 关键业绩指标作为定期汇报时的主要内容。 (文件号) 版次× (沪杭甬公司确定岗位关键业绩指标 评估程序) 文件号沪杭甬公司关键业绩指标体系程程序文件版次序 编制审核批准共 1 页第 1 页 日期日期日期生效日期 更更标记处数更改单号更改人更改日期标记处数更改单 号更改人更改日期 改改记记录录
软件版本发布流程 目录 1、目的 ........................................ 2、范围 ........................................ 3、涉及的干系人................................. 3.1 项目经理（PM，Project Manager）......... 3.2配置管理员（CMO，Configuration Management Officer） ............................................ 3.3测试人员（TP） .......................... 4、版本发布流程................................. 4.1版本发布流程图 .......................... 4.2版本发布流程描述 ........................ 5、涉及的表单和模板............................... 1、目的 为了确保测试人员的版本和开发人员发布的版本一致，不会出现版本混乱，保证测试代码版本的稳定性，以及开发代码版本的可控性，使基线库完全的受控起来。通过版本发布、基线发布报告等规程来保证软件生命过程中所有产品的完整性、一致性、可追溯性，同时也保证测试人员的工作效率。若是要变更必须走变更流程。 2、范围 适用于整个高铁事业部纳入配置管理中的所有项目。
3、涉及的干系人 3.1 项目经理（PM，Project Manager） 项目经理是整个信息系统开发和维护活动的负责人，他批准配置管理的各项活动并控制他们的进程。具体职责如下： 1）在项目将要进行编码阶段，就要使用SVN库，根据代码包含的模块在src和release下建立相应的文件夹，已明确区分，并每天要督促项目开发人员从SVN上上传和下载代码，并对每个重要的代码上传进行标注。 2）项目要开始测试时，需填写《版本发布报告》，交给配置管理人员； 3）将代码的可执行程序或代码上传到SVN目录结构下的code下相关的文件夹下； 4）Web类的测试程序需搭建服务器，并将访问的网址、用户名、密码等以书面的形式发给测试人员。 3.2配置管理员（CMO，Configuration Management Officer） 根据配置管理计划执行各项管理任务，其具体的工作职责如下： 1）根据项目经理提交的《版本发布报告》，将相关的内容打基线，确定测试版本； 2）发送《基线发布报告》给部门经理、开发人员、测试人员等，确定可以开始测试； 3）为测试人员增加SVN的库中该项目基线库的访问权限。 3.3测试人员（TP） 根据测试计划，执行测试任务，其具体工作职责如下： 1）根据《基线发布报告》在SVN基线库中获取代码或可执行程序； 2）Web类型的根据项目经理的发的访问网址、用户名、密码等登录系统，进行测试； 3）将每一轮测试的bug提交到mantis上。 4、版本发布流程 4.1版本发布流程图 4.2版本发布流程描述 1）项目从将要开始编码起就要求要使用SVN,每天进行上传和下载代码，进行标记，对应的VS? 和eclipse都有对应的SVN插件； 2）项目代码编写阶段结束后，要进入测试阶段进行测试，项目经理需向配置管理
项目上线部署发布流程
2017/9/14
一.目的 规范公司项目和产品的上线流程，建立和完善产品的版本控制，保证软件产品质量。二.适用范围 适用于公司所有项目和产品 三.职责分工 开发环境由开发人员内部负责（包括维护和管理开发分支和git代码库） 测试环境由测试人员负责 预热环境由运维人员负责 正式环境由运维人员负责 *数据库操作均由DBA统一负责(或运维人员) 四.发布流程 在已开发完毕的各系统正式部署生产环境前要严格按照以下流程进行上线前检查。 4.1.提交测试 ①开发人员在功能开发完毕后首先配置开发环境，并将系统部署至开发环境。在开发环境经过自测通过后提交测试代码，并开始撰写上线方案。(上线方案须包括新增的外部应用程序安装，应用程序部署顺序及应用关联性、是否关闭其他应用服务，数据库脚本，制定合理的上线时间，涉及的服务影响范围以及上线失败的回滚步骤。)并提交相关技术负责人审核，在审核过后邮件给相关测试人员。 ②测试人员根据模块功能文档并制定测试方案，测试用例，特别注意临界点测试方案。 ③测试人员通过自动化部署平台根据提供的分支号依照上线方案进行自动化部署，涉
及数据库操作可提请DBA操作。 ④记录各种数据测试结果及测试问题，并交由相关开发人员进行二次迭代处理，该点须交付测试结果报告。 ⑤内测完毕后交由相关业务及需求人员进行集成测试，并请测试人员记录测试结果及问题，交由相关开发人员进行再次迭代。该点须交付测试方案测试结果报告。 4.2.预热发布 ①测试人员在测试环境测试并跟踪修改bug达到上线标准（没有A、B级bug，C 级bug达到要求）时。开始部署预热环境，测试人员对现有功能在预热环境上进行验收测试（重新执行case）。紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决，确认达到上线标准。 ②如达到上线标准，测试人员发起邮件通知相关开发人员、产品人员，准备正式上线发布流程。 4.3.正式上线 ①在测试人员确认项目具备上线条件下，正式上线前，开发负责人须发起部署大会，召集相关开发人员、测试人员、产品人员、运维人员讨论此次部署事项(介绍项目的相应负责人员，数据库脚本执行，部署顺序，应用程序关联，部署时间点，部署回滚方案，包括数据库回滚和应用程序回滚)，最后生成会议纪要并发送邮件。 ②确认上线之后，测试人员邮件上线方案，数据库脚本，应用分支号给运维人员及DBA，DBA应提前执行数据库脚本，应用部署须通过自动化部署平台进行部署，部署系统应在应用系统中记录当前分支号，以便后续应用回滚使用。在部署中出现错误，及时通知相关开发人员。如若问题不能在计划内时间解决，执行回滚方案。 ③运维，DBA在操作完成时均需要回复邮件，并说明操作步骤结果。 ④发布完成后运维人员回复邮件通知测试人员、业务及需求人员进行线上测试。测试结果及问题, 提交至开发人员。如若出现问题不能在计划内时间解决，执行回滚方案，并进行迭代改进。 ⑤紧急Bug修改走补丁/hotfix流程。不影响功能的bug留到下次版本解决。测试通
文件管理程序
1．目的： 为了规范本公司的质量管理体系文件的编制、修订、更改、审批和发行的处理方法，以确保各部门使用有效版本，防止作废文件被使用。 2．范围： 适用于本公司质量管理体系中所有文件与资料，如本公司质量管理手册、程序文件、作业指导书、表单，以及顾客标准、国家标准、国际标准、国家法律法规等外来文件和资料。 3.权责： 3．1．总经理 3．1．1．负责一级文件、二级文件的批准、人力资源管理制度及绩效管理制度、销售制度的批准。 3.2．销售部 3．2．1．负责对外部图纸资料的保存和转换为内部图纸资料。 3．3．技术部 3．3．1．负责图纸等技术资料及工艺类文件的发行、回收与保存原件。3．3．2．负责对转换为内部文件资料的图纸等技术标准的审核与确认。3．4．文管中心 3．4．1．负责技术文件以外的文件与资料的发行与回收、保存原件，并监管已发行的受控文件的保存状况。 3．5．相关部门 3．5．1．负责组织编制本部门内部作业指导书并监督其运作。 3．5．2．根据管理体系文件的适用性提出修订建议。 3．5．3．负责保证受控文件副本在其责任范围内的人员均可参阅及交回过时之程序文件。 4．定义： 4．1．文件
4．1．1．一级文件：管理制度、体系管理手册、销售制度。 4．1．2．二级文件：程序文件。 4．1．3．三级文件：作业指导书。 4．1．4．四级文件：管理体系中使用到的所有表单。 4．1．5．外部文件：顾客标准、行业标准、国家标准、国际标准及法律法规等外来文件和资料。 4．2．受控文件 4．2．1．受更改控制的文件，盖有红色圆形“受控文件”印章标识，如是图纸和零件表等技术作业指导书，则加盖蓝色圆形“受控文件”印章标识，发放时应作登记及签收，正本更改生效后，应回收过时正本进行作废处理。4．3．非受控文件 4．3．1．不受更改控制的文件，发放后正本如更改，可以不回收过时副本。如是技术部试验性图纸、作业指导书须加盖红色方形“试用文件”印章标识，正式文件生效后须回收进行作废处理。 5．流程图：(附件一) 。 6．作业程序： 6．1．新增或修订文件的提出、会签及审批 6．1．1．视工作需要,各部门均可填写《文件新增/更改/补发/作废申请表》提出增加新的程序文件或对现行的程序文件提出修订建议，由部门经理与总经理商议。 6．1．2．总经理同意后，将新增或修改文件连同“文件会签记录”交相关部门负责人会签，文件会签完成后，交文管中心审阅，呈报总经理审批后，正本须由文管中心存档。 6．1．3．视工作需要，各部门均可填写《文件新增/更改/补发/作废申请表》向责任部门经理提出增加新的指导书或提出修订建议，责任部门经理须安排人员编写修订指导书，并按编号规则给该指导书进行编号。