MODUL REKAYASA PERANGKAT LUNAK

(CMC 102)

MODUL PERTEMUAN 02
PROSES PEMBANGUNAN PERANGKAT LUNAK
(SOFTWARE PROCESS)

DISUSUN OLEH
Dr. Fransiskus Adikara, S.Kom, MMSI

UNIVERSITAS ESA UNGGUL

2020

Universitas Esa Unggul

http://esaunggul.ac.id
0 / 17
 PENGANTAR MODEL PROSES PEMBANGUNAN
PERANGKAT LUNAK

A. Kemampuan Akhir Yang Diharapkan

Setelah mempelajari modul ini, diharapkan mahasiswa mampu :

1. Memahami tahapan proses perangkat lunak;
2. Memahami konsep dasar beberapa model proses perangkat lunak;
3. Memahami kegunaan dari proses perangkat lunak;

B. Uraian dan Contoh

Proses perangkat lunak adalah serangkaian kegiatan terkait yang

mengarah pada produksi perangkat lunak produk. Kegiatan ini mungkin
melibatkan pengembangan perangkat lunak dari awal dalam bahasa
pemrograman standar seperti Java atau C. Namun, aplikasi bisnis belum
tentu dikembangkan dengan cara ini. Perangkat lunak bisnis baru sekarang
sering dikembangkan dengan memperluas dan memodifikasi sistem yang
ada atau dengan mengkonfigurasi dan mengintegrasikan perangkat lunak
atau komponen sistem yang tidak tersedia.
Ada banyak proses perangkat lunak yang berbeda tetapi semua harus
mencakup empat kegiatan yang mendasar untuk rekayasa perangkat lunak:
1. Spesifikasi perangkat lunak Fungsi perangkat lunak dan batasan-
batasannya operasi harus ditentukan.
2. Desain dan implementasi perangkat lunak Perangkat lunak untuk
memenuhi spesifikasi harus diproduksi.
3. Validasi perangkat lunak Perangkat lunak harus divalidasi untuk
memastikan bahwa ia melakukan apa yang diinginkan pelanggan.
4. Evolusi perangkat lunak Perangkat lunak harus berevolusi untuk
memenuhi perubahan kebutuhan pelanggan.

Universitas Esa Unggul

http://esaunggul.ac.id
1 / 17
 Dalam beberapa bentuk, kegiatan ini adalah bagian dari semua proses
perangkat lunak. Dalam praktiknya, dari tentu saja, mereka adalah kegiatan
yang kompleks dalam diri mereka sendiri dan termasuk sub kegiatan seperti
validasi persyaratan, desain arsitektur, pengujian unit, dll. Ada juga yang
mendukung proses kegiatan seperti dokumentasi dan manajemen
konfigurasi perangkat lunak.
Ketika kami menggambarkan dan mendiskusikan proses, kami biasanya
berbicara tentang kegiatan di proses-proses ini seperti menentukan model
data, mendesain antarmuka pengguna, dll., dan pemesanan kegiatan ini.
Namun, seperti halnya kegiatan, proses deskripsi mungkin juga termasuk:
1. Produk, yang merupakan hasil dari suatu kegiatan proses. Misalnya
saja hasilnya dari aktivitas desain arsitektur dapat menjadi model
perangkat lunak Arsitektur.
2. Peran, yang mencerminkan tanggung jawab orang-orang yang
terlibat dalam proses. Contoh peran adalah manajer proyek,
manajer konfigurasi, pemrogram, dll.
3. Pra dan pasca kondisi, yaitu pernyataan yang benar sebelum dan
sesudah aktivitas proses telah diberlakukan atau produk yang
diproduksi. Misalnya, sebelumnya desain arsitektur dimulai, pra-
kondisi mungkin semua persyaratan miliki telah disetujui oleh
pelanggan; setelah kegiatan ini selesai, post-condition mungkin
model UML yang menggambarkan arsitektur telah ditinjau.
Proses perangkat lunak itu kompleks dan, seperti semua proses
intelektual dan kreatif, mengandalkan orang-orang yang membuat
keputusan dan penilaian. Tidak ada proses yang ideal dan sebagian besar
organisasi telah mengembangkan proses pengembangan perangkat lunak
mereka sendiri. Proses telah berevolusi untuk mengambil keuntungan dari
kemampuan orang-orang dalam suatu organisasi dan karakteristik khusus
dari sistem yang sedang dikembangkan. Untuk beberapa sistem, seperti
sistem kritis, proses pengembangan yang sangat terstruktur diperlukan.
Untuk sistem bisnis, dengan persyaratan yang berubah dengan cepat, yang
kurang formal, fleksibel proses cenderung lebih efektif.

Universitas Esa Unggul

http://esaunggul.ac.id
2 / 17
 Terkadang, proses perangkat lunak dikategorikan sebagai rencana-
driven atau gesit proses. Perencanaan proses didorong adalah proses di
mana semua kegiatan proses berada direncanakan sebelumnya dan
kemajuan diukur terhadap rencana ini. Dalam proses tangkas, yang saya
bahas di Bab 3, perencanaan bersifat inkremental dan lebih mudah untuk
mengubah proses untuk mencerminkan perubahan kebutuhan pelanggan. As
Boehm and Turner (2003) membahas, setiap pendekatan cocok untuk
berbagai jenis perangkat lunak. Secara umum, Anda perlu menemukan
keseimbangan antara proses yang digerakkan oleh rencana dan lincah.
Meskipun tidak ada proses perangkat lunak 'ideal', ada ruang untuk
meningkatkannya proses perangkat lunak di banyak organisasi. Proses dapat
mencakup teknik yang sudah ketinggalan zaman atau mungkin tidak
memanfaatkan praktik terbaik dalam rekayasa perangkat lunak industri.
Memang, banyak organisasi masih tidak memanfaatkan rekayasa perangkat
lunak metode dalam pengembangan perangkat lunak mereka.
Proses perangkat lunak dapat ditingkatkan dengan standarisasi proses di
mana keragaman dalam proses perangkat lunak di seluruh organisasi
berkurang. Ini mengarah pada peningkatan komunikasi dan pengurangan
waktu pelatihan, dan membuat dukungan proses otomatis lebih ekonomis.
Standardisasi juga merupakan langkah pertama yang penting dalam
memperkenalkan metode dan teknik rekayasa perangkat lunak baru dan
rekayasa perangkat lunak yang baik praktek. Saya membahas peningkatan
proses perangkat lunak secara lebih rinci di Bab 26.
Seperti yang saya jelaskan di Bab 1, model proses perangkat lunak
adalah representasi yang disederhanakan dari proses perangkat lunak. Setiap
model proses mewakili proses dari perspektif tertentu, dan dengan demikian
hanya menyediakan informasi parsial tentang proses itu. Sebagai contoh,
model aktivitas proses menunjukkan aktivitas dan urutannya tetapi mungkin
tidak ditampilkan peran orang-orang yang terlibat dalam kegiatan ini. Di
bagian ini, saya memperkenalkan nomor model proses yang sangat umum
(kadang-kadang disebut 'paradigma proses') dan menyajikan ini dari

Universitas Esa Unggul

http://esaunggul.ac.id
3 / 17
 perspektif arsitektur. Artinya, kita melihat kerangka kerja proses tetapi tidak
rincian kegiatan spesifik.
Model generik ini bukan deskripsi pasti dari proses perangkat lunak.
Agak, mereka adalah abstraksi dari proses yang dapat digunakan untuk
menjelaskan berbagai pendekatan pengembangan perangkat lunak. Anda
bisa menganggapnya sebagai kerangka proses yang mungkin diperluas dan
disesuaikan untuk menciptakan proses rekayasa perangkat lunak yang lebih
spesifik.
Model proses yang saya bahas di sini adalah:
1. Model air terjun Ini mengambil kegiatan proses spesifikasi dasar,
pengembangan, validasi, dan evolusi dan merepresentasikannya
sebagai terpisah fase proses seperti spesifikasi kebutuhan, desain
perangkat lunak, implementasi, pengujian, dan sebagainya.
2. Pengembangan inkremental. Pendekatan ini menghubungkan
kegiatan spesifikasi, pengembangan, dan validasi. Sistem ini
dikembangkan sebagai serangkaian versi (increments), dengan
setiap versi menambahkan fungsionalitas ke versi sebelumnya.
3. Rekayasa perangkat lunak berorientasi reuse. Pendekatan ini
didasarkan pada keberadaan sejumlah besar komponen yang dapat
digunakan kembali. Proses pengembangan sistem berfokus pada
pengintegrasian komponen-komponen ini ke dalam sistem daripada
mengembangkan mereka dari awal.
Model-model ini tidak saling eksklusif dan sering digunakan bersama,
terutama untuk pengembangan sistem besar. Untuk sistem besar, masuk
akal untuk menggabungkan beberapa fitur terbaik dari air terjun dan model
pengembangan tambahan. Kamu perlu memiliki informasi tentang
persyaratan sistem penting untuk merancang perangkat lunak arsitektur
untuk mendukung persyaratan ini. Anda tidak dapat mengembangkan ini
secara bertahap.
Sub-sistem dalam sistem yang lebih besar dapat dikembangkan dengan
menggunakan perbedaan pendekatan. Bagian dari sistem yang dipahami
dengan baik dapat ditentukan dan dikembangkan menggunakan proses

Universitas Esa Unggul

http://esaunggul.ac.id
4 / 17
 berbasis air terjun. Bagian dari sistem yang sulit tentukan terlebih dahulu,
seperti antarmuka pengguna, harus selalu dikembangkan menggunakan
pendekatan inkremental.

C. Latihan
1. Jelaskan apa itu proses perangkat lunak ?
2. Deskripsi proses termasuk apa saja ?

D. Kunci Jawaban
1. Model proses perangkat lunak adalah representasi yang
disederhanakan dari proses perangkat lunak.

2. Produk, Peran, Kondisi Sebelum dan Sesudah aktivitas.

Universitas Esa Unggul

http://esaunggul.ac.id
5 / 17
 MODEL PROSES PEMBANGUNAN PERANGKAT LUNAK

A. Kemampuan Akhir Yang Diharapkan

Setelah mempelajari modul ini, diharapkan mahasiswa mampu :
1. Memahami beberapa jenis model perangkat lunak;
2. Memahami model air terjun, model inkremental, dan rekayasa
perangkat lunak berorientasi menggunakan ulang;
3. Memahami kekurangan dan kelebihan masing-masing model proses
model;

B. Uraian dan Contoh

1. Model Air Terjun (Waterfall Model)

Model publikasi pertama dari proses pengembangan perangkat lunak
berasal dari proses rekayasa sistem yang lebih umum (Royce, 1970). Model
ini diilustrasikan pada Gambar 2.1. Karena kaskade dari satu fase ke fase
lain, model ini dikenal sebagai 'model air terjun' atau siklus hidup perangkat
lunak. Model air terjun adalah contoh dari proses yang digerakkan oleh
rencana — pada prinsipnya, Anda harus merencanakan dan menjadwalkan
semua proses kegiatan sebelum mulai bekerja pada mereka.
Tahap-tahap utama dari model air terjun secara langsung
mencerminkan perkembangan mendasar kegiatan:
1. Analisis dan definisi persyaratan Layanan, kendala, dan tujuan
ditetapkan dengan berkonsultasi dengan pengguna sistem. Mereka
kemudian didefinisikan secara terperinci dan berfungsi sebagai
spesifikasi sistem.
2. Desain sistem dan perangkat lunak Proses desain sistem
mengalokasikan persyaratan untuk sistem perangkat keras atau
perangkat lunak dengan membangun sistem secara keseluruhan
Arsitektur. Desain perangkat lunak melibatkan pengidentifikasian
dan penggambaran yang mendasar abstraksi sistem perangkat
lunak dan hubungannya.

Universitas Esa Unggul

http://esaunggul.ac.id
6 / 17
 3. Implementasi dan pengujian unit Selama tahap ini, desain
perangkat lunak direalisasikan sebagai seperangkat program atau
unit program. Pengujian unit melibatkan memverifikasi itu setiap
unit memenuhi spesifikasinya.
4. Integrasi dan pengujian sistem Unit atau unit program individual
terintegrasi dan diuji sebagai sistem yang lengkap untuk
memastikan bahwa perangkat lunak persyaratan telah terpenuhi.
Setelah pengujian, sistem perangkat lunak dikirim ke pelanggan.
5. Operasi dan pemeliharaan Biasanya (walaupun tidak harus), ini
adalah fase siklus hidup terpanjang. Sistem diinstal dan digunakan
secara praktis. Pemeliharaan melibatkan koreksi kesalahan yang
tidak ditemukan sebelumnya tahap siklus hidup, meningkatkan
implementasi unit sistem dan meningkatkan layanan sistem ketika
persyaratan baru ditemukan.

Gambar xxx
Pada prinsipnya, hasil dari setiap fase adalah satu atau lebih dokumen
yang disetujui (‘Ditandatangani’). Fase berikut tidak boleh dimulai sampai
fase sebelumnya selesai. Dalam praktiknya, tahapan-tahapan ini saling
tumpang tindih dan saling memberi informasi. Selama desain, masalah
dengan persyaratan diidentifikasi. Selama pengkodean, masalah desain
ditemukan dan seterusnya. Proses perangkat lunak bukanlah model linier

Universitas Esa Unggul

http://esaunggul.ac.id
7 / 17
 sederhana tetapi melibatkan umpan balik dari satu fase ke fase lainnya.
Dokumen yang diproduksi di setiap fase mungkin harus dimodifikasi untuk
mencerminkan perubahan yang dilakukan.
Karena biaya memproduksi dan menyetujui dokumen, iterasi dapat
dilakukan mahal dan melibatkan pengerjaan ulang yang signifikan. Oleh
karena itu, setelah sejumlah kecil iterasi, itu normal untuk membekukan
bagian dari pengembangan, seperti spesifikasi, dan untuk melanjutkan
dengan tahap pengembangan selanjutnya. Masalah dibiarkan untuk resolusi
nanti, diabaikan, atau diprogram di sekitar. Pembekuan persyaratan prematur
ini mungkin berarti bahwa sistem tidak akan melakukan apa yang diinginkan
pengguna. Ini juga dapat menyebabkan struktur yang buruk sistem sebagai
masalah desain diatasi dengan trik implementasi.
Selama fase siklus hidup akhir (operasi dan pemeliharaan) perangkat
lunak diletakkan mulai digunakan. Kesalahan dan kelalaian dalam
persyaratan perangkat lunak asli ditemukan. Kesalahan program dan desain
muncul dan kebutuhan akan fungsionalitas baru diidentifikasi. Karena itu
sistem harus berkembang agar tetap berguna. Membuat perubahan ini
(perangkat lunak pemeliharaan) dapat melibatkan pengulangan tahapan
proses sebelumnya.
Model air terjun konsisten dengan model proses dokumentasi dan
dokumentasi lainnya diproduksi pada setiap fase. Ini membuat prosesnya
terlihat sehingga manajer bisa memantau kemajuan terhadap rencana
pembangunan. Masalah utamanya adalah partisi yang tidak fleksibel proyek
ke dalam tahapan yang berbeda. Komitmen harus dibuat pada tahap awal
dalam proses, yang membuatnya sulit untuk menanggapi perubahan
kebutuhan pelanggan.
Pada prinsipnya, model air terjun hanya boleh digunakan ketika
persyaratannya dipahami dengan baik dan tidak mungkin berubah secara
radikal selama pengembangan sistem. Namun, model air terjun
mencerminkan jenis proses yang digunakan dalam rekayasa lainnya proyek.
Karena lebih mudah untuk menggunakan model manajemen umum untuk

Universitas Esa Unggul

http://esaunggul.ac.id
8 / 17
 seluruh proyek, proses perangkat lunak berdasarkan model air terjun masih
umum digunakan.
Varian penting dari model air terjun adalah pengembangan sistem
formal, di mana model matematika dari spesifikasi sistem dibuat. Model ini
kemudian disempurnakan, menggunakan transformasi matematika yang
menjaga konsistensinya, menjadi dieksekusi kode. Berdasarkan asumsi
bahwa transformasi matematis Anda benar, karena itu Anda dapat membuat
argumen yang kuat bahwa program dihasilkan dalam hal ini cara konsisten
dengan spesifikasinya.
Proses pengembangan formal, seperti yang didasarkan pada metode B
(Schneider, 2001; Wordsworth, 1996) sangat cocok untuk pengembangan
sistem itu memiliki persyaratan keselamatan, keandalan, atau keamanan
yang ketat. Pendekatan formal disederhanakan produksi kasus keselamatan
atau keamanan. Ini menunjukkan kepada pelanggan atau regulator bahwa
sistem sebenarnya memenuhi persyaratan keselamatan atau keamanannya.
Proses yang didasarkan pada transformasi formal umumnya hanya
digunakan dalam pengembangan sistem keamanan-kritis atau keamanan-
kritis. Mereka membutuhkan spesialisasi keahlian. Untuk sebagian besar
sistem, proses ini tidak menawarkan manfaat biaya yang signifikan atas
pendekatan lain untuk pengembangan sistem.

2. Model Pembangunan Inkremental

Pengembangan tambahan didasarkan pada gagasan untuk
mengembangkan implementasi awal, memaparkan ini ke komentar
pengguna dan mengembangkannya melalui beberapa versi hingga sistem
yang memadai telah dikembangkan (Gambar 2.2). Kegiatan spesifikasi,
pengembangan, dan validasi disisipkan alih-alih terpisah, dengan umpan
balik yang cepat kegiatan.
Pengembangan perangkat lunak tambahan, yang merupakan bagian
mendasar dari gesit pendekatan, lebih baik daripada pendekatan air terjun
untuk sebagian besar bisnis, e-commerce, dan sistem pribadi.
Pengembangan tambahan mencerminkan cara kita memecahkan masalah.

Universitas Esa Unggul

http://esaunggul.ac.id
9 / 17
 Kami jarang mencari solusi masalah yang lengkap di muka tetapi bergerak
maju solusi dalam serangkaian langkah, mundur ketika kita menyadari
bahwa kita telah membuat kesalahan. Dengan mengembangkan perangkat
lunak secara bertahap, lebih murah dan mudah dibuat perubahan dalam
perangkat lunak yang sedang dikembangkan.

Setiap kenaikan atau versi sistem menggabungkan beberapa fungsi

yang dibutuhkan oleh pelanggan. Secara umum, peningkatan awal sistem
termasuk fungsionalitas yang paling penting atau paling mendesak
dibutuhkan. Ini berarti bahwa pelanggan dapat mengevaluasi sistem pada
tahap yang relatif awal dalam pengembangan untuk melihat jika
memberikan apa yang diperlukan. Jika tidak, maka hanya kenaikan saat ini
yang harus dilakukan diubah dan, mungkin, fungsionalitas baru yang
ditentukan untuk peningkatan selanjutnya.
Pengembangan tambahan memiliki tiga manfaat penting, dibandingkan
dengan air terjun model:
1. Biaya mengakomodasi perubahan kebutuhan pelanggan berkurang.
Itu jumlah analisis dan dokumentasi yang harus diperbaiki jauh
lebih sedikit daripada yang ada diperlukan dengan model air terjun.
2. Lebih mudah untuk mendapatkan umpan balik pelanggan pada
pekerjaan pengembangan yang telah dilakukan selesai Pelanggan
dapat mengomentari demonstrasi perangkat lunak dan melihat

Universitas Esa Unggul

http://esaunggul.ac.id
10 / 17
 caranya banyak yang telah dilaksanakan. Pelanggan merasa sulit
untuk menilai kemajuan dari dokumen desain perangkat lunak.
3. Pengiriman lebih cepat dan penyebaran perangkat lunak yang
bermanfaat kepada pelanggan adalah mungkin, bahkan jika semua
fungsi belum dimasukkan. Pelanggan bisa gunakan dan dapatkan
nilai dari perangkat lunak lebih awal dari yang dimungkinkan
dengan air terjun proses.
Pengembangan inkremental dalam beberapa bentuk sekarang adalah
pendekatan yang paling umum untuk pengembangan sistem aplikasi.
Pendekatan ini dapat berupa rencana-didorong, gesit, atau, lebih biasanya,
campuran dari pendekatan ini. Dalam pendekatan yang digerakkan oleh
rencana, sistem kenaikan diidentifikasi terlebih dahulu; jika pendekatan
tangkas diadopsi, kenaikan awal diidentifikasi tetapi pengembangan
kenaikan selanjutnya tergantung pada kemajuan dan prioritas pelanggan.
Dari perspektif manajemen, pendekatan inkremental memiliki dua
masalah:
1. Prosesnya tidak terlihat. Manajer perlu kiriman reguler untuk
diukur kemajuan. Jika sistem dikembangkan dengan cepat, itu
tidak hemat biaya untuk diproduksi dokumen yang mencerminkan
setiap versi sistem.
2. Struktur sistem cenderung menurun ketika penambahan baru
ditambahkan. Kecuali waktu dan uang dihabiskan untuk
refactoring untuk meningkatkan perangkat lunak, perubahan biasa
cenderung merusak strukturnya. Menggabungkan lebih banyak
perubahan perangkat lunak menjadi semakin sulit dan mahal.
Masalah perkembangan inkremental menjadi sangat akut untuk
sebagian besar, kompleks, sistem tahan lama, di mana tim yang berbeda
mengembangkan bagian yang berbeda dari sistem. Sistem besar
membutuhkan kerangka kerja yang stabil atau arsitektur dan tanggung jawab
dari berbagai tim yang bekerja pada bagian-bagian sistem perlu
didefinisikan dengan jelas sehubungan dengan arsitektur itu. Ini harus
direncanakan terlebih dahulu daripada dikembangkan secara bertahap.

Universitas Esa Unggul

http://esaunggul.ac.id
11 / 17
 Anda dapat mengembangkan sistem secara bertahap dan
memaparkannya kepada pelanggan untuk dikomentari, tanpa benar-benar
mengirimkannya dan menyebarkannya di lingkungan pelanggan. Pengiriman
dan penyebaran tambahan berarti bahwa perangkat lunak digunakan secara
nyata dan operasional proses. Ini tidak selalu mungkin karena percobaan
dengan perangkat lunak baru dapat mengganggu proses bisnis normal. Saya
membahas kelebihan dan kekurangan incremental pengiriman dalam Bagian
2.3.2.

3. Reuse Software Engineering

Di sebagian besar proyek perangkat lunak, ada beberapa perangkat
lunak yang digunakan kembali. Ini sering terjadi informal ketika orang yang
bekerja di proyek mengetahui desain atau kode yang ada mirip dengan apa
yang dibutuhkan. Mereka mencari ini, memodifikasinya sesuai kebutuhan,
dan menggabungkan mereka ke dalam sistem mereka.
Penggunaan kembali secara informal ini terjadi terlepas dari proses
pembangunan yang ada bekas. Namun, pada abad ke-21, proses
pengembangan perangkat lunak yang berfokus pada penggunaan kembali
perangkat lunak yang ada telah menjadi banyak digunakan. Pendekatan
berorientasi reuse mengandalkan pada basis besar komponen perangkat
lunak yang dapat digunakan kembali dan kerangka kerja integrasi untuk
komposisi komponen-komponen ini. Terkadang, komponen-komponen ini
adalah sistem hak mereka sendiri (COTS atau sistem komersial yang
tersedia) yang mungkin menyediakan spesifik fungsionalitas seperti
pengolah kata atau spreadsheet.
Model proses umum untuk pengembangan berbasis penggunaan ulang
ditunjukkan pada Gambar 2.3.Meskipun tahap spesifikasi persyaratan awal
dan tahap validasi adalah sebanding dengan proses perangkat lunak lain,
tahap-tahap menengah dalam reuseoriented prosesnya berbeda. Tahapan-
tahapan ini adalah:
1. Analisis komponen Dengan spesifikasi persyaratan, pencarian
dilakukan komponen untuk mengimplementasikan spesifikasi itu.

Universitas Esa Unggul

http://esaunggul.ac.id
12 / 17
 Biasanya, tidak ada kecocokan persis dan komponen yang dapat
digunakan hanya menyediakan beberapa fungsi yang diperlukan.
2. Persyaratan modifikasi Selama tahap ini, persyaratan dianalisis
menggunakan informasi tentang komponen yang telah ditemukan.
Mereka kemudian dimodifikasi untuk mencerminkan komponen
yang tersedia. Di mana modifikasi tidak mungkin, the aktivitas
analisis komponen dapat dimasukkan kembali untuk mencari solusi
alternatif.
3. Desain sistem dengan menggunakan kembali Selama fase ini,
kerangka kerja sistem adalah dirancang atau kerangka kerja yang
ada digunakan kembali. Para desainer memperhitungkan
komponen yang digunakan kembali dan mengatur kerangka kerja
untuk memenuhi ini. Beberapa perangkat lunak baru mungkin
harus dirancang jika komponen yang dapat digunakan kembali
tidak tersedia.
4. Pengembangan dan integrasi Perangkat Lunak yang tidak dapat
diperoleh secara eksternal adalah dikembangkan, dan komponen
dan sistem COTS terintegrasi untuk membuat sistem baru.
Integrasi sistem, dalam model ini, dapat menjadi bagian dari
pengembangan proses daripada kegiatan yang terpisah.

Ada tiga jenis komponen perangkat lunak yang dapat digunakan dalam
berorientasi ulang proses:
1. Layanan web yang dikembangkan sesuai dengan standar layanan
dan yang mana tersedia untuk doa jarak jauh.
2. Koleksi objek yang dikembangkan sebagai paket untuk
diintegrasikan dengan kerangka kerja komponen seperti .NET atau
J2EE.

Universitas Esa Unggul

http://esaunggul.ac.id
13 / 17
 3. Sistem perangkat lunak yang berdiri sendiri yang dikonfigurasikan
untuk digunakan secara khusus lingkungan Hidup.
Rekayasa perangkat lunak berorientasi reuse memiliki keuntungan
yang jelas dari pengurangan jumlah perangkat lunak yang akan
dikembangkan sehingga mengurangi biaya dan risiko. Biasanya juga begitu
mengarah pada pengiriman perangkat lunak yang lebih cepat. Namun,
kompromi persyaratan adalah tak terhindarkan dan ini dapat mengarah pada
sistem yang tidak memenuhi kebutuhan nyata pengguna.
Selain itu, beberapa kontrol atas evolusi sistem hilang sebagai versi
baru dari komponen yang dapat digunakan kembali tidak di bawah kendali
organisasi yang menggunakannya. Penggunaan kembali perangkat lunak
sangat penting dan saya telah mendedikasikan beberapa bab dalam bab
ketiga bagian dari buku untuk topik ini. Masalah umum penggunaan kembali
perangkat lunak dan penggunaan ulang COTS adalah dibahas dalam Bab 16,
rekayasa perangkat lunak berbasis-komponen pada Bab 17 dan 18, dan
sistem yang berorientasi layanan di Bab 19.

C. Latihan

1. Mengapa rekayasa perangkat lunak reuse digunakan?

2. Apa ciri khas pembangunan perangkat lunak secara incremental ?

D. Kunci Jawaban

1. Rekayasa perangkat lunak berorientasi reuse memiliki keuntungan

yang jelas dari pengurangan jumlah perangkat lunak yang akan
dikembangkan sehingga mengurangi biaya dan risiko.

2. Ciri khas pembangun incremental adalah :

i. Perangkat lunak dikembangkan secara bertahap.
ii. Pengguna terlibat langsung dalam proses tes sistem.

Universitas Esa Unggul

http://esaunggul.ac.id
14 / 17
 iii. Terdiri dari beberapa versi.

E. Daftar Pustaka

1. Beck, K. (1999). ‘Embracing Change with Extreme Programming’.

IEEE Computer, 32 (10), 70–8.
2. Crabtree, A. (2003). Designing Collaborative Systems: A Practical
Guide to Ethnography. London: Springer-Verlag.
3. Davis, A. M. (1993). Software Requirements: Objects, Functions and
States. Englewood Cliffs, NJ: Prentice Hall.
4. IEEE. (1998). ‘IEEE Recommended Practice for Software
Requirements Specifications’. In IEEE Software Engineering
Standards Collection. Los Alamitos, Ca.: IEEE Computer Society
Press.
5. Jacobson, I., Christerson, M., Jonsson, P. and Overgaard, G. (1993).
Object-Oriented Software Engineering. Wokingham: Addison-Wesley.
6. Kotonya, G. and Sommerville, I. (1998). Requirements Engineering:
Processes and Techniques. Chichester, UK: John Wiley and Sons.
7. Larman, C. (2002). Applying UML and Patterns: An Introduction to
Object-oriented Analysis and Design and the Unified Process.
Englewood Cliff, NJ: Prentice Hall.
8. Martin, D., Rodden, T., Rouncefield, M., Sommerville, I. and Viller, S.
(2001). ‘Finding Patterns in the Fieldwork’. Proc. ECSCW’01. Bonn:
Kluwer. 39–58.
9. Martin, D., Rouncefield, M. and Sommerville, I. (2002). ‘Applying
patterns of interaction to work (re)design: E-government and planning’.
Proc. ACM CHI’2002, ACM Press. 235–42.
10. Martin, D. and Sommerville, I. (2004). ‘Patterns of interaction:
Linking ethnomethodology and design’. ACM Trans. on Computer-
Human Interaction, 11 (1), 59–89.
11. Robertson, S. and Robertson, J. (1999). Mastering the Requirements
Process. Harlow, UK: Addison-Wesley.

Universitas Esa Unggul

http://esaunggul.ac.id
15 / 17
 12. Sommerville, I., Rodden, T., Sawyer, P., Bentley, R. and Twidale, M.
(1993). ‘Integrating ethnography into the requirements engineering
process’. Proc. RE’93, San Diego CA.: IEEE Computer Society Press.
165–73.
13. Stevens, P. and Pooley, R. (2006). Using UML: Software Engineering
with Objects and Components, 2nd ed. Harlow, UK: Addison Wesley.
14. Suchman, L. (1987). Plans and Situated Actions. Cambridge:
Cambridge University Press.
15. Viller, S. and Sommerville, I. (1999). ‘Coherence: An Approach to
Representing Ethnographic Analyses in Systems Design’. Human-
Computer Interaction, 14 (1 & 2), 9–41.
16. Viller, S. and Sommerville, I. (2000). ‘Ethnographically informed
analysis for software engineers’. Int. J. of Human-Computer Studies,
53 (1), 169–96.

Universitas Esa Unggul

http://esaunggul.ac.id
16 / 17