外文翻譯---軟件過程模型

1、<p><b>　　軟件過程模型</b></p><p>　　Process Models in Software Engineering</p><p>　　作者：Stephen H. Kan</p><p>　　起止頁碼：第8頁～第17頁</p><p>　　出版日期（期刊號）：2002年9月（卷1）<

2、;/p><p>　　出版單位：Addison-Wesley Professional</p><p><b>　　外文翻譯譯文：</b></p><p><b>　　摘要</b></p><p>　　軟件系統(tǒng)從起初的開發(fā)，維護，再到一個版本升級到另一個版本，經(jīng)歷了一系列階段.這篇文章歸納和整理了一些描述

3、如何開發(fā)軟件系統(tǒng)的方法.從傳統(tǒng)的軟件生命周期的背景和定義出發(fā)，即大多數(shù)教科書所討論的，并且目前的軟件開發(fā)實踐所遵循的軟件生命周期，接著討論作為目前軟件工程技術基石的更全面的軟件開發(fā)模型.</p><p><b>　　1 前言</b></p><p>　　軟件業(yè)的發(fā)展最早可追溯到開發(fā)大型軟件項目的顯式模型，那是在二十世紀五十年代和六十年代間.總體而言，這些早期的軟件生

4、命周期模型的唯一目的就是提供一個合理的概念計劃來管理軟件系統(tǒng)的開發(fā).因此，這種計劃可以作為一個基礎規(guī)劃，組織，人員配備，協(xié)調，預算編制，并指導軟件開發(fā)活動. </p><p>　　自20世紀60年代，出現(xiàn)了許多經(jīng)典的軟件生命周期的描述（例如，霍西爾1961年，勞斯萊斯1970年，1976年博伊姆，迪斯塔索1980年，1984年斯卡基，薩默維爾1999年）.羅伊斯（1970）使用現(xiàn)在生活中熟悉的“瀑布”圖表，提出了

5、周期的概念，這個圖表概括了開發(fā)大型軟件系統(tǒng)是多么的困難，因為它涉及復雜的工程任務，而這些任務在完成之前可能需要不斷地返工.這些圖表也通常在介紹性發(fā)言中被采用，主要針對開發(fā)大型軟件系統(tǒng)的人們（例如，定制軟件的客戶），他們可能不熟悉各種各樣的技術問題但還是要必須解決這些問題.</p><p>　　這些經(jīng)典的軟件生命周期模型通常包括以下活動一些內容：</p><p>　　系統(tǒng)啟動/規(guī)劃：系統(tǒng)從何

6、而來？在大多數(shù)情況下，不論是現(xiàn)有的信息處理機制以前是自動的，手工的，還是非正式的，新系統(tǒng)都會取代或補充它們. </p><p>　　● 需求分析和說明書：闡述一個新的軟件系統(tǒng)將要開發(fā)的問題：其業(yè)務能力，其所達到的性能特點，支持系統(tǒng)運行和維護所需的條件. </p><p>　　● 功能或原型說明：潛在確

7、定計算的對象，它們的屬性和關系，改變這些對象的操作，約束系統(tǒng)行為的限制等.</p><p>　　● 劃分與選擇：給出需求和功能說明書，將系統(tǒng)分為可管理的模塊，它們是邏輯子系統(tǒng)的標志，然后確定是否有對應于這些模塊的新的，現(xiàn)有的，或可重復使用的軟件系統(tǒng)可以復用.</p><p>　　● 設計及配置說明書：以適合模塊的詳細設計和整體配置管理的方式定義各子系統(tǒng)之間的內部關系和接口.</p

8、><p>　　● 模塊設計的詳細規(guī)格說明：定義數(shù)據(jù)流在各組件之間傳遞的算法.</p><p>　　● 模塊實現(xiàn)和調試：將前面的規(guī)格說明的內容通過代碼實現(xiàn)并驗證他們的基本操作是否正確. </p><p>　　● 軟件集成與測試：確認并維持軟件系統(tǒng)結構配置的整體完整性.通過配置軟件系統(tǒng)架構的一致性和驗證完整的實施模塊，核實規(guī)格說明書中模塊的接口和內部關系，并驗證系統(tǒng)及

9、其子系統(tǒng)的性能是否他們的要求匹配.</p><p>　　● 文檔修訂和配送系統(tǒng)：將已經(jīng)寫好的系統(tǒng)開發(fā)說明書進行包裝并合理的轉化為系統(tǒng)文檔和用戶指南，所有的文檔都是以一種適于普及和系統(tǒng)支持的格式.</p><p>　　● 部署和安裝：提供安裝已發(fā)布軟件到本地計算機環(huán)境的指南，配置操作系統(tǒng)的參數(shù)和用戶的訪問權限，并運行診斷測試，以保證系統(tǒng)的基本操作的正常運作.</p><

10、;p>　　● 培訓和使用：提供教學器材及系統(tǒng)用戶指南，方便用戶了解系統(tǒng)的性能和限定，以便有效地使用該系統(tǒng). </p><p>　　● 軟件維護：通過提供功能改進，維修，性能提高及更新使得在其主機系統(tǒng)環(huán)境下維持有用的操作.</p><p>　　1.1 什么是軟件生命周期模型?</p><p>　　軟件生命周期模型是關于軟件是如何或應該是怎樣開發(fā)的描述性或說

11、明性的描述.描述性模型闡述了一個特定的軟件系統(tǒng)開發(fā)的過程.描述性模型可作為理解和改進軟件開發(fā)過程的基礎，或者作為開發(fā)系統(tǒng)的經(jīng)典規(guī)范模型（柯蒂斯，杰瑞，Iscoe，1988年）.這個模型描述了軟件應該如何開發(fā).它作為準則或框架來組織和策劃軟件開發(fā)應如何執(zhí)行，以及以什么順序.通常情況下，闡述軟件系統(tǒng)應該如何開發(fā)的規(guī)范性的生命周期模型，是比較容易和明確的.這是因為這種模式是直觀的并能夠很好的推導出來.這意味著，在實踐中，許多描述中提到的軟件開

12、發(fā)的細節(jié)是可以忽略不計的，或可以拖延的.當然，在不同的開發(fā)環(huán)境，使用不同的編程語言，由不同水平的開發(fā)人員，開發(fā)不同類型的應用系統(tǒng)時，應該相對的提高開發(fā)的有效性和健壯性.當然，在軟件開發(fā)的過程中，規(guī)范性的模型運用一些給定的軟件工程工具或環(huán)境后，也被用來包裝發(fā)任務和技術.</p><p>　　另一方面，描述性的生命周期模型描述了在特定的環(huán)境下，軟件系統(tǒng)實際中是如何開發(fā)的.因此，它們不太常見，更難以闡明，一個明顯的原因

13、：一個人必須觀察并收集整個軟件系統(tǒng)生命周期的數(shù)據(jù)，而這往往以年來衡量.此外，描述性模型針對具體觀察的系統(tǒng)，在進行系統(tǒng)的比較分析后得出來的.因此，這意味著規(guī)范的軟件生命周期模型占據(jù)著主導地位，直到大量的觀測數(shù)據(jù)提供足夠的資料，并闡明更好的生命周期模型.</p><p>　　這兩種描述表明，闡述軟件生命周期模型有一系列的目的.這些描述可以作為：</p><p>　　● 在安排時間，空間和計算

14、環(huán)境上指引協(xié)調，計劃，配備人員，安排并管理軟件項目工作.</p><p>　　● 規(guī)范指出產(chǎn)生什么樣的文件交付給客戶.</p><p>　　● 確定哪些軟件工程工具和方法將是最適合支持不同的生命周期活動的.</p><p>　　● 分析并估計在軟件生命周期中的資源分配和開支的框架（博伊姆1981）</p><p>

15、;　　● 進行實證研究的基礎，用以確定影響軟件生產(chǎn)率、成本以及整體質量的因素.</p><p>　　1.2 什么是軟件過程模型?</p><p>　　相對于軟件生命周期模型，軟件過程模型往往代表一個網(wǎng)絡化的序列活動、對象、轉換和事件，體現(xiàn)能夠實現(xiàn)軟件發(fā)展的策略的事件.這種模型可以用來制定更精確、更規(guī)范化的關于軟件生命周期活動的描述.它們的強大源于充分利用了豐富的符號，語法和語義，而這些

16、往往是適合于計算處理的.</p><p>　　軟件過程網(wǎng)絡可以被看作是代表多個相互關聯(lián)的任務鏈（克林1982年，加爾格1989年）.任務鏈代表了非線性序列的活動，這些活動能夠建造并改造現(xiàn)有的計算對象（資源），將其轉化成為中間或最終產(chǎn)品.非線性意味著活動的順序是不確定的，反復的，可以容納多個/平行的替代品，以及部分被用來循序漸進地推進.反過來，任務活動可以被視為非線性的簡單活動序列，這些簡單活動是計算處理的最小單元

17、，比如用戶使用鼠標或鍵盤進行命令或者菜單的一次選擇. </p><p>　　維諾格拉特和其他人將人與計算機之間的這種協(xié)同工作的單位，稱作是“結構化論述的工作”（維諾格拉特電腦1986年），而任務鏈，以“工作流程”（Bolcer 1998年）的名稱變得大眾化. </p><p>　　任務鏈可以用來描述任何規(guī)范或描述動作序列.指令性任務鏈是理想的計劃，計劃應該完成什么樣的活動，以及以什么順序.

18、例如，對于面向對象的軟件設計任務鏈活動可能包括下面的任務行動：</p><p>　　● 開發(fā)系統(tǒng)的一個非正式的規(guī)范.</p><p>　　● 確定對象和它們的屬性.</p><p>　　● 確定行動的對象.</p><p>　　● 確定對象之間，屬性或操作的接口.</p><p><b>　

19、　● 實施行動.</b></p><p>　　顯然，在增量模型逐步走向面向對象軟件設計的過程中，這種行動可能帶來多次迭代序列和非序列化的簡單活動.</p><p>　　任務鏈的結合或分割成其他任務鏈導致整體的生產(chǎn)網(wǎng)絡或網(wǎng)絡的產(chǎn)生（克林1982年）.這種生產(chǎn)網(wǎng)絡代表“組織生產(chǎn)系統(tǒng)”，它能將原始的計算，認知，和其他組織的資源轉化成綜合的和可使用的軟件系統(tǒng).因此，這種開發(fā)結構闡釋

20、了如何開發(fā)，使用和維護軟件系統(tǒng).但是，指令性任務鏈及其活動不能保證預期所有可能的情況會出現(xiàn)在軟件開發(fā)過程中（Bendifallah 1989年，Mi 1990）.因此，任何軟件制作的網(wǎng)頁只是以某種方式描述一個近似的或不完整軟件開發(fā)過程.</p><p>　　銜接工作是額外的任務，當計劃的任務鏈不足或破裂時才會執(zhí)行.它是一個開放的工作，在非銜接任務鏈上存儲進度，否則會將工作流轉移到其他一些生產(chǎn)性的工作任務鏈.因此，

21、描述任務鏈是用來描述當人們試圖按照計劃任務執(zhí)行時，出現(xiàn)的意外情況.銜接任務在軟件發(fā)展方面的工作包括采取人們的行動，就是凡涉及他們的住所，或一個軟件系統(tǒng)的異常行為，或與可以影響系統(tǒng)改變的人的協(xié)商.這種銜接工作的概念也被稱為軟件處理的推動力.</p><p>　　2 傳統(tǒng)軟件生命周期模型</p><p>　　傳統(tǒng)的軟件演化模型對于我們來說已經(jīng)很熟悉，因為早期的軟件開發(fā)就應用了這些.經(jīng)典的軟件

22、生命周期（或“瀑布圖”）一同逐步求精的模型在當前現(xiàn)代編程方法和軟件工程中被廣泛采用.增量釋放模型和工業(yè)實踐密切相關.基于模型的規(guī)范標準將經(jīng)典的生命周期模型具體化到為政府的承建商的軟件開發(fā).這四種模式分別使用粗粒度或宏觀特征來描述軟件的開發(fā).軟件開發(fā)的漸進過程經(jīng)常被描述為需求分析，設計，實施，這些通常很少或沒有進一步的表征每一階段都應具備.此外，這些模型是獨立于任何組織的開發(fā)環(huán)境、編程語言的選擇、軟件應用領域等.傳統(tǒng)的模型是上下文無關的，

23、而不是和上下文都有聯(lián)系的.但由于這些生命周期的所有模型在使用了一段時間，我們統(tǒng)稱他們?yōu)閭鹘y(tǒng)的模式，刻畫每個轉折.</p><p>　　2.1 經(jīng)典的軟件生命周期模型</p><p>　　經(jīng)典的軟件生命周期通常表示為一個簡單的規(guī)范瀑布軟件階段模型，即從一個階段有序的過渡到下一個階段.這種模式類似于描述軟件開發(fā)的有窮狀態(tài)機.但是，這些模型對于在復雜的組織環(huán)境下架構，分配人員和管理大型的軟件開

24、發(fā)項目中已經(jīng)也許是最有用的了，這就是它的主要目的所在.</p><p>　　另外，這些經(jīng)典模型已被廣泛用來描述如何開發(fā)小型或者大型的軟件項目.</p><p><b>　　2.2 逐步細化</b></p><p>　　在這種方法中，軟件系統(tǒng)的開發(fā)是通過逐步完善和由高層次的系統(tǒng)規(guī)格說明書升級到源代碼組件實現(xiàn)的.不過，至于選擇那一個步驟以及運用哪

25、一種升級辦法，這些仍然沒有言明.相反，在越來越多的工程實踐中，隨著不斷地反思和學習并應用這些方法，規(guī)范必定會出現(xiàn).在指導程序員如何組織軟件開發(fā)工作的過程中，這一模式已被廣泛有效深入的應用.經(jīng)典的軟件生命周期的許多說法也在他們的設計和實現(xiàn)過程中得到闡釋.</p><p>　　2.3 替代傳統(tǒng)的軟件生命周期模型</p><p>　　至少有三種可供選擇的軟件開發(fā)模型，這些模型都是傳統(tǒng)的軟件生命

26、周期模型.它們關注的重點在于產(chǎn)品，開發(fā)過程，軟件的開發(fā)環(huán)境.總的來說，這些模型是細粒度，通常計算形式化的要點描述得很詳細，往往以實證基礎，有時也闡述一些新的能促進軟件開發(fā)的自動化技術.</p><p>　　3 軟件產(chǎn)品開發(fā)模型</p><p>　　軟件產(chǎn)品代表了信息密集化的手工產(chǎn)品，經(jīng)歷了逐步設計并通過反復修改的開發(fā)工作才完成的.這一過程可以使用軟件產(chǎn)品的生命周期模型來說明.這些產(chǎn)品開發(fā)

27、模型代表了基于傳統(tǒng)的軟件生命周期模型上的漸進式開發(fā)模式.由于新的軟件開發(fā)技術，諸如軟件原型語言和環(huán)境，可重用的軟件，應用類，和文件支持環(huán)境的出現(xiàn)，這些模型才產(chǎn)生.這些技術旨在使每一個可執(zhí)行的軟件實施步驟提前完成.因此，這樣看來，軟件設計模式隱含于技術的實踐中，而不是明確的闡述.這是可能的，因為這些模式在那些有經(jīng)驗的開發(fā)人員的實踐中顯得越來越直觀.因此，當這些技術應用于工程實踐中，才是核查這些模型最合適的時候.</p>&l

28、t;p>　　3.1 快速原型和聯(lián)合應用開發(fā)</p><p>　　原型是在軟件系統(tǒng)開發(fā)初期，提供精簡功能或有限版本性能的技術（巴爾澤1983年，布德1984年，Hekmatpour 1987年）.相對于傳統(tǒng)的系統(tǒng)生命周期，原型是一種更著重于軟件開發(fā)早期階段（需求分析和功能設計）的策略.反過來，原型在定義、確定以及評估新系統(tǒng)的功能時就要更多的用戶參與.因此，這些努力的前期任務，再加上原型技術的運用，都旨在權衡

29、或減少后期的軟件設計任務，并簡化軟件開發(fā)工作. </p><p>　　軟件原型有多種不同的形式，包括一次性原型，實物原型，示范系統(tǒng)，快速原型，漸進式原型（Hekmatpour 1987年）.增加的功能和隨后的演化性是區(qū)分這些原型形式的所在.</p><p>　　快速原型技術通常以軟件功能說明書的形式作為其出發(fā)點，而這反過來是模擬，分析，或直接執(zhí)行.這些技術可以讓開發(fā)人員能夠快速構建軟件的早

30、期或原始版本系統(tǒng)，用戶就可以評估.用戶評價后可以進一步作為反饋，進而改進系統(tǒng)規(guī)格說明和設計.此外，根據(jù)原型技術，完整的軟件開發(fā)工作可以通過不斷的開發(fā)修改/精煉已有的規(guī)格說明.這就一向提供了有利的系統(tǒng)工作版本，來重新定義軟件設計和測試方案，使得規(guī)范說明不斷完善并得以執(zhí)行.另外，其他原型方法最適合發(fā)展一次性或演示系統(tǒng)，或者通過復用部分/所有的已有軟件系統(tǒng)來構造原型.其次，為什么現(xiàn)代軟件開發(fā)模式比如螺旋模型和ISO 12207預期原型將是一個

31、共同的活動，其有利于捕捉和完善軟件需求，以及全面的軟件開發(fā)，這樣看來就變得很清楚了.</p><p><b>　　外文翻譯原文：</b></p><p><b>　　Abstract</b></p><p>　　Software systems come and go through a series of passage

32、s 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 h

33、ow 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

34、by a</p><p>　　1 Introduction</p><p>　　Explicit models of software evolution date back to the earliest projects developing large software systems in the 1950's and 1960's (Hosier 1961, R

35、oyce 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

36、 basis for planning, organizing, staffing, coordinating, budgeting, and directing software development activities. </p><p>　　Since the 1960's, many descriptions of the classic software life cycle have ap

37、peared (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, disp

38、layed in Figure 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</p&g

39、t;<p>　　These classic software life cycle models usually include some version or subset of the following activities: </p><p>　　? System Initiation/Planning: where do systems come from? In most situati

40、ons, new feasible systems replace or supplement existing information processing mechanisms whether they were previously automated, manual, or informal.</p><p>　　? Requirement Analysis and Specification: iden

41、tifies 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.<

42、;/p><p>　　? Functional Specification or Prototyping: identifies and potentially formalizes the objects of computation, their attributes and relationships, the operations that transform these objects, the constr

43、aints that restrict system behavior, and so forth.</p><p>　　? Partition and Selection (Build vs. Buy vs. Reuse): given requirements and functional specifications, divide the system into manageable pieces tha

44、t denote logical subsystems, then determine whether new, existing, or reusable software systems correspond to the needed pieces.</p><p>　　? Architectural Design and Configuration Specification: defines the i

45、nterconnection and resource interfaces between system subsystems, components, and modules in ways suitable for their detailed design and overall configuration management.</p><p>　　? Detailed Component Design

46、 Specification: defines the procedural methods through which the data resources within the modules of a component are transformed from required inputs into provided outputs.</p><p>　　? Component Implementati

47、on and Debugging: codifies the preceding specifications into operational source code implementations and validates their basic operation.</p><p>　　? Software Integration and Testing: affirms and sustains the

48、 overall integrity of the software system architectural configuration through verifying the consistency and completeness of implemented modules, verifying the resource interfaces and interconnections against their specif

49、ications, and validating the performance of the system and subsystems against their requirements.</p><p>　　? Documentation Revision and System Delivery: packaging and rationalizing recorded system developmen

50、t descriptions into systematic documents and user guides, all in a form suitable for dissemination and system support.</p><p>　　? Deployment and Installation: providing directions for installing the delivere

51、d software into the local computing environment, configuring operating systems parameters and user access privileges, and running diagnostic test cases to assure the viability of basic system operation.</p><p&

52、gt;　　? Training and Use: providing system users with instructional aids and guidance for understanding the system's capabilities and limits in order to effectively use the system.</p><p>　　? Software Mai

53、ntenance: sustaining the useful operation of a system in its host/target </p><p>　　environment by providing requested functional enhancements, repairs, performance improvements, and conversions.</p>&

54、lt;p>　　1.1 What is a software life cycle model?</p><p>　　A software life cycle model is either a descriptive or prescriptive characterization of how software is or should be developed. A descriptive mode

55、l 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

56、prescriptive models (Curtis, Krasner, Iscoe, 1988). A prescriptive model prescribes how a new software system should be developed. Pre</p><p>　　Descriptive life cycle models, on the other hand, characterize

57、how particular software systems are actually developed in specific settings. As such, they are less common and more difficult to articulate for an obvious reason: one must observe or collect data throughout the life cycl

58、e 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 through systematic comparative analysis. Therefore, this s<

59、;/p><p>　　These two characterizations suggest that there are a variety of purposes for articulating software life cycle models. These characterizations serve as a </p><p>　　? Guideline to organize,

60、 plan, staff, budget, schedule and manage software project work</p><p>　　over organizational time, space, and computing environments.</p><p>　　? Prescriptive outline for what documents to produc

61、e for delivery to client.</p><p>　　? Basis for determining what software engineering tools and methodologies will be most</p><p>　　appropriate to support different life cycle activities.</p&g

62、t;<p>　　? Framework for analyzing or estimating patterns of resource allocation and consumption</p><p>　　during the software life cycle (Boehm 1981).</p><p>　　? Basis for conducting empir

63、ical studies to determine what affects software productivity,</p><p>　　cost, and overall quality.</p><p>　　1.2 What is a software process model?</p><p>　　In contrast to software l

64、ife cycle models, software process models often represent a networked sequence of activities, objects, transformations, and events that embody strategies for software evolution. Such models can be used to develop more p

65、recise 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.</p&g

66、t;<p>　　Software 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 structure and transform avai

67、lable computational objects (resources) into intermediate or finished products. Non-linearity implies that the sequence of actions may be non-deterministic, iterative, accommodate ultiple/parallel alternatives, as well a

68、s partially ordered to account for incremental progress. Task actions in tu</p><p>　　Winograd and others have referred to these units of cooperative work between people and computers as "structured disc

69、ourses of work" (Winograd 1986), while task chains have become popularized under the name of "workflow" (Bolcer 1998).</p><p>　　Task chains can be employed to characterize either prescriptive

70、or descriptive action sequences. 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 software design might

71、 include the following task actions:</p><p>　　? Develop an informal narrative specification of the system.</p><p>　　? Identify the objects and their attributes.</p><p>　　? Identify

72、the operations on the objects.</p><p>　　? Identify the interfaces between objects, attributes, or operations.</p><p>　　? Implement the operations.</p><p>　　Clearly, this sequence of

73、 actions could entail multiple iterations and non-procedural primitive action invocations in the course of incrementally progressing toward an object-oriented software design.</p><p>　　Task chains join or sp

74、lit into other task chains resulting in an overall production network or web (Kling 1982). The production web represents the "organizational production system" that transforms raw computational, cognitive, and

75、other organizational resources into assembled, integrated and usable software systems. The production lattice therefore structures how a software system is developed, used, and maintained. However, prescriptive task chai

76、ns and actions cannot be formally guaranteed to </p><p>　　Articulation work is a kind of unanticipated task that is performed when a planned task chain is inadequate or breaks down. It is work that represent

77、s an open-ended non-deterministic sequence of actions taken to restore progress on the disarticulated task chain, or else to shift the flow of productive work onto some other task chain (Bendifallah 1987, Grinter 1996, M

78、i 1990, Mi 1996, Scacchi and Mi 1997). Thus, descriptive task chains are employed to characterize the observed course of events and</p><p>　　2 Traditional Software Life Cycle Models</p><p>　　Tr

79、aditional models of software evolution have been with us since the earliest days of software engineering. In this section, we identify four. The classic software life cycle (or "waterfall chart") and stepwise r

80、efinement models are widely instantiated in just about all books on modern programming practices and software engineering. The incremental release model is closely related to industrial practices where it most often occu

81、rs. Military standards based models have also reified certain forms </p><p>　　2.1 Classic Software Life Cycle</p><p>　　The classic software life cycle is often represented as a simple prescript

82、ive waterfall software phase model, where software evolution proceeds through an orderly sequence of transitions from one phase to the next in order (Royce 1970). Such models resemble finite state machine descriptions of

83、 software evolution. However, these models have been perhaps most useful in helping to structure, staff, and manage large software development projects in complex organizational settings, which was one of t</p>&l

84、t;p>　　Alternatively, these classic models have been widely characterized as both poor descriptive and prescriptive models of how software development "in-the-small" or "in-the-large" can or should

85、occur. Figure 1 provides a common view of the waterfall model for software development attributed to Royce(1970). </p><p>　　2.2 Stepwise Refinement</p><p>　　In this approach, software systems

86、 are developed through the progressive refinement and enhancement of high-level system specifications into source code components (Wirth 1971, Mili 1986). However, the choice and order of which steps to choose and which

87、refinements to apply remain unstated. Instead, formalization is expected to emerge within the heuristics and skills that are acquired and applied through increasingly competent practice. This model has been most effectiv

88、e and widely applied in he</p><p>　　2.3 Alternatives to the Traditional Software Life Cycle Models</p><p>　　There are at least three alternative sets of models of software development. These mo

89、dels are alternatives to the traditional software life cycle models. These three sets focus of attention to either the products, production processes, or production settings associated with software development. Collecti

90、vely, these alternative models are finer-grained, often detailed to the point of computational formalization, more often empirically grounded, and in some cases address the role of new automated </p><p>　　3

91、 Software Product Development Models</p><p>　　Software products represent the information-intensive artifacts that are incrementally constructed and iteratively revised through a software development effort.

92、 Such efforts can be modeled using software product life cycle models. These product development models represent an evolutionary revision to the traditional software life cycle models (MacCormack 2001). The revisions ar

93、ose due to the availability of new software development technologies such as software prototyping languages and environ</p><p>　　3.1 Rapid Prototyping and Joint Application Development</p><p>　

94、　Prototyping is a technique for providing a reduced functionality or a limited performance version of a software system early in its development (Balzer 1983, Budde 1984,Hekmatpour 1987). In contrast to the classic syste

95、m life cycle, prototyping is an approach whereby more emphasis, activity, and processing are directed to the early stages of software development (requirements analysis and functional specification). In turn, prototyping

96、 can more directly accommodate early user participation in de</p><p>　　Prototyping technologies usually take some form of software functional specifications as their starting point or input, which in turn is

97、 simulated, analyzed, or directly executed. These technologies can allow developers to rapidly construct early or primitive versions of software systems that users can evaluate. User evaluations can then be incorporated