建设工程项目管理规范
建设工程项目管理规范GB/T 50326-2006
建设工程项目管理规范
中华人民共和国国家标准
GB/T 50326-2006
━━━━━━━━━━━━━━━━━━
建设工程项目管理规范
The code of construction project management
2006-06-21发布2006-12-01实施
中华人民共和国建设部
联合发布
国家质量监督检验检疫总局
目次
1 总则
2 术语
3 项目范围管理
3.1 一般规定
3.2 项目范围确定
3.3 项目结构分析
3.4 项目范围控制
4 项目管理规划
4.1 一般规定
4.2 项目管理规划大纲
4.3 项目管理实施规划
5 项目管理组织
5.1 一般规定
5.2 项目经理部
5.3 项目团队建设
6.1 一般规定
6.2 项目经理
6.3 项目管理目标责任书
6.4 项目经理的责、权、利
7 项目合同管理
7.1 一般规定
7.2 项目合同评审
7.3 项目合同实施计划
7.4 项目合同实施控制
7.5 项目合同终止和评价
8 项目采购管理
8.1 一般规定
8.2 项目采购计划
8.3 项目采购控制
9 项目进度管理
9.1 一般规定
9.2 项目进度计划编制
9.3 项目进度计划实施
9.4 项目进度计划的检查与调整
10 项目质量管理
10.1 一般规定
10.2 项目质量策划
10.3 项目质量控制与处置
10.4项目质量改进
11 项目职业健康安全管理
11.1 一般规定
11.2 项目职业健康安全技术措施计划
11.3 项目职业健康安全技术措施计划的实施11.4 项目职业健康安全隐患和事故处理
11.5 项目消防保安
12 项目环境管理
12.1 一般规定
12.2 项目文明施工
12.3 项目现场管理
13 项目成本管理
13.1 一般规定
13.2 项目成本计划
13.4 项目成本核算
13.5 项目成本分析与考核
14 项目资源管理
14.1 一般规定
14.2 项目资源管理计划
14.3 项目资源管理控制
14.4 项目资源管理考核
15 项目信息管理
15.1 一般规定
15.2 项目信息管理计划与实施
15.3 项目信息安全
16 项目风险管理
16.1 一般规定
16.2 项目风险识别
16.3 项目风险评估
16.4 项目风险响应
16.5 项目风险控制
17 项目沟通管理
17.1 一般规定
17.2 项目沟通程序和内容17.3 项目沟通计划
17.4 项目沟通依据与方式
17.5 项目沟通障碍与冲突管理
18 项目收尾管理
18.1 一般规定
18.2 项目竣工收尾
18.3 项目竣工验收
18.4 项目竣工结算
18.5 项目竣工决算
18.6 项目回访保修
18.7 项目管理考核评价
规范用词说明
1 总则
1.0.1 为提高建设工程项目管理水平，促进建设工程项目管理的科学化、规范化、制度化和国际化，制定本规范。
1.0.2 本规范适用于新建、扩建、改建等建设工程有关各方的项目管理。
1.0.3 本规范是建立项目管理组织、明确企业各层次和人员的职责与工作关系，规范项目管理行为，考核和评价项目管理成果的基本依据。
1.0.4 建设工程项目管理应坚持自主创新，采用先进的管理技术和现代化管理手段。
1.0.5 建设工程项目管理应坚持以人为本和科学发展观，全面实行项目经理责任制，不断改进和提高项目管理水平，实现可持续发展。
1.0.6 建设工程项目管理除应遵循本规范外，还应符合国家法律、法规及有关技术标准的规定。
2 术语
2.0.1 建设工程项目（construction project）
为完成依法立项的新建、扩建、改建等各类工程而进行的、有起止日期的、达到规定要求的一组相互关联的受控活动组成的特定过程，包括策划、勘察、设计、采购、施工、试运行、竣工验收和考核评价等。简称为项目。
2.0.2 建设工程项目管理(construction project management)
运用系统的理论和方法，对建设工程项目进行的计划、组织、指挥、协调和控制等专业化活动。简称为项目管理。
2.0.3 项目发包人（project employer）
按招标文件或合同中约定、具有项目发包主体资格和支付合同价款能力的当事人以及取得该当事人资格的合法继承人。简称为发包人。
2.0.4 项目承包人(project contractor)
按合同中约定、被发包人接受的具有项目承包主体资格的当事人，以及取得该当事人资格的合法继承人。简称为承包人。
2.0.5 项目承包(project contracting)
受发包人的委托，按照合同约定，对工程项目的策划、勘察、设计、采购、施工、试运行等实行全过程或分阶段承包的活动。简称为承包。
2.0.6 项目分包（project subcontracting）
承包人将其承包合同中所约定工作的一部分发包给具有相应资质的企业承担。简称为分包。
2.0.7 项目范围管理(project scope management)
对合同中约定的项目工作范围进行的定义、计划、控制和变更等活动。
2.0.8 项目管理目标责任书(document of project management responsibility)
企业的管理层与项目经理部签订的明确项目经理部应达到的成本、质量、工期、安全和环境等管理目标及其承担的责任，并作为项目完成后考核评价依据的文件。
2.0.9 项目管理组织(organization of project management)
实施或参与项目管理工作，且有明确的职责、权限和相互关系的人员及设施的集合。包括发包人、承包人、分包人和其他有关单位为完成项目管理目标而建立的管理组织。简称为组织。
2.0.10 项目经理(project manager)
企业法定代表人在建设工程项目上的授权委托代理人。
2.0.11 项目经理部（或项目部）(project management team)
由项目经理在企业法定代表人授权和职能部门的支持下按照企业的相关规定组建的、进行项目管理的一次性的现场组织机构。
2.0.12 项目经理责任制(responsibility system of project manager)
企业制定的、以项目经理为责任主体，确保项目管理目标实现的责任制度。
2.0.13 项目进度管理(project progress management)
为实现预定的进度目标而进行的计划、组织、指挥、协调和控制等活动。
2.0.14 项目质量管理(project quality management)
为确保工程项目的质量特性满足要求而进行的计划、组织、指挥、协调和控制等活动。
2.0.15 项目职业健康安全管理(project occupationl health and safety management)
为使项目实施人员和相关人员规避损害或影响健康风险而进行的计划、组织、指挥、协调和控制等活动。
2.0.16 项目环境管理(project environment management)
为合理使用和有效保护现场及周边环境而进行的计划、组织、指挥、协调和控制等活动。
2.0.17 项目成本管理(project cost management)
为实现项目成本目标所进行的预测、计划、控制、核算、分析和考核等活动。
2.0.18 项目采购管理(project procurement management)
对项目的勘察、设计、施工、资源供应、咨询服务等采购工作进行的计划、组织、指挥、协调和控制等活动。
2.0.19 项目合同管理(project contract management)
对项目合同的编制、签订、实施、变更、索赔和终止等的管理活动。
2.0.20 项目资源管理(project resources management)
对项目所需人力、材料、机具、设备、技术和资金所进行的计划、组织、指挥、协调和控制等活动。
2.0.21 项目信息管理(project information management)
对项目信息进行的收集、整理、分析、处置、储存和使用等活动。
2.0.22 项目风险管理(project risk management)
对项目的风险所进行的识别、评估、响应和控制等活动。
2.0.23 项目沟通管理(project communication management)
对项目内、外部关系的协调及信息交流所进行的策划、组织和控制等活动。
2.0.24 项目收尾管理(project closing stage management)
对项目的收尾、试运行、竣工验收、竣工结算、竣工决算、考核评价、回访保修等进行的计划、组织、协调和控制等活动。
3 项目范围管理
3.1 一般规定
3.1.1 项目范围管理应以确定并完成项目目标为根本目的，通过明确项目有关各方的职责界限，以保证项目管理工作的充分性和有效性。
3.1.2 项目范围管理的对象应包括为完成项目所必需的专业工作和管理工作。
3.1.3 项目范围管理的过程应包括项目范围的确定、项目结构分析、项目范围控制等。
3.1.4 项目范围管理应作为项目管理的基础工作，并贯穿于项目的全过程。组织应确定项目范围管理的工作职责和程序，并对范围的变更进行检查、分析和处置。
3.2 项目范围确定
3.2.1 项目实施前，组织应明确界定项目的范围，提出项目范围说明文件，作为进行项目设计、计划、实施和评价的依据。
3.2.2 确定项目范围应主要依据下列资料：
1 项目目标的定义或范围说明文件。
2 环境条件调查资料。
3 项目的限制条件和制约因素。
4 同类项目的相关资料。
3.2.3 在项目的计划文件、设计文件、招标文件和投标文件中应包括对工程项目范围的说明。
3.3 项目结构分析
3.3.1 组织应根据项目范围说明文件进行项目的结构分析。项目结构分析应包括下列内容：
1 项目分解。
2 工作单元定义。
3 工作界面分析。
3.3.2 项目应逐层分解至工作单元，形成树形结构图或项目工作任务表，进行编码。
3.3.3 项目分解应符合下列要求：
1 内容完整，不重复，不遗漏。
2 一个工作单元只能从属于一个上层单元。
3 每个工作单元应有明确的工作内容和责任者，工作单元之间的界面应清晰。
4 项目分解应有利于项目实施和管理，便于考核评价。
3.3.4 工作单元应是分解结果的最小单位，便于落实职责、实施、核算和信息收集等工作。
3.3.5 工作界面分析应达到下列要求：
1 工作单元之间的接口合理，必要时应对工作界面进行书面说明。
2 在项目的设计、计划和实施中，注意界面之间的联系和制约。
3 在项目的实施中应注意变更对界面的影响。
3.4 项目范围控制
3.4.1 组织应严格按照项目的范围和项目分解结构文件进行项目的范围控制。
3.4.2 组织在项目范围控制中，应跟踪检查，记录检查结果，建立文档。
3.4.3 组织在进行项目范围控制中，应判断工作范围有无变化，对范围的变更和影响进行分析与处理。
3.4.4 项目范围变更管理应符合下列要求：
1 项目范围变更要有严格的审批程序和手续。
2 范围变更后应调整相关的计划。
3 组织对重大的项目范围变更,应提出影响报告。
3.4.5 在项目的结束阶段，应验证项目范围，检查项目范围规定的工作是否完成和交付成果是否完备。
3.4.6 项目结束后，组织应对项目范围管理的经验教训进行总结。
4 项目管理规划
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 编制项目管理规划大纲应遵循下列程序：
1 明确项目目标。
2 分析项目环境和条件。
3 收集项目的有关资料和信息。
4 确定项目管理组织模式、结构和职责。
5 明确项目管理内容。
6 编制项目目标计划和资源计划。
7 汇总整理，报有关部门审批。
4.2.3 项目管理规划大纲可依据下列资料编制：
1 可行性研究报告。
2 设计文件、标准、规范与有关规定。
3 招标文件及有关合同文件。
4 相关市场信息与环境信息。
4.2.4 项目管理规划大纲可包括下列内容，组织应根据需要选定：
1 项目概况。
2 项目范围管理规划。
3 项目管理目标规划。
4 项目管理组织规划。
5 项目成本管理规划。
6 项目进度管理规划。
7 项目质量管理规划。
8 项目职业健康安全与环境管理规划。
9 项目采购与资源管理规划
10 项目信息管理规划。
11 项目沟通管理规划。
12 项目风险管理规划。
13 项目收尾管理规划。
4.3 项目管理实施规划
4.3.1 项目管理实施规划应对项目管理规划大纲进行细化，使其具有可操作性。
4.3.2 编制项目管理实施规划应遵循下列程序：
1 了解项目相关各方的要求。
2 分析项目条件和环境。
3 熟悉相关的法规和文件。
4 组织编制。
5 履行报批手续。
4.3.3 项目管理实施规划可依据下列资料编制：
1 项目管理规划大纲。
2 项目条件和环境分析资料。
3 工程合同及相关文件。
4 同类项目的相关资料。
4.3.4 项目管理实施规划应包括下列内容：
1 项目概况。
2 总体工作计划。
3 组织方案。
4 技术方案。
5 进度计划。
6 质量计划。
7 职业健康安全与环境管理计划。
8 成本计划。
9 资源需求计划。
10 风险管理规划。
11 信息管理计划。
12 项目沟通管理计划。
13 项目收尾管理计划。
14 项目现场平面布置图。
15 项目目标控制措施。
16 技术经济指标。
4.3.5 项目管理实施规划应符合下列要求：
1 项目经理签字后报组织管理层审批。
2 与各相关组织的工作协调一致。
3 进行跟踪检查和必要的调整。
4 项目结束后，形成总结文件。
5 项目管理组织
5.1 一般规定
5.1.1 项目管理组织的建立应遵循下列原则：
1 组织结构科学合理。
2 有明确的管理目标和责任制度。
3 组织成员具备相应的职业资格。
4 保持相对稳定，并根据实际需要进行调整。
5.1.2 组织应确定各相关项目管理组织的职责、权利、利益和应承担的风险。
5.1.3 组织管理层应按项目管理目标对项目进行协调和综合管理。
5.1.4 组织管理层的项目管理活动应符合下列规定：
1 制定项目管理制度。
2 实施计划管理，保证资源的合理配置和有序流动。
3 对项目管理层的工作进行指导、监督、检查、考核和服务。
5.2 项目经理部
5.2.1 项目经理部是组织设置的项目管理机构，承担项目实施的管理任务和目标实现的全面责任。
5.2.2 项目经理部由项目经理领导，接受组织职能部门的指导、监督、检查、服务和考核，并负责对项目资源进行合理使用和动态管理。
5.2.3 项目经理部应在项目启动前建立，并在项目竣工验收、审计完成后或按合同约定解体。
5.2.4 建立项目经理部应遵循下列步骤：
1 根据项目管理规划大纲确定项目经理部的管理任务和组织结构。
2 根据项目管理目标责任书进行目标分解与责任划分。
3 确定项目经理部的组织设置。
4 确定人员的职责、分工和权限。
5 制定工作制度、考核制度与奖惩制度。
5.2.5 项目经理部的组织结构应根据项目的规模、结构、复杂程度、专业特点、人员素质和地域范围确定。
5.2.6 项目经理部所制订的规章制度，应报上一级组织管理层批准。
5.3 项目团队建设
5.3.1 项目组织应树立项目团队意识，并满足下列要求：
1 围绕项目目标而形成和谐一致、高效运行的项目团队。
2 建立协同工作的管理机制和工作模式。
3 建立畅通的信息沟通渠道和各方共享的信息工作平台，保证信息准确、及时和有效地传递。
5.3.2 项目团队应有明确的目标、合理的运行程序和完善的工作制度。
5.3.3 项目经理应对项目团队建设负责，培育团队精神，定期评估团队运作绩效，有效发挥和调动各成员的工作积极性和责任感。
5.3.4 项目经理应通过表彰奖励、学习交流等多种方式和谐团队氛围，统一团队思想，营造集体观念，处理管理冲突，提高项目运作效率。
5.3.5 项目团队建设应注重管理绩效，有效发挥个体成员的积极性，并充分利用成员集体的协作成果。
6 项目经理责任制
6.1 一般规定
6.1.1 项目经理责任制应作为项目管理工作的基本制度，是评价项目经理绩效的依据。
6.1.2 项目经理责任制的核心是项目经理承担实现项目管理目标责任书确定的责任。
6.1.3 项目经理与项目经理部在工程建设中应严格遵守和实行项目管理责任制度，确保项目目标全面实现。
6.2 项目经理
6.2.1 项目经理应由法定代表人任命，并根据法定代表人授权的范围、期限和内容，履行管理职责，并对项目实施全过程、全面管理。
6.2.2 大中型项目的项目经理必须取得工程建设类相应专业注册执业资格证书。
6.2.3 项目经理应具备下列素质：
1 符合项目管理要求的能力,善于进行组织协调与沟通。
2 相应的项目管理经验和业绩。
3 项目管理需要的专业技术、管理、经济、法律和法规知识。
4 良好的职业道德和团队协作精神，遵纪守法、爱岗敬业、诚信尽责。
5 身体健康。
6.2.4 项目经理不应同时承担两个或两个以上未完项目领导岗位的工作。
6.2.5 在项目运行正常的情况下，组织不得随意撤换项目经理。特殊原因需要撤换项目经理时，应进行审计并按有关合同规定报告相关方。
6.3 项目管理目标责任书
6.3.1 项目管理目标责任书应在项目实施之前，由法定代表人或其授权人与项目经理协商制定。
6.3.2 编制项目管理目标责任书应依据下列资料：
1 项目合同文件。
2 组织的管理制度。
3 项目管理规划大纲。
4 组织的经营方针和目标。
6.3.3 项目管理目标责任书可包括下列内容：
1 项目管理实施目标。
2 组织与项目经理部之间的责任、权限和利益分配。
3 项目设计、采购、施工、试运行等管理的内容和要求。
4 项目需用资源的提供方式和核算办法。
5 法定代表人向项目经理委托的特殊事项。
6 项目经理部应承担的风险。
7 项目管理目标评价的原则、内容和方法。
8 对项目经理部进行奖惩的依据、标准和办法。
9 项目经理解职和项目经理部解体的条件及办法。
6.3.4 确定项目管理目标应遵循下列原则：
1 满足组织管理目标的要求。
2 满足合同的要求。
3 预测相关的风险。
4 具体且操作性强。
5 便于考核。
6.3.5 组织应对项目管理目标责任书的完成情况进行考核，根据考核结果和项目管理目标责任书的奖惩规定，提出奖惩意见，对项目经理部进行奖励或处罚。
6.4 项目经理的责、权、利
6.4.1 项目经理应履行下列职责：
1 项目管理目标责任书规定的职责。
2 主持编制项目管理实施规划，并对项目目标进行系统管理。
3 对资源进行动态管理。
4 建立各种专业管理体系并组织实施。
5 进行授权范围内的利益分配。
6 归集工程资料，准备结算资料，参与工程竣工验收。
7 接受审计，处理项目经理部解体的善后工作。
8 协助组织进行项目的检查、鉴定和评奖申报工作。
6.4.2 项目经理应具有下列权限：
1 参与项目招标、投标和合同签订。
2 参与组建项目经理部。
3 主持项目经理部工作。
4 决定授权范围内的项目资金的投入和使用。
5 制定内部计酬办法。
6 参与选择并使用具有相应资质的分包人。
7 参与选择物资供应单位。
8 在授权范围内协调与项目有关的内、外部关系。
9 法定代表人授予的其它权力。
6.4.3 项目经理的利益与奖罚：
1 获得工资和奖励。
2 项目完成后，按照项目管理目标责任书规定，经审计后给予奖励或处罚。
3 获得评优表彰、记功等奖励。
7 项目合同管理
7.1 一般规定
7.1.1 组织应建立合同管理制度，应设立专门机构或人员负责合同管理工作。
7.1.2 合同管理应包括合同的订立、实施、控制和综合评价等工作。
7.1.3 承包人的合同管理应遵循下列程序：
1 合同评审。
2 合同订立。
3 合同实施计划。
4 合同实施控制。
5 合同综合评价。
6 有关知识产权的合法使用。
7.2 项目合同评审
7.2.1 合同评审应在合同签订之前进行，主要是对招标文件和合同条件进行的审查、认定和评价。
7.2.2 合同评审应包括下列内容：
1 招标内容和合同的合法性审查。
2 招标文件和合同条款的合法性和完备性审查。
3 合同双方责任、权益和项目范围认定。
4 与产品或过程有关要求的评审。
5 合同风险评估。
7.2.3 承包人应研究合同文件和发包人所提供的信息，确保合同要求得以实现；发现问题应与发包人及时澄清，并以书面方式确定；承包人应有能力完成合同要求。
7.3 项目合同实施计划
7.3.1 合同实施计划应包括合同实施总体安排，分包策划以及合同实施保证体系的建立等内容。
7.3.2 合同实施保证体系应与其他管理体系协调一致，须建立合同文件沟通方式，编码系统和文档系统。承包人应对其同时承接的合同作总体协调安排。承包人所签订的各分
包合同及自行完成工作责任的分配，应能涵盖主合同的总体责任，在价格、进度、组织等方面符合主合同的要求。
7.3.3 合同实施计划应规定必要的合同实施工作程序。
7.4 项目合同实施控制
7.4.1 合同实施控制包括合同交底、合同跟踪与诊断、合同变更管理和索赔管理等工作。
7.4.2 在合同实施前，合同谈判人员应进行合同交底。合同交底应包括合同的主要内容、合同实施的主要风险、合同签订过程中的特殊问题、合同实施计划和合同实施责任分配等内容。
7.4.3 组织管理层应监督项目经理部的合同执行行为，并协调各分包人的合同实施工作。
7.4.4 进行合同跟踪和诊断应符合下列要求：
1 全面收集并分析合同实施的信息，将合同实施情况与合同实施计划进行对比分析，找出其中的偏差。
2 定期诊断合同履行情况，诊断内容应包括合同执行差异的原因分析、责任分析以及实施趋向预测。应及时通报合同实施情况及存在问题，提出合有关意见和建议，并采取相应措施。
7.4.5 合同变更管理应包括变更协商、变更处理程序、制定并落实变更措施、修改与变更相关的资料以及结果检查等工作。
7.4.6 承包人对发包人、分包人、供应单位之间的索赔管理工作应包括下列内容：
1 预测、寻找和发现索赔机会。
2 收集索赔的证据和理由，调查和分析干扰事件的影响，计算索赔值。
3 提出索赔意向和报告。
7.4.7 承包人对发包人、分包人、供应单位之间的反索赔管理工作应包括下列内容：
1 对收到的索赔报告进行审查分析，收集反驳理由和证据，复核索赔值，起草并提出反索赔报告。
2 通过合同管理，防止反索赔事件的发生。
7.5 项目合同终止和评价
7.5.1 合同履行结束即合同终止。组织应及时进行合同评价，总结合同签订和执行过程中的经验教训，提出总结报告。
7.5.2 合同总结报告应包括下列内容：
1 合同签订情况评价。
2 合同执行情况评价。
3 合同管理工作评价。
4 对本项目有重大影响的合同条款的评价。
5 其他经验和教训。
8 项目采购管理
8.1 一般规定
8.1.1 组织应设置采购部门，制定采购管理制度、工作程序和采购计划。
8.1.2 项目采购工作应符合有关合同、设计文件所规定的数量、技术要求和质量标准，符合工期、安全、环境和成本管理等要求。
8.1.3 产品供应和服务单位应通过合格评定。采购过程中应按规定对产品或服务进行检验，对不符合或不合格品应按规定处置。
8.1.4 采购资料必须真实、有效、完整，具有可追溯性。
8.1.5 采购管理应遵循下列程序：
1 明确采购产品或服务的基本要求、采购分工及有关责任。
2 进行采购策划，编制采购计划。
3 进行市场调查、选择合格的产品供应或服务单位，建立名录。
4 采用招标或协商等方式实施评审工作，确定供应或服务单位。
5 签订采购合同。
6 运输、验证、移交采购产品或服务。
7 处置不合格产品或不符合要求的服务。
8 采购资料归档。
8.2 项目采购计划
8.2.1 组织应依据项目合同、设计文件、项目管理实施规划和有关采购管理制度编制采购计划。
8.2.2 采购计划应包括下列内容：
1 采购工作范围、内容及管理要求。
2 采购信息，包括产品或服务的数量、技术标准和质量要求。
3 检验方式和标准。
4 供应方资质审查要求。
5 采购控制目标及措施。
8.3 项目采购控制
8.3.1 采购工作应采用招标询价或其他方式。
8.3.2 组织应对采购报价进行有关技术和商务的综合评审，并应制定选择、评审和重新
评审的准则。评审记录应保存。
8.3.3 组织应对特殊产品（特种设备、材料、制造周期长的大型设备、有毒有害产品）的供应单位进行实地考察，并采取有效措施进行重点监控。
8.3.4 承压产品、有毒有害产品、重要机械设备等特殊产品的采购，应要求供应单位提供有效的安全资质、生产许可证及其他相关要求的资格证书。
8.3.5 项目采用的设备、材料应经检验合格，并符合设计及相应现行标准要求。检验产品使用的计量器具，产品的取样、抽验应符合规范要求。
8.3.6 进口产品应按国家政策和相关法规办理报关和商检等手续。
8.3.7 采购产品在检验、运输、移交和保管等过程中，应按照职业健康安全和环境管理要求，避免对职业健康安全、环境造成影响。
9 项目进度管理
9.1 一般规定
9.1.1 组织应建立项目进度管理制度，制订进度管理目标。
9.1.2 项目进度管理目标应按项目实施过程、专业、阶段或实施周期进行分解。
9.1.3 项目经理部应按下列程序进行进度管理：
1 制定进度计划。
2 进行计划交底，落实责任。
3 实施进度计划，跟踪检查，对存在的问题分析原因并纠正偏差，必要时对进度计划进行调整。
4 编制进度报告，报送组织管理部门。
9.2 项目进度计划编制
9.2.1 组织应依据合同文件、项目管理规划文件、资源条件与内外部约束条件编制项目进度计划。
9.2.2 组织应提出项目控制性进度计划。控制性进度计划可包括下列种类：
1 整个项目的总进度计划。
2 分阶段进度计划。
3 子项目进度计划和单体进度计划。
4 年（季）度计划。
9.2.3 项目经理部应编制项目作业性进度计划。作业性进度计划可包括下列内容：
1 分部分项工程进度计划。
2 月（旬）作业计划。
9.2.4 各类进度计划应包括下列内容：
1 编制说明。
2 进度计划表。
3 资源需要量及供应平衡表。
9.2.5 编制进度计划的步骤应按下列程序：
1 确定进度计划的目标、性质和任务。
2 进行工作分解。
3 收集编制依据。
4 确定工作的起止时间及里程碑。
5 处理各工作之间的逻辑关系。
6 编制进度表。
7 编制进度说明书。
8 编制资源需要量及供应平衡表。
9 报有关部门批准。
9.2.6 编制进度计划可使用文字说明、里程碑表、工作量表、横道计划、网络计划等方法。作业性进度计划必须采用网络计划方法或横道计划方法。
9.3 项目进度计划实施
9.3.1 经批准的进度计划，应向执行者进行交底并落实责任。
9.3.2 进度计划执行者应制订实施计划措施。
9.3.3 在实施进度计划的过程中应进行下列工作：
1 跟踪检查，收集实际进度数据。
2 将实际数据与进度计划进行对比。
3 分析计划执行的情况。
4 对产生的进度变化，采取措施予以纠正或调整计划。
5 检查措施的落实情况。
6 进度计划的变更必须与有关单位和部门及时沟通。
9.4 项目进度计划的检查与调整
9.4.1 对进度计划进行的检查与调整应依据其实施结果。
9.4.2 进度计划检查应按统计周期的规定进行定期检查，并应根据需要进行不定期检查。
9.4.3 进度计划的检查应包括下列内容：
1 工作量的完成情况。
2 工作时间的执行情况。
3 资源使用及与进度的匹配情况。
4 上次检查提出问题的处理情况。
9.4.4 进度计划检查后应按下列内容编制进度报告：
1 进度执行情况的综合描述。
2 实际进度与计划进度的对比资料。
3 进度计划的实施问题及原因分析。
4 进度执行情况对质量、安全和成本等的影响情况。
5 采取的措施和对未来计划进度的预测。
9.4.5 进度计划的调整应包括下列内容：
1 工作量。
2 起止时间。
3 工作关系。
4 资源供应。
5 必要的目标调整。
9.4.6 进度计划调整后应编制新的进度计划，并及时与相关单位和部门沟通。
10 项目质量管理
10.1 一般规定
10.1.1 组织应遵照《建设工程质量管理条例》和《质量管理体系GB/T 19000》族标准的要求，建立持续改进质量管理体系，设立专职管理部门或专职人员。
10.1.2 质量管理应坚持预防为主的原则，按照策划、实施、检查、处置的循环方式进行系统运作。
10.1.3 质量管理应满足发包人及其他相关方的要求以及建设工程技术标准和产品的质量要求。
10.1.4 组织应通过对人员、机具、设备、材料、方法、环境等要素的过程管理，实现过程、产品和服务的质量目标。
10.1.5 项目质量管理应按下列程序实施：
1 进行质量策划，确定质量目标。
2 编制质量计划。
3 实施质量计划。
4 总结项目质量管理工作，提出持续改进的要求。
10.2 项目质量策划
10.2.1 组织应进行质量策划，制定质量目标，规定实施项目质量管理体系的过程和资源，编制针对项目质量的文件。该文件可称为质量计划。质量计划也可以作为项目管理实施规划的组成部分。
10.2.2 质量计划的编制应依据下列资料：
1 合同中有关产品（或过程）的质量要求。
2 与产品（或过程）有关的其他要求。
3 质量管理体系文件。
4 组织针对项目的其他要求。
10.2.3 质量计划应确定下列内容：
1 质量目标和要求。
2 质量管理组织和职责。
3 所需的过程、文件和资源。
4 产品（或过程）所要求的评审、验证、确认、监视、检验和试验活动，以及接收准则。
5 记录的要求。
6 所采取的措施。
10.2.4 质量计划应由项目经理部编制后，报组织管理层批准。
10.3 项目质量控制与处置
10.3.1 项目经理部应依据质量计划的要求，运用动态控制原理进行质量管理。
10.3.2 质量控制主要控制过程的输入，过程中的控制点以及输出，同时也应包括各个过程之间接口的质量。
10.3.3 项目经理部应在质量控制的过程中，跟踪收集实际数据并进行整理。并应将项目的实际数据与质量标准和目标进行比较，分析偏差，并采取措施予以纠正和处置，必要时对处置效果和影响进行复查。
10.3.4 质量计划需修改时，应按原批准程序报批。.
10.3.5 设计的质量控制应包括下列过程：
1 设计策划。
2 设计输入。
3 设计活动。
4 设计输出。
5 设计评审。
6 设计验证。
7 设计确认。
8 设计变更控制。
10.3.6 采购的质量控制应包括确定采购程序、确定采购要求、选择合格供应单位以及采购合同的控制和进货检验。
10.3.7 对施工过程的质量控制应包括：
1 施工目标实现策划。
2 施工过程管理。
3 施工改进。
4 产品（或过程）的验证和防护。
10.3.8 检验和监测装置的控制应包括：确定装置的型号、数量，明确工作过程，制定质量保证措施等内容。
10.3.9 组织应建立有关纠正和预防措施的程序，对质量不合格的情况进行控制。10.4 项目质量改进
10.4.1 项目经理部应定期对项目质量状况进行检查、分析，向组织提出质量报告，提出目前质量状况、发包人及其他相关方满意程度、产品要求的符合性以及项目经理部的质量改进措施。
10.4.2 组织应对项目经理部进行检查、考核，定期进行内部审核，并将审核结果作为管理评审的输入，促进项目经理部的质量改进。
10.4.3 组织应了解发包人及其他相关方对质量的意见，对质量管理体系进行审核，确定改进目标，提出相应措施并检查落实。
11 项目职业健康安全管理
11.1 一般规定
11.1.1 组织应遵照《建设工程安全生产管理条例》和《职业健康安全管理体系》GB/T 28000 标准，坚持安全第一、预防为主和防治结合的方针，建立并持续改进职业健康安全管理体系。项目经理应负责项目职业健康安全的全面管理工作。项目负责人、专职安全生产管理人员应持证上岗。
11.1.2 组织应根据风险预防要求和项目的特点，制定职业健康安全生产技术措施计划，确定职业健康安全生产事故应急救援预案，完善应急准备措施，建立相关组织。发生事故，应按照国家有关规定，向有关部门报告。要处理事故时，应防止二次伤害。11.1.3 在项目设计阶段应注重施工安全操作和防护的需要，采用新结构、新材料、新工艺的建设工程应提出有关安全生产的措施和建议。在施工阶段进行施工平面图设计和安排施工计划时，应充分考虑安全、防火、防爆和职业健康等因素。
11.1.4 组织应按有关规定必须为从事危险作业的人员在现场工作期间办理意外伤害保险。
11.1.5 项目职业健康安全管理应遵循下列程序：
1 识别并评价危险源及风险。
2 确定职业健康安全目标。
3 编制并实施项目职业健康安全技术措施计划。
4 职业健康安全技术措施计划实施结果验证。
配置管理规程
配置管理（Configuration Management, CM）的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性。 配置管理过程域的四个主要规程： 制定配置管理计划－配置库管理－配置版本控制－配置变更控制 定义 1.工作成果（Work Product） 项目研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等。 2.配置项（Configuration Item, CI） 所有纳入配置管理范畴的工作成果统称为配置项，配置项主要有两大类： （1）属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。 （2）项目管理中产生的文档。如计划、报告等。这些文档虽然不是产品的组成部分，但是值得保存。 每个配置项的主要属性有：标识符、名称、文件状态、版本、作者、日期等。所有配置项都须保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 3.基线（Baseline） 基线由一组配置项组成，并且这些配置项已被“冻结”，任何人不能再随意修改（见变更控制规程）。基线通常在里程碑处建立，所以一个产品可以有一个或多个基线。基线的主要属性有：标识符、名称、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发所用的基线则称为一个“Build”。 4.项目配置管理员（Project Configuration Manager） 为了提高配置管理的效率和安全性，项目需要有专人为项目制定《配置管理计划》，创建和维护配置库，在本文档中，该负责人称为项目配置管理员。在公司，项目支持负责人担任项目配置管理员的角色。 5.项目变更控制委员会（Change Control Board, CCB） 项目CCB对项目内配置管理的各项活动拥有决策权（例如审批配置管理计划，审批变更请求等）。对于配置管理而言，项目CCB是决策者，而项目配置管理员是执行者。项目CCB的人数视项目的规模而定。通常项目CCB由项目经理、资深项目成员等人组成，项目经理为项目CCB负责人。CCB的决策采用“少数服从多数”原则。 1.1 配置管理流程介绍 配置管理的流程下图所示：
软件配置管理规定
软件配置管理规定? 为进一步加强软件配置管理工作,明确软件配置原则,规范软件配置流程，制定本规定。 一、配置原则? 1、软件配置遵循安全性、适用性、 2、单经济性与正版化得原则，不得配置非正版软件。? 位使用得商业软件、OEM软件、免费软件均需纳入配置管理，不得配置与工作无关得各类软件。?3、优先采用场地授权(许可)方式配置软件。 二、配置流程 1、软件使用部门根据本部门各岗位工作需要，编制岗位软件需求清单，填写《软件使用需求申请表》（附件1)。 ２、信息化部门统计、汇总软件使用部门报送得《软件使用需求申请表》,对软件使用部门需要得相关软件进行统一测试与试用，综合考虑软件得价格、兼容性、安全性与售后服务等因素,确定软件选型,明确软件名称与版本.涉及使用免费软件得,更新《可使用免费软件清单》(附件2）。 3、信息化部门依据单位软件使用管理台账,梳理单位软件需求与现有软件许可得差异。单位软件许可不足得，编制《软件采购计划表》（附件3）。 4、财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年
限、兼容性与售后服务等要求。?5、财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作，重点就是软件采购合同、软件授权证书、软件安装序列号等资料得管理工作。? 6、信息化部门负责软件使用管理日常工作。?7、单位采购得软件,因以下情况申请报废得，需经过信息化部门鉴定,严格履行资产处置报批手续：?(１）已经达到规定得最低使用年限,且无法继续使用得.?（２）未达到规定得最低使用年限,因技术进步等原因无法继续使用得。?（3）未达到规定得最低使用年限,因计算机硬件报废，且无法迁移到其她计算机上继续使用得. ８、信息化部门在单位新采购软件、报废软件与调整可使用免费软件清单后，更新《软件使用情况汇总表》（附件4)。
软件配置管理过程指导说明书(超级实用)
软件配置管理过程指导说明书
目录 1 前言 (2) 1.1 目的 (2) 1.2 适用范围 (2) 1.3 术语名词解释 (2) 2 角色和职责说明 (3) 3 输入 (4) 4 入口准则 (4) 5 配置管理实施 (4) 5.1 配置库结构 (4) 5.1.1 配置库 (4) 5.1.2 配置管理库系统 (6) 5.2 配置管理流程 (6) 5.2.1 配置管理流程图 (6) 5.2.2 配置变更流程图 (7) 5.3 配置标识 (8) 5.3.1 配置库划分 (8) 5.3.2 配置库结构 (8) 5.3.3 配置项命名 (11) 5.3.4 版本编号规范 (11) 5.4 配置管理活动 (12) 5.4.1 制定配置管理计划 (12) 5.4.2 建立配置库 (12) 5.4.3 建立配置项 (12) 5.4.4 基线建立及发布过程 (12) 5.4.5 配置变更 (13) 5.4.6 配置审计 (15) 5.4.7 备份 (16) 6 输出 (16) 7 出口准则 (16) 8 本过程裁剪规定 (16)
1 前言 1.1 目的 用于描述配置管理作用和过程，规范配置管理的实施过程、活动和操作。 1.2 适用范围 适用于在软件生命周期中对各类软件项目的配置管理活动。 1.3 术语名词解释 CCB：Configuration Control Board，配置管理委员会，每个项目组需要建立项目级的CCB作为变更控制权威。CCB由质量工程师、项目经理、测试经理、配置管理员构成，有时也可以包括客户代表、上级质量部门主管。CCB组长可以是质量工程师或质量部领导，但不能是项目经理。 软件配置项：是指软件工程过程中所生产或使用的任何元素，或者是纳入软件产品的元素。它可以是说明书、计算机程序、数据结构或者开发软件产品所使用的工具等，包括：项目文档，源代码，执行程序，相关设备及资料。 软件配置管理：对软件配置项的管理称为软件配置管理。软件配置管理的目的是建立和维护软件项目整个生命周期中工作产品的完整性和可追溯性。 软件工作产品：由定义、维护和使用一个软件过程所产生的任何人工制品，包括过程描述、计划、规程、计算机程序和相关文档，无论是否打算将它们交给客户或最终用户。 软件产品：可交付给客户或最终用户的软件工作产品的子集称作软件产品 基线：基线，是开发过程中标识出的里程碑所交付的一个或多个配置项，也即指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态它有如下特征：（1）已经过正式的评审和批准；（2）作为项目发展和产品升级的基础。（3）基线变更必须经过CCB审批。 变更控制：对配置项的更改进行评价、协调、认可或不认可以及执行更改的过程。 版本发布：指从项目的配置库中将需交付给客户的所有配置项组装成一个完整的软件产品。即交付给客户的一个包括可执行程序和文档的发布基线称为发布（release）。 配置审计：可以分为物理审计和功能审计。物理审计审查配置项的外在特征的正确性与一致性，主要考查软件受控库的结构、内容及其它相关信息，以验证基线和描述它的文档的一致性；功能审计审查配置项内容的正确性与一致性，主要考核配置项在实现功能上的一致性，功能审计主要通过评审和测试报告体现。 物理审计的内容包括： ? 确认配置项标识的正确性； ? 确认已受控配置项的更改是受到控制的； ? 验证配置库内容与相应记录之间的一致性； ? 验证配置管理活动与相应记录之间的一致性； ? 验证配置管理工作是否符合适用的标准和规程； ? 验证配置管理系统与系统备份的有效性、一致性等。 功能审计的内容包括： ? 验证当前基线所含配置项对前一基线所含配置项的追溯性； ? 确认当前基线所含配置项均正确反映了项目需求； ? 评估基线的完整性； ? 验证当前基线和各基线间所含配置项的一致性； 验证配置库内容的完备性和正确性等。
软件版本管理规范标准[详]
软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 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.技术资料（保存项目技术文档，包括第三方技术资料等）
软件配置管理流程
配置管理流程规定 (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)配置库的日常操作和维护 开发人员
软件开发项目配置管理工具的选择
软件开发项目配置管理工具的选择 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报…… 每一个软件项目，无论是工程类项目，还是产品类项目，都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中，将生成各种各样不同的工件，包括文档、源程序、可执行代码、支持库。更可怕的是，频繁出现的变更是不可避免的，因此面向如此庞大且不断变动的信息集，如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题，最早的开发人员尝试过的解决办法是通过手工来实现： 1)文档：每次修改时都另存为一个新的文件，然后通过文件名进行区分，例如"XXX 软件需求说明书V1.0，XXX软件需求说明书V1.1，XXX 软件需求说明书V2.0."，并且在文件中注明每次版本变化的内容； 2) 源代码：每次要修改时就将整个工程目录复制一份，将原来的文件夹进行改名，例如"XX 项目V1.0、XX 项目1.01、."，然后在新的目录中进行修改； 但是这种方法，不仅十分繁琐，容易出错，而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时，还是会造成很大的混乱。很显然，这样简陋的方法是无法应对这一问题的。后来，有人尝试从制造工业领域引入了"配置管理"这一概念，通过不懈的研究与实践，最终形成了一套管理办法和活动原则，这也就是软件配置管理。 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。 常见的配置管理工具 正如前面所述，由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。 正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制
软件配置管理规范.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 目的 本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件
的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工 作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。 每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再
软件三库管理规范
软件三库管理规范-标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
1目的范围 规定了公司软件开发库、受控库、产品库（以下简称三库）的管理规范。 2参考文献 《软件三库管理制度》 3术语和定义 GitLab：一个仓库管理系统，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。 Jenkins：基于Java开发的一种持续集成平台，用于监控持续重复的工作。 SPM：公司研发部开发的持续集成工具，用于集成软件部署包。 Releaser：公司研发部开发的基于SPM的软件部署包发布工具。 Kiwi TCMS：公司研发部基于开源代码改进的测试用例管理系统，用于测试计划和测试用例的创建和维护、以及测试执行的记录。 4职责 4.1软件三库管理职责 软件开发库由项目组管理，软件受控库由研发部管理，软件产品库由质量部管理。 4.2软件管理员职责 a)具备软件配置管理知识； b)熟悉研制项目的配置管理； c)熟悉公司结构、软件三库管理规定、标识规定和软件配置管理计划。 5管理内容与方法 5.1建立软件三库 5.1.1 开发库 a)开发库代码部分和说明部分基于GitLab建立，按照软件项目分配仓库。 项目组长任仓库Master，负责需求说明的管理、成员管理、问题跟踪、分支Merge、任务分配、Tag标识等工作。 项目组成员任仓库Developer，负责设计和交付说明的管理、问题调查、分支维护等工作。 测试组成员任仓库Reporter，负责测试说明的管理、报告问题、问题回归等工作。 b)开发库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。
研发项目管理之配置管理规程
研发项目管理之配置管理规程 1 总则 1.1概述 在项目整个生命周期中项目管理员应对研发工作产品进行标识，跟踪完成有关基线变更处理。 1.2基本原则 项目配置管理的目的是建立和维护项目在整个生命周期产品的统一性、完整性和可追溯性。应遵循的原则： 项目管理员负责项目配置管理。 项目配置管理工作贯穿项目的整个生命周期。 项目管理员应定期检查配置管理工作。 项目结项时应提交配置状态记录表。 1.3人员要求及岗位职责 1.3.1项目管理员 1.3.1.1职责 建立基线库，实施版本控制；收到或更改某个配置项时，应及时通知有关人员；记录并维护配置状态信息，配合项目管理员及领导对项目配置管理的定期检查工作。项目结项时，应对项目的配置情况进行总结，最终提交配置状态记录表并存档。 1.3.1.2岗位要求 接受相关配置管理规范、变更管理规程的培训。
1.3.2项目经理、开发部经理 1.3. 2.1职责 定期或在事件驱动下检查配置管理工作。 1.3. 2.2岗位要求 接受相关配置管理规范、变更管理规程的培训。 1.4资源保证 公司研发部门保证提供完成项目配置管理工作所需的资源、工具和人力。 2 规范流程 2.1.1配置管理规范 2.1.1.1目的 指导项目管理员进行配置管理工作。 2.1.1.2适用范围 公司研发部门所有开发项目 2.1.1.3配置管理过程 2.1.1. 3.1制定配置管理计划 项目管理员负责制定项目配置管理计划，内容包括项目中将要进行的配置管理活动、时间安排、相关资源，职责分配等。 对于配置项变更应按照“变更请求流程”来进行。 配置管理计划应经项目经理审核 配置管理计划由项目管理员负责管理和控制，由项目组遵照实施。
版本管理制度
版本管理规范(草案) 研发部 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．风险管理制度....................................................... 错误!未定义书签。
软件配置管理控制程序A0
程序文件 软件配置管理控制程序 文件编号 版木A0 贞数第1贞共6贞 編制部门研发部 生效日期2018年09月05日 修改页 文件编号修改条款修改内容修改人/日期生效日期全文首次发行 分发部门会签 编制审核批准□业务部□研发部□采购部□生产韶□质量部□行政部
软件配置管理控制程序 软件配這皆理贯穿于软件整个生命周期，对规范软件版本、源代码、文件、工具、现成软件等控 制要求，确世配置标识、变更控制、配置状态记录等活动要求。使用配置管理工具保证软件质量使公 司的所有软件开发项目的软件配置管理活动都能按照统一的要求进行。 适用于本公司所有的软件项目，并贯穿于软件生存周期全过程。 3.1项目经理 负责指过配置管理人员: 负责审批配置管理il ?划; 负责执行配置管理il 划。 3. 3质量部 > 负责跟踪配置管理il ?划的实施。 4.1术语泄义 软件配置管理：是标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和变更, 记录并报告配置的状态和变更要求，验证配置项的完整性和正确性。 软件配置项：为配置管理的目的而作为一个单元来看待的硬件/软件成分。 基线：一组拥有唯一标识号的需求、设计、源代码文件以及柑应的可执行代码、构造文卷和用户文档 构成一条基线。基线一经放行，就可以作为从配置管理系统检索源代码文卷（配苣项〉和生成可执行 文卷的工具" 4.2配置管理讣划编制 所有项目在指；4^项目开发计划时，都应有项目经理指定配置管理人员，然后由配置管理人员编写 《配置管理计划》，也可以包含在《软件开发计划中》，配置管理讣划至少应包括的内容: ? 配置管理人员的组成及分工 2. 范围 3. 职责 3.2 配置管理人员 4. 工作程序
软件配置管理规范流程
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） 在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一
软件版本管理规范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) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。
配置管理岗位职责
配置管理员岗位职责 摘自：软件配置管理论坛 一、配置经理的基本技能与资格 资格： 能够重视配置管理工作； 能够按规范实施配置管理工作； 积极支持部门的配置管理方面的工作； 能够积极支持与帮助其他人员； 为部门的配置管理能力的提高贡献力量； 熟悉公司配置流程以及其他相关的流程； 为增进项目管理，对于项目内的困难和关键问题，能够及时反映到部门； 基本技能： 能够独立规划项目的配置管理工作； 熟练掌握配置管理的相关概念； 能够了解配置的相关工具，熟练使用技术工程部配置所使用的工具； 具有基本的与人沟通的技巧； 能够了解项目管理过程中的主要环节； 初步了解项目管理过程中的质量保证的各个方面； 了解部分系统和应用工具，如数据库ORACLE，前台开发工具DEPHI等； 二、配置经理的职责 作为一名配置人员，配置经理的职责就是能够与质量人员、测试人员等共同保证项目的质量。如：作为质量保证的成员之一，能够为整个技术工程部规范化管理的推进作贡献，如宣传规范化管理的知识，陈述规范化管理的利弊等；能够在项目进行的整个生命过程中，不断的与项目经理、QA、SCCB及项目成员进行配置管理规范化的沟通，为项目配置管理的规范化作出努力. 具体表现为： ?项目进行初期或首次进入项目中时，能够首先与项目经理、QA、SCCB及项目成员就项目的未来配置管理工作进行沟通，取得项目经理、QA、SCCB及项目全体成员对配置工作的认可与支持； ?积极了解项目情况，项目各阶段的进展，为更好的进行配置管理作努力； ?熟练并充分的利用配置管理工具的各方面的功能，提高配置管理的效率； ?为项目控制好版本，保证项目各阶段所使用的版本正确； ?及时发现项目问题，把问题及时反馈给项目经理、QA或SCCB，并积极协助解决； ?与项目内其他组成员，如开发组、测试组等协调工作，并能够很好的沟通； ?能够在项目中不断总结、分析，为项目内配置管理工作的进一步优化作贡献；
软件配置管理规范标准
页眉 软件配置管理规范 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