Model Waterfall

Pertama akan dibahas adalah model waterfall. Model ini merupakan model yang paling banyak dipakai oleh para pengembang software. Ada lima tahap dalam model waterfall, yaitu: Requirement Analysis, System Design, Implementation, Integration & Testing, Operations & Maintenance. Sesuai dengan namanya waterfall (air terjun) maka tahapan dalam model ini disusun bertingkat, setiap tahap dalam model ini dilakukan berurutan, satu sebelum yang lainnya (lihat tanda anak panah). Selain itu dari satu tahap kita dapat kembali ke tahap sebelumnya.

Berikut ini penjelasan tentang masing-masing tahap dalam model waterfall:

1. Requirement Analysis
Seluruh kebutuhan software harus bisa didapatkan dalam fase ini, termasuk didalamnya kegunaan software yang diharapkan pengguna dan batasan software. Informasi ini biasanya dapat diperoleh melalui wawancara, survey atau diskusi. Informasi tersebut dianalisis untuk mendapatkan dokumentasi kebutuhan pengguna untuk digunakan pada tahap selanjutnya.

2. System Design

Tahap ini dilakukan sebelum melakukan coding. Tahap ini bertujuan untuk memberikan gambaran apa yang seharusnya dikerjakan dan bagaimana tampilannya. Tahap ini membantu dalam menspesifikasikan kebutuhan hardware dan sistem serta mendefinisikan arsitektur sistem secara keseluruhan.

3. Implementation

Dalam tahap ini dilakukan pemrograman. Pembuatan software dipecah menjadi modul-modul kecil yang nantinya akan digabungkan dalam tahap berikutnya. Selain itu dalam tahap ini juga dilakukan pemeriksaaan terhadap modul yang dibuat, apakah sudah memenuhi fungsi yang diinginkan atau belum.

4. Integration & Testing

Di tahap ini dilakukan penggabungan modul-modul yang sudah dibuat dan dilakukan pengujian ini dilakukan untuk mengetahui apakah software yang dibuat telah sesuai dengan desainnya dan masih terdapat kesalahan atau tidak.

5. Operation & Maintenance

Ini merupakan tahap terakhir dalam model waterfall. Software yang sudah jadi dijalankan serta dilakukan pemeliharaan. Pemeliharaan termasuk dalam memperbaiki kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru.

V-Model

Dalam Model Pengembangan Perangkat Lunak Siklus Hidup V, berdasarkan informasi yang sama (persyaratanspesifikasi dokumen) kegiatan pembangunan & pengujian dimulai. Berdasarkan dokumen persyaratan timpengembang mulai bekerja pada desain & setelah selesai pada desain mulai implementasi aktual dan tim pengujianmulai bekerja pada perencanaan pengujian, menulis uji kasus, script pengujian. Kedua kegiatan bekerja sejajar satu sama lain. Dalam model Waterfall & V-model mereka cukup mirip satu sama lain. Karena itu adalah Uji Perangkat Lunak paling populer Hidup Model Siklus sehingga sebagian besar organisasi mengikuti model ini.

V-model juga disebut sebagai Verifikasi dan model Validasi. Kegiatan pengujian tampil dalam setiap fase dari faseSiklus Hidup Uji Perangkat Lunak. Di paruh pertama model kegiatan validasi pengujian terintegrasi dalam setiap fase seperti kebutuhan pengguna review, dokumen Sistem Desain & di babak berikutnya kegiatan pengujian Verifikasidatang dalam gambar.

Khas V-Model menunjukkan kegiatan Pengembangan Perangkat Lunak di sisi kiri dari model dan sisi kanan dari FasePengujian model yang sebenarnya dapat dilakukan.

Dalam proses ini "Do-Prosedur" akan diikuti oleh tim pengembang dan "Check-Prosedur" akan diikuti oleh timpengujian untuk memenuhi persyaratan yang disebutkan.

Dalam siklus V-Model hidup pengembangan perangkat lunak langkah yang berbeda yang diikuti Namun di sini kitaakan mengambil jenis yang paling umum dari V-model contoh. V-model biasanya terdiri dari beberapa tahap sebagai berikut:

1. Unit Pengujian: Persiapan Kasus Uji Satuan

2. Integrasi Pengujian: Persiapan Uji Kasus Integrasi

3. Sistem Pengujian: Persiapan kasus uji Sistem

4. Penerimaan Pengujian: Persiapan Uji Kasus Penerimaan

Berikut gambar V-Model :

Star Life Cycle

Dalam Siklus permodelan ini pengujian dilakukan terus menerus, tidak harus dikahir. Misalnya dimulai dari menentukan kosep desain (conceptual design) dalam proses ini akan langsung terjadi evaluasi untuk langsung ternilai apakah sudah sesuai dengan kebutuhan user, bila belum maka akan terus berulang di evaluasi hingga benar-benar pas, selanjutnya apabila sudah pas, maka dari tahap evaluasi yang pertama akan lanjut ke proses yg selanjutnya yakni requirements/specification yakni memverifikasikan persyaratan rancangan tersebut, dan pada tahap itu juga langsung terjadi pengevaluasian seperti tahap pertama, dan selanjutnya akan tetap sama terjadi pada tahapan-tahapan selanjutnya yakni task analysis/fungsion analysis, pengimplementasian, prototyping hingga pada akhirnya terciptalah sebuah aplikasi yang sesuai dengan kebutuhan user.

Intinya pada rancangan model ini pengevaluasian dilakukan disetiap tahapan tidak hanya pada tahapan akhir  seperti model-model rancangan yang lainnya. Dapat dilihat dari gambar dibawah ini bagaimana bentuk model Star Life Cycle.

Model Rapid Application Development (RAD)

Rapid Application Development (RAD) adalah sebuah model proses perkembangan software sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier di mana perkembangan cepat dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase – fase sebagai berikut : bussiness modeling, data modeling, process modeling, application generation dan testing and turnover.

Model Pengembangan Sistem Informasi Berbasis Web

1. Berikut adalah beberapa model pengembangan informasi berbasis web, yaitu :

Metode RAD (Rapid Application Development)

• Merupakan metode pengembangan sistem secara linear sequential yang menekankan pada siklus pengembangan yang sangat singkat. 

• Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60-90 hari). 

• Pemakai sistem dapat mendefinisikan kebutuhan perangkat lunak dengan baik. 

• Pemakai sistem bersedia meluangkan waktu yang cukup untuk berkomunikasi intensif dengan pengembang sehubungan dengan pengembangan perangkat lunak 

Rapid Application Development adalah seperangkat strategi yang terintegrasi yang ada dalam suatu kerangka kerja meneyeluruh yang disebut Information Engineering (IE).

ALASAN MEMILIH METODE RAD

Di dalam memilih metode RAD harus memperhatikan alasan-alasan berikut ini:

1. Alasan yang Buruk

-Apabila menggunakan RAD hanya untuk menghemat biaya pengembangan suatu sistem. Hal ini disebabkan karena dengan menggunakan metode RAD membutuhkan suatu tim yang mengerti betul

mengenai manajemen biaya. Sebab bila tidak, maka biaya yang dikeluarkan akan menjadi lebih besar.

-Apabila menggunakan RAD hanya untuk menghemat waktu pengembangan suatu sistem. Hal ini disebabkan karena dengan menggunakan metode RAD membutuhkan suatu tim yang mengerti betul mengenai manajemen waktu. Sebab bila tidak maka waktu yang dibutuhkan akan menjadi lebih lama.

2. Alasan yang Baik

-Apabila menggunakan RAD untuk mendapatkan suatu desain yang dapat diterima oleh konsumen dan dapat dikembangkan dengan mudah.

-Apabila menggunakan RAD untuk memberikan batasan-batasan pada suatu system supaya tidak mengalami perubahan.

-Apabila menggunakan RAD untuk menghemat waktu, dan kalau memungkinkan bisa menghemat biaya serta menghasilkan produk yang berkualitas.

1. Keuntungan RAD

Beberapa keuntungan dalam menggunakan metode RAD adalah sebagai berikut:

- Membeli sistem yang baru memungkinkan untuk lebih menghemat biaya ketimbang mengembangkan sendiri.

- Proses pengiriman menjadi lebih mudah, hal ini dikarenakan proses pembuatan lebih banyak menggunakan potongan-potongan script.

- Mudah untuk diamati karena menggunakan model prototype, sehingga user lebih mengerti akan sistem yang dikembangkan.

- Lebih fleksibel karena pengembang dapat melakukan proses desain ulang pada saat yang bersamaan.

- Bisa mengurangi penulisan kode yang kompleks karena menggunakan wizard.

- Keterlibatan user semakin meningkat karena merupakan bagian dari tim secara keseluruhan.

- Mampu meminimalkan kesalahan-kesalahan dengan menggunakan alat-alat bantuan (CASE tools).

- Mempercepat waktu pengembangan sistem secara keseluruhan karena cenderung mengabaikan kualitas.

- Tampilan yang lebih standar dan nyaman dengan bantuan software-software pendukung.

2. Kerugian RAD

Beberapa kerugian dalam menggunakan metode RAD adalah sebagai berikut :

- Dengan melakukan pembelian belum tentu bisa menghemat biaya dibanding-

kan dengan mengembangkan sendiri.

- Membutuhkan biaya tersendiri untuk membeli peralatan-peralatan penunjang seperti misalnya software dan hardware.

- Kesulitan melakukan pengukuran mengenai kemajuan proses.

- Kurang efisien karena apabila melakukan pengkodean dengan menggunakan tangan bisa lebih efisien.

- Ketelitian menjadi berkurang karena tidak menggunakan metode yang formal

dalam melakukan pengkodean.

- Lebih banyak terjadi kesalahan apabila hanya mengutamakan kecepatan diban-

dingkan dengan biaya dan kualitas.

- Fasilitas-fasilitas banyak yang dikurangi karena terbatasnya waktu yang tersedia.

- Sistem sulit diaplikasikan di tempat yang lain.

- Fasilitas yang tidak perlu terkadang harus disertakan, karena menggunakan komponen yang sudah jadi, sehingga hal ini membuat biaya semakin meningkat.

Ini merupakan gambar dari Model RAD