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

1、 軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻(xiàn)軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻(xiàn)(文檔含英文原文和中文翻譯)I 軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻(xiàn)軟件工程中的過程處理模型斯卡基沃爾特摘 要軟件系統(tǒng)從起初的開發(fā)，維護(hù)，再到一個版本升級到另一個版本，經(jīng)歷了一系列階段。這篇文章歸納和整理了一些描述如何開發(fā)軟件系統(tǒng)的方法。從傳統(tǒng)的軟件生命周期的背景和定義出發(fā)，即大多數(shù)教科書所討論的，并且目前的軟件開發(fā)實(shí)踐所遵循的軟件生命周期，接著討論作為目前軟件工程技術(shù)基石的更全面的軟件開發(fā)模型。關(guān)鍵詞：軟件生命周期； 模型； 原型II 軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻(xiàn)1 前言軟件業(yè)的發(fā)展最早可追溯到開發(fā)大型軟件項(xiàng)目的顯式模

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

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

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

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

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

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

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

9、，加爾格 1989年）。任務(wù)鏈代表了非線性序列的活動，這些活動能夠建造并改造現(xiàn)有的計(jì)算對象（資源），將其轉(zhuǎn)化成為中間或最終產(chǎn)品。非線性意味著活動的順序是不確定的，反復(fù)的，可以容納多個/平行的替代品，以及部分被用來循序漸進(jìn)地推進(jìn)。反過來，任務(wù)活動可以被視為非線性的簡單活動序列，這些簡單活動是計(jì)算處理的最小單元，比如用戶使用鼠標(biāo)或鍵盤進(jìn)行命令或者菜單的一次選擇。維諾格拉特和其他人將人與計(jì)算機(jī)之間的這種協(xié)同工作的單位，稱作是“結(jié)構(gòu)化論述的工作”（維諾格拉特電腦 1986 年），而任務(wù)鏈，以“工作流程”（Bolcer 1998 年）的名稱變得大眾化。任務(wù)鏈可以用來描述任何規(guī)范或描述動作序列。指令性任務(wù)

10、鏈?zhǔn)抢硐氲挠?jì)劃，計(jì)劃應(yīng)該完成什么樣的活動，以及以什么順序。例如，對于面向?qū)ο蟮能浖O(shè)計(jì)任務(wù)鏈活動可能包括下面的任務(wù)行動： 開發(fā)系統(tǒng)的一個非正式的規(guī)范。 確定對象和它們的屬性。 確定行動的對象。 確定對象之間，屬性或操作的接口。 實(shí)施行動。顯然，在增量模型逐步走向面向?qū)ο筌浖O(shè)計(jì)的過程中，這種行動可能帶來多次迭代序列和非序列化的簡單活動。任務(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)”，它能將原始的計(jì)算，認(rèn)知，和其他組織的資源轉(zhuǎn)化成綜合的和可使用的軟件系統(tǒng)。因此，這種開發(fā)結(jié)構(gòu)闡釋了如何開發(fā)，使用和維護(hù)軟件系統(tǒng)。但是，指令性任務(wù)鏈及

11、其活動不能保證預(yù)期所有可能的情況會出現(xiàn)在軟件開發(fā)過程中（Bendifallah 1989 年，Mi 1990）。因此，任何軟件制作的網(wǎng)頁只是以某種方式描述一個近似的或不完整軟件開發(fā)過程。銜接工作是額外的任務(wù)，當(dāng)計(jì)劃的任務(wù)鏈不足或破裂時才會執(zhí)行。它是一個開放的工作，在非銜接任務(wù)鏈上存儲進(jìn)度，否則會將工作流轉(zhuǎn)移到其他一些生產(chǎn)性的工作任務(wù)鏈。因此，描述任務(wù)鏈?zhǔn)怯脕砻枋霎?dāng)人們試圖按照計(jì)劃任務(wù)執(zhí)行時，出現(xiàn)的意外情況。銜接任務(wù)在軟件發(fā)展方面的工作包括采取人們的行動，就是凡涉及他們的住所，或一個軟件系統(tǒng)的異常行為，或與可以影響系統(tǒng)改變的人的協(xié)商。這種銜接工作的概念也被稱為軟件處理的推動力。3 軟件系統(tǒng)開發(fā)中

12、英文對照外文翻譯文獻(xiàn)2 傳統(tǒng)軟件生命周期模型傳統(tǒng)的軟件演化模型對于我們來說已經(jīng)很熟悉，因?yàn)樵缙诘能浖_發(fā)就應(yīng)用了這些。經(jīng)典的軟件生命周期（或“瀑布圖”）一同逐步求精的模型在當(dāng)前現(xiàn)代編程方法和軟件工程中被廣泛采用。增量釋放模型和工業(yè)實(shí)踐密切相關(guān)?；谀Ｐ偷囊?guī)范標(biāo)準(zhǔn)將經(jīng)典的生命周期模型具體化到為政府的承建商的軟件開發(fā)。這四種模式分別使用粗粒度或宏觀特征來描述軟件的開發(fā)。軟件開發(fā)的漸進(jìn)過程經(jīng)常被描述為需求分析，設(shè)計(jì)，實(shí)施，這些通常很少或沒有進(jìn)一步的表征每一階段都應(yīng)具備。此外，這些模型是獨(dú)立于任何組織的開發(fā)環(huán)境、編程語言的選擇、軟件應(yīng)用領(lǐng)域等。傳統(tǒng)的模型是上下文無關(guān)的，而不是和上下文都有聯(lián)系的。但由于

13、這些生命周期的所有模型在使用了一段時間，我們統(tǒng)稱他們?yōu)閭鹘y(tǒng)的模式，刻畫每個轉(zhuǎn)折。2.1 經(jīng)典的軟件生命周期模型經(jīng)典的軟件生命周期通常表示為一個簡單的規(guī)范瀑布軟件階段模型，即從一個階段有序的過渡到下一個階段。這種模式類似于描述軟件開發(fā)的有窮狀態(tài)機(jī)。但是，這些模型對于在復(fù)雜的組織環(huán)境下架構(gòu)，分配人員和管理大型的軟件開發(fā)項(xiàng)目中已經(jīng)也許是最有用的了，這就是它的主要目的所在。另外，這些經(jīng)典模型已被廣泛用來描述如何開發(fā)小型或者大型的軟件項(xiàng)目。2.2 逐步細(xì)化在這種方法中，軟件系統(tǒng)的開發(fā)是通過逐步完善和由高層次的系統(tǒng)規(guī)格說明書升級到源代碼組件實(shí)現(xiàn)的。不過，至于選擇那一個步驟以及運(yùn)用哪一種升級辦法，這些仍然沒

14、有言明。相反，在越來越多的工程實(shí)踐中，隨著不斷地反思和學(xué)習(xí)并應(yīng)用這些方法，規(guī)范必定會出現(xiàn)。在指導(dǎo)程序員如何組織軟件開發(fā)工作的過程中，這一模式已被廣泛有效深入的應(yīng)用。經(jīng)典的軟件生命周期的許多說法也在他們的設(shè)計(jì)和實(shí)現(xiàn)過程中得到闡釋。2.3 替代傳統(tǒng)的軟件生命周期模型至少有三種可供選擇的軟件開發(fā)模型，這些模型都是傳統(tǒng)的軟件生命周期模型。它們關(guān)注的重點(diǎn)在于產(chǎn)品，開發(fā)過程，軟件的開發(fā)環(huán)境?？偟膩碚f，這些模型是細(xì)粒度，通常計(jì)算形式化的要點(diǎn)描述得很詳細(xì)，往往以實(shí)證基礎(chǔ)，有時也闡述一些新的能促進(jìn)軟件開發(fā)的自動化技術(shù)。4 軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻(xiàn)3 軟件產(chǎn)品開發(fā)模型軟件產(chǎn)品代表了信息密集化的手工產(chǎn)品，

15、經(jīng)歷了逐步設(shè)計(jì)并通過反復(fù)修改的開發(fā)工作才完成的。這一過程可以使用軟件產(chǎn)品的生命周期模型來說明。這些產(chǎn)品開發(fā)模型代表了基于傳統(tǒng)的軟件生命周期模型上的漸進(jìn)式開發(fā)模式。由于新的軟件開發(fā)技術(shù)，諸如軟件原型語言和環(huán)境，可重用的軟件，應(yīng)用類，和文件支持環(huán)境的出現(xiàn)，這些模型才產(chǎn)生。這些技術(shù)旨在使每一個可執(zhí)行的軟件實(shí)施步驟提前完成。因此，這樣看來，軟件設(shè)計(jì)模式隱含于技術(shù)的實(shí)踐中，而不是明確的闡述。這是可能的，因?yàn)檫@些模式在那些有經(jīng)驗(yàn)的開發(fā)人員的實(shí)踐中顯得越來越直觀。因此，當(dāng)這些技術(shù)應(yīng)用于工程實(shí)踐中，才是核查這些模型最合適的時候。3.1 快速原型和聯(lián)合應(yīng)用開發(fā)原型是在軟件系統(tǒng)開發(fā)初期，提供精簡功能或有限版本性能

16、的技術(shù)（巴爾澤 1983年，布德 1984 年，Hekmatpour 1987 年）。相對于傳統(tǒng)的系統(tǒng)生命周期，原型是一種更著重于軟件開發(fā)早期階段（需求分析和功能設(shè)計(jì)）的策略。反過來，原型在定義、確定以及評估新系統(tǒng)的功能時就要更多的用戶參與。因此，這些努力的前期任務(wù)，再加上原型技術(shù)的運(yùn)用，都旨在權(quán)衡或減少后期的軟件設(shè)計(jì)任務(wù)，并簡化軟件開發(fā)工作。軟件原型有多種不同的形式，包括一次性原型，實(shí)物原型，示范系統(tǒng)，快速原型，漸進(jìn)式原型（Hekmatpour 1987 年）。增加的功能和隨后的演化性是區(qū)分這些原型形式的所在?？焖僭图夹g(shù)通常以軟件功能說明書的形式作為其出發(fā)點(diǎn)，而這反過來是模擬，分析，或直接

17、執(zhí)行。這些技術(shù)可以讓開發(fā)人員能夠快速構(gòu)建軟件的早期或原始版本系統(tǒng)，用戶就可以評估。用戶評價后可以進(jìn)一步作為反饋，進(jìn)而改進(jìn)系統(tǒng)規(guī)格說明和設(shè)計(jì)。此外，根據(jù)原型技術(shù)，完整的軟件開發(fā)工作可以通過不斷的開發(fā)修改/精煉已有的規(guī)格說明。這就一向提供了有利的系統(tǒng)工作版本，來重新定義軟件設(shè)計(jì)和測試方案，使得規(guī)范說明不斷完善并得以執(zhí)行。另外，其他原型方法最適合發(fā)展一次性或演示系統(tǒng)，或者通過復(fù)用部分/所有的已有軟件系統(tǒng)來構(gòu)造原型。其次，為什么現(xiàn)代軟件開發(fā)模式比如螺旋模型和 ISO 12207 預(yù)期原型將是一個共同的活動，其有利于捕捉和完善軟件需求，以及全面的軟件開發(fā)，這樣看來就變得很清楚了。5 軟件系統(tǒng)開發(fā)中英文對

18、照外文翻譯文獻(xiàn)參考文獻(xiàn)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 軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻(xiàn)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 軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻(xiàn) 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 軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻(xiàn) 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 軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻(xiàn)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 軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻(xiàn)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 軟件系統(tǒng)開發(fā)中英文對照外文翻譯文獻(xiàn)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