1. Model Sekuensial Linier
Sekuensial linier, yang sering disebut juga classic
life cycle atau waterfall model, menyampaikan suatu pendekatan yang berurutan
untuk pengembangan perangkat lunak.
Pengembangan dimulai dari perencanaan sistem (rekayasa sistem), analisa
kebutuhan, desain, penulisan program, pengujian dan
perawatan sistem. Sekuensial modeladalah
paradigma tertua dalam rekayasa perangkat lunak. Namun, pada dua dekade terakhir dengan banyaknya kritik terhadap
model proses initelah memunculkan keraguan dari para pengguna model ini
mengenai kehandalan model proses ini
Ø
Menggambarkan sekuensial linier untuk
rekayasa perangkat lunak yang sering
disebut juga dengan “siklus kehidupan klasik”atau”model air terjun”

Gambar Fase Lingkaran pemecahan masalah[RAC95]

Sekuensial
linier mengusulkan sebuah pendekatan kepada perkembangan perangkat lunak yang
sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh
analis,desain,kode,pengujian,model sekuensial linier.
2. Model Prototipe
Ø Prototyping
paradigma dimulai dengan pengumpulan kebutuhan.
Ø Secara
ideal prototipe berfungsi sebagai sebuah mekanisme untuk mengidentifikasi
kebutuhan perangkat lunak.
Ø Bila
prototipe sedang bekerja atau dibangun,pengembang harus mempergunakan
fragmen-fragmen yang ada atau
mengaplikasikan alat-alat bantu
Ø Contohnya:report
generator,window manager,dll yang memungkinkan program yang bekerja untuk
dimunculkan cecara cepat.
Ø Prototipe bisa berfungsi sebagai “sistem
pertama”
Ø Prototipe bisa juga menjadi masalah karena alasan-alasan sebagai berikut:
1. Pelanggan
melihat apa yang tampak sebagai versi perangkat lunak yang bekerja tanpa
melihat bahwa prototipe itu dijalankan bersama-sama tanpa melihat bahwa didalam
permintaan untuk membjuatnya bekerja.
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 da dikenal .
Ø Prototyping dipakai bila ditemui kondisi
• Definisi
user bersifat umum
• user
tidak tahu pasti apa yang diinginkan
• definisi
user bersifat tidak rinci
• user
tidak tahu pasti apa & bagaimana bentuk
– masukan
– proses
– keluaran
• pengembang
merasa tidak tahu pasti tentang
– pilihan algoritma yang akan dipakai
– bagaimana
lingkungan sistem yang akan dikembangkan
– bentuk, sifat & karakteristik antar-muka pemakai
• Terdapat
ketidak pastian dipihak user yaitu tentang apa diinginkan
• Terdapat
ketidak pastian dipihak pengembang yaitu
tentangapa yang harus dilakukan

Contoh Gambar
Model Proses Prototyping
3. Model Rad
Rapid Aplication
Development (RAD) adalah sebuah model proses perkembangan perangkat lunak
sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model
RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial
linier dimana perkembangan cepat dicapai dengan menggunakan pendekatan
konstruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD
memungkinkan tim pengembangan menciptakan “system fungsional yang utuh” dalam
periode waktu yang sangat pendek (kira-kira dalam waktu 60 – 90 hari).
Pendekatan RAD melingkupi fase – fase sebagai berikut :
Ø
Bussines modeling.
Aliran informasi
diantara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk menjawab
pertanyaan berikut : Informasi apa yang mengendalikan proses bisnis? Informasi
apa yang dimunculkan? Siapa yang memunculkan? Kemana informasi itu pergi? Siapa
yang memprosesnya?
Ø
Data modeling.
Aliran informasi
yang didefinisikan sebagai bagian dari fase Bussines modeling disaring kedalam
serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut.
Karakteristik (disebut atribut) masing – masing objek diidentifikasi dan
hubungan antara objek – objek tersebut didefinisakan .
Ø
Process modeling.
Aliran informasi
yang didefinisikan didalam fase data modeling ditrnsformasikan untuk mencapai
aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran
pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan
kembali sebuah objek data.
Ø
Aplication generation.
RAD mengasumsikan
pemakaian teknik generasi ke-empat (dalam pembahasan selanjutnya). Selain
menghasilkan perangkat lunak dengan menggunakan bahasa pemrograman generasi
ke-tiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi
komponen program yang ada (pada saat memunkinkan) atau menciptakan komponen
yang biasa dipakai lagi (bila perlu). Pada semua kasus, alat – alat Bantu otomatis
dipakai untuk memfasilitasi konstruksi perangkat lunak.
Ø
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 diuji dan
semua interface harus dilatih secara penuh.
Berikut kekurangan yang dimiliki RAD:
Ø Bagi proyek yang besar tapi berskala, RAD memerlukan SDM yang memadai,
untuk menciptakan jumlah tim RAD yang baik.
Ø RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam
aktifitas rapid-fire yang diperlukan
untuk melengkapi sebuah system, didalam kerangka waktu yang sangat diperpendek.
Jika komitmen tersebut tidak ada dari tiap konstituen, proyek RAD akan gagal.
Ø Tidak semua aplikasi sesuai untuk RAD. Bila system tidak dapat
dimodulasikan dengan teratur, pembangunan penting pada RAD akan sangat
terganggu.

Gambar
Model RAD
Dari gambar diatas,
secara jelas batasan waktu yang dibebankan pada sebuah proyek RAD memerlukan
“ruang lingkup yang bias diskala”. Jika sebuah aplikasi bisnis dapat dimodulkan
dengan cara tertentu sehingga memungkinkan setiap fungsi mayor untuk dilengkapi
dalam waktu kurang dari 3 bulan (dengan menggunakan pendekatan yang digambarkan
diatas),maka aplikasi itu merupakan kandidat bagi RAD. Masing – masing fungsi
mayor bias dibicarakan oleh suatu tim RAD yang terpisah, dan kemudian
diintegrasikan untuk membentuk suatu keadaan.
4.
Model Inkremental (Pertambahan)
Model Inkremential menggabungkan elemen-elemen model sekuensial
linier (diaplikasikan secara berulang) dengan filosofi iteratif. Seperti
diperlihatkan dibawah, model pertambahan memakai urutan linier yang
membingungkan, seiring dengan laju waktu kalender. Setiap urutan linier
menghasilkan pertambahan, perangkat lunak “yang biasa disampaikan”. Pada saat
model pertambahan dipergunakan, pertambahan pertama sering merupakan produk
inti (care product), yaitu sebuah model pertambahan yang biasa dipergunakan,
tetapi beberapa muka tambahan (beberapa diketahui dan beberapa tidak) tetap
tidak disampaikan. Rencana pertambahan selanjutnya menekan modifikasi produk
inti untuk secara lebih baik memenuhi kebutuhan para pelanggan dan penyampaian
fitur serta fungsionalitas tambahan. Proses ini diulangi mengikuti penyampaian
setiap pertambahan sampai menghasilkan produk yang lengkap.
Perkembangan pertambahan,khususnya berguna pada saat
staffing tidak dapat dilakukan dengan menggunakan implementasi lengkap oleh
batas waktu bisnis yang sudah disepakati oleh batas waktu tersebut. Jika produk
ini diterima maka staff tambahan dapat ditambahkan untuk mengimplementasikan
pertambahan selanjutnya. Sebagai tambahan, system mayor yang sedang dalam masa
perkembangan serta waktu penyampaian belum pasti, mungkin membutuhkan
keberadaan perangkat keras yang baru. Dapat juga membuat rencana tertentu untuk
menghindari pemakaian perangkat lunak ini, sehingga memungkinkan fungsionalitas
partai disampaikan kepada pemakai tanpa harus banyak tertunda.
Model Inkramental



5.
Model
Spiral
Model spiral yang pada awalnya
diusulkan oleh Boehm, adalah model proses perangkat lunak yang evolusioner yang
merngkai sifat iterative dari prototype dengan cara control dan aspek
sistematisdari model sekuensial linier. Dalam model spiral, perangkat lunak
dikembangkan dalam suatu penambahan.
Model spiral
dibagi menjadi sejumlah aktifitas kerangka
kerja, disebut juga wilayah luas, diantara tiga sampai enam wilayah luas :
Ø Komunikasi pelanggan : tugas – tugas yang dibutuhkan untuk membangun
komunikas yang efektif diantara pengembangan dan pelanggan.
Ø Perencanaan : tugas – tugas yang dibutuhkan untuk mendefinisikan sumber
daya, ketepatan waktu, dll.
Ø Analisis resiko : tugas yang dibutuhkan untuk menaksir resiko2, baik
manajemen maupun teknis.
Ø Perekayasaan : tugas yang dibutuhkan untuk membangun satu atau lebih
representasi dari aplikasi tersebut.
Ø Konstruksi dan peluncuran : tugas yang dibutuhkan untuk mengkonstruksi,
menguji, memasang (install), dan memberi pelayanan kepada pemakai.
Ø Evaluasi pelanggan : tugas yang dibutuhkan untuk memperoleh umpan balik
dari pelanggan.
Model spiral
menjadi sebuah pendekatan yang realistis bagiperkembangan system dan perangkat
lunak skala besar.karena perangkat lunak terus bekerja selama proses bergerak,
pengembangan dan pemakai memahami dam bereaksi lebih baik terhadap resiko
terhadap setiap evolusi. Tetapi model spiral bukanlah sebuah obat yang mujarab
,karena mode spiral membutuhkan keahlian penaksiran resiko yang masuk akal dan
sangat bertumpu untuk mencapai keberhasilan.
Contoh Gambar Spiral
6. Model Rakitan Komponen
Model rakitan
komponen menggabungkan karakteristik model spiral. Model ini bersifat
evolusioner sehingga membutuhkan pendekatan iterative untuk menciptakan
perangkat lunak. Tetapi model rakitan komponen merangkai aplikasi dari komponen
perangkat lunak sebelum dipaketkan (biasa disebut “kelas”). Kelas2 yang
diciptakan dalam proyek perangkat lunak disimpan didalam pustaka kelas atau
tempat penyimpanan.
Model rakitan
komponen membawa kepada pengguna kembali perangkat lunak, dan kegunaan kembali
tersebut memberi sejumlah keuntungan yang bias diukur pada rekayasa perangkat
lunak.
7. Model Perkembangan
Konkuren
Model
perkembangan konkuren juga disebut rekayasa konkuren. Model proses yang
konkuren dapat disajikan secara skematis sebagai sederetan aktivitas teknik
mayor, tugas – tugas, dan keadaan yang lain. Contohnya aktivitas rekayasa yang
dibatasi untuk model spiral dipenuhi dwengan melakukanprototyping, dan atau pemodelan
analisis, spesifikasikebutuhan,dan rancangan

Elemen model
proses konkuren
8. Model Formal
Metode formal
mencakup sekumpulan aktivitas yang membawa kepada spesifikasi matematis
perangkat lunak computer. Metode ini mmemungkinkan perekayasa untuk
mengkhususkan, mengembangkan, dan memverifikasi system berbasis computer dengan
menggunakan system matematis yang tepat. Variasi dalam
pendekatan ini disebut juga clean-room
rekayasa perangkat lunak..
Meskipun belum menjadi pendekatan
utama, metode ini sudah dapat menjanjikan perangkat lunak yang bebas dari cacat
/ kesalahan, tetapi perhatian tentang kemampuan aplikasinya sudah mulai
disuarakan :
1.
Pengembangan model format banyak memakan
waktu dan mahal.
2.
Perlu
latihan yang ekstensif.
3.
Sulit untuk menggunakan model2 sebagai
sebuah mekanisme komunikasi bagi pemakai yang secara teknik belum canggih.
Meskipun demikian , sepertinya
metode ini akan banyak penganutnya diantara pengembangan perangkat lunak yang
harus membangun perangkat lunak yang kritis untuk keselamatan (misal perangkat
medis, dan penerbangan pesawat), serta diantara pengembangan yang harus
menderita karena factor ekonomis yang harus dialami oleh perangkat lunak.
9. Teknik Generasi Keempat
Bentuk ini mencakup serangkaian
Bantu perangkat lunak yang luas yang secara umum memiliki satu hal; masing –
masing memungkinkan perekayasa perangkat lunak untuk mengkhususkan beberapa
karakteristik perangkat lunak pada suatu tingkat yang tinggi. Alat – alat Bantu
tersebut yang kemudian secara otomatis memunculkan kode sumber yang berdasarkan
pada spesifikasi perekayasa.
Seperti semua paradigma rekayasa
perangkat lunak yang lain, model ini juga memiliki keuntungan dan kerugian.
Orang sepaham mempermasalahkan penghematan waktu, serta produktivitas yang
dikembangkan secara baik oleh perekayasa perangkat lunak. Kelompok yang
berlawanan mempermasalahkan alat Bantu yang tidak lebih mudah digunakan dari
bahasa pemrograman, serta kemampuan pemeliharaan perangkat lunak yang
dikembangkan masih mengandung pertanyaan.
Ada beberapa sisi baik dari kedua
sisi permasalahan diatas :
1.
kegunaan metode ini telah disebarkan selama
dekade terakhir dan sekarang merupakan pendekatan yang masih berjalan terus
bagi area aplikasi yang berbeda.
2.
data yang dikumpulkan perusahaan – yang
menggunakan metode ini menunjukkan bahwa waktu yang dibutuhkan untuk
menghasilkan perangkat lunak sangat berkurang untuk aplikasi kecil dan
menengah, serta jumlah desain analisis bagi aplikasi kecil juga berkurang.
3.
tetapi kegunaannya untuk pengembangan
perangkat lunak yang besar membutuhkan analisis, desain dan pengujian yang
sangat banyak(aktivitas RPL) untuk memperoleh penghematam waktu.
Kesimpulannya, teknik ini telah
menjadi bagian yang penting dari perkembangan perangkat lunak. Bila dirangkai
dengan pendekatan rakitan komponen, paradigma metode ini dapat menjadi
pendekatan yang dominant untuk pengembangan perangkat lunak.
Tidak ada komentar:
Posting Komentar