软件部管理制度.docVIP

软件管理制度（暂定） 为进一步加强软件部门管理，提高各工程师工作效率，发挥每一位的主观能动性，创造良好的工作氛围，更好的推进部门各项目进度，并为下一步更好地开展项目创造良好的条件和工作环境。制定该制度，该制度进一部明确了部门人员工作职责，制定源码管理制度、程序打包管理、版本管理和其他日常管理制度。 开发规范 严格遵守公司代码开发规范。测试人员在进行存档前，检查相关开发规范，如果注释不清晰或代码结构与设计文档不符时，不予存档。 源代码管理 代码安全 各项目负责人保证各自项目用计算机安全，避免病毒对工作或项目源码造成影响。 不得擅自将项目源码以任何形式转至非软件部工作人员手中。 项目开发过程中需要去现场调试时，在调试完毕后必须将遗留代码进行备份和清理，不得让代码或程序随意流出。 项目开发过程中需要去现场和第三方接口联调时，注意保护己方代码和程序，严禁向第三方提供非接口协议内容。 严禁向非公司工作人员提供任何源代码和可执行程序。 严禁私自向第三方提供任何接口和数据（包括既有程序更新升级过程中的数据发送）。 SVN源代码管理 部门现已部署SVN服务器，各研发人员必须使用SVN管理源代码，坚决摒弃等待东西改完了再上传的漏习，根据各自分管的项目和模块及时上传更新自己的源代码，并添加修改注释。 有关该项目的概要设计文档，存于该项目目录下的Document目录下，供大家查阅。 有关该项目的详细设计文档，存于各自负责模块的目录下。 有关测试用例的文档，放入svn/Document目录下，供大家查阅。 各模块之间的文档交互以SVN上存的文档为准。 代码共享 工作中每位工程师都会在工作中写一些通用算法实现的过程和函数以及部分公共协议解析的单元等，可能还会写一些小工具之类的用于调试。为了能提高整个部门的工作效率，减少重复工作，都可以将自己写的小工具的源码上传至公共源码区，让更多的工程师分享你的成果。希望大家都能够抱着我为人人、人人为我的态度，共同进步和提高。 客户端打包工具管理 1、C或C++： 2、Delphi： 3、编译内容 公司信息、程序名称、版本信息。 另帮助内容中应包括使用手册、联系电话、公司网站、程序版本等信息 4、安装路径 统一默认安装路径为D盘根目录，路径格式：d:\程序名称\程序文件。 软件版本管理 1、源代码版本管理 所有项目中涉及的源代码必须使用SVN管理，希望大家一定要严格执行。 2、编译程序版本管理 车载程序版本管理： 服务器程序版本管理： Windows系统程序版本管理： 内部版本号由四位组成：a.b.c.d 外部版本号（存档版本）由三位组成：a.b.c a:主版本号 b:次版本号 c:小版本号 d:每日或常规构建包的版本号 发布版安装包管理 所有发布版安装包程序中必须包含软件修改说明，该说明中详细记录各版本程序修改内容。 开发流程 评审小组：部门经理、技术骨干、各相关模块软件开发工程师 需求分析：由外部或部门经理提出需求，形成可行性需求分析报告，交于指定开发人员。 同行评审：根据需求分析报告由评审小组进行同行评审，制定整套的技术解决方案、设计框架、设计思路、网络架构以及系统扩展范围等内容，形成评审结果报告。由部门经理或项目负责人整理出概要设计方案。 设计文档：开发人员根据概要设计方案，形成初步的设计文档，交于评审小组进行确定。 软件开发：由开发人员进行软件代码开发。 需求或方案变更：接收到需求变更消息或请求时，由评审小组进行变更确认，形成变更方案和技术解决方案。通知涉及到其他项目或第三方系统，待确认后，交于开发人员进行变更和修改，并书写使用手册。 代码测试：开发完成后，上传至SVN版本控制中，上传内容中只包括软件源代码，临时二进制文件、可执行程序等文件不要上传。通知测试人员进行相关测试，测试人员根据概要设计方案中确定的系统环境、模块功能搭建测试环境、编译代码并进行测试，形成测试报告，将Bug提交至开发人员，由开发人员负责解决Bug,解决后由测试人员关闭该Bug。 存档：测试完成后，由测试组形成最终测试报告，编译安装包，存档。 增加需求或代码优化：任何开发人员接收到新的需求信息时，首先通知部门经理，由部门经理安排评审小组确定修改方案并报领导批准后再实施，不得随意修改设计方案或增加新功能。 特殊说明： 车载和服务器程序的所有需求和协议接口必须以文档形式提供，无文档或未经详审的文档可视为无效需求。当有特殊情况需要修改且无相应文档时，应按领导或用户提出的内容，自己主动整理需求文档并交由部门经理组织评审，经过评审后再执行。 客户端程序：客户端程序因其特殊性，经常无法提供有效的文档，开发人员应做好用户需求记录，由主管领导或部门经理确认后再进行修改