Vous êtes sur la page 1sur 124

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

Halaman
BAB 1 TAHAPAN PENGEMBANGAN SISFO 4
Pendahuluan
Sistem
Pengertian sistem
Karakteristik sistem
Pengertian sub sistem
Sistem yang buruk
Beberapa konsep sistem yang penting
Data
Informasi
Sistem Informasi
Sistem Informasi Manajemen
Sistem Informasi Bisnis
Sistem Analisis dan Desain
Unsur Yang Terlibat Dalam Pengembangan Sistem
Pengguna sistem
Perancang sistem
Siklus Hidup SISFO
Tahap Perencanaan (waterfall, iterasi dan spiral)
Tahap Pengembangan SISFO
Tahap Evaluasi
Perubahan Dalam Analisa Sistem
Perancangan SIFO

BAB 2 ALAT PEMODELAN SISTEM 20


Metodologi Berorientasi Keluaran
Metodologi Berorientasi Proses
Data Flow Diagram (DFD) / Diagram Aliran Data.
Data Dictionary (DD) / Kamus Data.
Process Specification (PS) / Proses Spesifikasi.
State-Trasition Diagram (STD).
Block Chart Diagram (BCD).
System Procedure Diagram (SPD).
Metodologi Beroirentasi Data
ERD
Metodologi Berorientasi Objek

2
BAB 3 MENYEIMBANGKAN MODEL 89
DFD vs DD
DFD vs PS
PS vs DFD
DD vs DFD vs PS
ERD vs DFD vs PS
DFD vs STD

BAB 4 TAHAPAN PENGEMBANGAN SISFO 109


Survei Sistem
Analisa Sistem
Desain Sistem
Pembuatan Sistem
Implementasi Sistem
Pemeliharaan Sistem

BAB 5 TEKNIK YANG DIGUNAKAN DALAM


PENGEMBANGAN SISFO 118
Manajemen Proyek
Kegiatan pimpinan proyek
Diagram aktivitas dan jadwal
Walktrough
Pengumpulan Fakta
Wawancara
Dafatar pertanyaan
Pengamatan langsung
Membaca buku sistem dan dokumen
Presentasi oleh user

BAB 6 PENGANTAR UML (OOA/OOD) 123


Pendahuluan
Apa Itu UML
Konsep Dasar UML
Pengantar UML
Use Case Diagram
Class Diagram
State Chart Diagram
Activity Diagram
Sequence Diagram
Collaboration Diagram
Component Diagam
Deployment Diagram

3
BAB 1

TAHAPAN
PENGEMBANGAN SISFO

Setelah memperlajari BAB 1 ini diharapkan mahasiswa memahami


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

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 unsur-
unsur dari sisem yang membentuknya. Berikut ini adalah karakteristik sistem yang dapat
membedakan suatu sistem dengan sistem yang lainnya.
1. Batasan (boundray), yang menjadi batasan sistem, yang mana termasuk didalam
sistem dan yang mana diluar sistem.
2. Lingkungan (environment), segala sesuatu diluar sistem, lingkungan yang
menyediakan asumsi, kendala, dan input terhadap suatu sistem.
3. Masukkan (input), sumber daya (data, bahan baku, peralatan, energi) dari
lingkungan yang dikonsumsi dan dimanipulasi oleh suatu sistem.
4. Keluaran (output), sumber daya atau produk (informasi, laporan, dokumen,
tampilan layar komputer, barang jadi) yang disediakan untuk lingkungan sistem
oleh kegiatan dalam suatu sistem.
5. Komponen (component), kegiatan-kegiatan atau proses dalam suatu sistem yang
mentransformasikan input menjadi bentuk setengah jadi (output). Komponen ini
bisa merupakan subsistem dari sebuah sistem.
6. Penghubung (interface), tempat dimana komponen atau sistem dan lingkungannya
bertemu atau berinteraksi.
7. Penyimpanan (storage), area yang dikuasai dan digunakan untuk penyimpanan
sementara dan tetap dari informasi, energi, bahan baku dan sebagainya.

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 ciri-
ciri dari sistem yang buruk:
• Tidak memenuhi kebutuhan pengguna.
• Performance buruk.
• Reliabilitas rendah.
• Kegunaan rendah.

1.1.6. Beberapa Konsep Sistem Yang Penting


Beberapa konsep yang penting dalam pengembangan sistem, yaitu:
1. Dekomposisi (Pembagian sistem kedalam komponen-komponen yang lebih kecil).
2. Modularitas (Sistem yang besar terbagi menjadi subsistem-subsistem yang relatif
sama ukuranya, dengan modul-modul ini maka beban kerja mengembangkan sistem
bisa didistribusikan secara merata).
3. Coupling (Modul-modul yang saling bergantung harus dipasangkan (di-couple))
4. Kohesi (Kelompok modul harus dianalisis besama-sama dengan kelompok modul
yang saling berkohesi)

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. Tahapan-
tahapan pekerjaan dalam pelaksanaan tidak harus kaku namun dapat disesuaikan dengan
kebutuhan.

1.3.2.1.Tahapan Utama Pengembangan SISFO


Tahapan pengembahan sistem informasi yang umum ada 6 tahapan yaitu:
• Survei, bertujuan untuk mengetahui ruang lingkup pekerjaan.
• Analisis, bertujuan untuk memahami sistem yang ada, mengidentifikasi masalah
dan mencari solusinya.
• Desain, bertujuan mendesain sistem baru yang dapat menyelesaikan masalah-
masalah yang dihapdai perusahaan.
• Coding (program), membuat sistem baru / membuat program sistem yang akan
dikemabangkan.
• Impelementasi, bertujuan untuk mengimplementasikan istsem yang baru.
• Pemeliharaan, bertujuan agar sistem dapat berjalan secara optimal.

1.3.2.2.Penerapan Tahapan Pengembangan SISFO


Beberapa cara dapat ditempuh dalam penerapan tahapan pengembangan sistem informasi,
yaitu secara berurutan (waterfall model), iterasi dan spiral.

Waterfal, Setipa tahapan harus diselesaikan terlebih dahulu secara penuh sebelum
meneruskan ke tahapan berikutnya, dengan tujuan menghindari terjadinya pengulangan
tahapan tersebut. Proses ini lebih cocok untuk diterapkan dalam pengembangan “mass
product”.

Gambar 1.12 Tahapan Waterfal Model

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 mendeteksi dan


memperbaiki kesalahan serta kecurangan yang akan terjadi.

5. Efisien, Peningkatan pengunaan sumber daya secara optimal.

6. Pelayanan, Peningkatan terhadap pelayanan yang diberikan oleh sistem.

17
1.6. LATIHAN
1. Pandanglah universitas anda sebagai suatu sistem. Identifikasi komponen-
komponen apa saja yang menyusun sistem tersebut dan jelaskan peranan-peranan
masing-masing komponen tersebut. Bagaimana masing-masing komponen tersebut
bekerja untuk mendukung tujuan utama organisasi.

2. Pandanglah siklus kegiatan yang ada dalam perpustakaan universitas anda,


kemudian identifikasi komponen apa saja yang terlibat dalam sistem perpustakaan
anda, jelaskan peranan masing-masing penyusun sistem perpustakaan di universitas
anda dalam mendukung tujuan utam organisasi.

Dalam sistem yang lebih besar di lingkungan universitas anda, sistem perpustakaan
apakah merupakan suatu sistem utama atau merupakan sebuah sub sistem dalam
lingkungan universias, berikan pendapat anda.

Bila diperpustakaan universitas anda akan dilakukan komputerisasi, berikan


gambaran sistem yang akan ada rancang.

18
KERTAS KERJA (1)

19
BAB 2

ALAT
PEMODELAN SISTEM

Setelah memperlajari BAB 2 ini diharapkan mahasiswa mengetahui dengan


baik alat-
alat-alat bentu perancangan sistem yang dapat digunakan untuk
memodelkan
memodelkan sistem informasi, baik menggunakan pemodelan trandisonalm
struktur maupun pemodelan berbasis objek.
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.
• Memenuhi persyaratan minimal redudancy.
• Dapat merepresentasikan tingkah laku sistem.

Dari perkembangannya sampai sekarang, metodologi sistem informasi dapat


dikelompokkan menjadi empat ditinjau dari alat untuk membuat model dan paradigma.
Sedangkan tahapan pengembangan sistem informasi (waterfall, iterasi, spiral) pada
prinsipnya tidak mengalami perubahan yang mendasar, yang berbeda hanya pada sistem
konvensional, mensyaratakan setiap tahapan harus diselesaikan secara tuntas sebelum
memasuki tahapan selanjutnya. Sedangkan konsep baru lebih menekankan adanya iterasi
atau pelaksanaan secara spiral.

Keempat metodologi yang disebutkan diatas terdiri dari:


1. Metodologi berorientasi keluaran (output).

2. Metodologi berorientasi proses (process).


- Data Flow Diagram (DFD) / Diagram Aliran Data.
- Data Dictionary (DD) / Kamus Data.
- Process Specification (PS) / Proses Spesifikasi.
- State-Trasition Diagram (STD).
- Block Chart Diagram (BCD).
- System Procedure Diagram (SPD).

3. Metodologi berorientasi data


- Entity Relationship Diagram (ERD) / Hubungan Entiti.

4. Object Oriented / Metodologi Berorientasi Objek.

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. Langkah-
langkah yang harus ditempuh adalah sebagai berikut:
• Identifikasi data yang berikaitan dengan sistem.
• Identifikasi sumber data.
• Buat diagarm konteks.
• Turunkan diagram konteks menjadi DFD level 0.
• Bila dirasa perlu turunkan DFD level 0 menjadi DFD level berikutnya.

2.3.2. DATA DICTIONARY (DD)


Kamus data (data dictonary) tidak menggunakan notasi grafis sebagaimana halnya DFD.
DD berfungsi membatu pelaku sistem untuk mengerti aplikasi secara detail. DD
mereorganisasi semua elemen data yang digunakan dalam sistem dengan presisi yang
sedemikian rupa sehingga pemakai dan penganalisa sistem punya dasar pengertian yang
sama tentang masukan, keluaran, penyimpanan dan proses. DD mendefinisikan elemen data
dengan fungsi sebagai berikut:
• Mejelaskan arti aliran data dan penyimpanan dalam DFD.
• Mendeskripsikan komposisi paket data yang bergerak melalui aliran (misalnya
alamat diuraikan menjadi kota, negara dan kode pos).
• Mendeskripsikan komposisi penyimpanan data.
• Menspesifikasikan nilai dan satuan yang relevan bagi penyimpanan dan aliran.
• Mendeskripsikan hubungan detail antar penyimpanan (yang akan menjadi titik
perhatian dalam entity-relationship diagram).

Notasi struktur data digunakan untuk membuat spesifikasi elemen data. Notasi yang
digunakan dalam DD adalah:
No Notasi Keterangan
1 = Terdiri dari
2 + And (dan)
3 () Pilihan (boleh ada atu tidak)
4 {} Iterasi / pengulangan
5 [] Pilih salah satu pilihan
6 | Pemisah pilihan didalam tanda []
7 * Keterangan / catatan
8 @ Penunjuk (key field)

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 = **
*satuan : sentimeter; rentang 1-200*
Berat_sekarang = **
*satuan : kilogram; entang 1-300*

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

Jenis_kelamin = **
*nilai : [P | W]*

DD dibuat oleh penganalisa sistem selama pengembangan model sistem, tetapi sebaliknya
pemakai harus punya kemampuan membaca dan mengerti DD untuk mengecek model (agar
sinkron dengan kebutuhan pemakai). Umumnya pemakai dikondisikan untuk mengerti
notasi DD, memverifikasi DD (kelengkapan dan kebenarannya), dan terlibat secara tak

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 1 2 Form kas


masuk Kas Masuk Data Kas Keluar keluar
kas Data
masuk kas
keluar
Pihak Luar Bagian

Kas dan BANK


BANK BANK

Data
Data bank
Form bank 3 bank keluar 4 Form bank
masuk BANK Masuk masuk BANK Keluar keluar

Data kas & bank

5 Lap. kas
Direksi
Pelaporan bank

Gambar 2.8 DFD penerimaan dan pengeluaran Kas dan Bank

Dengan pengalamannya yang cukup luas ditambah intuisinya yang tajam, Pak Cerdas
berhasil mendefinsikan formulir-formulir untuk empat proses diatas, yaitu Formulir Kas
Masuk, Formulir Kas Keluar, Formulir Bank Masuk, serta Formulir Bank Keluar.

Nomor Formulir :
Tanggal :
Nomor Cek / Giro :
Penyetor :
Alamat :
No. Uraian Penerimaan Kas Jumlah

Jumlah : ...................................
Gambar 2.9 Formulir kas masuk

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.

Form Kas Masuk = *Data Formulir Penerimaan Kas*


Nomor Formulir + Tanggal + NomorCek + Penyetor + Alamat +
Tabel Penerima Kas
Nomor Formulir = 1 {karakter}10
Tanggal = *Tanggal*
Nomor Cek = 1 {Karakter} 10
Penyetor = 1 {Karakter} 10
Alamat = 1 {Karakter} 30
Tabel Penerimaan Kas= Nomor Urut + {Uraian penerimaan Kas } + Jumlah
Uraian Penerimaan Kas = Kode Penerimaan Kas + Penerimaan kas
Kode Penerimaan kas = 1 {Karakter } 3
Penerimaan kas = 1 {Karakter } 30
Nomor Urut = Angka
Karakter = {A-Z|a-z|0-9|-| |}
Angka = *Numerik*

Untuk (b.) s/d (d.) dapat dicoba sebagai latihan.

Selanjutnya akan kita coba menurunkan DD dari data store Kas dan Bank. Dari DFD diatas
kita bisa melihat bahwa ada yang dikrim ke data store Kas dan Bank bisa berupa data Form
Kas Masuk, Form Kas Keluar, Form Bank Masuk, atau Form Bank Keluar.

Kas dan Bank = [Form Kas Masuk | Form Kas Keluar | Form Bank Masuk |
Form Bank Keluar]

Untuk item (.f) dapat dicoba sebagai latihan. Sebagai petunjuk, gunakan intuisi dan logika
anda untuk mencoba menyusun beberapa alternatif laporan dari data yang tersedia. Bila
anda kesulitan untuk langsung membuat DD-nya buatlah formulirnya terlebih dahulu.

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. Masakan-
maskan istimewa itu adalah:
Kue apel, kue yang dulu membuat pak Lezat jatuh hati pada ibu Nikmat, Ikan mas bakar,
Ayam bakar, Sayur asem, serta buah-buahan yang disajikan secara menarik. Untuk
melengkapi hidangan pesta, ibu Lezat membeli kue-kue ditoko roti langganan ibu Lezat.

Ibu Lezat berbelanja bahan-bahan makanan di beberapa tempat, yaitu pasar, untuk bahan
makanan segar, supermarket, untuk bahan makanan yang diawetkan, termasuk tepung, gula
pasir dan telur ayam, serta toko roti langganan untuk kue-kue pelangkap pesta.

Sebagai catatan tambahan, ibu lezat benar-benar ingin agar pesta yang dia selenggarakan
benar-benar sempurna. Dia ingin agar bahan makanan yang digunakan untuk hidangan
benar-benar bermutu tinggi tetapi tidak memiliki waktu untuk pergi sendiri berbelanja.
Oleh karena itu, semua bearang belanjaan yang dibeli dia seleksi kembali.

45
Pase
Bahan baku kue
2
Bahan makana
Kue-kue Menyajikan
dari pasar
Kue-kue kue-kue
1
Toko Roti
Seleksi &
Kue-kue penyimpanan Ayam
bahan
Bahan makanan makanan 3
dari supermarket Ikan & ayam Pembuatan
ayam bakar
Supermarket
Bahan baku Ayam
Buah-buahan Sayuran Ikan

Tepung, gula,
Buah-buahan Sayur-sayuran
dll
4 Kue-kue
ikan Pembuatan
Bahan baku Bahan baku Bahan sayur Ayam
Apel ikan mas bakar
bakar

7 6 5 Ikan
Menyajikan Pembuatan Pembuatan bakar
buah-buahan kue apel sayur asem

Sayur-sayuran Tamu
Kue apel
Buah-buahan 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
Ikan & ayam Pembuatan
ayam bakar
Ayam

Siapkan alat masak


Siapkan ayam
DO WHILE masih ada ayam
Ayam dibersihkan
Ayam dibakar
ENDDO

Untuk bubble yang lain (4, 5, 6, 7) silahkan dicoba sebagai latihan

LATIHAN ANALISA KASUS PS


Buatlah PS dari latihan DFD tentang sistem rumah sakit. Selamat mengerjakan.

KERTAS KERJA (4)

48
49
50
2.3.4. STATE TRANSITION DIAGRAM (STD)
Diakhir tahun 1980 sistem yang memodelkan tingkah laku ketergantungan pada watu (time-
dependent behaviour) menjadi hal penting. Hal ini umumnya diterapkan pada katagori
khusus yang kita sebut dengan real-timem system. Umumnya sistem seperti ini pasif
dengan kata lain tidak digunakan untuk mengontrol segala sesuatu dengan aktif, tetapi lebih
ditik beratkan pada reaksinya terhadap lingkungan dalam bentuk kemampuan untuk
menangkap data (data cepture). Sistem real time yang lain kadang lebih aktif, misalnya
pada sistem yang berfungsi untuk melakukan pengawasan pemeliharaan pada sejumlah
aspek lingkungan sistem, misalnya pada sistem kontrol proses.

Untuk lebih jelasnya kita dapat membanyangkan suatu sistem yang bekerja dengan data
(dari sumber diluar sistem), yang harus menyediakan respon dan keluaran berkecepatan
tinggi dan dapat digunakan kembali oleh lingkungan diluar sistem pada waktu yang relatif
sama. Tentu saja bagi sistem seperti ini bagian terpenting adalah deskripsi tentang apa dan
kapan terjadinya sesuatu.
bagi sistem yang berorientasi ke bisnis, aspek real-time tidak terlalu penting. Masukkan
dapat muncul dalam sistem dari berbagai sumber dengan kecepatan relatif tinggi, tetapi
tidak selalu langsung diproses karena jika sistem sedang sibuk melakukan sesuatu yang lain
akan terjadi tenggang waktu. Sebagai contoh seistem penggajian tidak harus khawatir
dengan interupsi dan sinyal dari unit dari waktu dalam sistem seperti ini adalah spesifikasi
dan karakteristik repson sistem tersebut terhadap waktu.

Bagaimanapun juga akan sering dihadapkan untuk kondisi dimana kita harus mencoba
melalui untuk mengamati sistem besar dan komplek yang mempunyai aspek
ketergantungan pada waktu. Jika berinteraksi dengan masukkan dari ribuan terminal,
sebagaimana masukkan berkecepatan tinggi dari komputer lain atau fasilitas kombinasi
satelit, maka mungkin terdapat jenis ketergantungan terhadap waktu yang sama
sebagaimana yang diterapkan dalam real-time system klasik. Jika penganalias sistem punya
maslah dengan waktu maka harus dilakukan pendekatan melalui model ini dan sebaiknya
diterapkan dengan familier.

STD dibawah ini berfungsi untuk menunjukkan model tingkah laku dari mesin penjawab
telepon. Komponen utama diagram adalah keadaan (state) dan panah (row) yang
mempresentasikan perubahan keadaan. Ada banyak notasi alternatif dalam STD misalnya
penggunaan elips sebagai penggani keadaan.

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
Reset
“Masukkan kartu”

Tunggu Kartu
Reset or
Kartu dimasukkan Password salah
“Masukkan password”
Bersihkan layar
Tunggu
Password

Password dimasukkan Reset


“Pilih fungsi” Bersihkan layar

Tunggu
Jawaban
Ambil Uang

Tunggu Tunggu Deposit


Transfer Dana
Uang Neraca Uang

Gambar 2.20 STD Automatic Teller Machine (ATM) level 1

Gambar 2.21 Penurunan “Ambil uang”

Ketika kita mencoba membuat STD maka kita dapat melaluinya dengan dua pendekatan
yaitu:

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


Mata Mahasiswa Konstanta
kuliah

Transkip

Nilai Praktek

Key Penghitungan Transkirp


In

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

Catatan
Data pasien 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

Catatan
Pencatatan hasil
kesehatan
diagnosa
pasien

60
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
resep
diagnosa

7. Pencatatan daftar biaya


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

61
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 proses manual seperti


pencampuran, pencetakkan dll.

Dokumentasi, mendefinisikan penyimpanan arsip seandainya


suatu saat diperlukan sebagai back-up. Pembuatan laporan
gabungan, bahan audit dll.

Prosedur yang tidak didefinisikan, mendefinisikan prosedur


lain yang tidak termasuk sebagai bagian dari sistem prosedur
yang dibuat.

Master, mendefinisikan penyimpanan (storage) bagi semua


data transaksi ataupun data-data lain.

Proses berbasis komputer, mendefinisikan proses yang


dilakukan dengan komputer seperti penjurnalan, perhitungan
dll.

Kondisi, mendefinisikan alternatif setelah kondisi tertentu.

File, mendefnisikan penyimpanan (umumnya bukan master)


yang berupa file referensi, trasaksi ataupun temporer.

Display, mendefinisikan keluaran dalam bentuk layar


(screen).

65
Konektor 1; mendefinisikan hubungan dengan halaman
berikutnya yang dalam hal ini dapat berarti dari halaman x
atau ke halaman x.

Konektor 2; mendefinisikan hubungan dengan bagian lain


dalam satu halaman.

Gambar 2.24 Simbol-simbol sistem prosedur

Contoh SP sistem akademik


Pengajar Asisten Bagian Akademik Mahasiswa

Nilai Teori Nilai Praktek Transkrip


Pengumpulan Nilai
Nilai

Key
in

Penghitungan Transkrip
Nilai

Transkrip
Nilai

Mahasiswa

Gambar 2.25 Sistem prosedur akademik

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

Langkah-langkah yang patut untuk diterapkan adalah sebagai berikut:


• Tentukan dokumen apa saja yang terlibat.
• Siapa yang membuatnya.
• Diberikan kepada siapa.
• Selanjutnya tentukan proses apa saja yang dialami dokumen tersebut.
• Siapa yang melakukan.
• Setelah diproses (mungkin menjadi dokumen baru), dokumen tersebut diberikan
kepada siapa, dll.

Sebagai contoh akan kita coba membuat prosedur mengenai masalah yang telah kita bahas
pada latihan-latihan sebelumnya yaitu mengenai pelayanan pasien rumah sakit. Dalam
sistem tersebut terdapat beberapa dokumen, yaitu:
• Data induk pasien.
• Formulir hasil diagnosa.
• Daftar biaya pasien.
• Laporan keuangan.
• Laporan pemakaian obat.
• Resep.
• Catatan kesehatan pasien.

Dari dokumen-dokumen tersebut, kita coba membuat narasi mengenai aliran dokumen-
dokumen tersebut.
• Pertama kali, pasien yang belum terdaftar akan mengisi form data pribadi pasien.
Data pribadi ini akan disimpan dalam suatu tempat penyimpanan.
• Untuk pasien yang sudah terdaftar, maka data tentang riwayat kesehatan pasien
akan dicetak untuk digunakan oleh dokter sebagai masukkan pada saat melakukan
diagnosa.
• Setelah dokter melakukan diagnosa, maka dokter akan mengisi form hasil diagnosa
yang oleh bagian administrasi RS akan dimasukkan ke tempat penyimpanan sebagai
catatan kesehatan pasien. Dokter juga menulis resep untuk pasien yang
bersangkutan.
• Resep hasil diagnosa selanjutnya akan digunakan sebagai bahan untuk membuat
daftar biaya pasien.
• Selain itu juga berdasarkan hasil diagnosa dan resep, administrasi RS membuat
laporan keuangan dan laporan pemakian obat, yang diberikan kepada direktur RS.

Selanjutnya dari narasi yang telah kita buat, kita harus menggambarkannya sebagai sebuah
sistem prosedur, sbb:

67
Pasien Administrasi Rumah Saikit Dokter Direktur Rumah Sakit

Data pasien Pencetatan data


pasien

Laporan
Diagnosa keuangan

Biaya pasien

Laporan
Laporan
pemakian
keuangan
obat
Pencatatan
riwayat Laporan
kesehatan pemakian obat
pasien

Riwayat
kesehatan
pasien

Penghitungan Pembuatan
biaya pasien laporan

Laporan
Laporan
Biaya pasien pemakian
keuangan
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 N Mata Kuliah

Nim_Mhs Kode_MataK
Kode_MataK
Nama
Nim_Mhs
Nama_M_K
Nilai_Ujian

Gambar 2.30 Entiti, atribut dan hubungan

71
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 Ibu Bapak

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 1 Berisi 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.

Beranggota
Grup M kan 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.

Sekamar
Penghuni dengan

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.

Melakukan
Pelanggan 1 N Transaksi

Gambar 2.36 Entiti lemah

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

Bentuk normal kesatu


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

80
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 Nomor Keterangan Nomor Nama Jumlah Jumlah


Bukti Perkiraan Perkiraan Debet Kredit
01/01/97 K001 Penerimaan 100.000 Kas 350.000
01/01/97 K001 Penerimaan 800.000 Penjualan 350.000
02/02/97 B002 Pembelian 120.000 Persediaan 400.000
02/02/97 B002 Pembelian 100.000 Kas 250.000
02/02/97 B002 Pembelian 108.000 Piutang 150.000
Gambar 2.41 Bentuk normal ke dua

Bentuk normal ketiga


Hilangkan data yang berulang-ulang kecuali foreign key. Dalam hal ini tanggal dan
keterangan merupakan data yang disimpan berulang-ulang, shingga dapat dihilangkan
dengan membagi tabel tersebut ke dalam dua tabel, yaitu tabel tblJurnal (Header) dan tabel
tblJurnalID (Detail), dimana tblJurnal terdiri dari field tanggal, nomor bukti dan
keterangan, dan tblJurnalID terdiri dari field nomor bukti, nomor perkiraan, jumlah debet
dan jumlah kredit.

81
TblJurnalHeader
Tanggal Nomor Keterangan
Bukti
01/01/91 K001 Penerimaan
02/02/97 B002 Pembelian

TblMater Perkiraan
Nomor Nama
Perkiraan Perkiraan
100.000 Kas
108.000 Piutang
120.000 Persediaan
800.000 Penjualan

TblJurnalDetail
Nomor Nomor Jumlah Jumlah
Bukti Perkiraan Debet Kredit
K001 100.000 350.000
K001 800.000 350.000
B002 120.000 400.000
B002 100.000 250.000
B002 108.000 150.000
Gambar 2.42 Bentuk normal ke tiga

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

Gambar 2.43 Diagram ER (Entity Relationship) hotel

82
ER juga dapat dimodelkan seperti gambar berikut ini.

Gambar 2.44 Diagram ER (Entity Relationship) hotel

LATIHAN ANALISA KASUS ERD


1. Buatlah ERD sistem rumah sakit yang dibahas pada pemodelan sistem DFD.
2. Buatlah ERD sistem perpustakaan pada umiversitas anda.

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 diagram-
diagram baru yang masing-masing mempunyai kelebihan dan kekurangannya.

Sebagai gambaran notasi yang umum digunakan dalam pemodelan objek dari
Coad/Yourdon, firesmith, Rumbaugh, dan Booch. Walaupun banyak notasi yang
diperkenalkn namun satu hal yang pasti dalam metodologi ini adalah menggunakan satu
diagram mulai dari analisa sampai desain aplikasi.

Class 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 / subsistem-
subsistem.

87
4. Attributes, data / keterangan yang menjelaskan objek ditambhakan untuk setiap
objek.
5. Services, method ditambahkan untuk menjelaskan proses / kegiatan yang akan
dikerjakan oleh setiap objek bila menerima suatu messages (event).
6. Design, tahap desain melengkapi semua kegiatan yang dilakaukan seperti
pembuatan interface dan sebagainya.

2.5.4. Perbandingan Metodologi Objek dan Non Objek


Selanjutnya pengelompokan metodologi dibagi dua untuk lebih mempermudah penjelasan
yaitu metodologi objek dan non objek (keluaran, proses dan data).
• Metodologi non objek menggunakan beberapa alat untuk menggambarkan model
seperti DD, DFD, dan diagram terstruktur. Sedangkan metodologi objek hanya
menggunakan satu jenis model yang disempurnakan mulai dari analisa sampai
pembuatan sistem.

• Pada metodologi non objek, data dan proses dianggap dua komponen yang
berlainan, sedangkan metodologi objek data dan proses merupakan bagian dari
objek.

• Metodologi non objek ditunjukkan untuk melangkapi pemrograman terstruktur,


bahasa generasi ke tiga sedangkan metodologi objek ditujukan untuk pemrograman
berorientasi objek dan bahasa generasi ke empat.

88
BAB 3

MENYEIMBANGKAN
MODEL

Setelah memperlajari BAB 3 ini diharapkan mahasiswa memahami


memahami dengan
baik penyeimbangan model dalam merancang sistem.
sistem.
Materi yang dibahas dalam bab 3 ini meliputi
- DFD vs DD
- DFD vs PS
- PS vs DFD
- DD vs DFD vs PS
- ERD vs DFD PS
- DFD vs STD

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 bersama-
sama, untuk itulah bahasan ini diperlukan. Situasi ini mirip dengan tentang tiga orang buta
(dan bijaksana) di India yang mencoba mendifinisikan sesuatu yang disebut gajah. Orang
buta pertama menyentuh ujung yang tajam dari gading dan dia berkata saya tahu bahwa
mahluk ini sama dengan banteng...!, saya dapat merasakan kerasnya...! sementara orang
buta kedua menyentuh bulu-bulu kasar pada badan gajah dan tanpa banyak berpikir berkata
saya tahu ini apa,... ini adalah landak ya.... tentu saja landak yang sangat besar...!, dan
orang buta ketiga yang memegang kaki gajah yang besar dan tebal berkata tentu saja ini
adalah pohon tempat kita bertiga berteduh...!, Jika seluruh data pengamatan tesebut
digabung maka melalui analisa akan diketahui definisi gajah secara lengkap (dalam hal ini,
tentu saja kita harapakan ketiga orang buta tersebut melakukan konfirmasi satu sama lain).

Seperti ketiga model yang mengatakan tiga aspek berbeda dari sistem (fungsi dan waktu),
maka model DD, PS, BC dan SP memetakan karakteristik pendukung detail. Dalam kasus
tertentu penggunaan model-model tersebut dapat mengakibatkan interpretasi yang tidak
konsisten dari situasi yang sebenarnya. Hal ini terjadi jika sistem yang dikerjakan sangat
besar dimana terlibat personil dan kelompok personil yang mempunyai fokus perhatian
yang berbeda. Selain itu latar belakang profesi yang berbeda (dari anggota tim) juga akan
menyebabkan hal yang sama.

Ada alasan lain yang menegaskan kenapa model harus konsisten yaitu bertambah sulit dan
mahalnya penyelesaian masalah jika kesalahan tersebut baru ditemukan pada akhir proses.
Kesalahan akibat tidak kekonsistenan tersebut akan menyebar dan membesar pada proses
desain dan implementasi (martin dalam bukunya mencatat 50% porsi kesalahan yang
dideteksi dalam sistem diakibatkan oleh kesalahan pada tahap analisa dan menghabiskan
75% dari biaya perbaikan keseluruhan secara umum). Pada penelitian lain disimpulkan
koreksi kesalahan pada proses analisa akan sepuluh kali lebih murah daripada koreksi
kesalahan tersebut pada proses desain.

Kesalahan tersebut dapat berupa kesalahan menggambarkan model atau


menginterpretasikan secara salah keinginan pemakai, kesalahan sulit yang lain adalah
hubungan antar model (yang biasanya tersembunyi) yaitu tidak konsistennya hubungan

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

Rekapitulasi Presentasi
Form
Absensi Absensi Skripsi
Skripsi

Berita
Rekapitula
Acara
si Absensi
Nilai Presentasi
Nilai Teori
Praktek

Penentuan Penentuan Pendaftaran


Nilai Akhir Nilai Akhir Skripsi
Teori Praktek

Nilai Akhir Nilai Akhir Form


Teori Praktek Skripsi

Penentuan
Penentuan
Nilai Akhir
Transkrip
Teori

Nilai
Transkrip Transkrip
Indeks

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
Dosen
Akademik / BAAK
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
6
1 Pencatatan
Pencatatan
Pencatatan berita acara
data skripsi
dan absensi presentasi

Data absensi Data skrispi Data skripsi


3
Absensi Penghitungan
Berita acara
nilai akhir Data skripsi
presentasi
Data rekap absen
Data Rekap absen
Data nilai
2 Data 7
Pembuatan Pembuatan Data skripsi
Data presentasi
rekap absensirekapitulasi Nilai akhir transkrip
absensi
Data
berita
Data nilai indek acara Dat anilai indeks
Rekap absen presentasi

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 Nilai Teori Nilia Praktek
1 2 3 4 1 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 Nilai

Skrispis :
Judul :
Nilai :
Transkrip = @NIM+Nama_Mahasiswa + {Nilai_Matakuliah} + Judul_Skripsi + Nilai

101
Tanggal := *Tgl-Bulan-Tahun*
Jam := *99:99*
Angkatan := Kode_Angkatan + Ket_Angakatan
Kode_Angkatan := 1{Karakter}2
Ket_Angakatan := 1{Karakter}30
Mata_Kuliah := Kode_Mata_Kuliah + Ket_Mata_Kuliah
Kode_Mata_Kuliah := 1{Karakter}2
Ket_Mata_Kuliah := 1{Karakter}30
NIM := 1{Karakter}8
Nama_Mahasiswa := 1{Karakter}30
Kehadiran := [“Ya” | “Tidak”]
Jumlah_Absensi := 1{Angka}3
NT1 := 1{Angka}3
NT2 := 1{Angka}3
NT3 := 1{Angka}3
NT4 := 1{Angka}3
NP1 := 1{Angka}3
NP2 := 1{Angka}3
NP3 := 1{Angka}3
NP4 := 1{Angka}3
NTA := 1{Angka}3
NPA := 1{Angka}3
Indeks := [“A” | “B” |“C” |“D” |“E” ]
Kd_Skripsi := 1{karakter}3
Mahasiswa_skripsi := NIM
Judul_Skripsi := 1{Karaker}30
Tempat_skripsi := 1{Karakter}30
Pembimbing := Dosen
Dosen := Kode_Dosen + Nama_Dosen
Kode_Dosen := 1{Karaker}3
Nama_Dosen := 1{Karakter}30
Nilai_Skripsi := Indeks
Penguji := Dosen
Nilai_Mata_Kuliah := Indeks
Angka := [0-9 | . | ,]
Karakter := [A-Z | a – z | ‘ | | ]

4. Entity Relationship Diagram


Setelah kita buat DD, kita akan lanjutkan perancangan kita dengan membuat ERD. Objek-
objek yang potensial untuk menjadi entitas adalah:
• Mahasiswa
• Angkatan
• MataKuliah
• Skripsi

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
Rumus akhir

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 Administrasi Akademik Asisten Mahasiswa Penguji Skripsi

Form

Abse
Absensi Pencatatan Data

nsi
Absensi Skripsi
Absensi Presentasi
Skripsi

Rekapitulasi Nilai
Berita
Absensi Praktek
Acara
Presentasi
Nilai

Nilai Teori

Rekapitulasi
Absensi
Pemasukan Nilai
Teori Pengisian Data
Skripsi
Rekapitulasi
Absensi

Penentuan Nilai
Skrip
Data

si

Akhir Teori

Pencatatan Berita
Penentuan Nilai Acara Presentasi
Indeks
Prese
ntasi

Pembuatan
B. A

Transkrip

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 4 ini diharapkan mahasiswa memahami dengan


baik tahapan yang dilalui
dilalui dalam pengembangan sistem informasi, 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 Rp. .........
- Biaya penyusunan sistem Rp. .........
-------------
Efisiensi perbulan Rp. ........

111
Dari segi operasional
Laporan keuangan lebih cepat
Mengatasi masalah yang ada sepeti kesalahan posting, dan sebagainya.

Metodologi
Bagian ini menjelaskan metode, alat dan teknis yang digunakan untuk
pengembangan sistem.

Lampiran
Pada bagian ini diberikan referensi keahlian yang dimiliki konsultan, nama aplikasi
/ perusahaan yang pernah ditangani dan sebagainya.

4.3. ANALISA SISTEM


Setelah proposal disetujui untuk dilaksanakan, maka bagian EDP / konsultan dapat menilai
pekerjaan tahapan berikutnya yaitu analisa sistem.

Anaisa sistem dapat diartikan sebagai suatu proses untuk memahami sistem yang ada
dengan menganalisa jabatan dan uraian tugas (business users), proses bisnis (business
process), ketentuan / aturan yang ada (business rules), masalah dan mencari solusinya
(business problems & solution), business tools dan rencana-rencana perusahaan (business
plans). Tahapan ini sangat kritis karena kesalahan dalam tahap ini akan menyebabkan
kesalahan dalam tahap Desaian Sistem. Oleh sebab itu faktor-faktor seperti ketelitian,
metode pengumpulan data dan keahlian seorang analis sangat menentukan.

4.3.1. Business Users


Business user merupakan personel yang menjalankan suatu bisnis, yang dapat dimulai dari
staff, kasi, kabag / manajer sampai diraktur.

4.3.2. Analisa jabatan


Tujuan dari analisa jabatan adalah untuk mempelajari jabatan-jabatan yang berkaitan
dengan sistem yang akan dikembangkan.

4.3.3. Business Process


Buseiness process menggambarkan rangkian tugas yang harus diselesaikan menurut aturan-
auran tertentu untuk mendapatkan suatu hasil.

4.3.4. Business Ruless


Untuk menjamin agar sebuah sistem dapat berjalan seperti yang diharapkan, perusahaan
perlu menerapkan ketentuan / batasan yang dapat menjaga integritas / keabsahan data,
jangan sampai merusak sistem yang ada atau merugikan perusahaan / organisasi. Ketentuan
/ batasan ini dikenal dengan istilah Business Ruless.

4.3.5. Business Problems & Solusi


Analisa yang dilaksanakan dalam tahap ini dapat dibagi atas tiga tiga kelompok yaitu
identifikasi masalah, identifikasi penyebab masalah dan penyelesaian masalah.

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 kadang-
kadang bisa berakibat fatal terhadap sistem, sehingga harus diantisipasi sedini mungkin,
oleh karena itu proses ini termasuk dalam tahapan pemeliharaan.
Contoh:
- Melinium bug dimana data jenis tahun untuk aplikasi tertentu yang disimpan dalam
bentuk dua digit, akan menimbulkan gangguan pada tahun 2000.

4.7.3. Penyempurnaan (Upgrading)


Sutu sistem setelah berjalan beberapa waktu biasanya membutuhkan penyesuaian karena
berbagai alasan, seperti perkembangan bisnis, perubahan organisasi, perubahan kebijakan
manajemen, dan sebagainya.

4.7.4. Antisipasi Faktor-faktor di Luar Sistem


Seperti telah disebutkan, walalupun suatu sistem telah dapat berfungsi sebagaimana
diharapkan, kita masih harus mengantisipasi terhadap:
- Virus.
- Kerusakan / kehilangan data.
- Sistem diakses oleh user yang tidak berhak.

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 temuan-
temuan yang baru, untuk pengembangan dimasa yang akan datang)

Daftar Pustaka
Berisi daftar buku-buku yang digunakan sebagai reverensi baik dari buku maupun dari
internet.

117
BAB 5

TEKNIK YANG DIGUNAKAN


DALAM PENGEMBANGAN SISFO

Setelah memperlajari BAB 5 ini diharapkan mahasiswa memahami dengan


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 pertanyaan-
pertanyaan kepada user untuk menjawab secara tertulis dan dikembalikan kepada sistem
analis. Beberapa kebaikan dari daftar pertanyaan adalah:
• Dapat menjangkau responden / user yang banyak pada saat yang sama.
• Tidak mengganggu aktivitas pekerjaan.
• Pelaksanaan lebih sederhana.

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 6 ini diharapkan mahasiswa memahami dengan


baik teknik yang digunakan dalam rekayasa 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
Kuliah Umum IlmuKomputer.Com
Copyright © 2003 IlmuKomputer.Com

Pengantar Unified Modeling


Language (UML)
Sri Dharwiyanti
dharwiyanti@rnd.inti.co.id
Romi Satria Wahono
romi@romisatriawahono.net
http://romisatriawahono.net

Lisensi Dokumen:
Copyright © 2003 IlmuKomputer.Com Seluruh dokumen di IlmuKomputer.Com dapat digunakan,
dimodifikasi dan disebarkan cara bebas untuk tujuan bukan komersial (nonprofit), dengan syarat tidak
menghapus atau merubah atribut penulis dan pernyataan copyright yang disertakan dalam setiap dokumen.
Tidak diperbolehkan melakukan penulisan ulang, kecuali mendapatkan ijin terlebih dahulu dari
IlmuKomputer.Com.

124