BAB II LANDASAN TEORI
2.3 Konsep Logika Fuzzy
2.3.4 Operator Dasar Zadeh untuk Operasi Himpunan Fuzzy
Seperti halnya himpunan konvensional, ada beberapa operasi yang didefinisikan secara khusus untuk mengkombinasi dan memodifikasi himpunan fuzzy. Nilai keanggotaan sebagai hasil dari operasi 2 himpunan sering dikenal dengan nama fire strength atau α-predikat. Ada 3 operator dasar yang diciptakan oleh Zadeh, yaitu (Cox dalam Kusumadewi dan Hari, 2010:23)
1. Operator AND
Operator ini berhubungan dengan operasi interseksi pada himpunan. α-predikat sebagai hasil operasi dengan operator AND diperoleh dengan mengambil nilai keanggotaan terkecil antarelemen pada himpunan-himpunan yang bersangkutan.
2. Operator OR
Operator ini berhubungan dengan operasi union pada himpunan. α-predikat sebagai hasil operasi dengan operator OR diperoleh dengan mengambil nilai keanggotaan terbesar antarelemen pada himpunan-himpunan yang bersangkutan.
3. Operator NOT
UIN Syarif Hidayatullah Jakarta
Operator ini berhubungan dengan operasi komplemen pada himpunan. α-predikat sebagai hasil operasi dengan operator NOT diperoleh dengan mengurangkan nilai keanggotaan elemen pada himpunan yang bersangkutan dari 1.
2.3.5 Penalaran Monoton
Metode penalaran secara monoton digunakan sebagai dasar untuk teknik implikasi fuzzy. Meskipun penalaran ini sudah jarang sekali digunakan, namun terkadang mash digunakan untuk penskalaaan fuzzy. Jika 2 daerah fuzzy direlasikan dengan implikasi sederhana sebagai berikut (Cox dalam Kusumadewi dan Hari, 2010:25):
IF x is A THEN y is B Transfer fungsi:
maka sistem fuzzy dapat berjalan tanpa harus melalui komposisi dan dekomposisi fuzzy. Nilai output dapat diestimasi secara langsung dari nilai keanggotaan yang berhubungan dengan antesedennya.
2.3.6 Sistem Inferensi Fuzzy
Sistem Inferensi Fuzzy (Fuzzy Inference System atau FIS) merupakan suatu kerangka komputasi yang didasarkan pada teori himpunan fuzzy, aturan fuzzy berbentuk IF-THEN, dan penalaran
UIN Syarif Hidayatullah Jakarta
fuzzy. Secara garis besar, diagram blok proses inferensi fuzzy terlihat pada gambar
Sistem inferensi fuzzy menerima input crisp. Input ini kemudian dikirim ke basis pengetahuan yang berisi n aturan fuzzy dalam bentuk IF-THEN. Fire strength akan dicari pada setiap aturan.
Apabila jumlah aturan lebih dari satu, maka akan dilakukan agregasi dari semua aturan. Selanjutnya, pada hasil agregasi akan dilakukan defuzzy untuk mendapatkan nilai crisp sebagai output sistem.
(Kusumadewi dan Sri, 2010)
2.3.7 Sistem Inferensi Fuzzy Metode Tsukamoto
Metode Tsukamoto merupakan perluasan dari penalaran monoton. Pada metode Tuskamoto, setiap konsekuen pada aturan yang berbentuk IF-THEN harus direpresentasikan dengan suatu himpunan fuzzy dengan fungsi keanggotaan yang monoton. Sebagai hasilnya, output hasil inferensi dari tiap-tiap aturan diberikan secara tegas (crisp) berdasarkan α-predikat (fire strength). Hasil akhirnya diperoleh dengan menggunakan rata-rata terbobot. (Kusumadewi dan Hari, 2010:31)
Dalam inferensinya, metode Tsukamoto menggunakan tahapan berikut: (T. Sutojo, 2011)
1. Fuzzyfikasi, yang meliputi:
 Penentuan variabel fuzzy
 Penentuan domain himpunan fuzzy
UIN Syarif Hidayatullah Jakarta
2. Pembentukan basis pengetahuan Fuzzy (Rule dalam bentuk IF…THEN)
3. Mesin inferensi, yang meliputi:
 Menghitung Derajat Keanggotaan/Membership Function (µ)
 Mencari α-predikat dan Nilai crisp pada tiap Aturan
Menggunakan fungsi implikasi MIN untuk mendapatkan nilai α-predikat tiap-tiap rule (α1, α2, α3,… αn).
Kemudian masing-masing nilai α-predikat ini digunakan untuk menghitung output hasil inferensi secara tegas (crisp) masing-masing rule (z1, z2, z3, … zn)
4. Defuzzyfikasi, menggunakan metode rata-rata (Average)
2.4 Metodologi Penelitian
2.4.1 Metode Pengumpulan Data
Metode pengumpulan data ialah teknik atau cara-cara yang dapat digunakan oleh peneliti untuk mengumpulkan data. Metode (cara atau teknik) menunjukkan suatu kata yang abstrak dan tidak diwujudkan dalam benda, tetapi hanya dapat diperlihatkan penggunaanya melalui: angket, wawancara, pengamatan, ujian (tes), dokumentasi, dan lainnya. Peneliti dapat menggunakan salah satu atau gabungan, tergantung pada masalah yang dihadapi (Suryo dkk., 2011:125).
UIN Syarif Hidayatullah Jakarta
1. Studi Pustaka
Studi Pustaka adalah kegiatan mengkaji teori-teori yang mendasari penelitian, baik teori berkenaan dengan bidang ilmu yang diteliti maupun metodologi. Studi Pustaka mengkaji pula hal-hal bersifat empiris yang bersumber dari temuan-temuan penelitian terdahulu (Suryo dkk., 2011:18).
2. Wawancara
Wawancara adalah teknik pengumpulan kebutuhan yang paling umum digunakan. Langkah-langkah dasar dalam teknik wawancara adalah:
a. Memilih target wawancara
b. Mendesain pertanyaan-pertanyaan untuk wawancara c. Persiapan wawancara
d. Melakukan wawancara
e. Menindak lanjuti hasil wawancara
Wawancara adalah metode yang paling mudah digunakan, jika sistem yang dianalisis tidak terlalu besar (Al Fatta, 2007:69).
Pengumpulan data dengan menggunakan wawancara mempunyai beberapa keuntungan sebagai berikut (Rosa dan Shalahuddin, 2011):
a. Lebih mudah dalam menggali bagian sistem mana yang dianggap baik dan bagian mana yang dianggap kurang baik.
UIN Syarif Hidayatullah Jakarta
b. Jika ada bagian tertentu yang perlu digali lebih dalam, dapat langsung menanyakan kepada narasumber.
c. Dapat menggali kebutuhan user secara bebas.
d. User dapat mengungkapkan kebutuhannya secara lebih bebas.
Selain mempunyai kelebihan tersebut, teknik wawancara juga mempunyai beberapa kelemahan. Berikut ini adalah beberapa kelemahan dari teknik wawancara (Rosa dan Shalahuddin, 2011):
a. Wawancara akan sulit dilakukan jika narasumber kurang dapat mengungkap kebutuhannya.
b. Pertanyaan dapat menjadi tidak terarah, terlalu fokus pada hal-hal tertentu dan mengabaikan bagian lainnya.
2.4.2 Metode Pengembangan Perangkat Lunak
Pada pengembangan aplikasi dalam penelitian ini penulis menggunakan metode RAD (Rapid Application Development).
2.5 RAD (Rapid Application Development)
2.5.1 Pengertian RAD (Rapid Application Development)
Rapid Application Development (RAD) adalah strategi siklus hidup yang ditujukan untuk menyediakan pengembangan yang jauh lebih cepat dan mendapatkan hasil dengan kualitas yang lebih baik dibandingkan dengan hasil yang dicapai melalui siklus tradisional (McLeod, 2002). RAD merupakan gabungan dari bermacam-macam teknik terstruktur dengan teknik prototyping dan teknik
UIN Syarif Hidayatullah Jakarta
pengembangan joint application untuk mempercepat pengembangan sistem/aplikasi (Bentley, 2004). Dari definisi-definisi konsep RAD ini, dapat dilihat bahwa pengembangan aplikasi dengan menggunakan metode RAD ini dapat dilakukan dalam waktu yang relatif lebih cepat.
Pemaparan konsep yang lebih spesifik lagi dijelaskan oleh Pressman (2005) dalam bukunya,“Software Engineering: A Practition’s Approach”. Ia mengatakan bahwa RAD adalah proses model perangkat lunak inkremental yang menekankan siklus pengembangan yang singkat. Model RAD adalah sebuah adaptasi
“kecepatan tinggi” dari model waterfall, di mana perkembangan pesat dicapai dengan menggunakan pendekatan konstruksi berbasis komponen. Jika tiap-tiap kebutuhan dan batasan ruang lingkup projek telah diketahui dengan baik, proses RAD memungkinkan tim pengembang untuk menciptakan sebuah “sistem yang berfungsi penuh” dalam jangka waktu yang sangat singkat. Dari penjelasan Pressman (2012) ini, satu perhatian khusus mengenai metodologi RAD dapat diketahui, yakni implementasi metode RAD akan berjalan maksimal jika pengembang aplikasi telah merumuskan kebutuhan dan ruang lingkup pengembangan aplikasi dengan baik.
Sedangkan menurut Kendall (2010), RAD adalah suatu pendekatan berorientasi objek terhadap pengembangan sistem yang mencakup suatu metode pengembangan serta perangkat-perangkat lunak. RAD bertujuan mempersingkat waktu yang biasanya diperlukan
UIN Syarif Hidayatullah Jakarta
dalam siklus hidup pengembangan sistem tradisional antara perancangan dan penerapan suatu sistem informasi. Pada akhirnya, RAD sama-sama berusaha memenuhi syarat-syarat bisnis yang berubah secara cepat.
Gambar 2.2 Workflow perancangan model RAD 2.5.2 Tahapan Model Proses RAD
Tahap-tahap model RAD dapat dijelaskan secara ringkas sebagai berikut:
1. Perencanaan Syarat-syarat
Dalam fase ini, pengguna dan penganalisis bertemu untuk mengidentifikasikan tujuan-tujuan aplikasi atau sistem serta untuk mengidentifikasi syarat-syarat informasi yang ditimbulkan dari tujuan-tujuan tersebut. Fase ini memerlukan peran aktif mendalam dari kedua kelompok tersebut, tidak hanya menunjukkan proposal atau dokumen. Selain itu, juga melibatkan pengguna dari beberapa level yang berbeda dalam organisasi. Orientasi dalam fase ini ialah
UIN Syarif Hidayatullah Jakarta
menyelesaikan problem-problem perusahaan. Meskipun teknologi informasi dan sistem bisa mengarahkan sebagian dari sistem yang diajukan, fokusnya akan selalu tetap pada upaya pencapaian tujuan-tujuan perusahaan.
2. Workshop Desain
Fase ini adalah fase untuk merancang dan memperbaiki yang bisa digambarkan sebagai workshop. Selama workshop desain, pengguna merespon working prototype yang ada dan penganalisis memperbaiki modul-modul yang dirancang berdasarkan respon pengguna.
3. Implementasi
Penganalisis bekerja dengan para pengguna secara intens selama workshop untuk merancang aspek-aspek bisnis dan nonteknis dari perusahaan. Segera sesudah aspek-aspek ini disetujui dan sistem-sistem dibangun dan disaring, sistem-sistem-sistem-sistem baru atau bagian dari sistem diuji coba dan kemudian diperkenalkan kepada organisasi.
2.6 UML (Unified Modelling System) 2.6.1 Pengertian UML
Menurut Munawar (2005:17) UML (Unified Modeling Languagei) adalah salah satu alat bantu yang sangat handal di dunia pengembangan sistem yang berorientasi objek. Menurut Widodo (2011:5) UML bukan hanya sekedar diagram tetapi juga menceritakan
UIN Syarif Hidayatullah Jakarta
konteksnya. UML pertama kali dikenalkan pada tahun 1994 oleh three amigos, yaitu : Jim Rumbergh, Grady Booch, dan Ivar Jacobson.
Mereka menggabungkan ide-ide mereka untuk membangun notasi standar OOP untuk Software Rational IBM.
Pendekatan UML memiliki nilai yang sangat baik dalam penyelidikan dan penelitian. Perangkat UML distandarkan sebagai peralatan untuk dokumen analisis dan perancangan dari sistem perangkat lunak. Peralatan UML termasuk diagram yang memberikan gambaran seseorang untuk menampilkan konstruksi dari sebuah sistem berorientasi objek.
UML sendiri juga memberikan standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis proses, penulisan kelas-kelas dalam bahas program yang spesifik, skema database, dan komponen-komponen yang diperlukan dalam perangkat lunak.
UML diaplikasikan untuk maksud tertentu, biasanya untuk:
1. Merancang perangkat lunak.
2. Sarana komunikasi antara perangkat lunak dengan proses bisnis.
3. Menjabarkan sistem secara rinci untuk analisis dan mencari apa yang diperlukan sistem.
4. Mendokumentasikan sistem yang ada, proses-proses dan organisasinya.
2.6.2 Diagram-diagram UML
UIN Syarif Hidayatullah Jakarta
Ada beberapa diagram yang disediakan dalam UML antara lain:
1. Diagram use case (use case diagram) 2. Diagram aktivitas (activity diagram) 3. Diagram sekuensial (sequence diagram) 4. Diagram kolaborasi (collaboration diagram) 5. Diagram kelas (class diagram)
6. Diagram statechart (statechart diagram) 7. Diagram komponen (component diagram) 8. Diagram deployment (deployment diagram)
Dalam penelitian ini, penulis menggunakan use case diagram, activity diagram, sequence diagram, dan class diagram.
2.6.2.1 Use Case Diagram
Diagram Use case bersifat statis. Diagram ini memperlihatkan himpunan use-case dan aktor-aktor (suatu jenis khusus dari kelas). Diagram ini sangat penting untuk mengorganisasi dan memodelkan prilaku suatu sistem yang dibutuhkan serta diharapkan pengguna (Widodo, 2011:10).
Use case bekerja dengan cara mendeskripsikan tipikal interaksi antar user (pengguna) sebuah sistem dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah sistem dipakai (Munawar, 2005:63).
UIN Syarif Hidayatullah Jakarta
Pooley (2003:15) mengatakan bahwa model use case dapat dijabarkan dalam diagram use case, tetapi yang perlu diingat, diagram tidak identik dengan model, karena model lebih luas dari diagram.
Menurut Widodo (2011:16) Diagram use case memiliki tiga komponen yang merincikan diagram use case tersebut, yaitu:
a. Aktor (actor), menggambarkan pihak-pihak yang berperan dalam sistem.
b. Use case, aktivitas/sarana yang disiapkan oleh bisnis/sistem.
c. Hubungan (link), aktor mana saja yang terlibat dalam use case tersebut.
Di dalam use case terdapat teks untuk menjelaskan urutan kegiatan yang disebut use case spesification, yang terdiri dari:
a. Nama Use case
Mencantumkan nama dari use case yang bersangkutan.
Sebaiknya di awali dengan kata kerja untuk menunjukkan suatu aktivitas.
b. Deskripsi Singkat (brief description)
Menjelaskan secara singkat dalam satu atau dua kalimat tentang tujuan dari use case tersebut.
UIN Syarif Hidayatullah Jakarta
c. Aliran Normal (basic flow)
Ini adalah inti dari use case. Menjelaskan interaksi antara aktor dan sistem. Dalam kondisi normal, yaitu segala sesuatu berjalan baik, tanpa halangan atau hambatan dalam mencapai tujuan.
d. Aliran Alternatif (alternative flow)
Merupakan perlengkapan dari basic flow karena tidak ada yang sempurna dalam setiap kali use case berlangsung.
Di dalam alternative flow dijelaskan apa yang terjadi bila suatu halangan terjadi sewaktu use case berlangung.
e. Kondisi Sebelum (pre-condition)
Menjelaskan persyaratan yang harus dipenuhi sebelum use case di mulai.
f. Kondisi Sesudah (post-condition)
Menjelaskan kondisi yang berubah atau terjadi saat use case selesai di eksekusi.
2.6.2.2 Activity Diagram
Activity Diagram adalah tipe khusus dari diagram status yang memperlihatkan aliran dari suatu aktivitas ke aktivitas lainnya dalam suatu sistem. Diagram ini terutama penting dalam pemodelan fungsifungsi suatu sistem dan memberi tekanan pada aliran kendali antar objek (Widodo, 2011:11).
UIN Syarif Hidayatullah Jakarta
Diagram aktivitas lebih memfokuskan diri pada ekesekusi dan alur sistem dari pada bagaimana sistem itu dirakit. Diagram mempunyai peran seperti halnya flowchart, akan tetapi perbedaannya dengan flowchart adalah activity diagram bisa mendukung prilaku paralel, sedangkan flowchart tidak bisa (Munawar, 2005:109).
2.6.2.3 Sequence Diagram
Sequence Diagram berarti Diagram Urutan, diagram urutan adalah diagram interaksi yang menekankan pada pengiriman pesan dalam suatu waktu tertentu (Widodo, 2011:11). Diagram urutan merupakan salah satu dari pemodelan skenario interaksi pada UML. Diagram Urutan bersifat dinamis.
Menurut Munawar (2005:87) sequence diagram digunakan untuk menggambarkan perilaku pada sebuah scenario.
Anggota interaksi digambarkan dengen persegi panjang yang diberi nama garis hidup (lifeline). Anggota interaksi digambarkan dengan garis putus-putus dari persegi panjang turun ke bawah yang memperlihatkan berapa lama objek eksis dalam diagram (Widodo, 2011:175).
2.6.2.4 Class Diagram
UIN Syarif Hidayatullah Jakarta
Class Diagram memperlihatkan himpunan kelas-kelas, antarmuka-antarmuka, kolaborasi-kolaborasi, serta relasi-realasi. Diagrami ini umum dijumpai pada pemodelan sistem berorientasi objek (Widodo, 2011:10). Secara teknis, (Pender, 2003:bab5) mengartikan sebuah kelas sebagai suatu definisi sumber daya yang termasuk di dalam informasi-informasi yang menggambarkan fitur suatu entitas dan bagaimana penggunaannya. Sedangkan objek adalah entitas yang bersifat unik yang megikuti aturan-aturan yang sudah didefinisikan dalam kelasnya (Widodo, 2011:39)
Menurut Munawar (2005:219) class diagram bisa memberikan pandangan global atas sebuah sistem. Hal tersebut tercermin dari kelas-kelas yang ada relasinya satu dengan lainnya. Itulah sebabnya class diagram menjadi diagram paling populer di UML.
2.7 Basis Data
2.7.1 Konsep Basis Data
Basis Data terdiri atas 2 kata, yaitu Basis dan Data. Basis kurang lebih dapat diartikan sebagai markas atau gudang, tempat bersarang/berkumpul. Sedangkan Data adalah representasi fakta dunia nyata yang mewakili suatu ojek seperti manusia (pegawai, siswa, pembeli, pelanggan), barang, hewan, peristiwa, konsep, keadaan, dan
UIN Syarif Hidayatullah Jakarta
sebagainya, yang direkam dalam bentuk angka, huruf, simbol, teks, gambar, bunyi, atau kombinasinya. Basis Data sendiri dapat didefinisikan dalam sejumlah sudut pandang seperti (Fathansyah, 2007):
 Himpunan kelompok data (arsip) yang saling berhubungan yang
diorganisasi sedemikian rupa agar kelak dapat dimanfaatkan kembali dengan cepat dan mudah.
 Kumpulan data yang saling berhubungan yang disimpan secara
bersama sedemikian rupa dan tanpa pengulangan (redundansi) yang tidak perlu , untuk memenuhi berbagai kebutuhan.
 Kumpulan file/tabel/arsip yang saling berhubungan yang disimpan
dalam media penyimpanan elektronis.
Basis Data dan lemari arsip sesungguhnya memiliki prinsip kerja dan tujuan yang sama. Prinsip utamanya adalah pengaturan data/arsip. Dan tujuan utamanya adalah kemudahan dan kecepatan dalam pengambilan kembali data/arsip. Perbedaannya hanya terletak pada media penyimpanan yang digunakan. Jika lemari arsip menggunakan lemari dari besi atau kayu sebagai media penyimpanan, maka basis data menggunakan media penyimpanan elektronis seperti disk. Hal ini merupakan konsekuensi yang logis karena lemari arsip langsung dikelola/ditangani melalui perantaraan alat/mesin pintar elektronis (yang kita kenal sebagai komputer). Perbedaan media ini yang selanjutnya melahirkan perbedaan-perbedaan lain yang
UIN Syarif Hidayatullah Jakarta
menyangkut jumlah dan jenis metoda/cara yang dapat digunakan dalam upaya penyimpanan. (Fathansyah, 2007)
Satu hal yang juga harus diperhatikan, bahwa basis data bukan hanya sekedar penyimpanan data secara elektronis (dengan bantuan komputer). Artinya, tidak semua bentuk penyimpanan data secara elektronis bisa disebut basis data. Kita dapat menyimpan dokumen berisi data dalam file teks (dengan program pengolah kata), file spread sheet, dan lain-lain, tetapi tidak bisa disebut sebagai basis data. Karena di dalamnya tidak ada pemilahan dan pengelompokkan data sesuai jenis/fungsi data, sehingga akan menyulitkan pencarian data kelak.
Yang sangat ditonjolkan dalam basis data adalah pengaturan/pemilahan/pengelompokkan/pengorganisasian data yang akan kita simpan sesuai fungsi/jenisnya.
Pemilahan/pengelompokkan/pengorganisasian ini dapat berbentuk sejumlah file/tabel terpisahatau dalam bentuk pendefinisian kolom-kolom/field-field data dalam setiap file/tabel. (Fathansyah, 2007)
Menurut Simarmata (2009), basis data biasanya memiliki dua bagian utama. Pertama, file yang memegang basis data fisik. Kedua, perangkat lunak sistem manajemen basis data (DBMS) menggunakan aplikasi untuk mengakses data. DBMS bertanggung jawab menguatkan struktur basis data, termasuk:
 Memelihara hubungan antardata di dalam basis data.
UIN Syarif Hidayatullah Jakarta
 Memastikan bahwa data tersimpan secara tepat, dan menetapkan aturan hubungan data agar tidak dilanggar.
 Pemulihan (recovery) semua data dari kegagalan sistem.
2.8 Java
Bahasa Java merupakan karya Sun Mycrosystem Inc. Rilis resmi level beta dilakukan pada November 1995. Dua bulan berikutnya Netscape menjadi perusahaan pertama yang memperoleh lisensi bahasa Java dari Sun.
Sebagian besar bahasa pemograman modern berdiri diatas pustaka-pustaka kelas yang telah ada untuk mendukung fungsionalitas. Pada bahasa Java, kelompok-kelompok kelas yang berkaitan erat dimasukkan di satu paket, bervariasi sesuai edisi Java. Masing-masing paket untuk maksud tertentu: applet, aplikasi standar, skala enterprise, dan produk konsumer.
Java adalah bahasa yang dapat dijalankan di semabarang platform, di beragam lingkungan: internet, consumer electronic products, dan computer applications. The Java 2 Platform tersedia dalam tiga edisi untuk keperluan berbeda berikut: (Hariyanto, 2011)
a. Java 2 Standard Edition (J2SE), b. Java 2 Enterprise Edition (J2EE), c. Java 2 Micro Edition (J2ME).
UIN Syarif Hidayatullah Jakarta
2.9 Pengujian Perangkat Lunak
Pengujian sistem adalah bagian dari siklus hidup tersebut yang melibatkan verifikasi apakah setiap unit yang dikembangkan telah memenuhi kebutuhan sistem yang didefinisikan pada tahapan sebelumnya.
Pengujian sistem sering diasosiasikan dengan pencarian bug, ketidaksempurnaan program, kesalahan pada baris program yang menyebabkan kegagalan pada eksekusi sistem perangkat lunak (Al Fatta, 2007:169). Dalam penelitian ini penulis menggunakan pengujian metode black box.
2.9.1 Pengujian Metode Black Box
Menurut Al Fatta (2007: 172) pengujian Black Box terfokus pada apakah unit program memenuhi kebutuhan (requirement) yang disebutkan dalam spesifikasi. Pada pengujian Black Box, cara pengujian hanya dilakukan dengan menjalankan atau mengeksekusi unit atau modul, kemudian diamati apakah hasil dari unit itu sesuai dengan proses yang dinginkan.
Klasifikasi Pengujian Black Box
Simarmata (2010: 316) mengkasifikasikan pengujian Black Box menjadi 15, yakni: pengujian fungsional (functional testing), pengujian tegangan (stress testing), pengujian beban (load testing), pengujian khusus (ad-hoc testing), pengujian penyelidikan (exploratory testing), pengujian usabilitas (usability testing), pengujian asap (smoke testing), pengujian pemlihan (recovery testing), pengujian volume (volume
UIN Syarif Hidayatullah Jakarta
testing), pengujian domain (domain testing), pengujian skenario (scenario testing), pengujian regresi (regression testing), penerimaan pengguna (user acceptance), pengujian alfa (alpha testing), pengujian beta (beta testing).
Dalam melakukan pengujian black box pada penelitian ini, penulis menggunakan pengujian fungsional (functional testing), pengujian scenario (scenario testing), dan pengujian kelayakan (user acceptance testing).
Pengujian Fungsional (Functional Testing)
Pada pengujian ini, perangkat lunak diuji untuk persyaratan fungsional. Pengujian dilakukan dalam bentuk tertulis untuk memeriksa apakah aplikasi berjalan seperti yang diharapkan.
Walaupun pengujian fungsional sudah sering dilakukan di bagian akhir dari siklus pengembangan, bahkan sebelum sistem berfungsi, pengujian ini sudah dapat dilakukan pada seluruh sistem. Pengujian fungsional meliputi seberapa baik sistem melaksaakan fungsinya, termasuk perintah-perintah pengguna, manipulasi data, pencarian dan proses bisnis, pengguna layar, dan integrasi. Pengujian fungsional juga meliputi permukaan yang jelas dari jenis fungsi-fungsi, serta operasi back-end (seperti, keamanan dan bagaimana meningkatkan sistem).
(Simarmata, 2010: 316)
Pengujian Skenario (Scenario Testing)
UIN Syarif Hidayatullah Jakarta
Pengujian skenario adalah pengujian yang realistis, kredibel dan memotivasi stakeholder, tantangan untuk program dan mempermudah penguji untuk melakukan evaluasi.
Pengujian Kelayakan (User Acceptance)
Pada jenis pengujian ini, perangkat lunak akan diserahkan kepada pengguna untuk mengetahui apakah perangka lunak memenuhi harapan pengguna dan bekerja seperti yang diharapkan.
2.10 Penelitian Sejenis
Sumber penelitian yang digunakan dalam skripsi ini adalah hasil dari penelitian sejenis yang telah dilakukan sebelumnya. Penulis membagi studi literatur menjadi dua bagian, pertama tentang sistem penunjang keputusan untuk menentukan kelayakan dan kedua tentang logika fuzzy Tsukamoto. Berikut ini adalah rinciannya:
1. Studi Penelitian Sejenis Terkait Sistem Penunjang Keputusan untuk Menentukan Kelayakan
Tabel 2.1 Tabel Perbandingan Studi Literatur Sejenis
No. Judul & Keterangan Kelebihan Kekurangan 1 Perancangan Sistem Pendukung
Keputusan Seleksi Kelayakan Penerimaan Bantuan Beras Miskin (Raskin) untuk Masyarakat Miskin dengan Metode TOPSIS (The Technique for Order Preferences by Similarity to an Ideal Solution) (Studi Kasus : Kelurahan Kaligangsa Kulon, Kabupaten
 Mengimplementa sikan metode TOPSIS untuk mengukur tingkat kemiskinan bagi calon penerima Raskin
berdasarkan rasio variabel kriteria calon
UIN Syarif Hidayatullah Jakarta
Brebes)
Mohammad Aris (UIN Syarif Hidayatullah Jakarta, 2014)
keadaannya.
2 Pengembangan Sistem Pendukung Keputusan Penentu Mustahiq dengan Metode Weighted Product Studi Kasus BAZIS DKI Jakarta Harry Okta Maulana (UIN Syarif Hidayatullah Jakarta, 2016)
 Mengimplementas ikan Weighted Product untuk memeringkatkan
terbatas pada pengujian fungsional.
3 Penentuan Kelayakan Penerima Sedekah Menggunakan Logika Fuzzy Metode Tsukamoto Hadyan Ahmad (UIN Syarif Hidayatullah Jakarta, 2017)
 Mengimplementas ikan Logika Fuzzy Tsukamoto untuk meminimalir
 Pengujian sistem mencakup
pengujian
fungsional dan pengujian hasil perhitungan
aplikasi.
 Berbasis desktop
2. Studi Penelitian Sejenis Terkait Logika Fuzzy Tsukamoto
Berikut ini adalah perbandingan input dan output penelitian-penelitian sebelumnya dengan menggunakan sistem inferensi metode Tsukamoto:
Tabel 2.2 Tabel Perbandingan Input, Proses dan Output
No. Judul & Keterangan Input Proses dan
UIN Syarif Hidayatullah Jakarta
Output 1 Menentukan Harga Mobil Bekas
Toyota Avanza menggunakan
Toyota Avanza menggunakan