Activity Diagram

Activity diagram memiliki pengertian yaitu lebih fokus kepada menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses. Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis. Memiliki struktur diagram yang mirip flowchart atau data flow diagram pada perancangan terstruktur. Memiliki pula manfaat yaitu apabila kita membuat diagram ini terlebih dahulu dalam memodelkan sebuah proses untuk membantu memahami proses secara keseluruhan. Dan activity dibuat berdasarkan sebuah atau beberapa use case pada use case diagram.

Terdapat beberapa hal penting yang harus diketahui, yaitu ;

• Activity mengambarkan sebuah pekerjaan atau tugas dalam workflow
• Pada UML, activity digambarkan dengan simbol kotak

• Start state dengan tegas menunjukan dimulainya suatu workflow pada sebuah activity diagram
• Hanya ada satu start state dalam sebuah workflow
• Pada UML, start state digambarkan dengan simbol lingkaran yang solid

• End state menggambarkan akhir atau terminal dari pada sebuah activity diagram
• Bisa terdapat lebih dari satu end state pada sebuah activity diagram
• Pada UML, end state digambarkan dengan simbol sebuah bull’s eye

• State transition menunjukan kegiatan apa berikutnya setelah suatu kegiatan sebelumnya
• Pada UML, state transition digambarkan oleh sebuah solid line dengan panah

• Decision adalah suatu titik atau point pada activity diagram yang mengindikasikan suatu kondisi dimana ada kemungkinan perbedaan transisi
• Pada UML, decision digambarkan dengan sebuah simbol diamond

Swimlanes

Obyek swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

• Mulailah dengan node awal untuk titik awal.
• Tambahkan partisi jika relevan untuk analisis yang dibuat.
• Tambahkan aksi untuk setiap langkah utama dari use case.
• Tambahkan alur dari setiap aksi ke aksi lain, keputusan atau node akhir. Setiap aksi hanya mendapat satu alur masuk dan satu alur keluar menuju ke forks, joins, decisions, dan merges.
• Tambahkan decisions jika alur dipecah menjadi beberapa pilihan. Jangan lupa untuk menggabungkan kembali dengan merge.
• Tambahkan forks dan joins jika aktivitas akan dilakukan secara paralel.

Contoh Activity Diagram

Studi kasus : Penarikan Uang dari Account Bank Melalui ATM

 

 

Sumber : http://natanawa.hol.es/?p=535

USE CASE DIAGRAM

Bismillahirrahmanirrahim

Assalamualaikum Wr.Wb

USE CASE DIAGRAM

Pengertian :

● Use case class digunakan untuk memodelkan dan menyatakan unit fungsi/layanan yang disediakan oleh sistem (or bagian sistem: subsistem atau class) ke pemakai.
● Use case dapat dilingkupi dengan batasan sistem yang diberi label nama sistem.
● Use case adalah sesuatu yang menyediakan hasil yang dapat diukur ke pemakai atau sistem eksternal.

Karakteristik :

– Use cases adalah interaksi atau dialog antara sistem dan actor, termasuk pertukaran pesan dan tindakan yang dilakukan oleh sistem.
– Use cases diprakarsai oleh actor dan mungkin melibatkan peran actor lain. Use cases harus menyediakan nilai minimal kepada satu actor.
– Use cases bisa memiliki perluasan yang mendefinisikan tindakan khusus dalam interaksi atau use case lain mungkin disisipkan.
– Use case class memiliki objek use case yang disebut skenario. Skenario menyatakan urutan pesan dan tindakan tunggal.

Komponen Pembentuk Use Case Diagram :

1. Actor

Pada dasarnya actor bukanlah bagian dari use case diagram, namun untuk dapat terciptanya suatu use case diagram diperlukan beberapa actor. Actor tersebut mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain) yang berinteraksi dengan sistem. Sebuah actor mungkin hanya memberikan informasi inputan pada sistem, hanya menerima informasi dari sistem atau keduanya menerima, dan memberi informasi pada sistem. Actor hanya berinteraksi dengan use case, tetapi tidak memiliki kontrol atas use case. Actor digambarkan dengan stick man . Actor dapat digambarkan secara secara umum atau spesifik, dimana untuk membedakannya kita dapat menggunakan relationship

Gambar Actor

2. Use Case
Use case adalah gambaran fungsionalitas dari suatu sistem, sehingga customer atau pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan dibangun.
Catatan : Use case diagram adalah penggambaran sistem dari sudut pandang pengguna sistem tersebut (user), sehingga pembuatan use case lebih dititikberatkan pada fungsionalitas yang ada pada sistem, bukan berdasarkan alur atau urutan kejadian.

Cara menentukan Use Case dalam suatu sistem:

a. Pola perilaku perangkat lunak aplikasi.

b. Gambaran tugas dari sebuah actor.

c. Sistem atau “benda” yang memberikan sesuatu yang bernilai kepada actor.

d.   Apa yang dikerjakan oleh suatu perangkat lunak (*bukan bagaimana cara mengerjakannya).

Gambar Use Case

Relasi dalam Use Case

Ada beberapa relasi yang terdapat pada use case diagram:

1. Association, menghubungkan link antar element.

2. Generalization, disebut juga inheritance (pewarisan), sebuah elemen dapat merupakan spesialisasi dari elemen lainnya.

3. Dependency, sebuah element bergantung dalam beberapa cara ke element lainnya.

4. Aggregation, bentuk assosiation dimana sebuah elemen berisi elemen lainnya.

Tipe relasi/ stereotype yang mungkin terjadi pada use case diagram:

1. <<include>> , yaitu kelakuan yang harus terpenuhi agar sebuah event dapat terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case lainnya.

2. <<extends>>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti menggerakkan alarm.

3. <<communicates>>, mungkin ditambahkan untuk asosiasi yang menunjukkan asosiasinya adalah communicates association . Ini merupakan pilihan selama asosiasi hanya tipe relationship yang dibolehkan antara actor dan use case.

3. Contoh Use Case Diagram

Contoh Use Case Diagram

Sumber : http://mitanovia.wordpress.com/belajar-yuk/uml/use-case-diagram/

Struktur Tabel Dan Menu

Bismillahirrahmanirrahim

Assalamualaikum Wr.Wb

Hello bertemu lagi dengan saya fadli , kali ini saya akan coba memberikan contoh atau gambaran apa itu Struktur Tabel dan Menu..

Contoh Struktur Tabel

Struktur Menu

Entity Relationship Diagram (ERD)

Bismillahirrahmanirrahim

Assalamualaikum Wr.Wb

Hallo bertemu lagi dengan saya fadli , kali ini saya akan menjelaskan apa itu Entity Relationship Diagram (ERD).

Tugas RPL

Dalam rekayasa perangkat lunak, sebuah Entity-Relationship Model (ERM) merupakan abstrak dan konseptual representasi data. Entity-Relationship adalah salah satu metode pemodelan basisdata yang digunakan untuk menghasilkan skema konseptual untuk jenis/model data semantik sistem. Dimana sistem  seringkali memiliki basis data relasional, dan ketentuannya bersifat top-down. Diagram untuk menggambarkan model Entitiy-Relationship ini disebut Entitiy-Relationship diagram, ER diagram, atau ERD.

• ERD (Entity Relationship Diagram) adalah gambaran mengenai berelasinya antar entitas.
• Sistem adalah kumpulan dari elemen yang setiap elemen memiliki fungsi masing-masing dan secara bersama-sama mencapai tujuan dari sistem tersebut.
• Kebersama-samaan dari sistem di atas dilambangkan dengan saling berelasinya antara satu entitas dengan entitas lainnya
• Entitas (entity/ entity set), memiliki banyak istilah di dalam ilmu komputer, seperti tabel (table), berkas (data file), penyimpan data (data store), dan sebagainya

Komponen-komponen ERD

1. Entitas dan Atribut

Entitas, adalah segala sesuatu yang dapat digambarkan oleh data. Entitas juga dapatdiartikan sebagai individu yang mewakili sesuatu yang nyata (eksistensinya) dan dapatdibedakan dari sesuatu yang lain (Fathansyah, 1999). Ada dua macam entitas yaitu entitaskuat dan entitas lemah. Entitas kuat merupakan entitas yang tidak memiliki ketergantungan dengan entitas lainnya. Contohnya entitas anggota. Sedangkan entitas lemah merupakan entitas yang kemunculannya tergantung pada keberadaaan entitas lain dalam suatu relasi.

Atribut merupakan pendeskripsian karakteristik dari entitas. Atribut digambarkandalam bentuk lingkaran atau elips. Atribut yang menjadi kunci entitas atau key diberigaris bawah.

Kesimpulannya adalah:

• Entitas adalah tempat penyimpan data, maka entitas yang digambarkan dalam ERD ini merupakan data store yang ada di DFD dan akan menjadi file data di komputer
• Entitas adalah suatu objek dan memiliki nama. Secara sederhana dapat dikatakan bahwa jika objek ini tidak ada di suatu enterprise (lingkungan tertentu), maka enterprise tersebut tidak dapat berjalan normal.
• Contoh, entitas ‘MAHASISWA’ harus ada di lingkungan perguruan tinggi, begitu juga dengan entitas ‘DOSEN’, ‘MATA_KULIAH’, dan sebagainya
• Di dalam entitas ‘MAHASISWA’ berisi elemen-elemen data (biodata mahasiswa) yang terdiri atas NIM, NAMA, KELAS, ALAMAT, dan sebagainya. NIM, NAMA, KELAS, dan ALAMAT disebut dengan atribut (field)
• Gambar memperlihatkan bahwa atribut-atribut NIM, NAMA, ALAMAT, dan TANGGAL_LAHIR harus ada di dalam biodata seorang mahasiswa.
• Atribut-atribut TINGGI_BADAN, dan WARNA_RAMBUT adalah atribut-atribut yang boleh tidak ada di dalam biodata mahasiswa (karena tidak penting).
• Sedangkan atribut NAMA_DOSEN adalah atribut yang tidak boleh ada di entitas mahasiswa
• Pada akhirnya, entitas ini akan menjadi file data (yang bersifat master file) di dalam komputer. Master file adalah file utama (yang harus ada, dan sifatnya jarang berubah)

2. Relasi

Relasi adalah penghubung antara satu entitas (master file) dengan entitas lain di dalam sebuah sistem komputer. Pada akhirnya, relasi akan menjadi file transaksi (transaction file) di komputer. Secara kalimat logis, contoh relasi yang terjadi di sebuah perpustakaan adalah : “Anggota meminjam buku,” atau “Anggota mengembalikan buku.” Dalam hal ini, Anggota dan Buku adalah entitas, meminjam dan mengembalikan adalah transaksi (relasi antara anggota dan buku).

Data Flow Diagram (DFD)

Bismillahirrahmanirrhim

Assalamualaikum Wr.Wb

Bertemu lagi dengan saya , kali ini saya akan mencoba menjelaskan secara singkat apa itu Data Flow Diagram (DFD). Data Flow Diagram (DFD) adalah suatu diagram yang menggunakan notasi-notasi untuk menggambarkan arus dari data sistem, yang penggunaannya sangat membantu untuk memahami sistem secara logika, tersruktur dan jelas.

DFD merupakan alat bantu dalam menggambarkan atau menjelaskan proses kerja suatu sistem.

Contoh Data Diagram

Sumber : http://id.wikipedia.org/wiki/Data_flow_diagram

Context Diagram

Bismillahirrahmanirrahim

Assalamualaikum Wr.Wb

Pada postingan kali ini saya akan membagikan tentang Context Diagram . Context Diagram adalah bagian dari Data Flow Diagram (DF) yang berfungsi memetakan model lingkungan, yang dipresentasikan dengan lingkaran tunggal yang mewakili keseluruhan sistem. CD menyoroti sejumlah karakteristik penting sistem, yaitu :

1. Kelompok pemakai, organisasi atau sistem lain dimana sistem melakukan
    

2. Komunikasi (sebagai terminator).
    

3. Data masuk, yaitu data yang diterima sistem dari lingkungan dan harus diproses dengan cara tertentu.
    

4. Data keluar, yaitu data yang dihasilkan sistem dan diberikan ke dunia luar.
    

5. Penyimpanan data (storage), yaitu digunakan secara bersama antara sistem dengan terminator. Data ini dapat dibuat oleh sistem dan digunakan oleh lingkungan atau sebaliknya dibuat oleh lingkungan dan digunakan oleh sistem. Hal ini berarti pembuatan simbol data storage dalam CD dibenarkan, dengan syarat simbol tersebut merupakan bagian dari dunia diluar sistem. Batasan, antara sistem dan lingkungan.

Simbol yang digunakan dalam Context Diagram (CD), antara lain :

1. Persegi panjang (terminator) Untuk berkomunikasi langsung dengan sistem melalui aliran data antara terminator tidak diperbolehkan komunikasi langsung.
    

2. Lingkaran Untuk menunjukkan adanya kegiatian proses dalam sistem.

Aturan-aturan Data Flow Diagram Context (CD) :

1. Bila terdapat terminator yang mempunyai banyak masukan dan keluaran,diperbolehkan untuk digambarkan lebih dari satu kali sehingga mencegah penggambaran yang terlalu rumit, dengan ditandai secara khusus untuk menjelaskan bahwa terminator yang dimaksud adalah identik.
    

2. Tanda dapat berupa asterisk (*) atau tanda (#).
    

3. Bila terminator mewakili individu (personil) sebaiknya diwakili oleh peran yang dimainkan personil tersebut. Alasannya adalah : personil yang  berfungsi untuk melakukan itu dapat berganti, sedangkan CD harus tetap akurat walaupun personil berganti dan mungkin seorang personil dapat memiliki lebih dari satu tugas (peran).
    

4. Karena model ini membedakan sumber (resources) dan pelaku (handler).Dimana pelaku adalah mekanisme, perangkat, atau media fisik yang mentransformasikan data ke/dari sistem, sehingga pelaku tidak perlu digambarkan.
    

5. Aliran dalam CD memodelkan masukkan ke sistem dan keluaran dari sistem, seperti halnya sinyal kontrol yang diterima atau dibuat sistem.Aliran data hanya digambarkan jika diperlukan untuk mendeteksi kejadian dalam lingkungan dimana sistem harus memberikan respon atau membutuhkan data untuk menghasilkan respon. Selain itu aliran data dibutuhkan untuk menggambarkan transportasi antara sistem dan terminator. Dengan kata lain aliran data digambarkan jika data tersebut diperlukan untuk menghasilkan respon pada kejadian tertentu

Dalam hal ini seharusnya menggambar dengan asumsi bahwa masukan disebabkan dan diinisiasi oleh terminator, sedangkan keluaran disebabkan dan  diinisiasi oleh sistem. Hal itu dilakukan dengan mencegah interaksi yang tidak perlu (extraneous prompts) yang berorientasi pada implementasi masukan keluaran, dan mengkonsentrasikan pemodelan pada aliran data yang esensial saja.

CD dimulai dengan penggambaran terminator, aliran data, aliran kontrol, penyimpanan, dan proses tunggal yang mempresentasikan keseluruhan sistem. Bagian termudah adalah menetapkan proses yang hanya terdiri dari satu lingkaran dan diberi nama yang mewakili sistem. Nama harus dapat menjelaskan proses.

Langkah yang dapat membantu dalam menggambarkan Data Flow Diagram Context (CD) :

1. Identifikasikan seluruh informasi yang dibutuhkan.

2. Identifikasikan seluruh data yang dibutuhkan proses/informasi.

3. Identifikasikan seluruh tujuan setiap informasi bagi penggunanya.

4. Identifikasikan seluruh sumber data yang dibutuhkan proses/informasi

Contoh : 

Tabel 2.1 : Inventarisasi data, informasi, sumber data, tujuan informasi

Contoh untuk penerapan Data Flow Diagram Context (CD):

Gambar 2.1 : Context Diagram Sistem Informasi Sanggar Tari

Demikian yang bisa saya sampaikan , sekian dan Terimakasih :) 

Sumber : http://vanrpl.blogspot.com/2014/03/3-context-diagram.html

MODEL PENGEMBANGAN PERANGKAT LUNAK

Bismillahirrahmanirrahim

Assalamualaikum Wr.Wb

Hello , ketemu lagi dengan saya.. Kali ini saya akan membahas 3 Model Pengembangan Perangkat lunak, Yaitu: Model Sekuensial Linier , Model Prototype , dan Model Rapid Application Development (RAD).

1. Model Sekuensial Linier

Model sekuensial linear disebut juga model waterfall atau air terjun.  Model ini peertama kali muncul pada tahun1970 yang diperkenalkan oleh WinstonW.Royce. walaupun sudah dikenal dalam waktu yang lama dan sering di anggap kuno tetapi model ini paling banyak dipakai dalam industri perangkat lunak .

Model sekuensial linear berisi rangkaian proses yang disajikan secara terpisah, yaitu analisiskebutuhan,perancangan,pemgkodean,pemgujian, seta implementasi dan pemeliharaan. Setelah setiap proses dilakukan, proses tersebut ditutup dan pengembangan dilanjutkan pada proses berikutnya.

Untuk mengatasi kekurangna-kekurangan tersebut, dibuatlah model sekuensial linear yang dimodifikasis. Keunggulan model ini dibandingkan model sekuensial linear biasa adalah model ini memungkinkan tahap-tahap yang telah dilalui ditinjau kembali sehinnga jika ternyata terjadi  kesalahan atau kekurangan dalam menentukan kebutuhan di tahap awal, bisa dilakukan perbaikan atau peambahan lagi.

Model sekuensial linier melingkupi aktivitas – aktivitas sebagai berikut :

1. Rekayasa dan pemodelan sistem/informasi

Karena sistem merupakan bagian dari sebuah sistem yang lebih besar, kerja dimulai dengan membangun syarat dari semua elemen sistem dan mengalokasikan beberapa subset dari kebutuhan ke software tersebut. Pandangan sistem ini penting ketika software harus berhubungan dengan elemen-elemen yang lain seperti software, manusia, dan database. Rekayasa dan anasisis system menyangkut pengumpulan kebutuhan pada tingkat sistem dengan sejumlah kecil analisis serta disain tingkat puncak. Rekayasa informasi mancakup juga pengumpulan kebutuhan pada tingkat bisnis strategis dan tingkat area bisnis.

2. Analisis kebutuhan Software

Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khusunya pada software. Untuk memahami sifat program yang dibangun, analis harus memahami domain informasi, tingkah laku, unjuk kerja, dan interface yang diperlukan. Kebutuhan baik untuk sistem maupun software didokumentasikan dan dilihat lagi dengan pelanggan.

3. Desain

Desain software sebenarnya adalah proses multi langkah yang berfokus pada empat atribut sebuah program yang berbeda struktur data, arsitektur software, representasi interface, dan detail (algoritma) prosedural. Proses desain menterjemahkan syarat/kebutuhan ke dalam sebuah representasi software yang dapat diperkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi software.

4. Generasi Kode

Desain harus diterjemahkan kedalam bentuk mesin yang bisa dibaca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.

5. Pengujian

Sekali program dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika internal software, memastikan bahwa semua pernyataan sudah diuji, dan pada eksternal fungsional, yaitu mengarahkan pengujian untuk menemukan kesalahan – kesalahan dan memastikan bahwa input yang dibatasi akan memberikan hasil aktual yang sesuai dengan hasil yang dibutuhkan.

6. Pemeliharaan

Software akan mengalami perubahan setelah disampaikan kepada pelanggan (perkecualian yang mungkin adalah software yangdilekatkan). Perubahan akan terjadi karena kesalahan – kesalahan ditentukan, karena software harus disesuaikan untuk mengakomodasi perubahan – perubahan di dalam lingkungan eksternalnya (contohnya perubahan yang dibutuhkan sebagai akibat dari perangkat peripheral atau sistem operasi yang baru), atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja. Pemeliharaan software mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang baru lagi.

KEKURANGAN MODEL SEKUENSIAL LINEAR

Masalah yang kadang terjadi ketika model sekuensial linier diaplikasikan adalah :

1. Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model. Meskipun model linier bisa mengakomodasi iterasi, model ini melakukannya dengan cara tidak langsung. Sebagai hasilnya, perubahan – perubahan dapat menyebabkan keraguan pada saat tim proyek berjalan.

2. Kadang – kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya secara eksplisit. Model linier sekuensial memerlukan halini dan mengalami kesulitan untuk mengakomodasi ketidakpastiannatural yang ada pada bagian awal beberapa proyek.

3. Pelanggan harus bersifat sabar. Sebuah versi kerja dari program – program kerja itu tidak akan diperoleh sampai akhir waktu proyek dilalui. Sebuah kesalahan besar, jika tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bisa menjadi petaka

4. Pengembang sering melakukan penundan yang tidak perlu. Sifat alami dari siklus kehidupan klasik membawa kepada blocking state di mana banyak anggota tim proyek harus menunggu tim yang lain untuk melengkapi tugas yang saling memiliki ketergantungan. Blocking state cenderung menjadi lebih lazim pada awal dan akhir sebuah proses sekuensial linier

KELEBIHAN MODEL SEKUENSIL LINIER

1. Software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik.

2. Document pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.

2. Model Prototype

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

Prototyping model dapat diklasifikasikan menjadi beberapa tipe seperti terlihat pada gambar 2.4. 

• 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 dikatakan merupakan tahap-tahap yang dipercepat. Strategiutama dalam prototyping adalah kerjakan yang mudah terlebih dahulu, dan sampaikan hasil kepada pengguna sesegera mungkin. Harris (2003) membagi prototyping dalam enam tahapan seperti terlihat pada gambar 2.5. 

Tahapan-tahapan secara ringkas dapat dijelaskan sebagai berikut: 

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

3. Model Rapid Application Development (RAD)

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.^[1] Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final

Penerapan

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.

Kelemahan

Beberapa hal (kelebhan dan kekurangan) yang perlu diperhatikan dalam implementasi pengembangan menggunakan model RAD :

1. Model RAD memerlukan sumber daya yang cukup besar, terutama untuk proyek dengan skala besar.
2. Model ini cocok untuk proyek dengan skala besar.
3. Model RAD memerlukan komitmen yang kuat antara pengembang dan pemesssan, bahkan keduanya bisa tergabung dalam 1 tim
4. kinerja dari perangkat lunak yang dihasilkan dapat menjadi masalah manakala kebutuhan-kebutuhan diawal proses tidak dapat dimodulkan, sehingga pendekatan dengan model ini kurang bagus.
5. sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini.
6. penghalusan dan penggabungan dari beberapa tim di akhir proses sangat diperlukan dan ini memerlukan kerja keras.
7. proyek bisa gagal karena waktu yang disepakati tidak dipenuhi
8. risiko teknis yang tinggi juga kurang cocok untuk model ini.

KELEBIHAN

1. Fleksibilitas yang lebih besar

2. Sangat mengurangi manual coding

3. Peningkatan keterlibatan pengguna

4. Mungkin lebih sedikit cacat

5. Mungkin dikurangi biaya

6. Singkat siklus pengembangan

Demikian yang bisa saya jelaskan, mohon maaf apabila ada salah-salah kata. Terimakasih :)

Sumber : 

http://www.varia.web.id/2013/06/prototyping-model.html

http://id.wikipedia.org/wiki/Rapid_application_development

http://vanrpl.blogspot.com/2014/02/2-model-sekuensial-linier-prototype-dan.html