DESAIN APLIKASI BANTU PENGIRIMAN BEBAN PDP (POS DALAM PERJALANAN) PELAYANAN KESEHATAN ASKES KOMERSIAL DI PT. ASKES REGIONAL VII JAWA TIMUR

Prosiding Seminar Nasional Manajemen Teknologi VI Program Studi MMT-ITS, Surabaya 4 Agustus 2007

DESAIN APLIKASI BANTU PENGIRIMAN BEBAN PDP (POS DALAM PERJALANAN) PELAYANAN KESEHATAN ASKES KOMERSIAL DI PT. ASKES REGIONAL VII JAWA TIMUR Gunawan Budi*, Aries Tjahyanto** *Bidang Keahlian Manajemen Teknologi Informasi Program Studi Magister Manajemen Teknologi - ITS Email : [email protected] ** Fakultas Teknologi Industri - Institut Teknologi Sepuluh Nopember Kampus ITS, Jl.Raya ITS – Sukolilo, Surabaya 60111 Email: [email protected].

ABSTRAK Jaringan pelayanan kesehatan yang tersebar hampir di seluruh kota di Indonesia memungkinkan peserta dari suatu Badan Usahan (BU) yang menjalin Perjanjian Kerja Sama (PKS) dengan PT. Askes mendapatkan pelayanan kesehatan di luar Kantor Cabang yang melakukan penandatangan kerja sama dengan Badan Usaha tersebut. Pelayanan tersebut dapat di luar kota dalam propinsi atau luar propinsi tergantung dengan klausul kerja sama antara PT. Askes dengan Badan Usaha. Biaya pelayanan kesehatan yang timbul dari peserta BU luar tersebut diistilahkan dengan PDP (Pos Dalam Perjalanan) yang untuk sementara ditanggung oleh Kantor Cabang tempat pelayanan kesehatan. PDP tersebut harus dikirimkan ke Kantor Cabang tempat Badan Usaha melaksanakan PKS agar Kantor Cabang yang melayani pelayanan kesehatan dari Badan Usaha luar tidak mengalami kerugian. Badan Usahan merupakan sumber pendapatan asli bagi Kantor Cabang, jadi masalah dalam pengiriman beban Pos Dalam Perjalanan memerlukan perhatian khusus agar Kantor Cabang tidak mengalami kerugian dalam menjalin kerja sama dengan suatu Badan Usaha. Penelitian yang akan diusulkan berkaitan dengan desain aplikasi bantu untuk memudahkan administrasi dan transfer Pos Dalam Perjalanan sehingga proses tersebut dapat berjalan lebih efektif dan efisien dari pada dilakukan secara manual. Dalam melakukan analisis dan desain aplikasi digunakan metode visual modeling diagram dengan Unified Modelling Language (UML) yang telah dikemas dalam software Relational Rose. Evaluasi terhadap sistem aplikasi eksisting dilakukan dengan melakukan pengamatan dan wawancara di lokasi wilayah kerja Kantor Askes Regional VII Jawa Timur dan Kantor Cabang di wilyahnya yang dipilih menjadi objek pengamatan. Aplikasi bantu yang dibuat diharapkan dapat menyediakan kemudahan fasilitas dalam transfer PDP sehingga manfaat dari transfer tersebut dapat digunakan untuk perhutungan laba rugi per Badan Usaha (BU) dan analisa kasus dan biaya pelayanan kesehatan yang nantinya dapat digunakan sebagai salah satu pertimbangan dalam penentuan besarnya premi asuransi. Dengan demikian dengan adanya alat bantu tersebut dapat meningkatkan kinerja di bagian Askes Komersial PT. Regional VII Jawa Timur. Kata kunci: Pos Dalam Perjalanan (PDP), Badan Usaha (BU), Unified Modelling Language (UML), Rational Rose, Askes Komersial PENDAHULUAN PT. Askes adalah Badan Usaha Milik Negara (BUMN) yang bergerak pada bidang asuransi kesehatan. PT. Askes memiliki visi menjadi perusahaan Spesialis


Asuransi Kesehatan dan Jaminan Pemeliharaan Kesehatan dan market leader di Indonesia. Bidang-bidang pelayanan di PT. Askes dibagi menjadi tiga yaitu Askes Sosial, Askes Komersial, dan Askes Kin. Bidang Askes Komersial memiliki sifat profit oriented sedangkan untuk Askes Sosial dan Askes Kin bersifat nirlaba. Bidang Askes Komersial di masing-masilng Kantor Cabang mengadakan kegiatan pemasaran untuk mencari Badan Usahan yang bersesia mengadakan Perjanjian Kerja Sama (PKS) dengan PT. Askes dalam penyediaan jaminan pelayanan kesehatan. Sifat pelayanan kesehatan di PT. Askes yang bersifat terbukan memungkinkan peserta yang berasal dari Badan Usaha di suatu kantor cabang dapat memperoleh pelayanan kesehatan di luar kantor cabang tempat mengadakan PKS. Peserta dari Badan Usaha luar tersebut menimbulkan beban biaya pelayanan kesehatan bagi Kantor Cabang tempat PPK (Penyelenggara Pelayanan Kesehatan). Beban biaya pelayanan kesehatan ini seharusnya ditanggung oleh Kantor Cabang asal dari Badan Usahan peserta tersebut. Beban biaya pelayanan kesehatan yang untuk sementara ditanggung oleh Kantor Cabang tempat PPK yang melayani pelayanan kesehatan bagi peserta luar tersebut disebut sebagai beban PDP (Pos Dalam Perjalanan). Jenis PDP dibagi menjadi dua PDP In dan Out. PDP In adalah biaya yang diterima dari KC luar sedangkan PDP Out adalah biaya yang dikirimkan ke KC luar. Mekanisme pengiriman PDP ini juga disertai dengan TI (Transfer Informasi) yaitu dokumen yang berisi detail bukti pelayanan kesehatan yang telah diberikan sedangkan dokumen PDP berisi bukti pembukuan beban biaya pelayanan kesehatan yang telah dilakukan oleh bagian keuangan. Mekanisme pengiriman PDP dan TI yang saat ini masih berjalan manual memerlukan suatu sistem Bantu yang dapat membantu dalam proses di atas. Berdasarkan permasalahan inilah topik tesis ini diangkat. Dalam pembuatan aplikasi bantu, pendekatan yang digunakan adalah pendekatan model proses bisnis. Dengan menggunakan pendekatan model proses bisnis, akan didapatkan suatu pemahaman yang terbaik terhadap kebutuhan bisnis. Disiplin ilmu yang digunakan adalah Rekayasa Perangkat Lunak (RPL) atau dalam bahasa Inggris: Software Engineering (SE) atau Requirement Engineering (RE), sesuai IEEE Std 830-1998[1]. REQUIREMENTS ENGINEERING Dalam bagian ini dijelaskan konsep dasar yang berkaitan dengan Requirements Engineering. Penjelasan diberikan secara singkat dengan tujuan untuk memberikan pengertian, tujuan, dan manfaat dari aspek Requirements Engineering. Definisi Requirements Engineering Menurut IEEE Std 830-1998 [1], Rekayasa perangkat lunak (RPL, atau dalam bahasa Inggris: Software Engineering (SE) atau Requirement Engineering (RE)) adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat lunak termasuk pembuatan, manajemen organisasi pengembanganan software, desain sistem, implementasi, testing dan perawatan sistem. Requirement tidak hanya ditulis oleh pembangun, tapi sebelumnya justru ditulis oleh klien yang memesan software. Klien menuliskan requirement dalam bentuk yang masih abstrak tentang kebutuhannya. Kemudian requirement tersebut diserahkan kepada tim pembangun. Saat sudah ada persetujuan, pembangun kemudian menuliskan kemampuan sistem yang bisa dipahami oleh klien, inipun disebut requirement. Beberapa macam requirement menurut Sommerville [2] yaitu:

ISBN : 978-979-99735-3-5 C-8-2


a. User Requirement (Kebutuhan Pengguna) Pernyataan tentang layanan yang disediakan sistem dan tentang batasan-batasan operasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah. b. System Requirement (Kebutuhan Sistem) Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun. c. Software Design Specification (Spesifikasi Rancangan Perangkat Lunak) Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil. Ketiga jenis requirement tersebut diperlukan dalam pembangunan software karena masing-masing memberi pengertian ke pihak yang berbeda. Fungsi ketiga requirement diatas menurut Sommerville [2] dapat memberi pengertian pada beberapa pihak yang dipetakan menjadi: a. User Requirement (Kebutuhan Pengguna), yaitu Manager Klien, End User System, Staf Ahli Klien, Manager Developer dan Arsitek System b. System Requirement (Kebutuhan Sistem) yaitu End User System, Staf Ahli Klien, Tim Developer, Arsitek System c. Software Design Specification (Spesifikasi Rancangan Perangkat Lunak) yaitu Staf Ahli Klien, Tim Developer dan Arsitek System Tujuan Requirements Engineering Menurut IEEE Std 610.12 – 1990 [3], di dalam rancang-bangun sistem (system engineering atau system design engineering), suatu kebutuhan adalah suatu uraian dari apa yang perlu lakukan terhadap suatu sistem. Sistem mungkin punya dari beberapa sampai beribu-ribu kebutuhan. Suatu koleksi kebutuhan menggambarkan karakteristik atau corak yang diinginkan (atau diperlukan) sistem, tetapi secara umum tidak dikatakan bagaimana sistem perlu menerapkan kebutuhan itu. Di dalam rancang-bangun perangkat lunak (software engineering), suatu perangkat lunak kebutuhan (software requirement) adalah suatu potongan uraian dari apa yang perlu dilakukan (atau diperlukan) terhadap perangkat lunak tertentu. Suatu potongan perangkat lunak juga boleh mempunyai beberapa sampai beribu-ribu kebutuhan. Manfaat Requirements Engineering Menurut IEEE Std 1233-1998 [4], suatu perangkat lunak spesifikasi kebutuhan (software requirements specification, SRS) adalah suatu uraian yang lengkap menyangkut perilaku dari sistem yang akan dikembangkan. Sesuai IEEE Std 830 – 1998 [5], SRS biasanya berisi: i) Kebutuhan Fungsional: Suatu kebutuhan yang menetapkan suatu tindakan dimana suatu sistem harus mampu melaksanakan suatu aksi, tanpa mempertimbangkan batasan phisik; suatu kebutuhan yang menetapkan perilaku input/output dari suatu sistem. ii) Kebutuhan Non-Fungsional: Suatu kebutuhan yang menetapkan property sistem, seperti lingkungan dan batasan implementasi, capaian (performance), ketergantungan platform, kebutuhan maintainance, sifat dapat dikembangkan (extensibility), dan keandalan. Kebutuhan Non-Fungsional seringkali diklasifikasikan menjadi beberapa kategori, yaitu: a) Kebutuhan capaian

ISBN : 978-979-99735-3-5 C-8-3


(performance). Suatu kebutuhan dimana menetapkan karakteristik capaian yang dimiliki suatu sistem secara utuh atau komponen system. Misalnya: max. penggunaan CPU, max. penggunaan memory. b) Kebutuhan Interface Eksternal: Suatu kebutuhan dimana menetapkan spesifikasi perangkat keras, perangkat lunak, atau unsur-unsur database di dalam suatu sistem yang utuh atau komponen sistem yang dijembatani menghubungkan, atau menetapkan batasan pada format, pemilihan waktu atau faktor lain yang disebabkan oleh alat penghubung seperti itu. c) Batasan disain. Suatu kebutuhan dimana mempengaruhi atau membatasi perancangan suatu sistem secara utuh atau komponen system. Misalnya: kebutuhan bahasa pemrograman, kebutuhan phisik perangkat keras, standard pengembangan software, dan standard jaminan mutu perangkat lunak. d) Atribut Mutu. Suatu kebutuhan dimana menetapkan suatu derajat tingkatan dimana suatu sistem memiliki atribut yang mempengaruhi mutunya. Misalnya: ketepatan, keandalan, kebutuhan maintainance, dan portabilitas. Menurut Sommerville & Sawyer [5], SRS berisi seperangkat aktivitas untuk menemukan, menganalisa, mendokumen-tasikan, memvalidasi dan seperangkat kebutuhan pemeliharaan suatu sistem. SRS adalah dibagi menjadi dua kelompok utama aktivitas, manajemen kebutuhan (requirements management.) dan pengembangan kebutuhan (requirements development). Pengembangan kebutuhan meliputi aktivitas yang berhubungan dengan menemukan, menganalisa, mendokumentasikan dan memvalidasi kebutuhan, sedangkan manajemen kebutuhan meliputi aktivitas berhubungan dengan pemeliharaan yaitu identifikasi, traceabilitas dan perubahan manajemen kebutuhan. METODOLOGI PENELITIAN Pada bab ini dipaparkan langkah-langkah yang digunakan untuk membahas permasalahan yang diambil dalam penelitian. Dibagian ini juga dijelaskan alat dan metoda yang digunakan untuk melakukan perencanaan. Rational Unified Process (RUP) adalah salah satu metodologi dan proses Requirement Engineering. RUP adalah suatu kerangka proses low-level pengembangan software yang dikembangkan oleh Rational Software. RUP benar-benar merupakan suatu kerangka proses dan kerangka disain karena memiliki unsur-unsur suatu metodologi dan suatu proses. Menggunakan RUP, pengembangan lifecycles perangkat lunak dibagi menjadi pengembangan siklus individu. Masing-masing siklus ini dibagi menjadi tahapantahapan. Tahapan ini terdiri atas aktivitas yang berulang-ulang. Aktivitas berulangulang ini dibatasi dalam suatu timeframe (batas waktu tertentu) dan masing-masing tahapan mempunyai sasaran hasil. Di dalam metodologi RUP, tahapan dibagi menjadi: 1. Tahap Permulaan (Inception Phase) Pada tahap ini, implementasi yang dilaksanakan meliputi menggali konteks bisnis yang digeluti, faktor-faktor kesuksesan bisnis (seperti besaran pendapatan yang diinginkan, pangsa pasar dll) dan peramalan keuangan. Setelah tahap ini diselesaikan, proyek implementasi dicocokan terhadap ukuranukuran yaitu Definisi lingkup implementasi sesuai permintaan stakeholder, Pemahaman kebutuhan yang dibuktikan dengan ketepatan jadwal implementasi, Ketepatan menyangkut perkiraan cost/schedule, prioritas, resiko, dan proses pengembangan serta Evaluasi luas lingkup dan kedalaman detail tentang arsitektur prototipe yang dikembangkan.

ISBN : 978-979-99735-3-5 C-8-4


2. Tahap Pengembangan (Elaboration Phase) Di dalam tahap pengembangan dilakukan analisa permasalahan dan arsitektur dari proyek dibuat dalam format dasar. Keberhasilan tahap ini diukur dengan ukuran criteria yaitu Suatu uraian menyangkut arsitektur perangkat lunak di dalam suatu perangkat lunak pengembangan proses sistem dan Suatu perencanaan pengembangan untuk keseluruhan proyek. 3. Tahap Konstruksi (Construction Phase) Di dalam tahap ini, fokus utamanya adalah pengembangan komponen dan fitur-fitur lain dari sistem yang sedang dirancang. Ini adalah tahap dimana pemrograman dilakukan. 4. Tahap Transisi (Transition Phase) Di dalam tahap transisi, implementasi telah diperkenalkan ke end user. Aktivitas pada tahap ini meliputi pelatihan kepada end user, User Accepteance Test dan perbaikan bug yang muncul. Proses implementasi juga dicocokan terhadap standart mutu yang telah ditetapkan dalam Tahap Permulaan. Jika tidak sesuai, keseluruhan siklus di dalam tahap ini mulai lagi dari awal Penelitian yang dilakukan menggunakan suatu metode untuk menggambarkan proses-proses yang dilakukan. Dalam penelitian ini, secara keseluruhan pengumpulan kebutuhan menggunakan metodologi RUP dilaksanakan dengan bantuan suatu tools IBM Rational Rose dari IBM, database menggunakan MSSQL 2000 dan alat untuk pengembangan adalah MS Visual Studio.Net 2003. Diagram alur kerja yang digunakan dalam metodologi penelitian ini adalah sebagai berikut:

Gambar 1 Diagram Metodologi Penelitian

HASIL PENELITIAN Analisa Bisnis Dalam analisa bisnis dibagi menjadi empat sub pokok bahasan yaitu Analisa Sistem Yang Sedang Berjalan, Deskripsi Kebutuhan Sistem, Analisa Use Case dan Analisa Activity Diagram. Analisa Sistem Yang Sedang Berjalan Deskripsi sistem yang sedang berjalan dilakukan dengan pemodelan bisnis. Pemodelan bisnis meliputi penjelasan profil organisasi, struktur organisasi, aliran kerja dalam lokasi penelitian, dan aliran proses dari aplikasi yang sudah ada dan digunakan saat ini

ISBN : 978-979-99735-3-5 C-8-5


Gambar 2 Proses Eksisting Pengiriman PDP

Deskripsi Kebutuhan Sistem Sesuain hasil penelitian pada sistem yang sedang berjalan, maka ditemui hambatan yang mengganggu kelancaran proses administrasi PDP. Hal tersebut terjadi, karena aplikasi yang ada saat ini belum mendukung integrasi proses administrasi PDP dari bagian pelayanan ke bagian keuangan. Analisa Use Case Analisa use case dibuat untuk menggambarkan aktivitas-aktivitas yang dilakukan dalam sistem. Model analisa use case diwakili dengan diagram use case. Diagram use case menggambarkan fungsionalitas sistem sebagai prosedur/aturan yang disepakati sistem berjalan sesuai dengan yang diinginkan. Business Use Case Di Kantor Cabang <<extend>> <<extend>> Bikin File PDP Out

<<extend>> Hitung PDP Out

<<extend>>

Terima File PDP Out

Laporan TI Out Laporan PDP Out

<<extend>>

<<extend>>

Bagian Keuangan KC

Jurnal PDP Out

Bagian Pelayanan KC

LOGIN

(f rom Kantor Cabang)

(f rom Kantor Cabang)

<<extend>>

<<extend>> <<extend>>

Laporan Jurnal PDP Out

Laporan PDP In

<<extend>> Terima File PDP Out Dari KC Lain

<<extend>> Laporan TI In

<<extend>>

Laporan Jurnal PDP In

Jurnal PDP In

Gambar 3 Diagram Model Analisa Use Case

Analisa Activity Diagram Diagram aktivitas memodelkan alur kerja (work flow) sebuah proses bisnis atau use case dan urutan aktivitas dalam suatu proses.

ISBN : 978-979-99735-3-5 C-8-6


Diagram Aktivitas Business Use Case Login Start

Masukkan Username dan Password

[ Ulang Login ] Validasi

[ In-Correct ]

Tampil Error

[ Correct ] Tampil Menu Utam a

End [ Cancel Login ]

Gambar 4 Diagram Activity Use Case Login

Analisa Model Dalam analisa model dibagi menjadi empat sub pokok bahasan. Analisa Realisasi Use Case Pembuatan use case realization diperlukan untuk menghubungkan diagram use case dengan diagram-diagram yang akan dikembangkan pada tahap desain.

Gambar 5 Diagram Realisasi Use Case

Analisa Sequence Diagram Diagram ini menjelaskan interaksi objek yang disusun dalam suatu urutan waktu dan memperlihatkan tahap demi tahap apa yang seharusnya terjadi untuk menghasilkan sesuatu didalam use case.

Gambar 6 Sequence Diagram

ISBN : 978-979-99735-3-5 C-8-7


Analisa Collaboration Diagram Diagram ini melihat pada interaksi dan hubungan terstruktur antarobjek. Tipe diagram ini menekankan pada hubungan antar objek.

Gambar 7 Collaboration Diagram

Analisa Class Diagram Diagram ini membantu kita dalam visualisasi struktur kelas-kelas dari suatu sistem.

Gambar 8 Gambar Class Diagram Desain Model Dalam desain model dibagi menjadi tiga sub pokok bahasan. Desain Database Database yang digunakan untuk aplikasi bantu ini adalah MS SQL Server 2000. Entity Relationship Diagram (ERD) untuk aplikasi bantu ini adalah sebagai berikut:

Gambar 9 ER Diagram

Desain Class Diagram Analisa model yang telah kita buat digunakan sebagai masukan dan arahan dalam membuat desain model. Berbagai properti desain dalam desain kelas, seperti operasi dan atribut.

ISBN : 978-979-99735-3-5 C-8-8

Prosiding Seminar Nasional Manajemen Teknologi VI Program Studi MMT-ITS, Surabaya 4 Agustus 2007 IniReader + «property» Filename : S tring + «property» S ection : S tring - m_Filename : S tring - m_S ection : S tring - MAX_ENTRY : Integer = 32768

- mApplication MainA pp - «property» TestConnection : Boolean + «property» App_Path : S tring + «property» ValPilih : Boolean + «property» ValKdKc : S tring + «property» ValNmKc : S tring + «property» ValKdKr : S tring + «property» ValNmKr : S tring + «property» ValTgl : Date + «property» ValNoJurTran : S tring + «property» ValNoS jp : S tring - m_Pilih : Boolean - m_KdKc : S tring - m_NmKc : S tring - m_KdKr : S tring - m_NmKr : S tring - m_Tgl : Date - m_NoJurTran : S tring - m_NoS jp : S tring + FileIniExist : Boolean + m_S tatCon : Boolean + stsOk : Boolean - m_S ql : S tring - nTambah : Integer = 57

ClsJurTransPDPOut - m_S ql : S tring + New ( ) + GenerateNoTransaksi ( ) + InsertDataPDPOut ( ) + InsertDataPDPOutNew ( ) + UpdateDataPDPOutNew ( ) + DeleteDataPDPOut ( )

- m_MainApp

+ New ( ) + New ( ) # Dispose ( ) - InitializeComponent ( ) + Main ( ) + LastNumber ( ) + GetListComboKc ( ) + CekExistData ( ) + Enkrip ( ) + Deskrip ( ) + S tripPath ( ) + ExtractPath ( ) + ListData ( ) + ClearDataS et ( ) - «get» TestConnection ( ) + «get» App_Path ( ) + «get» ValPilih ( ) + «set» ValPilih ( ) + «get» ValKdKc ( ) + «set» ValKdKc ( ) + «get» ValNmKc ( ) + «set» ValNmKc ( ) + «get» ValKdKr ( ) + «set» ValKdKr ( ) + «get» ValNmKr ( ) + «set» ValNmKr ( ) + «get» ValTgl ( ) + «set» ValTgl ( ) + «get» ValNoJurTran ( ) + «set» ValNoJurTran ( ) + «get» ValNoS jp ( ) + «set» ValNoS jp ( ) + «get» DsKC ( )

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

)

- m_MainApp

ClsJurTransPDPIn - m_S ql : S tring + New ( ) + GenerateNoTransaksi ( ) + InsertDataPDPInNew ( ) + UpdateDataPDPInNew ( ) + DeleteDataPDPIn ( ) - m_PDPIn

- mTulPdp - m_MainApp - mTulPdp - mTulPdp - m_DbCon - m_MainApp - m_MainApp - m_DBCon

- m_PDPOut

New ( ) ReadInteger ( ) ReadInteger ( ) ReadInteger ( ) ReadInteger ( ) ReadS tring ( ) ReadS tring ( ) ReadS tring ( ) ReadLong ( ) ReadLong ( ) ReadLong ( ) ReadLong ( ) ReadByteArray ( ) ReadByteArray ( ) ReadBoolean ( ) ReadBoolean ( ) ReadBoolean ( ) ReadBoolean ( ) Write ( ) Write ( ) Write ( ) Write ( ) Write ( ) Write ( ) Write ( ) Write ( ) Write ( ) Write ( ) Write ( ) DeleteKey ( ) DeleteKey ( ) DeleteS ection ( ) GetS ectionNames ( «get» Filename ( ) «set» Filename ( ) «get» S ection ( ) «set» S ection ( )

FrmHit ungPDP

FrmPassword - nTambah : Integer = 57

- m_DbCon

ClsLaporan + m_sql : S tring + LoadReportPDPKc ( ) + LoadReportPembukuanPDP ( ) + LoadReportRekapTIOutBerdasarkanS JP ( ) + LoadReportKapitasiOut ( ) + LoadReportRekapTIInBerdasarkanS JP ( ) + LoadReportDetailTIOutBerdasarkanS JP ( ) + LoadReportDetailTIInBerdasarkanS Jp ( )

FrmUILaporan + New ( ) # Dispose ( ) - InitializeComponent ( ) - btnCetakTIOut_Click ( ) - BtnKapitasi_Click ( ) - BtnKapitasiIn_Click ( ) - FrmUILaporan_Load ( ) - txtNoS JP_ButtonClick ( ) - btnDetailTIOut_Click ( ) - btnTiIn_Click ( ) - cmbJenisTiIn_S electedIndexChanged ( - FillComboKc ( ) - FillComboKc1 ( ) - FillComboKc2 ( ) - txtNoS jpTiIn_ButtonClick ( ) - btnDetailTiIn_Click ( )

)

FrmJurTransPdpOut + New ( ) # Dispose ( ) - InitializeComponent ( ) - btnKeluar_Click ( ) - FrmJurTransPdpOut_Load ( ) - cmbJenis_S electedIndexChanged ( - txtKdKc_ButtonClick ( ) - CalculateTotals ( ) - ValidateDetailRow ( ) - jsgxDetails_RecordAdded ( ) - jsgxDetails_RecordsDeleted ( ) - jsgxDetails_RecordUpdated ( ) - jsgxDetails_CellUpdated ( ) - jsgxDetails_UpdatingRecord ( ) - jsgxDetails_AddingRecord ( ) - chkFile_CheckedChanged ( ) - BtnFile_Click ( ) - btnRekam_Click ( ) - S tatusTerimaFile ( ) - ClearData ( ) - btnBatal_Click ( ) - txtNoJurnal_ButtonClick ( ) - btnHapus_Click ( ) - btnCetak_Click ( )

+ New ( ) FrmTerimaFileTI # Dispose ( ) + «property» S erverName : S tring - InitializeComponent ( 0..1 + «property» UserName : S tring + New ( ) - FrmPassword_Load ( + «property» UserPwd : S tring # Dispose ( ) - Enkrip ( ) + «property» DBName : S tring - InitializeComponent ( ) - Deskrip ( ) + «property» KdKc : S tring - FrmTerimaFileTI_Load ( ) - btnCancel_Click ( ) + «property» NmKc : S tring - BtnFile_Click ( ) - btnOK_Click ( ) + «property» KdKr : S tring - BtnTerima_Click ( ) - _FrmPassword 0..1 + «property» NmKr : S tring + «property» Tgl : Date + «property» ConnType : S tring + «property» S trConn : S tring - _FrmMain + «property» MsgErrorDB : S tring + «property» PrepareS tatement : S tring - mDbCon - m_S trConn : S tring - _FrmMain - m_Error : S tring + m_ConnType : S tring - _FrmMain 0..1 + m_S erverName : S tring 0..1 0..1 + m_UserName : S tring FrmMain + m_Password : S tring + m_DBName : S tring + New ( ) + m_KdKc : S tring # Dispose ( ) + m_NmKc : S tring - InitializeComponent ( ) + m_KdKr : S tring - FrmMain_Load ( ) + m_NmKr : S tring - tvwUtilitas_AfterS elect ( ) + m_KdApotik : S tring - tvwTransaksi_AfterS elect ( ) + m_NmApotik : S tring - tvwLaporan_AfterS elect ( ) - m_Tgl : Date - _FrmMain - CmdHitungPDP_Click ( ) - m_S ql : S tring - CmdKeluar_Click ( ) + OpenConnection ( ) 0..1 - CmdJurnalPDPIN_Click ( ) - CloseConnection ( ) - CmdJurnalPDPOut_Click ( ) + LoadDataPDPKonsolidasi ( ) - m_DbCon - CmdTerimaFileTI_Click ( ) + GetDBList ( ) - m_DBCon - CmdRekapTIInBerdasarkanS JP1_Click ( ) + GetKC ( ) - CmdRekapTIOutBerdasarkanS JP1_Click ( ) + GetKR ( ) - CmdS ettingKoneksi_Click ( ) + AmbilTglS erver ( ) - cmdDetailTIOutBerdasarkanS JP_Click ( ) + HitungPDP ( ) - cmdDetailTiIn_Click ( ) + CekHitungPDP ( ) - CmdKapitasiRJTPIn_Click ( ) - HapusTIOut ( ) - CmdKapitasiRJTPOut_Click ( ) - mDbCon + HapusTIIn ( ) - _FrmMain 0..1 + HapusPDP ( ) - _FrmM... 0..1 + BeginTrans ( ) + CommitTrans ( ) - m_DbConn + RollbackTrans ( ) + PrepareTabelPDP ( ) FrmLaporan + BikinFileXMLPDPOutPerKc ( ) - sql : S tring - ReleaseResource ( ) + «get» S erverName ( ) + New ( ) + «set» S erverName ( ) # Dispose ( ) + «get» UserName ( ) - frm - InitializeComponent ( ) + «set» UserName ( ) + LoadReportPDPKc ( ) + «get» UserPwd ( ) + LoadReportPembukuanPDP ( ) + «set» UserPwd ( ) + LoadReportRekapTIOutBerdasarkanS JP ( ) + «get» DBName ( ) + LoadReportKapitasiOut ( ) + «set» DBName ( ) + LoadReportRekapTIInBerdasarkanS JP ( ) + «get» KdKc ( ) - FrmLaporan_Load ( ) + «set» KdKc ( ) + LoadReportDetailTIOutBerdasarkanS JP ( ) + «get» NmKc ( ) + LoadReportDetailTIInBerdasarkanS JP ( ) + «set» NmKc ( ) + «get» KdKr ( ) + «set» KdKr ( ) - m_DbCon + «get» NmKr ( ) + «set» NmKr ( ) + «get» Tgl ( ) + «get» ConnType ( ) + «set» ConnType ( ) + «get» S trConn ( ) FrmJurTransPdpIN + «get» ObjConnection ( )

- _DBConnection

+ New ( ) # Dispose ( ) - InitializeComponent ( ) - FrmHitungPDP_Load ( ) - btnHitung_Click ( ) - jsgxPDP_CellUpdated ( ) - CreateFileXML ( ) - BikinFileTIOut ( ) - BtnTutup_Click ( ) - BtnBikinFile_Click ( ) - BtnCetak_Click ( )

)

DBConnect ion

+ «get» MsgErrorDB ( ) + «get» PrepareS tatement ( + «set» PrepareS tatement ( + «get» objDataS et ( )

) )

- m_DbCon

+ New ( ) # Dispose ( ) - InitializeComponent ( ) - btnKeluar_Click ( ) - FrmJurTransPdpIN_Load ( ) - cmbJenis_S electedIndexChanged ( - txtKdKc_ButtonClick ( ) - CalculateTotals ( ) - ValidateDetailRow ( ) - jsgxDetails_RecordAdded ( ) - jsgxDetails_RecordsDeleted ( ) - jsgxDetails_RecordUpdated ( ) - jsgxDetails_CellUpdated ( ) - jsgxDetails_UpdatingRecord ( ) - jsgxDetails_AddingRecord ( ) - chkFile_CheckedChanged ( ) - BtnFile_Click ( ) - btnRekam_Click ( ) - S tatusTerimaFile ( ) - ClearData ( ) - btnBatal_Click ( ) - txtNoJurnal_ButtonClick ( ) - btnHapus_Click ( ) - btnCetak_Click ( )

) )

)

Gambar 10 Class Diagram

Desain User Interface Desain User Interface dibuat berdasarkan pemetaan dari kelas boundary yang ada dalam Analisa Model. Fungsi dari desain Use Interface ini adalah berperan sebagai tampilan antar muka pengguna dalam implementasinya pada pembuatan aplikasi. Implementasi Pada tahapan implementasi dibagi menjadi dua sub pokok bahasan yaitu Pembuatan Prototipe, dan Uji Coba sekaligus Analisa. Pembuatan Prototipe Ringkasan dari pembuatan aplikasi bantu adalah sebagai berikut:

Gambar 11 Menu Utama Aplikasi Bantu KC

Gambar 12 Menu Utama Aplikasi Bantu KR

Uji Coba dan Evaluasi Dalam tahapan ini dibuat skenario uji coba terhadap fitur aplikasi apakah sudah sesuai dengan kebutuhan pengguna atau belum.

ISBN : 978-979-99735-3-5 C-8-9


Gambar 13 Gambar Skenario Uji Coba Kantor Cabang

Gambar 14 Gambar Skenario Uji Coba Kantor Regional

KESIMPULAN DAN SARAN Kesimpulan Dengan memperhatikan hasil-hasil penelitian yang telah diperoleh dapat disimpulkan dua hal berikut: a. Berdasarkan pengamatan terhadap alur sistem yang ada beserta sistem informasi pendukung, terdapat adanya kebutuhan dari pengguna yaitu Bagian Keuangan dan Pelayanan (Staf dan Kepala Seksi), khususnya dukungan suatu aplikasi bantu yang terintegrasi dengan sistem informasi yang ada dalam mengelola pengiriman beban PDP Out dan In. b. Penelitian ini telah menghasilkan desain, analisa model dan prototipe dari aplikasi bantu dengan menggunakan pendekatan object oriented UML. Saran Hasil dari proses penelitian diharapkan dapat mempermudah dalam melakukan evaluasi untuk melakukan perbaikan sistem ke depannya. Dalam peningkatan performa untuk kedepannya alangkah lebih baiknya PT. Askes menyiapkan infrastruktur yang mendukung terciptanya transaksi on-line. DAFTAR PUSTAKA IEEE Recommended Practice for Software Requirements Specifications (IEEE Std 8301998). (1998). Institute of Electrical and Electronics Engineering, Inc. Sommerville, Ian. (2001), "Software Engineering" .6th . Addison Wesley. IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12 – 1990). (1990). Institute of Electrical and Electronics Engineering, Inc. IEEE Guide for Developing System Requirements Specifications (IEEE Std 1233, 1998 edition). (1998). Institute of Electrical and Electronics Engineering Inc. Sommerville, I. & Sawyer, P. (1997). Requirements Engineering: A Good Practise Guide. John Wiley & Sons. Peter Eeles, Kelli Houston, Wojtek Kozaczynski, Building J2EE Applications With The Rational Unified Prosess, Addison Wesley, 2003

ISBN : 978-979-99735-3-5 C-8-10

DESAIN APLIKASI BANTU PENGIRIMAN BEBAN PDP (POS DALAM PERJALANAN) PELAYANAN KESEHATAN ASKES KOMERSIAL DI PT. ASKES REGIONAL VII JAWA TIMUR

Recommend Documents