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.
Senin, 29 Agustus 2016
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
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/
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
- Mempelajari proses bisnis yang sedang berjalan (current system), dan memodelkan hasilnya dengan menggunakan flowmap.
- Membuat deskripsi untuk semua dokumen yang digunakan dalam proses bisnis.
- Menyusun proses bisnis baru yang dibantu komputer sesuai dengan permintaan pemakai (propose system), dan memodelkan hasilnya dengan menggunakan flowmap.
- Merancang “arsitektur” perangkat lunak secara keseluruhan dan memodelkannya dengan menggunakan general system flowchart.
- Merancang file data.
- Membuat deskripsi untuk masing-masing modul program dan memodelkannya dengan menggunakan system flowchart.
- Membuat struktur menu program.
- Merancang tata letak layar dan tata letak keluaran (print out).
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,
Objek pengembangan sistem informasi adalah sistem informasi. Untuk proyek pengembangan sistem informasi secara total,
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,
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.
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/
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,
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,
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.
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/
Langganan:
Postingan (Atom)