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

1、 软件系统开发中英文对照外文翻译文献软件系统开发中英文对照外文翻译文献(文档含英文原文和中文翻译)I 软件系统开发中英文对照外文翻译文献软件工程中的过程处理模型斯卡基沃尔特摘 要软件系统从起初的开发，维护，再到一个版本升级到另一个版本，经历了一系列阶段。这篇文章归纳和整理了一些描述如何开发软件系统的方法。从传统的软件生命周期的背景和定义出发，即大多数教科书所讨论的，并且目前的软件开发实践所遵循的软件生命周期，接着讨论作为目前软件工程技术基石的更全面的软件开发模型。关键词：软件生命周期； 模型； 原型II 软件系统开发中英文对照外文翻译文献1 前言软件业的发展最早可追溯到开发大型软件项目的显式模

2、型，那是在二十世纪五十年代和六十年代间。总体而言，这些早期的软件生命周期模型的唯一目的就是提供一个合理的概念计划来管理软件系统的开发。因此，这种计划可以作为一个基础规划，组织，人员配备，协调，预算编制，并指导软件开发活动。自 20 世纪 60 年代，出现了许多经典的软件生命周期的描述（例如，霍西尔1961 年，劳斯莱斯 1970 年，1976 年博伊姆，迪斯塔索 1980 年，1984 年斯卡基，萨默维尔 1999 年）。罗伊斯（1970）使用现在生活中熟悉的“瀑布”图表，提出了周期的概念，这个图表概括了开发大型软件系统是多么的困难，因为它涉及复杂的工程任务，而这些任务在完成之前可能需要不断地

3、返工。这些图表也通常在介绍性发言中被采用，主要针对开发大型软件系统的人们（例如，定制软件的客户），他们可能不熟悉各种各样的技术问题但还是要必须解决这些问题。这些经典的软件生命周期模型通常包括以下活动一些内容：系统启动/规划：系统从何而来？在大多数情况下，不论是现有的信息处理机制以前是自动的，手工的，还是非正式的，新系统都会取代或补充它们。 需求分析和说明书：阐述一个新的软件系统将要开发的问题：其业务能力，其所达到的性能特点，支持系统运行和维护所需的条件。 功能或原型说明：潜在确定计算的对象，它们的属性和关系，改变这些对象的操作，约束系统行为的限制等。 划分与选择：给出需求和功能说明书，将系统分

4、为可管理的模块，它们是逻辑子系统的标志，然后确定是否有对应于这些模块的新的，现有的，或可重复使用的软件系统可以复用。 设计及配置说明书：以适合模块的详细设计和整体配置管理的方式定义各子系统之间的内部关系和接口。 模块设计的详细规格说明：定义数据流在各组件之间传递的算法。 模块实现和调试：将前面的规格说明的内容通过代码实现并验证他们的基本操作是否正确。 软件集成与测试：确认并维持软件系统结构配置的整体完整性。通过配置软件系统架构的一致性和验证完整的实施模块，核实规格说明书中模块的接口和内部关系，并验证系统及其子系统的性能是否他们的要求匹配。 文档修订和配送系统：将已经写好的系统开发说明书进行包装

5、并合理的转化为系统文档和用户指南，所有的文档都是以一种适于普及和系统支持的格式。 部署和安装：提供安装已发布软件到本地计算机环境的指南，配置操作系统的1 软件系统开发中英文对照外文翻译文献参数和用户的访问权限，并运行诊断测试，以保证系统的基本操作的正常运作。 培训和使用：提供教学器材及系统用户指南，方便用户了解系统的性能和限定，以便有效地使用该系统。 软件维护：通过提供功能改进，维修，性能提高及更新使得在其主机系统环境下维持有用的操作。1.1 什么是软件生命周期模型?软件生命周期模型是关于软件是如何或应该是怎样开发的描述性或说明性的描述。描述性模型阐述了一个特定的软件系统开发的过程。描述性模型

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

7、程工具或环境后，也被用来包装发任务和技术。另一方面，描述性的生命周期模型描述了在特定的环境下，软件系统实际中是如何开发的。因此，它们不太常见，更难以阐明，一个明显的原因：一个人必须观察并收集整个软件系统生命周期的数据，而这往往以年来衡量。此外，描述性模型针对具体观察的系统，在进行系统的比较分析后得出来的。因此，这意味着规范的软件生命周期模型占据着主导地位，直到大量的观测数据提供足够的资料，并阐明更好的生命周期模型。这两种描述表明，阐述软件生命周期模型有一系列的目的。这些描述可以作为： 在安排时间，空间和计算环境上指引协调，计划，配备人员，安排并管理软件项目工作。 规范指出产生什么样的文件交付给

8、客户。 确定哪些软件工程工具和方法将是最适合支持不同的生命周期活动的。分析并估计在软件生命周期中的资源分配和开支的框架（博伊姆1981）进行实证研究的基础，用以确定影响软件生产率、成本以及整体质量的因素。1.2 什么是软件过程模型?相对于软件生命周期模型，软件过程模型往往代表一个网络化的序列活动、对象、转换和事件，体现能够实现软件发展的策略的事件。这种模型可以用来制定更精确、更规范化的关于软件生命周期活动的描述。它们的强大源于充分利用了丰富的符号，语法2 软件系统开发中英文对照外文翻译文献和语义，而这些往往是适合于计算处理的。软件过程网络可以被看作是代表多个相互关联的任务链（克林 1982 年

9、，加尔格 1989年）。任务链代表了非线性序列的活动，这些活动能够建造并改造现有的计算对象（资源），将其转化成为中间或最终产品。非线性意味着活动的顺序是不确定的，反复的，可以容纳多个/平行的替代品，以及部分被用来循序渐进地推进。反过来，任务活动可以被视为非线性的简单活动序列，这些简单活动是计算处理的最小单元，比如用户使用鼠标或键盘进行命令或者菜单的一次选择。维诺格拉特和其他人将人与计算机之间的这种协同工作的单位，称作是“结构化论述的工作”（维诺格拉特电脑 1986 年），而任务链，以“工作流程”（Bolcer 1998 年）的名称变得大众化。任务链可以用来描述任何规范或描述动作序列。指令性任务

10、链是理想的计划，计划应该完成什么样的活动，以及以什么顺序。例如，对于面向对象的软件设计任务链活动可能包括下面的任务行动： 开发系统的一个非正式的规范。 确定对象和它们的属性。 确定行动的对象。 确定对象之间，属性或操作的接口。 实施行动。显然，在增量模型逐步走向面向对象软件设计的过程中，这种行动可能带来多次迭代序列和非序列化的简单活动。任务链的结合或分割成其他任务链导致整体的生产网络或网络的产生（克林 1982年）。这种生产网络代表“组织生产系统”，它能将原始的计算，认知，和其他组织的资源转化成综合的和可使用的软件系统。因此，这种开发结构阐释了如何开发，使用和维护软件系统。但是，指令性任务链及

11、其活动不能保证预期所有可能的情况会出现在软件开发过程中（Bendifallah 1989 年，Mi 1990）。因此，任何软件制作的网页只是以某种方式描述一个近似的或不完整软件开发过程。衔接工作是额外的任务，当计划的任务链不足或破裂时才会执行。它是一个开放的工作，在非衔接任务链上存储进度，否则会将工作流转移到其他一些生产性的工作任务链。因此，描述任务链是用来描述当人们试图按照计划任务执行时，出现的意外情况。衔接任务在软件发展方面的工作包括采取人们的行动，就是凡涉及他们的住所，或一个软件系统的异常行为，或与可以影响系统改变的人的协商。这种衔接工作的概念也被称为软件处理的推动力。3 软件系统开发中

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

13、这些生命周期的所有模型在使用了一段时间，我们统称他们为传统的模式，刻画每个转折。2.1 经典的软件生命周期模型经典的软件生命周期通常表示为一个简单的规范瀑布软件阶段模型，即从一个阶段有序的过渡到下一个阶段。这种模式类似于描述软件开发的有穷状态机。但是，这些模型对于在复杂的组织环境下架构，分配人员和管理大型的软件开发项目中已经也许是最有用的了，这就是它的主要目的所在。另外，这些经典模型已被广泛用来描述如何开发小型或者大型的软件项目。2.2 逐步细化在这种方法中，软件系统的开发是通过逐步完善和由高层次的系统规格说明书升级到源代码组件实现的。不过，至于选择那一个步骤以及运用哪一种升级办法，这些仍然没

14、有言明。相反，在越来越多的工程实践中，随着不断地反思和学习并应用这些方法，规范必定会出现。在指导程序员如何组织软件开发工作的过程中，这一模式已被广泛有效深入的应用。经典的软件生命周期的许多说法也在他们的设计和实现过程中得到阐释。2.3 替代传统的软件生命周期模型至少有三种可供选择的软件开发模型，这些模型都是传统的软件生命周期模型。它们关注的重点在于产品，开发过程，软件的开发环境。总的来说，这些模型是细粒度，通常计算形式化的要点描述得很详细，往往以实证基础，有时也阐述一些新的能促进软件开发的自动化技术。4 软件系统开发中英文对照外文翻译文献3 软件产品开发模型软件产品代表了信息密集化的手工产品，

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

16、的技术（巴尔泽 1983年，布德 1984 年，Hekmatpour 1987 年）。相对于传统的系统生命周期，原型是一种更着重于软件开发早期阶段（需求分析和功能设计）的策略。反过来，原型在定义、确定以及评估新系统的功能时就要更多的用户参与。因此，这些努力的前期任务，再加上原型技术的运用，都旨在权衡或减少后期的软件设计任务，并简化软件开发工作。软件原型有多种不同的形式，包括一次性原型，实物原型，示范系统，快速原型，渐进式原型（Hekmatpour 1987 年）。增加的功能和随后的演化性是区分这些原型形式的所在。快速原型技术通常以软件功能说明书的形式作为其出发点，而这反过来是模拟，分析，或直接

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

18、照外文翻译文献参考文献1 Scacchi, W., Understanding Software Process Redesign using Modeling, Analysis andSimulation. Software Process -Improvement and Practice 5(2/3):183-195, 2000.2 Raffo, D. and W. Scacchi, Special Issue on Software Process Simulation and Modeling,Software Process-Improvement and Practice, 5

19、(2-3), 87-209, 2000.3 MacCormack, A., Product-Development Practices that Work: How Internet CompaniesBuild Software, Sloan Management Review, 75-84, Winter 2001.4 Beck, K. Extreme Programming Explaine, dAddison-Wesley, Palo Alto, CA, 1999.5 Chatters, B.W., M.M. Lehman, J.F. Ramil, and P. Werwick, Mo

20、deling a SoftwareEvolution Process: A Long-Term Case Study, Software Process-Improvement andPractice, 5(2-3), 91-102, 2000.6 Noll, J. and W. Scacchi, Specifying Process-Oriented Hypertext for OrganizationalComputing, J. Network and Computer Applications, 24(1):39-61, 2001.6 软件系统开发中英文对照外文翻译文献Process

21、Models in Software EngineeringAbstract: Software systems come and go through a series of passages that account for theirinception,initial development, productive operation, upkeep, and retirement from one generation toanother. This article categorizes and examines a number of methods for describing

22、ormodeling how software systems are developed. Itbegins with background and definitions oftraditional software life cycle models that dominate most textbook discussions and currentsoftware development practices. This is followed by a more comprehensive review of thealternative models of software evo

23、lution that are of current use as the basis for organizingsoftware engineering projects and technologies.1 IntroductionExplicit models of software evolution date back to the earliest projects developing largesoftware systems in the 1950s and 1960s (Hosier 1961, Royce 1970). Overall, the apparentpurp

24、ose of these early software life cycle models was to provide a conceptual scheme forrationally managing the development of software systems. Such a scheme could thereforeserve as a basis for planning, organizing, staffing, coordinating, budgeting, and directingsoftware development activities.Since t

25、he 1960s, many descriptions of the classic software life cycle have appeared (e.g.,Hosier 1961, Royce 1970, Boehm 1976, Distaso 1980, Scacchi 1984, Somerville 1999).Royce (1970) originated the formulation of the software life cycle using the now familiarwaterfall chart, displayed in Figure 1. The ch

26、art summarizes in a single display howdeveloping large software systems is difficult because it involves complex engineering tasksthat may require iteration and rework before completion. These charts are often employedduring introductory presentations, for people (e.g., customers of custom software)

27、 who maybe unfamiliar with the various technical problems and strategies that must be addressed whenconstructing large software systems (Royce 1970).These classic software life cycle models usually include some version or subset of thefollowing activities:1 软件系统开发中英文对照外文翻译文献 System Initiation/Planni

28、ng: where do systems come from? In most situations, newfeasible systems replace or supplement existing information processing mechanisms whetherthey were previously automated, manual, or informal. Requirement Analysis and Specification: identifies the problems a new software systemis suppose to solv

29、e, its operational capabilities, its desired performance characteristics, and theresource infrastructure needed to support system operation and maintenance. Functional Specification or Prototyping: identifies and potentially formalizes theobjects of computation, their attributes and relationships, t

30、he operations that transform theseobjects,the constraints that restrict system behavior, and so forth. Partition and Selection (Build vs. Buy vs. Reuse): given requirements and functionalspecifications, divide the system into manageable pieces that denote logical subsystems, thendetermine whether ne

31、w, existing, or reusable software systems correspond to the neededpieces. Architectural Design and Configuration Specification: defines the interconnection andresource interfaces between system subsystems, components, and modules in ways suitablefor their detailed design and overall configuration ma

32、nagement. Detailed Component Design Specification: defines the procedural methods throughwhich the data resources within the modules of a component are transformed from requiredinputs into provided outputs. Component Implementation and Debugging: codifies the preceding specifications intooperational

33、 source code implementations and validates their basic operation. Software Integration and Testing: affirms and sustains the overall integrity of thesoftware system architectural configuration through verifying the consistency andcompleteness of implemented modules, verifying the resource interfaces

34、 and interconnectionsagainst their specifications, and validating the performance of the system and subsystemsagainst their requirements. Documentation Revision and System Delivery: packaging and rationalizing recordedsystem development descriptions into systematic documents and user guides, all in

35、a formsuitable for dissemination and system support.2 软件系统开发中英文对照外文翻译文献 Deployment and Installation: providing directions for installing the delivered softwareinto the local computing environment, configuring operating systems parameters and useraccess privileges, and running diagnostic test cases t

36、o assure the viability of basic systemoperation. Training and Use: providing system users with instructional aids and guidance forunderstanding the systems capabilities and limits in order to effectively use the system. Software Maintenance: sustaining the useful operation of a system in its host/ta

37、rgetenvironment by providing requested functional enhancements, repairs, performanceimprovements, and conversions.1.1 What is a software life cycle model?A software life cycle model is either a descriptive or prescriptive characterization of howsoftware is or should be developed. A descriptive model

38、 describes the history of how aparticular software system was developed.Descriptive models may be used as the basis forunderstanding and improving software development processes, or for building empiricallygrounded prescriptive models (Curtis, Krasner, Iscoe, 1988). A prescriptive model prescribesho

39、w a new software system should be developed. Prescriptive models are used as guidelinesor frameworks to organize and structure how software development activities should beperformed, and in what order. Typically, it is easier and more common to articulate aprescriptive life cycle model for how softw

40、are systems should be developed. This is possiblesince most such models are intuitive or well reasoned. This means that many idiosyncraticdetails that describe how a software systems is built in practice can be ignored, generalized, ordeferred for later consideration. This, of course, should raise c

41、oncern for the relative validityand robustness of such life cycle models when developing different kinds of applicationsystems, in different kinds of development settings, using different programming languages,with differentially skilled staff, etc. However, prescriptive models are also used to pack

42、agethe development tasks and techniques for using a given set of software engineering tools orenvironment during a development project.Descriptive life cycle models, on the other hand, characterize how particular software systemsare actually developed in specific settings. As such, they are less com

43、mon and more difficult3 软件系统开发中英文对照外文翻译文献to articulate for an obvious reason: one must observe or collect data throughout the life cycleof a software system, a period of elapsed time often measured in years. Also, descriptivemodels are specific to the systems observed and only generalizable through

44、systematiccomparative analysis. Therefore, this suggests the prescriptive software life cycle models willdominate attention until a sufficient base of observational data is available to articulateempirically grounded descriptive life cycle models.These two characterizations suggest that there are a

45、variety of purposes for articulatingsoftware life cycle models. These characterizations serve as a Guideline to organize, plan, staff, budget, schedule and manage software project workover organizational time, space, and computing environments. Prescriptive outline for what documents to produce for

46、delivery to client. Basis for determining what software engineering tools and methodologies will be mostappropriate to support different life cycle activities. Framework for analyzing or estimating patterns of resource allocation and consumptionduring the software life cycle (Boehm 1981). Basis for

47、conducting empirical studies to determine what affects software productivity,cost, and overall quality.1.2 What is a software process model?In contrast to software life cycle models, software process models often represent a networkedsequence of activities, objects, transformations, and events that

48、embody strategies forsoftware evolution. Such models can be used to develop more precise and formalizeddescriptions of software life cycle activities. Their power emerges from their utilization of asufficiently rich notation, syntax, or semantics, often suitable for computational processing.Software

49、 process networks can be viewed as representing multiple interconnected task chains(Kling 1982, Garg 1989). Task chains represent a non-linear sequence of actions that structureand transform available computational objects (resources) into intermediate or finishedproducts.Non-linearity implies that

50、the sequence of actions may be non-deterministic,iterative,accommodate ultiple/parallel alternatives, as well as partially ordered to account forincremental progress. Task actions in turn can be viewed a non-linear sequences of primitive4 软件系统开发中英文对照外文翻译文献actions which denote atomic units of computi

51、ng work, such as a users selection of a ommandor menu entry using a mouse or keyboard. Winograd and others have referred to these units ofcooperative work between people and computers as structured discourses of work(Winograd 1986), while task chains have become popularized under the name of workflo

52、w(Bolcer 1998).Task chains can be employed to characterize either prescriptive or descriptive actionsequences.Prescriptive task chains are idealized plans of what actions should be accomplished,and in what order. For example, a task chain for the activity of object-oriented softwaredesign might incl

53、ude the following task actions: Develop an informal narrative specification of the system. Identify the objects and their attributes. Identify the operations on the objects. Identify the interfaces between objects, attributes, or operations. Implement the operations.Clearly, this sequence of actions

54、 could entail multiple iterations and non-procedural primitiveaction invocations in the course of incrementally progressing toward an object-orientedsoftware design.Task chains join or split into other task chains resulting in an overall production network orweb (Kling 1982). The production web repr

55、esents the organizational production system thattransforms raw computational, cognitive, and other organizational resources into assembled,integrated and usable software systems. The production lattice therefore structures how asoftware system is developed, used, and maintained. However, prescriptiv

56、e task chains andactions cannot be formally guaranteed to anticipate all possible circumstances or idiosyncraticfoul-ups that can emerge in the real world of software development (Bendifallah 1989, Mi1990).Thus, any software production web will in some way realize only an approximate orincomplete de

57、scription of software development.Articulation work is a kind of unanticipated task that is performed when a planned task chainis inadequate or breaks down. It is work that represents an open-ended non-deterministicsequence of actions taken to restore progress on the disarticulated task chain, or el

58、se to shift5 软件系统开发中英文对照外文翻译文献the flow of productive work onto some other task chain (Bendifallah 1987, Grinter 1996, Mi1990, Mi 1996, Scacchi and Mi 1997). Thus, descriptive task chains are employed tocharacterize the observed course of events and situations that emerge when people try tofollow a p

59、lanned task sequence.Articulation work in the context of software evolutionincludes actions people take that entail either their accommodation to the contingent oranomalous behavior of a software system, or negotiation with others who may be able toaffect a system modification or otherwise alter cur

60、rent circumstances (Bendifallah 1987,Grinter 1996, Mi 1990, Mi 1996, Scacchi and Mi 1997). This notion of articulation work hasalso been referred to as software process dynamism.2 Traditional Software Life Cycle ModelsTraditional models of software evolution have been with us since the earliestdays