resume rpl

16
RESUME REKAYASA PERANGKAT LUNAK Erlina Pujiasri A 207533408610 2/26/2010 Malang State University Erlina Pujiasri A.

Upload: erllynch

Post on 18-Jun-2015

672 views

Category:

Documents


22 download

TRANSCRIPT

Page 1: Resume Rpl

RESUME REKAYASA PERANGKAT LUNAK Erlina Pujiasri A

207533408610

2/26/2010 Malang State University

Erlina Pujiasri A.

Page 2: Resume Rpl

1

Daftar Isi 1. Perangkat Lunak ...................................................................................................... 1

1.1 Karakteristik Perangkat Lunak ...................................................................... 1

1.2 Komponen Perangkat lunak ............................................................................ 2

1.3 Aplikasi Perangkat Lunak ............................................................................... 2

2. Rekayasa Perangkat Lunak ..................................................................................... 4

2.1 Tujuan Rekayasa Perangkat Lunak ............................................................... 5

2.2 Ruang Lingkup .................................................................................................. 5

3. Mitos Rekayasa Perangkat Lunak .......................................................................... 6

4. Proses Perangkat Lunak .......................................................................................... 8

5. Model Proses Perangkat Lunak ............................................................................... 9

5.1 Model Konvensional ......................................................................................... 9

Linear SequentialModel/ Waterfall Model ............................................................. 9

Model Prototyping .................................................................................................. 10

RAD (Rapid Application Development) ............................................................... 11

5.2 Model Evolusioner .......................................................................................... 12

1. Incremental Model (Original: Mills) ............................................................. 12

2. Spiral Model (Original: Boehm) .................................................................... 13

Page 3: Resume Rpl

1

1. Perangkat Lunak

Perangkat lunak, adalah program komputer yang berfungsi sebagai sarana

interaksi antara pengguna dan perangkat keras. Perangkat lunak dapat juga

dikatakan sebagai 'penterjemah' perintah-perintah yang dijalankan pengguna

komputer untuk diteruskan ke atau diproses oleh perangkat keras. Perangkat lunak

ini dibagi menjadi 3 tingkatan: tingkatan program aplikasi (application program

misalnya OpenOffice.org), tingkatan sistem operasi (operating system misalnya

Ubuntu), dan tingkatan bahasa pemrograman (yang dibagi lagi atas bahasa

pemrograman tingkat tinggi seperti Pascal dan bahasa pemrograman tingkat

rendah yaitu bahasa rakitan).

Perangkat lunak merupakan program komputer yang isi instruksinya dapat

diubah dengan mudah. Perangkat lunak umumnya digunakan untuk mengontrol

perangkat keras (yang sering disebut sebagai device driver), melakukan proses

perhitungan, berinteraksi dengan perangkat lunak yang lebih mendasar lainnya

(seperti sistem operasi, dan bahasa pemrograman), dan lain-lain.

Gambaran tentang perangkat lunak di dalam sebuah buku teks mungkin

mengambil bentuk berikut :

1. Perangkat lunak merupakan perintah (program komputer) yang bila dieksekusi

memberikan fungsi dan unjuk kerja seperti yang diinginkan.

2. Perangkat lunak adalah struktur data yang memungkinkan program

memanipulasi informasi secara proporsional, dan

3. Perangkat lunak merupakan dokumen yang menggambarkan operasi dan

kegunaan program.

1.1 Karakteristik Perangkat Lunak

Perangkat lunak lebih merupakan elemen logika dan bukan merupakan

elemen sistem fisik. Dengan demikian, perangkat lunak memiliki ciri yang

berbeda dari perangkat keras :

1. Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuk yang

klasik (pabrikasi). Biaya untuk perangkat lunak dikonsentrasikan kepada

pengembangan. Hal ini berarti proyek perangkat lunak tidak dapat diatur

seperti pengaturan proyek-proyek pemanufakturan.

2. Perangkat lunak tidak pernah usang. Perangkat lunak tidak rentan terhadap

pengaruh lingkungan yang merusak yang menyebabkan perangkat keras

menjadi usang. Selama hidupnya, perangkat lunak mengalami perubahan

(pemeliharaan). Aspek lain dari keusangan menggambarkan perbedaan antara

perangkat keras dan perangkat lunak. Bila komponen suatu perangkat keras

telah usang, komponen dapat diganti dengan suku cadangnya. Namun tidak

ada suku cadang bagi perangkat lunak. Setiap kegagalan perangkat lunak

menggambarkan kesalahan dalam perancangan atau proses di mana rancangan

diterjemahkan ke dalam kode mesin yang dapat dieksekusi.

Page 4: Resume Rpl

2

3. Sebagian besar perangkat lunak dibuat secara custom-built, serta tidak dapat

dirakit dari komponen yang sudah ada. Perhatikan bagaimana perangkat keras

untuk produksi berbasis mikroprosesor dirancang dan dibuat. Setelah masing-

masing komponen diseleksi, perangkat keras dapat dipesan secara terpisah.

Sementara pada perangkat lunak, tidak katalog komponen perangkat lunak.

Memang memungkinkan untuk memesan perangkat lunak secara terpisah,

tetapi tetap merupakan satu kesatuan yang lengkap, bukan sebagai komponen

yang dapat dipasangkan ke dalam program-program yang baru.

1.2 Komponen Perangkat lunak

Reusability merupakan suatu ciri penting dari komponen perangkat lunak

kualitas tinggi. Sebuah komponen perangkat lunak harus didesain dan

diimplementasikan sehingga dapat dipakai lagi pada berbagai program yang

berbeda.

Komponen perangkat lunak dibangun dengan bahasa pemrograman yang

memiliki kosakata yang terbatas, sebuah tata bahasa yang dibatasi secara eksplisit, serta

aturan-aturan syntax dan semantik yang dibentuk secara baik.

Bahasa tingkat mesin merupakan perwakilan simbolik dari serangkaian instruksi

CPU. Bila program tidak dirancang dengan baik dan hanya memiliki sedikit dokumentasi,

maka bahasa tingkat mesin akan menjadi sebuah mimpi buruk.

Bahasa tingkat menengah memungkinkan pengambang perangkat lunak

serta program tidak tergantung pada mesin. Pada kenyataannya, bahasa tingkat

menengah meng-compile dan menginterpretasikan hasil bahasa tingkat mesin

sebagai keluaran.

Kode mesin, bahasa assembly (tingkat mesin), bahasa pemrograman

tingkat menengah, sering disebut tiga generasi bahasa komputer yang pertama.

Dengan bahasa-bahasa tersebut, pemrogram harus melihat dengan baik

kekhususan struktur informasi maupun kontrol pemrograman itu sendiri.

Demikianlah bahasa di dalam tiga generasi yang pertama dimasukkan ke dalam

jenis bahasa prosedural.

Bahasa generasi keempat, juga disebut bahasa nonprosedural menggerakkan

pengembang perangkat lunak untuk mengkhususkan pada detail prosedural.

1.3 Aplikasi Perangkat Lunak

Perangkat lunak dapat diaplikasikan ke berbagai situasi di mana

serangkaian langkah prosedural (seperti algoritma) telah didefinisikan.

Kandungan informasi dan determinasi merupakan faktor penting dalam

menentukan sifat aplikasi perangkat lunak. Content mengarah kepada arti dan

bentuk dari informasi yang masuk dan keluar.

Memang sulit untuk menentukan kategori umum untuk aplikasi perangkat lunak.

Ketika kompleksitas perangkat lunak mulai muncul, maka penggolongan yang rapi

menjadi hilang. Area perangkat lunak berikut menunjukkan luasnya aplikasi potensial :

Page 5: Resume Rpl

3

Perangkat Lunak Sistem. Perangkat lunak sistem merupakan sekumpulan

program yang ditulis untuk melayani program-program yang lain. Banyak

perangkat lunak sistem (misal kompiler, editor, dan utilitas pengatur file)

memproses struktur-struktur informasi yang lengkap namun tetap. Perangkat

lunak sistem ditandai dengan eratnya interaksi dengan perangkat keras komputer.

Perangkat Lunak Real-Time. Program-program yang memonitor/menganalisis

kejadian dunia nyata pada saat terjadinya disebut perangkat lunak real-time.

Elemen-elemen perangkat lunak real-time mencakup komponen pengumpul data

yang mengumpulkan dan memformat informasi dari lingkungan eksternal, sebuah

komponen analisis yang mentransformasi informasi pada saat dibutuhkan oleh

aplikasi, sebuah komponen kontrol/output yang memberi respon kepada

lingkungan eksternal, serta sebuah komponen monitor yang mengkoordinasi

semua komponen lain agar respon real-timenya (I milidetik sampai 1 menit) dapat

tetap terjaga. Perlu dicatat di sini bahwa real-time berbeda dengan interaksi atau

timesharing. Sistem real-time harus merespon di dalam suatu rentang waktu yang

tetap. Waktu respon sebuah sistem interaktif (timesharing) secara normal dapat

diperpanjang tanpa memberikan risiko kerusakan pada hasil.

Perangkat Lunak Bisnis. Sistem diskrit (contohnya payroll, account

receivable/payable, inventory) telah mengembangkan perangkat lunak sistem

informasi manajemen (MIS) yang mengakses satu atau lebih database besar yang

berisi informasi bisnis. Aplikasi perangkat lunak bisnis juga meliputi

penghitungan klien/server serta penghitungan interaktif (misal pemrosesan

transaksi point-of-sale).

Perangkat Lunak Teknik dan Ilmu Pengetahuan. Perangkat lunak teknik dan

ilmu pengetahuan ditandai algoritma number crunching. Perangkat lunak ini

memiliki jangkauan aplikasi mulai dari astronomi sampai vulkanologi, dari

analisis otomotif sampai dinamika orbit pesawat ruang angkasa, dan dari biologi

molekuler sampai pabrik yang sudah diotomatisasi. Computer-aided design,

simulasi sistem, dan aplikasi interaktif yang lain, sudah mulai memakai ciri-ciri

perangkat lunak sistem genap dan real-time.

Embedded Software. Embedded software ada dalam read-only memory dan

dipakai untuk mengontrol hasil serta sistem untuk keperluan konsumen dan pasar

industri. Embedded software dapat melakukan fungsi yang terbatas serta fungsi

esoterik (misal key pad control untuk microwave) atau memberikan kemampuan

kontrol dan fungsi yang penting (contohnya fungsi dijital dalam sebuah automobil

seperti kontrol bahan bakar, penampilan dash-board, sistem rem, dll).

Page 6: Resume Rpl

4

Perangkat Lunak Komputer Personal. Pengolah kata, spreadsheet, grafik

komputer, multimedia, hiburan, manajemen database, aplikasi keuangan, bisnis

dan personal, jaringan eksternal atau akses database hanya merupakan beberapa

saja dari ratusan aplikasi yang ada.

Perangkat Lunak Kecerdasan Buatan. Perangkat lunak kecerdasan buatan

(Artificial Inteligent /AI) menggunakan algoritma non-numeris untuk

memecahkan masalah kompleks yang tidak sesuai untuk perhitungan atau analisis

secara langsung. Perangkat lunak kecerdasan buatan adalah pengenalan pola

(image dan voice), pembuktian teorema, dan permainan game. Di tahun-tahun

terakhir, cabang perangkat lunak kecerdasan buatan yang baru, yang disebut

artificial neural network, telah berkembang. Jaringan syaraf mensimulasi struktur

proses-proses otak dan kemudian membawanya kepada perangkat lunak kelas

baru yang dapat mengenali pola-pola yang kompleks serta belajar dari

pengalaman-pengalaman masa lalu.

2. Rekayasa Perangkat Lunak

Istilah Rekayasa Perangkat Lunak (RPL) secara umum disepakati sebagai

terjemahan dari istilah Software Engineering. Istilah Software Engineering mulai

dipopulerkan tahun 1968 pada Software Engineering Conference yang

diselenggarakan oleh NATO. Sebagian orang mengartikan RPL hanya sebatas

pada bagaimana membuat program komputer. Padahal ada perbedaan yang

mendasar antara perangkat lunak (software) dan program komputer.

Perangkat lunak adalah seluruh perintah yang digunakan untuk

memproses informasi. Perangkat lunak dapat berupa program atau prosedur.

Program adalah kumpulan perintah yang dimengerti oleh komputer sedangkan

prosedur adalah perintah yang dibutuhkan oleh pengguna dalam memproses

informasi (O’Brien, 1999). Pengertian RPL sendiri adalah sebagai berikut:

Suatu disiplin ilmu yang membahas semua aspek produksi perangkat

lunak, mulai dari tahap awal yaitu analisa kebutuhan pengguna,

menentukan spesifikasi dari kebutuhan pengguna, disain,

pengkodean, pengujian sampai pemeliharaan sistem setelah

digunakan.

Jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan

program komputer. Pernyataan “semua aspek produksi” pada pengertian di atas,

mempunyai arti semua hal yang berhubungan dengan proses produksi seperti

manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas

sampai dengan pelatihan pengguna merupakan bagian dari RPL.

Page 7: Resume Rpl

5

2.1 Tujuan Rekayasa Perangkat Lunak

Secara umum tujuan RPL tidak berbeda dengan bidang rekayasa yang lain.

Mari kita perhatikan Gambar 1. berikut ini.

Dari Gambar 1 dapat diartikan bahwa bidang rekayasa akan selalu

berusaha menghasilkan output yang kinerjanya tinggi, biaya rendah dan waktu

penyelesaian yang tepat. Secara lebih khusus kita dapat menyatakan tujuan RPL

adalah :

a. Memperoleh biaya produksi perangkat lunak yang rendah.

b. Menghasilkan perangkat lunak yang kinerjanya tinggi, andal dan tepat waktu.

c. Menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis

platform.

d. Menghasilkan perangkat lunak yang biaya perawatannya rendah.

2.2 Ruang Lingkup

Sesuai definisi yang telah disampaikan sebelumnya, maka ruang lingkup

RPL dapat digambarkan sebagai berikut.

Software requirements berhubungan dengan spesifikasi kebutuhan dan

persyaratan perangkat lunak.

Software design mencakup proses penentuan arsitektur, komponen,

antarmuka, dan karakteristik lain dari perangkat lunak.

Software construction berhubungan dengan detil pengembangan perangkat

lunak, termasuk algoritma, pengkodean, pengujian, dan pencarian

kesalahan.

Software testing meliputi pengujian pada keseluruhan perilaku perangkat

lunak.

Software maintenance mencakup upaya-upaya perawatan ketika perangkat

lunak telah dioperasikan.

Page 8: Resume Rpl

6

Software configuration management berhubungan dengan usaha

perubahan konfigurasi perangkat lunak untuk memenuhi kebutuhan

tertentu.

Software engineering management berkaitan dengan pengelolaan dan

pengukuran RPL, termasuk perencanaan proyek perangkat lunak.

Software engineering tools and methods mencakup kajian teoritis tentang

alat bantu dan metode RPL.

Software engineering process berhubungan dengan definisi, implementasi,

pengukuran, pengelolaan, perubahan dan perbaikan proses RPL.

Software quality menitikberatkan pada kualitas dan daur hidup perangkat

lunak.

3. Mitos Rekayasa Perangkat Lunak

Sekarang ini kebanyakan kaum profesional yang memilki banyak

pengetahuan mengetahui berbagai mitos di bidang ilmu yang digelutinya – sikap

yang salah yang menyebabkan masalah yang serius bagi manajer serta masyarakat

teknisi. Tetapi sikap lama tersebut memang sangat sulit diubah, dan sisa-sisa

mitos perangkat lunak masih tetap dipercaya.

Mitos manajemen. Manajer yang bertanggung-jawab terhadap masalah

perangkat lunak, seperti juga manajer pada kebanyakan disimplin, sering

mengalami tekanan karena masalah pengaturan keuangan, menjaga jadwal agar

tidak kacau, dan peningkatan kualitas.

Mitos : Kita sudah memilki buku yang penuh dengan standar dan prosedur

untuk membuat perangkat lunak. Apakah buku itu tidak memberikan

semua yang ingin diketahui oleh staf saya?

Kenyataan : Buku standar mungkin ada, tetapi apakah buku-buku tersebut

dipakai? Apakah para praktisi perangkat lunak sadar akan keberadaan

buku-buku tersebut? Apakah dia benar-benar mencerminkan praktik

perkembangan perangkat lunak modern? Apakah sudah lengkap? Dalam

banyak hal, jawaban untuk semua pertanyaan di atas adalah “tidak”.

Mitos : Staf saya sebenarnya memiliki alat pengembangan perangkat

lunak terkini, karena itulah kita membeli komputer baru bagi mereka.

Kenyataan : Dibutuhkan lebih dari sekedar mainframe model terakhir,

workstation atau PC untuk mengembangkan perangkat lunak berkualitas

tinggi. Computer-aided software engineering (CASE) lebih penting

daripada perangkat keras untuk mencapai kualitas dan produktivitas yang

tinggi, tetapi mayoritas pengembang perangkat lunak tetap belum

menggunakannya.

Page 9: Resume Rpl

7

Mitos : Jika kita mentaati jadwal, kita dapat menambah lebih banyak lagi

pemrogram dan mengejar ketinggalan (kadang-kadang disebut

“Mongolian horde concept”).

Kenyataan : Perkembangan perangkat lunak bukan merupakan proses

mekanis seperti pemanufakturan. Semakin manusia bertambah, para

personil yang sudah bekerja lebih lama harus menggunakan waktu untuk

membimbing pendatang baru, sehingga akan mengurangi jumlah waktu

yang digunakan dalam fase pengembangan produksi.

Mitos Pelanggan. Pelanggan mempercayai mitos tentang perangkat lunak karena

manajer dan para pelaksana yang bertanggung-jawab atas masalah perangkat

lunak hanya bekerja sedikit saja untuk memperbaiki kesalahan informasi. Mitos

ini membawa ke arah pengharapan yang salah (oleh pelanggan) dan ketidak-

puasan pengembang.

Mitos: pernyataan umum tentang obyektivitas sudah cukup untuk memulai

menulis program. Kita dapat mengisi detailnya nanti.

Kenyataan: Definisi awal yang buruk merupakan sebab utama gagalnya

kerja perangkat lunak. Deskripsi yang detail dan formal tentang domain

informasi, fungsi, unjuk kerja , interface, design constraint, dan kriteria

validasi merupakan hal yang mendasar. Ciri-ciri dapat ditentukan melalui

komunikasi yang hati-hati antara pelanggan dan pengembang.

Mitos: kebutuhan proyek berubah terus-menerus, tetapi perubahan

tersebut dapat diakomodasi karena perangkat lunak bersifat fleksibel.

Kenyataan: Memang benar bahwa kebutuhan-kebutuhan perangkat lunak

selalu berubah. Tetapi pengaruh perubahan itu bervariasi sesuai waktu saat

perangkat lunak dikenalkan. Perubahan-perubahan pada fungsi, unjuk

kerja, atau karakteristik lain pada saat implementasi (kode dan tes) besar

pengaruhnya terhadap biaya. Perubahan, ketika diminta setelah perangkat

lunak diproduksi, dapat lebih mahal daripada bila perubahan yang sama

dilakukan pada saat yang lebih awal.

Mitos Para Praktisi. Seperti yang ditulis sebelumnya, selama masa awal

perangkat lunak, pemrograman dilihat sebagai sebuah karya seni. Cara dan

kebiasaan lama tetap sukar lenyap.

Mitos: Sekali kita menulis program, dan dapat membuatnya bekerja,

pekerjaan kita akan terselesaikan.

Kenyataan: Data industri menunjukkan bahwa antara 50 sampai 70 dari

semua usaha yang dilakukan pada sebuah program akan terus dilakukan

sampai program diantar ke tangan konsumen untuk yang pertama kalinya.

Page 10: Resume Rpl

8

Mitos: Saya benar-benar tidak mempunyai cara untuk “menilai” kualitas

program, kecuali jika saya dapat membuat program itu “berjalan”.

Kenyataan: Salah satu dari mekanisme jaminan kualitas perangkat lunak

yang paling efektif dapat diperkirakan dari awal proyek – formal technical

review. Tinjauan perangkat lunak merupakan “filter kualitas” yang lebih

efektif daripada pengujian untuk menemukan kelas-kelas kesalahan

perangkat lunak yang khusus.

Mitos: satu-satunya yang dapat disampaikan untuk sebuah proyek yang

sukses adalah program yang bekerja.

Kenyataan: Program yang bekerja hanya merupakan salah satu bagian

dari konfigurasi perangkat lunak yang menyangkut program, dokumen,

dan data. Dokumentasi membentuk fondasi bagi perkembangan yang

berhasil, serta yang lebih penting lagi, memberikan tuntunan bagi tugas

pemeliharaan perangkat lunak.

4. Proses Perangkat Lunak

Merupakan aktifitas yang saling terkait (koheren) untuk

menspesifikasikan, merancang, implementasi dan pengujian sistem perangkat

lunak.

Karakteristik proses pada perangkat lunak terdiri dari:

- Understandability

- Supportability

- Acceptability

- Reliability

- Maintainability

Secara umum prorses prangkat lunak terdiri dari beberapa proses yaitu,

spesifikasi, pengambangan, validasi, dan evolusi.

Spesifikasi merupakan apa yang harus dilakukan oleh perangkat lunak dan

batasan/kendala pengembangannya

Pengembangan merupakan proses memproduksi sistem perangkat lunak

Validasi merupakan pengujian perangkat lunak terhadap keinginan pengguna

Evolusi merupakan perubahan perangkat lunak berdasarkan perubahan keinginan.

Pada tahap proses rekayasa perangkat lunak, ciri-ciri yang dimunculkan

antara lain:

Biasanya, spesif

Lebih menghilangkan pembedaan sampai spesifikasi, desain, dan

manufacture

Tidak dalam bentuk fisik untuk menguji sistem

Software tidak bisa wear-out (maintenance bukan berarti mengganti

komponen)

Page 11: Resume Rpl

9

5. Model Proses Perangkat Lunak

Merupakan suatu representasi proses software yang disderhanakan,

dipresentasikan dari perspektif khusus

5.1 Model Konvensional

Model konvensional pada proses perangkat lunak mulai dikembangkan

sebelum pertengahan 1970-an. Dengan ciri cara spesifikasi narrative Victorian

novel, hard to read, hard to understand, dan virtually impossible to maintain.

Banyak macam model konvensional “klasik”, antara lain:

Linear Sequential Model / Waterfall Model

Prototyping Model

RAD (Rapid Application Development) Model

Linear SequentialModel/ Waterfall Model

Model ini adalah model klasik yang bersifat sistematis, berurutan dalam

membangun software. Berikut ini ada dua gambaran dari waterfall model.

Sekalipun keduanya menggunakan nama-nama fase yang berbeda, namun sama

dalam intinya. Fase-fase dalam Waterfall Model menurut referensi Pressman:

Fase-fase dalam Waterfall Model menurut referensi Sommerville :

1. Requirements analysis and definition: Mengumpulkan kebutuhan secara

lengkap kemudian kemudian dianalisis dan didefinisikan kebutuhan yang

harus dipenuhi oleh program yang akan dibangun. Fase ini harus dikerjakan

secara lengkap untuk bisa menghasilkan desain yang lengkap.

2. System and software design: Desain dikerjakan setelah kebutuhan selesai

dikumpulkan secara lengkap.

Page 12: Resume Rpl

10

3. Implementation and unit testing: desain program diterjemahkan ke dalam

kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan.

Program yang dibangun langsung diuji baik secara unit.

4. Integration and system testing: Penyatuan unit-unit program kemudian diuji

secara keseluruhan (system testing).

5. Operation and maintenance: mengoperasikan program dilingkungannya dan

melakukan pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi

dengan situasi sebenarnya.

Kekurangan yang utama dari model ini adalah kesulitan dalam

mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya harus

lengkap dan selesai sebelum mengerjakan fase berikutnya.

Masalah dengan waterfall :

1. Perubahan sulit dilakukan karena sifatnya yang kaku.

2. Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara

lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada

kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan

kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar

terjadi.

3. Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana

proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa

bagian sub-proyek.

Model Prototyping

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 prototyping sangat membantu

proses pembangunan software.

Proses pada model prototyping yang digambarkan pada gambar 1, 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.

Page 13: Resume Rpl

11

Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan

terpenuhi. 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.

RAD (Rapid Application Development)

RAD adalah model proses pembangunan PL yang incremental. RAD

menekankan pada siklus pembangunan yang pendek/singkat. RAD mengadopsi

model waterfall dan pembangunan dalam waktu singkat dicapai dengan

menerapkan component based construction. Waktu yang singkat adalah batasan

yang penting untuk model ini.

Jika kebutuhan lengkap dan jelas maka waktu yang dibutuhkan untuk

menyelesaikan secara komplit software yang dibuat adalah misalnya 60 sampai 90

hari.

Kelemahan dalam model ini:

1. tidak cocok untuk proyek skala besar

2. proyek bisa gagal karena waktu yang disepakati tidak dipenuhi

3. sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini

4. resiko teknis yang tinggi juga kurang cocok untuk model ini

Page 14: Resume Rpl

12

Fase-fase di atas menggambarkan proses dalam model RAD. Sistem

dibagi-bagi menjadi beberapa modul dan dikerjakan dalam waktu yang hampir

bersamaan dalam batasan waktu yang sudah ditentukan.

1. Business modelling : menjawab pertanyaan-pertanyaan: informasi apa yang

mengendalikan proses bisnis? Informasi apa yang dihasilkan? Siapa yang

menghasilkan informasi? Kemana informasi itu diberikan? Siapa yang

mengolah informasi? kebutuhan dari sistem

2. Data modelling: aliran informasi yang sudah didefinisikan, disusun menjadi

sekumpulan objek data. Ditentukan karakteristik/atribut dan hubungan antar

objek-objek tersebut analisis kebutuhan dan data

3. Process Modelling : objek data yang sudah didefinisikan diubah menjadi

aliran informasi yang diperlukan untukmenjalankan fungsi-fungsi bisnis.

4. Application Generation: RAD menggunakan component program yang sudah

ada atau membuat component yang bisa digunakan lagi, selama diperlukan.

6. Testing and Turnover: karena menggunakan component yang sudah ada,

maka kebanyakan component sudah melalui uji atau testing. Namun

component baru dan interface harus tetap diuji.

5.2 Model Evolusioner

Bersifat iteratif/ mengandung perulangan. Hasil proses berupa produk

yang makin lama makin lengkap sampai versi terlengkap dihasilkan sebagai

produk akhir dari proses.

Dua model dalam evolutionary software process model adalah:

1. Incremental Model (Original: Mills)

Page 15: Resume Rpl

13

1) kombinasikan element-element dari waterfall dengan sifat iterasi/perulangan.

2) element-element 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 PL tidak

cukup.

5) Mampu mengakomodasi perubahan secara fleksibel.

6) Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi

produk yang sudah bisa berfungsi dengan spesifikasi dasar.

Masalah dengan Incremental model:

a. cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding)

b. mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam

rencana spesifikasi masing-masing hasil increment

2. Spiral Model (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

Page 16: Resume Rpl

14

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.

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, makamenggunakan model formal dengan

perhitungan matematis, dan jika masalahnya adalah integrasi sistem 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 sektor tidak bisa saja dikembangkan seperti pada pembagian

sektor berikut pada model variasi spiral di bawah ini:

1. Customer communication: membangun komunikasi yang baik dengan

pengguna/customer.

2. Planning: mendefinisikan sesumber, batas waktu, informasi-informasi lain

seputar proyek

3. Risk analysis: identifikasi resiko managemen dan teknis

4. Engineering: pembangunan contoh-contoh aplikasi, misalnya prototype

5. Construction and release : pembangunan, test, install dan support.

6. Customer evaluation: mendapatkan feedback dari pengguna beradasarkan

evaluasi PL pada fase engineering dan fase instalasi.

Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu

yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan

yang realistik untuk PL 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.