软件版本管理办法

软件版本管理办法
软件版本管理办法

信息系统软件版本管理办法

第一章总则

第一条为加强软件版本管理,规范软件版本管理工作流程,提高版本运行维护质量,保证信息系统安全可靠高效地运行,特制定本办法。

第二条本办法涉及的软件包括在线运行的软件和拟投产的软件。软件版本管理对象包括应用软件版本以及相关操作系统、数据库、中间件等基础软件。

第三条软件版本管理是信息系统开发管理和日常维护管理工作的一个重要组成部分,本办法作为软件版本管理的重要依据,软件版本管理归口管理部门、业务支撑部门、风险管理部门、内审部门及各软件供应商要认真履行各自职责,严格执行软件版本管理的各项流程和规定,保障信息系统的安全稳定运行。

第四条任何未经版本归口管理部门许可的软件版本不允许在生产环境使用。在商务合同中若涉及信息系统软件版本,应确认为版本归口管理部门允许使用的软件版本。因使用未经许可的软件版本而造成系统故障影响正常业务交易,相关部门及各厂商要承担相应的责任。

第五条本办法由信息技术部负责解释和修订,自发文之日起开始执行。

第二章组织与职责

第六条软件版本管理实行总行集中管理体系。

第七条信息技术部是信息系统软件版本的归口管理部门。

第八条稽核监控部是信息系统软件版本管理的内审部门。

第九条风险管理部是信息系统软件版本管理的风险控制部门。

第十条信息系统软件版本管理工作还涉及软件提供商,软件提供商包括软件最终提供商、代理商和维保服务商(以下简称厂商)。

第一节归口管理部门职责

第十一条归口管理部门负责制定和完善的软件版本管理办法。

第十二条归口管理部门负责制定信息系统软件版本管理工作的工作计划、工作要求和技术规范,并组织实施。

第十三条归口管理部门负责审批业务支撑部门上报的版本变更申请,组织进行资料审核和上线测试,安排试运行工作及全行推广实施。

第十四条归口管理部门负责建立软件版本信息库,发布软件版本管理各类信息;建立版本预警体系,发布软件版本缺陷信息和版本预警信息。

第十五条归口管理部门负责与业务支撑部门、风险管理部门、内审部门、厂商协调信息系统软件版本管理的相关工作。

第三节业务支撑部门职责

第十六条版本管理业务支撑部门负责业务类需求的日常收集和集中收集。

第十七条版本管理业务支撑部门负责发起新版本的试运行申请。

第十八条版本管理业务支撑部门负责协助归口管理部门审核新版本发布资料(包括申请、厂家及仿真环境测试报告、版本说明文档、升级方案、测试方案等),并协助归口管理部门开展新版本试运行测试工作。

第十九条版本管理业务支撑部门负责自查并督促其下属机构履行职责,严格执行版本管理相关制度和流程。

第四节风险管理部门职责

第二十条版本管理风险管理部门负责重大版本发布前的风险评估。

第五节内审部门职责

第二十一条版本管理内审部门负责监督和检查版本管理归口管理部门、业务支撑部门、风险管理部门和厂商是否严格执行版本管理的相关制度与流程。

第五节厂商义务

第二十二条信息系统厂商应严格遵守软件版本管理的规章制度、技术规范。

第二十三条信息系统厂商应根据业务发展及运行维护的需要及时更新版本,保证在线运行的软件版本是允许使用的版本。

第二十四条信息系统厂商应配合软件版本归口管理部门进行软件仿真测试,及时提供各类运行维护及仿真测试所需的文件资料和技术咨询,并对这些材料的真实性、可靠性和实时性负责。在不具备相应仿真测试环境的情况下,厂商有义务提供仿真环境配合开展测试。

第二十五条信息系统厂商应配合进行试运行工作。厂商应根据版本变更情况选择能够测试所有升级功能点的分支机构,并结合用户量、安全性等的要求向提出试验点建议。

第二十六条信息系统厂商应配合做好信息系统软件版本管理工作,建立本厂家信息系统软件版本管理资料库信息,协助软件版本归口管理部门做好版本预警信息的发布与管理,提供必要的技术资料和技术支持。

第二十七条信息系统厂商应指定专门的版本管理联系人与软件版本归口管理部门衔接,以便配合进行软件的升级实施和及时跟踪处理升级过程中或者升级后出现的各种故障。第二十八条信息系统厂商有义务在升级过程中按照的要求配合完成各项工作,包括协助软件版本归口管理部门模拟重现升级或试运行期间出现的和软件版本相关的故障。

第二十九条信息系统厂商有义务在工程招标书中,承诺按照版本管理相关制度和流程履行投标方的义务。

第三章版本管理内容与流程

第三十条信息系统软件版本分为版本和补丁。版本是指软件系统中的核心部分发生结构性变化、应用部分新增若干功能而生成的软件版本。补丁是指软件系统中不涉及核心部分的变化,只是应用部分的故障修复或功能完善而生成的软件版本。

第三十一条版本管理的各项工作必须按照规定的操作流程执行,各相关部门应认真履行本部门的职责,做好部门之间的衔接和协调。

第三十二条版本管理工作内容主要包括需求管理、认证管理、变更管理、评估管理和信息管理。其中,需求管理是通过收集、整理和分析版本的新特性需求或未修复缺陷,引导厂家新版本开发,确定待认证的版本;认证管理是依据技术规范,对厂家待认证版本的符合性和可用性进行认证,并对已认证版本进行更新或废止管理;变更管理是对生产运行版本变更的技术审核和流程管控;评估管理是对生产运行版本的版本能力、缺陷等方面的评价和管理;信息管理是对全行软件版本信息及版本管理工作各环节输出信息的动态管理,主要包括信息的收集、整合、关联、更新、价值挖掘和全行共享,是版本管理各项工作的基础。

第一节需求管理

第三十三条版本需求管理主要分为业务类需求管理和运行维护类需求管理两大类,两大类需求的特点如下:

(一)业务类需求:包括对原有业务模型、业务流程进行变更完善的需求,对新业务模式、

新业务功能的支撑需求以及与业务推广能力相关的需求等;

(二)运行维护类需求:包括运维监控类需求、系统软件版本缺陷和问题解决需求等与运行

维护工作直接相关的需求;

第三十四条运行维护类需求由信息技术部系统运行中心(以下简称运行中心)牵头收集整理,业务类需求由信息技术部系统开发中心(以下简称开发中心)牵头收集整理,最终由软件版本归口管理部门负责进行统一梳理后落实到建设项目中,组织技术规范的修订。

第三十五条需求收集分为两种:日常收集和集中征集。

(一)日常收集:业务类需求由需求提交部门发起,开发中心收集整理,运行维护类需求由

运行中心不定期向综合部提交新需求并填写《软件版本需求汇总表》(见)作为附件。

(二)集中征集:在专项治理工作中,由专项治理工作归口管理部门发起、在规定时期内征

集各方需求,然后统一汇总整理,向需求归口管理部门提交新需求并填写《软件版本需求汇总表》(见)作为附件。

第二节认证管理

第三十六条软件新版本的认证过程包括仿真环境测试和生产环境试运行测试。

第三十七条仿真环境测试主要测试内容包括:版本差异化测试(新增功能测试、功能变更测试、故障修复有效性测试)、新版本回归性验证测试(即原有功能点的测试)、新版本的升级过程测试、性能测试、业务功能测试等。由厂商自行组织的内部测试也应涵盖上述测试内容。

第三十八条原则上,业务类需求导致的新软件版本由信息技术部开发中心组织进行仿真

环境测试;运行维护类需求导致的新软件版本由信息技术部运行中心组织进行仿真环境测试。如果新版本包含以上两方面的需求,则由软件版本归口管理部门统一组织新版本的仿真环境测试。新版软件正式开始测试前,厂商应向上述部门提交相关技术资料和说明书。说明书中应包含以下内容:

(一)软件版本变更的原因及必要性,新版软件与旧版软件的差异性说明、新增功能说

明、新版软件对硬件环境的要求、涉及第三方的软件版本说明;

(二)维护手册及有关资料变更部分;

(三)新版软件对所在平台及所承载业务的影响以及对相连的系统的影响以及相关接

口(包括第三方接口)变化的说明文档;

(四)新版本的历史应用情况,已知缺陷、隐患或与需求(含商务需求、设计需求、业

务需求、运维需求等)不符之处并列出解决方案;

(五)对新版软件进行测试的测试方案,包括测试所用的软硬件环境、测试项目及具体

测试方法步骤、测试环境要求及预期结果;

(六)详细的升级方案及针对各种异常情况的应急预案,升级失败的应急回退方案等;

(七)厂商内部测试情况报告。

第三十九条对于信息系统软件新版本的仿真环境测试原则上应在提供的仿真环境中进行,对不具备测试条件的,厂商须提供相应的仿真环境。厂商应在测试前,配合进行仿真环境的准备工作。仿真环境应能对版本进行尽量完整的测试。

第四十条对于仿真环境下无法测试的测试用例,经归口管理部门审核后可在试运行阶段再进行测试。

第四十一条因版本质量问题导致不能完成测试或测试报告结论为不通过的,需由厂商修改问题后重新测试。测试完成后测试单位应向软件版本归口管理部门提交新版本的测试报告《XX系统XX版本测试报告》(见)。测试报告文档应包含内容:

(一)测试原因

(二)测试环境拓扑图

(三)测试所需软硬件及其他工具(可选)

(四)基本连接和配置(可选)

(五)测试项目及具体测试方案

(六)测试结论(包含测试情况如何,该版本功能是否完善,是否符合申请内容以及升

级建议等)

第四十二条对于测试中不满足要求的项目,厂商应给出相应的改进承诺和时间表。

第四十三条完成版本测试后,业务支撑部门应向软件版本归口管理部门提出试运行建议申请,并填写《XX系统XX版本试运行建议表》(详见附表四),由软件版本归口管理部门发布新版本的试运行通知。

第四十四条信息系统的试运行升级申请应至少在升级日期前七个工作日提交到软件版本归口管理部门,软件版本归口管理部门在收到升级申请后的四个工作日内完成批复,试

运行准备时间不少于三个工作日。在紧急情况下,试运行申请至少提前四个工作日提交到软件版本归口管理部门,软件版本归口管理部门在收到申请后两个工作日内完成批复,试运行准备时间不少于两个工作日。升级方案所需要的内容具体参见。

第四十五条软件版本归口管理部门组织审核测试报告、升级方案及试运行资料,并填写《XX系统XX版本试运行资料审核报告》(详见)。

第四十六条重大版本变更厂商在试运行升级时应派专人在现场给予技术支撑,协助定位解决问题。

第四十七条软件版本归口管理部门负责组织开展试运行工作,密切关注新版本的运行情况,业务支撑部门应按照试运行测试要求和用例进行完整测试,及时填报测试结果。原则上,试运行时间应不少于三个月。试运行结束后,提交《XX系统XX版本试运行报告》(详见)。

第四十八条试运行测试完成、确认新版本安全稳定后,由信息技术部在运维管理系统发布新版本相关信息。

第四十九条在新版本运行期间若出现涉及危害平台安全、影响业务运行、对客户感知造成重大影响的问题,由业务支撑部门填写《XX系统XX版本软件变更申请表》(见),软件版本归口管理部门在两个工作日内审核回复,组织厂商、信息技术部执行版本回退或修复工作。

第五十条厂商应在版本升级后五个工作日内提交版本升级故障分析报告。

第五十一条厂商用于投标的软件版本以及新工程中使用的软件版本,均需由厂商向软件

版本归口管理部门提出新版本测试申请,按本节管理要求开展测试认证。软件版本归口管理部门和总行验收领导小组应在工程验收时对其使用的软件版本进行检查、把关,确认工程项目中所使用的软件版本是经过测试认证的。

第三节变更管理

第五十二条版本变更主要指版本和补丁的投入与使用,管理工作主要包括版本升级、补丁输入的申请与审批、版本升级方案(含应急措施、测试用例等)的制定与审批、升级成功后的资料移交和更新等。

第五十三条软件版本升级按发起方不同分为两种:

(一)软件版本归口管理部门安排布置的版本升级任务,主要是为了满足总行提出的对全行

信息系统的基础建设或维护的需求;

(二)业务支撑部门主动提交的版本升级申请(《XX系统软件变更申请表》(见)),主要是

为了满足某个业务需求。

第五十四条为了保证平台安全稳定运行,原则上每种平台每月升级次数不超过一次,承载不同业务的平台不安排在同一时间升级;

第五十五条软件版本归口管理部门发布批准使用新版本的信息后,总行各业务部室或分支机构可以根据实际情况更换新版本。

第五十六条升级方案包含但不限于以下内容:

(一)升级目的

(二)升级内容

(三)各方工作人员职责

(四)升级各步骤的时间估算

(五)升级涉及范围及对业务的影响

(六)具体升级步骤

1.升级准备工作及注意事项

2.升级操作详细步骤

3.升级应急预案和应急预案启动条件

4.业务测试用例

(七)升级完成核对的内容及步骤

(八)备品、备件的升级(升级时间、地点、方式)

(九)运行观察

(十)资料归档

第五十七条升级过程中间出现升级方案中未预料到的业务中断或中断时间超出预定时间等异常情况时,软件升级工作应立即停止,按照升级方案中的应急预案进行操作,并逐级上报。

第五十八条在升级结束后业务支撑部门将升级完成情况汇总,填写《XX系统XX版本使用情况汇总表》(见),在升级完成一周后上报软件版本归口管理部门备案。

第五十九条升级结束后,厂商必须向移交:

(一)各级用户密码;

(二)监控和应用软件的安装程序(必须经过测试);

(三)设备的详细配置资料;

(四)设备维护手册的追加与变更。

第四节评估管理

第六十条评估管理是对生产环境运行版本的评估,主要包括版本能力、版本缺陷和预警等的管理和评价。版本评估结果是对已认证版本进行更新或废止的重要依据。

第六十一条版本变更后,软件版本归口管理部门需跟踪新版本的使用情况,组织版本运行评估工作,对新版本满足业务功能、运行维护管理等需求的能力进行评估。如果新版本能力不足、且认证库中已存在满足需求的版本,则可将此已认证版本作为目标版本适时实施版本变更;如果新版本能力不足、且认证库中不存在满足需求的版本,则将关于新版本使用中所出现问题的评估结果提交版本管理归口管理部门。软件版本归口管理部门对评估结果进行分析,对于当前暂不需要解决的版本遗留问题进行汇总;否则输出至需求归口管理部门进行处理。

第六十二条预警定义:预先对因设备软硬件版本缺陷而可能导致业务系统或设备(含在

线设备和拟投产运行的设备)不能正常运行的因素进行警示并防范。版本缺陷的预警管理是保证在线安全、稳定运行的重要措施之一。

第六十三条软件版本归口管理部门根据全行在线版本的业务和维护支撑能力、缺陷发生数量及影响、版本变更次数及原因、上线时间等因素,于每年12月20日之前提交年度版本运行评估报告。

第五节信息管理

第六十四条建立软件版本信息管理体系,实现全行软件版本信息及版本管理工作各环节输出信息的收集、整合、关联、共享、价值挖掘和动态管理。

第六十五条软件版本归口管理部门按照统一的版本信息模型,每月初通过运维管理系统提交“全行软件版本使用情况汇总表”(见)并对汇总信息进行入库和维护更新管理。第六十六条软件版本归口管理部门及时发布版本信息,以便各分支机构和总行各业务部室正确选择使用的版本。各相关单位负责收集、整理、分析辖区内软件版本相关信息,并进行及时更新。版本信息库上包括但不限于以下所示:

(一)各厂商的软件版本的状况,包括:版本编号、功能变更说明书、上线测试报告、核准

上线日期等。

(二)各厂商的软件版本在生产环境中的运行情况,包括:投入运行时间、版本分布情况、

主要设备配置、版本的问题等。

(三)版本问题登记,包括:软件版本、问题发生时间、原因、现象、影响、排除方法、排

除时间及善后处理意见等。

(四)其它相关资料,包括:技术标准、企业规范、新业务、新功能的需求汇总、论文资料

等。

第六节版本管理流程

第四章监督与检查

第六十七条版本管理内审部门将适时组织检查信息系统的软件版本管理工作情况,并及时通报检查结果;结合本年度全行在线版本管理各项工作情况,于每年底发布全行年度在线版本管理工作情况通报。对于因版本管理不善或使用未经许可的软硬件版本而造成的业务中断故障、用户投诉及经济损失等,内审部门将视具体情况对相关部门、负责人或直接责任人给予通报批评,并反映在部门考核指标中。

第六十八条归口管理部门在进行“外包商服务质量评估”时,应将厂家软件版本运行评估情况及对版本管理工作的支撑情况作为评估内容之一,并将评估结果作为采购评标的重要考虑因素;在维保合同中应增加版本管理工作相关要求的条款,并进行相关考核;对于因厂家原因造成的业务中断故障及由此产生的损失,将视具体情况对相关厂家给予处罚并追究相关责任。

附表一:XX业务软件需求汇总表

附表二:软件版本测试申请表

附表三:XX系统XX版本/补丁测试报告

XX系统软件版本/补丁测试报告

1.测试概况

测试目的

2.测试环境

网络结构图

3.测试内容

对测试情况的描述

4.测试结论

测试通过或测试不通过,测试不通过请说明原因。附表四:XX业务XX版本试运行建议表

公司软件管理规范

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软件申请、开发、使用管理流程图:(如下图)

软件版本管理制度方案.doc

软件版本管理制度.1 软件版本管理规范 系统软件开发部 2011-9-20 目录 1引言(3) 1.1目的(3) 1.2范围(3) 1.3术语定义(3) 1.4版序控制记录(4) 1.5版本更新记录(4) 2版本管理(4) 2.1流程图(4) 2.2版本命名(9) 2.3版本升级(10) 2.3.1版本升级原则(10) 2.3.2新版本的发布(11)

2.4目录结构(11) 2.5文档的存放(12) 2.5.1文本文件的存放(12) 2.5.2源代码的存放(12) 2.5.3发行文档的存放(12) 2.6权限控制管理(12) 3备份管理(13) 3.1源文件备份(13) 3.2库文件备份(13) 4用户版本管理(13) 5版本工具的使用(14) 5.1配置管理工具(14) 5.2CVS的使用(14) 5.2.1常用命令(14) 5.2.2简单操作(17) 5.2.3版本分支管理(17) 1引言

本文档是为规范XXXXXX有限公司软件版本管理而制定的。 1.2 范围 本文档为系统软件开发部版本管理员提供有关版本管理规范的相关内容,包括: ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3 术语定义 CVS CVS是一个开源的版本控制系统Concurrent Versions System的简称 文档 一种数据媒体和其上所记录的数据。 配置管理 标识和确定系统中配置项的过程,在系统整个生存周期内控制这些项的投放和更动,记录并报告配置的状态和更动要求,验证配置项的完整性和正确性。

软件的具体形态在某时刻的瞬时影像。 配置项 软件配置管理的对象称为配置项,如:系统规格说明书,项目开发计划,用户手册,源码。 基线 软件生存周期中各开发阶段末尾的标记,它的作用是把各阶段工作的划分更加明确化,使本来连续的工作在这些点上断开,使之便于检验和肯定阶段成果。 1.4 版序控制记录 1.5 版本更新记录 2版本管理2.1 流程图 2.1.1文档归档流程 2.1.2文档变更流程

SPC统计过程控制实施规范2019

★★★ 质量管理实践 五大工具实施系列之 SPC统计过程控制实施规范 2019-12-23 编制: 周小东 本规范符合最新IATF16949 2016标准要求; 本规范引导企业如何正确实施SPC统计过程控制分析作业。

1.目的 通过实施统计过程控制,评估产品要求的符合性、过程和产品的特性及趋势、供方产品、过程能力是否达到规定要求,以便及时采取对策预防质量不良的发生,同时寻找改进的机会。 2.范围 本规定适用本公司所有的零部件产品的所有过程。 3.术语与定义 3.1工序能力:指工序处于受控状态或稳定状态下在加工精度方面的实际 能力,过程能力体现了过程稳定地实现加工质量的范围。 3.2工序处于受控状态或稳定状态:指工序的分布状态不随时间的变化而 变化。 3.3 工序加工能力:指工序质量特性的分散(或波动)有多大。 3.4 工序能力指数:即(CP&CPK),产品的公差与工序能力的比较指标值, 它表示该工序能力对产品设计质量要求的保证程度。 3.5 CMK:Machine Capability Index的缩写,称为设备能力指数。 3.6 PPK:Process Performance Index的缩写,过程性能指数。 3.7 CPK:Complex Process Capability index 的缩写,过程能力指数(调 整修正工序能力指数)。 3.8 SPC:Statistical Process Control是一种借助数理统计方法的过 程控制工具。它对生产过程进行分析评价,根据反馈信息及时发现系统性因素出现的征兆,并采取措施消除其影响,使过程维持在仅受随机性因素影响的受控状态,以达到控制质量的目的。 4.引用标准条款

软件版本管理制度

软件版本管理规范 系统软件开发部 2011-9-20 目录 1引言............................................................. 目的.......................................................... 范围.......................................................... 术语定义...................................................... 版序控制记录.................................................. 版本更新记录.................................................. 2版本管理......................................................... 流程图........................................................ 版本命名...................................................... 版本升级...................................................... 版本升级原则............................................... 新版本的发布............................................... 目录结构...................................................... 文档的存放.................................................... 文本文件的存放............................................. 源代码的存放............................................... 发行文档的存放................................ 错误!未定义书签。

统计过程控制

第一章 SPC简介 第一节什么是SPC 一、 定义:SPC是英文Statistical Process Control的字首缩写,即统计 过程控制。SPC就是应用统计技术对过程中的各个阶段进行监控,从而达到改进与保证质量的目的。SPC强调全过程的预防。 二、 SPC的特点: 1)SPC是全系统的,全过程的,要求全员参与,人人有责; 2)SPC强调用科学方法(主要是统计技术,尤其是控制图)来保证全过程的预防; 3)SPC不仅用于生产过程,而且可用于服务过程和一切管理过程。 三、 为什么要推行SPC? 优质企业平均有73%(用SPC方法的)的过程Cpk超过1.33,低质企业只有45%过程达到Cpk=1.33。Cpk>1.67的企业,平均销售收入增长率为11%以上,而其它企业的数据为4.4%。一家企业用了三年的时间使废品率降低58%,其使用的方法:将使用SPC的过程比例由52%增加到68%。 1)时代的要求:PPM管理、6σ管理; 2)科学的要求; 3)认证的要求; 4)外贸的要求。 四、推行SPC的目标 A.达到统计受控状态; B.维持统计受控状态; C.改进过程能力。

第二节 SPC发展简史 过程控制的概念与实施监控的方法早在20世纪20年代就由美国的休哈特(W.A.Shewhart)提出。今天的SPC与当年休哈特的方法并无根本的区别。 SPC迄今为止经历了三个发展阶段,即:SPC,SPCD及SPCDA。 1)第一阶段为SPC:SPC是美国休哈特在20世纪二、三十年代所创造的理论,它科学地区分出生产过程中产品质量的偶然波 动与异常波动,从而对过程的异常及时告警,以便采取措施, 消除异常,恢复过程的稳定。这就是所谓统计过程控制; 2)第二阶段为SPCD:SPCD是英文Statistical Process Control and Diagnosis的缩写,即统计过程控制与诊断。SPCD是SPC的进 一步发展,1982年我国张公绪首创两种质量诊断理论,突破了 传统的美国休哈特质量控制理论,开辟了统计质量诊断的新方 向。目前SPCD已进入实用性阶段; 3)第三阶段为SPCDA:SPCDA是英文Statistical Process Control,Diagnosis and Adjustment的缩写,即统计过程控制、诊断与调 整。这方面国外刚刚起步,他们称为ASPC(Algorithmic Statistical Process Control,算法的统计过程控制),目前尚无实 用性的成果。

软件版本管理规定

上海精佑通信技术有限公司企业标准 (管理标准) 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)拟制、审核、会签、批准不走电子流程时,必须用钢笔或签字笔填写,不得用铅笔、圆珠笔填写。

SPC统计过程控制管理办法

w 本手册所描述操纵图的选用程序 否 是 是 是是 是

注:本图假设测量系统差不多过 是 是 是 否否

评价同时是适用的 第Ⅰ章 持续改进及统计过程操纵概述 在今天的经济气候下,为了事业昌盛,我们——汽车制造商,供方及销售商必须致力于不断改进。我们必须查找更有效的方法来提供产品及服务。这些产品和服务必须不断地在价值上得以改进。我们必须重视内部以及外部的顾客,并将顾客中意作为企业的要紧目标。 为了达到这一目标,我们组织中的每一个人都必须确保不断改进及使用有效的方法。本手册涉及到第二个领域的某些要求。它描述了能使我们致力于的改进更有效的几种差不多的统计方法。为了完成不同的任务需要不同程度的理解。本手册的对象是见习生以及刚开始从事统计法应用的治理人员。关于现在正在应用更先进技术的人员,本手册也可作为他们学习这些差不多方法的参考文献。本手册并没有包括所有的差不多方法。附录H 所列的参考文献或手册中阐述了其他的差不多方法(例如:检查清单、 流程图、是

排列图、因果分析图等)及一些先进的方法(如其他操纵图、试验设计、质量功能展开等)。 本书所述的差不多统计方法包括与统计过程操纵及过程能力分析有关的方法。本手册的第1章阐述了过程操纵的背景知识,解释了一些重要的概念:如变差的专门及一般缘故,并介绍了操纵图,那个用来分析及监控过程特不有效的工具。第Ⅱ章描述了构 造和使用计量型数据操纵图表(定量的数据,或测量)的 - X —R , - X —s 图,中位数图以及X —MR(单值及移动极差)图。这一章还介绍了过程能力的概念并讨论了广泛应用的指数及比值。第Ⅲ章介绍了用于计数型数据(定性数据或计数值)的几种操纵图:p 图、np 图及u 图。第Ⅳ 章介绍了测量系统分析的内容并列举了适当的例子。附录包括分组及过度调整的例子,如何使用操纵图的流程图、常数及公式表、标准正态分布以及可复制的空白表等。术语索引给出了本手册所使用的术语及符号的解释,参考文献一节向读者提供了进一步学习的材料。 在开始讨论之前,需进行六点讲明: 1.收集数据并用统计方法来解释它们并不是最终目标,最终目标应是对读者的过程不断加深理解。当—个没有任何改进的技术专家是专门容易的。增加知识应成为行动的基础; 2.研究变差和应用统计知识来改进性能的差不多概念适用于任何领域,能够 是在车间中或办公室里。例子有:机器(性能特性)、记帐(差错率)、总销售额、白费分析(废品率)、计算机系统(性能特性)及材料治理(运送时刻)。本手册重点放在车间应用中。鼓舞读者参考附录H

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

软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容,使软件项目版本管理流程化并规化,确保在系统开发和实施过程中项目的完整性和一致性。 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.技术资料(保存项目技术文档,包括第三方技术资料等)

项目软件版本号管理规范

项目软件版本号管理规范

历史修改记录 一. 目的

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。

生产过程中的统计过程控制(SPC)

生产过程中的统计过程控制(SPC) 随着市场竞争的日益激烈,企业对产品质量提出了更高的要求,特别在全球一体化经济背景下,企业要想加入全球产业链之中,就必须按照国际统一的质量管理标准和方法进行质量管理。近年来,越来越多的国内企业意识到这一点,纷纷通过了ISO9000、ISO/TS16949等质量管理认证。国际标准化组织(ISO)也将SPC作为ISO9000族质量体系改进的重要内容,ISO/TS16949认证也将SPC列为一项重要指标,IRIS认证同样将SPC列为一项重要指标。 天行健咨询了解到,世界许多大公司不仅自身采用SPC,而且要求供应商也必须采用SPC控制质量,SPC业已成为企业质量管理必不可少的工具和质量保证手段,也是利用高新技术改造传统企业的重要内容。 一、SPC具体作用 1、提高产品合格率,降低生产成本,提高企业效益; 2、降低产品售后服务费用,包括因质量原因引发的退货、换货、修理; 3、实时监控企业质量管理过程,全面掌握质量动态,及时发现质量变异; 4、多种控制图提供质量变异分析方法,提供质量管理决策支持,使质量管理者能找出真正使质量变异的原因,有助于企业持续改善质量;

5、获得采购商对质量管理的认可,从而获得更多客户; 6、提升现代管理及信息化建设水平,改善企业形象。 二、过程能力分析 1、技术原理 统计过程控制是一种借助数理统计方法的过程控制工具。它认为,当过程仅受随机因素影响时,过程处于统计控制状态(简称受控状态),当过程中存在系统因素的影响时,过程处于统计失控状态(简称失控状态)。由于过程波动具有统计规律性,当过程受控时,过程特性一般服从稳定的随机分布;而失控时,过程分布将发生改变。SPC正是利用过程波动的统计规律性对过程进行分析控制。因而,它强调过程在受控和有能力的状态下运行,从而使产品和服务稳定地满足顾客的要求。 2、关键技术指标 过程能力(简称PC)是指过程质量方面的能力。这种能力表现在过程稳定(受控)的程度上,用过程能力指数Cpk表征。Cpk计算步骤如下:T的大小是标准要求,往往是根据顾客的要求确定的,一般是不变的,因而过程能力指数Cpk主要取决于标准偏差越小,Cpk越大。 三、过程能力不足的具体原因分析 1、从设备、工装方面分析:首先对设备的各种参数进行了评估,尤其对设备的各种重要参数进行了分析,初步判断各种参数可能对设备稳定性的影响程度。 2、从人员的作业方法分析,通过对作业人员作业方法的确认,作业时完全按照工艺卡片的要求执行,所以出现的过程波动与作业方法没有任何关系。 3、从原材料方面分析,通过对原材料的复验分析,原材料的成分与原来的成分相吻合,所以对出现的过程波动,与原材料没有任何关系。 4、从人员方面分析,通过对作业人员的工作认真程度、责任心等方面的全方位分析,确认

软件版本管理规范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

软件开发管理制度汇编

软件开发管理制度 版本:V1.0 2013年1月

第一节总则 第一条为规自有软件研发以及外包软件的管理工作,特制定本制度。本制度适用于公司总公司软件研发与管理,分公司参照执行。 第二条本制度中软件开发指新系统开发和现有系统重大改造。 第三条本制度中自行开发是指主要依赖公司自身的管理、业务和技术力量进行系统设计、软件开发、集成和相关的技术支持工作,一般仅向外购置有关的硬件 设备和支撑软件平台;合作开发是公司与专业IT公司(合作商)共同协作 完成IT应用的项目实施和技术支持工作,一般形式是公司负责提供业务框 架,合作商提供技术框架,双方组成开发团队进行项目实施,IT系统的日常 支持由IT技术中心和合作商共同承担,IT技术中心负责部(一级)支持, 合作商负责外部(二级)支持;外包开发是指将IT应用项目的设计、开 发、集成、培训等任务承包给某家专业公司(可以是专业的IT公司或咨询 公司等),由该公司(承包商)负责应用项目的实施。 第四条软件开发遵循项目管理和软件工程的基本原则。项目管理涉及立项管理、项目计划和监控、配置管理、合作开发管理和结项管理。软件工程涉及需求 管理、系统设计、系统实现、系统测试、用户接受测试、试运行、系统验 收、系统上线和数据迁移。 第五条除特别指定,本制度中项目组包括业务组(或需求提出组)、IT组(可能包括网络管理员和合作开发商)。 第二节立项管理 第六条提出开发需求的信息技术部门参与公司层面立项,进行立项的技术可行性分析,编写《立项分析报告》(附件一),开展前期筹备工作。《立项分析报 告》应明确项目的围和边界。 第七条应用系统主要使用部门将《立项分析报告》上交公司总裁室进行立项审批,以保证系统项目与公司整体策略相一致。 第八条《立项分析报告》得到批准后,成立项目组(如果是外包开发,则成立外包商项目组;如果是合作开发,则与外包商共同成立合作开发项目组,以下统 称“项目组”),项目组应包括业务组(由公司相关业务部门组成)和IT组 (自行开发为办公室网络管理员;外包开发为外包商成员;合作开发为网络

软件版本管理规范标准

软件版本管理规 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产品软件版本命名 产品软件版本的命名规则如下所示:

版本管理制度

版本管理规范(草案) 研发部 2009-2-4

目录 文档类别使用对象....................................................... 错误!未定义书签。1.引言................................................................ 错误!未定义书签。 目的 .................................................................. 错误!未定义书签。 范围 .................................................................. 错误!未定义书签。 术语定义 .............................................................. 错误!未定义书签。 版序控制记录 .......................................................... 错误!未定义书签。 版本更新记录 .......................................................... 错误!未定义书签。2.版本管理............................................................ 错误!未定义书签。 2.1版本标识方法...................................................... 错误!未定义书签。 2.1.1正式版本..................................................... 错误!未定义书签。 2.2目录结构.......................................................... 错误!未定义书签。 2.3文档的存放........................................................ 错误!未定义书签。 当前版本和历史版本的存放 ........................................... 错误!未定义书签。 开发文档的存放 ..................................................... 错误!未定义书签。 源代码的存放 ....................................................... 错误!未定义书签。 SQL语句的存放...................................................... 错误!未定义书签。 发行文档的存放 ...................................................... 错误!未定义书签。 2.4权限控制管理...................................................... 错误!未定义书签。3.更新管理(版本升级) ................................................ 错误!未定义书签。 版本升级原则 ........................................................ 错误!未定义书签。 新版本的发布 ....................................................... 错误!未定义书签。4.备份管理............................................................ 错误!未定义书签。5.用户版本管理........................................................ 错误!未定义书签。6.研发部统一管理阶段性版本............................................. 错误!未定义书签。 阶段性版本的提交到研发部............................................... 错误!未定义书签。 阶段性版本的发布到公司网站上........................................... 错误!未定义书签。 各项目组新版本内部及时备份。........................................... 错误!未定义书签。7.版本工具的使用...................................................... 错误!未定义书签。 研发部采用SVN配置管理工具............................................. 错误!未定义书签。8.各项目组提交文档及源码以及规则....................................... 错误!未定义书签。 各项目组需要提交的文档................................................ 错误!未定义书签。 目前所管理的产品列表................................................... 错误!未定义书签。9.周报管理制度........................................................ 错误!未定义书签。10.风险管理制度....................................................... 错误!未定义书签。

软件版本管理制度

软件版本管理规X 系统软件开发部 2011-9-20

目录1引言3 1.1目的3 1.2X围3 1.3术语定义3 1.4版序控制记录4 1.5版本更新记录4 2版本管理4 2.1流程图4 2.2版本命名7 2.3版本升级7 2.3.1版本升级原则7 2.3.2新版本的发布8 2.4目录结构8 2.5文档的存放9 2.5.1文本文件的存放9 2.5.2源代码的存放9 2.5.3发行文档的存放9 2.6权限控制管理10 3备份管理10 3.1源文件备份10 3.2库文件备份10 4用户版本管理10 5版本工具的使用11 5.1配置管理工具11 5.2CVS的使用11 5.2.1常用命令11 5.2.2简单操作12 5.2.3版本分支管理12

1引言 1.1 目的 本文档是为规XXXXXXXXX软件版本管理而制定的。 1.2 X围 本文档为系统软件开发部版本管理员提供有关版本管理规X的相关内容,包括: ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3 术语定义 CVS CVS是一个开源的版本控制系统Concurrent Versions System的简称 文档 一种数据媒体和其上所记录的数据。 配置管理 标识和确定系统中配置项的过程,在系统整个生存周期内控制这些项的投放和更动,记录并报告配置的状态和更动要求,验证配置项的完整性和正确性。 软件配置 软件的具体形态在某时刻的瞬时影像。 配置项 软件配置管理的对象称为配置项,如:系统规格说明书,项目开发计划,用户手册,源码。 基线 软件生存周期中各开发阶段末尾的标记,它的作用是把各阶段工作的划分更加明确化,使本来连续的工作在这些点上断开,使之便于检验和肯定阶段成果。

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

技术部软件版本规范 文档建立/修改记录: 版本管理规范 【新建项目版本管理部分】 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。测试发邮件给

软件项目管理制度

软件项目管理制度 文件编号 SKYEYES-ZJ-04 版 本 号 Version 0.1 编 制 审 核 批 准 保密级别 发布日期

目录 1目的 (2) 2适用范围 (2) 3职责 (2) 4软件项目管理 (3) 4.1项目整体管理 (3) 4.2项目启动阶段 (5) 4.3初步需求调研阶段 (6) 4.4软件需求规格阶段 (6) 4.5设计阶段 (7) 4.6实现阶段 (8) 4.7测试阶段 (8) 4.8实施及试运行阶段 (10) 4.9验收阶段 (11) 4.10收尾阶段 (12) 5相关文件 (13)

1目的 本制度规定了公司所承接的不同规模的软件项目开发流程,说明项目的各个阶段之间的输入输出结果,以及执行各阶段任务时的要求及相关模板,各部门的职责等,并说明了各阶段完成的标志和标准,是项目组推进项目及质量管理部门检查项目工作的核心制度。 本制度是作为项目配置管理、质量管理、测试管理制度的基础性文件,其他相关制度按照此制度规定的流程及要求进一步拓展、深化项目相关其他环节的管理规范。 2适用范围 本制度适用于以下情况: ●公司所承接的不同规模的软件开发类项目; ●公司所承接的集成项目中的软件开发部分; ●公司产品的外围开发工作。 3职责 部门名称主要职责 分管总监1.负责协助项目启动过程,指派项目经理及项目组; 2.负责协助项目组完成项目各阶段任务; 3.负责参与评审项目关键阶段成果; 4.负责协助项目组处理疑难问题。 应用开发部1.部门成员出任项目经理; 2.项目经理为项目第一责任人; 3.对项目结果负责; 4.根据公司要求开展项目各阶段任务; 5.负责项目启动至项目收尾的所有项目相关工作; 6.负责向其他部门提供允许的技术资料及技术支持。 质量管理部 1.负责项目启动阶段的准备工作; 2.负责检查项目各阶段的成果并出具检查报告;

SPC管理规定

SPC管理规定

5.3.1.4 选择控制图的刻度 对于X 图, 坐标上的刻度值的最大值与最小值之差应至少为子组均值( X ) 最大值与最小值差的2倍。 对于R 图, 刻度值应从最低值为0开始到最大值之间的差值为初始阶段所遇到的最大极差( R) 的2倍。 5.3.1.5 将均值X 和极差R 画到控制图上。 5.3.2 计算控制限 5.3.2.1 计算平均极差( R ) 及过程平均值( X ) K R R R R K 21 K X X X X K 21 K 为子组的数量 5.3.2.2 计算控制限 UCL R =D 4R UCL X =X +A 2R LCL R =D 3R LCL X =X -A 2R 式中之D 4、 D 3及A 2为常数, 见 。 5.3.2.3 画控制线 在平均值( X ) 和极差图( R) 中用水平虚线将各自的控制限画上去, 在初始研究阶段, 这些控制限叫试验控制限。 5.4 过程控制解释 5.4.1 分析极差图( R 图) 上的数据点 a 、 超出控制限的点——出现一个或多个点超出任何一个控制限, 是该点处于失控状态的主要证据。因为在只存在普通原因引起变差的情况下, 超出控制限的点会很少, 我们便假设该超出的是由于特殊原因造成的。因此, 任何超出控制限的点是立即进行分析、 找出存在的特殊原因点的信号。 超出极差上控制限的点一般说明存在下列情况中的一种或几种: 控制限计算错误或描点时描错; 零件间的变化性或分布的宽度已经增大( 即变坏) , 这种增大能够发生在某个 时间点上, 也可能是整个趋势的一部分; 测量系统变化( 例如, 不同 的检验员或量具) ; 测量系统没有适当的分辨力。 有一点位于控制限之下( 对于样本容量大于等于7的情况) , 说明存在下列情况的一种或几 种: 控制限或描点错误; 分布的宽度变小( 即变好) 测量系统已改变( 包括数据编辑或变换) b 、 链—有下列现象之一表明过程已改变或出现这种趋势: 连续7点位于平均值的一侧;

相关文档
最新文档