Pada bab ini akan diuraikan tentang kesimpulan dan saran yang dapat diambil dari pembahasan dan implementasi yang telah dilakukan serta saran- saran untuk pengembangan program selanjutnya.
BAB II
LANDASAN TEORI
2.1. Vihara
Menurut koran KOMPAS (2009) Vihara adalah tempat peribadatan Umat Buddha. Idealnya Vihara adalah tempat tinggal para Bhikkhu pada suatu komunitas. Jangan pula dirancukan dengan Biara Buddha, karena biara adalah untuk para Bhikkhu yang memutuskan untuk menjauhi kehidupan duniawi / menyendiri dan biasanya Biara terletak jauh dari keramaian. Selain itu ada pula vihara skala kecil yang disebut sebagai Cetya.
Jika anda sempat masuk ke vihara, tengoklah ke arah altar. Jika hanya ada 1 rupang Buddha, maka itu adalah Vihara Aliran Threavada. Bisa dipastikan rupang di altar tersebut adalah Rupang Buddha Gautama. Jika anda melihat rupang di altar ada 3, maka kemungkinan besar viharanya adalah Aliran Mahayana. Jika di altar ada Rupang Buddha yang berada di tengah, maka itu adalah Rupang Buddha Amitabha / Amitayus. Walaupun berbeda aliran, saya sempat menemukan Ruang Kebaktian suatu Vihara yang bisa digunakan oleh ke-2 aliran secara bergantian.
Selain itu, peribadatan yang dilakukan juga berbeda. Peribadatan di Klenteng kebanyakan adalah untuk meminta sesuatu dan bersifat pribadi, sedangkan di Vihara, peribadatan bersifat kebaktian dan bisa diisi ceramah oleh bhikkhu ataupun dhammadutta.
2.2. Pengolahan Data
2.2.1. Pengertian Data dan Pengolahan Data
Data menurut Drs. Jhon J. Longkutoy (1996 : 69), mengatakan bahwa
“Data adalah suatu istilah majemuk dari fakta yang mengandung arti yang
dihubungkan dengan kenyataan, simbol, gambar, angka, huruf yang menunjukan suatu ide, objek, kondisi atau situasi dan lainnya”.
Menurut Jogiyanto H.M (2005) “Pengolahan Data adalah manipulasi dari data ke dalam bentuk yang lebih berguna berarti. Dengan demikian dapat disimpulkan bahwa “Pengolahan Data merupakan kegiatan yang dilakukan dengan menggunakan masukan berupa data dan menghasilkan informasi
yang bermanfaat untuk tujuan sesuai dengan yang direncanakan.”
2.2.2 Desain Sistem
Desain sistem adalah spesifikasi solusi berbasis komputer yang terinci. Desain sistem terstruktur adalah teknik berorientasi proses untuk mengubah program besar ke dalam hirarki modul-modul yang menghasilkan sebuah program komputer yang lebih mudah untuk diimplementasikan dan dipelihara (diubah).
Tahapan dari desain sistem antara lain:
1. Arsitektur dan pemodelan aplikasi
3. Desain dan prototyping output
4. Desain dan prototyping input
5. Desain antarmuka pengguna
2.2.2.1.Use Case Diagram
Use case diagram adalah sebuah diagram yang
menggambarkan interaksi antara sistem, eksternal sistem dan pemakai. Use case merupakan bagian dari keseluruhan sistem. Digambarkan secara grafik dengan elips yang horizontal dengan nama dari use case tertera di atas, di bawah atau di dalam elips. Gambar 2.1 merupakan simbol use case.
Gambar 2.1. Simbol use case (Whitten et al, 2007)
Actor merupakan segala sesuatu yang dibutuhkan untuk berinteraksi dengan sistem untuk mengubah informasi. Dapat berupa orang, organisasi atau sistem informasi yang lain atau juga suatu waktu kejadian. Gambar 2.2 merupakan simbol dari aktor.
Gambar 2.2. Simbol Actor (Whitten et al, 2007)
Use case depends on relationship merupakan sebuah relasi use
case yang menentukan bahwa use case yang lain harus dibuat sebelum use case yang sekarang. Digambarkan sebagai anak panah yang dimulai dari satu use case dan menunjuk ke use case yang
depend on kepadanya. Setiap relasi depend on diberi label
“<<depend on>> “. Gambar 2.3 merupakan simbol depend on.
Use case1
Use case2
<<depend on>>
Gambar 2.3. Simbol depend on (Whitten et al, 2007)
2.2.2.2.Diagram Aktifitas
Diagram aktifitas digunakan untuk menggambarkan proses bisnis, langkah-langkah use case, dan logika perilaku obyek/metode.
Gambar 2.4 merupakan contoh dari activity diagram.
Keterangan Gambar 2.4 adalah:
1. Node awal / Initial Node merupakan lingkaran penuh
yang menyatakan awal proses.
2. Aksi / Actions merupakan kotak berujung bulat yang
menyatakan langkah tunggal. Sederetan aksi akan membentuk aktivitas total yang diperlihatkan dengan diagram.
3. Alur / Flow merupakan panah pada diagram
menunjukan alur aksi. Tidak perlu keterangan kecuali jika alur tersebut keluar dari notasi keputusan.
4. Keputusan / Decision merupakan bentuk belah ketupat
dengan satu alur masuk dan dua atau lebih alur keluar. Alur keluar diberi keterangan untuk mengindikasikan kondisi.
5. Penggabungan / Merge merupakan bentuk belah
ketupat dengan banyak alur masuk dan satu alur keluar. Notasi ini menggabungkan alur yang sebelumnya dipisah dengan keputusan. Proses berlanjut dengan banyak alur masuk ke penggabungan.
6. Pemisah / Fork merupakan garis hitam dengan satu alur
masuk dan dua atau lebih alur keluar. Aksi pada alur paralel di bawah pemisah dapat terjadi dalam beberapa urutan atau secara bersamaan.
7. Penghubung / Join merupakan garis hitam dengan dua atau lebih alur masuk dan satu alur keluar. Menandai akhir dari proses bersamaan. Semua aksi yang masuk ke join harus diselesaikan sebelum proses berlanjut.
8. Aktifitas akhir / Final Activity meupakan lingkaran
padat di dalam lingkaran berlubang menyataka akhir proses.
9. Indicator subaktivitas / Subactivity indicator
merupakan symbol dalam aksi ini menandakan bahwa aksi dipecah menjadi diagram aktivitas yang terpisah. Hal ini untuk membantu diagram aktivitas agar tidak menjadi kompleks.
10.Penghubung / Connector merupakan huruf di dalam
lingkaran yang membantu untuk membantu
kompleksitas. Alur masuk ke dalam konektor akan melompat ke alur keluar dengan huruf yang sesuai.
2.2.2.3. Diagram Kelas Analisa
Diagram Kelas Analisa merupakan gambaran grafis dari struktur obyek statis sistem. Diagram kelas ini menunjukan kelas-kelas obyek yang menyusun sistem sertaq relasi diantara kelas-kelas-kelas-kelas obyek. Obyek pada class diagram ini dapat disimpan dalam dua kelas, yaitu:
Kelas Persisten adalah sebuah kelas yang mendeskripsikan obyek yang akan tetap ada meskipun eksekusi program sudah selesai, dengan kata lain obyek tersebut disimpan secara permanen di dalam basis data.
Kelas Obyek Transien adalah sebuah kelas yang
mendeskripsikan obyek yang dibuat secara temporer dan hanya dikenali selama program dieksekusi.
2.2.2.4. Diagram Sekuensial
Diagram sekuensial merupakan diagram UML yang
memodelkan logika dari use case dengan menggambarkan interaksi pesan-pesan antara obyek dalam urutan waktu. Sequence diagram terdiri dari beberapa bagian seperti yang terlihat pada gambar 2.5.
Gambar 2.5. Contoh Diagram Sekuensial (Whitten et al, 2007)
Keterangan gambar 2.5 adalah:
1. Actor 2. System 3. Lifelines 4. Actifation bars 5. Input messages 6. Output messages
7. Receiver Actor
8. Frame
2.2.2.5. Diagram Kelas Desain
Diagram kelas desain merupakan sebuah diagram yang menggambarkan kelas-kelas yang berhubungan dengan komponen software yang digunakan untuk membangun aplikasi software. Diagram kelas berisi:
Kelas
Relasi asosiasi, generalization / specialization, dan agregasi.
Informasi atribut dan tipe atribut
Metode dengan parameter
Navigability
Ketergantungan (dependensi)
2.2.2.6. Desain Database
Entity Relationship (E-R Diagram)
E-R Diagram adalah model konseptual yang mendeskripsikan antara penyimpanan data. ERD digunakan untuk memodelkan struktur data dan relasi antara struktur data. Dengan ERD, model dapat diuji dengan mengabaikan proses yang dilakukan.
ERD pertama kali dideskripsikan oleh Peter Chen yang dibuat sebagai bagian dari perangkat lunak CASE.
Adapun beberapa konsep dasar dan simbol-simbol yang mendasari semua model data, yaitu sebagai berikut:
a. Entitas
Entitas adalah sebuah kumpulan dari orang, tempat, obyek, kejadian atau konsep yang diperlukan untuk menyimpan data.
Gambar 2.6. Simbol Entitas (Whitten et al, 2007)
b. Atribut
Atribut merupakan sebuah properti yang deskriptif atau
karakteristik dari sebuah entitas. Sinonimnya adalah element,
property, dan field.
Kardinalitas Relasi
Dalam ERD hubungan (relasi) dapat terdiri dari sejumlah entitas yang disebut dengan derajat relasi. Derajat relasi maksimum disebut kardinalitas sedangkan derajat minimum relasi disebut dengan modalitas. Jadi, kardinalitas relasi menunjukan jumlah maksimum entitas yang dapt berelasi dengan entitas pada himpunan entitas lain. Kardinalitas relasi yang terjadi diantara dua himpunan entitas (misalnya entitas A dan B) dapat berupa:
1. Satu ke satu (one to one / 1-1)
Setiap entitas pada himpunan entitas A dapat berelasi dengan paling banyak satu entitas pada himpunan entitas B, demikian sebaliknya.
2. Satu ke banyak (one to many / 1-N)
Setiap entitas pada himpunan A dapat berelasi dengan banyak entitas pada himpunan entitas B, tetapi tdak sebaliknya.
3. Banyak ke banyak (many to many / N-N)
Setiap entitas pada himpunan A dapat berelasi dengan banyak entitas pada himpunan entitas B, begitu juga sebaliknya.
Gambar 2.8 merupakan notasi dari cardinality
Gambar 2.8. Notasi Kardinalitas (Whitten et al, 2007)
2.3. Metodologi Penelitian dalam Pengembangan Sistem.
Metode penelitian yang digunakan untuk pengembangan Aplikasi Pengolahan Data Umat dan Alumni ini menggunakan metode FAST (Framework for the
Application of System Thinking), yang meliputi:
Fase Definisi Ruang Lingkup (Scope Definition Phase) : Fase ini merupakan
fase penentuan batasan sistem yang akan dibuat, serta mengidentifikasi garis besar dan kesempatan. Hasil dari Tahap ini adalah pernyataan masalah yang dihadapi.
Fase Analisis Masalah (Problem Analysis Phase) : Fase ini merupakan fase untuk melakukan analisis secara menyeluruh terhadap permasalahan dari sistem yang ada sekarang. Dalam tahap ini akan dihasilkan diagram konteks
dan analisa sebab–akibat (cause-effect analysis) dari sistem yang ada
sekarang.
Fase Analisis Kebutuhan (Requirement Analysis Phase) : Fase ini merupakan
fase untuk melakukan pengumpulan data kebutuhan. Hasil dari tahap ini
direpresentasikan dengan use – case diagram dan use-case narative.
Fase Desain Logikal (Logical Design Phase) : Dalam fase ini business
requirement yang ada diterjemahkan dalam bentuk gambar-gambar. Pada
tahap ini menggunakan diagram aktivitas untuk menggambarkan proses
bisnis, langkah–langkah use case, dan logika perilaku obyek. Selain itu, tahap
ini menggunakan ER-Diagram dan Class Diagram sebagai system modelnya.
Desain Fisikal dan Integrasi (Physical Design and Integration) : Fase ini
merupakan tahap perancangan sistem secara fisik berupa sequence diagram ,
class diagram lengkap, Perancangan database, dan desain User interface.
Konstruksi dan Percobaan Construction and Testing (Construction and
Testing) : Fase ini merupakan tahap pembangunan sistem berdasarkan
rancangan yang telah dibuat pada tahap desain fisikal, kemudian menguji komponen-komponen sistem tersebut dengan melakukan pengisian kuisioner kepada beberapa user.
2.4. PHP
PHP merupakan bahasa standar yang digunakan dalam dunia website. PHP adalah bahasa program yang berbentuk script yang diletakkan di dalam server web. Jika kita lihat dari sejarah, mulanya PHP diciptakan dari ide Rasmus Lerdof yang membuat sebuah script perl. Script tersebut sebenarnya dimaksudkan untuk digunakan sebagai program untuk dirinya sendiri. Akan tetapi, kemudian dikembangkan lagi sehingga menjadi sebuah bahasa yang disebut “Personal Home Page”. Inilah awal mulanya PHP sampai saat ini.
PHP telah dicipta terutama untuk kegunaan web dan boleh menghubungkan query database dan menggunakan simple task yang boleh diluruskan dengan 3 atau 4 baris kod saja. PHP adalah bahasa programming yang baru dibangun sekitar tahun 1994/1995. Malah pengunaannya masih baru di Malaysia dan sedang meningkat
popular kegunaannya. PHP dapat menukarkan static website yang menggunakan
HTML ke dynamic web pages yang berfungsi secara automatic seperti ASP< CGI,
dan sebagainya.
Hampir seluruh aplikasi berbasis web dapat dibuat dengan PHP ini, namun fungsi PHP yang paling utama adalah untuk menghubungkan database dengan web. Dengan PHP, membuat aplikasi web yang terkoneksi ke database menjadi sangat mudah. System database yang telah didukung oleh PHP adalah:
Oracle
mSQL MySQL Solid Generic ODBC PostgresSQL 2.5. MySQL
MySQL merupakan suatu software manajement database. Sistem manajemen
database dapat dilakukan penambahan, pengaksesan, dan pemrosesan data yang
diakses di komputer. MySQL menggunakan standar SQL. MySQL dapat digunakan
untuk melakukan pembuatan database, tabel, view. (MySQL 5.1 Manual).
Query Language
Query Language adalah pernyataan yang diajukan untuk mengambil
informasi. Merupakan bagian Data Manipulation Language (DML) untuk
pengambilan informasi. DML digunakan untuk menampilkan, menambah, mengubah dan menghapus dan menghapus data didalam objek-objek yang didefinisikan oleh
Data Definition Language (DDL). Perintah yang terdapatan pada DML adalah select,
BAB III
ANALISIS & PERANCANGAN SISTEM
3.1. Fase Definisi Ruang Lingkup (Scope Definition Phase )
Pengelolaan data umat Vihara Bodhicitta Maitreya Yogyakarta di jalan Kemetiran No. 9 masih dilakukan secara manual. Data umat hanya disimpan dalam bentuk dokumen-dokumen berupa kertas. Pintu Vihara dibuka dari jam 06.00 pagi sampai 22.00 malam, jadi biarawan harus menangani umat seorang diri karena keterbatasan tenaga biawaran-biarawati. Pengelolaan data umat secara manual ini mengakibatkan berbagai kesulitan, seperti kelambatan pelayanan dan informasi, penginputan data yang salah dan sebagainya.
Dari permasalahan – permasalahan tersebut di atas, diperoleh bahwa
pembuatan Aplikasi Pengolahan Data Umat perlu dilakukan untuk meningkatkan mutu pelayanan umat, serta memudahkan pimpinan Vihara melihat perkembangan kondisi dan keadaan umat yang ada di Yogyakarta dan memudahkan administrator untuk membuat laporan perkembangan umat selama beberapa bulan atau pun tahunan.
Performance : Sistem pengelolaan data – data umat yang masih bersifat manual, sehingga administrator kesulitan dalam pembuatan laporan-laporan yang dibutuhkan oleh pimpinan Vihara untuk dilaporkan ke Vihara pusat.
Information : Dalam sistem yang ada saat ini, informasi yang berkaitan dengan data umat dan laporan tidak bisa langsung disajikan, sehingga jika ada yang ingin meminta data tersebut harus menunggu beberapa jam kemudian.
Control : Keakuratan data pada sistem yang ada saat ini belum begitu terjamin. Ketika ingin membuat laporan, harus dibandingkan terlebih dahulu antara data yang telah disimpan dibuku dengan laporan yang akan dibuat. Proses penyimpanan data umat tidak aman. Karena data-data umat hanya disimpan dalam bentuk buku, kemungkinan kehilangan data sangat besar.
Eficiency : Dalam hal waktu, sistem yang ada saat ini membutuhkan banyak waktu untuk menyimpan dan memperoleh informasi data umat, pembuatan surat pemberkatan perkawinan dan pembuatan laporan.
Services : Pelayanan pada umat atau instansi yang ingin meminta informasi data umat kadang tidak optimal karena masih menggunakan sistem yang manual.
3.2. Fase Analisis Masalah (Problem Analysis Phase)
3.2.1. Sistem Yang Ada Saat Ini.
Sistem pengolahan data umat Vihara Bodhicitta masih dilakukan
secara manual. Data umat hanya disimpan dalam bentuk dokumen – dokumen
tersebut, administrator akan mengisi data diri yang berkaitan tentang umat tersebut di dokumen umat.
Aplikasi Pengolahan
Data Umat
Umat
Admin Data Umat Data Umat
Informasi Data Umat
Informasi Data Umat Laporan
Surat Pemberkatan Perkawinan
Gambar 3.1 Diagram Konteks
3.2.2. Sebab dan Akibat (Cause and Effect)
Tabel 3.1. Tabel Sebab Akibat (Cause and Effect)
Proyek: Aplikasi Pengolahan Data Umat
Manajer Proyek: Roby Hasan
Dibuat oleh: Roby Hasan Diperbarui terakhir oleh: Roby Hasan
Dibuat tanggal: Diperbarui terakhir tanggal:
Analisa Sebab dan Akibat Perbaikan Obyek Sistem
Masalah Sebab dan akibat Tujuan Sistem Batasan Sistem
1. Proses penyimpanan Data tidak aman. 1. Data-data umat masih disimpan dalam bentuk buku sehingga 1. Membantu mengurangi resiko kehilangan data dan menjamin data
1. Diperlukan update data secara berkala agar data ter-update.
2. Proses pencarian data umat masih lama. kemungkinan kehilangan data sangat besar. 2. Pengelolaan data
umat yang masih secara manual sehingga pencarian data umat harus dilakukan dengan mengecek setiap dokumen yang ada. disimpan dengan aman dengan menggunakan suatu aplikasi yang menggunakan database. 2. Menjadikan proses pencarian data lebih cepat dan efisien.
3.2.3. Gambaran Sistem Baru
Untuk menangani masalah – masalah di atas, maka akan dibuat sistem
baru yaitu Aplikasi Pengolahan Data Umat Vihara Bodhicitta Maitreya. Sistem ini digunakan untuk mengelola data umat. Selain itu sistem ini juga bertujuan untuk memberi informasi data diri umat dan membantu membuat laporan, seperti laporan pendhiksaan umat per tahun. Sistem ini akan menerapkan
teknologi basis data. Sistem ini akan di install pada komputer yang ada di Vihara Bodhicitta Maitreya.
Dalam sistem yang baru ini, jika pengguna (administrator) akan menggunakan sistem, pengguna harus login terlebih dahulu. Kemudian sistem akan mengecek apakah pengguna berhak atau tidak. Pada sistem ini, pengguna
hanya mengisikan data sesuai dengan form yang ada dalam sistem. Setelah itu
sistem akan memprosesnya secara otomatis dan data semua akan tersimpan dalam basis data.
Orang Yang Terlibat Dalam Sistem 1. Administrator (biarawan) / User
Biarawan adalah orang yang akan mengelola data umat, yaitu menyimpan, mengedit dan menghapus data umat.
2. Umat
Umat adalah orang yang data dirinya akan disimpan dan dikelola dalam sistem.
3.3. Fase Analisis Kebutuhan (Decision Analysis Phase) 3.3.1 Diagram Use Case
Berikut ini merupakan diagram use case sistem. LOGIN
Biarawan (Admin)
Mengedit Data Umat
Membuat & Mencetak Laporan Perkembangan Umat LOGOUT <<depends on>> Menambah Data Umat Mencari Data Umat Menambah Data User Mengedit Data User Menghapus Data User User
Mencetak Surat Pemberkatan Perkawinan Menambah Daftar Data
Perkawinan
Membatalkan Daftar Data Perkawinan Menambah Data Perkawinan Menambah Data Pandita Menambah Data Vihara Men-sah-kan Data Perkawinan
3.3.2. Ringkasan Use case.
Table 3.2 Tabel Ringkasan Use Case.
Berikut adalah Ringkasan dari use case diatas :
Nama Use Case Deskripsi Use Case Pelaku Yang
Berpartisipasi
Login Use case ini
menggambarkan proses masuk ke sistem.
Admin, User
Mencari data umat Use case ini
menggambarkan proses pencarian data umat
Admin, User
Menambah data umat Use case ini
menggambarkan proses penambahan data umat
Admin, User
Mengedit data umat Use case ini
menggambarkan proses pengeditan data umat
Admin, User
Menambah data pandita Use case ini
menggambarkan proses penambahan data pandita
Admin, User
Menambah data Vihara Use case ini
menggambarkan proses
penambahan data Vihara Menambah daftar data
perkawinan
Use case ini
menggambarkan proses penambahan daftar data perkawinan
Admin, User
Men-sah-kan data perkawinan
Use case ini
menggambarkan proses men-sah-kan data perkawinan
Admin, User
Membatalkan daftar data perkawinan
Use case ini
menggambarkan proses membatalkan data perkawinan Admin, User Menambah data perkawinan
Use case ini
menggambarkan proses penambahan data perkawinan
Admin, User
Menambah data user Use case ini
menggambarkan proses penambahan data user
Admin
Mengedit data user Use case ini
menggambarkan proses
pengeditan data user
Menghapus data user Use case ini
menggambarkan proses penghapusan data user
Admin
Mencetak surat perkawinan
Use case ini
menggambarkan proses pencetakan surat
pemberkatan perkawinan umat
Admin, User
Membuat dan mencetak laporan perkembangan umat
Use case ini
menggambarkan proses pembuatan laporan perkembangan umat
Admin, User
Logout Use case ini
menggambarkan proses keluar dari sistem
3.3.3 Narasi Use Case (Use case Narative)
A. Narasi Use CaseLogin
Author : Roby Hasan Date : 23 Agustus 2010
Version : 1.0
Nama Use Case: Login Jenis Use case
Business Requirements:
Use Case ID: RM-001
Prioritas: High
Sumber: -
Aktor Bisnis
Primer:
Admin (Biarawan), User
Aktor Lain Yang Terlibat:
-
Stakeholder Lain:
-
Deskripsi: Use case ini menggambarkan proses untuk masuk ke sistem. Use
case ini berguna untuk menjaga privileges.
Kondisi Awal: Admin telah memiliki password
Pemicu: Use case ini digunakan apabila admin ingin masuk ke dalam
sistem.
Urutan Normal
Aktifitas:
Aksi Aktor Respon Sistem
Step 1: Admin membuka halaman login.
Step 2: Sistem meminta
Step 3: Admin memasukkan username dan password, lalu menekan tombol ”LOGIN”.
Password.
Step 4: Sistem mengecek validasi di database.
Step 5: Sistem masuk ke menu Utama.
Aktifitas Lain: Alt-step 4: Jika username dan password yang dimasukkan tidak
sesuai maka sistem akan memberikan peringatan.
Kesimpulan: Admin dapat masuk ke dalam sistem.
Kondisi Akhir: • Admin berhasil login dan masuk ke menu utama.
• Admin tidak jadi masuk ke sistem.
Prosedur Bisnis: Admin harus memasukan username dan password dengan benar
Batasan Implementasi dan Spesifikasi:
• Harus dapat diakses setiap saat.
B. Narasi Use Case Mencari Data Umat
Author : Roby Hasan Date : 23 Agustus 2010
Version : 1.0
Nama Use Case: Mencari Data Umat Jenis Use case
Business Requirements:
Use Case ID: RM-002
Prioritas: High
Sumber: -
Aktor Bisnis
Primer:
Admin(Biarawan), User
Aktor Lain Yang Terlibat:
-
Stakeholder Lain:
-
Deskripsi: Use case ini menggambarkan proses pencarian data diri umat
Kondisi Awal: Admin telah berada di halaman Data Umat
Pemicu: Use case ini digunakan apabila Admin ingin mencari data umat
Urutan Normal
Aktifitas:
Aksi Aktor Respon Sistem
Step 1: Admin memilih memilih menu Data Umat.
Step 3: Admin memilih kategori pencarian dan memasukkan
Step 2: Sistem menampilkan halaman Data Umat.
Step 4: Sistem mencari data ke Database.
kata kunci, lalu menekan
tombol “Tampil”. Step 5: Sistem menampilkan
data sesuai kategori yang diinginkan.
Aktifitas Lain: Alt-step 4a: data yang dicari tidak ada dalam database
Alt-step 4b: sistem menampilkan pesan tidak ada .
Kesimpulan: Admin Dapat mencari data umat.
Kondisi Akhir: • Jika berhasil maka sistem akan menampilkan data yang ada
dalam database.
• Jika tidak berhasil maka sistem akan memberi pesan gagal/kembali ke menu utama.
Prosedur Bisnis: Admin harus memasukan data dengan tipe yang sesuai.
Batasan