Rapid Aplication Development (RAD)

Pengertian RAD

           Rapid Aplication Development (RAD) adalah sebuah proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier dimana perkembangan cepat dicapai dengan menggunakan pendekatan konstruksi 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).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

Sejarah RAD

       Rapid Application Development ( RAD ) adalah istilah awalnya digunakan untuk menggambarkan proses pengembangan perangkat lunak pertama kali dikembangkan dan berhasil digunakan selama pertengahan 1970-an oleh Sistem Pusat Pengembangan New York Telephone Co di bawah arahan Dan Gielan. Setelah serangkaian implementasi sangat berhasil dari proses ini, Gielan kuliah secara ekstensif di berbagai forum pada metodologi , praktek, dan manfaat dari proses ini.

RAD melibatkan pengembangan dan pembangunan prototipe iteratif . Pada tahun 1990 , dalam buku RAD, Rapid Application Development, James Martin didokumentasikan penafsirannya tentang metodologi. Baru-baru ini, istilah dan singkatan yang telah datang untuk digunakan dalam lebih luas, pengertian umum yang mencakup berbagai metode yang bertujuan untuk mempercepat pengembangan aplikasi, seperti penggunaan kerangka perangkat lunak dari berbagai jenis, seperti kerangka kerja aplikasi web.

        Pengembangan aplikasi yang cepat merupakan respon terhadap proses yang dikembangkan pada 1970-an dan 1980-an, seperti Structured Sistem Metode Analisis dan Desain dan model Waterfall lainnya. Satu masalah dengan metodologi sebelumnya adalah bahwa aplikasi begitu lama untuk membangun bahwa persyaratan telah berubah sebelum sistem itu selesai, sehingga sistem tidak memadai atau bahkan tidak dapat digunakan. Masalah lain adalah asumsi bahwa persyaratan metodis tahap analisis saja akan mengidentifikasi semua persyaratan penting. Membuktikan fakta bahwa ini adalah jarang terjadi, bahkan untuk proyek-proyek dengan profesional yang sangat berpengalaman di semua tingkatan.

Dimulai dengan ide-ide dari Brian Gallagher, Alex Balchin, Barry Boehm dan Scott Shultz, James Martin mengembangkan pendekatan pengembangan aplikasi yang cepat selama tahun 1980 di IBM dan akhirnya diresmikan itu dengan menerbitkan sebuah buku pada tahun 1991, Rapid Application Development.

Unsur-unsur model RAD

Prototyping

          Sebuah aspek kunci dari RAD adalah pembangunan prototipe untuk tujuan membangkitkan kembali desain untuk kebutuhan pengguna. Tujuannya adalah untuk membangun sebuah fitur ringan yang hasil akhirnya dalam jumlah pendek dengan waktu yang memugkinkan. Prototipe awal berfungsi sebagai bukti konsep untuk klien, tetapi lebih penting berfungsi sebagai titik berbicara dan alat untuk kebutuhan pemurnian.

Iterative Development

      Iterative Development berarti menciptakan versi yang lebih fungsional dari sebuah sistem dalam siklus pembangunan pendek. Setiap versi ditinjau dengan klien untuk menghasilkan persyaratan untuk membuat versi berikutnya. Proses ini diulang sampai semua fungsionalitas telah dikembangkan.

Time boxing

         Time boxing adalah proses menunda fitur untuk versi aplikasi di masa mendatang untuk melengkapi versi saat ini sebagai ketepatan waktu.Ketepatan waktu merupakan aspek penting dari RAD, karena tanpa itu ruang lingkup dapat mengancam untuk memperpanjang iterasi pembangunan, sehingga membatasi umpan balik dari klien, meminimalkan manfaat dari pembangunan berulang, dan berpotensi mengembalikan proses kembali ke pendekatan metodologi air terjun.

Team Member

      Metodologi RAD merekomendasikan penggunaan tim kecil yang terdiri dari anggota yang berpengalaman, serbaguna, dan motivasi yang mampu melakukan peran ganda. Sebagai klien memainkan peran penting dalam proses pembangunan, sumber daya klien khusus harus tersedia selama awal Joint Application Development (JAD) sesi serta Focus Group Sessions dilakukan pada akhir siklus pengembangan. Pengembangan tim (juga dikenal sebagai SWAT atau Skilled Workers with Advance 4 Tools) idealnya harus memiliki pengalaman di Rapid Application Development dan harus memiliki pengalaman dengan Computer Aided Software Engineering.

RAD Tools

       Salah satu tujuan utama dari metodologi Rapid Application Development yang dikembangkan oleh James Martin pada tahun 1980an adalah untuk memanfaatkan teknologi terbaru yang tersedia untuk mempercepat pembangunan. Jelas teknologi tahun 1980 sudah kuno, tetapi fokus RAD tentang alat terbaru adalah sama pentingnya hari ini seperti ketika metodologi awalnya diciptakan

Penerapan Model RAD
Model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang dicapai dengan menerapkan :
1. Component based construction ( pemrograman berbasis komponen bukan prosedural).
2. Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada.
3. Pembangkitan kode program otomatis/semi otomatis.
4. Multiple team (banyak tim), tiap tim menyelesaikan satu tugas yang selevel tapi tidak sama. Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun.

Fase-Fase Model RAD
Bussiness Modeling

       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 dimunculkan? Siapa yang memunculkannya? Ke mana informasi itu pergi? Siapa yang memprosesnya?

Data Modeling

         Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modeling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik masing-masing objek didefinisikan dan hubungan antara objek-objek tersebut didefinisikan.

Prosess Modeling

      Objek data yang telah 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.

Aplication Generation

       RAD mengasumsikan pemakaian teknik generasi keempat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman general yang konvensional, RAD lebih banyak memproses kerja untuk mamakai lagi komponen program yang ada atau menciptakan komponoen yang bisa dipakai lagi. Pada semua kasus, alat-alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.

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 diuji dan semua interface harus dilatih secara penuh.

Kelebihan Penggunaan Model RAD
1. Dimungkinkan dalam proses pembuatan membutuhkan waktu yang sangat singkat (60-90 hari)
2. Menghemat biaya, karena penekannya adalah penggunaan komponen-komponen yang sudah ada
3. RAD menggunakan kembali komponen-komponen yang sudah ada, maka beberapa komponen program sudah diuji sehingga kita dapat melakukan penghematan waktu dalam uji coba

Kekurangan Penggunaan Model RAD
Seperti semua proses model yang lain, pendekatan RAD memiliki kekurangan-kekurangan sebagi berikut:
1. Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.
2. RAD menuntut pengembangan dan pelanggan yang memiliki komitmen di dalam aktifitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek.
3. Tidak semua aplikasi sesuai untuk RAD. Bila sistem tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat problematis.
4. RAD menjadi tidak sesuai jika risiko teknisnya tingggi. Hal ini terjadi bila sebuah aplikasi baru memforsir teknologi baru atau bila perangkat lunak baru membutuhkan tingkat interoperabilitas yang tinggi dengan program komputer yang ada

Model Waterfall

Sejarah Model Waterfall

       Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini pertama kali yang diperkenalkan oleh Winston Royce sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan berurutan. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan.

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.

Tahapan Atau Fase Model Waterfall

1. System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software.
2. Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software.
3. Design. Proses ini digunakan untuk mengubah kebutuhan -kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai.
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. .
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.

Karakteristik

Dalam model ini terdapat beberapa sifat-sifat yang menojol dan cenderung menjadi permasalahan pada model waterfall.

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 agar problem ini tidak muncul.

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.

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

Tahap Pengembangan Waterfall
Tahap – tahap pengembangan waterfall model adalah
1. Analisis dan definisi persyaratan.
2. Perancangan sistem dan perangkat lunak.
3. Implementasi dan pengujian unit
4. Integrasi dan pengujian sistem
5. Operasi dan pemeliharaan

Kelebihan dari Model Waterfall
1. Merupakan model pengembangan paling handal dan paling lama
digunakan.
2. Cocok untuk system software berskala besar.
3. Cocok untuk system software yang bersifat generic.
4. Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol

Kelemahan Waterfall
1. Waktu pengembangan lama. hal ini dikarenakan input tahap berikutnya  adalah output dari tahap sebelumnya. Jika satu tahap waktunya molor,  maka waktu keseluruhan pengembangan juga ikut molor.
2. Biaya juga mahal, hal ini juga dikarenakan waktu pengembangan yang lama
3. Terkadang perangkat lunak yang dihasilkan tidak akan digunakan karena sudah tidak sesuai dengan requirement bisnis customer. hal ini juga dikarenakan waktu pengembangan yang lama. selain itu dikarenakan waterfall merupakan aliran yang linear, sehingga jika requirement berubah proses tidak dapat diulang lagi.
4. Karena tahap-tahapan pada waterfall tidak dapat berulang, maka model ini tidak cocok untuk pemodelan pengembangan sebuah proyek yang  memiliki kompleksitas tinggi.

INCEREMENTAL MODEL

      Incremental model adalah model pengembangan sistem pada software engineering berdasarkan requirement software yang dipecah menjadi beberapa fungsi atau bagian sehingga model pengembangannya secara bertahap. dilain pihak ada mengartikan model incremental sebagai perbaikan dari model waterfall dan sebagai standar pendekatan topdown.

Layaknya Model Waterfall, Model ini pun juga memiliki tahapan tahapan untuk perancangan perangkat lunaknya, yaitu:

1. Requirement , Requirment adalah proses tahapan awal yang

dilakukan pada incremental model adalah penentuan

kebutuhanatau analisis kebutuhan.

2. Specification, Specification adalah proses spesifikasi dimana

menggunakan analisis kebutuhan sebagai acuannya.

3. Architecture Design, adalah tahap selanjutnya, perancangan

software yang terbuka agar dapat diterapkan sistem

pembangunan per-bagian pada tahapan selanjutnya.

4. Code setelah melakukan proses desain selanjutnya ada

pengkodean.

5. Test merupakan tahap pengujian dalam model ini.

    Tahapan-tahapan tersebut dilakukan secara berurutan. Setiap bagian yang sudah selesai dilakukan testing, dikirim ke pemakai untuk langsung dapat digunakan. Pada incremental model, tiga tahapan awal harus diselesaikan terlebih dahulu sebelum sebelum tahap membangun tiap increment. Untuk mengantisipasi kondisi yang terjadi pada incremental model, diperkenalkan model More Risky Incremental Model. Model ini menerapkan sistem kerja yang paralel. Setelah daftar kebutuhan didapatkan dari pemakai, tim spesifikasi membuat spesifikasi untuk modul pertama. Setelah spesifikasi pertama selesai, tim desain menindak lanjuti. Tim spesifikasi sebelumnya juga langsung membuat spesifikasi untuk model kedua, dan seterusnya. Jadi, tidak harus menunggu modul pertama selesai hingga dikirim ke user.

Kelebihan Dari Mode Incremental:
1. Merupakan model dengan manajemen yang
sederhana
2. Pengguna tidak perlu menunggu sampai seluruh
sistem dikirim untuk mengambil keuntungan dari
sistem tersebut. Increment yang pertama sudah
memenuhi persyaratan mereka yang paling kritis,
sehingga perangkat lunak dapat segera digunakan.
3 Resiko untuk kegagalan proyek secara keseluruhan
lebih rendah. Walaupun masalah masih dapat
ditemukan pada beberapa increment. Karena
layanan dengan prioritas tertinggi diserahkan
pertama dan increment berikutnya diintegrasikan
dengannya, sangatlah penting bahwa layanan
sistem yang paling penting mengalami pengujian
yang ketat. Ini berarti bahwa pengguna akan
memiliki kemungkinan kecil untuk memenuhi
kegagalan perangkat lunak pada increment sistem
yang paling bawah.
4 Nilai penggunaan dapat ditentukan pada setiap
increment sehingga fungsionalitas sistem
disediakan lebih awal.
5 Memiliki risiko lebih rendah terhadap keseluruhan
pengembagan sistem,
6. Prioritas tertinggi pada pelayanan sistem adalah
yang paling diuji

Kelemahannya :
1 kemungkinan tiap bagian tidak dapat diintegrasikan
2 Dapat menjadi build and Fix Model, karena
kemampuannya untuk selalu mendapat perubahan
selama proses rekayasa berlangsung
3 Harus Open Architecture
5. Mungkin terjadi kesulitan untuk memetakan
kebutuhan pengguna ke dalam rencana spesifikasi
masing-masing hasil increment.

COMPONENT ASSEMBLY MODEL ( CAM )

Pengertian CAM

   Component Assembly Model (CAM) adalah suatu model Metodologi penelitian RPL yang merupakan gabungan dari berbagai model lain karena terdapat beberapa kesamaan dari Model RPL Prototype, Spiral Boehm dan RAD.

       Sifat karakteristik dari CAM yaitu yang seperti saya sebutkan tadi Model Spiral Boehm dan sangat erat keterikatannya dengan model RAD (Rapid Application Development), model karena model CAM ini menggunakan peralatan-peralatan dan GUI (Graphic User Interface) untuk membangun software Dengan kata lain pembuatan aplikasinya dibuat dari paket perangkat lunak yang berisi serangkaian komponen yang telah ada sebelumnya. Namun, waktu yang dibutuhkan dapat disesuaikan atau lebih efektif daripada harus mengerjakan program dari awal.

Tahapan-tahapan CAM yaitu sebagai berikut :
1. Tahap identifikasi calon-calon komponen (Kelas Objek)
2. Tahap melihat komponen-komponen dalam pustaka
3. Tahap mengekstrak komponen
4. Tahap membangun komponen
5. Tahap menyimpan komponen baru pada pustaka
6. Tahap mengkonstruksi iterasi ke-N dari sistem.


Kelebihan CAM

   kelebihanya adalah tinggal mencaplok atau menggunakan program atau komponen yang sudah ada dan menyusunnya menjadi sebuah program yang lebih kompleks dan berkembang sesuai dengan kebutuhan user/pengguna sehingga dapat mengefisienkan penggunaan waktu dan tenaga. Selain itu, model ini juga menyediakan kemampuan untuk memvisualisasikan hasil rakitan dengan kesanggupan untuk mengukur, menganalisa, merancang dan merancang ulang program.

Kekurangan CAM

     kekurangan CAM adalah seringnya program atau komponen-komponen terdahulu tidak kompatibel atau sejalan dengan model perakitan komponen ini sehingga untuk perusahaan berskala kecil akan kesulitan menemukan komponen yang sesuai untuk dirakit.

MODEL SPIRAL

Pengertian model spiral

     Model Spiral (spiral model) adalah salah satu bentuk dari Metode Pengembangan Perangkat Lunak atau yang disebut SDLC (Software Development Life Cycle), yang sangat populer digunakan dalam bidang teknologi informasi. Model Spiral adalah gabungan dari Model Prototyping dan Model Waterfall dengan penekanan yang tinggi pada analisis risiko tiap tahapannya. Bentuk ini bersifat iteratif atau berulang dengan mengontrol aspek yang teratur dari sekuensial linier. Fungsi Model Spiral ini adalah untuk melakukan perubahan, penambahan dan pengembangan suatu software dengan deretan pertambahan menjadi lebih baik secara cepat dan tepat berdasarkan keinginan dan kebutuhan penggunanya.

        Model ini ditemukan, yaitu pada sekitar tahun 1988 oleh Barry Boehm pada artikel A Spiral Model of Software Development and Enhancement. Spiral model adalah salah satu bentuk evolusi yang menggunakan metode iterasi natural yang dimiliki oleh model prototyping dan di gabungkan dengana speksistimatis yang dikembangkan dengan model waterfall. Tahap desain umumnya di gunakan pada model Waterfall, sedangkan tahap prototyping adalah suatu model dimana software dibuat prototype (incomplete model), “blue-print”-nya, atau contohnya dan ditunjukkan ke user / customer untuk mendapatkan feedback-nya. Jika prototype-nya sudah sesuai dengan keinginan user / customer, maka proses SE di lanjutkan dengan membuat produk sesungguhnya dengan menambah dan memperbaiki kekurangandari prototype tadi.

     Model ini juga mengkombinasikan top-down design dengan bottom-up design, dimana top-down design menetapkan sistem global terlebih dahulu, baru di teruskan dengan detail sistemnya, sedangkan bottom-up design berlaku sebaliknya. Top-down design biasanya di aplikasikan pada model waterfall dengan sequential-nya, sedangkan bottom-up design biasanya di aplikasikan pada model prototyping dengan feedback yang diperoleh. Dari 2 kombinasi tersebut, yaitu kombinasi antara desain dan prototyping, serta top-down dan bottom-up, yang juga di aplikasikan pada model waterfall dan prototype, maka spiral model ini dapat dikatakan sebagai model proses hasil kombinasi dari kedua model tersebut. Oleh karena itu, model ini biasanya dipakai untuk pembuatan software dengan skala besar dan kompleks.

Sejarah model spiral

    Tahun 1986, model ini dikenalkan pertama kali oleh Barry Boehm pada makalahnya yang berjudul “A Spiral Model of Software Development and Enhancement”. Makalah tersebut menjelaskan tentang sebuah diagram yang dihasilkan dari berbagai publikasi yang mendiskusikan tentang Model Spiral ini. Model ini merupakan model yang sudah lama, tetapi sangat berguna untuk melakukan pembangunan proyek-proyek besar.

       Pada makalah awal yang dibuatnya, Barry Boehm menganggap bahwa Model Spiral adalah suatu model proses yang berhubungan dengan inkrementasi, Model Waterfall dan Model Prototyping.

Namun dalam publikasi selanjutnya, Boehm menjelaskan bahwa Model Spiral sebagai model proses generator yang mana pilihan berdasarkan risiko proyek untuk menghasilkan suatu model proses yang tepat untuk proyek tersebut. Dengan demikian, inkrementasi, Model Waterfall dan Model Prototyping adalah kasus khusus dengan pola risiko proyek tertentu dari Model Spiral.

Tahap-tahap Spiral Model
Dalam Model Spiral terdapat lima tahap untuk merealisasikan penggunaannya sebagai berikut :
1. Tahap Liason

Tahap ini berhubungan dengan komunikasi antara orang yang 

akan mengembangkan software (system analyst) dengan

pelanggan. Tujuannya adalah agar dapat memuaskan pelanggan

dengan memperbaiki dan mengembangkan software sesuai

dengan kebutuhan, kepentingan dan keinginannya.

2. Tahap Planning
Tahap perencanaan meliputi estimasi biaya yang digunakan,
batas waktu, pengaturan jadwal, identifikasi lingkungan kerja,
sumber-sumber infomasi untuk melakukan iterasi. Hasilnya
adalah dokumen spesifikasi kebutuhan sistem dan bisnis.
3. Tahap Analisis Risiko
Tahap ini berfungsi untuk mengidentifikasi risiko yang
berpotensial untuk terjadi dan menghasilkan suatu solusi
alternatif secara teknis dan manajemen saat strategi mitigasi
risiko direncanakan dan diselesaikan.
4. Tahap Rekayasa (engineering)
Pada tahap ini, yang dilakukan adalah sebagai berikut :
1. Menguji, coding dan mengembangkan software
2. Menginstal software
3. Membuat prototipe
4. Mendesain dokumen
5. Meringkas suatu pengujian software
6. Membuat laporan atas kekurangan dari software agar segera
diperbaiki
5. Tahap Evaluasi

Peran pelanggan sangat diperlukan pada tahap ini. Mereka

dapat memberikan masukan dan tanggapan, mengevaluasi

produk kerja dan memastikan bahwa produk yang dibutuhkan

sesuai dengan semua ketentuan. Jika terdapat perubahan,

semua tahapan akan diperbaiki sesuai dengan kepuasan

pelanggan. Namun, mengidentifkasi dan memantau risiko yang

terjadi juga diperlukan, seperti cost overrun.

Sektor-sektor pada Spiral Model
1. Mengidentifikasi tujuan, alternatif, dan kendala setiap tahap
secara spesifik 2.
2. Mengevaluasi alternatif, menilai resiko dan pengurangannya,
aktifitas ditempatkan untuk mengurangi resiko kunci3.
3. Pengembangan dan validasi
4. Proyek ditinjau ulang dan tahap spiral berikutnya direncanakan

Penggunaan Spiral Model
Model Spiral tepat digunakan dalam hal sebagai berikut :
1. Ketika memiliki sebuah proyek dengan risiko sedang hingga tinggi
2 Komitmen proyek jangka panjang karena potensi perubahan pada
prioritas ekonomi dalam perubahan waktu
3. Lini produk baru yang harus dirilis secara bertahap untuk
mendapatkan feedback pelanggan dengan cukup
4. Ketika penciptaan prototipe berlaku
5. Perubahan signifikan yang diharapkan dalam produk selama siklus
pengembangan
6. Persyaratan yang kompleks dan memerlukan suatu evaluasi

kelebihan dan Kekurangan Spiral Model

Kelebihan dalam menggunakan Model Spiral, yaitu :
1. Perubahan-perubahan yang terjadi dapat diselesaikan secara
sistematis
2. Estimasi biaya menjadi mudah karena pembuatan prototipe telah
selesai dalam fragmen yang kecil
4. Manajemen dan analisis risiko yang lebih baik
5. Pembangunan yang cepat dan mudah secara sistematis
6. Manajemen waktu yang lebih baik
7. Mudah dalam melakukan perubahan kebutuhan dan dokumentasi
jika perubahan terjadi di tengah-tengah perubahan
8. Produksi software terjadi lebih cepat

Kekurangan dalam menggunakan Model Spiral, yaitu :
1. Tidak cocok ketika digunakan dalam proyek-proyek kecil
2. Tidak terlalu berguna dalam proyek-proyek kecil
3. Sulit dalam mengikuti strategi proyek kecil
4. Kurang efisien dalam penerapan model spiral karena waktu yang
digunakan
5. Membutuhkan sumber pengalaman sebagai proses sehingga sangat
kompleks
6 Dalam melakukan proyek kecil, estimasi biaya akan sangat tinggi
7. Risiko dalam tahap planning, jika terjadi perbedaan dalam jadwal
pengembangan atau dalam anggaran belanja

FOUR GENERATION TECHNIQ GE/ 4GT

Pengertian four generation techniq / 4GT

Istilah Fourth Generation Techniques (4GT) mencakup seperangkat peralatan perangkat lunak yang berfungsi sebagai perangkat bantu yang memudahkan seorang pengembang software mengaplikasi beberapa karakteristik software pada tingkat yang tinggi, yang akan menghasilkan source code dan object code secara otomatis sesuai dengan spesifikasi (persyaratan khusus) yang dibuat oleh sang pengembang perangkat lunak.

Tool 4GT adalah bahasa non prosedur antara lain :

1. DataBase Query 
2. Pembentukan laporan ( Report Generation ) 
3. Manipulasi data 
4. Definisi dan interaksi layar (screen) 
5. Pembentukan object dan source ( Object and source generation ) 
6. Kemampuan grafik yang tinggi, dan 
7. Kemampuan spreadsheet

Tahapan-tahapan model 4GT antara lain sebagai berikut : 

• · Tahap pengumpulan kebutuhan 

   Tahap ini merupakan tahap pengumpulan serangkaian kebutuhan. Customer menjelaskan kebutuhan-kebutuhan kemudian akan diterjemahkan ke dalam prototype. Tetapi jika customer merasa tidak yakin dengan apa yang diperlukan, maka prototype tidak akan dikerjakan oleh 4GT

• Tahap Merancang Strategi 

    Tahap ini dibutuhkan untuk proyek besar yakni dengan menterjemahkan kebutuhan menjadi prototipe operasional agar tidak timbul masalah yang sama jika dibuat dengan model konvensional. Namun, untuk proyek skala kecil tahap ini dapat dihilangkan dengan langsung melakukan implementasi dengan menggunakan bahasa generasi keempat (4GT). 

• Tahap Implementasi 

        untuk skala kecil tahap ini dapat langsung dilakukan ketika kebutuhan telah jelas, dan untuk proyek besar tahapan ini dijalankan setelah dirancang prototipe operasional. Implementasi yang menggunakan 4GT memudahkan pengembang software untuk menjelaskan hasil yang diharapkan yang nantinya akan diterjemahkan ke dalam bentuk kode sumber dan kode objek. 

• Tahap produksi 

    Tahap ini merupakan langkah terakhir yakni mengubah implementasi 4GT ke dalam hasil akhir berupa produk. 

MODEL PROSES PENGEMBANGAN PROTOTYPING

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 (Howard, 1997). 

• Reusable prototype: Prototype yang akan ditransformasikan menjadi produk final. 
• Throwaway prototype: Prototype yang akan dibuang begitu selesai menjalankan maksudnya. 
• Input/output prototype: Prototype yang terbatas pada antar muka pengguna (user interface). 
• Processing prototype: Prototype yang meliputi perawatan file dasar dan proses-proses transaksi. 
• System prototype: Prototype yang berupa model lengkap dari perangkat lunak. 

Tahap-tahap dalam prototyping boleh dikata merupakan tahap-tahap yang dipercepat. Strategi utama dalam prototyping adalah kerjakan yang mudah terlebih dahulu dan sampaikan hasil kepada pengguna sesegera mungkin. 

Harris (2003) membagi prototyping dalam enam tahapan, tahapan-tahapan secara ringkas dapat dijelaskan sebagai berikut: 

1. Identifikasi kandidat prototyping. Kandidat dalam kasus ini meliputi user interface (menu, dialog, input dan output), file-file transaksi utama, dan fungsi-fungsi pemrosesan sederhana. 
2. Rancang bangun prototype dengan bantuan software seperti word processor, spreadsheet, database, pengolah grafik, dan software CASE (Computer-Aided System Engineering). 
3. Uji prototype untuk memastikan prototype dapat dengan mudah dijalankan untuk tujuan demonstrasi. 
4. Siapkan prototype USD (User’s System Diagram) untuk mengidentifikasi bagian- bagian dari perangkat lunak yang di-prototype-kan. 
5. Evaluasi dengan pengguna untuk mengevaluasi prototype dan melakukan perubahan jika diperlukan. 
6. Transformasikan prototype menjadi perangkat lunak yang beroperasi penuh dengan melakukan penghilangan kode-kode yang tidak dibutuhkan, penambahan program-program yang memang dibutuhkan dan perbaikan dan pengujian perangkat lunak secara berulang.

Tahapan Metode Prototyping

Contoh tahapan metode prototyping

Requirement Gathering

     Pada tahapan prototyping atau phase ini adalah menjelaskan bahwasanya user dan analis melakukan pertemuan lalu kemudian melakukan conversation antara keduanya, user mendeskripsikan mengenai spesifikasi kebutuhan dari aktivitas yang user lakukan seperti dalam pekerjaannya atau aktivitas lainnya, kemudian analis harus berusaha memahami apa maksud dari deskripsi user yang diajukannya tersebut. Dan kedua belah pihak yaitu tentunya antara user dan analis (pengembang) berusaha untuk setuju pada tahap ini.

Formal Language Representation

        Hasil dari tahap atau phase pertama tersebut dijadikan analis sebagai dasar idea (konsep) pembuatan program atau sistem, kemudian pada tahapan ini juga analis menjadikan spesifikasi yang telah diperoleh menjadi konsep yang mudah di mengerti oleh analis dan tentunya dalam tahapan ini analis sudah mengetahui apa maksud spesifikasi dari deskirpsi user tersebut.

Quick Design Prototype

       Pada tahapan atau phase ini analis akan dilakukan perencanaan dan pemodelan secara cepat berupa rancangan cepat (quick design) dan kemudian akan memulai konstruksi pembuatan prototype
Optimization and Tuning

    Selanjutnya pada tahapan atau phase ini program dibuat berdasarkan prototype yang telah diajukan dan disetujui bersama (Team analis), kemudian pada tahap ini juga sebuag program di uji coba oleh analis dan tentunya user, kemudia user menilai apakah program tersebut dapat di terima atau tidak.

         Jika sebuah program tersebut user menolak maka analis harus kembali pada phase atau tahapan sebelumnya untuk memperbaiki kesalahan, kekurangan dan ketidak sesuaian program tersebut dengan spesifikasi user.

Complete Software 

     Pada tahapan ini program telah disetujui (berhasil memenuhi spesifikasi yang diajukan) oleh user dan selanjutnya user dapat menggunakan program pesanan-nya dengan sukses, tentunya pada tahapan ini program telah diserahkan kepada user.

Kelebihan Metode Prototyping

1. Dapat menjalin komunikasi yang baik antar user dan pengembang sistem
2. Setiap perbaikan yang dilakukan pada prototype merupakan hasil masukan dari user yang akan menggunakan sistem tersebut, sehingga lebih reliabel
3. User akan memberikan masukan terhadap sistem sesuai dengan kemauannya
4. Menghemat waktu dalam mengembangkan sebuah sistem
5. Menghemat biaya, terutama pada bagian analisa, karena hanya mencatat poin – point penting saja
6. Cocok digunakan pada sebuah sistem kecil, yang digunakan pada ruang lingkup tertentu, seperti sistem di dalam sebuah kantor
7. Penerapan dari sistem yang menjadi lebih mudah untuk dilakukan.

Kekurangan Metode Prototyping

1. Untuk menghemat waktu, biasanya pengembang hanya menggunakan bahasa pemrograman sederhana, yang mungkin rentan dari segi keamanannya
2. Tidak cocok untuk diimplementasikan pada sebuah sistem yang sangat besar dan global, seperti sistem operasi komputer.