III. METODOLOGI PENELITIAN
1. Inception
bisnis dan menjadikannya permasalahan dalam bisnis, membuat ruang lingkup
sistem, dan estimasi ketidakpastian.
2. Elaboration, merevisi visi yang ada, mengurangi resiko terbesar dengan cara
menangani tugas-tugas tersulit yang ada agar estimasi biaya dan penjadwalan
dapat diperbarui, dan mendesain, mengimplementasikan, testing, dan membuat
garis besar inti arsitektur, mengidentifikasi kebutuhan dan ruang lingkup yang
paling besar.
3. Construction, membangun keseluruhan sistem mulai dari elemen terbesar
hingga yang terkecil secara bertahap. Akhir dari fase ini adalah sebuah sistem
software tahap beta yang sudah terdokumentasi dan dapat digunakan oleh
4. Transition, testing sistem dan memenuhi sisa kebutuhan pengguna yang masih
belum terpenuhi sebelum dilepas ke pasaran.
Seperti yang terlihat pada Gambar 2.6, setiap fase pada Unified Process memiliki
iterasinya sendiri-sendiri dimana dari setiap iterasi tersebut akan menghasilkan
sistem yang bekerja sampai pada tahap tertentu sehingga memungkinkan pengguna
melihat peningkatan yang terjadi.
2.8.2.Unified Modeling Language (UML)
Unified Modeling Language (UML) adalah keluarga notasi grafis yang didukung
oleh meta-model tunggal, yang membantu pendeskripsian dan desain sistem
perangkat lunak, khususnya sistem yang dibangun menggunakan pemrograman
berorientasi objek (OO). Definisi ini merupakan definisi yang sederhana. Pada
kenyataannya, pendapat orang – orang tentang UML berbeda satu sama lain. Hal ini dikarenakan oleh sejarahnya sendiri dan oleh perbedaan persepsi tentang apa
yang membuat sebuah proses rancang – bangun perangkat lunak efektif.
Unified Modeling Language (UML) merupakan strandar yang relatif terbuka yang
dikontrol oleh Object Management Group (OMG), sebuah konsorsium terbuka
yang terdiri dari banyak perusahaan. OMG dibentuk untuk membuat standar –
standar yang mendukung interoperabilitas, khusunya interoperabilitas sistem
berorientasi objek. OMG mungkin lebih dikenal dengan standar – standar COBRA (Common Object Request Broker Architecture).
UML lahir dari penggabungan banyak bahasa permodelan grafis berorientasi objek
yang berkembang pesat pada akhir 1980-an dan awal 1990-an. UML dibuat oleh
Grady Booch, James Rumbaugh, dan Ivar Jacobson di bawah bendera Rational
Software Corp. UML menyediakan notasi-notasi yang membantu memodelkan
sistem dari berbagai perspektif. UML tidak hanya digunakan dalam pemodelan
perangkat lunak, namun hampir dalam semua bidang yang membutuhkan
pemodelan (Fowler, 2004).
UML dideskripsikan oleh beberapa diagram, yaitu sebagai berikut.
1. Use case Diagram
Use case Diagram digunakan untuk menggambarkan sistem dari sudut pandang
pengguna sistem tersebut (user), sehingga pembuatan use case diagram lebih
dititikberatkan pada fungsionalitas yang ada pada sistem, bukan berdasarkan alur
atau urutan kejadian. Sebuah use case diagram merepresentasikan sebuah interaksi
antara aktor dengan sistem (Fowler, 2004).
Komponen-komponen dalam use case diagram (Fowler, 2004) :
a. Aktor
Pada dasarnya aktor bukanlah bagian dari use case diagram, namun untuk dapat
terciptanya suatu use case diagram diperlukan aktor, dimana aktor tersebut
mempresentasikan seseorang atau sesuatu (seperti perangkat atau sistem lain)
yang berinteraksi dengan sistem yang dibuat. Sebuah aktor mungkin hanya
memberikan informasi inputan pada sistem, hanya menerima informasi dari
hanya berinteraksi dengan use case, tetapi tidak memiliki kontrol atas use case.
Aktor digambarkan dengan stick pan seperti yang terdapat pada Gambar 2.7.
Gambar 2.7 Contoh Aktor (Fowler, 2004).
b. Use Case
Gambaran fungsionalitas dari suatu sistem, sehingga pengguna sistem paham
dan mengerti kegunaan sistem yang akan dibangun. Bentuk use case dapat
terlihat pada Gambar 2.8.
Gambar 2.8 Use Case (Fowler, 2004).
Ada beberapa relasi yang terdapat pada use case diagram:
1. Association, menghubungkan link antar element.
2. Generalization, disebut juga pewarisan (inheritance), sebuah elemen dapat
merupakan spesialisasi dari elemen lainnya.
3. Dependency, sebuah element bergantung dalam beberapa cara ke element
lainnya.
Tipe relasi yang mungkin terjadi pada use case diagram:
1. <<include>>, yaitu kelakuan yang harus terpenuhi agar sebuah event dapat
terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case
lainnya.
2. <<extends>>, kelakuan yang hanya berjalan di bawah kondisi tertentu seperti
menggerakkan peringatan
3. <<communicates>>, merupakan pilihan selama asosiasi hanya tipe
relationship yang dibolehkan antara aktor dan use case.
Berikut adalah bentuk dari use case diagram yang dapat dilihat pada Gambar 2.9.
2. Activity Diagram
Menggambarkan rangkaian aliran dari aktivitas, digunakan untuk mendeskripsikan
aktivitas yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk
aktifitas lainnya (Fowler, 2004).
Notasi Activity Diagram dapat dilihat pada Tabel 2.1.
Tabel 2.1 Notasi Activity Diagram(Meildy, 2014).
Simbol Keterangan
Titik Awal
Titik Akhir
Activity
Pilihan untuk mengambil keputusan
Fork; Digunakan untuk menunjukkan kegiatan yang dilakukan secara paralel atau untuk menggabungkan dua kegiatan paralel menjadi satu. Rake; Menunjukkan adanya dekomposisi
Tanda Waktu
Tanda pengiriman
Tanda penerimaan
Aliran akhir (Flow Final)
Diagram ini mirip dengan flowchart karena memodelkan workflow dari satu
diagram pada awal pemodelan proses dapat membantu memahami keseluruhan
proses. Activity diagram digunakan untuk menggambarkan interaksi antara
beberapa use case (Fowler, 2004).
Berikut adalah bentuk dari activity diagram yang dapat dilihat pada Gambar 2.10.
3. Class Diagram
Class adalah sebuah spesifikasi yang akan menghasilkan sebuah objek dan
merupakan inti dari pengembangan dan desain berorientasi objek. Class
menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan
layanan untuk memanipulasi keadaan tersebut (metode/fungsi). Class Diagram
menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan
satu sama lain seperti pewarisan, asosiasi, dan lain-lain (Fowler, 2004).
Bentuk dari class diagram dapat terlihat pada Gambar 2.11.
Class memiliki tiga area pokok :
1. Nama (ClassName)
2. Atribut
3. Metode (Operations)
Pada UML, class digambarkan dengan segi empat yang dibagi beberapa bagian.
Bagian atas merupakan nama dari class. Bagian yang tengah merupakan struktur
dari class (atribut) dan bagian bawah merupakan sifat dari class (metode/operasi).
Atribut dan metode dapat memiliki salah satu sifat berikut :
1. Private , tidak dapat dipanggil dari luar class yang bersangkutan.
2. Protected, hanya dapat dipanggil oleh class yang bersangkutan dan class lain
yang mewarisinya.
3. Public, dapat dipanggil oleh class lain (Fowler, 2004).
Hubungan antar class:
Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang
memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi
class lain.
1. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas”).
2. Pewarisan, yaitu hubungan hirarki antar class. Class dapat diturunkan dari class
lain dan mewarisi semua atribut dan metode class asalnya serta bisa
menambahkan fungsionalitas baru. Sehingga class tersebut disebut anak dari
3. Hubungan dinamis, yaitu rangkaian pesan (message) yang di- class dari satu
class kepada class lain. Hubungan dinamis dapat digambarkan dengan
menggunakan sequence diagram yang akan dijelaskan kemudian (Fowler,
2004).
4. Statechart Diagram
Menggambarkan semua state (kondisi) yang dimiliki oleh suatu objek dari suatu
class dan keadaan yang menyebabkan state berubah. Statechart diagram tidak
digambarkan untuk semua class, hanya yang mempunyai sejumlah state yang
terdefinisi dengan baik dan kondisi class berubah oleh state yang berbeda. State
adalah sebuah kondisi selama kehidupan sebuah objek atau ketika objek memenuhi
beberapa kondisi, melakukan beberapa aksi atau menunggu sebuah event. State dari
sebuah objek dapat dikarakteristikkan oleh nilai dari satu atau lebih atribut-atribut
dari class. State dari sebuah objek ditemukan dengan pengujian/pemeriksaan pada
atribut dan hubungan dari objek. Notasi UML untuk state adalah persegi
panjang/bujur sangkar dengan ujung yang dibulatkan. Masing-masing diagram
harus mempunyai satu dan hanya satu start state ketika objek mulai dibuat. Sebuah
objek boleh mempunyai banyak stopstate. (Fowler, 2004).
Sebuah state transition dapat mempunyai sebuah aksi dan/atau sebuah kondisi
penjaga (guard condition) yang terasosiasi dengannnya, dan mungkin juga
memunculkan sebuah event. Sebuah aksi adalah kelakuan yang terjadi ketika state
transition terjadi. Sebuah event adalah pesan yang dikirim ke objek lain di sistem.
atribut-atribut yang mengijinkan sebuah state transition hanya jika kondisinya benar.
Kedua aksi dan penjaga adalah kelakuan dari objek dan secara tipikal menjadi
operasi (Fowler, 2004). Contoh statechart diagram disajikan pada Gambar 2.12.
Gambar 2.12 Contoh Statechart Diagram (uml-diagrams.org, 2014).
5. Sequence Diagram
Menggambarkan interaksi antara sejumlah objek dalam urutan waktu.
Kegunaannya untuk menunjukkan rangkaian pesan yang dikirim antara objek juga
interaksi antar objek yang terjadi pada titik tertentu dalam eksekusi sistem. (Fowler,
2014).
Notasi Sequence Diagram dapat dilihat pada Tabel 2.2.
Tabel 2.2 Notasi Sequence Diagram(Meildy, 2014).
Simbol Nama Keterangan
Object Object merupakan instance dari sebuah class dan dituliskan tersusun secara horizontal.
Digambarkan sebagai sebuah class (kotak) dengan nama obyek
Simbol Nama Keterangan
didalamnya yang diawali dengan sebuah titik koma
Actor Actor juga dapat berkomunikasi dengan object, maka actor juga dapat diurutkan sebagai kolom. Simbol Actor sama dengan simbol pada Actor Use Case Diagram.
Lifeline Lifeline mengindikasikan keberadaan sebuah object dalam basis waktu. Notasi untuk Lifeline adalah garis putus-putus vertikal yang ditarik dari sebuah obyek.
Activation Activation dinotasikan sebagai sebuah kotak segi empat yang digambar pada sebuah lifeline. Activation mengindikasikan sebuah obyek yang akan melakukan sebuah aksi.
Message Message, digambarkan dengan anak panah horizontal antara Activation. Message
mengindikasikan komunikasi antara object-object.
Berikut adalah contoh dari sequence diagram yang dapat dilihat pada Gambar
2.13.
Gambar 2.13 Contoh Sequence Diagram (uml-diagrams.org, 2014).
6. Collaboration Diagram
Diagram ini menggambarkan interaksi objek yang diatur objek sekelilingnya dan
hubungan antara setiap objek dengan objek yang lainnya. Dalam menunjukkan
pertukaran pesan, collaboration diagram menggambarkan objek dan hubungannya
diagram, tapi jika penekanannya pada konteks gunakan collaboration diagram
Contoh dari collaboration diagram dapat dilihat pada Gambar 2.14 (Fowler, 2004).
Gambar 2.14 Contoh Collaboration Diagram (Fowler, 2014).
2.8.2.1 Keunggulan UML
Secara umum UML diterapkan dalam pengembangan sistem/perangkat lunak
berorientasi obyek sebab metodologi UML ini umumnya memiliki
keunggulan-keunggulan sebagai berikut (Nugroho, 2005) :
1. Uniformity. Dengan metodologi UML, para pengembang cukup menggunakan
dilakukan dalam metodologi pengembangan terstruktur. Dengan
perkembangan masa kini ke arah aplikasi GUI (Graphical User Interface),
UML juga memungkinkan kita merancang komponen antarmuka pengguna
(user interface) secara integrasi bersama dengan perancangan perangkat lunak
sekaligus dengan perancangan basis data.
2. Understandability. Dengan metodologi ini kode yang dihasilkan dapat
diorganisasi ke dalam kelas-kelas yang berhubungan dengan masalah
sesungguhnya sehingga lebih mudah dipahami siapapun juga.
3. Stability. Kode program yang dihasilkan relatif stabil ssepanjang waktu sebab
sangat mendekati permasalahan sesungguhnya di lapangan.
4. Reusability. Dengan metodologi berorientasi obyek, dimungkinkan
penggunaan ulang kode, sehingga pada gilirannya akan sangat mempercepat
waktu pengembangan perangkat lunak.
2.9 Pengujian Perangkat Lunak
Pengujian perangkat lunak adalah proses menjalankan dan mengevaluasi sebuah
perangkat lunak secara manual maupun otomatis untuk menguji apakah perangkat
lunak sudah memenuhi persyaratan atau belum (Clune, 2011). Singkat kata,
pengujian adalah aktivitas untuk menemukan dan menentukan perbedaan antara
hasil yang diharapkan dengan hasil sebenarnya. Berikut merupakan penjelasan
lebih rinci dari pengujian perangkat lunak baik itu teknik maupun metode yang
2.9.1 Teknik Pengujian Perangkat Lunak
Ada dua macam pendekatan kasus uji yaitu white-box dan black-box. Pendekatan
white-box adalah pengujian untuk memperlihatkan cara kerja dari produk secara
rinci sesuai dengan spesifikasinya (Jiang, 2012). Jalur logika perangkat lunak akan
dites dengan menyediakan kasus uji yang akan mengerjakan kumpulan kondisi dan
pengulangan secara spesifik. Sehingga melalui penggunaan metode ini akan dapat
memperoleh kasus uji yang menjamin bahwa semua jalur independen pada suatu
model telah diigunakan minimal satu kali, penggunaan keputusan logis pada sisi
benar dan salah, pengeksekusian semua loop dalam batasan dan batas operasional
perekayasa, serta penggunaan struktur data internal guna menjamin validitasnya
(Pressman, 2010).
Pendekatan black-box merupakan pendekatan pengujian untuk mengetahui apakah
semua fungsi perangkat lunak telah berjalan semestinya sesuai dengan kebutuhan
fungsional yang telah didefinisikan (Jiang, 2012). Kasus uji ini bertujuan untuk
menunjukkan fungsi perangkat lunak tentang cara beroperasinya. Teknik pengujian
ini berfokus pada domain informasi dari perangkat lunak, yaitu melakukan kasus
uji dengan mempartisi domain input dan output program. Metode black-box
memungkinkan perekayasa perangkat lunak mendapatkan serangkaian kondisi
input yang sepenuhnya menggunakan semua persyaratan fungsional untuk suatu
program. Pengujian ini berusaha menemukan kesalahan dalam kategori
fungsi-fungsi yang tidak benar atau hilang, kesalahan interface, kesalahan dalam struktur
data atau akses basis data eksternal, kesalahan kinerja, dan inisialisasi dan
Teknik pengujian yang digunakan dalam penelitian ini terbagi atas pengujian
fungsional dan pengujian non fungsional. Adapun pengujian fungsional
menggunakan metode black box yaitu Equivalence Partitioning dan pengujian non
fungsional menggunakan angket yang penyusunan bentuk jawaban dari pertanyaan
menggunakan skala likert.
2.9.2 Equivalence Partitioning
Equivalence Partitioning (EP) merupakan metode black box testing yang membagi
domain masukan dari program kedalam kelas-kelas sehingga test case dapat
diperoleh. Equivalence Partitioning berusaha untuk mendefinisikan kasus uji yang
menemukan sejumlah jenis kesalahan, dan mengurangi jumlah kasus uji yang harus
dibuat. Kasus uji yang didesain untuk Equivalence Partitioning berdasarkan pada
evaluasi dari kelas ekuivalensi untuk kondisi masukan yang menggambarkan
kumpulan keadaan yang valid atau tidak. Kondisi masukan berupa spesifikasi nilai
numerik, kisaran nilai, kumpulan nilai yang berhubungan atau kondisi boolean.
Kesetaraan kelas dapat didefinisikan menurut panduan berikut (Pressman, 2001) :
1. Jika masukan kondisi menentukan kisaran, satu sah dan dua diartikan tidak
valid kesetaraan kelas.
2. Jika masukan membutuhkan nilai, kondisi tertentu satu sah dan dua tidak valid
kesetaraan kelas diartikan.
3. Jika masukan kondisi menentukan anggota dari set, satu sah dan satu tidak valid
kesetaraan kelas diartikan.
2.9.3 Skala Likert
Menurut Likert dalam buku Azwar S (2011), sikap dapat diukur dengan metode
rating yang dijumlahkan (Method of Summated Ratings). Metode ini merupakan
metode penskalaan pernyataan sikap yang menggunakan distribusi respons sebagai
dasar penentuan nilai skalanya. Nilai skala setiap pernyataan tidak ditentukan oleh
derajat favourable nya masing-masing akan tetapi ditentukan oleh distribusi
respons setuju dan tidak setuju dari sekelompok responden yang bertindak sebagai
kelompok uji coba (pilot study) (Azwar, 2011).
Skala Likert, yaitu skala yang berisi lima tingkat preferensi jawaban dengan pilihan
sebagai berikut: 1 = sangat tidak setuju; 2 = tidak setuju; 3 = ragu–ragu atau netral; 4 = setuju; 5 = sangat setuju. Selanjutnya pada tahun 2006, Yitnosumarto
menjelaskan penentuan kategori interval tinggi, sedang, atau rendah digunakan
rumus sebagai berikut :
� = �� − ��� Keterangan :
I = Interval;
NT = Total nilai tertinggi;
NR = Total nilai terendah;
BAB III
METODOLOGI PENELITIAN
3.1 Waktu dan Tempat Penelitian
Penelitian ini dilakukan di Fakultas Matematika dan Ilmu Pengetahuan Alam
Universitas Lampung yang berada di jalan Soemantri Brojonegoro No.1 Gedung
Meneng, Bandar Lampung. Penelitian ini dilaksanakan mulai dari semester genap
tahun ajaran 2014/2015 sampai dengan semester ganjil tahun ajaran 2015/2016.
3.2Alat Pendukung Penelitian
Penelitian ini dilakukan dengan menggunakan alat untuk mendukung dan
menunjang pelaksanaan penelitian.
1. Perangkat Keras
Perangkat keras yang digunakan pada pengembangan sistem ini yaitu laptop
dengan spesifikasi :
a. Prosessor Intel Core i3-2310M CPU @ 2,1 GHz
b. VGA Intel HD Graphic 3000
c. RAM 4GB
2. Perangkat Lunak
Perangkat lunak yang digunakan dalam pengembangan sistem ini yaitu :
a. Sistem Operasi Windows 8.1 (64 Bit)
b. Eclipse Luna
c. Astah Community Version 37
d. Paint Version 6.3
e. Microsoft Picture Manager
f. Adobe Photo Shop CS6
g. Web Browser (Google Chrome)
3.3Metodologi Penelitian
Pada tahapan metodologi penelitian ini terdapat beberapa tahapan, seperti alir
penelitian, metode pengembangan sistem, jadwal kegiatan penelitian, metode
pengumpulan data, serta jenis dan sumber data. Berikut merupakan penjelasan
secara rinci dari masing-masing tahapan tersebut.
3.3.1 Alir Penelitian
Penelitian dilakukan berdasarkan diagram alir metodologi penelitian yang terdapat
1. Identifikasi Masalah
2. Perumusan Masalah
3. Tujuan, Manfaat dan Batasan
4. Survei Pendahuluan
- Observasi 5. Studi Literatur
6. Inception - Pengumpulan Data
- Analisis Kebutuhan Dasar Sistem - Analisis User Requirement
8. Construction 1 - Pembuatan Program (Koding)
9. Construction 2 - Pengujian
10. Transition - Penyerahan aplikasi ke-user (roll-out)
Sistem Bekerja Sesuai Analisis? Tidak
Ya
11. Analisis Hasil Penelitian A. Langkah I B. Langkah II C. Langkah III 7. Elaboration - Perancangan UML - Perancangan antarmuka
Penjelasan rinci dari diagram alir metodologi penelitian pada Gambar 3.1 adalah
sebagai berikut.
A. Langkah I
1. Pada langkah pertama, yang dilakukan pada tahap pertama adalah identifikasi
masalah. Identifikasi masalah adalah pengenalan masalah atau inventarisir
masalah. Masalah penelitian akan menentukan kualitas dari penelitian, bahkan
juga menentukan apakah sebuah kegiatan bisa disebut penelitian atau tidak.
2. Tahap kedua adalah perumusan masalah. Rumusan masalah adalah pertanyaan
penelitian, yang umumnya disusun dalam bentuk kalimat tanya,
pertanyaan-pertanyaan tersebut akan menjadi arah kemana sebenarnya penelitian akan
dibawa, dan apa saja sebenarnya yang ingin dikaji.
3. Tahap ketiga adalah menentukan tujuan, manfaat dan batasan. Target
pencapaian dalam tahap ini adalah diketahuinya tujuan dan manfaat dari
aplikasi pencarian SPBU terdekat yang ada di Kota Bandar Lampung.
Sedangkan batasan digunakan untuk membatasi pembahasan dan ruang lingkup
penelitian.
4. Tahap keempat adalah survei pendahuluan. Survei pendahuluan ini
dimaksudkan untuk mengetahui hal-hal penting yang berhubungan dengan
penelitian.
5. Tahap kelima adalah studi literatur. Studi literatur ini ditujukan untuk
mendapatkan teori-teori dan hasil-hasil penelitian terlebih dahulu yang akan
B. Langkah II
6. Memasuki langkah kedua. Langkah kedua adalah pengembangan sistem.
Metode pengembangan sistem yang digunakan dalam penelitian ini adalah
Unified Process. Tahap pertama yang dilakukan dalam pengembangan sistem
ini adalah inception. Pada tahap ini akan dilakukan pengumpulan data berupa
data lokasi SPBU yang ada di Kota Bandar Lampung. Pada tahap ini juga akan
dilakukan analisis kebutuhan dasar sistem dan analisis user requirement.
7. Tahap ketujuh adalah Elaboration. Pada tahap ini akan dilakukan perancangan
sistem dan perancangan antarmuka. Perancangan atau desain sistem dalam
penelitian ini menggunakan Unified Modelling Language (UML), pada tahap
ini akan diketahui semua entitas luar, input dan output yang terlibat dalam
sistem serta usecase, class diagram, activity diagram, sequence diagram yang
digunakan dalam analisis sistem. Selanjutnya akan dilakukan perancangan
antarmuka (interface), perancangan antarmuka ini dilakukan untuk merancang
tata letak sistem sesuai dengan analisis kebutuhan sistem.
8. Tahap kedelapan adalah construction 1. Pada tahap ini akan dilakukan
pembuatan program (coding).
9. Tahap kesembilan adalah construction 2. Setelah pembuatan program selesai,
maka akan dilakukan pengujian. Pendekatan kasus uji dalam penelitian ini
adalah pengujian black box dengan metode Equivalence Partitioning (EP). Jika
sistem tidak bekerja sesuai analisis, maka kembali ke tahap construction 1 dan
jika sistem bekerja sesuai analisis maka dilakukan tahap selanjutnya.
10.Tahap kesepuluh adalah transition. Pada tahap ini akan dilakukan penyerahan
C. Langkah III
11.Tahap kesebelas adalah analisis hasil penelitian. Tahap ini dilakukan untuk
mengetahui hasil yang telah diperoleh selama melakukan penelitian, apakah
hasil dapat mengatasi permasalahan yang dideskripsikan di awal.
3.3.2 Metode Pengembangan Sistem
Penelitian ini dilakukan berdasarkan metode pengembangan sistem yang dipilih
yaitu Unified Process (UP). Tahap-tahap yang dilakukan dalam pengembangan
sistem aplikasi Cari SPBU ini adalah sebagai berikut.
1. Inception
Pada tahap ini dilakukan pengumpulan data berupa data lokasi SPBU yang ada
di Kota Bandar Lampung. Data ini diperoleh melalui 2 cara yaitu dengan
menggunakan aplikasi bernama GPS Locator pada sebuah perangkat android
dan juga berdasarkan informasi dari situs resmi pertamina. Data spasial dalam
penelitian ini terdiri dari 32 titik koordinat lokasi SPBU Pertamina dan 1 titik
koordinat SPBKB AKR yang tersebar di seluruh Kota Bandar Lampung.
Selanjutnya apabila telah didapat sebanyak 33 titik koordinat tersebut, maka
dibuat Point of Interest (POI) yang digunakan sebagai penanda dari setiap titik
pada lokasi-lokasi SPBU yang ada di Kota Bandar Lampung.
Pada tahap ini juga dilakukan analisis kebutuhan dasar sistem dan analisis user
requirement. Analisis kebutuhan dasar sistem dilakukan untuk menentukan
requirement dilakukan untuk menentukan kebutuhan spesifikasi perangkat
keras (hardware) dan perangkat lunak (software) yang berperan dalam desain
sistem dan generate code pada sistem.
2. Elaboration
Pada tahap ini akan dilakukan perancangan sistem dan perancangan antarmuka.
Perancangan atau desain sistem dalam penelitian ini menggunakan Unified
Modelling Language (UML). Diagram-diagram UML yang dibuat dalam
penelitian ini antara lain sebagai berikut :
a. Use case diagram : digunakan untuk menggambarkan sistem dari sudut pandang
pengguna sistem tersebut (user), sehingga pembuatan use case diagram ini lebih
dititikberatkan pada fungsionalitas yang ada pada sistem, bukan berdasarkan
alur atau urutan kejadian. Pada aplikasi ini pengguna dapat melakukan 5 (lima)