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://dewadirga.blogspot.com/2011/09/tentang-activity-diagram.html

Diagram Use case

Use Case Diagram menggambarkan sebuah fungsionalitas yang diharapkan dari sebuah sistem dan bagaimana sistem berinteraksi dengan dunia luar. Yang ditekankan dalam Use Case Diagram adalah ”apa” yang diperbuat sistem, dan bukan “bagaimana” sistem itu melakukannya.

Sebuah Use Case mempresentasikan sebuah interaksi antara actor dengan sistem. Use Case Diagram juga menjelaskan manfaat sistem jika dilihat menurut pandangan orang yang berada diluar sistem (actor). Use Case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng - create sebuah daftar daftar belanja dan sebagainya.

• Actor

Actor menggambarkan orang, sistem atau entitas luar yang menyediakan informasi atau menerima informasi dari sistem. Actor menggambarkan sebuah tugas/peran dan bukannya posisi sebuah jabatan. Actor biasanya menggunakan Kata benda. Dalam Use Case Diagram terdapat satu aktor pemulai atau initiator actor yang membangkitkan rangsangan awal terhadap sistem, dan mungkin sejumlah aktor lain yang berpartisipasi atau participating actor akan sangat berguna untuk mengetahui siapa aktor pemulai tersebut.

• Use Case

Use case menggambarkan perilaku, termasuk didalamnya interaksi antara actor dengan sistem. Use case dibuat berdasarkan keperluan actor, merupakan “apa” yang dikerjakan sistem bukan “bagaimana” sistem mengerjakannya. Setiap use case harus diberi nama yang menyatakan apa hal yang dicapai dari hasil interaksinya dengan actor. Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada dua use case yang memiliki nama yang sama.

• Association antara actor dan use case

Ujung panah pada association antara actor dan use case mengindikasikan siapa/apa yang meminta interaksi dan bukannya mengindikasikan aliran data Sebaiknya gunakan Garis tanpa panah untuk association antara actor dan use case



association antara actor dan use case yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system anda




1. include termasuk didalam use case lain (required) / (diharuskan) Pemanggilan use case oleh use case lain, contohnya adalah pemanggilan sebuah fungsi program Tanda panah terbuka harus terarah ke sub use case Gambarkan association include secara horizontal. berikut adalah contohnya:







2. extend digunakan ketika hendak menggambarkan variasi pada kondisi perilaku normal dan menggunakan lebih banyak control forn dan mendeklarasikan ekstension pada use case utama atau dengan kata lain adalah perluasan dari use case lain jika syarat atau kondisi terpenuhi. Berikut adalah contohnya:

• Generalization / Inheritance antara Use Case

Generalization dipakai ketika ada sebuah perilaku khusus (single condition) dan merupakan pola hubungan base – parent use case. Digambarkan dengan generalization / inheritance antar use case secara vertical dengan inheriting use case dibawah base / parent use case.

entitas

“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 :

http://natanawa.hol.es/?p=519

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 

ERD

Bahasan Sistem Basis Data kali ini tentang Entity Relationship Diagram (ERD) salah satu bentuk pemodelan basis data yang sering digunakan dalam pengembangan sistem informasi. Bahasan meliputi: Pengertian ERD, Notasi ERD, Metode ERD, Tahap ERD, Kardinalitas, dan Contoh kasus ERD

Pengertian ERD

Dalam rekayasa perangkat lunak, sebuah Entity-Relationship Model (ERM) merupakan abstrak dan konseptual representasi data. Entity-Relationship adalah salah satu metode pemodelan basis data 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.

Notasi ERD

Ada sejumlah konvensi mengenai Notasi  ERD. Notasi klasik sering digunakan untuk model konseptual. Berbagai notasi lain juga digunakan untuk menggambarkan secara logis dan fisik dari suatu basis data, salah satunya adalah IDEF1X.

http://fairuzelsaid.wordpress.com/2010/03/16/sistem-basis-data-entity-relationship-diagram-erd/Model ERD

Notasi-notasi simbolik yang digunakan dalam Entity Relationship Diagram adalah sebagai berikut :

• Entitas, Adalah segala sesuatu yang dapat digambarkan oleh data. Entitas juga dapat diartikan sebagai individu yang mewakili sesuatu yang nyata (eksistensinya) dan dapat dibedakan dari sesuatu yang lain (Fathansyah, 1999). Ada dua macam entitas yaitu entitas kuat 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, Atribut merupakan pendeskripsian karakteristik dari entitas. Atribut digambarkan dalam bentuk lingkaran atau elips. Atribut yang menjadi kunci entitas atau key diberi garis bawah.

• Relasi atau Hubungan, Relasi menunjukkan adanya hubungan diantara sejumlah entitas yang berasal dari himpunan entitas yang berbeda.
• Penghubung antara himpunan relasi dengan himpunan entitas dan himpunan entitas dengan atribut dinyatakan dalam bentuk garis.

Contoh ERD

Derajat relasi atau kardinalitas

Menunjukkan jumlah maksimum entitas yang dapat berelasi dengan entitas pada himpunan entitas yang lain. Macam-macam kardinalitas adalah:

• Satu ke satu (one to one), Setiap anggota entitas A hanya boleh berhubungan dengan satu anggota entitas B, begitu pula sebaliknya.
• Satu ke banyak (one to many), Setiap anggota entitas A dapat berhubungan dengan lebih dari satu anggota entitas B tetapi tidak sebaliknya.
• Banyak ke banyak (many to many), Setiap entitas A dapat berhubungan dengan banyak entitas himpunan entitas B dan demikian pula sebaliknya.

Tahap ERD

Tahap pertama pada desain sistem informasi menggunakan model ER adalah menggambarkan kebutuhan informasi atau jenis informasi yang akan disimpan dalam database. Teknik pemodelan data dapat digunakan untuk menggambarkan setiap ontologi (yaitu gambaran dan klasifikasi dari istilah yang digunakan dan hubungan anatar informasi) untuk wilayah tertentu.
Tahap berikutnya disebut  desain logis, dimana data dipetakan ke model data yang logis, seperti model relasional.  Model data yang loguis ini kemudian dipetakan menjadi model fisik , sehingga kadang-kadang, Tahap kedua ini disebut sebagai “desain fisik”.
Secara umum metodologi ERD sebagai berikut:

Metodologi ERD

Contoh Kasus:

Sebuah perusahaan mempunyai beberapa bagian. Masing-masing bagian mempunyai pengawas dan setidaknya satu pegawai. Pegawai ditugaskan paling tidak di satu bagian (dapat pula dibeberapa bagian). Paling tidak satu pegawai mendapat tugas di satu proyek. Tetapi seorang pegawai dapat libur dan tidak dapat tugas di proyek.

Menentukan entitas

Entitasnya : pengawas, bagian, pegawai, proyek

Menentukan relasi dengan matrik relasi

Menentukan Relasi

Gambar ERD sementara

Hubungkan entitas sesuai dengan matrik relasi yang dibuat

ERD Sementara

Mengisi kardinalitas

Dari gambaran permasalahan dapat diketahui bahwa:

• masing-masing bagian hanya punya satu pengawas
• seorang pengawas bertugas di satu bagian
• masing-masing bagian ada minimal satu pegawai
• masing-masing pegawai bekerja paling tidak di satu bagian
• masing-masing proyek dikerjakan paling tidak oleh satu pegawai

Mengisi kardinalitas

Menentukan kunci utama
Kunci utamanya: Nomor Pengawas, Nama Bagian, Nomor Pegawai, Nomor Proyek

Menentukan Kunci Utama

Menggambar ERD berdasarkan kunci

Ada dua relasi many to many pada ERD sementara, yaitu antara bagian dengan pegawai, pegawai dengan proyek, oleh sebab itu kita buat entitas baru yaitu bagian -pegawai dan pegawai-proyek Kunci utama dari entitas baru adalah kunci utama dari entitas lain yang akan menjadi kunci tamu di entitas yang baru.

Menggambar ERD berdasarkan kunci

Menentukan atribut

Atribut yang diperlukan adalah: nama bagian, nama proyek, nama pegawai, nama pengawas, nomor proyek, nomor pegawai, nomor pengawas

Memetakan atribut

• Bagian : Nama bagian
• Proyek: Nama proyek
• Pegawai:Nama pegawai
• Pengawas: Nama pengawas
• Proyek-Pegawai : Nomor proyek, Nomor pegawai
• Pengawas: Nomor pengawas

Menggambar ERD dengan atribut

Menggambar ERD dengan atribut

Data Flow Diagram

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

Simbol DFD

TERMINATOR/KESATUAN LUAR (EXTERNAL ENTITY)

Setiap sistem pasti mempunyai batas sistem (boundary) yang memisahkan suatu sistem dengan lingkungan luarnya. Kesatuan luar (external entity) merupakan kesatuan (entity) di lingkungan luar sistem yang berupa orang, organisasi atau sistem lainnya yang berada di lingkungan luarnya yang akan membeikan input atau menerima output dari sistem (Jogiyanto, 1989).

Suatu kesatuan luar dapat disimbolkan dengan suatu notasi kotak.

Notasi terminator/Kesatuan Luar di DFD

Terminator dapat berupa orang, sekelompok orang, organisasi, departemen di dalam organisasi, atau perusahaan yang sama tetapi di luar kendali sistem yang sedang dibuat modelnya. Terminator dapat juga berupa departemen, divisi atau sistem di luar sistem yang berkomunikasi dengan sistem yang sedang dikembangkan.

ARUS DATA (DATA FLOW)

Arus data (data flow) di DFD diberi simbol suatu panah. Arus data ini mengalir diantara proses (Process), simpanan data (data store) dan kesatuan luar (external entity). Arus data ini menunjukkan arus data yang dapat berupa masukkan untuk sistem atau hasil dari proses sistem.

 

PROSES (PROCESS)

Suatu proses adalah kegiatan atau kerja yang dilakukan oleh orang, mesin, atau komputer dan hasil suatu arus data yang masuk ke dalam proses untuk dilakukan arus data yang akan keluar dari prises. Suatu proses dapat ditunjukkan dengan simbol lingkaran atau dengan simbol empat persegi panjang tegak dengan sudut-sudutnya tumpul.

Notasi Proses di DFD

Ada beberapa hal yang perlu diperhatikan tentang proses :

• Proses harus memiliki input dan output.

• Proses dapat dihubungkan dengan komponen terminator, data store atau proses melalui alur data.

• Sistem/bagian/divisi/departemen yang sedang dianalisis oleh profesional sistem digambarkan dengan komponen proses.

SIMPANAN DATA (DATA STORE)

Simpanan data (data store) merupakan simpanan dari data yang dapat berupa file atau database di sistem komputer, arsip atau catatan manual, kotak tempat data di meja seseorang, tabel acuan manual, agenda atau buku. Simpanan data di DFD dapat disimbolkan dengan sepasang garis horizontal paralel yang tertutup di salah satu ujungnya.

Simbol dari Simpanan Data di DFD

 

 

http://en.wikipedia.org 

 

Diagram konteks

Diagram konteks (Context Diagram) adalah suatu diagram alir yang tingkat tinggi yang menggambarkan seluruh jaringan, masukan dan keluaran. sistem yang dimaksud adalah untuk menggambarkan sistem yang sedang berjalan. mengidentifikasikan awal dan akhir data awal dan akhir yang masuk dan keluaran sistem. Diagram ini merupakan gambaran umum sistem yang nantinya akan kita buat. secara uraian dapat dikatakan bahwa diagram konteks itu berisi siapa saja yang memberikan data (input-an) kesistem serta kepada siapa data informasi yang harus dihasilkan sistem.

Gambar  : Diagram Konteks Sistem Informasi Pemesanan Barang Dagang

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

Metode Prototyping Dalam Pengembangan Sistem Informasi

1. Pengertian

Proses pengembangan sistem seringkali menggunakan pendekatan prototipe (prototyping). Metode ini sangat baik digunakan untuk menyelesesaikan masalah kesalahpahaman antara user dan analis yang timbul akibat user tidak mampu mendefinisikan secara jelas kebutuhannya (Mulyanto, 2009).

Prototyping adalah pengembangan yang cepat dan pengujian terhadap model kerja (prototipe) dari aplikasi baru melalui proses interaksi dan berulang-ulang yang biasa digunakan ahli sistem informasi dan ahli bisnis. Prototyping disebut juga desain aplikasi cepat (rapid application design/RAD) karena menyederhanakan dan mempercepat desain sistem (O'Brien, 2005).

Sebagian user kesulitan mengungkapkan keinginannya untuk mendapatkan aplikasi yang sesuai dengan kebutuhannya. Kesulitan ini yang perlu diselesaikan oleh analis dengan memahami kebutuhan user dan menerjemahkannya ke dalam bentuk model (prototipe). Model ini selanjutnya diperbaiki secara terus menerus sampai sesuai dengan kebutuhan user.

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. Gambar di bawah ini mengilustrasikan proses pembuatan prototipe :

Langkah-Langkah Prototyping

a.  Analisis Kebutuhan Sistem

Pembangunan sistem informasi memerlukan penyelidikan dan analisis mengenai alasan timbulnya ide atau gagasan untuk membangun dan mengembangkan sistem informasi. Analisis dilakukan untuk melihat berbagai komponen yang dipakai sistem yang sedang berjalan meliputi hardware, software, jaringan dan sumber daya manusia. Analisis juga mendokumentasikan aktivitas sistem informasi meliputi input, pemrosesan, output, penyimpanan dan pengendalian (O'Brien, 2005).

Selanjutnya melakukan studi kelayakan (feasibility study) untuk merumuskan informasi yang dibutuhkan pemakai akhir, kebutuhan sumber daya, biaya, manfaat dan kelayakan proyek yang diusulkan (Mulyanto, 2009).

Analisis kebutuhan sistem sebagai bagian dari studi awal bertujuan mengidentifikasi masalah dan kebutuhan spesifik sistem. Kebutuhan spesifik sistem adalah spesifikasi mengenai hal-hal yang akan dilakukan sistem ketika diimplementasikan (Mulyanto, 2009).

Analisis kebutuhan sistem harus mendefinisikan kebutuhan sistem yang spesifik antara lain :

1)     Masukan yang diperlukan sistem (input)

2)     Keluaran yang dihasilkan (output)

3)     Operasi-operasi yang dilakukan (proses)

4)     Sumber data yang ditangani

5)     Pengendalian (kontrol)

Spesifikasi Kebutuhan Sistem

Tahap analisis kebutuhan sistem memerlukan evaluasi untuk mengetahui kemampuan sistem dengan mendefinisikan apa yang seharusnya dapat dilakukan oleh sistem tersebut kemudian menentukan kriteria yang harus dipenuhi sistem. Beberapa kriteria yang harus dipenuhi adalah pencapaian tujuan, kecepatan, biaya, kualitas informasi yang dihasilkan, efisiensi dan produktivitas, ketelitian dan validitas dan kehandalan atau reliabilitas (Mulyanto, 2009).

b.  Desain Sistem

Analisis sistem (system analysis) mendeskripsikan apa yang harus dilakukan sistem untuk memenuhi kebutuhan informasi pemakai. Desain sistem  (system design) menentukan bagaimana sistem akan memenuhi tujuan tersebut. Desain sistem terdiri dari aktivitas desain yang menghasilkan spesifikasi fungsional. Desain sistem dapat dipandang sebagai desain interface, data dan proses dengan tujuan menghasilkan spesifikasi yang sesuai dengan produk dan metode interface pemakai, struktur database serta pemrosesan dan prosedur pengendalian (Ioanna et al., 2007).

Desain sistem akan menghasilkan paket software prototipe, produk yang baik sebaiknya mencakup tujuh bagian :

1)     Fitur menu yang cepat dan mudah.

2)     Tampilan input dan output.

3)     Laporan yang mudah dicetak.

4)     Data dictionary yang menyimpan  informasi pada setiap field termasuk panjang field, pengeditan dalam setiap laporan dan format field yang digunakan.

5)     Database dengan format dan kunci record yang optimal.

6)     Menampilkan query online secara tepat ke data yang tersimpan pada database.

7)     Struktur yang sederhana dengan bahasa pemrograman yang mengizinkan pemakai melakukan pemrosesan khusus, waktu kejadian, prosedur otomatis dan lain-lain.

c. Pengujian Sistem

Paket software prototipe diuji, diimplementasikan, dievaluasi dan dimodifikasi berulang-ulang hingga dapat diterima pemakainya (O'Brien, 2005). Pengujian sistem bertujuan menemukan kesalahan-kesalahan yang terjadi pada sistem dan melakukan revisi sistem. Tahap ini penting untuk memastikan bahwa sistem bebas dari kesalahan (Mulyanto, 2009).

Menurut Sommerville (2001) pengujian sistem terdiri dari :

1)     Pengujian unit untuk menguji komponen individual secara independen tanpa komponen sistem yang lain untuk menjamin sistem operasi yang benar.

2)     Pengujian modul yang terdiri dari komponen yang saling berhubungan.

3)     Pengujian sub sistem yang terdiri dari beberapa modul yang telah diintegrasikan.

4)     Pengujian sistem untuk menemukan kesalahan yang diakibatkan dari interaksi antara subsistem dengan interfacenya serta memvalidasi persyaratan fungsional dan non fungsional.

5)     Pengujian penerimaan dengan data yang dientry oleh pemakai dan bukan uji data simulasi.

6)     Dokumentasi berupa pencatatan terhadap setiap langkah pekerjaan dari awal sampai akhir pembuatan program.

Pengujian sistem informasi berbasis web dapat menggunakan teknik dan metode pengujian perangkat lunak tradisional. Pengujian aplikasi web meliputi pengujian tautan, pengujian browser, pengujian usabilitas, pengujian muatan, tegangan dan pengujian malar  (Simarmata, 2009).

Penerimaan pengguna (user) terhadap sistem dapat dievaluasi dengan mengukur kepuasan user terhadap sistem yang diujikan. Pengukuran kepuasan meliputi tampilan sistem, kesesuaian dengan kebutuhan user, kecepatan dan ketepatan sistem untuk menghasilkan informasi yang diinginkan user. Ada beberapa model pengukuran kepuasan user terhadap sistem, diantaranya adalah Technology Acceptance Model (TAM), End User Computing (EUC) Satisfaction, Task Technology Fit (TTF) Analysis dan  Human Organizational Technology (HOT) Fit Model.

Salah satu model pengukuran yang telah diterjemahkan ke dalam beberapa bahasa berbeda dan tidak menunjukkan perbedaan hasil pengukuran yang signifikan adalah End User Computing (EUC) Satisfaction. Model ini menekankan kepuasan user terhadap aspek teknologi meliputi aspek isi, keakuratan, format, waktu dan kemudahan penggunaan sistem (Chin & Mathew, 2000).

d.  Implementasi

Setelah prototipe diterima maka pada tahap ini merupakan implementasi sistem yang siap dioperasikan dan selanjutnya terjadi proses pembelajaran terhadap sistem baru dan membandingkannya dengan sistem lama, evaluasi secara teknis dan operasional serta  interaksi pengguna, sistem dan teknologi informasi.

5.Alat Perancangan Sistem

Perancangan sistem membutuhkan peralatan berupa alat alat perancangan proses dan  alat perancangan data. Alat perancangan proses terdiri dari diagram aliran data dan diagram arus sistem. Sedangkan alat perancangan data terdiri dari diagram relasi entitas (entity relationship) dan kamus data (data dictionary).

a. Diagram Aliran Data

Diagram aliran data (data flow diagram/DFD) adalah sebuah alat dokumentasi grafik yang menggunakan simbol-simbol untuk menjelaskan sebuah proses. Diagram ini menunjukkan aliran proses seluruh sistem kepada pemakai dan dapat diatur detailnya sesuai dengan kemampuan pemahaman pemakai. DFD terdiri dari tiga elemen yaitu lingkungan, pemrosesan, aliran data dan penyimpanan data. Salah satu keuntungan menggunakan DFD adalah memudahkan pemakai yang kurang menguasai bidang komputer untuk mengerti sistem yang sedang akan dikerjakan (Ladjamudin, 2005).

b.Diagram Arus Sistem

Diagram arus sistem (Sistem Flow chart) adalah peralatan yang digunakan untuk menggambarkan proses sistem secara rinci untuk menggambarkan aliran sistem informasi dan diagram arus sistem untuk menggambarkan aliran program .

c.Diagram Relasi Entitas

Diagram relasi entitas menunjukkan antar entitas satu dengan yang lain dan bentuk hubungannya sehingga data tergabung dalam satu kesatuan yang terintegrasi .

d.Kamus Data

Kamus data adalah penjelasan tertulis lengkap dari data yang diisikan ke dalam database .

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.

 

model waterfall dan pembangunan dalam waktu singkat yang

dicapai dengan menerapkan :

1. Component based construction ( pemrograman berbasis komponen ).

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 komplekstasnya sstem yang

dibangun.

Jika keutuhan yang diinginkan pada tahap analisa kebutuhan telah lengkap dan jelas,

maka waktu yang dibutuhkan untuk menyelesakan secara lengkap perangkat lunak yang

dibuat adalah berkisar 60 sampai 90 hari. Model RAD hampr sama dengan model

waterfall, bedanya siklus pengembangan yang ditempuh model in sangat pendek

dengan penerapan teknik yang cepat.

Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan beberapa tmm dalam waktu

yang hampir bersamaan dalam waktu yang sudah ditentukan. Model in melibatkan

banyak tim, dan setiap tim mengerjakan tugas yang selevel, namun berbeda. Sesuai

dengan pembagian modul sistem.

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