Pengertian dan Model-Model

Proses Perangkat Lunak

Pengertian Rekaya Perangkat Lunak.

Menurut Roger S.Pressman,ph.D. dalam bukunya yang berjudul Rekaya Perangkat Lunak Edisi 7, terdapat beberapa definisi tentang perangkat lunak dan rekayasa perangkat lunak yaitu :

1.Instruksi-instruksi (program komputer) yang ketika dijalankan menyediakan fitur-fitur, fungsi-fungsi, dan kinerja-kinerja yang dikehendaki.

Struktur data yang memungkinkan program-program memanipulasi informasi, dan

Informasi deskriptif pada salinan tercetak dan bentuk-bentuk maya yang menggambarkan pengoperasian dan pengunaan program-program.
Sedangkan definisi rekayasa perangkat lunak sendiri adalah

Aplikasi atau suatu pendekatan yang sistematik, disiplin, dan dapat diukur pada pengembangan, operasi, dan perawatan pada perangkat lunak  yaitu, penerapan rekayasa pada perangkat lunak.

Rekayasa perangkat lunak adalah teknologi berlapis. Hal itu dapat ditunjukan dengan gambar sebagai berikut,

Gambar 1

Dari gambar di atas dapat diartikan bahwa  setiap pendekatan rekayasa (termasuk rekayasa perangkat lunak) harus menekankan pada  kualitas.

Dasar untuk rekayasa perangkat lunak adalah lapisan proses. Proses rekayasa perangkat lunak adalah proses yang terus berulang, karena karakteristik perangkat lunak yang membutuhkan pemeliharaan dan pengembangan berkelanjutan agar perangkat lunak tidak kadarluasa.

proses didefinisikan sebagai kumpulan aktivitas kerja, tindakan, dantugas-tugas yang dilakukan ketika  ada produk kerja yang akan dibuat. Masing-masing kegiatan, tindakan, dan tugas berada dalam kerangka atau model yang mendefinisikan mereka berhubungan dengan proses  dan dengan satu sama lain.

Proses perangkat lunak diwakili skematis pada Gambar berikut.

  Gambar 2.

Mengacu pada Angka, setiap aktivitas kerangka kerja dihuni oleh serangkaian tindakan rekayasa perangkat lunak.

Setiap tindakan rekayasa perangkat lunak didefinisikan oleh satu set tugas yang mengidentifikasi pekerjaan tugas-tugas yang harus diselesaikan, produk pekerjaan yang akan diproduksi, kualitas poin jaminan yang akan diperlukan, dan tonggak yang akan digunakan untuk menunjukkan kemajuan.

Kerangka Proses Generik

kerangka proses generik untuk rekayasa perangkat lunak

mendefinisikan lima kerangka kegiatan-komunikasi, perencanaan, pemodelan,

konstruksi, dan penyebaran. Selain itu, satu set payung kegiatan-proyek

pelacakan dan kontrol, manajemen risiko, jaminan kualitas, manajemen konfigurasi,

ulasan teknis, dan lain-lain-yang diterapkan selama proses berlangsung. Proses aspek menjelaskan bagaimana kerangka kegiatan dan tindakan dan tugas yang terjadi dalam setiap kerangka kerja Kegiatan diselenggarakan sehubungan dengan urutan dan waktu dan diilustrasikan dalam Gambar berikut.

Gambar 3.

Model Proses Perspektiv

Model proses preskriptif awalnya diusulkan untuk membawa solusi kekacauan

pengembangan perangkat lunak. Sejarah telah menunjukkan bahwa model-model tradisional

telah membawa sejumlah struktur yang berguna untuk pekerjaan rekayasa perangkat lunak dan telah menyediakan peta jalan cukup efektif untuk tim perangkat lunak.

 Namun, perangkat lunak pekerjaan rekayasa dan produk yang menghasilkan tetap di "tepi kekacauan."

Dalam sebuah makalah yang menarik tentang hubungan aneh antara ketertiban dan kekacauan di dunia perangkat lunak, Nogueira dan rekan-rekannya  negara

Tepi kekacauan didefinisikan sebagai "keadaan alami antara ketertiban dan kekacauan, kompromi besar antara struktur dan kejutan “ . Tepi kekacauan dapat divisualisasikan

tidak stabil, sebagai terstruktur negara. . . . Hal ini tidak stabil karena selalu tertarik

kekacauan atau untuk memesan mutlak.

.Pada bagian berikut, saya memeriksa proses preskriptif

Pendekatan di mana urutan dan konsistensi proyek adalah masalah yang dominan. Saya menyebutnya "Preskriptif" karena mereka meresepkan satu set proses kegiatan elemen-kerangka, tindakan rekayasa perangkat lunak, tugas, produk kerja, jaminan kualitas, dan

mengubah mekanisme kontrol untuk setiap proyek. Setiap model proses juga mengatur sebuah aliran proses (juga disebut alur kerja) -yaitu, cara di mana proses

elemen yang saling terkait satu sama lain.

Semua model proses perangkat lunak dapat mengakomodasi kegiatan kerangka generik , tetapi masing-masing berlaku penekanan yang berbeda untuk kegiatan ini dan mendefinisikan alur proses yang memanggil setiap kegiatan kerangka (serta perangkat lunak tindakan rekayasa dan tugas) dengan cara yang berbeda.

Model Proses dalam RPL

Waterfall Model / Linear Sequential Model

Waterfall model adalah model yang melakukan pendekatan pada perkembangan perangkat lunak secara seistematik dan sekuensial. Yang artinya kegiatan pada model ini dilakukan secara terurut berdasarkan panduan proses mulai dari komunikasi kepada client atau pelanggan sampai dengan aktifitas sampai pengorderan setelah masalah dipahami secara lengkap dan berjalan stabil sampai selesai.

(Menurut referensi Pressman )

Gambar 4.

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 :

• Logika internal PL : memastikan bahwa semua statement telah diuji
• Fungsi eksternal : mengarahkan testing untuk menemukan kesalahan-kesalahan 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.

Gambar 5.

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.

Gambar 6.

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.

Gambar.7

Dalam model Incremental ini proses pengerjaan perangkat lunak akan dilakukan perbagian sehingga bagian selanjutnya akan dikerjakan setelah bagian awal telah selesai dan selanjutnya sampai menghasilkan perangkat lunak yang lengkap dengan semua fungsi yang diperlukan dan pengerjaan perangkat lunak berakhir. Sebelum pengerjaan perangkat lunak akan dilakukan perancangan arsitektur software sebagai kerangka dalam pengerjaan perbagian.

Tahapan dari Incremental Model :

• Requirement -> penentuan kebutuhan perangkat lunak yang akan dibangun.
• Specification -> spesifikasi bagian dari perangkat lunak.
• Architecture Design -> pembuatan perancangan perangkat lunak (dasar dari kerangka kerja)

Kelebihan incremental model

• Resiko yang rendah pada pengembangan sistem.
• Mengutamakan fungsi-fungsi pada sistem perangkat lunak sehingga kemudahan pemakaian sistem yang paling di utamakan.
• Tahap awal adalan dasar dari pembuatan tahap berikutnya (dikerjakan secara terurut)

The Spiral Model

         Spiral model adalah model proses yang pendekatannya bersifat realistis pada software besar karena proses dari awal sampai proses pengiriman dan perbaikan dapat dipahami dnegan baik oleh clieent dan developer. Model ini mempunyai rangkaian kerja yang iterasi (peningkatan pada model) awal yang berbentuk prototype dan kemudian iterasi selanjutnya akan menjadi perkembangan dari model sebelumnya. Model ini dapat terus digunakan meskipun software sudah dikirimkan karena proses (siklus)dapat berputar lagi jika ada perubahan pada software sampai tidak ada permintaan perupbahan pada software oleh client.

Ada 6 pembagian proses pembuatan pada spiral model : 

• Komunikasi Pelanggan
•  Perencanaan
• Analisis resiko
•    Perekayasaan
•  Konstruksi dan Peluncuran
•   Evaluasi Client

Kelebihan model Spiral :

Setiap tahap pengerjaan dibuat prototyping sehingga kekurangan dan apa yang diharapkan oleh client dapat diperjelas dan juga dapat menjadi acuan untuk client dalam mencari kekurangan kebutuhan.

Kekurangan model Spiral :

Banyak konsumen (Client) tidak percaya bahwa pendekatan secara evolusioner dapat dikontrol oleh kedua pihak. Model spiral mempunyai resiko yang harus dipertimbangkan ulang oleh konsumen dan developer.

Concurrent Development Model

Pada model ini aktifitas kerja dilakukan secara bersamaan, setiap proses kerja memiliki beberapa triger(pemicu) kerja dari aktifitas. Pemicu dapat berasal dari awal proses kerja maupun dari pemicu yang lain   karena setiap trigrer akan sling berhubungan.

Misalnya proses Desain akan berubah atau berhenti sementara karena ada perubahan permintaan kebutuhan dari konsumen(client).

Kekurangan dari model ini:

Berhentinya suatu kegiatan karena kegiatan yang lain tentunya akan menyebabkan pengunduran waktu dari target yang ditentukan, yang artinya akan semakin banyak waktu yang ditunda untuk pengerjaan. Lebih lama proses pembuatan terhenti akan lebih banyak timbul masalah saat mulainya proses pembuatan setelah terhenti.

Daftar Pustaka :
 Buku Pressman, Roger S. .”Software Enginering A practitioners Approach 7.edition.”
 Buku Pressman, Roger S. 2002.”Rekayasa Perangkat Lunak (Pendekatan Praktis).” 

Jauhari,Jaidan..“ModulRekayasaPerangkatLunak.”__:__.pdf.http://heckerlaye.files.wordpress.com/2009/11/modul-rekayasa-perangkat-lunak.pdf

-