研发过程管理工作规范
| 分类: 质量保障 | 
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. Tayntor
1.7
缩写说明 
PM:Project
Manager项目经理
RUP: Rational Unified Process
CMM: 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循环进行工作,我们首先定义出一些工作模版,工作流程,评审工作以及角色定义。研发部员工在使用过程中必须按照规定执行,但希望大家及时提出自己的观点和建议,我们随时进行调整并发布给大家,以便越来越适用于公司的需求。
http://developer.51cto.com/files/uploadimg/20061030/1623340.jpg
图1:PDCA循环
◆计划阶段:按照(上一轮)需求计划过程、角色和文档;
◆执行阶段:由定义的角色在工作中按照定义的流程,执行相应的工作,产出相应的文档;
◆检查阶段:大家在实施过程中,遇到问题随时提出,对文档、过程、角色进行检察;
◆改进阶段:按照大家提出来的合理化建议和意见,对文档、过程、角色进行修正,修改。
然后进入下一轮循环,以便越来越适合公司,提高公司的质量水平。
5.过程工作
5.1过程
5.1.1主过程
http://developer.51cto.com/files/uploadimg/20061030/1623341.jpg
图2:总体流程
◆按照管理角度来说整个流程分为概念、计划、实施、发布与维护、结项几个阶段工作
◆按照技术角度来说分为需求、设计、编码、测试、部署几个阶段工作
整个过程中受培训、质量管理、配置管理、需求管理、风险管理和项目管理工作监控过程中的工作:
◆概念阶段主要工作为:调研、可行性分析、立项、定义需求规格;
◆计划阶段主要工作为:项目计划、项目估计、定义需求规格;
◆实施计阶段划主要工作为:概要设计、用户界面设计、详细设计、数据库设计;
◆实施编码阶段主要工作为:编码、单元测试;
◆实施测试阶段主要工作为:集成测试、系统测试、测试总结;
◆发布阶段主要工作为:产品发布、验收测试、产品维护;
◆结项阶段主要工作为:结项,项目总结。
每个阶段产生的文档在图二中表现出来了,由于纸面原因培训、质量管理、配置管理、需求管理、风险管理和项目管理的文档没有表示出来具体请看下一节5.2文档。
文档Process.vsd中对每个阶段定义了子流程,主要分为:需求与需求管理、分析设计、编码、测试发布、测试、配置和变更管理、项目管理,除了测试发布以外每一个子过程都是基本按照RUP的流程来制定的。这里每一个阶段又定义了子阶段,子阶段为这个阶段的内部里程碑。
◆需求与需求管理中子里程碑为确认需求、定义需求和管理变更;
◆分析设计中子里程碑为概要设计和详细设计;
◆编码中子里程碑为开发和集成;
◆测试阶段子里程碑为测试计划、测试设计、测试编码、测试执行和测试总结
◆配置和变更管理子里程碑分为配置计划和配置管理
◆项目管理子里程碑分为项目计划、项目监控和项目结项
对于子流程的具体细节,请参见Process.vsd文档。
从图二可以看出来,一共包括计划、设计、编码、测试、交付、结项六大评审
每一个大的阶段完成,必须通过相关的评审才可以进入下一个阶段;项目中的内部里程碑也同样需要相应的评审工作才可以进入下一阶段。
5.1.2研发过程管理的工作
(1)制定整体项目实施计划
◆制定整体项目组织架构和沟通机制
◆分析各子项目实施计划并确定关联性制定整体项目进度基准
◆制定整体项目人力资源配置计划
◆制定整体项目成本基准
◆制定整体项目质量管理及风险管理计划
◆形成整体项目实施计划
(2)执行整体项目实施计划
◆监控各子项目的实施进程
◆检测并报告整体项目实施进程
◆协调解决子项目间争议 
◆管理整体项目实施质量 
◆管理整体项目实施成本 
◆管理整体项目实施风险 
◆组织项目相关培训和知识转移
5.2文档
5.2.1文档及其缩写
文档按照阶段分类如下,在这里不考虑指南性质和评审文档。由于考虑到每个项目的复杂性,设立通用模版供大家使用,大家在要求的文档前提下,可以自己设计所需的文档。
具体要求的文档如下:
 
 
| 
 阶段 
 | 
 名称 
 | 
 缩写 
 | 
| 
 过程与度量 
 | 
 过程依从性检查单 
 | 
 PCC 
 | 
| 
 度量方法 
 | 
 MM 
 | 
|
| 
 立项 
 | 
 调研计划书 
 | 
 RAP 
 | 
| 
 调研作业指导书 
 | 
 RAG 
 | 
|
| 
 立项可行性分析报告 
 | 
 FRS 
 | 
|
| 
 立项建议书 
 | 
 CA 
 | 
|
| 
 立项调查报告 
 | 
 CR 
 | 
|
| 
 立项评审报告 
 | 
 CRP 
 | 
|
| 
 结项 
 | 
 项目总结报告 
 | 
 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角色
根据公司目前状况,角色主要分为部门经理、项目经理、开发经理、客户经理、需求分析师、系统架构师、设计师、美工、软件工程师、集成工程师、数据库管理员、系统管理员、测试经理、测试设计人员、测试开发人员、测试工程师。他们的职责表如下:
 
 
| 
 名称 
 | 
 职责 
 | 
| 
 部门经理 
 | 
 
负责分配部门资源,确定优先级,协调与客户和用户之间的沟通。尽量使项目团队一直集中于正确的目标。部门经理还要建立一套工作方法,以确保部门工件的完整性和质量。 
 | 
| 
 项目经理 
 | 
 
负责分配资源,确定优先级,协调与客户和用户之间的沟通。总而言之,就是尽量使项目团队一直集中于正确的目标。项目经理还要建立一套工作方法,以确保项目工件的完整性和质量。 
 | 
| 
 开发经理 
 | 
 负责分配资源,尽量使项目团队一直集中于正确的目标,确保项目工件的完整性和质量。 
 | 
| 
 客户经理 
 | 
 代表客户对项目进行评审、验收等工作,是项目组与最终客户之间的接口 
 | 
| 
 需求分析师 
 | 
 
系统分析员通过概括系统的功能和界定系统来领导和协调需求获取及用例建模。例如,确定存在哪些主角和用例,以及他们之间如何交互。 
 | 
| 
 系统架构师 
 | 
 设计系统整体框架 
 | 
| 
 设计师 
 | 
 设计系统细节 
 | 
| 
 美工 
 | 
 制作可作为产品包装一部分的产品标识图案,设计用户界面 
 | 
| 
 软件工程师 
 | 
 
制订公司的编程手册和编程规范;严格按照设计任务书的要求和编程规范在规定的时间内完成程序的编写和单元测试的工作;负责完成程序修改; 
 | 
| 
 集成工程师 
 | 
 集成软件产品 
 | 
| 
 数据库管理员 
 | 
 负责数据库的维护、性能调优等 
 | 
| 
 系统管理员 
 | 
 负责维护支持开发环境、硬件和软件、系统管理、备份等。 
 | 
| 
 测试经理 
 | 
 
负责测试工作的组织与管理,各项目测试计划的编写,测试任务的调度与安排等。具体包括:制定与实施测试管理方案;获取适当的资源,管理测试资源;控制测试进度;测试活动评审;提供管理报告。 
 | 
| 
 测试设计人员 
 | 
 测试设计员是测试中的主要角色。该角色负责对测试进行计划、设计、实施和评估,包括:
生成测试计划和测试模型;执行测试过程;评估测试范围和测试结果,以及测试的有效性 ;生成测试评估摘要 
 | 
| 
 测试开发人员 
 | 
 开发测试代码 
 | 
| 
 测试工程师 
 | 
 测试员负责执行测试,其职责包括:设置和执行测试;评估测试执行过程并修改错误 
 | 
 
5.4过程组织
过程组织主要有变更控制委员会CCB以及评审委员会。
作者介绍
jerry 
 

加载中…