软件系统开发中英文对照外文翻译文献

软件系统开发中英文对照外文翻译文献软件系统开发中英文对照外文翻译文献PAGE\*ROMANPAGE\*ROMANII软件系统开发中英文对照外文翻译文献(文档含英文原文和中文翻译)软件工程中的过程处理模型斯卡基沃尔特摘要软件系统从起初的开发，维护，再到一个版本升级到另一个版本，经历了一系列阶段。这篇文章归纳和整理了一些描述如何开发软件系统的方法。从传统的软件生命周期的背景和定义出发，即大多数教科书所讨论的，并且目前的软件开发实践所遵循的软件生命周期，接着讨论作为目前软件工程技术基石的更全面的软件开发模型。关键词：软件生命周期；模型；原型软件系统开发中英文对照外文翻译文献软件系统开发中英文对照外文翻译文献PAGEPAGE1前言软件业的发展最早可追溯到开发大型软件项目的显式模型，那是在二十世纪五十年代和六十年代间。总体而言，这些早期的软件生命周期模型的唯一目的就是提供一个合理的概念计划来管理软件系统的开发。因此，这种计划可以作为一个基础规划，组织，理的概念计划来管理软件系统的开发。因此，这种计划可以作为一个基础规划，组织，202060（例如，霍西尔196119611970，19761980，1984念，这个图表概括了开发大型软件系统是多么的困难，因为它涉及复杂的工程任务，而1999。罗伊斯使用现在生活中熟悉的“瀑布”图表，提出了周期的概念，这个图表概括了开发大型软件系统是多么的困难，因为它涉及复杂的工程任务，而这些任务在完成之前可能需要不断地返工。这些图表也通常在介绍性发言中被采用，主要针对开发大型软件系统的人们（例如，定制软件的客户），他们可能不熟悉各种各样的技术问题但还是要必须解决这些问题。的技术问题但还是要必须解决这些问题。这些经典的软件生命周期模型通常包括以下活动一些内容：这些经典的软件生命周期模型通常包括以下活动一些内容：系统启动/规划：系统从何而来？在大多数情况下，不论是现有的信息处理机制以前是自动的，手工的，还是非正式的，新系统都会取代或补充它们。需求分析和说明书：阐述一个新的软件系统将要开发的问题：其业务能力，其所达到的性能特点，支持系统运行和维护所需的条件。操作，约束系统行为的限制等。功能或原型说明：潜在确定计算的对象，它们的属性和关系，改变这些对象的操作，约束系统行为的限制等。划分与选择：给出需求和功能说明书，将系统分为可管理的模块，它们是逻辑子系统的标志，然后确定是否有对应于这些模块的新的，现有的，或可重复使用的软件子系统的标志，然后确定是否有对应于这些模块的新的，现有的，或可重复使用的软件系统可以复用。系统可以复用。统之间的内部关系和接口。设计及配置说明书：以适合模块的详细设计和整体配置管理的方式定义各子系●统之间的内部关系和接口。设计及配置说明书：以适合模块的详细设计和整体配置管理的方式定义各子系●模块设计的详细规格说明：定义数据流在各组件之间传递的算法。模块实现和调试：将前面的规格说明的内容通过代码实现并验证他们的基本操●模块设计的详细规格说明：定义数据流在各组件之间传递的算法。模块实现和调试：将前面的规格说明的内容通过代码实现并验证他们的基本操作是否正确。作是否正确。软件集成与测试：确认并维持软件系统结构配置的整体完整性。通过配置软件并验证系统及其子系统的性能是否他们的要求匹配。系统文档和用户指南，所有的文档都是以一种适于普及和系统支持的格式。文档修订和配送系统：将已经写好的系统开发说明书进行包装并合理的转化为系统文档和用户指南，所有的文档都是以一种适于普及和系统支持的格式。部署和安装：提供安装已发布软件到本地计算机环境的指南，配置操作系统的参数和用户的访问权限，并运行诊断测试，以保证系统的基本操作的正常运作。以便有效地使用该系统。软件维护：通过提供功能改进，维修，性能提高及更新使得在其主机系统环境以便有效地使用该系统。软件维护：通过提供功能改进，维修，性能提高及更新使得在其主机系统环境●下维持有用的操作。下维持有用的操作。软件生命周期模型是关于软件是如何或应该是怎样开发的描述性或说明性的描述。软件生命周期模型是关于软件是如何或应该是怎样开发的描述性或说明性的描述。（着，在实践中，许多描述中提到的软件开发的细节是可以忽略不计的，或可以拖延的。着，在实践中，许多描述中提到的软件开发的细节是可以忽略不计的，或可以拖延的。当然，在不同的开发环境，使用不同的编程语言，由不同水平的开发人员，开发不同类规范性的模型运用一些给定的软件工程工具或环境后，也被用来包装发任务和技术。这两种描述表明，阐述软件生命周期模型有一系列的目的。这些描述可以作为：项目工作。规范指出产生什么样的文件交付给客户。确定哪些软件工程工具和方法将是最适合支持不同的生命周期活动的。分析并估计在软件生命周期中的资源分配和开支的框架（博伊姆1981）进行实证研究的基础，用以确定影响软件生产率、成本以及整体质量的因素。相对于软件生命周期模型，软件过程模型往往代表一个网络化的序列活动、对象、相对于软件生命周期模型，软件过程模型往往代表一个网络化的序列活动、对象、转换和事件，体现能够实现软件发展的策略的事件。这种模型可以用来制定更精确、更转换和事件，体现能够实现软件发展的策略的事件。这种模型可以用来制定更精确、更规范化的关于软件生命周期活动的描述。它们的强大源于充分利用了丰富的符号，语法和语义，而这些往往是适合于计算处理的。（1982年。任务链代表了非线性序列的活动，这些活动能够建造并改造现有的计算对象（资源源，将其转化成为中间或最终产品。非线性意味着活动的顺序是不确定的，反复的，可以容纳多个/平行的替代品，以及部分被用来循序渐进地推进。反过来，任务活动可以被视为非线性的简单活动序列，这些简单活动是计算处理的最小单元，比如用户使用鼠标或键盘进行命令或者菜单的一次选择。1986，而任务链，以“工作流程”Bolcer1998的名称变得大众化。任务链可以用来描述任何规范或描述动作序列。指令性任务链是理想的计划，计划应该完成什么样的活动，以及以什么顺序。例如，对于面向对象的软件设计任务链活动可能包括下面的任务行动：开发系统的一个非正式的规范。确定对象和它们的属性。●确定对象和它们的属性。确定行动的对象。●确定行动的对象。确定对象之间，属性或操作的接口。●确定对象之间，属性或操作的接口。实施行动。●实施行动。显然，在增量模型逐步走向面向对象软件设计的过程中，这种行动可能带来多次迭显然，在增量模型逐步走向面向对象软件设计的过程中，这种行动可能带来多次迭代序列和非序列化的简单活动。代序列和非序列化的简单活动。任务链的结合或分割成其他任务链导致整体的生产网络或网络的产生（克林1982源转化成综合的和可使用的软件系统。因此，这种开发结构阐释了如何开发，使用和维年。这种生产网络代表“组织生产系统”，它能将原始的计算，认知，和其他组织的资源转化成综合的和可使用的软件系统。因此，这种开发结构阐释了如何开发，使用和维开发过程中Bendifallah1989Mi1990。因此，任何软件制作的网页只是以某种方式描述一个近似的或不完整软件开发过程。衔接工作是额外的任务，当计划的任务链不足或破裂时才会执行。它是一个开放的工作，在非衔接任务链上存储进度，否则会将工作流转移到其他一些生产性的工作任务链。因此，描述任务链是用来描述当人们试图按照计划任务执行时，出现的意外情况。衔接任务在软件发展方面的工作包括采取人们的行动，就是凡涉及他们的住所，或一个软件系统的异常行为，或与可以影响系统改变的人的协商。这种衔接工作的概念也被称为软件处理的推动力。式描述一个近似的或不完整软件开发过程。传统软件生命周期模型传统的软件演化模型对于我们来说已经很熟悉，因为早期的软件开发就应用了这些。经典的软件生命周期（或“瀑布图”）一同逐步求精的模型在当前现代编程方法和软件工程中被广泛采用。增量释放模型和工业实践密切相关。基于模型的规范标准将经这些通常很少或没有进一步的表征每一阶段都应具备。此外，这些模型是独立于任何组织的开发环境、编程语言的选择、软件应用领域等。传统的模型是上下文无关的，而不是和上下文都有联系的。但由于这些生命周期的所有模型在使用了一段时间，我们统称他们为传统的模式，刻画每个转折。经典的软件生命周期模型有序的过渡到下一个阶段。这种模式类似于描述软件开发的有穷状态机。但是，这些模有用的了，这就是它的主要目的所在。有用的了，这就是它的主要目的所在。另外，这些经典模型已被广泛用来描述如何开发小型或者大型的软件项目。另外，这些经典模型已被广泛用来描述如何开发小型或者大型的软件项目。逐步细化效深入的应用。经典的软件生命周期的许多说法也在他们的设计和实现过程中得到阐释。释。替代传统的软件生命周期模型至少有三种可供选择的软件开发模型，这些模型都是传统的软件生命周期模型。它们关注的重点在于产品，开发过程，软件的开发环境。总的来说，这些模型是细粒度，通常计算形式化的要点描述得很详细，往往以实证基础，有时也阐述一些新的能促进软通常计算形式化的要点描述得很详细，往往以实证基础，有时也阐述一些新的能促进软件开发的自动化技术。件开发的自动化技术。软件产品开发模型作才完成的。这一过程可以使用软件产品的生命周期模型来说明。这些产品开发模型代作才完成的。这一过程可以使用软件产品的生命周期模型来说明。这些产品开发模型代表了基于传统的软件生命周期模型上的渐进式开发模式。由于新的软件开发技术，诸如表了基于传统的软件生命周期模型上的渐进式开发模式。由于新的软件开发技术，诸如软件原型语言和环境，可重用的软件，应用类，和文件支持环境的出现，这些模型才产软件原型语言和环境，可重用的软件，应用类，和文件支持环境的出现，这些模型才产生。这些技术旨在使每一个可执行的软件实施步骤提前完成。因此，这样看来，软件设生。这些技术旨在使每一个可执行的软件实施步骤提前完成。因此，这样看来，软件设计模式隐含于技术的实践中，而不是明确的阐述。这是可能的，因为这些模式在那些有计模式隐含于技术的实践中，而不是明确的阐述。这是可能的，因为这些模式在那些有经验的开发人员的实践中显得越来越直观。因此，当这些技术应用于工程实践中，才是经验的开发人员的实践中显得越来越直观。因此，当这些技术应用于工程实践中，才是核查这些模型最合适的时候。核查这些模型最合适的时候。3.13.1快速原型和联合应用开发原型是在软件系统开发初期，提供精简功能或有限版本性能的技术（巴尔泽原型是在软件系统开发初期，提供精简功能或有限版本性能的技术（巴尔泽19831984年，Hekmatpour1987年。相对于传统的系统生命周期，原型是一种更着重于软件开发早期阶段（需求分析和功能设计）的策略。反过来，原型在定义、确定着重于软件开发早期阶段（需求分析和功能设计）的策略。反过来，原型在定义、确定以及评估新系统的功能时就要更多的用户参与。因此，这些努力的前期任务，再加上原以及评估新系统的功能时就要更多的用户参与。因此，这些努力的前期任务，再加上原型技术的运用，都旨在权衡或减少后期的软件设计任务，并简化软件开发工作。型技术的运用，都旨在权衡或减少后期的软件设计任务，并简化软件开发工作。软件原型有多种不同的形式，包括一次性原型，实物原型，示范系统，快速原型，渐进软件原型有多种不同的形式，包括一次性原型，实物原型，示范系统，快速原型，渐进（Hekmatpour1987年快速原型技术通常以软件功能说明书的形式作为其出发点，而这反过来是模拟，分快速原型技术通常以软件功能说明书的形式作为其出发点，而这反过来是模拟，分析，或直接执行。这些技术可以让开发人员能够快速构建软件的早期或原始版本系统，析，或直接执行。这些技术可以让开发人员能够快速构建软件的早期或原始版本系统，用户就可以评估。用户评价后可以进一步作为反馈，进而改进系统规格说明和设计。此用户就可以评估。用户评价后可以进一步作为反馈，进而改进系统规格说明和设计。此/精炼已有的规格说明。这就一向提供了有利的系统工作版本，来重新定义软件设计和测试方案，使得规范说明这就一向提供了有利的系统工作版本，来重新定义软件设计和测试方案，使得规范说明不断完善并得以执行。另外，其他原型方法最适合发展一次性或演示系统，或者通过复不断完善并得以执行。另外，其他原型方法最适合发展一次性或演示系统，或者通过复用部分用部分/ISO12207预期原型将是一个共同的活动，其有利于捕捉和完善软件需求，以及全面的软件开发，这样看来就变得很清楚了。的软件开发，这样看来就变得很清楚了。参考文献 Scacchi,W.,UnderstandingSoftwareProcessRedesignusingModeling,AnalysisSimulation.SoftwareProcess--ImprovementandPractice5(2/3):183-195,2000. Raffo,D.andW.Scacchi,SpecialIssueonSoftwareProcessSimulationandModeling,SoftwareProcess--ImprovementandPractice,5(2-3),87-209,2000. MacCormack,A.,Product-DevelopmentPracticesthatWork:HowInternetCompaniesBuildSoftware,SloanManagementReview,75-84,Winter2001.Beck,K.ExtremeProgrammingExplain,Addison-Wesley,PaloAlto,CA,1999.Chatters,B.W.,M.M.Lehman,J.F.Ramil,andP.Werwick,ModelingaSoftwareEvolutionProcess:ALong-TermCaseStudy,SoftwareProcess-ImprovementPractice,5(2-3),91-102,2000.Noll,J.andW.Scacchi,SpecifyingProcess-OrientedHypertextforOrganizationalComputing,J.NetworkandComputerApplications,24(1):39-61,2001.软件系统开发中英文对照外文翻译文献软件系统开发中英文对照外文翻译文献PAGEPAGE10ProcessModelsinSoftwareEngineeringAbstract:Softwaresystemscomeandgothroughaseriesofpassagesthataccountfortheirinception,initialdevelopment,productiveoperation,upkeep,andretirementfromonegenerationanother.Thisarticlecategorizesandexaminesanumberofmethodsfordescribingormodelinghowsoftwaresystemsaredeveloped.withbackgroundanddefinitionsoftraditionalsoftwarelifecyclemodelsthatdominatemosttextbookdiscussionsandcurrentsoftwaredevelopmentpractices.Thisisfollowedbyamorecomprehensivereviewofthealternativemodelsofsoftwareevolutionthatareofcurrentuseasthebasisfororganizingsoftwareengineeringprojectsandtechnologies.IntroductionExplicitmodelsofsoftwareevolutiondatebacktotheearliestprojectsdevelopinglargesoftwaresystemsinthe1950'sand1960's(Hosier1961,Royce1970).Overall,theapparentpurposeoftheseearlysoftwarelifecyclemodelswastoprovideaconceptualschemeforrationallymanagingthedevelopmentofsoftwaresystems.Suchaschemecouldthereforeserveasabasisforplanning,organizing,staffing,coordinating,budgeting,anddirectingsoftwaredevelopmentactivities.Sincethe1960's,manydescriptionsoftheclassicsoftwarelifecyclehaveappeared(e.g.,Hosier1961,Royce1970,Boehm1976,Distaso1980,Scacchi1984,SomervilleRoyce(1970)originatedtheformulationofthesoftwarelifecycleusingthenowfamiliar"waterfall"chart,displayedinFigure1.Thechartsummarizesinasingledisplayhowdevelopinglargesoftwaresystemsisdifficultbecauseitinvolvescomplexengineeringtasksthatmayrequireiterationandreworkbeforecompletion.Thesechartsareoftenemployedduringintroductorypresentations,forpeople(e.g.,customersofcustomsoftware)whomaybeunfamiliarwiththevarioustechnicalproblemsandstrategiesthatmustbeaddressedwhenconstructinglargesoftwaresystems(Royce1970).Theseclassicsoftwarelifecyclemodelsusuallyincludesomeversionorsubsetofthefollowingactivities:SystemInitiation/Planning:wheredosystemscomefrom?Inmostsituations,feasiblesystemsreplaceorsupplementexistinginformationprocessingmechanismswhethertheywerepreviouslyautomated,manual,orinformal.RequirementAnalysisandSpecification:identifiestheproblemsanewsoftwaresystemissupposetosolve,itsoperationalcapabilities,itsdesiredperformancecharacteristics,andtheresourceinfrastructureneededtosupportsystemoperationandmaintenance.FunctionalSpecificationorPrototyping:identifiesandpotentiallyformalizestheobjectsofcomputation,theirattributesandrelationships,theoperationsthattransformtheseobjects,theconstraintsthatrestrictsystembehavior,andsoforth.PartitionandSelection(Buildvs.Buyvs.Reuse):givenrequirements andfunctionalspecifications,dividethesystemintomanageablepiecesthatdenotelogicalsubsystems,thendeterminewhethernew,existing,orreusablesoftwaresystemscorrespondtotheneededpieces.ArchitecturalDesignandConfigurationSpecification:definestheinterconnectionandresourceinterfacesbetweensystemsubsystems, components,andmodulesin waysfortheirdetaileddesignandoverallconfigurationmanagement.DetailedComponentDesignSpecification:definestheproceduralmethodsthroughwhichthedataresourceswithinthemodulesofacomponentaretransformedfromrequiredinputsintoprovidedoutputs.ComponentImplementationandDebugging:codifiestheprecedingspecificationsintooperationalsourcecodeimplementationsandvalidatestheirbasicoperation.SoftwareIntegrationandTesting:affirmsandsustainstheoverallintegrityofthesoftwaresystemarchitecturalconfigurationthroughverifyingtheconsistencyandcompletenessofimplementedmodules,verifyingtheresourceinterfacesandinterconnectionsagainsttheirspecifications,andvalidatingtheperformanceofthesystemandsubsystemsagainsttheirrequirements.DocumentationRevisionandSystemDelivery:packagingandrationalizingrecordedsystemdevelopmentdescriptionsintosystematicdocumentsanduserguides,allinasuitablefordisseminationandsystemsupport.DeploymentandInstallation:providingdirectionsforinstallingthedeliveredsoftwareintothelocalcomputingenvironment,configuringoperatingsystemsparametersandaccessprivileges,andrunningdiagnostictestcasestoassuretheviabilityofbasicsystemoperation.TrainingandUse:providingsystemuserswithinstructionalaidsandguidanceforunderstandingthesystem'scapabilitiesandlimitsinordertoeffectivelyusethesystem.SoftwareMaintenance:sustainingtheusefuloperationofasysteminitshost/targetenvironment by providing requested functional enhancements, repairs, improvements,andconversions.Whatisasoftwarelifecyclemodel?Asoftwarelifecyclemodeliseitheradescriptiveorprescriptivecharacterizationofhowsoftwareisorshouldbedeveloped.Adescriptivemodeldescribesthehistoryofhowaparticularsoftwaresystemwasdeveloped.Descriptivemodelsmaybeusedasthebasisforunderstandingandimprovingsoftwaredevelopmentprocesses,orforbuildingempiricallygroundedprescriptivemodels(Curtis,Krasner,Iscoe,1988).Aprescriptivemodelprescribeshowanewsoftwaresystemshouldbedeveloped.Prescriptivemodelsareusedasguidelinesorframeworkstoorganizeandstructurehowsoftwaredevelopmentactivitiesshouldbeperformed,andinwhatorder.Typically,itiseasierandmorecommontoarticulateprescriptivelifecyclemodelforhowsoftwaresystemsshouldbedeveloped.Thisispossiblesincemostsuchmodelsareintuitiveorwellreasoned.Thismeansthatmanyidiosyncraticdetailsthatdescribehowasoftwaresystemsisbuiltinpracticecanbeignored,generalized,ordeferredforlaterconsideration.This,ofcourse,shouldraiseconcernfortherelativevalidityandrobustnessofsuchlifecyclemodelswhendevelopingdifferentkindsofapplicationsystems,indifferentkindsofdevelopmentsettings,usingdifferentprogramminglanguages,withdifferentiallyskilledstaff,etc. However,prescriptivemodelsarealsousedto thedevelopmenttasksandtechniquesforusingagivensetofsoftwareengineeringtoolsorenvironmentduringadevelopmentproject.Descriptivelifecyclemodels,ontheotherhand,characterizehowparticularsoftwaresystemsareactuallydevelopedinspecificsettings.Assuch,theyarelesscommonandmoredifficulttoarticulateforanobviousreason:onemustobserveorcollectdatathroughoutthelifecycleofasoftwaresystem,aperiodofelapsedtimeoftenmeasuredinyears.Also,descriptivemodelsarespecifictothesystemsobservedandonlygeneralizablethroughsystematiccomparativeanalysis.Therefore,thissuggeststheprescriptivesoftwarelifecyclemodelswilldominateattentionuntilasufficientbaseofobservationaldataisavailabletoarticulateempiricallygroundeddescriptivelifecyclemodels.Thesetwocharacterizationssuggestthatthereareavarietyofpurposesforarticulatingsoftwarelifecyclemodels.ThesecharacterizationsserveasaGuidelinetoorganize,plan,staff,budget,scheduleandmanagesoftwareprojectworkoverorganizationaltime,space,andcomputingenvironments.Prescriptiveoutlineforwhatdocumentstoproducefordeliverytoclient.Basisfordeterminingwhatsoftwareengineeringtoolsandmethodologieswillbeappropriatetosupportdifferentlifecycleactivities.Frameworkforanalyzingorestimatingpatternsofresourceallocationandconsumptionduringthesoftwarelifecycle(Boehm1981).Basisforconductingempiricalstudiestodeterminewhataffectssoftwarecost,andoverallquality.Whatisasoftwareprocessmodel?Incontrasttosoftwarelifecyclemodels,softwareprocessmodelsoftenrepresentanetworkedsequenceofactivities,objects,transformations,andeventsthatembodystrategiesforsoftwareevolution.Suchmodelscanbeusedtodevelopmorepreciseandformalizeddescriptionsofsoftwarelifecycleactivities.Theirpoweremergesfromtheirutilizationofasufficientlyrichnotation,syntax,orsemantics,oftensuitableforcomputationalprocessing.Softwareprocessnetworkscanbeviewedasrepresentingmultipleinterconnectedtaskchains(Kling1982,Garg1989).Taskchainsrepresentanon-linearsequenceofactionsthatstructureandtransformavailablecomputationalobjects(resources)intointermediateorfinishedproducts.Non-linearity implies that the sequenceof actions may be iterative,accommodateultiple/parallelalternatives,aswellaspartiallyorderedtoaccountforincrementalprogress.Taskactionsinturncanbeviewedanon-linearsequencesofprimitiveactionswhichdenoteatomicunitsofcomputingwork,suchasauser'sselectionofaommandormenuentryusingamouseorkeyboard.Winogradandothershavereferredtotheseunitsofcooperative work between people and computers as "structured discourses of (Winograd1986),whiletaskchainshavebecomepopularizedunderthenameof"workflow"(Bolcer1998).Taskchainscanbeemployedtocharacterizeeitherprescriptiveordescriptiveactionsequences.Prescriptivetaskchainsareidealizedplansofwhatactionsshouldbeandinwhatorder.Forexample,ataskchainfortheactivityofobject-orientedsoftwaredesignmightincludethefollowingtaskactions:Developaninformalnarrativespecificationofthesystem.Identifytheobjectsandtheirattributes.Identifytheoperationsontheobjects.Identifytheinterfacesbetweenobjects,attributes,oroperations.Implementtheoperations.Clearly,thissequenceofactionscouldentailmultipleiterationsandnon-proceduralprimitiveactioninvocationsinthecourseofincrementallyprogressingtowardanobject-orientedsoftwaredesign.Taskchainsjoinorsplitintoothertaskchainsresultinginanoverallproductionnetworkorweb(Kling1982).Theproductionwebrepresentsthe"organizationalproductionsystem"thattransformsrawcomputational,cognitive,andotherorganizationalresourcesintoassembled,integratedandusablesoftwaresystems.Theproductionlatticethereforestructureshowasoftwaresystemisdeveloped,used,andmaintained.However,prescriptivetaskchainsandactionscannotbeformallyguaranteedtoanticipateallpossiblecircumstancesoridiosyncraticfoul-upsthatcanemergeintherealworldofsoftwaredevelopment(Bendifallah1989,1990).Thus,anysoftwareproductionwebwillinsomeway realizeonlyanapproximateorincompletedescriptionofsoftwaredevelopment.Articulationworkisakindofunanticipatedtaskthatisperformedwhenaplannedtaskchainisinadequateorbreaksdown.Itisworkthatrepresentsanopen-endednon-deterministicsequenceofactionstakentorestoreprogressonthedisarticulatedtaskchain,orelsetoshifttheflowofproductiveworkontosomeothertaskchain(Bendifallah1987,Grinter1996,Mi1990,Mi1996,ScacchiandMi1997).Thus,descriptivetaskchainsareemployedtocharacterizetheobservedcourseofeventsandsituationsthatemergewhenpeopletrytofollowaplannedtasksequence.Articulationworkinthecontextofsoftwareevolutionincludesactionspeopletakethatentaileithertheiraccommodationtothecontingentanomalousbehaviorofasoftwaresystem,ornegotiationwithotherswhomaybeabletoaffectasystemmodificationorotherwisealtercurrentcircumstances(Bendifallah1987,Grinter1996,Mi1990,Mi1996,ScacchiandMi1997).Thisnotionofarticulationworkhasalsobeenreferredtoassoftwareprocessdynamism.TraditionalSoftwareLifeCycleModelsTraditionalmodelsofsoftwareevolutionhavebeenwithussincetheearliestdaysofsoftwareengineering.Inthissection,weidentifyfour.Theclassicsoftwarelifecycle(or"waterfallchart")andstepwiserefinementmodelsarewidelyinjustaboutallbooksonmodernprogrammingpracticesandsoftwareengineering.Theincrementalreleasemodeliscloselyrelatedtoindustrialpracticeswhereitmostoftenoccurs.Militarystandardsbasedmodelshavealsoreifiedcertainformsoftheclassiclifecyclemodelintorequiredpracticeforgovernmentcontractors.Eachofthesefourmodelsusescoarse-grainormacroscopiccharacterizationswhendescribingsoftwareevolution.Theprogressivestepsofsoftwareevolutionareoftendescribedasstages,suchasrequirementsspecification,preliminarydesign,andimplementation;theseusuallyhavelittleornofurthercharacterizationotherthanalistofattributesthatproductofsuchastageshouldpossess.Further,thesemodelsareindependentofanyorganizationaldevelopmentsetting,choiceofprogramminglanguage,softwareapplicationdomain,etc.Inshort,thetraditionalmodelsarecontext-freeratherthancontext-sensitive.Butasalloftheselifecyclemodelshavebeeninusetime,werefertothemasthetraditionalmodels,andcharacterizeeachinturn.ClassicSoftwareLifeCycleTheclassicsoftwarelifecycleisoftenrepresentedasasimpleprescriptivewaterfallsoftwarephasemodel,wheresoftwareevolutionproceedsthroughanorderlysequencetransitionsfromonephasetothenextinorder(Royce1970).Suchmodelsresemblefinitestatemachinedescriptionsofsoftwareevolution.However,thesemodelshavebeenperhapsmostusefulinhelpingtostructure,staff,andmanagelargesoftwaredevelopmentprojectscomplexorganizationalsettings,whichwasoneoftheprimarypurposes(Royce1970,1976).Alternatively,theseclassicmodelshavebeenwidelycharacterizedasbothpoordescriptiveandprescriptivemodelsofhowsoftwaredevelopment"in-the-small"or"in-the-large"canorshouldoccur.Figure1providesacommonviewofwaterfallmodelforsoftware developmentattributedtoRoyce(1970).StepwiseRefinementInthisapproach,softwaresystemsaredevelopedthroughtheprogressiverefinementandenhancementofhigh-levelsystemspecificationsintosourcecodecomponents(Wirth1971,Mili1986).However,thechoiceandorderofwhichstepstochooseandwhichrefinementstoapplyremainunstated.Instead,formalizationisexpectedtoemergewithintheheuristicsandskillsthatareacquiredandappliedthroughincreasinglycompetentpractice.Thismodelhasbeenmosteffectiveandwidelyappliedinhelpingtoteachindividualprogrammershowtoorganizetheirsoftwaredevelopmentwork.Manyinterpretationsoftheclassicsoftwarecyclethussubsumethisapproachwithintheirdesignandimplementations.AlternativestotheTraditionalSoftwareLifeCycleModelsThereareatleastthreealternativesetsofmodelsofsoftwaredevelopment.Thesemodelsarealternativestothetraditionalsoftwarelifecyclemodels.Thesethreesetsfocusofattentiontoeithertheproducts,productionprocesses,orproductionsettingsassociatedwithsoftwaredevelopment.Collectively,thesealternativemodelsarefiner-grained,oftendetailedtothepointofcomputationalformalization,moreoftenempiricallygrounded,andinsomecasesaddresstheroleofnewautomatedtechnologiesinfacilitatingsoftwaredevelopment.Asthesemodelsarenotinwidespreadpractice,weexamineeachsetofmodelsinthefollowingsections.SoftwareProductDevelopmentModelsSoftwareproductsrepresenttheinformation-intensiveartifactsthatareincrementallyconstructedanditerativelyrevisedthroughasoftwaredevelopmenteffort.Sucheffortscanbemodeledusingsoftwareproductlifecyclemodels.Theseproductdevelopmentmodelsrepresentanevolutionaryrevisiontothetraditionalsoftwarelifecyclemodels(MacCormack2001).Therevisionsaroseduetotheavailabilityofnewsoftwaredevelopmenttechnologiessuchsoftwareprototypinglanguagesandenvironments,reusablesoftware,applicationgenerators,anddocumentationsupportenvironments.Eachofthesetechnologiesseekstoenablethecreationofexecutablesoftwareimplementationseitherearlierinthesoftwaredevelopmenteffortormorerapidly.Thereforeinthisregard,themodelsofsoftwaredevelopmentmaybeimplicitintheuseofthetechnology,ratherthanexplicitlyarticulated.Thisispossiblebecausesuchmodelsbecomeincreasinglyintuitivetothosedeveloperswhosefavorableexperienceswiththesetechnologiessubstantiatetheiruse.Thus,detailedexaminationofthesemodelsismostappropriatewhensuchtechnologiesareavailableforuseorexperimentation.3.1 RapidPrototypingandJointApplicationDevelopmentPrototypingisatechniqueforprovidingareducedfunctionalityoralimitedperformanceversionofasoftwaresystemearlyinitsdevelopment(Balzer1983,Budde1984,Hekmatpour1987).Incontrasttotheclassicsystemlifecycle,prototypingisanapproachwherebymoreemphasis,activity,andprocessingaredirectedtotheearlystagesofsoftwaredevelopment(requirementsanalysisandfunctionalspecification).Inturn,prototypingcanmoredirectlyaccommodateearlyuserparticipationindetermining,shaping,orevaluatingemergingsystemfunctionality.Therefore,theseup-frontconcentrationsofeffort,togetherwiththeuseofprototypingtechnologies,seekst