MODEL SIKLUS HIDUP PERANGKAT LUNAK
V- Model
2.4 MODEL PENGEMBANGAN CEPAT
Perkembangan bertahap adalah ciri khas model evolusioner dan RAD. Namun, dalam RAD setiap kenaikan pada dasarnya menghasilkan prototipe yang cepat dan kotor, sedangkan dalam model evolusioner setiap kenaikan dikembangkan secara sistematis menggunakan model air terjun iteratif. Juga dalam model RAD, perangkat lunak dikembangkan dalam peningkatan yang jauh lebih pendek dibandingkan model evolusioner. Dengan kata lain, fungsionalitas tambahan yang dikembangkan memiliki granularitas yang cukup besar dalam model evolusi.
inefisiensi dan menyebabkan waktu penyelesaian proyek menjadi lebih lama dibandingkan dengan harapan pelanggan.
• Model air terjun mengatur hampir tidak ada interaksi pelanggan setelah persyaratan telah ditentukan. Faktanya, dalam model pengembangan perangkat lunak air terjun, interaksi pelanggan sebagian besar terbatas pada tahap inisiasi proyek dan penyelesaian proyek.
Model pengembangan perangkat lunak tangkas diusulkan pada pertengahan 1990-an untuk mengatasi kekurangan serius dari model pengembangan air terjun yang diidentifikasi di atas. Model tangkas terutama dirancang untuk membantu proyek beradaptasi dengan permintaan perubahan dengan cepat.1 Jadi, tujuan utama model tangkas adalah untuk memfasilitasi penyelesaian proyek dengan cepat. Tapi, bagaimana kelincahan dicapai dalam model ini? Kelincahan dicapai dengan menyesuaikan proses dengan proyek, yaitu menghilangkan aktivitas yang mungkin tidak diperlukan untuk proyek tertentu. Juga, apa pun yang membuang-buang waktu dan usaha dihindari.
Harap dicatat bahwa model tangkas digunakan sebagai istilah umum untuk merujuk pada sekelompok proses pengembangan. Proses-proses ini memiliki karakteristik umum tertentu, tetapi memiliki perbedaan halus tertentu di antara mereka sendiri. Beberapa model SDLC tangkas yang populer adalah sebagai berikut:
• Kristal
• Atern (sebelumnya DSDM)
• Pengembangan berbasis fitur
• Scrum
• Pemrograman ekstrim (XP)
• Pengembangan ramping
• Proses terpadu
Dalam model tangkas, persyaratan didekomposisi menjadi banyak bagian kecil yang dapat dikembangkan secara bertahap. Model tangkas mengadopsi pendekatan iteratif. Setiap bagian inkremental dikembangkan melalui iterasi. Setiap iterasi dimaksudkan untuk menjadi kecil dan mudah dikelola dan berlangsung selama beberapa minggu saja. Pada suatu waktu, hanya satu peningkatan yang direncanakan, dikembangkan, dan kemudian disebarkan di lokasi pelanggan. Tidak ada rencana jangka panjang yang dibuat. Waktu untuk menyelesaikan iterasi disebut kotak waktu. Implikasi dari istilah kotak waktu adalah bahwa tanggal akhir untuk iterasi tidak berubah. Artinya, tanggal pengiriman dianggap sakral. Namun, tim pengembangan dapat memutuskan untuk mengurangi fungsionalitas yang diberikan selama kotak waktu jika perlu. Prinsip utama dari model tangkas adalah pengiriman kenaikan ke pelanggan setelah setiap kotak waktu. Beberapa prinsip lain yang penting untuk model tangkas dibahas di bawah ini.
Ide Penting di Balik Model Agile
Untuk menjalin kontak dekat dengan pelanggan selama pengembangan dan untuk mendapatkan pemahaman yang jelas tentang masalah khusus domain, setiap proyek tangkas biasanya menyertakan perwakilan pelanggan dalam tim. Pada akhir setiap iterasi, pemangku kepentingan dan perwakilan pelanggan meninjau kemajuan yang dibuat dan mengevaluasi kembali persyaratan. Karakteristik yang membedakan model tangkas adalah seringnya pengiriman peningkatan perangkat lunak kepada pelanggan.
Model Agile menekankan komunikasi tatap muka atas dokumen tertulis. Disarankan agar ukuran tim pengembangan sengaja dibuat kecil (5-9 orang) untuk membantu anggota tim terlibat secara bermakna dalam komunikasi tatap muka dan memiliki lingkungan kerja yang kolaboratif. Maka tersirat bahwa model tangkas cocok untuk pengembangan proyek-proyek
kecil. Namun, jika proyek besar diperlukan untuk dikembangkan menggunakan model tangkas, kemungkinan tim yang berkolaborasi mungkin bekerja di lokasi yang berbeda. Dalam hal ini, tim yang berbeda diperlukan untuk mempertahankan kontak harian sebanyak mungkin melalui konferensi video, telepon, email, dll.
• Model tangkas menekankan rilis tambahan dari perangkat lunak yang berfungsi sebagai ukuran utama kemajuan. Prinsip-prinsip penting berikut di balik model tangkas dipublikasikan dalam manifesto tangkas pada tahun 2001:
• Perangkat lunak yang berfungsi melalui dokumentasi yang komprehensif.
• Pengiriman versi tambahan perangkat lunak secara berkala kepada pelanggan dalam interval beberapa minggu.
• Permintaan perubahan kebutuhan dari pelanggan didorong dan dimasukkan secara efisien.
• Memiliki anggota tim yang kompeten dan meningkatkan interaksi di antara mereka dianggap jauh lebih penting daripada masalah seperti penggunaan alat canggih atau kepatuhan yang ketat terhadap proses yang terdokumentasi.
Disarankan bahwa peningkatan komunikasi di antara anggota tim pengembangan dapat diwujudkan melalui komunikasi tatap muka daripada melalui pertukaran dokumen formal.
Interaksi berkelanjutan dengan pelanggan dianggap jauh lebih penting daripada negosiasi kontrak yang efektif. Perwakilan pelanggan diperlukan untuk menjadi bagian dari tim pengembangan, sehingga memfasilitasi kerjasama harian yang erat antara pelanggan dan pengembang.
Proyek pengembangan tangkas biasanya menggunakan pemrograman berpasangan.
Dalam pemrograman berpasangan, dua programmer bekerja sama di satu stasiun kerja. Satu mengetik kode sementara yang lain meninjau kode saat diketik. Dua programmer berganti peran setiap jam atau lebih. Beberapa penelitian menunjukkan bahwa programmer yang bekerja berpasangan menghasilkan program yang ditulis dengan baik dan melakukan lebih sedikit kesalahan dibandingkan dengan programmer yang bekerja sendiri.
Keuntungan dan kerugian dari metode tangkas
Metode tangkas memperoleh banyak kelincahan mereka dengan mengandalkan pengetahuan tacit dari anggota tim tentang proyek pengembangan dan komunikasi informal untuk mengklarifikasi masalah, daripada menghabiskan banyak waktu dalam menyiapkan dokumen formal dan meninjaunya. Meskipun ini menghilangkan beberapa overhead, tetapi kurangnya dokumentasi yang memadai dapat menyebabkan beberapa jenis masalah, yaitu sebagai berikut:
• Kurangnya dokumen formal menyisakan ruang untuk kebingungan dan keputusan penting yang diambil selama fase yang berbeda dapat disalahartikan di kemudian hari oleh anggota tim yang berbeda.
• Dengan tidak adanya dokumen formal, menjadi sulit untuk mendapatkan keputusan proyek penting seperti keputusan desain untuk ditinjau oleh ahli eksternal.
• Ketika proyek selesai dan developer bubar, pemeliharaan bisa menjadi masalah.
Agile versus Model Lain
Berikut ini adalah perbandingan karakteristik model tangkas dengan model pengembangan lainnya.
Model tangkas versus model air terjun berulang
Model air terjun sangat terstruktur dan langkah sistematis melalui persyaratan- capture, analisis, spesifikasi, desain, coding, dan tahap pengujian dalam urutan yang
direncanakan. Kemajuan umumnya diukur dalam hal jumlah artefak yang telah diselesaikan dan ditinjau seperti spesifikasi persyaratan, dokumen desain, rencana pengujian, tinjauan kode, dll. yang tinjauannya telah selesai. Sebaliknya, saat menggunakan model tangkas, kemajuan diukur dalam hal fungsionalitas yang dikembangkan dan disampaikan. Dalam model tangkas, pengiriman versi kerja perangkat lunak dibuat dalam beberapa peningkatan. Namun, dari segi kesamaan dapat dikatakan bahwa tim tangkas menggunakan model air terjun dalam skala kecil, mengulangi seluruh siklus air terjun di setiap iterasi.
Jika proyek yang sedang dikembangkan menggunakan model air terjun dibatalkan di tengah jalan selama pengembangan, maka tidak ada yang bisa ditunjukkan dari proyek yang ditinggalkan di luar beberapa dokumen. Dengan model tangkas, bahkan jika sebuah proyek dibatalkan di tengah jalan, itu masih meninggalkan pelanggan dengan beberapa kode yang berharga, yang mungkin telah dimasukkan ke dalam operasi langsung.
Pemrograman tangkas versus eksplorasi
Meskipun beberapa kesamaan memang ada antara gaya pemrograman tangkas dan eksploratif, ada perbedaan besar antara keduanya juga. Evaluasi ulang rencana model pengembangan tangkas, penekanan pada komunikasi tatap muka, dan penggunaan dokumentasi yang relatif jarang mirip dengan gaya eksplorasi. Tim yang gesit, bagaimanapun, mengikuti proses yang ditentukan dan disiplin dan melakukan penangkapan persyaratan sistematis, desain yang ketat, dibandingkan dengan pengkodean yang kacau dalam pemrograman eksplorasi.
Model tangkas versus model RAD
Perbedaan penting antara model gesit dan RAD adalah sebagai berikut:
• Model Agile tidak merekomendasikan pengembangan prototipe, tetapi menekankan pengembangan sistematis dari setiap fitur tambahan. Sebaliknya, tema sentral RAD didasarkan pada perancangan prototipe cepat dan kotor, yang kemudian disempurnakan menjadi kode kualitas produksi.
• Proyek tangkas secara logis memecah solusi menjadi fitur yang dikembangkan dan disampaikan secara bertahap. Pendekatan RAD tidak merekomendasikan hal ini.
Sebaliknya, developer yang menggunakan model RAD berfokus pada pengembangan semua fitur aplikasi dengan terlebih dahulu melakukannya dengan buruk dan kemudian secara berturut-turut meningkatkan kode dari waktu ke waktu.
• Tim tangkas hanya mendemonstrasikan pekerjaan yang telah selesai kepada pelanggan. Sebaliknya, tim RAD mendemonstrasikan kepada pelanggan layar mock up, dan prototipe, yang mungkin didasarkan pada penyederhanaan seperti pencarian tabel daripada perhitungan.
Model Pemrograman Ekstrim (Extreme Programming)
Extreme programming (XP) adalah model proses penting di bawah payung tangkas dan diusulkan oleh Kent Beck pada tahun 1999. Nama model ini mencerminkan fakta bahwa model ini merekomendasikan untuk mengambil praktik terbaik yang telah bekerja dengan baik di masa lalu dalam pengembangan program. proyek ke tingkat ekstrim. Model ini didasarkan pada filosofi yang agak sederhana: "Jika sesuatu diketahui bermanfaat, mengapa tidak menggunakannya terus-menerus?" Berdasarkan prinsip ini, ia mengajukan beberapa praktik utama yang perlu dipraktikkan secara ekstrem. Harap dicatat bahwa sebagian besar praktik utama yang ditekankan telah diakui sebagai praktik yang baik untuk beberapa waktu.
Praktik baik yang perlu dipraktikkan secara ekstrem
Beberapa praktik yang diakui dalam model pemrograman ekstrem dan cara yang disarankan untuk memaksimalkan penggunaannya:
Tinjauan kode: Ini bagus karena membantu mendeteksi dan memperbaiki masalah dengan paling efisien. Ini menyarankan pemrograman berpasangan sebagai cara untuk mencapai tinjauan berkelanjutan. Dalam pair programming, pengkodean dilakukan oleh pasangan programmer. Programmer bergiliran menulis program dan sementara yang satu menulis kode ulasan lainnya yang sedang ditulis.
Pengujian: Kode pengujian membantu menghilangkan bug dan meningkatkan keandalannya. XP menyarankan pengembangan berbasis uji (TDD) untuk terus menulis dan menjalankan kasus uji. Dalam pendekatan TDD, kasus uji ditulis bahkan sebelum kode apa pun ditulis.
Pengembangan inkremental: Pengembangan inkremental bagus, karena membantu mendapatkan umpan balik pelanggan, dan tingkat fitur yang disampaikan merupakan indikator kemajuan yang dapat diandalkan. Ini menunjukkan bahwa tim harus membuat peningkatan baru setiap beberapa hari.
Kesederhanaan: Kesederhanaan membuatnya lebih mudah untuk mengembangkan kode berkualitas baik, serta untuk menguji dan men-debugnya. Oleh karena itu, seseorang harus mencoba membuat kode paling sederhana yang membuat fungsionalitas dasar yang ditulis berfungsi. Untuk membuat kode yang paling sederhana, seseorang dapat mengabaikan aspek-aspek seperti efisiensi, keandalan, pemeliharaan, dll. Setelah hal yang paling sederhana berhasil, aspek lain dapat diperkenalkan melalui refactoring.
Desain: Karena memiliki desain berkualitas baik penting untuk mengembangkan solusi berkualitas baik, setiap orang harus mendesain setiap hari. Ini dapat dicapai melalui refactoring, di mana kode kerja ditingkatkan untuk efisiensi dan pemeliharaan.
Pengujian integrasi: Ini penting karena membantu mengidentifikasi bug pada antarmuka fungsi yang berbeda. Untuk tujuan ini, pemrograman ekstrim menyarankan bahwa developer harus mencapai integrasi berkelanjutan, dengan membangun dan melakukan pengujian integrasi beberapa kali sehari.
Ide dasar model pemrograman ekstrim
XP didasarkan pada rilis yang sering (disebut iterasi ), di mana developer menerapkan
"cerita pengguna". Cerita pengguna mirip dengan kasus penggunaan, tetapi lebih informal dan lebih sederhana. Kisah pengguna adalah deskripsi percakapan oleh pengg una tentang fitur sistem yang diperlukan. Misalnya, cerita pengguna tentang perangkat lunak perpustakaan dapat berupa:
• Seorang anggota perpustakaan dapat menerbitkan buku.
• Seorang anggota perpustakaan dapat menanyakan tentang ketersediaan buku.
• Seorang anggota perpustakaan harus dapat mengembalikan buku yang dipinjam.
Kisah pengguna adalah pernyataan sederhana dari pelanggan tentang fungsionalitas yang dia butuhkan, tidak menyebutkan tentang detail yang lebih baik seperti skenario berbeda yang dapat terjadi, prasyarat (keadaan di mana sistem) harus dipenuhi sebelum fitur dapat dipanggil , dll.
Berdasarkan cerita pengguna, tim proyek mengusulkan "metafora"—sebuah visi bersama tentang bagaimana sistem akan bekerja. Tim pengembangan dapat memutuskan untuk membuat lonjakan untuk beberapa fitur. Sebuah spike, adalah program yang sangat sederhana yang dibangun untuk mengeksplorasi kesesuaian solusi yang diusulkan. Lonjakan dapat dianggap mirip dengan prototipe. XP mengatur beberapa aktivitas dasar untuk menjadi bagian dari proses pengembangan perangkat lunak. Kegiatan ini adalah sebagai berikut:
Coding: XP berpendapat bahwa kode adalah bagian penting dari setiap proses pengembangan sistem, karena tanpa kode tidak mungkin memiliki sistem yang berfungsi. Oleh
karena itu, perhatian dan perhatian penuh perlu ditempatkan pada aktivitas pengkodean.
Namun, konsep kode seperti yang digunakan di XP memiliki arti yang sedikit berbeda dari apa yang dipahami secara tradisional. Misalnya, kegiatan coding meliputi menggambar diagram (modelling) yang akan diubah menjadi kode, membuat script sistem berbasis web, dan memilih di antara beberapa alternatif solusi.
Pengujian: XP sangat mementingkan pengujian dan menganggapnya sebagai sarana utama untuk mengembangkan perangkat lunak bebas kesalahan.
Mendengarkan: developer perlu mendengarkan pelanggan dengan cermat jika mereka harus mengembangkan perangkat lunak berkualitas baik. Programmer mungkin belum tentu memiliki pengetahuan mendalam tentang domain spesifik dari sistem yang sedang dikembangkan. Di sisi lain, pelanggan biasanya memiliki pengetahuan domain ini. Oleh karena itu, agar programmer dapat memahami dengan baik apa fungsi sistem yang seharusnya, mereka harus mendengarkan pelanggan.
Merancang: Tanpa desain yang tepat, implementasi sistem menjadi terlalu kompleks dan ketergantungan dalam sistem menjadi terlalu banyak dan menjadi sangat sulit untuk memahami solusinya, dan dengan demikian membuat biaya pemeliharaan menjadi sangat mahal. Sebuah desain yang baik harus menghasilkan penghapusan ketergantungan yang kompleks dalam suatu sistem. Dengan demikian, penggunaan yang efektif dari teknik desain yang sesuai ditekankan.
Umpan balik: Ini mendukung kebijaksanaan: "Sebuah sistem yang menjauh dari pengguna adalah masalah yang menunggu untuk terjadi". Ini mengakui pentingnya umpan balik pengguna dalam memahami kebutuhan pelanggan yang tepat. Waktu yang berlalu antara pengembangan versi dan pengumpulan umpan balik di dalamnya sangat penting untuk belajar dan membuat perubahan.
Kesederhanaan: Sebuah landasan XP didasarkan pada prinsip: "bangun sesuatu yang sederhana yang akan berhasil hari ini, daripada mencoba membangun sesuatu yang akan memakan waktu namun mungkin tidak akan pernah digunakan". Ini pada dasarnya berarti bahwa perhatian harus difokuskan pada fitur spesifik yang segera dibutuhkan dan membuatnya berfungsi, daripada mencurahkan waktu dan energi untuk spekulasi tentang persyaratan di masa depan.
XP mendukung pembuatan solusi untuk masalah sesederhana mungkin. Sebaliknya, metode pengembangan sistem tradisional merekomendasikan perencanaan untuk penggunaan kembali dan ekstensibilitas kode dan desain di masa depan dengan mengorbankan kode yang lebih tinggi dan kompleksitas desain.
Penerapan model pemrograman ekstrim
Berikut ini adalah beberapa karakteristik proyek yang menunjukkan kelayakan suatu proyek untuk dikembangkan dengan menggunakan model extreme programming:
• Proyek yang melibatkan teknologi baru atau proyek penelitian: Dalam hal ini, persyaratan berubah dengan cepat dan masalah teknis yang tidak terduga perlu diselesaikan.
• Proyek kecil: Pemrograman ekstrem diusulkan dalam konteks tim kecil karena pertemuan tatap muka lebih mudah dicapai.
Karakteristik proyek tidak cocok untuk pengembangan menggunakan model tangkas Berikut ini adalah beberapa karakteristik proyek yang menunjukkan ketidaksesuaian model pengembangan agile untuk digunakan dalam proyek pengembangan:
Persyaratan stabil: Model pengembangan konvensional lebih cocok untuk digunakan dalam proyek yang ditandai dengan persyaratan stabil. Untuk proyek-proyek seperti itu, diketahui bahwa hanya sedikit perubahan, jika sama sekali, akan terjadi. Oleh karena itu,
model proses seperti model air terjun berulang yang melibatkan pembuatan rencana jangka panjang selama inisiasi proyek dapat digunakan secara bermakna.
Sistem kritis misi atau kritis keselamatan: Dalam pengembangan sistem seperti itu, model SDLC tradisional biasanya lebih disukai untuk memastikan keandalan.
Model Scrum
Dalam model scrum, sebuah proyek dibagi menjadi bagian-bagian kecil dari pekerjaan yang dapat dikembangkan secara bertahap dan dikirimkan dari waktu ke waktu disebut sprint.
Oleh karena itu, perangkat lunak dikembangkan melalui serangkaian potongan yang dapat dikelola. Setiap sprint biasanya hanya membutuhkan waktu beberapa minggu untuk diselesaikan. Di akhir setiap sprint, pemangku kepentingan dan anggota tim bertemu untuk menilai kemajuan yang dibuat dan pemangku kepentingan menyarankan kepada tim pengembangan setiap perubahan yang diperlukan untuk fitur yang telah dikembangkan dan peningkatan keseluruhan yang mungkin mereka rasa perlu.
Dalam model scrum, anggota tim mengambil tiga peran mendasar— pemilik perangkat lunak, master scrum, dan anggota tim. Pemilik perangkat lunak bertanggung jawab untuk mengkomunikasikan visi pelanggan dari perangkat lunak kepada tim pengembangan. Scrum master bertindak sebagai penghubung antara pemilik perangkat lunak dan tim, sehingga memfasilitasi pekerjaan pengembangan.