MAKALAH REKAYASA PERANGKAT LUNAK

Model Proses RPL

Disusun Oleh
Verick Lesly (2055202005)

Fakultas Ilmu Komputer

Program Studi Teknik Informatika

Institut Bisnis dan Teknologi Pelita Indonesia

2023
 KATA PENGANTAR

Puji dan syukur penulis ucapkan atas kehadirat Tuhan Yang Maha Esa karena segala
rahmat-Nya sehingga kami dapat menyelesaikan tugas makalah yang berjudul Model Proses
RPL , Penyusunan Daftar Pustaka ini tepat pada waktunya.

Adapun tujuan dari penulisan dari makalah ini adalah untuk memenuhi tugas
dosen pada mata kuliah Rekayasa Perangkat Lunak. Selain itu, makalah ini juga bertujuan
untuk menambah wawasan tentang model proses RPL.

Tidak lupa kami mengucapkan terima kasih kepada Bapak Wahyu Joni Kurniawan,
M.KOM selaku dosen pengampu Rekayasa Perangkat Lunak yang telah memberikan tugas
ini sehingga dapat menambah pengetahuan dan wawasan.

Kami menyadari sepenuhnya bahwa makalah ini masih jauh dari kata sempurna. Oleh
karena itu, kami mengharapkan segala bentuk saran serta masukan bahkan kritik yang
membangun dari berbagai pihak.

Pekanbaru, 03-04-2023

Verick Lesly

ii
 DAFTAR ISI

KATA PENGANTAR.........................................................................................................................ii
DAFTAR ISI.......................................................................................................................................iii
BAB I PENDAHULUAN....................................................................................................................1
1.1 Latar Belakang.....................................................................................................................1
1.2 Rumusan Masalah................................................................................................................2
1.3 Tujuan Penelitian.................................................................................................................2
BAB II PEMBAHASAN.....................................................................................................................3
2.1 Model Waterfall.....................................................................................................................3
2.2 Model Prototyping.................................................................................................................6
2.3 Model Evolutionary...............................................................................................................8
2.4 Model Spiral.........................................................................................................................10
2.5 Model Reuse Based Development.......................................................................................14
BAB III PENUTUP...........................................................................................................................15
3.1 Kesimpulan..........................................................................................................................15
DAFTAR PUSTAKA........................................................................................................................16

iii
 BAB I
PENDAHULUAN
1.1 Latar Belakang

Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang dilakukan di
tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih
memungkinkan tanpa melakukan suatu pemodelan. Namun hal itu tidak dapat lagi dilakukan
dalam suatu industri perangkat lunak. Pemodelan delam perangkat lunak merupakan suatu
yang harus dikerjakan di bagian awal dari rekayasa, dan pemodelan ini akan mempengaruhi
perkerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut.

Pada rekayasa perangkat lunak, banyak model yang telah dikembangkan untuk membantu
proses pengembangan perangkat lunak. Model-model ini pada umumnya mengacu pada
model proses pengembangan sistem yang disebut System Development Life Cycle (SDLC).

Setiap model yang dikembangkan mempunyai karakteristik sendiri. Namun secara umum ada
persamaannya, yaitu :

 Kebutuhan terhadap definisi masalah yang jelas. Input utama dari setiap model
pengembangan perangkat lunak adalah pendefinisian masalah yang jelas. Semakin
jelas akan semakin baik karena akan memudahkan dalam penyelesaian masalah. Oleh
karena itu pemahaman masalah merupakan bagian penting dari model pengembangan
perangkat lunak.

 Tahapan-tahapan pengembangan yang teratur. Meskipun model-model

pengembangan perangkat lunak memiliki pola yang berbeda-beda, biasanya model-
model tersebut mengikuti pola umum analysis – design – coding – testing –
maintenance.

 Stakeholder berperan sangat penting dalam keseluruhan tahapan pengembangan.

Stakeholder dalam rekayasa perangkat lunak dapat berupa pengguna, pemilik,
pengembang, pemrogram dan orang-orang yang terlibat dalam rekayasa perangkat
lunak tersebut.

iv
  Dokumentasi merupakan bagian penting dari pengembangan perangkat lunak.
Masing-masing tahapan dalam model biasanya menghasilkan sejumlah tulisan,
diagram, gambar atau bentuk-bentuk lain yang harus didokumentasi dan merupakan
bagian tak terpisahkan dari perangkat lunak yang dihasilkan.

 Keluaran dari proses pengembangan perangkat lunak harus bernilai ekonomis. Nilai
dari sebuah perangkat lunak sebenarnya agak susah dirupiah- kan. Namun efek dari
penggunaan perangkat lunak yang telah dikembangkan haruslah memberi nilai
tambah bagi organisasi. Hal ini dapat Setiap model yang dikembangkan mempunyai
karakteristik sendiri-sendiri

1.2 Rumusan Masalah

Adapun rumusan masalah yang dibuat dalam pembuatan makalah ini yaitu :

1. Jelaskan apa saja model proses RPL?

1.3 Tujuan Penelitian

Adapun beberapa tujuan dari pembuatan makalah ini yaitu :

1. Untuk mengetahui macam macam model proses RPL

2.

v
 BAB II
PEMBAHASAN
2.1 Model Waterfall

Pengertian Metode Waterfall adalah metode pengembangan perangkat lunak yang

memungkinkan pembuatan sistem dilakukan secara terstuktur dan sistematis (berurutan)
sesuai dengan siklus pengembangan yang ada.

Metode ini disebut waterfall atau air terjun karena dalam prosesnya, sistem akan dibuat
berurutan setahap demi setahap. Mulai dari tahapan;

 Requirement
 Design
 Implementation
 Verification dan
 Maintenance 

Dalam metode ini. Jika tahapan 1 belum selesai, maka tahapan 2 tidak bisa berjalan,
begitupun seterusnya. Semua tahapan saling berkaitan dan masing-masing harus dikerjakan
secara detail dan terdokumentasi.

Metode waterfall mengharuskan setiap spesifikasi, persyaratan dan tujuan sistem

terdefinisikan secara detail di tahap awal (requirement & design) sebelum masuk pada proses
pengerjaan (implementasi).

Ini dikarenakan metode waterfall tidak mengakomodir perubahan di tengah proses

pengembangan. Jadi apa yang telah disepakati bersama oleh tim analis dan klien di tahap
awal, itulah yang akan menjadi hasil akhir.

Semuanya harus mematuhi dan konsisten terhadap hal tersebut sampai aplikasi selesai dan
diserahkan pada pihak klien.

vi
Pihak klien sendiri tidak bisa melakukan ‘intervensi’ pada para programmer, ini berbeda
dengan beberapa model pengembangan lain yang memungkinkan keduanya berkomunikasi
untuk menentukan atau merevisi pekerjaan di tahap peng-codingan.

Jenis Metode air terjun ini umumnya digunakan pada proyek pembuatan sistem besar dengan
kompleksitas tinggi serta membutuhkan sumber daya manusia yang banyak dalam
pembangunannya.

1. Requirement (Analisis Kebutuhan)

Requirement adalah proses analisa atau pengumpulan data-data yang berkaitan dengan sistem
yang akan dibuat. Pengumpulan data ini bisa dilakukan dengan wawancara, studi literatur,
observasi atau penelitian langsung.

Dalam fase ini tim analis akan menggali informasi sebanyak-banyaknya dari klien atau user
tentang software apa yang mereka inginkan beserta dengan kebutuhan sistem lainnya.

Hasil dari tahapan ini akan menghasilkan dokumen bernama “User Requirement Document”
atau “User Requirement Specification” yang dalam bahasa Indonesia dikelan dokumen
Spesifikasi kebutuhan user.

Tahapan analisis kebutuhan (requirements) memiliki beragam istilah lain, diantaranya

adalah system requirements, costumer requirement gathering, analysis ataupun analisa
kebutuhan user.

vii
2. Design System (Desain Sistem)
Proses ini akan berfokus pada pembangunan struktur data, arsitekur perangkat lunak,
perancangan interface, perancangan fungsi internal dan eksternal serta detail dari setiap
algoritma prosedural.

Tahapan design akan menghasilkan dokumen bernama “Sofware Requirement” yang

nantinya  menjadi landasan para programmer dalam membuat code-code aplikasi.

3. Implementasi (Pengerjaan)
Tahap ini adalah tahapan pembuatan aplikasi oleh para programmer dengan menggunakan
kode-kode bahasa pemrograman tertentu. Proses penulisan sinkode (coding) aplikasi
mengacu pada dokumen-dokumen yang telah dibuat sebelumnya.

Dalam dokumen tersebut biasanya terdapat pemecahan modul-modul sistem sehingga

pengerjaan aplikasi dapat dilakukan oleh beberapa programmer sekaligus tanpa mengganggu
sistem lain secara keseluruhan.

Tahap implementasi disebut juga tahap code and debug, atau juga disebut

tahapan integration and system testing.

4. Verification (Verifikasi)
Tahapan verifikasi meliputi pengintegrasian sistem dan juga melakukan testing terhadap
aplikasi yang telah dibuat. Sistem akan diverifikasi untuk diuji sejauh mana kelayakannya.

Dalam tahapan ini semua modul yang dikerjakan oleh programmer berbeda akan
digabungkan kemudian diuji apakah telah sesuai dengan spesifikasi yang ditetapkan atau
terdapat kesalahan/error dalam sistem sebelum kemudian diperbaiki ulang.

5. Maintenance (Pemeliharaan)
Tahapan ini umumnya meliputi tahapan penginstalasian perangkat lunak dan pengujian
aplikasi. Maintenance juga adalah bentuk tanggung jawab tim pengembang untuk
memastikan aplikasi dapat berjalan lancar setelah diserah-terima kan pada klien dalam
periode waktu tertentu.

Dalam definisi yang lebih luas, maintenance adalah proses memperbaiki aplikasi dari setiap
error atau bug celah keamanan, peningkatan kinerja aplikasi, memastikan aplikasi dapat

viii
berjalan pada ruang lingkup baru dan juga penambahan modul-modul baru untuk
pengembangan aplikasi.

Kelebihan :

1. Rangkaian kerja jelas

2. Berkomitmen pada tujuan akhir
3. Dokumentasi yang baik
4. Hemat waktu dan biaya
5. Cocok untuk pembuatan Software berskala besar

Kekurangan :

1. Membutuhkan Tim dan Manajemen yang solid

2. Kurang fleksibel bagi klien
3. Waktu pembuatan software lebih lama
4. Tidak bisa melihat gambaran sistem
5. Kenaikan biaya dan tanggal rilis

2.2 Model Prototyping

Prototype adalah salah satu model dalam pengembangan sistem Rekayasa Perangkat Lunak
dimana pengembang dan klien dapat saling membantu satu sama lain dalam merancang suatu
sistem. Tidak hanya ikut turut serta pada tahap awal saja, namun akan berlanjut terus hingga
pada tahap terakhir dan sistem dapat berjalan dengan baik sesuai dengan perencanaan.

Metode Prototype mempunyai beberapa kelebihan dan kekurangan, diantaranya:

Kelebihan Metode Prototype

 Menjalin komunikasi yang baik antara pengembang dan klien.

 Menghemat waktu dan biaya.

 Klien dapat berperan aktif

 Penerapan sistem akan lebih mudah dilakukan.

Kelemahan Metode Prototype

ix
  Tidak cocok pada sebuah sistem yang berskala besar.

 Biasanya pengembang hanya menggunakan bahasa pemrograman yang sederhana,

dikarenakan sistem tersebut tidak terlalu mementingkan segi keamanan.

Tahapan-tahapan :

1. Mengumpulkan Kebutuhan
Pengembang dan klien membahas mengenai kebutuhan apa saja yang akan
dibutuhkan dalam perancangan sistem tersebut.  Entah itu mengenai proses i/o, fitur-
fitur yang ada pada sistem, dan sebagainya.

2. Membangun Prototyping
Setelah kebutuhan sistem sudah terdata. Pengembang akan membuat perancangan
sistem secara sederhana terlebih dahulu sebagai contoh dasar atau gambaran sistem
yang akan digunakan oleh user.

3. Evaluasi Prototyping
Jika perancangan sistem sudah dibuat. Tahapan selanjutnya yaitu mengevaluasi hasil
prototyping yang telah dibuat oleh Pengembang. Aoakah sudah sesuai dengan
permintaan klien?

4. Pengkodean Sistem
Jika sistem sudah berhasil melalui tahap Evalusi Prototyping dan tidak ada yang di
revisi lagi. Maka Pengembang akan melakukan proses pengkodean sistem, dimana
Pengembang akan mengeksekusi apapun yang terdapat pada sistem menggunakan
bahasa pemrograman yang sesuai dengan kebutuhan.

x
 5. Pengujian Sistem
Setelah sistem sudah siap untuk dipakai. Belum tentu sudah bisa langsung digunakan
oleh user. Pada tahapan ini akan dilakukan suatu pengujian untuk mengetahui
seberapa besar keberhasilan sistem tersebut.

6. Evaluasi Sistem
Apakah sistem sudah berjalan dengan baik? Atau masih terdapat suatu kesalahan pada
sistem. Maka dari itu, klien mengevaluasi sistem untuk mengurangi resiko terjadi
error pada sistem. Agar sistem dapat dikatakan user friendly.

7. Penggunaan Sistem
Sistem yang sudah lolos melalui semua tahapan diatas, maka sistem sudah siap
digunakan secara umum oleh user.

2.3 Model Evolutionary

Model evolusioner merupakan kombinasi dari Iterative dan Incremental model

dari siklus hidup pengembangan perangkat lunak. Menyampaikan sistem Anda dalam
rilis besar, mengirimkannya dalam proses bertahap dari waktu ke waktu adalah tindakan
yang dilakukan dalam model ini. Beberapa persyaratan awal dan visi arsitektur perlu
dilakukan. Lebih baik untuk produk perangkat lunak yang rangkaian fiturnya
didefinisikan ulang selama pengembangan karena umpan balik pengguna dan faktor lainnya.
Model pengembangan Evolusioner membagi siklus pengembangan menjadi model air
terjun inkremental yang lebih kecil di mana pengguna bisa mendapatkan akses ke produk
di akhir setiap siklus. Umpan balik diberikan oleh pengguna pada produk untuk tahap
perencanaan siklus berikutnya dan tim pengembangan merespons, seringkali dengan
mengubah produk, rencana atau proses. Oleh karena itu, produk perangkat lunak berkembang
seiring waktu. Semua model memiliki kelemahan yaitu durasi waktu dari mulai proyek
hingga waktu pengiriman solusi sangat tinggi. Model evolusi memecahkan masalah ini
dengan pendekatan yang berbeda.

Keuntungan: Dalam model evolusioner, pengguna mendapat kesempatan untuk

bereksperimen dengan sistem yang dikembangkan sebagian. Ini mengurangi kesalahan
karena modul inti diuji secara menyeluruh. Kekurangan: Terkadang sulit untuk membagi
masalah menjadi beberapa versi yang dapat diterima pelanggan yang dapat diterapkan dan
disampaikan secara bertahap Model evolusioner juga disebut sebagai model versi

xi
berurutan dan terkadang sebagai model inkremental. Dalam model Evolutionary,
kebutuhan perangkat lunak pertama-tama dipecah menjadi beberapa modul (atau unit
fungsional) yang dapat dibangun dan dikirim secara bertahap . Pengembangan pertama kali
mengembangkan modul inti dari sistem. Modul inti adalah modul yang tidak membutuhkan
layanan dari modul lain. Kerangka produk awal disempurnakan menjadi tingkat
kemampuan yang meningkat dengan menambahkan fungsi baru dalam versi yang
berurutan. Setiap model evolusi dapat dikembangkan dengan menggunakan model
pengembangan air terjun iteratif.

Model evolusioner
merupakan kombinasi dari
Iterative dan Incremental
model
dari siklus hidup
pengembangan perangkat
lunak. Menyampaikan sistem
Anda
dalam rilis besar,
mengirimkannya dalam
proses bertahap dari waktu
ke waktu
xii
adalah tindakan yang
dilakukan dalam model ini.
Beberapa persyaratan awal dan
visi arsitektur perlu
dilakukan. Lebih baik untuk
produk perangkat lunak yang
rangkaian fiturnya
didefinisikan ulang selama
pengembangan karena umpan
balik
pengguna dan faktor lainnya.
Model pengembangan
Evolusioner membagi siklus
pengembangan menjadi
model air terjun inkremental
yang lebih kecil di mana
xiii
pengguna bisa mendapatkan
akses ke produk di akhir setiap
siklus.
Umpan balik diberikan oleh
pengguna pada produk untuk
tahap perencanaan
siklus berikutnya dan tim
pengembangan merespons,
seringkali dengan mengubah
produk, rencana atau proses.
Oleh karena itu, produk
perangkat lunak berkembang
seiring waktu.
Semua model memiliki
kelemahan yaitu durasi

xiv
waktu dari mulai proyek
hingga
waktu pengiriman solusi
sangat tinggi. Model evolusi
memecahkan masalah ini
dengan pendekatan yang
berbeda
Model evolusioner
merupakan kombinasi dari
Iterative dan Incremental
model
dari siklus hidup
pengembangan perangkat
lunak. Menyampaikan sistem
Anda

xv
dalam rilis besar,
mengirimkannya dalam
proses bertahap dari waktu
ke waktu
adalah tindakan yang
dilakukan dalam model ini.
Beberapa persyaratan awal dan
visi arsitektur perlu
dilakukan. Lebih baik untuk
produk perangkat lunak yang
rangkaian fiturnya
didefinisikan ulang selama
pengembangan karena umpan
balik

xvi
pengguna dan faktor lainnya.
Model pengembangan
Evolusioner membagi siklus
pengembangan menjadi
model air terjun inkremental
yang lebih kecil di mana
pengguna bisa mendapatkan
akses ke produk di akhir setiap
siklus.
Umpan balik diberikan oleh
pengguna pada produk untuk
tahap perencanaan
siklus berikutnya dan tim
pengembangan merespons,
seringkali dengan mengubah

xvii
produk, rencana atau proses.
Oleh karena itu, produk
perangkat lunak berkembang
seiring waktu.
Semua model memiliki
kelemahan yaitu durasi
waktu dari mulai proyek
hingga
waktu pengiriman solusi
sangat tinggi. Model evolusi
memecahkan masalah ini
dengan pendekatan yang
berbeda.

Model evolusioner
merupakan kombinasi dari
xviii
Iterative dan Incremental
model
dari siklus hidup
pengembangan perangkat
lunak. Menyampaikan sistem
Anda
dalam rilis besar,
mengirimkannya dalam
proses bertahap dari waktu
ke waktu
adalah tindakan yang
dilakukan dalam model ini.
Beberapa persyaratan awal dan
visi arsitektur perlu
dilakukan. Lebih baik untuk
produk perangkat lunak yang
xix
rangkaian fiturnya
didefinisikan ulang selama
pengembangan karena umpan
balik
pengguna dan faktor lainnya.
Model pengembangan
Evolusioner membagi siklus
pengembangan menjadi
model air terjun inkremental
yang lebih kecil di mana
pengguna bisa mendapatkan
akses ke produk di akhir setiap
siklus.
Umpan balik diberikan oleh
pengguna pada produk untuk
tahap perencanaan
xx
siklus berikutnya dan tim
pengembangan merespons,
seringkali dengan mengubah
produk, rencana atau proses.
Oleh karena itu, produk
perangkat lunak berkembang
seiring waktu.
Semua model memiliki
kelemahan yaitu durasi
waktu dari mulai proyek
hingga
waktu pengiriman solusi
sangat tinggi. Model evolusi
memecahkan masalah ini
dengan pendekatan yang
berbeda
xxi
Model evolusioner
merupakan kombinasi dari
Iterative dan Incremental
model
dari siklus hidup
pengembangan perangkat
lunak. Menyampaikan sistem
Anda
dalam rilis besar,
mengirimkannya dalam
proses bertahap dari waktu
ke waktu
adalah tindakan yang
dilakukan dalam model ini.
Beberapa persyaratan awal dan

xxii
visi arsitektur perlu
dilakukan. Lebih baik untuk
produk perangkat lunak yang
rangkaian fiturnya
didefinisikan ulang selama
pengembangan karena umpan
balik
pengguna dan faktor lainnya.
Model pengembangan
Evolusioner membagi siklus
pengembangan menjadi
model air terjun inkremental
yang lebih kecil di mana
pengguna bisa mendapatkan
akses ke produk di akhir setiap
siklus.
xxiii
Umpan balik diberikan oleh
pengguna pada produk untuk
tahap perencanaan
siklus berikutnya dan tim
pengembangan merespons,
seringkali dengan mengubah
produk, rencana atau proses.
Oleh karena itu, produk
perangkat lunak berkembang
seiring waktu.
Semua model memiliki
kelemahan yaitu durasi
waktu dari mulai proyek
hingga
waktu pengiriman solusi
sangat tinggi. Model evolusi
xxiv
memecahkan masalah ini
dengan pendekatan yang berbe
1. Model Incremental

Model Incremental merupakan hasil kombinasi elemen-elemen dari model waterfall yang
diaplikasikan secara berulang, atau bisa disebut gabungan dari Model linear sekuensial
(waterfall) dengan Model Prototype. Elemen-elemen tersebut dikerjakan hingga
menghasilkan produk dengan spesifikasi tertentu kemudian proses dimulai dari awal kembali
hingga muncul hasil yang spesifikasinya lebih lengkap dari sebelumnya dan tentunya
memenuhi kebutuhan pemakai.

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 ini cocok dipakai untuk proyek kecil dengan anggota tim yang sedikit dan
ketersediaan waktu yang terbatas.

Pada proses Pengembangan dengan Model Incremental, perangkat lunak dibagi menjadi
serangkaian increment yang dikembangkan secara bergantian.

 Contoh Penerapan Model Incremental

Perangkat lunak pengolah kata yang dikembangkan dengan menggunakan paradigma

pertambahan akan menyampaikan manajemen file, editing, serta fungsi penghasilan dokumen

xxv
pada pertambahan pertama, dan selanjutnya. Pertambahan pertama dapat disebut sebagai
produk inti (core product).  Dan pada pertambahan selanjutnya, produk inti akan
dikembangkan terus hingga menghasilkan produk jadi yang siap untuk digunakan/dipasarkan.

Kelebihan Model Incremental :

 Personil bekerja optimal.

 mampu mengakomodasi perubahan secara fleksibel, dengan waktu yang relatif

singkat dan tidak dibutuhkan anggota/tim kerja yang banyak untuk menjalankannya.

 Pihak konsumen dapat langsung menggunakan dahulu bagian-bagian yang telah

selesai dibangun. Contohnya pemasukan data karyawan.

 Mengurangi trauma karena perubahan sistem. Klien dibiasakan perlahan-lahan

menggunakan produknya setiap bagian demi bagian.

 Memaksimalkan pengembalian modal investasi konsumen.

Kekurangan Model Incremental :

 Tidak cocok untuk proyek berukuran besar (lebih dari 200.000 baris coding).

 Sulit untuk memetakan kebutuhan pemakai ke dalam rencana spesifikasi tiap-tiap

hasil dari increament.

2.4 Model Spiral

Model Spiral atau Metode spiral adalah salah satu model Siklus Hidup Pengembangan
Perangkat Lunak (SDLC) yang paling penting, yang menyediakan dukungan untuk
Penanganan Risiko. Dalam representasi diagram, itu terlihat seperti spiral dengan banyak
loop. Jumlah pasti loop spiral tidak diketahui dan dapat bervariasi dari proyek ke proyek.
Setiap loop spiral disebut Fase dari proses pengembangan perangkat lunak. Jumlah pasti fase
yang dibutuhkan untuk mengembangkan produk dapat divariasikan oleh manajer proyek
tergantung pada risiko proyek. Karena manajer proyek secara dinamis menentukan jumlah
fase, maka manajer proyek memiliki peran penting untuk mengembangkan produk
menggunakan model spiral.

xxvi
Tahap Liason

Tahap pertama disebut sebagai tahap liason. Pada tahap ini, memiliki tujuan untuk
memperbaiki dan mengembangkan perangkat lunak. Perbaikan dan pengembangannya tentu
akan didasarkan kepada kebutuhan konsumen.

Artinya, pada tahap ini beberapa pihak terlibat untuk mencapai tujuan itu, termasuk
diantaranya yaitu pihak system analyst dan pelanggan atau user.

Tahap Planning

Tahap planning adalah tahap di mana beberapa hal berikut ini diestimasikan :

Biaya

Batas waktu

Pengaturan jadwal

Identifikasi lingkungan kerja

Sumber sumber informasi iterasi (teknik perulangan)

Dengan demikian, pada tahap ini hasil utamanya yang akan diperoleh akan berupa dokumen
spesifikasi dari kebutuhan sistem maupun bisnis.

Tahap Analisis Risiko

Tahap ketiga yaitu tahap analisis risiko, di mana sebagaimana namanya, pada tahap ini akan
potensi risiko yang mungkin terjadi akan diidentifikasikan.

Tidak hanya itu, pada tahap ini juga akan dilakukan pencarian terhadap solusi atas potensi
risiko yang telah diidentifikasi sebelumnya. Tahap ini bisa dikatakan juga seperti tahap
mitigasi, atau upaya mengurangi risiko bencana. Solusinya pun akan mencakup strategi
teknis dan manajerial.

Tahap Rekayasa (Engineering)

Tahap rekayasa merupakan tahap yang memiliki beberapa kegiatanutama mulai dari menguji,
melakukan coding dan mengembangkan perangkat lunak hingga membuat laporan

xxvii
 kekurangan perangkat lunak.

Dari laporan itu, maka kekurangan perangkat lunak akan dapat segera diperbaiki. Untuk lebih
detailnya, tahap rekayasa ini akan mencakup kegiatan berikut ini :

Menginstal software

Membuat prototype

Mendesain dokumen

Meringkas suatu pengujian software

Tahap Evaluasi

Tahap yang terakhir yaitu tahap evaluasi. Pada tahap ini, perangkat lunak yang telah dibuat
oleh system analyst akan di evaluasi oleh beberapa pihak ter,asuk user.

Hal ini tentu dilakukan tidak lain untuk menguji kesesuaian perangkat lunak dengan
kebutuhan dan kepuasan pelanggan. Pada tahap ini, risiko yang menyebabkan pembengkakan
biaya juga masih akan tetap dipantau.

Kapan menggunakan Model Spiral?

 Model Spiral dalam rekayasa perangkat lunak digunakan ketika proyek besar

 Ketika rilis harus sering, metodologi spiral digunakan

 Ketika pembuatan prototipe dapat diterapkan

 Ketika evaluasi risiko dan biaya penting

 Metodologi spiral berguna untuk proyek berisiko menengah hingga tinggi

 Ketika persyaratan tidak jelas dan kompleks, model Spiral di SDLC berguna

xxviii
 Ketika perubahan mungkin memerlukan setiap saat

 Ketika komitmen proyek jangka panjang tidak layak karena perubahan prioritas ekonomi

Kelebihan dan Kekurangan dari Metode Spiral

Jadi – apa keuntungan dan kerugian utama menggunakan model Spiral untuk proyek
perangkat lunak? Mari kita lihat beberapa aspek terpenting.

Kelebihan

 Model yang sangat fleksibel

 Pengembangan cepat dan hemat biaya

 Sangat cocok untuk proyek skala besar dan pengembangan mission-critical

 Bekerja dengan baik untuk proyek yang kompleks

 Pemantauan mudah dan efektif

 Penekanan kuat pada persetujuan klien

 Fokus pada kontrol dokumentasi

 Potensi untuk fungsionalitas pasca-proyek tambahan

 Perangkat lunak diproduksi di awal siklus hidup proyek

 Analisis risiko membantu menghilangkan dan menghindari risiko

 Persyaratan yang diubah diakomodasi selama umur proyek

 Produk akhir bisa sangat disesuaikan

Kekurangan

 Bisa mahal untuk diterapkan – terutama jika spiral berlanjut tanpa batas

 Aspek analisis risiko proyek mungkin memerlukan keahlian khusus

 Tidak cocok untuk proyek yang lebih kecil atau berisiko rendah

 Keberhasilan mungkin sangat bergantung pada analisis risiko

 Dokumentasi bisa jadi berat, karena jumlah tahap perantara

 Akhir proyek mungkin sulit untuk ditentukan sebelumnya

 Spiral secara luas dianggap sebagai proses yang kompleks

xxix
 Aturan dan protokol harus dipatuhi secara ketat selama pengembangan

2.5 Model Reuse Based Development

sangat berkaitan dengan teknologi berorientasi objek. Pada pemrograman berorientasi
objek, banyak class yang dibangun dan menjadi komponen dalam suatu software. Class-class
tersebut bersifat reusable artinya bisa digunakan kembali. Model ini bersifat iteratif atau
berulang-ulang prosesnya.

Secara umum proses yang terjadi dalam model ini adalah:

1. Identifikasi class-class yang akan digunakan kembali dengan menguji class tersebut
dengan data yang akan dimanipulasi dengan aplikasi/software dan algoritma yang
baru

2. Class yang dibuat pada proyek sebelumnya disimpan dalam class library, sehingga
bisa langsung diambil dari library yang sudah ada. Jika ternyata ada kebutuhan class
baru, maka class baru dibuat dengan metode berorientasi objek.

3. Bangun software dengan class-class yang sudah ditentukan atau class baru yang
dibuat, integrasikan.

Penggunaan kembali komponen software yang sudah ada menguntungkan dari segi:
-Siklus waktu pengembangan   software, karena   mampu   mengurangi waktu 70%

- Biaya produksi berkurang sampai 84% arena pembangunan komponen berkurang

Pembangunan software dengan menggunakan komponen yang sudah tersedia dapat

menggunakan komponen COTS (Commercial off-the-shelf) – yang bisa didapatkan dengan
membeli atau komponen yang sudah dibangun sebelumnya secara internal. Component-
Based Software Engineering (CBSE) adalah proses yang menekankan perancangan dan
pembangunan software dengan menggunakan komponen software yang sudah ada. CBSE
terdiri dari dua bagian yang terjadi secara paralel yaitu software engineering (component-
based development) dan domain engineering.

xxx
 BAB III
PENUTUP
3.1 Kesimpulan
Pengembangan perangkat lunak yaitu suatu penerapan struktur pada pengembangan
perangkat lunak yang bertujuan untuk mengembangkan sistem yang menggunakan tahap
tahap tertentu . Dari jenis jenis model diatas memiliki kelebihan dan kekurangan masing
masing , oleh karena itu kita bisa menggunakannya sesuai kebutuhan saat melakukan
pengembangan perangkat lunak.

xxxi
 DAFTAR PUSTAKA

https://www.mediainformasionline.com/2022/07/model-proses-rekayasa-perangkat-
lunak.html
https://salamadian.com/metode-waterfall/
https://bloganyun.wordpress.com/2016/11/23/metode-prototype-pada-rekayasa-
perangkat-lunak/
https://www.studocu.com/id/document/universitas-esa-unggul/rekayasa-perangkat-
lunak/modul-rpl-03-iterative-waterfall-model-prototyping-model-evolutionary-model-
spiral-model/46056779
https://dosenit.com/ilmu-komputer/spiral-model
https://rplhlw117a03.wordpress.com/2015/09/28/model-proses-rpl/

xxxii