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.