Planning dan AnalisisSistem

PERTEMUAN 2

Capaian Pembelajaran

Mahasiswa mengetahui dan memahami AnalisisSistem (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

1. Definisi dan Diagram UML

a. Definisi UML

Menurut (Sukamto dan Shalahuddin:2013)

“UML muncul karena adanya kebutuhan pemodelan visual untukmenspesifikasikan, menggambarkan, membangun, dandokumentasi dari sistem perangkat lunak “.

UML adalah bahasa umum untuk analis bisnis, arsitek perangkatlunak dan pengembang yang digunakan untuk mendeskripsikan,menentukan, merancang, dan mendokumentasikan prosesbisnis, struktur, dan perilaku yang ada atau baru dari artefaksistem perangkat lunak.

• UML adalah bahasa penyatuan dari berbagaibahasa pemodelan, sehingga UML tidakmemiliki Metode pemodelan

sumber : Teduh (2016)

b. Diagram UmlDiagram UML 2.4 dapat dikategorikan secara hierarkis :

Diagram struktur mewakili konsep-konsep yangbermakna dari suatu sistem, dan dapat mencakupkonsep-konsep abstrak, dunia nyata dan implementasi.

Diagram perilaku menunjukkan perilaku dinamis dariobjek dalam suatu sistem, yang dapat digambarkansebagai serangkaian perubahan pada sistem dari waktuke waktu.

Sumber : uml-diagram.org

History UML

Dalam materi APSIA, yang akan dibahashanya 5 Diagram, yaitu :

1. Use case diagram

2. Activity diagram

3. Class diagram

4. Sequence diagram

5. Deployment diagram

2. Konsep Dasar Use Case

• Use Case adalah rangkaian atau uraiansekelompok yang saling terkait dan membentuksistem secara teratur yang dilakukan atau diawasioleh sebuah aktor. (Tohari,2014)

• Use Case digunakan untuk membentuk tingkahlaku benda dalam sebuah model sertadirealisasikan oleh sebuah kolaborasi, dan usecase menggambarkan fungsionalitas yangdiharapkan dari sebuah sistem. (Tohari,2014)

Konsep Dasar Use Case

• Use Case diagram menggambarkanfungsionalitas yang diharapkan dari sebuahsistem

• Penekanan Use Case pada “apa” yangdiperbuat sistem, dan bukan “bagaimana”.

• Use Case merepresentasikan sebuah interaksiantara aktor dengan sistem.

(Yasin,2012)

Level of Use Case

Lockburn suggests a scheme of levels of use cases .

• Sea-level use cases typically represent a discreteinteraction between a primary actor and the System.

• Use cases that are there only because they are included bysea-level use cases are fish-level .

• Kite-level use cases are usually business use cases, whereassea and fish levels are system use cases.(fowler,2004)

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

❑ Dalam pembuatan use case, dahulukan membuat use case sealevel, jika ada yang di include silakan lanjut tahap fish level

Elemen Use Case

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

1. Aktor

2. Use cases

3. Subject boundaries,

4. Relationship

Elemen Use Case

1. ActorOrang atau sistem yang memiliki peranan dalamkeberhasilan operasi dari sistem. Dapat digambarkanberupa orang atau digambarkan dengan segi empatdisertai notasi “<<Actor>”.

2. Use CaseSetiap use case mengekspresikan goal dari sistem yangharus dicapai. Diberi nama sesuai dengan goalnya dandigambarkan dengan elips. Dilabeli dengan frase katakerja-kata benda deskriptif

Elemen Use Case

3. Boundary Sistem/SubjekBatasan sistem dalam relasi dengan actor-actor yang menggunakannya. Nama Subjek didalamatau diatas.

4. Relationship

Relationship Function Notation

Association Interaksi antara actor dengan usecase, digambarkan dengan garis.Asosiasi bisa berarah (garis dengananak panah) jika komunikasi satuarah, namun umumnya terjadi keduaarah(tanpa anak panah).

Relationship Function Notation

IncludeRelasi use case tambahan kesebuah use case dimana use caseyang ditambahkan membutuhkanuse case ini untuk menjalankanfungsinya atau sebagai syaratdijalankannya use case ini.Arah panah include mengarahpada use case yang dipakai(dibutuhkan).

Extend Relasi use case (utama) ke sebuahuse case lain (tambahan), dimanause case utama dapat berdirisendiri meski tanpa use casetambahan. Arah panah mengarahpada use case utama.

Relationship Function Notation

Generalization Hubungan generalisasi danspesialisasi (umum-khusus)antara dua buah use casedimana fungsi yang satumerupakan fungsi yanglebih umum dari lainnyaArah panah mengarah padause case general (umum)

Contoh include

Penjelasan gambar :Use Case Login merupakan syarat/ selalu dipanggil terlebih dahulusebelum dijalankannya use caseMengelola Anggota atau use caseMengelola Peminjaman.

Sumber : slidedosen.com(2017)

Contoh extend

Use case Buka Rekening merupakanuse case utama sehingga use case inidapat berdiri sendiri sedangkan usecase Buka Deposito dan Buat KartuKredit merupakan use case tambahanyang berasal dari pengembangan usecase Buka Rekening .

pada contoh di atas setelah penggunamelakukan Buka Rekening, penggunadapat mengembangkannya /melanjutkannya (opsional) denganBuka Deposito / Buat Kartu Kredit.

Sumber : slidedosen.com(2017)

Sumber : slidedosen.com(2017)

Contoh Generalisasi

Use case MengelolaPustaka merupakan use case generalisasi / umum.

Sedangkan use case mencari pustaka, melihatpustaka, memasukkanpustaka, mengubahpustaka dan menghapuspustaka merupakan use case spesialisasi / khusus. Sumber : slidedosen.com(2017)

Pembahasan Studi Kasus

(Planning dan Analisis)

Tahapan Waterfall (Planning)

• Sistem yang akan dibuat untuk menyelesaikanpermasalahan yang ada, diantaranyapermasalahan dalam penyimpanan data dandokumen

• Sistem dapat membantu proses pencatatankeuangan pembelian menjadi lebih baik lagi

Tahapan Waterfall (Analisis)

Dalam buku Daniel Siahaan ada beberapa pengertian dariAnalisis Kebutuhan yaitu :

Analisa kebutuhan memungkinkan pengembang membangunmodel-model yang akan diterjemahkan ke dalam data,arsitektur, antarmuka, dan prosedural perancangan menjadiperangkat lunak (Pressman,2008)

Analisis kebutuhan merupakan proses mendapatkan,mengklasifikasikan, dan menstrukturisasi informasi yangdilakukan oleh perekayasa ketika berusaha memahami semuabagian dari permasalahan dan hubungannya.(Siahaan, 2012)

Tahapan Analisa Kebutuhan

1. Mempelajari dan memahami Persoalan2. Mengidentifikasi kebutuhan pemakai3. Mendefinisikan kebutuhan perangkat lunak4. Membuat dokumen spesifikasi kebutuhan

perangkat lunak5. Mengkaji ulang kebutuhan

Untuk no 1 dan 2 biasanya dijadikan satu dalampelaksanaannya.(Yasin,2012 : 117)

Tahapan 1 dan 2

• Siapa pemakai yang menggunakan perangkatlunak

• Dimana perangkat lunak digunakan

• Apa saja cakupan pekerjaan dan bagaimanamekanismenya

• Apa yang menjadi kendala

• Fungsi apa yang diinginkan pada perangkat lunak

• Kelakuan sistem yang diharapkan

(Yasin,2012 : 117-118)

Perusahaan Annoname, melakukan transaksi pembelian barang-barang kebutuhanperusahaan kepada supplier. Proses berawal dari Bagian pembelian melakukanpemesanan barang. Mulai dari proses pemesanan barang, bag. pembelianmengirimkan surat pesanan kepada supplier.

Setelah barang yang dibeli diterima oleh bagian pembelian, maka akan dicek terlebihdahulu antara surat pesanan dan Surat jalan yang diterima, apakah ada cacat/rusakdari barang atau tidak. Barang yang diterima akan di catat dalam transaksi pembelianyang akan mempengaruhi stok dan akan membentuk jurnal pembelian. Semuatransaksi yang terjadi akan dibuatkan laporannya berupa laporan pesanan, laporanpembelian, dan laporan retur pembelian untuk Pimpinan.

Jika terjadi barang rusak maka akan dilakukan retur dan membuat surat retur yangditujukan kesupplier. Barang yang sudah diterima akan diselesaikan pembayarannyadari faktur yang dikirim dari supplier untuk bagian keuangan dan bagian pembelianakan mendapatkan info pembayaran. Sumber : Penelitian mandiri(2018)

Tahapan 1 dan 2

Berikut beberapa tahapan yang dapat dilakukanpada 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

4. Proses Bisnis sistem Pembelian :

• Proses Pemesanan : bagian pembelian mengirimkan suratpesanan pembelian kepada supplier

• Proses Penerimaan barang : bagian pembelian menerima barangdan surat jalan, barang yang diterima oleh bagian pembelian akandicek antara surat pesanan dan surat jalan yang diterima,kemudian di cek kondisi barang, jika tidak sesuai maka akandibuatkan retur untuk diserahkan ke supplier. Barang yangditerima akan di catat dalam transaksi pembelian yang akanmempengaruhi stok dan akan membentuk jurnal pembelian

• Proses Laporan : Semua transaksi yang terjadi akan dibuatkanlaporannya berupa laporan pesanan barang, laporan pembelian,dan laporan retur barang yang akan di serahkan pada Pimpinan

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

Sumber : Penelitian mandiri(2018)

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

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

Kebutuhan Fungsional

Digambarkan dengan Diagram Use Case

Kebutuhan akan sistem Pembelian

Bagian Pembelian :Dapat Mengolah data BarangDapat Mengolah data SupplierDapat Mengolah AkunDapat Membuat PesananDapat Membuat ReturDapat Mengolah transaksi pembelianDapat Membuat Jurnal PembelianDapat Membuat Laporan

PimpinanMelihat laporan

Sea Level Use Case Pembelian

Sumber : Penelitian mandiri(2018)

Fish Level Use Case Pembelian

Sumber : Penelitian mandiri(2018)

Sekenario Use Case

Dari diagram use case yang sudah dibuat, makaselanjutnya dibuatkan Sekenario Use case

Sekenario Use Case berguna untuk menjelaskansecara detail alur sistem yang akan terjadi, dannantinya akan dapat membantu dalam pembuatanActivity Diagram.

Berikut sekenario diagram use case MembuatPesanan dan Mengolah Data Barang

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

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

2. Sistem menampilkan Daftar pesanan yang telah terjadi maupun yang

sedang terjadi

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

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

Daftar PustakaAlan 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.

Teduh Dirgahayu , R. Rekayasa Perangkat Lunak Pengenalan

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

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