外文翻譯軟件過程模型

1、軟件過程模型process models in software engineering作者：stephen h. kan起止頁碼：第8頁第17頁出版日期（期刊號）：2002年9月（卷1）出版單位：addison-wesley professional外文翻譯譯文：摘要軟件系統(tǒng)從起初的開發(fā)，維護，再到一個版本升級到另一個版本，經(jīng)歷了一系列階段.這篇文章歸納和整理了一些描述如何開發(fā)軟件系統(tǒng)的方法.從傳統(tǒng)的軟件生命周期的背景和定義出發(fā)，即大多數(shù)教科書所討論的，并且目前的軟件開發(fā)實踐所遵循的軟件生命周期，接著討論作為目前軟件工程技術(shù)基石的更全面的軟件開發(fā)模型.1 前言軟件業(yè)的發(fā)展最早可追溯到開發(fā)大型

2、軟件項目的顯式模型，那是在二十世紀五十年代和六十年代間.總體而言，這些早期的軟件生命周期模型的唯一目的就是提供一個合理的概念計劃來管理軟件系統(tǒng)的開發(fā).因此，這種計劃可以作為一個基礎(chǔ)規(guī)劃，組織，人員配備，協(xié)調(diào)，預(yù)算編制，并指導(dǎo)軟件開發(fā)活動. 自20世紀60年代，出現(xiàn)了許多經(jīng)典的軟件生命周期的描述（例如，霍西爾1961年，勞斯萊斯1970年，1976年博伊姆，迪斯塔索1980年，1984年斯卡基，薩默維爾1999年）.羅伊斯（1970）使用現(xiàn)在生活中熟悉的“瀑布”圖表，提出了周期的概念，這個圖表概括了開發(fā)大型軟件系統(tǒng)是多么的困難，因為它涉及復(fù)雜的工程任務(wù)，而這些任務(wù)在完成之前可能需要不斷地返工.這

3、些圖表也通常在介紹性發(fā)言中被采用，主要針對開發(fā)大型軟件系統(tǒng)的人們（例如，定制軟件的客戶），他們可能不熟悉各種各樣的技術(shù)問題但還是要必須解決這些問題.這些經(jīng)典的軟件生命周期模型通常包括以下活動一些內(nèi)容： 系統(tǒng)啟動/規(guī)劃：系統(tǒng)從何而來？在大多數(shù)情況下，不論是現(xiàn)有的信息處理機制以前是自動的，手工的，還是非正式的，新系統(tǒng)都會取代或補充它們. 需求分析和說明書：闡述一個新的軟件系統(tǒng)將要開發(fā)的問題：其業(yè)務(wù)能力，其所達到的性能特點，支持系統(tǒng)運行和維護所需的條件. 功能或原型說明：潛在確定計算的對象，它們的屬性和關(guān)系，改變這些對象的操作，約束系統(tǒng)行為的限制等. 劃分與選擇：給出需求和功能說明書，將系統(tǒng)分為可管

4、理的模塊，它們是邏輯子系統(tǒng)的標志，然后確定是否有對應(yīng)于這些模塊的新的，現(xiàn)有的，或可重復(fù)使用的軟件系統(tǒng)可以復(fù)用. 設(shè)計及配置說明書：以適合模塊的詳細設(shè)計和整體配置管理的方式定義各子系統(tǒng)之間的內(nèi)部關(guān)系和接口. 模塊設(shè)計的詳細規(guī)格說明：定義數(shù)據(jù)流在各組件之間傳遞的算法. 模塊實現(xiàn)和調(diào)試：將前面的規(guī)格說明的內(nèi)容通過代碼實現(xiàn)并驗證他們的基本操作是否正確. 軟件集成與測試：確認并維持軟件系統(tǒng)結(jié)構(gòu)配置的整體完整性.通過配置軟件系統(tǒng)架構(gòu)的一致性和驗證完整的實施模塊，核實規(guī)格說明書中模塊的接口和內(nèi)部關(guān)系，并驗證系統(tǒng)及其子系統(tǒng)的性能是否他們的要求匹配. 文檔修訂和配送系統(tǒng)：將已經(jīng)寫好的系統(tǒng)開發(fā)說明書進行包裝并合理

5、的轉(zhuǎn)化為系統(tǒng)文檔和用戶指南，所有的文檔都是以一種適于普及和系統(tǒng)支持的格式. 部署和安裝：提供安裝已發(fā)布軟件到本地計算機環(huán)境的指南，配置操作系統(tǒng)的參數(shù)和用戶的訪問權(quán)限，并運行診斷測試，以保證系統(tǒng)的基本操作的正常運作. 培訓(xùn)和使用：提供教學(xué)器材及系統(tǒng)用戶指南，方便用戶了解系統(tǒng)的性能和限定，以便有效地使用該系統(tǒng). 軟件維護：通過提供功能改進，維修，性能提高及更新使得在其主機系統(tǒng)環(huán)境下維持有用的操作.1.1 什么是軟件生命周期模型?軟件生命周期模型是關(guān)于軟件是如何或應(yīng)該是怎樣開發(fā)的描述性或說明性的描述.描述性模型闡述了一個特定的軟件系統(tǒng)開發(fā)的過程.描述性模型可作為理解和改進軟件開發(fā)過程的基礎(chǔ)，或者作為

6、開發(fā)系統(tǒng)的經(jīng)典規(guī)范模型（柯蒂斯，杰瑞，iscoe，1988年）.這個模型描述了軟件應(yīng)該如何開發(fā).它作為準則或框架來組織和策劃軟件開發(fā)應(yīng)如何執(zhí)行，以及以什么順序.通常情況下，闡述軟件系統(tǒng)應(yīng)該如何開發(fā)的規(guī)范性的生命周期模型，是比較容易和明確的.這是因為這種模式是直觀的并能夠很好的推導(dǎo)出來.這意味著，在實踐中，許多描述中提到的軟件開發(fā)的細節(jié)是可以忽略不計的，或可以拖延的.當然，在不同的開發(fā)環(huán)境，使用不同的編程語言，由不同水平的開發(fā)人員，開發(fā)不同類型的應(yīng)用系統(tǒng)時，應(yīng)該相對的提高開發(fā)的有效性和健壯性.當然，在軟件開發(fā)的過程中，規(guī)范性的模型運用一些給定的軟件工程工具或環(huán)境后，也被用來包裝發(fā)任務(wù)和技術(shù).另一

7、方面，描述性的生命周期模型描述了在特定的環(huán)境下，軟件系統(tǒng)實際中是如何開發(fā)的.因此，它們不太常見，更難以闡明，一個明顯的原因：一個人必須觀察并收集整個軟件系統(tǒng)生命周期的數(shù)據(jù)，而這往往以年來衡量.此外，描述性模型針對具體觀察的系統(tǒng)，在進行系統(tǒng)的比較分析后得出來的.因此，這意味著規(guī)范的軟件生命周期模型占據(jù)著主導(dǎo)地位，直到大量的觀測數(shù)據(jù)提供足夠的資料，并闡明更好的生命周期模型.這兩種描述表明，闡述軟件生命周期模型有一系列的目的.這些描述可以作為： 在安排時間，空間和計算環(huán)境上指引協(xié)調(diào)，計劃，配備人員，安排并管理軟件項目工作.規(guī)范指出產(chǎn)生什么樣的文件交付給客戶.確定哪些軟件工程工具和方法將是最適合支持不

8、同的生命周期活動的.分析并估計在軟件生命周期中的資源分配和開支的框架（博伊姆1981） 進行實證研究的基礎(chǔ)，用以確定影響軟件生產(chǎn)率、成本以及整體質(zhì)量的因素.1.2 什么是軟件過程模型?相對于軟件生命周期模型，軟件過程模型往往代表一個網(wǎng)絡(luò)化的序列活動、對象、轉(zhuǎn)換和事件，體現(xiàn)能夠?qū)崿F(xiàn)軟件發(fā)展的策略的事件.這種模型可以用來制定更精確、更規(guī)范化的關(guān)于軟件生命周期活動的描述.它們的強大源于充分利用了豐富的符號，語法和語義，而這些往往是適合于計算處理的.軟件過程網(wǎng)絡(luò)可以被看作是代表多個相互關(guān)聯(lián)的任務(wù)鏈（克林1982年，加爾格1989年）.任務(wù)鏈代表了非線性序列的活動，這些活動能夠建造并改造現(xiàn)有的計算對象（

9、資源），將其轉(zhuǎn)化成為中間或最終產(chǎn)品.非線性意味著活動的順序是不確定的，反復(fù)的，可以容納多個/平行的替代品，以及部分被用來循序漸進地推進.反過來，任務(wù)活動可以被視為非線性的簡單活動序列，這些簡單活動是計算處理的最小單元，比如用戶使用鼠標或鍵盤進行命令或者菜單的一次選擇. 維諾格拉特和其他人將人與計算機之間的這種協(xié)同工作的單位，稱作是“結(jié)構(gòu)化論述的工作”（維諾格拉特電腦1986年），而任務(wù)鏈，以“工作流程”（bolcer 1998年）的名稱變得大眾化. 任務(wù)鏈可以用來描述任何規(guī)范或描述動作序列.指令性任務(wù)鏈是理想的計劃，計劃應(yīng)該完成什么樣的活動，以及以什么順序.例如，對于面向?qū)ο蟮能浖O(shè)計任務(wù)鏈活

10、動可能包括下面的任務(wù)行動： 開發(fā)系統(tǒng)的一個非正式的規(guī)范. 確定對象和它們的屬性. 確定行動的對象. 確定對象之間，屬性或操作的接口. 實施行動.顯然，在增量模型逐步走向面向?qū)ο筌浖O(shè)計的過程中，這種行動可能帶來多次迭代序列和非序列化的簡單活動.任務(wù)鏈的結(jié)合或分割成其他任務(wù)鏈導(dǎo)致整體的生產(chǎn)網(wǎng)絡(luò)或網(wǎng)絡(luò)的產(chǎn)生（克林1982年）.這種生產(chǎn)網(wǎng)絡(luò)代表“組織生產(chǎn)系統(tǒng)”，它能將原始的計算，認知，和其他組織的資源轉(zhuǎn)化成綜合的和可使用的軟件系統(tǒng).因此，這種開發(fā)結(jié)構(gòu)闡釋了如何開發(fā)，使用和維護軟件系統(tǒng).但是，指令性任務(wù)鏈及其活動不能保證預(yù)期所有可能的情況會出現(xiàn)在軟件開發(fā)過程中（bendifallah 1989年，mi

11、 1990）.因此，任何軟件制作的網(wǎng)頁只是以某種方式描述一個近似的或不完整軟件開發(fā)過程.銜接工作是額外的任務(wù)，當計劃的任務(wù)鏈不足或破裂時才會執(zhí)行.它是一個開放的工作，在非銜接任務(wù)鏈上存儲進度，否則會將工作流轉(zhuǎn)移到其他一些生產(chǎn)性的工作任務(wù)鏈.因此，描述任務(wù)鏈是用來描述當人們試圖按照計劃任務(wù)執(zhí)行時，出現(xiàn)的意外情況.銜接任務(wù)在軟件發(fā)展方面的工作包括采取人們的行動，就是凡涉及他們的住所，或一個軟件系統(tǒng)的異常行為，或與可以影響系統(tǒng)改變的人的協(xié)商.這種銜接工作的概念也被稱為軟件處理的推動力.2 傳統(tǒng)軟件生命周期模型傳統(tǒng)的軟件演化模型對于我們來說已經(jīng)很熟悉，因為早期的軟件開發(fā)就應(yīng)用了這些.經(jīng)典的軟件生命周期

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

13、為一個簡單的規(guī)范瀑布軟件階段模型，即從一個階段有序的過渡到下一個階段.這種模式類似于描述軟件開發(fā)的有窮狀態(tài)機.但是，這些模型對于在復(fù)雜的組織環(huán)境下架構(gòu)，分配人員和管理大型的軟件開發(fā)項目中已經(jīng)也許是最有用的了，這就是它的主要目的所在.另外，這些經(jīng)典模型已被廣泛用來描述如何開發(fā)小型或者大型的軟件項目.2.2 逐步細化在這種方法中，軟件系統(tǒng)的開發(fā)是通過逐步完善和由高層次的系統(tǒng)規(guī)格說明書升級到源代碼組件實現(xiàn)的.不過，至于選擇那一個步驟以及運用哪一種升級辦法，這些仍然沒有言明.相反，在越來越多的工程實踐中，隨著不斷地反思和學(xué)習(xí)并應(yīng)用這些方法，規(guī)范必定會出現(xiàn).在指導(dǎo)程序員如何組織軟件開發(fā)工作的過程中，這一

14、模式已被廣泛有效深入的應(yīng)用.經(jīng)典的軟件生命周期的許多說法也在他們的設(shè)計和實現(xiàn)過程中得到闡釋.2.3 替代傳統(tǒng)的軟件生命周期模型至少有三種可供選擇的軟件開發(fā)模型，這些模型都是傳統(tǒng)的軟件生命周期模型.它們關(guān)注的重點在于產(chǎn)品，開發(fā)過程，軟件的開發(fā)環(huán)境.總的來說，這些模型是細粒度，通常計算形式化的要點描述得很詳細，往往以實證基礎(chǔ)，有時也闡述一些新的能促進軟件開發(fā)的自動化技術(shù).3 軟件產(chǎn)品開發(fā)模型軟件產(chǎn)品代表了信息密集化的手工產(chǎn)品，經(jīng)歷了逐步設(shè)計并通過反復(fù)修改的開發(fā)工作才完成的.這一過程可以使用軟件產(chǎn)品的生命周期模型來說明.這些產(chǎn)品開發(fā)模型代表了基于傳統(tǒng)的軟件生命周期模型上的漸進式開發(fā)模式.由于新的軟件

15、開發(fā)技術(shù)，諸如軟件原型語言和環(huán)境，可重用的軟件，應(yīng)用類，和文件支持環(huán)境的出現(xiàn)，這些模型才產(chǎn)生.這些技術(shù)旨在使每一個可執(zhí)行的軟件實施步驟提前完成.因此，這樣看來，軟件設(shè)計模式隱含于技術(shù)的實踐中，而不是明確的闡述.這是可能的，因為這些模式在那些有經(jīng)驗的開發(fā)人員的實踐中顯得越來越直觀.因此，當這些技術(shù)應(yīng)用于工程實踐中，才是核查這些模型最合適的時候.3.1 快速原型和聯(lián)合應(yīng)用開發(fā)原型是在軟件系統(tǒng)開發(fā)初期，提供精簡功能或有限版本性能的技術(shù)（巴爾澤1983年，布德1984年，hekmatpour 1987年）.相對于傳統(tǒng)的系統(tǒng)生命周期，原型是一種更著重于軟件開發(fā)早期階段（需求分析和功能設(shè)計）的策略.反過來

16、，原型在定義、確定以及評估新系統(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ā)工作可以

17、通過不斷的開發(fā)修改/精煉已有的規(guī)格說明.這就一向提供了有利的系統(tǒng)工作版本，來重新定義軟件設(shè)計和測試方案，使得規(guī)范說明不斷完善并得以執(zhí)行.另外，其他原型方法最適合發(fā)展一次性或演示系統(tǒng)，或者通過復(fù)用部分/所有的已有軟件系統(tǒng)來構(gòu)造原型.其次，為什么現(xiàn)代軟件開發(fā)模式比如螺旋模型和iso 12207預(yù)期原型將是一個共同的活動，其有利于捕捉和完善軟件需求，以及全面的軟件開發(fā)，這樣看來就變得很清楚了.外文翻譯原文：abstractsoftware systems come and go through a series of passages that account for their inception

18、, 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 mo

19、dels that dominate most textbook discussions and current software development practices. this is followed by a more comprehensive review of the alternative models of software evolution that are of current use as the basis for organizing software engineering projects and technologies.1 introductionex

20、plicit 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 purpose of these early software life cycle models was to provide a conceptual scheme for rationally managing the developmen

21、t of software systems. such a scheme could therefore serve as a basis for planning, organizing, staffing, coordinating, budgeting, and directing software development activities. since the 1960s, many descriptions of the classic software life cycle have appeared (e.g., hosier 1961, royce 1970, boehm

22、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 comple

23、x engineering tasks that may require iteration and rework before completion. these charts are often employed during introductory presentations, for people (e.g., customers of custom software) who may be unfamiliar with the various technical problems and strategies that must be addressed when constru

24、cting 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 come from? in most situations, new feasible systems replace or supplement existing information processi

25、ng 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 suppo

26、rt system operation and maintenance. functional specification or prototyping: identifies and potentially formalizes the objects of computation, their attributes and relationships, the operations that transform these objects, the constraints that restrict system behavior, and so forth. partition and

27、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 s

28、pecification: defines the interconnection and resource interfaces between system subsystems, components, 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 resourc

29、es within the modules of a component 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 a

30、nd sustains the 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 specifications, and validating the performance of the system and subsys

31、tems 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

32、for installing the delivered 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. training and use: providing system users with instructional aids and g

33、uidance 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/target environment by providing requested functional enhancements, repairs, performance improvements, and conversions.1.

34、1 what is a software life cycle model?a software life cycle model is either a descriptive or prescriptive characterization of how software is or should be developed. a descriptive model describes the history of how a particular software system was developed. descriptive models may be used as the bas

35、is for understanding and improving software development processes, or for building empirically grounded prescriptive models (curtis, krasner, iscoe, 1988). a prescriptive model prescribes how a new software system should be developed. prescriptive models are used as guidelines or frameworks to organ

36、ize 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 for how software systems should be developed. this is possible since most such models are intuitive or well reasoned. th

37、is 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, should raise concern for the relative validity and robustness of such life cycle models when developing different kind

38、s of application systems, in different kinds of development settings, using different programming languages, with differentially skilled staff, etc. however, prescriptive models are also used to package the development tasks and techniques for using a given set of software engineering tools or envir

39、onment during a development project.descriptive life cycle models, on the other hand, characterize 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 throu

40、ghout 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 through systematic comparative analysis. therefore, this suggests the prescriptive software life cycle models will dominat

41、e attention until a sufficient base of observational data is available to articulate empirically grounded descriptive life cycle models.these two characterizations suggest that there are a variety of purposes for articulating software life cycle models. these characterizations serve as a guideline t

42、o organize, plan, staff, budget, schedule and manage software project workover organizational time, space, and computing environments. prescriptive outline for what documents to produce for delivery to client. basis for determining what software engineering tools and methodologies will be mostapprop

43、riate 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 conducting empirical studies to determine what affects software productivity,cost, and overall quality.1.2 wha

44、t is a software process model?in contrast to software life 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 precise and formalized desc

45、riptions 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

46、). task chains represent a non-linear sequence of actions that structure and transform available 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

47、, as well as partially ordered to account for incremental progress. task actions in turn can be viewed a non-linear sequences of primitive actions which denote atomic units of computing work, such as a users selection of a ommand or menu entry using a mouse or keyboard. winograd and others have refe

48、rred to these units of cooperative work between people and computers as structured discourses of work (winograd 1986), while task chains have become popularized under the name of workflow (bolcer 1998).task chains can be employed to characterize either prescriptive or descriptive action sequences. p

49、rescriptive 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 include the following task actions: develop an informal narrative specification of the system. identify the objec

50、ts 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 could entail multiple iterations and non-procedural primitive action invocations in the course of incrementa

51、lly progressing toward an object-oriented software design.task chains join or split 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 other organi

52、zational 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 chains and actions cannot be formally guaranteed to anticipate all possible circumstances or idi

53、osyncratic foul-ups that can emerge in the real world of software development (bendifallah 1989, mi 1990).thus, any software production web will in some way realize only an approximate or incomplete description of software development.articulation work is a kind of unanticipated task that is perform

54、ed when a planned task chain is inadequate or breaks down. it is work that represents 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 199

55、6, mi 1990, mi 1996, scacchi and mi 1997). thus, descriptive task chains are employed to characterize the observed course of events and situations that emerge when people try to follow a planned task sequence.articulation work in the context of software evolution includes actions people take that en

56、tail either their accommodation to the contingent or anomalous behavior of a software system, or negotiation with others who may be able to affect a system modification or otherwise alter current circumstances (bendifallah 1987, grinter 1996, mi 1990, mi 1996, scacchi and mi 1997). this notion of ar

57、ticulation work has also been referred to as software process dynamism.2 traditional software life cycle modelstraditional 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

58、chart) and stepwise refinement 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 occurs. military standards based models have also reified certain forms of the classic life cycle model into required practice for government contractors .each of these four models uses coarse-grain or macroscopic characterizations when describing software evolution. the progressive steps of softwar