Konsep model waterfall, prototyping, RAD dan Spiral a.

Model Waterfall Model Waterfall merupakan model yang menggunakan milestone sebagai titik transisi dan pengujian, artinya setiap aktivitas pada tahap pengembangan harus diselesaikan sebelum menuju tahap pengembangan berikutnya. Sehingga model ini sangat sesuai untuk perangkat lunak dengan syarat-syarat yang telah didefinisikan secara lengkap sebelumnya karena besar kemungkinan tidak adanya perubahan aplikasi dimasa yang akan datang. Kondisi semacam ini akan sangat berpengaruh pada perangkat lunak dan menimbulkan masalah terhadap kebutuhan iterasi dimana aplikasi akan terus berkembang dengan penyesuaian-penyesuaian terhadap kebutuhan, proses bisnis dan lingkungan aplikasi yang terus berubah dari waktu kewaktu. b. Model Protyping Model Prototyping adalah salah satu pendekatan dalam rekayasa perangkat lunak yang secara langsung mendemonstrasikan bagaimana sebuah perangkat lunak atau komponen-komponen perangkat lunak akan bekerja dalam lingkungannya, sebelum tahapan konstruksi aktual dilakukan. c. Model RAD (Rapid Aplication Development), Model RAD merupakan 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. d. Model Spiral Spiral merupakan model kombinasi dari Prototyping model dengan Waterfall model. Setiap tahapan model ini selalu dilakukan Risk Analisys dan verifikasi atau testing. Dalam model ini, proses digambarkan sebagai spiral. Setiap loop mewakili satu fase dari software process. Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya. 2. Tahap-tahap pengembangan perangkat lunak menurut masing-masing model di atas yaitu: a. Waterfall Ada pun tahap-tahap pengembangan perangkat lunak menurut model waterfall yaitu: 1) Requirements analysis and definition : pada tahap ini tim pengembang mengumpulkan kebutuhan secara lengkap kemudian dianalisis dan mendefinisikan kebutuhan-kebutuhan proses bisnis yang harus dipenuhi oleh perangkat lunak (solusi bisnis) yang akan dibangun. 2) System and software design : pada tahap ini tim pengembang mendesain sistem dan aplikasi meliputi desain konseptual, logikal dan fisikal. 3) Implementation and unit testing : pada tahap ini desain yang telah di rancang diimplementasikan dengan menerjemahkan ke dalam kode-kode program menggunakan sebuah bahasa pemrograman, sekaligus melakukan pengujian terhadap unit-unit program yang telah dibuat. 4) Integration and system testing : tim pengembang menyatukan unit-unit program kemudian melakukan pengujian sistem perangkat lunak secara keseluruhan. 5) Operation and maintenance : tim pengembang melakukan pengoperasian program dan melakukan pemeliharaan terhadap perangkat lunak dengan penyesuaian atau perubahan terhadap situasi sebenarnya.

Model Proses Waterfall

b. Prototyping Tahap pengembangan perangkat lunak berdasarkan model prototyping adalah 1) Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan. 2) Perancangan : perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype. 3) Evaluasi prototype: klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.

c. RAD Berikut tahap pengembangan perangkat lunak berdasarkan model RAD 1) Business modelling Aliran informasi di antara fungsi fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan pertanyaan berikut : informasi apa yang mengendalikan proses bisnis? Informasi apa yang di munculkan? Siapa yang memunculkanya? Ke mana informasi

itu pergi? Siapa yang memprosesnya? 2) Data modeling Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modelling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik (disebut atribut) masingmasing objek diidentifikasi dan hubungan antara objek objek tersebut didefinisikan. 3) Prosess modelling Aliran informasi yang didefinisikan di dalam fase data modeling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data. 4) Aplication generation RAD mengasumsikan pemakaian teknik generasi ke empat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memkai lagi komponen program yang ada ( pada saat memungkinkan) atau menciptakan komponen yang bisa dipakai lagi (bila perlu). Pada semua kasus, alat alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak. 5) Testing and turnover Karena proses RAD menekankan pada pemakaian kembali, banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi komponen baru harus di uji dan semua interface harus dilatih secara penuh.

Model Proses RAD d. Spiral Model spiral terbagi menjadi empat quadrant, dimana setiap quadrant merepresentasikan sebuah manajemen proses dengan tahapan-tahapan identify, design, construct dan evaluate. Sistem akan melalui tahapan-tahapan proses yang akan berulang sebagai berikut: 1) Mendefinisikan tujuan dan kebutuhan bisnis, mengembangkan desain konseptual, rancangan konsep, rencana pengujian, dan analisis terhadap resiko dengan melibatkan pemakai. 2) Mendefinisikan kebutuhan sistem, mengembangkan desain logikal, mengkompilasi

(software-build) rancangan awal, mengevaluasi hasil dengan melibatkan pemakai. 3) Mendifinisakan kebutuhan subsistem, menghasilkan desain fisikal, mengkompilasi rancangan berikutnya, mengevaluasi hasil dengan melibatkan pemakai. 4) Mendefinisikan kebutuhan setiap unit, menghasilkan desain akhir, mengkompilasi rancangan akhir, mengevaluasi keseluruhan.

Model Proses Spiral 3. Pada saat kondisi yang bagaimana masing-masing model di atas digunakan? a. Waterfall Digunakan pada saat kondisi perangkat lunak dengan syarat-syarat yang telah didefinisikan secara lengkap sebelumnya dan besar kemungkinan tidak adanya perubahan aplikasi dimasa yang akan datang. b. Prototyping Digunakan pada saat kondisi yang dimana kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output. Di lain waktu mungkin dimana tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user interface c. RAD Digunakan pada saat kondisi dimana sebuah aplikasi bisnis dapat dimodulkan dengan cara tertentu sehingga memungkinkan setiap fungsi mayor untuk dilengkapi dalam waktu kurang dari 3 bulan d. Spiral Digunakan pada saat kondisi kebutuhan waktu untuk pengembangan aplikasi yang cepat dengan kapasitas proyek yang relatif kecil.
Menurut Ian Somerville, Model proses secara umum terdiri dari: 1. Pendekatan Model Air terjun (Water fall), Menempatkan semua aktifitas sesuai dengan tahapan pada model Waterfall dengan memisahkan dan membedakan antara spesifikasi dan pengembangan

Waterfall model pertama kali diperkenalkanoleh Winston Royce tahun 1970. Waterfall Model merupakan model klasik yang sederhana dengan aliran sistem yang linier. Output dari setiap tahap merupakan input bagi tahap berikutnya.Model ini telah diperoleh dari proses rekayasa lainnya dan menawarkan cara pembuatan rekayasa perangkat lunak secara lebih nyata. Model ini melibatkan tim SQA (Software Quantity Assurance) dengan 5 tahapan, dimana setiap tahapan selalu dilakukan verifikasi atau testing

Tahapan model waterfall meliputi :

Requirment

Dalam tahapan ini jasa, kendala dan tujuandari konsultasi dengan pengguna sistem. Kemudian semuanya dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang. Dengan kata lain, dalam tahapn ini dilakukan analisa kebutuhan, kemdian diverifikasi klien dan tim SQA.

Specification

Dokumentasi spesifikasi, kemudian diperiksa oleh tim SQA. Selanjutnya jika disetujui oleh klien, maka dokumen tersebutmerupakan kontrak kerjaantaraklien dan pengembang s0ftware. Selanjutnya merencanakan jadwal pengembangan software. Jika disetujui oleh SQA, tahap desain baru dilakukan.

Design

Proses design sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. Proses tersebut menghasilkan sebuah arsitektur keseluruhan. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkatlunak dalam bentuk yang mungkin ditransformasi kedalam satu atau lebih program yang dapat dijalankan. Tahapan ini telah menentukan alur software hingga pada tahap algoritma detail. Di akhir tahap ini, kembali diperksa tim SQA.

Implementation

Selama tahap ini, desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. Desain yang telah disetujui, diubah dalam bentuk kode-kode program. Tahap ini, kode-kode program yang dihasilkan masih pada tahap modul-modul. Diakhir tahap ini, tiap modul di testing tanpa diintegrasikan.

Integration

Unit program diintegrasikan dandiuji menjadi sistem yang lengkap untuk meyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah uji coba, sistem disampaikan ke konsumen.

Operaton mode & retirement

Normalnya, ini adalah tahap yang terpanjang. Sistem dipasang dan digunakan. Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan

inmplementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan.Setiap tahap dari modelini menggunakan Document Drivent, yaitu tahap selanjutnya selalu bekerja berdasarkan dokumen yang telah diberikan sebelumnya. Tahapan pada waterfall model tidak akan selesai jika tidak disetujui SQA. Modifikasi pada tahap tertentu (tidak sesuai dengan dokumen sebelumnya), proses harus kembali pada tahap sebelumnya untuk penyesuaian dan peninjauan ulang.Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain. Proses perangkat lunak tidak linierdan sederhana, tapi mengandung urutan iterasi dari aktifitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.Sayangnya model yang banyak mengandung iterasi, sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan atau diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user. Mungkin juga sistem terstruktur secarajelek yang sebenarnya merupakan masalah deain akan dibiarkan karenaterkalahkan olehtrik implementasi.Masalah pendekatan waterfall adalah ketidakluwaesan pembagian proyek ke dalam langkah yang jelas/nyata. Sistem yang disampaikan kadang-kadang tidak dapatdigunakan sesuai keinginan konsumen. Namun demikian, model waterfall mencerminkan kepraktisan rekayasa. Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini, digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas. Sedangkan Pengertian prototype Sering seorang pelanggan mendefinisikan serangkaian sasaran umum bagi perangkat lunak, tetapi tidak melakukan mengidentifikasi kebutuhan output, pemrosesan, atupun input detail. Pada kasus yang lain, pengembang mungkin tidak memiliki kepastian terhadap efisiensi algoritme, kemampuan penyesuaian dari sebuah sistem operasi,atau bentuk-bentuk yang harus dilakukan oleh interaksi manusia dengan mesin. Dalam hal ini, serta pada banyak situasi yang lain, prototyping paradigma mungkin menawarkan pendekatan yang terbaik. Prototyping paradigma dimulai dengan pengumpulan kebutuhan. Pengembang dan pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari software, mengidentifikasi segala kebutuhan yang diketahui, dan area garis besar diman definisi lebih jauh merupakan keharusan kemudian dilakukan perancangan kilat. Perancangan kilat berfokus pada penyajian dari aspek-aspek software tersebut yang akan nampak bagi pelanggan atau pemakai (contohnya pendekatan input dan format output). Perancangan kilat membawa kepada konstruksi sebuah prototipe. Prototipe tersebut dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaring kebutuhan pengembangan software. Iterasi terjadi pada saat prototipe disetel untuk memenuhi kebutuhan pelanggan, dan pada saat yang sama memungkinkan pengembang untuk secara lebih baik memahami apa yang harus dilakukannya. Secara ideal prototipe berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan software. Bila prototipe yang sedang bekerja dibangun, pengembang harus mempergunakan fragmen fragmen program yang ada atau mengaplikasikan alat alat bantu

(contohnya report generator, window manager, dll) yang memungkinkan program yang bekerja untuk dimunculkan secara cepat.Prototipe bisa berfungsi sebagai sistem yang pertama. Brooks setuju bila kita membuangnya. Tetapi mungkin ini merupakan pandangan yang ideal. memang benar bahwa baik pelanggan maupun pengembang menyukaiparadigma prototipe. Para pemakai merasa enak dengan sitem aktual, sedangkan pengembang bisa membangun dengan segera. tetapi prototipe bisa juga menjadi masalah karena alasan sebagai berikut: 1. Pelanggan melihat apa yang tampak sebagai versi software yang bekerja tanpa melihat bahwa prototipe itu dijalin bersama sama dengan permen karet dan baling wire, tanpa melihat bahwa di dalam untuk membuatnya bekerja, kita belum menyantumkan kualitas software secara keseluruhan atau kemampuan pemeliharaan untuk jangka waktu yang panjang. Ketika diberi informasi bahwa produk harus dibangun lagi agar tingkat kualitas yang tinggi bisa dijaga, pelanggan akan meneriakan kecurangan dan permintaan agar dipakai beberapa campuran untuk membuat prototipe menjadi sebuah produk yang bekerja yang lebih sering terjadi, sehingga manajemen pengembangan software menjadi penuh dengan belas kasihan. 2. Pengembang sering membuat kompromi kompromi implementasi untuk membuat prototipe bekerja dengan cepat. Sistem operasi atau bahasa pemrograman yang tidak sesuai bisa dipakai secara sederhana karena mungkin diperoleh dan dikenal; algoritma yang tidak efisien secara sederhana bisa diimplementasikan untuk mendemonstrasikan kemampuan. Setelah selang waktu tertentu, pengembang mungkin mengenali pilihan pilihan tersebut dan melupakan semua alasan mengapa mereka tidak cocok. Pilihan yang kurang ideal telah menjadi bagian integral dari sebuah sistem. Meskipun berbagai masalah bisa terjadi, prototipe bisa menjadi paradigma yang efektif bagi Software Engineering. Kuncinya adalah mendefinisikan aturan main pada saat awal; yaitu pelanggan dan pengembang keduanya harus setuju bahwa prototipe dibangun untuk berfungsi sebagai mekanisme pendefinisian kebutuhan. Prototipe kemudian disingkirkan (paling tidak sebagian), dan software aktual direkayasa dengan tertuju kepada kualitas dan kemampuan pemeliharaan.