MODUL ANALISA PERANCANGAN SISTEM INFORMASI ...

MODUL

ANALISA PERANCANGAN SISTEM INFORMASI

AKUNTANSI

Disusun Oleh :

EVY PRIYANTI, M.KOM

UNIVERSITAS BINA SARANA INFORMATIKA

FAKULTAS TEKNIK DAN INFORMATIKA

PROGRAM STUDI SISTEM INFORMASI AKUNTANSI

JAKARTA

2019

2

KATA PENGANTAR

Puji syukur kami panjatkan kehadirat Allah SWT, karena atas limpahan rahmat

dan hidayahnya sehingga kami dapat menyelesaikan modul Analisa Perancangan Sistem

Informasi Akuntansi ini dengan baik. Modul Analisa Perancangan Sistem Informasi

Akuntansi ini disusun untuk memberikan gambaran bagi mahasiswa yang

mempelajari matakuliah Analisa Perancangan Sistem Informasi Akuntansi.

Saya selaku penyusun, tak lupa ingin mengucapkan banyak terima kasih kepada

semua pihak yang telah terlibat dan membantu dalam penyusunan modul ini, terima kasih

juga kepada rekan–rekan dosen dan semuanya yang tidak bisa disebutkan satu persatu,

yang selalu mendukung sehingga modul ini sehingga dapat selesai sesuai yang kita

inginkan semua.

Saya menyadari masih banyak kekurangan dalam penyusunan modul ini. Untuk

itu saran dan kritik yang membangun sangat saya harapkan guna perbaikan dan

pengembangan modul ini kedepan.

Akhir kata saya selaku penyusun berharap semoga modul Analisa Perancangan

Sistem Informasi Akuntansi ini dapat dipergunakan sebaik-baiknya dan dapat dijadikan

referensi untuk mahasiswa umum yang ingin mempelajarinya.

Jakarta, Desember 2019

Penulis

Evy Priyanti, M.Kom

3

DAFTAR ISI

Kata Pengantar ____________________________________________________ 2

Daftar Isi ________________________________________________________ 3

Kontrak Perkuliahan ________________________________________________ 5

Minggu Ke 1 Konsep Dasar Analisa Pengembangan Sistem Informasi Akuntansi 11

Minggu Ke 2 Planning dan analisis system ______________________________ 29

Minggu Ke 3 Perancangan sistem _____________________________________ 71

Minggu Ke 4 desain database_________________________________________ 83

Minggu Ke 5 Perancangan Sistem _____________________________________ 112

Minggu Ke 6 Perancangan Sistem Lanjutan dan implementasi _______________ 124

Minggu Ke 7 Pengujian _____________________________________________ 138

4

KONTRAK PERKULIAHAN

1. Matakuliah APSIA (Analisa Perancangan Sistem Informasi Akuntansi)

adalah matakuliah lanjutan dari SIA dan matakuliah yang berkaitan

dengan matakuliah Java.

2. Mahasiswa diwajibkan membuat project pengembangan sistem

menggunakan diagram UML dengan Metode Waterfall atau Metode

yang lainnya dengan menampilkan Programnya (ikuti praktikum java).

3. Mahasiswa dapat melakukan riset atau menggunakan materi hasil riset

untuk dilakukan Rancang Bangun sistem informasi akuntansi.

4. Tema Pembahasan yang berhubungan dengan sistem informasi

akuntansi

5. Tugas secara Berkelompok terdiri dari 5 mahasiswa, dan harus sama

dengan kelompok pada matakuliah Java. Mahasiswa membuat project

subsistem (perkelompok)

6. Project dicetak dalam bentuk makalah (1 makalah untuk 1 kelas yang

7. terdiri dari gabungan semua makalah kelompok) dan dijilid lakban.

8. Makalah dikumpulkan pada pertemuan 9 (untuk dinilai oleh Dosen)dan

Presentasi dilakukan mulai dari pertemuan 10 atau disesuaikan dengan

jumlah kelompok

9. Bobot penilaian saat Presentasi

N = Penilaian Paper (25%) +Penilaian Analisa dan Project (50%)+

Penilaian

Kemampuan Individu (25%)

5

Daftar Isi Makalah

Lembar Judul Makalah

Daftar isi Daftar Gambar Daftar Tabel

BAB I PENDAHULUAN

1.1 Latar Belakang Masalah

1.2 Maksud dan Tujuan

1.3 Metode Penelitian

1.3.1 Metode Pengumpulan Data

1.3.2 Metode Pengembangan Software

1.4 Ruang Lingkup

BAB II LANDASAN TEORI

2.1 Konsep Dasar

2.1.1 Konsep dasar sistem (tambahkan Jurnal sebagai referensi)

2.1.2 Konsep dasar Program

2.2 Peralatan Pendukung

6

BAB III PEMBAHASAN

3.1 Tinjauan Perusahaan

3.2 Tinjauan Kasus

3.2.1 Proses Bisnis Sistem Berjalan

3.2.2 Activity Diagram

3.2.3 Dokumen Masukan

3.2.4 Dokumen Keluaran

3.2.5 Permasalahan Pokok

3.2.6 Pemecahan Masalah

3.3 Analisis Kebutuhan Software

3.3.1 Analisis Kebutuhan Fungsional

3.3.2 Use Case Diagram

3.3.3 Activity Diagram

3.4 Desain

3.4.1 Entity Relationship Diagram(ERD)

3.4.2 Logical Record Structure (LRS)

3.4.3 Spesifikasi File

3.4.4 Class Diagram

3.4.5 Sequence Diagram (lampirkan min.2)

3.4.6 User Interface

3.4.7 Deployment Diagram

3.5. Implementasi

3.5.1 Code Generation

3.5.2 Testing

3.5.3 Spesifikasi Hardware dan Software

7

Daftar Isi Makalah

BAB IV PENUTUP

4.1 Kesimpulan

4.2 Saran

DAFTAR PUSTAKA

DAFTAR RIWAYAT KELOMPOK SURAT KETERANGAN

PKL/RISET LAMPIRAN-LAMPIRAN

8

Contoh Sistem berkaitan dengan SIA

Sistem Informasi Keuangan Perusahaan Dagang

a. Sistem Penjualan

b. Sistem Pembelian

c. Sistem Penggajian

d. Sistem Pengeluaran Kas

e. Sistem Penerimaan Kas

f. Sistem Aktiva Tetap

9

PERTEMUAN 1

KONSEP DASAR ANALISA PENGEMBANGAN

SISTEM INFORMASI AKUNTANSI

10

Materi Pertemuan 1

1. Analisa Desain dan Pengembangan Sistem

2. Metodologi Berorientasi Objek

3. Definisi Systems Development Life Cycle

(SDLC)

4. Metode Waterfall

5. Studi Kasus

11

1. Analisis, Desain dan Pengembangan Sistem

A. ANALISA SISTEM

Menurut (Sukamto & Salahuddin, 2013), mendefinisikan Analisa Sistem adalah

“Kegiatan analisis sistem adalah kegiatan untuk melihat sistem yang sudah berjalan,

melihat bagian mana yang bagus dan tidak bagus dan kemudian

mendokumentasikan kebutuhan yang akan dipenuhi dalam sistem yang baru “.

Langkah-langkah Analisis Sistem:

1. Identify, yaitu mengidentifikasikan masalah

2. Understand, yaitu memahami kerja dari sistem yang ada

3. Analyze, yaitu menganalisis sistem

4. Report, yaitu membuat laporan hasil analisis

12

Menurut (Sukamto & Salahuddin , 2013)

• Hal pertama yang akan dilakukan dalam analisa sistem adalah melakukan pengumpulan data.

Ada beberapa teknik pengumpulan data, yaitu:

1) Teknik Wawancara

2) Teknik Observasi

3) Teknik Kuesioner

13

B. DESAIN SISTEM

Menurut (Sukamto & Salahuddin, 2013) mengatakan bahwa Desain atau

perancangan dalam pembangunan perangkat lunak merupakan upaya untuk

mengonstruksi sebuah sistem yang memberikan kepuasan akan spesifikasi

kebutuhan fungsional, memenuhi target, memenuhi kebutuhan secara implisit atau

eksplisit dari segi performansi maupun penggunaan sumber daya, kepuasan

batasan pada proses segi biaya, waktu dan perangkat.

Tujuan Perancangan Sistem

a. Untuk memenuhi kebutuhan kepada pemakai sistem

b. Untuk memberikan gambaran yang jelas dan rancang bangun yang lengkap

kepada pemrogram komputer dan ahli- ahli teknik lainnya yang terlibat.

14

C. Pengembangan Sistem

Pengembangan sistem (System Development) memiliki arti menyusun sistem yang

baru untuk menggantikan sistem yang lama secara keseluruhan atau memperbaiki

sistem yang sudah ada.

Kenapa Perlu Diperbaiki?

15

Pengembangan Sistem

Penyebab perlu diperbaikinya sebuah sistem :

1. Adanya permasalahan-permasalahan yang timbul (ketidak beresan sistem, pertumbuhan organisasi)

2. Adanya kesempatan-kesempatan (opportunities) untuk peningkatan pelayanan dan untuk proses pengambilan keputusan

3. Adanya instruksi-instruksi (directives) dari pimpinan

Pengembangan Sistem

Permasalahan

Kesempatan

Instruksi

Memecahkan Masalah Meraih

Kesempatan Memenuhi Instruksi

Sumber : Tohari (2014)

Sistem yang baru

Sistem yang ada

16

2. Metodologi Berorientasi Objek

Merupakan suatu cara bagaimana sistem perangkat lunak dibangun melalui pendekatan berorientasi objek secara sistematis.

Setiap Objek mempunyai informasi-informasi atau atribut-atribut dan perilaku (behavior) sebagai suatu operasi pengaturnya.

Atribut (data) :

Pedal, Ban, Rante, Rem

Methode (function/behaviour) : Maju, Mengerem,

Pindah gigi

17

Karakteristik Berorientasi Objek

1. Pembungkusan ( Encapsulation)

Pembungkusan berfungsi untuk melindungi suatu objek dari dunia luar,

sehingga seseorang tidak akan mampu merusak objek yang terbungkus.

Objek yang terbungkus dalam suatu kelas baik data maupun fungsinya

tidak bisa terlihat apalagi dirubah pada saat objek digunakan.

Dalam Java data dibungkus dengan modifier private

agar tidak bisa diakses secara langsung dari luar class.

18

2. Pewarisan ( Inheritance )

Class dapat menurunkan metode-metode dan properti-properti yang

dimilikinya pada class lain. Class yang mewarisi metode dan properti dari

objek lain dinamakan class turunan. Class turunan ini mampu

mengembangkan metode sendiri.

Contoh Pewarisan ( Inheritance )

Dalam gambar diatas, dari Kelas SegiTiga, dapat dibuatkan dua

kelas yang baru yaitu kelas SegiTiga SamaSisi dan SegiTiga

SamaKaki, yang merupakan turunan dari kelas SegiTiga. Dalam

bahasa pemrograman Java, biasanya dalam kelas turunan terdapat

keyword extends.

19

Penerapan dalam Java

public class SamaKaki extends SegiTiga

{

public SamaKaki(){

}

public int hitungLuas(){

return 0;

}

}

public class SamaSisi extends SegiTiga

{

public SamaSisi(){

}

public int hitungLuas(){ return 0;

}

}

20

3. Keanekaragaman (Polymorphism)

Polymorphism dapat diartikan sebagai kemampuan suatu bahasa

pemrograman untuk memiliki fungsi-fungsi atau metode yang bernama

sama tetapi berbeda dalam parameter dan implementasi kodenya

(overloading).

Kelas turunan dapat menggunakan fungsi yang ada pada kelas

pewarisnya dan dapat mengimplementasikan kode yang berbeda dari

fungsi pewarisnya ini dinamakan overriding.

21

Pada contoh kelas SegiTiga sebelumnya, dapat ditambahkan fungsi

dengan nama yang sama, misalnya hitungLuas, namun dengan

penambahan parameter alas dan tinggi.

public class SegiTiga{

public int hitungLuas(){

int luas = 0;

luas = (this.getAlas() * this.getTinggi()) / 2; return luas;

}

public int hitungLuas (int alas, int tinggi){ int luas = 0;

luas = (alas * tinggi) / 2; return luas;

}

}

Sumber : (Akil, 2018)

22

3. Systems Development Life Cycle

(SDLC)

Siklus hidup pengembangan sistem (SDLC) adalah proses memahami

bagaimana sistem informasi (IS) dapat mendukung kebutuhan bisnis dengan

merancang sistem, membangunnya, dan menyampaikan ke pengguna. (Dennis

et al., 2015)

Kata Kunci dalam Systems Development Life Cycle adalah Analis sistem, yang

menganalisis situasi bisnis, mengidentifikasi peluang untuk perbaikan, dan mendesain

sistem informasi untuk diimplementasikan. (Dennis et al., 2015)

SDLC memiliki fase secara umum yaitu Planning, Analisis, Desain dan Implementasi

(Dennis et al., 2015)

Dalam pelaksanaannya, fase yang digunakan dapat berbeda-beda dan pada intinya empat

fase umum yang ada termasuk dalam fase yang digunakan.

23

Fase umum SDLC

1. Planning (Perencanaan)

Fase perencanaan adalah proses fundamental untuk memahami mengapa sistem

informasi harus dibangun dan menentukan bagaimana tim proyek akan

membangunnya

2. Analisis

Fase analisis menjawab pertanyaan tentang bagaimana menggunakan sistem, apa

yang akan dilakukan sistem, dimana dan kapan akan digunakan.

3. Desain

Desain secara bertahap menentukan bagaimana sistem akan beroperasi, dalam hal

perangkat keras, perangkat lunak, dan infrastruktur jaringan; antarmuka pengguna,

formulir, dan laporan; dan program-program spesifik, database, dan file yang

dibutuhkan.

4. Implementasi

Fase terakhir dalam SDLC adalah fase implementasi, di mana sistem sebenarnya

dibangun (atau dibeli, dalam kasus desain software yang dikemas). Ini adalah fase

yang biasanya mendapat perhatian paling besar, karena untuk kebanyakan sistem

itu adalah yang terpanjang dan paling mahal bagian dari proses pengembangan.

24

Model SDLC

Menurut (Sukamto dan Shalahuddin, 2013), Model SDLC terdiri dari :

1. Model Waterfall

2. Model Prototipe

3. Model Rapid Application Development (RAD)

4. Model Iteratif

5. Model Spiral

Adapun model yang dibahas dalam matakuliah ini adalah model Waterfall

25

4. Model Waterfall

Model waterfall adalah model SDLC yang paling sederhana. Model ini cocok

untuk pengembangan perangkat lunak dengan spesifikasi yang tidak berubah-

rubah (Sukamto dan Salahudin, 2013).Model waterfall

Sumber : (Dennis et al., 2015)

26

Model waterfall

Metode ini disebut juga metode air terjun, karena dengan metode Waterfall para analis dan

pengguna dapat melanjutkan fase – fase secara bertahap mulai dari fase atas ke fase paling

bawah.

Dua keunggulan utama dari waterfall :

1. Mengidentifikasi kebutuhan sistem sebelum program dibuat

2. Meminimalkan perubahan pada saat proyek berlansung

27

Model waterfall

Kelemahan utama dalam waterfall adalah Desain harus sepenuhnya

ditentukan sebelum pemrograman dimulai.

Catatan

Sistem yang baik adalah sistem yang selalu menyesuaikan dengan

perubahan lingkungan disekitarnya. Sistem tersebut harus dinamis

menuju pada keadaan yang lebih secara berkelanjutan

28

DAFTAR PUSTAKA

Akil, Ibnu. 2018. Referensi dan Panduan UML 2.4 Singkat Tepat Jelas. Jakarta Buku

Panduan Penulisan Tugas Akhir 2018

Dennis, A., Wixom, B.H., Tegarden, D., 2015. Systems analysis and design: An object-oriented approach with UML.

https://www.petanikode.com/java-oop-inheritance/8

Rosa dan Shalahuddin.2013.Rekayasa Perangkat Lunak Terstruktur dan Berorientasi

Objek.Bandung:Informatika

Tohari, Hamim.2014.Analsisis Serta Perancangan Sistem Informasi Melalui Pendekatan UML.Yogakarta:Andi

http://www.petanikode.com/java-oop-inheritance/8

http://www.petanikode.com/java-oop-inheritance/8

29

PERTEMUAN 2

Planning dan Analisis Sistem

30

Capaian Pembelajaran

Mahasiswa mengetahui dan memahami Analisis Sistem (analisis proses bisnis,

analisis permasalahan dan analisis kebutuhan fungsional) mengggunakan model

Waterfall

Materi Pertemuan 2

1. Definisi UML dan Diagram UML

2. Konsep Dasar Use Case

3. Studi Kasus Pembelian

4. Tahapan Waterfall (Planning)

5. Analisis Kebutuhan Fungsional

31

1. Definisi dan Diagram UML

a. Definisi UML

Menurut (Sukamto dan Shalahuddin:2013)

“UML muncul karena adanya kebutuhan pemodelan visual untuk

menspesifikasikan, menggambarkan, membangun, dan dokumentasi dari sistem

perangkat lunak “.

UML adalah bahasa umum untuk analis bisnis, arsitek perangkat lunak dan

pengembang yang digunakan untuk mendeskripsikan, menentukan, merancang,

dan mendokumentasikan proses bisnis, struktur, dan perilaku yang ada atau baru

dari artefak sistem perangkat lunak.

32

• UML adalah bahasa penyatuan dari berbagai bahasa pemodelan, sehingga UML tidak memiliki Metode pemodelan

33

b. Diagram Uml

Diagram UML 2.4 dapat dikategorikan secara hierarkis :

Diagram struktur mewakili konsep-konsep yang bermakna dari suatu

sistem, dan dapat mencakup konsep-konsep abstrak, dunia nyata dan

implementasi.

Diagram perilaku menunjukkan perilaku dinamis dari objek dalam suatu

sistem, yang dapat digambarkan sebagai serangkaian perubahan pada sistem

dari waktu ke waktu.

35

History UML

36

Dalam materi APSIA, yang akan dibahas hanya 5 Diagram, yaitu :

1. Use case diagram

2. Activity diagram

3. Class diagram

4. Sequence diagram

5. Deployment diagram

37

2. Konsep Dasar Use Case

• Use Case adalah rangkaian atau uraian sekelompok yang saling terkait

dan membentuk sistem secara teratur yang dilakukan atau diawasi oleh

sebuah aktor. (Tohari,2014)

• Use Case digunakan untuk membentuk tingkah laku benda dalam

sebuah model serta direalisasikan oleh sebuah kolaborasi, dan use case

menggambarkan fungsionalitas yang diharapkan dari sebuah sistem.

(Tohari,2014)

• Use Case diagram menggambarkan fungsionalitas yang diharapkan dari

sebuah sistem

• Penekanan Use Case pada “apa” yang diperbuat sistem, dan bukan

“bagaimana”.

• Use Case merepresentasikan sebuah interaksi antara aktor dengan

sistem.

(Yasin,2012)

38

Level of Use Case

Lockburn suggests a scheme of levels of use cases .

• Sea-level use cases typically represent a discrete

interaction between a primary actor and the System.

• Use cases that are there only because they are included by sea-level

use cases are fish-level .

• Kite-level use cases are usually business use cases, whereas sea and

fish levels are system use cases.(fowler,2004)

❑ Use case sea dan fish level adalah use case system, kite level

biasanya untuk use case bisnis

❑ Dalam pembuatan use case, dahulukan membuat use case sea

level, jika ada yang di include silakan lanjut tahap fish level

39

Elemen Use Case

Elemen-elemen dalam diagram Use-case: (Dennis et al., 2015)

1. Aktor

2. Use cases

3. Subject boundaries,

4. Relationship

40

Elemen Use Case

1. Actor

Orang atau sistem yang memiliki peranan dalam keberhasilan operasi dari sistem. Dapat digambarkan berupa

orang atau digambarkan dengan segi empat disertai notasi “<<Actor>”.

2. Use Case

Setiap use case mengekspresikan goal dari sistem yang harus dicapai. Diberi nama sesuai dengan goalnya dan

digambarkan dengan elips. Dilabeli dengan frase kata kerja-kata benda deskriptif

41

Elemen Use Case

3. Boundary Sistem/Subjek

Batasan sistem dalam relasi dengan actor-actor yang menggunakannya. Nama Subjek didalam

atau diatas.

4. Relationship

Relationship Function Notation

Association Interaksi antara actor dengan use case, digambarkan

dengan garis. Asosiasi bisa berarah (garis dengan anak

panah) jika komunikasi satu arah, namun umumnya

terjadi kedua arah(tanpa anak panah).

42


Include

Relasi use case tambahan ke sebuah use case dimana use

case yang ditambahkan membutuhkan use case ini untuk

menjalankan fungsinya atau sebagai syarat dijalankannya

use case ini.

Arah panah include mengarah pada use case yang dipakai

(dibutuhkan).

43

Extend Relasi use case (utama) ke sebuah use case lain (tambahan),

dimana use case utama dapat berdiri sendiri meski tanpa

use case tambahan. Arah panah mengarah pada use case

utama.

44


Generalization

Hubungan generalisasi dan

spesialisasi (umum-khusus) antara dua

buah use case dimana

fungsi yang satu

merupakan fungsi yang lebih umum dari

lainnya Arah panah mengarah pada use case general

(umum)

45

Contoh include

Penjelasan gambar :

Use Case Login merupakan syarat

/ selalu dipanggil terlebih dahulu sebelum dijalankannya use case Mengelola

Anggota atau use case Mengelola Peminjaman.

46

Contoh extend

Use case Buka Rekening merupakan use case utama sehingga use case ini

dapat berdiri sendiri sedangkan use case Buka Deposito dan Buat Kartu

Kredit merupakan use case tambahan yang berasal dari pengembangan

use case Buka Rekening .

pada contoh di atas setelah pengguna melakukan Buka Rekening, pengguna

dapat mengembangkannya /

melanjutkannya (opsional) dengan Buka Deposito / Buat Kartu Kredit.

48

Contoh Generalisasi

Use case Mengelola Pustaka merupakan use case

generalisasi / umum.

Sedangkan use case mencari pustaka, melihat

pustaka, memasukkan pustaka, mengubah pustaka

dan menghapus pustaka merupakan use case

spesialisasi / khusus.

49

Pembahasan Studi Kasus

(Planning dan Analisis)

50

Tahapan Waterfall (Planning)

• Sistem yang akan dibuat untuk menyelesaikan permasalahan yang ada,

diantaranya permasalahan dalam penyimpanan data dan dokumen

• Sistem dapat membantu proses pencatatan keuangan pembelian menjadi

lebih baik lagi

51

Tahapan Waterfall (Analisis)

Dalam buku Daniel Siahaan ada beberapa pengertian dari Analisis

Kebutuhan yaitu :

Analisa kebutuhan memungkinkan pengembang membangun model-

model yang akan diterjemahkan ke dalam data, arsitektur, antarmuka, dan

prosedural perancangan menjadi perangkat lunak (Pressman,2008)

Analisis kebutuhan merupakan proses mendapatkan, mengklasifikasikan,

dan menstrukturisasi informasi yang dilakukan oleh perekayasa ketika

berusaha memahami semua bagian dari permasalahan dan hubungannya.

(Siahaan, 2012)

52

Tahapan Analisa Kebutuhan

1. Mempelajari dan memahami Persoalan

2. Mengidentifikasi kebutuhan pemakai

3. Mendefinisikan kebutuhan perangkat lunak

4. Membuat dokumen spesifikasi kebutuhan perangkat lunak

5. Mengkaji ulang kebutuhan

Untuk no 1 dan 2 biasanya dijadikan satu dalam pelaksanaannya.

(Yasin,2012 : 117)

53

Tahapan 1 dan 2

• Siapa pemakai yang menggunakan perangkat lunak

• Dimana perangkat lunak digunakan

• Apa saja cakupan pekerjaan dan bagaimana mekanismenya

• Apa yang menjadi kendala

• Fungsi apa yang diinginkan pada perangkat lunak

• Kelakuan sistem yang diharapkan

(Yasin,2012 : 117-118)

54

Perusahaan Annoname, melakukan transaksi pembelian barang-barang

kebutuhan perusahaan kepada supplier. Proses berawal dari Bagian

pembelian melakukan pemesanan barang. Mulai dari proses pemesanan

barang, bag. pembelian mengirimkan surat pesanan kepada supplier.

Setelah barang yang dibeli diterima oleh bagian pembelian, maka akan dicek

terlebih dahulu antara surat pesanan dan Surat jalan yang diterima, apakah

ada cacat/rusak dari barang atau tidak. Barang yang diterima akan di catat

dalam transaksi pembelian yang akan mempengaruhi stok dan akan

membentuk jurnal pembelian. Semua transaksi yang terjadi akan dibuatkan

laporannya berupa laporan pesanan, laporan pembelian, dan laporan retur

pembelian untuk Pimpinan.

Jika terjadi barang rusak maka akan dilakukan retur dan membuat surat retur

yang ditujukan kesupplier. Barang yang sudah diterima akan diselesaikan

pembayarannya dari faktur yang dikirim dari supplier untuk bagian

keuangan dan bagian pembelian akan mendapatkan info pembayaran.

55

Tahapan 1 dan 2

Berikut beberapa tahapan yang dapat dilakukan pada contoh kasus pembelian

diatas.

1. Pemakai sistem :

Bagian Pembelian, Pimpinan

2. Dimana perangkat lunak digunakan:

Disistem Pembelian

3. Data dan infomasi yang akan diproses : Data Barang,

data supplier, data akun, pesanan, retur dan pembelian,

laporan

56

4. Proses Bisnis sistem Pembelian :

• Proses Pemesanan : bagian pembelian mengirimkan surat pesanan

pembelian kepada supplier

• Proses Penerimaan barang : bagian pembelian menerima barang

dan surat jalan, barang yang diterima oleh bagian pembelian akan

dicek antara surat pesanan dan surat jalan yang diterima, kemudian di

cek kondisi barang, jika tidak sesuai maka akan dibuatkan retur untuk

diserahkan ke supplier. Barang yang diterima akan di catat dalam

transaksi pembelian yang akan mempengaruhi stok dan akan

membentuk jurnal pembelian

• Proses Laporan : Semua transaksi yang terjadi akan dibuatkan

laporannya berupa laporan pesanan barang, laporan pembelian, dan

laporan retur barang yang akan di serahkan pada Pimpinan

57

act Sistem Pembelian

PimpinanSupplierBagian Pembelian

start

Membuat surat

pesanan pembelian

Menyerahkan surat

pesanan pembelian

Menerima surat

pesanan pembelian

Menyerahkan

barang

Menyerahkan

surat jalan

Menerima barang dan

surat jalan

fork

join

Melakukan

pemeriksaan

Sesuai?

Membuat returMelakukan

pencatatan

pembelian

Menyerahkan

retur

Menerima retur

FlowFinal

Membuat laporan

Menyerahkan

laporan

pesanan

Menyerahkan

laporan

pembelian

Menyerahkan

laporan retur

fork join

Menerima laporan

pesanan, laporan

pembelian dan laporan

retur

Final

ya tidak

58

Spesifikasi Dokumen Masukan ( Surat Jalan)

Nama Dokumen : Surat Jalan

Fungsi : Sebagai bukti penerimaan barang

Sumber : Supplier

Tujuan : Bagian pembelian

Media : Kertas

Jumlah : Satu lembar

Frekuensi : Setiap terjadi pembelian barang Bentuk : A1

59

Spesifkasi dokumen keluaran ( surat pesanan pembelian, retur,

laporan pesanan, laporan pembelian dan laporan retur )

Nama Dokumen : Retur

Fungsi : sebagai bukti retur barang

Sumber : Bagian pembelian

Tujuan : Supplier

Media : Kertas

Jumlah : satu lembar

Frekuensi : setiap terjadi retur barang

Bentuk : B1

60

Kebutuhan Fungsional

Digambarkan dengan Diagram Use Case

61

Kebutuhan akan sistem Pembelian

Bagian Pembelian :

Dapat Mengolah data Barang Dapat Mengolah data Supplier Dapat Mengolah Akun

Dapat Membuat Pesanan Dapat Membuat Retur

Dapat Mengolah transaksi pembelian Dapat Membuat Jurnal Pembelian Dapat

Membuat Laporan

Pimpinan

Melihat laporan

62

Sea Level Use Case Pembelian

63

Fish Level Use Case Pembelian

64

Sekenario Use Case

Dari diagram use case yang sudah dibuat, maka selanjutnya dibuatkan

Sekenario Use case

Sekenario Use Case berguna untuk menjelaskan secara detail alur sistem

yang akan terjadi, dan nantinya akan dapat membantu dalam pembuatan

Activity Diagram.

Berikut sekenario diagram use case Membuat Pesanan dan Mengolah Data

Barang

65

Use Case Name Membuat Pesanan

Requirements Bagian Pembelian Mengolah data Pesanan

Goal Admin dapat menambah data pesanan

Pre-conditions Admin telah login ke sistem pembelian

Post-conditions Data pesanan tersimpan, terupdate

Failed end condition Gagal menyimpan, mengupdate atau menghapus

Primary Actors Bagian Pembelian

66

Main Flow / Basic Path 1. Bagian Pembelian memilih Tambah.

2. Sistem menampilkan form Pesanan Pembelian

3. Sistem membuat nomor otomatis.

4. Bagian Pembelian memilih nama supplier.

5. Sistem menampilkan kode, nama dan alamat supplier.

6. Bagian pembelian memilih kode barang

7. Sistem menampilkan nama, harga barang

8. Admin memasukkan jumlah barang yang akan dibeli

9. Sistem akan mengkalkulasi subtotal, dan total pesanan

10. Bagian Pembelian menyimpan form pesanan

11. Sistem akan menyimpan data pesanan dan mencetak Surat Pesanan

Alternate Flow /

Invariant 1

1. Admin melihat data pesanan

67

2. Sistem menampilkan Daftar pesanan yang telah terjadi maupun yang sedang terjadi

68

Use Case Name Mengolah Data Barang

Requirements Bagian Pembelian Mengolah data Barang

Goal Admin dapat menambah , mencari, merubah, menghapus, dan

menyimpan data barang

Pre-conditions Admin telah login ke sistem pembelian

Post-conditions Data barang tersimpan, terupdate, terhapus

Failed end condition Gagal menyimpan, mengupdate atau menghapus

Primary Actors Bagian Pembelian

69

Main Flow / Basic Path 1. Bagian Pembelian memilih Tambah.

2. Sistem menampilkan form barang

3. Bagian pembelian menginput kode barang, nama barang,

harga, stok barang

4. Bagian pembelian memilih simpan

5. Sistem akan menyimpan data barang

6. Bagian Pembelian menyimpan form pesanan

Alternate Flow /

Invariant 1

1. Bagian pembelian dapat membatalkan penginputan data

2. Sistem akan menghapus data yang telah diinput

3. Bagian pembelian dapat mencari data barang

4. Sistem menampilkan data barang

70

Daftar Pustaka

Alan Dennis et al, Systems Analysis and Design with UML

4th Edition, John Wiley and Sons, 2013

http://www.materidosen.com/2017/04/use-case-diagram-lengkap-

studi-kasus.html

Tohari, Hamim.2014. Analisis Serta Perancangan Sistem Informasi Melalui

Pendekatan UML.Yogakarta:Andi

Yasin, Verdi. 2012. Rekayasa Perangkat Lunak Berorientasi Objek

Pemodelan, Arsitektur dan Perancangan (Modeling,

Architecture and Design). Jakarta. Mitra Wacana Media.

https://www.youtube.com/watch?v=h28T37mnMLI

https://www.uml-diagrams.org/uml-24-diagrams.html

http://www.materidosen.com/2017/04/use-case-diagram-lengkap-studi-kasus.html

http://www.materidosen.com/2017/04/use-case-diagram-lengkap-studi-kasus.html

https://www.youtube.com/watch?v=h28T37mnMLI

https://www.uml-diagrams.org/uml-24-diagrams.html

71

PERTEMUAN 3

Perancangan Sistem

72


Mahasiswa mengetahui dan memahami mengenai bagaimana pembuatan Activity

Diagram serta dapat menggambarkan Activity Diagram dengan baik berdasarkan studi

kasus yang diberikan.

Materi Pertemuan 3

1. Konsep Dasar Activity Diagram

2. Studi Kasus Pembelian

73

Konsep Dasar Activity Diagram

Menurut (Akil, 2018), dalam suatu organisasi yang berorientasi profit maupun non

profit pasti memiliki proses-proses dan prosedur-prosedur (bussiness process)

yang harus dilaksanakan sebagai landasan operasional perusahaan.

Menurut (Gata & Gata, 2013), Activity Diagram menggambarkan workflow (aliran

kerja) atau simbol dari sebuah sistem atau proses bisnis atau menu yang ada

diperangkat lunak.

74

Elemen dalam Activity Diagram,

sebagai berikut :

Simbol Nama Simbol Fungsi

Action

Action merupakan aksi-aksi individual yang bersifat komputasional, seperti memasukkan nilai, mengambil nilai , memanggil operasi dari suatu objek

Action adalah unit fungsional dasar didalam sebuah activity diagram

75

Activity

Activity merupakan unit organisasional didalam activity diagram

Activity dapat berisi grup-grup dari action-action

76


Control Flow

Control Flow menunjukkan arus kendali dari suatu action/activity ke action/activity yang lain

Ketika action/activity selesai dieksekusi maka flow akan berlanjut ke action atau activity lainnya.

Initial Node

Initial Node adalah titik awal serangkaian activity atau action

Flow Final Node

Flow Final Node, digunakan sebagai tanda akhir dari sebuah control flow

77


Activity Final Node Activity Final Node, digunakan sebagai tanda akhir dari

semua control flow dalam activity.

78

Decision dan Merge

Decision dan Merge node memiliki

notasi yang sama yaitu Belah Ketupat.

Sebuah decision akan membagi flow menjadi dua dimana

hanya satu flow yang akan dilalui apabila kondisi guard

terpenuhi

Merge adalah tempat bergabung kembali flow yang

terpisah karena decision

79


act Activ ity Diagram - ATM

Fork dan Join

Fork dan Join mengindikasin proses yang paralel atau

concurrent (bersamaan)

Fork untuk percabangan proses yang dieksekusi secara

parallel atau bersamaan

Join sebagai titik temu proses-proses yang parallel menjadi

satu flow, dimana flow ini tidak akan berjalan sebelum

semua proses selesai

Sumber (Akil, 2018)

80

Pembahasan Studi Kasus

Activity diagram ini dibuat berdasarkan analisa kebutuhan yang telah

dibahas dalam pertemuan ke-2, dimana adanya pengembangan sistem

dalam sistem pembeliannya.

Kebutuhan akan sistem Pembelian

Bagian Pembelian :

• Dapat Mengolah data Barang

• Dapat Mengolah data Supplier

• Dapat Mengolah Akun

• Dapat Membuat Pesanan

• Dapat Membuat Retur

• Dapat Mengolah transaksi pembelian

• Dapat Membuat Jurnal Pembelian

• Dapat Membuat Laporan, PimpinanMelihat laporan

81

Sea Level Use Case Pembelian

82

Fish Level Use Case Pembelian

83

• Use case yang ada akan membentuk diagram aktivitas, satu use case

membentuk satu activity diagram

• Activity diagram menggambarkan secara detail dari diagram use case

• Dalam kasus pembelian, akan digambarkan diagram aktivitas mengolah

data barang dan mengolah data akun

84

Activity Data Barang

act databarang

SistemAdmin

klik menu Data Barangmenampilkan form Data

Barang

memberikan pilihanmenentukan pilihan

memilih tambah memilih cari keluar kembali ke Menu Utama

melakukan input

Data Barangmelakukan input id

barang

memproses cari id

barang

menampilkan Data

Barangmenampilkan pesan

data tidak ketemu

ubah

hapusmemproses

perubahan data

memproses

hapus data

proses

batal

proses

simpan

Form Data Barang

tidak

valid

tidak

ya

tidak valid

tidakya

ya

85

Activity Data Akun

act data akun

Admin Sistem

klik menu data akunmenampilkan form data

akun

memberikan pilihanmenentukan pilihan

memilih carimemilih tambah keluarkembali ke

menu utama

melakukan

input data akun

melakukan

input kode

akun

memproses cari

kode akun

menampilkan

data akun

menampilkan

pesan data tidak

ketemu

ubah

memproses

perubahan data

hapus

memproses

hapus data

proses batalproses simpan

Form Data Akun

tidak

tdk valid

ya

tidak

ya

valid

tidak

ya

86

Untuk pembuatan Activity Diagram

selanjutnya, dapat dijelaskan oleh Dosen, dengan memberikan contoh pembuatan Activity Diagram Transaksi Pesanan

menyesuaikan dengan Sekenario Use Case yang telah dibuat.

LATIHAN MANDIRI

Dosen Memberikan Soal Studi Kasus Mahasiswa Mengerjakan Soal secara mandiri, dengan urutan pengerjaan :

1. Analisa Kebutuhan

2. Diagram Use case

3. Diagram Activity

Dosen Menilai tugas mahasiswa untuk nilai Tugas 1

87

Daftar Pustaka

Gata dan Gata.2013. Sukses membangun aplikasi Penjualan dengan Java. Jakarta : PT. Elex Media Komputindo.

Akil, Ibnu. 2018. Referensi Dan Panduan UML 2.4. Jakarta : Ibnu Akil

88

PERTEMUAN 4

Desain Database

89


Mahasiswa mengetahui dan memahami bagaimana membuat desain database

berdasarkan dari analisa kebutuhannya. Penggambaran database ini menggunakan

class diagram.

Materi Pertemuan 4

1. Konsep Dasar Database

2. Class Diagram

3. Pembahasan Studi Kasus

90

1. Konsep Dasar Database

Menurut (Indrajani, 2015) mendefinisikan sebuah basis data merupakan kumpulan

data yang saling berhubungan secara logis, dan merupakandata yang dibutuhkan oleh

sebuah organisasi.

Dalam database, semua data diintegrasikan untuk menghindari adanya duplikasi

data.

Konsep Dasar Database

Menurut (Indrajani, 2015), Desain database adalah proses membuat desain yang akan

mendukung operasional dan tujuan perusahaan.

Tujuan desain database :

1. Menggambarkan relasi data antara yang dibutuhkan oleh aplikasi dan user

view

2. Menyediakan model data yang mendukung seluruh transaksi yang

diperlukan

3. Menspesifikasikan desain dengan struktur yang sesuai kebutuhan sistem

91

2. Class Diagram

Menurut Tohari(2013:83) , diagram kelas (class diagram) menggambarkan

jenis-jenis dari objek dalam suatu sistem dan berbagai jenis hubungan statis

yang ada diantaranya.

Menurut (Akil, 2018), Class (Kelas) adalah deskripsi dari satu set objek-objek

yang berbagi atribut-atribut, operasi-operasi, relasi-relasi, semantik-

semantik yang sama.

Sebuah Kelas merupakan kumpulan dari objek yang memiliki karakteristik

yang sama seperti atribut, operasi hubungan dan semantik.

Kelas juga merupakan sebuah spesifikasi yang jika diinstansiasi akan

menghasilkan sebuah objek dan merupakan inti dari pengembangan dan

perancangan berorientasi objek.

92

Simbol-Simbol dalam Class Diagram

1. Class

Class terdiri dari tiga area, sebagai berikut :

class Class Model

Class Name

- Atribut: int

+ Operation()

93

Keterangan

• Class Name

❑ Nama kelas bersifat tekstual dan selalu diwali dengan huruf besar

❑ Jika terdiri dari dua suku kata, maka penamaannya harus disambung

dan suku kata kedua diawali dengan huruf besar

❑ Kelas bisa digunakan untuk mewakili orang, tempat atau hal-hal

yang dibutuhkan oleh sistem, yang digunakan untuk menangkap

atau menyimpan informasi

94

Keterangan

• Attribute (Atribut)

❑ Atribut adalah properti yang memiliki nama dari suatu kelas yang

menjadi karakteristik dari kelas tersebut

❑ Atribut merepresentasikan property yang sedang anda modelkan

❑ Sebuah atribut harus memiliki type data sesuai dengan bahasa

pemrograman kelas tersebut

❑ Nama atribut biasanya diawali dengan huruf kecil dan suku kata

berikutnya diawali huruf besar

95

Keterangan

❑ Atribut juga memiliki jangkauan visibility, baik yang bersifat public

(+), private (-), protected (#) dan package (~)

❑ Visibility adalah spesifikasi yang dapat dimiliki oleh kelas, atribut dan

operasi yang menetukan hak akses atau jangkauan atribut dan

operasi tersebut

❑ (-) private, hanya kelas yang bersangkutan yang dapat menggunakan

fitur tersebut

❑ (+) public, kelas-kelas diluar kelas yang bersangkutan dapat

mengakses dan menggunakannya

❑ (#) protected, setiap kelas turunannya dapat mengakses dan

menggunakannya

❑ (~) package, hanya kelas yang berada dalam package yang sama

yang dapat mengakses dan menggunakannya

96

Keterangan

• Operation()

❑ Operation (operasi) adalah implementasi dari layanan yang dapat

diminta dari objek manapun dari kelas

❑ Operasi merupakan perilaku dari objek yang mempengaruhi status

dari objek

❑ Dalam konteks pemrograman operasi pada dasarnya sebuah fungsi

atau prosedur yang dimiliki objek terkait

❑ Suatu operasi dapat mengembalikan nilai sesuai dengan type data

yang kita tentukan

97

• Contoh Class

class Class Model

Mobil

-

-

-

-

-

merk: String

mesi n: String

model: String

tahun: int

warna: String

+

+

+

+

+

break(): voi d

moveBackward(): voi d

moveForward(): voi d

moveLeft(): voi d

moveRi ght(): voi d

98

public class Mobil {

P private String merk;

e private String mesin;

private String model; n

private int tahun; e

private String warna;

r

a public Mobil(){

p

a }

n

public void finalize()

k throws Throwable {

o

d }

e

public void break(){

}

public void moveBackward(){

}

public void moveForward(){

}

public void moveLeft(){

}

public void moveRight(){

}

}

99

2. Multiplicity

Menurut (Akil, 2018), Multiplicity (baca : multiplisitas) adalah spesifikasi

jangkauan kardinalitas yang diijinkan yang dimiliki suatu entitas.

Multiplisitas menunjukkan jumlah suatu objek yang dapat berhubungan

dengan objek yang lain.

Multiplisitas biasanya ditunjukkan dengan satu atau banyak, tetapi secara

khusus dapat ditunjukkan pula dengan bilangan integer lebih besar atau

sama dengan nol

100

Menurut (Tohari, 2014), jenis-jenis multiplisitas sebagai berikut :

Indikator Arti

0..1 Nol atau satu

1 Hanya satu

0..* Nol atau banyak

1..* Satu atau banyak

n Hanya n (dengan n>1)

0,..n Nol sampai n (dengan n>1)

1..n Satu sampai n (dengan n>1)

101

Contoh

- (Cara baca dari kiri ke kanan) Setiap karyawan bisa kemungkinan tidak memiliki mobil atau memiliki satu mobil

- (Cara baca dari kanan ke kiri) Setiap mobil kemungkinan tidak dimiliki oleh karyawan atau dimiliki oleh seorang karyawan

- Kesimpulan kardinalitasnya adalah one to one

102

- (Cara baca dari kiri ke kanan) Setiap konsumen melakukan satu atau banyak transaksi

- (cara baca dari kanan ke kiri) Setiap transaksi dilakukan oleh satu konsumen

- Kesimpulan kardinalitasnya adalah one to many

103

• (Cara baca dari kiri ke kanan) Setiap transaksi melibatkan satu atau banyak barang

• (Cara baca dari kanan ke kiri) Setiap barang dilibatkan dalam satu atau banyak transaksi

• Kesimpulan kardinalitasnya adalah many to many

3. Generalization

Menurut (Akil, 2018)

Sebuah generalization (baca : generalisasi) adalah hubungan antara kelas umum (parent / superclass) dengan kelas khusus

(child/ subclass)

Dengan hubungan generalisasi suatu kelas child dapat mewarisi struktur dang tingkah laku dari kelas parentnya.

104

4. Association (Asosiasi) Menurut (Akil, 2018)

Asosiasi adalah hubungan struktural yang menspesifikasikan bahwa objek-objek dari satu hal terhubung dengan objek yang

lainnya.

Sebuah asosiasi biasanya memiliki nama yang menjelaskan secara alami hubungan tersebut

Dapat ditambahkan direction (arah) hubungan asosiasi tersebut

5. Aggregation (Agregasi)

Hubungan keseluruhan/bagian, dimana satu kelas merepresentasikan hal yang lebih besar keseluruhan yang berisi hal lebih

kecil bagian, hubungan ini disebut Agregasi

Agregasi merepresentasikan hubungan memiliki yang berarti bahwa objek keseluruhan memiliki objek-objek bagian.

Agregasi digambarkan sebagai asosiasi dengan belah ketupat kosong pada objek keseluruhan

105

Contoh

Keseluruhan Agregasi Bagian

class Class Model

Perusahaan Div isi

Keseluruhan Agregasi Bagian

106

6. Composition (komposisi)

Komposisi adalah bentuk agregasi dengan hubungan kepemilikan yang lebih kuat dan lifetimedari objek sebagai bagian dari

keseluruhan.

Objek-objek yang merupakan bagian pada saat diinstansiasi hanya dapat dimiliki oleh objek keseluruhan dan hidup selama

keseluruhan hidup.

107

• Dari gambar diatas, objek KeranjangBelanja merupakan komposisi dari objek ItemBarang

• Objek ItemBarang sepenuhnya dimiliki oleh objek kerangjangBelanja dan hidup selama objek KerangjangBelanja hidup

class Class Model

KeranjangBelanja ItemBarang

1..*1

108

Class Diagram yang terbentuk untuk kasus sistem pembelian sebagai berikut :

class Sistem Pembelian

Pemesanan

- noPesan: char

- tglPesan: date

- total: int

+ batal(): void

+ keluar(): void

+ simpan(): void

+ tambah(): void

DetailPesan

- kdBarang: char

- noPesan: char

- qtyPesan: int

- subTotal: int

Barang

- harga: int

- kdBarang: char

- nmBarang: char

- stok: int

+ batal(): void

+ cari(): void

+ edit(): void

+ hapus(): void

+ keluar(): void

+ simpan(): void

+ tambah(): void

Supplier

- alamat: char

- kdSupp: char

- nmSupp: char

- telepon: char

+ batal(): void

+ cari(): void

+ edit(): void

+ hapus(): void

+ keluar(): void

+ simpan(): void

+ tambah(): void

Pembelian

- noBeli: char

- noFaktur: char

- tglBeli: date

- totalBeli: double

+ batal(): void

+ keluar(): void

+ simpan(): void

+ tambah(): void

DetailPembelian

- kdBarang: char

- noBeli: char

- qtyBeli: int

- subBeli: int

ReturBeli

- noRetur: char

- tglRetur: date

- totalRetur: double

+ batal(): void

+ keluar(): void

+ simpan(): void

+ tambah(): void

DetailRetur

- kdBarang: char

- noRetur: char

- qtyRetur: int

- subRetur: double

Jurnal

- noJurnal: char

- tglJurnal: date

+ batal(): void

+ keluar(): void

+ simpan(): void

+ tambah(): void

DetailJurnal

- debet: int

- kredit: int

- noAkun: char

- noJurnal: char

Akun

- nmAkun: char

- noAkun: char

+ batal(): void

+ cari(): void

+ edit(): void

+ hapus(): void

+ keluar(): void

+ simpan(): void

+ tambah(): void

User

- hakAkses

- idUser

- nmUser

- pass

+ batal(): void

+ cari(): void

+ edit(): void

+ hapus(): void

+ keluar(): void

+ simpan(): void

+ tambah(): void

1

1

1

1..*

1

1..*

1..*

1

1..*

1

1

0..*

1 0..*

1

1..*

1..*

1

1 0..1

1 1

1 1..*

1..*

1

1..

1..*

0..*

1

1

1..*

1

1

1

1..*

1

1..*

109

Spesifikasi file

Nama File : Supplier

Fungsi : Untuk menyimpan data supplier

Akronim : Supplier.myd

Tipe File : Master

Media File : Harddisk Organisasi File : Index

Sequential Akses File : Random Panjang Record : 71 Karakter

Kunci Field : kdSupp

Software : My SQL

110

Tabel Spesifikasi File

Elemen Data Akronim Tipe Data Panjang Keterangan

Kode Supplier kdSupp Char 3 Primary Key

Nama Supplier nmSupp Char 25

Alamat alamat Char 30

Telepon telepon Char 13

111

Daftar Pustaka

• Akil, Ibnu. 2018. Referensi Dan Panduan UML 2.4. Jakarta : Ibnu Akil

• Indrajani.2015. Database Design. Jakarta : PT. Elex Media Komputindo.

• Tohari, Hamim.2013. Analisis serta Perancnagan Sistem Informasi melalui

Pendekatan UML. Yogyakarta : Andi Offset

112

PERTEMUAN 5

Perancangan Sistem

113


Mahasiswa mengetahui dan memahami pembuatan sequence diagram dan user interface berdasarkan analisa kebutuhannya.

Materi Pertemuan 5

1. Sequence Diagram

2. User Interface

114

1. Sequence Diagram

Menurut (Gata & Gata, 2013), mengemukakan bahwa sequence diagram adalah kelakuan objek pada use case dengan

mendeskripsikan waktu hidup objek dan pesan yang dikirimkan dan diterima antar objek.

Simbol Sequence Diagram

SIMBOL DESKRIPSI

Boundary Class

Berisi kumpulan kelas yang menjadi interface atau interaksi antara satu atau lebih

aktor dengan sistem, seperti tampilan form entry dan form cetak

Control Class

Suatu objek yang berisi logika aplikasi yang tidak memiliki tanggungjawab kepada

entitas, contohnya kalkulasi dan aturan bisnis yang melibatan berbagai objek

115

Entity Class

Merupakan bagian sistem yang berisi kumpulan kelas berupa entitas-entias yang

membentuk gambaran awal sistem dan menjadi landasan untuk menyusun basis data

(Gata & Gata, 2013)

116

Simbol Deskripsi

Aktor

Orang, proses, atau sistem lain yang berinteraksi dengan sistem informasi yang akan dibuat di luar

sistem informasi yang akan dibuat itu sendiri, jadi walaupun simbol dari actor

adalah gambar orang, tapi actor belum tentu merupakan orang.

Object Message

Menggambarkan pesan/hubungan antar obyek, yang

menunjukkan urutan kejadian yang terjadi.

Message to Self

Menggambarkan pesan/hubungan objek itu sendiri, yang

menunjukkan urutan kejadian yang terjadi.

Garis Hidup / Lifeline

Garis titik-titik yang berhubungan dengan objek, sepanjang

lifeline terdapat activation.

117

Waktu Aktif / Activation

Mewakili sebuah eksekusi operasi dari objek, panjang kotak

ini berbanding lurus dengan durasi aktivasi sebuah operasi.

120

User Interface

Menurut Mathiassen dalam (Noerlina,et al, 2007) mendefinisikan bahwa user interface adalah “interface yang dibuat untuk

user”. Biasanya user interface dibuat dalam bentuk dialog ang saling berubungan antara menu, tombol dan layar (Navigation

Diagram).User Interface (cont’)

Adapun Desain User Interface yang telah dibuat dalam sistem Pembelian ini sebagai berikut :

1. Form Barang

2. Form Akun

3. Form Transaksi

4. Form Supplier

Dan yang dicontohkan adalah Form Barang dan Form Akun

121

Form Data Barang

122

Form Akun

123

Daftar Pustaka

• Gata, Windu dan Gata, Grace. 2013. Sukses Membangun Aplikasi Penjualan dengan Java.

Jakarta : Elex Media Komputindo

• Noerlina, Idris Gautama, Henricus Bambang.2007.Perancangan Sistem Informasi Berbasis

Object Oriented Studi Kasus. Jakarta: Mitra Wacana

• Modul Java 2

124

PERTEMUAN 6

Perancangan Sistem (Lanjutan) dan Implementasi

125


Mahasiswa mengetahui dan memahami pembuatan Deployment Diagram dan dapat

mengimplementasikan kedalam Bahasa Pemrograman

Deployment Diagram & Bahasa

Pemrograman

1. Deployment Diagram

• Menggambarkan topologi hardware yang ada pada sistem dan merupakan

bagian dari spesifikasi arsitektur sistem.

• Menggambarkan penampakan statis dari detail implementasi komponen

software yang terkait dengan hardware.

• Menggambarkan detail konfigurasi run-time yang didalamnya termasuk detail

hardware seperti processor dan perangkat lain, protokol, middleware dan

server database yang didistribusikan di jaringan atau server database terpusat.

126

Simbol Deployment Diagram

a. Node:

– Merupakan unit komputasi yang dapat berupa hardware maupun software.

– Contoh: komputer, printer, mesin ATM, Card Reader.

– Disimbolkan dengan kubus

Node:

– Kubus tersebut menggambarkan device ataupun processor

– Device digambarkan dengan kubus tanpa bayangan.

– Processor digambarkan dengan kubus berbayangan

127

b. Connection:

– Menggambarkan interaksi antar device.

– Secara umum hubungan antara nodes menggambarkan

mekanisme komunikasi dan dapat bertindak sebagai protokol

software

– Menggambarkan kabel RS-232, koneksi Ethernet, koneksi LAN,

satelit, RMI, WAP, SOAP, ODBC, JDBC- ODBC.

– Disimbolkan dengan garis lurus horizontal

Contoh Deployment diagram dengan

komponen software dan database

129

Contoh pada ERP System

130

• Contoh koneksi antara PC user, server aplikasi, server database dan web service

131

Deployment Diagram untuk Sistem

Pembelian

132

2. Bahasa Pemrograman

• Contoh bahasa PBO:

Java, C++, C#, Python, PHP, Ruby, Perl, Object Pascal, ObjectiveC, Dart,

Swift, Scala, Commo n Lisp dan Smalltalk.

• Meningkatkan efektivitas dan efisiensi program karena adanya konsep

penggunaan ulang komponen (Component Reuseable)”

Implementasi Class Diagram

• Bisa dalam bentuk kelas di dalam bahasa pemrograman ataupun kelas-kelas

persisten yang hadir dalam tabel di dalam basisdata relasional.

133


• Membuat implementasi kode atas kelas-kelas yang terdapat pada class

diagram.

• Membuat konstruktor ataupun setter dan getter

untuk kelas yang bersangkutan.

• Implementasi atribut dalam kelas menjadi kode program, dan sesuai dengan

konsep PBO yakni encapsullation maka setiap atribut memiliki visibility

private.

• Membuat implementasi kode atas setiap metode pada setiap kelas dengan

memberikan visibility public

• Mengimplementasi atribut dan metode yang akan diwariskan dengan

memberikan visibility protected.

134


135

Implementasi Activity Diagram

136

Kode Program Hasil Implementasi

137

DAFTAR PUSTAKA

Nugroho, Adi. 2009. Rekayasa Perangkat Lunak Menggunakan

UML dan Java. Penerbit Andi. Yogyakarta.

Mala, D.J., Geetha.S. 2013. Object Oriented Analysis And Design - Using UML. Mc Graw Hill Wducation. New Delhi.

138

PERTEMUAN 7

PENGUJIAN

139


Mahasiswa mengetahui dan memahami definisi pengujian dan bagaimana cara pengujian.

Pembahasan

1. Definisi Pengujian

2. Tahapan Pengujian

3. Faults, error dan Failures

4. Pengujian Aplikasi Web

5. Studi Kasus

141

1. Definisi Pengujian

• Pengujian adalah proses melaksanakan atau mengevaluasi sistem atau

komponen sistem dengan cara manual atau otomatis untuk memverifikasi

bahwa telah memenuhi persyaratan tertentu. (IEEE83a)

• Pengujian perangkat lunak adalah proses mengeksekusi program atau sistem

dengan tujuan menemukan kesalahan (Myers)

• Pengujian perangkat lunak secara sederhana sering disebut sebagai verifikasi

& validasi (V&V).

• Verifikasi: serangkaian tugas untuk memastikan bahwa setiap fungsi telah

diimplementasikan dengan benar pada perangkat lunak.

• Validasi: serangkaian tugas untuk memastikan bahwa perangkat lunak yang

telah dibangun telah sesuai dengan kebutuhan.

(Pressman,2012)

142

V & V

Pressman, 2012

Verification:

“Are we building the product right?”

Validation:

“Are we building the right product?”

143

• Pengujian lebih dari sekadar debugging, karena tidak hanya digunakan untuk

mencari kesalahan dan memperbaikinya.

• Tetapi terdiri dari validasi, verifikasi dan pengukuran keandalan (reabilitas)

Test Data & Test Cases

• Test data: Input yang yang direncanakan digunakan oleh sistem.

• Test cases: Input yang digunakan untuk menguji sistem dan memprediksi

output dari input jika sistem beroperasi sesuai dengan spesifikasi.

Akhir Pengujian

• Pesimistic: pengujian berhenti ketika sumberdaya yang dialokasikan (waktu,

anggaran, test case) telah habis

• Optimistic: pengujian berhenti ketika reliabilitasnya sudah terpenuhi ataupun

ketika keuntungan dari melanjutkan pengujian tidak sebanding dengan biaya

pengujian.

144

2. Tahapan Pengujian

Unit Integration System Acceptance

Dennis,2012

145

A. Unit

• Menguji komponen Perangkat Lunak (PL) komponen ataupun modul.

• Harus dipastikan bahwa desain terperinci untuk setiap unit telah dilakukan dengan benar.

• Pada OO, dilakukan terhadap Class hingga construktor dan destruktor

Black Box

White Box Spesifikasi Program

Source Code

146

B. Integration

• Menjelaskan kecacatan yang ada pada antarmuka dan interaksi yang ada pada

modul.

• Pengujian PL yang dipadukan dengan elemen dari desain arsitekturnya hingga PL

bekerja sebagai Sistem.

147

Integration Testing

Menguji Semua Skenario

Data Flow Testing : Menguji

Semua Proses Tahap demi tahap

User Interface Testing : Menguji

Semua Antarmuka

System Interface Testing : Menguji Pertukaran Data pada dan antar sistem

148

C. System

• Menguji sistem terpadu secara menyeluruh untuk memastikan sistem telah sesuai dengan persyaratan.

• Menguji Kesesuaian sistem dengan persyaratan

Requirement

• Menguji Kenyamanan Sistem

Usability

• Menguji Akses yang tidak sah dan Recovery nya

Security

• Menguji Kemampuan sistem dengan beban yang tinggi

Performance

• Memeriksa akurasi dokumentasi

Documentation

149

D. Acceptance

Alpha Dilakukan oleh Pengguna, untuk memastikan Sistem diterima oleh Pengguna

Betha

Menggunakan Data Real, Bukan data Uji

150

3. Faults, Error dan Failures

• Fault: kesalahan dalam source code yang mungkin

menimbulkan failure ketika code yang fault tersebut

dijalankan.

• Error : kesalahan dalam logika yang mungkin menimbulkan failure

ketika program sedang dijalankan.

• Failure: output yang tidak benar/tidak sesuai ketika sistem dijalankan.

151

4. Pengujian Aplikasi Web

Definisi

• Serangkaian aktivitas untuk menemukan kesalahan dalam isi, fungsi,

kegunaan, kemampuan navigasi, kinerja kapasitas dan keamanan aplikasi

web (Pressman, 2013).

Web.App

• Pada sistem berbasis web, browser berada di workstation klien. Workstation

klien ini terhubung ke server web, baik melalui koneksi jarak jauh atau

melalui jaringan seperti jaringan area lokal (LAN) atau jaringan area luas

(WAN).

• Ketika server web menerima dan memproses permintaan dari workstation

klien, permintaan dapat dikirim ke server aplikasi untuk melakukan tindakan

seperti permintaan data, transaksi perdagangan elektronik, dan sebagainya.

• Proses back-end bekerja di latar belakang untuk melakukan pemrosesan batch

dan menangani transaksi bervolume tinggi. Pemrosesan back-end juga dapat

berinteraksi dengan transaksi ke sistem lain dalam organisasi.

• Misalnya, ketika transaksi perbankan online diproses melalui Internet,

transaksi akhirnya diperbarui ke akun pelanggan dan ditampilkan dalam

proses back-end.

152

Pengujian Web.App

Perry, 2006

153

Task 1:

Select Web-Based Risks to Include in the Test Plan

Keamanan.

Usability

Integritas

Data

Kinerja.

Kebenaran

Keandalan Kompatibilitas

154

Task 2:

Select Web-Based Tests

155

Task 3:

Select Web-Based Test Tools

• Memverivikasi HTML.

HTML tools.

• Memeriksa aplikasi web untuk mengidentifikasi inkonsistensi dan kesalahan, seperti tautan halaman .

Site validation tools.

• Mengevaluasi sistem saat mengelola sejumlah besar data atau transaksi.

Load/stress testing tools.

• Menciptakan transaksi untuk digunakan dalam pengujian

Test case generators.

156

Task 4:

Test Web-Based Systems

Organizing

Verification

Analyzing

& Reporting

Post- Implement

ation Analysis

Test Plan Validation Acceptance & Operationa l

158

5. Studi Kasus

• Dilakukan Pengujian terhadap Web E- Commerce Produk Unggulan Desa.

• Pengujian yang dilakukan menggunakan Blackbox

159

Pengujian Login Admin

160

Pengujian Modul Transaksi

161

Pengujian Modul Transaksi

Notifikasi Kesalahan Pada

Informasi Penagihan

Notifikasi Kesalahan Pada Pembayaran dengan Kupon

162

Form Pemesanan

163

DAFTAR PUSTAKA

Pressman, Roger S. 2012. Rekayasa Perangkat Lunak Pendekatan

Praktisi. Edisi 7. Yogyakarta. Penerbit Andi.

Dennnis, A., Wixom, B.H., Roth, R.M. 2012. System Analysis And

Design. 5th Edition. New Jersey. John Willey & Sons Inc.

Perry, W.E. 2006. Effective Methods for Software Testing. 3rd Edition.

Indiana. Willey Publishing Inc.

Simarmata, Janner. 2010. Rekayasa Perangkat Lunak. Yogyakarta.

Penerbit Andi.

Wahyunningrum, T & Dwi Januarita. Implementasi dan Pengujian Web E-

commerce untuk Produk Unggulan Desa. Jurnal Komputer Terapan, Vol 1,

No 1, Mei 2015, 57-66.

MODUL ANALISA PERANCANGAN SISTEM INFORMASI ...

Documents

Transcript of MODUL ANALISA PERANCANGAN SISTEM INFORMASI ...