开发管理流程

开发管理流程公司发文会签单拟文部门: 研发部 拟稿人 日期:2007/12/文件标题: 公司开发管理规定发文说明:为加强研发部软件的规范化管理，提高软件开发规范性，特颁发此规定。在《司发（2006）20号研发部开发管理》文档基础上作了如下修订：1、将网上需求管理和网上问题管理流程合并进来2、增加配置管理流程规范3、强化质量评审制度发文单位：研发部批准人（签字）：批准人名单：会签人名单：行政办公会议人员会签人（签字）:发文编号司发【2007】号发文数量：1 发文日期：2007/12/发往单位:以公告形式通知全公司人员。行政人事部保存一份文件。信息平台提供信息共享。主 送：研发部销售部 技术支援部抄 送：总经办、行政人事部1/32开发管理流程深圳市信息系统有限公司公司文件司发【2007】20号 签发人：（）签名研发部开发管理规定产品开发过程配合配置管理规范的开发过程增加了新的修订，在开发过程中间嵌入软件配置管理。产品经理全程参与所有的过程， 对产品的整体负责。 销售部产品负责人、 技术支援产品负责人参与需求分析阶段。1.1 项目和版本开发过程1.1.1 项目概貌阶段参与的角色： 产品经理、项目经理活动： 项目需求概貌的制定（重点说明项目的定义性描述） 、项目计划的制定《项目概貌》中需要对项目所需的配置项进行描述。当在执行过程中，出现任何意外情况需要进行计划更改时，产品经理有责任及时修改当月的月度计划，并转发给所有相关人员，包括项目组成员、相关部门以及上级领导。输出： 《项目概貌》、《项目开发计划》1.1.2 需求分析阶段参与的角色： 产品经理、项目经理、、项目组成员、销售部产品负责人、技术支援部产品2/32开发管理流程负责人活动： 需求规格/产品规格的制定，含详细的用户界面规格、性能分析，市场分析软件版本发布报告表建立：产品经理， ，需求规格的制定（可以采用 的分析方法）：产品经理。需求规格的评审：评审专家、 、测试人员、销售部产品负责人、 技术支援部产品负责人市场推广规划的制定：销售部产品负责人总体方案的设计：产品经理总体方案的评审：配置库需求基线的建立：输出：《系统需求规格》、《系统需求规格评审》、《系统总体方案》、《系统总体方案评审》、《市场推广规划》1.1.3 系统设计阶段参与的角色： 项目经理、、测试经理、项目组成员活动：软件版本发布报告表更新：项目经理， ，系统概要设计：项目经理，项目组成员系统概要设计的评审：系统测试方案的设计：测试经理系统测试方案的评审：子系统设计：项目组成员子系统设计评审：配置库设计基线的建立：输出： 《系统概要设计》、《系统概要设计评审》、《系统测试方案》、《系统测试方案评审》、《子系统设计方案》、《子系统设计方案评审》1.1.4 编码阶段参与的角色：、项目经理、项目组成员活动：3/32开发管理流程软件版本发布报告表更新：项目经理，详细设计：项目经理，项目组成员详细设计的评审：单元测试方案的设计：项目经理，项目组成员单元测试方案的评审：单元测试用例的设计：项目经理，项目组成员子系统编码：项目组成员关键子系统编码抽样检视：项目经理编码单元测试：项目组成员输出： 《详细设计》、《详细设计评审》、《单元测试方案》、《单元测试方案评审》、《单元测试用例》、《子系统代码》、《代码检视报告》、《单元测试报告》1.1.5 系统测试阶段参与的角色： 测试经理、测试组成员、 、项目经理、项目组成员。活动：软件版本发布报告表更新：测试经理，集成测试：项目组成员、测试组成员、测试经理系统测试：测试经理、测试组成员系统测试报告评审：测试问题控制：测试经理、用户文档：测试经理输出：《系统测试报告》、《系统测试报告评审》、《质量评估报告》、《第三方组件和工具》、《安装程序》、《用户文档》、《版本说明书》1.1.6 版本发布软件版本的发布由测试经理提交软件版本各项和软件版本发布报告表， 由产品经理召集开发经理、测试经理、项目经理、 、技术支援部人员、市场人员，召开产品版本发布会，审核通过后，由配置经理发布产品。《软件版本发布报告表》由研发部统一归档管理。4/32开发管理流程参与的角色： 产品经理、开发经理、测试经理、 、项目经理、。活动：软件版本发布报告表完成：产品经理、开发经理， ，配置库发布基线的建立：输出：《软件版本发布报告表》 ，见附件。整个开发过程如下图所示：5/32开发管理流程1.2 网上需求管理过程1.2.1 技术支援人员提需求角色：技术支援人员活动：通过邮件方式进行需求沟通：邮件标题：年/月/日+用户名称+关键字（需求）邮件附件：《客户需求邮件确认模板》，按模板详细提示进行操作、填写邮件接收者:主送研发部产品经理、项目市场负责人、技术支援部经理1.2.2 产品经理确认需求角色：产品经理活动：与客户沟通后、回复对该需求的判断及工作量的评估情况回复对象：原邮件所有接收人回复内容：与客户沟通记录？该需求能否做？工作量？预计开发时间等逐条答复回复时限：24小时内（1个工作日内）1.2.3 销售人员确认需求角色：销售人员活动：与客户沟通、研发产品经理协调，再做邮件回复；若与产品经理意见发生不一致，则提交研发部经理、销售部经理共同协调处理。回复对象：原邮件所有接收人，并抄送市场部秘书回复内容：与客户回复内容？工作计划？完成时间？是否发起客户需求电子流程？响应时限：48小时内（2个工作日内）角色：市场部秘书活动：发起客户需求电子流。角色：技术支援人员6/32开发管理流程活动：按照《需求评估通知函模版》正式答复客户响应时限：2个工作日内1.2.4 产品经理安排计划角色：产品经理活动；纳入产品计划，将需求文档同时提交开发经理和测试经理响应时限：24小时内（1个工作日内）1.2.5 开发经理安排计划角色：开发经理活动：纳入开发计划，知会测试经理，提交电子流到下一审批人对于紧急的需求，在正式版本发布以前走临时版本发布流程，在需求完成后，开发项目负责人在工作流中进行确认。正式版本未发布前由产品经理发布兼容临时版本代替。响应时限：根据产品计划监控角色；测试经理活动：纳入测试计划，知会测试人员提前熟悉需求响应时限：根据产品计划监控1.2.6 开发人员实施角色：开发人员活动：实施需求。提交开发包和发布包给开发经理提交电子流到下一审批人响应时限：根据开发计划监控角色：开发经理活动：提交发布包给测试经理响应时限：根据开发计划监控7/32开发管理流程1.2.7 测试部测试角色：测试经理活动：提交发布包给测试人员测试角色：测试人员活动：测试人员验证版本，发邮件知会测试经理测试完成。角色：测试经理活动；提交发布包和测试包给配置管理员，提交电子流到下一审批人响应时限：根据测试计划监控角色：配置管理员活动：收到测试经理邮件，发布版本，归档开发包和测试包响应时限：2小时1.2.8 技术产品部负责人确认角色：技术产品部负责人活动：安排工程人员更新现场，更新成功后提交电子流到下一审批人1.2.9 技术支援部经理确认角色：技术产品部经理活动：对需求的完成状态及质量跟踪确认，若完成则关闭电子流；若未完成则发起问题管理电子流 .。响应时限：24小时内说明：以上“响应时限”除开发实施和测试验证、工程实施是根据计划时间来监控外，其他流程要求在规定时限内做出实质结果。对于审批通过的需求 /问题，研发在计划时间内完成。非客户因素导致该需求 /问题在承诺时间内到期未完成， 将由研发对该需求 /问题再次承诺完成时间，并由此派生第二个客户需求 /网上问题（以此类推，数量以累计方式统8/32开发管理流程计）。因客户临时调整或协助工作没到位等客观原因， 该需求/问题的完成期限顺延。 涉及流程各环节严格按该文件规定执行，因工作疏忽等原因导致流程停滞不前影响流程 /计划进度将追究相关人责任。1.3 网上问题管理过程1.3.1 技术支援人员提单角色：技术支援人员活动：以邮件方式将客户问题提交给技术产品部负责人进行处理过滤。1.3.2 技术产品部负责人确认角色；技术产品部负责人活动：对问题进行过滤，若需要研发协助，提交网上问题电子流。1.3.3 测试经理确认角色：测试经理活动；收到网上问题电子流后，请测试人员定位问题。角色：测试人员活动：定位网上问题，邮件知会测试经理问题定位原因。角色：测试经理活动：根据测试人员定位，若需要开发人员协助，将电子流提交开发经理处理；若需要技术支援人员协助，将电子流提交技术支援人员处理响应时限：8小时内1.3.4 开发经理确认角色：开发经理9/32开发管理流程活动：收到网上问题电子流后，安排开发计划，将电子流提交相应开发人员处理。响应时限：3小时1.3.5 开发人员处理问题角色：开发人员活动：收到网上问题电子流，按照开发计划开发开发完成后，归档更新包和开发包，以邮件知会开发经理开发完成，在电子流中填写“处理说明” ，将电子流提交到下一审批人（测试经理）角色：开发经理活动：收到开发人员开发完成的邮件后，以邮件知会测试经理请求测试对于时间紧急的需求，开发经理提交临时版本发布流程，转1.4.4响应时限：按照开发计划监控1.3.6 测试部验证经理确认角色：测试经理活动：收到网上问题电子流，安排测试计划。角色：测试人员活动；测试人员验证版本；发邮件知会测试经理测试完成角色：测试经理活动：收到测试人员邮件，在网上问题电子流里确认，提交下一审批人；提交更新包和测试包给配置管理员。响应时限：按照测试计划监控角色：配置管理员活动：收到测试经理邮件，发布更新包，归档开发包和测试包响应时限：2小时10/32开发管理流程1.3.7 技术支援部安排实施角色：技术产品部负责人活动：收到网上问题电子流，安排工程人员实施；实施后对问题解决质量跟踪确认，如果发现问题，返回1.3.2执行；没有问题结束网上问题电子流。响应时限：12小时内1.4 临时版本管理过程有时会出现项目需要在较短的时间内提交在线版本的情况。 原因比较多，有市场等多方面的因素。这时候，项目组可以在设计、编码、测试方面走快速通道。由于试用版本在实现过程中存在一定的风险， 不排除上线后出现较大的问题。 需要产品经理、开发经理、技术支援部人员、市场人员共同提交试用版本发布报告表， 主要是阐明可能存在的风险，经相关人员审核通过后发布。在推出后续正式版本之前， 需要充分考虑完全兼容试用版本。 要求能够无缝地进行软件升级。1.4.1 需求分析参与角色：产品经理，活动： 需求分析：产品经理，需要对功能的实现进行取舍。当然，需要与用户沟通。需求规格说明书评审： 、测试人员输出：《需求规格说明书》1.4.2 概要设计参与角色：项目经理，，项目组成员活动： 概要设计：项目经理，项目组成员概要设计说明书评审：输出： 《概要设计说明书》11/32开发管理流程1.4.3 编码参与角色：项目经理，项目组成员，活动： 编码：项目经理，项目组成员安装操作说明书：项目组经理、项目组成员输出： 提交测试版本（包括安装版本、安装操作说明书）1.4.4 临时版本发布参与角色：产品经理、开发经理、项目经理、技术支援部人员、市场人员活动：1、临时版本的发布由产品经理发起，产品经理负责拟定报告表，填写临时版本概述、发布原因及存在风险； 并指定临时版本研发部的接口人， 接口人负责接收和收集现场反馈的用户需求和问题。响应时间：8小时工作时间2、开发经理签署意见，将更新包提交测试经理确认，开发包提交配置管理员归档。响应时间：8小时工作时间3、测试经理安排测试人员对临时版本做安装检查，输出检查报告，并签署意见。响应时间：8小时工作时间4、销售部经理签署意见，销售部经理外出可授权相关人员审批或邮件回复。响应时间：4小时工作时间5、技术支援部经理签署意见。响应时间：2小时工作时间6、研发部经理填写审核结论。响应时间：2小时工作时间7、配置管理员签字确认后发布临时版本。响应时间：2小时工作时间8、研发部秘书归档报告表。响应时间：4小时工作时间 。以上各步骤责任人因外出未能及时填写报告表的， 上一步骤责任人可要求该步骤责任人所属部门秘书通过电话或邮件提醒责任人， 责任人回复邮件指定授权人填写报告表， 各部门12/32开发管理流程秘书督促相关被授权人按各流程响应时间及时填写报告表。输出： 《试用版本发布报告表》 ，见附件《试用版本发布报告表》由研发部统一归档管理。产品配置管理过程为加强研发部软件的规范化管理， 严格软件开发的过程控制以及版本发布过程， 提高软件开发规范性，特制定研发部软件开发的配置管理规范， 其作用范围涵盖目前公司所有在开发和已经开发的软件版本。本方案解释权在研发部。2.1 人员与职责2.1.1 产品经理研发部设立了产品经理的岗位，需要在项目开发过程中发挥其重要作用：在项目概貌阶段，参与项目概貌的制定和软件配置项。在项目分析阶段，参与项目的需求分析工作，参与总体方案的制定和各部门的分工界定。在项目基线化阶段，协助参与版本的归档。开发过程中关键设计文档必须要包含有产品经理审核确认， 关键文档包括需求规格、 总体设计、概要设计、系统测试方案等。文档中包含以下要素：设计人———文档的作者。审核人———文档审核人，为产品经理 /技术专家，未经过审核的文档不能参加评审。产品经理——最终确认人。2.1.2 开发经理研发部在项目的生命周期内， 设立开发经理的岗位，需要在项目开发过程中发挥重要作用：在项目概貌阶段，协助产品经理参与项目概貌的制定和软件配置项。13/32开发管理流程在项目开发过程阶段，协助产品经理参与项目的需求分析工作，参与项目的方案设计和编码工作。定期向产品经理、开发部经理汇报项目的工作进度。2.1.3 配置管理员研发部设立岗位，负责公司软件开发配置管理，其职责包括：建立和维护各个软件版本的基线库。对配置项进行管理和控制。负责版本发布。对配置项的变更进行跟踪，并形成定期的配置审计报告。每周备份数据库2.2 可行性保证配置管理员以工作输出归档为依据，确认该项工作任务的完成。各开发经理和测试经理负责将配置项打包提交归档。配置管理员定期进行配置审计工作，核查归档的完备性和正确性，输出配置审计报告。2.3 数据库权限管理1、产品基线库用来保存所有产品所有版本的源代码及文档，访问路径为 。由配置管理员进行日常维护产品管理部成员对此库中对应的产品具有访问权限2、产品发布库作为产品发布的唯一出口，访问路径 ，由配置管理员进行日常维护技术支援部成员对此库具有读取权限3、开发组专用数据库研发各开发组拥有自己专用的开发库， 开发组专用数据库由开发经理及开发组成员进行维14/32开发管理流程护。开发组成员具有对各自数据库的访问权限，不具有对其他组的访问权限。4、品质保证组专用数据库品质保证组数据库访问路径为 品质保证组\品质保证组数据库由测试经理及成员进行维护品质保证组成员和具有此数据库的访问权限各开发经理具有对此数据库对应目录的访问权限2.4 配置项定义公司软件配置管理对象统称配置项（） 。目前公司的配置项包括：需求规格说明书源代码总体方案概要设计（以及详细设计）系统测试计划测试用例测试报告测试结果记录表单元测试报告单元测试用例集成测试用例评审报告版本安装说明版本修改清单版本描述用户使用手册维护手册验收手册安装程序15/32开发管理流程采用的组件和动态库、以及外部应用程序。2.5 基线定义软件版本在开发过程中在每一个阶段评审点后都会形成相应的基线， 目前的基线设置包括以下几个：需求基线：包括软件的需求分析文档、以及总体方案、需求评审表。设计基线：包括软件的概要设计、测试方案、以及相应的评审表格。发布基线：包括详细设计、代码、测试用例、软件工具、组件以及外部的应用程序、系统测试报告，发布评审表格。相应的一旦形成基线后其变更应该严格受控。基线化操作由产品经理和共同完成。在项目进行到相应阶段时，由产品经理将本项目相应配置项整理后统一交给，由检查无误后归入基线，检查项包括《项目概貌》和评审文档。和产品经理对每一次基线化操作负责。2.6 版本发布控制版本发布的次数。版本发布间隔不少于 10个工作日。在发布间隔时间内的需求和问题，统一安排在下一个版本完成并基线化。需求或问题答复时，开发经理可以按此来规划完成的时间。如果没有需求或问题，则不需要进行版本发布，但可以进行更新包的发布。对于特别紧急的版本，可以走“版本快速发布通道” 。随着版本质量的提升，这种情况会慢慢减少。拒绝一些市场人员不负责任的客户承诺。配置经理每 10个工作日发布一次版本更新汇总可以跟产品经理一起来完成， 抄送給所有的产品经理、 开发经理、技术支援部和市场人员。产品经理的责任产品经理需要对产品的导向要有明确的目标。是归并在统一版本还是只是作为特定版本进行维护，需要产品经理在申请变更时作出明确的说明。16/32开发管理流程2.7 配置管理过程2.7.1 制定配置管理计划配置管理员依据产品计划制定每月产品基线计划，并知会开发经理、测试经理2.7.2 开发经理提交更新包开发经理开发完成（或回归版本开发完成）发邮件通知测试人员取更新包2.7.3 测试经理提交测试包测试经理完成测试后提交更新包和测试包2.7.4 开发经理提交开发包开发经理收到测试经理确认测试完成的邮件后即整理并提交开发包2.7.5 配置管理员发布和归档配置管理员取更新包归档并发布，取开发包、测试包归档。配置管理员每周发布归档情况督促相关人员归档。2.8 归档规范2.8.1 包定义发布基线由开发包、测试包、发布包（或更新包）三个包构成。发布基线在产品完成每次提交发布时候建立。更新包：针对网上问题和网上需求更新。发布包：针对新版本发布。开发包：包括源码和文档。测试包：包括所有测试文档。17/32开发管理流程2.8.2 归档规范数据库作为产品基线库，包含与产品相关的所有工作成果，发布包（更新包） 、测试包以及开发包中内容均应包含在内。数据库作为对外发布的数据库，包含发布包（或更新包）内容。目前库按照产品+局点归档，库按照产品+版本+局点归档，对于针对多个局点的版本在相应的位置同时归档。2.8.3 包命名规范包名由产品编码、版本号、版本日期号、局点名称以及版本简要描述、包的类别、打包日期几个要素组成，所有字母统一用英文大写。格式：<产品简称>空格V<版本号>空格R<版本日期号>空格<局点名称><版本简要描述>更新包(<日期>)范例：V3.0R950 山东平台与客服接口更新包 (20071016)2.8.4 打包规范发布包发布包包含用户文档、安装文件、需求文档三大部分。文档模板参考《版本安装说明》 、《版本描述》更新包更新包包含用户手册、安装文件、 《版本更新说明》。《版本更新说明》文档必须包含 备份、更新、回退三个步骤，内容层次要清晰明了。文档模板参考《版本更新说明》开发包开发包包含源码和文档，文档包括需求规格、概要设计、开发手册、需求确认邮件、 《版本修改清单》对于所有已发布版本，开发经理都必须及时提供开发包归档。文档模板参考《版本修改清单》测试包18/32开发管理流程测试包包含单元测试文档和系统集成测试文档，新版本开发需包含《测试计划》 。文档模板参考《系统测试计划》、《测试用例》、《测试报告》、《测试结果记录表》、《单元测试报告》、《单元测试用例》、《集成测试用例》产品质量评审过程评审是提升软件质量的有效手段。为了增强对评审的控制，公司从几个方面进行管理：建立专家库：针对各个方面的专业知识和技能， 公司将遴选部分优秀员工加入相应的专家库， 参加评审的专家人选将优先从专家库中挑选。评审专家和主审人的确定：1、每次评审相关产品线 /部门必须至少有一人参加，不得推辞，人员可以由产品经理 /部门经理指定；2、需要涉及到哪些产品线 /部门由主审人确定；3、所有评审必须要有产品部和测试部的人员参加；4、在月初制定月度计划时将评审计划和工作量安排进去；5、主审人的评分影响评审专家的考核；6、主审人默认为产品经理；7、产品需求规格评审必须需要销售（拓展）部门、技术支援部门参与；关键事件制度：评审主审人对参加评审的专家根据相关原则进行评定， 专家的评定结果分为四类， 分别如下：A、B：参与评审表现突出，有重要的评审建议获得通过，记入考核正向关键事件。C：能积极参与评审，并能给出相关建议。D：未能起到评审专家作用，记入考核负面关键事件。评审工作量：参与评审的专家，每次参与评审安排时间 /工作量为 1个人日。其他的规定：19/32开发管理流程未经过评审的重要项不允许基线化。评审的发起人为产品经理。评审专家在评审会议召开前必须出预审报告表。主审人评审后出评审报告表。专家需要在每个业务（如短信、网关、等）至少设定两个。当有项目需要评审时，两个专家至少一个需要对项目的评审完全负责。需要给出专家分的奖惩详细规定。预审报告表见附件。评审报告表见附件评审流程如下图所示：20/32评审电子流不合格评审报告

开发管理流程产品QA/项目经理/任务责任人1评审任务名称及计划完成时间评审需要完创建评审任务单，提交跟踪对象成的资料及完成时间评审文档及相关资料（含评审要点）系统部接口人2不需评审系统部确定评审级别、主审人、关闭评审专家评审专家3评审专家确定初审要点列表预审评审规范资料（含CHECKLIST）出预审报告4主审人审核预审意见5N召开评审会7Y6主审人主审人评审报召开评审会，提交评审报告不召开评审会，提交评审报告告8评审专家请专家会签9QAQA提交过程评估报告QA过程审计报告审计合格NY审计不通过，关闭遗留问题？NY审计合格，关闭10评审任务责任人问题解决报评审问题解决告11QAQA验证问题解决QA审计报告N已解决？Y审计合格，关闭21/32开发管理流程深圳市信息系统有限公司二零零七年十二月 日主送：研发部 销售部 技术支援部报送： 总经办、行政人事部印发时间：二零零七年十二月 日附件附件1基线归档申请表基线归档申请表编号项目编项目名称号基线化类型产品经理 时间软件配置项123456789101122/32开发管理流程121314151617181920软件配置经理 时间附件2变更控制报告表变更申请项目名称提示：说明变更原因和变更内容，估计此变更对项目造成的影响。变更申请申请人签签字，日期字变更审批[ ] 同意变更 [ ] 拒绝变更审批意见指示：审批人签签字，日期字执行变更提示：说明变更内容变更说明23/32开发管理流程执行人签签字，日期字签字 签字，日期附件3预审报告表预审报告表编号项目编项目名称号评审任务名称预审意见预审结论预审人 时间附件4评审报告表评审报告表编号24/32开发管理流程项目编项目名称号评审任务名称评审要点评审意见评审结论评审专家签名主审人 时间附件5软件版本发布报告表软件版本发布报告表25/32开发管理流程编号项目名称 项目编号版本概述（开发经理填写）软件开发过程（各个负责人填写）阶段负责人软件开发阶段 开始时间 结束时间 （签名） （签名）（签