Model Proses Rekayasa Perangkat Lunak
Pemodelan dalam suatu rekayasa perangkat
lunak merupakan suatu hal yang dilakukan di tahapan awal. Di dalam suatu
rekayasa dalam perangkat lunak sebenarnya masih memungkinkan tanpa melakukan
suatu pemodelan. Namun hal itu tidak dapat lagi dilakukan dalam suatu industri
perangkat lunak. Pemodelan delam perangkat lunak merupakan suatu yang harus
dikerjakan di bagian awal dari rekayasa, dan pemodelan ini akan mempengaruhi
perkerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut.
Di dalam suatu industri dikenal berbagai
macam proses, demikian juga halnya dengan industri perangkat lunak. Perbedaan
proses yang digunakan akan menguraikan aktivitas-aktivitas proses dalam
cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang
berbeda untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin
dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda. Namun
beberapa proses lebih cocok dari lainnya untuk beberapa tipe aplikasi. Jika
proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang
dikembangkan.
Pada rekayasa perangkat lunak, banyak
model yang telah dikembangkan untuk membantu proses pengembangan perangkat
lunak. Model-model ini pada umumnya mengacu pada model proses pengembangan
sistem yang disebut System Development Life Cycle (SDLC) .
Setiap model yang dikembangkan mempunyai
karakteristik sendiri. Namun secara umum ada persamaannya, yaitu :
1.
Kebutuhan
terhadap definisi masalah yang jelas. Input utama dari setiap model pengembangan
perangkat lunak adalah pendefinisian masalah yang jelas. Semakin jelas akan
semakin baik karena akan memudahkan dalam penyelesaian masalah. Oleh karena itu
pemahaman masalah merupakan bagian penting dari model pengembangan perangkat
lunak.
2.
Tahapan-tahapan
pengembangan yang teratur. Meskipun model-model pengembangan perangkat lunak
memiliki pola yang berbeda-beda, biasanya model-model tersebut mengikuti pola
umum analysis – design – coding – testing – maintenance.
3.
Stakeholder
berperan sangat penting dalam keseluruhan tahapan pengembangan. Stakeholder
dalam rekayasa perangkat lunak dapat berupa pengguna, pemilik, pengembang,
pemrogram dan orang-orang yang terlibat dalam rekayasa perangkat lunak tersebut.
4.
Dokumentasi
merupakan bagian penting dari pengembangan perangkat lunak. Masing-masing
tahapan dalam model biasanya menghasilkan sejumlah tulisan, diagram, gambar
atau bentuk-bentuk lain yang harus didokumentasi dan merupakan bagian tak
terpisahkan dari perangkat lunak yang dihasilkan.
5.
Keluaran
dari proses pengembangan perangkat lunak harus bernilai ekonomis. Nilai dari
sebuah perangkat lunak sebenarnya agak susah dirupiah- kan. Namun efek dari
penggunaan perangkat lunak yang telah dikembangkan haruslah memberi nilai
tambah bagi organisasi. Hal ini dapat Setiap model yang dikembangkan mempunyai
karakteristik sendiri-sendiri.
Model proses perangkat lunak masih
menjadi object penelitian, tapi sekarang ada banyak model umum atau paradigma
yang berbeda dari pengembangan perangkat lunak, antara lain:
Sebuah pendekatan pengembangan perangkat
lunak sistematik dan sekuensial. Disebut juga “Classic Life Cycle”. Disebut
waterfall (berarti air terjun) karena memang diagram tahapan prosesnya mirip
dengan air terjun yang bertingkat.
Aktivitas Waterfall Model
· Requirements analysis and definition :
mengumpulkan kebutuhan secara lengkap kemudian dianalisis dan didefinisikan
kebutuhan yang hasrus dipenuhi oleh program yang akan dibangun.
· System and software design : desain
dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap.
· Implementation and unit testing : desain
program diterjemahkan ke dalam kode-kode dengan menggunakan bahasa pemrograman
yang sudah ditentukan. Program yang dibangun langsung diuji.
· Integration and system testing :
penyatuan unit-unit program kemudian diuji secara keseluruhan (system testing)
· Operation and maintenance :
mengoperasikan program dilingkungannya dan melakukan pemeliharaan, seperti
penyesuaian atau perubahan karena adaptasi dengan situasi sebenarnya.
Keunggulan dari waterfall:
1.
Software
yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik.
2.
Dokumen
pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan
dengan lengkap sebelum melangkah ke fase berikutnya.
Kekurangan dari 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.
B. Evolutionary Software Process Models
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
Incremental Model merupakan gabungan
antara model linear sekuensial dan prototyping. Setiap linear sekuen
menghasilkan produk yang deliveriables. Increment pertama merupakan produk inti
yang mengandung persyaratan/kebutuhan dasar. Penambahan dilakukan pada
increment-incremet berikutnya.
Keterangan:
1.
Kombinasikan
elemet-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.
Keunggulan dari Incremental Model :
1.
Personil
bekerja optimal
2.
Pihak
konsumen dapat langsung menggunakan dahulu bagian-bagian yang telah selesai
dibangun. Contohnya pemasukan data karyawan
3.
Mengurangi
trauma karena perubahan sistem. Klien dibiasakan perlahan-lahan
menggunakan produknya bagian per bagian
4.
Memaksimalkan
pengembalian modal investasi konsumen
Kekurangan dari 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
3.
Dapat
menjadi build and Fix Model, karena kemampuannya untuk selalu mendapat
perubahan selama proses rekayasa berlangsung
2. Spiral model
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. Langkahlangkah 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, maka
menggunakan 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:
· Customer communication: membangun
komunikasi yang baik dengan pengguna/customer.
· Planning: mendefinisikan sesumber, batas
waktu, informasi-informasi lain seputar proyek
· Risk analysis: identifikasi resiko
managemen dan teknis
· Engineering: pembangunan contoh-contoh
aplikasi, misalnya prototype
· Construction and release : pembangunan,
test, install dan support.
· Customer evaluation: mendapatkan
feedback dari pengguna berdasarkan evaluasi PL
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.
C. Transformasi Formal
Metode ini berbasiskan pada transformasi
spesifikasi secara matematik melalui representasi yang berbeda untuk suatu
program yang dapat dieksekusi. Trasformasi menyatakan spesifikasi program
Menggunakan pendekatan ‘Cleanroom’ untuk pengembangan PL.
Metode ini mempunyai keterbatasan dalam
pemakaiannya. Keunggulannya adalah mengurangi jumlah kesalahan pada sistem
sehingga penggunaan utamanya adalah pada sistem yang kritis. Hal ini menjadi
efektif dari segi biaya.
Pemakaian model pengembangan formal
memerlukan tingkat kerahasian sebelum digunakan.Permasalahan dalam model
pengembangan metode formal:
۞ Memerlukan keahlian khusus dan
pelatihan untuk mengaplikasikannya
۞ Sulit menentukan beberapa aspek
dari suatu sistem seperti user interface
D. Model Rapid Aplication Development
(RAD)
Rapid Aplication 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
sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada
aplikasi sistem konstruksi, pendekatan RAD melingkupi fase – fase sebagai
berikut :
♣ 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 memunculkanya? Ke mana informasi itu pergi?
Siapa yang memprosesnya?
♣ 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.
♣ Prosess 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.
♣ Aplication 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 memkai 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.
♣ 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.
Keunggulan model RAD adalah :
1.
Setiap
fungsi mayor dapat dimodulkan dalam waktu tertentu kurang dari 3 bulan dan
dapat dibicarakan oleh tim RAD yang terpisah dan kemudian diintegrasikan
sehingga waktunya lebih efisien
2.
RAD
mengikuti tahap pengembangan sistem seperti umumnya, tetapi mempunyai kemampuan
untuk menggunakan kembali komponen yang ada sehingga pengembang tidak perlu
membuat dari awal lagi dan waktu yang lebih singkat
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.
E. Prototyping Model
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 model prototyping, 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. 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:
· 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.
· 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. Component-based Development Model
Component-based development sangat
berkaitan dengan teknologi berorientasi objek. Pada pemrograman berorientasi
objek, banyak class yang dibangun dan menjadi komponen dalam suatu software.
Class-class tersebut bersifat reusable artinya bisa digunakan kembali. Model
ini bersifat iteratif atau berulang-ulang prosesnya.
Secara umum proses yang terjadi dalam
model ini adalah:
1.
Identifikasi
class-class yang akan digunakan kembali dengan menguji class tersebut dengan
data yang akan dimanipulasi dengan aplikasi/software dan algoritma yang baru
2.
Class
yang dibuat pada proyek sebelumnya disimpan dalam class library, sehingga bisa
langsung diambil dari library yang sudah ada. Jika ternyata ada kebutuhan class
baru, maka class baru dibuat dengan metode berorientasi objek.
3.
Bangun
software dengan class-class yang sudah ditentukan atau class baru yang dibuat,
integrasikan.
Penggunaan kembali komponen software
yang sudah ada menguntungkan dari segi:
►Siklus waktu pengembangan software,
karena mampu mengurangi waktu 70%
►Biaya produksi berkurang sampai 84%
arena pembangunan komponen berkurang
Pembangunan software dengan menggunakan
komponen yang sudah tersedia dapat menggunakan komponen COTS (Commercial
off-the-shelf) – yang bisa didapatkan dengan membeli atau komponen yang sudah
dibangun sebelumnya secara internal. Component-Based Software Engineering
(CBSE) adalah proses yang menekankan perancangan dan pembangunan software
dengan menggunakan komponen software yang sudah ada. CBSE terdiri dari dua
bagian yang terjadi secara paralel yaitu software engineering (component-based
development) dan domain engineering.
1.
Domain
engineering menciptakan model domain bagi aplikasi yang akan digunakan untuk
menganalisis kebutuhan pengguna. Identifikasi, pembangunan, pengelompokan dan
pengalokasikan komponen-komponen software supaya bisa digunakan pada sistem
yang ada dan yang akan datang.
2.
Software
engineering (component-based development) melakukan analisis terhadap domain
model yang sudah ditetapkan kemudian menentukan spesifikasi dan merancang
berdasarkan model struktur dan spesifikasi sistem, kemudian melakukan
pembangunan software dengan menggunakan komponen-komponen yang sudah ditetapkan
berdasarkan analisis dan rancangan yang dihasilkan sebelumnya hingga akhirnya
menghasilkan software.
G. Extreme Programming (XP) Model
Model proses ini diciptakan dan
dikembangkan oleh Kent Beck. Model ini adalah model proses yang terbaru dalam
dunia rekayasa perangkat lunak dan mencoba menjawab kesulitan dalam
pengembangan software yang rumit dan sulit dalam implementasi. Menurut Kent
Beck XP adalah : “A lightweight, efficient, low-risk, flexible,predictable,
scientific and fun way to develop software”. Suatu model yang menekankan pada:
► keterlibatan user secara langsung
► pengujian
► pay-as-you-go design
Adapun empat nilai penting dari XP :
1.
Communication/Komunikasi
: komunikasi antara developer dan klien sering menjadi masalah. Karena itu
komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair
programming). Developer didampingi oleh pihak klien dalam melakukan coding dan
unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil
berkomunikasi dengan developer. Selain itu perkiraan beban tugas
jugadiperhitungkan.
2.
Simplicity/
sederhana: Menekankan pada kesederhanaan dalam pengkodean: “What is the
simplest thing that could possibly work?” Lebih baik melakukan hal yang
sederhana dan mengembangkannya besok jika diperlukan. Komunikasi yang lebih
banyak mempermudah, dan rancangan yang sederhana mengurangi penjelasan.
3.
Feedback
/ Masukan/Tanggapan: Setiap feedback ditanggapi dengan melakukan tes, unit test
atau system integration dan jangan menunda karena biaya akan membengkak (uang,
tenaga, waktu).
4.
Courage
/ Berani: Banyak ide baru dan berani mencobanya, berani mengerjakan kembali dan
setiap kali kesalahan ditemukan, langsung diperbaiki.
