软件源代码版本管理与发布
[键入文字]
文件编号:XWQMS-CM-TEM-01 版本号:1.1
软件源代码版本管理与发布
版本：1.0
日期： 2010-9-9
欣网视讯 | 天智互联
修订记录
目录
修订记录 (2)
1.引言 (4)
1.1.目的 (4)
1.2.术语 (4)
1.3.参考资料 (5)
2.软件版本管理 (5)
2.1.版本阶段说明 (5)
2.2.版本命名规范 (5)
2.3.版本号修改规则 (5)
2.4.SVN版本库分支与合并策略 (6)
2.4.1.版本库管理说明 (6)
2.4.2.版本库操作说明 (6)
2.4.3.各种源码变动时，版本库操作方案 (7)
2.4.4.版本库发布模式 (9)
2.5.版本号发布 (13)
2.5.1.版本发布追踪表 (13)
1.引言
1.1. 目的
该文档是配置管理计划的一部分，主要用于源代码版本管理与发布。也可用于项目配置管理与发布。该文档使项目组成员熟悉并按文档约定执行版本管理与发布。该文档列举在开发过程中会出现的开发情况，规范在开发过程中分支的类型，何时分支、何时合并。该文档根据实际项目操作实践处于不断完善中。
应该此方案最基本的前提是需要熟悉SVN客户端操作。
1.2. 术语
1.3. 参考资料
《Version Control with Subversion》
《SMOP文档格式定义规范》
2.软件版本管理
2.1. 版本阶段说明
* Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
* Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
* RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
* Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，
Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。
2.2. 版本命名规范
软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号+希腊字母版本号+SVN最后修订版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。例如：1.1.1.20100409_beta_334。
2.3. 版本号修改规则
主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目经理和技术主管决定是否修改。
* 子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目经理和技术主管决定是否修改。
* 阶段版本号(1)：一般是Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由技术主管决定是否修改。
* 日期版本号(20100409):用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。
* 希腊字母版本号+SVN最后修订版本号(beta_334):此版本号用于标注当前版本的软
件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。
2.4. SVN版本库分支与合并策略
2.4.1. 版本库管理说明
源代码版本管理采用主干和分支的开发模式，建立分支必然会涉及到合并，如果要使用主干分支方案就必须接受合并可能带来的操作繁复。
源代码的变动主要有几种：
1、建立新项目
2、修改bug
3、根据新需求增加新功能
4、项目技术方案重大变革、升级
下面分别对以上几种变动的操作方案加以说明，当然实际操作中并不局限于下面所描述的方案，做为一种建议方案，仅希望提供给大家一种管理思路。
2.4.2. 版本库操作说明
分支的合并类型
合并的工作是把主干或者分支上合并范围内的所有改动列出，并对比当前工作副本的内容，由合并者手工修改冲突，然后提交到服务器的相应目录里。如果当前工作副本是主干，则合并的范围是分支上的改动，如果工作副本是分支的，则合并范围是主干上的改动，并且一定要注意，合并的起始位置URL一定要和当前的工作副本的URL是相同的。
一、合并一个范围的版本
此类型应用最为广泛，主要是把分支中的修改合并到主干上来。在主干上点击右键选择合并，然后选择合并类型：合并一个范围的版本。合并的源URL填写的是要合并的分支的URL，待合并的版本范围如果为空，则指的是合并分支上所有的版本，即自从分支创建以来到分支当前最新版本的所有演变。如果只是选择其中一个版本，或者几个版本，那么就表示只是将制定的n个版本的变化合并到主干上。如果只是选择其中一个版本，那么表示只是选择那个版本的修改，之前或之后的修改将不被采纳。
二、复兴合并
复兴合并可以理解为是第一种合并类型的一种特例，在复兴合并中，主干可以理解为是自从
开创分支之后没有任何修改，而分支是经过修改的，而且合并中分支是没有版本选择的。经过复兴合并，分支中所有的修改都会合并到主干中，合并的结果将使得分支和主干一模一样，从而可以删除分支。
三、合并两个不同的树
此类型与前两种类型不同，第一种类型可以选择分支合并的版本，主干不能选择版本；第二种类型是主干和分支都不能选择合并的版本；而这种类型则是无论是主干还是分支都可以选择合并的版本，即可以选择过去的一个主干版本与分支的某个版本进行合并。合并的时候以选择的分支版本为主，如果选择的主干版本与分支版本有不同的地方，合并时主干部分将被放弃。
起始URL：选择主干目录的URL（应当和当前工作副本的URL一致，这个是所谓的合并点）结束URL：选择要合并的分支的URL。
起始和结束的版本：一般起始版本应当找到最后一次同步时的版本，如果从没有同步过（第一次合并），则选择创建分支时的版本，结束版本一般是最新版本，如果你不想将某些内容合并进主干的话，也可以选择一个合并点。
2.4.
3. 各种源码变动时，版本库操作方案
2.4.
3.1. 建立新项目的操作方案
通常建立一个新项目时，配置管理人员会根据CMMI规范给我们建立一套完整的项目配置库，类似下图
接下来，我们在源代码目录下建立2个子目录branchs和trunk，类似下图
Trunk目录代表源代码主干，在主干上的代码通常是经过测试、功能稳定、可以随时发布的项目代码
Branchs目录代表分支，通常用于功能修改
对于新建立的项目，一般会由1人或多人搭建项目代码框架。由多人搭建项目代码框架时，每个人分别在branchs下建立自己的分支，同时建立1个集成分支，用于将搭建的代码框架合并到集成分支下，类似下图
每个人在自己的工作副本中工作、提交。当在规定时期做完自己的框架搭建后，按照2.4.2描述的分支合并类型的第一种方法全部合并到集成分支上，类似下图
合并前的图
合并后的图
在集成分支上形成一个稳定的代码框架版本后，完全可以对该框架版本进行测试。如果认为此代码框架可以合并到主干上的话，同时也可以合并到主干上，如果认为有必要的话，同时也可以对此版本打tag。
例如：新建一个WEB工程项目框架，一般web项目工程都需要用户和权限管理模块，如果该框架集成了公司统一的用户和权限管理模块，完全可以做为全公司web项目工程的基线代码（当然需要统一技术框架，如：用java开始的项目统一使用开源的ssh技术框架，以php开始的项目应该是不能用）。
项目进行到这一步后，大家都在集成分支下进行共同开发。全部功能开发完成后进行测试、修改bug。稳定版本后合并到主干上并打tag。后面操作不再细述。
2.4.
3.2. 根据新需求增加新功能
对于主干上已有稳定版本，需要在此版本上增加新的开发功能的操作方案，细分的话也有不少，往往会遇到各种各样的情况，是在稳定的主干版本上新增功能开发，还是建立分支开发需要根据开发周期来衡量，最主要的还是技术主管要根据需求规划好分支，即能方便开发、方便发布，又能权衡好合并带来的工作量。举例说明：
已有稳定的主干项目A，需要在此基础上增加功能B和功能C
1、如果功能B和功能C之间无依赖、时间上功能B要先完成，则可以建立2个分支由2人及以上分别负责，分别完成后测试并分别合并到主干上，并根据需要打tag。完成功能B后即可以合并到主干上发布版本，也可以在B分支上发布版本。
2、如果功能C依赖于功能B，时间上功能B要先完成，则可以建立1个分支由1人及以上负责，完成功能B后测试并将功能B合并到主干上，发布版本。完成功能C后再测试合并到主干上，发布版本
3、做完功能B并合并到主干上了，突然说不需要功能B了，只需要功能C。此时可以在C分支上做测试、发布版本。也可以在主干上还原到合并功能B之前的版本，并将功能C合并到主干上做测试、发布版本
以上只举例说明了3项，实际过程中肯定有很多情况。无论如果变化，坚持主干-分支的开发模式的同时，也要记住，分支不能过多，分支一旦超多起来带来的可能是灾难而不是灵活开发和发布。建立分支不要超过3层。
2.4.
3.3. 修改bug的操作方案
修改bug的方案，还是离不开分支操作。如果是新建立的项目，通常在分支上开发完成功能后，可以直接在此分支上修改bug，测试并合并到主干上打tag
对于已有稳定版本的项目，如果修改bug的时间不长也可以直接在主干上修改bug，也可以新建分支修改bug，最后测试合并。
2.4.
3.
4. 项目技术方案重大变革、升级的操作方案
对于项目技术方案重大变革、升级的操作，一方面可以重新单独建立配置库，以之前稳定的版本做为基线代码。一方面也可以在主干上建立分支，并以此分支做为变革后的主干
2.4.4. 版本库发布模式
2.4.4.1. 开发在主干上进行
开发在主干上进行，临近发布阶段，从主干分支出来，在分支上修订集成测试，系统测试所发现的bug。在分支上发布产品升级包。发布完成，分支合并到主干。此模式需要对主干上的开发周期做一定限制，在主干上开发的各功能模块需明确开始时间与大概结束的时间，开发周期需符合主干上的发布周期。
2.4.4.2. 开发在分支上进行
开发在分支上进行，分支上的开发临近结束阶段，合并到主干修订集成测试、系统测试所发现的bug。在主干上发布产品升级包。此模式下的开发周期较灵活，各功能模块自主定义开发周期，分支上的开发临近末期则合并分支上的开发至主干。如多个功能模块发布时间临近则采取先合并先收益的方式，先合并的分支，在合并过程中解决的冲突越小。
2.4.4.
3. 分支的类型
2.4.4.
3.1.1. 现场版本维护的分支
现场版本的维护有如下两种情况：
现场版本即为主干上最新版本如现场版本既是主干上最新的版本，从主干上最新版本分支，分支上修改完毕，合并至主干后，在主干上做集成测试，系统测试。
现场版本不是主干上最新的版本现场版本不是主干上最新的，即现场的版本属于之前的某个时期的版本，尚未更新至目前最新的。首先确定现场版本，从现场版本的基线分支，在分支上修改完毕，通过集成测试，系统测试，发布，再合并至主干。
2.4.4.
3.1.2. 项目技术方案重大变革、升级
适用于对主干的重构或开发周期较长的功能开发
2.4.4.
3.2. 根据新需求增加新功能
客户化分支是永远不会关闭的分支，它随着主干的不断开发一直往前推进。客户化分支的发布在客户化分支上进行。
注：客户化分支的开发难点到一个如何与主干中的开发同步的问题。
客户化分支与主干同步有两种实现方法：
通过升级包实现同步。在主干的开发过程中，会不断有升级包产生。升级包在全省范围内部署的时候。这种处理方法适用于客户化修改未发布到现场之前通过合并主干代码实现同步。在主干的开发过程中，会不断有升级包产生。对应升级包产生的代码合并到客户化分支，解决源码上的冲突，在客户化分支做该升级包的发布。这种处理方法适用于客户化修改发布到
现场之后。
2.5. 版本号发布2.5.1. 版本发布追踪表
版本控制跟踪.xlsx
软件企业研发组织管理制度
公司软件研发管理制度 第一章、总则 为保证日常工作正常有序的进行，让开发中各个环节更紧凑，更可控，需要尽可能实现软件研发部项目管理的正规化，工作过程的流程化，以便提高软件质量和开发效率，达到项目能按质按量按期交付的目标。 1、软件开发总体遵循项目管理和软件工程的基本原则。 2、项目管理涉及项目立项、项目计划和监控、配置管理。 3、软件工程涉及需求分析、系统设计、软件实现、系统测试、用户测试、试运行、系统验收、系统上线和数据迁移、产品维护。 第二章、阶段成果 根据软件工程的过程理论并结合公司目前的实际情况，制定以下工作流程，并规定了各个重要环节需要提交的交付物。 1、立项：市场需求分析（或者合同）、项目立项申请表、项目风险分析清单。 2、需求分析：软件需求报告或设计方案、需求规格说明书。 3、总体设计：概要设计说明书或功能模块描述。 4、详细设计：详细设计说明书，包括软件接口说明、单元测试计划。
5、软件实现：软件功能说明、源代码、源代码说明或者注释 6、产品测试：测试报告 7、产品发布：产品说明书、使用手册 8、产品维护：问题反馈记录 9、项目总结：提交客户方的项目总结和公司项目汇报的PPT。软件过程成果表：
第三章、岗位设置 根据公司目前的开发过程主要分为分析、开发、测试三个阶段。分析阶段完成用户需求文档的编写，系统总体设计的编写；开发阶段完成设计文档的编写，代码的编写、代码的维护。测试阶段完成系统的测试，测试文档及其他材料。通过逐渐的调整岗位，
明确工作职责，逐步实现项目经理，需求分析工程师，高级软件开发工程师，软件开发工程师，测试工程师的岗位设置。
源代码安全管理制度V
技术部源代码控制管理制度V1.0 一、总则 1、目的: 为保障公司源代码安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、使用范围: 本办法适用于所有涉及接触源代码的各部门各岗位，所涉及部门都必须严格执行本管理办法。 3、责权: 源代码直接控制管理部门为技术部。本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个平台系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 二、管理内容及要求(根据部门工作情况撰写) 1、源代码完整性保障 所有系统的源代码及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定SVN库中。
我们研发的平台系统运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的SVN库中。 功能开始编写或者调整代码之前，其相应的设计文档必须签入SVN库（由测试组文档管理员负责检查）。 系统编码或代码调整优化结束后，提交技术测试组功能测试之前，相应的源代码必须提交到SVN库。 测试组对功能进行测试时必须从源代码服务器上的SVN库中获取代码，包括必须的第三方软件、控件和其它支撑库等文件，然后进行测试。 所有提交到SVN上的代码必须保证编译通过,而且提交的时候不会影响主干其它程序的正常运行. 2、源代码的授权访问 源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。（由SVN管理员进行管理和设置） 在SVN库中设置用户，为不同用户分配不同的、适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可创建权、可编辑权、可删除权、可销毁权。每个用户切实保证自己的用户身份和口令不泄露,用户要经常更换自己在SVN库中账号的口令。同时，工作任务变化或岗位调整后SVN管理员要实时回收用户的相关权限。要获取不属于自己范围内的文件，例如：代码、数据库，需求文档等，需经项目经理和技术部经理审批同意后由SVN管理员授权。
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、软件工程涉及需求分析、系统设计、软件实现、系统测试、用户测试、试运行、系统验收、系统上线和数据迁移、产品维护。 第二章、阶段成果 根据软件工程的过程理论并结合公司目前的实际情况，制定以下工作流程，并规定了各个重要环节需要提交的交付物。 1、立项：市场需求分析（或者合同）、项目立项申请表、项目风险分析清单。 2、需求分析：软件需求报告或设计方案、需求规格说明书。 3、总体设计：概要设计说明书或功能模块描述。 4、详细设计：详细设计说明书，包括软件接口说明、单元测试计划。 5、软件实现：软件功能说明、源代码、源代码说明或者注释 6、产品测试：测试报告 7、产品发布：产品说明书、使用手册 8、产品维护：问题反馈记录 9、项目总结：提交客户方的项目总结和公司项目汇报的PPT。 软件过程成果表：
第三章、岗位设置 根据公司目前的开发过程主要分为分析、开发、测试三个阶段。分析阶段完成用户需求文档的编写，系统总体设计的编写；开发阶段完成设计文档的编写，代码的编写、代码的维护。测试阶段完成系统的测试，测试文档及其他材料。通过逐渐的调整岗位，明确工作职责，逐步实现项目经理，需求分析工程师，高级软件开发工程师，软件开发工程师，测试工程师的岗位设置。
软件公司管理制度
广州市爱喜软件有限公司管理制度为加强公司的规范化管理，完善各项工作制度，促进公司持续、稳定、健康发展，广州 市爱喜软件有限公司特制定管理制度如下： 第一节总纲 遵纪守法，忠于职守，爱岗敬业。 维护公司声誉，保护公司利益。 服从领导，关心下属，团结互助。 爱护公物，勤俭节约，杜绝浪费。 不断学习，提高水平，精通业务。 积极进取，勇于开拓，求实创新。 第二节职能划分
第三节员工守则 一、公司全体员工必须遵守公司的各项规章制度和决定。 二、凡事以公司利益为重，有集体荣誉感。禁止任何部门、个人做有损公司利益、形象、声 誉或破坏公司发展的事情。 三、员工在上班时间应保持仪表整洁，举止端庄，行为检点，谈吐得体。特别在代表公司对 外业务联系时应树立公司良好形象。 四、员工应发扬求真务实的工作作风，提高工作效率；团结互助，同舟共济，发扬集体合作 和集体创造精神，增强团体的凝聚力和向心力。在工作当中应多发挥主观能动性，为公司出谋划策，多提合理化建议。各部门、各员工之间应互相配合，真诚协作，互相信任，互相学习，同心协力解决问题；注重对工作的主动性及创造性的培养，提高工作效率，不断提高个人的自身素质，每位员工都应尽职尽责，一切工作为求做到最好的效果。五、员工必须服从公司的组织领导与管理，对上级领导安排的工作应按质按量地完成，对未 经明示事项的处理，应及时请示，遵照指示办理；员工必须尽职尽责、精诚合作、敬业爱岗、积极进取。 六、每位员工都有义务爱护公司财产，遵守公司关于设备使用的规定。管理、保养好所使用 的设备并使之处于完好状态。损坏或遗失公司财物要立即报告上级，并主动赔偿由本人原因造成的全部或部分损失。不得将公司的财物据为已有。未经允许，不得随意翻看其它同事或公司的物品和资料。 七、节约就是美德，节约就是利润。从自身做起，从节约一张纸、一滴水、一度电、一分钱 做起，反对浪费。 八、维护公共环境卫生，随时保持办公区域的整洁，个人的办公桌和办公用品要每天整理， 垃圾应扔到垃圾篓，不得随地吐痰，乱抛杂物、纸屑果皮等； 七、上班时间应保持良好的工作气氛及环境，严禁打闹、嬉笑、高声喧哗、吃零食、看小说 及与专业无关的报刊、杂志；不得利用公司电脑打游戏、聊天或做其它与工作无关的事情。办公室内严禁打牌、下棋，酗酒、吸烟等。 第四节岗位责任制度 一、营运总监： 1)营运总监的工作范围：
软件公司管理制度
科技有限公司 管理制度(全) 该制度为科技有限公司全部管理制度 2016-03 目录 行政管理制度 (3) 一、办公室管理制度 (3) 1. 仪容仪表管理办法 (3) 2. 日常工作行为管理办法 (4) 3. 卫生管理办法 (4) 二、办公会议管理制度 (4) 三、办公用品管理制度 (4) 四、固定资产管理制度 (4)
五、办公车辆管理制度 (5) 六、办公公文管理制度 (5) 七、印章管理制度 (5) 八、档案管理制度 (5) 九、通讯管理制度 (6) 十、接待宴请管理制度 (6) 人事管理制度 (6) 一、招聘管理制度 (6) 二、考勤管理制度 (8) 三、人事异动管理制度 (11) 1. 考勤责任管理..................................... 错误!未定义书签。 2. 工作时间......................................... 错误!未定义书签。 3. 出勤管理......................................... 错误!未定义书签。 4. 休假管理......................................... 错误!未定义书签。 四、培训管理制度 (18) 五、薪酬福利管理制度 (18) 1. 薪酬体系 (18) 2. 薪酬管理 (18) 3. 福利体系 (18) 4. 福利管理 (18) 六、绩效考核管理制度 (18) 1. 考核原则 (19) 2. 试岗期考核管理办法 (20) 3. 试用期考核管理办法 (20) 4. 日常考核管理办法 (20) 5. 季度考核管理办法 (20) 6. 年度考核管理办法 (21) 七、社会保险管理制度 (21) 八、劳动合同、协议管理制度 (21) 采购管理制度 (21) 保密制度 (22) 安全管理管理制度 (22) 节约管理办法 (22) 办公管理制度 (22) 一、请示管理机制 (22) 二、汇报管理机制 (23) 三、沟通管理机制 (23) 无形资产管理制度 (24) 职业素养管理制度 (24)
软件研发版本管理制度
北京东达悦科技有限公司 软件研发版本管理规范v1.0(草案) 研发部 2009-2-4
目录 文档类别使用对象 (3) 1．引言 (4) 1.1目的 (4) 1.2范围 (4) 1.3术语定义 (4) 1.4版序控制记录 (5) 1.5版本更新记录 (5) 2．版本管理 (6) 2．1版本标识方法 (6) 2．1．1正式版本 (6) 2．2目录结构 (6) 2．3文档的存放 (8) 2.3.1当前版本和历史版本的存放 (8) 2.3.2开发文档的存放 (8) 2.3.3源代码的存放 (8) 2.3.4 SQL语句的存放 (8) 2.3.5发行文档的存放 (9) 2．4权限控制管理 (9) 3．更新管理（版本升级） (9) 3.1版本升级原则 (9) 3.2 新版本的发布 (10) 4．备份管理 (11) 5．用户版本管理 (11) 6．研发部统一管理阶段性版本 (12) 6.1阶段性版本的提交到研发部 (12) 6.2阶段性版本的发布到公司网站上 (12) 6.3各项目组新版本内部及时备份。 (12) 7．版本工具的使用 (13) 7.1研发部采用SVN配置管理工具 (13) 8．各项目组提交文档及源码以及规则 (13) 8.1各项目组需要提交的文档 (13) 8.2目前所管理的产品列表 (14)
9．周报管理制度 (14) 10．风险管理制度 (15) 文档类别使用对象 文档类别 该文档是为东达悦公司提供一个版本管理规范性文件。 使用对象 该文档使用对象为东达悦软件公司研发本部各部门项目经理及版本管理人员，以及其他相关人员。未经许可，该文档不得提供给上述规定对象以外的人员阅读或使用。
源代码管理制度
源代码管理制度 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
软件研发管理制度
武汉新英赛研发管理 第一节 软件研发岗位职责 一、软件研发部经理岗位职责 软件研发部经理在总经理或主管副总的领导下, 全面负责软件研发部的日常管理， 组织 开展软件研发与测试工作，完成企业研发目标和经营目标。其具体职责如表 二、高级研发工程师岗位职责 高级研发工程师参与建立研发工作标准与规范，协助部门经理组织完成软件研发工作, 管理软件研发项目，改良升级进行软件。其具体职责如表 8-1所示。 8-2所示。
表8-2 高级研发工程师岗位职责 三、软件研发工程师岗位职责 软件研发工程师协助高级工程师进行软件的设计与开发，收集整理相关行业信息与资料，为软件产品决策提供依据。其具体职责如表8-3所示。
四、软件测试工程师岗位职责 软件测试工程师主要负责软件测试工作, 根据软件产品规格和测试需求，编写测试方案、测试用例、测试脚本软件等。其具体职责如表8-4所示。 第二节软件研发管理制度 六、软件研发费用管理制度 第1章总则 第1条目的。 为了加强软件研发费用管理，规范资金的使用，减少公司不必要的损失，根据公司的实
际情况，特制定本制度。 第2 条研发费用管理原则。 1．计划统筹安排原则。 2．节约使用、讲求经济效益原则。 第3 条职责分工。 1．公司财务部负责研发费用的审批和报销，并随时监督费用的使用情况。 2．软件研发部负责研发费用的预算与使用控制。 第2 章研发费用的来源及使用范围 第4 条研发费用的来源。 1．公司对重点研发产品的专项拨款。 2．公司成本列支的研发费用。 3．从其他方面筹措来用于研发的费用。 第5 条研发费用的使用范围。 1．研发活动直接消耗的材料、燃料和动力费用。 2．研发人员的工资、奖金、社会保险费、住房公积金等人工费用以及外聘研发人员的劳务费用。 3．用于研发活动的仪器、设备、房屋等固定资产的折旧费或租赁费以及相关固定资产的运行维护、维修等费用。 4．用于研发活动的软件、专利权、非专利技术等无形资产的摊销费用。 5．用于中间试验和产品试制的模具、工艺装备开发及制造费，设备调整及检验费，样品、样机及一般测试手段的购置费，试制产品的检验费等。 用。用。6．研发成果的论证、评审、验收、评估以及知识产权的申请费、注册费、代理费等费7．通过外包、合作研发等方式，委托其他单位、个人或与之合作进行研发而支付的费8．与研发活动直接相关的其他费用，包括技术图书资料费、资料翻译费、会议费、差 旅费、办公费、外事费、研发人员培训费、专家咨询费、高新科技研发保险费用等。 第3章研发费用的使用管理 第6 条专款专用。
源代码管理规范
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) 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库中要求区别对待不同用户的可访问权、可读权、可写权。
软件公司内部管理制度
公司内部管理制度 发件部门：人力资源部 审批：总经办 适用范围：公司全体员工 生效日期：2013年7月
第一部分公司考勤 第一章总则 第一条员工考勤是公司管理的基础性工作，是计发工资、奖金、福利的重要依据，员工上下班必须指纹打卡考勤。 第二条员工的考勤由人事行政部负责管理。 第三条员工须按照公司规定进行考勤并及时对异常考勤及假情况进行申报。第四条各级管理者须对员工的考勤情况进行监控，并按照规定及时审批员工的异常考勤。 第二章细则 第一节考勤分类说明 一、迟到、早退 第五条公司实行单双休工作制。每天具体工作时间为：上午8:30—11:30，下午13:00—18:00。 第六条员工上下班必须在指纹打卡机上签到，签到次数为两次，即上班和下班各一次。 第七条上班不得迟到与早退。 第八条 1.迟到：超过上午8:30到岗。如因堵车等自己无法控制的原因导致迟到需提前电话通知人事行政部。每月迟到两次以上者，从第三次开 始处罚。2.早退：早于下午18:00离岗。 扣款规定迟到、早退每次罚款30元：每月迟到、早退以及脱岗累计达到2次以上开始计算处罚（即从第3次开始计算处罚），并且每月迟到、
早退以及脱岗累计达到4次予以通报批评一次。每月迟到、早退以 及脱岗累计5次以上（含5次），按旷工一天处理。 二、旷工 第九条如有下列情形之一，均按照旷工处理。 1.未请假或者请假未批准，不到公司上班； 2.用不正当手段骗取、涂改、伪造请假证明； 3.其他等同于矿工的行为。 第十条1小时以上，2小时以内为旷工半天；3小时以上为旷工一天。 扣款规定旷工半天扣一天工资，旷工一天以及一天以上扣罚旷工时间的双倍工资。 三、事假、病假 第十一条事假须提前填写请假申请单，遇到紧急情况没能事先申请须于当日上午8:30分前电话通知上级主管和行政部，得到批准后按请假处理，但 须上班后填写请假单并由上级主管签字，将请假单交给行政部方能生 效，否则按缺勤处理。超过1天的事假：必须有事前经过批准的书面 请假单方可生效。 第十二条请事假必须由本人告知上一级主管并填写请假单，由他人代请假无效。扣款规定（1）扣除事假薪资的计算=月度薪资÷每月应出勤天数÷8×请假小时（2）月累计事假超过5天，当月没有考核工资，全年累计事假达到 15天没有年终绩效；连续6个月事假达到15天，或连续12个月累 计事假达到20天，公司有权解聘。 第十三条病假应事先填写请假单，病假超过一天须提交区级以上医院出具的病
代码版本管理规范_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，研发修改，再提交测试，然后预发布测试
软件公司源代码管理制度
源代码管理制度(讨论稿) 一、总则为了加强公司产品、项目开发源代码及相关技术文档的管理，进而确保项目实施的效率和质量，特制定本办法。 二、适用范围产品、项目开发技术人员及项目实施负责人。 三、定义项目：是指通过公司立项确定需要按期实施的项目。项目实施：是指为完成立项项目进行的阶段性或特定领域的实施过程，主要包括研发实施和部署实施。 源代码：是指产品、项目研发过程中所产生的程序源代码。技术文档：是指产品、项目配套的各类设计文档、操作手册等技术性文档。 版本管理服务器：指公司架设供所有开发人员使用的Subversion(SVN) 服务器。 源代码提交：指开发人员通过客户端程序将所编写源代码上传至版本管理服务器的操作过程。 四、源代码日常管理流程源代码管理是技术研发过程的日常管理，主要包括 源代码提交、 源代码审阅、异常协调等几个环节
五、源代码结构设定 源代码结构是指源代码在版本管理服务器上存放的文件夹结构 源代码结构的设定由项目实施负责人决定 源代码结构设定有几项基本要求： 必须设置文档文件夹: 每一个独立项目或子项目源代码文件内， 至少设定一个docs 或doc 文件夹以存放仅与该项目相关技术文档 和参考资料； 必须考虑支持库：源代码结构中，应考虑具体项目所引用的非标 第三方支持库或框架的存放位置； 一台新装计算机，在安装了必要的开发环境软件以后，通过从版 准备 否
本管理服务器上签出整套源代码后，应该可以直接完成编译。 六、500提交 500提交是指项目实施期间，所有参与开发的技术人员，每日5:00 必须将当日所编制的源码或技术文档提交至版本管理服务器。 源代码及技术文档提交有如下几项要求： 任何一次提交都必须对所提交内容进行注释； 提交注释必须包含的信息项包括：所属模块或功能（必须与项目 实施进度计划一致）、性质（正常开发、修改BUG、扩展功能）、状态（编码中（x% ）、调试通过、独测通过、联测通过）、更新说明（本次提交所涉及修改部分的简要说明）。 提交注释必须以下图示例格式为准。 所提交源码必须是编译无错版本。 七、530审阅 530审阅是指项目实施负责人，每日下班前审阅版本服务器上所有下属技术人员所提交的源代码和技术文档。 源代码审阅有以下几点审阅标准： 下属技术人员必须全员按时提交;
公司软件开发管理制度
XX公司软件开发管理制度 XX公司软件开发管理制度 版本：1.0 SDM审批： QA经理[时间] CTO[时间] 目录 1.目的和作用3 2.适用范围：3 3. 参考文件3 4.适用对象3 5.软件开发流程4 5.1可行性研究与计划4 5.1.1实施4 5.1.2 文档4 5.1.2.1 应交付的文档4 5.1.2.2 提交步骤4 5.2需求分析4 5.2.1实施4 5.2.2要求5 5.2.3交付文档5 5.2.4审批5 5.3概要设计5 5.3.1实施5 5.3.2要求6 5.3.3交付文档6 5.3.4补充说明6 5.3.5审批6 5.4详细设计7 5.4.1实施7 5.4.2要求7 5.4.3文档7 5.4.4审批7 5.5实现7 5.5.1实施与要求7 5.5.2交付文档8 5.5.3审批8 5.6组装测试8 5.6.1实施8 5.6.2要求8 5.6.3交付文档8 5.6.4审批8
5.7确认测试9 5.7.1实施9 5.7.2要求9 5.7.3交付文档9 5.7.4 补充说明9 5.7.5 审批9 5.8发布10 5.8.1过程10 5.8.2 文档10 5.8.3 审核10 5.9 交接10 6. 附录1：项目文档清单11 1.目的和作用 本流程详细规定软件开发程的各个阶段及每一阶段的任务、要求、交付文件，使整个软件开发过程阶段清晰、要求明确、任务具体，实现软件开发过程的标准化。 2.适用范围： 公司的软件开发产品均适用。 3. 参考文件 各种文档模板 文档命名规则 交接流程 4.适用对象 软件管理人员，软件开发人员，软件维护人员 5.软件开发流程 5.1可行性研究与计划 5.1.1实施 5.1.1.1 软件开发部分析人员进行市场调查与分析，确认软件的市场需求 5.1.1.2 在调查研究的基础上进行可行性研究，写出可行性报告 5.1.1.3 评审和审批，决定项目取消或继续 5.1.1.4 若项目可行，制订初步的软件开发计划，建立项目日志 5.1.1.5 根据市场环境、公司软硬件情况预测十大风险因素 5.1.2 文档 5.1.2.1 应交付的文档 1）可行性研究报告* 2）初步的软件开发计划 3）十大风险列表* 4）软件项目日志* 5.1.2.2 提交步骤 1) 适用于以后各阶段的文档提交。 2) 项目相关文档用sourcesafe进行版本管理，相关书写人员可根据各文档模板形式撰写文档，正式提交的文档以存入软件管理服务器相关目录时间为准。以后每次修改都应注明修改内容。 5.2需求分析
源代码管理规范
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操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。
软件公司管理制度
重庆博邦信息技术有限公司管理制度 为加强公司的规范化管理，完善各项工作制度，促进公司持续、稳定、健康发展，天水 中强软件信息技术有限公司特制定管理制度如下： 第一节总纲 遵纪守法，忠于职守，爱岗敬业。 维护公司声誉，保护公司利益。 服从领导，关心下属，团结互助。 爱护公物，勤俭节约，杜绝浪费。 不断学习，提高水平，精通业务。 积极进取，勇于开拓，求实创新。 第二节职能划分
第三节员工守则 一、公司全体员工必须遵守公司的各项规章制度和决定。 二、凡事以公司利益为重，有集体荣誉感。禁止任何部门、个人做有损公司利益、形象、声 誉或破坏公司发展的事情。 三、员工在上班时间应保持仪表整洁，举止端庄，行为检点，谈吐得体。特别在代表公司对 外业务联系时应树立公司良好形象。 四、员工应发扬求真务实的工作作风，提高工作效率；团结互助，同舟共济，发扬集体合作 和集体创造精神，增强团体的凝聚力和向心力。在工作当中应多发挥主观能动性，为公司出谋划策，多提合理化建议。各部门、各员工之间应互相配合，真诚协作，互相信任，互相学习，同心协力解决问题；注重对工作的主动性及创造性的培养，提高工作效率，不断提高个人的自身素质，每位员工都应尽职尽责，一切工作为求做到最好的效果。五、员工必须服从公司的组织领导与管理，对上级领导安排的工作应按质按量地完成，对未 经明示事项的处理，应及时请示，遵照指示办理；员工必须尽职尽责、精诚合作、敬业爱岗、积极进取。 六、每位员工都有义务爱护公司财产，遵守公司关于设备使用的规定。管理、保养好所使用 的设备并使之处于完好状态。损坏或遗失公司财物要立即报告上级，并主动赔偿由本人原因造成的全部或部分损失。不得将公司的财物据为已有。未经允许，不得随意翻看其它同事或公司的物品和资料。 七、节约就是美德，节约就是利润。从自身做起，从节约一张纸、一滴水、一度电、一分钱 做起，反对浪费。 八、维护公共环境卫生，随时保持办公区域的整洁，个人的办公桌和办公用品要每天整理， 垃圾应扔到垃圾篓，不得随地吐痰，乱抛杂物、纸屑果皮等； 七、上班时间应保持良好的工作气氛及环境，严禁打闹、嬉笑、高声喧哗、吃零食、看小说 及与专业无关的报刊、杂志；不得利用公司电脑打游戏、聊天或做其它与工作无关的事情。办公室内严禁打牌、下棋，酗酒、吸烟等。 第四节岗位责任制度 一、公司经理（主任）：
软件开发管理制度
软件开发管理制度 Xx 为加强对定制软件开发工作管理，缩短开发周期，提高软件开发质量，降低开发成本，提高定开发效率和效益，特制定软件开发流程管理制度。 一、总则 为保证日常工作正常有序的进行，让开发中各个环境更紧凑，更可控，需要尽可能实现项目管理的正规化，工作过程的流程化，以便提高软件质量，按期交付。 1、软件开发总体遵循项目管理和软件工程的基本原则。 2、项目管理涉及项目立项、项目计划和监控、配置管理。 3、软件工程涉及需求分析、系统设计、软件实现、系统测试、用户测试、试运行、系统验收、系统上线和数据迁移、产品维护。 二、阶段成果 根据软件工程的过程，制定以下工作流程，并规定了各个重要环节需要提交的交付物。各阶段需提交的文档： 1、立项：项目申请表，软件需求报告或设计方案。 2、需求分析：项目研发主计划、需求规格说明书 3、总体设计：概要设计说明书或功能模块描述 4、详细设计：详细设计说明书，包括软件接口说明、单元测试计划。 5、软件实现：软件功能说明、源代码说明或者注释 6、产品测试：测试报告 7、产品发布：产品说明书、使用手册 8、产品维护：问题反馈记录 9、项目总结：提交客户方的项目总结和公司项目汇报的PPT。
软件过程成果表： 三、岗位设置 根据公司目前的开发过程主要分为分析、开发、测试三个阶段。分析阶段完成用户需求文档的编写，系统总体设计的编写；开发阶段完成设计文档的编写，代码的编写、代码的维护。测试阶段完成系统的测试，测试文档及其他材料。通过逐渐的调整岗位，明确工作职责，逐步实现项目经理，软件设计师，程序员，测试工程师的岗位设置。
四、项目立项 1、分析人员进行应用调查与分析，确认软件的应用需求。 2、成立项目评审会，开发总监、部门经理和指定人员必须参加。对项目进行可行性研究，编写项目建议书，评估项目的难度和工作量，形成可行性研究报告。 3、根据项目配置的优劣成立项目开发组，制定软件开发计划，确定项目经理，由部门和项目经理共同来确定具体项目配置，知识技能要求，团队成员及团队的角色。
软件开发管理制度
软件开发部管理制度 一、目的 为保障日常工作正常有序的进行，让开发中各个环节更加紧凑，更加可控，需要尽可能实现软件开发部的管理正规化，工作过程的流程化，以便提高网页质量和开发效率，达到项目能够按质按量按期上线的目标。 二、试用范围 本制度适用于XX有限公司及其下属分公司或全资控股的子公司。 三、部门职责 1、负责公司国内网站平台的建设，包括开发，完善与维护； 2、负责公司国外网站平台的建设，包括开发，完善与维护； 3、负责公司后台数据中心的建设，包括发开，完善与维护； 4、负责公司各部门运营流程体系搭建与维护； 5、负责公司ERP、CRM系统开发与维护； 6、负责公司应用软件、产品软件开发； 四、部门架构 软件开发部共分为五个小组，以下是部门的组织架构图： 五、软件开发管理制度
软件开发共有四个阶段，分别是：项目立案，软件开发，功能测试以及产品上线，每一个阶段又细分出相应的流程，如图： 1．项目立案管理与规范 1.1提出需求：公司所有部门的负责人可以在后台系统提出功能需求，包括软件 维护，软件改进，软件开发。 1.2需求管理： IT自动化中心对来自用户等各方面的需求进行收集、汇总、分析、 更新、跟踪； 1.3产品设计：IT自动化中心编写产品需求文档，包括业务结构及流程、界面原 型、页面要素描述等内容； 1.4确定方案：IT自动化中心组织协调需求方、软件开发负责人，对需求进行评 估，审核通过后方可立项，并确认开发周期； 2. 软件开发 2.1分配功能：在新项目发布后，软件开发负责人根据项目的紧急重要程度，及时 分配安排开发人员进行开发，将项目任务标记为‘已分配’，并讲解说明该项 目在公司业务层面上的意义，使项目立体化； 2.2开发功能：软件开发人员在接到分配的新项目时，先标记项目状态为‘处理中’，
源代码管理规范
源代码管理规范 标准化文件发布号：（9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-
代码管理制度 1总则.................................................................................................. 错误!未定义书签。2源代码完整性保障............................................................................ 错误!未定义书签。3源代码的授权访问............................................................................ 错误!未定义书签。4代码版本管理 ................................................................................... 错误!未定义书签。5源代码复制和传播............................................................................ 错误!未定义书签。6系统测试验收流程............................................................................ 错误!未定义书签。 系统初验........................................................................................... 错误!未定义书签。 试运行............................................................................................... 错误!未定义书签。 系统终验........................................................................................... 错误!未定义书签。 系统验收标准................................................................................... 错误!未定义书签。 文档评审通过标准........................................................................... 错误!未定义书签。 确认测试通过标准........................................................................... 错误!未定义书签。 系统试运行通过标准....................................................................... 错误!未定义书签。