1 | P a g e R P L 1

4. PEMODELAN ANALISIS

Topik meliputi :

1. Elemen Model Analisa

2. Pemodelan Data

3. Pemodelan Fungsional dan Aliran Informasi

4. Petunjuk Dalam pemakaian Penamaan

5. Kamus Data (Data Dictionary)

6. Normalisasi Data

7. Entity Relationship Diagram (ERD)

8. Diagram Warnier

9. Sistim Pengembangan Jackson (JSD – JACKSON SYSTEM DEVELOPMENT)

10. SADT (Structural Analysis and Design Technique)

Tujuan bab ini dapat memahami :

Model Elemen analisa.

Konsep data flow diagram, konteks dan levelisasi.

Entity relational diagram (ERD), obyek data, atribut dan hubungan.

Pada tingkat teknik, rekayasa perangkat lunak dimulai dengan serangkaian tugas pemodelan yang

membawa kepada suatu spesifikasi lengkap dari persyaratan representasi dan representasi desain

yang komprehensif bagi perangkat lunak yang dibangun.

1. ELEMEN MODEL ANALISA

Model analisa harus dapat mencapai tiga sasaran utama penting yakni :

o Menggambarkan apa yang dibutuhkan untuk pelanggan.

o Membangun dasar bagi pembuatan desain perangkat lunak.

o Membatasi serangkaian persyaratan yang dapat divalidasi begitu perangkat lunak

dibangun.

Gambar Proses penerjemahan model analisa ke suatu desain perangkat lunak.

2 | P a g e R P L 1

Untuk mencapai sasaran tersebut dibuatlah model analisa yang berisi :

Data Dictionary

Penyimpanan yang berisi diskripsi dari semua obyek data yang dikonsumsi atau diproduksi

oleh perangkat lunak.

Entity Relationship Diagram (ERD)

Menggambarkan hubungan antara obyek data.

Data Flow Diagram (DFD)

Memberikan indikasi mengenai bagaimana data ditransformasi pada saat data bergerak

melalui sistim.

Menggambarkan fungsi-fungsi (dan sub fungsi) yang mentransformasikan aliran data.

State Transition Diagram

Menunjukkan bagaimana sistim bertingkah laku sebagai akibat dari kejadian eksternal.

Control Specification (CSPEC)

Informasi tambahan mengenai aspek kontrol dari perangkat lunak.

Design Data

Mentransformasikan model domain informasi yang dibuat selama analisa ke dalam struktur

data yang akan diperlukan untuk mengimplementasikan perangkat lunak.

Design Arsitektur

Menentukan hubungan antara elemen-elemen struktural utama dari program.

Representasi desain tersebut, kerangka kerja modular dari sebuah program komputer,

sehingga dapat diperoleh dari model-model analisa dan interaksi subsistim yang ditentukan

dalam model analisa.

Design Interface

Menggambarkan bagaimana perangkat lunak dapat berkomunikasi dalam dirinya sendiri dan

dengan manusia yang menggunakannya.

Interface mengimplikasi aliran informasi (misalnya data dan atau control) dengan demikian,

data dan diagram aliran control memberikan informasi yang dibutuhkan bagi desain interface.

Desain Prosedural

Mentransformasikan elemen-elemen structural dari arsitektur program kedalam suatu

diskripsi prosedural dari komponen-komponen perangkat lunak.

3 | P a g e R P L 1

2. PEMODELAN DATA

Untuk dapat menjawabnya pertanyaan sebagai berikut :

Bagaimana komposisi dari masing-masing obyek data dan atribut apa yang menggambarkan

obyek tersebut ?

Dimana obyek saat ini berada ?

Bagaimana hubungan antara masing-masing obyek data dan obyek lainnya ?

Bagaimana hubungan antara obyek dengan proses yang mentransformasikannya ?

Digunakan Entity Relational Diagram (ERD)

2.1. OBYEK DATA, ATRIBUT DAN HUBUNGAN

Pada model data ada 3 informasi yang saling berhubungan yaitu antara lain :

2.1.1. OBYEK DATA

2.1.2. ATRIBUT

2.1.3. HUBUNGAN

2.1.1. OBJEK DATA

Adalah representasi dari hampir semua informasi gabungan yang harus dipahami oleh perangkat

lunak.

2.1.2. ATRIBUT

Menentukan property suatu obyek data dan mengambil salah satu dari tiga karakteristik yang

berbeda.

Menamai sebuah contoh dari obyek data.

Menggambarkan contoh.

Membuat referensi ke contoh yang lain pada tabel yang lain.

2.1.3. HUBUNGAN

Obyek data disambungkan satu dengan lainnya dengan berbagai macam cara.

2.2. KARDINALITAS DAN MODALITAS

Merupakan spesifikasi dari sejumlah peristiwa dari suatu obyek yang dapat dihubungkan ke

sejumlah peristiwa dari obyek yang lain.

Berikut penjelasan dan contoh masing-masing.

2.2.1. KARDINALITAS

Model data harus dapat merepresentasikan jumlah peristiwa dari obyek didalam hubungan yang

diberikan.

Satu ke satu (1:1)

Contoh :

seorang suami hanya dapat memiliki satu istri, dan seorang istri hanya mempunyai satu

suami.

Satu ke banyak (1:N)

Contoh:

4 | P a g e R P L 1

seorang ibu dapat memiliki banyak anak tetapi seorang anak hanya dapat memiliki satu ibu.

Banyak ke banyak (M:N)

Contoh:

seorang paman dapat memiliki banyak keponakan, sementara itu seorang keponakan dapat

memiliki banyak paman.

2.2.2. MODALITAS

Modalitas dari suatu hubungan adalah nol bila tidak ada kebutuhan eksplisit untuk hubungan

yang terjadi atau hubungan itu bersifat opsional.

Modalitas bernilai satu jika suatu kejadian dari hubungan merupakan perintah.

Gambar Hubungan antara Kardinalitas dan Modalitas.

Contoh :

Sebuah perangkat lunak yang digunakan oleh perusahaan telepon lokal untuk memproses permintaan

pelayanan lapangan.

Seorang pelanggan menunjukkan bahwa salah satu dari pelanggan mengalami masalah.

Jika masalah tersebut didiagnosis sebagai masalah yang sederhana maka dilakukan aksi perbaikan

tunggal dan jika masalahnya rumit maka dilakukan aksi perbaikan bertingkat.

Perhatikan gambar diatas, yang menggambarkan hubungan, kardinalitas dan modalitas antara obyek

data pelanggan dan aksi perbaikan.

Pelanggan Tindakan

Perbaikan

Kardinalitas

Mengimplikasikan bahwa

pelanggan tunggal menunggu tindakan perbaikan

Kardinalitas

Mengimplikasikan bahwa Ada banyak tindakan perbaikan

Modalitas : Harus

Mengimplikasikan bahwa

Untuk mempunyai tindakan perbaikan, kita harus ada pelanggan.

Modalitas : Opsional

Mengimplikasikan bahwa

Ada situasi diamana tindakan perbaikan tidak diperlukan

5 | P a g e R P L 1

3. PEMODELAN FUNGSIONAL DAN ALIRAN INFORMASI

Informasi ditransformasikan pada saat dia mengalir melalui sebuah sistim berbasis komputer.

Sistim tersebut menerima input dengan berbagai cara dan menghasilkan suatu output.

Akibatnya kita dapat menciptakan suatu model aliran bagi setiap sistim berbasis komputer tanpa

melihat ukuran dan kompleksitasnya.

3.1. DIAGRAM ALIRAN DATA / DATA FLOW DIAGRAM (DFD)

Merupakan sebuah teknik grafis yang menggambarkan aliran informasi dan transformasi yang

diaplikasikan pada saat data bergerak dari input menjadi output. Dikenal juga dengan sebutan grafik

aliran data atau Bubble Chart.

Keuntungan menggunakan data flow diagram adalah memudahkan pemakai (user) yang kurang

menguasai bidang computer untuk mengerti sistim yang akan dikerjakan atau dikembangkan.

Arus dari data tersebut nantinya dapat di jelaskan dengan menggunakan kamus data (Data

Dictionary).

Gambar Contoh Diagram aliran data / data flow diagram.

Beberapa komponen yang disimbolkan dalam Data Flow Diagram antara lain sebagai berikut :

3.1.1. Proses

3.1.2. File atau Data Store

3.1.3. External entity / Sumber / Sink

3.1.4. Data Flow

3.1.1. PROSES

Proses menunjukkan apa yang dikerjakan oleh sistim.

6 | P a g e R P L 1

Setiap proses memiliki nama yang unik dan nomor yang ditempatkan dalam simbol.

Simbol proses terdiri dari :

Gambar Simbol Proses.

3.1.2. FILE ATAU DATA STORE

File atau Data Store adalah tempat penyimpanan data.

Proses dapat menempatkan data ke dalam data store atau mengambil / mendapatkan data store.

Setiap data store rnempunyai nama yang unik.

Simbol File atau Data Store terdiri dari :

Gambar Simbol File atau Data Store.

3.1.3. EXTERNAL ENTITY / SUMBER / SINK

o External entity adalah diluar sistim, tetapi mereka merupakan salah satu bagian yang memberikan

input data kedalam sistim atau digunakan oleh output sistim.

o Source adalah External entity yang memberikan input data kedalam sistim.

o Sinks adalah External entity yang menggunakan data sistim.

o Simbol :

Gambar Simbol External entity.

3.1.4. DATA FLOW

Aliran data / data flow merupakan arus informasi yang mengalir dari atau ke proses, entity

ataupun data store.

Aliran data / data flow pada sistim yang di perbolehkan adalah :

Antara dua proses.

Dari sebuah data store ke sebuah proses.

Dari sebuah proses ke sebuah data store.

Dari sebuah source ke sebuah proses.

Dari sebuah proses ke sebuah sink.

Simbol :

7 | P a g e R P L 1

Gambar Simbol Data Flow.

Perhatikanlah bahwa apabila kita menggambarkan sebuah sistim maka simbol-simbol data flow

diagram tersebut akan digunakan.

3.2. MENGGAMBARKAN SISTIM DENGAN DATA FLOW DIAGRAM

Langkah awal yang harus dibuat adalah membuat "DIAGRAM KONTEKS", yaitu DFD di mana

sistim terdiri dari satu proses.

Pada tahap ini terlihat semua external entity yang berinteraksi dengan sistim dan data flow, antara

external entity dan sistim, dan pada DFD tidak diperkenankan mempunyai data store.

Gambar Contoh diagram Konteks Budget monitoring sistim.

Jika anda perhatikan dari gambar diatas, diagram konteks, maka pada level konteks tidak ada simbol

store dan sistim berinteraksi dengan 3 simbol external entity, antara lain :

1. DEPARTEMENTS

2. MANAGEMENTS

3. SUPPLIERS

Aliran data utama dari Departements adalah "Spending Request".

Sebagai tanggapan dari sistim, Departemen menerima "Rejected Request" atau aliran data

"Delivery Advice".

Management menerima data flow "Request For Special Approval", yang kemudian

memberikan respons.

8 | P a g e R P L 1

Management juga mengirim data flow “Budget Allocation” ke sistim dan mendapatkan data

flow “Spending Summaries”.

Supplier menerima data flow “Part Order” dan mengembalikan data flow “Supplier Delivery

Advice”.

Setelah mendapatkan “Diagram Konteks”, langkah selanjutnya adalah membuat DFD yang

memperlihatkan proses dari sistim utama, yang dinamakan dengan DFD LEVEL TINGKAT 1.

Gambar Contoh diagram konteks level tingkat 1.

Budget monitoring sistim.

Pada diagram konteks level 1 diatas memperlihatkan berbagai proses yang membentuk sistim dimana

terdiri dari 5 simbol proses dan setiap proses mempunyai simbol dan nama yang unik serta nomor

proses dari masing-masing simbol.

DFD diatas kita lihat bahwa data flow “Spending Request” dari Departements menuju ke

proses “Check Funding”.

Proses “Check Funding” melihat “Allocated Budget” dan menetapkan apakah izin khusus

diperlukan dari management untuk diteruskan ke permintaan.

Data flow “Approved Request” menuju ke proses “Classify Expenditure”, dan kemudian

dimasukkan pada data store “Departemental-Accounts” dan “Type-Accounts”.

Akhirnya, jika diperlukan, “Part Order” untuk menetapkan bagian ( part ) semula dalam

“Spending Request” diurus oleh supplier.

9 | P a g e R P L 1

Dua proses lainnya : “Setup Budget” dan “Provide Spending Summaries”.

Kita dapat memperluas setiap proses pada Level DFD selanjutnya.

Sebagai contoh diambil proses “Classify Expenditure”.

Pada level ini simbol proses harus diisi nama yang unik serta nomor seperti yang terlihat pada proses

Classify Expenditure dengan nomor 3.1 (gambar dibawah) demikian juga untuk proses selanjutnya

sehingga akan mendapatkan aliran data yang menunjukkan hubungan satu proses ke proses yang

lainnya.

Gambar Contoh diagram konteks level tingkat 1 ke level tingkat 2.

10 | P a g e R P L 1

Gambar Contoh diagram konteks level 1

yang di sertai dengan keterangan pada setiap proses dan aliran data.

Data Flow Diagram yang baik :

1. Ketiadaan dari struktur flowchart.

2. Penyimpanan data.

3. Penamaan yang baik.

Perbedaan antara Flowchart dan Data Flow Diagram :

Flowchart terdiri dari box-box yang mendiskripsikan :

Komputasi.

Decision / Keputusan.

Iterasi.

Loop.

Data Flow Diagram bukan Flowchart program dan tidak mempunyai elemen control.

11 | P a g e R P L 1

3.3. FAKTOR YANG HARUS DIPERHATIKAN DALAM MEMBUAT DECISIONS

DAN INTERACTIVE CONTROL

Hal yang terpenting adalah bagaimana anda dapat menempatkan proses yang akan berjalan pada

sistim dengan penamaan yang unik serta aliran data yang jelas, diskripsi data store.

3.3.1. DECISION DALAM DFD

Gambar Contoh Decision dalam DFD.

3.3.2. PERULANGAN DALAM DFD

Gambar Contoh perulangan dalam DFD.

Contoh lain :

Studi kasus Prosedur Sistim Usulan.

Proses-proses dalam Sistim Usulan secara berurutan terbagi atas 3 proses antara lain :

1. Prosedur Pengolahan Penjualan.

Setelah pelanggan melakukan pemesanan kemudian dicek barang dalam file barang, bila

barang tersedia disimpan dalam file barang, kemudian dicek status pelanggan dalam file

pelanggan dan disimpan.

12 | P a g e R P L 1

Setelah itu pemesanan dicek limit kredit, jika pemesanan melebihi limit kredit maka

diberikan konfirmasi kepada pelanggan, bila tidak dibuat faktur dan surat jalan untuk

dikirimkan ke pelanggan.

2. Pembayaran dan Retur.

Setelah itu dibuat pengolahan penjualan terdapat beberapa prosedur yang berurutan seperti :

Pembayaran pelanggan, terdapat proses pembayaran, proses pembuatan kuitansi dan

pengelolaan piutang.

Retur pelanggan, proses pengembalian barang karena adanya ke tidak cocokan terhadap

barang yang dipesan.

3. Pelaporan.

Pembuatan laporan penjualan, laporan barang, laporan piutang, laporan pelanggan, laporan

ramalan penjualan, dan laporan retur.

Pemodelan diawali dengan diagram konteks, diagram nol dan terus dilanjutkan dengan

diagram tingkat selanjutnya sampai dengan jelas tergambar keseluruhan proses secara rinci.

Gambar Diagram Konteks Sistim Usulan.

13 | P a g e R P L 1

Gambar Diagram Nol Sistim Usulan.

14 | P a g e R P L 1

Gambar Diagram Level Satu (Proses 1.0).

Proses Pengolahan Penjualan.

15 | P a g e R P L 1

Gambar Diagram Level Satu (Proses 2.0).

Proses Pembayaran dan Retur.

16 | P a g e R P L 1

Gambar Diagram Level Satu (Proses 3.0).

Proses Pelaporan.

17 | P a g e R P L 1

Gambar Diagram Level Dua (Proses 1.1).

Proses Pemesanan Barang.

18 | P a g e R P L 1

Gambar Diagram Level Dua (Proses 2.1).

Proses Pembayaran Pelanggan.

19 | P a g e R P L 1

Gambar Diagram Level Dua (Proses 2.2).

Proses Retur Pelanggan.

20 | P a g e R P L 1

4.1. PENAMAAN “PROSES”

Dalam membuat penamaan, nama proses harus tunggal dan dapat mendeskripsikan suatu

proses dalam sebuah kalimat yang jelas.

Dalam membuat penamaan, nama proses harus mendefinisikan kegiatan atau aksi yang

spesifik.

Contoh :

1. Mengedit

2. Menghitung gaji mingguan

3. Menghitung diskon pada pesanan

4. Dan lainnnya

Dalam membuat penamaan, jika suatu proses menangani proses maka harus di pecah menjadi

beberapa proses.

4.2. PENAMAAN “DATA STORE”

Penamaan data store harus khas atau spesifik.

Ingatlah bahwa setiap data store hanya berisi satu set struktur data.

4.3. PENAMAAN DATA FLOWS ANTARA PROSES

o Gunakan satu kata, Contoh : “kuitansi”, “Cek” dan sebagainya.

o Jangan menggunakan nama yang sama untuk setiap data flow.

o Perhatikan contoh pada gambar a berikut, yang menggunakan penamaan yang sama

selanjutnya hasil setelah penamaan tersebut diperbaiki adalah gambar b.

Gambar a. Contoh DFD.

Penamaan yang salah dan berulang.

21 | P a g e R P L 1

Pada data flow “Invoice” yang masuk ke “Edit Invoice”, dan keluar sebagai “Invoice” lagi, hal ini

tidak diizinkan dengan menggunakan nama yang sama atau dalam gambar diatas yang menggunakan

simbol bintang tidak diperbolehkan.

Gambar b. Contoh DFD.

Penamaan yang benar dan telah diperbaiki.

5. KAMUS DATA (DATA DICTIONARY)

Merupakan kumpulan data yang bertujuan untuk memberikan informasi mengenai definisi, struktur,

pemakai dari masing-masing elemen.

Notasi yang digunakan dalam kamus data adalah :

Penyusunan Data Notasi Arti

Sequence

(berurutan)

=

+

Di susun dari

dan

Selection (pilihan) [ | ] Jika atau

Repetion

(pengulangan)

( )n

( )

* *

Pegulangan ke n dari

Data optional

Komentar tidak dibatasi

Berikut diskripsi dan struktur data pada sistim penjualan adalah sebagai berikut :

Tabel KAMUS DATA.

No NAMA

ARUS DATA STRUKTUR DATA

1 DATA

BARANG

= Kd_Brg + Nm_Brg + Satuan + Hrg_Sat + Qty_Masuk + Qty_Keluar +

Stok_Akhir + Tanggal

22 | P a g e R P L 1

2 DATA

PELANGGAN

= Kd_Plg + Nm_Plg + Alamat + Kota + Kd_Pos + Telp + Lama_Kredit

+ Lmt_Kredit + NPWP

3 DATA

PESANAN = No_Psn + Tgl_Psn + Kd_Plg + Nil_Psn + Kd_Brg + Qty

4 DATA FAKTUR = No_Fak + Tgl_Fak + Kd_Plg + Nil_Fak + Kd_Brg + Qty

5 DATA

PIUTANG

= Kd_Plg + No_Fak + Nil_Fak + No_Byr + Jml_Byr + No_Ret +

Nil_Ret

6 DATA BAYAR = No_Byr + Tgl_Byr + Nm_Bank + No_Gr/Ck + Tgl_Gr/Ck + Jml_Brg

+ No_Fak

7 DATA RETUR = No_Ret + Tgl_Ret + Kd_Plg + No_Fak + Nil_Ret + Qty + Ket

8 DATA SURAT

JALAN = No_Sj + Tgl_Sj + Kd_Plg + Kd_Brg + Qty

6. NORMALISASI DATA

Normalisasi merupakan suatu pendekatan formal yang menguji data dan elemen data secara

bersamaan kedalam suatu bentuk yang dapat menampung perubahan dimasa yang akan datang.

Masing-masing atribut memiliki kesamaan kepentingan memudahkan memanggil ulang dalam

perangkat lunak komputer mengunakan kunci atau key.

Tabel adalah suatu kesatuan yang terdiri dari baris dan kolom (field) yang berisi data untuk

ditampilkan ke user sebagai informasi.

Sekelompok tabel untuk suatu keperluan dikelompokkan dalam sebuah database yang ditangani dan

dihandle oleh database engine dan disimpan sebagai sebuah file.

Dalam pembentukan sebuah tabel yang baik dibutuhkan tahapan tahapan antara lain tahap

unnormalized yakni tabel yang berisi seluruh data yang akan ditangani tanpa memperdulikan faktor

relation dan ke tergantungannya.

Langkah selanjutnya adalah menormalisasi tabel menjadi bentuk 3NF dengan menghilangkan

repetisi dan ketergantungan data antar kolom dalam sebuah tabel.

Meskipun bukan suatu yang mutlak dan pasti, sebuah tabel dalam bentuk 3NF biasanya terdiri dari 3

sampai 5 kolom dan satu sama lain saling terhubung melalui pola relation yang diatur dalam foreign

key.

ATRIBUT KUNCI

Merupakan field kunci dari sebuah file tabel yang dapat mewakili suatu record.

Misalnya dalam contoh ini, kunci dari tabel barang adalah kode barang, field kunci ini harus bersifat

unik dan dalam nomor induk pasti tidak boleh ada yang sama.

Beberapa atribut kunci yang digunakan antara lain :

1. KUNCI PRIMER (PRIMARY KEY)

Adalah atribut atau minimal satu set atribut yang tidak hanya mengidentifikasi secara unik

suatu kejadian spesifik tapi juga dapat mewakili setiap kejadian dari suatu entity.

23 | P a g e R P L 1

2. KUNCI TAMU (FOREIGN KEY)

Adalah satu atribut yang melengkapi satu hubungan (relationship) yang menunjukkan ke

induknya.

Kunci Tamu ditempatkan pada entity anak dan sama dengan Kunci Primary induk

direlasikan.

Hubungan antara entity induk dengan anak adalah hubungan satu lawan banyak (one to many

relationship).

3. KUNCI ALTERNATIF (ALTERNATIVE KEY)

Alternative Key adalah kunci kunci tertentu yang tidak dipakai sebagai Primary Key.

Sering kali kunci ini hanya dipakai sebagai kunci pada saat terjadi pengurutan (sorting) dalam

laporan.

Ada beberapa bentuk Normalisasi, yaitu :

1. BENTUK TIDAK NORMAL (UNNORMALLIZED FORM / UNF).

Merupakan kumpulan data yang akan direkam, tidak ada keharusan mengikuti suatu format

tertentu, bisa berupa data tidak lengkap atau terduplikasi, Data dikumpulkan apa adanya.

2. BENTUK NORMAL PERTAMA (FIRST NORMAL FORM / 1NF).

Merupakan suatu kumpulan data yang dibentuk menjadi bentuk normal ke satu dengan

memisah misahkan data pada field field yang tepat dan bersifat atomic yaitu tidak ada set

atribut yang berulang atau atribut bernilai ganda.

3. BENTUK NORMAL KE DUA (SECOND NORMAL FORM / 2NF).

Setiap atribut dalam record adalah fungsional dependent dari record key.

Dalam second normal form tidak terdapat data redudancy / berulang-ulang .

Pembentukan Normal Ke Dua mencari kunci field yang dipakai sebagai patokan dalam

pencarian data dan memiliki sifat unik.

4. BENTUK NORMAL KE TIGA (THIRD NORMAL FORM / 3NF).

Bentuk Normal Ke Tiga mempunyai syarat setiap tabel tidak mempunyai field yang

tergantung transitif, namun harus tergantung penuh pada Kunci Utama.

Dengan kata lain, setiap atribut bukan kunci haruslah bergantung hanya pada Primary Key

dan pada pada Primary Key secara menyeluruh.

5. BOYCE-CODD NORMAL FORM (BCNF).

Boyce-Codd Normal Form mempunyai alasan paksaan yang lebih kuat dari Bentuk Normal

Ke Tiga.

Untuk menjadi BCNF, relasi harus dalam bentuk normal pertama dan setiap atribut harus

bergantung fungsi pada atribut super key.

24 | P a g e R P L 1

CONTOH NORMALISASI

1. PEMESANAN.

Normalisasi data untuk proses “pemesanan barang” pada bentuk 1, 2 dan 3 (1NF, 2NF dan

3NF serta UNF) pada gambar Diagram Level Dua (Proses 1.1), Proses Pemesanan Barang, terpusat

pada proses P2.1.2. adalah :

UNF = No_Psn + Tgl_Psn + Kd_Plg + Nm_Plg + Alamat + Kota + Kd_Pos + {Kd_Brg +

Nm_Brg + Qty + Satuan + Hrg_Sat} + Nilai_Psn

1NF = No_Psn + Tgl_Psn + Kd_Plg + Nm_Plg + Alamat + Kota + Kd_Pos + Kd_Brg +

Nm_Brg + Qty + Satuan + Hrg_Sat + Nilai_Psn

2NF :

Header_Pesan = No_Psn* + Tgl_Psn + Kd_Plg + Nm_Plg + Alamat + Kota + Kd_Pos +

Nilai_Psn

Detail_Pesan = No_Psn* + Kd_Brg* + Qty

Barang = Kd_Brg* + Nm_Brg + Qty + Satuan + Hrg_Sat

3NF :

Header_Pesan = No_Psn* + Tgl_Psn + Kd_Plg + Nilai_Psn

Pelanggan = Kd_Plg* + Nm_Plg + Alamat + Kota + Kd_Pos

Detail_Pesan = No_Psn* + Kd_Brg* + Qty

Barang = Kd_Brg* + Nm_Brg + Qty + Satuan + Hrg_Psn

Proses pemesanan barangnya lihat proses P2.1.2. pada “cek barang”, pada gambar Diagram Level

Dua (Proses 1.1), Proses Pemesanan Barang.

2. FAKTUR.

Normalisasi data untuk proses “pemesanan barang” pada bentuk 1, 2 dan 3 (1NF, 2NF dan

3NF serta UNF) pada gambar Diagram Level Dua (Proses 1.1), Proses Pemesanan Barang, terpusat

pada proses P2.1.5. adalah :

UNF = No_Fak + Tgl_Fak + No_Sj + No_Psn + Kd_Plg + Nm_Plg + Alamat + Kota + Kd_Pos +

{Kd_Brg + Nm_Brg + Qty + Satuan + Hrg_Sat} + Nilai_Fak

1NF = No_Fak* + Tgl_Fak + No_Sj + No_Psn + Kd_Plg + Nm_Plg + Alamat + Kota + Kd_Pos

+ Kd_Brg + Nm_Brg + Qty + Satuan + Hrg_Sat + Nilai_Fak

2NF :

Header_faktur = No_Fak* + Tgl_Fak + No_Sj + No_Psn + Kd_Plg + Nm_Plg + Alamat + Kota +

Kd_Pos + Nilai_Fak

Detail_ faktur = No_Fak* + Kd_Brg + Nm_Brg + Qty + Satuan + Hrg_Sat

3NF :

Header_faktur = No_Fak* + Tgl_Fak + No_Sj + No_Psn + Kd_Plg + Nilai_Fak

25 | P a g e R P L 1

Detail_ faktur = No_Fak* + Kd_Brg* + Nm_Brg + Qty + Satuan + Hrg_Sat

Pelanggan = Kd_Plg* + Nm_Plg + Alamat + Kota + Kd_Pos

Barang = Kd_Brg* + Nm_Brg + Qty + Satuan + Hrg_Psn

Proses pemesanan barangnya lihat proses P2.1.5. pada “Buat faktur dan surat jalan”, pada

gambar Diagram Level Dua (Proses 1.1), Proses Pemesanan Barang.

3. PEMBAYARAN.

Normalisasi data untuk proses “pembayaran pelanggan” pada bentuk 1, 2 dan 3 (1NF, 2NF

dan 3NF serta UNF) pada gambar Diagram Level Dua (Proses 2.1), Proses Pembayaran Pelanggan,

terpusat pada proses P2.1.1. (proses terima pembayaran) adalah :

UNF = No_Byr + Tgl_Byr + Jml_Byr + Kd_Plg + {No_Fak} + Nm_Bank +

No_Gr/Ck + Tgl_Gr/Ck

1NF = No_Byr* + Tgl_Byr + Jml_Byr + Kd_Plg + No_Fak + Nm_Bank + No_Gr/Ck

+ Tgl_Gr/Ck

2NF / 3NF :

Header_Bayar = No_Byr* + Tgl_Byr + Jml_Byr + Kd_Plg + Nm_Bank + No_Gr/Ck +

Tgl_Gr/Ck

Detail_Bayar = No_Byr* + No_Fak*

4. RETUR.

Normalisasi data untuk proses “Retur pelanggan” pada bentuk 1, 2 dan 3 (1NF, 2NF dan

3NF, serta UNF) pada gambar Diagram Level Dua (Proses 2.2), Proses Retur Pelanggan, terpusat

pada proses P2.2.1. (Cek retur) adalah :

UNF = No_Ret + Tgl_Ret + No_Fak + Kd_Plg + Nm_Plg + Alamat + Kota + Kd_Pos

+ {Kd_Brg + Nm_Brg + Qty + Satuan + Hrg_Sat + Ket_Ret } + Nilai_Ret

1NF = No_Ret* + Tgl_Ret + No_Fak + Kd_Plg + Nm_Plg + Alamat + Kota +

Kd_Pos + Kd_Brg + Nm_Brg + Qty + Satuan + Hrg_Sat + Ket_Ret +

Nilai_Ret

2NF :

Header_Retur = No_Ret* + Tgl_Ret + No_Fak + Kd_Plg + Nm_Plg + Alamat + Kota +

Kd_Pos + Nilai_Ret

Detail_Retur = No_Ret* + Kd_Brg* + Nm_Brg + Qty + Satuan + Hrg_Sat + Ket_Ret

3NF :

Header_Retur = No_Ret* + Tgl_Ret + No_Fak + Kd_Plg + Nilai_Ret

Detail_Retur = No_Ret* + Kd_Ret* + Qty + Ket_Ret

Pelanggan = Kd_Plg* + Nm_Plg + Alamat + Kota + Kd_Pos

Barang = Kd_Plg* + Nm_Brg + Satuan + Hrg_Sat

26 | P a g e R P L 1

7. ENTITY RELATIONSHIP DIAGRAM (ERD)

Diagram hubungan entitas (Entity Relationship Diagram) adalah diagram yang menerangkan

tentang:

Informasi apa saja yang terkandung didalam media penyimpanan (data storage).

Hubungan apa yang ada diantara media penyimpanan (data storage).

Hubungan entitas adalah model jaringan kerja yang menguraikan susunan data yang disimpan dari

sistim secara acak.

Abstraksi yang dipakai untuk mengurai data, lihat simbol dalam DFD,

7.1. ENTITAS

Entitas merupakan sebuah lingkungan elemen, sebuah sumber atau transaksi yang mana merupakan

hal penting bagi perusahaan yang didokumentasikan dengan data.

Entitas ini digambarkan dengan empat persegi panjang.

7.2. RELASI (RELATIONSHIP)

Relationship merupakan hubungan antara entitas atau lebih.

Digambarkan dengan diamond.

7.3. CARDINALITY

Cardinality merupakan hubungan antara entitas yang satu dengan yang lainnya, terdiri dari satu ke

satu (one to one), satu ke banyak (one to many) dan banyak ke banyak (many to many).

ENTITAS

RELASI

1 1 ONE TO ONE

1 M ONE TO MANY

M M MANY TO MANY

Gambar Simbol ERD.

27 | P a g e R P L 1

Gambar Contoh Entity Relationship Diagram.

28 | P a g e R P L 1

8. DIAGRAM WARNIER

Diagram ini memungkinkan analis menggambarkan informasi dalam bentuk hirarki dengan baik dan

dilengkapi dengan struktur program dan logika program serta struktur datanya.

Contoh : Pengulangan

Dalam Flowchart Dalam Warnier

Baca A

C = A + 2

Tulis C

Keputusan

Dalam Flowchart Dalam Warnier

A>0 B = A

+

A>0 Tulis salah

9. SISTEM PENGEMBANGAN JACKSON (JSD – JACKSON SYSTEM DEVELOPMENT)

Menjelaskan analisis domain informasi dan hubungan dengan program dan perancangan sistim.

Langkah-langkah JSD adalah :

9.1. ENTITY ACTION STEP

9.2. ENTITY STRUKTUR STEP

9.3. INITIAL MODEL STEP

9.4. FUCTION STEP

9.5. SYSTEM TIMING STEP

9.6. IMPLEMENTATION STEP

9.1. ENTITY ACTION STEP

Entity adalah orang, objek, organisasi yang menghasilkan atau memakai informasi.

Sedangkan action (aksi) adalah tindakan yang terjadi dan mempengaruhi entity.

Baca A

C = A+2

Tulis C

A > 0 Tulis

salah

B = A

T

Y

29 | P a g e R P L 1

9.2. ENTITY STRUKTUR STEP

Tindakan yang mempengaruhi entity, dikerjakan dalam waktu dan digambarkan dengan diagram

Jackson.

9.3. INITIAL MODEL STEP

Entity dan action yang digambarkan sebagai model proses, hubungan antar model dengan dunia

nyata didefinisikan.

9.4. FUCTION STEP

Spesifikasi fungsi yang berhubungan dengan definisi aksi.

9.5. SYSTEM TIMING STEP

Karakteristik proses penjadwalan yang akan dinilai dan spesifikasinya.

9.6. IMPLEMENTATION STEP

Perangkat keras dan perangkat lunak yang spesifikasi dalam perancangan.

30 | P a g e R P L 1

10. SADT (STRUCTURAL ANALYSIS AND DESIGN TECHNIQUE)

Digunakan sebagai alat bantu otomatis untuk pendefinisian sistim, analisis keperluan perangkat

lunak dan perancangan perangkat lunak.

Terdiri dari prosedur-prosedur yang mengizinkan analis sistim untuk memecah-mecah permasalahan

yang ada, menggunakan notasi grafik dan juga menyediakan petunjuk pengawasan untuk penerapan

metodologi pada proyek.

Simbol yang digunakan pada SADT :

AKTIGRAM

Gambar Simbol SADT.