Rabu, 04 Januari 2012

REKAYASA PERANGKAT LUNAK (RPL)


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)

Tidak ada komentar:

Poskan Komentar