NGCRM 版本总体流程(更新版).doc

PD-BOSS-ORG-ZTLC-001 （内部保密资料）NGCRM版本总体流程自年 月 日起正式生效广州从兴电子开发有限公司 编制： 审批：共 页 PD-BOSS-ORG-ZTLC-001 NGCRM版本总体流程文档修改历史日期版本作者修改内容评审号变更控制号发布日期2011-3-8V0.1高岚/李锋初稿2011-5-6V0.2李伶2011-5-14V0.3李伶更新5.1.10，增加涉及文档2011-6-1V0.4李伶调整4.1版本管理总体流程图，增加需求流程；新增4.2需求流程和4.5上载流程2011-11-2V0.5李伶根据项目特性，修订各流程细节2012-1-11V0.6梁展鹏、罗周杰增加BUG版本管理流程2012-1-20V0.7罗周杰新增2.3需求开发活动阶段与OA流程映射图目录1前言41.1文档目的41.2适用范围41.3名词解释41.4参考资料42正式版本流程52.1角色与职责52.2流程图62.3需求开发活动阶段与OA流程映射图72.4过程描述92.4.1需求流程92.4.2研发流程112.4.3测试流程152.4.4上载流程173bug版本流程193.1角色与职责193.2流程图203.3过程描述213.3.1确认BUG213.3.2建立缺陷单213.3.3缺陷评审213.3.4缺陷分析223.3.5BUG单排版223.3.6任务分派223.3.7缺陷处理223.3.8BUG版本上载231 前言1.1 文档目的规范NGCRM项目的版本需求、开发、测试、上载流程，明确项目版本开发过程中的各项活动，分清职责。有效地生产出正确的，与客户需求一致的软件产品1.2 适用范围本文档适用参与NGCRM割接项目的项目管理人员、需求管理人员、开发人员、测试人员、运维人员。1.3 名词解释术语解释NGCRM下一代客户关系管理系统1.4 参考资料编号资料名称作者1232 正式版本流程2.1 角色与职责角色职责备注移动公司l 发布需求,确定版本计划版本经理l 外部收集需求、协助确定版本计划；内部发布版本颁布计划，协助版本上线开发经理 l 跟据版本计划确定内部开发计划，跟进开发进度测试经理 l 跟据版本计划确定内部测试计划，跟进测试进度。版本打包上载开发组长l 安排各组的开发任务l 监控本组开发任务的质量设计人员l 完成概要设计编写l 参与概要设计评审活动设计总负责人l 协助需求人员制定CRM内部的实现方案l 协调、合并各组之间的完成概设开发人员l 编写代码l 配合测试人员测试测试人员l 编译、打包程序l 部署内部测试机l 执行内部测试运维人员l 负责需求上载的执行及上载过程中问题的反馈QAl 监控流程的执行情况2.2 流程图2.3 需求开发活动阶段与OA流程映射图2.4 过程描述2.4.1 需求流程 确定版本范围l 涉及的文档或工具：版本计划l 涉及的角色：客户、版本经理、开发经理、测试经理l 详细的活动描述：n 版本经理收到局方发布的版本计划，与开发经理、测试经理沟通确定版本范围n 确定版本范围后版本经理需要与客户沟通需求的优先级 需求评估l 涉及的文档或工具：版本计划l 涉及的角色：版本经理、需求负责人l 详细的活动描述：n 版本经理对每个需求指定需求负责人n 需求负责人对需求进行评估，并填入版本计划中相应的列。评估内容包括： 工作量估算 涉及CRM开发小组 识别是否涉及外围系统（CRM以外的系统，包括营帐、计费、HSC等） 存在的问题n 对于有问题的需求版本经理和客户进行进一步讨论，达成一致意见。n 对跨项目需求，版本经理与其他项目版本经理做版本对接。 需求评估结果内部评审l 涉及的文档或工具：版本计划l 涉及的角色：版本经理、开发经理、需求负责人、开发负责人、测试负责人l 详细的活动描述：n 版本经理召集需求负责人、开发负责人、测试负责人对需求评估结果进行评审。n 评审过程中版本经理与开发经理确定重点需求n 版本经理将版本计划与局方确认。 确定版本计划l 涉及的文档或工具： 版本计划 l 涉及的角色：版本经理、开发经理、设计总负责人l 详细的活动描述：n 需求评估结果通过后，版本经理将版本计划内部公布。n 版本经理将内部评审过的版本计划与局方确认。n 版本计划公布后，开发经理根据需求评估结果（需求工作量等级为A/B的需求单）指定该需求的设计总负责人 建立OA需求版本l 涉及的文档或工具：版本计划 l 涉及的角色：需求助理l 详细的活动描述：n 需求助理根据版本计划在OA上建立版本，并将该版本的需求单录入，并填入相关的需求负责人，分发需求分析任务n 需求助理从OA定期（一周两次）导出版本开发进度，对版本进行监控 需求分析l 涉及的文档或工具：需求0级技术方案l 涉及的角色：需求负责人、设计总负责人l 详细的活动描述：n 需求负责人接到需求分析任务后， 其进行分析，产出需求0级技术方案，需并将文档放入配置库，svn路径为（03需求/12 版本需求分析）n 设计总负责人应该协助需求人员制定CRM内部的实现方案n 完成需求分析任务时要在在处理情况中填写需求0级技术方案的SVN路径或其它说明。n 如果需求为产品配置并涉及其他项目配置，由需求负责人与其他项目接口人联系，说明配置需求。（待讨论） 需求0级技术方案评审l 涉及的文档或工具：需求0级技术方案、需求0级技术方案评审报告l 涉及的角色：需求负责人、开发人员、测试人员、运维人员、涉及系统接口人l 详细的活动描述：n 需求负责人对需求0级技术方案发起需求评审，并召集相关开发、测试、运维人员以及所涉及的系统接口人参与。n 评审方式采取先邮件预审然后集中评审的方式，同时在集中评审时可采用批量方式进行，提高效率。n 在评审过程中发现的缺陷，由需求负责人进行修改，功能组组长负责跟踪缺陷的闭合情况。n 评审后，输出需求0级技术方案评审报告中，放入配置库中。 建立开发计划l 涉及的文档或工具：版本计划l 涉及的角色：需求负责人、开发组长、测试组长l 详细的活动描述：n 需求负责人在OA上拆分需求变更给该需求所涉及的功能组组长n 开发组长根据需求负责人所分发的变更内容，给各组员安排开发任务。n 每条需求变更必须包含设计任务、设计评审、编码任务、单元测试、测试分发任务。如果为产品配置类需求则包含参数设计任务、设计评审、配置修改任务、测试分发任务。n 小组计划有变更时，开发组长需要邮件通知测试组长更新测试计划。如果测试任务已分发，由组员拒绝任务后，由测试组长重新分发。n 版本经理、需求负责人、功能组组长、测试组组长都有义务跟进开发、测试进度。跟进方式可以通过NGCRM项目日报监控开发进度2.4.2 研发流程 概要设计l 涉及的文档或工具：概要设计说明书l 涉及的角色：设计人员、设计总负责人l 模板地址：08/NGCRM/09文档模板/开发设计模板/l 详细的活动描述：n 设计人员根据需求0级技术方案进行概要设计，完成后在OA上提交任务，并在处理情况处填写设计文档的SVN路径。n 在设计过程中如果发现涉及产品配置，需在概要设计中说明配置方案。同时通知开发组长在OA上将参数配置修改任务分发给产品配置组长。n 配置方案要求可参见产品配置方案说明n 概要设计完成后，将其放入配置库中，并同步更新以下文档：1）05设计/03数据库设计/NGCRM.物理模型变更申请表.xls2）05设计/03数据库设计/CMCC.NGCRM.固定参数详细设计.doc3）05设计/03数据库设计/CMCC.NGCRM.系统参数配置设计.xls4）05设计/03数据库设计/CMCC.NGCRM.业务参数配置设计.xls05设计/03数据库设计/CMCC.NGCRM.业务规则检查配置设计.xls5）业务概设：/05设计/01概要设计/ 02业务概设（将需求级设计文档合并至业务级总文档）6）版本概设：/05设计/01概要设计/01版本概设7）crm后台独立程序：/21质量管理/02系统运营/NGCRM后台独立程序.xls（crm后台独立程序，如果有新增的或对原来修改的，务必先登记到以下svn，由各组代码提交接口人负责监督，没有登记不予以提交到测试）8）/01概要设计/服务组件设计/NGCRM服务组件需求矩阵.xls9）/01概要设计/服务组件设计/NGCRM服务设计文档(内部).doc10）/01概要设计/服务组件设计/NGCRM组件设计文档(JAVA).doc11）/05设计/01概要设计/服务组件设计/内外服务映射.xls12）设计注意事项参见，05设计/03数据库设计/NGCRM.物理模型相关的业务规则.xlsn 对于有设计总负责人的需求，设计总负责人要整体把握设计的进度，协调各组之间顺利完成概设。n 如果设计涉及库表变更，在设计完成后提交相关库表变更申请到外部（省公司，华为）进行评审，并在规定时间内跟进反馈的评审结果。如果外部评审不结束，则不提交设计评审任务，不启动编码任务。 概要设计评审l 涉及的文档或工具：概设评审报告l 涉及的角色：设计人员、设计总负责人、开发人员、开发组长、测试组长、测试人员、维护人员、需求负责人l 详细的活动描述：n 由组长检查设计文档是否齐全，设计人员发起评审（对于有设计总负责人的需求则由其合并各功能组的设计文档，并发起评审）。参加人员有设计人员、设计总负责人、开发人员、开发组长、测试组长、测试人员、维护人员、需求负责人。n 对于重点需求需要先邮件预审，然后集中评审方式。其余需求可视情况采用邮件评审方式进行。n 评审后，评审人将评审结果填入概设评审报告中，放入配置库中。n 对于概设评审过程中发现的缺陷，设计人员要对设计文档进行修改，并同步维护相关文档，相应的功能组组长负责跟踪缺陷的闭合情况。n 如果设计涉及库表模型变更，在设计评审通过后，由各个设计负责人在开发环境变更库表模型。 编码/参数配置l 涉及的文档或工具：单元测试报告l 涉及的角色：开发人员、功能组组长、设计总负责人l 详细的活动描述：n 开发人员根据概要设计进行编码工作，有设计疑问直接和设计人员沟通；n 编码要求参见编码规范,地址：08/NGCRM/02资料/02通用规范资料文档/03编码规范n 编码完成后，由设计总负责人检查设计相关产出，包括概要设计、概设评审报告，开发组长检查编码相关产出，包括安装文档、固定参数文档、固定参数SQL文档、系统参数文档，系统参数SQL文档，安装文档、库表变更日志等是否齐全。n 如果为参数配置类任务，则开发人员按照产品配置方案进行配置参数修改。 代码走查（可裁剪）/单元测试l 涉及的文档或工具：代码走查报告、单元测试报告l 涉及的角色：开发人员、功能组组长、设计人员、设计总负责人l 模板地址：n 单元测试报告模板地址：08/NGCRM/09文档模板/开发设计模板/NGCRM(功能_开发人员)单元测试报告.docn 代码走查报告模板地址：08/NGCRM/09文档模板/开发设计模板/NGCRM（功能_走查人员）代码走查报告模板（C+）.xls08/NGCRM/09文档模板/开发设计模板/NGCRM（功能_走查人员）代码走查报告模板（JAVA）.xlsl 详细的活动描述：n 如果是重点需求，需由设计人员和测试人员进行代码走查，输出代码走查报告。n 配置参数任务的评审用代码走查任务实现n 开发人员需在代码提交前进行单元测试，并填写单元测试报告n 参数配置完成后需进行配置评审，主要分为以下几点：1：需求人员&配置人员在前台界面查看产品相关信息是否配置满足产品规范说明2：计费信息配置评审：这个需要提交给HSC查看CRM是否漏挂、错挂计费ID信息3：如果需要修改、则输出修改方案。n 单元测试之后，需由设计负责人（设计总负责人）检查开发人员的输出是否与设计要求一致，发现有差异时要求开发人员进行修改。 分组按单提交代码列表(待讨论)l 涉及的文档或工具：代码列表l 涉及的角色：开发人员、开发组长l 详细的活动描述：n 开发在OA先提交“编码实现”任务，然后再提交代码列表。n 开发人员提供代码列表并协助测试人员进行代码编译打包；n 开发人员提供业务参数协助测试人员进行测试系统的模块部署；n NG-CRM项目群对于WAS前台集成原则上设定一天进行一次打包，打包时间设定为每天17:00，开发人员须在每天17:00前提交代码，交付测试团队。n 开发通过提交测试申请表的方式提交功能给测试组测试.1 SQL列表l 涉及的文档或工具：SQL列表l 涉及的角色：开发人员、功能组上载接口人、上载接口人l 详细的活动描述：n 开发人员提交自己负责的需求单涉及的SQL语句（库表变更、参数变更、菜单变更、权限变更等）到本功能组上载接口人。n 功能组上载接口人定时汇总组内SQL语句放上SVN。n SQL编写规范请参考BOSS版本SQL规范。n 上载变更的sql，如果涉及附件所列42张表，必须同时变更xxzw、xxzwhis下的表。.2 后台程序列表l 涉及的文档或工具：后台代码列表l 涉及的角色：开发人员、功能组上载接口人、上载接口人l 详细的活动描述：n 开发人员提交自己的后台独立程序安装文档到本功能组上载接口人n 功能组上载接口人定时汇总并提交到SVN上，方法如下： 需求组在SVN上给各组统一建目录； 各组每天将自组的新增量加到此目录（所有有文档统一放入此目录下）； 如果有临时紧急上载需要邮件通知上载接口人，并从版本上载增量维护中删掉临时紧急上载内容；临时紧急上载内容需求组会单独生成文档放到SVN； 到版本上载截至时间，需求组会锁住此目录，重建下版本目录提供给各组。.3 前台代码列表l 涉及的文档或工具：前台代码列表l 涉及的角色：开发人员l 详细的活动描述：n 开发人员按需求提交前台程序代码列表到SVN指定目录中。.4 安装文档l 涉及的文档或工具：安装文档模板l 涉及的角色：功能组开发人员、功能组上载接口人l 详细的活动描述：n 开发人员按需求提交后台程序安装文档列表到SVN制定目录中。n 请注意在安装文档中填写相关的监控策略。n 功能组上载接口人将版本的安装文档汇总。2.4.3 测试流程 测试需求分析（可裁剪）l 涉及的文档或工具：TDl 涉及的角色：测试人员l 详细的活动描述：n 测试人员在配置库中获取客户的原始需求文档、需求分析文档和概要审计文档。n 模块负责人根据需求说明书分析该需求需要修改的功能点。在TD的需求模块的相关需求下面填写需求功能点，按照系统模块进行划分。 制定测试计划l 涉及的文档或工具：测试计划、版本开发计划l 涉及的角色：测试组长l 详细的活动描述：n 测试组长根据版本整体计划安排版本整体测试计划，在OA上分发测试任务，任务包括测试设计、测试执行、测试报告。n 如果涉及到需要联调测试的需求，内部联调由测试规划组组织联调，外部联调由测试组组织联调。 编写测试用例l 涉及的文档或工具：TD平台l 涉及的角色：测试人员l 详细的活动描述：n 测试人员进行初步测试用例设计，在代码提交之前完成。n 根据后续设计增加、裁减、细化测试用例。n 如果涉及到需要联调测试的需求，由测试组统一编写联调测试用例。n 测试团队使用TD进行用例管理，TD上建立NG-CRM项目的模块，用例根据归属模块的不同，形成用例库。 测试用例评审l 涉及的文档或工具：评审报告l 涉及的角色：测试人员、测试用例评审人l 详细的活动描述：n 对重点需求必须进行测试用例评审。n 测试人员发起，召集测试用例评审人（可以是其他测试人员、测试组长、相关设计人员、需求负责人）进行评审，也可以邮件的方式按需求来评审测试用例。n 评审结束后，评审结果记录在评审报告中。测试负责人需对发现的问题对用例进行调整和修改。（邮件评审无需出评审报告） 测试环境准备l 涉及的文档或工具：前台代码列表、后台代码列表、打包编译工具、TDl 涉及的角色：测试人员l 详细的活动描述：n 前台代码：根据每天的前台代码列表，从配置库中获取指定版本的代码并打包。n 后台独立程序：根据后台代码中的版本号，编译后台独立程序。n 每次编译前，检查代码列表中是否有makefile发生改变，若发现有MAKEFILE变更，需向相应开发组的组长确认，确认通过后才能进行后续操作。n 测试人员根据开发提交的上载申请前台代码列表、上载申请后台代码列表编译程序。如有编译失败，通过缺陷打回到开发这边。n 如出现编译错误，登记在TD上。n 准备测试数据。 测试执行l 涉及的文档或工具：TDl 涉及的角色：测试人员l 详细的活动描述：n 测试人员根据测试用例，执行测试。测试的结果记录在TD上（如测试数据、结果、界面等证据）。n 到TD的test lab中更新用例的执行情况。n 测试结果尽量使用截图，图片格式一律使用JPG。截图软件建议使用SnagIt。n 测试过程中发现缺陷需在OA上进行登记，指定开发负责人，并跟进缺陷修复进度。n 测试人员审核开发人员的单元测试效果，对于应该在单元测试中发现却未被发现的缺陷，测试人员可以记录下来，最后由组长汇总。 编写或汇总测试报告l 涉及的文档或工具：TDl 涉及的角色：测试需求负责人l 详细的活动描述：n 测试人员在执行测试后输出测试报告，测试组长汇总版本的测试报告。n 为了保证开发质量及开发处理缺陷的及时性，测试组将每周提供项目缺陷报告，由测试主管发布。缺陷报告内容包含项目缺陷率，模块缺陷率，缺陷处理及时率。 联调测试（可裁剪）l 涉及的文档或工具：TD、联调测试用例、联调测试用例评审报告、联调测试报告、联调测试跟踪表l 涉及的角色：测试人员 l 详细的活动描述：n 需要联调测试的需求，内部联调由测试规划组组织联调，外部联调由测试组组织联调n 测试组编写联调测试测试用例并组织评审，执行联调测试，测试中发现的缺陷在OA登记处理。n 联调测试时测试人员要识别、确认涉及网络的需求相关信息2.4.4 上载流程（待讨论） 上载计划制定l 涉及的文档或工具：版本上载计划l 涉及的角色： 版本经理、开发主管、测试主管l 详细的活动描述：n 版本经理和各开发主管、测试主管根据版本计划、开发测试的实际完成情况确定版本上载内容，制定当期的版本上载计划（外部需求需要提前一周发布，内部需求需要提前3天发布）n 确定版本上载计划后，版本经理要与客户做确认工作 上载文档准备l 涉及的文档或工具：上载申请文档，上载检查列表，版本计划，代码列表，上载计划l 涉及的角色： l 详细的活动描述：n 测试人员将上载应用程序包、配置文件、SQL语句准备好n 需准备的文档还包括NGCRM上载变更影响分析、NGCRM统一版本上载、应用安装文档、设计文档以及上载Checklist 上载文档交付l 涉及的文档或工具：上载文档，上载检查列表，版本计划，代码列表，上载计划l 涉及的角色：测试负责人l 详细的活动描述：n 上载文档评审l 涉及的文档或工具：上载申请文档，安装文档l 涉及的角色：维护上载负责人，开发负责人、测试负责人、需求负责人、版本经理l 详细的活动描述：n 维护上载负责人牵头组织开发负责人评审上载文档（上载内容，配置文件，SQL），NGCRM统一版本上载，上载变更影响分析，上载Checklistn 在评审过程中发现的问题填在NGCRM上载问题跟进列表中，并指定问题跟进人 执行上载l 涉及的文档或工具：程序包，安装文档l 涉及的角色：维护上载负责人l 详细的活动描述：n 维护上载负责人根据上载操作文档，在上载当晚将前台应用包、后台独立程序等上传到应用服务器，包括旧应用的停用以及新应用的启动。n 上载过程中出现的问题，运维人员及时通知开发、测试人员解决n 在上载完成后填写上载顺序流程中的实际上载情况。 上线检查并验收l 涉及的文档或工具：上载记录l 涉及的角色：维护上载负责人、测试人员、开发人员l 详细的活动描述n 在上载完成后，由运维人员根据上载Checklist完成上载检查n 运维、测试配合客户进行验收，发现问题时通知开发、测试组成员进行处理。n 在上线检查以及验收过程中发现的问题需填写在NGCRM上载问题跟进列表中，并指定开发、测试负责人跟进。 版本总结l 涉及的文档或工具：版本总结报告l 涉及的角色：版本经理、开发经理、测试经理、运维经理、QAl 详细的活动描述：n 在版本上载后一周内需召开版本总结会议n 在会议召开前，项目各负责人应该提前填好按版本总结报告中相关的内容n 版本经理组织需求、开发、测试、运维负责人召开版本总结评审会，评估整个版本执行过程和上载过程，发现并讨论存在问题，填入版本总结报告中的问题列表并确定改进事项和责任人。2.5 附件列表文档名称文档附件NGCRM项目日报产品配置方案说明NGCRM上载变更影响分析NGCRM上载问题跟进列表NGCRM统一版本上载上载顺序流程上载Checklist3 变更处理流程3.1 角色与职责角色职责备注版本经理l 发起版本计划变更l 与客户确认版本计划变更需求负责人l 发起需求变更，0级方案变更设计负责人l 发起设计变更开发、测试人员l 评估变更l 实施变更3.2 流程图3.3 过程说明3.3.1 提出变更l 涉及的文档或工具： l 涉及的角色：版本经理、需求负责人、设计人员l 详细的活动描述：1) 版本计划变更：由版本经理发起，通知需求负责人、开发负责人、测试负责人2) 需求变更：由需求负责人发起，邮件通知开发负责人、测试负责人3) 0级方案变更：由需求负责人发起，邮件通知开发负责人、测试负责人4) 设计变更：由设计负责人发起，邮件通知需求负责人、开发负责人、测试负责人3.3.2 评估变更l 涉及的文档或工具： l 涉及的角色：版本经理、需求负责人、开发负责人、测试负责人l 详细的活动描述：n 变更发起人召集相关需求、开发、测试负责人进行变更影响评估，综合评估该变更需要的工作量以及对项目进度的影响， 判断变更能否实施。3.3.3 确认变更（可裁剪）l 涉及的文档或工具：版本计划l 涉及的角色：版本经理l 详细的活动描述：n 如果变更影响版本计划，版本经理将变更评估的结果与客户确认，更新版本计划并内部公布。3.3.4 实施变更l 涉及的文档或工具：版本计划、OAl 涉及的角色：版本经理、需求负责人、开发人员、测试人员l 详细的活动描述：1) 版本计划变更处理： 需求增加的处理：版本经理根据更新的版本计划在OA上新建需求单，指定需求分析人，按需求的正常开发流程进行。 需求删除的处理：版本经理根据更新的版本计划在OA上将要删除的需求作废处理（作废后该需求下属的所有开发任务消失），也可使用版本调出功能将需求调至其它版本。2) 需求变更的处理： 当变更出现在需求分析阶段（未分发开发任务）： 由需求负责人按照变更后的内容编写0级技术方案 评估变更是否影响开发计划，有影响则通知开发、测试负责人 当变更出现在开发、测试阶段（已分发开发任务）： 开发组长与需求负责人沟通确认，如需直接封闭变更的，要需求负责人在OA上发布封闭通知给各组长，开发组长方可进行直接封闭操作。 需求负责人重新分析需求，对需求0级技术方案进行更新，并邮件发布给相关开发、测试人员，说明变更内容和变更影响 需求负责人完成需求分析任务后重新拆分需求变更给各开发组长 组长按变更内容重新分发开发任务3) 0级方案变更处理 开发组长与需求负责人沟通确认，如需直接封闭变更的，要需求负责人在OA上发布封闭通知给各组长，开发组长方可进行直接封闭操作。 需求负责人重新分析需求，对需求0级技术方案进行更新，并邮件发布给相关开发、测试人员，说明变更内容和变更影响 需求负责人完成需求分析任务后重新拆分需求变更给各开发组长 组长按变更内容重新分发开发任务4) 设计变更处理： 处于编码阶段（设计任务已提交/编码任务未提交）：组长重新分发设计任务，并要求编码人员按更新后的设计文档进行编码。 处于测试阶段（设计、代码任务已提交，测试人员返回设计缺陷给设计人员）：设计人员根据缺陷描述对设计文档进行修改，完成后通知相关编码人员进行代码修改，待代码修复完成后设计人员将缺陷返回测试人员评审 该变更已经封闭（所有开发、测试任务已完成）：走内需流程进行修改。 4 内需申请流程4.1 角色与职责角色职责备注开发人员l 内需分析l 提交内需方案给组长评审开发组长l 对内需方案进行初审l 将内需方案提交给版本经理评审版本经理l 评审内需方案l 将内需排入正式版本，更新版本计划4.2 流程图4.3 过程说明4.3.1 内需分析l 涉及的文档或工具：内需0级方案内需申请单l 涉及的角色：开发人员l 详细的活动描述：n 开发人员在发现缺陷或优化需求后，可启动内需申请流程n 开发人员需要对内需进行分析，并输出初步方案即内需0级方案n 完成0级方案后，可填写内需申请单，并将其与0级方案一同交给开发组长进行初审。内需申请单模板: 50:8888/svn/NGCRMDOC/21质量管理/01文档模板/开发相关模板/内需申请单模板.xls4.3.2 内需方案初审l 涉及的文档或工具：内需0级方案内需申请单l 涉及的角色：开发组长l 详细的活动描述：n 开发组长对提交上来的内需申请单、内需0级方案进行初审n 开发组长首先判断内需方案是否通过，若不通过则打回开发人员处或与其确认疑点n 方案通过后开发组长要判断该需求走内需流程、缺陷流程还是外部需求流程 如果走内需流程则将内需申请单和方案提交至版本经理（李伶）或王楠处 如果走缺陷流程则启动BUG版本开发流程，具体见“BUG版本流程”章节4.3.3 内需方案评审l 涉及的文档或工具：内需0级方案内需申请单l 涉及的角色：版本经理l 详细的活动描述：n 版本经理对开发组长对提交上来的内需申请单、内需0级方案进行评审 如果评审通过则将内需排入正常版本中 如果不通过则将申请打回开发组长，内需申请流程结束4.3.4 更新版本计划l 涉及的文档或工具：版本计划l 涉及的角色：版本经理l 详细的活动描述：n 版本经理将评审通过的内需排入正常版本，更新版本计划n 如果涉及外围平台改造，版本经理应该通知所涉及的项目组将需求排入版本n 版本经理将更新的版本计划发布给开发、测试、运维负责人n 内需后续的研发流程和普通版本的需求一致，具体请见“正式版本流程”中的研发流程章节5 bug版本流程5.1 角色与职责角色职责备注移动公司l 登记下发bug单；与开发商确定BUG版本计划运维人员l 与开发人员协同确定属于BUG的事件单l 收集在日常维护中发现的BUGl 在OA上建立缺陷单l 进行BUG版本上载操作BUG版本负责人l 和局方沟通版本内容和上载时间，制定BUG版本计划l 监控BUG修复进度开发人员l 确认运维人员所收集到的BUGl 完成开发组长安排的缺陷修复任务测试人员l 验证缺陷修复情况5.2 流程图5.3 过程描述5.3.1 建立BUG版本l 涉及的文档或工具：OAl 涉及的角色：BUG版本负责人l 详细的活动描述：n 根据什么建立版本计划？n 新建版本时注意BUG版本的命名规则： 版本名称：BUG版本（年份.月份.日期）如：BUG版本(2012.2.27) 外部版本号：BUG年份.月份.日期 如：BUG2012.02.27 内部版本号：V.年份末两位.月份.0日期 如：V12.02.0275.3.2 确认BUGl 涉及的文档或工具：AMS、OA、事件单、BUG单l 涉及