研发部门管理规章制度草稿

1、研发部门管理规章制度草稿目 录 21 摘要32 研发管理制度 32.1 立项32.2 软件需求分析32.3 总体设计 32.4详细设计 42.5软件实现 42.6测试42.7 产品发布53 研发管理表格53.1 项目立项申请表53.2 阶段评审会议63.3 软件 Bug详细跟踪记录表63.4软件研发风险评估与控制表 73.5周工作总结计划表73.6出差报告表格83.7产品测试报告摘要 为保证日常工作正常有序地进行，让工作中的各环节更紧凑，更可控，需要尽可能实现工作过程正规化、流程化，以便提高质量、提高速度。以下是一个大概的工作流程，可供参考。各个重要环节需有文档统计。需求文档，即每个员工根据产

2、品规划应提交的交付物，要求：完全实现设计的功能，能按时提交，并具有可继承性。可继承性包含两点含义：1、对产品维护有好处，具有可追溯性；2、对新产品的开发提供可借鉴的范例，可快速确定方向，少走弯路。 各阶段需提交的文档：立项：项目立项申请表、软件设计报告。软件需求分析：项目研发计划、需求规格说明书。 总体设计：功能模块描述。详细设计：软件接口说明、单元测试计划。软件实现：软件功能说明、源代码说明 (源代码注释 ) 。 产品测试：产品测试报告。产品发布：产品发布公告、产品说明书和产品使用手册。产品维护：产品问题反馈。研发管理制度立项 （ 1）研发部调研分析人员进行市场调查与分析，通过客户需求分析，

3、获取与产品发展相关的客户意向、市场需求、竞争态势、同类产品等信息。确认软件的市场需求。（ 2）在调查研究的基础上进行可行性分析，提交项目立项申请表。（ 3）研发经理组织相关人员进行论证，决定项目取消或继续。（4）研发部根据论证结果制定初步的软件设计报告。软件需求分析（1）对软件开发需求进行分析并给出详细的功能定义。（ 2）做出简单的用户原型，与用户共同研究，直到用户满意为止。3）对可利用的资源（计算机硬件、软件、人力等）进行估计。 （ 4）制定大概的项目进度计划。 （ 5）评审。 （ 6）需求规格说明书须明确需求细则，应该实现哪几点功能等，并经过用户确认。 （ 7）汇总并提交所有相关文档，并知

4、会研发部经理。 总体设计 （ 1）确定目标系统的总体结构。可按软件需求划分成子系统，也可直接定义目标系统的功能模块及各功能模块间的关系。（ 2）给出每个功能模块的功能描述、数据接口描述，并形成文档。 （ 3）设计数据库或数据结构。 （ 4）制订各阶段软件实现的目标（里程碑）计划。 （5）制定第一个里程碑的功能模块测试计划。 （ 6）评审。 （ 7）每一个里程碑计划又可分为详细设计、实现、组装测试、确认测试、发布、交接等阶段。（ 8）汇总并提交所有相关文档， 并连同整体进度知会研发部经理审核。 详细设计 （ 1）将总体设计产生的构成软件系统的各个功能模块逐步细化，形成若干个程序模块。（ 2）详细

5、设计是细化过程，可能会发现前一步设计存在的不足，需确定各程序模块之间的详细接口信息。 （ 3）确定程序模块内的数据流或控制流，对每个程序模块必须确定所有输入、输出和处理功能。 （ 4）撰写拟订单元测试计划，可分两种情况，即程序模块的测试或由于细化过程引起设计变更而更改功能模块测试。（ 5）评审。（ 6）汇总并提交所有相关文档，并知会研发部经理，审核确认软件质量和进度。 软件实现 （ 1）对每个程序模块用所选定的程序设计语言进行编码，写出的程序应该结构良好、清晰易读且与设计一致，符合公司编码规范。 （ 2）单元测试，研发人员按单元测试计划对自己编写的程序进行测试。 （ 3）对编程及单元测试过程进

6、行版本管理，需要在文档中明确各个版本对应的单元测试内容。4）研发人员需在实现过程中撰写相关文档。软件实现文档应包含软件功能说明、源代码说明。 （ 5）软件功能说明文档应说明项目名称、 编号、软件名称和版本号、 软件功能、软件功能模块划分、主要功能实现过程。 （6）源代码说明文档应说明项目编号、软件名称、软件功能、全局变量、结构、数据库字典、函数功能、接口。该文档可以包含在源代码文件中，以注释形式存在。 （ 7）单元测试完成后，进行产品整体调试。 产品由研发人员自行调试， 并撰写调试记录。调试记录应说明项目名称、编号、调试记录版本号、调试时间、软硬件版本号、 调试环境、 发现的主要问题及解决办法

7、。8）研发产品确认运行稳定后，由项目负责人组织内部验收。 （9）汇总并提交所有相关文档，并知会研发部经理。测试 （1）项目组完成调试后，研发人员将产品以及研发调试记录移交给测试人员。测试人员按照产品的测试计划报告、研发调试记录，设计测试过程，并填写产品测试报告。2）产品测试报告应该说明项目名称、编号、测试报告版本号、需测试功能、指标、测试方法、测试环境、测试结果、结论等。 （ 3）测试人员对测试结果进行分析，如果产品不能通过测试，则生成问题列表（Bug List ），返给研发负责人。 （ 4）对发现的问题如产生歧义，需进行评审。由于评审的结果可能会引起需求变更，所以应该保留评审文档。（5）研发

8、人员经过分析、修复并自测完毕，生成BUG 修复报告，返给测试人员。（6）测试人员进行反复测试，直至测试通过。（ 7）测试人员确认产品达到要求，在产品测试报告的结论栏内签字表示同意，交给项目负责人。（ 8）汇总并提交所有相关文档，并知会研发部经理。产品发布 （ 1）经测试合格的产品由项目经理填写产品发布公告，连同发布文档一起提交给研发部经理进行审核，签字发布。发布公告需送达销售部、技术支持部及公司有关领导。 （ 2）项目负责人需在产品发布后一周内安排相关人员整理相关文档并提交，研发助理进行归档。 （ 3）产品发布公告需说明项目名称、编号、产品名称、型号、版本号、产品内软硬件版本号、产品主要特征及

9、功能、产品与上一版本的区别、产品的适用范围、使用注意事项等。（ 4）产品说明书和产品使用手册应在产品发布后由项目负责人指定人员撰写。研发管理表格 项目立项申请表 编号：填表人： 项目名称项目简称 初始版本号 申请时间市场情况概述 市场背景（用户群、销售潜力、预计年收入等）市场同类产品对比分析使用对象 预计完成时间 可行性分析研发平台及工具产品功能描述 问题及风险分析意见与审批 研发经理意见签字： 日期： 年 月 日 总经理意见签字：日期：年月日阶段评审会议 在项目发展的重要时间段，如里程碑阶段，对设计文档应及时进行评审，以确定下一步的工作方向。遇到问题的人员需自行发起评审会议。项目团队评审会议

10、可以使项目团队成员了解项目的情况以及项目中存在的问题和难题，以讨论解决方案， 加快项目进行。 评审会议记录 项目名称 产品型号 评审类型 评审时间 版本号 提交评审材料： 评审主要内容： 评审结论： 存在主要问题及改进意见： 评审人员签字： 编制： 审核： 批准： 软件 Bug 详细跟踪记录表 项目名称 功能模块 Bug 说明 拟采用措施发现日期 清除日期 追踪过程记录 软件研发风险评估与控制表 软件研发风险评估与控制表需要提交给项目经理。可以采取共享excel 表格，由发现风险的人填写该表格的办法。风险排序风险等级风险项描述风险提交人风险跟踪人降低风险策略1 2 风险等级可划分为严重(导致功能不能实现 )、一般 (功能可以实现， 但技术指标没实现)、提示 (因人员因素影响工期：请假、变动 )等。 周工作总结计划表每周一提交工作计划总结，周总结中需对上周计划的完成情况做出汇总，未能完成的则提出问题点。周总结计划的模板可参考下表：上周工作总结：5-165-20 ；本周工作计划：5-235-28 序列 姓名