Membuat Rencana Proyek
A. Opsi-Opsi Metodologi Peng- embangan Perangkat Lunak
Ada banyak metodologi pengembangan sistem yang berbeda, dan setiap metodologi berbeda dalam hal mengimplementasikan fase-fase SDLC.
Beberapa metodologi merupakan standar formal yang digunakan oleh lembaga pemerintah, sementara yang lain telah dikembangkan oleh perusahaan konsultan untuk dijual kepada klien. Pada bagian ini akan dibahas beberapa metodologi utama yang telah berkembang seiring waktu.
1. Waterfall
Pada metodologi pengembangan berbasis waterfall (air terjun), analis dan pengguna bersama-sama merumuskan suatu kegiatan secara berurutan dari satu fase ke fase berikutnya (gambar 2.2.1). Hasil utama untuk setiap fase disampaikan kepada komite persetujuan dan sponsor proyek untuk disetujui selama proyek berjalan dari fase ke fase. Setelah pekerjaan yang dihasilkan dalam satu fase disetujui, fase berakhir dan fase berikutnya dimulai.
Metodologi pengembangan Waterfall memiliki keunggulan dalam mengidentifikasi kebutuhan pengguna jauh sebelum kegiatan pemrograman dimulai dan membatasi perubahan kebuthan pengguna saat proyek dimulai. Kelemahan utama adalah bahwa rancangan sistem harus benar-benar dipersiapkan secara matang sebelum pemrograman
dimulai, sebab kebutuhan perubahan sistem tidak diakomudir selama fase-fase berjalan. Kelemahan lain adalah terdapat jedah waktu yang lama sejak usulan sistem dalam fase analisis hingga fase pengujian dan pendistribusian sistem dalam fase implementasi, merupakan hal yang patut direnungkan. Selain itu, pada fase pendistribusian sistem seringkali terjadi mekanisme komunikasi yang buruk, sehingga persyaratan penting diabaikan dalam dokumentasi sistem.
Gambar 2.2.1 Model Waterfall
Ada dua varian utama dari model Waterfall, yaitu model Parallel dan V- Model.
a. Model Parallel
Model Parallel dikembangkan untuk mengatasi permasalahan waktu pengembangan yang lama pada model Waterfall. Seperti yang ditunjukkan pada gambar 2.2.2, pada tahap awal dibuat desain secara umum untuk keseluruhan sistem. Kemudian proyek dibagi menjadi serangkaian sub proyek yang dapat dirancang dan diimplementasikan secara paralel. Setelah semua sub proyek selesai, dilakukan integrasi
akhir dari bagian-bagian yang terpisah, dan selanjutnya sistem didistribusikan.
Gambar 2.2.2 Model Parallel
Dengan konsep pengembangan yang paralel, metodologi pengembangan Parallel dapat mengurangi waktu yang diperlukan untuk menghasilkan suatu sistem. Perubahan dalam lingkungan bisnis tidak menyebabkan perubahan yang besar pada produk yang memerlukan pengerjaan ulang. Masalah muncul jika sub proyek tidak didesain sepenuhnya untuk dapat berdiri sendiri, hasil desain dalam satu sub proyek dapat mempengaruhi yang lain, dan pada akhir proyek pengintegrasian sub-sub proyek mungkin cukup rumit.
b. V-Model
V-Model adalah variasi lain dari model Waterfall yang lebih difokuskan pada pengujian secara eksplisit. Seperti ditunjukkan pada gambar 2.2.3, proses pengembangan berlangsung di sisi kiri kemiringan V, yaitu kegiatan penentuan kebutuhan sistem dan perancangan
komponen sistem. Di dasar V, dilakukan kegiatan pemrograman. Di kemiringan sisi kanan model, terdapat pengujian komponen, pengujian integrasi, dan berakhir pada pengujian penerimaan sistem.
Model-V sederhana dan menekankan pada pengembangan rencana pengujian. Pengujian dan keahlian lebih difokuskan pada fase-fase awal proyek, daripada diletakkan pada bagian akhir proyek. Model ini kaku dalam proses Waterfall, dan tidak selalu sesuai pada keadaan lingkungan bisnis yang bersifat dinamis (selalu berubah ubah).
Gambar 2.2.3 V-Model
2. Rapid Application Development (RAD)
RAD adalah kumpulan metodologi yang muncul untuk merespon kelemahan pada metode pengembangan Waterfall dan variasinya. RAD menggabungkan teknik-teknik khusus dan peralatan komputer guna mempercepat fase analisis, desain, dan implementasi untuk mendapatkan sebagian dari sistem yang dikembangkan dengan cepat
tersebut ke tangan pengguna untuk dievaluasi dan mendapatkan umpan balik.
Meskipun RAD dapat meningkatkan kecepatan dan kualitas pengembangan sistem, RAD juga dapat menimbulkan masalah dalam mengelola keinginan pengguna. Karena sistem dikembangkan lebih cepat dan pengguna mendapatkan pemahaman yang lebih baik tentang teknologi informasi, harapan pengguna dapat meningkat secara dramatis dan kebutuhan sistem dapat berkembang selama fase proyek berlangsung.
RAD dapat dilakukan dengan berbagai cara, seperti Iterative Development, System Prototyping, dan Throwaway Prototyping.
a. Iterative Development
Gambar 2.2.4 Model Iterative
Pengembangan iterative memecah satu proyek menjadi beberapa bagian untuk dikembangkan secara berurutan (Fowler, 2005).
Kebutuhan paling penting dan mendasar digabungkan ke dalam versi pertama sistem. Versi ini dikembangkan dengan cepat melalui model SDLC mini, dan sekaligus diimplementasikan. Pengguna dapat memberikan umpan balik yang berharga untuk dimasukkan ke dalam versi sistem selanjutnya (lihat Gambar 2.2.4). Kelemahan utama dari model pengembangan iterative adalah bahwa ketika pengguna mulai menggunakan sistem (yang memang sengaja dibuat tidak lengkap), pengguna sering tidak menyadari bahwa pada versi awal hanya kebutuhan paling kritis dari sistem yang akan tersedia, dan mereka terus menuntut untuk menggunakan versi yang sempurnah.
b. System Prototyping
Model System Prototyping melakukan fase analisis, desain, dan implementasi secara keseluruhan (tuntas) untuk mengembangkan versi sederhana dari sistem yang diusulkan, dan mendistribusikan kepada pengguna untuk mendapatkan evaluasi dan umpan balik (lihat gambar 2.2.5).
System prototyping sangat cepat menyediakan sistem bagi pengguna untuk mengevaluasi dan meyakinkan pengguna bahwa kemajuan sedang dibuat. Pendekatan ini sangat berguna ketika pengguna memiliki kesulitan mengungkapkan seluruh kebutuhan pada fase awal pengembangan sistem. Prototype berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan pengguna yang sesungguhnya.
Namun, kekurangannya adalah kurangnya analisis metodis yang cermat sebelum membuat keputusan melanjutkan ke tahap desain dan implementasi. System Prototype mungkin memiliki beberapa keterbatasan pada rancangan sistem yang paling mendasar, yang merupakan akibat langsung dari pemahaman sistem yang tidak memadai pada fase awal proyek.
Gambar 2.2.5 Model System Prototyping c. Throwaway Prototyping
Model Throwaway Prototyping tergolong dalam model pengembangan Prototype, akan tetapi penekanannya pada penggunaan prototype terutama untuk mengeksplorasi alternatif desain daripada sebagai sistem yang berfungsi seperti dalam System Prototyping.
Contoh:
Anggaplah pengguna tidak memahami dengan jelas tentang cara kerja sistem entri pesanan. Tim analis dapat membuat serangkaian halaman yang dapat dilihat pada browser Web untuk membantu pengguna memvisualisasikan sistem entri pesanan. Melalui mock up desain, pengguna dapat melihat visualisasi calon aplikasi secara nyata sehingga pengguna dapat memberikan masukan kepada desainer jika tampilan mock up dirasa belum sesuai dengan permintaan sebelumnya.
Suatu sistem yang dikembangkan menggunakan metodologi Throwaway Prototyping ini mungkin memerlukan beberapa Prototype Design selama fase analisis dan desain. Masing-masing prototype digunakan untuk meminimalkan risiko yang terkait dengan sistem dengan mengonfirmasi bahwa masalah-masalah penting memang telah
dipahami dengan jelas sebelum sistem nyata dibangun. Setelah masalah diselesaikan, proyek dilanjutkan ke fase desain dan implementasi. Pada titik ini, Prototype Design tidak lagi digunakan (dibuang). Disinilah letak perbedaan mendasar antara pendekatan Throwaway Prototyping dan System Prototype, di mana prototype berevolusi menjadi sistem akhir.
Gambar 2.2.6 Model Throwaway Prototyping 3. Agile Development
Agile development adalah sekelompok metodologi pemrograman yang fokus pada penyederhaan SDLC. Banyak fitur tambahan pada fase pemodelan dan dokumentasi dihilangkan, sebaliknya proses komunikasi melalui interaksi langsung dengan pengguna sistem lebih disukai.
Pengembangan proyek menekankan pada hal-hal yang sederhana, pengembangan sistem secara berulang dimana setiap perulangan merupakan serangkaian fase pekerjaan yang lengkap yaitu: perencanaan, analisis kebutuhan, desain, pengkodean, pengujian, dan dokumentasi (lihat gambar 2.2.7). Siklus dijaga agar tetap pendek (sekitar satu hingga empat minggu), dan tim pengembangan berfokus pada bagaimana beradaptasi dengan lingkungan bisnis saat ini. Ada beberapa pendekatan
Programming (XP), Scrum, dan Dynamic Systems Development Method (DSDM). Modul ini hanya akan memberikan gambaran secara singkat mengenai Extreme Programming.
a. Extreme Programming
Metodologi pengembangan Extreme Programming (XP) menekankan pada kepuasan pelanggan dan kerja tim (kerja secara kelompok).
Komunikasi, kesederhanaan, umpan balik, dan keberanian adalah prinsip utama dalam Extreme Programming.
Proyek XP dimulai dengan pengguna menggambarkan apa yang perlu dilakukan sistem. Kemudian, programmer membuat kode program dalam modul kecil dan sederhana, mengujinya untuk memenuhi kebutuhan tersebut. Pengguna harus bersedia untuk memberikan keterangan secara jelas dan tuntas atas segala pertanyaan dan permasalahan yang muncul. Proyek XP memberikan hasil lebih cepat daripada pendekatan RAD, dan tim pengembang jarang mengalami kebuntuan dalam kegiatan pengkajian kebutuhan untuk sistem.
Gambar 2.2.7 Model Extreme Programming
Untuk proyek-proyek kecil dengan tim pengembang yang tetap, memiliki motivasi tinggi, kompak, dan berpengalaman, XP dapat bekerja dengan baik. Namun, jika proyek berskala besar dan tim tidak kompak, maka kemungkinan keberhasilan proyek XP akan berkurang.
Karena hanya sedikit dokumentasi analisis dan desain yang diproduksi dalam XP, maka hanya terdapat dokumentasi kode program.
Oleh karena itu, pemeliharaan pada sistem besar yang dikembangkan menggunakan XP mungkin tidak dimungkinkan.
b. Agile versus Waterfall-Based Methodologies
Pendekatan pengembangan berbasis Agile telah ada selama lebih dari satu dekade. Praktik pengembangan berbasis Agile dilandasi adanya ketidakpuasan terhadap model sekuensial, seperti pendekatan berbasis air terjun (waterfall) yang tidak fleksibel. Saat ini, pengembangan berbasis Agile telah membuat terobosan ke dalam organisasi pengembangan perangkat lunak, dimana banyak organisasi bereksperimen dengan model Agile sambil terus menggunakan pendekatan tradisional Waterfall. Para pengembang perangkat lunak secara aktif meneliti untuk mengintegrasikan elemen terbaik dari model Waterfall dan model Agile dalam praktik pengembangan perangkat lunak. Proses pengembangan sistem informasi tidak pernah statis.
Sebagian besar departemen Sistem Informasi dan manajer proyek mengakui bahwa pilihan metodologi pengembangan "terbaik"
tergantung pada karakteristik proyek.