REKAYASA PERANGKAT LUNAK

Model Proses Pada Perangkat Lunak

Dalam rekayasa perangkat lunak, proses adalah resep kaku nota untuk bagaimana untuk membangun perangkat lunak komputer. Sebaliknya, itu adalah pendekatan beradaptasi yang memungkinkan orang melakukan pekerjaan (tim software) untuk memilih dan memilih set sesuai tindakan dan tugas bekerja. Tujuannya adalah selalu untuk memberikan software secara tepat waktu dan dengan kualitas yang cukup untuk memenuhi orang-orang yang telah mensponsori penciptaan dan mereka yang akan menggunakannya.

Sebuah kerangka proses menetapkan dasar untuk proses rekayasa perangkat lunak lengkap dengan mengidentifikasi sejumlah kecil aktivitas kerangka kerja yang berlaku untuk semua proyek perangkat lunak, terlepas dari ukuran atau kompleksitas. Selain itu, kerangka proses meliputi satu set payung activitiesthat berlaku di seluruh proses perangkat lunak seluruh. Sebuah kerangka proses generik untuk rekayasa perangkat lunak meliputi lima kegiatan:

Komunikasi.
Sebelum pekerjaan teknis dapat dimulai, pentingnya untuk berkomunikasi dan berkolaborasi dengan pelanggan (dan lainnya stakeholder). Tujuannya adalah untuk memahami tujuan stakeholder 'untuk proyek dan untuk mengumpulkan persyaratan yang membantu mendefinisikan fitur perangkat lunak dan fungsi.

Perencanaan.
Setiap perjalanan yang rumit dapat disederhanakan jika peta itu ada. Sebuah proyek perangkat lunak adalah perjalanan yang rumit, dan kegiatan perencanaan menciptakan "peta" yang membantu memandu tim karena membuat perjalanan. Peta-disebut proyek software rencana-mendefinisikan software engineering pekerjaan dengan menjelaskan tugas-tugas teknis yang akan dilakukan, risiko yang mungkin, sumber daya yang akan diperlukan, produk pekerjaan yang harus diproduksi, dan jadwal kerja.

Pemodelan.
Apakah Anda seorang penata taman, pembangun jembatan, seorang insinyur penerbangan, tukang kayu, atau arsitek, Anda bekerja dengan model setiap hari. Anda membuat "sketsa" dari hal sehingga Anda akan memahami gambaran-apa besar itu akan terlihat seperti arsitektur, bagaimana bagian-bagian penyusunnya cocok bersama-sama, dan karakteristik lainnya. Jika diperlukan, Anda memperbaiki sketsa ke dalam yang lebih besar dan lebih rinci dalam upaya untuk lebih memahami masalah dan bagaimana Anda akan mengatasinya. Seorang insinyur perangkat lunak melakukan hal yang sama dengan menciptakan model-model untuk lebih memahami kebutuhan perangkat lunak dan desain yang akan mencapai kebutuhan tersebut.

Konstruksi.
Kegiatan ini menggabungkan kode generasi (baik manual atau otomatis) dan pengujian yang diperlukan untuk mengungkap kesalahan dalam kode.

Deployment.
Perangkat lunak (sebagai entitas lengkap atau sebagai selisih sebagian selesai) dikirimkan ke pelanggan yang mengevaluasi disampaikan produk dan menyediakan umpan balik berdasarkan evaluasi.

MODEL-MODEL PROSES

1. Model Waterfall

Model ini meliputi sistem / teknik informasi dan pemodelan. Perangkat lunak merupakan bagian dari sistem yang lebih besar (atau bisnis). Pandangan sistem ini penting ketika perangkat lunak harus berinteraksi dengan unsur-unsur lain seperti perangkat keras, orang, dan database.

• Analisis/Requirements kebutuhan perangkat lunak. Persyaratan proses pengumpulan diintensifkan dan difokuskan secara khusus pada software.
• Rancangan. Desain perangkat lunak merupakan langkah yang berfokus pada empat atribut yang berbeda dari sebuah program, yaitu struktur data, arsitektur perangkat lunak, representasi interface, dan prosedural (algoritmik) rinci.
• Implementation/Pembuatan kode. Desain harus diterjemahkan ke dalam bentuk mesin yang dapat dibaca. Dalam tahap ini dilakukan pembuatan kode.
• Pengujian/Verification. Setelah kode telah dihasilkan, pengujian program dimulai. Pengujian yang dilakukan secara internal (benar tidaknya pernyataan yang dibuat dalam coding) dan eksternal (melakukan tes untuk menemukan kesalahan dan memastikan bahwa input sesuai dengan apa yang dibutuhkan).
• Maintenance/Dukungan (Support). Perangkat lunak akan mengalami perubahan setelah disampaikan kepada pelanggan.

2. Model Prototype

Pada model ini pengembang dan pelanggan bertemu dan menentukan tujuan keseluruhan untuk perangkat lunak dan mengidentifikasi objektif umum dari perangkat lunak. Prototipe ini diuji oleh pengguna dan digunakan untuk memperbaiki persyaratan untuk perangkat lunak yang akan dikembangkan.

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.

3. Model RAD (Rapid Application Development

Model ini merupakan model proses pengembangan perangkat lunak 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 (Bussiness Modelling)

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 (Data Modelling)

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 (Process Modelling)

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 (Application generation)

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 (Testing and turnover)

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

4. Model Proses Evolusioner

Model evolusioner adalah model yang ditandai dengan tingkah laku yang memungkinkan perekayasa perangkat lunak mengembangkan versi perangkat lunak yang lebih lengkap. Kebutuhan produk dan bisnis kadang-kadang berubah seiring dengan laju perkembanganya. Dalam situasi tersebut maupun lainya, perekayasa perangkat lunak membutuhkan sebuah model proses yang sudah dirancang secara eksplisit untuk mengakomodasi produk perkembangan sepanjang waktu. Model-model evolusioner meliputi :

• Model Incremental

Model incremental yaitu menggabungkan elemen-elemen model sekuensial linier yang di aplikasikan secara berulang. Model ini memakai urutan-urutan linier seiring dengan laju waktu kalender. Setiap urutan linier menghasilkan pertambahan, perangkat lunak yang bisa disampaikan. Pertambahan pertama dapat disebut sebagai produk inti (core product). Model ini termasuk gabungan dari model waterfall dan model prototype.

Model ini berfokus pada penyampaian produk operasional dalam Setiap pertambahanya. Pertambahan awal ada di versi stripped down dari produk akhir, tetapi memberikan kemampuan untuk melayani pemakai dan juga menyediakan platform untuk evaluasi oleh pemakai.

• Model Spiral

Model spiral ini adalah model proses perangkat lunak yang evolusioner, merangkai sifat iterative dari prototype dengan cara control dan aspek sistematis dari model sekuensial linier. Model yang berpotensi untuk pengembangan versi pertambahan perangkat lunak secara lbertahap dan cepat.

Model spiral dibagi menjadi sejumlah aktifitas kerangka kerja atau wilayah tugas, antara lain:

• Komunikasi pelanggan, tugas-tugas yang dibutuhkan untuk membangun komunikasi yang efektif diantara pengembang dan pelanggan.
• Perencanaan, tugas-tugas yang dibutuhkan untuk mendefinisikan sumber-sumber daya, ketepatan waktu, dan proyek informasi lain yang berhubungan.
• Analisis resiko, tugas-tugas yang dibutuhkan untuk menaksir resiko-resiko, baik manajemen maupun teknis.
•  Perekayasaan, tugas-tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut.
• Konstruksi dan peluncuran, tugas-tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang (instal), dan memberikan pelayanan kepada pemakai (contohnya pelatihan dan dokumentasi) 
• Evaluasi pelanggan, tugas-tugas untuk memperoleh umpan balik dari pelanggan dengan didasarkan pada evaluasi representasi perangkat lunak, yang dibuat selama masa perekayasaan, dan dimplementasikan selama masa pemasangan. 

5. Model Concurrent

Model ini disebut juga dengan concurrent engineering yang dapat digambarkan secara skematik sebagai serial dari kegiatan teknis utama, tugas-tugas, dan hubungan antar bagian-bagian yang saling terkait di mana aktifitas analisa seperti desain/rancangan atau komunikasi pelanggan dapat diskemakan dengan cara yang sama.

Concurrent process model cocok digunakan untuk pengembangan aplikasi client/server yang terdiri atas satu set komponen yang fungsional. Terdapat dua dimensi aktivitas yang digambarkan oleh model ini sebagai berikut.

Dimensi sistem: terdapat tiga proses di dalamnya yakni perancangan, perakitan (assembly) dan penggunaan (use).

Dimensi komponen: terdapat dua kegiatan utama yaitu perancangan dan realisasi.

Concurrency (pertemuan) dapat diperoleh dengan dua cara: 

1) sistem dan komponen kegiatan (aktifitas) terjadi secara simultan dan dapat diperagakan dengan memanfaatkan pendekatan yang berdasar pada status sebelumnya.

2) aplikasi client/server yang bersifat unik/khas di mana dapat diterapkan pada banyak komponen yang tiap-tiap komponen bisa dirancang dan direalisasikan secara serentak.

Sumber dikutip dari : Software Engineering Book. Sevent Edition. Pressman, S. Roger