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