Rekayasa Perangkat Lunak ( RPL) atau Software Enggineering

PENGERTIAN REKAYASA PERANGKAT LUNAK

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 sebagai berikut:
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.
Jelaslah bahwa 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.

TUJUAN REKAYASA PERANGKAT LUNAK
Secara umum tujuan RPL tidak berbeda dengan bidang rekayasa yang lain.  Mari kita perhatikan Gambar  berikut ini.

 Dari Gambar di atas dapat diartikan bahwa bidang rekayasa akan selalu
berusaha menghasilkan output yang kinerjanya tinggi, biaya rendah dan waktu penyelesaian yang tepat.  Secara lebih khusus kita dapat menyatakan tujuan RPL adalah :
a. Memperoleh biaya produksi perangkat lunak yang rendah. 

b. Menghasilkan perangkat 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.  

RUANG LINGKUP 

Sesuai definisi yang telah disampaikan sebelumnya, maka ruang lingkup 

Keterangan :

• Software requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat lunak.
• Software design mencakup proses penentuan arsitektur, komponen, antarmuka, dan karakteristik lain dari perangkat lunak
• Software construction berhubungan dengan detil pengembangan perangkat lunak, termasuk algoritma, pengkodean, pengujian, dan pencarian kesalahan.
• Software testing meliputi pengujian pada keseluruhan perilaku perangkat lunak.
• Software maintenance mencakup upaya-upaya perawatan ketika perangkat lunak telah dioperasikan. 
• Software configuration management berhubungan dengan usaha perubahan konfigurasi perangkat lunak untuk memenuhi kebutuhan tertentu. 
• Software engineering management berkaitan dengan pengelolaan dan pengukuran RPL, termasuk perencanaan proyek perangkat lunak. 
• Software engineering tools and methods mencakup kajian teoritis tentang alat bantu dan metode RPL. 
• Software engineering process berhubungan dengan definisi, implementasi, pengukuran, pengelolaan, perubahan dan perbaikan proses RPL. 
• Software quality menitikberatkan pada kualitas dan daur hidup perangkat lunak.

 Perkembangan Rekayasa Perangkat Lunak

Mitos  

Ada 3 metode mitos, yaitu : 

1. Mitos management

• Kita tidak perlu mengubah pendekatan terhadap pengembangan software, karena jenis pemrograman yang kita lakukan sekarang ini sudah kita lakukan 10 tahun yang lalu.
• Realita  : Wa lau  has il  pr ogr am  sam a, pr oduktivitas  dan kualitas  software harus ditingkatkan dengan menggunakan pendekatan software developments. 
• Kita sudah mempunyai buku yang berisi standarisasi danprosedur untuk pembentukan software.
• Realita  : Mem ang buku ter s ebut  ada, tetapi  apakah buku ter s ebut  sudah dibaca atau buku tersebut sudah ketinggalan jaman (out ofdate).
• Jika kita tertinggal dari jadwal yang ditetapkan, kita menambah beberapa programmer saja. Konsep ini sering disebut Mongolian har de concept. 

2. Mitos Customer Pernyataan tujuan umum sudah cukup untuk memulai penulisan program. Penjelasan yang lebih rinci akan menyusul kemudian.

• Realita  : D efinis i  aw al yang bur uk adalah  penyebab utam a kegagalan terhadap usaha-usaha pembentukkan software. Penjelasan yang formal dan terinci tentang informasi fungsi performance interface, hambatan desain dan kriteria validasi adalah penting.
• Kebutuhan proyek yang terus menerus berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel.
• Realita : Jika perubahan mendekati akhir penyelesaian, maka biaya akan lebih besar.

3. Mitos Praktisi Tidak ada metode untuk analisis disain dan testing terhadap suatu pekerjaan, cukup menuju ke depan terminal dan mulai coding.

• Realita  : Metode  untuk analis is  des ain dan tes ting  diper lukan  dalam pengembangan software.
• Segera setelah software digunakan, pemeliharaan dapat diminimalisasikan dan diatasi.
• Realita  : D iper lukan budget  yang bes ar  dalam  maintenance  software. Pemeliharaan software harus diorganisir, direncanakandan dikontrol seolah-olah sebagai suatu proyek besar dalamsebuah organisasi.

Proses Software   

1. Pengertian Software ProsesSekumpulan aktifitas yang saling terkait untuk spesifikasi, desain, implementasi dan testing system software.

2. Tujuan Software Proses 

• Memperkenalkan model proses software 
• Menggambarkan beberapa model proses dan kapan digunakan 
• Menggambarkan outline model proses untuk rekayasa kebutuhan, pengembangan software,testing dan evolusi 
• Mengenalkan teknologi CASE untuk mendukung aktifitas proses software

3. Model Proses Software 

•  Model waterfall  > Membagi dan membedakan fase spesifikasi dan pengembangan 
•  Pengembangan Evolusioner > Spesifikasi dan pengembangan terpisah 
• Pengembangan sistem Formal > Model sistem matematis yang secara formal diterjemahkan ke dalam implementasi
• Pengembangan Reuse-based > Sistem dibangun dari komponen yang sudah ada

Metode Konvensional  

Dalam metode konvensional, hanya terdapat satu model, yaitu model waterfall Model waterfall 

•  Model waterfall  > Membagi dan membedakan fase spesifikasi dan pengembanga

• Fase model Waterfall 

1. Analisa dan definisi kebutuhan Proses menganalisis dan pengumpulan kebutuhan sistem yang sesuai
2. Desain sistem dan software Proses desain akan menerjemahkan syarat kebutuhan ke sebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat coding.
3. Pengkodean Menerjemahkan desain ke bahasa yang dimengerti komputer
4. Pengujian Memeriksa program, mencari kesalahan
5. Operasi dan Maintenance Pemeliharaan sistem 

• Keunggulan Model Waterfall 

1. Mudah aplikasikan 
2. Memberikan template tentang metode analisis, desain, pengkodean, pengujian, dan pemeliharaan

•  Permasalahan Model Waterfall 

1. Jarang sekali proyek yang prosesnya bisa dilakukan secara sequencial 
2. Sukar  bagi customer untuk secara explisit mengemukakan semua kebutuhannya 
3. Customer harus sabar
4. Jika ada developer yang menunda pekerjaan, maka anggota tim harus menunggu

Metode Evolusioner 
1. Pengembangan Evolusioner

• Pengembangan Exploratory 

Obyektif : bekerja dengan konsumen dan melibatkan sistem akhir dari spesifikasi skemainisial. Dimulai dengan kebutuhan yang dimengerti dengan baik

• Throw-away prototyping 

Obyektif : mengerti kebutuhan sistem. Dimulai dengan kebutuhan yang tidak dimengerti dengan baik

2. Permasalahan Evolusioner
•    Tidak ada visibilitas proses
•    Sistem biasanya tidak terstruktur dengan baik
•     Kemampuan khusus (misalnya bahasa untuk prototipe cepat) kemungkinan diperlukan

3. Aplikasi
•     Untuk sistem interaktif berukuran kecil atau medium
•     Untuk bagian dari sistem besar (misalnya user interface)
•     Untuk sistem dengan daur hidup pendek

Posted in: RPL