Saturday, April 26, 2014
A. Model
Waterfall
Pada
tahun 1960-an dan 1970-an, proyek pengembangan perangkat lunak merupakan
pekerjaan yang sangat memakan biaya dan waktu karena pengembangan perangkat lunak ini difokuskan pada
perencanaan dan pengendalian (Basili dan Musa, 1991). Kemunuclan model
waterfall adalah untuk membantu mengatasi kerumitan yang terjadi akibat
proye-proyek pengembangan perangkat lunak (Boehm, 1976). Seperti yang terlihat
pada gambar di bawah, sebuah model air terjum memacu tim pengembang untuk
merinci apa yang seharusnya perangkat lunak lakukan (mengumpulkan dan
menentukan kebutuhan system) sebelum system tersebut dikembangkan.
Tahapan-tahapan
utama dari model ini memetakan kegiatan-kegiatan pengembangan dasar yaitu :
1. Analisis
dan definisi persyaratan. Pelayanan, batasan dan tujuan sistem ditentukan
melalui konsultasi dengan user system. Persyaratan ini kemudian didefinisikan
secara rinci dan berfungsi sebagai spesifikasi system.
2. Perancangan
system dan perangkat lunak. Proses perancangan system membagi persyaratan dalam
system perangkat keras atau lunak. Kegiatan ini menentukan arsitektur system
secara keseluruhan. Perancangan perangkat lunak melibatkan identifikasi dan
deskripsi abstraksi system perangkat lunak yang mendasar dan
hubungan-hubungannya.
3. Implementasi
dan pengujian unit. Pada tahap ini, perancangan perangkat lunak direalisasikan
sebagai serangkaian program atau unit program. Pengujuan unit melibatkan
verifikasi bahwa setiap unit telah memenuhi spesifikasinya.
4. Integrasi
dan pengujian system. Unit program atau program individual diintegrasikan dan
diuji sebagai system yang lengkap untuk menjamin bahwa persyaratan system telah
dipenuhi. Setelah pengujian system, perangkat lunak dikirim kepada pelanggan.
5. Operasi
dan pemeliharaan. Biasanya (walau tidak seharushya), ini merupakan fase siklus
hidup yang paling lama. Sistem diinstal dan dipakai. Pemeliharaan mencakup
koreksi dari berbagai error yang tidak ditemukan pada tahap-tahap terdahulu,
perbaikan atas implementasi unit system dan pengembangan pelayanan system,
sementara persyaratan-persyaratan baru ditambahkan.
 |
| Model Waterfall |
B. Pengembangan
Evolusioner
Pengembangan
evolusioner berdasarkan pada ide untuk mengembangkan implementasi awal,
memperlihatkan kepada user untuk dikomentari, dan memperbaiki versi demi versi
sampai system yang memenuhi persyaratan diperoleh. Tidak ada kegiatan
spesifikasi, pengembangan, dan validasi yang terpisah, alih-alih kegiatan-kegiatan
ini dilakukan pada saat yang bersamaan dengan umpan balik yang cepat untuk
masing-masing kegiatan. Ada dua jenis pengembangan evolusioner:
1. Pengembangan
eksploratori. Tujuan proses ini adalah bekerja dengan pelanggan untuk
menyelidiki persyaratan mereka dan mengirimkan sistem akhir. Pengembangan
dimulai dengan bagian-bagian sistem yang dipahami. Sistem berubah dengan adanya
tambahan fitur-fitur baru sesuai usulan pelanggan.
2. Prototipe
yang dapat dibuang (throw-away). Tujuan pengembangan evolusioner adalah untuk
memahami persyaratan pelanggan dan dengan demikian mengembangkan definisi
persyaratan yang lebih baik untuk sistem. Prototipe berkonsentrasi pada
eksperimen, dengan persyaratan pelanggan yang tidak dipahami dengan baik.
Pendekatan
evolusioner terhadap pengembangan perangkat lunak seringkali lebih efektif dari
pendekatan air terjun dalam menghasilkan sistemyang memenuhi kebutuhan langsung
dari pelanggan. Keuntungan proses perangkat lunak yang berdasarkan pada
pendekatan evolusioner adalah bahwa spesifikasi dapat dikembangkan secara
inkremental. Sementara user mendapat pemahaman yung lebih baik dari
masalahmereka, sistem perangkat lunak dagat merefleksikannya. Namun demikian, dari sudut pandang rekayasa
dan manajemen, ada tiga masalah dengan cara ini:
1. Proses
tidak bisa dilihat. Manajer memerlukan hasil reguler untuk mengukur kemajuan.
Jika sistem dikembangkan dengan cepat, tidaklah efektif dari segi biaya jika
dihasilkan dokumen yang merefleksikan setiap versi sistem.
2. Sistem
seringkali memiliki struktur yang buruk. perubahan yang terus-menerus cenderung
merusak struktur perangkat lunak. penyesuaian perubahan perangkat lunak menjadi
kian sulit dan mahal.
3. Mungkin
diperlukan alat bantu dan teknik khusus. Keperluan ini memungkinkan pengembangan
yang cepat tetapi mungkin tidak kompatibel dengan alat bantu atau teknik lain
dan relatif hanya sedikit orang yang memiliki keahlian untuk memakainya.
Untuk
sistem kecil (kurang dari 100.000 baris kode) atau sistem berukuran menengah
(sampai 500.000 baris kode) dengan waktu hidup yang pendek, pendekatan
evolusioner untuk pengembangan merupakan
pendekatan yang paling baik. Akan tetapi, untuk sistem yang besar dan memiliki
waktu hidup yang lama, masalah-masalah dengan pengembangan evolusioner bisa
menimbulkan masalah yang besar. Untuk sistem-sistem ini, direkomendasikan
proses campuran, yang memakai fitur-fitur terbaik dari model air terjun dan
pengembangan evolusioner. cara ini bisa melibatkan pengembangan prototipe yang
dapat dibuang dengan menggunakan pendekatan evolusiner unfuk menangani
ketidakpastian pada spesifikasi sistem. Sistem ini bisa diimplementasi kemudian
dengan tn"nggunutun pendekatan yang lebih terstruktur. Bagian-bagian
sistem yang dipahami dengan baik dapat dispesifikasi dan dikembangkan dengan
menggunakan proses yang berdasarkan pada model air terjun. Bagian sistem yang
lain, seperti interface untuk dispesifikasi sebelumnya, harus dikembangkan dengan
pendekatan perffograman eksploratori.
C. Pengembangan
Sistem Formal
Pengembangan
sistem formal merupakan pendekatan terhadap pengembangan perangkat lunak yang memiliki kesamaan dengan
model air terjun, tetapi proses pengembangannya didasarkan pada transformasi
matematis dari spesifikasi system menjadi program yang dapat dijalankan.
 |
| Pengembangan system formal |
Perbedaan kritis antara pendekatan ini dan model air terjun
adalah :
1.
Spesifikasi persyaratan
perangkat lunak diperbaiki menjadi spesifikasi formal yang rinci yang
dinyatakan dalam notasi matematis
2. Proses pembangunan perancangan, ,
imprementasi, dan pengujian unit digantikn oleh proses pengembangan
transformasional di mana spesifikasi formal diperbaiki, melalui serangkaian transformasi,
menjadi program.
Pada
proses transfoirnasi, representasi matematis formal dari sistem secara sistematis
diubah menjadi representasi sistem yang lebih rinci, tetapi tetap benar secara
matematis. Setiap langkah menambahkan perincian sampai speiifikasi formal diubah
menjadi program yang ekivalen. Transformasikan sampai cukup dekat sehingga
usaha verifikasi transformasi tidak berlebihan. oengan demikian dapat dijamin,
dengan menganggap tidak adanya error verifikasi, bahwa program merupakan
implementasi yang benar dari spesifikasi.
Keuntungan
pendekatan transformasional dibandingkan dengan penyetujuan bahwa suatu program
telah memenuhi spesifikasinya adalah bahlwa jarak Antara setiap transformasi
lebih kecil dari pada jarak antara spesifikasi dan program. Bukti program
sangat panjang dan tidak praktis untuk sistem berskala besar. Pendekatan transformasional
yang terdiri dari serangkaian langkah yang lebih kecil akan lebih mudah ditelusuri.
Namun demikian,pemilihan transfomasi apa yang akan dipakai merupakan pekerjaan
yang membutuhkan keahlian dan membuktikan hubungan transformasi adalah sesuatu
yang sulit.
Contoh
yang paling dikenal tentang proses pengembangan formal ini adalah proses Cleanroom
yang aslinya dikembangkan oleh IBM (Mills er al., 1987; Selby et al1987;
Linger, 1994; Prowell et al, 1999). Proses Cleanroom bergantung pada
pengembangan perangkat lunak incremental dansetiap tahap dikembangkan dan kebenarannya
didemonstrasikan dengan menggunakan pendekatan formal. Tidak ada pengujian kesalahan
pada proses dan pengujian system difokuskan pada penilaian keandalan system.
Pendekatan
Cleanroom dan pendekatan lain bagi pengembangan
formal yang berdasarkan pada metode B (Wordsworth, 1996) telah diterapkan
dengan sukses. Ada sedikit kesalahan pada
system yang dikirimkan dan biaya pengembangan tidak berbeda secara signifikan
dari biaya pendekatan lain. Pendekatan ini terutama disesuaikan dengan pengembang
system yang memiliki persyaratan
keselamatan keandalan, atau keamanan yang ketat. Pendekatan formal menyederhanakan
pembuatan kasus keselamatan atau keamanan yang menunjukkan kepada pelanggan atau
badan sertifikasi bahwa sistem tersebut telah memenuhi persyaratan keselamatan
atau keamanan.
Di
luar domain khusus ini, proses yang berdasarkan pada transformasi formal tidak
digunakan secara luas. Cara ini
memerlukan keahlian khusus dan sesungguhnya untuk sebagian besar system, proses
ini tidak memberikan keuntunganbiaya atau kualitas yang signifikan dibandingkan
dengan pendekatan yang lain. Alasan utamanya adalah bahwa interaksi sistem
tidak menerima spesifikasi system dan hal ini menyita bagian sangat besar dari
usaha pengembangan sebagian besar sistem perangkat lunak.
D. Pengembangan
Berorientasi Pemakaian Ulang
Pada
sebagian besar proyek perangkat lunak terjadi pemakaian ulang. Hal ini biasanya
terjadi secara intormal ketika orang yang bekerja di proyek tersebut mengetahui
adanya rancangan atau kode yang mirip dengan yang dibutuhkan. Mereka mencari rancangan
atau kode ini, memodifikasinya sebagaimana dibutuhkan, dan menggabungkannya dalam
sistem. pada pendekatan evolusioner, pemakaian ulang seringkali dipandang
penting untuk pengembangan system yang cepat.
Pemakaian
ulang informal ini terjadi dengan mengabaikan proses generik yangdipakai. Namun
d"mlkian, dalam beberapa tahun belakangan ini suatu pendekatan terhadap
pengembanganperangkat lunak (rekaya perangkat lunak berdasarkan komponen) yang
berdasarkan atas pemakaian ulang telah
muncul dan penggunaannya bertambah luas.
Pendekatan
yang berorientasi pemakaian ulang ini bergantung pada sejumlah besar komponen perangkat lunak yang dapat dipakai ulang yang bisa
didapa dan beberapa kerangka kerangka kerja untuk komponen-komponen ini.
Kadangkala komponen-komponen ini merupakan
sistem juga (COTS atau-Commercial Off-The-Shelf systems / Sistem Siap Beli Komersial
yang dapat digunakan untuk memberikan fungsionalitas khusus seperti format
teks, perhitungan numeric, dll.
 |
| Pengembangan berorientasi pemakaian ulang |
Sementara
tahap spesifikasi persyaratan dan tahap validasi dapat dibandingkan dengan
proses lain, tahap pertengahan pada proses berorientasi pemakaian ulang ini ternyata
berbeda. Tahap-tahap ini adalah:
1. Analisis
komponen. Jika diketahui spesifikasi persyaratan, komponen-komponen untuk
implementasi spesifikasi tersebut akan dicari. Biasanya, tidak ada kesesuaian
yang tepat dan komponen yang dapat dipakai hanya memberikan sebagian dari
fungsionalitas yang dibutuhkan.
2. Modifikasi persyaratan. Pada tahap ini,
persyaratan dianalisis dengan menggunakan informasi mengenai komponen yang
telah didapat. persyarltan kemudian dimodifikasi untuk merefleksikan komponen
yang tersedia. Jika modifikasi tidak mungkin dilakukan, maka kegiatan analisis
komponen bisa diulang untuk mencari solusi alternatif.
3. Perancangan
sistem dengan pemakaian arang. pada fase
ini, kerangka kerja sistem dirancang, atau kerangka kerja yang telah ada
dipakai ulang. Perancang memperhitungkan komponen yang dipakai ulang dan
mengatur kerangka kerja untuk menyesuaikan. Beberapa perangkat lunak yang baru
mungkin perlu dirancang jika komponen yang dapat dipakai ulang tidak tersedia.
4. Pengembangan
dan integrasi. perangkat runak yang tidak dapat dibeli akan dikembangkan dan
komponen dan sistem corS diintegrasikan untuk membentuk sistem. Integrasi
sistem, pada model ini, bisa merupakan bagian dari proses pengembangan dan
bukan merupakan kegiatan yang terpisah.
Model
yang berorientasi pemakaian ulang mempunyai keuntungan nyata yaitu mengurangi
besarnya perangkat lunak yang akan dikembangkan, sert-a memperkecil biaya dan
risiko. Keuntungan ini biasanya memungkinkan penyelesaian perangkat lunak
dengan cepat. Akan tetapi, kompromi persyaratan sangatlah penting dan bisa menghasilkan
sistem yang tidak memenuhi kebutuhan sebenarnya dari user. Lebih jauh lagi,
kontrol terhadap evolusi sistem akan hilang sementara versi baru dari komponen
yang dapat dipakai ulang tidak terkontrol oleh organisasi yang memakai komponen
ini.
