【正文】 的技術(shù)（巴爾澤 1983年，布德 1984 年， Hekmatpour 1987 年） .相對于傳統(tǒng)的系統(tǒng)生命周期，原型是一種更著重于軟件開發(fā)早期階段（需求分析和功能設(shè)計）的策略 .反過來，原型在定義、確定以及評估新系統(tǒng)的功能時就要更多的用戶參與 .因此，這些努力的前期任務(wù)，再加上原型技術(shù)的運用，都旨在權(quán)衡或減少后期的軟件設(shè)計任務(wù)，并簡化軟件開發(fā)工作 . 軟件原型有多種不同的形式，包括一次性原型，實物原型，示范系統(tǒng)，快速原型，漸進式原型（ Hekmatpour 1987年） .增加的功能和隨后的演化性是區(qū)分這些原型形式的所在 . 快速原型技術(shù)通常以軟件功能說明書的形 式作為其出發(fā)點，而這反過來是模擬，分析，或直接執(zhí)行 .這些技術(shù)可以讓開發(fā)人員能夠快速構(gòu)建軟件的早期或原始版本系統(tǒng)，用戶就可以評估 .用戶評價后可以進一步作為反饋，進而改進系統(tǒng)規(guī)格說明和設(shè)計 .此外，根據(jù)原型技術(shù)，完整的軟件開發(fā)工作可以通過不斷的開發(fā)修改 /精煉已有的規(guī)格說明 .這就一向提供了有利的系統(tǒng)工作版本，來重新定義軟件設(shè)計和測試方案，使得規(guī)范說明不斷完善并得以執(zhí)行 .另外，其他原型方法最適合發(fā)展一次性或演示系統(tǒng)，或者通過復(fù)用部分 /所有的已有軟件系統(tǒng)來構(gòu)造原型 .其次，為什么現(xiàn)代軟件開發(fā)模式比如螺旋模型和 ISO 12207預(yù)期原型將是一個共同的活動，其有利于捕捉和完善軟件需求，以及全面的軟件開發(fā)，這樣看來就變得很清楚了 . 6 外文翻譯原文： Abstract Software systems e 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 modeling 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 prehensive review of the alternative models of software evolution that are of current use as the basis for anizing software engineering projects and technologies. 1 Introduction Explicit models of software evolution date back to the earliest projects developing large software systems in the 195039。s and 196039。s (Hosier 1961, Royce 1970). Overall, the apparent purpose 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, anizing, staffing, coordinating, budgeting, and directing software development activities. Since the 196039。s, many descriptions of the classic software life cycle have appeared (., 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 1. The chart summarizes in a single display how developing large software systems is difficult because it involves plex engineering tasks that may require iteration and rework before pletion. These charts are often employed during introductory presentations, for people (., customers of custom 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: where do systems e 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 solve, its operational capabilities, its desired performance characteristics, and the resource infrastructure needed to support system operation and maintenance. 7 ? Functional Specification or Prototyping: identifies and potentially formalizes the objects of putation, their attributes and relationships, 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 whether 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, ponents, and modules in ways suitable for their detailed design and overall configuration management. ? Detailed Component Design Specification: defines the procedural methods through which the data resources within the modules of a ponent are transformed from required inputs into provided outputs. ? Component Implementation and Debugging: codifies the preceding specifications into 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 pleteness of implemented modules, verifying the resource 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 guides, all in a form suitable for dissemination and system support. ? Deployment and Installation: providing directions for installing the delivered software into the local puting environme