Rekayasa Perangkat Lunak
Rekayasa
perangkat lunak telah berkembang sejak pertama kali diciptakan pada
tahun 1940-an hingga kini. Focus utama pengembangannya adalah untuk
mengembangkan praktek dan teknologi untuk meningkatkan produktivitas
para praktisi pengembang perangkat lunak dan kualitas aplikasi yang
dapat digunakan oleh pemakai.
Daftar Isi
SEJARAH SOFTWARE ENGINEERING
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 kasus 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 usahanya untuk menemukan teknik jitu untuk memecahkan masalah krisi 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).
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 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. Hal ini dapat kita lihat pada Gambar di bawah 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:
- Memperoleh biaya produksi perangkat lunak yang rendah
- Menghasilkan perangkat lunak yang kinerjanya tinggi, andal dan tepat waktu
- Menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis platform
- Menghasilkan perangkat lunak yang biaya perawatannya rendah
RUANG LINGKUP
Sesuai dengan definisi yang telah disampaikan sebelumnya, maka ruang lingkup RPL dapat digambarkan sebagai berikut:
- 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 Ada 12 metode Softwate Development yang saya rangkum dari beberapa sumber di internet, antara lain:
1. Waterfall Model
2. Agile Methodology
3. Scrum Development Methodology
4. RAD (Rapid Application Development)
5. Prototype Methodology
6. Dynamic Systems Development Model (DSDM)
7. Spiral Model
8. Extreme programming
9. Feature Driven Development
10. Joint Application Development
11. Lean Development
12. Rational Unified Process
Selain 12 metode di atas, masih ada metode lain yang tidak saya sebutkan. Saya hanya mengambil top 12 metode Berikut ini penjelasan dari masing-masing metode.
1. Waterfall Model
Kelebihan:
- Waterfall sangat sederhana, mudah dipahami dan digunakan untuk para pengembang pemula.
- Mudah dimanage, karena setiap tahap memiliki tugas-tugas spesifik.
- Sangat menghemat waktu karena setiap tahap diproses dan diselesaikan sekaligus.
- Waterfall sangat efektif untuk mengembangkan perangkat lunak dalam skala kecil dengan beberapa kebutuhan perangkat lunak yang mudah dipahami.
- Testing (pengujian) mudah dilakukan karena mengacu pada skenario pengujian yang sudah didefinisikan dalam spesifikasi fungsional sebelumnya.
- Model ini hanya dapat digunakan ketika tersedia requirement (kebutuhan) yang sangat tepat.
- Model ini tidak dapat diterapkan untuk pemeliharaan sistem (hanya untuk pengembangan sistem baru).
- kelemahan utama model ini adalah sekalinya berada di tahap pengujian, tidak ada kemungkinan untuk kembali ke tahap sebelumnya untuk melakukan suatu perubahan.
- Tidak ada kemungkinan untuk menghasilkan beberapa perangkat lunak lain sampai dengan tahap terakhir dari siklus terselesaikan.
- Tidak ada pilihan untuk mengetahui hasil akhir dari proyek secara keseluruhan.
- Model ini cocok digunakan untuk proyek kecil tetapi tidak cocok untuk proyek lama dan berkelanjutan.
- Kurang ideal untuk proyek yang requirement-nya sangat moderat dan ada ruang lingkup yang besar untuk modifikasi.
Kelebihan :
- Memiliki pendekatan adaptif yang dapat merespon perubahan kebutuhan-kebutuhan dari klien.
- Komunikasi secara langsung dan umpan balik konstan dari klien yang tidak meninggalkan celah untuk beberapa dugaan dalam sistem.
Kelemahan:
- Hanya fokus pada perangkat lunak yang dikembangan daripada dokumentasi, sehingga dapat menyebabkan kurangnya dokumentasi.
- Proyek yang sedang dikembangkan dapat keluar dari jalur (tidak sesuai rencana) jika klien tidak menjelaskan secara rinci tentang hasil akhir dari proyek yang diinginkan.
3. SCRUM Development Methodology
Metode
SCRUM dapat diterapkan ke berbagai macam proyek yang memiliki perubahan
yang sangat cepat atau memiliki kebutuhan yang mendesak. Metode SCRUM
dimulai dengan perencanaan singkat, meeting, dan diakhiri dengan
review akhir. Metode ini digunakan untuk pengembangan perangkat lunak
secara cepat yang didalamnya terdapat sekumpulan iterasi untuk membuat
perangkat lunak yang dibutuhkan. Metode ini merupakan metode yang ideal
karena mudah dibawa ke dalam jalur proyek yang memiliki progress yang
lambat.
Kelebihan:
- Semua keputusan berada di tangan tim.
- Dapat digunakan untuk proyek yang tidak mempertimbangkan dokumentasi kebutuhan bisnis.
- Meeting yang dilakukan setiap hari secara mudah dapat membantu pengembang untuk membuat kemungkinan untuk mengukur produktivitas individu. Hal ini dapat menyebabkan peningkatan produktivitas masing-masing anggota tim.
Kekurangan:
- Metode ini akan memakan biaya dan waktu lebih jika tidak diperkirakan secara akurat.
- Tidak cocok untuk proyek dalam lingkup besar, tetapi cocok untuk proyek kecil dan proyek yang bergerak cepat.
- Setiap anggota tim harus memiliki pengalaman. Jika tim terdiri dari orang-orang pemula, proyek tidak dapat diselesaikan dalam waktu yang sudah ditentukan.
4. RAD (Rapid Application Development)
RAD
merupakan metode yang efektif untuk memberikan pengembangan yang lebih
cepat dan kualitas yang dihasilkan lebih tinggi daripada metode lain.
Tujuan utama dari metode ini adalah untuk mengakselerasikan seluruh
proses pengembangan perangkat lunak. Tujuan dapat mudah dicapai karena
metode ini memungkinkan user untuk berpartisipasi dalam pengembangan
perangkat lunak.
Kelebihan:
- Membantu mengurangi risiko dan tenaga yang dibutuhkan pada bagian pengembangan perangkat lunak.
- Membantu klien untuk mengambil review singkat untuk proyek.
- Mendorong umpan balik customer yang selalu memberikan ruang lingkup perbaikan untuk berbagai proyek pengembangan perangkat lunak.
Kekurangan:
- Bergantung pada tim yang kuat dan kinerja individu untuk mengidentifikasi secara jelas kebutuhan bisnis yang tepat.
- Hanya akan berhasil pada sistem yang dapat dimodularisasi.
- Pendekatan ini membutuhkan pengembang dan tim desainer yang berskil tinggi yang bisa jadi tidak memungkinkan untuk setiap organisasi.
- Tidak dapat diterapkan untuk pengembang yang menggunakan budget rendah karena biaya pemodelan dan pembuatan kode sangat tinggi.
5. Prototype Methodology
Metode
prototype merupakan metode pengembangan perangkat lunak yang
memungkinkan developer untuk hanya membuat prototype dari solusi yang
ditawarkan untuk mendemonstrasikan fungsi-fungsi perangkat lunak pada
klien dan membuat modifikasi yang dibutuhkan sebelum dikembangkan pada
aplikasi yang sesungguhnya. Fitur terbaik dari metode ini adalah dapat
menyelesaikan beberapa isu yang mungkin terjadi pada model waterfall.
Kelebihan:
- Ketika prototype ditunjukkan pada klien, mereka dapat memahami secara jelas fungsi-fungsi dari perangkat lunak.
- Mengurangi risiko kegagalan secara signifikan, karena risiko potensial dapat diindentifikasi pada tahap awal dan tahap moderasi dapat dilakukan dengan cepat.
- Komunikasi antara tim pengembang perangkat lunak dan klien dapat menjadikan lingkungan yang sangat baik dan kondusif selama pengembangan.
- Membantu dalam mengumpulkan kebutuhan dan analisis kebutuhan ketika kurangnya dokumentasi tentang kebutuhan sistem.
Kekurangan:
- Metode prototype biasanya menggunakan biaya pengembang, sehingga sebaiknya dilakukan dengan menggunakan sumber daya minimal jika biaya pengembangan organisasi terlalu tinggi.
- Terlalu banyak keterlibatan klien biasanya tidak disukai oleh pengembang.
- Terlalu banyak modifikasi mungkin tidak bagus untuk proyek, karena hal ini dapat mengganggu aliran kerja dari seluruh tim pengembangan perangkat lunak.
6. Dynamic Systems Development Model (DSDM)
Kelebihan:
- Pengguna sangat terlibat dalam pengembangan sistem, sehingga mereka lebih cenderung mendapatkan pegangan pada proyek pengembangan perangkat lunak.
- Fungsionalitas dasarnya adalah sistem diserahkan dengan cepat, dengan lebih banyak fungsi yang disampaikan secara sering.
- Meberikan kemudahan akses oleh pengembang ke end-user.
- Proyek diserahkan tepat waktu dengan budget yang spesifik.
Kekurangan:
- DSDM mahal untuk diimplementasikan, karena mengharuskan user dan pengembang dilatih untuk menerapkannya secara efektif. Tidak cocok untuk organisasi kecil atau one-time project.
- Merupakan model relatif baru, oleh karena itu tidak umum dan tidak mudah dimengerti.
7. Spiral Model
Model Spiral merupakan model mutakhir yang berfokus pada identifikasi awal dan pengurangan risiko terhadap proyek.
Kelebihan:
Kekurangan:
8. Extreme Programming Methodology
Tidak ada komentar:
Posting Komentar