MODEL-MODEL SDLC (SYSTEM DEVELOPMEN LIFE CYCLE)

SDLC memiliki beberapa model dalam penerapan tahapan prosesnya.Masing-masing model memiliki kelebihan dan kekurangan.Akan tetapi semua tergantung kepada pengembang dan user untuk memilih model yang mana lebih sesuai dengan mereka.Berikut model-model SDLC.Selamat membaca !

1.Model Waterfall

Model ini biasa disebut model air terjun atau model sekuensial linier(sequential linear).Model air terjun menyediakan pendekatan alur perangkat lunak secara sekuensial/terurut  mulai dari analisis,desain,pengkodean,pengujian dan tahap pendukung (support).



Ilustrasi Model Waterfall

  • Analisis kebutuhan perangkat lunak merupakan proses pengumpulan kebutuhan dilakukan secara intensif untuk menspesifikasikan kebutuhan perangkat lunak agar dapat dipahami perangkat lunak seperti apa yang dibutuhkan oleh user.Spesfikasi kebutuhan perangkat lunak pada tahap ini perlu untuk didokumentasikan.
  • Desain adalah proses multi langkah yang fokus pada desain pembuatan program perangkat lunak termasuk struktur data,arsitektur perangkat lunak,representasi antarmuka,dan prosedur pengkodean.
  • Pengkodean,desain harus ditranslasikan ke dalam program perangkat lunak.Hasil dari tahap ini adalah program komputer sesuai dengan desain yang telah dibuat pada tahap desain.
  • Pengujian  fokus kepada perangkat lunak secara dari segi logik dan fungsional dan memastikan bahwa semua bagian sudah diuji.Hal ini dilakukan untuk meminimalisir kesalahan/error dan memastikan keluaran yang dihasilkan sesuai dengan yang diinginkan.
  • Maintenance/Support tidak menutup kemungkinan sebuah perangkat lunak mengalami perubahan ketika sudah dikirimkan ke user.Perubahan bisa terjadi karena adanya kesalahan yang muncul dan tidak terdeteksi saat pengujian atau perangkat lunak harus beradaptasi dengan lingkungan yang baru.Tahap maintenance dapat mengulangi proses pengembangan mulai dari analisis untuk perubahan perangkat lunak yang sudah ada,tapi tidak untuk membuat perangkat lunak yang baru.
Kelemahan dari model waterfall yaitu :
  • Perubahan spesifikasi perangkat lunak yang terjadi ditengah alur pengembangan
  • Sangat sulit bagi pelanggan untuk mendeskripsikan kebutuhan spesifikasi di awal pengembangan.Pelanggan sering kali membutuhkan contoh (prototype) untuk menjabarkan spesifikasi kebutuhan sistem lebih lanjut.
  • Pelanggan tidak mungkin bersabar mengakomodasi perubahan yang diperlukan di akhir alur pengembangan.
Saran : Model Waterfall adalah model SDLC yang hanya cocok untuk pengembangan perangkat lunak dengan spesifikasi yang tidak berubah-ubah.


2.Model Prototype

Seringkali pelanggan membayangkan kumpulan kebutuhan yang diinginkan tapi tidak terspesifikasi secara detail dari segi masukan(input),proses maupun keluaran(output).Di sisi lain seorang pengembang perangkat lunak harus menspesifikasikan sebuah kebutuhan secara detail dari segi teknis dimana pelanggan sering kurang mengerti mengenai hal teknis ini.

Model Prototype dapat digunakan untuk menyambungkan ketidakpahaman pelanggan mengenai hal teknis dan memperjelas spesifikasi kebutuhan yang diinginkan pelanggan kepada pengembang perangkat lunak.

Model prototype dimulai dari mengumpulkan kebutuhan pelanggan terhadap perangkat lunak yang akan dibuat.Lalu dibuatlah program contoh agar pelanggan lebih terbayang dengan apa yang sebenarnya diinginkan(Program Simulasi).Program ini dievaluasi oleh pelanggan atau user sampai ditemukan spesifikasi yang sesuai dengan keinginan pelanggan/user.

Mock-Up adalah sesuatu yang digunakan sebagai model desain yang digunakan untuk mengajar,demonstras,evaluasi desain,promosi,atau keperluan lain.Sebuah mock-up disebut sebagai prototipe perangkat lunak jika menyediakan atau mampu mendemonstrasikan sebagian besar fungsi sistem perangkat lunak dan memungkinkan pengujian desain sistem perangkat lunak.

Ilustrasi Model Prototype


Model Prototype memiliki kelemahan sebagai berikut :
  • Pelanggan dapat sering mengubah-ubah atau menambah-nambah spesifikasi kebutuhan karena menganggap aplikasi sudah dengan cepat dikembangkan,karena adanya masalah ini ,pengembang banyak mengalah dengan pelanggan karena perubahan atau penambahan spesifikasi kebutuhan perangkat lunak.
  • Pengembang lebih sering mengambil kompromi dengan pelanggan untuk mendapatkan prototype dengan waktu yang cepat sehingga pengembang lebih sering melakukan cara guna menghasilkan prototype untuk didemonstrasikan.Hal ini dapat menyebabkan kualitas perangkat lunak menjadi kurang baik.
Permasalahan yang terjadi di metode ini  dapat diatasi dengan melakukan perjanjian(kontrak) antara pengembang dan pelanggan agar model prototype hanya digunakan untuk mendefinisikan spesifikasi kebutuhan perangkat lunak,tetapi tidak untuk seluruh proses pengembangan sistem perangkat lunak.

Saran :Model prototype kurang cocok digunakan untuk aplikasi dengan skala besar karena membuat prototype untuk aplikasi skala besar sangat memakan waktu dan tenaga.Model Prototype cocok digunakan untuk menggali spesifikasi kebutuhan pelanggan secara lebih detail tetapi berisiko tinggi terhadap membengkaknya biaya dan waktu proyek. 

3.Model Rapid Application Development(RAD)

RAD adalah model proses pengembangan perangkat lunak yang bersifat inkremental terutama untuk waktu pengerjaan yang pendek.Model RAD.Model RAD adalah adaptasi dari model waterfall versi kecepatan tinggi dengan menggunakan model air terjun untuk pengembangan setiap komponen perangkat lunak.

Jika kebutuhan perangkat lunak dipahami dengan baik dan lingkup perangkat lunak dibatasi dengan baik sehingga tim dapat menyelesaikan pembuatan perangkat lunak dengan waktu yang pendek.Model RAD membagi tim pengembang menjadi beberapa tim untuk mengerjakan beberapa komponen.Masing-masing tim pengerjaan dapat dilakukan secara pararel.Berikut adalah gambar ilustrasi dari model RAD :

Ilustrasi Model RAD

Dari gambar di atas,kita dapat menyimpulkan bahwa pada model RAD,menggunakan terapan dari Model Waterfall akan tetapi menjadi lebih cepat karena ada tim yang dibagi.Semua tim masing-masing mengerjakan proses/tahapan yang sama tetapi fungsi-fungsi yang berbeda.Contohnya : dalam tahapan bussiness modeling,tim a mencari informasi tentang kebutuhan apa yang terkait fungsi bisnisnya sedangkan di tim b mencari informasi tentang alur proses bisnisnya.Keduanya sama-sama di tahapan proses modeling bussiness tapi beda materi.


  • Pemodelan Bisnis : pemodelan yang dilakukan untuk memodelkan fungsi bisnis untuk mengetahui informasi apa yang terkait fungsi bisnis,informasi apa saja yang harus dibuat,siapa saja yang membuat informasi,bagaimana alur informasi itu,proses apa saja yang terkait informasi itu
  • Pemodelan Data : memodelkan data apa saja yang dibutuhkan berdasarkan pemodelan bisnis dan mendefinisikan atribut-atributnya beserta relasinya dengan data-data yang lain.
  • Pemodelan Proses : mengimplementasikan fungsi bisnis yang sudah didefinisikan terkait dengan pendefinisian data.
  • Pembuatan Aplikasi : mengimplementasikan pemodelan proses dan data menjadi program.Model RAD sangat menganjurkan pemakaian komponen yang sudah ada jika dimungkinkan.
  • Pengujian dan Pergantian :menguji komponen-komponen yang dibuat.Jika sudah teruji maka tim pengembang komponen dapat beranjak untuk mengembangkan komponen berikutnya.
Kelemahan dari model RAD adalah :

  • untuk pembuatan sistem perangkat lunak dengan skala besar maka model RAD akan memerlukan sumber daya manusia yang cukup besar untuk membentuk tim-tim yang mengembangkan komponen-komponen.
  • jika sistem perangkat lunak yang akan dibuat tidak bisa dimodulkan (dibagi-bagi menjadi beberapa komponen) maka model RAD tidak dapat digunakan untuk membuat sistem perangkat lunak karena terlalu banyak campur tangan antar tim.
  • model RAD tidak cocok digunakan untuk sistem perangkat lunak yang memiliki risiko teknis sangat tinggi,contohnya menggunakan teknologi baru yang belum banyak dikenal dan dikuasai pengembang.
Model RAD cocok diterapkan apabila memenuhi kriteria proyek sebagai berikut :

  • anggota tim sudah berpengalaman mengembangkan perangkat lunak yang sejenis
  • pengembang sudah memiliki komponen-komponen sistem yang bisa digunakan kembali dalam proyek tersebut.
4.Model Iteratif(Perulangan)

Model ini mengkombinasikan proses-proses pada model air terjun dan iteratif pada model prototype.Model inkremental akan menghasilkan versi-versi perangkat lunak yang sudah mengalami penambahan fungsi untuk setiap pertambahannya(increment).Berikut adalah gambar dari model inkremental

Ilustrasi Model Iteratif

Model inkremental dibuat untuk mengatasi kelemahan dari model air terjun yang tidak mengakomodasikan iterasi dan mengatasi kelemahan dari metode prototype yang memiliki proses terlalu pendek dan setiap prosesnya tidak selalu menghasilkan produk(hanya prototype).Model inkremental menghasilkan produk/aplikasi untuk setiap tahapan inkremen.

Model inkremental sangat cocok digunakan jika staff yang dimiliki memiliki pergantian yang tinggi sehingga staff tidak dapat terus ikut dalam pengembangan perangkat lunak.Mekanisme tahapan inkremental perlu direncanakan terlebih dahulu agar hasil produk dan pengerjaan setiap tahapan inkremen menjadi lebih baik.

Saran : Model ini cocok digunakan pengembang dengan turnover(pergantian) staff yang tinggi

5.Model Spiral

Model Spiral memasangkan iteratif pada model prototype dengan kontrol dan aspek sistematik yang diambil dari model air terjun.Model spiral menyediakan pengembangan dengan cara cepat dengan perangkat lunak yang memiliki versi yang terus bertambah fungsinya.

Pada pengulangan awal maka dihasilkan adalah prototype sedangkan pada pengulangan akhir yang dihasilkan adalah perangkat lunak yang sudah lengkap.Model spiral dibagi menjadi beberapa kerangka wilayah kerja biasanya diantara tiga sampai enam wilayah sebagai berikut :
  • Komunikasi dengan pelanggan : aktifitas ini diperlukan untuk membagnun komunikasi yang efektif antara pengembang dan pelanggan.
  • Perencanaan : aktifitas ini diperlukan untuk mendefinisikan sumber daya,waktu dan informasi yang terkait dengan proyek.
  • Analisis Risiko : aktifitas ini diperlukan untuk memperkirakan risiko dari segi teknis maupun manajemen.
  • Rekayasa : aktifitas ini diperlukan untuk membangun satu atau lebih representasi dari aplikasi perangkat lunak (dapat berupa prototype).
  • Konstruksi dan peluncuran : aktifitas ini dibutuhkan untuk mengonstruksi,menguji,melakukan instalasi dan menyediakan dukungan terhadap user
  • Evaluasi Pelanggan : aktifitas ini dibutuhkan untuk mendapatkan umpan balik berdasarkan evaluasi representasi perangkat lunak yang dihasilkan dari proses rekayasa dan diimplementasikan pada tahap instalasi.
Berikut adalah gambar model spiral :

Ilustrasi Model Spiral

Setiap wilayah kerja terdiri dari kumpulan pekerjaan yang tergantung pada karakteristik proyek yang sedang dikerjakan.Semakin besar suatu proyek maka kumpulan pekerjaan di dalam setiap wilayah kerja juga semakin banyak.

Model spiral dilakukan searah jarum jam dimulai dari sumbu proyek.Sumbu proyek dapat digunakan sebagai awal iterasi atau evaluasi dari iterasi yang sudah dilakukan

Saran : model spiral cocok digunakan untuk mengembangkan aplikasi dengan skala besar tetapi target waktu dan biaya tidak terlalu mengikat.

Sekian pembahasan mengenai Model-Model SDLC !Sebenarnya masih ada beberapa model lagi,model tersebut akan dibahas di postingan berikutnya.Semoga ilmu yang dibagikan dapat bermanfaat !Terima Kasih !

Comments

  1. Mana model lainnya ?!!!!
    Model extreme programming enggak dicantumkan ?!!!!!
    Kalo gini doang sih, baca jurnal atawa buku juga banyak....coba dong bikin penjelasan yang enggak teoritis tapi berbobot !!!!

    ReplyDelete
    Replies
    1. jangan ke blog ini makanya bang, cari di tempat lain aja :)

      Delete

Post a Comment