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