免费智能真题库 > 历年试卷 > 嵌入式系统设计师 > 2017年下半年 嵌入式系统设计师 上午试卷 综合知识
  第64题      
  知识点:   软件能力成熟度模型(CMM)   CMM   能力成熟度模型   软件管理
  关键词:   CMM   能力成熟度模型   软件能力成熟度        章/节:   系统开发过程及其项目管理       

 
软件能力成熟度模型CMM(Capability Maturity Model)规定了(64)中的主要软件管理过程和工程过程的实践。
 
 
  A.  系统分析与软件定义阶段
 
  B.  软件研制和维护活动
 
  C.  软件研制和软件测试
 
  D.  软件设计
 
 
 

 
  第64题    2014年下半年  
   54%
软件能力成熟度模型CMM(Capability MaturityM odel)将软件能力成熟度自低到高依次划分为(64)。需求管理关键过程域属于(65)..
  第43题    2010年下半年  
   78%
软件能力成熟度模型CMM中,将软件能力成熟度自低到高依次划分为5级。除等级1外,每个成熟度等级被分解成几个关键过程域,其中&ld..
  第64题    2020年下半年  
   46%
软件能力成熟度模型CMM(Capability Maturity Model)将软件能力成熟度自低到高依次划分为(64)。
   知识点讲解    
   · 软件能力成熟度模型(CMM)    · CMM    · 能力成熟度模型    · 软件管理
 
       软件能力成熟度模型(CMM)
        在美国国防部支持下,1987年,卡内基-梅隆大学软件工程研究所率先推出了软件工程评估项目的研究成果——软件过程能力成熟度模型(Capability Maturity Model of Software,CMM),其研究目的是提供一种评价软件承接方能力的方法,同时它可用于帮助软件组织改进其软件过程。
        CMM是对软件组织进化阶段的描述,随着软件组织定义、实施、测量、控制和改进其软件过程,软件组织的能力经过这些阶段逐步前进。该能力成熟度模型使软件组织能够较容易地确定其当前过程的成熟度并识别其软件过程执行中的薄弱环节,确定对软件质量和过程改进最为关键的几个问题,从而形成对其过程的改进策略。软件组织只要关注并认真实施一组有限的关键实践活动,就能稳步地改善其全组织的软件过程,使全组织的软件过程能力持续增长。
        CMM将软件过程改进分为如下5个成熟度级别,分别为:
        (1)初始级(Initial)。软件过程的特点是杂乱无章,有时甚至很混乱,几乎没有明确定义的步骤,项目的成功完全依赖个人的努力和英雄式核心人物的作用。
        (2)可重复级(Repeatable)。建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性。有必要的过程准则来重复以前在同类项目中的成功。
        (3)已定义级(Defined)。管理和工程两方面的软件过程已经文档化、标准化,并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。
        (4)已管理级(Managed)。制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。
        (5)优化级(Optimized)。加强了定量分析,通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。
        CMM模型提供了一个框架,将软件过程改进的进化步骤组织成5个成熟度等级,为过程不断改进奠定了循序渐进的基础。这5个成熟度等级定义了一个有序的尺度,用来测量一个组织的软件过程成熟度和评价其软件过程能力。成熟度等级是已得到确切定义的,也是在向成熟软件组织前进途中的平台。每一个成熟度等级为继续改进过程提供一个基础。每一等级包含一组过程目标,通过实施相应的一组关键过程域达到这一组过程目标,当目标满足时,能使软件过程的一个重要成分稳定。每达到成熟度框架的一个等级,就建立起软件过程的一个相应成分,导致组织过程能力一定程度的增长。
        基于CMM模型的产品包括一些诊断工具,可应用于软件过程评价和软件能力评估小组以确定一个机构的软件过程实力、弱点和风险。最著名的是成熟度调查表。软件过程评价及软件能力评估的方法及培训也依赖于CMM模型。
 
       CMM
        CMM模型描述和分析了软件过程能力的发展程度,确立了一个软件过程成熟程度的分级标准。
        (1)初始级:软件过程的特点是无秩序的,有时甚至是混乱的。软件过程定义几乎处于无章法和无步骤可循的状态,软件产品所取得的成功往往依赖于极个别人的努力和机遇。初始级的软件过程是未加定义的随意过程,项目的执行是随意甚至是混乱的。也许,有些企业制定了一些软件工程规范,但若这些规范未能覆盖基本的关键过程要求,且执行时没有政策、资源等方面的保证,那么它仍然被视为初始级。
        (2)可重复级:已经建立了基本的项目管理过程,可用于对成本、进度和功能特性进行跟踪。对类似的应用项目,有章可循并能重复以往所取得的成功。焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程,一个可重复的过程则能逐渐演化和成熟。从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。
        (3)已定义级:用于管理方面和工程方面的软件过程均已文档化、标准化,并形成整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。它要求制定企业范围的工程化标准,而且无论是管理还是工程开发都需要一套文档化的标准,并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程,剪裁出项目适宜的过程,并执行这些过程。过程的剪裁不是随意的,在使用前需经过企业有关人员的批准。
        (4)已管理级:软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。已管理级的管理是量化的管理。所有过程需建立相应的度量方式,所有产品的质量(包括工作产品和提交给用户的产品)需有明确的度量指标。这些度量应是详尽的,且可用于理解和控制软件过程和产品,量化控制将使软件开发真正变成为一个工业生产活动。
        (5)优化级:通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析,能够不断地、持续地进行过程改进。如果一个企业达到了这一级,表明该企业能够根据实际的项目性质、技术等因素,不断调整软件生产过程以求达到最佳。
        在CMM中,每个成熟度等级(第一级除外)规定了不同的关键过程域(Key Process Area,KPA),一个软件组织如果希望达到某一个成熟度级别,就必须完全满足关键过程域所规定的要求,即满足关键过程域的目标。每个级别对应的关键过程域见下表。
        
        关键过程域的分类
 
       能力成熟度模型
        能力成熟度模型(简称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级——改进软件安全风险覆盖率、评估安全差距。
 
       软件管理
               软件管理的范围
               软件资源就是指企业整个环境中运行的软件和文档,其中程序包括操作系统、中间件、市场上买来的应用、本公司开发的应用、分布式环境软件、服务与计算机的应用软件以及所提供的服务等,文档包括应用表格、合同、手册、操作手册等。软件管理系统必须将它们表示出来,才能对其进行管理。软件资源管理,是指优化管理信息的收集,对企业所拥有的软件授权数量和安装地点进行管理。还包括软件分发管理,指的是通过网络把新软件分发到各个站点,并完成安装和配置工作。
               要进行企业的软件资源管理,首先就要先识别出企业中的运行的软件和文档,将其归类汇总、登记入档。
               在项目管理中,软件资源可重用的程度是CMM衡量的一个重要指标。众所周知,提高软件的重用度也是每一家软件公司所追求的。
               首先要搞清楚自己的家底。把各个项目组的负责人召集在一起,把有重用价值的软件模块或控件收集起来,再把相关的资料组织在一起,标注说明、建立索引、由专人负责管理,可重用模块的升级和完善都要建立完整的档案资料,在升级档案中要记录升级前后的主要区别。为重用模块做出贡献的个人都要被记录在册。一个项目在做系统设计任务书时,就要考虑有哪些以往的软件资源可以利用?新一轮的开发有那些功能可以做成可重用模块。这样才能很好地管理企业的软件资源。
               软件生命周期和资源管理
               软件生命周期指软件开发全部过程、活动和任务的结构框架。软件开发包括发现、定义、概念、设计和实现阶段。
               选择一个适当的软件生命周期对项目来说至关重要。在项目策划的初期,就应该确定项目所采用的软件生命周期,统筹规划项目的整体开发流程。一个组织通常能为多个客户生产软件,而客户的要求也是多样化的,一种软件生命周期往往不能适合所有的情况。常见的软件生命周期如下表所示。
               
               常见的软件生命周期
               
               软件开发的生命周期包括两方面的内容,首先是项目应包括哪些阶段,其次是这些阶段的顺序如何。一般的软件开发过程包括:需求分析(RA)、软件设计(SD)、编码(Coding)及单元测试(Unit Test)、集成及系统测试(Integration and System Test)、安装(Install)、实施(Implementation)等阶段。
               维护阶段实际上是一个微型的软件开发生命周期,包括:对缺隙或更改申请进行分析即需求分析(RA)、分析影响即软件设计(SD)、实施变更即进行编程(Coding),然后进行测试(Test)。在维护生命周期中,最重要的就是对变更的管理。软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后,由于多方面的原因,软件不能继续适应用户的要求。要延续软件的使用寿命,就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。
               软件构件管理
               软件构件是软件系统的一个物理单元,它驻留在计算机中而不是只存在于系统分析员的脑海里。像数据表、数据文件、可执行文件、动态链接库、文档等都可以被称为构件。构件有几个基本属性:
               (1)构件是可独立配置的单元,因此构件必须自包容。
               (2)构件强调与环境和其他构件的分离,因此构件的实现是严格封装的,外界没机会或没必要知道构件内部的实现细节。
               (3)构件可以在适当的环境中被复合使用,因此构件需要提供清楚的接口规范,可以与环境交互。
               (4)构件不应当是持续的,即构件没有个体特有的属性,理解为构件不应与其有区别,在任何环境中,最多仅有特定构件的一份副本。
               可以看出,构件沿袭了对象的封装特性,但同时并不局限于一个对象,其内部可以封装一个或多个类、原型对象甚至过程,其结构是灵活的。构件突出了自包容和被包容的特性,这就是在软件生产线上作为零件的必要特征。
               软件构件要想在实际工作中得到有效利用,还离不开软件平台的支持。这个软件平台包括构件的运行支撑环境、构件开发/组装环境、构件管理环境和基于构件的开发方法以及开发过程等。在这个软件平台上,用户可以按照自己的需求,选择适合的基础服务模块或高级服务模块,按照一定管理模式搭建出一个基础的框架。这个框架承载的就是软件构件模块。基础框架和软件构件模块,共同构成了基础框架平台。例如,微软公司的COM就利用Windows系统注册表配合几种唯一标识构件的方式,实现了构件的登记、注销、定位。CORBA规范中有接口池、实现池等规范定义,配合应用登记管理的机制,也能对应用构件实施管理。
               软件分发管理
               当前,IT部门需要处理的日常事务大大超过了他们的承受能力,他们要跨多个操作系统部署安全补丁和管理多个应用。在运营管理层面上,他们不得不规划和执行操作系统移植、主要应用系统的升级和部署。这些任务在大多数情况下需要跨不同地域和时区在多个硬件平台上完成。如果不对这样的复杂性和持久变更情况进行管理,将导致整体生产力下降,额外的部署管理成本将远远超过软件自身成本。因此,软件分发管理是基础架构管理的重要组成部分,可以提高IT维护的自动化水平,实现企业内部软件使用标准化,并且大大减少维护IT资源的费用。
               技术在飞速发展,企业需要不断升级或部署新的软件来保持业务应用的适应性和有效性。在企业范围内,手工为每个业务系统和桌面系统部署应用和实施安全问题修复已经成为过去。软件分发管理的支持工具可以自动完成软件部署的全过程,包括软件打包、分发、安装和配置等,甚至在特定的环境下可以根据不同事件的触发实现软件部署的回滚操作。在相应的管理工具的支持下,软件分发管理可以自动化或半自动化地完成下列软件分发任务。
                      软件部署
                      IT系统管理人员可将软件包部署至遍布网络系统的目标计算机,对它们执行封装、复制、定位、推荐和跟踪。软件包还可在允许最终用户干预或无需最终用户干预的情况下实现部署,而任何IT支持人员均不必亲身前往。
                      无论软件产品是像Windows XP Professional这样的操作系统、像Microsoft Office这样的完整应用套件,还是由第三方厂商提供的软件或重要的Windows系统更新,均可确保软件处于即时更新状态并降低所需的工作量。
                      安全补丁分发
                      随着Windows等操作系统的安全问题越来越受到大家的关注,每隔一段时间微软都要发布修复系统漏洞的补丁,但很多用户仍不能及时使用这些补丁修复系统,在病毒爆发时就有可能造成重大损失。通过结合系统清单和软件分发,安全修补程序管理功能能够显示计算机需要的重要系统和安全升级,然后有效地分发这些升级。并就每台受控计算机所需安全修补程序做出报告,保障了基于Windows的台式机、膝上型计算机和服务器安全。
                      远程管理和控制
                      对于IT部门来说,手工对分布空间很大的个人计算机进行实际的操作将是繁琐而效率低下的。有了远程诊断工具,可帮助技术支持人员及时准确获得关键的系统信息,这样他们就能花费较少的时间诊断故障并以远程方式解决问题。
               文档管理
               软件文档(document)也被称为文件,通常指的是一些记录的数据和数据媒体,它具有固定不变的形式,可被人和计算机阅读。它和计算机程序共同构成了能完成特定功能的计算机软件(有人把源程序也当作文档的一部分)。软件文档的编制(documentation)在软件开发工作中占有突出的地位和相当大的工作量。高效率、高质量地开发、分发、管理和维护文档对于转让、变更、修正、扩充和使用文档,对于充分发挥软件产品的效益都有着重要意义。
               在整个软件生存期中,各种文档作为半成品或最终成品,会不断地生成、修改或补充。为了最终得到高质量的产品,必须加强对文档的管理。应注意做到以下几点:
               (1)软件开发小组应设一位文档保管人员,负责集中保管本项目已有文档的两套主文本。两套文本内容完全一致。其中的一套可按一定手续,办理借阅。
               (2)软件开发小组的成员可根据工作需要在自己手中保存一些个人文档。一般都应是主文本的复制件,并注意和主文本应保持一致,在做必要的修改时,也应先修改主文本。
               (3)开发人员个人只保存着主文本中与他工作相关的部分文档。
               (4)在新文档取代了旧文档时,管理人员应及时注销旧文档。在文档内容有变动时,管理人员应随时修订主文本,使其及时反映被更新了的内容。
               (5)项目开发结束时,文档管理人员应收回开发人员的个人文档。发现个人文档与主文本有差别时,应立即着手解决。这常常是由未及时修订主文本而造成的。
               (6)在软件开发过程中,可能发现需要修改已完成的文档,特别是规模较大的项目,对主文本的修改必须特别谨慎。修改以前要充分估计修改可能带来的影响,并且要按照提议、评议、审核、批准和实施等步骤加以严格控制。
               常见的文档管理工具有PVCS、Microsoft VSS、Winnote等。
               软件资源的合法保护
               个人计算机功能的不断翻新,带动了软件开发行业的发展。资源共享已经不再是一个难题。然而,这却使专业的软件开发公司面临着一大难题,那就是他们在不断地投下人力、物力、财力的情况下,却必须承受非法盗版带来的损失。于是,不断出台了一些知识产权保护的办法,来保证公司的正常运营。例如公司间购买软件或者外包业务会分别签订“购买/租用软件许可合同”和“软件开发外包合同”等合同用于保障公司的权益。同时,国家也在出台一系列的政策法规来保护版权。例如我国修订并出台了《计算机软件保护条例》用于保护知识产权等。
               软件资源的状况报告可对哪些应用程序由哪些用户使用、使用多久和基于哪些受控系统等情况加以描述。可对用户或计算机的使用情况进行跟踪,而生成的报告则可将并发使用情况数据与当前许可证所有权进行对比。这有助于将已购买软件同已使用软件进行对照调整,以便做出更加明智的远期采购决策。
   题号导航      2017年下半年 嵌入式系统设计师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第64题    在手机中做本题