Analisa Dan Perancangan Sistem Informasi

ANALISA DAN PERANCANGAN
SISTEM INFORMASI
NPM : _______________________
NAMA : _______________________
Dosen : Hanafi, M.Kom / M.Ropianto, M.Kom

SATUAN ACARA PERKULIAHAN
MATA KULIAH : ANALISIS & PERANCANGAN SISTEM INFORMASI */**
JURUSAN TEKNIK INFORMATIKA
KODE / SKS : 355KB307 / 3 SKS
Pertemuan Pokok Bahasan Sub Pokok Bahasan dan TIK Teknik Media Tugas Referensi
ke dan TIU Pembelajaran Pembelajaran
1 PENDAHULUAN 1. Ruang Lingkup Mata Kuliah Kuliah mimbar OHT, papan 1, 4, 5, 7,

Mengapa dan Apa Analisis & Perancangan tulis 8
Sistem.
Siapa saja yang terlibat dalam Analisis &
Perancangan Sistem.
2. Sasaran
Mengenal konsep dan dasar dari Analisis &
Perancangan Sistem.
3. Tujuan
Dapat menjelaskan konsep dan dasar dari
Analisis & Perancangan Sistem.
4. Kompetensi Lulusan
Mampu mengimplementasikan Analisis &
Perancangan Sistem.
PENGERTIAN SISTEM 1. Definisi Sistem

DAN ANALISIS SISTEM 2. Karakteristik Sistem
3. Klasifikasi Sistem
4. Pengertian Analisis Sistem
5. Fungsi Analis Sistem
TIU TIK
Memahami konsep sistem Mahasiswa mampu :
informasi, karakteristik, 1. Menjelaskan konsep sistem informasi berikut
klasifikasi dan tim contohnya dan pengertian analis beserta
pengembang sistem. fungsinya.
2. Menjelaskan karakteristik sistem.
3. Menjelaskan sistem berdasarkan klasifikasi
tertentu.
4. Menjelaskan siapa saja yang akan terlibat
SAP-Analisis dan Perancangan Sistem Informasi 1
Revisi : 09-10-2012
dalam pengembangan sistem.
2 dan 3 ANALISIS SISTEM 1. Pendahuluan Kuliah mimbar OHT, papan 1, 4, 5, 7,
2. Langkah-langkah di dalam analisis sistem tulis 9
3. Mengidentifikasi Masalah
4. Memahami Kerja dari sistem
5. Menganalisis Hasil
6. Membuat Laporan hasil analisis
TIU TIK
Memahami konsep, Mahasiswa mampu :
langkah-langkah, cara 1. Menjelaskan konsep analisis sistem
identifikasi masalah, 2. Menjelaskan cara mengidentifikasi masalah,
Kerja dari Sistem, memahami kerja dari sistem, Menganalisis
Menganalisis hasil dan hasil penelitian dan membuat laporan hasil
membuat laporan hasil analisis.
analisis.
4 PERANCANGAN 1. Pendahuluan Kuliah mimbar OHT, papan 1, 2, 4, 5,

SISTEM SECARA UMUM 2. Arti Perancangan Sistem tulis 10
3. Tujuan Perancangan Sistem
4. Personil Yang terlibat
5. Perancangan sistem secara umum
Perancangan Ouput
Perancangan Input
Perancangan Proses
Perancangan Database
Perancangan Kontrol
Perancangan Jaringan
Perancangan Komputer
6. Tekanan-tekanan Perancangan
TIU TIK
Memahami pengertian, Mahasiswa mampu :
tujuan dan tahapan 1. Menjelaskan konsep merancang sistem.
perancangan sistem serta 2. Menjelaskan tujuan, tahapan merancang
personil yang terlibat dan secara umum mulai dari ouput, input, proses,
tekanan-tekanan dalam database, kontrol jaringan sampai arsitektur
merancang sistem. komputer.
3. Menjelaskan tekanan-tekanan dalam
merancang.

Revisi : 09-10-2012
5 dan 6 PENDEKATAN 1. Konsep Perancangan Terstruktur Kuliah mimbar OHT, papan 1, 2, 4, 5,
PERANCANGAN 2. Data Flow Diagram (DFD) tulis 6, 7, 8, 9
TERSTRUKTUR Komponen DFD
Bentuk DFD
2.3 Syarat pembuatan
DATA FLOW DIAGRAM
TIU TIK
Memahami konsep Mahasiswa dapat :
pendekatan perancangan 1. Menjelaskan konsep DFD serta bagaimana
terstruktur dengan salah cara menggunakannya.
satu alat batunya DFD. 2. Menentukan kapan menggunakan secara
Serta dapat tepat berdasarkan kelebihan dan kekurangan
menggunakan DFD DFD.
secara tepat dan benar. 3. Membuat model sistem yang akan mereka
kembangkan dengan DFD.
7 FLOWCHART 1. Pedoman-pedoman dalam membuat Kuliah mimbar OHT, papan 4, 6, 7

Flowchart tulis
2. Jenis-jenis Flowchart
System Flowchart
Document Flowchart
Schematic Flowchart
Program Flowchart
Process Flowchart
TIU TIK
Flowchart dan dapat 1. Menjelaskan konsep dasar flowchart dan
menggunakan Flowchart perbedaan dari tiap jenis flowchart yang ada.
secara tepat dan benar. 2. Menggunakan masing-masing flowchart
sesuai dengan sistem yang sedang mereka
kembangkan.
8 PERANCANGAN 1. Perancangan Output Kuliah mimbar OHT, papan 1, 2, 4, 5,

SISTEM TERINCI 1.1. Macam-macam bentuk laporan tulis 10
(OUTPUT DAN INPUT) 1.2. Pedoman perancangan laporan
1.3. Pengaturan tata Letak isi output
2. Perancangan Input
Revisi : 09-10-2012
Perancangan formulir kertas
Pengelolaan dan perancangan formulir
elektronik
Pengkodean Input
Validasi Input
TIU TIK
perancangan Output dan 1. Menjelaskan konsep perancangan sistem
Input serta dapat terinci dan bagaimana melaksanakan
melakukan perancangan perancangan sistem terinci.
Output. Input dan validasi 2. Melakukan perancangan sistem terinci, mulai
input. dari perancangan output, input, perancangan
dialog terminal sampai perancangan file.
3. Menjelaskan cara untuk melakukan
pengendalian input melalui validasi transaksi,
cek data dan modifikasi data transaksi.
9 dan 10 PERANCANGAN 1. Perancangan Database Kuliah mimbar OHT, papan 1, 2, 3, 4,

SISTEM TERINCI 1.1. Entity Relationship Diagram (ERD) tulis 5, 10
DATABASE 1.2. Normalisasi
2. Hubungan DFD, ERD dan Normalisasi.
TIU TIK
Memahami konsep Mahasiswa mampu :
perancangan proses dan 1. Menjelaskan perbedaan dan hubungan yang
perancangan database. ada antara DFD dan ERD.
Dapat menggunakan 2. Membuat model sistem yang akan mereka
DFD, ERD dan kembangkan dengan ERD dan normalisasi.
Normalisasi serta 3. Membuat perancangan database
keterhubungannya. menggunakan ERD dan normalisasi.
11 PENDEKATAN 1. Pendahuluan. Kuliah mimbar OHT, papan 10, 11, 12

PERANCANGAN 2. Pemodelan Berorientasi Objek. tulis
BERORIENTASI OBJEK 3. Analisis Berorientasi Objek.
4. Desain Berorientasi Objek.
TIU TIK
Memahami konsep Mahasiswa mampu :
perancangan berorientasi 1. Menjelaskan konsep dari pemodelan
Revisi : 09-10-2012
objek serta dapat berorientasi objek.
menerapkannya kedalam 2. Mengenali penggunaan, teknik dan model
bentuk analisis dan berorientasi objek serta pedomannya.
perancangan. 3. Menjelaskan komponen perancangan
berorientasi objek.
12 PERANCANGAN 1. Pengenalan UML. Kuliah mimbar OHT, papan 10, 13

SISTEM BERORIENTASI 2. Sejarah Singkat UML. tulis
OBJEK DENGAN UML 3. Bagian-bagian UML.
(UNIFIED MODELLING View.
LANGUAGE) Diagram.
4. Langkah-langkah Pembvuatan UML.
TIU TIK
Melakukan perancangan Mahasiswa dapat :
sistem berorientasi objek 1. Mengetahui tujuan penggunaan UML.
Menggunakan alat bantu 2. Mengetahui sejarah singkat UML.
UML. 3. Mengenal bagian-bagian (diagram-diagram)
UML.
4. Menggunakan UML untuk membuat model
sederhana.
13 DAN 14 PEMBAHASAN TUGAS Contoh kasus dengan pemecahan masalah yang

PENGGUNAAN tertuang dalam bentuk sebuah paper 3 bab
MODEL/ALAT ANALISIS (Gambaran Sistem, Penggunaan Metode/Alat,
DAN PERANCANGAN Penutup)
SISTEM
TIU TIK
Mampu memilih dan Mahasiswa mampu :
menggunakan 1. Menganalisa dan menyusun pemecahan
Metode/Alat Analisis dan masalah.
Perancangan secara 2. Memilih dan menggunkan Metode/Alat
tepat. Analisis dan Perancangan Sistem secara
benar.
3. Bekerja secara tim dalam menganalisis dan
merancang sebuah sistem.
4. Mempresentasikan sistem yang
dikembangkan.

Revisi : 09-10-2012
Daftar Referensi
[1] Burch, J.G., System, Analysis, Design, and Implementation, Boyd & Fraser Publishing Company, 1992.
[2] D. Suryadi H.S., Bunawan, Pengantar Perancangan Sistem Informasi, Gunadarma, 1996.
[3] Elmasri/Navathe, Fundamentals of Database System, Benjamin/Cummings Publishing Company, Inc, 1989.
[4] Jogiyanto, Analisis dan Disain Sistem Informasi, Andi Offset, Yogyakarta, 1990.
[5] Senn, James A., Analysis and Design of Information Systems, McGraw-Hill Publishing Company, 1989.
[6] Tavri D. Mahyuzir, Analisa Perancangan Sistem Pengolahan Data, PT. Elex Media Komputindo, Jakarta, 1989.
[7] Yourdon, Edward, Modern Structure Analysis, Prentice-Hall, Inc, 1989.
[8] Anonim, Pengantar Analisis dan Perancangan Sistem Terstruktur, Gunadarma, 1995.
[9] Kendall & Kendall, Analisis dan Perancangan Sistem, Edisi Ke 5 – Jilid 1, PT. Prenhallindo, Jakarta, 2003.
[10] Kendall & Kendall, Analisis dan Perancangan Sistem, Edisi Ke 5 – Jilid 2, PT. Indeks, Jakarta, 2003.
[11] Ariesto Hadi Sutopo, Analisis dan Desain Berorientasi Objek, J&J Learning, Yogyakarta, 2002.
[12] Adi Nugroho, Analisis dan Perancangan Sistem Informasi dengan Metodologi Berorientasi Objek, Informatika, Bandung, 2003
[13] A. Suhendar, Hariman Gunadi, Visual Modeling Menggunakan UML dan RATIONAL ROSE, Informatika, Bandung, 2002.
[14] Schmuller, Josep, SAMS Teach Yourself UML ini 24 Hours, Second Edition, Sams Publishing, 2002.

Revisi : 09-10-2012
PENDAHULUAN
Informasi dapat dipandang sebagai suatu sumber daya organisasional.

Karena itu harus dikelola dengan baik sebagaimana sumber daya-sumber
daya lainnya. Ketersediaan daya komputer yang bisa dijangkau untuk
organisasi berarti ledakan informasi, dan konsekuensinya semakin banyak
atensi yang harus diberikan untuk disalin dengan informasi yang
diciptakan.
Semua sistem informasi terkomputerisasi memiliki basis data dasar yang

menyimpan data-data yang diperlukan untuk mendukung fungsi-fungsi
bisnis. Transaction processing systems (TPS) mendukung transaksi-
transaksi bisnis besar dan rutin seperti daftar gaji/upah dan inventaris.
Office Automation Systems (OAS) mendukung data-data pekerja yang
menggunakan word processing, spreadsheet, dll untuk menganalisis,
mentransformasikan, atau memanipulasi data. Knowledge Work Systems
(KWS) mendukung para profesional seperti ilmuwan dan insinyur yang
menciptakan pengetahuan baru.
Sistem Informasi Manajemen (SIM) adalah sistem terkomputerisasi yang

lebih berfungsi mendukung jangkauan yang lebih luas fungsi-fungsi bisnis
dibandingkan melakukan transaction processing systems. Yang paling
sering, output SIM memberi laporan kepada para pembuat keputusan.
Decision Support Systems (DSS) adalah sistem informasi yang outputnya
disesuaikan dengan kebutuhan pengguna mereka dan membantu
mendukung para pembuat keputusan dalam membuat keputusan-
keputusan semi terstruktur. Sistem ahli menangkap keahlian pembuat
keputusan untuk digunakan dalam menyelesaikan masalah.
Penganalisis bisa dipanggil berdasarkan hal itu untuk merancang berbagai

jenis sistem baru, termasuk sistem-sistem rekomendasi, yang
mengkombinasikan intelligent agents, sistem ahli, dan teknologi-teknologi
berbasis Web lainnya yang memungkinkan interactivity dengan filtering
dan polling yang canggih.
Analisis dan Perancangan Sistem Halaman 1 dari 2

Apa Analisis dan Perancangan Sistem ?
Analisis dan perancangan sistem adalah suatu pendekatan yang sistematis

untuk :
- mengidentifikasi masalah, peluang, dan tujuan-tujuan
- menganalisis arus informasi dalam organisasi
- merancang sistem informasi terkomputerisasi untuk menyelesaikan
masalah
Peranan Penganalisis Sistem
Penganalisis sistem secara sistematis menilai bagaimana fungsi bisnis

dengan cara mengamati proses input dan pengolahan data serta proses
output informasi dengan untuk membantu peningkatan proses-proses
organisasional.
Penganalisis harus mampu bekerja dengan orang-orang dari semua

kalangan sekaligus bekerja dengan komputer. Penganalisis memainkan
banyak peran, kadang-kadang menyeimbangkan banyak hal sekaligus
dalam waktu yang sama.
Tiga peran Penganalisis sistem adalah :

1. Konsultan luar untuk bisnis
2. Ahli pendukung di dalam bisnis
3. Agen perubahan baik dalam situasi internal maupun eksternal terhadap
bisnis
Penganalisis memiliki kemampuan yang beragam. Pertama yang paling

menonjol, adalah sebagai pemecah segala masalah, yakni orang yang
menikmati tantangan menganalisis masalah dan merencanakan solusi yang
bisa digunakan. Penganalisis sistem memerlukan keahlian dalam
berkomunikasi dengan berbagai macam orang sekaligus dengan komputer.
Keterlibatan pengguna ujung berpengaruh terhadap keberhasilan mereka.

PENGERTIAN SISTEM DAN ANALISIS SISTEM
1. DEFINISI SISTEM
Sistem adalah sekumpulan unsur / elemen yang saling berkaitan dan

saling mempengaruhi dalam melakukan kegiatan bersama untuk
mencapai suatu tujuan.
Contoh :
§ Sistem Komputer terdiri dari Software, Hardware, dan Brainware
§ Sistem Akuntansi
Menurut LUDWIG VON BARTALANFY

Sistem merupakan seperangkat unsur yang saling terikat dalam suatu
antar relasi diantara unsur-unsur tersebut dengan lingkungan.
Menurut ANATOL RAPOROT

Sistem adalah suatu kumpulan kesatuan dan perangkat hubungan
satu sama lain.
Menurut L. ACKOF
Sistem adalah setiap kesatuan secara konseptual atau fisik yang
terdiri dari bagian-bagian dalam keadaan saling tergantung satu
sama lainnya.
Syarat-syarat sistem :
1. Sistem harus dibentuk untuk menyelesaikan masalah.
2. Elemen sistem harus mempunyai rencana yang ditetapkan.
3. Adanya hubungan diantara elemen sistem.
4. Unsur dasar dari proses (arus informasi, energi dan material) lebih
penting dari pada elemen sistem.
5. Tujuan organisasi lebih penting dari pada tujuan elemen.

Secara garis besar, sistem dapat dibagi 2 :
A. SISTEM FISIK ( PHYSICAL SYSTEM ) :

Kumpulan elemen-elemen/ unsur-unsur yang saling berinteraksi
satu sama lain secara fisik serta dapat diidentifikasikan secara
nyata tujuan-tujuannya.
Contoh :
- Sistem transportasi, elemen : petugas,mesin, organisasi yang
menjalankan transportasi
- Sistem Komputer, elemen : peralatan yang berfungsi bersama-
sama untuk menjalankan pengolahan data.
B. SISTEM ABSTRAK ( ABSTRACT SYSTEM) :

Sistem yang dibentuk akibat terselenggaranya ketergantungan
ide, dan tidak dapat diidentifikasikan secara nyata, tetapi dapat
diuraikan elemen-elemennya.
Contoh :
Sistem Teologi, hubungan antara manusia dengan Tuhan.
§ MODEL UMUM SISTEM
Model sistem sederhana
input proses output
Contoh :
- Program perhitungan basic kita masukkan, setelah dijalankan kita
dapatkan hasilnya.
- Data mahasiswa (nama, nilai) diproses menjadi daftar nilai
semester (berupa laporan).

Sistem dengan banyak input dan output
Input1 Output 1
Input2 PROSES Output 2
…. ……..
Input n Output n
Contoh : Matriks → masukannya banyak, keluarannyapun banyak
2. KARAKTERISTIK SISTEM
a. Organisasi
b. Interaksi
c. Interdependensi
d. Integrasi
e. Tujuan pokok
a. Organisasi
Mencakup struktur dan fungsi organisasi
Contoh :
- Struktur
DIRUT
MRKT PROD ADM SUB SISTEM
BAG.SUBSISTEM
- Fungsi
Organisasi tidak akan berjalan tanpa adanya fungsi dari setiap bagian
maupun sub bagian.

Contoh :
- Fungsi direktur utama.
Bertanggung jawab penuh terhadap mati atau hidupnya perusahaan
yang dipimpinnya.
- Fungsi departemen marketing.

Bertanggung jawab penuh atas kelancaran pembuatan produk
dengan jalan mencari langganan pembeli.
- Fungsi departemen keuangan dan administrasi.

Bertanggung jawab atas kelancaran pengeluaran keuangan
perusahaan.
b. Interaksi.
Saling keterhubungan antara bagian yang satu dengan lainnya.
Contoh :
SA dengan P dengan DE dan sebaliknya.
SA : Sistem Analis, P : Programmer, DE : Data entry.
c. Interdependensi.
Bagian yang satu mempunyai ketergantungan dengan bagian yang
lainnya.
Contoh :
Bagian marketing saling bergantung dengan bagian produksi dan
bagian keuangan dan administrasi dalam hal penagihan pada
customer.
d. Integritas.
Suatu keterpaduan antara subsistem-subsistem untuk mencapai
tujuan.
Contoh :
Bagian marketing mendapat pesanan 100 buah mobil tapi hanya
mampu menyediakan 50 unit. Untuk menangani masalah ini diadakan
kerjasama dengan perusahaan lain yang bergerak dalam bidang yang
sama.

e. Main objection ( tujuan utama ).
Pemusatan tujuan yang sama dari masing-masing subsistem.
Contoh : suatu perusahaan memerlukan pemusatan tujuan.
3. KLASIFIKASI SISTEM
A. DETERMINISTIK SISTEM
Sistem dimana operasi-operasi (input/output) yang terjadi
didalamnya dapat ditentukan/ diketahui dengan pasti.
Contoh :
- Program komputer, melaksanakan secara tepat sesuai dengan
rangkaian instruksinya.
- Sistem penggajian.
B. PROBABILISTIK SISTEM
Sistem yang input dan prosesnya dapat didefinisikan, tetapi output
yang dihasilkan tidak dapat ditentukan dengan pasti; (Selalu ada
sedikit kesalahan/penyimpangan terhadap ramalan jalannya
sistem).
Contoh :
- Sistem penilaian ujian
- Sistem pemasaran.
C. OPEN SISTEM
Sistem yang mengalami pertukaran energi, materi atau informasi
dengan lingkungannya. Sistem ini cenderung memiliki sifat
adaptasi, dapat menyesuaikan diri dengan lingkungannya sehingga
dapat meneruskan eksistensinya.
Contoh :
Sistem keorganisasian memiliki kemampuan adaptasi.(Bisnis dalam
menghadapi persaingan dari pasar yang berubah. Perusahaan yang
tidak dapat menyesuaikan diri akan tersingkir).

D. CLOSED SISTEM
Sistem fisik di mana proses yang terjadi tidak mengalami
pertukaran materi, energi atau informasi dengan lingkungan di luar
sistem tersebut.
Contoh : reaksi kimia dalam tabung berisolasi dan tertutup.
E. RELATIVELY CLOSED SISTEM

Sistem yang tertutup tetapi tidak tertutup sama sekali untuk
menerima pengaruh-pengaruh lain.
Sistem ini dalam operasinya dapat menerima pengaruh dari luar
yang sudah didefinisikan dalam batas-batas tertentu .
Contoh :
Sistem komputer. (Sistem ini hanya menerima masukan yang
telah ditentukan sebelumnya, mengolahnya dan memberikan
keluaran yang juga telah ditentukan sebelumnya. tidak
terpengaruh oleh gejolak di luar sistem).
F. ARTIFICIAL SISTEM
Sistem yang meniru kejadian dalam alam. Sistem ini dibentuk
berdasarkan kejadian di alam di mana manusia tidak mampu
melakukannya. Dengan kata lain tiruan yang ada di alam.
Contoh :
- Sistem AI, yaitu program komputer yang mampu membuat
komputer seolah-olah berpikir.
- Sistem robotika.
- Jaringan neutral network.
G. NATURAL SISTEM
Sistem yang dibentuk dari kejadian dalam alam.
Contoh : laut, pantai, atmosfer, tata surya, dll.
H. MANNED SISTEM
Sistem penjelasan tingkah laku yang meliputi keikutsertaan
manusia.

Sistem ini dapat digambarkan dalam cara-cara sebagai berikut :
H.1. Sistem manusia-manusia.
Sistem yang menitik beratkan hubungan antar manusia.
H.2. Sistem manusia-mesin.
Sistem yang mengikutsertakan mesin untuk suatu tujuan.
H.3. Sistem mesin-mesin.
Sistem yang otomatis dimana manusia mempunyai tugas
untuk memulai dan mengakhiri sistem, sementara itu
manusia dilibatkan juga untuk memonitor sistem.
Mesin berinteraksi dengan mesin untuk melakukan beberapa
aktifitas. Pengotomatisan ini menjadikan bertambah
pentingnya konsep organisasi, dimana manusia dibebaskan
dari tugas-tugas rutin atau tugas-tugas fisik yang berat.
Perancang sistem lebih banyak menggunakan metode " Relatively

Closed dan Deterministik Sistem ", karena sistem ini dalam
pengerjaannya lebih mudah meramalkan hasil yang akan diperoleh
dan lebih mudah diatur dan diawasi.
Contoh :
Pada bidang sistem informasi, faktor komputer dan program
komputer biasanya " Relatively Closed dan Deterministik ", tetapi
faktor manusia sebagai pengelolanya adalah " Open dan Probabilistik
Sistem ".
• METODE SISTEM
A. BLACKBOX APPROACH.
Suatu sistem dimana input dan outputnya dapat didefinisikan tetapi
prosesnya tidak diketahui atau tidak terdefinisi.
Metode ini hanya dapat dimengerti oleh pihak dalam ( yang

menangani ) sedangkan pihak luar hanya mengetahui masukan
dan hasilnya. Sistem ini terdapat pada subsistem tingkat terendah.
Contoh : bagian pencetakan uang, proses pencernaan.

masukan yang keluaran yang
sudah terdefinisi sudah terdefinisi
pengolah yang tidak
terdefinisi
B. ANALITYC SISTEM.
Suatu metode yang mencoba untuk melihat hubungan seluruh
masalah untuk menyelidiki kesistematisan tujuan dari sistem yang
tidak efektif dan evaluasi pilihan dalam bentuk ketidak efektifan
dan biaya.
Dalam metode ini beberapa langkah diberikan seperti di bawah ini :

a. Menentukan identitas dari sistem.
- sistem apa yang diterapkan
- batasannya
- apa yang dilaksanakan sistem tersebut
b. Menentukan tujuan dari sistem.

- output yang dihasilkan dari isi sistem
- fungsi dan tujuan yang diminta untuk mencoba menanggulangi
lingkungan
c. Bagian-bagian apa saja yang terdapat dalam sistem dan apa

tujuan dari masing-masing bagian tersebut.
- tujuan masing-masing bagian sistem harus jelas.
- cara apa yang digunakan subsistem untuk berhubungan
dengan subsistem lain
d. Bagaimana bagian-bagian yang ada dalam sistem itu saling

berhubungan menjadi satu kesatuan.
4. PENGERTIAN ANALISIS SISTEM
Suatu sistem akan dirancang oleh satu orang atau sekelompok orang
yang membentuk tim. Orang yang merancang sistem ini disebut
Sistem Analis.

Ada yang mendefinisikan Sistem Analis sebagai :
§ Seorang yang menggunakan pengetahuan aplikasi komputer yang
dimilikinya untuk memecahkan masalah-masalah bisnis, dibawah
petunjuk Manajer Sistem.
§ Seorang yang bertanggung jawab menterjemahkan kebutuhan-
kebutuhan si pemakai sistem (user) ke dalam spesifikasi teknik
yang diperlukan oleh Programmer dan diawasi oleh Manajemen.
Pengertian sistem analis ini dapat digambarkan sebagai berikut :
MANAJEMEN
USER ANALIS SISTEM PROGRAMMER
5. FUNGSI ANALIS SISTEM
Fungsi Analisis Sistem adalah

1. Mengidentifikasikan masalah-masalah dari user
2. Menyatakan secara spesifik sasaran yang harus dicapai untuk
memenuhi kebutuhan user
3. Memeilih alternatif-alternatif metode pemecahan masalah
4. Merencanakan dan menerapkan rancangan sistemnya sesuai
dengan permintaan user

ANALISIS SISTEM
PENDAHULUAN
Definisi Analisis Sistem :

Penguraian dari suatu sistem informasi yang utuh ke dalam
bagian-bagian komponennya dengan maksud untuk
mengidentifikasikan dan mengevaluasi permasalahan,
kesempatan, hambatan yang terjadi dan kebutuhan yang
diharapkan sehingga dapat diusulkan perbaikan.
Tahap analisis dilakukan setelah tahap perencanaan sistem dan

sebelum tahap desain sistem. Tahap ini merupakan tahap yang kritis
dan sangat penting, karena kesalahan dalam tahap ini menyebabkan
kesalahan pada tahap selanjutnya.
Misalnya anda dihadapkan pada suatu sistem untuk menentukan

seberapa jauh sistem tersebut telah mencapai sasarannya. Jika
sistem mempunyai beberapa kelemahan, anda harus dapat
menemukannya. Tugas ini yang disebut sebagai analisis sistem.
Tugas utama dari menganalisis sistem meliputi :

§ Menentukan lingkup sistem
§ Mengumpulkan fakta
§ Menganalisis fakta
§ Mengkomunikasikan temuan-temuan tersebut melalui laporan
analisis sistem
Fakta merupakan bagian dari informasi yang menunjukkan realita,

situasi dan relasi yang menjamin analisis dan pemodelan.
LANGKAH-LANGKAH DI DALAM ANALISIS SISTEM
Langkah-langkah dasar yang harus dilakukan oleh analis sistem

adalah :
1. Identify, mengidentifikasi masalah
2. Understand, memahami kerja sistem yang ada
3. Analyze, menganalisis sistem
4. Report, membuat laporan hasil analisis
Analisis dan Perancangan Sistem Halaman 1

Untuk masing-masing langkah ini, beberapa tugas perlu dilakukan
oleh analis sistem. Supaya memudahkan untuk melakukan
koordinasi dan pengawasan, koordinator tim analis dapat membuat
suatu kertas kerja yang memuat tugas-tugas yang harus dikerjakan
untuk masing-masing langkah analisis sistem ini.
MENGIDENTIFIKASI MASALAH
Mengidentifikasi (mengenal) masalah merupakan langkah pertama

yang dilakukan dalam tahap analisis sistem. Masalah dapat
didefinisikan sebagai suatu pertanyaan yang diinginkan untuk
dipecahkan. Masalah inilah yang menyebabkan sasaran dari sistem
tidak dapat dicapai. Oleh karena itu langkah pertama yang harus
dilakukan oleh analis sistem adalah mengidentifikasi terlebih dahulu
masalah-masalah yang terjadi.
Tugas yang harus dilakukan analis sistem adalah :

§ Mengidentifikasi penyebab masalah
§ Mengidentifikasi titik keputusan
§ Mengidentifikasi personil-personil kunci
3.1. Mengidentifikasi Penyebab Masalah
Analis sistem harus mempunyai pengetahuan yang cukup tentang

aplikasi yang sedang dianalisisnya. Untuk aplikasi bisnis, analis
sistem perlu mempunyai pengetahuan tentang sistem bisnis yang
diterapkan di organisasi, sehingga dapat mengidentifikasi penyebab
terjadinya masalah ini.
Tugas mengidentifikasi penyebab masalah dimulai dengan mengkaji

ulang terlebih dahulu subyek permasalahan yang telah diutarakan
oleh manajemen atau yang telah ditemukan oleh analis sistem di
tahap perencanaan sistem.
3.2. Mengidentifikasi Titik Keputusan
Setelah penyebab terjadinya masalah dapat diidentifikasi, selanjutnya

juga harus mengidentifikasikan titik keputusan penyebab masalah
tersebut. Titik keputusan menunjukkan suatu kondisi yang
menyebabkan sesuatu terjadi.
Analis sistem bila telah dapat mengidentifikasi terlebih dahulu titik-titik
keputusan penyebab masalah, maka dapat memulai penelitiannya di
titik-titik keputusan tersebut. Sebagai dasar identifikasi titik-titik
keputusan ini, dapat digunakan dokumen paperwork flow atau form
flowchart bila dokumentasi ini dimiliki oleh perusahaan.
3.3. Mengidentifikasi Personil-personil Kunci
Setelah titik-titik keputusan penyebab masalah dapat diidentifikasi

beserta lokasi terjadinya, maka selanjutnya yang perlu diidentifikasi
adalah personil-personil kunci baik yang langsung maupun yang tidak
langsung dapat menyebabkan terjadinya masalah tersebut.
Identifikasi personil-personil kunci ini dapat dilakukan dengan
mengacu pada bagan alir dokumen perusahaan serta dokumen
deskripsi kerja (job description).
MEMAHAMI KERJA SISTEM
Langkah ini dapat dilakukan dengan mempelajari secara terinci

bagaimana sistem yang ada beroperasi. Diperlukan data yang dapat
diperoleh dengan cara melakukan penelitian. Bila di tahap
perencanaan sudah pernah diadakan penelitian, sifatnya masih
penelitian pendahuluan (preliminary survey). Sedangkan pada tahap
analisis sistem, penelitiannya bersifat penelitian terinci (detailed
survey).
Analis sistem perlu mempelajari apa dan bagaimana operasi dari

sistem yang ada sebelum mencoba untuk menganalisis
permasalahan, kelemahan dan kebutuhan pemakai sistem untuk
dapat memberikan rekomendasi pemecahannya. Sejumlah data perlu
dikumpulkan, dengan menggunakan teknik pengumpulan data yang
ada, yaitu wawancara, oberservasi, daftar pertanyaan dan
pengambilan sampel.
Tugas yang perlu dilakukan di langkah ini adalah :

§ Menentukan jenis penelitian
§ Merencanakan jadual penelitian
o Mengatur jadual wawancara
o Mengatur jadual observasi
o Mengatur jadual pengambilan sampel

§ Membuat penugasan penelitian
§ Membuat agenda wawancara
§ Mengumpulkan hasil penelitian
4.1. Menentukan Jenis Penelitian
Jenis penelitian perlu ditentukan untuk masing-masing titik keputusan

yang akan diteliti. Jenis penelitian tergantung dari jenis data yang
diperoleh, dapat berupa data tentang operasi sistem, data tentang
perlengkapan sistem, pengendalian sistem, atau I/O yang digunakan
oleh sistem.
4.2. Merencanakan Jadual Penelitian
Supaya penelitian dapat dilakukan secara efisien dan efektif, maka

jadual penelitian harus direncanakan terlebih dahulu yang meliputi :
o Dimana penelitian akan dilakukan

o Apa dan siapa yang akan diteliti
o Siapa yang akan meneliti
o Kapan penelitian dilakukan
Dari rencana jadual ini, berikutnya ditentukan ke dalam jenis

penelitiannya masing-masing.
4.3. Membuat Penugasan Penelitian
Setelah rencana jadual penelitian dibuat, maka tugas dilanjutkan

dengan menentukan tugas dari masing-masing anggota tim analis
sistem, yang ditentukan oleh koordinator analis sistem melalui surat
penugasan dengan menyertakan lampiran kegiatan penelitian yang
harus dilakukan.
4.4. Membuat Agenda Wawancara
Sebelum wawancara dilakukan, waktu dan materi wawancara perlu

didiskusikan. Rencana ini dapat ditulis di agenda wawancara dan
dibawa selama wawancara berlangsung. Tujuannya adalah supaya
wawancara dapat diselesaikan tepat pada waktunya dan tidak ada
materi yang terlewatkan.

4.5. Mengumpulkan Hasil Penelitian
Fakta atau data yang diperoleh dari hasil penelitian harus

dikumpulkan sebagai suatu dokumentasi sistem lama, yaitu :
1. Waktu untuk melakukan suatu kegiatan
2. Kesalahan melakukan kegiatan di sistem yang lama
3. Pengambilan sampel
4. Formulir dan laporan yang dihasilkan oleh sistem lama
5. Elemen-elemen data
6. Teknologi yang digunakan di sistem lama
7. Kebutuhan informasi pemakai sistem / manajemen
MENGANALISIS HASIL
Langkah ini dilakukan berdasarkan data yang telah diperoleh dari

hasil penelitian yang telah dilakukan.
5.1. Menganalisis Kelemahan Sistem

Penelitian dilakukan untuk menjawab pertanyaan :
Ø apa yang dikerjakan ?
Ø bagaimana mengerjakannya ?
Ø siapa yang mengerjakan ?
Ø dimana dikerjakan ?
Menganalisis kelemahan sistem sebaliknya dilakukan untuk

menjawab pertanyaan :
Ø mengapa dikerjakan ?
Ø perlukah dikerjakan ?
Ø apakah telah dikerjakan dengan baik ?
Sasaran yang diinginkan oleh sistem yang baru ditentukan oleh

kriteria penilaian sebagai berikut : relevance, capacity, efficiency,
timeliness, accessibility, flexibility, accuracy, reliability, security,
economy, simplicity
Berdasarkan pertanyaan dan kriteria ini, selanjutnya analis sistem

akan dapat melakukan analis dari hasil penelitian dengan baik untuk
menemukan kelemahan dan permasalahan dari sistem yang ada.

Analisa yang dilakukan meliputi :
ANALISA DAFTAR PERTANYAAN

Distribusi pekerjaan Apakah tugas dan tanggungjawab telah
didefinisikan dan diterapkan dengan jelas ?
Apakah telah didistribusikan dengan efektif
untuk masing-masing personil dan unit
organisasi ?
Pengukuran Apakah kebijakan dan prosedur telah
pekerjaan dipahami dan diikuti ?
Apakah produktivitas karyawan memuaskan
?
Apakah unit-unit organisasi telah bekerja
sama dan terkoordinasi dengan baik menjadi
arus data dengan lancar ?
Apakah terjadi operasi yang tumpah tindih ?
Seberapa perlu hasil dari tiap-tiap operasi ?
Apakah terdapat operasi yang menghambat
arus data ?
Apakah volume puncak dari data dapat
ditangani dengan baik ?
Apakah terdapat standar kinerja yang baik
dan selalu mutakhir ?
Keandalan Apakah jumlah kesalahan yang terjadi di
masing-masing operasi diminimumkan ?
Apakah operasi-operasi telah direncanakan
dengan baik dan terkendali ?
Dokumen Seberapa perlu dokumen-dokumen yang
ada ?
Apakah masing-masing dokumen telah
dirancang untuk penggunaan yang efektif ?
Apakah tembusan dari dokumen perlu ?
Laporan Dapatkah laporan dipersiapkan dengan
mudah dari file dan dokumen yang ada ?
Apakah terdapat duplikasi di file, catatan dan
laporan ?
Teknologi Apakah fasilitas dari sistem informasi
(personil, peralatan dan fasilitas lain) cukup
untuk menangani volume rata-rata data
tanpa terjadi penundaan yang berarti ?

5.2. Menganalisis Kebutuhan Informasi Pemakai / Manajemen
Tugas lain dari analis sistem yang diperlukan sehubungan dengan

sasaran utama sistem informasi, yaitu menyediakan informasi yang
dibutuhkan bagi para pemakainya perlu dianalisis.
6. MEMBUAT LAPORAN HASIL ANALISIS
Laporan hasil analisis diserahkan ke Panitia Pengarah (Steering

Committee) yang nantinya akan diteruskan ke manajemen. Pihak
manajemen bersama-sama dengan panitia pengarah dan pemakai
sistem akan mempelajari temuan-temuan dan analis yang telah
dilakukan oleh analis sistem yang disajikan dalam laporan ini.
Tujuan utama dari penyerahan laporan ini kepada manajemen adalah :

§ Analisis telah selesai dilakukan
§ Meluruskan kesalah-pengertian mengenai apa yang telah
ditemukan dan dianalisis oleh analis sistem tetapi tidak sesuai
menurut manajemen
§ Meminta pendapat dan saran dari pihak manajemen
§ Meminta persetujuan kepada pihak manajemen untuk melakukan
tindakan selanjutnya (dapat berupa meneruskan ke tahap disain
sistem atau menghentikan proyek bila dipandang tidak layak lagi)
Semua hasil yang didapat dari penelitian perlu dilampirkan pada

laporan hasil analisis ini, sehingga manajemen dan user dapat
memeriksa kembali kebenaran data yang telah diperoleh.

MENDEFINISIKAN LINGKUP SISTEM BARU DAN PENGUMPULAN
INFORMASI
Untuk melaksanakan pekerjaan ini, analis sistem perlu menentukan

lingkup sistem dari sistem yang baru dan mendapatkan informasi
yang banyak.
Ada tiga sumber dari fakta studi, yaitu :

§ Sistem yang berjalan
§ Sumber internal lainnya
§ Sumber eksternal
Apa yang termasuk ke dalam sistem baru ?

Untuk menjawab pertanyaan ini secara umum, analis sistem
memerlukan beberapa pertanyaan khusus berikut ini :
§ Informasi apa yang dibutuhkan ?
§ Siapa yang membutuhkan ?
§ Kapan dibutuhkan ?
§ Dalam bentuk apa dibutuhkannya ?
§ Dari mana asalnya informasi ?
§ Kapan dan bagaimana dikumpulkannya ?
Masalah utama bagi profesional sistem, baik yang baru mau pun
yang berpengalaman adalah mengubah / menterjemahkan sebuah
instruksi dari : “I want a daily purchasing report” ke dalam “Develop a
new purchasing and inventory managemet system”. DFD merupakan
alat yang cocok untuk mendefinisikan lingkup analisis sistem.
Batasan-batasan yang ada dalam mendefinisikan sistem membatasi

penyelesaian sistem dan rekomendasi yang dihasilkan dari analisis.
Definisi awal dari lingkupnya merupakan pokok untuk mendefinisikan
ulang pada saat dimana temuan-temuan terjadi saat analisis.
Biasanya banyak menghabiskan waktu dan uang, sehingga perlu
komitmen waktu dari user untuk ikut berpartisipasi.
Keuntungan dari pemodelan sistem yang berjalan

Menyediakan kesempatan untuk menentukan apakah sistem
memuaskan, perlu sedikit perbaikan, membutuhkan pemeriksaan
yang besar, atau diganti. Juga menyediakan sumber ide
perancangan untuk membantu analis mengidentifikasikan sumber
yang ada bagi sistem yang baru.
Saat sistem baru diimplementasikan, analis bertanggungjawab atas
kapan tugas dan kegiatan akan dibutuhkan untuk menghapus
pertahap sistem yang berjalan dan memulai mengoperasikan sistem
yang baru. Saat dikonversi, analis harus mengetahui tidak hanya
kegiatan apa yang dilaksanakan tetapi juga kegiatan-kegiatan yang
sudah dilaksanakan. Dengan mempelajari dan memodelkan sistem
yang berjalan, memberi jawaban terhadap analis.
Kerugian dari pemodelan sistem yang berjalan

Dalam banyak situasi dimana sistem baru unik atau berbeda sekali
dengan sistem yang berjalan, mempelajari sistem yang berjalan
kadang-kadang menyesatkan. Jeleknya, sistem yang berjalan
menjadi tidak relevan dan menganalisisnya menjadi menghabiskan
waktu dan uang. Lebih menyenangkan jika mengidentifikasikan apa
yang dibutuhkan dari sistem baru dibandingkan membicarakan
kembali apa yang terjadi dengan sistem yang berjalan.
Pengumpulan informasi dari orang yang menggunakan sistem

Sumber yang utama adalah orang yang akan menggunakan sistem
yang baru. Pengetahuan teknis user dari user baru hingga yang ahli
disebut pengetahuan sintaksis. Untuk bisnis dan pekerjaan
merupakan pengetahuan semantik dan merupakan keahliannya.
Untuk membangun sistem baru, analis sistem mengumpulkan data

semantik dari user. Data semantik ini yang akan mengarahkan analis
sistem selama menganalis dan merancang. Analis sistem dan
perancang kemudian akan mendiskusikan data teknis dengan ahli
teknisi sistem seperti programmer untuk mendapatkan spesifikasi
sistem (mikro atau mini spec). Jadi analis sistem perlu berkomunikasi
dengan user yang memiliki pengetahuan semantik di satu sisi, dan di
sisi lain dengan teknisi sistem yang mempunyai pengetahuan
sintaksis.
Sumber kedua didapat dari dokumen kerja yang ada dalam

organisasi. Dokumen dapat diklasifikasikan misalnya struktur
organisasi, apa yang sudah dilakukan organisasi, dan rencana apa
yang akan dilakukan organisasi.
Lihat contoh pada gambar 2.1

Pengumpulan informasi dari sumber di luar organisasi user
Informasi yang berasal dari luar organisasi membuka cakrawala ide
dan teknik. Banyak industri dari kelompok dan seminar memberikan
pengalaman sistem informasi dan merekomendasikan cara yang
lebih baik.
TEKNIK-TEKNIK PENGUMPULAN INFORMASI TAMBAHAN
1. Interview (Wawancara)
o Merupakan teknik yang efektif digunakan selama
pengembangan sistem.
o Merupakan sebuah pertukaran informasi antara pewawancara
(analis sistem) dengan yang diwawancarai (user).
o Perlu ada perencanaan, dan perlu ada tujuan khusus.
o Terdiri dari pertanyaan dan menjawab pertanyaan.
o Analis sistem menggunakan mekanisme feedback dan cara
utama untuk mengumpulkan fakta lapangan dan melihat gap
yang ada.
Ada dua tipe pertanyaan dalam wawancara, yaitu Open-ended dan

Closed-ended.
Pertanyaan Open-Ended
Pertanyaan ini adalah netral dan tidak dibatasi. Pewawancara
mengijinkan secara bebas orang yang diwawancarai dalam
menjawab pertanyaan, dan pewawancara menganjurkan yang
diwawancarai untuk memberikan informasi yang tidak diketahui
sebelumnya kepada pewawancara.
Contoh :
“What are your feelings about chaging from paper forms to electronic
forms ?”
Pertanyaan Closed-Ended
Dalam closed-ended, pewawancara lebih mudah mengontrol yang
diwawancarai, karena apa yang akan ditanyakan sudah pasti dan
menghindari yang diwawancarai menjawab bebas. Cara yang terbaik
adalah menhindari pertanyaan yang berasumsi, dan pernyataan
dengan akhir “could you ?” atau “isn’t it ?”

Contoh :
“Should we use a PC-based network or a departemental computer ?”
“You agree with this report format, don’t you ?”
Pertanyaan dapat dibagi dalam 2 kategori , yaitu :

§ Primer : untuk topik khusus, direncanakan dan netral.
§ Sekunder : merupakan kelanjutan dari pertanyaan primer untuk
mendapatkan tambahan informasi, pertanyaannya bersifat tidak
terencana.
Contoh :
“Would you describe ?” atau “Would you please give me more
details ?”
Merencanakan Urutan Pertanyaan :
Funnel format Inverted funnel format
Open-ended Closed-ended
Closed-ended Open-ended
Funnel Format :
Dengan format ini, pewawancara mulai dengan pertanyaan open-
ended, kemudian menggunakan pertanyaan closed-ended, secara
berangsur-angsur wawancara berakhir sampai informasi khusus yang
dibutuhkan.
Inverted Funnel Format :

Pewawancara mulai dengan pertanyaan closed-ended khusus dan
secara berangsur-angsur yang diwawancarai memberikan gambaran
keluar dari titik dimana dia akan menjawab dan memperluas jawaban
untuk pertanyaan open-ended.

Psikologi Wawancara
Berkenaan dengan hubungan antar manusia. Berikut ini adalah
pedoman-pedoman yang dapat dilakukan oleh pewawancara untuk
melakukan tindak lanjut terhadap tingkah laku dari orang yang
diwawancarai.
Wawancara juga dapat dibuat sebelumnya.
Ada dua sumber dasar informasi, sumber pertama yaitu apa yang
orang katakan mengenai calon yang diwawancarai, dan sumber
kedua adalah catatan atau dokumen organisasi seperti struktur
organisasi atau resume organisasi.
Setelah selesai wawancara, pewawancara sebaiknya menyimpan

atau mencatat dan mengevaluasi hasilnya. Dan perlu dibuat
ringkasan dan laporan ke manajemen dan ke yang diwawancarai
untuk menunjukkan bahwa apa yang dikatakan mereka cukup
penting untuk dicatat.
2. Sampling
Sampling adalah aplikasi dari prosedur tertentu yang kurang dari
100% item dalam suatu survey untuk mengevaluasi atau estimasi
beberapa karakteristik dari populasi. Sampling berguna untuk
menentukan karakteristik atau nilai dari seluruh item yang akan
dipergunakan hingga selesai.
Sampling Statistik dan Non Statistik

Probabilitas statistik digunakan untuk mengontrol resiko sampling
dalam sampling statistik.
Dalam sampling non statistik, analis menentukan ukuran sampling
dan mengevaluasi hasil seluruh sample berdasarkan pertimbangan
dan pengalaman.
Analis perlu mengetahui dimana harus dipergunakan jumlah sample
yang besar, dan dimana untuk jumlah sample yang kecil.

Tahapan dalam Perencanaan Sampling
Sampling statistik mau pun non statistik tahapannya sama, hanya
dalam sampling statistik tidak menggunakan formula matematika dan
tabel statistik.
Tahapannya adalah :
1. Menentukan tujuan sampling.
2. Mendefinisikan populasi dan unit sampling.
3. Menspesifikasikan karakteristik.
4. Menentukan ukuran sample.
5. Menentukan metode pemilihan sample dan melaksanakannya.
Ada tiga metode sampling : random number, sampling sistematis
dan sampling blok.
6. Mengevaluasi hasil sample dan membuat suatu kesimpulan.
3. Observasi
Observasi memiliki banyak tujuan. Analis dapat menentukan apa
yang akan dilakukan, bagaimana dilakukan, siapa yang mengerjakan,
kapan dikerjakan, berapa lama dikerjakan, dimana dikerjakan, dan
mengapa dikerjakan. Analis juga dapat berpartisipasi dalam
pelaksanaan prosedur yang dilakukan oleh pegawai.
Beberapa cara mengobservasi :
Persiapan
Sebelum observasi dimulai, analis akan :
§ Mengidentifikasi dan menentukan apa yang akan diobservasi
§ Mengestimasi waktu untuk observasi
§ Menjamin persetujuan manajemen untuk pelaksanaan observasi
§ Menjelaskan ke organisasi yang diobservasi, apa yang akan
dilakukan dan mengapa
Pelaksanaan Observasi
Observasi akan dikelola secara efektif oleh analis dengan mengikuti
aturan berikut ini :
§ Analis perlu terbiasa dengan lingkungan sekitar dan komponen
dalam area yang diobservasi. Membiasakan dengan pekerjaan
yang berjalan pada tempat tersebut.
§ Selama observasi, analis secara berkala melakukan pencatatan.

§ Analis perlu mencatat hal-hal yang khusus. Deskripsi yang umum
dan samar sebaiknya dihindari.
§ Jika analis berinteraksi dengan orang-orang yang diobservasi,
analis sebaiknya berulang-ulang membuat komentar kualitatif dan
penilaian.
§ Analis perlu menunjukkan kebaikan dan keamanan selama
observasi.
Analis kemungkinan bisa tidak memiliki banyak waktu dalam

mengobservasi. Untuk itu, teknik sampling dapat digunakan secara
efektif untuk mengurangi waktu yang dibutuhkan dalam
mengobservasi dan tetap dapat mengumpulkan fakta / hasil yang
pasti.
MENYIMPULKAN ANALISIS SISTEM DAN MENGKOMUNIKASI-

KAN TEMUAN
Selama fase analisis sistem, analis perlu tetap memelihara
komunikasi yang ekstensif dengan user, manajer proyek dan orang-
orang proyek lainnya. Komunikasi tersebut meliputi :
§ Feedback ke orang yang diwawancarai, atau diobservasi menurut
apa yang analis ketahui.
§ Verifikasi dengan user untuk menemukan keterhubungan fungsi
dan aktivitas yang perlu analis indentifikasi.
§ Melakukan pertemuan secara periodik untuk memberitahu
manajer proyek dan personal proyek lainnya tentang progress,
status dan ketepatan waktu.
Menyiapkan Laporan Analisis Sistem

Laporan Analisis Sistem disiapkan secara professional dengan
menggunakan kertas, PC atau teknologi CASE. Beberapa aturan
dalam membuat professional documented deliverables sama seperti
membuat laporan-laporan hasil penulisan.
Beberapa isi laporan analisis sistem yang perlu ada adalah :

1. Alasan dan lingkup dari analisis sistem
2. List dari masalah utama yang diidentifikasi
3. Pernyataan yang lengkap dan definisi dari kebutuhan user
4. List dari asumsi kritis
5. Rekomendasi

Mempresentasikan secara oral
Penyampaian presentasi secara oral dari setiap dokumen analisis
sistem memerlukan komunikasi yang lengkap dan jelas. Ada tiga
metode yang dapat digunakan untuk prensentasi secara oral ini,yaitu:
§ Mengingat
§ Membaca
§ Tanpa persiapan
Dapat pula mempresentasikan dengan bantuan teknologi audio

visual.
Ada empat hal yang dapat dihasilkan dari analisis sistem :

1. Proyek dilepas.
Proyek sistem yang dilepas dapat berasal dari masalah utama
yang tidak dapat diselesaikan. Alasan lain, adanya perubahan dari
prioritas sistem oleh pihak manajemen atau komite pengarah,
yang mengakibatkan proyek sistem yang sekarang dilepas.
2. Proyek ditunda.
Pada saat ini, pihak manajemen akan menentukan sumber daya
untuk proyek sistem lain dengan prioritas yang lebih tinggi. Maka
instalasi untuk backbone telekomunikasi akan tertunda, sehingga
proyek sistem yang sekarang ditunda. Beberapa pemakai kunci
mungkin sedang berlibur atau tidak masuk untuk beberapa
minggu, sehingga menyebabkan proyek ditunda sementara waktu
dari SDLC.
3. Proyek diganti.
Hasil ini berarti bahwa aspek penting dari proposal sistem yang
asli mempunyai perubahan yang berarti. Seperti perubahan yang
melibatkan perluasan utama dan penyusunan dari lingkup sistem.
Atau mungkin pemakai membutuhkan perubahan yang berarti dari
perkiraan yang lebih cepat itu, menyebabkan kebutuhan sumber
daya yang lebih banyak atau sedikit.
4. Proyek dilanjutkan.
Proyek sistem akan diteruskan seperti rencana dalam laporan
analisis sitem.

PERANCANGAN SISTEM SECARA UMUM
1. PERANCANGAN SISTEM
Setelah tahap analisis sistem selesai dilakukan, maka analis sistem telah
mendapatkan gambaran dengan jelas apa yang harus dikerjakan. Tiba
waktunya sekarang bagi analis sistem untuk memikirkan bagaimana
membentuk sistem tersebut. Tahap ini disebut dengan perancangan sistem.
Perancangan sistem dapat dibagi dalam 2 bagian, yaitu :

1. Perancangan sistem secara umum / perancangan konseptual,
perancangan logikal / perancangan secara makro.
2. Perancangan sistem terinci / perancangan sistem secara phisik.
2. PENGERTIAN PERANCANGAN SISTEM
Verzello / John Reuter III

Tahap setelah analisis dari siklus pengembangan sistem : Pendefinisian dari
kebutuhan-kebutuhan fungsional dan persiapan untuk rancang bangun
implementasi : “menggambarkan bagaimana suatu sistem dibentuk “.
John Burch & Gary Grudnitski

Desain sistem dapat didefinisikan sebagai penggambaran, perencanaan dan
pembuatan sketsa atau pengaturan dari beberapa elemen yang terpisah ke
dalam satu kesatuan yang utuh dan berfungsi.
George M. Scott
Desain sistem menentukan bagaimana suatu sistem akan menyelesaikan
apa yang mesti diselesaikan ; tahap ini menyangkut mengkonfigurasikan dari
komponen-komponen perangkat lunak dan perangkat keras dari suatu
sistem, sehingga setelah instalasi dari sistem akan benar-benar memuaskan
rancang bangun yang telah ditetapkan pada akhir tahap analisis sistem.
Dengan demikian Perancangan Sistem dapat diartikan sbb :

1. Tahap setelah analisis dari siklus pengembangan sistem
2. Pendefinisian dari kebutuhan-kebutuhan fungsional
3. Persiapan untuk rancang bangun implementasi
4. Menggambarkan bagaimana suatu sistem dibentuk
5. Dapat berupa penggambaran, perencanaan dan pembuatan sketsa atau
pengaturan dari beberapa elemen yang terpisah ke dalam satu kesatuan
yang utuh dan berfungsi
6. Termasuk menyangkut mengkonfigurasi dari komponen-konponen
perangkat lunak dan perangkat keras dari suatu sistem

3. TUJUAN PERANCANGAN SISTEM
Tahap Perancangan / Desain Sistem mempunyai 2 tujuan utama, yaitu :
1. Untuk memenuhi kebutuhan kepada pemakai sistem
2. Untuk memberikan gambaran yang jelas dan rancang bangun yang
lengkap kepada pemrogram komputer dan ahli-ahli teknik yang terlibat
(lebih condong pada desain sistem yang terinci)
4. PERSONIL YANG TERLIBAT

Analis sistem seharusnya melibatkan beberapa personil, seperti :
1. Spesialis pengendalian
2. Personil penjamin kualitas
3. Spesialis komunikasi data
4. Pemakai sistem
5. PERANCANGAN SISTEM SECARA UMUM
Tujuan dari desain sistem secara umum adalah untuk memberikan

gambaran secara umum kepada user tentang sistem yang baru.
Analisis sistem dan desain sistem secara umum bergantung satu sama lain.
Studi menunjukkan bahwa apa yang dikumpulkan, dianalisis dan dimodelkan
selama fase analisis menyediakan dasar bagi desain sistem secara umum
untuk dibuat. Fase analisis sistem merupakan investigasi dan berorientasi ke
temuan.
Pada fase ini, profesional sistem harus sering membuat fitur yang baru atau
berbeda dari model dasar yang dibuat selama analisis sistem.
Kuncinya adalah dapatkan atau tuliskan semua ke dalam kertas tanpa

mencoba untuk memperbaiki desain sistem lebih awal. Aturannya adalah :
berinteraksi dengan user, periksa dengan anggota tim, periksa dengan
teknisi (pemrogram); desain ulang, periksa, periksa dan periksa kembali
tetapi jangan coba-coba untuk membangun detail yang lebih rendah atau
spec kecil selama fase ini. Semua ini akan dilakukan jika salah satu dari
desain sistem secara umum sudah dipilih untuk implementasi.
TIGA KATEGORI DESAIN SISTEM

1. Global-Based Systems
2. Group-Based Systems
3. Local-Based Systems
Lihat gambar 6.2 Categories of systems based on size and breadth, degree
of complexity, and volume of transactions halaman 13

Global-Based Systems (Sistem Berbasis Global)
Untuk mendesain sistem yang berbasis global (global-based) membutuhkan
pemeriksaan secara seksama dan lengkap atau penggantian dari seluruh
komponen desain umum. Beberapa tipe perubahan yang umum adalah :
 Output yang lama : dari laporan berbentuk tabel setiap bulannya menjadi
layar grafik berwarna 2 atau 3 dimensi
 Proses baru dibuat
 Input diambil dari peralatan scan daripada dengan pensil dan kertas
 Database hirarki lama diubah ke database relasional baru dengan
standar bahasa query
 Kontrol yang bervariasi diinstal, termasuk UPS (Uninterruptible Power
Systems), DRP (Disaster Recovery Plans), peralatan enkripsi dan
peralatan kontrol akses biometri
 Platform teknologi baru yang menggabungkan seluruh topologi jaringan
organisasi (komputer dan peralatannya) yang mendukung
Membutuhkan beberapa tim proyek yang langsung ditunjuk dari CIO.
Lembar kerjanya berisi semua komponen desain umum berikut deskripsi

masing-masing secara umum. Beberapa alternatif diberikan ke user untuk di
review dan diketahui.
Setelah direview, alternatif beberapa aspek dapat digabungkan untuk dibuat
gabungannya. Beberapa diantaranya dapat diterima atau dapat ditolak.
Lihat gambar 6.3 General systems design worksheet showing one general
systems design alternative halaman 14
Group-Based Systems (Sistem Berbasis Kelompok)

Sistem ini melayani cabang-cabang atau group user khusus dalam
organisasi. Kelompok ini memiliki kebutuhan khusus untuk menyelesaikan
pekerjaan dan membuat keputusan yang tepat. Perancang sistem yang
bekerja pada group ini perlu memiliki pengetahuan tentang bekerja pada
sistem group-based. Perancang tidak perlu memusatkan perhatian ke
perancangan desain sistem tertentu, seperti database dan platform teknologi
tetapi pada output, input, proses, kontrol dan untuk platform teknologi,
khusus untuk group local (LAN).
Local-Based Systems (Sistem Berbasis Lokal)

Sistem ini khusus didesain untuk beberapa orang, sering satu atau dua,
untuk aplikasi khusus tambahan. User memiliki PC dan ia direncanakan
untuk memiliki sistemnya. Profesional sistem umumnya dipakai untuk bekerja
sama dengan user menganalisis mendesain, mengevaluasi sistem yang
berbeda, memilih satu dan mengimplementasikan dengan menggunakan
jaringan dan pendukungnya.

EMPAT KUNCI ELEMEN DARI RAPID APPLICATION DEVELOPMENT
(RAD) UNTUK MENDESAIN SISTEM
RAD dipopulerkan oleh James Martin.
Sinergismenya adalah bahwa RAD menggabungkan elemen-elemen yang
bekerja sama, sehingga dampak keseluruhannya lebih besar dibandingkan
dengan jumlah dampak per individu / masing-masing.
Adapun 4 kunci elemen RAD adalah :

1. Joint Application Development (JAD)
2. Specialists With Advanced Tools (SWAT) teams
3. Computer-Aided System and Software Engineering (CASE) tools
4. Prototyping
Joint Apllication Development (JAD)

Efektif untuk digunakan di sistem global-based.
JAD dapat juga dipakai di sistem group-based maupun local-based.
Kunci utamanya adalah joint; user dan professional sistem bekerja sama
untuk menganalisis dan mendesain sistem.
Lihat gambar 6.4 Systems designer and user interacting jointly to create
conceptual systems design model halaman 15
Gambar 6.4 menunjukkan 3 perbedaan model perancangan, yaitu :

1. Model Perancangan Mental Desainer (Designer’s Mental Design
Model)
Model ini diformulasikan dari pengalaman, pengetahuan, studi lapangan
dan input dari interaksi yang dilakukan dengan user.
2. Model Perancangan Mental User (User’s Mental Design Model)

Idealnya model ini dan model desain sistem konseptual adalah sama.
Interaksi joint dan proses desain diulang hingga model desain sistem
konseptual sama dengan model desain mental user
3. Model Perancangan Sistem Konseptual

Menggambarkan modeling tool, seperti Data Flow Diagram (DFD), Entity
Relationship Diagram (ERD), decision table, screen prototype of report,
decision tree, dll.

Specialists With Advanced Tools (SWAT) teams
Terdiri dari 3 atau 4 profesional sistem yang memiliki kemampuan dan
motivasi.
Tim proyek yang kecil lebih produktif dibandingkan dengan tim proyek untuk
sistem yang lebih besar.
CASE Tools
Digunakan oleh tim SWAT untuk menambah produktifitas dan kualitas kerja
dari membangun sistem.
 Menambah disiplin
 Mengurangi kesalahan dan kekosongan desain
 Mengurangi kerja sistem yang berulang
Prototyping
Bekerja dengan JAD dimana user ditunjukkan dengan apa yang akan
mereka dapatkan dan meresponnya. CASE memfasilitasi prototyping untuk
membuat desain layar, model-model yang bervariasi dan dialog yang cepat
serta untuk memodifikasinya saat berinteraksi dengan user.
Dengan RAD, penyusunan prototyping tidak dibuang, tetapi menjadi bagian

dari desain sistem akhir. Pendekatannya mencapai aturan 80:20, 80%
permintaan user dapat dipenuhi dengan 20% desain sistem. Tim SWAT
bekerja di akhir dari sistem. Pengalaman user membantu tim SWAT dalam
mendefinisikan perubahan-perubahan yang tidak terbayangkan.
Macam dari aturan 80:20 ini untuk membangun sistem adalah teknik kotak
waktu DuPont (time box technique) dimana proyek sistem harus diselesaikan
tidak lebih dari 90 hari. Pendekatan ini lebih ke teknik manajemen proyek.
Jika melebihi 90 hari berarti kehilangan kesempatan bisnis dan akan
melebihi estimasi waktu dan uang.
6. TAHAPAN PERANCANGAN SISTEM
6.1. PERANCANGAN OUTPUT

Perancangan output atau keluaran merupakan hal yang tidak dapat
diabaikan, karena laporan atau keluaran yang dihasilkan harus
memudahkan bagi setiap unsur manusia yang membutuhkannya.

Tipe output dapat dibedakan :
Eksternal
Tujuan output untuk informasi diluar organisasi pemakai
Contoh : faktur, check, tanda terima pembayaran, dll.
Internal
Tujuan output untuk informasi dilingkungan organisasi pemakai
Contoh : laporan-laporan terinci, laporan-laporan ringkasan, dll.
Yang harus diperhatikan dalam perancangan output :

Tipe output (Eksternal, Internal)
Isi output (keterangan atau informasi)
Format output (berupa keterangan/narrative, tabel atau grafik)
Frekuensi (banyaknya pencetakan dalam periode tertentu)
Langkah-langkah Perancangan Output Secara Umum :

Menentukan kebutuhan Output dari sistem yang baru
Output yang akan dirancang dapat ditentukan dari DFD sistem baru yang
telah dibuat.
Menentukan parameter dari Output (lihat yang harus diperhatikan dalam
perancangan Output)
6.2. PERANCANGAN INPUT

Tujuan dari Perancangan Input adalah :
Untuk mengefektifkan biaya pemasukan data
Untuk mencapai keakuratan yang tinggi
Untuk menjamin pemasukan data dapat diterima & dimengerti oleh
pemakai
Proses Input dapat melibatkan dua atau tiga tahapan utama, yaitu :
Data capture / Penangkapan data
Data preparation / Penyiapan data
Data entry / Pemasukan data
Input yang menggunakan alat input tidak langsung mempunyai 3 tahapan

utama, yaitu data capture, data preparation dan data entry.
Sedangkan input yang menggunakan alat input langsung terdiri dari 2
tahapan utama, yaitu data capture dan data entry.
Tipe Input
Eksternal
Pada tipe ini pemasukan data berasal dari luar organisasi
Contoh : faktur pembelian, kwitansi-kwitansi dari luar organisasi, dll
Internal

Pada tipe ini pemasukan data hasil komunikasi pemakai dengan sistem
Contoh : faktur penjualan, order penjualan, dll
Yang perlu diperhatikan dalam Perancangan Input adalah :

Tipe input
Fleksibel format
Kecepatan
Akurat
Metode verifikasi
Mudah dikoreksi
Keamanan
Mudah digunakan
Kompatibel dengan sistem yang lain
Biaya yang ekonomis
Langkah-langkah Perancangan Input Secara Umum :

Menentukan kebutuhan Input dari sistem yang baru
Input yang akan dirancang dapat ditentukan dari DFD sistem baru yang
telah dibuat
Menentukan parameter dari Input
Alat Input direct entry :

MICR, OCR, OMR, DIGITIZER, IMAGE SCANNER, POS DEVICE, ATM,
MOUSE, VOICE RECOGNITION.
6.3. PERANCANGAN DIALOG

Tujuan dari perancangan Dialog adalah :
Untuk menjaga agar pemasukan data benar
Untuk menjawab pertanyaan yang sering diajukan oleh pemakai
Tipe Dialog :
Dialog Aktif
Pemakai mengajukan pertanyaan atau memasukan data
PEMASUKAN DATA BARANG
Nomor Order :
Nama Barang :
Jumlah Barang :
Harga :
Penjual :
Tanggal Pemesanan Barang :
Tanggal Diterima Barang :

Dialog Pasif
Pada tipe ini pemakai memilih pilihan yang tersedia
PROGRAM SISTEM INVENTORY
MENU PILIHAN
1. PEMASUKAN DATA BARANG
2. PROSES DATA BARANG
3. CETAK LAPORAN
4. SELESAI
PILIHAN ANDA : …
Yang perlu diperhatikan dalam Perancangan Dialog adalah :

Mudah digunakan
Dapat memberikan petunjuk
Menggambarkan atau sesuai dengan keinginan pemakai
Cepat memberikan respon
Dapat menampilkan pesan kesalahan
Fleksibel
6.4. PERANCANGAN PROSES SISTEM

Tujuan dari Perancangan Proses Sistem adalah :
Untuk menjaga agar proses data lancar dan teratur sehingga
menghasilkan informasi yang benar
Untuk mengawasi proses dari sistem
Perancangan Proses Sistem ini bisa digambarkan dengan :

Sistem Flowchart
DFD
dll
Proses
Real Time
Batch
Online
Offline

6.5. PERANCANGAN DATABASE
Penerapan database dalam sistem informasi disebut dengan database
system. Sistem basis data (database system) ini adalah suatu sistem
informasi yang mengintegrasikan kumpulan dari data yang saling
berhubungan satu dengan lainnya.
Tipe dari File

1. File Master
Berisi data yang tetap dimana pemrosesan terhadap data hanya pada
waktu-waktu tertentu.
Terdapat 2 tipe file master :

a. File Referensi
Data yang tetap, dimana pengolahan terhadap data tersebut
memerlukan waktu yang lama
b. File Dinamik
Data yang ada dalam file berubah tergantung transaksi
2. File Input / Transaksi

Berisi data masukan yang berupa data transaksi dimana data-data
tersebut akan diolah oleh komputer
3. File Laporan
Berisi informasi yang akan ditampilkan
4. File Sejarah / Arsip

Berisi data masa lalu yang sudah tidak aktif lagi, tetapi disimpan untuk
keperluan masa datang
5. File Backup / Pelindung

Berisi salinan data-data yang masih aktif di database pada suatu waktu
tertentu
6. File Kerja / Temporary File

Berisi data-data hasil pemrosesan yang bersifat sementara
7. File Library
Berisi program-program aplikasi atau utility program
Akses File :
Metode yang menunjukkan bagaimana suatu program komputer akan
membaca record-record dari suatu file.

File dapat diakses dengan 2 cara, yaitu :
Sequential (urut)
Direct / Random (langsung)
Organisasi File :
Pengaturan dari record secara logika didalam file dihubungkan satu dengan
yang lainnya.
File Urut (Sequential File)
Merupakan file dengan organisasi urut dengan pengaksesan urut pula
File Urut Berindex (Indexed Sequential File)
Merupakan file dengan organisasi urut dengan pengaksesan langsung
File Akses Langsung (Direct Acces File)
Merupakan file dengan organisasi acak dengan pengaksesan langsung
Alat Perancangan Database

ERD
Mapping
Normalisasi
Langkah-langkah Perancangan Database secara umum :

1. Menentukan kebutuhan file database untuk sistem baru
2. Menentukan parameter dari file database
6.6. PERANCANGAN KONTROL

Tujuannya agar keberadaan sistem setelah diimplementasi dapat memiliki
keandalan dalam mencegah kesalahan, kerusakan serta kegagalan
proses sistem.
Ancaman Sistem
Kesalahan manusia (lalai, kurang pelatihan)
Perangkat lunak yang bersifat merusak / menipu (Salami Technique,
Trojan Horse, Logic Bomb, Worm, Virus)
Penyadapan
Pengaksesan yang tidak sah
Perubahan / kehilangan database
Kegagalan landasan teknologi
Jenis Kontrol
Pencegahan
Pendeteksian
Pengkoreksian

6.7. PERANCANGAN JARINGAN
Langkah :
1. Membuat segmen bidang usaha (berdasarkan geografis, departemen,
bangunan, lantai, dsb)
2. Membuat sebuah model LAN
3. Mengevaluasi LAN untuk menentukan apakah mereka cocok untuk tiap
segmen diseluruh usaha
4. Interkoneksi segmen-segmen jaringan
Topologi :
Bus
Star
Ring
6.8. PERANCANGAN KOMPUTER

Kelompok Komputer :
Mainframe
Mini Komputer
Mikrokomputer
Device :
Input
Output
Proses
Penyimpanan
7. TEKANAN-TEKANAN PERANCANGAN
Perancangan Sistem Informasi harus memperhatikan sejumlah tekanan
desain (forces design) :
1. Integrasi (Integration)
2. Jalur Pemakai / Sistem (User / System Interface)
3. Tekanan Persaingan (Competitive Forces)
4. Kualitas dan kegunaan Informasi (Information Quality and Usability)
5. Kebutuhan-kebutuhan System (Systems Requirements)
6. Kebutuhan-kebutuhan Pengolahan Data (Data Processing Requirements)
7. Faktor-faktor Organisasi (Organizations Factors)
8. Kebutuhan-kebutuhan Biaya Efektifitas (Cost Effectiveness
Requirements)
9. Faktor-faktor Manusia (Human Factors)
10. Kebutuhan-Kebutuhan Kelayakan (Feasibility Requirements)

Lecture Notes : Sistem Informasi Data Flow Diagram
DATA FLOW DIAGRAM
1. KONSEP PERANCANGAN TERSTRUKTUR
Pendekatan perancangan terstruktur dimulai dari awal 1970.

Pendekatan terstruktur dilengkapi dengan alat-alat (tools) dan teknik-
teknik (techniques) yang dibutuhkan dalam pengembangan sistem,
sehingga hasil akhir dari sistem yang dikembangkan akan diperoleh
sistem yang strukturnya didefinisikan dengan baik dan jelas.
Melalui pendekatan terstruktur, permasalahan yang komplek di

organisasi dapat dipecahkan dan hasil dari sistem akam mudah untuk
dipelihara, fleksibel, lebih memuaskan pemakainya, mempunyai
dokumentasi yang baik, tepat waktu, sesuai dengan anggaran biaya
pengembangan, dapat meningkatkan produktivitas dan kualitasnya akan
lebih baik (bebas kesalahan)
2. DATA FLOW DIAGRAM (DFD)
Data Flow Diagram (DFD) adalah alat pembuatan model yang

memungkinkan profesional sistem untuk menggambarkan sistem
sebagai suatu jaringan proses fungsional yang dihubungkan satu sama
lain dengan alur data, baik secara manual maupun komputerisasi. DFD
ini sering disebut juga dengan nama Bubble chart, Bubble diagram,
model proses, diagram alur kerja, atau model fungsi.
DFD ini adalah salah satu alat pembuatan model yang sering digunakan,
khususnya bila fungsi-fungsi sistem merupakan bagian yang lebih
penting dan kompleks dari pada data yang dimanipulasi oleh sistem.
Dengan kata lain, DFD adalah alat pembuatan model yang memberikan
penekanan hanya pada fungsi sistem.
DFD ini merupakan alat perancangan sistem yang berorientasi pada

alur data dengan konsep dekomposisi dapat digunakan untuk
penggambaran analisa maupun rancangan sistem yang mudah
dikomunikasikan oleh profesional sistem kepada pemakai maupun
pembuat program.
Parno, SKom., MMSI Halaman 1 dari 17 Halaman

3. KOMPONEN DATA FLOW DIAGRAM
Menurut Yourdan dan DeMarco
Terminator Proses Data Store Alur Data
Menurut Gene dan Serson
Terminator Proses Data Store Alur Data
3.1. Komponen Terminator / Entitas Luar

Terminator mewakili entitas eksternal yang berkomunikasi dengan
sistem yang sedang dikembangkan. Biasanya terminator dikenal dengan
nama entitas luar (external entity).
Terdapat dua jenis terminator :

1. Terminator Sumber (source) : merupakan terminator yang menjadi
sumber.
2. Terminator Tujuan (sink) : merupakan terminator yang menjadi tujuan
data / informasi sistem.
Bagian
Penjualan
Terminator Sumber Terminator Tujuan T. Tujuan & Sumber
Terminator dapat berupa orang, sekelompok orang, organisasi,

departemen di dalam organisasi, atau perusahaan yang sama tetapi di
luar kendali sistem yang sedang dibuat modelnya.
Terminator dapat juga berupa departemen, divisi atau sistem di luar

sistem yang berkomunikasi dengan sistem yang sedang dikembangkan.

Komponen terminator ini perlu diberi nama sesuai dengan dunia luar
yang berkomunikasi dengan sistem yang sedang dibuat modelnya, dan
biasanya menggunakan kata benda, misalnya Bagian Penjualan,
Dosen, Mahasiswa.
Ada tiga hal penting yang harus diingat tentang terminator :

¶ Terminator merupakan bagian/lingkungan luar sistem. Alur data
yang menghubungkan terminator dengan berbagai proses sistem,
menunjukkan hubungan sistem dengan dunia luar.
¶ Profesional Sistem Tidak berhak mengubah isi atau cara kerja
organisasi atau prosedur yang berkaitan dengan terminator
¸ Hubungan yang ada antar terminator yang satu dengan yang lain
tidak digambarkan pada DFD.
3.2. Komponen Proses
Komponen proses menggambarkan bagian dari sistem yang

mentransformasikan input menjadi output.
Proses diberi nama untuk menjelaskan proses/kegiatan apa yang

sedang/akan dilaksanakan. Pemberian nama proses dilakukan dengan
menggunakan kata kerja transitif (kata kerja yang membutuhkan
obyek), seperti Menghitung Gaji, Mencetak KRS, Menghitung Jumlah
SKS.
Ada empat kemungkinan yang dapat terjadi dalam proses sehubungan

dengan input dan output :
1 input & 1 output 1 input & banyak output
Banyak input & 1 output Banyak input & banyak output

Ada beberapa hal yang perlu diperhatikan tentang proses :

¶ Proses harus memiliki input dan output.
· Proses dapat dihubungkan dengan komponen terminator, data store
atau proses melalui alur data.
¸ Sistem/bagian/divisi/departemen yang sedang dianalisis oleh
profesional sistem digambarkan dengan komponen proses.
Berikut ini merupakan suatu contoh proses yang salah :
1 2
Gambar 1. Contoh proses
Umumnya kesalahan proses di DFD adalah :

1. Proses mempunyai input tetapi tidak menghasilkan output. Kesalahan
ini disebut dengan black hole (lubang hitam), karena data masuk ke
dalam proses dan lenyap tidak berbekas seperti dimasukkan ke
dalam lubang hitam (lihat proses 1).
2. Proses menghasilkan output tetapi tidak pernah menerima input.
Kesalahan ini disebut dengan miracle (ajaib), karena ajaib dihasilkan
output tanpa pernah menerima input (lihat proses 2).
3.3. Komponen Data Store
Komponen ini digunakan untuk membuat model sekumpulan paket

data dan diberi nama dengan kata benda jamak, misalnya
Mahasiswa.
Data store ini biasanya berkaitan dengan penyimpanan-penyimpanan,

seperti file atau database yang berkaitan dengan penyimpanan secara
komputerisasi, misalnya file disket, file harddisk, file pita magnetik. Data
store juga berkaitan dengan penyimpanan secara manual seperti buku
alamat, file folder, dan agenda.

Suatu data store dihubungkan dengan alur data hanya pada komponen
proses, tidak dengan komponen DFD lainnya. Alur data yang
menghubungkan data store dengan suatu proses mempunyai pengertian
sebagai berikut :
• Alur data dari data store yang berarti sebagai pembacaan atau
pengaksesan satu paket tunggal data, lebih dari satu paket data,
sebagian dari satu paket tunggal data, atau sebagian dari lebih dari
satu paket data untuk suatu proses (lihat gambar 2 (a)).
• Alur data ke data store yang berarti sebagai pengupdatean data,

seperti menambah satu paket data baru atau lebih, menghapus satu
paket atau lebih, atau mengubah/memodifikasi satu paket data atau
lebih (lihat gambar 2 (b)).
Pada pengertian pertama jelaslah bahwa data store tidak berubah, jika
suatu paket data/informasi berpindah dari data store ke suatu proses.
Sebaliknya pada pengertian kedua data store berubah sebagai hasil alur
yang memasuki data store. Dengan kata lain, proses alur data
bertanggung jawab terhadap perubahan yang terjadi pada data store.
(a) (b)
Gambar 2. Implementasi data store
3.4. Komponen Data Flow / Alur Data
Suatu data flow / alur data digambarkan dengan anak panah, yang
menunjukkan arah menuju ke dan keluar dari suatu proses. Alur data ini
digunakan untuk menerangkan perpindahan data atau paket
data/informasi dari satu bagian sistem ke bagian lainnya.

Selain menunjukkan arah, alur data pada model yang dibuat oleh
profesional sistem dapat merepresentasikan bit, karakter, pesan,
formulir, bilangan real, dan macam-macam informasi yang berkaitan
dengan komputer. Alur data juga dapat merepresentasikan
data/informasi yang tidak berkaitan dengan komputer.
Alur data perlu diberi nama sesuai dengan data/informasi yang

dimaksud, biasanya pemberian nama pada alur data dilakukan dengan
menggunakan kata benda, contohnya Laporan Penjualan.
Ada empat konsep yang perlu diperhatikan dalam penggambaran alur

data, yaitu :
¶ Konsep Paket Data (Packets of Data)
Apabila dua data atau lebih mengalir dari suatu sumber yang sama
menuju ke tujuan yang sama dan mempunyai hubungan, dan harus
dianggap sebagai satu alur data tunggal, karena data itu mengalir
bersama-sama sebagai satu paket.
Nama
Periksa
Mahasiswa NPM Formulir
Daftar Ulang
Alamat
(a) Konsep paket data yang salah
Formulir Daftar Ulang Periksa

Mahasiswa Formulir
Daftar Ulang
(b) Konsep paket data yang benar
Gambar 3. Konsep paket data
· Konsep Alur Data Menyebar (Diverging Data Flow)

Alur data menyebar menunjukkan sejumlah tembusan paket data
yang yang berasal dari sumber yang sama menuju ke tujuan yang
berbeda, atau paket data yang kompleks dibagi menjadi beberapa
elemen data yang dikirim ke tujuan yang berbeda, atau alur data ini
membawa paket data yang memiliki nilai yang berbeda yang akan
dikirim ke tujuan yang berbeda.
Laporan
Penerimaan
Sehari-hari Manajer
Membuat
Pesanan Laporan
Pesanan Penerimaan
Sehari-hari
Bagian
Laporan Pembukuan
Penerimaan
Sehari -hari
Gambar 4. Konsep alur data menyebar
¸ Konsep Alur Data Mengumpul (Converging Data Flow)

Beberapa alur data yang berbeda sumber bergabung bersama-sama
menuju ke tujuan yang sama.
Membuat
Faktur Faktur
Slip Konsumen
Pengiriman
Membuat
Slip
Pengirim
an
Gambar 5. Konsep alur data mengumpul
¹ Konsep Sumber atau Tujuan Alur Data

Semua alur data harus minimal mengandung satu proses. Maksud
kalimat ini adalah :
q Suatu alur data dihasilkan dari suatu proses dan menuju ke suatu
data store dan/atau terminator (lihat gambar 6 (a)).

q Sutu alur data dihasilkan dari suatu data store dan/atau terminator
dan menuju ke suatu proses (lihat gambar 6 (b)).

q Suatu alur data dihasilkan dari suatu proses dan menuju ke suatu
proses (lihat gambar 6 (c)).

(a) (b)
(c)
Gambar 6. Konsep sumber atau tujuan alur data
4. BENTUK DATA FLOW DIAGRAM
Terdapat dua bentuk DFD, yaitu Diagram Alur Data Fisik, dan
Diagram Alur data Logika. Diagram alur data fisik lebih menekankan
pada bagaimana proses dari sistem diterapkan, sedangkan diagram alur
data logika lebih menekankan proses-proses apa yang terdapat di
sistem.
4.1. Diagram Alur Data Fisik (DADF)

DADF lebih tepat digunakan untuk menggambarkan sistem yang ada
(sistem yang lama). Penekanan dari DADF adalah bagaimana proses-
proses dari sistem diterapkan (dengan cara apa, oleh siapa dan
dimana), termasuk proses-proses manual.
Untuk memperoleh gambaran bagaimana sistem yang ada diterapkan,

DADF harus memuat :
1. Proses-proses manual juga digambarkan.
2. Nama dari alur data harus memuat keterangan yang cukup terinci
untuk menunjukkan bagaimana pemakai sistem memahami kerja
sistem.
3. Simpanan data dapat menunjukkan simpanan non komputer.
4. Nama dari simpanan data harus menunjukkan tipe penerapannya
apakah secara manual atau komputerisasi. Secara manual misalnya
dapat menunjukkan buku catatat, meja pekerja. Sedang cara
komputerisasi misalnya menunjukkan file urut, file database.
5. Proses harus menunjukkan nama dari pemroses, yaitu orang,

departemen, sistem komputer, atau nama program komputer yang
mengakses proses tersebut.
4.2. Diagram Alur Data Logika (DADL)
DADL lebih tepat digunakan untuk menggambarkan sistem yang akan

diusulkan (sistem yang baru). Untuk sistem komputerisasi,
penggambaran DADL hanya menunjukkan kebutuhan proses dari sistem
yang diusulkan secara logika, biasanya proses-proses yang
digambarkan hanya merupakan proses-proses secara komputer saja.
Konsumen Konsumen
Harga
Item-item
untuk dibeli Pembayaran Nota
Item & Jml yang

3 4
1 ID item 2 harga hrs dibayar
Menghit. Menetapkan
Identitas Melihat transaksi &
Item Total biaya
harga pesanan menerbitkan
nota
(a) Diagram Alur Data Fisik
Konsumen
Konsumen File trans.
File Harga Sementara
UPC
Item-item Item Item,harga, Tunai,cek, Nota kas
Untuk dibeli Kode Deskripsi item & & Subtotal kartu debit register
UPC dan harga hrg
UPC Item & Jml yang
3 4
1 Bar code 2 harga hrs dibayar Mengumpul-
Menghit.
Menscan Melihat kan uang &
Total
item harga memberi nota
biaya
(manual)
(b) Diagram Alur Data Logika
Gambar 7. DADF dan DADL

5. SYARAT-SYARAT PEMBUATAN DATA FLOW DIAGRAM
Syarat pembuatan DFD ini akan menolong profesional sistem untuk

menghindari pembentukkan DFD yang salah atau DFD yang tidak
lengkap atau tidak konsisten secara logika. Beberapa syarat pembutan
DFD dapat menolong profesional sistem untuk membentuk DFD yang
benar, menyenangkan untuk dilihat dan mudah dibaca oleh pemakai.
Syarat-syarat pembuatan DFD ini adalah :

1. Pemberian nama untuk tiap komponen DFD
2. Pemberian nomor pada komponen proses
3. Penggambaran DFD sesering mungkin agar enak dilihat
4. Penghindaran penggambaran DFD yang rumit
5. Pemastian DFD yang dibentuk itu konsiten secara logika
5.1. Pemberian Nama untuk Tiap komponen DFD

Seperti yang telah dijelaskan sebelumnya, komponen terminator
mewakili lingkungan luar dari sistem, tetapi mempunyai pengaruh
terhadap sistem yang sedang dikembangkan ini. Maka agar pemakai
mengetahui dengan lingkungan mana saja sistem mereka berhubungan,
komponen terminator ini harus diberi nama sesuai dengan lingkungan
luar yang mempengaruhi sistem ini. Biasanya komponen terminator
diberi nama dengan kata benda.
Selanjutnya adalah komponen proses. Komponen proses ini
mewakili fungsi sistem yang akan dilaksanakan atau menunjukkan
bagaimana fungsi sistem dilaksanakan oleh seseorang, sekelompok
orang atau mesin. Maka sangatlah jelas bahwa komponen ini perlu
diberi nama yang tepat, agar siapa yang membaca DFD khususnya
pemakai akan merasa yakin bahwa DFD yang dibentuk ini adalah model
yang akurat.
Pemberian nama pada komponen proses lebih baik menunjukkan

aturan-aturan yang akan dilaksanakan oleh seseorang dibandingkan
dengan memberikan nama atau identitas orang yang akan
melaksanakannya. Ada dua alasan mengapa bukan nama atau identitas
orang (yang melaksanakan fungsi sistem) yang digunakan sebagai
nama proses, yaitu :
À Orang tersebut mungkin diganti oleh orang lain saat mendatang,

sehingga bila tiap kali ada pergantian orang yang melaksanakan
fungsi tersebut, maka sistem yang dibentuk harus diubah lagi.

Á Orang tersebut mungkin tidak melaksanakan satu fungsi sistem saja,

melainkan beberapa fungsi sistem yang berbeda. Daripada
menggambarkan beberapa proses dengan nama yang sama tetapi
artinya berbeda, lebih baik tunjukkan dengan tugas/fungsi sistem
yang sebenarnya akan dilaksanakan.
Karena nama untuk komponen proses lebih baik menunjukkan

tugas/fungsi sistem yang akan dilaksanakan, maka lebih baik pemberian
nama ini menggunakan kata kerja transitif.
Pemberian nama untuk komponen data store menggunakan kata benda,

karena data store menunjukkan data apa yang disimpan untuk
kebutuhan sistem dalam melaksanakan tugasnya. Jika sistem sewaktu-
waktu membutuhkan data tersebut untuk melaksanakan tugasnya, maka
data tersebut tetap ada, karena sistem menyimpannya.
Begitu pula untuk komponen alur data, namanya lebih baik diberikan
dengan menggunakan kata benda. Karena alur data ini menunjukkan
data dan infiormasi yang dibutuhkan dan yang dikeluarkan oleh sistem
dalam pelaksanaan tugasnya.
5.2. Pemberian Nomor pada Komponen Proses

Biasanya profesional sistem memberikan nomor dengan bilangan terurut
pada komponen proses sebagai referensi. Tidak jadi masalah
bagaimana nomor-nomor proses ini diberikan. Nomor proses dapat
diberikan dari kiri ke kanan, atau dari atas ke bawah, atau dapat pula
dilakukan dengan pola-pola tertentu selama pemberian nomor ini tetap
konsisten pada nomor yang dipergunakan.
R 1
S X
2
3
W
Y
Z T
Gambar 8. Contoh Pemberian nomor pada proses

Nomor-nomor proses yang diberikan terhadap komponen proses ini

tidak dimaksudkan bahwa proses tersebut dilaksanakan secara
berurutan. Pemberian nomor ini dimaksudkan agar pembacaan suatu
proses dalam suatu diskusi akan lebih mudah dengan hanya
menyebutkan prosesnya saja jika dibandingkan dengan menyebutkan
nama prosesnya, khususnya jika nama prosesnya panjang dan sulit.
Maksud pemberian nomor pada proses yang lebih penting lagi adalah
untuk menunjukkan referensi terhadap skema penomoran secara hirarki
pada levelisasi DFD. Dengan kata lain, nomor proses ini merupakan
dasar pemberian nomor pada levelilasi DFD (lihat gambar 11).
5.3. Penggambaran DFD sesering mungkin

Penggambaran DFD dapat dilakukan berkali-kali sampai secara teknik
DFD itu benar, dapat diterima oleh pemakai, dan sudah cukup rapih
sehingga profesional sistem tidak merasa malu untuk menunjukkan DFD
itu kepada atasannya dan pemakai.
Dengan kata lain, penggambaran DFD ini dilakukan sampai terbentuk

DFD yang enak dilihat, dan mudah dibaca oleh pemakai dan profesional
sistem lainnya. Keindahan penggambaran DFD tergantung pada
standar-standar yang diminta oleh organisasi tempat profesional sistem
itu bekerja dan perangkat lunak yang dipakai oleh profesional sistem
dalam membuat DFD.
Penggambaran yang enak untuk dilihat dapat dilakukan dengan

memperhatikan hal-hal berikut ini :
Ø Ukuran dan bentuk proses.

Beberapa pemakai kadang-kadang merasa bingung bila ukuran
proses satu berbeda dengan proses yang lain. Mereka akan mengira
bahwa proses dengan ukuran yang lebih besar akan diduga lebih
penting dari proses yang lebih kecil. Hal ini sebenarnya hanya karena
nama proses itu lebih panjang dibandingkan dengan proses yang
lain. Jadi, sebaiknya proses yang digambarkan memiliki ukuran dan
bentuk yang sama.
Ø Alur data melingkar dan alur data lurus.

Alur data dapat digambarkan dengan melingkar atau hanya garis
lurus. Mana yang lebih enak dipandang tergantung siapa yang akan
melihat DFD tersebut.

(a). Alur data dengan garis lurus (b). Alur data dengan melingkar
Gambar 9
Ø DFD dengan gambar tangan dan gambar menggunakan mesin.

DFD dapat digambarkan secara manual atau dengan menggunakan
bantuan mesin, tergantung pilihan pemakai atau profesional sistem.
5.4. Penghindaran Penggambaran DFD yang rumit

Tujuan DFD adalah untuk membuat model fungsi yang harus
dilaksanakan oleh suatu sistem dan interaksi antar fungsi. Tujuan
lainnya adalah agar model yang dibuat itu mudah dibaca dan dimengerti
tidak hanya oleh profesional sistem yang membuat DFD, tetapi juga oleh
pemakai yang berpengalaman dengan subyek yang terjadi. Hal ini
berarti DFD harus mudah dimengerti, dibaca, dan menyenangkan untuk
dilihat.
Pada banyak masalah, DFD yang dibuat tidak memiliki terlalu banyak
proses (maksimal enam proses) dengan data store, alur data, dan
terminator yang berkaitan dengan proses tersebut dalam satu diagram.
Bila terlalu banyak proses, terminator, data store, dan alur data
digambarkan dalam satu DFD, maka ada kemungkinan terjadi banyak
persilangan alur data dalam DFD tersebut. Persilangan alur data ini
menyebabkan pemakai akan sulit membaca dan mengerti DFD yang
terbentu. Jadi semakin sedikit adanya persilangan data pada DFD, maka
makin baik DFD yang dibentuk oleh profesional sistem.
Persilangan alur data ini dapat dihindari dengan menggambarkan DFD

secara bertingkat-tingkat (levelisasi DFD), atau dengan menggunakan
pemakaian duplikat terhadap komponen DFD.
Komponen DFD yang dapat menggunakan duplikat hanya komponen

store dan terminator. Pemberian duplikat ini juga tidak dapat diberikan
sesuka profesional sistem yang membuat DFD, tetapi makin sedikit
pemakaian duplikat, makin baik DFD yang terbentuk.

Pemberian duplikat terhadap data store dilakukan dengan memberikan

simbol garis lurus (x) atau asterik (*), sedangkan untuk terminator
menggunakan simbol garis miring (/) atau asterik (*). Banyaknya
pemberian simbol duplikat pada duplikat yang digunakan tergantung
banyaknya duplikat yang digunakan.
At atau * *
T1 T1 T1 T1
(a)
** ** **
T1 T1 T1 atau T1 T1 T1
(b)
Gambar 10. Contoh pemakaian simbol duplikat pada terminator

(a) Satu duplikat yang digunakan (b) Dua duplikat yang digunakan
5.5. Penggambaran DFD yang Konsisten

Penggambaran DFD harus konsisten terhadap kelompok DFD lainnya.
Profesional sistem menggambarkan DFD berdasarkan tingkatan DFD
dengan tujuan agar DFD yang dibuatnya itu mudah dibaca dan
dimengerti oleh pemakai sistem. Hal ini sesuai dengan salah satu tujuan
atau syarat membuat DFD.
6. PENGGAMBARAN DFD
Tidak ada aturan baku untuk menggambarkan DFD. Tapi dari berbagai
referensi yang ada, secara garis besar langkah untuk membuat DFD
adalah :
1. Identifikasi terlebih dahulu semua entitas luar yang terlibat di sistem.
2. Identifikasi semua input dan output yang terlibat dengan entitas luar.
3. Buat Diagram Konteks (diagram context)

Diagram ini adalah diagram level tertinggi dari DFD yang
menggambarkan hubungan sistem dengan lingkungan luarnya.
Caranya :
q Tentukan nama sistemnya.

q Tentukan batasan sistemnya.
q Tentukan terminator apa saja yang ada dalam sistem.
q Tentukan apa yang diterima/diberikan terminator dari/ke sistem.
q Gambarkan diagram konteks.
4. Buat Diagram Level Zero

Diagram ini adalah dekomposisi dari diagram konteks. Caranya :
q Tentukan proses utama yang ada pada sistem.
q Tentukan apa yang diberikan/diterima masing-masing proses
ke/dari sistem sambil memperhatikan konsep keseimbangan (alur

data yang keluar/masuk dari suatu level harus sama dengan alur
data yang masuk/keluar pada level berikutnya).
q Apabila diperlukan, munculkan data store (master) sebagai
sumber maupun tujuan alur data.

q Gambarkan diagram level zero.
- Hindari perpotongan arus data
- Beri nomor pada proses utama (nomor tidak menunjukkan
urutan proses).
5. Buat Diagram Level Satu

Diagram ini merupakan dekomposisi dari diagram level zero.
Caranya :
q Tentukan proses yang lebih kecil (sub-proses) dari proses utama
yang ada di level zero.
q Tentukan apa yang diberikan/diterima masing-masing sub-proses
ke/dari sistem dan perhatikan konsep keseimbangan.
q Apabila diperlukan, munculkan data store (transaksi) sebagai
sumber maupun tujuan alur data.
q Gambarkan DFD level Satu
- Hindari perpotongan arus data.

- Beri nomor pada masing-masing sub-proses yang menunjukkan
dekomposisi dari proses sebelumnya.
Contoh : 1.1, 1.2, 2.1
6. DFD Level Dua, Tiga, …

Diagram ini merupakan dekomposisi dari level sebelumnya. Proses
dekomposisi dilakukan sampai dengan proses siap dituangkan ke
dalam program. Aturan yang digunakan sama dengan level satu.

a 0 d
Sistem
b
ds1
a 1
e 2 d
4 f
g c
3
ds1
h 3.2
i f
3.1
b
j
k 3.3
3.4 c
ds1
Gambar 11. Levelisasi DFD

Pada gambar 11 terlihat bahwa Proses 0 diuraikan lagi ke dalam empat

proses, penguraian ini digambarkan pada diagram Figure 0, sedangkan
Proses 2 diuraikan kembali menjadi tiga proses yang digambarkan pada
diagram Figure 2. Penguraian ini juga diikuti oleh alur data yang
berkaitan dengan tiap proses yang diuraikan. Alur data yang berkaitan
dengan tiap proses yang diuraikan dikenal dengan Alur data global.
Jadi pada balancing DFD yang perlu diperhatikan adalah jumlah alur
data global pada suatu level harus sama pada level berikutnya.
Ada beberapa hal yang perlu diperhatikan dalam penggambaran

levelisasi DFD, yaitu :
¶ Dalam diagram konteks, ada beberapa hal yang perlu diperhatikan
seperti hubungan sistem dengan dunia luar yang mempengaruhinya,
penggambaran sistem dalam satu proses, dan penggambaran data
store (optional) yang dikenal dengan data store eksternal atau data
store master. Data store eksternal ini maksudnya adalah data store
itu dihasilkan oleh sistem yang sedang dianalisis, tetapi digunakan
oleh sistem lain, atau data store itu dihasilkan oleh sistem lain tetapi
digunakan oleh sistem yang sedang dianalisis.
Sistem
Gambar 12. Contoh penggambaran diagram konteks
· Balancing (kesimbangan) dalam penggambaran levilisasi DFD perlu

diperhatikan. Balancing DFD ini maksudnya keseimbangan antara
alur data yang masuk/keluar dari suatu level harus sama dengan alur
data yang masuk/keluar pada level berikutnya (lihat gambar 11).

FLOWCHART
Flowchart adalah penggambaran secara grafik dari langkah-langkah dan

urut-urutan prosedur dari suatu program.
Flowchart terbagi atas lima jenis, yaitu :
 Flowchart Sistem (System Flowchart)

Flowchart Sistem merupakan bagan yang menunjukkan alur kerja atau
apa yang sedang dikerjakan di dalam sistem secara keseluruhan dan
menjelaskan urutan dari prosedur-prosedur yang ada di dalam sistem.
 Flowchart Paperwork / Flowchart Dokumen (Document Flowchart)

Kegunaan utamanya adalah untuk menelusuri alur form dan laporan
sistem dari satu bagian ke bagian lain baik bagaimana alur form dan
laporan diproses, dicatat dan disimpan.
 Flowchart Skematik (Schematic Flowchart)

Flowchart Skematik mirip dengan Flowchart Sistem yang
menggambarkan suatu sistem atau prosedur.
Flowchart Skematik ini juga menggunakan gambar-gambar komputer,
peripheral, form-form atau peralatan lain yang digunakan dalam
sistem.
 Flowchart Program (Program Flowchart)

Flowchart Program merupakan keterangan yang lebih rinci tentang
bagaimana setiap langkah program atau prosedur sesungguhnya dilaksanakan.
 Flowchart Proses (Process Flowchart)

Flowchart Proses merupakan teknik penggambaran rekayasa
industrial yang memecah dan menganalisis langkah-langkah
selanjutnya dalam suatu prosedur atau sistem.

FLOWCHART SISTEM
Pesanan
Pesanan
Pembelian
Pembelian
Masukan
Masukan
Pesanan
Pesanan
Pembelian
Pembelian
Informasi
Pesanan
Pembelian
Tentukan
Jumlah
Pesanan
Laporan
Jumlah
Pesanan
Keluarkan
Pesanan
Gambar 1. Flowchart Sistem

3.2. FLOWCHART PAPERWORK / FLOWCHART DOKUMEN
FLOW DOKUMEN SISTEM BARU CALON ANGGOTA PERPUSTAKAAN
ANGGOTA ADMINISTRASI KEPALA PERPUSTAKAAN
# #
Formulir Formulir Kartu
Anggota
#
Kartu
Anggota P
Pengisian
Formulir
# #
Kartu
Anggota
#
Formulir #
Kartu
Anggota
Kartu Anggota
#
Formulir
KETERANGAN :
# : Masukkan data calon anggota ke dalam komputer (proses pengisian data)
P : Tanda tangan dan validasi data
Gambar 2. Flowchart Paperwork
3.3. FLOWCHART SKEMATIK

3.4. FLOWCHART PROGRAM
Suatu contoh flowchart program dapat dilihat pada Gambar 3. berikut ini :
Start
Catatan :
Baca Bahwa flowchart program ini
Data adalah rincian dari sistem
Pesanan flowchart ( Gambar 1.) untuk
Pembelian kotak yang bernama “Tentukan
Jumlah Pesanan”
X=2xAxP
Y=RxC Untuk Menentukan Jumlah

Pesanan :
Jumlah Pesanan =
Z= X/Y 2AP
RC
Dimana :
A = Biaya setahun
Jumlah Pesanan =
P = Pemakaian setahun
R = Biaya sekali pesan
z
C = Biaya penyimpanan
Cetak
Jumlah &
Item
Pesanan
T EOF
Stop
Gambar 3. Flowchart Program

3.5. FLOWCHART PROSES
Flowchart Proses memiliki lima simbol khusus (lihat Gambar 4)
PROSEDUR PEMBELIAN | Analis : Tuti S. | Hal : 1 dari 3
RINCIAN METODE Perpin

Operasi dahan Inspeksi Penundaan File
Departemen Pembelian mengetik pesanan penjualan.

Pesanan ini merupakan form dengan 4 tembusan / copy.
Departemen Pembelian menyimpan copy ke-4 sebagai

referensi.
Pabrik menerima copy ke-1.
Departemen Penerimaan barang memperoleh copy ke-2.
Departemen Penerimaan barang menyimpan copy ke-2

sampai barang-barang diterima.
Departemen Kredit menerima copy ke-3.
Departemen Kredit menyimpan copy ke-3 sampai copy ke-2

dikirim oleh Departemen Penerimaan barang.
Departemen Kredit menerima copy ke-2 dari Departemen

Penerimaan barang.
Gambar 5. Flowchart Proses

4. SIMBOL-SIMBOL FLOWCHART
SIMBOL ARTI CONTOH
Input / Output
Merepresentasikan Input data atau
Output data yang diproses atau Baca Jam
Informasi. & Tarif
Upah
Proses
Mempresentasikan operasi Hitung

Upah Kotor
Penghubung
Keluar ke atau masuk dari bagian lain 3 Keluar
flowchart khususnya halaman yang
sama
3 Masuk
Anak Panah
Merepresentasikan alur kerja
Hitung
Upah Kotor
Penjelasan
Digunakan untuk komentar tambahan
Urutkan Berdasarkan
Sebelum No.
Pembayaran Pelanggan

Gambar 6. Simbol Flowchart Standar
SIMBOL ARTI CONTOH
Keputusan
Keputusan dalam program
Apakah
< A < B >
=
>
Predefined
Process
Rincian operasi berada di tempat
lain Hitung Akar
Pangkat Dua
Preparation
Pemberian harga awal
SW = 1
Terminal
Points Awal / akhir flowchart
Start
Punched card
Input / outuput yang menggunakan Kartu Absen
kartu berlubang

SIMBOL ARTI CONTOH
Dokumen
I/O dalam format yang dicetak
Cetak
Slip Upah
Magnetic Tape
I/O yang menggunakan pita
magnetik File
Upah
Magnetic Disk
I/O yang menggunakan disk
magnetik
Update
File
Pegawai
Magnetic Drum
I/O yang menggunakan drum
magnetik
File
Pegawai
Gambar 6. Lanjutan

SIMBOL ARTI CONTOH
On-line Storage
I/O yang menggunakan
penyimpanan akses
langsung File
Pelanggan
Punched Tape
I/O yang menggunakan pita
kertas berlubang
File Pelanggan
Manual Input
Input yang dimasukkan
secara manual dari
keyboard Masukkan
Tarif Upah
Display
Output yang ditampilkan
pada terminal
Pesan
Kesalahan
Manual Operation
Operasi Manual
Ketik
Pesanan
Penjualan
Gambar 6. Lanjutan

SIMBOL ARTI CONTOH
Communication
Link Transmisi data melalui
channel komunikasi, seperti Terminal
telepon Komputer
Off-line Storage
Penyimpanan yang tidak
dapat diakses oleh
komputer secara langsung
Gambar 6. Lanjutan

PERANCANGAN BERORIENTASI OBJEK
1. PENDAHULUAN
Analisis dan disain berorientasi objek adalah cara baru dalam

memikirkan suatu masalah dengan menggunakan model yang dibuat
menurut konsep sekitar dunia nyata. Dasar pembuatan adalah objek,
yang merupakan kombinasi antara struktur data dan perilaku dalam
satu entitas.
Pengertian "berorientasi objek" berarti bahwa kita mengorganisasi

perangkat lunak sebagai kumpulan dari objek tertentu yang memiliki
struktur data dan perilakunya.
1.1. Karakteristik dari Objek
Objek
 Identitas berarti bahwa data diukur mempunyai nilai tertentu yang
membedakan entitas disebut Objek.
 Objek dapat kongkrit, seperti halnya arsip dalam sistem, atau
konseptual seperti kebijakan penjadualan dalam multiprocessing
pada sistem operasi.
 Setiap objek mempunyai sifat yang melekat pada identitasnya.
 Dua objek dapat berbeda walaupun bila semua nilai atributnya
identik.
Mobil Singa
NoPeg Nama
96001 Susan
96002 David
97001 Shila
Tabel
Gambar 1. Macam-macam Objek

Kelas Objek
 Kelas merupakan gambaran sekumpulan Objek yang terbagi
dalam atribut, operasi, metode, hubungan, dan makna yang
sama.
 Suatu kegiatan mengumpulkan data (atribut) dan perilaku
(operasi) yang mempunyai struktur data sama ke dalam satu grup.
 Kelas Objek merupakan wadah bagi Objek. Dapat digunakan
untuk menciptakan Objek.
 Objek mewakili fakta/keterangan dari sebuah kelas.
Objek Poligon Kelas Poligon
Atribut
titik sudut
batas
warna
Operasi
gambar
hapus
translasi
Gambar 2. Kelas dan Objek
Istilah-istilah Objek
 Atribut : Data item yang menegaskan Objek
 Operasi : Fungsi di dalam kelas yang dikombinasikan ke bentuk
tingkah laku kelas
 Metode : Pelaksanaan prosedur (badan dari kode yang
mengeksekusi respon terhadap permintaan objek lain di
dalam sistem).
1.2. Karakteritik Metodologi Berorientasi Objek
Metodologi pengembangan sistem berorientasi objek mempunyai tiga

karakteristik utama :
 Encapsulation
 Inheritance
 Polymorphism
A. ENCAPSULATION (PENGKAPSULAN)
 Encapsulation merupakan dasar untuk pembatasan ruang lingkup
program terhadap data yang diproses.
 Data dan prosedur atau fungsi dikemas bersama-sama dalam
suatu objek, sehingga prosedur atau fungsi lain dari luar tidak
dapat mengaksesnya.
 Data terlindung dari prosedur atau objek lain, kecuali prosedur
yang berada dalam objek itu sendiri.
B. INHERITANCE (PEWARISAN)
 Inheritance adalah teknik yang menyatakan bahwa anak dari objek
akan mewarisi data/atribut dan metode dari induknya langsung.
Atribut dan metode dari objek dari objek induk diturunkan kepada
anak objek, demikian seterusnya.
 Inheritance mempunyai arti bahwa atribut dan operasi yang dimiliki
bersama di anatara kelas yang mempunyai hubungan secara
hirarki.
 Suatu kelas dapat ditentukan secara umum, kemudian ditentukan
spesifik menjadi subkelas. Setiap subkelas mempunyai hubungan
atau mewarisi semua sifat yang dimiliki oleh kelas induknya, dan
ditambah dengan sifat unik yang dimilikinya.
 Kelas Objek dapat didefinisikan atribut dan service dari kelas
Objek lainnya.
 Inheritance menggambarkan generalisasi sebuah kelas
Contoh :
- Sedan dan Sepeda Motor adalah subkelas dari Kendaraan
Bermotor.
- Kedua subkelas mewarisi sifat yang dimiliki oleh Kendaraan
Bermotor, yaitu mempunyai mesin dan dapat berjalan.
- Kedua subkelas mempunyai sifat masing-masing yang
berbeda, misalnya jumlah roda, dan kemampuan untuk berjalan
mundur yang tidak dimiliki oleh sepeda motor.
C. POLYMORPHISM (POLIMORFISME)
 Polimorfisme yaitu konsep yang menyatakan bahwa seuatu yang
sama dapat mempunyai bentuk dan perilaku berbeda.
 Polimorfisme mempunyai arti bahwa operasi yang sama mungkin
mempunyai perbedaan dalam kelas yang berbeda.

 Kemampuan objek-objek yang berbeda untuk melakukan metode
yang pantas dalam merespon message yang sama.
 Seleksi dari metode yang sesuai bergantung pada kelas yang
seharusnya menciptakan Objek.
2. PEMODELAN BERORIENTASI OBJEK
2.1 . Pemodelan Sebagai Teknik Desain

Teknik pemodelan objek menggunakan tiga macam model untuk
menggambarkan sistem :
A. Model Objek
B. Model Dinamik
C. Model Fungsional
A. Model Objek :
 Model objek Menggambarkan struktur statis dari suatu objek
dalam sistem dan relasinya
 Model objek berisi diagram objek. Diagram objek adalah graph
dimana nodenya adalah kelas yang mempunyai relasi antar kelas.
B. Model Dinamik
 Model dinamik menggambarkan aspek dari sistem yang berubah
setiap saat.
 Model dinamik dipergunakan untuk menyatakan aspek kontrol dari
sistem.
 Model dinamik berisi state diagram. State diagram adalah graph
dimana nodenya adalah state dan arc adalah tarnsisi antara state
yang disebabkan oleh event.
C. Model Fungsional
 Model fungsional menggambrakan transformasi nilai data di dalam
sistem.
 Model fungsional berisi data flow diagram. DFD adalah suatu
graph dimana nodenya menyatakan proses dan arcnya adalah
aliran data.
2.2. Model Berorientasi Objek

Sebuah model objek menangkap struktur statis dari sistem dengan
menggambarkan objek dalam sistem, hubungan antara objek, serta

atribut dan operasi yang merupakan karakteristik setiap kelas dan
objek.
Model berorientasi objek lebih mendekati keadaan nyata, dan
dilengkapi dengan penyajian grafis dari sistem yang sangat
bermanfaat untuk komunikasi dengan user dan pembuatan
dokumentasi struktur dari sistem.
A. Objek dan Kelas
Objek
 Objek didefinisikan sebagai konsep, abstraksi atau benda dengan
batasan dan arti untuk suatu masalah.
 Semua objek mempunyai identitas yang berbeda dengan lainnya.
Istilah identitas berarti bahwa objek dibedakan oelh sifat yang
melekat dan bukan dengan uraian sifat yang dimilikinya.
Contohnya, kembar identik, walaupun mereka nampak seperti
sama, tetapi merupakan dua orang yang berbeda.
 Kadang-kadang objek berarti suatu barang, maka digunakan
istilah object instance, dan object class untuk menunjukkan satu
grup dari barang yang sama.
Kelas
 Suatu object class menggambarkan kumpulan dari objek yang
mempunyai sifat (atribut), perilaku umum (operasi), relasi umum
dengan objek lain dan semantik umum.
Contoh : Orang, perusahaan , binatang, proses adalah objek.
Setiap orang mempunyai umur, IQ, dan mungkin pekerjaan. Setiap
proses mempunyai pemilik, prioritas, list dari sumber daya yang
dibutuhkan.
 Objek dan object class sering sama sebagai benda dalam
deskripsi masalah.
B. Diagram Objek
Diagram objek melengkapi notasi grafik untuk pemodelan objek,

kelas dan relasinya dengan yang lain. Diagram objek bermanfaat
untuk pemodelan abstrak dan membuat perancangan program.

Kelas dan Objek
Konsep fundamental dalam analisis berorientasi objek adalah objek
itu sendiri. Sebuah objek adalah sebuah entitas yang mencakup data
dan metode.
Kelas merupakan satu atau lebih objek dengan persamaan atribut

dan metode, sedangkan kelas-&-objek adalah kelas dengan satu
atau lebih objek di dalamnya. Nama kelas adalah kata benda
tunggal, atau kata sifat dan kata benda. Nama dari kelas-&-objek
harus dapat menjelaskan objek tunggal dari suatu kelas.
nama kelas nama

kelas-&-objek
atribut atribut
metode metode
kelas kelas dengan objek
Gambar 3. Notasi untuk kelas dan kelas-&-objek
Struktur Objek dan Hirarki Kelas

Struktur kelas dibagi dua macam, yaitu Whole-Part Structure dan
Gen-Spec Structure.
Whole-Part Structure memperlihatkan hirarki dari suatu kelas

sebagai komponen dari kelas lain yang disebut juga sub objek.
Contohnya, kelas Mobil adalah Whole dan komponennya Mesin,

Rangka, dll merupakan Part1, Part 2, …, Partn.

WHOLE
PART 1 PART n
  
Gambar 4. Notasi untuk whole-part structure
Gen-Spec Structure memperlihatkan kelas sebagai spesialisasi dari

kelas di atasnya. Kelas yang mempunyai sifat umum disebut
Generalization, Superclass atau Topclass, sedangkan kelas yang
mempunyai sifat khusus disebut Specialization.
GENERALIZATION
SPECIALIZATION SPECIALIZATION n
  

Gambar 5. Notasi untuk gen-spec structure
Contohnya, kelas Mobil adalah Generalization, sedangkan Sedan,
Truk, Minibus, dll merupakan Specizlization1, Specialization2, …,
Specializationn, yaitu kelas yang mempunyai sifat khusus.
Atribut
Atribut menggambarkan data yang dapat memberikan informasi
mengenai kelas atau objek dimana atribut tersebut berada.
nama DOKUMEN
kelas-&-objek
nomor
atribut 1 judul
. sumber
atribut n tanggal
Notasi Contoh
Gambar 6. Notasi untuk atribut
Metode
Metode (method) disebut juga service atau operator adalah prosedur
atau fungsi seperti yang terdapat dalam bahasa Pascal pada
umumnya, tetapi cara kerjanya agak berlainan. Metode adalah
subprogram yang tergabung dalam objek bersama-sama dengan
atribut. Metode dipergunakan untuk pengaksesan terhadap data yang
terdapat dalam objek tersebut.
nama DOKUMEN
kelas-&-objek
Metode 1 Tampil teks

. Tampil peta
metode n Tampil foto
Notasi Contoh
Gambar 7. Notasi untuk metode
Pesan (Message)
Message merupakan cara untuk berhubungan antara satu objek
dengan objek lain. Suatu pesan dikirimkan oleh suatu objek kepada
objek tertentu dapat digambarkan dengan anak panah.
nama nama
kelas-&-objek kelas-&-objek
message
atribut atribut
metode metode
Gambar 8. Notasi untuk message
3. ANALISIS BERORIENTASI OBJEK
3.1. Pendekatan Berorientasi Objek
A. Dasar
Metode berorientasi objek dapat digambarkan sebagai berikut :
Berorientasi objek = Kelas dan Objek

+ Inheritance
+ Komunikasi dengan message
B. Prinsip
Analisis Berorientasi Objek berdasarkan pada aplikasi yang
mempunyai bentuk sama untuk mengatur kompleksitas :
1. Abstraksi
a. Prosedural
b. Data
2. Pengkapsulan
3. Pewarisan
4. Asosiasi
5. Hubungan dengan message
6. Meliputi metode dari organisasi
a. Objek
b. Whole – part
c. Kelas dan anggota, dan perbedaan diantaranya
7. Skala
8. Kategori dari perilaku
a. Penyebab yang mendadak
b. Perubahan dari waktu ke waktu
c. Kesamaan fungsi
C. Pendekatan
Analisis Berorientasi Objek memiliki lima aktivitas utama dalam
pendekatannya, yaitu :
1. Menentukan Kelas-&-Objek
2. Identifikasi Struktur
3. Identifikasi Subyek
4. Menentukan Atribut
5. Menentukan Metode
D. Tujuan dan Keuntungan

Terdapat tujuh macam tujuan dan keuntungan dari Analisis
Berorientasi Objek, yaitu
3.2. Contoh Kasus

OBJECT ORIENTED ANALYSIS AND DESIGN (OOAD)
Object Oriented analaysis adalah metode analisis yang memeriksa

reqirements (syarat/keperluan yang harus dipenuhi suatu sistem) dari
sudut pandang kelas-kelas dan objek-objek yang ditemui dalam
ruang lingkup permasalahan.
Object Oriented Design adalah metode untuk mengarahkan

arsitektur software yang didasarkan pada manipulasi objek-objek
sistem atau subsistem.
Beberapa Konsep Dasar dalam OOAD
Objek
Objek (object) adalah “benda”, secara fisik atau konseptual.
Contoh : hardware, software, dokumen, manusia, dan konsep.
Untuk kepentingan memodelkan perusahaannya, seorang
kepala eksekutif akan melihat karyawan, gedung, divisi,
dokumen, dan keuntungan sebagai objek.
Sebuah objek memiliki keadaan sesaat (state) dan perilaku

(behavior).
State dari sebuah objek adalah kondisi objek tersebut atau himpunan
dari keadaan yang menggambarkan objek tersebut. Sebagai contoh,
bola lampu adalah objek, dan salah satu keadaan nyala atau tidak
adalah state dari objek bola lampu tersebut.
State dinyatakan dengan nilai atribut objeknya. Atribut adalah nilai

internal suatu objek yang mencerminkan antara lain karakteristik
objek, kondisi sesaat, koneksi dengan objek lain, dan identitas.
Perubahan state dicerminkan oleh perilaku (behavior) objek tersebut.
Behavior suatu objek mendefinisikan bagaimana sebuah objek

bertindak (beraksi) dan memberi reaksi. Behavior ditentukan oleh
himpunan semua atau beberapa operasi yang dapat dilakukan dalam
objek itu sendiri. Behavior dari sebuah objek dicerminkan oleh
interface, service, dan metode dari objek tersebut.

Interface adalah pintu untuk mengakses service objek. Service
adalah fungsi yang bisa diemban objek. Metode adalah mekanisme
internal objek yang mencerminkan perilaku (behavior) objek tersebut.
Sebagai contoh, jika printer merupakan sebuah objek, maka perilaku
(behavior) atau service-nya mencetak apapu yang dia terima.
Kelas
Kelas adalah definisi umum (pola, template atau cetak biru) untuk
himpunan objek sejenis. Kelas menetapkan spesifikasi perilaku
(behavior) dan atribut objek-objek tersebut. Kelas adalah keniskalan
(abstraksi) dari entitas dalam dunia nyata. Objek adalah “contoh”
(instance) dari sebuah kelas. Sebagai contoh, atribut untuk kelas
binatang adalah berkaki empat dan memiliki ekor. Perilakunya adalah
tidur dan makan. “Contoh” (instance) yang mungkin dari kelas
binatang ini adalah kucing, gajah, dan kuda.
Keunggulan Object Oriented

 Programmer dapat mendesain program dalam bentuk objek-objek
dan hubungan antar objek tersebut untuk kemudian dimodelkan
dalam sistem nyata.
 Proses pembuatan software dapat dilakukan dengan lebih cepat
karena software dibangun dari objek-objek standar, dapat
menggunakan ulang model yang ada, dan dapat membuat model
dengan cepat melalui metodologi. Kualitas yang tinggi dari
software dapat dicapai karena adanya tested components.
 Lebih mudah dalam maintenance karena perbaikan kode hanya
diperlukan pada satu tempat (bukan diurut dari awal).
 Mudah dalam membangun sistem yang besar karena subsistem
dapat dibuat dan diuji secara terpisah. Mengubah sistem yang
sudah ada tidak memerlukan membangun ulang keseluruhan
sistem.
Bahasa Pemrograman yang Menggunakan Object Oriented

Terdapat berbagai bahasa pemrograman yang menggunakan OO
sekarang ini, diantaranya yang terkenal adalah SmallTalk, C++,
Visual Basic, dan Java.

Unified Modeling Language (UML)
Pendahuluan
UML (Unified Modeling Language) adalah sebuah bahasa yang

berdasarkan grafik/gambar untuk memvisualisasi, menspesifikasikan,
membangun, dan pendokumentasian dari sebuah sistem
pengembangan software berbasis OO (Object-Oriented).
UML sendiri juga memberikan standar penulisan sebuah sistem blue

print, yang meliputi konsep bisnis proses, penulisan kelas-kelas dalam
bahasa program yang spesifik, skema database, dan komponen-
komponen yang diperlukan dalam sistem software
UML adalah salah satu tool / model untuk merancang pengembangan

software yang berbasis object oriented
UML sebagai sebuah bahasa yang memberikan vocabulary dan tatanan

penulisan kata-kata dalam ‘MS Word’ untuk kegunaan komunikasi.
Sebuah bahasa model adalah sebuah bahasa yang mempunyai
vocabulary dan konsep tatanan / aturan penulisan serta secara fisik
mempresentasikan dari sebuah sistem.
UML adalah sebuah bahasa standard untuk pengembangan sebuah

software yang dapat menyampaikan bagaimana membuat dan
membentuk model-model, tetapi tidak menyampaikan apa dan kapan
model yang seharusnya dibuat yang merupakan salah satu proses
implementasi pengembangan software.
UML tidak hanya merupakan sebuah bahasa pemograman visual saja,

namun juga dapat secara langsung dihubungkan ke berbagai bahasa
pemograman, seperti JAVA, C++, Visual Basic, atau bahkan
dihubungkan secara langsung ke dalam sebuah object-oriented
database. Begitu juga mengenai pendokumentasian dapat dilakukan
seperti; requirements, arsitektur, design, source code, project plan, tests,
dan prototypes.
Untuk dapat memahami UML membutuhkan bentuk konsep dari sebuah

bahasa model, dan mempelajari 3 (tiga) elemen utama dari UML seperti
building block, aturan-aturan yang menyatakan bagaimana building
block diletakkan secara bersamaan, dan beberapa mekanisme umum
(common).
Building blocks
Tiga macam yang terdapat dalam building block adalah :
Benda/Things, adalah abstraksi yang pertama dalam sebuah model
Hubungan/Relationships, sebagai alat komunikasi dari benda-benda,
Bagan/Diagrams. sebagai kumpulan / group dari benda-benda/things.
Benda/Things
Adalah hal yang sangat mendasar dalam model UML, juga merupakan
bagian paling statik dari sebuah model, serta menjelaskan elemen-
elemen lainnya dari sebuah konsep dan atau fisik.
Bentuk dari beberapa benda/thing adalah sebagai berikut:
 Classes, yang diuraikan sebagai sekelompok dari object yang

mempunyai atribute, operasi, hubungan yang semantik. Sebuah
kelas mengimplementasikan 1 atau lebih interfaces. Sebuah kelas
dapat digambarkan sebagai sebuah persegi panjang, yang
mempunyai sebuah nama, atribute, dan metoda
pengoperasiannya.
 Interfaces, merupakan sebuah antar-muka yang menghubungkan

dan melayani antar kelas dan atau elemen. ‘Interface’ / antar-muka
mendefinisikan sebuah set / kelompok dari spesifikasi
pengoperasian, umumnya digambarkan dengan sebuah lingkaran
yang disertai dengan namanya. Sebuah antar-muka berdiri sendiri
dan umumnya merupakan pelengkap dari kelas atau komponen.
 Collaboration, yang didefinisikan dengan interaksi dan sebuah

kumpulan / kelompok dari kelas-kelas/elemen-elemen yang
bekerja secara bersama-sama. Collaborations mempunyai struktur
dan dimensi. Pemberian sebuah kelas memungkinkan
berpartisipasi didalam beberapa collaborations dan digambarkan
dengan sebuah ‘elips’ dengan garis terpotong-potong.
 Use cases, adalah rangkaian/uraian sekelompok yang saling

terkait dan membentuk sistem secara teratur yang dilakukan atau
diawasi oleh sebuah aktor. ‘use case’ digunakan untuk
membentuk tingkah-laku benda/ things dalam sebuah model serta
di realisasikan oleh sebuah collaboration. Umumnya ‘use case’
digambarkan dengan sebuah ‘elips’ dengan garis yang solid,
biasanya mengandung nama.
 Nodes, merupakan fisik dari elemen-elemen yang ada pada saat

dijalankannya sebuah sistem, contohnya adalaha sebuah
komputer, umumnya mempunyai sedikitnya memory dan
processor. Sekelompok komponen mungkin terletak pada sebuah
node dan juga mungkin akan berpindah dari node satu ke node
lainnya. Umumnya node ini digambarkan seperti kubus serta
hanya mengandung namanya.
Hubungan / Relationship
Ada 4 macam hubungan didalam penggunaan UML, yaitu;
 Dependency, adalah hubungan semantik antara dua benda/things

yang mana sebuah benda berubah mengakibatkan benda satunya
akan berubah pula. Umumnya sebuah dependency digambarkan
sebuah panah dengan garis terputus-putus.
 Association, hubungan antar benda struktural yang terhubung

diantara obyek. Kesatuan obyek yang terhubung merupakan
hubungan khusus, yang menggambarkan sebuah hubungan
struktural diantara seluruh atau sebagian. Umumnya assosiation
digambarkan dengan sebuah garis yang dilengkapi dengan
sebuah label, nama, dan status hubungannya.
 Generalizations, adalah menggambarkan hubungan khusus

dalam obyek anak/child yang menggantikan obyek parent / induk .
Dalam hal ini, obyek anak memberikan pengaruhnya dalam hal
struktur dan tingkah lakunya kepada obyek induk. Digambarkan
dengan garis panah.
 Realizations, merupakan hubungan semantik antara

pengelompokkan yang menjamin adanya ikatan diantaranya.
Hubungan ini dapat diwujudkan diantara interface dan kelas atau
elements, serta antara use cases dan collaborations. Model dari
sebuah hubungan realization.
Bagan/Diagram
UML sendiri terdiri atas pengelompokkan diagram-diagram sistem
menurut aspek atau sudut pandang tertentu. Diagram adalah yang
menggambarkan permasalahan maupun solusi dari permasalahan suatu
model. UML mempunyai 9 diagram, yaitu; use-case, class, object, state,
sequence, collaboration, activity, component, dan deployment diagram.
 Use Case Diagram, menggambarkan sekelompok use cases dan

aktor yang disertai dengan hubungan diantaranya. Diagram use
cases ini menjelaskan dan menerangkan kebutuhan / requirement
yang diinginkan/ dikehendaki user/pengguna, serta sangat
berguna dalam menentukan struktur organisasi dan model dari
pada sebuah sistem.
 Class Diagram, yang memperlihatkan struktur statis dari kelas

actual didalam sistem.
 Object Diagram, yang merupakan varian dari kelas diagram yang

memperlihatkan lebih detail banyaknya obyek yang mengintantiasi
(instances) kelas.
 State Diagram, yang memperliatkan semua keadaan (state) yang

dapat dimiliki oleh kelas dan event yang dapat merubah keadaan
tersebut.
 Sequence Diagram, yang memperlihatkan kolaborasi dinamik
antara objek-objek dengan suatu urutan pesan (a sequence of
message) antar objek tersebut.
 Collaboration Diagram, yang memperlihatkan kolaborasi dinamik

antar objek tanpa memperhatikan aspek waktu.
 Activity Diagram, yang memperlihatkan aliran urutan aktifitas.
 Component Diagram, yang memperlihatkan struktur fisik dari

source code dalam terminology code components. Komponen
berisi informasi tentang logical class dapat berupa komponen
source code, komponen biner atau komponen yang dapat
dieksekusi.
 Deployment Diagram, yang memperlihatkan arsitektur fisik dari

hardware dan software pada sistem.
TEORI UML
2.1. Penjelasan UML
Pemecahan masalah utama dari Object Oriented biasanya dengan

penggambaran dalam bentuk model. Model abstrak (semu) merupakan gambaran detail
dari inti masalah yang ada, umumnya sama seperti refleksi dari problem yang ada pada
kenyataan. Beberapa modeling tool yang dipakai adalah bagian dari dasar UML,
kependekan dari United Modeling Language.
UML terdiri atas beberapa diagram, yaitu :
 Diagram Use Case
 Diagram Class
 Diagram Package
 Diagram Sequence
 Diagram Collaboration
 Diagram StateChart
 Diagram Activity
 Diagram Deployment
Semakin kompleks bentukan sistem yang akan dibuat, maka semakin sulit
komunikasi antara orang-orang yang saling terkait dalam pembuatan dan
pengembangan software yang akan dibuat. Pada masa lalu, UML mempunyai peranan
sebagai software blueprint (gambaran) language untuk analisis sistem, designer, dan
programmer. Sedangkan pada saat ini, merupakan bagian dari software trade (bisnis
software). UML memberikan jalur komunikasi dari sistem analis kemudian designer,
lalu programmer mengenai rancangan software yang akan dikerjakan.
Salah satu pemecahan masalah Object Oriented adalah dengan
menggunakan UML. Oleh karena itu orang-orang yang berminat dalam mempelajari
UML harus mengetahui dasar-dasar mengenai Object Oriented Solving (pemecahan
masalah OO). Tahap pertama, pembentukan model. Model adalah gambaran abstrak
dari suatu dasar masalah. Dan dunia nyata atau tempat dimana masalah itu timbul bisa
disebut dengan domain. Model mengandung obyek-obyek yang beraktifitas dengan
saling mengirimkan messages (pesan-pesan). Obyek mempunyai sesuatu yang diketahui
(atribut /attributes) dan sesuatu yang dilakukan (behaviors atau operations). Attributes
hanya berlaku dalam ruang lingkup obyek itu sendiri (state). Lalu “blue print” dari
suatu obyek adalah Classes (kelas). Obyek merupakan bagian-bagian dari kelas.
2.1.1. Diagram Use Case

Diagram Use Case menggambarkan apa saja aktifitas yang dilakukan oleh
suatu sistem dari sudut pandang pengamatan luar. yang menjadi persoalan itu apa yang
dilakukan bukan bagaimana melakukannya.
Diagram Use Case dekat kaitannya dengan kejadian-kejadian. kejadian
(scenario) merupakan contoh apa yang terjadi ketika seseorang berinteraksi dengan
sistem. untuk lebih memperjelas lihat gambaran suatu peristiwa untuk sebuah klinik
kesehatan di bawah ini :
“Pasien menghubungi klinik untuk membuat janji (appointment) dalam
pemeriksaan tahunan. Receptionist mendapatkan waktu yang luang pada
buku jadwal dan memasukkan janji tersebut ke dalam waktu luang itu.”
contoh kegiatan pasien yang membuat janji.
Gambar 2. 1
Diagram Use Case berguna dalam tiga hal :

 Menjelaskan fasilitas yang ada (requirements) Use
Case baru selalu menghasilkan fasilitas baru ketika sistem di analisa, dan design
menjadi lebih jelas.
 Komunikas dengan klien
Penggunaan notasi dan simbol dalam diagram Use Case membuat
pengembang lebih mudah berkomunikasi dengan klien-kliennya.
 Membuat test dari kasus-kasus secara umum
Kumpulan dari kejadian-kejadian untuk Use Case bisa dilakukan test kasus
layak untuk kejadian-kejadian tersebut.
2.1.2. Diagram Class
Diagram Class memberikan pandangan secara luas dari suatu sistem dengan
menunjukan kelas-kelasnya dan hubungan mereka. Diagram Class bersifat statis;
menggambarkan hubungan apa yang terjadi bukan apa yang terjadi jika mereka
berhubungan.
Diagram Class mempunyai 3 macam relationalships (hubungan), sebagai
berikut :
 Association Suatu
hubungan antara bagian dari dua kelas. Terjadi association antara dua kelas jika
salah satu bagian dari kelas mengetahui yang lainnya dalam melakukan suatu
kegiatan. Di dalam diagram, sebuah association adalah penghubung yang
menghubungkan dua kelas.
 Aggregation Suatu
association dimana salah satu kelasnya merupakan bagian dari suatu kumpulan.
Aggregation memiliki titik pusat yang mencakup keseluruhan bagian. Sebagai
contoh : OrderDetail merupakan kumpulan dari Order.
 Generalization Suatu
hubungan turunan dengan mengasumsikan satu kelas merupakan suatu superClass
(kelas super) dari kelas yang lain. Generalization memiliki tingkatan yang
berpusat pada superClass. Contoh : Payment adalah superClass dari Cash, Check,
dan Credit.
Untuk tambahan bahwa association mempunyai 2 titik. Salah satu titik bisa
memiliki label untuk menjelaskan association tersebut, contoh : OrderDetail adalah line
Item untuk setiap permintaan.
Panah navigability (pengatur alur arah) dalam suatu association
menggambarkan arah mana association dapat ditransfer atau disusun. Seperti dalam
contoh : OrderDetail dapat disusun dari item-nya, namun tidak bisa sebaliknya. Panah
ini juga menjelaskan siapa “memiliki” implementasi dari association; dalam kasus ini
OrderDetail memiliki Item. Association tanpa arah panah merupakan bidirectional
(bolak-balik).
Multiplicity dari suatu titik association adalah angka kemungkinan bagian
dari hubungan kelas dengan single instance (bagian) pada titik yang lain. Multiplicity
berupa single number (angka tunggal) atau range number (angka batasan). Pada contoh,
hanya bisa satu ‘Customer’ untuk setiap ‘Order’, tapi satu ‘Customer’ hanya bisa
memiliki beberapa ‘Order’.
Tabel di bawah mengenai multiplicity yang sering digunakan :
Tabel 2. 1
Tabel Multiplicity.
Multiplicities artinya
Nol atau satu bagian. Notasi n . . m menerangkan n sampai m
0..1
bagian.
0..* or * Tak hingga pada jangkauan bagian (termasuk kosong).
1 Tepat satu bagian
1..* Sedikitnya hanya satu bagian
Setiap diagram Class memiliki Class (kelas), association, dan multiplicity.

Sedangkan navigability (alur arah) dan role (kegiatan) merupakan optional (tidak
diharuskan).
Contoh Diagram Class transaksi Pembelian barang.
Gambar 2. 2
2.1.3. Package dan Object

Untuk mengatur pengorganisasian diagram Class yang kompleks, dapat
dilakukan pengelompokan kelas-kelas berupa package (paket-paket). Package adalah
kumpulan elemen-elemen logika UML. Gambar di bawah ini mengenai model bisnis
dengan pengelompokan kelas-kelas dalam bentuk paket-paket :
Contoh Diagram Package.
Gambar 2. 3
Ada jenis khusus dari diagram Class yaitu diagram Object. Kegunaannya
untuk penjelasan yang sedikit dengan relasi yang sulit, khususnya relasi rekursif.
Lihat gambar dibawah, diagram Class kecil menunjukkan bahwa
‘department’ dapat mengandung banyak ‘department’ yang lain.
Class yang relasinya rekursif.
Gambar 2. 4
Setiap tingkatan pada diagram berpengaruh pada single instance (bagian
tunggal). Nama bagian digarisbawahi dalam diagram UML. Untuk Class name (nama
kelas) maupun instance name (nama bagian) bisa mengambil dari diagram Object
selama arti diagram tersebut masih jelas.
Instance name memiliki huruf yang digarisbawahi.
Gambar 2. 5
2.1.4. Diagram Sequence

Diagram Class dan diagram Object merupakan suatu gambaran model statis.
Namun ada juga yang bersifat dinamis, seperti Diagram Interaction.
Diagram sequence merupakan salah satu diagram Interaction yang
menjelaskan bagaimana suatu operasi itu dilakukan; message (pesan) apa yang dikirim
dan kapan pelaksanaannya. Diagram ini diatur berdasarkan waktu. Obyek-obyek yang
berkaitan dengan proses berjalannya operasi diurutkan dari kiri ke kanan berdasarkan
waktu terjadinya dalam pesan yang terurut.
Di bawah ini adalah diagram Sequence untuk pembuatan Hotel Reservation.
Obyek yang mengawali urutan message adalah ‘aReservation Window’.
Contoh Diagram Sequence ‘Pemesanan kamar di Hotel’.

Gambar 2. 6
‘Reservation window’ mengirim pesan makeReservation() ke
‘HotelChain’. Kemudian ‘HotelChain’ mengirim pesan yang sama ke ‘Hotel’. Bila
‘Hotel’ punya kamar kosong, maka dibuat ‘Reservation’ dan ‘Confirmation’.
Lifeline adalah garis dot (putus-putus) vertikal pada gambar, menerangkan
waktu terjadinya suatu obyek. Setiap panah yang ada adalah pemanggilan suatu pesan.
Panah berasal dari pengirim ke bagian paling atas dari batang kegiatan (activation bar)
dari suatu pesan pada lifeline penerima. Activation bar menerangkan lamanya suatu
pesan diproses.
Pada gambar diagram , terlihat bahwa ‘Hotel’ telah melakukan pemanggilan
diri sendiri untuk pemeriksaan jika ada kamar kosong. Bila benar, maka ‘Hotel’
membuat ‘Reservation’ dan ‘Confirmation’. Pemanggilan diri sendiri disebut dengan
iterasi. Expression yeng dikurung dengan “[ ]”, adalah condition (keadaan kondisi).
Pada diagram dapat dibuat note (catatan). Pada gambar, terlihat seperti
selembar kertas yang berisikan teks. Note bisa diletakan dimana saja pada diagram
UML.
2.1.5. Diagram Collaboration

Diagram Collaboration juga merupakan diagram interaction. Diagram
membawa informasi yang sama dengan diagram Sequence, tetapi lebih memusatkan
atau memfokuskan pada kegiatan obyek dari waktu pesan itu dikirimkan.
Contoh Diagram Collaboration ‘Pemesanan kamar di Hotel’.

Gambar 2. 7
Kotak kegiatan obyek diberi label dengan nama kelas atau obyek (atau
keduanya). Nama kelas dibatasi dengan colons /titik dua ( : ).
Setiap pesan pada diagram Collaboration mempunyai angka yang terurut.
Pesan yang tingkatannya tertinggi adalah angka 1. Pesan yang berada pada tingkat yang
sama memiliki prefix yang sama, namun suffix berbeda bergantung pada posisinya;
hanya untuk angka 1, 2, dan seterusnya.
2.1.6. Diagram StateChart

Behaviors dan state dimiliki oleh obyek. Keadaan dari suatu obyek
bergantung pada kegiatan dan keadaan yang berlaku pada saat itu. Diagram StateChart
menunjukan kemungkinan dari keadaan obyek dan proses yang menyebabkan
perubahan pada keadaannya.
Untuk lebih jelas, contoh yang digunakan model diagram untuk login yang
merupakan bagian dari Online Banking System. Logging in terdiri atas masukan input
Social Security Number dan Personal Id Number yang berlaku, lalu memutuskan
kesahan dari informasi tersebut.
Contoh Diagram StateChart ‘Sistem Perbankkan secara Online’.
Gambar 2. 8
Logging in dapat dibagi menjadi empat tahapan proses, yaitu :
 Getting SSN (masukkan SSN),
 Getting PIN (masukkan PIN),
 Validating (periksa kesahannya), dan
 Rejecting (keluar).
Proses peralihan digambarkan dengan panah dari satu state ke yang lainnya.
Event (peristiwa) atau condition (keadaan) yang menyebabkan perubahan dituliskan
pada samping panah. Diagram ini mengandung dua self-transition (transisi sendiri), satu
pada getting SSN dan lainnya pada getting PIN.
Keadaan awal Start (black circle /lingkar hitam) adalah dummy (model)
untuk memulai action (kegiatan). Keadaan akhir juga keadaan model yang
menghentikan kegiatan.
Aksi yang terjadi sebagai hasil dari suatu peristiwa atau keadaan ditandai
dalam bentuk /action. Pada Validating State, obyek tidak menunggu peristiwa dari
luar untuk menyebabkan suatu perubahan. Sebagai gantinya melakukan suatu activity
(aktifitas). Hasil dari aktifitas tersebut menentukan keadaan berikutnya dari obyek
tersebut.
2.1.7. Diagram Activity

Pada dasarnya diagram Activity sering digunakan oleh flowchart. Diagram
ini berhubungan dengan diagram Statechart. Diagram Statechart berfokus pada obyek
yang dalam suatu proses (atau proses menjadi suatu obyek), diagram Activity berfokus
pada aktifitas-aktifitas yang terjadi yang terkait dalam suatu proses tunggal. Jadi
dengan kata lain, diagram ini menunjukkan bagaimana aktifitas-aktifitas tersebut
bergantung satu sama lain.
Sebagai contoh, perhatikan proses yang terjadi.
“Pengambilan uang dari bank melalui ATM.”
Ada tiga aktifitas kelas (orang, dan lainnya) yang terkait yaitu : Customer,
ATM, and Bank. Proses berawal dari lingkaran start hitam pada bagian atas dan
berakhir di pusat lingkaran stop hitam/putih pada bagian bawah. Aktivitas digambarkan
dalam bentuk kotak persegi. Lihat gambar di bawah ini, agar lebih jelas :
Contoh Diagram Activity ‘Pengambilan Uang melalui ATM’.
Gambar 2. 9
Diagram Activity dapat dibagi menjadi beberapa jalur kelompok yang
menunjukkan obyek yang mana yang bertanggung jawab untuk suatu aktifitas.
Peralihan tunggal (single transition) timbul dari setiap adanya activity (aktifitas), yang
saling menghubungi pada aktifitas berikutnya.
Sebuah transition (transisi) dapat membuat cabang ke dua atau lebih
percabangan exclusive transition (transisi eksklusif). Label Guard Expression (ada di
dalam [ ]) yang menerangkan output (keluaran) dari percabangan. percabangan akan
menghasilkan bentuk menyerupai bentuk intan. transition bisa bercabang menjadi
beberapa aktifitas paralel yang disebut Fork. Fork beserta join (gabungan dari hasil
output fork) dalam diagram berbentuk solid bar (batang penuh).
2.1.8. Diagram Component dan Deployment
Component adalah sebuah code module (kode-kode module). Diagram
Component merupakan fisik sebenarnya dari diagram Class. Diagram Deployment
menerangkan bahwa konfigurasi fisik software dan hardware.
Gambar 2.10 menerangkan hubungan sekitar komponen software dan
hardware yang berperan dalam ruang lingkup real estate.
Contoh Diagram Deployment ‘Sistem Real Estate’.
Gambar 2. 10
Fisik hardware berbentuk seperti node-node. Setiap komponen merupakan
bagian dari node. Pada gambar komponen berbentuk dua kotak tersusun yang terletak di
sebelah kiri atas.
PERANCANGAN SISTEM TERINCI
1. PERANCANGAN OUTPUT
Tujuan Perancangan Output adalah mengubah data menjadi

informasi yang berkualitas dan dapat digunakan. Tujuan akhirnya
adalah untuk proses pengambilan keputusan.
Informasi yang berkualitas dan dapat digunakan meliputi hal-hal

berikut ini :
 Accessibility : easy- to-use interfaces (kemudahan akses)
 Timeliness : dibuat sesuai waktu untuk melakukan aksi
(ketepatan waktu menghasilkan informasi)
 Relevance : menghindari detail yang berlebihan
(sesuai kebutuhan)
 Accuracy : bebas dari kesalahan
(ketepatan nilai dari informasi)
 Usability : sesuai dengan model mental / tipe kognitif user
Perancang output harus menyediakan suatu produk terhadap klien

(end user) yang akan menggunakan laporan. Perancang harus
bertanya kepada klien, format output apa yang sangat membantu dan
sangat mungkin untuk digunakan.
1.1. Macam-Macam Bentuk Laporan
Bentuk dari laporan yang dihasilkan oleh sistem informasi, yang

paling banyak digunakan adalah dalam bentuk tabel dan berbentuk
grafik atau bagan.
 Laporan Untuk Level Manajemen yang Berbeda
Laporan Berhirarki
Laporan yang dibuat untuk masing-masing level manajemen untuk
menerima informasi sesuai dengan permintaan khusus, tanpa
memberikan detail yang tidak relevan.
Para eksekutif akan melihat trend, kecenderungan, dan pola-pola dari

laporan tersebut. Mereka ingin mengetahui apakah masing-masing
bagian sudah mencapai tujuan.
Ada dua macam laporan berhirarki :
 Filter Report : laporan yang dirancang untuk memfilter elemen-
elemen data yang dipilih dari database, sehingga pengambil
keputusan akan memperoleh laporan yang sesuai dengan
kebutuhannya. Biasanya data difilter pada level atas.
Lihat contoh filter report
 Responsibility Report : laporan yang dibuat untuk memutuskan

siapa yang bertanggungjawab terhadap suatu laporan, apakah
CEO, manajer pemasaran, atau spesialis media, dll.
Lihat contoh responsibility report
 Laporan Yang Membandingkan Data

Laporan ini dibuat untuk membantu manajer dan user lain dalam
memilih dua atau lebih item untuk menyusun kesamaan atau
ketidaksamaan (perbedaan). Dengan perbandingan ini, user berada
pada posisi terbaik untuk membuat keputusan yang rasional.
Ada tiga macam laporan yang membandingkan data :

 Horizontal Report
Neraca dan laporan rugi laba menunjukkan laporan keuangan
periodik yang meringkas ribuan transaksi dan elemen data
menjadi output untuk beragam user. User akan memperoleh
gambaran yang jelas dengan melihat perbandingan pada laporan.
Hal ini dapat dilakukan dengan merancang horizontal report.
Jumlah setiap item dibandingkan dengan item yang berhubungan
pada satu atau lebih laporan sebelumnya.
Lihat contoh horizontal report
 Vertical Report
Laporan yang membandingkan suatu bagian komponen dengan
totalnya.
Lihat contoh vertical report

 Counterbalance Report
Setiap situasi dibandingkan dalam laporan.
Contohnya, skenario yang terburuk, layak, dan terbaik dapat
membantu para perencana menilai proyek-proyek yang berisiko,
juga informasi berharga bagi para eksekutif dalam pengambilan
keputusan.
Lihat contoh counterbalance report
 Laporan Untuk Monitor Variansi Data
Laporan ini dibedakan menjadi :

 Variance Report : laporan yang dibuat untuk membandingkan
standard dengan hasil aktual yang diperoleh. Biasanya laporan ini
dibuat sesuai dengan waktu atau selesainya suatu proses.
Lihat contoh variance report
 Exception Report : laporan ini seperti variance report, tetapi

beberapa kuota atau batasan dibuat untuk suatu proses atau
aktivitas. Laporan ini dibuat hanya ketika beberapa proses atau
aktivitas tidak sesuai dengan batasan atau kuota.
Lihat contoh exception report
1.2. Dasar-dasar Merancang Layar (Pedoman Perancangan

Laporan)
Teknik untuk merancang layar laporan dapat diperoleh atau diadopsi

dari perancangan laporan di kertas. Yang harus diperhatikan :
 Organisasi dari layar
 Justifikasi dari field data dan pelabelan
 Judul
 Spasi
 Identifikasi judul dan layar
 Warna
 Membuat Grafik Untuk Ilustrasi Data

Grafik merupakan suatu cara untuk mengilustrasikan informasi
numerik yang dapat dipahami dengan cepat.

Grafik mengubah kuantitas ke suatu bentuk. Ada empat tools untuk
prototipe grafik, yaitu Spreadsheet, CASE tools, DBMS, dan 4th GL.
Grafik dibagi-bagi dalam beberapa kategori berdasarkan jenis

informasi yang diinginkan :
 Scatter graph: untuk menunjukkan trend suatu data.
 Line graph : menggambarkan fluktuasi melalui waktu, apakah

naik atau turun, tinggi, rendah, atau stabil.
 Bar graph : menunjukkan proporsi atau hubungan kuantitas

satu sama lain.
Ada dua macam bar graph, yaitu :

- Horizontal Bar Graph : membandingkan item-item yang
berbeda pada waktu yang sama.
- Vertical Bar Graph : mengukur item yang sama dibandingkan
pada periode waktu yang berbeda.
 Sectograph : menggambarkan bagaimana membagi jumlah total.
Ada dua macam sectograph :

- Pie chart : merupakan suatu lingkaran yang terbagi dalam
dua atau lebih segmen yang merepresentasikan
suatu persentasi.
- Layer graph : seperti line graph, tetapi area antar garis menunjuk-
kan kuantitas dan menambah jumlah totalnya.
Lihat contoh layer graph
 Picturegraph : menggunakan simbol-simbol atau icon-icon khusus

sebagai pengganti bar. Setiap gambar menunjuk-
kan kuantitas item yang diilustrasikan.
Lihat contoh picturegraph
 Membuat Tabel dan Matriks

Tabel dan matrik menggabungkan ciri dari laporan tabular
konvensional dan grafik. Keduanya dapat dipakai untuk hubungan
yang penting, menunjukkan perbandingan, dan memberikan instruksi.

Membuat Tabel
Tabel dibentuk dari sejumlah kolom dengan judul subyek yang diatur
dalam garis. Tabel sangat berarti untuk menyediakan rangkuman
informasi eksekutif.
Lihat contoh tabel
Membuat Matriks
Elemen kolom dan baris yang diatur dalam segi empat. Matriks
sangat baik untuk menunjukkan hubungan antara elemen.
Lihat contoh matriks
1.3. Pengaturan Tata Letak Isi Output
Pengaturan isi dari output akan secara langsung menentukan

kemudahan dari output untuk dipahami dan dimengerti. Pengaturan
tata letak output merupakan pekerjaan perancangan yang penting
dan sangat diperlukan baik bagi pemakai sistem maupun
programmer.
Bagi pemakai sistem digunakan untuk menilai isi dan bentuk dari
output, apakah sudah sesuai dengan yang diinginkan atau belum.
Bagi programmer akan digunakan sebagai dasar pembuatan program

untuk menghasilkan output yang diinginkan. Programmer membutuh-
kan perancangan output ini untuk menentukan posisi kolom, baris
dan informasi yang harus disajikan di suatu output.
Pengaturan tata letak isi output yang akan dicetak di printer dapat
digunakan alat bagan tata letak printer (printer layout chart) dan
kamus data output.
2. PERANCANGAN INPUT
Input mengawali dimulainya proses informasi. Input perlu

direncanakan untuk mengkonversikan data mentah ke dalam
informasi yang berguna (input – output).

Beberapa kegiatan di bawah ini memakai data mentah atau data
input :
 Insert into, delete from, update database
 Menggabungkan dengan data lain dari database untuk menghasil-
kan output
 Masukkan dan proses langsung menjadi output tanpa
menggabungkan dengan data lain
 Memulai aksi atau melaksanakan suatu tugas
 Mengadakan dialog dengan sistem
Beberapa media dan metode yang digunakan untuk mendapatkan data

dan input data :
 Paper form yang digabungkan dengan layar data-entry
 Electronic form
 Direct-entry devices
 Codes
 Menus
 Natural language
2.1 Perancangan Formulir Kertas
Formulir kertas merupakan pembawa data fisik. Kejadian

berlangsung, transaksi terjadi, dan aksi diambil. Aktivitas ini
menghasilkan data yang dapat diambil dan dimasukkan ke dalam
sistem untuk diproses. Aktivitas pemasukkan data dapat dilakukan
dengan keying atau scanning.
Pada beberapa perusahaan, form ini menjadi suatu bisnis, seperti

asuransi, saham, hipotik, kredit, dll.
Beberapa faktor yang harus diperhatikan dalam merancang formulir

kertas :
1. Pemilihan Kertas
Beberapa faktor harus dipertimbangkan di dalam pemilihan kertas
yang akan digunakan, yaitu :
 Lama formulir akan disimpan
 Penampilan dari formulir
 Banyak formulir tersebut ditangani
 Bagaimana penanganannya (halus, kasar, dilipat, atau dibawa-
bawa oleh pemakainya)
 Kemudahan untuk digunakan
 Tahan lamanya untuk pengisian yang lama
 Lingkungan (minyak, kotor, panas, dingin, lembab, dll)
 Metode untuk pengisian data di formulir (tulis tangan, mesin)
 Keamanan terhadap pudarnya data
Semakin lama formulir akan disimpan, formulir tersebut harus

semakin baik. Semakin sering digunakan, kelas kertas harus
semakin baik pula.
2. Ukuran Kertas
Usahakan ukuran kertas yang digunakan berupa ukuran kertas
yang standar dan banyak dijual. Jika kertas tidak standar,
sebaiknya dibuat ukuran yang merupakan kelipatan yang tidak
membuang kertas, seperti ukuran kertas standar dibagi 2, 3, 4,
dst.
3. Warna
Penggunaan warna membantu mengidentifikasi dengan cepat
formulir yang dipergunakan. Warna yang baik adalah warna yang
datanya mudah dibaca, terutama bila menggunakan karbon.
Warna yang baik adalah warna yang cerah.
4. Judul Formulir
Formulir harus diberi judul untuk menunjukkan jenis dan
kegunaannya. Judul dibuat sesingkat mungkin tetapi jelas. Nama
perusahaan juga perlu dicantumkan.
5. Nomor Formulir
Nomor dapat digunakan untuk menunjukkan keunikan. Dapat
diletakkan di pojok kiri bawah atau di bawah kanan. Nomor
formulir ini dapat juga digunakan untuk menunjukkan sumber dan
jenisnya.
6. Nomor Urut Formulir

Nomor urut dari masing-masing formulir ini biasanya dicantumkan
di pojok kanan atas. Nomor urut ini sangat perlu untuk tujuan
pengendalian, pelacakan pemeriksaan, dan pengarsipan.
7. Nomor dan Jumlah Halaman

Jika formulir terdiri lebih dari satu halaman, maka tiap-tiap
halaman harus diberi nomor dan jumlah halaman, supaya bila ada
halaman yang hilang dapat diketahui. Nomor dan jumlah halaman
ini biasanya diletakkan pada sebelah kanan atas.
8. Spasi
Spasi antar baris dan spasi antar karakter pada formulir harus
diperhatikan, terutama bila formulir akan diisi dengan data yang
dicetak dengan mesin.
9. Pembagian Area
Formulir harus dibentuk dengan pembagian area sedemikian rupa,
sehingga memudahkan dalam pengisian atau pencarian data.
Pembagian area ini meliputi area judul, area halaman, area
kontrol, area organisasi, area obyek, area tubuh, area berita, area
otorisasi, area jumlah, dan area nomor.
Lihat gambar pembagian area sebuah formulir
10. Caption
Merupakan kata-kata yang dicetak di formulir untuk menunjukkan
siapa yang harus mengisi data dan apa yang harus diisikan.
Jenis-jenis caption : box caption, yes/no check off caption,
horizontal check off caption, checklist caption, blocked spaces
caption dan scannable form caption.
11. Instruksi dalam Formulir

Formulir yang baik harus bersifat self-instruction, artinya harus
berisi instruksi-instruksi yang jelas bagi pengisi untuk menuliskan
data tanpa harus bertanya lagi.
12. Jendela di Amplop

Jika formulir harus dikirimkan, dapat dipergunakan amplop yang
berjendela supaya mengurangi penulisan nama dan alamat yang
dikirim pada amplop.
13. Jumlah Tembusan

Banyak tembusan atau rangkap dari formulir harus dibuat
seefisien dan seefektif mungkin, tidak boleh berlebihan dan tidak
boleh kurang. Jumlah dari tembusan ini tergantung dari jalur
distribusinya, yaitu dapat berupa jalur distribusi urut (sequential
routing), dan jalur ditsribusi serentak (concurrent routing).

2.2. Pengelolaan dan Perancangan Formulir Elektronik
Merupakan layar pengisian data yang dirancang untuk digunakan

tanpa adanya sumber dokumen resmi. Formulir elektronik dirancang
pada sebuah digitizer atau layar Video Display Terminal (VDT) dari
sistem CASE, menggunakan beberapa komponen seperti pada
formulir, yaitu :
 Pembagian area
 Instruksi
 Line, box dan caption
 Indikator field data
 Urutan pedoman perancangan
 Pengelolaan Formulir Elektronik

Sesudah formulir ini dirancang dan disetujui, formulir disimpan pada
media magnetik atau media optikal dan dikirim ke workstation.
Formulir elektronik ditampilkan pada layar workstation, dan diisi oleh
user melalui keyboard. Jika hard copy dari formulir elektronik ini
diperlukan, dapat diakses dari database dan dihasilkan oleh printer.
Lihat contoh dokumen sumber dan layar pemasukkan data

Lihat sistem formulir elektronik
Smart Electronic Forms

Formulir elektronik yang cerdas menunjukkan bagaimana user
mengisi formulir, menyediakan instruksi-instruksi dan pesan-pesan
secara online, melakukan perhitungan, dan mengirimkan data untuk
pemrosesan tambahan.
 Perancangan Formulir Elektronik

Untuk merancang formulir ini kita mengambil data dari dokumen
sumber, dan kita harus mengikuti format dari dokumen sumber.
Dengan formulir elektronik, tidak dibutuhkan lagi dokumen sumber.
Lihat contoh formulir elektronik
 Pemasukkan Data secara Langsung

Komponen hardware yang biasanya digunakan untuk memasukkan
data ke dalam formulir adalah keyboard. Keyboard merupakan alat
untuk masuk ke dalam sistem informasi. Karena pemasukkan data
melalui keyboard bergantung pada keahlian dan usaha manusia, hal
ini tidak selalu menjadi cara yang paling efisien dan akurat untuk
memasukkan data.
Pemasukkan data secara langsung sering disebut sebagai
otomatisasi data sumber, merupakan suatu cara menginput data
yang tidak membutuhkan pemasukkan data dengan membaca
sesuatu dari dokumen sumber, atau mengisi pada formulir elektronik,
jadi menambah efisiensi pengisian data dan mengurangi
kemungkinan kesalahan pada saat proses pengisian.
Beberapa peralatan pemasukkan data secara langsung adalah :

 Magnetic Ink Character Recognition (MICR)
 Optical Character Recognition (OCR)
 Optical Mark Recognition (OMR)
 Digitizer
 Image scanner
 Point-of-Sales (POS) devices
 Automatic Teller Machine (ATM)
 Mouse
 Voice recognition
2.3. Pengkodean Input
Kode digunakan untuk tujuan mengklasifikasikan data, memasukkan

data ke dalam komputer, dan untuk mengambil bermacam-macam
informasi yang berhubungan dengannya.
Kode dapat terdiri dari kumpulan angka, huruf, karakter-karakter
khusus (misalnya %, /, #, $, &, :, dsb), simbol kode batang (bar code),
warna, dan suara.
2.3.1 Petunjuk Pembuatan Kode

Beberapa kemungkinan susunan angka, huruf, dan karakter-karakter
khusus dapat dirancang ke dalam bentuk kode.
Di dalam merancang suatu kode hal-hal berikut ini perlu diperhatikan:

1. Mudah diingat
2. Unik
3. Fleksibel
4. Efisien
5. Konsisten
6. Sesuai standar
7. Menghindari spasi
8. Menghindari karakter yang mirip
9. Panjang kode harus sama

2.3.2. Tipe Kode
Ada beberapa macam tipe dari kode yang dapat digunakan di dalam
sistem informasi.
Tipe kode tersebut adalah :
Kode Mnemonik (Mnemonic Code)

Kode mnemonik digunakan untuk tujuan supaya mudah diingat. Kode
ini dibuat dengan dasar singkatan atau mengambil sebagian karakter
dari item yang akan diwakili oleh kode ini. Umumnya kode mnemonik
menggunakan huruf. Akan tetapi dapat juga menggunakan gabungan
huruf dan angka. Kebaikan dari kode ini adalah mudah diingat, dan
kelemahannya adalah kode dapat menjadi terlalu panjang.
Contoh : P = Pria; W = Wanita.
Kode Urut (Sequential Code)

Kode urut disebut juga kode seri (serial code), merupakan kode yang
nilainya urut antara satu kode dengan kode berikutnya.
Contoh : 001 Kas

002 Piutang Dagang
003 Persediaan Produk Selesai
004 Persediaan Produk Dalam Proses
005 Persediaan Bahan Baku
Kebaikan Kelemahan
Sederhana, mudah diterapkan, Penambahan kode hanya
kode dapat pendek tetapi unik, dapat ditambahkan pada akhir
mudah dicari bila kodenya urutan dan tidak dapat
diketahui, cocok untuk rekaman disisipkan, tidak mempunyai
di file yang menggunakan dasar logika tentang informasi
nomor record relatif, baik untuk item yang diwakilinya, tidak
pengendalian. fleksibel bila terjadi perubahan
kode.
Kode Blok (Block Code)

Kode blok mengklasifikasikan item ke dalam kelompok blok tertentu
yang mencerminkan satu klasifikasi tertentu atau dasar pemakaian
maksimum yang diharapkan.

Contoh :
Blok Kelompok
1000 - 1999 Aktiva Lancar

2000 - 2999 Aktiva Tetap
3000 - 3499 Hutang Lancar
3500 - 3999 Hutang Jangka Panjang
4000 - 4999 Modal
Dari blok-blok kode untuk masing-masing kelompok rekening utama,

maka rekening-rekening AKTIVA LANCAR dapat mempunyai kode
diantara 1000 sampai dengan 1999 sebagai berikut :
1000 Kas
1100 Piutang Dagang
1200 Persediaan Produk Selesai
1210 Persediaan Produk Dalam Proses
1220 Persediaan Bahan Baku
Kebaikan Kelemahan
Nilai dari kode mempunyai arti, Panjang kode tergantung dari
mudah diperluas, kode dapat jumlah bloknya, kurang mudah
ditambah atau dibuang diingat.
sebagian, proses pembuatan
laporan keuangan dapat
dilakukan dengan lebih mudah.
Kode Group (Group Code)

Kode group merupakan kode yang berdasarkan field-field dan tiap
field kode mempunyai arti.
Contoh : Kode ISBN, NPM
Kebaikan Kelemahan
Nilai dari kode mempunyai arti, Kode dapat menjadi panjang.
mudah diperluas, dapat
ditambah atau dibuang
sebagian, menunjukkan jenjang
dari data.

Kode Desimal (Decimal Code)
Kode desimal mengklasifikasikan kode atas dasar 10 unit angka
desimal dimulai dari angka 0 .. .9, atau 00 .. 99, tergantung dari
banyaknya kelompok.
Contoh : 00 Aktiva Lancar

00100 Kas
00200 Piutang dagang
00300 Persediaan produk selesai.
01 Aktiva Tetap
01100 Tanah
01200 Bangunan Kantor

PERANCANGAN SISTEM TERINCI DATABASE
1. PERANCANGAN DATABASE
Perancangan Database adalah proses untuk menentukan isi dan
pengaturan data yang dibutuhkan untuk mendukung berbagai
rancangan sistem.
Perancangan sistem terjadi pada dua tingkat , yaitu :

Pada tingkat pertama, perencanaan sistem, analisis dan rancangan
umum dilaksanakan untuk menetapkan kebutuhan pemakai. Tingkat
perancangan database ini melibatkan tahap front-end, bebas dari
perancangan database tertentu atau Database Management System
(DBMS).
Pada tingkat kedua, rancangan umum, seperti diagram entitas relasi

tingkat tinggi, ditransformasikan (atau didekomposisikan) ke dalam
perancangan database rinci untuk sebuah DBMS tertentu yang akan
digunakan untuk mengimplementasikan sistem total.
Tiga model database yang cukup dikenal adalah :

 Model Hierarkikal
 Model Jaringan
 Model Relasional
Pada masa lalu banyak penjual (vendors) menawarkan Database

Management Systems (DBMS) yang berdasarkan pada Model
Hierarkikal dan Model Jaringan. Saat ini Model Relasional adalah
dominan. Karena itu hampir semua penjual perangkat lunak database
menawarkan produk perangkat lunak Relational Database
Management Systems (RDBMS).
RDBMS dibuat dengan struktur tiga skema , yaitu :

 Eksternal
 Konseptual
 Internal
Lihat Gambar 1. Struktur tiga-skema dari sebuah RDBMS

Struktur lapisan ini mendefinisikan data perusahaan pada tingkat
yang berbeda.
Skema Eksternal mendefinisikan bagaimana pemakai mengakses

dan melihat output dari RDBMS, bebas dari bagaimana data
disimpan atau diakses secara fisik. Akses dan manipulasi seperti ini
dilaksanakan oleh pemakai dengan memperkerjakan bahasa
prosedural, seperti COBOL atau bahasa query, seperti Structured
Query Language (SQL), bahasa standar yang diakui untuk RDBMS.
Skema Konseptual yang mendefinisikan model database relasional

terdiri dari sekumpulan tabel yang dinormalisasi. Skema konseptual
adalah rancangan dari database yang merupakan subyek utama dari
bab ini.
Skema Internal terdiri dari organisasi fisik dari data (mis. sekuensial,
indeks sekuensial, langsung) dalam hal struktur fisik data dan
metode-metode pengaksesan dari sistem operasi komputer.
APAKAH DATABASE RELASIONAL ITU ?

Model relasional berdasarkan teori himpunan matematik. Struktur
didefinisikan dengan Tabel. Dalam istilah matematika, tabel disebut
sebagai Relasi. Profesional sistem sering menggunakan istilah “tabel”
dan “relasi” secara bergantian.
Tiap tabel dalam model relasional dikomposisikan dari baris dan

kolom. Kolom disebut Atribut. Nilai untuk sebuah atribut harus dipilih
dari sekelompok nilai yang dinamakan Domain. Karena banyak kolom
dalam tabel yang sama dapat diidentifikasikan atas domain yang
sama, maka nama atribut didefinisikan untuk tiap kolom. Tiap nama
atribut dalam sebuah relasi harus unik. Urutan kiri ke kanan dari
kolom tidak penting. Urutan dari baris juga tidak penting.
Perpotongan dari suatu baris dan kolom berisi sebuah nilai tunggal.
Sifat-sifat Tabel :
1. Duplikasi baris tidak diperbolehkan. Untuk melaksanakan sifat ini,
harus terdapat paling sedikit satu atribut atau kombinasi beberapa
atribut yang mengidentifikasi secara unik tiap baris dari tabel.
Atribut atau kombinasi beberapa atribut yang melaksanakan tugas
ini disebut Kunci Primer (Primary Key). Contoh :
Nomor_Mahasiswa, adalah kunci primer yang mengidentifikasi
tiap mahasiswa secara unik.

2. Database relasional adalah nilai Primary Key tidak boleh
mempunyai duplikat atau NIL (NULL, yaitu nilai tidak diketahui).
3. Keterhubungan (relationship) antara dua tabel. Jika Tabel R2

mempunyai sebuah Kunci Asing (Foreign Key) yang cocok
dengan kunci primer dari Tabel R1, maka untuk setiap nilai
Foreign Key harus terdapat sebuah nilai kecocokan dari Primery
Key, atau nilai Foreign Key harus nil.
Menggunakan Structures Query Language (SQL)

SQL adalah bahasa standar database yang digunakan untuk query,
manipulasi dan memperbarui RDBMS. Karena semakin banyak
organisasi yang memutuskan untuk mengkonsolidasikan database
mereka ke dalam sistem seluas usaha, pengetahuan mengenai SQL
akan menjadi kebutuhan untuk para perancang database.
2. ENTITY RELATIONSHIP DIAGRAM (ERD)
Model Entity Relationship

Adalah suatu penyajian data dengan menggunakan Entity dan
Relationship.
Entity
 Entity adalah obyek yang dapat dibedakan dalam dunia nyata
 Entity set adalah kumpulan dari entity yang sejenis
 Entity set dapat berupa :

- Obyek secara fisik : Rumah, Kendaraan, Peralatan
- Obyek secara konsep : Pekerjaan , Perusahaan, Rencana
Relationship
 Relationship adalah hubungan yang terjadi antara satu atau lebih
entity.
 Relationship set adalah kumpulan relationship yang sejenis.

PEGAWAI KERJA PROYEK
Atribut
 Atribut adalah karakteristik dari entity atau relationship, yang

menyediakan penjelasan detail tentang entity atau relationship
tersebut.
 Nilai Atribut merupakan suatu data aktual atau informasi yang

disimpan pada suatu atribut di dalam suatu entity atau relationship.
Jenis-jenis atribut :
 Key
Atribut yang digunakan untuk menentukan suatu entity secara unik.
 Atribut Simple
Atribut yang bernilai tunggal.
 Atribut Multivalue
Atribut yang memiliki sekelompok nilai untuk setiap instan entity.
TglLahir Gelar NIP Nama
PEGAWAI

 Atribut Composite
Suatu atribut yang terdiri dari beberapa atribut yang lebih kecil
yang mempunyai arti tertentu.
Nama Nama Nama

Depan TTengah Belakang
NAMA
PEGAWAI
 Atribut Derivatif
Suatu atribut yang dihasilkan dari atribut yang lain.
TglLahir Umur
PEGAWAI
Derajat dari relationship

Menjelaskan jumlah entity yang berpartisipasi dalam suatu
relationship.
Unary Degree (Derjat Satu)
PEGAWAI LAPOR

Binary Degree (Derajat Dua)
PEGAWAI KERJA DEPARTEMEN
Ternary Degree (Derajat Tiga)
KOTA
Cardinality Ratio Constraint
 Menjelaskan batasan jumlah keterhubungan satu entity dengan

entity lainnya.
 Jenis Cardinality Ratio
1 : 1 (One-To-One)
Sebuah entity A diasosiasikan pada sebuah entity B, dan sebuah

entity B diasosiasikan dengan paling banyak sebuah entity A.
a1 b1
a2 b2
a3 b3
a4 b4
A B

Pegawai Milik Kendaraan
r1
P1    k1
r2
p2    k2
r3
p3    k3
. . .
1 1
PEGAWAI MILIK KENDARAAN
AIII
1 : N (One-To-Many)
Sebuah entity A diasosiasikan dengan sejumlah entity B, tetapi entity

B dapat diasosiasikan paling banyak satu entity A.
a1 b1
b2
a2 b3
b4
a3 b5
A B
Pegawai Kerja Departemen
r1
P1    d1
r2
p2    d2
r3
p3    d3
r4
p4   .
. .

N 1
PEGAWAI
KERJA DEPARTEMEN
N : 1 (Many-To-One)
Suatu entity A dapat diasosiasikan dengan paling banyak sebuah

entity B, tetapi entity B dapat diasosiasikan dengan sejumlah entity di
A.
a1 b1
a2
a3 b2
a4
a5 b3
A B
M : N (Many-To-Many)
Suatu entity A dapat diasosiasikan dengan sejumlah entity B dan

entity B dapat diasosiasikan dengan sejumlah entity di A.
a1 b1
a2 b2
a3 b3
a4 b4
A B

Pegawai Kerja Proyek
r1
P1    pr1
r2
p2    pr2
r3
p3    pr3
r4
 .
. .
M N
Participation Constraint
Menjelaskan apakah keberadaan suatu entity tergantung pada
hubungannya dengan entity lain .
Terdapat 2 macam Participation Constraint :
Total Participation
Keberadaan suatu entity tergantung pada hubungannya dengan
entity lain.
N 1
PEGAWAI PUNYA BAGIAN
Partial Participation
Keberadaan suatu entity tidak tergantung pada hubungannya
dengan entity lain.
N 1
KERJA
PEGAWAI PROYEK

Weak Entity
 Weak Entity adalah suatu Entity dimana keberadaan dari entity

tersebut tergantung dari keberadaan entity lain.
 Entity yang merupakan induknya disebut Identifying Owner dan

relationshipnya disebut Identifying Relationship.
 Weak Entity selalu mempunyai Total Participation constraint

dengan Identifying Owner.
NOPEG ……… NAMA

………
….
…
PEGAWAI MILIK TANGGUNGAN
Simbol-simbol ER-Diagram
Notasi Arti
1. 1. Entity
2. 2. Weak Entity
3. 3. Relationship
4. 4. Identifying Relationship
5. 5. Atribut
6. 6. Atribut Primary Key
7. 7. Atribut Multivalue
8. 8. Atribut Composite
9. 9. Atribut Derivatif
Transformasi dari ERD ke Database Relasional
1. Setiap tipe Entity dibuat suatu relasi yang memuat semua atribut
simple, sedangkan untuk atribut composite hanya dimuat
komponen-komponennya saja.
NOPEG ALM1 KDPOS
PEGAWAI ALAMAT
PEGAWAI (NOPEG, ALM1, KDPOS, …….)
2. Setiap relasi yang mempunyai atribut multivalue, buatlah relasi

baru dimana Primary Keynya merupakan gabungan dari Primary
Key dari relasi tersebut dengan atribut multivalue.
NOPRO .... LOKASI
PROYEK
LOKPR(NOPRO, LOKASI)

3. Setiap Unary Relationship 1:N, pada relasi perlu ditambahkan
suatu foreign key yang menunjuk ke nilai primary keynya.
NOPEG …….
1
PEGAWAI KONTROL
PEGAWAI (NOPEG, ….., SUPERVISOR-ID)
4. Setiap Unary Relationship M:N, buatlah relasi baru dimana

primary keynya merupakan gabungan dari dua atribut dimana
keduanya menunjuk ke primary key relasi awal dengan
penamaan yang berbeda.
NOBAR …….
M
BARANG TERDIRI JUMLAH
KOMBAR (NOBAR, NOKOMP , JUMLAH)
5. Setiap Binary Relationship 1:1, dimana Participation Constraint

keduanya total, buatlah suatu relasi gabungan dimana Primary
Keynya dapat dipilih salah satu.
NOPEG NOPRO
1 1
1
PEGAWAI (NOPEG, ... , NOPRO, ...).

6. Setiap Binary Relationship 1:1 dan salah satu Participation
Constraintnya Total, maka Primary Key pada relasi yang
Participation Constraintnya Partial menjadi Foreign Key pada
relasi yang lainnya.
NOPEG NOBAG
1 1
PEGAWAI PIMPIN BAGIAN
BAGIAN (NOBAG, ... , MANAGER)
7. Setiap Binary Relationship 1:1, dimana kedua Participation

Constraintnya partial, maka selain kedua relasi perlu dibuat relasi
baru yang berisi Primary Key gabungan dari Primary Key kedua
tipe Entity yang berelasi.
NOPEG NOPRO
1 1
PEGAWAI KERJA
PROYEK
PEKERJAAN ( NOPEG, NOPRO, …)
8. Setiap Binary Relationship 1 : N, dimana tipe Entity yang bersisi N

mempunyai Participation Constraint Total, maka Primary Key
pada relasi yang bersisi 1 dijadikan Foreign Key pada relasi yang
bersisi N.
NOBAG ………. NOPRO
1 N
BAGIAN PUNYA PROYEK
PROYEK (NOPRO, ... , NOBAG)

9. Setiap Binary Relationship 1 : N, dimana tipe Entity yang bersisi N
mempunyai Participation Constraint partial, buatlah relasi baru
dimana Primary Keynya merupakan gabungan dari Primary Key
kedua tipe Entity yang berelasi.
NOPEG ……… NOPRO
N 1
PEGAWAI KERJA
PROYEK
PEKERJAAN (NOPEG, NOPRO, ……)
10. Setiap Binary Relationship M:N, buatlah relasi baru dimana

Primary Keynya merupakan gabungan dari Primary Key kedua
tipe Entity yang berelasi.
NOPEG …… .. NOPRO
M N
M N
PEGAWAI KERJA
PROYEK
PEKERJAAN (NOPEG, NOPRO, …..)
11. Setiap Ternary Relationship, buatlah relasi baru dimana Primary

Keynya merupakan gabungan dari Primary Key ketiga tipe Entity
yang berelasi.
NOPEG NOPRO
PEGAWAI KERJA
PROYEK
KOTA
NOKOT
PEKERJAAN ( NOPEG, NOPRO , NOKOT)

12. Setiap tipe Weak Entity, dibuat suatu relasi yang memuat semua
atributnya dimana Primary Keynya adalah gabungan dari Partial
Key dan Primary Key dari relasi induknya (identifying owner).
NOPEG … NAMA
… …….
…
1 N
PEGAWAI PUNYA TANGGUNGAN
PUNYA
PUPPU
NYAPIL
IK NAMA, ….)
TANGGUNGAN (NOPEG,
Hasil Transformasi dari Diagram ER ke Database Relasional :
Skema Database
PEGAWAI (NOPEG, NAPEG, ALM1, KDPOS,TGLLAH,

UMUR, SUPERVISOR-ID, NOBAG)
BAGIAN (NOBAG, NABAG, LOKASI, MANAGER)
PROYEK (NOPRO, NAPRO, NOBAG)
LOKPR (NOPRO, LOKAPR)
PEKERJAAN (NOPEG, NOPRO, JAM)
TANGGUNGAN (NOPEG, NAMA, JNKELT,HUBUNGAN)
3. NORMALISASI
Normalisasi adalah suatu teknik untuk mengorganisasi data ke dalam

tabel-tabel untuk memenuhi kebutuhan pemakai di dalam suatu
organisasi.

Tujuan dari Normalisasi
 Untuk menghilangkan kerangkapan data
 Untuk mengurangi kompleksitas
 Untuk mempermudah pemodifikasian data
Proses Normalisasi
 Data diuraikan dalam bentuk tabel, selanjutnya dianalisis

berdasarka persyaratan tertentu ke beberapa tingkat.
 Apabila tabel yang diuji belum memenuhi persyaratan tertentu,

maka tabel tersebut perlu dipecah menjadi beberapa tabel yang
lebih sederhana sampai memenuhi bentuk yang optimal.
Tahapan Normalisasi
Bentuk Tidak Normal
Menghilangkan perulangan group
Bentuk Normal Pertama (1NF)
Menghilangkan ketergantungan sebagian
Bentuk Normal Kedua (2NF)
Menghilangkan ketergantungan transitif
Bentuk Normal Ketiga (3NF)
Menghilangkan anomali-anomali hasil dari

ketergantungan fungsional
Bentuk Normal Boyce-Codd (BCNF)
Menghilangkan Ketergantungan Multivalue
Bentuk Normal Keempat (4NF)
Menghilangkan anomali-anomali yang tersisa
Bentuk Normal Kelima

Ketergantungan Fungsional
Definisi :
Atribut Y pada relasi R dikatakan tergantung fungsional pada
atribut X (R.X ---> R.Y), jika dan hanya jika setiap nilai X pada
relasi R mempunyai tepat satu nilai Y pada R.
Misal, terdapat skema database Pemasok-barang :

Pemasok (No-pem, Na-pem)
Tabel PEMASOK-BARANG
No-pem Na-pem
P01 Baharu
P02 Sinar
P03 Harapan
Ketergantungan fungsional dari tabel PEMASOK-BARANG adalah :

No-pem ---> Na-pem
Ketergantungan Fungsional Penuh

Definisi :
Atribut Y pada relasi R dikatakan tergantung fungsional penuh
pada atribut X pada relasi R, jika Y tidak tergantung pada
subset dari X ( bila X adalah key gabungan)

Contoh :
KIRIM-BARANG( No-pem, Na-pem, No-bar, Jumlah)
No-pem Na-pem No-bar Jumlah
P01 Baharu B01 1000

P01 Baharu B02 1500
P01 Baharu B03 2000
P02 Sinar B03 1000
P03 Harapan B02 2000
Ketergantungan fungsional :
No-pem --> Na-pem
No-bar, No-pem --> Jumlah (Tergantung penuh terhadap key-
nya)
Ketergantungan Transitif
Definisi :
Atribut Z pada relasi R dikatakan tergantung transitif pada
atribut X , jika atribut Y tergantung pada atribut X pada relasi R
dan atribut Z tergantung pada atribut Y pada relasi R. (X
Y, Y Z , maka X Z )
Contoh :
No-pem Kode-kota Kota No-bar Jumlah

P01 1 Jakarta B01 1000
P02 3 Bandung B03 1000
P03 2 Surabaya B02 2000

Ketergantungan fungsional :
No-pem Kode-kota
Kode-kota Kota , maka
No-pem Kota
Bentuk Normal Kesatu (1NF)

Suatu relasi dikatakan sudah memenuhi Bentuk Normal Kesatu bila
setiap data bersifat atomik yaitu setiap irisan baris dan kolom
hanya mempunyai satu nilai data
Tabel KIRIM-1 (Unnormal)

B02 1500
B03 2000
Tabel KIRIM-2 (1NF)


Diagram Ketergantungan Fungsional
Kode-kota
No-pem
Kota
Jumlah
No-bar
Bentuk Normal Kedua (2NF)

Suatu relasi dikatakan sudah memenuhi Bentuk Normal Kedua bila
relasi tersebut sudah memenuhi bentuk Normal kesatu, dan atribut
yang bukan key sudah tergantung penuh terhadap keynya.
Tabel PEMASOK-1 (2NF)
No-pem Kode-kota Kota
P01 1 Jakarta
P02 3 Bandung
P03 2 Surabaya
Bentuk Normal Ketiga (3NF)

Suatu relasi dikatakan sudah memenuhi Bentuk Normal ketiga bila
relasi tersebut sudah memenuhi bentuk Normal kedua dan atribut
yang bukan key tidak tergantung transitif terhadap keynya.

Tabel KIRIM-3 (3NF)
No-pem No-bar Jumlah
P01 B01 1000

P01 B02 1500
P01 B03 2000
P02 B03 1000
P03 B02 2000
Tabel PEMASOK-2 (3NF) Tabel PEMASOK-3 (3NF)
No-pem Kode-kota Kode-kota Kota
P01 1 1 Jakarta
P02 3 2 Surabaya
P03 2 3 Bandung
Normalisasi pada database perkuliahan
Asumsi :
 Seorang mahasiswa dapat mengambil beberapa mata kuliah
 Satu mata kuliah dapat diambil oleh lebih dari satu mahasiswa
 Satu mata kuliah hanya diajarkan oleh satu dosen
 Satu dosen dapat mengajar beberapa mata kuliah
 Seorang mahasiswa pada mata kuliah tertentu hanya mempunyai
satu nilai

Tabel MAHASISWA-1 ( Unnormal )
No-Mhs Nama Jurusan Kode- Nama-MK Kode-Dosen Nama- Nilai
- Mhs MK Dosen
2683 Welli MI MI350 Manajamen DB B104 Ati A
MI465 Analsis Prc. Sistem B317 Dita B
5432 Bakri Ak. MI350 Manajemen DB B104 Ati C
AKN201 Akuntansi Keuangan D310 Lia B
MKT300 Dasar Pemasaran B212 Lola A
Tabel MAHASISWA-2 ( 1NF )

No- Nama- Jurusan Kode- Nama-MK Kode-Dosen Nama- Nilai
Mhs Mhs MK Dosen
2683 Welli MI MI350 Manajamen DB B104 Ati A
2683 Welli MI MI465 Analsis Prc. Sistem B317 Dita B
5432 Bakri Ak. MI350 Manajemen DB B104 Ati C
5432 Bakri Ak. AKN201 Akuntansi Keuangan D310 Lia B
5432 Bakri Ak. MKT300 Dasar Pemasaran B212 Lola A
Diagram Ketergantungan Fungsional

Nama_Mhs
No-Mhs Jurusan
Nilai
Nama-MK
Kode-MK Kode-Dosen
Nama-Dosen

Tabel KULIAH (2NF)
Nama-MK Kode-Dosen
MI350 Manajamen DB B104 Ati

MI465 Analsis Prc. Sistem B317 Dita
AKN201 Akuntansi Keuangan D310 Lia
MKT300 Dasar Pemasaran B212 Lola
Tabel MAHASISWA-3 (3NF)
Nama-Mhs Jurusan
2683 Welli MI
5432 Bakri Ak.
Tabel NILAI (3NF)

Nilai
2683 MI350 A
2683 MI465 B
5432 MI350 C
5432 AKN201 B
5432 MKT300 A
Tabel MATAKULIAH (3NF)

Kode-MK Nama-MK Kode-Dosen
MI350 Manajamen DB B104
MI465 Analsis Prc. Sistem B317
AKN201 Akuntansi Keuangan D310
MKT300 DasarPemasaran B212

Tabel DOSEN (3NF)
Kode- Dosen Nama-Dosen
B104 Ati
B317 Dita
B310 Lia
B212 Lola

DATA FLOW DIAGRAM
KASUS : SISTEM PEMINJAMAN UANG PADA KOPERASI KARYAWAN PT.

PENGERUKAN INDONESIA
ANALISIS MASALAH
Pinjaman Anggota :
 Pinjaman anggota koperasi karyawan PT. Pengerukan Indonesia adalah
pinjaman jangka panjang, yang dikelola untuk meningkatkan kesejahteraan
anggota. Pinjaman ini ditangani oleh pengurus koperasi dan kepala bagian
akunting.
 Anggota yang berhak meminjam uang adalah anggota yang bekerja pada
PT. Pengerukan Indonesia, dan pensiunan perusahaan tersebut yang
terdaftar menjadi anggota koperasi karyawan. Anggota yang berhak
meminjam uang adalah mereka yang sedang tidak meminjam uang ke
koperasi. Bagi anggota yang masih mempunyai pinjaman tidak
diperkenankan meminjam uang sampai pinjamannya lunas.
 Jika anggota disetujui untuk memperoleh pinjaman, maka anggota akan
memperoleh uang sebesar pinjaman serta tanda terima pinjaman.
 Besar pinjaman yang ditetapkan sesuai dengan slip gaji anggota dari instasi
PT. Pengerukan Indonesia. Pemotongan gai untuk pembayaran hutang harus
kurang dari 50% dari gajinya, dan maksimum pembayaran tiga bulan.
Sistem Pembayaran :
Sistem pembayaran tunai : dibayar langsung oleh peminjam kepada koperasi
sesuai dengan kesepakatan perjanjian dengan
koperasi yang memberikan pinjaman.
Sistem pembayaran payroll : pembayaran dilakukan oleh pihak ketiga, yaitu PT.
Pengerukan Indonesia melalui bagian akunting,
melalui pemotongan gaji karyawan.
Diagram Konteks
Daftar Nama Peminjam Bagian
FPP, Slip gaji Sistem Akunting
Peminjaman
Anggota Uang di
Koperasi PT.
Uang, TTP, Pengerukan Laporan pinjaman Pengurus
Informasi penolakan Indonesia bulanan Koperasi
Pinjaman
Diagram Zero
1
FPP, Slip Gaji Cek anggota Data Anggota
Anggota dan Anggota
menambah
data anggota
Data anggota
2 Data Pinjaman
Informasi Penolakan Menseleksi Pinjaman
Pinjaman pinjaman
Data Jumlah
Pinjaman
Data Jumlah
Pinjaman
3
Uang, TTP Data Transaksi
Transaksi
Pinjaman Transaksi
Pinjaman
5 Data Transaksi
Master Anggota 4
Membuat
Membuat
Data Data Jumlah
Daftar Nama
Data Anggota Laporan Pinjaman
Peminjam
Pinjaman
Bulanan Data Anggota
Daftar peminjam
Pinjaman Data Laporan pinjaman bulanan
Pinjaman
Bagian Pengurus
Keuangan Koperasi
FPP : Formulir Permohonan Pinjaman TTP : Tanda Terima Pinjaman
ERD SISTEM PEMINJAMAN UANG PADA KOPERASI KARYAWAN PT. PENGERUKAN
INDONESIA :
1 1
Transaksi
Anggota Pinjaman
No- Kd-Trans* Kd-Pinjam*

Anggota*
Nama Tgl-Pinjam Jml-Pinjam
Alamat Gapok
Bagian
Jabatan
Keterangan :
* : Primary Key
KASUS : SISTEM PEMBAYARAN PARKIR DI TOKO BUKU GRAMEDIA
MATRAMAN
ANALISIS SISTEM
Sistem yang Berjalan :

Suatu sistem pengolahan data kendaraan merupakan salah satu sistem yang
penting selain sistem keamanan, sistem penempatan kendaraan, dsb. Kesemua
sistem tersebut merupakan bagian dari sistem yang lebih besar, yaitu Sistem
Perpakiran.
Dalam Sistem Pengolahan Data Kendaraan yang ada di toko buku ini, sering
dijumpai masalah-mesalah seperti : kurangnya perhitungan waktu yang tepat
untuk menetapkan besarnya biaya yang yang harus dibayar oleh pengguna jasa
parkir. Hal ini dikarenakan sistem yang digunakan masih menerapkan sistem
karcis. Sehingga waktu yang terhitung dan besarnya tarif yang diberlakukan
masih menggunakan perhitungan manual. Untuk itu diperlukan suatu sistem
yang dapat memberikan kepastian, baik dalam hal perhitungan waktu, maupun
dalam hal menentukan besarnya biaya yang harus dikeluarkan oleh pengguna
jasa.
Sistem yang diusulkan :

Sistem Pembayaran Parkir yang baru akan berawal dari sebuah kendaraan
bermotor masuk ke dalam area perpakiran. Pada saat kendaraan tersebut
melalui pintu masuk area, maka dilakukan pendataan oleh petugas pintu masuk.
Pengguna jasa akan diberikan informasi mengenai area parkir yang kosong.
Dari pendataan yang dilakukan oleh petugas, data tersebut akan diproses lagi
pada saat kendaraan akan keluar melalui pintu keluar area. Dan hasil data yang
telah diproses akan dijadikan ukuran dalam menentukan lamanya waktu yang
digunakan dan besarnya biaya yang akan dikeluarkan oleh pengguna jasa parkir
tersebut.
Diagram Konteks :
Data kendaraan Sistem Laporan harian
Kendaraan Pembayaran Bagian
Parkir Laporan bulanan Keuangan
Tanda Parkir, Bukti Pembayaran
Informasi Lokasi Parkir

Diagram Zero :
1
Data Kendaraan Memeriksa Data Lokasi File Parkir
Kendaraan Informasi Lokasi lokasi
Parkir parkir
Tanda
Parkir Data
Kendaraan
Data Lokasi
Mbayaran
Data 3 Data 2 Kendaraan
Mencetak
Kendaraa Kendaraan Pendataan
Tanda kendaraan File Kendaraan
Parkir masuk
Bukti Pembayaran
Data Kendaraan
Data 4 Data Lokasi File Parkir

5 Pendataan
Mencetak Pembayar
an Kendaraan
Bukti
Keluar
Pembayaran
Data
Pembayaran
Data
6 Kendaraan
Mencetak
Laporan
Data Harian
File Kendaraan
7
Mencetak Kendaraan Laporan
Laporan Harian
Bulanan
Laporan
Bagian
Bulanan
Keuangan
KASUS : RANCANGAN SISTEM PENJUALAN PADA BUTIK BUSANA
MUSLIM BAIT AZ-ZAHRA
Butik busana muslim Bait Az-Zahra beralamat di Jl. Iskandarsyah Raya No.96 A Kebayoran
Baru Jakarta Selatan ini dibuka pada tanggal 27 Juli 2002. Butik ini menyediakan beberapa
jenis busana muslim yang diproduksi sendiri, mulai dari stelan tunik, abaya dan baju koko.
Karena dirasakan usaha busana muslim ini semakin berkembang, maka butik yang semula
hanya berdiri 1 lantai, ditambah menjadi 2 lantai. Seiring dengan itu piula, maka pemilik mulai
mengupayakan untuk menambah menjual perlengkapan muslim lainnya seperti mukena,
buku-buku agama pilihan dan juga pasmina.
Prosedur penjualan yang sedang berlangsung di butik ini adalah :

1. Konsumen datang memesan barang
2. Dari proses tersebut kemudian dicatat dalam faktur rangkap 2
3. Selanjutnya faktur yang berwarna merah diserahkan ke konsumen, sedangkan faktur yang
berwarna putih disimpan untuk kemudian dicatat di data konsumen, data barang dan data
transaksi.
4. Setelah itu dibuat laporan penjualan untuk diserahkan ke pemilik.
Diagram Konteks :
Data pesanan Laporan

Sistem Penjualan
Konsumen penjualan Pemilik
Faktur penjualan
Informasi penolakan
Diagram Zero :
1
Konsumen Data pesanan Memeriksa Data barang
barang Barang
Informasi penolakan
Data
barang
2
Cek & Data Konsumen
Input Konsumen
konsumen
Data barang
Data konsumen
3
Faktur penjualan Transaksi & Data barang terjual
Pembuatan
faktur
Data transaksi
Transaksi
Data
transaksi
Data
4 brg
Membuat
Laporan
penjualan Data
konsumen
Laporan
Penjualan
Pemilik
ERD SISTEM PENJUALAN PADA BAIT AZ-ZAHRA :
M Beli N
Konsumen Barang
Kd-Kons No-Faktur Kd-Brg
Nama-Kons Tgl-Jual Nama-Brg
Alamat Jumlah Hrg-Brg
No-Telp Total Jml-Stok

KASUS : SISTEM PEMESANAN TIKET KERETA API PADA PT. KERETA API
INDONESIA (PT. KAI)
Prosedur yang sedang berjalan :

Pemesan mengisi formulir pesanan tiket yang telah disiapkan oleh Bagian Pemesanan.
Adapun yang diisi di dalam formulir pesanan diantaranya adalah Nama pemesan, alamat,
No.telpon, nama kereta api, kelas, tgl.berangkat dan jumlah pesanan. Setelah formulir diisi
dengan benar, formulir di serahkan ke Bagian Pemesanan. Data pesanan akan di entry ke
dalam komputer dan disimpan di dalam file. Pembayaran dilakukan secara tunai. Setelah
proses pembayaran selesai, maka pemesan mendapat bukti pembayaran berupa kwitansi
dan bukti pemberangkatan berupa tiket kereta api.
Prosedur yang diusulkan:

Prosedur yang diusulkan tidak jauh berbeda dengan prosedur yang telah berjalan
sebelumnya, hanya pada prosedur yang diusulkan akan ditambah satu item yaitu No.ID
Pemesan bedasarkan urutan formulir data pesanan yang masuk ke Bagian Pemesanan.
Diagram Konteks :
Data pemesan,
FPT Sistem
Pemesanan Lap.pemesanan tiket
Pemesan Pimpinan
Tiket PT. KAI
Informasi tolak,
Kwitansi, Tiket
Diagram Zero :
Data pemesan,
FPT 1
Memeriksa Data kereta Kereta
Pemesan kereta
Informasi tolak
Data kereta,
Data pemesan
2
Memeriksa & Data pemesan
menambah Pemesan
data
pesanan
Data kereta,
Data pemesan
3 Data kereta yang dipesan

Kwitansi, Tiket Transaksi
Pemesanan
tiket dan Data transaksi
Pembuatan
kwitansi
Transaksi
Data
transaksi
Data
Laporan pemesan tiket 4
Pimpinan Membuat pemesan
PT. KAI laporan
Data kereta
FPT : Formulir Pemesanan Tiket

ERD SISTEM PEMESANAN TIKET KERETA API :
Kd-KA *
Kd-Tiket * Jam-Dtg
Nama-KA
Tgl_Pesan Jml-Dws
Kelas-KA
Tgl-Brkt Jml-Anak
Tujuan
Jam-Brkt Jml-Lansia
M Transaksi N
Pemesan Kereta
No-ID * Tot-Penump Hrg-Dws
Nm-Pms Tot-Bayar Hrg-Anak
Alamat Hrg-Lansia
Bea_Pesan
No-Telp No-
Gerbong
No-Kursi
Keterangan :
* : Primary Key
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:
Seluruh dokumen di IlmuKomputer.Com dapat digunakan, dimodifikasi dan disebarkan
secara 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.
Pendahuluan
Saat ini piranti lunak semakin luas dan besar lingkupnya, sehingga tidak bisa lagi dibuat asal-asalan.
Piranti lunak saat ini seharusnya dirancang dengan memperhatikan hal-hal seperti scalability,
security, dan eksekusi yang robust walaupun dalam kondisi yang sulit. Selain itu arsitekturnya harus
didefinisikan dengan jelas, agar bug mudah ditemukan dan diperbaiki, bahkan oleh orang lain selain
programmer aslinya. Keuntungan lain dari perencanaan arsitektur yang matang adalah
dimungkinkannya penggunaan kembali modul atau komponen untuk aplikasi piranti lunak lain yang
membutuhkan fungsionalitas yang sama.
Pemodelan (modeling) adalah proses merancang piranti lunak sebelum melakukan pengkodean
(coding). Model piranti lunak dapat dianalogikan seperti pembuatan blueprint pada pembangunan
gedung. Membuat model dari sebuah sistem yang kompleks sangatlah penting karena kita tidak
dapat memahami sistem semacam itu secara menyeluruh. Semakin komplek sebuah sistem, semakin
penting pula penggunaan teknik pemodelan yang baik.
Dengan menggunakan model, diharapkan pengembangan piranti lunak dapat memenuhi semua
kebutuhan pengguna dengan lengkap dan tepat, termasuk faktor-faktor seperti scalability, robustness,
security, dan sebagainya.
Kesuksesan suatu pemodelan piranti lunak ditentukan oleh tiga unsur, yang kemudian terkenal
dengan sebuan segitiga sukses (the triangle for success). Ketiga unsur tersebut adalah metode
pemodelan (notation), proses (process) dan tool yang digunakan.
1
Memahami notasi pemodelan tanpa mengetahui cara pemakaian yang sebenarnya (proses) akan
membuat proyek gagal. Dan pemahaman terhadap metode pemodelan dan proses disempurnakan
dengan penggunaan tool yang tepat.
Apa itu UML
Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah menjadi standar dalam
industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML
menawarkan sebuah standar untuk merancang model sebuah sistem.
Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak,
dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta
ditulis dalam bahasa pemrograman apapun. Tetapi karena UML juga menggunakan class dan
operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa-
bahasa berorientasi objek seperti C++, Java, C# atau VB.NET. Walaupun demikian, UML tetap
dapat digunakan untuk modeling aplikasi prosedural dalam VB atau C.
Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan syntax/semantik. Notasi UML
merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak.
Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk
tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada
sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling
Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering).
Sejarah UML sendiri cukup panjang. Sampai era tahun 1990 seperti kita ketahui puluhan metodologi
pemodelan berorientasi objek telah bermunculan di dunia. Diantaranya adalah: metodologi booch [1],
metodologi coad [2], metodologi OOSE [3], metodologi OMT [4], metodologi shlaer-mellor [5],
metodologi wirfs-brock [6], dsb. Masa itu terkenal dengan masa perang metodologi (method war)
dalam pendesainan berorientasi objek. Masing-masing metodologi membawa notasi sendiri-sendiri,
yang mengakibatkan timbul masalah baru apabila kita bekerjasama dengan group/perusahaan lain
yang menggunakan metodologi yang berlainan.
2
Rumbaugh
Booch Jacobson
Odell OMG
(Object Management Group)
Shlaer and Mellor Meyer
Gamma
Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan tiga tokoh
yang boleh dikata metodologinya banyak digunakan mempelopori usaha untuk penyatuan
metodologi pendesainan berorientasi objek. Pada tahun 1995 direlease draft pertama dari UML
(versi 0.8). Sejak tahun 1996 pengembangan tersebut dikoordinasikan oleh Object Management
Group (OMG – http://www.omg.org). Tahun 1997 UML versi 1.1 muncul, dan saat ini versi terbaru
adalah versi 1.5 yang dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson menyusun tiga buku
serial tentang UML pada tahun 1999 [7] [8] [9]. Sejak saat itulah UML telah menjelma menjadi
standar bahasa pemodelan untuk aplikasi berorientasi objek.
Konsepsi Dasar UML

Dari berbagai penjelasan rumit yang terdapat di dokumen dan buku-buku UML. Sebenarnya
konsepsi dasar UML bisa kita rangkumkan dalam gambar dibawah.
3
Abstraksi konsep dasar UML yang terdiri dari structural classification, dynamic behavior, dan
model management, bisa kita pahami dengan mudah apabila kita melihat gambar diatas dari
Diagrams. Main concepts bisa kita pandang sebagai term yang akan muncul pada saat kita membuat
diagram. Dan view adalah kategori dari diagaram tersebut.
Lalu darimana kita mulai ? Untuk menguasai UML, sebenarnya cukup dua hal yang harus kita
perhatikan:
1. Menguasai pembuatan diagram UML
2. Menguasai langkah-langkah dalam analisa dan pengembangan dengan UML
Tulisan ini pada intinya akan mengupas kedua hal tersebut.
Seperti juga tercantum pada gambar diatas UML mendefinisikan diagram-diagram sebagai berikut:
• use case diagram
• class diagram
• statechart diagram
• activity diagram
• sequence diagram
• collaboration diagram
• component diagram
• deployment diagram
Use Case Diagram
Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang
ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case
merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah
pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya.
Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem
untuk melakukan pekerjaan-pekerjaan tertentu.
Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem,
mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang
ada pada sistem.
Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam
dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use
case yang meng-include dieksekusi secara normal.
Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas
dapat dihindari dengan cara menarik keluar fungsionalitas yang common.
Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri.
Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan
spesialisasi dari yang lain.
4
Contoh use case diagram :
Class Diagram
Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan
merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan
(atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut
(metoda/fungsi).
Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan
satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.
Class memiliki tiga area pokok :

1. Nama (dan stereotype)
2. Atribut
3. Metoda
Atribut dan metoda dapat memiliki salah satu sifat berikut :

• Private, tidak dapat dipanggil dari luar class yang bersangkutan
• Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang
mewarisinya
• Public, dapat dipanggil oleh siapa saja
Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki
metoda. Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu
menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time.
5
Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi package. Kita juga
dapat membuat diagram yang terdiri atas package.
Hubungan Antar Class
1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki
atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah
navigability menunjukkan arah query antar class.
2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).
3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan
mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru,
sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah
generalisasi.
4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari satu class kepada
class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram
yang akan dijelaskan kemudian.
Contoh class diagram :
6
Statechart Diagram
Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya)
suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart
diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart
diagram).
Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama
sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan
syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan
sebagai akibat dari event tertentu dituliskan dengan diawali garis miring.
Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan berwarna setengah.
Contoh statechart diagram :
Activity Diagram
Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang,
bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka
berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada
beberapa eksekusi.
Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan
sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh
karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi
antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas
dari level atas secara umum.
Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses
yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk
melakukan aktivitas.
7
Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk
menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi
tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi
yang dapat berupa titik, garis horizontal atau vertikal.
Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana
yang bertanggung jawab untuk aktivitas tertentu.
Contoh activity diagram tanpa swimlane:
Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk
pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence
diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).
Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah
yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari
apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal
dan output apa yang dihasilkan.
Masing-masing objek, termasuk aktor, memiliki lifeline vertikal.

Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain
berikutnya, message akan dipetakan menjadi operasi/metoda dari class.
Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya
sebuah message.
8
Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk
objek boundary, controller dan persistent entity.
Contoh sequence diagram :
Collaboration Diagram
Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi
lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message.
Setiap message memiliki sequence number, di mana message dari level tertinggi memiliki nomor 1.
Messages dari level yang sama memiliki prefiks yang sama.
Component Diagram
Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak,
termasuk ketergantungan (dependency) di antaranya.
9
Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik
library maupun executable, baik yang muncul pada compile time, link time, maupun run time.
Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari
komponen-komponen yang lebih kecil.
Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen
untuk komponen lain.
Contoh component diagram:
Deployment Diagram
Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam

infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa),
bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang
bersifat fisikal
Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy
komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement
dapat juga didefinisikan dalam diagram ini.
10
Contoh deployment diagram :
Langkah-Langkah Penggunaan UML
Berikut ini adalah tips pengembangan piranti lunak dengan menggunakan UML:
1. Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan
proses yang mungkin muncul.
2. Petakan use case untuk tiap business process untuk mendefinisikan dengan tepat
fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram dan
lengkapi dengan requirement, constraints dan catatan-catatan lain.
3. Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem.
4. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus
disediakan oleh sistem.
5. Berdasarkan use case diagram, mulailah membuat activity diagram.
6. Definisikan objek-objek level atas (package atau domain) dan buatlah sequence dan/atau
collaboration diagram untuk tiap alir pekerjaan. Jika sebuah use case memiliki
kemungkinan alir normal dan error, buatlah satu diagram untuk masing-masing alir.
7. Buarlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk
menjalankan skenario use case.
8. Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap package atau
domain dipecah menjadi hirarki class lengkap dengan atribut dan metodanya. Akan lebih
11
baik jika untuk setiap class dibuat unit test untuk menguji fungsionalitas class dan interaksi
dengan class lain.
9. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class
menjadi komponen-komponen. Karena itu buatlah component diagram pada tahap ini. Juga,
definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.
10. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement
piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.
11. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan :
• Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang
tertentu untuk mengembangkan unit code yang lengkap dengan tes.
• Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim
pengembang tertentu.
12. Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus
selalu sesuai dengan code yang aktual.
13. Piranti lunak siap dirilis.
Tool Yang Mendukung UML

Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool komersial maupun
opensource. Beberapa diantaranya adalah:
• Rational Rose (www.rational.com)
• Together (www.togethersoft.com)
• Object Domain (www.objectdomain.com)
• Jvision (www.object-insight.com)
• Objecteering (www.objecteering.com)
• MagicDraw (www.nomagic.com/magicdrawuml)
• Visual Object Modeller (www.visualobject.com)
Data seluruh tool yang mendukung UML, lengkap beserta harganya (dalam US dolar) bisa anda
pelajari di situs http://www.objectsbydesign.com/tools/umltools_byCompany.html . Disamping itu,
daftar tool UML berikut fungsi dan perbangingan kemampuannya juga dapat dilihat di
http://www.jeckle.de/umltools.htm.
Pointer Penting UML

Sebagai referensi dalam mempelajari dan menggunakan UML, situs-situs yang merupakan pointer
penting adalah:
• http://www.cetus-links.org/oo_uml.html
• http://www.omg.org
• http://www.omg.org/technology/uml/
• http://www.rational.com/uml
• http://www.uml.org/
Dan juga buku-buku yang terdapat di daftar pustaka.
12
Daftar Pustaka
[1] Grady Booch, Object-Oriented Analysis and Design with Application, Benjamin/Cummings,
1991.
[2] Peter Coad and Edward Yourdon, Object-Oriented Analysis, Yourdon Press, 1991.
[3] Ivar Jacobson, Magnus Christerson, Patrik Jonson, and Gunnar Overgaard, Object-Oriented
Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992.
[4] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorenson,
Object-Oriented Modeling and Design, Prentice Hall, 1991.
[5] Sally Shlaer and Stephen J. Mellor, Object-Oriented System Analysis: Modeling the World in
Data, Yourdon Press, 1988.
[6] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener, Designing Object-Oriented
Software, Prentice Hall, 1990.
[7] Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified Modeling Language User
Guide, Addison-Wesley, 1999.
[8] Ivar Jacobson, Grady Booch, and James Rumbaugh, The Unified Software Development
Process, Addison-Wesley, 1999.
[9] James Rumbaugh, Ivar Jacobson, and Grady Booch, The Unified Modeling Language
Reference Manual, Addison-Wesley, 1999.
[10] Unified Modeling Language Specification, Object Management Group, www.omg.org, 1999.
[11] Introduction to OMG UML [http://www.omg.org/gettingstarted/what_is_uml.htm]
[12] UML Tutorial [http://www.sparxsystems.com.au/UML_Tutorial.htm]
[13] Embarcadero Tech Support [http://www.embarcadero.com/support/uml_central.asp]
[14] Practical UML A Hands-On Introduction for Developers,
[http://www.togethersoft.com/services/practical_guides/umlonlinecourse/index.html]
[15] Architecture and Design: Unified Modeling Language (UML), [http://www.cetus-
links.org/oo_uml.html]
13
2.1 Aliran Sistem Informasi (ASI)
Aliran sistem informasi menunjukkan arus pekerjaan secara keseluruhan dari sistem.
Aliran sistem informasi dapat ditunjukkan dengan bagan alir sistem yang disebut dengan
system flowchart. Bagan ini menjelaskan urutan – urutan dari prosedur – perosedur yang ada
didalam sistem. Bagan alir sistem menunjukkan apa yang dikerjakan di sistem. Bagan alir
sistem ditunjukkan dengan simbol – simbol sebagai berikut :
Simbol Keterangan
“Simbol Dokumen” yang menunjukkan dokumen input
dan output baik untuk proses manual, mekanik atau
komputer.
“Simbol Kegiatan Manual” yang menunjukkan pekerjaan
manual.
“Simbol Kartu Plong” menunjukkan input atau output
yang menggunakan kartu plong (punched card).
“Simbol Proses” menunjukkan kegiatan proses dari
operasi program komputer.
“Simbol Operasi Luar” menunjukkan operasi yang
dilakukan diluar proses operasi komputer.
“Simbol Pengurutan Offline” menunjukkan proses
pengurutan data diluar proses komputer.
“Simbol Pita Magnetik” menunjukkan input atau output
menggunakan pita mengetik.
“Simbol Diskette” menunjukkan input atau output
menggunakan diskette.
Simbol Keterangan
“Simbol Keyboard” menunjukkan input yang
menggunakan keyboard.
“Simbol Keputusan” digunakan untuk menyelesaikan
kondisi didalam program.
“Simbol Proses Terdefinisi” digunakan untuk
menunjukkan suatu operasi yang rinciannya ada ditempat
lain.
“Simbol Persiapan” digunakan untuk memberikan nilai
awal suatu besaran.
“Simbol Penghubung” digunakan untuk menunjukkan
sambungan dari bagan alir yang terputus di halaman yang
masih sama atau di halaman lainnya.
“Simbol Garis Alir” digunakan untuk menunjukkan arus
dari proses.
Tabel 2.1 Simbol – simbol Sistem Informasi

Analisa Dan Perancangan Sistem Informasi

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Analisa Dan Perancangan Sistem Informasi

Diunggah oleh

Hak Cipta:

Format Tersedia

ANALISA DAN PERANCANGAN

Dosen : Hanafi, M.Kom / M.Ropianto, M.Kom

1 PENDAHULUAN 1. Ruang Lingkup Mata Kuliah Kuliah mimbar OHT, papan 1, 4, 5, 7,

PENGERTIAN SISTEM 1. Definisi Sistem

4 PERANCANGAN 1. Pendahuluan Kuliah mimbar OHT, papan 1, 2, 4, 5,

SAP-Analisis dan Perancangan Sistem Informasi 2

DATA FLOW DIAGRAM

7 FLOWCHART 1. Pedoman-pedoman dalam membuat Kuliah mimbar OHT, papan 4, 6, 7

8 PERANCANGAN 1. Perancangan Output Kuliah mimbar OHT, papan 1, 2, 4, 5,

9 dan 10 PERANCANGAN 1. Perancangan Database Kuliah mimbar OHT, papan 1, 2, 3, 4,

11 PENDEKATAN 1. Pendahuluan. Kuliah mimbar OHT, papan 10, 11, 12

12 PERANCANGAN 1. Pengenalan UML. Kuliah mimbar OHT, papan 10, 13

13 DAN 14 PEMBAHASAN TUGAS Contoh kasus dengan pemecahan masalah yang

SAP-Analisis dan Perancangan Sistem Informasi 5

SAP-Analisis dan Perancangan Sistem Informasi 6

Informasi dapat dipandang sebagai suatu sumber daya organisasional.

Semua sistem informasi terkomputerisasi memiliki basis data dasar yang

Sistem Informasi Manajemen (SIM) adalah sistem terkomputerisasi yang

Penganalisis bisa dipanggil berdasarkan hal itu untuk merancang berbagai

Analisis dan Perancangan Sistem Halaman 1 dari 2

Analisis dan perancangan sistem adalah suatu pendekatan yang sistematis

Peranan Penganalisis Sistem

Penganalisis sistem secara sistematis menilai bagaimana fungsi bisnis

Penganalisis harus mampu bekerja dengan orang-orang dari semua

Tiga peran Penganalisis sistem adalah :

Penganalisis memiliki kemampuan yang beragam. Pertama yang paling

Analisis dan Perancangan Sistem Halaman 2 dari 2

Sistem adalah sekumpulan unsur / elemen yang saling berkaitan dan

Menurut LUDWIG VON BARTALANFY

Menurut ANATOL RAPOROT

Analisis dan Perancangan Sistem Halaman 1 dari 9

A. SISTEM FISIK ( PHYSICAL SYSTEM ) :

B. SISTEM ABSTRAK ( ABSTRACT SYSTEM) :

§ MODEL UMUM SISTEM

Model sistem sederhana

input proses output

Analisis dan Perancangan Sistem Halaman 2 dari 9

Contoh : Matriks → masukannya banyak, keluarannyapun banyak

MRKT PROD ADM SUB SISTEM

Analisis dan Perancangan Sistem Halaman 3 dari 9

- Fungsi departemen marketing.

- Fungsi departemen keuangan dan administrasi.

Analisis dan Perancangan Sistem Halaman 4 dari 9

Contoh : suatu perusahaan memerlukan pemusatan tujuan.

Analisis dan Perancangan Sistem Halaman 5 dari 9

Contoh : reaksi kimia dalam tabung berisolasi dan tertutup.

E. RELATIVELY CLOSED SISTEM

Contoh : laut, pantai, atmosfer, tata surya, dll.

Analisis dan Perancangan Sistem Halaman 6 dari 9

Perancang sistem lebih banyak menggunakan metode " Relatively

Metode ini hanya dapat dimengerti oleh pihak dalam ( yang

Contoh : bagian pencetakan uang, proses pencernaan.

Analisis dan Perancangan Sistem Halaman 7 dari 9

Dalam metode ini beberapa langkah diberikan seperti di bawah ini :

b. Menentukan tujuan dari sistem.

c. Bagian-bagian apa saja yang terdapat dalam sistem dan apa

d. Bagaimana bagian-bagian yang ada dalam sistem itu saling

4. PENGERTIAN ANALISIS SISTEM

Analisis dan Perancangan Sistem Halaman 8 dari 9

Pengertian sistem analis ini dapat digambarkan sebagai berikut :

USER ANALIS SISTEM PROGRAMMER

5. FUNGSI ANALIS SISTEM

Fungsi Analisis Sistem adalah