公司软件管理规范

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软件申请、开发、使用管理流程图：（如下图）

<软件管理流程>

<软件申请>

<软件开发><软件使用/管理>

<使用部门>

<监控部门>

<开发部门>

<需求提出部门>

软件调试

软件开发

日常管理、维护

结束

需求申请需求评估是

开发能力评估

外购

NG 软件受控

OK NG

中断

否

技术支持

监控管理

5．2开发管理

当申请部门提出软件需求申请后，软件开发部门技术评审、立项管理、及软件编写、完成及后期调试、受控、验收的过程。详见《软件开发管理规范》 5.3命名管理:

软件命名一般要求具有使用对像、功能说明、版本说明。各软件命名规则具体如下: 5.31产品源程序:

命各规则:工程代号（客户型号）-版本_年月日.文件格式，

如：22W6006（M040）-A_20121212.SENC表示的意思是：客户型号为M040，工程代号22W6006，软件版本A，生产日期（2012年12月12日），烧录的软件格式为SENC。关于产品源程序命名规则详见《软件命名规则》

5.32 ATE测试软件:使用对像+功能说明+版本号，如：飞斯卡尔单片机烧录软件V1.0 5.33 ATE测试程序:

命各规则:公司名-----工程代码-----产品型号-----程序版本-----机器代码如：XX-1204020（M066401）-A-AT 表示：蓝微产品M066401ATE测试程序A版。详见《设备程序编写命名规范》

5.34 设备应用程序:

命各规则:公司名-----工程代码-----产品型号-----PCB（A面）----机器代码

如：XX-1204020（M066401）-01-J，表示：蓝微产品M066401 A面贴片程序。详见《设备程序编写命名规范》

5.35管理程应用软件:软名+版本号，如:SPC V1.0版。

5.36办公软件:软件名+版本号，如:Excel 2003版。

5.4受控管理：

软件在完成试用验收合格后,需要完成受控，才能给到相应部门进行使用。各软件的受控要求、受控流程略有不同，具体如下:

5.41产品源程序受控：新编写的产品源程序及变更的产品源程序均可按照软件受控（变更）流程进行受控。

5.42 ATE测试软件及测试程序受控：

4.421 ATE测试软件受控流程：参照软件受控（变更）流程进行。

4.422 ATE测试程序：参照软件受控（变更）流程进行。

5.43设备应用程序受控：

设备应用程序：如打码软件、贴片程序、AOI检测程序、分板程序、回流焊程序等不做单独受控要求,但需要保证与SOP程序各称、版本保持一致。

5.44 办公软件受控：

办公软件,一般是外购软件,以不违返知识产权保护法律、法规为前提，不做具体受控要求。

5．5软件变更：

5．51 4M变更管理：产品源程序、测试软件变更必须进行4M变更管理。

5．52 软件升级管理：软件升级之后，版本号需要有相应的升级；对于未进行版本管理的设备应用程序需要《设备程序变更履历表》进行记录，同时旧的软件必须及时归档，不可与新程序同时存在，以确保新程序的唯一正确性。

5.6软件使用权限:

5.61使用范围:公司现有软件仅限公司内部使用,不得私自复制、出售给外部人员使用,一经查实，将追究相应法律责任。

5.62软件使用权限:未经授权，不得盗用他人权限使用软件。

5.63限制型软件使用:不得在公司电脑、设备上传播、使用病毒软件、攻击型软件或者与工作无关的软件，如游戏软件、视频软件等。

6.记录表格

1．软件开发管理规范

2．软件命名规则

3. 软件受控（变更）流程

4．设备程序编写命名规范

5. 软件版本履历表

6．设备程序变更履历表

源代码安全管理制度V

技术部源代码控制管理制度V1.0 一、总则 1、目的: 为保障公司源代码安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、使用范围: 本办法适用于所有涉及接触源代码的各部门各岗位，所涉及部门都必须严格执行本管理办法。 3、责权: 源代码直接控制管理部门为技术部。本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个平台系统运行所必须具备的第三方软件、控件和其它支撑库等文件。二、管理内容及要求(根据部门工作情况撰写) 1、源代码完整性保障所有系统的源代码及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定SVN库中。

我们研发的平台系统运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的SVN库中。功能开始编写或者调整代码之前，其相应的设计文档必须签入SVN库（由测试组文档管理员负责检查）。系统编码或代码调整优化结束后，提交技术测试组功能测试之前，相应的源代码必须提交到SVN库。测试组对功能进行测试时必须从源代码服务器上的SVN库中获取代码，包括必须的第三方软件、控件和其它支撑库等文件，然后进行测试。所有提交到SVN上的代码必须保证编译通过,而且提交的时候不会影响主干其它程序的正常运行. 2、源代码的授权访问源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。（由SVN管理员进行管理和设置）在SVN库中设置用户，为不同用户分配不同的、适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可创建权、可编辑权、可删除权、可销毁权。每个用户切实保证自己的用户身份和口令不泄露,用户要经常更换自己在SVN库中账号的口令。同时，工作任务变化或岗位调整后SVN管理员要实时回收用户的相关权限。要获取不属于自己范围内的文件，例如：代码、数据库，需求文档等，需经项目经理和技术部经理审批同意后由SVN管理员授权。

技术服务规范

技术服务规范为了协调公司各部门工作，更好地为客户服务，我们根据弱电安防行业标准制定了以下作业程序，使之成为公司规范化管理的标准。一、工程承接公司业务部人员在接到用户委托后，协同系统工程部，根据用户要求、风险等级标准进行实地测试，查看现场，根据中华人民共和国公共安全行业标准等有关规定，制订科学可行的工程方案设计书、绘制施工图、编制概（预）算。设计方案经行业主管部门、用户单位论证确定后，依法签定包括售后服务内容在内的工程承包合同。二、工程施工合同签定后，工程管理部将严格按照合同确定的施工日期，派出由项目经理及工程技术人员组成的项目部。项目部根据施工图纸，确定施工方案，及时向工程土建单位出具施工联系单。参与现场施工的所有施工人员，应严格遵守行业的施工规定与要求安全施工。工程人员应严格遵守企业保密制度，着工作服，带好有关证件，保质保量地在规定时间内完成施工。施工过程中若方案有新的变动，需经用户方同意，并填报“工程联系单”书面确认；交工前要予以验收。三、工程验收

整个工程按合同书内容操作完成后，项目部应及时填报工程试运行报告、竣工报告，绘制工程竣工图。试运行结束前会同行业主管部门、用户单位进行工程验收，并根据验收情况开展需求的整改工作。工程复验后多余器材和辅料及时退库，按复验结果出具工程决算清单和绘制竣工图。并按系统使用要求对用户单位人员提供免费技术培训。四、工程资料移交和存档工程复验竣工后，项目部应将有关工程资料严格按照行业规定设定密级并统一交公司办公室存档。存档内容：（1）工程设计方案（包括初案）；（2）合同；（3）器材清单（预、决算书）；（4）平面布置图；（5）竣工图；（6）工程验收单；（7）工程联系单。工程竣工后，工程管理部需将有关工程方案、合同、图纸整套移交给售后服务部并办理移交手续，填写"工程资料移交单"。所有移交手续资料报公司办公室备案。五、售后服务售后服务部在工程交接后，应严格遵守工程合同的保修、维修约定条款，以及本公司的售后服务承诺：对竣工工程保修期内每月一次巡访，维修响应时间为30分钟以内，维修工程师于市内2小时、市外4小时内赶赴现场。维修完毕后将"维修单"交用户签字，一式二份，一份交用户，另一份交回公司办公室决算和存档。

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

软件版本管理规第一章目的本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 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.技术资料（保存项目技术文档，包括第三方技术资料等）

Git源代码管理规范样本

Git源代码管理规范一、分支管理使用git进行源代码管理, 一般将某个项目的所有分支分为以下几条主线: 1.Master 顾名思义, 既然名字叫Master, 那么该分支就是主分支的意思。master分支永远是production-ready的状态, 即稳定可产品化发布的状态。 2.Develop 这个分支就是我们平常开发的一个主要分支了, 不论是要做新的feature还是需要做bug fix, 都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本, 即完成了某个feature或者修复了某个bug后的开发稳定版本。 3.Feature branches 这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当功能点开发测试完毕之后, 就会合并到develop分支去。

4.release branches 这个分支系列从develop分支出来, 也就是预发分支。在预发状态下, 我们往往会进行预发环境下的测试, 如果出现缺陷, 那么就在该release分支下进行修复, 修复完毕测试经过后, 即分别并入master分支后develop分支, 随后master分支做正常发布。 5.Hotfix branches 这个分支系列也就是我们常说的紧急线上修复, 当线上出现bug且特别紧急的时候, 就能够从master拉出分支到这里进行修复, 修复完成后分别并入master和develop分支。下面这张图将完整展示这一个流程

二、工作原理Git的工作方式:

也就是说, 每次提交版本变动的时候, git会保存一个快照(snapshot)。如果文件没有被更改, git也不会再次保存, 而是提供一个到原来文件的链接。这样一来, git更像是一个小型的文件系统。另外, git的所有操作都能够是本地的, 仅仅在将新版本的内容上传到服务器上时才需要连接网络。 Git目录( repository) 是Git保存元数据和对象数据库的地方。这也是Git最重要的部分。

技术服务级别及响应规范

1．服务级别及响应方式在系统建设中我部门将提供优良的服务和技术支持。一旦系统出现硬件、软件、网络故障，不能正常工作，本部门提供以小时和工作日为单位的响应服务。 2．服务范围硬件设备：包括把系统恢复到正常工作状态所需要的所有零部件软件维护：包括把软件恢复到正常工作状态所需要的所有软件应用网络：诊断与排查网络故障与优化网络 3．服务方式员工碰到任何问题，可先通过电话与专人联系，寻求技术支持。电话——员工可在星期一至星期五，8：00-17：00期间获得电话支持；远程拨入——网络工程师可以通过远程网络拨入，远程检查你的系统，以便更快捷的解决问题。现场——如果有些问题不能通过电话或远程拨入解决，我部门将派遣经验丰富的网络工程师，到现场为您服务。 4．紧急程度 A级——严重，系统无法使用 B级——紧急，系统遭到严重破坏 C级——一般，有问题但不太严重 5．服务级别服务级别分为：一级、二级 6．响应时间

响应时间是根据我部门所提供的不同服务级别来确定，具体见下：一级服务：响应紧急程度A，B级电话支持:7*24，指的是员工每周7天，从周一至周日，8小时工作时间内外（0点至24点），每天24小时可要求我部门提供服务。现场支持:我部门接到服务请求经过确诊后，工程师2小时之内到达现场进行维修；直至原主机恢复到正常状态。非工作时间远程支持：网络工程师可以通过远程网络拨入，远程检查你的系统，以便更快捷的解决问题。非工作时间（如：深夜，周末与节假日等）如遇本地主机系统崩溃或系统遭到严重破坏，我部门将立即通知供应商实施现场支持。二级服务：响应紧急程度C级电话支持:5*8，指的是员工每周5天，从周一至周五，8小时工作时间以内（早8点至下午5点），每天8小时可要求我部门提供服务。远程拨入——网络工程师可以通过远程网络拨入，远程检查你的系统，以便更快捷的解决问题。现场支持:我部门接到服务请求经过确诊后，工程师4小时之内到达员工现场进行维修；直至原主机恢复到正常状态。 7．每年度一次的技术支持总结通过对员工请求和相应服务跟踪报告的分析，总结技术支持的工作效率和问题提高技术支持的水平和质量，总结员工在使用设备与系统时发现的问题和需求，返回给技术部门；使我们提供给员工的设备更能符合员工的要求。 8. 技术顾问服务

软件项目代码编码规范

变更履历

目录 1总则 (4) 2源代码完整性保障 (4) 3源代码的授权访问 (4) 4代码版本管理 (5) 4.1系统初验 (6) 4.2试运行 (6) 4.3系统终验 (7) 4.4系统验收标准 (7)

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

源代码管理规范

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操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。

技术服务管理制度

技术服务管理制度技术服务管理制度第一章总则第一条适用范围

本管理办法适用于中国建筑标准设计研究所发行室(以下简称发行室)。第二条目的主要经过技术服务来扩大标准所的市场知名度,塑造品牌形象以及增强国标的权威性。第三条原则原则上,发行室不能把技术服务作为年度创收的渠道或盈利来源,而应作为走向市场,实现年度销售目标的一种营销策略。第二章技术服务的组织管理第四条技术服务方案制定技术服务方案制定由营销主管负责组织制定,经主任审批和主任办公会讨论经过后,上报标准所主管领导审核,审核经过后,由有关部门负责执行第五条技术服务方案执行营销主管负责技术服务方案的组织实施第六条技术服务方案实施过程监督营销主管领导负责对技术服务执行过程进行监督检查第七条技术服务实施效果考核主任负责对技术服务方案执行效果进行考核

第三章技术服务形式第八条技术服务形式或内容 (一)技术培训会 (二)标准化技术研讨会 (三)技术推广会第四章技术培训第九条培训主题培训主题根据客户需求和现有技术专家资源情况而决定。第十条培训对象设计院、建筑工程、房地产开发等单位的工程技术人员。第十一条培训时间一般确定为春季、秋季各一次。第十二条参会人数由营销管理根据客户培训需求调查统计分析而制定。每次会议不得低于办会成本标准为原则。第十三条收费标准首先由营销管理根据培训内容、培训专家资质水平、参会人数、办会环境等因素而拟订会议收费标准,报主管领导审核,主任和主管所长审批后执行。第十四条会议运作管理 (一)会前准备

负责联系培训专家、课程安排,确定培训地点、时间、住宿标准、相关培训材料的准备及其它相关服务工作等。 (二)会议组织 1.会前签到营销主管组织相关人员给与会人员办理签到手续、住宿登记、日程安排、有关资料发放等 2.会中组织 (1)为授课老师作好服务; (2)为与会人员作好服务。参会、就餐、娱乐、休息、预定火车票或飞机票等 3.会后服务 (1)培训效果调查:当培训会结束的后,营销主管将事先设计好的技术培训效果调查表发放给与会人员,并在问卷发放后的1个小时内进行回收,调查问卷回收率不得低于参会人员的98%。 (2)疏散参会人员离开宾馆。 (3)营销主管协助有关人员(主任/财务)与宾馆进行结算。第十五条会后总结会议结束之后,营销主管负责写技术培训分析报告,总结本次会议成功的的经验和成功或失败的关键因素分析以及本次办会的宗旨和目的是否达到,现存的主要问题、未来改进的措施和方法等。

源代码管理规范

代码管理制度 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.1为规范公司技术服务费和评审费的管理，根据国家相关法律、法规及集团公司有关规定，结合公司实际情况制定本办法。 1.2本办法所称技术服务费是指公司在生产经营过程中，支付有关单位或个人为公司提供与工艺、技术有关的指导、服务而发生的费用。本办法所称评审费是指为设计联络会、产品验收会、管理项目验收会（认证会）等聘请专家发生的评审费用等。 1.3本办法适用于公司各部门。子公司参照执行。 2 费用涵盖范围 2.1技术服务费涵盖范围 2.1.1有关单位或个人为公司的工程建设项目、技术改造项目和技术引进项目提供相关技术指导和服务发生的费用。 2.1.2有关单位或个人为公司产品工艺和生产流程提供的指导和服务发生的费用。 2.1.3有关单位或个人为公司研发项目提供的指导和服务发生的费用。 2.2评审费涵盖范围 2.2.1有关单位或个人为公司项目设计联络会、产品验收会、管理项目验收会（认证会）等聘请专家发生的费用。包括为项目进行符合性鉴定（如：加计扣除）而聘请有权的专家等发生的费用。 3操作流程 3.1技术服务应当签订纸质协议，协议应包括需要技术服务的原因、服务内容和

支付标准，原则上一个项目一签。 3.2技术服务应当对每次提供服务做出书面记录，包括：时间、地点、参与人员，服务内容。 3.3技术服务应当在每次提供服务后出具小结，对服务的内容和产生的效果做出文字描述。 3.4技术服务应当在一个合同周期（一般为一年）结束时对服务提供方做出总结性的书面评价（应包括服务效果的验证和续不续签合同的原因的描述）。 3.5效果是指本办法第2条所述项目接受技术指导和服务产生的效益和成果，可以是项目因接受技术服务而产生的时间效益、资金效益等利益，或者是最终形成专利、专有技术等知识产权成果。 3.6评审费应有评审原因（有文件规定的提供文件，无文件规定的提供书面报告）、评审过程记录（比如：会议通知，签到记录；鉴定费也如此）、载有评审（或鉴定）结果的文件。 4支付 4.1技术服务协议的签订部门应根据合同进度支付技术服务费，审批流程按照公司《资金计划管理办法》的规定执行，支付时应提供协议、服务记录、小结（或总结）、发票（如是个人，提供签领记录并代扣代缴个人所得税）或其他完税凭证。 4.2评审费（或鉴定费）的支付审批流程按照公司《资金计划管理办法》的规定执行，发生部门应在费用报销时提供第3条3.6款所述资料和发票（如是个人，提供签领记录并代扣代缴个人所得税）或其他完税凭证。

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

要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。 2、曾经涉及、触及源代码的计算机在转作它用，或者离开研发部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定，必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。 1.4代码版本管理 1、终端软件的版本标识管理终端软件版本由终端型号、版本号和内部修订号来进行标识。终端型号：终端型号是硬件标识号，也唯一的标识了我们的项目。版本号：由“＜主版本号＞.＜次版本号＞.＜修订号＞”三段组成，中间是点号分开。版本号的目的主要是管理终端软件的对外发布，终端软件的bug的记录和统计，主要是针对于版本号的，测试部、项目部、客户等会记录某个版本号的终端软件存在哪些bug，bug会在哪个版本号中得到修正。终端软件一个新的版本号出来后，我们会统计新的版本号解决了上一个版本号中的哪些bug，以及增加了哪些新功能，等等。内部修订号：也就是“应用程序的源代码的svn修订号”，主要是由软件部和测试部内部来使用，内部修订号唯一标识我们的终端软件，即：通过内部修订号能够唯一的找出我们发布的终端软件所对应的全部软件源代码，目的是为了软件排错使用。另外，终端软件在发布时，还会给出发布日期，以便开发、测试、项目、客户等相关人员参考。 2、终端软件版本发布管理终端软件主要是以版本号为基准，对外发布，目前采用不定时发布策略，发布的时间由软件部、项目部和客户方根据情况，共同商量决定。由于目前项目时间紧，终端软件无法得到完整的测试就要发布，在发布之后，有一些需要紧急需要修复的bug，软件部需要紧急修复后就要发布更新包，以便用户能够使用，所以，在一个版本号发布后，需要进行多次修订，对于这些修订的版本，其版本号保持不变，内部修订发生变化。 3、软件bug记录、管理和统计软件bug的记录、管理和统计主要以版本号为基准，但为了软件开发人员能够找到bug

计划生育技术服务质量管理规范

计划生育技术服务质量管理规范公司标准化编码 [QQX96QT-XQQB89Q8-NQQJ6Q8-MQM9N]

计划生育技术服务质量管理规范第一章总则 1．为了加强计划生育技术服务质量管理，规范计划生育技术服务行为，提高技术服务质量和水平，为人民群众提供优质、安全、满意的计划生育技术服务，根据《中华人民共和国人口与计划生育法》、《计划生育技术服务管理条例》等法律、法规及有关规定，制定计划生育技术服务质量管理规范。 2．计划生育技术服务要坚持安全第一、质量第一的方针。坚持以人为本，以服务对象为中心，遵循国家相关法律、法规。 3．计划生育技术服务质量规范管理目标是规范计划生育技术服务，提高计划生育技术服务质量，提升计划生育技术服务管理水平，保障服务对象的身心健康与生命安全。 4．计划生育技术服务机构和技术人员向服务对象提供服务时，必须保障服务对象的计划生育生殖健康权益，保障服务对象获得国家规定的免费技术服务，满足服务对象计划生育生殖健康及相关方面的需求。 5．本规范是各级计划生育技术服务机构开展计划生育技术服务工作和技术服务质量管理的基本要求和行为准则。第二章质量管理基本要求 1．计划生育技术服务质量规范管理包括机构管理、人力资源管理、基础设施管理、器械仪器设备管理、药品和避孕药具管理、技术服务过程管理、技术服务文书档案管理、环境安全管理和质量管理持续改进等。 2．计划生育技术服务机构应设立技术服务质量管理组织，配备技术服务质量管理人员，制定技术服务质量管理制度，建立技术服务质量管理机制。计划生育技术服务机构应逐步引入现代质量管理方法，创新计划生育优质服务理念。 3．计划生育技术服务机构的法定代表人是技术服务质量管理的第一责任人，负责本机构技术服务质量管理组织的建立和质量管理标准、规范的组织实施。各部门和各岗位人员是本机构实施全面质量管理的重要成员，是技术服务质量管理规范的实施者。

源代码管理规范

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操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。

技术服务管理办法最终版

无锡市高润杰化学有限公司技术服务管理办法总则 (一)本公司为求增进经营效能，加强技术服务的工作，特制定本办法。 (二)本办法包括总则、技术服务职责、技术服务方式、技术服务程序，客户意见处理等五章。 (三)技术服务部为本公司产品售后的策划单位，其与技术部及销售部门间，应保持直接及密切的联系，对服务工作处理的核定依本公司权责划分办法处理。 (四)本办法呈请总经理核准公布后施行，修正时同。技术服务职责 (五)本公司技术服务的职责分为下列四项： 1. 负责售前产品技术支持 1.1与客户及相关人员交流，收集、分析客户需求，为客户提供产品应用工艺技术指导及解决方案，引导客户技术和产品选择； 1.2参与重大客户技术洽谈。 2. 负责组织处理客户投诉、产品应用技术质量问题等售后服务工作 2.1负责组织分析客户投诉，协调并提出处理方案及实施 2.2及时跟踪新老客户产品使用情况，现场解决客户端产品应用技术问题 2.3及时认真填写《售后服务质量信息档案》，客户服务信息及时反馈给相关销售人员，建立完善售后服务档案并存档。 3. 联络客户，获取反馈 3.1根据需要，对客户举行各种形式的回访和调查，以获取客户的直接反馈 3.2协助进行市场调查；开拓新市场，增加新客户 3.3树立锡炼产品的形象，保证高润杰公司的名誉不受到侵害 4. 负责与其他相关部门的协作 4.1针对市场需求提出产品开发意见；提供产品技术改进需求建议；与技术生产等部门相互协调解决产品生产端及客户端应用技术质量问题 4.2参与展销推广项目工作；提供销售策略建议 4.3了解市场竞争对手产品现况，提供同行业竟争产品信息

4.4定期或不定期组织销售人员产品应用技术及产品知识培训技术服务方式 (六)本公司技术服务方式分为下列十四项： 1、上门服务对于润滑油生产企业或代理商采用此方式较好，上门为客户提供培训，现场使用指导或处理使用故障，或处理客户投诉等，如果在家守株待兔，肯定没有回头客，送上门同样也为上门服务的一种。 2、委托服务润滑油生产企业常常这样做服务，或委托代理商为是体用户服务，或委托某运输公司为客户送货等，一般委托服务都要付费的。 3、咨询服务润滑油产品是高新科技产品，人们对之了解不多或根本不了解，如何去营销，如何去使用，如何去保管，许多用户都不知道，一般企业都开通服务热线，免费为用户提供技术咨询服务或业务咨询服务。这方面有长城的、昆仑、埃索的800免费电话。 4、市场调研服务这是一般企业与代理商有合作合同后进行，由于代理商对该企业产品特性及市场不了解，需企业提供此服务，派员协助代理商进行市场调研，从而开展以后的销售工作。嘉实多多免费为代理商提供当地的市场调研，从不吝啬投入。 5、技术指导服务指导客户随不同的季节，不同的细分市场进行配货，指导用户使用等等，这包括推出一些技术性小册子，如《司机手册》《业务员油品共销手册》等。 6、货运服务有条件的企业自己配备送货车辆，客户随时要货随时送货上门，或者帮助客户进行油品托运等等。 7、货款服务企业提供合理的货款结算服务，目前不少企业都是现金现货或批款结算或滚动结算，客户出示订单后，必须在财务上尽快落实货款问题，尽快给客户发货，如企业开户行一定要服务快捷，收款财务一定要时时数实公司货款流向等。 8、订货服务有了现代高科技的协助，订货方式越来越简便，由原来的写信到电话、传真再发展

助产技术服务管理规定审批稿

助产技术服务管理规定 YKK standardization office【 YKK5AB- YKK08- YKK2C- YKK18】

助产技术服务管理办法（征求意见稿）第二章管理与审批第五条助产技术服务实行分级管理，分为三级。一级助产技术服务指正常分娩服务；二级助产技术服务指除开展正常分娩外所开展的手术助产、一般异常情况的处理及产科抢救；三级助产技术服务指在二级助产技术服务基础上所开展的孕产妇和新生儿危重症抢救、严重产科并发症和合并症处理。开展助产技术服务的医疗保健机构必须按照审批确定的助产技术服务级别提供服务。除紧急情况无法转诊外，医疗保健机构不得超越级别开展助产技术服务项目。第十一条开展助产技术服务的医疗保健机构应当在明显的位置悬挂母婴保健技术服务执业许可证，并公布本机构开展助产技术服务级别的基本项目。第十五条开展助产技术服务的医疗保健机构应当建立健全相关岗位工作制度，严格执行助产技术操作规范。严格执行有关医院感染管理的规定，预防和控制医院感染。要建立新生儿身份识别、交接制度和流程，强化产房、病房等关键区安全防范制度和措施，建立严格的24小时监控和管理，确保母婴人身安全。

第十七条医务人员应当遵照国家相关规定，如实、及时履行告知义务。开展助产技术服务的医疗保健机构应当依法为新生儿出具《出生医学证明》。严禁泄露产妇和新生儿相关信息。第二十条县级以上地方人民政府卫生计生行政部门应当建立健全快速、高效的孕产妇及新生儿急救网络和转诊制度，完善服务设施，合理配置资源。医疗保健机构实施分级管理原则，应及时发现、救治和转诊危重孕产妇和围产儿，提高产科、儿科急救水平。助产技术服务基本要求一、一级助产技术服务基本要求（一）技术服务内容 1．产前检查：规范进行产前检查，给予保健指导，及时筛查高危孕妇并及时转诊； 2．产程中母婴监测技术：提供全程护理、监测产程进展、正确绘制产程图、母婴生命体征检查、胎心听诊、羊水异常的识别等； 3．正常分娩、产后2小时的观察处理，以及新生儿常规处理； 4．常用助产相关技术：包括常规阴道分娩助产、人工破膜术、人工剥离胎盘术、胎盘残留刮宫术、会阴侧切和裂伤缝合术、子宫按摩、宫缩剂的正确使用、宫腔填塞等； 5.孕产妇及胎婴儿危险因素识别、紧急处理及转诊，转诊途中的处理；

技术服务规范

技术服务规范 1.技术服务规范概述为提高公司整体形象和综合实力，使客户充分享受和体验本公司专业技术支持服务，对于客户的服务过程，必须用专业、统一、标准的形式加以规范，以确保公司和客户利益。通过对合同实施的迅速、准确、有效控制，确保安装、实施、验收、保修等各个工作环节能够得到有效及时完成，达到并提升客户满意度，形成“XX服务”品牌，增加并提高公司竞争力。在提高并完善客户技术服务的同时，对内稳定健全技术支持队伍结构，细化并规范客户服务支持流程，全面提高团队技术服务能力，对外清晰加强售前支持能力，将规定、准则渐进为自觉行为，以达到提高整体工作效率的目的。只有按目标有规范一致地前进才是公司团队行为，宁可在短期内发展慢一些，但也决不要以个人风格去改变或误导公司整体目标。在规范中前进，在前进中规范，公司中的每个员工只能推动公司前进，除此别无选择。 XX技术力量整体分布于各事业部之间。现有支持平台广、产品多、变化大，整体力量分散，在现阶段我们必需尽快地稳定健全技术支持队伍，以适应公司主体业务发展的规划与需要。对于技术支持队伍建设的主题是规范与专业。我们可以承受短期的混乱，但绝不可以继续。 2.服务范围（1）产品标准分销服务：如验货、客户签收、基本安装、售前售后远程电话支持。主要是代理产品对于集成商等非最终用户的技术支持，一般有厂商支持并由其完成，一般过程短，服务要求简单，技术要求低，保修一般不用到现场。（2）现场维护服务：突发响应现场修复支持服务或安装服务；（3）服务例检：主要用于服务合同内定期例行预防性检查；厂商标准增值服务，如延伸原厂商产品保修年限、服务范围、地域；（4）技术顾问服务：售前售后咨询，售前方案设计，技术培训；（5）外包服务；（6）备品备件服务； 3.技术部（虚拟）及技术经理职责技术部（虚拟）作为在公司运作中担负技术支持的服务部门，负责公司所有产品合同和维护服务合同的技术支持工作，包括对客户的售后支持如安装、保修等，公司内部的售前技术支持如方案

产品版本管理规范

基于Tortoise SVN的软件产品版本管理规范[草稿]

目录 1. 引言 (1) 1.1. 目的 (1) 1.2. 范围 (1) 1.3. 术语定义 (1) 1.4. 参考资料 (2) 1.5. 版本控制记录 (2) 1.6. 版本更新记录 (2) 2. 版本管理 (4) 2.1. 版本标示方法 (4) 2.1.1. 正式版本 (4) 2.2. 目录结构 (5) 2.3. 文档的存放 (6) 2.3.1. 开发文档的存放 (6) 2.3.2. 源代码的存放 (6) 2.3.3. SQL的语句存放 (7) 2.3.4. 发行文档的存放 (7) 2.4. 配置管理流程 (7) 2.5. 权限控制的管理 (8) 3. 更新管理 (9) 3.1. 源程序的修改 (9) 3.2. 版本升级 (10) 3.2.1. 版本升级原则 (10) 3.2.2. 新版本发布 (11) 3.3. 文档的变更 (11) 4. 备份管理 (12) 5. 版本工具Tortoise SVN的使用 (13)

1.引言版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。 1.1. 目的本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。 1.2. 范围本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容，包括： ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3. 术语定义 SCM 软件配置管理（Software Configuration Management）缩写 SVM 软件版本管理（Software Version Management）缩写 SVN 一个开源的版本控制系统Subversion. 文档一种数据媒体和其上所记录的数据。

源代码管理规范

源代码管理规范标准化文件发布号：（9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-

代码管理制度 1总则.................................................................................................. 错误!未定义书签。2源代码完整性保障............................................................................ 错误!未定义书签。3源代码的授权访问............................................................................ 错误!未定义书签。4代码版本管理 ................................................................................... 错误!未定义书签。5源代码复制和传播............................................................................ 错误!未定义书签。6系统测试验收流程............................................................................ 错误!未定义书签。系统初验........................................................................................... 错误!未定义书签。试运行............................................................................................... 错误!未定义书签。系统终验........................................................................................... 错误!未定义书签。系统验收标准................................................................................... 错误!未定义书签。文档评审通过标准........................................................................... 错误!未定义书签。确认测试通过标准........................................................................... 错误!未定义书签。系统试运行通过标准....................................................................... 错误!未定义书签。