Use Case Diagram (UCD)

Pengertian USE CASE

Use Case merupakan sebuah teknik yang digunakan dalam pengembangan sebuah software atau sistem informasi untuk menangkap kebutuhan fungsional dari sistem yang bersangkutan, Use Case menjelaskan interaksi yang terjadi antara ‘aktor’ – inisiator dari interaksi sistem itu sendiri dengan sistem yang ada, sebuah Use Case direpresentasikan dengan urutan langkah yang sederhana.

Deskripsi singkat tentang USE CASE

Perilaku sistem adalah bagaimana sistem beraksi dan bereaksi. Perilaku ini merupakan aktifitas sistem yang bisa dilihat dari luar dan bisa diuji.

Perilaku sistem ini dicapture di dalam USE CASE. USE CASE sendiri mendeskripsikan sistem, lingkungan sistem, serta hubungan antara sistem dengan lingkungannya.

Deskripsi dari sekumpulan aksi sekuensial yang ditampilkan sistem yang menghasilkan yang tampak dari nilai ke actor khusus. Use Case digunakan untuk menyusun behavioral things dalam sebuah model. Use case direalisasikan dengan sebuah collaboration. Secara gambar, sebuah use case digambarkan dengan sebuah ellips dengan garis penuh, biasanya termasuk hanya namanya, seperti gambar berikut :

Representasi atau model yang digunakan dalam Rekayasa Perangkat Lunak untuk menggambarkan fungsional requirement suatu sistem. Sekelompok skenario pengguna yang menggambarkan alur penggunaan sistem. Setiap skenario digambarkan dari sudut pandang “aktor”, seseorang atau piranti yang berinteraksi dengan perangkat lunak dalam berbagai cara. Suatu Use Case adalah suatu sekuensial aksi yang dilakukan oleh sistem, yang akan secara bersama-sama, memproduksi hasil yang dibutuhkan oleh pengguna sistem. Use Case mendefinisikan alur proses sepanjang sistem berbasis pada kegunaan sebagaimana yang biasa dilakukan (secara manual).

Contoh :

Use case pada Rumah sakit

Kegunaan Use Case

 untuk menspesifikasikan konteks sistem, menggambarkan kebutuhan sistem, memvalidasikan arsitektur sistem, menjalankan implementasi dan meng-generate test case.

Include

Keterhubungan secara include antar use case menunjukkan bahwa use case asal secara eksplisit memasukkan perilaku dari use case lain yang ditunjuk oleh use case tersebut. Included use case tidak pernah berdiri sendiri, tetapi hanya merupakan bagian dari beberapa use case yang lebih besar yang diikutinya. Keterhubungan use case secara include pada dasarnya merupakan sebuah contoh dari pendelegasian - sekumpulan dari tanggung jawab sebuah sistem diambil dan ditangkap di dalam satu tempat (included use case) - kemudian bagian lainnya dari sistem (use case yang lain) memasukkan kumpulan tanggung jawab yang baru setiap saat mereka memerlukan fungsi-fungsi use case tersebut.

Extend

Keterhubungan use case secara extend menunjukkan bahwa use case yang ditunjuk merupakan perluasan perilaku dari use case asal. Use case asal dapat berdiri sendiri, tetapi untuk kondisi tertentu perilaku use case tersebut dapat diperluas oleh perilaku dari use case lain. Hubungan perluasan digunakan untuk memodelkan bagian dari use case yang dapat dilihat oleh user sebagai perilaku yang dapat dipilih dari sistem. Hubungan perluasan juga dapat digunakan untuk memodelkan sub aliran yang terpisah-pisah yang hanya dapat dijalankan dalam kondisi tertentu. Pada akhirnya, hubungan perluasan use case untuk memodelkan beberapa aliran yang dapat dimasukkan dalam titik tertentu.

Struktur Data dan Struktur Table

     Pada Kesempatan kali ini saya akan melanjutkan pembahasan tentang rancangan data tabel yang akan di gunakan dalam aplikasi pemninajam dvd. Sebelum masuk dalam perangan table apa yang kita butuhkan marilah kita flashback kebelakang melihat proses atau skema dari proses peminjaman dvd tersebut. Berikut aluratau proses bisnis untuk aplikasi ini.“pelanggan datang kemudian melihat-lihat daftar film dvd yang tersedia atau yang terupdate,setelah pelanggan menemukan dvd yang akan dipinjam pelanggan menuju ke operator toko untuk proses peminjaman,setelah berhadapan dengan operator toko pelanggan akan ditanyakan oleh operator film apa yang akan di pinjam,pelanggan menyebutkan nama film ,lalu operator mencari filmnya kemudian operator menanyakan kembali kepada pelanggan sudah punya kartu membernya belum ?,jika belum pelanggan diwajibkan untuk registrasi terlebih dahulu,jika sudah maka langsung diproses ke pembayaran, operator akan bertanya berapa hari akan meminjam dvd film tersebut, setelah operator mendapatkan jawabnnya,lalu operator memberitahu nominal biaya yang harus dikeluarkan sesuai dengan lama peminjaman,kemudian pelanggan membayarnya ,operator memberikan dvdnya, pelanggan keluar toko dengan membawa dvd hasil peminjamannya. Kemudian operator membuat laporan peminjaman dan laporan diberikan kepada pemilik toko”Dari cerita diatas dapat kita gambarkan dalam model sketsa agar lebih terbuka atau lebih ringkas sehingga kita dapat mengetahui lebih jelas.

 berikut model sketsanya :

Pada saat ini setelah melihat model sketsa saya baru menyimpulkan bahwa aplikasi ini membutuhkan 6 tabel sebagai database penunjang aplikasi yaitu :
Tabel Login
Tabel DVD
Tabel Anggota
Tabel Peminjaman
Tabel Pendaftaran
Tabel Laporan

berikut entitas-entitas pada setiap tabel 

Pengertian ERD

ERD (Entity Relationship Diagram) 

Entity Relationship Diagram (ERD) adalah menyediakan cara untuk mendeskripsikan perancangan basis data pada peringkat logika.

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

ERD merupakan suatu model untuk menjelaskan hubungan antar data dalam basis data berdasarkan objek-objek dasar data yang mempunyai hubungan antar relasi.ERD untuk memodelkan struktur data dan hubungan antar data, untuk menggambarkannya digunakan beberapa notasi dan simbol. Pada dasarnya ada tiga simbol yang digunakan, yaitu : 

> Entri

Entiti merupakan objek yang mewakili sesuatu yang nyata dan dapat dibedakan dari sesuatu yang lain. Simbol dari entiti ini biasanya digambarkan dengan persegi panjang. 

> Hubugan Relasi 

Hubungan antara sejumlah entitas yang berasal dari himpunan entitas yang berbeda. Relasi dapat digambarkan sebagai berikut :

Relasi yang terjadi diantara dua himpunan entitas (misalnya A dan B) dalam satu basis data yaitu: 

• Satu ke satu (One to one) Hubungan relasi satu ke satu yaitu setiap entitas pada himpunan entitas A berhubungan paling banyak dengan satu entitas pada himpunan entitas B.
• Satu ke banyak (One to many)
  Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B, tetapi setiap entitas pada entitas B dapat berhubungan dengan satu entitas pada himpunan entitas A.
• Banyak ke banyak (Many to many)
  Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B.

> Atribut 

Setiap entitas pasti mempunyai elemen yang disebut atribut yang berfungsi untuk mendeskripsikan karakteristik dari entitas tersebut. Isi dari atribut mempunyai sesuatu yang dapat mengidentifikasikan isi elemen satu dengan yang lain. Gambar atribut diwakili oleh simbol elips.

Contoh ERD 

Derajat Relationship

Terdapat 3 macam derajat dari relationship, yaitu : 

Unary Degree (derajat satu)

Bila satu entity mempunyai relasi terhadap dirinya sendiri.  Digambarkan sebagai berikut :

Binary degree (derajat dua)

Bila satu relasi menghubugkan dua entity, digambarkan sebagai berikut :

Ternary degree (derajat tiga)

Bila satu entity menghubungkan lebih dari dua entity. Digambarkan sebagai berikut :

Simbol-simbol  ER-Diagram

Contoh Penggambaran Diagram ERD

DFD Level 1

Data Flow Diagram (DFD) adalah alat pembuatan model yang memungkinkan profesional sistem untuk menggambarkan sistem sebagai suatu jaringan proses fungsional yang dihubungkan satu sama lain dengan alur data, baik secara manual maupun komputerisasi. DFD ini sering disebut juga dengan nama Bubble chart, Bubble diagram, model proses, diagram alur kerja, atau model fungsi.
DFD ini adalah salah satu alat pembuatan model yang sering digunakan, khususnya bila fungsi-fungsi sistem merupakan bagian yang lebih penting dan kompleks dari pada data yang dimanipulasi oleh sistem. Dengan kata lain, DFD adalah alat pembuatan model yang memberikan penekanan hanya pada fungsi sistem.
DFD ini merupakan alat perancangan sistem yang berorientasi pada alur data dengan konsep dekomposisi dapat digunakan untuk penggambaran analisa maupun rancangan sistem yang mudah dikomunikasikan oleh profesional sistem kepada pemakai maupun pembuat program.
Didalam DFD terdapat 3 level, yaitu :

Diagram Konteks : menggambarkan satu lingkaran besar yang dapat mewakili seluruh proses yang terdapat di dalam suatu sistem. Merupakan tingkatan tertinggi dalam DFD dan biasanya diberi nomor 0 (nol). Semua entitas eksternal yang ditunjukkan pada diagram konteks berikut aliran-aliran data utama menuju dan dari sistem. Diagram ini sama sekali tidak memuat penyimpanan data dan tampak sederhana untuk diciptakan.
Diagram Nol (diagram level-1) : merupakan satu lingkaran besar yang mewakili lingkaran-lingkaran kecil yang ada di dalamnya. Merupakan pemecahan dari diagram Konteks ke diagram Nol. di dalam diagram ini memuat penyimpanan data.
Diagram Rinci : merupakan diagram yang menguraikan proses apa yang ada dalam diagram Nol.




sumber : 
http://tember-lio.blogspot.com/2012/10/pengertian-dfd-gambar.html
http://7enius.wordpress.com/2012/03/11/pengertian-fungsi-dan-contoh-dari-data-flow-diagramdfd/

REKAYASA PERANGKAT LUNAK (Diagram konteks)

Diagram Konteks

Diagram konteks adalah diagram yang menggambarkan sistem secara umum. Diagram konteks merupakan alat bantu perancangan yang merupakan bagian dari Data Flow Diagram (DFD) yang memperlihatkan bagian-bagian atau entitas-entitas yang terlibat di dalam sistem dan bagaimana entitas-entitas tersebut berhubungan. Diagram konteks juga merupakan suatu pandangan, yang mencakup masukan-masukan dasar, sistem umum, dan keluaran. Diagram ini memperlihatkan pengalihan data di dalam sistem dan melebarkan konseptualitas sistem yang memungkinkan. Diagram ini adalah tingkatan tertinggi dalam aliran data dan hanya memuat satu proses secara keseluruhan. Gambar di bawah ini memperlihatkan bagaimana sistem yang akan diterapkan.


Gambar Diagram Konteks

pemesanan Pemesanan Barang Dagang akan memproses data-data yang telah masuk yaitu, dari bagian gudang memberikan data barang, supplier memberikan data supplier, konsumen memberikan data konsumen serta data permintaan, setelah diproses  menghasilkan daftar  pemesanan yang akan diberikan kepada supplier, daftar barang yang telah diterima dan daftar permintaan diberikan kepada bagian gudang. Kemudian informasi yang diterima oleh pimpinan berupa laporan-laporan yaitu laporan barang, laporan supplier, laporan konsumen, laporan daftar permintaan dan laporan daftar.

Model Pengembangan Rekayasa Perangkat Lunak

MODEL SEKUENSIAL LINIER

Model sekuensial linier untuk software engineering yang disebut dengan siklus kehidupan klasik atau model air terjun. Model ini mengusulkan sebuah pendekatan kepada perkembangan software yang sistematik dan sekuensial. Dimodelkan setelah siklus rekysa konvensional, model sekuensial linier melingkupi aktivitas-aktivitas sebagai berikut   :

1. Feasibility

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 anaslisis sistem menyangkut pengumpulan kebutuhan pada tingkat sistem dengan sejumlah kecil analisis serta disain tingkat puncak. Rekayasa informasi mencakup 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. Implementasi

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.

MODEL PROTOTIPE

Prototype adalah sebuah Javascript Framework yang dibuat untuk lebih memudahkan proses dalam membangun aplikasi berbasis web. Paradigma dari metode prototyping adalah sistem informasi yang menggambarkan hal-hal penting dari sistem informasi yang akan datang. Prototipe sistem informasi bukanlah merupakan sesuatu yang lengkap, tetapi sesuatu yang harus dimodifikasi kembali, dikembangkan, ditambahkan atau digabungkan dengan sistem informasi yang lain bila perlu. Model ini digunakan jika customer tidak menjelaskan detail kebutuhan input, proses atau output, sehingga developer tidak dapat memastikan algoritma yang akan dipakai, kesesuaian sistem operasi atau bentuk user interface. Prototyping model dimulai dengan mendengarkan kebutuhan user. Engineer dan customer bertemu dan menentukan semua tujuan software dan menentukan kebutuhan-kebutuhan. Developer kemudian membangun prototype dan user menguji coba prototype untuk memberikan feedback. Prototype dapat dijalankan sebagai sistem yang pertama. User bisa mendapatkan pengertian dari sistem yang sesungguhnya dan developer dapat membangun sistem dengan segera. Kekurangan : kontrak akan merugikan, dirugikan oleh keinginan customer yang meminta penambahan-penambahan. Kelebihan : akan mengurangi waktu pembuatan program, kebutuhan customer akan lebih terpenuhi dengan baik, jika kebutuhannya belum jelas, maka dengan prototype akan lebih menguntungkan.

 Metode pengembangan perangkat lunak ini dimulai dengan pengumpulan kebutuhan. Pendekatan prototyping model digunakan jika pemakai hanya mendefenisikan secara umum dari perangkat lunak tanpa merinci kebutuhan input, pemrosesan dan outputnya, sementara pengembang tidak begitu yakin akan efisiensi algoritma, adaptasi sistem operasi, atau bentuk antarmuka manusia-mesin yang harus diambil. 

2. Kelebihan dan Kekurangan

Keunggulan prototyping adalah :

1)     Adanya komunikasi yang baik antara pengembang dan pelanggan.

2)     Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan.

3)     Pelanggan berperan aktif dalam pengembangan sistem.

4)     Lebih menghemat waktu dalam pengembangan sistem.

5)     Penerapan menjadi lebih  mudah karena pemakai mengetahui apa yang diharapkannya

Sedangkan kelemahan prototyping adalah :

1)     Pelanggan tidak melihat bahwa perangkat lunak belum mencerminkan kualitas perangkat lunak secara keseluruhan dan belum memikirkan peneliharaan dalam jangka waktu yang lama.

2)     Pengembang biasanya ingin cepat menyelesaikan proyek sehingga menggunakan algoritma dan bahasa pemrograman sederhana.

3)     Hubungan pelanggan dengan komputer mungkin tidak menggambarkan teknik perancangan yang baik.

3.  Bentuk Prototipe

Berdasarkan karakteristiknya prototipe sebuah sistem dapat berupa low fidelity dan high fidelity. Fidelity mengacu kepada tingkat kerincian sebuah sistem (Walker et al, 2003).

Low fidelity prototype tidak terlalu rinci menggambarkan sistem. Karakteristik dari low fidelity prototype adalah mempunyai fungsi atau interaksi yang terbatas, lebih menggambarkan kosep perancangan dan layout dibandingkan dengan model interaksi, tidak memperlihatkan secara rinci operasional sistem, mendemostrasikan secara umum feel and look dari antarmuka pengguna dan hanya menggambarkan konsep pendekatan secara umum (Walker et al, 2003).

High fidelity protoype lebih rinci menggambarkan sistem. Prototipe ini mempunyai interaksi penuh dengan pengguna dimana pengguna dapat memasukkan data dan berinteraksi dengan dengan sistem, mewakili fungsi-fungsi inti sehingga dapat mensimulasikan sebagian besar fungsi dari sistem akhir dan mempunyai penampilan yang sangat mirip dengan produk sebenarnya (Walker et al, 2003).

Fitur yang akan diimplementasikan pada prototipe sistem dapat dibatasi dengan teknik vertikal atau horizontal. Vertical prototype mengandung fungsi yang detail tetapi hanya untuk beberapa fitur terpilih, tidak pada keseluruhan fitur sistem. Horizontal prototype mencakup seluruh fitur antarmuka pengguna namun tanpa fungsi pokok hanya berupa simulasi dan belum dapat digunakan untuk melakukan pekerjaan yang sebenarnya (Walker et al, 2003).

4.     Proses Pembuatan Prototipe

Proses pembuatan prototipe merupakan proses yang interaktif dan berulang-ulang yang menggabungkan langkah-langkah siklus pengembangan tradisional. Prototipe dievaluasi beberapa kali sebelum pemakai akhir menyatakan protipe tersebut diterima

Tahapan-tahapan Prototyping

1. Pengumpulan kebutuhan : Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.
2.  Membangun prototyping : Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output)
3. Evaluasi prototyping : Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. Jika sudah sesuai maka langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulangu langkah 1, 2 , dan 3.
4. Mengkodekan sistem : Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai
5. Menguji sistem : Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain
6. Evaluasi Sistem : Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Jika ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5.
7. Menggunakan sistem : Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.\

MODEL RAD 

Pengertian 

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

Fase-fase dalam RAD

1. Bussines Modelling. Aliran informasi diantara funsi-fungsi bisnis dimodelkan dengan suatu cara untuk

menjawab pertanyaan-pertanyaan berikut: Informasi apa yg mengendalikan proses bisnis? Informasi apa yg dimunculkan? Siapa yg memunculkan? Ke mana informasi itu pergi? Siapa yg memprosesnya?

2. Data Modelling Aliran informasi yg di definisikan sebagai bagian dari fase bussiness modelling di

saring ke dalam serangkaian objek data yg dibutuhkan untuk menopang bisnis tersebut. Karakteristik (disebut atribut) masing-masing objek diidentifikasi dan hubungan antara objek-objek tersebut didefinisikan.

3. Prosess Modeling Aliran informasi yg didefinisikan di dalam fase data modelling ditransformasikan untuk mencapai aliran informasi yg perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan digunakan 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 ke-tiga yg konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program yg ada (pada saat memungkinkan) atau menciptakan komponen yg 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 diuji dan semua interface harus dilatih secara penuh.

Rencana Kebutuhan (Requirement Planning)

Pada tahap ini, user dan analyst melakukan semacam pertemuan untuk melakukan identifikasi tujuan dari aplikasi atau sistem dan melakukan identifikasi kebutuhan informasi untuk mencapai tujuan. Pada tahap ini hal terpenting adalah adanya keterlibatan dari kedua belah pihak, bukan hanya sekedar persetujuan akan proposal yang sudah dibuat. Untuk lebih jauh lagi, keterlibatan user bukan hanya dari satu tingkatan pada suatu organisasi, melainkan beberapa tingkatan organisasi sehingga informasi yang dibutuhkan untuk masingmasing user dapat terpenuhi dengan baik. Di samping itu, dapat juga melakukan koordinasi dengan Chief Information Office (CIO) atau bagian perencana strategis terutama untuk mengembangkan suatu aplikasi E-commerce berbasis Web untuk mendapatkan informasi yang lebih detail akan tujuan dari suatu organisasi. Pertemuan semacam ini seringkali disebut Joint Aplication Development.

Proses Desain (Design Workshop)

Pada tahap ini adalah melakukan proses desain dan melakukan perbaikan-perbaikan apabila masih terdapat ketidaksesuaian desain antara user dan analyst. Untuk tahap ini maka keaktifan user yang terlibat sangat menentukan untuk mencapai tujuan, karena user bisa langsung memberikan komentar apabila terdapat ketidaksesuaian pada desain. Biasanya, user dan analyst berkumpul menjadi satu dan duduk di meja melingkar dimana masing-masing orang bisa melihat satu dengan yang lain tanpa ada halangan.

Apabila memungkinkan, maka masingmasing user diberikan satu komputer yang terhubung satu dengan yang lain, sehingga masing-masing bisa melihat desain yang dibuat dan langsung memberikan komentar. Hal ini sering kali disebut dengan Group Decision Support System (GDSS). Pada beberapa kasus, GDSS ini merupakan suatu langkah yang ideal, karena user dan analyst dapat menyetujui desain yang dibuat untuk kemudian dilanjutkan oleh programmer dalam pembuatan prototype dari aplikasi yang dimaksud dengan langsung menampilkan kepada user hasilnya dengan cepat. Pada tahap desain ini membutuhkan waktu beberapa hari, akan tetapi bisa semakin lebih lama, tergantung dari besar kecilnya sistem yang dibuat. Pada selang waktu tersebut, user bisa memberikan tanggapan akan sistem yang sudah dikembangkan untuk selanjutnya dilakukan perbaikan-perbaikan. Dengan demikian proses pengembangan suatu sistem membutuhkan waktu yang cepat.

Implementasi (Implementation)

Setelah desain dari sistem yang akan dibuat sudah disetujui baik itu oleh user dan Analyst, maka pada tahap ini programmer mengembangkan desain menjadi suatu program. Setelah program selesai baik itu sebagian maupun secara keseluruhan, maka dilakukan proses pengujian terhadap program tersebut apakah terdapat kesalahan atau tidak sebelum diaplikasikan pada suatu organisasi. Pada saat ini maka user bisa memberikan tanggapan akan sistem yang sudah dibuat serta persetujuan mengenai sistem tersebut. Adapun hal terpenting adalah bahwa keterlibatan user sangat diperlukan supaya sistem yang dikembangkan dapat memberikan kepuasan kepada user, dan di samping itu, sistem yang lama tidak perlu dijalankan secara paralel dengan sistem yang baru. 

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. sisttem 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 tekns yang tinggi juga kurang cocok untuk model ini. 

pengertian Rekayasa perangkat lunak

Nama : Deni Herdiansyah

Nim   : TI 111023

Jurusan teknik informatika

Rekayasa Perangkat Lunak adalah pengubahan perangkat lunak itu sendiri guna mengembangkan, memelihara, dan membangun kembali dengan menggunakan prinsip reakayasa untuk menghasilkan perangkat lunak yang dapat bekerja lebih efisien dan efektif untuk pengguna.

http://kityyulia.blogspot.com/2013/02/pengertian-dan-tujuan-rpl.html