全部科目 > 嵌入式系统设计师 >
2020年下半年 上午试卷 综合知识
第 7 题
知识点 风险管理   过程模型   螺旋模型(Spiral Model)  
章/节 系统开发过程及其项目管理  
 
 
传统过程模型中,(7)首先引入了风险管理
 
  A.  瀑布模型
 
  B.  螺旋模型
 
  C.  V模型
 
  D.  原型化模型
 
 




 
 
相关试题     过程模型 

  第15题    2015年下半年  
若用户需求不清晰且经常发生变化,但系统规模不太大且不太复杂,则最适宜采用(15)开发方法。对于数据处理领域的问题,若系统规模不太大且不太复杂,需求变化也不大,则最适宜采用(16)开发方法。..

  第18题    2010年下半年  
敏捷开发方法XP是一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方法,其特性包含在12个最佳实践中。系统的设计要能够尽可能早交付,属于(18)最佳实践。

  第16题    2016年下半年  
在敏捷过程的开发方法中,(16)使用了迭代的方法,其中,把每段时间(30天)一次的迭代称为一个“冲刺”,并按需求的优先级别来实现产品,多个自组织和自治的小组并行地递增实现产品..

 
知识点讲解
· 风险管理
· 过程模型
· 螺旋模型(Spiral Model)
 
        风险管理
        风险管理主要包括脆弱性识别、风险计算与分析和风险处置三个方面。
               脆弱性识别
               脆弱性是资产自身存在的,如没有被威胁利用,脆弱性本身不会对资产造成损害。如信息系统足够健壮,威胁难以导致安全事件的发生。因此,组织一般通过尽可能消减资产的脆弱性,来阻止或消减威胁造成的影响,所以脆弱性识别是风险评估中最重要的一个环节。
               脆弱性可从技术和管理两个方面进行识别。技术方面,可从物理环境、网络、主机系统、应用系统、数据等方面识别资产的脆弱性;管理方面,可从技术管理脆弱性和组织管理脆弱性两方面识别资产的脆弱性,技术管理脆弱性与具体技术活动相关,组织管理脆弱性与管理环境相关。
               风险计算与分析
               组织或信息系统安全风险需要通过具体的计算方法实现风险值的计算。风险计算方法一般分为定性计算方法和定量计算方法两大类。
               通过风险计算,应对风险情况进行综合分析与评价。风险分析是基于计算出的风险值确定风险等级。风险评价则是对组织或信息系统总体信息安全风险的评价,首先对风险计算值进行等级化处理。风险等级化处理目的是,对风险的识别直观化,便于对风险进行评价。等级化处理的方法是按照风险值的高低进行等级划分,风险值越高,风险等级越高。风险等级一般可划分为五级:很高、高、中等、低、很低,也可根据项目实际情况确定风险的等级数,如划分为高、中、低三级。
               风险处置
               依据风险评估结果,针对风险分析阶段输出的风险评估报告进行风险处置。风险处置方式一般包括接受、消减、转移、规避等。安全整改是风险处置中常用的风险消减方法。风险评估需提出安全整改建议。
               安全整改建议需根据安全风险的严重程度、加固措施实施的难易程度、降低风险的时间紧迫程度、所投入的人员力量及资金成本等因素综合考虑。
               (1)对于非常严重、需立即降低且加固措施易于实施的安全风险,建议被评估组织立即采取安全整改措施。
               (2)对于非常严重、需立即降低,但加固措施不便于实施的安全风险,建议被评估组织立即制定安全整改实施方案,尽快实施安全整改;整改前应对相关安全隐患进行严密监控,并作好应急预案。
               (3)对于比较严重、需降低且加固措施不易于实施的安全风险,建议被评估组织制定限期实施的整改方案;整改前应对相关安全隐患进行监控。
               在风险整改建议提出之后,紧接着组织召开的评审会是评估活动结束的重要标志。评审会应由被评估组织组织,评估机构协助。评审会参与人员一般包括:被评估组织、评估机构及专家等。
               被评估组织包括:单位信息安全主管领导、相关业务部门主管人员、信息技术部门主管人员、参与评估活动的主要人员等;
               最后,需在评审会中有专门记录人员负责对各位专家发表意见进行记录。评审会成果是会议评审意见。评审意见包括:针对评估项目的实施流程、风险分析的模型与计算方法、评估的结论及评估活动产生的各类文档等内容提出意见。评审意见对于被评估组织是否接受评估结果,具有重要的参考意义。
               依据评审意见,评估机构应对相关报告进行完善、补充和修改,并将最终修订材料一并提交被评估组织,作为评估项目结束的移交文档。
 
        过程模型
        产品开发生命周期通常使用过程模型进行表示。过程模型习惯上也称为开发模型,它是系统开发全部过程、活动和任务的结构框架。典型的开发过程模型有瀑布模型、增量模型、演化模型(原型模型、螺旋模型)、喷泉模型、基于构件的开发模型和形式化方法模型等。
               瀑布模型(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个基本的原则:有一个使命作为指导;特征被视为客户价值的关键点;过程中的等待是很重要的,因此“重做”与“做”同样关键;变化不被视为改正,而是被视为对软件开发实际情况的调整;确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求;风险也包含其中。
 
        螺旋模型(Spiral Model)
        对于复杂的大型系统,开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来,加入了两种模型均忽略的风险分析,弥补了这两种模型的不足。螺旋模型是一种演化模型。
        螺旋模型将开发过程分为几个螺旋周期,每个螺旋周期大致和瀑布模型相符合,如下图所示。在每个螺旋周期分为如下4个工作步骤。
        
        螺旋模型
        (1)制订计划。确定系统的目标,选定实施方案,明确项目开发的限制条件。
        (2)风险分析。分析所选的方案,识别风险,消除风险。
        (3)实施工程。实施系统开发,验证阶段性产品。
        (4)用户评估。评价开发工作,提出修正建议,建立下一个周期的开发计划。
        螺旋模型强调风险分析,使得开发人员和用户对每个演化层出现的风险有所了解,继而做出应有的反应。因此特别适用于庞大、复杂并且具有高风险的系统。
        与瀑布模型相比,螺旋模型支持用户需求的动态变化,为用户参与软件开发的所有关键决策提供了方便,有助于提高产品的适应能力,并且为项目管理人员及时调整管理决策提供了便利,从而降低了系统开发的风险。在使用螺旋模型进行系统开发时,需要开发人员具有相当丰富的风险评估经验和专门知识。另外,过多的迭代次数会增加开发成本,延迟提交时间。



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

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