Sistem informasi lembaga keuangan mikro subsistem perkreditan pada Bank Perkreditan Rakyat : studi kasus pada Bank Perkreditan Rakyat Wilayah Daerah Istimewa Yogyakarta - USD Repository

(1)

i

WILAYAH DAERAH ISTIMEWA YOGYAKARTA )

Skripsi

Diajukan untuk Memenuhi Salah Satu Syarat

Memperoleh Gelar Sarjana Teknik

Program Studi Teknik Informatika

Oleh:

I Kadek Dendy Senapartha

055314074

PROGRAM STUDI TEKNIK INFORMATIKA

JURUSAN TEKNIK INFORMATIKA

FAKULTAS SAINS DAN TEKNOLOGI

UNIVERSITAS SANATA DHARMA

YOGYAKARTA

(2)

ii A Thesis

Presented as Partial Fulfillment of the Requirements

To Obtain the Sarjana Teknik Degree

In Study Program of Informatics Engineering

By:

I Kadek Dendy Senapartha

055314074

INFORMATICS ENGINEERING STUDY PROGRAM

DEPARTMENT OF INFORMATICS ENGINEERING

FACULTY OF SCIENCE AND TECHNOLOGY

SANATA DHARMA UNIVERSITY

YOGYAKARTA

(3)

(4)

(5)

v

BHAGAVAD GITA

Sloka 3. 8

niyatam kuru karma tvam karma jyayo hy akarmanah sarira – yatrapi ca te na prasiddhyed akarmanah

Artinya :

Lakukanlah tugas kewajibanmu yang telah ditetapkan, sebab melakukan hal

demikian lebih baik dari pada tidak bekerja. Seseorang bahkan tidak dapat

(6)

vi

bagian karya orang lain, kecuali yang telah disebutkan dalam kutipan dan daftar pustaka, sebagaimana layaknya karya ilmiah.

Yogyakarta, Januari 2010 Penulis

(7)

vii

(BPR) adalah sistem yang digunakan untuk menangani proses bisnis perbankan sehari-hari. Sistem ini dikembangkan untuk mempermudah proses transaksi bank mulai dari customer service, tabungan, deposito, perkreditan, teller, utilitas dan pencatatan akuntansi.

Dalam tugas akhir ini dibuat sebuah subsistem dari sistem informasi lembaga keuangan mikro (microbank) pada Bank Perkreditan Rakyat (BPR) yaitu subsistem backoffice yang menangani masalah perkreditan. Subsistem ini menangani semua proses perkreditan yaitu, manajemen data debitur, transaksi angsuran kredit, pencetakan laporan, perhitungan bunga dan denda, realisasi kredit, manajemen data tabel pendukung kredit dan penjadwalan angsuran kredit debitur. Sistem telah berhasil dikembangkan dengan menggunakan metodologi FAST, dan diimplementasikan dengan menggunakan bahasa permrograman Java, database MySQL, Netbeans 6.5 dan MySQL browser. Selain itu, sistem yang dibuat dapat berjalan pada platform yang berbeda seperti sistem operasi Windows dan Linux.

(8)

viii ABSTRACT

The information system of microfinance institutions in Bank Perkreditan Rakyat (BPR) is a system that used to handle daily banking business processes. This system was developed to facilitate the process of banking transactions consist of customer service, savings, deposits, credits, teller, utilities and accounting records.

This thesis was made in purpose to build a subsystem of the information system of microfinance institutions (microbank) in BPR that handle backoffice credit problems. This subsystem handles all the credit process, the debtor data management, credit installment transactions, printing reports, calculating interest and penalties, the realization of credit, supporting tables of data management and scheduling of installment credit loan borrowers. The system has been successfully developed using FAST methodology, and has been implemented using the Java programming language, MySQL database, NetBeans 6.5 and MySQL browser. In addition, the system can be run on different platforms like Windows and Linux.

(9)

ix

LEMBAR PERNYATAAN PERSETUJUAN

PUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS

Yang bertanda tangan dibawah ini, saya mahasiswa Universitas Sanata Dharma : Nama : I Kadek Dendy Senapartha

NIM : 055314074

Demi pengembangan ilmu pengetahuan, saya memberikan kepada Perpustakaan Universitas Sanata Dharma karya ilmiah saya yang berjudul :

SISTEM INFORMASI LEMBAGA KEUANGAN MIKRO

SUBSISTEM PERKREDITAN PADA BANK PERKREDITAN RAKYAT

( STUDI KASUS PADA BANK PERKREDITAN RAKYAT

WILAYAH DAERAH ISTIMEWA YOGYAKARTA )

Beserta perangkat yang diperlukan ( bila ada ). Dengan demikian saya memberikan kepada Perpustakaan Universitas Sanata Dharma hak untuk menyimpan, mengalihkan dalam bentuk media lain, mengelolanya dalam bentuk pangkalan data, mendistribusikan secara terbatas, dan mempublikasikannya di Internet atau media lain untuk kepentingan akademis tanpa perlu meminta ijin dari saya maupun memberikan royalti kepada saya selama tetap mencantumkan nama saya sebagai penulis.

Demikian pernyataan ini yang saya buat dengan sebenarnya. Dibuat di Yogyakarta

Pada tanggal : Janunari 2009

Yang menyatakan

(10)

x

KATA PENGANTAR

Puji dan syukur saya panjatkan kehadirat Tuhan Yang Maha Esa atas berkat dan rahmatNya yang melimpah sehingga penulis dapat menyelesaikan Laporan Tugas Akhir ini.

Pada kesempatan ini penulis ingin menyampaikan terimakasih kepada semua pihak yang sudah membantu dalam penyelesaian skripsi ini, sehingga skripsi ini dapat terselesaikan dengan baik. Ucapan terima kasih ini saya sampaikan terutama kepada.

1. Bapak Yosef Agung Cahyanta, S.T., M.T., selaku Dekan Fakultas Sains dan Teknologi Universitas Sanata Dharma Yogyakarta.

2. Bapak Puspaningtyas Sanjaya Adi, S.T., M.T., selaku Ketua Jurusan Teknik Informatika Universitas Sanata Dharma.

3. Ibu A. Rita Widiarti, S.Si., M.Kom, selaku Dosen Pembimbing Akademik Teknik Informatika angkatan 2005.

4. Ibu P.H. Prima Rosa, S.Si., M.Sc, selaku Dosen Pembimbing TA. Terima kasih atas bimbingan selama saya mengerjakan Laporan Skripsi ini. 5. Kepada mbak Nurma Evy selaku pembimbing lapangan yang telah

membantu saya dalam menganalisa dan memecahkan permasalahan – permasalahan selama pengerjaan tugas akhir ini.

(11)

xi

Nariwastu, Fransiskus Paranso, Ari Bagoes, Christiono Eka, Ignasius Hans, Dominikus Catur, Gregorius Arif, Linus Wedar Duanto dan teman – teman SaOS dan Narayana Smrti.

8. Semua pihak yang telah membantu penulisan baik secara langsung maupun tidak langsung, yang tidak dapat penulis sebutkan satu persatu.

Akhir kata penulis menyadari bahwa skrisi ini masih jauh dari sempurna. Karena itu penulis sangat berterima kasih atas segala kritik dan saran yang akan diberikan sehingga skripsi ini bermanfaat bagi pembaca.

Atas perhatian dari semua pihak sata ucapkan terima kasih.

Yogyakarta, Januari 2010

(12)

xii DAFTAR ISI

(13)

xiii

(14)

xiv

(15)

xv

(16)

xvi

DAFTAR GAMBAR

(17)

xvii

(18)

xviii

(19)

xix

(20)

DAFTAR TABEL

(21)

Tabel 3.27. Tabel Jenis Asuransi ________________________________ 117 Tabel 5.1. Perbandingan kapabilitas basis data MySQL 3.x dan MySQL 5.x _

(22)

BAB I

PENDAHULUAN

1.1. Latar Belakang Masalah

Bank Perkreditan Rakyat adalah suatu bank yang lebih mengkhususkan pelayanan perbankannya pada pemberian kredit untuk masyarakat. Namun BPR juga menerima dana dari masyarakat berupa tabungan dan deposito. Pada BPR permintaan kredit oleh nasabah dapat dilayani dengan cepat, dimana proses pencairan dana kredit tersebut dapat mencapai waktu satu hari. Untuk mempercepat dan mempermudah pegawai BPR dalam melayani kredit nasabah, maka diperlukan pembukuan kredit yang akurat dan cepat.

(23)

Dari kendala-kendala tersebut, penulis bermaksud membangun “Sistem Informasi Lembaga Keuangan Mikro Subsistem Perkreditan Pada Bank Perkreditan Rakyat”. Subsistem ini nantinya diharapkan dapat menangani proses transaksi kredit yang besar dan banyak, menggunakan basis data yang mendukung teknologi transaction, stored procedure, trigers, cursors, constraints, dan full join. Sistem ini juga nantinya diharapkan akan dapat bekerja pada platform manapun (multiplatform), sehingga BPR memiliki peluang untuk memilih sistem operasi yang diinginkannya.

1.2. Rumusan Masalah

Dari latar belakang masalah yang telah dikemukakan oleh penulis, maka rumusan masalahnya adalah sebagai berikut:

1. Bagaimana mengembangkan suatu subsistem perkreditan pada BPR yang dapat bekerja pada platform manapun (multiplatform)?

2. Bagaimana cara mengembangkan sebuah subsistem perkreditan pada BPR menggunakan metode perhitungan bunga kredit flat dan basis data yang mendukung teknologi transaction, stored procedure, triger, cursor, constraint, dan full join ?

1.3. Batasan Masalah

(24)

bunga kredit yang tidak berkaitan dengan faktor-faktor berikut ini : 1.1 Penentuan nasabah yang mendapatkan kredit.

1.2 Pembukuan pada neraca, overboking dan buku besar akuntansi. 1.3 Kolektor dan aspek yang dinilai dari nasabah yang ingin

mengajukan kredit ke BPR.

2. Sistem dapat digunakan oleh banyak pengguna (Multiuser). 3. Sistem ditampilkan dalam ruang lingkup window application.

1.4. Tujuan dan Manfaat Penelitian

Tujuan dan manfaat dari pembuatan sistem ini adalah :

1. Membuat suatu subsistem perkreditan yang dapat menangani transaksi kredit yang besar dan banyak.

2. Membuat suatu subsistem perkreditan yang menggunakan basis data dengan teknologi stored procedure, trigers, cursors, constraints, dan full join

3. Mengembangkan suatu subsistem perkreditan yang dapat bekerja pada platform manapun (multiplatform).

1.5. Metode Penelitian

1. Definisi ruang lingkup: Dalam tahap ini dilakukan penentuan kelayakan dan batasan-batasan dari sistem yang akan dibangun. Hasil dari tahap ini adalah pernyataan masalah yang dihadapi.

(25)

yang ada sekarang dan menganalisa masalah-masalah utama yang dihadapi dalam sistem. Dalam tahap ini akan dihasilkan diagram konteks dan analisa sebab-akibat (cause-effect analysis).

3. Analisis kebutuhan : Dalam tahap ini dilakukan pengumpulan data akan kebutuhan dan menganalisanya. Metode dalam pengumpulan data ini menggunakan cara wawancara dan studi literatur. Hasil dari tahap ini direpresentasikan dengan use-case diagram dan use-case narative.

4. Desain logis : Dalam tahap ini dilakukan pembuatan rancangan sistem informasi secara logis, baik activity diagram, E-R diagram dan class diagram.

5. Desain fisik dan integrasi : Dalam tahap ini dilakukan perancangan sistem secara fisik berupa desain interface, sequence diagram, relational model, dan class diagram lengkap.

6. Pembuatan sistem dan pengujian: Tahap ini digunakan untuk membangun sistem berdasarkan rancangan yang dibuat pada tahap desain fisik, kemudian menguji komponen-komponen sistem tersebut.

1.6. Sistematika Penulisan

Sistematika penulisan Tugas akhir ini adalah sebagai berikut : BAB I. PENDAHULUAN

(26)

masalah, metodelogi penelitian, dan sistematika penulisan.

BAB II. LANDASAN TEORI

Bab ini mengemukakan teori-teori yang mendukung dalam perancangan dan pengimplementasian sistem informasi perkreditan BPR antara lain tentang peraturan perhitungan bunga kredit standard Bank Indonesia (BI), perhitungan bunga kredit pada BPR, MySQL dan JAVA.

BAB III. ANALISIS DAN PERANCANGAN SISTEM

Bab ini berisi uraian mengenai pernyataan masalah, analisis masalah menggunakan PIECES, gambaran sistem saat ini, cause-effect analysis, gambaran sistem baru, orang-orang yang terlibat dalam sistem, diagram konteks, diagram use case, ringkasan use case, use case narative, activity diagram, E-R diagram, sequence diagram, class diagram, dan perancangan tampilan untuk pembuatan sistem informasi lembaga keuangan mikro subsistem perkreditan pada Bank Perkreditan Rakyat.

BAB IV. IMPLEMENTASI SISTEM

Bab ini akan menguraikan tentang proses implementasi rancangan sistem yang sudah dibuat pada bab III.

BAB V. ANALISA HASIL

(27)

perkreditan BPR antara lain tentang metode rekayasa perangkat lunak yang dipakai dalam pengembangan sistem, analisa manfaat, perangkat lunak yang digunakan, dan kelebihan serta kekurangan sistem.

BAB VI. PENUTUP

(28)

BAB II

LANDASAN TEORI

2.1. Pengertian Sistem Informasi

Sistem informasi adalah pengaturan orang, data, proses dan teknologi informasi yang berintraksi untuk mengumpulkan, memproses, menyimpan, dan menyediakan sebagai output informasi yang diperlukan untuk mendukung. Banyak organisasi menganggap sistem informasi diperlukan untuk memiliki kemampuan bersaing atau memperoleh keuntungan persaingan. Banyak oraganisasi menyadari bahwa semua pekerja harus berpartisipasi dalam pengembangan sistem informasi.

Sistem informasi adalah susunan dari orang, data, proses serta teknologi informasi yang saling berinteraksi untuk mengumpulkan, memproses, menyimpan dan menyediakan suatu informasi yang diperlukan untuk mendukung organisasi. Sistem informasi banyak digunakan dalam organisasi untuk meningkatkan kemampuan memperoleh manfaat ataupun competitive advantage (Whitten).

(29)

2.3. Analisis dan Desain Berbasis Objek

Pendekatan berorientasi pada pengembangan sistem didasarkan pada konsep tentang objek yang telah ada pada sebuah lingkungan sistem. Objek dapat diartikan sesuatu yang dapat dilihat, disentuh atau dirasakan, dan user menyimpan data serta mencatat perilaku mengenai sesuatu itu.

2.3.1. Object Oriented Analysis (OOA)

Menurut Whitten (2004), Object Oriented Analysis merupakan pendekatan yang digunakan untuk mengidentifikasikan fungsionalitas dari kebutuhan sistem dari perspektif user dan mengidentifikasikan objek, atribut, behaviour, dan relasi yang mendukung kebutuhan fungsional sistem.

2.3.2. Object Oriented Design (OOD)

Menurut Whitten (2004), Object Oriented Design merupakan pendekatan yang digunakan untuk menspesifikasikan solusi perangkat lunak dalam bentuk kolaborasi objek, atribut, dan fungsinya. Tahap ini merupakan kelanjutan dari proses object oriented analysis. Dalam tahap ini terdapat tiga jenis objek, yaitu :

1. Entity Object, merupakan sebuah objek yang berisi informasi yang berhubungan dengan bisnis dan secara khusus bersifat persisten dan disimpan dalam database.

(30)

menggambarkan bagaimana sebuah aktor akan berkomunikasi dengan sistem. Contoh : sebuah window, dialog box. Interface object mempunyai dua tanggung jawab, yaitu :

a. Menterjemahkan input user ke dalam informasi yang dapat dimengerti oleh sistem dan sistem dapat menggunakannya untuk memproses kejadian bisnis.

b. Membawa data yang berhubungan ke dalam suatu kejadian bisnis dan menterjemahkan data untuk dipresentasikan secara tepat kepada user.

c. Control Object, merupakan sebuah objek yang berisi aplikasi logik yang bukan merupakan tanggung jawab entity object. Control object akan mengkoordinasikan message antar interface object dan entity object dan mengurutkan message yang terjadi.

2.3.3. UML (Unified Modelling Languange)

(31)

UML memberikan sembilan diagram yang dikelompokan ke dalam lima kelompok dengan sudut pandang yang berbeda terhadap sebuah model sistem. Berikut adalah pengelompokannya :

1. USE-CASE MODEL DIAGRAM

Use case diagram adalah sekumpulan diagram yang menggambarkan interaksi antara sistem dan eksternal sistem dan user. Use case secara behavioral berhubungan dengan urutan langkah-langkah, baik secaraotomatis maupun manual dengan tujuan untuk melengkapi bisnis tunggal, misalnya login ke sistem, manambah data barang, menghapus data barang, dan sebagainya. Actor adalah segala sesuatu yang dibutuhkan untuk berinteraksi dengan sistem untuk mengubah informasi.

Use Case Diagram terdiri atas beberapa komponen, yaitu :

1. Use Case

Use case adalah urutan langkah – langkah yang secara tindakan saling terkait ( skenario ), baik terotomatisasi maupun secara manual, untuk tujuan melengkapi satu tugas bisnis tunggal ( Whitten, 2004 ).

2. Pelaku

(32)

Whitten, 2004 ). Adapun terdapat empat tipe pelaku, yaitu : 2.1. Primary business actor ( pelaku bisnis utama )

Stakeholder yg mendapat keuntungan utama dari proses mengeksekusi use case.

2.2. Primary system actor( pelaku sistem utama )

Stakeholder yg secara langsung berinteraksi dg sistem utk menginisiasi atau memicu (men- trigger) kejadian bisnis atau sistem.

2.3. External server actor ( pelaku pelayan luar )

Stakeholder yg merespon terhadap permintaan dari use case.

2.4. External receiver actor( pelaku penerima luar )

Stakeholder yg bukan merupakan pelaku utama tetapi menerima sesuatu yg berharga dr use case.

3. Relationship ( Hubungan )

Relationship adalah hubungan antar use case dengan pelaku maupun antar use case ( Whitten, 2004 ). Adapun terdapat lima tipe relationship yaitu :

Association

Suatu relasi antara seorang aktor dan sebuah use case dimana terjadi interaksi yg terjadi diantara mereka. Extends

(33)

dringkas dari sebuah use case yang lebih kompleks agar menjadi use case yang lebih sederhana namun secara fungsi lebih meluas.

Abstract

Suatu use case yg mengurangi redudansi antara dua atau lebih use case dg cara mengkombinasikan langkah - langkah yg umum yg ditemui dalam use case tersebut.

Depends on

Sebuah relasi use case yang menentukan bahwa use case yang lain harus dibuat sebelum current use case. Inheritance

Suatu relasi use case dimana tindakan yg sama dari dua aktor menginisiasi use case yg sama diekstrapolasi dan dibentuk menjadi aktor baru secara abstrak untuk mengurangi redundancy.

(34)

Tabel 2.1. Tabel Komponen Use Case

Simbol Keterangan

Simbol dari pelaku atau aktor use case.

Simbol dari use case atau fungsi sistem.

Simbol relasi association. Simbol relasi extends.

Simbol relasi abstract.

Simbol relasi depends on.

Simbol relasi inheritance.

2. STATIC STRUCTURE DIAGRAM

Ada 2 diagram yang tergolong dalam kelompok ini yaitu:

a. Class diagram menggambarkan struktur dari objek sistem. Class diagram memperlihatkan class dalam sistem beserta relasi antara class.

(35)

3. INTERACTION DIGARAM

Interaction diagram memodelkan sebuah interaksi, yang berisi sekumpulan objek dan relasinya, dan juga message yang dikirim antara objek dan relasinya. Diagram ini memodelkan dinamic behaviour dari sistem. Ada dua diagram yaitu:

a. Sequence diagram menjelaskan interaksi objek yang disusun dalam suatu urutan waktu. Diagram ini secara khusus berasosiasi dengan use case. Sequence diagram memperlihatkan tahap demi tahap apa yang seharusnya terjadi untuk menghasilkan sesuatu didalam use case. b. Collaboration diagram sama dengan sequence diagram tetapi tidak

berfokus pada timing atau ‘sequence’ dari message. Menggambarkan interkasi (collaboration) antar objek dalam format network. Antara sequence diagram dan collaboration diagram bersifat isomorphic, yang berarti dapat melakukan transformasi satu bentuk ke bentuk yang lainnya.

4. STATE DIAGRAM

(36)

a. Statechart diagram digunakan untuk model dinamic behaviour dari particular object.

b. Activity diagram digunakan untuk menggambarkan aliran sequen dari aktifitas dari proses bisnis atau sebuah use case.

5. IMPLEMENTATION DIAGRAM

Implementation diagram terdiri dari dua diagram:

a. Component diagram digunakan untuk menggambarkan organisasi dan ketergantungan dari komponen sistem software. Component diagram dapat digunakan utnuk memperlihatkan bagaimana kode program dibagi ke dalam modul-modul (atau komponen).

b. Deployment diagram menggambarkan arsitektur secara fisik dalam bentuk ‘node’ untuk hardware dan software dalam sistem. Menggambarkan konfigurasi dari run-time software component, processor, dan peralatan lain yang membentuk arsitektur sistem.

2.4. Diagram Relasi Entitas

(37)

Gambar 2.1. Diagram Relasi Entitas

Entitas adalah sebuah kumpulan dari orang, tempat, objek, kejadian atau konsep yang diperlukan untuk menyimpan data. Nama entity berupa kata benda tunggal ( singular noun ).

Gambar 2.2. Entitas

(38)

Gambar 2.3. Atribut

Key merupakan sebuah atribut atau kelompok atribut yang diasumsikan memiliki nilai yang unik untuk setiap instance. Sering juga disebut dengan identifier.

1. Concatenated key merupakan sekelompok atribut yang memiliki identitas instance dari sebuah entity yang unik Sinonimnya composite key dan compound key.

2. Candidate key merupakan satu dari nilai key yang akan berfungsi sebagai primary key dari sebuah entity. Sinonimnya adalah candidate identifier

3. Primary key merupakan sebuah candidate key yang paling umum digunakan untuk mengidentifikasikan secara unik instance dari entitas yang tunggal.

(39)

Gambar 2.4. Identifier atau kunci

Relasi adalah sebuah asosiasi bisnis normal yang ada antara satu atau lebih entitas. Relasi mungkin juga mewakili suatu kejadian yang menghubungkan antara entitas atau logika gabungan antara entitas.

Gambar 2.5. Relasi Antar Entitas

Kardinalitas merupakan minimum dan maksimum kejadian dari sebuah entitas yang dihubungkan dengan kejadian tunggal dari entitas yang lain. Karena seluruh relasi adalah bidirectional maka kardinalitas

(40)

harus didefinisikan pada kedua arah untuk setiap relasi. Tabel 2.2. Tabel Notasi Relasi INTERPRETASI

KARDINALITAS

CONTOH

MINIMUM

CONTOH

MAKSIMUM

NOTASI

GRAFIS

Tepat satu ( satu dan hanya satu )

1 1

atau

Nol atau satu 0 1

Satu atau lebih 1 Banyak ( > 1 )

Nol, satu atau lebih 0 Banyak ( > 1 )

Lebih dari satu >1 >1

Foreign key adalah sebuah primary key dari sebuah entitas yang digunakan oleh entitas yang lain untuk mengidentifikasikan instance dari sebuah relasi.

(41)

relasi dimana banyak instance dari sebuah entitas berasosiasi dengan banyak instance dari entitas yang lainnya. Disebut juga dengan relasi many-to-many relationship. Nonspecific relationship harus diselesaikan. Kebanyakan dari nonspecific relationship diselesaikan dengan sebuah entitas asosiatif.

Key-base data model bertujuan untuk mengeliminasikan nonspecific relationship jika ada, menambah asosiatif entitas termasuk primary dan alternate key, dan kardinalitas yang tepat.

Fully attributed data model bertujuan untuk memasukkan seluruh atribut.

2.5. Sistem Pemrosesan Transaksi

Menurut M. Lewis, sistem pemrosesan transaksi adalah sebuah sistem yang mengatur akses kepada DBMS. Sistem pemrosesan transaksi umumnya terdiri dari pemantau pemprosesan transaksi, satu atau lebih DBMS, dan sekelompok aplikasi yang berisi transaksi.

Transaksi memiliki komponen yang membedakannya dengan sistem yang biasa. Komponen untuk membuat sebuah transaksi dikenal dengan istilah ACID yaitu:

a. Atomicity, merujuk pada sistem harus memastikan bahwa transaksi dapat berjalan. Jika transaksi tidak berjalan, maka tidak memiliki akibat apapun.

(42)

dapat mengasumsikan ketika menjalankan transaksi, basis data memenuhi aturan integritas data yang memuaskan. Perancang basis data memiliki tanggung jawab untuk memastikan ketika eksekusi transaksi telah selesai, maka basis data tetap memenuhi aturan integritas.

c. Isolation, merujuk pada walaupun transaksi dijalankan bersama-sama, memiliki hasil yang sama dengan transaksi yang dijalankan secara serial.

d. Durable, merujuk pada sistem harus memastikan bahwa ketika transaksi berhasil maka tersimpan dalam basis data baik di komputer atau media dimana basis data disimpan.

2.6. Lembaga Keuangan Mikro (LKM)

Lembaga keuangan yang terlibat dalam penyaluran kredit mikro umumnya disebut Lembaga Keuangan Mikro (LKM). Menurut Asian Development Bank (ADB), lembaga keuangan mikro (microfinance) adalah lembaga yang menyediakan jasa penyimpanan (deposits), kredit (loans), pembayaran berbagai transaksi jasa (payment services) serta money transfers yang ditujukan bagi masyarakat miskin dan pengusaha kecil (insurance to poor and low-income households and their microenterprises).

(43)

Desa). Sedangkan yang bersifat non bank adalah koperasi simpan pinjam (KSP), unit simpan pinjam (USP), lembaga dana kredit pedesaan (LDKP), baitul mal wattanwil (BMT), lembaga swadaya masyarakat (LSM), arisan, pola pembiayaan Grameen, pola pembiayaan ASA, kelompok swadaya masyarakat (KSM), dan credit union.

2.7. Bank Perkreditan Rakyat

Bank Perkreditan Rakyat atau BPR adalah salah satu jenis bank yang melayani golongan pengusaha mikro, kecil dan menengah dengan lokasi yang pada umumnya dekat dengan tempat masyarakat yang membutuhkan. BPR sudah ada sejak jaman sebelum kemerdekaan yang dikenal dengan sebutan Lumbung Desa, bank Desa, Bank Tani dan Bank Dagang Desa atau Bank Pasar.

BPR merupakan lembaga perbankan resmi yang diatur berdasarkan Undang-Undang No. 7 tahun 1992 tentang Perbankan dan sebagaimana telah diubah dengan Undang-Undang No. 10 tahun 1998. Dalam undang-undang tersebut secara jelas disebutkan bawah ada dua jenis bank, yaitu Bank Umum dan BPR.

(44)

prinsip 3T, yaitu Tepat Waktu, Tepat, Jumlah, Tepat Sasaran, karena proses kreditnya yang relatif cepat, persyaratan lebih sederhana, dan sangat mengerti akan kebutuhan Nasabah.

Jenis layanan yang diberikan BPR adalah :

 Menghimpun dana masyarakat dalam bentuk deposito berjangka, tabungan dan atau bentuk lain yang dipersamakan dengan itu.

 Memberikan kredit dalam bentuk Kredit Modal Kerja, Kredit Investasi, maupun Kredit Konsumsi.

2.8. Perhitungan Bunga Kredit dengan Angsuran

Perhitungan bunga kredit yang digunakan bank akan menentukan besar kecilnya angsuran pokok dan bunga yang harus dibayar Debitur atas kredit yang diterima dari bank. Pemahaman mengenai berbagai perhitungan bunga akan membantu Debitur dalam membuat keputusan untuk mengambil kredit yang paling menguntungkan sesuai dengan kemampuan keuangannya.

Beberapa cara yang digunakan oleh bank dalam menghitung bunga antara lain:

1. Flat Rate

(45)

bunga kredit setiap bulan sama besarnya. Rumusan perhitungan Flat Rate:

2. Efektif (Sliding Rate)

Perhitungan bunga dilakukan setiap akhir periode pembayaran angsuran. Pada perhitungan ini, bunga kredit dihitung dari saldo akhir setiap bulannya (baki debet) sehingga bunga yang dibayar debitur setiap bulannya semakin menurun. Dengan demikian, jumlah angsuran yang dibayar debitur setiap bulannya akan semakin mengecil.

Rumusan perhitungan Efektif (Sliding Rate):

3. Anuitas

(46)

akan semakin membesar.

Rumusan perhitungan Efektif (Sliding Rate):

2.9. Java

Java merupakan pemrograman yang dikembangkan oleh Sun Microsystem dan dirancang sedemikian rupa agar program yang dibuat menggunakan Java dapat berjalan pada semua platform. Java merupakan pemrograman berorientasi objek (OOP), dengan kata lain rancangan Java merupakan suatu teknik yang memusatkan rancangan pada data (objek) dan interface (Didik D.P, 2004).

Menurut Indrajani dan Martin (2004), dibandingkan dengan bahasa pemrograman yang lain, Java memiliki beberapa kelebihan, yaitu:

a. Bersifat portable dan platform independent

(47)

c. Memiliki garbage collection yang dapat mendealokasi memori secara otomatis.

d. Menghilangkan pewarisan berganda yang terdapat pada C++. Walaupun kelihatannya lebih sebagai suatu kekurangan, namun banyak para ahli yang mengakui bahasa konsep pewarisan berganda lebih banyak mengakibatkan kerugian daripada keuntungan.

e. Penggunaan pointer aritmetik telah dikurangi dengan membatasi penggunakan reference.

f. Memiliki array sejati

g. Mengurangi kerancuan antara pemberian nilai pada statemen kondisional. Contoh penggunaan tanda ‘=’ dengan ‘= =’ pada kondisi if.

2.10. JDBC

Menurut Didik D.P (2004), JDBC merupakan API Java Database Connectivity dan merupakan bagian dari Java Enterprise APIs dari JavaSoft. Class JDBC terdapat di dalam paket java.sql, dan semua program Java menggunakan method serta objek dari paket tersebut untuk membaca serta menulis data source.

(48)

perintah SQL ke sistem database relasional dan mendukung bermacam-macam perintah SQL.

Dengan JDBC dapat dibuat program dengan portabilitas tinggi dan cukup mudah karena secara umum pemrograman JDBC tidak memiliki perbedaan kode yang berarti untuk pemrograman pada database tertentu dengan database lain. Perbedaan utama pada kode hanyalah kode yang mendefinisikan driver dari database server serta perintah SQL tertentu yang mungkin memiliki perbedaan sintak atau perintah SQL khusus yang hanya terdapat pada database tertentu. Pemrograman JDBC memiliki struktur seperti melakukan koneksi, membuat object statement, mengeksekusi perintah SQL, mendapatkan hasil query, serta menangani error.

2.11. MySQL

MySQL (My Structure Query Language) merupakan sebuah aplikasi database open-source. MySQL dikembangkan dengan tujuan untuk menyediakan database dengan koneksi yang aman dan cepat, memiliki keamanan yang tinggi, mudah digunakan dan dapat dipakai oleh semua orang. MySQL sendiri sebenarnya merupakan pengembangan dari mSQL dengan optimasi konektivitas, peningkatan performa dan perbedaan interface SQL.

(49)

mengakses database di internet.

Beberapa kemampuan MySQL antara lain :

1. MySQL bisa diakses dan dimanipulasi dari beberapa bahasa pemrograman, diantaranya adalah C, C++, Java, Perl, Python, Java dan lain-lain.

2. MySQL mendukung tipe data yang umum digunakan, seperti float, double, char, varchar, text, blob, date, integer dan lain-lain.

3. MySQL mendukung subset fungsi query dan pengelompokkan lanjut, termasuk diantaranya group by dan order by.

4. MySQL memungkinkan alokasi password tiap server. Password yang melalui MySQL telah terenkripsi.

5. MySQL bisa diperoleh secara gratis untuk penggunaan pribadi, termasuk aplikasi-aplikasi lain yang diperlukan dalam memakai MySQL.

a. Structure Query Languange

SQL merupakan bahasa standar yang digunakan untuk mengakses dan memanipulasi database. Perintah-perintah dasar SQL antara lain : 1. Perintah untuk membuat database.

CREATE DATABASE nama_database;

2. Perintah untuk membuat tabel.

(50)

3. Perintah untuk membaca data yang tersimpan di dalam tabel. SELECT * FROM nama_tabel;

SELECT nama_field1, nama_field2, … FROM nama_tabel;

4. Perintah untuk menambahkan data ke dalam tabel.

INSERT INTO nama_tabel (nama_field1, nama_field2, …) values (data_field1, data_field2, …);

5. Perintah untuk mengubah data yang tersimpan di dalam tabel. UPDATE nama_tabel

SET nama_field1 = nilai_baru1, nama_field2 = nilai_baru2, … WHERE kriteria;

6. Perintah untuk menghapus data yang tersimpan di dalam tabel. DELETE FROM nama_tabel WHERE kriteria;

7. Perintah untuk mengurutkan data.

SELECT nama_field1, nama_field2, … FROM nama_tabel ORDER BY nama_field ASC || DESC;

b. Stored Procedure

(51)

prosedur tersebut diubah atau dimodifikasi, semua client akan mendapatkan versi terbarunya secara otomatis (tanpa perlu diadakan update aplikasi client). Stored procedure selain bersifat terintegrasi dengan server juga sudah terkompilasi, sehingga pemrosesan kode yang terjadi di dalam stored procedure akan berlangsung lebih cepat dibandingkan dengan mengeksekusi beberapa statement SQL secara sekuensial.

Pendefinisian stored procedure pada DBMS Engine masih termasuk tahap pendefinisian DDL (Data Definition Language). Ciri utama query SQL termasuk ke dalam DDL adalah dengan penggunaan keyword CREATE, ALTER atau DROP. Kedudukan CREATE PROCEDURE, CREATE FUNCTION, maupun CREATE TRIGGER setara dengan proses pendefinisian DDL yang paling umum dipergunakan, CREATE TABLE, yang mana dalam konteks pembahasan pengembangan sistem pada umumnya, fase pendefinisian DDL ini termasuk dalam siklus desain sistem dalam System Development Lifecycle (SDLC).

(52)

Gambar 2.6. Transaksi lalu lintas query

Seperti terlihat pada gambar di atas, pemrosesan query pada sistem yang menerapkan stored procedure sangat menghemat lalu-lintas pengiriman query dari program aplikasi di sisi client kepada DBMS Engine. Jumlah query yang dikirimkan hanya satu, yaitu pengeksekusian procedure. Berbeda jauh dengan pemrosesan query yang dilakukan tanpa stored procedure, melainkan mengandalkan programming pada sisi client, dimana jumlah query yang dikirimkan sangatlah banyak bergantung pada kontrol perulangan (loop) yang dieksekusi.

(53)

kejadian tertentu terjadi.

Berikut perintah untuk membuat store procedure : 1. Membuat procedure. Perintah :

CREATE PROCEDURE nama_procedure ([parameter_proc[,…]])

[characteristic ..] routine_body

2. Membuat function. Perintah :

CREATE FUNCTION nama_function ([parameter_proc[,…]])

RETURN type [characteristic ..] routine_body

3. Membuat trigger. Perintah :

CREATE [DEFINER = { user | current_user } ] TRIGGER

trigger_name trigger_time trigger_event ON table_name

FOR EACH ROW trigger_statement

4. Pemanggilan procedure. Perintah : CALL nama_proc(parameter_proc);

5. Pemanggilan function. Perintah :

SELECT nama_function(parameter_function);

6. Melihat procedure dan function yang ada. Perintah : SHOW PROCEDURE STATUS;

SHOW FUNCTION STATUS;

7. Melihat isi procedure dan function. Perintah : SHOW CREATE PROCEDURE nama_procedure;

SHOW CREATE FUNCTION nama_function;

8. Menghapus procedure dan function. Perintah : DROP PROCEDURE nama_procedure;

(54)

BAB III

ANALISIS KEBUTUHAN DAN PERANCANGAN LOGIS SISTEM

3.1. Analisis Kebutuhan Sistem

3.1.1. Gambaran Sistem di BPR

Proses transaksi kredit pada Bank Perkreditan Rakyat dimulai dari pencatatan data nasabah yang dilakukan pada subsistem costumer service. Dalam subsistem ini akan dilakukan pencatatan informasi pribadi nasabah. Setelah itu data nasabah yang sudah dicatat pada subsistem costumer service akan digunakan pada subsistem perkreditan dan sistem teller.

Gambar 3.1. Diagram Konteks Sistem yang Lama

(55)

subsistem ini akan dilakukan pencatatan data pinjaman kredit seperti jumlah dana yang ingin dipinjam, lamanya jangka waktu pinjaman, jumlah angsuran, pencatatan data jaminan, penjadwalan angsuran kredit, penentuan denda, dan pemilihan produk kredit. Hasil pencatatan dari subsistem ini akan digunakan oleh berbagai subsistem seperti customer service, tabungan, deposito, teller dan akuntansi.

Setelah pencatatan pada subsistem perkreditan selesai, maka proses transaksi dapat dilakukan pada subsistem teller. Subsistem ini melakukan transaksi realisasi kredit, perhitungan denda bulanan dan jatuh tempo, dan transaksi angsuran kredit. Hasil dari transaksi ini kemudian digunakan kembali oleh subsistem perkreditan untuk kemudian dibuat laporan transaksi kredit per periode.

Pengguna dari sistem ini terdiri dari beberapa kelompok yaitu manajer dan direksi. Untuk dapat menjalankan sistem ini, setiap pengguna harus login terlebih dahulu. Dalam proses login ini, penentuan tingkat akses dari sistem ditentukan, apakah pengguna merupakan seorang direksi atau manajer perkreditan.

(56)

Direksi perkreditan adalah pihak yang dapat membuat dan memasukkan data-data sebuah produk kredit beserta kebijakan-kebijakan yang digunakan pada setiap produk perkreditan.

3.1.2. Fase Definisi Ruang Lingkup (Scope Definition Phase)

3.1.1.1. Pernyataan Masalah

Sistem informasi lembaga keuangan mikro subsistem perkreditan yang digunakan pada BPR saat ini masih terdapat kendala-kendala utama. Performance : Kendala utama pada sistem informasi yang lama terletak pada basis data yang masih menggunakan MySQL 3 yang tidak mendukung teknologi stored procedure, trigers, cursors, constraints, dan full joins sehingga kueri yang dikirimkan ke basis data rentan terhadap crash yang disebabkan sistem.

Information : Dengan adanya performa yang rendah dari basis data yang digunakan dan sering terjadinya crash pada sistem, menyebabkan informasi transaksi pada sistem menjadi tidak valid. Ini juga menyebabkan sistem direksi harus sering mem-backup basis data secara keseluruhan.

(57)

biaya yang digunakan untuk membangun sistem ini.

Control : Keakuratan data yang dihasilkan dan disimpan oleh sistem informasi saat ini kurang akurat, hal ini dikarenakan performa sistem yang kurang baik dan penggunaan basis data yang tidak mendukung teknologi stored procedure, trigers, cursors, constraints, dan full joins.

Eficiency : Sistem informasi yang ada saat ini tidak menggunakan basis data yang mendukung teknologi stored procedure, trigers, cursors, constraints, dan full joins, kueri yang dikirimkan dari aplikasi ke basis data tidak efisien.

Service : -

Tabel 3.1. Pernyataan Masalah

Pernyataan masalah Solusi

1. Sistem yang lama masih sering terjadi crash saat menangani transaksi yang cukup besar dan banyak.

Membuat sistem dengan teknologi yang dapat menangani transaksi yang cukup besar dan banyak.

2. Sistem yang lama menggunakan basis data yang tidak mendukung teknologi teknologi stored procedure, trigers, cursors, constraints, dan full joins sehingga kueri yang dikirimkan ke basis data rentan terhadap crash yang

disebabkan sistem.

Membuat sistem yang mendukung teknologi stored procedure, trigers, cursors, constraints, dan full join.

3. Sistem saat ini hanya dapat berjalan pada platform sistem operasi Windows, sehingga BPR harus

(58)

menganggarkan dana untuk

membayar lisensi sistem operasi dari Microsoft. Hal ini membuat

anggaran pengadaan sistem menjadi lebih mahal.

3.1.3. Fase Analisis Masalah (Problem Analysis Phase) 3.1.2.1. Analisa Sebab-Akibat (Cause-Effect Analysis)

Tabel 3.2. Analisa Sebab Akibat Project : Sistem informasi lembaga

keuangan Mikro pada Bank Perkreditan Rakyat Subsistem Perkreditan Menggunakan Metode Perhitungan Bunga Kredit Flat

Project manajer : I Kadek Dendy S

Created by : I Kadek Dendy S Last Update by : I Kadek Dendy S Date Created : 18 November 2008 Date Last Update : 18 November 2008

CAUSE AND EFFECT ANALYSIS SYSTEM IMPROVEMENT OBJECTIVES Problem /

Opportunity

Causes and effects

System objectives System constraint

(59)

3.1.2.2. Gambaran sistem baru

Secara kontekstual, alur bisnis sistem lama dengan sistem yang baru tidak ada perbedaan.

(60)

Untuk menggunakan sistem ini, pengguna haruts melakukan login terlebih dahulu dimana login dari masing-masing pengguna akan menentukan tingkat akses pengguna sistem. Setelah proses login selesai maka pengguna dapat menggunakan sistem untuk mencatat dan mengolah data perkreditan.

Pengguna sistem memasukan data kredit yang kemudian akan diolah dan disimpan ke basis data. Kemudian manajer dapat melakukan pengolahan data debitur, perhitungan denda, penjadwalan angsuran kredit, dan pencatatan data transaksi kredit.

Setelah semua proses pengolahan data selesai dan disimpan dalam basis data, manajer juga dapat mencetak berbagai laporan dari subsistem perkreditan yang kemudian dilaporkan kepada pihak direksi Bank Perkreditan Rakyat.

Pembuatan produk tabungan dan kebijakannya masih menjadi hak dari Direksi perkreditan yang harus disetujui oleh pihak direksi Bank Perkreditan Rakyat

3.1.2.3. Orang yang terlibat dalam sistem

1. Direksi : Orang / kelompok yang mempunyai hak akses / kewenangan khusus untuk melakukan penambahan, perubahan, penghapusan data-data, pengaturan bunga kredit, produk kredit dan pengaturan administrasi kredit BPR, dimana data-data tersebut tersimpan dalam satu basis data di kantor.

(61)

pencatatan transaksi kredit, validasi transaksi kredit dan pencetakan transaksi kredit yang diinginkan debitur. manajer juga dapat melakukan update transaksi apabila kredit debitur telah lunas.

3.1.2.5. Diagram use case 3.2.1.5.1.

Aktor use case

Tabel 3.3. Aktor Use Case

Nama aktor Keterangan

Direksi Orang / kelompok yang mempunyai hak akses / kewenangan khusus untuk melakukan penambahan, perubahan, penghapusan data-data, pengaturan bunga kredit, produk kredit dan pengaturan administrasi kredit BPR, dimana data-data tersebut tersimpan dalam satu basis data-data di kantor.

(62)

3.2.1.5.2. Use Case Diagram Direksi

Sistem informasi lembaga

keuangan mikro BPR

Subsistem perkreditan

Direksi

Login

Logout Pengelolaan produk kredit

Pengelolaan data debitur <<depend on>>

Pengelolaan tabel pendukung

Pencetakan laporan

(63)

A. Use case diagram paket pengelolaan produk kredits

Pengelolaan tabel pendukung

Menghapus data table pendukung Mengisi data table

pendukung

Mengubah data table pendukung

Direksi

Gambar 3.3. Use case paket pengelolaan tabel pendukung

B. Use case diagram paket pengelolaan tabel pendukung

(64)

3.2.1.5.3. Use Case Diagram Manajer

Sistem informasi perbankan

mikro BPR

Subsistem perkreditan

Manager

Login

Logout

Pengelolaan data debitur

<<depend on>>

Menjadwal angsuran kredit

Transaksi kredit

Pencetakan laporan kredit

(65)

A. Use case diagram paket pengelolaan data debitur

Pengelolaan data debitur

Administrator/Manager

Menambah data debitur

Mencari data debitur Menghapus data

debitur

Mengubah data debitur

<<extend>>

Gambar 3.6. Use case diagram paket mengelola data debitur

B. Use case diagram paket transaksi kredit

(66)

C. Use case diagram paket pencetakan laporan kredit

Gambar 3.8. Use case diagram paket pencetakan laporan kredit

3.1.2.6. Ringkasan use case a. Use case direksi

Tabel 3.4. Ringkasan Use Case Direksi Nama Use-case Deskripsi Use-Case

Login Use case ini menggambarkan proses masuk ke sistem. Membuat produk

kredit

Use case ini menggambarkan proses pembuatan produk kredit yang ada pada subsistem perkreditan.

Menghapus produk kredit

Use case ini menggambarkan proses menghapus produk kredit yang ada pada subsistem perkreditan.

Mengubah produk kredit

Use case ini menggambarkan proses mengubah atau mengupdate produk kredit yang ada pada subsistem perkreditan.

Mengisi data table pendukung

Use case ini menggambarkan proses menambah atau mengisi data tabel pendukung.

(67)

pendukung pendukung. Menghapus data tabel

pendukung

Use case ini menggambarkan proses menghapus data tabel pendukung.

Logout Use case ini menggambarkan proses logout (keluar) dari system

b. Use case manajer

Tabel 3.5. Ringkasan Use Case Manajer

Nama Use-case Deskripsi Use-Case

Login Use case ini menggambarkan proses masuk ke sistem. Menambah data

debitur

Use caseini menggambarkan proses menambah data debitur.

Menghapus data debitur

Use case ini menggambarkan proses menghapus data debitur.

Mengubah data debitur

Use case ini menggambarkan proses mengubah data debitur

Mencari data debitur Use case ini menggambarkan proses pencarian data debitur. Pencetakan laporan

nominatif

Use case ini menggambarkan proses pencetakan laporan nominative

Pencetakan daftar angsuran kredit

Use case ini menggambarkan proses pencetakan daftar angsuran kredit

Pencetakan riwayat transaksi kredit

Use case ini menggambarkan proses pencetakan riwayat transaksi kredit

Pencetakan data debitur

Use case ini menggambarkan proses pencetakan data debitur.

Setoran dan perhitungan denda

Use case ini menggambarkan proses angsuran dan perhitungan jumlah denda kredit debitur.

Realisasi Kredit Use case ini menggambarkan proses realisasi / pencairan dana kredit debitur

Pencetakan nota angsuran

Use case ini menggambarkan proses pencetakan nota angsuran debitur.

Pencetakan bukti realisasi

Use case ini menggambarkan proses pencetakan bukti realisasi kredit debitur

(68)

kredit kredit debitur.

Logout Use case ini menggambarkan proses logout (keluar) dari system

3.1.2.7. Use case narative 1) login

Author :dendy prtha Date : 26 November 2008 Version : 1.0

Nama Use-case:

Login Jenis Use-Case

Business Requirements:  ID Use-Case: SIMSPK-001

Prioritas : High Sumber: - Aktor bisnis primer:

Direksi atau manajer Aktor lain Use case ini berguna untuk menjaga privileges.

Kondisi awal: Direksi dan manajer telah memiliki password

Trigger: Use case ini digunakan apabila direksi atau manajer ingin masuk ke dalam sistem.

Urutan aktivitas normal:

Aksi Aktor Respon sistem

Step 1: Direksi atau manajer membuka form login

Step 3: Direksi atau manajer memasukkan username dan password Step 4: Direksi atau manajer menekan tombol ”MASUK”

Step 2: Sistem meminta memasukkan username dan password

Step 5: Sistem mengecek validasi username dan password di basis data

Step 6: Sistem masuk ke menu utama

(69)

sehingga sistem tidak jadi masuk ke menu utama.

Alt-step 5: Jika username dan password yang dimasukkan tidak sesuai maka sistem akan memberikan peringatan dan secara otomatis kembali meminta user untuk memasukan username dan password.

Kesimpulan: Use case ini berhenti apabila Direksi atau manajer telah berhasil masuk ke dalam menu utama masing-masing user.

Kondisi akhir:  Direksi atau manajer berhasil login dan masuk ke menu utama masing-masing user.

 Direksi atau manajer gagal login dan tidak jadi masuk ke menu utama

Prosedur bisnis:

User baik direksi atau manajer harus memasukan username dan password dengan benar

Batasan Implementasi dan

spesifikasi:

 Harus dapat diakses setiap saat

 Dapat diakses hanya oleh pengguna yang memiliki password

2) Membuat produk kredit

Membuat produk kredit Jenis Use-Case

Prioritas : High

Deskripsi: Use case ini menggambarkan proses pembuatan produk kredit yang ada pada subsistem perkreditan.

Kondisi awal: Direksi melakukan login ke dalam sistem

Trigger: Use case ini digunakan apabila direksi ingin membuat produk kredit yang ada pada BPR

(70)

Step 1: Direksi masuk ke menu pengelolaan produk kredit pesan data berhasil disimpan Aktivitas lain: Alt-step 3 : Direksi menekan tombol “SELESAI” dan kembali

ke menu utama

Alt-step 4: Direksi menekan tombol “BATAL” untuk membatalkan pembuatan produk kredit.

Alt-step 8: Jika data tidak berhasil disimpan, sistem akan menampilkan pesan gagal.

Kesimpulan: Use case ini berhenti apabila Direksi telah berhasil memproses dan menyimpan data-data produk kredit yang dibuat.

Kondisi akhir:

 Data-data produk kredit yang dimasukan berhasil disimpan

 Data-data produk kredit yang dimasukan gagal disimpan Prosedur

bisnis:

User direksi harus memasukan data dengan tipe yang sesuai Batasan

Implementasi dan

spesifikasi:

 Harus dapat diakses oleh direksi

 Harus dapat menyimpan data jenis produk kredit yang dimasukkan

3) Menghapus produk kredit

Menghapus produk kredit Jenis Use-Case

Prioritas : High Sumber: - Aktor bisnis primer:

(71)

Aktor lain

Deskripsi: Use case ini menggambarkan proses menghapus produk kredit yang ada pada subsistem perkreditan.

Kondisi awal: Direksi sudah melakukan login ke dalam sistem, berada pada form produk kredit dan telah melakukan pencarian produk kredit yang ingin dihapus.

Trigger: Use case ini digunakan apabila direksi ingin menghapus produk kredit yang ada pada BPR

Step 1 : Direksi memilih data yang ingin dihapus Step 2 : Direksi menekan tombol “HAPUS”

Step 4 : Direksi memilih “Ya” pada pesan konfirmasi.

Step 3 : Sistem memberikan pesan konfirmasi ya dan tidak ke direksi. Step 5 : Sistem memproses penghapusan data

Step 6 : Sistem menampilkan pesan data berhasil dihapus

Aktivitas lain: Alt-step 2: Direksi menekan tombol “SELESAI” dan kembali ke menu utama

Alt-step 2: Direksi menekan tombol “SIMPAN” untuk menyimpan data produk kredit.

Alt-step 4: Direksi memilih “Tidak” pada pesan konfirmasi, sehingga tidak terjadi penghapusan data.

Kesimpulan: Use case ini berhenti apabila Direksi telah berhasil menghapus produk kredit yang ingin dihapus.

Kondisi akhir:  Data yang ingin dihapus berhasil dihapus  Data yang ingin dihapus gagal gagal dihapus Prosedur

bisnis:

spesifikasi:

 Harus dapat menampilkan data apabila data telah ditemukan

(72)

ditemukan

4) Mengubah produk kredit

Mengubah produk kredit Jenis Use-Case

Deskripsi: Use case ini menggambarkan proses mengubah produk kredit yang ada pada subsistem perkreditan.

Kondisi awal: Direksi sudah melakukan login ke dalam sistem, berada pada form produk kredit dan telah melakukan pencarian produk kredit yang ingin diubah.

Trigger: Use case ini digunakan apabila direksi ingin mengubah produk kredit yang ada pada BPR

Step 1 : Direksi memilih pesan data berhasil disimpan Aktivitas lain: Alt-step 2 : Direksi menekan tombol “SELESAI” dan kembali

ke menu utama

Alt-step 2: Direksi menekan tombol “HAPUS” untuk menghapus produk kredit yang sudah ada.

(73)

dan menyimpan produk kredit yang ingin diubah.

Kondisi akhir:  Data yang ingin diubah berhasil ditemukan dan diubah  Data yang ingin diubah gagal ditemukan dan gagal

diubah Prosedur

bisnis:

spesifikasi:

 Harus dapat menampilkan data apabila data telah ditemukan

 Harus dapat menyimpan data apabila data telah diubah

5) Mengisi data table pendukung

Author :dendy prtha Date : 26 November 2008 Version : 1.0 ID Use-Case: SIMSPK-009

Deskripsi: Use case ini menggambarkan proses menambah atau mengisi data tabel pendukung

Kondisi awal: Direksi melakukan login ke dalam sistem

Trigger: Use case ini digunakan apabila direksi ingin menambah atau mengisi data tabel pendukung

(74)

memasukan data yang pesan data berhasil disimpan Aktivitas lain: Alt-step 3 & 5 : Direksi menekan tombol “SELESAI” dan

kembali ke menu utama

Alt-step 5 : Direksi menekan tombol “HAPUS” untuk menghapus data yang sudah ada pada tabel pendukung.

Kesimpulan: Use case ini berhenti apabila Direksi telah berhasil mengisi dan menyimpan data tabel pendukung.

Kondisi akhir:  Data yang sudah diisi berhasil disimpan  Data yang sudah diisi gagal disimpan Prosedur

bisnis:

spesifikasi:

 Data yang dimasukan harus dapat disimpan pada tabel pendukung .

6) Mengubah data table pendukung

Business Requirements: ・ ID Use-Case: SIMSPK-011

Deskripsi: Use case ini menggambarkan proses mengubah data tabel pendukung

(75)

Trigger: Use case ini digunakan apabila direksi ingin mengubah data tabel pendukung

Step 1 : Direksi memilih pesan data berhasil disimpan Aktivitas lain: Alt-step 2 : Direksi menekan tombol “SELESAI” dan kembali

ke menu utama

Alt-step 2: Direksi menekan tombol “HAPUS” untuk menghapus data yang sudah ada pada tabel pendukung.

Kesimpulan: Use case ini berhenti apabila Direksi telah berhasil mengubah dan menyimpan data tabel pendukung yang ingin diubah.

Kondisi akhir:  Data yang diubah berhasil ditemukan dan berhasil disimpan

 Data yang diubah gagal ditemukan dan gagal disimpan Prosedur

bisnis:

spesifikasi:

 Data yang diubah harus dapat disimpan pada tabel pendukung .

7) Menghapus data table pendukung

Menghapus data tabel pendukung

Jenis Use-Case

(76)

yang

Deskripsi: Use case ini menggambarkan proses menghapus data tabel pendukung

Kondisi awal: Direksi sudah melakukan login ke dalam sistem, berada pada form tabel pendukung dan telah melakukan pencarian data tabel pendukung yang ingin dihapus

Trigger: Use case ini digunakan apabila direksi ingin menghapus data tabel pendukung

Step 1 : Direksi memilih data yang ingin hapus

Step 2 : Direksi menekan tombol “HAPUS”

Step 4 : Direksi memilih “Ya” pada pesan konfirmasi.

Step 3 : Sistem memberikan pesan konfirmasi ya dan tidak ke direksi. Step 5: Sistem memproses dan menghapus data

Aktivitas lain: Alt-step 2 : Direksi menekan tombol “SELESAI” dan kembali ke menu utama

Alt-step 2: Direksi menekan tombol “SIMPAN” untuk menyimpan data.

Alt-step 4: Direksi memilih “Tidak” pada pesan konfirmasi, sehingga tidak terjadi penghapusan data tabel pendukung. Alt-step 4: Jika data tidak berhasil dihapus, sistem akan menampilkan pesan gagal.

Kesimpulan: Use case ini berhenti apabila Direksi telah berhasil menghapus data tabel pendukung yang ingin dihapus.

Kondisi akhir:  Data tabel pendukung yang dicari berhasil ditemukan dan berhasil dihapus

 Data tabel pendukung yang dicari gagal ditemukan dan gagal dihapus

Prosedur bisnis:

(77)

spesifikasi:

8) Menambah data debitur

Menambah data debitur Jenis Use-Case

Subsistem teller (memberikan data nasabah yang akan menjadi calon debitur)

Stakeholder lain yang tertarik:

-

Deskripsi: Use case ini menggambarkan proses menambah atau mengisi data debitur

Kondisi awal: manajer melakukan login ke dalam sistem

Trigger: Use case ini digunakan apabila manajer ingin menambah atau mengisi data debitur

Step 1: manajer masuk ke menu data debitur Step 2 : manajer memilih tab entry data debitur Step 4 : manajer membuka tabel data nasabah yang sudah ada Step 6 : manajer memilih data nasabah yang akan menjadi calon debitur

Step 7 : manajer memasukan data kredit yang diinginkan oleh

Step 2: sistem menampilkan form data debitur

Step 3 : sistem menampilkan form entry data debitur

(78)

debitur pesan data berhasil disimpan Aktivitas lain: Alt-step 8 : manajer menekan tombol “SELESAI” dan kembali

ke menu utama

Alt-step : manajer menekan tombol “HAPUS” untuk menghapus data debitur

Kesimpulan: Use case ini berhenti apabila manajer telah berhasil memasukan data debitur dan menyimpan data debitur.

Kondisi akhir:  _{Data yang sudah diisi berhasil disimpan}  Data yang sudah diisi gagal disimpan Prosedur

bisnis:

User manajer harus memasukan data dengan tipe yang sesuai Batasan

Implementasi dan spesifikasi:

 Harus dapat diakses oleh manajer

 Data calon debitur harus ada pada daftar nasabah  Data yang dimasukan harus dapat disimpan

9) Menghapus data debitur

Menghapus data debitur Jenis Use-Case

Subsistem teller (memberikan data yang akan menjadi calon debitur)

-

Deskripsi: Use case ini menggambarkan proses menghapus data debitur Kondisi awal: Manajer/Direksi sudah melakukan login ke dalam sistem,

berada pada form data debitur dan telah melakukan pencarian data debitur yang ingin dihapus.

(79)

Step 1: Manajer/ Direksi memilih data debitur yang ingin dihapus memilih “Ya” pada pesan konfirmasi.

Step 3 : Sistem menampilkan form entry data debitur

Step 5 : Sistem memberikan pesan konfirmasi ya dan tidak

Step 7 : Sistem memproses dan menghapus data debitur

Aktivitas lain: Alt-step 2: manajer menekan tombol “SELESAI” dan kembali ke menu utama.

Alt-step 2: manajer menekan tombol “PROSES” untuk mencari data debitur.

Alt-step 4: manajer menekan tombol “KEMBALI” untuk kembali data debitur yang sudah tercatat.

Alt-step 6: Direksi memilih “Tidak” pada pesan konfirmasi, sehingga tidak terjadi penghapusan data tabel pendukung. Alt-step 8: Jika data tidak berhasil dihapus, sistem akan menampilkan pesan gagal.

Kesimpulan: Use case ini berhenti apabila manajer telah berhasil mencari dan menghapus data debitur.

Kondisi akhir:  Data yang dicari berhasil dihapus  Data yang dicari gagal dihapus Prosedur

bisnis:

User manajer harus memasukan data dengan tipe yang sesuai Batasan

Implementasi dan spesifikasi:

 Harus dapat diakses oleh manajer

 Calon debitur telah terdaftar pada nasabah  Kredit debitur belum direalisasikan / dicairkan  Data yang ingin dihapus harus benar-benar dihapus

10)Mengubah data debitur

(80)

Mengubah data debitur Jenis Use-Case

Subsistem teller (memberikan data yang akan menjadi calon debitur)

-

Deskripsi: Use case ini menggambarkan proses mengubah data debitur Kondisi awal: Manajer / Direksi sudah melakukan login ke dalam sistem,

berada pada form data debitur dan telah melakukan pencarian data debitur yang ingin dihapus.

Trigger: Use case ini digunakan apabila manajer / Direksi ingin mengubah data debitur

Step 1 : manajer/ Direksi memilih data debitur yang ingin diubah pesan data berhasil disimpan Aktivitas lain: Alt-step 2 : manajer menekan tombol “SELESAI” dan kembali