Universitas Bunda Mulia Program Studi Sistem Informasi Analisis dan Perancangan SISFO (Bahan Pelengkap E-Learning) I Gusti Nguah Suryantara, S.Kom., M.Kom (c)032009 Untuk Kalangan Sendiri
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Universitas Bunda Mulia
Program Studi Sistem Informasi
Analisis dan Perancangan SISFO
(Bahan Pelengkap E-Learning)
I Gusti Nguah Suryantara, S.Kom., M.Kom (c)032009
Untuk Kalangan Sendiri
2
ANALISIS dan PERANCANGAN SISTEM INFORMASI
Halaman BAB 1 TAHAPAN PENGEMBANGAN SISFO 4 Pendahuluan Sistem Pengertian sistem Karakteristik sistem Pengertian sub sistem Sistem yang buruk Beberapa konsep sistem yang penting Data Informasi Sistem Informasi Sistem Informasi Manajemen Sistem Informasi Bisnis Sistem Analisis dan Desain Unsur Yang Terlibat Dalam Pengembangan Sistem Pengguna sistem Perancang sistem Siklus Hidup SISFO Tahap Perencanaan (waterfall, iterasi dan spiral) Tahap Pengembangan SISFO Tahap Evaluasi Perubahan Dalam Analisa Sistem Perancangan SIFO BAB 2 ALAT PEMODELAN SISTEM 20 Metodologi Berorientasi Keluaran Metodologi Berorientasi Proses
Data Flow Diagram (DFD) / Diagram Aliran Data. Data Dictionary (DD) / Kamus Data. Process Specification (PS) / Proses Spesifikasi. State-Trasition Diagram (STD). Block Chart Diagram (BCD). System Procedure Diagram (SPD).
Metodologi Beroirentasi Data ERD
Metodologi Berorientasi Objek
3
BAB 3 MENYEIMBANGKAN MODEL 89 DFD vs DD DFD vs PS PS vs DFD DD vs DFD vs PS ERD vs DFD vs PS DFD vs STD BAB 4 TAHAPAN PENGEMBANGAN SISFO 109 Survei Sistem Analisa Sistem Desain Sistem Pembuatan Sistem Implementasi Sistem Pemeliharaan Sistem BAB 5 TEKNIK YANG DIGUNAKAN DALAM PENGEMBANGAN SISFO 118 Manajemen Proyek Kegiatan pimpinan proyek Diagram aktivitas dan jadwal Walktrough Pengumpulan Fakta Wawancara Dafatar pertanyaan Pengamatan langsung Membaca buku sistem dan dokumen Presentasi oleh user BAB 6 PENGANTAR UML (OOA/OOD) 123 Pendahuluan Apa Itu UML Konsep Dasar UML Pengantar UML
Use Case Diagram Class Diagram State Chart Diagram Activity Diagram Sequence Diagram Collaboration Diagram Component Diagam Deployment Diagram
4
TAHAPAN PENGEMBANGAN SISFO
Setelah memperlajari BAB Setelah memperlajari BAB Setelah memperlajari BAB Setelah memperlajari BAB 1111 ini diharapkan mahasiswa memah ini diharapkan mahasiswa memah ini diharapkan mahasiswa memah ini diharapkan mahasiswa memahami dengan ami dengan ami dengan ami dengan
baik baik baik baik tahapantahapantahapantahapan----tahapantahapantahapantahapan pengembangan sistem informasi menggunakan pengembangan sistem informasi menggunakan pengembangan sistem informasi menggunakan pengembangan sistem informasi menggunakan
Waterfall, Iterasi dan SpiralWaterfall, Iterasi dan SpiralWaterfall, Iterasi dan SpiralWaterfall, Iterasi dan Spiral dalam mencapai daur hisup sistem. dalam mencapai daur hisup sistem. dalam mencapai daur hisup sistem. dalam mencapai daur hisup sistem.
Materi yang dibahas dalam bab 1 ini meliputi
- Pendahuluan
- Unsur Yang terlibat Dalam Pengembangan Sistem
- Siklus Hidup SISFO
- Perubahan Dalam Analisa Sistem
- Perancangan SISFO
BAB 1
5
1.1. PENDAHULUAN Analisa sistem mempelajari interaksi yang sepenuhnya rumit, tidak terdefinisi, dan sukar antara manusia, kelompok manusia, komputer dan organisasi. Masalah ini menjadi lebih pelik karena suatu sistem tidak pernah dianggap selesai. Seringkali, status selesainya sistem diberikan karena dapat digunakan pada waktu yang relatif lama. Pada abada informasi sekarang ini sulit dibayangkan ketidak tergantungan terhadap sistem terlepas dari pada apapun latar belakang seseorang. Melalui pengertian tentang sistem kita akan sadar bahwa kita hidup dalam dunia sistem, sistem dalam sistem, yang meruapkan bagian dari sistem yang lebih besar lagi. Melalui materi ini mahasiswa diharapkan mampu menjadi seorang analisa sistem, mengerti dan mengetahui apa sebenarnya sistem tersebut bagaimana sistem dibuat melalui pendekatan tertentu, komunikasi dengan pemakai untuk mengetahui esensi sistem, dan untung rugi pengembangan sistem. Bagaimanapun juga untuk lebih jauh memahami sistem dibutuhkan pendekatan yang berorientasi pada dunia nyata. 1.1.1. Sistem Sistem terdiri dari komponen-komponen yang saling berkaitan bekerja sama untuk mencapai suatu tujuan. Pada dasarnya ada dua jenis sistem yaitu:
1. Sistem alamai, seperti: sistem tata surya, sistem galaksi, sistem reproduksi dan lain sebagainya.
Gambar 1.1 Sistem planet dalam tata surya (sistem alami)
Gambar 1.2 Sistem galaksi (sistem alami)
6
Gambar 1.3 Sistem reproduksi (sistem alami)
2. Sistem buatan manusia, seperti: sistem penjualan, sistem akuntansi, sistem hukum
dan lain sebagainya.
Gambar 1.4 Sistem akuntansi(sistem buatan manusia)
Gambar 1.5 Sistem hukum (sistem buatan manusia)
Gambar 1.6 Sistem penjualan(sistem buatan manusia)
7
Sistem alami dibagi menjadi 2 yaitu: 1. Sistem fisik, seperti sistem molekul, luar angkasa. 2. Sistem kehidupan, seperti sistem tumbuhan, sistem manusia, dll.
Sedangkan sistem buatan manusia umumnya dibagi berdasarkan spesifikikasi tertentu seperti sistm sosial (hukum, doktrin, seragam), sistem organiasi (perpustakaan), sistem transportasi (jaringan jalan raya, kanal, udara, laut), sistem komunikasi (telepon, teleks, sinyal asap), sistem produksi (pabrik), sistem keuangan (akuntansi, inventori, buku besar). Sistem yang akan kita pelajari sistem yang terotomasi, yang merupakan bagian dari sistem buatan manusia dan berinteraksi atau dikontrol satu atau lebih komputer sebagai bagian dari masyarakat modern. Sistem terotomasi mempunyai sejumlah komponen yaitu:
1. Perangkat keras (CPU, disk, terminal, printer, tape dll). 2. Perangkat lunak (sistem operasi, sistem database, program pengontrol komunikasi,
program aplikasi, dll). 3. Personil (yang mengoperasikan sistem, menyediakan masukan, mengkonsumsi
keluaran dan melakukan aktivitas manual yang mendukung sistem) 4. Data (yang harus tersimpan dalam sistem dalam jangka waktu tertentu). 5. Prosesdur (intruksi dan kebijakan untuk mengoprasikan sistem).
Sistem terotomasi terbagi dalam sejumlah kategori yaitu: 1. On-line system, sistem yang menerima secara langsung masukan pada area dimana
mereka dimasukkan, dan menghasilkan keluaran (yang dapat berupa hasil komputasi) diarea dimana mereka diperlukan. Area sendiri dapat terpisah pisah dalam skala misalnya ratusan kilometer. Biasanya digunakan bagi reservasi angkutan udara, perbankan, pemesana tiket pesawat, dll.
2. Real-time system, sistem real time adalah mekanisme pengontrolan perekaman
data, pemrosesan yang sangat cepat dengan hasil yang dapat diterima dalam waktu yang relatif sama. Perbedaanya dengan sistem on-line adalah satuan waktu yang digunakan, real time biasanya seperseratur atau seper seribu detik, sedangkan pada online masih dalam sakala detik. Sistem real time biasanya digunakan untuk sistem traffic controler, peluru kendali dan lain sebagainya. Perbedaan lainnya online sistem biasanya berinteraksi dengan pemakai, sedangkan real time berinteraksi dengan pemakai dan lingkungan yang dipetakan.
3. Decision support system + strategic planning system, sistem yang memproses
transaksi organiasi secara harian, dan membantu para manajer mengambil kputusan, mengevalasi dan menganalisa tujuan organiasi. Digunakan untuk sistem penggajian, sistem pemasaran, sistem akuntanasi, dll.
4. Knowledge-based system, program komputer yang dibuat mendekati kemampuan
dan pentehauan seorang pakar, umumnya menggunakan prangkat keras dan perangkat lunak khusus seperti LISP dan PROLOG, aplikasi dibidang kecerdasan buatan.
8
1.1.2. Pengertian Sistem Menurut Scott (1996), Sistem terdiri dari unsur-unsur seperti masukkan (input), pengolahan (processing), serta keluaran (output).
Gambar 1.7 Model sistem
Menurut Mc. Leod (1995), Sistem sebagai sekelompok elemen-elemen yang terintegrasi dengan maksud yang sama untuk mencapai suatu tujuan.
Gambar 1.8 Model hubungan elemen-elemen dalam sistem
1.1.3. Karakteristik Sistem Untuk memahami atau mengembangkan suatu sistem, maka perlu membedakan unsur-unsur dari sisem yang membentuknya. Berikut ini adalah karakteristik sistem yang dapat membedakan suatu sistem dengan sistem yang lainnya.
1. Batasan (boundray), yang menjadi batasan sistem, yang mana termasuk didalam sistem dan yang mana diluar sistem.
2. Lingkungan (environment), segala sesuatu diluar sistem, lingkungan yang menyediakan asumsi, kendala, dan input terhadap suatu sistem.
3. Masukkan (input), sumber daya (data, bahan baku, peralatan, energi) dari lingkungan yang dikonsumsi dan dimanipulasi oleh suatu sistem.
4. Keluaran (output), sumber daya atau produk (informasi, laporan, dokumen, tampilan layar komputer, barang jadi) yang disediakan untuk lingkungan sistem oleh kegiatan dalam suatu sistem.
5. Komponen (component), kegiatan-kegiatan atau proses dalam suatu sistem yang mentransformasikan input menjadi bentuk setengah jadi (output). Komponen ini bisa merupakan subsistem dari sebuah sistem.
6. Penghubung (interface), tempat dimana komponen atau sistem dan lingkungannya bertemu atau berinteraksi.
7. Penyimpanan (storage), area yang dikuasai dan digunakan untuk penyimpanan sementara dan tetap dari informasi, energi, bahan baku dan sebagainya.
9
1.1.4. Pengertian Sub Sistem Suatu sistem yang komplek biasanya tersusun dari beberapa subsistem. Subsistem bisa dijelaskan sebagai sebuah sistem dalam sistem yang lebih besar. Setiap sub sistem bisa terdiri dari beberapa subsistem.
Gambar 1.9 Gambaran sub sistem dalam sistem
Sistem secara umum terdiri dari sejumlah prinsip yaitu:
1. Sistem yang terspesialiasi, adalah sistem yang sulit diterapkan pada lingkungan yang berbeda (misalnya sistem biologi, ikan yang dipindahkan ke darat).
2. Sistem yang besar, adalah sistem yang sebagaian besar sumber dayanya melakukan perawatan harian (misalnya dinosaurus menghabiskan sebagain besar masa hidupnya dengan makan dan makan).
3. Sistem selalu merupakan bagian dari sistem yang lebih besar, dan dapat terbagi menjadi sistem yang lebih kecil.
4. Sistem hampir selalu berkembang. 1.1.5. Sistem Yang Buruk Untuk menghindari pengembangan suatu sistem yang buruk, perlu diketahui beberapa ciri-ciri dari sistem yang buruk:
• Tidak memenuhi kebutuhan pengguna. • Performance buruk. • Reliabilitas rendah. • Kegunaan rendah.
1.1.6. Beberapa Konsep Sistem Yang Penting Beberapa konsep yang penting dalam pengembangan sistem, yaitu:
1. Dekomposisi (Pembagian sistem kedalam komponen-komponen yang lebih kecil). 2. Modularitas (Sistem yang besar terbagi menjadi subsistem-subsistem yang relatif
sama ukuranya, dengan modul-modul ini maka beban kerja mengembangkan sistem bisa didistribusikan secara merata).
3. Coupling (Modul-modul yang saling bergantung harus dipasangkan (di-couple)) 4. Kohesi (Kelompok modul harus dianalisis besama-sama dengan kelompok modul
yang saling berkohesi)
10
1.1.7. Data Data mengandung arti kumpulan dari fakta atau kejadian-kejadian. Data belum memiliki arti lebih. 1.1.8. Informasi Informasi merupakan proses lebih lanjut dari data dan memiliki nilai tambah atau dapat dikatakan informasi adalah data yang diolah dan berguna bagi sipemakai. Dari segi kualitas informasi harus dapat memenuhi syrat-syarat sebagai berikut:
• Lengkap. • Akurat. • Relevan. • Tepat waktu.
Gambar 1.10 menggambaran data yang diproses menjadi informasi 1.1.9. Sistem Informasi Sistem informasi dapat didefinisikan sebagi suatu sistem yang dibuat oleh manusia yang terdiri dari komponen-komponen dalam organisasi untuk mencapai suatu tujuan yaitu menyajikan informasi. Komponen sistem informasi terdiri dari:
• Hardware. • Software. • Data. • Manusia. • Prosedur. • Input. • Proses. • Output. • Penyimpanan. • Control.
11
1.1.10. Sistem Informasi Manajemen Sistem informasi manajemen menyajikan informasi untuk mendukung operasional dan fungsi mengambil keputusan menajemen dengan mempertimbangkan informasi apa, untuk siapa, dan kepan harus disajikan. Sistem informasi manajemen terdiri dari sub sistem yaitu:
• Sistem Inforamsi Akuntansi. • Sistem Informasi Personalia. • Sistem Informasi Pemasaran. • Sistem Informasi Pemebelian. • Sistem Informasi Persediaan. • Sistem Informasi Disteribusi.
1.1.11. Sistem Informasi Bisnis Sebelum membahas mengenai sistem informasi bisnis kita lihat definisi dari: Manajemen:
1. Adalah suatu proses penggunaan sumber daya secara efisien dan efektif untuk mencapai sasaran.
2. Pejabat / orang yang bertangung jawab atas jalannya perushaan atau organisasi. Bisnis:
Suatu kegiatan (badan atau perseorangan) memasarkan produk atau jasa dengan tujuan memperoleh laba, atau secara singkat disebut juga jual beli.
1.1.12. Sistem Analisis dan Desain Sistem analisis dan desain dapat dipandang dari dua kegiatan utama yaitu:
• Sistem analisis adalah suatu proses untuk memahami sistem yang ada, termasuk mendiagnosa masalah dan memberikan solusi penyelesaian. Sistem analisis sebagai karier sering juga disebut software engineer, sistem analyst programmer, information sistem engineer atau sistem engineer.
• Sistem desain yaitu, suatu proses mencakup perencanaan desain dan implementasi
sistem yang baru. Pengetahuan yang harus dimiliki oleh sistem analis antara lain:
• Pemahaman terhadap teknologi informasi. • Pemahaman terhadap bisnis secara umum. • Keahlian dalam pemecahan masalah. • Keahlian dalam komunikasi antar personel. • Memahami metodologi pengembangan sistem informasi.
12
1.2. UNSUR YANG TERLIBAT DALAM PENGEMBANGAN SISTEM
1.2.1. Pengguna Sistem
• User, dapat dikatagorikan sebagai end-user (operator) dan user-manager yang mengawasi pekerjaan end-user.
• Manajemen, memegang peranana penting dalam suatu sistem inforamsi termasuk menyetujui rencana pengembangan sistem dan penyediaan dana.
1.2.2. Perancang Sistem Perancangan sistem yang dimasukkan disini mencakup, analisa, desain, implementasi dan pemeliharaan, tediri dari:
• Project coordinator. • Sistem analyst dan Design. • Programmer. • Network Designer. • Technician (Hardware). • Database Administrator. • Documenter. • Software Tester. • Graphic Desinger.
1.3. SIKLUS HIDUP SISTEM INFORMASI Siklus hidup sistem informasi dimulai dari perencanaan, pengembangan (survei, analisa, desain, pembuatan, implementasi, pemeliharaan) dan dievaluasi secara terus menerus untuk mendapatkan apakah sistem informasi tersebut masih layak diaplikasikan, jika tidak, sistem informasi tersebut akan diganti dengan yang baru dan dimulai dari perencanaan kembali.
Gambar 1.11 Siklus hidup sistem informasi
13
1.3.1. Tahap Perancangan Perencanaan pengembanan sistem informasi bertujuan untuk mengidentifikasi dan memprioritaskan sistem informasi apa yang akan dikembangkan, sasaran yang ingin dicapai, jangka waktu pelaksanaan serta mempertimbangkan dana yang tersedia dan siapa yang akan melaksanakan. Perencanaan sistem dapat mencakup keseluruhan unit bisnis maupun secara departemen dengan memperhatikan misi dari usaha bisnis tersebut. Perencanaan dimulai setelah adanya usulan baik dari intern maupun ekstern, dilanjutkan dengan keputusan manajemen.
1. Usulan Usulan perubahan sistem dari internal biasanya berisi: adanya permasalahan yang dihadapai sistem lama seperti biaya operasional yang tinggi, pembuatan order yang sering terlambat, dan laporan yang tidak up to date. Selain masalah-masalah seperti diatas usulan juga dikarenakan penyempurnaan sietem.
2. Keputusan Manajemen Usulan-usulan tersebut harus mendapatkan persetujuan dari manajeen karena menyangkut biaya, perubahan sistem kerja, keamanan data, hubungan dengan pelanggan, dan sebagainya.
3. Kerangka Acuan Kerja
Setelah mendapatkan persetujuan dari manajemen selanjutnya dibentuk tim yang dapat terdiri dari divisi-divisi yang terkait untuk menyusun kerangka acuan kerja yang menyangkut: • Latar belakang • Maksud dan tujuan • Sasaran proyek • Ruang lingkup pekerjaan • Jangka waktu pelaksanaan • Prioritas pekerjaan
4. Anggaran (dana)
Berdasarkan kerangka kerja acuan kerja diatas, disusunlah anggaran untuk hardware, software, pelatihan SDM, pemeliharaan dan cadangan dana untuk keperluan yang tidak terduga.
5. Penunjukan Tim Pelaksana
Setelah semua kegiatan diatas diketahui, selanjutnya diputskan apakah pengembangan sistm informasi akan dilakukan oleh perushaan atau pihak konsultan. Setelah meneteapkan pelaksanaana, diminta untuk memasukkan proposal pelaksanaan sistem informasi sesuai dengan acuan kerja. Proposal tersebut akan dievaluasi untuk menentapkan apakah proyek tersebut layak dilaksanakan atau tidak.
14
6. Menilai Kelayakan Proyek Penilaian kelayakan proyek mencakup kelayakan opeasional, teknis dan ekonomis. Dalam praktek, yang dominan dinilai umumnya aspek ekonomisnya (dana). • Kelayakan operasional. • Kelayakan teknis. • Kelayakan ekonomis.
1.3.2. Tahap Pengambangan Sistem Informasi Tahap pengembangan sistem informasi disebut juga Siklus Hidup Pengembangan Sistem Informasi yang garis besarnya (tahapan umumnya) terdir dari enam langkah. Tahapan-tahapan pekerjaan dalam pelaksanaan tidak harus kaku namun dapat disesuaikan dengan kebutuhan. 1.3.2.1.Tahapan Utama Pengembangan SISFO Tahapan pengembahan sistem informasi yang umum ada 6 tahapan yaitu:
• Survei, bertujuan untuk mengetahui ruang lingkup pekerjaan. • Analisis, bertujuan untuk memahami sistem yang ada, mengidentifikasi masalah
dan mencari solusinya. • Desain, bertujuan mendesain sistem baru yang dapat menyelesaikan masalah-
masalah yang dihapdai perusahaan. • Coding (program), membuat sistem baru / membuat program sistem yang akan
dikemabangkan. • Impelementasi, bertujuan untuk mengimplementasikan istsem yang baru. • Pemeliharaan, bertujuan agar sistem dapat berjalan secara optimal.
1.3.2.2.Penerapan Tahapan Pengembangan SISFO Beberapa cara dapat ditempuh dalam penerapan tahapan pengembangan sistem informasi, yaitu secara berurutan (waterfall model), iterasi dan spiral. Waterfal, Setipa tahapan harus diselesaikan terlebih dahulu secara penuh sebelum meneruskan ke tahapan berikutnya, dengan tujuan menghindari terjadinya pengulangan tahapan tersebut. Proses ini lebih cocok untuk diterapkan dalam pengembangan “mass product”.
Gambar 1.12 Tahapan Waterfal Model
15
Iterasi dan Spiral, tahapan-tahapan tersebut dilakasanakan dengan memakai teknik iterasi / pengulangan dimana suatu proses dilaksanakan secara berulang-ulang sampai mendapatkan hasil yang diinginkan. Umumnya proses ini diaplikasikan untuk pembuatan “Tailor Made Product”
Gambar 1.13 Tahapan Iterasi model
Gambar 1.14 Tahapan Spiral
16
1.3.3. Tahap Evaluasi Evaluasi perlu dilakukan untuk meastikan bahwa pelaksanaan pengembangan sesuai dengan rencana yang telah ditetapkan baik dari segi waktu, biaya maupun secara teknis. 1.3.3.1.Saat Pengembangan Pada saat pengembangan sistem informasi perlu dievaluasi apakah sesuai dengan rencana, jadwal dan sebagainya. Dengan demikian setiap penyimpanan dapat diatasi sedini mungkin. 1.3.3.2.Saat Penyerahan Sistem yang telah dikembangkan, perlu dites apakah program dapat berfungsi sebagai mana yang diharapkan seperti efisiensi sistem baru, waktu respon, kelengkapan informasi yang disajikan dan sebagainya. Setelah semua dievaluasi, dan sistem tersebut dinyatakan dapat diterima, maka perlu dibuat suatu berita acara penyerahan sebagai bukti telah selesainya pengembangan sistem tersebut. 1.3.3.3.Saat Pengoprasian Dalam pengoperasian sehari-hari sistem tersebut masih perlu dievaluasi, tetapi tidak perlu seintensif pada saat pengembangan ataupun pada saat penyerahan. Evaluasi dapat dilakukan misalnya setengah tahun, satu tahun atau sesuai kebutuhan. Hasil dari proses evaluasi menjadi masukkan bagi manajemen dalam menentukan apakah sistem yang berjalan harus dipertahankan atau diganti dengan sistem yang baru. Jika diambil keputusan untuk membangun sistem yang baru menggantikan sistem yang ada, maka harus kembali ke proses perencanaan. Demikian proses ini berjalan secara terus menerus, sehingga membentuk sebuah siklus.
1.4. PERUBAHAN DALAM ANALISA SISTEM A. Analisa terstruktur, kelemahan pengembagan sistem dengan cara klasik antara
lain cendrung monoitik (pelaku sistem seringkali harus membaca keseluruhan laporan pengembangan sistem hanya untuk mengetahui bagian tertentu), redudansi (informasi yang sama sering muncul berulang-ulang pada bagian yang berbeda, sehingga kemungkinan inkonsistensi menjadi besar), amgigous (statemen detail kebutuhan pemakai diinterpretasikan berbeda oleh pelaku sistem), dan impossible to maintain (fungsi spesifikasinya seringkali sudah terlalu kuno untuk dikembangkan). Karena itu harus dilakukan perubahan yang mendasar pada cara merepresentasikan fungsi sepsifik sistem, yaitu dengan graphic (komposisi dari sejumlah diagram yang didukung informasi detail tekstual), partitioned (tidak harus punya ketergantungan dengan fungsi spesifik lainnya), dan minimally redudant (sehingga perubahan pada pendefinisian kebutuhan pemakai dapat dikonsentrasikan pada satu bagian saja dalam spesifikasi).
17
B. Perubahan dalam analisa terstruktur klasik, perubahan ini antara lain mencakup mengelimasi proses mempelajari sistem lama, menggabungkan model fisik dan modl lojik, menerapkan time-dependent untuk membantu memetakan sinkronisasi dan koordinasi dalam pemodelan, dan menggabungkan sejumlah perangkat pemodelan.
C. Perangkat analisa terotomasi, sekarang ini banyak alat bantu perancangan sistem
seperti CASE (Computer Aided Software Engineering), UML (Uiform Modeling Language), VISO, dll.
D. Penggunaan prototipe, karena pemakai seringkali kesulitan untuk memahami model
grafik analisa terstruktur maka, menggunakan prototipe menjadi jalan keluar yang tepat. Hanya saja prototipe seringkali menitik beratkan pemodelan hanya pada aspek human interface dalam peracanagan sistem.
E. Penggabungan analisa dan desain sistem, hal yang harus diperhatikan dalam point
ini adalah, penggabungan merupakan cara yang tepat agar tidak terjadi salah pengertian antara para pelaku sistem.
1.5. PERANCANGAN SISTEM INFORMASI Perancangan suatu sistem dilakukan untuk menggantikan, memperbaiki sistem yang lama atau memang belum ada. Sistem yang lama perlu diperbaiki atau digantikan karena beberapa hal, yaitu:
1. Adanya permasalahan yang timbul pada sistem yang lama. 2. Untuk meraih kesempatan yang ada atau menciptakan kesempatan yang ada. 3. Adanya intsruksi baik dari internal binis atau external seperti pemerintahan.
Penggantian atau perbaikan dari sistem yang lama diharapkan dapat memberikan peningkatan-peningkatan terhadap sistem yang baru. Peningkatan tersebut dapat berupa:
1. Kinerja, Pada sistem yang baru diharapkan dapat meningkatkan jumlah pekerjaan yang dilakukan dalam satu waktu dan waktu yang lebih singkat dalam melakukan pekerjaan tersebut.
2. Informasi, Pada perancangan sistem yang baru diharapkan dapat memberikan
informasi yang lebih berkualitas.
3. Ekonomi, Peningkatan diharapkan dapat memberikan keuntungan atau penekanan terhadap biaya.
4. Pengendalian, Peningkatan terhadap pengendalian untuk mendeteksi dan
memperbaiki kesalahan serta kecurangan yang akan terjadi.
5. Efisien, Peningkatan pengunaan sumber daya secara optimal.
6. Pelayanan, Peningkatan terhadap pelayanan yang diberikan oleh sistem.
18
1.6. LATIHAN 1. Pandanglah universitas anda sebagai suatu sistem. Identifikasi komponen-
komponen apa saja yang menyusun sistem tersebut dan jelaskan peranan-peranan masing-masing komponen tersebut. Bagaimana masing-masing komponen tersebut bekerja untuk mendukung tujuan utama organisasi.
2. Pandanglah siklus kegiatan yang ada dalam perpustakaan universitas anda,
kemudian identifikasi komponen apa saja yang terlibat dalam sistem perpustakaan anda, jelaskan peranan masing-masing penyusun sistem perpustakaan di universitas anda dalam mendukung tujuan utam organisasi.
Dalam sistem yang lebih besar di lingkungan universitas anda, sistem perpustakaan apakah merupakan suatu sistem utama atau merupakan sebuah sub sistem dalam lingkungan universias, berikan pendapat anda. Bila diperpustakaan universitas anda akan dilakukan komputerisasi, berikan gambaran sistem yang akan ada rancang.
19
KERTAS KERJA (1)
20
ALAT PEMODELAN SISTEM
Setelah memperlajari BAB 2 ini diharapkan mahasiswa Setelah memperlajari BAB 2 ini diharapkan mahasiswa Setelah memperlajari BAB 2 ini diharapkan mahasiswa Setelah memperlajari BAB 2 ini diharapkan mahasiswa mengetahuimengetahuimengetahuimengetahui dengan dengan dengan dengan
baik alatbaik alatbaik alatbaik alat----alat bentu perancangan sistem yang dapat alat bentu perancangan sistem yang dapat alat bentu perancangan sistem yang dapat alat bentu perancangan sistem yang dapat digunakan untuk digunakan untuk digunakan untuk digunakan untuk
memodelkamemodelkamemodelkamemodelkan sistem informasi, baik menggunakan pemodelan n sistem informasi, baik menggunakan pemodelan n sistem informasi, baik menggunakan pemodelan n sistem informasi, baik menggunakan pemodelan trandisonalm trandisonalm trandisonalm trandisonalm
struktur maupun pemodelan struktur maupun pemodelan struktur maupun pemodelan struktur maupun pemodelan berbasis berbasis berbasis berbasis objek.objek.objek.objek.
Materi yang dibahas dalam bab 2 ini meliputi
- Metodologi Berorientasi Keluaran
- Metodologi Berorientasi Proses
- Metodologi Berorientasi Data
- Metodologi Berorientasi Objek
BAB 2
21
2.1. KONSEP DASAR Ada tiga alasan mengapa kita melakukan pemodelan sistem, yaitu:
1. Dapat memfokuskan perhatian pada hal yang lebih penting dalam sistem tanpa mesti terlibat lebih jauh.
2. Mendiskusikan perubahan dan koreksi terhadap kebutuhan pemakai dengan resiko dan biaya minimal.
3. Menguji pengertian penganalisa sistem terhadap kebutuhan pemakai dan membantu pendesaian sistem dan programmer dalam membangun sistem.
Tetapi ada banyak bentuk model yang dapat kita gunakan dalam perancangan sistem antara lain model narasi, model prototipe, model grafis, dll. Dalam hal ini tidak jadi masalah model mana yang akan digunakan, yang jelas harus sampai mereperesentasikan visualisasi bentuk sistem yang diinginkan pemakai, karena sistem akhir yang dibuat bagi pemakai akan diturunkan dari model. Secara garis besar model yang digunakan seharusnya mempunyai sejumlah karaktersitik, yaitu:
• Dibuat dalam bentuk grafis dan tambahan keterangan secara tekstual. • Dapat diamati dengan pola top-down dan partitioned. • Memenuhi persyaratan minimal redudancy. • Dapat merepresentasikan tingkah laku sistem.
Dari perkembangannya sampai sekarang, metodologi sistem informasi dapat dikelompokkan menjadi empat ditinjau dari alat untuk membuat model dan paradigma. Sedangkan tahapan pengembangan sistem informasi (waterfall, iterasi, spiral) pada prinsipnya tidak mengalami perubahan yang mendasar, yang berbeda hanya pada sistem konvensional, mensyaratakan setiap tahapan harus diselesaikan secara tuntas sebelum memasuki tahapan selanjutnya. Sedangkan konsep baru lebih menekankan adanya iterasi atau pelaksanaan secara spiral. Keempat metodologi yang disebutkan diatas terdiri dari:
1. Metodologi berorientasi keluaran (output). 2. Metodologi berorientasi proses (process).
- Data Flow Diagram (DFD) / Diagram Aliran Data. - Data Dictionary (DD) / Kamus Data. - Process Specification (PS) / Proses Spesifikasi. - State-Trasition Diagram (STD). - Block Chart Diagram (BCD). - System Procedure Diagram (SPD).
3. Metodologi berorientasi data
- Entity Relationship Diagram (ERD) / Hubungan Entiti.
4. Object Oriented / Metodologi Berorientasi Objek.
22
2.2. METODE BERORIENTASI KELUARAN Sebelum alat bantu pemodelan sistem dikembangkan, kebanyakan para perancang sistem menggunakan pendekatan berbasis keluaran atau sering disebut pendekatan klasik (trasisononal). Metode ini diperkenalkan sekitar tahun 1960 dengan memberikan tahapan dalam pengembangan sistem tanpa dibekali dengan teknik dan peranti (tools) yang memadai seperti cara menganalisa, menggambarkan sistem, sehingga sering juga disebut metodologi System Development Life Cycle (SDLC). Hal diatas tidak menjadi maslah untuk pengembangan sistem yang kecil dimana sistem analisa, desain dan programmer ditangani oleh satu orang. Bagaimana dengan pengembangan sistem yang melibatkan tim di mana sistem analisa, desain dan programmer terdiri dari orang yang berbeda ?, disini akan timbul kesulitan dalam menyampaikan hasil analisa ke orang yang mendesain dan dari orang yang mendesain ke programmer, karena penggunaan narasi dapat menimbulkan persepsi yang berlainan. Foklus utama metodologi ini pada keluaran / output seperti laporan penjualan, laporan pembelian, dan sebagainya.
Gambar 2.1 Fokus utama metodologi berorientasi keluaran
2.3. METODOLOGI BERORIENTASI PROSES Metodologi ini disebut juga dengan metodologi analisa dan desain, diperkenalkan sekitar tahun 1970 dan masih mendominasi dalam sistem pengembangan sistem sampai saat ini, karena metodologi ini telah dilengkapi dengan alat-alat (tools) dan teknik-teknik yang dibutuhkan dalam pengembangan sistem khususnya pemrograman terstruktur / modular. Fokus utama metodologi ini pada proses dengan menggambarkan dunia nyata memakai diagram arus data.
Gambar 2.2 Fokus utama metodologi berorientasi proses
23
2.3.1. DATA FLOW DIAGRAM (DFD) Model ini menggambarkan sistem sebagai jaringan kerja antar fungsi yang berhubungan satu sama lain dengan aliran dan penyimpanan data. Sebagai perangkat analisis, model ini hanya mampu memodelkan sistem dari satu sudut pandang yaitu sudut pandang fungsi. Pada sejumlah kasus model ini biasanya dinamakan berbeda seperti buble diagram, process model, work flow diagram, dan function model. Ada empat komponen daalam model ini yaitu: • Proses, komponen pertama dalam model ini dinamakan proses, kadang-kadang
dinamakan juga gelembung (bubble), fungsi, dan transofrmasi. Proses menunjukkan tenasformasi dari masukkan menjadi keluaran, dalam hal ini sejumlah masukkan dapat menjadi hanya satu keluaran ataupun sebaliknya. Proses direpresentasikan dalam bentuk lingkaran (bisa juga oval, atau bujur sangkar dengan sudut melengkung). Proses umumnya didefinisikan dengan kata tunggal, atau kalimat sederhana. Pada sejumlah kasus definisi ini dapat berupa nama departemen, bagian dalam suatu organisasi, komputer perlatan mekanik. Sehingga definisi tadi lebih sering mengidentifikasi subyek proses daripada obyek proses itu sendiri.
Tutup
Buku
Notasi Yourdan/DeMarco Notasi Gane & Sarson • Alrian, aliran direpresentasikan menggunakan panah yang menunjukkan ke atau dari
proses. Arah panah menunjukkan arah aliran. Aliran yang digambarkan sebagai panah dengan dua ujung menggambarkan terjadinya dialog. Aliran dapat juga menyebar atau menyatu (sejumlah atribut dapat membentuk satu aliran, atau satu aliran menyebar menjadi sejumlah atribut, atribut dalam hal ini dapat merupakan bagian atau duplikasi dari aliran).
Notasi Yourdan/DeMarco Notasi Gane & Sarson • Penyimpanan, komponen ini digunakan untuk memodelkan kumpulan data (paket
data). Notasi yang digunakan adalah garis sejajar, segi empat dengan sudut melenkung, atau persegi panjang. Notasi ini dapat mendefinisikan file atau basis data. Panah yang bergerak dari penyimpanan berarti; pengunaan data paket tunggal, penggunaan data paket kelompok, penggunaan perbagai paket dan penggunaan perbagian bagi lebih dari satu paket. Jika aliran tidak didefinsikan, maka keseluruhan paket informasi dari penyimpanan digunakan, demikian juga dengan aliran yang mempunyai nama sama dengan penyimpanan, sedangkan definisi aliran yang berbeda dengan penyimpanan menunjukkan hanya satu atau dua komponen dari keseluruhan penyimpanan yang digunakan. Hal yang penting untuk diingat bahwa penyimpanan tidak berubah ketika paket informasi bergerak dari penyimpanan melalui aliran.
Notasi Yourdan/DeMarco Notasi Gane & Sarson
24
Panah yang bergerak ke penyimpanan mendeskripsikan pemulisan, perubahan atau penghapusan, satu atau lebih paket dimasukkan ke baru), atau lebih paket dihapus, dipindahkan dari penyimpanan, satu atau lebih paket dimodifikasi atau berubah (dapat berarti menggubah seluruh paket atau hanya sebagain dari paket). • Teminator, yang direpresentasikan dengan persegi panjang yang mewakili entiti luar
dimana sistem berkomunikasi. Ada hal penting yang harus diingat tentang termnator.
Controller
Controller
Notasi Yourdan/DeMarco Notasi Gane & Sarson
a. Terminatro merupakan bagian luar sistem, dan aliran data (panah) yang dihubungkan dengan terminator (ke/dari proses, ke/dari penyimpanan) dalam sistem memodelkan hubungan antar sisten dengan dunia luar.
b. Hubungan atar terminator tidak digambarkan dalam model ini, hal ini disebabkan
karena hubungan antar terminator bukan merupakan bagian sistem yang akan dimodelkan. Jika pada sejmumlah kasus, hubungan antar teminator sangat penting dan esensial bagi sistem yang akan dimodelkan, maka terminator tersebut meruapakan bagian dari sistem dan seharusnya dimodelkan sebagai proses.
Ketika DFD mulai dibuat kita harus hati-hati agar DFD tadi tidak kelewat sederhana, salah dan tidak konsisten. Karena itu ada sejumlah petunjuk yang perlu dilakukan untuk membuat DFD yang jelas, dan enak dibaca yaitu: a. Pilih nama yang jelas maksudnya (bagi proses, aliran penyimpanan dan terminator).
1.sebagiknya menggunaan nama yang lebih mangacu pada fungsi, yaitu gabungan antara kata kerja yang spesifik dan obyek (misalnya memproses laporan inventori, validasi nomor telepon, dll). 2.jangan menggunakan nama yang terlalu umum (misalnya proses data, tangani masukan, dll). 3.gunakan nama yang familiar bagi pemakai.
b. Menomori proses, 1.tiak jadi masalah bagimana urutan ditempatkan. 2.nomor tidak
menunjukkan urutan. 3.penomoran dimaksudkan sebagai identifikasi proses dan memudahkan penuruan (level yang lebih rendah) ke proses berikutnya.
c. Menggambarkan kembali DFD sehingga cukup estetis. Dalam menggambarkan
lingkaran (proses) harus benar-benar bulat dan setiap proses memiliki ukuran yang sama. Jangan ada yang besar atau ada yang kecil, karena dapat mengandung penafsiran lingkaran yang besar mengontrol lingkaran yang kecil.
d. Mencegah DFD yeng teterlalu kompleks. Kegunaan DFD bukan hanya menggambarkan
fungsi dan interaksinya dalam sistem secara akurat tetapi juga untuk dibaca dan dimengerti oleh bukan hanya penganalaisa sistem, tetapi pemakai yang berpengalaman dalam sistem yang dimodelkan, hal ini berati: jangan membuat DFD dengan terlalu banyak proses, aliran, penyimapanan dan terminator.
25
e. Meyakinkan DFD tersebut konsisten secara intren dan konsisten dengan DFD lain yang berhubungan. Hal-hal penting yang harus diingat aladah: 1.mencegah proses yang mempunyai masukkan tetapi tidak mempunyai keluaran (dikenal sebagi black hols). 2.mencegah proses yang mempunyai keluaran tetapi tidak mempunyai masukkan. 3.hati-hati dengan aliran dan proses yang tidak dinamakan (dapat mengakibatkan elemen data yang saling tidak berhubungan menjadi satu). 4.hati-hati dengan penyimpanan yang punya satatus hanya dapat dibaca atau hanya dapat ditulis yang berkaitan erat dengan hanya memproses masukkan dan hanya memproses keluaran.
Level yang paling tinggi dalam DFD hanya punya sebuah lingkaran (proses) yang memodelkan seluruh sistem, sedangkan aliran memodelkan hubungan antar sistem dengan terminator diluar sistem (external terminator), level ini disebut contex-diagram (diagram konteks). Dalam hal ini berperan penomoran DFD yang sudah dibahas sebelumnya (yang berguna untuk memudahkan penuruan DFD ke level yang lebih rendah). Penurunan ini mengacu pada aturan tertentu yaitu: 1. Setiap penurunan ke-level yang lebih rendah harus mampu merepresentasikan proses
tersebut dalam spesifikasi proses yang jelas (seandainya belum cukup jelas maka seharusnya diturunkan ke-level yang lebih rendah).
2. Setiap penurunan harus dilakaukan hanya jika perlu. 3. Tidak semua bagian dari sistem harus diturunkan dengan jumlah level yang sama (yang
kompleks bisa saja diturunkan, dan hanya sesederhana mungkin tidak perlu diturunkan, karena tidak semua proses dalam level yang sama punya drajat kompleksitas yang sama juga).
4. Konfirmasikan DFD yang telah dibuat pada pemakai dengan cara top-down. 5. Aliran data yang masuk dan keluar pada suatu proses di level x harus berhubungan
dengan aliran data yang masuk dan keluar pada level x+1 yang mendefinisikan proses pada levek x tersebut.
6. Penyimpanan yang muncul pada level x harus didefinsikan kembali pada level x+1,
sedangkan penyimpanan yang muncul pada level x tidak harus muncul pada level x-1 (karena penyimpanan tersebut bersfiat lokal).
7. Ketika mulai menurunkan DFD dari level tertinggi cobalah untuk mengidentifikasi
external events diamana sistem harus memberikan respon. DFD sebagai perangkat pemodelan bisa dikatakan sederhana, tetapi sangat berguna untuk memodelkan fungsi dalam sistem, jika yang akan dimodelkan punya ketergantungan dengan waktu (misalnya real time sistem) harus dimodelkan dengan model lain. Ruginya banyak penganalisa sistem mengira dengan DFD, maka meraka sudah tahu banyak segala sesuatu tentang analisa terstruktur, sedangkan kenyataan membuktikan tanpa perangkat pemodelan tambahan DFD menjadi sesuatu yang serba penuh kekurangan.
26
CONTOH ANALISA KASUS DFD Sebuah Rumah Sakit Surya Husada yang sedang berkembang ingin meningkatkan service terhadap para pasiennya dengan cara membangun sistem pelayanan pasien yang dibantu oleh komputer. Sistem yang akan dibuat hanya dibatasi untuk poliklinik. Ketika pasien mendaftar maka akan dilakukan pengecekan terhadap data yang telah disimpan untuk mencari apakah pasien tersebut pernah terdaftar, ataukah belum. Bila belum terdaftar maka data lengkap pasien akan dimasukkan. Sebagai salah satu bahan masukkan bagi dokter dalam melakukan diagnosa adalah catatan kesehatan pasien. Setelah selesai pemeriksaan, dokter memberikan data tantang diagnosa terhadap pasien tersebut, serta menuliskan resep. Dokter juga harus melaporakan tentang injeksi apa yang telah diberikan dan resep yang dibuat dokter, maka dikeluarkan biaya tentang obat yang harus dibayar. Selanjutnya petugas rumah sakit akan menyrahkan obat tersebut beserta rincian biaya tersebut (biaya obat dan biaya pemeriksaan). Data tentang diagnosa dan obat yang diberikan dicatat oleh petugas rumah sakit berharap agar sistem yang akan dibuat dapat memberikan laporan keuangan dan laporan pemakian obat. Dari abstraksi diatas akan dibuat DFD yang memetakan sistem pelayanan rumah sakit. Langkah-langkah yang ditempuh adalah sebagai berikut: 1. identifikasi data-data yang berkaitan dengan sistem. 2. identifikai sumber data. 3. buat diagram konteks. 4. turunkan diagram konteks menjadi DFD level 0. 5. bila dirasa perlu turunkan DFD level 0 menjadi DFD level berikutnya. Data yang berkaitan dengan sistem pelayanan rumah sakit adalah: • Data pasien, yang diperoleh dari pasien yang bersangkutan. • Data diagnosa, yang dibuat oleh dokter setelah malakukan pemeriksaan (termasuk
injeksi yang diberikan dokter). • Resep, yang juga didapat dari dokter. • Biaya pengobatan, yang dihitung berdasarkan resep dan data diagnosa. • Laporan keuangan, yang dibuat berdasarkan biaya yang dibayarkan oleh pasien serta
harga obat yang telah digunakan, serta laporan pemakian obat-obatan, yang dibuat berdsarkan data pemakian obat oleh pasien.
Selanjutnya kita buat diagram konteks-nya. Untuk membuat diagram konteks, kita daftarkan terlebih dahulu terminator-terminator (entiti luar) yang berkaitan dengan sistem, yaitu:
• Dokter • Pasien • Direktur Rumah Sakit
27
Gambar 2.3 Dagram konteks sistempalayan rumah sakit
Tahap selanjutnya adalah menurunkan Diagram Konteks menjadi DFD level ke-0. Cara yang cukup membantu dalam penurunan diagram konteks menjadi DFD level ke-0 adalah dengan menentukan kejadian (event) apa saja yang mungkin muncul dalam sistem. Kita catat kejadian-kejadian tersebut dalam suatu daftar (list). Daftar ini sering disebut sebagai even list. Kejadian-kejadian tersebut adalah:
• Pencarian data pasien, untuk mengetahui apakah pasien tersebut sudah pernah tecatat sebelumnya.
• Pencetatan data pasien, untuk mencatat data pasien yang belum pernah terdaftar. • Pencatatan data injeksi. • Pencatatan data resep. • Pengambilan data riwayat kesehatan pasien, untuk digunakan oleh dokter dalam
mendiagnosa psien. • Pembuatan dafatar biaya, yaitu biaya yang harus dibayar oleh pasien. • Pembuatan laporan keuangan. • Pembuatan laoran pemakaian obat.
Bila daftar terlalu panjang (menurut Yordon, lebih dari tujuh termasuk panjang), maka kejadian-kejadian tersebut harus dikelompokkan terlebih dahulu. Dafatar kejadian diatas dapat dikelompokkan sebagai berikut:
1. Pendaftaran pasien - pencarian data pasien - pencatatan data pasien - pengambilan data riwayat kesehatan pasien
2. Diagnosa - pencatatan data hasil diagnosa - pencatatan data injeksi - pencatatan data resep
3. Pembuatan dafatar biaya 4. Pembuatan laporan
- pembuatan laporan keuangan - pembuatan laporan pemakaian obat
Kelompok kejadian diatas adalah bubble pada DFD level 0
28
Gambar 2.4 DFD Level 0 sistem pelayanan rumah sakit
Dengan pengelompokan yang telah kita lakukan, penurunan DFD level 0 menjadi DFD level 1 akan lebih mudah dilakukan.
Gambar 2.5 DFD level 1 pendaftaran pasien
29
Gambar 2.6 DFD level 1 diagnosa
Gambar 2.7 DFD level 1 pembuatan laporan
LATIHAN ANALISA KASUS DFD Sebuah hotel berbintang akan mengembangkan sebuah sistem yang dapat membantu pelayanan tamu. Sistem tersebut diharapkan dapat langsung mengeluarkan daftar biaya yang harus dibayar oleh tamu, ketika tamu hendak meningalkan hotel. Biaya yang harus ikut dihitung adalah biaya kamar, biaya makanan di restoran, biaya pelayanan tambahan (pencucian baju, dll). Di hotel itu terdapat juga sebuah toko souvenir. Tamu hotel boleh saja mengambil souvenir tertentu dimana pembayarannya dilakukan ketika dia hendak meninggalkan hotel. Di hotel tersebut terdapat juga bagian perjalanan yang melayani tamu yang ingin melakukan perjalanan baik dengan pesawat terbang maupun dengan kereta api.
30
KERTAS KERJA (2)
31
32
33
Dari abstraksi diatas buatlah DFD yang memetakan sistem pelayanan Hotel. Langkah-langkah yang harus ditempuh adalah sebagai berikut:
• Identifikasi data yang berikaitan dengan sistem. • Identifikasi sumber data. • Buat diagarm konteks. • Turunkan diagram konteks menjadi DFD level 0. • Bila dirasa perlu turunkan DFD level 0 menjadi DFD level berikutnya.
2.3.2. DATA DICTIONARY (DD) Kamus data (data dictonary) tidak menggunakan notasi grafis sebagaimana halnya DFD. DD berfungsi membatu pelaku sistem untuk mengerti aplikasi secara detail. DD mereorganisasi semua elemen data yang digunakan dalam sistem dengan presisi yang sedemikian rupa sehingga pemakai dan penganalisa sistem punya dasar pengertian yang sama tentang masukan, keluaran, penyimpanan dan proses. DD mendefinisikan elemen data dengan fungsi sebagai berikut:
• Mejelaskan arti aliran data dan penyimpanan dalam DFD. • Mendeskripsikan komposisi paket data yang bergerak melalui aliran (misalnya
alamat diuraikan menjadi kota, negara dan kode pos). • Mendeskripsikan komposisi penyimpanan data. • Menspesifikasikan nilai dan satuan yang relevan bagi penyimpanan dan aliran. • Mendeskripsikan hubungan detail antar penyimpanan (yang akan menjadi titik
perhatian dalam entity-relationship diagram). Notasi struktur data digunakan untuk membuat spesifikasi elemen data. Notasi yang digunakan dalam DD adalah:
No Notasi Keterangan
1 = Terdiri dari
2 + And (dan)
3 () Pilihan (boleh ada atu tidak)
4 {} Iterasi / pengulangan
5 [] Pilih salah satu pilihan
6 | Pemisah pilihan didalam tanda []
7 * Keterangan / catatan
8 @ Penunjuk (key field)
34
Notasi tipe data yang digunakan untuk mebuat spesifikasi format input maupun output suatu data. Notasi tipe data yang digunakan dalam DD adalah:
No Notasi Keterangan
1 X Setiap karakter
2 9 Angka numerik
3 A Karakter alfabet
4 Z Angka nol ditampilkan sebagai spasi kosong
5 . Titik, sebagai pemisah ribuan
6 , Koma, sebagai pemisah pecahan
7 - Tanda penghubung (contoh:021-4373818)
8 / Tanda pembagi (contoh 30/04/83)
Contoh: Kita mendefinisikan nama dengan menggunakan aturan diatas. Nama dalam hal ini punya sejumlah atribut pendukung seperti gelar, nama_depan, nama_tengah, dan nama_akhir. Nama = Gelar + Nama_depan + Nama_tengah + Nama_akhir Gelar = [Tuan | Nyonya | Nona | Doktor | Professor] Nama_depan = karakter_valid Nama_tengah = karakter_valid Nama_akhir = karakter_valid Karakter_valid= [A-Z | a-z | 0-9| ‘ | - | | ] Tentu saja ada elemen data yang tidak perlu didefinisikan karena elemen data tersebut sudah cukup naratif. Contoh: Tinggi_sekarang = ** *satuan : sentimeter; rentang 1-200* Berat_sekarang = ** *satuan : kilogram; entang 1-300* Tanggal_lahir = ** *satuan : hari sejak 1 januari 1900; rentang 36500* Jenis_kelamin = ** *nilai : [P | W]* DD dibuat oleh penganalisa sistem selama pengembangan model sistem, tetapi sebaliknya pemakai harus punya kemampuan membaca dan mengerti DD untuk mengecek model (agar sinkron dengan kebutuhan pemakai). Umumnya pemakai dikondisikan untuk mengerti notasi DD, memverifikasi DD (kelengkapan dan kebenarannya), dan terlibat secara tak
35
lansung dalam pembuatan DD. Walaupun sepintas lalu noasi DD seperti simbol matematis, tetapi simbol yang digunakan relaif sedikti jumlahnya. Umumnya pemakai kewalahan jika harus membaca seluruh DD, item demi item untuk mengecek benar tidaknya DD tersebut. Sulit membayangkan pemakai mau dan mampu melakukan ini, terutama karena keterkaitan DD dengan perangkat pemdoelan lain. Karena tentu ada sejumlah cara untuk mengecek kebenaran DD tersebut (tanpa harus dibantu pemakai), cara ini digunakan untuk mengecek kelengkapan, konsistensi, dan koordinasi melalui testing dengan sejumlah pertanyaan dibawah ini.
• Apakah semua aliran DFD sudah didiefinisikan dalam DD?. • Apakah semua komponen elemen data sudah didefinsikan ?. • Apakah semua data yang didefinsikan lebih dari satu kali ?. • Apakah semua notasi yang digunakan pada DD sudah dikoreksi ?. • Apakah elemen data dalam DD tidak menjelaskan sesuatu dalam Data Flow
Diagaram, Entity Relationship, atau State Trasition Diagram ?. Pada sistem berukuran menengah sampai besar, DD menjadi pekerjaan yang punya porsi pelaksanaan besar. Umumnya sangat jarang DD yang digunakan untuk mendifinsikan ribuan masukkan sistem, sedangkan yang sering kita jumpai adalah sistem yang relatif berukuran menengah dengan ratusan masukkan. Dengan sistem berukurtan menengah tetap harus dilakukan sesuatu agar pendefinisian ini tidak terlalu membebani pekerjaan analisa sistem. Membangun DD adalah salah satu dari sejumlah aspek analisa yang paling banyak menghabiskan waktu. Tetapi DD juga merupakan salah satu aspek terpenting tanpa DD yang mendefinsikan semua terminologi maka presisi sistem akan menjadi harapan kosong. CONTOH ANALISA KASUS DD Seorang perancang dan penganalisa sistem mendapat proyek untuk memetakan sistem sebuah perusahaan perdagangan. Pak Cerdas demikian rekan-rekan seprofesi memanggilnya, telah membuat DFD lengkap yang terdiri atas Diagram Konteks dan beberapa level DFD, serta DD-nya. Kesulitan utama yang dihapdai Pak Cerdas untuk menyelesaikan rancangannya adalah maslaah waktu, sehingga ada satu bagian dari DFD yang dia buat yaitu pada bagian Peneriamaan dan Pengeluaran Kas dan Bank (PPKB), belum sempat diselesaikan DD-nya. Oleh karena itu, Pak Cerdas meminta kita untuk berperan sebagai analisa junior membantu menuntaskan pekerjaan perancangan tersebut dengan membuatkan DD untuk DFD PPKB tersebut. PPKB adalah sub sistem yang mencatat tiap penerimaan ataupun pemakian uang baik melalui kas atupun melelui Bank. Data penerimaan kas dicatat oleh proses (bubble) Kas Masuk, demikian juga untuk Kas Keluar, Bank Masuk dan Bank Keluar. Seluruh data yang
36
masuk akan disimpan dalam data store Kas dan Bank. Selanjutnya dari data yang telah tesimpan, diharapkan diperoleh laporan-laporan yang akan diberikan untuk direksi.
1
Kas Masuk
2
Kas Keluar
Kas dan BANK
Data
kas
masuk
Data
kas
keluar
5
Pelaporan
4
BANK Keluar
3
BANK Masuk
Pihak Luar
BANK
Bagian
BANK
Direksi
Form kas
masuk
Form bank
masuk
Data
bank
masuk
Data
bank
keluar
Lap. kas
bank
Form bank
keluar
Form kas
keluar
Data kas & bank
Gambar 2.8 DFD penerimaan dan pengeluaran Kas dan Bank
Dengan pengalamannya yang cukup luas ditambah intuisinya yang tajam, Pak Cerdas berhasil mendefinsikan formulir-formulir untuk empat proses diatas, yaitu Formulir Kas Masuk, Formulir Kas Keluar, Formulir Bank Masuk, serta Formulir Bank Keluar. Nomor Formulir : Tanggal : Nomor Cek / Giro : Penyetor : Alamat :
No. Uraian Penerimaan Kas Jumlah
Jumlah : ................................... Gambar 2.9 Formulir kas masuk
37
Nomor Formulir : Tanggal : Nomor Cek / Giro : Penerima : Alamat :
No. Uraian Pengeluaran Kas Jumlah
Jumlah : ............................... Gambar 2.10 Formulir kas keluar
Nomor Formulir : Tanggal : Nomor Cek / Giro : Penyetor : Alamat :
No. Uraian Penerimaan Bank Jumlah
Jumlah : ................................... Gambar 2.11 Formulir Bank masuk
Nomor Formulir : Tanggal : Nomor Cek / Giro : Penerima : Alamat :
No. Uraian Pengeluaran Bank Jumlah
Jumlah : ................................... Gambar 2.12 Formulir Bank keluar
38
Langkah-langkah yang dilakukan untuk membuat DD dari DFD penerimaan dan pengeluaran Kas dan Bank adalah sebagai berikut:
• Mengidentifikasi data apa saja yang akan dideskripsikan dalam DD. • Mendefinsikan data tersebut sebagai DD. • Mendeskripskan item-item DD sampai bentuk yang cukup detail.
Data yang akan kita deskripsikan adalah: (perhatikan DFD diatas)
a. Form kas masuk b. Form kas keluar c. Form bank masuk d. Form bank keluar e. Kas dan Bank (data store) f. Laporan Kas dan Bank
Untuk point (a.) s/d (d.) diatas, kita dapat menggunakan formulir-formulir yang telah dideskripsikan untuk mempermudah pembuatan DD. Form Kas Masuk = *Data Formulir Penerimaan Kas* Nomor Formulir + Tanggal + NomorCek + Penyetor + Alamat +
Tabel Penerima Kas Nomor Formulir = 1 {karakter}10 Tanggal = *Tanggal* Nomor Cek = 1 {Karakter} 10 Penyetor = 1 {Karakter} 10 Alamat = 1 {Karakter} 30 Tabel Penerimaan Kas= Nomor Urut + {Uraian penerimaan Kas } + Jumlah Uraian Penerimaan Kas = Kode Penerimaan Kas + Penerimaan kas Kode Penerimaan kas = 1 {Karakter } 3 Penerimaan kas = 1 {Karakter } 30 Nomor Urut = Angka Karakter = {A-Z|a-z|0-9|-| |} Angka = *Numerik* Untuk (b.) s/d (d.) dapat dicoba sebagai latihan. Selanjutnya akan kita coba menurunkan DD dari data store Kas dan Bank. Dari DFD diatas kita bisa melihat bahwa ada yang dikrim ke data store Kas dan Bank bisa berupa data Form Kas Masuk, Form Kas Keluar, Form Bank Masuk, atau Form Bank Keluar. Kas dan Bank = [Form Kas Masuk | Form Kas Keluar | Form Bank Masuk |
Form Bank Keluar] Untuk item (.f) dapat dicoba sebagai latihan. Sebagai petunjuk, gunakan intuisi dan logika anda untuk mencoba menyusun beberapa alternatif laporan dari data yang tersedia. Bila anda kesulitan untuk langsung membuat DD-nya buatlah formulirnya terlebih dahulu.
39
LATIHAN ANALISA KASUS DFD Buatlah DD untuk sistem rumah sakit berdasarkan DFD yang kita rancang pada latihan kasus materi DFD.
KERTAS KERJA (3)
40
41
2.3.3. PROCESS SPECIFICATION (PS) PS digunakan untuk mendeskripsikan proses yang terjadi pada level paling dasar dalam DFD (dalam DeMarco 1978, Gane dan Sarson 1977 disebut sebagai miatur spesifikasi). Model ini berfungsi mendeskripsikan apa yang dilakukan ketika masukkan ditransformasikan mejadi keluaran. Model ini yang memperjelas pola kerja dalam satipa lingkaran (dibaca proses). Untuk menjelaskan PS ada banyak cara yang dapat digunakan (misalnya decision tables, flowcharts, pre-post conditions, dll), tidak jadi masalah model mana yang akan digunakan, yang jelas setiap model yang akan digunakan harus memenuhi syarat:
1. Dapat diverifikasi oleh pemakai dan penganalisa sistem. 2. Mampu berkomunikasi secara efektif dengan pemakai yang bervariasi.
Umumnya penganalisa sistem menggunakan English Structure sebagai cara untuk memodelkan PS. Dengan kata lain yang harus dipetakan adalah untuk apa proses itu dilakukan buka bagaimana proses itu dikerjakan. Kalimat dalam PS umumnya tersusun dari sejumlah komposisi seperti rumus matematis, kata kerja, dan obyek (variabel atau elemen data). Triminologi dalam komputasi dideksripsikan dengan kata kerja seperti:
Cari (find, search, atau locate). Jumlahkan (add) Kalikan (multiply) Kurangi (substract) Bagi (divide) Ambil (get, read, accept) Tulis (display, write) Hitung (compute) Hapus (delete) Cek (validate) Pindahkan (move) Gantikan (replace) Set (set) Urutkan (sort) Buka (open) Gandakan (copy), dll Operator logika seperti: Dan (.and.) Atau (.or.) Operator matematis seperti: + (plus), -(minus), : (bagi), x(kali) dll.
Konstruksi yang digunakan dalam PS adalah: IF..THEN..ELSE Digunakan untuk mendeskripsikan pilihan secara biner (pada satu saat hanya ada dua pilihan). Kondidi ini punya dua bentuk yaitu;
42
IF Kondisi-1 Kalimat-1
EndIF Atau IF Kondisi-1 Kalimat-1 ELSE Kalimat-2 EndIF Dalam contoh kasus akan berentuk seperti ini:
IF pelanggan tinggal di Bandung Buka prospek_pemasaran * membuka penyimpanan pemasaran* Tulis pelanggan ke prospek_pemasaran EndIF Atau IF Umur_Pelanggan > 65 Set tarif_pemesanan ke penggan_senior ELSE Set tarif_pemesanan ke tarif_normal EndIF DO CASE,.....CASE, .....ENDCASE Digunakan untuk mendeskrisikan pilihan pada satu saat secara jamak (multivalued decision). Secara umum berbentuk.
Do Case Case variabel = nilai_(1)
Kalimat_(1) Case variabel = nilai_(2)
Kalimat_(2) . . Case vaiabel_nilai_(n)
Kalimat_(n) Otherwise
Kalimat_(n+1) EndCase
Dalam contoh kasus akan berbentuk seprti ini: Do Case
Case umur_pelanggan < 12 Set tarif_pemesanan ke tarif_anak Case umur_pelanggan > 12 dan umur_pelanggan < 20
43
Set tarif_pemesanan ke tarif_remaja Case umur_pelanggan > 20 dan umur _pelanggan < 65 Set tarif_pemesanan ke tarif_dewasa Otherwise Set tarif_pemesanan ke tarif _senior
EndCase DO WHILE CINDITION ...ENDDO Digunakan untuk mendefinisikan pengulangan instruksi selama memenuhi kondisi tertentu (dari kalimat pertama sudah harus memenuhi kondisi). Secara umum bentuknya: Do While kondisi_1 Kalimat_1 EndDo Pengecekan kondisi dilakukan kalimat_1 dijalankan, dan jika kondisi tidak dipenuhi maka kalimat_1 tidak dijalankan (keluar dari pengulangan). Do While (masih ada item_pemesanan) Nilai_transaksi = harga_item x jumlah_item EndDo REPEAT ... UNTIL Digunakan untuk mendefinisikan pengulangan instruksi selama memenuhi kondisi tertentu (kalimat pertama tidak harus memenuhi kondisi). Secara umum berbentuk: Repeat Kalimat_1 Until Kondisi_1 Kalimat dalam PS merupakan kombinasi dari semua struktur diatas dan struktur kalimat sederhana yang harus memenuhi aturan berikut: A. Kalimat linier yang berurutan adalah ekivalien dengan kalimat sederhana seperti:
Kalimat_1 Kalimat_2 .. .. Kalimat_n Dan secara struktur, ekivalen dengan kalimat tunggal sederhanan, dan dapat ditempatkan dibagian yang berlainan jika diperlukan, sehingga dapat berbentuk seperti: If kondisi_1 Kalmat_1 Kalimat_2
44
Else Kalimat_3 Kalimat_4 Kalimat_5 EndIf Atau Do While kondisi_1 Kalimat_1 Kalimat_2 Kalimat_3 EndDo
B. Konstruksi sederhana If-Then-Else adalah kalimat tunggal sederhana, dan penggabungan konstruksi ini dengan konstruksi sejenis, ataupun dengan Do While, dan Case diperbolahkan. If Kondisi_1 Kalimat_1 If Kondisi_2 Kalimat_2 Kalimat_3 Else Kalimat_4 Kalimat_5 EndIf Else Kalimat_7 If Kondisi_3 Kalimat_8 Kalimat_9 EndIf EndIf
C. Struktur sederhanan Do While adalah ekivalen dengan kalimat tunggal sederhana, dan
penggabungan konstruksi ini dengan konstruksi sejenis ataupun If-Then-Else dan Case diperbolehkan. Total = 0 Do While (ada pemesanan yang diproses) Total_transksi = 0 Baca pemesanan berikutnya dari pemesanan Do While (ada item pada pemesanan) Total_transaksi = total_transkasi + transksi_item EndDo
45
Tulis nomor_pemesanan, total_transksi Total = total + total_transksi EndDo Tulis Total
D. Struktur sederhana Case adalah ekivalen dengan kalimat tunggal sederhana, dan dapat digunakan dengan kombinasi sejenis, If-Then-Else ataupun Do While Seperti kita lihat bahwa dengan PS kita dapat membuat deskripsi yang kompleks dan lengkap tentang proses, kontrol, kebajikan. Tetapi penggunaan PS dengan cara seperti itu akan merugikan karena terlalu kompleks untuk pemakai (untuk mengerti dan menyetujui). Karena itu harus diingat sejumlah hal seperti: • Sebaiknya membatasi PS hanya dituliskan pada satu halaman bagi setiap proses
yang terjadi. • Membatasi penggunaan lebih dari tiga level kombinasi struktur terutama bagi
struktur If-Then_Else • Dan memberikan penjelasan deskritif sesingkat mungkin.
CONTOH ANALISA KASUS PS Suatu hari, Ibu Nikmat ingin mengadakan sebuah pesta dirumahnya. Pesata itu dihadiri oleh rekan-rekan suaminya, Pak Lezat. Bu Nikmat ingin pestanya semenarik mungkin, sehingga dia menyewa sebuah Band yang menyajikan musik Jazz, musik kesukaan suaminya, serta berniat menghidangkan masakan-masakan istimewa yang dia buat sendiri. Masakan-maskan istimewa itu adalah: Kue apel, kue yang dulu membuat pak Lezat jatuh hati pada ibu Nikmat, Ikan mas bakar, Ayam bakar, Sayur asem, serta buah-buahan yang disajikan secara menarik. Untuk melengkapi hidangan pesta, ibu Lezat membeli kue-kue ditoko roti langganan ibu Lezat. Ibu Lezat berbelanja bahan-bahan makanan di beberapa tempat, yaitu pasar, untuk bahan makanan segar, supermarket, untuk bahan makanan yang diawetkan, termasuk tepung, gula pasir dan telur ayam, serta toko roti langganan untuk kue-kue pelangkap pesta. Sebagai catatan tambahan, ibu lezat benar-benar ingin agar pesta yang dia selenggarakan benar-benar sempurna. Dia ingin agar bahan makanan yang digunakan untuk hidangan benar-benar bermutu tinggi tetapi tidak memiliki waktu untuk pergi sendiri berbelanja. Oleh karena itu, semua bearang belanjaan yang dibeli dia seleksi kembali.
46
1
Seleksi &
penyimpanan
bahan
makanan
Pase
Toko Roti
Supermarket
Buah-buahanTepung, gula,
dllSayur-sayuran
Kue-kue
Ikan & ayam
7
Menyajikan
buah-buahan
6
Pembuatan
kue apel
5
Pembuatan
sayur asem
4
Pembuatan
ikan mas bakar
3
Pembuatan
ayam bakar
2
Menyajikan
kue-kue
Tamu
undanganBuah-buahanKue apel
Sayur-sayuran
Ikan
bakar
Ayam
bakar
Kue-kue
Bahan bakuApel
Bahan baku Bahan sayurikan
Ikan
Ayam
Kue-kue
Ayam
Bahan baku kue
Buah-buahan Sayuran
Bahan baku
Bahan makana
dari pasar
Kue-kue
Bahan makanan
dari supermarket
Gambar 2.13 DFD jamuan pesta
DFD diatas akan dibuatkan PS-nya. Seperti dijelaskan dalam teori, PS mendeskripsikan proses yang tidak dibuka lagi (sebagai level berikutnya). Dari DFD diatas terlihat bahwa ada 7 proses yang harus kita buat PS-nya yaitu:
1. Seleksi dan penyimpanan bahan makanan. 2. Menyajikan kue-kue. 3. Pembuatan ayam bakar. 4. Pembuatan ikan bakar. 5. Pembuatan sayur asem. 6. Pembuatan kue apel. 7. Menyajikan buah-buah.
47
1. Seleksi dan Penyimpanan Bahan Makanan Pertama, kita pisahkan bubble yang akan kita diskripsikan.
Kemudian deskripsikan hal apa saja yang akan dilakukan dalam bubble tersebut sebagai PS. DO WHILE ada bahan makanan IF bahan makanan memenuhi syarat DO CASE CASE bahan makanan adalah kue Simpan di tempat penyimapanan kue-kue CASE bahan makanan adalah ikan atau ayam Simpan di tempat penyimpanan ikan dan ayam CASE bahan makanan adalah sayur-sayuran Simpan di tempat penyimpanan sayur-sayuran CASE bahan makanan adalah tepung atau gula atau bahan kue lain Simpan di tempat penyimpanan tpung, gula dll CASE bahan makanan adalah buah-buahan Simpan di tempat penyimpanan buah-buahan ENDCASE ELSE “dibuang” *kita tidak perhatikan lagi data yang “tidak digunakan”* ENDIF ENDDO
48
2. Menyajikan Kue-kue
DO WHILE ada data kue-kue Letakkan di piring kue ENDDO
3. Pembuatan Ayam Bakar Pemisahan bubble dari DFD bukan merupakan suatu keharusan, tetapi hanya untuk mempermudah.
Ikan & ayam
3
Pembuatan
ayam bakar
Ayam
Siapkan alat masak Siapkan ayam DO WHILE masih ada ayam Ayam dibersihkan Ayam dibakar ENDDO
Untuk bubble yang lain (4, 5, 6, 7) silahkan dicoba sebagai latihan LATIHAN ANALISA KASUS PS Buatlah PS dari latihan DFD tentang sistem rumah sakit. Selamat mengerjakan.
KERTAS KERJA (4)
49
50
51
2.3.4. STATE TRANSITION DIAGRAM (STD) Diakhir tahun 1980 sistem yang memodelkan tingkah laku ketergantungan pada watu (time-dependent behaviour) menjadi hal penting. Hal ini umumnya diterapkan pada katagori khusus yang kita sebut dengan real-timem system. Umumnya sistem seperti ini pasif dengan kata lain tidak digunakan untuk mengontrol segala sesuatu dengan aktif, tetapi lebih ditik beratkan pada reaksinya terhadap lingkungan dalam bentuk kemampuan untuk menangkap data (data cepture). Sistem real time yang lain kadang lebih aktif, misalnya pada sistem yang berfungsi untuk melakukan pengawasan pemeliharaan pada sejumlah aspek lingkungan sistem, misalnya pada sistem kontrol proses. Untuk lebih jelasnya kita dapat membanyangkan suatu sistem yang bekerja dengan data (dari sumber diluar sistem), yang harus menyediakan respon dan keluaran berkecepatan tinggi dan dapat digunakan kembali oleh lingkungan diluar sistem pada waktu yang relatif sama. Tentu saja bagi sistem seperti ini bagian terpenting adalah deskripsi tentang apa dan kapan terjadinya sesuatu. bagi sistem yang berorientasi ke bisnis, aspek real-time tidak terlalu penting. Masukkan dapat muncul dalam sistem dari berbagai sumber dengan kecepatan relatif tinggi, tetapi tidak selalu langsung diproses karena jika sistem sedang sibuk melakukan sesuatu yang lain akan terjadi tenggang waktu. Sebagai contoh seistem penggajian tidak harus khawatir dengan interupsi dan sinyal dari unit dari waktu dalam sistem seperti ini adalah spesifikasi dan karakteristik repson sistem tersebut terhadap waktu. Bagaimanapun juga akan sering dihadapkan untuk kondisi dimana kita harus mencoba melalui untuk mengamati sistem besar dan komplek yang mempunyai aspek ketergantungan pada waktu. Jika berinteraksi dengan masukkan dari ribuan terminal, sebagaimana masukkan berkecepatan tinggi dari komputer lain atau fasilitas kombinasi satelit, maka mungkin terdapat jenis ketergantungan terhadap waktu yang sama sebagaimana yang diterapkan dalam real-time system klasik. Jika penganalias sistem punya maslah dengan waktu maka harus dilakukan pendekatan melalui model ini dan sebaiknya diterapkan dengan familier. STD dibawah ini berfungsi untuk menunjukkan model tingkah laku dari mesin penjawab telepon. Komponen utama diagram adalah keadaan (state) dan panah (row) yang mempresentasikan perubahan keadaan. Ada banyak notasi alternatif dalam STD misalnya penggunaan elips sebagai penggani keadaan.
52
Gambar 2.14 Contoh penerapan STD dalam mesin penjawab telepon Setiap persegi panjang merepresentasikan keadaan (state lebih tepat jika diasumsikan sebagai kumpulan yang menggambarkan sesuatu pada satu saat, atau kondisi) sistem pada saat tertentu. Yang dimaksud dengan keadaan seperti contoh berikut:
• Menunggu pemakai memasukkan password. • Menunggu perintah berikutnya. • Kondisi tungu (idle).
Keadaan dalam hal ini dapat berarti menunggu sesuatu (dari lingkuran luar) atau menunggu aktivitas yang sedang berlangsung berubah menjadi aktivitas lain. Hal ini tidak selalu berarti sistem tidak melakukan aksi justru kondisi tersebut adalah aksi sistem. Pada gambar dibawah ini diperlihatkan bagimanan sistem berubah dari keadaan 1 ke keadaan 2; sistem berubah dari keadaa 2 ke keadaan 1 atau ke keadaan 3 (alternatif); sistem berubah kembali dari keadaan 3 ke keadaan 1, sedangkan dari keadaan 1 tidak bisa lansung ke kadaan 3.
Gambar 2.15 Perubahan keadaan
53
Pada sejumlah sistem keadaan akhir tidak ada, sehingga sistem akan terus bekerja dan tetap terus bekerja sampai ada aksi yang tidak didefinisikan dalam sistem untuk menghentikan proses. Tetapi pada umumnya sistem salalu punya keadaan akhir dan keadaan awal (dan mudah dikenali).
Gambar 2.16 Sistem tanpa keadaan akhir
Kondisi awal umumnya selalu digambarkan pada bagian atas diagram yang diidentifikasi dari panah awal yang menuju keadaan awal. Kondiai akhir digambarkan dengan panah yang menuju keadaan akhir pada bagian bawah diagram (tidak selalu keadaan paling bawah menjadi kondisi akhir suatu sistem) secara masing-masing eksklusiv.
Gambar 2.17 Kondisi akhir ganda
Jika kita menggunakan STD untuk membuat model esensi, kita harus mengasumsikan keadaan dapat berubah dengan spontan, dengan kata lain sistem tidak memerlukan waktu untu observasi bagi perubahan keadaan yang satu keadaan yang lain.
54
Untuk melengkapkan STD, kita membutuhkan dua hal lagi yaitu pertama, sebagai kondisi penyebab perubahan keadaan dan kedua, aksi yang harus dilakukan ketika akan berubah keadaan.
State 1
State 2
Konidi
Aksi
Gambar 2.18 Kondisi dan Aksi
Kodisi adalah suatu kejadian dalam lingkungan luar yang akan dideteksi sistem, misalnya berupa sinyal, atau interupsi, atau munculnya sejumlah paket data hal ini menyebabkan sistem berubah dari keadaan menunggu x yang berubah menjadi keadaan baru menjadi menungu y, atau melanjutkan pemrosesan x menjadi pemrosesan y. Sebagai bagian dan perubahan keadaan, sistem akan melakukan satu atau lebih yang menghasilkan keluaran seperti tampilan layar, pesan pada terminal pemakai, penghitungan, dan seterusnya. Aksi ini merupakan respon balik sistem bagi lingkungan diluar sistem atau merupakan bahan masukan bagi keadaan berikutnya. Pada sistem yang kompleks terdapat lusinan keadaan, mecoba mengelompokkan dalam satu diagram tunggal akan sulit dan kadang-kadang tak mungkin. Karena itu kita menggunakan penurunan level (seperti yang kita lakukan pada DFD). Gambar berikut menunjukkan penurunan level dalam STD.
Gambar 2.19 Penurunan level dalam STD
Sebagai catatan, dalam kasus ini kondisi akhir keadaan yang levelnya lebih tinggi menjadi konisi awal bagi level yang lebih rendah. Sedangkan kondisi akhir bagi level yang lebih rendah menjadi kondisi awal bagi level yang lebih tinggi, berikut ini contoh kasus penggunaan STD dalam sistm ATM.
55
Tunggu
Tunggu Kartu
Tunggu
Password
Tunggu
Jawaban
Tunggu
Uang
Tunggu
Neraca
Deposit
UangTransfer Dana
Reset
Reset or
Password salah
Bersihkan layar
Reset
Bersihkan layar
Tekan
“Masukkan kartu”
Kartu dimasukkan
“Masukkan password”
Password dimasukkan
“Pilih fungsi”
Ambil Uang
Gambar 2.20 STD Automatic Teller Machine (ATM) level 1
Gambar 2.21 Penurunan “Ambil uang”
Ketika kita mencoba membuat STD maka kita dapat melaluinya dengan dua pendekatan yaitu:
56
1. Memulai mengidentifikasi keadaan yang mungkin, memisah-misahkannya dalam diagram. Kemudian mencoba mengeksplore panah (dan perubahan) antar persegi panjang (baca: keadaan).
2. Memulainya dengan kondisi awal (initial state), dan dengan sistematis melacak jalan menuju keadaan berikutnya, kemudian keadaan berikutnya lagi dan seterusnya.
Model tersebut akan dikonfofirmasikan pada pemakai (yang merupakan satu satunya pelaku sistem yang familiar dengan sstem tersebut. Setelah model selesai kita harus mengecek konsistensinya dengan: • Apakah semua keadaan sudah didefinisikan ? (lakukan pendekatan kembali untuk
mencegah kemungkinan keadaan yang belum dimodelkan). • Evaluasi semua keadaan (apakah semua masukan dan keluaran sudah deskritif ?). • Yakinkan sistem dapat keluar dari segala keadaan (darurat), dan cek semua kondsi akhir
yang mungkin. • Dalam setaip keadaan cek apakah sistem melakukan respon untuk semua kondisi yng
mungkin. Sebagai model, STD dapat berdiri sendiri, meskipun begitu hubungan dengan model lain dapat dilakukan (biasanya memang dilakukan). Umunya STD merepresntasikan PS untuk mengontrol setiap lingkaran dalam DFD. Kondisi dalam STD berkorespondensi dengan aliran data kearah lingkaran (panah masuk) dan aksi dalam STD berkoresponden dengan aliran data keluar lingkaran (panah keluar) dalam DFD. Sebagai pemodelan tingkat tinggi, STD dapat mendukung PS bagi keseluruhan sistem. Jika DFD yang dibuat hanya menggunakan satu lingkaran bagi keseluruhan sistem, maka kita dapat menggunakan STD untuk menunjukkan sekuen (urutan) aktivitas dalam sistem. STD merupakan model yang bagus untuk mendeskripsikan kebutuhan pemodelan real-time system, sebagaimana pemodelan porsi manusia dalam on-line system, karena itu model ini tidak banyak digunakan dalam pengembangan sistem berorientasi ke bisnis. Tetapi familier dengan STD adalah hal yang penting, karena dimasa depan kita akan berhadapan dengan labih banyak sistem berorientasi pada real-time (baik orientasi bisnis maupun oreintasi teknologi). LATIHAN ANALISA KASUS STD Buatlah STD dari sistem pengisian pulsa kartu isi ulang pada HP anda, misalnya kartu yang digunakan adalah kartu XL.
57
KERTAS KERJA (5)
58
2.3.5. BLOCK CHART DIAGRAM (BC) Block chart berfungsi memodelkan masukkan, keluaran, refrensi, master, proses ataupun transaski dalam simbol-simbol tertentu. Pada dasarnya tidak berorientasi pada fungsi, waktu ataupun aliran data tetapi lebih ke arah proses (saling melengkapi dengan PS). Simbol-simbol yang digunakan dalam Block Chart, relatif umum digunakan dalam banyak sistem dan terdiri dari:
Simbol Keterangan
FORM, digambarkan dengan kombinasi persegi panjang dan garis lengkung umumnya mendefinisikan dokumen masukkan (baca: formulir) dan dokumen keluaran (baca : laporan).
PAPAN KUCI, digambarkan dengan segitiga dan segiempat umumnya mendefinisikan fungsi pemasukkan data (key-in). Dapat berarti masukkan untuk direkam ataupun tidak untuk direkam (kedalam storage)
PROSES, digambarkan dengan persegi panjang, umumnya mendefinisikan mekanisme perekaman, proses dan pelaporan.
FILE, digambarkan dengan kombinasi garis lengkung dan lurus umumnya mendefinisikan file referensi, file master atau file temporer yang digunakan dalam proses.
MONITOR, digambarkan dengan kombinasi garis lengkung umumnya mendefinisikan keluaran dalam bentuk layar (screen).
Gambar 2.22. Simbol-simbol block chart
Contoh Block Chart penghitungan nilai mahasiswa
Gambar 2.23 Block Chart menghitung nilai mahasiswa
Mata kuliah
Mahasiswa Konstanta
Nilai Praktek
Nilai Teori
Key In
Penghitungan Transkirp
Konstanta
Transkip
59
CONTOH ANALISA KASUS BC Pada dasarnya ada 3 hal yang harus diperhatikan dalam membuat BC, yaitu:
• Masukkan (Input). • Proses. • Keluaran (Output).
Langkah-langkah yang harus dilakukan dalam pembuatan BC adalah:
• Identifikasi proses yang akan dideskripsikan sebagai BC. • Tentukan masukkannya (form, file, keyborad, dll). • Tentukan keluarannya (form, file, printer, screen, dll). • Tentukan aliran datanya.
Sebagai contoh, kita kembali melihat DFD tentang pelayanan pasien rumah sakit. pada DFD tersebut, proses-proses yang terjadi (pada level terendah) adalah:
1. Pencarian data pasien. 2. Pencatatan data pasien. 3. Pengambilan data riwayat kesehatan pasien. 4. Pencatatan data hasil diagnosa. 5. Pencatatan data injeksi. 6. Pencatatan data resep. 7. Pencatatan daftar biaya. 8. pembuatan laporan keuangan. 9. pembuatan laporan pemakain obat.
Untuk setiap proses diatas, kita buat block chart-nya. 1. Pencarian data pasien
Masukan : Kyboard, file pasien Keluaran : Layar monitor
60
2. Pencatatan data pasien Masukan : Keyboard, formulir data pasien Keluaran : Data pasien
3. Pengambilan data riwayat kesehatan pasien
Masukan : Keyboard, file data pasien, file catatan kesehatan pasien. Keluaran : Layar monitor, catata kesehatan pasien (print out).
Pengambilan
cat.kesehatan
pasienCatatan
kesehatan
pasien
Data pasien
Pasien
Catatan
kesehatan pasien
4. Pencatatan data hasil diagnosa Masukan : Keyboard, form hasil diagnosa. Keluaran : File catatan kesehatan pasien.
Form hasil
dignosa
Pencatatan hasil
diagnosa
Catatan
kesehatan
pasien
61
5. Pencatatan data injeksi Masukan : Keyboard, form hasil diagnosa. Keluaran : File injeksi.
6. Pencatatan data resep
Masukan : Keyboard, resep. Keluaran : File resep.
Form hasil
diagnosa
Pencatatan hasil
diagnosaresep
7. Pencatatan daftar biaya
Masukan : File resep, file injeksi, file pasien. Keluaran : monitor, biaya pasien (print out).
62
8. Pembuatan laporan keuangan Masukan : File injeksi, file resep. Keluaran : Layar monitor, laporan keuangan (print out).
9. Pembuatan laporan pemakain obat
Masukan : File injeksi, file resep. Keluaran : Layar monitor, laporn pemakian obat (print out).
LATIHAN ANALISA KASUS BC Buatlah BC dari sistem perpustakaan yang ada pada universitas anda.
63
KERTAS KERJA (6)
64
65
2.3.6. SYSTEM PROCEDUR DIAGRAM (SPD) Digunakan untuk mendefinsikan hubungan antar bagian (pelaku proses) proses (manual atau berbasis komputer) dan aliaran data (dalam bentuk dokumen keluaran, dan masukkan). Menggunakan simbol-simbol sebagai berikut:
Simbol Keterangan
Dokumen, mendefinisikan dokumen masukan (formulir) dan dokmen keluaran (laporan).
Pemasukkan data, mendefinisikan data (umumnya melalui keyboard, tetapi juga masukan lain seperti digitizer, mouse dll).
Proses manual, mendefinisikan proses manual seperti pencampuran, pencetakkan dll.
Dokumentasi, mendefinisikan penyimpanan arsip seandainya suatu saat diperlukan sebagai back-up. Pembuatan laporan gabungan, bahan audit dll.
Prosedur yang tidak didefinisikan, mendefinisikan prosedur lain yang tidak termasuk sebagai bagian dari sistem prosedur yang dibuat.
Master, mendefinisikan penyimpanan (storage) bagi semua data transaksi ataupun data-data lain.
Proses berbasis komputer, mendefinisikan proses yang dilakukan dengan komputer seperti penjurnalan, perhitungan dll.
Kondisi, mendefinisikan alternatif setelah kondisi tertentu.
File, mendefnisikan penyimpanan (umumnya bukan master) yang berupa file referensi, trasaksi ataupun temporer.
Display, mendefinisikan keluaran dalam bentuk layar (screen).
66
Konektor 1; mendefinisikan hubungan dengan halaman berikutnya yang dalam hal ini dapat berarti dari halaman x atau ke halaman x.
Konektor 2; mendefinisikan hubungan dengan bagian lain dalam satu halaman.
Gambar 2.24 Simbol-simbol sistem prosedur Contoh SP sistem akademik
Pengajar Asisten Bagian Akademik Mahasiswa
Gambar 2.25 Sistem prosedur akademik
Nilai Teori Nilai Praktek Pengumpulan
Nilai
Transkrip Nilai
Key in
Penghitungan Transkrip
Nilai
Transkrip Nilai
Mahasiswa
67
CONTOH ANALISA KASUS SP Untuk memudahkan pembuatan prosedur, cara paling tepat adalah dengan mengkonsentrasikan pada dokumen, asal dokumen, tujuan, serta alur dokumen. Langkah-langkah yang patut untuk diterapkan adalah sebagai berikut:
• Tentukan dokumen apa saja yang terlibat. • Siapa yang membuatnya. • Diberikan kepada siapa. • Selanjutnya tentukan proses apa saja yang dialami dokumen tersebut. • Siapa yang melakukan. • Setelah diproses (mungkin menjadi dokumen baru), dokumen tersebut diberikan
kepada siapa, dll. Sebagai contoh akan kita coba membuat prosedur mengenai masalah yang telah kita bahas pada latihan-latihan sebelumnya yaitu mengenai pelayanan pasien rumah sakit. Dalam sistem tersebut terdapat beberapa dokumen, yaitu:
• Data induk pasien. • Formulir hasil diagnosa. • Daftar biaya pasien. • Laporan keuangan. • Laporan pemakaian obat. • Resep. • Catatan kesehatan pasien.
Dari dokumen-dokumen tersebut, kita coba membuat narasi mengenai aliran dokumen-dokumen tersebut.
• Pertama kali, pasien yang belum terdaftar akan mengisi form data pribadi pasien. Data pribadi ini akan disimpan dalam suatu tempat penyimpanan.
• Untuk pasien yang sudah terdaftar, maka data tentang riwayat kesehatan pasien akan dicetak untuk digunakan oleh dokter sebagai masukkan pada saat melakukan diagnosa.
• Setelah dokter melakukan diagnosa, maka dokter akan mengisi form hasil diagnosa yang oleh bagian administrasi RS akan dimasukkan ke tempat penyimpanan sebagai catatan kesehatan pasien. Dokter juga menulis resep untuk pasien yang bersangkutan.
• Resep hasil diagnosa selanjutnya akan digunakan sebagai bahan untuk membuat daftar biaya pasien.
• Selain itu juga berdasarkan hasil diagnosa dan resep, administrasi RS membuat laporan keuangan dan laporan pemakian obat, yang diberikan kepada direktur RS.
Selanjutnya dari narasi yang telah kita buat, kita harus menggambarkannya sebagai sebuah sistem prosedur, sbb:
68
Data pasien Pencetatan data
pasien
Biaya pasien
Pencatatan
riwayat
kesehatan
pasien
Riwayat
kesehatan
pasien
Penghitungan
biaya pasien
Pembuatan
laporan
Biaya pasienLaporan
keuangan
Laporan
pemakian
obat
Laporan
keuangan
Laporan
pemakian
obat
Diagnosa
Pasien Administrasi Rumah Saikit Dokter Direktur Rumah Sakit
Laporan
keuangan
Laporan
pemakian obat
Gambar 2.26 Prosedur palayanan rumah sakit
LATIHAN ANALISA KASUS SP Buatlah sistem prosedur yang ada pada perpustakaan di universitas anda.
69
KERTAS KERJA (7)
70
2.4. METODOLOGI BERORIENTASI DATA Metodologi ini disebut juga metodologi model informasi, diperkenaklan sekitar tahun 1980an dengan banyaknya perusahaan menggunakan “Relational Database Management System”. Alat yang digunakan untuk membuat model ialah Entity Relationship Diagram (ERD). Fokus utamam metodologi ini adalah data, diaman dunia nyata digambarkan dalam bentuk entitas, atribut data serta hubungan atar data tersebut.
Gambar 2.27 Fokus utama metodologi berorientasi data
2.4.1. ENTITY-RELATIONSHIP DIAGRAM (ERD) ERD adalah model yang mendeskripsikan hubungan antar penyimpanan (dalam DFD) karena itu ERD berbeda dengan DFD yang memodelkan fungsi sistem atau STD (state trasition diagram) yang memodelkan sistem dari segi ketergantungan terhadap waktu. ERD digunakan untuk memodelkan struktur data dan hubungan atar data, karena hal ini relatif komplek. Dengan ERD kita dapat menguji model dengan mengabaikan proses yang harus dilakukan. Dan dengan ERD kita mencoba menjawab pertanyaan seperti, data apa yang kita perlukan ?, bagaimana data yang satu berhubungan dengan data yang lain?. ERD pertama kali dideskripsikan oleh Peter Chen (The Entity Relationship Model – Toward a Unified of Data, March 1976). Dalam buku ini Chen mencoba merumuskan dasar dasar model. Setelah itu dikembangkan dan dimodifikasi oleh Chen dan banyak pakar lain. ERD menggunakan sejumlah notasi dan simbol untuk menggambarkan struktur dan hubungan atar data. Pada dasarnya ada tiga macam simbol yaitu:
1. Entiti. 2. Atribut. 3. Hubungan.
a. Entiti Entiti adalah suatu obyek yang dapat diidentifikasi dalam lingkungan pemakai, sesuatu yang penting bagi pemakai dalam konteks sistem yang akan dibuat. Sebagai contoh: Pelanggan, Pekerja, dll. Seandainya X adalah seorang pekerja maka x adalah isi dari
71
pekerja, sedangkan jika y adalah seorang pelanggan maka y adalah isi dari pelanggan. Karena itu harus dibedakan antara entiti (sebagai bentuk umum dari deskripsi tertentu) dan isi entiti (seperti x dan y dalam contoh diatas).
Gambar 2.28 Entiti
b. Atribut
Entiti mempunyai elemen yang disebut atribut, dan berfungsi mendeskripsikan karakter entiti. Sebagai contoh atribut nama pekerja dari entiti pekerja. Dalam hal ini untuk setiap ERD bisa terdapat lebih dari satu atribut misalnya entiti item mempunyai atribut deskripsi_item, warna_item, dan ukuran_item. Isi atribut mempunyai sesuatu yang dapat mengididentifikasi isi entiti satu dengan yang lainnya. Misalnya pekerja x punya NIP yang berbeda dengan pekerja y (NIP dalam hal ini berfungsi sebagai komponen pembeda karena dalam satu organisasi kita seringkali menemukan nama_pekerja yang sama bagi lebih dari satu pekerja). Atribut disimbolkan dengan lambang elips.
Gambar 2.29 Entiti dan atribut c. Hubungan
Entiti dapat berhubungan satu sama lain. Hubungan ini dinamakan relationships. Sebagaimana halnya entiti maka dalam hubunganpun harus dibedakan antara hubungan (bentuk hubungan antar entiti) dan isi hubungan. Misalnya dalam kasus hubungan antar entiti mahasiswa dan mata_kuliah adalah mengambil, sedangkan isi hubungannya dapat berupa nilai_ujian. 1 N
Gambar 2.30 Entiti, atribut dan hubungan
Pekerja
Pekerja Warna_item
Ukuran item
Deskripsi_item
Mahasiswa
Mata Kuliah
Nama
Nim_Mhs
Mengambil
Kode_MataK
Nim_Mhs
Nilai_Ujian
Kode_MataK
Nama_M_K
72
Dalam ERD hubungan ini dapat terdiri dari sejumlah entiti yang disebut sebagai derajat hubungan. Tetapi pada umumnya hampir semu model hanya menggunakan hubungan derajat dua (binary-relationship). (a) hubungan drajat dua (biner) (b) hubungan drajat tiga
Gambar 2.31 Derajat hubungan Pada suatu hubungan (tidak masalah berapapun derajatnya) antar entiti selalu ada tiga jenis hubungan biner, yaitu: Satu ke Satu (1 to 1)
Hubungan Satu ke Satu yaitu (seperti dalam contoh dibawah ini ) jika dalam suatu perusahaan ada peraturan yang mengharuskan satu supir hanya boleh menangani satu kendaraan (karena alasan tertentu). Maka dalam pemodelan dituliskan bentuk hubungan (cardinality) 1 ke 1, atau satu orang mahasiswa satu kartu mahasiswa. 1 1
Gambar 2.32 Hubungan 1 ke 1
Satu ke Banyak (1 to m) Hubungan Satu ke Banyak yaitu jika suatu badan pendidikan selalu digunakan asumsi bahwa satu kelas terdiri dari banyak siswa tetapi tidak sebaliknya, yaitu satu siswa tidak dapat belajar pada kelas yang berbeda, maka dalam pemodelan dituliskan bentuk hubungan 1 ke M. Atau satu orang mahasiswa mengambil banyak matakuliah.
Penjual
Ibu
Item
Penjualan
Bapak
Anak
Ortu
Supir
Mobil Penugasan
73
1 M
Gambar 2.33 Hubungan 1 ke m Banyak ke Banyak (m to n)
Hubungan banyak ke Banyak yaitu jika dalam dunia musik ada banyak personil yang bermain dalam banyak grup (mislnya x bermain di grup metal, jazz dan pop dilain pihak grup metal mempunyai personil y,z dan x). Maka dalam pemodelan dituliskan bentuk m ke n. M N
Gambar 2.34 Hubungan m ke n
Dalam hal ini m dan n berarti kardinaliti maksimum, sedangkan 1 berati kardinaliti minimum. Ketiga hubungan diatas disebut juga relasi mempunyai (has-a-relationships) karena setiap entiti mempunyai hubungan dengan entiti lain. Pada sejumlah hubungan ada kasus dimana entiti yang sama saling berhubungan misalnya hubungan sekamar_dengan (jika pada suatu tempat kos satu kamar dapat terdiri dari beberapa orang) seperti pada gambar berikut. 1 M
Gambar 2.35 Hubungan rekursive Dalam ERD ada entiti yang disebut sebagai entiti lemah, yaitu entiti yang kehadirannya dalam suatu basis data tergantung pada kehadiran entiti lain misalnya jika dalam suatu perusahaan hanya ada transaksi jika ada pelanggan seandainya tidak ada pelanggan maka tidak terjadi transaksi. Dalam hal ini terdapat entiti pelanggan, entiti transkasi adalah entiti lemah.
1 N
Gambar 2.36 Entiti lemah
Kelas
Siswa Berisi
Grup
Personil
Beranggotakan
Penghuni
Sekamar dengan
Pelanggan
Transaksi
Melakukan
74
Biasanya entiti yang tergantung pada entiti lain tidak punya faktor pembeda (identifier), sehingga faktor pembedanya menggunakan atribut dari entiti yang lebih kuat. Dalam contoh diatas jika transkasi mempunyai atribut tanggal_transkasi, jam_trnasksi maka faktor pembedanya adalah nomor_pelanggan (yang juga merupakan atribut pelanggan). Pada sejumlah kasus ada entiti yang tidak homogen, tetapi terdiri dari sejumlah bagian. Misalnya pada contoh diatas, pelanggan terdiri dari atribut Nomor_Pelanggan, Nama_Pelanggan dan Nilai_Rekening, sedangkan palanggan terbagi menjadi perorangan, partner dan perusahaan. Karena itu ada informasi tambahan untuk setiap jenis pelanggan yaitu: Pelanggan perorangan berisi: Alamat Nomor_registrasi_penduduk Pelanggan Partner berisi: Nama_Partner Alamat Nomor_wajib_Pajak Pelanggan_Perusahaan berisi: Nama_kontak_personil Nomor_telepon Nomor_wajib_pajak Dalam kasus ini kesemua jenis pelanggan diatas tergantung dalam satu entiti yang kita namakan pelanggan. Sebagai konsekuensinya tidak semua atribut digunakan (hanya atribut yang digunakan pada ketiga pelanggan tersebut yang dapat digunakan). Dalam contoh diatas nama_partner hanya dapat digunakan pada jenis pelanggan_partner, bagi pelanggan dengan tipe lain hal tersebut tidak berarti. Dalam ERD kasus ini perorangan, partner dan perushaan disebut sebagai entiti subtipe (subtype entities) sedangkan pelanggan disebut sebagai entiti supertipe (supertype entities).
Gambar 2.37 Entiti subtipe dan entiti supertipe
Dalam hal ini entiti pelanggan berhubungan 1 ke 1 untuk setiap entiti subtipe berarti setiap entiti subtipe dalam satu saat adalah ekslusiv ketika hanya salah satu yang diperlukan. Bentuk lain dari kasus ini ialah jika sejumlah pemakai komputer dalam satu perusahaan dikelompokkan dalam ketagori jenis komputer yang digunakan seperti.
75
Gambar 2.38 Entiti subtipe dan entiti supertipe non-ekslusiv
Untuk kasus ini hubungan antar entiti subtipe dan entiti supertipe tidak ekslusiv dan disebut dengan generalisasi hirarki (generalization hierarchy), karena untuk setiap entiti pemakai terdapat tiga entiti subtipe pemakai pada saat yang sama (non-ekslusive). Bentuk ini dinamakan hubungan adalah (is-a-relationship). Cara untuk mengecek hubungan ini adalah dengan mencoba untuk menentukan faktor pembeda keempat entiti ini, dalam hal ini faktor pembeda yang sama yaitu: nomor_pemakai (sebagai salah satu alternatif hubungan selain hubungan mempunyai atau has-a-relationship) Pada dasarnya ERD merupakan desain database dengan konsep Top-Down. Pembuatan model ini memerlukan komunikasi antar pemakai dan penganalisa sistem untuk mengidentifikasi entiti dan hubungan antar entiti dalam lingkup perancangan. Pada saat yang sama atribut dan hubungan tersebut juga didokumentasikan. Pembuatan model ini menggunakan gabungan antar DFD dan DD sebagai sumber (dalam hal ini PS tidak terlalu berperan) Sejumlah Kesimpulan Penting Tentang ERD
• ERD penting karena dua alasan, Pertama dapat digunakan untuk memetakan DBMS (Data Base Management Systems) yang punya tingkat ketidak tergantungan tinggi (independent desgin). Kedua ERD menjadi dasar pengelompokan berdasarkan kepentingan dari produk DBMS.
• Normalisasi (penyempurnaan struktur) dapat digunakan sebagai cara untuk
mengecek kebenaran dan kebutuhan relasi.
• Relasi pada dasarnya adalah tabel 2 dimensi yang punya nilai tunggal isi pada kolom yang sama mempunyai jenis yang sama, sedangkan kolom mempunyai nama yang unik. kolom disebut juga sebagai atribut.
• Tidak ada baris pada tabel dua dimensi tersebut yang identik. Baris disebut juga
tuple atau record.
• Tabel file dan relasi adalah kata yang sama sebagaimana kolom, field dan atribut, atau baris, tuple dan record ketiga-tiganya dilihat dari sudut pandang model relasional, pemrograman dan pemakai sistem.
76
• Sejumlah relasi ketika modifikasi dilakukan mengalami konsekuensi yang tidak diinginkan dan disebut modifikasi anomali (modification anomalies).
• Penghapusan anomali terjadi jika penghapsan baris mengakibatkan hilangnya
sejumlah informasi tentang dua atau lebih entiti.
• Penyisipan anomali terjadi jika struktur relasional mengharuskan penambahan fakta bagi dua entiti pada saat yang sama.
• Anomali dapat dihilangkan dengan membagi relasi menjadi dua atau lebih relasi. • Ada banyak cara memodifikasi anomali, dimana relasi diklasifikasikan berdasarkan
tipe anomali. Klasifikasi ini disebut bentuk normal (Normal Form).
• Ketergantungan fungsi adalah hubungan antar atribut. Y tergantung secara fungsi dari X, menunjukkan nilai X menentukan nilai Y.
• Determinan adalah sekelompok atribut (dapat juga satu) yang berfungsi sebagai
faktor penentu atribut lainnya (left side). sebagai contoh jika X menentukan Y, maka X adalah determinan.
• Key adalah kumpulan satu atau lebih atribut yang berfungsi sebagai faktor pembeda
dengan record yang lain.
• Setiap relasi harus memupnyai minimal satu key, karena setiap baris adalah unik, pada kasus ekstrim key merupakan kumpulan dari semua atribut dalam relasi. Meskupun key adalah unik tetapi determinan dalam fungsi ketergantungan tidak harus unik.
• Setiap relasi pada dasarnya adalah 1st Normal Form.
• Realsi menjadi 2nd Normal Form jika semua atribut non-key tergantung pada
semua key.
• Relasi menjadi 3rd Normal Form jika pada 2nd Normal Form tidak terdapat transitive dependencies.
• Relasi menjadi BCNF (Boyce-Codd Normal Form) jika setiap determinan menjadi
calon key (candidate key).
• Relasi menjadi 4th Normal Form jika dalam BCNF tiadak ada ketergantungan bernilai ganda (multivalued dependencies).
• Relasi menjadi 5th Normal Form cendrung tertutup sehingga tidak perlu
didefinisikan.
77
• Relasi menjadi DKNF (Domain / Key Normal Form Relationship) jika setiap konstrain dalam relasi mempunyai konsekuensi logis terhadap pendefinisian daerah asal (domain) dan key. Atau dengan kata lain setiap relasi harus punya hanya satu tema.
• Normalisasi mulai dilakukan dari titik dimana sudah terjad relasi antar atribut jika
dua atribut punya ketergantungan secara fungsional satu sama lain, maka akan terbentuk hubungan satu ke satu, jika satu atribut menentukan yang lian, tetapi tidak sebaliknya maka akan terbentuk hubungan satu kebanyak jika atribut saling menentukan satu sama lain maka akan terbentuk hubungan banyak ke abanyak. Hal ini digunakan ketika mengkonstruksi relasi.
Sebagai catatan, ketika akan membuat pemodelan sebaiknya tidak berorientasi pada seberapa jauh akurasi desain memodelkan dunia nyata tetapi apakah desain tersebut sudah cukup akurat memodelkan kebutuhan pemakai dalam lingkungannya. Sebagai Tambahan Langkah-langkah menyusun ERD
1. Identifikasi objek / entitas. 2. Identifikasi hubungan antar entitas. 3. Persiapkan ERD secara garis besar. 4. Pembuatan atribut data. 5. Penyempurnaan atribut (normalisasi). 6. Penyusunan kembali ERD.
Beberapa bentuk model notasi hubungan (bentuk Cardinality) 1. Information Engineering
78
2. Betuk cardinality yang diusulkan oleh Chen
3. Bentuk cardinality yang diusulkan bachman
79
4. Bentuk cardinality yang diusulkan martin
Jenis-jenis Key ( Kunci ) Jenis-jenis kunci yang dikenal adalah:
1. Candidate Key 2. Primary Key 3. Foreign Key 4. Alternate Key
Candidate Key Sebuah attribute atau lebih yang secara unik mengidentifikasi sebuat record, disebut candidate key. Attribute ini mempunyai nilai yang unik pada hampir setiap recordnya. Fungsi dari candidate key ini adalah sebagai calon primary key. Primary Key Merupakan candidate key yang telah dipilih untuk mengidentifikasi setiap record secara unik. Primary key harus merupakan field yang benar-benar unik dan tidak boleh ada nilai NULL. Misal : KodeDosen, NIM (NoIndukMahasiswa) , NO_KTP. Foreign Key Jika sebuah primary key terhubungan ke table/entity lain, maka keberadaan primary key pada entity tersebut di sebut sebagai foreign key. Misal : Primary Key KodeDosen dari entity Dosen digunakan juga pada field entity KRS, maka keberadaan field KodeDosen pada entity KRS disebut sebagai foreign key.
80
Alternate Key Adalah candidate key yang tidak terpilih. Misal : dalam suatu entity terdapat dua field yang bisa dijadikan sebagai kunci. Sementara yang boleh dijadikan kunci hanya satu, maka anda harus memilih salah satu. Field yang anda pilih, disebut primary key, sedangkan field yang tidak dipilih disebut dengan alternate key. • Misal : Kembali ke kasus entity dosen diatas, jika kita pilih field KodeDosen sebagai Primary Key, maka otomatis field NoKTP menjadi Alternate Key-nya, begitu juga sebaliknya. Analisa Kasus Normalisasi (kasus general ledger) Normalisasi merupakan proses konversi dokumen, laporan manual ke dalam struktur tabel (RDBMS / Relational Data Base Management System) dengan menghilangkan elemen yang sama, dan data yang berulang-ulang. Sebagai contoh dokumen / laporan jurnal yang terdiri dari tanggal, nomor bukti, keterangan, nomor perkiraan, nama perkiraan, jumlah debet dan jumlah kredit dapat dinormalisasikan dalam tiga tahap sebagai berikut: Tabel data yang belum dinormalisasi
Tanggal Nomor Bukti
Keterangan Nomor Perkiraan
Nama Perkiraan
Jumlah Debet
Jumlah Kredit
01/01/97 -
02/02/97 - -
K001 -
B002 - -
Penerimaan -
Pembelian - -
100.000 800.000 120.000 100.000 108.000
Kas Penjualan Persediaan Kas Piutang
350.000
400.000
350.000
250.000 150.000
Gambar 2.39 Form yang belum dinormalisasikan Bentuk normal kesatu Bentuk normal kesatu menjadikan semua kolom berisi data.
Tanggal Nomor Bukti
Keterangan Nomor Perkiraan
Nama Perkiraan
Jumlah Debet
Jumlah Kredit
01/01/97 01/01/97 02/02/97 02/02/97 02/02/97
K001 K001 B002 B002 B002
Penerimaan Penerimaan Pembelian Pembelian Pembelian
100.000 800.000 120.000 100.000 108.000
Kas Penjualan Persediaan Kas Piutang
350.000
400.000
350.000
250.000 150.000
Gambar 2.40 Bentuk normal ke satu
81
Bentuk normal kedua Hilangkan elemen yang sama, dalam hal ini nama perkiraan merupakan elemen yang sama dengan nomor perkiraan, karena dapat terelasi ke tabel perkiraan.
Nomor Perkiraan
Nama Perkiraan
100.000 108.000 120.000 800.000
Kas Piutang Persediaan Penjualan
Tanggal Nomor
Bukti Keterangan Nomor
Perkiraan Nama
Perkiraan Jumlah Debet
Jumlah Kredit
01/01/97 01/01/97 02/02/97 02/02/97 02/02/97
K001 K001 B002 B002 B002
Penerimaan Penerimaan Pembelian Pembelian Pembelian
100.000 800.000 120.000 100.000 108.000
Kas Penjualan Persediaan Kas Piutang
350.000
400.000
350.000
250.000 150.000
Gambar 2.41 Bentuk normal ke dua Bentuk normal ketiga Hilangkan data yang berulang-ulang kecuali foreign key. Dalam hal ini tanggal dan keterangan merupakan data yang disimpan berulang-ulang, shingga dapat dihilangkan dengan membagi tabel tersebut ke dalam dua tabel, yaitu tabel tblJurnal (Header) dan tabel tblJurnalID (Detail), dimana tblJurnal terdiri dari field tanggal, nomor bukti dan keterangan, dan tblJurnalID terdiri dari field nomor bukti, nomor perkiraan, jumlah debet dan jumlah kredit.
82
TblJurnalHeader Tanggal Nomor
Bukti Keterangan
01/01/91 02/02/97
K001 B002
Penerimaan Pembelian
TblMater Perkiraan
TblJurnalDetail Nomor Bukti
Nomor Perkiraan
Jumlah Debet
Jumlah Kredit
K001 K001 B002 B002 B002
100.000 800.000 120.000 100.000 108.000
350.000
400.000
350.000
250.000 150.000
Gambar 2.42 Bentuk normal ke tiga Contoh ERD Contoh berikut ini cara lain dalam menggambarkan diagram ER.
Gambar 2.43 Diagram ER (Entity Relationship) hotel
Nomor Perkiraan
Nama Perkiraan
100.000 108.000 120.000 800.000
Kas Piutang Persediaan Penjualan
83
ER juga dapat dimodelkan seperti gambar berikut ini.
Gambar 2.44 Diagram ER (Entity Relationship) hotel LATIHAN ANALISA KASUS ERD
1. Buatlah ERD sistem rumah sakit yang dibahas pada pemodelan sistem DFD. 2. Buatlah ERD sistem perpustakaan pada umiversitas anda.
84
KERTAS KERJA (8)
85
86
2.5. METODOLOGI BERORIENTASI OBJEK Metodologi ini diperkenalksan sekitar tahun 1990 sebagai pelengkap untuk pemrograman yang terlebih dahulu telah mengadopsi metode berorientasi objek. Beberapa alat dan teknik yang dapat digunakan antara lain dynamic dan static object-oriented model, state transisition diagram dan case scenario. Fokus utama metodologi ini pada objek, dengan melihat suatu sistem terdiri dari objek yang saling berhubungan dengan beberapa cara untuk mencapai suatu tujuan. Objek dapat digambarkan sebagai benda, orang, tempat dan sebaginya yang mempunyai atribut dan method.
Gambar 2.45 Fokus utama metodologi berorientasi objek
2.5.1. Karakteristik Metodologi Objek Dalam pendekatan berorientasi objek ada 4 pilar utama yang harus dipahamai dalam pendekatan berorientasi objek yaitu: 1. Abstraction (abstraksi)
Kemampuan untuk menjadikan dalam bentuk yang lebih sederhana. Hal ini juga dikenal dalam metodologi pendekatan struktur yaitu dekomposisi seperti menyerderhanakan suatu sistem dalam bentuk Context Diagram.
2. Encapsulation (pembungkusan)
Berbeda dengan metodologi terdahulu, meodologi ini menggabungkan atribut dan fungsi/proses kedalam suatu objek yang disebut dengan encapsulation. Setiap objek dapat “menyembunyikan” kompleksitasnya dan berhubungan dengan objek lain dengan mengirim “pesan / message” yang dapat dikenal dan diproses oleh objek penerima.
3. Inheritance (pewarisan)
Suatu mekanisme yang memungkinkan suatu objek memiliki semua atau sebagian definisi dari objek induk.
4. Polymorphism (banyak bentuk) Polymorphism berasal dari kara Poly yang artinya banyak dan morph yang artinya bentuk. Jadi polymorphism adalah kemampuan suatu atribut atau method dapat berubah dalam berbagai bentuk dalam implementasi. Bandingkan air yang dapat berbentuk padat (es), cair atau pun gas.
87
2.5.2. Diagram Objek Dalam metodologi objek terdapat puluhan notasi dan sampai saat ini belum ada satupun diagram yang menjadi dominan, dan setiap penulis / peneliti mengusulkan diagram-diagram baru yang masing-masing mempunyai kelebihan dan kekurangannya. Sebagai gambaran notasi yang umum digunakan dalam pemodelan objek dari Coad/Yourdon, firesmith, Rumbaugh, dan Booch. Walaupun banyak notasi yang diperkenalkn namun satu hal yang pasti dalam metodologi ini adalah menggunakan satu diagram mulai dari analisa sampai desain aplikasi. Class-With-Object Class
Gambar 2.46 Contoh notasi class dengan notasi Coad /Yordon
Class-With-Object Class
Gambar 2.47 Contoh notasi class dengan notasi Rumbaugh 2.5.3. Contoh Metodologi Berorientasi Objek dan Transisi Object Oriented Analysis, metodologi ini dipetik dari buku H.D Cliton & A.G. Sutcliffe, dalam bukunya Business Information Systems, halaman 400. Enam langkah utama metodologi ini adalah:
1. Objects and Classess, langkah pertama ialah menentukan object dan mengelompokkannya ke dalam hierarki kelas (class).
2. Structures, tahap ini menggabungkan objek-objek dan relasinya untuk membuat suatu gambaran umum sistem.
3. Subjects, pada tahap ini objek-objek dikelompokkan menjadi subjek / subsistem-subsistem.
Class Name
Atribut
Method
Class Name
Atribut
Method
Class Name
Atribut
Method
Class Name
Atribut
Method
88
4. Attributes, data / keterangan yang menjelaskan objek ditambhakan untuk setiap objek.
5. Services, method ditambahkan untuk menjelaskan proses / kegiatan yang akan dikerjakan oleh setiap objek bila menerima suatu messages (event).
6. Design, tahap desain melengkapi semua kegiatan yang dilakaukan seperti pembuatan interface dan sebagainya.
2.5.4. Perbandingan Metodologi Objek dan Non Objek Selanjutnya pengelompokan metodologi dibagi dua untuk lebih mempermudah penjelasan yaitu metodologi objek dan non objek (keluaran, proses dan data).
• Metodologi non objek menggunakan beberapa alat untuk menggambarkan model seperti DD, DFD, dan diagram terstruktur. Sedangkan metodologi objek hanya menggunakan satu jenis model yang disempurnakan mulai dari analisa sampai pembuatan sistem.
• Pada metodologi non objek, data dan proses dianggap dua komponen yang
berlainan, sedangkan metodologi objek data dan proses merupakan bagian dari objek.
• Metodologi non objek ditunjukkan untuk melangkapi pemrograman terstruktur,
bahasa generasi ke tiga sedangkan metodologi objek ditujukan untuk pemrograman berorientasi objek dan bahasa generasi ke empat.
89
MENYEIMBANGKAN MODEL
Setelah memperlajari BAB Setelah memperlajari BAB Setelah memperlajari BAB Setelah memperlajari BAB 3333 ini diharapkan mahasiswa mema ini diharapkan mahasiswa mema ini diharapkan mahasiswa mema ini diharapkan mahasiswa memahami dengan hami dengan hami dengan hami dengan
baik baik baik baik penyeimbangan model dalam merancang sistempenyeimbangan model dalam merancang sistempenyeimbangan model dalam merancang sistempenyeimbangan model dalam merancang sistem....
Materi yang dibahas dalam bab 3 ini meliputi
- DFD vs DD
- DFD vs PS
- PS vs DFD
- DD vs DFD vs PS
- ERD vs DFD PS
- DFD vs STD
BAB 3
90
3.1. PENDAHULUAN Dalam bahasan sebelumnya kita telah mempelajari sejumlah perangkat pemodelan penting bagi analisa tersetruktur (dalam hal ini DFD, DD, PS, ER dan STD dimana BC dan SP memegang peranan pendukung). Pada dasarnya setiap model difokuskan pada satu aspek penting sistem yang akan dimodelkan. Hal ini berarti, pemakai yang akan membaca model juga akan memfokuskan perhatian pada salah satu aspek (yang dimodelkan). Karena yang berbeda kompleksitasnya maka kita ingin DFD difokuskan pada fungsi sistem tanpa mengabaikan hubungan antar data, atau ERD difokuskan pada hubungan atar data tanpa mengabaikan karakteristik fungsional, dan kita ingin STD difokuskan pada karaktersitik waktu tanpa mengabiakan fungsi. Dengan kata lain pemodelan pada satu aspek sebaiknya tidak dengan mengabaikan aspek lain. Pada saatnya ada kondisi penganalisa sistem harus menggunakan kesemua model bersama-sama, untuk itulah bahasan ini diperlukan. Situasi ini mirip dengan tentang tiga orang buta (dan bijaksana) di India yang mencoba mendifinisikan sesuatu yang disebut gajah. Orang buta pertama menyentuh ujung yang tajam dari gading dan dia berkata saya tahu bahwa mahluk ini sama dengan banteng...!, saya dapat merasakan kerasnya...! sementara orang buta kedua menyentuh bulu-bulu kasar pada badan gajah dan tanpa banyak berpikir berkata saya tahu ini apa,... ini adalah landak ya.... tentu saja landak yang sangat besar...!, dan orang buta ketiga yang memegang kaki gajah yang besar dan tebal berkata tentu saja ini adalah pohon tempat kita bertiga berteduh...!, Jika seluruh data pengamatan tesebut digabung maka melalui analisa akan diketahui definisi gajah secara lengkap (dalam hal ini, tentu saja kita harapakan ketiga orang buta tersebut melakukan konfirmasi satu sama lain). Seperti ketiga model yang mengatakan tiga aspek berbeda dari sistem (fungsi dan waktu), maka model DD, PS, BC dan SP memetakan karakteristik pendukung detail. Dalam kasus tertentu penggunaan model-model tersebut dapat mengakibatkan interpretasi yang tidak konsisten dari situasi yang sebenarnya. Hal ini terjadi jika sistem yang dikerjakan sangat besar dimana terlibat personil dan kelompok personil yang mempunyai fokus perhatian yang berbeda. Selain itu latar belakang profesi yang berbeda (dari anggota tim) juga akan menyebabkan hal yang sama. Ada alasan lain yang menegaskan kenapa model harus konsisten yaitu bertambah sulit dan mahalnya penyelesaian masalah jika kesalahan tersebut baru ditemukan pada akhir proses. Kesalahan akibat tidak kekonsistenan tersebut akan menyebar dan membesar pada proses desain dan implementasi (martin dalam bukunya mencatat 50% porsi kesalahan yang dideteksi dalam sistem diakibatkan oleh kesalahan pada tahap analisa dan menghabiskan 75% dari biaya perbaikan keseluruhan secara umum). Pada penelitian lain disimpulkan koreksi kesalahan pada proses analisa akan sepuluh kali lebih murah daripada koreksi kesalahan tersebut pada proses desain. Kesalahan tersebut dapat berupa kesalahan menggambarkan model atau menginterpretasikan secara salah keinginan pemakai, kesalahan sulit yang lain adalah hubungan antar model (yang biasanya tersembunyi) yaitu tidak konsistennya hubungan
91
model yang satu dengan yang lain. Karena itu spesifikasi terstruktur pada semua cara pemodelan harus saling koreksi silang (cross-check) agar konsisten dan seimbang. Umumnya kesalahan yang sering terjadi adalah hilangnya definsi, yaitu sesuatu yang didefinisikan pada model yang satu tidak didefinisikan pada model yang lain (misalnya penyimpanan dalam DFD tidak didefinisikan dalam DD). Kesalahan umum berikutnya adalah kontrasdiksi antar prangkat pemodelan dalam memodelkan dunia nyata. Berikut ini kita akan membahas penyeimbangan antar model. 3.1.1. DVD vs DD Aturannya adalah:
1. Setiap aliran data dan setiap penyimpanan dalam DFD harus didefinisikan dalam DD, dan jika dalam DD tidak ada, maka aliran data dan penyimpanan tersebut dapat dipertimbangkan untuk dihapus.
2. Setiap elemen data dan setiap penyimpanan yang didefinisikan dalam DD harus punya tempat dalam DFD dan jika tidak elemen data dan penyimpanan tersebut akan menjadi hantu (sesuatu yang didefinisikan tapi tidak digunakan dalam sistem). Hal ini terjadi karena elemen data tersebut didefinisikan dari referensi versi DFD yang terdahulu (jika ada), bahayanya ketidak DFD berubah (misalnya salah satu penyimpanan di hapus) konfirmasi perubahan tersebut tidak dikorespondensikan dengan DD.
Sebagai catatan, ketika dilakukan pengujian tidak jadi masalah model mana yang hendak diuji terlebih dauhulu (umumnya dimulai dengan DFD). 3.1.2. DFD vs PS Aturannya adalah:
1. Setiap lingkaran pada level paling rendah dalam DFD harus dijelaskan dalam PS. 2. Setiap masukkan dan keluaran untuk proses tertentu harus sesuai DFD
menggambarkan panah masuk dan keluar pada setiap lingkaran atau panah ke penyimpanan dan hasil ini digambarkan dalam PS dengan kalimat seperti baca, ambil, masukkan, terima (untuk panah masuk) atau tulis, tampilkan (untuk panah keluar).
Sebagai catatan, kasus yang umumnya terjadi adalah perubahan dalam DFD tidak dikorespondensikan dengan PS. 3.1.3. PS vs DD Aturannya adalah: Bagi setiap referensi dalam PS berlaku:
1. Nama aliran data dan penyimpanan yang berhubungan dengan lingkaran dalam DFD harus dideskripsikan dalam PS, atau
2. Jika statusnya variabel lokal (lokal term), didefinisikan secara eksplisit dalam PS, atau
3. Muncul sebagai salah satu komponen dalam DD (penyimpanan yang berhubungan denang lingkaran). Dalam contoh dibawah ini elemen data x dan y dalam PS tidak terlihat dalam aliran data pada DFD kesimpulan bahwa x dan y adalah komponen dari z dijelaskan dalam DD. Sedangkan keberadaan z sendiri digambarkan dalam
92
DFD karena itu dapat diambil kesimpulan bahwa pemodelan sistem ini sudah imbang.
Z W
Gambar 3.1 DFD hitung W Mempunyai PS seperti
PS hitung W *P dan Q adalah variabel lokal untuk menghitung hasil atara*
P = 3.14156*x Q = 2.78128 * y -13 W = P * Q + 2 Dan mempunyai DD seperti: X = *komponen horizonatal* *satuan : sentimeter, rentang : 0-100* Y = *komponen vertikal* *satuan : sentimeter; rentang : 1 -10* Z = *faktor pendukung* X + Y
3.1.4. DD vs DFD vs PS Aturannya adalah:
1. Setiap elemen dalam DD harus dijadikan referensi pembuatan PS, atau DFD atau elemen DD yang lain. Pemodelan sistem berjalan akan mempunyai elemen-elemen yang mungkin tidak diperlukan dalam perancangan sistem baru. Disamping itu ada kemungkinan dimana seorang penganalisa menyediakan elemen tambahan yang mungkin tidak diperlukan sekarang tetapi dimasa mendatang.
3.1.5. ERD vs DFD vs PS ER seperti yang sudah dijelaskan sebelumnya mempunyai sudut pandang yang benar-benar berbeda dengan DFD. Bagaimanapun juga sebuah sistem yang baik seharusnya memodelkan seluruh sistem secara komplit, benar dan konsisten. Aturannya adalah:
1. Setialam DFD harus berkorespondensi dengan entiti dan hubungan (relation) atau kombinasi dari entiti dan hubungan. Jika dalam DFD terdapat penyimpnanan yang tidak dideskripsikan dalam ER, maka ada sesuatu yang salah, dan jika ada entiti atau relasi dalam ER yang tidak terlihat dalam DFD juga ada sesuatu yang salah.
Hitung W
93
2. Nama obyek dalam ER dan nama penyimpanan dalam DFD harus cocok (pada dasarnya DFD mendeskripsikan bentuk jamak sedangkan ERD bentuk tunggal).
3. DD harus dapat diaplikasikan pada DFD dan ER. Dengan kata lain definisi pada DD harus menjelaskan terminologi yang digunakan dalam pemodelan pada DFD dan ER.
3.1.6. DFD vs STD Aturannya adalah:
1. Setiap lingkaran dalam DFD punya STD tersendiri. Dengan kata lain setiap STD dalam keseluruhan sistem harus mempunyau hubungan dengan lingkaran dalam DFD.
2. Setiap kondisi dalam STD harus berkorespondensi dengan aliran data masuk ke proses tertentu dalam DFD. Sebaliknya setiap aliran data masuk dalam DFD harus berkorespondensi dengan kondisi dalam STD.
3. Setiap aksi dalam STD harus berkorespondensi dengan aliran data keluaran dari lingkaran dalam DFD. Sebaliknya setiap aliran data keluar delam DFD harus berkorespondensi dengan aksi dalam STD.
Sebagai catatan perlu diketahui tidak semua aturan menyeimbangkan model dituliskan disini dan seandainya kita secara pribadi inging menguji model sistem untuk menemukan kesalahan potensial dan ketidak konsistenan maka hal ini dapat berarti ketika kita mencoba untuk menyeimbangka model maka semua model tersebut dihamparkan pada tempat yang cukup luas, kemudian diuji dan model satu ke model lain dan dengan hati-hati memastikan apakah semua berjalan sesuai rencana.
3.2. ANALISA KASUS Sistem Administrasi Akademik di Universitas Harapan Bangsa (UHB) UHB, sebagai suatu lembaga pendidikan di bawah Yayasan UHB, memiliki kepentingan yang cukup besar berkaitan dengan maslah akademik. Sejalan dengan kebijaksanaan peningkatan mutu UHB, maka sistem administrasi akademik di UHB perlu dikembangkan dalam rangka meningkatkan efisiensi. Cukup sistem administasi akademik menyangkut data mahasiswa, absensi serta nilia dan sebagai muaranya adalah pembuatan transkirp nilai. Agar lebih jelas, penggambaran sistem yang berjalan akan dideskripsikan dalam prosedur berikut ini.
94
Absensi
Nilai Teori
Absensi
Nilai
Praktek
Penentuan
Nilai Akhir
Teori
Nilai Akhir
Teori
Penentuan
Nilai Akhir
Teori
Nilai
Indeks
Penentuan
Nilai Akhir
Praktek
Nilai Akhir
Praktek
Rekapitulasi
Absensi
Rekapitula
si Absensi
Pendaftaran
Skripsi
Form
Skripsi
Penentuan
Transkrip
Transkrip Transkrip
Form
Skripsi
Presentasi
Skripsi
Berita
Acara
Presentasi
Dosen Asisten BAAK Mahasiswa Penguji Skripsi
Gambar 3.2 Sistem prosedur yang berjalan di UHB
Setelah dosen/asisten melakukan tugasnya, maka absensi yang telah diisi oleh mahasiswa UHB diberikan oleh dosen kepada bagian adminitrasi UHB untuk dilakukan rekapitulasi. Rekapitulasi absen ini digunakan oleh dosen untuk menentukan nilai akhir teori dan praktek. Selain nilai akhir dibuat, maka dosen menentukan nilai indek dari matakuliah yang bersangkutan. Nilai indeks yang telah didibuat, diberikan kepada adminitrasi akademik untuk bahan pembutan transkrip. Mahasiswa UHB ketika akan mengambil skripsi harus mengisi formulir skripsi, yang diberikan kepada administrasi akademik. Setelah skripsi selesai dan setelah dilakukan sidang, maka berita acara sidang harus diserahkan kepada administrasi akademik. Berita acara presentasi, daftar skripsi serta nilai indeks akan digunakan oleh bagian akademik UHB untuk membuat transkrip nilai.
95
Hal-hal yang harus diperhtaikan dalam sistem akademik adalah: • Penentuan nilai indeks adalah wewenang pengajar, meskipun dibuat berdasarkan
nilai akhir teori dan nilai akhir praktek. Oleh sebab itu, sistem yang dibuat tidak boleh mematok rumus tertentu untuk menghitung indeks tetapi rumus mampu mempermudah pengajar untuk menentukan nilai indeks.
• Meskipun dari prosedur diatas tidak terlihat adanya pengolahan data pribadi
mahasiswa UHB, bagaimanapun juga data tersebut tidak boleh diabaikan. Dari deskripsi meneganai sistem yang berjalan tersebut diatas, kita akan melakukan perancangan. 1. Data Flow Diagram (DFD) Pertama yang harus dibuat adalah DFD. Langkah-langkah yang harus ditempuh adalah sebagai berikut: • Identifikasi data-data yang berkaitan dengan sistem. • Identifikasi sumber data. • Buat diagram konteks. • Turunkan diagram konteks menjadi DFD level 0. • Bila dirasa perlu turunkan DFD level 0 menjadi DFD level berikutnya. Data-data yang berkaitan dengan sistem diatas adalah: • Nilai (nilai teori, nilai praktek, nilai akhir, nilai indeks), yang harus dibuat oleh
pengajar. • Absensi, diisi oleh mahasiswa dan diberikan oleh pengajar. • Data skripsi, dibuat oleh administrasi akademik. • Berita acara presentasi, dibuat setelah selesai acara presentasi, dan diserahkan oleh
moderator sidang skripsi. • Transkrip, dibuat oleh administrasi akademik. Selanjutnya, kita buat diagram konteks dari sistem tersebut. Terminator dari diagram konteks yang akan kita buat adalah: • Dosen (pengajar). • Aisten (bila menggunakan asisten). • Administrasi akademik (BAAK). • Moderator sidang skripsi. • Mahasiswa UHB.
96
Sistem administrasi
akademik
Dosen
Asisten
Mahasiswa
Penguji Skripsi
Administasi
Akademik / BAAKNilai teori,
Nilai akhir,
Nilai indeks
Absensi
Nilai praktek
Transkrip
Data presenasi
Gambar 3.3 Diagram konteks sistem akademik UHB
Setelah kita selesai memetakan sistem kedalam diagram konteks maka diagram konteks tersebut akan kita buka sebagai DFD level 0. untuk mempermudah pembuatan DFD, akan kita lihat ada kejadian apa saja dalam sistem kita. Kejadian-kejadian itu kita tuliskan sebagai suatu daftar kejadian (event lits). Event list dari sistem administrasi akdemik UHB adalah sebagai berikut: • Pengajar / asisten menyerahkan absensi. • Administrasi membuat rekaptulasi absensi. • Administrasi membuat transkrip untuk mahasiswa UHB. • Presentasi skripsi. • Moderator skripsi menyerahkan berita acara presentasi. • Mahasiswa UHB mendaftarkan untuk skripsi. • Pengajar / Asisten menenrukan nilai terori & praktek. • Pengajar menenukan nilai indeks. Kejadian-kejadian diatas, bila kita perhatikan lebih cermat, sangat berorientasi dengan kejadian manual. Sedangkan yang akan kita buat adalah suatu sistem informasi yang berbasis komputer. Sehinggan kejadian-kejadian diatas harus kita tranformasikan menjadi kejadian yang berorientasi ke sistem informasi berbasis komputer, yaitu: • Pencatatan data absensi. • Pembuatan rekapitulasi absensi. • Pencatatan berita acara. • Pencatatan data skripsi. • Penghitungan nilai akhir. • Penentuan nilai indeks. • Pembuatan transkrip. Dari event list yang telah kita perbaiki diatas, kita dapat membuat DFD level 0.
97
1
Pencatatan
dan absensi
2
Pembuatan
rekap absensi
Absensi
Data absensi
Data rekap absen
Rekap absen
3
Penghitungan
nilai akhir
Nilai akhir
4
Penentuan
nilai indeks
Data
rekapitulasi
absensi
Data Rekap absenData nilai
Data nilai indek
5
Pencatatan
berita acara
presentasi
Berita acara
presentasi
6
Pencatatan
data skripsi
Data skripsi
Data skripsi
7
Pembuatan
transkrip
Nilai indeks
Dat anilai indeks
Data skrispi
Data skripsiData
presentasi
Data
berita
acara
presentasi
Data nilai indek
Gambar 3.4 DFD level 0 sistem administrasi akdemik UHB DFD diatas sudah cukup detail, sehingga tidak perlu diturunkan lagi menjadi DFD level 1. 2. Process Specification (PS) Langkah kita berikutnya adalah membuat Process Spesefication (PS). Proses-proses yang akan dibuat PS-nya adalah bulatan pada DFD paling detail (dalam hal ini adalah DFD level 0, karena dalam kasus ini DFD lebel 0 sudah cukup detail), sebagai berikut. • Pencatatan data absensi. • Pembuatan rekapitulasi absensi. • Pencatatan berita acara presentasi. • Pencatatan data skripsi. • Pencatatan nilai teori dan nilai praktek. • Penghitungan nilai akhir. • Penentuan nilai indeks. • Pembuatan transkrip.
98
a. Pencatatan Data Absensi PS pencatatan data absensi sebagai berikut: Masukkan angkatan mahasiswa UHB Masukkan waktu perkuliahan (tahun akademik, dll).
Masukkan mata kuliah (termasuk keterangan teori / praktek). Do While ada data mahasiswa Masukkan absensi (hadir / tidak). EndDo Simpan data ditempat penyimpanan.
b. Pembuatan Rekap Absensi PS pembuatan rekap absensi sebagai berikut: Do While ada data absensi Cari data matakuliah dan no mahasiswa tertentu ke data store. Rekapitulasi absensi. If Ketemu Jumlah absensi = jumlah absensi +1. Else Buat record baru. Jumlah = jumlah + 1. Endif EndDo
c. Pencatatan Berita Acara Presentasi PS pencatatan berita acara presentasi sebagai berikut: Masukkan tgl masuk (angkatan). Ambil data skripsi dari file skripsi. Masukkan nilai presentasi.
Masukkan data penguji. Simpan di data store bagian akademik presentasi
d. Pencatatan Data Skripsi PS pencatatan data skripsi sebagai berikut: Masukkan NIM mahasiswa. Masukkan Judul Skripsi. Masukkan data pembimbing. Simpan ditempat penyimpanan. e. Pemasukkan Nilai Teori dan Praktek PS pemasukkan nilai teori dan praktek sebagai berikut:
Masukkan angakatan. Masukkan mata kuliah. Do While ada data mahasiswa
Masukkan nilai (teori / praktek) EndDo
99
f. Penghitungan Nilai Akhir PS penghitungan nilai akhir sebagai berikut: Masukkan angkatan. Masukkan matakuliah.
Masukkan rumus perhitungan nilai. Do While ada data nilai Hitung berdasarkan rumus tersebut. EndDo Simpan di data store nilai akhir.
g. Pembuatan Nilai Indeks PS pembuatan nilai indeks sebagai berikut: Masukkan angkatan. Masukkan matakuliah Hitung statistik nilai. Tampilkan hasil statistik. Masukkan standar indeks. Do While ada data nilai Tentukan nilai indeks (berdasarkan standar). EndDo
h. Pembuatan Transkrip Nilai PS pembuatan transkrip nilai sebagai berikut: Masukkan NIM mahasiswa Do While ada data nilai untuk mahasiswa tersebut Tampilkan mata kuliah. Tampilkan nilia. EndDo Cari mahasiswa di data store skripsi If Ketemu Tampilkan judul skripsi Tampilkan nilai ujian skripsi EndIf
3. Data Dictionary (DD) / Kamus Data Untun data yang ada di DFD, kita gunakan Data Dictionary. Data yang akan dibuat DD-nya adalah:
• Absensi • Rekap Nilai • Nilai • Nilai Akhir • Nilai Indeks • Skripsi • Berita Acara Presentasi • Transkrip
Pembuatan DD akan menjadi lebih mudah bila kita buat formulirnya terlebih dahulu.
100
A. Absensi DD untuk absensi adalah sebagai berikut: Angkatan : Matakuliah : Tanggal : Jam :
NIM Nama Kehadiran
Absensi = @Angkatan + @Matakuliah + Tanggal + Jam + {NIM + Nama + Kehadiran} B. Rekap Absen DD untuk rekap absen sebagai berikut: Angkatan : Matakuliah :
NIM Nama Jumlah_Kehadiran
Rekap_Absensi = @Angkatan + @Matakuliah + {NIM + Nama + Jumlah_Kehadiran} C. Nilai DD untuk nilai sebagai berikut: Angkatan : Matakuliah :
Nilai Teori Nilia Praktek NIM Nama 1 2 3 4 1 2 3 4
Rekap_Absensi = @Angkatan + @Matakuliah + {NIM + Nama + NT1 + NT2 +NT3 + NT4 + NP1 + NP2 + NP3 + NP4}
101
D. Nilai Akhir DD untuk nilai akhir sebagai berikut: Angkatan : Matakuliah :
Nilai Akhir NIM Nama Teori Praktek
Nilai_Akhir = @Angkatan + @MataKuliah + {NIM + Nama + Nilai Teori + Nilai Praktek} E. Nilai Indeks DD untuk nilai akhir sebagai berikut: Angkatan : Matakuliah :
NIM Nama Nilai Indeks
Rekap_Indeks = @Angkatan + @Matakuliah + {NIM + Nama + Nilai_Indeks} Bila dirasa penggambaran formulir tidak diperlukan, kita tidak perlu membuat formulirnya terlebih dahulu. Skripsi = Kode_Skripsi + {Peserta_Skripsi } + Judul_Skripsi + Pembimbing} Berita_acara = Kode_Skripsi + {NIM + NilaiSkripsi} + {Penguji} F. Transkrip DD untuk trnaskrip sebagai berikut: NIM : Nama : Kode_Matakuliah Nama Matakuliah Nilai
Skrispis : Judul : Nilai : Transkrip = @NIM+Nama_Mahasiswa + {Nilai_Matakuliah} + Judul_Skripsi + Nilai
102
Tanggal := *Tgl-Bulan-Tahun* Jam := *99:99* Angkatan := Kode_Angkatan + Ket_Angakatan Kode_Angkatan := 1{Karakter}2 Ket_Angakatan := 1{Karakter}30 Mata_Kuliah := Kode_Mata_Kuliah + Ket_Mata_Kuliah Kode_Mata_Kuliah := 1{Karakter}2 Ket_Mata_Kuliah := 1{Karakter}30 NIM := 1{Karakter}8 Nama_Mahasiswa := 1{Karakter}30 Kehadiran := [“Ya” | “Tidak”] Jumlah_Absensi := 1{Angka}3 NT1 := 1{Angka}3 NT2 := 1{Angka}3 NT3 := 1{Angka}3 NT4 := 1{Angka}3 NP1 := 1{Angka}3 NP2 := 1{Angka}3 NP3 := 1{Angka}3 NP4 := 1{Angka}3 NTA := 1{Angka}3 NPA := 1{Angka}3 Indeks := [“A” | “B” |“C” |“D” |“E” ] Kd_Skripsi := 1{karakter}3 Mahasiswa_skripsi := NIM Judul_Skripsi := 1{Karaker}30 Tempat_skripsi := 1{Karakter}30 Pembimbing := Dosen Dosen := Kode_Dosen + Nama_Dosen Kode_Dosen := 1{Karaker}3 Nama_Dosen := 1{Karakter}30 Nilai_Skripsi := Indeks Penguji := Dosen Nilai_Mata_Kuliah := Indeks Angka := [0-9 | . | ,] Karakter := [A-Z | a – z | ‘ | | ] 4. Entity Relationship Diagram Setelah kita buat DD, kita akan lanjutkan perancangan kita dengan membuat ERD. Objek-objek yang potensial untuk menjadi entitas adalah:
• Mahasiswa • Angkatan • MataKuliah • Skripsi
103
Kita dapat melihat bahwa ada hubungan antara mahasiswa, angkatan dan matakuliah. Hubungan tersebut adalah sebagai berikut:
Relasi diatas melibatkan tiga entitas. Relasi yang demikian akan menyulitkan kita ketika akan menentukan kardinalitas relasi. Untuk itu, relasi tersebut harus diubah menjadi relasi biner, yaitu:
Terlihat bahwa relasi nilai menjadi entitas nilai. Kemudian kita tentukan atribut-atribut penting pada entitas nilai diatas.
104
Kita tambahkan pada ERD diatas hubungan antara mahasiswa dengan skripsi. Selain itu atribut absensi yang terdapat pada nilai adalah jumlah kehadiran. Padahal kita memiliki data absensi yang dihubungkan dengan nilai.
Akhirnya kita lengkapi ERD kita dengan kardinalitasnya.
NN
11
105
Dan ERD diatas, kita buat model relasinya sebagai berikut: • Mata_kuliah (Kode_Matakuliah, Ket_Mata_Kuliah) • Angakatan(Kode_Angkatan, Ket_Angakatan) • Mahasisw(NIM, Nama_Mahasiswa) • Nilai(Kode_Matakuliah, Kode_Angkatann, NIM, Jumlah_Kehadiran, Nilai_Akhir,
Nilai_Indeks) • Skripsi(Kode_Skripsi, Judul_Skripsi, Judul, Pembimbing) • Nilai_Skripsi(Kode_Skripsi, NIM, Nilai_Skripsi) • Absensi(Tanggal, Jam, Kode_Matakuliah, Kode_Angkatan, NIM,
Jumlah_Kehadiran, Nilai_Akhir, Nilai_Indeks) 5. Block Chart (BC) Tahap berikutnya adalah pembuatan Block Chart, ada beberapa proses yang harus kita buat BC-nya, yaitu:
• Pencatatan data absensi. • Pembuatan rekapitulasi absensi. • Pencatatan berita acara. • Pencatatan berita acara skripsi. • Penghitungan nilai akhir. • Penentuan nilai indeks. • Pembuatan transkrip.
a. Pencatatan Data Absensi BC untuk data absensi. Masukkan : Keyboard, form absensi. Kekuaran : File absensi.
b. Pembuatan Rekapitulasi Absensi BC untuk rekapitulasi absensi. Masukkan : File absensi. Keluaran : File nilai.
106
c. Pencatatan Berita Acara Presentasi BC untuk pencatatan berita acara presentasi. Masukkan : Keyboard, Form berita acara presentasi. Keluaran : File nilai, Skripsi.
d. Pencatatan Data Skripsi BC untuk pencatatan data skripsi. Masukkan : Keyboard, form skripsi Keluaran : File skripsi
e. Pencatatan Nilai BC untuk pencatatan nilai. Masukkan : Keyboard, form nilai Keluaran : File nilai
f. Penghitungan Nilai Akhir BC untuk penghitungan nilai akhir. Masukkan : Keyboard, file nilai. Keluaran : File nilai.
107
Rumus
Penghitungan nilai
akhir
Nilai
Nilai
g. Penentuan Nilai Indeks BC untuk kenentuan nilai indek. Masukkan : Keyboard, file nilai. Keluaran : Layar monitor, file nilai.
h. Pembuatan Transkrip BC untuk pembuatan transkrip. Masukkan : File nilia, file nilai skripsi. Keluaran : Layar monitor, form transkrip
108
6. System Procedure (SP) Akhirnya kita selesaikan perancangan kita dengan membuat rancangan prosedurnya.
Absensi
Nilai Teori
Transkrip
AbsensiPresentasi
Skripsi
Berita
Acara
Presentasi
Dosen Administrasi Akademik Asisten Mahasiswa Penguji Skripsi
Pemasukan Nilai
Teori
Penentuan Nilai
Akhir Teori
Penentuan Nilai
Indeks
Pencatatan Data
Absensi Abse
nsi
Rekapitulasi
Absensi
Nilai
Pengisian Data
Skripsi
Data
Skrip
si
Pembuatan
Transkrip B. A
Prese
ntasi
Pencatatan Berita
Acara Presentasi
Nilai
Praktek
Rekapitulasi
Absensi
Rekapitulasi
Absensi
Form
Skripsi
Transkrip
Dosen dan asisten, setelah mengajar harus menyerahkan absensi kepada administrasi UHB untuk dilakukan pencatatan data absensi. Data absensi ini disimpan dalam suatu basis data yang bernama absensi, dan selanjutnya data absensi di-rekapitulasi dan hasilnya disimpan didalam basis data nilai. Selain itu, dosen dan asisten harus mengisikan nilai teori / praktek kedalam basis data nilai. Dan data nilai teori / praktek dilakukan proses penghitungan nilai akhir dan penghitungan nilai indeks. Hasil penghitungan tersebut disimpan kembali di dalam basis data nilai. Ketika mahasiswa UHB akan mengambil Skripsi (tugas akhir) dia harus mendaftar terlebih dahuku ke bagian administrasi UHB, dengan mengisi form Skripsi. Data tentang skripsi akan disimpan didalam basis data UHB. Selanjutnya setelah mahasiswa yang mengambil skripsi tersebut melakukan presentasi Skripsi, maka moderator skripsi harus memberikan berita acara presentasi untuk selanjutnya disimpan di basis data BA presentasi. Akhirnya administrasi UHB akan dapat memberikan transkrip kepada mahasiswa yang membutuhkan, dengan mengambil data dari basis data nilai dan dari BA presentasi.
109
TAHAPAN PENGEMBANGAN SISFO
Setelah memperlajari BAB Setelah memperlajari BAB Setelah memperlajari BAB Setelah memperlajari BAB 4444 ini diharapkan mahasiswa memahami dengan ini diharapkan mahasiswa memahami dengan ini diharapkan mahasiswa memahami dengan ini diharapkan mahasiswa memahami dengan
baik baik baik baik tahapan yang diltahapan yang diltahapan yang diltahapan yang dilalui dalam pengembangan sistem informasi, tahapan alui dalam pengembangan sistem informasi, tahapan alui dalam pengembangan sistem informasi, tahapan alui dalam pengembangan sistem informasi, tahapan
yang umum digunakan adalah waterfallyang umum digunakan adalah waterfallyang umum digunakan adalah waterfallyang umum digunakan adalah waterfall....
Materi yang dibahas dalam bab 4 ini meliputi
- Survei Sistem
- Analisa Sistem
- Desain Sistem
- Pembuatan (Coding) Sistem
- Implementasi Sistem
- Pemeliharaan Sistem
BAB 4
110
4.1. PENDAHULUAN Dalam melakukan pengemabangan sistem yang baik maka kita perlu memilih metodologi yang digunakan dalam pengembangan sistem. Dengan menggunakan metodologi dalam pengembangan sistem maka diharapkan kesalahan-kesalahan yang timbul selama pengembangan sistem dapat diketahui dari awal sehingga sistem yang akan dikembangkan menjadi optimal. Tahapan pengembangan sistem yang umum digunakan adalah: Waterfall model, Iterasi model dan Spiral model. Dalam materi ini kita akan menggunakan pendekatan Waterfall Model. Adapun tahapan yang ada dalam waterfall model adalah: Survei, Analisa, Desain, Pembuatan (Coding), Implementasi, Pemeliharaan. 4.2. SURVEI SISTEM Setelah adanya rencana dari pihak menajemen / klien (calon pelanggan) untuk membangusn sisem baru, maka divisi EDP / konsultan akan melaksanakan survei sistem. Proses ini dilaksanakan yang meliputi kegiatan Identifikasi Kondisi Eksistensi / Kebutuhan Pengguna, Definisi Ruang Lingkup Pekerjaan dan Penyusunan Study Kelayakan. Personil yang dibutuhkan dalam pengembangan sistem komputer meliputi:
• Project Coordinator. • System Analyst & Design. • Programmer. • Network Designer. • Technical (hardware). • Database Administrator. • Documentaer.
Bils sistem yang dikembangkan dalam skala kecil, maka hanya dibutuhkan System Analyst & Design, Programmer dan Documenter, dimana jabatan-jabatan ini bisa dirangkap oleh satu atau dua orang. 4.2.1. Identifikasi Kondidi Eksistensi dan Kebutuhan Pengguna Identifikasi kondisi eksistensi dan kebutuhan pengguna dilaksanakan dengan mengunjungi divisi yang bersangkutan / klien untuk mengetahui rencana aplikasi yang akan dikembangkan, ruang lingkup dan jadwal pelaksanaan, software dan hardware yang akan dipergunakan, serta inventarisasi terhadap sistem/aplikasi yang telah ada. Investigasi awal dapat dilakukan dengan wawancara dan penelitian terhadap dokumen yang ada. Investigasi ini wajib dilakukan, baik bagi konsultan yang membangun aplikasi untuk klien, maupun bagi bagian EDP yang membangun aplikasi untuk perusahaan sendiri. 4.2.2. Definis Ruang Lingkup Tujuan dari definisi ruang lingkup adalah untuk mengetahui ruang lingkup dari aplikasi yang akan dikembangkan baik luas cakupan dari aplikasi maupun tahapan pekerjaan, misalnya apakah konsultan akan mengembangkan dari awal sampai selesai atau hanya sampai tahap mendesain, sedangkan pemrograman dilakukan oleh klien.
111
4.2.3. Penyusunan Proposal Berdasarkan definisi ruang lingkup yang dibuat diatas, kemudian disusunlah proposal yang pada dasarnya memberikan gambaran umum tentang riancian biaya, rincian teknis yang mencakup jangka waktu dan aplikasi yang akan dikembangkan, kesimpulan yang menyangkut analisa keuangan / biaya serta dan methodologi yang akan digunakan. Proposal ini sangat penting karena merupakan dasar bagi klien untuk mengambil keputusan apakah akan melanjutkan proyek tersebut atau tidak. Proposal terdiri dari:
• Kelayakan operasional. • Kelayakan teknis. • Kelayakan ekonomis.
Contoh format propsal secara sederhana: I. Surat Pengantar, surat ini menjelaskan sepintas tentang perusahaan, biaya dan solusi
yang ditawarkan serta ucapan terimakasih. II. Lampiran
Pendahuluan, pada bagian ini dijelaskan latar belakang dan masalah-masalah yang dihadapi oleh perusahaan klien. Usulan Biaya, pada bagian ini diuraikan perincian biaya yang diperulakn dalam pembangunan aplikasi. Biaya kantor Rp. ........ Biaya Perangka Keas Rp. ........ Biaya Tenaga Ahli Rp. ........ Biaya Transportasi Rp. ........ Rincian Teknis
Jangka Waktu, selain menggambarkan jangka waktu pembuatan aplikasi, bagian ini sekaligus menggambarkan ruang lingkup pekerjaan konsultan.
Gambaran umum aplikasi, pada bagian ini diberikan gambaran umum aplikasi, yang meliputi metode pengkodean, menu dan toolbar, form dan report
Analisa Biaya dan Keuangan
Pada bagian ini dijelaskan keuntungan yang dapat diperoleh dari pembangunan aplikasi baru dibandingkan dengan sitem manual.
Dari segi baiaya - Biaya tenaga kerja Rp. .........
Penggunaan aplikasi baru - Biaya tenaga kerja Rp. ......... - Biaya penyusunan sistem Rp. ......... ------------- Efisiensi perbulan Rp. ........
112
Dari segi operasional Laporan keuangan lebih cepat Mengatasi masalah yang ada sepeti kesalahan posting, dan sebagainya.
Metodologi Bagian ini menjelaskan metode, alat dan teknis yang digunakan untuk pengembangan sistem.
Lampiran Pada bagian ini diberikan referensi keahlian yang dimiliki konsultan, nama aplikasi / perusahaan yang pernah ditangani dan sebagainya.
4.3. ANALISA SISTEM Setelah proposal disetujui untuk dilaksanakan, maka bagian EDP / konsultan dapat menilai pekerjaan tahapan berikutnya yaitu analisa sistem. Anaisa sistem dapat diartikan sebagai suatu proses untuk memahami sistem yang ada dengan menganalisa jabatan dan uraian tugas (business users), proses bisnis (business process), ketentuan / aturan yang ada (business rules), masalah dan mencari solusinya (business problems & solution), business tools dan rencana-rencana perusahaan (business plans). Tahapan ini sangat kritis karena kesalahan dalam tahap ini akan menyebabkan kesalahan dalam tahap Desaian Sistem. Oleh sebab itu faktor-faktor seperti ketelitian, metode pengumpulan data dan keahlian seorang analis sangat menentukan. 4.3.1. Business Users Business user merupakan personel yang menjalankan suatu bisnis, yang dapat dimulai dari staff, kasi, kabag / manajer sampai diraktur. 4.3.2. Analisa jabatan Tujuan dari analisa jabatan adalah untuk mempelajari jabatan-jabatan yang berkaitan dengan sistem yang akan dikembangkan. 4.3.3. Business Process Buseiness process menggambarkan rangkian tugas yang harus diselesaikan menurut aturan-auran tertentu untuk mendapatkan suatu hasil. 4.3.4. Business Ruless Untuk menjamin agar sebuah sistem dapat berjalan seperti yang diharapkan, perusahaan perlu menerapkan ketentuan / batasan yang dapat menjaga integritas / keabsahan data, jangan sampai merusak sistem yang ada atau merugikan perusahaan / organisasi. Ketentuan / batasan ini dikenal dengan istilah Business Ruless. 4.3.5. Business Problems & Solusi Analisa yang dilaksanakan dalam tahap ini dapat dibagi atas tiga tiga kelompok yaitu identifikasi masalah, identifikasi penyebab masalah dan penyelesaian masalah.
113
4.3.6. Business Tools Bagi perusahaan yang Business Tools-nya masih menggunakan sistem konvensional seperti masin ketik, maka tahap ini tidak perlu dianalisa lebih lanjut, karena pengadaan perangkat kearas dapat dilakukan dengan cara pengadaan baru. Analisa business toools dapat memberikan informasi mengenai kelebihan dan kekurangan sistem komputer tersebut dengan menganalisa input, proses dan output. 4.3.7. Business Plans Hasil analisa terhadap business users , business process, business rules, business problem dan busienss tools adalah menggambarkan kondisi yang ada sekarang ini yang terjadi pada sistem user. 4.4. DESAIN SISTEM Setelah memahami sistem yang ada termask solusi business problems dan kebutuhan (user reqirement), tahap selanjutnya adalah mendesain sistem baru agar dapat berjalan lebih baik, dan diharapkan dapat mengatasi masalah-masalah yang ada sedapat mungkin mengatasi kemungkinan-kemungkinan dimasa yang akan datang. Suatu sistem informasi yang dikomputerisasi haus terdiri dari:
• Hardware, terdiri dari komponen input, proses, output dan jaringan. • Software, terdiri dari sistem operasi, utiliti dan aplikasi. • Data, mencakup strukur data, keamanana dan integritas data. • Prosedur, seperti dokumentasi prosedur / proses sistem, buku petunjuk operasional
(aplikasi) dan teknis. • Manusia, yang terlibat dalam komponen manusia seperti operator, pemimpin sistem
informasi dan sebagainya. Manfaat desain sistem adalah memberikan gambaran rancang bangusn (blue print) yang lengkap, sebagai penuntun bagi programmer dalam mengembangkan aplikasi. Setelah memahami bisnis process yang sekarang, business rule, business problem and solution dan business plan, tiba saatnya untuk mendesain suatu model sistem informasi untuk mengatasi permasalahan. Dalam mendesain sistem ada 2 pendekatan yang dapat digunakan yaitu: 1. Pendekatan Berdasakan Proses dan Data.
Pendekatan berdasarkan proses mengunakan alat bantunya adalah DFD, DD, dan untuk memodelkan sistem berorientasi data dapat menggunakan ERD. Alat bantu pemodelan ini sudah dipelajari pada Bab 2.
2. Pendekatan Berorientasi Objek. Pendekatan berorientasi objek dapat menggunakan pendekatan secara OOA, OOD. Dengan menggunakan Class diagram, Use Case Diragarm. Pendekatan berorientasi objek akan dibahas pada bab 6.
114
4.5. PEMBUATAN SISTEM (Coding) Pembuatan sistem mencakup pembuatan database, progam aplikasi dan buku petunjuk: 4.5.1. Database Database Low End hanya dapat digunakan untuk membuat objek database seperti tabel, skema, indeks dan view, sedangkan databse High End memungkinkan untuk dibuat Database Triger atau Stored Procedur. 4.5.2. Aplikasi Suatu aplikasi umumnya terdiri dari forms, reports, class dan bitmaps. Pembuatan form, reports dan classes dapat dilakukan melalui application tools. Dalam lingkungan client/server, seorang programmer dituntut bukan hanya memahami application development tools, tetapi juga RDBMS, sistem operasi di client, di server dan midlware. 4.5.3. Buku Petunjuk Pembuatan buku petunjuk yang baik dan lengkap akan dapat menjamin kelangsungn suatu sistem / aplikasi. buku petunjuk yang umum dibuat dalam pengembangan sistem adalah:
1. Buku petunjuk sistem / proses Buku petunjuk ini berisi penjelasan tentang sistem tersebut.
2. Buku petunjuk teksnis Buku pentujuk teknis berisi masalah teknis aplikasi dan database. Seperti listing program, struktur database dan tool yang menjelaskan langkah-langkah program tersebut. Buku ini sangat dibutuhkan bila akan diadakan perubahan / penyempurnaan aplikasi.
3. Buku petunjuk operasional Buku ini digunakan oleh operator karena berisi petunjuk / penjelasan dan cara-cara menjalankan aplikasi.
4.5.4. Testing Tujuan dari testing adalah untuk mengetahui masih ada atau tidaknya kesalahan program, kekurangan atau ketidakefisienan sistem yang baru. 4.6. IMPELEMNTASI SISTEM Tahap impelemntasi sistem meliputi proses persiapan sistem, konversi sistem, pelatihan sistem dan pengoprasian sistem. 4.7. PEMELIHARAAN SISTEM Tahap pemeliharan sistem mecakup proses seluruh proses yang diperlukan untuk menjamin kelangsungan, kelancaran dan penyempurnaan sistem yang telah diperoleh. Tahapan ini penting mengingat hal-hal sebagai berikut: • Pengguna sistem yang telah dilatih kemungkinan belum siap untuk mengantisipasi
sistem baru, sehingga memerlukan waktu untuk penyesuaian.
115
• Meskupun sistem baru yang dioperasikan sudah diuji coba, tidak tertutup kemungkinan terjadinya ganguan-gangguan kecil (bug) yang tidak diantisipiasi sebelumnya.
• Setelah sistem berjalan, biasanya timbul kebutuhan baru dari organisasi, baik untuk
mengubah sistem (misalnya mengubah format isian, formay laporan, dan sebaginya), maupun untuk menambah sistem yang ada (misalnya menambah laporan baru, menambah isian baru, dan sebagainya).
• Walaupun sistem telah berfungsi sebagaimana yang diharapkan, masih sering muncul
masalah-masalah yang disebabkan oleh faktor diluar aplikasi, seperti virus dan kehilanagan atau kerusakan data.
Berdasarkan hal-hal diatas, maka proses-proses yang tercakup dalam tahapan ini meliputi pemantauan pengoprasian, antisipasi gangguan kecil (bug) dan penyempurnaan (up grading / enhancement) dan mengantisipasi faktor-faktor diluar aplikasi. 4.7.1. Pemantauan Pengoprasian Tujuan proses ini adalah untuk mencegah terjadinya kesalahan dalam pengoprasian, atau memperbaiki kesalahan pengoprasian yang telah terjadi, atau memperkecil dampak dari kesalahan pengoprasian yang telah terjadi. Kesalahan pengoprasian dapat terjadi karena ketidaktahuan atau kelalaian pengguna. 4.7.2. Antisipasi Gangguan Kecil (bug) Bug ini biasanya hanya terjadi jika penguna menjalakn suatu proses tertentu yang tidak diantisipasi oleh perancng sistem. Meskipun itu hanya gangguan kecil, tetapi kadang-kadang bisa berakibat fatal terhadap sistem, sehingga harus diantisipasi sedini mungkin, oleh karena itu proses ini termasuk dalam tahapan pemeliharaan. Contoh:
- Melinium bug dimana data jenis tahun untuk aplikasi tertentu yang disimpan dalam bentuk dua digit, akan menimbulkan gangguan pada tahun 2000.
4.7.3. Penyempurnaan (Upgrading) Sutu sistem setelah berjalan beberapa waktu biasanya membutuhkan penyesuaian karena berbagai alasan, seperti perkembangan bisnis, perubahan organisasi, perubahan kebijakan manajemen, dan sebagainya. 4.7.4. Antisipasi Faktor-faktor di Luar Sistem Seperti telah disebutkan, walalupun suatu sistem telah dapat berfungsi sebagaimana diharapkan, kita masih harus mengantisipasi terhadap:
- Virus. - Kerusakan / kehilangan data. - Sistem diakses oleh user yang tidak berhak.
116
4.8. ANALISA KASUS Rekan-rekan mahasiswa dapat membentuk kelompok untuk menyelesaikan kasus perancangan sistem informasi. Masing-masing kelompok mencari suatu topik (tidak boleh sama topik yang diambil dengan kelompok lain) kemudian masing-masing kelompok melakukan pengembangan sistem informasi sesuai dengan topik yang diambil. Dalam proses pengembangan sistem informasi menggunakan tahapan waterfall model. Laporan pengembangan sistem ini dikumpulkan pada akhir pekuliahan. Setiap tahapan yang dilalui dikonsultasikan dengan dosen pengajar matakuliah ini, sehingga akhirnya terbentuk laporan yang berisi tahapan pengembangan sistem, hingga sistem teruji dapat diimpelemtasikan. Sistem yang dibuat dapat menggunakan bahasa pemrograman VB 6.0, atau VB.Net, basis data yang diguankan dapat menggunakan MS-Access atau SQL Server. Sistem yang akan dikembangkan dapat berupa sistem berbasis WEB, atau bukan berbasis WEB. Sistem yang dikembangkan misalnya:
1. Sistem Rumah Sakit. 2. Sistem Biling Hotel. 3. Sistem Biling Sekolah. 4. Sistem Perpustakaan. 5. Sistem Penjulan dan Pembelian. 6. Sistem HRD dan Payroll. 7. Sistem General Ledger (sistem akuntansi). 8. Sistem Stok (inventory). 9. Sistem Apotek. 10. Sistem Bengkel. 11. Sistem Retail. 12. Sistem Administasi Universitas (BAAK). 13. dll.
Laporan masing-masing kelompok diprint kemudian dijilid dilengkapi dengan CD yang berisi aplikasi yang dibuat sesuai dengan kasus yang dikerjakan oleh masing-masing kelompok. Format penulisan menggnakan format penulisan skripsi, tujuan dari tugas ini supaya rekan-rekan mahasiswa memiliki bekal dalan penyusunan SKRIPSI. Adapun contoh Formatnya adalah: Halaman Judul (berisi judul yang diambil oleh masing-masing kelompok, dan berisi nama angota kelompok) Abstraksi Abstraksi cukup satu halaman saja, berisi penjelasan secara garis besar mengenai latar belakng topik yang diambil, permasalahan, solusi dan kesimpulan. Daftar isi (cukup jelas) Daftar Gambar (cukup jelas) Daftar Tabel (cukup jelas)
117
Bab 1 PENDAHULUAN 1.1. Latar Belakang
Berisi hal-hal yang melatar belakangi permasalahan yang timbul. 1.2. Rumusan Maslah
Merumuskan permasalah yang timbul dilatar belakang, sehingga lebih memperjelas maslah-maslah yang ada.
1.3. Ruang Lingkup Membatasi permaslahan supaya tidak terlalu luas cakupannya, dengan adanya batasan masalah ini akan menjadi lebih fokus terhadap topik yang diambil.
1.4. Tujuan dan Manfaat Memberikan pemaparan tentang tujuan dari penelitian sesuai dengan topik, dan manfaat apa yang didaptkan.
1.5. Metodologi Penelitian Berisi metodologi penelitian untuk pengumpulan data yang berguna dalam analisa dan desain sistem.
1.6. Sistimatika Penulisan Berisi penjelasan dari setiap bab
Bab 2 LANDASAN TEORI (berisi teori-terori yang mendukung dalam pengembangan sistem, yang digunakan dalam analisis dan desain) Bab 3 ANALISA dan DESAIN (Berisi analisa sistem yang berjalan, analiasa sisem dan desain sistem yang dikembangkan. Dalam Analisa dan Desain ini gunakan tahapan waterfall model. Dalam analisa dan desaian bila menggunakan tahapan waterfall model turunkan 3 tahapan yaitu: Survei, Analisis, dan Desain). Bab 4 IMPLEMENTASI (Pada bab 4 ini berisi implementasi dari sistem yang dikembangkan, bila menggunakan tahapan waterfall model dalam pengembagan sistem, maka pada bab 4 ini kita menurunkan level ke 4 Pembuatan sistem (coding / membuat program), ke5-Implementasi, ke-6 pemeliharaan). Bab 5 KESIMPULAN dan SARAN (Pada bab ini berisi kesimpulan dan saran mengenai pengembangan sistem yang dibuat, baik dari sistem yang berjalan hingga sistem yang dikembangkan. Saran berisi temuan-temuan yang baru, untuk pengembangan dimasa yang akan datang) Daftar Pustaka Berisi daftar buku-buku yang digunakan sebagai reverensi baik dari buku maupun dari internet.
118
TEKNIK YANG DIGUNAKAN DALAM PENGEMBANGAN SISFO
Setelah memperlajari BAB Setelah memperlajari BAB Setelah memperlajari BAB Setelah memperlajari BAB 5555 ini diharapkan mahasiswa memahami dengan ini diharapkan mahasiswa memahami dengan ini diharapkan mahasiswa memahami dengan ini diharapkan mahasiswa memahami dengan
baik teknik yang digunakan dalam pengembangan SISFO .baik teknik yang digunakan dalam pengembangan SISFO .baik teknik yang digunakan dalam pengembangan SISFO .baik teknik yang digunakan dalam pengembangan SISFO .
Materi yang dibahas dalam bab 5 ini meliputi
- Manajemen Proyek
- Analisa Biaya & Manfaat
- Pengumpulan Fakta
BAB 5
119
5.1. MANAJEMEN PROYEK Manajemen proyek memegang peranan yang sangat penting dalam pengembangan sistem informasi yang biasanya ditangani oleh seorang pimpinan proyek. Manajemen proyek dilakukan dari mulai survei hingga proyek selesai. Manajemen proyek merupakan disiplin ilmu yang sangat komplek yang memerlukan buku tersediri untuk membahasnya, sedangkan pembahasan disini hanya merupakan gambaran umum. 5.1.1. Kegiatan Pimpinan Proyek A. Estimasi
Apa yang harus diestimasi dalam pengembangan sistem informasi ?, hal tersebut sangat bervariasi dari satu proyek dengan proyek lainnya, namun ada beberapa hal yang umum seperti: 1. Sumber Daya Manusia, beberapa sistem analis, programmer, database designer,
ahli jaringan dan telekomunikasi yang dibutuhkan serta keahlian minimal. 2. Jadwal, berapa lama proyek tersebut dapat diselesaikan dan jadwal untuk setiap
kegiatan.
3. Anggaran, Berapa anggaran yang dibutuhkan untuk tenaga ahli, biaya kantor, administrasi dan lainnya.
Estimasi di atas sangat diperlukan dalam rangka penyusunan proposal yang akan diajukan ke client. Beberapa hal yang harus diperhatikan dalam estimasi adalah: 1. Kemungkinan estimasi anda masih akan dinegosiasi. 2. Kemungkinan hambatan-hambatan yang akan menyebabkan proyek berjalan lebih
lama dari estimasi. 3. Apakah tim mempunyai pengalaman untuk proyek bersangkutan ? jika tidak,
estimasi waktu yang lebih panjang.
B. Perencanaan dan Pengorganisasisan Setelah melakukan estimasi terhadap berapa lama proyek akan dikerjakan serta sumber daya manusia yang dibutuhkan, perlu dibuat suatu perencanaan dan pengorghanisasian antara kegiatan, SDM dan jadwal dengan menggunakan diagram Gantt atau PERT (Program Evaluasi and Review Technique). Dalam perencanaan dan pengorganisasian juga ditetapan teknik pembentukan tim apakah menggunakan Losely Structured Teams (anggota berasal dari beberapa jenis keahlian dalam semua bidang), ataukah menggunakan Structured Teams (anggota tim disusun menurut aturan hierarki).
C. Memonitor Agar semua kegiatan dapat berjalan sesuai dengan rencana, setiap kegiatan tersebut termasuk jadwal, penggunaan sumber daya manusia dan penggunaan dana harus dimonitor.
120
D. Penyesuaian Walaupun telah dimonitor semua kegiatan tersebut, tidak tertutup kemungkinan terjadi penyimpangan-penyimpangan yang disebabkan banyak faktor seperti adanya pegawai yang tidak dapat melaksanakan tugas sesuai rencana karena sakit / kecelakaaan, output dari tenaga ahli tidak sesuai dengan harapan. Dengan mengetahui penyimpangan secara dini segera dapat dilakukan penyesuaian seperlunya.
5.1.2. Diagram Aktivitas dan Jadwal Diagram balok (gantt chart) merupakan cara yang mudah untuk menggambarkan jadwal dan akativitas yang akan dikerjakan. Diagram balok terdiri dari kolom aktivitas yang menggambarkan aktivitas yang dilakukan dalam pengembangan sistem informasi, sedangkan tanggal menggambarkan mulai dan selesainya pelaksanaan suatu kegiatan.
Gambar 5.1 Gantt Chart pengembangan aplikasi
5.1.3. Walkthrough Dalam monitoring, pengawasan lebih ditujukan kepada masalah manajemen seperti penggunaan SDM dan dana, akan tetapi keberhasilan suatu sistem juga harus dilihat dari segi teknis dan kepuasan pengguna. Oleh suatu review secara teknis (walkthrough) yang melibatkan pemakai, sistem analis / programmer yang tidak terlibat langsung dengan sistem yang akan dikembangkan untuk memeriksa ulang spesifikasi teknis dan output yang dihasilkan oleh program yang dibuat. 5.2. PENGUMPULAN FAKTA Salah satu faktor yang terpenting dalam pengembangan sistem informasi adalah memahami sistem yang ada dan permasalahannya. Untuk itu selain mngetahui bagian-bagian mana saja yang akan dipelajari, kita juga harus memilih teknik yang tepat untuk mengumpulkan fakta/data. Beberpa teknik yang umum digunakan antara lain:
� Wawancara (interview). � Daftar pertanyaan (questionnaire). � Pengamatan langsung (overvation). � Membaca buku sistem / dokumen. � Presentasi oleh user.
5.2.1. Wawancara Wawancara merupakan salah satu teknik pengumpulan fakta / data yang banyak digunakan sistem analis. Beberapa kebaikan dari wawancara adalah:
� Analisi dapat bertatap muka langsung dengan user, sehingga dapat lebih akrab. � Memungkinkan pertanyaan berkembang sesuai dengan situasi yang berkembang.
121
� Karena tidak tertulis, user lebih berani menggunakan permasalahan yang dihapdai dalam pekerjaan.
5.2.1.1. Jenis-jenis pertanyaan Open question, digunakan untuk meminta pendapat / pandangan dari user. Contohnya:
� Bagimana pendapat anda tentang kompuerisasi di divisi anda ?. atau
� Pekerjaan apa ang tidak relevan lagi dikerjakan secara manual ?. Close question, merupakan pertanyaan yang memerlukan jawaban yang lebih spesifik. Contohnya:
� Berapa kali diadakan stok opname ?. atau
� Ke mana laporan order penjualan di kirim ?. Probe question, digunakan untuk menanyakan lebih detail dari close question. Bila dalam close question disebutkan laporan oerder penjualan dikirim ke departemen penjualan, maka dapat ditanya lebih detail seperti :
� Kenapa mengirim ke departemen penjualan ?. 5.2.1.2. Mempersiapkan wawancara Sebelum melakukan wawancara terlebih dahulu harus dibuat persiapan-persiapan mencakup:
� User yang akan diwawancara. � Urutan dari user yang akan diwawancara. � Daftar pertanyaan untuk setiap user. � Jadwal pertanyaan.
5.2.1.3. Langkah-langkah wawancara Beberapa langkah dalam melakukan wawancara antara lain:
� Terlebih dahulu memperkenalkan diri. � Menjelaskan maksud dan tujuan dari wawancara. � Menjelaskan waktu yang dibutuhkan dan informasi yang dibutuhkan dari user. � Memasuki inti wawancara. � Membuat kesimpulan dari wawancara tersebut.
5.3.2. Daftar Pertanyaan Daftar pertanyaan adalah teknik pengumpulan data dengan mengirim pertanyaan-pertanyaan kepada user untuk menjawab secara tertulis dan dikembalikan kepada sistem analis. Beberapa kebaikan dari daftar pertanyaan adalah:
• Dapat menjangkau responden / user yang banyak pada saat yang sama. • Tidak mengganggu aktivitas pekerjaan. • Pelaksanaan lebih sederhana.
122
5.2.2.1. Tipe-tipe daftar pertanyaan Ada tiga tipe daftar pertanyaan yitu tipe pertanyaan, tipe memeriksa (check-off), dan tipe pilihan ya/tidak. Berikut ini diberikan contoh untuk masing-masing tipe tersebut. Contoh tipe pertanyaan Tugas apa saja yang anda kerjakan dan dilapor kepada siapa ? .................................................................................................. .................................................................................................. .................................................................................................. Contoh tipe memeriksa Jenis komputer yang anda gunakan ?
- Tipe 80386 - Tipe 80486 - Tipe pentium - Lain-lain sebutkan ....................... Jika jawaban yang dipilih dapat lebih dari satu, dibuat catatan yang menyebutkan bahwa jawaban dapat dipilih lebih dari satu. Contoh tipe Ya/Tidak Apakah pegawai pencatat piutang menerapkan mencatat utang ?
- Ya - Tidak
5.2.3. Pengamatan Langsung Pengamatan lansung merupakan teknik pengumpulan data dengan cara langsung melihat kegiatan yang dilakukan oleh user. Salah satu keuntungan dari pengamatan langsung adalah sistem analis dapat lebih mengenal lingkungan fisik seperti tata letak ruangan, serta peralatan yang digunakan dan formulir. Selain itu juga sangat membantu untuk melihat proses bisnis secara langsung beserta kendala-kendalanya. 5.2.4. Membaca Buku Sistem & Dokumen Cara yang tidak mengangu kegiatan user ialah dengan cara membaca buku sistem dan dokumen perushaan. Permasalahan yang ada dengan teknik ini ialah tidak semua perushaan memiliki buku sistem yang menggambarkan keseluruhan bisnis proses dan aturan bisnis di perusahaan tersebut. 5.2.5. Presentasi Oleh User Dengan teknik ini, user yang harus lebih aktif mempersiapkan segala bahan-bahan yang akan dipresentasi seperti proses kerja, permasalahan yang dihadapi dan harapan-harapan user dari sistem baru. Sistem analis hanya mendengar dan sekali-sekali bertanya jika memerlukan penjelasan lebih detail.
123
PENGANTAR UML
Setelah memperlajari BAB Setelah memperlajari BAB Setelah memperlajari BAB Setelah memperlajari BAB 6666 ini diharapkan mahasiswa memahami dengan ini diharapkan mahasiswa memahami dengan ini diharapkan mahasiswa memahami dengan ini diharapkan mahasiswa memahami dengan
baik teknik yang digunakan dalam baik teknik yang digunakan dalam baik teknik yang digunakan dalam baik teknik yang digunakan dalam rekayasa rekayasa rekayasa rekayasa SISFO SISFO SISFO SISFO berbasis objek berbasis objek berbasis objek berbasis objek
(OOA/OOD)(OOA/OOD)(OOA/OOD)(OOA/OOD)....
Materi yang dibahas dalam bab 6 ini meliputi
- Pendahuluan
- Apa itu UML
- Konsep Dasar UML
- Pengantar UML
Catatan: Materi untuk UML ini diambil dari materi ilmukomputer.com
BAB 6
124
Kuliah Umum IlmuKomputer.Com Copyright © 2003 IlmuKomputer.Com
Pengantar Unified Modeling Language (UML) Sri Dharwiyanti [email protected]
Romi Satria Wahono [email protected] http://romisatriawahono.net Lisensi Dokumen: Copyright © 2003 IlmuKomputer.Com Seluruh dokumen di IlmuKomputer.Com dapat digunakan, dimodifikasi dan disebarkan cara bebas untuk tujuan bukan komersial (nonprofit), dengan syarat tidak menghapus atau merubah atribut penulis dan pernyataan copyright yang disertakan dalam setiap dokumen. Tidak diperbolehkan melakukan penulisan ulang, kecuali mendapatkan ijin terlebih dahulu dari IlmuKomputer.Com.
Related Documents
