外文翻譯軟件過(guò)程模型

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

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

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

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

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

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

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

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

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

10、動(dòng)可能包括下面的任務(wù)行動(dòng)： 開(kāi)發(fā)系統(tǒng)的一個(gè)非正式的規(guī)范. 確定對(duì)象和它們的屬性. 確定行動(dòng)的對(duì)象. 確定對(duì)象之間，屬性或操作的接口. 實(shí)施行動(dòng).顯然，在增量模型逐步走向面向?qū)ο筌浖O(shè)計(jì)的過(guò)程中，這種行動(dòng)可能帶來(lái)多次迭代序列和非序列化的簡(jiǎn)單活動(dòng).任務(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).因此，這種開(kāi)發(fā)結(jié)構(gòu)闡釋了如何開(kāi)發(fā)，使用和維護(hù)軟件系統(tǒng).但是，指令性任務(wù)鏈及其活動(dòng)不能保證預(yù)期所有可能的情況會(huì)出現(xiàn)在軟件開(kāi)發(fā)過(guò)程中（bendifallah 1989年，mi

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

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

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

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

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

16、，原型在定義、確定以及評(píng)估新系統(tǒng)的功能時(shí)就要更多的用戶參與.因此，這些努力的前期任務(wù)，再加上原型技術(shù)的運(yùn)用，都旨在權(quán)衡或減少后期的軟件設(shè)計(jì)任務(wù)，并簡(jiǎn)化軟件開(kāi)發(fā)工作. 軟件原型有多種不同的形式，包括一次性原型，實(shí)物原型，示范系統(tǒng)，快速原型，漸進(jìn)式原型（hekmatpour 1987年）.增加的功能和隨后的演化性是區(qū)分這些原型形式的所在.快速原型技術(shù)通常以軟件功能說(shuō)明書(shū)的形式作為其出發(fā)點(diǎn)，而這反過(guò)來(lái)是模擬，分析，或直接執(zhí)行.這些技術(shù)可以讓開(kāi)發(fā)人員能夠快速構(gòu)建軟件的早期或原始版本系統(tǒng)，用戶就可以評(píng)估.用戶評(píng)價(jià)后可以進(jìn)一步作為反饋，進(jìn)而改進(jìn)系統(tǒng)規(guī)格說(shuō)明和設(shè)計(jì).此外，根據(jù)原型技術(shù)，完整的軟件開(kāi)發(fā)工作可以

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