BAB 16

PENGGUNAAN KEMBALI PERANGKAT LUNAK

(SOFTWARE REUSE)

REKAYASA PERANGKAT LUNAK EDISI KE-9

IAN SOMMERVILLE LANCASTER UNIVERSITY
ADDISON – WESLEY 2011

DITERJEMAHKAN OLEH:

OLIVER MANAHAN PASARIBU,S.T.

JURUSAN TEKNIK ELEKTRO
FAKULTAS TEKNIK
UNIVERSITAS BRAWIJAYA
MALANG 2018
Saat ini sedang bekerja sebagai Tenaga Harian Lepas/Karyawan Honorer Bagian Adm.
Keuangan dan Asset Sekretariat Daerah Kota Pematangsiantar Propinsi Sumatera Utara
Republik Indonesia

[Type here]
 16

Penggunaan Kembali
Perangkat Lunak
(Software Reuse)
Tujuan Pembelajaran
Tujuan pembelajaran bab ini adalah untuk memperkenalkan konsep penggunaan kembali
perangkat lunak (software reuse) dan menjelaskan pendekatan-pendekatan yang digunakan
dalam pengembangan suatu sistem yang berasarkan pada penggunaan kembali sistem skala
besar. Setelah mempelajari bab ini, mahasiswa diharapkan akan:

 Memahami manfaat dan permasalahan yang berhubungan dengan penggunaan kembali

perangkat lunak (reusing software) ketika sedang mengembangan suatu sistem.
 Memahami konsep dari kerangka kerja aplikasi sebagai himpunan dari reusable object
serta bagaimana kerangka kerja tersebut dapat digunakan dalam pengembangan
aplikasi.
 Memperkenalkan software product line, yaitu istilah yang digunakan untuk
penyebutan produk-produk yang dibangun dari suatu arsitektur inti bersama yang
dapat dikonfigurasi, pemanfaatan kembali komponen-komponen (reusable
components)
 Telah mempelajari bagaimana sistem-sistem dapat dikembangkan dengan melakukan
konfigurasi dan penyusunan sistem-sistem perangkat lunak off-the-shelf.

[Type here]
 Sistematika Penulisan::
16.1 Arsitektur Penggunaan Kembali Perangkat Lunak (Reuse Landscape)

16.2 Kerangka-Kerja Aplikasi

16.3 Regulasi Mengenai Produksi Perangkat Lunak Software

16.4 Reuse Produk COTS

[Type here]
 Bab 16 ■ Software reuse

Rekayasa perangkat lunak berlandaskan konsep ‘’reuse’’ adalah suatu strategi yang
digunakan dalam rekayasa perangkat lunak dimana proses pengembangan di akselerasi
dengan menggunakan kembali perangkat lunak yang telah ada. Meskipun konsep
penggunaan kembali (reuse) telah diajukan sebagai strategi pengembangan sejak lebih
dari 40 tahun yang lalu (McIlroy, 1968), namun pada kenyataannya pengembangan
dengan konsep penggunaan kembali menjadi sebuah ‘’norma’’ untuk suatu sistem bisnis
yang baru sejak tahun 2000. Pengembangan perangkat lunak yang berlandaskan konsep
reuse ini merupakan suatu tanggapan terhadap tuntutan kebutuhan akan produksi dan
perawatan perangkat lunak berbiaya rendah, proses penyerahan atau delivery sistem yang
lebih cepat dan peningkatan mutu perangkat lunak yang diproduksi. Semakin banyak
perusahaan-perusahaan yang melihat perangkat lunak yang diproduksi sebagai aset yang
sangat berharga. Mereka sedang mempromosikan konsep ‘’reuse’’ untuk meningkatkan
pengembalian modal investasi mereka dalam rekayasa perangkat lunak.
Ketersediaan perangkat lunak yang bersifat reusable telah bertambah secara
mencengangkan. Pergerakan open source telah menjadi suatu sarana dimana kode
perangkat lunak yang berukuran raksasa dapat digunakan kembali dengan biaya yang
rendah. Penggunaan kembali ini memungkinkan untuk dilakukan dalam reuse bentuk
pustaka-pustaka program atau reuse keseluruhan aplikasi. Ada banyak domain sistem
aplikasi yang tersedia, yang dapat disatukan dan diadopsi untuk memenuhi kebutuhan
khusus dalam suatu perusahaan. Beberapa perusahaan-perusahaan besar menyediakan
berbagai komponen yang dapat digunakan kembali untuk pelanggan mereka. Standar-
standar, seperti standar layanan web, telah membuat pengembangan dan penggunaan
kembali layanan-layanan yang bersifat umum dari sejumlah besar aplikasi menjadi lebih
mudah.
Rekayasa perangkat lunak berlandaskan penggunaan kembali (reuse) merupakan
suatu pendekatan untuk pengembangan perangkat lunak yang mencoba untuk
memaksimalkan penggunaan kembali perangkat lunak yang telah ada. Satuan-satuan
[Type here]
perangkat lunak yang digunakan kembali boleh jadi memiliki ukuran-ukuran yang
berbeda secara radikal. Sebagai contoh:

Reuse sistem aplikasi. Keseluruhan sistem aplikasi boleh jadi digunakan kembali dengan
menyertakannya tanpa mengubah sistem lain, atau dengan melakukan konfigurasi
aplikasi pelanggan-pelanggan yang berbeda. Sebagai contohnya adalah klasifikasi
aplikasi-aplikasi yang memiliki arsitektur yang serupa, tetapi yang disatukan untuk
pelanggan spesifik, dapat dikembangkan. Penulis akan menerangkan aplikasi sistem
reuse pada bagian berikutnya dari bab ini.

Reuse komponen. Komponen-komponen dari suatu aplikasi memiliki ukuran yang

brbeda-beda mulai dari bentuk sub sistem sampai kepada objek tunggak boleh jadi
digunakan. Sebagai contoh, suatu sistem pencocokan pola dikembangkan sebagai bagian
dari suatu sistem pemrosesan teks dapat digunakan kembali dalam sistem management.
Penulis akan menerangkan komponen reuse dalam bab 17 dan 19.

Reuse objek dan fungsi. Komponen-komponen perangkat lunak yang

mengimplementasikan suatu fungsi tunggal, seperti fungsi matematis, atau sebuah kelas
objek dapat digunakan kembali. Bentuk reuse ini, berdasarkan pada pustaka-pustaka
standar yang telah digunakan bersama selama 40 tahun terakhir. Ada banyak fungsi dan
kelas yang tersedia secara gratis. Pembaca dapat menggunakan kembali kelas dan fungsi
dalam pustaka ini dengan menghubungkan nya dengan kode aplikasi yang baru
dikembangkan. Dalam area seperti algoritma matematik dan grafik yang membutuhkan
pengalaman khusus untuk mengembangkan fungsi-fungsi dan objek-objek secara efisien,
ini merupakan pendekatan khusus yang efektif.
Sistem-sistem perangkat lunak dan komponen-komponen merupakan entitas
reusable yang potensial, namun sifat alami yang spesifik kadang-kadang membuat proses
modifikasi untuk suatu siautasi yang baru menjadi lebih mahal. Bentuk komplementer
dari reuse adalah ‘reuse konsep’; dari pada menggunakan komponen perangkat lunak,
[Type here]
mahasiswa dapat menggunakan kembali ide,cara, pekerjaan atau suatu algoritma.
(misalnya suatu model sistem), yang tidak menyertakan rincian implementasi. Dengan
demikian, ide, gagasan, cara, pekerjaan atau algoritma itu dapat dikonfigurasikan dan
disesuaikan untuk suatu situasi tertentu. Reuse konsep atau penggunaan kembali
konsep/gagasan dapat diterapkan sebagai pendekatan dalam membuat desain pola (telah
diterangkan dalam bab 7), produk-produk sistem yang dapat dikonfigurasi, dan
membangkitkan program.

Manfaat
Meningkatkan dependabilitas
Mengurangi resiko proses
Penggunaan Secara Efektif Oleh
Spesialis
Penjelasan
Perangkat lunak yang dimanfaatkan kembali, sudah pernah
diuji dan dijalankan pada suatu sistem, seharusnya lebih
dependable daripada perangkat lunak yang baru.Hal ini
disebabkan karena kesalahan-kesalahan yang terdapat dalam
proses desain dan implementasinya teah ditemukan dan
diperbaiki
Alokasi dan rincian Komponen biaya yang dikeluarkan untuk
perangkat lunak yang telah ada sudah dapat diketahui secara
pasti, sedangkan alokasi dan rincian komponen biaya untuk
pengembangan perangkat lunak yang baru masih perlu
dikalkulasi secara rinci. Hal ini merupakan faktor penting dalam
manajemen proyek karena akan mengurangi margin of error
dalam memperkirakan biaya proyek terutama untuk
komponen-komponen perangkat lunak yang besar yang
mengadopsi prinsip pemanfaatan kembali dalam tingkat sub
sistem.
Alih-alih melakukan suatu pekerjaan yang sama secara
berulang-ulang, ahli aplikasi (para insinyur) dapat
mengembangkan perangkat lunak yang dapat digunakan
kembali (reusable software) dan melakukan proses enkapsulasi
terhadap pengetahuan mereka.

[Type here]
 Kesesuaian terhadap standar Beberapa standar seperti standar antarmuka dapat
diimplementasikan sebagai suatu himpunan komponen-
komponen yang dapat digunakan kembali. Sebagai contoh, jika
menu-menu dalam antarmuka pengguna diimplementasikan
dengan menggunakan komponen-komponen reusable, maka
seluruh aplikasi akan menampilkan format menu yang sama
kepada para pengguna. Penggunaan antarmuka pengguna
standar meningkatkan dependabilitas karena akan mengurangi
kesalahan user ketika dihadapkan dengan suatu antarmuka
yang familiar.
Percepatan Pengembangan Proses pemasaran sistem sedini mungkin seringkali jauh lebih
penting daripada keseluruhan biaya pengembangan.
Penggunaan kembali perangkat lunak dapat mempercepat
produksi sistem karena dapat mengurangi waktu
pengembangan dan waktu validasi.

Gambar 16.1
Manfaat Penggunaan kembali Perangkat Lunak

Ketika suatu gagasan atau konsep digunakan kembali, proses reuse mengikutsertakan
suatu aktivitas dimana konsep-konsep abstrak dimulai untuk menciptakan komponen
reusable yang executable.
Suatu keuntungan yang jelas dari penggunaan kembali perangkat lunak adalah
bahwa biaya pengembangan keseluruhan (overall development-cost) seharusnya dapat
dikurangi. Komponen yang perlu ditentukan, didesain, diimplementasikan dan divalidasi
semakin sedikit. Bagaimanapun juga, pengurangan biaya hanya salah satu keuntungan
dari reuse. Pembaca dapat melihat manfaat atau keuntungan dari penggunaan kembali
aset-aset perangkat lunak dalam gambar 16.1
Meskipun demikian, tetap saja masih ada masalah-masalah dan biaya yang timbul
sehubungan dengan prinsip reuse (gambar 16.2). Ada komponen biaya penting yang

[Type here]
dihubungkan dengan pengertian apakah suatu komponen pantas untuk dipergunakan
kembali dalam suatu situasi khusus maupun dalam pengujian untuk meyakinkan
dependabilitas komponen tersebut. Biaya tambahan ini berarti bahwa adanya reduksi
dalam keseluruhan biaya yang dikeluarkan untuk pengembangan perangkat lunak sebagai
akibat adanya penggunaan kembali atau reuse boleh jadi kurang dapat diantisipasi.
Sebagaimana telah didiskusikan oleh penulis dalam bab 2, proses pengembangan
perangkat lunak perlu disesuaikan kembali dengan memasukkan konsep reuse ke dalam
perhitungan. Secara khusus, perlu dilakukan tahap perbaikan persyaratan-persyaratan.
Pada tahap ini, seluruh persyaratan yang telah dibuat dimodifikasi untuk merefleksikan
ketersediaan perangkat lunak yang bersifat reuseable. Tahap desain dan implementasi
sistem juga harus memperhitungkan secara eksplisit aktivitas-aktivitas yang berhubungan
dengan pemilihan dan evaluasi komponen-komponen mana saja yang akan dipergunakan
kembali.
Pemanfaatan kembali perangkat lunak (software reuse) akan menjadi lebih efektif
saat hal itu direncanakan sebagai bagian dari suatu program reuse yang diterapkan secara
luas dalam suatu organisasi pengembang perangkat lunak. Suatu penggunaan kembali
perangkat lunak melibatkan suatu penciptaan dari aset-aset yang dapat digunakan
kembali dan adaptasi dari sebuah proses pengembangan untuk memasukkan aset ini
dalam suatu perangkat lunak yang baru. Jepang telah memahami betapa pentingnya
perencanaan reuse ini selama bertahun-tahun (Matsumoto, 1984). Hal ini dibuktikan
dengan dimasukkannya reuse sebagai bagian yang tidak terpisahkan dalam proses
pengembangan perangkat lunak di Jepang (Cusamano, 1989). Perusahaan-perusahaan
seperi Hewlett-Packard pernah mengalami kesuksesan besar dalam pelaksanaan program
reuse mereka. (Griss AND Wosser 1995). Pengalaman mereka telah didokumentasikan
dalam sebuah buku yang ditulis oleh Jacobson dkk (1997)

Masalah Penjelasan

Tingginya biaya perawatan Jika kode sumber dari suatu sistem perangkat lunak atau
komponen yang dipergunakan kembali tidak tersedia, biaya

[Type here]
 perawatan menjadi lebih tinggi karena kuantitas element-
element yang dipergunakan kembali dari sistem perangkat
lunak tersebut dapat menyebabkan inkompatibilitas dengan
perubahan sistem.
Tidak ada dukungan Beberapa peralatan perangkat lunak yang tidak mendukung
peralatan pengembangan dengan prinsip reuse. Hal ini akan
menimbulkan kesulitan sehingga tidak mungkin untuk
mengintegrasikan peralatan-peralatan ini dengan suatu sistem
pustaka komponen.
Sindrom not-invented-here Sebagian insinyur perangkat lunak lebih suka untuk menulis
kembali komponen-komponen karena mereka percaya bahwa
mereka dapat meningkatkan kemampuan perangkat lunak
tersebut. Hal ini berhubungan dengan kepercayaan dan
kenyataan bahwa penulisan perangkat lunak yang asli terlihat
lebih menantang daripada menggunakan kembali perangkat
lunak milik orang lain.
Pembuatan,pemeliharan Populasi dari suatu pustaka komponen reusable dan adanya
dan penggunaan pustaka suatu keyakinan bahwa para pengembang perangkat lunak
komponen dapat menggunakan pustaka ini dapat menyebabkan
penggunaan kembali menjadi lebih mahal. Proses-proses
pengembangan harus disesuaikan bahwa pustaka digunakan.
Penemuan, pengertian dan Komponen-komponen harus ditemukan dalam suatu pustaka,
penyesuaian komponen- dimengerti, dan kadangkala disesuaikan agar dapat
komponen yang dapat dimanfaatkan dalam suatu lingkungan yang baru. Para insinyur
dipergunakan kembali harus memiliki alasan yang kuat dalam penemuan komponen
dalam pustaka atau library sebelum disertakan dalam pencarian
komponen sebagai bagian dari proses pengembangan yang
normal.

Gambar 16.2

Masalah-masalah yang timbul akibat adanya Penggunaan Kembali

[Type here]
16.1 Arsitektur Penggunaan Kembali Perangkat Lunak.
Selama lebih dari 20 tahun, banyak teknik telah dikembangkan untuk
mendukung ide penggunaan kembali perangkat lunak (software reuse). Teknik-
teknik ini mengemukakan kenyataan bahwa sistem-sistem yang berada dalam
daerah asal aplikasi yang sama adalah serupa dan memiliki kemungkinan untuk
reuse; implementasi reuse memungkinkan untuk dilakukan pada level yang
berbeda-beda mulai dari fungsi-fungsi sederhana sampai kepada aplikasi-aplikasi
lengkap; dan bahwa standar-standar untuk komponen-komponen yang digunakan
kembali memfasilitasi reuse. Gambar 16.3 menunjukkan sejumlah cara yang
mungkin untuk implementasi penggunaan kembali perangkat lunak, masing-
masing dijelaskan secara singkat dalam gambar 16.4.
Penulis telah menerangkan berbagai teknik yang digunakan untuk reuse.
Pertanyaan kuncinya adalah “dari sekian banyak teknik yang tersedia, teknik
manakah yang lebih akurat untuk digunakan dalam situasi tertentu?” Jelas, hal ini
bergantung pada persyaratan-persyaratan sistem yang sedang dikembangkan,
teknologi dan reusable-asset yang tersedia, dan pengalaman yang dimiliki oleh
team yang mengembangkan perangkat lunak tersebut. Faktor utama yang harus
dipertimbangkan saat merencanakan reuse adalah:

1. Jadwal pengembangan perangkat lunak. Jadwal pengembangan perangkat

lunak. Jika sebuah perangkat lunak perlu untuk dikembangkan secara cepat,
maka anda seharusnya mencoba untuk menggunakan kembali off-the-shelf
system COTS dari pada menggunakan kembali komponen-komponen secara
individual. Ini merupakan “bulir kasar” asset-asset yang dapat dipergunakan
kembali. Walaupun kesesuaian terhadapan persyaratan yang ditentukan belum
sempurna,namun pendekatan yang digunakan ini dapat meminimalisasi
jumlah pengembangan yang dipersyaratkan.

[Type here]
 Gambar 16.3
Tinjauan Umum Konsep “Reuse” Dalam Disiplin Ilmu Rekayasa Perangkat
Lunak

2. Siklus hidup/Masa Pakai Perangkat Lunak Yang Diharapkan. Jika anda

sedang mengembangkan sistem –sistem dengan waktu-hidup yang panjang,
anda seharusnya berfokus pada maintainabilitas sistem. Anda seharusnya
tidak hanya memikirikan mengenai manfaat sesaat dari reuse tetapi juga
implikasi jangka panjang. Pada saat sistem tersebut telah mencapai atau
melebihi batas umur yang diharapkan, maka kita perlu untuk mendefinisikan
persyaratan-persyaratan yang baru untuk disesuaikan dengan sistem yang baru
pula. Ini berarti melakukan perubahan pada bagian-bagian tertentu dari sistem.
Jika anda tidak memiliki hak akses terhadap kode sumber, boleh jadi anda
lebih suka untuk menghindari komponen-komponen off-the-shelf dan sistem-
sistem dari supplier eksternal; supplier bisa jadi tidak dapat melanjutkan
dukungan untuk perangkat lunak yang dimanfaatkan kembali.

[Type here]
 3. Latar belakang, keahlian, dan pengalaman tim pengembang perangkat lunak.
Semua teknologi reuse bersifat kompleks, para insinyur perangkat lunak akan
menghabiskan banyak waktu untuk memahami dan menggunakan reuse
teknologi ini secara efektif. Oleh karena itu, jika tim yang mengembangkan
perangkat lunak memiliki skill dalam area-area khusus, mungkin ini adalah
tempat dimana para developer harus memusatkan perhatiannya.

4. Perangkat Lunak Critical dan Persyaratan Non-Fungsionalnya. Sistem-

sistem yang critical perlu untuk disertifikasi oleh suatu badan regulator
eksternal; anda dapat membuat dependability case untuk sistem ini (Penulis
telah membahas materi ini pada bab 15). Hal ini akan menjadi sulit jika anda
tidak memiliki akses terhadap kode sumber perangkat lunak. Jika perangkat
lunak anda memiliki persyaratan unjuk kerja yang keras, mustahil untuk
menggunakan strategi-strategi seperti reuse berbasiskan pembangkit, dimana
seorang insinyur perangkat lunak membangkitkan suatu kode dari daerah asal
tertentu dari suatu sistem. Sistem-sistem ini sering kali membangkitkan kode
yang relatif tidak efiesien.

5. Daerah Asal (domain) Aplikasi. Dalam beberapa daerah asal (domain)

aplikasi, seperti sistem manufakturing dan sistem informasi medis, ada
beberapa produk-produk umum yang dapat dimanfaatkan kembali dengan
melakukan konfigurasi terhadap situasi lokal. Jika anda sedang bekerja dalam
suatu domain, anda harus selalu mempertimbangkan ini sebagai suatu pilihan.

[Type here]
 Pendekatan Penjelasan

Pola-Pola Arsitektural Arsitektur-arsitektur perangkat lunak standar yang

mendukung tipe-tipe umum dari sistem-sistem aplikasi
digunakan sebagai dasar aplikasi-aplikasi. Penjelasan
mengenai hal ini diberikan dalam bab 6,13,dan bab
20.
Pola-Pola Desain Abstraksi umum yang terjadi melintasi aplikasi
direpresentasikan sebagai pola-pola desain yang
menunjukkan objek-objek nyata maupun abstrak
beserta interaksinya. Dijelaskan dalam bab 7.
Pengembangan Sistem-sistem dikembangkan dengan
berdasarkan komponen mengintegrasikan komponen-komponen (kumpulan
objek-objek) yang sesuai dengan standar model-
komponen. Dijelaskan dalam bab 17.
Kerangka Kerja Aplikasi Kumpulan kelas-kelas yang abstrak dan kongkrit yang
diadopsi dan diperluas untuk menciptakan sistem-
sistem aplikasi.
Legacy-System Wraping Sistem-sistem legacy (Bab 9) di ”lestarikan” dalam
pengertian suatu himpunan dari sekumpulan
antarmuka dan penyediaan akses kepada sistem-
sistem legacy yang merupakan warisan masa lalu
melalui mekanisme antarmuka ini.
Sistem-Sistem Yang Sistem-sistem dikembangkan dengan
Berorientasi Pada menghubungkan layanan yang dapat dibagikan
Layanan (Service (shared service), yang dapat digunakan secara
Oriented Systems) eksternal.
Armada Produk Jenis aplikasi yang arsitektur umumnya digeneralisasi
Perangkat Lunak sedemikian sehingga dapat disesuaikan untuk
dipergunakan oleh pelanggan yang berbeda.
Reuse COTS Sistem yang dikembangkan dengan mengatur dan
menyatukan sistem-sistem aplikasi yang telah ada.
Sistem-sistem ERP Sistem-sistem skala besar yang memiliki mekanisme
enkapsulasi pada fungsionalitas bisnis secara umum

[Type here]
 serta aturan/mekanisme yang dikonfigurasi untuk
suatu organisasi.
Aplikasi vertikal yang Sistem-sistem generik yang didesain sedemikian
dapat dikonfigurasi sehingga dapat diatur sesuai kebutuhan dari
pelanggan sistem tertentu/spesifik.

Gambar 16.4

Pendekatan-pendekatan yang mendukung reuse dalam bidang ilmu Rekayasa

Perangkat Lunak.

6. Platform dimana sistem akan dijalankan. Beberapa model-model komponen

seperti .NET, bersifat spesifik terhadap platform Microsoft. Demikian juga
halnya sistem-sistem aplikasi generik bisa saja bersifat platform-specified.
Hal ini berarti pengguna hanya dapat menggunakan kembali aplikasi tersebut
jika sistem mereka memiliki platform yang sama.

Penggunaan kembali perangkat lunak berbasis-generator meliputi penyertaan konsep-konsp reusable dan pengetahuan mengenai
peralatan automasi dan penyediaan cara yang mudah bagi pengguna peralatan untuk menyatukan kode yang spesifik dengan
pengetahuan umum menyangkut hal ini. Pendekatan ini biasanya paling efektif dalam aplikasi-aplikasi domain-spesifik.
Mengetahui solusi-solusi yang layak dari permasalahan dalam domain ini tertanam (embedded) dalam sistem generator dan dipilih
oleh user untuk menciptakan suatu sistem yang baru

http://www/softwareengineering-9.com/web/reuse/generator.html

Jangkauan ketersediaan teknik-teknik reuse seperti disebutkan di atas,

memiliki kemungkinan untuk digunakan kembali mekanisme reuse. Apakah reuse
itu berhasi atau tidak lebih menyangkut aspek manajerial dari pada isu-isu teknikal.
Para manager mungkin enggan untuk berkompromi mengena persyaratan-
persyaratan yang mereka buat untuk mengijinkan komponen-komponen reusable
[Type here]
 dapat digunakan. Mereka mungkin tidak memahami resiko-resiko yang timbul
sehubungan dengan reuse sebagaimana mereka memahami resiko dari
pengembangan asli. Meskipun resiko-resiko dari pengembangan perangkat lunak
yang baru meningkat, beberapa manager memilih untuk mengenali resiko-resiko
yang tidak diketahui.

16.2 KERANGKA KERJA APLIKASI

Ketertarikan awal terhadap pengembangan perangkat lunak berorientasi objek
menunjukkan bahwa salah satu manfaat utama dari penggunaan pendekatan
berorientasi objek adalah bahwa objek-objek dapat di pergunakan kembali dalam
sistem-sistem yang berbeda. Bagaimana pun jug, pengalaman telah menunjukkan
bahwa objek-objek tersebut sering kali terlalu kecil dan hanya dikhusukan untuk
aplikasi tertentu saja. Pengembangan perangkat lunak berorientasi objek
memerlukan waktu yang lebih lama untuk memahami dan menyesuaikan suatu
objek jika dibandingkan dengan alokasi waktu yang diperlukan untuk melakukan
re-implementasi. Sekarang telah jelas bahwa penggunaan-kembali berorientasi-
objek akan memberikan hasil terbaik jika dilakukan dalam suatu proses
pengembangan yang berorientasi objek, yaitu melalui abstraksi butiran-yang lebih
besar yang disebut kerangka kerja (framework).

Sebagaimana namanya, suatu framework merupakan struktur umum yang

diperluas untuk menciptakan sub sistem atau aplikasi yang lebih spesifik.
Framework didefinisikan sebagai:

“… suatu himpunan yang terintegrasi dari artefak perangkat lunak (seperti kelas-
kelas, objek-objek dan komponen-komponen) yang bekerja sama untuk
menyediakan arsitektur yang dapat dipergunakan kembali untuk suatu keluarga
aplikasi-aplikasi yang berhubungan (Schmidt, 2004)”.

[Type here]
 Kerangka kerja – kerangka kerja atau frameworks menyediakan fitur-fitur
umum yang kemungkinan akan digunakan dalam aplikasi-aplikasi yang memiliki
tipe yang sama. Sebagai contoh, suatu framework user-interface akan menyediakan
dukungan untuk penanganan event atau kejadian dan akan mengikutsertakan suatu
himpunan widgets untuk membangun tampilan. Developer berhak untuk membuat
spesialisasi dengan menambahkan fungsionalitas yang spesifik untuk suatu aplikasi
khusus. Sebagai contoh, dalam suatu kerangka kerja antar-muka pengguna,
developer mendefinisikan bahwa tata letak tampilan yang sesuai untuk aplikasi
yang sedang diimplementasikan.

Framework mendukung penggunaan kembali suatu desain (design reuse)

dalam arti framework menyediakan suatu kerangka arsitektural untuk aplikasi-
aplikasi serta penggunaan kembali kelas-kelas spesifik dalam suatu sistem
perangkat lunak. Arsitektur didefinisikan oleh kelas-kelas objek. Kelas-kelas
dimanfaatkan kembali secara langsung dan dapat diperluas dengan menggunakan
pewarisan sifat (inheritance).

[Type here]
 Masukan Pengguna
Keadaan Controller Tampilkan Keadaan

Metode Controller Tampilkan Metode

Tampilkan pesan untuk Modifikasi
Ubah
melakukan
Model permintaaan
dan
perbaharui
model.
Keadaan Model

Metode Model

Gambar 16.5
Pola Tampilan-Model-Controller (Model-View-Controller Pattern)

Frameworks diimplementasikan sebagai suatu kumpulan dari kelas-kelas

objek yang bersifat nyata maupun abstrak dalam suatu bahasa pemrograman yang
berorientasi obyek. Oleh sebab itu, frameworks itu bersifat laguage-specific. Ada
sejumlah kerangka kerja atau frameworks yang tersedia dalam semua bahasa
pemrograman berorientasi obyek (seperti Java, C#, C++, termasuk bahasa-bahasa
dinamis seperti Ruby dan Python). Pada kenyataannya, suatu kerangka kerja dapat
menyertakan beberapa kerangka kerja lainnya, dimana setiap kerangka kerja itu
ditujukan untup mendukung pengembangan dari bagian aplikasi. Anda dapat
menggunakan kerangka kerja atau framework untuk membuat suatu aplikasi yang
lengkap atau untuk mengimplementasikan bagian tertentu dari suatu aplikasi;
seperti Antar Muka Pengguna Secara Grafis / Graphical User Interface (GUI).

Ada 3 kelas frameworks (Fayad dan Schmidt, 1997) yaitu:

1. Framework infrastruktur sistem (system-infrastructure frameworks).

Frameworks atau kerangka kerja ini mendukung pengembangan dari
infrastruktur sistem sepeti komunikasi, antarmuka pengguna dan kompiler.
[Type here]
 2. Framework integrasi middleware. (middleware integration frameworks).
Framework ini terdiri dari himpunan standar-standar dan kelas-kelas objek
yang berhubungan, yang mendukung atau memampukan terjadinya
komunikasi dan pertukaran informasi komponen. Contoh dari kerangka kerja
atau framework jenis ini adalah Microsoft .NET dan Enterprise Java Bean
(EJB). Frameworks jenis ini menyediakan dukungan unduk standardisasi
model-model komponen. (pembahasan yang lebih rinci pembaca dapat
menemukannya dalam bab 17.)
3. Framework aplikasi enterprise (enterprise application frameworks).
Framework ini berhubungan dengan domain aplikasi spesifik seperti sistem-
sistem finansial atau telekomunikasi. (Baumer dkk, 1997). Framework ini
“menanamkan” domain aplikasi pengetahuan dan mendukung pengembangan
aplikasi-aplikasi end-user.

Kerangka kerja aplikasi web (Web Application Frameworks,WAFs) adalah

jenis kerangka kerja terkini dan sangat penting. WAFs yang mendukung konstruksi
dari website-website dinamis saat ini telah tersedia secara luas. Arsitektur WAF
biasanya berdasarkan pada pola gabungan Model View Controller (MVC) (Gamma
dkk, 1995), seperti ditunjukkan dalam gambar 16.5.
Pola MVC pada awalnya diajukan sekitar tahun 1980-an sebagai suatu
pendekatan dalam membuat desain antarmuka pengguna secara grafis / graphical
user interface,GUI; yang memungkinkan penyajian suatu objek secara jamak dan
memisahkan cara interaksi dalam setiap setiap penyajiannya. MVC
memungkinkan untuk melakukan pemisahan keadaan aplikasi dari suatu antar-
muka pengguna terhadap aplikasi. Suatu framework MVC mendukung penyajian
data secara berbeda, dan menunjukkan jenis interaksi antara data dalam tiap
penyajiannya. Ketika data dimodifikasi melalui suatu penyajian, model sistem
diubah dan controllers yang berhubungan akan menampilan pembaharuan
penyajiannya.

[Type here]
 Kerangka kerja-kerangka kerja atau framework kerap kali merupakan
implemetasi dari pola-pola desain, sebagaiman didiskusikan dalam bab 7. Sebagai
contoh, suatu framework atau kerangka kerja MVC memasukkan suatu pola
pengamat, pola strategi, pola gabungan, dan sejumlah pola lainnya sebagaimana
telah dikemukakan oleh Gamma dkk (1995). Sifat-sifat umum dari pola-pola dan
penggunaan kelas-kelas yang bersifat abstrak dan kongkrit mengijinkan untuk
melakukan ekstensibilitas. Tanpa pola-pola, framework akan, setidaknya tentulah
menjadi tidak praktis.
Framework aplikasi web biasanya menyertakan satu atau lebih framework
yang lebih khusus yang mendukung kelengkapan aplikasi yang spesifik. Meskipun
tiap framework menyertakan fungsionalitas yang sedikit berbeda, kebanyakan
framework aplikasi web mendukung fitur-fitur sepert berikut ini:
1. Keamanan WAFs (Security WAFs). Framework aplikasi-web ini memasukkan
kelas-kelas yang berguna untuk membantu otentikasi pengguna dan kendali
akses untuk meyakinkan bahwa hanya pengguna yang sah saja yang dapat
mengakses fungsinonalitas yang diijinkan dalam suatu sistem.
2. Halaman-halaman web dinamis (dynamic web-pages). Kelas-kelas disediakan
untuk membantu pengguna mendefinisikan template-template halaman web
dan untuk mempopulasikannya secara dinamis dengan data yang spesifik dari
basis-data yang ada dalam suatu sistem.
3. Dukungan basis data (database support). Kerangka kerja-kerangka kerja atau
framework ini biasanya tidak menyertakan suatu basis data terpadu, melainkan
basis data yang terpisah, seperti MySQL akan dapat digunakan. Suatu
framework ini dapat menyediakan kelas-kelas yang menyediakan antarmuka
secara abstrak kepada database-database lainnya.
4. Pengaturan sesi (session management). Kelas-kelas untuk membuat dan
mengatur sesi-sesi (sesi dapat diartikan sebagai jumlah interaksi dengan sistem
yang dilakukan oleh seorang pengguna),biasanya merupakan bagian dari suatu
WAF.

[Type here]
 5. Interaksi pengguna (user interaction). Sebagian besar framework web saat ini
telah menyediakan dukungan AJAX; (Holdener, 2008) suatu teknologi yang
memungkinkan pembuatan halaman web yang lebih interaktif.

Untuk memperluas suatu kerangka kerja, anda tidak perlu mengubah kode
framework. Sebagai pengguna, anda hanya perlu menambahkan kelas-kelas yang
mewariskan operasi-operasi dari kelas-kelas abstrak dalam suatu framework.
Sebagai tambahan, pengguna perlu untuk mendefinisikan callbacks. Callbacks
adalah metode-metode yang dipanggil sebagai tanggapan terhadap kejadian atau
events yang dikenali oleh suatu framework. Schmitd dkk menyebutnya dengan
istilah inversion of control. Objek-objek framework, merupakan objek-objek aplikasi
yang spesifik, dan bertanggungjawab untuk mengendalikan sistem. Sebagai respon
terhadap events dari pengguna antarmuka, basis data, dsb maka frameworks ini akan
melakukan metode hook yang menghubungkan kepada fungsionalitas yang
disediakan oleh pengguna. Fungsionalitas aplikasi yang spesifik menanggapi event
tersebut dengan cara yang bersesuaian (gambar 16.6). Sebagai contoh, suatu
framework akan memiliki suatu metode yang menangani suatu mouse click dari
lingkungan. Metode ini memanggil metode hook, yang harus dikonfigurasikan oleh
pengguna untuk memanggil metode aplikasi yang sesuai untuk menangani mouse
click.
Aplikasi-aplikasi yang dibangun menggunakan frameworks atau kerangka-
kerja-kerangka kerja ini dapat menjadi dasar untuk penggunaan kembali selanjutnya
melalui suatu konsep product lines atau keluarga aplikasi. Karena aplikasi-aplikasi
ini dibangun menggunakan suatu framework, maka modifikasi terhadap anggota-
anggota keluarga untuk membuat contoh-contoh atau instance dari suatu sistem
seringkali merupakan proses yang berlangsung terus menerus. Ini melibatkan
aktivitas menuliskan kembali kelas-kelas yang kongkrit dan metode-metode yang
sudah pernah ditambahkan pada suatu kerangka kerja atau framework.

[Type here]
 Gambar 16.6
Pembalikan Kendali (Inversion of Control) dalam Kerangka Kerja atau Frameworks

Bagaimanapun juga, framework biasanya lebih umum dari software product

lines yang hanya berfokus pada golongan keluarga spesifik dari sistem aplikasi.
Sebagai contoh, pembaca dapat menggunakan suatu kerangka kerja atau framework
berbasis-web untuk membangun jenis-jenis yang berbeda dari aplikasi-aplikasi web.
Salah satu dari ini bisa saja berupa produk-line perangkat lunak yang mendukung
help-desk berbasiskan web. Produk-line helpdesk ini kemudian dapat di
spesialisasikan untuk menyediakan jenis khusus dari dukungan helpdesk.
Frameworks merupakan pendekatan yang efektif terhadap reuse, tetapi
memerlukan biaya yang tinggi untuk memperkenalkannya ke dalam proses
development. Ini merupakan hal yang rumit dan memerlukan waktu beberapa bulan
untuk belajar menggunakannya. Proses evaluasi framework yang tersedia untuk
memilih framework yang paling sesuai memerlukan biaya tinggi dan sangat rumit.
Debugging aplikasi-aplikasi berbasis framework juga merupakan hal yang sulit
karena anda tidak memahami bagaimana interaksi metode-metode framework. Ini
merupakan suatu permasalahan umum dengan pemanfaatan kembali perangkat

[Type here]
 lunak. Peralatan-peralatan untuk melakukan debugging bisa jadi menyediakan
informasi tentang komponen-komponen sistem yang dipergunakan kembali, yang
tidak dipahami oleh seorang developer.

16.3 VARIAN KELUARGA PRODUK PERANGKAT LUNAK (SOFTWARE

PRODUCT LINE)

Salah satu pendekatan yang paling efektif terhadap pemanfaatan kembali

dalam bidang ilmu rekayasa perangkat lunak adalah dengan menciptakan software
product line atau armada-produk perangkat-lunak atau varian keluarga
aplikasi. Suatu armada produk perangkat lunak atau software product line adalah
kumpulan aplikasi-aplikasi yang memiliki kesamaan arsitektural dan memiliki
komponen-komponen yang digunakan bersama (shared components), dimana
setiap aplikasi dikhususkan untuk mencerminkan persyaratan-persyaratan yang
berbeda. Sistem inti atau core system didesain untuk dapat dikonfigurasikan dan
disesuaikan dengan kebutuhan-kebutuhan dari pelanggan-pelanggan sistem.
Aktivitas ini dapat melibatkan konfigurasi dari beberapa komponen, implementasi
komponen-komponen tambahan, dan modifikasi beberapa komponen untuk
mencerminkan persyaratan-persyaratan baru.

Pengembangan aplikasi-aplikasi dengan melakukan penyesuaian versi

umum dari aplikasi berarti bahwa suatu ada bagian besar dari kode aplikasi yang
dimanfaatkan kembali. Selanjutnya, pengalaman aplikasi seringkali dapat
ditransfer dari suatu sistem ke sistem lainnya. Sebagai akibatnya, saat para
insinyur perangkat lunak bergabung dengan suatu tim pengembang perangkat
lunak, proses pembelajaran mereka menjadi lebih cepat. Pengujian
disederhanakan karena menguji bagian yang besar dari suatu aplikasi bisa juga
dipergunakan kembali (reused), dengan demikian akan mengurangi waktu
pengembangan aplikasi secara keseluruhan (overall application development
time).
[Type here]
 Software product-line atau armada-produk perangkat-lunak biasanya
muncul dari aplikasi-aplikasi yang telah ada. Oleh sebab itu, suatu organisasi
pengembang akan mengembangkan aplikasi terlebih dahulu, kemudian ketika
sistem yang sama diperlukan, maka pengembang secara informal akan
menggunakan kembali kode dari aplikasi yang sudah ada dan menyatukannya ke
dalam aplikasi baru yang sedang dikembangkan. Proses yang sama juga
digunakan dalam mengembangkan aplikasi serupa lainnya. Bagaimanapun juga,
perubahan cenderung untuk merusak struktur aplikasi, sehingga semakin banyak
contoh-contoh baru (new instances) dikembangkan, maka akan semakin
bertambah kesulitan untuk membuat suatu versi yang lebih baru. Sebagai
akibatnya, suatu keputusan untuk membuat desain varian produk yang bersifat
umum harus dilakukan. Ini berhubungan dengan identifikasi kesamaan
fungsionalitas dalam contoh produk dan menyertakannya dalam aplikasi dasar,
yang kemudian digunakan untuk pengembangan di masa depan. Aplikasi dasar
ini dire-strukturisasi dengan hati-hati untuk menyederhanakan reuse dan re-
konfigurasi.

Kerangka kerja-kerangka kerja aplikasi dan armada produk perangkat lunak

ini jelas memiliki banyak kesamaan. Kedunya mendukung arsitektur dan
komponen-komponen umum dan memerlukan pengembangan baru untuk
menciptakan versi spesifik dari suatu sistem. Perbedaan utama antara framework
aplikasi dan armada produk perangkat lunak adalah sebagai berikut:

1. Framework aplikasi mengandalkan pada fitur object-oriented seperti

pewarisan sifat (inheritance), dan polimorfisme untuk mewujudkan perluasan
kerangka kerja. Secara umum, kode framework tidak dimodifikasi dan
modifikasi yang mungkin terbatas pada apapun yang diijinkan oleh suatu
kerangka kerja. Armada produk perangkat lunak tidak perlu dibuat
menggunakan pendekatan berorientasi objek. Komponen-komponen aplikasi

[Type here]
 diubah, dihapus, atau ditulis kembali. Tidak ada batasan, setidaknya secara
prinsipil, terhadap perubahan yang dapat dilakukan.
2. Framework-framework aplikasi terutama difokuskan pada penyediaan
teknikal dan bukan pada dukungan domain-spesifik. Sebagai contoh ada
framework-framework aplikasi yang digunakan untuk membuat aplikasi
berbasis web. Suatu software product line biasanya menanamkan informasi
platfor dan domain secara detail. Sebagai contoh, bisa jadi ada software
product line yang berhubungan dengan aplikasi berbasis web untuk
manajemen rekaman kesehatan.
3. Software product line atau armada produk perangkat lunak seringkali
mengendalikan aplikasi-aplikasi untuk peralatan. Sebagai contoh, ada armada
produk perangkat lunak untuk suatu keluarga peralatan pencetak atau printer
(misalnya keluarga printer cannon bubble jet, keluarga seri pixma,keluarga
printer multi purpose Cannon seri MP, HP deskjet, HP Laserjet,dsb). ini
berarti suatu armada produk telah menyediakan dukungan untuk antarmuka
perangkat keras. Framework aplikasi biasanya berorientasi pada perangkat
lunak dan jarang sekali menyediakan dukungan untuk antarmuka perangkat
keras.
4. Varian produk perangkat lunak atau software product line terdiri dari suatu
keluarga aplikasi yang saling berhubungan, dan biasanya dimiliki oleh
organisasi atau perusahaan yang sama. Ketika anda membuat aplikasi yang
baru, titik awal anda seringkali anggota terdekat dari keluarga aplikasi, dan
bukan aplikasi inti yang umum.

Jika pembaca sedang mengembangkan armada produk dengan

menggunakan bahasa pemrograman berorientasi objek, anda dapat menggunakan
framework aplikasi sebagai dasar untuk sistem yang akan dibangun. Anda
membuat inti dari armada produk dengan memperluas framework dengan
komponen-komponen domain spesifik menggunakan mekanisme built-in yang
telah tersedia. Dengan demikian ada fasa kedua dari pengembangan perangkat
[Type here]
 lunak, dimana versi-versi dari sistem untuk pelanggan-pelanggan yang berbeda
dibuat atau diciptakan.

Ada berbagai jenis spesialisasi dari armada produk perangkat lunak

(software product line) yang dapat dikembangkan:

1. Spesialisasi platform (Platform specialization). Versi-versi dari aplikasi

dikembangkan untuk platform yang berbeda-beda. Sebagai contoh, versi-versi
dari aplikasi ada yang dibuat untuk Windows, sistem operasi Mac, dan Linux.
Dalam kasus ini, fungsionalitas dari aplikasi pada dasarnya tidak berubah,
hanya komponen-komponen yang merupakan antarmuka dengan perangkat
keras dan sistem operasi yang dimodifikasi.
2. Spesialisasi lingkungan (environment specialization). Versi dari aplikasi-
aplikasi dibuat untuk menangani lingkungan operasi dan bermacam perangkat
yang bersifat khusus. Sebagai contoh, suatu sistem untuk layanan keadaan
darurat dapat tersedia dalam versi yang berbeda, bergantung pada sistem
komunikasi wahana. Dalam hal ini, komponen-komponen sistem diubah
untuk mencerminkan fungsionalitas dari peralatan komunikasi yang
digunakan.
3. Spesialisasi fungsional. Versi-versi dari aplikasi diciptakan untuk customer
spesifik yang memiliki persyaratan yang berbeda-beda pula. Sebagai contoh,
suatu sistem otomasi pustaka dapat dimodifikasi bergantung pada apakah
pustaka sistem otomasi tersebut digunakan dalam pustaka umum. Suatu
pustaka referensi, atau pustaka universitas. Dalam kasus ini, komponen-
komponen yang melaksanakan fungsionalitas dapat dimodifikasi, sehingga
ada komponen-komponen baru yang ditambahkan ke dalam sistem.
4. Spesialisasi proses. Sistem disesuaikan untuk mengatasi kesulitan yang
berhubungan dengan proses bisnis yang spesifik. Sebagai contoh, suatu sistem
pemesanan dapat disesuaikan untuk mengatasi masalah proses-pemesanan

[Type here]
 yang-terpusat, namun juga memiliki proses yang terdistribusi di dalam suatu
perusahaan tertentu.

Arsitektur dari suatu armada produk perangkat lunak seringkali

merefleksikan suatu gaya arsitektural atau pola spesifik dari suatu aplikasi secara
umum. Sebagai contoh, coba pembaca pikirkan suatu sistem armada produk yang
didesain untuk menangani pengiriman cepat untuk layanan darurat. Operator dari
sistem ini menerima panggilan-panggilan telepon yang berisi laporan kejadian,
mereka harus menemukan jenis kendaraan yang sesuai sebagai tanggapan
terhadap insiden tersebut, dan mengirimkan suatu wahana atau kendaraan ke
tempak terjadinya insiden. Perusahaan pengembang perangkat lunak yang
mengembangkan suatu sistem boleh memasarkan versi-versi dari ini untuk pihak
aparat kepolisian, pemadam kebakaran,layanan ambulans.

Sistem pengiriman kendaraan merupakan suatu contoh dari arsitektur

manajemen sumber-daya (gambar 16.7). Pembaca dapat melihat bagaimana
arsitektur armada produk perangkat lunak untuk pengiriman kendaraan yang
terdiri dari susunan empat-lapis sebagaimana ditunjukkan dalam gambar 16.8,
yang menunjukkan modul-modul yang mungkin disertakan dalam suatu armada
produk perangkat lunak untuk pengiriman kendaraan. Komponen-komponen
pada tiap tingkatan dalam sistem armada produk adalah sebagai berikut:

1. Pada tingkat interaksi (interface level), ada komponen-komponen yang

menyediakan operator untuk antar-muka tampilan, dan suatu antar-muka
dengan sistem komunikasi yang digunakan.
2. Pada tingkatan manajemen I/O (level 2), ada komponen-komponen yang
menangani otentikasi operator, membangkitkan laporan dari suatu kejadian
dan kendaraan yang akan dikirimkan, membantu membuat peta keluaran dan
perencanaan rute, serta menyediakan suatu mekanisme untuk operator
melakukan permintaan atau query basis data yang terdapat dalam sistem.

[Type here]
 Gambar 16.7

Arsitektur Sistem Alokasi Sumber-Daya

Gambar 16.8
Arsitektur Product-Line dari Sistem Pengiriman Kendaraan

[Type here]
 3. Pada tingkatan manajemen sumber-daya (resource management level; level
3); terdapat komponen-komponen yang mengijinkan kendaraan-kendaraan
untuk ditempatkan dan dikirimkan, komponen-komponen untuk
memperbaharui status kendaraan dan peralatan, dan suatu komponen untuk
mencatat rincian tiap kejadian.
4. Pada tingkatan basis-data, sebagaimana biasanya dukungan manajemen
transaksi, ada pemisahan database untuk kendaraan, peralatan, dan peta.

Untuk menciptakan versi spesifik dari sistem ini, insinyur perangkat lunak
yang mengembangkan sistem ini harus memodifikasi komponen-komponen
secara individu. Sebagai contoh, seorang polisi memiliki sejumlah besar
kendaraan namun memiliki sejumlah kecil jenis kendaraan, sedangkan layanan
pemadam kebakaran memiliki beragam jenis kendaraan yang memiliki kegunaan
khusus. Oleh sebab itu, pengembang perangkat lunak harus dapat mendefinisikan
atau membuat struktur basis-data kendaraan yang berbeda saat melakukan
implementasi sistem untuk layanan-layanan yang berbeda ini.

Memilih contoh
sistem yang
paling sesuai

Memilih
Menggali contoh sistem
Persyaratan yang paling
Stakeholder sesuai

Memilih contoh Mengirimkan

sistem yang contohSistem
paling sesuai Yang Barui

Gambar 16.9
Contoh Pengembangan Produk

[Type here]
 Gambar 16.9 menunjukkan langkah-langkah dalam memperluas suatu
software product line atau armada produk perangkat lunak untuk membuat suatu
aplikasi baru. Langkah-langkah umum untuk memperluas software-product-line
adalah sebagai berikut:

1. Menggali persyaratan stakeholder. Pembaca dapat mulai dengan proses

rekayasa persyaratan. Bagaimana pun juga,karena sistem ini telah ada
sebelumnya maka pengembang perangkat lunak perlu mendemonstrasikan
sistem dan mengetahui percobaan yang telah dilakukan stakeholder terhadap
sistem yang telah ada, menjelaskan persyaratan stakeholder sebagai
modifikasi kepada fungsi-fungsi yang tersedia.
2. Memilih sistem yang telah ada yang paling memenuhi persyaratan. Ketika
menciptakan anggota baru dari product line, tim pengembang boleh mulai
dengan contoh produk yang paling mirip. Persyaratan-persyaratan dianalisis
dan anggota-keluarga yang paling memenuhi dipilih untuk modifikasi.
3. Renegosiasi. Semakin terperinci perubahan penting yang diinginkan dan
perencanaan proyek yang dilakukan, menyebabkan beberapa persyaratan
yang sudah didefinisikan perlu di negosiasikan kembali untuk meminimalkan
perubahan yang diinginkan.
4. Penyesuaian sistem yang telah ada. Modul-modul baru dikembangkan untuk
sistem yang telah ada dan modul-modul sistem yang telah ada disesuaikan
agar memenuhi persyaratan yang baru didefinisikan kembali.
5. Mengirimkan anggota keluarga baru. Contoh yang baru dari armada produk
diantarkan kepada pelanggan. Pad tahap ini, tim pengembang membuat
dokumentasi fitur-fitur kunci sedemikian sehingga dapat digunakan sebagai
dasar untuk pengembangan sistem lain di masa depan.

Saat tim pengembang menciptakan anggota baru dari product line, mereka
perlu melakukan kompromisasi antar penggunaan kembali sebanyak mungkin

[Type here]
 aplikasi umum dan memuaskan persyaratan stakeholder secara rinci. Semakin rinci
persyaratan sistem, maka semakin kecil kemungkinan bahwa komponen-komponen
yang telah ada akan memenuhi persyaratan ini. Meskipun demikian, jika
stakeholder berkeinginan untuk lebih fleksibel dan untuk membatasi modifikasi
sistem yang disyaratkan, mereka biasanya mengantarkan sistem dalam waktu yang
lebih singkat dengan biaya yang rendah.

Gambar 16.10
Konfigurasi Deployment-Time

Software product lines di desain untuk dapat direkonfigurasi, dan

rekonfigurasi ini dapat melibatkan penambahan atau penghapusan komponen-
komponen dari sistem, pendefinisikan parameter dan kendala-kendala untuk
komponen-komponen sistem, dan memasukkan pengetahuan tentang bisnis proses.
Konfigurasi ini dapat terjadi pada tahapan yang berbeda dalam proses
pengembangan:

1. Konfigurasi waktu-desain. Suatu organisasi atau perusahaan yang

mengembangkan perangkat lunak memodifikasi inti product line dengan
pengembangan, pemilihan, atau penyesuaian komponen-komponen untuk
menciptakan sistem yang baru bagi pelanggan.
[Type here]
 2. Konfigurasi waktu-penyebaran. Suatu sistem umum ditujukan untuk
konfigurasi oleh pelanggan atau konsultan bekerja sama dengan pelanggan.
Pengetahuan tentang persyaratan spesifik pelanggan dan lingkungan
pengoperasian sistem ditanamkan dalam suatu kumpulan file konfigurasi yang
digunakan oleh sistem secara umum.

Ketika suatu sistem dikonfigurasi pada saat melakukan desain, supplier mulai
dengan sistem umum atau menggunakan contoh produk yang telah ada . Mereka
membuat suatu sistem spesifik yang melakukan fungsionalitas yang diinginkan
oleh pelanggan. Ini melibatkan perubahan dan perluasan suatu kode sumber dari
sistem, sehinggan fleksibilitas yang lebih luas menjadi mungkin jika dibandingkan
dengan konfigurasi waktu-penyebaran.

Konfigurasi waktu-penyebaran melibatkan penggunaan suatu peralatan

konfigurasi untuk membuat suatu konfigurasi sistem yang spesifik yang direkam
dalam sebuah basis-data konfigurasi atau suatu kumpulan file-file konfigurasi
(gambar 16.10). Eksekusi sistem akan melakukan konfirmasi kepada basis-data
ketika eksekusi dilakukan, sehingga fungsionalitas dapat dikhusukan kepada
konteks eksekusinya.

Ada beberapa tingkatan konfigurasi deployment-time yang disediakan dalam

sistem:

1. Pemilihan komponen, dimana pengembang perangkat lunak memilih modul-

modul dalam suatu sistem yang menyediakan fungsionalitas yang disyaratkan.
Sebagai contoh, dalam sistem informasi pasien, developer dapat memilih suatu
komponen manajemen citra yang mengijinkan untuk menghubungkan citra-citra
(sinar X, CT scan, dsb) medis kepada rekaman medis pasien.
2. Pendefinisian aturan dan workflow, saat developer mendefinisikan workflow
(aliran pemrosesan informasi, tahap demi tahap) dan melakukan validasi aturan
yang seharusnya diterapkan kepada informasi yang dimasukkan oleh para
pengguna atau yang dibangkitkan oleh sistem/
[Type here]
 3. Pendefinisian parameter, dimana para developer menentukan nilai-nilai dari
parameter-parameter sistem secara spesifik yang merefleksikan suatu contoh
dari aplikasi yang sedang dikembangkan. Sebagai contoh, misalnya menentukan
panjang maksimum dari field-field untuk data yang dimasukkan oleh pengguna,
atau karakteristik dari perangkat keras yang dihubungkan kepada sistem
tersebut.

Konfigurasi deployment-time bisa menjadi sangat kompleks dan memakan

waktu berbulan-bulan untuk melakukan konfigurasi sistem yang diperuntukkan
bagi pelanggan. Sistem-sistem besar yang dapat dikonfigurasi biasanya
mendukung proses konfigurasi dengan menyediakan peralatan perangkat lunak
seperti peralatan perencanaan konfigurasi (configuration planning tools) untuk
mendukung proses konfigurasi (konfigurasi dibaca:pengaturan). Penulis
membahas tentang konfigurasi waktu-penyebaran lebih mendalam dalam sub-bab
16.4.1. Bahasan ini meliputi penggunaan kembali (reuse) sistem-sistem COTS
yang harus diatur atau dikonfigurasikan agar dapat bekerja dalam lingkunan
operasional yang berbeda.

Pengaturan waktu-desain digunakan pada saat tidak memungkinkan untuk

menggunakan fasilitas konfigurasi waktu-penyebaran (deployment-time
configuration facility) dalam sistem untuk mengembangkan versi sistem yang
lebih baru. Bagaimana pun juga, lembur,ketika tim telah membuat beberapa
anggota-anggota keluarga dengan fungsionalitas yang dapat dibandingkan, maka
pengembang dapat memutuskan untuk melakukan refactor terhadap produk inti
untuk memasukkan fungsionalitas yang telah diimplementasikan dalam beberapa
anggota keluarga aplikasi. Selanjutnya pengembang membuat fungsionalitas baru
yang dapat dikonfigurasi ketika sistem disebarkan.

[Type here]
16.4 PENGGUNAAN KEMBALI PRODUK-PRODUK COTS

Produk COTS (commercial-off-the-shelf) adalah suatu sistem perangkat

lunak komersial dapat disesuaikan dengan kebutuhan pelanggan-pelanggan yang
berbeda tanpa merubah kode sumber dari sistem. Secara virtual, seluruh perangkat
lunak desktop dan produk-produk server dalam ragam yang luas sebenarnya
adalah perangkat lunat COTS. Hal ini dikarenakan perangkat lunak ini ditujukan
untuk digunakan secara umum, dan biasanya menyertakan berbagai fitur atau
kelengkapan dan fungsi-fungsi. Oleh sebab itu, suatu perangkat lunak COTS
memiliki potensi untuk dipergunakan kembali dalam lingkungan-lingkungan
yang berbeda, dan juga sebagai bagian dari aplikasi lainnya. produk-produk open-
source juga seringkali digunakan sebagai produk COTS (Torchiano and Morisio,
2004). Oleh sebab itu sistem-sistem yang dikembangkan secara terbuka (open
source systems) dulunya juga dipergunakan tanpa perubahan dan tanpa
memperhatikan kode sumbernya.

Produk-produk COTS diadaptasi dengan menggunakan mekanisme

konfigurasi built-in yang mengijinkan suatu fungsionalitas dari sistem disatukan
untuk memenuhi kebutuhan pelanggan tertentu. Sebagai contoh, dalam suatu
sistem rekaman-medis pasien, pemisahan bentuk masukan dan laporan keluaran
mungkin didefinisikan untuk tipe-tipe pasien yang berbeda. Fitur konfigurasi
lainnya juga mengijinkan sistem untuk menerima plug-in yang memperluas
fungsionalitas atau memeriksa masukan pengguna untuk menjamin
keabsahannya.

Pendekatan terhadap reuse perangkat lunak seperti ini telah diadopsi secara
luas oleh perusahaan-perusahaan besar selama lebih dari 15 tahun, karena
menawarkan manfaat yang signifikan bagi pengembangan perangkat lunak yang
dapat dikustomisasi sbb:

1. Sebagaimana tipe reuse lainnya, deployment yang cepat dari suatu sistem yang
handal mungkin untuk dilakukan.
[Type here]
 2. mengetahui fungsionalitas apa yang disediakan oleh suatu aplikasi, akan
membuat lebih mudah untuk menentukan apakah reuse itu dapat dilakukan.
3. Bebarapa resiko pengembangan dapat dihindari dengan menggunakan
perangkat lunak yang telah ada. Meskipun demikian, pendekatan ini memiliki
resiko seperti disebutkan di bawah ini.
4. Bisnis dapat memusatkan pada aktivitas inti tanpa memerlukan banyak
sumber daya untuk pengembangan sistem-sistem IT.
5. Sebagaimana suatu platform operasi mengalami perkembangan, pembaharuan
teknologi dapat disederhanakan. Ini merupakan tanggung jawab pihak vendor
produk COTS dan bukan tanggung jawab pelanggan.

Tentu saja, pendekatan dalam rekayasa perangkat lunak ini menimbulkan masalah
tersendiri:

1. Persyaratan-persyaratan biasanya telah disesuaikan sebelumnya untuk

merefleksikan fungsionalitas dan mode operasi dari produk-produk COTS.
Hal ini dapat menimbulkan perubahan yang merusak bisnis proses yang telah
ada.
2. Produk-produk COTS bisa jadi didasarkan pada asumsi-asumsi bahwa
mustahil untuk mengubah secara praktis. Oleh karena itu, seorang pelanggan
perlu menyesuaikan bisnis mereka untuk merefleksikan asumsi-asumsi ini.
3. Pemilihan sistem COTS yang sesuai untuk suatu perusahaan bisa jadi
merupakan proses yang sulit, khususnya ada banyak produk COTS yang tidak
didokumentasikan dengan baik. Penentuan pilihan yang salah dapat
menimbulkan bencana karena tidak mungkin untuk membuat sistem yang
baru dapat beroperasi seperti yang diperlukan.
4. Terdapat banyak ketertinggalan dari ahli lokal untuk mendukung
pengembangan sistem. Sebagai akibatnya, pelanggan hanya mengandalkan
pada vendor dan konsultan eksternal untuk saran pengembangan. Advice ini

[Type here]
 bisa jadi bersifat bias dan diutamakan untuk penjualan produk dan servis dan
bukan untuk memenuhi kebutuhan pelanggan yang sebenarnya.
5. Vendor produk COTS mengendalikan dukungan sistem dan evolusinya.
Mereka mungkin keluar dari bisnis, diambil alih atau membuat perubahan
yang menyebabkan kesulitan-kesulitan bagi pelanggan.

Prinsip penggunaan kembali perangkat lunak COTS ini mengalami

peningkatan secara kuantitatif. Hal ini dapat dibuktikan oleh banyaknya bisnis
sistem-sistem pemrosesan informasi yang baru, dibangun dengan menggunakan
COTS daripada menggunakan pendekatan berorientasi objek. Walaupun kerap
kali muncul permasalahan-permasalahan dengan menggunakan pendekatan ini
dalam pengembangan sistem (Tracz, 2001), ada banyak cerita-cerita sukses
(Baker, 2002; Balk dan Kedia, 2000; Brownsword dan Morris, 2003; Pfarr dan
Reis, 2002; ) yang menunjukkan bahwa perangkat lunak COTS berbasis reuse
mengurangi usaha dan waktu untuk membangun sebuah sistem.

Ada dua jenis penggunaan kembali yang digunakan produk COTS, yaitu
sistem solusi-COTS (COTS-solution system) dan sistem COTS-terintegrasi
(COTS-integrated system). Sistem solusi-COTS terdiri dari suatu aplikasi umum,
mulai dari vendor tunggal yang disusun sesuai persyaratan pelanggan. Sistem
COTS-terintegrasi mengintegrasikan dua atau lebih sistem COTS (yang mungkin
berasal dari vendor-vendor yang berbeda) untuk menciptakan suatu sistem
aplikasi. Gambar 16.11 menyimpulkan perbedaan-perbedaan antara sistem solusi-
COTS dan sistem COTS-terintegrasi.

Sistem solusi-COTS Sistem COTS-terintegrasi

Produk tunggal yang menyediakan Beberapa produk sistem yang heterogen
fungsionalitas yang diperlukan oleh seorang disatukan untuk menyediakan
pelanggan tungsionalitas yang dapat dikustomisasi.

[Type here]
 Berdasarkan pada solusi generik dan proses- Solusi yang fleksibel dapat dikembangkan
proses yang distandarisasi untuk proses-proses pelanggan
Pengembangan berpusat pada konfigurasi Pengembangan berpusat pada integrasi
sistem sistem
Vendor sistem bertanggung jawab untuk Pemilik sistem bertanggungjawab untuk
maintenance maintenance
Vendor sistem menyediakan platform untuk Pemilik sistem menyediakan platform
sistem. untuk sistem.

Gambar 16.11

Perbedaan antara Sistem Solusi-COTS dan Sistem COTS-Terintegrasi.

16.4.1 Sistem Solusi-COTS

Sistem-sistem solusi COTS merupakan sistem-sistem aplikasi umum yang

ditujukan untuk mendukung suatu jenis bisnis yang partikuler, aktivitas bisnis,
atau kadangkala, suatu perusahaan bisnis yang lengkap. Sebagai contoh, suatu
sistem solusi-COTS dapat dibuat untuk para dokter gigi untuk menangani masalah
appointment, rekaman kesehatan gigi, patient-recall, dsb. Pada skala yang lebih
besar, suatu sistem Perencanaan Sumber Daya Perusahaan (Enterprise Resource
Planning,ERP) dapat mendukung seluruh aktivitas-aktivitas manajemen seperti
fabrikasi (manufacturing), pemesanan (ordering), dan hubungan pelanggan
(customer relationship) dalam suatu perusahaan besar.

Sistem-sistem solusi COTS domain-specific (misalnya saja manajemen

dokument), menyediakan fungsionalitas yang kemungkinan akan dibutuhkan oleh
sejumlah besar pengguna-pengguna potensial/ Bagaimana pun juga, mereka juga
menyertakan asumsi-asumsi built-in mengenai bagaimana para pengguna bekerja;
ini akan menyebabkan masalah-masalah dalam situasi-situasi tertentu. Sebagai
contoh, suatu sistem yang dibangun untuk mendukung registrasi mahasiswa di
suatu universitas yang mengasumsikan bahawa para mahasiswa akan didaftarkan
sebagai mahasiswa selama satu tahun akademik di universitas tersebut. Jika

[Type here]
 universitas tersebut menjalin kerjasama dan menawarkan program joint-degrees,
secara praktis akan mustahil untuk merepresentasikan hal tersebut dalam sistem
informasi registrasi mahasiswa yang lama ini.

Sistem-sistem ERP seperti yang diproduksi oleh SAP dan BEA merupakan
sistem-terintegrasi skala-besar yang didesain untuk mendukung praktek-praktek
bisnis seperti pemesanan dan tagihan, manajemen inventaris, dan perencanaan
manufakturing (O’Leary, 2000). Proses konfigurasi sistem-sistem ini
berhubungan dengan pengumpulan informasi yang terperinci mengenai bisnis
pelanggan dan proses bisnisnya, serta menanamkan ini dalam suatu susunan basis-
data (configuration database). Untuk dapat melakukan hal ini, dibutuhkan
pengetahuan yang rinci mengenai notasi-notasi dan peralatan-peralatan; dan
biasanya dilakukan dengan menggunakan jasa konsultan yang bekerja sama
dengan pelanggan sistem tersebut.

Suatu sistem ERP yang umum biasanya memiliki sejumlah modul-modul

yang dapat disusun dalam cara-cara yang berbeda untum menciptakan suatu
sistem seperti yang diinginkan oleh pelanggan. Proses penyusuna konfigurasi ini
meliputi pemilihan modul-modul yang akan dimasukkan, penyusunan modul-
modul secara individu, pendefinisian proses-proses dan aturan-aturan bisnis, serta
pendefinisian struktur dan organisasi database sistem. Suatu model dari
keseluruhan arsitektur dari suatu sistem ERP yang membantu utnuk
melaksanakan sejumlah fungsi-fungsi bisnis ditunjukkan dalam gambar 16.12.

[Type here]
 Gambar 16.12

Arsitektur Sistem ERP

Fitur-fitur kunci dari arsitektur sistem Perencanaan Sumber Daya

Perusahaan (Enterprise Resource Planning,ERP) ini adalah:

1. Sejumlah modul-modul untuk mendukung fungsi-fungsi bisnis yang

berbeda. Ini merupakan modul-modul dengan bulir yang besar yang
mendukung seluruh departemen atau divisi bisnis perusahaan. Dalam
contoh yang ditunjukkan dalam gambar 16.12, suatu modul yang telah
dipilih untuk disertakan dalam sistem adalah sebuah modul untuk
mendukung pengadaan, manajemen rantai pasok, dan modul logistik untuk
mendukung pengiriman barang-barang, dan suatu modul manajemen
hubungan pelanggan untuk menyimpan data pelanggan.
2. Suatu himpunan prose-proses bisnis, yang dihubungkan dengan tiap modul,
yang menghubungkannya dengan aktivitas-aktivitas dalam modul itu.
Sebagai contoh, dalam modul tersebut terdapat suatu definisi dari proses
reservasi yang mendefinisikan bagaimana pesan-pesan atau reservasi
diciptakan dan disetujui. Hal ini akan menentukan peran-peran dan
aktivitas-aktivitas yang terlibat dalam menempatkan suatu pesanan atau
reservasi.

[Type here]
 3. Suatu basis-data umum yang menyimpan informasi mengenai seluruh
fungsi-fungsi bisnis yang berhubungan. Hal ini bertujuan untuk
menghindari adanya informasi tiruan (baca:duplikasi atau replikasi atau
redundancy) seperti rincian pelanggan, dalam bagian-bagian yan berbeda
dari suatu bisnis atau kegiatan usaha.
4. Suatu himpunan aturan-aturan bisnis yang diterapkan kepada seluruh data
yang ada dalam database. Oleh sebab itu, ketika dapat dimasukkan dari
suatu fungsi, aturan-aturan ini seharusnya meyakinkan bahwa data itu
konsisten dengan data yang diperlukan oleh fungsi-fungsi lainnya. Sebagai
contoh, mungkin saja ada aturan bisnis yang menyatakan bahwa klaim biaya
harus disetujui oleh seseorang yang lebih senior dari pada orang yang
mengajukan klaim.

Sistem-sistem perencanaan sumber daya perusahaan (Enterprise Resource

Planning System, ERP systems) dipergunakan oleh hampir seluruh perusahaan-
perusahaan besar untuk mendukung sebagian atau seluruh operasional
perusahaan. Oleh sebab itu dalam sistem ini terdapat banyak sekali bentuk
penggunaan kembali perangkat lunak. Bagaimana pun juga, kelemahan utama
dari pendekatan reuse model seperti ini adalah adanya keterbatasan pada
fungsional sistem yang disediakan hanya terbatas pada fungsionalitas core atau
inti yang bersifat generik atau umum. Selanjutnya, operasional dan proses bisnis
perusahaan harus dijelaskan dalam bentuk bahasa konfiguras sistem. Hal ini
akan menyebabkan timbulnya ketidaksesuaian antara konsep-konsep dalam
bisnis nyata dan konsep-konsep yang didukung oleh bahasa konfigurasi.

Sebagai contoh kasus, dalam suatu sistem ERP yang dulunya dijual kepada
suatu perguruan tinggi, konsep tentang pelanggan harus didefinisikan. Hal ini
akan menimbulkan kesulitan yang hebat ketika melakukan konfigurasi sistem.
Pada kenyataannya, suatu universitas memiliki berbagai macam tipe komponen
yang selanjutnya disebut customer, seperti mahasiswa, donatur yang

[Type here]
 mensponsori penelitian, yayasan pendidikan, dan komponen lainnya yang
masing-masing memiliki karakteristik yang berbeda satu dengan yang lainnya.
Universitas tentu akan sangat berbeda dengan pelanggan komersial (misalnya
orang atau bisnis yang berhubungan dengan pembelian barang dan jasa.)
Ketidaksesuaian antara pemodelan bisnis yang digunakan oleh sistem dan
pembeli yang menggunakan sistem ini membuatnya mungkin saja terjadi sistem
ERP tidak akan dapat memenuhi kebutuhan pembeli yang sebenarnya (Scott,
1999).

Produk-produk COTS dan sistem-sistem ERP biasanya memerlukan

konfigurasi yang luas untuk menyesuaikannya dengan persyaratan-persyaratan
dari tiap organisasi di lingkungan mana sistem itu dipasang. Konfigurasi itu
menyangkut hal-hal berikut ini:

1. Pemilihan fungsionalitas yang diigninkan dari sistem (misalnya saja

dengan memutuskan modul-modul mana saja yang akan disertakan).
2. Membuat suatu model data yang mendefinisikan bagaimana data dari
perusahaan atau organisasi akan distukturisasi dalam database sistem.
3. Membuat definisi aturan-aturan bisnis yang diterapkan pada data
tersebut.
4. Membuat definisi interaksi-interaksi dengan sistem eksternal yang
diharapkan.
5. Membuat desain bentuk masukan dan keluaran laporan yang
dibangkitkan oleh sistem.
6. Membuat desain proses bisnis yang baru yang sesuai dengan model
proses lapis bawah yang didukung oleh sistem.
7. Pengaturan parameter-parameter yang mendefinisikan bagaimana
sistem didistribusikan sehingga dapat bekerja dengan baik pada platfor
yang mendasarinya.

[Type here]
 Saat pengaturan konfigurasi telah diselesaikan,suatu sistem solusi-COTS siap
untuk diuji.Pengujian adalah suatu masalah utama ketika sistem-sistem telah
dikonfigurasi dan tidak diprogram menggunakan suatu bahasa konvensional.
Karena sistem-sistem ini dibangun dengan menggunakan platform yang handal,
sudah jelas bahwa kegagalan sistem dan crash relatif jarang terjadi. Masalah-
masalah yang terjadi hanya masalah kecil yang sering tidak terdeteksi dan
berhubungan dengan interaksi-interaksi antara proses-proses operasional dan
konfigurasi sistem. Masalah-masalah yang tidak terdeteksi ini hanya dapat
dideteksi oleh end-user dan boleh jadi tidak ditemukan selama proses pengujian
sistem. Selanjutnya, otomasi unit-testing, didukung oleh pengujian frameworks
seperti Junit tidak dapat digunakan. Sistem lapis bawah sepertinya tidak
memungkinkan untuk mendukung setiap jenis tes otomasi, dan boleh jadi tidak
ada spesifikasi sistem yang lengkap yang dapat digunakan untuk men-derivasi
pengujian-pengujian sistem.

16.4.2 Sistem COTS-Terintegrasi

Sistem COTS-terintegrasi adalah aplikasi-aplikasi yang meyertakan dua

atau lebih produk COTS, atau kadangkala berupa sistem-sistem aplikasi “masa
lalu”. Saudara dapat menggunakan pendekatan ini ketika tidak ada sistem COTS
tunggal yang dapat memenuhi semua kebutuhan atau ketika pembaca berharap
untuk menggabungkan produk sistem COTS dengan sistem-sistem yang telah
digunakan. Produk COTS dapat berinteraksi melalui antarmuka pemrograman
aplikasi APIs (Application Programming Interface) atau antarmuka layanan jika
didefinisikan. Sebagai alternatif, produk COTS ini dapat disusun dengan
menghubungkan keluaran dari suatu sistem kepada masukan dari sistem lainnya
(cascade system) dengan pembaharuan database yang digunakan oleh aplikasi-
aplikasi COTS.

[Type here]
 Untuk mengembangkan sistem-sistem menggunakan produk-produk
COTS, tim pengembang perangkat lunak harus membuat sejumlah pilihan
desain sebagai berikut:

1. Produk COTS mana yang menawarkan fungsionalitas yang paling sesuai

dengan kebutuhan? Pada umumnya, tersedia beberapa produk COTS, yang
dapat dikombinasikan dalam cara-cara yang berbeda. Jika pembaca belum
memiliki pengalaman dengan produk COTS, akan sulit untuk memutuskan
produk mana yang paling sesuai.
2. Bagaimana mekanisme pertukaran data yang terjadi? Produk-produk yang
berbeda secara normal menggunakan stuktur dan format yang unik. Pembaca
perlu menuliskan adaptor-adaptor (baca : converter) yang melakukan
pengubahan data dari satu bentuk ke bentuk lainnya. Peralatan adaptor ini
merupakan sistem run-time yang beroperasi bersama produk COTS.
3. Fitur apakah yang ada dalam produk COTS, yang benar-benar akan berguna
bagi proses bisnis perusahaan? Produk COTS menyertakan fungsionalitas
yang lebih banyak dari yang dibutuhkan oleh perusahaan. Mungkin saja
produk-produk yang berbeda juga memiliki fungsi yang sama. Pembaca
perlu memutuskan fitur-fitur dalam produk COTS yang mana yang paling
sesuai dengan kebutuhan sesuai dengan persyaratan yang telah dibuat/ Jika
memungkinkan, pembaca seharusnya juga menolak akses kepada
fungsionalitas yan tidak berguna, karena ini akan mengganggu operasi
normal dari sistem. Peristiwa kegagalan penerbangan pertama roket Ariane
5 (Nuseibeh, 1997) di waktu lalu merupakan akibat dari kegagalan dalam
sistem navigasi yang menggunakan kembali sistem Ariane 4.
Bagaimanapun, fungsionalitas yang gagal sebenarnya tidak benar-benar
dibutuhkan dalam sistem navigasi Ariane 5.

Perhatikan skenario berikut sebagai suatu ilustrasi integrasi COTS. Suatu

organisasi yang besar bermaksud untuk mengembangkan suatu sistem

[Type here]
 pengadaan yang memungkinkan staf untuk menempatkan pesanan-pesanan dari
meja mereka. Efek positif dari penggunaan sistem ini dalam lingkup organisasi,
perusahaan memperkirakan bahwa mereka dapat melakukan penghematan biaya
sebesar US$5.000.000 pertahun. Pembelian yang terpusat, sistem pengadaan
yang baru dapat menjamin bahwa order atau pesanan dari supplier-supplier yang
memberikan penawaran harga terbaik dan seharusnya akan menghemat biaya
kertas yang diasosiasikan dengan pesanan. Sebagaimana dalam sistem manual,
sistem ini memungkinkan aliran aktivitas proses kerja pemilihan barang-barang
yang tersedia dari suatu supplier, pembuatan order, memiliki order atau pesanan
yang telah disetujui, pengiriman pesanan kepada supplier, penerimaan barang-
barang, dan konfirmasi pembayaran dapat dibuat.

Perusahaan memiliki suatu sistem pemesanan ‘’lama’’ yang digunakan

oleh kantor pusat. Perangkat lunak pemroses pesanan ini digabungkan dengan
suatu sistem pengiriman dan sistem tegihan yang telah ada. Untuk membuat
sistem pemesanan, sistem lama ini diintegrasikan dengan suatu platform e-
commerce berbasis web dan suatu sistem surat elektronik yang menangani tugas
komunikasi dengan para pengguna. Struktur dari sistem pengadaan dibangun
dengan menggunakan COTS, ditunjukkan dalam gambar 16.13.

[Type here]
 Gambar 16.13

Sistem Pengadaan COTS-terintegrasi

Sistem pengadaan ini berbasis client-server. Sisi client menggunakan

browser web dan aplikasi e-mail standar. Pada sisi server, platform e-commerce
telah terintegrasi dengan sistem pemesanan yang telah ada sebelumnya melalui
suatu adaptor. Sistem perdagangan elektronik ini memiliki format pesanan
sendiri, konfirmasi pengiriman, dan sebagainya. Yang telah dikonversi ke dalam
format yang digunakan oleh sistem pemesanan/reservasi. Sistem e-commerce ini
menggunakan sistem e-mail untuk mengirimkan notifikasi kepada pengguna,
tetapi sistem reservasi ini bukan didesin untuk tujuan ini. Oleh sebab itu, suatu
perangkat adaptor lain harus ditulis untuk mengubah notifikasi dari sistem
pemesanan ke dalam bentuk e-mail atau surat elektronik.

Selama berbulan-bulan, bahkan bertahun-tahun, usaha implementasi

dapat dikurangi, dan waktu untuk mengembangkan dan mendistribusikan sistem
dapat dikurangi secara signifikan dengan menggunakan pendekatan COTS-
[Type here]
 terintegrasi. Sistem pengadaan yang dijelaskan di atas telah diimplementasikan
dan didistribusikan dalam perusahaan-perusahaan skala besar dalam 9 bulan,
dan tidak perlu memakan waktu hingga tiga tahun sesuai dengan estimasi untuk
melakukannya dengan sistem yang dikembangkan dengan menggunakan bahasa
pemrograman JAVA.

COTS-terintegrasi dapat disederhanakan dengan menggunakan

pendekatan yang berorientasi pada layanan. Secara esensial,suatu pendekatan
yang berorientasi pada layanan berarti bahwa akses kepada fungsionalitas
aplikasi sistem ini dilakukan dengan menggunakan antarmuka layanan standar,
dengan suatu layanan untuk tiap satuan diskrit fungsionalitasnya. Beberapa
aplikasi juga memberikan kemudahan antarmuka layanan, tetapi kadangkala
antarmuka layanan ini harus diimplementasikan dengan menggunakan
integrator sistem. Pengembang harus membuat program suatu wrapper yang
menyembunyikan aplikasi dan menyediakan layanan visibel secara eksternal
(gambar 16.14).

Pendekatan ini sangat berguna untuk sistem-sistem lama yang perlu

diintegrasikan dengan sistem-sistem aplikasi yang lebih baru. Pembaca harus
memahami antarmuka sistem dan menggunakannya secara eksklusif untuk
berkomunikasi dengan suatu perangkat lunak; pembaca harus mengadakan
trade-off antara persyaratan yang spesifik dengan rapid development dan reuse.
Selain itu anda juga perlu untuk membuat desain arsitektur sistem yang dapat
beroperasi bersama dengan sistem-sistem COTS.

[Type here]
 Gambar 16.14

Wrapping Aplikasi

Pada kenyataannya, produk ini biasanya merupakan sistem yang

berukuran besar, dan dijual secara terpisah sebagai sistem yang berdiri sendiri
(standalone system). Hal ini akan menyebabkan timbulnya permasalahan
tambahan. Ada 4 permasalahan penting yang berkaitan erat dengan integrasi
sistem COTS (Boehm dan Abts, 1999), yaitu:

1. Tidak tersedia kendali terhadap fungsionalitas dan kinerja. Meskipun antar-

muka produk yang dipublikasikan terlihat menawarkan fasilitas-fasilitas
yang diperlukan, namun produk ini boleh jadi belum layak untuk
diimplementasikan, atau memiliki kinerja yang buruk. Produk ini bisa jadi
memiliki operasi-operasi tersembunyi yang mengganggu penggunaannya
dalam suatu situasi yang khusus. Mempebaiki masalah ini biasanya menjadi
kewajiban integrator produk COTS, dan bukan kewajiban vendor. Para
pengguna harus menemukan masalah-masalah jika mereka berharap untuk
menggunakan kembali produk COTS.
2. Masalah yang berhubungan dengan interoperabilitas. Kadang-kadang,
sangat sulit untuk memperoleh produk COTS untuk bekerja secara bersama-
sama, karena setiap produk memiliki asumsinya sendiri tentang bagaimana
[Type here]
 itu akan digunakan. Garlan dkk (1995) mengemukakan bahwa berdasarkan
pengalaman mengintegrasikan 4 jenis produk COTS, ditemukan bahwa
terdapat 3 produk yang bekerja berdasarkan-kejadian (event based) yang
menggunakan model-model yang berbeda dari kejadian-kejadian atau
events. Setiap sistem mengasumsikan bahwa sistem memiliki akses eksklusif
terhadap event antrian. Sebagai akibatnya, integrasi akan sulit untuk
dilakukan. Proyek ini memerlukan usaha yang besarnya lima kali lipat dari
prediksi awal. Durasi pelaksanaan pekerjaan ini memerlukan waktu dua
tahun, jauh melebihi estimasi awal yang diperkirakan hanya sekitar 6 bulan.
Dalam suatu analisis retrospektif terhadap proyek yang telah mereka
kerjakan dalam 10 tahun ke depan, Garlan dkk (2009) menyimpulkan bahwa
mereka telah menemukan masalah-masalah yang belum terselesaikan.
Analisis lain juga menemukan bahwa ketidaksesuaian dengan standar-
standar dalam beberapa produk COTS berarti bahwa pekerjaan integrasi
akan menjadi lebih sulit dari yang diperkirakan sebelumnya (Torchiano dan
Morisio,2004)
3. Tidak adanya mekanisme pengendalian terhadap evolusi sistem. Vendor-
vendor produk COTS telah mengambil keputusan untuk melakukan
perubahan terhadap sistem mereka, sebagai tanggapan terhadap tekanan
pasar. Secara khusus menyengkut produk PC, versi-versi yang lebih baru
seringkali diproduksi lebih sering dan boleh jadi tidak kompatibel dengan
versi sebelumnya. Versi-versi yang lebih baru biasanya memiliki
fungsionalitas tambahan yang tidak diinginkan, dan versi sebelumnya
menjadi tidak tersedia atau tidak didukung.
4. Dukungan vendor-vendor COTS. Tingkat ketersediaan dukungan dari
vendor-vendor COTS mengalami perubahan yang lebih luas. Dukungan
vendor ini khususnya menjadi penting saat masalah timbul karena
pengembang perangkat lunak tidak memilik akses terhadap sistem.
Meskipun vendor-vendor telah menyatakan komitmen untuk menyediakan

[Type here]
 dukungan, perubahan keadaan ekonomi dan pasar dapat menimbulkan
kesulitan bagi mereka untuk melaksanakan komitment ini. Sebagai contoh,
suatu sistem COTS mungkin memutuskan untuk menghentikan suatu produk
karena jumlah permintaan yang terbatas atau cenderung rendah, atau bisnis
mereka diambil alih oleh perusahaan lain yang tidak berkeinginan untuk
mendukung seluruh produk yang telah dikeluarkan.
Boehm dan Abts memperkirakan bahwa dalam banyak kasus, biaya
perawatan dan evolusi sistem menjadi lebih besar untuk sistem-sistem
COTS-terintegrasi. Semua kesulitan yang disebutkan di atas berhubungan
dengan masalah siklus-hidup; dan tidak hanya mempengaruhi
pengembangan awal dari sistem. Selanjutnya orang-orang yang terlibat
dalam perawatan sistem berasal dari pengembang sistem original, sehingga
sangat mungkin akan timbul masalah-masalah yang berhubungan dengan
produk COTS-terintegrasi.

 Kebanyakan bisnis sistem perangkat lunak yang baru, saat ini dikembangkan
dengan mengadopsi pengetahuan reusing dan kode dari sistem-sistem yang
telah diimplementasikan sebelumnya.
 Ada berbagai cara yang berbeda untuk menggunakan kembali perangkat
lunak, mulai dari penggunaan kembali kelas-kelas dan metode-metode dalam
pustaka-pustaka sampai kepada penggunaan kembali sistem-sistem aplikasi
yang lengkap.

[Type here]
  Keuntungan dari penggunaan kembali perangkat lunak adalah biaya yang
lebih rendah, pengembangan perangkat lunak yang lebih cepat, dan resiko
yang lebih rendah. Dependabilitas sistem semakin meningkat. Para spesialist
dapat dipergunakan secara lebih efektif dengan pemusatan pengalaman
mereka dalam membuat desain komponen-komponen perangkat lunak yang
dapat dipergunakan kembali (reuse-component design).
 Kerangka kerja aplikasi (application frameworks) adalah koleksi dari objek-
objek abstrak dan kongkrit yang didesain untuk digunakan kembali melalui
spesialisasi dan penambahan objek-objek baru. Mereka biasanya menyertakan
pelatihan desain yang baik (good design practices) melalui pola-pola desain.
 Armada produk perangkat lunak adalah aplikasi-aplikasi yangberhubungan
yang dikembangkan dari satu atau lebih aplikasi dasar. Suatu sistem generik
disesuaikan dan dispesialisasikan untuk memenuhi persyaratan spesifik untuk
fungsionalitas, platform target, atau konfigurasi operasional.
 Penggunaan kembali Produk-produk COTS berhubungan dengan penggunaan
skala-besar dari sistem-sistem off-the-shelf. Produk ini menyediakan banyak
fungsionalitas dan penggunaan kembalinya dapat mengurangi biaya secara
radikal dan waktu pengembangan. Sistem-sistem dikembangkan dengan
pengaturan suatu produk COTS umum, tunggal, atau dengan menggabungkan
dua atau lebih produk COTS.
 Sistem Perencanaan Sumber Daya Perusahaan merupakan contoh dari reuse
COTS skala besar. Anda menciptakan suatu contoh dari suatu sistem ERP
dengan mengkonfigurasikan sebuah sistem umum yang menyediakan
informasi mengenai aturan dan proses bisnis pelanggan.
 Masalah potensial yang mengkin timbul dalam produk COTS berbasis reuse
menyangkut tidak adanya mekanisme pengendalian terhadap fungsionalitas
dan unjuk kerja, tidak adanya kendali terhadap evolusi sistem, kebutuhan
adanya dukungan dari vendor-vendor eksternal, dan kesulitan-kesulitan dalam
menjamin interoperabilitas.

[Type here]
 Chapter 16 ■ Exercises 449

F U RT H E R R E A D I N G

Reuse-based Software Engineering. A comprehensive discussion of different approaches

to software reuse. The authors cover technical reuse issues and managing reuse
processes. (H. Mili, A. Mili, S. Yacoub and E. Addy, John Wiley & Sons, 2002.)

‘Overlooked Aspects of COTS-Based Development’. An interesting article that discusses

a survey of developers using a COTS-based approach, and the problems that they
encountered. (M. Torchiano and M. Morisio, IEEE Software, 21 (2), March–April 2004.)
http://dx.doi.org/10.1109/MS.2004.1270770.

‘Construction by Configuration: A New Challenge for Software Engineering’. This is an

invited paper that I wrote in which I discuss the problems and difficulties of constructing
a new application by configuring existing systems. (I. Sommerville, Proc. 19th
Australian Software Engineering Conference, 2008.)
http://dx.doi.org/10.1109/ASWEC.2008.75.

‘Architectural Mismatch: Why Reuse Is Still So Hard’. This article looks back on an earlier
paper that discussed the problems of reusing and integrating a number of COTS systems. The
authors concluded that, although some progress has been made, there were still problems in
conflicting assumptions made by the designers of the individual systems. (D. Garlan et al.,
IEEE Software, (4), July–August 2009.) http://dx.doi.org//10.1109/MS.2009.86.

[Type here]
SOAL-SOAL LATIHAN

16.1. Apa saja faktor-faktor teknikal dan non-teknikal menghalangi munculnya ide
penggunaan kembali perangkat lunak? Apakah saudara sering menggunakan reuse
perangkat lunak? Jika tidak, jelaskan juga mengapa saudara tidak menggunakan
reuse?

16.2 Jelaskan pendapat saudara, mengapa penghematan biaya dengan menggunakan

kembali perangkat lunak yang telah ada tidak proporsional terhadap ukuran
komponen-komponen yang di-reuse?

16.3 Jelaskan 4 keadaan yang mendorong saudara untuk merekomendasikan ide

penggunaan kembali perangkat lunak.

16.4 Jelaskan apa yang dimaksud dengan ‘inversion of control’ atau pembalikan kendali
dalam framework aplikasi. Jelaskan mengapa pendekatan ini dapat menyebabkan
timbulnya permasalahan jika saudara mengintegrasikan dua sistem yang berbeda
yang dulunya diciptakan menggunakan framework aplikasi yang sama.

16.5 Gunakan contoh sistem stasiun pengamat cuaca (stasiun meteorologi dan geofisika)
yang telah dijelaskan dalam bab 1 dan bab 7. Berikan saran arsitektur armada produk
atau varian keluarga aplikasi yang berhubungan dengan pengumpulan data dan
monitoring daerah yang berada di tempat yang jauh (remote monitoring). Saudara
harus menyajikan arsitektur tersebut sebagai model berlapis, yang menunjukkan
komponen-komponen yang mungkin disertakan dalam tiap level.

16.6 Pada mayoritas perangkat lunak desktop seperti perangkat lunak pengolah kata,
dapat disusun dalam sejumlah cara yang berbeda. Ujilah perangkat lunak yang
sering anda gunakan secara teratur, dan buat daftar opsi konfigurasi untuk perangkat
lunak tersebut. Jika saudara menggunakan Microsoft Office atau Open Office, ini
merupakan contoh yang baik untuk digunakan dalam latihan ini.

16.7 Mengapa dalam banyak perusahan-perusahan skala besar cenderung memilih

menggunakan sistem perencanaan sumber daya perusahaan (Enterprise Resource
Planning,ERP) sebagai basis sistem informasi perusahaan? Permasalahan apa saja
yang mungkin timbul dalam mendistribusikan sistem ERP skala-besar dalam suatu
oraganisasi?

[Type here]
 16.8 Identifikasi 6 jenis resiko yang dapat timbul ketika sistem-sistem dibangun dengan
menggunakan COTS. Berikan uraian saudara langkah-langkah apa saja yang dapat
diambil oleh perusahaan untuk mengurangi resiko-resiko ini?

16.9 Berikan penjelasan saudara mengapa adaptor-adaptor biasanya diperlukan ketika

sistem-sistem dibangun dengan menggunakan produk COTS-terintegrasi. Berikan
saran saudara 3 masalah praktis yang mungkin timbul dalam penulisan kode
perangkat lunak yang berfungsi sebagai adaptor untuk menghubungkan dua
produk aplikasi COTS yang berbeda.

16.10 Penggunaan kembali suatu perangkat lunak memunculkan sejumlah isu-isu yang
berhubungan dengan masalah hak cipta dan hak atas kekayaan intelektual (HAKI).
Jika seorang pelanggan menggaji suatu kontraktor perangkat lunak untuk
mengembangkan suatu sistem, siapakah yang berhak untuk menggunakan
kembali / reuse kode sumber yang telah dikembangkan? Apakah kontraktor
perangkat lunak tersebut memiliki hak untuk menggunakan kode sebagai basis
untuk komponen-komponen yang bersifat umum? Mekanisme pembayaran seperti
apakah yang mungkin untuk dipergunakan untuk imbalan bagi penyedia komponen
reusable? Diskusikan isu-isu ini dan isu lain yang menyangkut masalah etika dalam
penggunaan kembali suatu perangkat lunak.

[Type here]
SOLUSI

16.1 Faktor-faktor yang menghambat penggunaan kembali /reuse perangkat lunak:

Masalah Penjelasan

Faktor teknikal
Tidak ada dukungan Beberapa peralatan perangkat lunak yang tidak mendukung
peralatan pengembangan dengan prinsip reuse. Hal ini akan
menimbulkan kesulitan sehingga tidak mungkin untuk
mengintegrasikan peralatan-peralatan ini dengan suatu sistem
pustaka komponen.
Sindrom not-invented-here Sebagian insinyur perangkat lunak lebih suka untuk menulis
kembali komponen-komponen karena mereka percaya bahwa
mereka dapat meningkatkan kemampuan perangkat lunak
tersebut. Hal ini berhubungan dengan kepercayaan dan
kenyataan bahwa penulisan perangkat lunak yang asli terlihat
lebih menantang daripada menggunakan kembali perangkat
lunak milik orang lain.
Pembuatan,pemeliharan Populasi dari suatu pustaka komponen reusable dan adanya
dan penggunaan pustaka suatu keyakinan bahwa para pengembang perangkat lunak
komponen dapat menggunakan pustaka ini dapat menyebabkan
penggunaan kembali menjadi lebih mahal. Proses-proses
pengembangan harus disesuaikan bahwa pustaka digunakan.
Penemuan, pengertian dan Komponen-komponen harus ditemukan dalam suatu pustaka,
penyesuaian komponen- dimengerti, dan kadangkala disesuaikan agar dapat
komponen yang dapat dimanfaatkan dalam suatu lingkungan yang baru. Para insinyur
dipergunakan kembali harus memiliki alasan yang kuat dalam penemuan komponen
dalam pustaka atau library sebelum disertakan dalam pencarian
komponen sebagai bagian dari proses pengembangan yang
normal.
Faktor non-teknikal

Tingginya biaya perawatan Jika kode sumber dari suatu sistem perangkat lunak atau
komponen yang dipergunakan kembali tidak tersedia, biaya

[Type here]
 perawatan menjadi lebih tinggi karena kuantitas element-
element yang dipergunakan kembali dari sistem perangkat
lunak tersebut dapat menyebabkan inkompatibilitas dengan
perubahan sistem.

Akhir-akhir ini saya tidak pernah menulis kode program, sehingga tidak
melakukan reuse dalam rekayasa perangkat lunak. Reuse kadangkala dilakukan
dalam tingkatan reuse class untuk program berbeda yang menggunakan kelas
dengan fungsionalitas yang sama. Bisa juga dikatakan reuse program dengan
modifikasi kelas, komponen tertentu untuk menambah atau menghapus kelas dan
komponen dalam program yang berbeda namun memiliki fungsionalitas yang
hampir sama untuk memenuhi kebutuhan pribadi atau klien yang memiliki core
bisnis yang sama atau hampir sama. Misalnya sistem informasi medis untuk klien
rumah sakit yang berbeda, sistem informasi akademik untuk fakultas atau
universitas yang berbeda, sistem informasi perencanaan sdm, finance suatu
perusahaan yang memiliki fungsionalitas core business, aturan dan proses bisnis
yang hampir sama.
16.2 Karena reuse itu sendiri merupakan suatu proses aktivitas menggunakan kembali
kode sumber, maka dalam skala besar tentu perlu suatu aktivitas tambahan
sebelum melakukan reuse itu sendiri. Aktivitas ini adalah menguji untuk
menentukan kelas-kelas, komponen-komponen mana saja yang harus direuse
sesuai dengan kebutuhan. Pengerjaan proses pengujian dan penentuan ini tentu
memerlukan alokasi waktu dan komponen biaya tambahan yang diperlukan.
Pengembang harus mempertimbangkan proporsionalitas reduksi biaya
keseluruhan dibandingkan dengan komponen biaya yang timbul untuk reuse ini.
Jangan sampai komponen biaya yang timbul jauh lebih besar dari pada saat tidak
melakukan reuse, sehingga penghematan yang dilakukan tidak berguna.
16.3 Faktor utama yang harus dipertimbangkan saat merencanakan reuse
adalah:
Jadwal pengembangan perangkat lunak. Jadwal pengembangan perangkat
lunak. Jika sebuah perangkat lunak perlu untuk dikembangkan secara
cepat, maka anda seharusnya mencoba untuk menggunakan kembali off-

[Type here]
 the-shelf system COTS dari pada menggunakan kembali komponen-
komponen secara individual. Ini merupakan “bulir kasar” asset-asset yang
dapat dipergunakan kembali. Walaupun kesesuaian terhadapan
persyaratan yang ditentukan belum sempurna,namun pendekatan yang
digunakan ini dapat meminimalisasi jumlah pengembangan yang
dipersyaratkan.
1. Siklus hidup/Masa Pakai Perangkat Lunak Yang Diharapkan. Jika
anda sedang mengembangkan sistem –sistem dengan waktu-hidup
yang panjang, anda seharusnya berfokus pada maintainabilitas
sistem. Anda seharusnya tidak hanya memikirikan mengenai manfaat
sesaat dari reuse tetapi juga implikasi jangka panjang. Pada saat
sistem tersebut telah mencapai atau melebihi batas umur yang
diharapkan, maka kita perlu untuk mendefinisikan persyaratan-
persyaratan yang baru untuk disesuaikan dengan sistem yang baru
pula. Ini berarti melakukan perubahan pada bagian-bagian tertentu
dari sistem. Jika anda tidak memiliki hak akses terhadap kode
sumber, boleh jadi anda lebih suka untuk menghindari komponen-
komponen off-the-shelf dan sistem-sistem dari supplier eksternal;
supplier bisa jadi tidak dapat melanjutkan dukungan untuk perangkat
lunak yang dimanfaatkan kembali.

2. Latar belakang, Keahlian, dan Pengalaman Tim Pengembang

Perangkat Lunak. Semua teknologi reuse bersifat kompleks, para
insinyur perangkat lunak akan menghabiskan banyak waktu untuk
memahami dan menggunakan reuse teknologi ini secara efektif. Oleh
karena itu, jika tim yang mengembangkan perangkat lunak memiliki
skill dalam area-area khusus, mungkin ini adalah tempat dimana para
developer harus memusatkan perhatiannya.

[Type here]
 3. Latar belakang, Keahlian, dan Pengalaman Tim Pengembang
Perangkat Lunak. Semua teknologi reuse bersifat kompleks, para
insinyur perangkat lunak akan menghabiskan banyak waktu untuk
memahami dan menggunakan reuse teknologi ini secara efektif. Oleh
karena itu, jika tim yang mengembangkan perangkat lunak memiliki
skill dalam area-area khusus, mungkin ini adalah tempat dimana para
developer harus memusatkan perhatiannya.

4. Perangkat Lunak Critical dan Persyaratan Non-Fungsionalnya.

Sistem-sistem yang critical perlu untuk disertifikasi oleh suatu badan
regulator eksternal; anda dapat membuat dependability case untuk
sistem ini (Penulis telah membahas materi ini pada bab 15). Hal ini
akan menjadi sulit jika anda tidak memiliki akses terhadap kode
sumber perangkat lunak. Jika perangkat lunak anda memiliki
persyaratan unjuk kerja yang keras, mustahil untuk menggunakan
strategi-strategi seperti reuse berbasiskan pembangkit, dimana
seorang insinyur perangkat lunak membangkitkan suatu kode dari
daerah asal tertentu dari suatu sistem. Sistem-sistem ini sering kali
membangkitkan kode yang relatif tidak efiesien.

16.4 Inversion of Control adalah istilah lain dari callbacks adalah metode-metode
yang dipanggil sebagai tanggapan terhadap kejadian atau events yang dikenali
oleh suatu framework. Objek-objek framework, merupakan objek-objek
aplikasi yang spesifik, dan bertanggungjawab untuk mengendalikan sistem.
Sebagai respon terhadap events dari pengguna antarmuka, basis data, dsb maka
frameworks ini akan melakukan metode hook yang menghubungkan kepada
fungsionalitas yang disediakan oleh pengguna. Fungsionalitas aplikasi yang
spesifik menanggapi event tersebut dengan cara yang bersesuaian (gambar
16.6). Sebagai contoh, suatu framework akan memiliki suatu metode yang
menangani suatu mouse click dari lingkungan. Metode ini memanggil metode
[Type here]
 hook, yang harus dikonfigurasikan oleh pengguna untuk memanggil metode
aplikasi yang sesuai untuk menangani mouse click. Pendekatan penggunaan
Penggunaan framework ini merupakan pendekatan yang baik jika digunakan
dalam reuse, namun akan memerlukan biaya tinggi jika digunakan dalam
proses pengembangan perangkat lunak. Framework ini rumit dan tidak dapat
dipisahkan. Akan memerlukan waktu berbulan-bulan untuk belajar
menggunakannya. Ini bisa menjadi sulit dan mahal untuk melakukan evaluasi
framework yang tersedia untuk memilih framework yang paling sesuai

Gambar 16.6

Inversion of control atau callbacks dapat dilakukan oleh pengguna dengan event loop pada GUI, basis

data atau platform untuk memanggil kembali kelas-kelas aplikasi spesifik yang diperlukan.

16.5 Arsitektur 4-lapis sistem alokasi sumber daya untuk sistem stasiun pengamat
cuaca atau stasiun pengamat cuaca badan meteorologi dan geofisika beserta
komponennya dalam tiap level seperti contoh sistem bab 1 dan bab 7:

[Type here]
 Interaksi / antarmuka pengguna

Antarmuka operator Antarmuka komunikasi sistem

dengan stasiun-stasiun pengamat

Manajemen I/O

Otentikasi Pengguna Sistem kendali Manajemen query

sensor
pengumpulan
data cuaca
Report Generator

Manajemen sumber-daya

Stasiun pengamat Sensor pengumpulan Baterai

data

Manajemen database

Database stasiun Database data cuaca Contor map database

pengamat hasil pembacaan sensor

[Type here]
16.6 Konfigurasi Built-in perangkat lunak pengolah kata Microsoft WORD 2016:

File : info,new, save, save as, open, print, share, export, close.
Home : Apllication Program Interface clipboard, font, paragraph, style
Insert : ILLUSTRATION: PICTURE,ONLINE PICTURES, SHAPE,SMART
ART, CHART, SCREEN SHOT.
TEXT
SYMBOLS
COMMENTS
LINK
Design : Themes, colour, fonts, Page Background
Layout : Page Setup, Paragraph, Arrange
References : TOC, Citations ^ Bibliography, Caption, Index, Table of
Authorities
Mailings : Create, Start Mail Merge,Write and Insert Fields,Preview Results
Review : Proofing, Insights,Language, Comments, Tracking, Changes,
Compare,Protect
View : Views, Show, Zoom, Window, Macros.
16.7 Perusahaan-perusahaan skala besar cenderung memilih menggunakan ERP
sebagai basis sistem informasi perusahaan karena:
1. Sistem ERP memiliki banyak modul untuk mendukung fungsi-fungsi
bisnis perusahaan. Modul modul “bulir-besar” ini mendukung kebutuhan
bisnis seluruh departemen atau divisi dalam perusahaan. Misalnya saja
ERP memiliki modul yang mendukung purchasing, supply-chain
management, logistic, dan customer-relationship management (gambar
6.12)
2. Suatu himpunan proses bisnis yang terdefinisi dihubungkan dengan tiap
modul yang berhubungan dengan aktivitas dalam modul tersebut. Sebagai
contoh, ada definisi proses ordering atau pembuatan order yang

[Type here]
 mendefisikan bagaimana order atau pesanan barang tertentu dibuat dan
disetujui. Ini akan menentukan peran dan aktivitas yang berhubungan
dengan penempatan pesan.
3. ERP memiliki suatu basis-data umum yang memelihara informasi-
informasi tentang seluruh fungsi-fungsi bisnis yang berhubungan. Hal ini
berarti perusahaan tidak perlu untuk melakukan replikasi informasi seperti
rincian pelanggan dalam bagian yang terpisah dari bisnis perusahaan.
4. ERP memiliki sekumpulan aturan bisnis yang diterapkan kepada seluruh
data yang terdapat dalam database. Oleh sebab itu, ketika data dimasukkan
dari suatu fungsi, aturan-aturan ini akan menjamin bahwa data ini konsisten
dengan data yang disyaratkan oleh fungsi-fungsi lainnya. Sebagai contoh
dalam sistem ERP terdapat suatu aturan bisnis yang menyatakan bahwa
klain harus memperoleh persetujuan oleh seseorang yang tingkatannya
lebih senior dari pada orang yang mengajukan klaim.

Gambar 6.12
Arsitektur Umum sistem Perencanaan Sumber daya Perusahaan (Enterprise
Resource System,ERP).

[Type here]
 Permasalahan yang timbul dalam distribusi sistem ERP adalah setiap produk
sistem ERP umumnya hanya memiliki fungsionalitas yang bersifat umum atau
generic core saja. Proses dan operasional bisnis perusahaan sudah dijelaskan
dalam suatu bahasa konfigurasi sistem (system configuration language) yang
telah dibuat sebelumnya. Pada kenyataannya, mungkin saja terjadi
ketidakcocokan atau mismatch antara konsep dalam bisnis di dunia nyata
dengan konsep yang diciptakan dalam bahasa konfigurasi sistem. Dalam hal ini
perlu dilakukan penyesuaian kembali atau konfigurasi terhadap fungsionalitas,
model data yang digunakan, aturan-aturan bisnis,ekspektasi interaksi dengan
sistem eksternal,bentuk masukan dan laporan keluaran yang dihasilkan oleh
sistem,mendefinisikan proses bisnis yang baru sesuai dengan proses lapis
bawah yang didukung oleh sistem, dan pengaturan parameter-parameter yang
diperlukan dalam system deployment sesuai dengan platfor yang mendasarinya.

16.8 Klasikfikasi 6 jenis resiko yang dapat timbul saat membangun atau
Mengembangkan sistem dengan menggunakan COTS:

[Type here]
 Contoh praktis 6 jenis resiko (teknologi, sdm, organisasi, peralatan,
persyaratan dan estimasi) yang timbul saat pengembangan sistem termasuk
sistem COTS:
Resiko Pengaruh Penjelasan

Staff turnover Proyek Staf yang berpengalaman

meninggalkan proyek sebelum
selesai
Perubahan Proyek Terjadi perubahan manajemen
Manajemen yang memilik prioritas yang
berbeda
Perangkat keras yang Proyek Perangkat keras yang penting
dibutuhkan tidak tidak dikirmkan sesuai rencana
tersedia waktu yang ditentukan
Perubahan Proyek dan Ada sejumlah besar perubahan
requirements Produk persyaratan atau requirement
melebihi perkiraan atau estimasi.
Penundaan spesifikasi Proyek dan Spesifikasi interface yang
Produk diperlukan tidak tersedia sesuai
dengan schedule
Size underestimate Proyek dan Ukuran sistem jauh lebih rendah
Produk dibawah perkiraan
Kinerja perangkat Produk Perangkat CASE yang digunakan
CASE rendah untuk mendukung pelaksanaan
proyek tidak memberikan unjuk
kerja sesuai perhitungan yang
diinginkan.

[Type here]
 Perubahan teknologi Operasional Teknologi yang menjadi basis
Bisnis pengembangan sistem telah
digantikan dengan teknologi yang
lebih baru.
Kompetisi Produk Operasional Produk COTS perusahaan lain
Bisnis yang kompetitif dipasarkan
terlebih dahulu sebelum sistem
diselesaikan seluruhnya.

Langkah-langkah antisipatif perusahaan sebagai strategi untuk ansipasi

resiko yang muncul:

16.9 Adaptor (berfungsi sebagai converter) biasanya dibutuhkan saat membangun

sistem COTS-terintegrasi untuk mengubah representasi atau penyajian data dari
satu bentuk ke bentuk lainnya agar dapat dimengerti dan digunakan oleh tiap-

[Type here]
 tiap COTS berbeda yang akan diintegrasikan. Ada 3 problem praktis yang dapat
terjadi dalam menulis kode perangkat lunak yang berfungsi sebagai adaptor:

1. Tidak tersedia kendali terhadap fungsionalitas dan kinerja. Meskipun

antar-muka produk yang dipublikasikan terlihat menawarkan fasilitas-
fasilitas yang diperlukan, namun produk ini boleh jadi belum layak untuk
diimplementasikan, atau memiliki kinerja yang buruk. Produk ini bisa jadi
memiliki operasi-operasi tersembunyi yang mengganggu penggunaannya
dalam suatu situasi yang khusus. Mempebaiki masalah ini biasanya menjadi
kewajiban integrator produk COTS, dan bukan kewajiban vendor. Para
pengguna harus menemukan masalah-masalah jika mereka berharap untuk
menggunakan kembali produk COTS.
2. Masalah yang berhubungan dengan interoperabilitas. Kadang-kadang,
sangat sulit untuk memperoleh produk COTS untuk bekerja secara
bersama-sama, karena setiap produk memiliki asumsinya sendiri tentang
bagaimana itu akan digunakan. Garlan dkk (1995) mengemukakan bahwa
berdasarkan pengalaman mengintegrasikan 4 jenis produk COTS,
ditemukan bahwa terdapat 3 produk yang bekerja berdasarkan-kejadian
(event based) yang menggunakan model-model yang berbeda dari kejadian-
kejadian atau events. Setiap sistem mengasumsikan bahwa sistem memiliki
akses eksklusif terhadap event antrian. Sebagai akibatnya, integrasi akan
sulit untuk dilakukan. Proyek ini memerlukan usaha yang besarnya lima
kali lipat dari prediksi awal. Durasi pelaksanaan pekerjaan ini memerlukan
waktu dua tahun, jauh melebihi estimasi awal yang diperkirakan hanya
sekitar 6 bulan. Dalam suatu analisis retrospektif terhadap proyek yang
telah mereka kerjakan dalam 10 tahun ke depan, Garlan dkk (2009)
menyimpulkan bahwa mereka telah menemukan masalah-masalah yang
belum terselesaikan. Analisis lain juga menemukan bahwa ketidaksesuaian
dengan standar-standar dalam beberapa produk COTS berarti bahwa

[Type here]
 pekerjaan integrasi akan menjadi lebih sulit dari yang diperkirakan
sebelumnya (Torchiano dan Morisio,2004)
3. Tidak adanya mekanisme pengendalian terhadap evolusi sistem. Vendor-
vendor produk COTS telah mengambil keputusan untuk melakukan
perubahan terhadap sistem mereka, sebagai tanggapan terhadap tekanan
pasar. Secara khusus menyengkut produk PC, versi-versi yang lebih baru
seringkali diproduksi lebih sering dan boleh jadi tidak kompatibel dengan
versi sebelumnya. Versi-versi yang lebih baru biasanya memiliki
fungsionalitas tambahan yang tidak diinginkan, dan versi sebelumnya
menjadi tidak tersedia atau tidak didukung.
4. Dukungan vendor-vendor COTS. Tingkat ketersediaan dukungan dari
vendor-vendor COTS mengalami perubahan yang lebih luas. Dukungan
vendor ini khususnya menjadi penting saat masalah timbul karena
pengembang perangkat lunak tidak memilik akses terhadap sistem.
Meskipun vendor-vendor telah menyatakan komitmen untuk menyediakan
dukungan, perubahan keadaan ekonomi dan pasar dapat menimbulkan
kesulitan bagi mereka untuk melaksanakan komitment ini. Sebagai contoh,
suatu sistem COTS mungkin memutuskan untuk menghentikan suatu
produk karena jumlah permintaan yang terbatas atau cenderung rendah, atau
bisnis mereka diambil alih oleh perusahaan lain yang tidak berkeinginan
untuk mendukung seluruh produk yang telah dikeluarkan

16.10. Dengan mengacu pada KODE ETIK DAN PELATIHAN PROFESIONAL

PERANGKAT LUNAK mengenai hubungan antara software engineer
(kontraktor atau developer) dan klien (pelanggan yang menggunakan jasa
kontraktor, konsultan, developer perangkat lunak), pelanggan adalah klien dari
developer. Yang paling berhak untuk reuese kode sumber yang telah
dikembangkan adalah kontraktornya sendiri. Kontraktor memiliki hak untuk
menggunakan kode sebagai basis pengembangan komponen yang bersifat

[Type here]
 umum. Mekanisme pembayaran dengan menggunakan jasa perbankan. Yang
perlu diperhatikan adalah sebelum memulai pekerjaan, ada perjanjian kerja
antara kontraktor dan pelanggan yang menyatakan hak dan kewajiban yang
harus dipatuhi oleh developer dan pelanggan yang menggunakan jasa
developer/kontraktor tersebut. Yang jelas pekerjaan kontraktor harus sejalan
dengan keinginan pelanggan dan masyarakat luas dan tidak melanggar norma-
norma hukum yang mengatur tentang hal tersebut, kecuali dinyatakan lain
dalam perjanjian kerja.

.
1. Kerahasiaan (confidentiality). Software engineer seharusnya menghormati kerahasiaan
pekerja atau klien tanpa memperhatikan apakah persetujuan kerahasiaan resmi secara
tertulis telah ditandatangani.
2. Kompetensi (competence). Seorang insinyur perangkat lunak seharusnya menghindari
terjadinya kesalahan dalam menjelaskan level kompetensi yang dimilikinya. Seorang
software engineer seharusnya tidak menerima pekerjaan di luar kompetensi yang
dimilikinya.
3. Hak Atas Kekayaan Intelektual (Intellectual Property Rights). Pahami aturan-aturan hukum
yang mengatur tentang penggunaan properti intelektual seperti hak patent dan hak cipta.
Seorang Software Engineer harus menjaga dan melindungi properti intelektual
perusahaan dan client.
4. Penyalahgunaan komputer (Computer Misuse). Seorang Software Engineer seharusnya
tidak menggunakan kemampuan teknikalnya untuk menyalahgunakan komputer milik
orang lain. Penyalahgunaan komputer bisa terjadi mulai dari tingkat ringan (bermain game
dengan menggunakan sumberdaya komputer yang dimiliki perusahaan) hingga ke tingkat
yang sangat serius (menyebarkan virus atau malware lainnya).

[Type here]
 Kode Etik dan Pelatihan Profesional Rekayasa Perangkat Lunak
ACM/IEEE Komite Gabungan pada Kode Etik dan Pelatihan Profesional Rekayasa Perangkat Lunak

PEMBUKAAN
Versi yang lebih singkat dari kode etik merupakan intisari dari berbagai aspirasi pada abstraksi tingkat tinggi. Klausa-
klausa yang digunakan dalam versi lengkap dari kode etik dan pelatihan profesional rekayasa perangkat lunak ini
memberikan contoh-contoh dan rincian bagaimana aspirasi ini mengubah cara seseorang bertindak sebagai
seorang engineer perangkat lunak profesional. Tanpa adanya aspirasi, rincian bisa menjadi sesuatu yang bersifat
legalistik dan menyebabkan kejenuhan;sebaliknya tanpa rincian aspirasi ibarat tong kosong nyaring bunyinya;
aspirasi dan rincian digabungkan bersama-sama keduanya akan membentuk suatu kode yang sinergis.
Para insinyur perangkat lunak harus memiliki komitmen pribadi untuk membuat analisis, spesifikasi,
desain, pengembangan, pengujian dan pemeliharaan perangkat lunak menjadi suatu profesi yang berguna dan
dihormati di masyarakat. Sehubungan dengan komitmen mereka untuk kesehatan, keselamatan dan kesejahteraan
masyarakat, para insinyur perangkat lunak harus senantiasa berpegang teguh sesuai dengan delapan prinsip utama:
1. PUBLIK – Seorang Software Engineer harus bertindak konsisten dan
memperhatikan kebutuhan masyarakat umum.
2. PERUSAHAAN DAN KLIEN – Seorang software engineer bertingkah laku dengan
cara sedemikian sehingga ekspektasi perusahaan dan ekspektasi klien
sejalan dengan ekspektasi masyarakat luas.
3. PRODUK – Software Engineer harus dapat meyakinkan bahwa produk perangkat
lunak yang diproduksi dan modifikasi-modifikasi yang dilakukan memenuhi
standar profesional yang setinggi mungkin.
4. JUSTIFIKASI – Para software engineer harus memelihara integritas dan independensi dalam membuat
suatu justifikasi profesional.
5. MANAJEMEN – Manager dan Leader perusahaan yang bergerak dalam bidang pengembangan perangkat
lunak harus berlangganan dan mempromosikan suatu pendekatan etikal kepada pihak manajemen
perusahaan pengembang dan pemeliharaan perangkat lunak.
6. PROFESI – Software engineer harus menjaga integritas dan reputasi profesi secara konsisten dengan
harapan masyarakat lias.
7. KOLEGA – Software Engineer harus bersikap fair dan mendukung kolega atau rekan sejawatnya.
8. MOTIVASI DIRI – Setiap software engineer harus senantiansa berpartisipasi dalam proses pembelajaran
seumur hidup mengenai pelatihan profesional dan mengutamakan pendekatan etikal terhadap pelatihan
profesional rekayasa perangkat lunak.

[Type here]
REFERENS I

Baker, T. (2002). ‘Lessons Learned Integrating COTS into Systems’. Proc. ICCBSS 2002 (1st
Int. Conf on COTS-based Software Systems), Orlando, Fla:: Springer, 21–30.

Balk, L. D. and Kedia, A. (2000). ‘PPT: A COTS Integration Case Study’. Proc. Int. Conf. on Software

Eng., Limerick, Ireland: ACM Press, 42–9.

Baumer, D., Gryczan, G., Knoll, R., Lilienthal, C., Riehle, D. and Zullighoven, H. (1997).
‘Framework Development for Large Systems’. Comm. ACM, 40 (10), 52–9.

Boehm, B. and Abts, C. (1999). ‘COTS Integration: Plug and Pray?’ IEEE Computer, 32 (1), 135–38.

Brownsword, L. and Morris, E. (2003). ‘The Good News about COTS’.

http://www.sei.cmu.edu/ news-at-sei/features/2003/1q03/feature-1-1q03.htm

Cusamano, M. (1989). ‘The Software Factory: A Historical Interpretation’. IEEE Software, 6 (2), 23–30.

Fayad, M. E. and Schmidt, D. C. (1997). ‘Object-oriented Application Frameworks’. Comm.

ACM, 40 (10), 32–38.

Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995). Design Patterns: Elements of Reusable

Object-Oriented Software. Reading, Mass.: Addison-Wesley.

Garlan, D., Allen, R. and Ockerbloom, J. (1995). ‘Architectural Mismatch: Why Reuse is so Hard’.

IEEE Software, 12 (6), 17–26.

Garlan, D., Allen, R. and Ockerbloom, J. (2009). ‘Architectural Mismatch: Why Reuse is Still so Hard’.

IEEE Software, 26 (4), 66–9.

Griss, M. L. and Wosser, M. (1995). ‘Making reuse work at Hewlett-Packard’. IEEE Software, 12 (1), 105–7.

[Type here]
 Bab 16 ■ Referensi

Holdener, A. T. (2008). Ajax: The Definitive Guide. Sebastopol, Calif.: O’Reilly and Associates.

Jacobson, I., Griss, M. and Jonsson, P. (1997). Software Reuse. Reading, Mass.: Addison-Wesley.

Matsumoto, Y. (1984). ‘Some Experience in Promoting Reusable Software: Presentation in Higher

Abstract Levels’. IEEE. Trans. on Software Engineering, SE-10 (5), 502–12.

McIlroy, M. D. (1968). ‘Mass-produced software components’. Proc. NATO Conf. on Software Eng.,
Garmisch, Germany: Springer-Verlag.

Nuseibeh, B. (1997). ‘Ariane 5: Who Dunnit?’ IEEE Software, 14 (3), 15–6.

O’Leary, D. E. (2000). Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic

Commerce and Risk. Cambridge, UK: Cambridge University Press.

Pfarr, T. and Reis, J. E. (2002). ‘The Integration of COTS/GOTS within NASA’s HST Command and
Control System’. Proc. ICCBSS 2002 (1st Int. Conf on COTS-based Software Systems), Orlando, Fla.:
Springer, 209–21.

Schmidt, D. C. (1997). ‘Applying design patterns and frameworks to develop object-oriented

communications software’. In Handbook of Programming Languages, Vol. 1. (ed.). New York:
Macmillan Computer Publishing.

Schmidt, D. C., Gokhale, A. and Natarajan, B. (2004). ‘Leveraging Application Frameworks’. ACM
Queue, 2 (5 (July/August)), 66–75.

Scott, J. E. (1999). ‘The FoxMeyer Drug’s Bankruptcy: Was it a Failure of ERP’. Proc. Association for
Information Systems 5th Americas Conf. on Information Systems, Milwaukee, WI.

Torchiano, M. and Morisio, M. (2004). ‘Overlooked Aspects of COTS-Based Development’.

IEEE Software, 21 (2), 88–93.

[Type here]
Tracz, W. (2001). ‘COTS Myths and Other Lessons Learned in Component-Based Software Development’. In
Component-based Software Engineering. Heineman, G. T. and Councill, W. T. (ed.). Boston: Addison

[Type here]