全部科目 > 信息系统项目管理师 >
2012年上半年 上午试卷 综合知识
第 2 题
知识点 项目生命期   过程模型   螺旋模型   其他模型   软件过程  
关键词 开发   螺旋模型   软件过程   原型  
章/节 信息系统项目管理基础  
 
 
螺旋模型是演化软件过程模型,将原型实现的迭代特征与线性顺序模型结合起来,使得软件的增量版本的快速开发成为可能。螺旋模型其他模型相比,更强调(2)。
 
  A.  制定计划
 
  B.  风险分析
 
  C.  实施工程
 
  D.  客户评估
 
 




 
 
相关试题     要点详解 

  第20题    2021年上半年  
在接到涉密系统集成项目后,项目经理要求信息技术部按公司规定,为每个项目组成员配置并安装数据防泄露工具的笔记本电脑,该项目经理采用的是( )。

  第48题    2019年下半年  
领导者的工作主要涉及( )。

  第24题    2022年上半年  
关于项目管理计划的描述,不正确的是()。

 
知识点讲解
· 项目生命期
· 过程模型
· 螺旋模型
· 其他模型
· 软件过程
 
        项目生命期
        定义
        项目经理或组织可以把每个项目分成若干个阶段,以便有效地进行管理控制,并与该项目实施组织的日常运行联系起来,这些项目阶段合在一起称为项目生命期。项目生命期通常规定:
        .每个阶段应完成哪些技术工作?
        .每个阶段的交付物应何时产生?对每个交付物如何进行评审、验证和确认?
        .每个阶段都有哪些人员参与?
        .如何控制和批准每个阶段?
        项目阶段特征:
        .每个项目阶段都以一个或多个可交付成果的完成为标志。
        .项目阶段的结束通常以对完成工作与可交付成果的审查为标志。
        .在未决定是否启动任何其他阶段时,也可以结束一个阶段。
        .阶段的正式完成不包括核准随后的阶段。阶段末审查往往称为阶段放行口、阶段关卡或验收站。
        特征
        大多数项目生命周期都具有如下特征:
        .在初始阶段,费用和人员水平较低,在中间阶段达到最高,当项目接近结束时则快速下降。
        .项目初始阶段不确定性水平高,因此不能达成项目目标的风险也高,后续阶段完成项目的确定性逐渐变好。
        .随着项目阶段的深入,变更和缺陷修改的费用通常会增加。
        .项目初始阶段,项目干系人影响项目的最终产品特征的能力最高,随着项目的继续逐渐变低。
        与产品生命期关系
        产品生命期开始于经营计划,经过构思,到产品,到日常经营和产品退出市场。
        在某些应用领域,项目生命期可以视为产品生命期的一部分。
        信息系统项目生命期模型
        1.瀑布模型
        经典的软件生命周期模型,一般将软件开发分为可行性分析(计划)、需求分析、软件设计(概要设计、详细设计)、编码(含单元测试)、测试、运行维护等几个阶段。适用于需求明确或很少变更的项目。
        2.螺旋模型
        螺旋模型是一个演化软件过程模型,将原型实现的迭代特征与瀑布模型中控制的和系统化的方面结合起来,使得软件的增量版本的快速开发成为可能。螺旋模型强调了风险分析,特别适用于庞大而复杂的、高风险的系统。
        3.迭代模型
        迭代模型分4个阶段:初始、细化、构造、移交。各阶段的主要任务有:
        .初始阶段:系统地阐述项目的范围,选择可行的系统构架,计划和准备业务案例。
        .细化阶段:细化构想,细化过程和基础设施,细化构架并选择构件。
        .构造阶段:资源管理、控制和过程最优化,完成构件的开发并依据评价标准进行测试,依据验收标准评估产品的发布。
        .移交阶段:同步并使开发的构造增量集成到一致的实施基线中,根据完整的构想和需求集的验收标准评估与实施有关的工程活动的实施基线。
        适用于面向对象的软件开发过程。
        4.信息化项目的生命周期
        信息化项目一般有可行性分析、业务重组、信息系统规划、系统需求分析、系统设计、系统实现、系统测试、系统实施、系统试运行、运营和维护等几个阶段。
 
        过程模型
        产品开发生命周期通常使用过程模型进行表示。过程模型习惯上也称为开发模型,它是系统开发全部过程、活动和任务的结构框架。典型的开发过程模型有瀑布模型、增量模型、演化模型(原型模型、螺旋模型)、喷泉模型、基于构件的开发模型和形式化方法模型等。
               瀑布模型(Waterfall Model)
               瀑布模型是将系统生存周期各个活动规定为依线性顺序连接的若干阶段的模型,也称为线性模型。它包括需求分析、设计、实现、测试、运行和维护。它规定了由前至后、相互衔接的固定次序,如同瀑布流水,逐级下落,如下图所示。
               
               瀑布模型
               瀑布模型为系统的开发和维护提供了一种有效的管理模式,根据这一模式制定开发计划,进行成本预算,组织开发力量,以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导,所以它是以文档作为驱动、适合于系统需求很明确的软件项目的模型。
               瀑布模型假设一个待开发的系统需求是完整的、简明的、一致的,而且可以先于设计和实现产生。瀑布模型的优点是,容易理解,管理成本低;强调开发的阶段性早期计划及需求调查和产品测试。不足之处是,客户必须能够完整、正确和清晰地表达他们的需要;在开始的两个或三个阶段中,很难评估真正的进度状态;当接近项目结束时,出现了大量的集成和测试工作;直到项目结束之前,都不能演示系统的能力。在瀑布模型中,需求或设计中的错误往往只有到了项目后期才能够被发现,对于项目风险的控制能力较弱,从而导致项目常常延期完成,开发费用超出预算。
               瀑布模型的一个变体是V模型,如下图所示。V模型描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系。随着团队工作沿着V模型左侧步骤向下推进,基本问题需求逐步细化,形成问题及解决方案的技术描述。一旦编码结束,团队沿着V模型右侧的步骤向上推进工作,其实际上是执行了一系列测试(质量保证活动),这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。V模型提供了一种将验证确认活动应用于早期软件工程工作中的方法。
               
               V模型
               增量模型(Incremental Model)
               增量模型融合了瀑布模型的基本成分和原型实现的迭代特征,它假设可以将需求分段为一系列增量产品,每一增量可以分别开发。该模型采用随着日程时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的“增量”,如下图所示。当使用增量模型时,第1个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能,这个过程在每一个增量发布后不断重复,直到产生最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
               
               增量模型
               增量模型作为瀑布模型的一个变体,具有瀑布模型的所有优点。此外,它还有以下优点:第一个可交付版本所需要的成本和时间很少;开发由增量表示的小系统所承担的风险不大;由于很快发布了第一个版本,因此可以减少用户需求的变更;运行增量投资,即在项目开始时,可以仅对一个或两个增量投资。
               增量模型有以下不足之处:如果没有对用户的变更要求进行规划,那么产生的初始增量可能会造成后来增量的不稳定;如果需求不像早期思考的那样稳定和完整,那么一些增量就可能需要重新开发,重新发布;管理发生的成本、进度和配置的复杂性可能会超出组织的能力。
               原型模型(Prototype Model)
               并非所有的需求都能够预先定义,大量的实践表明,在开发初期很难得到一个完整的、准确的需求规格说明。这主要是由于客户往往不能准确地表达对未来系统的全面要求,开发者对要解决的应用问题模糊不清,以至于形成的需求规格说明常常是不完整的、不准确的,有时甚至是有歧义的。此外,在整个开发过程中,用户可能会产生新的要求,导致需求的变更。而瀑布模型难以适应这种需求的不确定性和变化,于是出现了快速原型(rapid prototype)这种新的开发方法。原型方法比较适合于用户需求不清、需求经常变化的情况,是一种演化模型(Evolutionary Model)。当系统规模不是很大也不太复杂时,采用该方法比较好。
               原型是预期系统的一个可执行版本,反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束,其目的是能快速、低成本地构建原型。当然,能够采用原型方法是因为开发工具的快速发展,使得能够迅速地开发出一个让用户看得见、摸得着的系统框架。这样,对于计算机不是很熟悉的用户就可以根据这个框架提出自己的需求。开发原型系统首先确定用户需求,开发初始原型,然后征求用户对初始原型的改进意见,并根据意见修改原型。原型模型如下图所示。
               
               原型模型
               原型模型开始于沟通,其目的是定义软件的总体目标,标识需求,然后快速制定原型开发的计划,确定原型的目标和范围,采用快速射击的方式对其进行建模,并构建原型。被开发的原型应交付给客户使用,并收集客户的反馈意见,这些反馈意见可在下一轮中对原型进行改进。在前一个原型需要改进,或者需要扩展其范围的时候,进入下一轮原型的迭代开发。
               根据使用原型的目的不同,原型可以分为探索型原型、实验型原型和演化型原型3种。探索型原型的目的是要弄清目标的要求,确定所希望的特性,并探讨多种方案的可行性。实验型原型的目的是验证方案或算法的合理性,是在大规模开发和实现前,用于考查方案是否合适、规格说明是否可靠等。演化型原型的目的是将原型作为目标系统的一部分,通过对原型的多次改进,逐步将原型演化成最终的目标系统。
               螺旋模型(Spiral Model)
               对于复杂的大型系统,开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来,加入了两种模型均忽略的风险分析,弥补了这两种模型的不足。螺旋模型是一种演化模型。
               螺旋模型将开发过程分为几个螺旋周期,每个螺旋周期大致和瀑布模型相符合,如下图所示。在每个螺旋周期分为如下4个工作步骤。
               
               螺旋模型
               (1)制订计划。确定系统的目标,选定实施方案,明确项目开发的限制条件。
               (2)风险分析。分析所选的方案,识别风险,消除风险。
               (3)实施工程。实施系统开发,验证阶段性产品。
               (4)用户评估。评价开发工作,提出修正建议,建立下一个周期的开发计划。
               螺旋模型强调风险分析,使得开发人员和用户对每个演化层出现的风险有所了解,继而做出应有的反应。因此特别适用于庞大、复杂并且具有高风险的系统。
               与瀑布模型相比,螺旋模型支持用户需求的动态变化,为用户参与软件开发的所有关键决策提供了方便,有助于提高产品的适应能力,并且为项目管理人员及时调整管理决策提供了便利,从而降低了系统开发的风险。在使用螺旋模型进行系统开发时,需要开发人员具有相当丰富的风险评估经验和专门知识。另外,过多的迭代次数会增加开发成本,延迟提交时间。
               喷泉模型(water fountain model)
               喷泉模型是一种以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性,如下图所示。迭代意味着模型中的开发活动常常需要重复多次,在迭代过程中不断地完善系统。无间隙是指在开发活动(如分析、设计、编码)之间不存在明显的边界,也就是说,它不像瀑布模型那样,需求分析活动结束后才开始设计活动,设计活动结束后才开始编码活动,而是允许各开发活动交叉、迭代地进行。
               
               喷泉模型
               喷泉模型的各个阶段没有明显的界限,开发人员可以同步进行。其优点是可以提高项目开发效率,节省开发时间。由于喷泉模型在各个开发阶段是重叠的,在开发过程中需要大量的开发人员,不利于项目的管理。此外这种模型要求严格管理文档,使得审核的难度加大。
               形式化方法模型(Formal Methods Model)
               形式化方法是用于将复杂系统建模为数据实体的技术,是建立在严格数学基础上的一种开发方法,其主要活动是生成计算机软件形式化的数学规格说明。
               形式化方法用严格的数学语言和语义描述功能规约和设计规约,通过数学的分析和推导,易于发现需求的歧义性、不完整性和不一致性,易于对分析模型、设计模型和程序进行验证。通过数学的演算,使得从形式化功能规约到形式化设计规约,以及从形式化设计规约到程序代码的转换成为可能。
               统一过程(UP)模型
               统一过程的特色是“用例和风险驱动,以架构为中心,迭代的增量开发过程”。迭代的意思是将整个产品开发项目划分为许多个小的“袖珍项目”,每个“袖珍项目”都包含正常项目的所有元素:计划、分析和设计、构造、集成和测试,以及内部和外部发布。
               统一过程定义了5个阶段及其制品。
               (1)起始阶段(inception phase)。起始阶段专注于项目的初创活动,产生的主要工作产品有构想文档(vision document)、初始用例模型、初始项目术语表、初始业务用例、初始风险评估、项目计划(阶段及迭代)、业务模型以及一个或多个原型(需要时)。本阶段的里程碑是生命周期目标。
               (2)精化阶段(elaboration phase)。精化阶段在理解了最初的领域范围之后进行需求分析和架构演进,产生的主要工作产品有用例模型、补充需求(包括非功能需求)、分析模型、体系结构描述、可执行的体系结构原型、初步的设计模型、修订的风险列表、项目计划(包括迭代计划、调整的工作流、里程碑和技术工作产品)以及初始用户手册。本阶段的里程碑是生命周期架构。
               (3)构建阶段(construction phase)。构建阶段关注系统的构建,产生实现模型,产生的主要工作产品有设计模型、系统构件、集成的增量、测试计划及步骤、测试用例以及支持文档(用户手册、安装手册和对于并发增量的描述)。初始运作功能。
               (4)移交阶段(transition phase)。移交阶段关注于系统提交方面的工作,产生系统增量,产生的主要工作产品有提交的系统增量、β测试报告和综合用户反馈。本阶段的里程碑是产品发布版本。
               (5)生产阶段(production phase)。生产阶段对持续使用的软件进行监控,提供运行环境(基础设施)的支持,提交并评估缺陷报告和变更请求。
               在每个迭代中,有5个核心工作流:捕获系统应该做什么的需求工作流,精化和结构化需求的分析工作流,用系统构架实现需求的设计工作流,构造系统的实现工作流,验证实现是否如期望那样工作的测试工作流。
               统一过程的典型代表是RUP(Rational Unified Process),主要针对前4个技术阶段。RUP是UP的商业扩展,完全兼容UP,但比UP更完整、更详细。
               敏捷方法(Agile Development)
               敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。通过在产品开发过程中加入灵活性,敏捷方法使用户能够在开发周期的后期增加或改变需求。
               敏捷过程的典型方法有很多,每一种方法基于一套原则,这些原则实现了敏捷方法所宣称的理念(敏捷宣言)。
               (1)极限编程(XP)。XP是一种轻量级(敏捷)、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成,彼此相互依赖、关联,并通过行为贯穿于整个生存周期。
               .4大价值观:沟通、简单性、反馈和勇气。
               .5个原则:快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
               .12个最佳实践:计划游戏(快速制订计划、随着细节的不断变化而完善)、小型发布(系统的设计要能够尽可能早地交付)、隐喻(找到合适的比喻传达信息)、简单设计(只处理当前的需求,使设计保持简单)、测试先行(先写测试代码,然后再编写程序)、重构(重新审视需求和设计,重新明确地描述它们以符合新的和现有的需求)、结队编程、集体代码所有制、持续集成(可以按日甚至按小时为客户提供可运行的版本)、每周工作40个小时、现场客户和编码标准。
               (2)水晶法(Crystal)。水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论。
               (3)并列争球法(Scrum)。并列争球法使用迭代的方法,其中,把每30天一次的迭代称为一个“冲刺”,并按需求的优先级别来实现产品。多个自组织和自治的小组并行地递增实现产品。协调是通过简短的日常情况会议来进行,就像橄榄球中的“并列争球”。。
               (4)自适应软件开发(ASD)。ASD有6个基本的原则:有一个使命作为指导;特征被视为客户价值的关键点;过程中的等待是很重要的,因此“重做”与“做”同样关键;变化不被视为改正,而是被视为对软件开发实际情况的调整;确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求;风险也包含其中。
 
        螺旋模型
        螺旋模型将瀑布模型和变换模型相结合,综合了两者的优点,并增加了风险分析。它以原型为基础,沿着螺线自内向外旋转,每旋转一圈都要经过制定计划、风险分析、实施工程及客户评价等活动,并开发原型的一个新版本。经过若干次螺旋上升的过程,得到最终的系统。螺旋模型的核心思想是循环,在每个循环的出口设置里程碑。
 
        其他模型
               X模型
               由于V模型受到了很多人的质疑,因此,也有人提出了一些不同的观点和意见。在此,我们向大家介绍另外一种测试模型,即X模型,其目标是弥补V模型的一些缺陷。
               X模型的基本思想是由Marick提出的,但首先Marick不建议建立一个替代模型,同时,他也认为他的观点并不足以支撑一个模型的完整描述。不过,Robin F. Goldsmith先生在自己的文章里将其思想定义为X模型,理由是,在Marick的观点中已经具备一个模型所需要的一些主要内容,其中也包括了像探索性测试这样的亮点。软件测试X模型如下图所示。
               
               软件测试X模型
               Marick对V模型最主要的批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面,包括交接、频繁重复的集成以及需求文档的缺乏等。Marick认为一个模型不应该规定那些和当前所公认的实践不一致的行为。
               X模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试,此后,将进行频繁的交接,通过集成最终合成为可执行的程序。这一点在图的右上方得以体现,而且这些可执行程序还需要进行测试,已通过集成测试的成品可以进行封版并提交给用户,也可以作为更大规模和范围内集成的一部分。
               同时,X模型还定位了探索性测试,即如上图中右下方所示。这是不进行事先计划的特殊类型的测试,诸如“我这么测一下,结果会怎么样”,这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
               Marick对V模型提出质疑,也是因为V模型是基于一套必须按照一定顺序严格排列的开发步骤,而这很可能并没有反映实际的实践过程。因为在实践过程中,很多项目是缺乏足够的需求的,而V模型还是从需求处理开始。
               Marick也质疑了单元测试和集成测试的区别,因为在某些场合人们可能会跳过单元测试而热衷于直接进行集成测试。Marick担心人们盲目地跟随“学院派的V模型”,按照模型所指导的步骤进行工作,而实际上某些做法并不切合实用。
               前置测试模型
               前置测试模型是由Robin F. Goldsmith等人提出的,它是一个将测试和开发紧密结合的模型,该模型提供了轻松的方式,可以使你的项目加快速度。前置测试模型如下图所示。
               
               前置测试模型
               前置测试模型体现了以下的要点。
               . 开发和测试相结合:前置测试模型将开发和测试的生命周期整合在一起,标识了项目生命周期从开始到结束之间的关键行为。并且标识了这些行为在项目周期中的价值所在。如果其中有些行为没有得到很好的执行,那么项目成功的可能性就会因此而有所降低。如果有业务需求,则系统开发过程将更有效率。我们认为在没有业务需求的情况下进行开发和测试是不可能的。而且,业务需求最好在设计和开发之前就被正确定义。
               . 对每一个交付内容进行测试:每一个交付的开发结果都必须通过一定的方式进行测试。源程序代码并不是惟一需要测试的内容。图中的椭圆框表示了其他一些要测试的对象,包括可行性报告、业务需求说明,以及系统设计文档等。这同V模型中开发和测试的对应关系是一致的,并且在其基础上有所扩展,变得更为明确。
               . 在设计阶段进行测试计划和测试设计:设计阶段是作测试计划和测试设计的最好时机。很多组织要么根本不作测试计划和测试设计,要么在即将开始执行测试之前才飞快地完成测试计划和测试设计。在这种情况下,测试只是验证了程序的正确性,而不是验证整个系统本该实现的东西。
               . 测试和开发结合在一起:前置测试将测试执行和开发结合在一起,并在开发阶段以编码—测试—编码—测试的方式来体现。也就是说,程序片段一旦编写完成,就会立即进行测试。一般情况下,先进行的测试是单元测试,因为开发人员认为通过测试来发现错误是最经济的方式。但也可参考X模型,即一个程序片段也需要相关的集成测试,甚至有时还需要一些特殊测试。对于一个特定的程序片段,其测试的顺序可以按照V模型的规定,但其中还会交织一些程序片段的开发,而不是按阶段完全地隔离。
               . 让验收测试和技术测试保持相互独立:验收测试应该独立于技术测试,这样可以提供双重的保险,以保证设计及程序编码能够符合最终用户的需求。验收测试既可以在实施阶段的第一步来执行,也可以在开发阶段的最后一步执行。前置测试模型提倡验收测试和技术测试沿循两条不同的路线来进行,每条路线分别地验证系统是否能够如预期设想的那样进行正常工作。这样,当单独设计好的验收测试完成了系统的验证时,我们即可确信这是一个正确的系统。
 
        软件过程
        在开发产品或构建系统时,遵循一系列可预测的步骤(即路线图)是非常重要的,它有助于及时交付高质量的产品。软件开发中所遵循的路线图称为"软件过程"。过程是活动的集合,活动是任务的集合。软件过程有3层含义:一个是个体含义,即指软件产品或系统在生存周期中的某一类活动的集合,如软件开发过程、软件管理过程等;二是整体含义,即指软件产品或系统在所有上述含义下的软件过程的总体;三是工程含义,即指解决软件过程的工程,应用软件的原则、方法来构造软件过程模型,并结合软件产品的具体要求进行实例化,以及在用户环境下的运作,以此进一步提高软件的生产率,降低成本。
               能力成熟度模型(CMM)
               CMM将软件组织的过程能力分成五个成熟度级别:初始级、可重复级、已定义级、已管理级和优化级。由低到高,软件开发生产精度越来越高,每单位工程的生产周期越来越短。
               (1)初始级。软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力。
               (2)可重复级。建立了基本的项目管理过程来跟踪费用、进度和功能特性;制定了必要的过程纪律,能重复早先类似应用项目取得的成功。
               (3)定义级。已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。
               (4)管理级。收集对软件过程和产品质量的详细度量,对软件过程和产品都有定量的理解和控制。
               (5)优化级。过程的量化反馈和先进的新思想、新技术促使过程不断改进。
               能力成熟度模型集成(CMMI)
               CMM的成功导致了适用不同学科领域的模型的衍生,如系统工程的能力成熟度模型,适用于集成化产品开发的能力成熟度模型等。而一个工程项目又往往涉及多个交叉的学科,因此有必要将各种过程改进的工作集成起来。1998年,由美国产业界、政府和卡内基.梅隆大学软件工程研究所共同主持CMMI项目。CMMI是若干过程模型的综合和改进,是支持多个工程学科和领域的、系统的、一致的过程改进框架,能适应现代工程的特点和需要,能提高过程的质量和工作效率。
               CMMI提供了两种表示方法:阶段式模型和连续式模型。
               1)阶段式模型
               阶段式模型的结构类似于CMM,它关注组织的成熟度。CMMI-SE/SW/IPPD 1.1版中有5个成熟度等级。
               初始的:过程不可预测且缺乏控制。
               已管理的:过程为项目服务。
               已定义的:过程为组织服务。
               定量管理的:过程已度量和控制。
               优化的:集中于过程改进。
               2)连续式模型
               连续式模型关注每个过程域的能力,一个组织对不同的过程域可以达到不同的过程域能力等级(Capability Level,CL)。CMMI中包括6个过程域能力等级,等级号为0-5。能力等级包括共性目标及相关的共性实践,这些实践在过程域内被添加到特定目标和实践中。当组织满足过程域的特定目标和共性目标时,就说该组织达到了那个过程域的能力等级。
               能力等级可以独立地应用于任何单独的过程域,任何一个能力等级都必须满足比它等级低的能力等级的所有准则。对各能力等级的含义简述如下。
               CLo(未完成的):过程域未执行或未得到CLi中定义的所有目标。
               CLi(已执行的):其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品,以实现支持过程域的特定目标。
               CL2(已管理的):其共性目标集中于已管理的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程,项目遵循已文档化的计划和过程描述,所有正在工作的人都有权使用足够的资源,所有工作任务和工作产品都被监控、控制和评审。
               CL3(已定义级的):其共性目标集中于已定义的过程的制度化。过程是按照组织的剪裁指南从组织的标准过程集中剪裁得到的,还必须收集过程资产和过程的度量,并用于将来对过程的改进。
               CL4(定量管理的):其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域,建立和使用关于质量和过程执行的定量目标作为管理准则。
               CLs(优化的):使用量化(统计学)手段改变和优化过程域,以满足客户要求的改变和持续改进计划中的过程域的功效。



更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5
京公网安备 11010502032051号 | 营业执照
 Copyright ©2000-2023 All Rights Reserved
软考在线版权所有