研发过程管理工作规范.doc

研发过程管理工作规范1文档说明1.1编制说明本文档为*公司研发过程管理规范规划及实施阶段对总体项目进行技术、管理和控制方面的总体指导性文件。 1.2适用范围本规范适用于*公司研发过程。1.3起草单位*公司研发部SEPG小组。1.4解释权本规范的解释权属于*公司研发部SEPG小组。1.5版权 本规范的版权属于*公司。 1.6 参考资料 2002.5 “The Rational Unified Process An Introduction (Second Edition)” Philippe Kruchten1 2001.12 “The Capability Maturity Model Guidelines for improving the Softwaew Process” SEI 2003.10 “Six Sigma Software Development” Christine B. Tayntor1.7 缩写说明 PM：Project Manager项目经理RUP: Rational Unified ProcessCMM: Capability Maturity Model过程能力模型ISO: International Standards Organize 国际标准化组织QA: Quality Administer 质量管理QC: Quality Control质量控制CCB: Change Control Board 变更管理委员会CM: Configuration Management 配置管理SEPG: Software Engineering Process Group 软件过程管理小组SDP: Software Development Plan 软件开发计划CR: Change Require 变更需求 KPA: Key Practice Area 关键过程域RM: Requirement Manager 需求管理2 概述我们都知道一个项目的主要内容是：成本、进度、质量；良好的项目管理就是综合三方面的因素，平衡三方面的目标，最终依照目标完成任务。项目的这三个方面是相互制约和影响的，有时对这三方面的平衡策略甚至成为一个企业级的要求，决定了企业的行为。影响软件项目进度、成本、质量的因素主要是 “人、过程、技术”。在当今日益激烈的竞争社会中，客户的满意程度已经成为许多软件机构生存和兴旺发达的准则，软件质量也被定义为满足客户需求的产品为高质量的软件产品。但是不科学，不合理的软件开发过程；对软件只重视开发不重视需求分析，设计，测试等种种弊端在许多软件公司中仍旧存在，随着软件在我们生活中的日益普及，持续了二三十年的软件危机变得更为突出，这些都已经严重影响软件公司的生存和发展。所以，建立一套比较规范的，适合于本公司软件质量控制规范，对于软件公司的生存已经到了至关重要的地步。目前国际上比较流行的软件工程产品和思想有国际标准组织的ISO-9000,卡纳吉梅隆大学美国软件工程研究所（SEI）制定的CMMI, Rational公司创建的RUP以及摩托罗拉公司提出的6SIGMA等。各标准化组织都建议企业应该结合本公司特点，以质量标准化方案作为指南，建立起一套适合于本公司的软件质量控制是加强本企业软件质量控制的关键所在。附：软件危机的种种表现： 需求变更频繁，软件公司陷于困境：据报告，全球所有的以取消结束的软件项目90%都是需求得不到很好的管理，造成项目无限制的拖延，最终造成项目取消； 人员变更频繁，公司产品无法得到延续：由于目前IT公司人员流动现象十分普遍，没有良好的软件过程作为后盾，人员流失就意味资源和知识的流失，从而不断延长软件开发时间； 没有合理的质量流程，产品bug无法得到有效的控制； 3软件质量控制原则3.1以预防为中心对于质量控制方法上通常为检测和预防，而人们大多数都比较重视检测工作，成立测试部门在产品开发完毕进行测试。不可否认测试是整个软件工程中是一个非常重要的环节，但是预防从某种意义上来讲，比测试更为重要。打个比方，造一座大楼，如果在大楼设计后对大楼设计图纸进行检测发现问题，要比大楼施工完毕再发现问题资金，人力开销都小得多。再看一个数据，据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计，得出这样一个结论：软件缺陷在开发前期发现比在开发后期发现资金，人力上节约90%；软件缺陷在推向市场前发现比在推出后发现资金，人力上节约90%。所以说软件的缺陷应该尽早提出，在整个公司软件开发工程中，每个阶段都有相应的对产品的质量控制（QC）,和对过程的质量保障（QA）体系。3.2降低偏差换句话来说就是增加一致性，一致性是非常重要的，因为一致性是可以预防的，可以预防就可以纠正。对于打靶来说，选手A的六个镖平均分布在靶的四周，有一个是击中靶心；选手B六个靶都没有击中靶心，但是都集中在靶的左上方。一般人认为选手A比选手B打得好，但是对于改进来说选手B要比选手A更好控制，因为选手B的偏差小，只要检查一下是否改选手握靶位置不对，或者没有考虑风的因素，就可以很容易达到全中，所以一致性是公司的质量奋斗目标。3.3以客户为中心一个好的质量产品是这样定义的，它能够最大限度的满足客户的需求，不管技术人员认为存在某某不合理的地方。以客户为中心是所有质量体系都遵循的原则，不管是ISO还是CMM。道理很简单，没有客户，公司就没有存在的必要。在我们公司来说，提高质量就需要整个软件开发过程中严把需求关。3.4协同工作先进的软件公司是一个走出软件作坊式的公司，项目的成败不在于某几个人的努力（又叫个人英雄主义），即CMM1级。现阶段的软件公司需要大家协同工作，共同努力，互相协调，互为补充，共同提高公司的软件产品质量。4 工作定位研发过程管理工作按照著名的PDCA循环进行工作，我们首先定义出一些工作模版，工作流程，评审工作以及角色定义。研发部员工在使用过程中必须按照规定执行，但希望大家及时提出自己的观点和建议，我们随时进行调整并发布给大家，以便越来越适用于公司的需求。 计划阶段：按照（上一轮）需求计划过程、角色和文档； 执行阶段：由定义的角色在工作中按照定义的流程，执行相应的工作，产出相应的文档； 检查阶段：大家在实施过程中，遇到问题随时提出，对文档、过程、角色进行检察； 改进阶段：按照大家提出来的合理化建议和意见，对文档、过程、角色进行修正，修改。然后进入下一轮循环，以便越来越适合公司，提高公司的质量水平 5过程工作5.1过程5.1.1主过程 图二 总体流程 按照管理角度来说整个流程分为概念、计划、实施、发布与维护、结项几个阶段工作 按照技术角度来说分为需求、设计、编码、测试、部署几个阶段工作整个过程中受培训、质量管理、配置管理、需求管理、风险管理和项目管理工作监控过程中的工作： 概念阶段主要工作为：调研、可行性分析、立项、定义需求规格； 计划阶段主要工作为：项目计划、项目估计、定义需求规格； 实施计阶段划主要工作为：概要设计、用户界面设计、详细设计、数据库设计； 实施编码阶段主要工作为：编码、单元测试； 实施测试阶段主要工作为：集成测试、系统测试、测试总结； 发布阶段主要工作为：产品发布、验收测试、产品维护； 结项阶段主要工作为：结项，项目总结。每个阶段产生的文档在图二中表现出来了，由于纸面原因培训、质量管理、配置管理、需求管理、风险管理和项目管理的文档没有表示出来具体请看下一节5.2文档文档Process.vsd中对每个阶段定义了子流程，主要分为：需求与需求管理、分析设计、编码、测试发布、测试、配置和变更管理、项目管理，除了测试发布以外每一个子过程都是基本按照RUP的流程来制定的。这里每一个阶段又定义了子阶段，子阶段为这个阶段的内部里程碑。 需求与需求管理中子里程碑为确认需求、定义需求和管理变更； 分析设计中子里程碑为概要设计和详细设计； 编码中子里程碑为开发和集成； 测试阶段子里程碑为测试计划、测试设计、测试编码、测试执行和测试总结 配置和变更管理子里程碑分为配置计划和配置管理 项目管理子里程碑分为项目计划、项目监控和项目结项 对于子流程的具体细节，请参见Process.vsd文档。从图二可以看出来，一共包括计划、设计、编码、测试、交付、结项六大评审每一个大的阶段完成，必须通过相关的评审才可以进入下一个阶段；项目中的内部里程碑也同样需要相应的评审工作才可以进入下一阶段。5.1.2研发过程管理的工作1.制定整体项目实施计划 制定整体项目组织架构和沟通机制 分析各子项目实施计划并确定关联性制定整体项目进度基准 制定整体项目人力资源配置计划 制定整体项目成本基准 制定整体项目质量管理及风险管理计划 形成整体项目实施计划 执行整体项目实施计划 监控各子项目的实施进程 检测并报告整体项目实施进程 协调解决子项目间争议 管理整体项目实施质量 管理整体项目实施成本 管理整体项目实施风险 组织项目相关培训和知识转移 5.2文档5.2.1文档及其缩写文档按照阶段分类如下，在这里不考虑指南性质和评审文档。由于考虑到每个项目的复杂性，设立通用模版供大家使用，大家在要求的文档前提下，可以自己设计所需的文档。具体要求的文档如下：阶段 名称 缩写 过程与度量 过程依从性检查单 PCC 度量方法MM 立项 调研计划书 RAP 调研作业指导书 RAG 立项可行性分析报告 FRS 立项建议书 CA 立项调查报告 CR 立项评审报告CRP结项 项目总结报告 PDSP 结项申请书 FPR 结项评审报告FPRR结项 项目总结报告PDSP 结项申请书 FPR 结项评审报告 FPRR 项目计划 项目计划变更控制报告 PDP 项目计划项目计划附件PP 项目估计表 PET 项目监控 项目监控数据表PID 项目管理过程 PMP 项目偏差数据表PWD项目进展报告PER风险管理 风险检查表RC风险管理报告 RMP需求及需求管理 产品需求规格说明书 SRS 需求变更控制报告 RMP需求跟踪报告 RTR 设计 体系结构设计报告 PDS用户界面设计 UID数据库设计报告 DBS模块设计报告 IDD技术预研 技术预研计划 TBP 技术预研报告 TBR 源代码 CODE产品特性表PCT测试 测试计划书 TP 测试用例书 TC测试报告 TR Beta测试协议BTP Beta测试报告BTR 软件配置 配置管理计划 CMP 配置库管理报告 CMR 配置项变更控制报告CCCR 计划评审检查单PRC 软件配置管理过程 SCCP 状态统计表SST 客户验收 客户验收计划 PAP 客户验收报告 PAR技术评审 技术评审计划 TRP技术评审通知 TRI 技术评审报告 TRR外包与采购管理 外包开发竞标邀请书 EPCI 外包开发合同 EEC 外包开发过程监控报告 EEPIR 采购竞标邀请书 SCI 承包商评估报告CEP外包开发成果验收报告 EEPCAR 供应商评估报告 SEP 采购合同 SC 采购物品验收报告 SGCAR 培训 培训计划 TP培训通知 TI培训评估报告 TRP 产品维护计划 客户服务计划 CSP 客户服务报告 CSR产品维护计划MP产品维护报告 MQ质量保证 质量保证计划 SQAP 质量保证检查表 SQACT 质量保证报告 SQAR 质量问题跟踪表 SQQTT 5.2.2文档编码规范 一般文档：FreeSky-Project-缩写：比如：办公自动化（OA）项目需求文档：FreeSky-OA-SRS 记录文档 FreeSky-Project-Report-YYMMDDPP比如：2006年9月16日 OA产品第5次会议纪要：FreeSky-OA-Report-2006091605 评审文档FreeSky-Project-缩写-Review-YYMMDDPP比如2006年10月26日OA产品第二次需求额评审报告：FreeSky-OA-SRS-Rewiew-2006102602 指南文档FreeSky-Project-Guide-YYMMDDPP比如2006年11月06日建立的OA产品如何书写需求报告，为OA项目的第4份指南文件：FreeSky-OA-Guide-2006110604 5.3角色根据公司目前状况，角色主要分为部门经理、项目经理、开发经理、客户经理、需求分析师、系统架构师、设计师、美工、软件工程师、集成工程师、数据库管理员、系统管理员、测试经理、测试设计人员、测试开发人员、测试工程师.他们的职责表如下：名称职责 部门经理 负责分配部门资源，确定优先级，协调与客户和用户之间的沟通。尽量使项目团队一直集中于正确的目标。部门经理还要建立一套工作方法，以确保部门工件的完整性和质量。 项目经理 负责分配资源，确定优先级，协调与客户和用户之间的沟通。总而言之，就是尽量使项目团队一直集中于正确的目标。项目经理还要建立一套工作方法，以确保项目工件的完整性和质量。 开发经理 负责分配资源，尽量使项目团队一直集中于正确的目标,确保项目工件的完整性和质量。 客户经理 代表客户对项目进行评审、验收等工作，是项目组与最终客户之间的接口 需求分析师 系统分析员通过概括系统的功能和界定系统来领导和协调需求获取及用例建模。例如，确定存在哪些主角和用例，以及他