model-model pengembangan perangkat lunak
Post on 01-Jul-2015
247 Views
Preview:
DESCRIPTION
TRANSCRIPT
REKAYASA PERANGKAT LUNAK I
2011
Model-model
Pengembangan
Perangkat Lunak
Ferry Ferdiansyah
090010129
F091
F E R R Y F E R D I A N S Y A H _ 0 9 0 0 1 0 1 2 9
STMIK STIKOM BALI
2011
F e r r y F e r d i a n s y a h _ 0 9 0 0 1 0 1 2 9
2
Model-model Pengembangan Perangkat Lunak 2011
Model Prototype
Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software
tanpa detil input, proses atau detil output. Di lain waktu mungkin dimana tim pembangun
(developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi
terhadap sistem operasi atau rancangan form user interface. Ketika situasi seperti ini
terjadi model prototype sangat membantu proses pembangunan software.
Proses pada model prototyping yang digambarkan pada gambar diatas, bisa
dijelaskan sebagai berikut:
Pengumpulan kebutuhan : developer dan klien bertemu dan menentukan tujuan
umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan
dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada
awal pengumpulan kebutuhan.
Perancangan : perancangan dilakukan cepat dan rancangan mewakili semua aspek
software yang diketahui dan rancangan ini menjadi dasar pembuatan prototype.
Evaluasi prototype: klien mengevaluasi prototype yang dibuat dan digunakan
untuk memperjelas kebutuhan software.
Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi.
F e r r y F e r d i a n s y a h _ 0 9 0 0 1 0 1 2 9
3
Model-model Pengembangan Perangkat Lunak 2011
Prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk
memahami kebutuhan klien lebih baik. Prototype yang dibuat dapat dimanfaatkan kembali
untuk membangun software lebih cepat, namun tidak semua prototype bisa dimanfaatkan.
Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien
mendapat gambaran awal dari prototype , membantu mendapatkan kebutuhan detil lebih
baik namun demikian prototype juga menimbulkan masalah:
1. Dalam membuat prototype banyak hal yang diabaikan seperti efisiensi, kualitas,
kemudahan dipelihara/dikembangkan dan kecocokan dengan lingkungan yang
sebenarnya. Jika klien merasa cocok dengan prototype yang disajikan dan berkeras
terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan
produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya.
2. Developer biasanya melakukan kompromi dalam beberapa hal karena harus
membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak
sesuai, bahasa pemrograman yang berbeda atau algoritma yang lebih sederhana.
Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan
developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan
kebutuhan software.
F e r r y F e r d i a n s y a h _ 0 9 0 0 1 0 1 2 9
4
Model-model Pengembangan Perangkat Lunak 2011
Model RAD (Rapid Application Development)
Rapid Application 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
F e r r y F e r d i a n s y a h _ 0 9 0 0 1 0 1 2 9
5
Model-model Pengembangan Perangkat Lunak 2011
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 memunculkannya?
- Kemana 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. Process modeling
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. Application 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 memakai 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.
F e r r y F e r d i a n s y a h _ 0 9 0 0 1 0 1 2 9
6
Model-model Pengembangan Perangkat Lunak 2011
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.
Kekurangan model RAD adalah :
1. Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia
yang memadai untuk menciptakan jumlah tim RAD yang baik.
2. RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktivitas
rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka
waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD
akan gagal.
F e r r y F e r d i a n s y a h _ 0 9 0 0 1 0 1 2 9
7
Model-model Pengembangan Perangkat Lunak 2011
Model Incremental (Original : Mills)
Keterangan:
1) Kombinasikan elemen-elemen dari waterfall dengan sifat iterasi/perulangan.
2) Elemen-elemen dalam waterfall dikerjakan dengan hasil berupa produk dengan
spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan
menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya.
Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang
ditetapkan oleh pengguna.
3) Produk hasil increment pertama biasanya produk inti (core product), yaitu produk
yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau
menjalani review/pengecekan detil. Hasil review tersebut menjadi bekal untuk
pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk
yang komplit dihasilkan.
4) Model ini cocok jika jumlah anggota tim pengembang/pembangun perangkat lunak
tidak cukup.
5) Mampu mengakomodasi perubahan secara fleksibel.
F e r r y F e r d i a n s y a h _ 0 9 0 0 1 0 1 2 9
8
Model-model Pengembangan Perangkat Lunak 2011
6) Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk
yang sudah bisa berfungsi dengan spesifikasi dasar.
Model Incremental dalam rekayasa perangkat lunak, menerapkan rekayasa
perangkat lunak perbagian, hingga menghasilkan perangkat lunak yang lengkap. Proses
membangun berhenti jika produk telah mencapai seluruh fungsi yang diharapkan.
Pada awal tahapan dilakukan penentuan kebutuhan dan spesifikasi. Kemudian dilakukan
perancangan arsitektur software yang terbuka, agar dapat diterapkan pembangunan per-
bagian pada tahapan selanjutnya.
Tahapan Incremental Model adalah :
Requirement
Specification
Architecture Design
Tahapan-tahapan tersebut dilakukan secara berurutan. Setiap bagian yang sudah
selesai dilakukan testing, dikirim ke pemakai untuk langsung dapat digunakan.
Pada incremental model, tiga tahapan awal harus diselesaikan terlebih dahulu sebelum
sebelum tahap membangun tiap modal.
Untuk mengantisipasi kondisi yang terjadi pada model incremental, diperkenalkan
model More Risky Incremental Model. Model ini menerapkan sistem kerja yang paralel.
Setelah daftar kebutuhan didapatkan dari pemakai, tim spesifikasi membuat spesifikasi
untuk modul pertama. Setelah spesifikasi pertama selesai, tim desain menindak lanjuti.
TIm spesifikasi sebelumnya juga langsung membuat spesifikasi untuk model kedua, dan
seterusnya.
Masalah dengan Incremental model:
1) Cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding).
2) Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana
spesifikasi masing-masing hasil increment.
F e r r y F e r d i a n s y a h _ 0 9 0 0 1 0 1 2 9
9
Model-model Pengembangan Perangkat Lunak 2011
Model Spiral (Original : Boehm)
Proses digambarkan sebagai spiral. Setiap loop mewakili satu fase dari software
process. Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang
definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya.
Setiap Loop dibagi menjadi beberapa sektor :
1. Objective settings (menentukan tujuan) : menentukan tujuan dari fase yang
ditentukan. Batasan-batasan pada proses dan produk sudah diketahui. Perencanaan
sudah disiapkan. Resiko dari proyek sudah diketahui. Alternatif strategi sudah
disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan.
2. Risk assessment and reduction (Penanganan dan pengurangan resiko) : setiap
resiko dianalisis secara detil pada sektor ini. Langkah-langkah penanganan
dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan
kebutuhan.
F e r r y F e r d i a n s y a h _ 0 9 0 0 1 0 1 2 9
10
Model-model Pengembangan Perangkat Lunak 2011
3. Development and Validation (Pembangunan dan pengujian) : Setelah evaluasi
resiko, maka model pengembangan sistem dipilih. Misalnya jika resiko user
interface dominan, maka membuat prototype User Interface. Jika bagian keamanan
yang bermasalah, maka menggunakan model formal dengan perhitungan matematis
dan jika masalahnya adalah integrasi system, model waterfall lebih cocok.
4. Planning : Proyek dievaluasi atau ditinjau ulang dan diputuskan untuk terus ke fase
loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya rencana untuk loop
selanjutnya.
Pembagian sector bisa saja dikembangkan seperti pada pembagian sektor berikut
pada model variasi spiral di bawah ini:
o Customer communication : membangun komunikasi yang baik dengan pengguna
atau customer.
o Planning : mendefinisikan sumber, batas waktu, informasi-informasi lain seputar
proyek.
o Risk analysis : identifikasi resiko managemen dan teknis.
o Engineering : pembangunan contoh-contoh aplikasi, misalnya prototype.
o Construction and release : pembangunan, test, install dan support.
o Customer evaluation : mendapatkan feedback dari pengguna beradasarkan
evaluasi perangkat lunak pada fase engineering dan fase instalasi.
F e r r y F e r d i a n s y a h _ 0 9 0 0 1 0 1 2 9
11
Model-model Pengembangan Perangkat Lunak 2011
Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang
mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistik
untuk perangkat lunak berskala besar. Pengguna dan pembangun bisa memahami dengan
baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat
diamati dengan baik. Namun demikian, waktu yang cukup panjang mungkin bukan pilihan
bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar.
Model Incremental dan Spiral merupakan 2 model dalam Evolutionary Software
Process Model yang bersifat iteratif/ mengandung perulangan. Hasil proses berupa produk
yang makin lama makin lengkap sampai versi terlengkap dihasilkan sebagai produk akhir
dari proses.
top related