PENGENALAN REKAYASA PERANGKAT LUNAK

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 (OBrien, 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 pembuatanprogram 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.

Gambar Tujuan RPL.

Dari Gambar 1.2 dapat diartikan bahwa bidang rekayasa akan selalu berusaha menghasilkan output yang kinerjanya tinggi, biaya rendah dan waktupenyelesaian 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 RPL dapat digambarkan sebagai berikut.

Gambar Ruang lingkup RPL (Abran et.al., 2004).

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.

Tanggungjawab dan profesional etika Perekayasa perangka lunak harus menerima bahw pekerjaannya melibatkan tanggjung jawab yng lebih luas dari hanya sekedar menerakan keahlian teknis. Pekerjaan mereka dilakukan dalam kerangka legal dan sosial. Rekayasa perangkat lunak jelas dibatasi oleh hukum lokal, nasional, dan internasional. Perekayasa perangkat lunak harus memiliki tanggung jawab etis dan moral jika mereka ingin dihormati sebagai profesional.
Tidak perlu dikatakan bahwa para perekayasa harus mematuhi standar normal mengenai kejujuran dan integritas. Mereka tidak boleh menggunakan keahlian dan kemampuan mereka dengan cara yang tidak jujur atau dengan cara yang menjatuhkan reputasi profesi rekayasa perangkat lunak. Nemun demikian, ada area di mana standar perilaku yang dapat diterima dan tidak dibatasi oleh hukum tetpi oleh prinsip yang lebih longgar demi tanggun jawab profesional. Beberapa dianataranya adalah 1. Konfidensialitas. Perekayasa umumnya harus menghormati konfidensialitas atasan atau kliennnya, walaupun tidak ada persetujuan konfidensialitas formal yang ditandatangani 2. Kompetensi. Perekyasa tidak boleh menyalahi tingkat kompetensinya. Mereka tidak boleh dengan sadar menerima pekerjaan yang melebihi kompetensi mereka 3. Hak Properti Intelektual. Perekayasa harus menyadari hukum lokal yang mengatur penggunaan properti intelektual seperti paten, hak cipta, dsb. Mereka harus berhati-hati untuk memastikan bahwa properti intelektual atasan dan klien terlindungi. 4. Penyalahgunaan komputer. Perekayasa perangkat lunak tidak boleh menggunakan keahlian teknis mereka untuk menyalahgunakan komputer orang lain. Penyalahgunaan komputer bisa berkisar dari hal yang relatif ringan (bermain game pada kompter atasan) sampai yang sangat serius (menyebarkan virus) Dengan pertimbangan ini, perhimpunan dan institute profesional mempunyai peran penting. Organisasi seperti ACM, IEEE (Institute of Electrical and Electonic Engginers) dan british Computer Society memerbitkan kode perilaku profesional atau koce etik. Anggota organisasi ini mengikuti kode tersebut ketika mereka mendaftar sebagai anggota. Kode perilaku ini umumnya berkenaan dengan perilaku etik dasar. ACM and IEEE telah bekerja sama untuk menghasilkan kode etik dan praktek profesional gabungan. Perekayasa perangkat lunak akan turut serta menjadikan analisis, spesifikasi, peracangan,

pengembangan, pengujian, dan pemeliharaan perangkat lunak sebagai suatu profesi yang menguntungkan dan dihormati. Sehubungan dengan komitmen mereka pada kesehatan, keamanan, dan kesejahteraan masyarakat. Perekayasa perangkat lunak harus mengikuti delapan prisnsip berikut ini : 1. MASYARAKAT perekayasa perangkat lunak akan bertindak secara konsisten sesuai dengan kepentingan masyarakat 2. KIEN dan ATASAN. Perekayasa perangkat lunak akan melakukan yang terbaik bagi klien dan atasan mereka, konsisten dengan kepentingan masyarakat 3. PRODUK. Perekayasa perangkat lunak akan menjamin bahwa produk mereka dan modifikasi yang mereka lakukan terhadapnya memenuhi standar setinggi tingginya. 4. PENILAIAN. Perekayasa perangkat lunak akan mempertahankan integritas dan independensi peniaian profesional mereka 5. MANAJEMEN. Manajer dan pemimpin rekayasa perangkat lunak akan mengikuti dan mempromosikan pendekatan etis terhadap manajemen pengembangan dan pemeliharaan perangkat lunak 6. PROFESI. Perekayasa perangkat lunak akan mempertinggi integritas dan reputasi profesinya konsisten dengan kepentingan masyarakat 7. KOLEGA. Perekayasa perangkat lunak akan bersifat adil dan mendukung terhadap koleganya. 8. DIRI SENDIRI. Perekayasa perangkat lunak akan berpartisipasi dalam pembelajaran seumur hidup mengenai praktek profesi mereka dan akan mempromosikan pendekatan etis terhadap praktek profesi tersebut. profesional yang

Software Development Life Cycle / SWDLC Proses sebagai problem solving : pengembangan perangkat lunak (PL) dapat dianggap sebagai ingkaran pemecahan masalah. Untuk menyelesaikan masalah besar, dipecah menjadi kecil terus-menerus sampai paling kecil, kemudian diselesaikan (recursive). Keterangan gambar : status quo (idle)

Model proses / daur hidup PL : model proses untuk Rekayasa Perangkat Lunak (RPL) dipilih berdasarkan sifat aplikasi dan proyeknya, metode dan tool yang digunakan, serta kontrol dan deliverable yang diinginkan. Linear sequential model (classic life cycle / model cycle) Model yang paling luas dipakai dan tertua. Mengusulkan suatu pendekatan sekuensial dan sistematis pada pengembangan PL. Meliputi aktivitas-aktivitas :

System / information engineering (rekayasa dan pemodelan sistem) : menyangkut pengumpulan kebutuhan (requirement gathering) pada level sistem dengan sejumlah kecil analisis serta top desain.

Analisis : kebutuhan PL, proses requirement gathering diintesifkan dan difokuskan, khususnya pada PL. Untuk memahami sifat program yang dibangun, analis harus memahami domain informasi, tingkah laku, unjuk kerja, dan interface yang diperlukan. Kebutuhan sistem maupun PL didokumentasikan dan direview bersama user.

Desain : fokus pada 4 hal : desain database, arsitektur PL, interface, dan algoritma prosedural. Proses desain menerjemahkan kebutuhan ke dalam representasi PL sebelum dimulai coding.

Coding : menerjemahkan desain ke dalam bahasa yang dimengerti mesin. Testing : fokus pada :
o o

Logika internal PL : memastikan bahwa semua statement telah diuji Fungsi eksternal : mengarahkan testing untuk menemukan kesalahankesalahan dan memastikan bahwa input yang diberikan akan menghasilkan output sesuai yang diinginkan.

Maintenance

Kelemahan model :

Meskipun mengakomodasi iterasi, model linier melakukannya secara tidak langsung sehingga perubahan-perubahan dapat menyebabkan keraguan saat tim proyek berjalan Jika user sulit menyatakan semua kebutuhannya secara explisit, model ini sulit mengakomodasi ketidakpastian itu User harus bersabar karena hasil baru bisa dinikmati setelah testing (akhir waktu). Jika ada kesalahan besar yang tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bisa menjadi petaka.

Pengembang sering melakukan penundaan yang tidak perlu. Anggota tim harus menunggu anggota tim lain selesai mengerjakan tugasnya yang mempunyai keterkaitan dan ketergantungan tinggi.

Meski memiliki kelemahan, model ini masih lebih baik daripada pendekatan yang sembrono / sembarangan. Contoh : model Waterfall terdiri dari fase investigasi -> analisis -> desain -> implementasi (coding) -> testing -> maintenance. Prototyping Model Berfungsi sebagai mekanisme pendefinisian kebutuhan. Pertama, developer menggali semua kebutuhan user secara cepat kemudian membangun prototipe yang sesuai dengan yang diinginkan dengan cepat pula dan ditunjukkan ke user, baru dibuat PL yang sesungguhnya berdasarkan komentar user terhadap prototipe. Kelebihan model : user dapat langsung melihat wujud PL yang akan dibangun meskipun sederhana dan dari sana dapat digali kebutuhan yang lebih dalam sebagai bahan penyusunan PL berikutnya.

Masalah yg muncul :

User merasa prototipe merupakan PL yang sesungguhnya, padahal ketika membuat prototipe belum disertakan kualitas PL secara keseluruhan / kemampuan pemeliharaan untuk jangka panjang

Developer sering membuat kompromi-kompromi implementasi untuk membuat prototipe bekerja dengan cepat sehingga akan ditemui ketidakcocokan pada prototipe ketika prototipe dibangun dengan bahasa yang sederhana

Program dibuat ulang / prototipe selalu baru

Contoh : model Iterative : investigasi -> membuat PL -> testing / deliver ke user dengan program prototipe. Rapid Application Development (RAD) Model Model proses perkembangan PL sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Menekankan perkembangan komponen program yang bisa dipakai lagi sehingga mendasari konsep Object-Oriented. Fase2 pendekatan RAD : Bussines modeling Data modeling Proses modeling Application generation : RAD mengasumsikan pemakaian teknik 4G (generasi keempat). Selain menciptakan PL dengan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program atau menciptakan komponen yang bias dipakai lagi.

Testing and Turn Over : karena menekankan pada reusability, banyak komponen program yang telah diuji sehingga mengurangi keseluruhan waktu pengujian. Tapi komponen baru harus diuji dan semua interface harus dilatih secara penuh.

The Incremental Model Mengadopsi model sekuensial linier dan model prototipe. Fungsi dasar sama, tapi ada tambahan asesoris (contoh : ada M.Word 1997, 2000). Fungsi tambahan ditambahkan terus untuk membuat sistem menjadi lebih baik. Pada increment pertama PL yang jadi, mengakomodasi kebutuhan inti. Baru pada tahap berikutnya ditambahkan kemampuan baru. Contoh : pengembangan microsoft word.

Increment 1 : hanya memberi fungsi inti > hanya bisa mengetik saja Increment 2 : bisa word art, spelling, dll

Kelebihan model : cocok untuk produksi masal.

An Evolutionary (Spiral) Model Penomoran dimulai dari arsiran paling dalam. Proses yang terjadi : Proyek pengembangan konsep Proyek pengembangan produk baru Proyek perbaikan produk Proyek pemeliharaan produk

Semua proyek tersebut dibangun dengan mengikuti model spiral melalui tahap :

Customer communication Planning Risk analysis Engineering Construction and release Customer evaluation

Win-Win Spiral Model Eliciting kebutuhan PL yang didefinisikan melalui negosiasi antara pelanggan dan developer, di mana tiap pihak berusaha menyeimbangkan teknik dan batasan bisnis. Concurrent Development Model Mirip Spiral model, biasa digunakan dalam pengembangan aplikasi client / server. Component-Based Development Variasi Spiral model di mana aplikasi dibangun dari komponen PL prepackage yang disebut class. Formal Methods Model Menggunakan notasi Matematika yang teliti untuk menentukan desain dan menguji sistem berbasis komputer. Fourth Generation (4GT) Techniques Menggunakan alat PL untuk menggenerate source code untuk sistem PL dari representasi perincian level tinggi.