2.8.1. Hadits yang dilihat dari banyak sedikitnya Perawi
Ada 5 macam Hadist yang dilihat dari banyak sedikitnya Perawi yaitu :
2.8.1.1. Hadits Mutawatir
Yaitu hadits yang diriwayatkan oleh sekelompok orang dari beberapa sanad yang tidak mungkin sepakat untuk berdusta. Berita itu mengenai hal-hal yang
dapat dicapai oleh panca indera. Dan berita itu diterima dari sejumlah orang yang semacam itu juga. Berdasarkan itu, maka ada beberapa syarat yang harus dipenuhi
agar suatu hadits bisa dikatakan sebagai hadits Mutawatir:
1. Isi hadits itu harus hal-hal yang dapat dicapai oleh panca indera.
2. Orang yang menceritakannya harus sejumlah orang yang menurut ada
kebiasaan, tidak mungkin berdusta. Sifatnya Qathiy. 3.
Pemberita-pemberita itu terdapat pada semua generasi yang sama.
2.8.1.2. Hadits Ahad
Yaitu hadits yang diriwayatkan oleh seorang atau lebih tetapi tidak mencapai tingkat mutawatir. Sifatnya atau tingkatannya adalah zhonniy. Sebelumnya para
ulama membagi hadits Ahad menjadi dua macam, yakni hadits Shahih dan hadits Dhaif. Namun Imam At Turmudzy kemudian membagi hadits Ahad ini menjadi
tiga macam, yaitu:
a. Hadits Shahih
Menurut Ibnu Sholah, hadits shahih ialah hadits yang bersambung sanadnya. Ia diriwayatkan oleh orang yang adil lagi dhobit kuat
ingatannya hingga akhirnya tidak syadz tidak bertentangan dengan hadits lain yang lebih shahih dan tidak muallal tidak cacat. Jadi hadits Shahih
itu memenuhi beberapa syarat sebagai berikut :
1. Kandungan isinya tidak bertentangan dengan Al-Quran.
2. Harus bersambung sanadnya
3. Diriwayatkan oleh orang perawi yang adil.
4. Diriwayatkan oleh orang yang dhobit kuat ingatannya
5. Tidak syadz tidak bertentangan dengan hadits lain yang lebih
shahih 6.
Tidak cacat walaupun tersembunyi.
b. Hadits Hasan
Ialah hadits yang banyak sumbernya atau jalannya dan dikalangan perawinya tidak ada yang disangka dusta dan tidak syadz.
c. Hadits Dhaif
Ialah hadits yang tidak bersambung sanadnya dan diriwayatkan oleh orang yang tidak adil dan tidak dhobit, syadz dan cacat.
2.8.2. Menurut Macam Periwayatannya
Ada beberapa macam meurut periwayatannya yaitu : 2.8.2.1. Hadits yang bersambung sanadnya
Hadits ini adalah hadits yang bersambung sanadnya hingga Nabi Muhammad SAW. Hadits ini disebut hadits Marfu atau Maushul.
2.8.2.2. Hadits yang terputus sanadnya
Ada beberapa macam Hadits yang terputus sanadnya yaitu :
a. Hadits Muallaq
Hadits ini disebut juga hadits yang tergantung, yaitu hadits yang permulaan sanadnya dibuang oleh seorang atau lebih hingga akhir
sanadnya, yang berarti termasuk hadits dhaif.
b. Hadits Mursal
Disebut juga hadits yang dikirim yaitu hadits yang diriwayatkan oleh para tabiin dari Nabi Muhammad SAW tanpa menyebutkan sahabat tempat
menerima hadits itu.
c. . Hadits Mudallas
Disebut juga hadits yang disembunyikan cacatnya. Yaitu hadits yang diriwayatkan oleh sanad yang memberikan kesan seolah-olah tidak ada
cacatnya, padahal sebenarnya ada, baik dalam sanad ataupun pada gurunya. Jadi hadits Mudallas ini ialah hadits yang ditutup-tutupi
kelemahan sanadnya.
d. Hadits Munqathi
Disebut juga hadits yang terputus yaitu hadits yang gugur atau hilang seorang atau dua orang perawi selain sahabat dan tabiin.
e. Hadits Mudhol
Disebut juga hadits yang terputus sanadnya yaitu hadits yang diriwayatkan oleh para tabiit dan tabiin dari Nabi Muhammad SAW atau dari Sahabat
tanpa menyebutkan tabiin yang menjadi sanadnya. Kesemuanya itu dinilai dari ciri hadits Shahih tersebut di atas adalah termasuk hadits-hadits dhaif.
2.8.3. Hadits-hadits dhaif disebabkan oleh cacat perawi
Macam – macam Hadits yang disebabkan oleh cacat perawi yaitu : 2.8.3.1. Hadits Maudhu
Yang berarti yang dilarang, yaitu hadits dalam sanadnya terdapat perawi yang berdusta atau dituduh dusta. Jadi hadits itu adalah hasil karangannya sendiri
bahkan tidak pantas disebut hadits.
2.8.3.2. Hadits Matruk
Yang berarti hadits yang ditinggalkan, yaitu hadits yang hanya diriwayatkan oleh seorang perawi saja sedangkan perawi itu dituduh berdusta.
2.8.3.3. Hadits Mungkar
Yaitu hadits yang hanya diriwayatkan oleh seorang perawi yang lemah yang bertentangan dengan hadits yang diriwayatkan oleh perawi yang terpercaya jujur.
2.8.3.4. Hadits Muallal
Artinya hadits yang dinilai sakit atau cacat yaitu hadits yang didalamnya terdapat cacat yang tersembunyi. Menurut Ibnu Hajar Al Atsqalani bahwa hadis Muallal
ialah hadits yang nampaknya baik tetapi setelah diselidiki ternyata ada cacatnya. Hadits ini biasa disebut juga dengan hadits Malul yang dicacati atau
disebut juga hadits Mutal hadits sakit atau cacat.
2.8.3.5. Hadits Mudhthorib
Artinya hadits yang kacau yaitu hadits yang diriwayatkan oleh seorang perawi dari beberapa sanad dengan matan isi kacau atau tidak sama dan kontradiksi
dengan yang dikompromikan.
2.8.3.6. Hadits Maqlub
Artinya hadits yang terbalik yaitu hadits yang diriwayatkan oleh perawi yang dalamnya tertukar dengan mendahulukan yang belakang atau sebaliknya baik
berupa sanad silsilah maupun matan isi.
2.8.3.7. Hadits Munqalib
Yaitu hadits yang terbalik sebagian lafalnya hingga pengertiannya berubah.
2.8.3.8. Hadits Mudraj
Yaitu hadits yang diriwayatkan oleh seorang perawi yang didalamnya terdapat tambahan yang bukan hadits, baik keterangan tambahan dari perawi sendiri atau
lainnya.
2.8.3.9. Hadits Syadz
Hadits yang jarang yaitu hadits yang diriwayatkan oleh perawi yang tsiqah terpercaya yang bertentangan dengan hadits lain yang diriwayatkan dari perawi-
perawi periwayat pembawa yang terpercaya pula. Demikian menurut sebagian ulama Hijaz sehingga hadits syadz jarang dihapal ulama hadits. Sedang yang
banyak dihapal ulama hadits disebut juga hadits Mahfudz.
2.8.4. Beberapa pengertian istilah dalam ilmu hadits
macam – macam pengertian ilmu Hadits yaitu : 2.8.4.1. Muttafaq Alaih
Yaitu hadits yang diriwayatkan oleh Imam Bukhari dan Imam Muslim dari
sumber sahabat yang sama, atau dikenal juga dengan Hadits Bukhari - Muslim.
2.8.4.2. As Sabah
As Sabah berarti tujuh perawi, yaitu:
1. Imam Ahmad
2. Imam Bukhari
3. Imam Muslim
4. Imam Abu Daud
5. Imam Tirmidzi
6. Imam Nasai
7. Imam Ibnu Majah
2.8.4.3. As Sittah
Yaitu enam perawi yang tersebut pada As Sabah, kecuali Imam Ahmad bin Hanbal.
2.8.4.4. Al Khamsah
Yaitu lima perawi yang tersebut pada As Sabah, kecuali Imam Bukhari dan Imam Muslim.
2.8.4.5. Al Arbaah
Yaitu empat perawi yang tersebut pada As Sabah, kecuali Imam Ahmad, Imam Bukhari dan Imam Muslim.
2.8.4.6. Ats tsalatsah
Yaitu tiga perawi yang tersebut pada As Sabah, kecuali Imam Ahmad, Imam Bukhari, Imam Muslim dan Ibnu Majah.
2.8.4.7. Perawi
Yaitu orang yang meriwayatkan hadits.
2.8.4.8. Sanad
Sanad berarti sandaran yaitu jalan matan dari Nabi Muhammad SAW sampai kepada orang yang mengeluarkan mukhrij hadits itu atau mudawwin orang
yang menghimpun atau membukukan hadits. Sanad biasa disebut juga dengan
Isnad berarti penyandaran. Pada dasarnya orang atau ulama yang menjadi sanad hadits itu adalah perawi juga.
2.8.4.9. Matan
Matan ialah isi hadits baik berupa sabda Nabi Muhammad SAW, maupun berupa perbuatan Nabi Muhammad SAW yang diceritakan oleh sahabat atau berupa
taqrirnya.
2.8.5. Beberapa kitab hadits yang masyhur populer
1. Shahih Bukhari
2. Shahih Muslim
3. Riyadhus Shalihin
2.9. Kebutuhan Fitur Pada Aplikasi
Ada beberapa fitur yang akan digunakan pada pembuatan aplikasi ini, yang banyak memanfaatkan fitur yang telah di bawa oleh android sendiri. Karena
alasan yang paling penting dalam membuat aplikasi ini adalah lebih mengoptimalkan penggunaan dari smartphone khususnya yang memakai android.
Jogiyanto 1999:12
2.9.1. Pengertian Aplikasi
Aplikasi menurut Jogiyanto 1999:12 , adalah penggunaan dalam suatu komputer,instruksi instructiom atau pernyataan statement yang disusun
sedemikian rupasehingga komputer dapat memproses input menjadi output.
Menurut Kamus Kamus Besar Bahasa Indonesia 1998 : 52, “Aplikasi adalah penerapan dari rancang sistem untuk mengolah data yang menggunakan
aturan atauketentuan bahasa pemrograman tertentu”. Aplikasi adalah suatu program komputer yang dibuat untuk mengerjakan
danmelaksanakan tugas khusus dari pengguna. Aplikasi merupakan rangkaian kegiatan atauperintah untuk dieksekusi oleh komputer.
Program merupakan kumpulan instruction set yang akan dijalankan oleh pemroses, yaitu berupa software. Bagaimana sebuah sistem komputer berpikir
diatur oleh program ini. Program inilah yang mengendalikan semua aktifitas yang ada pada pemroses. Program berisi konstruksi logika yang dibuat oleh manusia,
dan sudah diterjemahkan ke dalam bahasa mesin sesuai dengan format yang ada pada instructionset .
Program aplikasi merupakan program siap pakai. Program yang direka untuk melaksanakan suatu fungsi bagi pengguna atau aplikasi yang lain. Contoh-
contoh aplikasiialah program pemproses kata dan Web Browser. Aplikasi akan menggunakan sistem operasi OS komputer dan aplikasi yang lainnya yang
mendukung. Istilah ini mulai perlahan masuk ke dalam istilah Teknologi Informasi
semenjak tahun 1993, yang biasanya juga disingkat dengan app. Secara historis, aplikasi adalah software yang dikembangkan oleh sebuah perusahaan. App adalah
sofware yang dibeli perusahaan dari tempat pembuatnya. Industri PC tampaknya menciptakan istilah ini untuk merefleksikan medan pertempuran persaingan yang
baru, yang paralel dengan yang terjadi antar sistem operasi yang dimunculkan.
2.10. Unified Modelling Language UML
Unified Modelling Language UML adalah sebuah bahasa yang telah
menjadi standar dalam industri untuk visualisasi, merancang dan
mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem. Dengan menggunakan UML dapat
membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis
dalam bahasa pemrograman apapun. Tetapi karena UML juga menggunakan class
dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa-bahasa berorientasi objek seperti C++, Java, C atau
VB.NET. Walaupun demikian, UML tetap dapat digunakan untuk modeling
aplikasi prosedural dalam VB atau C. Sri Dharwiyanti 2003, Pengantar Unified
Modeling Language UML
Seperti juga tercantum pada gambar diatas UML mendefinisikan diagram- diagram sebagai berikut:
a. use case diagram
b. class diagram
c. statechart diagram
d. activity diagram
e. sequence diagram
f. collaboration diagram
2.10.1 Use Case Diagram
Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan
“bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke
sistem, meng-create sebuah daftar belanja, dan sebagainya. Seorangsebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk
melakukan pekerjaan-pekerjaan tertentu. Fowler,2005 Use case diagram dapat sangat membantu bila kita sedang menyusun
requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem.
Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang
di-include akan dipanggil setiap kali use case yang meng-include dieksekusi secara normal. Sebuah use case dapat di-include oleh lebih dari satu use case lain,
sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common.
Sebuah use case juga dapat meng-extend use case lain dengan behaviour- nya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa
use case yang satu merupakan spesialisasi dari yang lain.
Contoh Use Case Diagram :
Gambar 2.8 Contoh Use Case
2.10.2 Class Diagram
Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi
objek. Class menggambarkan keadaan atributproperti suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut metodafungsi.
Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi,
dan lain-lain. Class memiliki tiga area pokok :
1. Nama dan stereotype 2. Atribut
3. Metoda
Atribut dan metoda dapat memiliki salah satu sifat berikut : a.
Private, tidak dapat dipanggil dari luar class yang bersangkutan b.
Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya.
c. Public, dapat dipanggil oleh siapa saja
Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki metoda. Interface tidak dapat langsung
diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time.Sesuai
dengan perkembangan class model, class dapat dikelompokkan menjadi package. Kita juga dapat membuat diagram yang terdiri atas package. Ir. M. FARID AZIS,
M. Kom,2003
Hubungan Antar Class 1.
Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus
mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class.
2. Agregasi, yaitu hubungan yang menyatakan bagian “terdiri atas..”.
3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari
class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class
yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.
4. Hubungan dinamis, yaitu rangkaian pesan message yang di-passing dari
satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.
Contoh class diagram :
Gambar 2.9 Contoh Class Diagram
2.10.3 Activity Diagram
Meurut Julius Hermawan 2003 Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-
masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang
mungkin terjadi pada beberapa eksekusi. Activity diagram merupakan state diagram khusus, di mana sebagian besar
state adalah action dan sebagian besar transisi di-trigger oleh selesainya state
sebelumnya internal processing. Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem dan interaksi antar subsistem
secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum.
Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case
menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas.
Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.
Contoh activity diagram tanpa swimlane:
Gambar 2.10 Contoh Activity Diagram
2.10.4 Sequence Diagram
Meurut Julius Hermawan 2003 Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem termasuk pengguna, display,
dan sebagainya berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal waktu dan dimensi horizontal objek-objek
yang terkait. Sequence diagram biasa digunakan untuk menggambarkan skenario atau
rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas
tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.
Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase
desain berikutnya, message akan dipetakan menjadi operasimetoda dari class. Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali
dengan diterimanya sebuah message. Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan
icon khusus untuk objek boundary, controller dan persistent entity.
Contoh sequence diagram :
Gambar 2.11 Contoh Sequence Diagram
2.10.5 Cardinality Ratio
Dalam penggambaran ER-diagram juga diperlukan cardinality rasio yaitu notasi yang menunjukan banyaknya relasi yang terjadi antar enitas. Disamping itu
cardinality rasio juga untuk membantu gambaran relasi secara lengkap.Terdapat tiga macam relasi dalam hubungan atribut dalam satu file, relasi dari data dapat
berupa: 1.
Hubungan satu ke satu one to one, dimana satu anggota entitas hanya berhubungan dengan satu anggota entitas yang lain
Relation_11
Macam dana
Melaksanakan 2.
Hubungan satu ke banyak one to many, dimana satu anggota entitas berhubungan lebih dari satu dengan anggota entitas yang lain.
3. Hubungan banyak ke banyak many to many, dimana satu anggota entitas
berhubungan lebih dari satu dengan anggota entitas yang lain serta sebaliknya
Pada tools PowerDesigner yang digunakan penulis dalam perancangan dan pembuatan sistem, simbol–simbol yang digunakan pada ER diagram konvensional
berbeda dengan simbol–simbol yang digunakan oleh tools PowerDesigner. Pada tabel dibawah ini merupakan simbol–simbol ER diagram yang digunakan oleh
penulis dalam pembuatan sistem dengan menggunakan tools PowerDesigner. Sri Dharwiyanti 2003, Pengantar Unified Modeling Language UML
Tabel 2.1 Simbol ER Diagram PowerDesigner
Simbol Keterangan
Simbol entitas, “Ent_1” merupakan nama dari entity. Sedangkan “Atribut_1”, “Atribut_2” dan “Atribut_3”
Merupakan atribut–atribut yang ada pada entity Simbol one to one relationship, “Relation_11”
Merupakan nama dari relationship Simbol one to many relationship, “Macam dana”
Merupakan nama dari relationship Simbol many to many relationship, “Melaksanakan”
Merupakan nama dari relationship
2.11. Pengertian RPL Rekaya Perangkat Lunak
Rekayasa perangkat lunak telah berkembang sejak pertama kali diciptakan pada tahun 1940-an hingga kini. Focus utama pengembangannya adalah untuk
mengembangkan praktek dan teknologi untuk meningkatkan produktivitas para praktisi pengembang perangkat luank dan kualitas aplikasi yang dapat digunakan
oleh pemakai. O’Brien, 1999
2.11.1. Sejarah Software Engineering
Istilah software engineering digunakan pertama kali pada akhir 1950-an dan awal 1960-an. Saat itu, masih terdapat perdebatan tajam mengenai aspek
engineering dari pengembangan perangkat lunak. Pada tahun 1968 dan 1969, komite sains NATO mensponsori dua konferensi tentang rekayasa perangkat
lunak, yang memberikan dampak kuat terhadap pengembangan rekayasa perangkat lunak. Banyak yang menganggap dua konferensi inilah yang menandai
awal resmi profesi rekayasa perangkat lunak. Pada tahun 1960-an hingga 1980-an, banyak masalah yang ditemukan para
praktisi pengembangan perangkat lunak. Banyak project yang gagal, hingga masa ini disebut sebagai krisis perangkat lunak. Kasus kegagalan pengembangan
perangkat lunak terjadi mulai dari project yang melebihi anggaran, hingga kasusu yang mengakibatkan kerusakan fisik dan kematian. Salah satu kasus yang terkenal
antara lain meledaknya roket Ariane akibat kegagalan perangkat lunak. Selama bertahun-tahun, para peneliti memfokuskan usahanay untuk menemukan teknik
jitu untuk memecahkan masalah krisi perangkat lunak. Berbagai teknik, metode, alat, proses diciptakan dan diklaim sebagai senjata pamungkas untuk memecahkan
kasus ini. Mulai dari pemrograman terstruktur, pemrograman berorientasi objek, pernagkat pembantu pengembangan perangkat lunak CASE tools, berbagai
standar, UML hingga metode formal diagung-agungkan sebagai senjaat pamungkas untuk menghasilkan software yang benar, sesuai anggaran dan tepat
waktu. Pada tahun 1987, Fred Brooks menulis artikel No Silver Bullet, yang berproposisi bahwa tidak ada satu teknologi atau praktek yang sanggup mencapai
10 kali lipat perbaikan dalam produktivitas pengembanan perngkat lunak dalam tempo 10 tahun.
Sebagian berpendapat, no silver bullet berarti profesi rekayasa perangkat lunak dianggap telah gagal. Namun sebagian yang lain justru beranggapan, hal ini
menandakan bahwa bidang profesi rekayasa perangkat lunak telah cukup matang, karena dalam bidang profesi lainnya pun, tidak ada teknik pamungkas yang dapat
digunakan dalam berbagai kondisi. executive editors, Alain Abran, James W. Moore ; editors, Pierre Bourque, Robert Dupuis. 2004
2.11.2. Pengertian Dasar
Istilah Reakayasa Perangkat Lunak RPL secara umum disepakati sebagai terjemahan dari istilah Software engineering. Istilah Software Engineering mulai
dipopulerkan pada tahun 1968 pada software engineering Conference yang diselenggarakan oleh NATO. Sebagian orang mengartikan RPL hanya sebatas
pada bagaimana membuat program komputer. Padahal ada perbedaan yang mendasar antara perangkat lunak software dan program komputer.
Perangkat lunak adalah seluruh perintah yang digunakan untuk memproses informasi. Perangkat lunak dapat berupa program atau prosedur. Program adalah
kumpulan perintah yang dimengerti oleh komputer sedangkan prosedur adalah perintah yang dibutuhkan oleh pengguna dalam memproses informasi O’Brien,
1999. Pengertian RPL sendiri adalah suatu disiplin ilmu yang membahas semua
aspek produksi perangkat lunak, mulai dari tahap awal yaitu analisa kebutuhan pengguna, menentukan spesifikasi dari kebutuhan pengguna, disain, pengkodean,
pengujian sampai pemeliharaan sistem setelah digunakan. Dari pengertian ini jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan program
komputer. Pernyataan ”semua aspek produksi” pada pengertian di atas, mempunyai arti semnua hal yang berhubungan dengan proses produksi seperti
manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas sampai dengan pelatihan pengguna merupakan bagian dari RPL. executive
editors, Alain Abran, James W. Moore ; editors, Pierre Bourque, Robert Dupuis. 2004
2.11.3. Tujuan Rekayasa Perangkat Lunak
Secara umunmm tujuan RPL tidak berbeda dengan bidang rekayasa yang lain. Hal ini dapat kita lihat pada Gambar di bawah ini.
Gambar 2.12 Tujuan RPL
Dari Gambar di atas dapat diartikan bahwa bidang rekayasa akan selalu berusaha menghasilkan output yang kinerjanya tinggi, biaya rendah dan waktu
penyelesaian yang tepat. Secara leboih khusus kita dapat menyatakan tujuan RPL adalah: executive editors, Alain Abran, James W. Moore ; editors, Pierre
Bourque, Robert Dupuis. 2004 a.
memperoleh biaya produksi perangkat lunak yang rendah b.
menghasilkan pereangkat lunak yang kinerjanya tinggi, andal dan tepat waktu
c. menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis
platform d.
menghasilkan perangkat lunak yang biaya perawatannya rendah
2.11.4. RUANG LINGKUP
Sesuai dengan definisi yang telah disampaikan sebelumnya, maka ruang lingkup RPL dapat digambarkan sebagai berikut: O’Brien, 1999.
Gambar 2.13 Ruang lingkup RPL Abran et.al., 2004.
- software Requirements berhubungan dengan spesifikasi kebutuhan dan
persyaratan perangkat lunak -
software desain mencakup proses penampilan arsitektur, komponen, antar muka, dan karakteristik lain dari perangkat lunak
- software construction berhubungan dengan detail pengembangan
perangkat lunak, termasuk algoritma, pengkodean, pengujian dan pencarian kesalahan
- software testing meliputi pengujian pada keseluruhan perilaku perangkat
lunak -
software maintenance mencakup upaya-upaya perawatan ketika perangkat lunak telah dioperasikan
- software configuration management berhubungan dengan usaha perubahan
konfigurasi perangkat lunak untuk memenuhi kebutuhan tertentu -
software engineering management berkaitan dengan pengelolaan dan pengukuran RPL, termasuk perencanaan proyek perangkat lunak
- software engineering tools and methods mencakup kajian teoritis tentang
alat bantu dan metode RPL -
software engineering process berhubungan dengan definisi, implementasi pengukuran, pengelolaan, perubahan dan perbaikan proses RPL
- software quality menitik beratkan pada kualitas dan daur hidup perangkat
lunak
2.11.5. Metode Rekayasa Perangkat Lunak
Pada rekayasa perangkat lunak, banyak model yang telah dikembangkan untuk membantu proses pengembangan perangkat lunak. Model-model ini pada
umumnya mengacu pada model proses pengembangan sistem yang disebut
System Development Life Cycle SDLC seperti terlihat pada Gambar berikut ini.
Rosa A.S. - M. Shalahuddin Rekayasa Perangkat Lunak, Medula, Bandung, ISBN 978-602-8759-13-7
Gambar 2.14 System Development Life Cycle SDLC.
• Kebutuhan terhadap definisi masalah yang jelas. Input utama dari setiap
model pengembangan perangkat lunak adalah pendefinisian masalah yang jelas. Semakin jelas akan semakin baik karena akan memudahkan dalam
penyelesaian masalah. Oleh karena itu pemahaman masalah seperti dijelaskan pada Bab 1, merupakan bagian penting dari model
pengembangan perangkat lunak.
• Tahapan-tahapan pengembangan yang teratur. Meskipun model-model
pengembangan perangkat lunak memiliki pola yang berbeda-beda, biasanya model-model tersebut mengikuti pola umum analysis – design –
coding – testing – maintenance
• Stakeholder berperan sangat penting dalam keseluruhan tahapan
pengembangan. Stakeholder dalam rekayasa perangkat lunak dapat berupa pengguna, pemilik, pengembang, pemrogram dan orang-orang yang
terlibat dalam rekayasa perangkat lunak tersebut.
• Dokumentasi merupakan bagian penting dari pengembangan perangkat
lunak. Masing-masing tahapan dalam model biasanya menghasilkan sejumlah tulisan, diagram, gambar atau bentuk-bentuk lain yang harus
didokumentasi dan merupakan bagian tak terpisahkan dari perangkat lunak yang dihasilkan.
• Keluaran dari proses pengembangan perangkat lunak harus bernilai
ekonomis. Nilai dari sebuah perangkat lunak sebenarnya agak susah di- rupiah-kan. Namun efek dari penggunaan perangkat lunak yang telah
dikembangkan haruslah memberi nilai tambah bagi organisasi. Hal ini dapat berupa penurunan biaya operasi, efisiensi penggunaan sumberdaya,
peningkatan keuntungan organisasi, peningkatan “image” organisasi dan lain-lain.
2.11.6. Tahapan Rekayasa Perangkat Lunak
Meskipun dalam pendekatan berbeda-beda, namun model-model pendekatan memiliki kesamaan, yaitu menggunaka pola tahapan analysis – design –
codingconstruction – testing – maintenance. Whitten et al, 2004.
1. Analisis sistem
adalah sebuah teknik pemecahan masalah yang menguraikan sebuah sistem menjadi komponen-komponennya dengan tujuan mempelajari
seberapa bagus komponen-komponen tersebut bekerja dan berinteraksi untuk meraih tujuan mereka.
Analisis mungkin adalah bagian terpenting dari proses rekayasa perangkat lunak. Karena semua proses lanjutan akan sangat bergantung pada baik
tidaknya hasil analisis. Ada satu bagian penting yang biasanya dilakukan dalam tahapan analisis yaitu pemodelan proses bisnis.
2. Model proses
adalah model yang memfokuskan pada seluruh proses di dalam sistem yang mentransformasikan data menjadi informasi Harris, 2003.
Model proses juga menunjukkan aliran data yang masuk dan keluar pada suatu proses. Biasanya model ini digambarkan dalam bentuk Diagram Arus Data
Data Flow Diagram DFD. DFD meyajikan gambaran apa yang manusia, proses dan prosedur lakukan untuk mentransformasi data menjadi informasi.
3. Disain perangkat lunak
adalah tugas, tahapan atau aktivitas yang difokuskan pada spesifikasi detil dari solusi berbasis computer Whitten et al,
2004.
Disain perangkat lunak sering juga disebut sebagai physical design. Jika tahapan analisis sistem menekankan pada masalah bisnis business rule, maka
sebaliknya disain perangkat lunak fokus pada sisi teknis dan implementasi sebuah perangkat lunak Whitten et al, 2004.
Output utama dari tahapan disain perangkat lunak adalah spesifikasi disain. Spesifikasi ini meliputi spesifikasi disain umum yang akan disampaikan
kepada stakeholder sistem dan spesifikasi disain rinci yang akan digunakan pada tahap implementasi. Spesifikasi disain umum hanya berisi gambaran
umum agar stakeholder sistem mengerti akan seperti apa perangkat lunak yang akan dibangun. Biasanya diagram USD tentang perangkat lunak yang baru
merupakan point penting dibagian ini. Spesifikasi disain rinci atau kadang disebut disain arsitektur rinci perangkat lunak diperlukan untuk merancang
sistem sehingga memiliki konstruksi yang baik, proses pengolahan data yang tepat dan akurat, bernilai, memiliki aspek user friendly dan memiliki dasar-
dasar untuk pengembangan selanjutnya. Desain arsitektur ini terdiri dari desain database, desain proses, desain user
interface yang mencakup desain input, output form dan report, desain hardware, software dan jaringan. Desain proses merupakan kelanjutan dari
pemodelan proses yang dilakukan pada tahapan analisis.
4. Konstruksi
adalah tahapan menerjemahkan hasil disain logis dan fisik ke dalam kode-kode program komputer.
5. Pengujian
sistem melibatkan semua kelompok pengguna yang telah direncanakan pada tahap sebelumnya. Pengujian tingkat penerimaan terhadap
perangkat lunak akan berakhir ketika dirasa semua kelompok pengguna menyatakan bisa menerima perangkat lunak tersebut berdasarkan kriteria-
kriteria yang telah ditetapkan.
6. Perawatan dan Konfigurasi.
Ketika sebuah perangkat lunak telah dianggap layak untuk dijalankan, maka tahapan baru menjadi muncul yaitu perawatan
perangkat lunak. Ada beberapa tipe perawatan yang biasa dikenal dalam
dunia perangkat lunak seperti terlihat pada diagram di Gambar di bawah ini :
Gambar 2.15 Tipe-tipe perawatan.
• Tipe perawatan corrective dilakukan jika terjadi kesalahan atau biasa
dikenal sebagai bugs.
• Tipe perawatan routine biasa juga disebut preventive maintenance
dilakukan secara rutin untuk melihat kinerja perangkat lunak ada atau tidak ada kesalahan.
• Tipe perawatan sistem upgrade dilakukan jika ada perubahan dari
komponen-komponen yang terlibat dalam perangkat lunak tersebut.
2.12. Pengertian Validitas
Secara umum konsep validitas diartikan sejauhmana suatu alat ukur mengukur apa yang seharusnya diukur. Dalam teori tes klasik, pengertian
validitas dinyatakan sebagai sejauhmana skor tampak X mendekati skor murni T. Sesungguhnya skor tampak X itu tidak akan pernah sama dengan skor
murni T, kecuali alat ukur tersebut memiliki validitas yang sempurna yang memiliki fungsi ukur tanpa kesalahan. Suatu alat ukur yang memiliki validitas
tinggi akan menghasilkan kesalahan ukur yang kecil. Ini berarti bahwa skor yang diperoleh setiap subjek skor X tidak jauh berbeda dengan skor murni T
yang dimiliki subjek.
Dengan demikian secara keseluruhan alat ukur tersebut akan menghasilkan varian error yang kecil pula. Oleh karena itu apa yang kita
peroleh dari perhitungan validasi adalah hanya semacam estimasi terhadap vaiditas dengan prosedur tertentu. Sebutan validitas tes hendaklah diartikan
sebagai validitas hasil pengukuran yang diperoleh dengan alat ukur tersebut. Demikian pula dalam proses validasi, kita tidak bertujuan untuk melakukan
validasi tes, akan tetapi melakukan validasi terhadap interpretasi data yang diperoleh dengan alat dan prosedur tertentu. Samuel, ST, MT. 2009
2.13. SPSS
Kategori