Use Case Diagram

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 (Entity Relationship Diagram)

ERD

(Entity Relationship Diagram) 

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

• Sistem adalah kumpulan elemen yang setiap elemen memiliki fungsi masing-masing dan secara bersama-sama mencapai tujuan dari sistem tersebut.
• ‘Kebersama-sama’-an 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

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 :

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

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

• Hubungan / 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: 

1. 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.
2. 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.
3. Banyak ke banyak (Many to many) Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B.

Contoh Gambar 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

PENGERTIAN DFD & GAMBAR

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 sistem yang sedang berjalan logis

Andri Kristanto ( 2003 : 55 ), menjelaskan : “Data flow diagram adalah suatu model logika data atau proses yang dibuat untuk menggambarkan dari mana asal data dan kemana tujuan data yang keluar dari sistem, dimana data tersimpan, proses apa yang menghasilkan data tersebut dan interaksi antara data tersimpan dan proses yang dikenakan pada data tersebut”.

Menurut Tata Sutabri (2003 : 163), “Data flow diagram adalah suatu network yangn menggambarkannnya di suatu sistem automat / komputerisasi, manualisasi atau gabungan dari keduanya, yang penggambarasusun dalam bentuk kumpulan komponen sistem yang saling berhubungan sesuai dengan aturan.

gambar DFD Level 1

sumber : http://tember-lio.blogspot.com/2012/10/pengertian-dfd-gambar.html

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

MODEL PENGEMBANGAN PERANGKAT LUNAk

 Model Pengembangan Sekuensial Linier (Waterfall Model)

Metode pengembangan sistem sekuensial linier atau yang sering disebut juga dengan siklus kehidupan klasik atau model air terjun (waterfall model) memberikan sebuah pendekatan pengembangan sistem yang sistematik dan sekuensial, dimulai pada fase perencanaan sistem, analisis, desain, kode, pengujian, dan pemeliharaan. 

1. Perencanaan atau rekayasa dan pemodelan siste Pada fase ini dilakukan identifikasi sistem, studi kebutuhan pengguna, dan studi kelayakan sistem baik    secara teknis maupun teknologi serta penjadwalan pengembangan sistem.
2. Analisis kebutuhan perangkat lunak Pada fase ini pengumpulan kebutuhan diintensifkan dan difokuskan pada sistem yang akan dibangun meliputi identifikasi domain informasi, tingkah laku sistem, unjuk kerja, dan antarmuka sistem. Kebutuhan untuk sistem didokumentasikan dan dikonsultasikan lagi dengan pengguna.
3. Desain Fase ini difokuskan pada proses desain struktur data, arsitektur sistem, representasi interface, dan algoritma program.
4. Kode Setelah proses desain selesai maka hasilnya harus diterjemahkan kedalam bentuk program komputer yang kemudian menghasilkan suatu sistem.
5. PengujianPengujian dilakukan untuk menemukan kesalahan-kesalahan yang mungkin terjadi pada proses pengkodean serta memastikan bahwa input yang dibatasi memberikan hasil yang sesuai dengan kebutuhan.
6. Pemeliharaan Proses ini dilakukan setelah sistem yang dihasilkan disampaikan kepada pengguna, terutama jika sistem mengalami permasalahan yang belum ditemukan pada saat proses pengujian, permasalahan ini dapat berkaitan dengan permintaan pengguna yang membutuhkan perkembangan fungsional sistem maupun adanya penyesuaian dengan lingkungan eksternal seperti adanya perubahan periperal atau perubahan sistem operasi. Fase pemeliharaan akan mengakibatkan pengembang mengaplikasikan lagi setiap fase pengembangan sistem mulai dari awal, namun tidak membuat sistem yang baru.

Kelebihan dan kekurangan sekuensial linear

KEKURANGAN MODEL SEKUENSIAL LINEAR 

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

•  software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik.
• Document pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.

Pengembangan 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. Cakupan aktivitas dari prototyping model terdiri dari

•  Mendefinisikan objektif secara keseluruhan dan mengidentifikasi kebutuhan yang sudah diketahui.
•  Melakukan perancangan secara cepat sebagai dasar untuk membuat prototype.
• Menguji coba dan mengevaluasi prototype dan kemudian melakukan penambahan dan perbaikan-perbaikan terhadap prototype yang sudah dibuat.

Empat langkah yang menjadi karakteristik metode Prototyping yaitu

1. Pemilihan fungsi Mengacu pada pemilahan fungsi yang harus ditampilkan oleh prototyping. Pemilahan harus selalu dilakukan berdasarkan pada tugas-tugas yang relevan yang sesuai dengan contoh kasus yang akan diperagakan
2. Penyusunan Sistem Informasi Bertujuan untuk memenuhi permintaan akan tersedianya prototype
3. Evaluasi
4. Penggunaan Selanjutnya 

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.

Jenis-jenis Prototyping

• Feasibility prototyping digunakan untuk menguji kelayakan dari teknologi yang akan digunakan untuk system informasi yang akan disusun.
• Requirement prototyping digunakan untuk mengetahui kebutuhan aktivitas bisnis user.
• Desain Prototyping - digunakan untuk mendorong perancangan system informasi yang akan digunakan.
• Implementation prototyping merupakan lanjytan dari rancangan protipe, prototype ini langsung disusun sebagai suatu system informasi yang akan digunakan.

Keunggulan dan Kelemahan Prototyping

Keunggulan Prototyping :

• End user dapat berpartisipasi aktif
• Penentuan kebutuhan lebih mudah diwujudkan
• Mempersingkat waktu pengembangan SI
• Adanya komunikasi yang baik antara pengembang dan pelanggan
• Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan
• Pelanggan berperan aktif dalam pengembangan sistem
• Lebih menghemat waktu dalam pengembangan sistem
• Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.

Kelemahan Prototyping :

• Proses analisis dan perancangan terlalu singkat
• Mengesampingkan alternatif pemecahan masalah
• Bisanya kurang fleksible dalam mengahadapi perubahan
• Prototype yang dihasilkan tidak selamanya mudah dirubah
• Prototype terlalu cepat selesai

Model Pengembangan RAD (RAPID APPLICATION DEVELOPMENT)

Model RAD adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik increment (bertingkat). RAD menekankan pada siklus pembangunan pendek/singkat/cepat. Waktu yang singkat adalah batasan yang penting untuk model ini.Model RAD ini merupakan sebuah adaptasi ”kecepatan tinggi” dari model waterfall dimana perkembangan cepat dicapai dengan menggunakan pendekatan kontruksi 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).

Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi

fase-fase sebagai berikut :

1. Business 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 di munculkan? Siapa yang memunculkannya? Ke mana informasi itu pergi? Siapa yang memprosesnya?

2. Data modeling

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

3. Proses modeling

Aliran informasi yang didefinisikan di dalam fase data modeling   ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data.

4. Application Generation

RAD mengasumsikan pemakaian teknik generasi ke empat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program yang ada (pada saat memungkinkan) atau menciptakan komponen yang bisa dipakai lagi (bila perlu). Pada semua kasus, alat-alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.

5. Testing dan turnover Karena proses RAD menekankan pada pemakaian kembali, banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi komponen baru harus di uji dan semua interface harus dilatih secara penuh.

 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.

Tahapan keseluruhan

Dengan berdasarkan pada tahapantahapan tersebut di atas maka proses utama pengembangan suatu sistem dengan menggunakan metode RAD adalah sebagai berikut :

- Pengembang membuat prototype berdasarkan kebutuhan-kebutuhan yang sudah didefinisikan sebelumnya

- Desainer melakukan penilaian terhadap prototype

- User melakukan uji coba pada prototype dan memberikan masukan mengenai kebutuhan-kebutuhan yang      kurang.

- User dan developer melakukan pertemuan untuk memberikan penilaian terhadap produk secara bersama-      sama, menyesuaikan kebutuhan serta memberikan komentar apabila diperlukan perubahan.

- Semua kebutuhan akan sistem dan perubahan-perubahan yang terjadi dilakukan proses “timeboxed”             dengan mempunyai 2 kemungkinan :

• Perubahan yang tidak dapat ditampung seperti yang sudah direncanakan harus dihilangkan.
• Jika diperlukan, kebutuhan-kebutuhan yang bersifat sekunder ditiadakan

Beberapa kelebihan dan kekurangan yang perlu diperhatikan dalam implementasi

pengembangan menggunakan model RAD :

1. Model RAD memerlukan sumber dara 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 pemessan,bahkan keduanya dapat     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 dapat 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. Resiko teknis yang tinggi juga kurang cocok untuk model ini.
9. Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.  
10. RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktivitas rapid-fire yang     diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika   komitmen tersebut tidak ada, proyek RAD akan gagal.    
11. Tidak cocok untuk proyek skala besar.
12. Proyek dapat gagal karena waktu yang disepakati tidak dipenuhi.
13. Sistem yang tidak dapat dimodularisasi tidak cocok untuk model ini.
14. Resiko teknis yang tinggi juga kurang cocok untuk model ini.

   

Sejarah dan pengertian Rekayasa Perangkat Lunak

Rekayasa perangkat lunak

 Rekayasa perangkat lunak telah berkembang sejak pertama kali diciptakan pada tahun 1940-an hingga kini. Fokus utama pengembangannya adalah untuk mengembangkan praktik dan teknologi untuk meningkatkan produktivitas para praktisi pengembang perangkat lunak dan kualitas aplikasi yang dapat digunakan oleh pemakai.

Istilah software engineering digunakan pertama kali pada akhir 1950-an dan awal 1960-an. Saat itu, masih terdapat debat tajam mengenai aspek engineering dari pengembangan perangkat lunak.
Pada tahun 1968 dan 1969, komite sains NATO mensponsori dua konferensi tentang rekayasa perangkat lunak, yang memberikan dampak kuat terhadap perkembangan rekayasa perangkat lunak. Banyak yang menganggap bahwa dua konferensi inilah yang menandai awal resmi profesi rekayasa perangkat lunak. jangan pernah menganggap kalau software itu akn menjadi yang terbaik karena itu adalah sebuah karya yang bersifat sementara.

1965 - 1985: krisis perangkat lunak

Pada tahun 1960-an hingga 1980-an, banyak masalah yang ditemukan para praktisi pengembangan perangkat lunak. Banyak projek yang gagal, hingga masa ini disebut sebagai krisis perangkat lunak. Kasus kegagalan pengembangan perangkat lunak terjadi mulai dari projek yang melebihi anggaran, hingga kasus yang mengakibatkan kerusakan fisik dan kematian. Salah satu kasus yang terkenal antara lain meledaknya roket Ariane akibat kegagalan perangkat lunak.

1985 - kini: tidak ada senjata pamungkas

Selama bertahun-tahun, para peneliti memfokuskan usahanya untuk menemukan teknik jitu untuk memecahkan masalah krisis perangkat lunak.
Berbagai teknik, metode, alat, proses diciptakan dan diklaim sebagai senjata pamungkas untuk memecahkan kasus ini. Mulai dari pemrograman terstruktur, pemrograman berorientasi object, perangkat pembantu pengembangan perangkat lunak (CASE tools), berbagai standar, UML hingga metode formal diagung-agungkan sebagai senjata pamungkas untuk menghasilkan software yang benar, sesuai anggaran dan tepat waktu.
Pada tahun 1987, Fred Brooks menulis artikel No Silver Bullet, yang berproposisi bahwa tidak ada satu teknologi atau praktik yang sanggup mencapai 10 kali lipat perbaikan dalam produktivitas pengembangan perangkat lunak dalam tempo 10 tahun.
Sebagian berpendapat, no silver bullet berarti profesi rekayasa perangkat lunak dianggap telah gagal. Namun sebagian yang lain justru beranggapan, hal ini menandakan bahwa bidang profesi rekayasa perangkat lunak telah cukup matang, karena dalam bidang profesi lainnya pun, tidak ada teknik pamungkas yang dapat digunakan dalam berbagai kondisi.

pengertian dan tujuan RPL

Pengertiaan dan Definisi 

Menurut Wikipedia : Rekayasa perangkat lunak adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat lunak termasuk pembuatan, pemeliharaan, manajemen organisasi pengembanganan perangkat lunak dan manajemen kualitas.

Menurut IEEE Computer Society : Rekayasa perangkat lunak sebagai penerapan suatu pendekatan yang sistematis, disiplin dan terkuantifikasi atas pengembangan, penggunaan dan pemeliharaan perangkat lunak, serta studi atas pendekatan-pendekatan ini, yaitu penerapan pendekatan engineering atas perangkat lunak.

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.

Dari beberapa definisi dan penjelasan diatas ada beberapa kategori dari suatu rekayasa perangkat lunak yaitu :

1. Maintainability yang artinya perangkat lunak dapat terus dirawat dan dipelihara.

Pengertian lain dari maintainability adalah suatu usaha yang diperlukan untuk menemukan dan memperbaiki kesalahan dalam perangkat lunak. maintanability diperlukan untuk pemeliharaan perangkat lunak dimana setelah dikembangkan dan diimplementasikan terdapat beberapa hal yang perlu diperbaiki berdasarkan hasil ujicoba maupun evaluasi. Suatu perangkat lunak yang baik dikatakan maintainability dapat dengan mudah direvisi apabila diperlukan.

2. Dependability yang artinya perangkat lunak dapat mengikuti perkembangan teknologi.

Dependability maksudnya suatu perangkat lunak dapat diandalkan dan mengikuti perkembangan, secara kasarnya dependability itu maksudnya adalah kepercayaan konsumen terhadap suatu perangkat lunak.  Sebenarnya dependability itu sendiri tergantung dari beberapa faktor diantaranya availability (ketersediaan sistem pada setiap waktu diperlukan oleh sistem) , reliability (kecenderungan sistem gagal dalam melaksanakan perintah), security(bagian dari sistem yang mencerminkan kemampuan untuk berjalan secara normal tanpa menyebabkan resiko bagi pengguna) dan safety(berkaitan dengan kehandalan sistem dalam menangkal ancaman dari luar sistem).

3. Robust yang artinya perangkat lunak dapat mengikuti keinginan pengguna.

Maksud dari robust perangkat lunak adalah kinerja atau hasil yang diharapkan meskipun dalam kondisi yang tidak ideal seperti adanya gangguan yang tidak terkendali yang dapat mempengaruhi kinerja perangkat lunak.

4. efektif dan efisien dalam menggunakan energi dan penggunaannya

suatu perangkat lunak dikatakan efektif dan efisien artinya pengguna tidak harus melakukan proses yang berulang-ulang hanya untuk menghasilkan beberapa output yang diinginkan.

5. Usability yang artinya dapat memenuhi kebutuhan yang diinginkan

Usability adalah tingkat kualitas dari perangkat lunak yang mudah dipelajari, mudah digunakan dan mendorong pengguna untuk menggunakan perangkat lunak sebagai alat bantu positif dalam menyelesaikan tugas. Usability adalah suatu ukuran, dimana pengguna dapat mengakses fungsionalitas dari sebuah perangkat lunak dengan efektif, efisien dan memuaskan dalam mencapai tujuan tertentu

Tujuan Rekayasa Perangkat Lunak

Secara lebih khusus kita dapat menyatakan tujuan dan Rekaya Perangkat Lunak ini adalah:

1. Memperoleh biaya produksi perangkat lunak yang rendah.
2. Menghasilkan pereangkat lunak yang kinerjanya tinggi, andal dan tepat waktu
3. Menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis platform
4. Menghasilkan perangkat lunak yang biaya perawatannya rendah

Kriteria Dalam Merekayasa Perangkat Lunak

1. Dapat terus dirawat dan dipelihara (maintainability)
2. Dapat mengikuti perkembangan teknologi (dependability)
3. Dapat mengikuti keinginan pengguna (robust).
4. Efektif dan efisien dalam menggunakan energi dan penggunaannya.
5. Dapat memenuhi kebutuhan yang diinginkan (usability).

Ruang Lingkup Rekayasa Perangkat Lunak

1. Software Requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat lunak.
2. Software desain mencakup proses penampilan arsitektur, komponen, antar muka, dan karakteristik lain dari perangkat lunak.
3. Software construction berhubungan dengan detail pengembangan perangkat lunak, termasuk. algoritma, pengkodean, pengujian dan pencarian kesalahan.
4. Software testing meliputi pengujian pada keseluruhan perilaku perangkat lunak.
5. Software maintenance mencakup upaya-upaya perawatan ketika perangkat lunak telah dioperasikan.
6. Software configuration management berhubungan dengan usaha perubahan konfigurasi perangkat lunak untuk memenuhi kebutuhan tertentu.
7. Software engineering management berkaitan dengan pengelolaan dan pengukuran RPL, termasuk perencanaan proyek perangkat lunak.
8. Software engineering tools and methods mencakup kajian teoritis tentang alat bantu dan metode RPL.

Rekayasa Perangkat Lunak dan Disiplin Ilmu Lain

Cakupan ruang lingkup yang cukup luas, membuat RPL sangat terkait dengan disiplin dengan bidang ilmu lain. tidak saja sub bidang dalam disiplin ilmu komputer namun dengan beberapa disiplin ilmu lain diluar ilmu komputer.

Keterkaitan RPL dengan bidang ilmu lain

• Bidang ilmu manajemen meliputi akuntansi, finansial, pemasaran, manajemen operasi, ekonomi, analisis kuantitatif, manajemen sumber daya manusia, kebijakan, dan strategi bisnis. 
• Bidang ilmu matematika meliputi aljabar linier, kalkulus, peluang, statistik, analisis numerik, dan matematika diskrit.
• Bidang ilmu manajemen proyek meliputi semua hal yang berkaitan dengan proyek, seperti ruang lingkup proyek, anggaran, tenaga kerja, kualitas, manajemen resiko dan keandalan, perbaikan kualitas, dan metode-metode kuantitatif.