外文翻译 软件过程模型Word下载.docx

外文翻译 软件过程模型Word下载.docx

《外文翻译 软件过程模型Word下载.docx》由会员分享，可在线阅读，更多相关《外文翻译 软件过程模型Word下载.docx（16页珍藏版）》请在冰点文库上搜索。

摘要

软件系统从起初的开发，维护，再到一个版本升级到另一个版本，经历了一系列阶段.这篇文章归纳和整理了一些描述如何开发软件系统的方法.从传统的软件生命周期的背景和定义出发，即大多数教科书所讨论的，并且目前的软件开发实践所遵循的软件生命周期，接着讨论作为目前软件工程技术基石的更全面的软件开发模型.

1前言

软件业的发展最早可追溯到开发大型软件项目的显式模型，那是在二十世纪五十年代和六十年代间.总体而言，这些早期的软件生命周期模型的唯一目的就是提供一个合理的概念计划来管理软件系统的开发.因此，这种计划可以作为一个基础规划，组织，人员配备，协调，预算编制，并指导软件开发活动.

自20世纪60年代，出现了许多经典的软件生命周期的描述（例如，霍西尔1961年，劳斯莱斯1970年，1976年博伊姆，迪斯塔索1980年，1984年斯卡基，萨默维尔1999年）.罗伊斯（1970）使用现在生活中熟悉的“瀑布”图表，提出了周期的概念，这个图表概括了开发大型软件系统是多么的困难，因为它涉及复杂的工程任务，而这些任务在完成之前可能需要不断地返工.这些图表也通常在介绍性发言中被采用，主要针对开发大型软件系统的人们（例如，定制软件的客户），他们可能不熟悉各种各样的技术问题但还是要必须解决这些问题.

这些经典的软件生命周期模型通常包括以下活动一些内容：

系统启动/规划：

系统从何而来？

在大多数情况下，不论是现有的信息处理机制以前是自动的，手工的，还是非正式的，新系统都会取代或补充它们.

●需求分析和说明书：

阐述一个新的软件系统将要开发的问题：

其业务能力，其所达到的性能特点，支持系统运行和维护所需的条件.

●功能或原型说明：

潜在确定计算的对象，它们的属性和关系，改变这些对象的操作，约束系统行为的限制等.

●划分与选择：

给出需求和功能说明书，将系统分为可管理的模块，它们是逻辑子系统的标志，然后确定是否有对应于这些模块的新的，现有的，或可重复使用的软件系统可以复用.

●设计及配置说明书：

以适合模块的详细设计和整体配置管理的方式定义各子系统之间的内部关系和接口.

●模块设计的详细规格说明：

定义数据流在各组件之间传递的算法.

●模块实现和调试：

将前面的规格说明的内容通过代码实现并验证他们的基本操作是否正确.

●软件集成与测试：

确认并维持软件系统结构配置的整体完整性.通过配置软件系统架构的一致性和验证完整的实施模块，核实规格说明书中模块的接口和内部关系，并验证系统及其子系统的性能是否他们的要求匹配.

●文档修订和配送系统：

将已经写好的系统开发说明书进行包装并合理的转化为系统文档和用户指南，所有的文档都是以一种适于普及和系统支持的格式.

●部署和安装：

提供安装已发布软件到本地计算机环境的指南，配置操作系统的参数和用户的访问权限，并运行诊断测试，以保证系统的基本操作的正常运作.

●培训和使用：

提供教学器材及系统用户指南，方便用户了解系统的性能和限定，以便有效地使用该系统.

●软件维护：

通过提供功能改进，维修，性能提高及更新使得在其主机系统环境下维持有用的操作.

1.1什么是软件生命周期模型?

软件生命周期模型是关于软件是如何或应该是怎样开发的描述性或说明性的描述.描述性模型阐述了一个特定的软件系统开发的过程.描述性模型可作为理解和改进软件开发过程的基础，或者作为开发系统的经典规范模型（柯蒂斯，杰瑞，Iscoe，1988年）.这个模型描述了软件应该如何开发.它作为准则或框架来组织和策划软件开发应如何执行，以及以什么顺序.通常情况下，阐述软件系统应该如何开发的规范性的生命周期模型，是比较容易和明确的.这是因为这种模式是直观的并能够很好的推导出来.这意味着，在实践中，许多描述中提到的软件开发的细节是可以忽略不计的，或可以拖延的.当然，在不同的开发环境，使用不同的编程语言，由不同水平的开发人员，开发不同类型的应用系统时，应该相对的提高开发的有效性和健壮性.当然，在软件开发的过程中，规范性的模型运用一些给定的软件工程工具或环境后，也被用来包装发任务和技术.

另一方面，描述性的生命周期模型描述了在特定的环境下，软件系统实际中是如何开发的.因此，它们不太常见，更难以阐明，一个明显的原因：

一个人必须观察并收集整个软件系统生命周期的数据，而这往往以年来衡量.此外，描述性模型针对具体观察的系统，在进行系统的比较分析后得出来的.因此，这意味着规范的软件生命周期模型占据着主导地位，直到大量的观测数据提供足够的资料，并阐明更好的生命周期模型.

这两种描述表明，阐述软件生命周期模型有一系列的目的.这些描述可以作为：

●在安排时间，空间和计算环境上指引协调，计划，配备人员，安排并管理软件项目工作.

● 

规范指出产生什么样的文件交付给客户.

确定哪些软件工程工具和方法将是最适合支持不同的生命周期活动的.

分析并估计在软件生命周期中的资源分配和开支的框架（博伊姆1981）

●进行实证研究的基础，用以确定影响软件生产率、成本以及整体质量的因素.

1.2什么是软件过程模型?

相对于软件生命周期模型，软件过程模型往往代表一个网络化的序列活动、对象、转换和事件，体现能够实现软件发展的策略的事件.这种模型可以用来制定更精确、更规范化的关于软件生命周期活动的描述.它们的强大源于充分利用了丰富的符号，语法和语义，而这些往往是适合于计算处理的.

软件过程网络可以被看作是代表多个相互关联的任务链（克林1982年，加尔格1989年）.任务链代表了非线性序列的活动，这些活动能够建造并改造现有的计算对象（资源），将其转化成为中间或最终产品.非线性意味着活动的顺序是不确定的，反复的，可以容纳多个/平行的替代品，以及部分被用来循序渐进地推进.反过来，任务活动可以被视为非线性的简单活动序列，这些简单活动是计算处理的最小单元，比如用户使用鼠标或键盘进行命令或者菜单的一次选择.

维诺格拉特和其他人将人与计算机之间的这种协同工作的单位，称作是“结构化论述的工作”（维诺格拉特电脑1986年），而任务链，以“工作流程”（Bolcer1998年）的名称变得大众化.

任务链可以用来描述任何规范或描述动作序列.指令性任务链是理想的计划，计划应该完成什么样的活动，以及以什么顺序.例如，对于面向对象的软件设计任务链活动可能包括下面的任务行动：

●开发系统的一个非正式的规范.

●确定对象和它们的属性.

●确定行动的对象.

●确定对象之间，属性或操作的接口.

●实施行动.

显然，在增量模型逐步走向面向对象软件设计的过程中，这种行动可能带来多次迭代序列和非序列化的简单活动.

任务链的结合或分割成其他任务链导致整体的生产网络或网络的产生（克林1982年）.这种生产网络代表“组织生产系统”，它能将原始的计算，认知，和其他组织的资源转化成综合的和可使用的软件系统.因此，这种开发结构阐释了如何开发，使用和维护软件系统.但是，指令性任务链及其活动不能保证预期所有可能的情况会出现在软件开发过程中（Bendifallah1989年，Mi1990）.因此，任何软件制作的网页只是以某种方式描述一个近似的或不完整软件开发过程.

衔接工作是额外的任务，当计划的任务链不足或破裂时才会执行.它是一个开放的工作，在非衔接任务链上存储进度，否则会将工作流转移到其他一些生产性的工作任务链.因此，描述任务链是用来描述当人们试图按照计划任务执行时，出现的意外情况.衔接任务在软件发展方面的工作包括采取人们的行动，就是凡涉及他们的住所，或一个软件系统的异常行为，或与可以影响系统改变的人的协商.这种衔接工作的概念也被称为软件处理的推动力.

2传统软件生命周期模型

传统的软件演化模型对于我们来说已经很熟悉，因为早期的软件开发就应用了这些.经典的软件生命周期（或“瀑布图”）一同逐步求精的模型在当前现代编程方法和软件工程中被广泛采用.增量释放模型和工业实践密切相关.基于模型的规范标准将经典的生命周期模型具体化到为政府的承建商的软件开发.这四种模式分别使用粗粒度或宏观特征来描述软件的开发.软件开发的渐进过程经常被描述为需求分析，设计，实施，这些通常很少或没有进一步的表征每一阶段都应具备.此外，这些模型是独立于任何组织的开发环境、编程语言的选择、软件应用领域等.传统的模型是上下文无关的，而不是和上下文都有联系的.但由于这些生命周期的所有模型在使用了一段时间，我们统称他们为传统的模式，刻画每个转折.

2.1经典的软件生命周期模型

经典的软件生命周期通常表示为一个简单的规范瀑布软件阶段模型，即从一个阶段有序的过渡到下一个阶段.这种模式类似于描述软件开发的有穷状态机.但是，这些模型对于在复杂的组织环境下架构，分配人员和管理大型的软件开发项目中已经也许是最有用的了，这就是它的主要目的所在.

另外，这些经典模型已被广泛用来描述如何开发小型或者大型的软件项目.

2.2逐步细化

在这种方法中，软件系统的开发是通过逐步完善和由高层次的系统规格说明书升级到源代码组件实现的.不过，至于选择那一个步骤以及运用哪一种升级办法，这些仍然没有言明.相反，在越来越多的工程实践中，随着不断地反思和学习并应用这些方法，规范必定会出现.在指导程序员如何组织软件开发工作的过程中，这一模式已被广泛有效深入的应用.经典的软件生命周期的许多说法也在他们的设计和实现过程中得到阐释.

2.3替代传统的软件生命周期模型

至少有三种可供选择的软件开发模型，这些模型都是传统的软件生命周期模型.它们关注的重点在于产品，开发过程，软件的开发环境.总的来说，这些模型是细粒度，通常计算形式化的要点描述得很详细，往往以实证基础，有时也阐述一些新的能促进软件开发的自动化技术.

3软件产品开发模型

软件产品代表了信息密集化的手工产品，经历了逐步设计并通过反复修改的开发工作才完成的.这一过程可以使用软件产品的生命周期模型来说明.这些产品开发模型代表了基于传统的软件生命周期模型上的渐进式开发模式.由于新的软件开发技术，诸如软件原型语言和环境，可重用的软件，应用类，和文件支持环境的出现，这些模型才产生.这些技术旨在使每一个可执行的软件实施步骤提前完成.因此，这样看来，软件设计模式隐含于技术的实践中，而不是明确的阐述.这是可能的，因为这些模式在那些有经验的开发人员的实践中显得越来越直观.因此，当这些技术应用于工程实践中，才是核查这些模型最合适的时候.

3.1快速原型和联合应用开发

原型是在软件系统开发初期，提供精简功能或有限版本性能的技术（巴尔泽1983年，布德1984年，Hekmatpour1987年）.相对于传统的系统生命周期，原型是一种更着重于软件开发早期阶段（需求分析和功能设计）的策略.反过来，原型在定义、确定以及评估新系统的功能时就要更多的用户参与.因此，这些努力的前期任务，再加上原型技术的运用，都旨在权衡或减少后期的软件设计任务，并简化软件开发工作.

软件原型有多种不同的形式，包括一次性原型，实物原型，示范系统，快速原型，渐进式原型（Hekmatpour1987年）.增加的功能和随后的演化性是区分这些原型形式的所在.

快速原型技术通常以软件功能说明书的形式作为其出发点，而这反过来是模拟，分析，或直接执行.这些技术可以让开发人员能够快速构建软件的早期或原始版本系统，用户就可以评估.用户评价后可以进一步作为反馈，进而改进系统规格说明和设计.此外，根据原型技术，完整的软件开发工作可以通过不断的开发修改/精炼已有的规格说明.这就一向提供了有利的系统工作版本，来重新定义软件设计和测试方案，使得规范说明不断完善并得以执行.另外，其他原型方法最适合发展一次性或演示系统，或者通过复用部分/所有的已有软件系统来构造原型.其次，为什么现代软件开发模式比如螺旋模型和ISO12207预期原型将是一个共同的活动，其有利于捕捉和完善软件需求，以及全面的软件开发，这样看来就变得很清楚了.

外文翻译原文：

Abstract

Softwaresystemscomeandgothroughaseriesofpassagesthataccountfortheirinception,initialdevelopment,productiveoperation,upkeep,andretirementfromonegenerationtoanother.Thisarticlecategorizesandexaminesanumberofmethodsfordescribingormodelinghowsoftwaresystemsaredeveloped.Itbeginswithbackgroundanddefinitionsoftraditionalsoftwarelifecyclemodelsthatdominatemosttextbookdiscussionsandcurrentsoftwaredevelopmentpractices.Thisisfollowedbyamorecomprehensivereviewofthealternativemodelsofsoftwareevolutionthatareofcurrentuseasthebasisfororganizingsoftwareengineeringprojectsandtechnologies.

1Introduction

Explicitmodelsofsoftwareevolutiondatebacktotheearliestprojectsdevelopinglargesoftwaresystemsinthe1950'

sand1960'

s（Hosier1961,Royce1970）.Overall,theapparentpurposeoftheseearlysoftwarelifecyclemodelswastoprovideaconceptualschemeforrationallymanagingthedevelopmentofsoftwaresystems.Suchaschemecouldthereforeserveasabasisforplanning,organizing,staffing,coordinating,budgeting,anddirectingsoftwaredevelopmentactivities.

Sincethe1960'

s,manydescriptionsoftheclassicsoftwarelifecyclehaveappeared（e.g.,Hosier1961,Royce1970,Boehm1976,Distaso1980,Scacchi1984,Somerville1999）.Royce（1970）originatedtheformulationofthesoftwarelifecycleusingthenowfamiliar"

waterfall"

chart,displayedinFigure1.Thechartsummarizesinasingledisplayhowdevelopinglargesoftwaresystemsisdifficultbecauseitinvolvescomplexengineeringtasksthatmayrequireiterationandreworkbeforecompletion.Thesechartsareoftenemployedduringintroductorypresentations,forpeople（e.g.,customersofcustomsoftware）whomaybeunfamiliarwiththevarioustechnicalproblemsandstrategiesthatmustbeaddressedwhenconstructinglargesoftwaresystems（Royce1970）.

Theseclassicsoftwarelifecyclemodelsusuallyincludesomeversionorsubsetofthefollowingactivities:

•SystemInitiation/Planning:

wheredosystemscomefrom?

Inmostsituations,newfeasiblesystemsreplaceorsupplementexistinginformationprocessingmechanismswhethertheywerepreviouslyautomated,manual,orinformal.

•RequirementAnalysisandSpecification:

identifiestheproblemsanewsoftwaresystemissupposetosolve,itsoperationalcapabilities,itsdesiredperformancecharacteristics,andtheresourceinfrastructureneededtosupportsystemoperationandmaintenance.

•FunctionalSpecificationorPrototyping:

identifiesandpotentiallyformalizestheobjectsofcomputation,theirattributesandrelationships,theoperationsthattransformtheseobjects,theconstraintsthatrestrictsystembehavior,andsoforth.

•PartitionandSelection（Buildvs.Buyvs.Reuse）:

givenrequirementsandfunctionalspecifications,dividethesystemintomanageablepiecesthatdenotelogicalsubsystems,thendeterminewhethernew,existing,orreusablesoftwaresystemscorrespondtotheneededpieces.

•ArchitecturalDesignandConfigurationSpecification:

definestheinterconnectionandresourceinterfacesbetweensystemsubsystems,components,andmodulesinwayssuitablefortheirdetaileddesignandoverallconfigurationmanagement.

•DetailedComponentDesignSpecification:

definestheproceduralmethodsthroughwhichthedataresourceswithinthemodulesofacomponentaretransformedfromrequiredinputsintoprovidedoutputs.

•ComponentImplementationandDebugging:

codifiestheprecedingspecificationsintooperationalsourcecodeimplementationsandvalidatestheirbasicoperation.

•SoftwareIntegrationandTesting:

affirmsandsustainstheoverallintegrityofthesoftwaresystemarchitecturalconfigurationthroughverifyingtheconsistencyandcompletenessofimplementedmodules,verifyingtheresourceinterfacesandinterconnectionsagainsttheirspecifications,andvalidatingtheperformanceofthesystemandsubsystemsagainsttheirrequirements.

•DocumentationRevisionandSystemDelivery:

packagingandrationalizingrecordedsystemdevelopmentdescriptionsintosystematicdocumentsanduserguides,allinaformsuitablefordisseminationandsystemsupport.

•DeploymentandInstallation:

providingdirectionsforinstallingthedeliveredsoftwareintothelocalcomputingenvironment,configuringoperatingsystemsparametersanduseraccessprivileges,andrunningdiagnostictestcasestoassuretheviabilityofbasicsystemoperation.

•TrainingandUse:

providingsystemuserswithinstructionalaidsandguidanceforunderstandingthesystem'

scapabilitiesandlimitsinordertoeffectivelyusethesystem.

•SoftwareMaintenance:

sustainingtheusefuloperationofas