Analisis Dan Perancangan Sisfo

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

ANALISIS dan PERANCANGAN SISTEM INFORMASI

BAB 1

TAHAPAN PENGEMBANGAN SISFO 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 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

2

Halaman 4

20

ANALISIS dan PERANCANGAN SISTEM INFORMASI

BAB 1

TAHAPAN PENGEMBANGAN SISFO 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 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

2

Halaman 4

20

BAB 3

MENYEIMBANGKAN MODEL DFD vs DD DFD vs PS PS vs DFD DD vs DFD vs PS ERD vs DFD vs PS DFD vs STD

89

BAB 4

TAHAPAN PENGEMBANGAN SISFO Survei Sistem Analisa Sistem Desain Sistem Pembuatan Sistem Implementasi Sistem Pemeliharaan Sistem

109

BAB 5

TEKNIK YANG DIGUNAKAN DALAM PENGEMBANGAN SISFO 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) 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

3

118

123

BAB 1 TAHAPAN PENGEMBANGAN SISFO

 Setelah memperlajari BAB ini diharapkan mahasiswa memah memahami  ami dengan BAB  111   ini   baik  baik tahapantahapan -tahapan  pengembangan pengembangan sistem sistem informasi informasi menggunakan menggunakan tahapan Waterfall, Iterasi dan Spiral dalam mencapai daur hisup sistem. Spiral  dalam  Materi yang dibahas dalam bab 1 ini meliputi  -  Pendahuluan - Unsur Yang terlibat Dalam Pengembangan Sistem -  Siklus Hidup SISFO  -  Perubahan Dalam Analisa Sistem -  Perancangan SISFO 

4

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)

5

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)

6

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.

7

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 unsurunsur 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.

8

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 ciriciri 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)

9

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. •

10

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. •

11

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

12

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.

13

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. Tahapantahapan 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

14

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

15

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).

16

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 memperbaiki kesalahan serta kecurangan yang akan terjadi.

mendeteksi

5. Efisien, Peningkatan pengunaan sumber daya secara optimal. 6. Pelayanan, Peningkatan terhadap pelayanan yang diberikan oleh sistem.

17

dan

1.6. LATIHAN 1. Pandanglah universitas anda sebagai suatu sistem. Identifikasi komponenkomponen 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.

18

KERTAS KERJA (1)

19

BAB 2

 ALAT PEMODELAN SISTEM 

 Setelah memperlajari BAB 2 ini diharapkan mahasiswa  mengetahui mengetahui  dengan dengan  mengetahui    baik alat  alat- alat dapat  digunakan untuk  alat bentu bentu perancangan perancangan sistem sistem yang yang dapat  dapat    memodelka memodelkan   n sistem informasi, baik menggunakan pemodelan trandisonalm trandisonalm  struktur maupun pemodelan  berbasis berbasis  objek. objek.  berbasis   Materi yang dibahas dalam bab 2 ini meliputi  -  Metodologi Berorientasi Keluaran -  Metodologi Berorientasi Proses  -  Metodologi Berorientasi Data -  Metodologi Berorientasi Objek 

20

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  dan partitioned .. •  redudancy . Memenuhi persyaratan minimal  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. Oriented  / Metodologi Berorientasi Objek. 4. Object Oriented /

21

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

22

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

23

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.

24

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.

25

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 •

26

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

27

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

28

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.

29

KERTAS KERJA (2)

30

31

32

Dari abstraksi diatas buatlah DFD yang memetakan sistem pelayanan Hotel. Langkahlangkah 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 )

33

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

Berat_sekarang

= ** *satuan : sentimeter; rentang 1-200* = ** *satuan : kilogram; entang 1-300*

Tanggal_lahir

= ** *satuan : hari sejak 1 januari 1900; rentang 36500*

Jenis_kelamin Jenis_kelami n

= ** *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 

34

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

35

masuk akan disimpan dalam data store Kas dan Bank. Selanjutnya dari data yang telah tesimpan, diharapkan diperoleh laporan-laporan yang akan diberikan untuk direksi. Form kas masuk

1 Kas Masuk

Data kas masuk

Data kas keluar 

2 Kas Keluar 

Form kas keluar 

Pihak Luar 

Bagian

Kas dan BANK BANK

BANK

Form bank masuk

3 BANK Masuk

Data Data bank bank keluar  masuk

4 BANK Keluar 

Form bank keluar 

Data kas & bank

5 Pelaporan

Lap. kas bank

Direksi

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 

36

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 

37

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. = * 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 * Form Kas Masuk

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.

38

LATIHAN ANALISA KASUS DFD Buatlah DD untuk sistem rumah sakit berdasarkan DFD yang kita rancang pada latihan kasus materi DFD.

KERTAS KERJA (3)

39

40

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;

41

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

42

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

43

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

44

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. Masakanmaskan 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.

45

Pase Bahan baku kue Bahan makana dari pasar  Toko Roti Kue-kue Bahan makanan dari supermarket

Kue-kue

1 Seleksi & penyimpanan bahan makanan

Ayam 3 Pembuatan ayam bakar 

Ikan & ayam

Supermarket

Ayam

Bahan baku Buah-buahan

Bahan baku

7 Menyajikan buah-buahan

Apel

Ikan

Sayuran

Tepung, gula, dll

Buah-buahan

2 Menyajikan kue-kue

Kue-kue

Sayur-sayuran

Bahan baku

Bahan sayur  

6 Pembuatan kue apel

5 Pembuatan sayur asem

ikan

4 Pembuatan Ayam ikan mas bakar  bakar 

Kue-kue

Ikan bakar 

Sayur-sayuran Kue apel Buah-buahan

Tamu undangan

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.

46

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

47

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. 3 Pembuatan ayam bakar 

Ikan & ayam 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)

48

49

50

2.3.4. STATE TRANSITION DIAGRAM (STD) Diakhir tahun 1980 sistem yang memodelkan tingkah laku ketergantungan pada watu ( timedependent 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.

51

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

52

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.

53

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 Konidi Aksi State 2

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.

54

Tunggu Tekan “Masukkan kartu”

Reset

Tunggu Kartu Reset or  Password salah

Kartu dimasukkan “Masukkan password”

Bersihkan layar  Tunggu Password Password dimasukkan “Pilih fungsi”

Reset Bersihkan layar  Tunggu Jawaban

Ambil Uang

Tunggu Uang

Tunggu Neraca

Deposit Uang

Transfer Dana

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:

55

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.

56

KERTAS KERJA (5)

57

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 Mahasiswa

Mata kuliah

Konstanta

Transkip

Nilai Praktek  Key In

Penghitungan

Transkirp

Nilai Teori Konstanta

Gambar 2.23 Block Chart menghitung nilai mahasiswa

58

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

59

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 ).

Data pasien

P   a  s  i       e n

Catatan kesehatan pasien

Pengambilan cat.kesehatan 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

60

Catatan kesehatan pasien

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 diagnosa

7. Pencatatan daftar biaya Masukan : File resep, file injeksi, file pasien. Keluaran : monitor, biaya pasien ( print out ).

61

resep

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.

62

KERTAS KERJA (6)

63

64

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 pencampuran, pencetakkan dll.

proses

manual

seperti

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 (screen).

65

keluaran

dalam

bentuk

layar

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

Nilai Teori

Nilai Praktek 

Bagian Akademik

Transkrip Nilai

Pengumpulan Nilai

Key in

Penghitungan

Transkrip Nilai

Transkrip Nilai

Mahasiswa

Gambar 2.25 Sistem prosedur akademik 

66

Mahasiswa

CONTOH ANALISA KASUS SP Untuk memudahkan pembuatan prosedur, cara paling tepat adalah mengkonsentrasikan pada dokumen, asal dokumen, tujuan, serta alur dokumen.

dengan

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 dokumendokumen 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:

67

Pasien

Data pasien

Administrasi Rumah Saikit

Dokter

Direktur Rumah Sakit

Pencetatan data pasien Laporan keuangan

Diagnosa

Biaya pasien

Laporan keuangan

Laporan pemakian obat

Pencatatan riwayat kesehatan pasien

Laporan pemakian obat

Riwayat kesehatan pasien

Penghitungan biaya pasien

Biaya pasien

Pembuatan laporan

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.

68

KERTAS KERJA (7)

69

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

70

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).

Pekerja 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.

Warna_item

Pekerja

Ukuran item Deskripsi_item 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.

Mahasiswa

1

Mengambil

Nim_Mhs

Kode_MataK

Nama

Nim_Mhs Nilai_Ujian

Gambar 2.30 Entiti, atribut dan hubungan

71

N

Mata Kuliah

Kode_MataK

Nama_M_K

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).

Penjual

Bapak 

Ibu

Penjualan

Ortu

Item

Anak 

(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.

Supir

1

Penugasan

1

Mobil

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.

72

Kelas

Berisi

1

M

Siswa

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.

Grup

Beranggota kan

M

N

Personil

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 Sekamar dengan

Penghuni

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.

Pelanggan

1

Melakukan

Gambar 2.36 Entiti lemah

73

N

Transaksi

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.

74

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.

75

•

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.

76

•

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

77

2. Betuk cardinality yang diusulkan oleh Chen

3. Bentuk cardinality yang diusulkan bachman

78

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.

79

 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 Keterangan Nomor Nama Jumlah Bukti Perkiraan Perkiraan Debet 01/01/97 K001 Penerimaan 100.000 Kas 350.000 800.000 Penjualan 02/02/97 B002 Pembelian 120.000 Persediaan 400.000 100.000 Kas 108.000 Piutang Gambar 2.39 Form yang belum dinormalisasikan

Bentuk normal kesatu Bentuk normal kesatu menjadikan semua kolom berisi data. Tanggal Nomor Keterangan Nomor Nama Jumlah Bukti Perkiraan Perkiraan Debet 01/01/97 K001 Penerimaan 100.000 Kas 350.000 01/01/97 K001 Penerimaan 800.000 Penjualan 02/02/97 B002 Pembelian 120.000 Persediaan 400.000 02/02/97 B002 Pembelian 100.000 Kas 02/02/97 B002 Pembelian 108.000 Piutang Gambar 2.40 Bentuk normal ke satu

80

Jumlah Kredit 350.000 250.000 150.000

Jumlah Kredit 350.000 250.000 150.000

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 Nama Perkiraan Perkiraan 100.000 Kas 108.000 Piutang 120.000 Persediaan 800.000 Penjualan

Tanggal 01/01/97 01/01/97 02/02/97 02/02/97 02/02/97

Nomor Bukti K001 K001 B002 B002 B002

Keterangan

Nomor Nama Jumlah Perkiraan Perkiraan Debet Penerimaan 100.000 Kas 350.000 Penerimaan 800.000 Penjualan Pembelian 120.000 Persediaan 400.000 Pembelian 100.000 Kas Pembelian 108.000 Piutang Gambar 2.41 Bentuk normal ke dua

Jumlah Kredit 350.000 250.000 150.000

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.

81

Tanggal 01/01/91 02/02/97

TblJurnalHeader Nomor Keterangan Bukti K001 Penerimaan B002 Pembelian TblMater Perkiraan Nomor Nama Perkiraan Perkiraan 100.000 Kas 108.000 Piutang 120.000 Persediaan 800.000 Penjualan

TblJurnalDetail Nomor Nomor Bukti Perkiraan K001 100.000 K001 800.000 B002 120.000 B002 100.000 B002 108.000

Jumlah Debet 350.000

Jumlah Kredit 350.000

400.000 250.000 150.000 Gambar 2.42 Bentuk 2.42 Bentuk normal ke tiga

Contoh ERD Contoh berikut ini cara lain dalam menggambarkan diagram ER.

Gambar 2.43 Diagram 2.43 Diagram ER (Entity Relationship) hotel

82

ER juga dapat dimodelkan seperti gambar berikut ini.

Gambar 2.44 Diagram 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.

83

KERTAS KERJA (8)

84

85

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.

86

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 diagramdiagram 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 Name

Class Name

Atribut

Atribut

Method

Method

Class-With-Object

Class

Gambar 2.46 Contoh notasi class dengan notasi Coad /Yordon Class Name

Class Name Atribut

Atribut

Method

Method

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 / subsistemsubsistem.

87

4. 5. 6.

 Attributes, data / keterangan yang menjelaskan objek ditambhakan untuk setiap objek. Services, method ditambahkan untuk menjelaskan proses / kegiatan yang akan dikerjakan oleh setiap objek bila menerima suatu messages (event).  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.

88

BAB 3

 MENYEIMBANGKAN  MODEL

 Setelah memperlajari BAB  BAB 3 3   ini ini diharapkan mahasiswa mema memahami  hami dengan 3  baik penyeimbangan model dalam merancang sistem sistem..  baik  penyeimbangan  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 

89

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 bersamasama, 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

90

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

91

DFD karena itu dapat diambil kesimpulan bahwa pemodelan sistem ini sudah imbang.

Z

Hitung W

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.

92

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.

93

Dosen

Asisten

BAAK

Mahasiswa

Penguji Skripsi

Absensi

Absensi

Rekapitulasi Absensi

Form Skripsi

Berita Acara Presentasi

Rekapitula si Absensi Nilai Teori

Nilai Praktek

Penentuan Nilai Akhir  Teori

Penentuan Nilai Akhir  Praktek

Pendaftaran Skripsi

Nilai Akhir  Teori

Nilai Akhir  Praktek

Form Skripsi

Penentuan Nilai Akhir  Teori

Penentuan Transkrip

Nilai Indeks

Transkrip

Presentasi Skripsi

Transkrip

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.

94

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. •

95

Administasi Akademik / BAAK

Dosen Nilai teori, Nilai akhir, Nilai indeks

Transkrip Sistem administrasi akademik

Nilai praktek

Data presenasi

Asisten

Penguji Skripsi Absensi

Mahasiswa

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.

96

5 Pencatatan berita acara presentasi

1 Pencatatan dan absensi

Data absensi

6 Pencatatan data skripsi

Data skrispi 3 Penghitungan nilai akhir 

Absensi

Berita acara presentasi

Data skripsi

Data skripsi

Data rekap absen Data Rekap absen 2 Pembuatan Data rekap absensirekapitulasi

Data nilai 7 Pembuatan transkrip

Data presentasi Nilai akhir 

absensi Data nilai indek Rekap absen

Data berita acara presentasi

Data skripsi

Dat anilai indeks

Nilai indeks

4 Penentuan nilai indeks

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. •

97

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

98

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.

99

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 : NIM Nama 1

Nilai Teori 2 3 4

1

Nilia Praktek  2 3 4

Rekap_Absensi = @ Angkatan + @Matakuliah + {NIM + Nama + NT1 + NT2 +NT3 +  NT4 + NP1 + NP2 + NP3 + NP4}

100

D. Nilai Akhir DD untuk nilai akhir sebagai berikut: Angkatan : Matakuliah : NIM Nama

Nilai Akhir 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

Skrispis Judul Nilai Transkrip

Nilai

: : : = @NIM+Nama_Mahasiswa + {Nilai_Matakuliah} + Judul_Skripsi + Nilai

101

Tanggal Jam Angkatan Kode_Angkatan Ket_Angakatan Mata_Kuliah Kode_Mata_Kuliah Ket_Mata_Kuliah NIM Nama_Mahasiswa Kehadiran Jumlah_Absensi NT1 NT2 NT3 NT4 NP1 NP2 NP3 NP4 NTA NPA Indeks Kd_Skripsi Mahasiswa_skripsi Judul_Skripsi Tempat_skripsi Pembimbing Dosen Kode_Dosen Nama_Dosen Nilai_Skripsi Penguji Nilai_Mata_Kuliah Angka Karakter

:= *Tgl-Bulan-Tahun* := *99:99* := Kode_Angkatan + Ket_Angakatan := 1{Karakter}2 := 1{Karakter}30 := Kode_Mata_Kuliah + Ket_Mata_Kuliah := 1{Karakter}2 := 1{Karakter}30 := 1{Karakter}8 := 1{Karakter}30 := [“Ya” | “Tidak”] := 1{Angka}3 := 1{Angka}3 := 1{Angka}3 := 1{Angka}3 := 1{Angka}3 := 1{Angka}3 := 1{Angka}3 := 1{Angka}3 := 1{Angka}3 := 1{Angka}3 := 1{Angka}3 := [“A” | “B” |“C” |“D” |“E” ] := 1{karakter}3 := NIM := 1{Karaker}30 := 1{Karakter}30 := Dosen := Kode_Dosen + Nama_Dosen := 1{Karaker}3 := 1{Karakter}30 := Indeks := Dosen := Indeks := [0-9 | . | ,] := [A-Z | a – z | ‘ | | ]

4. Entity Relationship Diagram Setelah kita buat DD, kita akan lanjutkan perancangan kita dengan membuat ERD. Objekobjek yang potensial untuk menjadi entitas adalah: Mahasiswa • Angkatan • MataKuliah • Skripsi •

102

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.

103

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.

   N

   N

   1

   1

104

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.

105

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.

106

Nilai

Penghitungan nilai akhir 

Rumus

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

107

6. System Procedure (SP) Akhirnya kita selesaikan perancangan kita dengan membuat rancangan prosedurnya. Dosen

Absensi

Administrasi Akademik

Asisten

  e   i   s   s    b   n    A

Pencatatan Data Absensi

Absensi

Pemasukan Nilai Teori

Form Skripsi

Nilai Praktek

Rekapitulasi Absensi Nilai Teori

Mahasiswa

Penguji Skripsi

Presentasi Skripsi

Berita Acara Presentasi

   i   a    l    i    N

Rekapitulasi Absensi Pengisian Data Skripsi

Penentuan Nilai Akhir Teori

Rekapitulasi Absensi

  p   a   i    t   r   i   a   k   s    D    S

Pencatatan Berita Acara Presentasi

Penentuan Nilai Indeks

Pembuatan Transkrip

  e   i    A  s   s   a  .   e    t B  r   n    P

Transkrip

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.

108

BAB 4

TAHAPAN PENGEMBANGAN SISFO

 Setelah memperlajari BAB  BAB 4 4   ini ini diharapkan mahasiswa memahami dengan   baik  baik tahapan tahapan yang yang dil  dilalui dil    alui dalam dalam pengembangan pengembangan sistem sistem informasi, informasi, tahapan tahapan  yang umum digunakan adalah waterfall  waterfall..  Materi yang dibahas dalam bab 4 ini meliputi  -  Survei Sistem -  Analisa Sistem - Desain Sistem -  Pembuatan (Coding) Sistem -  Implementasi Sistem -  Pemeliharaan Sistem

109

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.

110

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 - Biaya penyusunan sistem

Rp. ......... Rp. ......... ------------Rp. ........

Efisiensi perbulan

111

Dari segi operasional Laporan keuangan lebih cepat Mengatasi masalah yang ada sepeti kesalahan posting, dan sebagainya. Metodologi Bagian ini menjelaskan pengembangan sistem.

metode, alat dan teknis yang digunakan untuk 

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 aturanauran 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.

112

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.

113

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.

114

•

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 kadangkadang 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.

115

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)

116

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 temuantemuan yang baru, untuk pengembangan dimasa yang akan datang) Daftar Pustaka Berisi daftar buku-buku yang digunakan sebagai reverensi baik dari buku maupun dari internet.

117

BAB 5

TEKNIK YANG DIGUNAKAN DALAM PENGEMBANGAN SISFO

 Setelah memperlajari BAB 5   ini ini diharapkan mahasiswa memahami dengan BAB  5 5  baik teknik yang digunakan dalam pengembangan SISFO .  Materi yang dibahas dalam bab 5 ini meliputi  -  Manajemen Proyek  -  Analisa Biaya & Manfaat  -  Pengumpulan Fakta

118

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.

119

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.

120



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 pertanyaanpertanyaan 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. •

121

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.

122

BAB 6

PENGANTAR UML

 Setelah memperlajari BAB  BAB 66   ini ini diharapkan mahasiswa memahami dengan   baik teknik yang digunakan dalam   rekayasa rekayasa   SISFO  SISFO SISFO   berbasis objek  (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

123