免费智能真题库 > 历年试卷 > 软件设计师 > 2018年下半年 软件设计师 上午试卷 综合知识
第30题      
知识点   能力成熟度模型集成(CMMI)   量化   CMMI   CMM   过程模型   能力成熟度模型
关键词   CMMI   持续改进   能力成熟度模型   CMM      分类   软件过程管理       

 
能力成熟度模型集成(CMMI是若干过程模型的综合和改进。连续式模型和阶段式模型是CMMI提供的两种表示方法,而连续式模型包括6个过程域能力等级,其中( )使用量化(统计学)手段改变和优化过程域,以应对客户要求的改变和持续改进计划中的过程域的功效。
 
 
  A.  CL2(已管理的)
 
  B.  CL3(已定义级的)
 
  C.  CL4(定量管理的)
 
  D.  CL5(优化的)
 
 
 

  相关试题     软件过程管理    更多>  
 
  第30题    2019年上半年  
   51%
以下关于极限编程(XP)的最佳实践的叙述中,不正确的是( )。
  第16题    2009年上半年  
   21%
一个软件开发过程描述了 “谁做”、“做什么”、“怎么做”和“什么时候做”,RUP 用(..
  第29题    2014年上半年  
   61%
以下关于统一过程UP的叙述中,不正确的是 (29) 。
 


   知识点讲解    
   · 能力成熟度模型集成(CMMI)    · 量化    · CMMI    · CMM    · 过程模型    · 能力成熟度模型
 
       能力成熟度模型集成(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(优化的):使用量化(统计学)手段改变和优化过程域,以满足客户要求的改变和持续改进计划中的过程域的功效。
 
       量化
        经过FDCT变换后的系数,其数值变化较多,不利于编码。为了将系数数值映射到更小的取值范围,可以使用量化(quantisation)实现。通过量化可以减小非0系数的幅度和增加0值系数的数目。当然,量化也是导致图像质量下降的主要原因。
        JPEG的有损压缩算法使用均匀标量量化器进行量化,量化步距是按照系数所在的位置和每种颜色分量的色调值确定的。
        由于人眼对亮度信号比对色差信号更敏感,因此JPEG编码中使用了亮度量化表和色差量化表两种标准的量化表,参见下1表和下2表。此外,由于人眼对低频分量的图像比对高频分量的图像更敏感,因此表中的左上角的量化步距要比右下角的量化步距小。
        
        亮度量化值表
        
        色差量化值表
        量化的具体计算公式如下。
        
        其中,Squ,v)为量化后的结果,Fuv)为FDCT系数,Quv)为量化表中的数值,round为舍入取整函数。
 
       CMMI
        与CMM相比,CMMI涉及面更广,专业领域覆盖软件工程、系统工程、集成产品开发和系统采购。据美国国防部资料显示,运用CMMI模型管理的项目,不仅降低了项目的成本,而且提高了项目的质量与按期完成率。
        CMMI可以看做把各种CMM集成到一个系列的模型中了,CMMI的基础源模型包括软件CMM 2.0版(草稿C)、EIA-731系统工程,以及集成化产品和过程开发IPD CMM(IPD)0.98a版等。CMMI也描述了5个不同的成熟度级别。
               CMMI的表示方法
               每一种CMMI模型都有两种表示法,即阶段式和连续式。这是因为在CMMI的三个源模型中,CMM是“阶段式”模型,系统工程能力模型是“连续式”模型,而集成产品开发(IPD)CMM是一个混合模型,组合了阶段式和连续式两者的特点。两种表示法在以前的使用中各有优势,都有很多支持者,因此,CMMI产品开发群组在集成这三种模型时,为了避免由于淘汰其中任何一种表示法而失去用户对CMMI的支持,并没有选择单一的结构表示法,而是为每一个CMMI都推出了两种不同表示法的版本。
               不同表示法的模型具有不同的结构。连续式表示法强调的是单个过程域的能力,从过程域的角度考查基线和度量结果的改善,其关键术语是“能力”;而阶段式表示法强调的是组织的成熟度,从过程域集合的角度考查整个组织的过程成熟度阶段,其关键术语是“成熟度”。
               尽管两种表示法的模型在结构上有所不同,但CMMI产品开发群组仍然尽最大努力确保了两者在逻辑上的一致性,两者的需要构件和期望部件基本上都是一样的。过程域、目标在两种表示法中都一样,特定实践和共性实践在两种表示法中也不存在根本区别。因此,模型的两种表示法并不存在本质上的不同。组织在进行集成化过程改进时,可以从实用角度出发选择某一种偏爱的表示法,而不必从哲学角度考虑两种表示法之间的差异。
               CMMI的级别
               阶段式模型也把组织分为以下5个不同的级别。
               (1)初始级。代表了以不可预测结果为特征的过程成熟度,过程处于无序状态,成功主要取决于团队的技能。
               (2)已管理级。代表了以可重复项目执行为特征的过程成熟度。组织使用基本纪律进行需求管理、项目计划、项目监督和控制、供应商协议管理、产品和过程质量保证、配置管理,以及度量和分析。对于级别2而言,主要的过程焦点在于项目级的活动和实践。
               (3)严格定义级。代表了以组织内改进项目执行为特征的过程成熟度。强调级别3的关键过程域的前后一致的、项目级的纪律,以建立组织级的活动和实践。
               (4)定量管理级。代表了以改进组织性能为特征的过程成熟度。4级项目的历史结果可用来交替使用,在业务表现的竞争尺度(成本、质量、时间)方面的结果是可预测的。
               (5)优化级。代表了以可快速进行重新配置的组织性能和定量的、持续的过程改进为特征的过程成熟度。
               CMMI的目标
               CMMI的具体目标是:
               (1)改进组织的过程,提高对产品开发和维护的管理能力。
               (2)给出能支持将来集成其他科目CMM的公共框架。
               (3)确保所开发的全部有关产品符合将要发布的关于软件过程改进的国际标准ISO/IEC 15504对软件过程评估的要求。
               CMMI的优点
               使用在CMMI框架内开发的模型具有下列优点。
               (1)过程改进能扩展到整个企业级。
               (2)先前各模型之间的不一致和矛盾将得到解决。
               (3)既有分级的模型表示,也有连续的模型表示,可任意选用。
               (4)原先单科目过程改进的工作可与其他科目的过程改进工作结合起来。
               (5)基于CMMI的评估将与组织原先评估得分相协调,从而保护当前的投资,并与ISO/IEC 15504评估结果相一致。
               (6)节省费用,特别是当要运用多科目改进时,以及进行相关的培训和评估时。
               (7)鼓励组织内各科目之间进行沟通和交流。
 
       CMM
        CMM模型描述和分析了软件过程能力的发展程度,确立了一个软件过程成熟程度的分级标准。
        (1)初始级:软件过程的特点是无秩序的,有时甚至是混乱的。软件过程定义几乎处于无章法和无步骤可循的状态,软件产品所取得的成功往往依赖于极个别人的努力和机遇。初始级的软件过程是未加定义的随意过程,项目的执行是随意甚至是混乱的。也许,有些企业制定了一些软件工程规范,但若这些规范未能覆盖基本的关键过程要求,且执行时没有政策、资源等方面的保证,那么它仍然被视为初始级。
        (2)可重复级:已经建立了基本的项目管理过程,可用于对成本、进度和功能特性进行跟踪。对类似的应用项目,有章可循并能重复以往所取得的成功。焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程,一个可重复的过程则能逐渐演化和成熟。从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。
        (3)已定义级:用于管理方面和工程方面的软件过程均已文档化、标准化,并形成整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。它要求制定企业范围的工程化标准,而且无论是管理还是工程开发都需要一套文档化的标准,并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程,剪裁出项目适宜的过程,并执行这些过程。过程的剪裁不是随意的,在使用前需经过企业有关人员的批准。
        (4)已管理级:软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。已管理级的管理是量化的管理。所有过程需建立相应的度量方式,所有产品的质量(包括工作产品和提交给用户的产品)需有明确的度量指标。这些度量应是详尽的,且可用于理解和控制软件过程和产品,量化控制将使软件开发真正变成为一个工业生产活动。
        (5)优化级:通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析,能够不断地、持续地进行过程改进。如果一个企业达到了这一级,表明该企业能够根据实际的项目性质、技术等因素,不断调整软件生产过程以求达到最佳。
        在CMM中,每个成熟度等级(第一级除外)规定了不同的关键过程域(Key Process Area,KPA),一个软件组织如果希望达到某一个成熟度级别,就必须完全满足关键过程域所规定的要求,即满足关键过程域的目标。每个级别对应的关键过程域见下表。
        
        关键过程域的分类
 
       过程模型
        产品开发生命周期通常使用过程模型进行表示。过程模型习惯上也称为开发模型,它是系统开发全部过程、活动和任务的结构框架。典型的开发过程模型有瀑布模型、增量模型、演化模型(原型模型、螺旋模型)、喷泉模型、基于构件的开发模型和形式化方法模型等。
               瀑布模型(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个基本的原则:有一个使命作为指导;特征被视为客户价值的关键点;过程中的等待是很重要的,因此“重做”与“做”同样关键;变化不被视为改正,而是被视为对软件开发实际情况的调整;确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求;风险也包含其中。
 
       能力成熟度模型
        能力成熟度模型(简称CMM)是对一个组织机构的能力进行成熟度评估的模型。成熟度级别一般分成五级:1级-非正式执行、2级-计划跟踪、3级-充分定义、4级-量化控制、5级-持续优化。其中,级别越大,表示能力成熟度越高,各级别定义如下:
        . 1级-非正式执行:具备随机、无序、被动的过程;
        . 2级-计划跟踪:具备主动、非体系化的过程;
        . 3级-充分定义:具备正式的、规范的过程;
        . 4级-量化控制:具备可量化的过程;
        . 5级-持续优化:具备可持续优化的过程。
        目前,网络安全方面的成熟度模型主要有SSE-CMM、数据安全能力成熟度模型、软件安全能力成熟度模型等。
               SSE-CMM
               SSE-CMM(Systems Security Engineering Capability Maturity Model)是系统安全工程能力成熟度模型。SSE-CMM包括工程过程类(Engineering)、组织过程类(Organization)、项目过程类(Project)。各过程类包括的过程内容如下表所示。
               
               SSE-CMM系统安全工程能力成熟度模型过程清单
               SSE-CMM的工程过程、风险过程、保证过程的相互关系如下图所示。
               
               SSE-CMM的工程过程、风险过程、保证过程关联图
               SSE-CMM的工程过程关系如下图所示。
               
               SSE-CMM的工程过程关联图
               SSE-CMM的工程质量来自保证过程,如下图所示。
               
               SSE-CMM的保证过程图
               数据安全能力成熟度模型
               根据《信息安全技术数据安全能力成熟度模型》,数据安全能力成熟度模型架构如下图所示。
               
               数据安全能力成熟度模型架构
               数据安全能力从组织建设、制度流程、技术工具及人员能力四个维度评估:
               .组织建设——数据安全组织机构的架构建立、职责分配和沟通协作;
               .制度流程——组织机构关键数据安全领域的制度规范和流程落地建设;
               .技术工具——通过技术手段和产品工具固化安全要求或自动化实现安全工作;
               .人员能力——执行数据安全工作的人员的意识及专业能力。
               详细情况参考标准。
               软件安全能力成熟度模型
               软件安全能力成熟度模型分成五级,各级别的主要过程如下:
               . CMM1级——补丁修补;
               . CMM2级——渗透测试、安全代码评审;
               . CMM3级——漏洞评估、代码分析、安全编码标准;
               . CMM4级——软件安全风险识别、SDLC实施不同安全检查点;
               . CMM5级——改进软件安全风险覆盖率、评估安全差距。


 题号导航      2018年下半年 软件设计师 上午试卷 综合知识   本试卷我的完整做题情况 
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
↓第30题