TUGAS REKAYASA

PERANGKAT LUNAK

Nama Kelompok:

Irwan (C1855201017)
Panji (C1855201042)
Pebe Yupinda (C1855201028)
Yon Novembrian (C1855201029)
David Kaharap (C1855201009)
Widya Margareta S. (C1855201003)
1. MODEL EVOLUTIONARY DEVELOPMENT

Model Evolutionary Development bersifat iteratif (mengandung perulangan). Hasil

prosesnya berupa produk yang makin lama makin lengkap sampai versi terlengkap
dihasilkan sebagai produk akhir dari proses. dan metode ini dibagi 2 yaitu:
1.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 spefikasi yang makin kesini makin lengkap. 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.
a. Contoh Penerapan Model Incremental:

Perangkat lunak pengolah kata yang dikembangkan dengan menggunakan

paradigma pertambahan akan menyampaikan manajemen file, editing, serta fungsi
penghasilan dokumen 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 yang lengkap akan
fungsi.

Gambar Model Incremental.

1.
b. 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
c. 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.
 Tidak cocok untuk projek besar.

1.2 Model Spiral / Model Boehm.
Model ini mengadaptasi dua model perangkat lunak yang ada yaitu model
prototyping dengan pengulangannya dan model waterfall dengan pengendalian dan
sistematikanya. Model ini dikenal dengan sebutan Spiral Boehm. Pengembang dalam
model ini memadupadankan beberapa model umum tersebut untuk menghasilkan
produk khusus atau untuk menjawab persoalan-persoalan tertentu selama proses
pengerjaan proyek.Lebih singkatnya model ini menggunakan sistem pengulangan yang
makin kesini makin lengkap fungsi dll.

Gambar Model Spiral / Model Boehm.

2.
 a. Tahap-tahap model ini dapat dijelaskan secara ringkas sebagai berikut :
 Tahap Liason:pada tahap ini dibangun komunikasi yang baik dengan calon
pengguna/pemakai.
 Tahap Planning (perencanaan):pada tahap ini ditentukan sumber-sumber
informasi, batas waktu dan informasi-informasi yang dapat menjelaskan
proyek.
 Tahap Analisis Resiko:mendefinisikan resiko, menentukan apa saja yang
menjadi resiko baik teknis maupun manajemen.
 Tahap Rekayasa (engineering):pembuatan prototipe.
 Tahap Konstruksi dan Pelepasan (release):pada tahap ini dilakukan
pembangunan perangkat lunak yang dimaksud, diuji, diinstal dan diberikan
sokongan-sokongan tambahan untuk keberhasilan proyek.
 Tahap Evaluasi:Pelanggan/pemakai/pengguna biasanya memberikan
masukan berdasarkan hasil yang didapat dari tahap engineering dan
instalasi.
b. Kelebihan model ini:
adalah sangat mempertimbangkan resiko kemungkinan munculnya kesalahan
sehingga sangat dapat diandalkan untuk pengembangan perangkat lunak skala besar.
Pendekatan model ini dilakukan melalui tahapan-tahapan yang sangat baik dengan
menggabungkan model waterfall ditambah dengan pengulangan-pengulangan sehingga
lebih detail untuk mencerminkan keadaan sebenarnya. Baik pengembang maupun
pemakai dapat cepat mengetahui letak kekurangan dan kesalahan dari sistem karena
proses-prosesnya dapat diamati dengan baik dan detail.
c. Kekurangan model ini :
adalah waktu yang dibutuhkan untuk pengembangkan perangkat lunak cukup
panjang demikian juga biaya yang besar. Selain itu, sangat tergantung kepada tenaga
ahli yang dapat memperkirakan resiko. Terdapat pula kesulitan untuk mengontrol
proses. Sampai saat ini, karena masih relatif baru, belum ada bukti apakah metode ini
cukup handal untuk diterapkan.

3.
 2. WATERFALL DEVELOPMENT MODEL.

2.1 Sejarah.
a. Presentasi pertama yang menggambarkan penggunaan fase dari
model waterfall dalam rekayasa perangkat lunak diberikan oleh Herbert D.
Benington di Symposium on Advanced Programming Methods for Digital
Computers pada tanggal 29 Juni 1956. Presentasi ini adalah tentang pengembangan
perangkat lunak untuk SAGE. Pada tahun 1983, makalah ini diterbitkan kembali dengan
kata pengantar oleh Benington yang menjelaskan bahwa fase-fase tersebut sengaja
disusun sesuai dengan spesialisasi tugas, dan menunjukkan bahwa proses tersebut
sebenarnya tidak dilakukan dengan cara top-down yang ketat, tetapi tergantung
pada prototipe.
b. Deskripsi formal pertama dari model waterfall sering dikutip sebagai artikel
tahun 1970 oleh Winston W. Royce, meskipun Royce tidak menggunakan
istilah waterfall dalam artikel itu. Royce menyajikan model ini sebagai contoh model cacat
yang tidak bekerja; itulah istilah yang umumnya digunakan dalam penulisan tentang
pengembangan perangkat lunak untuk menggambarkan pandangan kritis praktik
pengembangan perangkat lunak yang umum digunakan. Penggunaan awal dari
istilah waterfall mungkin dalam makalah tahun 1976 oleh Bell and Thayer.
c. Pada tahun 1985, Departemen Pertahanan Amerika Serikat menangkap pendekatan
ini dalam DOD-STD-2167A, standar mereka untuk bekerja dengan kontraktor
pengembangan perangkat lunak, yang menyatakan bahwa "kontraktor harus
menerapkan siklus pengembangan perangkat lunak yang mencakup enam fase
berikut: Preliminary Design, Detailed Design, Coding and Unit Testing,
Integration, danTesting".

2.2 Pengertian Metode Waterfall.

Metode waterfall atau metode air terjun merupakan salah satu siklus hidup klasic
(Classic life cycle) dalam pengembangan perangkat lunak. Metode ini menggambarkan
pendekatan yang cukup sistematis juga berurutan pada pengembangan software, mulai dari
:
a. spesifikasi kebutuhan pengguna,
b. perencanaan,
c. permodelan,
d. konstruksi,
e. penyerahan sistem ke pengguna,
f. serta perawatan system.

Tahapan-Tahapan Metode Waterfall:

4.
 Dari pengertian di atas sebetulnya kita sudah mendapatkan tahapan-tahapan metode
pengembangan software ini. Supaya lebih jelas berikut ini uraiannya.
1. Requirement.

Pada tahap ini pengembang harus mengetahui seluruh informasi mengenai

kebutuhan sofatware seperti kegunaan software yang diinginkan oleh pengguna dan
batasan software. Informasi tersebut biasanya diperoleh dari wawancara, survey,
ataupun diskusi. Setelah itu informs dianalisis sehingga mendapatkan data-data yang
lengkap mengenai kebutuhan pengguna akan software yang akan dikembangkan.
2. Design.

Tahap selanjutnya yaitu Desain. Desain dilakukan sebelum proses coding dimulai.
Ini bertujuan untuk memberikan gambaran lengkap tentang apa yang harus dikerjakan
dan bagaimana tampilan dari sebuah sistem yang diinginkan. Sehingga membantu
menspesifikan kebutuhan hardware dan sistem, juga mendefinisikan arsitektur sistem
yang akan dibuat secara keseluruhan.
3. Implementation.

Proses penulisan code ada di tahap ini. Pembuatan software akan dipecah menjadi
modul-modul kecil yang nantinya akan digabungkan dalam tahap selanjutnya. Dalam
tahap ini juga akan dilakukan pemeriksaan lebih dalam terhadap modul yang sudah
dibuat, apakah sudah memenuhi fungsi yang diinginkan atau belum.
4. Integration & Testing.

Pada tahap keempat ini akan dilakukan penggabungan modul-modul yang sudah
dibuat sebelumnya. Setelah itu akan dilakukan pengujian yang bertujuan untuk

5.
 mengetahui apakah software sudah sesuai desain yang diinginkan dan apakah masih
ada kesalahan atau tidak.
5. Operation & Maintenance.

Operation & Maintenance adalah tahapan terakhir dari metode pengembangan

waterfall. Di sini software yang sudah jadi akan dijalankan atau dioperasikan oleh
penggunanya. Disamping itu dilakukan pula pemeliharaan yang termasuk :
• perbaikan kesalahan,
• perbaikan implementasi unit system,
• peningkatan jasa sistem sesuai kebutuhan baru

2.3 Keunggulan Metode Waterfall.

Di bawah ini adalah beberapa kelebihan mengembangkan software dengan metode
waterfall, antara lain :
• Metode ini adalah model pengembangan yang paling handal dan paling lama
digunakan oleh para developer,
• Cocok untuk membuat software dengan skala besar,
• Cocok untuk mengembangkan sistem yang bersifat generic,
• Pengerjaan proyek sistem akan mudah dikontrol dan terjadwal dengan baik.

2.4 Kekurangan Waterfall.

Selain kelebihan, tentunya setiap metode pengembangan software memiliki kekurangan,
adapun kekurangan dari waterfall yaitu :
• Persyaratan sistem harus digambarkan dengan jelas,
• Rincian proses harus benar-benar jelas dan tidak boleh berubah,
• Sulit untuk beradaptasi jika ada perubahan spesifikasi pada suatu tahapan
pengembangan.

2.5 Contoh Metode Waterfall Sistem Informasi.

Berikut ini adalah contoh penerapan metode waterfall pada sistem informasi alumni pada
sebuah SMK:
No Tahapan Uraian
.
1. Alasan menggunakan Karena kebutuhan pihak sekolah telah jelas.
waterfall.
2. Analisis. Analisis kebutuhan dilakukan dengan cara mewawancarai
coordinator BK SMK A. Dari wawancara didapatkan data-
data seputar alumni, seperti : total alumni yang lulus,
alumni yang bekerja, dan alumni yang melanjutkan studi
3. Desain Perancangan sistem menggunakan ERD seperti Use Case
dan Sequence.

6.
 4. Iplementasi Sistem informasi akan dibuat menggunakan bahasa
pemrograman PHP dengan Framework CodeIgninter.
5. Pengujian system Pengujian dilakukan pada aspek fungsionalitas kepada ahli
sistem informasi, petugas administrator dan alumni
langsung.
6. Maintenance Pemeliharaan akan dilakukan apabila ada update fitur atau
memperbaiki kesalahan yang ditemukan pada saat sistem
digunakan langsung oleh user.

3. PENGEMBANGAN SISTEM SPIRAL MODEL

Model spiral diperkenalkan pertama kali oleh Barry Boehm pada makalahnya yang berjudul
Spiral Model of Software Development and Enhancement. Barry Boehm menjelaskan
bahawa model spiral merupakan model yang sangat berguna untuk melakukan pembangunan
proyek-proyek besar dan prosesnya dilakukan dengan memperhatikan resiko proyek sehingga
pada akhirnya akan menghasilkan model proses yang tepat sesuai kebutuhan pengguna.

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.

7.
Fungsi model spiral adalah untuk melakukan perubahan, penambahan dan pengembangan
perangkat lunak dengan memaksimalkan aspek kecepatan dan ketepatan berdasarkan
keinginan dan kebutuhan penggunanya.

Tahapan dalam Spiral Model

Dalam penerapan Model Spiral, terdapat lima tahapan untuk merealisasikan penggunaannya,
yaitu sebagai berikut:

1. Tahap Liason

Tahap ini 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 reisiki 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:

 Menguji, coding dan mengembangkan software

 Menginstal software
 Membuat prototype
 Mendesain dokumen
 Meringkas suatu pengujian software
 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).

Kelebihan dalam menggunakan model spiral :

8.
 1. Pembangunan dan perubahan perangkat lunak yang terjadi dapat diselesaikan secara
sistematis
2. Mudah dalam mengestimasi biaya karena proses pembuatan prototype yang jelas dan
terencana dalam tahapan yang sistematis
3. Manajemen dan analisa risiko yang lebih cepat dan mudah
4. Mudah dalam melakukan perubahan kebutuhan dan dokumentasi
5. Produksi software bisa terjadi lebih cepat

Kekurangan dalam menggunakan model spiral :

1. Tidak cocok dan sulit diimplementasikan dalam projek kecil

2. Memakan waktu yang cukup lama
3. Membutuhkan best practice atau pengalaman sebelumnya karena proses yang sangat
kompleks
4. Resiko dalam tahap planning cukup besar. Misalnya terjadi perbedaan dalam jadwal
pengembangan dan anggaran belanja.

4. INCREMENTAL DEVELOPMENT MODEL

model proses ini dilakukan secara bertahap dan tahap pengerjaan dilakukan permodul.
Bisa dikatakan Incremental adalah bentuk pengulangan secara bertahap dari Waterfall. Model
ini mengaplikasikan urutan-urutan linier secara bertingkat selaras dengan berjalannya waktu.
Setiap urutan linier menghasilkan penambahan (increment) pada software yang dikirimkan.
Proses model ini menfokuskan pada pengiriman produk operasional pada setiap
penambahannya. Produk awal adalah versi rendah dari produk akhir namun telah mampu
mengakomodir kebutuhan pengguna. Apabila aliran proses dari Communication sampai
Deployment telah selesai pada tahap pertama, maka dilanjutkan pada pengerjaan tahap kedua
yang aliran prosesnya sama yaitu dari Communication sampai Deployment. Proses ini
berlangsung berulang-ulang secara bertahap sampai tahap final. Tahap pertama adalah tahap
yang penting karena tahap pertama merupakan tahap kunci dan produk perdana dalam
pengembangan karena apabila produk pada tahap pertama gagal, maka tahap selanjutnya
tidak akan berjalan. Tahap pertama sering disebut dengan Core Product.

9.
Contoh Penerapan Model Incremental
Perangkat lunak pengolah kata yang dikembangkan dengan menggunakan paradigma
pertambahan akan menyampaikan manajemen file, editing, serta fungsi penghasilan dokumen
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 Incremental :
 Penambahan kemampuan "ungsional akan lebih mudah diuji, di$eri"ikasi, dan
di$alidasidan dapat menurunkan biaya yang dikeluarkan untuk memperbaiki sistem.
 resiko lebih minim dan hasil dapat lebih baik secara bertahap
 Personil bekerja optimal.mampu mengakomodasi perubahan secara "leksibel,
denganwaktu yang relati" singkat dan tidak dibutuhkan anggota*tim kerja yang
banyak untuk menjalankannya.
 Pihak konsumen dapat langsung menggunakan dahulu bagian-bagian yang telah
selesaidibangun. +ontohnya pemasukan data karyawan.
 mengurangi trauma karena perubahan sistem. Klien dibiasakan perlahan-
lahanmenggunakan produknya setiap bagian demi bagian dan memaksimalkan
pengembalian modal in$estasi konsumen.

10.
Kelemahan model incremental:
 Hanya akan berhasil jika tidak ada sta""ing untuk penerapan secara menyeluruh
 Bila ada perubahan harus dikerjakan sebagai produk baru.
 Penambahan sta" dilakukan jika hasil incremental akan dikembangkan lebih lanjut
 Sulit untuk memetakan kebutuhan pemakai ke dalam rencana spesifikasi tiap-tiap
hasildari increament

5. SCRUM DEVELOPMENT MODEL

Metode ini adalah turunan dari metode agile, yang nantinya akan dibahas secara
tersendiri. scrum seringkali tidak digolongkan sebagai metodologi, melainkan suatu
kerangka kerja yang menggunakan pendekatan iteratif (perulangan) dan inkremental
(berangsur-angsur).
Pengembang menerapkan scrum ketika ingin membuat sistem yang kompleks.
Pasalnya, kerangka kerja ini memang ditujukan untuk menghasilkan produk bernilai
tinggi, unik sekaligus produktif. Kabarnya Google, Microsoft, hingga Spotify menerapkan
sistem ini.

Berbeda dengan metode waterfall yang memakai pendekatan

sistematis, scrum diaplikasikan dengan lima tahapan yang bersifat imperatif dan
inkremental. Oleh karena itu, kerangka kerja scrum pasti melibatkan beberapa tim yang
saling bersinergi. Kerangka kerja scrum membagi proses pengembangan menjadi target-
target kecil yang dinyatakan dalam satuan sprint. Istilah ini mengacu pada kecepatan lari
jarak pendek. Sejumlah target kecil harus selesai dalam waktu singkat untuk tujuan akhir
yang lebih besar.  

Pengembangan dimulai dengan merumuskan target sprint prioritas dari setiap tim.

Diikuti dengan identifikasi pekerjaan spesifik serta proses pengerjaan sesuai
target sprint yang telah ditentukan. Sementara itu, evaluasi berkala dilakukan selama masa
penggarapan tiap sprint.  Setiap sprint berakhir, tim yang terlibat selalu menyampaikan
hasil pekerjaannya. Tahapan ini juga mencakup evaluasi menyeluruh dan perumusan ide-
ide baru yang mungkin bisa diterapkan pada sprint berikutnya.

11.
 

Kekurangan dan Kelebihan Metode Scrum

Kelebihan:

-Kelebihan dari metode scrum terletak pada kemampuannya untuk menghasilkan perangkat

lunak bernilai tinggi. Pun dipandang lebih efektif karena mampu mengatasi permasalahan
kompleks dengan mendelegasikan tugas-tugas spesifik kepada beberapa tim yang mandiri. 

Kekurangan:

-Masalah baru muncul ketika terjadi kendala yang membuat salah satu tim gagal mencapai
target sprint-nya. Imbasnya akan memengaruhi ritme kerja tim yang lain. Metode ini juga
memungkinkan improvisasi bebas sehingga membutuhkan tim dengan fleksibilitas tinggi

6. KENBAN DEVELOPMENT MODEL

Kanban merupakan suatu metode untuk menvisualisasikan proses perkerjaan yang

dilakukan saat kita sedang mengembangkan suatu Software. Team member
dapat Menarik/Pull tugas yang harus diselsaikan dan bukan mendorong atau didorong oleh
suatu tugas. Dengan menggunakan metode ini, kita dapat menjaga keseimbangan antara
perkerjaan team member yang satu, dengan team member yang lainya. Metode ini juga dapat

12.
melacak Bottleneck dalam pengembangan aplikasi. Untuk mengetahu lebih lanjut
tentang Kanban pertama kita harus mengerti tentang proses Agile development berkerja.

Agile Development hampir sama dengan metodologi pengembangan sistem lainya,

yaitu Stakeholders dan manajer berunding dan membuat suatu dokumen yang
menyatakan Requirement, Keinginan, dan Ekspektasi dari suatu produk yang akan
dibuat. Requirement, Keinginan dan Ekspektasi ini akan di kumpulkan ke dalam suatu
dokumen yang disebut Product Backlog. 

Setelah itu, Project Manager akan menugaskan Dev Team untuk berkerja membuat

produk tersebut dan hasilnya akan diberikan ke User dimana user akan
memberikan feedbacks ke project Manager.

Perbedaanya adalah, Agile memberikan hasil secara Incremental kepada User setiap 2

atau 3 minggu sekali dan bukan menghasilkan 1 produk langsung secara
komplit. Kanban adalah suatu Framework agar Dev Team dapat melaksanakan Agile dengan
rapih dan benar.

Secara singkat, proses kerja yang dilakukan Dev Team jika mereka

menggunakan Kanban adalah sebagai berikut.  

1. Memilih Agile Coach yang bertanggung jawab memimpin team agar berkerja dengan

etika dan kebiasaan yang benar.

13.
2. Menyiapkan Kanban Board dan beberapa Post-It/Sticker atau kertas apapun yang
dapat ditempelkan ke Kanban Board.
3. Dev Team dan Agile Coach membuat segmentasi di Kanban Board, biasanya
berbentuk seperi berikut:

4. Dev Team dan Agile Coach menuliskan tugas – tugas apa yang harus diselesaikan dan
limit tugas yang dapat dikerjakan di setiap segmentasi.

5. Dev Team berkerja dan setiap perkerjaan selesai, Post-It yang merepresentasikan

tugas tersebut dipindahkan ke segment selanjutnya, jika tugas di “TO-DO” mulai
sedikit, maka Dev Team akan menarik tugas dari Product Backlog. Setiap pagi, Dev
Team akan melakukan Daily Stand-Up untuk membicarakan progress.

14.
15.
 6. Jika tugas yang di “DONE” sudah cukup, maka Dev Team akan mempaketkan produk
tersebut, melakukan Demo di depan Stakeholders, dan me-release product tersebut.
7. Setelah product di release di minggu tersebut, Dev
Team dan Stakeholders melakukan Retrospection untuk membicarakan kinerja dari
minggu-minggu tersebut.
8. Lalu kegiatan tersebut akan dilakukan berulang-ulang sampai produk benar-benar
selesai.

   

Dev Team dan Agile Coach dapat melonggarkan beberapa kegiatan

dari Kanban (walau hal ini tidak disarankan). Misal, Dev Team menambahkan batas
maksimum “CODE” dan “TESTING” menjadi 5 buah. Kanban juga menggunakan peraturan
dalam mendefinisikan suatu tugas. Tugas yang didefinisikan biasanya tugas yang hanya
memakan waktu 2 hari untuk dikerjakan, jika tugas tersebut melebihi dari 2 hari maka tugas
tersebut harus di bagi menajdi 2 dan seterusnya. Maka dengan mengetahui peraturan
tersebut, Kanban Board akan berisikan detail seperti ini.

Dengan sistem ini, Agile Coach dapat mengetahui mengapa suatu tugas tidak selesai tepat
waktu dan apa yang harus dilakukan untuk menyelesaikanya.

Keuntungan dari menggunakan Kanban Board adalah sebagai berikut:

16.
  Flexibel : Dengan memvisualisasikan perkerjaan yang dilakukan, kita dapat
mengetahui bottleneck dan kesalahan yang dapat dengan mudah diubah.
 Memperlihatkan WIP : Dengan mengetahui WIP (Work In Progress) team dapat
menentukan kapan dan seberapa cepat suatu tugas harus diselesaikan.
 Memudahkan dalam menjaga flow perkerjaan : Dengan sistem ini Agile Coach dapat
menjaga agar setiap tugas dapat diselesaikan dan release produk berjalan lancar.
 Mempromosi kebersamaan : Dengan menggunakan Kanban, tim harus belajar
memiliki kebiasaan yang baik dan pola kerja yang baik seperti saat ada masalah,
masalah tersebut harus diselesaikan secara cepat hari itu juga dengan tatap muka.

Kanban dikembangkan sebagai sarana pemenuhan just-in-time (JIT) sistem

persediaan. Dengan menerapkan kanban, bahan dan persediaan tiba tepat ketika Anda
membutuhkan mereka.

Hal ini mengurangi biaya penyimpanan dan membawa. Kanban sebagian besar
berhubungan dengan manufaktur. Sebuah perhatian utama di bidang manufaktur adalah
kebutuhan untuk memiliki persediaan siap bahan, tanpa menimbulkan biaya persediaan yang
tidak perlu memegang. Tetapi juga dapat diterapkan dalam lingkungan non manufaktur, di
mana efisiensi alur kerja Anda tergantung pada memiliki sumber daya yang tersedia. Istilah
'kanban' menggabungkan kata-kata Jepang 'kan,' yang berarti 'visual' dan 'larangan', yang
berarti 'kartu' atau 'papan. " Sebuah kanban kartu visual atau isyarat lain yang sinyal ada
sesuatu yang diperlukan.

Ini adalah "menarik" sistem, di mana pasokan ditentukan oleh produsen atau
pengguna. Sebuah Kanban adalah kartu fisik yang digunakan dalam Toyota Production
System (TPS) untuk mendukung non-terpusat "tarik" kontrol produksi. Hal ini telah
menyebar ke industri manufaktur di seluruh dunia sebagai alat Lean Manufacturing. Sekarang
dalam pengembangan perangkat lunak Agile visualisasi proyek, seperti posting kartu tugas di
dinding, adalah praktek umum terlihat, yang kadang-kadang disebut "Software Kanban", atau
"Tugas Kanban". Sekarang kita bahkan melihat beberapa tim pemeliharaan produk
memanfaatkan sistem Kanban dalam model proses air terjun seperti.

Jadi apa Kanban? Mengapa ini dipakai dalam konteks pengembangan perangkat
lunak? Pada artikel ini, pertama di jelaskan bahwa sebuah sistem Kanban adalah dalam
konteks Lean manufacturing, khususnya di TPS, dan mengumpulkan wawasan dari praktek

17.
dan prinsip-prinsip dalam industri dewasa, mengidentifikasi konsep-konsep yang dapat
diterapkan untuk pengembangan perangkat lunak. Kedua kita lihat ke sekeliling proyek
pengembangan perangkat lunak dan menunjukkan contoh-contoh aplikasi Kanban.  
Kemudian, kita menganalisis kesamaan dan perbedaan antara sistem Kanban dalam produksi
dan pengembangan perangkat lunak, dan mencoba untuk memberikan ide-ide tentang cara
efektif menerapkan sistem Kanban untuk pengembangan perangkat lunak, termasuk
pengantar untuk gerakan baru-baru ini "KSSE - Sistem Kanban untuk Sustaining Rekayasa"
muncul pada kanbandev  daftar diskusi. Akhirnya, kita memberikan gambaran besar TPS,
konteks asli untuk yang menggunakan Kanban sebagai alat, dan dari pengembangan
perangkat lunak yang masih dapat belajar lebih banyak.  

Apa Kanban di TPS? Kanban adalah perangkat sinyal (biasanya kartu fisik dalam
amplop plastik bening) yang menginstruksikan bergerak atau membuat bagian-bagian dalam
suatu sistem "menarik" produksi, ditemukan dan dikembangkan sebagai bagian dari Toyota
Production System (TPS).

Sebelum masuk ke Kanban dalam pengembangan perangkat lunak, di sini saya

mengambil melihat dari dekat aslinya yaitu penggunaan yang Kanban di TPS. Tujuan kanban
adalah untuk meminimalkan WIP (Work-In-Process), atau persediaan, antara proses dengan
memastikan bahwa proses menghasilkan bagian hulu hanya jika proses hilir
membutuhkannya. "Tarik" berarti bahwa para pekerja hilir menarik atau "tarik" bagian-
bagian yang mereka butuhkan dari proses hulu mereka.

Gambar 1 adalah sebuah model abstrak dari sistem Kanban. Digambarkan di

dalamnya adalah dua proses, sebuah hulu dan hilir proses, dimana proses persediaan bagian

18.
(item) hulu ke hilir. Dalam rangka untuk memasok produk ke konsumen akhir, proses
kebutuhan untuk memproduksi komponen dan membuat mereka mengalir ke hilir, tetapi
tidak terlalu banyak, karena overproduksi dianggap pemborosan terburuk. Jadi untuk
mencegah kelebihan produksi, hulu tidak "mendorong" selesai bagian ke hilir, tetapi itu
adalah hilir yang secara aktif menarik (mengambil) bagian-bagian dari hulu. Ruang di mana
bagian ditempatkan disebut "toko" (atau "supermarket  Taiichi Ohno mendapat ide pertama
dari Kanban ketika ia mengunjungi sebuah supermarket Amerika, di mana tidak pegawai
toko namun pelanggan sendiri yang pergi untuk mendapatkan apa yang ia membutuhkan di
toko). 

Toko adalah di lokasi hulu dan bekerja sebagai "penyangga" atau "antrian" WIP.
Ketika seorang pekerja dari proses hilir, yang disebut "materi handler", datang ke toko dan
mengambil bagian yang baru selesai, itu juga kembali sinyal produksi - yaitu hal-hal menarik
hilir dari hulu dan pada saat yang sama mendorong informasi kepada hulu melalui kartu
Kanban. Hal ini diperlukan, karena proses hulu tidak pernah menghasilkan bagian tanpa
instruksi dari proses hilir.  Jadi di sini adalah dua jenis Kanban bekerja sama dalam Gambar
1:

 Withdraw Kanban - adalah salah satu item pada daftar belanja yang handler bahan
yang dibutuhkan untuk toko.
 Kanban Produksi - menginstruksikan proses hulu untuk memproduksi komponen
untuk proses hilir.

Seperti ditunjukkan dalam Gambar 1, menarik Kanbans beredar antara proses,

sementara Kanbans beredar dalam proses produksi, dan mereka dipertukarkan di toko. Mari
kita sedikit lebih ke dalam mekanisme ini. Gambar 2 mengilustrasikan bagaimana "Kanban
pertukaran" bekerja di toko.

19.
 Gambar 2 Kanban Exchange di Store

1. Seorang penangan material di lokasi hilir ditandai untuk menarik bagian. Sinyal
didefinisikan oleh proses hilir dan salah satu dari dua di bawah ini:
(A) ditandai dengan jumlah dikumpulkan menarik Kanbans
(B) ditandai dengan interval waktu periodik Ia mengunjungi toko di lokasi hulu
dengan palet kosong dan dikumpulkan-Nya menarik Kanbans sebagai daftar
belanja, yang menunjukkan apa yang dibutuhkan dan dalam jumlah apa untuk
proses hilir.
2. Bagian selesai dengan proses hulu dikemas dalam palet dan ditempatkan di toko
dengan Kanbans produksi terpasang. (Hal ini terjadi terlepas dari (1), dalam thread
terpisah.)
3. Handler bahan mengambil bagian yang ditentukan oleh menarik Kanban (daftar
belanja), memeriksa apakah cocok dengan Kanban produksi melekat pada bagian-
bagian, dan pertukaran dua Kanbans.
4. Dia menempatkan Kanban produksi ke "Dewan Produksi", yang nantinya akan memicu
produksi visual hulu saat Kanbans tumpukan pada ambang.
5. Dia menyampaikan bagian yang diperlukan, dengan Kanban menarik terpasang, dari
toko ke lokasi hilir.
Anda melihat bahwa toko adalah antrian antara dua proses, bekerja di sebuah thread
terpisah dari kontrol, bertukar informasi melalui hal-hal dan Kanban. Pada permukaan kartu
Kanban, informasi seperti nomor bagian / nama, jumlah, jenis palet, alamat toko, ditulis
sehingga penangan bahan yang mengambil kartu ini bisa tahu apa yang harus dilakukan.

20.
 Ada disiplin yang ketat menjalankan Kanban, yang disebut "aturan enam dari Kanban":
1. Pelanggan (Hilir) proses menarik item dalam jumlah yang tepat ditentukan pada
Kanban itu.
2. Pemasok (Hulu) menghasilkan item dalam jumlah yang tepat dan urutan yang
ditentukan oleh Kanban
3. Tidak ada item yang dibuat atau dipindahkan tanpa Kanban sebuah.
4. Kanban A harus menemani setiap item, setiap saat.
5. Cacat dan jumlah yang salah tidak pernah dikirim ke proses hilir berikutnya.
6. Jumlah Kanbans berkurang hati-hati untuk persediaan yang lebih rendah dan untuk
mengungkapkan masalah.

Sebagaimana telah kita bahas, toko bekerja sebagai antrian bagian, palet bekerja
sebagai pembawa bagian, dan kartu Kanban bekerja sebagai pembawa pelanggan
membutuhkan informasi. Mereka membuatnya menjadi "menarik" sistem, menciptakan
keseimbangan antara mempertahankan "aliran kontinu" (menghilangkan pemborosan
menunggu) dan "WIP minizing" (menghilangkan pemborosan overproduksi). Mekanisme
pengelolaan "hak" jumlah WIP dalam aliran antara membeli-in dan menjual-out adalah persis
apa yang terjadi di supermarket, dan melakukannya dengan baik adalah kunci untuk
profitabilitas toko.

7. METODE PROTOTYPE

Prototype adalah salat satu metode pengembangan perangkat lunak yang banyak
digunakan Dengan menggunakan Metode prototyping ini , pengembangan dan pelanggan
dapat saling berinteraksi selama proses pembuatan sistem . Sering terjadi seorang pelanggan
hanya mendefinisikan secara umum apa yang dibutuhkan , pemrosesan dan data-data apa saja

21.
yang dibutuhkan. Sebaliknya , disisi pengembang kurang memperhatikan efisiensi
Algoritma . Kemampuan sistem operasi dan interface yang menghubungkan manusia dengan
komputer.
Pada prototyping model kadang- kadang klien hanya memberikan beberapa
kebutuhan umum software tanpa detail input, proses atau detail output dilain waktu mungkin
tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan,
tingkat adaptasi terhadap sistem operasi atau rancangan form user interface. Ketika situasi
seperti ini , terjadi model prototyping sangat membantu proses pembangunan software.
Proses pada prototyping bisa dijelaskan sebagai berikut.
1. Pengumpulan Kebutuhan . Developer dan klien bertemu dan menentukan tujuan
umum, kebutuhan yang diketahui dan gambaran bagian - bagian yang akan
dibutuhkan berikutnya. Detail kebutuhan mungkin tidak dibicarakan disini , pada awal
pengumpulan kebutuhan.
2. Perancangan . Perancangan dilakukan cepat dan rancangan mewakili aspek software
yang diketahui dan rancangan ini menjadi dasar pembuatan prototype.

3. Evaluasi Prototype . Klien mengevaluasi prototype yang dibuat dan dipergunakan

untuk memperjelas kebutuhan software.

Tahapan - Tahapan Prototype

Tahap - tahap pengembangan model prototype menurut bapak Roger S . Pressman adalah :

1 . Mendengarkan Pelanggan 
Pada tahap ini dilakukan pengumpulan kebutuhan dari sistem dengan cara mendengar
keluhan dari pelanggan . Untuk membuat suatu sistem yang sesuai kebutuhan , maka harus
diketahui terlebih dahulu bagaimana sistem yang sedang berjalan untuk kemudian
mengetahui masalah yang terjadi .
2 . Merancang dan Membuat Prototype

22.
 Pada tahapan ini , dilakukan perancangan dan pembuatan prototype system . Prototype
yang dibuat disesuaikan dengan kebutuhan sistem yang telah didefinisikan sebelumnya
dari keluhan pelanggan atau pengguna.
3 . Uji Coba
Pada tahap ini , Prototype dari sistem di uji coba oleh pelanggan atau pengguna . Lalu
dilakukan evaluasi kekurangan - kekurangan dari kebutuhan pelanggan . Pengembangan
kemudian kembali mendengarkan keluhan dari pelanggan untuk memperbaiki Prototype
yang ada.

Kelebihan Metode Prototype

Kelebihan dari metode prototyping ini adalah :

1. Adanya komunikasi yang baik antara pengembang dan pelanggan

2. Pengembangan dapat bekerja baik dalam menentukan kebutuhan pelanggan
3. Lebih menghemat waktu dalam pengembangan sistem
4. Penerapan lebih mudah karena pemakai mengetahui apa yang diharapkannya

Kekurangan Metode Prototype

Sedangkan kekurangan dari metode prototyping ini adalah :

1. Resiko tinggi yaitu untuk masalah - masalah yang tidak terstruktur dengan baik , ada
perubahan yang besar dari waktu ke waktu dan adanya persyaratan data yang tidak
menentu
2. Interaksi pemakai penting . Sistem harus menyediakan dialog on-line antara
pelanggan dan komputer
3. Hubungan pelanggan dengan komputer yang disediakan mungkin tidak
mencerminkan teknik perancangan yang baik.

8. EXTREME PROGRAMMING (XP)

Extreme Programming (XP)merupakan salah satu metode pengembangan software

yang termasuk dalam Agile Software Development. XP menggunakan pendekatan object-
oriented.

Dalam XP, terdapat 5 nilai yang menjadi pondasi yaitu communication, simplicity,

feedback, courage, dan respect. Komunikasi yang efektif antara pengembang perangkat
lunak dan pihak-pihak yang terlibat sangatlah penting. Dalam XP, desain dijadikan
kebutuhan intermediate. Desain dibuat sesederhana mungkin agar mudah
mengimplementasikan code.

23.
Proses Extreme Programming menurut Pressman (2010):

1. Planning. Tahap planning dimulai dengan membuat user stories

yang menggambarkan output, fitur, dan fungsi-fungsi dari software yang akan dibuat.
User stories tersebut kemudian diberikan bobot seperti prioritas dan dikelompokkan
untuk selanjutnya dilakukan proses delivery secara incremental. 

2. Design. Design di Extreme Programming mengikuti prinsip Keep It Simple (KIS).

Untuk design yang sulit, Extreme Programming akan menggunaan Spike Solution dimana
pembuatan design dibuat langsung ke tujuannya. Extreme Programming juga
mendukung adanya refactoring dimana software system diubah sedemikian rupa dengan
cara mengubah stuktur kode dan menyederhanakannya namun hasil dari kode tidak
berubah. 

3. Coding. Proses coding pada XP diawali dengan membangun serangkaian unit test.

Setelah itu pengembang akan berfokus untuk mengimplementasikannya. Dalam Extreme
Programming diperkenalkan istilah Pair Programming dimana proses penulisan program
dilakukan secara berpasangan. Dua orang programmer saling bekerjasama di satu
komputer untuk menulis program. Dengan melakukan ini akan didapat real-time problem
solving dan real-time quality assurance. 

4. Testing. Tahap ini dilakukan pengujian kode pada unit test.

Dalam Extreme Programming, diperkenalkan XP acceptance test atau biasa
disebut customer test. Tes ini dilakukan oleh customer yang berfokus kepada fitur dan
fungsi sistem secara keseluruhan. Acceptance test ini berasal dari user stories yang telah
diimplementasikan.

5.

XP fokus pada:

 Implementasi desain sederhana

 Komunikasi antara pengembang dan pelanggan
 Secara terus menerus menguji basis kode
 Refaktorisasi untuk mengakomodasi perubahan spesifikasi
 Mencari timbal balik pelanggan
Praktik Komentar

24.
1. Perencanaan dan kebutuhan Personil pemasaran dan pengembangan
bisnis bekerja bersama untuk
mengidentifikasi nilai bisnis yang
maksimal  dari setiap fitur perangkat lunak.
Setiap fitur utama perangkat lunak ditulis
sebagai cerita pengguna.
Pemrogram menyediakan estimasi waktu
untuk penyelesaian setiap cerita pengguna.
Pengguna memilih fitur perangkat lunak
berdasarkan estimasi waktu dan nilai
bisnis.

2. Perilisan penambahan kecil Berusaha untuk menambahkan fitur kecil

yang nyata dan memberi nilai lebih serta
merilis basis kode sesering mungkin.

3. Metafora system Tim pemrograman Anda mengidentifikasi

suatu metafora pengaturan untuk
membantu konvensi penamaan dan alur
program.

4. Desain sederhana Implementasi desain yang paling sederhana

yang memungkinkan kode Anda untuk
lolos pengujian unit. Asumsikan akan ada
perubahan, sehingga jangan membuang
banyak waktu untuk mendesain, langsung
implementasikan.

5. Pengujian berkelanjutan Tulis pengujian unit sebelum menulis

modul kode. Setiap unit belum lengkap
sampai bisa lolos pengujian unit. Lebih
jauh, program belum lengkap sampai telah
melewati semua pengujian unit dan
pengujian penerimaan.

6. Refaktorisasi Membersihkan dan menyederhanakan basis

kode Anda. Pengujian unit membantu
memastikan bahwa Anda tidak
menghancurkan fungsionalitas dalam
prosesnya. Anda harus mengulang semua
pengujian unit setelah ada refaktorisasi.

7. Pemrograman sepasang Anda dan pemrogram lain bekerja bersama,

dengan mesin yang sama, untuk membuat
basis kode. Hal ini memungkinkan ulasan
kode secara langsung, yang mana secara
dramatis memfasilitasi deteksi gangguan

25.
 dan resolusi.

8. Kepemilikan kolektif atas kode Semua kode adalah hak milik semua
pemrogram.
Tidak ada satu pun pemrogram yang
didedikasikan untuk basis kode spesifik.

9. Integrasi berkelanjutan Setiap hari, integrasikan semua perubahan,

setelah kode melewati pengujian unit,
kembalikan ke dalam basis kode.

10. Kerja 40 jam per minggu
Tidak diizinkan adanya lembur, jika Anda
bekerja dengan dedikasi selama 40 jam per
minggu, jam lembur tidak dibutuhkan.
Pengecualian hanya untuk minggu sebelum
perilisan.

11. Kehadiran pelanggan di tempat
Anda dan tim pemrograman memiliki akses
tidak terbatas ke pelanggan, untuk
memungkinkan Anda untuk menyelesaikan
pertanyaan secara cepat dan meyakinkan,
yang mana menjaga penguluran proses
pengembangan.

12. Standar Pemrograman Semua kode seharusnya terlihat sama.

Pengembangan sebuah metafora system
membantu mencapai prinsip ini.

9. RAPID APLPLICATION DEVELOPMENT (RAD) MODEL

Rapid Application Development (RAD) adalah strategi siklus hidup yang ditujukan
untuk menyediakan pengembangan yang jauh lebih cepat dan mendapatkan hasil dengan
kualitas yang lebih baik dibandingkan dengan hasil yang dicapai melalui siklus tradisional
(McLeod, 2002). RAD merupakan gabungan dari bermacam-macam teknik terstruktur
dengan teknik prototyping dan teknik pengembangan joint application untuk mempercepat
pengembangan sistem/aplikasi (Bentley, 2004). Dari definisi-definisi konsep RAD ini, dapat
dilihat bahwa pengembangan aplikasi dengan menggunakan metode RAD ini dapat dilakukan
dalam waktu yang relatif lebih cepat.

Pemaparan konsep yang lebih spesifik lagi dijelaskan oleh Pressman (2005) dalam
bukunya, “Software Engineering: A Practition’s Approach”. Ia mengatakan bahwa RAD
adalah proses model perangkat lunak inkremental yang menekankan siklus pengembangan
yang singkat. Model RAD adalah sebuah adaptasi “kecepatan tinggi” dari model waterfall, di
mana perkembangan pesat dicapai dengan menggunakan pendekatan konstruksi berbasis

26.
komponen. Jika tiap-tiap kebutuhan dan batasan ruang lingkup projek telah diketahui dengan
baik, proses RAD memungkinkan tim pengembang untuk menciptakan sebuah “sistem yang
berfungsi penuh” dalam jangka waktu yang sangat singkat. Dari penjelasan Pressman (2012)
ini, satu perhatian khusus mengenai metodologi RAD dapat diketahui, yakni implementasi
metode RAD akan berjalan maksimal jika pengembang aplikasi telah merumuskan kebutuhan
dan ruang lingkup pengembangan aplikasi dengan baik.

Sedangkan menurut Kendall (2010), RAD adalah suatu pendekatan berorientasi objek
terhadap pengembangan sistem yang mencakup suatu metode pengembangan serta
perangkat-perangkat lunak. RAD bertujuan mempersingkat waktu yang biasanya diperlukan
dalam siklus hidup pengembangan sistem tradisional antara perancangan dan penerapan suatu
sistem informasi. Pada akhirnya, RAD sama-sama berusaha memenuhi syarat-syarat bisnis
yang berubah secara cepat.

Menurut Kendall (2010), terdapat tiga fase dalam RAD yang melibatkan penganalisis
dan pengguna dalam tahap penilaian, perancangan, dan penerapan. Adapun ketiga fase
tersebut adalah requirements planning (perencanaan syarat-syarat), RAD design workshop
(workshop desain RAD), dan implementation (implementasi). Sesuai dengan metodologi
RAD menurut Kendall (2010), berikut ini adalah tahap-tahap pengembangan aplikasi dari
tiap-tiap fase pengembangan aplikasi.

1)      Requirements Planning (Perencanaan Syarat-Syarat)

Dalam fase ini, pengguna dan penganalisis bertemu untuk mengidentifikasikan tujuan-
tujuan aplikasi atau sistem serta untuk megidentifikasikan syarat-syarat informasi yang
ditimbulkan dari tujuan-tujuan tersebut. Orientasi dalam fase ini adalah menyelesaikan
masalah-masalah perusahaan. Meskipun teknologi informasi dan sistem bisa mengarahkan
sebagian dari sistem yang diajukan, fokusnya akan selalu tetap pada upaya pencapaian
tujuan-tujuan perusahaan (Kendall, 2010).

27.
2)      RAD Design Workshop (Workshop Desain RAD)

Fase ini adalah fase untuk merancang dan memperbaiki yang bisa digambarkan sebagai
workshop. Penganalisis dan dan pemrogram dapat bekerja membangun dan menunjukkan
representasi visual desain dan pola kerja kepada pengguna. Workshop desain ini dapat
dilakukan selama beberapa hari tergantung dari ukuran aplikasi yang akan dikembangkan.
Selama workshop desain RAD, pengguna merespon prototipe yang ada dan penganalisis
memperbaiki modul-modul yang dirancang berdasarkan respon pengguna. Apabila sorang
pengembangnya merupakan pengembang atau pengguna yang berpengalaman, Kendall
menilai bahwa usaha kreatif ini dapat mendorong pengembangan sampai pada tingkat
terakselerasi (Kendall, 2010).

3)      Implementation (Implementasi)

Pada fase implementasi ini, penganalisis bekerja dengan para pengguna secara intens
selama workshop dan merancang aspek-aspek bisnis dan nonteknis perusahaan. Segera
setelah aspek-aspek ini disetujui dan sistem-sistem dibangun dan disaring, sistem-sistem baru
atau bagian dari sistem diujicoba dan kemudian diperkenalkan kepada organisasi (Kendall,
2010).

Kelebihan dan Kekurangan RAD

Metode pengembangan sistem RAD relatif lebih sesuai dengan rencana pengembangan
aplikasi yang tidak memiliki ruang lingkup yang besar dan akan dikembangkan oleh tim yang
kecil. Namun, RAD pun memiliki kelebihan dan kekurangannya sebagai sebuah metodoligi
pengembangan aplikasi. Berikut ini adalah kelebihan metodologi RAD menurut Marakas
(2006):

1. Penghematan waktu dalam keseluruhan fase projek dapat dicapai.

2. RAD mengurangi seluruh kebutuhan yang berkaitan dengan biaya projek dan
sumberdaya manusia.
3. RAD sangat membantu pengembangan aplikasi yang berfokus pada waktu
penyelesaian projek.
4. Perubahan desain sistem dapat lebih berpengaruh dengan cepat dibandingkan dengan
pendekatan SDLC tradisional.
5. Sudut pandang user disajikan dalam sistem akhir baik melalui fungsi-fungsi sistem
atau antarmuka pengguna.
6. RAD menciptakan rasa kepemilikan yang kuat di antara seluruh pemangku kebijakan
projek.

Sedangkan, mengacu pada pendapat Kendall (2010), maka dapat diketahui bahwa
kekurangan penerapan metode RAD adalah sebagai berikut:

1. Dengan metode RAD, penganalisis berusaha mepercepat projek dengan terburu-buru.

2. Kelemahan yang berkaitan dengan waktu dan perhatian terhadap detail. Aplikasi
dapat diselesaikan secara lebih cepat, tetapi tidak mampu mengarahkan penekanan
terhadap permasalahan-permasalahan perusahaan yang seharusnya diarahkan.

28.
 3. RAD menyulitkan programmer yang tidak berpengalaman menggunakan prangkat ini
di mana programmer dan analyst dituntut untuk menguasai kemampuan-kemampuan
baru sementara pada saat yang sama mereka harus bekerja mengembangkan sistem.

Daftar Pustaka :
MODEL EVOLUTIONARY DEVELOPMENT
- https://murtri.wordpress.com/2014/08/25/model-model-pengembangan-perangkat-lunak-
beserta-contoh-penerapannya/
- https://www.angon.co.id/news/uncategorized/model-model-pengembangan-perangkat-
lunak-beserta-contoh-penerapannya

WATERFALL DEVELOPMENT MODEL.

- https://www.slideshare.net/27071993/model-waterfall.
- https://id.wikipedia.org/wiki/Model_waterfall

PENGEMBANGAN SISTEM SPIRAL MODEL

- https://www.dictio.id/t/apa-yang-dimaksud-dengan-model-spiral-dalam-pengembangan-
perangkat-lunak/15028/2

- https://www.google.co.id/searchq=pengertian+cost+overrun&sa=X&ved=0ahUKEwi9p
PCihpncAhXJe30KHUAqApUQ1QIIfigA&biw=679&bih=524

INCREMENTAL DEVELOPMENT MODEL

- http://iniono80.blogspot.com/2018/03/macam-macam-model-sdlc.html
- https://www.academia.edu/34453557/Model_Waterfall

SCRUM DEVELOPMENT MODEL

- https://salamadian.com/metode-pengembangan-perangkat-lunak/

KENBAN DEVELOPMENT MODEL

- http://oursolving.blogspot.com/2011/09/10_420.html
- https://sis.binus.ac.id/2018/03/09/knowing-agile-development-methodologies-kanban/

METODE PROTOTYPE

29.
 - https://materikuliahif-unpas.blogspot.com/2018/07/metode-prototype.html

EXTREME PROGRAMMING (XP)

- http://www.kumpulanpengertian.com/2016/01/pengertian-dan-proses-extreme.html
Glenford, J. M., Sandler, C., & Badgett, T. (2012). The Art of Software Testing. New
Jersey: John Wiley & Sons, Inc.
- https://sis.binus.ac.id/2018/04/02/dasar-dasar-extreme-programming-xp/

RAPID APPLICATION DEVELOPMENT (RAD) MODEL

- Mc.,Leod, R. Jr. 2002. System Development: A Project Management Approach. New
York: Leigh Publishing LLC.
- Whitten, J.L. & Bentley, L.D. 2004. System Analysis & Design Methods: Sixth Edition.
New York: Mc.Graw-Hill.
- Pressman, R.S. 2012. Rekayasa Perangkat Lunak: Pendekatan Praktisi. Yogyakarta:
Penerbit Andi.
- Marakas, G.M. 2006. System Analysis Design: an Active Approach. New York:
Mc.Graw-Hill.
- Kendall, J.E. & Kendall, K.E. 2010. Analisis dan Perancangan Sistem. Jakarta: Indeks

30.