BAB II LANDASAN TEORI
2.1.
Arsitektur Aplikasi Model 3-Tier. Arsitektur aplikasi model 3-tier merupakan model aplikasi yang terdiri
dari 3 tingkat. Dimana pada tingkat pertama dan tingkat kedua adalah server yang berada di pusat pemrosesan data. Server pada tingkat pertama adalah sebagai lapisan basis data (data management tier) yang akan terhubung dengan lapisan layanan di tingkat kedua (middle tier), sedangkan tingkat kedua adalah penghubung antara tingkat pertama dengan lapisan client di tingkat ketiga (presentation tier), artinya dari tingkat ketiga untuk terhubung ke tingkat pertama harus melalui tingkat kedua terlebih dahulu. Untuk tingkat kedua ini adalah aplikasi server, sedangkan tingkat ketiga adalah aplikasi yang ada di komputer client atau user. Tingkat client menangani semua interaksi user dengan aplikasi. Lapisan ini bertanggung jawab untuk semua masukan dan komunikasi dengan lapisan layanan. Tingkat menengah akan memberlakukan aturan bisnis, memproses data, dan mengelola transaksi. Gambar 2.1 menunjukkan model 3-tiers.
Gambar 2.1 Model Tiga-Tingkat. Kelebihan dari model tiga-tingkat adalah terdapatnya tingkat menengah yang berfungsi sebagai pemisah antara client dari server. Client tidak lagi
4
5
mengakses basis data, tetapi memanggil metode yang dimiliki oleh obyek-obyek pada tingkat menengah. 2.2.
Pengertian Power Builder Powerbuilder adalah software development yang dikeluarkan oleh Sybase.
Powerbuilder memiliki lingkungan pengembangan aplikasi berbentuk grafikal sehingga programmer dapat mendesign antarmuka seperti form entri data, window dialog, menu, laporan dan sebagainya secara grafis dari object/kontrol yang sudah disediakan dengan melakukan drag-and-drop. Selanjutnya atribut masing-masing object dapat diatur sendiri seperti posisi, ukuran, teks, warna, jenis huruf dan sebagainya. Powerbuilder mendukung basis data interface standar, seperti ODBC, JDBC, OLE DB, serta memiliki beberapa native basis data interface yang memungkinkan pengaksesan langsung ke basis data-basis data tertentu seperti MS SQL Server, Oracle, dan informix. Powerbuilder merupakan sebuah development tool dengan konsep pemrograman berorientasi objek atau object oriented programming (OOP). OOP adalah konsep yang umum dan telah di adopsi oleh banyak bahasa pemrograman modern seperti C++, Java, VBScript dan sebagainya. Teknik pemrograman pada OOP bersifat modular berbeda dengan teknik pemrograman konvensional yang sifatnya structural. Pada OOP, sebuah modul program dipandang sebagai sebuah objek. Lingkungan window utama Power Builder berisi beberapa komponen, seperti terlihat di Gambar 2.2.
6
Gambar 2.2 Lingkungan window utama Power Builder 10 2.3.
Pengertian SQL Server 2000 MS SQL Server 2000 adalah salah satu produk Relational Basis data
Management System (RDBMS) yang dikeluarkan oleh microsoft. Fungsi utamanya adalah sebagai server basis data yang mengatur semua proses penyimpanan data dan transaksi dari suatu aplikasi. Data Definition Language (DDL) Data Definition Language (DDL) adalah satu paket bahasa DBMS yang berguna untuk melakukan spesifikasi terhadap skema basis data. Secara umum perintah perintah dalam DDL berhubungan dengan operasi-operasi dasar seperti membuat basis data baru, menghapus basis data, membuat tabel baru, menghapus tabel, membuat
indeks,
mengubah
struktur
tabel.
Contoh
perintah
DDL
misalnya, Create Table, Create Index, Alter, dan Drop Basis data. Data Manipulation Language Data Manipulation Language (DML) adalah satu paket DBMS yang memperbolehkan pemakai untuk mengakses atau memanipulasi data sebagaimana yang telah diorganisasikan sebelumnya dalam model data yang tepat. Dengan DML dapat dilakukan kegiatan :
7
Mengambil informasi yang tersimpan dalam basis data (select).
Mengubah informasi dari tabel (update).
Menyisipkan informasi baru dalam basis data (insert). 2.4.
Menghapus informasi dari tabel (delete). Unified Modelling Language (UML) UML (Unified Modeling Language) adalah sebuah bahasa yang
berdasarkan grafik/gambar untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah sistem pengembangan software berbasis orientasi objek (Object-Oriented). UML sendiri memberikan standar penulisan sebuah sistem yang meliputi konsep bisnis proses, penulisan kelas-kelas dalam bahasa program yang spesifik, skema basis data, dan komponen-komponen yang diperlukan dalam sistem software (http://www.omg.org). Secara resmi bahasa UML dimulai pada bulan oktober 1994, ketika Dr. James Rumbaugh bergabung dengan Grady Booch untuk membuat sebuah project pendekatan metoda yang seragam dari masing-masing metoda mereka. Saat itu baru dikembangkan draft metoda UML version 0.8 dan diselesaikan serta di release pada bulan oktober 1995. Bersamaan dengan itu, Dr. Ivan Jacobson bergabung dan UML tersebut diperkaya ruang lingkupnya dengan metoda OOSE sehingga muncul release version 0.9 pada bulan Juni 1996. Hingga saat ini sejak Juni 1998 UML version 1.3 telah diperkaya dan direspons oleh OMG (Object Management Group), dan mengakui bahwa UML sebagai sebuah bahasa pemodelan standar untuk aplikasi object oriented UML adalah standar dunia yang dibuat oleh Object Management Group (OMG), yang alamat situnya adalah http://www.omg.org, sebuah badan yang bertugas mengeluarkan standar-standar teknologi object toriented dan software component. UML mendefinisikan diagram-diagram sebagai berikut: a. use case diagram, b. class diagram, c. activity diagram, d. sequence diagram,
8
2.4.1. Use Case Diagram Use case diagram menggambarkan kebutuhan sistem dari sudut pandang user. Digunakan untuk menggambarkan hubungan antara internal sistem dan eksternal sistem atau hubungan antara sistem dan aktor. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem. Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu. Secara umum elemen use case diagram terdiri dari : a.
Use Case Use case dibuat berdasarkan keperluan aktor, merupakan “apa” yang
dikerjakan sistem, bukan “bagaimana” sistem mengerjakannya. Dalam pemberian nama use case biasanya menggunakan kata kerja dan menyatakan apa yang dicapai dari hasil interaksinya dengan aktor. Dalam UML use case dinotasikan dengan gambar horizontal elipse, yaitu :
Gambar 2.3 Simbol Use Case b.
Actor Actor adalah sesuatu (entitas) yang berhubungan dengan sistem dan
berpartisipasi dalam use case. Actor menggambarkan orang, sistem atau eksternal entitas/stakeholder yang menyediakan atau menerima informasi dari sistem. Actor menggambarkan suatu tugas/peran yang dimainkan dalam use case, seperti anggota, petugas perpustakaan dan lain-lain. Actor digambarkan dengan gambar stick figure atau dengan gambar visual, seperti contoh gambar dibawah ini :
Gambar 2.4 Simbol actor dalam UML
9
c.
Relationship Relasi (relationship) digambarkan sebagai bentuk garis antara dua simbol
dalam use case diagram. Relasi antara aktor dan use case disebut juga dengan asosiasi (association). Asosiasi ini digunakan untuk menggambarkan bagaimana hubungan antara keduanya. Ada beberapa jenis relasi antara use case yaitu : a. Include, yaitu proses yang harus terpenuhi agar sebuah event dapat terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case lainnya. Contoh gambar :
<
>
Nasabah
Buka rekening
Catat data Pribadi
Gambar 2.5 Use Case Include b. Extend, merupakan perluasan dari use case jika kondisi atau syarat terpenuhi. Contoh gambar :
Gambar 2.6 Use Case Extend 2.4.2. Class Diagram Class diagram menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus
menawarkan
layanan
untuk
memanipulasi
keadaan
tersebut
(metoda/fungsi). Class diagram menggambarkan struktur dan deskripsi kelas, paket (package)dan obyek beserta hubungan satu sama lain seperti pewarisan dan asosiasi.
10
Kelas memiliki tiga area pokok : 1. Nama, berfungsi untuk memberi identitas pada sebuah kelas. 2. Atribut, yaitu sebuah nilai data yang dimiliki oleh objek sebuah kelas. Nama, umur, berat badan, tinggi badan adalah contoh atribut dari obyek manusia. 3. Metode, merupakan suatu operasi berupa fungsi-fungsi yang dapat dikerjakan oleh suatu object. Metode didefinisikan pada class akan tetapi dipanggil melalui object. Contoh pada object mangga terdapat method ambilRasa , kupasKulit dan lain-lain. Atribut dan metoda dapat memiliki salah satu sifat berikut : 1. Private, tidak dapat dipanggil dari luar kelas yang bersangkutan. 2. Protected, hanya dapat dipanggil oleh kelas yang bersangkutan dan anak-anak yang mewarisinya. 3. Public, dapat dipanggil oleh siapa saja. Hubungan-hubungan antar kelas, antara lain : 1. Asosiasi, yaitu hubungan statis antar kelas. Umumnya menggambarkan kelasyang memiliki atribut berupa kelas lain, atau kelas yang harus mengetahui eksistensi kelas lain. Panah navigability menunjukkan arah query antar kelas. 2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”). 3. Pewarisan, yaitu hubungan hirarkis antar kelas. Kelas dapat diturunkan dari kelas lain dan mewarisi semua atribut dan metoda kelas asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari kelas yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi. 4. Hubungan dinamis, yaitu rangkaian pesan (message) yang dikirim dari satu kelas kepada kelas lain. Nama Class Daftar Atribut Daftar Operasi() Gambar 2.7 Notasi dan contoh class diagram.
11
2.4.3. Activity Diagram Activity diagram menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, keputusan (decision) yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. 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. Tabel 2.1 Notasi-notasi pada Activity Diagram Notasi
Keterangan Titik awal Titik akhir Activity Decision, pengambilan keputusan Fork, digunakan untuk menunjukkan percabangan Join, digunakan untuk menunjukkan penggabungan
2.4.4. Sequence Diagram Sequence diagram digunakan untuk menggambarkan perilaku pada sebuah scenario. Diagram ini menunjukkan sejumlah contoh objek dan message yang diletakan diantara objek-objek ini di dalam use case. Komponen utamanya terdiri atas : 1. Participant/objek dituliskan dengan kotak segi empat bernama, diletakkan di dekat bagian atas diagram dengan urutan dari kiri kekanan. Setiap objek terhubung dengam garis titik-titik yang disebut lifeline. Sepanjang lifeline ada kotak yang disebut activation yang mewakili sebuah eksekusi operasi dari objek.
12
2. Message diwakili oleh garis dengan tanda panah, bergerak dari satu objek ke objek yang lain dan dari saru lifeline ke lifeline yang lain. Sebuah objek bisa mengirim sebuah message kepada dirinya sendiri. 3. Time/waktu ditunjukkan dengan progress vertical dimulai dari atas ke bawah. Message yang lebih dekat dari atas akan dijalankan terlebih dahulu dibanding message yang lebih dekat ke bawah. Notasi sequence diagram dapat dilihat pada Gambar 2.7.
actor objek/ participant activation message
lifeline
Gambar 2.8 Notasi Sequence Diagram
2.5.
Perancangan Basis Data Jogiyanto (1993:13) dalam buku Analisis dan Disain Sistem Informasi
mendefinisikan basis data sebagai kumpulan dari data yang saling berhubungan satu dengan yang lainnya, tersimpan di perangkat keras komputer, dan digunakan perangkat lunak untuk memanipulasinya. Menurut Petroutsos (2004:39) perancangan basis data membutuhkan logika. Basis data ditujukan untuk memecahkan masalah praktis yang dihadapi oleh pengguna basis data. Masalah yang praktis membutuhkan solusi yang praktis.
13
Abtraksi Data Perancangan basis data merupakan proses menciptakan perancangan untuk basis data yang akan mendukung operasi dan tujuan perusahaan (Connolly, 2002,p279). Dalam merancang suatu basis data, digunakan metodologi-metodologi yang membantu dalam tahap perancangan basis data. Metodologi perancangan adalah pendekatan struktur dengan menggunakan prosedur, teknik, alat, serta bantuan dokumen untuk membantu dan memudahkan dalam proses perancangan. Dengan menggunakan teknik metode disain ini dapat membantu dalam merencanakan, mengatur, mengontrol, dan mengevaluasi basis data development project (Connolly,2002,p418). 2.5.1.1 Level Konseptual (Conceptual Level) Level konseptual (http://geodesi-250.gd.itb.ac.id) adalah Aktivitas yang dilakukan pada tahap desain konseptual adalah identifikasi dan analisis jenis-jenis aplikasi yang harus ada yang terkait dengan keinginan pengguna, serta klarifikasi dan inventarisasi apa-apa saja yang menjadi tujuan akhir dari basis data yang akan dibangun. Semakin jelas hal-hal ini didefinisikan, semakin mudah pelaksanaan. Pada tahapan desain konseptul ini pemilihan dan penentuan perangkat lunak dan perangkat keras yang akan digunakan belum dipermasalahan.
Gambar 2.9 Fase perancangan basis data secara konseptual
14
Fase perancangan basis data secara konseptual mempunyai 4 aktifitas paralel : 1. Pengumpulan data dan analisa Proses
identifikasi
dan
analisa
kebutuhan-kebutuhan
data
disebut
pengumpulan data dan analisa. Untuk menentukan kebutuhan-kebutuhan suatu sistem basis data, pertama-tama harus mengenal bagian-bagian lain dari sistem informasi yang akan berinteraksi dengan sistem basis data, termasuk para pemakai yang ada dan para pemakai yang baru serta aplikasi-aplikasinya. Kebutuhan-kebutuhan dari para pemakai dan aplikasi-aplikasi inilah yang kemudian dikumpulkan dan dianalisa. 2. Perancangan skema konseptual Menguji kebutuhan-kebutuhan data dari suatu basis data yang merupakan hasil dari
pengumpulan data dan analisa, dan menghasilkan sebuah
conceptual basis data schema pada DBMS independent model data tingkat tinggi seperti EER (enhanced entity relationship) model. Skema ini dapat dihasilkan dengan menggabungkan bermacam-macam kebutuhan user dan secara langsung membuat skema basis data atau dengan merancang skemaskema yang terpisah dari kebutuhan tiap-tiap user dan kemudian menggabungkan skema-skema tersebut. Model data yang digunakan pada perancangan skema konseptual adalah DBMS-independent, dan langkah selanjutnya adalah memilih sebuah DBMS untuk melaksanakan rancangan tersebut. 3. Perancangan transaksi Menguji aplikasi-aplikasi basis data dimana kebutuhan-kebutuhannya telah dianalisa pada fase pengumpulan data dan analisa, dan menghasilkan perincian transaksi-transaksi ini. Kegunaan fase ini yang diproses secara paralel bersama fase perancangan skema konseptual adalah untuk merancang karakteristik dari transaksi-transaksi basis data yang telah diketahui pada suatu DBMS-independent. 4. Output yang diinginkan Langkah terakhir dalam fase ini dirasakan penting agar output yang dihasilkan oleh aplikasi sesuai dengan apa yang diharapkan oleh user pengguna.
15
2.5.1.2 Level Logic (Logical Level) Perancangan basis data secara logic (http://geodesi-250.gd.itb.ac.id) merupakan tahapan untuk memetakan proses perancangan konseptual kedalam model basis data yang akan digunakan, apakah model data hirarki, jaringan atau relasi. Perancangan basis data secara logik ini tidak tergantung pada DBMS yang digunakan, sehingga tahap perancangan ini disebut juga pemetaan model data.
Gambar 2.9 Fase perancangan basis data secara Logical Fase perancangan basis data secara Logical mempunyai 4 aktifitas : 1. Mendefinisikan Entity data Entiti adalah sesuatu yang mudah diidentifikasi dengan mudah dari suatu system basis data, bisa berupa objek, orang, tempat, kejadian atau konsep yang informasinya akan disimpan. Hal-hal yang terlibat dalam suatu sistem basis data dapat dijadikan entity. Dari sekian banyak kemungkinan entity yang ada maka harus dipilah-pilah entity mana saja yang sesuai dan mampu mengakomodasi kebutuhan sistem yang akan dirancang. Misalnya dalam proses merancang Sistem Informasi Akademik, ada banyak kemungkinan yang bisa di jadikan entity, Misalnya entity mahasiswa, matakuliah, dosen, fakultas, jurusan, lokal dan lain sebagainya.
16
2. Menentukan Attribute Entity Setelah menentukan entity-entity yang terlibat pada sistem basis data yang dirancang, langkah berikutnya adalah menentukan attribute yang melekat pada entity tersebut. Attribute adalah ciri khas yang melekat pada suatu entity dan menunjukkan item sejenis. Sama halnya dalam menentukan entity, dalam menentukan attribute ini juga banyak kemungkinan, maka harus dipilah-pilah attribute apa saja yang diperlukan oleh sistem basis data yang dirancangan. 3. Menentukan relasi Antar Entity Setelah menentukan entity dan attribute beserta kuncinya, maka selanjutnya adalah menentukan relasi antar entity. Bisa saja antara satu entity dengan entity yang lainnya tidak saling berhubungan, tapi entity tersebut berhubungan dengan entity yang satu lagi. Jika antara satu entity dengan entity yang lain saling berhubungan, maka hubungan tersebut dinyatakan sebagai entity baru, dan harus ditentukan pula attribute dan field kuncinya. Entity hasil relasi pasti mempunyai kunci tamu (foreign key). Kunci tamu adalah attribute yang berfungsi sebagai kunci pada entity yang lain, digunakan juga sebagai kunci pada entity hasil relasi 4.
Menentukan Derajat Relasi Derajat relasi menunjukkan jumlah maksimum record suatu entity ber-relasi dengan record ada entity yang lainnya. Derajat relasi yang terjadi antara satu entity dengan entity lainnya adalah satu ke satu, satu ke banyak atau sebaliknya, atau banyak ke banyak.
2.5.1.3 Level Physic (Physical Level) Perancangan basis data secara fisik (http://geodesi-250.gd.itb.ac.id) merupakan tahapan untuk mengimplementasikan hasil perancangan basis data secara logis menjadi tersimpan secara fisik pada media penyimpanan eksternal sesuai dengan DBMS yang digunakan. Dapat disimpulkan bahwa proses perancangan fisik merupakan transformasi dari perancangan logis terhadap jenis DBMS yang digunakan sehingga dapat disimpan secara fisik pada media penyimpanan.
17
Gambar 2.10 Fase perancangan basis data secara Fase perancangan basis data secara Logical mempunyai 3 aktifitas : 1. Transformasi istilah entity menjadi Tabel 2. Transformasi istilah attribute menjadi Field 3. Konfigurasi Perangkat Keras dan Lunak 2.5.2
Diagram Relasi Entitas Diagram relasi entitas digunakan untuk memodelkan struktur data dan
hubungan antar data, karena hal ini relatif kompleks. Diagram relasi entitas digambarkan sebagai garis yang menghubungkan entitas-entitas yang dipandang memiliki hubungan antara satu dengan lainnya. a. Relasi satu ke satu Hubungan antara file pertama dengan file kedua satu berbanding satu. Hubungan tersebut dapat digambarkan tanda persegi untuk menunjukkan tabel dan relasi antara keduanya diwakilkan tanda panah tunggal. b. Relasi satu ke banyak Hubungan antara file pertama dengan file kedua adalah satu berbanding banyak atau dapat pula dibalik menjadi banyak lawan satu. Hubungan tersebut dapat digambarkan dengan tanda persegi untuk menunjukkan tabel dan relasi antara keduanya diwakilkan dengan tanda panah ganda untuk menunjukkan hubungan banyak tersebut dengan tanda panah tunggal.
18
c. Relasi banyak ke banyak Hubungan antara file pertama dengan file kedua adalah banyak berbanding banyak. Hubungan tersebut digambarkan dengan tanda persegi dan tanda panah ganda. 2.6.
Model Waterfall Model pengembangan software yang diperkenalkan oleh Winston Royce
pada tahun 70-an ini merupakan model klasik yang sederhana dengan aliran sistem yang linier. Keluaran dari tahap sebelumnya merupakan masukan untuk tahap berikutnya. Pengembangan dengan model ini adalah hasil adaptasi dari pengembangan perangkat keras, karena pada waktu itu belum terdapat metodologi pengembangan perangkat lunak yang lain. Metode Waterfall adalah suatu proses pengembangan perangkat lunak berurutan, di mana kemajuan dipandang sebagai terus mengalir ke bawah (seperti air terjun) melewati fase-fase perencanaan, pemodelan, implementasi (konstruksi), dan pengujian. Berikut adalah gambar pengembangan perangkat lunak berurutan/ linear (Pressman, Roger S. 2001):
Gambar 2.11 Model Waterfall
19
Tahapan Metode Waterfall Dalam pengembangannya metode waterfall memiliki beberapa tahapan yang runtut: requirement (analisis kebutuhan), design sistem (system design), Coding & Testing, Penerapan Program, pemeliharaan. a. Requirement (analisis kebutuhan). Dalam langakah ini merupakan analisa terhadap kebutuhan sistem. Pengumpulan data dalam tahap ini bisa melakukan sebuah penelitian, wawancara atau study literatur. Seseorang system analisis akan menggali informasi sebanyak-banyaknya dari user sehingga akan tercipta sebuah sistem komputer yang bisa melakukan tugas-tugas yang diinginkan oleh user tersebut. Tahapan ini akan menghasilkan dokumen user requirement atau bisa dikatakan sebagai data yang berhubungan dengan keinginan user dalam pembuatan sistem. Dokumen inilah yang akan menjadi acuan system analisis untuk menterjemahkan kedalam bahasa pemrograman. b. Design System (design sistem) Proses desain akan menterjemahkan syarat kebutuhan kesebuah perancangan perangkat lunak yang dapat diperkirakan sebelum dibuat koding. Proses ini berfokus pada : struktur data, arsitektur perangkat lunak, representasi interface, dan detail (algoritma) prosedural. Tahapan ini akan menghasilkan dokumen yang disebut software requirement. Dokumen inilah yang akan digunakan programmer untuk melakukan aktivitas pembuatan sistemnya. c. Coding & Testing (penulisan sinkode program) Coding merupakan penerjemahan desain dalam bahasa yang bisa dikenali oleh komputer. Dilakukan oleh programmer yang akan menterjemahkan transaksi yang diminta oleh user. Tahapan inilah yang merupakan tahapan secara nyata dalam mengerjakan suatu sistem. Dalam artian penggunaan komputer akan dimaksimalkan dalam tahapan ini. Setelah pengkodean selesai maka akan dilakukan testing terhadap sistem yang telah dibuat tadi. Tujuan testing adalah menemukan kesalahan-kesalahan terhadap sistem tersebut dan kemudian bisa diperbaiki.
20
d. Integration & Testing (Penerapan / Pengujian Program) Tahapan ini bisa dikatakan akhir dalam pembuatan sebuah sistem. Setelah melakukan analisa, desain dan pengkodean maka sistem yang sudah jadikan digunakan oleh user. e. Operation & Maintenance (Pemeliharaan) Perangkat lunak yang susah disampaikan kepada pelanggan pasti akan mengalami perubahan. Perubahan tersebut bisa karena mengalami kesalahan karena perangkat lunak harus menyesuaikan dengan lingkungan (periperal atau sistem operasi baru) baru, atau karena pelanggan membutuhkan perkembangan fungsional. 2.7
Metoda Pengujian Unit program/ program individual diintegrasikan menjadi sebuah kesatuan
sistem dan kemudian dilakukan pengujian. Dengan kata lain, pengujian ini ditujukan untuk menguji keterhubungan dari tiap-tiap fungsi perangkat lunak untuk menjamin bahwa persyaratan sistem telah terpenuhi. Setelah pengujian sistem selesai dilakukan, perangkat lunak dikirim ke user (Sommerville, 2003) Sebuah perangkat lunak sering terjadi kesalahan pada proses-proses tertentu pada saat perangkat lunak tersebut sudah diserahkan kepada user, kesalahan-kesalahan yang terjadi ini biasa disebut sebagai “bug”. Untuk menghindari munculnya bug maka diperlukan adanya suatu pengujian perangkat lunak sebelum perangkat lunak tersebut diserahkan atau selama perangkat lunak tersebut masih dalam proses pengembangan. Munculnya suatu bug adalah hal yang biasa, bahkan sebuah perangkat lunak yang sudah besar dan terkenalpun biasanya masih ada bug, yang bisa dilakukan pengembang perangkat lunak adalah meminimalisir munculnya bug tersebut dengan melakukan beberapa pengujian. Pengujian perangkat lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain dan pengkodean. Pada proses pembuatan perangkat lunak, pengembang pertama-tama berusaha membangun perangkat lunak dari konsep abstrak ke implementasi yang dapat dilihat, baru dilakukan pengujian.
21
Pengujian diawali dari pengujian unit. Unit disini bisa berupa kumpulan fungsi atau prosedur yang memiliki keterkaitan pada pemrograman terstruktur atau kelas pada pemrograman berorientasi objek. Unit juga dapat berupa modul atau dikenal juga sebagai package. Setelah unit-unit selesai diuji maka dilakukan pengujian integrasi. Pengujian integrasi dilakukan secara bertahap untuk menghindari kesulitan penelusuran jika terjadi kesalahan (error). Pengujian integrasi lebih pada pengujian penggabungan dari dua atau lebih unit pada perangkat lunak. Setelah pengujian integrasi maka dilakukan pengujian sistem dimana unit-unit proses yang sudah diintegrasi diuji dengan antar muka yang sudah dibuat sehingga pengujian ini dimaksudkan untuk menguji sistem perangkat lunak. Setelah pengujian sistem selesai maka dapat dilakukan pengujian penerimaan perangkat lunak oleh user (pemakai perangkat lunak). Pengujian penerimaan digunakan untuk mengetahui kepuasaan user terhadap perangkat lunak yang sudah dibuat. Adapun untuk melakukan pengujian ini dilakukan beberapa pendekatan, diantaranya : a. Black-Box Testing (Pengujian kotak hitam) Menguji perangkat lunak dari segi fungsional tanpa menguji desain dan kode program. Pengujian dimaksudkan untuk mengetahui apakah fungsi-fungsi, masukan dan keluaran dari perangkat lunak sesuai dengan spesifikasi yang diharapkan. Pengujian kotak hitam dilakukan dengan membuat kasus uji yang dibuat dengan “kasus benar” dan “kasus salah”. Misalkan untuk kasus login, maka dibuat kasus uji sebagai berikut :
Login menggunakan username dan password yang benar.
Login menggunakan username dan password yang salah, misalnya username benar tapi password salah, atau sebaliknya atau keduanya salah.
b. White-Box Testing (Pengujian kotak putih) Menguji perangkat lunak dari segi desain dan kode program apakah mampu menghasilkan fungsi-fungsi, masukan, dan keluaran yang sesuai dengan spesifikasi masukan dan keluaran yang sesuai dengan kebutuhan. Pengujian
22
kotak putih dilakukan dengan memeriksa lojik dari kode program. Pembuatan kasus uji bisa mengikuti standar pengujian dari standar pemrograman yang seharusnya. Contoh dari pengujian kotak putih misalkan menguji alur (dengan menelusuri) pengulangan (looping) pada logika pemrograman.
