软件系统部署及升级流程及管理

软件系统部署及升级流程及管理

第一章总则

第一条为保障股份有限公司（简称：公司）信息软件系统安全运行在生产环境，规范软件系统部署与升级流程、控制软件系统的生产运行安全，保证业务流程的顺畅和生产系统的完整性、功能完备，特制定本办法。

第二条本办法所指软件系统包括，但不仅限于公司组织实施的账户管理和受托管理核心业务系统、网上受理系统、呼叫中心系统、投资交易系统、投资估值系统、投资风险控制系统，以及OA办公系统、对外网站系统、基础技术架构系统等涉及的软件系统的部署、安全运行与升级管理。

第三条本办法所指软件系统部署与升级管理主要包括以下内容：软件系统投产前准备、软件系统投产管理、软件系统生产运行管理、软件系统生产安全管理、软件系统升级管理。

第四条信息技术部是本办法的制定部门和执行部门，设立系统运维岗，负责系统软件系统部署、安全运行与升级的具体技术实现，其它相关岗位和部门应按本办法所制定的流程配合完成相关工作。

第二章软件系统投产前准备

第五条软件系统的投产关系到整个信息系统的安全运行，应做好充分的投产前准备。投产前的准备工作包括以下几个方面：环境设备的准备、硬件设备的准备、投产程序和数据的准备、相关投产文档和培训的准备等。

第六条环境设备的准备主要包括：系统架构确认、机房机柜机架配备、电源使用配备、网络线路配备、操作系统预安装和配臵、主机命名和网络配臵、存储环境配臵检查、备份环境、环境参数配臵、数据库配臵、中间件配臵、环境冗余切换配臵、通讯配臵、部署操作员配臵、环境变量、客户端环境等。

第七条硬件设备的准备主要包括：主机连接方式、主机型号配臵、处理器

频率和数量、内存配臵、内臵硬盘容量、网卡类型和数量、光纤通道卡型号和数量、其他内臵的I/0卡和其他外设等。

第八条投产程序和数据的准备主要包括：目标程序及相关清单说明、可控版本组织、系统配臵参数、数据库初始化数据等。

第九条相关投产文档和培训的准备主要包括：《系统安装部署手册》、《系统IT参数配臵手册》、《数据备份和恢复操作指导》、《系统故障与恢复手册》、《系统文件目录清单说明》、《系统运行日志存放说明》、《系统各类密码修改说明》、《文件清理计划及操作指导》、《管理员、项目经理、厂商负责人通讯录》以及相应的功能使用培训、安装部署培训、日常维护培训等。

第十条系统投产准备工作中有关权限管理、参数配臵、数据初始化管理应遵照《IT系统权限及数据管理办法》的相关规定：

(一)投产系统权限申请设臵应形成流程并由业务部门负责人和风险控

制部门审核；

(二)软件系统投产的参数配臵由信息技术部牵头组织信息，各业务部们

予以协同支持，最终由风险控制部进行参数定级并进行投产参数审

核；

(三)对于系统初始化数据，原则上不允许进行数据库文件导入操作，而

应通过数据操作语句进行数据初始化，各基础数据应得到业务部门

和风险控制部门的签字审核。

第三章软件系统投产管理

第十一条软件系统投产管理是指对软件系统产品从提交投产申请到投产运行过程的管理，由信息技术部项目管理岗和系统运维岗协同负责相关管理工作。

第十二条软件系统投产部署须经相关业务部门领导的核实，并经过信息技术部领导审批后由相关技术人员制定详细的安装计划和操作步骤，并依据具体设备特性对系统进行合理配臵、测试和调整，从而充分发挥设备资源优势。

第十三条软件系统供应商必须向信息技术部提供详细完整的有关投产系

统的软硬件及其运行维护的技术资料，并负责向信息技术部的系统管理人员、系统操作人员进行技术培训。

第十四条软件系统供应商应会同信息技术部制定周密、严谨的软件系统上线计划。

第十五条软件系统供应商应向信息技术部提供相应的系统监控手段、日常维护工具、数据备份计划以及应急联系办法等，并至少指定一名系统开发人员作为该系统投产后的软件维护员。

第十六条软件系统投产申请流程：

(一)统一由信息技术部发起权限申请流程、参数设臵、数据初始化申请

流程，并会同软件系统供应商完成软件系统投产前准备工作和《系

统移交说明书》。

(二)在征询相关业务部门意见后形成请示签报，并附《岗位菜单对应

表》、《批量员工权限申请表》、《业务系统参数表》以及批量初始化

数据文件，以便各项关部门进行核对检查。

(三)该请示签报需经过相关业务部门、风险与合规部，以及运营总监会

签后，提交总裁办最终审核。

(四)该请示经总裁办审核通过后，由信息技术部系统运维岗负责软件系

统部署投产。

(五)《岗位菜单对应表》、《批量员工权限申请表》、《业务系统参数表》

以及批量初始化数据文件经相关业务部门（或办公室）和风险与合

规部进行核对审批后，提交给信息技术部，由系统运维岗进行执行。

第十七条软件系统投产部署工作规范：

(一)软件系统产品投产部署入总部机房，必须在预定安装日之前三个工

作日提出部署工作计划，并按照《系统安装部署手册》、《系统IT

参数配臵手册》《系统移交说明书》核对各项准备工作。经过信息技

术部负责人签字同意后，交系统运维岗协调部署工作。

(二)系统运维岗人员协调软件系统供应商、软件项目管理岗，及相关网

络管理岗、桌面管理岗人员，按照部署工作计划执行各项投产部署

安装工作。

(三)软件系统产品安装时，系统负责人员必须到场，所有参与上线工作

的人员必须严格遵守《计算机机房运行安全》相关规定，值班人员

必须加强监督并填写好《机房工作日志》。

第十八条软件系统产品投产运行的前提条件是：

(一)软件系统产品已通过信息技术部、相关业务部门双方测试和联合验

收。

(二)项目管理岗和系统运维岗协同软件系统供应商完成了软件系统投

产前准备工作和《系统移交说明书》的编写。

(三)信息技术部项目管理岗会同系统运维岗发起项目上线申请签报，经

相关业务部门、风险与合规部、运营总监会签后，向总裁办提出上

线申请，并提供该系统相应的文档、业务及技术测试报告以及经过

核准的业务验收报告。

第十九条软件系统产品投产运行时，信息技术部项目管理岗、系统运维岗以及相关业务部门应共同明确各自职责：

(一)信息技术部系统运维岗主要负责软件系统上线后的安全运行；

(二)项目管理岗主要负责该软件系统的技术优化、功能缺陷纠正和紧急

维护；

(三)业务部门主要负责业务操作和业务管理。在明确职责的基础上，各

自制定相应的管理办法。

第二十条软件系统投产申请流程遵循本办法第十六条规定；各软件系统上线根据系统类型，业务类别、服务对象的不同可以根据实际情况选择执行不同的步骤：

(一)软件项目完成对业务及技术测试报告进行总结和评估,并形成系统

业务验收报告和技术验收报告;系统菜单权限表与参数表由业务部

门确认和会签,提交合规与风险管理部确认和会签;信息技术部保障

硬件与网络到位，完成软件项目文档的整理与归档工作，并制定该

系统故障处理办法、系统备份策略、日常运维操作流程，完成系统

上线前数据初始化工作。软件项目开发实施厂商对系统稳定安全运

行的作出承诺。

(二)信息技术部提交内部评审请示（包括系统准备情况汇报、内部评审

方案介绍）；

(三)经总裁室同意请示后，由信息技术部牵头准备评审工作；信息技术

部、相关业务部门、合规与风险管理部、开发商进行汇报；由业务部门负责人、信息技术部负责人、分管领导、外部专家组成评审组，对系统进行评议，并统计形成评审结果。

(四)由信息技术部根据评审结果向总裁室提交《关于系统试运行的请

示》签报；

(五)在总裁室同意后，信息技术部开始系统正式环境的切换工作；各业

务部门与外部机构按正式岗位进行系统试运行工作，并按信息技术部正式运维流程提交系统问题单。

(六)系统试运行结果由信息技术部牵头对系统试运行情况进行总结，并

提交系统正式运行上线的请示，在总裁室同意后开始正式运作。(七)软件系统投入正式投入运行后，应根据《信息系统安全等级保护定

级指南》要求开展自主定级、系统测评、专家评审，对于定级在第二级以上信息系统，应当在投入运行后30日内，到公安机关办理备案手续，并保备相应的主管和监管部门。

第四章软件系统生产运行管理

第二十一条生产运行管理是指对生产系统中系统软件（包括操作系统、数据库、中间件、管理监控平台等）的管理，由信息技术部系统运维岗负责相关管理工作。

第二十二条信息技术部系统运维岗应做好系统的日常运行维护工作：

(一)制定系统运行维护计划，严格按计划对系统进行维护，并详细记录

维护情况。

(二)制定备份计划，对备份的时间、内容、级别、人员、保管期限、异

地存取和销毁手续等进行明确规定。

(三)密切监视系统运行状况，及时处理系统故障，并对故障产生原因进

行认真的分析总结。

(四)定期对系统运行状况进行分析，定期进行系统性能优化。必要时应

制定主机系统的升级方案，升级方案实施须报信息技术部门领导审

批。

(五)建立软件系统运行档案，对软件系统的基本情况（版本、配臵等）、

升级、故障现象、故障产生原因、故障处理过程及处理结果等进行

详细记录。

第二十三条信息技术部项目管理组和系统运维组应密切关注应用系统上线运行情况，及时处理应用系统故障，对故障原因进行认真的分析总结，制定有效的优化改进计划,并最终反馈给业务部门。

第二十四条信息技术部系统运维岗应及时收集、整理应用系统运行过程中所发生的问题，反馈给信息技术部项目管理组。

第二十五条信息技术部系统运维岗应建立上线应用系统的变更管理制度，对程序版本更新、例行操作变更、非例行操作、应用系统维护以及系统运行

环境等变更实施规范管理和有效控制。

第二十六条严禁在生产系统上安装开发测试类软件、编译工具、应用系统源程序及其他与生产系统无关的软件。项目管理岗相关人员未经授权，不得随意访问生产环境，更不得随意变更已上线的各类应用系统。

第二十七条任何人未经允许不得擅自修改系统配臵。如确需修改应填写《生产环境变更操作登记表》，严格履行审批手续，并由双人会同实施。实施时应有系统运维组主管现场监督，实施后应将变更前后的系统配臵及变更全过程记录备案。

第二十八条对于软件系统的软硬件升级、变更、系统切换、年终结算等重大操作，信息技术部、相关业务管理部应密切配合，共同制定详细的计划和应急方案，统一部署，周密安排，防范风险。

第五章软件系统生产安全管理

第二十九条生产安全管理是指对保障生产系统安全可靠运行的关键安全环节的管理，由系统运维岗和网络及机房管理岗负责相关管理工作。

第三十条信息技术部应充分合理地利用生产系统提供的各种安全机制，实现系统备份、安全保护和安全服务。

第三十一条备份系统在构成和配臵上应与生产系统尽量保持一致，并制定了有效、可行的切换机制，确保当生产系统出现故障时能迅速接管和承载业务运行。

第三十二条数据备份包括本地数据备份和异地数据备份，由信息技术部系统运维岗负责相关管理工作。

(一)备份介质应按备份对象分类存放，不得混放、混用。业务数据备份

介质必须存放于有保护的特定场所，并同时对其拷贝进行异地（非

同一建筑物）保存。

(二)任何人未经授权，不得随意导入和导出备份介质中的信息和数据，

不得随意将备份介质或数据报表带出机房。

(三)废弃的备份介质或数据报表应存放在指定地点，并由专人集中销

毁。

(四)严格执行异地数据备份交接，交接双方必须严格履行交接手续，整

个操作过程在相应的监控设备下进行，并有书面记录备查。

第三十三条信息技术部对各级用户及其权限的设定应进行严格管理，用户权限的分配必须遵循“最小特权”原则。

第三十四条用户账号与密码管理应严格遵循有关规定。用户密码应严格保密，及时更新。重要用户密码应密封交安全管理员保管。密码口令知情人员调离时，信息技术部应及时修改相关密码、口令。运行机构应严格限制对密钥等密级文件的访问，防止非法研读和拷贝。

第三十五条系统运维岗人员不得担任业务操作工作。项目管理岗不得代替系统运维岗人员从事运行各岗位的工作。

第三十六条信息技术部应采取切实有效的措施，做好生产环境的计算机病毒防范工作。对易受病毒攻击的计算机信息系统，应落实专人定期清查病毒，升级安全补丁，防止病毒或漏洞对计算机系统和数据造成破坏。

第三十七条信息技术部应制定安全运行应急计划，针对系统运行过程中可能发生的故障和灾难，制定恢复运行的措施、方法负责本公司应急计划的演练、实施和管理。

第三十八条应急计划的实施必须按规定经过有关领导批准。应急计划实施后，信息技术部必须认真分析和总结事故原因，制定相应的补救和整改措施。

第三十九条如发生重大运行事故，信息技术部须在事故发生一小时内将事故情况上报上级部门，不得迟报、瞒报。事故恢复后，信息技术部须形成关于事故原因、处理过程和整改措施的详细报告，于事故恢复后10个工作日内上报。

第四十条系统软硬件及应用软件的升级、更新等重大变更操作的实施方案必须包括应急措施。实施过程中一旦出现意外情况，须及时采取应急措施恢复运行，避免引发重大运行事故。

第六章软件系统升级管理

第四十一条软件系统升级管理是指管理软件系统在生产环境的系统更

新的过程，由信息技术部系统运维岗负责相关管理工作。管理软件升级的目的是，通过规范升级流程、控制升级次数，达到定期升级的目标，保证业务流程的顺畅。

第四十二条为保障生产环境的安全稳定运行，准投产环境数据与应用程序与生产环境进行同步升级管理，一般要求周二完成准投产环境升级测试，周四完成生产环境升级。

第四十三条紧急更新是指，软件系统因软件故障影响该系统的继续使用和运行或生产系统的系统功能已经无法满足业务开展，且该影响将对业务造成较大的破坏或造成较大范围的业务停顿，而此时必须进行软件系统处理，同时已经具备了紧急处理所需要的各项条件而执行的软件系统变化的软件系统维护操作。

第四十四条生产环境软件系统的系统升级遵循安全、稳定、慎重的原则，以保证业务流程的顺畅及生产环境的稳定为最大目标，分为：例行升级、紧急升级。

(一)升级内容必须做到文档齐全，要至少包含：《系统需求规格说明书》、

（或《生产环境故障报告单》）、软件测试结果、《生产环境更新审批

单》及其附件、《生产环境更新文件清单》及提交的程序、数据。

(二)升级内容测试结果必须得到相关业务部门审批后方可提交系统运

维组执行升级。例行升级应到得到涉及该功能的业务部门测试人员

以及测试部门负责人、项目经理、信息技术部负责签字方可升级。

确因时间紧迫无法按要求提前申请的，应及时通过电话方式与相关

部门进行沟通确认，并通过邮件通知风险与合规部进行临时登记后

方可执行。

(三)软件系统升级前必须做好数据库、系统软件的备份，以防出现升级

失败后能够立即恢复升级前的系统；升级完成后相应业务部门或开

发组项目经理必须在生产环境软件系统启动进行功能验证测试无误

后，方可离开。

(四)软件系统升级必须建立完整的升级档案，并定期将这些档案归档，

已备审计和检查。

第四十五条软件项目升级通用操作步骤

(一)系统运维岗人员以E-mail并以电话等形式通知业务部门和开发组

项目经理升级的时间安排。

(二)相关人员回复系统升级计划意见。

(三)首先进行系统的数据、程序、配臵脚本等进行备份。

(四)备份完成后，当涉及数据库升级时，系统运维岗使用脚本语言进行

服务器端的数据库升级；系统运维岗将升级包中的应用程序拷贝至

应用服务器，进行系统软件升级，如有配臵变动，同样作相应修改。。

(五)启动应用服务器，如启动不正常，检查操作步骤是否正确、相关配

臵是否正确，如并进行简单访问，确保应用服务器的配臵文件正常

启动。

(六)启动应用服务器，如启动不正常，检查操作步骤是否正确、相关配

臵是否正确，如应用服务器启动正常，并经过常规验证后，联系业

务部门或开发组项目经理进行升级验证。验证通过视为系统升级成

功；反之，为升级失败，系统运维岗联系开发组项目经理协助判别

失败原因，视实际情况，必要时则将系统环境恢复至升级前的备份

版本。

(七)系统运维岗填写《生产环境维护日志》，记录此次升级情况。并将

升级结果以E-mail等形式通知相关人员。

第四十六条软件系统更新与升级申请流程遵循本办法第四十四条规定；升级管理应全面考虑各个因素分别由部门经理、风险与合规部、主管总监、内部评审、总裁办审核等审批后执行，影响因素列举示例如下用于参照执行：

附则

第四十七条本管理办法由信息技术部负责解释和指导。第四十八条本管理办法自下发之日起实施。

信息技术部2007-12-29

软件系统投产管理流程

软件系统上线部署申请表

以下内容请附页详细提供：

附件三

生产环境故障报告单

注：故障编号规则：按日期顺序进行编号，具体YYMMDD0001- YYMMDD00019999。

生产环境更新审批单

生产环境变更操作登记表

生产环境维护日志

软件配置管理规定

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

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

车辆运输管理制度及流程

车辆运输管理制度及流程 为了更好地完善公司的内部管理，增强企业的凝聚力，明确司机的利益与公司的效益的密切关系，提高司机的工作责任心，特定如下制度。 一、车辆运输工作流程 1．调度员负责接收用户信息 2．调度员按照发车计划给司机下达运输任务； 3、司机按调度的发车计划到搅拌站主楼装车，集控室出具一式五联的《供货单》交付司机； 4．实施运输、质量的监督与审核 （1）司机负责监督混凝土装卸工作，并对运输质量负责；（2）混凝土在运输过程中发生问题时，司机应立刻通知有关人员进行解决。 5．交付 （1）司机将混凝土按指定时间、指定地点交给指定人员；（2）用户在《供货单》上签字盖章，自留一联； 6．结算 （1）司机负责带回经客户签字确认的《供货单》并交给调度员； （2）调度员负责对《供货单》进行核对、统计、转交财务部（会计）；

（3）财务部记帐后在结算期限内与用户进行统一结算。 二、车辆运输管理办法 1、各承运司机必须按公司生产调度的要求，按时、保质、保量的完成运输任务，每发生一次未按要求承运的车辆，一律按《公司奖惩制度》进行罚款。如因个人原因不能及时到达给用户造成经济损失的，不仅赔偿损失而且视情节暂停运输，情节严重的予以辞退。 2、承运司机的运输车辆在途中出现车辆故障和交通肇事等问题，不能按要求到达目的地。在出事后30分钟内必须打电话向公司调度和车队队长汇报详细情况，尽快采取措施。 3、承运司机必须保管好各票据并按规定及时传递各种票据，否则根据情节进行处罚，对严重影响正常工作者当月不予发放业务提成。 4、各承运司机必须根据公司生产调度下达的指令，准时到达指定地点，进行装卸车，不得以任何借口拖延，如有违反，将按规定处罚。 5、各承运司机接受处罚后，必须在下次装车前按规定及时将罚款交公司财务部，如果承运司机不能按时上缴罚金，生产调度不分配任务，并在运费中扣除。 6、运输问题处罚标准 （1）承运司机未按要求时间把货送到用户手中，影响用户使用，每晚一次罚款200元；

信息系统软件开发流程管理规范_初稿

软件开发流程管理规范

一、概述 随着公司规模的扩大、各部门对软件需求的激增、提高效率的工作要求，IT 部门承接的软件开发项目越来越多，而与之相对应的就是软件开发流程不明确，软件项目的随意性较大、可追溯性较差、可统计性模糊、可预测性不足是摆在我们面前最直接的问题。为了适应公司的发展，IT 部软件开发项目特制订本流程。 二、流程 由上图可以得出以下几个关键步骤： 一、需求部门： I、需求部门首先需要填写《软件需求申请表》，说明需要开发的软件具体用途径、目前工作模式、工作不方便之处、基本功能等信息； II、待 IT 部门评审通过后，通知需求部门，填写《软件开发申请表》，具体列明需要实现的功能、目前工作流程、使用系统后需

要达到的状态，可节省的人力、物力，调高的效率等信息； III、软件开发测试完成之后，接受 IT 部门的软件使用培训，并填写《参与培训确认单》； IV、软件试用结束后，填写《软件验收表》，完成软件项目的开发流程； V、在开发测试过程中，遇到开发风险增加、需求变更等，都需要配合 IT 软件开发人员 填写相关的《项目风险管理表》和《项目 变更管理表》。二、IT 部门： I、积极对需求部门提出的《软件需求申请表》进行评审、审批，限 3 个工作日完成， 及时反馈结果给需求部门；

II、指导需求部门填写各类表格； III、积极评审需求部门填写的表格、积极沟通，有效获得相对准确的需求，并填写完善， 让需求部门签字确认； IV、进入开发流程后，积极填写《项目成员组成表》、《项目策划任务书》、《WBS 表》、 《项目进度计划表》等（具体见附件）； V、积极开展人员培训和软件试用工作，编写完善的《XXX 软件试用说明书》，并要求相关人员签字确认，并存档处理。 三、附件附件一、编码规范1、 命名空间 1. 公共类库（公司功能业务）： （1）全局公共类库： 例：生成 dll 文件，添加至最小应用库可全程序引用 （2）局部公共类库（主要区分公司），命名方式为专有业务场景+专有业务名+具体类名：例：（总部）/In（国内市场）/Rb（生产）注：（公共类库）信息登记、评审、信息共享，命名空间最多三层2. 项目程序文件：项目文件名,以核心功能的英文名称为准,格式:ECO_英文名词首字母大写 2、命名规则 文件夹及相关文件命名规则 a) 文件夹：功能文件夹，采用驼峰形式，首字母大写全称 b) 窗体文件：采用驼峰形式，首字母大写全称

软件配置管理流程

配置管理流程规定 (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)配置库的日常操作和维护 开发人员

车辆装卸过程安全管理措施

车辆装卸过程安全管理措 施 Prepared on 22 November 2020

厂内车辆装卸过程安全措施要求 一、目的：为进一步规范厂内车辆（包含平板车）装卸工作，加强对装卸人员的管理，杜绝车辆装卸过程中的安全生产事故，提出以下明确安全措施要求。 二、适用范围：公司内所有员工及外来装卸车人员。 三、管理要求： 1、装卸货物要指派专门人员担任装卸车工作，装卸人员确保材料、货物堆放稳固，不滚动，不滑落，装车时由下向上，分层堆放；装车完毕，绑扎牢固。 2、卸车时由上向下，分层卸货，保持车辆重心稳定，不偏载。 3、用起重设备配合作业时，严格执行6个“禁止”。 严禁作业人员站在吊物运行线路内或从吊起的货物底下钻过；禁止站在列角和敞车车帮上；禁止站在起吊物件上；禁止用手校正吊高米以上的物件；禁止用手脚伸入已吊起的货物下方直接取放垫物；禁止不按规定，随处乱放货物。 4、具体要求： （1）作业前，必须检查作业人员是否佩戴整齐，不得光膀、、穿拖鞋，在未做好的情况下不得从事作业。 （2）对，吊索具进行及时全面检查，发现有故障、有损坏，要及时进行更换或报废，以保证作业安全。

（3）人力装卸、搬运时，应量力而行，配合协调，绝不可冒险；在车辆尚未停稳、就位的情况下，不得上下车辆；存放地点不在一处，车辆需要移位时，要员、货物的安全，采取必要的保护措施；车辆装完货物捆扎牢固。 （4），必须严格执行和有关规定，要有专人负责操作设备和起吊、栓吊工作，严格按设备规定负荷作业和车允许载荷装载。 （5）作业现场的装卸、搬运人员和行车操作人员，要严格，服从指挥，不得野蛮装卸，摔坏，砸坏货物，不得在没有装卸完毕的情况下提前弃车下班，不得在作业现场嬉戏、追逐、打闹。 （6）严格遵守安全消防规定，不得在仓库、作业现场吸烟，动用一切火具。（7）必须及时观察作业过程，发现存在，应立即停止作业，进行排除后，方可继续作业。 （8）当每次作业完毕后，对现场进行检查、清理，不遗留、吊索具、和垃圾，做到有始有终。 四、违规处理：违反以上规定，按照公司相关处罚制度进行处理。 2014年1月22日

软件开发流程管理系统规章制度

软件开发流程管理制度 （讨论稿） 为加强对定制软件开发工作管理，缩短开发周期，提高软件开发质量，降低开发成本，提高定开发效率和效益，特制定软件开发流程管理制度。 第一章、总则 为保证日常工作正常有序的进行，让开发中各个环境更紧凑，更可控，需要尽可能实现项目管理的正规化，工作过程的流程化，以便提高软件质量，按期交付。 1、软件开发总体遵循项目管理和软件工程的基本原则。 2、项目管理涉及项目立项、项目计划和监控、配置管理。 3、软件工程涉及需求分析、系统设计、软件实现、系统测试、用户测试、试运行、系统验收、系统上线和数据迁移、产品维护。 第二章、阶段成果 根据软件工程的过程，制定以下工作流程，并规定了各个重要环节需要提交的交付物。各阶段需提交的文档： 1、立项：项目申请表，软件需求报告或设计方案。 2、需求分析：项目研发主计划、需求规格说明书 3、总体设计：概要设计说明书或功能模块描述

4、详细设计：详细设计说明书，包括软件接口说明、单元测试计划。 5、软件实现：软件功能说明、源代码说明或者注释 6、产品测试：测试报告 7、产品发布：产品说明书、使用手册 8、产品维护：问题反馈记录 9、项目总结：提交客户方的项目总结和公司项目汇报的PPT。软件过程成果表：

第三章、岗位设置 根据公司目前的开发过程主要分为分析、开发、测试三个阶段。分析阶段完成用户需求文档的编写，系统总体设计的编写；开发阶段完成设计文档的编写，代码的编写、代码的维护。测试阶段完成系统的测试，测试文档及其他材料。通过逐渐的调整岗位，明确工作职责，逐步实现项目经理，软件设计师，程序员，测试工程师的岗位设置。

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

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

管理信息系统开发过程

开发阶段 项目立项主要任务 提出开发请求 用户需求分析 企业的运行情况 企业管理方法 信息需求分析 基础数据管理状态 现有信息系统运行状态 确定系统目标常用工具初步调查各种调查方法系统规划划分子系统 功能结构图的总体设计 数据库系统总体结构设计 总体方案设计代码方案的总体设计 系统物理配置总体方案的设计 工程费用概算与效益分析 制定实施计划 给出系统的总体方案 经济上的可行性研究 技术上的可行性研究 可行性研究操作上的可行性研究

法律上的可行性研究 管理上的可行性研究 书写可行性分析报告 审核批准 组织机构与功 详能分析审核项目开发计划 申和可行性分析报告 组织机构与功能调查 绘制组织机构图 绘制业务功能一览表 收集相关资料 绘制业务流程图 绘制表格分配图 收集相关资料 绘制数据流程图 分析系统目标 分析原系统存在的问题 优化子系统的划分结果，分析各子系统的功能数据分析，绘制新系统的DFD图 新系统的边界分析 确定数据处理方式

系统分析报告组织结构图业务功能一览表业务流程图表格分配图 数据流图U/C矩阵PERT图细 系调业务流程分析xx 数据流分析分析系统分析与逻辑模 型设计 系系统物理配置方案 设计完成系统分析报告，交有关部门审批，选择计算机机型 确定网络 确定DBMS统设计功能结构图设计 系统流程图设计 处理流程图设计 详细设计编码 数据存储设计 输入与输出设计 指定设计规范 编写程序说明书 编写系统设计报告 物理系统的实施绘制功能结构图 划分模块

把DFD图转化为管理信息系统流程图具体规定处理过程中各个步骤 为新系统中的数据编码 统一并改进编码 DB的逻辑结构设计 DB的物理结构设计 输入设计、输出设计 制定文件名和程序名的统一格式 定义处理过程 完成系统设计报告，提交有关部门审批采购计算机和通讯网络系统 准备机房 安装调试设备 管理程序设计 业务程序设计 程序调控 分调 总调 以新系统代替旧系统 将系统交付使用，验收是否合格 编写程序设计说明书

软件配置管理规范.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

软件配置管理计划示例

软件配置管理计划示例 作者：赵文锋计划名CADCSC软件配置管理计划 项目名中国控制系统CAD工程化软件系统 项目委托单位 代表签名年月日 项目承办单位 代表签名年月日 1 引言 1．1 目的 本计划的目的在于对所开发的CADCSC软件规定各种必要的配置管理条款，以保证所交付的CADCSC软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1．2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料 ◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆CADCSC 软件质量保证计划 2 管理

2．1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务 在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第条中详细规定。 2．3 职责 在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下： A．组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责； B．软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范； C．项目的专职配置管理人员检查在作配置更改时的质量保证措施； D．各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；

客运站车辆安全例检工作流程图

客运站车辆安全例检工作流程图 车辆进入 ↓ 不合格

客运站安全例检说明： 1、此表系参照客运总站、富裕客运站、克山客运站营运客车例检做法汇集而成。 2、车辆进入检测站，由驾驶员介绍车辆情况，安检员按照交通运输部制定的9项安全例检项目对车辆进行检测，对合格的车辆出具例检合格报告单，填报营运客车安全例检合格通知单并在报告单、通知单和安检证、上盖章签字，报告单由安检站留存。对不合格车辆，开具例检不合格项目告知单，驾驶员到具有资质的维修企业进行维修。 3、驾驶员凭营运客车安全例检合格通知单和安检证到客运站值班室向负责报站人员报站。报站人员检查安检证、营运证、驾驶证、行驶证、从业资格证、乘务证、安全教育培训证及线路牌（七证一牌）是否齐全。并填写《客运车辆进站从业人员证照检查登记表》，同时报站人员对驾驶员进行资质核查，查看驾驶员精神状态，有无精神不佳或疲劳现象，发现有精神状态不佳等行为，不予报站，建议更换驾驶人员。对无疑问，证件齐全的，在通知单签字，方可报站进入售票系统。 4、出站安检（六不出站），检查人员认真核对定员、实载人员，开货箱检验货物、提示系好安全带、安全锤、灭火器、GPS监控镜头、安全告知宣传片播放等检查。核对安检证、营运证、驾驶证、行驶

证、从业资格证、乘务证、安全教育培训证及线路牌（七证一牌）是否齐全。查验无误后，经驾驶员在出站检查单签字，检查人员签字后放行出站。 5、客运站有停靠站的，营运客车必须到停靠站签单，停靠站再次对定员、实载人员、开货箱检验、旅客系安全带、灭火器、安全锤、GPS监控、安全告知宣传片等检查。核对无误后，经驾驶员在停靠站检查单签字和停靠站检查人员签字后运营生效。 6、驾驶员凭最终客运站出站或停靠站售票结算单与客运站结算票款费用。

软件项目开发过程管理

软件项目开发过程管理 计算机软件尤其是数据库软件，成为了当代计算机应用的主流。因此软件开发人员就必须掌握正确的开发手段，了解软件开发的主要过程，这样心中对软件项目才有清醒的认识，才能达到事半功倍的效果。本文就软件开发过程中的一些方法，结合本人开发过的一些软件项目做一些详细论述。 1 开发前的准备工作 一般软件项目在开发前都有系统任务书，主要规定软件的开发目标、主要任务、功能、性能指标及研制人员和经费、进度等安排，作为系统设计开发和检验的基本依据。 系统任务书的基本框架如下： （1）引言 包括编写目的，背景，参考资料。 （2）系统的目标及任务 包括系统建设目标，系统的主要任务，系统性能指标，系统标准化要求。 （3）系统的结构及功能 包括系统应用组成及结构，系统主要功能。 （4）系统的规模及进度要求

包括系统规模，系统研制进度，人员计划。 但是系统任务书只是这个软件项目的一个基本要求，针对具体情况，软件开发人员和需求分析人员就要联合对软件项目的细节进行具体分析，必要时还要进行实地调研，然后共同商讨写出系统的需求分析，需求分析的编写目的在于： a. 说明系统在军事方面、技术方面、经济方面和社会条件方面实现的可行性和必要性； b. 分析原系统（工作环境）现状,描述待开发系统的详细需求，提供用户和开发人员之间沟通的基础，提供项目设计的基本信息。 需求分析报告的基本框架如下： （1）概述 包括编写目的，背景，参考资料，术语及缩写词。 （2）对现有系统的分析 （3）待开发系统的详细需求 包括功能需求，使用范围，业务流程，用户界面，输出要求，故障处理。 （4）使用环境 包括网络环境，硬件环境，软件环境，与其他系统的关系，安全与保密。 （5）可行性分析 包括技术可行性分析，经济可行性分析，人员可行性分析，影响待开发系统的主要因素。 （6）结论意见

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

软件配置管理规范 流程 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) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再

软件系统部署及升级流程及管理.doc

. 软件系统部署及升级流程及管理 第一章总则 第一条为保障股份有限公司（简称：公司）信息软件系统安全运行在 生产环境，规范软件系统部署与升级流程、控制软件系统的生产运行安全，保证业务流程的顺畅和生产系统的完整性、功能完备，特制定本办法。 第二条本办法所指软件系统包括，但不仅限于公司组织实施的账户管理和受托管理核心业务系统、网上受理系统、呼叫中心系统、投资交易系统、投资估 值系统、投资风险控制系统，以及OA 办公系统、对外网站系统、基础技术架构 系统等涉及的软件系统的部署、安全运行与升级管理。 第三条本办法所指软件系统部署与升级管理主要包括以下内容：软件系统投产前准备、软件系统投产管理、软件系统生产运行管理、软件系统生产安全管 理、软件系统升级管理。 第四条信息技术部是本办法的制定部门和执行部门，设立系统运维岗，负责系统软件系统部署、安全运行与升级的具体技术实现，其它相关岗位和部门应 按本办法所制定的流程配合完成相关工作。 第二章软件系统投产前准备 第五条软件系统的投产关系到整个信息系统的安全运行，应做好充分的投产前准备。投产前的准备工作包括以下几个方面：环境设备的准备、硬件设备的

准备、投产程序和数据的准备、相关投产文档和培训的准备等。 第六条环境设备的准备主要包括：系统架构确认、机房机柜机架配备、电源使用配备、网络线路配备、操作系统预安装和配置、主机命名和网络配置、存 储环境配置检查、备份环境、环境参数配置、数据库配置、中间件配置、环境冗 余切换配置、通讯配置、部署操作员配置、环境变量、客户端环境等。 第七条硬件设备的准备主要包括：主机连接方式、主机型号配置、处理器频率和数量、内存配置、内置硬盘容量、网卡类型和数量、光纤通道卡型号和数 量、其他内置的I/0 卡和其他外设等。 第八条投产程序和数据的准备主要包括：目标程序及相关清单说明、可控版本组织、系统配置参数、数据库初始化数据等。 第九条相关投产文档和培训的准备主要包括：《系统安装部署手册》、《系统 IT 参数配置手册》、《数据备份和恢复操作指导》、《系统故障与恢复手册》、《系统文件目录清单说明》、《系统运行日志存放说明》、《系统各类密码修改说明》、《文件清理计划及操作指导》、《管理员、项目经理、厂商负责人通讯录》以及相应的功能使用培训、安装部署培训、日常维护培训等。 第十条系统投产准备工作中有关权限管理、参数配置、数据初始化管理应遵 照《 IT 系统权限及数据管理办法》的相关规定： (一 ) 投产系统权限申请设置应形成流程并由业务部门负责人和风险控制 部门审核； (二 ) 软件系统投产的参数配置由信息技术部牵头组织信息，各业务部们 予以协同支持，最终由风险控制部进行参数定级并进行投产参数审 核；

软件配置管理规定

软件配置管理规定 为进一步加强软件配置管理工作，明确软件配置原则，规范软件配置流程，制定本规定。 一、配置原则 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) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。

软件项目配置管理系统计划清单指导应用清单

中国核电集团 CHINA GUANGDONG NUCLEAR POWER GROUP 记录文件 项目编号 项目名称 CGN-IT-C3-A12-01 软件项目配置管理计划 版本编写审核审定批准生效时间A/0 注：如无受控文件标识（蓝色印章）则为非有效版本，以受控文件规定为准。 此文件属中国核电集团所有，未经许可，不得以任何方式外传。

修改记录页

目录 (一)基本信息 (4) (二)角色与职责 (4) (三)配置管理资源 (5) (四)权限分配 (5) (五)配置项计划 (6) (六)配置库基线 (7) (七)配置库备份计划 (8) (八)配置库状态报告 (8) (九)配置审核 (9) (十)审批意见 (9)

配置管理计划(一)基本信息 项目名称： 项目代号： 立项时间： 预计主要项目阶段有： 配置项目命名规则依据： (二)角色与职责

(三)配置管理资源 本项目使用配置管理工具对各配置项进行存储、版本管理，并提供更新、检索和历史版本的恢复。 提示： （1）配置管理员确定本项目的配置管理软件。例如采用Microsoft公司的TFS或者IBM公司的clearecase。 （2）配置管理员根据所采用的配置管理软件，确定计算机资源（考虑存、外存、CPU等）。 预计建库申请日期： 预计建库日期： 预计工作库需空间： (四)权限分配 项目成员访问配置库的ID及PASSWORD默认设置为与域的设置相同。 若个人要求另行设置的，由项目组配置管理员负责汇总后，提交给高级配置管理员调整设置。

(五)配置项计划 填写上面表格过程中，需要对照成果物列表逐项填写。

信息系统软件开发流程管理规范 初稿

软件开发流程管理规范 一、概述 随着公司规模的扩大、各部门对软件需求的激增、提高效率的工作要求，IT 部门承接的软件开发项目越来越多，而与之相对应的就是软件开发流程不明确，软件项目的随意性较大、可追溯性较差、可统

计性模糊、可预测性不足是摆在我们面前最直接的问题。为了适应公司的发展，IT 部软件开发项目特制订本流程。 二、流程 由上图可以得出以下几个关键步骤： 一、需求部门： I、需求部门首先需要填写《软件需求申请表》，说明需要开发的软件具体用途径、目前工作模式、工作不方便之处、基本功能等信息；II、待 IT 部门评审通过后，通知需求部门，填写《软件开发申现的功能、目前工作流程、使用系统后需请表》，具体列明需要实 要达到的状态，可节省的人力、物力，调高的效率等信息； III、软件开发测试完成之后，接受 IT 部门的软件使用培训，并填写《参与培训确认单》； IV、软件试用结束后，填写《软件验收表》，完成软件项目的开发流程； V、在开发测试过程中，遇到开发风险增加、需求变更等，都需要配合 IT 软件开发人员 填写相关的《项目风险管理表》和《项目变更管理表》。二、IT 部门： I、积极对需求部门提出的《软件需求申请表》进行评审、审批，限 3 个工作日完成， 及时反馈结果给需求部门；

II、指导需求部门填写各类表格； III、积极评审需求部门填写的表格、积极沟通，有效获得相对准确的需求，并填写完善， 让需求部门签字确认； IV、进入开发流程后，积极填写《项目成员组成表》、《项目策划任务书》、《WBS 表》、 《项目进度计划表》等（具体见附件）； V、积极开展人员培训和软件试用工作，编写完善的《XXX 软件试用说明书》，并要求相关人员签字确认，并存档处理。 三、附件附件一、编码规范 1、命名空间 1. 公共类库（公司功能业务）： （1）全局公共类库： 例：生成 dll 文件，添加至最小应用库可全程序引用 （2）局部公共类库（主要区分公司），命名方式为专有业务场景+专有业务名+具体类名：例：（总部）/In（国内市场）/Rb（生产）注：（公共类库）信息登记、评审、信息共享，命名空间最多三层2. 项目程序文件：项目文件名,以核心功能的英文名称为准,格 式:ECO_英文名词首字母大写 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）根据确定的配置管理计划和相关规定，提交配置项