II-1 BAB II
TINJAUAN PUSTAKA
Bab ini menjelaskan mengenai teori-teori dan metode yang akan digunakan untuk pemecahan masalah. Tinjauan pustaka diambil dari berbagai sumber yang berkaitan langsung dengan permasalahan yang dibahas dalam penelitian.
2.1 Fiksasi Eksternal (External Fixator)
Fiksasi eksternal merupakan salah satu metode pengobatan cedera tulang, sendi, dan jaringan lunak serta koreksi kelainan bentuk tulang dengan cara menyematkan tulang pada perangkat eksternal untuk menstabilkan anggota tubuh yang terluka atau cacat. Fiksasi eksternal mampu memanipulasi segmen anggota tubuh sehingga panjang dan kelurusan segmen tersebut dapat diperbaiki (Solomin, 2012).
2.1.1 Cara Kerja Fiksasi Eksternal
Seorang pasien penderita fraktur tulang yang tidak memerlukan pembedahan segera menggunakan fiksator eksternal sebagai salah satu alternatif pengobatan. Dokter bedah melakukan roentgen pada bagian tulang yang mengalami fraktur. Kemudian fiksator eksternal dipasang pada bagian yang mengalami fraktur tulang. Cara pemasangan fiksator eksternal dapat dilakukan dengan dua cara, pertama ketika frame sudah terpasang pada bagian fraktur tulang atau memasang frame beserta komponen lainnya secara bersamaan. Frame yang sudah terpasang pada bagian fraktur tulang dipasang wire dari frame hingga menembus tulang yang mengalami fraktur. Setelah semua komponen terpasang maka dokter akan memasukan 3 parameter deformitas ke software deformitas skeletal pasien, ukuran frame yang sesuai, dan posisi frame yang tepat pada anggota tubuh pasien. Sehingga dari software ini dapat ditentukan panjang strut fiksator yang tepat untuk dipasangkan pada tubuh pasien. Pengoperasian software dimulai dari log in dengan akun yang sudah ada. Kemudian dokter akan memasukkan data-data pasien dan deskripsi fraktur yang dialami. Dokter bedah akan memasukkan detail deformitas yang terjadi pada pasien. Software akan
II-2
memproses gejala-gejala yang dialami oleh pasien kemudian mengkalkulasikan jadwal pengoperasian strut tiap harinya.
2.1.2 Bagian-bagian Fiksasi Eksternal Sistem Heksapod
Gambar 2.1 Bagian Utama Fiksasi Eksternal
Bagian-bagian utama fiksator eksternal yaitu : 1. Ring
Ring merupakan bagian dari fiksator eksternal yang berfungsi untuk menghubungkan strut, pins dan wire ke tulang manusia. Ring terdiri dari lubang dengan jarak yang sama. Ketebalan ring rata-rata adalah 7mm.
2. Universal Joint
Universal Joint merupakan bagian untuk menyambungkan antara strut dan frame. Bagian ini terdiri dari 12 buah terletak pada ujung-ujung setiap strut.
3. Strut
Strut merupakan kunci untuk pengoperasian fiksator eksternal. Strut terdiri dari 6 buah yang terhubung pada frame atas dan frame bawah.
1
2
3
II-3 2.2 Sistem Heksapod
Heksapod merupakan struktur mekanisme paralel berkaki enam yang telah digunakan di dunia robotika (Taghirad, 2013). Struktur mekanisme paralel merupakan dua platform (satu sebagai base/dasar dan satu sebagai platform/bagian yang bergerak) yang dihubungkan dengan sambungan paralel (berupa strut) dengan bantuan sambungan prismatik tertentu. Struktur mekanisme heksapod memiliki enam kaki yang merupakan aktuator linier (contoh: silinder hidrolik). Hasil dari mekanisme ini adalah platform yang dapat bergerak dengan enam derajat kebebasan (Degrees of Freedom/DOF) secara relatif terhadap platform lainnya (base). Derajat kebebasan sendiri merupakan jumlah gerakan independen yang dapat dibuat suatu objek terhadap sistem koordinat yang dapat menyebabkan perubahan posisi atau orientasi. Semakin banyak derajat kebebasan gerak, makin kompleks pergerakan yang dapat dilakukan. Karena memiliki enam DOF, platform ini mampu bergerak dalam tiga arah linear dan tiga arah angular baik secara tunggal maupun dengan kombinasi apapun.
Gambar 2.2 Enam Derajat Kebebasan pada Suatu Objek
Tipe struktur heksapod telah dikenal dalam waktu yang cukup lama. Sekitar tahun 1800, A. L. Cauchy (ahli matematika) mempelajari kekakuan (stiffness) dari
“articulated octahedron”. Pada tahun 1949, V. E. Gough menggunakan mekanisme yang sama untuk melakukan pengujian ban. Kemudian pada tahun 1965 mekanisme ini ditemukan ulang dan digunakan secara sangat luas dalam simulator penerbangan oleh D. Stewart. Sejak saat itu, semua mekanisme kaki
II-4
paralel tersebut disebut “Stewart Platform”, meskipun Gough adalah yang pertama kali menemukan mekanisme tersebut.
2.3 Sistem Aplikasi Web Multi Pengguna
Suatu sistem adalah suatu jaringan kerja dari prosedur-prosedur yang saling berhubungan, berkumpul bersama-sama untuk melakukan suatu kegiatan atau menyelesaikan suatu sasaran yang tertentu. istilah yang digunakan untuk pengguna komputer bagi pemecahan masalah. Biasanya istilah aplikasi dipasangkan atau digabungkan dengan suatu perangkat lunak akan dapat memberikan makna atau arti baru yaitu suatu program yang ditulis atau dibuat untuk menangani masalah tertentu (Tirtobisono, 1999). Aplikasi merupakan suatu subkelas dari perangkat lunak yang memanfaatkan kemampuan komputer dalam melakukan suatu tugas tertentu. Contoh aplikasi adalah pengolah data, lembar kerja, dan pemutar media.
2.3.1 Sistem Aplikasi Web
Aplikasi web adalah sebuah program yang disimpan di server dan dikirim melalui internet dan diakses melalui antarmuka browser (Rouse, 2011). Aplikasi web juga dapat diartikan sebagai sebuah software yang dikodekan dengan pemograman yang dapat terintegrasi dengan browser, biasanya pemograman yang digunakan adalah JavaScript yang dikombinasikan dengan HTML.
Sebuah aplikasi web pada dasarnya memiliki 3 layer. Pada layer pertama berada di sisi klien yang memiliki sistem browser dasar. Pada layer kedua terdapat dynamic content generation tool seperti JavaScript dan php. Pada layer ketiga terdapat penyimpanan data dan terdiri dari back end dari database seperti Mysql atau oracle. Untuk ilustrasi cara kerja aplikasi web dapat dilihat pada Gambar 2.3.
II-5
Gambar 2.3 Cara Kerja Aplikasi Web
Keunggulan aplikasi berbasis web (Noviyanto dan Jati, 2009) : 1. Aplikasi dapat dijalankan tanpa harus melakukan penginstallan
2. Tidak memerlukan lisensi ketika menggunakan web based application, sebab lisensi telah menjadi tanggung jawab dari penyedia aplikasi web.
3. Dapat dijalankan di sistem operasi apapun, aplikasi berbasis web dapat di akses dengan memiliki browser beserta akses internet.
4. Dapat diakses melalui media seperti computer, Smartphone atau tablet yang sudah sesuai dengan standard.
5. Tidak memerlukan spesifikasi computer yang tinggi untuk menggunakan aplikasi berbasis web ini, sebab di sebagaian besar proses dilakukan di web server penyedia aplikasi berbasis web ini.
2.3.2 Multiuser (Multi Pengguna)
Multiuser atau multi pengguna adalah sistem operasi atau perangkat lunak aplikasi yang memperbolehkan akses oleh beberapa pengguna dalam waktu bersamaan ke sistem operasi atau aplikasi tersebut dan dimana lebih dari satu orang dapat menggunakan program yang sama atau berbeda dari satu mesin yang sama pada saat bersamaan, di terminal yang sama atau berbeda (Ariyantantina, 2012). Tujuan sistem multi pengguna yaitu :
1. Meningkatkan produktivitas dan efektifitas sumber daya 2. Meningkatkan produktivitas dan efektifitas organisasi
II-6
3. Meningkatkan layanan kepada mereka yang tergantung pada sistem multi user
Fitur yang harus dimiliki oleh sistem multi pengguna :
1. Mekanisme authentication untuk verifikasi identitas pemakai.
2. Mekanisme proteksi terhadap program user yang mengandung bug sehingga dapat menghindari kemungkinan memblokir aplikasi lain dalam sistem.
3. Mekanisme penghitungan yang membatasi jumlah sumberdaya yang dapat dialokasi untuk masing-masing pemakai.
2.4 Perilaku Pengguna Perangkat Fiksasi Eksternal Berbasis Heksapod Fiksasi eskternal adalah metode untuk mengobati cedera tulang dan sendi serta untuk mengoreksi kelainan bentuk tulang dengan menempelkan tulang ke perangkat fiksasi eksternal eksternal yang akan menstabilkan anggota badan mengalami cedera. Selain itu, perangkat ini dapat melakukan manipulasi pada segmen ekstremitas untuk mencapai pemulihan panjang dan keselarasan (Solomin, 2012).
2.4.1 Spesifikasi Fraktur
Jenis fraktur yang dapat ditangani dengan perangkat fiksasi eksternal adalah sebagai berikut (Solomin, 2012):
a.) Fraktur pada hampir semua tulang kerangka, termasuk panggul, humerus, lengan bawah, klavikula, femur, tibia, dan kaki / pergelangan kaki.
- Perangkat fiksasi eksternal dapat diaplikasikan pada dalam beberapa tingkatan seperti : diaphyseal, epi-/metaphyseal, intraarticular.
- Fraktur segmental sederhana, kominutif dan fraktur segmental - Fraktur terbuka atau tertutup
- Fraktur dengan potensial terkontaminasi pada jaringan lunak dan berpotensi terkenal infeksi
b.) Malunion/union
- Infeksi pada malunion/union - Trauma pada deformitas
II-7 c.) Patologi Ortopedi
- Deformitas bawaan, cacat tulang, reseksi tulang segmental untuk kondisi patologis
- Patologi ortopedi yang terinfeksi d.) Patologi gabungan
- Kesalahan pada formasi - Kontraktur
- Diskolasi
- Disfasia atau penyakit degenertif 2.4.2 Spesifikasi Pasien
Indikasi dasar untuk penggunaan fiksasi eksternal adalah sebagai berikut (Solomin, 2012) :
1. Fraktur dan dislokasi yang disertai kerusakan ringan 2. Cedera pada sendi, termasuk cedera akibat luka tembak 3. Fraktur ganda
4. Fraktur dengan kerusakan luas termasuk komunisi dan pengupasan periosteal (C3 dalam klasifikasi AO / ASIF)
5. Pasien yang membutuhkan osteogenesis distraksi dengan kondisi kardiovaskular kronis, seperti endarteritis, diabaete dan penyakit vaskular parifer
6. Penumbuhan kulit, otot, tendon, pembuluh dan saraf secara disengaja
7. Bedah estetika yang melibatkan perbedaan panjang tungkai, malformasi dan malalignment.
8. Operasi rekonstruktif “tibialisasi” dari fibula, pemanjangan tunggul, koreksi tangan dan kaki,
2.4.3 Gejala yang Dialami Pasien Setelah Operasi
Setelah pemasangan perangkat fiksasi eksternal pasien akan mengalami gejala-gejala seperti berikut ini (Solomin, 2012):
1. Pasien akan mengalami rasa sakit di area insersi setelah pemasangan fiksasi eksternal. Pasien akan diberi obat untuk mengontrol rasa sakit.
II-8
2. Setelah operasi pelepasang fiksasi eksternal, pasien mengalami rasa sakit, bengkak dan rasa kaku di dalam dan di luar bagian fraktur. Pasien mengalami penurunan jangkauan jangkauan gerakan, kekuatan dan kontrol di bawah otot kaki.
3. Kemerahan dan rasa hangat di sekitar wire. Kemerahan dengan jumlah pada bagian wire adalah hal yang wajar. Namun, apabila kemerahan hampir merata di seluruh bagian kaki, perlu pemeriksaan oleh dokter.
4. Demam persisten 100,5 farenheit
5. Keluar cairan berwarna putih, kuning atau kehijauan di sekitar wire.
6. Bau yang tidak sedap di sekitar wire adalah hal yang wajar.
7. Apabila mengalami rasa sakit di bagian yang tidak terpasang wire, kemungkinan terdapat masalah pada saraf. Tanda berikutnya adalah perasaan nyeri yang terus meningkat di bagian tuubuh yang terpasang fiksasi eksternal. Apabila hal ini terjadi maka perlu melakukan konsultasi kepada dokter yang menangani, karena dapat mengkakibatkan infeksi saraf.
2.4.4 Perawatan Selama Masa Penyembuhan
Hal-hal berikut perlu diperhatikan oleh pasien perangkat fiksasi eksternal (Solomin, 2012) :
1. Dokter bedah akan memberi arahan untuk perawatan pada wire. Perawatan pada wire dengan menghilangkan darah yang keluar dari pin setelah operasi pemasangan fiksasi eksternal. Pijatan lembut di sekitar wire akan membantu menjaga kulit di sekitar wire. Jika kesulitan dalam menjangkau wire atau bagian fiksasi eksternal yang lain maka dapat meminta bantuan orang lain.
2. Perawatan ketika membersihkan badan atau mandi ialah pasien tidak diperbolehkan mandi selama 5 hingga 7 hari setelah pemasangan fiksasi eksternal. Setelah diizinkan untuk mandi. Pasien dapat memasangkan karet pada bagian wire yang terpasang pada bagian tubuh.
3. Pasien melakukan fisioterapi komprehensif. Terapi harus dilakukan sesegera mungkin agar segera dapat melakukan mobilitas secara penuh
4. Pasien tidak diperkenankan mengendarai mobil.
II-9 2.5 Software Taylor Spatial Frame
Software Taylor Spatial Frame merupakan software berbasis web yang khusus digunakan untuk perangkat Taylor Spatial Frame. Software ini digunakan oleh ahli bedah untuk melakukan koreksi total deformitas skeletal yang dipasang pada kaki pasien yang bengkok. Software Taylor Spatial Frame memiliki kelebihan dibanding software perangkat fiksasi eksternal lain, yaitu ketika foto x- ray diambil, pengguna software dapat memasukkan ke enam panjang strut ke dalam software (Ganger R, 2001). Tampilan dari software Taylor Spatial Frame dapat dilihat pada gambar :
Gambar 2.4 Tampilan Taylor Spatial Frame
2.5.1 Spesifikasi Software Taylor Spatial Frame 1. Menu
Menu untuk pengerjaan tugas dibedakan menjadi 3 menu utama yaitu home, cases dan literature (Taylor, 2002)
Tabel 2.1 Menu Software Taylor Spatial Frame
Menu Halaman / Sub Menu
Home Log in
Help
Useful Links File
Tabel 2.1 Menu Software Taylor Spatial Frame (Lanjutan)
II-10
Menu Halaman / Sub Menu
Cases Case Info
Define Deformity Select Frame Mount Frame Initial Frame Final Frame Structure at Risk Prescription Report
2. Warna yang digunakan
Tampilan pada software Taylor Spatial Frame menggunakan dominasi warna ungu. Pada Tabel 4.8 merupakan warna dasar yang digunakan untuk setiap halaman.
Tabel 2.2 Pemilihan Warna Software Taylor Spatial Frame
Warna Kode Warna
#39e259
#56538e
#65cea7
#f9f9f9
II-11
Selain warna pada tampilan layar, terdapat warna pada strut. Strut terdiri dari 6 jenis warna. Berikut adalah tabel 2.3 yang menunjukkan warna strut untuk perangkat Taylor Spatial Frame :
Tabel 2.3 Warna Strut Software Taylor Spatial Frame Warna Kode Warna Keterangan
#e74e31 Strut 1
#ef8942 Strut 2
#fbd144 Strut 3
#37a342 Strut 4
#6fbdb1 Strut 5
#b479a5 Strut 6
3. Resolusi Layar
Resolusi layar yang harus dimiliki untuk menggunakan Software Taylor Spatial Frame minimum adalah 1024 x 768 pixel.
4. Browser setting
Netscape Navigator/Communicator 4.7 atau browser lain yang lebih tinggi .
2.5.2 Fitur Software Taylor Spatial Frame
Fitur pada software Taylor Spatial Frame dipaparkan pada Tabel 2.4. Fitur dibedakan menurut halaman yang ada. Fitur dijabarkan menurut konten-konten yang ada dalam setiap halaman. Berikut adalah daftar fitur pada software Taylor Spatial Frame.
II-12
Tabel 2.4 Fitur Software Taylor Spatial Frame
Halaman Fitur Konten
Home Page Log in User Name Password Case Info Penyimpanan
data
Nama Kasus Inisial Pasien
Tanggal dimulai penanganan Catatan Kasus
Sisi tulang yang dikoreksi Define
Deformity
Penyimpanan data
AP View Angulasi
Besar sudut angulasi dari sisi AP Besar sudut translasi dari sisi AP Besar sudut angulasi dari sisi Lateral Besar sudut translasi dari sisi Lateral Besar sudut angulasi dari sisi Axial Besar sudut translasi dari sisi Axial
Simulasi Simulasi besar pergeseran tulang dari sisi AP Simulasi besar pergeseran tulang dari sisi lateral Simulasi besar pergeseran tulang dari sisi Axial Select Frame Penyimpanan
data
Ukuran ring atas Ukuran ring bawah
Ukuran strut 1 - ukuran strut 6 Mount
Frame
Penyimpanan data
Mode Operatif
Frame offset dari sisi AP (mm) Frame offset dari sisi Lateral (mm) Axial frame offset (mm)
Besar sudut rotasi
Simulasi Simulasi tulang terhadap titik origin dari sisi AP
II-13
Tabel 2.4 Fitur Software Taylor Spatial Frame (Lanjutan)
Halaman Fitur Konten
Simulasi tulang terhadap titik origin dari sisi Lateral Simulasi tulang terhadap titik origin dari sisi Axial Initial Frame Penyimpanan
data
Ukuran strut 1 - ukuran strut 6
Final Frame Simulasi Simulasi frame terpasang pada tulang dari sisi AP Simulasi frame terpasang pada tulang dari sisi Lateral
Simulasi frame terpasang pada tulang dari sisi Axial Structure at
Risk
Penyimpanan data
Besar AP view SAR Offset (mm) Besar Axial view SAR Offset (mm) Besar Lateral view SAR Offset (mm) Besar maksimum rotasi
Hitung Jumlah hari minimum untuk koreksi tulang Prescription Penyimpanan
data
Tanggal dimulai koreksi
Hitung Jadwal pemutaran strut 1 - strut 6
Panjang target strut yang melebihi ukuran strut Report Menampilkan
data
Besar sudut pergeseran tulang Sisi anatomi
Komponen frame
Ukuran awal strut 1 - strut 6 Ukuran akhir strut 1 - strut 6 Jadwal pemutaran strut 1 - strut 6 Unduh PDF Hasil rangkuman report
II-14 2.6 Spesifikasi Software TrueLok Hexapod
Software Truelok Hexapod merupakan Software yang dikeluarkan oleh perusahaan Orthofix. Software ini pertama kali diciptakan di Rumah Sakit Texas Scottish Rite untuk anak-anak. Tampilan pada Software TrueLok Hexapod dapat dilihat pada Gambar 2.6. Software TrueLok Hexapod memiliki beberapa spesifikasi, yaitu :
Gambar 2.5 Tampilan Software TrueLok Hexapod
1. Menu
Menu yang terdapat dalam Software TrueLok Hexapod dibedakan berdasarkan halaman yang ada. Menu yang terdapat dalam software ini dapat dilihat pada Tabel 2.5.
Tabel 2.5 Menu Software TrueLok Hexapod
Menu Halaman
Home Page Log in
Patient Add New Patient
List of Patient
Cases Case Data
Deformity Parameter Frame Parameter
II-15
Tabel 2.5 Menu Software TrueLok Hexapod (Lanjutan)
Menu Halaman
Postoperative End of correction Schedule
Prescription Report
Account Change Password
2. Warna yang digunakan
Tampilan pada Software Taylor Spatial Frame menggunakan dominasi warna biru. Pada Tabel 2.6 merupakan warna dasar yang digunakan untuk setiap halaman.
Tabel 2.6 Warna Dasar Software Taylor Spatial Frame
Warna Kode Warna
#015499
# 6599d4
#ebefee
#f9f9f9
II-16
Selain warna pada tampilan layar, terdapat warna pada strut. Strut terdiri dari 6 jenis warna. Berikut adalah Tabel 2.7 yang menunjukkan warna strut untuk perangkat Taylor Spatial Frame :
Tabel 2.7 Warna Strut Taylor Spatial Frame Warna Kode Warna Keterangan
# e73a3e Strut 1
#f4a51d Strut 2
#f2e500 Strut 3
#9fc12b Strut 4
#46bbc6 Strut 5
#e371a4 Strut 6
3. Resolusi layar
Resolusi layar yang digunakan adalah 1024x768 atau resolusi yang lebuh tinggi.
4. Browser setting
Microsoft Internet Explorer : Version 8 or 9
2.6.1 Fitur Software TrueLook Hexapod
Fitur pada Software TrueLook Hexapod dipaparkan pada tabel 2.8. Fitur dibedakan menurut halaman yang ada. Fitur dijabarkan menurut konten-konten yang ada dalam setiap halaman. Berikut adalah daftar fitur pada Software TrueLook Hexapod :
II-17
Tabel 2.8 Fitur Software TrueLook Hexapod
Halaman Fitur Konten
Home Page Log in User Name Password Case Data Penyimpanan
data
ID Pasien Nama Kasus
Tanggal pendaftaran Sisi anatomi tulang Catatan kasus Daftar pasien Daftar kasus Deformity
Parameter
Penyimpanan data
Semen referensi
Besar sudut angulasi dari AP view Besar sudut translasi dari AP view Besar sudut angulasi dari Lateral view Besar sudut translasi dari Lateral view Besar sudut rotasi
Panjang translasi aksial Panjang pemanjangan tulang Frame
Parameter
Penyimpanan data
Tipe ring atas Ukuran ring atas Tipe ring bawah Ukuran ring bawah Posisi referensi ring (mm) Posisi ring ke dua (mm)
Frame offset dari AP view (mm) Frame offset dari Lateral view (mm) Reference Ring AP translation (mm) Ukuran awal strut 1 - strut 6
Simulasi Simulasi frame terpasang pada tulang dari sisi AP
II-18
Simulasi frame terpasang pada tulang dari sisi Lateral
Simulasi frame terpasang pada tulang dari sisi Axial
Unduh pdf Simulasi frame terpasang pada tulang Postoperative Penyimpanan
data
Besar sudut Reference Ring AP Reference Ring ML translation (mm) Besar sudut Reference Ring ML Posisi Referensi ring relatif Posisi referensi ring (mm) Besar sudut rotasi frame
Simulasi Simulasi frame terpasang pada tulang dari sisi AP
Simulasi frame terpasang pada tulang dari sisi Lateral
Simulasi frame terpasang pada tulang dari sisi Axial
End of
correction
Penyimpanan data
Sudut AP setelah/sedang dilakukan koreksi Panjang AP setelah/sedang dilakukan koreksi (mm)
Sudut ML setelah/sedang dilakukan koreksi Panjang ML setelah/sedang dilakukan koreksi (mm)
Besar sudut rotasi setelah/sedang dilakukan koreksi
Pemanjangan tulang (mm)
Simulasi Simulasi akhir posisi tulang dari sisi AP Simulasi akhir posisi tulang dari sisi Lateral Simulasi akhir posisi tulang dari sisi Axial Schedule Penyimpanan
data
Rata-rata koreksi per hari (mm/day) Kecepatan maksimal perputaran (deg/day)
II-19
Kecepatan maksimum angular (deg/day) Tanggal operasi
Periode laten (hari)
Periode waktu koreksi (jam) Prescription Hitung Jadwal pemutaran strut 1 - strut 6
Simulasi Simulasi koreksi dasi sisi AP Simulasi koreksi dasi sisi Lateral Simulasi koreksi dasi sisi Axial Report Menampilkan
data
Jadwal pemutaran strut 1 - strut 6
Unduh PDF Jadwal pemutaran strut 1 - strut 6
2.7 MVP (Minimum Viable Product)
Menurut Ries (2011) Minimum Viable Product adalah produk web atau aplikasi dengan spesifikasi seminimal mungkin dan pembuatan secepat mungkin, namun mampu melayani kebutuhan ini pengguna semaksimal mungkin. Tujuan pembuatan MVP ialah menguji asumsi bisnis dan memastikan pengembangan aplikasi sudah sesuai dengan tujuan bisnis. Dengan begitu, aplikasi yang sudah dibuat dapat terus berkembang sesuai dengan harapan desainer. Selain itu, MVP dibuat untuk meningkatkan efisiensi biaya pengembangan aplikasi. Hal itu dikarenakan fitur di dalam produk MVP sangat minimum sehingga untuk pengembangan dan maintenanance tidak membutuhkan banyak tenaga desainer aplikasi. Adapun, tujuan akhir dari pembuatan MVP ialah menghasilkan aplikasi yang dicintai oleh pengguna dan mendatangkan nilai bisnis bagi perusahaan.
Kelebihan dari MVP :
a. Waktu pengembangannya yang singkat. Paling lama, waktu pengembangan MVP hanya membutuhkan waktu empat minggu. Lalu, kelebihan selanjutnya ialah biaya produksinya terjangkau. Sebab, dalam proses pembuatannya tidak membutuhkan banyak desainer.
II-20
b. Untuk mendapatkan umpan balik dari pengguna membutuhkan waktu yang singkat. Karena fitur didalamnya yang minimum, pengguna akan sangat cepat menguasai dan berinteraksi dengan MVP. Dengan begitu, pengguna akan cepeat memberikan umpan balik untuk sebuah produk aplikasi. Umpan balik dari pelanggan dapat digunakan untuk merumuskan strategi lebih lanjut agar sebuah produk bisa bersaing dalam sebuah pasar produk sejenis.
Tipe Minimum Viable Product
Untuk melakukan hipotesis terhadap MVP perlu memilih tipe MVP yang sesuai dengan tujuan. Menurut Saadatmand (2014), tipe dari MVP ada 2 yaitu : a. Low Fidelity MVP
Tipe low fidelity MVP merupakan tahap paling awal dan paling sederhana dalam membangun sebuah produk. Untuk tipe ini sangat bermanfaat untuk mendapatkan informasi kebutuhan pelanggan secepat mungkin untuk segera dilakukan validasi. Tujuan dari tipe ini yaitu mengetahui keinginan pelanggan terhadap suatu produk dengan cara yang sederhana dan singkat. Sehingga dapat dikatakan bahwa low fidelity MVP merupakan konsep awal mengetahui solusi terbaik untuk pelanggan. Berikut adalah beberapa cara untuk mengidentifikasi kebutuhan pelanggan tipe low fidelity MVP :
- Wawancara pelanggan - User story (cerita pengguna)
- Paper prototype (prototipe menggunakan kertas) - Digital prototype (prototipe digital)
- Blogs atau forum video - Pengujian halaman web - Pendapat pendengar - Survei mikro
- Kampanye sebuah iklan b. High Fidelity MVP
Tipe High Fidelity MVP merupkan tipe yang memperhatikan fungsionalitas sebuah produk. Tipe ini sudah menyerupai produk yang dapat bekerja. Sehingga pelanggan dapat menjalankan proses untuk menyelesaikan tugas-tugas. Tujuan
II-21
dari tipe high fidelity MVP adalah membangun sebuah produk prototipe yang bisa dilihat fungsionalitasnya. Berikut adalah beberapa cara untuk mengidentifikasikan kebutuhan pelanggan tipe high fidelity MVP :
- Wireframe - Single featured
- Physicl product prototype - Concierge
- Wizard of oz - Piecemeal - Crowfunding
2.8 User Story
Menurut Cohn (2014) user story adalah deskripsi pendek dan sederhana sebuah fitur yang disampaikan dari sudut pandang seseorang yang menginginkan kapabilitas baru pada sebuah sistem. Untuk menyusun sebuah sistem yang baru, maka perlu mengetahui kebutuhan dari sistem tersebut. Seorang user yang menginginkan adanya sistem yang baru harus memiliki komunikasi dengan orang yang akan membangun sistem tersebut. Untuk mencapai keberhasilan dari sebuah proyek maka perlu dilakukan pengumpulan informasi dari beberapa pihak seperti pelanggan atau user, domain expert dan seseorang yang memakai sistem untuk kebutuhan bisnis atau organisasi, dan technical team. Output dari user story adalah deskripsi tugas yang harus dikejakan oleh develroper yang akan dibuat sebuah sistem aplikasi ataupun sistem infomasi.
User story dituliskan pada kartu indeks yang kemudian disusun untuk menunjang perencanaan dan diskusi. User story dapat dibuat dengan menggunakan pola saya sebagai seorang (who), saya ingin (what) sehingga (why).
Jeffries (2001) menyatakan user story disusun dari 3 aspek yaitu : a. Card
Card merupakan deskripsi tertulis dari cerita user yang digunakan untuk perencanaan dan pengingat untuk menyusun requirement. Card menjadi manifestasi paling terlihat dari sebuah user story namun bukan menjadi yang
II-22
terpenting. User story card dapat diwakilkan dengan membuat sebuah deskripsi hasil rekap hasil wawancara.
Gambar 2.6 Contoh User Story b. Conversation
Conversation merupakan wawancara yang berfungsi untuk memperjelas user story. Detail untuk menyusun sistem didapatkan dari hasil wawancara.
c. Confirmation
Confirmation merupakan pengujian yang menyampaikan detail dari user story kepada user yang mendandakan bahwa sebuah user story telah berakhir.
Davies (2001) mengatakan bahwa card hanya untuk mewakili kebutuhan user atau pengguna. Namun yang terpenting ialah ketika melakukan wawancara terhadap pengguna yang dicatat kemudian dilakukan konfirmasi. Konfirmasi dilakukan dengan melakukan diskusi antara tim pengembangan dan user.
Proses User Story
Menurut penelitian yang telah dilakukan oleh Norman (2015), penyusunan user story dilakukan 3 langkah sebagai berikut :
1. Create user story (membuat user story)
Pengumpulan user story dilakukan berdasarkan 3 aspek yaitu card, conversation dan confirmation. Pada tahap pengumpulan user story dilakukan penggalian informasi secara intensif untuk mengungkap kebutuhan dengan wawancara. Hal terpenting dalam penggalian informasi adalah melalui wawancara langsung terhadap user calon pengguna aplikasi
II-23
(Cohn, 2014). User story dapat dituliskan sewaktu-waktu ada tambahan selama proyek pembuata sebuah sistem berlangsung.
2. Prioritizing User Story (memprioritaskan user story).
Penyusunan prioritas dilakukan guna mengurutkan user stories sesuai dengan urutan dari yang akan dikerjakan terlebih dahulu. Penyusunan prioritas dilakukan oleh tim pengembang dan user. Ada beberapa dimensi untuk pertimbangan mengurutkan stories. Faktor teknis yang harus dipertimbangkan ialah :
a. Resiko apabila sebuah stories tidak bisa diselesaikan sesuai keingian b. Dampak dari sebuah story yang akan mempegaruhi stories lain
apabila sebuah story ditunda
Selain itu, user memiliki beberapa faktor yang dapat digunakan untuk menyortir sebuah cerita, antara lain :
a. Sebuah story yang dibuat satu user bisa diterima oleh user lain
b. Sebuah story diutamakan apabila memang dianggap penting oleh sekelompok user.
c. Hubungan yang ada antar user story (contoh : zoom out story mungkin tidak memiliki prioritas yang lebih tinggi karena sudah ada zoom in user story yang pasti memiliki prioritas yang lebih tinggi) Sedangkan tahap dalam melakukan penyusunan prioritas adalah sebagai berikut :
1. Mengurutkan user story berdasarkan dari kebutuhan user yang paling mendesak.
2. Menentukan velocity.
3. Membagi user story setiap rilis ke dalam iterasi. Jumlah iterasi ditentukan dari hasil velocity.
4. Melakukan pengembangan task setiap user story.
5. Klarifikasi terhadap user story yang telah dirutukan sesuai prioritas.
Tim developer mempunyai sebuah rangkaian prioritas yang akan diimplementasikan menjadi sebuah aplikasi, dan begitupula dengan user yang diwawancarai. Apabila ada perbedaan pendapat antara keduanya maka harus
II-24
permintaan user yang diutamakan. User tidak dapat menyanggah rangkaian prioritas yang disusun developer tanpa mengetahui informasi terlebih dahulu dari tim developer. Minimal, user mengetahui perkiraan sebuah user story akan terealisasi. Sebelum sebuah story di prioritaskan, terlebih dahulu diestimasi secara tertulis apabila ada sebuah pernyataan user yang kurang jelas.
Apabila terdapat permasalahan ketika memprioritaskan sebuah story, maka sebuah story dapat dipisah menjadi dua atau lebih. Story yang terpisahkan tidak harus diurutkan atas bawah, bisa dipisahkan oleh story yang lain. Setelah diurutkan menurut prioritas, maka dilakukan klarifikasi terhadap story Menurut Cohn (2014) user mendeskripsikan kebutuhan untuk 2 alasan utama. Pertama, setiap stories harus dideskripsikan dalam bahasa bisnis bukan dalam bahasa teknis sehigga user dapat membantu pengembang dalam penyusunan prioritas untuk dimasukkan ke dalam iterasi. Kedua, user merupakan posisi terbaik utuk menggambarkan sistem aplikasi yang dibutuhkan.
Setelah user story diurutkan berdasarkan prioritas, peneliti harus mengetahui prediksi waktu untuk menyelesaikan sebuah proyek. Untuk memprediksi durasi dari sebuah proyek dilakukan perhitungan perkiraan jumlah story yang dikerjakan dalam target waktu sebuah proyek yang disebut dengan velocity. Velocity ditentukan dengan 3 cara :
- Gunakan nilai historis
- Menjalankan iterasi awal dan gunakan velocity tersebut untuk iterasi selanjutnya
- Memperkirakan velocity
Menggunakan nilai historis adalah opsi terbaik,namun hanya bisa dilakukan apabila sebelumnya sudah ada tim yang menjalankan proyek ini. Namun sangat jarang terjadi tim yang sama dapat bekerja berturut-turut di proyek yang serupa.
Dengan menjalankan iterasi awal, dapat ditentukan kecepatan awal dengan memperkirakan lama hari target pengerjaan sebuah proyek. Jumlah iterasi bisa didapatkan dari membagi rata user story dengan target waktu yang sudah ditentukan. Iterasi merupakan pengelompokkan user story berdasarkan prioritas yang sudah disusun.
II-25
Cohn (2014) memberikan contoh apabila sebuah proyek memiliki 100 user story, kemudian di estimasikan setiap iterasi terdiri dari 20 stories. Berarti sebuah proyek dibagi menjadi 5 iterasi. Iterasi didiskusikan oleh tim pengembang yaitu programmer, penguji dan user. Urutan kegiatan untuk diskusi perencanaan sebuah iterasi adalah sebagai berikut :
a. Mendiskusikan user story secara umum
b. Memisahkan user story ke dalam task penyusunnya
c. Tim pengembang memastikan bahwa mereka mampu untuk mengerjakan task.
Saat dilakukan diskusi perencanaan iterasi, tim pengembang sudah memiliki serangkaian user story yang sudah diprioritaskan. Pada saat diskusi ini, user dapat mengubah prioritas sebuah cerita. Tim pengembang dapat mengajukan pertanyaan-pertanyaan untuk memahami betul sebuah story untuk memahami task yang harus dilakukan. Tidak perlu memahami cerita terlalu detail karena akan membuat waktu diskusi menjadi sangat lama dan tidak efisien.
3. Pengembangan Task
User story yang telah diurutkan sesuai prioritas kemudian dikembangkan menjadi task. Task digunakan untuk menunjukkan hal-hal yang akan dilakukan dalam proses pengembangan aplikasi untuk memenuhi persyaratan dan kebutuhan user story. Tidak ada seni untuk memisahkan cerita ke dalam task. Pengembangan user story menjadi sebuah task adalah penting, karena :
a. Untuk sebuah proyek yang rumit, story dimplementasikan oleh banyak pengembang sehingga task dikembangkan oleh banyak developer.
b. Story merupakan deskripsi fungsionalitas dari user. User tidak mendeskripsikan tugas yang harus dilakukan oleh developer, mereka hanya mendeskripsikan kebutuhan. Sehingga perlu dilakukan pengembangan menjadi task supaya membantu menunjukkan task yang belum terlaksana.
2.9 Usability (Usabilitas)
Usabilitas berasal dari kata usable yang berarti dapat digunakan dengan baik. Nielsen (1992) menyatakan bahwa usability adalah atribut kualitas yang
II-26
menjelaskan atau mengukur seberapa mudah penggunaan suatu antar muka (interface). Kata “usability” juga merujuk pada suatu metode untuk meningkatkan kemudahan pemakaian selama proses desain. Inti utama usability adalah menjawab pertanyaan, apakah produk tersebut sesuai dengan kebutuhan user yang menjadi tolok ukur bagi para pembuat sistem. Hal ini menjadi penting sebab seorang system developer/web developer tidak bisa berdiri sendiri, system developer/web developer tak lebihnya dari penyedia jasa yang wajib sekali memperhatikan betul-betul apa yang dibutuhkan oleh pengguna. Usabilitas didefinisikan melalui 5 komponen kualitas (Nielsen, 1992) yaitu :
1. Learnibility : mengukur semudah apa user dapat mempelajari cara penggunaan produk tersebut untuk pertama kali.
2. Efficiency : mengukur secepat apa user dapat melakukan tugasnya.
3. Memorability : sejauh mana user dapat mengingat langkah-langkah atau proses yang dilakukan dalam mencapai tujuannya
4. Error : sebanyak apa user melakukan error, dan sejauh mana akibat error tersebut, serta apakah mudah bagi user untuk mengatasi error tersebut.
5. Satisfaction : bagaimana perasaan user ketika menggunakan produk atau tanggapan terhadap desain produk secara keseluruhan
Usabilitas menunjukkan kemudahan manusia untuk menggunakan suatu alat atau objek buatan manusia lainnya untuk mencapai tujuan tertentu. International Organization for Standardization (ISO) mendefinisikan usability sebagai tingkat dimana produk bisa digunakan oleh pengguna tertentu untuk mencapai tujuannya dengan lebih efektif, efisien, dan memuaskan dalam ruang lingkup penggunanya.
Konteks penggunaan terdiri dari pengguna, tugas, peralatan (hardware, Software, dan material), dan lingkungan fisik serta sosial yang mempengaruhi usabilitas produk dalam sistem kerja. Dalam ISO 9241-11 (1998) terdapat 3 dimensi yaitu efektifitas, efisiensi dan kepuasan. Dimensi usabilitas menurut ISO 9241-11 ini mempunyai makna sebagai berikut
a. Efektivitas
Efektivitas adalah seberapa besar alat atau produk dapat membantu pengguna
II-27 dalam menyelesaikan tugas-tugasnya.
b. Efisiensi
Efisiensi adalah tingkat efektivitas yang dicapai, yang berkaitan dengan resosumber daya. Sumber daya yang relevan dapat mencakup usaha mental atau fisik, waktu, dan biaya. Misalnya efisiensi manusia bisa diukur sebagai efektifitas dibagi dengan usaha manusia, efisiensi dan efektifitas temporal dibagi waktu, atau efisiensi ekonomi dibagi dengan biaya.
c. Kepuasan
Kepuasan adalah mengukur sejauh mana pengguna bebas dari ketidaknyamanan dan sikap mereka terhadap penggunaan produk. Kepuasan bisa ditentukan dan diukur menurut penilaian subjektif pada skala seperti ketidaknyamanan yang dialami, kesukaan pada produk, kepuasan menggunakan produk, atau penerimaan dari beban kerja ketika melaksanakan tugas yang berbeda, atau sejauh mana tujuan kegunaan tertentu (seperti efisiensi atau learnability) telah dipenuhi. Tindakan-tindakan lain termasuk jumlah komentar positif dan negatif dicatat selama penggunaan. Informasi tambahan dapat diperoleh dari langkah-langkah jangka panjang seperti tingkat absensi, pengamatan overloading atau underloading dari pengguna kognitif atau fisik beban kerja, atau dari masalah laporan kesehatan atau frekuensi dengan mana pengguna meminta pindah ke pekerjaan lain.
2.9.1 Pengukuran Usability
Mengukur usability berarti mengukur efektifitas, efisiensi dan kepuasan user. Untuk itu dapat dilakukan dua cara yaitu :
Mengandalkan asumsi pembuat program / diri sendiri a. Menggunakan usability metric.
Hasil pengukuran usability dapat dimanfaatkan untuk beberapa hal berikut (Albert, 2007) :
Mendapatkan masukan dari data, lebih obyektif daripada pendapat sendiri a. Dapat digunakan untuk membandingkan usability dua produk
b. Dapat mengklasifikasi permasalahan (jika ada)
II-28
c. Membuat prediksi penggunaan produk yang sebenarnya d. Memberikan ilustrasi pada manajemen berdasarkan fakta
Saat ini, terdapat beberapa jenis metrik atau teknik pengukuran usability, yang secara umum dapat dibagi menjadi dua kategori yaitu :
a. Desired quality : merupakan pengamatan berupa ukuran selesai/tidaknya suatu tugas (Yes/no), atau tercapai tidaknya suatu hasil, atau diterima/tidaknya suatu pernyataan (agree/ disagree)
b. Pengukuran kuantitatif : mengukur dalam skala angka tertentu, misalnya X% user dapat menyelesaikan tugasnya kurang dari satu menit
Pengukuran usability dapat dilakukan dengan melakukan tahapan-tahapan sebagaimana penelitian lainnya yaitu :
1. Pemilihan kuisioner : memilih paket kuisioner yang akan digunakan. Setiap paket kuisioner memiliki asumsi dasar tertentu, kerangka pemikiran dan pendekatan yang berbeda-beda.
2. Memilih partisipan : menentukan partisipan yang repersentatif, membagi berdasarkan kelompok seperti umur, jenis kelamin dan lain- lain
3. Menentukan ukuran sampel: menentukan ukuran partisipan yang representatif untuk dijadikan obyek pengumpulan data.
4. Mengolah dan interpretasi data sesuai dengan karakteristik data penelitian.
Pada umumnya, pengukuran usability dilakukan menggunakan serangkaian kuisioner. Pada saat ini terdapat beberapa jenis kuisioner yang dapat digunakan untuk mengukur usability seperti :
1. System Usability Scale (SUS), yang ditawarkan secara komersial dalam bentuk paket.
2. Post-Study System Usability Questionnaire (PSSUQ), merupakan paket kuisioner yang dirilis oleh IBM yang terdiri atas 19 item instrument pengukuran.
3. WAMMI dan SUPR-Q untuk mengukur website
4. Single Ease Question (SEQ) yang terdiri dari satu pertanyaan singkat.
5. USE (Usefulness, Satisfaction, and Ease of use), serta beberapa paket kuisioner lainnya.
II-29
Suatu aplikasi disebut usable jika fungsi-fungsinya dapat dijalankan secara efektif, efisien, dan memuaskan (Nielsen, 1992). Efektivitas berhubungan dengan keberhasilan pengguna mencapai tujuan dalam menggunakan suatu perangkat lunak. Efisiensi berkenaan dengan kelancaran pengguna untuk mencapai tujuan tersebut. Kepuasan berkaitan dengan sikap penerimaan pengguna terhadap perangkat lunak. Pengujian usability dilakukan untuk mengevaluasi apakah sebuah aplikasi sudah sesuai dengan kebutuhan pengguna atau belum.
2.9.2 USE Questionnarie
Salah satu paket kuisioner yang dapat digunakan untuk mengukur usability adalah USE Questionnarie. USE dapat mencakup 3 aspek pengukuran usability menurut ISO 9241 yaitu efisiensi, efektivitas dan kepuasan. ISO 9241 Part 11 menjelaskan bahwa usabilitas menunjuk pada tingkat sebuah produk yang dapat digunakan oleh pengguna tertentu untuk mencapai tujuan spesifik dengan efektif, efisien dan memuaskan dalam sebuah konteks penggunaan.
Beberapa penelitian yang sudah dilakukan menunjukkan bahwa kebanyakan evaluasi produk mengacu pada tiga dimensi tersebut, yaitu usefulness, satisfaction dan ease of use. Meskipun ditemukan juga beberapa dimensi lain, tetapi tiga dimensi tersebut merupakan parameter yang paling mudah diamati dan dibandingkan hasilnya jika harus mengevaluasi lebih dari satu antarmuka produk (Amali, 2014)
Hasil beberapa pengamatan juga menunjukkan adanya korelasi dan saling mempengaruhi antara parameter ease of use dan usefulness. Peningkatan pada parameter ease of use akan diikuti peningkatan pada usefulness, dan sebaliknya.
Kedua parameter tersebut akan berkontribusi besar pada satisfaction. Faktor usefulness biasanya kurang penting jika sistem tersebut bersifat sistem internal dimana penggunaannya bersifat wajib. Untuk sistem internal, faktor yang berkontribusi terhadap parameter ease of use dapat dibagi menjadi 2 yaitu ease of learning dan ease of use (Lund,2001). Bentuk paket kuisioner USE selengkapnya sebagai berikut :
II-30
Tabel 2.9 Paket Kuesioner USE
Kriteria Pernyataan
Usefulness It helps me be more effective.
It helps me be more productive.
It is useful.
It gives me more control over the activities in my life It makes the things I want to accomplish easier to get done.
It saves me time when I use it.
It meets my needs.
It does everything I would expect it to do.
Ease of Use It is easy to use.
It is simple to use.
It is user friendly
It requires the fewest steps possible to accomplish what I want to do with it.
It is flexible.
Using it is effortless.
I can use it without written instructions I don't notice any inconsistencies as I use it.
Both occasional and regular users would like it.
I can recover from mistakes quickly and easily.
I can use it successfully every time.
Ease of Learning I learned to use it quickly
I easily remember how to use it.
It is easy to learn to use it.
I quickly became skillfull with it
II-31
Tabel 2.9 Paket Kuesioner USE (Lanjuttan) Satisfaction I am satisfied with it.
I would recommend it to a friend It is fun to use
It works the way I want it to work It is wonderful.
I feel I need to have it It is pleasant to use.
Kuisioner tersebut dibuat dalam bentuk skor tujuh point dengan model Skala Likert, untuk mengukur tingkat persetujuan user terhadap statement- statemen di atas. Hasil pengukuran kemudian dioleh dengan metoda statistik deskriptif dan dilakukan analisis baik terhadap masing-masing parameter atau terhadap keseluruhan parameter.Saat ini, USE merupakan salah satu paket kuisioner non komersial yang dapat digunakan untuk penelitian usability sistem.
2.10 Usability Engineering Life Cycle (UEL)
Usability Engineeering Life Cycle (UEL) pertama kali diciptakan oleh Bias dan Mayhew tahun 2005. UEL merupakan sarana untuk membangun rencana pengujian usabilitas sebuah produk. Jika seorang dapat mengintegrasikan UEL ke dalam sikus pengembangan produk awal akan sangat memperkuat analisis dan pengujian sebuah produk. Dengan mengikuti UEL maka dapat memberikan hasil maksimal dari usabilitas desain produk, analisis dan pengujian. UEL adalah model siklik yang menggabungkan 3 fase (Bias dan Mayhew, 2005)
1. Fase 1 Requirement Analysis (Analisis Kebutuhan)
Tahap ini seorang developer akan menetapkan karakteristik pengguna.
Selain itu pada tahap ini user akan menentukan kebutuhan sebuah produk.
Dari kebutuhan user, tim developer akan mengetahaui tugas-tugas yang harus dikerjakan untuk membangun produk yang diinginkan user. Pada tahap ini juga akan dilakukan penentuan tujuan dan menentukan pedoman desain studi usabilitas.
II-32
2. Fase 2 Design, Testing dan Development (Desain, Pengujian dan Pengembangan)
Pada tahap ini, developer membuat struktur, pendekatan top-down untuk merancang produk baik antar muka pengguna, dokumentasi atau kombinasi dari ketiganya. Tahap ini merupakan tahap yang paling banyak membutuhkan feedback (umpan balik) dari pelanggan.
3. Fase 3 Installation and Feedback (Instalasi dan Umpan Balik)
Dalam tahap ini seorang developer akan mengumpulkan umpan balik dari user selama dan setelah proses pengembangan. Umpan balik sebaiknya dibagikan kepada anggota tim developer lain supaya mengetahui apakah dibutuhkan perubahan lagi setelah mengetahui umpan balik dari pelanggan
Gambar 2.7 Usability Engineering Life Cycle
Sumber : User Interface Design for Mere Mortals Book 1st Edition
Apabila tim developer menemukan bahwa dbutuhkan perubahan apapun setelah mengetahui umpan balik dari pelanggan maka bisa kembali ke tahap 2
II-33
design, testing dan development. Namun user testing juga dapat mengungkap kekurangan dalam persyaratan analisis yang telah dibuat oleh peneliti. UEL hanyala sebuah panduan yang dapat disesuaikan dengan kebutuhan seorang peneliti karena kebutuha setiap produk berbeda-beda. Tim developer kemungkinan memiliki keterbatasan waktu sehingga tidak memungkinkan untuk melakukan pengujian usabilitas secara menyeluruh. UEL memiliki fleksibilitas yang cukup baik untuk seorang peneliti dapat menentukan sendiri pengujian yang tepat untuk proyek yang dibangun.
2.10.1 Fase 1 Requirement Analysis (Analisis Kebutuhan)
Peneliti dapat mengumpulkan kebutuhan pengguna dengan banyak cara.
Misalnya dengan menggunakan prototipe kertas untuk memberikan representasi cetak kepada pengguna produk yang kira-kira akan dihasilkan. Peneliti bebas menentukan bagaimana cara mengetahui kebutuhan pengguna namun harus memastikan bahwa peneliti mendapatkan informasi prasyarat. Berikut adalah prasyarat yang harus ada di tahap requirement analysis :
a. Profil Pengguna : profil pengguna merupakan deskripsi karakteristik dari calon user produk yang dirancang. Tidak ada standar untuk pembuatan profil pengguna ini. Namun yang terpenting dalam tahap mengenali profil pengguna ialah memahami betul masalah yang dimiliki dan keterbatasan pengguna. Selain itu, profil pengguna hendaknya dituliskan mengenai hubungan profesi pengguna dengan produk yang akan dibuat.
b. Analisis teks kontekstual : mempelajari tugas, alur kerja, lingkungan kerja dan kerangka kerja calon pengguna produk. Konteks ini akan membantu peneliti untuk memahami keperluan seorang pengguna terhadap produk yang dibuat.
c. Penentuan tujuan usabilitas : peneliti perlu menetapkan tujuan kualitatif yang spesifik untuk mencerminkan persyaratan yang diambil peneliti dari profil pengguna. Sebagai contoh, peneliti menginginkan agar pengguna menyelesaikan tugas dalam periode tertentu dan lihat apakah mereka bisa melakukan itu. Jika seorang pengguna memiliki beberapa kendala yang membutuhkan metode yang berbeda untuk menyelesaikan tugas, peneliti harus mengatur ulang tujuan pengguna itu dengan tepat.
II-34
d. Penentuan kemampuan dan kendala : peneliti harus menentukan cakupan dari kemungkinan-kemungkinan untuk mengatasi kebutuhan dari pengguna dengan menentukan keterbatasan kemampuan perangkat yang dimiliki.
e. Pedoman desain : peneliti harus menerapkan desain yang diterima secara umum untuk mendesain antar muka (user interface).
2.10.2 Fase 2 Design (Desain)
Fase ini dibagi menjadi 3 tingkat kerja desain. Setiap level membawa peneliti dari merancang konsep pada fase 1 untuk mengembangkan kinerja produk supaya dapat diuji oleh pengguna.
a. Desain Level 1
Desain level 1 adalah tingkat desain konspetual dimana peneliti akan mendesain fungsi, alur kerja dan aturan. Jika peneliti memiliki banyak waktu, peneliti sebaiknya menggali informasi sebanyak mungkin dari pengguna sebelum memutuskan bagaimana merancang desain konspetual.
Model yang dibangun dari masukan pengguna memiliki kesempatan untuk diterima oleh pengguna selama evaluasi desain pada desain level 3. Berikut adalah 4 tahapan desain level 1 :
1. Perancangan ulang tugas
Tim developer mengatur fungsi dan desain alur kerja berdasarkan tugas dari pengguna sebelum mulai membuat desain. Tahap ini melakukan tahap rekayasa ulang, validasi dan perbaikan terhadap requirement analysis. Dalam rekayasa tugas tidak dibuat desain antar muka.
2. Mockups model konseptual
Peneliti dapat membuat mockups prototipe kertas atau program kecil yang menunjukkan beberapa fungsi tetapi bukanlah seluruh fungsi dari sebuah program.
3. Evaluasi Iterativ
Peneliti melakukan evaluasi berulang pada mockups yang telah dibuat.
Evaluasi dilakukan maksimal 2 putaran untuk setiap iterasi.
II-35 b. Desain Level 2
Tahap ini adalah tahap untuk membuat standar desain layar proyek penelitian. Menciptakan standar desain layar sangat penting karena semua orang dalam tim perlu mengerti bagaimana sebuah proyek akan disatukan nantinya. Perancangan antarmuka prototipe ini dilakukan dengan menggunakan standar desain layar yang jelas. Standar ini diperlukan agar pengguna dapat dengan mudah mengenali dan mengidentifikasi suatu fungsi kontrol hanya dari bentuknya yang standar. Standar ini mengatur kebutuhan khusus tentang tampilan layar dan operasinya. Inti dari standardisasi tampilan layar adalah tipe layar yang reusable pada suatu template yang umum digunakan. Desain standar prototipe mengikuti prinsip desain sebuah amtarmuka. Prinsip desain umum yang digunakan dalam perancangan antarmuka ini adalah prinsip desain yang didasarkan pada Galitz (2007).
a. Scrolling
Desain prototipe ini lebih menekankan pada penggunaan vertical scrolling yang memudahkan pengguna melakukan pergeseran menu pilihan secara vertikal (atas-bawah) untuk menampilkan sejumlah pilihan menu yang tersedia. Hal ini dilakukan karena hampir semua mobile phone memiliki orientasi layar vertikal dengan ukuran sisi layar vertikal lebih panjang dibandingkan sisi horizontalnya (Ballard 2007). Minimalisasi scrolling ini dilakukan untuk meningkatkan experience dan memudahkan penerimaan informasi oleh pengguna.
b. Tipografi
Dalam merancang suatu antarmuka, Galitz (2007) menyarankan untuk tidak menggunakan lebih dari dua typeface dengan salah satu typeface mendominasi. Ukuran huruf dibuat dan dibakukan agar tidak berubah-ubah sehingga tidak mengganggu (Galitz, 2007). Pada prototipe ini hanya digunakan satu jenis typeface yaitu default typeface dengan jenis typeface yang digunakan pada sistem emngikuti jenis typeface komputer yang digunakan. Hal ini dilakukan agar
II-36
pengguna lebih mudah mengenali sistem dengan jenis typeface yang sudah familiar olehnya.
c. Screen Elements
1. Control Caption/Data Field Justification
Data fields yang digunakan dapat berupa line box untuk menampilkan dan modifikasi data. Cara penulisan data field yang benar adalah sebagai berikut (Maulana, 2009) :
- Rata kiri untuk caption dan data field dan terdapat satu spasi antara caption terpajang dan kolom data field
Gambar 2.8 Aturan Pertama Caption dan Data Field Justification
- Rata kanan untuk caption dan rata kiri untuk data field serta terdapat satu spasi di tiap-tiap caption dan kolom data field
Gambar 2.9 Aturan Kedua Caption dan Data Field Justification 2. Headings
Headings digunakan untuk membagi blok teks yang besar.
Headings memberikan gambaran dari isi suatu halaman apllikasi dengan jelas. Tiga jenis headings adalah sebagai berikut
- Control sections headings
Heading diletakkan di atas control caption dan dipisahkan dengan satu spasi baris
Gambar 2.10 Control sections headings
II-37
- Control subsection / Row headings
Heading menggunakan simbol yang unik, seperti panah dan diletakkan di samping kiri control caption dan dipisahkan dengan tiga spasi
Gambar 2.11 Control Subsection / Row Headings
- Field group headings
Heading diletakkan di tengah control caption yang dikelilingi dengan garis
Gambar 2.12 Field Group Headings c. Warna
Menurut Nielsen dan Loranger (2006) untuk memperjelas teks yang dimunculkan, warna teks haruslah kontras dengan warna latar yaitu teks berwarna gelap dengan latar terang (positive tet) atau teks berwarna terang dengan latar belakang gelap (negative text). Pada perancangan antarmuka ini akan digunakan positive text dan beberapa kombinasi warna lainya di beberapa menu namun masih dalam warna yang sama.
Warna memiliki tujuan tertentu. Warna foreground harus berbeda dengan warna background. Foreground menggunakan warna hitam untuk teks sedangkan background menggunakan warna yang kontras dengan foreground seperti putih atau abu-abu muda. Warna yang ditampilkan dibuat minimal karena dengan menggunakan banyak warna, pengguna sulit untuk memperhatikan sesuatu yang mungkin
II-38
paling penting. Pemilihan warna foreground dan background yang sesuai dapat dilihat pada berikut ini.
Gambar 2.13 Kombinasi Warna
d. Desain level 3
Pada level ini tim developer benar-benar mendesain produk setelah pembuatan semua persiapan dalam dua level sebelumnya. Level ini terdiri dari 2 tahap yaitu :
1. Detail desain antarmuka
Peneliti mendesain antarmuka berdasarkan syarat-syarat yang ada di level 1 dan level 2. Produk yang dihasilkan adalah versi beta yang tersedia untuk diuji dan diberi umpan balik oleh pelanggan. Versi beta adalah aplikasi atau Software itu adalah dimana suatu aplikasi atau Software tersebut masih dalam masa percobaan atau dalam masa uji coba.
II-39 2. Evaluasi Desain antarmuka
Tim proyek melakukan evaluasi keseluruhan desain antarmuka. Proses ini berlanjut sampai tim proyek memvalidasi produk terhadap tujuan kegunaan.
2.7.3 Fase 3 Installation and Feedback
Setelah produk telah dipasang dan digunakan untuk jangka waktu tertentu, tim developer harus mengumpulkan umpan balik dari pengguna tentang apa yang mereka sukai dan tidak suka tentang produk dan bagaimana mereka menggunakannya. Tim developer dapat memperoleh umpan balik dalam berbagai cara: melalui e-mail, telepon, surat, atau pada situs Web Anda. Anda dapat mengirim survei ke pelanggan, dan Anda mungkin ingin menawarkan hadiah atau penawaran khusus untuk menarik pelanggan untuk mengembalikan survei, terutama jika survei panjang. Anda juga mungkin ingin melakukan grup fokus baik secara langsung di gedung perusahaan Anda atau di klien, atau daring menggunakan kolaboratif perangkat lunak yang menggunakan videoconferencing real time seperti WebEx, Microsoft LiveMeeting, atau Raindance. Dalam penelitian ini umpan balik didapatkan dari USE Questionnere
