Pengujian Perangkat Lunak & Model-model

Pengujian Perangkat Lunak :

Pengujian perangkat lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain  dan pengkodean. Dalam strategi pengujian sebuah perangkat lunak dimulai dari penentuan kebutuhan perangkat lunak, kemudian proses dilanjutkan ke dalam bentuk rancangan, dan akhirnya ke pengkodean. Strategi pengujian dimulai dengan pengujian unit atau unit testing di pusat spiral di mana masing-masing modul/unit dari perangkat lunak yang diimplementasikan dalam source code menjadi sasaran pengujian. Kemudian dilakukan testing integrasi atau integration testing dengan fokus pengujian adalah desain dan kontruksi arsitektur perangkat lunak. Selanjutnya dilakukan testing validasi atau validation testing dengan sasaran pengujian adalah kesesuaian dengan kebutuhan perangkat lunak yang telah ditentukan di awal. Terakhir pada lingkaran terluar spiral sampai pada pengujian sistem atau system testing, di mana perangkat lunak dan keseluruhan sistem diuji. Secara lebih spesifik dari masing-masing pengujian tersebut adalah sebagai berikut.

Model Pengujian :

1. Pengujian Unit Program

Pengujian Unit/ Unit Testing adalah metode verifikasi perangkat lunak dimana programmer menguji suatu unit program layak atau tidaknya untuk dipakai. Unit testing ini fokusnya pada verifikasi unit yang terkecil pada desain perangkat lunak (komponen atau modul perangkat lunak). Uji coba unit selalu berorientasi pada white box testing dan dapat dikerjakan paralel atau beruntun dengan modul lainnya.

•        Pertimbangan Pengujian Unit

Interface modul diuji untuk memastikan bahwa informasi secara tepat mengalir masuk dan keluar dari inti program yang diuji. Struktur data lokal diuji untuk memastikan bahwa data yang tersimpan secara temporal dapat tetap menjaga integritasnya selama semua langkah langkah di dalam suatu algoritma dieksekusi. Kondisi batas diuji untuk memastikan bahwa modul beroperasi dengan tepat pada batas yang ditentukan untuk membatasi pemrosesan. Semua jalur independen (jalur dasar) yang melalui struktur control dipakai sedikitnya satu kali. Dan akhirnya penanganan kesalan diuji.

•       Prosedur Pengujian Unit

Sumber yang telah dikembangkan, ditunjang kembali dan diverifikasi untuk sintaks-nya, maka perancangan test case dimulai. Peninjauan kembali perancangan informasi akan menyediakan petunjuk untuk menentukan test case. Karena modul bukan program yang berdiri sendiri maka driver (pengendali) dan atau stub perangkat lunak harus dikembangkan untuk pengujian unit..

2. Pengujian Integrasi

Pengujian integrasi  lebih pada pengujian penggabungan dari dua atau lebih unit pada perangkat lunak. Pengujian integrasi sebaiknya dilakukan secara bertahap untuk menghindari kesulitan penelusuran jika terjadi kesalahan error / bug. Pengujian terintegrasi adalah teknik yang sistematis untuk penyusunan struktur program, pada saat dikerjakan uji coba untuk memeriksa kesalahan yang nantinya digabungkan dengan interface. Metode pengujiannya meliputi :

2         1.  Top down integration

Merupakan pendekatan untuk penyusunan struktur program. Modul dipadukan dengan bergerak ke bawah melalui kontrol hirarki dimulai dari modul utama. Modul subkordinat ke modul kontrol utama digabungkan ke dalam struktur baik menurut depth first atau breadth first.

Proses integrasi :

·       Modul utama digunakan sebagai test driver dan stub yang menggantikan seluruh modul yang secara langsung berada di bawah modul kontrol utama.

·       Tergantung pada pendekatan perpaduan yang dipilih (depth / breadth)

·       Uji coba dilakukan selama masing-masing modul dipadukan

·       Pada penyelesaian masing-masing uji coba stub yang lain dipindahkan dengan modul sebenarnya.

·       Uji coba regression yaitu pengulangan pengujian untuk mencari kesalahan lain yang mungkin muncul.

2         2.  Buttom up integration

Pengujian buttom up dinyatakan dengan penyusunan yang dimulai dan diujicobakan dengan atomic modul (modul tingkat paling bawah pada struktur program). Karena modul dipadukan dari bawah ke atas, proses yang diperlukan untuk modul subordinat yang selalu diberikan harus ada dan diperlukan untuk stub yang akan dihilangkan.

Strategi pengujian

·       Modul tingkat bawah digabungkan ke dalam cluster yang memperlihatkan subfungsi perangkat lunak

·       Driver (program kontrol pengujian) ditulis untuk mengatur input test case danoutput

·       Cluster diuji

·       Driver diganti dan cluster yang dikombinasikan dan dipindahkan ke atas pada struktur program

3. Pengujian Validasi

Pengujian penerimaan perangkat lunak dilakukan oleh pengguna yang telah bekerja sama dengan pembuat program guna untuk mengetahui secara langsung bagaimana perangkat lunak yang telah dibuat dapat bekerja sebelum perangkat lunak yang dibuat disebar luaskan. Pengujian penerimaan ini bertujuan untuk mengetahui kepuasan pengguna atau user. Pengujian validasi dikatakan berhasil bila fungsi yang ada pada perangkat lunak sesuai dengan yang diharapkan pemakai. Validasi perangkat lunak merupakan kumpulan seri uji coba black box yang menunjukkan sesuai dengan yang diperlukan. Kemungkinan kondisi setelah pengujian dilakukan adalah sebagai berikut :

• Karakteristik performansi fungsi sesuai dengan spesifikasi dan dapat diterima
• Penyimpangandari spesifikasi ditemukan dan dibuatkan daftar penyimpangan.

Pengujian BETA dan ALPHA

Apabila perangkat lunak dibuat untuk pelanggan maka dapat dilakukan aceeptance testsehingga memungkinkan pelanggan untuk memvalidasi seluruh keperluan. Tes ini dilakukan karena memungkinkan pelanggan menemukan kesalahan yang lebih rinci dan membiasakan pelanggan memahami perangkat lunak yang telah dibuat.

1. Pengujian Alpha

Dilakukan pada sisi pengembang oleh seorang pelanggan. Perangkat lunak digunakan pada setting yang natural dengan pengembang “yang memandang” melalui bahu pemakai dan merekam semua kesalahan dan masalah pemakaian.

2. Pengujian Beta

Dilakukan pada satu atau lebih pelanggan oleh pemakai akhir perangkat lunak dalam lingkungan yang sebenarnya, pengembang biasanya tidak ada pada pengujian ini. Pelanggan merekan semua masalah (real atau imajiner) yang ditemui selama pengujian dan melaporkan pada pengembang pada interval waktu tertentu.

4.    Pengujian Sistem

Pengujian sistem dilakukan pada unit-unit proses yang telah diintegrasikan diuji dengan antarmuka yang sudah dibuat sehingga pengujian ini dimaksudkan untuk menguji sistem perangkat lunak. Perlu diingat bahwa pengujian sistem harus dilakukan secara bertahap sejak awal pengembangan, jika pengujian hanya diakhir maka dapat dipastikan kualitas sistemnya kurang bagus.

Pada akhirnya perangkat lunak digabungkan dengan elemen sistem lainnya dan rentetan perpaduan sistem dan validasi tes dilakukan. Jika uji coba gagal atau di luar skope dari proses daur siklus pengembangan sistem, langkah yang diambil selama perancangan dan pengujian dapat diperbaiki. Keberhasilan perpaduan perangkat lunak dan sistem yang besar merupakan kuncinya. Sistem testing merupakan rentetan pengujian yang berbeda-beda dengan tujuan utama mengerjakan keseluruhan elemen sistem yang dikembangkan.

1. Recovery Testing. Recovery testing adalah sistem testing yang memaksa perangkat lunak mengalami kegagalan dalam bermacam-macam cara dan apakah perbaikan dilakukan dengan tepa
2. Security Testing. Security testing adalah pengujian yang akan melalukan verifikasi dari mekanisme perlindungan yang akan dibuat oleh sistem, melindungi dari hal-hal yang mungkin terjadi.
3. Strees Testin. Strees testing dirancang untuk menghadapi situasi yang tidak normal pada saat program diuji. Testing ini dilakukan oleh sistem untuk kondisi seperti volume data yang tidak normal (melebihi atau kurang dari batasan) atau fekuensi.

Linear Sequential Model

KELOMPOK 1

Linear Sequential Model

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

2.      PengertianWaterfall

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.

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

2. Tahap Pengembangan Waterfall

Tahap – tahappengembangan waterfall model adalah

1.         Analisis dan definisi persyaratan
1.    Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user.
2.      Perancangan sistem dan perangkat lunak Kegiatan ini menentukan arsitektur sistem secara keseluruhan
3.      Implementasidanpengujian unit Perancangan perangkat lunak direalisasikan sebagai serangkaian program
4.      Integrasidanpengujiansistem Unit program diintegrasikan atau diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sitem telah terpenuhi
5.      Operasidanpemeliharaan
Merupakan fase siklus yang paling lama. Sistem diinstall dan dipakai. Perbaikan mencakup koreksi dari berbagai error, perbaikan dan implementasi unit sistem dan pelayanan sistem.

3.      Kelebihan dari Model Waterfall

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

4.      Kelemahan Waterfall

1. Waktupengembangan 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.   Biayajugamahal, hal ini juga dikarenakan waktu pengembangan yang lama

3. Terkadangperangkatlunak 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. Karenatahap-tahapanpada waterfall tidak dapat berulang, maka model ini tidak cocok untuk pemodelan pengembangan sebuah proyek yang memiliki kompleksitas tinggi.

5. Meskipun waterfall memilikibanyak kelemahan yang dinilai cukup fatal, namun model ini merupakan dasar bagi model-model lain yang dikembangkan setelahnya.

Rapid Aplication Development (RAD)

KELOMPOK 3

Rapid Aplication Development (RAD)

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

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

3.   Unsur-unsur model RAD

Rapid Aplication Development memiliki banyak unsurunsur yang membuat sebuah metodologi yang unik termasuk prototyping, iterative development, time boxing, team members, management approach, dan RAD tools.

a. 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. Mengembangkan prototipe cepat dicapai dengan Computer Aided Engineering CASE tools Software yang berfokus pada menangkap persyaratan, mengkonversi mereka ke model data, mengubah model data ke database, dan menghasilkan kode semua dalam satu alat. CASE tools populer di 80an dan awal 90an, tetapi sebagai teknologi telah berubah (dan COBOL telah menjadi usang) beberapa alat mengambil keuntungan penuh dari potensi penuh dari teknologi KASUS alat. Perusahaan rasional adalah yang paling terkenal meskipun prototipe potensi pembangkitnya terbatas. Pada Otomatis Arsitektur produk cetak biru kami 3 berfokus pada peningkatan tingkat aplikasi enterprise web yang berfungsi sebagai prototipe karena kecepatan yang mereka dapat diciptakan (dalam menit).

b. 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. Panjang ideal iterasi adalah antara satu hari (yang lebih dekat dengan Metodologi Agile) dan tiga minggu. Setiap siklus pengembangan memberikan pengguna kesempatan untuk memberikan umpan balik, memperbaiki persyaratan, dan kemajuan melihat (dalam pertemuan sesi fokus grup). Hal ini akhirnya pembangunan berulang yang memecahkan masalah yang melekat dalam metodologi fleksibel dibuat pada 1970an.

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

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

Pendekatan manajemen Aktif dan manajemen yang terlibat sangat penting untuk mengurangi risiko siklus pengembangan diperpanjang, kesalahpahaman klien, dan melebihi tenggat waktu. Di atas manajemen semua harus kuat dan konsisten dalam keinginan mereka untuk menggunakan metodologi Rapid Application Development. Selain menegakkan waktu yang ketat, manajemen harus fokus pada pemilihan anggota tim, motivasi tim, dan pada kliring hambatan birokrasi atau politik.

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

 

4.    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. Jika keutuhan yang diinginkan pada tahap analisis kebutuhan telah lengkap dan jelas, maka waktu yang dibutuhkan untuk menyelesaikan secara lengkap perangkat lunak yang dibuat adalah berkisar 60 sampai 90 hari. Model RAD hampir sama dengan model waterfall, bedanya siklus pengembangan yang ditempuh model ini sangat pendek dengan penerapan teknik yang cepat.

Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan beberapa tim dalam waktu yang hampir bersamaan dalam waktu yang sudah ditentukan. Model ini melibatkan banyak tim, dan setiap tim mengerjakan tugas yang selevel, namun berbeda. Sesuai dengan pembagian modul sistem.

5.     Fase-Fase Model RAD

Bussiness Modeling

 

Testing and Turnover

Prosess Modeling

Aplication Generation

Data Modeling

 

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.

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

6.    Perbandingan RAD dengan Metode Lain

6.1 Perbandingan Dengan Metode Tradisional

Sebagai gambaran umum, pengembangan aplikasi berarti mengembangkan aplikasi pemrograman yang bervariasi dari pemrograman umum dalam arti bahwa ia memiliki tingkat yang lebih tinggi dari kewajiban, termasuk untuk kebutuhan menangkap dan pengujian. Pada 1970an, Rapid Application Development muncul sebagai respon mengerikan untuk proses nontangkas, seperti model Waterfall. Pengembang perangkat lunak menghadapi masalah waktu dengan metodologi sebelumnya sebagai aplikasi begitu lama untuk membangun bahwa.spesifikasi persyaratan diubah oleh sistem waktu itu selesai. Dengan demikian, metodologi tersebut sering mengakibatkan sistem tidak dapat digunakan.

Metodologi RAD adalah dalam jangkauan hampir semua orang sebagai generator kode, alatalat visual seperti VB, Visual C + + dan CASE tool seperti Rational Rose didasarkan pada teknik RAD saja. Jika Anda merancang aplikasi dengan Rational Rose, kode dapat secara otomatis dihasilkan dalam bahasa seperti C + +, VC + + atau VB. Sebagai contoh sederhana, jika Anda telah menggunakan alat alat seperti MS FrontPage maka itu kembali alat RAD. Berikut ini gambar perbandingan antara metode RAD dengan metode Trdisional.

Gambar 1 Perbandingan RAD dengan metode Tradisional

Pada gambar 1 menggambarkan perbedaan dari metode tradisonal dengan metode RAD. Untuk tahap tradisonal mengacu pada urutan tahaptahap SDLC. Pada RAD Tahap pertama langsung membuat analisis dan design, lalu langsung ketahap siklus prototyping yaitu membangun, memperhalus dan mendemonstrasikannya. Itu akan mempercepat proses dalam pembuatan suatu project. RAD memang lebih cepat dari Waterfall. Jika kebutuhan dan batasan project sudah diketahui dengan baik. Juga jika proyek memungkinkan untuk dimodularisasi.

6.2 Metodelogi RAD mengunakan Prototyping dan Throwaway Prototyping

Gambar 2 RAD menggunakan Prototyping 8

Karena Keunggulan metode ini menggabungkan teknik SDLC, Prototyping, teknik joint application development (JAD) dan computer aided software engineering (CASE Tools) yang bertujuan untuk membuat system dalam waktu singkat ( kurang dari 6 bulan ). Pada gambar 2 diatas Metodologi prototyping melakukan analisis, desain dan implementasi secara bersamaan untuk menghadirkan sebuah sistem dengan skala kecil dalam fungsi minimal kemudian di review oleh user untuk dilakukan proses development secara berulang hingga menghasilkan sebuah system.

6.3 Menggunakan Throwaway Prototyping Methodologies

Gambar 3 RAD Menggunakan Throwaway Prototyping Methodologies

Untuk gambar 3 adalah metode Throwaway Prototyping, pada metodologi ini Analisa dilakukan lebih mendalam, prototype dibuat dan ditest, pengalaman yang diperoleh dari latihan ini digunakan untuk membuat produk finalnya, tetapi prototypenya sendiri dibuang.

7.     Kelebihan Penggunaan Model RAD

·      Dimungkinkan dalam proses pembuatan membutuhkan waktu yang sangat singkat (60-90 hari)

·      Menghemat biaya, karena penekannya adalah penggunaan komponen-komponen yang sudah ada

·      RAD menggunakan kembali komponen-komponen yang sudah ada, maka beberapa komponen program sudah diuji sehingga kita dapat melakukan penghematan waktu dalam uji coba

8.     Kekurangan Penggunaan Model RAD

Seperti semua proses model yang lain, pendekatan RAD memiliki kekurangan-kekurangan sebagi berikut:

·      Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.

·      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. Jika komitmen tersebut tidak ada, proyek RAD akan gagal. RAD menekankan perkembangan komponen program yang bisa dipakai kembali. Reusable menjadi batu pertama teknologi objek dan ditemui di dalam proses rakitan komponen

·      Tidak semua aplikasi sesuai untuk RAD. Bila sistem tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat problematis.

·      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