软件部管理制度.docVIP

软件管理制度（暂定） 为进一步加强软件部门管理，提高各工程师工作效率，发挥每一位的主观能动性，创造良好的工作氛围，更好的推进部门各项目进度，并为下一步更好地开展项目创造良好的条件和工作环境。制定该制度，该制度进一部明确了部门人员工作职责，制定源码管理制度、程序打包管理、版本管理和其他日常管理制度。 开发规范 严格遵守公司代码开发规范。测试人员在进行存档前，检查相关开发规范，如果注释不清晰或代码结构与设计文档不符时，不予存档。 源代码管理 代码安全 各项目负责人保证各自项目用计算机安全，避免病毒对工作或项目源码造成影响。 不得擅自将项目源码以任何形式转至非软件部工作人员手中。 项目开发过程中需要去现场调试时，在调试完毕后必须将遗留代码进行备份和清理，不得让代码或程序Windows系统程序版本管理： 内部版本号由四位组成：a.b.c.d 外部版本号（存档版本）由三位组成：a.b.c a:主版本号 b:次版本号 c:小版本号 d:每日或常规构建包的版本号 发布版安装包管理 所有发布版安装包程序中必须包含软件修改说明，该说明中详细记录各版本程序修改内容。 开发流程 评审小组：部门经理、技术骨干、各相关模块软件开发工程师 需求分析：由外部或部门经理提出需求，形成可行性需求分析报告，交于指定开发人员。 同行评审：根据需求分析报告由评审小组进行同行评审，制定整套的技术解决方案、设计框架、设计思路、网络架构以及系统扩展范围等内容，形成评审结果报告。由部门经理或项目负责人整理出概要设计方案。 设计文档：开发人员根据概要设计方案，形成初步的设计文档，交于评审小组进行确定。 软件开发：由开发人员进行软件代码开发。 需求或方案变更：接收到需求变更消息或请求时，由评审小组进行变更确认，形成变更方案和技术解决方案。通知涉及到其他项目或第三方系统，待确认后，交于开发人员进行变更和修改，并书写使用手册。 代码测试：开发完成后，上传至SVN版本控制中，上传内容中只包括软件源代码，临时二进制文件、可执行程序等文件不要上传。通知测试人员进行相关测试，测试人员根据概要设计方案中确定的系统环境、模块功能搭建测试环境、编译代码并进行测试，形成测试报告，将Bug提交至开发人员，由开发人员负责解决Bug,解决后由测试人员关闭该Bug。 存档：测试完成后，由测试组形成最终测试报告，编译安装包，存档。 增加需求或代码优化：任何开发人员接收到新的需求信息时，首先通知部门经理，由部门经理安排评审小组确定修改方案并报领导批准后再实施，不得随意修改设计方案或增加新功能。 特殊说明： 车载和服务器程序的所有需求和协议接口必须以文档形式提供，无文档或未经详审的文档可视为无效需求。当有特殊情况需要修改且无相应文档时，应按领导或用户提出的内容，自己主动整理需求文档并交由部门经理组织评审，经过评审后再执行。 客户端程序：客户端程序因其特殊性，经常无法提供有效的文档，开发人员应做好用户需求记录，由主管领导或部门经理确认后再进行修改。 测试管理 测试人员负责搭建测试环境、测试用例的编写、测试跟踪、代码测试、Bug管理Bug跟踪、需求整理、需求跟踪、软件存档审核等工作。 测试人员需全程跟踪项目过程，根据概要设计方案编写完善的测试用例。 搭建测试环境，嵌入式系统尽可能以真实数据环境模拟测试。Windows环境下需多测试几种环境，在不同的系统版本中进行测试。 针对不同的开发环境，测试程序的健壮性、性能等。 需长期测试的内容，需建立测试跟踪记录表，做好测试记录。 测试完成后，及时完成测试用例，并将Bug录入Bug管理系统，及时通知开发人员解决Bug后再进行测试，测试完成后关闭Bug。 存档时应审核源代码的完整性、编写规范、注释、设计文档（包括数据库设计文档、接口协议文档、模块结构关系图、模块数据流、关键算法、流程逻辑、关键过程函数定义说明、软件修改说明文档等），不符合要求的不予存档，并要求开发人员补充。 未经测试人员测试的程序严禁对外发布，如有特殊情况时，需报部门经理批准后方可发布。 基本原则 软件部所有程序只针对档案室，未经经理批准不得随意将代码或编译程序参与运用。 工作中存在问题时，在自己研究1天还不能解决时应及时提出，和主要技术人员讨论沟通，尽快提出解决方案，减少时间的浪费，提高工作效率，加快项目进度。