软件项目管理第六章软件过程管理本章内容提要软件过程与过程管理CMMI概述CMMI的成熟度等级及其过程域CMMI的应用PSP,TSP与CMMI敏捷软件开发方法第一节软件过程与过程管理软件过程(SoftwareProcesses)是指软件开发人员开发和维护软件及相关产品(如项目计划、设计文档、代码、测试用例和用户手册)的一套行为、方法、技术及变换过程。不能把软件过程简单地理解为软件产品的开发流程。从大量项目实践中归纳总结出的行之有效的过程称为最佳实践(BestPractices)。软件过程管理就是对最佳实践进行有效的积累,形成可重复的软件过程,使最佳实践在组织范围内共享。软件过程管理可将个人能力转变为企业的能力。软件过程管理的主要内容包括过程定义和过程改进。过程定义是指对最佳实践进行总结,形成一套稳定的、可重复的软件过程。过程改进是指根据实践中对软件过程的使用情况,对软件过程中的偏差和不足之处进行不断优化。软件过程管理和软件项目管理的关系互相依赖,互相促进组织级过程资产项目过程TailorWhenprojectcoming!!!Improve第二节CMMI概述CMMI(CapabilityMaturityModelIntegration)即能力成熟度模型集成,由CMM(CapabilityMaturityModel)发展而来,它最早是应用于软件业的一个过程改进模型,为软件组织描述了从混乱的、不成熟的软件过程向成熟有序的软件过程进行改进的一条途径。后来随着应用的推广和模型本身的发展,CMMI逐渐演化成为一个被广泛应用的综合性过程改进模型。CMMI的历史1991年,美国卡耐基梅隆大学软件工程研究所(SEI)推出了能力成熟度模型CMM,CMM的作用各主要有两方面:为软件客户提供评价软件开发商能力的方法。帮助软件开发商改进其软件过程,提高成熟度。随着CMM在软件界应用的不断推广,其它相关学科和领域也采用它的模式,开发出了许多类似于CMM的模型。SE-CMM(SystemEngineeringCMM)系统工程CMM,应用于系统工程管理。SA-CMM(SoftwareAcquisitionCMM)软件获取CMM,应用于软件获取(采购)方的能力成熟度模型。CMMI的历史IPD-CMM(IntegratedsystemsproductDevelopmentCMM):集成系统产品开发CMM,应用于集成系统产品的开发管理。P-CMM(PeopleCMM):人员能力成熟度模型,应用于人力资源管理。为了以示区别,常把CMM叫做SW-CMM。同一个组织可能会应用多个过程改进模型,但多个过程改进模型的并存可能会引起冲突和混淆。CMMI的历史CMMI为工业界和政府部门提供了一个集成的能力成熟度模型产品集,消除了不同模型之间的不一致和重复,降低了过程改进的成本。CMMI覆盖了软件工程、系统工程、集成产品开发和系统采购,以更加系统和一致的框架来指导组织改善软件过程,提高产品和服务的开发、获取和维护能力。CMMI1.0版于2000年发布,2002年又发布了1.1版,2006年发布了1.2版。CMMI的历史CMMI是目前世界公认的软件产品进入国际市场的通行证。一般来说,通过CMMI认证的级别越高,就越容易获得用户的信任,在国内、国际市场上的竞争力也就越强。2000年6月,国务院颁发了《鼓励软件产业和集成电路产业发展若干政策》,其中第17条中明确规定“鼓励软件出口型企业通过CMM认证,其费用通过中央外贸发展基金适当予以支持”。随后各省市、高新区、软件园都出台了对通过CMM的企业给予资金奖励的制度。CMMI的历史软件过程成熟度软件过程成熟度指一个具体的软件过程被明确和有效地定义、管理、度量、控制和实施的程度。软件组织成熟的过程是一个不断改进、循序渐进的过程,而不是通过革命性的革新快速实现的。不成熟组织与成熟组织的对比不成熟的组织成熟的组织软件过程一般在项目进行中临时确定,有时确定了也不严格执行。建立了机构级的软件开发和维护过程,软件人员按照计划完成活动。被动地处理软件项目中的一些突发事件。具有对软件项目的监控和主动应对风险的能力。进度和经费预算估计得不准确,进度延期导致削减软件功能,降低软件质量。项目进度和预算是根据以往项目取得的实践经验确定,比较符合实际情况。产品质量难以预测。软件产品质量由质量保证部门负责监控。CMMI中的成熟度等级初始级:软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力。管理是反应式的。已管理级:建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验。已定义级:已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。量化管理级:分析软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。管理活动有一个作出结论的客观依据,能够在定量的范围内预测性能。CMMI中的成熟度等级优化管理级:过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。CMMI中的成熟度等级CMMI是一个引导软件组织不断走向成熟的过程模型。CMMI中的成熟度等级初始级已管理级已定义级量化管理级优化管理级有纪律的过程标准一致的过程可预见的过程不断改进的过程成熟度等级的结构成熟度等级过程域1过程域2过程域n…特定目标共性目标特定实践共性实践CMMI的关键过程域每个成熟度等级包含若干个关键过程域(KeyProcessArea,KPA)。KPA表示当软件组织改进软件过程时必须集中精力解决的关键问题。一个组织要想达到某个成熟度等级,必须满足该等级(以及较低等级)包含的KPA的所有要求,满足每个KPA的所有目标。CMMI的关键过程域成熟度等级关键过程域缩写词等级2:已管理级需求管理REQM项目计划PP项目监督与控制PMC供应商协议管理SAM度量和分析MA过程和产品质量保证PPQA配置管理CM等级3:已定义级需求开发RD技术解决方案TSCMMI的关键过程域(续)成熟度等级关键过程域缩写词等级3:已定义级产品集成PI验证VER确认VAl组织过程核心OPF组织过程定义OPD组织培训OD集成项目管理IPM风险管理RSKM决策分析与解决DARCMMI的关键过程域(续)成熟度等级关键过程域缩写词等级3:已定义级集成供应商管理ISM组织集成环境OEI集成团队IT等级4:量化管理级组织过程性能OPP量化项目管理QPM等级5:优化管理级组织革新与部署OID原因分析与解决CARCMMI的能力等级能力等级(CapabilityLevel,CL)是指在一个单独的过程域中执行的良好程度。CMMI包括6个能力等级:CL0,不完整级:过程域的一个或多个目标没有被满足。CL1,已执行级:过程通过转换可识别的输入工作产品,产生可识别的输出工作产品。能实现过程域的特定目标。CL2,已管理级:过程作为已管理的过程制度化。CL3,已定义级:过程作为已定义的过程制度化。CL4,量化管理级:过程作为量化管理的过程制度化。CL5,优化级:过程作为优化的过程制度化。CMMI的能力等级CMMI是什么?CMMI指明该做什么,但没有指明如何做,它不是方法论,没有给出特定应用领域内的专门技术。CMMI是一个用于改进软件产品和管理过程的结构化模型,但是仅描述软件过程的本质属性,并非涉及软件工程的所有问题。CMMI是从软件过程角度定义了成熟的软件过程的实践活动,但是对于成熟的软件组织而言,人的因素和技术的因素也同样重要。CMMI过程改进需要多长时间?有何效果?一般需要2年才能把成熟度提升一级(建议安排1.5年到2年)。根据CMU-SEI的统计,软件企业在引入CMM后劳动生产率平均增长了35%;错误比率平均减少39%;平均成本回报率为5:1。第三节CMMI的成熟度等级及其过程域3.1初始级过程极少存在或使用稳定的软件过程。(过程无秩序)各种条例、规章制度互不协调,甚至互相矛盾。(开发无规范)初始级人员依赖个人努力和精英人物;项目组成员的工作方式就是哪里出现危机就去哪儿解决。技术引进新技术是很大的风险。度量不收集和分析数据。注意:有些组织制定了一些软件工程规范,但如果这些规范没有覆盖基本的关键过程域,且执行没有政策、资源方面的保证时,那么该组织仍然被视为处于初始级成熟度。初始级改进方向建立项目管理过程,实施规范化管理,保障项目的承诺。进行需求管理,建立客户与软件项目之间的共同理解,使项目真正反映客户的要求。建立各种软件项目计划。如:软件开发计划、配置管理计划、风险管理计划等。开展软件质量保证活动。初始级3.2CMMI已管理级特征:进行较为现实的承诺,按以前在同类项目上的成功经验建立必要的过程准则以确保再一次成功。逐个项目地建立基本过程管理条例来加强软件过程能力。建立了基本的项目管理过程来跟踪成本、进度和功能,包括:需求管理、计划和跟踪监控、质量管理、配置管理、子合同管理。通过执行这些过程,从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。特征:管理工作主要跟踪软件经费支出、进度和功能,识别在承诺方面出现的问题。采用基线(baseline)来标志进展,控制完整性。定义了软件项目的过程标准,并遵循它。通过子合同建立有效的供求关系。过程软件开发和维护过程是相对稳定的,但过程建立在项目级别,而非企业级别。软件工程过程受控于有效的工程管理过程,先前的成功经验可以被重复使用。问题出现时,有能力识别并纠正,承诺可以兑现。CMMI已管理级人员理解管理的必要性并对管理有承诺。注意人员的培训。技术建立技术支持活动,并有稳定的计划。度量有计划地收集、分析有关项目过程和产品的数据。CMMI已管理级已管理级的改进方向不再按项目制定软件过程,而是总结各种项目的成功经验,使之规则化,把具体经验归纳为全组织机构的标准软件过程。将改进组织机构整体软件过程能力作为软件组织的责任。确定全组织机构的标准软件过程,把软件工程及管理活动集成到一个稳固而确定的软件过程中。从而可以跨项目改进软件过程效果。建立软件工程过程小组(SEPG),长期承担评估与调整软件过程的任务,以适应未来软件项目的要求。积累数据:建立组织机构的软件过程库及软件过程相关的文档库。加强人员培训。已管理级的改进方向已管理级的关键过程域需求管理项目计划项目监督与控制供应协议管理过程与产品质量保证配置管理度量与分析需求管理需求管理(RequirementsManagement,ReqM)是指在客户和项目组之间就客户的需求建立一个协议并加以管理。该协议包括技术需求和非技术需求两个方面,它构成了整个产品生命周期中估计、计划、执行和跟踪项目活动的基础。目标控制系统的需求,为工程和管理活动建立基线。保持计划、产品和活动与系统的需求一致。需求管理划分为以下5个独立的过程:需求获取:通过与用户的交流,对现有系统的观察及对业务的分析,从而开发、捕获和修订用户的需求。需求分析:也称需求建模,是为最终用户所看到的系统建立一个概念模型,是对需求的抽象描述。需求规格:以开发人员可用的技术形式,描述一个产品所应具有的特征和性质,形成需求规格说明书。需求管理过程需求验证:开发人员和用户对需求规格进行分析和验证。需求变更:采用正式的审批流程来管理需求的变更,使需求变更产生的影响是可控的。变更审批流程包括4个主要活动:变更申请、变更评估、批准/拒绝变更、实现变更。需求管理过程项目计划项目计划(ProjectPlanning)的目标是为实施和管理项目制定合理的计划。要制定合理的计划,就要对需要完成的工作做出比较实际的估计,并为完成这些工作建立一些必要约定。项目计划首先对要进行的工作、项目的约束条件和项目的目标进行描述。项目计划过程包括如下步骤:定