REKAYASA PERANGKAT LUNAK

SOFTWARE REUSE

[Software Reuse]

Page 2 of 23

16.1. Software Reuse

Software reuse adalah proses dimana suatu organisasi mendefinisikan
satu set prosedur operasi yang sistematis untuk menentukan, menghasilkan,
mengklasifikasikan, mengambil, dan beradaptasi artefak perangkat lunak untuk
tujuan menggunakan mereka dalam kegiatan pembangunan." (Mili et al., 2002).
Penggunaan kembali perangkat lunak adalah proses menciptakan sistem
perangkat lunak dari sistem perangkat lunak yang ada. Reuse adalah seperti
rekening tabungan. Sebelum kita kumpulkan minat, kita harus melakukan
deposit, dan semakin kita masukkan ke dalam, semakin besar dividen.
Rekayasa perangkat lunak berbasis Reuse adalah strategi rekayasa
perangkat lunak di mana proses pembangunan diarahkan untuk menggunakan
kembali perangkat lunak yang sudah ada. Meskipun penggunaan kembali
diusulkan sebagai strategi pembangunan lebih dari 40 tahun yang lalu (McIlroy,
1968), hanya sejak tahun 2000 bahwa 'pembangunan dengan reuse' telah
menjadi norma bagi sistem bisnis baru. Rekayasa perangkat lunak telah lebih
fokus pada pengembangan asli tetapi sekarang diakui bahwa untuk mencapai
perangkat lunak yang lebih baik, lebih cepat dan biaya lebih rendah, kita
membutuhkan proses desain yang didasarkan pada penggunaan kembali
perangkat lunak yang sistematis. Ketersediaan perangkat lunak dapat digunakan
kembali telah meningkat secara dramatis. Gerakan open source berarti bahwa
ada besar dapat digunakan kembali kode dasar tersedia dengan biaya rendah.
Rekayasa perangkat lunak berbasis Reuse adalah sebuah pendekatan
untuk pembangunan yang mencoba untuk memaksimalkan penggunaan kembali
perangkat lunak yang ada. Unit perangkat lunak yang digunakan kembali
mungkin ukuran yang berbeda. Sebagai contoh:

[Software Reuse] [2014]

Page 3 of 23

a. Sistem Aplikasi Reuse

Seluruh sistem aplikasi dapat digunakan kembali dengan
memasukkan, tanpa berubah menjadi sistem lain atau dengan
mengkonfigurasi aplikasi untuk pelanggan yang berbeda. Atau, keluarga
aplikasi yang memiliki arsitektur yang umum, tetapi yang disesuaikan untuk
pelanggan tertentu, dapat dikembangkan.
b. Komponen Reuse
Komponen aplikasi, mulai dari ukuran subsistem ke objek tunggal,
dapat digunakan kembali. Sebagai contoh, sistem pencocokan pola yang
dikembangkan sebagai bagian dari sistem pengolahan teks dapat digunakan
kembali dalam sistem manajemen database.
c. Obyek dan Fungsi Reuse
Komponen perangkat lunak yang melaksanakan fungsi tunggal,
seperti fungsi matematika, atau kelas objek dapat digunakan kembali.
Bentuk reuse, berdasarkan pada library standar, yang umumnya selama 40
tahun terakhir. Banyak library fungsi dan kelas yang tersedia secara bebas.
Anda dapat menggunakan kembali kelas dan fungsi di library ini dengan
menghubungkan mereka dengan kode aplikasi baru dikembangkan. Di area
seperti algoritma matematika dan grafis, di mana keahlian khusus yang
dibutuhkan untuk mengembangkan objek efisien dan fungsi, ini adalah
pendekatan yang sangat efektif.
Keuntungan dari software reuse adalah bahwa biaya pengembangan
secara keseluruhan dapat dikurangi. Sedikit komponen perangkat lunak
harus ditentukan, dirancang, dilaksanakan, dan divalidasi. Namun,
pengurangan biaya adalah hanya salah satu keuntungan dari penggunaan
kembali.

[Software Reuse] [2014]

Page 4 of 23

Di Bawah ini adalah keuntungan dari software reuse:

Keuntungan Penjelasan
Peningkatan Ketergatungan Software Reuse, yang telah dicoba
dan diuji dalam sistem kerja, harus
lebih diandalkan daripada perangkat
lunak baru. Desain dan implementasi
kesalahannya harus ditemukan dan
diperbaiki.
Mengurangi Proses Risiko Biaya perangkat lunak yang ada sudah
diketahui, sedangkan biaya
pengembangan selalu masalah
pertimbangan. Ini merupakan faktor
penting untuk manajemen proyek
karena mengurangi margin of error
dalam estimasi biaya proyek. Hal ini
terutama berlaku ketika komponen
perangkat lunak yang relatif besar
seperti subsistem digunakan kembali.
Keefektifitasan menggunakan
spesialis
Daripada melakukan pekerjaan yang
sama berulang-ulang, spesialis aplikasi
dapat mengembangkan perangkat
lunak yang dapat digunakan kembali
yang merangkum pengetahuan
mereka.
Standar kepatuhan Beberapa standar, seperti standar
user interface yang dapat
diimplementasikan sebagai satu set
komponen dapat digunakan
kembali. Misalnya, jika menu
dalam user interface yang
diimplementasikan dengan
menggunakan komponen dapat
digunakan kembali, semua aplikasi
menyajikan format menu yang
sama kepada pengguna.
Penggunaan user interface standar
dapat meningkatkan
ketergantungan karena pengguna
akan membuat kesalahan lebih
sedikit ketika disajikan dengan
antarmuka yang familiar.
Mempercepat Pengembangan Membawa sistem ke pasar secepat
[Software Reuse] [2014]

Page 5 of 23

mungkin sering lebih penting

daripada biaya pembangunan
secara keseluruhan. Menggunakan
kembali perangkat lunak dapat
mempercepat produksi sistem
karena kedua pengembangan dan
waktu validasi dapat dikurangi.

Namun, ada biaya dan masalah yang terkait dengan penggunaan kembali.
Ada biaya yang signifikan terkait dengan pemahaman apakah komponen cocok
untuk digunakan kembali dalam situasi tertentu, dan dalam pengujian komponen
yang untuk memastikan kehandalan nya. Biaya-biaya tambahan berarti bahwa
pengurangan biaya pengembangan keseluruhan melalui penggunaan kembali
mungkin kurang daripada yang diantisipasi.
Masalah Penjelasan
Meningkatkan Biaya Maintenance Jika source code atau komponen dari
perangkat lunak yang digunakan tidak
tersedia, maka biaya maintenance
akan meningkat karena unsur 鈥� unsur
yang digunakan kembali dari system
dapat menjadi semakin tidak sesuai
dengan perubahan system
Kurangnya Alat Pendukung Beberapa perangkat lunak tidak
mendukung pengembangan dengan
reuse. Mungkin sulit atau tidak
mungkin untuk mengintegrasikan
alat-alat ini dengan sistem
perpustakaan komponen. Proses
perangkat lunak diasumsikan oleh
alat-alat ini mungkin tidak mengambil
reuse ke rekening. Hal ini terutama
berlaku untuk alat-alat yang
mendukung embedded system
engineering, kurang begitu untuk alat
pengembangan berorientasi objek.
Sindrom 鈥淭 idak Ditemukan Disini 鈥� Beberapa software engineer memilih
untuk menulis ulang komponen
karena mereka percaya bahwa
mereka dapat memperbaikinya. Hal
[Software Reuse] [2014]

Page 6 of 23

ini sebagian untuk melakukan dengan

kepercayaan dan sebagian
hubungannya dengan fakta bahwa
menulis software asli dianggap lebih
menantang daripada menggunakan
kembali software orang lain.
Membuat, Memelihara, dan
Menggunakan Library Komponen
Mengisi library komponen yang
digunakan kembali dan memastikan
pengembang software dapat
menggunakan library ini bisa menjadi
mahal. Proses pengembangan harus
disesuaikan untuk memastikan bahwa
library tersebut digunakan.
Menemukan, Memahami, dan
Beradaptasi dengan komponen
reusable
Komponen software harus ditemukan
di library, dipahami dan, kadang-
kadang, diadaptasikan untuk bekerja
di lingkungan yang baru. Engineering
harus cukup yakin untuk menemukan
komponen di library sebelum mereka
termasuk pencarian komponen
sebagai bagian dari proses
perkembangan normal mereka.
[Software Reuse] [2014]

Page 7 of 23

16.1.1 The Reuse Landscape

Gambar 16.1. The Reuse Landscape

Mengingat array ini teknik untuk digunakan kembali, pertanyaan

kuncinya adalah "yang merupakan teknik yang paling tepat untuk digunakan
dalam situasi tertentu?" Jelas, ini tergantung pada persyaratan untuk sistem
yang dikembangkan, teknologi dan aset dapat digunakan kembali tersedia, dan
keahlian dari tim pengembangan. Faktor-faktor utama yang harus Anda
pertimbangkan ketika merencanakan penggunaan kembali adalah:
a. Jadwal pengembangan software
Jika perangkat lunak tersebut harus dikembangkan dengan cepat,
Anda harus mencoba untuk menggunakan kembali off-the-shelf sistem
daripada komponen individu. Ini adalah besar-grain aset dapat digunakan
kembali. Meskipun cocok dengan kebutuhan mungkin tidak sempurna,
pendekatan ini meminimalkan jumlah pembangunan yang dibutuhkan.

[Software Reuse] [2014]

Page 8 of 23

b. Masa waktu software yang diharapkan

Jika Anda sedang mengembangkan sebuah sistem lama seumur
hidup, Anda harus fokus pada pemeliharaan sistem. Anda seharusnya tidak
hanya berpikir tentang manfaat langsung dari penggunaan kembali tetapi
juga implikasi jangka panjang.
c. Latar belakang, keterampilan, dan pengalaman dari tim pengembangan
Semua teknologi reuse cukup kompleks dan Anda perlu cukup banyak
waktu untuk memahami dan menggunakannya secara efektif. Oleh karena
itu, jika tim pengembangan memiliki keterampilan di daerah tertentu, ini
mungkin di mana Anda harus fokus.
d. Kekritisan perangkat lunak dan kebutuhan non-fungsional
Untuk sistem kritis yang harus disertifikasi oleh regulator eksternal,
Anda mungkin harus membuat kasus ketergantungan untuk sistem (dibahas
dalam Bab 15). Hal ini sulit jika Anda tidak memiliki akses ke kode sumber
dari perangkat lunak. Jika perangkat lunak Anda memiliki persyaratan kinerja
yang ketat, mungkin mustahil untuk menggunakan strategi seperti
penggunaan kembali berbasis-generator, di mana Anda menghasilkan kode
dari domain representasi tertentu dapat digunakan kembali dari suatu
sistem. Sistem ini sering menghasilkan kode yang relatif tidak efisien.
e. Aplikasi domain
Dalam beberapa domain aplikasi, seperti manufaktur dan informasi
medis sistem, ada beberapa produk generik yang dapat digunakan kembali
dengan mengkonfigurasi mereka untuk situasi lokal. Jika Anda bekerja di
domain seperti itu, Anda harus selalu mempertimbangkan ini sebagai pilihan.
f. Platform yang digunakan oleh sistem akan berjalan
Beberapa model komponen, seperti NET, khusus untuk platform
Microsoft. Demikian pula, sistem aplikasi generik mungkin platform-spesifik
[Software Reuse] [2014]

Page 9 of 23

dan Anda mungkin hanya dapat menggunakan kembali ini jika sistem Anda
dirancang untuk platform yang sama.
Pendekatan yang mendukung system reuse adalah:
Pendekatan Penjelasan
Pola Arsitektural Arsitektur perangkat lunak standar
yang mendukung jenis umum dari
sistem aplikasi yang digunakan
sebagai dasar aplikasi.
Pola Desain Abstraksi generik yang terjadi di
seluruh aplikasi yang
direpresentasikan sebagai pola desain
menunjukkan objek 鈥� objek abstrak
dan objek nyata dan interaksi.
Pengembangan Component-based Sistem yang dikembangkan dengan
mengintegrasikan komponen
(kumpulan objek) yang sesuai dengan
standar komponen model.
Framework Aplikasi Kumpulan class abstrak dan konkret
disesuaikan dan diperluas untuk
membuat sistem aplikasi.
Sistem Pembukus Warisan Sistem warisan yang 'dibungkus'
dengan mendefinisikan satu set
antarmuka dan menyediakan akses ke
sistem warisan ini melalui antarmuka
ini.
Sistem yang Berorientasi pada
Layanan
Sistem yang dikembangkan dengan
menghubungkan layanan bersama,
yang dapat disediakan dari eksternal.
Jajaran Produk Perangkat Lunak Sebuah tipe aplikasi ini secara umum
meliputi arsitektur biasa sehingga
dapat disesuaikan untuk pelanggan
yang berbeda.
COTS product reuse Sistem yang dikembangkan dengan
mengkonfigurasi dan
mengintegrasikan sistem aplikasi yang
sudah ada. .
System ERP Sistem berskala besar yang
merangkum fungsi bisnis generik dan
aturan dikonfigurasi untuk sebuah
organisasi.
[Software Reuse] [2014]
Page 10 of 23

Aplikasi vertikal yang dapat

dikonfigurasi
Sistem generik dirancang sehingga
mereka dapat dikonfigurasi untuk
kebutuhan pelanggan sistem tertentu.
Library Program Kelas dan fungsi librari yang
menerapkan abstraksi umum
digunakan untuk digunakan kembali.
Model-driven engineering Software direpresentasikan sebagai
model domain dan implementasi
model independen dan kode yang
dihasilkan dari model ini.
Program generators Sebuah sistem generator yang
memiliki ilmu dari jenis aplikasi dan
digunakan untuk menghasilkan sistem
dalam domain dari pengguna
disediakan model sistem.
Pengembangan Aspect-oriented
software
Komponen bersama yang dijalin
menjadi sebuah aplikasi di tempat
yang berbeda ketika program
dikompilasi.

16.1.2 Application Frameworks

Frameworks adalah entitas cukup besar yang dapat digunakan kembali.
Frameworks berada di suatu tempat antara system dan komponen reuse.
Frameworks adalah desain sub-sistem yang terdiri dari kumpulan kelas abstrak
dan konkret dan antarmuka di antara mereka. Sub-sistem diimplementasikan
dengan menambahkan komponen untuk mengisi bagian dari desain dan dengan
instantiating class abstrak dalam frameworks.
Frameworks mendukung desain ulang bahwa mereka menyediakan
arsitektur frameworks untuk aplikasi serta penggunaan kembali kelas khusus
dalam sistem. Arsitektur didefinisikan oleh kelas objek dan interaksi mereka.
Kelas digunakan kembali secara langsung dan dapat diperpanjang menggunakan
fitur seperti pewarisan.
Bahkan, sebuah framework dapat menggabungkan beberapa framework
lainnya, di mana masing-masing dirancang untuk mendukung pengembangan
[Software Reuse] [2014]

Page 11 of 23

bagian dari aplikasi. Anda dapat menggunakan framework untuk membuat

aplikasi lengkap atau untuk melaksanakan bagian dari aplikasi, seperti antarmuka
pengguna grafis. Ada tiga kelas dari framework:
1. Framework Infrastruktur Sistem
Framework ini mendukung pengembangan infrastruktur sistem
seperti komunikasi, antarmuka pengguna, dan kompiler (Schmidt, 1997).
2. Framework Integrasi Middleware
Terdiri dari serangkaian standar dan kelas objek yang terkait yang
mendukung komunikasi komponen dan pertukaran informasi. Contoh dari
jenis framework termasuk NET Microsoft dan Enterprise Java Beans (EJB).
Framework ini memberikan dukungan untuk model komponen standar.
3. Framework Aplikasi Enterprise.
Ini berkaitan dengan domain aplikasi tertentu seperti telekomunikasi
atau sistem keuangan (Baumer, et al., 1997). Ini menanamkan aplikasi
pengetahuan domain dan mendukung pengembangan aplikasi pengguna
akhir.
Framework aplikasi web (WAFS) adalah jenis yang lebih baru dan sangat
penting dari framework. WAFS yang mendukung pembangunan website dinamis
kini banyak tersedia. Arsitektur dari WAF biasanya didasarkan pada Model-View-
Controller (MVC) pola komposit (Gamma et al., 1995).
[Software Reuse] [2014]

Page 12 of 23

Gambar 16.2. Pola Model-View-Controller

Pola MVC awalnya diusulkan pada 1980-an sebagai pendekatan untuk
desain GUI yang memungkinkan untuk beberapa presentasi dari sebuah objek
dan gaya yang terpisah dari interaksi dengan masing-masing presentasi tersebut.
Hal ini memungkinkan untuk pemisahan negara aplikasi dari antarmuka
pengguna ke aplikasi. Sebuah framework MVC mendukung penyajian data dalam
berbagai cara dan memungkinkan interaksi dengan masing-masing presentasi
tersebut. Bila data tersebut dimodifikasi melalui salah satu presentasi, model
system berubah dan pengendali yang terkait dengan setiap tampilan
memperbarui presentasi mereka.
Sebagai contoh, sebuah kerangka kerja MVC termasuk pola Observer,
pola Strategi, pola komposit, dan sejumlah orang lain. Sifat umum pola dan
penggunaan dari kelas abstrak dan konkret memungkinkan untuk diperpanjang.
Framework aplikasi web biasanya menggabungkan satu atau lebih khusus
framework yang mendukung fitur aplikasi spesifik. Meskipun masing-masing
framework meliputi fungsi yang sedikit berbeda, sebagian besar framework
aplikasi web mendukung fitur berikut:

[Software Reuse] [2014]

Page 13 of 23

1. Keamanan
WAFS mungkin termasuk kelas untuk membantu menerapkan
otentikasi pengguna (login) dan kontrol akses untuk memastikan bahwa
pengguna hanya dapat mengakses diizinkan fungsi dalam sistem.
2. halaman web dinamis
Kelas disediakan untuk membantu Anda menentukan halaman web
template dan untuk mengisi ini dinamis dengan data dari sistem database.
3. Dukungan Basis Data
Framework biasanya tidak termasuk database melainkan menganggap
bahwa database yang terpisah, seperti MySQL, akan digunakan. Framework
dapat memberikan kelas yang menyediakan antarmuka abstrak ke database
yang berbeda.
4. Manajemen Sesi
Kelas untuk membuat dan mengelola sesi (sejumlah interaksi dengan
sistem oleh pengguna) biasanya bagian dari WAF.
5. Interaksi Pengguna
Kebanyakan web framework sekarang memberikan dukungan AJAX
(Holdener, 2008), yang memungkinkan lebih halaman web interaktif yang
akan dibuat.
Framework generik dan diperluas untuk membuat aplikasi yang lebih
spesifik atau sub-sistem. Mereka menyediakan arsitektur framework untuk
sistem. Memperluas framework melibatkan dengan menambahkan kelas konkrit
yang mewarisi operasi dari kelas abstrak dalam rangka dan menambahkan
metode yang disebut dalam menanggapi peristiwa yang diakui oleh framework.
[Software Reuse] [2014]

Page 14 of 23

Masalah dengan framework ini adalah kerumitannya yang berarti bahwa

dibutuhkan waktu yang lama untuk menggunakannya secara efektif.

Gambar 16.3. Inversi Kontrol dalam Framework

Namun, framework biasanya lebih umum daripada produk software, yang
berfokus pada keluarga tertentu dari sistem aplikasi. Misalnya, Anda dapat
menggunakan framework berbasis web untuk membangun berbagai jenis
aplikasi berbasis web. Salah satunya mungkin produk software yang mendukung
meja bantuan berbasis web. 'Help desk product line' mungkin lebih khusus untuk
memberikan jenis dukungan khusus help desk.
Framework merupakan pendekatan yang efektif untuk menggunakan
kembali, tetapi mahal untuk memperkenalkan ke dalam proses pengembangan
perangkat lunak. Mereka dasarnya kompleks dan dapat memakan waktu
beberapa bulan untuk belajar menggunakannya. Ini bisa sulit dan mahal untuk
mengevaluasi framework yang tersedia untuk memilih yang paling sesuai.
Debugging aplikasi berbasis framework sulit karena Anda mungkin tidak
mengerti bagaimana metode framework berinteraksi. Ini adalah masalah umum
[Software Reuse] [2014]

Page 15 of 23

dengan software yang dapat digunakan kembali. Alat debugging dapat

memberikan informasi tentang komponen sistem reuse, yang seorang
pengembang tidak mengerti.
16.2 Jajaran Produk Perangkat Lunak
Jajaran produk perangkat lunak atau keluarga aplikasi adalah aplikasi
dengan fungsi generik yang dapat disesuaikan dan dikonfigurasi untuk digunakan
dalam konteks tertentu. Sebuah Jajaran produk perangkat lunak adalah
seperangkat aplikasi dengan arsitektur yang umum dan komponen bersama,
dengan masing-masing aplikasi khusus untuk mencerminkan kebutuhan yang
berbeda.
Jajaran produk perangkat lunak biasanya muncul dari aplikasi yang ada.
Artinya, sebuah organisasi mengembangkan aplikasi kemudian, ketika sistem
serupa diperlukan, informal menggunakan kembali kode dari ini dalam aplikasi
baru. Proses yang sama digunakan sebagai aplikasi sejenis lainnya
dikembangkan. Namun, perubahan cenderung struktur aplikasi korup demikian,
karena lebih banyak kasus baru dikembangkan, menjadi semakin sulit untuk
membuat versi baru.
Oleh karena itu, keputusan untuk merancang Jajaran produk generik
kiranya dibuat. Ini melibatkan mengidentifikasi fungsi umum dalam kasus produk
dan termasuk ini dalam aplikasi dasar, yang kemudian digunakan untuk
pengembangan di kemudian hari. . Aplikasi berbasis ini sengaja disusun untuk
menyederhanakan penggunaan kembali dan konfigurasi ulang.
Framework aplikasi dan jajaran produk perangkat lunak tentu saja
memiliki banyak kesamaan. Keduanya mendukung arsitektur dan komponen
umum, dan membutuhkan pengembangan baru untuk membuat versi tertentu
dari sistem. Perbedaan utama antara pendekatan ini adalah sebagai berikut:
[Software Reuse] [2014]

Page 16 of 23

1) Framework Aplikasi mengandalkan fitur berorientasi objek seperti

pewarisan dan polimorfisme untuk menerapkan ekstensi untuk
kerangka. Umumnya, kode framework tidak diubah dan modifikasi
yang mungkin terbatas pada apa pun yang diperbolehkan oleh
framework. jajaran produk perangkat lunak tidak selalu dibuat
menggunakan pendekatan berorientasi objek. Komponen aplikasi
berubah, dihapus, atau ditulis ulang. Tidak ada batasan, pada
prinsipnya setidaknya, untuk perubahan yang dapat dibuat.
2) Framework aplikasi yang terutama difokuskan pada penyediaan
teknis daripada dukungan spesifik domain. Misalnya, ada framework
aplikasi untuk membuat aplikasi berbasis web. Sebuah jajaran produk
software biasanya embeds domain dan platform informasi yang rinci.
Misalnya, mungkin ada jajaran produk perangkat lunak yang
bersangkutan dengan aplikasi berbasis web untuk pengelolaan
catatan kesehatan.
3) Jajaran produk perangkat lunak sering mengontrol aplikasi untuk
peralatan. Misalnya, mungkin ada jajaran produk perangkat lunak
untuk keluarga printer. Ini berarti bahwa jajaran produk harus
menyediakan dukungan untuk perangkat keras antarmuka.
framework aplikasi biasanya software-oriented dan mereka jarang
memberikan dukungan untuk perangkat keras antarmuka.
4) Jajaran produk perangkat lunak yang terdiri dari keluarga aplikasi
yang terkait, yang dimiliki oleh organisasi yang sama. Ketika Anda
membuat aplikasi baru, titik awal Anda anggota terdekat dari
keluarga aplikasi, bukan aplikasi inti generik.
Jika Anda mengembangkan jajaran produk perangkat lunak menggunakan
bahasa pemrograman berorientasi objek, maka Anda dapat menggunakan
framwork aplikasi sebagai dasar untuk sistem. Anda membuat inti dari jajaran
produk dengan memperluas framework dengan komponen tertentu
[Software Reuse] [2014]

Page 17 of 23

menggunakan mekanisme built-in versi sistem untuk pelanggan yang berbeda

diciptakan. Berbagai jenis spesialisasi jajaran produk perangkat lunak dapat
dikembangkan:
1) Spesialisasi Platform
Versi aplikasi yang dikembangkan untuk platform yang berbeda.
Sebagai contoh, versi aplikasi mungkin ada untuk Windows, Mac OS,
dan platform Linux. Dalam hal ini, fungsi aplikasi biasanya tidak
berubah; hanya komponen-komponen yang antarmuka dengan
perangkat keras dan sistem operasi yang dimodifikasi.
2) Spesialisasi Lingkungan
Versi aplikasi yang dibuat untuk menangani lingkungan kerjadan dan
perangkat periferal tertentu. Sebagai contoh, sistem untuk layanan
keadaan darurat mungkin ada dalam versi yang berbeda, tergantung
pada sistem komunikasi. Dalam hal ini, komponen sistem berubah
untuk mencerminkan fungsi peralatan komunikasi yang digunakan.

3) Spesialisasi Fungsional
Versi aplikasi diciptakan untuk pelanggan tertentu memiliki
kebutuhan yang berbeda. Sebagai contoh, sistem otomasi
perpustakaan dapat dimodifikasi tergantung pada apakah itu
digunakan di perpustakaan umum, perpustakaan referensi, atau
perpustakaan universitas. Dalam hal ini, komponen yang
melaksanakan fungsi dapat dimodifikasi dan komponen baru
ditambahkan ke sistem
4) Proses spesialisasi
Sistem ini disesuaikan untuk mengatasi proses bisnis yang spesifik.
Sebagai contoh, sistem pemesanan dapat disesuaikan untuk
mengatasi proses pemesanan terpusat dalam satu perusahaan dan
proses didistribusikan di negara lain.
[Software Reuse] [2014]

Page 18 of 23

Arsitektur dari jajaran produk perangkat lunak sering mencerminkan

aplikasi tertentu, gaya arsitektur umum atau pola Arsitektur harus disusun
sedemikian rupa untuk memisahkan sub-sistem yang berbeda dan untuk
memungkinkan mereka untuk dimodifikasi. Arsitektur juga harus memisahkan
entitas dan deskripsi mereka dan tingkat yang lebih tinggi dalam entitas sistem
akses melalui deskripsi bukan langsung.
Sistem pengiriman ini adalah contoh dari arsitektur pengelolaan sumber
daya (Gambar 16.4). Anda dapat melihat bagaimana struktur empat lapisan ini
dipakai pada Gambar 16.5, yang menunjukkan modul yang mungkin dimasukkan
dalam jajaran produk sistem pengirim. Komponen pada tiap tingkat dalam sistem
jajaran produk adalah sebagai berikut:

Gambar 16.4 arsitektur sistem alokasi sumber daya

[Software Reuse] [2014]

Page 19 of 23

Gambar 16.5 arsitektur jajaran produk dari sistem dispatcher

Komponen pada tiap tingkat dalam sistem jajaran produk adalah sebagai
berikut:
1. Pada tingkat UI, ada komponen untuk tampilan operator dan
komunikasi;
2.Di tingkat I / O manajemen, ada komponen yang menangani otentikasi,
pelaporan dan rute perencanaan;
3 Di tingkat manajemen sumber daya, ada komponen untuk lokasi
kendaraan dan pengiriman, mengelola Status kendaraan dan insiden
logging;
4. Database mencakup peralatan, kendaraan dan peta database.

[Software Reuse] [2014]

Page 20 of 23

Gambar 16.6 Produk contoh pengembangan

Gambar 16.6 menunjukkan langkah-langkah yang terlibat dalam
memperluas jajaran produk perangkat lunak untuk membuat aplikasi
baru. Langkah-langkah yang terlibat dalam proses umum ini adalah
sebagai berikut:
1) Memperoleh persyaratan pemangku kepentingan
Anda mungkin mulai dengan persyaratan proses rekayasa normal.
Namun, karena sistem sudah ada, Anda akan perlu untuk
menunjukkan sistem dan bereksperimen pemangku kepentingan
dengan itu, mengungkapkan kebutuhan mereka sebagai
modifikasi fungsi yang disediakan.
2) Pilih sistem yang sudah ada dan yang paling cocok dengan
persyaratan
Ketika membuat anggota baru dari jajaran produk, Anda bisa
mulai dengan productinstance terdekat. Persyaratan dianalisis dan
anggota keluarga yang adalah yang paling cocok dipilih untuk
modifikasi.
3) persyaratan renegosiasi
Sebagai rincian lebih lanjut dari perubahan yang diperlukan
muncul dan proyek yang direncanakan, mungkin ada beberapa
persyaratan negosiasi ulang untuk meminimalkan perubahan yang
diperlukan.
4) Beradaptasi sistem yang ada
Modul baru dikembangkan untuk sistem yang ada dan modul
sistem yang ada disesuaikan untuk memenuhi persyaratan baru.
[Software Reuse] [2014]

Page 21 of 23

5) Memberikan anggota keluarga baru

Contoh baru dari jajaran produk dikirim ke pelanggan. Pada tahap
ini, Anda harus mendokumentasikan fitur utamanya sehingga
mungkin digunakan sebagai dasar untuk pengembangan sistem
lain di masa depan.
Lini produk perangkat lunak yang dirancang untuk dikonfigurasi ulang dan
konfigurasi ini mungkin melibatkan menambahkan atau menghapus komponen
dari sistem, mendefinisikan parameter dan kendala untuk komponen sistem, dan
termasuk pengetahuan tentang proses bisnis. Konfigurasi ini dapat terjadi pada
berbagai tahap dalam proses pembangunan:
1. Konfigurasi desain waktu
Organisasi yang mengembangkan perangkat lunak dapat memodifikasi
produk umum secara garis inti dengan mengembangkan, memilih, atau
mengadaptasi komponen untuk menciptakan sistem baru untuk
pelanggan.
2. Konfigurasi penyebaran waktu
Sebuah sistem generik dirancang untuk konfigurasi oleh pelanggan atau
konsultan yang bekerja dengan pelanggan. Pengetahuan tentang
kebutuhan spesifik pelanggan dan lingkungan operasi sistem tertanam
dalam satu set file konfigurasi yang digunakan oleh sistem generik.
Ketika sistem dikonfigurasi pada saat desain, pemasok dimulai dengan
baik sistem generik atau contoh produk yang sudah ada. Dengan memodifikasi
dan memperluas modul pada sistem ini, mereka menciptakan sistem khusus
yang memberikan fungsionalitas pelanggan yang diperlukan. Hal ini biasanya
melibatkan perubahan dan memperluas kode program dari sistem sehingga
fleksibilitas yang lebih besar mungkin dibandingkan dengan konfigurasi
penyebaran waktu.
[Software Reuse] [2014]

Page 22 of 23

Gambar 16.7 Konfigurasi penyebaran-waktu

Konfigurasi penyebaran waktu melibatkan menggunakan alat konfigurasi
untuk membuat suatu konfigurasi sistem tertentu yang tercatat dalam database
dikonfigurasi atau sebagai set file konfigurasi (Gambar 16.7). Sistem akan
mengeksekusi untuk berkonsultasi dengan database ketika menjalankan
sehingga fungsinya dapat khusus untuk konteks pelaksanaannya.
Ada beberapa tingkat konfigurasi penyebaran waktu yang dapat diberikan dalam
suatu sistem:
1. Komponen seleksi, di mana Anda memilih modul dalam suatu sistem
yang menyediakan fungsionalitas yang diperlukan. Misalnya, dalam
sistem informasi pasien, Anda dapat memilih komponen manajemen
gambar yang memungkinkan Anda untuk menghubungkan gambar
medis (x-ray, CT scan, dll) untuk rekam medis pasien.
2. Workflow dan aturan definisi, di mana Anda menentukan alur kerja
(bagaimana informasi diproses, tahap demi tahap) dan aturan
validasi yang harus berlaku untuk informasi yang dimasukkan oleh
pengguna atau yang dihasilkan oleh sistem.
[Software Reuse] [2014]

Page 23 of 23

3. Definisi Parameter, di mana Anda menentukan nilai-nilai parameter

sistem tertentu yang mencerminkan contoh aplikasi yang Anda
ciptakan. Misalnya, Anda dapat menentukan panjang maksimum
kolom untuk data input oleh pengguna atau karakteristik perangkat
keras yang melekat pada sistem.