Model Proses Perangkat Lunak ?

10.55 | Label: Opini

By Audika

- Sekuensial linear

Gambar dibawah ini menggambarkan sekuensial linier untuk rekayasa perangkat lunak, yang sering disebut juga dengan “siklus kehidupan klasik” atau “model air terjun”. Model sekuensial linier mengusulkan sebuah pendekatan kepada perkembangan perangkat lunak sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian dan pemeliharaan. Dimodelkan setelah siklus rekayasa konvensional, model sekuensial linier melingkupi aktivitas-aktivitas sbb :

Rekayasa dan pemodelan sistem/informasi. Karena perangkat lunak selalu merupakan bagian dari sebuah sistem yang lebih besar, kerja dimulai dengan membangun syarat dari semua elemen sistem dan mengalokasikan beberapa subset dari kebutuhan ke perangkat lunak tersebut.

Analisis kebutuhan perangkat lunak. Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khususnya pada perangkat lunak. Untuk memahami sifat program yang dibangun, perekayasa perangkat lunak (analis) harus memahami domain informasi, tingkah laku, unjuk kerja, dan antar muka (interface) yang diperlukan. Kebutuhan baik untuk sistem maupun perangkat lunak didokumentasikan dan dilihat lagi dengan pelanggan.

Desain. Desain perangkat lunak sebenarnya adalah proses multi langkah yang berfokus pada empat atribut sebuah program yang berbeda; struktur data, arsitektur perangkat lunak, representasi interface, dan detail (algoritma) prosedural. Proses desain menerjemahkan syarat/kebutuhan ke dalam sebuah representasi perangkat lunak yang dapat diperkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi perangkat lunak.

Generasi Kode. Desain harus diterjemahkan ke dalam bentuk mesin yang bisa dibaca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.

Pengujian. Sekali kode dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika internal perangkat lunak, 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.

Pemeliharaan. Perangkat lunak akan mengalami perubahan setelah disampaikan kepada pelanggan. Perubahan akan terjadi karena kesalahan-kesalahan ditentukan, karena perangkat lunak harus disesuaikan untuk mengakomodasi perubahan-perubahan di dalam lingkungan eksternalnya, atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja. Pemeliharaan perangkat lunak mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang baru lagi.

Model sekuensial linier adalah paradigma rekayasa perangkat lunak yang paling luas dipakai dan paling tua. Masalah-masalah yang kadang-kadang terjadi ketika model sekuensial linier diaplikasikan adalah:

Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model ini. Meskipun model linier bisa mengakomodasi iterasi, model itu melakukannya dengan cara tidak langsung.
Kadang-kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya secara eksplisit.
Pelanggan harus bersikap sabar. Sebuah versi kerja dari program-program itu tidak akan diperoleh sampai akhir waktu proyek dilalui.
Pengembang sering melakukan penundaan yang tidak perlu. Bradac mendapatkan bahwa pada model ini banyak anggota tim proyek haus menunggu tim yang lain untuk melengkapi tugas yang saling memiliki ketergantungan.
Masing-masing dari masalah tersebut bersifat riil. Tetapi paradigma siklus kehidupan klasik memiliki tempat yang terbatas namun penting di dalam kerja rekayasa [erangkat lunak. Paradigma itu memberikan template di mana metode analisis, desain, pengkodean, pengujian dan pemeliharaan bisa dilakukan. Siklus kehidupan klasik tetap menjadi model bagi rekayasa perangkat lunak yang paling luas dipakai.

- Prototype

Sering seorang pelanggan mendefinisikan serangkaian sasaran umum bagi perangkat lunak, tetapi tidak melakukan mengidentifikasi kebutuhan output, pemrosesan, ataupun input detail. Pada kasus lain pengembang mungkin tidak memiliki kepastian terhadap efisiensi algoritma, kemampuan penyesuaian dari sebuah sistem operasi, atau bentuk-bentuk yang harus dilakukan oleh interaksi manusia dengan mesin. Dalam hal ini serta pada banyak situasi yang lain, protyping paradigma mungkin menawarkanpendekatan yang terbaik.

Prototyping paradigma dimulai dengan pengumpulan kebutuhan. Kemudian dilanjutkan dengan mengidentifikasi kebutuhan yang diketahui, dan area garis besar di mana definisi lebih jauh merupakan keharusan kemudian dilakukan “perancangan kilat”. Perancangan kilat berfokus pada penyajian dari aspek-aspek perangkat lunak tersebut yang akan nampak bagi pelanggan/pemakai. Prototipe tsb dievaluasi oleh pelanggan dan dipakai untuk menyaring kebutuhan pengembangan perangkat lunak. Iterasi terjadi pada saat prototipe disetel untuk memenuhi kebutuhan pelanggan, dan pada saat yang sama memungkinkan pengembang untuk secara lebih baik memahami apa yang harus dilakukannya.

Prototipe Paradigma

Para pemakai merasa enak dengan sistem aktual, sedangkan pengembang bisa membangunnya dengan segera. Tetapi prototyping bisa juga menjadi masalah karena alasan-alasan sbb :

1. Pelanggan melihat apa yang tampak sebagai versi perangkat lunak yang bekerja tanpa melihat bahwa prototipe itu dijalin bersama-sama, tanpa melihat bahwa kita belum mencantumkan kualitas perangkat lunak secara keseluruhan atau kemampuan pemeliharaan untuk jangka waktu yang panjang.

2. Pengembang sering membuat kompromi-kompromi implementasi untuk membuat prototipe bekerja dengan cepat.

Meskipun berbagai masalah bisa terjadi, prototipe bisa menjadi paradigma yang efektif bagi rekayasa perangkat lunak. Kuncinya adalah mendefinisikan aturan-aturan main pada saat awal; yaitu pelanggan dan pengembang keduanya harus setuju bahwa prototipe dibangun untuk berfungsi sebagai mekanisme pendefinisian kebutuhan.

- RAD

Rapid application development (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan. Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final.

Penerapan model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang dicapai dengan menerapkan:

Component based construction ( pemrograman berbasis komponen bukan prosedural).
Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada.
Pembangkitan kode program otomatis/semi otomatis.
Multiple team (banyak tim), tiap tim menyelesaikan satu tugas yang selevel tapi tidak sama. Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun.

Jika keutuhan yang diinginkan pada tahap analisis kebutuhan telah lengkap dan jelas, maka waktu yang dibutuhkan untuk menyelesaikan secara lengkap perangkat lunak yang dibuat adalah berkisar 60 sampai 90 hari. Model RAD hampir sama dengan model waterfall, bedanya siklus pengembangan yang ditempuh model ini sangat pendek dengan penerapan teknik yang cepat.

Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan beberapa tim dalam waktu yang hampir bersamaan dalam waktu yang sudah ditentukan. Model ini melibatkan banyak tim, dan setiap tim mengerjakan tugas yang selevel, namun berbeda. Sesuai dengan pembagian modul sistem.

Beberapa hal (kelebhan dan kekurangan) yang perlu diperhatikan dalam implementasi pengembangan menggunakan model RAD :

Model RAD memerlukan sumber daya yang cukup besar, terutama untuk proyek dengan skala besar.
Model ini cocok untuk proyek dengan skala besar.
Model RAD memerlukan komitmen yang kuat antara pengembang dan pemesssan, bahkan keduanya bisa tergabung dalam 1 tim
Kinerja dari perangkat lunak yang dihasilkan dapat menjadi masalah manakala kebutuhan-kebutuhan diawal proses tidak dapat dimodulkan, sehingga pendekatan dengan model ini kurang bagus.
Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini.
Penghalusan dan penggabungan dari beberapa tim di akhir proses sangat diperlukan dan ini memerlukan kerja keras.
Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi
Risiko teknis yang tinggi juga kurang cocok untuk model ini.

- Assembly

Assembly atau lebih umum dikenal sebagai Bahasa rakitan adalah bahasa pemrograman tingkat rendah yang digunakan dalam pemrograman komputer, mikroprosesor, pengendali mikro, dan perangkat lainnya yang dapat diprogram. Bahasa rakitan mengimplementasikan representasi atas kode mesin dalam bentuk simbol-simbol yang secara relatif lebih dapat dipahami oleh manusia. Berbeda halnya dengan bahasa-bahasa tingkat tinggi yang berlaku umum, bahasa rakitan biasanya mendukung secara spesifik untuk suatu ataupun beberapa jenis arsitektur komputer tertentu. Dengan demikian, portabilitas bahasa rakitan tidak dapat menandingi bahasa-bahasa lainnya yang merupakan bahasa pemrograman tingkat tinggi. Namun demikian, bahasa rakitan memungkinkan programmer memanfaatkan secara penuh kemampuan suatu perangkat keras tertentu yang biasanya tidak dapat ataupun terbatas bila dibuat dengan menggunakan bahasa pemrograman tingkat tinggi.

Pada bahasa rakitan, programmer umumnya menggunakan sebuah program utilitas yang disebut sebagai perakit (bahasa Inggris: assembler) yang digunakan untuk menerjemahkan kode dalam bahasa rakitan tersebut ke dalam kode mesin untuk perangkat keras tertentu. Sebuah perintah dalam bahasa rakitan biasanya akan diterjemahkan menjadi sebuah instruksi mnemonic dalam kode mesin, berbeda halnya dengan kompiler pada bahasa pemrograman tingkat tinggi yang menerjemahkan sebuah perintah menjadi sejumlah instruksi dalam kode mesin.

Beberapa perangkat lunak bahasa rakitan terkenal biasanya menyediakan tambahan fitur untuk memgasilitasi proses pengembangan program, mengontrol proses perakitan, dan alat bantu debugging.

Ada beberapa dasar alasan menggunakan bahasa rakitan dilihat dari sudut pandang penggunaannya:

· Bahasa rakitan dibandingkan dengan bahasa mesin, bahasa rakitan merupakan representasi atas bahasa mesin yang dirancang agar lebih mudah dipahami oleh manusia. Dengan menggunakan bahasa rakitan, seorang programmer dapat lebih mudah mengingat instruksi-instruksi dengan menggunakan simbol yang lebih dapat dimengerti dibandingkan bila menggunakan simbol mnemonic kode mesin secara langsung. Demikian halnya pula dengan mekanisme lompatan yang umum terdapat dalam bahasa mesin yang biasanya menggunakan alamat memori, programmer dapat lebih mudah menggunakan fasilitas labeling yang terdapat bahasa rakitan dibandingkan menggunakan alamat memori tertentu dalam kode mnemonic.

· Bahasa rakitan dibandingkan dengan bahasa tingkat tinggi, bahasa rakitan memungkinkan programmer untuk mengontrol serta memanfaatkan secara penuh kapabilitas yang terdapat atas suatu perangkat keras, berbeda halnya dengan bahasa pemrograman tingkat tinggi yang memiliki banyak keterbatasan dalam pemanfaatan secara penuh suatu perangkat keras. Bahasa rakitan menjanjikan tingkat unjuk kerja yang maksimum karena sifatnya yang menerjemahkan secara langsung instruksi rakitan menjadi instruksi mesin, berbeda halnya dengan bahasa pemrograman tingkat tinggi yang biasanya menerjemahkan sebuah instruksi menjadi sejumlah kode mesin.

- Inkremental

Model inkremental menggabungkan elemen-elemen model sekuensial linier dengan filosofi prototipe iteratif. Pada saat model pertambahan dipergunakan, pertambahan pertama sering merupakan produk inti (core product), yaitu sebuah model pertambahan yang dipergunakan, tetapi beberapa muka tambahan tetap tidak disampaikan. Produk inti tersebut dipergunakan oleh pelanggan (atau mengalami pengkajian lebih detail). Sebagai hasil dari pemakaian dan/atau evaluasi, maka dikembangkan rencana bagi pertambahan selanjutnya. Rencana tersebut menekankan modifikasi produk inti untuk secara lebih baik memenuhi kebutuhan para pelanggan dan penyampaian fitur serta fungsionalitas tambahan. Proses ini diulang mengikuti penyampaian setiap pertambahan sampai bisa menghasilkan produk yang lengkap.

Model proses pertambahan tersebut, seperti model prototipe dan pendekatan-pendekatan evolusioner yang lain, bersifat iteratif. Tetapi tidak seperti model prototipe, model pertambahan berfokus pada penyampaian produk operasional dalam setiap pertambahannya. Pertambahan awal ada di versi stripped down dari produk akhir, tetapi memberikan kemampuan untuk melayani pemakai dan juga menyediakan platform untuk evaluasi oleh pemakai.

Reference by: Michaele