项目配置管理规范
1
卷号卷内编号密级
分类:
<规范>
使用者:
<项目组、项
目管理部> 文档编号:
?托普信息( iTOP) 集团, 软件配置管理规范
Version 2.1
技术委员会
文档信息
修订文档历史记录
目录
1.简介 (1)
1.1 目的 (1)
1.2 范围 (1)
1.3 文档结构 (1)
1.4 词汇表 (2)
1.5 参考信息 (3)
1.5.1可追溯性 (3)
1.5.2方针 (3)
1.5.3过程/规范 (3)
1.5.4指南 (3)
1.5.5模板 (3)
1.5.6检查表 (4)
1.5.7培训 (4)
1.5.8工具 (4)
1.6 参考网站 (4)
2.配置管理规范 (5)
2.1 配置管理流程图 (5)
2.2 角色 (5)
2.3 进入准则 (6)
2.4 输入 (6)
2.5 活动 (6)
2.6 输出 (7)
2.7 验证与确认 (7)
2.8 退出准则 (8)
2.9 度量 (8)
3.变更控制规范 (9)
3.1 变更控制流程图 (9)
3.2 角色 (11)
3.3 进入准则 (11)
3.4 输入 (11)
3.5 活动 (11)
3.6 输出 (12)
3.7 验证与确认 (12)
3.8 退出准则 (12)
3.9 度量 (12)
4.参考文献 (12)
附录 A –流程框图符号 (13)
附录B文档命名指南 (14)
信息安全管理规范
信息安全管理规范公司
版本信息 修订历史
Table of Contents( 目录) 1. 公司信息安全要求............................................................. 错误!未定义书签。 1.1 信息安全方针 .................................................................... 错误!未定义书签。 1.2 信息安全工作准则 ............................................................ 错误!未定义书签。 1.3 职责 .................................................................................... 错误!未定义书签。 1.4 信息资产的分类规定 ........................................................ 错误!未定义书签。 1.5 信息资产的分级( 保密级别) 规定 ................................... 错误!未定义书签。 1.6 现行保密级别与原有保密级别对照表............................ 错误!未定义书签。 1.7 信息标识与处理中的角色与职责 .................................... 错误!未定义书签。 1.8 信息资产标注管理规定 .................................................... 错误!未定义书签。 1.9 允许的信息交换方式 ........................................................ 错误!未定义书签。 1.10 信息资产处理和保护要求对应表 ................................. 错误!未定义书签。 1.11 口令使用策略 ................................................................. 错误!未定义书签。 1.12 桌面、屏幕清空策略 .................................................... 错误!未定义书签。 1.13 远程工作安全策略 ......................................................... 错误!未定义书签。 1.14 移动办公策略 ................................................................. 错误!未定义书签。 1.15 介质的申请、使用、挂失、报废要求 ...................... 错误!未定义书签。 1.16 信息安全事件管理流程 ................................................. 错误!未定义书签。 1.17 电子邮件安全使用规范 ................................................. 错误!未定义书签。 1.18 设备报废信息安全要求 ................................................. 错误!未定义书签。
软件配置管理规定? 为进一步加强软件配置管理工作,明确软件配置原则,规范软件配置流程，制定本规定。 一、配置原则? 1、软件配置遵循安全性、适用性、 2、单经济性与正版化得原则，不得配置非正版软件。? 位使用得商业软件、OEM软件、免费软件均需纳入配置管理，不得配置与工作无关得各类软件。?3、优先采用场地授权(许可)方式配置软件。 二、配置流程 1、软件使用部门根据本部门各岗位工作需要，编制岗位软件需求清单，填写《软件使用需求申请表》（附件1)。 ２、信息化部门统计、汇总软件使用部门报送得《软件使用需求申请表》,对软件使用部门需要得相关软件进行统一测试与试用，综合考虑软件得价格、兼容性、安全性与售后服务等因素,确定软件选型,明确软件名称与版本.涉及使用免费软件得,更新《可使用免费软件清单》(附件2）。 3、信息化部门依据单位软件使用管理台账,梳理单位软件需求与现有软件许可得差异。单位软件许可不足得，编制《软件采购计划表》（附件3）。 4、财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年
限、兼容性与售后服务等要求。?5、财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作，重点就是软件采购合同、软件授权证书、软件安装序列号等资料得管理工作。? 6、信息化部门负责软件使用管理日常工作。?7、单位采购得软件,因以下情况申请报废得，需经过信息化部门鉴定,严格履行资产处置报批手续：?(１）已经达到规定得最低使用年限,且无法继续使用得.?（２）未达到规定得最低使用年限,因技术进步等原因无法继续使用得。?（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.技术资料（保存项目技术文档，包括第三方技术资料等）
中国移动通信集团吉林有限公司重大业务服务质量事件应急管理办法 V1.0（试行）
中国移动通信集团吉林有限公司 2011年9月
目录 第一章总则 (4) 第二章重大业务服务质量事件的定义及分类 (4) 备注：满足上述任何一个条件，即为相应的预警级别。 (6) 第三章组织机构和工作职责 (6) 第四章重大业务服务质量事件应急处理流程 (9) 第五章重大业务服务质量事件的信息上报与事后改善 (12) 第六章附则 (13)
第一章总则 第一条为加强对全网重大业务服务质量事件的管理，提高相关问题的处理效率，最大程度降低公司的负面影响，根据总部重大业务服务质量事件应急管理办法，制订了《中国移动通信集团重大业务服务质量事件应急管理办法》，用以处理舆情监控、法律诉讼、客户投诉信息中所反映的涉及产品和服务质量、客户权益保护的重要问题，包括与网络质量、增值业务质量、终端质量、收费争议、服务质量、信息安全等相关的短时间全网大范围内的批量客户投诉和媒体重大曝光事件等。 第二条本管理办法适用于规范和指导中国移动吉林公司重大业务服务质量事件的应急处理工作。 第二章重大业务服务质量事件的定义及分类 第三条重大业务服务质量事件是指与产品和服务质量、客户权益保护相关的问题，包括可能或已经对客户感知造成重大负面影响的问题；可能或已经引发媒体大量报道、社会关注、政府干预、诉讼仲裁等严重影响公司正常运营、对公司声誉造成严重负面影响的重大问题；以及由于公司责任可能或已经引发批量客户使用故障的问题。对因自然灾害、社会事件等突发事件引发的应急问题，不纳入该范围内，
均遵照现有的管理办法和流程执行。 第四条重大业务服务质量事件类别 （一）按业务线条分类，重大业务服务质量事件可分为重大网络质量事件、重大业务支撑质量事件、重大增值业务质量事件、重大集团产品质量事件、重大终端质量事件、重大收费争议事件、重大服务质量事件、重大信息安全事件等。 （二）按预警信息来源分类，重大业务服务质量事件可分为总部下发重大业务服务质量事件和省内重大业务服务质量事件两大类。其中省内重大业务服务质量事件信息来源包括舆情通报（综合办公室）、法律诉讼（法律安保部）、重大投诉信息（分公司和省客服中心）和业务风险及故障（各业务管理部门）。 （三）按预警级别分类，重大业务服务质量事件分为红色预警事件、橙色预警事件及黄色预警事件。各级别重大业务服务质量事件判定标准如下： 表－1：重大业务服务质量事件预警级别
软件配置管理规范 流程 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 公文管理办法 （草案） 编制日期 审核日期 批准日期 修订记录 日期修订状态修订内容修订人审核人批准人 公文管理办法 第一章总则 第一条为使东方怡然酒店管理有限公司（以下简称“公司”）的公文处理工作制度化、规范化、科学化，建立规范、严谨、高效的公文处理程序，提高公文处理的效率和公文质量，制定本办法。 第二条公司的公文（包括传真、邮件），是公司在公务来往中形成的具有约束力、体式规范的文书，是维持公司正常运转不可缺少的重要工具。 第三条行政部负责集团公司公文处理和指导所属各企业公文处理工作，负责公文的统一收发、分办、传递、用印、立卷、归档和销毁。第四条公文处理必须做到及时、准确、安全、规范，必须严格执行有关保
密法规，确保国家秘密和公司商业秘密的安全。 第二章公文种类 第五条公司的公文种类主要有12 种，其中包括： （一）命令，适用于公司下达的需按时、按质、按量完成的重大 紧急事项； （二）决议，适用于公司董事会按公司章程决定重大事项，部署公司全局工作； （三）决定，适用于对重要事情或重要行动做出安排，奖惩有关公司及人员，变更或者撤销所属企业不适当的决定事项； （四）通告，适用于公布各有关方面应当遵守或周知的事项； （五）通知，适用于批转所属企业的公文，转发上级机关或不相隶属部门的公文，传达要求所属企业办理和有关企业周知或者要共同执行的事项，任免和聘用人员； （六）通报，适用于表彰先进，批评错误，传达重要精神或情况； 七）报告，适用于向上级机关或其他行业管理部门汇报工 作，反映情况，答复上级部门的询问; （八）请示，适用于向上级机关请求指示、批准； （九）批复，适用于批准所属企业请示的重要事项（不同意用“复函”）；
软件配置管理规范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 目的 本文档指导项目开展配置管理活动。 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角色与职责 2乙方开发内容 2.1乙方开发内容 参考附件一中的功能列表，验收时要包含所列出的所有功能和针对这些功能中双方确认的功能细节，功能的细节是通过交互设计的文档进行补充和双方沟通的方式进行确认。 2.2 版本控制 乙方开发代码统一在甲方的配置管理工具（SVN）平台管理，开发代码调试通过后，乙方开发人员上传到指定的SVN目录，甲方3tiPM指定专人负责代码整合测试。 2.3 交付物管理 交付物清单至少包括：项目开发计划、详细设计文档、开发文档、测试计划、测试用例、测试报告、操作手册、源代码。
计划需要在7月30日前递交给甲方3tiPM，设计文档和测试用例需要在8月10日左右提交，测试报告、源代码需要在8月31日交付，开发和操作文档在9月7日提交。 2.4 里程碑控制 乙方需要在8月15日18:00前提交一个可以测试的迭代版本供甲方公司测试和AR集成。 乙方需要在8月31日交付完整版供甲公司测试。 2.5 沟通计划 甲方3tiPM和乙方承包方PM是双方主要的对口人，所有需要双方沟通的地方都通过双方的PM来沟通。 乙方PM需要每天下班前，以邮件的方式向甲方3tiPM汇报每日的工作进展。 每天早上9:30~10:00，乙方PM和甲方3tiPM进行简短沟通，回顾昨天完成的任务、遇到的问题及解决方案、当天需要完成的任务。 每周双方需组织一次沟通视频或音频会议来沟通项目进度情况和相关问题。 如果项目沟通过程中产生问题和冲突，可以通过双方的上级，也就是甲方3ti的项目总监和乙方的负责人来做进一步沟通。 2.6 应当遵循的标准和规范 乙方必须使用原生的android程序和ios程序开发，不得使用html5等非原生程序。 开发的代码命名应该符合常用的命名规范，所有开发都采用统一的命名规范，并保证可读性。 在一些主要的文件和方法上要加上注释。 开发要尽可能的考虑到代码的抽象和重用。 2.7 缺陷管理 项目系统缺陷管理统一在甲方的缺陷管理工具（JIRA）平台管理。乙方PM在该平台内完成缺陷的分派、跟踪。 2.8 测试标准 2.8.1功能测试 产品功能、界面、逻辑符合开发内容。
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） 在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一
卷号DEPLOY 卷内编号DEPLOY005 密级组内 HD20090917SR005 通用型行政审批服务协同管理平台 配置管理计划 1.2 项目承担部门：java第四组 撰写人（签名）：区允文 完成日期：2010年8月4日 本文档使用部门：■主管领导■项目组 □客户（市场）□维护人员□用户 评审负责人（签名）：江威龙 评审日期：2010/8/4
目录 1.简介4 1.1目的4 1.2范围4 1.3定义、首字母缩写词和缩略语4 1.4参考资料4 1.5概述4 2.项目配置4 2.1组织结构4 2.2职责和接口5 2.3工具、环境和基础设施5 3.配置管理活动6
3.1配置库6 3.1.1配置库架构6 3.1.2权限分配7 3.1.3配置库层次及开发活动说明：8 3.2配置标识9 3.2.1标识方法9 3.2.2项目基线10 3.3配置项11 3.4配置和变更控制11 3.4.1变更请求的处理和审批11 3.4.2变更控制委员会 (CCB)11 3.4.3变更过程中的活动11 3.4.4变更过程中的变更请求状态12 3.4.5保存变更历史记录13 3.4.6变更请求中受影响配置项的变更13 3.5配置状态统计14 3.5.1项目介质存储和发布进程14 3.5.2报告和审计14 4.里程碑15 5.培训和资源15 6.分包商和厂商软件控制15 7.附录15
配置管理计划 1.简介 1.1目的 为了使项目相关的各种资源便于查看，修改，不至于凌乱；为了让各个开发人员方便高效地协同合作；为了项目的版本便于管理，作出此配置管理计划。 1.2范围 项目进行中所得出的所有工件都要遵守此计划，包括文档以及源代码，以及硬件。 1.3定义、首字母缩写词和缩略语 CM：配置管理。 CCB：变更控制委员会。 CI：配置项。包含文档、程序。 Baseline：基线。 CR：变更请求。 PCA：物理审计。 FCA：功能审计。 1.4参考资料 《华南农业大学软件学院实训讲义》 《华南农业大学项目阶段评审工件》 1.5概述 此文档对项目开发过程中的配置方面作出约束，开发以及变更都要按照要求来做。 2.项目配置 2.1组织结构
管理制度完整版 1
第一章考勤管理制度 一、工作时间管理规定: 1、①办公室实行每周六天工作制,星期一至星期五为正常上班,星期六星期日为轮班调休时间,如有紧急任务或临时突发任务,应服从公司的安排,如不能到岗未得到领导批准的给予处罚。 ②生产车间员工每月休息两天,休息时间由部门主管安排,如有赶制订单任务或临时突发任务需要加班应服从领导的安排,如不能到岗未得到领导批准的给予处罚,如果因生产需要未安排休息时间,将依照考勤工资平均基数给予补发工资 2、公司实行作息时间: 夏令时上午7: 30----11: 30 下午2: 00----6: 00 冬令时上午8: 00----12: 00 下午1: 30----5: 30 3、加班规定; 主管以上管理人员为义务加班,所有人员加班考勤以考勤打卡结合车间手工考勤为依据。夜间加班时间定为:18: 30-----22: 00按季调整加班时间, 有特殊赶制任务的按主管通知执行。夜间加班时间满三个半小时,按半天工时计算加班工资, 不满三个半小时的按小时数计算加班工资,加班工资按工资的平均基数计算。通霄加班的第二天予以补休一天。加班至夜间零点以后凌晨二点以前的夜霄补贴6元, 加班至四点的夜霄予以补贴8元。至次日六点的予以10元补贴。 二、考勤方式: 1、员工上下班实行考勤打卡和查岗相结合的考勤管理办法,
各部门负责人负责监督人员到岗情况。工作期间未说明原因脱离岗位超过十分钟的按脱离岗位予以处罚, 每次十元。为了节省时间提高工作效率,允许办完事后再回公司打卡,考勤卡经部门主管确认后签字认可,未经主管签字的一律按旷工半天处理每次, 车间主管及后勤全体人员一律交由行政部签字确认。公司员工外出学习或借调外出的, 需要部门主管同意后将情况报备人事部。厂内车间互相借调的按正常考勤打卡。 2、打卡考勤管理规定: 员工考勤打卡由当班门卫负责监督,任何人等不得代替打卡,如有违反发现一次, 打卡人与代打卡人分别给予第一次三十元处罚。第二次处以五十元处罚。第三次处以一百元处罚。情节恶劣的予以辞退。当班门卫监督不力负连带责任每次处罚三十元。 3、考勤机管理,若考勤机遭到人为破坏追究当事人责任, 设备维修或购新机费用由当事人承担, 并视情节轻重予以五十至一百元处罚。考勤卡由当班门卫负责保管, 若出现遗失由当班门卫承担责任给予三十元处罚每次。若出现停电等突发事件, 由主管负责手工考勤。 三、请假管理制度: 公司严格执行请假管理制度,员工不得无故缺勤,病事假等应事先办理请假手续,经批准后方可给予各种假期,未经批准擅自休假一律按旷工处理,若因特殊情况确实无法事先请假的或假期已满无法准时返岗的,必须联系直属主管说明情况由主管报备人事部后予以续准。上班后第一天应立即补办相关手续, 否则按旷工处理。
软件配置管理规定 为进一步加强软件配置管理工作，明确软件配置原则，规范软件配置流程，制定本规定。 一、配置原则 1.软件配置遵循安全性、适用性、经济性和正版化的原则，不得配置非正版软件。 2.单位使用的商业软件、OEM软件、免费软件均需纳入配置管理，不得配置与工作无关的各类软件。 3.优先采用场地授权（许可）方式配置软件。 二、配置流程 1.软件使用部门根据本部门各岗位工作需要，编制岗位软件需求清单，填写《软件使用需求申请表》（附件1）。 2.信息化部门统计、汇总软件使用部门报送的《软件使用需求申请表》，对软件使用部门需要的相关软件进行统一测试和试用，综合考虑软件的价格、兼容性、安全性和售后服务等因素，确定软件选型，明确软件名称和版本。涉及使用免费软件的，更新《可使用免费软件清单》（附件2）。 3.信息化部门依据单位软件使用管理台账，梳理单位软件需求与现有软件许可的差异。单位软件许可不足的，编制《软件采购计划表》（附件3）。
4.财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年限、兼容性和售后服务等要求。 5.财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作，重点是软件采购合同、软件授权证书、软件安装序列号等资料的管理工作。 6.信息化部门负责软件使用管理日常工作。 7.单位采购的软件，因以下情况申请报废的，需经过信息化部门鉴定，严格履行资产处置报批手续：（1）已经达到规定的最低使用年限，且无法继续使用的。 （2）未达到规定的最低使用年限，因技术进步等原因无法继续使用的。 （3）未达到规定的最低使用年限，因计算机硬件报废，且无法迁移到其他计算机上继续使用的。 8.信息化部门在单位新采购软件、报废软件和调整可使用免费软件清单后，更新《软件使用情况汇总表》（附件4）。
软件配置管理规范精编 W O R D版 IBM system office room 【A0816H-A0912AAAHH-GX8Q8-GNTHHJ8】
软件配置管理规范 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)
机电管理系统性能测试系统 配置管理计划
这里填写公司名称 文档编号：XXXXXXXX-XXX-XXX 版本号：1.00 产品名称:机电管理系统性能测试系统 文档名称:配置管理计划 这里填写公司地址、联系方式等
目录 1. 引言 (1) 1.1 目的 (1) 1.2 术语定义 (1) 1.3 参考资料 (1) 2. 软件配置 (2) 2.1 软件配置环境 (2) 2.2 软件配置项 (2) 2.3 配置管理员 (3) 3. 软件配置管理计划 (4) 3.1 建立示例配置库 (4) 3.2 配置标识管理 (6) 3.3 配置库控制 (7) 3.4 配置的检查和评审 (8) 3.5 配置库的备份 (9) 3.6 配置管理计划的修订 (9) 3.7 配置管理计划附属文档 (9) 4. 里程碑 (11) 附录1 文档命名规定 (12) 1、受控配置库文件命名规则 (12) 2、非受控配置库文件命名规则 (12) 3、提交文档文件命名规则 (12) 附录2文档编码规范 (13) 附录3 帐号及权限管理 (14) 附录4 配置库使用规定 (16) 文档修改记录 (17)
1. 引言 1.1 目的 本文档目的在于机电管理系统性能测试系统进行软件配置管理，提高软件质量，降低软件开发成本。 本文档内容主要参考研发中心相关的ISO程序和制度文档，并在这基础上整理成适合本项目的软件配置管理，为项目经理、配置管理员及相关人员提供日常的配置管理操作步骤。 1.2 术语定义 软件配置管理：简称SCM（Software Configuration Management的缩写），是在项目开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。软件的规模越大，配置管理就显得越重要。 基线：(BaseLine) 是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。 配置管理员：项目组中负责配置管理工作的角色，该角色可以兼职。在某一开发阶段通过评审或某一质量检查点通过审核后，配置管理员负责统一添加或修改相关文档的最新有效版本以及审批人签字。 配置标识：（Configuration Identification）对软件项目在开发过程中的资源进行标识，以便识别。 配置检查：（Configuration Audit）对软件配置管理过程中的行动进行检查。 1.3 参考资料 《研发中心配置管理制度》 《产品的标识与可追溯性程序》 《开发手册》
工装管理规范 1 目的 减少工艺装备（以下简称”工装” ）的使用损耗, 提高工装的使用效率和使用周期, 明确工装管理职责和细则, 规范工装的需求、设计、审核、制作、采购、使用、维护和报废等管理。 2 定义和适用范围 2.1 工装分为二大类: 产品工装和辅助工装 2.1.1 产品工装 是指在冰箱产品生产中, 为保证冰箱满足设计质量和尺寸等要求所使用的如衬模等的工装（不包括相关模具和新品试制过程中的临时工装）。 产品工装能够细分为: 专用工装和通用工装二类。 专用工装: 指在某一系列型号产品的装配上使用的工装（证冰箱门体和箱体发泡质量等要求与发泡模具配套使用的衬模等） ; 通用工装: 指在多系列型号产品的装配上都能够使用的工装; 2.1.2 辅助工装 是指在生产现场中各工序用以存放冰箱零部件、原材料或生产工具以及冰箱转运的各种装置和辅助性器具; 当前的辅助工装包括: 物料架、工作台、物料小车、椅子、脚踏板、工具柜六类; 2.2 本规范适用于冰箱事业部各生产单位的工装。各子公司可参照执行。
3 职责 3.1 工程院: 负责对工装需求的管理和审核, 负责工装的技术管理和质量管理负责工 装总台账的管理, 负责工装报废的审核工作。工程院木工房负责自制工装的制作; 3.2 各使用单位: 负责工装的使用、实物报废以及维护保管、工装分台账等日常管理工作; 3.3 物资采购部: 负责工装的委外加工、招标、核价和工装验收的组织工作。 4 管理流程图
工 求 需 5内容
5.1 工装的需求提出 5.1.1 新建厂房的工装根据新厂房生产线的产品生产以及工艺布局规划要求由工程院 或项目组提出相关需求; 5.1.2 新品生产所需工装由工程院工艺所根据产品工艺提出相关需求; 5.1.3 由于使用损耗产量增加等原因导致的工位器具需求由使用单位经过申 请、报告等形式提出需求; 5.1.4 所有需求除非有专项立项报告外, 均经过《工装需求报告》的形式提出; 5.1.5 需大批量制作的工装, 提交需求申请时应有相关的效益分析报告。 5.2 工装的设计 5.2.1 工装设计由工程院归口管理, 分为自主设计和委外设计二类。 5.2.2 对于需要委外设计的工装, 由工程院装备所编制相关《技术协议》, 提出详细 需求, 委外进行设计, 委外设计的单位应提供相关电子版图纸; 5.2.3 工装自主设计由工程院工艺所负责; 5.2.4 所有工装应按照《工装设计规范》的要求进行设计并归档; 5.3 工装的设计评审 5.3.1 新设计的的工装必须经过设计评审后才能够实施制作; 5.3.2 委外设计工装经过对《技术协议》进行讨论会签的方式实施评审; 5.3.3 工程院设计的工装图纸由相关工艺人员、产品项目经理（如涉及到具体产 品）和使用单位进行评审; 5.3.4 对于需求数量小于3 件（包括3 件）的工装评审可经过图纸会签, 需求数 量大于 3 件的工装除了图纸会签外, 应经过制作试用件试用验证的方式进行评审; 5.3.5 所有新设计的工装应在试用验证后才能够全面推广使用
软件配置管理规范 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. 目的 2. 适用范围 3. 术语和缩略语 4. 规范内容 5. 引用文件
1.目的 指导配置管理人员如何建立配置库，并利用配置库管理所有配置项，从而提供配置项的存取和检索功能，有利于配置项的更改控制，保证配置项的完整性和可跟踪性。 2.适用范围 适用于所有软件产品和软件项目的配置项管理。配置管理可采用各种工具及手工办法，本文件以Source safe配置管理工具为例，规定公司的配置管理办法，使用其他工具时也可对应本文件的要求参照执行。 3.术语和缩略语 本文件采用NP601100《配置管理》程序使用的术语和缩略语的定义。 4.规范内容 4.1 配置管理的范围 软件配置可包括以下几方面：项目文档，源代码，执行程序，相关设备及资料等。 1）项目文档主要指：立项建议报告、项目启动计划、可行性分析报告、开发计划、需求分析报告、软件功能规格说明书、系统设计报告、数据库表结构、 技术报告、总结报告、验收报告以及上述文档的评审记录。 2）相关设备主要指项目开发和运行环境（包括硬件和软件），以及项目开发和测试过程中使用的专用仪器设备，如读卡机、扫描仪等。 3）相关资料主要指客户提供的行业法规，标准及其调研期间提供的业务单据，往来会议记要，传真，电子邮件，重要的电话记录等。 4.2 各配置项的获得 项目立项之后，软件配置管理负责人SCML即可建立项目配置库，并着手收集各配置项。 1）项目文档。开发各阶段结束时，软件配置管理负责人SCML可向开发人员索要相关文档及对应评审记录，归到配置库。 2）开发人员在出差前应带好与客户会谈的准备材料。根据出差的任务不同，还应准备客满意度调查表，交付书，验收报告等。返回之前应和客户确认，并 在出差回来时交给软件配置管理负责人SCML一份备份，如有客户提供的文
配置管理计划配置管理计划的案例 配置管理计划来自：://.chinaspis. 作者：林锐电子工业出版社出版发行 { 项目名称 } 配置管理计划文状态： [√] 草稿 [ ] 正式发布 [ ] 正在修改文标识： pany-Project-CM-PLAN 当前版本： X.Y 作者： 完成日期： Year-Month-Day 版本历史版本/状态作者参与者起止日期备注 目录 1.人员及职责 2.配置管理软硬资源 3.配置项计划 4.基线计划 5.配置库备份计划 附录：本计划审批意见 1.人员及职责 提示： （1）根据《项目计划》中的角色分配，确定配置管理员，CCB（配置控制委员会）成员。
（2）CCB的人数根据项目规模而定。一般地，项目经理是CCB的负责人。 角色人员职责、工作范围 配置管理员 （1）制定《配置管理计划》 （2）创建和维护配置库 CCB负责人 （1）审批《配置管理计划》 （2）审批重大的变更 CCB成员例如：审批某些配置项或基线的变更… 2.用于配置管理的软硬资源 提示： （1）配置管理员确定本项目的配置管理软。例如采用Microsoft公司的Visual SourceSafe或者Rationa公司的l ClearCase。 （2）配置管理员根据所采用的配置管理软，确定计算机资源（考虑内存、外存、CPU等）。 配置管理软硬资源说明配置管理软名称公司，软版本等计算机名称内存、外存、CPU等3.配置项计划 提示：配置管理员标识配置项，估计每个配置项的正式发布时间。标识符的参考格式为Project-Type…Type-Number。例如：类型主要配置项标识符预计正式发表时间计划 《项目计划》