4 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 clientatauuser.
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
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.
Gambar 2.2Lingkungan window utamaPower Builder10
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 :
Mengambil informasi yang tersimpan dalam basis data(select).
Mengubah informasi dari tabel(update).
Menyisipkan informasi baru dalam basis data(insert).
Menghapus informasi dari tabel(delete). 2.4. 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,
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 elemenuse casediagram 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.3SimbolUse Case
b. Actor
Actor adalah sesuatu (entitas) yang berhubungan dengan sistem dan berpartisipasi dalamuse 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 :
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 sebuahuse caseadalah bagian dariuse caselainnya. Contoh gambar :
Nasabah Buka rekening Catat data Pribadi <<include>>
Gambar 2.5 Use Case Include
b. Extend, merupakan perluasan dariuse casejika 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.
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 navigabilitymenunjukkan 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()
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.1Notasi-notasi padaActivity 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 diagramdigunakan untuk menggambarkan perilaku pada sebuah scenario. Diagram ini menunjukkan sejumlah contoh objek dan message yang diletakan diantara objek-objek ini di dalamuse 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. Sepanjanglifeline ada kotak yang disebut activation yang mewakili sebuah eksekusi operasi dari objek.
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 sebuahmessagekepada dirinya sendiri.
3. Time/waktu ditunjukkan denganprogress vertical dimulai dari atas ke bawah. Messageyang lebih dekat dari atas akan dijalankan terlebih dahulu dibanding messageyang lebih dekat ke bawah.
Notasi sequence diagramdapat dilihat pada Gambar 2.7.
objek/ participant message lifeline activation actor
Gambar 2.8NotasiSequence 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.
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.
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 skema-skema 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. Outputyang diinginkan
Langkah terakhir dalam fase ini dirasakan penting agaroutputyang dihasilkan oleh aplikasi sesuai dengan apa yang diharapkan oleh user pengguna.
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 modelbasis datayang akan digunakan, apakah model data hirarki, jaringan atau relasi. Perancanganbasis datasecara logik ini tidak tergantung pada DBMS yang digunakan, sehingga tahap perancangan ini disebut juga pemetaan model data.
Gambar 2.9Fase perancanganbasis datasecara Logical
Fase perancangan basis data secara Logical mempunyai 4 aktifitas : 1. MendefinisikanEntitydata
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 dijadikanentity. Dari sekian banyak kemungkinanentityyang 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.
2. MenentukanAttribute Entity
Setelah menentukan entity-entity yang terlibat pada sistem basis data yang dirancang, langkah berikutnya adalah menentukan attribute yang melekat padaentity tersebut. Attribute adalah ciri khas yang melekat pada suatu entity dan menunjukkan item sejenis. Sama halnya dalam menentukan entity, dalam menentukanattribute ini juga banyak kemungkinan, maka harus dipilah-pilah attributeapa saja yang diperlukan oleh sistem basis data yang dirancangan. 3. Menentukan relasi AntarEntity
Setelah menentukan entity dan attribute beserta kuncinya, maka selanjutnya adalah menentukan relasi antar entity. Bisa saja antara satu entity dengan entityyang lainnya tidak saling berhubungan, tapientitytersebut 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 pulaattributedan field kuncinya. Entityhasil relasi pasti mempunyai kunci tamu (foreign key). Kunci tamu adalah attribute yang berfungsi sebagai kunci pada entity yang lain, digunakan juga sebagai kunci padaentityhasil relasi
4. Menentukan Derajat Relasi
Derajat relasi menunjukkan jumlah maksimum record suatu entity ber-relasi denganrecord ada entityyang 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.
Gambar 2.10 Fase perancangan basis data secara
Fase perancangan basis data secara Logical mempunyai 3 aktifitas : 1. Transformasi istilahentitymenjadi Tabel
2. Transformasi istilahattributemenjadi 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.
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):
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, representasiinterface, 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)
Codingmerupakan penerjemahan desain dalam bahasa yang bisa dikenali oleh komputer. Dilakukan oleh programmer yang akan menterjemahkan transaksi yang diminta olehuser. 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 dilakukantestingterhadap sistem yang telah dibuat tadi. Tujuantestingadalah menemukan kesalahan-kesalahan terhadap sistem tersebut dan kemudian bisa diperbaiki.
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 olehuser.
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 keuser(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.
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 :
Loginmenggunakanusernamedanpasswordyang 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
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.
