极限编程与增量开发模型的对比分析

极限编程与增量开发模型的对比分析
极限编程与增量开发模型的对比分析

极限编程与增量开发模型的对比分析

崔华

(武汉理工大学计算机科学与技术学院计算机软件与理论,武汉430070)

【摘要】面对日益增长和变化的需求,传统的软件工程需要不断改进保证理论对实践的指导作用,重构、设计模式、面向对象测试都是最近新发展起来的技术,它们的出现推动了方法论的发展,极限编程、增量模型便是这些方法论中最为令人注目的两种,文中通过分析它们的原理、有缺点,提出了一种基于增量模型引入极限编程、风险分析和原型的开发方法。【关键词】极限编程没有银弹并行过程增量模型

The Comparison And Analysis between Extreme Programming

& Increasing development model

Cui-hua

(Computer Science &Technology School Of WuHan University Of Technology, Graduate

Computer Software & Theory,WuHan 430070)

【Abstract】With increasing and unstable requirement of software, traditional software engineering must take some measure to appropriate it and ensure itself as a guiding of software development. Refractory, design patterns, comprehensive unit testing, pair programming are the tools of developers who are exploring new ways to meet the difficult goals of rapid product delivery, low defect levels, and flexibility. Extreme Programming and increasing model are the best presentation of it, in this paper, analysis the advantages and flaws of them at first, then giving a new method which is base on extreme programming and risk analysis and prototype model. 【Key words】XP No sliver bulletin paralleling process Increasing model

引言

在上个世纪七十年代经历了软件危机之后,软件工程受到信息技术领域的广泛关注,在这三十年里,软件工程无论是在理论上还是在实践中都取得了很大的进展,从技术上讲,现代软件开发技术都以面向对象技术为核心,通过管理技术与开发技术相结合来最大限度的解决用户需求的变化和开发计划之间的矛盾,提高软件生产率。在开发过程中,选取合适的模型进行构建目标系统,在管理上通过风险分析以及软件配置管理来协调软件开发进度和产品质量的之间的关系,达到利益最大化。但是,随着信息技术的发展和在大规模软件的应用,曾级数增长的软件需求和日益膨胀的软件开发队伍使得现有的软件开发技术和管理技术面临着严峻的挑战,于是在软件工程领域出现了各种各样的软件开发方法和开发技术,从管理和技术以及软件开发涉及到的方方面面来解决软件危机遗留下来的各种问题,极限编程和增量模型便是这众多方法和理论中的一种,它们都从如何适应变化了的需求,如何理解、表达和解决复杂的问题域来提高软件生产效率。

极限编程与增量式开发模型

传统的软件工程是重量级的开发模式,从问题定义到维护都采用严格的评审标准,提倡以文档为驱动(对整个软件项目而言),人员之间的交流与沟通主要是通过项目文档实现的,项目文档的编写势必要占用大量的人力物力,然而在整个软件开发过程中由于通讯问题带来的费用占到了软件总体开发成本的6%,由于开发小组成员的增加,通讯费用会呈线性增长,因此在大型项目中文档的编写和沟通产生的费用实际上可以占到整个项目的10%或者更多。

Harlan Mill建议所有软件系统都应该以增量的方式开发,即,首先系统应该能够运行,即使未完成任何有用功能,只能正确调用一系列伪子系统。接着,系统逐步被充实,子系统轮流被开发,或者是在更低的层次调用程序、模块、子系统的占位符(伪程序)等【3】。

增量开发模型采用递增的方式,使开发以所谓的增量模式进行,产品北作为一系列的增量构件来设计、实现、集成和测试。增量开发模型在哥哥阶段并不提交一个可实际运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解为构件,开发人员将构件逐个的交付给产品,用户在从第一个构件交付时起便可以同步使用、测试和反馈已交付产品的性能,从而引入了软件并行开发过程,可以从更多方面提高软件生产率。这也证明了重用和交互的构件开发是解决软件根本困难的一种方法【4】

极限编程是在复用基础之上的轻量级开发模式,提倡简化软件开发过程,通过四个原则和四个过程实现以最小的代价开发出令客户满意的软件产品。极限编程提出以测试驱动开发过程的向前推进,用隐喻来取代传统软件工程中的软件体系结构,用配对开发来取代正式的软件开发小组,简化开发小组自身的复杂性,提出了人人参与,及时反馈的开发原则,对传统的开发过程进行改进,通过大量的测试和修正实践来提高软件维护时的效率,通过简洁的设计模式使得设计简单化,用大多数人乐于接受的方式来改善和提高协作水平,让软件开发过程容易控制,促进软件生产效率的提高。

极限编程和增量式开发模型中存在的问题

从实践上看无论是极限编程还是增量开发模型在软件开发过程中都体现出来了他们的价值,但是它们和任何其他理论一样,在自己发展的初期都暴露了自己的缺陷和不足,都有自己的适用范围。传统的软件工程通过一系列严格的规定和方法来约束和管理开发过程,可以说它是基于方法论的,旨在使软件开发更可预见并更加有效。这些方法论借鉴其它的工程规范,通过制定一个严格强调计划的详细的过程来达到这样的目标。但是这些方法学的体系庞大,并且涉及众多的学科,所以这种方法要遵循的规则复杂,往往阻碍整体的开发进度。

极限编程通过简化传统的重量级软件工程来实现自由软件和小项目的开发在良好有序的状态下进行。以改进沟通和反馈的途径为手段,提高通信效率,简化文档和设计,完成传统软件工程追求的目标。它同增量模型有着许多共同之处,采用迭代设计过程,注重重用,但是忽略了在软件开发过程中人员的依赖关系以及运行中的系统分析和设计。

软件开发过程中不同人员之间的关系联系是十分紧密的,任何一个开发人员都要和其他人员进行交互,存在沟通问题,面对面的沟通和交流可以加快对问题形成共识,但并不一定总是如此,因此引入标准是减少无休止争吵的前提。

任何一种软件工程理论都认同一个相同的观点:发现错误越早,修改该错误的成本就越低,这就意味着如果能在需求阶段改正尽可能多的错误,那么软件开发成本将会大幅度的降低。

极限编程采用隐喻来简化系统架构,使得需求和高层设计的结果更加直观,易于评价和

理解,实现采用结对编程的方式来加快程序员对特定问题的理解,以便产生更为简单的代码,采用整个生命周期不间断的测试来保证软件的质量和可维护性,但是它却忽视了软件产品开发过程中人员之间的依赖性以及更改运行中的系统分析和设计等问题。

软件开发过程中,特别是基于面向对象的软件开发本质上都是面向构件和重用的,它引入了一个新的问题――并行过程,如果人员之间没有很好的协调和细致的分工使用再好的技术都是徒劳,所以正式的开发小组是必须的,文档的编写也必须详细,这些都是不可避免,也是至关重要的,因为它关系到重用问题,另外,软件开发过程中人员的变动是任何一个公司和管理技术都必须面对的,但是可以采用一定的预防措施减少这种影响产生的“抖动”效,从某种意义上说正式的开发小组也是一种可以限制人员变动产生的负面作用的一种方式。

按照布鲁克斯的观点,可以认为传统的软件工程(包括面向对象软件工程)它解决的是软件开发中的主要问题。但是如果开发的次要部分少于整个工作的9/10,那么即使不占用任何时间(除非出现奇迹),也不会给生产率带来数量级的提高,因此,必须着手解决开发的根本问题【5】。然而主要问题和次要问题再不同的系统中是不同的,极限编程解决的是诸如测试之类的主要问题和文档编写、沟通交流之类的次要问题,但是它并不是万能的。

在软件开发过程中主要复杂性和工作量在复用获取、体系结构、建立原型、配置管理、正式集成、和项目管理以及编写文档。在具有1000个功能点的外包软件活动中有以下的参数估计【8】。

项目管理、编写文档、建立原型和体系结构占用了大量的开发成本,编写文档可以通过文档规范化来从某种程度上简化但是极限编程的灵活方便的沟通和修改必须的面对另外一个难题,项目管理的复杂度问题,产生这个问题的关键是要保证开发人员意见和各种活动的同一性必须引入大量的管理工具如:SCM工具,版本管理工具等,这些软件是不可能有开发人员自己编写的,同时引入这些工具也是必须的,从这方面来说它并没有比增量开发模型优越。

和极限编程不同的是,增量模型沿用了传统软件工程的各种理论,加入了风险分析和管理,是软件工程七原则的应用,它采用正式的开发小组,严格的管理和分阶段的测试,有利于分工和更准确的控制开发过程,但是它本身也存在和当前开发协调的因素,变动的需求产生无休止的迭代,使得开发陷入无法提交任何可用产品的状态之中。

增量模型采用分阶段的测试给人的感觉是测试成了一个单独的阶段,实际上的软件开发过程测试是贯穿与开发活动的始终,分阶段的测试往往导致信息交流和反馈速度缓慢,成本开支过大,往往达到开发总成本的30%-40%。

再次,增量模型关注的是软件开发过程中的主要问题的解决,忽视了次要问题的分析和解决,除了在沟通交流上有严格的通信路径占用大量资源外,文档的结构也有待改进,分析方法、表示方法要统一,力求简单直观。

一种改进的软件开发方法

要提高软件开发的效率,必须从开发方法和技术等多方面来进行。极限编程和增量模型都是面对变化的需求对传统软件工程作出的变化,但是它们都或多或少的存在不足。因此我们必须找出一种拥有两者优点的方法来继承它们,同时改进它们的缺陷,通过对BEP(电子商务平台)和EAIP(企业应用集成)项目的开发中各种问题的分析,原型的建立、开发文档的编写、项目小组之间的沟通、测试的规模、软件配置管理是制约项目成功的关键。

在项目开始前必须确定开发小组的构成形式,文档和设计的标准及规范,项目中必须用到的管理和设计工具,在对需求进行风险分析后提交需求报告,根据需求分析然后制定需求规格说明书,在进行风险分析后提交需求规格说明书,经过风险分析建立原型,然后根据确认的原型开发构件,在创建构件的同时进行测试,然后通过组装测试创建产品,给出实际可运行的系统。

结束语

极限编程和增量模型作为一种开发方法出现和应用是软件工程发展里程中的重要一步,是对变化的一种自觉的调整和适应,但是它们和其他任何一种方法论一样,在发展的初期都

有不成熟的地方,因此我们必须在实际的开发过程中通过实践来完善它们,使它们解决问题的能力更高,更灵活,能够成为提高软件生产率的工具。原型方法、极限编程等都是人们在长期的软件开发活动中总结的经验和教训的结晶,我们只用通过学习、实践、分析、改进,不断发展各种理论知识和方法论,才能推动科学理论的发展。在软件工程上,已经证明任何一种新的理论都可以用软件工程七原则来说明,这同时也表明了任何问题都是可以通过不断的学习和研究在理论上给予解决的,这个改进的开发方法不能说明它解决了软件开发的所有问题,但是它继承了许多被实践和理论证明有效的方法,同时解决了各个单一方法的缺陷,因此在实际开发过程中使可行的。

参考文献

【1】Kent Beck 著,唐东铭译极限编程, 北京人民邮电出版社,2002

【2】Erich Gamma, Richard Helm, Ralph johnsom, John Vlissides著, Design Patterns Elements of Reusable Object-Oriented Software. British Pearson Education Litimted 2002

【3】Frederick P.Brooks·JR著. The Mythical Man Month 北京清华大学出版社,2002 【4】Cox, B. J., There is a silver bullet, Byte, Amercian 1990

【5】Frederick P.Brooks·JR 著. 没有银弹:软件工程的根本和次要问题IFIPS 1986

【6】Glass, R. L, S. A. Conger, Research software talks: Intellectual or clerical? Information or Management, Amercian 1992.

【7】Stephen R.Schach 著,袁兆山等译,软件工程, 北京机械工业出版社1999

【8】FergusO’Connell著How to Run Successful Projects III ,The Silver Bullet British Pearson Education Litimited, 2001

几种常见的测试模型汇总

几种比较常见的测试模型汇总: V模型 V模型最早是由Paul Rook在20世纪80年代后期提出的,旨在改进软件开发的效率和效果。V模型反映出了测试活动与分析设计活动的关系。从左到右描述了基本的开发过程和测试行为,非常明确的标注了测试过程中存在的不同类型的测试,并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。 V模型指出,单元和集成测试应检测程序的执行是否满足软件设计的要求;系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标;验收测试确定软件的实现是否满足用户需要或合同的要求。 但V模型存在一定的局限性,它仅仅把测试作为在编码之后的一个阶段,是针对程序进行的寻找错误的活动,而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。 W模型(也叫双V模型)

W模型由Evolutif公司公司提出,相对于V模型,W模型增加了软件各开发 阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成,分别代 表测试与开发过程,图中明确表示出了测试与开发的并行关系。 W模型强调:测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、设计等同样要测试,也就是说,测试与开发是同步进行的。W模型 有利于尽早地全面的发现问题。例如,需求分析完成后,测试人员就应该参与到对需求的验证和确认活动中,以尽早地找出缺陷所在。同时,对需求的测试也有利于及时了解项目难度和测试风险,及早制定应对措施,这将显著减少总体测试时间,加快项目进度。 但W模型也存在局限性。在W模型中,需求、设计、编码等活动被视为串行的,同时,测试和开发活动也保持着一种线性的前后关系,上一阶段完全结束,才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况,W模型并不能解除测试管理面临着困惑。 X模型 X模型是由Marick提出的,他的目标是弥补V模型的一些缺陷,例如:交接、经常性的集成等问题。 X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试, 此后将进行频繁的交接,通过集成最终合成为可执行的程序。右上半部分,这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户,也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。 X模型还定位了探索性测试(右下方)。这是不进行事先计划的特殊类型的测试,诸如“我这么测一下结果会怎么样?”,这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。 但V模型的一个强项是它明确的需求角色的确认,而X模型没有这么做,这大概是X模型的一个不足之处。而且由于X模型从没有被文档化,其内容一开始需要从V模型的相关内容中进行推断,因为它还没有完全从文字上成为V 模型的全面扩展。

软件开发模型介绍与对比分析

常用的软件开发模型 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目工作的基础。对于不同的软件系统,可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等,以及允许采用不同的软件工具和不同的软件工程环境。 1. 瀑布模型-最早出现的软件开发模型 1970年温斯顿?罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型。 瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。从本质来讲,它是一个软件开发架构,开发过程是通过一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好“返回”上一个阶段并进行适当的修改,开发进程从一个阶段“流动”到下一个阶段,这也是瀑布开发名称的由来。 瀑布模型是最早出现的软件开发模型,在软件工程中占有重要的地位,它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入,利用这一输入实施该项活动应完成的内容给出该项活动的工作成果,并作为输出传给下一项活动。同时评审该项活动的实施,若确认,则继续下一项活动;否则返回前面,甚至更前面的活动。对于经常变化的项目而言,瀑布模型毫无价值。(采用瀑布模型的软件过程如图所示)

软件过程模型优缺点

软件过程模型优缺点 一、瀑布模型 1、优点 1)它是一种线性的开发模型,具有不可回溯性。2)过程模型简单,执行容易。3)将复杂的软件开发过程明确分解为几个顺序的步骤,降低开发软件的复杂性。 2、缺点 1)无法适应变更,由于开发模型是线性的用户只有等到整个过程的末期才能见到开发成果,从而卡增加了开发的风险。2)早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重后果。 二、快速原型模型 1、优点 1)可以得到比较良好的需求定义,容易适应需求的变化。2)开发人员和用户在“原型”上达成一致。可以减少设计中的错误和开发中的风险,也减少了对用户培训的时间,而提高了系统的实用、正确性以及用户的满意程度。3)缩短了开发周期,加快了工程进度,降低成本。 2、缺点 1)不宜利用原型系统作为最终产品。采用原型模型开发系统,用户和开发者必须达成一致。2)不利于开发人员的创新。 三、增量模型 1、优点 1)将待开发的软件系统模块化。可以分批次地提交软件产品,使用户可以及时了解软件项目的进展。2)以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到这个软件系统。3)开发顺序灵活。开发人员可以对构件的实现顺序进行优先级排序,先完成需求稳定的核心组件。当组件的优先级发生变化时。还能及时第实现顺序进行调整。 2、缺点 1)要求待开发的软件系统可以被模块化。如果待开发的软件系统很难被模块化,那么将会给增量开发带来很多麻烦。

四、螺旋模型 1、优点 1)将风险分析扩展到各个阶段中,大幅度降低了软件开发的风险。2)以小的分段来构建大型系统,使成本计算变得简单容易。3)客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。 2、缺点 1)模型的控制和管理较为复杂,可操作性不强,对项目管理人员的要求较高。2)过多的迭代次数会增加开发成本,延迟提交时间。 五、喷泉模型 1、优点 喷泉模型不像瀑布模型那样,需要分析活动结束后才开始设计活动,设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限,开发人员可以同步进行开发。其优点是可以提高软件项目开发效率,节省开发时间,适应于面向对象的软件开发过程。 2、缺点 由于喷泉模型在各个开发阶段是重叠的,因此在开发过程中需要大量的开发人员,因此不利于项目的管理。此外这种模型要求严格管理文档,使得审核的难度加大,尤其是面对可能随时加入各种信息、需求与资料的情况。 六、基于组件的开发模型 1、优点 1)用现有的组件和系统框架进行产品开发,可靠性相对新研发组件高。2)开发简单,降低了开发成本和风险。 2、缺点 任何基于组件技术的系统,在开发前期都会面临一定的风险。对于组件式软件开发而言.对象技术不是必需的,但是又不能完全脱离对象技术,而且组件技术还离不开体系结构,大多数组件技术对于组件都有一定的限制。 七、统一软件开发过程模型 1、优点 1)有利于更好地理解需求、设计出合理的系统架构,并最终交付一系列渐趋完善的成功。2)每个阶段结束时都要进行阶段评估,这样可以及早发现软件中的缺陷。

软件工程考试题库

软件工程概述 一单项选择 1.软件生命周期一般包括:软件开发期和软件运行期,下述(D)不是软件开发期所应包含的内容。 A需求分析B结构设计C程序编制D软件维护 2.软件是一种逻辑产品,它的开发主要是(A)。 A研制B拷贝C再生产D复制 3.以文档作为驱动,适合于软件需求很明确的软件项目的生存周期模型是(C)。 A喷泉模型B增量模型C瀑布模型D螺旋模型 4.在软件生存周期中,(B)阶段必须要回答的问题是“要解决的问题是做什么?”。 A详细设计B可行性分析和项目开发计划C概要设计D软件测试 5.软件产品与物质产品有很大区别,软件产品是一种(C)产品 A有形B消耗C逻辑D文档 6.(C)把瀑布模型和专家系统结合在一起,在开发的各个阶段上都利用相应的专家系统来帮助软件人员完成开发工作。 A原型模型B螺旋模型C基于知识的智能模型D喷泉模型 7.(B)阶段是为每个模块完成的功能进行具体的描述,要把功能描述转变为精确的、结构化的过程描述。 A概要设计B详细设计C编码D测试 8.下列软件开发模型中,适合于那些不能预先确切定义需求的软件系统的开发的模型是(A)。 A原型模型B瀑布模型C基于知识的智能模型D变换模型 9.下列软件开发模型中,以面向对象的软件开发方法为基础,以用户的需求为动力,以对象来驱动的模型是(C)。 A原型模型B瀑布模型C喷泉模型D螺旋模型 10.下列软件开发模型中,支持需求不明确,特别是大型软件系统的开发,并支持多种软件开发方法的模型是(D)。 A原型模型B瀑布模型C喷泉模型D螺旋模型 11.软件特性中,使软件在不同的系统约束条件下,使用户需求得到满足的难易程度称为(C)。 A可修改性B可靠性C可适应性D可重用性 12.软件特性中,一个软件能再次用于其他相关应用的程度称为(B)。 A可移植性B可重用性C容错性D可适应性 13.软件特性中,(A)是指系统具有清晰的结构,能直接反映问题的需求的程度。 A可理解性B可靠性C可适应性D可重用性 14.软件特性中,软件产品交付使用后,在实现改正潜伏的错误、改进性能、适应环境变化等方面工作的难易程度称为(B)。 A可理解性B可维护性C可适应性D可重用性 15.软件特性中,软件从一个计算机系统或环境移植到另一个上去的难易程度指的是(C). A可理解性B可修改性C可移植性D可重用性 16.软件特性中,在给定的时间间隔内,程序成功运行的概率指的是(D)。 A有效性B可适应性C正确性D可靠性 17.软件特性中,允许对软件进行修改而不增加其复杂性指的是(A)。 A可修改性B可适应性C可维护性D可移植性 18.软件特性中,多个软件元素相互通讯并协同完成任务的能力指的是(B)。 A可理解性B可互操作性C可维护性D可追踪性 19.软件特性中,根据软件需求对软件设计、程序进行正向追踪,或根据程序、软件设计对软件需求进行逆向

软件工程——软件开发过程中用到的各种图

软件工程——软件开发过程中用到的各种图 一、宏观导图 导图说明:我们的软件开发中用到的各种图型工具都是为了辅助我们更好的理解开发的阶段或者过程。上图是根据软件过程中各个阶段所需要用到的各种图的一个小结。下面是各种图的简介和示例。 二、谈细节: 1、问题定义阶段(规划阶段): UC图:( Use Creat 图)它是 BSP( business system planning )法中常用的子系统划分工具。

2、可行性分析 2.1系统流程图:是描述系统物理模型的一种传统工具。它是表达数据在系统各部件之间流动的情况,而不是对数据加工处理的控制过程,它是物理数据流图而不是程序流程图。系统流程图形象的呈现了软件的功能,即使不懂软件的人也可以轻松的看懂,可以说它是软件设计师与用户之间沟通、交流的有效工具。

3、需求分析: 3.1 DFD图(Data Flow Diagram):从数据传递和加工角度,以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程.建立系统的功能模型。 3.2 ERD(Entity-Relationship Diagram)图:当数据量很大并且数据间关系复杂时对于数据的分析就得用到它来刻画系统数据模型

3.3 IPO(input process output)图描述了输入数据、处理数据、输出数据之间的关系。 3.4 STD(State Transition Diagram)图:刻画系统响应外部事件的过程。为系统的行为建模。

面向数据结构的几个图形工具: 3.5 层次方框图:用来展示数据的层次结构 3.6 warnier图:和层次方框图一个意思,不过她能描述的手段比层次图更加丰富。

软件工程复习题及答案

2006-2007-2软件工程复习 一、单项选择题(20选10) 1. 结构化分析的主要描述手段有( B )。 A. 系统流程图和模块图 B. DFD图、数据词典、加工说明 C. 软件结构图、加工说明 D. 功能结构图、加工说明 2. 用于表示模块间的调用关系的图叫( D )。 A.PAD B.SC C.N-S D.HIPO 3. 在( B )模型中是采用用例驱动和架构优先的策略,使用迭代增量建造方法,软件“逐渐”被开发出来的。 A.快速原型 B. 统一过程 C.瀑布模型 D. 螺旋模型 4. 常用的软件开发方法有面向对象方法、面向( A )方法和面向数据方法。 A. 过程 B. 内容 C. 用户 D. 流程 5 从工程管理的角度来看,软件设计分两步完成( D )。 A. ①系统分析②模块设计 B. ①详细设计②概要设计 C. ①模块设计②详细设计 D. ①概要设计②详细设计 6. 程序的三种基本结构是( B )。 A. 过程、子程序、分程序 B.顺序、条件、循环 C.递归、堆栈、队列 D.调用、返回、转移 7. 程序的三种基本结构是( B )。 A. 过程、子程序、分程序 B.顺序、条件、循环 C.递归、堆栈、队列 D.调用、返回、转移 8. SD方法衡量模块结构质量的目标是( C )。 A. 模块间联系紧密,模块内联系紧密 B. 模块间联系紧密,模块内联系松散 C. 模块间联系松散,模块内联系紧密 D. 模块间联系松散,模块内联系松散 9.为提高软件测试的效率,应该( C )。 A.随机地选取测试数据 B.取一切可能的输入数据作为测试数据 C.在完成编码后制定软件测试计划 D.选择发现错误可能性大的数据作为测试数据 10.( D )测试用例发现错误的能力较大。 A.路径覆盖 B.条件覆盖 C.判断覆盖 D.条件组合覆盖 11.软件需求分析应确定的是用户对软件的( A )。 A. 功能需求和非功能需求 B. 性能需求 C. 非功能需求 D. 功能需求 12.下列各种图可用于动态建模的有( C )。 A.用例图 B. 类图 C. 序列图 D. 包图 13.软件过程模型有瀑布模型、( B )、增量模型等。 A. 概念模型 B. 原型模型 C. 逻辑模型 D. 物理模型 14.面向对象的分析方法主要是建立三类模型,即( D )。 A. 系统模型、ER模型、应用模型 B. 对象模型、动态模型、应用模型 C. E-R模型、对象模型、功能模型 D. 对象模型、动态模型、功能模型 15.测试的分析方法是通过分析程序( B )来设计测试用例的方法。 A.应用范围 B.内部逻辑 C.功能 D.输入数据 16. 软件工程是研究软件( B )的一门工程学科。 A. 数学 B. 开发与管理 C. 运筹学 D. 工具 17. 需求分析可以使用许多工具,但( C )是不适合使用的。 A.数据流图 B.判定表 C.PAD图 D.数据字典 18.划分模块时,一个模块内聚性最好的是( A )。 A. 功能内聚 B. 过程内聚 C. 信息内聚 D. 逻辑内聚 19.软件可移植性是用来衡量软件的( D )的重要尺度之一。 A.效率 B. 质量 C. 人机关系 D. 通用性 20.软件配置管理是在软件的整个生存周期内管理( D )的一组活动。 A.程序 B.文档 C.变更 D.数据 二、判定题(20选10) 1统一过程是一种以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法。(×) 2当模块中所有成分结合起来完成一项任务,该模块的内聚是偶然内聚。(×) 3SD方法衡量模块结构质量的目标是模块间联系松散,模块内联系紧密(√) 4当模块中所有成分结合起来完成一项任务,该模块的内聚是功能内聚。(√) 5在进行需求分析时,就应该同时考虑软件的可维护性问题。(√) 6需求分析可以使用许多工具,但数据流图是不适合使用的。(×)

软件开发与项目管理课后练习(参考答案)

软件开发与项目管理参考答案 第一章(软件开发模型和开发方法) (一)知识回顾与思考 1、软件产品的特性是什么? ①软件是一种逻辑产品,具有无形性; ②软件产品的生产主要是研制;主要是脑力劳动; ③软件不存在磨损和老化问题,但存在退化问题; ④软件产品的成本非常昂贵,其开发方式目前尚未完全摆脱手工生产方式; ⑤软件具有“复杂性”,其开发和运行常受到计算机系统的限制。 2、软件生产有几个阶段?各有何特征? ①程序设计时代:这个阶段生产方式是个体劳动,使用的生产工具是机器语言,汇编语言。 ②程序系统时代:这个阶段生产方式是小集团合作生产,使用的生产工具是高级语言,开发方法仍依靠个人技巧,但开始提出结构化方法。 ③软件工程时代:这个阶段生产方式是工程化的生产,使用数据库﹑开发工具﹑开发环境﹑网络﹑分布式﹑面向对象技术来开发软件。 3、什么是软件危机?产生的原因是什么? 软件危机:是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。主要是指如何开发软件,怎样满足对软件日益增长的需求,如何维护数量不断膨胀的先有软件。 原因:一是软件产品的固有特性(软件的不可预见性、软件的规模大且逻辑较复杂),二是软件专业人员自身的缺陷。 4、什么是软件工程?它的目标和容是什么? 软件工程:是用科学的知识程和技术原理来定义,开发,维护软件的一门学科。 目标:付出较低开发成本;达到要求的功能;取得较好的性能;开发的软件易于移植;只需较低的维护费用;能按时完成开发任务,及时交付使用;开发的软件可靠性高。 容:研究容包括开发技术和开发管理两个方面。开发技术主要研究:软件开发方法,开发过程,开发工具和环境。开发管理主要研究:软件管理学,软件经济学,软件心。 5、软件工程面临的问题是什么? ①软件重用性差 ②软件可维护性差 ③开发出的软件不能满足用户需要 6、什么是软件生命周期?它有哪几个活动? 软件生命周期:一个软件从提出开发要求开始直到该软件报废为止的整个时期。 活动:可行性分析和项目开发计划,需求分析,概要设计,详细设计,编码,测试,维护。

软件开发模型介绍与对比分析

常用的软件开发模型 任务的结构框 架。软件开发包括需求、设 段。 软件开发 模型能清晰、直观地表达软 计、编码和测试等阶段,有 时也包括维护阶 件开发全过程,明确规定了 要完成的主要活 动和任务,用来作为软 件项目工作的基础。对于不同的软件 系统,可以采用不同的开 理方法和手段 等,以及允许采用不同的软件工 具和不同的软件工程环境。 1. 瀑布模型 -最早出现的软件开发模型 1970 年温斯顿 ?罗伊斯( Winston Royce )提出了著名的 “瀑布模型 ”,直到 80 年 代早期,它一 直是唯一被广泛采用的软件开发 模型。 瀑布模型 核心思想是按工序将问题化简 ,将功能的实现与设计分开 ,便于分工协 作,即采 用结构化的分析与设计方法将逻 辑实现与物理实现分开。将 软件生命周期划 分为制定计划 、需求分析、软件设计、程序编写、软件测试和运行维 护等六个基本活 动,并 且规定了它们自上而下 、相互衔接的固定次序 ,如同瀑布流水,逐级 下落。从 本质来讲,它是一个软 件开发架构,开发过程是通过一系列 阶段顺序展开的,从系统 需求分析开始 直到产品发布和维护,每个阶段都会产 生循环反馈,因此,如果有信息 未被覆盖或者 发现了问题, 那么 最好 “返回 ”上一个 阶段并进行适当的修改 ,开发进程 从一个阶段 “流动 ”到下一个阶段, 这也是瀑布开发名称的由来。 瀑布模型是最 早出现的软件开发模型,在软件工程中占有重要的地位 ,它提供了 软件开发的基 本框架。其过程是从上一项 活动接收该项活动的工作对象作 为输入,利 用这一输入实 施该项活动应完成的内容给出该 项活动的工作成果, 并 作为输出传给下 一项活动。同 时评审该项活动的实施,若确认 ,则继续下一项活动;否则返 回前面, 甚至更前面的 活动。对于经常变化的项目而 言,瀑布模型毫无价值。(采用瀑布模型 的软件过程如 图所示) 软件 开发模型 (Software Development Model) 是指软件开发 全部过程、活动和 发方法、使用不同的程序设计语言以及各 种不同技能的人员参与工作 、运用不同的管

常见的软件开发模型

常见的软件开发模型 软件开发模型是软件开发全部过程、活动和任务的结构框架。 1.软件开发模型是对软件过程的建模,即用一定的流程将各个环节连接起来,并可用规范的方式操作全过程,好比工厂的流水线。 2.软件开发模型能清晰、直观地表达软件开发全部过程,明确规定要完成的主要活动和任务,它用来作为软件项目工作的基础。 3.软件开发模型应该是稳定和普遍适用的 软件开发模型的选择应根据: 1.项目和应用的特点 2.采用的方法和工具 3.需要控制和交付的特点 软件工程之软件开发模型类型 1.边做边改模型 2.瀑布模型 3.快速原型模型 4.增量模型 5.螺旋模型 6.喷泉模型 边做边改模型(Build-and-Fix Model) 国内许多软件公司都是使用"边做边改"模型来开发的。在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改. 在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户满意为止。 这是一种类似作坊的开发方式,对编写几百行的小程序来说还不错,但这种方法对任何规模的开发来说都是不能令人满意的,其主要问题在于:(1)缺少规划和设计环节,软件的结构随着不断的修改越来越糟,导致无法继续修改; (2)忽略需求环节,给软件开发带来很大的风险; (3)没有考虑测试和程序的可维护性,也没有任何文档,软件的维护十分困难。

瀑布模型(Waterfall Model) 1970年Winston Royce提出了著名的"瀑布模型",直到80年代早期,它一直是唯一被广泛采用的软件开发模型。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。 在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。 瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于: (1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量; (2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险; (3)早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。 我们应该认识到,"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时,总是千方百计地将其分解或转化为一系列简单的线性问题,然后逐个解决。一个软件系统的整体可能是复杂的,而单个子程序总是简单的,可以用线性的方式来实现,否则干活就太累了。线性是一种简洁,简洁就是美。当我们领会了线性的精神,就不要再呆板地套用线性模型的外表,而应该用活它。例如增量模型实质就是分段的线性模型,螺旋模型则是接连的弯曲了的线性模型,在其它模型中也能够找到线性模型的影子. 快速原型模型(Rapid Prototype Model) 快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。 显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。 快速原型的关键在于尽可能快速地建造出软件原型,一旦确定了客户的真正需求,所建造的原型将被丢弃。因此,原型系统的内部结构并不重要,重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求。 增量模型(Incremental Model) 又称演化模型。与建造大厦相同,软件也是一步一步建造起来的。在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各

几种常见软件开发方法的研究与比较

几种常见软件开发方法的研究与比较 摘要:本文介绍四种常见软件开发方法的过程、特点、优缺点及如何对软件开发方法进行评价与选择。 关键词:软件软件开发 1 引言 在软件开发的过程中,软件开发方法是关系到软件开发成败的重要因素。软件开发方法就是软件开发所遵循的办法和步骤,以保证所得到的运行系统和支持的文档满足质量要求。在软件开发实践中,有很多方法可供软件开发人员选择。 2 常见的软件开发方法 2.1 结构化开发方法 结构指系统内各组成要素之间的相互联系、相互作用的框架。结构化开发方法强调系统结构的合理性以及所开发的软件的结构的合理性,主要是面向数据流的,因此也被称为面向功能的软件开发方法或面向数据流的软件开发方法。结构化技术包括结构化分析、结构化设计和结构化程序设计三方面内容。 2.1.1 结构化分析的步骤 结构化分析是一种模型的确立活动,就是使用独有的符号,来确立描绘信息(数据和控制)流和内容的模型,划分系统的功能和行为,以及其他为确立模型不可缺少的描述。其基本步骤是:(1)构造数据流模型:根据用户当前需求,在创建实体—关系图的基础上,依据数据流图构造数据流模型。(2)构建控制流模型:一些应用系统除了要求用数据流建模外,通过构造控制流图(CFD),构建控制流模型。(3)生成数据字典:对所有数据元素的输入、输出、存储结构,甚至是中间计算结果进行有组织的列表。目前一般采用CASE的“结构化分析和设计工具”来完成。(4)生成可选方案,建立需求规约:确定各种方案的成本和风险等级,据此对各种方案进行分析,然后从中选择一种方案,建立完整的需求规约。 2.1.2 结构化设计步骤 结构化设计是采用最佳的可能方法设计系统的各个组成部分以及各成分之间的内部联系的技术,目的在于提出满足系统需求的最佳软件的结构,完成软件层次图或软件结构图。其基本步骤如下:

常见的软件质量模型

常见的软件质量模型 关于软件质量模型,业界已经有很多成熟的模型定义,比较常见的质量模型有McCall 模型、Boehm 模型、FURPS 模型、Dromey 模型和 ISO9126 模型。 ?Jim McCall 软件质量模型(1977 年) ?Barry W. Boehm 软件质量模型(1978 年) ?FURPS/FURPS+ 软件质量模型 ?R. Geoff Dromey 软件质量模型 ?ISO/IEC 9126 软件质量模型(1993 年) ?ISO/IEC 25010 软件质量模型(2011 年) Jim McCall 软件质量模型(1977 年) Jim McCall 的软件质量模型,也被称为 GE 模型(General Electrics Model)。其最初起源于美国空军,主要面向的是系统开发人员和系统开发过程。McCall 试图通过一系列的软件质量属性指标来弥补开发人员与最终用户之间的沟壑。 McCall 质量模型使用 3 中视角来定义和识别软件产品的质量: 1.Product revision (ability to change). 2.Product transition (adaptability to new environments). 3.Product operations (basic operational characteristics).

McCall 模型通过层级的要素、标准和指标来详述这 3 个视角定义(产品修改、产品转移、产品运行)。 ?11 Factors (To specify):描述软件的外部视角,也就是客户或使用者的视角。 ?23 Criterias (To build):描述软件的内部视角,也就是开发人员的视角。 ?Metrics (To control):定义衡量指标和方法 下图中,左侧为 11 个质量要素,右侧为 23 个质量标准。

常用软件开发模型比较分析

常用软件开发模型比较分析 2007-09-26 20:21 正如任何事物一样,软件也有其孕育、诞生、成长、成熟和衰亡的生存过程,一般称其为“软件生命周期”。软件生命周期一般分为6个阶段,即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的,而应该是带有反馈的迭代过程。在软件工程中,这个复杂的过程用软件开发模型来描述和表示。 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架,它给出了软件开发活动各阶段之间的关系。目前,常见的软件开发模型大致可分为如下3种类型。 ① 以软件需求完全确定为前提的瀑布模型(Waterfall Model)。 ② 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型,如螺旋模型(Spiral Model)。 ③ 以形式化开发方法为基础的变换模型(T ransformational Model)。 本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。 1.2.1 瀑布模型瀑布模型即生存周期模型,其核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段,规定了它们自上而下、相互衔接的固定次序,如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。

图1-3 采用瀑布模型的软件过程 瀑布模型是最早出现的软件开发模型,在软件工程中占有重要的地位,它提供了软件开发的基本框架。瀑布模型的本质是一次通过,即每个活动只执行一次,最后得到软件产品,也称为“线性顺序模型”或者“传统生命周期”。其过程是从上一项活动接收该项活动的工作对象作为输入,利用这一输入实施该项活动应完成的内容给出该项活动的工作成果,并作为输出传给下一项活动。同时评审该项活动的实施,若确认,则继续下一项活动;否则返回前面,甚至更前面的活动。瀑布模型有利于大型软件开发过程中人员的组织及管理,有利于软件开发方法和工具的研究与使用,从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明,上述各项活动之间并非完全是自上而下且呈线性图式的,因此瀑布模型存在严重的缺陷。 ① 由于开发模型呈线性,所以当开发成果尚未经过测试时,用户无法看到软件的效果。这样软件与用户见面的时间间隔较长,也增加了一定的风险。 ② 在软件开发前期末发现的错误传到后面的开发活动中时,可能会扩散,进而可能会造成整个软件项目开发失败。 ③ 在软件需求分析阶段,完全确定用户的所有需求是比较困难的,甚至可以说是不太可能的。 1.2.2 螺旋模型螺旋模型将瀑布和演化模型(Evolution Model)结合起来,它不仅体现了两个模型的优点,而且还强调了其他模型均忽略了的风险分析。这

软件开发模式及优缺点

软件开发模式有哪些? 快速原型模型:(需要迅速造一个可以运行的软件原型,以便理解和澄清问题) 快速原型模型允许在需求分析阶段对软件的需求进行初步的非完全的分析和定义,快速设计开发出软件系统的原型(展示待开发软件的全部或部分功能和性能(过程:用户对该原型进行测试评定,给出具体改善的意见以及丰富的细化软件需求,开发人员进行修改完善) 优点: 克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险 缺点: 、所选用的开发技术和工具不一定符合主流的发展 、快速建立起来的系统加上连续的修改可能会造成产品质量底下 增量模型:(采用随着日程时间的进展而交错的线性序列,每一个线性徐磊产生软件的一个可发布的“增量”,第一个增量往往就是核心的产品) 与其他模型共同之处:它与原型实现模型和其他演化方法一样,本质都是迭代 与原型实现模型不同之处:它强调每一个增量均发布一个可操作产品,(它不需要等到所有需求都出来,只要摸个需求的增量包出来即可进行开发) 优点: 、人员分配灵活,一开始不需要投入大量人力资源 、当配备人员不能在限定的时间内完成产品时,它可以提供一种先推出核心产品的途径,可现发布部分功能给用户(对用户起镇静作用) 、增量能够有计划的管理技术风险 缺点: 、如果增量包之间存在相交的情况且未很好处理,则必须做全盘系统分析 注: 这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程原型模型:(样品模型,采用逐步求精的方法完善原型)

主要思想: 先借用已有系统作为原型模型,通过“样品”不断改进,使得最后的产品就是用户所需要的。原型模型通过向用户提供原型获取用户的反馈,使开发出的软件能够真正反映用户的需求, 采用方法: 原型模型采用逐步求精的方法完善原型,使得原型能够“快速”开发,避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应 优点: ()开发人员和用户在“原型”上达成一致。这样一来,可以减少设计中的错误和开发中的风险,也减少了对用户培训的时间,而提高了系统的实用、正确性以及用户的满意程度。 ()缩短了开发周期,加快了工程进度。 ()降低成本。 缺点: 、当重新生产该产品时,难以让用户接收,给工程继续开展带来不利因素。 、不宜利用原型系统作为最终产品。采用原型模型开发系统,用户和开发者必须达成一致: 喷泉模型:(以用户需求为动力,以对象为驱动的模型,主要用于采用对象技术的软件开发项目) 它认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性 相互迭代:软件的摸个部分常常被重复工作多次,相关对象在每次迭代中随之加入渐进的软件成分 无间隙:它在各项活动之间没有明显边界(如分析和设计活动之间<由于对象概念的应用,表达分析,设计,实现等活动只用对象类和关系>) 优点: 、可以提高软件项目开发效率,节省开发时间,适应于面向对象的软件开发过程 不便之处:

软件过程模型的优缺点和适用范围

软件过程模型 1、4种模型的对比 瀑布模型: 优点:文档驱动 缺点:阶段划分固定,大量文档;开发成果最后出增加风险;不适应用户的变化适用范围:需求准确无重大变化的软件项目开发 快速原型模型: 优点:关注了客户的需求,降低了开发风险 缺点:可能导致系统设计差,难维护;不宜用原型产生最终产品,最终产品还是要考虑质 量和可维护性 适用范围:需求复杂,难以确定、动态变化的系统 增量模型: 优点:分批提交产品;减少新软件对用户的冲击;可维护性增加,需求变更只需要更改构 件 缺点:构件逐渐加入,不能破坏已经构造的系统,要求软件具备开放式结构;需 求变化时,适应性大于瀑布和快速原型,但容易退化为边做边盖,失去整体控制性;有无法集成的风险; 适用范围:风险较大用户需求较稳得大型软件系统 螺旋模型: 优点:1)设计上的灵活性,可以在项目的各个阶段进行变更。 2)以小的分段来构建大型系统,使成本计算变得简单容易。 3)客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。 4)随着项目推进,客户始终掌握项目的最新信息,从而他或她能够和管理层有效地交互。 5)客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。 缺点:建设周期长,和当前技术水平差距大,无法满足需求; 适用范围:庞大复杂并具有高风险的系统,特别适合内部开发的大规模软件项目 2、喷泉模型 特点:无明显边界、阶段内迭代 优点:各阶段无明显界限,开发人员同步进行,提高项目开发效率缺点: 重叠的项目不利于项目管理,审核难度加大 适用:面向对象的软件过程 3、重用构件模型 4、RUP 通用的过程框架 4个阶段 9个核心工作流 前6个为核心过程,后3个是核心支撑

!软件工程练习题3

一、选择题 1.软件是一种()产品。 A.有形 B.逻辑C.物质 D.消耗 2.与计算机科学的理论研究不同,软件工程是一门() A.理论性B.工程性C.原理性D.心理性 3.软件工程学科出现的主要原因是() A.计算机的发展B.其他工程学科的影响力 C.软件危机的出现D.程序设计方法学的影响 4.软件生存周期模型有多种,下列选项中,()不是软件生存周期的模型。 A.螺旋模型B.增量模型C.功能模型D.瀑布模型 5.软件开发模型是指软件开发的全部过程、活动和任务的结构框架。主要的开发模型有瀑布模型、 演化模型、螺旋模型和喷泉模型。螺旋模型将瀑布模型和演化模型相结合,并增加了[A ],它建立在[B ]的基础上,沿着螺线自内向外每旋转一圈,就得到[B ]的一个版本。喷泉模型描述了[C ]的开发模型,它体现了这种开发方法创建软件的过程所固有的[D ]和 [E ]的特征。 供选择的答案: A:(1)系统工程(2)风险分析(3)设计评审(4)进度控制 B:(1)模块划分(2)子程序分解(3)设计(4)原型 C:(1)面向对象(2)面向数据流(3)面向数据结构(4)面向事件驱动 D:(1)归纳(2)推理(3)迭代(4)递归 E:(1)开发各阶段之间无“间隙”(2)开发各阶段分界明显(3)部分开发阶段分界明显(4)开发过程不分阶段 您的选择是: 【A 】【B 】【C 】【D 】【E 】 6.目前存在若干种软件生存周期模型,例如瀑布模型、增量模型、螺旋模型等。其中规定了由前至 后、相互衔接的固定次序的模型是() A.瀑布模型B.增量模型C.螺旋模型D.喷泉模型 7.软件生命周期包括可行性分析和项目开发计划、需求分析、概要设计、详细设计、编码、()维 护等活动。 A.应用B.测试C.检测D.以上都是 8.准确地解决“软件系统必须做什么”是()阶段的任务。 A.分析阶段B.设计阶段C.编码阶段D.测试阶段 9.研究开发所需要的成本和资源是属于可行性研究中的()研究的一方面。 A.技术可行性 B. 经济可行性 C. 社会可行性 D. 法律可行性 10.需求分析()。【】 A.要回答“软件必须做什么”B.可概括为“理解、分析、表达”六个字 C.要求编写需求规格说明书D.以上都对 11.瀑布模型中软件生命周期划分为八个阶段:问题定义、可行性研究、需求分析、总体设计、详细 设计、编码、测试和运行、维护。这八个阶段又可归纳为三个大的阶段:计划阶段、开发阶段和()阶段。

常见软件开发模型

常见软件开发模型 模型优点缺点 瀑布模型文档驱动系统可能不满足客户的需求 快速原型模型关注满足客户需求可能导致系统设计差、效率低,难于 维护 增量模型开发早期反馈及时,易于维护需要开放式体系结构,可能会设计差、 效率低 螺旋模型风险驱动风险分析人员需要有经验且经过充分 训练 瀑布模型(Waterfall Model ) 1970年Winston Royce 提岀了著名的“瀑布模型“,直到80年代早期,它一直是唯一被广泛采用的软件开发模型。 瀑布模型中,如图所示,将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、

软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如 同瀑布流水,逐级下落。 在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。 瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于: (1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量; (2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,开发的风 从而增加了险; (3)早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。 快速原型模型(Rapid Prototype Model ) 快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么; 第二步则在第一步的基础上开发客户满意的软件产品。 显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。快速 原型的关键在于尽可能快速地建造出软件原型,一旦确定了客户的真 正需求,所建造的原型将被丢弃。因此,原型系统的内部结构并不重要,重要的是必须迅速 建立原型,随之迅速修改原型,以反映客户的需求。

常用软件开发模型

常用软件开发模型比较分析 正如任何事物一样,软件也有其孕育、诞生、成长、成熟和衰亡的生存过程,一般称其为“软件生命周期”。软件生命周期一般分为6个阶段,即制定计划、需求分析、设计、编码、测试、运行和维护。软件开发的各个阶段之间的关系不可能是顺序且线性的,而应该是带有反馈的迭代过程。在软件工程中,这个复杂的过程用软件开发模型来描述和表示。 软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架,它给出了软件开发活动各阶段之间的关系。目前,常见的软件开发模型大致可分为如下3种类型。 ①以软件需求完全确定为前提的瀑布模型(Waterfall Model)。 ②在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型,如螺旋模型(Spiral Model)。 ③以形式化开发方法为基础的变换模型(Transformational Model)。 本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。 1.2.1 瀑布模型 瀑布模型即生存周期模型,其核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段,规定了它们自上而下、相互衔接的固定次序,如同瀑布流水逐级下落。采用瀑布模型的软件过程如图1-3所示。 图1-3 采用瀑布模型的软件过程 瀑布模型是最早出现的软件开发模型,在软件工程中占有重要的地位,它提供了软件开发的基本框架。瀑布模型的本质是一次通过,即每个活动只执行一次,最后得到软件产品,

软件开发过程规范

软件开发过程规范 版本 <1.0> 修订历史纪录

目录 1.前言 (3) 1.1 目的 (3) 1.2 对象 (3) 1.3 要求 (3) 1.4 适用范围 (3) 1.5 软件开发过程模型 (3) 1.6 开发过程划分 (3) 2.技术过程规范部分 (3) 2.1 概述 (3) 2.2 业务建模阶段 (4) 2.3 需求阶段 (5) 2.4 分析设计阶段 (6) 2.5 实现阶段 (7) 3.管理过程规范部分 (7) 3.1 概述 (7) 3.2 接受项目 (8) 3.3 重新评估项目范围和风险(对于较大项目) (8) 3.4 制定开发计划 (8) 3.5 迭代开发管理 (9) 3.6 监控项目的实施 (9) 3.7 结束项目 (10)

软件开发过程规范 1. 前言 1.1 目的 本规范的目的是使整个软件产品开发及项目工程阶段清晰,要求明确,任务具体,便于规范化、系统化及工程化。有利于提高软件生命周期的控制及管理,提高所开发软件的质量,缩短开发时间,减少开发和维护费用,使软件开发活动更科学、更有成效。 1.2 对象 本规范面向产品生命周期的所有相关人员,包括管理人员、开发人员、质管人员。 1.3 要求 具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。 1.4 适用范围 适用于产品开发生命周期中的除产品提交外的其他全部过程;规范分为两部分:技术过程规范和管理过程规范,分别适用于软件开发过程中的技术性活动和管理性活动。 1.5 软件开发过程模型 本规范所采用的软件开发过程模型为简化的RUP开发过程模型;软件开发过程是体系结构为中心,用例驱动和风险驱动相结合的过程迭代。 1.6 开发过程划分 开发过程包括多次迭代,每次迭代的目标和侧重点不同;较早的迭代侧重于业务建模和需求建模;而后的迭代则侧重于分析设计和编码。 2. 技术过程规范部分 2.1 概述 本规范中将软件开发的整个技术过程分为四个顺序实施的阶段,分别为业务建模阶段、需求阶段、分析设计阶段和实现阶段。在对技术过程规范的描述,按阶段内部的活动和产物对四个阶段分别说明。 在本规范中对阶段内活动的说明,是按顺序性活动和持续性活动两类分别进行说明。对于顺序性活动是按该阶段中活动的总体顺序进行的描述,而在实际工作中,从各活动的具体实施的细节来看,各活动之间的顺序是不断交叉变化的。对于持续性活动主要是对贯穿该阶段过程始终的技术活动进行说明。

相关文档
最新文档