BAB III ANALISA DAN DESAIN SISTEM
D. Use Case Narative
3. Activity diagram memasukkan data anamnese
Activity diagram menggambarkan aktivitas dari sebuah sistem atau proses
bisnis, bukan apa yang dilakukan aktor. Berikut adalah simbol yang digunakan dalamactivity diagram:
Nama Simbol Notasi Keterangan
Status awal
Status awal aktivitas sistem, sebuah activity diagram
memiliki satu status awal.
Aktivitas
Aktivitas yang dilakukan sistem, biasanya diawali dengan kata kerja.
Decision
Asosiasi percabangan, jika pilihan aktifitas lebih dari satu.
Penggabungan (join)
Asosiasi penggabungan, jika lebih dari satu aktivitas digabungkan menjadi satu.
Status akhir
Status akhir yang dilakukan sistem, sebuah diagram aktivitas memiliki satu status akhir.
Swimlane
Memisahkan organisasi bisnis yang bertanggung jawab terhadap aktivitas yang terjadi
Tabel 3.Daftar simbolactivity diagram menurut referensi Rumbaugh
4. Sequence Diagram
Sequence diagram digunakan untuk menunjukkan urutan method /
behavior dalam suatu use case. Berikut adalah simbol yang digunakan
Nama Simbol Notasi Keterangan
Aktor
Orang, proses, atau sistem lain yang berinteraksi dengan sistem informasi yang akan dibuat.
Object lifeline
Object: menyatakan object yang
berinterkasi melalui pesan.
Lifeline : menyatakan lifeline
suatuobject.
Activation
Menyatakan object dalam keadaan aktif dan berinteraksi melalui pesan.
Message type:
create
Menyatakan suatu object
membuatobject yang lain.
Message type :
call
Menyatakan suatu object
memanggil method yang ada
pada object lain atau pada
dirinya sendiri.
Message type :
send
Menyatakan bahwa suatu object
mengirimkan data ke object
Message type :
return
Menyatakan bahwa suatu object yang telah menghasilkan nilai balik keobject tertentu.
Message type :
destruction
Menyatakan akhir lifeline suatu
object.
Tabel 4.Daftar simbolsequence diagram menurut referensi Rumbaugh
5. Entity Relationship Diagram
Entity Relationship Diagram digunakan untuk pemodelan relational
database. Berikut adalah simbol yang digunakan dalam entity
relationship diagram (Connolly, 2005) :
Nama Simbol Notasi Keterangan
Entity (entitas)
Attribute (atribut)
Primary Key
(PK)
Entitas : data inti yang akan disimpan; bakal tabel pada
database.
Atribut : field atau kolom data yang melekat pada suatu entitas.
Primary Key : atribut yang
digunakan sebagai kunci akses
record yang diinginkan
dengan sebuah garis yang menghubungkan entitas terkait, diberi label dengan nama relasi. Arah tanda panah menunjukkan arah relasi.
Attributes on relationship
Attribut yang dimiliki suatu relasi.
Tabel 5.Daftar simbol entity relationship diagram menurut referensi Connolly
Dalam entity relationship, dikenal istilah multiplicity. Multiplicity
merupakan jumlah kejadian yang mungkin dari suatu entity relationship. Berikut cara menggambarkan multiplicity yang terjadi dalam entity relationship :
Jenis Relasi Notasi
one to one (1:1)
one to many (1:*)
many to many (*:*)
Selain penggambaran seperti dalam Tabel 6., multiplicity dapat pula digambarkan seperti berikut :
Multiplicity Constraint Meaning
0..1 Zero or one entity occurrence
1..1 (or just 1) Exactly one entity occurence
0..* (or just *) Zero or many entity occurence
1..* One or many entity occurence
5..10
Minimum of 5 up to a maximum of 10 entity occurence
0, 3, 6-8
zero, or three, or six, seven, or eight entity occurence
BAB III ANALISA DAN DESAIN SISTEM A. Pengumpulan Data
Proses pengumpulan data yang dilakukan penulis menggunakan metode observasi, dan dokumentasi.
• Metode observasi dilakukan dengan mengamati dan ikut serta dalam proses kerja objek penelitian, dalam hal ini adalah proses kerja Bidan Diah Widiarti. Dari hasil observasi, dapat diketahui cara kerja sistem pengolahan data akseptor Keluarga Berencana (KB) yang terdapat di tempat praktek Bidan Diah Widiarti.
• Metode dokumentasi dilakukan dengan mengumpulkan formulir, laporan, dan peraturan yang berkaitan dengan penelitian. Dokumen yang diperoleh adalah :
§ Formulir Kartu Status Peserta KB (lampiran 1),
§ Kunjungan Ulang (lampiran 2), dan
§ Laporan Pelayanan Kesehatan Ibu dan Anak (KIA) KB Bidan Praktek Swasta di Wilayah Kabupaten Bantul (lampiran 3).
Dari hasil observasi dan dokumentasi, diketahui bahwa sistem pengolahan data akseptor KB di tempat praktek Bidan Diah Widiarti masih dilakukan secara manual. Data akseptor KB dicatat dalam formulir kartu status peserta KB, sedangkan data kunjungan ulang dicatat pada formulir kunjungan ulang dan dicatat ulang pada buku regester.
Ketika akseptor KB datang untuk pertama kalinya, Bidan mencatat data pasien dalam kartu status peserta KB. Setelah pemeriksaan selesai, Bidan mencatat diagnosa dan obat yang diberikan pada sebuah buku register, kemudian pasien KB diberi kartu kontrol yang berisi tanggal kunjungan ulang.
Ketika akseptor KB datang untuk kontrol, akseptor menyerahkan kartu kontrol, kemudian Bidan mencari data pasien tersebut, lalu melayani akseptor. Setelah pelayanan selesai, diagnosa dan obat yang diberikan dicatat pada sebuah buku regester. Kemudian Bidan mencatat tanggal kunjungan ulang pada kartu kontrol dan menyerahkannya kembali ke akseptor KB. Pencatatan pada buku regester berdasarkan tanggal kunjungan, bukan berdasar nama pasien.
Setiap akhir bulan, Bidan menyerahkan laporan pelayanan KIA ke Puskesmas. Sebelum laporan dibuat, Bidan merangkum data pasien yang tercatat pada formulir dan buku regester. Kemudian hasil rangkuman tersebut dicatat dalam sebuah formulir laporan pelayan KIA dengan format yang telah tersedia.
Penggambaran sistem yang ada saat ini, dapat dilihat dalam diagram konteks berikut :
B. Analisa Sistem
Proses analisa sistem menggunakan framework PIECES yang dikembangkan oleh James Wetherbe. Framework PIECES berguna untuk mengkategorikanproblem, opportunity, dan directive. Kategori tersebut sesuai dengan akronim dari PIECES :Performance,Information, Economic,Control,
Efficiency, danServices (Whitten, 2004).
Hasil analisa dari data yang berhasil penulis kumpulkan, dapat dilihat dalam tabel analisa sebab dan akibat berikut :
Project: Aplikasi Pengolahan Data
Akseptor KB Bidan Praktek Swasta
Project Manager:
Maria Asumpta Endah Narwastuti
Cause and Effect Analysis System Improvement Objective
Problem or Opportunity Causes and Effect System Objective System Constraint Performance: Proses pencarian data akseptor membutuhkan waktu relatif lama. Terutama saat pasien tidak
Data akseptor dicatat pada buku regester urut berdasar tanggal kunjungan. Bidan mencari Mempermudah proses pencarian data pasien. Pencarian dilakukan berdasarkan nama pasien.
membawa kartu kontrol tanggal terakhir pasien berkunjung terlebih dahulu, kemudian mencari data akseptor dalam formulir Information: Informasi yang disampaikan dalam laporan kurang jelas. Laporan dalam bentuk tulisan tangan memungkinkan adanya perbedaan pemahaman antara orang yang satu dengan yang lain ketika membaca laporan tersebut. Membuat laporan dengan lebih jelas, dengan memilih jenis huruf yang baku / standar. Format laporan sesuai dengan format yang tersedia. Economic: Perlu anggaran Pencatatan dalam buku, Meminimalkan anggaran dengan
khusus untuk perlengkapan. memerlukan anggaran khusus untuk pembelian buku, fotokopi, pena, dan sebagainya. menyimpan data dalam basisdata elektronik. Control: Data akseptor tidak dapat dibaca / hilang.
Penyimpanan yang kurang baik, dengan materi kertas, lebih rentan sobek, basah, hilang, terselip, dsb. Meminimalkan kemungkinan kehilangan data karena basah, terselip, dan sebagainya. Efficiency: Pembuatan laporan membutuhkan waktu relatif lama, dan kurang akurat Proses perangkuman data akseptor untuk laporan membutuhkan ketelitian dan waktu relatif lama. Mempermudah proses pembuatan laporan. Laporan dibuat sesuai dengan format yang telah tersedia.
Services: Pelayanan kurang optimal karena akseptor harus menunggu lebih lama. Terutama ketika akseptor lupa membawa kartu kontrol. Bidan mencari data akseptor secara manual sebelum melakukan pelayanan kepada akseptor. Mempersingkat waktu pencarian untuk meningkatkan pelayanan terhadap akseptor. Pencarian berdasarkan nama akseptor.
Tabel 8.Analisa sebab dan akibat
C. Use Case Diagram
Dari tabel 8., terlihat bahwa dibutuhkan suatu aplikasi pengolahan data akseptor KB yang dapat mengatasi masalah-masalah yang ada. Untuk merancang suatu aplikasi pengolahan data, hal yang pertama dilakukan adalah membuatuse case diagram yang menggambarkan sistem yang akan dibuat.
1. Penentuan aktor
• Bidan adalah pihak yang memiliki kewenangan untuk mengelola data akseptor KB. Pengelolaan data berupa memasukkan data ke dalam sistem, dan menyunting data yang ada dalam sistem.
• Akseptor adalah pihak yang data diri ataupun rekam medisnya akan diolah oleh sistem.
2. Use case diagram aplikasi pengolahan data akseptor KB Bidan Memasukkan Data Akseptor KB Menyunting Data Akseptor KB Mencetak Laporan Mencari Data Akseptor Memasukkan Data Kunjungan Ulang Memasukkan Data Anamnese Login <<depends on>> Mengelola data akseptor KB
Gambar 6.Use case diagram
Use case pada gambar 6., menggambarkan proses – proses yang dapat dilakukan oleh aktor bidan. Dari gambar 6., terlihat bahwa sebelum mengelola data akseptor KB, aktor harus melakukan proses login terlebih dahulu.
3. RingkasanUse Case
Berikut adalah ringkasan use case diagram yang telah digambarkan pada Gambar 6 :
No. Use Case Deskripsi
1. Login Proses validasi hak askses. Proses wajib
untuk dapat masuk ke sistem utama. 2. Mengelola Data
Akseptor KB
Merupakan proses generalisasi yang meliputi lima buah proses pengelolaan data akseptor yaitu memasukkan data akseptor, menyunting data akseptor, memasukkan data diagnosa, mencetak laporan, dan mencari data akseptor. 3. Memasukkan Data
Akseptor KB
Merupakan proses memasukkan data akseptor KB ke dalamdatabase.
4. Memasukkan Data Anamnese
Merupakan proses memasukkan data anamnese untuk akseptor KB tertentu.
Use case ini membutuhkan use case
memasukkan data akseptor KB 5. Menyunting Data
Akseptor KB
Merupakan proses mengubah data akseptor KB yang ada dalamdatabase.
6. Memasukkan Data Kunjungan Ulang
Merupakan proses memasukkan data diagnosa akseptor KB tertentu ke dalam database.
7. Mencari Data Akseptor KB
Mencari data Akseptor KB berdasarkan nama akseptor.
8. Mencetak Laporan Mencetak laporan yang dibutuhkan .
Tabel 9.Ringkasan Use Case
D. Use Case Narative
Berikut adalah use case narative untuk masing-masing use case yang telah digambarkan pada Gambar 6.:
1. Use case narative login
USE CASE NAME: Log In USE CASE TYPE
USE CASE ID: APKB-001
PRIORITY: High
Business
Requirements : PRIMARY SYSTEM
ACTOR: Bidan
DESCRIPTION: Bagian ini mendeskripsikan proses masuk ke aplikasi pengolahan data akseptor KB
PRE-CONDITION: Pengguna telah memilikiusername danpassword TRIGGER: Use case ini digunakan ketika pengguna akan masuk
ke dalam menu utama.
Actor Action System Response Step 1:Memilih
menu Log - Login
Step 2:Sistem
menampilkanform login
Step 3: Pengguna memasukkan
username dan
password.
Step 4:Sistem melakukan validasipassword.
TYPICAL COURSE OF EVENTS:
Step 5:Validasi berhasil, sistem menampilkan menu utama.
ALTERNATE COURSES:
Alternate Step 5: validasi gagal,user diminta memasukkanusername danpassword kembali.
CONCLUSION: Pengguna memasukkanusername danpassword
dengan benar, sehingga dapat masuk ke dalam sistem utama
BUSINESS RULES Pengguna harus memasukkan kata kunci dengan benar.
IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
• Harus dapat diakses setiap saat
2. Use case narative memasukkan data akseptor KB
USE CASE NAME: Memasukkan Data Akseptor KB
USE CASE TYPE
USE CASE ID: APKB-002
PRIORITY: High Business Requirements : PRIMARY SYSTEM ACTOR: Bidan
DESCRIPTION: Bagian ini mendeskripsikan proses penambahan data akseptor
PRE-CONDITION: Pengguna telah berhasil masuk ke dalam aplikasi pengolahan data akseptor KB
TRIGGER: Use case ini digunakan ketika pengguna hendak menambahkan data akseptor KB yang baru.
Actor Action System Response TYPICAL COURSE
OF EVENTS:
Step 1: Pengguna memilih menu Pasien
– Data Pasein
Step3:Sistem
menampilkan halaman data pasien
Step 2:Pengguna melakukan klik pada tombol tambah pasien
Step 4:Sistem
menampilkan form tambah pasien baru
Step 5: Pengguna memasukkan data melaluifield-field
yang tersedia
Step 6:Pengguna melakukan klik pada tombol simpan
Step 7:Sistem melakukan proses penyimpanan data ke dalamdatabase
berhasil. Sistem
menampilkan data yang berhasil disimpan
ALTERNATE COURSES:
Alternate Step 5: Pengguna batal melakukan penambahan data pasien baru.
Alternate Step 6: Pengguna melakukan klik pada tombol batal
Alternate Step 8: Penyimpanan gagal Sistem menampilkan pesan data gagal disimpan.
CONCLUSION: Pengguna dapat melakukan penambahan data pasien baru.
POST-CONDITION: Data pasien baru berhasil disimpan ke dalam database.
BUSINESS RULES Pengguna harus dapat login / masuk ke menu utama
IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
• Dapat diakses oleh pengguna yang berhasil masuk ke menu utama.
3. Use case narative memasukkan data anamnese
USE CASE NAME: Memasukkan data anamnese USE CASE TYPE
USE CASE ID: APKB-003
PRIORITY: High Business Requirements : PRIMARY SYSTEM ACTOR: Bidan
DESCRIPTION: Bagian ini mendeskripsikan proses penambahan data anamnese pada pasien tertentu.
PRE-CONDITION: Pengguna berada di halaman data pasien.
Telah memiliki data akseptor yang tersimpan dalam database.
TRIGGER: Use case ini digunakan ketika pengguna hendak menambahkan data anamnese pada pasien tertentu.
Actor Action System Response Step 1:Sistem
menampilkan halaman data pasien (data yang berhasil disimpan)
TYPICAL COURSE OF EVENTS:
Step 2: Pengguna melakukan klik pada tombol tambah status
Step 3:Sistem
menampilkanform tambah status baru
Step 4 :Pengguna memasukkan data melaluifield-field
yang tersedia.
Step 5 :Pengguna melakukan klik pada tombol simpan
Step 6 :Sistem melakukan proses penyimpanan data ke dalamdatabase.
Step 7:Penyimpanan berhasil, Sistem
menampilkan data pasien.
ALTERNATE COURSES:
Alternate Step 4: Pengguna batal melakukan penambahan status pada akseptor tertentu.
Alternate Step 5: Pengguna melakukan klik pada tombol batal.
menampilkan pesan data gagal disimpan.
CONCLUSION: Pengguna dapat melakukan penambahan status pada pasien tertentu.
POST-CONDITION: Status pasien tertentu berhasil disimpan ke dalam database.
BUSINESS RULES Data pasien yang akan ditambah statusnya harus sudah tersimpan dalam database.
IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
• Dapat diakses oleh pengguna yang berhasil masuk ke menu utama.
4. Use case narative menyunting data akseptor KB
USE CASE NAME: Mengubah data akseptor KB USE CASE TYPE
USE CASE ID: APKB-004
PRIORITY: High Business Requirements : PRIMARY SYSTEM ACTOR: Bidan
DESCRIPTION: Bagian ini mendeskripsikan proses penyuntingan data akseptor KB
PRE-CONDITION: Telah memiliki data akseptor yang tersimpan dalam
TRIGGER: Use case ini digunakan ketika pengguna hendak menyunting data akseptor KB tertentu
Actor Action System Response Step 1: Menampilkan halaman detail pasien
Step 2: Pengguna memilih data yang akan diubah
Step 3:Pengguna melakukan klik pada tombol sunting data.
Step 4:Sistem menampilkan halaman penyuntingan data. Step 5: Pengguna melakukan penyuntingan data Step 6: Pengguna melakukan klik pada tombol perbarui data
TYPICAL COURSE OF EVENTS:
update data akseptor KB tertentu yang tersimpan dalamdatabase
ALTERNATE COURSES:
Alternate Step 5: Pengguna batal melakukan penyuntingan.
Alternate Step 6: Pengguna melakukan klik pada tombol batal
Alternate Step 7: Kembali kehalaman detail pasien, tanpa melakukanupdate database.
CONCLUSION: Pengguna dapat melakukan penyuntingan data, dan data dalamdatabase dapat ter-update.
POST-CONDITION: Data dalamdatabase berhasil diperbarui.
BUSINESS RULES Pengguna harus dapat mengakses data dalam
database.
IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
• Dapat diakses oleh pengguna yang berhasil masuk ke menu utama.
5. Use case narative memasukkan data kunjungan ulang
USE CASE NAME: Memasukkan data kunjungan ulang
USE CASE ID: APKB-005 PRIORITY: High Business Requirements : PRIMARY SYSTEM ACTOR: Bidan
DESCRIPTION: Bagian ini mendeskripsikan proses memasukkan data kunjungan ulang akseptor KB
PRE-CONDITION: Telah memiliki data akseptor yang tersimpan dalam
database
TRIGGER: Use case ini digunakan ketika pengguna hendak memasukkan data kunjungan ulang akseptor KB tertentu
Actor Action System Response Step 1: Pengguna
memilih menu Pasien – Kunjungan Ulang. Step 2:Sistem menampilkan halaman kunjungan ulang TYPICAL COURSE OF EVENTS: Step 3:Pengguna memilih akseptor tertentu
Step 4:Sistem menampilkanform
kunjungan ulang pasien tertentu
Step 5:Pengguna mengisi data hasil pemeriksaan akseptor
Step 6:Pengguna melakukan klik pada tombol simpan
Step 7:Sistem melakukan proses penyimpanan data ke dalamdatabase
ALTERNATE COURSES:
Alternate Step 5: Pengguna batal melakukan penambahan data kunjungan ulang.
Alternate Step 6: Pengguna melakukan klik pada tombol batal
Alternate Step 7: Kembali ke tampilan awal halaman kunjungan ulang.
CONCLUSION: Pengguna dapat melakukan penambahan data kunjungan ulang pada setiap akseptor yang
melakukan kunjungan ulang
POST-CONDITION: Data Kunjungan ulang akseptor tertentu berhasil disimpan dalam database
BUSINESS RULES Pengguna harus dapat login/masuk ke menu utama
IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
• Dapat diakses oleh pengguna yang berhasil masuk ke menu utama
6. Use case narative mencari data akseptor KB
USE CASE NAME: Mencari data akseptor KB USE CASE TYPE
USE CASE ID: APKB-006
PRIORITY: High Business Requirements : PRIMARY BUSINESS ACTOR: PRIMARY SYSTEM ACTOR: Bidan
DESCRIPTION: Bagian ini mendeskripsikan proses mencari data akseptor KB
PRE-CONDITION: Pengguna telah masuk ke dalam menu utama
TRIGGER: Use case ini digunakan ketika pengguna hendak mencari data akseptor KB tertentu
Step 1: Pengguna memilih menu Pasien – Data Pasien
Step 2:Sistem
menampilkan halaman data pasien
Step 3: Pengguna memasukkan kata kunci pencarian, berupa nama
Step 4:Sistem melakukan pencarian data ke dalam database, berdasarkan kata kunci yang dimasukkan oleh pengguna
OF EVENTS:
Step 5:Data ditemukan. Sistem menampilkan hasil pencarian dalam tabel yang tersedia
ALTERNATE COURSES:
Alternate Step 5: Data tidak ditemukan. Sistem menampilkan informasi bahwa data yang dicari tidak
ditemukan di dalam database.
CONCLUSION: Pengguna menemukan data akseptor yang dicari
POST-CONDITION: Data akseptor yang dicari dapat ditemukan dan ditampilkan.
BUSINESS RULES Kata kunci pencarian berupa nama akseptor KB
IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
• Dapat diakses oleh pengguna yang berhasil masuk ke menu utama.
7. Use case narative mencetak laporan
USE CASE NAME: Mencetak laporan USE CASE TYPE
USE CASE ID: APKB-007
PRIORITY: High Business Requirements : PRIMARY SYSTEM ACTOR: Bidan
DESCRIPTION: Bagian ini mendeskripsikan proses mencetak laporan yang dibutuhkan pengguna
PRE-CONDITION: Pengguna telah berhasil masuk ke dalam menu utama
TRIGGER: Use case ini digunakan ketika pengguna hendak mencetak laporan yang dibutuhkan
Actor Action System Response Step 1: Pengguna memilih menu Laporan Step 2:Sistem menampilkan halaman mencetak laporan Step 3 : Pengguna memasukkan kata kunci berupa bulan dan tahun pelaporan
Step 4:Sistem mencari data sesuai dengan kata kunci yang dimasukkan
Step 5:Sistem menemukan data, dan menampilkannya.
Step 6 :Pengguna melakukan klik pada tombol cetak
TYPICAL COURSE OF EVENTS:
Step 7:Sistem
laporan sebelum dicetak
Step 8:Pengguna melakukan klik pada tombol dengan ikon printer
Step 9:Sistem
memerintahkan printer untuk mencetak laporan
CONCLUSION: Pengguna memperoleh laporan sesuai kebutuhan
POST-CONDITION: Laporan yang dibutuhkan berhasil dicetak
BUSINESS RULES Pengguna memasukkan kata kunci dengan tepat.
IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS
• Dapat diakses oleh pengguna yang berhasil masuk ke menu utama
• Koneksi printer sudah dipastikan dalam kondisi baik.
E. Activity Diagram
Berikut adalah activity diagram untuk masing-masing use case yang telah digambarkan pada Gambar 6.:
1. Activity diagram login
2. Activity diagram memasukkan data akseptor KB
Sistem Pengguna (Bidan)
memilih menu Pasien - Data Pasien
menampilkan halaman data pasien klik tombol tambah pasien
menampilkan form tambah pasien memasukkan data pasien baru
klik tombol batal klik tombol simpan [tambah data] [batal]
menyimpan data ke dalam database [penyimpanan gagal] [penyimpanan berhasil]
menampilkan data yang baru ditambahkan menampilkan pesan data gagal disimpan
3. Activity diagram memasukkan dataanamnese