PENGEMBANGAN PERANGKAT LUNAK SDLC

2.1          Pengertian SDLC

Pada awal pengembangan perangkata lunak, para pembuat program (programmer) langsung melakukan pengodean perangkat lunak tanpa menggunakan prosedur atau tahapan pengembangan perangkat lunak. Dan ditemuilah kendala-kendala seiring dengan perkembangan skala system-sistem perangkat yang semakin besar.

SDLC dimulai dari tahun 1960-an, untuk mengembangkan system skala usaha besar secara fungsional untuk para konglomerat pada jaman itu. System-sytem yang dibangun mengelola informasi kegiatan dan rutinitas dari perusahaan-perusahaan yang berpotensi memiliki data yang lebih besar lagi dalam pengembangannya.

SDLC atau Software Development Life Cycle atau sering disebut juga System Development Life Cycle adalah proses mengembangkan asta mengubah suatu sustem perangkat lunak dengan menggunakan model-model dan metodologi yang digunakan orang untuk mengembangkan system-sistem perangkat lunak sebelumnya (berdasarkan best pratictice atau cara-cara yang sudah teruji baik). Seperti halnya proses metamorphosis 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 menghasilkan perangkat lunak yang berkualitas.

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

a.       Inisiasi (initiation)

Tahap ini biasanya ditandai dengan pembuatan proposal proyek perangkat lunak.

b.      Pengembangan konsep system (system concept development)

Mendefiniskan lingkup konsep termasuk dokumen lingkup system, analisis manfaat biaya, manajemen rencana dan pembelajran kemudahan system.

c.       Perencanaan (planning)

Mengembangakn rencana menajemen proyek dan dokumen perencanaan lainnya. Menyediakan dasar untuk mendapatkan sumber data (resourced) yang dibutuhkan untuk memperoleh solusi.

d.      Analisi kebutuhan (requirements analysis)

Menganalisis kebutuhan pemakai system peangkat lunak (user) dan mengembangkan kebutuhan user. Membuat dokumen kebutuhan fungsional.

e.       Desain (design)

Mentranformasikan kebutuhan detail menjadi kebutuhan yang sudah lengkap, dokumen desain system focus pada bagaimana dapat memenuhi fungsi-fungsi yang dibutuhkan.

f.       Pengembangan (development)

Mengonversi desain ke system informasi yang lengkap termasuk bagaimana memperoleh dan melakukan instalasi lingkungan system yang dibutuhkan, membuat basis data dan mempersiapkan prosedur kasus pengujian, mempersiapkan berkas atau file pengujian, pengodean, pengompilasian, memperbaiki dan membersihkan program, peninjauam pengujian.

g.      Integrasi dan pengujian (integration and test)

Mendemontrasikan system perangkat lunak bahwa telah memenuhi kebutuhan yang dispesifikasikan pada dokumen kebutuhan fungsioanl. Dengan diarahkan oleh staf penjamin kuaita dan user. Menghasilkan laporan analisi pengujian.

h.      Implementasi (implementation)

Termasuk pada persiapan implementasi, implementasi perangkat lunak pada lingkunganproduksi (lingkungan pada user) dan menjalankan resolusi dari permasalahan yang teridentifikasi dari fase integrasi dan pengujian.

i.        Operasi dan pemeliharaan (operations and maintenance)

Mendeskripsikan pekerjaan untuk mengoperasikan dan meme;ihara system informasi pada lingkungan produksi (lingkungan pada user), termasuk implementasi akhir dan masuk pada proses peninjauan.

j.        Disposisi (disposition)

Mendeskripsikan aktifitas akhir dari pemngembangan system dan membangun data yang sebenarnya sesuai dengan aktifitas user.

Analisi dan desain sering dikelompokkan sebagai proses system/rekayasa informasi karena pada tahapan inilah informasi mengenai kebutuhan perangkat lunak banyak dikumpulkan dan diintegrasikan. Ada beberapa model SDLC yang dapat digunakan. Semuanya memiliki kelemhan dan kelebihan pada setiap model SDLC. Hal terpenting adalah mengenali tipe pelanggan (customer) dan memilih menggunakan model SDLC yangsesuai dengan karakter pelanggan (customer) dan sesuai dengan karakter pengembang.

2.2          Model SDLC

2.2.1     Waterfall Model

Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini adalah model yang muncul pertama kali yaitu sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance.

Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement. Secara umum tahapan pada model waterfall dapat dilihat pada gambar berikut :

Kelebihan waterfall model :

a.       Menghasilkan mature process pada setiap tahapannya.

b.      Mudah untuk diaplikasikan pada sebuah proyek.

c.       Menghasilkan sistem yang terstuktur dengan baik.

d.      Memiliki tingkat visibilitas yang tinggi (setiap tahap mempunyai dokumen yang jelas).

Kelemahan waterfall model:

a.       Ketidakfleksibelan antar tahapan.

b.      Susah dalam merespon kebutuhan customer.

2.2.2     V Model

Bisa dikatakan model ini merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena tahap-tahapnya mirip dengan yang terdapat dalam model waterfall. Jika dalam model waterfall proses dijalankan secara linear, maka dalam model V proses dilakukan bercabang. Dalam model V ini digambarkan hubungan antara tahap pengembangan software dengan tahap pengujiannya.

Kelebihan v model :

a.       V Model sangat fleksibel. V Model mendukung project tailoringdan penambahan dan pengurangan method dantool secara dinamik. Akibatnya sangat mudah untuk melakukan tailoring pada V Model agar sesuai dengan suatu proyek tertentu dan sangat mudah untuk menambahkan method dan tool baru atau menghilangkanmethod dan tool yang dianggap sudah obsolete.

b.      V Model dikembangkan dan di-maintainoleh publik. Userdari V Model berpartisipasi dalam change control boardyang memproses semua change request terhadap V Model.

Kekurangan v model :

a.       V Model adalah model yang project orientedsehingga hanya bisa digunakan sekali dalam suatu proyek.

b.      V Model terlalu fleksibel dalam arti ada beberapa activitydalam V Model yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalamactivitytersebut dan apa yang tidak.

2.2.3     Incremental Process Model

Model incremental (Incremental waterfall model) merupakan perbaikan dari  model waterfall dan sebagai standar pendekatan top-down. Ide dasar dari model ini adalah membangun software secara meningkat (increment) berdasarkan kemampuan fungsional. Model incremental ini diaplikasikan pada sistem pakar dengan penambahan rules yang mengakibatkan bertambahnya kemampuan fungsional sistem

Kelebihan Incremental Model :

a.       Personil bekerja optimal

b.      Pihak konsumen dapat langsung menggunakan dahulu bagian-bagian yang telah selesai dibangun. COntohnya pemasukan data karyawan

c.       Mengurangi trauma karena perubahan sistem.  Klien dibiasakan perlahan-lahan menggunakan produknya bagian per bagian

d.      Memaksimalkan pengembalian modal investasi konsumen

Kekurangan Incremental Model :

a.       kemungkinan tiap bagian tidak dapat diintegrasikan

b.      Dapat menjadi build and Fix Model, karena kemampuannya untuk selalu mendapat perubahan selama proses rekayasa berlangsung

2.2.4     Rapid Application Development (RAD)

Rapid application development (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan. Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final.

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 :

a.       Tidak cocok untuk proyek skala besar.

b.      Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi.

c.       Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini.

d.      Resiko teknis yang tinggi juga kurang cocok untuk model ini.

2.2.5     Prototyping

Prototype merupakan metodologi pengembangan software yang menitik-beratkan pada pendekatan aspek desain, fungsi dan user–interface. Developer dan user fokus pada user-interface dan bersama-sama mendefinisikan spesifikasi, fungsi, desain dan bagaimana software bekerja.

Developer dan user bertemu dan melakukan komunikasi  dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan. Developer mengumpulkan detail dari kebutuhan dan memberikan suatu gambaran dengan cetak biru (prototype).

Keunggulan prototyping adalah:

a.       Adanya komunikasi yang baik antara pengembang dan pelanggan

b.      Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan

c.       Pelanggan berperan aktif dalam pengembangan sistem

d.      Lebih menghemat waktu dalam pengembangan sistem

e.       Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.

Kelemahan prototyping adalah :

a.       Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangja waktu lama.

b.      Pengembang biasanya ingin cepat menyelesaikan proyek. Sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan cetak biru sistem.

c.       Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik

2.2.6     Concurrent Process Model

Model proses konkuren sering digunakan sebagai paradigma bagi pengembangan aplikasi klien/server. Sistem klien/server dirancang dari serangkaian komponen fungsional. Bila diaplikasikan kepada klien/server, model proses konkuren akan mendefinisikan aktivitas di dalam dua dimensi : dimensi sistem, dan dimensi komponen. Isu tingkat sistem ditujudengan menggunakan tiga aktivitas : desain, assembly, dan pemakaian. Dimensi komponen dituju dengan dua aktivitas : desain dan rea-lisasi.

Kelebihan concurrent model :

Proses konkuren model ini berlaku untuk semua jenis pengembangan perangkat lunak dan memberikan gambaran yang akurat tentang keadaan sekarang dari suatu proyek

Kekurangan concurrent model :

statenya sangat banyak sehingga membutuhkan waktu lebih banyak.

2.2.7     Spiral model

Model spiral adalah model proses perangkat lunak yang evolusioner yang merangkai sifat iteratif dari prototipe dengan cara kontrol dan aspek sistematis dari model sekuensial linier. Model itu berpotensi untuk pengambangan versi pertambahan perangkat lunak secara cepat.

Kelebihan model Spiral :

a.       Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak komputer.

b.      Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar

c.       Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi  terhadap resiko  setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses .

d.      Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiap keadaan di dalam evolusi produk.

e.       Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan memasukkannya ke dalam kerangka kerja iteratif .

f.       Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi resiko sebelum menjadi permaslahan yang serius.

Kelemahan model Spiral:

a.       Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa dikontrol.

b.      Memerlukan  penaksiran resiko yang masuk akal dan akan menjadi masalah yang serius jika  resiko mayor tidak ditemukan dan diatur.

c.       Butuh  waktu lama untuk menerapkan paradigma ini  menuju kepastian yang absolut