REKAYASA PERANGKAT LUNAK
(RPL)
1. Pengertian
Rekayasa Perangkat Lunak (RPL)
Suatu Perangkat Lunak menjadi
kebutuhan manusia dengan berbagai bagian disiplin ilmu yang dibidangi setiap
tenaga profesionalnya, menjadi bagian penting yang melatarbelakangi tumbuhnya
perkembangan perangkat lunak dengan berbagai krisis perangkat lunak menurut
berbagai sisi pandang konsumen, manajer dan pengembang/praktisi.
Rekayasa
Perangkat Lunak berasal dari 2 kata yakni Rekayasa dan Perangkat Lunak.
Rekayasa Perangkat Lunak merupakan perihal kegiatan yang kreatif dan sistematis
berdasar suatu disiplin ilmu yang membangun suatu perangkat lunak berdasar
suatu aspek masalah tertentu.
Dalam
Rekayasa Perangkat Lunak dilakukan Proses Perangkat Lunak dengan menggunakan
model Proses yang merupakan Daur Hidup Rekayasa Perangkat Lunak. Model Proses
ini terdiri dari beberapa karakteristik pendekatan proses. Dalam Proses
pembangunan Perangkat Lunak perlu diketahui Biaya yang dikeluarkan.
Istilah
Rekayasa Perangkat Lunak (RPL) secara umum disepakati sebagai terjemahan dari
istilah Software Engineering. Istilah Software Engineering mulai dipopulerkan tahun
1968 pada Software Engineering Conference yang diselenggarakan oleh NATO.
Sebagian orang mengartikan RPL hanya sebatas pada bagaimana membuat program
komputer. Padahal ada perbedaan yang mendasar antara perangkat lunak (software)
dan program komputer.
Perangkat lunak adalah seluruh perintah yang digunakan
untuk memproses informasi. Perangkat lunak dapat berupa program atau prosedur.
Program adalah kumpulan perintah yang
dimengerti oleh komputer sedangkan
prosedur adalah perintah yang dibutuhkan oleh
pengguna dalam memproses informasi. (O’Brien, 1999).
Pengertian RPL sendiri adalah Suatu disiplin ilmu yang membahas semua
aspek produksi perangkat lunak, mulai dari tahap awal yaitu analisa kebutuhan
pengguna, menentukan spesifikasi dari kebutuhan pengguna, disain, pengkodean,
pengujian sampai pemeliharaan sistem setelah digunakan.
RPL tidak hanya berhubungan dengan
cara pembuatan program komputer. Pernyataan “semua aspek produksi” pada pengertian
di atas, mempunyai arti semua hal yang berhubungan dengan proses produksi
seperti manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal,
kualitas sampai dengan pelatihan pengguna merupakan bagian dari RPL.
2. Tujuan
Atau Pentingnya Rekayasa Perangkat Lunak (RPL)
Secara umum
tujuan RPL tidak berbeda dengan bidang rekayasa yang lain. Hal ini
dapat kita lihat pada Gambar di bawah ini.
Bidang rekayasa
akan selalu berusaha menghasilkan output yang kinerjanya tinggi, biaya rendah
dan waktu penyelesaian yang tepat. Secara leboih khusus kita dapat menyatakan
tujuan RPL adalah:
a.
memperoleh biaya produksi perangkat lunak yang rendah
b.
menghasilkan pereangkat lunak yang kinerjanya tinggi,
andal dan tepat waktu
c.
menghasilkan perangkat lunak yang dapat bekerja pada
berbagai jenis platform
d.
menghasilkan perangkat lunak yang biaya perawatannya
rendah
Di
samping tujuan di atas, adapun tujuan yang lain dari Rekayasa Perangkat Lunak
(RPL), yaitu :
1. Meningkatkan keakuratan, performance &
efficiency produk secara keseluruhan
dalam pengembangan.
2. Menerapkan metodologi
yang terdefinisi dengan baik untuk resolusi software.
3. Melengkapi secara
rasional konflik-konflik dan dokumentasi.
Secara singkat, tujuan
atau pentingnya Rekayasa Perangkat Lunak adalah Tujuan RPL adalah menghasilkan perangkat lunak dengan
kinerja tinggi, tepat waktu, berbiaya rendah, dan multiplatform.
3. Kapan
Rekayasa Perangkat Lunak (RPL) Diperlukan
Keadaan perangkat lunak semakin
memburuk sehubungan dengan waktu, dan karena itu, preventive maintenance yang
sering juga disebut Rekayasa perangkat lunak, harus dilakukan untuk
memungkinkan perangkat lunak melayani kebutuhan para pemakainya. Pada dasarnya
preventive maintenance melakukan perubahan pada program komputer sehingga bisa
menjadi lebih mudah untuk dikoreksi,disesuaikan, dan dikembangkan.
Sekarang,
aging software plant memaksa banyak perusahaan untuk mengikuti strategi
rekayasa perangkat lunak. Secara global, rekayasa perangkat lunak sering
dianggap sebagai bagian dari perekayasaan ulang proses bisnis.
Fase dan langkah langkah yang berhubungan,
seperti yang digambarkan pada padangan umum kita tentang rekayasa perangkat
lunak, harus diimbangi dengan sejumlah aktifitas pelindung, yang meliputi :
1.
kontrol dan pelacakan proyek perangkat lunak,
2.
Review teknis formal,
3.
Jaminan kualitas perangkat lunak,
4.
Manajemen konfigurasi perangkat lunak,
5.
Penghasilan dan penyiapan dokumen,
6.
Manajemen reusabilitas,
7.
Pengukuran,
8.
Manajemen resiko.
4. Yang
Terlibat Dalam Melakukan Rekayasa Perangkat Lunak (RPL)
Manajemen proyek perangkat lunak yang
efektif berfokus pada tiga P : People (manusia),
problem (masalah), process (proses).
1. Manusia
(People)
Faktor
manusia sangat penting sehingga Software Engineering Institute telah
mengembangkan sebuah model kematangan kemampuan manajemen manusia (PM-CMM)
”untuk mempertinggi kesiapan organisasi perangkat lunak untuk mengerjakan
aplikasi yang semakin kompleks dengan membantu menarik, menumbuhkan,
memotivasi, menyebarkan, dan memelihara bakat yang dibutuhkan untuk
mengembangan kemampuan perkembangan perangkat lunak mereka”
Model
kematangan manajemen manusia membatasi area praktikj berikut kunci bagi
masyarakat perangkat lunak : rekruitmen, seleksi, manajemen unjuk kerja,
pelatihan, kompensasi, perkembangan karir, desain kerja dan organisasi, dan
perkembangan tim/kultur.
Ø
Para Pemain
Proses perangkat lunak
diisi oleh para pemain yang dapat dikategorikan ke dalam salah satu dalam lima
konstituen berikut ini :
1.
Manajer
Senior, yang
menentukan isu-isu bisnis yang sering memiliki pengaruh penting di dalam
proyek.
2.
Manajer
(teknik) Proyek, yang
harus merencanakan, memotivasi, mengorganisir, dan mengontrol sebuah produk
atau aplikasi.
3.
Pelaksana, yang menaympaikan ketrampilan teknik
yang diperlukan untuk merekayasa sebuah produk atau aplikasi.
4.
Pelanggan, yang menentukan jenis kebutuhan bagi
perangkat lunak yang akan direkayasa.
5.
Pemakai
Akhir, yang
berinteraksi dengan perangkat lunak bila perangkat lunak telah dikeluarkan
untuk digunakan.
Ø
Pimpinan Tim
Jerry Weinberg cenderung
mengusulkan model kepemimpinan MOI :
Motivasi. Kemampuan untuk memberi dorongan
orang teknik untuk menghasilkan sesuatu dengan kemampuan terbaiknya.
Organisasi. Kemampuan untuk membentuk proses yang
sedang berlangsung yang memungkinkan konsep dasar diterjemahkan ke dalam suatu
hasil akhir.
Gagasan
dan inovasi.
Kemampuan untuk mendorong manusia untuk menciptakan dan bertindak kreatif
meskipun mereka bekerja di dalam suatu ikatan yang dibangun untuk suatu produk
atau aplikasi perangkat lunak yang spesifik.
Pandangan lain tentang karakteristik
seorang manajer proyek yang efektif memberikan tekanan pada empat kata kunci :
Pemecahan masalah.
Seorang manajer proyek yang efektif dapat mendiagnosis isu-isu organisasi dan
teknis yang paling relevan, yang secara sistematis membentuk sebuah pemecahan
atau dengan tepat memotivasi para pelaksana yang lain untuk membuat pemecahan.
Identitas manajerial.
Seorang manajer proyek yang baik harus bersentuhan secara langsung dengan
proyeknya. Dia harus memilki rasa percaya diri untuk melakukan kontrol bila
perlu dan membolehkan orang-orang teknik yang baik untuk mengikuti insting
mereka.
Prestasi.
Untuk mengoptimasi
produktivitas sebuah tim proyek, seorang manajer harus memiliki inisiatif dan
prestasi, serta dengan caranya sendiri memperlihatkan bahwa pengambilan risiko
yang terkontrol tidak akan dikenai hukuman.
Pengaruh dan pembentukan
tim. Seorang manajer proyek yang efektif harus mampu “membaca” manusia; dia
harus mampu memahami sinyal verbal dan nonverbal serta bereaksi terhadap
kebutuhan-kebutuhan orang-orang yang mengirimkan sinyal tersebut. Manajer harus
dapat menguasai diri meskipun berada pada situasi tekanan yang sangat tinggi.
Ø
Tim Perangkat Lunak
Mantei mengusulkan tiga
organisasi tim yang umum :
Demokratis
terdesentralisasi (DD).
Tim rekayasa perangkat lunak ini tidak memiliki pemimpin yang permanen. Tetapi
“koordinator” dipilih untuk bertugas di dalam durasi waktu yang pendek, yang
kemudian diganti oleh yang lain yang mungkin bertugas untuk mengkoordinasi
tugas-tugas yang berbeda. Keputusan terhadap masalah dan pendekatan yang
dilakukan dibuat oleh konsensus kelompok. Komunikasi di antara anggota tim
bersifat horisontal.
Terkontrol
terdesentralisasi (CD).
Tim rekayasa perangkat lunak memiliki pemimpin tertentu yang mengkoordinasi
tugas-tugas khusus serta memiliki pemimpin-pemimpin sekunder yang bertanggung
jawab atas masalah sub-sub tugas. Pemecahan masalah merupakan aktivitas dari
kelompok, tetapi implementasi dari pemecahan masalah dipecah di antara sub-sub
kelompok oleh pimpinan tim. Komunikasi antar kelompok dan orang bersifat
horisontal, tetapi komunikasi vertikal sepanjang hirarki kontrol juga terjadi
di sini.
Terkontrol
terdesentralisasi (CC).
Koordinasi pemecahan masalah tingkat puncak dan internal tim diatur oleh
pimpinan tim. Komunikasi antara pimpinan dan anggota tim bersifat vertikal.
Ø
Masalah Koordinasi dan Komunikasi
Kraul dan Streeter
menguji sekumpulan teknik koordinasi proyek yang dikategorikan dalam kelompok
berikut :
Pendekatan
impersonal, formal.
Mencakup penyampaian dan dokumen rekayasa perangkat lunak (seperti kode
sumber), memo-memo teknis, kejadian penting pada proyek, jadwal dan piranti
kontrol proyek, kebutuhan akan perubahan dan dokumentasi yang berhubungan,
laporan pelacakan kesalahan dan data cadangan.
Prosedur
interpersonal, formal. Berfokus
pada aktivitas jaminan kualitas yang diterapkan kepada produk kerja rekayasa
perangkat lunak. Hal ini menyangkut pertemuan status pengkajianserta
perancangan dan inspeksi kode.
Prosedur
interpersonal, informal.
Menyangkut pertemuan kelompok untuk penyebaran informasi dan pemecahan masalah
serta “alokasi kebutuhan dan pengembangan staf”.
Komunikasi
elektronik. Mencakup
surat elektronik, papan buletin elektronik, web sites, serta sistem
konferensi berbasis video.
Jaringan interpersonal. Diskusi
informal dengan orang-orang di luar proyek yang mungkin memiliki pengalaman
atau pengetahuan yang dalam yang dapat mendukung anggota tim.
2. Masalah
(Poblem)
Sebelum
proyek direncanakan, obyektivitas dan ruang lingkupnya harus ditetapkan,
pemecahan alternatifnya harus dipertimbangkan, teknik dan bataspun harus
didefinisikan. Tanpa informasi ini tidak mungkin melakukan estimasi biaya yang
dapat dipertanggungjawabkan (akurat); penilaian yang efektif terhadap resiko;
merinci secara realistis tugas-tugas proyek; atau jadwal proyek yang dapat
dikelola yang memberikan indikasi kemajuan yang berarti. Pengembang dan pemakai
perangkat lunak harus bertemu untuk menentukan tujuan dan ruang lingkup proyek.
Di dalam banyak kasus, aktivitas ini dimulai sebagai bagian dari proses
rekayasa sistem dan berlanjut sebagai langkah pertama dalam analisis kebutuhan
perangkat lunak.
Ø
Ruang lingkup
Aktivitas manajemen
proyek perangkat lunak yang pertama adalah menentukan ruang lingkup perangkat
lunak. Ruang lingkup dibatasi dengan menjawab pertanyaan-pertanyaan berikut :
Konteks. Bagaimana perangkat lunak yang akan
dibangun dapat memenuhi sebuah sistem, produk, atau konteks bisnis yang lebih
besar, serta batasan apa yang ditentukan sebagai hasil dari kontek tersebut?
Tujuan informasi. Objek data pelanggan apa yang
dihasilkan sebagai output dari perangkat lunak? Objek data apa yang diperlukan
sebagai input?
Fungsi dan unjuk
kerja. Fungsi apa
yang dilakukan oleg perangkat lunak untuk mentransformasi input data menjadi
output? Adakah ciri kerja khusus yang akan ditekankan?
Ruang lingkup proyek
perangkat lunak harus tidak ambigu dan dapat dipahami pada tingkat teknis
maupun manajemen.
Ø
Dekomposisi Masalah
Dekomposisi masalah sering
disebut juga partitioning (pembagian), merupakan sebuah aktivitas yang
mendudukan inti dari analisis kebutuhan perangkat lunak.
Dekomposisi diterapkan
pada dua area utama :
(1). Fungsionalitas yang
harus disampaikan, dan
(2). Proses yang akan
dipakai untuk menyampaikannya.
Secara sederhana,
masalah yang kompleks dibagi ke dalam sejumlah masalah yang lebih kecil yang
dapat lebih dikendalikan.
3. Proses
(Process)
Proses
perangkat lunak memberikan suatu kerangka kerja di mana rencana komprehensif
bagi pengembangan perangkat lunak dapat dibangun. Sejumlah kumpulan tugas yang
berbeda – tugas-tugas milestone, kemampuan penyampaian, dan jaminan kualitas –
memungkinkan aktivitas kerangka kerja disesuaikan dengan karakteristik proyek
perangkat lunak serta kebutuhan tim proyek. Akhirnya aktivitas pelindung
seperti jaminan kualitas perangkat lunak, manajemen konfigurasi perangkat
lunak, dan pengukurannya – melapisi model proses yang ada.
Fase-fase
generik yang menandai proses perangkat lunak – definisi, pengembangan dan
pemeliharaan – dapat diaplikasikan pada semua perangkat lunak. Masalahnya
adalah bagaimana memilih model proses yang sesuai bagi perangkat lunak yang
akan direkayasa oleh sebuah tim proyek. Berikut ini beberapa jenis paradigma
yang dapat dipergunakan dalam rekayasa perangkat lunak :
·
Model
sekuensial linier
·
Model
prototipe
·
Model
RAD
·
Model
inkremental
·
Model
spiral
·
Model
asembli komponen
·
Model
pengembangan kongkuren
·
Model
metode formal
·
Model
teknik generasi keempat
Manajer proyek harus memutuskan model
proses mana yang paling sesuai untuk proyek tertentu.
Perencanaan proyek dimulai dengan
menggabungkan masalah dan proses. Setiap fungsi yang akan direkayasa oleh tim
perangkat lunak harus melampaui sejumlah aktivitas kerangka kerja yang sudah
ditentukan bagi sebuah organisasi perangkat lunak. Misal organisasi sudah
mengadopsi serangkaian aktivitas kerangka kerja sebagai berikut :
·
Komunikasi
pelanggan – tugas-tugas yang diperlukan untuk membangun komunikasi yang efektif
diantara pengembang dan pelanggan.
·
Perencanaan
– tugas-tugas yang diperlukan untuk menentukan sumber-sumber daya, ketepatan
waktu, dan informasi proyek yang lain.
·
Analisis
resiko – tugas-tugas yang diperlukan untuk memperkirakan resiko-resiko
manajemen dan teknis.
·
Rekayasa
– tugas-tugas yang diperlukan untuk membangun satu perwakilan aplikasi atau lebih.
·
Konstruksi
dan rilis – tugas-tugas yang diperlukan untuk membangun, menguji, memasang, dan
memberikan dukungan kepada pemakai (seperti dokumentasi dan pelatihan)
·
Evaluasi
pelanggan – tugas-tugas yang diperlukan untuk memperoleh umpan balik dari
pelanggan.
5. Contoh
Perangkat Lunak Dan Penerapan RPL
Sebagai
contoh dari perangkat lunak dan penerapan RPL adalah Proyek perangkat
lunak “Sistem Gudang On-Line”.
System
Gudang On-Line yang dimaksud, bertujuan untuk :
a. Menghasilkan
perangkat lunak untuk aplikasi Sistem Gudang On-Line yang memiliki fitur-fitur
standar seperti menambah barang, menghapus barang, menampilkan inventarisasi
barang dan pembuatan laporan dan sebagainya.
b. Memudahkan pekerjaan administrator gudang,
karena bisa mendapatkan informasi barang secara cepat dan akurat..
c. Memudahkan pekerjaan up-date barang, karena ada
penambahan barang baru dan
pengurangan barang akibat rusak maupun hilang.
Dalam sistem
gudang on-line
yang akan dibuat, pengguna dapat mengetahui informasi barang yang ada seperti
persediaan barang tertentu, jumlah barang dipesan, tanggal dipesan dsb. Juga
tersedia fasilitas untuk menambahkan barang baru maupun menghapus barang yang
sudah tidak dikehendaki ke File
Pilihan Barang. Kedua operasi terakhir dilakukan melalui Tabel Pilihan Barang
yang menghubungkan item-item yang ada di File
Pilihan Barang ke master
dan mengontrol suatu perhitungan record
terakhir. Suatu Laporan
Inventory Barang bisa disajikan dalam sistem gudang on-line
ini.
Laporan ini
bisa diminta melalui terminal operator. Laporan ini minimal terdiri dari header dan rincian yang.
memuat daftar barang persediaan dan yang dipesan. Laporan Kontrol Pilihan
juga bisa diberikan untuk membuat daftar semua perubahan pada File Pilihan Barang
akibat transaksi bisnis yang terjadi. Laporan ini terdiri dari bagian rincian
dan ringkasan. Bagian rincian berisi penambahan barang, penghapusan barang dan
jumlah permintaan yang salah. Sedangkan bagian ringkasan berisi rekapitulasi
jumlah barang yang ditambahkan maupun dihapus, laporan ukuran dan status
terakhirnya.
6. Sumber
Ø
Perencanaan
Proyek Rekayasa Perangkat Lunak (Amri Shodiq) Ilmu Komputer.com
Ø
Meluruskan
Salah Kapra Rekayasa Perangkat Lunak (Romi Satria Wahono) Ilmu Komputer.com
Ø
Rekayasa
Perangkat Lunak jilid 1, untuk Sekolah Menengah Kejuruan (Aunur Rofiq Mulyanto,
dkk).
Ø
Rekayasa
Perangkat Lunak, TELKOM POLYTECHNIC BANDUNG (Komala Ratnsari, dkk)
