SDLC (Software Development Life Cycle) dan Model - Modelnya

          SDLC singkatan dari Software Development Life Cycle atau kadang disebut juga System Development Life Cycle. Pada kesempatan ini akan dijelaskan tentang beberapa model SDLC yang sering digunakan. 

   1.     Pengertian SDLC

Pada awal pengembangan perangkat lunak, para pembuat program (programmer) langsung melakukan pengodean perangkat lunak tanpa menggunakan prosedur atau tahapan penhembangan perangkat lunak. Dan ditemuilah kendala-kendala seiring dengan perkembangan skala sistem-sistem perangkat yang semakin besar. SDLC dimulai dari tahun 1960-an, untuk mengembangkan sistem skala usaha besar secara fungsional untuk para konglomerat pada jaman itu. Sistem-sistem yang dibangun mengelola informasi kegiatan dan rutinitas dari perusahaan-perusahaan yang berpotensi memiliki data yang besar dalam perkembangannya.

SDLC adalah proses mengembangkan atau mengubah suatu sistem perangkat lunak dengan menggunakan model-model dan metodologi yang digunakan orang untuk mengembangkan sistem-sistem perangkat lunak sebelumnya (berdasarkan best practice atau cara-cara yang sudah teruji baik). Seperti halnya proses metamorfosis pada kupu-kupu, untuk menjadi kupu-kupu yang indah maka dibutuhkan beberapa tahap untuk dilalui, sama halnya dengan membuat perangkat lunak, memiliki daur tahapan yang dilalui agar mrnghasilkan perangkat lunak yang berkualitas.

Tahapan-tahapan yang ada pada SDLC secara global adalah sebagai berikut :

·    Inisiasi (initiation), pembuatan proposal proyek perangkat lunak

·    Pengembangan konsep sistem (sistem concept development), lingkup kosep sistem seperti dokumen sistem, analisa manfaat biaya, manajemen recana, dan pembelajaran kemudahan sistem.

·    Perencanaan (Planning), rencana manajemen proyek dan dokumen lainnya

·    Analisa Kebutuhan (requirement analysis), analisa kebutuhan user dan mengembangkan kebutuhan user.

·     Desain (design), mentransformasikan kebutuhan detail menjadi kebutuhan yang sudah lengkap.

·     Pengembangan (development), membuat basis data dan mempersiapkan prosedur pengujian, file pengujian, pengkodean, pengompilasian, peninjauan pengujian

·     Integrasi dan pengujian (integration and test), mendemontrasikan sistem perangkat lunak bahwa telah memenuhi kebutuhan yang dispesifikasikan pada dokumen kebutuhan fungsional

·     Implementasi (implementation), persiapan implementasi dan menjalankan resolusi dari permasalahan

·     Operasi dan Pemeliharaan (operations and maintenance), mengoperasikan dan memelihara sistem informasi

·      Disposisi (disposition), mendeskripsikan  aktifitas akhir dari pengembangan sistem dan membangun data yang sebenarnya sesuai dengan aktifitas user

      2.    Model SDLC

     

SDLC memiliki beberapa model dalam penerapan tahapan prosesnya. Beberapa model dasar akan dibahas pada subbab-subbab berikutnya. Selain model-model dasar yang akan dibahas, masih banyak model-model yang muncul dengan memodifikasi model-model SDLC dasar.

A.       Model Waterfall

Model SDLC air terjun (waterfall) sering juga disebut model sekuensial linier (sequential diagram) atau alur hidup klasik (classic life cycle). Model air terjun menyediakan pendekatan alur hidup perangkat lunak secara sekuensial atau terurut dimulai dari analisis, desain, pengodean, pengujian, dan tahap pendukung (support).

Ilustrasi Model Waterfall

• Analisis kebutuhan perangkat lunak. Proses pengumpulan kebutuhan dilakukan secara intensif untuk menspesifikasi kebuthuan perangkat lunak agar dapat dipahami perangkat lunak seperti apa yang dibutuhkan oleh user. Spesifikasi kebutuhan perangkat lunak pada tahap ini perlu di dokumentasikan.
• Desain. Desain perangkat lunak adalah proses multi langkah yang fokus pada desain pembuatan program perangkat lunak termasuk struktur data, arsitektur perangkat lunak, representasi antarmuka, dan prosedur pengodean.
• Pembuatan kode program. Desain juga harus ditranslasikan ke dalam program perangkat lunak. Hasil dari tahap ini adalah program komputer sesuai dengan desain yang telah dibuat pada tahap desain.
• Pengujian. Pengujian fokus pada perangkat lunak secara dari segi lojik 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.
• Pendukung (support) atau pemeliharaan (maintenance). Tidak menutup kemungkinan sebuah perangkat lunak mengalami perubahan ketika sudah dikirimkan ke user.tahap ini dapat mengulangi proses pegembangan mulai dari analisis spesifikasi untuk perubahan perangkat lunak yang sudah ada, tapi tidak untuk membuat perangkat lunak baru.

Dari kenyataannya yang terjadi sangat jarang model air terjun dapat dilakukan sesuai alurnya karena sebab berikut :

• Perubahan spesifikasi perangkat lunak terjadi di tengah alur pengembangan.
• Sangat sulit bagi pelanggan untuk mendefinisikan semua spesifikasi di awal alur pengembangan. Pelanggan sering kali butuh contoh (prototype) untuk menjabarkan spesifikasi kebutuhan sistem lebih lanjut.
• Pelanggan tidak mungkin bersabar mengakomodasi perubahan yang diperlukan di akhir alur pengembangan.

Dengan berbagai kelemahan yang dimiliki model air terjun tapi model ini telah menjadi dasar dari model-model yang lain dalam melakukan perbaikan model pengembangan perangkat lunak. 

Model air terjun sangat cocok digunakan kebutuhan pelanggan sudah sangat dipahami dan kemungkinan terjadinya perubahan kebutuhan selama pengembangan perangkat lunak kecil. Hal positif dari model ini adalah struktur tahap pengembangan sistem jelas, dokumentasi dihasilkan di setiap tahap pengembangan, dan sebuah tahap dijelaskan setelah tahap sebelumnya selesai dijalankan (tidak ada tumpang tindih pelaksanaan tahap).

Model waterfall adalah model SDLC yang paling sederhana. Model ini hanya cocok untuk pengembangan perangkat lunak dengan spesifikasi yang tidak berubah-ubah

B.     Model Prototipe

Model prototipe (prototyping model) dimulai dari mengumpulkan kebutuhan pelanggan terhadap perangkat lunak yang akan dibuat. Lalu dibuat program protipe agar pelanggan lebih terbayang dengan apa yang sebenarnya diinginkan. Program prototipe biasanya merupakan program yang belum jadi. Program ini biasanya menyediakan tampilan dengan simulasi alur perangkat lunak sehingga tampak seperti perangkat lunak yang sudah jadi. Program ini dievaluasi oleh pelanggan atau user sampai ditemukan spesifikasi yang sesuai dengan keinginan pelanggan atau user.

Ilustrasi Model Prototipe

Mock-up adalah sesuatu yang digunakan sebagai model desain yang digunakan untuk mengajar, demonstrasi, evaluasi desain, promosi, atau keperluan lain. Sebuah mock-up disebut sebagai protipe perangkat lunak jika mampu mendemonstrasikan sebagian besar fungsi sistem perangkat lunak.dan memungkinkan pengujian desain sistem perangkat lunak. Iterasi terjadi pada perbuatan prototipe sampai sesuai dengan keinginan pelanggan (customer) atau user.

Kelemahan model prototipe antara lain :

• Pelanggan sering mengubah-ubah atau menambah-tambah spesifikasi kebutuhan karena menganggap aplikasi sudah dengan cepat dikembangkan, karena adanya iterasi ini dapat menyebabkan pengembang banyak mengalah dengan pelanggan karena perubahan atau penambahan spesifikasi kebutuhan perangkat lunak.
• Pengembang lebih sering mengambil kompromi dengan pelanggan untuk mendapat prototipe dengan waktu yang cepat sehingga pengembang lebih sering melakukan segala cara (tanpa idealis) guna menghasilkan prototipe untuk didemonstrasikan. Hal ini dapat menyebabkan kualitas perangkat lunak yang kurang baik atau bahkan menyebabkan itertif tanpa akhir.

Permasalahan dapat di atasi dengan melakukan perjanjian antara pengembang perangkat lunak dengan pelanggan atau pengguna agar model ptototipe  hanya digunakan untuk mendefinisikan spesifikasi kebutuhan perangkat lunak, tapi tidak untuk seluruh proses pengembangan seluruh sistem perangkat lunak.

Model prototipe kurang cocok untuk aplikasi dengan skala besar karena membuat prototipe untuk aplikasi skala besar akan sangat memakan waktu dan tenaga.

Model prototipe ini cocok digunakan untuk menggali spesifikasi kebutuhan pelanggan secara lebih detail tetapi beresiko tinggi terhadap membengkaknya biaya dan waktu proyek.

C.      Model Rapid Application Development (RAD)

RAD adalah model proses pengembangan perangkat lunak yang bersifat inkremental terutama untuk waktu pengerjaan yang pendek. Model RAD adalah adaptasi dari model air terjun 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 pengembangan menjadi beberapa tim untuk mengerjakan beberapa komponen masing –masing tim pengerjaan dapat dilakukan secara paralel.

Ilustrasi Model RAD

• Pemodelan bisnis. Dilakukan untuk memodelkan fungsi bisnis unttuk mengetahui informasi apa yang terkait proses bisnis, informasi apa saja yang harus dibuat, siapa yang harus membuat informasi itu, 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 lain.
• Pemodelan proses. Mengimplementasikan fungsi bisnis yang sudah di definisikan terkait dengan pendefinisian data.
• Pembuatan aplikasi. Mengimplementasikan pemodelan proses dan data menjadi program. Model RAD sangat menganjurakan pemakaian komponen yang sudah ada jika dimungkinkan.  
• Pengujian dan pergantian. Menguji komponen-komponen yang di buat.

Kelemahan Model RAD antara lain :

•  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 tidak ada persetujuan untuk mengembangkan perangkat lunak secara cepat (rapid) maka proyek dengan model ini akan gagal karena hanya akan bingung mendefinisikan kebutuhan pelanggan atau user.
• 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 ini karena terlalu banyak campur tangan antar tim;
• Model RAD tidak cocok untuk sistem perangkat lunak yang memiliki resiko teknis sangat tinggi, misalnya 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;
• Pengembangan sudah memiliki komponen-komponen sistem yang bisa digunakan kembali dalam proyek tersebut.

D.      Model Iteratif

Model iteratif atau (iterative model) mengkombinasikan proses-proses pada model air terjun dan iteratif pada model prototipe. Model inkremental akan menghasilkan versi-versi perangkat lunak yang sudah mengalami penambahan fungsi untuk setiap pertambahannya (inkremen/increment).

Ilustrasi Model Iteratif

Model inkremental dibuat untuk mengatasi kelemahan dari model air terjunyang tidak mengakomodasikan iterasi, dan mengatasi kelemahan dari metode prototipe yang memiliki proses terlalu pendek dan setiap iteratif prosesnya tidak selalu menghasilkan produk (bisa jadi hanya prototipe). Model inkremental meghasilkan produk/aplikasi untuk setiap tahapan inkremen.

Model inkeremen sangat cocok digunakan jika staf yang dimiliki memiliki pergantian (turnover) yang tinggi sehingga staf 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.

Metode iteratif merupakan gabungan dari model waterfall dan model prototipe. Model ini cocok digunakan pengembangan dengan turnover staf yang tinggi.

E. Model Spiral.

Model spiral memasangkan iteratif pada model prototipe 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 (increment).

Model spiral dibagi menjadi beberapa kerangka aktifitas atau disebut juga wilayah kerja task region. Banyaknya wilayah kerja biasanya diantara tiga sampai enak wilayah sebagai berikut :

• Komunikasi dengan pelanggan (customer communication), aktifitas ini diperlukan untuk membangun komunikasi yang efektif antara pengembang dan pelanggan.
• Perencanaan (planning), untuk mendefinisikan sumber daya , waktu, dan informasi yang terkait dengan proyek.
• Analisa risiko (risk anaysis), untuk memperbaiki risiko dari segi teknis maupun manajemen.
• Rekayasa (engineering), untuk membangun satu atau lebih representasi dari aplikasi perangkat lunak (dapat juga berupa prototipe).
• Konstruksi dan peluncuran (construction and release). Untuk mengonstruksi menguji melakukan instalasi dan menyediakan dukungan terhadap iser (misalnya dari segi dokumentasi dan pelatihan).
• Evaluasi pelanggan (customer evaluation ). Untuk mendapatkan umpan balik berdasarkan evaluasi representasi perangkat lunak yang dihasilkan dari proses  rekayasa dan diimplementasikan pada instalasi.

Ilustrasi Model Spiral

Pada model spiral, hasil akhir dan evaluasi dari sebuah wilayah kerja akan menjadi inisiasi dari wilayah kerja berikutnya. Model spiral cocok digunakan untuk mengembangkan sistem perangkat lunak berskala besar karena memiliki proses analisa proses analisis risiko yang dapat sangat meminimalisir risiko yang kemungkinan terjadi. Model spiral memungkinkan pengembangan untuk menggunakan prototipe pada setiap tahap untuk mengurangi risiko.

Dari beberapa model SDLC yang sudah disebutkan sebelumnya, model spiral merupakan model yang bisa memberikan jaminan kualitas yang paling baik untuk aplikasi berskala besar. Penerapan model spiral cocok digunakan untuk suatu proyek dengan target waktu dan biaya yang tidak terlalu ketat. Setiap perubahan spesifikasi pasti berisiko pada molornya waktu pengerjaan dan membengkaknya biaya proyek.

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


DAFTAR PUSTAKA 

A.S, Rosa. M. Shalahuddin. 2016. Rekayasa Perangkat Lunak (Terstruktur dan Berorientasi Objek). Bandung: Informatika Bandung.