Berikut Metode-Metode Pengembangan Perangkat Lunak (Model Proses Pengembangan
Perangkat Lunak) yaitu metode Sekuensial Linier, prototype, RAD :
A.
Sekuensial Linier
Model
sekuensial adalah paradigm rekayasa perangkat lunak yang paling luas dipakai
dan paling tua. Sering juga disebut dengan “siklus kehidupan klasik”
atau “model air terjun.” Penggambaran model ini :
Gb. Fase lingkaran pemecahan masalah
Gb. Model sekuensial linier
1. Rekayasa dan pemodelan sistem/informasi
Karena sistem merupakan
bagian dari sebuah sistem yang lebih besar, kerja dimulai dengan membangun
syarat dari semua elemen sistem dan mengalokasikan beberapa subset dari
kebutuhan ke software tersebut. Pandangan sistem ini penting ketika software
harus berhubungan dengan elemen-elemen yang lain seperti software, manusia, dan
database. Rekayasa dan anasisis system menyangkut pengumpulan kebutuhan pada
tingkat sistem dengan sejumlah kecil analisis serta disain tingkat puncak.
Rekayasa informasi mancakup juga pengumpulan kebutuhan pada tingkat bisnis
strategis dan tingkat area bisnis.
2. Analisis kebutuhan Software
Proses pengumpulan
kebutuhan diintensifkan dan difokuskan, khusunya pada software. Untuk memahami
sifat program yang dibangun, analis harus memahami domain informasi, tingkah
laku, unjuk kerja, dan interface yang diperlukan. Kebutuhan baik untuk sistem
maupun software didokumentasikan dan dilihat lagi dengan pelanggan.
3. Desain
Desain software
sebenarnya adalah proses multi langkah yang berfokus pada empat atribut sebuah
program yang berbeda struktur data, arsitektur software, representasi
interface, dan detail (algoritma) prosedural. Proses desain menterjemahkan
syarat/kebutuhan ke dalam sebuah representasi software yang dapat diperkirakan
demi kualitas sebelum dimulai pemunculan kode. Sebagaimana persyaratan, desain
didokumentasikan dan menjadi bagian dari konfigurasi software.
4. Generasi Kode
Desain harus
diterjemahkan kedalam bentuk mesin yang bisa dibaca. Langkah pembuatan kode
melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan
kode dapat diselesaikan secara mekanis.
5. Pengujian
Sekali program dibuat,
pengujian program dimulai. Proses pengujian berfokus pada logika internal
software, memastikan bahwa semua pernyataan sudah diuji, dan pada eksternal
fungsional, yaitu mengarahkan pengujian untuk menemukan kesalahan – kesalahan
dan memastikan bahwa input yang dibatasi akan memberikan hasil aktual yang
sesuai dengan hasil yang dibutuhkan.
6. Pemeliharaan
Software akan mengalami
perubahan setelah disampaikan kepada pelanggan (perkecualian yang mungkin
adalah software yangdilekatkan). Perubahan akan terjadi karena kesalahan –
kesalahan ditentukan, karena software harus disesuaikan untuk mengakomodasi
perubahan – perubahan di dalam lingkungan eksternalnya (contohnya perubahan
yang dibutuhkan sebagai akibat dari perangkat peripheral atau sistem operasi
yang baru), atau karena pelanggan membutuhkan perkembangan fungsional atau
unjuk kerja. Pemeliharaan software mengaplikasikan lagi setiap fase program
sebelumnya dan tidak membuat yang baru lagi.
KEKURANGAN MODEL SEKUENSIAL LINEAR
Masalah yang kadang terjadi ketika model
sekuensial linier diaplikasikan adalah :
1. Jarang sekali proyek nyata mengikuti aliran
sekuensial yang dianjurkan oleh model. Meskipun model linier bisa mengakomodasi
iterasi, model ini melakukannya dengan cara tidak langsung. Sebagai hasilnya,
perubahan – perubahan dapat menyebabkan keraguan pada saat tim proyek berjalan.
2. Kadang – kadang sulit bagi pelanggan untuk
menyatakan semua kebutuhannya secara eksplisit. Model linier sekuensial
memerlukan halini dan mengalami kesulitan untuk mengakomodasi
ketidakpastiannatural yang ada pada bagian awal beberapa proyek.
3. Pelanggan harus bersifat sabar. Sebuah versi
kerja dari program – program kerja itu tidak akan diperoleh sampai akhir waktu
proyek dilalui. Sebuah kesalahan besar, jika tidak terdeteksi sampai program
yang bekerja tersebut dikaji ulang, bisa menjadi petaka
4. Pengembang sering melakukan penundan yang
tidak perlu. Sifat alami dari siklus kehidupan klasik membawa kepada blocking
state di mana banyak anggota tim proyek harus menunggu tim yang lain untuk
melengkapi tugas yang saling memiliki ketergantungan. Blocking state cenderung
menjadi lebih lazim pada awal dan akhir sebuah proses sekuensial linier
KELEBIHAN MODEL SEKUENSIL LINIER
1. Software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik.
2. Document pengembangan sistem sangat
terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum
melangkah ke fase berikutnya.
B. Prototype
Model ini dimulai dengan pengumpulan kebutuhan. Pendekatan
prototyping model digunakan jika pemakai hanya mendefenisikan objektif umum dari
perangkat lunak tanpa merinci kebutuhan input, pemrosesan dan outputnya,
sementara pengembang tidak begitu yakin akan efisiensi algoritma, adaptasi
sistem operasi, atau bentuk antarmuka manusia-mesin yang harus diambil. Cakupan
aktivitas dari prototyping model terdiri dari :
a. Mendefinisikan objektif secara
keseluruhan dan mengidentifikasi kebutuhan yang sudah diketahui.
b. Melakukan perancangan secara cepat
sebagai dasar untuk membuat prototype.
c. Menguji coba dan mengevaluasi prototype dan
kemudian melakukan penambahan dan perbaikan- perbaikan terhadap prototype
yang sudah dibuat.
Secara ideal prototype
berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan perangkat
lunak. Bila prototype yang sedang bekerja dibangun, pengembang harus
menggunakan fragmen-fragmen program yang ada atau mengaplikasikan alat-alat
bantu (contoh: window manager, dsb) yang memungkinkan program yang bekerja agar
dimunculkan secara cepat.
Kelemahan prototyping model :
1. Pelanggan
yang melihat working version dari model yang dimintanya tidak menyadari, bahwa
mungkin saja prototype dibuat terburu-buru dan rancangan tidak tersusun dengan
baik
2. Pengembang kadang-kadang
membuat implementasi sembarang, karena ingin working version bekerja dengan cepat
C. RAD (Rapid Application Development)
Merupakan model proses pengembangan perangkat lunak secara linear sequential
yang menekankan pada siklus pengembangan yang sangat singkat/pendek. Jika
kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan
menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat
pendek (kira-kira 60-90 hari). Pendekatan RAD model menekankan cakupan :
a. Pemodelan Bisnis
Aliran informasi diantara
fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab
pertanyaan-pertanyaan berikut : Informasi apa yang mengendalikan proses bisnis
? Kemana informasi itu pergi? Siapa yang memprosesnya ?
b.
Pemodelan Data
Aliran informasi yang didefinisikan sebagai bagian dari fase pemodelan
bisnis disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang
bisnis tersebut. Karakteristik/atribut dari masing-masing objek diidentifikasi
dan hubungan antara objek-objek tersebut didefinisikan.
c. Pemodelan Proses
Aliran informasi
yang didefinisikan dalam fase pemodelan data ditransformasikan untuk mencapai
aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran
pemrosesan diciptakan untuk menambah, memodifikasi, menghapus atau mendapatkan
kembali sebuah objek data.
d. Pembuatan Aplikasi
Selain menciftakan
perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang
konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen
program yang telah ada atau menciftakan komponen yang bias dipakai lagi. Pada
semua kasus, alat-alat Bantu otomatis dipakai untuk memfasilitasi kontruksi
perangkat lunak.
e. Pengujian dan Pergantian
Karena proses RAD menekankan pada pemakaian kembali, banyak komponen yang telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tapi komponen baru harus diuji.
Kelemahan
model RAD :
1. Untuk proyek dengan skala
besar, RAD membutuhkan sumber daya manusia yang cukup untuk membentuk sejumlah
tim RAD yang baik.
2. RAD membutuhkan pengembang dan pemakai yang mempunyai komitmen dalam aktivitas rapid-fire untuk melaksanakan aktivitas melengkapi sistem dalam kerangka waktu yang singkat. Jika komitmen tersebut tidak ada, proyek RAD gagal.
Tidak semua aplikasi sesuai untuk RAD.bila system tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat problematic. RAD menjadi tidak sesuai jika risiko teknisnya tinggi.
(sumber : ugm.ac.id & andisulaeman.weebly.com)