DOKUMENTASI ANALISIS DAN PERANCANGAN PERANGKAT LUNAK

(PENDEKATAN TERSTRUKTUR)

Pemeriksaan Pasien

untuk:

Dokter

Dipersiapkan oleh:

Group 58

Syafaatul Udhma Nugraha

Mohamad Wahyudi Putra

Serevina Naibaho

Muhammad Hamdan

Program Studi Teknik IndustriFakultas Rekayasa Industri

Telkom University

2015

DAFTAR PERUBAHANRevisi Deskripsi

A

B

C

D

E

F

G

INDEXTGL

- A B C D E F G

Ditulis oleh

Diperiksa oleh

Disetujui oleh

Daftar Halaman Perubahan

Halaman Revisi Halaman Revisi

Daftar Isi1. Pendahuluan..........................................................................................................................................................5

1.1 Tujuan Penulisan Dokumen......................................................................................................................51.2 Lingkup Masalah.......................................................................................................................................51.3 Definisi, Istilah dan Singkatan.................................................................................................................51.4 Aturan Penomoran....................................................................................................................................51.5 Referensi...................................................................................................................................................51.6 Deskripsi umum Dokumen (Ikhtisar)........................................................................................................5

2 Deskripsi Umum Perangkat Lunak...................................................................................................................52.1 Deskripsi Umum Sistem...........................................................................................................................52.2 Fungsi Produk...........................................................................................................................................52.3 Karakteristik Pengguna.............................................................................................................................52.4 Batasan......................................................................................................................................................52.5 Lingkungan Operasi..................................................................................................................................6

3 Deskripsi Umum Kebutuhan.............................................................................................................................63.1 Kebutuhan antarmuka eksternal................................................................................................................6

3.1.1 Antarmuka pemakai..........................................................................................................................63.1.2 Antarmuka perangkat keras...............................................................................................................63.1.3 Antarmuka perangkat lunak..............................................................................................................63.1.4 Antarmuka komunikasi.....................................................................................................................6

3.2 Deskripsi Fungsional.................................................................................................................................63.2.1 Context Diagram...............................................................................................................................6

3.2.1.1 DFD Level 1..................................................................................................................................63.3 Data Requirement.....................................................................................................................................7

3.3.1 E-R diagram......................................................................................................................................73.4 Non Functional Requirement....................................................................................................................73.5 Batasan Perancangan.................................................................................................................................83.6 Kerunutan (traceability)............................................................................................................................8

3.6.1 Data Store vs E-R..............................................................................................................................83.7 Ringkasan Kebutuhan...............................................................................................................................8

3.7.1 Functional Requirement Summary...................................................................................................83.7.2 Non Functional Requirement Summary............................................................................................8

4 Deskripsi Perancangan Global..........................................................................................................................94.1 Rancangan Lingkungan Implementasi......................................................................................................94.2 Deskripsi Data...........................................................................................................................................9

4.2.1 Definisi Domain/Type.......................................................................................................................94.2.2 Conceptual Data Model.....................................................................................................................94.2.3 Physical Data Model.........................................................................................................................94.2.4 Daftar Tabel Aplikasi........................................................................................................................9

4.3 Dekomposisi Fungsional Modul.............................................................................................................105 Deskripsi Perancangan Rinci..........................................................................................................................10

5.1 Deskripsi Rinci Tabel..............................................................................................................................105.1.1 Tabel <Nama..>...............................................................................................................................105.1.2 Tabel <Nama>.................................................................................................................................11

5.2 Deskripsi Fungsional secara Rinci..........................................................................................................115.2.1 Spesifikasi Fungsi/Proses <nama fungsi 1>....................................................................................115.2.2 Spesifikasi Fungsi/Proses <nama fungsi 2>....................................................................................11

5.3 Dekomposisi Fisik Modul.......................................................................................................................115.4 Matriks Kerunutan..................................................................................................................................12

Setelah Daftar Isi Boleh ada Daftar Tabel dan Daftar Gambar

1. Pendahuluan

1.1 Tujuan Penulisan Dokumen

Tujuan dokumen ini dibuat unutk melihat bagaimana elemen-elemen dari aplikasi ini terhubung atau berinteraksi

dengan pihak penggun, atau bisa disebut interaksi antara sistem dan user :

1. Sistem menyediakan dan menentukan apa yang harus diinputkan oleh user, yang harapannya dapat

memudahkan dalam merekap rekam medis pasien oleh asisten dokter

2. User terdiri dari 3 pihak, yaitu pasien, asisten dokter dan dokter. Pasien merupakan sumber data yang

akan diinputkan oleh asisten dokter, lalu sistem akan merekam data pasien yang nantinya akan

digunakan oleh keperluan dokter untuk pemeriksaan

1.2 Lingkup Masalah

Aplikasi Pemeriksaan Pasein adalah sebuah sistem yang dirancang untuk memudahkan asisten dalam merekap

rekam medis pasien, yang selanjutnya data akan digunakan oleh dokter untuk melakukan pemeriksaan. Alur

proses pada sistem ini, pasien – asisten dokter – sistem – dokter.

1.3 Definisi, Istilah dan Singkatan

Asisten dokter / Administrasi

karyawan yang bekerja berdampingan bersama dokter

User

merupakan pihak klinik

Softwere

perangkat lunak yang dalam hal ini suatu program

1.4 Aturan Penomoran

Aturan penomoran pada penulisan ini menggunakan angka pada setiap bab, sub bab dan sub-sub bab lainnya.

Contoh :

Bab 1 Pendahuluan

1.1. Latar Belakang

1.1.2 Data

1.5 Referensi

Referensi yang digunakan untuk menyusun tulisan ini diantaranya adalah :

File bentuk PDF, yang merupakan pedomana untuk menggunakan atau mengoprasikan softwere atau

aplikasi pemeriksaan pasien

Buku pegangan matakuliah APSI, Introdusction to system analysis & design method 7th oleh jeffrey L.

Whitten dan Lonnie Bentley.

1.6 Deskripsi umum Dokumen (Ikhtisar)

Bab I. Pendahuluan

Pada bab ini berisi uraian mengenai tujuan penulisan dokumen, lingkup masalah, definisi, istilah dan singkatan,

aturan penomoran, referensi, dan deskripsi umum dokumen (ikhtisar)

Bab II. Deskripsi Umum Perangkat Lunak

Pada bab ini berisi mengenai deskripsi umum sistem, fungsi produk, karakteristik pengguna, batasan, dan

lingkupan operasi

Bab III Deskripsi Umum Kebutuhan

Pada bab ini berisi kebutuhan antarmuka eksternal, deskripsi fungsional, data requirement, non functional

requirement, batasan perancangan, kerunutan (traceability), dan ringkasan kebutuhan

Bab IV Deskripsi Perancangan Global

Pada bab ini berisi mengenai rancangan lingkungan implementasi, deskripsi data dan dekomposisi fungsional

modul

Bab V Deskripai Perancangan Rinci

Pada bab ini berisi tentang deskripsi rinci tabel, deskripsi fungsional secara rinci, dekomposisi fisik modul dan

matriks kerunutan

2 Deskripsi Umum Perangkat Lunak

2.1 Deskripsi Umum Sistem

Form Biodata Pasien

Keluhan penyakit

No.Antri Pasien

Kartu ID Pasien

Update Data Pasien

Data Obat Pasien

Diagnosis Pemeriksaan

Keluahan Pasien

Resep Obat Pasien

Kartu Status Pasien

1

Aplikasi Pemeriksaan Pasien

Dokter

Administrasi

Pasien

Gambar diatas merupakan deskripsi umum dasi sistem aplikasi Pemeriksaan Pasien yang akan digunakan.

Terdapat 3 Entitas yang berhubungann dengan aplikasi Pemeriksaan Pasien, yaitu Dokter, Adimistrasi, dan

Pasien. Cara Kerja dimulai dari Pasien yang menginputkan biodata diri dan juga keluhan penyakit yang

dirasakan oleh bagian administrasi yang akan disimpan pada database aplikasi Pemeriksaan Pasien, yang

kemudian dari data tersebut pasien akan mendapatkan Kartu ID pasien dan juga nomer antrian untuk dilakukan

pemeriksaan. Setelah itu ketika nomer antrian tiba, pasien masuk ke ruang pemeriksaan yang kemudian

dilakukan pemeriksaan oleh dokter berdasarkan keluhan yang dirasakan pasien. Kemudian dokter memberikan

diagnosis hasil pemeriksaan terhadap pasien. Kemudian dokter menginputksan resep obat untuk pasien dan

kemudian diproses oleh admistrasi untuk dilanjutkan pencetakan kartu status pasien setelah melakuakan

pemeriksaan. Pasien yang sudah dilakuakan pemeriksaan menuju kembali ke admistrasi untuk melakuakan

pengambilan kartu status pasien dan pasien dapat mendapati penyakit yang dialami oleh pasien.

2.2 Fungsi Produk

Menu pada aplikasi ini terdiri atas Menu Utama dan Sub Menu. Terdapat 4 Menu Utama yang terdiri atas:

a. Menu Data Diri Pasien

Pada menu data diri pasien terdapat 8 sub menu yaitu nama, alamat, umur, kelamin, agama, status,

nama orang tua, no. telfon yang akan disi dengan biodata diri dari pasien yang yang melakukan

pemeriksaan.

b. Menu Status Pasien

Pada menu status pasien terdapat 6 sub menu yaitu anamnesa, pemeriksaan, Lab-USG, Photo, Diagnosa

dan resep yang akan diisi oleh dokter ketika telah melakukan pemeriksaan terhadap pasien

c. Menu Pencarian

Pada menu pencarian terdapat 5 sub menu yaitu nama, alamat, umur, nama orang tua dan telfon. Menu

ini digunakan untuk pasien yang sudah pernah melakukan pemeriksaan sebelumnya yang sudah pernah

mengisi biodata pasien. Dapat dilakukan pencarian data diri pasien oleh administrasi dengan

memasukan nama atau alamat atau umur atau nama orang tua tau no mer telefon dari pasien.

d. Menu Control Panel

Pada menu control panel terapat 8 sub menu yaitu show, hide, edit profile, show toolbar, cetak kartu

status, laporan resep, lap daftar pasien dan keluar. Menu ini adalah bagian untuk melakukan pencetakan

hasil pemeriksaan dan kartu status pasien seta juga untuk pengeditan data pasien yang dilakukan oleh

bagian administrasi.

2.3 Karakteristik Pengguna

Kategori Pengguna Tugas Hak Akses ke aplikasi

Administrasi Input data diri Pasien Admin Login

Update Resep Pasien Edit Database Pasien

Update Status Data Pasien Pencetakan Keseluruhan data Pasien

User/Pasien Mencari hal Terkait Dirinya Adm Search ID Pasien

Pencetakan Kartu ID Pasien

Pencetakan Kartu Status Pasien

2.4 Batasan

Batasan yang terdapat pada sistem ini adalah spesifikasi minimal :

1. Komputer P2-500Mhz ,identik atau lebih.

2. Memory RAM 128Mb atau lebih

3. Layar dengan resolusi 1024x768 atau lebih

4. Ms windows 98, Me, XP, atau Vista

5. Ms office terutama ms access tahun 97, 2000, 2002(XP), 2003, 2007(belum di tes)

6. Penggunan printer

2.5 Lingkungan Operasi

Aplikasi Client server ini akan berfungsi dengan spesifikasi :

Server : Administrasi

Client : PAsien

OS : Windows

DBMS :

3 Deskripsi Umum Kebutuhan

3.1 Kebutuhan antarmuka eksternal

Aplikasi ini hanya dijalankan oleh orang/bagian yang berkepentingan dan memiliki wewenang untuk melakukan

penggunakan aplikasi ini seperi login dan update data yang hanya dapat dilakukan oleh bagian administrasi dan

dokter

3.1.1 Antarmuka pemakai

Aplikasi ini hanya berjalan pada perangkat komputer atau PC yang memiliki atau memakai operating system

windows, maka dari itu penghubung antara aplikasi dengan pemakai yaitu seperangkat komputer lengkap dengan

accessories (keyboard, ` mouse)

3.1.2 Antarmuka perangkat keras

Hanya diisi jika perlu perangkat keras khusus, misalnya CARD XXX, CABLE XYZ

3.1.3 Antarmuka perangkat lunak

Hanya diisi jika PL memakai interface (berupa PL), misalnya API Windows.

3.1.4 Antarmuka komunikasi

Hanya diisi jika PL beroperasi di jaringan dan membutuhkan alat komunikasi khusus, misalnya RS232.

3.2 Deskripsi Fungsional

3.2.1 Context Diagram

Input Data

ID PasienNomor Urut

Data Pasien

Input Jadwal Pasien

Input Jadwal Kosong

Daftar Pasien

PasienAsisten Dokter

Dokter

1

Sistem Pemeriksaan Pasien

Terdapat 3 entitas yang berinteraksi dengan aplikasi yang pertama adalah pasien yang hak penggunaannya

adalah pengisi biodata diri yang dilakukan oleh administrasi kemudian pasien mendapatkan ID pasien beserta

kartu pasien dan nomer urut antrian pemeriksaan. Yang kedua adalah dokter yang bertugas melakukan

pemeriksaan dan menginputkan jadwal pemeriksaan. Yang ketiga adalah asisten dokter/adminsitrasi yang

bertugas untuk menginputkan biodata diri pasien dan update data pasien serta menginutkan jadwal pasien.

3.2.1.1 DFD Level 1

Input Data Pasien

Data Pasien

Data Pasien

Input Jadwal PasienJadwal Pasien

Input Jadwal Kosong

Jadwal Kosong

Jadwal Dokter Jadwal Pasien

Asisten Dokter

Pasien

Dokter

1

Kelola Jadwal Pasien

2

Kelola Jadwal Kosong

3

Kelola Data Pasien

1 Data Jadwal Pasien

2 Data Jadwal Kosong

3 Data Pasien

3.2.1.2 DFD Level 2

Data Pasien

Input Data Pasien Mendaftarkan Data Pasien

Data PasienKartu Pasien

Pasien

1

Proses Pasien Baru

2

Pencetakan ID

1 Data Pasien

Data Jadwal Pemeriksaan

Data Pasien Data Jadwal KosongAsisten 1

Jadwal Pasien1 Jadwal Kosong

Data Pemeriksaan

Input Jadwal Kosong

Jadwal pasien

Jadwal Kosong Dokter

Input Jadwal Kosong Untuk Pasien

Dokter

1

Input Jadwal Kosong

2

Input Jadwal Pasien

1 Jadwal Kosong

3.3 Data Requirement

Data yang dibutuhkan dalam sistem aplikasi Pemeriksaan Pasien adalah

Dokter : NIP, Jadwal Pemeriksaan, Hasil Pemeriksaan

Asisten/Administrasi : NIP, Data Nama Obat, Daftar harga Obat, Biaya Pemeriksaan

Pasien : Biodata Diri, Keluhan Penyakit

3.3.1 E-R diagram

Gambar E-R diagram yang benar-benar konseptual, dengan VISIO. Minimal ada nama Entity, Relasi dan Key

(Skema relasi). Sudah dijelaskan apa bedanya E-R konseptual dengan Conceptual Data Model pada Case

Tools, karena E-R diagram ini tidak mungkin digambar dengan Case Tools. Keterbatasan CASE Tools biasanya

adalah:

- tidak mungkin mempunyai relasi dengan atribut non-key

- tidak mungkin mempunyai relasi bukan biner (terner, dan lebih tinggi)

sehingga akibatnya, relasi dijadikan “entity”. Kenapa E-R konseptual disarankan untuk digambar, adalah

karena E-R ini sebenarnya lebih mencerminkan abstraksi perancang

3.4 Non Functional Requirement

Uraikan dengan ringkas kebutuhan non fungsional dalam tabel sebagai berikut. Isilah Kolom Requirement

dengan kalimat yang jelas dan kelak dapat ditest untuk dipenuhi. SRS-NO adalah nomor requirement yang

harus ditelusuri pada saat test. Tuliskan N/A bila Not Applicable..

SRS-Id Parameter Requirement

SRS-NF-001 Availability

Aplikasi beroperasi selama 24 jam,

namun pemakaian hanya dapat

digunakan sesuai jam operasional. Jam

praktik dokter yang sudah ditentukan.

SRS-NF-002 ReliabilityPersentase aplikasi tidak boleh gagal

adalah sebesar 99%.

SRS-NF-003 ErgonomyAplikasi nyaman untuk digunakan oleh

user (Administrasi dan Dokter)

SRS-NF-004 Portability Aplikasi digunakan Komputer atau PC

SRS-NF-005 Memory Aplikasi memiliki kapasitas 15 MB

SRS-NF-006 Response timeAplikasi mampu menampilkan hasil

dalam 1 detik

SRS-NF-007 Safety Single Sign On

SRS-NF-008 Security

Aplikasi hanya dapat diakses oleh bagian

administrasi dan dokter yang bertugas

pada waktu operasional dan ditempat

praktik

Others 1: Bahasa

komunikasi

Misalnya : semua tanya jawab harus dalam

bahasa Indonesia

Setiap layar harus mengandung logo PT Pos

Indonesia

Catatan :

Availability : ketersediaan aplikasi, misalnya harus terus menerus beroperasi 7 hari perminggu, 24 jam per

haritanpa gagal

Reliability : keandalan, misalnya tidak pernah boleh gagal(atau kegagalan yang ditolerir adalah …%) sehingga

harus dipikirkan fault tolerant architecture. Biasanya hanya perlu untuk Critical Application yang jika gagal

akan berakibat fatal.

Ergonomy : kenyamanan pakai bagi pengguna

Portability : kemudahan untuk dibawa dan dioperasikan ke mesin/sistem operasi/platform yang lain

Memory : jika perhitungan kapasitas memori internal kritis (misalnya untuk SW yang harus dijadikan CHIPS

dan ukurannya harus kecil

Response time : Batasan waktu yang harus dipenuhi. Sangat penting untuk aplikasi Real Time. Contoh:

“Aaplikasi harus mampu menampilkan hasil dalam 4 detik”, atau “ATM harus menarik kembali kartu yang

tidak diambil dalam waktu 3 menit”

Safety: yang menyangkut keselamatan manusia, misalnya untuk SW yang dipakai pada sistem kontrol di pabrik

Security : aspek keamanan yang harus dipenuhi.

3.5 Batasan Perancangan

Batasan perancangan pada software ini adalah hanya dapat digunakan untuk

pemeriksaan dokter umum dan belum sampai khusus untuk dokter spesialis

3.6 Kerunutan (traceability)

Diisi dengan tabel yang berisi traceability dari hasil analisis. Gunanya untuk menilai apakah hasil analisis

“runut” dan lojik. Untuik sementara, baru didefinisikan Data-store versus E-R.

3.6.1 Data Store vs E-R

Mapping data store pada DFD dengan Entity - Relasi

Data Store Entity Relasi

3.7 Ringkasan Kebutuhan

Bab ini berisi ringkasan semua “Requirement item”. Requirement item ini mencerminkan semua hal yang harus

dipenuhi, dan nantinya akan menjadi arahan untuk tahapan testing, karena pada dasarnya, semua requirement

harus dapat ditest supaya dapat dibuktikan dipenuhi. Dibagi menjadi dua bagian: functional dan non functional

3.7.1 Functional Requirement Summary

SRS-Id Description

3.7.2 Non Functional Requirement Summary

SRS-Id Description

4 Deskripsi Perancangan Global

4.1 Rancangan Lingkungan Implementasi

Sebutkan Operating system, DBMS, development tools, filing system, bahasa pemrograman yang dipakai

4.2 Deskripsi Data

Berisi deskripsi tabel-tabel basis data jika aplikasi berbasis data. Awali dengan daftar tabel basisdata dan

deskripsi isinya. Untuk setiap tabel, harus mengandung Nama tabel, jenisnya, Volume, laju, primary key,

constraint integrity dengan tabel lain( jika ada). Volume dan laju harus mimimal mengandung angka kira-kira.

Boleh berasal dari “dumb” dari database yang digunakan.

4.2.1 Definisi Domain/Type

Sebutkan nama domain (type terdefinisi) yang anda rancang pada aplikasi ini dengan mengisi tabel sebagai

berikut

Domain name Power Designer Type (mis)

Rupiah NUM …

4.2.2 Conceptual Data Model

Gambar ini diambil dari Case Tools. . Hasilnya diprint di bagian ini

4.2.3 Physical Data Model

Jika ada, Gambar ini adalah hasil generate diambil dari Case Tools. Gunanya supaya nantinya langsung

diterjemahkan menjadi tabel atau bahkan mungkin dipakai untuk membangkitkan tabel secara otomatis.

4.2.4 Daftar Tabel Aplikasi

.Awali dengan daftar tabel basisdata, primary key dan deskripsi isinya.

Nama Tabel Primary key Data Store E/R Deskripsi isi

Untuk setiap tabel, buatlah deskripsi rincinya pada Sub-bab Deskripsi Rinci Tabel

4.3 Dekomposisi Fungsional Modul

Berisi dekomposisi “lojik” dari modul. Minimal berisi tabulasi dengan kolom: Modul, Proses, Keterangan.

Kolom keterangan hanya diisi jika proses tidak tergambarkan dalam DFD. Misalnya untuk proses-proses yang

mewakili suatu library umum

Tabel. XXX. Input-Proses-Output

No. Fungsi diturunkan dari semua hal yang harus diprogram :

- Bubble DFD yang tidak didekomposisi lagi.

- Proses-proses yang “membungkus” proses lain (misalnya menjadi Menu)

Setelah IPO ini, setiap fungsi akan dibuat detailnya. Pada bagian berikutnya

Konvensi : setiap bubble harus menjadi fungsi saja. Jika “menghilang” dan tidak akan diprogram, maka akan

ditulis di bagian keterangan (misalnya Menu yang akan diprogram dengan Editor VB dan tidak lagi ditulis

kodenya, maka pada keterangan akan ditulis :”Ditangani oleh VB”

Disarankan agar penomoran fungsi dibuat hirarkhis, sehingga jika dijadikan menu akan sekaligus merupakan

Function Tree

No.Fungsi Fungsi/Proses Tabel/Data

Input

Tabel /Data

Output

Keterangan

Untuk setiap nomor fungsi, buatlah spesifikasi rincinya pada Deskripsi rancangan Rinci

5 Deskripsi Perancangan Rinci

5.1 Deskripsi Rinci Tabel

Setiap tabel pada rancangan global, dirinci satu per satu

5.1.1 Tabel <Nama..>

Identifikasi/Nama : ………..

Deskripsi Isi : ……..

Primary Key : ………….

Id Field Deskripsi Tipe & length Boleh

NULL

Default Keterangan

Id_master CHAR(8) NO

Id_ref Refer ke t_ref

Catatan : kolom “Boleh NULL” berisi “NO” artinya tidak boleh kosong, berisi “YES” artinya boleh NULL

5.1.2 Tabel <Nama>

Buat seperti di atas

5.2 Deskripsi Fungsional secara Rinci

Setiap Fungsi pada rancangan global, dirinci satu per satu

5.2.1 Spesifikasi Fungsi/Proses <nama fungsi 1>

Identifikasi/Nama : ……..

Deskripsi Isi : ……..

Jenis : Form Entry columnar/Tabular/Master-Detail

Report Columnar/tabular/Master-Detail

Form berisi dialog/button saja

Proses tanpa layar

Tabel input :

Tabel output :

Query : (diisi jika query cukup rumit)

Layar Utama :

Gambarkan layar dan percabangan ke layar lain function key/pilihan yang dilakukan)

Jika layar mengandung filed dan label, gambarkanlah pada posisi nya, supaya siap

dikoding. Jika ada zoning/frame, gambarkan pula an jelaskan pada spesifikasi Objek pada

layar

Algoritma : (diisi jika algoritma cukup kompleks)

Layout Report : (diisi jika fungsi menghasilkan report)

5.2.2 Spesifikasi Fungsi/Proses <nama fungsi 2>

Untuk setiap fungsi, buat detailnya seperti di atas

5.3 Dekomposisi Fisik Modul

Berisi dekomposisi “fisik” dari modul. Minimal berisi tabulasi dengan kolom: Sub Aplikasi, Modul, Nama File,

Input, Output. Sub Aplikasi biasanya dibuat per pengguna. Dibuat per modul

Berisi struktur direktori dan pengumpulan fungsi menjadi file. Minimal berisi tabulasi dengan kolom: Modul,

Proses, Keterangan. Kolom keterangan hanya diisi jika proses tidak tergambarkan dalam DFD. Misalnya untuk

proses-proses yang mewakili suatu library umum

Nama Direktori Nama File Nama Modul Nama Fungsi Keterangan

5.4 Matriks Kerunutan

Pada bagian ini, diisi dengan tabel, yang memungkinkan pembaca untuk menelusuri keterkaitan perancangan

terhadap spesifikasi kebutuhan.

OK

Objek

Diisi dengan tabel yang berisi traceability dari SRS dengan nomor CSU

SRS-Id No. Fungsi Keterangan

LAMPIRAN