1. Linear
Sequential Model
Model proses ini
sering disebut sebagai Waterfall
atau Classic Life Cycle Model.
Metode Linear Sequential Model menyarankan pendekatan yang sistematis
dan sekuensial dalam pengembangan perangkat lunak yang dimulai pada level
sistem dan bergerak maju mulai tahap analisis, desain, coding, testing,
dan support.
The Linear Sequential Model
Model Linear Sequential mencakup
aktivitas-aktivitas berikut:
1.
Rekayasa dan pemodelan sistem/informasi (System/information
engineering). Dikarenakan perangkat lunak selalu merupakan bagian dari sistem
atau bisnis yang lebih besar, kegiatan proses perangkat lunak dimulai dengan melakukan
indentifikasi kebutuhan (requirements) dari seluruh elemen sistem lalu
memetakan bagian dari kebutuhan tersebuat sebagai kebutuhan perangkat lunak.
Pandangan
secara sistem ini sangat dibutuhkan ketika perangkat lunak harus berinterakasi
dengan elemen-elemen yang lain seperti perangkat keras, manusia, dan basisdata.
Identifikasi dan pengumpulan kebutuhan dilakukan dalam level strategi bisnis
dan level manajerial.
Baca Selengkapnya!!!
2. Analisis
kebutuhan perangkat lunak (Software requirements analysis).
Proses identifikasi dan pengumpulan kebutuhan sistem difokeskan pada kebutuhan
perangkat lunak. Untuk memahami program-program yang akan dibangun, analis
harus memahami domain dan lingkup perangkat lunak yang akan dibangun, termasuk
didalamnya fungsi, tingkah laku perangkat
lunak, performansi, dan antarmuka. Kebutuhan sistem dan perangkat lunak
didokumentasikan dan dikonfirmasikan dengan customer.
3. Desain (Design). Proses
desain perangkat lunak fokus kepada sturktur data, arsitektur perangkat lunak,
representasi antarmuka, dan algoritma detil proses. Desain merupakan
representasi kebutuhan yang akan dijadikan pedoman dalam pengkodean program.
Desain didokumentasikan dan menjadi bagian dari manajemen konfigurasi perangkat
lunak.
4. Pengkodean
(Code
generation). Desain yang telah dibuat, ditranslasikan ke dalam suatu bahasa
pemrograman tertentu.
5. Pengujian (Testing).
Setelah kode program dibangun, program diuji untuk memastikan bahwa semua
kebutuhan dan persoalan dapat diselesaikan dan benar. Proses pengujian fokus
pada logika perangkat lunak. Memastikan bahwa dari proses input, pemrosesan,
hingga output benar dan sesuai dengan yang diinginkan.
6. Support.
Perangkat lunak sangat memungkinkan untuk berubah. Perubahan dapat terjadi
karena ditemukannya kesalahan, perangkat lunak harus diadaptasikan kepada
sistem yang baru, customer menginginkan peningkatan fungsional dan
performansi perangkat lunak, dan perawatan perangkat lunak.
Keunggulan
model ini adalah:
1.
Programmer jarang diinterupsi pekerjaanya dengan
perubahan kebutuhan, sehingga programmer dapat lebih konsentrasi.
2. Bila
proses yang dilakukan telah jelas dan pasti, model ini akan memberikan
efisiensi dan efektivitas yang tinggi.
3. Dituntut
bekerja secara disiplin
4. Dokumennya
lengkap
5. Maintenance
mudah karena memiliki dokumen yang lengkap
6. Selalu
dalam kontrol SQA (Software Quality Assurance)
Kekurangan model ini adalah:
Meskipun
model ini merupakan model yang paling banyak/sering digunakan, model ini
memiliki kekurangan:
1.
Umumnya customer kurang bisa menyampaikan
seluruh kebutuhan yang diinginkannya dalam tahan pendefinisian, sehingga dalam
proses pengembangan perangkat lunak sering customer menginginkan
perubahan atau tambahan kebutuhan. Model waterfall sulit mengakomodasi
perubahan ini.
2.
Kesalahan yang dibuat akan dibawa ke tahap
berikutnya. Pada tahap pengujian (testing) bila kesalahan tersebut
ditemukan, kesalahan tersebut telah terakumulasi dan berinteraksi dengan
proses-proses lain, sehingga biaya (waktu, uang, sumber daya lain) dan usaha
harus dikeluarkan dalam jumlah yang besar.
3. Keterlibatan
customer sangat minim. Customer harus sabar menunggu hingga semua
program selesai dibangun.
4. Konsumen
sulit membaca dokumen menyebabkan komunikasi juga menjadi sulit
5. Alur
pengerjaan yang linier menyebabkan proses menjadi lambat Personil tidak
bekerja optimal karena ada waktu tunggu atau jeda setiap tahapan.
II. Prototyping
Model
Sering
customer dalam memesan perangkat lunak tidak dapat mengidentifikasi
input, proses, dan permintaan output secara detil. Kasus lain, yaitu pengembang
tidak yakin terhadap efisiensi algoritma yang digunakan terhadap permasalahan
yang dihadapi customer, kemampuan adaptasi terhadap sistem operasi, atau
bentuk interaksi manusia -perangkat lunak yang akan diterapkan. Pada
kasus-kasus ini, paradigma prototyping memberikan pendekatan yang lebih
baik.
Prototyping Model
Model
Prototyping mencakup aktivitas-aktivitas berikut:
1.
Pengumpulan kebutuhan.
Aktivitas dimulai dengan pengumpulan kebutuhan (requirements).
Pengembang dan customer bertemu untuk menentukan tujuan keseluruhan dan
global perangkat lunak, mengidentifikasi kebutuhan yang telah diketahui, lalu
mendefinisikan area dan lingkup pengembangan.
2. Desain. Proses
desain dilakukan dengan sangat cepat. Desain difokuskan kepada aspek-aspek
desain yang nampak kepada customer/user (contoh: interface, pendekatan
input, format output). Hasil desain inilah yang disebut sebagai prototipe.
3. Evaluasi
Prototipe. Prototipe yang dihasilkan, direview oleh customer.
Hasil evaluasi ini dijadikan bahan untuk perubahan dan pengembangan
selanjutnya. Iterasi terus dilakukan hingga memenuhi keinginan customer,
sementara pada saat yang sama, memungkinkan pengembang untuk dapat lebih
memahami kebutuhan perangkat lunak.
Tujuan
utama model proses prototipe ini adalah untuk memudahkan pengembang memahami
kebutuhan customer. Brooks, F. dalam bukunya “The Mythical Man-Month”,
menyarankan kita untuk membuang prototipe ini bila semua kebutuhan customer
berhasil diungkap. Akan tetapi dapat juga kita melakukan modifikasi dan
memanfaatkan template prototipe sebelumnya.
Keunggulan
model ini adalah:
1.
Dapat segera memahami kebutuhan customer.
2. Dapat
segera menemukan kesalahan program atau kesalahan interpretasi kebutuhan
perangkat lunak.
3. Customer atau user
dapat segera memahami dan mempunyai gambaran terhadap sistem (PL) yang akan
dibangun.
Kelemahan model ini yaitu:
1. Biasanya customer setelah melihat prototipe
terakhir yang telah disepakati bersama, customer ingin segera
memilikinya. Tidak peduli efisiensi algoritma yang digunakan, dokumentasi, dan
aspek-aspek rekayasa perangkat lunak lain. Hal ini dapat menyebabkan kualitas
perangkat lunak menjadi rendah.
2. Programmer
akan sering diinterupsi oleh perubahan. Sedangkan sifat alamiah perubahan
adalah mengganggu.
III. Evolutionary
Model
Model sequensial linier
diatas dirancang untuk pengembangan PL yang memiliki garis lurus, yang berarti
bahwa sistem yang lengkap akan disampaikan setelah urutan linier tersebut
dilengkapi. Sedangkan model prototype dirancang untuk mendorong konsumen (atau
pengembang) agar memahami kebutuhan (menyampaikan sitem produksi).
Model evolusioner adalah
model iterative yang tidak termasuk kedalam model klasik, model ini
memungkinkan perekayasa PL untuk mengembangkan versi PL yang lebih lengkap
sedikit demi sedikit. Model evolusioner terbagi menjadi banyak model, tapi
hanya 3 model yang paling digunakan, yaitu:
Spiral
Model
Model Spiral, adalah model yang diusulkan oleh Boehm (1988), yaitu model
proses perangkat lunak yang evolusioner yang merangkai sifat iterative dari
model prototype dengan cara kontrol dan aspek sistematis dari model sequential
linier. Dengan kata lain model ini menggunakan fitur-fitur yang ada pada Model
Sequential dan Prototyping.
Model Spiral mencakup aktivitas-aktivitas berikut:
1.
Customer Communication, Komunikasi Pelanggan yaitu tugas-tugas yang
dibutuhkan untuk membangun komunikasi yang efektif diantara pengembang dan
pelanggan.
2.
Planning,
Perencanaan yaitu tugas-tugas yang dibutuhkan untuk
mendefinisikan sumber-sumber daya, ketepatan waktu, dan proyek informasi lain
yang berhubungan.
3.
Risk Analysis, Analisis Resiko yaitu tugas-tugas yang dibutuhkan
untuk menaksir resiko-resiko yang mungkin akn dihadapi, baik manajemen maupun
teknis.
4.
Engineering,
Perekayasaan yaitu tugas-tugas yang dibutuhkan untuk
membangun satu atau lebih representasi dari aplikasi tersebut.
5.
Construction and Release, Konstruki dan Peluncuran yaitu tugas-tugas yang
dibutuhkan untuk mengkonstruksi, menguji, memasang (instal) dan memberikan
pelayanan kepada pemakai, contohnya pelatihan dan dokumentasi.
6.
Customer Evaluation, Evaluasi Pelanggan yaitu tugas-tugas yang dibutuhkan
untuk memperoleh umpan balik dari pelanggan dengan didasarkan pada evaluasi
representasi perangkat lunak, yang dibuat selama masa perekayasaan, dan
diimplementasikan selama masa pemasangan.
Keunggulan model ini adalah:
1.
Model ini sangat baik digunakan untuk sistem dan
perangkat lunak yang besar.
2. Ditekankan
pada pencarian alternatif, dan pemaksaan penggunaan kembali software yang telah
ada.
3. Adanya
analisis resiko pada mekanisme untuk memperkecil resiko
4. Adanya
prototype memudahkan komunikasi dengan konsumen
Kelemahan model ini yaitu:
1.
Memerlukan waktu yang
cukup lama untuk mengembangkan perangkat lunak.
2.
Sistem Pengontrolan yang
kurang baik
3.
Tidak banyak cerita
sukses mengenai perancangan menggunakan model ini.
4. 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 diluar perusahaan maka akan timbul masalah
hukum
5. Incremental
Model
Incremental Model, adalah model rekayasa perangkat lunak yang dikerjakan
bagian per bagian hingga menghasikan perangkat lunak yang lengkap. Proses
pembangunan berhenti bila produk telah mencakup seluruh fungsi yang diharapkan.
Pada
tahapan system engineering aktivitas utama yang dilakukan adalah Requirement,
Specification dan Architecture Design. Setelah aktivitas utama terpenuhi,
tahapan selanjutnya adalah membangun tiap bagian secara berurutan. Setiap
bagian yang sudah selesai dilakukan testing, dikirim ke pemakai untuk langsung
dapat digunakan.
Keunggulan model ini adalah:
1.
Personil dapat bekerja secara optimal
2. Konsumen
dapat langsung menggunakan dahulu bagian-bagian yang telah selesai dibangun.
Misalnya input data karyawan.
3. Megurangi
trauma karena perubahan sistem. Klien dibiasakan perlahan-lahan menggunakan
produknya bagian per-bagian
4. Memaksimalkan
pengembalian model investasi konsumen.
Kelemahan
model ini yaitu:
1.
Kemungkian tiap bagian
tidak dapat diintegrasikan dengan baik
2.
Selalu berubah selama
proses rekayasa berlangsung
3.
Harus open architecture.
4th
Generation Technicques
Paradigma 4th GT untuk rekayasa perangkat
lunak berfokus pada kemampuan spesifikasi perangkat lunak dengan menggunakan
bentuk bahasa yang dikhususkan atau sebuah notasi grafik yang menggambarkan
masalah yang akan dipecahkan kedalam bentuk yang dapat dipahami oleh pelanggan.
Model 4th GT mencakup
aktivitas-aktivitas berikut:
1.
Requirement Gathering, usaha untuk
mengetahui/mendapatkan kebutuhan atas perangkat lunak yang akan dibangun
2. Design
Strategy, menentukan strategy perancangan, ini adalah bagian terpenting.
3. Implementasi,
menggunakan 4th GL (fourth
generation language), karena semua prosedur pemrograman sudah tersedia
(tinggal click), dikarenakan sudah tersedia maka implementas menjadi mudah
4. Testing,
maintenance.
Keunggulan model ini adalah:
1.
User lebih gampang mendesain program
2. Semua
orang awam bisa.
3. Megurangi
waktu yang dibutuhkan untuk menghasilkan PL aplikasi kecil dan menengah
4. Mempercepat
waktu desain.
Kelemahan model ini yaitu:
Untuk aplikasi yang
besar dibutuhkan analisis, desain dan pengujian yang sangat banyak, atau dengan
kata lain aktivitas rekayasa perangkat lunak sangat besar.
v Metode
Analisis dan Perancangan PL
Terlepas
dari paradigma pengembangan perangkat lunak yang dijelaskan di atas, ada dua
pendekatan yang bisa dilakukan dalam Analisa dan Perancangan Perangkat Lunak,
yaitu:
1.
Pendekatan Berorientasi Data (Data Oriented
Approach) / Terstruktur
a. Data Flow
Oriented
b. Data
Structured Oriented
2. Pendekatan
Berorientasi Objek (Object Oriented Approach) / Obyek
a.
Shlaer/Mellor Method
[Shlaer-1988]
b.
Coad/Yourdan Method
[Coad-1991]
c.
Booch Method
[Booch-1991] / OOAD
d.
OMT Method [Rumbaugh-1991]
e.
Wirfs-Brock Method
[Wirfs-Brock-1990]
f.
OOSE Objectory Method
[Jacobson-1992]
g.
UML (Unified Modeling
Language) [UML-1997]
0 comments:
Posting Komentar