SDLC (Systems
Development Life Cycle) dalam rekayasa sistem dan rekayasa perangkat lunak
adalah proses pembuatan dan pengubahan sistem serta model dan metodologi yang
digunakan untuk mengembangkan sistem-sistem tersebut. Konsep ini umumnya
merujuk pada sistem komputer atau informasi. Dalam rekayasa perangkat lunak,
konsep SDLC mendasari berbagai jenis metodologi pengembangan perangkat lunak.
Metodologi-metodologi ini membentuk suatu kerangka kerja untuk perencanaan dan
pengendalian pembuatan sistem informasi, yaitu proses pengembangan perangkat
lunak. Dibawah ini saya akan mencoba memaparkan beberapa model pengembangan
perangkat lunak:
a. Metode Waterfall
Model waterfall mengusulkan
sebuah pendekatan kepada perkembangan software yang sistematik dan sekuensial
yang mulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain,
kode, pengujian, dan pemeliharaan. Model ini melingkupi aktivitas – aktivitas
sebagai berikut : rekayasa dan
pemodelan sistem/informasi, analisis kebutuhan, desain, coding, pemeliharaan dan pengujian.
Setiap phase pada Waterfall dilakukan secara berurutan namun kurang dalam
iterasi pada setiap level.
Kelebihan:
·
Dituntut bekerja secara disiplin
·
Dokumen lengkap
·
Selalu dalam kontrol SQA
·
Maintenance mudah, karena dokumen lengkap
Kekurangan:
·
Konsumen kesulitan membaca dokumen, komunikasi menjadi sulit
·
Alur linier, proses lambat
·
Konsumen tidak dapat melihat hasil hingga akhir tahapan
· Personil
tidak bekerja optimal, karena ada waktu tunggu sebuah tahapan selesai
b.Model
Prototype
Model prototype dimulai
dengan pengumpulan kebutuhan. Pengembang dan user bertemu dan mendefinisikan
obyektif keseluruhan dari software, mengidentifikasi segala kebutuhan yang
diketahui, dan area garis besar dimana definisi lebih jauh merupakan keharusan
kemudian dilakukan “perancangan kilat”.
Perancangan kilat
berfokus pada penyajian dari aspek – aspek software tersebut yang akan nampak
bagi user atau pemakai (contohnya pendekatan input dan format output).
Perancangan kilat membawa kepada konstruksi sebuah prototype. Prototype
tersebut dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaring
kebutuhan pengembangan software. Iterasi terjadi pada saat prototype disetel
untuk memenuhi kebutuhan pelanggan, dan pada saat yang sama memungkinkan
pengembang untuk secara lebih baik memahami apa yang harus dilakukannya.
Kelebihan
:
- Prototype melibatkan
user dalam analisa dan desain.
- Punya kemampuan
menangkap requirement secara konkret daripada secara abstrak.
- Untuk digunakan secara
standalone.
- Digunakan untuk
memperluas SDLC.
- Mempersingkat waktu
pengembangan Sistem Informasi
Kekurangan
:
- Proses analisis dan perancangan
terlalu singkat.
- Mengesampingkan alternatif
pemecahan masalah.
- Bisanya kurang fleksible dalam
mengahdapi perubahan.
- Protitype yang dihasilkan tidak
selamanya mudah dirubah
- Protype terlalu cepat selesai
c. Model
Rapid Aplication Development
Rapid Application
Development (RAD) adalah
sebuah model proses perkembangan software sekuensial linier yang menekankan
siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi
“kecepatan tinggi” dari model sekuensial linier di mana perkembangan cepat
dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Jika
kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan
menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat
pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi
sistem konstruksi, pendekatan RAD melingkupi fase – fase sebagai berikut : bussiness
modeling, data modeling, process modeling, application
generation dan testing and turnover.
Beberapa kategori RAD misalnya Phased
Development, Prototyping dan Throw-away Prototyping.
Kelebihan :
- RAD mengikuti tahapan pengembangan
sistem sepeti umumnya, tetapi mempunyai kemampuan untuk menggunakan kembali
komponen yang ada (reusable object).
- Setiap fungsi dapat dimodulkan dalam
waktu tertentu dan dapat dibicarakan oleh tim RAD yang terpisah dan kemudian
diintegrasikan sehingga waktunya lebih efesien.
Kekurangan :
- Tidak cocok untuk proyek skala
besar.
- Proyek bisa gagal karena waktu yang
disepakati tidak dipenuhi.
- Sistem yang tidak bisa
dimodularisasi tidak cocok untuk model ini.
- Resiko
teknis yang tinggi juga kurang cocok untuk model ini.
d.
Model
Spiral / Incremental
Model spiral (spiral
model) adalah model proses software yang evolusioner yang merangkai sifat
iteratif dari prototipe dengan cara kontrol dan aspek sistematis dari model
sekuensial linier. Model ini berpotensi untuk pengembangan versi pertambahan
software secara cepat. Di dalam model spiral, software dikembangkan di dalam
suatu deretan pertambahan. Selama awal iterasi, rilis inkremental bisa
merupakan sebuah model atau prototipe kertas. Selama iterasi berikutnya,
sedikit demi sedikit dihasilkan versi sistem rekayasa yang lebih lengkap.
Model spiral
dibagi menjadi sejumlah aktifitas kerangka kerja, disebut juga wilayah tugas,
di antara tiga sampai enam wilayah tugas, yaitu : komunikasi pelanggan yang
dibutuhkan untuk membangun komunikasi yang efektif di antara pengembangan dan
pelanggan, perencanaan yang dibutuhkan untuk mendefinisikan sumber – sumber
daya, ketepatan waktu, dan proyek informasi lain yang berhubungan, analisis
risiko yang dibutuhkan untuk menperhitungkan resiko (manajemen maupun teknis),
perekayasaan yang dibutuhkan untuk membangun satu atau lebih representasi dari
aplikasi tersebut, konstruksi dan peluncuran yang dibutuhkan untuk
mengkonstruksi dan menguji serta memasang (instal) dan memberikan pelayanan
kepada user (contohnya pelatihan dan dokumentasi) dan bagian evaluasi user yang
dibutuhkan untuk memperoleh umpan balik dari user dengan didasarkan pada
evaluasi representasi software, yang dibuat selama masa perekayasaan, dan
diimplementasikan selama masa pemasangan.
Kelebihan:
• ditekankan pada pencairan
alternatif, dan pemaksaan penggunaan kembali Software yang telah ada
• Analisa resiko
• Adanya prototype memudahkan
komunikasi dengan konsumen
Kekurangan:
• Biasanya pihak
pengembang dan perusahaan berada pada satu pihak yang sama
• Tahapan analisa resiko sewaktu-waktu
dapat membatalkan proses rekayasa, jika pihak pengembang adalah pihak di luar
perusahaan, maka timbulah masalah hukum