Rekayasa Perangkat Lunak

“Model Spiral”
(Model Pengembangan RPL)

Di Susun Oleh :
Nama: Dwi Arianti
NIM: (090010233)
Kelas: F091

SEKOLAH TINGGI MANAJEMEN INFORMATIKA

DAN TEKNIK KOMPUTER - STIKOM BALI
DENPASAR – BALI
 Model Spiral Pada Model Pengembangan RPL
Model proses waterfall yang berorientasi dokumen telah diambil sebagai
standart umum oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi tidak
mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang
ditimbulkan dalam model tersebut.

Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang
dapat menggunakan semua model umum sepeti yang telah kita bicarakan
sebelumnya. Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan
pembuat perangkat lunak.

Pendekatan alternatif diusulkan oleh Boehm (1988). Boehm mengusulkan

sebuah model yang secara explisit menjelaskan bahwa resiko yang disadari mungkin
membentuk dasar model proses umum.

Model yang diusulkan Boehm berbentuk spiral dan merupakan kombinasi dari
Prototyping Model dengan Waterfall Model. Setiap tahapan model ini selalu
dilakukan Risk Analisys dan verifikasi atau testing.

Setiap loop dalam model ini mewakili sebuah tahap dari proses perangkat
lunak. Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan
bagaimana membentuk proyek ke dalam tahap-tahap. Perusahaan biasanya bekerja
dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau
ketika masalah-masalah ditemukan selama pembuatan proyek.

Setiap loop dibagi dalam 4 sektor sebagai berikut :

 Determine objectives

Menentukan permasalahan, menentukan alternatif dan obyek yang mendesak.

Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek
ditentukan. Rencana rinci manajemen juga ditulis lengkap. Pembuatan strategi-
strategi alternatif direncanakan sesuai dengan resiko yang ada.

 Risk Analysis

Analisis resiko, evaluasi, dan mencari solusi. Jika resiko tidak dapat ditemukan
solusinya, maka proses berhenti. Untuk setiap resiko yang telah diidentifikasi, akan
dibuat analisys rincinya. Kemudian diambil langkah-langkah untuk mengurangi
resiko. Contohnya, jika ada resiko bahwa persyaratan-persyaratan tidak tepat, maka
sebuah model contoh mungkin dapat dikembangkan.
  Engineering / develop

Melakukan proses rekayasa perangkat lunak. Setelah evaluasi resiko, sebuah

model pengembangan untuk sistem dipilih. Misalnya, jika resiko interface poengguna
yang dominan maka model pengembangan yang tepat mungkin pengembangan
evalusioner dengan menggunakan model contoh (prototype). Jika resiko keselamatan
yang diutamakan, model pengembangan yang sesuai adalah transformasi formal dan
seterusnya. Model waterfall mungkin tepat digunakan jika resiko yang diutamakan
adalah integrasi sistem

 Plan next phase

Penentuan rencana-rencana untuk tahap selanjutnya. Jika diputuskan untuk

melanjutkan pada loop spiral berikutnya maka proyek dibicaraka kembali dan
rencana dibuat untuk tahap selanjutnya/

Tidak perlu menggunakan satu model tunggal pada setiap loop spiral bahkan
dalam keseluruhan sistem perangkat lunak. Permodelan digunakan pada salah satu
spiral untuk memecahkan masalah kebutuhan. Kemudian dapat diikuti oleh model
konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan
bagian-bagian sistem yang memiliki persyaratan kesempatan yang tinggi.

Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya
dikombinasikan dengan yang lain. Permodelan waterfall, yang sangat bagus dalam
menentukan millestones dan permodelan spiral, yang sangat bagus dengan
menggunakan prototyping, merupakan kombinasi yang sering dipakai di dalam
kontrak-kontrak untuk perangkat lunak dewasa ini.

Bila tahapan risk analysis tidak dapat dilewati, maka proses dihentikan, tidak
mengijinkan proses kembali ke tahapan sebelumnya.

Berikut adalah gambar dari spiral model secara umum :

Risk Analysis yang dilakukan adalah :

 Project risk, mempengaruhi rencana proyek, contoh kekurangan sumber daya

 Technical risk, mempengaruhi tahap aktual, contoh : personil tidak terlatih di
tahap tersebut
 Bussines risk, mempengaruhi keinginan perusahaan untuk membuat software,
contoh : software tidak diperlukan

Prioritas resiko dapat dikategorikan sebagai berikut :

 Catastropik (luar biasa), contoh : penurunan kualitas yang luar biasa, biaya
yang tidak terkontrol
 Critical (kritis), contoh : tidak tepat waktu, biaya di luar perkiraan
 Marginal (ringan), contoh : penjadwalan yang terlambat
 Negligible (tidak berarti), contoh : penggunaan waktu proyek tidak optimal

Perbedaan mendasar antara model sprilal dengan model lainnya adalah

bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada. Resiko
adalah konsep yang sulit didefinisikan secara tepat. Secara informal resiko adalah
sesuatu yang sederhana yang dapat menyebabkan kesalahan. Contohnya, jika
bertujuan menggunakan pemrograman bahasa baru (new programming languge),
resiko yang mungkin adalah alat pengumpul yang digunakan tidak reliable dan tidak
menghasilkan code obyek yang efisien.

Resiko adalah sebagai hasil ketidakcukupan informasi. Resiko tersebut dapat

dipecahkan dengan pengenalan beberapa kegiatan yang dapat menutupi informasi
yang kurang meyakinkan. Dalam contoh di atas, resiko mungkin dapat diatasi
dengan survey pasar untuk menemukan alat pengumpul mana yang dapat digunakan
dan bagaimana kebaikan alat tersebut. Jika sistem ternyata tidak sesuai maka
keputusan untuk menggunakan bahasa harus diubah.

Siklus spiral dimulai dengan penggunaan tujuan-tujuan seperti kinerja, kegunaan,

dan seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan
dengan sebaik-baiknya kemudian diperhitungkan. Setiap alternatif diperhitungkan
bertentangan dengan tujuan. Ini biasanya menghasilkan identifikasi sumber resiko
proyek. Langkah selanjutnya adalah mengevaluasi resiko-resiko ini dengan aktivitas
seperti analisis yang lebih detail, pembuatan model / contoh, simulasi dan seterusnya.

Untuk menggunakan model spiral, Boehm menyarankan sebuah bentuk umum

yang dipenuhi dalam setiap daerah spiral. Bentuk ini mungkin dilengkapi pada
sebuah level abstrak atau perkiraan yang imbang dari pengembangan produk.