软件测试工作与软件开发模型息息相关，在不同的软件开发模型中，测试的任务和作用也不相同，因此测试人员要充分了解软件开发模型，以便找准自己在其中的定位与任务。软件开发模型规定了软件开发应遵循的步骤，是软件开发的导航图，它能够清晰、直观地表达软件开发的全过程，以及每个阶段要进行的活动和要完成的任务。开发人员在选择开发模型时，要根据软件的特点、开发人员的参与方式选择稳定可靠的开发模型自有软件开发以来，软件开发模型也从最初的“边做边改”发展出了多个模型，下面以软件开发模型发展历史为顺序，介绍几个典型的开发模型。

瀑布模型是W.W.罗伊斯(W.W.Royce)于1970年提出的软件开发模型，由模型名称可知该模型遵循从上至下一次性完成整个软件产品的开发方式瀑布模型将软件开发过程分为6个阶段:计划→需求分析→软件设计→编码→测试→运行维护，其开发过程如图1-1所示。

在瀑布模型中，软件开发的各项活动严格按照这条线进行，只有当一个阶段任务完成之后才能开始下一个阶段。软件开发的每一个阶段都要有结果产出，结果经过审核验证之后作为下一个阶段的输入，下个阶段才可以顺利进行。如果结果审核验证不通过，则需要返回修改。

瀑布模型为整个项目划分了清晰的检查点，当一个阶段完成之后，只需要把全部精力放置在后面的开发上即可，它有利于大型软件开发人员的组织管理及工具的使用与研究，可以提高开发的效率。

但是瀑布模型是严格按照线性方式进行的，无法适应用户需求变更，用户只能等到最后才能看到开发成果，增加了开发风险。如果开发人员与客户对需求理解有偏差，到最后开发完成后，最终成果与客户需求可能会差之千里。使用瀑布模型开发软件时，如果早期犯的错误在项目完成后才发现，此时再修改原来的错误需要付出巨大的代价。瀑布模型要求每一个阶段必须有结果产出，这就势必增加了文档的数量，使软件开发的工作量变大。

除此之外，对于现代软件来说，软件开发各阶段之间的关系大部分不会是线性的，很难使用瀑布模型开发软件，因此瀑布模型不再适合现代软件开发，已经被逐渐废弃。

快速原型模型与瀑布模型正好相反，它在最初确定用户需求时快速构造岀一个可以运行的软件原型，这个软件原型向用户展示待开发软件的全部或部分功能和性能，客户对该原型进行审核评价，然后给出更具体的需求意见，这样逐步丰富细化需求，最后开发人员与客户达成最终共识，确定客户的真正需求。确定客户的真正需求之后，开始真正的软件开发。

快速原型模型类似于建造房子，确定客户对房子的需求之后快速地搭建一个房子模型，由客户对房子模型进行评价，房子的样式、功能、布局等是否满足需求，哪里需要改进等，最后确定了客户对房子的要求，就开始真正地建造房子。该模型的开发过程如图1-2所示。

与瀑布模型相比，快速原型模型克服了需求不明确带来的风险，适用于不能预先确定需求的软件项目。但快速原型模型关键在于快速构建软件原型，准确地设计出软件原型存在定的难度。此外，这种开发模型也不利于开发人员对产品进行扩展。

迭代模型又称为增量模型或演化模型，它将一个完整的软件拆分成不同的组件，然后逐个组件地开发测试，每完成一个组件就展现给客户，让客户确认这一部件功能和性能是否达到客户需求，最终确定无误，将组件集成到软件体系结构中。整个开发工作被组织为一系列短期、简单的小项目，称为一系列迭代，每一个迭代都需要经过需求分析→软件设计→编码→测试的过程，其开发过程如图1-3所示。

在迭代模型中，第一个迭代(即第一个组件)往往是软件基本需求的核心部分，第一个组件完成之后，经过客户审核评价形成下一个组件的开发计划，包括对核心产品的修改和新功能的发布，这样重复迭代步骤直到实现最终完善的产品。

迭代模型可以很好地适应客户需求变更，它逐个组件地交付产品，客户可以经常看到产品，如果某个组件没有满足客户需求，则只需要更改这一个组件，降低了软件开发的成本与风险。但是选代模型需要将开发完成的组件集成到软件体系结构中，这样会有集成失败的风险，因此要求软件必须有开放式的体系结构。此外，迭代模型逐个组件地开发修改，很容易退化为“边做边改”的开发形式，从而失去对软件开发过程的整体控制。

螺旋模型由巴利·玻姆(Barry Boehm)于1988年提岀，该模型融合了瀑布模型、快速原型模型，它最大的特点是引入了其他模型所忽略的风险分析，如果项目不能排除重大风险，就停止项目从而减小损失。这种模型比较适合开发复杂的大型软件。

螺旋模型将整个项目开发过程划分为几个不同的阶段，每个阶段按部就班地执行，这种划分方式采用了瀑布模型。每个阶段在开始之前都要进行风险评估，如果能消除重大风险则可以开始该阶段任务。在每个阶段，首先构建软件原型，根据快速原型模型完成这个迭代过程，产出最终完善的产品，然后进入下一个阶段，同样下一个阶段开始之前也要进行风险评估，这样循环往复直到完成所有阶段的任务。螺旋模型的若干个阶段是沿着螺线方式进行的，如图1-4所示。

图1-4有4个象限:制订计划、风险分析、实施工程、客户评估，各象限含义如下。

(1)制订计划:确定软件目标，制订实施方案，并且列出项目开发的限制条件。

(2)风险分析:评价所制订的实施方案，识别风险并消除风险。

(3)实施工程:开发产品并进行验证

(4)客户评估:客户对产品进行审核评估，提出修正建议，制订下一步计划。

在螺旋模型中，每一个选代都需要经过这4个步骤，直到最后得到完善的产品，可以进行提交。

敏捷模型是20世纪90年代兴起的一种软件开发模型。在现代社会,技术发展非常快软件开发也是在快节奏的环境中进行的。在业务快速变换的环境下,往往无法在软件开发之前收集到完整而详尽的软件需求。没有完整的软件需求,传统的软件开发模型就难以展开工作。

为了解决这个问题,人们提出了敏捷开发模型。敏捷模型以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷模型中,软件项目在构建初期被拆分为多个相互联系而又独立运行的子项目,然后迭代完成各个子项目,开发过程中,各个子项目都要经过开发测试。当客户有需求变更时,敏捷模型能够迅速地对某个子项目做出修改以满足客户的需求。在这个过程中,软件一直处于可使用状态。

除了响应需求,敏捷模型还有一个重要的概念——迭代,就是不断对产品进行细微、渐进式的改进,每次改进一小部分,如果可行再逐步扩大改进范围。在敏捷模型中,软件开发不再是线性的,开发的同时也会进行测试工作,甚至可以提前写好测试代码,因此在敏捷模有“开发未动,测试先行”的说法。

另外,相比于传统的软件开发模型,敏捷模型更注重“人”在软件开发中的作用,项目的各部门应该紧密合作、快速有效地沟通(如面对面沟通),提出需求的客户可以全程参与到开发过程,以适应软件频繁的需求变更。为此,敏捷模型描述了一套软件开发的价值和原则,具体如下所示。

(1)个体和交互重于过程和工具。

(2)可用软件重于完备文档。

(3)客户协作重于合同谈判。

(4)响应变化重于遵循计划。

对于敏捷模型来说,并不是工具、文档等不重要,而是更注重人与人之间的交流沟通。

　　软件开发是根据用户要求建造出软件系统或者系统中的软件部分的过程。那么，你知道软件开发的英语怎么说吗?

　　软件开发的英文释义：

　　软件开发的英文例句：

　　软件测试作为软件开发过程的重要环节,是保证软件质量,提高软件可靠性的重要手段,软件开发技术的发展,也必然会带动软件测试技术的发展。

　　摘要软件复用技术对提高软件开发效率与质量、降低软件开发成本及缩短软件开发周期有着极其重要的作用。

　　，与敏捷软件开发方法一样，强调软件开发过程的自适应性和以人优先的价值观[1]，这与传统的重量级软件开发方法强调对开发过程的控制相反。

　　每一个软件开发人员开发包括Windows，MacOSX开发或移动设备软件开发类型的邀请。

　　克服软件危机、提高软件质量可以从三个方面入手：软件开发方法论、过程管理和软件开发工具。

　　在软件开发的历程中，软件专家尝试了各种方法来改进软件过程，提高软件开发的质量和速度。

　　什么是敏捷软件开发?敏捷软件开发是一个概念意义上的框架,用来取代软件工程项目的概念;它强调在项目的整个生命周期中,拥抱并促进由于软件进化式的发展所带来的变化。

　　采用面向对象分析与设计技术以及统一建模语言开发产品结构管理软件，这一技术的应用减少了软件开发成本以及开发周期，提高了软件质量。

　　软件复杂性度量是软件工程的一个研究领域，它关系到软件开发和维护的开销。另一方面，软件复杂性度量和软件测试技术关系密切。

　　软件工程是指导软件开发和维护的工程学科，它采用工程的概念、原理、技术和方法来开发和维护软件，把正确的管理技术和开发技术结合起来，经济的开发出高质量的软件。

　　不管怎么说，他们在软件开发的诸神殿上都占有一席之地。

　　但是在软件开发方面，它仍然与以前一样全面——如果不是更全面的话。

　　然而，如果您在价值链中拥有一组错误的投资混合，那么您的业务将继续在没有执行软件开发和交付组织的情况下进行。

　　并不是所有的软件开发活动在从一个组织到另一个组织时处于同样的重要程度，这依赖于组织的架构和它的商业因素。

　　没有创造力就没有软件开发。

　　它能够也应该使用在过去十几年间的软件开发和系统工程中所积累的最佳实践。

　　那么我们如何以此方式对我们的软件开发组织塑形呢?

　　在软件开发中我们面对的一个主要问题是复杂度。

　　无论您怎样看它，对于大多数组织来说，实际上是一个软件开发产品的混合。

　　当我们执行过程时，每个过程都会改进，特别是软件开发过程，即使您采用了RUP。

　　当你回过头来评估你的组织中的软件开发工作的全面状况时，你看到了什么?

　　确实，几乎软件开发的每个方面都提供了至少一个框架。

　　接下来你就可以自己确定这些区别如何应用到你自己的软件开发项目里。

　　事实上，如果软件开发是工程学的一个形式，那么应该有一个易于理解的过程，它告诉我们怎样实践规范。

　　在此上下文中，资产不是上面所定义的现有资产，而是任意抽象级别的任何类型的软件开发资产，包括设计模型、模式和代码实现。

　　其次，我将环顾我们的软件开发项目并指出看板应用的例子。

　　有一部分是我工作的公司本身陷入困境，但大部分还是我自己试图在软件开发中找到属于我自己的道路。

　　本文不需要特定的编译器和环境配置，但您必须熟悉软件开发，因为可能需要诊断与设置有关的问题或配置错误。

　　对于一个性能测试，您必须找到一种有效的方法，去为软件开发早期阶段的测试创建大量的数据。

　　因而，这就是一个范围问题：敏捷开发讲究的是软件开发。

针对某一特定地三维设计软件进行的二次开发，也要遵循一定的顺序。首先要让开发出来的插件满足大部分设计人的基本需求，让使用者能比较顺畅地使用三维软件；然后再进行扩展，开发各个专业的建模工具，以满足目前图纸翻模型的需求；之后要开发与三维设计相关的工具，逐渐让使用者脱离二维设计.

由于目前国内工程设计行业使用范围最广的三维设计软件是欧特克公司的Revit，其开发平台也最为完善和易用，因此，将优先基于该软件进行二次开发。

为了让二维设计人员能够更顺利地转换到三维设计环境中，并进行简单的专业协同，开发人员首先要开发一批能满足土建及公用设备等各专业通用的建模工具，比如创建视图类工具、定位工具、可见性控制工具、构件基本操作工具等，用这些工具来弥补Revit软件自身功能的缺失，满足Revit建模的基本需求。在此基础上，再开发各个专业所特有的建模和批量处理工具，比如管线调整、对齐、翻越等，以进一步提高专业的建模效率。

在这个阶段的开发过程中，会有人提出“走捷径”的想法，即通过二次开发来实现将二维图纸转成三维Revit模型的功能。但经过多次论证，这个想法被否定。这主要基于以下两方面考虑：首先，二维图纸中的构成要素是线条，缺乏必要的属性信息，单纯的转换要么技术难度高，要么需要用户补充的信息量过大，实现过程困难；其次，二维图纸翻三维模型的过 程只是一个过渡阶段，最终会是三维设计取代二维设计，那时也就不存在翻模的过程，所以即便现在开发出相关的插件，也不能具备长期可持续有用性。

在满足设计人员使用三维软件进行建模纠错的需求之后，开发工作就要进入下一个阶段，即通过开发一系列的工具来实现完整的三维设计。由于当前绝大多数工程师对于二维设计流程及思维习惯根深蒂固，因此，这个特定阶段开发的三维设计工具需要在延续二维设计思路的前提下，尽量引导设计人员接受三维设计思想，以降低设计人员平台迁移难度。

在这个设计阶段，开发人员要做的主要工作是设计计算工具、材料统计工具、管道汇总工具和标注出图工具的开发。

1）设计计算工具—将各个专业在二维设计软件中常用的计算和设计工具迁移到三维软件中，同时根据三维模型的特有优势来进行必要的改进，能够最明显地提高设计工程师对于三维软件的亲和度，用户上手快，三维设计的推广速度也会加快。

2）材料统计工具—借助已建立的三维模型来统计工程材料用量，能够补充和完善二维设计中材料统计所缺失的功能，提高统计的精确性，这在工程概预算和招投标中都会起到巨大的作用。

3）管道汇总工具—在三维设计中，进行管道汇总和排布支吊架是非常便利的，能够避免二维管汇的频繁比对专业图纸、专业协调不畅、细节照顾不到等诸多问题。基于这样的先天优势，进行管道汇总工具的开发，能够提高管汇质量，降低碰撞干涉概率。

4）标注出图工具—由于国家并未出台具有实际应用意义的的三维出图标准，因此，一段时间内都要面临模型和图纸共存的状态。然而，由于三维模型的表达方式会与二维图纸存在一些差异，要将三维模型转换成施工用的二维图纸，就必须开发必要的标注出图工具，通过对模型进行特定的调节和标注，来尽量符合二维出图标准。

前两个阶段的开发成果，基本上已经能够满足设计人员从二维设计迁移到三维设计平台的需求。在此基础上，开发人员需要做进一步的开发工作，进行各种方向和阶段的拓展，来 进一步发扬BIM的优势。比如进行方案阶段的快速建模，施工阶段的工程管理等。此外，二次开发工作还将介入到与Revit相关联的下游软件，进行功能的增强和补充，比如对Navisworks的检查碰撞和施工模拟工具进行必要的改进，以提高工作效率；对二维Auto CAD进行适当的开发，来更平滑地进行二三维交互。

由于某些工程设计院的机电设备专业还会使用到其他平台的一些软件，比如Inventor、Microstation等，开发人员也可以对其基本功能进行适当的改进，来与Revit和Navisworks等软件进行协作。对此，需要对上述软件进行细致的调研，根据软件用户群体的数量和重要性，安排软件二次开发的优先顺序。

工程设计院的设计人员在三维设计上顺利开展的同时， 不可避免地需要一个专门针对三维项目的集成管理平台，来统一协调设计过程和管理设计成果，形成真正意义上全专业的整合。由于三维的协作过程与二维设计协同过程差异很大， 因此，这个平台不能继续沿用传统的二维协同平台，而只能自行开发。通过协同平台，开发人员根据工程设计院特有的设计风格和工作流程进行定制，帮助其改善专业提资流程，实现专业间模型和数据的交互，管理项目进度和成果，延长设计成果生命期等。在此基础上，开发人员还可将自身多年来开发出来的工具进行整合，比如建立专有的服务器存放模型，开发模型的网页浏览功能，给模型轻量化，在较差的现场施工网络环境下能够轻易地浏览模型，来进行现场的施工和管理等。

转载请注明来源本文地址：