4. PEMODELAN ANALISIS

1|Page

RPL 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|Page

RPL 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|Page

RPL 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|Page

RPL 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. Kardinalitas Mengimplikasikan bahwa pelanggan tunggal menunggu tindakan perbaikan

Pelanggan

Modalitas : Harus Mengimplikasikan bahwa Untuk mempunyai tindakan perbaikan, kita harus ada pelanggan.

Kardinalitas Mengimplikasikan bahwa Ada banyak tindakan perbaikan

Tindakan Perbaikan

Modalitas : Opsional Mengimplikasikan bahwa Ada situasi diamana perbaikan tidak diperlukan

tindakan

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.

5|Page

RPL 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|Page

RPL 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|Page

RPL 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|Page

RPL 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|Page

RPL 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

RPL 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 3.3.

RPL 1

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

RPL 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

RPL 1

Gambar Diagram Nol Sistim Usulan.

14 | P a g e

RPL 1

Gambar Diagram Level Satu (Proses 1.0). Proses Pengolahan Penjualan.

15 | P a g e

RPL 1

Gambar Diagram Level Satu (Proses 2.0). Proses Pembayaran dan Retur.

16 | P a g e

RPL 1

Gambar Diagram Level Satu (Proses 3.0). Proses Pelaporan.

17 | P a g e

RPL 1

Gambar Diagram Level Dua (Proses 1.1). Proses Pemesanan Barang.

18 | P a g e

RPL 1

Gambar Diagram Level Dua (Proses 2.1). Proses Pembayaran Pelanggan.

19 | P a g e

RPL 1

Gambar Diagram Level Dua (Proses 2.2). Proses Retur Pelanggan.

20 | P a g e

RPL 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 Gunakan satu kata, Contoh : “kuitansi”, “Cek” dan sebagainya. Jangan menggunakan nama yang sama untuk setiap data flow. Perhatikan contoh pada gambar a berikut, yang menggunakan penamaan yang sama selanjutnya hasil setelah penamaan tersebut diperbaiki adalah gambar b.

o o o

Gambar a. Contoh DFD. Penamaan yang salah dan berulang.

21 | P a g e

RPL 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 Sequence (berurutan) Selection (pilihan) Repetion (pengulangan)

Notasi = + [|] ( )n

Arti Di susun dari dan Jika atau Pegulangan ke n dari

()

Data optional

**

Komentar tidak dibatasi

Berikut diskripsi dan struktur data pada sistim penjualan adalah sebagai berikut : Tabel KAMUS DATA. No 1

NAMA ARUS DATA DATA BARANG

STRUKTUR DATA = Kd_Brg + Nm_Brg + Satuan + Hrg_Sat + Qty_Masuk + Qty_Keluar + Stok_Akhir + Tanggal

22 | P a g e 2 3 4 5

DATA PELANGGAN DATA PESANAN DATA FAKTUR DATA PIUTANG

RPL 1 = Kd_Plg + Nm_Plg + Alamat + Kota + Kd_Pos + Telp + Lama_Kredit + Lmt_Kredit + NPWP = No_Psn + Tgl_Psn + Kd_Plg + Nil_Psn + Kd_Brg + Qty = No_Fak + Tgl_Fak + Kd_Plg + Nil_Fak + Kd_Brg + Qty = Kd_Plg + No_Fak + Nil_Fak + No_Byr + Jml_Byr + No_Ret + Nil_Ret = No_Byr + Tgl_Byr + Nm_Bank + No_Gr/Ck + Tgl_Gr/Ck + Jml_Brg + No_Fak = No_Ret + Tgl_Ret + Kd_Plg + No_Fak + Nil_Ret + Qty + Ket

6

DATA BAYAR

7

DATA RETUR DATA SURAT = No_Sj + Tgl_Sj + Kd_Plg + Kd_Brg + Qty JALAN

8

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

RPL 1

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

RPL 1

CONTOH NORMALISASI 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 : 1.

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

RPL 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

2NF / 3NF : Header_Bayar

Detail_Bayar

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

= No_Byr* + Tgl_Byr + Jml_Byr + Kd_Plg + Nm_Bank + No_Gr/Ck + Tgl_Gr/Ck = 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

2NF : Header_Retur

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

RPL 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

RPL 1

Gambar Contoh Entity Relationship Diagram.

28 | P a g e

RPL 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

Baca A C = A+2

C=A+2

Tulis C

Tulis C Keputusan

Dalam Flowchart T A>0

Dalam Warnier

Tulis salah

A>0

B=A +

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

29 | P a g e

RPL 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

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