Model Proses Perangkat Lunak

Ø   Proses Perangkat Lunak

Sekumpulan aktifitas yang memiliki tujuan untuk pengembangan ataupun evolusi perangkat lunak dimana setiap aktifitas bersifat saling terkait (koheren) untuk menspesifikasikan, merancang, implementasi dan pengujian sistem perangkat lunak.

Aktifitas generic dalam semua proses perangkat lunak adalah :

·         Initial : Proses perangkat lunak yang ditandai dengan ad hoc.

·         Repeatable : Proses-proses manajemen proyek dasar dibangun untuk menelusuri masalah biaya, jadwal, dan fungsionalitas.

·         Defined : Proses perangkat lunak baik untuk aktifitas manajemen atau perekayasaan di dokumentasikan, distandarkan dan diintegrasikan ke dalam proses perangkat lunak organisasi besar.

·         Managed : Pengukuran detail terhadap proses perangkat lunak dan kualitas produksi dikumpulkan.

·         Optimizing : Pertambahan proses yang terus menerus dimungkinkan oleh umpan balik kuantitatif dari proses dan dari gagasan inovatif pengujian serta teknologi

Ø  Pengembangan Perangkat Lunak

Pengembangan perangkat lunak adalah suatu proses dimana kebutuhan pemakai diterjemahkan menjadi produk lunak. Proses ini mencakup aktifitas penerjemahan kebutuhan pemakai menjadi kebutuhan perangkat lunak, transformasi kebutuhan perangkat lunak menjadi desain, penerapan desain menjadi kode program, uji coba kode program, dan instalasi serta pemeriksaan kebenaran perangkat lunak untuk operasional.

Berdasarkan pengertian tersebut, secara umum dapat dikatakan bahwa proses pengembangan perangkat lunak mengikuti tahap-tahap:

1.       Menentukan apa yang harus dikerjakan oleh perangkat lunak dalam satu rentang waktu tertentu

2.      Integrasi dan pengujian modul-modul program 

3.      Validasi perangkat lunak secara keseluruhan (pengujian sistem)

Ø  Model Proses Perangkat Lunak

Model proses perangkat lunak merupakan suatu representasi proses perangkat lunak yang disederhanakan, dipresentasikan dan perspektif khusus. Contoh perspektif proses :

- Perspektif alur-kerja (work flow) - barisan kegiatan

- Perspektif alur-data (data flow) - alur informasi

- Perspektif peran atau aksi - siapa melakukan apa

Ø  Model Sekuensial Linier (Waterfall)

Sekuensial linier mengusulkan sebuah pendekatan kepada perkembangan perangkat lunak yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian dan pemeliharaan.

Fase lingkaran pemecahan masalah

Aktifitas Model Sekuensial Linier meliputi:

Rekayasa dan Pemodelan Sistem atau Informasi.

Karena perangkat lunak merupakan bagian dari sebuah sistem (bisnis) yang lebih besar, kerja dimulai dengan membangun syarat dari semua elemen sistem dan mengalokasikan beberapa subset dari kebutuhan ke perangkat lunak tersebut. Pandangan sistem ini penting ketika perangkat lunak harus berhubungan dengan elemen-elemen yang lain seperti perangkat lunak, manusia dan database.

Analisis kebutuhan perangkat lunak

Proses pengumpulan kebutuhan difokuskan khususnya untuk perangkat lunak, perekayasa perangkat lunak (analisis) harus memahami domain permasalahan (problem domain), tingkah laku, unjuk kerja dan antar muka (interface) yang diperlukan. Kebutuhan baik untuk sistem maupun perangkat lunak di dokumentasikan 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 atau kebutuhan ke dalam sebuah representasi perangkat lunak yang dapat diperkirakan demi kualitas sebelum dimulai pemunculan kode (coding).

Generasi Kode

Desain harus diterjemahkan ke dalam bentuk mesin yang bisa dibaca. langkah pembuatan kode meliputi pekerjaan dalam langkah ini, dan dapat dilakukan secara mekanis.

Pengujian (Tes)

Sekali kode dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika internal perangkat lunak, memastikan bahwa semua pernyataan sesudah 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 pada pelanggan (perkecualian yang mungkin adalah perangkat lunak yang diletakkan). Perubahan akan terjadi karena kesalahan-kesalahan karena perangkat lunak harus disesuaikan untuk mengakomodasi perubahan-perubahan di dalam lingkungan eksternalnya atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja.

Model Waterfall adalah model yang paling lama dan banyak secara luas digunakan sebagai paradigmauntuk rekayasa software.
Keuntungan : Sederhana, langkah secara terurut, fokus, dan mudah diikuti
Permasalahan :
- Tidak fleksibel sebab proyek yang nyata jarang mengikuti aliran yang terurut untuk menyusun model
-  Sangat sulit untuk customer terhadap menhadapi semua kebutuhan yang eksplisit
- Customer harus memiliki kesabaran untuk menunggu keabsahan produk software
- Customer tercakup dalam awal proyek
- Pembuat sering ditunda secara tidak berhubungan diantara fase

Ø  Model Prototype

Model prototype ini dimulai dengan mengumpulkan kebutuhan. Pengembang dan pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari perangkat lunak, dan mengidentifikasi segala kebutuhan yang diketahui

Model Prototipe

Secara ideal prototipe berfungsi sebagai sebuah mekanisme untuk mengidentifikasi keutuhan perangkat lunak. 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 mekanisme pendefinisian kebutuhan. Prototipe kemudian disingkirkan dan perangkat lunak actual direkayasa dengan tertuju kepada kualitas dan kemampuan pemeliharaan.

Keuntungan: 

Mudah dan cepat identifikasi kebutuhan customer

Customer mengecek prototipe di awal tingkatan dan menyediakan input dan umpan baliknya

Persetujuan yang baik dengan mengikuti kasus: customer tidak bisa menyediakan kebutuhan yang jelas, menggunakan teknologi baru, hardware dan algoritma

Masalah:

Developer biasa ikut membuat produk didasarkan pada prototipe 

Developer sering membuat perjanjian implementasi dalam memerintahkan untuk prototipe agar bekerja secara cepat

Ø  Model RAD

Rapid Application Development (RAD) adalah sebuah model proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi "kecepatan tinggi" dari model sekuensial linier dimana perkembangan cepat dicapai dengan menggunakan pendekatan konstruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan merupakan "sistem fungsional yang utuh" dalam periode waktu yang sangat pendek (kira-kira 60-90 hari)

Pendekatan RAD melingkupi fase-fase sebagai berikut:

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

2.      Pemodelan Data
aliran informasi yang didefinisikan sebagai bagian dari fase business modelling disaring kedalam serangkaian objek data yang dibutuhkan untuk mendukung bisnis tersebut.

3.      Pemodelan Proses
aliran informasi yang didefinisikan di dalam fase data modelling ditransfirmasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus atau mendapatkan kembali sebuah objek data.
Pembentukan Aplikasi

Keuntungan dan masalah yang ada pada model RAD :

Keuntungan : 

Waktu pembuatan yang pendek

Pengurangan biaya supaya software digunakan kembali dan konstruksi dasar komponen

Masalah :

RAD butuh developer dan pelanggan yang diijinkan untuk menyusun

Pembuatan software  adalah spesifik proyek, dan tidak boleh dimodulkan secara baik

Kualitasnya tergantung pada kualitas dari komponen yang ada

Proyek yang tidak akurat dengan resiko teknik yang tinggi dan teknologi

Ø  Model Proses Perangkat Lunak Evolusioner

Model proses klasik tidak dirancang untuk mengirimkan sistem yang produktif sehingga asumsinya pada:

Sistem yang sempurna akan dikirimkan stelah urutan linier diselesaikan

Customer mengetahui yang mereka inginkan ditingkatan awal

Realita dalam proses pemuatan software

Banyaknya kebutuhan perubahan selama latihan pembuatan

Banyaknya aktifitas iterasi dan bekerja sebab evolusi alami dari produksi software

Persetujuan yang sulit dengan evolusi produk, beberapa evolusi model proses yang disusun:

a.      the increment model

b.      the spiral model

c.       the component assembly model (model rakitan komponen)

d.      the concurrent development model (model perkembangan konkuren)

 Incremental Model

merupakan kombinasi linier sekuensial model (diaplikasikan secara berulang) dan filosofi pengulangan dari prototyping model. Setiap tahapan linier sekuensial model menghasilkan deliverable increment bagi perangkat lunak, dimana increment pertamanya merupakan sebuah produk inti yang mewakili kebutuhan dasar sistem. Produk inti ini nantinya dikembangkan menjadi increment-increment selanjutnya setelah digunakan dan dievaluasi sampai didapat produk yang lengkap dan memenuhi kebutuhan pemakai.
Kelemahan:
- hanya akan berhasil jika tidak ada staffing untuk penerapan secara menyeluruh
- penambahan staf dilakukan jika hasil increment akan dikembangkan labih lanjut

Spiral Model

merupakan model proses perangkat lunak yang memadukan wujud pengulangan dari model prototyping dengan aspek pengendalian dan sistematika dari linier sekuensial model. Dalam model ini perangkat lunak dikembangkan dalam suatu seri incremental release. Spiral model dibagi menjadi 6 aktivitas kerangka kerja sebagai berikut:

-  Komunikasi dengan pemakai

- Perencanaan

- Analisis resiko

- Rekayasa

- Konstruksi dan pelepasan

- Evaluasi

 Model Rakitan Komponen

Menggabungkan berbagai karakteristik dari spiral model. Pembuatan aplikasi dengan pendekatan model ini dibangun dari komponen-komponen perangkat lunak yang sudah dipaketkan sebelumnya dengan cakupan aktifitas sebagai berikut:

a.      mengidentifikasi calon-calon komponen (kelas objek)

b.      melihat komponen-komponen dalam pustaka

c.       mengekstrak komponen jika ada

d.      membangun komponen jika ada

e.      menyimpan komponen baru pada pustaka

f.        mengkonstruksi interaksi ke-n dari sistem

model rakitan komponen

 Model Perkembangan Konkuren

Model perkembangan konkuren juga disebut rekayasa konkuren. Model proses yang konkuren dapat disajikan secara skematis sebagai sederetan aktifitas teknik mayor, tugas-tugas, dan keadaan yang lain. Contohnya aktiftas rekayasa yang dibatasi untuk model spiral dipenuhi dengan melakukan prototyping atau pemodelan analisis, spesifikasi kebutuhan dan rancangan.

Model Formal

Metode formal mencakup sekumpulan aktifitas yang membawa kepada spesifikasi matematis perangkat lunak komputer. Metode ini memungkinkan perekayasa untuk mengkhususkan, mengembangkan, dan memverifikasi sistem berbasis komputer dengan menggunakan sistem matematis yang tepat. Variasi dalam pendekatan ini disebut juga clean-room rekayasa perangkat lunak.

Meskipun belum menjadi pendekatan utama, metode ini sudah dapat menjanjikan perangkat lunak yang bebas dari cacat atau kesalahan, tetapi perhatian tentang kemampuan aplikasinya sudah mulai disuarakan:

Pengembangan model format banyak memakan waktu dan mahal

Perlu latihan yang ekstensif

Sulit untuk menggunakan model-model sebagai sebuah mekanisme komunikasi bagi pemakai yang secara teknik belum canggih

Teknik Generasi Keempat

menggunakan perangkat bantu yang akan membuat kode sumber secara otomatis berdasarkan spesifikasi dari pengembang perangkat lunak. Hanya digunakan untuk mengembangkan perangkat lunak yang menggunakan bentuk bahasa khusus atau notasi grafik yang diselesaikan dengan syarat yang dimengerti pemakai.

Cakupan aktifitas 4GT:
~ Pengumpulan kebutuhan
~ Translasi kebutuhan menjadi prototype operasional atau langsung melakukan implementasi secara langsung dengan menggunakan bahasa generasi keempat (4GL) jika aplikasi relatif kecil
~ Untuk aplikasi yang cukup besar, dibutuhkan strategi perancangan sistem walaupun 4GL akan digunakan
~ Pengujian
~ Membuat dokumentasi
~ Melakukan seluruh aktifitas untuk mengintegrasikan solusi-solusi yang membutuhkan paradigma rekayasa perangkat lunak lainnya.

Salah satu keuntungan menggunakan model 4GT adalah pengurangan waktu dan peningkatan produktifitas secara besar, sementara kekurangannya terletak pada kesulitan penggunaan perangkat bantu dibandingkan dengan bahasa pemrograman, dan juga kode sumber yang dihasilkan tidak efisien.