BAB 2 LANDASAN TEORI

2.1 Teori Umum

2.1.1 Software Engineering Menurut Pressman (2010, p.13), ”software engineering merupakan

penerapan development, operation dan maintenance pada perangkat

lunak dengan pendekatan yang sistematis, disiplin dan kuantitatif.

Software engineering mencakup proses dan method untuk mengatur serta

tools yang diperlukan dalam pengembangan perangkat lunak. Hal

mendasar yang menjadi pendukung software engineering adalah fokus

pada kualitas.”

2.1.1.1 Software Menurut Pressman (2010, p.4), software memiliki karakteristik

sebagai berikut:

• Software dibangun dan dirancang, tidak dibuat dengan cara yang

klasik

• Software tidak akan usang.

• Walaupun industri bergerak ke arah konstruksi menggunakan

komponen, kebanyakan software masih custom built.

2.1.1.2 System Development Life Cycle (SDLC) System Development Life Cycle (SDLC) adalah suatu kerangka

yang menggambarkan kegiatan-kegiatan yang dilakukan pada setiap

tahap pembuatan sebuah software (Fatta, 2007, p.24). Dalam

pembangunan aplikasi kita menggunakan spiral. Menurut Pressman

(2010, p.45-47) model proses pengembangan perangkat lunak spiral

merupakan plan-driven process atau pada prinsipnya pengembang

harus membuat rencana dan jadwal pekerjaan yang berdasarkan

sirkuit spiral dengan mengikuti arah jarum jam dan dimulai dari sisi

paling dalam. Berikut adalah tahapan yang ada dalam spiral:

1. Communication

Pada tahap ini dilakukan proses komunikasi yang efektif antara

pengembang dan pelanggan mengenai kebutuhan dan kriteria

spesifik pada proyek yang akan dikerjakan.

2. Planning

Pada tahap ini dilakukannya proses perencanaan estimasi biaya,

waktu pengerjaan, risk analysis dan scheduling agar tidak terjadi

cost overrun dan juga mencari solusi alternative lainnya.

3. Modeling

Pada tahap ini membahas desain konseptual yang meliputi desain

arsitektural, desain logikal modul, dan juga desain fisik tampilan

pada produk.

4. Construction

Pada tahap ini program yang telah direncanakan sebelumnya

memasuki implementasi coding dan testing sehingga memenuhi

software requirement. Apabila sudah terpenuhi, sistem perangkat

lunak didistribusikan kepada user.

5. Deployment

Pada tahap ini dilakukan serah terima program antara pengembang

dan pelanggan setelah melalui rangkaian testing. Pelanggan juga

dapat mengevaluasi piranti lunak mengenai fungsi dan spesifikasi

yang sesuai harapan.

Gambar 2.1 Spiral Model (Sumber: Pressman, 2010, p.46)

2.1.2 Analisa Kebutuhan Menurut Ramnath dan Dathan (2011, p.134), analisis menentukan

kebutuhan dari sistem dan apa yang harus dilakukan oleh sistem.

Proses ini dilakukan oleh tim analis. Tim analis akan membuat model

dari sistem, mengidentifikasikan beberapa komponen sistem dan

hubungan diantara mereka. Produk yang dihasilkan dari fase ini

adalah conceptual model dari sistem yang mendeskripsikan

fungsionalitas sistem, mengidentifikasikan conceptual entities dan

mencatat sifat asosiasi antar entitas tersebut.

2.1.3 Perancangan Pressman (2010, p.215) berpendapat perancangan adalah membuat

gambaran atau model dari sebuah perangkat lunak dengan

menyediakan rincian mengenai arsitektur dari perangkat lunak,

struktur data, tampilan, dan komponen yang diperlukan untuk

mengimplementasikan sistem. Perancangan berperan penting karena

model ini dapat dinilai terlebih dahulu kualitasnya dan dikembangkan

sebelum sistem dibangun.

2.1.4 Unified Modeling Language (UML) UML menurut Pressman (2010, p.841) atau Bahasa Pemodelan

Terpadu adalah bahasa standar untuk penulisan perangkat lunak. UML

dapat digunakan untuk menggambarkan, mendefinisikan,

mengkonstruksi, dan mendokumentasikan sistem perangkat lunak.

Perusahaan banyak menggunakan UML untuk pengembangan sistem

perangkat lunak, karena didalamnya terdapat diagram serta narasi agar

lebih mudah dalam pemahamannya akan sistem perangkat lunak

tersebut.

2.1.4.1 Use Case Diagram Menurut Whitten & Bentley (2007, p.246), use case

diagram merupakan diagram yang menggambarkan interaksi

antara sistem, eksternal sistem dan pengguna. Diagram ini

mendeskripsikan siapa yang akan menggunakan sistem dan

dengan cara apa yang diharapkan oleh pengguna untuk dapat

berinteraksi dengan sistem. Berikut adalah komponen pada use

case diagram:

• Use Case

Mendeskripsikan fungsi dari sistem dari perspektif user

dengan menggunakan kata-kata dan terminologi yang mereka

pahami (Whitten & Bentley, 2007, p.246). Use case

dilambangkan dengan simbol :

Gambar 2.2 Simbol Use Case

Use case menyatakan hanya satu tujuan dari sistem dan

mendeskripsikan rentetan aktivitas dan interaksi pengguna

dalam upaya mencapai tujuan tersebut.

• Actor

Menurut Whitten & Bentley (2007, p.247), actor

merupakan segala sesuatu yang berinteraksi dengan sistem

untuk bertukar informasi. Actor merepresentasikan peran

yang harus dipenuhi oleh pengguna untuk berinteraksi

dengan sistem. Faktanya actor tidak harus manusia, actor

dapat berupa organisasi, sistem informasi yang lain,

peralatan eksternal seperti sensor panas, atau bahkan waktu.

Simbol actor:

Gambar 2.3 Simbol Actor

• Relationship

Menurut Whitten & Bentley (2007, p.248), digambarkan

sebagai garis yang menghubungkan antara dua simbol pada

diagram usecase:

1. Association

Asosiasi merupakan relationship antara actor dan use case

dimana interaksi terjadi diantara mereka berdua. Asosiasi

dengan tanda panah mengindikasikan use case diimitasi

oleh actor pada ujung garis yang lain. Sedangkan asosiasi

tanpa tanda panah mengindikasikan interaksi antara usecase

dan eksternal server atau actor penerima (Whitten &

Bentley, 2007, p.248).

Gambar 2.4 Contoh Association pada Use Case

2. Inheritance

Menurut Whitten & Bentley (2007,p.250), inheritance

dalam usecase menunjukkan hubungan antara actor yang

bertujuan untuk menyederhanakan penggambaran ketika

abstract actor mewarisi peran dari beberapa actor asli lain.

Gambar 2.5 Contoh Inheritance

3. Extends

Menurut Whitten & Bentley (2007, p.249) extends

menggambarkan use case yang bersifat kompleks agar menjadi

lebih sederhana dan mudah dimengerti dengan membaginya ke

dalam tahap-tahap.

Gambar 2.6 Contoh Extends

4. Depends On

Menurut Whitten & Bentley (2007, p.250) depends on

menggambarkan adanya ketergantungan antara satu use

case dengan use case lainnya sehingga sebuah aktivitas

hanya bisa dilakukan apabila aktivitas sebelumnya sudah

berjalan.

Gambar 2.7 Contoh Depends On

• Use Case Narrative

Whitten & Bentley (2007, p.246) mendeskripsikan use case

narrative sebagai deskripsi secara tertulis dari event bisnis dan

bagaimana user akan berinteraksi dengan sistem untuk

mencapai tujuan. Format use case narrative adalah sebagai

berikut.

Tabel 2.1 Elemen Use Case Narrative

Keterangan

Usecasename Nama use case harus merepresentasikan

tujuan yang hendak dicapai use case.

Nama harus diawali dengan kata kerja.

Usecaseid Penanda yang secara unik mendefinisikan

use case.

Priority Mengkomunikasikan tingkat kepentingan

use case (low, medium, high).

Primarybusinessactor Stakeholder yang mendapatkan

keuntungan langsung dari eksekusi use

case dengan menerima sesuatu yang bisa

diukur maupun dinilai.

Description Deskripsi singkat yang berisi beberapa

kalimat yang menguraikan tujuan dan

aktivitas dari use case.

Precondition Use case lain harus dijalankan terlebih

dahulu sebelum use case ini dieksekusi.

Trigger Event yang memulai eksekusi sebuah use

case. Biasanya berupa physical action

atau waktu.

Typical Course of

Events

Rentetan aktivitas yang dilakukan oleh

actor dan system dengan maksud untuk

memenuhi sasaran dari use case.

2.1.4.2 Class Diagram Menurut Whitten & Bentley (2007, p.400), merupakan

gambaran grafis dari struktur obyek sistem yang bersifat statis,

menunjukkan class object yang membentuk sistem serta relasi

antar class object tersebut. Dalam class diagram dikenal istilah

visibility, yaitu bagaimana atribut dan method didefinisikan untuk

diakses oleh class lain. Ada tiga macam visibility:

Tabel 2.2 Visibility pada Class Diagram Nama Simbol Keterangan

Public

“+”

Atribut bersifat public dapat

diakses dan dipanggil oleh

method pada class yang

berbeda.

Protected

“#”

Protected method dapat

dipanggil oleh method lain

dalam class dimana atribut atau

methoddidefinisikan atau

subclass dari class tersebut.

Private

“-”

Private method hanya dapat

dipanggil oleh method lain pada

class dimana atribut atau

method tersebut didefinisikan.

Relationship yang ada pada sebuah class adalah:

a. Association

Menurut Whitten & Bentley (2007, p.377) merupakan garis

penunjuk relasi yang menghubungkan antar class.

Gambar 2.8 Contoh Association Pada Class

Relasi di atas dapat dijelaskan bahwa user menempatkan nol atau

lebih order dan order ditempatkan oleh satu dan hanya satu user.

b. Generalization

Atribut dan perilaku dari kelas dikelompokan ke kelas dan

diwariskan ke kelas mereka sendiri (Whitten & Bentley, 2007,

p.373).

Gambar 2.9 Contoh Generalization (Sumber: Whitten & Bentley, 2007, p.376)

c. Dependency

Digunakan untuk memodelkan asosiasi antara dua class pada

dua instansi dengan tujuan mengindikasikan bahwa ketika terjadi

perubahan pada satu class akan berpengaruh pada class yang lain

dan sebagai indikasi asosiasi antara persistent class dan transient

class.

Sedangkan transient class adalah class yang mendeskripsikan

object yang object tersebut dibuat sementara oleh program dan

hanya akan hidup selama eksekusi program berlangsung (Whitten

& Bentley, 2007, p.650).

Gambar 2.10 Contoh Dependency Gambar diatas menjelaskan class order display window

merupakan class interface dan dibuat untuk menampilkan isi dari

order. Class order display window tergantung pada class place

new order handler untuk memetakan informasi dan class tersebut

akan merespon terhadap even.

d. Aggregation

Menurut Whitten & Bentley (2007, p.378), aggregation adalah

relasi dengan class yang lebih besar terdiri dari satu atau lebih

bagian kecil dari suatu class.

Gambar 2.11 Contoh Aggregation (Sumber Whitten & Bentley, 2007, 379)

e. Composition

Relasi class yang utuh memiliki tanggung jawab atas

pembentukan dan penghancuran bagian-bagiannya. Jika bagian

yang utuhnya hancur maka bagian-bagiannya juga akan ikut hancur

(Whitten & Bentley, 2007,p.378).

Gambar 2.12 Contoh Composition (Sumber Whitten & Bentley, 2007, 379)

2.1.4.3 Activity Diagram Menurut Whitten & Bentley (2007, p.390), merupakan diagram

yang digunakan untuk menggambarkan aliran proses bisnis,

langkah-langkah menggunakan use case atau logika behavior dari

object. Setidaknya untuk satu use case bisa menghasilkan satu

activity diagram, tetapi jika use case-nya panjang akan bisa

menghasilkan lebih dari satu activity diagram.

Tabel 2.3 Notasi Activity Diagram Nama

Simbol

Simbol Keterangan

Initial

Node

Gambar lingkaran penuh

yang merepresentasikan

dimulainya suatu proses.

Action

Persegi panjang berbentuk

bulat yang menyatakan

langkah-langkah kegiatan.

Flow

Anak panah pada diagram

yang mengindikasikan

progression. Kebanyakan

flow tidak memerlukan

penjelasan atau keterangan

yang mengidentifikasi

mereka kecuali flow yang

merupakan hasil.

Decision

Gambar berbentuk diamond

dengan arah satu flow masuk

dan dua flow keluar. Flow

yang keluar diberi keterangan

untuk mengindikasikan

kondisi.

Merge

Bentuk diamond dengan dua

atau lebih flow masuk dan

satu flow keluar. Merge

menggabungkan flow yang

sebelumnya terpisah oleh

decision.

Fork

Balok hitam dengan satu flow

masuk dan dua flow keluar.

Kegiatan yang bersifat paralel

ditandai menggunakan fork

agar dapat dieksekusi secara

bersamaan.

Join

Balok hitam dengan dua atau

lebih flow masuk dan satu

flow keluar, menandakan

berakhirnya proses yang

dieksekusi secara bersamaan.

Semua kegiatan yang masuk

ke join harus diselesaikan

terlebih dahulu sebelum

pemrosesan dilanjutkan.

Activity

final

lingkaran penuh yang berada

di dalam lingkaran berbentuk

garis menandakan akhir dari

proses.

2.1.4.4 Sequence Diagram Menurut Whitten & Bentley (2007, p.394), sequence diagram

merupakan diagram yang menggambarkan interaksi antara actor dan

sistem untuk use case scenario. Sequence menjelaskan bagaimana

object berinteraksi dengan yang lainnya melalui pesan pada waktu

eksekusi use case. Notasi yang digunakan dalam sequence diagram

dapat dilihat pada table berikut:

Tabel 2.4 Notasi Sequence Diagram No Nama Notasi Keterangan

1 Actor Actor yang memulai suatu kegiatan,

digambarkan dengan simbol actor dari

use case.

2 System Kotak yang mengindikasikan sistem

sebagai “blackbox” atau sepenuhnya.

Tanda “:” merupakan notasi standar pada

sequence diagram untuk menandakan

instansi pada sistem yang sedang berjalan.

3 Lifelines Garis putus-putus vertikal terbentang ke

bawah dari actor dan sistem, menandakan

kehidupan atau masa aktif dari sequence.

4 Activationbars Balok yang ada pada lifelines

mengindikasikan masa waktu ketika

partisipan dalam status aktif pada

interaksi.

5 Inputmessages Anak panah horizontal yang terbentang

dari actor ke sistem mengindikasikan

pesan yang masuk. Penulisannya adalah

huruf awal merupakan huruf kecil dan

menambahkan kata tambahan dengan

abjad awal berupa huruf kapital dan tanpa

spasi.

6 Outputmessages

Anak panah horizontal dari sistem ke

actor yang ditunjukkan dengan garis

putus-putus.

7 Receiveractor Actor lain atau sistem eksternal yang

menerima pesan dari sistem.

8 Frame Kotak yang dapat menyertakan satu atau

lebih pesan untuk memisahkan bagian

dari sequence. Frame dapat menyatakan

loop, bagian yang bersifat alternatif atau

langkah opsional. Untuk bagian opsional,

:

kondisi yang ditunjukkan pada kurung

siku menyatakan kondisi dimana langkah-

langkah tersebut akan dieksekusi apabila

memenuhi kondisinya.

2.1.5 Entity Relationship Diagram (ERD) Menurut Whitten & Bentley (2007, p.271), Entity Relationship

Diagram (ERD) adalah sebuah diagram yang menggambarkan data

dalam bentuk entitas-entitas beserta hubungan yang terbentuk antar

data tersebut. ERD tidak menyatakan bagaimana memanfaatkan data,

membuat data, menghapus data dan mengubah data. ERD merupakan

suatu alat utama pemodelan data dan membantu menggambarkan data

ke dalam entitas dan hubungan antar entitas. Elemen-elemen ERD

pada dasarnya, yaitu :

a. Entitas : sesuatu yang ada dalam sistem, baik nyata

maupun abstrak dimana data tersimpan atau

dimana terdapat data.

b. Relasi : hubungan alamiah yang terjadi antara entitas,

menyangkut dua komponen yang menyatakan

ikatan yang terjadi, yaitu cardinality dan

participation.

c. Atribut : deskripsi kelompok data yang mempunyai

karakteristik yang sama (data yang

mendeskripsikan entitas dan relasi).

Tabel 2.5 Simbol Entity Relationship Diagram

Simbol Keterangan

objek yang dapat diidentifikasikan

dengan objek lainnya.

karakteristik dari entitas. Atribut

hubungan yang terjadi antara satu

entity dengan entity lainnya

Penghubung atribut dengan entitas

dan relasi dengan entitas

Tabel 2.6 Simbol Cardinality

Interpretasi

Kardinalitas

Contoh

Minimum

Contoh

Maksimum

Notasi Grafis

Hanya 1

1

1

-atau-

0 atau 1

0

1

1 atau banyak

1

Banyak(>1)

0, 1, atau

banyak

0

Banyak(>1)

Lebih dari 1 (>1) (>1)

Langkah-langkah untuk membuat ERD, yaitu :

a. Identifikasi entitas

Mengidentifikasi peran, kejadian, lokasi, hal abstrak/konsep yang

datanya disimpan oleh end-user.

b. Menentukan relasi

Menentukan hubungan/relasi antara sepasang entitas

menggunakan relationship matriks.

c. Menggambar kasar ERD

Menggambarkan entitas-entitas dan relasi diantara entitas untuk

menghubungkannya.

d. Menentukan cardinality

Menentukan cardinality(pemunculan suatu entitas di entitas

lainnya yang berhubungan).

e. Menentukan primary key

Mengidentifikasi atribut data yang secara unik mengidentifikasi

setiap entitas.

f. Menggambar ERD berdasarkan atribut kunci

Menggambarkan ERD beserta primary key di setiap entitas.

g. Identifikasi atribut lainnya

Mengumpulkan informasi detail yang penting dalam sistem yang

sedang dikembangkan.

h. Memetakan atribut

Meletakkan atribut dalam satu entitas yang tepat serta mencari

atribut yang ada dalam relasi.

i. Menggambar ERD lengkap dengan atribut

Menggambarkan ERD dengan menyesuaikan ERD pada

langkah 6 dengan entitas atau relasi pada langkah 8.

j. Memeriksa hasil

Memeriksa ERD yang dihasilkan untuk mengetahui ketepatan

ERD dengan sistem.

2.1.6 Sistem Database

2.1.6.1 Sistem Sistem adalah Kumpulan dari komponen yang berfungsi untuk

mencapai tujuan spesifik (Satzinger, Jackson dan Burd, 2009, p.6).

Sistem adalah sususan dari beberapa dari komponen yang bekerja

bersama-sama untuk mencapai suatu tujuan utama atau beberapa

tujuan tertentu dengan cara menerima input dan memproses input

tersebut sehingga menghasilkan suatu output.

2.1.6.2 Database Menurut Connolly dan Begg (2010, p.65), database yakni

kumpulan logical data yang terkait dan data yang dirancang untuk

memenuhi kebutuhan informasi dari suatu organisasi.

2.1.6.3 Database Management System (DBMS) Menurut Connolly dan Begg (2010, p.66), sistem perangkat

lunak memungkinkan pengguna untuk mendefinisikan, membuat,

memelihara, dan mengontrol akses ke basis data. DBMS memiliki

beberapa fasilitas:

1. Pengguna dapat memasukkan, merubah, memungkinkan untuk

menentukan basis data, biasanya melalui Data Definition

Language (DDL). DDL memungkinkan pengguna untuk

menentukan jenis data, struktur, dan kendala pada data yang

akan disimpan dalam basis data.

2. Dapat juga digunakan untuk menghapus, dan mengambil data dari

database, biasanya melalui Data Manipulation Language (DML).

DML memiliki fasilitas untuk data yang disebut query language.

Bahasa query yang paling umum adalah Structured Query

Language (SQL) yang sekarang merupakan bahasa standar untuk

DBMS relational.

3. Menyediakan akses control ke database. Contohnya:

a. Sistem keamanan (security system), mencegah pengguna yang

tidak sah mengakses basis data.

b. Sistem integritas (integrity system), yang mempertahankan

konsistensi data yang disimpan.

c. Concurrency Control System, yang memungkinkan akses basis

data dapat tersebar.

d. Sistem control pemulihan (recovery control system), yang

mengembalikan keadaan basis data ke keadaan semula yang

konsisten.

e. Sebuah catalog yang dapat diakses pengguna, yang berisi dari

data dalam basis data.

2.1.7 User Interface (UI) Menurut Pressman (2010, p.319), ada beberapa langkah dalam

merancang user interface:

1. Interface Analysis and Modeling

Analisa antarmuka untuk interaksi antar pengguna dengan sistem.

Kemudian dianalisis untuk mendefinisikan satu set objek dan aksi

interface. Informasi yang dikumpulkan digunakan untuk membuat

model analisis untuk interface.

2. Interface Design

Interface design mendefinisikan desain satu set obyek dan aksi

antarmuka yang memungkinkan user untuk melakukan semua tugas

desain tata letak.

3. Interface Construction

Interface construction yakni membuat sebuah purwarupa yang

memungkinkan skenario penggunaan untuk dievaluasi dan

digunakan untuk menyelesaikan konstruksi interface.

4. Interface Validation

Setelah pembuatan prototype, interface validation berfokus pada

evaluasi secara keseluruhan untuk menentukan kemampuan

interface untuk menjalankan setiap perintah berjalan dengan

benar dan sejauh mana interface mudah digunakan dan mudah

dipelajari serta memenuhi kebutuhan user.

1.1.7.1 User Acceptance Test (UAT)

Menurut Hambling dan Goethem (2013, p.15), User

Acceptance Test (UAT) merupakan tahap akhir pengujian

perangkat lunak pada pengguna yang dilakukan sebelum

perangkat lunak tersebut diperkenalkan kepada sebuah organisasi.

Tujuan utamanya adalah untuk memastikan sistem yang baru

melakukan apa yang telah ditetapkan dan memenuhi kebutuhan

bisnis yang dibutuhkan.

1.1.7.2 Eight Golden Rules

Teori delapan aturan emas dari Shneiderman dan Plaisant (2010,

p.88):

a. Strive for Consistency

Berfokus pada rentetan aksi yang bersifat konsisten pada

situasi yang sama. Terminologi yang identik harus digunakan

pada prompts, menu, dan help screen, serta konsisten dalam hal

penggunaan warna, layout, kapitalisasi, font, dan lainnya.

Kecuali pada konfirmasi dalam perintah penghapusan atau

penampilan password yang harus dipertimbangkan dan dibatasi

penggunaannya.

b. Cater to Universal Usability

Memberikan penambahan fitur-fitur baru untuk pengguna

awam seperti penjelasan mengenai menu yang ada. Dan untuk

pengguna yang telah ahli disediakan fitur shortcut dan fitur

untuk navigasi yang lebih cepat. Hal tersebut dapat memperkaya

tampilan dan menambah kualitas sistem.

c. Offer Informative Feedback

Untuk setiap aksi dari user, harus ada respon dari sistem.

Untuk aksi yang kecil dan sering dilakukan, dapat digunakan

respon yang sederhana, sedangkan untuk aksi yang penting dan

jarang, dapat digunakan respon yang lebih kompleks.

d. Design Dialogue to Yield Closure

Umpan balik yang informatif memberikan rasa puas terhadap

pengguna bahwa hal yang dilakukan telah selesai maupun baru

akan dimulai. Misalnya situs e-commerce yang diakhiri dengan

halaman konfirmasi yang jelas bahwa transaksi yang dilakukan

telah berakhir.

e. Offer Simple Error Handling

Rancangan dari sistem harus menghindari terjadinya error

yang fatal. Misalnya memberikan warna peringatan terhadap

menu yang tidak sesuai atau tidak mengijinkan karakter alfabet

pada field numerik. Jika pengguna melakukan kesalahan, maka

sistem harus segera mendeteksi kesalahan tersebut dan

memberikan instruksi pemecahan masalah yang sederhana,

konstruktif dan spesifik untuk mengatasi error tersebut.

f. Permit Easy Reversal of Actions

Sebisa mungkin suatu aksi harus dapat dibatalkan. Fitur ini

akan menghilangkan kecemasan pengguna karena mereka tahu

bahwa error dapat diatasi, dan mendorong eksplorasi dari opsi-

opsi yang belum pernah dikunjungi sebelumnya.

g. Support Internal Focus of Control

Pengguna yang telah berpengalaman memiliki keinginan

yang kuat bahwa mereka memegang kendali atas interface

dan interface tersebut merespon terhadap aksi yang mereka

lakukan.

h. Reduce Short-Term Memory Load

Hal ini terjadi akibat keterbatasan kemampuan

mengingat otak manusia dalam memproses suatu informasi

yang diterima. Oleh karena itu perancang situs harus

menghindari kondisi dimana pengguna harus mengingat

informasi dari satu layar dan kemudian menggunakan

informasi tersebut pada layar lainnya. Itu berarti bahwa

nomor telepon harus dimasukkan sekali saja, lokasi situs web

harus tetap terlihat, dan harus ada pertimbangan terhadap

tampilan halaman web yang lebih dari satu.

1.1.7.3 Lima Faktor Manusia Terukur

Demi tercapainya tujuan dari IMK, maka perancangan

interface sebaiknya tidak lupa untuk mengikutsertakan evaluasi

terhadap lima (5) faktor terukur dari manusia sebagai berikut

(Shneiderman dan Plaisant, 2010, p.32-33):

1. Waktu untuk belajar

Ukuran berapa lama seorang user untuk mempelajari fungsi-

fungsi di dalam sebuah aplikasi hingga pada akhirnya dapat

menggunakan dengan baik.

2. Kecepatan performa

Ukuran berapa lama suatu fungsi atau serangkaian tugas di

dalam aplikasi tersebut dilakukan.

3. Tingkat error yang dilakukan pengguna

Ukuran berapa banyak dan jenis error yang dilakukan oleh

user di dalam melakukan serangkaian tugas.

4. Daya ingat pengguna

Ukuran berapa lama user mempertahankan ingatan dan

pengetahuannya setelah beberapa jam, hari, atau bahkan

mingu.

5. Kepuasan subjektif

Ukuran seberapa puas user atas berbagai aspek dari suatu

sistem.

2.1.8 Black Box Testing Menurut Pressman (2010, p.495) Black-Box testing berfokus pada

persyaratan fungsional perangkat lunak yang memungkinkan

engineers untuk memperoleh set kondisi input yang sepenuhnya

akan melaksanakan persyaratan fungsional untuk sebuah

program.Black-Box testing berusaha untuk menemukan kesalahan

dalam kategori berikut:

1. Fungsi yang tidak benar atau fungsi yang hilang

2. Kesalahan antarmuka

3. Kesalahan dalam struktur data atau akses database eksternal

4. Kesalahan perilaku (behavior) atau kesalahan kinerja

5. Inisialisasi dan pemutusan kesalahan

Tidak seperti White Box Testing yang dilakukan pada awal

proses pengujian, Black Box Testing cenderung diterapkan pada

tahap selanjutnya dari pengujian. Karena Black Box Testing sengaja

mengabaikan struktur kontrol, perhatian difokuskan pada domain

informasi. Pengujian ini dirancang untuk menjawab pertanyaan

berikut (Pressman, 2010, p.495):

a. Bagaimana validitas fungsional diuji?

b. Bagaimana perilaku sistem dan kinerja diuji?

c. Apakah kelas masukkan akan membuat kasus uji yang baik?

d. Apakah sistem sangat sensitif terhadap nilai masukkan tertentu?

e. Bagaimana batas-batas kelas data yang terisolasi?

f. Kecepatan data dan volume data apa yang dapat mentolerir

sistem?

g. Efek apa yang akan muncul dari kombinasi data tertentu

terhadap operasi sistem?

2.2 Teori Khusus

2.2.1 Android Menurut Nazruddin (2012, p1) Android adalah perangkat mobile

yang mencakup sistem operasi, middleware, dan aplikasi berbasis

Linux. Source code Android didistribusikan secara terbuka (open

source) sehingga pengembang dapat menciptakan aplikasi mereka

sendiri yang dapat digunakan untuk berbagai macam smartphone

dengan sistem operasi Android. Awalnya, Android dikembangkan

oleh perusahaan bernama Android Inc., hingga pada tahun 2005

perusahaan tersebut diakusisi oleh Google Inc. User application

dibuat dengan menggunakan bahasa pemrograman Java.

2.2.2 Java Menurut Deitel (2012, p2) Java adalah sebuah bahasa

pemrograman yang dapat memenuhi kebutuhan organisasi dengan

mengimplemantasi aplikasi berbasis internet dan pernagkat lunak

pada alat, yang terhubung melalui jaringan. Salah satu tujuan

dibentuknya bahasa pemrograman Java adalah untuk dapat menulis

program yang akan dijalankan pada berbagai macam sistem

komputer. Hal ini disebut dengan “write once, run anywhere.” Yang

artinya bahasa pemrograman Java dapat ditulis sekali namun dapat

digunakan dan dijalankan dimana saja (pada komputer apa saja).

2.2.3 Extensible Markup Language (XML) Menurut Hunter et al. (2007, p3), Extensible Markup Language

(XML) merupakan teknologi dengan aplikasi dunia nyata, khususnya

untuk manajemen, tampilan, dan organisasi data. XML bekerja dengan

tujuan markup dari setiap jenis data tetapi dengan kompleksitas yang di

eliminasi, XML tidak benar – benar merupakan bahasa, tetapi lebih

pada sintaks yang digunakan untuk menjelaskan markup lain.

2.2.4 PHP Menurut Deitel (2012, p17) PHP adalah sebuah bahasa naskah yang

berpendekatan objek, bersifat open source didukung oleh komunitas

pengguna dan pengembang. PHP merupakan platform mandiri karena

dapat diimplementasikan pada semua sistem operasi dan juga

mendukung beberapa database termasuk salah satunya MySQL.

2.2.5 Hypertext Markup Language (HTML) Menurut William and Sawyer (2011, p68) Hypertext Markup

Language (HTML) merupakan sebuah kumpulan untuk instruksi-

instruksi spesial biasa disebut “tags” atau “markups” yang digunakan

untuk menspesifikasi struktur, fomat dan penghubung multimedia

lainnya dalam web.

2.2.6 Javascript Menurut William & Sawyer (2011, p524) Javascript adalah bahasa

naskah berorientasi objek yang digunakan pada web browser dengan

menambahkan fungsi interaktif pada halaman web.

2.2.7 Cascading Style Sheet (CSS) Menurut Saputra dan Agustin (2011, p.6), kepanjangan dari

CSS adalah Cascading Style Sheet yang merupakan suatu bahasa

pemrograman suatu bahasa pemrgraman web yang digunakan untuk

mengendalikan dan membangun berbagai komponen dalam web

sehingga tampilan web akan lebih rapi, terstruktur, dan seragam.

2.2.8 MySQL Menurut Luke Welling (2009, p3) MySQL adalah Relational

Database Management System (RDMS) yang sangat cepat dan

tangguh. Pengguna dapat menyimpan, mencari, dan menyortir data

secara efisien.

2.3 Penelitian Terdahulu Terdapat berberapa penelitian terdahulu tentang aplikasi pariwisata yang

berbasis android. Salah satunya adalah “Strategi Pemerintah Kota Surakarta

dalam Mengembangkan E-Government (Studi Kasus Pada Aplikasi

Smartphone Solo Destination)” yang dipublikasikan pada tahun 2016.

Merupakan salah satu aplikasi kebanggaan Kota Solo dalam memudahkan

para wisatawan untuk menjelajahi Solo lewat genggaman.

Merujuk pada penelitian yang kedua yang dipublikasikan pada tahun 2014

yaitu “Sistem Informasi Pariwisata Kabupaten Malang Berbasis Android”,

dijelaskan tentang penggunaan smartphone yang sekarang sudah dapat

digunakan oleh berbagai lapisan masyarakat. Pariwisata bagi pemda adalah

salah satu aspek dalam meningkatkan pendapatan daerah. Adanya kendala

bagi pemda adalah kurangnya promosi yang informatif dan menarik untuk

para wisatawan yang hanya disuguhkan brosur, pamflet, poster dan buku.

2.4 Letak Geografis Kota Tangerang Letak Kota Tangerang terletak pada posisi 106 36 - 106 42 Bujur Timur (BT)

dan 6 6 - 6 Lintang Selatan (LS). Sebelah Utara berbatasan dengan Kecamatan

Teluk Naga dan Kecamatan Sepatan Kabupaten Tangerang, sebelah Selatan

berbatasan dengan Kecamatan Curug, Kecamatan Serpong dengan DKI Jakarta,

sedangkan sebelah Barat berbatasan dengan Kecamatan Cikupa Kabupaten

Tangerang.

Secara administratif luas wilayah Kota Tangerang dibagi dalam 13

kecamatan, yaitu Ciledug (8,769 Km2), Larangan (9,611 Km2), Karang Tengah

(10,474Km2), Cipondoh ((17,91 Km2), Pinang (21,59 Km2), Tangerang (15,785

Km2), Karawaci (13,475 Km2), Jatiuwung (14,406 Km2), Cibodas (9,611

Km2), Periuk (9,543 Km2), Batuceper (11,583 Km2), Neglasari (16,077 Km2),

dan Benda (5,919 Km2), serta meliputi 104 kelurahan dengan 981 rukun warga

(RW) dan 4.900 rukun tetangga (RT) (Letak Geografis, 2007).