menghasilkan proses yang ada dalam Use Case.
b. Membuat perancangan basis data dengan tahapan sebagai berikut:
i. Membuat LRS Logical Record Structured Penulis menvisualisasikan struktur kelas-
kelas dari suatu sistem dan memperlihatkan hubungan antar kelas dan penjelasan detail
tiap-tiap kelas di dalam model desain dalam logical view dari suatu sistem.
ii. Membuat Model Data Relasional Model Data Relasional ini dimaksudkan agar
alur penurun Primary Key menjadi Foreign Key ditabel lain menjadi lebih terlihat jelas.
iii. Membuat Spesifikasi Basis Data Spesifikasi basis data ini dimaksudkan agar
setiap atribut dari sebuah tabel dapat terlihat dengan jelas untuk pembuatan database.
iv. Membuat Matriks Data-to-Location-CRUD Matriks
Data-to-Location-CRUD dibuat
untuk mengidentifikasi data dan hak akses apa yang diperlukan dan di lokasi mana.
c. Membuat desain antarmuka dari aplikasi native dan dashboard dengan menggunakan Balsamiq Mockups
for Desktop berdasarkan panduan atau guide line yang sudah ditentukan oleh sistem operasi Windows
Phone untuk aplikasi native.
3.4.1.3 Fase Implementasi
Penganalisis bekerja dengan para pengguna secara intens selama workshop untuk merancang aspek-aspek bisnis
dan non-teknis dari sistem. Segera sesudah aspek-aspek ini disetujui dan sistem-sistem dibangun dan disaring, sistem-
sistem baru atau bagian dari sistem di uji coba dan kemudian diperkenalkan kepada organisasi. Pada tahap ini penulis
melakukan beberapa tahap implementasi, diantaranya sebagai berikut:
a. Melakukan pengkodean aplikasi aplikasi baik yang berada di sisi native application, API, dan sisi
aplikasi dashboard. b. Instalasi aplikasi konten ke server hosting internet
agar dapat diakses secara online. c. Instalasi ke device Windows Phone.
d. Melakukan penginputan data merchant ke dalam basis data lokal.
e. Pengujian atau testing pada device Windows Phone secara metode pengujian Blackbox, yaitu dengan
mengetahui fungsi yang ditentukan dimana produk dirancang untuk melakukan sesuatu, pengujiannya
dapat dilakukan untuk memperlihatkan bahwa masing-masing fungsi beroperasi sepenuhnya, pada
waktu yang sama mencari kesalahan pada setiap fungsi.
3.5. Alasan Menggunakan RAD
Berikut akan dijelaskan beberapa alasan penulis menggunakan metodologi pengembangan sistem RAD dalam merancang dan
mengembangkan mobile marketing berbasis Windows Phone. Menurut Whitten 2004, RAD memungkinkan:
Lebih aktif melibatkan para pengguna sistem dalam aktivitas analisis, desain, dan konstruksi. Sehingga klien dapat berperan aktif
memberi masukan atau arahan dalam pengembangan sistem ini. Proses RAD memungkinkan menciptakan sistem fungsional yang
utuh dalam periode yang pendek sehingga sesuai dengan penelitian ini karena kebutuhan yang ada dapat dipahami dengan baik.
Mengakselerasi fase-fase analisis dan desain persyaratan melalui pendekatan konstruksi berulang. RAD dapat mengembangkan
aplikasi dengan
cepat dan
secara berkelanjutan
mengimplementasikan perancangan dan spesifikasi kebutuhan menggunakan framework seperti Silverlight.
Berikut adalah perbandingan beberapa metodologi pengembangan sistem:
Tabel 3.1 Perbandingan Metodologi Pengembangan Sistem
Model Pengembangan Kelebihan
Kekurangan
Waterfall - Digunakan jika kebutuhan pelanggan
sudah dipahami - Kecil kemungkinan perubahan kebutuhan
selama pengembangan sistem - Struktur tahapan jelas
- Terjadinya kesulitan
jika terjadi
perubahan kebutuhan - Sistem yang diserahkan dapat menjadi
tidak fleksibel - Harapan
akan spesifikasi
dapat didefinisikan secara keseluruhan di
depan sehingga kadang tidak realistis Prototype
- Pendefinisian kebutuhan pemakai lebih baik karena keterlibatan pemakai yang
lebih intensif. - Memperkecil kesalahan disebabkan pada
setiap versi prototype kesalahan segera terdeteksi oleh pemakai.
- Pemakai mempunyai kesempatan dalam meminta perubahan-perubahan.
- Apabila prototype tak dikelola dengan baik dapat mengakibatkan prototype tak
pernah berakhir
karena usulan
perubahan terlalu sering dipenuhi. - Waktu yang singkat menghasilkan
sistem yang tidak lengkap dan kurang teruji.
- Dokumentasi sering terabaikan karena pengembang lebih berkonsentrasi pada
tahap pengujian
dan pembuatan
prototype. Incremental Prototype
- Digunakan untuk menyelesaikan sistem secara global terlebih dahulu, kemudian
untuk feature
dari sistem
akan dikembangkan kemudian
- Batasan proses tidak jelas - Sistem tidak terstruktur
- Mempercepat pengimplementasian proyek - Memiliki risiko yang rendah
Spiral -
Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap
risiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama
proses
- Menggunakan
prototype sebagai
mekanisme pengurangan risiko dan pada setiap keadaan di dalam evolusi produk
- Memerlukan penaksiran risiko yang masuk akal dan akan menjadi masalah
yang serius jika risiko yang besar tidak bisa ditemukan atau diatur
- Terlalu banyak memikirkan risiko yang akan terjadi sehingga banyak
waktu yang terbuang - Masih jarang digunakan
Rational Unified Process -
Mendukung proses pengulangan dalam pengembangan software.
- Memungkinkan adanya penambahan-
penambahan pada proses. -
Memungkinkan untuk secara sistematis mengontrol perubahan-perubahan yang
terjadi pada software selama proses pengembangannya.
- Metodologi ini hanya dapat digunakan
pada pengembangan perangkat lunak yang berorientasi objek dengan
berfokus pada UML Unified Modeling Language
Rapid Application Development -
Siklus pembangunan yang pendeksingkat karena jika ada modul yang salah maka
akan langsung dibuang
- fleksibilitas yang besar
- mengurangi biaya
- Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini.
- Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi
3.6. Kerangka Berpikir
Mulai Metode Pengumpulan
Data Nazir, 2009
Wawancara Observasi
Studi Kepustakaan
Metode Pengembangan Sistem
Rapid Application Develoment
Kendall dan Kendall, 2008 Fase Perencanaan
Syarat-syarat Gambaran Umum PT.
Yotomo Indonesia Sejarah Singkat
Struktur Organisasi Visi, Misi, dan Tujuan
Analisis Sistem Berjalan Proses Bisnis Berjalan
Pengujian Aplikasi Yotomo
Identifikasi Masalah
Analisis Sistem Usulan Pemecahan Masalah
Proses Bisnis Usulan Kebutuhan Sistem Usulan
Workshop Desain RAD Desain Sistem
Use Case Diagram Activity Diagram
Class Diagram Sequence Diagram
Desain Antarmuka GUI Graphic User Interface
Penulisan Kode Program
Black Box Instalasi Aplikasi Native
Pengujian Fase Implementasi
Selesai Proses Bisnis Berjalan dan Rencana Pengembangan
Sistem Berjalan Kelebihan dan Kekurangan
Sistem Berjalan Perbandingan Produk Mobile Marketing Yotomo dengan
Standarisasi Tiga Domain Fitur Aplikasi Mobile Marketing Inovasi Fitur Aplikasi Mobile
Marketing Yotomo Regulasi, Standarisasi, dan Penelitian Sejenis
UU RI No 11 Tahun 2008, 6 Artikel Standarisasi Mobile,
dan 6 Penelitian Sejenis
Susunan Kerja
Instalasi Aplikasi Server Melakukan Penginputan
Data Desain Basis Data
LRS Logical Record Structured
Model Data Relasional Spesifikasi Basis Data
Kekurangan Sistem Berjalan Kelebihan Sistem Berjalan
C dan PHP Hosting
Windows Phone Basis data
Matriks CRUD StarUML
StarUML StarUML
StarUML Microsoft Visio
Balsamiq Mockups Microsoft Visual Studio
Adobe Dreamweaver idHostinger
MySQL
Gambar 3.1 Kerangka Berpikir
