9
LANDASAN TEORI
2.1 Gambaran usaha laundry (binatu)
Usaha jasa cuci pakaian atau binatu atau lebih populer dengan nama laundry, tumbuh kembang dengan subur dikarenakan adanya pergeseran gaya hidup serta tuntutan kebutuhan ekonomi yang menyebabkan masyarakat semakin sibuk dengan tugas dan rutinitas, hampir semua anggota keluarga memiliki mobilitas tinggi dan menghabiskan sebagian waktu nya untuk beraktivitas di luar rumah, dan ketika kembali ke rumah sudah dalam keadaan lelah dan langsung beristirahat, hal itulah yang menyebabkan beberapa urusan rumah tangga menjadi kurang diperhatikan.
Pekerjaan mencuci dan menggosok pakaian di anggap merepotkan dan menghabiskan waktu, padahal kebutuhan untuk penampilan yang bersih dan rapih tetap diperlukan, sehingga mereka cenderung lebih memilih mendelegasikan tugas mencuci ke jasa laundry. Pada umumnya layanan usaha laundry menawarkan jasa:
Jasa cuci-kering (pengeringan) Jasa cuci-kering-setrika Jasa antar-jemput pakaian
Persaingan usaha laundry memang sudah sangat ramai, oleh pemain laundry rumahan (UKM) hingga laundry besar yang sudah memiliki nama. Namun potensi pasar yang besar membuat usaha di bidang ini tetap dapat tumbuh dengan baik. Nilai tambah layanan usaha laundry bagi pelanggan:
Tempat strategis
Pelayanan yang ramah, cermat, dan cepat Harga ekonomis
Pewangi yang harum dan tahan lama
Kontrol terhadap kepemilikan baju yang baik Promosi/diskon
Strategi promosi yang dilakukan usaha laundry biasanya berupa banner (spanduk), poster, dan promosi secara langsung dari mulut ke mulut.
2.2 Definisi aplikasi on-demand (sesuai permintaan)
Kini semakin banyak aplikasi teknologi yang membuat hidup semakin lebih mudah, mulai dari proses mencari transportasi, berbelanja makanan, mengirimkan barang, hingga kebutuhan bulanan bisa dilakukan hanya dengan beberapa sentuhan pada layar ponsel pintar. Jurnalis VOA Indonesia mewartakan aplikasi sesuai permintaan seperti ini tidak hanya menjadi tren di Indonesia, namun di seluruh dunia sedang mengalami perkembangan layanan aplikasi sesuai permintaan (Vina Mubtadi. 2015. Aplikasi 'On Demand' Makin Digemari, http://www.voaindonesia.com/media/video/on-demands-apps-pada-
smartphone/2915530.html), kita bisa melihat selengkapnya pada situs web perkumpulan pebisnis sesuai permintaan https://theondemandeconomy.org/ yang menunjukkan bahwa kini sedang terjadi revolusi yang diakibatkan oleh teknologi dan perubahan perilaku konsumen.
Steve Schlafman (2014 Consumer behavior is changing. Immediate access to messaging, e-mail, media, and other online functionality through smartphones has generated a sense of entitlement to fast, simple, and
conducted by The
On-groceries online.
Dunia digital memasuki era dimana konsumen semakin berkuasa, konsumen semakin pintar dengan adanya akses informasi yang tak terbatas melalui internet, konsumen kini menuntut informasi produk yang selalu relevan,
cepat dan tanggap terhadap keinginan konsumen, inilah yang menjadi pemicu dari era ekonomi on-demand. Sebuah revolusi ekonomi dari perkembangan teknologi yang menawarkan akses kemudahan untuk kebutuhan barang dan jasa (terutama pasar mobile).
Aplikasi jasa berbasis online sesuai permintaan ini dibangun di atas infrastruktur teknologi yang membawa dunia online dan dunia offline bersama-sama. Permintaan yang dikumpulkan secara online dilayani secara offline baik secara langsung atau secara terjadwal. Konsep yang luas ini menemukan aplikasi dalam industri yang berbeda dalam bentuk yang sedikit bervariasi. On demand economy didefinisikan sebagai kegiatan ekonomi yang diciptakan oleh perusahaan teknologi yang memenuhi permintaan konsumen melalui penyediaan barang dan jasa. Memanfaatkan ponsel pintar yang semakin lumrah di masyarakat untuk menciptakan suatu solusi rantai pasokan menjadi lebih efisien.
Salah satu kesalahpahaman umum yang berlangsung di masyarakat adalah menyamakan layanan on demand dengan layanan instant. Layanan sesuai permintaan memiliki bisnis model instant (seketika) ataupun scheduled (terjadwal). Layanan instan biasanya memerlukan waktu antara 5-30 menit untuk dipenuhi, sifat permintaan seketika ini cocok untuk model bisnis yang mengutamakan waktu yang mendesak seperti permintaan taksi, dan makanan cepat saji. Sedangkan layanan terjadwal cocok untuk model bisnis seperti belanja kebutuhan pokok, laundry, logistik dan sebagainya.
Cosseboom
sedang menjadi tren bagi pelaku industri kreatif, membangun dan menjalankan platform on-demand seperti Go-jek, Seekmi atau ServisHero adalah sebuah langkah yang sangat disruptif di pasar terbesar di Asia Tenggara (Indonesia) (Leighton Cosseboom, 2015, https://id.techinasia.com/pasar-startup-on-demand-di-indonesia).
Beberapa orang bahkan merasa ini penting untuk mendukung ekonomi Indonesia yang konsumtif. Dalam beberapa tahun terakhir, pertumbuhan pendapatan per tahun Indonesia naik sekitar enam persen tiap tahunnya, walaupun infrastruktur yang belum rapi dan merata di Indonesia, justru menjadi tantangan
dan sebuah kesempatan yang tak terlihat untuk menghasilkan solusi kreatif menyelesaikan segala keterbatasan.
2.2.1 On-Demand Laundry Business Models
Kesuksesan aplikasi sesuai permintaan seperti
Go-ranah aplikasi sesuai permintaan dengan menerapkan model bisnis yang mirip. Salah satunya adalah sektor jasa laundry dan dry cleaning yang berevolusi untuk mengadopsi tren model bisnis berbasis aplikasi online.
Dalam era smartphone, hampir setiap layanan barang dan jasa bisa tersedia melalui aplikasi, baik itu makanan, transportasi, jasa atau bahan makanan bisa kita dapatkan. Aplikasi memungkinkan pengguna melakukan alih daya (outsourcing) pekerjaan rumah tangga seperti menjemput anak, membersihkan rumah, memasak, dan bahkan mencuci pakaian.
Ajay Deep seorang penulis pada Juggernauts yang berpengalaman dalam mengembangkan on-demand platforms, menuliskan bahwa model bisnis yang memungkinkan untuk jasa laundry sesuai permintaan diantaranya adalah (Ajay Deep. 2015. Uber for Laundry: Business Models to Start an On Demand Laundry Business. http://nextjuggernaut.com/blog/uber-for-laundry-business-model-start-on-demand-laundry/).
A. On Demand On Site
Dimana jika pengusaha laundry sudah memiliki tim yang solid dan berpengalaman, maka implementasi teknologi aplikasi mobile dapat membantu pelanggan dalam hal:
Membuat jadwal antar-jemput pakaiana sesuai dengan waktu yang dimiliki pelanggan
Memberikan kebebasan bagi pelanggan untuk menentukan preferensi laundry (jika ada)
Mendapatakan notifikasi ketika pakaian pelanggan telah dibersihkan Membayar tagihan dengan mudah (secara online ataupun tunai/COD).
Menerima pengiriman pakaian pada waktu yang telah ditentukan.
B. Marketplace (Agregasi Model)
Model bisnis lain yang memungkinkan dalam sektor jasa cuci pakaian sesuai permintaan adalah model agregasi, di mana sebuah aplikasi bertindak sebagai pasar, tempat bertemunya penyedia jasa cuci pakaian dengan pengguna aplikasi yang mencari layanan cuci pakaian. Model bisnis ini dapat diadopsi oleh siapa saja, terlepas apakah orang tersebut memiliki usaha laundry pakaian. Di sini, informasi tentang jasa laundry disediakan oleh pihak ketiga (agen laundry), sedangkan transaksi diproses oleh operator marketplace. Semua layanan yang ada disediakan dan dikerjakan oleh agen laundry yang berpartisipasi. Dalam model ini, pembuat aplikasi dapat mengambil untung dengan cara mengenakan biaya dari setiap transaksi yang terjadi melalui platform aplikasi.
Model bisnis ini memudahkan pengguna dalam hal: Memilih agen laundry berdasarkan peringkat dan ulasan.
Memberikan rating dan review untuk agen laundry setelah mencoba layanannya.
Mencari agen laundry berdasarkan harga, peringkat, lokasi, dll. Melakukan transaksi dengan mudah pada platform.
Aplikasi Londria yang dikerjakan oleh penulis memiliki model bisnis marketplace, dimana melalui aplikasi Londria akan menghubungkan pencari jasa cuci pakaian dengan agen laundry yang handal dan terpercaya.
2.3 Pengguna smartphone di Indonesia
Pertumbuhan pengguna ponsel pintar di Indonesia sedang berkembang pesat, masyarakat perkotaan, khususnya generasi muda, memiliki gawai ponsel pintar untuk menunjang aktivitasnya. Hasil data riset StatCounter yang menyediakan hasil analisis statistik mengenai pengguna ponsel selama September 2013 sampai dengan September 2015 menunjukkan dominasi Android sebagai sistem operasi terpopuler dengan grafik meningkat diikuti oleh Symbian series 40 di posisi kedua, dan BlackBerry OS yang menunjukkan tren pengguna yang
menurun. Selain itu, rata-rata orang Indonesia menghabiskan waktu 5,5 jam per hari menatap layar ponsel pintarnya, hal tersebut diungkapkan oleh Google Indonesia melalui hasil survei di lima kota besar di Indonesia yaitu Jakarta, Bodetabek, Bandung, Semarang, Surabaya pada periode Desember 2014 sampai Februari 2015.
Menurut Country Industry Head sekarang sudah mulai beralih ke mobile
smartphone yang tinggi dan layanan internet yang kian merata dan terjangkau ini lah yang menjadi alasan di balik tingginya penggunaan ponsel pintar di Indonesia. (Reska Nistanto. 2015. Kebiasaan Orang Indonesia, Pelototi "Smartphone" 5,5
Jam Sehari,
http://tekno.kompas.com/read/2015/09/04/11301837/Kebiasaan.Orang.Indonesia. Pelototi.Smartphone.5.5.Jam.Sehari)
2.3.1 Pengguna internet di Indonesia
Banyak pendapat pakar yang mengatakan bahwa Indonesia adalah pasar yang potensial yang bisa menjadi pusat ekosistem start-up di wilayah Asia tenggara, jumlah populasi penduduk yang melebihi 251.160.000, dengan angka pemilik telepon genggam yang mencapai 112% populasi, ini tentu sangat menggiurkan bagi pelaku bisnis untuk membuka usahanya di Indonesia.
Pengguna internet di Indonesia mencapai 15% dari populasi, atau sekitar 38,2 juta jiwa adalah pengguna internet aktif. Waktu yang dihabiskan pengguna internet di Indonesia lebih banyak di ranah sosial media pada peringkat pertama, lalu pencarian informasi berita di peringkat kedua, dan peringkat ketiga adalah online shopping.
Menurut Henky Prihatna, aktivitas online shopping dengan peranti mobile kian banyak dilakukan karena kini mereka bisa melakukannya dengan nyaman. "Puncaknya pada malam hari, dimulai dari setelah jam kerja, mungkin karena sambil menunggu macet mereka mengakses mobile".
2.4 System Development Life Cycle (SDLC)
Setiap perangkat lunak memiliki siklus hidup pengembangan sistem (SDLC) yaitu suatu proses periode pembuatan dan perubahan sistem yang disertai dengan metodologi yang digunakan untuk mengembangkan sistem.
Rekayasa perangkat lunak adalah suatu proses penelusuran, perencanaan, pemodelan, pengembangan yang dilaksanakan dan dikelola untuk membangun sebuah sistem perangkat lunak. Setiap sistem perangkat lunak memiliki siklus hidup (life cycle) dimana periode dilakukan pengembangan perangkat lunak untuk menyelesaikan masalah baru yang timbul, umumnya pengembangan sistem memiliki 5 tahapan yaitu investigasi dan analisis, modeling, development, implementasi, dan pengelolaan.
Dalam pengembangan suatu sistem, sulit diprediksi hal-hal apa saja yang akan terjadi saat pengembangan berlangsung. Keinginan pemilik produk (product owner) dapat berubah sewaktu-waktu. Gagal beradaptasi dengan perubahan menjadi salah satu penyebab kegagalan suatu proyek.
Menurut Elvis C. Foster (2014:9) pada bukunya yang berjudul Software Engineering A Methodical Approach, siklus hidup pengembangan, sistem memiliki banyak variasi model. Seperti diantaranya:
Waterfall Model
Phased Prototype Model Iterative Development Model Rapid Prototype Model Formal Transformation Model Component-Based Model Agile Development Model
Menurutnya Terlepas dari model apa yang di gunakan, pada umumnya siklus hidup pengembangan sistem memiliki 5 tahapan yaitu:
Gambar 2.1 lima tahapan utama SDLC (Elvis C. Foster 2014:9)
2.5 Metode Scrum
Scrum adalah sebuah pendekatan iteratif untuk pengembangan perangkat lunak yang selaras dengan prinsip-prinsip agile dan Agile manifesto seperti berikut:
Prioritas utama kami adalah memuaskan klien dengan menghasilkan perangkat lunak yang bernilai secara dini dan rutin.
Menyambut perubahan kebutuhan, walaupun terlambat dalam pengembangan perangkat lunak. Proses Agile memanfaatkan perubahan untuk keuntungan kompetitif klien.
Menghasilkan perangkat lunak yang bekerja secara rutin, dari jangka waktu beberapa minggu sampai beberapa bulan, dengan preferensi kepada jangka waktu yang lebih pendek.
Rekan bisnis dan pengembang perangkat lunak harus bekerja-sama tiap hari sepanjang proyek.
Kembangkan proyek di sekitar individual yang termotivasi. Berikan mereka lingkungan dan dukungan yang mereka butuhkan, dan percayai mereka untuk menyelesaikan pekerjaan dengan baik.
Metode yang paling efisien dan efektif untuk menyampaikan informasi dari dan dalam tim pengembangan perangkat lunak adalah dengan komunikasi secara langsung.
Proses agile menggalakkan pengembangan berkelanjutan. Sponsor-sponsor, pengembang-pengembang, dan pengguna-pengguna akan dapat mempertahankan kecepatan tetap secara berkelanjutan.
Perhatian yang berkesinambungan terhadap keunggulan teknis dan rancangan yang baik meningkatkan agility.
Kesederhanaan seni memaksimalkan jumlah pekerjaan yang belum dilakukan adalah hal yang amat penting.
Arsitektur, kebutuhan, dan rancangan perangkat lunak terbaik muncul dari tim yang yang dapat mengorganisir diri sendiri.
Secara berkala, tim pengembang berefleksi tentang bagaimana untuk menjadi lebih efektif, kemudian menyesuaikan dan menyelaraskan kebiasaan bekerja mereka.
Scrum terdiri dari serangkaian blok waktu yang disebut dengan , yang berfokus untuk membuat perangkat lunak yang bekerja (berjalan). Sebuah sprint biasanya terdiri dari dua sampai empat minggu panjangnya dan memiliki suatu tujuan atau tema yang membantu memperjelas targetdari suatu sprint. Sebuah sprint yang berjalan terisolasi dari perubahan, yang memungkinkan tim untuk fokus untuk menyelesaikan perangkat lunak tanpa gangguan (Jerrel Blankenship, dkk. 2011:13).
Scrum dianggap sebagai value-driven method untuk pengembangan perangkat lunak. Scrum adalah perubahan dramatis atas metode waterfall untuk sejumlah alasan. Dimana pada waterfall kita mencoba untuk melakukan segala sesuatu di awal, dimulai dari mengumpulkan semua kebutuhan (requirements) yang diperlukan untuk setiap fitur, lalu menyelesaikan semua desain dan modeling aplikasi, dan kemudian proses pembuatan kode aplikasi berdasarkan kebutuhan ini, Scrum terlihat lebih interative (dilakukan berulang) dengan pengembangan yang meningkat. Scrum adalah mengambil langkah kecil dari suatu masalah dan menilai kembali masalah itu setelah setiap tahapan terlewati.
Gambar 2.2 Proses Scrum (Jerrel Blankenship, dkk. 2011:19)
2.5.1 Perbedaan metode pengembangan waterfall dengan scrum
Untuk melihat perbedaan antara metode waterfall dan metode Scrum, kita perlu melihat inti di balik setiap metode. Pada metode waterfall adalah metode berbasis rencana (Plan Driven) yang telah dibuat pada awal proyek, sementara metode agile adalah metode yang berdasarkan oleh nilai (Value Driven) yang akan diberikan untuk pelanggan. Menurut tulisan Jerrel Blankenship, dkk. (2011:19) tentang perbedaan waterfall dengan Scrum adalah sebagai berikut:
A. Waterfall Method (Plan Driven)
Jerrel Blankenship, dkk. (2011:19) mengatakan metode waterfall dapat dianggap sebagai metode pengembangan perangkat lunak berbasis rencana. Di masa lalu, metode ini digunakan oleh banyak orang, bukan karena waterfall adalah cara terbaik untuk mengembangkan perangkat lunak, tetapi karena itulah satu-satunya metode pengembangan perangkat lunak yang dikenal saat itu.
Sebuah proyek yang menggunakan metode waterfall akan memiliki sejumlah risiko, terutama karena analisis sebagian besar dilakukan pada tahap awal sebelum proyek dimulai. Semua requirements gathering, dan menentukan ruang lingkup proyek akan dibuat sebelum baris pertama dari kode program ditulis. Pelanggan (users) harus mengetahui segala sesuatu yang mereka perlukan dari sistem pada tahap awal proyek, lalu pelanggan juga harus menentukan setiap detail dari kebutuhan mereka. Ketika pelanggan tidak tahu persis apa yang mereka inginkan di awal, dan kemudian baru menyadarinya ketika proyek sudah dimulai, maka pelanggan tidak bisa mengubah spesifikasi kebutuhan sistem dan meminta perubahan itu segera di penuhi.
Pendekatan waterfall ini membuat proyek memiliki risiko sangat besar kemungkinannya untuk gagal, bahkan sebelum proyek dimulai, karena terkadang terlalu mahal untuk membuat perubahan. Pada setiap tahapan proses waterfall bisa saja memiliki masalah yang tersembunyi yang tiba-tiba mencuat menjelang akhir proyek, dikarenakan kebutuhan pelanggan yang kurang rinci.
B. Scrum Metode (Value Driven)
Jerrel Blankenship, dkk. (2011:20) melanjutkan pembahasan mengenai Scrum yang dianggap sebagai metode pengembangan berbasis nilai (value driven). Scrum adalah perubahan dramatis atas metode waterfall untuk beberapa hal. Alih-alih mengumpulkan semua persyaratan yang dibutuhkan untuk setiap fitur dari proyek sekaligus, lalu membuat rancangan sistem berdasarkan kebutuhan tersebut, dan kemudian tahap coding aplikasi berdasarkan rancangan sistem ini, Scrum berbeda dalam pengembangan sistem ini dengan menggunakan pendekatan inkremental dan dilakukan berulang.
Gambar 2.4 Tahapan iterasi (Jerrel Blankenship, dkk. 2011:10)
Scrum akan mengambil langkah kecil di dalam pengembangan sistem untuk menyelesaikan masalah pelanggan secepatnya lalu menilai kembali masalah itu setelah setiap selesai tahapan pengembangan.
Scrum adalah semua tentang mengambil hal kecil seperti: sprint
Fitur minimal
Setiap sprint bisa saja dipandang sebagai sebuah proyek waterfall mini. Hal ini karena dalam setiap sprint ini pengembang akan melakukan kegiatan yang biasanya akan dilakukan di proyek waterfall, tetapi dengan skala yang lebih kecil. Dalam setiap sprint, pengembang akan mengambil fitur yang diinginkan pelanggan lalu mengumpulkan kebutuhan apa saja yang diperlukan pada fitur itu terlaksana, kemudian membuat rancangan fitur berdasarkan kebutuhan tersebut, lalu menuliskan baris kode hingga aplikasi bisa dibuat dan diuji untuk memastikan fitur sudah terpenuhi berdasarkan pada desain awal. Tujuan dari setiap sprint adalah untuk merilis fitur yang diinginkan pelanggan seminimal mungkin dan dengan cepat bisa langsung digunakan oleh pelanggan.
Ada satu hal penting tentang Scrum, tujuan dari Scrum adalah untuk mengekspos masalah (issues) secepat mungkin, namun Scrum tidak dirancang untuk memperbaiki masalah seketika. Namun memasukan perbaikan tersebut ke rencana pengembangan fitur di sprint berikutnya. Sehingga tim penggembang bisa fokus dalam menyelesaikan semua fitur pada sprint berjalan.
2.5.2 Sprint
Jerrel Blankenship, dkk (2011:20) menuliskan pada Pro Agile .NET Development with Scrum bahwa setiap sprint dapat dipandang sebagai sebuah mini waterfall project. Hal ini karena dalam setiap sprint itu melakukan segala sesuatu yang biasanya dilakukan dalam waterfall project, tetapi melakukannya pada skala yang lebih kecil. Lamanya Sprint bisa mencapai dua minggu, satu bulan atau kurang.
Dalam setiap sprint, kita mengambil fitur yang akan dikerjakan dan mengumpulkan kebutuhan yang harus dilakukan untuk fitur tersebut, kita merancang fitur berdasarkan requirements, dan membuat kode dan menguji
bahwa fitur sesuai dengan desain. Tujuan dari setiap sprint adalah untuk memberikan peningkatan dari produk akhir, tapi kenaikan yang berpotensi di release.
2.5.3 Tim Scrum
Menurut Ken Schwaber dan Jeff Sutherland (2013:4) menuliskan rincian-rincian panduan, definisi dan aturan main dalam Scrum.
Tim Scrum terdiri dari Product Owner, Tim Pengembang dan Scrum Master. Tim Scrum mengatur diri mereka sendiri dan berfungsi antar-lintas. Tim yang mengatur dirinya sendiri menentukan cara terbaik untuk menyelesaikan pekerjaannya, daripada diatur oleh pihak lain yang berada di luar anggota tim. Tim yang berfungsi antar-lintas memiliki semua kompetensi yang dibutuhkan untuk menyelesaikan pekerjaan, tanpa mengandalkan pihak lain yang berada di luar anggota tim. Model tim di dalam Scrum dirancang sedemikian rupa untuk mengotimalisasi fleksibilitas, kreatifitas dan produktifitas.
Tim Scrum menghantarkan produk secara berkala dan bertahap untuk memperbesar kesempatan mendapatkan masukan. Penghantaran secara bertahap dari sebuah produk, memastikan produk yang berpotensi dapat digunakan, selalu siap.
a. Product Owner
Product Owner bertanggung-jawab untuk memaksimalkan nilai produk dan hasil kerja Tim Pengembang. Cara pelaksanaannya sangat bervariasi antar organisasi, Tim Scrum dan individu.
Product Owner merupakan satu-satunya orang yang bertanggung-jawab untuk mengelola Product backlog. Pengelolaan Product backlog mencakup:
Mengekspresikan dengan jelas item Product backlog;
Mengurutkan item di dalam Product backlog untuk mencapai tujuan dan misi dengan cara terbaik;
Memastikan Product backlog transparan, jelas, dan dapat dilihat semua pihak, dan menunjukkan apa yang akan dikerjakan oleh Tim Scrum selanjutnya;
Memastikan Tim Pengembang dapat memahami item dalam Product backlog hingga batasan yang diperlukan;
Product owner dapat saja mengerjakan pekerjaan-pekerjaan di atas, atau menyerahkan pengerjaannya kepada Tim Pengembang, namun satu-satunya pihak yang bertanggung jawab tetaplah Product owner. Product owner adalah satu orang dan bukan berupa sebuah komite. Product owner dapat mengejawantahkan aspirasi dari komite ke dalam Product backlog, namun mereka yang ingin merubah prioritas item Product backlog, harus melakukannya melalui Product owner. Agar Product owner berhasil menjalankan tugasnya, seluruh organisasi harus menghormati setiap keputusan yang ia buat. Keputusan dari Product owner ini dapat dilihat dari isi dan urutan Product backlog. Tidak ada seseorang pun yang dapat memerintah Tim Pengembang untuk mengerjakan kebutuhan lain selain Product owner. Dan Tim Pengembang pun tidak diperbolehkan untuk melakukan apa yang diperintahkan oleh pihak lain selain Product owner.
b. Tim Pengembang
Tim Pengembang terdiri dari para profesional yang bekerja untuk menghasilkan tambahan potongan user story (sprint backlog) yang berpotensi untuk dirilis di setiap akhir Sprint. Hanya anggota Tim Pengembang yang mengembangkan sprint backlog ini. Tim Pengembang dibentuk dan didukung oleh organisasi untuk mengatur dan mengelola pekerjaannya secara mandiri. Sinergi yang ada di dalam tim akan meningkatkan efisiensi dan efektifitas dari Tim Pengembang secara keseluruhan.
Tim Pengembang memiliki karakteristik sebagai berikut:
Mereka mengatur dirinya sendiri. Tidak ada satu orang pun (bahkan Scrum Master) yang memerintah Tim Pengembang bagaimana cara merubah Product backlog menjadi sprint backlog yang berpotensi untuk dirilis;
Tim Pengembang berfungsi antar-lintas, sebagai sebuah tim, memiliki semua keahlian yang dibutuhkan untuk menghasilkan produk;
Scrum tidak mengenal adanya jabatan tertentu untuk anggota Tim Pengembang selain Pengembang, apapun pekerjaan yang dikerjakan oleh masing-masing anggota tim; tidak ada pengecualian untuk aturan yang satu ini;
Tim Pengembang tidak mengenal adanya sub-tim yang dikhususkan untuk bidang tertentu seperti pengujian atau analisa bisnis; tidak ada pengecualian untuk aturan yang satu ini;
Anggota Tim Pengembang boleh memiliki spesialisasi keahlian dan fokus di satu area tertentu, namun akuntabilitas dari hasil dari pekerjaan secara keseluruhan adalah milik Tim Pengembang.
c. Scrum Master
Scrum Master bertanggung jawab untuk memastikan Scrum telah dipahami dan dilaksanakan. Scrum Master melakukannya dengan memastikan Tim Scrum mengikuti teori, praktik, dan aturan main Scrum. Scrum Master adalah seorang pemimpin yang melayani Tim Scrum. Scrum Master membantu pihak di luar Tim Scrum, untuk memahami apakah interaksi mereka dengan Tim Scrum bermanfaat atau tidak. Scrum Master membantu setiap pihak untuk merubah interaksi-interaksi yang tidak bermanfaat sehingga bisa memaksimalkan nilai yang dihasilkan oleh Tim Scrum.
2.5.4 Aktifitas Scrum
Menurut praktisi Scrum, Jerrel Blankenship (2011:29) kegiatan-kegiatan yang terlibat dalam Scrum berkisar antara perencanaan proyek, review, dan pertemuan, seperti:
a. Perencanaan Sprint (sprint planning/Requirement gathering)
Sebelum memulai sebuah sprint, diadakan pertemuan untuk membahas fitur apa saja yang akan dikerjakan dalam suatu sprint. Fitur berasal dari Product backlog, yang diprioritaskan oleh product owner. Kemudian Product backlog
yang dipilih oleh Product owner akan dimasukkan ke dalam sprint untuk selanjutnya diberikan kepada tim pengembang untuk dinilai kompleksitas dari suatu user story dibandingkan dengan user story lainnya dengan memberikan point.
Setelah user story tersebut diberikan point, maka user story tersebut diubah menjadi tugas-tugas kecil untuk anggota tim disertai perkiraan waktu pengerjaan tugas tersebut. Daftar tugas ini disebut juga sprint backlog.
Tujuan dari tahap analisis adalah untuk mencari tahu apa kebutuhan bisnis. Tujuan dari tahap desain adalah untuk memutuskan bagaimana untuk membangunnya. desain sistem adalah penentuan arsitektur sistem secara keseluruhan (terdiri dari satu set komponen fisik pengolahan, hardware, software, orang, dan komunikasi di antara mereka) yang akan memenuhi persyaratan utama sistem. (Alan Dennis. 2011:260)
b. Design
Tahap desain memutuskan bagaimana sistem baru akan beroperasi. Banyak kegiatan akan terlibat sebagai tim pengembangan mengembangkan kebutuhan sistem.
Selama tahap awal desain, tim proyek mengubah kebutuhan bisnis pada sistem ke dalam system requirement yang menggambarkan rincian teknis untuk membangun sistem. Tidak sepertibu, yang tercantum dalam definisi persyaratan dan dikomunikasikan melalui kasus penggunaan dan proses logis dan model data, persyaratan sistem dikomunikasikan melalui koleksi dokumen desain dan proses fisik dan model data. Bersama-sama, dokumen desain dan model fisik membuat cetak biru untuk sistem baru . (Alan Dennis. 2011:260).
c. Development
Mengembangkan perangkat lunak sistem (menulis program) dapat menjadi komponen tunggal terbesar dari setiap proyek pengembangan sistem baik dari segi waktu dan biaya. Hal ini umumnya juga komponen dipahami terbaik dan mungkin menawarkan masalah paling sedikit dari semua aspek dari SDLC. Karena analis sistem biasanya tidak benar-benar melakukan pemrograman (programmer), dalam fase ini kita memusatkan perhatian kita pada mengelola proses pemrograman.
Sementara programmer mengubah spesifikasi program ke kode program kerja, sistem analis akan merancang berbagai tes yang akan dilakukan pada sistem baru. Sebagai program diselesaikan, sistem analis dapat melakukan tes ini untuk memverifikasi bahwa sistem benar-benar melakukan apa yang dirancang untuk melakukan. Pengujian mungkin menjadi elemen utama dari tahap implementasi untuk analis sistem. (Dalam beberapa organisasi, pengujian dilakukan oleh personil jaminan kualitas khusus.)
Selama fase ini, juga merupakan tanggung jawab analis sistem untuk menyelesaikan dokumentasi sistem dan mengembangkan dokumentasi pengguna. (Alan Dennis. 2011:446)
d. Testing
Sebuah program dianggap tidak selesai sampai telah lulus pengujian. Untuk alasan ini, pemrograman dan pengujian berkaitan erat. Pengujian sering kali menjadi fokus utama dari sistem analis ketika sistem sedang dibangun. Para analis harus menahan godaan untuk buru-buru melakukan pengujian ketika modul program yang pertama selesai, namun menguji secara spontan berbagai aktivitas dan kemungkinan tanpa menghabiskan waktu untuk mengembangkan rencana tes komprehensif berbahaya, karena tes penting dapat diabaikan. Jika kesalahan tidak terjadi, itu mungkin sulit untuk mereproduksi urutan kejadian yang menyebabkan hal itu. Sebaliknya, pengujian harus dilakukan dan didokumentasikan secara sistematis sehingga tim proyek selalu tahu apa yang telah dan belum diuji. (Alan denis. 2011:449)
e. Daily Stand-Ups (Scrums)
Selama sprint berlangsung, tim pengembang, Scrum Master, dan Product owner berkomitmen untuk melaksanakan pertemuan sehari sekali di tempat yang sama dan pada waktu yang sama untuk membahas masalah yang terjadi yang menghambat pekerjaan.
Pertemuan ini mengharuskan semua orang berdiri dan waktu pelaksanaan dibatasi untuk tidak lebih dari 15 menit. Setiap orang yang terlibat di dalam proyek diundang untuk menghadiri daily stand-ups ini; Namun, hanya
orang-orang diklasifikasikan sebagai tim proyek yang diperbolehkan untuk berbicara di rapat ini.
Pada Daily Scrum, masing-masing anggota tim menjawab tiga pertanyaan berikut:
Apa yang telah dikerjakan sejak kemarin? Apa rencana untuk dikerjakan hari ini? Apakah terdapat masalah yang mengganggu?
Untuk menjaga rapat harian ini menjadi panjang, batasi waktu rapat hanya 15 menit, jika terdapat masalah yang kompleks bisa dibahas lebih lanjut diluar rapat harian ini dengan orang terkait.
Daily Scrum meningkatkan komunikasi, menghilangkan pertemuan-pertemuan lain, mengidentifikasi hambatan untuk dihilangkan, mendukung pembuatan keputusan secara cepat dan meningkatkan tingkat pengetahuan tim. Pertemuan ini adalah kunci dari proses peninjauan dan pengadaptasian. (Jerrel Blankenship. 2011:30)
f. Sprint Review & Retrospektif
Sprint Review adalah pertemuan yang diadakan pada akhir sprint. Tujuannya adalah agar tim Scrum bisa menyajikan user story mana saja yang telah selesai selama sprint. Dihadiri Tim pengembang, Product owner, dan ScrumMaster hadir di sprint review ini, biasanya bersama dengan pihak terkait terutama manajer dan pelanggan.
Ulasan ini terdiri dari sebuah demo informal dari fitur yang dikembangkan. Pertemuan ini adalah kesempatan bagi pelanggan untuk memberikan umpan balik pada produk (saran dan kritik) untuk tim. Tujuan dari kajian ini adalah untuk menunjukkan fitur yang bisa digunakan, tidak perlu ada acara presentasi atau persiapan khusus untuk pertemuan ini, sejalan dengan prinsip agile dalam hal memuaskan klien dengan menghasilkan perangkat lunak yang bernilai secara dini dan rutin.
Seiring dengan sprint review, sprint retrospective adalah kilas balik tim pengembang untuk mengulas perjalanan sprint hingga akhir sprint. Sprint retrospektif adalah kesempatan bagi tim untuk merefleksikan sprint yang sedang berlangsung. Ini adalah moment bagi tim untuk mengucapkan selamat atas pencapaian sesama tim dalam menyelesaikan sprint yang berjalan dengan baik dan membahas hal-hal yang tidak beres. Ini adalah area terbuka di mana tim harus merasa bebas untuk mendiskusikan masalah yang mempengaruhi tim dan kemampuan mereka untuk merilis produk ke pelanggan. Selama pertemuan ini, seluruh tim hadir, termasuk ScrumMaster dan Product owner. (Jerrel Blankenship. 2011:30)
2.5.5 Scrum Artifacts
Scrum berisi tiga artefak utama: Product backlog, sprint backlog, danburn-down chart. Artefak ini adalah produk khas dari kegiatan Scrum dan membantu memberikan arah dan transparansi untuk tim.
1. Product backlog
Product backlog adalah daftar semua fitur yang ada pada sebuah proyek yang perlu diselesaikan oleh tim pengembang. Daftar ini merupakan kebutuhan dan keinginan pelanggan.
Product backlog dikelola oleh pemilik produk (Product Owner), yang bertanggung jawab untuk menambah dan menghapus fitur yang diinginkan dari daftar. Product backlog lalu diprioritaskan oleh pemilik produk kemudian tim pengembangan bekerja sama dengan Product Owner, dan pemangku kepentingan untuk membuat rapat perencanaan sprint lalu memperkirakan Product backlog mana yang diyakini dapat diselesaikan hingga akhir dari suatu sprint (menjadi sprint backlog), fitur dapat ditambahkan ke dalam Product backlog, namun itu tidak akan disampaikan kepada tim sampai dengan sprint yang berjalan telah selesai.
2. Sprint Backlog
Sprint backlog adalah daftar semua pekerjaan yang tersisa di sprint yang berjalan. sprint backlog adalah bagian dari Product backlog. Biasanya ketika sebuah keinginan pengguna (user story) dipilih untuk sebuah sprint, tim akan membagi user story menjadi tugas-tugas yang lebih rinci. Tugas ini ditampilkan pada task board (dikenal juga dengan nama papan Kanban) agar dapat terlihat ke seluruh organisasi. Item lainnya dapat muncul di papan ini juga, termasuk informasi tentang rapat untuk mengumpulkan kebutuhan (requirements), permasalahan, pengujian, desain, dan tahapan kode.
Gambar 2.6 Penggunaan papan Kanban dan sprint backlog (Jerrel Blankenship, dkk. 2011:25)
3. Burn-Down Chart
Sebuah burn-down chart adalah cara visual untuk melacak bagaimana kemajuan dari sebuah sprint. Diagram grafis ini menunjukkan jumlah pekerjaan yang tersisa pada hari tertentu dalam sprint. Hal ini biasanya ditampilkan di area publik di mana setiap orang dapat melihatnya. Ini membantu komunikasi antara anggota tim dan pemangku kepentingan dalam organisasi. Grafik ini juga dapat bertindak sebagai indikator awal jika ada masalah dalam sprint dan mengakibatkan kemungkinan tim tidak dapat memenuhi komitmennya.
Untuk menjaga hal-hal berjalan lancar pada sebuah sprint, seorang Scrum Master ditunjuk untuk memastikan tidak ada kendala yang menghambat tim dari tugas untuk menyelesaikan fitur yang telah disepakati. Daily stand-up meetings membantu tim berkomunikasi tentang masalah yang ada dan hambatan yang terjadi selama sprint. Retrospektif pada akhir setiap sprint membantu untuk meningkatkan proses di sprint kemudian.
Gambar 2.7 Contoh diagram burndown chart (Jerrel Blankenship, dkk. 2011:26)
2.6 Pemodelan UML
Modeling adalah merancang aplikasi perangkat lunak sebelum proses pembuatan kode aplikasi. Modeling adalah Bagian penting dari proyek pengembangan perangkat lunak. Sebuah modeling ibarat cetak biru pada rencana pembangunan gedung (peta lokasi, ketinggian, model fisik). Survei menunjukkan bahwa proyek software besar memiliki probabilitas kegagalan yang besar, untuk meningkatkan peluang proyek yang sukses, maka pemodelan adalah satu-satunya cara untuk memvisualisasikan desain aplikasi untuk bisa diperiksa terhadap persyaratan sebelum tim mulai menulis kode.
Unified Modeling Language (UML) memungkinkan untuk menggambarkan sistem dengan kata-kata dan gambar. Hal ini dapat digunakan untuk memodelkan berbagai sistem: sistem perangkat lunak, sistem bisnis, atau
sistem lainnya. Terutama penggunaan berbagai grafis diagram grafik seperti use case. Dimana diagram ini bukanlah hal baru,sehingga perlu dibakukan oleh Object Management Group (OMG), sebuah asosiasi internasional yang mempromosikan standar terbuka untuk aplikasi berorientasi objek.
Tujuan dari UML adalah untuk menyediakan kosakata umum istilah berbasis obyek dan teknik diagram yang cukup kaya untuk memodelkan setiap proyek pengembangan sistem dari analisis untuk merancang. (Alan Dennis, 2012:513).
2.6.1 Use Case Diagram
Diagram use case menggambarkan fungsi utama dari sistem dan berbagai jenis pengguna yang berinteraksi dengan sistem itu. Diagram berisi aktor, yang merupakan orang-orang atau hal-hal yang memperoleh nilai dari sistem, dan use case yang mewakili fungsi dari sistem. Aktor dan use case dipisahkan oleh batas sistem dan terhubung oleh garis mewakili asosiasi. Kadang, aktor versi khusus lebih dari aktor umum. Demikian pula, use case dapat memperpanjang atau menyertakan use case lainnya. Di kali, aktor versi khusus dari aktor yang lebih umum. Demikian pula, diagram use case dapat memperpanjang atau termasuk use caselainnya.Bangunan diagram use caseadalah proses lima langkah dimana analis mengidentifikasi use case itu,menarik batas sistem, menambahkan diagram, mengidentifikasi pelaku,dan, akhirnya, menambahkan asosiasi yang tepat untuk menghubungkan use casedan aktor bersama-sama. (Alan Dennis, 2012:517)
Unsur pada use case: 1. Aktor
a. Adalah orang atau sistem yang memperoleh manfaat dari dan di eksternal ke dalam sistem.
b. Dilabeli sesuai dengan perannya.
c. Dapat dikaitkan dengan aktor-aktor lain oleh spesialisasi / asosiasi superclass,dilambangkan dengan panah dengan panah berongga.
d. Ditempatkan di luar batas sistem. 2. Use case
a. Merupakan bagian utama dari sistem fungsi. b. Dapat memperpanjang kasus penggunaan lain. c. Ditempatkan di dalam batas sistem.
d. Diberi label dengan deskriptif kata kerja-kata benda frasa 3. system boundary/ batas system
a. Termasuk nama dari sistem di dalam atau di atas. b. Merupakan lingkup sistem.
4. association relationship / hubungan asosiasi
Kaitan antara aktor dengan use case yang berinteraksi.
2.6.2 Activity Diagrams
Activity diagrams menunjukkan aliran proses antara objek, seperti alur proses bisnisnya. Diagram ini terbuat dari beberapa bentuk khusus, kemudian dihubungkan dengan panah. Notasi ditetapkan untuk diagram aktivitas.
Menurut Alan Dennis (Diagram activity adalah yang menggambarkan alur kerja bisnis independen dari class, aliran kegiatan dalam use case, atau desain rinci sebuah metode. (Alan Dennis dkk 2012: 5013)
Gambar 2.10 Simbol Activity Diagram (Alan Dennis, 2009:161 ) Unsur activity diagram adalah
1. Sebuah aksi / An action
a. Apakah sepotong, terurai non sederhana perilaku. b. Apakah label dengan namanya.
2. Suatu kegiatan/An activity
a. Apakah digunakan untuk mewakili serangkaian tindakan. b. Apakah label dengan namanya
3. Sebuah objek simpul/An object node
a. Apakah digunakan untuk mewakili suatu objek yang terhubung ke satu set arus objek.
b. Apakah label dengan nama kelasnya. 4. Aliran kontrol/A control flow
a. Menunjukkan urutan eksekusi. 5. Aliran objek/An object flow
a. Menunjukkan aliran objek dari satu kegiatan (atau tindakan) untuk aktivitas lain (atau tindakan).
6. Node awal/An initial node
a. menggambarkan awal dari serangkaian tindakan atau kegiatan. 7. Node akhir-aktivitas/a final-activity node:
a. Apakah digunakan untuk menghentikan semua arus kontrol dan arus objek dalam suatu kegiatan (atau tindakan).
8. Akhir-aliran simpul/final-flow node:
a. Apakah digunakan untuk menghentikan aliran kontrol atau aliran objek tertentu.
9. Keputusan simpul/A decision node:
a. Apakah digunakan untuk mewakili kondisi tes untuk memastikan bahwa aliran kontrol atau aliran objek hanya turun satu jalur.
b. Apakah label dengan kriteria keputusan untuk terus menyusuri jalan tertentu.
10. Sebuah penggabungan simpul/A merge node:
a. Apakah digunakan untuk membawa kembali jalur keputusan bersama yang berbeda yang diciptakan menggunakan Keputusan simpul.
2.6.3 Class Diagrams
Diagram kelas mewakili struktur statis dari suatu sistem, termasuk classes, attributes, operations, dan objek. Diagram Kelas diwakili dengan bentuk persegi panjang yang dibagi menjadi tiga. Bagian atas menampilkan nama kelas, sementara bagian tengah berisi atribut kelas. Bagian bawah memiliki operasi kelas (juga dikenal sebagai methods). Menggunakan garis untuk mewakili asosiasi, pewarisan (inheritance), multiplicity, dan hubungan lainnya antara class dan subclass.
Diagram kelas adalah model statis yang mendukung pandangan statis dari sistem berkembang. Ini menunjukkan kelas dan hubungan di antara kelas yang tetap konstan dalam sistem (Alan Dennis, 2012 :521)
Deskripsi simbol Class diagram 1. Class
b. Mewakili orang, tempat, atau hal tentang sistem yang menyimpan informasi.
c. Memiliki nama diketik dalam huruf tebal dan diatas pusat diagram. d. Memiliki daftar atribut di pusat diagram.
e. Memiliki daftar operasi di bawahnya pusat diagram.
f. Tidak secara eksplisit menunjukkan semua operasi pada semua kelas. 2. Atribut
a. Merupakan sifat yang menggambarkan kondisi dari sebuah objek.
b. Dapat diturunkan dari atribut lainnya, ditunjukkan dengan menempatkan garis miring sebelum nama atribut itu.
3. Metode
a. Merupakan tindakan atau fungsi bahwa kelas dapat melakukan sesuatu. b. Dapat diklasifikasikan sebagai konstruktor, query, atau operasi update. c. Termasuk tanda kurung yang mungkin berisi parameter khusus atau
informasi yang dibutuhkan untuk melakukan operasi. 4. Asosiasi
a. Merupakan hubungan antara beberapa kelas, atau kelas dan itu sendiri. b. Diberi label oleh frase verba atau nama peran, yang menggambarkan
hubungan.
c. Bisa ada di satu atau lebih kelas.
d. Berisi simbol keragaman, yang mewakili minimum dan maksimum jumlah kelas dapat dikaitkan dengan instance kelas.
Gambar 2.13 Contoh class diagram (Alan Dennis, 2012 :523)
2.6.4 Sequence Diagram
Sequence diagram digunakan untuk menggambarkan model logika dari sebuah use case yang menunjukkan interaksi antara aktor dengan sistem dalam pengiriman pesan dalam suatu urutan waktu tertentu.
Diagram urutan model dinamis yang menggambarkan contoh kelas yang berpartisipasi dalam kasus penggunaan dan pesan yang melewati antara mereka dari waktu ke waktu. Benda ditempatkan horizontal di bagian atas diagram urutan, masing-masing memiliki garis putus-putus, yang disebut garis hidup, secara vertikal di bawahnya. Fokus kontrol, diwakili oleh persegi panjang tipis, ditempatkan di atas garis hidup untuk menunjukkan ketika objek yang mengirim atau menerima pesan. Sebuah pesan adalah komunikasi antara objek yang
menyampaikan informasi dengan harapan kegiatan yang akan terjadi, dan pesan ditunjukkan oleh tanda panah yang menghubungkan dua benda yang menunjuk ke arah yang pesan sedang berlalu. Untuk membuat diagram urutan, pertama mengidentifikasi kelas yang berpartisipasi dalam kasus penggunaan dan kemudian menambahkan pesan yang lulus di antara mereka. Akhirnya, Anda akan perlu menambahkan garis hidup dan fokus kontrol. Sequence diagram sangat membantu untuk memahami spesifikasi real-time dan untuk skenario kompleks kasus penggunaan. (Alan Dennis, 2012 : 540 ).
Deskripsi simbol Squen Diagram dalam bahasa indonesia: 1. Aktor/An actor:
a. Adalah orang atau sistem yang berasal manfaatdari dan eksternal ke sistem.
b. Berpartisipasi secara berurutan dengan mengirimkandan / atau menerima pesan.
c. Ditempatkan di bagian atas diagram. 2. Sebuah objek/ An object:
a. Berpartisipasi secara berurutan dengan mengirimkandan / atau menerima pesan.
b. Ditempatkan di bagian atas diagram. 3. Sebuah garis hidup/A lifeline:
a. Menunjukkan kehidupan obyek selamaurutan.
b. Berisi X pada titik di manakelas tidak lagi berinteraksi. 4. Fokus kontrol/ focus of control:
a. Adalah persegi panjang yang panjang sempit ditempatkan di atas sebuahgaris hidup.
b. Menunjukkan ketika sebuah objek mengirim ataumenerima pesan. 5. Sebuah pesan/ A message:
a. Menyampaikan informasi dari satu objek keyang lain. 6. Penghancuran objek/ object destructions:
a. X ditempatkan pada akhir objekLifeline untuk menunjukkan bahwa itu akan keluar dariadanya.
Gambar 2.15 Contoh Sequence Diagram (Alan Dennis, 2012 :531)
2.7 Hybrid Mobile Apps
Seperti halnya website yang ada di internet, hybrid mobile apps dikembangkan menggunakan web teknologi seperti HTML5, CSS3 dan JavaScript. Perbedaan utamanya adalah aplikasi hybrid di install (dipasang) didalam platform ponsel layaknya aplikasi native. Sehingga mampu mengakses kemampuan hardware ponsel seperti kamera, kontak, accelerometer, GPS, dan lainnya. (John Bristowe:2015).
Hybrid mobile apps dibangun berdasarkan Web View dari platform ponsel, untuk mengakses kemampuan ponsel, pengertian web view menurut adalah: A web view is a native application component that is used to render web content
essentially a programmatically accessible wrapper around the built-in web browser included with the mobile device. For some examples, on the BlackBerry d as a Browser Field object (using
(using System/Library/Frameworks/UIKit.framework). (Wargo, 2014:1)
Wargo melanjutkan mengenai Hybrid Mobile Apps disebutkan bahwa Aplikasi yang dijalankan di dalam kontainer web view diperlakukan seperti
membuka aplikasi di dalam sebuah mobile browser, namun pada dasarnya aplikasi yang berjalan pada mobile web browser tidak memiliki akses ke dalam fitur perangkat keras ponsel seperti kamera, accelerometer, kompas, dll. Padahal sebuah aplikasi native pada umumnya sangat sering memanfaatkan fitur yang ada pada perangkat keras tersebut. Di sinilah Apache Cordova mengakomodasi kebutuhan dari aplikasi web yang dijalankan pada kontainer web view dengan adanya kumpulan JavaScript API yang memberikan akses untuk fitur yang ada pada perangkat keras ponsel. JavaScript API ini mengimplementasikan dua hal, yaitu: Sebuah pustaka JavaScript yang memberikan kemampuan ponsel kepada aplikasi web dengan penggunaan sintaks JavaScript, dan mencocokkan kode native yang sesuai berdasarkan JavaScript API yang digunakan dengan implementasi native API pada platform native ponsel.
Gambar 2.16 Arsitektur aplikasi Apache Cordova (John M. Wargo, 2014:5) PhoneGap dan Apache Cordova pada dasarnya adalah sama, PhoneGap merupakan turunan Cordova, namun PhoneGap memiliki perkakas tambahan
semenjak menjadi bagian dari Adobe Service. Baik itu PhoneGap maupun Cordova, keduanya adalah framework yang open source dan gratis untuk digunakan.
A. Apache Cordova
Apache Cordova adalah open source framework untuk mengembangkan aplikasi native cross-platform menggunakan HTML5. Menurut pencipta Apache Cordova menginginkan kemudahan dalam pengembangan aplikasi mobile antar platform dengan mengimplementasikan kombinasi antara web application technologies dengan fungsi native sehinga ini di sebut hybrid application.
Pengertian Cordova framework Cordova
wraps your HTML/JavaScript app into a native container which can access the device functions of several platforms. These functions are exposed via a unified JavaScript API, allowing you to easily write one set of code to target nearly every
phone or t (Anonim.
2015. Supported Platforms, http://cordova.apache.org/)
Keuntungan utama menggunakan Apache Cordova adalah membuat pengembangan aplikasi pada ponsel seperti pengembangan aplikasi web, sehingga pengetahuan dan kemampuan dari dunia pengembangan web bisa diterapkan dalam membuat aplikasi pada ponsel tanpa perlu mempelajari lagi bahasa pemrograman native setiap platform mobile seperti Objective-C/Swift (iOS), Java (android) ataupun C# (Windows Phone).
Menurut Wargo (2014:2)
web application, package the web application into the native container, test and . Di dalam aplikasi hybrid, saat pengguna membuka aplikasi yang di buat dengan Cordova, sebenarnya aplikasi tersebut memanggil fungsi web view dan memuat kode sumber seperti HTML, JavaScript dan CSS di dalam sistem aset dalam paket aplikasi dan konten data (bisa dari server), lalu menampilkannya ke dalam web view.
Apache Cordova saat ini menyediakan API sebagai berikut: Accelerometer Camera Capture Compass Connection Contacts Device Events File Geolocation Globalization InAppBrowser MediaNotification Splashscreen Storage B. HTML5
HTML (singkatan dari Hyper Text Markup Language) adalah kode dasar yang membangun seluruh website di dalam World Wide Web, dan HTML5 adalah langkah besar dalam sejarah perkembangan web, HTML5 tidak hanya versi mutakhir dari HTML tetapi merupakan kesatuan dari teknologi terkait yang membuat we bmenjadi lebih cerdas, lebih cepat dan kaya akan konten daripada sebelumnya.
Dengan HTML5, aplikasi web memiliki kemampuan baru yang memungkinkan aplikasi untuk beroperasi secara lebih efisien pada perangkat
mobile (atau perangkat dengan konektivitas terbatas), dan HTML5 dapat menggunakan basis data pada client-side untuk menyimpan data aplikasi.
Selain itu, Menurut Wargo (2014:10) disebutkan bahwa HTML5 mendukung penambahan file manifest yang berisi daftar semua file yang terdiri dari aplikasi web. Ketika file index pada aplikasi di muat, browser membaca file manifest, mengambil semua file yang terdaftar dalam manifest, dan men-download manifest dan menyimpannya ke perangkat ponsel. Jika ponsel yang kehilangan konektivitas jaringan, aplikasi masih bisa digunakan karena data yang diperlukan mungkin sudah disimpan secara lokal.
C. CSS3
HTML5 memiliki pendamping khusus di sisi visual yang disebut CSS3 (versi 3 dari Cascading Style Sheets ) yang sangat meningkatkan kemampuan CSS. Cascading Style Sheets digunakan untuk memisahkan kode desain dari konten, CSS menjadi cara standar dalam mengatur tampilan layar pada sebuah halaman website. Pengertian CSS3 berdasarkan World Wide Web Consortium (W3C) adalah: CSS Level 3 builds on CSS Level 2 module by module, using the CSS2.1 specification as its core. Each module adds functionality and/or replaces part of the CSS2.1 specification. The CSS Working Group intends that the new CSS modules will not contradict the CSS2.1 specification: only that they will add functionality and refine definitions. As each module is completed, it will be plugged in to the existing system of CSS2.1 plus previously-completed modules.
CSS3 adalah standar baru untuk antar muka yang kaya dan indah. Dengan CSS3, membuat tampilan yang baik menjadi lebih mudah, lebih cepat, dan lebih baik. Dengan dukungan untuk animasi, situs berbasis CSS3 sekarang dapat bersaing dengan situs berbasis flash. Selain itu situs web kini dapat dengan mudah berubah menjadi situs mobile hanya dari file CSS yang sama (responsive web). Kini browser mobile adalah pengadopsi awal dari standar W3C. Ini berarti ponsel adalah platform yang tepat untuk aplikasi yang dibangun dengan HTML5 / CSS3.
D. JavaScript
Sedari dulu, JavaScript dianggap sebagai bahasa kelas dua, hanya digunakan untuk melaksanakan fungsi dasar, seperti validasi input user. Namun pada 5 tahun terakhir, reputasi JavaScript telah meningkat secara dramatis. Hal ini terjadi sebagai akibat dari peningkatan kinerja dari JavaScript engine, dimulai pada Chrome dan lalu merembet ke semua browser utama lainnya. Lebih pentingnya, programmer mulai mengevaluasi kembali bahasa JavaScript itu sendiri dan memulai untuk memanfaatkan kekuatannya.
Meskipun JavaScript memiliki berbagai keanehan, dan para perancang bahasa ini membuat beberapa keputusan yang tidak biasa, JavaScript ternyata menjadi bahasa yang kuat dan flexible bila digunakan dengan benar.
E. Framework7
Menurut situs resmi Framework7 adalah
HTML framework to develop hybrid mobile apps or web apps with iOS & Android native look and feel.
memberikan pengembang kerangka untuk membuat aplikasi iOS & Android dengan HTML, CSS dan JavaScript dengan mudah dan jelas.
Gambar 2.17 Tampilan halaman utama website Framework7 (Vladimir Kharlampidi. 2015. Landing page. http://framework7.io/)
Alasan penulis memilih Framework7 adalah kelengkapan dari komponen antar muka yang disediakan, fitur pendukung yang lengkap sehingga tidak perlu
menambahkan plug-in lain dari pihak ketiga, dan dokumentasi framework yang disediakan lengkap sangat mudah dipelajari.
Framework7 menerapkan MIT Licensed yang memberikan izin, bebas biaya kepada siapa saja untuk memperoleh salinan sumber kode tanpa pembatasan, termasuk kebebasan untuk memodifikasi, mempublikasikan, mendistribusi dan menjual kepada pihak lain.
Penulis menggunakan Framework7 versi terbaru 1.2.0 yang diambil dari repositori resmi di https://github.com/nolimits4web/Framework7/tree/v1.2.0 yang dirilis pada 18 Juli 2015.
2.8 Aplikasi Android
Android merupakan sebuah sistem operasi mobile yang open source. Android sendiri mencakup sistem operasi, middleware, dan aplikasi mobile yang berbasis Linux Kernel yang dikembangkan oleh Google dan Open Handset Alliance. Sebuah aplikasi android dikembangkan menggunakan Android SDK dan ditujukan untuk perangkat ponsel yang menggunakan sistem operasi android ataupun runtime android. Ada banyak bahasa pemrograman yang bisa berjalan di Android, seperti C/C++, Python, Ruby dan HTML/JavaScript.
Menurut Gok dkk (2012:5), disebutkan bahwa
an archive that includes a combination of compiled Android components, a manifest file, and a b
.
Berdasarkan statistik Google Developer Console populasi pengguna android terbanyak adalah sistem operasi KitKat (API 19) dengan 38,9%, dan peringkat kedua adalah sistem operasi Lolipop (API 21) dengan 15,6%. Maka dari itu penulis memfokuskan pengembangan pada sistem operasi android KitKat dan Lolipop karena lebih dari separuh pengguna android menggunakan sistem operasi tersebut.
Gambar 2.18 Statistik pengguna sistem operasi android (Anonim. 2016. Platform Versions.
http://developer.android.com/about/dashboards/index.html#Platform)
2.9 RESTful Web Service
REST merupakan singkatan dari REpresentational State Transfer, berbeda dengan protokol lain seperti SOAP atau XML-RPC, REST itu lebih filosofi atau seperangkat prinsip dari protokol itu sendiri. REST adalah sepaket ide-ide tentang bagaimana data dapat ditransfer dengan elegan, dan meskipun tidak terikat dengan HTTP, REST mengambil keuntungan besar dari fitur HTTP, sehingga header dan kata kerja semua bisa datang bersama-sama untuk mendukung pengetahuan yang baik dari REST.
RESTful service, empat kata kerja HTTP yang sering digunakan untuk menyediakan satu set dasar CRUD (Create, Read, Update, Delete) fungsi: POST, GET, PUT dan DELETE. Hal ini juga mungkin untuk melihat implementasi dari kata kerja lain dari RESTful service, seperti PATCH untuk memungkinkan pembaruan parsial record, tapi empat kata kerja tadi merupakan dasar dari RESTful service. (Lorna Jane Mitchell. 2013:55)
2.10 JSON (JavaScript Object Notation)
JSON (JavaScript Objek Notation) adalah sub-set dari JavaScript dan merupakan struktur data native di JavaScript (Agung Julisman. 2014:34). JSON merupakan format penulisan untuk pertukaran data seperti XML. JSON mudah untuk dimengerti karena formatnya sederhana. JSON mampu melakukan pemindahan data antara dua interface dengan sangat cepat dan power full (misalnya antara php dengan JavaScript). Bentuk dari representasi struktur dari JSON adalah sebagai berikut
:
Gambar 2.19 Struktur JSON (Agung Julisman. 2014:34)
Data format JSON tersebut dapat dibaca: Nama Agung JUlisman, umur 24, anak pertama bernama Nizaam, anak kedua bernama Ibrahim dan no hp nya +6285720009849 (Agung Julisman. 2014:34).
Format JSON tidak tergantung dengan bahasa pemrograman apapun, struktur JSON sederhana sehingga mudah diimplementasikan. Karena JSON lebih sedikit membutuhkan space dan tidak perlu dituliskan dengan lengkap layaknya XML. Sehingga secara logika, proses pengolahannya (parsing) menjadi lebih cepat.
