Abstrak
Proses pengembangan perangkat lunak tradisional untuk mengembangkan aplikasi Web. Kita akan merumuskan enam persyaratan dasar untuk proses pengembangan aplikasi Web. Persyaratan ini akan digunakan untuk mengevaluasi berat dan proses kritis, dan kegunaannya untuk pengembangan aplikasi Web. Secara khusus, kami akan mengevaluasi Rational Unified Process (RUP) sebagai wakil dari model proses kelas berat dan Extreme Programming (XP) sebagai wakil dari model proses tangkas. Kami akan berkonsentrasi pada proses sebenarnya, yaitu, bagaimana proses pembangunan diatur, mengabaikan metode yang mendasarinya. Kita akan menunjukkan bahwa baik dari dua pendekatan proses mampu memenuhi semua persyaratan. Proses kekuatan kelas berat adalah daya adaptasi pada kompleksitas aplikasi di bawah pembangunan. Sebaliknya, kekuatan proses tangkas adalah bagaimana mereka menangani pengembangan pendek siklus dan persyaratan baru atau berubah. Sebagai hasil dari perkenalan dari proses meta-untuk mengintegrasikan keuntungan dari kedua model proses. Web ini berkembang dari sebuah media informasi murni menjadi media aplikasi (Ginigedan Murugesan 2001a, Murugesan et al. 1999). Kecenderungan dalam aplikasi Web adalah menuju penuh, sistem perangkat lunak yang kompleks. Pentingnya sebuah teratur dan terstruktur dengan baik proses pembangunan tumbuh sebagai kompleksitas dari aplikasi Web dalam pengembangan.
Kata kunci : web, pengembangan, model proses, rup, xp, aplikasi, perangkat lunak, siklus, persyaratan, penerbitan, reuse, integrasi, program extreme
1.Pendahuluan
Sebagian besar pengembangan pendekatan dipraktekkan saat ini terlalu pragmatis (McDonald dan Welland 2001a). Meskipun hal ini menyebabkan waktu pengembangan yang singkat, pendekatan seperti itu sering "Cepat dan kotor" metode. Konsekuensi adalah masalah operasi dan pemeliharaan akibat rendahnya kualitas aplikasi Web. rekayasa Web adalah disiplin yang sangat muda dan belum memiliki model sendiri proses pembangunan. proses model dan metode menjelaskan bagaimana suatu proyek pengembangan perangkat lunak berlangsung. Namun, model proses menggambarkan pendekatan dalam konteks keseluruhan, sedangkan metode yang menggambarkan pendekatan secara rinci. Cara termudah untuk melihat perbedaan adalah dengan melihat ciri-ciri umum. Kedua pendekatan secara rinci dan pendekatan dalam konteks keseluruhan menetapkan cara untuk mencapai tujuan tertentu dan bagaimana mereka dipengaruhi oleh kondisi sisi yang dapat dideduksi dari dependensi antara langkah-langkah tertentu dan eksternal kondisi.
Suatu pengembangan proyek perangkat lunak, konten-aspek khusus ditangani dengan metode, sedangkan proses kesepakatan dengan aspek organisasi. Ini berarti bahwa metode pasokan jawaban atas pertanyaan-pertanyaan tentang bagaimana sesuatu harus dilakukan, dan ketika dapat dilaksanakan dengan konten-aspek tertentu. Sebaliknya, model proses menggambarkan sesuatu ketika harus dilakukan di bawah aspek organisasi. Menurut sudut pandang ini, suatu proses yang menyediakan panduan bagi insinyur perangkat lunak pada urutan berbagai
metode harus dilakukan keluar dalam proyek pengembangan.
1). Proses ini adalah kerangka kerja untuk mengelola pengembangan dan pemeliharaan, dalam hal itu memungkinkan para pengembang untuk memperkirakan sumber daya, monitor kemajuan, dll derajat kebebasan untuk keputusan dalam proses dibatasi oleh mendasari metode, karena proses harus mengambil dependensi metodologis ke rekening. Sebaliknya, organisasi kebutuhan seperti kebutuhan orang yang berpartisipasi dalam sebuah proyek untuk berkomunikasi menentukan persyaratan pada metode. Ini adalah alasan mengapa proses dan metode yang harus dikoordinasikan.
Gambar 1. proses dengan metode pada project pengembangan software
Properti penting dari proses pengembangan perangkat lunak modern adalah bahwa mereka iteratif. Ide dasarnya adalah untuk mengembangkan sistem perangkat lunak secara bertahap dari hasil awal ke final produk dalam beberapa iterasi. Selain iterasi, pilihan kedua untuk membagi suatu proses yang fase. Fase yaitu definisi kebutuhan, analisis, perancangan, implementasi, pengujian, dan pemeliharaan. Hal ini sesuai dengan pendekatan sesuai dengan model air terjun tradisional, di mana kegiatan metodologis mengikuti satu sama lain secara linier.
Gambar 2. Iterasi pengembangan software
Masalah dari pendekatan ini adalah bahwa penanganan risiko ditunda ke masa depan. Ketika potensi risiko benar-benar terjadi, maka biaya untuk menghapus kesalahan meningkat sejalan dengan waktu yang berlalu sampai tertangkap. Pendekatan berorientasi fase merupakan cara untuk memecahkan masalah ini. Dalam pendekatan fase-berorientasi, sebuah fase menunjuk rentang waktu antara dua tonggak dari sebuah proyek pengembangan perangkat lunak.
Proses perangkat lunak terkenal pembangunan dapat dikelompokkan menjadi dua kategori:
Proses ringan yang dikenal sebagai agile proses
proses ini yang cocok untuk aplikasi yang lebih kecil dan tim pengembangan sesuai yang lebih kecil.
Proses berat
Yang mengacu pada tingkat formalisasi proses, yaitu, berapa banyak dokumen dan model diciptakan. Proses ini digunakan terutama ketika tim besar mengembangkan aplikasi dengan tinggi tuntutan pada kualitas.
2. Persyaratan Proses Pengembangan Aplikasi Web
Enam persyaratan yang paling penting untuk proses pengembangan aplikasi Web :
1. Penanganan pengembangan siklus pendek
2. Penanganan perubahan kebutuhan
3. Melepaskan batas waktu dan isi yang fleksibel
4. Pengembangan parallel dari release yang berbeda
5. Penggunaan kembali dan integrasi
6. Mengadaptasi level kompleksitas web aplikasi
Banyak karakteristik yang khas untuk proses pengembangan aplikasi Web juga dapat ditemukan dalam proses pengembangan perangkat lunak tradisional, hanya kejadian dan intensitas yang berbeda (Ramesh et al 2002.). Sebagai contoh, hampir setiap proyek pengembangan perangkat lunak berada di bawah tekanan waktu, dan perubahan persyaratan yang sangat umum. Intensitas khusus karakteristik ini dalam pengembangan aplikasi Web mengarah pada situasi di mana tipe yang berbeda dari rencana rilis telah terbukti berguna, setidaknya pada tahap awal pembangunan di mana aplikasi Web memiliki tingkat kompleksitas rendah.
Sebuah aplikasi Web harus dipublikasikan sesegera mungkin perspektif jangka panjang mengabaikan. Hal ini menyebabkan aplikasi web dengan tingkat kompleksitas kecil di tahap awal pengembangan. Tingkat kompleksitas yang lebih tinggi akan menghindari publikasi awal. Sebagai perspektif jangka panjang lebih banyak dan lebih terintegrasi ke dalam aplikasi Web meningkatkan tingkat kompleksitas dan aplikasi Web yang ada yang harus diganti dengan rilis baru. Hal ini difasilitasi dengan cara sederhana bahwa rilis baru dapat diterbitkan dan tersedia bagi pengguna-akhir.
3. Penanganan Siklus Pengembangan Pendek
Fakta yang ditemukan dalam studi empiris adalah bahwa beberapa waktu pengembangan aplikasi Web sangat singkat, tetapi biasanya tidak melebihi enam bulan, dan durasi rata-rata kurang dari tiga bulan (McDonald dan Welland 2001a, 2001b McDonald dan Welland). Pendek ini siklus pengembangan yang sangat khas untuk aplikasi Web yang dapat diasumsikan untuk menjadi yang pertama persyaratan untuk proses aplikasi pengembangan Web. Kehadiran langsung diberikan prioritas di atas perspektif jangka panjang (Pressman 1998). Web adalah sebuah pasar internasional dengan ukuran yang tidak dapat diestimasi dengan andal. Selain itu, ada kebutuhan ekstrim untuk
menjadi lebih cepat daripada yang lain di pasar untuk memastikan pangsa pasar yang cukup (Ramesh et al. 2002). Itu "Mekanisme pengiriman instan" yang melekat pada sifat dari Web memungkinkan untuk mempublikasikan produk segera dan akibatnya memberlakukan keharusan ini. Sebuah baru fungsi diperkenalkan oleh pesaing untuk pertama kalinya menyebabkan tekanan besar bagi orang lain juga menawarkan fungsi ini. Jika tidak, mungkin ada risiko untuk cepat kehilangan pasar yang besar berbagi, karena Web adalah media yang memerlukan kewajiban (Holck dan Clemmensen 2002).
Pelanggan tidak dapat diharapkan untuk setia kepada vendor Web tunggal ketika kompetisi hanya klik mouse jauh. Hal ini bahwa banyak aplikasi Web adalah instrumen pemasaran.
4. Penerbitan dengan Tenggat waktu Tetap dan Isi Fleksibel
Sebuah konsekuensi tidak langsung dari persyaratan terakhir adalah keharusan untuk menggunakan jenis khusus prototyping dalam proses pembangunan. Lebih khusus lagi, "sekali pakai" rilis dikembangkan terhadap detail dan memvalidasi persyaratan pelanggan. Beberapa penulis, termasuk Lowe (2002) dan McDonald dan Welland (2001b), telah menemukan bahwa cara eksploratif mengembangkan spesifikasi sistem telah menjadi praktek umum. Pelanggan menggambarkan fungsi dasar, dan prototipe dengan cepat dikembangkan untuk tujuan demonstrasi. Ini berarti bahwa prototyping drive komunikasi dengan pelanggan. Berbeda dengan perangkat lunak konvensional pembangunan, namun, pendekatan ini menghasilkan dan menerbitkan "sekali pakai" rilis dari sebuah Web aplikasi. Sebuah produk yang diterbitkan dapat dengan cepat diganti dengan versi baru. Dari tanggapan publikasi kesimpulan yang menarik dapat ditarik yang membantu untuk lebih mengembangkan persyaratan.
Interval antara rilis tersebut relatif singkat (saat ini antara dua dan lima belas hari) (Ramesh et al. 2002). Rencana waktu untuk urutan rilis dan evaluasi mereka lebih penting daripada perencanaan persyaratan untuk sebuah rilis. Ini berarti bahwa sebuah rilis tidak didefinisikan oleh isi tentukan sebelumnya, tetapi hanya dengan tenggat waktu yang pasti dimana rilis harus siap. Fitur tunggal yang tidak dapat diselesaikan oleh waktu yang hanya pindah ke berikutnya lepaskan. Persyaratan untuk rilis berikutnya harus variabel untuk memperhitungkan terus menerus pasar observasi dan prioritas fitur. Fitur dapat ditunda untuk rilis nanti atau pindah ke yang sebelumnya. Ini biasanya bukan masalah besar karena interval antara rilis pendek dan penyebaran mereka adalah
sederhana dan tidak menimbulkan biaya layak disebut.
Hal lain yang penting adalah bahwa aplikasi web jarang aplikasi kritis (seperti yang dalam perawatan pembedahan atau kesehatan). Berkualitas tinggi persyaratan akan meminta perencanaan yang lebih kuat dari rilis sehubungan dengan tahap pengujian dll rawatan tertentu adalah persyaratan kualitas yang sering diabaikan dalam aplikasi Web. Rawatan tidak kepentingan tertentu jika produk software
dengan cepat digantikan oleh versi baru.
5. Paralel Pengembangan Penerbitan Berbeda
Persaingan sengit mendorong pesaing untuk mempersingkat siklus rilis. Di bawah ini jenis tekanan waktu, hanya tumpang tindih atau proyek pembangunan paralel dapat menyebabkan distribusi lengkap aplikasi atau rilis dalam waktu. Ini berarti bahwa metodologi kegiatan dalam desain, implementasi, dan kualitas jaminan fase yang bekerja pada bersamaan untuk rilis yang berbeda. Secara umum, beberapa tim pengembangan kecil bekerja pada tugas yang sama di paralel (McDonald dan Welland 2001b). Hal ini menyebabkan persyaratan baru pada perencanaan penyebaran staf di proyek-proyek pengembangan aplikasi Web. Oleh karena itu, overhead komunikasi sangat luas dalam pengembangan aplikasi Web
.
6. Penanganan Mengubah Persyaratan
Titik sangat terkait dengan kebutuhan sebelumnya adalah fakta bahwa persyaratan untuk Web yang aplikasi sering muncul hanya selama perkembangannya, atau bahwa mereka tunduk pada perubahan besar berkaitan dengan baik konten dan teknologi. Setelah semua, pengembang sering harus berurusan dengan bidang yang tidak diketahui dari bisnis dan kebutuhan bisnis dapat berubah secara dramatis sebagai pengembang memperoleh pemahaman yang lebih baik dari bisnis yang dalam perjalanan proyek (Ramesh et al. 2002). Persyaratan baru yang dihasilkan dari situasi pasar berubah harus diintegrasikan cepat untuk mencegah persaingan dari mendapatkan keunggulan kompetitif. Sebagai konsekuensi dari fokus dijelaskan pada perkembangan yang cepat, sering tidak mungkin untuk tepat menentukan persyaratan. Persyaratan tidak lengkap atau ambigu harus diterima. Sejak tidak dapat diasumsikan bahwa persyaratan akan tetap stabil, tentang diri sendiri lebih dari diperlukan dengan mereka tampaknya tidak menjadi bermanfaat. Sebuah analisis rinci dari sebuah aplikasi Web kelompok pengguna diperlukan untuk menetapkan persyaratan yang stabil, tetapi biasanya lebih realistis, karena kelompok pengguna biasanya ditandai dengan heterogenitas tak terhitung. Karena fakta bahwa produk perangkat lunak (atau bagian dari itu)
dapat segera didistribusikan, hal itu malah menjadi umum berlatih untuk menarik kesimpulan tentang persyaratan yang sebenarnya dari pengguna akhir tanggapan terhadap diterbitkan bagian dari aplikasi Web. Bahkan jika temuan baru menunjukkan bahwa sebagian fungsionalitas tidak ada lagi muncul diperlukan atau penting, mereka biasanya diterbitkan namun dalam upaya untuk menarik pasar (Ramesh et al. 2002). Banyak pelanggan merasa jauh lebih sulit untuk merumuskan kebutuhan mereka untuk proyek web dari untuk proyek-proyek pengembangan perangkat lunak lainnya, karena mereka tidak akrab dengan masalah tertentu domain dan potensi solusi (Lowe 2002). Ini adalah alasan mengapa pengembangan aplikasi Web Proses sering memiliki fokus sedikit bias (Crane dan Clyde 1999, Fournier 1998) dalam bahwa mereka juga harus membangun pemahaman dari domain masalah. Selain itu, seringkali sulit untuk melihat nilai tambah potensial yang dicapai dengan mengembangkan fungsionalitas atau memberikan tertentu Isi (Wallace et al. 2002). Ini membutuhkan pembaruan terus menerus dari bahan data yang ditawarkan oleh aplikasi Web, yang merupakan aspek lain yang mengarah ke perubahan sering ke logika aplikasi persyaratan. Terutama dalam fase awal dari sebuah perubahan aplikasi Web dari bahan data seringkali berarti bahwa data harus direstrukturisasi dan bahwa pelanggan berkualitas tuntutan pada isi perubahan. Selain itu, perubahan permanen juga karena sering update teknologi dan standar. Tekanan kompetitif tinggi yang disebutkan di atas membutuhkan adaptasi terhadap teknologi tersebut dan standar (Kappel et al 2000,. Scharl 2000). Dalam hal ini, penelitian empiris banyak mengeluh tentang kurangnya pengalaman dengan pengembangan jenis produk (Ramesh et al 2002,. McDonald dan Welland 2001b).
7. Reuse dan Integrasi
Salah satu konsekuensi dari tekanan waktu yang sangat besar dalam pengembangan aplikasi Web adalah bahwa pengembang harus mencoba untuk menggunakan kembali sebagai komponen sebanyak mungkin (Ramesh et al. 2002). Hal ini sering menyangkut interoperabilitas dan integrasi dari berbagai komponen yang telah dikembangkan eksternal atau dibeli dari pihak ketiga. Untuk alasan ini, proses pengembangan salah satu aplikasi Web tidak dapat dilakukan di isolasi dari proses pengembangan aplikasi Web lain dalam organisasi yang sama. Jika komponen dapat digunakan kembali dikembangkan dalam sebuah proyek, maka harus dikembangkan dalam koordinasi dengan proyek-proyek pembangunan lainnya yang akan menggunakan komponen ini. Hal yang sama berlaku untuk kebalikannya kasus di mana komponen dari proyek lain
aplikasi Web pembangunan harus digunakan kembali. Juga, sering bermanfaat untuk mengembangkan arsitektur yang umum untuk aplikasi web beberapa. Ini berarti bahwa kita harus berkoordinasi baik hasil yang diinginkan dan pendekatan yang digunakan untuk mencapai mereka. Yang kuat mendatang silang-ketergantungan antara proyek pembangunan Web yang berbeda meningkatkan bahaya masalah menyebar dari satu aplikasi ke yang lain, yang harus ditangani oleh suatu proses. Satu masalah utama adalah bahwa konsep tersedia untuk penggunaan kembali komponen dalam aplikasi Web adalah tidak sepenuhnya matang.
8.Beradaptasi dengan Tingkat
Kompleksitas Web Application bahwa siklus pengembangan yang singkat peringkat lebih tinggi dari beberapa kualitas persyaratan dalam pengembangan aplikasi web. Skalabilitas dan rawatan adalah contoh untuk kualitas yang sering dikesampingkan. Berturut-turut maju fungsi produk yang diterbitkan. Kualitas hilang dalam tahap pengembangan awal diperkenalkan di berikutnya rilis dengan mengganti komponen dan mengembangkan yang baru. Ini adalah lebih baik untuk Rencana rinci dan dokumentasi. Hal ini tampaknya menjadi pendekatan yang berguna sampai tingkat kerumitan tertentu berkaitan dengan baik logika aplikasi dan konten. Namun, sebagai integrasi aplikasi Web ke dalam kemajuan proses bisnis pelanggan, pendekatan ini menjadi lebih dan lebih praktis. Itu pengembangan aplikasi Web ini kemudian tidak lagi dikelola ad-hoc atau tanpa rinci merencanakan karena kompleksitas yang lebih tinggi. Ini berarti bahwa proses pengembangan aplikasi web tergantung pada kompleksitas mereka, pada persyaratan kualitas, dan terakhir pada kategori aplikasi Web. Singkatnya, proses harus dinamis beradaptasi dengan tingkat kompleksitas. Proses harus mirip dengan proses ringan ketika sebuah aplikasi Web memiliki tingkat kompleksitas yang lebih rendah pada awal pengembangan fase. Namun, proses tersebut harus bekerja analogi untuk proses kelas berat ketika aplikasi Web mencapai tingkat kompleksitas yang lebih tinggi dalam tahap perkembangan selanjutnya.
9. Analisis Rational Unified Process (RUP)
Rational Unified Process (RUP) (Jacobson et al 1999.) sebagai perwakilan dari keluarga proses kelas berat, fase-oriented, incremental, dan iteratif. Tujuan dari proses ini adalah untuk mendukung pengembangan produk berkualitas tinggi dalam jangka waktu tertentu dan pada harga tetap. Produk harus merupakan nilai tambah yang jelas bagi pengguna masa depan.
Gambar 3 Empat fase Rational Unified Process
Pendekatan bertahap ini tercermin dalam fase RUP (Kruchten 2003). RUP menetapkan empat tahap yang berbeda untuk proyek pembangunan, dan masing-masing fase ini diatur dalam sejumlah iterasi terpisah. Keempat fase berfokus pada aspek-aspek berbeda dari proses pembangunan. Tiap tahap berakhir dalam tonggak yang digunakan untuk menilai kemajuan proses secara keseluruhan.). Jadi, tahap harus memenuhi kriteria yang didefinisikan dengan baik sebelum fase berikutnya dimulai. Keempat fase itu antara lain:
fase Inception: Pada fase awal, pengembang menetapkan cakupan proyek dan kasus bisnis sistem. Tujuan dari fase ini adalah untuk mengembangkan visi umum dari produk akhir bekerja sama dengan pelanggan dan pengguna sistem yang akan datang. Hal ini mencakup definisi dari persyaratan mendasar, yaitu, membatasi sistem apa yang harus dilakukan terhadap apa yang tidak perlu dilakukan. Ini adalah dasar untuk
pendekatan tambahan. Selain itu, juga mencakup penelaahan atas kelayakan yaitu, arsitektur, minimal, tahap pertama harus menemukan dan bereksperimen dengan arsitektur sesuai dengan persyaratan.
Fase elaboration : Di dalam tahap pengembangan, pengembang meneliti proyek kebutuhan dalam detil lebih besar dan menggambarkan yayasan/pondasi secara ilmu bangunan nya. Gol tahap ini adalah untuk mengeluarkan/meniadakan proyek yang paling tinggi mengambil resiko kepada luas mungkin yang paling luas, sedemikian sehingga suatu harga pasti dapat dirumuskan pada ujung tahap ini. Ini meliputi pemilihan dari suatu arsitektur dapat diperluas dan optimal dan familiarisasi staff dengan teknologi untuk digunakan
Tahap konstruksi: Pada tahap konstruksi, pengembang berkonsentrasi pada menyelesaikan analisis, melakukan sebagian besar desain dan implementasi sistem. Artinya, tahap konstruksi membangun produk dengan berurusan dengan penerapan semua komponen dan integrasi mereka ke dalam satu produk. Produk ini tidak boleh tanpa cacat, karena beberapa pekerjaan lebih lanjut harus selesai dalam tahap transisi. Hasil lain dari tahap ini adalah tes rinci
Transisi fase: Pada fase transisi, pengembang memberikan sistem kepada pengguna. Fase ini menyimpulkan proyek ini dengan mengintegrasikan produk ke dalam lingkungan pengguna.
10.Kesesuaian Umum untuk Pengembangan Aplikasi Web
Bagian ini membahas bagaimana tahapan RUP dapat digunakan untuk pengembangan aplikasi Web. Untuk tujuan ini, kita harus mengevaluasi apakah atau tidak risiko proyek pada tahap awal dapat dikecualikan atau dikurangi sehingga upaya pengembangan tertinggi dalam jangka waktu tertentu dan pada harga tetap dapat diukur pada fase konstruksi antara lain: fase Inception: Definisi dari fase pertama adalah masalah untuk aplikasi Web pembangunan. Sebuah visi beton produk penuh, seperti yang diharapkan oleh RUP, bentuk-bentuk secara bertahap dalam rangka proyek. Sebagai instrumen pemasaran, aplikasi Web memiliki kelompok sasaran, namun kebutuhan kelompok ini tidak diketahui pada awal proyek, dan mereka berubah terus-menerus karena pengaruh pasar
Tahap Elaborasi: fakta bahwa siklus pengembangan yang sangat singkat untuk membangun sebuah versi produk pertama yang memiliki prioritas terhadap mengukur harga tetap untuk produk akhir yang jelas. Alasannya adalah bahwa risiko terkait dengan penggunaan produk perangkat lunak menimbang berat daripada risiko yang melekat dalam pembangunan yang sebenarnya. Tahap konstruksi: Pengembangan aplikasi Web juga memiliki fase di mana pekerjaan konstruksi yang sebenarnya dilakukan. Berdasarkan pembahasan di atas tahap awal, itu hanyalah pertanyaan apakah atau tidak ada bisa menjadi salah satu titik waktu ketika cukup yakin apa yang komponen lainnya masih harus dikembangkan.
Transisi fase: Fase transisi dapat berarti bagi aplikasi Web, juga. Terutama ketika fungsionalitas baru ditambahkan ke aplikasi Web iteratif, ini bisa memerlukan sebuah migrasi data atau operasi paralel dua versi. Namun, fase transisi bisa sangat mudah jika mungkin untuk hanya mengganti aplikasi yang sudah ada dengan versi yang baru.
11. Analisis Program Extreme
Bagian ini membahas kesesuaian Extreme Programming (XP) (Beck 1999, Beck dan Fowler 2000) - software paling populer pengembangan model proses agile - untuk pengembangan Aplikasi web. Agile adalah proses dibangun di atas dasar pembangunan iteratif. Untuk yayasan
bahwa mereka menambahkan lebih ringan, lebih manusia-sentris sudut pandang dari pendekatan tradisional. Agile proses umpan balik digunakan, bukan perencanaan, sebagai mekanisme kontrol utama mereka. umpan balik yang digerakkan oleh tes reguler dan rilis software berkembang. sastra umumnya tidak membedakan antara proses dan metode bila memperkenalkan XP. Sebaliknya, menjelaskan empat nilai inti , yang antara lain: komunikasi, kesederhanaan, umpan balik, dan keberanian dan dua belas praktek proyek XP. Keempat nilai inti merupakan dasar untuk proyek XP, dan mereka harus dipahami dengan baik. Dua belas praktek yang berasal dari empat nilai aspek metodologis sesuai dengan definisi kita tentang proses pengembangan perangkat lunak. Selama beberapa tahun terakhir, namun, proses gesit telah terbukti sukses di banyak proyek pengembangan Web. Jika kita melihat persyaratan yang paling dipenuhi oleh proses ini, kita dapat melihat bahwa proses adaptasi sampai pada tingkat kompleksitas aplikasi Web menonjol. Kesulitan dalam menggunakan proses agile terletak pada skalabilitas mereka untuk aplikasi lebih besar dan lebih kompleks, yang harus dikembangkan oleh tim besar karena melekat tekanan waktu. Masalah dalam menjalankan sebuah proyek dengan sebuah proses agile termasuk tuntutan sangat tinggi pada anggota tim. Tapi mengetahui perubahan yang dibutuhkan tidak cukup untuk menjamin bertindak foresighted. Persiapan yang tepat diperlukan untuk beralih ke proses kelas berat. Perubahan tersebut harus direncanakan dengan hati-hati, diperkenalkan perlahan, dan dilaksanakan secara bertahap (DeVilliers 2002). Seperti disebutkan di atas, siklus hidup masing-masing proyek sangat pendek yang hanya serangkaian proyek akan mengarah ke aplikasi Web baru dengan tingkat kompleksitas yang lebih tinggi. Ini berarti bahwa kita harus membuat suatu proses tingkat tinggi di seluruh proses pengembangan perangkat lunak proyek berturut-turut.
Daftar Pustaka
Fournier, R., A Methodology for Client/Server and Web Application Development, Prentice Hall, 1998.
DeVilliers, D. J., Introducing the RUP into an Organization, The Rational Edge, 2002, http://www-
128.ibm.com/developerworks/rational/library/916.html, [last visit: 2005-12-06].
