软件产品发布管理流程规范

软件产品发布管理流程规范
软件产品发布管理流程规范

软件产品发布管理流程规范

1.目的

产品的发布主要用于指导从项目到产品,从产品到市场的发布过程,本过程目的是为了有效指导项目组开展产品发布,实现下列目的:

1)指导发布活动,有效控制产品发布过程

2)有效控制和追踪产品版本

2.角色与职责

1)运营人员:

(1)负责产品发布

(2)组织评审

(3)跟踪需要现场调测的异常产品包验证状态

2)产品经理:

(1)提出发布申请

(2)跟踪异常发布的产品

(3)负责产品移交给市场、销售部门

(4)审核产品发布

3)项目组开发成员:

(1)修改完善产品

(2)负责对市场、销售人员进行培训

(3)协助测试人员进行验收测试

(4)编写《用户手册》、《安装手册》

4)测试人员:负责产品测试

3.定义

1)软件版本正式发布:通过软件测试人员测试验证并符合发布标准的软件版本发布过程。2)软件版本异常发布通过软件测试人员测试;

4.发布前期

4.1、发布准备开发人员先要确定发布的准备工作和发布的日期。准备工作应包含以下内容:1)原有BUG的是否彻底解决;

2)新增模块在功能上是否达到设计要求;

3)修改了什么,增加了什么;

4)所做的改变带来的影响;

4.2、撰写文档开发人员确定所发布内容中是否有新增功能。若有,则需撰写一份需求文档(即功能列表文档),交给测试人员。否则发送测试通知单,告知测试人员。需求文档的内容如下:

1)所做的改动有哪些;

2)修改原有BUG或新增模块的设计目标

4.3、全面测试

测试人员在收到测试通知单或需求文档后,应进行全面、完善的测试,如果通过测试,发送测试报告给产品经理,并修改BUG状态。否则,将测试结果反馈给开发人员,测试结果中应包含以下内容:

1)原有BUG的解决情况或新增模块的BUG情况

2)发现BUG的测试用例

4.4、发布确认

通过系统测试后,测试人员将通过测试后的最新版本提交给产品经理:

1)产品经理编写《产品发布说明书》

2)产品经理通知项目开发组人员编写《用户手册》、《安装手册》,并组织评审,评审通过后,由产品经理提交给运营人员。

篇二

软件产品发布管理流程规范

1.目的

产品的发布主要用于指导从项目到产品,从产品到市场的发布过程,本过程目的是为了有效指导项目组开展产品发布,已实现下列目的:

(1)指导发布活动,有效控制产品发布过程

(2)有效控制和追踪产品版本

2.角色与职责

1)运营人员:

(1)负责产品发布

(2)组织评审

(3)跟踪需要现场调测的异常产品包验证状态

2)项目负责人:

(1)提出发布申请

(2)跟踪异常发布的产品

(3)负责产品移交给市场、销售部门

3)产品经理:审核产品发布

4)项目组开发成员:

(1)修改完善产品

(2)负责对市场、销售人员进行培训

(3)协助测试人员进行验收测试

5)测试人员:负责产品测试

3.定义

1)软件版本正式发布:通过软件测试人员测试验证并符合发布标准的软件版本发布过程。

2)软件版本异常发布:通过软件测试人员测试验证,但测试结果不符合发布标准的软件版本发布过程,可采取软件版本异常发布流程的情形仅限于生产和客户使用现场缺陷修复或现场测试等紧急情况。

4.发布前期

4.1、发布准备

开发人员先要确定发布的准备工作和发布的日期。准备工作应包含以下内容:

1)原有BUG的是否彻底解决;

2)新增模块在功能上是否达到设计要求;

3)修改了什么,增加了什么;

4)所做的改变带来的影响;

4.2、撰写文档

开发人员确定所发布内容中是否有新增功能。若有,则需撰写一份需求文档(即功能列表文档),交给测试人员。否则发送测试通知单,告知测试人员。需求文档的内容如下:

1)所做的改动有哪些;

2)修改原有BUG或新增模块的设计目标

4.3、全面测试

测试人员在收到测试通知单或需求文档后,应进行全面、完善的测试,如果通过测试,发送测试报告给项目负责人,并修改BUG状态。否则,将测试结果反馈给开发人员,测试结果中应包含以下内容:

1)原有BUG的解决情况或新增模块的BUG情况

2)发现BUG的测试用例

4.4、发布确认

通过系统测试后,测试人员将通过测试后的最新版本提交给配置管理员,并告知项目负责人:

1)项目负责人编写《产品发布说明书》

2)项目负责人通知并协调售前部门安排售前人员提供《用户手册》、《安装手册》,并组织评审,评审通过后,由项目负责人提交给运营人员。

3)项目负责人提交发布申请给产品经理,并通知运营人员开展产品发布前评审,运营人员、测试人员、项目负责人协助开展评审,评审通过后,配置运营人员向产品经理提交评审报告和发布申请进行审批。

4)审批通过后,产品经理告知配置管理员实施发布;审批不通过则放弃本次发布。

5.产品发布

5.1软件版本正式发布流程

5.1.1源码、文档入库

源码包括数据库创建脚本(含静态数据)、编译构建脚本和所有源代码;文档包括需求、设计、测试文档,安装手册、使用手册、产品变更信息文档、相关联的系统版本号、产品介绍等相关文件。

5.1.2程序打包

开发人员进行程序打包;标记源码、文档版本。

5.1.3发布产品

编写产品发布计划,填写配置项,并执行发布计划(发布产品)。

5.1.4正式发布通知

通知开发、测试、市场、销售各相关部门,并附上产品发布说明和产品介绍。

5.2软件版本异常发布流程

5.2.1运营人员启动软件发布后,如发现软件测试人员提供的测试结果不符合软件发布标准时,可选择重新提交测试,或者申请启动软件版本异常发布流程。

5.2.2项目负责人填写《软件版本异常发布说明》,启动软件版本异常发布流程。

5.2.3软件版本异常发布时,项目组仍须提交程序软件包,产品发布说明,需求变更信息说明等文档。

5.2.4运营人员提交软件异常发布文件给项目负责人及技术部总监审核,技术部总监批准后,即可异常发布软件版本。

5.2.5运营人员按照文件分发要求进行发放和登记。

5.2.6开发人员需对异常发布的软件版本进行跟踪,并确保在预定的期限内该软件版本被正式下发的软件版本替代。

6.后续工作

产品发布后,在使用过程中可能还会发现一些bug。在不影响正常使用的情况下,这些bug将在下一版本发布时解决;如果bug严重影响使用,必须打补丁或者按照流程重新发布。

仅供参考

公司软件管理规范

XXXXXX有限公司 文件制订(修订、作废)申请单NO.: 表格编码:

1. 目的 为规范公司软件、程序的管理,确保开发、使用、变更等过程得以受控,根据本公司实际情况,特制定本规范。 2. 适用范围 本规范适用于公司所有自主开发、外购、客供软件、程序的管理。(如无特别说明,本规范内“软件”包含软件、程序) 3. 软件分类: 3.1产品源程序: 由研发部软件开发工程师编写,实现产品功能的烧录文件。 3.2 ATE测试软件及测试程序: 是指由信息技术部负责编写的配套ATE硬件使用的产品测试软件平台,及在此平台下针对不同型号产品编写的测试程序。 3.3 设备应用程序: 是指工程部在设备操作系统下针对不同产品型号编写的对应程序(ATE除外)。如:打码程序、贴片程序、SPI检测程序、AOI检测程序、分板程序、回流焊程序、X-Ray 测试程序等。 3.4管理应用软件: 是指企业使用的电子化管理工具或系统平台。如:ERP系统、品质管理系统、SPC系统、生产报表系统、电子看板系统、绩效管理系统、项目管理系统等 3.5办公软件:Windows、office、Coremail、PDM、AutoCAD、杀毒软件等。 4、职责定义: 原则上公司各部门均可依据自身需求提出软件申请,由技术部门进行开发,交由使用部门进行管理,异常无法解决时,可向技术部门寻求技术支援。具体定义如下: 4.1 需求提出部门:依据公司或者部门的实际情况,提出软件需求申请。软件需求多由软

件使用部门提出,但也可以由其它部门提出。 4.2使用/管理部门:对提出的申请进行评估,确定需求后向开发部门发起正式申请;在软件验收合格后负责日常的管理、维护等;当异常时且无法解决时,及时向开发部门反馈,并要求协助处理。 4.3开发部门:对于使用/管理部门提出的申请进行评估,确定执行方案,并最终完成软件开发;开发部门也负责后期的技术支援。 4.4监控部门:负责对软件验收完成后的使用过程进行监控,确保不出现使用错误,维规操作,使用非法软件及机密软件外流等。 4.4软件管理职责对照见下表: 分类开发部门使用/管理部门监控部门 产品源程序研发部工程部品质部 ATE测试软件及测试程序信息技术部工程部品质部 设备应用程序工程部工程部品质部 管理应用软件信息技术部使用部门信息技术部 办公软件信息技术部使用部门信息技术部 5.软件管理规范: 5.1软件申请、开发、使用管理流程图:(如下图)

软件配置管理规定

软件配置管理规定? 为进一步加强软件配置管理工作,明确软件配置原则,规范软件配置流程,制定本规定。 一、配置原则? 1、软件配置遵循安全性、适用性、 2、单经济性与正版化得原则,不得配置非正版软件。? 位使用得商业软件、OEM软件、免费软件均需纳入配置管理,不得配置与工作无关得各类软件。?3、优先采用场地授权(许可)方式配置软件。 二、配置流程 1、软件使用部门根据本部门各岗位工作需要,编制岗位软件需求清单,填写《软件使用需求申请表》(附件1)。 2、信息化部门统计、汇总软件使用部门报送得《软件使用需求申请表》,对软件使用部门需要得相关软件进行统一测试与试用,综合考虑软件得价格、兼容性、安全性与售后服务等因素,确定软件选型,明确软件名称与版本.涉及使用免费软件得,更新《可使用免费软件清单》(附件2)。 3、信息化部门依据单位软件使用管理台账,梳理单位软件需求与现有软件许可得差异。单位软件许可不足得,编制《软件采购计划表》(附件3)。 4、财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年

限、兼容性与售后服务等要求。?5、财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作,重点就是软件采购合同、软件授权证书、软件安装序列号等资料得管理工作。? 6、信息化部门负责软件使用管理日常工作。?7、单位采购得软件,因以下情况申请报废得,需经过信息化部门鉴定,严格履行资产处置报批手续:?(1)已经达到规定得最低使用年限,且无法继续使用得.?(2)未达到规定得最低使用年限,因技术进步等原因无法继续使用得。?(3)未达到规定得最低使用年限,因计算机硬件报废,且无法迁移到其她计算机上继续使用得. 8、信息化部门在单位新采购软件、报废软件与调整可使用免费软件清单后,更新《软件使用情况汇总表》(附件4)。

产品研发部管理制度及流程

规划设计和技术质量管理制度及流程设计管理制度--项目前期工作指导书 为使规划设计和技术质量日常工作达到规范化、制度化,高效优质地完成公司的各项计划和任务,规划设计和技术质量特制定本指导书。 规划设计和技术质量的日常性工作包括以下几个部分: 一、设计任务书 1、编制《设计任务书》:根据《项目开发计划》和《市场分析报告》, 编制《设计任务书》。设计任务书包括《方案设计任务书》和《施 工图设计任务书》。 2、征询各部门意见:由负责人填写《征询意见表》,经本部门认可后, 发营销部、工程管理部、成本合约部征询意见。 3、协调各部门意见:由负责人汇总各部门意见,如有不同意,可组织 相关部门,召开协调会议,协调会议应由负责人负责记录,并汇总 意见后出《会议纪要》。 4、报审:由负责人依据各部门意见和有关的《会议纪要》修改《设计 任务书》,填写《公司文件审批流程表》后,上报主管领导批准。 5、存档:由负责人将《设计任务书》编号存档。 二、方案设计 方案设计包括:总体方案设计、户型方案设计、立面方案设计、环境方案设计等。 1、编制计划:由规划设计和技术质量依据《项目开发计划》编制《方 案设计组织计划》,本部门认可后存档。 2、选择设计单位:由负责人选择符合资质的设计单位,填写《公司文 件审批流程表》,上报主管领导批准 3、签订合同:由负责人拟订《方案设计合同》后,上报主管领导批准, 并与设计单位签订《方案设计合同》。 4、准备资料:由负责人准备《方案设计任务书》、地形图及相关资料

填写《资料发放记录单》,转交设计单位签收。 5、现场踏勘:由负责人组织设计人员进行现场踏勘,并填写《现场工 作记录表》。 6、监控:项目负责人应随时了解方案设计进度,对于过程中出现的问 题及时解决,必要时可以组织协调会,请相关部门参加,并作会议 纪要。 7、接收设计成果:由负责人按《方案设计合同》及有关要求接收设计 成果,并填写《资料接收记录单》。 8、审核:由负责人对方案进行审核,提出方案审核意见。 9、评审:由负责人报请主管领导批准召开方案评审会,并负责组织、 记录方案评审会,出《会议纪要》,进行设计修改。 10、结算设计费:由负责人按《方案设计合同》结算方案设计费。 三、施工图设计 施工图设计包括:建筑施工图设计、环境施工图设计、灯光设计、智能化施工图设计等。 四、施工图审核:见《施工图审核管理办法》。 五、环境设计 六、项目前期工作(办理规划许可证及其相关报批手续)

软件配置管理流程

配置管理流程规定 (Ver1.0) 拟制:___________________ 审核:___________________ 签发:___________________

目录 1.配置管理流程 (3) 1.1概述 (3) 1.2总体流程图 (3) 1.3软件需求分析阶段 (4) 1.4软件设计阶段 (4) 1.5制定配置管理计划 (4) 1.6配置库管理 (4) 1.6.1相关人员分配权限 (4) 1.6.2配置项 (5) 1.7版本控制 (6) 1.8变更控制 (6) 1.9配置审计 (8) 1.9.1配置审核的类别 (8) 1.9.2配置审核执行的时机 (8) 1.9.3不符合项的处理 (8) 2.0.0配置状态报告 (8) 2.0.1配置状态报告的目的 (8) 2.0.2配置状态报告记录的内容 (8) 2.0.3配置状态报告的生成 (9) 2.1.0发行管理 (9) 2.1.1交付管理 (9) 2.软件基线化规范 (10) 2.1正常开发期 (10) 2.2版本发布期 (11) 2.3项目发布期 (13) 3.Jira配置管理 (14)

1.配置管理流程 1.1概述 规范配置管理活动,确保配置项正确地唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2总体流程图

1.3软件需求分析阶段 参加需求分析会议,配置管理负责人记录,有关文档提交归档。如《需求分析》。 1.4软件设计阶段 参加设计阶段,为了详细制定配置管理计划。针对需求分析报告进行系统设计,配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审通过后,建立设计基线。 1.5制定配置管理计划 配置管理员制定配置管理计划,主要内容包括配置管理软硬件资源、配置项计划、备份计划等,审批该计划。 1.6配置库管理 配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 1.6.1相关人员分配权限 项目经理: 1)与(有关负责人员)协商确定项目起始基线 2)接受配置管理计划,并按相关规定贯彻执行; 3)接受配置控制委员会的报告。 4)提出配置管理计划的修改要求; 5)提出管理管理的建议和要求。 配置管理员 1)编制配置管理计划; 2)执行配置项管理; 3)执行版本控制和变更控制方案; 4)编制配置状态报告; 5)配置库的建立和权限分配; 6)配置管理工具的日常管理与维护; 7)配置库的日常操作和维护 开发人员

产品研发管理制度

产品研发管理 第一节 产品研发岗位职责 一、研发经理岗位职责 产品研发经理的主要职责是新产品的研发工作,其具体职责如表4-1所示。 表4-1 研发经理岗位职责 1.工作规划 (1)负责制定与企业产品研发相关的规章制度和工作流程,经领导审批后执行 (2)根据企业总体规划和生产经营需要,制订新产品研发计划 (3)根据企业发展计划以及客户需求和市场发展趋势,确定新产品研发方向 2.研发过程管理 (1)研究新产品技术方向,组织新产品设计、试制、改进等系列工作 (2)对新产品进行可行性分析,提出研发立项申请 (3)制定产品研发费用预算及实施成本控制 (4)根据研发计划合理分配任务 3.研发结果评估 (1)组织产品研发成果的鉴定和评审 (2)分析总结研发过程的经验与教训,制订并执行工作改进计划 4.其他工作 (1)指导、监督、培训、考核下属人员的工作,提高工作绩效 (2)完成领导临时交办的其他工作 二、新品研发组长岗位职责 新品研发组长在研发部研发经理的指导下,协助制订产品研发计划,开展产品研发工作。其具体职责如表4-2所示。 表4-2 新品研发组长岗位职责 1.基本职责 (1)严格执行与研发工作相关的规章制度和工作标准 (2)传达上级领导的指示,完成领导临时交办的各项工作 工作大项 工作细化 工作大项 工作细化

2.参与产品研发(1)了解行业市场信息,做好新产品的可行性论证和立项准备(2)参与新产品的试制,做好试制记录,发现问题及时解决(3)指导、帮助生产人员进行新产品生产 (4)参与新产品的上市推广工作,协助推广新产品 (5)参与新产品的评审工作 3.编制报告 (1)编写新产品研发和老产品改进工作报告 (2)定期向产品研发经理提供新产品开发报告和完整的新产品技术资料三、产品设计工程师岗位职责 产品设计工程师主要负责产品设计规划工作,并对设计进行全程管理与控制,同时对相关人员进行培训。其具体职责如表4-3所示。 表4-3 产品设计工程师岗位职责 1.制定设计规范及规划(1)负责研究和优化所管理业务的工作流程,编制相关的工作标准(2)负责组织相关人员编制设计技术任务书等设计文件 (3)负责相关产品或项目的设计规划工作,经批准后监督执行 2.设计过程控制(1)编制并实施设计进度计划,对计划的执行情况进行跟踪、检查(2)参与设计图纸的校核、评审及审批,并提供专业意见 (3)控制设计过程中的质量与成本,确保设计工作并能按计划圆满完成(4)指导相关人员的设计工作,明确设计中的各项技术要求 组织召开设计专业例会,解决设计过程中存在的问题 3.设计人员培训负责所辖设计人员的培训工作 4.其他职责 (1)协助有关人员将设计转变为产品的工作,提供相关的技术支持和专业意见 (2)完成领导交办的其他任务 工作大项工作细化

软件版本管理规定

上海精佑通信技术有限公司企业标准 (管理标准) Q/HT 0001–2005 软件版本管理规定 V1.04 2005-04-11 发布 2005-04-11实施

上海精佑通信技术有限公司 目录 1范围 (4) 2术语和定义 (4) 2.1软件 (4) 2.2产品软件 (4) 2.3生产支持软件 (4) 3软件版本命名规则 (5) 3.1软件版本命名组成 (5) 3.2手机软件版本命名 (5) 3.3模块软件版本命名 (5) 3.4手机PC侧软件版本命名 (6) 3.5模块PC侧软件版本命名 (7) 3.6手机生产支持软件版本命名 (7) 3.7模块生产支持软件版本命名 (8) 3.8公用于所有手机和模块的软件版本命名 (9) 3.9无线上网卡相关软件版本命名 (9) 3.10无线上网卡驱动软件版本命名 (10) 3.11正式版本号的升级规则 (10) 3.12版本的电子文件命名规则 (11) 4软件版本发布流程 (11) 5禁止条例 (14) 6管理条例 (14) 7附录 (14)

上海精佑通信技术有限公司 文档版本变更记录: 版本号拟制日期拟制人版本描述存档编号 V1.00 2005-4-11 郝军初始版本 V1.01 2005-4-27 郝军1.版本号前增加“V”,用以明显标识版 本号 2.版本号和时间之间以下划线分隔 3.增加生产支持软件种类 4.增加无线上网卡生产支持软件、管理 器软件和驱动软件命名 5.增加版本发布流程的文字说明 V1.02 2005-7-1 郝军增加手机和模块生产支持软件的类型:射 频补丁软件(RFP) V1.03 2005-7-15 郝军更改版本号升级规则,更改资料外发申请 表 V1.04 2005-7-26 郝军增加机卡合一版本的命名规则 注:1)拟制、审核、会签、批准不走电子流程时,必须用钢笔或签字笔填写,不得用铅笔、圆珠笔填写。

产品研发流程管理制度汇编

产品研发管理制度 第一章总则 第一条产品研发过程的管理,指产品研发项目确定后,进行产品研发,形成可交付使用的软件产品的过程。在产品的研发过程中,做好研发流程的管理和控制,是确保产品研发质量和研发进度的关键。 第二条本流程制定的目的是为了对产品研发进行有效的组织实施,使产品研发处于受控状态,保证软件开发的最后成功,向用户提供高质量的软件产品。 第二章产品的需求分析管理 第三条需求的采集 采集的渠道分为市场反响、竞争对手分析、客户反馈、运营数据分析、公司内部的建议等方面。 第四条需求的分析及编制文档 采集到的需求经过深入了解和系统分析,通过跟用户的讨论验证,并形成产品需求文档,让开发、设计人员理解产品的概念,功能、特点及产品各个部分的逻辑。产品需求文档包括业务需求、用户需求、功能需求和非功能性的需求。 1、业务需求:反映客户对系统、产品高层次的目标要求,在项目定义与范围文档中予以说明。 2、用户需求:描述用户的目标,或用户要求系统必须要完成的任务,这在使用实例或方案脚本中予以说明。 3、功能需求:规定开发人员必须在产品中实现的软件功能,使用户利用这些功能来完成任务,从而满足了业务需求。 4、非功能性需求:描述软件产品为满足用户业务需求而必须具有的除功能需求以外的特性。包括系统的完整性(联机帮助、数据管理、用户管理、软件发布管理、在线升级等)、性能、可靠性、可维护性、可扩充性、适应性等。 工作责任人需求分析工程师 工作职责概述需求采集、用户调查、业务分析、系统分析、变更管 理、用户验证

工作关系客户、市场、公司内部员工 工作成果产品需求文档 第三章产品的可行性分析报告、原型及评审管理 第五条可行性分析报告 产品可行性分析报告的编制是为了明确产品项发立项之前的市场、技术、财务、生产等方面的可行性,论述为了实现产品研发目标而可能选择的各种方案、投资及效益分析、潜在的风险因素,论证所选定的方案的可行性。 可行性分析报告编制完成后,由公司技术战略委员会组织完成对产品可行性分析报告的可行性初审和复审,形成相关议决后报总经理审批。 第六条产品需求规格说明书 确定客户需求、根据产品需求文档形成产品需求规格说明书。用于保证软件开发的质量、需求的完整与可追溯性,通过产品需求规格说明书,以保证用户与需求分析人员、开发人员、测试人员及其它相关利益人对需求达成共识,确保产品需求的实现。 第七条产品原型 原型图是对流程图中“界面元素”的展现,将页面的模块、原素、人机交互的形式,利用线框描述的方法,将产品脱离皮肤状态下更加具像跟生动的进行表达。 工作责任人产品经理、产品助理 工作职责概述用户和市场分析、产品规划、产品需求管理、产品设计、推动产品研发进程、产品发布管理、产品宣传推广工作关系产品中心经理、需求分析工程师、研发中心、客户 工作成果产品可行性分析报告、产品需求规格说明书、产品原型设计 第四章产品的立项及评审管理 第七条产品立项报告书 产品立项报告书含以下内容:

软件版本管理规范标准[详]

软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容,使软件项目版本管理流程化并规化,确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库(可使用工具建立配置库,本文所述使用的是SVN)进行版本管理。 2.第三章职责 配置库管理员:负责配置库的日常维护和管理;监督开发及测试部门及时提交版本管理对象(即配置项)。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于: 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划

上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划: ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中,项目部的目录结构: |–projectA |–src (保存该项目的源程序) |–doc (保存项目相关文档) |–000.项目管理(保存项目过程管理相关文档) |–010.项目计划(保存项目计划相关文档) |–020.项目需求(保存项目需求相关文档) |–030.系统设计(保存项目设计相关文档) |–030.系统测试(保存项目代码测试相关文档) |–040.系统实施(保存项目部署实施相关文档) |–050.系统运维(保存项目运维文档,包括培训、用户手册等) |–060.技术资料(保存项目技术文档,包括第三方技术资料等)

软件配置管理规范.doc

软件配置管理规范1 1.简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分: 简介,包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分: 配置管理工作规范的正文,包括活动的流程图、进入能及退出的准则、所涉及的角色、相 关活动的阐述、验证与确认能及度量。 第三部分: 变更控制工作规范的正文,包括活动的流程图、进入能及退

出准则、所涉及的角色、相关 活动的阐述、验证与确认能及度量。 第四部分: 参考文献,列出了编写本规范所参考的相关的文献资料。 第五部分: 附录,本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项,包含文档、程序。 CR (Change Request) 变更请求,对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息 是有关当前问题、提议解决方案及其成本的起源和影响的信息。

PCA (Physical Configuration Audit) 物理审计,在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计,核心软件配置项的实际性能是否符合它的需求。 基线(Baseline) 己通过复审和批准的工件发布版,由此构成进一步演进或开发的公认基础,并且只能 通过正式程序,例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库,存储项目工件的所有版本,即存储项目的定义的配置项。 版本(Version) 某个工件的变体,工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1

项目软件版本号管理规范

项目软件版本号管理规范

历史修改记录 一. 目的

1.1软件版本按照一定的规则保存所有版本,避免发生版本丢失或混淆等现象, 并且可以快速准确的查找到任何版本。 1.2软件版本规范有利于公司各部门之间的对接工作,有利于公司内部资料统一 管理。 1.3本文档是为规范研发部软件版本管理而制定的。 二. 范围 2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容,包括:2.2版本标识方法及管理 2.3版本升级 2.4文档及源码的备份制度 2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作,公司内部使 用按照文档及源码存放备份制度。 三. 版本管理 3.1版本号规则 3.1.1每个归档版本都有两个版本号:内部版本号和外部版本号。版本号使用 VP规则,V(Version)是指外部版本号(研发测试版本),P(Patch)是指补丁版本号(可选)。 3.1.2版本号命名:V/B+主版本号+次版本号+修订版本号+日期版本号

3.2版本号修改规则 3.2.1主版本号:当功能模块有较大的变动,比如增加模块或是整体架构发生 变化。此版本号由项目决定是否修改。 3.2.2次版本号:相对于主版本号而言,次版本号的升级对应的只是局部的变 动,但该局部的变动造成程序和以前版本不能兼容,或者对该程序以前的协作关系产生了破坏,或者是功能上有大的改进或增强。此版本号由项目决定是否修改。 3.2.3修订版本号:一般是Bug 的修复或是一些小的变动或是一些功能的扩 充,要经常发布修订版,修复一个严重Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。 3.2.4日期版本号:用于记录修改项目的当前日期,每天对项目的修改都需要 更改日期版本号。此版本号由开发人员决定是否修改。 如: V8.1.0.XXX (上一级版本号有变动时,下级要归零) 3.3版本号修改举例说明 如此时版本号为:V8.1.0.XXX ,此时为内部测试阶段 3.3.1 开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug 之后,发布到外网时,此时就进入了软件的下一个阶段,版本号可改为: V8.1.1.XXXX ,如当前日期跟上一个版本号的日期不一样,版本号可改为: V8.1.1.XXX。

软件配置管理规范流程模板

软件配置管理规范 流程 1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件

的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工 作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。 每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再

研发工程部管理制度及流程

研发工程部管理制度及流程 1.目的和作用: 新产品开发是企业在激烈的技术竞争中赖以生存和发展的命脉,它对企业产品发展方向、产品优势、开拓新市场、提高经济效益等方面起着决定性作用。为了使新产品开发能够严格遵循科学管理程序进行,取得较好的效果,特制定本制度; 2.范围: 公司内工程部日常工作内容等各项流程的管理; 所包含的过程具体见如下章节: 2.1负责新产品的设计与开发,现有产品的改良; 2.2新产品工艺的贯彻与落实; 2.3产品材料的改良 2.4工艺文件的编制与核准 2.5生产中技术问题的解决; 2.6客户样品的跟踪,采购样品的确认 2.7 BOM表(产品零件结构表)的编制与管理 2.8 新材料供方的联系,新材料应用技术问题的改善 2.9新产品质量的跟踪 2.10协助品质部建立品质标准与计量标准化工作 2.11指导生产部做好机器、设备的保养与维护 2.12供方的评审 2.13特采作业的核准 2.14负责公司工程资料的制作,发放及存档 2.15负责样品的打样 2.16负责样板、夹具的图纸制作 2.17在整个开发阶段系统地衡量客户的满意度 3.权责: 权力 3.1有权参与公司生产政策的制定; 3.2有权参与公司产品开发战略的制定 3.3有权参与公司年度、季度、月度生产计划的制定,并提出意见和建议 3.4对违反操作工艺的行为和过失有实施处罚的权力 3.5部门内部员工考核的权利 3.6部门内部员工聘任、解雇的建议权 3.7其他上级授予的权力

责任 3.8对产品和技术开发计划完成负主要责任 3.9对技术保密负领导责任 3.10如因工作失职,给公司造成损失,应负相应的经济和行政责任。*岗位职责对照 *部门组织架构

软件版本管理规范19726

软件版本管理规范 第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容,使软件项目版本管理流程化并规范化,确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用范围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库(可使用工具建立配置库,本文所述使用的是SVN)进行版本管理。 2.第三章职责 配置库管理员:负责配置库的日常维护和管理;监督开发及测试部门及时提交版本管理对象(即配置项)。 此岗位可由开发或测试人员兼任。 3.第四章内容 4.1. 版本管理对象 包括但不限于: 项目总体计划 可行性研究报告 开发计划 需求说明书

需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划 上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。

配置库目录结构规划: ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中,项目内部的目录结构: |–projectA

软件配置管理规定

软件配置管理规定 为进一步加强软件配置管理工作,明确软件配置原则,规范软件配置流程,制定本规定。 一、配置原则 1.软件配置遵循安全性、适用性、经济性和正版化的原则,不得配置非正版软件。 2.单位使用的商业软件、OEM软件、免费软件均需纳入配置管理,不得配置与工作无关的各类软件。 3.优先采用场地授权(许可)方式配置软件。 二、配置流程 1.软件使用部门根据本部门各岗位工作需要,编制岗位软件需求清单,填写《软件使用需求申请表》(附件1)。 2.信息化部门统计、汇总软件使用部门报送的《软件使用需求申请表》,对软件使用部门需要的相关软件进行统一测试和试用,综合考虑软件的价格、兼容性、安全性和售后服务等因素,确定软件选型,明确软件名称和版本。涉及使用免费软件的,更新《可使用免费软件清单》(附件2)。 3.信息化部门依据单位软件使用管理台账,梳理单位软件需求与现有软件许可的差异。单位软件许可不足的,编制《软件采购计划表》(附件3)。

4.财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年限、兼容性和售后服务等要求。 5.财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作,重点是软件采购合同、软件授权证书、软件安装序列号等资料的管理工作。 6.信息化部门负责软件使用管理日常工作。 7.单位采购的软件,因以下情况申请报废的,需经过信息化部门鉴定,严格履行资产处置报批手续:(1)已经达到规定的最低使用年限,且无法继续使用的。 (2)未达到规定的最低使用年限,因技术进步等原因无法继续使用的。 (3)未达到规定的最低使用年限,因计算机硬件报废,且无法迁移到其他计算机上继续使用的。 8.信息化部门在单位新采购软件、报废软件和调整可使用免费软件清单后,更新《软件使用情况汇总表》(附件4)。

软件配置管理规范

软件配置管理规范 1.简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分: 简介,包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分: 配置管理工作规范的正文,包括活动的流程图、进入能及退出的准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第三部分: 变更控制工作规范的正文,包括活动的流程图、进入能及退出准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第四部分: 参考文献,列出了编写本规范所参考的相关的文献资料。 第五部分: 附录,本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项,包含文档、程序。 CR (Change Request) 变更请求,对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息是有关当前问题、提议解决方案及其成本的起源和影响的信息。 PCA (Physical Configuration Audit) 物理审计,在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计,核心软件配置项的实际性能是否符合它的需求。 基线 (Baseline) 己通过复审和批准的工件发布版,由此构成进一步演进或开发的公认基础,并且只能通过正式程序,例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库,存储项目工件的所有版本,即存储项目的定义的配置项。

软件版本管理规范标准

软件版本管理规 V1.0.0 文档版本变更记录:

目录 前言 (3) 1 围 (4) 2 术语和定义 (4) 2.1 软件 (4) 2.2 产品软件 (4) 2.3 演示软件 (4) 3 软件版本命名规则 (4) 3.1 软件版本命名组成 (4) 3.2 产品软件版本命名 (4) 3.3 演示软件版本命名 (5) 3.4 正式版本号的升级规则 (6) 3.4.1 软件版本升级规则 (6) 3.4.2 演示版本升级规则 (6) 3.5 版本的安装文件命名规则及存放路径 (6) 4 软件版本发布流程 (7) 5 管理条例 (7) 6 附录 (7)

前言 为规部门产品软件版本的管理与控制,保证产品版本的有效与质量,制定本标准。本标准由移动金融事业部拟制。 本标准于2015年6月首次发布。

软件版本管理规定 1围 本标准规定了移动银行事业部产品软件版本的控制与管理。 本标准适用于移动银行事业部产品软件版本的控制与管理。 2术语和定义 下列定义适用于本标准。 2.1软件 指与产品相关的所有软件,可以分为产品软件和演示软件。 2.2产品软件 已签订合同,有明确交付日期的产品。 2.3演示软件 处于研发阶段,并未正式投入生产的应用。 3软件版本命名规则 3.1软件版本命名组成 产品的正式软件版本命名由四部分组成。第一部分为主版本号,第二部分为次版本号,第三部分为修订版本号,第四部分为日期版本号。 产品的演示版本命名由四部分组成。第一部分为主版本号,第二部分为次版本号,第三部分为修订版本号,第四部分为日期版本号。 3.2产品软件版本命名 产品软件版本的命名规则如下所示:

软件配置管理规范标准

页眉 软件配置管理规范 1.简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分: 简介,包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分: 配置管理工作规范的正文,包括活动的流程图、进入能及退出的准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第三部分: 变更控制工作规范的正文,包括活动的流程图、进入能及退出准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第四部分: 参考文献,列出了编写本规范所参考的相关的文献资料。 第五部分: 附录,本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项,包含文档、程序。 CR (Change Request) 变更请求,对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息是有关当前问题、提议解决方案及其成本的起源和影响的信息。 PCA (Physical Configuration Audit) 物理审计,在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计,核心软件配置项的实际性能是否符合它的需求。 基线(Baseline)

己通过复审和批准的工件发布版,由此构成进一步演进或开发的公认基础,并且只能通过正式程序,例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库,存储项目工件的所有版本,即存储项目的定义的配置项。 版本(Version) 页脚 页眉 某个工件的变体,工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1 1.5.2 方针 SWL开发组项目开发与管理工作方针 1.5.3 过程/规范 项目计划与控制规范 1.5.4 指南 配置管理计划指南 基线策略指南 配置状态报告编制指南 配置审计工作活动指南 配置管理工具指南 VSS 使用指南 组织管理配置库使用指南 软件开发文档命名约定 1.5.5模板 配置管理计划 配置状态报告 配置审计报告 文档变更请求 1.5.6 检查表 无 1.5.7 培训 《软件配置管理教材》 《软件变更控制管理教材》 《Clear Case 配置管理培训教材》 1.5.7 工具 Clear Case Visual SourceSafe Visual Basic Office 97/2000/XP DreamWeaver PhotoShop

软件配置管理流程

软件配置管理流程

目录 1.配置管理流程 (3) 1.1 概述 (3) 1.2 总体流程图 (3) 1.3 软件需求分析阶段 (4) 1.4 软件设计阶段 (4) 1.5 制定配置管理计划 (4) 1.6 配置库管理 (4) 1.6.1 相关人员分配权限 (4) 1.6.2 配置项 (5) 1.7 版本控制 (6) 1.8 变更控制 (6) 1.9 配置审计 (7) 1.9.1 配置审核的类别 (7) 1.9.2 配置审核执行的时机 (7) 1.9.3 不符合项的处理 (7) 2.0.0 配置状态报告 (7) 2.0.1 配置状态报告的目的 (7) 2.0.2 配置状态报告记录的内容 (7) 2.0.3 配置状态报告的生成 (7) 2.1.0 发行管理 (8) 2.1.1 交付管理 (8) 2.1.1 软件配置管理员的处理规范 (8) 2.1.1.1 现阶段使用的版本配置服务器 (8) 2.1.1.2 主要操作流程 (8) 2.1.1.3 版本规范化处理 (8) 2.1.1.4 客户反馈问题处理 (8) 2.软件基线化规范 (9) 2.1 正常开发期 (9) 2.2 版本发布期 (9) 2.3 项目发布期 (9) 2.4 项目维护期 (9)

1.配置管理流程 概述 规范配置管理活动,明确配置项正确的唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 总体流程图

软件需求分析阶段 参加需求分析会议,配置管理负责人记录,有关文档提交归档。如《需求分析》。 软件设计阶段 参加涉及阶段,为了详细制定配置管理计划。针对需求分析报告进行系统设计,配置时应说明系统设计的版本于需求分析报告版本的对应关系。设计书评审通过后,建立设计基线。 制定配置管理计划 配置管理员制定配置管理计划,主要内容包括配置管理软硬件资源、配置项计划、备份计划等,审批该计划。 配置库管理 配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 相关人员分配权限 项目经理: 1)与(有关负责人员)协商确定项目起始基线; 2)接受配置管理计划,并按相关规定贯彻执行; 3)接受配置控制委员会的报告; 4)提出配置管理计划的修改要求; 5)提出管理的建议和要求。 配置管理员 1)编制配置管理计划; 2)执行配置项管理; 3)执行版本控制和变更控制方案; 4)编制配置状态报告; 5)配置库的建立和权限分配; 6)配置管理工具的日常管理与维护; 7)配置库的日常操作和维护; 开发人员 1)根据确定的配置管理计划和相关规定,提交配置项

(完整版)技术部软件版本管理规范

技术部软件版本规范 文档建立/修改记录: 版本管理规范 【新建项目版本管理部分】 1,项目组接到项目需求, 1.1,开发组出项目设计和开发计划; 1.2,测试在Git中建立空项目(项目名称开会时候会有,没有需要问),形成master版本,版本设定为V0.0.0。 2,组长发邮件给技术总监,并且抄送给项目经理和测试。 邮件内容:开发计划文档url和开发版本号(V0.1.0),请批准第一阶段(开发计划中会包含)开发。 3,得到批准开发回复后,测试从master(V0.0.0)建立分支版本(V0.1.0),打开版本参与人员的更新权限,并且将url给组长。 4,组长download项目,上传项目可运行框架,并且更新GIT中的readme文档并通知开发;5,开发者必须按时按功能点来提交(提交时需写相应描述)项目到GIT中,并且push前必须测试,保证代码不能有运行异常,导致无法测试 5.1,Push结束后,开发者继续开发下一个功能点。 5.2,push结束会自动化构建,自动化构建完成后系统会自动通知测试人员进行测试,测试人员需先关闭版本参与人员的更新权限,再按功能点来测试bug,然后更新bug文档和测试用例文档的内容(有无bug都需要更新),随即打开更新权限并通知组长。 6,开发者下一个功能点提交时,同上要求。 7,第一阶段最后一个功能点提交完毕后,测试者关闭此版本参与者更新权限,然后将此版本(V0.1.0)建分支版本(V0.1.1)并且给出版本url给组长,继续进行测试最后一个功能点bug。8,组长通知组员进行bug(bug一般会比较少,bug很多只能说明开发者开发质量有问题)修改,给出修改版本地址。 9,修改完毕后提交,测试人员再次关权限且测试,如仍然有bug存在,更新相应文档并在相关修改支版本(这里是V0.1.1)中再次建立修改版本(此时是V0.1.2),随即给出版本url给组长。ps:提交版本如有冲突找组长调节。 10,第一阶段开发完全完成后开始开发第二阶段任务,重复2~9步骤,相应的版本号会变为从V0.2.0开始,同里修改版本号则是V0.2.1/V0.2.2/V0.2.3...... 11,当全部阶段任务完成(指的是开发完成并测试无bug),测试将最新的修改完成的版本(应该是V0.x.x,x为任意数字)合并到master版本中,此时版本号设定为V1.0.0。测试发邮件给

相关文档
最新文档