CMMI-过程改进方针政策.docx

《CMMI-过程改进方针政策.docx》由会员分享，可在线阅读，更多相关《CMMI-过程改进方针政策.docx（15页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、CMMI-过程改进方针政策 过程改进方针政策 文件编号 HW-SP-OPF-S01 文件状态 草稿 正式发布 正在修改 当前版本 V1.1 修 订 张三 日期 年 月 日 审 核 李四 日期 年 月 日 批 准 王五 日期 年 月 日 发布日期 年 月 日 生效日期 年 月 日 广东技术股份有限公司 修订历史记录 A - 增加 M - 修订 D - 删除 变更版本号 日期 变更类型 （A*M*D） 修改人 摘 要 备注 1.0 A 文件建立 目 录 1 目的 4 2 适用范围 4 3 名词术语 4 4 过程改进方针 4 4.1 过程改进方针 4 4.2 各过程域（PA）方针 4 4.2.1 组

2、织过程定义 4 4.2.2 组织过程改进 5 4.2.3 组织培训 5 4.2.4 项目立项 5 4.2.5 项目启动 5 4.2.6 项目规划和集成项目管理 5 4.2.7 项目监控 6 4.2.8 风险管理 6 4.2.9 变更限制与管理 6 4.2.10 需求开发与管理 7 4.2.11 系统设计 7 4.2.12 实现与测试 7 4.2.13 系统测试 7 4.2.14 研发验收和客户验收 8 4.2.15 技术评审 8 4.2.16 缺陷管理 8 4.2.17 系统维护 8 4.2.18 配置管理 8 4.2.19 过程与产品质量保证 9 4.2.20 度量和分析 9 4.2.21

3、决策分析和解决方案 9 4.2.22 项目结项 10 5 过程改进组织结构 10 6 过程改进政策 10 6.1 公司领导的支持 10 6.2 项目管理委员会（MSG）的职责 11 6.3 质量管理的政策 11 6.4 工程过程小组的政策 12 6.5 质量保证小组的政策 12 6.6 项目团队的政策 12 1 目的 为指导公司的软件过程改进活动，保证软件过程改进活动持续有效的进行，特制定本文件。 2 适用范围 部门：公司研发中心及技术拓展部。业务：公司的软件过程改进活动。3 名词术语 CMMI（Capability Maturity Model Integration）：实力成熟度模型集成。

4、PA（Process Area）：过程域。PI（Process Improvement）：过程改进。MSG（Manage Support Group）：公司项目管理委员会，是公司项目最高管理机构。EPG (Engineering Process Group)：工程过程组，负责公司内部的过程定义、维护和改进的专家组。PAT（Process Action Team）：过程行动小组，为了执行某项过程改进活动而临时成立的小组，负责完成一项过程改进专项任务并向EPG报告改进状态。QAG（Quality Assurance Group）：质量保证小组，负责对组织过程改进活动及项目执行软件过程活动的质量进行

5、检查。 4 过程改进方针 4.1 过程改进方针 以CMMI-DEV（实力成熟度模型集成）模型为基础，结合美国项目管理协会（PMI）的PMBOK（项目管理学问体系），对公司软件开发过程进行持续的改进。从而实现提高软件项目的质量和生产率，降低成本，有效限制进度的目标。这套方法将在公司软件开发过程中反复实践，不断进行改进，最终达到CMMI3级的要求。 1） 建立度量分析体系，用科学合理的分析结果支持研发、管理的须要，提高项目的研发、管理、质量的水平。2） 为实现组织过程改进的总体及年度目标，组织领导需供应并协调必要的资源，以持续满意整体过程改进的支撑条件。 4.2 各过程域（PA）方针 4.2.1

6、组织过程定义 定义组织的标准软件过程。 项目定义过程是组织标准软件过程的裁剪版本。 项目自定义开发过程必需得到EPG组认可后方可运用。 项目应严格根据项目定义过程进行项目管理和开发。 组织标准软件过程必需得到定期维护。 收集各个项目信息并存于组织过程资产库，以便对组织标准软件过程进行改进。 组织级QA定期审计组织过程定义过程，并报告结果。4.2.2 组织过程改进 EPG负责收集、评估过程改进建议，并对组织标准软件过程进行定期更新。 项目中将会运用的工作过程，工具以及方法等应受到监控和评价。 各个项目所采纳的项目过程是恰当地遵循或剪裁组织标准软件过程。 EPG负责收集项目最佳实践和每个项目的阅历

7、教训，使其能在各项目中共享。 组织级QA定期审计组织过程改进过程，并报告结果。4.2.3 组织培训 培训活动有安排并按安排开展相应的活动。 识别项目开发过程中各角色所需的技能和学问。 批准和建立培训技能和学问的方式和方法。 建立组织的技能基础以满意特定需求和个人技能。 开展组织内部和外部培训，使项目组成员得到所需的技能。 组织级QA定期审计组织培训过程，并报告结果。4.2.4 项目立项 使符合公司商业目标的项目能够立项。 不符合公司利益的项目得不到立项，避开奢侈公司珍贵的人力资源和金钱。 重大项目的立项须由公司各部门专家组成的评审委员会进行决策评审。4.2.5 项目启动 重要的项目须要有项目任

8、务书。 为实现项目目标，项目组需获得必要的资源。4.2.6 项目规划和集成项目管理 项目实施采纳项目经理负责制，每个项目设置一个项目经理。 安排的开发需求是项目安排的基础。 项目在进行项目估计、识别风险时应尽量借鉴组织资产库的内容。 全部项目都必需参照组织过程裁剪指南形成项目定义过程。 项目必需有文档化的干系人纳入及管理安排 项目经理明确安排开发工作任务到项目成员。 项目经理负责制订集成化的项目安排。 技术评审小组评审项目安排及承诺，并被高级经理批准。 项目经理应严格按PDP和集成的项目安排管理项目。 项目安排变更需按变更限制流程执行。 项目在结项时，项目经理及QA应总结项目的阅历教训，好的实

9、践等贡献给组织的资产库。 QA定期审计项目规划和集成项目管理过程，并报告结果。 4.2.7 项目监控 项目安排是项目跟踪的基础。 项目经理负责建立和维护一个环境，促进项目组及相关组之间的沟通。 项目经理定期维护项目安排，并报告项目开发的状态和结果。 高层经理、项目经理定期或事务驱动方式评审项目跟踪和监督活动。 依据实际结果，对与安排的重大偏离状况进行分析。当项目的实际结果严峻偏离安排时，项目经理负责实行订正措施。 项目跟踪数据被定期记录、并提交给相关部门。 QA组定期审计项目监控的活动，并报告结果。4.2.8 风险管理 在项目规划时，应识别项目风险，并制定风险的应对措施。 风险的识别参考组织的

10、资产库。 风险缓解措施的制定应当根据风险优先等级来确定。 使风险管理制度化，在项目实施的整个过程中跟踪并处理风险。 高层管理者审查“风险管理”过程的活动并解决问题。4.2.9 变更限制与管理 项目阶段产品基线化后，如须要变更，必需按变更流程执行变更。 涉及安排、需求、设计等的重大变更，需按技术评审的要求进行评估。 让项目干系人适当的参加变更限制与管理过程。4.2.10 需求开发与管理 收集项目客户（用户）等供利益者的须要、期限、限制条件和接口，并转换成客户需求。 对客户需求加以精练和细化，以便开发产品生存周期中的产品和产品构件需求。 对各项需求进行分析和确认，从而开发出所要求的产品功能。 产品

11、需求需经过评审，并得到项目干系人的一样承诺。 开发需求文档化，并建立需求基线。 开发需求的变更遵循变更限制流程。 建立需求跟踪矩阵，使需求与设计、编码及测试保持一样性，对于部分非功能性需求可以不做全程跟踪。 产品需求需得到高层经理的审批。 QA组定期审核需求管理的活动，并报告结果。4.2.11 系统设计 系统设计须要覆盖产品规格需求。 系统设计应符合产品发展路途图。 系统设计中遇到多种设计方案时，应启动决策评审流程。 对较大型的项目，系统设计应按概要设计和具体设计两个阶段分别进行。 系统设计的输出应能满意编码阶段的要求。4.2.12 实现与测试 按组织编程规范编写代码。 编写的程序代码需通过代

12、码审查。 制定并维护进行产品集成的策略。 产品构件接口，不论内部的还是外部的，都应是兼容的。 对单元测试和集成测试的结果需进行记录，对缺陷按缺陷管理要求处理。 对经过验证的产品构件进行组装并且交付已集成、验证和确认的产品。 该过程制度化，并建立维护需求、目标和安排。 收集改进信息、监督和限制该过程。4.2.13 系统测试 在完成产品的集成测试后，产品在交付验收测试之前，项目组需根据产品规格说明书要求制定系统测试安排、编写系统测试用例。 系统测试安排和系统测试用例需经过技术评审，确保测试范围覆盖产品真正需求。 按安排和系统测试用例对最终系统进行全面的测试，确保最终系统满意产品需求并且遵循系统设计

13、。 对系统测试的结果需进行记录，对缺陷按缺陷管理要求处理。 系统测试结果和总结报告需得到高层经理的批准。4.2.14 研发验收和客户验收 确认需求和确认策略用文档化的确认策略描述。 对产品或产品构件进行确认，确保产品适合于在预定的环境中运用。 该过程制度化，并对该过程安排责任和供应足够资源。 监督和限制该过程，收集过程信息，并实行适当的订正措施。 高层管理者评审该过程、并解决问题。4.2.15 技术评审 定义要进行技术评审的产品标准。 项目组在项目规划时制定技术评审安排。 技术评审需有同类产品开发阅历的人参加。 QA应参加项目阶段重要产品的技术评审活动。 技术评审小组应记录产品缺陷，QA跟踪解

14、决过程。4.2.16 缺陷管理 缺陷管理应覆盖到项目规划起先至产品维护期间。 对组件、产品缺陷的产生、处理、验证要有完整的记录。 该过程制度化，并对该过程安排责任和供应足够资源。 QA组定期审核缺陷管理的活动，并报告结果。4.2.17 系统维护 系统维护包括客户询问服务和产品维护，以提高用户满足度为宗旨。 系统维护过程应有完整的记录。 该过程制度化，并对该过程安排责任和供应足够资源。4.2.18 配置管理 项目开发过程中的阶段产品须要纳入配置管理系统。 采纳集中的配置管理系统，CMO负责配置管理系统的管理和维护。每个项目组指定一个配置管理人员，并制定项目配置管理安排。 指定CM职责，并在整个项

15、目开发过程中执行CM活动。 项目经理、CMO、高级经理、QA人员定期审计产品基线和CM活动。 对项目工作产品进行有效标识，产品基线变更受到严格限制。 产品基线内容和状态应刚好/定期通知共利益者。 QA定期审计CM的活动，并报告结果。4.2.19 过程与产品质量保证 为满意用户对产品的质量要求，每个项目组指派一个QA人员（专职或兼职），QA人员制定质量保证安排。 应给予QA肯定权限，使QA能独立的开展质量保证工作， QA报告有独立的报告渠道给高层经理。 QA按安排参加项目组的技术评审活动。 QA按安排检查项目组的过程和产品质量，对检查出的不符合项刚好通知项目经理，并跟踪不符合项的解决过程。 QA

16、记录QA活动和审计结果。 QA经理定期审计QA的QA活动和相关记录。 高层经理处理项目组内部不能解决的不符合项或豁免不符合项。4.2.20 度量和分析 使测量目标规定和测量行为与信息须要和目标相一样。 把测量目标进一步精练成精确的、定量的度量项。 项目经理按度量数据收集、分析及存储规程收集存储数据，定期供应度量数据分析报告。 向项目共利益者通报分析数据。 QA人员监督度量和分析过程。 高层经理评估度量分析报告，并给出改进看法。4.2.21 决策分析和解决方案 确定决策分析的进入准则和选择决策方案的原则。 针对决策的问题确定多选方案。 在项目或产品生存周期的任何阶段运用所拟定的准则评价侯选方案，

17、最终确定方案。 该过程作为已定义过程并制度化，进行过程管理责任安排，人员培训及资源配置。 高层管理者评审该过程活动、状态和结果，并解决问题。4.2.22 项目结项 确定项目结项的准则。 总结项目的阅历教训，丰富组织过程资产库。 依据项目过程数据，对项目进行评估和考核。 高层管理者和行业技术专家参加项目结项过程。 5 过程改进组织结构 公司过程改进活动组织结构如下： MSG 询问公司EPG cmmi经理(EPG Leader) TG CM EPG QAG MSG：公司项目管理委员会，是公司进行过程改进的最高权威机构，由公司主管软件技术部门的副总裁负责MSG的领导工作。 cmmi经理：公司研发中心

18、项目管理办公室经理，负责过程改进的各项详细工作。 EPG：负责软件过程规范的制定、修改完善及实施指导； QAG：监督规范的实施，确保全部项目以及相关部门准照规范开展工作。分析并解决机构内存在的共性质量问题，协组EPG完善规范。 CM：组织级的配置管理。TG：组织级的过程规范培训小组（成员可由EPG成员兼任），负责组织内的软件过程规范的培训工作。 6 过程改进政策 6.1 公司领导的支持 1）、公司主管领导批准用于软件过程改进的必要经费，例如支付询问费，购买相关软件工具等。 2）、公司主管领导组建EPG和QAG，特地从事软件过程改进工作及质量保证工作。EPG的主要职责是建立适合于组织的过程规范，

19、QAG的主要职责是监督该规范的实施。建议让EPG和QAG的部分人员重叠，这些人既是EPG成员又是质量保证员，扮演两种角色。这样不仅节约人力资源，并且提高了工作效果（由制定规范的人去监督规范的实施最合适不过）。一般地，EPG成员和质量保证员共占组织软件技术部门总人数的5%左右。3）、公司主管领导和高层经理不仅要口头支持，还要亲自参加软件过程改进的实践。例如参与培训、根据过程规范执行立项管理、参加过程规范的建立及改进的评审和审批等。 6.2 项目管理委员会（MSG）的职责 1）、将PI规划与组织的商业目标和战略联系起来； 2）、供应过程改进所需的资源和资金支持 3）、参加组织过程改进安排的评审；

20、4）、监督EPG活动； 5）、制定对过程改进活动的奖惩制度。 6.3 质量管理的政策 质量管理的口号是：“在开发过程之中内建质量而非修补质量”。 质量管理有几种基本措施：“质量保证”、“技术评审”和“测试”。1）、质量保证 公司的质量保证员周期性地检查项目成员的“工作过程以及工作成果”是否符合既定的规范，来监控和改进“过程质量以及产品质量”。公司的质量保证员独立于任何项目，并给予他肯定的权利，对质量不合格的工作成果作出处理。2）、技术评审 在工作成果刚产生之际，对其进行技术评审（评审的形式有多种方式），目的是尽早地发觉工作成果中的缺陷，并帮助开发人员刚好消退缺陷，从而提高产品的质量。假如时间允

21、许的话，应当尽可能多地对产品的重要工作成果进行技术评审。技术评审活动由项目开发团队组织。3）、测试 测试是指通过运行测试用例来找出软件中的缺陷。测试与技术评审的主要区分是前者要运行软件而后者不必运行软件。一般地，产品开发过程中有四个测试阶段：单元测试、集成测试、系统测试和验收测试（或Beta测试）。其中单元测试和集成测试可以由项目开发团队组织。系统测试阶段必需有项目外的人员参加，以保证系统测试的客观性。验收测试（或Beta测试）由技术部门组织或客户组织（研发项目由技术部门组织测试，合同项目由客户组织测试）。在条件允许的状况下，技术部门应成立特地的测试小组从事单元测试、集成测试和系统测试工作。

22、6.4 工程过程小组的政策 公司主管领导任命一位熟识软件工程、项目管理、CMM/CMMI并且有丰富工作阅历的人担当EPG的负责人。在公司主管领导的许可下，该负责人组建EPG（成员可以是全职的也可以是兼职的）。EPG小组应按EPG章程开展各项工作。 6.5 质量保证小组的政策 公司主管领导任命一位熟识过程规范并且有丰富的质量管理阅历的人担当QAG的负责人（或称为质量经理）。在公司主管领导的许可下，该负责人组建QAG（成员可以是全职的也可以是兼职的）。 QAG在行政上独立于任何项目。这种独立性有助于质量保证员客观地检查和监控“过程以及产品的质量”。QAG根据EPG制定的“质量保证规范”开展工作。公

23、司主管领导给予QAG肯定的权利，可以对质量不合格的工作成果做出处理。这种权利使得QAG的工作不会被轻视，并有助于加强全员的质量意识。对于QAG与项目之间出现的难以调和的争议，由高层经理或公司主管领导处理。 6.6 项目团队的政策 项目中的任何管理人员、开发人员、测试人员等，必需学习与本职工作相关的过程规范，每个人都必需明白自己“应当在什么时候依据什么规范做什么事情”。项目经理应当树立榜样，并且督促项目成员们按规范做事。 允许项目经理依据本项目的特征，在EPG和QAG的指导下，适当地裁剪或扩充组织的过程规范，从而快速建立本项目的过程规范。这项工作应当在“项目规划过程域”中完成，并在项目安排中体现出来。 假如项目对机构过程规范的裁剪幅度比较大，遭到QAG的反对，假如双方不能达成共识，则由高层经理或公司主管领导处理该争议。 EPG对项目过程实力的评估成果将作为评定项目人员工作业绩的重要因素，详细比重由高层经理和公司主管领导确定，一般占30以上的比重。