XXSPOPFS01 过程改进方针政策.docx
《XXSPOPFS01 过程改进方针政策.docx》由会员分享，可在线阅读，更多相关《XXSPOPFS01 过程改进方针政策.docx（15页珍藏版）》请在冰点文库上搜索。
XXSPOPFS01过程改进方针政策
过程改进方针政策
文件编号
XX-SP-OPF-S01
文件状态
[]草稿[√]正式发布[]正在修改
当前版本
V1.1
修订
日期
2006-9-4
审核
日期
2006-9-7
批准
日期
2006-9-8
发布日期
200x年x月13日
生效日期
200x年x月15日
xxx公司
修订历史记录
A-增加M-修订D-删除
变更版本号
日期
变更类型
（A*M*D）
修改人
摘要
备注
1.0
2006-5-18
A
文件建立
1.1
2006-9-4
M
修改了工程类PA的方针
目录
1目的4
2适用范围4
3名词术语4
4过程改进方针4
4.1过程改进方针4
4.2各过程域（PA）方针4
4.2.1组织过程定义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需求开发与管理6
4.2.11系统设计7
4.2.12实现与测试7
4.2.13系统测试7
4.2.14研发验收和客户验收7
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决策分析和解决方案9
4.2.22项目结项9
5过程改进组织结构10
6过程改进政策10
6.1公司领导的支持10
6.2项目管理委员会（MSG）的职责10
6.3质量管理的政策11
6.4工程过程小组的政策11
6.5质量保证小组的政策11
6.6项目团队的政策12
1
目的
为指导公司的软件过程改进活动，保证软件过程改进活动持续有效的进行，特制定本文件。
2适用范围
部门：
公司研发中心及技术拓展部。
业务：
公司的软件过程改进活动。
3名词术语
CMMI（CapabilityMaturityModelIntegration）：
能力成熟度模型集成。
PA（ProcessArea）：
过程域。
PI（ProcessImprovement）：
过程改进。
MSG（ManageSupportGroup）：
公司项目管理委员会，是公司项目最高管理机构。
EPG（EngineeringProcessGroup）：
工程过程组，负责公司内部的过程定义、维护和改进的专家组。
PAT（ProcessActionTeam）：
过程行动小组，为了执行某项过程改进活动而临时成立的小组，负责完成一项过程改进专项任务并向EPG报告改进状态。
QAG（QualityAssuranceGroup）：
质量保证小组，负责对组织过程改进活动及项目执行软件过程活动的质量进行检查。
4过程改进方针
4.1过程改进方针
以CMMI-DEV（能力成熟度模型集成）模型为基础，结合美国项目管理协会（PMI）的PMBOK（项目管理知识体系），对公司软件开发过程进行持续的改进。
为客户提供可靠的解决方案，开发优秀的XXX及其支撑软件，强化客户至上的服务理念。
4.2各过程域（PA）方针
4.2.1组织过程定义
Ø定义组织的标准软件过程。
Ø项目定义过程是组织标准软件过程的裁剪版本。
Ø项目自定义开发过程必须得到EPG组认可后方可使用。
Ø项目应严格按照项目定义过程进行项目管理和开发。
Ø组织标准软件过程必须得到定期维护。
Ø收集各个项目信息并存于组织过程资产库，以便对组织标准软件过程进行改进。
Ø组织级QA定期审计组织过程定义过程，并报告结果。
4.2.2组织过程改进
ØEPG负责收集、评估过程改进建议，并对组织标准软件过程进行定期更新。
Ø项目中将会使用的工作过程，工具以及方法等应受到监控和评价。
Ø各个项目所采用的项目过程是恰当地遵循或剪裁组织标准软件过程。
ØEPG负责收集项目最佳实践和每个项目的经验教训，使其能在各项目中共享。
Ø组织级QA定期审计组织过程改进过程，并报告结果。
4.2.3组织培训
Ø培训活动有计划并按计划开展相应的活动。
Ø识别项目开发过程中各角色所需的技能和知识。
Ø批准和建立培训技能和知识的方式和方法。
Ø建立组织的技能基础以满足特定需求和个人技能。
Ø开展组织内部和外部培训，使项目组成员得到所需的技能。
Ø组织级QA定期审计组织培训过程，并报告结果。
4.2.4项目立项
Ø使符合公司商业目标的项目能够立项。
Ø不符合公司利益的项目得不到立项，避免浪费公司宝贵的人力资源和金钱。
Ø重大项目的立项须由公司各部门专家组成的评审委员会进行决策评审。
4.2.5项目启动
Ø重要的项目需要有项目任务书。
Ø为实现项目目标，项目组需获得必要的资源。
4.2.6项目规划和集成项目管理
Ø项目实施采用项目经理负责制，每个项目设置一个项目经理。
Ø分配的开发需求是项目计划的基础。
Ø项目在进行项目估计、识别风险时应尽量借鉴组织资产库的内容。
Ø所有项目都必须参照组织过程裁剪指南形成项目定义过程。
Ø项目必须有文档化的干系人纳入及管理计划
Ø项目经理明确分配开发工作任务到项目成员。
Ø项目经理负责制订集成化的项目计划。
Ø技术评审小组评审项目计划及承诺，并被高级经理批准。
Ø项目经理应严格按PDP和集成的项目计划管理项目。
Ø项目计划变更需按变更控制流程执行。
Ø项目在结项时，项目经理及QA应总结项目的经验教训，好的实践等贡献给组织的资产库。
ØQA定期审计项目规划和集成项目管理过程，并报告结果。
4.2.7项目监控
Ø项目计划是项目跟踪的基础。
Ø项目经理负责建立和维护一个环境，促进项目组及相关组之间的交流。
Ø项目经理定期维护项目计划，并报告项目开发的状态和结果。
Ø高层经理、项目经理定期或事件驱动方式评审项目跟踪和监督活动。
Ø根据实际结果，对与计划的重大偏离状况进行分析。
当项目的实际结果严重偏离计划时，项目经理负责采取纠正措施。
Ø项目跟踪数据被定期记录、并提交给相关部门。
ØQA组定期审计项目监控的活动，并报告结果。
4.2.8风险管理
Ø在项目规划时，应识别项目风险，并制定风险的应对措施。
Ø使风险管理制度化，在项目实施的整个过程中跟踪并处理风险。
Ø高层管理者审查“风险管理”过程的活动并解决问题。
4.2.9变更控制与管理
Ø项目阶段产品基线化后，如需要变更，必须按变更流程执行变更。
Ø涉及计划、需求、设计等的重大变更，需按技术评审的要求进行评估。
Ø让项目干系人适当的参与变更控制与管理过程。
4.2.10需求开发与管理
Ø收集项目客户（用户）等供利益者的需要、期限、限制条件和接口，并转换成客户需求。
Ø对客户需求加以精练和细化，以便开发产品生存周期中的产品和产品构件需求。
Ø对各项需求进行分析和确认，从而开发出所要求的产品功能。
Ø产品需求需经过评审，并得到项目干系人的一致承诺。
Ø开发需求文档化，并建立需求基线。
Ø开发需求的变更遵循变更控制流程。
Ø建立需求跟踪矩阵，使需求与设计、编码及测试保持一致性。
Ø产品需求需得到高层经理的审批。
ØQA组定期审核需求管理的活动，并报告结果。
4.2.11系统设计
Ø系统设计需要覆盖产品规格需求。
Ø系统设计应符合产品发展路线图。
Ø系统设计中遇到多种设计方案时，应启动决策评审流程。
Ø对较大型的项目，系统设计应按概要设计和详细设计两个阶段分别进行。
Ø系统设计的输出应能满足编码阶段的要求。
4.2.12实现与测试
Ø按组织编程规范编写代码。
Ø编写的程序代码需通过代码审查。
Ø制定并维护进行产品集成的策略。
Ø产品构件接口，不论内部的还是外部的，都应是兼容的。
Ø对单元测试和集成测试的结果需进行记录，对缺陷按缺陷管理要求处理。
Ø对经过验证的产品构件进行组装并且交付已集成、验证和确认的产品。
Ø该过程制度化，并建立维护需求、目标和计划。
Ø收集改进信息、监督和控制该过程。
4.2.13系统测试
Ø在完成产品的集成测试后，产品在交付验收测试之前，项目组需按照产品规格说明书要求制定系统测试计划、编写系统测试用例。
Ø系统测试计划和系统测试用例需经过技术评审，确保测试范围覆盖产品真正需求。
Ø按计划和系统测试用例对最终系统进行全面的测试，确保最终系统满足产品需求并且遵循系统设计。
Ø对系统测试的结果需进行记录，对缺陷按缺陷管理要求处理。
Ø系统测试结果和总结报告需得到高层经理的批准。
4.2.14研发验收和客户验收
Ø确认需求和确认策略用文档化的确认策略描述。
Ø对产品或产品构件进行确认，确保产品适合于在预定的环境中使用。
Ø该过程制度化，并对该过程分配责任和提供足够资源。
Ø监督和控制该过程，收集过程信息，并采取适当的纠正措施。
Ø高层管理者评审该过程、并解决问题。
4.2.15技术评审
Ø定义要进行技术评审的产品标准。
Ø项目组在项目规划时制定技术评审计划。
Ø技术评审需有同类产品开发经验的人参与。
ØQA应参与项目阶段重要产品的技术评审活动。
Ø技术评审小组应记录产品缺陷，QA跟踪解决过程。
4.2.16缺陷管理
Ø缺陷管理应覆盖到项目规划开始至产品维护期间。
Ø对组件、产品缺陷的产生、处理、验证要有完整的记录。
Ø该过程制度化，并对该过程分配责任和提供足够资源。
ØQA组定期审核缺陷管理的活动，并报告结果。
4.2.17系统维护
Ø系统维护包括客户咨询服务和产品维护，以提高用户满意度为宗旨。
Ø系统维护过程应有完整的记录。
Ø该过程制度化，并对该过程分配责任和提供足够资源。
4.2.18配置管理
Ø项目开发过程中的阶段产品需要纳入配置管理系统。
Ø采用集中的配置管理系统，CMO负责配置管理系统的管理和维护。
每个项目组指定一个配置管理人员，并制定项目配置管理计划。
Ø指定CM职责，并在整个项目开发过程中执行CM活动。
Ø项目经理、CMO、高级经理、QA人员定期审计产品基线和CM活动。
Ø对项目工作产品进行有效标识，产品基线变更受到严格控制。
Ø产品基线内容和状态应及时/定期通知共利益者。
ØQA定期审计CM的活动，并报告结果。
4.2.19过程与产品质量保证
Ø为满足用户对产品的质量要求，每个项目组指派一个QA人员（专职或兼职），QA人员制定质量保证计划。
Ø应赋予QA一定权限，使QA能独立的开展质量保证工作，QA报告有独立的报告渠道给高层经理。
ØQA按计划参与项目组的技术评审活动。
ØQA按计划检查项目组的过程和产品质量，对检查出的不符合项及时通知项目经理，并跟踪不符合项的解决过程。
ØQA记录QA活动和审计结果。
ØQA经理定期审计QA的QA活动和相关记录。
Ø高层经理处理项目组内部不能解决的不符合项或豁免不符合项。
4.2.20度量和分析
Ø使测量目标规定和测量行为与信息需要和目标相一致。
Ø把测量目标进一步精练成精确的、定量的度量项目。
Ø项目经理按《度量数据收集、分析及存储规程》收集存储数据，定期提供度量数据分析报告。
Ø向项目共利益者通报分析数据。
ØQA人员监督度量和分析过程。
Ø高层经理评估度量分析报告，并给出改进意见。
4.2.21决策分析和解决方案
Ø确定决策分析的进入准则和选择决策方案的原则。
Ø针对决策的问题确定多选方案。
Ø在项目或产品生存周期的任何阶段运用所拟定的准则评价侯选方案，最终确定方案。
Ø该过程作为已定义过程并制度化，进行过程管理责任分配，人员培训及资源配置。
Ø高层管理者评审该过程活动、状态和结果，并解决问题。
4.2.22项目结项
Ø确定项目结项的准则。
Ø总结项目的经验教训，丰富组织过程资产库。
Ø根据项目过程数据，对项目进行评估和考核。
Ø高层管理者和行业技术专家参与项目结项过程。
5过程改进组织结构
公司过程改进活动组织结构如下：
MSG：
公司项目管理委员会，是公司进行过程改进的最高权威机构，由公司主管软件技术部门的副总裁负责MSG的领导工作。
cmmi经理：
公司研发中心项目管理办公室经理，负责过程改进的各项具体工作。
EPG：
负责软件过程规范的制定、修改完善及实施指导；
QAG：
监督规范的实施，确保所有项目以及相关部门准照规范开展工作。
分析并解决机构内存在的共性质量问题，协组EPG完善规范。
CM：
组织级的配置管理。
TG：
组织级的过程规范培训小组（成员可由EPG成员兼任），负责组织内的软件过程规范的培训工作。
6过程改进政策
6.1公司领导的支持
1）、公司主管领导批准用于软件过程改进的必要经费，例如支付咨询费，购买相关软件工具等。
2）、公司主管领导组建EPG和QAG，专门从事软件过程改进工作及质量保证工作。
EPG的主要职责是建立适合于组织的过程规范，QAG的主要职责是监督该规范的实施。
建议让EPG和QAG的部分人员重叠，这些人既是EPG成员又是质量保证员，扮演两种角色。
这样不仅节约人力资源，并且提高了工作效果（由制定规范的人去监督规范的实施最合适不过）。
一般地，EPG成员和质量保证员共占组织软件技术部门总人数的5%左右。
3）、公司主管领导和高层经理不仅要口头支持，还要亲自参与软件过程改进的实践。
例如参加培训、按照过程规范执行立项管理、参与过程规范的建立及改进的评审和审批等。
6.2项目管理委员会（MSG）的职责
1）、将PI规划与组织的商业目标和战略联系起来；
2）、提供过程改进所需的资源和资金支持
3）、参与组织过程改进计划的评审；
4）、监督EPG活动；
5）、制定对过程改进活动的奖惩制度。
6.3质量管理的政策
质量管理的口号是：
“在开发过程之中内建质量而非修补质量”。
质量管理有几种基本措施：
“质量保证”、“技术评审”和“测试”。
1）、质量保证
公司的质量保证员周期性地检查项目成员的“工作过程以及工作成果”是否符合既定的规范，来监控和改进“过程质量以及产品质量”。
公司的质量保证员独立于任何项目，并赋予他一定的权利，对质量不合格的工作成果作出处理。
2）、技术评审
在工作成果刚产生之际，对其进行技术评审（评审的形式有多种方式），目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而提高产品的质量。
如果时间允许的话，应当尽可能多地对产品的重要工作成果进行技术评审。
技术评审活动由项目开发团队组织。
3）、测试
测试是指通过运行测试用例来找出软件中的缺陷。
测试与技术评审的主要区别是前者要运行软件而后者不必运行软件。
一般地，产品开发过程中有四个测试阶段：
单元测试、集成测试、系统测试和验收测试（或Beta测试）。
其中单元测试和集成测试可以由项目开发团队组织。
系统测试阶段必须有项目外的人员参与，以保证系统测试的客观性。
验收测试（或Beta测试）由技术部门组织或客户组织（研发项目由技术部门组织测试，合同项目由客户组织测试）。
在条件允许的情况下，技术部门应成立专门的测试小组从事单元测试、集成测试和系统测试工作。
6.4工程过程小组的政策
公司主管领导任命一位熟悉软件工程、项目管理、CMM/CMMI并且有丰富工作经验的人担任EPG的负责人。
在公司主管领导的许可下，该负责人组建EPG（成员可以是全职的也可以是兼职的）。
EPG小组应按《EPG章程》开展各项工作。
6.5质量保证小组的政策
公司主管领导任命任命一位熟悉过程规范并且有丰富的质量管理经验的人担任QAG的负责人（或称为质量经理）。
在公司主管领导的许可下，该负责人组建QAG（成员可以是全职的也可以是兼职的）。
QAG在行政上独立于任何项目。
这种独立性有助于质量保证员客观地检查和监控“过程以及产品的质量”。
QAG按照EPG制定的“质量保证规范”开展工作。
公司主管领导赋予QAG一定的权利，可以对质量不合格的工作成果做出处理。
这种权利使得QAG的工作不会被轻视，并有助于加强全员的质量意识。
对于QAG与项目之间出现的难以调和的争议，由高层经理或公司主管领导处理。
6.6项目团队的政策
项目中的任何管理人员、开发人员、测试人员等，必须学习与本职工作相关的过程规范，每个人都必须明白自己“应当在什么时候依据什么规范做什么事情”。
项目经理应当树立榜样，并且督促项目成员们按规范做事。
允许项目经理根据本项目的特征，在EPG和QAG的指导下，适当地裁剪或扩充组织的过程规范，从而快速建立本项目的过程规范。
这项工作应当在“项目规划过程域”中完成，并在《项目计划》中体现出来。
如果项目对机构过程规范的裁剪幅度比较大，遭到QAG的反对，如果双方不能达成共识，则由高层经理或公司主管领导处理该争议。
EPG对项目过程能力的评估成绩将作为评定项目人员工作业绩的重要因素，具体比重由高层经理和公司主管领导决定，一般占30％以上的比重。
升级会员 