軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻

軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻PAGE\*ROMANPAGE\*ROMANII軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻(文檔含英文原文和中文翻譯)軟件工程中的過程處理模型斯卡基沃爾特摘要軟件系統(tǒng)從起初的開發(fā)，維護，再到一個版本升級到另一個版本，經(jīng)歷了一系列階段。這篇文章歸納和整理了一些描述如何開發(fā)軟件系統(tǒng)的方法。從傳統(tǒng)的軟件生命周期的背景和定義出發(fā)，即大多數(shù)教科書所討論的，并且目前的軟件開發(fā)實踐所遵循的軟件生命周期，接著討論作為目前軟件工程技術(shù)基石的更全面的軟件開發(fā)模型。關(guān)鍵詞：軟件生命周期；模型；原型軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻PAGEPAGE1前言軟件業(yè)的發(fā)展最早可追溯到開發(fā)大型軟件項目的顯式模型，那是在二十世紀(jì)五十年代和六十年代間。總體而言，這些早期的軟件生命周期模型的唯一目的就是提供一個合理的概念計劃來管理軟件系統(tǒng)的開發(fā)。因此，這種計劃可以作為一個基礎(chǔ)規(guī)劃，組織，理的概念計劃來管理軟件系統(tǒng)的開發(fā)。因此，這種計劃可以作為一個基礎(chǔ)規(guī)劃，組織，202060（例如，霍西爾196119611970，19761980，1984念，這個圖表概括了開發(fā)大型軟件系統(tǒng)是多么的困難，因為它涉及復(fù)雜的工程任務(wù)，而1999。羅伊斯使用現(xiàn)在生活中熟悉的“瀑布”圖表，提出了周期的概念，這個圖表概括了開發(fā)大型軟件系統(tǒng)是多么的困難，因為它涉及復(fù)雜的工程任務(wù)，而這些任務(wù)在完成之前可能需要不斷地返工。這些圖表也通常在介紹性發(fā)言中被采用，主要針對開發(fā)大型軟件系統(tǒng)的人們（例如，定制軟件的客戶），他們可能不熟悉各種各樣的技術(shù)問題但還是要必須解決這些問題。的技術(shù)問題但還是要必須解決這些問題。這些經(jīng)典的軟件生命周期模型通常包括以下活動一些內(nèi)容：這些經(jīng)典的軟件生命周期模型通常包括以下活動一些內(nèi)容：系統(tǒng)啟動/規(guī)劃：系統(tǒng)從何而來？在大多數(shù)情況下，不論是現(xiàn)有的信息處理機制以前是自動的，手工的，還是非正式的，新系統(tǒng)都會取代或補充它們。需求分析和說明書：闡述一個新的軟件系統(tǒng)將要開發(fā)的問題：其業(yè)務(wù)能力，其所達到的性能特點，支持系統(tǒng)運行和維護所需的條件。操作，約束系統(tǒng)行為的限制等。功能或原型說明：潛在確定計算的對象，它們的屬性和關(guān)系，改變這些對象的操作，約束系統(tǒng)行為的限制等。劃分與選擇：給出需求和功能說明書，將系統(tǒng)分為可管理的模塊，它們是邏輯子系統(tǒng)的標(biāo)志，然后確定是否有對應(yīng)于這些模塊的新的，現(xiàn)有的，或可重復(fù)使用的軟件子系統(tǒng)的標(biāo)志，然后確定是否有對應(yīng)于這些模塊的新的，現(xiàn)有的，或可重復(fù)使用的軟件系統(tǒng)可以復(fù)用。系統(tǒng)可以復(fù)用。統(tǒng)之間的內(nèi)部關(guān)系和接口。設(shè)計及配置說明書：以適合模塊的詳細設(shè)計和整體配置管理的方式定義各子系●統(tǒng)之間的內(nèi)部關(guān)系和接口。設(shè)計及配置說明書：以適合模塊的詳細設(shè)計和整體配置管理的方式定義各子系●模塊設(shè)計的詳細規(guī)格說明：定義數(shù)據(jù)流在各組件之間傳遞的算法。模塊實現(xiàn)和調(diào)試：將前面的規(guī)格說明的內(nèi)容通過代碼實現(xiàn)并驗證他們的基本操●模塊設(shè)計的詳細規(guī)格說明：定義數(shù)據(jù)流在各組件之間傳遞的算法。模塊實現(xiàn)和調(diào)試：將前面的規(guī)格說明的內(nèi)容通過代碼實現(xiàn)并驗證他們的基本操作是否正確。作是否正確。軟件集成與測試：確認(rèn)并維持軟件系統(tǒng)結(jié)構(gòu)配置的整體完整性。通過配置軟件并驗證系統(tǒng)及其子系統(tǒng)的性能是否他們的要求匹配。系統(tǒng)文檔和用戶指南，所有的文檔都是以一種適于普及和系統(tǒng)支持的格式。文檔修訂和配送系統(tǒng)：將已經(jīng)寫好的系統(tǒng)開發(fā)說明書進行包裝并合理的轉(zhuǎn)化為系統(tǒng)文檔和用戶指南，所有的文檔都是以一種適于普及和系統(tǒng)支持的格式。部署和安裝：提供安裝已發(fā)布軟件到本地計算機環(huán)境的指南，配置操作系統(tǒng)的參數(shù)和用戶的訪問權(quán)限，并運行診斷測試，以保證系統(tǒng)的基本操作的正常運作。以便有效地使用該系統(tǒng)。軟件維護：通過提供功能改進，維修，性能提高及更新使得在其主機系統(tǒng)環(huán)境以便有效地使用該系統(tǒng)。軟件維護：通過提供功能改進，維修，性能提高及更新使得在其主機系統(tǒng)環(huán)境●下維持有用的操作。下維持有用的操作。軟件生命周期模型是關(guān)于軟件是如何或應(yīng)該是怎樣開發(fā)的描述性或說明性的描述。軟件生命周期模型是關(guān)于軟件是如何或應(yīng)該是怎樣開發(fā)的描述性或說明性的描述。（著，在實踐中，許多描述中提到的軟件開發(fā)的細節(jié)是可以忽略不計的，或可以拖延的。著，在實踐中，許多描述中提到的軟件開發(fā)的細節(jié)是可以忽略不計的，或可以拖延的。當(dāng)然，在不同的開發(fā)環(huán)境，使用不同的編程語言，由不同水平的開發(fā)人員，開發(fā)不同類規(guī)范性的模型運用一些給定的軟件工程工具或環(huán)境后，也被用來包裝發(fā)任務(wù)和技術(shù)。這兩種描述表明，闡述軟件生命周期模型有一系列的目的。這些描述可以作為：項目工作。規(guī)范指出產(chǎn)生什么樣的文件交付給客戶。確定哪些軟件工程工具和方法將是最適合支持不同的生命周期活動的。分析并估計在軟件生命周期中的資源分配和開支的框架（博伊姆1981）進行實證研究的基礎(chǔ)，用以確定影響軟件生產(chǎn)率、成本以及整體質(zhì)量的因素。相對于軟件生命周期模型，軟件過程模型往往代表一個網(wǎng)絡(luò)化的序列活動、對象、相對于軟件生命周期模型，軟件過程模型往往代表一個網(wǎng)絡(luò)化的序列活動、對象、轉(zhuǎn)換和事件，體現(xiàn)能夠?qū)崿F(xiàn)軟件發(fā)展的策略的事件。這種模型可以用來制定更精確、更轉(zhuǎn)換和事件，體現(xiàn)能夠?qū)崿F(xiàn)軟件發(fā)展的策略的事件。這種模型可以用來制定更精確、更規(guī)范化的關(guān)于軟件生命周期活動的描述。它們的強大源于充分利用了豐富的符號，語法和語義，而這些往往是適合于計算處理的。（1982年。任務(wù)鏈代表了非線性序列的活動，這些活動能夠建造并改造現(xiàn)有的計算對象（資源源，將其轉(zhuǎn)化成為中間或最終產(chǎn)品。非線性意味著活動的順序是不確定的，反復(fù)的，可以容納多個/平行的替代品，以及部分被用來循序漸進地推進。反過來，任務(wù)活動可以被視為非線性的簡單活動序列，這些簡單活動是計算處理的最小單元，比如用戶使用鼠標(biāo)或鍵盤進行命令或者菜單的一次選擇。1986，而任務(wù)鏈，以“工作流程”Bolcer1998的名稱變得大眾化。任務(wù)鏈可以用來描述任何規(guī)范或描述動作序列。指令性任務(wù)鏈?zhǔn)抢硐氲挠媱?，計劃?yīng)該完成什么樣的活動，以及以什么順序。例如，對于面向?qū)ο蟮能浖O(shè)計任務(wù)鏈活動可能包括下面的任務(wù)行動：開發(fā)系統(tǒng)的一個非正式的規(guī)范。確定對象和它們的屬性?！翊_定對象和它們的屬性。確定行動的對象。●確定行動的對象。確定對象之間，屬性或操作的接口?！翊_定對象之間，屬性或操作的接口。實施行動?！駥嵤┬袆印ｏ@然，在增量模型逐步走向面向?qū)ο筌浖O(shè)計的過程中，這種行動可能帶來多次迭顯然，在增量模型逐步走向面向?qū)ο筌浖O(shè)計的過程中，這種行動可能帶來多次迭代序列和非序列化的簡單活動。代序列和非序列化的簡單活動。任務(wù)鏈的結(jié)合或分割成其他任務(wù)鏈導(dǎo)致整體的生產(chǎn)網(wǎng)絡(luò)或網(wǎng)絡(luò)的產(chǎn)生（克林1982源轉(zhuǎn)化成綜合的和可使用的軟件系統(tǒng)。因此，這種開發(fā)結(jié)構(gòu)闡釋了如何開發(fā)，使用和維年。這種生產(chǎn)網(wǎng)絡(luò)代表“組織生產(chǎn)系統(tǒng)”，它能將原始的計算，認(rèn)知，和其他組織的資源轉(zhuǎn)化成綜合的和可使用的軟件系統(tǒng)。因此，這種開發(fā)結(jié)構(gòu)闡釋了如何開發(fā)，使用和維開發(fā)過程中Bendifallah1989Mi1990。因此，任何軟件制作的網(wǎng)頁只是以某種方式描述一個近似的或不完整軟件開發(fā)過程。銜接工作是額外的任務(wù)，當(dāng)計劃的任務(wù)鏈不足或破裂時才會執(zhí)行。它是一個開放的工作，在非銜接任務(wù)鏈上存儲進度，否則會將工作流轉(zhuǎn)移到其他一些生產(chǎn)性的工作任務(wù)鏈。因此，描述任務(wù)鏈?zhǔn)怯脕砻枋霎?dāng)人們試圖按照計劃任務(wù)執(zhí)行時，出現(xiàn)的意外情況。銜接任務(wù)在軟件發(fā)展方面的工作包括采取人們的行動，就是凡涉及他們的住所，或一個軟件系統(tǒng)的異常行為，或與可以影響系統(tǒng)改變的人的協(xié)商。這種銜接工作的概念也被稱為軟件處理的推動力。式描述一個近似的或不完整軟件開發(fā)過程。傳統(tǒng)軟件生命周期模型傳統(tǒng)的軟件演化模型對于我們來說已經(jīng)很熟悉，因為早期的軟件開發(fā)就應(yīng)用了這些。經(jīng)典的軟件生命周期（或“瀑布圖”）一同逐步求精的模型在當(dāng)前現(xiàn)代編程方法和軟件工程中被廣泛采用。增量釋放模型和工業(yè)實踐密切相關(guān)?；谀Ｐ偷囊?guī)范標(biāo)準(zhǔn)將經(jīng)這些通常很少或沒有進一步的表征每一階段都應(yīng)具備。此外，這些模型是獨立于任何組織的開發(fā)環(huán)境、編程語言的選擇、軟件應(yīng)用領(lǐng)域等。傳統(tǒng)的模型是上下文無關(guān)的，而不是和上下文都有聯(lián)系的。但由于這些生命周期的所有模型在使用了一段時間，我們統(tǒng)稱他們?yōu)閭鹘y(tǒng)的模式，刻畫每個轉(zhuǎn)折。經(jīng)典的軟件生命周期模型有序的過渡到下一個階段。這種模式類似于描述軟件開發(fā)的有窮狀態(tài)機。但是，這些模有用的了，這就是它的主要目的所在。有用的了，這就是它的主要目的所在。另外，這些經(jīng)典模型已被廣泛用來描述如何開發(fā)小型或者大型的軟件項目。另外，這些經(jīng)典模型已被廣泛用來描述如何開發(fā)小型或者大型的軟件項目。逐步細化效深入的應(yīng)用。經(jīng)典的軟件生命周期的許多說法也在他們的設(shè)計和實現(xiàn)過程中得到闡釋。釋。替代傳統(tǒng)的軟件生命周期模型至少有三種可供選擇的軟件開發(fā)模型，這些模型都是傳統(tǒng)的軟件生命周期模型。它們關(guān)注的重點在于產(chǎn)品，開發(fā)過程，軟件的開發(fā)環(huán)境。總的來說，這些模型是細粒度，通常計算形式化的要點描述得很詳細，往往以實證基礎(chǔ)，有時也闡述一些新的能促進軟通常計算形式化的要點描述得很詳細，往往以實證基礎(chǔ)，有時也闡述一些新的能促進軟件開發(fā)的自動化技術(shù)。件開發(fā)的自動化技術(shù)。軟件產(chǎn)品開發(fā)模型作才完成的。這一過程可以使用軟件產(chǎn)品的生命周期模型來說明。這些產(chǎn)品開發(fā)模型代作才完成的。這一過程可以使用軟件產(chǎn)品的生命周期模型來說明。這些產(chǎn)品開發(fā)模型代表了基于傳統(tǒng)的軟件生命周期模型上的漸進式開發(fā)模式。由于新的軟件開發(fā)技術(shù)，諸如表了基于傳統(tǒng)的軟件生命周期模型上的漸進式開發(fā)模式。由于新的軟件開發(fā)技術(shù)，諸如軟件原型語言和環(huán)境，可重用的軟件，應(yīng)用類，和文件支持環(huán)境的出現(xiàn)，這些模型才產(chǎn)軟件原型語言和環(huán)境，可重用的軟件，應(yīng)用類，和文件支持環(huán)境的出現(xiàn)，這些模型才產(chǎn)生。這些技術(shù)旨在使每一個可執(zhí)行的軟件實施步驟提前完成。因此，這樣看來，軟件設(shè)生。這些技術(shù)旨在使每一個可執(zhí)行的軟件實施步驟提前完成。因此，這樣看來，軟件設(shè)計模式隱含于技術(shù)的實踐中，而不是明確的闡述。這是可能的，因為這些模式在那些有計模式隱含于技術(shù)的實踐中，而不是明確的闡述。這是可能的，因為這些模式在那些有經(jīng)驗的開發(fā)人員的實踐中顯得越來越直觀。因此，當(dāng)這些技術(shù)應(yīng)用于工程實踐中，才是經(jīng)驗的開發(fā)人員的實踐中顯得越來越直觀。因此，當(dāng)這些技術(shù)應(yīng)用于工程實踐中，才是核查這些模型最合適的時候。核查這些模型最合適的時候。3.13.1快速原型和聯(lián)合應(yīng)用開發(fā)原型是在軟件系統(tǒng)開發(fā)初期，提供精簡功能或有限版本性能的技術(shù)（巴爾澤原型是在軟件系統(tǒng)開發(fā)初期，提供精簡功能或有限版本性能的技術(shù)（巴爾澤19831984年，Hekmatpour1987年。相對于傳統(tǒng)的系統(tǒng)生命周期，原型是一種更著重于軟件開發(fā)早期階段（需求分析和功能設(shè)計）的策略。反過來，原型在定義、確定著重于軟件開發(fā)早期階段（需求分析和功能設(shè)計）的策略。反過來，原型在定義、確定以及評估新系統(tǒng)的功能時就要更多的用戶參與。因此，這些努力的前期任務(wù)，再加上原以及評估新系統(tǒng)的功能時就要更多的用戶參與。因此，這些努力的前期任務(wù)，再加上原型技術(shù)的運用，都旨在權(quán)衡或減少后期的軟件設(shè)計任務(wù)，并簡化軟件開發(fā)工作。型技術(shù)的運用，都旨在權(quán)衡或減少后期的軟件設(shè)計任務(wù)，并簡化軟件開發(fā)工作。軟件原型有多種不同的形式，包括一次性原型，實物原型，示范系統(tǒng)，快速原型，漸進軟件原型有多種不同的形式，包括一次性原型，實物原型，示范系統(tǒng)，快速原型，漸進（Hekmatpour1987年快速原型技術(shù)通常以軟件功能說明書的形式作為其出發(fā)點，而這反過來是模擬，分快速原型技術(shù)通常以軟件功能說明書的形式作為其出發(fā)點，而這反過來是模擬，分析，或直接執(zhí)行。這些技術(shù)可以讓開發(fā)人員能夠快速構(gòu)建軟件的早期或原始版本系統(tǒng)，析，或直接執(zhí)行。這些技術(shù)可以讓開發(fā)人員能夠快速構(gòu)建軟件的早期或原始版本系統(tǒng)，用戶就可以評估。用戶評價后可以進一步作為反饋，進而改進系統(tǒng)規(guī)格說明和設(shè)計。此用戶就可以評估。用戶評價后可以進一步作為反饋，進而改進系統(tǒng)規(guī)格說明和設(shè)計。此/精煉已有的規(guī)格說明。這就一向提供了有利的系統(tǒng)工作版本，來重新定義軟件設(shè)計和測試方案，使得規(guī)范說明這就一向提供了有利的系統(tǒng)工作版本，來重新定義軟件設(shè)計和測試方案，使得規(guī)范說明不斷完善并得以執(zhí)行。另外，其他原型方法最適合發(fā)展一次性或演示系統(tǒng)，或者通過復(fù)不斷完善并得以執(zhí)行。另外，其他原型方法最適合發(fā)展一次性或演示系統(tǒng)，或者通過復(fù)用部分用部分/ISO12207預(yù)期原型將是一個共同的活動，其有利于捕捉和完善軟件需求，以及全面的軟件開發(fā)，這樣看來就變得很清楚了。的軟件開發(fā)，這樣看來就變得很清楚了。參考文獻 Scacchi,W.,UnderstandingSoftwareProcessRedesignusingModeling,AnalysisSimulation.SoftwareProcess--ImprovementandPractice5(2/3):183-195,2000. Raffo,D.andW.Scacchi,SpecialIssueonSoftwareProcessSimulationandModeling,SoftwareProcess--ImprovementandPractice,5(2-3),87-209,2000. MacCormack,A.,Product-DevelopmentPracticesthatWork:HowInternetCompaniesBuildSoftware,SloanManagementReview,75-84,Winter2001.Beck,K.ExtremeProgrammingExplain,Addison-Wesley,PaloAlto,CA,1999.Chatters,B.W.,M.M.Lehman,J.F.Ramil,andP.Werwick,ModelingaSoftwareEvolutionProcess:ALong-TermCaseStudy,SoftwareProcess-ImprovementPractice,5(2-3),91-102,2000.Noll,J.andW.Scacchi,SpecifyingProcess-OrientedHypertextforOrganizationalComputing,J.NetworkandComputerApplications,24(1):39-61,2001.軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻PAGEPAGE10ProcessModelsinSoftwareEngineeringAbstract:Softwaresystemscomeandgothroughaseriesofpassagesthataccountfortheirinception,initialdevelopment,productiveoperation,upkeep,andretirementfromonegenerationanother.Thisarticlecategorizesandexaminesanumberofmethodsfordescribingormodelinghowsoftwaresystemsaredeveloped.withbackgroundanddefinitionsoftraditionalsoftwarelifecyclemodelsthatdominatemosttextbookdiscussionsandcurrentsoftwaredevelopmentpractices.Thisisfollowedbyamorecomprehensivereviewofthealternativemodelsofsoftwareevolutionthatareofcurrentuseasthebasisfororganizingsoftwareengineeringprojectsandtechnologies.IntroductionExplicitmodelsofsoftwareevolutiondatebacktotheearliestprojectsdevelopinglargesoftwaresystemsinthe1950'sand1960's(Hosier1961,Royce1970).Overall,theapparentpurposeoftheseearlysoftwarelifecyclemodelswastoprovideaconceptualschemeforrationallymanagingthedevelopmentofsoftwaresystems.Suchaschemecouldthereforeserveasabasisforplanning,organizing,staffing,coordinating,budgeting,anddirectingsoftwaredevelopmentactivities.Sincethe1960's,manydescriptionsoftheclassicsoftwarelifecyclehaveappeared(e.g.,Hosier1961,Royce1970,Boehm1976,Distaso1980,Scacchi1984,SomervilleRoyce(1970)originatedtheformulationofthesoftwarelifecycleusingthenowfamiliar"waterfall"chart,displayedinFigure1.Thechartsummarizesinasingledisplayhowdevelopinglargesoftwaresystemsisdifficultbecauseitinvolvescomplexengineeringtasksthatmayrequireiterationandreworkbeforecompletion.Thesechartsareoftenemployedduringintroductorypresentations,forpeople(e.g.,customersofcustomsoftware)whomaybeunfamiliarwiththevarioustechnicalproblemsandstrategiesthatmustbeaddressedwhenconstructinglargesoftwaresystems(Royce1970).Theseclassicsoftwarelifecyclemodelsusuallyincludesomeversionorsubsetofthefollowingactivities:SystemInitiation/Planning:wheredosystemscomefrom?Inmostsituations,feasiblesystemsreplaceorsupplementexistinginformationprocessingmechanismswhethertheywerepreviouslyautomated,manual,orinformal.RequirementAnalysisandSpecification:identifiestheproblemsanewsoftwaresystemissupposetosolve,itsoperationalcapabilities,itsdesiredperformancecharacteristics,andtheresourceinfrastructureneededtosupportsystemoperationandmaintenance.FunctionalSpecificationorPrototyping:identifiesandpotentiallyformalizestheobjectsofcomputation,theirattributesandrelationships,theoperationsthattransformtheseobjects,theconstraintsthatrestrictsystembehavior,andsoforth.PartitionandSelection(Buildvs.Buyvs.Reuse):givenrequirements andfunctionalspecifications,dividethesystemintomanageablepiecesthatdenotelogicalsubsystems,thendeterminewhethernew,existing,orreusablesoftwaresystemscorrespondtotheneededpieces.ArchitecturalDesignandConfigurationSpecification:definestheinterconnectionandresourceinterfacesbetweensystemsubsystems, components,andmodulesin waysfortheirdetaileddesignandoverallconfigurationmanagement.DetailedComponentDesignSpecification:definestheproceduralmethodsthroughwhichthedataresourceswithinthemodulesofacomponentaretransformedfromrequiredinputsintoprovidedoutputs.ComponentImplementationandDebugging:codifiestheprecedingspecificationsintooperationalsourcecodeimplementationsandvalidatestheirbasicoperation.SoftwareIntegrationandTesting:affirmsandsustainstheoverallintegrityofthesoftwaresystemarchitecturalconfigurationthroughverifyingtheconsistencyandcompletenessofimplementedmodules,verifyingtheresourceinterfacesandinterconnectionsagainsttheirspecifications,andvalidatingtheperformanceofthesystemandsubsystemsagainsttheirrequirements.DocumentationRevisionandSystemDelivery:packagingandrationalizingrecordedsystemdevelopmentdescriptionsintosystematicdocumentsanduserguides,allinasuitablefordisseminationandsystemsupport.DeploymentandInstallation:providingdirectionsforinstallingthedeliveredsoftwareintothelocalcomputingenvironment,configuringoperatingsystemsparametersandaccessprivileges,andrunningdiagnostictestcasestoassuretheviabilityofbasicsystemoperation.TrainingandUse:providingsystemuserswithinstructionalaidsandguidanceforunderstandingthesystem'scapabilitiesandlimitsinordertoeffectivelyusethesystem.SoftwareMaintenance:sustainingtheusefuloperationofasysteminitshost/targetenvironment by providing requested functional enhancements, repairs, improvements,andconversions.Whatisasoftwarelifecyclemodel?Asoftwarelifecyclemodeliseitheradescriptiveorprescriptivecharacterizationofhowsoftwareisorshouldbedeveloped.Adescriptivemodeldescribesthehistoryofhowaparticularsoftwaresystemwasdeveloped.Descriptivemodelsmaybeusedasthebasisforunderstandingandimprovingsoftwaredevelopmentprocesses,orforbuildingempiricallygroundedprescriptivemodels(Curtis,Krasner,Iscoe,1988).Aprescriptivemodelprescribeshowanewsoftwaresystemshouldbedeveloped.Prescriptivemodelsareusedasguidelinesorframeworkstoorganizeandstructurehowsoftwaredevelopmentactivitiesshouldbeperformed,andinwhatorder.Typically,itiseasierandmorecommontoarticulateprescriptivelifecyclemodelforhowsoftwaresystemsshouldbedeveloped.Thisispossiblesincemostsuchmodelsareintuitiveorwellreasoned.Thismeansthatmanyidiosyncraticdetailsthatdescribehowasoftwaresystemsisbuiltinpracticecanbeignored,generalized,ordeferredforlaterconsideration.This,ofcourse,shouldraiseconcernfortherelativevalidityandrobustnessofsuchlifecyclemodelswhendevelopingdifferentkindsofapplicationsystems,indifferentkindsofdevelopmentsettings,usingdifferentprogramminglanguages,withdifferentiallyskilledstaff,etc. However,prescriptivemodelsarealsousedto thedevelopmenttasksandtechniquesforusingagivensetofsoftwareengineeringtoolsorenvironmentduringadevelopmentproject.Descriptivelifecyclemodels,ontheotherhand,characterizehowparticularsoftwaresystemsareactuallydevelopedinspecificsettings.Assuch,theyarelesscommonandmoredifficulttoarticulateforanobviousreason:onemustobserveorcollectdatathroughoutthelifecycleofasoftwaresystem,aperiodofelapsedtimeoftenmeasuredinyears.Also,descriptivemodelsarespecifictothesystemsobservedandonlygeneralizablethroughsystematiccomparativeanalysis.Therefore,thissuggeststheprescriptivesoftwarelifecyclemodelswilldominateattentionuntilasufficientbaseofobservationaldataisavailabletoarticulateempiricallygroundeddescriptivelifecyclemodels.Thesetwocharacterizationssuggestthatthereareavarietyofpurposesforarticulatingsoftwarelifecyclemodels.ThesecharacterizationsserveasaGuidelinetoorganize,plan,staff,budget,scheduleandmanagesoftwareprojectworkoverorganizationaltime,space,andcomputingenvironments.Prescriptiveoutlineforwhatdocumentstoproducefordeliverytoclient.Basisfordeterminingwhatsoftwareengineeringtoolsandmethodologieswillbeappropriatetosupportdifferentlifecycleactivities.Frameworkforanalyzingorestimatingpatternsofresourceallocationandconsumptionduringthesoftwarelifecycle(Boehm1981).Basisforconductingempiricalstudiestodeterminewhataffectssoftwarecost,andoverallquality.Whatisasoftwareprocessmodel?Incontrasttosoftwarelifecyclemodels,softwareprocessmodelsoftenrepresentanetworkedsequenceofactivities,objects,transformations,andeventsthatembodystrategiesforsoftwareevolution.Suchmodelscanbeusedtodevelopmorepreciseandformalizeddescriptionsofsoftwarelifecycleactivities.Theirpoweremergesfromtheirutilizationofasufficientlyrichnotation,syntax,orsemantics,oftensuitableforcomputationalprocessing.Softwareprocessnetworkscanbeviewedasrepresentingmultipleinterconnectedtaskchains(Kling1982,Garg1989).Taskchainsrepresentanon-linearsequenceofactionsthatstructureandtransformavailablecomputationalobjects(resources)intointermediateorfinishedproducts.Non-linearity implies that the sequenceof actions may be iterative,accommodateultiple/parallelalternatives,aswellaspartiallyorderedtoaccountforincrementalprogress.Taskactionsinturncanbeviewedanon-linearsequencesofprimitiveactionswhichdenoteatomicunitsofcomputingwork,suchasauser'sselectionofaommandormenuentryusingamouseorkeyboard.Winogradandothershavereferredtotheseunitsofcooperative work between people and computers as "structured discourses of (Winograd1986),whiletaskchainshavebecomepopularizedunderthenameof"workflow"(Bolcer1998).Taskchainscanbeemployedtocharacterizeeitherprescriptiveordescriptiveactionsequences.Prescriptivetaskchainsareidealizedplansofwhatactionsshouldbeandinwhatorder.Forexample,ataskchainfortheactivityofobject-orientedsoftwaredesignmightincludethefollowingtaskactions:Developaninformalnarrativespecificationofthesystem.Identifytheobjectsandtheirattributes.Identifytheoperationsontheobjects.Identifytheinterfacesbetweenobjects,attributes,oroperations.Implementtheoperations.Clearly,thissequenceofactionscouldentailmultipleiterationsandnon-proceduralprimitiveactioninvocationsinthecourseofincrementallyprogressingtowardanobject-orientedsoftwaredesign.Taskchainsjoinorsplitintoothertaskchainsresultinginanoverallproductionnetworkorweb(Kling1982).Theproductionwebrepresentsthe"organizationalproductionsystem"thattransformsrawcomputational,cognitive,andotherorganizationalresourcesintoassembled,integratedandusablesoftwaresystems.Theproductionlatticethereforestructureshowasoftwaresystemisdeveloped,used,andmaintained.However,prescriptivetaskchainsandactionscannotbeformallyguaranteedtoanticipateallpossiblecircumstancesoridiosyncraticfoul-upsthatcanemergeintherealworldofsoftwaredevelopment(Bendifallah1989,1990).Thus,anysoftwareproductionwebwillinsomeway realizeonlyanapproximateorincompletedescriptionofsoftwaredevelopment.Articulationworkisakindofunanticipatedtaskthatisperformedwhenaplannedtaskchainisinadequateorbreaksdown.Itisworkthatrepresentsanopen-endednon-deterministicsequenceofactionstakentorestoreprogressonthedisarticulatedtaskchain,orelsetoshifttheflowofproductiveworkontosomeothertaskchain(Bendifallah1987,Grinter1996,Mi1990,Mi1996,ScacchiandMi1997).Thus,descriptivetaskchainsareemployedtocharacterizetheobservedcourseofeventsandsituationsthatemergewhenpeopletrytofollowaplannedtasksequence.Articulationworkinthecontextofsoftwareevolutionincludesactionspeopletakethatentaileithertheiraccommodationtothecontingentanomalousbehaviorofasoftwaresystem,ornegotiationwithotherswhomaybeabletoaffectasystemmodificationorotherwisealtercurrentcircumstances(Bendifallah1987,Grinter1996,Mi1990,Mi1996,ScacchiandMi1997).Thisnotionofarticulationworkhasalsobeenreferredtoassoftwareprocessdynamism.TraditionalSoftwareLifeCycleModelsTraditionalmodelsofsoftwareevolutionhavebeenwithussincetheearliestdaysofsoftwareengineering.Inthissection,weidentifyfour.Theclassicsoftwarelifecycle(or"waterfallchart")andstepwiserefinementmodelsarewidelyinjustaboutallbooksonmodernprogrammingpracticesandsoftwareengineering.Theincrementalreleasemodeliscloselyrelatedtoindustrialpracticeswhereitmostoftenoccurs.Militarystandardsbasedmodelshavealsoreifiedcertainformsoftheclassiclifecyclemodelintorequiredpracticeforgovernmentcontractors.Eachofthesefourmodelsusescoarse-grainormacroscopiccharacterizationswhendescribingsoftwareevolution.Theprogressivestepsofsoftwareevolutionareoftendescribedasstages,suchasrequirementsspecification,preliminarydesign,andimplementation;theseusuallyhavelittleornofurthercharacterizationotherthanalistofattributesthatproductofsuchastageshouldpossess.Further,thesemodelsareindependentofanyorganizationaldevelopmentsetting,choiceofprogramminglanguage,softwareapplicationdomain,etc.Inshort,thetraditionalmodelsarecontext-freeratherthancontext-sensitive.Butasalloftheselifecyclemodelshavebeeninusetime,werefertothemasthetraditionalmodels,andcharacterizeeachinturn.ClassicSoftwareLifeCycleTheclassicsoftwarelifecycleisoftenrepresentedasasimpleprescriptivewaterfallsoftwarephasemodel,wheresoftwareevolutionproceedsthroughanorderlysequencetransitionsfromonephasetothenextinorder(Royce1970).Suchmodelsresemblefinitestatemachinedescriptionsofsoftwareevolution.However,thesemodelshavebeenperhapsmostusefulinhelpingtostructure,staff,andmanagelargesoftwaredevelopmentprojectscomplexorganizationalsettings,whichwasoneoftheprimarypurposes(Royce1970,1976).Alternatively,theseclassicmodelshavebeenwidelycharacterizedasbothpoordescriptiveandprescriptivemodelsofhowsoftwaredevelopment"in-the-small"or"in-the-large"canorshouldoccur.Figure1providesacommonviewofwaterfallmodelforsoftware developmentattributedtoRoyce(1970).StepwiseRefinementInthisapproach,softwaresystemsaredevelopedthroughtheprogressiverefinementandenhancementofhigh-levelsystemspecificationsintosourcecodecomponents(Wirth1971,Mili1986).However,thechoiceandorderofwhichstepstochooseandwhichrefinementstoapplyremainunstated.Instead,formalizationisexpectedtoemergewithintheheuristicsandskillsthatareacquiredandappliedthroughincreasinglycompetentpractice.Thismodelhasbeenmosteffectiveandwidelyappliedinhelpingtoteachindividualprogrammershowtoorganizetheirsoftwaredevelopmentwork.Manyinterpretationsoftheclassicsoftwarecyclethussubsumethisapproachwithintheirdesignandimplementations.AlternativestotheTraditionalSoftwareLifeCycleModelsThereareatleastthreealternativesetsofmodelsofsoftwaredevelopment.Thesemodelsarealternativestothetraditionalsoftwarelifecyclemodels.Thesethreesetsfocusofattentiontoeithertheproducts,productionprocesses,orproductionsettingsassociatedwithsoftwaredevelopment.Collectively,thesealternativemodelsarefiner-grained,oftendetailedtothepointofcomputationalformalization,moreoftenempiricallygrounded,andinsomecasesaddresstheroleofnewautomatedtechnologiesinfacilitatingsoftwaredevelopment.Asthesemodelsarenotinwidespreadpractice,weexamineeachsetofmodelsinthefollowingsections.SoftwareProductDevelopmentModelsSoftwareproductsrepresenttheinformation-intensiveartifactsthatareincrementallyconstructedanditerativelyrevisedthroughasoftwaredevelopmenteffort.Sucheffortscanbemodeledusingsoftwareproductlifecyclemodels.Theseproductdevelopmentmodelsrepresentanevolutionaryrevisiontothetraditionalsoftwarelifecyclemodels(MacCormack2001).Therevisionsaroseduetotheavailabilityofnewsoftwaredevelopmenttechnologiessuchsoftwareprototypinglanguagesandenvironments,reusablesoftware,applicationgenerators,anddocumentationsupportenvironments.Eachofthesetechnologiesseekstoenablethecreationofexecutablesoftwareimplementationseitherearlierinthesoftwaredevelopmenteffortormorerapidly.Thereforeinthisregard,themodelsofsoftwaredevelopmentmaybeimplicitintheuseofthetechnology,ratherthanexplicitlyarticulated.Thisispossiblebecausesuchmodelsbecomeincreasinglyintuitivetothosedeveloperswhosefavorableexperienceswiththesetechnologiessubstantiatetheiruse.Thus,detailedexaminationofthesemodelsismostappropriatewhensuchtechnologiesareavailableforuseorexperimentation.3.1 RapidPrototypingandJointApplicationDevelopmentPrototypingisatechniqueforprovidingareducedfunctionalityoralimitedperformanceversionofasoftwaresystemearlyinitsdevelopment(Balzer1983,Budde1984,Hekmatpour1987).Incontrasttotheclassicsystemlifecycle,prototypingisanapproachwherebymoreemphasis,activity,andprocessingaredirectedtotheearlystagesofsoftwaredevelopment(requirementsanalysisandfunctionalspecification).Inturn,prototypingcanmoredirectlyaccommodateearlyuserparticipationindetermining,shaping,orevaluatingemergingsystemfunctionality.Therefore,theseup-frontconcentrationsofeffort,togetherwiththeuseofprototypingtechnologies,seekst