软件工程中的过程处理模型外文翻译.doc

1、 Process Models in Software EngineeringWalt ScacchiEncyclopedia of Software Engineering, 2nd Edition, 5th ChapterJohn Wiley and Sons, Inc, New York, December 2001.软件工程中的过程处理模型斯卡基沃尔特软件工程百科全书，第二版，第五章John Wiley和Sons出版社，纽约，2001年12月。摘 要软件系统从起初的开发，维护，再到一个版本升级到另一个版本，经历了一系列阶段。这篇文章归纳和整理了一些描述如何开发软件系统的方法。从传统的软

2、件生命周期的背景和定义出发，即大多数教科书所讨论的，并且目前的软件开发实践所遵循的软件生命周期，接着讨论作为目前软件工程技术基石的更全面的软件开发模型。关键词： 软件生命周期； 模型； 原型91 前言软件业的发展最早可追溯到开发大型软件项目的显式模型，那是在二十世纪五十年代和六十年代间。总体而言，这些早期的软件生命周期模型的唯一目的就是提供一个合理的概念计划来管理软件系统的开发。因此，这种计划可以作为一个基础规划，组织，人员配备，协调，预算编制，并指导软件开发活动。 自20世纪60年代，出现了许多经典的软件生命周期的描述（例如，霍西尔1961年，劳斯莱斯1970年，1976年博伊姆，迪斯塔索1

3、980年，1984年斯卡基，萨默维尔1999年）。罗伊斯（1970）使用现在生活中熟悉的“瀑布”图表，提出了周期的概念，这个图表概括了开发大型软件系统是多么的困难，因为它涉及复杂的工程任务，而这些任务在完成之前可能需要不断地返工。这些图表也通常在介绍性发言中被采用，主要针对开发大型软件系统的人们（例如，定制软件的客户），他们可能不熟悉各种各样的技术问题但还是要必须解决这些问题。这些经典的软件生命周期模型通常包括以下活动一些内容： 系统启动/规划：系统从何而来？在大多数情况下，不论是现有的信息处理机制以前是自动的，手工的，还是非正式的，新系统都会取代或补充它们。 需求分析和说明书：阐述一个新的软

4、件系统将要开发的问题：其业务能力，其所达到的性能特点，支持系统运行和维护所需的条件。 功能或原型说明：潜在确定计算的对象，它们的属性和关系，改变这些对象的操作，约束系统行为的限制等。 划分与选择：给出需求和功能说明书，将系统分为可管理的模块，它们是逻辑子系统的标志，然后确定是否有对应于这些模块的新的，现有的，或可重复使用的软件系统可以复用。 设计及配置说明书：以适合模块的详细设计和整体配置管理的方式定义各子系统之间的内部关系和接口。 模块设计的详细规格说明：定义数据流在各组件之间传递的算法。 模块实现和调试：将前面的规格说明的内容通过代码实现并验证他们的基本操作是否正确。 软件集成与测试：确认

5、并维持软件系统结构配置的整体完整性。通过配置软件系统架构的一致性和验证完整的实施模块，核实规格说明书中模块的接口和内部关系，并验证系统及其子系统的性能是否他们的要求匹配。 文档修订和配送系统：将已经写好的系统开发说明书进行包装并合理的转化为系统文档和用户指南，所有的文档都是以一种适于普及和系统支持的格式。 部署和安装：提供安装已发布软件到本地计算机环境的指南，配置操作系统的参数和用户的访问权限，并运行诊断测试，以保证系统的基本操作的正常运作。 培训和使用：提供教学器材及系统用户指南，方便用户了解系统的性能和限定，以便有效地使用该系统。 软件维护：通过提供功能改进，维修，性能提高及更新使得在其主

6、机系统环境下维持有用的操作。1.1 什么是软件生命周期模型?软件生命周期模型是关于软件是如何或应该是怎样开发的描述性或说明性的描述。描述性模型阐述了一个特定的软件系统开发的过程。描述性模型可作为理解和改进软件开发过程的基础，或者作为开发系统的经典规范模型（柯蒂斯，杰瑞，Iscoe，1988年）。这个模型描述了软件应该如何开发。它作为准则或框架来组织和策划软件开发应如何执行，以及以什么顺序。通常情况下，阐述软件系统应该如何开发的规范性的生命周期模型，是比较容易和明确的。这是因为这种模式是直观的并能够很好的推导出来。这意味着，在实践中，许多描述中提到的软件开发的细节是可以忽略不计的，或可以拖延的。

7、当然，在不同的开发环境，使用不同的编程语言，由不同水平的开发人员，开发不同类型的应用系统时，应该相对的提高开发的有效性和健壮性。当然，在软件开发的过程中，规范性的模型运用一些给定的软件工程工具或环境后，也被用来包装发任务和技术。另一方面，描述性的生命周期模型描述了在特定的环境下，软件系统实际中是如何开发的。因此，它们不太常见，更难以阐明，一个明显的原因：一个人必须观察并收集整个软件系统生命周期的数据，而这往往以年来衡量。此外，描述性模型针对具体观察的系统，在进行系统的比较分析后得出来的。因此，这意味着规范的软件生命周期模型占据着主导地位，直到大量的观测数据提供足够的资料，并阐明更好的生命周期模

8、型。这两种描述表明，阐述软件生命周期模型有一系列的目的。这些描述可以作为： 在安排时间，空间和计算环境上指引协调，计划，配备人员，安排并管理软件项目工作。规范指出产生什么样的文件交付给客户。确定哪些软件工程工具和方法将是最适合支持不同的生命周期活动的。 分析并估计在软件生命周期中的资源分配和开支的框架（博伊姆1981） 进行实证研究的基础，用以确定影响软件生产率、成本以及整体质量的因素。1.2 什么是软件过程模型?相对于软件生命周期模型，软件过程模型往往代表一个网络化的序列活动、对象、转换和事件，体现能够实现软件发展的策略的事件。这种模型可以用来制定更精确、更规范化的关于软件生命周期活动的描述

9、。它们的强大源于充分利用了丰富的符号，语法和语义，而这些往往是适合于计算处理的。软件过程网络可以被看作是代表多个相互关联的任务链（克林1982年，加尔格1989年）。任务链代表了非线性序列的活动，这些活动能够建造并改造现有的计算对象（资源），将其转化成为中间或最终产品。非线性意味着活动的顺序是不确定的，反复的，可以容纳多个/平行的替代品，以及部分被用来循序渐进地推进。反过来，任务活动可以被视为非线性的简单活动序列，这些简单活动是计算处理的最小单元，比如用户使用鼠标或键盘进行命令或者菜单的一次选择。 维诺格拉特和其他人将人与计算机之间的这种协同工作的单位，称作是“结构化论述的工作”（维诺格拉特电

10、脑1986年），而任务链，以“工作流程”（Bolcer 1998年）的名称变得大众化。 任务链可以用来描述任何规范或描述动作序列。指令性任务链是理想的计划，计划应该完成什么样的活动，以及以什么顺序。例如，对于面向对象的软件设计任务链活动可能包括下面的任务行动： 开发系统的一个非正式的规范。 确定对象和它们的属性。 确定行动的对象。 确定对象之间，属性或操作的接口。 实施行动。显然，在增量模型逐步走向面向对象软件设计的过程中，这种行动可能带来多次迭代序列和非序列化的简单活动。任务链的结合或分割成其他任务链导致整体的生产网络或网络的产生（克林1982年）。这种生产网络代表“组织生产系统”，它能将原

11、始的计算，认知，和其他组织的资源转化成综合的和可使用的软件系统。因此，这种开发结构阐释了如何开发，使用和维护软件系统。但是，指令性任务链及其活动不能保证预期所有可能的情况会出现在软件开发过程中（Bendifallah 1989年，Mi 1990）。因此，任何软件制作的网页只是以某种方式描述一个近似的或不完整软件开发过程。衔接工作是额外的任务，当计划的任务链不足或破裂时才会执行。它是一个开放的工作，在非衔接任务链上存储进度，否则会将工作流转移到其他一些生产性的工作任务链。因此，描述任务链是用来描述当人们试图按照计划任务执行时，出现的意外情况。衔接任务在软件发展方面的工作包括采取人们的行动，就是凡

12、涉及他们的住所，或一个软件系统的异常行为，或与可以影响系统改变的人的协商。这种衔接工作的概念也被称为软件处理的推动力。2 传统软件生命周期模型传统的软件演化模型对于我们来说已经很熟悉，因为早期的软件开发就应用了这些。经典的软件生命周期（或“瀑布图”）一同逐步求精的模型在当前现代编程方法和软件工程中被广泛采用。增量释放模型和工业实践密切相关。基于模型的规范标准将经典的生命周期模型具体化到为政府的承建商的软件开发。这四种模式分别使用粗粒度或宏观特征来描述软件的开发。软件开发的渐进过程经常被描述为需求分析，设计，实施，这些通常很少或没有进一步的表征每一阶段都应具备。此外，这些模型是独立于任何组织的开

13、发环境、编程语言的选择、软件应用领域等。传统的模型是上下文无关的，而不是和上下文都有联系的。但由于这些生命周期的所有模型在使用了一段时间，我们统称他们为传统的模式，刻画每个转折。2.1 经典的软件生命周期模型经典的软件生命周期通常表示为一个简单的规范瀑布软件阶段模型，即从一个阶段有序的过渡到下一个阶段。这种模式类似于描述软件开发的有穷状态机。但是，这些模型对于在复杂的组织环境下架构，分配人员和管理大型的软件开发项目中已经也许是最有用的了，这就是它的主要目的所在。另外，这些经典模型已被广泛用来描述如何开发小型或者大型的软件项目。2.2 逐步细化在这种方法中，软件系统的开发是通过逐步完善和由高层次

14、的系统规格说明书升级到源代码组件实现的。不过，至于选择那一个步骤以及运用哪一种升级办法，这些仍然没有言明。相反，在越来越多的工程实践中，随着不断地反思和学习并应用这些方法，规范必定会出现。在指导程序员如何组织软件开发工作的过程中，这一模式已被广泛有效深入的应用。经典的软件生命周期的许多说法也在他们的设计和实现过程中得到阐释。2.3 替代传统的软件生命周期模型至少有三种可供选择的软件开发模型，这些模型都是传统的软件生命周期模型。它们关注的重点在于产品，开发过程，软件的开发环境。总的来说，这些模型是细粒度，通常计算形式化的要点描述得很详细，往往以实证基础，有时也阐述一些新的能促进软件开发的自动化技

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

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

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

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 Prac

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

20、wick, Modeling a Software Evolution Process: A Long-Term Case Study, Software Process-Improvement and Practice, 5(2-3), 91-102, 2000.6 Noll, J. and W. Scacchi, Specifying Process-Oriented Hypertext for Organizational Computing, J. Network and Computer Applications, 24(1):39-61, 2001.Process Models i

21、n Software EngineeringAbstract: Software systems come and go through a series of passages that account for their inception,initial development, productive operation, upkeep, and retirement from one generation to another. This article categorizes and examines a number of methods for describing or mod

22、eling how software systems are developed. It begins with background and definitions of traditional software life cycle models that dominate most textbook discussions and current software development practices. This is followed by a more comprehensive review of the alternative models of software evol

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

24、rpose of these early software life cycle models was to provide a conceptual scheme for rationally managing the development of software systems. Such a scheme could therefore serve as a basis for planning, organizing, staffing, coordinating, budgeting, and directing software development activities. S

25、ince the 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 familiar waterfall chart, displayed in Figure

26、1. The chart summarizes in a single display how developing large software systems is difficult because it involves complex engineering tasks that may require iteration and rework before completion. These charts are often employed during introductory presentations, for people (e.g., customers of cust

27、om software) who may be unfamiliar with the various technical problems and strategies that must be addressed when constructing large software systems (Royce 1970). These classic software life cycle models usually include some version or subset of the following activities: System Initiation/Planning:

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

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

30、 the operations that transform these objects,the constraints that restrict system behavior, and so forth. Partition and Selection (Build vs. Buy vs. Reuse): given requirements and functional specifications, divide the system into manageable pieces that denote logical subsystems, then determine wheth

31、er new, existing, or reusable software systems correspond to the needed pieces. Architectural Design and Configuration Specification: defines the interconnection and resource interfaces between system subsystems, components, and modules in ways suitable for their detailed design and overall configur

32、ation management. Detailed Component Design Specification: defines the procedural methods through which the data resources within the modules of a component are transformed from required inputs into provided outputs. Component Implementation and Debugging: codifies the preceding specifications into

33、operational source code implementations and validates their basic operation. Software Integration and Testing: affirms and sustains the overall integrity of the software system architectural configuration through verifying the consistency and completeness of implemented modules, verifying the resour

34、ce interfaces and interconnections against their specifications, and validating the performance of the system and subsystems against their requirements. Documentation Revision and System Delivery: packaging and rationalizing recorded system development descriptions into systematic documents and user

35、 guides, all in a form suitable for dissemination and system support. Deployment and Installation: providing directions for installing the delivered software into the local computing environment, configuring operating systems parameters and user access privileges, and running diagnostic test cases t

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

37、target environment by providing requested functional enhancements, repairs, performance improvements, 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 m

38、odel describes the history of how a particular software system was developed.Descriptive models may be used as the basis for understanding and improving software development processes, or for building empirically grounded prescriptive models (Curtis, Krasner, Iscoe, 1988). A prescriptive model presc

39、ribes how a new software system should be developed. Prescriptive models are used as guidelines or frameworks to organize and structure how software development activities should be performed, and in what order. Typically, it is easier and more common to articulate a prescriptive life cycle model fo

40、r how software systems should be developed. This is possible since most such models are intuitive or well reasoned. This means that many idiosyncratic details that describe how a software systems is built in practice can be ignored, generalized, or deferred for later consideration. This, of course,

41、should raise concern for the relative validity and robustness of such life cycle models when developing different kinds of application systems, in different kinds of development settings, using different programming languages, with differentially skilled staff, etc. However, prescriptive models are

42、also used to package the development tasks and techniques for using a given set of software engineering tools or environment during a development project.Descriptive life cycle models, on the other hand, characterize how particular software systems are actually developed in specific settings. As suc

43、h, they are less common and more difficult to articulate for an obvious reason: one must observe or collect data throughout the life cycle of a software system, a period of elapsed time often measured in years. Also, descriptive models are specific to the systems observed and only generalizable thro

44、ugh systematic comparative analysis. Therefore, this suggests the prescriptive software life cycle models will dominate attention until a sufficient base of observational data is available to articulate empirically grounded descriptive life cycle models.These two characterizations suggest that there

45、 are a variety of purposes for articulating software 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 prod

46、uce for 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). Ba

47、sis for 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 even

48、ts that embody strategies for software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. Their power emerges from their utilization of a sufficiently rich notation, syntax, or semantics, often suitable for computational processing.Software process networks can be viewed as representing multiple interconnected task chains(Kling 1982, Garg 1989).