TUGAS REKAYASA PERANGKAT LUNAK

Disusun Oleh:

Bayu Dwi Leyfrand. P (8040210062)

Habil Dwi Ilham. R (8040210067)
Rizki Maulana (8040210163)
Adit febrian (8040200049)
Bagas Ramadhan (8040200267)

PROGRAM STUDI SISTEM INFORMASI

FAKULTAS ILMU KOMPUTER
UNIVERSITAS DINAMIKA BANGSA
JAMBI
2023
 A. WATERFALL

1. Spesifikasi
Model pengembangan perangkat lunak Waterfall merupakan pendekatan linear
yang terdiri dari serangkaian fase yang harus diselesaikan secara berurutan.
Berikut adalah spesifikasi umum dari model pengembangan Waterfall:

1. Analisis : Tahap ini melibatkan pemahaman kebutuhan pengguna dan

spesifikasi sistem. Tim proyek mengumpulkan informasi tentang fungsi-
fungsi yang diinginkan dan batasan-batasan yang ada.
2. Perancangan : Pada fase ini, perancangan sistem dilakukan berdasarkan
spesifikasi yang telah dikumpulkan. Ini mencakup rancangan arsitektur,
desain modul, dan rincian teknis lainnya.
3. Implementasi : Implementasi melibatkan penerjemahan desain ke dalam
kode yang dapat dieksekusi oleh komputer. Setiap modul atau komponen
sistem dikembangkan secara terpisah.
4. Pengujian : Pengujian dilakukan untuk memastikan bahwa setiap
komponen bekerja dengan benar dan memenuhi spesifikasi. Ini melibatkan
pengujian unit, pengujian integrasi, dan pengujian sistem.
5. Implementasi : Setelah pengujian selesai dan sistem dianggap siap, produk
atau sistem dapat diimplementasikan dan dirilis kepada pengguna akhir.
6. Pemeliharaan : Tahap pemeliharaan melibatkan perbaikan bug,
pembaruan, dan perawatan sistem setelah implementasi. Ini dapat
mencakup perbaikan kesalahan dan peningkatan fungsi.

Model Waterfall memprioritaskan urutan dan keberlanjutan fase, sehingga setiap

fase bergantung pada penyelesaian fase sebelumnya. Salah satu kritik terhadap
model ini adalah kurangnya fleksibilitas dalam mengakomodasi perubahan
kebutuhan atau perubahan spesifikasi selama proses pengembangan.
2. Proses Proses Waterfall

1. Requirement Analysis : Sebelum melakukan pengembangan perangkat

lunak, seorang pengembang harus mengetahui dan memahami bagaimana
informasi kebutuhan penggguna terhadap sebuah perangkat lunak. Metode
pengumpulan informasi ini dapat diperoleh dengan berbagai macam cara
diantaranya, diskusi, observasi, survei, wawancara, dan sebagainya.
Informasi yang diperoleh kemudian diolah dan dianalisa sehingga
didapatkan data atau informasi yang lengkap mengenai spesifikasi
kebutuhan pengguna akan perangkat lunak yang akan dikembangkan.

2. System and Software Design : Informasi mengenai spesifikasi kebutuhan

dari tahap Requirement Analysis selanjutnya di analisa pada tahap ini
untuk kemudian diimplementasikan pada desain pengembangan.
Perancangan desain dilakukan dengan tujuan membantu memberikan
gambaran lengkap mengenai apa yang harus dikerjakan. Tahap ini juga
akan membantu pengembang untuk menyiapkan kebutuhan hardware
dalam pembuatan arsitektur sistem perangkat lunak yang akan dibuat
secara keseluruhan.

3. Implementation and Unit Testing : Tahap implementation and unit testing

merupakan tahap pemrograman. Pembuatan perangkat lunak dibagi
menjadi modul-modul kecil yang nantinya akan digabungkan dalam tahap
berikutnya. Disamping itu, pada fase ini juga dilakukan pengujian dan
 pemeriksaan terhadap fungsionalitas modul yang sudah dibuat, apakah
sudah memenuhi kriteria yang diinginkan atau belum.

4. Integration and System Testing : Setelah seluruh unit atau modul yang
dikembangkan dan diuji di tahap implementasi selanjutnya diintegrasikan
dalam sistem secara keseluruhan. Setelah proses integrasi selesai,
selanjutnya dilakukan pemeriksaan dan pengujian sistem secara
keseluruhan untuk mengidentifikasi kemungkinan adanya kegagalan dan
kesalahan sistem.

5. Operation and Maintenance : Pada tahap terakhir dalam Metode Waterfall,

perangkat lunak yang sudah jadi dioperasikan pengguna dan dilakukan
pemeliharaan. Pemeliharaan memungkinkan pengembang untuk
melakukan perbaikan atas kesalahan yang tidak terdeteksi pada tahap-
tahap sebelumnya. Pemeliharaan meliputi perbaikan kesalaha, perabikan
implementasi unit sistem, dan peningkatan dan penyesuaian sistem sesuai
dengan kebutuhan.

3. Kelebihan dan kekurangan Metode Waterfall

- Kelebihan Waterfall

1. Workflow yang jelas

Dengan menggunakan model SDLC jenis ini, mempunyai rangkaian alur
kerja sistem yang jelas dan terukur. Masing – masing tim, memiliki tugas
dan tanggung jawab sesuai dengan bidang keahliannya. Serta dapat
menyelesaikan pekerjaan sesuai dengan alokasi waktu yang telah
ditentukan sebelumnya.

2. Hasil dokumentasi yang baik

Waterfall merupakan pendekatan yang sangat metodis, dimana setiap
informasi akan tercatat dengan baik dan terdistribusi kepada setiap anggota
tim secara cepat dan akurat. Dengan adanya dokumen, maka pekerjaan
dari setiap tim akan menjadi lebih mudah, serta mengikuti setiap arahan
dari dokumen tersebut.

3. Dapat menghemat biaya

Kelebihan yang selanjutnya tentu saja dari segi resource dan biaya yang
dikeluarkan oleh suatu perusahaan dengan menggunakan model ini. Jadi,
 dalam hal ini klien tidak dapat mencampuri urusan dari tim pengembang
aplikasi. Sehingga pengeluaran biaya menjadi lebih sedikit. Berbeda
dengan metode Agile, yang mana klien dapat memberikan masukan dan
feedback kepada tim developer terkait dengan perubahan atau penambahan
beberapa fitur. Sehingga perusahaan akan mengeluarkan biaya yang lebih
besar daripada Waterfall.

4. Digunakan untuk pengembangan software berskala besar

Metode ini dinilai sangat cocok untuk menjalankan pembuatan aplikasi
berskala besar yang melibatkan banyak sumber daya manusia dan prosedur
kerja yang kompleks. Akan tetapi, Model ini juga dapat digunakan untuk
proyek berskala kecil dan menengah. Tentu saja disesuaikan dengan
kondisi dan kebutuhan proyek yang diambil.

- Kekurangan Waterfall

1. Membutuhkan tim yang solid

Untuk menggunakan model SDLC ini, tentu saja membutuhkan
dukungan dari setiap stakeholders yang ada. Setiap tim harus mempunyai
kerja sama dan koordinasi yang baik. Dikarenakan, apabila salah satu tim
tidak dapat menjalankan tugas dengan semestinya, maka akan sangat
berpengaruh terhadap alur kerja tim yang lain.

2. Masih kurangnya fleksibilitas

Semua tim dituntut untuk bekerja sesuai dengan arahan dan petunjuk
yang telah ditetapkan di awal. Sehingga, klien tidak dapat mengeluarkan
pendapat dan feedback kepada tim pengembang. Klien hanya dapat
memberikan masukan pada tahap awal perancangan sistem perangkat
lunak saja.

3. Tidak dapat melihat gambaran sistem dengan jelas

Dengan model waterfall, customer tidak dapat melihat gambaran sistem
secara jelas. Berbeda dengan model agile yang dapat terlihat dengan baik
meskipun masih dalam proses pengembangan.

4. Membutuhkan waktu yang lebih lama

Proses pengerjaan dengan menggunakan waterfall terbilang cukup lama
jika dibandingkan dengan model SDLC yang lain. Karena, tahapan
pengerjaan aplikasi yang dilakukan satu per satu membuat waktu yang
dibutuhkan menjadi lebih lama. Sebagai contoh, tim developer tidak akan
 bisa melakukan proses coding jika tim designer belum menampilkan
tampilan desain dari aplikasi.

B. ICONIX

1. Spesifikasi

Iconix adalah suatu metode pengembangan perangkat lunak yang fokus pada
analisis dan desain. Berikut adalah beberapa spesifikasi umum dari metode
pengembangan perangkat lunak Iconix:

1. Use Case Driven : Iconix menekankan penggunaan kasus pengguna (use

cases) sebagai dasar untuk merinci kebutuhan perangkat lunak dan
merancang solusi yang sesuai.
2. Iterative Dan Incremental : Proses pengembangan Iconix bersifat iteratif
dan inkremental, memungkinkan perubahan dan penambahan seiring
waktu.
3. Model Berorientasi Objek : Iconix banyak menggunakan konsep
pemrograman berorientasi objek dalam analisis dan desainnya.
4. Unified Modeling Language (UML) : Iconix menggunakan UML sebagai
alat utama untuk mendokumentasikan dan menggambarkan model analisis
dan desain.
5. Focus on Visualization : Metode ini menekankan penggunaan diagram dan
visualisasi untuk memahami dan mengkomunikasikan desain perangkat
lunak.
6. Structured Analysis and Design : Iconix menggabungkan pendekatan
analisis dan desain terstruktur untuk memahami dengan baik kebutuhan
dan merancang solusi yang terstruktur.
7. Requirement Traceability : Metode ini menempatkan vektor traceability
yang kuat antara kebutuhan, use cases, dan desain untuk memastikan
konsistensi dan kelengkapan.
8. Testing Early and Often : Uji coba (testing) dilibatkan secara dini dan
sering selama siklus pengembangan untuk memastikan kualitas perangkat
lunak.

Penting untuk dicatat bahwa spesifikasi Iconix bisa sedikit bervariasi tergantung
pada konteks penggunaannya dan evolusi metodologi pengembangan perangkat
lunak.
2. Proses Proses Iconix

1. Membuat Functional Requirement

Gunakan Ms.Word untuk menuliskan functional requirement (apa saja yang
dibutuhkan oleh sistem). Tahap ini melibatkan bussines analyst, pelanggan,
end-user dan project stakeholder lainnya. Functional requirement masih belum
terstruktur sehingga tidak bisa dipakai secara langsung dalam perancangan.

2. Membuat Domain Model

Pada tahap ini, domain model adalah class diagram yang hanya memakai
relasi pewarisan (is-a/adalah sebuah) dan agregasi (has-a/memiliki sebuah).
Class diagram ini belum memiliki atribut dan operasi.

3. Membuat Use Case

Sebuah use case hampir mirip seperti dokumentasi sistem. Kita perlu
menspesifikasikan seperti apa cara pakai sistem (termasuk respon sistem)
sebelum sebuah sistem dibuat. Berikut ini adalah contoh use case diagram
berdasarkan functional requirement di langkah 1 dan memakai domain model
dari langkah-langkah
4. Requirements Review
Pada langkah ini, kita kembali memastikan bahwa use case & domain model
telah dibuat dengan baik. Pelanggan juga perlu dilibatkan untuk memastikan
bahwa use case (behavioral requirement) & functional requirement sesuai
dengan yang diharapkan. Ingatlah selalu bahwa bagian terpenting dari sebuah
sistem bukanlah seberapa keren design pattern yang diterapkan di class
diagram, tetapi sejauh mana sistem tersebut memberikan profit bagi
penggunanya (memenuhi requirements).

5. Melakukan Robutness Analysis

Robustness analysis dipakai untuk menjembatani analisis dan perancangan.
Robustness analysis harus diterapkan pada setiap use case yang ada. Pada
Enterprise Architect, robustness analysis dapat digambarkan dengan
menggunakan Analysis Diagrams (terdapat di kategori Extended).

Berikut ini adalah contoh hasil robustness analysis untuk use case yang ada:

6. Preliminary Design Review

Ini adalah langkah terakhir dimana pelanggan (stackholder) terlibat! Hal ini
karena langkah berikutnya melibatkan proses techincal. Akan berbahaya bila
membiarkan pelanggan yang non-technical atau semi-technical mengambil
keputusan untuk hal-hal yang bersifat teknis (misalnya framework atau
database yang dipakai).

7. Menentukan Technical Architecture

Tentukan framework apa yang akan dipakai. Sebagai contoh, saya akan
membuat sebuah aplikasi desktop dengan Griffon. Pola arsitektur yang dipakai
menyerupai Model View ViewModel (MVVM) dimana terdapat perbedaan
antara domain model dan view model. Saya juga mengasumsikan penggunaan
sebuah plugin fiktif yang dirujuk sebagai simple-jpa. Gambar berikut ini
memperlihatkan contoh arsitektur yang dipakai:

8. Membuat Sequence Diagram

Object oriented pada dasarnya adalah menggabungkan antara data dan operasi
ke dalam sebuah entitas. Saat ini, domain model baru berisi data. Oleh sebab
itu, dibutuhkan sebuah upaya untuk menemukan operasi untuk domain model.
Caranya adalah dengan memakai sequence diagram :
9. Critical Design Review
Kembali melakukan review untuk memastikan bahwa tidak ada yang kurang
pada sequence diagram. Pastikan bahwa setiap class yang ada telah memiliki
atribut dan operasi yang didefinisikan secara lengkap (memiliki nama, tipe
data, parameter, dsb).
Berikut ini adalah contoh hasil domain model yang telah dilengkapi dengan
operasi dan multiplicity:
Getter dan setter tidak perlu ditampilkan karena hanya akan membuat class
diagram terlihat ‘penuh’.
Versi bidirectional-nya akan terlihat seperti pada gambar berikut ini:

Selain domain model, saya juga menemukan terdapat class-class lain yang
dihasilkan yang berkaitan dengan penggunaan framework, yang terlihat seperti
pada gambar berikut ini:
 10. Coding
Disini developer berperan mengubah rancangan (design) menjadi kode
program. Karena semua telah direncanakan dan dipikirkan sebelumnya, maka
proses coding dapat dianggap sebagai sebuah pembuktian (test) bahwa
rancangan yang dibuat sudah benar. Terkadang terdapat beberapa hal yang
lolos dari perancangan dan baru terungkap saat coding; pada kasus tersebut,
perubahan pada rancangan harus segera dilakukan sehingga kode program dan
rancangan bisa tetap sinkron.

3. Kelebihan dan Kekurangan Iconix

- Kelebihan Iconix

1. Fokus pada Perencanaan : Iconix menekankan perencanaan yang baik,

membantu dalam mengidentifikasi kebutuhan dengan jelas sebelum
tahap pengembangan dimulai.

2. Model Berbasis Use Case : Menggunakan model berbasis use case

membantu tim pengembangan memahami kebutuhan pengguna dengan
lebih baik.
 3. Iteratif dan Inkremental : Memungkinkan pendekatan pengembangan
secara iteratif dan inkremental, memudahkan adaptasi terhadap
perubahan kebutuhan.

- Kekurangan Iconix

1. Kompleksitas Tertentu : Beberapa orang mungkin menganggap proses

Iconix terlalu kompleks, terutama untuk proyek-proyek kecil atau
sederhana.

2. Tidak Sesuai untuk Semua Proyek : Metodologi ini mungkin kurang

cocok untuk proyek-proyek yang membutuhkan fleksibilitas maksimal
atau memiliki persyaratan yang sangat dinamis.

3. Memerlukan Keterampilan Analisis yang Kuat : Penerapan Iconix

membutuhkan keterampilan analisis yang baik untuk merinci
kebutuhan dengan jelas, dan tidak semua tim pengembangan mungkin
memiliki keterampilan tersebut.

C. XP

1. Spesifikasi

XP adalah sebuah proses perangkat lunak yang membantu pengembang membuat

kode berkualitas dengan cepat. Di sini, kita mendefinisikan kualitas sebagai
sebuah basis kode yang sesuai dengan desain spesifikasi dan ekspektasi
pelanggan.
Berikut adalah beberapa spesifikasi dan karakteristik utama dari Extreme
Programming (XP):
1. Komunikasi Tim yang Intensif
Pasangan Pemrograman (Pair Programming): Praktik di mana dua
pengembang bekerja bersama di satu komputer, yang memfasilitasi
pertukaran ide dan pengetahuan secara langsung.

2. Pengembangan Berbasis Fitur (Feature-Based Development)

Pengembangan Berbasis Kebutuhan Pelanggan: Fokus pada
pengembangan fitur-fitur yang diidentifikasi sebagai kebutuhan pelanggan
tertinggi.

3. Pengujian Otomatis (Automated Testing)

Setiap fitur atau komponen perangkat lunak diuji secara otomatis untuk
memastikan integritas fungsionalitas.

4. Integrasi Terus Menerus (Continuous Integration)

Integrasi Kode yang Sering: Setiap kali ada perubahan kecil dalam kode,
integrasi otomatis dilakukan untuk memastikan bahwa perangkat lunak
tetap berfungsi dengan baik.

5. Perencanaan yang Fleksibel

Perencanaan Iteratif: Proyek dibagi menjadi iterasi kecil yang dikenal
sebagai "iterasi" atau "sprint," dengan rencana yang dapat disesuaikan
dengan perubahan kebutuhan pelanggan.

6. Desain Sederhana (Simple Design)

Kesederhanaan Desain Kode: Menekankan pada kejelasan dan
kesederhanaan dalam desain kode untuk memudahkan pemeliharaan dan
pemahaman.

7. Refaktoring (Refactoring)
Perbaikan Terus Menerus: Kode secara terus-menerus diperbaiki melalui
refaktoring untuk meningkatkan struktur dan kualitas tanpa mengubah
fungsionalitas.

8. Keterlibatan Pelanggan Aktif

Partisipasi Pelanggan: Pelanggan atau pemangku kepentingan terlibat
secara aktif dalam pengembangan, memberikan umpan balik yang
berkelanjutan.
 9. Kerja Berbasis Prioritas (Priority-Based Work
Mengutamakan Fitur: Fitur yang memiliki nilai tertinggi untuk pelanggan
dikerjakan terlebih dahulu.

10. Pemrograman yang Berani (Courageous Programming)

Mendorong tim untuk mengambil risiko dan melakukan perubahan yang
diperlukan untuk meningkatkan kualitas perangkat lunak.

11. Penetapan Batasan (Setting Limits)

Batasan Waktu dan Biaya: Menetapkan batasan yang jelas pada waktu dan
biaya untuk setiap iterasi.

12. Kode Terpantau (Collective Code Ownership)

Pemilikan Bersama Kode: Semua anggota tim diharapkan memiliki
tanggung jawab terhadap semua kode, sehingga setiap orang dapat
mengubah atau memperbaiki bagian-bagian tertentu.

2. Proses proses XP
1. Planning
Tahap pertama adalah pertemuan antara client dengan tim developer guna
presentasi gambaran hasil yang diinginkan oleh client.
Tim kemudian memperkirakan gambaran yang diinginkan oleh client dan
membuat rencana pengembangan yang dibagi menjadi beberapa tahapan
yang diperlukan untuk memenuhi fungsionalitas yang dibutuhkan. Jika
satu atau lebih dari gambaran client tidak dapat diperkirakan, atau biasa
disebut dengan spike, maka diperlukan penelitian yang lebih lanjut.

Untuk lebih lanjutnya, berikut penjelasan mengenai dua kunci yang ada
utama dalam tahap planning. Biasanya tim developer mengajukan
pertanyaan seputar dua hal ini ke client:

1. Release Planning
Pada tahap ini, pelanggan mempresentasikan fitur yang diinginkan kepada
programmer atau tim developer, dan tim developer memperkirakan tingkat
kesulitan beserta biayanya.

2. Iteration Planning
Pada tahap ini, tim diberi arahan rutin setiap beberapa minggu. Tim XP
membangun software dalam iterasi selama dua minggu dan memberikan
progress software yang sedang dibuat pada akhir setiap iterasi. Selama
perencanaan iterasi, pelanggan menyampaikan fitur-fitur yang diinginkan
untuk dua minggu ke depan.

2. Designing
Tahap designing sebenarnya merupakan bagian dari proses planning tetapi
dapat dipisahkan untuk mengoptimalkan kedua proses ini. Hal ini terkait
dengan salah satu nilai utama XP yaitu kesederhanaan. Desain yang baik
membawa logika dan struktur ke dalam sistem sehingga dapat
menghindari kompleksitas dan redundansi yang tidak diperlukan.

1. Simple Design
Pada fase perancangan desain, XP berkonsentrasi untuk memastikan
desain tepat sederhana dan lengkap. Tidak ada fungsionalitas tambahan
yang ditambahkan, fungsionalitas yang ditambahkan sesuai dengan yang
diinginkan client.
 2. Metafora Sistem
Metafora sistem membuat tim pengembangan tetap terorganisir dengan
menyediakan konvensi penamaan. Konvensi penamaan sangatlah penting
karena digunakan untuk membantu memahami desain sistem secara
keseluruhan juga penggunaan ulang kode.

Hal ini dapat menghemat waktu karena memudahkan proses dalam

menemukan fungsionalitas yang dicari dan dapat mendeteksi di mana
harus meletakkan fungsionalitas tertentu.

3. Refactoring
Refactoring adalah proses peningkatan desain yang berkelanjutan untuk
menjaga desain sesederhana mungkin serta digunakan untuk menghindari
kekacauan dan kerumitan yang sebetulnya tidak perlu.

Refactoring cenderung menghilangkan redudansi dan duplikasi serta

meningkatkan kohesi kode Refactoring di seluruh proyek akan menghemat
waktu, meningkatkan kualitas, dan meningkatkan pemahaman. Hal ini
harus didukung oleh pengujian yang komprehensif untuk memastikan
tidak ada yang rusak.

3. Testing
Tahap ini adalah inti dari extreme programming. Fase testing adalah
aktivitas rutin yang melibatkan pengujian unit (pengujian otomatis untuk
menentukan apakah fitur yang dikembangkan berfungsi dengan baik) dan
pengujian penerimaan (pengujian pelanggan untuk memverifikasi bahwa
keseluruhan sistem dibuat sesuai dengan persyaratan awal).

4. Listening
Pada tahap ini, komunikasi antara pelanggan dan manajer proyek
dilakukan untuk menjelaskan logika bisnis dan nilai yang diharapkan.

3. Kelebihan dan Kekurangan XP

- Kelebihan XP
1. Efisiensi Waktu dan Biaya : Dengan penggunaan Extreme Programming
memunginkan perusahaan untuk menekan biaya pengembangan software
serta waktu untuk realisasi proyek. Extreme Programming menghilangkan
kegiatan yang tidak produktif untuk mengurangi biaya dan beban semua
orang yang terlibat. Hal ini memungkinkan tim pengembang untuk fokus
pada pengkodean.

2. Minim Resiko : Salah satu keuntungan utama dari Extreme Programming

adalah minim resiko yang berkaitan dengan kegagalan pemrograman atau
proyek. XP memastikan bahwa klien mendapatkan hasil seperti apa yang
diinginkannya.

3. Sederhana : Metode Extreme Programming memungkinkan tim

pengembang untuk membuat kode yang sederhana sehingga dapat
diperbaiki setiap saat.

4. Prosesnya Transparan dan Dapat Dipertanggungjawabkan : Keuntungan

dasar dari Extreme Programming adalah seluruh proses transparan dan
dapat dipertanggungjawabkan. Para pengembang membuat komitmen
konkret tentang apa yang akan mereka capai, dengan menunjukkan proses
pengembangan yang ril.

5. Konstan Feedback : Adanya feedback yang konstan dapat mempermudah

tim melakukan perbaikan. XP membantu tim untuk stay on track.

6. Perangkat Lunak yang Berfungsi Lebih Cepat : Dengan metode Extreme

Programming dapat menghasilkan software yang memiliki kecepatan
tinggi dikarenakan pengujian rutin yang dilakukan saat proses
pengembangan dapat mendeteksi semua bug juga tes validasi yang
disetujui oleh pengguna dapat menentukan keberhasilan penyelesaian
coding block untuk memastikan bahwa implementasi gambaran hasil
sudah seperti yang diinginkan pelanggan.

7. Teamwork : Setiap orang adalah bagian dari tim. Anggota tim bekerja
bersama dalam segala hal mulai dari requirements hingga kode.

8. Meningkatkan Kepuasan Tim : Xp merupakan pendekatan berbasis nilai

yang menetapkan waktu kerja tetap, dengan sedikit peluang untuk lembur.
Pemecahan ruang lingkup proyek menjadi sub komponen dan umpan balik
 pelanggan yang konstan mencegah penumpukan banyak pekerjaan yang
harus diselesaikan sebelum tenggat waktu.

- Kekurangan XP

1. Kurangnya Dokumentasi : Perubahan yang konstan tidak dapat

didokumentasikan dengan baik. Dengan demikian, ada risiko tinggi akan
kegagalan tak terduga yang tidak dapat ditelusuri. Bahkan ketika bug telah
diperbaiki, tanpa dokumentasi yang akurat, ada kemungkinan kesalahan
yang sama dapat terulang kembali.

2. Minim Desain : Extreme Programming lebih berfokus kepada pengkodean

dibanding dengan desain. Namun, desain juga merupakan aspek penting
dalam sebuah software sehingga desain tidak boleh diabaikan. Dengan
minimnya desain, ada kemungkinan client merasa kurang puas.

3. Tidak Cocok Dikerjakan Secara Remote : Proyek Extreme Programming

sulit untuk diimplementasikan apabila tim tidak berada di tempat yang
sama. Biasanya proses komunikasi Extreme Programming dapat dilakukan
dengan lancar ketika anggota tim bertemu tatap muka. Dengan tim yang
bekerja secara on-site, proses pengembangan Extreme Programming dapat
dilakukan dengan cepat.

D. SPIRAL

1. Spesifikasi

Model Spiral adalah salah satu metode yang dapat digunakan dalam
pengembangan perangkat lunak. Model spiral merupakan penggabungan dari
model prototyping dan model waterfall. Model prototyping yang fokus pada
penyajian atau presentasi kepada user dengan format input dan output kemudian
perangkat lunak akan dievaluasi. Model waterfall yang fokus kepada proses
pengembangan perangkat lunak yang sistematis atau berurutan. Model spiral
menekankan pada Analisa resiko setiap tahapannya.

1. Tahap Liason
 Berhubungan dengan komunikasi antara pihak-pihak yang terlibat dalam
pengembangan softaware (seperti: system analyst) dengan pelanggan
(user). Tujuannya adalah memperbaiki dan mengembangan software
sesuai kebutuhan dan keinginan hingga memuaskan pelanggan.
2. Tahap planning
Tahap perencanaan meliputi estimasi biaya yang digunakan, batas waktu,
pengaturan jadwal, identifikasi lingkungan kerja, sumber-sumber
informasi untuk melakukan iterasi (Teknik perulangan). Hasil dari tahapan
ini adalah dokumen spesifikasi kebutuhan sistem dan bisnis.

3. Tahap analisis risiko

Tahap analisis resiko berfungsi untuk mengidentifikasi resiko yang
berpotensi akan terjadi dan menghasilkan solusi alternatif secara teknis
dan manajemen saat strategi mitigasi (upaya untuk mengurangi resiko
bencana) direncanakan dan diselesaikan.

4. Tahapan rekayasa (engineering)

Pada tahap rekayasa, beberapa kegiatan ini yang akan dilakukan, yaitu:
1) Menguji, coding dan mengembangkan software
2) Menginstal software
3) Membuat prototype
4) Mendesain dokumen
5) Meringkas suatu pengujian software
6) Membuat laporan atas kekurangan dari software agar segera
diperbaiki

5. Tahap evaluasi
Pada tahap evaluasi, system analyst membutuhkan masukan dan
tanggapan dari para user dalam mengevaluasi perangkat/produk yang diuji
dan memastikan bahwa produk dibutuhkan sesuai ketentuan yang telah
dibicarakan diawal dengan user. System analyst memastikan pelanggan
puas dengan produk yang akan dihasilkan untuk menjawab persoalan
bisnis mereka. Selain itu, system analyst harus tetap memantau resiko
yang akan terjadi seperti faktor-faktor yang dapat menyebabkan cost
overrun (pembengkakan biaya).
2. Proses proses Spiral

Setiap fase Model Spiral dibagi menjadi empat kuadran seperti terlihat pada
gambar di atas. Fungsi keempat kuadran ini dibahas di bawah ini

1) Penentuan tujuan dan mengidentifikasi solusi alternatif: Persyaratan

dikumpulkan dari pelanggan dan tujuan diidentifikasi, diuraikan, dan
dianalisis pada awal setiap fase. Kemudian solusi alternatif yang mungkin
untuk fase tersebut diusulkan di kuadran ini.

2) Identifikasi dan selesaikan Risiko: Selama kuadran kedua, semua solusi

yang mungkin dievaluasi untuk memilih solusi terbaik. Kemudian risiko
yang terkait dengan solusi tersebut diidentifikasi dan risiko tersebut
diselesaikan dengan menggunakan strategi terbaik. Di akhir kuadran ini,
Prototipe dibangun untuk mendapatkan solusi terbaik.
 3) Kembangkan Produk versi berikutnya: Selama kuadran ketiga, fitur yang
teridentifikasi dikembangkan dan diverifikasi melalui pengujian. Pada
akhir kuadran ketiga, versi perangkat lunak berikutnya tersedia.

4) Tinjau dan rencanakan untuk Fase berikutnya: Di kuadran keempat,

Pelanggan mengevaluasi versi perangkat lunak yang dikembangkan sejauh
ini. Pada akhirnya, perencanaan untuk tahap selanjutnya dimulai.
3. Kelebihan dan kekurangan Spiral

- Kelebihan Spiral

1. Penanganan Risiko: Proyek dengan banyak risiko yang tidak diketahui

yang terjadi seiring berjalannya pembangunan, dalam hal ini Model Spiral
adalah model pengembangan terbaik untuk diikuti karena analisis risiko
dan penanganan risiko di setiap fase.

2. Baik untuk proyek besar: Disarankan untuk menggunakan Model Spiral

dalam proyek besar dan kompleks.

3. Fleksibilitas dalam Persyaratan: Permintaan perubahan dalam Persyaratan

pada tahap selanjutnya dapat digabungkan secara akurat dengan
menggunakan model ini.

4. Kepuasan Pelanggan: Pelanggan dapat melihat perkembangan produk

pada tahap awal pengembangan perangkat lunak dan dengan demikian,
mereka terbiasa dengan sistem dengan menggunakannya sebelum
penyelesaian produk secara keseluruhan.

5. Pendekatan Iteratif dan Inkremental: Model Spiral memberikan

pendekatan iteratif dan inkremental terhadap pengembangan perangkat
lunak, memungkinkan fleksibilitas dan kemampuan beradaptasi dalam
menanggapi perubahan persyaratan atau kejadian tak terduga.

6. Penekanan pada Manajemen Risiko: Model Spiral memberikan penekanan

kuat pada manajemen risiko, yang membantu meminimalkan dampak
ketidakpastian dan risiko pada proses pengembangan perangkat lunak.

7. Peningkatan Komunikasi: Model Spiral menyediakan evaluasi dan

peninjauan rutin, yang dapat meningkatkan komunikasi antara pelanggan
dan tim pengembangan.
 8. Peningkatan Kualitas: Model Spiral memungkinkan beberapa iterasi
proses pengembangan perangkat lunak, yang dapat menghasilkan
peningkatan kualitas dan keandalan perangkat lunak.

- Kekurangan Spiral

1. Kompleks: Model Spiral jauh lebih kompleks dibandingkan model SDLC

lainnya.

2. Mahal: Model Spiral tidak cocok untuk proyek kecil karena mahal.

3. Terlalu banyak ketergantungan pada Analisis Risiko: Keberhasilan

penyelesaian proyek sangat bergantung pada Analisis Risiko. Tanpa
tenaga ahli yang sangat berpengalaman, pengembangan proyek yang
menggunakan model ini akan gagal.

4. Kesulitan dalam manajemen waktu: Karena jumlah tahapan tidak

diketahui pada awal proyek, estimasi waktu menjadi sangat sulit.

5. Kompleksitas: Model Spiral bisa jadi rumit, karena melibatkan banyak

iterasi dalam proses pengembangan perangkat lunak.

6. Memakan Waktu: Model Spiral dapat memakan waktu karena

memerlukan banyak evaluasi dan peninjauan.

7. Intensif Sumber Daya: Model Spiral dapat bersifat intensif sumber daya,
karena memerlukan investasi yang signifikan dalam perencanaan, analisis
risiko, dan evaluasi.

E. RUP

1. Spesifikasi RUP

RUP atau Rational Unified Process, adalah suatu kerangka kerja pengembangan
perangkat lunak yang bersifat iteratif dan inkremental. Dikembangkan oleh
Rational Software Corporation (sekarang bagian dari IBM), RUP memberikan
panduan yang komprehensif untuk pengembangan perangkat lunak dalam bentuk
metodologi siklus hidup yang terstruktur. Berikut adalah beberapa aspek
spesifikasi dari RUP :

1. Iteratif dan Inkremental:

RUP menganut pendekatan pengembangan perangkat lunak yang iteratif
dan inkremental. Proyek dibagi menjadi iterasi yang relatif pendek, dan
setiap iterasi menghasilkan peningkatan atau "inkremental" pada produk
perangkat lunak.

2. Arsitektur Berbasis Model:

Arsitektur perangkat lunak didasarkan pada model yang dikembangkan
selama siklus hidup proyek. Model ini melibatkan dokumentasi terstruktur
dan visualisasi arsitektur perangkat lunak.

3. Manajemen Risiko:
RUP memasukkan manajemen risiko sebagai bagian integral dari
prosesnya. Analisis risiko dilakukan secara terus-menerus selama siklus
hidup proyek.

4. Pemisahan Fungsi dan Tanggung Jawab:

RUP membagi pengembangan perangkat lunak menjadi serangkaian
disiplin dan fase. Masing-masing disiplin memiliki tanggung jawabnya
sendiri, seperti analisis, desain, implementasi, dan pengujian.

5. Komunikasi dan Keterlibatan Pemangku Kepentingan:

RUP menekankan pada komunikasi yang efektif antara tim pengembang
dan pemangku kepentingan proyek. Pemangku kepentingan, termasuk
pengguna akhir, terlibat secara aktif dalam siklus hidup proyek.

6. Pengelolaan Perubahan:
RUP menyediakan mekanisme untuk mengelola perubahan dalam
kebutuhan atau spesifikasi proyek. Ini mencakup manajemen konfigurasi
dan pemeliharaan dokumentasi yang baik.

7. Dokumentasi Terstruktur:
 Dokumentasi dalam RUP dihasilkan secara terstruktur dan mencakup
berbagai dokumen yang mendukung setiap fase pengembangan, seperti
dokumen kebutuhan, model desain, dan dokumen pengujian.

8. Adaptasi dan Penyesuaian:

Meskipun RUP menyediakan kerangka kerja yang terstruktur, itu juga
dirancang untuk dapat disesuaikan dan diadaptasi sesuai dengan kebutuhan
spesifik proyek.

9. Tool-Oriented:
RUP mendukung penggunaan alat atau perangkat lunak untuk membantu
pelaksanaan proses. Ini bisa termasuk alat manajemen proyek, alat
pemodelan, dan alat pengujian.

10. Dikelola oleh Tim dan Proyek:

RUP memberikan panduan bagi tim pengembangan perangkat lunak dan
manajer proyek untuk mengelola proyek dengan efektif, memastikan
pemenuhan tujuan, jadwal, dan anggaran.

11. Berbasis UML (Unified Modeling Language):

RUP menggunakan UML sebagai bahasa pemodelan utama untuk
mendokumentasikan dan merancang sistem.

RUP memberikan struktur dan disiplin bagi proyek pengembangan

perangkat lunak yang kompleks dan besar.

2. Proses proses RUP

1. Inception : merupakan tahap untuk mengidentifikasi sistem yang akan
dikembangkan. Aktivitas yang dilakukan pada tahap ini antara lain
mencakup analisis sistem existing, perumusan sistem target, penentuan
arsitektur global target, identifikasi kebutuhan, perumusan persyaratan
(fungsional, performansi, keamanan, GUI, dll), perumusan kebutuhan
pengujian (level unit, integrasi, sistem, performansi, fungsionalitas,
keamanan, dll), UML diagram, dan pembuatan dokumentasi.

2. Elaboration : Elaboration merupakan tahap untuk melakukan desain secara

lengkap berdasarkan hasil analisis pada tahap inception. Aktivitas yang
dilakukan pada tahap ini antara lain mencakup pembuatan desain arsitektur
subsistem (architecture pattern), desain komponen sistem, desain format
data (protokol komunikasi), desain database, desain user interface,
pemodelan diagram UML(diagram sequence, class, component,
deployment, dll.), dan pembuatan dokumentasi.

3. Construction : Construction merupakan tahap untuk mengimplementasikan

hasil desain dan melakukan pengujian hasil implementasi. Pada tahap awal
construction, ada baiknya dilakukan pemeriksaan ulang hasil analisis dan
desain, terutama desain pada sequence diagram, class diagram, component
dan deployment. Apabila desain yang dibuat telah sesuai dengan analisis
sistem, maka implementasi dengan bahasa pemrogramanan tertentu dapat
dilakukan. Aktivitas yang dilakukan pada tahap ini antara lain mencakup
pengujian hasil analisis dan desain, pendataan kebutuhan implementasi
lengkap (berpedoman pada identifikasi kebutuhan di tahap analisis),
 penentuan coding pattern yang digunakan, pembuatan program, pengujian,
optimasi program, pendataan berbagai kemungkinan pengembangan atau
perbaikan lebih lanjut, dan pembuatan dokumentasi.

4. Transition : Transition merupakan tahap untuk menyerahkan sistem

aplikasi kepada user (roll-out), yang umumnya mencakup pelatihan dan
beta testing aplikasi.

3. Kelebihan dan Kekurangan RUP

- Kelebihan RUP

1. Membantu anggota tim untuk mengidentifikasi dan menyelesaikan risiko

proyek yang terkait dengan client melalui request management and review
yang lebih berhati-hati.

2. Metode ini cukup scalable, sehingga cocok untuk berapapun jumlah tim
atau proyeknya.

3. Review berkala membantu untuk menjaga fokus dan meningkatkan

transparansi bagi kedua belah pihak

- Kekurangan RUP

1. Proses development kompleks dan membutuhkan skill yang mendalam

dari tim.

2. Component testing yang berkelanjutan meningkatkan kompleksitas dan

hasil dimana banyak issue yang terjadi ketika fase testing.

F. RAD
1. Spesifikasi

Rapid Application Development (RAD) adalah suatu pendekatan pengembangan

perangkat lunak yang berfokus pada pengembangan cepat dan iteratif. Berikut
adalah beberapa aspek spesifikasi dari pendekatan RAD:

1. Iteratif dan Cepat: RAD berfokus pada pengembangan perangkat lunak

yang cepat dengan menggunakan siklus pengembangan yang iteratif.
Proyek dibagi menjadi iterasi pendek yang memungkinkan pengembang
untuk merespons perubahan kebutuhan pelanggan dengan cepat.

2. Pemahaman Kebutuhan Pengguna: RAD menekankan interaksi yang erat

dengan pemangku kepentingan dan pengguna akhir untuk memastikan
pemahaman yang mendalam terhadap kebutuhan dan harapan pengguna.

3. Penggunaan Prototipe: Prototipe atau model awal dikembangkan untuk

memberikan representasi visual kepada pemangku kepentingan tentang
bagaimana sistem akan berfungsi. Ini membantu memastikan pemahaman
yang jelas tentang kebutuhan dan mengurangi risiko kesalahpahaman.

4. Keterlibatan Pelanggan yang Intensif: Keterlibatan pelanggan adalah kunci

dalam RAD. Pemangku kepentingan dan pengguna secara aktif terlibat
dalam seluruh proses pengembangan untuk memberikan umpan balik yang
kontinyu.

5. Tim Pengembangan Terpadu: RAD melibatkan tim pengembangan yang

terdiri dari berbagai peran, termasuk analis bisnis, desainer, dan
pengembang perangkat lunak. Kolaborasi tim yang efektif mempercepat
pengembangan.

6. Penggunaan Alat dan Generator Kode Otomatis: RAD sering

memanfaatkan alat-alat pengembangan dan generator kode otomatis untuk
mempercepat pembangunan prototipe dan implementasi.

7. Manajemen Risiko yang Efektif:

Meskipun RAD berfokus pada pengembangan yang cepat, manajemen
risiko tetap diperhatikan. Risiko diidentifikasi dan dikelola secara proaktif
selama seluruh siklus pengembangan.

8. Pentingnya Reusabilitas:
 RAD mendorong penggunaan komponen-komponen yang dapat digunakan
kembali (reusable) untuk meningkatkan efisiensi pengembangan dan
konsistensi dalam pengembangan perangkat lunak.

9. Desain dan Pengembangan Terfokus pada Pengguna:

Desain dan pengembangan dalam RAD berfokus pada memenuhi
kebutuhan pengguna dan memastikan pengalaman pengguna yang baik.

10. Fleksibilitas terhadap Perubahan:

RAD dirancang untuk dapat menanggapi perubahan kebutuhan pelanggan
dengan cepat dan efisien. Ini memungkinkan adaptasi yang lebih baik
terhadap perubahan dalam lingkungan bisnis atau persyaratan proyek.

11. Uji yang Terus Menerus: Pengujian dilakukan secara kontinu selama
seluruh siklus pengembangan. Ini termasuk pengujian unit, integrasi, dan
pengujian sistem untuk memastikan kualitas produk.

12. Dokumentasi yang Terfokus: Dokumentasi dalam RAD terfokus pada

memberikan informasi yang paling relevan dan diperlukan. Dokumen
yang dihasilkan mencakup dokumentasi kebutuhan, desain, dan panduan
pengguna.

2. Proses Proses RAD

1. Perencanaan Kebutuhan
 Tahapan ini merupakan tahap awal dalam suatu pengembangan sistem,
dimana pada tahap ini dilakukan identifikasi masalah dan pengumpulan
data yang diperoleh dari pengguna atau stakeholder pengguna yang
bertujuan untuk mengidentifikasi maksud akhir atau tujuan dari sistem dan
kebutuhan informasi yang diinginkan. Pada tahap ini keterlibatan kedua
belah sangatlah penting dalam mengidentifikasi kebutuhan untuk
pengembangan suatu sistem.

2. Desain Sistem
Di dalam tahap desain sistem, keaktifan pengguna yang terlibat sangatlah
penting untuk mencapai tujuan karena pada tahapan ini dilakukan proses
desain dan proses perbaikan desain secara berulang-ulang apabila masih
terdapat ketidaksesuaian desain terhadap kebutuhan pengguna yang telah
diidentifikasi pada tahapan sebelumnya. Luaran dari tahapan ini adalah
spesifikasi software yang meliputi organisasi di dalam sistem secara
umum, struktur data, dan lain-lain.
3. Proses pengembangan dan pengumpulan feedback.
Pada tahap ini desain sistem yang telah dibuat dan disepakati, diubah ke
dalam bentuk aplikasi versi beta sampai dengan versi final. Pada tahapan
ini juga programmer harus terus-menerus melakukan kegiatan
pengembangan dan integerasi dengan bagian-bagian lainnya sambal terus
mempertimbangkan feedback dari pengguna atau klien. Jika proses
berjalan lancar maka dapat berlanjut ke tahapan berikutnya, sedangkan
jika aplikasi yang dikembangkan belum menjawab kebutuhan,
programmer akan kembali ke tahapan desain sistem.

4. Implementasi atau penyelesaian produk

Tahapan ini merupakan tahapan dimana programmer menerapkan desain
dari suatu sistem yang telah disetujui pada tahapan sebelumnya. Sebelum
sistem diterapkan, terlebih dahulu dilakukan proses pengujian terhadap
program untuk mendeteksi kesalahan yang ada pada sistem yang
dikembangkan. Pada tahap ini biasa memberikan tanggapan akan sistem
yang sudah dibuat dan mendapat persetujuan mengenai sistem tersebut.
3. Kelebihan dan Kekurangan RAD

- Kelebihan RAD

1. Dapat menggunakan kembali komponen yang ada (reusable object)

sebelumnya sehingga tidak perlu membuat dari awal lagi.

2. Integrasi proses yang lebih cepat dan efektif.

3. Penyesuaian kebutuhan dan keinginan user menjadi lebih mudah.

4. Memperkecil kemungkinan kesalahan atau error.

- Kekurangan RAD

1. Memerlukan kolaborasi tim yang kuat dan memadai.

2. Memerlukan komitmen yang kuat antara pengembang dan stakeholder.

3. Hanya cocok diterapkan untuk proyek kecil dan memiliki waktu

pengerjaan yang singkat.

4. Hanya cocok digunakan untuk mengembangkan aplikasi yang memiliki

fokus pada suatu fitur untuk dijadikan modular terpisah.

G. PROTOTYPING

1. Spesifikasi

Prototyping adalah suatu metode pengembangan perangkat lunak di mana model

atau prototipe awal dari sistem atau aplikasi dikembangkan untuk memberikan
gambaran visual atau konsep fungsional dari produk akhir. Berikut adalah
beberapa spesifikasi dari pendekatan prototyping:

1. Pengembangan Cepat : Prototyping bertujuan untuk memberikan hasil

yang cepat. Prototipe dapat dikembangkan dengan relatif lebih cepat
dibandingkan dengan pengembangan seluruh sistem.
2. Keterlibatan Pelanggan : Melibatkan pengguna akhir atau pemangku
kepentingan proyek dalam proses pengembangan. Prototipe digunakan
sebagai alat komunikasi yang efektif untuk memastikan bahwa kebutuhan
pengguna terpenuhi.

3. Perwujudan Visual : Menyajikan representasi visual dari produk akhir. Ini

membantu pemangku kepentingan untuk lebih memahami dan
mengevaluasi aspek visual dan desain produk.

4. Iteratif dan Responsif : Prototyping bersifat iteratif, yang berarti bahwa

prototipe dapat diperbarui dan dimodifikasi seiring berjalannya waktu
sesuai dengan umpan balik yang diterima dari pengguna atau pemangku
kepentingan.
5. Pentingnya Umpan Balik Pengguna : Prototipe digunakan untuk
mendapatkan umpan balik dari pengguna atau pemangku kepentingan
lebih awal dalam siklus pengembangan, yang membantu dalam
mengidentifikasi perubahan yang mungkin dibutuhkan.

6. Fleksibilitas terhadap Perubahan : Kemampuan untuk dengan cepat

merespons perubahan kebutuhan atau persyaratan yang muncul selama
pengembangan. Prototyping memungkinkan fleksibilitas yang lebih besar
dalam menyesuaikan desain dan fungsionalitas.

7. Desain dan Fungsionalitas Awal : Prototipe memberikan gambaran awal

tentang desain dan fungsionalitas produk akhir, meskipun mungkin tidak
mencakup seluruh fitur atau tingkat detail.

8. Pengujian dan Evaluasi Awal : Prototipe dapat digunakan untuk

melakukan pengujian dan evaluasi awal terhadap fungsionalitas dan
desain. Ini membantu mengidentifikasi masalah atau perbaikan yang
mungkin diperlukan sebelum implementasi penuh.

9. Pembangunan Sistem Bertahap : Prototyping memungkinkan

pembangunan sistem secara bertahap. Prototipe awal dapat menjadi dasar
untuk membangun fungsionalitas tambahan atau memperbarui sistem
secara bertahap.

10. Peningkatan Komunikasi Tim : Prototyping dapat meningkatkan

komunikasi dalam tim pengembangan dan antara tim dan pemangku
 kepentingan. Model visual memudahkan pemahaman dan diskusi antar
anggota tim.

11. Pemodelan Berbasis Pengguna : Prototyping berfokus pada pengalaman

pengguna. Hal ini memungkinkan pengguna untuk berinteraksi dengan
model dan memberikan umpan balik yang dapat meningkatkan akurasi
implementasi akhir.

12. Dokumentasi yang Fleksibel : Dokumentasi prototyping bersifat lebih

fleksibel dan tidak harus sesuai dengan standar dokumentasi yang ketat.
Ini memungkinkan penyesuaian dokumen sesuai dengan perubahan
prototipe.

2. Proses proses prototyping

1. Requirements
Tahapan awal model prototype dimulai dari analisis kebutuhan. Dalam
tahap ini kebutuhan sistem didefinisikan dengan rinci. Dalam prosesnya,
klien dan tim developer akan bertemu untuk mendiskusikan detail sistem
seperti apa yang dibutuhkan oleh user.

2. Quick design
Tahap kedua adalah pembuatan desain sederhana yang akan memberi
gambaran singkat tentang sistem yang ingin dibuat. Design baru dapat
dibuat jika persyaratan dari user sudah diketahui. Setelah itu, pembuatan
design dapat dilakukan berdasarkan requirement gathering dan analisis
pada tahap 1.

3. Build prototype
Setelah desain quick design disetujui oleh user, tahap selanjutnya yaitu
pembangunan prototype sebenarnya yang akan dijadikan rujukan tim
programmer untuk pembuatan program atau aplikasi.
 4. User evaluation
Setelah prototype dibuat selanjutnya adalah tahap evaluasi oleh user. Pada
tahap ini, sistem yang telah dibuat dalam bentuk prototype dipresentasikan
pada klien untuk di evaluasi. Selanjutnya, user akan memberikan komentar
dan saran terhadap prototype yang telah dibuat. Prototype jauh lebih cepat
dibuat daripada implementasi sistem yang sudah jadi, sehingga user dapat
mengevaluasinya lebih cepat dan memberikan evaluasi yang lebih cepat
tentang desain yang baik dan buruk.

5. Refining prototype
Tahap refining merupakanan tahap perbaikan prototype berdasarkan hasil
feedback klien pada tahap 4. Jika user tidak mempunyai catatan revisi dari
prototype yang dibuat, maka tim bisa berlanjut pada tahapan 6 untuk
implementasi produk. Apabila klien mempunyai catatan untuk perbaikan
sistem, maka fase 4-5 akan terus berulang sampai klien setuju dengan
sistem yang akan dikembangkan.

6. Implement product and maintain

Setelah perbaikan pada tahap 5 disetujui klien, maka selanjutnya adalah
tahap implement dan maintanance. Pada fase akhir ini, produk akan segera
dibuat oleh para programmer berdasarkan prototype akhir. Selanjutnya,
sistem akan diuji dan diserahkan pada klien dan fase pemeliharaan agar
sistem berjalan lancar tanpa kendala.

3. Kelebihan dan Kekurangan

- Kelebihan Prototyping

1. Menghemat waktu dalam pengembangan sistem.

2. Menentukan kebutuhan lebih mudah ditetapkan.
3. Klien ikut aktif dalam pengembangan sistem, sehingga hasil perangkat
lunak mudah disesuaikan dengan kebutuhan dan keinginan klien.
4. Komunikasi yang baik antara pelanggan dan pengembang.
5. Pengembang dapat lebih mudah menentukan kebutuhan pelanggan.
6. Menghemat waktu dalam sistem pengembangan prototipe.

- Kekurangan Prototyping

1. Proses perencanaan dan analisis terlalu singkat.

2. Biasanya tidak fleksibel dalam menghadapi perubahan.
3. Pengembang terkadang membuat peringatan implementasi dengan
menggunakan sistem operasi yang tidak relevan dan algoritma yang tidak
efisien.
4. Pelanggan tidak dapat melihat perangkat lunak dengan gambaran umum
perangkat lunak dan tidak memikirkan pemeliharaannya untuk waktu yang
lama.
5. Hubungan antara pelanggan dan komputer tidak dapat digambarkan
sebagai teknik perencanaan yang baik jika dilihat dari awal prototipe.