免费智能真题库 > 历年试卷 > 系统架构设计师 > 2012年下半年 系统架构设计师 上午试卷 综合知识
  第25题      
  知识点:   瀑布模型   软件生存周期   软件生存周期模型
  关键词:   软件生存周期模型   软件生存周期        章/节:   软件开发方法       

 
以下关于软件生存周期模型的叙述,正确的是(25)。
 
 
  A.  在瀑布模型中/前一个阶段的错误和疏漏会隐蔽地带到后一个阶段
 
  B.  在任何情况下使用演化模型,都能在一定周期内由原型演化到最终产品
 
  C.  软件生存周期模型的主要目标是为了加快软件开发的速度
 
  D.  当一个软件系统的生存周期结束之后,它就进入到一个新的生存周期模型
 
 
 

 
  第29题    2014年下半年  
   33%
下列关于敏捷方法的叙述中,错误的是(29)。
  第29题    2012年下半年  
   44%
快速应用开发(Rapid Application Development,RAD)通过使用基于(29)的开发方法获得快速开发。当(30)时,最适合于采用RAD方法。..
  第28题    2017年下半年  
   32%
以下关于敏捷方法的叙述中,( )是不正确的。
   知识点讲解    
   · 瀑布模型    · 软件生存周期    · 软件生存周期模型
 
       瀑布模型
        瀑布模型也称为生命周期法,是结构化方法中最常用的开发模型,它把软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段,规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。采用瀑布模型的软件过程如下图所示。
        
        软件生存周期的瀑布模型
        (1)软件计划(问题的定义及规划):主要确定软件的开发目标及其可行性。
        (2)需求分析:在确定软件开发可行的情况下,对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段,这一阶段做得好,将为整个软件开发项目的成功打下良好的基础。
        (3)软件设计:主要是指根据需求分析的结果,对整个软件系统进行设计,如系统框架设计和数据库设计等。软件设计一般分为总体设计(概要设计)和详细设计。
        (4)程序编码:将软件设计的结果转换成计算机可运行的程序代码。在程序编写中必须要制定统一的、符合标准的编写规范,以保证程序的可读性和易维护性,提高程序的运行效率。
        (5)软件测试:在软件设计完成后要经过严密的测试,以发现软件在整个设计过程中存在的问题并加以纠正。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试,以减少测试的随意性。
        (6)软件维护:软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后,由于多方面的原因,软件可能会不能继续适应用户的要求,这时如果要延续软件的使用寿命,就必须对软件进行维护。
        瀑布模型是最早出现的软件开发模型,在软件工程中占有重要的地位,它提供了软件开发的基本框架。瀑布模型的本质是“一次通过”,即每个活动只做一次,最后得到软件产品,也称做“线性顺序模型”或者“传统生命周期”,其过程是从上一项活动接收该项活动的工作对象并作为输入,利用这一输入实施该项活动应完成的内容,给出该项活动的工作成果,然后作为输出传给下一项活动。同时对该项活动实施的工作进行评审,若其工作得到确认,则继续下一项活动,否则返回前项,甚至更前项的活动进行返工。
        瀑布模型有利于大型软件开发过程中人员的组织与管理,有利于软件开发方法和工具的研究与使用,从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明,上述各项活动之间并非完全是自上而下的,而是呈线性图式,因此,瀑布模型存在严重的缺陷。
        (1)由于开发模型呈线性,所以当开发成果尚未经过测试时,用户无法看到软件的效果。这样,软件与用户见面的时间间隔较长,也增加了一定的风险。
        (2)在软件开发前期未发现的错误传到后面的开发活动中时,可能会扩散,进而可能会导致整个软件项目开发失败。
        (3)在软件需求分析阶段,完全确定用户的所有需求是比较困难的,甚至可以说是不太可能的。
        :瀑布模型适用于需求明确或很少变更的项目。
 
       软件生存周期
        同任何事物一样,一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡的许多阶段,一般称为软件生存周期。把整个软件生存周期划分为若干阶段,每个阶段的任务相对独立,而且比较简单,便于不同人员分工协作,从而降低了整个软件开发工程的困难程度。通常,软件生存周期包括可行性分析与项目开发计划、需求分析、概要设计、详细设计、编码和单元测试、综合测试及维护阶段。
               可行性分析与项目开发计划
               可行性分析与项目开发计划阶段的主要任务是确定软件的开发目标及可行性。必须考虑的关键问题是:“要解决的问题是什么?”“对这些问题有可行的解决办法吗?”等。可行性分析的任务不是具体解决问题,而是研究问题的范围,探索这个问题是否值得去解,是否有可行的解决办法。该阶段应该给出关于问题定义、可行性分析和项目开发计划。
               需求分析
               需求分析阶段的任务不是具体地解决问题,而是准确地确定软件系统必须做什么,确定软件系统的功能、性能、数据和界面等要求,从而确定系统的逻辑模型。
               概要设计
               在概要设计阶段,开发人员需要将确定的功能需求转换成相应的体系结构。在该体系结构中,每个成分都是意义明确的模块,即每个模块都和某些功能需求相对应。可见,概要设计就是设计软件的结构,明确软件有哪些模块组成,模块的层次以及功能。与此同时,还要应用系统的总体数据结构和数据库结构。
               详细设计
               详细设计阶段的主要任务就是对每个模块完成的功能进行具体描述,不是编写程序,而是设计出程序的详细规格说明,该说明应该包含必要的细节,使程序员可以根据它们写出实际的程序代码。通常采用HIPO(层次加输入/处理/输出图)或PDL语言(过程设计语言)描述详细设计的结果。
               编码和单元测试
               编码和单元测试阶段就是把每个模块的控制结构转换成计算机可接受的程序代码,即写成某种特定程序设计语言表示的源程序清单,并仔细测试编写出的每一个模块。
               综合测试
               综合测试阶段的关键任务是通过各种类型的测试(及相应的调试)使软件达到预定的要求。最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构,把经过单元测试检验的模块按某种选定的策略装配起来,在装配过程中对程序进行必要的测试。所谓验收测试是按照规格说明书的规定(通常在需求分析阶段确定),由用户(或在用户积极参与下)对目标系统进行验收。通过对软件测试结果的分析可以预测软件的可靠性;反之,根据对软件可靠性的要求,也可以决定测试和调试过程什么时候可以结束。应该用正式的文档资料把测试计划、详细测试方案以及实际测试结果保存下来,作为软件配置的一个组成部分。
               维护
               维护阶段是软件生存期中时间最长的阶段。软件一旦交付正式投入运行后便进入软件维护阶段。该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。每一项维护活动都应该准确地记录下来,作为正式的文档资料加以保存。
 
       软件生存周期模型
        软件生存周期模型是一个包括软件产品开发、运行和维护中有关过程、活动和任务的框架,覆盖了从该系统的需求定义到系统的使用终止(IEEE标准12207.0—1996)。把这个概念应用到开发过程,可以发现所有生存周期模型的内在基本特征:描述了开发的主要阶段;定义了每一个阶段要完成的主要过程和活动;规范了每一个阶段的输入和输出(提交物);提供了一个框架,可以把必要的活动映射到该框架中。
        常见的软件生存周期模型有瀑布模型、演化模型、螺旋模型和喷泉模型等。
               瀑布模型(Waterfall Model)
               瀑布模型是将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型。它包括需求分析、设计、编码、测试、运行和维护。它规定了由前至后、相互衔接的固定次序,如同瀑布流水,逐级下落,如下图所示。
               
               瀑布模型为软件的开发和维护提供了一种有效的管理模式,根据这一模式制订开发计划,进行成本预算,组织开发力量,以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导,所以它是以文档作为驱动、适合于软件需求很明确的软件项目的模型。
               瀑布模型假设,一个待开发的系统需求是完整的、简明的、一致的,而且可以先于设计和实现完成之前产生。瀑布模型的优点是,容易理解,管理成本低;强调开发的阶段性早期计划及需求调查和产品测试。不足之处是,客户必须能够完整、正确和清晰地表达他们的需要;在开始的两个或三个阶段中,很难评估真正的进度状态;当接近项目结束时,出现了大量的集成和测试工作;直到项目结束之前,都不能演示系统的能力。在瀑布模型中,需求或设计中的错误往往只有到了项目后期才能够被发现,对于项目风险的控制能力较弱,从而导致项目常常延期完成,开发费用超出预算。
               增量模型(Incremental Model)
               增量模型融合了瀑布模型的基本成分和原型实现的迭代特征,它假设可以将需求分段为一系列增量产品,每一增量可以分别地开发。该模型采用随着日程时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的“增量”,如下图所示。当使用增量模型时,第1个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能,这个过程在每一个增量发布后不断重复,直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
               
               增量模型
               增量模型作为瀑布模型的一个变体,具有瀑布模型的所有优点,此外,它还有以下优点:第一个可交付版本所需要的成本和时间很少;开发由增量表示的小系统所承担的风险不大;由于很快发布了第一个版本,因此可以减少用户需求的变更;运行增量投资,即在项目开始时,可以仅对一个或两个增量投资。
               增量模型的不足之处:如果没有对用户的变更要求进行规划,那么产生的初始增量可能会造成后来增量的不稳定;如果需求不像早期思考的那样稳定和完整,那么一些增量就可能需要重新开发,重新发布;管理发生的成本、进度和配置的复杂性,可能会超出组织的能力。
               演化模型(Evolutionary Model)
               演化模型主要针对事先不能完整定义需求的软件开发,是在快速开发一个原型的基础上,根据用户在使用原型的过程中提出的意见和建议对原型进行改进,获得原型的新版本。重复这一过程,最终可得到令用户满意的软件产品。
               演化模型的主要优点是,任何功能一经开发就能进入测试,以便验证是否符合产品需求,可以帮助引导出高质量的产品要求。其主要缺点是,如果不加控制地让用户接触开发中尚未稳定的功能,可能对开发人员及用户都会产生负面影响。
               螺旋模型(Spiral Model)
               对于复杂的大型软件,开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来,加入了两种模型均忽略的风险分析,弥补了这两种模型的不足。
               螺旋模型将开发过程分为几个螺旋周期,每个螺旋周期大致和瀑布模型相符合,如下图所示。在每个螺旋周期分为如下4个工作步骤:
               
               螺旋模型
               (1)制订计划。确定软件的目标,选定实施方案,明确项目开发的限制条件。
               (2)风险分析。分析所选的方案,识别风险,消除风险。
               (3)实施工程。实施软件开发,验证阶段性产品。
               (4)用户评估。评价开发工作,提出修正建议,建立下一个周期的开发计划。
               螺旋模型强调风险分析,使得开发人员和用户对每个演化层出现的风险有所了解,继而做出应有的反应。因此特别适用于庞大、复杂并且具有高风险的系统。
               与瀑布模型相比,螺旋模型支持用户需求的动态变化,为用户参与软件开发的所有关键决策提供了方便,有助于提高软件的适应能力,并且为项目管理人员及时调整管理决策提供了便利,从而降低了软件开发的风险。在使用螺旋模型进行软件开发时,需要开发人员具有相当丰富的风险评估经验和专门知识。另外,过多的迭代次数会增加开发成本,延迟提交时间。
               喷泉模型(Fountain Model)
               喷泉模型是一种以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。迭代意味着模型中的开发活动常常需要重复多次,在迭代过程中不断地完善软件系统。无间隙是指在开发活动(如分析、设计、编码)之间不存在明显的边界,也就是说,它不像瀑布模型那样,需求分析活动结束后才开始设计活动,设计活动结束后才开始编码活动,而是允许各开发活动交叉、迭代地进行。
               喷泉模型如下图所示,该模型的各个阶段没有明显的界限,开发人员可以同步进行。其优点是可以提高软件项目开发效率,节省开发时间。由于喷泉模型在各个开发阶段是重叠的,在开发过程中需要大量的开发人员,不利于项目的管理。此外这种模型要求严格管理文档,使得审核的难度加大。
               
               喷泉模型
   题号导航      2012年下半年 系统架构设计师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第25题    在手机中做本题