人员编制管理规范

人员编制管理规范
人员编制管理规范

人员编制管理规范

总则

第一条为科学配置人力资源,优化队伍结构,建立与企业发展相适应的人才队伍,提高公司的人力资源管理水平,同时严控人力资源成本;特制定本规范。

第二条编制依据:以公司中长期限战略规划和公司年度经营目标为依据。

第三条编制原则:实行总量控制、严控成本的原则。

第一章人员编制的拟订

第四条公司人力资源编制分为年度编制、半年修订,以确保编制的适宜性。

第五条人力资源编制计划原则在上一年度的12月份, 以公司中长期限战略规划和公司年度经营目标为依据,以各部门编制建议为基础,由公司办公会确定后,人力资源部拟订编制报总经理审批后执行。

第六条各部门提交编制建议前,应配合人力资源部做好岗位说明书,在岗位调查和岗位设计的基础上,提出该岗位的主要工作职责、绩效指标,建议薪酬标准和入职条件,经分管领导核准后;交人力资源部部长审核,报总经理审批后在公司正式颁布,做为公司人力资源管理依据。

第七条人力资源部每年12月中旬组织各部门填写年度部门编制建议;各部门在提出本部门编制建议时,要以部门年度经营目标和

现有人员情况为依据,首先进行岗位分析,科学核定;避免因人设岗, 严控人力资源成本。

第八条分管领导在核准各部门编制时,应本着适度从紧、严控编制的原则据需核定;

第九条人力资源部在汇总编制时,应进行编制核订,调查拟增岗位、相邻岗位工作量大小,协调整合,并向部门部长提出人员优化建议,确因工作需要且业务扩大方能提出增编报告。

第十条在核订过程中,新增人力资源编制要确认入职时间,避免人员提前到岗而导致人力资源成本虚高。

第十一条编制完成后,人力资源部应汇总编制,报总经理核准。

第十二条总经理核准后,人力资源部根据新的编制作人力资源成本预算(薪酬预算、福利预算、培训预算、招聘预算、企业文化活动经费预算)。

第二章人员编制的执行与调整

第十三条经总经理审批后的人力资源年度编制,由人力资源部严格执行。

第十四条编制一经确定,原则上每半年调整一次;确因工作需要的特殊情况,报总经理办公会审批后方能调整(减少编制除外)。

第十五条增加编制的原因:

1、出现新的业务形态及布局;

2、因工作需要增设新部门或岗位;

3、市场环境出现新的业务变化或机会,现有编制不能满足需要;

4、其它需要增加编制的情况。

第十六条减少编制的原因:

1、原有业务市场出现萎缩;

2、因工作需要精简部门或岗位;

3、因劳动生产率提升或工作流程优化,可精简现有编制;

4、其它需要精简编制的情况。

第十七条当各部门提出调整编制的建议后,人力资源部首先进行核实,在与各部门沟通的基础上,提出是否调整的建议;报总经理办公会讨论。

第十八条为维护编制调整的严肃性,应召开由公司总经理主持,公司分管副总,各部门部长、人力资源部长参加的总经理办公会,三分之二以上人员同意后,由总经理签批后方能执行。否则,人力资源部将不予受理。

第三章附则

第十九条本规定由人力资源部制定并负责解释。

第二十条本规定自总经理签批之日起执行。

公司软件管理规范

XXXXXX有限公司 文件制订(修订、作废)申请单NO.: 表格编码:

1. 目的 为规范公司软件、程序的管理,确保开发、使用、变更等过程得以受控,根据本公司实际情况,特制定本规范。 2. 适用范围 本规范适用于公司所有自主开发、外购、客供软件、程序的管理。(如无特别说明,本规范内“软件”包含软件、程序) 3. 软件分类: 3.1产品源程序: 由研发部软件开发工程师编写,实现产品功能的烧录文件。 3.2 ATE测试软件及测试程序: 是指由信息技术部负责编写的配套ATE硬件使用的产品测试软件平台,及在此平台下针对不同型号产品编写的测试程序。 3.3 设备应用程序: 是指工程部在设备操作系统下针对不同产品型号编写的对应程序(ATE除外)。如:打码程序、贴片程序、SPI检测程序、AOI检测程序、分板程序、回流焊程序、X-Ray 测试程序等。 3.4管理应用软件: 是指企业使用的电子化管理工具或系统平台。如:ERP系统、品质管理系统、SPC系统、生产报表系统、电子看板系统、绩效管理系统、项目管理系统等 3.5办公软件:Windows、office、Coremail、PDM、AutoCAD、杀毒软件等。 4、职责定义: 原则上公司各部门均可依据自身需求提出软件申请,由技术部门进行开发,交由使用部门进行管理,异常无法解决时,可向技术部门寻求技术支援。具体定义如下: 4.1 需求提出部门:依据公司或者部门的实际情况,提出软件需求申请。软件需求多由软

件使用部门提出,但也可以由其它部门提出。 4.2使用/管理部门:对提出的申请进行评估,确定需求后向开发部门发起正式申请;在软件验收合格后负责日常的管理、维护等;当异常时且无法解决时,及时向开发部门反馈,并要求协助处理。 4.3开发部门:对于使用/管理部门提出的申请进行评估,确定执行方案,并最终完成软件开发;开发部门也负责后期的技术支援。 4.4监控部门:负责对软件验收完成后的使用过程进行监控,确保不出现使用错误,维规操作,使用非法软件及机密软件外流等。 4.4软件管理职责对照见下表: 分类开发部门使用/管理部门监控部门 产品源程序研发部工程部品质部 ATE测试软件及测试程序信息技术部工程部品质部 设备应用程序工程部工程部品质部 管理应用软件信息技术部使用部门信息技术部 办公软件信息技术部使用部门信息技术部 5.软件管理规范: 5.1软件申请、开发、使用管理流程图:(如下图)

检验记录和检验报告管理规程

某某制药有限公司GMP文件 目的:建立检验记录和检验报告管理规程,规范检验记录、检验报告的填写,确保检验人员真实记载当时的检验情况,正确开具报告。 适用范围:适用于中心化验室检验人员。 责任人:主任,各室主管,中心化验室人员 内容: 1.检验记录 1.1 检验记录的分类: 1.1.1将检验记录分为理化检验记录、微生物检验记录二大类。 1.1.2 微生物/无菌检验记录分为无菌检查,微生物限度检查,细菌内毒素检查等记录。1.1.3 理化检验记录分为原辅料、包装材料、成品、工艺用水、环境、其它(试制品、退货)等检验记录。 1.2 检验记录的编号:每种检验记录统一编号,QJ-×××-00(第一版),不得重编、漏编、错编。 1.3检验记录的填写 1.3.1检验记录内容必须真实,记录及时、字迹清楚、色调一致,不得用铅笔或圆珠笔填写。1.3.2不得撕毁或任意涂改,确需改正时应在改正处划线并在旁边注明正确内容、更改日期及更改人姓名。 1.3.3按表格内容填写,不得留有空格,如无内容填写时一律用“—”表示,内容与上项相同时应重复抄写不得用“〞”或“同上”表示。 1.3.4品名不得简写,规格、数量应注明单位。 1.3.5操作者、复核者应填写姓名、不得只写姓或名。 1.3.6日期填写规范,一律横写,例如10月11日不得写成“1/10”。 1.3.7记录填写必须与其精度要求相适应。 1.3.8保留有效数字的规则是四舍六入五成双。 1.3.9有检验数据、计算式的必须准确。 1.3.10检验结果书写应与药典规定相一致,有判定依据,无漏项。 1.4检验记录的复核:

1.4.1记录填写完成后,应由第二人进行复核。 1.4.2复核内容:检验项目完整;书写工整、正确;检验依据正确;计算式、计算数值正确;记录填写完整、正确。 1.4.3复核后的记录有错误属复核错误,复核人要负责,属检验错误的复核人无责任。 2.检验报告 2.1检验报告必须有中心化验室主任开具并复核签字。 2.2检验报告必须加盖质检公章方可生效。 2.3原辅料、包装材料、成品检验报告中应有检验单号。 2.4检验单号由中心化验室主任编写。 3.检验记录、检验报告的保存、销毁 3.1检验记录完成后除纳入批检验记录外统一保存于中心化验室主任处,不能保存在个人中。3.2检验记录、检验报告应保存至药品有效期满后一年,无有效期的保存三年。 3.3检验记录、检验报告保存期满一个月后,应填写“销毁记录”交质量部长批准后销毁。

数据安全管理办法

数据安全管理办法 为保护公司重要经营数据安全,结合各部门实际情况及保密需求,制定本规定。 一、结合公司实际硬件配置情况,公司目前实行双硬盘数据加密共享备份机制。 二、数据加密共享备份以部门为单位,备份所需的专用硬盘安装于部门负责人的电脑上。总监及以上人员配备专用移动硬盘存放日常重要文件。 三、专用硬盘的安装及使用 1、公司在各部门负责人的台式电脑上安装500G大容量硬盘,该硬盘仅用于备份部门重要数据。 2、信息技术员将在安装数据备份专用硬盘的计算机上以部门内每个员工的姓名拼音建立帐户,设置初始密码,并在专用数据备份硬盘上建立一个以员工姓名命名的文件夹。 3、员工在备份资料时应及时请部门负责人更改初始密码。 4、部门负责人有权限查看和使用部门内所有员工的备份资料,员工仅有权限查看和使用个人备份的资料(信息技术员已在设置备份时设置完成此项功能)。

5、员工可通过远程共享访问部门经理的计算机,将欲备份的文件拷贝到个人姓名的文件夹里。 6、数据备份操作说明: 主要操作内容涉及三部分:(1)部门负责人修改密码操作;(2)员工备份数据操作;(3)部门负责人查看备份文件夹内的资料。 操作一:部门经理修改员工帐号密码步骤 (1)在桌面我的电脑图标点右键,选择管理,打开。如图: (2)展开本地用户和组,点击用户,右侧会显示所有用户名。 (3)找到在欲修改密码的用户名,点右键,选择设置密码,会提示如图,点继续。

(4)如下图,输入新的密码,点确定,即完成密码修改。 操作二:员工备份数据的步骤 (1)以财务部阎旭升为例,在个人电脑上上打开网上邻居—查看工作组计算机,找到部门经理姚滢的电脑,双击打开,会提示如图: (2)输入用户名/密码,并勾选记住我的密码,以后就不用再输入密码(注意1:非本部门员工在访问共享文档时,也会提示输入用

软件版本管理规范标准[详]

软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容,使软件项目版本管理流程化并规化,确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库(可使用工具建立配置库,本文所述使用的是SVN)进行版本管理。 2.第三章职责 配置库管理员:负责配置库的日常维护和管理;监督开发及测试部门及时提交版本管理对象(即配置项)。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于: 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划

上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划: ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中,项目部的目录结构: |–projectA |–src (保存该项目的源程序) |–doc (保存项目相关文档) |–000.项目管理(保存项目过程管理相关文档) |–010.项目计划(保存项目计划相关文档) |–020.项目需求(保存项目需求相关文档) |–030.系统设计(保存项目设计相关文档) |–030.系统测试(保存项目代码测试相关文档) |–040.系统实施(保存项目部署实施相关文档) |–050.系统运维(保存项目运维文档,包括培训、用户手册等) |–060.技术资料(保存项目技术文档,包括第三方技术资料等)

检验报告单管理规范

检验报告单管理规范 1、目的: 建立检验报告单管理规程,保证检验数据准确无误。 2、范围: 适用于本公司原材料、包装物料、中间产品及成品检验报告单检验报告书的管理。 3、责任: 质量管理部负责人、QC负责人、检验员对本规程的实施负责。 4、内容 4.1检验报告单的内容 4.1.1检验人员根据检验结果逐项填写检验报告单,内容完整无误。 4.1.2检验报告单的检验结果、数据应客观、真实、准确、无涂改。 4.1.3根据检验结果,写有检验结论,并有检验人、复核人签名。 4.1.4检验报告单应编码管理。 4.1.5如涉及委托外部实验室进行检验,应符合委托检验的管理,同时应在检验报告单中予以说明。 4.2检验报告书的审核 4.2.1包装物料检验报告单由质量管理负责人或质量控制负责人及其授权人审核签名放行使用。 4.2.2原材料、中间产品检验报告单由质量管理负责人或质量控制负责人及其授权人审核签名放行使用。 4.2.3成品检验报告单由质量管理部负责人或其授权人审核批准后,交由负责产品放行的部门。

4.3检验报告单的发送 4.3.1由质量管理部审核合格的检验报告单,出具合格证并一同发送相关部门。 4.3.2由质量管理部审核不合格的检验报告单,出具不合格证,并提出相应处理意见、决定,送交有关部门处理。 4.4检验报告单的保存 4.4.1由质量管理部审核,出具的检验报告单,本部门按编码保存一份备查。 4.4.2原材料、成品检验报告单、分别由原材料库、成品库保存一份。 4.4.3车间生产完毕,所用原材料检验报告单、成品检验报告单并入生产批记录保存。 4.4.4其它检验报告单分别由相关部门保存备份。 4.4.5所有检验报告单保存期限为三年。

文件拷贝和共享等的管理规定

文件拷贝、保存、删除和共享规定 为了防止病毒感染,影响整个公司电脑系统和网络正常运作,同时为规范文件的存储、软件的安装、做好客户资料保密工作,最重要的就是便于客户文件资料的管理和查询、配合公司设备信息做好电脑的保养工作。 为适用于开普图文快印店铺的管理,大客户文件、固定客户文件及客户明确要求保存的文件按此规定执行,其他文件打完后,任务完成客户已验收,立即删除。 开普图文快印店铺的电脑上设置共享文件盘,为方便店铺电脑管理和维护特制定以下条例,希望所有员工参与管理和共同遵守: 1、每台电脑上C盘为系统盘,D盘为软件盘,E盘为客户临时资料盘,F盘为客户资料存储盘,G盘为资料盘,另注F盘、G盘设置为共享盘。为保护公司电脑不被病毒感染,任何人在未经经理同意的情况下,任何人不得共享其他文件或分区目录。 2、F盘、G盘中的文件,除上传者本人外,其他任何人不能删除任何文件。 3、F盘中为大客户、固定客户的文件夹命名格式为***公司名(学校名称)****文件分类(如文档、宣传页、易拉宝等)***文件(文件名称上应标明文件内容、日期,格式如:开普图文营销宣传页2012.2.13)。另注:每个电脑的F盘均单独列出一个“名片”的文件夹,所有定稿名片的矢量版(CDR或PSD格式)应放入该文件夹,以便查找。 4、如客户没有特殊要求,由我公司设计的版面均不能删除,保存到相应的文件夹中,若客户为散户,则将文件存储到F盘“其他客户资料”文件夹中。 5、QQ或邮箱接收文件的管理。应将文件接收到E盘临时资料存储盘中,并且建立以日期命名的文件夹,里面再建立以客户名称命

名的文件夹,文件夹内除了保存客户发送的文件之外,还应该保留QQ交谈记录及制作要求,客户联系方式的WORD文件。 6、制作文件的保存。每天工作结束前或交接班前,每位技术人员应整理自己制作过的文件,将有必要保存的文件存储到相应的文件夹中。将没有存储价值的文件留到E盘临时文件盘的当天日期的文件夹里,一周后整理文件时,可将其删除。 7、公司移动磁盘上文件的管理:移动磁盘由设计人员和后期制作人员共同保管和保密,员工取件如需要带盘到客户处拷贝文件,应先将磁盘清空,避免将其他客户资料或内部资料泄露。严禁共享C 盘。 8、设计素材放到G盘,并对名片、易拉宝、展板、暗纹背景等进行分类保存。 9、公司可定期对设计材料、素材等进行整理,刻成光盘,以留备份。为方便查找文件,设计人员每周对自己设计的所有文件进行整理,将客户定稿文件拷贝到4号电脑上进行保存。 10、文件的拷贝:在拷贝客户文件时或打印移动盘里的文件时,先对U盘、移动磁盘等进行病毒查杀。没有病毒再打开。如有病毒应立即进行病毒查杀。查杀后再打开。 11、每个电脑应安装病毒查杀和安全防护软件,并定期进行系统维护,清理系统垃圾等。

源代码管理规范

1源代码管理 (1) 总则 (1) 源代码完整性保障 (1) 源代码的授权访问 (2) 代码版本管理 (2) 源代码复制和传播 (5) 系统测试验收流程 (5) 系统初验 (6) 试运行 (6) 系统终验 (6) 应用系统验收标准 (8) 文档评审通过标准 (9) 确认测试通过标准 (9) 系统试运行通过标准 (10)

1代码管理 总则 1、为保障公司源代码和开发文档安全不至于泄露,保证源代码的完整,明确源代码控制管理流程,特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性,不被非授权获取,不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码,而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前,其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后,相应的源代码必须进行SVNCommit操作,在最终进行SVNCommit操作之前需要再进行SVNUpdate操作,查看是否有冲突产生,如果有冲突产生需要和冲突相关人一并解决冲突。

软件版本管理规定

上海精佑通信技术有限公司企业标准 (管理标准) Q/HT 0001–2005 软件版本管理规定 V1.04 2005-04-11 发布 2005-04-11实施

上海精佑通信技术有限公司 目录 1范围 (4) 2术语和定义 (4) 2.1软件 (4) 2.2产品软件 (4) 2.3生产支持软件 (4) 3软件版本命名规则 (5) 3.1软件版本命名组成 (5) 3.2手机软件版本命名 (5) 3.3模块软件版本命名 (5) 3.4手机PC侧软件版本命名 (6) 3.5模块PC侧软件版本命名 (7) 3.6手机生产支持软件版本命名 (7) 3.7模块生产支持软件版本命名 (8) 3.8公用于所有手机和模块的软件版本命名 (9) 3.9无线上网卡相关软件版本命名 (9) 3.10无线上网卡驱动软件版本命名 (10) 3.11正式版本号的升级规则 (10) 3.12版本的电子文件命名规则 (11) 4软件版本发布流程 (11) 5禁止条例 (14) 6管理条例 (14) 7附录 (14)

上海精佑通信技术有限公司 文档版本变更记录: 版本号拟制日期拟制人版本描述存档编号 V1.00 2005-4-11 郝军初始版本 V1.01 2005-4-27 郝军1.版本号前增加“V”,用以明显标识版 本号 2.版本号和时间之间以下划线分隔 3.增加生产支持软件种类 4.增加无线上网卡生产支持软件、管理 器软件和驱动软件命名 5.增加版本发布流程的文字说明 V1.02 2005-7-1 郝军增加手机和模块生产支持软件的类型:射 频补丁软件(RFP) V1.03 2005-7-15 郝军更改版本号升级规则,更改资料外发申请 表 V1.04 2005-7-26 郝军增加机卡合一版本的命名规则 注:1)拟制、审核、会签、批准不走电子流程时,必须用钢笔或签字笔填写,不得用铅笔、圆珠笔填写。

源代码管理规范

代码管理制度 1总则 (2) 2源代码完整性保障 (2) 3源代码的授权访问 (2) 4代码版本管理 (3) 5源代码复制和传播 (4) 6系统测试验收流程 (5) 6.1 系统初验 (5) 6.2 试运行 (5) 6.3 系统终验 (5) 6.4 系统验收标准 (6) 6.5 文档评审通过标准 (7) 6.6 确认测试通过标准 (7) 6.7 系统试运行通过标准 (7)

1总则 1、为保障公司源代码和开发文档安全不至于泄露,保证源代码的完整,明确源代码控制管理流程,特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性,不被非授权获取,不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码,而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前,其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后,相应的源代码必须进行SVNCommit操作,在最终进行SVNCommit操作之前需要再进行SVNUpdate操作,查看是否有冲突产生,如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的,基于身份和口令的访问授权。 第十条在SVN库中设置用户,并为不同用户分配不同的,适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。

文件共享管理办法(2)

文件共享管理办法(2) -标准化文件发布号:(9556-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII

修改记录 NO 修 订 版 本 修改内容摘要 修改 人 修改日期生效日期 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 文件共享管理办法 文件编号:I-WI-IT-0018 版本:V1.0 制定日期:2011-08-01 修订日期: 生效日期:2011-12-09 部门签名日期编制信息安全部黄志勇2011-08-01确认 审核信息安全部梁继清2011-12-09会审 批准信息中心张伟刚2011-12-09

1.目的 为了规划好网络共享平台,充分利用网络资源,特指定本办法。 2.范围 本制度适用于公司全体员工。 3.定义 3.1.准入:指符合公司计算机安全策略的公司或外来办公人员电脑接入英威腾网络的动 作。 3.2.离线:指公司计算机因异动、回收、报废等退出英威腾网络;外来办公人员作业结 束离开公司网络的动作。 4.角色与职责 4.1.信息中心:负责制定公司计算机准入安全策略;审核并记录计算机的准入及离线情 况;为准入或离线人员提供技术支持服务。 4.2.用户:负责配合信息中心人员做好计算机的准入及离线的管理工作。 5.流程图 无 6.管理办法细则 6.1.申请管理 6.1.1.申请部门提出申请,注明需要创建文件夹名称,并加上需要访问人员的 权限。 6.1.2.申请部门第一负责人核实后,提交给IT部负责人审核。

6.1.3.IT部负责人需与申请部门负责人确认申请人的权限内容。 6.1.4.IT部负责人与申请部门负责人确认无误后,提交给网络管理员技术实 现。 6.2.使用管理 6.2.1.各部门人员使用共享文件夹,未经部门领导同意,不得随意修改、删 除、复制、打印文件夹里面的文件。 6.2.2.禁止存放私人文件在共享文件夹里面。 6.2.3.各部门定期检查共享文件夹,不必要存放在服务器上的文件及时清理。 6.2.4.各部门人员存放文件到共享文件夹里,应注意存放路径以及目录,存放 文件必须与文件夹目录相对应。 6.2.5.设置权限时文件夹路径不超过两层。 6.3.维护管理 6.3.1.申请开通创建文件夹共享后,由网络管理员根据审阅后的文件在文件服 务器上根据相应的目录创建共享文件夹。 6.3.2.个人申请开通访问权限,网络管理员根据审阅后的文件在文件服务器上 开通申请人的权限。 6.3.3.开通访问权限后,各部门人员必须更改网络管理员提供的密码,防止密 码泄露,更改密码登录http://192.168.1.3/password上面修改。 6.3.4.网络管理员不得私自更改访问人员的权限,不得在共享文件夹内创建、 修改、删除、复制以及打印文件夹内的文件。 6.3.5.请各部门认真贯彻公司信息保密制度,严格控制好信息文件流通。

代码版本管理规范_v1.1

XXXXXXXX 代码版本管理规范

历史版本

目录 历史版本 (2) 1引言 (4) 1.1目的 (4) 1.2管理工具 (4) 2现状概述 (5) 3现状分析 (5) 3.1现状详述 (5) 3.2目标细化 (6) 3.3SVN版本管理 (6) 3.3.1概述 (6) 3.3.2使用对比 (7) 4完整的实施方案 (9) 4.1开发阶段 (9) 4.2预发布测试阶段 (9)

1引言 1.1目的 为了规范和制度化公司的软件版本管理制度,并保障项目开发资料的完整性和安全性,同时明确开发源代码的控制管理流程,特此制定此规范。 1.2管理工具 沿用SVN管理工具来进行开发的版本管理,源代码管理和开发资料归档。

2现状概述 目前公司研发部门对于代码的版本管理方式较为简单,只是在每次发版后做了基线库存档,导致所有正在开发的需求和项目都在同一个目录里面进行修改,造成每次发版的代码都有可能包含了本次发版以外的内容。 这样会造成如下两点影响: ●会有不稳定的因素存在,比如:测试只会对当前需要发版的内容进行测试,但是代码库 中同时存在多个版本和项目的代码,对于本次发版无涉及的代码没有进过测试就部署到了服务器上,影响运行的稳定性。 ●一旦出现点问题不好定位,比如:出现问题后通常会优先排查发版涉及的内容,但是部 分问题是由于其他项目代码引起的。 因此,随着公司和项目规模的壮大,对软件代码版本管理提出了更高的要求。 3现状分析 3.1现状详述 当前代码版本管理现状如下: 1.所有的开发都在一个目录里面做,各种需求、项目、代码、文件混杂在一起。 2.提交测试服务器时,只考虑了编译能通过,而没有考虑功能本身有没有完成。 3.测试出bug以后,会在开发目录进行修改,然后再次提交到测试服务器。这时提交的 代码就可能包含了他人对其他功能/项目的修改,而测试又只会针对此bug再做测试。 这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上,引起预发布环境不稳定并增加预发布bug数量。 总体来说,当前工作流程是:预发布出bug,研发修改,再提交测试,然后预发布测试

项目软件版本号管理规范

项目软件版本号管理规范

历史修改记录 一. 目的

1.1软件版本按照一定的规则保存所有版本,避免发生版本丢失或混淆等现象, 并且可以快速准确的查找到任何版本。 1.2软件版本规范有利于公司各部门之间的对接工作,有利于公司内部资料统一 管理。 1.3本文档是为规范研发部软件版本管理而制定的。 二. 范围 2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容,包括:2.2版本标识方法及管理 2.3版本升级 2.4文档及源码的备份制度 2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作,公司内部使 用按照文档及源码存放备份制度。 三. 版本管理 3.1版本号规则 3.1.1每个归档版本都有两个版本号:内部版本号和外部版本号。版本号使用 VP规则,V(Version)是指外部版本号(研发测试版本),P(Patch)是指补丁版本号(可选)。 3.1.2版本号命名:V/B+主版本号+次版本号+修订版本号+日期版本号

3.2版本号修改规则 3.2.1主版本号:当功能模块有较大的变动,比如增加模块或是整体架构发生 变化。此版本号由项目决定是否修改。 3.2.2次版本号:相对于主版本号而言,次版本号的升级对应的只是局部的变 动,但该局部的变动造成程序和以前版本不能兼容,或者对该程序以前的协作关系产生了破坏,或者是功能上有大的改进或增强。此版本号由项目决定是否修改。 3.2.3修订版本号:一般是Bug 的修复或是一些小的变动或是一些功能的扩 充,要经常发布修订版,修复一个严重Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。 3.2.4日期版本号:用于记录修改项目的当前日期,每天对项目的修改都需要 更改日期版本号。此版本号由开发人员决定是否修改。 如: V8.1.0.XXX (上一级版本号有变动时,下级要归零) 3.3版本号修改举例说明 如此时版本号为:V8.1.0.XXX ,此时为内部测试阶段 3.3.1 开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug 之后,发布到外网时,此时就进入了软件的下一个阶段,版本号可改为: V8.1.1.XXXX ,如当前日期跟上一个版本号的日期不一样,版本号可改为: V8.1.1.XXX。

汇报管理规定

汇报管理规定 集团文件版本号:(M928-T898-M248-WU2669-I2896-DQ586-M1988)

汇报管理制度为建立良好的工作秩序,确保上传下达,以及全面了解公司经营管理情况及存在的问题,为公司管理层提供决策参考,依据实际情况实行临时、天、周、月、半年、年度工作汇报制度,具体要求如下: 一、汇报内容及方式 1、临时报: 上级临时安排的工作或突发紧急需要处理的事情,在规定时间内向上级汇报工作处理结果,汇报方式有口头或书面汇报材料。 2、天报: 当天完成工作内容、存在问题与解决措施、未完成工作及原因、明天工作计划、需部门协助配合或上级明确解决事宜。(附日报表) 3、周报: 本周完成工作内容、下周工作计划、未完成工作及原因、需部门协助配合或上级明确解决事宜。(附周报表) 2、月、半年、年报: (1)大事记(重大成绩或重要事项);(2)本月/半年/年度主要完成工作情况;(3)下月/半年/年度工作具体计划; (4)存在问题及对策,需其它部门协助或公司领导协调解决事宜 汇报管理制度 二、汇报类别及时间 1、临时报:上级安排的工作的中途或完成后的回报(口头、便条、书面)。

2、天报:次日09:00以前提交; 3、周报:每周六下午16:00前提交; 4、月报:每月最后一个工作日结束前提交; 5、半年报:每年6月30日工作结束前提交; 6、年报:完成日期为次年1月5日前;特殊情况以行政部通知为准。 7、有半年、年报的月份同时需交月报,年报当月不需提交半年报。 以上汇报内容提交时间如遇节假日应按规定提前在放假前一个工作日内完成。 三、汇报对象及程序 1、临时报:由接受工作任务的下属对指派工作任务的上级汇报。 2、2、天报、周报、月报、半年报、年报 由销售部与财务部向总经理汇报;会计(各项生产采购数据)、生产部、技术部、开发部、仓库、跟单、采购部、行政部、设备部、品管部向副总经理汇报副总经理收集汇总汇报总经理 3、所有员工必须严格遵守逐级汇报制度,不得越级。 四、汇报要求: 1、汇报方式严格按照统一格式提交; 2、汇报内容要真实、详尽,一事一项;日常或简单工作事项不用陈述; 3、汇报内容使用文字要简洁、精炼,将事件陈述清楚即可; 4、汇报事件尽量使用时间说明,如确实无法用时间表述的除外。 五、考核 1、没有按时执行汇报制度,没有造成工作影响,每次处罚10元/次。

外点文件服务器共享作业规范

作业流程 文件名称:外点文件服务器共享作业规范文件编号: 文件版本:1.0 制定单位:资讯处 机密等级:一般 发行日期: 目录

1.目的 (3) 2.适用范围 (4) 3.权责 (4) 4.定义 (4) 5.作业内容 (4) 5.1.系统要求 (4) 5.2.设定步骤.......................................... 错误!未定义书签。 6.相关文件 (18) 7.附件 (19) 版本历史

审核记录 1.目的 标准化外点文件服务器管理,规范外点文件服务器共享及配额管理。

2.适用范围 适用于集团外点分公司及工厂。 3.权责 由集团总部资讯处负责编写及更新。 4.定义 无 5.作业内容 5.1.系统要求 5.1.1.系统准备: 5.1.1.1.文件服务器操作系统:Windows 2003 R2(因需做配额管理) 5.1.1.2.逻辑分区:C盘及D盘,C盘用于系统分区,D盘用于共享文件夹存放分区 5.1.2.安装组件: 5.1.2.1.打开控制面板→添加或删除程序→添加/删除Windows组件→管理和监视工具 (如下图所示)。双击进去后,在文件服务器管理和文件服务器资源管理器前 面打勾。(如下图所示)选中后点击下一步,安装完毕后点完成。

可通过控制面板中的管理工具打开(如上图) 桌面图标如下图所示。

5.2.共享文件夹建立 5.2.1.首先在服务器上D盘根目录下建立共享文件夹,用于本单位的统一的共享平台(如下图) 5.2.2.打开共享文件夹属性,将”共享”访问设置为相应的GROUP(如淮安总厂所有员工),权 限完全控制。具体权限在各部门的文件夹里的”安全”里面做。

源代码管理规范

1源代码管理 (1) 1.1总则 (1) 1.2源代码完整性保障 (1) 1.3源代码的授权访问 (2) 1.4代码版本管理 (2) 1.5源代码复制和传播 (5) 1.6系统测试验收流程 (5) 1.6.1系统初验 (6) 1.6.2试运行 (6) 1.6.3系统终验 (6) 1.6.4应用系统验收标准 (8) 1.6.5文档评审通过标准 (9) 1.6.6确认测试通过标准 (9) 1.6.7系统试运行通过标准 (10)

1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露,保证源代码的完整,明确源代码控制管理流程,特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性,不被非授权获取,不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码,而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前,其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后,相应的源代码必须进行SVNCommit操作,在最终进行SVNCommit操作之前需要再进行SVNUpdate操作,查看是否有冲突产生,如果有冲突产生需要和冲突相关人一并解决冲突。

软件版本管理规范19726

软件版本管理规范 第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容,使软件项目版本管理流程化并规范化,确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用范围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库(可使用工具建立配置库,本文所述使用的是SVN)进行版本管理。 2.第三章职责 配置库管理员:负责配置库的日常维护和管理;监督开发及测试部门及时提交版本管理对象(即配置项)。 此岗位可由开发或测试人员兼任。 3.第四章内容 4.1. 版本管理对象 包括但不限于: 项目总体计划 可行性研究报告 开发计划 需求说明书

需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划 上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。

配置库目录结构规划: ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中,项目内部的目录结构: |–projectA

传染病信息报告管理规范(2015年版)

传染病信息报告管理规范(2015年版)

传染病信息报告管理规范 (2015年版) 根据传染病防控工作的新形势,为进一步加强全国传染病信息报告管理工作,提高报告质量,依据《中华人民共和国传染病防治法》、《中华人民共和国电子签名法》等相关法律法规,制定本规范。 一、组织机构职责 遵循分级负责、属地管理的原则,各有关部门与机构在传染病信息报告管理工作中履行以下职责: (一)卫生计生行政部门。 负责本辖区内传染病信息报告工作的管理。 1.负责本辖区内传染病信息报告工作的管理,建设和完善本辖区内传染病信息网络报告系统,并为系统正常运行提供保障条件。 2.依据相关法律法规规定,结合本辖区的具体情况,组织制定传染病信息报告工作实施方案,落实传染病信息报告工作。 3.定期组织开展对各级医疗卫生机构传染病信息报告、管理等工作监督检查。 4.国家卫生计生委及省级地方人民政府卫生计生行政部门根据全国或各省(区、市)疾病预防控制工作的需要,可调整传染病监测报告病种和内容。 (二)疾病预防控制机构。 负责本辖区内传染病信息报告工作的业务指导和技术支持。 1.中国疾病预防控制中心。 (1)负责全国传染病信息报告业务管理、技术培训和工作指导,协助国家卫生计生委制定相关标准、技术规范和指导方案等。 (2)负责全国传染病信息的收集、分析、报告和反馈,预测重大传染病发生、流行趋势,开展传染病信息报告管理质量评价。

(3)动态监视全国传染病报告信息,对疫情变化态势 进行分析,及时分析报告异常情况或甲类及按甲类管理的 传染病疫情。 (4)负责国家信息报告网络系统的规划、建设、维护 和应用性能的改进与完善,并为省级相关系统建设提供技 术支持。 (5)负责对全国传染病信息报告数据备份,确保数据 安全。 (6)开展全国传染病信息报告的考核和评估。 2.地方各级疾病预防控制机构。 (1)负责本辖区的传染病信息报告业务管理、技术培 训和工作指导,实施传染病信息报告管理规范和相关方 案,建立健全传染病信息报告管理组织和制度。 (2)负责本辖区的传染病信息的收集、分析、报告和 反馈,预测传染病发生、流行趋势,开展传染病信息报告 管理质量评价。 (3)动态监视本辖区的传染病报告信息,对疫情变化 态势进行分析,及时分析报告、调查核实异常情况或甲类 及按甲类管理的传染病疫情。 (4)负责对本辖区信息报告网络系统的维护,提供技 术支持。 (5)负责对本辖区的传染病信息分析相关数据备份, 确保报告数据安全。 (6)开展对本辖区的传染病信息报告工作的考核和评估。 县级疾病预防控制机构履行以上职责的同时,负责对本辖区内医疗机构和其他责任报告单位报告传染病信息的审核;承担本辖区内不具备网络直报条件的责任报告单位报告的传染病信息的网络直报,或指导本辖区承担基本公共卫生服务项目任务的基层医疗卫生机构对不具备网络直报条件的责任报告单位报告的传染病信息进行网络报告。 (三)卫生监督机构。 配合卫生计生行政部门开展对传染病报告管理工作情况的监督检查,对不履行职责的单位或个人依法进行查处。 (四)医疗机构。

软件版本管理规范标准

软件版本管理规 V1.0.0 文档版本变更记录:

目录 前言 (3) 1 围 (4) 2 术语和定义 (4) 2.1 软件 (4) 2.2 产品软件 (4) 2.3 演示软件 (4) 3 软件版本命名规则 (4) 3.1 软件版本命名组成 (4) 3.2 产品软件版本命名 (4) 3.3 演示软件版本命名 (5) 3.4 正式版本号的升级规则 (6) 3.4.1 软件版本升级规则 (6) 3.4.2 演示版本升级规则 (6) 3.5 版本的安装文件命名规则及存放路径 (6) 4 软件版本发布流程 (7) 5 管理条例 (7) 6 附录 (7)

前言 为规部门产品软件版本的管理与控制,保证产品版本的有效与质量,制定本标准。本标准由移动金融事业部拟制。 本标准于2015年6月首次发布。

软件版本管理规定 1围 本标准规定了移动银行事业部产品软件版本的控制与管理。 本标准适用于移动银行事业部产品软件版本的控制与管理。 2术语和定义 下列定义适用于本标准。 2.1软件 指与产品相关的所有软件,可以分为产品软件和演示软件。 2.2产品软件 已签订合同,有明确交付日期的产品。 2.3演示软件 处于研发阶段,并未正式投入生产的应用。 3软件版本命名规则 3.1软件版本命名组成 产品的正式软件版本命名由四部分组成。第一部分为主版本号,第二部分为次版本号,第三部分为修订版本号,第四部分为日期版本号。 产品的演示版本命名由四部分组成。第一部分为主版本号,第二部分为次版本号,第三部分为修订版本号,第四部分为日期版本号。 3.2产品软件版本命名 产品软件版本的命名规则如下所示:

共享文件管理规范

共享文件管理规范 Document number:BGCG-0857-BTDO-0089-2022

修订记录 条款号修改条款或修改内容摘要修订人版本/状态 修改 日期旧版新版 制订审核批准日期日期日期

1、目的 为了合理有效、安全便捷的使用文件共享平台,充分利用网络资源,特制订本管理规范。 2、适用范围 本规范适用于耀阳科技所有部门和员工。 3.职责 信息管理部:负责管理和配置访问共享平台的账号和密码,为准入或离线人员提供技术支持服务。 用户:负责配合信息管理部人员做好计算机的准入及离线的管理工作。 4、定义 准入:指符合公司计算机安全策略的人员电脑接入文件共享平台的动作。 离线:指公司计算机因异动、回收、报废等退出文件共享平台,或者是人员离职、申请退出共享文件平台的动作。 5、内容 申请管理 申请部门通过钉钉《IT申请单》提出申请,注明需要创建文件夹或访问已有文件夹名称,以及访问人员权限时读取还是写入。 申请部门主管核实后,提交给信息管理部负责人审核,抄送运维工程师。 审批完成后,由运维工程师实施。 新员工入职,有配备电脑的,信息管理部会配置域账号,设置访问部门共享文件和公共文件。 由于部门间协作,需要访问其他部门的共享文件,流程是:申请人员申请---部门审批---被访问部门审批---信息管理部审批---运维工程师实施。如果涉及绝密、机密、秘密等重要文件,需总经办审批,流程是:申请人员申请---部门审批---被访问部门审批---信息管理部审批---总经办审批---运维工程师实施。 使用管理 、各部门人员使用共享文件夹,不得随意修改、删除、复制、打印文件夹里面的文件。随着管理要求的提高,后续计划上文档管理系统,将对每个文件的操作权限进行严格控制,并会留下操作记录,一旦出现安全问题,将有记录可查,做到事前预防,事中控制,事后追查。 、各部门定期检查共享文件夹,不必要存放在服务器上的文件每3个月清理一次。

(完整版)技术部软件版本管理规范

技术部软件版本规范 文档建立/修改记录: 版本管理规范 【新建项目版本管理部分】 1,项目组接到项目需求, 1.1,开发组出项目设计和开发计划; 1.2,测试在Git中建立空项目(项目名称开会时候会有,没有需要问),形成master版本,版本设定为V0.0.0。 2,组长发邮件给技术总监,并且抄送给项目经理和测试。 邮件内容:开发计划文档url和开发版本号(V0.1.0),请批准第一阶段(开发计划中会包含)开发。 3,得到批准开发回复后,测试从master(V0.0.0)建立分支版本(V0.1.0),打开版本参与人员的更新权限,并且将url给组长。 4,组长download项目,上传项目可运行框架,并且更新GIT中的readme文档并通知开发;5,开发者必须按时按功能点来提交(提交时需写相应描述)项目到GIT中,并且push前必须测试,保证代码不能有运行异常,导致无法测试 5.1,Push结束后,开发者继续开发下一个功能点。 5.2,push结束会自动化构建,自动化构建完成后系统会自动通知测试人员进行测试,测试人员需先关闭版本参与人员的更新权限,再按功能点来测试bug,然后更新bug文档和测试用例文档的内容(有无bug都需要更新),随即打开更新权限并通知组长。 6,开发者下一个功能点提交时,同上要求。 7,第一阶段最后一个功能点提交完毕后,测试者关闭此版本参与者更新权限,然后将此版本(V0.1.0)建分支版本(V0.1.1)并且给出版本url给组长,继续进行测试最后一个功能点bug。8,组长通知组员进行bug(bug一般会比较少,bug很多只能说明开发者开发质量有问题)修改,给出修改版本地址。 9,修改完毕后提交,测试人员再次关权限且测试,如仍然有bug存在,更新相应文档并在相关修改支版本(这里是V0.1.1)中再次建立修改版本(此时是V0.1.2),随即给出版本url给组长。ps:提交版本如有冲突找组长调节。 10,第一阶段开发完全完成后开始开发第二阶段任务,重复2~9步骤,相应的版本号会变为从V0.2.0开始,同里修改版本号则是V0.2.1/V0.2.2/V0.2.3...... 11,当全部阶段任务完成(指的是开发完成并测试无bug),测试将最新的修改完成的版本(应该是V0.x.x,x为任意数字)合并到master版本中,此时版本号设定为V1.0.0。测试发邮件给

相关文档
最新文档