BAB 2 || MODEL PROSES PERANGKAT LUNAK

Proses Perangkat Lunak

 sekumpulan aktifitas yang memiliki tujuan untuk pengembangan ataupun evolusi perangkat lunak, di mana 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 sebagai ad hoc
• Repeatable Proses-proses manajemen proyek dasar dibangun untuk menelusuri masalah biaya, jadwal dan fungsionalitas
• Defiend Proses perangkat lunak, baik untuk aktifitas manajemen atau perekayasaan didokumentasi, distandarkan dan diintregrasi kedalam proses perangkat lunak organisasi besar
• Management 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 perangkat lunak.

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

• Menentukan APA yang harus dikerjakan oleh perangkat lunak dalam suatu rentang waktu tertentu
• Mendefinikan BAGAIMANA perangkat lunak dibuat, mencakup arsitektur perangkat lunaknya, antarmuka internal, algoritma, dan sebagainya
• Penerapan (penulisan program) dan pengujian unit-unit program
• Validasi perangkat lunak secara keseluruhan (pengujian sistem)

Pemodelan 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 (workflow)-barisan kegiatan
• Perspektif Alur Data (data flow) - alur informasi
• Perspektif Peran - siapa melakukan apa

Model Sekuensial Linier (Waterfall)

Aktifitas model sekuensial linier meliputi:

• Rekayasa dan Pemodelan Sistem / Informasi
• Analsis Kebutuhan Perangkat Lunak
• Desain
• Generasi kode
• Pengujian (tes)
• Pemeliharaan

Model waterfall adalah model yang paling lama dan bayak secara luas digunakan sebagai paradigma untuk rekayasa software

Keuntungan : Sederhana, langkah secara terurut, fokus dan mudah diikuti

Kekurangan : 

• Tidak fleksibel sebab proyek yang nyata jarang mengikuti aliran yang terurut untuk menyusun model
• Sangat sulit untuk costumer terhadap menghadapi semua kebutuhan yang eksplisit
• Costumer harus memiliki kesabaran untuk menunggu keabsahan produk software dalam fase
• Yang terlambat
• Costumer tercakup dalam awal proyek
• Pembuat sering ditunda secara tidak berhubungan diantara fase

Model Prototipe

Model prototpe ini dimulai dengan mengumpulkan kebutuhan. Pengembang dan pelanggan bertemu dan mendenfinisikan obyektif keseluruhan dari perangkat lunak, dan mengidentifikasikan segala kebutuhan yang diketahui.

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 "prototype di bangun untuk berfungsi sebagai mekanisme pendefinisian kebutuhan

Keuntungan :

• Mudah dan cepat identifikasi kebutuhan costumer
• Costumer mengecek prototipe di awal tingkatan dan menyediakan input dan umpan baliknya

Model RAD

Rapid application Development (RAD) adalah sebuah model proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek

Pendekata RAD melingkupi fase-fase berikut:

• Pemodelan Data
• Pemodelan Bisnis
• Pemodelan Aplikasi
• Pengujian dan Turnover

Keuntungan: 

• Waktu pembuatan yang pendek
• Pengurangan biaya supaya software digunakan kembali dan konstruksi dasar komponen

Kelemahan:

• RAD butuh developer dan pelanggan yang diijinkan untuk menyusun
• Pembuatan software adalah spesifik proyek, dan tidak boleh dimodulkann secara baik

Model Proses Perangkat Lunak Evolusioner

Model proses klasik tidak dirancang untuk mengirim sistem yang produktif sehingga asumsiya pada :

• Sistem yang akan dikirimkan setelah urutan linear diselesaikan
• Costumer mengetahui yang mereka inginkan di tingkatan awal

Realita dalam proses pembuatan 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:

• the incremental model
• the spiral model
• the component assembely model
• the concurrent development model

Model Formal

Meskipun belum menjadi pendekatan utama, metode inin