Jumat, 28 Februari 2014

Model Proses Pengembangan Perangkat Lunak


     Berikut Metode-Metode Pengembangan Perangkat Lunak (Model Proses Pengembangan Perangkat Lunak) yaitu metode Sekuensial Linier, prototype, RAD :

A. Sekuensial Linier  
     
     Model sekuensial adalah paradigm rekayasa perangkat lunak yang paling luas dipakai dan paling tua. Sering juga disebut dengan “siklus kehidupan klasik” atau “model air terjun.” Penggambaran model ini : 



Gb. Fase lingkaran pemecahan masalah  

Gb. Model sekuensial linier 
1. Rekayasa dan pemodelan sistem/informasi
     Karena sistem merupakan bagian dari sebuah sistem yang lebih besar, kerja dimulai dengan membangun syarat dari semua elemen sistem dan mengalokasikan beberapa subset dari kebutuhan ke software tersebut. Pandangan sistem ini penting ketika software harus berhubungan dengan elemen-elemen yang lain seperti software, manusia, dan database. Rekayasa dan anasisis system menyangkut pengumpulan kebutuhan pada tingkat sistem dengan sejumlah kecil analisis serta disain tingkat puncak. Rekayasa informasi mancakup juga pengumpulan kebutuhan pada tingkat bisnis strategis dan tingkat area bisnis.
2. Analisis kebutuhan Software
     Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khusunya pada software. Untuk memahami sifat program yang dibangun, analis harus memahami domain informasi, tingkah laku, unjuk kerja, dan interface yang diperlukan. Kebutuhan baik untuk sistem maupun software didokumentasikan dan dilihat lagi dengan pelanggan.
3. Desain
     Desain software sebenarnya adalah proses multi langkah yang berfokus pada empat atribut sebuah program yang berbeda struktur data, arsitektur software, representasi interface, dan detail (algoritma) prosedural. Proses desain menterjemahkan syarat/kebutuhan ke dalam sebuah representasi software yang dapat diperkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi software.
4. Generasi Kode
     Desain harus diterjemahkan kedalam bentuk mesin yang bisa dibaca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.
5. Pengujian
     Sekali program dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika internal software, memastikan bahwa semua pernyataan sudah diuji, dan pada eksternal fungsional, yaitu mengarahkan pengujian untuk menemukan kesalahan – kesalahan dan memastikan bahwa input yang dibatasi akan memberikan hasil aktual yang sesuai dengan hasil yang dibutuhkan.
6. Pemeliharaan
     Software akan mengalami perubahan setelah disampaikan kepada pelanggan (perkecualian yang mungkin adalah software yangdilekatkan). Perubahan akan terjadi karena kesalahan – kesalahan ditentukan, karena software harus disesuaikan untuk mengakomodasi perubahan – perubahan di dalam lingkungan eksternalnya (contohnya perubahan yang dibutuhkan sebagai akibat dari perangkat peripheral atau sistem operasi yang baru), atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja. Pemeliharaan software mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang baru lagi.
KEKURANGAN MODEL SEKUENSIAL LINEAR
Masalah yang kadang terjadi ketika model sekuensial linier diaplikasikan adalah :
1. Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model. Meskipun model linier bisa mengakomodasi iterasi, model ini melakukannya dengan cara tidak langsung. Sebagai hasilnya, perubahan – perubahan dapat menyebabkan keraguan pada saat tim proyek berjalan.
2. Kadang – kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya secara eksplisit. Model linier sekuensial memerlukan halini dan mengalami kesulitan untuk mengakomodasi ketidakpastiannatural yang ada pada bagian awal beberapa proyek.
3. Pelanggan harus bersifat sabar. Sebuah versi kerja dari program – program kerja itu tidak akan diperoleh sampai akhir waktu proyek dilalui. Sebuah kesalahan besar, jika tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bisa menjadi petaka
4. Pengembang sering melakukan penundan yang tidak perlu. Sifat alami dari siklus kehidupan klasik membawa kepada blocking state di mana banyak anggota tim proyek harus menunggu tim yang lain untuk melengkapi tugas yang saling memiliki ketergantungan. Blocking state cenderung menjadi lebih lazim pada awal dan akhir sebuah proses sekuensial linier
KELEBIHAN MODEL SEKUENSIL LINIER

1.    Software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik.
2.  Document pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.

B. Prototype

Gb. Prototype Paradigma

     Model ini dimulai dengan pengumpulan kebutuhan. Pendekatan prototyping model digunakan jika pemakai hanya mendefenisikan objektif umum dari perangkat lunak tanpa merinci kebutuhan input, pemrosesan dan outputnya, sementara pengembang tidak begitu yakin akan efisiensi algoritma, adaptasi sistem operasi, atau bentuk antarmuka manusia-mesin yang harus diambil. Cakupan aktivitas dari prototyping model terdiri dari :

a.  Mendefinisikan objektif secara keseluruhan dan mengidentifikasi kebutuhan yang sudah diketahui.  
b.  Melakukan perancangan secara cepat sebagai dasar untuk membuat prototype.
c. Menguji coba dan mengevaluasi prototype dan kemudian melakukan penambahan dan perbaikan-  perbaikan terhadap prototype yang sudah dibuat.  

     Secara ideal prototype berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan perangkat lunak. Bila prototype yang sedang bekerja dibangun, pengembang harus menggunakan fragmen-fragmen program yang ada atau mengaplikasikan alat-alat bantu (contoh: window manager, dsb) yang memungkinkan program yang bekerja agar dimunculkan secara cepat. 

Kelemahan prototyping model :

1. Pelanggan yang melihat working version dari model yang dimintanya tidak menyadari, bahwa mungkin saja prototype dibuat terburu-buru dan rancangan tidak tersusun dengan baik
2. Pengembang kadang-kadang membuat implementasi sembarang, karena ingin working version bekerja dengan cepat

 C. RAD (Rapid Application Development)

     Merupakan model proses pengembangan perangkat lunak secara linear sequential yang menekankan pada siklus pengembangan yang sangat singkat/pendek. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60-90 hari). Pendekatan RAD model menekankan cakupan :

a. Pemodelan Bisnis
  Aliran informasi diantara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan-pertanyaan berikut : Informasi apa yang mengendalikan proses bisnis ? Kemana informasi itu pergi? Siapa yang memprosesnya ? 

b. Pemodelan Data
   Aliran informasi yang didefinisikan sebagai bagian dari fase pemodelan bisnis disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik/atribut dari masing-masing objek diidentifikasi dan hubungan antara objek-objek tersebut didefinisikan.

c. Pemodelan Proses 
   Aliran informasi yang didefinisikan dalam fase pemodelan data ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus atau mendapatkan kembali sebuah objek data.

d. Pembuatan Aplikasi
   Selain menciftakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program yang telah ada atau menciftakan komponen yang bias dipakai lagi. Pada semua kasus, alat-alat Bantu otomatis dipakai untuk memfasilitasi kontruksi perangkat lunak.

e. Pengujian dan Pergantian
   Karena proses RAD menekankan pada pemakaian kembali, banyak komponen yang telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tapi komponen baru harus diuji.

Gb. Model RAD

Kelemahan model  RAD : 
1. Untuk proyek dengan skala besar, RAD membutuhkan sumber daya manusia yang cukup untuk membentuk sejumlah tim RAD yang baik.

2. RAD membutuhkan pengembang dan pemakai yang mempunyai komitmen dalam aktivitas rapid-fire untuk melaksanakan aktivitas melengkapi sistem dalam kerangka waktu yang singkat. Jika komitmen tersebut tidak ada, proyek RAD gagal.
Tidak semua aplikasi sesuai untuk RAD.bila system tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat problematic. RAD menjadi tidak sesuai jika risiko teknisnya tinggi.
    
 (sumber : ugm.ac.id & andisulaeman.weebly.com)

Kamis, 20 Februari 2014

Apa itu Rekayasa Perangkat Lunak "RPL"

Pada masa kini, rasanya hampir semua bidang kehidupan tersentuh dengan penggunaan perangkat lunak atau software. Beberapa perangkat lunak mungkin sudah terbiasa kita gunakan. Perangkat lunak ini merupakan hasil dari serangkaian proses atau kegiatan yang dikenal sebagai Rekayasa Perangkat Lunak. 
 
Apakah sebenarnya Rekayasa Perangkat Lunak itu ?

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, desain, 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. RPL selalu berusaha menghasilkan output yang kinerjanya tinggi, biaya rendah dan waktu penyelesaian yang tepat.

Tentang RPL :

1. Rekayasa Perangkat Lunak itu ilmu untuk mempelajari seluruh konsep perancangan sebuah perangkat lunak, mulai dari ground zero, penyusunan rencana bisnis/proyek, analisis kebutuhan dan perangkat, dilanjutkan dengan perencanaan kerja, pelaksanaan pembangunan perangkat lunak, evaluasi dan testing, dokumentasi, serta akhirnya produk dilepaskan ke konsumen. So yang dipelajari itu konsepnya. Setelah menguasai konsep baru kemudian belajar praktiknya yaitu dengan komputer (ya iyalah masak pakek tv atau mesin ketik?) dan bahasa pemrograman, aplikasi database, jaringan komputer, dan lainnya.

2. Kenapa dipakai kata Rekayasa?
Kalau kata beberapa ahli, itu sebagai ‘akibat’ dari penyesuaian hasil terjemahan ‘Software Engineering’.  Kalau diartikan secara  teknik perangkat lunak, akan bertabrakan dengan teknik informatika yang telah ada sebelumnya. Selain itu pembuatan perangkat lunak dipercaya sebagai membuat atau memodifikasi sesuatu dengan menggunakan tool, sistem, serta perangkat lunak yang telah ada sehingga menghasilkan suatu perangkat lunak yang ‘baru’ sesuai dengan kebutuhan bisnis. Maka lebih tepat digunakan kata rekayasa daripada teknik.

3. Rekayasa Perangkat Lunak merupakan sebuah konsep yang luas dan bisa dikatakan intisari dari seluruh materi Teknik Informatika. Ia bukanlah merupakan suatu bidang pekerjaan. Yang akan menjadi bidang pekerjaan adalah materi2 dalam RPL itu yaitu Analisis - Desain - Implementasi - Testing - Maintenance. Dari sub konsep itulah lahir jenis2 profesi seperti Business Analyst, System Analyst, Designer, Programmer, Software Developer, Software Tester, IT Consultant, Network Engineer, Data Analyst, dan ada beberapa lagi yang lain.


Tujuan RPL adalah:  
a.   memperoleh biaya produksi perangkat lunak yang rendah
b.  menghasilkan perangkat lunak yang kinerjanya tinggi, handal dan tepat waktu
c.   menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis platform
d.  menghasilkan perangkat lunak yang biaya perawatannya rendah

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. Meskipun terlihat terpisah pisah, namun dalam penerapannya, sub-bidang RPL selalu membutuhkan dukungan dari sub-bidang lain, terutama sub-bidang Algoritma dan Struktur Data, Bahasa Pemrograman, Basis Data, Sistem Operasi dan Jaringan, dan Sistem Informasi.

Secara konsep, rekayasa perangkat lunak memiliki kedekatan dengan prinsip-prinsip pemecahan masalah. Pemahaman tentang masalah, strategi dan proses pemecahan masalah, serta pendekatan sistem pada pemecahan masalah akan sangat membantu proses rekayasa perangkat lunak. Untuk mengetahui dengan baik masalah, maka pengetahuan tentang gejala dari masalah menjadi sangat penting. proses pemecahan masalah dapat dilakukan dengan empat tahapan utama yaitu :
1. Memahami dan mendefinisikan masalah,
2. Membuat rencana untuk pemecahan masalah,
3. Merancang dan menerapkan rencana untuk memperoleh cara penyelesaian,
4. Memeriksa dan menyampaikan hasil dari pemecahan masalah.

       Jadi, Rekayasa perangkat lunak adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat lunak termasuk pembuatan, pemeliharaan, manajemen organisasi pengembangan perangkat lunak dan manajemen kualitas.



(sumber : ilmu-risa.blogspot.com)