【培训】软件过程的管理与改进ppt课件_第1页
【培训】软件过程的管理与改进ppt课件_第2页
【培训】软件过程的管理与改进ppt课件_第3页
【培训】软件过程的管理与改进ppt课件_第4页
【培训】软件过程的管理与改进ppt课件_第5页
已阅读5页,还剩58页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、软件过程的管理与改良1 软件过程管理与改良概述2 度量软件过程3 才干成熟度模型CMM4 个体软件过程PSP5 团体软件过程TSP6 内容总结1 软件过程管理与改良概述软件过程的开展1984年第一届国际软件过程讨论会正式提出,软件工程又一次认识上飞跃。1、软件过程的概念-软件过程是指人们开发和维护软件及其相关产品所采取的一系列活动。其中软件相关产品包括工程方案、设计文档、源代码、测试用例和用户手册等。软件产品的质量主要取决于产品开发和维护的软件过程的质量。一个有效的、可视的软件过程可以将人力资源、物理设备和实施方法结合成一个有机的整体,并为软件工程师和高级管理者提供实践工程的形状和性能,从而可

2、以监视和控制软件过程的进展。IEEE广义软件过程:包括软件的采购、开发、维护、运作、获取、管理、支持ISO 12207分成三个过程:根本过程、支持过程、组织过程研讨目的:管理和改良软件过程软件过程管理:对软件产品及对强化软件系统的开发、维护和支持所涉及的任务过程进展管理软件过程改良:为了更有效的到达优化软件过程的目的而实施的改善或改动其软件过程的系列活动。1 软件过程管理与改良概述2、软件过程改良的实践意义:软件过程实例:软件组织在进展详细软件工程时采用的软件过程。胜利的改良带来的价值:提高效率、减少错误、保证进度、提高质量软件过程管理改良:是软件组织评价和认证的根底,也是竞标软件工程的根底。

3、软件组织角度看软件过程管理和改良:有利于组织获得认证以提高竞争力;从产业角度,可以提高产业整体程度和竞争力印度1 软件过程管理与改良概述3、软件过程建模与软件过程改良的实际与方法:软件过程模型:又称软件工程开发模型或软件生命周期模型,是软件开发全部过程、资源和义务的构造框架。包括组织、功能、行为及其他方面。如件过程建模:经过过程设计和过程定义来建立过程模型的活动。包含两种常用方法:构造化:基于模块化思想,进展构造化分析、设计和编程面向对象:用面向对象的分析、设计、编程及测试方法为软件过程建模。目前的主流方法。用UML工具进展详细建模。过程管理改良的实际:以统计过程控制实际为根底,内容包括:过程

4、的可控性,如何改良使其产生预期结果,如何在度量和统计根底上进展过程改良。1 软件过程管理与改良概述软件过程管理的职责:定义过程度量过程控制过程改良过程4、过程改良的方式和体系目的驱动方式预先设定目的自顶向下制定过程度量或评价模型,有目的的开展改良活动。缺陷驱动方式根据过程缺陷反响的信息,进展有针对性的改良活动1 软件过程管理与改良概述过程改良体系:ISO 9001:效力行业的通用规范,后追加了ISO 9000-3,包含了软件组织满足ISO认证的20个条款CMM:是指关注软件开发的过程体系,明确强调继续的软件过程改良。公用于软件的。TrilliumSPICEBOOTSTRAP5、过程改良的原那么

5、和步骤最普遍的原那么:改良建立在评价和度量根底之上是一个继续过程活动本身应作为一个过程改良工程完成将过程度量用于对改良过程进展监控,及时对改良活动作必要的调整适当反复软件过程的评价活动1 软件过程管理与改良概述5、过程改良活动的组织和实施改良活动涉及的问题:SPI立项成立SPI小组SPI方案 制定SPI意义:明确特定工程活动的目的、目的期限和估计输出工程分解成有特定操作目的的有限义务,使工程更易完成保证义务的优先次序和协调,阐明各义务间关系协助高层管理者、SPI工程成员和相关从业者建立完成特定承诺作为交流工具,确保SPI过程被正确的看到和了解度量和反响渐进和革命建立基准商定普遍建立过程改良认识

6、2度量软件过程度量:是对对象进展量化处置。就是采集数据和分析数据。软件有关的度量有:软件产品度量软件工程度量软件质量度量软件错误和缺陷度量软件过程度量:是软件过程改良的根底软件过程改良度量:软件过程改良本身作为一个过程也需求度量2度量软件过程1、度量软件过程的步骤:制定度量方案确定过程问题选择与定义度量规划如何将度量与软件过程集成与软件过程集成采集数据数据的保管分析过程行为2、过程行为分析技术分析过程行为的目的是对过程稳定行进展测试和评价,找出异常过程行为方式,发现和纠正可归属的缘由,进展过程才干分析2度量软件过程过程的稳定性分析:一个稳定的过程的可度量特征或过程性能的根底分布是一直独一的,对

7、稳定性进展测试,需求专门的统计处置异常过程行为方式分析:找出过程中异常行为的规律和特点,以便发现问题的症结。过程才干分析:过程才干指的是经过这个过程能到达的结果。过程才干分析除了明确过程才干,还要将过程才干与客户或企业需求进展比较,假设不能满足客户需求,必然要对过程改良3 软件才干成熟度模型CMM软件才干成熟度模型CMMCapability Maturity Model是由美国卡内基-梅隆大学软件工程研讨所(CMU/SEI)推出的评价软件才干与成熟度的一套规范。并提供了软件过程评价和软件才干评价两种评价方法和软件成熟度提问单。4年之后,SEI将软件过程成熟度框架进化为软件才干成熟度模型Capa

8、bility Maturity Model For Software,简称SW-CMM。该规范基于众多软件专家的实际阅历,偏重于软件开发过程的管理及工程才干的提高与评价,是国际上流行的软件消费过程规范和软件企业成熟度等级认证规范,它更代表了一种管理哲学在软件工业中的运用。 目前,CMM认证曾经成为世界公认的软件产品进入国际市场的通行证。为推进我国软件产业的开展,促进软件企业向正规化和国际化迈进,应进一步引入和推行CMM认证。3 软件才干成熟度模型CMM1. CMM的体系开展1999年提出CMMI集成才干成熟度模型,也叫综合才干成熟度模型。包括:CMM SW软件工程CMM、CMM SE系统工程C

9、MM、CMM/SE/SW with IPPD集成的产品和过程开发、CMM SA系统采办。来源于CMM2.0草案,1.1版本2003年1月正式发布。PSP个体软件过程,假设没有个体过程认识和过程才干的支持,不能够提高才干成熟度。1995提出PSPTSP团体软件开发过程:提供如何提高软件开发小组本身的知识和技艺的方法。1996提出TSP。TSPi专门用于开发小组。 软件过程成熟度 软件过程成熟度是指一个软件过程被明确定义、管理、度量和控制的有效程度。成熟意味着软件过程才干继续改善的过程,成熟度代表软件过程才干改善的潜力。成熟度等级用来描画某一成熟度等级上的组织特征,每一等级都为下一等级奠定根底,过

10、程的潜力只需在一定的根底之上才可以被充分发扬。成熟级别的改善包括管理者和软件从业者根本任务方式的改动,组织成员根据建立的软件过程规范执行并监控软件过程,一旦来自组织和管理上的妨碍被去除后,有关技术和过程的改善进程能迅速推进。软件过程的成熟度等级 CMM将软件过程的成熟度分为5个级别Maturity Levels ,如下图,5个等级分别是:初始级可反复级已定义级已管理级优化级1、初始级Initial2、可反复Repeatable3、已定义级Defined4、已管理级Managed5、优化级OptimizingSW-CMM为每个软件组织建立和改善软件过程提供了一个阶梯式的过程成熟度框架,这一框架由

11、5个成熟度等级构成。除初始级以外,其他的成熟度等级都包含了假设干个关键过程区域,每个关键过程区域又包含了假设干个关键实际,这些关键实际按照5个共同特点加以组织。 成熟度等级单击鼠标左键查看相应内容初始级可反复级已定义级已管理级优化级初始级Initial在初始级,企业普通不具备稳定的软件开发与维护环境。工程胜利与否在很大程度上取决于能否有出色的工程经理和阅历丰富的开发团队。此时,工程经常超出预算和不能按期完成,组织的软件过程才干不可预测。初始级初始级可反复级已定义级已管理级优化级可反复级(Repeatable): 在可反复级,组织建立了管理软件工程的方针以及为贯彻执行这些方针的措施。组织基于在类

12、似工程上的阅历对新工程进展谋划和管理。组织的软件过程才干可描画为有纪律的,并且工程过程处于工程管理系统的有效控制之下。可反复级可反复级初始级可反复级已定义级已管理级优化级已定义级Defined:在已定义级,组织构成了管理软件开发和维护活动的组织规范软件过程,包括软件工程过程和软件管理过程。工程根据规范定义本人的软件过程进展管理和控制。组织的软件过程才干可描画为规范的和一致的,过程是稳定的和可反复的并且高度可视已定义级初始级可反复级已定义级已管理级优化级已管理级Managed:在已管理级,组织对软件产品和过程都设置定量的质量目的。工程经过把过程性能的变化限制在可接受的范围内,实现对产品和过程的控

13、制。组织的软件过程才干可描画为可预测的,软件产品具有可预测的高质量已管理级已管理级初始级可反复级已定义级已管理级优化级优化级Optimizing:在优化级,组织经过预防缺陷、技术创新和更矫正程等多种方式,不断提高工程的过程性能以继续改善组织软件过程才干。组织的软件过程才干可描画为继续改善的。优化级优化级表1描画了SW-CMM不同成熟度等级过程的可视性和过程才干。等级成熟度可视性过程能力1初始级有限的可视性一般达不到进度和成本的目标2可重复级里程碑上具有管理可视性由于基于过去的性能,项目开发计划比较现实可行3已定义级项目定义软件过程的活动具有可视性基于已定义的软件过程,组织持续地改善过程能力4已

14、管理级定量地控制软件过程基于对过程和产品的度量,组织持续地改善过程能力5优化级不断地改善软件过程组织持续地改善过程能力可视性与过程才干的比较SW-CMM的关键过程区域 过程分类成熟度等级管理过程组织过程工程过程 5、优化级 技术改革管理过程更改管理缺陷预防4、已管理级 定量过程管理软件质量管理3、已定义级集成软件管理组间协调组织过程焦点组织过程定义培训大纲软件产品工程同行评审2、可重复级需求管理软件项目策划软件项目跟踪与监督软件子合同管理软件质量保证软件配置管理 1、初始级无序过程关键过程区域除了初始级外,每一成熟度等级又由假设干个关键过程区域(Key Process Areas)构成。关键过

15、程区域指出为了到达某个成熟度等级所要着手处理的问题。到达一个成熟度等级,必需实现该等级上的全部关键过程区域。要实现一个关键过程区域,就必需到达该关键过程区域的一切目的。每个等级内容按三个层面组织:关键过程域KPA共同特点关键实际关键过程区域KPA(Key Process Areas)是一组相关的活动,可按照上表描画,也可按照图描画。 初始级需求管理软件工程方案软件工程跟踪与监视软件子合同管理软件质量保证软件配置管理可反复级软件机构过程关注点软件机构过程定义培训方案整体化软件管理软件产品工程组间协作同行评审已定义级定量过程管理软件质量管理已管理级过程变卦管理预防缺点技术变卦管理优化级关键过程域关

16、键实际:对软件组织的才干成熟度有关键意义的实际共同特点五个:承诺才干活动监控验证CMM常见关键过程域(1) 需求管理(requirements management)建立客户的软件工程需求,並使工程开发人员与客户对软件需求产生一致的了解。这是软件工程规划(SPP)和管理(SPTO)的根底,需求变卦依赖于配置管理(SCM)的变卦控制流程。在工程实施过程中,最突出的景象就是工程组成员没有完全了解需求,软件需求不稳定,客户经常变卦需求,无法有效控制需求变卦,需求变卦往往呵斥工程延期和费用超支。CMM要求的需求管理的根本流程可如所示。该流程描画了软件工程组开场获取原始需求,汇总为系统需求,分配系统需求

17、,复审软件需求,软件需求必需文档化构成需求文档,此文档必需经过相关组和个人的评审,经过评审之后才纳入配置管理,为需求文档建立基线。软件工程方案、活动及软件任务产品,应和软件需求的变化坚持一致。a. 获取需求和确认需求以Use case用例为单位,以Rational Requisite Pro作为需求管理工具,运用Rational Rose进展维护Use case和Use case Model。b. 经过访谈,从客户处获取原始需求,构成需求文档。c. 分析软件需求构成Use case描画文档,与客户共同确认需求,向客户展现Use case文档,获得客户认可。d. 建立基线的需求必需经过相关组的审

18、查,包括:系统分析组、设计组、编码组、测试组、质量保证组、配置管理组、文档管理中心及个人。经过审查,工程组成员发现需求能否可行、能否完善、能否明晰、能否可进展测试。e. 经过审查后,将需求文档纳入配置管理,为需求创建基线。需求管理步骤: f. 经过工具管理,对需求进展跟踪,尽快找出需求变卦受影响的需求及工件,并了解需求的实现情况。g. 客户确认后如需变卦,工程小组成员向其阐明变卦的影响,并有能够添加费用及时间,尽量控制客户的需求。需求变卦的流程按配置管理的变卦流程执行。h. 一旦需求发生变卦,工程方案、活动、工序随之变卦,并重新提交相关组和个人复审。i. 实践工程需求管理中运用的文档有: 工程

19、需求管理流程定义、工程需求复审流程定义、工程需求及形状跟踪流程定义、需求获取表格、需求形状报告、需求复审报告、需求变卦报告、需求跟踪报告(2)软件工程方案(software project planning)制定实施软件工程与管理软件工程的任务方案。CMM软件工程方案根据纳入配置管理后的软件需求进展工程估算,并根据文档化的流程,构成工程方案文档。工程方案文档经复审后纳入配置管理,由工程开发人员遵照,并据此跟踪检查方案的执行。工程方案文档在复审过程中,假设工程方案对风险估算缺乏或存在其它问题,就需求对工程方案文档重新修正,以获得工程组和高层管理者的支持。a) 工程采用 Microsoft Wor

20、d 拟定方案文档,以 Microsoft Project 拟定方案的进度表。b) 工程经理根据工程软件需求进展估算,确定进展工程选择的生命周期、工程规模、所需的人员、时间、进度、资源、风险等内容。将估算的结果构成估算过程文档,并拟定软件开发方案。c) 软件开发方案内容包含:软件工程方案、迭代方案、进度时间表、配置管理方案、质量保证方案、需求管理方案、工程评测方案、风险管理方案、产品验收方案、问题处理方案、测试方案。软件工程方案的实践运用方式如下:d) 估算过程文档和软件工程方案文档必需经过相关组的审查,以获得相关组及个人的支持,包括:系统分析组、设计组、编码组、测试组、质量保证组、配置管理组、

21、文档管理中心及个人。经过审查,发现并修正工程估算和工程方案的偏向。只需获得了支持,软件工程组在开发过程中才干尽量防止或消除风险。e) 在高层管理者复审经过后,工程经理指定人员或参与拟定软件开发方案其它部分,并由相关组和个人复审。f) 配置管理人员将软件开发方案文档纳入配置管理。g) 实践工程中运用的文档有: 制定工程方案流程定义、工程估算流程定义、工程评价表、资源评价表、软件开发方案模板包括:软件工程方案、迭代方案、配置管理方案、质量保证方案、需求管理方案、工程评测方案、风险管理方案、产品验收方案、问题处理方案、测试方案、进度时间表、制定软件开发方案的指南。(3) 软件工程跟踪和监视(soft

22、ware project tracking and oversight)根据软件开发方案管理软件工程,随时掌握软件工程的实践开发过程。按照工程方案对软件开发的进度和阶段产品进展跟踪和评审,当软件工程的执行情况与软件工程方案发生较大偏向时,管理机构必需采取有效控制措施,必要时根据工程的实践完成情况和结果,修订工程方案。CMM软件工程跟踪与监控的根本流程可如所示。该流程描画了软件工程组根据文档化的估计、承诺、方案跟踪和审查软件成果,并基于实践调整方案。文档化的软件工程方案被用作跟踪软件活动、了解形状和修正方案的根底。工程经理根据工程开发方案跟踪工程的执行情况,定期构成工程进度报告,并与工程开发方案

23、进展对比,发现问题,根据实践情况对软件开发方案进展修正。掌握了这个中心,实施软件工程跟踪与监控活动就很容易了。a) 工程组运用 Rational 的工具进展管理,将 Microsoft Project 拟定的工程方案进度表导入 ClearQuest,主要以 ClearCase 和 ClearQuest 作为跟踪监控工具。b) 工程经理每周根据工程的实践执行情况,拟定工程的进度报告。然后召集工程小组成员,对进度报告进展确认和修正。c) 工程经理对照方案与实践执行情况,发现差距并将其纪录成问题报告,其中包括:费用、进度、风险、人员、资源情况等。d) 由高层管理者复审进度报告及问题报告,并敦促工程经

24、理修正其方案及处理工程存在的问题和风险。e) 实践工程中运用的文档有: 工程跟踪与监控流程定义、工程进度报告、工程进度目的搜集指南。 工程方案跟踪与监控采取如下方式:(4) 软件分包合同管理(subcontract management)根据商业联盟、过程才干和技术等要素选择高质量的软件承制方,承制软件工程的部分子工程。制定子工程承制方的任务义务和工程方案文档,它是主承制方跟踪检查和监视子工程过程和产品的根据。(5) 软件质量保证(quality assurance)评审软件产品和活动,检验它们能否与运用的规范和规程坚持一致,对发现的问题应采取必要措施予以处理。软件质量保证的根本流程可如所示。

25、该流程描画了软件质量保证方案的构成与复审,SQA人员根据质量保证方案开展质量保证活动,发现问题,跟踪处理问题,并最终向高层管理者汇报工程的执行情况。质量保证方案普通包含工程过程采用的规范如:工程方案估算过程、方案过程、测试过程、复审过程、开发过程、风险管理等以及软件任务产品的规范如:编码规范、接口定义规范等。软件质量保证过程a) 工程质量保证人员以Microsoft Word拟定工程质量保证方案文档,以Microsoft Project拟定工程质量保证活动的进度表。b) 由质量保证经理或高层管理者指定工程的质量保证人员。工程的质量保证人员在工程开发方案复审经过之后,拟定工程的质量保证方案,并提

26、交给工程经理和质量保证经理或高层管理者复审。c) 质量保证人员根据方案对工程执行的活动进展定期审计,记录与工程流程定义不一致的问题,并构成报告。 d) 质量保证人员组织人员对产出的任务产品进展复审,以验证其能否与工程采用的规范一致,并构成报告。e) 将审计和复审发现的问题记录到工程的问题跟踪进度表中,跟踪并协调问题的处理情况,并定期向高层管理者汇报。假设不能处理的由高层管理者协助处理。f) 工程经理或高层管理者定期检查质量保证人员的活动。g) 实践工程中运用的文档有: 工程质量保证流程定义、质量保证方案、流程审计报告、软件任务产品复审报告、质量保证方案进度表、SQA问题跟踪处理进度表。(6)软

27、件配置管理(configuration management)保证软件工程生成的产品在软件生命周期中的完好性。在给定时间点上确定软件配置,如任务产品及其阐明。系统的控制软件配置的变化并在整个软件生命周期中维护配置的完好性和可跟踪性。软件配置管理可以分为两方面的内容,一是配置项的识别和管理,另一方面是变卦管理。a. 配置项管理的根本流程可如所示,该流程描画了软件工程组在进展开发过程中,生成软件任务产品,识别配置项,为配置项创建基线。配置管理项最显著的特征就是包含版本号或发布日期。实践工程管理经常不知道该如何识别区分配置项和基线。b. 变卦管理描画了纳入配置管理的配置项进展变卦的完好流程。根据新需

28、求、工程进度报告、客户意见反响、软件任务产品复审记录等不同的缘由提出变卦恳求,由工程小组或变卦控制委员会SCCB分析其影响,确定变卦恳求的回绝、接受或搁置,并根据不同的决议进展不同的处置,不断到变卦恳求被处置。一旦采用了严厉的变卦控制管理流程,才干了解变卦呵斥的影响,一切工程组成员才了解变卦,构成共识,接受变卦。短少对变卦有效的控制,往往会呵斥配置管理的无序,导致工程返工、延期,甚至失败。 a) 工程设定配置管理人员,以Rational ClearCase为配置管理工具,根据工程方案拟定工程的配置管理方案文档,以Microsoft Project拟定工程配置活动的进度表。b) 工程的配置管理方

29、案包含以下内容:配置管理工具、目录构造、识别配置项的方法、配置项命名、创建配置管理库、基线管理、配置审计、配置形状报告、变卦管理等。c) 在ClearCase创建工程的VOB版本对象库,创建工程小组成员的任务区和集成区,工程组成员只在各自的任务区Check in 或Check out操作,由配置管理人员进展合并,标识出软件配置项。d) 由配置管理人员担任在适当的时机如:里程碑处或迭代终了创建基线,提升基线,下降基线,并由其负指摘份和恢复基线。软件配置管理的方法e) 根据配置管理方案对工程的配置项和基线定期或里程碑处进展审计,以验证其能否与工程配置方案或工程开发方案一致。f) 一切的变卦恳求首先

30、向配置管理人员提出,由配置管理人员对变卦恳求进展分析确定其影响,组织变卦评审小组。g) 一旦赞同变卦,由配置管理人员Check out需变卦的配置项,然后对配置项进展变卦,变卦完成后再由配置管理人员Check in到配置管理库中。h) 由SQA人员定期审计配置管理的活动。i) 实践工程中运用的文档有: 工程配置管理方案制定流程定义、工程配置管理活动流程定义、工程配置管理方案、配置形状报告、基线审计报告见附表、配置项变卦恳求表、工程配置管理活动进度表、配置管理工具操作指南才干成熟度模型集成CMMI1才干成熟度模型集成CMMI的产生软件才干成熟度模型CMM获得了胜利,产生了很大影响。系统工程、系统

31、平安工程、集成化产品开发等许多工程学科和领域也都参照CMM建立本人的才干成熟度模型,如SE-CMM、People CMM、IPD-CMM、FAA-iCMM等。模型的繁衍导致模型框架、术语等方面的矛盾和不一致。当某一工程工程涉及假设干个学科和领域后,这种矛盾就非常突出了。才干成熟度模型集成CMMI的产生 CMM公布后的假设干年内工程环境更加复杂,工程规模更大、参与工程工程的组织和人员更多、范围更广泛,工程的施工涉及多学科、交叉学科、并行工程、及更多的国际规范。这些新的变化促使美国国防部、美国国防工业协会和SEI/CMU共同开发一种新的模型CMMICapability Maturity Model

32、 Integration。才干成熟度模型集成CMMICMMI工程在1998年正式启动来自业界、政府部门和SEI/CMU三个方面的170多人,经过两年的任务于2000年发布 CMMI-SE/SW/IPPD V1.0CMMI-SE/SW/IPPD v1.0的主要参考模型 软件学科的SW-CMM 系统工程学科的EIA/IS 731 集成化产品和过程开发领域的IPD CMM v0.98才干成熟度模型集成CMMICMMI承继了SW-CMM的阶段式表示法和EIA/IS 731的延续式表示法。软件学科的两种表示法均采用一致的24个过程域,它们在逻辑上是等价的。对同一组织采用两种模型分别进展CMMI评价应该得

33、到一样的结论。2 阶段式模型和延续式模型1) 阶段式模型阶段式模型根本沿袭SW-CMM模型框架,仍坚持五个“成熟度等级,但过程域做了一些调整和扩展,如表2.23所示过程域的阶段式分组成熟度等级 过程域L2可反复级 需求管理 工程方案 配置管理 工程监视和控制 供应商合同管理 度量和分析 过程和产质量量保证L3己定义级 需求开发 技术处理方案 产品集成 验证 确认 组织级过程焦点 组织级过程定义 组织级培训 集成化工程管理 风险管理 集成化的团队 决策分析和处理方 组织级集成环境L4 己管理级 组织级过程性能 工程定量管理L5 优化级 组织级改革和实施 因果分析和处理方案2) 延续式模型延续式模

34、型没有与组织成熟度相关的几个阶段。延续式模型将24个过程域按照功能划分为过程管理、工程管理、工程、支持 四个过程组。表2.24 延续式模型的过程域分组延续式分组 过程域过程管理 组织级过程焦点 组织级过程定义 组织级培训 组织级过程性能 组织级改革和实施工程管理 工程方案 工程监视和控制 供应商合同管理 集成化工程管理 风险管理 集成化的团队 工程定量管理工 程 需求管理 需求开发 技术处理方案 产品集成 验证 确认 支 持 配置管理 度量和分析 过程和产质量量保证 决策分析和处理方案 组织级集成环境 因果分析和处理方案CMM和CMMI的选择和运用CMM优点CMM模型概念明晰、层次清楚、易于操作。为组织担任人和管理者提供指点组织逐渐成熟的、明确的、有效的、单一路途。CMM缺陷在阶段式模型中,属于较高级别成熟度的过程域不支持较低级别的过程域,如在L2级就无法安排属于L3级的“同行评审过程域的实际活动。CMM过程域的度量只需经过或不经过,度量比较粗糙没有反映优势和普通。CMMI优点CMMI-SE/SW和CMMI-SE/SW/IPPD模型综合了系统工程、软件工程、集成化产品和过程开发三个过程改良模型。综合了阶段式和延续

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论