Tuesday, December 06, 2011

Model-model SDLC

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


No comments:

Post a Comment