Waterfall

Waterfall model? apa sih yang kita ketahui tentang waterfall? air terjun? *benar memang air terjun :D ... lalu apa hubungannya dengan pemodelan sistem? *jelas ada hubungannya karena ya memang bentuknya seperti air terjun yang dari tahap atas sampai tahap paling bawah (minimalisasi) dari segi kebutuhan yang sudah terpenuhi artinya kebutuhan yang tadinya maksimal menjadi minimal karena proses model waterfall ini ... waterfall model ini bisa juga disebut "linear sequence model" atau "classic life cycle", model ini sistem ini pertama kali di kenal pada tahun 1970an *sudah kuno sekali ya? memang kuno ... namun jangan salah software proses model ini merupakan model yang sering digunakan (populer) ....

Ciri khas model waterfall ini yaitu dalam tahap rekayasa perangkat lunak nya harus berurutan dari satu tahap ke tahap selanjutnya jadi tidak bisa melompati dari tahap satu ke 2 tahap setelah nya ataupun sebelumnya, lalu memakan banyak biaya dan waktu bila suatu sistem yang di kembangkan selalu melakukan perubahan dalam sistemnya, maka dari itu model software proses ini biasa di gunakan oleh development skala besar dan memakan waktu yang lama dalam proses pengerjaan lalu jarang melakukan perubahan sistem maupun peningkatan versi ...

Waterfall Model Refersnsi Sommerville

Pengertian Waterfall

Waterfall atau AIR terjun adalah model yang dikembangkan untuk pengembangan perangkat lunak, membuat perangkat lunak. model berkembang secara sistematis dari satu tahap ke tahap lain dalam mode seperti air terjun.
Model ini mengusulkan sebuah pendekatan kepada pengembangan software yang sistematikdan sekuensial yang mulai dari tingkat kemajuan sistem pada seluruh analisis, desain, kode, pengujian dan pemeliharaan. Model ini melingkupi aktivitas-aktivitas sebgai berikut : rekayasa dan pemodelan sistem informasi, analisis kebutuhan, desain, koding, mengujian dan pemeliharaan.
Model pengembangan ini bersifat linear dari tahap awal pengembangan system yaitu tahap perencanaan sampai tahap akhir pengembangan system yaitu tahap pemeliharaan. Tahapan berikutnya tidak akan dilaksanakan sebelum tahapan sebelumnya selesai dilaksanakan dan tidak bisa kembali atau mengulang ke tahap sebelumnya.

Tahapan atau fase model waterfall

Ini adalah gambar tahapan atau fase yang paling umum tentang model waterfall
Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya. Berikut adalah Gambar dan penjelasan dari tahap-tahap yang dilakukan di dalam model ini menurut Pressman:
1)   System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.
2)   Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.
3)   Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.
4)   Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.
5)   Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.
6)   Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.

Karakteristik

Dalam model ini terdapat beberapa sifat-sifat yang menojol dan cenderung menjadi permasalahan pada model waterfall.
1) Ketika problem muncul, maka proses berhenti karena tidak dapat menuju ke tahapan selanjutnya. Apabila terdapat kemungkinan problem tersebut muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi tahapan sebelumnya agarproblem ini tidak muncul.
2) Karena pendekatannya secara sequential, maka setiap tahap harus menunggu hasil dari tahap sebelumnya. Hal itu tentu membuang waktu yang cukup lama, artinya bagian lain tidak dapat mengerjakan hal lain selain hanya menunggu hasil dari tahap sebelumnya.

Mengapa model ini sangat populer?

Selain karena pengaplikasian menggunakan model ini mudah, kelebihan dari model ini adalah ketika semua kebutuhan sistem dapat didefinisikan secara utuh, eksplisit, dan benar di awal project, maka SE dapat berjalan dengan baik dan tanpa masalah. Meskipun seringkali kebutuhan sistem tidak dapat didefinisikan seeksplisit yang diinginkan, tetapi paling tidak, problem pada kebutuhan sistem di awal project lebih ekonomis dalam hal uang (lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan problem yang muncul pada tahap-tahap selanjutnya.
Meskipun demikian, karena model ini melakukan pendekatan secara urut / sequential, maka ketika suatu tahap terhambat, tahap selanjutnya tidak dapat dikerjakan dengan baik dan itu menjadi salah satu kekurangan dari model ini.

Kapan model waterfall di gunakan?????

Salah satu model tradisional dan mudah yang tahapannya mengalir satu arah seperti air terjun adalah Waterfall Model atau Linear Sequential Model. Pertanyaannya, kapan sebaiknya model tersebut digunakan?
Teori-teori lama menyimpulkan ada beberapa hal, yaitu:
1)      Ketika semua persyaratan sudah dipahami dengan baik di awal pengembangan.
2)      Definisi produk stabil dan tidak ada perubahan saat pengembangan untuk alasan apapun seperti perubahan eksternal, perubahan tujuan, perubahan anggaran atau perubahan teknologi. Untuk itu, teknologi yang digunakan pun harus sudah dipahami dengan baik.
3)      Menghasilkan produk baru, atau versi baru dari produk yang sudah ada. Sebenarnya, jika menghasilkan versi baru maka sudah masuk incremental development, yang setiap tahapnya sama dengan Waterfall kemudian diulang-ulang.
4)      Porting produk yang sudah ada ke dalam platform baru.
Dengan demikian, Waterfall dianggap pendekatan yang lebih cocok digunakan untuk proyek pembuatan sistem baru. Tetapi salah satu kelemahan paling dasar adalah menyamakan pengembangan perangkat keras dengan perangkat lunak dengan meniadakan perubahan saat pengembangan. Padahal, galat diketahui saat perangkat lunak dijalankan, dan perubahan-perubahan akan sering terjadi.

Tahap Pengembangan Waterfal

Tahap – tahap pengembangan waterfall model adalah :
1)      Analisis dan definisi persyaratan Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user.
2)      Perancangan sistem dan perangkat lunak Kegiatan ini menentukan arsitektur sistem secara keseluruhan.
3)      Implementasi dan pengujian unit Perancangan perangkat lunak direalisasikan sebagai serangkaian program.
4)      Integrasi dan pengujian sistem Unit program diintegrasikan atau diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sitem telah terpenuhi
5)      Operasi dan pemeliharaan Merupakan fase siklus yang paling lama. Sistem diinstall dan dipakai. Perbaikan mencakup koreksi dari berbagai error, perbaikan dan implementasi unit sistem dan pelayanan sistem.

Keuntungan Waterfall

Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.
Document pengembangan system sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. Jadi setiap fase atau tahapan akan mempunyai dokumen tertentu.
Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno, daripada menggunakan pendekatan asal-asalan. Selain itu, metode ini juga masih masuk akal jika kebutuhan sudah diketahui dengan baik.

Kelemahan Waterfall

Diperlukan majemen yang baik, karena proses pengembangan tidak dapat dilakukan secara berulang sebelum terjadinya suatu produk.
Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal pengembangan yang berakibat pada tahapan selanjutnya.
Pelanggan sulit menyatakan kebutuhan secara eksplisit sehingga tidak dapat mengakomodasi ketidak pastian pada saat awal pengembangan.
Pelanggan harus sabar, karena pembuatan perangkat lunak akan dimulai ketika tahap desain sudah selesai. Sedangkan pada tahap sebelum desain bisa memakan waktu yang lama.
Pada kenyataannya, jarang mengikuti urutan sekuensial seperti pada teori. Iterasi sering terjadi menyebabkan masalah baru.

Prototyping

Model Prototyping

Sebuah prototipe adalah bagian dari produk yang mengekspresikan logika maupun fisik antarmuka eksternal yang ditampilkan. Konsumen potensial menggunakan prototipe dan menyediakan masukan untuk tim pengembang sebelum pengembangan skal besar dimulai. Melihat dan mempercayai menjadi hal yang diharapkan untuk dicapai dalam prototipe. Dengan menggunakan pendekatan ini, konsumen dan tim pengembang dapat mengklarifikasi kebutuhan dan interpretasi mereka.

Prototyping perangkat lunak (software prototyping) atau siklus hidup menggunakan protoyping (life cycle using prototyping) adalah salah satu metode siklus hidup sistem yang didasarkan pada konsep model bekerja (working model). Tujuannya adalah mengembangkan model menjadi sistem final. Artinya sistem akan dikembangkan lebih cepat dari pada metode tradisional dan biayanya menjadi lebih rendah. Ada banyak cara untuk memprotoyping, begitu pula dengan penggunaannya. Ciri khas dari metodologi ini adalah pengembang sistem (system developer), klien, dan pengguna dapat melihat dan melakukan eksperimen dengan bagian dari sistem komputer dari sejak awal proses pengembangan.

Dengan prototype yang terbuka, model sebuah sistem (atau bagiannya) dikembangkan secara cepat dan dipoles dalam diskusi yang berkali-kali dengan klien. Model tersebut menunjukkan kepada klien apa yang akan dilakukan oleh sistem, namun tidak didukung oleh rancangan desain struktur yang mendetil. Pada saat perancang dan klien melakukan percobaan dengan berbagai ide pada suatu model dan setuju dengan desain final, rancangan yang sesungguhnya dibuat tepat seperti model dengan kualitas yang lebih bagus.

Protoyping membantu dalam menemukan kebutuhan di tahap awal pengembangan,terutama jika klien tidak yakin dimana masalah berasal. Selain itu protoyping juga berguna sebagai alat untuk mendesain dan memperbaiki user interface – bagaimana sistem akan terlihat oleh orang-orang yang menggunakannya.

Salah satu hal terpenting mengenai metodologi ini, cepat atau lambat akan disingkirkan dan hanya digunakan untuk tujuan dokumentasi. Kelemahannya adalah metode ini tidak memiliki analisa dan rancangan yang mendalam yang merupakan hal penting bagi sistem yang sudah kokoh, terpercaya dan bisa dikelola. Jika seorang pengembang memutuskan untuk membangun jenis prototipe ini, penting untuk memutuskan kapan dan bagaimana ia akan disingkirkan dan selanjutnya menjamin bahwa hal tersebut telah diselesaikan tepat pada waktunya.

Tahapan-Tahapan Prototyping

Tahapan-tahapan dalam Prototyping adalah sebagai berikut:

Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.

Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output).

Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. Jika sudah sesuai maka langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulang langkah 1, 2 , dan 3.

Mengkodekan sistem
Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.

Menguji sistem
Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain.

Evaluasi Sistem
Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan. Jika ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5.

Menggunakan sistem
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.

Tujuan Prototype
Prototyping model sendiri mempunyai tujuan yaitu mengembangkan model awal software menjadi sebuah sistem yang final.
A. Proses
Proses-proses dalam model prototyping menurut saya yaitu:

Komunikasi terlebih dahulu yang dilakukan antara pelanggan dengan tim pemgembang perangkat lunak mengenai spesifikasi kebutuhan yang diinginkan
Akan dilakukan perencanaan dan pemodelan secara cepat berupa rancangan cepat(quick design) dan kemudian akan memulai konstruksi pembuatan prototype
Prototipe kemudian akan diserahkan kepada para stakeholder untuk dilakukan evaluasi lebih lanjut sebelum diserahkan kepada para pembuat software
Pembuatan software sesuai dengan prototype yang telah dievaluasi yang kemudian akan diserahkan kepada pelanggan
Jika belum memenuhi kebutuhan dari pelanggan maka akan kembali ke proses awal sampai dengan kebutuhan dari pelanggan telah terpenuhi

Sedangkan proses-proses dalam model prototyping secara umum adalah sebagai berikut:
1. Pengumpulan kebutuhan
developer dan klien akan bertemu terlebih dahulu dan kemudian menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya
2. Perancangan
Perancangan dilakukan dengan cepat dan rancangan tersebut mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype
3. Evaluasi Prototype
Klien akan mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.
B. Tahapan
Selain itu, untuk memodelkan sebuah perangkat lunak dibutuhkan beberapa tahapan di dalam proses pengembangannya. Tahapan inilah yang akan menentukan keberhasilan dari sebuah softwareitu .Pengembang perangkat lunak harus memperhatikan tahapan dalam metode prototyping agar software finalnya dapat diterima oleh penggunanya. Dan tahapan-tahapan dalam prototyping tersebut adalah sebagai berikut :
1. Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format dan kebutuhan kesseluruhan perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.
2. Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang berpusat pada penyajian kepada pelanggan (misalnya dengan membuat input dan contoh outputnya).
3. Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai maka langkah keempat akan diambil. Jika tidak, maka prototyping diperbaiki dengan mengulang langkah 1, 2 , dan 3.
4. Mengkodekan system
Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.
5. Menguji system
Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain.
6. Evaluasi Sistem
Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Jika sudah, maka langkah ketujuh dilakukan, jika belum maka mengulangi langkah 4 dan 5.
7. Menggunakan system
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan
C. Keunggulan dan kelemahan metode prototype
Keunggulan prototyping :

Komunikasi akan terjalin baik antara pengembang dan pelanggan.
Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan setiap pelanggannya.
Pelanggan berperan aktif dalam proses pengembangan sistem.
Lebih menghemat waktu dalam pengembangan sistem.
Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya

Kelemahan prototyping :

Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangka waktu lama.
Pengembang biasanya ingin cepat menyelesaikan proyek sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan sebuah kerangka kerja(blueprint) dari sistem .
Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik dan benar.

Dalam setiap metode mempunyai kelebihan maupun kekurangan, namun kekurangan tersebut dapat diminimalisir yaitu dengan mengetahui kunci dari model prototype tersebut. Kunci agar model prototype ini berhasil dengan baik adalah dengan mendefinisikan aturan-aturan main pada saat awal, yaitu pelanggan dan pengembang harus setuju bahwa prototype dibangun untuk mendefinisikan kebutuhan.

SPIRAL

Berikut adalah gambar dari spiral model secara umum :

Definisi
[1] Model spiral, juga dikenal model Sebagai Siklus spiral, adalah Siklus hidup pengembangan sistem (SDLC) model yang Digunakan dalam teknologi informasi (TI). Pengembangan model ini menggabungkan fitur Model ini menggabungkan fitur pengembangan model prototyping model prototipe dan model air terjun. model dan terjun udara. Model spiral disukai untuk besar, mahal, dan rumit proyek. Disukai untuk model spiral besar, mahal, dan rumit proyek.

[2] Model spiral juga dikenal dengan model siklus hidup spiral, adalah siklus hidup pengembangan sistem (SDLC) yang digunakan di Teknologi informasi. Model ini adalah kombinasi antara model prototipe dan model waterfall.

[3] Model spiral adalah proses pengembangan perangkat lunak yang menggabungkan elemen-elemen dari kedua desain dan prototyping-in-tahap, dalam upaya untuk menggabungkan keuntungan dari top-down dan bottom-up konsep-konsep. Juga dikenal sebagai model siklus spiral (atau pengembangan spiral), itu adalah metode pengembangan sistem (SDM) yang digunakan dalam teknologi informasi (TI). Model pengembangan ini menggabungkan fitur dari prototyping model dan model air terjun. Model spiral dimaksudkan untuk besar, proyek mahal dan rumit.

Sejarah

Model spiral ditentukan oleh Barry Boehm tahun 1988 dalam artikel "A Spiral Model Pengembangan dan Peningkatan Perangkat Lunak" [1]. Model ini bukan model pertama untuk membahas perkembangan berulang-ulang, tapi itu adalah model pertama untuk menjelaskan mengapa hal iteration.

Sebagai awalnya direncanakan, para iterasi yang biasanya 6 bulan sampai 2 tahun lama. Setiap tahap desain dimulai dengan tujuan dan berakhir dengan klien (yang mungkin internal) meninjau kemajuan sejauh ini. Analisis dan upaya rekayasa yang diterapkan pada setiap fase proyek, dengan mata ke arah tujuan akhir proyek.

Kelebihan dan Kelemahan Model Spiral

a. Kelebihan model Spiral :
   1. Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak
       komputer.
   2. Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar
   3. Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap
       resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses .
   4. Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiap
       keadaan di dalam evolusi produk.
   5. Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan memasukkannya
       ke dalam kerangka kerja iteratif .
   6. Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi
       resiko sebelum menjadi permaslahan yang serius.

b. Kelemahan model Spiral :

1. Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa dikontrol.
   2. Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang
       serius jika resiko mayor tidak ditemukan dan diatur.
   3. Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolut

RAD Rapid application development

Pengertian Rapid application development (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan. Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final.

Fase dan Tahapan Pengembangan Aplikasi

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).

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 Model Sekuensial Linear / Waterfall Development Model :

Tahapan proses pengembangannya tetap (pasti), mudah diaplikasikan, dan prosesnya teratur.
Cocok digunakan untuk produk software/program yang sudah jelas kebutuhannya di awal, sehingga minim kesalahannya.
Software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik.
Documen pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.

Kekurangan Model Sekuensial Linear / Waterfall Development Model :

Proyek yang sebenarnya jarang mengikuti alur sekuensial seperti diusulkan, sehingga perubahan yang terjadi dapat menyebabkan hasil yang sudah didapatkan tim pengembang harus diubah kembali/iterasi sering menyebabkan masalah baru.
Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen harus dilakukan pada tahap awal proses.
Sulit untuk mengalami perubahan kebutuhan yang diinginkan oleh customer/pelanggan.
Pelanggan harus sabar untuk menanti produk selesai, karena dikerjakan tahap per tahap, dan proses pengerjaanya akan berlanjut ke setiap tahapan bila tahap sebelumnya sudah benar-benar selesai.
Perubahan ditengah-tengah pengerjaan produk akan membuat bingung tim pengembang yang sedang membuat produk.
Adanya waktu kosong (menganggur) bagi pengembang, karena harus menunggu anggota tim proyek lainnya menuntaskan pekerjaannya.

RUP (Rational Unified Process)

RUP, singkatan dari Rational Unified Process, adalah suatu kerangka kerja proses pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software, suatu divisi dari IBM sejak 2003. RUP bukanlah suatu proses tunggal dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh organisasi pengembang dan tim proyek perangkat lunak yang akan memilih elemen proses sesuai dengan kebutuhan mereka.

Sejarah

RUP merupakan produk proses perangkat lunak yang awalnya dikembangkan oleh Rational Software. Rational Software diakuisisi oleh IBM pada Februari 2003. Produk ini memuat basis-pengetahuan yang bertautan dengan artefak sederhana disertai deskripsi detail dari beragam aktivitas. RUP dimasukkan dalam produk IBM Rational Method Composer (RM C) yang memungkinkan untuk kustomisasi proses.

Dengan mengombinasikan pengalaman dari banyak perusahaan, dihasilkan enam praktik terbaik untuk rekayasa perangkat lunak modern:

1. Pengembangan iteratif, dengan risiko sebagai pemicu iterasi primer

2. Kelola persyaratan

3. Terapkan arsitektur yang berbasis komponen

4. Visualisasikan model perangkat lunak

5. Secara kontinyu, verifikasi kualitas

6. Kendalikan perubahan

Keuntungan yang didapat dengan menggunakan pendekatan iterasi diantaranya adalah : mengurangi resiko lebih awal, perubahan yang dilakukan lebih mudah diatur, higher level of reuse, project team memiliki waktu lama untuk memahami sistem yang akan dibangun, dan menghasilkan kualitas yang lebih baik di segala aspek.

RUP menawarkan berbagai kemudahan dalam membangun sebuah sotfware, ada yang disebut Six Best Practices yang terdiri dari :

Develop Iteratively

Manage Requirement

Use Component-based Architecture

Model Visually

Verify Quality

Control Changes to software

Extreme Programming (XP)

merupakan salah satu metodologi dalam rekayasa perangkat lunak dan juga merupakan satu dari beberapa agile software development methodologies yang berfokus pada coding sebagai aktivitas utama di semua tahap pada siklus pengembangan perangkat lunak (software development lifecycle). Metodologi ini mengedepankan proses pengembangan yang lebih responsive terhadap kebutuhan customer (”agile”) dibandingkan dengan metode-metode tradisional sambil membangun suatu software dengan kualitas yang lebih baik.

Extreme Programming muncul menawarkan sebuah disiplin baru dalam pengembangan software secara agile. Nilai dasar yang terkandung di dalam Extreme Programming adalah: Komunikasi (Communication), Kesederhanaan (Simplicity), Umpan balik (Feedback) Keberanian (Courage) dan menghormati (Respect).

Kata Kunci: Extreme Programming, agile, coding, komunikasi, kesederhanaan, umpan balik, keberanian, menghormati.

Latar Belakang XP

Requirement yang berubah dengan cepat menuntut lifecycles yang lebih pendek, dan tidak selaras dengan metoda pengembangan tradisional, yang pada umumnya memerlukan disain luas di awal dan mengakibatkan perubahan desain yang terjadi kemudian memerlukan biaya yang lebih tinggi atau kehilangan milestones.

Berdasarkan hal ini kemudian dilahirkan konsep XP yang digagas oleh Kent Beck dan Ward Cunningham pada Maret 1996. Metode XP merupakan yang terpopuler dari beberapa metodologi pengembangan software yang dipakai untuk mengimplementasikan proyek pengembangan perangkat lunak.

Tujuan XP

Tujuan utama XP adalah menurunkan biaya dari adanya perubahan software. Dalam metodologi pengembangan sistem tradisional, kebutuhan sistem ditentukan pada tahap awal pengembangan proyek dan bersifat fixed. Hal ini berarti biaya terhadap adanya perubahan kebutuhan yang terjadi pada tahap selanjutnya akan menjadi mahal. XP diarahkan untuk menurunkan biaya dari adanya perubahan dengan memperkenalkan nilai-nilai basis dasar, prinsip dan praktis. Dengan menerapkan XP, pengembangan suatu sistem haruslah lebih fleksibel terhadap perubahan.

Kunci Utama XP

Menurut penggagas dari metode XP, Kent Beck mendefinisikan empat kunci utama (inti) dari XP yaitu:

1. Communication (Komunikasi)

Tugas utama developer dalam membangun suatu sistem perangkat lunak adalah mengkomunikasikan kebutuhan sistem kepada pengembang perangkat lunak. Komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair programming). Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer. Tujuannya untuk memberikan pandangan pengembang sesuai dengan pandangan pengguna sistem.

2. Simplicity (Kesederhanaan)

XP mencoba untuk mencari solusi paling sederhana dan praktis. Perbedaan metode ini dengan metodologi pengembangan sistem konvensional lainnya terletak pada proses desain dan coding yang terfokus pada kebutuhan saat ini daripada kebutuhan besok, seminggu lagi atau sebulan lagi. Lebih baik melakukan hal yang sederhana dan mengembangkannya besok jika diperlukan.

3. Feedback (Masukan)

Hal ini diperlukan untuk mengetahui kemajuan dari proses dan kualitas dari aplikasi yang dibangun. Informasi ini harus dikumpulkan setiap interval waktu yang singkat secara konsisten. Ini dimaksudkan agar hal-hal yang menjadi masalah dalam proses pengembangan dapat diketahui sedini mungkin. Setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).

4. Courage (Keberanian)

Berani mencoba ide baru. Berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki. Contoh dari courage adalah komitmen untuk selalu melakukan design dan coding untuk saat ini dan bukan untuk esok. Ketika ada kode yang terlalu rumit, sulit dibaca dan dipahami, tidak sesuai dengan kemauan pelanggan, dll maka seharusnya kode program seperti itu di refactor (kalau perlu dibangun ulang). Hal ini menjadikan pengembang merasa nyaman dengan refactoring program ketika diperlukan.

5. Respect (Menghormati)

Pentingnya respect terhadap anggota team lainnya karena dengan siklus pendek dan integrasi continue, programmer tidak boleh melakukan perubahan yang dapat merusak kompilasi dan menyebabkan keberadaan unit uji gagal atau memperlambat kerja team. Respects tiap individu akan selalu menghasilkan kualitas tinggi.

Penerapan XP

Beberapa hal yang harus dipertimbangkan sebelum seseorang masuk dalam dunia XP adalah sebagai berikut:

1. User harus memahami konteks bisnis yang akan dikembangkan sistemnya, sehingga developer dapat menangkap sistem secara aplikatif dan dapat mengusulkan teknologi apa yang dapat dikembangkan dalam sistem barunya.

2. Akan lebih efektif apabila developer pernah menangani proyek pengembangan sistem yang sejenis sehingga dapat memberikan usulan model sistem baru, di samping alasan bahwa developer telah memiliki template aplikasi sistem tersebut untuk dijadikan prototype sistem baru. Hal ini akan berimplikasi kepada kemudahan dalam konstruksi sistem karena dikembangkan berdasarkan template yang sudah ada.

3. Extreme programming menuntut komunikasi antar developer dan user secara intensif dan komunikasi internal antar developer secara komprehensif, sehingga akan lebih representatif apabila tahap pengembangan sistem dilakukan di lokal yang mendukung proses komunikasi tersebut.

XP adalah suatu bentuk pembangunan perangkat lunak yang berbasis nilai kemudahan, komunikasi, umpan balik, dan keberanian. Bekerja dalam whole team bersama-sama dengan praktek yang mudah. Adapun inti penerapannya adalah:

Planning Game
Small, frequent releases
System metaphors
Simple design
Testing (unit testing & TDD)
Frequent refactoring
Pair programming
Collective code ownership
Continuous integration
Sustainable pace
Whole team together
Coding standards

Kesimpulan
Keuntungan XP:

Menjalin komunikasi yang baik dengan client.
Meningkatkan komunikasi dan sifat saling menghargai antar developer.

Kerugian XP:

Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.
Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga).

Sumber-Sumber yang terkait

Sumber http://www.materi-it.com/2014/06/analisis-7-software-model.html?id-ID

Sumber http://moel87cronaldo.blogspot.co.id/2009/03/tugas-rpl-3-model-extreme-programming.html

Sumber http://www.academia.edu/17873145/Model_Pengembangan