免费智能真题库 > 历年试卷 > 软件设计师 > 2013年下半年 软件设计师 上午试卷 综合知识
  第29题      
  知识点:   软件需求   过程模型   开发过程
  关键词:   开发过程模型   需求   开发   开发过程        章/节:   系统分析基础知识       

 
(29)开发过程模型最不适用于开发初期对软件需求缺乏准确全面认识的情况。
 
 
  A.  瀑布
 
  B.  演化
 
  C.  螺旋
 
  D.  增量
 
 
 

 
  第18题    2013年上半年  
   45%
“软件产品必须能够在3秒内对用户请求作出响应”属于软件需求中的(18)。
  第19题    2017年下半年  
   32%
某企业财务系统的需求中,属于功能需求的是( )。
  第15题    2022年下半年  
   43%
某零件厂商的信息系统中,一个基本加工根据客户类型、订单金额、客户信用等信息的不同采取不同的行为,此时最适宜采用()来描述..
   知识点讲解    
   · 软件需求    · 过程模型    · 开发过程
 
       软件需求
        在进行需求获取之前,首先要明确需要获取什么,也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常,这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等,并预先估计以后系统可能达到的目标。此外,还需要注意其他非功能性的需求。具体内容如下。
        (1)功能需求。
        (2)性能需求。
        (3)用户或人的因素。
        (4)环境需求。
        (5)界面需求。
        (6)文档需求。
        (7)数据需求。
        (8)资源使用需求。
        (9)安全保密要求。
        (10)可靠性要求。
        (11)软件成本消耗与开发进度需求。
        (12)其他非功能性要求。
               需求分析的任务
               需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体来说有下面几点。
               (1)确定软件系统的综合要求,包括系统界面、功能、性能、安全性、保密性、可靠性、运行等方面的要求。
               (2)分析软件系统的数据要求,包括基本数据元素、数据元素之间的逻辑关系、数据量、峰值等。
               (3)导出系统的逻辑模型,在结构化方法中可用数据流图来描述;在面向对象分析方法中可以用类模型来描述。
               (4)修正项目开发计划。
               (5)如有必要,可开发一个原型系统以验证用户的需求。
               软件需求的分类
               下面介绍软件需求的分类。
               (1)功能需求。所开发的软件必须具备什么样的功能。
               (2)非功能需求。它是指产品必须具备的属性或品质,如可靠性、性能响应时间、容错性和可扩展性等。
               (3)设计约束。其也称为限制条件、补充规约,这通常是对解决方案的一些约束说明。
               软件需求分析方法
               需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。它定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的,数据域具有数据流、数据内容和数据结构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个基本的原则:有一个使命作为指导;特征被视为客户价值的关键点;过程中的等待是很重要的,因此“重做”与“做”同样关键;变化不被视为改正,而是被视为对软件开发实际情况的调整;确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求;风险也包含其中。
 
       开发过程
        嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
        项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段,与通用软件的开发过程基本一致,都可按照软件工程方法进行,如采用原型化方法、结构化方法等。
        :由于嵌入式软件的运行和开发环境不同,开发工作是交叉进行的,所以每一步都要考虑到这一点。
        程序建立阶段的工作是根据详细设计阶段产生的文档进行的,主要是源代码编写、编译链接等子过程,这些工作都在宿主机上进行,不需要用到目标机。产生应用程序的可执行文件后,就要用到交叉开发环境进行调试,根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高,所以,在对嵌入式系统进行白盒测试时,要求有更高的代码覆盖率。
        最后,要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同,可以固化在EPROM(Erasable Programmable ROM,可擦除可编程ROM)和Flash等存储器中,也可固化在DOC(DiskOnChip)等电子盘中,通常还要借助一些专用编程器进行。
   题号导航      2013年下半年 软件设计师 上午试卷 综合知识   本试卷我的完整做题情况  
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 /
 
第29题    在手机中做本题