Prototyping
Prototyping merupakan salah satu metode pengembangan
perangat lunak yang banyak digunakan. Dengan metode prototyping ini pengembang
dan pelanggan dapat saling berinteraksi selama proses pembuatan sistem.
Sering terjadi seorang pelanggan hanya mendefinisikan
secara umum apa yang dikehendakinya tanpa menyebutkan secara detal output apa
saja yang dibutuhkan, pemrosesan dan data-data apa saja yang dibutuhkan.
Sebaliknya disisi pengembang kurang memperhatikan efesiensi algoritma,
kemampuan sistem operasi dan interface yang menghubungkan manusia dan komputer.
Untuk mengatasi ketidakserasian antara pelanggan dan
pengembang , maka harus dibutuhkan kerjasama yanga baik diantara keduanya
sehingga pengembang akan mengetahui dengan benar apa yang diinginkan pelanggan
dengan tidak mengesampingkan segi-segi teknis dan pelanggan akan mengetahui
proses-proses dalam menyelasaikan sistem yang diinginkan. Dengan demikian akan
menghasilkan sistem sesuai dengan jadwal waktu penyelesaian yang telah
ditentukan.
Kunci agar model prototype ini berhasil dengan baik
adalah dengan mendefinisikan aturan-aturan main pada saat awal, yaitu pelanggan
dan pengembang harus setuju bahwa prototype dibangun untuk mendefinisikan
kebutuhan. Prototype akan dihilangkan sebagian atau seluruhnya dan perangkat
lunak aktual aktual direkayasa dengan kualitas dan implementasi yang sudah
ditentukan
Tahapan-Tahapan
Prototyping
Tahapan-tahapan dalam Prototyping adalah sebagai berikut:
1.
Pengumpulan kebutuhan Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak,
mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.
2. Membangun prototyping Membangun prototyping dengan membuat perancangan
sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan
membuat input dan format output)
3. Evaluasi protoptyping Evaluasi ini
dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai
dengan keinginann pelanggan. Jika sudah sesuai maka langkah 4 akan diambil.
Jika tidak prototyping direvisi dengan mengulangu langkah 1, 2 , dan 3.
4. Mengkodekan sistem Dalam tahap ini
prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman
yang sesuai
5.
Menguji sistem Setelah sistem sudah
menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum
digunakan. Pengujian ini dilakukan
dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain
6.
Evaluasi Sistem Pelanggan mengevaluasi
apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Juka ya,
langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5.
7.
Menggunakan sistem Perangkat lunak yang
telah diuji dan diterima pelanggan siap untuk digunakan .
Keunggulan dan Kelemahan Prototyping
Keunggulan
prototyping adalah:
1.
Adanya komunikasi yang baik antara
pengembang dan pelanggan
2.
Pengembang dapat bekerja lebih baik
dalam menentukan kebutuhan pelanggan
3.
Pelanggan berperan aktif dalam
pengembangan sistem
4.
Lebih menghemat waktu dalam pengembangan
sistem
5.
Penerapan menjadi lebih mudah karena
pemakai mengetahui apa yang diharapkannya.
Kelemahan
prototyping adalah :
1.
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.
2.
penegmbang 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 .
3.
Hubungan pelanggan dengan komputer yang
disediakan mungkin tidak mencerminkan
teknik perancangan yang baik
Prototyping bekerja dengan baik pada penerapan-penerapan yang berciri
sebagai berikut:
1.
Resiko tinggi yaitu untuk masalah-masalah
yang tidak terstruktur dengan baik, ada perubahan yang besar dari waktu ke
waktu, dan adanya persyaratan data yang tidak menentu.
2.
Interaksi pemakai penting . Sistem harus
menyediakan dialog on-line antara pelanggan dan komputer.
3.
Perlunya penyelesaian yang cepat
4.
Perilaku pemakai yang sulit ditebak
5.
Sitem yang inovatif. Sistem tersebut
membutuhkan cara penyelesaian masalah dan penggunaan perangkat keras yang
mutakhir
6.
Perkiraan
tahap penggunaan sistem yang pendek
Prototipe bisa juga menjadi masalah karena alasan sebagai
berikut:
1.
Pelanggan
melihat apa yang tampak sebagai versi software yang bekerja tanpa melihat bahwa
prototipe itu dijalin bersama – sama “dengan permen karet dan baling wire”,
tanpa melihat bahwa di dalam untuk membuatnya bekerja, kita belum menyantumkan
kualitas software secara keseluruhan atau kemampuan pemeliharaan untuk jangka
waktu yang panjang. Ketika diberi informasi bahwa produk harus dibangun lagi
agar tingkat kualitas yang tinggi bisa dijaga, pelanggan akan meneriakan
kecurangan dan permintaan agar dipakai “beberapa campuran” untuk membuat
prototipe menjadi sebuah produk yang bekerja yang lebih sering terjadi,
sehingga manajemen pengembangan software menjadi penuh dengan belas kasihan.
2.
Pengembang
sering membuat kompromi – kompromi implementasi untuk membuat prototipe bekerja
dengan cepat. Sistem operasi atau bahasa pemrograman yang tidak sesuai bisa
dipakai secara sederhana karena mungkin diperoleh dan dikenal; algoritma yang
tidak efisien secara sederhana bisa diimplementasikan untuk mendemonstrasikan
kemampuan. Setelah selang waktu tertentu, pengembang mungkin mengenali pilihan
– pilihan tersebut dan melupakan semua alasan mengapa mereka tidak cocok.
Pilihan yang kurang ideal telah menjadi bagian integral dari sebuah sistem.
Meskipun berbagai masalah bisa terjadi, prototipe bisa
menjadi paradigm yang efektif bagi Software Engineering. Kuncinya adalah
mendefinisikan aturan main pada saat awal; yaitu pelanggan dan pengembang
keduanya harus setuju bahwa prototipe dibangun untuk berfungsi sebagai
mekanisme pendefinisian kebutuhan. Prototipe kemudian disingkirkan (paling
tidak sebagian), dan software aktual direkayasa dengan tertuju kepada kualitas
dan kemampuan pemeliharaan.
2.
METODE RAD ( RAPID APPLICATION DEVELOPMENT )
Rapid Aplication 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 :
1.
Bussiness modeling
Aliran informasi di antara fungsi – fungsi bisnis dimodelkan dengan suatu
cara untuk menjawab pertanyaan – pertanyaan berikut : informasi apa yang
mengendalikan proses bisnis? Informasi apa yang di munculkan? Siapa
yang memunculkanya? Ke mana informasi itu pergi? Siapa yang memprosesnya?
2.
Data modeling Aliran informasi yang
didefinisikan sebagai bagian dari fase bussiness modelling disaring ke dalam
serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut.
Karakteristik (disebut atribut) masing – masing objek diidentifikasi dan
hubungan antara objek – objek tersebut didefinisikan.
3. Prosess modelling Aliran informasi yang didefinisikan di dalam
fase data modeling 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.
4. Aplication generation RAD mengasumsikan pemakaian teknik generasi
ke empat. Selain menciptakan perangkat lunak dengan menggunakan bahasa
pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja
untuk memkai lagi komponen program yang ada ( pada saat memungkinkan) atau
menciptakan komponen yang bisa dipakai lagi (bila perlu). Pada semua kasus,
alat – alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat
lunak.
5. Testing and turnover Karena proses RAD menekankan pada pemakaian kembali, banyak komponen
program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi
komponen baru harus di uji dan semua interface harus dilatih secara penuh.
Keunggulan dan Kelemahan Model RAD
1. Keunggulan Model RAD
·
Setiap fungsi mayor dapat dimodulkan
dalam waktu tertentu kurang dari 3 bulan dan dapat dibicarakan oleh tim RAD
yang terpisah dan kemudian diintegrasikan sehinnga waktunya lebih efesien.
·
RAD mengikuti tahapan pengembangan
sistem sepeti umumnya, tetapi mempunyai kemampuan untuk menggunakan kembali
komponen yang ada (reusable object) sehingga pengembang pengembang tidak
perlu membuat dari awal lagi dan waktu lebih singkat .
2. Kelemahan Model RAD :
·
Proyek yang besar dan berskala, RAD
memerlukan sumer daya manusia yang memadai untuk menciptakan jumlah tim yang
baik.
·
RAD menuntut pengembang dan pelanggan
memiliki komitmen dalam aktivitas rapid fire yang diperlukan untuk melengkapi
sebuah sistem dlam waktu yang singkat. Jiak komitmen tersebut tidak ada maka
proyek RAD akan gagal.
3.
METODE
SDLC / WATERFALL
Model ini 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. Dimodelkan setelah siklus rekysa konvensional, model sekuensial
linier melingkupi aktivitas – aktivitas sebagai berikut :
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 sistem
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 yang dilekatkan).
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.
Gambar 2.1 Model SDLC
Masalah yang kadang terjadi ketika model SDLC
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 hal ini
dan mengalami kesulitan untuk mengakomodasi ketidakpastian natural 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.
Keunggulan dan Kelemahan Model
SDLC
·
Keunggulan
1.
Mudah aplikasikan
2.
Memberikan template tentang metode analisis, desain,
pengkodean, pengujian, dan pemeliharaan
·
Kelemahan
1.
Jarang sekali proyek riil mengikuti aliran sekuensial
yang dianjurkan model karena model ini bisa melakukan itersi tidak langsung .
Hal ini berakibat ada perubahan yang diragukan pada saat proyek berjalan.
2.
Pelanggan sulit untuk menyatakan kebutuhan secara
eksplisit sehingga sulit untuk megakomodasi ketidakpastian pada saat awal
proyek.
3.
Sebuah kesalahan jika tidak diketahui dari awal akan
menjadi masalah besar karena harus mengulang dari awal.
5.
METODE
INCREMENTAL
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. Keuntungan dari model ini adalah bahwa penambahan kemampuan fungsional
akan lebih mudah diuji, diverifikasi, dan divalidasi dan dapat menurunkan biaya
yang dikeluarkan untuk memperbaiki sistem. Model incremental merupakan model
continous rapid prototype dengan durasi yang diperpanjang hingga akhir proses
pengembangan. Pada model prototipe biasa, prototipe hanya dibuat pada tahap
awal untuk mendapatkan kebutuhan user.
- METODE SPIRAL
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.
Dalam
pengembangan sistem informasi berbasis web, model ini digunakan untuk
menyelesaikan sistem secara global terlebih dahulu, kemudian untuk feature dari
sistem akan dikembangkan kemudian. Dengan ini mempercepat dalam
pengimplementasian project. dan hal ini cocok digunakan dalam sistem informasi
Web.
Kekurangan model spiral
adalah sulitnya untuk meyakinkan konsumen (khusunya dalam situasi kontrak)
bahwa pendekatan evolusioner bisa dikontrol. Model spiral memerlukan keahlian
penaksiran risiko yang msuk akal , dan sangat bertumpu pada keakhlian ini untuk
mencapai keberhasilan. Jika resiko mayor tidak ditemukan dan diatur, pasti akan
terjadi masalah. Akhirnya model itu sendiri masih baru dan belum dipergunakan
secara luas seperti paradigma sekuensial dan prototipe.
https://www.scribd.com/doc/52693474/metode-pengembangan-sistem
https://www.scribd.com/doc/58298607/Pengertian-Prototype