Analisa DFD ngaco (episode 2)

Setelah terjadinya kesalah pahaman dalam pengerjaan tugas analisa springer yang TERNYATA gambar DFD tidak boleh ada yang sama untuk setiap individu, terpaksa (nggak juga sih) gue menganalisa DFD orang. tentang apa ini DFD dan bagaimana alur data-datanya menuju.

Langsung aja nih secara garis besar ini DFD menceritakan tentang proses pemesanan salah satu jenis makanan impor yang gue gak terlalu doyan, namanya Pizza.

Sebelum memulai analisa, bagi orang yang memiliki mata yang jeli dan pemikiran cermat pasti akan merasakan ada yang aneh dalam DFD diatas. Keanehan tersebut bisa dilihat pada notasinya, yang beda dari bentuk DFD secara umum seperti DFD yang ada pada postingan sebelumnya (yang boleh ngambil dari springer). Yang bikin beda adalah bentuk dari notasi System(Process) dan Customer. Kalau dalam bentuk umumnya notasi System digambarkan dengan simbol lingkaran sementara Customer digambarkan dengan simbol persegi, maka dalam apa yang terlihat pada notasi Yourdon/DeMarco ini merupakan kebalikan dari bentuk umum tersebut (alasan ngaco, but I think it's true). Jadi, tidak ada perdebatan diantara kita mengenai kesalahan dalam penggambaran notasi DFD. Sepakat.

 

Baiklah sekarang gue mulai analisanya. Seperti biasalah, atas nama keadilan gue bakal mulai dari Proses nomer satu, "Enter Sales Orders". Proses ini merupakan proses dimana pesanan penjualan dimasukkan. Artinya, seorang pelanggan melakukan transaksi pada Proses#1 ini. Jadi wajar, kalau Proses#1 membutuhkan data "Sales Order" atau pesanan penjualan dari entitas eksternal "Customer". Proses ini bertindak seperti perantara yang mengantarkan data dari Customer tadi yang berupa pesanan penjualan ke database "Sales Orders" yang menyimpan pesanan² dari para pelanggan. Dari sini, pesanan penjualan tadi diantarkan menuju Proses#2, "Organize Manufacturing Schedule".

 

Proses#2 ini bisa disebut kegiatan pengaturan jadwal produksi. Itu artinya, pada proses inilah kegiatan produksi dimulai. Proses ini membutuhkan data dari database "Stock" berupa Stock Quantities, yang artinya kurang lebih jumlah persediaan. Jika pesanan penjualan dan jumlah persediaan barang telah masuk, Proses#2 akan menghasilkan data berupa Production Schedule. Nah data tersebut akan masuk kedalam database "Production Schedules" sebelum akhirnya masuk ke Proses#3, "Make Pizzas".

 

Proses#3 ini anak SD jaman sekarang juga tau, Pembuatan Pizza. Disini, "aktor utama" DFD ini akan dibuat. Kalau mau bikin Pizza enak, tentu nggak boleh asal; harus terstruktur dan teratur agar cita rasa terjaga. Untuk itulah dibutuhkan resep, yang disimpan dalam database keempat kita, "Recipes". Data yang dikirim dari database ini tentu saja resep itu sendiri. Proses#3 ini sekarang sudah memiliki dua input penting, yaitu jadwal produksi dan resep, lantas menghasilkan data berupa pizzas manufactured (pizza yang udah jadi) dan raw materials requisition (seperti.. surat izin permintaan bahan baku) yang masuk ke database "Stock" (persediaan). Masuk akal kan, pizza yang udah jadi masuk ke "Stock" yang berarti sudah tersedia, sekaligus memesan bahan baku baru untuk pesanan selanjutnya. Lanjut, database "Stock" ini akan menghasilkan output berupa raw material quantities (yaitu jumlah bahan baku yang tersedia pada database ini) dan pizzas in stock (yaitu jumlah pizza yang tersedia) kedalam Proses#7, "Determine Raw Materials Required". Tapi itu nanti dulu, sekarang kita masuk ke Proses#4 sesuai urutan!

 

Proses#4 adalah "Order Raw Materials" yang berarti kegiatan pemesanan bahan baku. Kemana? ya ke Supplier (ya iya..). Untuk bisa berjalan, Proses#4 membutuhkan data dari Proses#7 berupa Raw material required (bahan baku yang dibutuhkan). Proses ini kemudian akan menghasilkan data berupa Purchase order requested (pembelian pesanan yang diminta) ke entitas eksternal "Supplier" serta database "Purchase Orders". Entitas Supplier kemudian akan menghasilkan data berupa Stock quantities yaitu jumlah persediaan barang (dari supplier) yang kembali masuk ke Proses#4 ini. Setelah barang masuk, Proses#4 akan mengirimkan data kembali berupa Purchase order fulfilled yang berarti pesanan sudah terpenuhi, kedalam database "Purchase Orders". Setelah semuanya beres, Proses#4 menghasilkan data berupa Raw material quantities (jumlah bahan baku) yang dimasukkan kedalam database kedua kita, "Stock". Dengan demikian proses pembuatan pizza telah selesai.

 

Proses#5 adalah "Deliver Sales Order". Jelas tujuannya, proses ini merupakan kegiatan pengiriman pesanan penjualan. Proses#5 membutuhkan data berupa Sales order dari database "Sales Order". Proses ini kemudian akan mengirimkannya kepada entitas "Customer" sebagai penerima. Setelah semuanya beres, Proses ini akan mengirimkan output berupa Delivery note (catatan/bukti pengiriman) kedalam database "Delivery".

 

Dari database "Delivery", akan keluar Delivery note yang masuk kedalam Proses#6, "Obtain Payment" atau penerimaan pembayaran. Proses ini akan mengirimkan Invoice (sejenis dokumen berisi daftar barang² yang berhasil dikirim) dan Receipt (Kwitansi) kepada Customer. Sebagai "timbal balik" Customer mengirimkan data berupa Payment details (Detail pembayaran) yang akan masuk kedalam database ketujuh, "Payment".

 

Proses#7 secara garis besar menggambarkan kegiatan Menentukan jumlah/jenis bahan baku yang dibutuhkan. Selain jumlah bahan baku dan pizza yang telah tersedia, Proses ini membutuhkan satu masukan lagi yaitu pesanan penjualan dari database pertama, "Sales Order". Ini bertujuan agar proses tidak "bingung" dan meminimalisir terjadinya kesalahan pada Proses itu sendiri. Dengan ketiga masukan tersebut, lahirlah data berupa Raw materials required (bahan baku yang diperlukan) yang akan masuk ke Proses#4!

 

Siklus seperti ini terjadi tanpa terikat waktu, artinya bisa terus-terusan nggak berhenti-berhenti, atau bahkan nggak jalan sama sekali. Tidak jelas karena DFD tidak memiliki patokan/keterangan kapan proses-proses akan dijalankan. Dan menurut analisa saya.. karena ada "Flow mendetail" pada DFD ini seperti Payment details dan purchase order fulfilled, DFD ini termasuk level 2 diagram (bener gak sih?)

yah after all (cie) sistem sudah komplit serta lengkap dan saya rasa tidak ada kekurangan sedikitpun. Sekian analisis ngaco dari seorang yang masih butuh belajar lebih dalam lagi.. semoga bisa memberi ilham buat semua pembaca bahwa DFD itu nggak serumit yang dilihat, cukup butuh kesabaran dan ketelitian dalam "menerawang" setiap prosesnya sesuai urutan.

 

Ini "Analisa" Springer (Ngaco Edition)

Kali ini gue mau coba melakukan "Analisa" untuk jurnal Springer yang berhasil *teman* gue temukan entah darimana. Dilihat dari judul figure/gambar nya sih, ini merupakan DFD untuk Sistem Manufaktur Diskrit, atau bahasa gampangnya, mungkin "Sistem Pabrik Terpisah" <-- ini google translate :lol:

gue coba menjelaskan, sebenarnya kalo udah ngerti nggak ribet-ribet amat kok. langsung aja, biar adil kita mulai dari Proses nomer 1, yaitu "Receive & record both product and m/c status" apa tuh m/c? m/c itu singkatan dari Machine. jadi jelas ya, maksud Proses disini adalah "Menerima dan merekam/mendata status dari produk dan mesin". Proses#1 ini menghasilkan dua buah output. Pertama adalah Product's position yang berarti mungkin posisi/letak produk, yang masuk kedalam Database "Product History" (mungkin ini berarti database yang merekam jejak produk yang dihasilkan) serta Database "Current Product Position" yang mungkin berisi data tentang produk terbaru; dan Machine Status yang berarti Status Mesin, yang masuk kedalam Proses#7 "Verify Machine status" (Proses verifikasi mesin). Oh iya, BTW ini proses ada berkat hasil dari entitas eksternal "Machine Station" (ibarat kata ini stasiun penyimpanan mesin) yang berupa Machine Status serta Product's Position yang merupakan hasil dari sensor(mesin)... Stop sampai sini dulu! mari kita lanjut ke proses nomer 2.

Sekarang kita masuk ke Proses nomer 2, "Monitor the position of all products to identify collisions" maksudnya, proses pemantauan posisi semua produk untuk mengetahui adanya bentrok. Nah, proses ini membutuhkan data dari Database "Production Track" yang berisi informasi detail tentang produk tersebut. Hasil Monitoring/Pemantauan dari proses ini masuk kedalam Database "Current Product Position" dan "Product being Manufactured" (Program tentang produknya yg sedang diproduksi massal). Hasil pemantauan ini juga bakal masuk ke Proses nomer 6, "Produce reports & Warnings" (menghasilkan laporan & kesalahan jika ada). Stop! nanti gue bakal jelasin lagi tentang Proses#6 ini. Jangan nangis! ea..

Sekarang kita masuk ke Proses nomer 3, "Monitor the postion of all products to check them against the production plan".. BUSET panjang bener! artinya kira-kira proses pemantauan posisi letak semua produk untuk menyocokkan dengan rencana produksi. Gitu deh. Proses ini membutuhkan data dari Database "Current product position" untuk mendapatkan informasi mengenai posisi produk; serta data dari Database "Production Scheduling Plan" (Rencana penjadwalan produksi) untuk mengetahui posisi yang diharapkan saat produksi. Nah, hasil dari proses ini akan masuk ke Proses#6 tadi. Proses ini juga menghasilkan "sesuatu" kedalam Database "Job" yang membawa informasi bahwa pekerjan telah selesai. Database "Job" ini mengantarkan "sesuatu" tadi menuju Proses berikutnya, Proses#4! booyah!!

Sekarang kita masuk ke Proses nomer 4, "Update production plan" atau bisa diartikan sebagai proses pembaharuan rencana produksi. Proses ini butuh data dari Database "Current product position" untuk mengetahui posisi produk saat ini (ya iya..). Proses ini nantinya akan menghasilkan data yang bakalan masuk kedalam Database "Production Scheduling Plan" tadi, berupa "completed job in product plan" yang berarti Pekerjaan yang telah selesai dalam rencana produksi. Lanjut deh..

Sekarang kita masuk ke Proses nomer 5, "Change & identify production details" yang artinya Proses merubah dan identifikasi detail produksi. Proses ini butuh data dari entitas eksternal "Production Controller" atau pengendali produksi (ini bukan avatar, lagipula produksi itu bukanlah elemen). BTW entitas eksternal ini tidak akan dibahas lebih detail lagi, sorry ya. Uhuk.. proses ini menghasilkan data yang masuk kedalam Database "Production scheduling plan" tadi berupa Perubahan untuk rencana produksi, serta kedalam Database "Product being Manufactured" berupa hal yang sama (Perubahan, red). See? kayaknya udah mulai keliatan darimana dan bakal kemana data-data ini mengalir nih!

Sekarang kita masuk ke Proses nomer 6, "Produce reports & warnings". Dalam proses ini bakal terjadi adegan reproduksi.. halah. Proses ini berupa kegiatan untuk menghasilkan laporan dan kesalahan (produksi) jika ada. Proses ini membutuhkan data mengenai produk terkait yang diambil dari Database "Product being manufactured" serta data mengenai data yang diperlukan untuk mengetahui produk yang salah sasaran/salah kirim atau terlambat produksi masuh memenuhi kriteria perencanaan produksi atau tidak, dari Proses#3. Proses ini juga membutuhkan data berupa 'Posisi letak produk yang sudah ada dan produk yang tertunda maupun di produksi ulang' dari Proses#2~ wow! semuanya saling berhubungan, dunia (DFD) memang sempit -,- | Proses ini juga membutuhkan data berupa "Production floor layout" dari Database yang bernama sama. Lanjut deh!

Sekarang kita masuk ke Proses nomer 7, "Verify machine status" yang artinya proses verifikasi status mesin. Masih ingatkan sama kejadian di Proses#1? ini lanjutannya nih. Status mesin yang merupakan dari Proses#1 ini masuk ke Proses#7, menghasilkan status mesin yang valid/SAH karena telah di-SAH-kan oleh Proses#7 (sah? sah? Alhamdulillah.. emangnya penghulu!). Status mesin yang valid ini masuk kedalam entitas eksternal "Production controller". Seperti yang gue bilang, kalo gue jelasin tentang avatar (pengendali) ini, gue gak akan mau. soalnya kalo ditulis pasti malah bikin bingung karena avatar ini merupakan penghubung "penting" dari proses-proses DFD disini. Bisa disimpulkan sendiri kalau entitas eksternal ini akan menghasilkan data yang akan masuk ke Proses#5, membutuhkan data dari Proses#6, dan sebagainya, yang mana sudah dijelaskan secara "ngaco" pada paragraf-paragraf sebelumnya. Harap maklum!

Nah akhirnya kita masuk ke Proses nomer 8, "Move Products from queue" maksudnya, proses ini menggambarkan kegiatan pemindahan produk (yang dihasilkan) dari antrian barang. Proses ini butuh "Produk" (ya iya..) dari Database "Queue" (Antrian) dan Proses#8 ini menghasilkan data berupa posisi letak produk yang akan dibawa kedalam entitas eksternal bernama "Sensor" atau #$*%# (maksudnya Pemindai barang, haha). Entitas eksternal ini menghasilkan Posisi Produk yang bakalan masuk kedalam Proses#1, "Receive & record both product & m/c status". HOREE.. HOREE.. selesai penjelasannya.

Kesimpulan yang bisa gue ambil bahwa, DFD ini menggambarkan alur data yang cukup rumit dan seperti nggak ada habisnya (muter-muter terus) ya karena wajar, soalnya DFD tidak mengenal waktu dan kapan proses ini dieksekusi. Tapi sistem yang memakai DF ini gue rasa cukup mantab dan tob markotob banget karena struktur alurnya "kokoh" dan jelas, hampir tidak ada kekurangan/kelemahan yang bisa dicari-cari lagi. Sekian dan terimakasih telah mampir, membaca, mencoba memahami, meninggalkan komentar, menyukai postingan, membagi postingan, serta MEMBERI NILAI softskill buat gu.. saya! Thanks..

sumber: bingung saya, ini gambar yang nyari temen saya (nitip) tapi saya jamin ini asli dari Springer! --> http://link.springer.com/article/10.1007/s10270-006-0013-0

Ini Namanya Data Flow Diagram

tugas awal tahun yang sangat menyenangkan.. disaat kampus-kampus lain sedang libur, cuma kampus gue yang udah masuk, plus dapet tugas dari Boss, disuruh bikin penjelasan "mendalam" mengenai Apa Itu DFD (Data Flow Diagram). Uhuk baiklah.. gue coba bikin "Segala Tentang DFD" pake bahasa sendiri, dengan gaya menulis layaknya menulis Laporan praktikum.

DFD atau Data Flow Diagram adalah sebuah diagram yang merepresentasikan alur-alur yang ada pada suatu sistem. DFD menjelaskan tentang bagaimana data-data yang ada dalam sistem itu mengalir. (bagaimana bisa mengalir? mengalir kemana? mengalir darimana? dsb). dalam DFD kita bisa mengetahui kemana data yang mengalir itu akan tersimpan. Ada satu hal yang tidak bisa "dilakukan" oleh DFD ini, yaitu DFD "tidak mampu" untuk memberikan informasi mengenai waktu proses berjalan yg digunakan aliran data tersebut.

Pada dasarnya, dalam pembuatan DFD dibutuhkan dua langkah utama. Langkah utama yang pertama adalah membuat diagram konteks. Diagram konteks dalam artian sederhana, adalah diagram yang secara umum menggambarkan keseluruhan sistem. Diagram ini bisa diartikan sebagai "sketsa" awal dari pembuatan DFD ini. Diagram konteks ini nantinya bisa berkembang lebih jauh lagi, menjadi diagram level 1, level 2, level 3 dan seterusnya. Semakin tinggi level diagram, semakin detail informasi yang diberikan. Proses "pendalaman" level diagram ini merupakan Langkah utama kedua.

Cukup jelas bukan.. kalau udah lanjut ke penjelasan yang lebih mendalam lagi.

 



 

Gambar diatas merupakan struktur DFD (Diagram konteks) secara umum.

Database pada DFD adalah sebuah entitas yang melambangkan penyimpanan data yang berasal dari/dibutuhkan oleh proses-proses yang ada pada sistem.

Process (System) pada DFD adalah sebuah entitas yang melambangkan proses (ya iya..) dengan kata lain, proses ini berarti aktivitas atau pekerjaan bisnis yang melibatkan data-data yang akan dimanipulasi atau dirubah.

Customer pada DFD adalah sebuah entitas yang melambangkan orang (orang hidup, bernyawa). Bisa juga melambangkan sistem atau sub-sistem. Orang, Sistem, dan Sub-sistem adalah sebuah "wadah" yang menjelaskan kemana data datang dan pergi.

Garis panah adalah flow atau alurnya. Arah panah menentukan segalanya. keluar ya keluar, masuk ya masuk. Pasti ngerti deh. Lanjut ke diagram level 1.

Lihat entitas System ditengah itu? nah pada pembuatan diagram level 1, entitas System akan dipecah menjadi "sub-sistem" lain yang menjelaskan secara detail dari "Sebenarnya apa aja sih System yang digunakan?"

Untuk lebih jelasnya, mari lihat gambar ilustrasi dibawah.. (ini gambar boleh ngambil dari SINI)



 

Gambar ilustrasi diatas sebenarnya sama kayak gambar diagram konteks, hanya saja posisi Database (dilambangkan dengan kota abu-abu dengan huruf D) ada di sebelah kanan.  Nah!! kali ini System sebagai Process akan dipecah menjadi tiga bagian. apa saja?



ternyata Proses yang digunakan sistem, dijabarkan lebih mendetail lagi menjadi 3 bagian, yaitu Process Order (Pemesanan), Ship Good (Pemaketan barang) dan Issue Receipt (resipien atau bisa dibilang tanda terima atau kwitansi). dengan begini, selesai sudah perubahan dari diagram konteks menjadi diagram level 1. Tapi belum sepenuhnya selesai karena masih dibutuhkan langkah selanjutnya yaitu pemberian alur arah panah..



 

Penjelasan harusnya sudah jelas, karena tanda panah sudah memberi tahu kearah mana data tersebut mengalir. Ceritanya seorang Customer  datang untuk memesan sesuatu (Process Order). Data pelanggan yang tersimpan pada database pelanggan (Customer D) diminta oleh proses pemesanan tadi. Dengan demikian, proses tersebut otomatis membuat record yang masuk kedalam database Transaksi (Transaction D).

Lalu pemesanan akan berpindah ke langkah pemaketan barang (Ship Good). Lagi lagi Data pelanggan (Customer D) diminta oleh proses pemesanan (Process Order) karena proses tersebut membutuhkan data pelanggan untuk pemaketan dan pengiriman. Process Order juga membutuhkan data transaksi (Transaction D) untuk memilih barang mana yang sesuai pesanan si pelanggan tersebut. Setelah barang selesai dipaketkan dengan benar dan tepat, ia akan memasukkan data ke Database penyimpanan barang (Inventory D).

Setelah barang disimpan, maka bisa sampai ke tangan si pelanggan. Ketika sudah sampai, pelanggan akan menerima Tanda Terima (Issue Receipt), yang Issue Receipt itu sendiri membutuhkan data yang ada pada database transaksi (Transaction D). HORE.. HORE...

 

Namun ada satu aturan lagi dalam pembuatan DFD, yaitu kita bisa merubah susuan tiap entitas demi mempermudah pembacaan DFD itu sendiri supaya nggak pusing dan arah alur tidak saling mepet bersinggungan satu sama lain. contohnya bisa dilihat pada ilustrasi dibawah ini:



dengan demikian, DFD bisa lebih mudah dibaca dan dimengerti serta jelas kemana arah tujuan datanya. dan dengan sampainya dalam paragraf ini maka gue akhiri penjelasan singkat nan mendasar tentang "Data Flow Diagram". semoga bermanfaat. #Repost dari situs tutorial yang sangat luar biasa: http://www.visual-paradigm.com/product/lz/tutorials/dfd.jsp