REKAYASA PERANGKAT LUNAK

     PENGERTIAN DASAR

Istilah Reakayasa Perangkat Lunak (RPL) secara umum disepakati sebagai terjemahan dari istilah Software engineering. Istilah Software Engineering mulai dipopulerkan pada 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. Dari pengertian ini jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan program komputer. Pernyataan ”semua aspek produksi” pada pengertian di atas, mempunyai arti semnua hal yang berhubungan dengan proses produksi seperti manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas sampai dengan pelatihan pengguna merupakan bagian dari RPL.

SEJARAH SOFTWARE ENGINERING

Istilah software engineering digunakan pertama kali pada akhir 1950-an dan awal 1960-an. Saat itu, masih terdapat perdebatan tajam mengenai aspek engineering dari pengembangan perangkat lunak. Pada tahun 1968 dan 1969, komite sains NATO mensponsori dua konferensi tentang rekayasa perangkat lunak, yang memberikan dampak kuat terhadap pengembangan rekayasa perangkat lunak. Banyak yang menganggap dua konferensi inilah yang menandai awal resmi profesi rekayasa perangkat lunak.

Pada tahun 1960-an hingga 1980-an, banyak masalah yang ditemukan para praktisi pengembangan perangkat lunak. Banyak project yang gagal, hingga masa ini disebut sebagai krisis perangkat lunak. Kasus kegagalan pengembangan perangkat lunak terjadi mulai dari project yang melebihi anggaran, hingga kasusu yang mengakibatkan kerusakan fisik dan kematian. Salah satu kasus yang terkenal antara lain meledaknya roket Ariane akibat kegagalan perangkat lunak. Selama bertahun-tahun, para peneliti memfokuskan usahanay untuk menemukan teknik jitu untuk memecahkan masalah krisi perangkat lunak. Berbagai teknik, metode, alat, proses diciptakan dan diklaim sebagai senjata pamungkas untuk memecahkan kasus ini. Mulai dari pemrograman terstruktur, pemrograman berorientasi objek, pernagkat pembantu pengembangan perangkat lunak (CASE tools), berbagai standar, UML hingga metode formal diagung-agungkan sebagai senjaat pamungkas untuk menghasilkan software yang benar, sesuai anggaran dan tepat waktu. Pada tahun 1987, Fred Brooks menulis artikel No Silver Bullet, yang berproposisi bahwa tidak ada satu teknologi atau praktek yang sanggup mencapai 10 kali lipat perbaikan dalam produktivitas pengembanan perngkat lunak dalam tempo 10 tahun.

Sebagian berpendapat, no silver bullet berarti profesi rekayasa perangkat lunak dianggap telah gagal. Namun sebagian yang lain justru beranggapan, hal ini menandakan bahwa bidang profesi rekayasa perangkat lunak telah cukup matang, karena dalam bidang profesi lainnya pun, tidak ada teknik pamungkas yang dapat digunakan dalam berbagai kondisi.

TUJUAN REKAYASA PERANGKAT LUNAK

Secara umunmm tujuan RPL tidak berbeda dengan bidang rekayasa yang lain. Hal ini dapat kita lihat pada Gambar di bawah ini.

 

Gambar 1. Tujuan RPL

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 leboih khusus kita dapat menyatakan tujuan RPL adalah:

1. memperoleh biaya produksi perangkat lunak yang rendah
2. menghasilkan pereangkat lunak yang kinerjanya tinggi, andal dan tepat waktu
3. menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis platform
4. menghasilkan perangkat lunak yang biaya perawatannya rendah

     RUANG LINGKUP 

Sesuai dengan definisi yang telah disampaikan sebelumnya, maka ruang lingkup RPL dapat digambarkan sebagai berikut:

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

-          software Requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat lunak

-          software desain mencakup proses penampilan arsitektur, komponen, antar muka, dan karakteristik lain dari perangkat lunak

-          software construction berhubungan dengan detail 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 menitik beratkan pada kualitas dan daur hidup perangkat lunak

       
         REKAYASA PERANGKAT LUNAK DAN DISIPILIN ILMU LAIN

Cakupan ruang lingkup yang cukup luas, membuat RPL sangat terkait dengan disiplin dengan bidang ilmu lain. tidak saja sub bidang dalam disiplin ilmu komputer namun dengan beberapa disiplin ilmu lain diluar ilmu komputer.

Keterkaitan RPL dengan bidang ilmu lain

• 
  

-          bidang ilmu manajemen meliputi akuntansi, finansial, pemasaran, manajemen operasi, ekonomi, analisis kuantitatif, manajemen sumber daya manusia, kebijakan, dan strategi bisnis

-          bidang ilmu matematika meliputi aljabar linier, kalkulus, peluang, statistik, analisis numerik, dan matematika diskrit

-          bidang ilmu manajemen proyek meliputi semua hal yang berkaitan dengan proyek, seperti ruang lingkup proyek, anggaran, tenaga kerja, kualitas, manajemen resiko dan keandalan, perbaikan kualitas, dan metode-metode kuantitatif

-          bidang ilmu ergonomika menyangkut hubungan ( interaksi) antar manusia dengan komponen-komponen lain dalam sistem komputer

-          bidang ilmu rekayasa sistem meliputi teori sistem, analisis biaya-keuntungan, pemodelan, simulasi, proses, dan operasi bisnis

  PERKEMBANGAN REKAYASA PERANGKAT LUNAK

Tahun	Kejadian
1940an	Komputer pertama yang membolehkan pengguna menulis kode program langsung
1950an	Generasi awal interpreter dan bahasa macro Generasi pertama compiler
1960an	Generasi kedua compiler Komputer mainframe mulai dikomersialkan Pengembangan perangkat lunak pesanan Konsep Software Engineering mulai digunakan
1970an	Perangkat pengembang perangkat lunak Perangkat minicomputer komersial
1980an	Perangkat Komputer Personal (PC) komersial Peningkatan permintaan perangkat lunak
1990an	Pemrograman berorientasi obyek (OOP) Agile Process dan Extreme Programming Peningkatan drastis kapasitas memori Peningkatan penggunaan internet
2000an	Platform interpreter modern (Java, .Net, PHP, dll) Outsourcing

PROSES, METODE, dan TOOL(alat)

Rekayasa perangkat lunak merupakan teknologi yang berlapis-lapis.  Manajemen kualitas dan kesamaan pendirian akan mengembangkan software itu dan akhirnya mengarah pada software yang berkualitas.

Salah satu landasan dalam software engineering adalah Proses. Merupakan elemen penting yang menyatukan lapisan lainnya dan memungkinkan pengembangan yang rasional dan tepat waktu dari software.

Metode, merupakan cara yang dilakukan untuk membangun suatu software. Mencakup analisis kebutuhan, desain, konstruksi program, pengujian, dan support. Prinsip yang dilakukan oleh software engineer bergantung pada jenis masalah yang akan dibuat kedalam bentuk model.

Tools memberikan support untuk lapisan proses dan metode. Saat alat-alat saling terintegrasi, memungkinkan informasi yang dibuat oleh tool dapat digunakan oleh tool yang lain, sistem untuk pengembangan software, yang biasa di sebut Computer-aided software engineering telah terbentuk.

Fase pada SE

Pekerjaan yang berkaitan dengan rekayasa perangkat lunak dapat dikategorikan kedalam 3 fase generik. Setiap fase memiliki tujuan yang berbeda.

• Definition phase, fokus ke apa. Selama fase ini seorang software engineer menncoba untuk mengidentifikasi informasi untuk diproses, apa fungsi-fungsi yang akan dibuat, sistem apa yang akan diterapkan, desain apa yang harus dibuat sehingga menghasilkan software yang bagus.
• Development phase, fokus ke bagaimana. Dalam arsitektur perangkat lunak, bagaimana detail prosedural diimplementasikan, bagaimana interface dibangun, bagaimana desain engineer ditransalate kedalam sebuah bahasa program, dan bagaimana testing dilakukan. Umumnya ada 3 kegiatan yang selalu dilakukan software engineer ya itu : desain software, code generation, testing software.
• Support phase, fokus ke perubahan. Fase ini isinya adalah pengulangan fase definisi dan development. Terjadi karena adanya perubahan yang memungkinkan baik dari user ataupun faktor lain. Lingkup dari aktifitas ini meliputi (umbrella activities):
  •  tracking dan kontrol software
  • review formal teknis
  • jaminan kualitas software
  • manajemen pengaturan software
  • dokumentasi persiapan dan pembuatan
  • manajemen penggunaan kembali
  • pengukuran
  • manajemen resiko

PROSES SOFTWARE

Software Engineering Institute (SEI) telah mengembangkan model yang komperehensif didasarkan pada kumpulan kegunaan software yang harusnya bisa hadir sebagai suatu organisasi yang mencapai proses kematangan software. Pendekatan SEI menetapkan lima tahapan tingkat kematangan suatu software sebagai berikut :

1. Inisialisasi.  Proses software sangatlah panjang dan bahkan membuat stakeholder kualahan. Stakeholder adalah siapa saja yang ikut dalam proses software(manager, analist, programmer, user, dan client).  Sedikit proses yang didefinisikan dan keberhasilan dari software proses tergantung pada kemampuan individu.
2. Dapat diulang. Manajemen dasar proyek dibentuk untuk mengetahui dan mengukur biaya, jadwal, dan kegunaan. Tujuannya adalah untuk memberikan kemudahan jika terdapat masalah atau proyek yang hampir sama.
3. Jelas. Proses software untuk manajemen dan engineering (perekayasaan) akan didokumnetasi, distandardkan, dan di integrasi kedalam suatu organisasi besar dalam proses software.
4. Teratur. Detail dari proses software dan kualitas produk telah diketahui. Keduanya diketahui seberapa besar ukurannya dengan menggunakan pengukuran yang detail.
5. Optimal. Proses perbaikan yang berlanjut terus yang berasal dari feedback pada proses dan testing. Pada tahap ini berarti sudah menyakup tahap-tahap sebelumnya. Begitu juga pada tahap 4, berarti sudah menyakup tahap ke 3 begitu seterusnya.

MODEL PROSES SOFTWARE

Software enginer beserta timnya harus bekerjasama untuk  strategi pengembangan yang meliputi lapisan proses, metode, tools(alat) untuk memecahkan masalah sebenarnya dalam industri kini. Sebuah model proses untuk software engineering dipilih berdasarkan sifat proyek dan aplikasi, metode dan alat yang digunakan serta kontrol yang diperlukan.

Semua pengembangan software dapat dicirikan sebagai lingkaran pemecahan masalah yang berbeda tempat dan tahapnya : status quo, problem definition (definisi masalah), technical development (pengembangan teknis), and solution integration (solusi). Penting untuk mengingat setiap model yang telah dicirikan membantu dalam kontrol dan koordinasi proyek pada software yang nyata.

MODEL SEKUENSIAL LINIER 

• Biasanya disebut juga classic life cycle atau model air terjun (waterfall). Menunjukan pendekatan yang sistematis dan terurut untuk pengembangan software yang dimulai pada tingkat sistem dan kemajuan melalui analisis, desain, coding, testing dan support. 
• Permodelan dan rekayasa sistem/informasi. Rekayasa sistem dan analisis meliputi pengumpulan bahan pada tingkat sistem dengan tingkat teratas dari desain dan analisis. Rekayasa informasi meliputi pengumpulan  pada tingkatan bisnis dan tingkatan area bisnis. 
• Analisis Persyaratan Software. Proses pengumpulan bahan/syarat khusus difokuskan pada software requirements untuk sistem maupun untuk dokumentasi dan review dengan customer.
• Desain. Proses desain menerjemahkan requirement kedalam representasi software yang dapat dinilai kualitasnya sebelum dilakukan coding. Desain juga didokumentasikan dan menjadi bagian dari konfigurasi perangkat lunak (software configuration)
• Code generation/ coding. Desain harus diterjemahkan ke bahasa program. Jika pada tahap sebelumnya sudah mendapatkan detail yang cukup, maka tahap ini mudah untuk dilakukan.
• Testing/ Pengujian. Saat sekali saja code sudah digenerate/ dicompile, itu sudah termasuk ke dalam testing. Fokus pada logika internal pada software. Memperbaiki error dan bug yang didapat dan menghasilkan software dengan hasil output sesuai yang diinginkan.
• Support. Sebuah software mengalami perubahan setelah dikirim ke customer (kecuali software yang in-built/embedded). Perubahan akan terlihat karena error akan ditemukan saat dilakukan pengujian. Software harus dapat beradaptasi dengan lingkungan elsternal.
• Model ini termasuk yang paling tua dan banyak digunakan di banyak paradigma software engineering. Bagaimanapun, kritik tetap ada. Hal itu dikarenakan :
  • Proyek pada kenyataannya banyak yang keluar dari alur seperti pada gambar. Akibatnya, perubahan dapat menyebabkan kebingungan pada hasil proyek tim.
  • Banyak sekali customer yang sulit untuk menyatakan semua persyaratan / requirements yang dibutuhkan secara eksplisit.
  • Pelanggan harus sabar. Karena jika terjadi suatu kesalahan jika tidak terdeteksi sampai projek berakhir an sangat fatal.

MODEL PROTOTYPE 

• Idealnya prototype berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan perangkat lunak. Jika prototype kerja dibangun, pengembang mencoba menggunakan fragmen program dan tools (seperti report generator, windows manager) yang mempermudah dan memepermudah pekerjaan. Bisa juga prototype disebut sebagai “first system”. Namun model ini juga mempunyai banyak kendala seperti :
  • Para customer melihat apa yang ada pada software yang dibagun dari awal. Prototype ini akan di handle bersama-sama oleh pengembang dan customer. Setiap satu putaran siklus akan menghasilkan versi software yang lebih baik kualitasnya. Tapi ini akan membutuhkan waktu yang sangat panjang untuk membuatnya.
  • Pengembang sering berkompromi dengan implementasi agar prototype bekerja cepat.
  • Meskipun masalah pasti ada, prototype dapat menjadi paradigma yang efektif untuk rekayasa perangkat lunak. Kuncinya adalah definisikan peraturan di awal, itulah customer dan pengembang harus menyetujui pembuatan prototype untuk menjelaskan mekanisme untuk definisi requirements. Software yang sebenarnya haruslah yang berkualitas dan dapat diperbaharui.

MODEL RAD

• Rapid application development (RAD) adalah sebuah model proses pengembangan software cepat yang menekankan siklus pengembangan sanat pendek. Model RAD adaptasi dengan kecepatan tinggi dari model linier sekuensial permodelan bisnis. Permodelan Data. Alur informasi didefinisikan sebagai bagian dari fase permodelan bisnis kedalam objek data yang dibutuhkan untuk menyokong bisnis. Atribut dari setiap objek teridentifikasi dan hubungan antara objek juga diketahui.
• 
• Permodelan Proses. Objek data terdefinisi di fase permodelan yang ditransformasikan ke alur informasi untuk implementasi fungsi bisnis. Deskripsi proses dibuat untuk menambah, merubah, menghapus ataupun menerima objek data.
• Generation aplikasi. RAD menyatakan penggunaan kembali komponen yang bisa digunakan ataupun pembuatan komponen yang reusable (bila diperlukan).
• Pengujian dan omset. Sejak proses RAD menekankan tentang reuseable, banyak komponen program yang sudah di uji. Ini akan mengurangi waktu uji. Bagaimanapun komponen yang baru harus diuji dan semua interface harus disinkornkan.
• Setiap fungsi utama dapat dibedakan oleh tim RAD dan diintegrasikan kemudian untuk digabungkan. Seperti semua model proses, pendekatan RAD memiliki kekurangan :• Untuk projek yang berskala, RAD membutuhkan sumber daya untuk membuat jumah tim yang cukup.• RAD membutuhkan pengembang dan customer yang setuju dengan aktifitas cepat untuk mendapatkan sistem dalam waktu relatif cepat. Jika tidak bisa, RAD akan gagal di tengah jalan.• Tidak emua tipe aplikasi dapat menggunakan model RAD. Jikasuatu sistem tidak ter modulisasi dengan benar, pembangunan komponen RAD akan menjadi masalah. Membutuhkan performa yang tinggi, jika tidak pendekatan RAD akan sia-sia.
  • RAD tidak sesuai saat resiko sangat tinggi. Saat aplikasi baru membuat kerja yang besar (lambat) dari teknologi atau saat  software baru membutuhkan spesifikasi komputer tinggi tapi dengan hanya komputer yang ada saat itu.

MODEL INCREMENT

• Model increment menggabungkan elemen dari sekuensial linier dengan iterative prototype. Berdasarkan gambar, setiap sekuensial linier menghasilkan peningkatan software. 

MODEL SPIRAL

• Model spiral terdiri dari iteratif prototype dengan kontrol dan aspek sistematis dari model sekuensila linier. Model spiral dibagi menjadi beberapa kerangka aktifitas, yang juga disebut task region.
• • Customer communication, dibutuhkan untuk menetapkan komunikasi efektif antara developer dan customer.
  • Planning, dibutuhkan untuk mendefinisikan sumber, garis waktu dan informasi lain yang berhubungan dengan proyek.
  • Risk analysis, dibutuhkan untuk menilai manajemen resiko dan resiko teknik.
  • Engineering, dibutuhkan untuk membuat satu atau lebih representasi dari aplikasi.
  • Construction and release, dibutuhkan untuk membuat, menguji, menginstall dan menyediakan support bagi user(misalnya dokumentasi dan training).
  • Customer evaluation, dibutuhkan untuk memperoleh feedback (umpan balik) customer berdasarkan evaluasi software yang dibuat selama tahap rekayasa dan implementasi selama tahap instalasi.
    

MODEL SPIRAL WINWIN

• Model WINWIN mendefinisikan kumpulan aktifitas disekitar siklus. Aktifitas yang dilakukan : 
• 

1. Identifikasi sistem atau subsistem
2. Tujuan dari stakeholder(semua orang yang terlibat dalam aktifitas ini)
3. Negosiasi diantara stakeholder

MODEL PENGEMBANGAN BERSAMA

• Model Proses bersamaan dapat diwakili bagan sebagai serangkaian kegiatan teknis utama, tugas, dan negara-negara yang terkait. Hal ini menghasilkananalisis acara koreksi model yang akan memicu aktivitas analisis dari negarayang dilakukan ke negara perubahan menunggu. Model Proses bersamaan sering digunakan sebagai paradigma untuk pengembangan client/server11 aplikasi (Bab 28). Pada kenyataannya, model proses konkuren ini berlaku untuk semua jenis pengembangan perangkat lunak dan memberikan gambaran yang akurat tentang keadaan saat ini proyek. 

PEMBANGUNAN yang BERBASIS KOMPONEN

Teknologi yang berorientasi obyek menyediakan kerangka kerja teknis untuk proses model berbasis komponen untuk software. Paradigma orientasi obyek menekankan pembuatan kelas yang mengenkapsulasi data dan algoritma yang digunakan untuk manipulasi data. Jika didesain dan dibuat dengan benar kelas orientasi obyek dapat digunakan kembali meski dengan berbagai aplikasi dan arsitektur yang berbasis komputer.

Model CBD (Compnent-Based Development) atau model pembangunan berbasis komponen menggabungkan banyak karakteristik dari model spiral. Pengembangan software yang terpadu adalah wakil dari sejumlah model pengembangan berbasis komputer yang diusulkan dalam dunia industri. Menggunakan UML (Unified Modelling Language), proses terpadu mendefinisikan komponen yang digunakan untuk membangun sistem dan interface yang akan menghubungkan komponen. Menggunakan kombinasi iteratif dan incremental, proses terpadu menyatakan fungsi sistem dengan menerapkan pendekatan berbasis skenario (dari sudut pandang pengguna).

RINGKASAN

Software engineering adalah disiplin yang mengintegrasikan proses, metode, dan alat untuk pengembangan perangkat lunak komputer. Sejumlah model proses yang berbeda untuk rekayasa perangkat lunak telah diusulkan, masing-masing kekuatan dan kelemahan telah ditunjukkan, tetapi semua memiliki serangkaian fase generik yang sama.

Referensi: 

• Software Engineering:  A PRACTITIONER APPROACH’S ‘edisi 5. Roger S Pressman.
• http://kityyulia.blogspot.com/2013/02/pengertian-dan-tujuan-rpl.html
• http://lingga-repeluone.blogspot.com/p/ruang-lingkup-rekayasa-perangkat-lunak.html
• https://bagusharisa.wordpress.com/2013/03/19/rekayasa-perangkat-lunak-software-engineering/