Pages

Friday, 5 September 2014

Data Flow Diagram (DFD)

Pengertian Data Flow Diagram (DFD)
Data Flow Diagram atau sering disingkat DFD adalah perangkat-perangkat analisis dan perancangan yang terstruktur sehingga memungkinkan peng-analis sistem memahami sistem dan subsistem secara visual sebagai suatu rangkaian aliran data yang saling berkaitan.
Simbol dalam Data Flow Diagram
gambar 1.1 Simbol-simbol dalam DFD
Entitas  biasanya diberi nama dengan kata benda.
Aliran data merupakan perpindahan data dari satu titik ke titik yang lain (penggambarannya dengan cara kepala tanda panah mengarah ke tujuan datanya.
Proses biasanya selalu menunjukkan suatu perubahan data dan terjadinya proses transformasi data.
Penyimpanan Data (data store) diberi nama dengan kata benda, sesuai dengan data yang disimpan didalamnya.
Didalam DFD terdapat 3 level, yaitu :
1. 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.
2. 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.
3. Diagram Rinci : merupakan diagram yang menguraikan proses apa yang ada dalam diagram Nol.
Fungsi DFD
Fungsi dari Data Flow Diagram adalah :
  • 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.

  • SYARAT MEMBUAT DFD
Syarat-syarat pembuatan DFD ini adalah :
1. Pemberian nama untuk tiap komponen DFD.
2. Pemberian nomor pada komponen proses.
3. Penggambaran DFD sesering mungkin agar enak dilihat.
4. Penghindaran penggambaran DFD yang rumit.
5. Pemastian DFD yang dibentuk itu konsiten secara logika.
  • TIPS DALAM MEMBUAT DFD
Berikut ini tips-tips dalam membuat DFD :
  1. Pilih notasi sehingga proses yang didekomposisi atau tidak didekomposisi dapat dibaca dengan mudah.
  2. Nama proses harus terdiri dari kata kerja dan kata benda.
  3. Nama yang dipakai untuk proses, data store, dataflow harus konsisten (identitas perlu).
  4. Setiap level harus konsisten aliran datanya dengan level sebelumnya.
  5. Usahakan agar external entity pada setiap level konsisten peletakannya.
  6. Banyaknya proses yang disarankan pada setiap level tidak melebihi 7 proses.
  7. Dekomposisi berdasarkan kelompok data lebih disarankan (memudahkan aliran data ke storage yang sama).
  8. Nama Proses yang umum hanya untuk prose yang masih akan didekomposisi.
  9. Pada Proses yang sudah tidak didekomposisi, nama Proses dan nama Data harus sudah spesifik.
  10. Aliran ke storage harus melalui proses, tidak boleh langsung dari external entity.
  11. Aliran data untuk Proses Report .. : harus ada aliran keluar. Akan ada aliran masuk jika perlu parameter untuk mengaktifkan report.Aliran data yang tidak ada datastorenya harus diteliti, apakah memang tidak mencerminkan persisten entity (perlu disimpan dalam file/tabel), yaitu kelak hanya akan menjadi variabel dalam program.
  • LANGKAH MEMBUAT/MENGGAMBAR DFD
Tidak ada aturan baku untuk menggambarkan DFD. Tapi dari berbagai referensi yang ada, secara garis besar langkah untuk membuat DFD adalah :
1. Identifikasi Entitas Luar, Input dan Output
Identifikasi terlebih dahulu semua entitas luar, input dan ouput yang terlibat di sistem.
2. Buat Diagram Konteks (diagram context)
Diagram ini adalah diagram level tertinggi dari DFD yang menggambarkan hubungan sistem dengan    lingkungan luarnya. Caranya :
• Tentukan nama sistemnya.
• Tentukan batasan sistemnya.
• Tentukan terminator apa saja yang ada dalam sistem.
• Tentukan apa yang diterima/diberikan external entity dari/ke sistem.
• Gambarkan diagram konteks.
3. Buat Diagram Level Zero (Overview Diagram)
Diagram ini adalah dekomposisi dari diagram konteks. Caranya :
  • Tentukan proses utama yang ada pada sistem.
  • Tentukan apa yang diberikan/diterima masing-masing proses ke/dari sistem sambil memperhatikan konsep keseimbangan (alur data yang keluar/masuk dari suatu level harus sama dengan alur data yang masuk/keluar pada level berikutnya).
  • Apabila diperlukan, munculkan data store (master) sebagai sumber maupun tujuan alur data.
  • Hindari perpotongan arus data.
  • Beri nomor pada proses utama (nomor tidak menunjukkan urutan proses).
4. Buat Diagram Level Satu
Diagram ini merupakan dekomposisi dari diagram level zero. Caranya :
  • Tentukan proses yang lebih kecil (sub-proses) dari proses utama yang ada di level zero.
  • Tentukan apa yang diberikan/diterima masing-masing sub-proses ke/dari sistem dan perhatikan konsep  keseimbangan.
  • Apabila diperlukan, munculkan data store (transaksi) sebagai sumber maupun tujuan alur data.
  • Hindari perpotongan arus data.
  • Beri nomor pada masing-masing sub-proses yang menunjukkan dekomposisi dari proses sebelumnya.Contoh : 1.1, 1.2, 2
  • KESALAHAN DALAM PEMBUATAN DFD
Umumnya kesalahan dalam pembuatan DFD adalah :
  1. Proses mempunyai input tetapi tidak menghasilkan output. Kesalahan ini disebut dengan black hole (lubang hitam), karena data masuk ke dalam proses dan lenyap tidak berbekas seperti dimasukkan ke dalam lubang hitam.
  2. Proses menghasilkan output tetapi tidak pernah menerima input. Kesalahan ini disebut dengan miracle (ajaib), karena ajaib dihasilkan output tanpa pernah menerima input.
  3. Input yang masuk tidak sesuai dengan kebutuhan proses.
  4. Data Store tidak memiliki keluaran.
  5. Data Store tidak memiliki masukan.
  6. Hubungan langsung antar entitas luar.
  7. Masukan langsung entitas data store.
  8. Keluaran langsun dari data store ke Entitas luar.
  9. Hubungan langsung antar data store.
  10. Data masukan dan keluaran yang tidak bersesuain dalam data store.

Proses Rekayasa Kebutuhan

Merupakan proses menemukan, memperbaiki, memodelkan dan menspesifikasikan.
Terdiri dari lima langkah pokok:
  1. Identifikasi Masalah
  2. Evaluasi dan sintesis
  3. Pemodelan
  4. Spesifikasi
  5. Review
  • Lengkap: Mendeskripsikan semua fasilitas yang diinginkan
  • Konsisten: Tidak adanya konflik dan kontradiksi
Proses Rekayasa Kebutuhan
  • sudah sesuai dengan tujuan organisasi
  • dapat dikembangkan dengan teknologi terkini dan dana yang tersedia
  • dapat diintegrasikan dengan sistem lain yang sudah digunakan
  • Bank customers
  • Representatives of other banks
  • Hardware and software maintenance engineers
  • Marketing department
  • Bank managers and counter staff
  • Database administrators and security staff
  • Communications engineers
  • Personnel department

  • Penggambaran bagaiman sistem akan digunakan
  • Membantu dalam menemukan kebutuhan dengan mempermudah dalam penggambaran proses dibandingkan pernyataan abstrak kebutuhan sistem
  • Menambahkan detail ke outline deskripsi kebutuhan
  • Sistem State pada awal scenario
  • Alur Normal kejadian-kejadian di sistem
  • Apa yang dapat berkembang dan bagaimana menanganinya
  • Aktifitas-aktifitas yang bersamaan terjadi
  • System state setelah proses selesai
  • Skenario kejadian dapat digunakan untuk menggambarkan bagaimana sistem merespon ke suatu kejadian tertentu seperti awal transaksi
  • VORD dapat berupa diagram untuk menggambarkan scenario kejadian
  • Data yang dikirim dan disediakan
  • Kontrol Informasi
  • Pengecualiaan Proses
  • Kejadian berikutnya
  • Elips menyatakan data yang disediakan oleh dan dikirim ke viewpoint
  • Data keluar dari sisi kanan setiap kotak
  • Eksepsi ditunjukkan di bawah maisng-masing box
  • Nama kejadian berikutnya berada di box dengan garis panah tebal
  • Timeout: Pelanggan salah memasukkan nomor PIN selama waktu yang diberikan
  • Invalid Card: Kartu tidak diknal oleh sistem dan dikembalikan
  • Stolen Card: Kartu sudah diregister sebagai kartu yang sudah dicuri/hilang dan akan diambil oleh sistem (tidak dikembalikan)
  • Bertujuan untuk meyakinkan bahwa kebutuhan yang sudah didefinisikan sesuai dengan yang diinginkan pengguna
  • Menghindari Kesalahan pendefinisian kebutuhan karena akan menyebabkan penambahan biaya yang besar
  • Memperbaiki definisi kebutuhan stelah software dikirim akan menyebabkan peningkatan biaya hingga 100 kali.
  • Validasi. Apakah sudah sesuai dengan yang diinginkan
  • Konsistensi. Adakah konflik dengan kebutuhan lainnya
  • Lengkap: Apakah sudah termasuk semua fungsi yang dibutuhkan
  • Realisasi: Dapatkan kebutuhan diimplementasikan ke dana dan teknologi yang tersedia
  • Dapat diverifikasi: Dapatkah spesifikasi kebutuhan dicek
Teknik Validasi Kebutuhan
Review:
Prototyping
Test-Case Generator
Analisis Konsistensi Otomatis

Dalam menemukan Area permasalahan, perlu adanya komunikasi yang intensif dengan user. Hal yang perlu diperhatikan dalam berkomunikasi adalah menghindari salah interpretasi
Jenis Kebutuhan:
1. Kebutuhan Fungsional
Pendefinisian layanan yang harus disediakan, bagaimana reaksi sistem terhadap input dan apa yang harus dilakukan sistem pada situasi khusus (Kebutuhan sistem dilihat dari kacamata pengguna)
 2. Kebutuhan Non-Fungsional
Kendala pada pelayanan atau fungsi sistem seperti kendala waktu, kendala proses pengembangan, standard, dll. Contoh: kehandalan, waktu respon dan kebutuhan storage. Contoh kendala seperti: Keterbatasan kemampuan peralatan I/O, representasi sistem dll.
Domain Kebutuhan
Kebutuhan yang berasal dari domain aplikasi sistem dan merefleksikan karakteristik domain
Secara Prinsip, spesifikasi Kebutuhan harus:
Tipe Non-Fungsional
Studi kelayakan
Studi Kelayakan memutuskan apakah sistem software yang akan dibuat sudah mencakup seluruh aspek permasalahan. Melakukan studi untuk menguji apakah sistem:
- Feasibility Study 
sebuah analisa dan evaluasi dari proyek yang diusulkan untuk menentukan apakah secara teksis layak, layak dalam perkiraan biaya dan menguntungkan.

- Feasibility Report
analisis yang mengevaluasi satu atau lebih langkah-langkah tindakan potensial dan merekomendasikan bagaimana organisasi tersebut harus dilanjutkan. Diperkirakan biaya, mengidentifikasi manfaat yang diharapkan memperkirakan berapa lama proyek akan mengambil dan menguraikan kesulitan potensial.

- Requirements  Elicitation and Analysis
pengumpulan persyaratan sistem pengguna, pelanggan dan stakeholder lainnya. meliputi wawancara, kuisioner, observasi pengguna.

- System Model
sistem model konseptual yang menggambarkan dan mewakili suatu sistem. Sebuah sistem terdiri dari beberapa pandangan seperti perencanaan, persyaratan, desain, implementasi, penyebaran, struktur, perilaku, input data, dan data tampilan output.
Dalam system model terdapat 2 pendekatan, yaitu
1. Pendekatan non-arsitektur
terstruktur Sistem Metode Analisis dan Desain (SSADM), memilih bagan struktur untuk deskripsi struktur dan data flow diagram (DFD) untuk deskripsi perilaku.
2. Pendekatan arsitektur
arsitektur sistem menggunakan Bahasa Arsitektur Deskripsi (ADL) baik struktur dan perilaku deskripsi.

- Requirements spesification 
akibat langsung dari analisis kebutuhan dan dapat merujuk.

- User Requirements
kebutuhan pengguna, menggambarkan apa yang pengguna lakukan dengan sistem, seperti kegiatan yang pengguna harus dapat melakukan apa. Persyaratan pengguna umumnya didokumentasikan dalam Dokumen Persyaratan Pengguna (URD) menggunakan teks narasi. Persyaratan pengguna umumnya ditanda tangani oleh pengguna dan digunakan sebagai masukan utama untuk menciptakan persyaratan sistem.

- System Requirements 
persyaratan sistem diklarifikasikan sebagai persyaratan baik fungsional maupun tambahan. 
*Persyaratan fungsional menentuka sesuatu yang pengguna perlu untuk melakukan pekerjaan mereka. contoh : sistem mungkin diperlukan untuk mencetak dan masuk perkiraan biaya.
*Persyaratan non-fungsional atau tambahan menentukan semua persyaratan yang tersisa tidak tercakup oleh persyaratan fungsional 

- Requirements Validation
kepastian bahwa suatu produk, layanan, atau sistem memenuhi kebutuhan pelanggan dan stakeholder lainnyadidentifikasi. Ini sering melibatkan penerimaan dan kesesuaian dengan pelanggan eksternal.

- Requirements Document
dokumen yang ditulis oleh sebuah perusahaan yang mendefinisikan sebuah produk yang mereka buatatau persyaratan untuk satu atau lebih fitur baru untuk produk yang sudah ada. Fungsinya sebagai pemasaran persyaratan dokumen juga, terutama jika produk tersebut rumit atau kecil. 
Implementasi Studi Kelayakan
Proses analisis kebutuhan
Pemodelan Sistem
Dapat dilakukan dalam beberapa cara, seperti model structural, state machine, state chart, dll. Pemodelan tersebut dapat pula direpresentasikan sebagai formaliasi sudut pandang pengguna (viewpoint-oriented)
Viewpoint-oriented elicitation
Stakeholder merepresentatikan sudut pandang suatu masalah dalam beberapa cara. Analisis Multi perspektif adalah penting jika tidak terdapat suatu cara yang benar untuk menganalisa kebutuhan sistem.
Contoh: Sistem ATM Bank
Sistem ATM dapat menyediakan pelayanan bank secara otomatis. Pelayanan tersebut mencakup: penarikan tunai, pengiriman pesan untuk permintaan layanan, pemensanan, dan transfer.
Autoteller viewpoint
Identifikasi Viewpoint
Menemukan viewpoint sebagai penerima layanan sistem dan mengidentifikasikan layanan yang disediakan untuk masing-masing viewpoint
Pembentukan Struktur Viewpoint
Mengelompokkan viewpoint yang saling berhubungan secara hierarki. Layanan umum disediakan pada level yang lebih tinggi dalam hierarki
Dokumentasi Viewpoint : Memperbaiki deskripsi viewpoint dan layanan yang teridentifikasi
Viewpoint system mapping : Transformasi analisis ke perancangan berorientasi objek
Viewpoint Service Information
Skenario
Deskripsi Dan Skenario
Skenarion Kejadian
Notasi:
Pada contoh di atas, eksepsi adalah:
Validasi Kebutuhan
Pengujian Pendefinisian Kebutuhan
Managemen Perubahan Kebutuhan