Senin, 29 Agustus 2016

USE-CASE dengan DFD

Model itu representasi sesuatu yang diwakilinya. DFD, Object itu termasuk model untuk mencoba menggambarkan, apa yang dialami data, apa yang dilakukan proses di dalam komputer. Kenapa harus pakai model ? Lah, software eta anu barang ghaib, pan teu tiyasa di-to'ong ku panon jelma ? Kalau kita mengintip ke dalam kotak komputer atau laptop, yang terlihat cuman chip-chip elektronik. Si softwarenya kemana ? Salah satu ciri dari model harus komunikatif. Harus bisa menyampaikan idea dari seseorang ke orang lainnya yang bekerjasama, atau yang sedang ditawari agar mau membeli si ghaib. 

Untuk komunikatif, harus pakai standar yang sudah disepakati banyak orang. Kepada calon pembeli, si software eta bisa gini, bisa gitu, nah itu cukup list fungsional saja. Modelnya sebaiknya sederhana saja, disertai penjelasan yang gamblang. Tapi kepada perajin yang disebut programmer, ya harus lebih rinci dari sekedar fungsional. Ada yang cukup dengan alur aliran data melewati proses, ada juga yang harus lebih njelimet, lebih teliti sampai kepada perubahan state-nya. Ada yang harus di-kotak-kotak dulu, dalam bentuk beberapa diagram kontek (namanya juga kontek, jadi ya harus kontekstual, supaya fokus kelompok fungsional dapat lebih tajam, dan bisa diselesaikan.) Ada juga yang harus bisa mengintegrasikan beberapa konteks pekerjaan si ghaib. Nah, kalau sudah menyebut integrasi alias kompleks alias rumit, bagaimana memodelkan struktur relasi antara diagram konteksnya (itu kalau kalau pakai DFD). 

Atau adakah hubungan antara usecase aplikasi ghaib yang satu, dengan use case aplikasi yang lain ? Bagaimana hubungan antara aplikasi yang dikerjakan oleh suatu team work ? Ini modelnya jarang ada contohnya yang bisa di copy paste.Karena untuk porsi mahasiswa, diberi satu diagram konteks atau satu use case saja sudah mabok. Layer analisis yang lebih tinggi, jarang dibahas. Sehingga tumbuh suatu dogma, bahwa bikin aplikasi itu harus dimulai dari satu use case atau satu diagram konteks. Untuk yang lebih kompleks, jarang yang berlatih. Kalau maksa, si ghaib yang kompleks dipaksa dimodelkan dengan satu unit diagram use case. Sehingga bentuknya seperti rambutan, eh maksudnya seperti kelengkeng, meureun. Mau bacanya berangkat dari mana. di akhiri dimana. Atau pakai Power Designer bajakan, maksa dimodelkan pakai satu Diagram Konteks, sehingga bentuknya seperti Chip elektroniknya MikroProsesor. he he.

Nostalgia RPL – Bagian I

Mencermati hasil tugas akhir/skripsi mahasiswa, materi kuliah yang diajarkan beberapa teman dosen, dan dokumentasi proyek yang dibuat beberapa partner kerja, masih sering ditemukan penggunaan metode/teknik dan alat bantu (tools) “gado-gado” untuk membuat perangkat lunak (software development). Sah-sah saja hal itu dilakukan asal ada penjelasan mengapa teknik dan alat bantu “gado-gado” tersebut digunakan. Juga penjelasan bagaimana penggunaan sebenarnya.
Sebagai contoh, proses bisnis yang mewakili persoalan dianalisis dengan menggunakan pendekatan konvensional, hasilnya dimodelkan dengan menggunakan flowmap atau DFD (Data Flow Diagram) fisik sistem lama. Kebutuhan fungsional perangkat lunak dianalisis dengan menggunakan pendekatan terstruktur (data flow oriented), tetapi hasilnya kadang direpresentasikan dalam bentuk DFD saja, tidak dilengkapi dengan kamus data (data dictionary), spesifikasi proses, dan ERD (Entity-Relationship Diagram). Perancangan dilaksanakan tidak dengan menggunakan pendekatan apapun, karena objek perancangannya adalah basis data dan user interface (dan itu pun sering merupakan hasil capture dari program yang sudah dibuat). Dan yang lebih aneh, implementasinya dilaksanakan dengan menggunakan bahasa pemrograman visual atau web yang sudah berbasis objek.
Kalau kita coba kilas balik ke belakang, sebenarnya teknik dan alat bantu yang disebutkan di atas punya jamannya sendiri-sendiri sesuai dengan situasi lingkungan pengolahan data dan teknik komputasi yang ada saat itu.
Teknik konvensional dengan flowchart (flowmap, system flowchart dan program flowchart) sebagai alat bantunya, serta COBOL (Common Business Oriented Languange) dan FORTRAN (FORmula TRANslation) sebagai bahasa pemrogramannya, digunakan di masa awal pemanfaatan komputer untuk membantu proses bisnis organisasi, sekitar tahun 1950an sampai pertengahan tahun 1970an. Komputer yang digunakan pada umumnya adalah mainframe dan mini computer yang ditempatkan di satu lokasi, dan bagian organisasi sebagai pemakai (user) mengaksesnya melalui dump terminal. Sistem operasi yang digunakan walaupun sudah mendukung konsep multiuser tetapi belum multiprogramming, masih menggunakan konsep batch processing.
Dengan bentuk sistem komputer seperti itu, pengolahan data hanya dapat dilakukan secara terpusat. Masing-masing bagian organisasi mempunyai perangkat lunak aplikasi sendiri-sendiri, bersifat sektoral, dan tidak terintegrasi. Aplikasi tersebut pada umumnya digunakan untuk membantu proses pengolahan data transaksi sehari-hari, seperti penjualan barang, pembelian barang, inventory, produksi, keuangan, dan penggajian (payroll). Atau untuk membantu menyelesaikan perhitungan matematika yang cukup rumit dengan jumlah data yang cukup banyak. Datanya sendiri lebih banyak disimpan dalam bentuk file, bukan dalam bentuk basis data karena DBMS (Database Management System) masih jarang, dan harganya pun sangat mahal.
Pembuatan perangkat lunak dengan menggunakan pendekatan konvensional biasanya mengikuti tahap-tahap proses sebagai berikut:
Analisis
  1. Mempelajari proses bisnis yang sedang berjalan (current system), dan memodelkan hasilnya dengan menggunakan flowmap.
  2. Membuat deskripsi untuk semua dokumen yang digunakan dalam proses bisnis.
Perancangan Global
  1. Menyusun proses bisnis baru yang dibantu komputer sesuai dengan permintaan pemakai (propose system), dan memodelkan hasilnya dengan menggunakan flowmap.
  2. Merancang “arsitektur” perangkat lunak secara keseluruhan dan memodelkannya dengan menggunakan general system flowchart.
Perancangan Rinci
  1. Merancang file data.
  2. Membuat deskripsi untuk masing-masing modul program dan memodelkannya dengan menggunakan system flowchart.
  3. Membuat struktur menu program.
  4. Merancang tata letak layar dan tata letak keluaran (print out).
Implementasi
Menulis dan menguji program.
Klik disini untuk melihat Contoh Penggunaan Metode Konvensional atau disini untuk versi updatenya.


Sumber : https://totosuharto.wordpress.com/2008/03/26/nostalgia-rpl-%E2%80%93-bagian-i/

Sistem Informasi vs RPL

Pertanyaan yang sering mengemuka saat saya menyampaikan materi kuliah Sistem Informasi atau Rekayasa Perangkat Lunak (RPL) adalah,
Apa perbedaan dan persamaan sistem informasi dengan Rekayasa Perangkat Lunak (RPL)?
Supaya tidak kemana-mana, saya coba tempatkan dulu konteks pertanyaannya. Dalam konteks pengembangan (development) dari suatu proyek IT atau tugas akhir, substansi perbedaannya terletak pada objek yang dikembangkan, sehingga produk (output) yang dihasilkannya pun berbeda.
Objek pengembangan sistem informasi adalah sistem informasi. Untuk proyek pengembangan sistem informasi secara total,
proyeksisfo
Objek pengembangan perangkat lunak tentunya perangkat lunak, yaitu program, (basis) data, dan dokumen-dokumen yang terkait dengan proses pengembangannya.
Ruang lingkup pekerjaan dan produk yang dihasilkan dari pengembangan sistem informasi secara total meliputi,
totalsystemdevelopment
outputproyek1
Pada umumnya pengembangan sistem informasi secara total hanya sekali dilaksanakan, yaitu di awal pembentukan sistem informasi. Untuk proyek-proyek berikutnya, juga tugas akhir, objek yang dikembangkan lebih ke aplikasi dan basis datanya.
applicationdevelopment
outputproyek2
Pada keadaan inilah pengembangan sistem informasi menjadi sama ruang lingkup dan produknya dengan pengembangan perangkat lunak.
Semoga bermanfaat.
Sumber : https://totosuharto.wordpress.com/2008/11/11/sistem-informasi-vs-rpl/