在實踐中應用系統(tǒng)開發(fā)方法

1、在實踐中應用系統(tǒng)開發(fā)方法1.引言系統(tǒng)開發(fā)方法已經(jīng)被爭議的討論很長時間了，但在基礎上仍然是一個缺乏知識和理解的， 系統(tǒng)的開發(fā)實際上是如何在實踐中進行的，如何用于系統(tǒng)開發(fā)的方法和方法，進行到什么程 度，他們被用作實證研究文學而提出（弗洛伊德，1986; Nandhakumar Avison，1999年）。本 文的目的是為了促進這種認識它報告的方式和程度，Rational的統(tǒng)一過程（RUP）是在兩個 商業(yè)開發(fā)項目中使用。RUP被視為一個國家的最先進的，面向?qū)ο螅攸c對迭代和增量開發(fā)功能的方法，并已 作為一個未完成的項目，預算和時間的超支，系統(tǒng)錯誤等問題的系統(tǒng)開發(fā)的解決方案推動缺 乏功能（貝姆，198

2、8年;雅各布森等，1999）的系統(tǒng)。本文提出了一種在一家咨詢公司的實證案例研究，案例研究是根據(jù)采訪經(jīng)驗的項目經(jīng)理 和系統(tǒng)開發(fā)商，誰在這兩個項目參加。本文的結構如下：第二節(jié)介紹背景及相關工作研究。 第三節(jié)介紹的概念框架，這是用來分析從個案研究的實證結果。在第四節(jié)解釋RUP和第五 節(jié)中描述的研究方法，以用于數(shù)據(jù)收集和分析。第六節(jié)的案例研究和第七節(jié)包含了實證結果 的討論。最后一節(jié)總結從我們調(diào)查的主要結論。2.背景系統(tǒng)開發(fā)文學的重要組成部分，涉及方法的發(fā)展。許多書籍提供了不同的方法，指定關 于如何開發(fā)系統(tǒng)的指令性準則的廣大。這些方法的基礎上和大型系統(tǒng)的開發(fā)是一個理性的， 目標驅(qū)動的假設和管理的過程，它

3、是理所當然地認為有需要為推動這一進程的方法（Truex 等，2000）。理論命題是，使用方法，降低了生產(chǎn)時間和復雜性，提高了開發(fā)進程以及作為 最終系統(tǒng)的質(zhì)量。另一個流文學，涉及有條不紊系統(tǒng)的發(fā)展。Truex等創(chuàng)造的任期內(nèi)有條不紊。（2000）不 涉及反方法或方法系統(tǒng)開發(fā)的方法，而是提出了批評方法文學，正如作者所說的那樣，這意 味著沒有嚴格的預定義的結構系統(tǒng)開發(fā)的管理和業(yè)務流程，順序控制性，合理性或普遍性的 要求，但它并不意味著混亂或無政府狀態(tài)。主要論點是指令性方法背后的假設并不像如何在 實踐中進行系統(tǒng)開發(fā)。據(jù)有條不紊認為系統(tǒng)開發(fā)是一個獨特的，談判的和機會主義的過程， 并具有意外帶動作用（Tru

4、ex等，2000）。這種立場較早前已制定弗洛伊德等。（1989年）的 Kautz（1993）使用進化系統(tǒng)開發(fā)的概念，此外，最近已為自適應（海史密斯三，2000年） 或敏捷開發(fā)（科伯恩，2002年）重新構造，這種觀點也支持通過實證研究表明，系統(tǒng)開發(fā)， 可以作為一個有點有條不紊的活動，形式化方法不使用全部或只有特定的工具或技術，從一 個特定的方法是使用（Bansler B.dker， 1993特點;菲茨杰拉德，1997年，1998年）?；谒麄兊牡难芯浚˙ansler B.dker，1993）的結論是結構性的分析方法是如何提出的文 學，以及它是如何在實踐中使用之間是有很大的差距o Stolterm

5、an（1994）和杰拉德（1997） 進一步報告說，適應有經(jīng)驗的開發(fā)和應用，以務實的方式方法。系統(tǒng)開發(fā)定制的方法在手的 項目，省略方法方面，這是太費時，繁瑣或特殊情況無關。還指示和說明性的方法之間的問 題的關系實踐中，Wastell（1996年）在使用嚴格的結構化分析與設計方法（SSADM）從個 案研究報告。然而，而不是改善發(fā)展過程中，該方法抑制創(chuàng)造性思維，造成開發(fā)商注重細節(jié)， 而不是對項目的總體目標。最近已獲得有關系統(tǒng)開發(fā)方法的討論再次在Web開發(fā)方面的利益。文學流認為，傳統(tǒng) 的開發(fā)方法是web開發(fā)的適用（陳等，1999; MURUGESAN Deshpande說，2001年），而另一 個流

6、認為，基于網(wǎng)絡系統(tǒng)的發(fā)展是根本不同的，因此，需要全新的方法和途徑（Braa等人， 2000年格林鮑姆和Stuedahl，2000巴斯克維爾與Pries Heje，2001年;卡斯特森Vogelsang公 司，2001）。之前這些極端已提出面向Web前端開發(fā)（用戶界面），需要新的方法和途徑， 但后端導向和技術上復雜的web開發(fā)（功能）要求（新聞記者，1998年）的傳統(tǒng)方法得到 埃里克森（2000）的支持?；趯嵶C研究，他得出結論后端功能的發(fā)展，傳統(tǒng)的開發(fā)方法是 有用的，但基于Web的前端方面提供一些指導。在這種情況下，研究這兩個項目分別為大型后端導向的Web項目。然而，由于其規(guī)模 和復雜性，我們

7、不認為他們有什么不同，從傳統(tǒng)的系統(tǒng)開發(fā)項目，下面我們將參照等?？蚣苎芯勘姸嗟母拍?，方法和方法的定義存在（Avison菲茨杰拉德，1995年）。分析的結果，從 我們的案例研究，我們借鑒Mathiassen等人（1990）定義一個方法二。他們定義為一個有 紀律的方法，結構化的方式來解決問題，特點是（1）它的應用領域，（2）底層的角度（3） 的指導方針和執(zhí)行過程，A）技術的幫助B）工具和C）組織原則。一個方法有一個應用領域，它是合適的依賴于信息系統(tǒng)的類型，項目規(guī)模，團隊規(guī)模等， 此外，一種方法是基于一個基本的觀點，即一套假設，這些假設確定類型的解決方案，提出 的方法更實際的層面等類型的問題，這是要求

8、分析手頭的問題，由有關的技術，工具和組織 原則的指引。技術說明應如何采取的一項活動，工具與技術，以確?；顒拥淖钣行У姆绞竭M 行。組織原則表明人士和團體應如何共同努力，如何分配有限的資源應。組織的原則是：該 項目劃分為階段和用戶參與的指導方針。統(tǒng)一建模文獻中的條款方法論和方法的辯論，但他們的區(qū)別特征的討論并不是本文的一部分。對 于本文的目的，我們將使用術語可以互換。在1990年代初期的一個不同的大型數(shù)字對象導 向的方法已經(jīng)出現(xiàn)。雅各布森，Booch的和南姆勃每一個創(chuàng)作自己的方法，但在90年代中 期，他們加入軍隊要統(tǒng)一成一個一致的建模語言現(xiàn)稱為“統(tǒng)一建模語言UML）”，其不同的 符號。他們繼續(xù)合作

9、進一步統(tǒng)一到理性的統(tǒng)一過程，一個完整的過程模型，聲稱支持整個系 統(tǒng)開發(fā)生命周期（雅各布森等人，1999年）有關系統(tǒng)開發(fā)的主流觀念。最初的RUP開發(fā)傳統(tǒng)和大型系統(tǒng)的開發(fā)，但它不僅是一個單一的過程。RUP提供了一 個通用的過程框架，可定制，以適應許多不同項目，不同類型的組織，不同層次的能力和不 同的項目大小（雅各布森等人，1999年）。因此，RUP的應用領域是自稱是十分廣闊的。RUP是作為驅(qū)動的情況下使用的特點，體系結構為中心，迭代和增量的過程模型，用例 定義系統(tǒng)的功能，每個用例描述，該系統(tǒng)將執(zhí)行結果提供用戶通過一步一步的行動。使用案 件正在使用的要求規(guī)范和分裂成適合和管理的增量項目，對于每一個增

10、量的最重要的活動之 一，是尋找，測試和評估架構，即技術系統(tǒng)設計的基礎設施，組件和接口組成，彌補系統(tǒng)。RUP術語包含4個階段，所謂的初始，細化，建設和過渡階段。起始階段和細化階段上， 也有工程設計階段，并在這些階段的分析，設計和規(guī)劃開展活動。在建設和過渡階段，也被 稱為生產(chǎn)階段，進行編碼，測試和部署活動。一個項目分成若干迭代，每個迭代的項目通過 所有四個階段。此外，RUP是基于增量的編碼，這意味著，每一次迭代的增量，即一部分， 超過所有的系統(tǒng)要經(jīng)過四個階段。這使得項目團隊結合的經(jīng)驗教訓，下一次迭代開始時的想 法是幫助項目團隊及時發(fā)現(xiàn)的主要障礙。因此，RUP的剪裁迭代和增量的過程和選擇工具和 技術

11、，以適應一個給定的項目提供了框架。RUP在起始階段和細化階段主要關注圖表和文字說明寫作的創(chuàng)作上的文件和活動的強 烈關注。UML符號和軟件程序的Rational Rose，支持這項工作。研究方法本文提出的研究從個案研究顧問公司在挪威，在兩個項目中使用RUP的經(jīng)驗數(shù)據(jù)為基 礎。案例研究包括七個采訪，每個采訪持續(xù)了45-90分鐘，與會者主任工藝和技術負責該公 司的系統(tǒng)開發(fā)方法，一個方法顧問，兩名項目經(jīng)理，首席程序員和兩個系統(tǒng)的開發(fā)。與會者 涵蓋了廣泛的系統(tǒng)開發(fā)中的角色和活動范圍和4-10之間多年的經(jīng)驗與系統(tǒng)開發(fā)項目。指更 一般的長期顧問向與會者。進行數(shù)據(jù)收集，使用半結構式訪談，每個采訪錄音。訪談面試

12、指南，這對他們的經(jīng)驗 與RUP作為一個發(fā)展的角度以及其技術，工具和組織原則，重點圍繞結構。已進行面試后，被確定的主要議題，并寫了一個詳細的記錄，每個接受記者采訪時描述， 每個參與者收到了該帳戶的校正和批準的副本。此外，管理概要列出的主要議題和結論寫案 例研究，這也被送往校正和批準的參與者。用例在一個大型的顧問公司進行的案例研究，與500多名員工和相當豐富的經(jīng)驗，系統(tǒng)開發(fā)。 RUP的“正式”公司在2001年1月推出。高層管理人員已決定RUP的開始，應采取通過試點 項目的數(shù)量，并在公司層面的RUP必須適應公司的系統(tǒng)開發(fā)方法。因此，何時以及如何使 用RUP發(fā)展的指導方針。然而，這項研究是在2001年

13、10月進行的管理決策，就引入了 RUP 沒有被清楚地傳達組織和準則的制定和正式的RUP適應尚未發(fā)生。案例研究關注的經(jīng)驗，采訪顧問獲得了同時使用兩個大型項目，項目A和B A計劃歷時 12個月，涉及18人的RUP。在采訪時，該項目最終交付給客戶的準備。團隊成員中有9人 顧問公司，包括項目經(jīng)理。其他九人小組成員分別從大型ERP系統(tǒng)，這構成了該項目的基礎 上軟件供應商。顧問公司對項目的總體責任。此外，他們有責任為表現(xiàn)層，即前端的設計和 編碼，表示層和后端數(shù)據(jù)集成。供應商的后端和表示層提供數(shù)據(jù)的責任。項目B在2001年5月開始，該項目的第一階段剛剛結束，在這種情況下，研究訪談進 行October.12人

14、曾參與的項目，這些全職工作6。項目B預計將持續(xù)15個月，將涉及約10 人，全職。隨著項目的RUP方面是由于內(nèi)部不妨試試這種方法的開發(fā)方法的選擇，而為項目B RUP 的選擇，因為從客戶的要求。下面的經(jīng)驗，這兩個項目團隊與RUP的將提交描述將根據(jù)RUP 的以下特點：發(fā)展情況的文件，迭代，用例，架構，文件，作為承上啟下的RUP的正式開 發(fā)合同關系結構。7.研究討論采訪顧問，盡管經(jīng)歷了與RUP的使用困難，他們都表示，他們有正面印象的方法，并 想再次使用它。然而，他們的經(jīng)驗與Mathiassen等人（1990）的定義是什么方法的特點進 行比較時，項目團隊只用了 2 5的特點。在A和B兩個項目已經(jīng)從RUP

15、的技術和模板使用， 但該項目的團隊，盡管他們曾計劃和企圖-沒有成功使用RUP結構的發(fā)展過程和底層開發(fā)的 角度來看，他們并沒有采取。RUP中沒有被用于剪裁和管理一個迭代和增量的過程，而是兩個項目正在調(diào)查結束后， 傳統(tǒng)的發(fā)展過程，即瀑布模型，輔以從RUP的工具和技術。RUP的主要是用來作為工具箱， 工具和技術，以務實的方式選擇和應用，這是保持與菲茨杰拉德（1998年），誰的結論是， 系統(tǒng)開發(fā)方法在實踐中最明顯的貢獻，作為一個工具箱，而不是作為一個過程的框架。它還 支持Truex等。（2000年），他認為，系統(tǒng)的發(fā)展是一種投機取巧，談判和妥協(xié)的活動， 這不遵循理性的理想的一個預定義的過程。在本研究中

16、的機會主義，妥協(xié)和談判成為通過開 發(fā)人員和客戶缺乏明顯和可見經(jīng)驗與方法，合同的情況和客戶的普遍行為。是否與RUP更有經(jīng)驗的項目團隊可避免所描述的情況，但是有受到質(zhì)疑。項目成員后， 都非常有經(jīng)驗的IT專業(yè)人員。因此，開發(fā)合同的作用和客戶重新我們的案例研究表明，作 為一個學習的過程造成困難時，按固定價格合同進行系統(tǒng)開發(fā)的迭代系統(tǒng)開發(fā)的開發(fā)和明確 重點。這種類型的合同，必須嚴格控制成本，從而抑制了真正的學習和基于對中間的發(fā)展過 程中，不完全記錄規(guī)范。Mathiassen與Bjerknes（2000）提出了類似的觀點，并討論了合同 和承包商的客戶關系方面的信任和控制之間的平衡。雖然信任促進創(chuàng)造力和相互

17、學習，促進 合同決定，并根據(jù)該協(xié)議的進展情況的監(jiān)測。Mathiassen與Bjerknes（2000），因此建議， 有一個需要調(diào)整的關系之間的信任和控制，以創(chuàng)建學習環(huán)境，他們的結論是，這是不可能提 高系統(tǒng)發(fā)展的做法不改變目前的合同形式。本案例研究支持這一論點。mathiassen與Bjerknes（2000）的原因更多的顧客，供應商聯(lián)絡。客戶在我們的例子中 有一個項目的過程和方法利用的巨大影響力。他們有不同的理解方法，他們只有部分在增量 發(fā)展和有利于詳細的書面作為不同階段的結果規(guī)格更感興趣。在一個項目中他們甚至提出1 技術，建筑的決定，在與該方法的發(fā)展方式發(fā)生沖突。在這樣的環(huán)境，發(fā)展組織和開發(fā)

18、商中 所述的方法指引和自己的打算，不能適用的方法。他們不得不做出讓步，通過談判找到一 個務實和切實可行的辦法，以提供所要求的產(chǎn)品，由于我們的情況表明，系統(tǒng)的發(fā)展重新考 慮客戶與供應商的關系，加強實踐。作為一個面向?qū)ο蠛偷ǖ腞UP已銷售系統(tǒng)開發(fā)中的問題的解決。但現(xiàn)在看來，即 使RUP是聲稱自己是一個看似廣闊的應用領域的現(xiàn)代方法，它沒有重視上下文中的商業(yè)系 統(tǒng)發(fā)展需要的地方。然而，無論是可行的，納入在一個方法執(zhí)行系統(tǒng)開發(fā)的所有活動是毋庸 置疑的。科伯恩（2002年），我們的研究表明，系統(tǒng)開發(fā)，如實際執(zhí)行，如1復雜的過程， 它可以不被準確描述。如果可以，沒有人會是能夠來讀這樣復雜的描述和從中吸取教