1 BAB 2 TINJAUAN PUSTAKA 2.1 Teori Dasar Umum Berikut merupakan teori-teori dasar umum yang digunakan di dalam penulisan skripsi ini: Unified Modeling...
2.1 Teori Dasar Umum Berikut merupakan teori-teori dasar umum yang digunakan di dalam penulisan skripsi ini: 2.1.1 Unified Modeling Language (UML) Berdasarkan Whitten dan Bentley (2007:371), Unified Modeling Language
adalah
sekumpulan
aturan
yang
digunakan
untuk
menspesifikasikan atau mendeskripsikan sebuah sistem perangkat lunak berdasarkan obyek. Pertama kali dirilis pada tahun 1997 dengan versi 1.0, saat ini UML memiliki versi 2.0 sebagai versi terbarunya. Menurut Whitten dan Bentley (2007:381), UML versi 2.0 dapat dibagi menjadi 3 fase, yaitu:
Tabel 2.1 Jenis Diagram pada UML versi 2.0 Requirement
Logical Design
Physical Design
Analysis Phase
Phase
Phase
Use-case Diagram
Activity Diagram
Sequence Diagram
Sistem Sequence
Class Diagram
Diagram Class Diagram
State Machine Diagram Communication Diagram Component Diagram Deployment Diagram
8
9
2.1.1.1 Use Case Diagram Use Case Diagram adalah diagram UMLyang berguna untuk memberikan penjelasan mengenai fungsi suatu sistem yang sedang dikembangkan kepada user menggunakan istilahistilah yang mudah dimengerti (bukan merupakan istilah yang hanya dimengerti oleh developer). Use Case Diagram memberikan representasi grafis mengenai urutan aktivitas berupa interaksi yang terjadi antara user (didalam Use Case Diagram disebut dengan Actor) dan sistemserta tujuan dari penggunaan sistemtersebut. Di dalam Use Case Diagram, fungsi-fungsi dari sistem dideskripsikan menggunakan alat bernama use case. Actor adalah user yang melakukan interaksi dengan sistem, sedangkan jenis-jenis interaksi yang dilakukan oleh Actor terhadap use case disebut relationship.(Whitten and Bentley, 2007:247-248). Terdapat beberapa macam hubungan yang digunakan di dalam Use Case Diagram (Whitten and Bentley, 2007:248-256), yaitu: 1.
Association Association menggambarkan hubungan antara Actor dan sebuah use case. Association yang memiliki tanda panah mengarah pada sebuah use case menunjukkan bahwa interaksi dinisiasikan oleh actor. Association yang tidak memiliki tanda panah menunjukkan adanya interaksi antara use case dengan external server atau actor penerima. Association dapat bersifat dua arah atau satu arah.
10
Gambar 2.1 Contoh penggunaan Association pada use case (Sumber: System Analysis and Design Method - Whitten and Bentley, 2007: 248)
2.
Extends Extends menggambarkan use case yang bersifat kompleks agar menjadi lebih sederhana dan mudah dimengerti dengan membaginya ke dalam tahap-tahap.
Gambar 2.2 Contoh penggunaan Extends pada use case (Sumber: System Analysis and Design Method - Whitten and Bentley, 2007: 249)
3.
Uses (atau includes) Uses (atau includes) menciptakan abstract use case, yaitu bentuk generalisasi dari beberapa tahap use case yang memiliki kemiripan. Abstract use case dibuat agar mengurangi redundansi pada use case diagram, dan dapat digunakan satu atau lebih use case yang membutuhkan fungsionalitasnya.
11
Gambar 2.3 Contoh Penggunaan include pada Use Case (Sumber: System Analysis and Design Method – Whitten and Bentley, 2007: 249)
4.
Depends On Depends On menggambarkan adanya ketergantungan antara satu use case dengan use case lainnya sehingga sebuah aktivitas hanya bisa dilakukan apabila aktivitas sebelumnya sudah berjalan.
Gambar 2.4 Contoh penggunaan Depends On pada Use Case (Sumber: System Analysis and Design Method - Whitten and Bentley, 2007: 250)
12
5.
Inheritance Inheritance digunakan ketika terdapat dua atau lebih actor yang melakukan inisiasi terhadap use case yang sama. Dengan inheritance, diciptakan sebuah abstract actor yang dapat melakukan use case tersebut (bentuk generalisasi dari actor-actor yang ada).
Gambar 2.5 Contoh penggunaan Inheritance pada Use Case (Sumber: System Analysis and Design Method - Whitten and Bentley, 2007: 250)
Gambar 2.6 Contoh Use Case Diagram (Sumber: System Analysis and Design Method - Whitten and Bentley, 2007: 256)
13
2.1.1.2 Use Case Narrative Menurut
Whitten
dan
Bentley
(2007:246 (2007 246),
UseCaseNarrativemerupakan deskripsi dalam bentuk teks dari UseCaseNarrativemerupakan dan bagaimana userakan akan berinteraksi dengan sistem dalam menyelesaikan sebuah tugas. Ketika sedang mempersiapkan untuk membuat usecase agar lebih mudah dalam memahami events dari sistem
Gambar 2.7 2. Contoh Use Case Narrative (Sumber: System Analysis and Design Method Met - Whitten and Bentley, 2007: 257)
Bagian--bagian dari High-level Use Case Narrative adalah sebagai berikut: 1.
Authoradalah adalah nama nama-nama individu yang berkontribusi didalam dalam penulisan use case.
2.
Dateadalah adalah tanggal use case terakhir kali dimodifikasi.
3.
Versionadalah Version versi dari use case.
4.
Use-case case name adalah nama yang merepresentasikan tujuan dari use case tersebut, harus dimulai dengan kata kerja.
14
5.
Use-case typeadalah jenis use case yang digunakan. Business requirement use-case memiliki fokus pada visi strategis dan tujuan dari banyak stakeholders. Jenis use case ini
memberikan
deskripsi
penjelasan
secara
umum
mengenai masalah dan cakupannya, tetapi tidak termasuk rincian yang harus dikomunikasikan kepada developer mengenai apa yang harus dilakukan oleh sistem. 6.
Use-case IDadalah pengidentifikasi unik dari sebuah use caseyang tujuannya untuk pengelompokkan usecase.
7.
Priorityadalah tingkat prioritas dari sebuah use case yang menunjukkan pentingnya fungsi use case tersebut di dalam sistem.
8.
Sourceadalah yang mendefinisikan entitas yang memicu pembuatan use case. Dapat berupa kebutuhan, dokumen, atau stakeholder.
9.
Primary business actoradalah stakeholder yang secara utama diuntungkan oleh eksekusi use case dengan menerima suatu nilai yang terukur.
10. Other participating actorsadalah actor lain di dalam use case yang berpartisipasi dan membantu terwujudnya tujuan dari use case yang ada. 11. Interested stakeholder(s)adalah seseorang selain actor yang memiliki ketertarikan pada tujuan dari use case. 12. Descriptionadalah deskripsi singkat yang terdiri dari beberapa kalimat yang menjelaskan tujuan dari use case dan aktivitas-aktivitasnya.
15
Gambar 2.8 2. Contoh Use Case Narrative (Sumber: System Analysis and Design Method Met - Whitten and Bentley, 2007: 259-260)
16
Setiap high-level use case dilakukan expand untuk mencakupi rincian event-event yang typical dan alternate. Typical course of events adalah deskripsi langkah demi langkah pelaksanaan use case, sedangkan alternate course of events berisi beragam kondisi yang terjadi di dalam use case. Berikut adalah konten tambahan dari sebuah ekspansi highlevel use case: 1.
Preconditionadalah batasan dari kondisi/status sistem sebelum use case dapat dieksekusi.
2.
Triggeradalah event yang menyebabkan eksekusi sebuah use case.
3.
Typical courseof eventsadalah urutan biasa dari aktivitas yang dilakukan aktor dan sistem untuk mencapai tujuan dari use case.
4.
Alternate coursesadalah apabila terdapat pengecualian atau variasi dari typical course yang terjadi.
5.
Conclusionadalah spesifikasi saat use case berhasil dieksekusi, saat primary actor menerima suatu nilai yang terukur.
6.
Postconditionadalah batasan dari kondisi/status sebuah sistem setelah use case berhasil dieksekusi.
7.
Business rulesmenspesifikasikan aturan dan prosedur bisnis di dalam sistem yang baru.
8. Implementationconstraintsandspecificationsmenspesi fikasikan kebutuhan yang bersifat nonfungsional yang dapat mempengaruhi realisasi use case, dapat berguna dalam perencanaan arsitektur dan pencakupan.
17
9.
Assumptionsadalah semua asumsi yang dibuat oleh creator saat mendokumentasikan use case.
10.
Open issuesadalah
pertanyaan
atau
masalah
yang
harusdiselesaikan atau diteliti sebelum use case disetujui. 2.1.1.3 Activity Diagram Activity Diagram digunakan untuk menggambarkan alur urutan yang ada pada sebuah sistem dan menjelaskan alur dari sebuah use case.Terdapat beberapa elemen di dalam sebuah activity diagram, yaitu:
Tabel 2.1 Tabel Elemen Activity Diagram (Sumber: System Analysis and Design Method - Whitten and Bentley, 2007: 391) Nama Initial Mode
Simbol
Deskripsi Lingkaran
hitam
yang
merepresentasikan awal sebuah proses. Simbol yang merepresentasikan
Activity
langkah-langkah
individual
di
dalam activity diagram. Simbol berupa tanda panah yang Flow
menunjukkan alur perpindahan dari satu aktivitas ke aktivitas lainya. Simbol yang sama digunakan untuk dua fungsi kondisional yang
Decision dan Merge
berbeda,
Decision
dan
Merge.Decisionmengindikasikan percabangan
karena
adanya
pemilihan aktivitas dengan alur berbeda.Merge
mengindikasikan
adanya penggabungan aktivitas
18
untuk kembali ke jalur yang sama setelahsebelumnya
dipisahkan
oleh sebuah decision. Nama
Deskripsi
Simbol
Simbol
yang
diasosiasikan paralel
sama dengan
(dua
arah). dua
dapat proses Fork
Fork dan
menggambarkan
aktivitas
Join
yang akan berjalan secara paralel. Join menggambarkan berakhirnya proses
yang
berjalan
secara
paralel (dua arah) Activity Final
Simbol ini menunjukkanakhir dari proses diagram.
pada
sebuah
activity
19
Gambar 2.9 Contoh Activity Diagram (Sumber: System Analysis and Design Method - Whitten and Bentley, 2007: 392)
20
2.1.1.4 Class Diagram Menurut Whitten dan Bentley (2007:373-381), Class Diagram digunakan untuk menggambarkan pengorganisasian obyek-obyek bisnis dan asosiasinya terhadap satu sama lain pada sebuah sistem. Dalam hal ini, obyek bisnis disebut sebagai class.Di dalam class diagram, class – class yang ada dapat dihubungkan satu sama lain menggunakan garis lurus. Di dalam sebuah class, terdapat elemen berupa nama, attribute, dan operation. Berikut adalah beberapa jenis hubungan di dalam class diagram menurut Whitten dan Bentley (2007:373-381): 1.
Multiplicity Multiplicity
adalah
indikator
yang
menunjukkan
banyaknya hubungan antar class.
Tabel 2.2Jenis-Jenis Multiplicity
2.
Multiplicity
Deskripsi
1
Hanya satu.
0..1
Nol atau satu
*
Nol atau lebih.
1..*
Satu atau lebih.
x..y
Antara jumlah x dan jumlah y
Association Association adalah hubungan antara dua class atau lebih di dalam sebuah class diagram. Pada setiap association terdapat multiplicity. Terdapat dua jenis hubungan association di dalam class diagram, yaitu:
21
a.
Bi-directional Adanya hubungan antar class dimana kedua class sama-sama memiliki peran terhadap satu sama lain. Hubungan bi-directional digambarkan dengan garis lurus tanpa tanda panah yang menghubungkan kedua class.
b. Uni-directional Adanya hubungan antar class dimana hanya salah satu class memiliki peran dalam hubungan tersebut. Hubungan uni-directional digambarkan dengan garis lurus yang memiliki tanda panah di salah satu ujungnya.
Gambar 2.10 Contoh Association Bi-Directional dan Uni-Directional Class Diagram
3.
Generalization dan Specialization Generalization dan Specialization adalah hubungan antar class dimana terdapat super class, yaitu sebuah class yang
merupakan
berdasarkanattribute
hasil dan
pengelompokan behavior
class-class
yang
sama
(generalization), dan sub class, yaitu class-class yang mendapatkan attribute dan behavior turunan dari sebuah super classnamun dapat memiliki attribute dan behaviornya sendiri (specialization).
22
Gambar 2.11 Contoh Generalization/Specialization /Specialization Class Diagram (Sumber: System Analysis and Design Method – Whitten dan Bentley, 2007: 375)
4.
Aggregation dan Composition Aggregation dan Composition adalah hubungan antar class dimana sebuah class merupakan bagian dari class lainnya.
Gambar 2.12 Contoh Aggregation Class Diagram (Sumber: System Analysis and Design Method – Whitten and Bentley, 2007: 379) Perbedaan antara composition dan aggregation adalah pada composition terdapat hubungan yang lebih erat antar class. Misalnya, jika class A adalah bagian dari class
23
B,maka maka class B tidak akan bisa berdiri sendiri tanpa class A. Pada UML 2.0 notasi aggregation tidak lagi digunakan karena fungsinya kurang terlihat perbedaannya dengan bentuk association dengan multiplicity satu atau lebih ((one or more). more
Hal ini menyebabkann
beberapa praktisi
menganggap aggregation tidak memiliki arti penting pada penggunaannya. penggunaannya
Gambar 2.13 2. Contoh Composition Class Diagram (Sumber System Analysis and Design Method - Whitten (Sumber: Whittenand Bentley, 2007: 379)
Gambar 2.14 Contoh Class Diagram (Sumber System Analysis and Design Method – Whitten (Sumber: and Bentley, 2007: 406)
24
2.1.1.5 Sequence Diagram Sequence
diagram
menggambarkan
adalah
interaksi antara
sistemberdasarkan
urutan
waktu
diagram
UML
obyek-obyek (Whitten
yang
di dalam
and
Bentley,
2007:659). Berikut ini adalah elemen-elemen dari sequence diagram:
Tabel 2.4Elemen Sequence Diagram Nama
Simbol
Deskripsi Actor adalah representasi user yang
Actor
berinteraksi
dengan
sistem.
Suatu notasi yang berfungsi Interface Class
untuk <>
memastikan
classinterface code, agar tidak terjadi kebingungan atas jenis class. Setiap use case memiliki satu
Controller Class
<>
atau
lebih
digambarkan
controller, sama
seperti
notasi interface class. Entity
Simbol yangmerepresentasikan
Classes
class pada class diagram. Berfungsi
Message
menyampaikan setiap method.
untuk pesan
dari
25
Nama
Activity Bars
Simbol
Deskripsi
Berfungsi untuk menunjukan berapa lamanya waktu objek digunakan.
Return
Hasil
Message
dimasukan oleh objek.
Self-call
dari
Objek
masukan
yang
memanggil
method-nya sendiri. Menandakan
Frame
yang
diagram seleksi,
yang
area
pada
melakukan
pengulangan,
suatu pilihan khusus.
dan
26
Gambar 2.15 Contoh Sequence Diagram (Sumber: System Analysis and Design Method - Whitten and Bentley, 2007: 659)
2.1.2
Interaksi Manusia dan Komputer Berikut ini merupakan penjelasan teori Interaksi Manusia dan Komputer:
2.1.2.1 Pengertian Interaksi Manusia dan Komputer Menurut Shneiderman dan Plaisant(2010: 22), interaksi manusia dan komputer merupakan suatu ilmu yang mempelajari desain interaktif antara manusia dengan komputer. Dan membantu menghasilkan bisnis yang sukses, kompetisi yang kuat, kerjasama internasional, dan perang intellectual-property.
27
2.1.2.2 Lima Faktor Manusia Terukur Shneiderman dan Plaisant (2010:32) juga menyatakan untuk memperhatikan lima faktor manusia terukur yang berisi sebagai berikut: 1.
Waktu belajar Berapa lama waktu yang akan diperlukan user untuk mempelajari semua aksi yang diperlukan,sehingga dapat mencapai tujuannya dalam menggunakan aplikasi.
2.
Kecepatan kinerja Berapa lama waktu yang diperlukanuser hingga aplikasiselesai dalam melakukan tugas.
3.
Tingkat kesalahan user Berapa banyak jumlah dan jenis kesalahan yang kemungkinan akan dilakukan oleh user saat berinteraksi dengan aplikasi.
4.
Daya ingat Bagaimana
kemampuan
usermempertahankan
pengetahuannya dalam jangka waktu tertentu. 5.
Kepuasan subjektif Bagaimana
tingkat
ketertarikanuser
terhadap
penggunaanaspek-aspek pada interface. 2.1.2.3 Delapan Aturan Emas Shneiderman dan Plaisant (2010:88-89) dalam perancangan desain antar muka terdapat delapan aturan emas (Eight Golden Rules) yang harus diperhatikan, yaitu: 1.
Berusaha konsisten Konsistensi
sangat
dibutuhkan,
seperti
pada
penggunaan warna, tata letak,font,hingga urutan tindakan. Prinsip ini paling banyak dilanggar karena banyaknya bentuk konsistensi dalam perancangan.
28
2.
Dapat digunakanuniversal Pengetahuan mengenai kebutuhan user yang beragam, sehingga rancangan interface yang dibuat bisa memfasilitasi perubahan konten sesuai kebutuhan user. Perbedaan tingkatan userseperti pemula atau ahli, tua atau muda, anak kecil atau orang dewasa membuat requirement yang dibutuhkan semakin bertambah. Contohnyaseperti pada user pemula ditambahkan penjelasan atau panduan pada interface, pada user ahli ditambahkan shortcut yang membuat user dapat mempersingkat aksi.
3.
Memberi umpan balik (feedback)yang informatif Setiap
aksi
yang
dilakukan
userharus
diberi
feedbackyang mudah dimengerti dari sistem mengenai apa yang terjadi dari aksi yang telah dilakukan. 4.
Merancang dialog untuk penutup/akhir Urutan aksi harus dikelompokkan menjadi bagian awal, tengah dan akhir. Dialog penutupyang informatif pada hasil akhir akan membuat user merasa puas dan lega dari aksi yang telah dilakukannya sehingga dapat juga menjadi tanda untuk mempersiapkan tugas selanjutnya.
5.
Memberikan
penanganan
dan
pencegahan
yang
sederhana terhadap error Desain sistem yang dibuat tidak memperbolehkan user melakukan kesalahan. Contohnya, user harus memasukkan alamat e-mail yang sesuai dengan formate-mail yang ada pada umumnya. Jika terjadi kesalahan, sistem harus dapat mendeteksi
dan
memberikan
instruksi
yang
mudah
dimengerti, konstruktif dan spesifik. 6.
Memperbolehkan pengembalian aksi Setiap aksi yang telah dilakukanuser harus dapat dikembalikan atau dikembalikan ke keadaan semula. Hal ini dapat mengurangi rasa khawatir userdengan mengetahui
29
situasi error dapat dikembalikan pada sistuasi sebelum terjadi error. 7.
Mendukung pengendalian internal locus Pada dasarnya usermerupakan pengendali sistem dan sistem merespons terhadap aksi yang dilakukan user. Rancangan sistem harus memposisikan user sebagai inisiator bukan sebagai responden.
tampilan harus dibuat sederhana. Cara mengatasinya seperti membuat interface yang lebih sederhana dan meminimalisir frekuensi pergerakan tampilan. Lalumemberikan pelatihan yang cukup untuk kode, mnemonik serta urutan aksi. 2.1.3
Prinsip Rancangan InterfaceAplikasi Mobile Seringkali smartphone dan desktop computer disamakan sebagai computing devices, tetapi faktanya keduanya sangat berbeda baik dari segi layar masing – masing perangkat, menggunakan baterai atau menggunakan kabel untuk sumber listrik, hingga tinggi atau rendahnya bandwidth. Oleh karena itu perbedaan antara smartphone dan desktop computer membuat perancangan interface keduanya tidak dapat disamakan. Sepuluh prinsip perancangan interface untuk aplikasi mobile yang dikemukakan oleh Jonathan Stark pada setiap workshop-nya (netmagazine.com, 2012) sebagai berikut: 1.
Mobile Mindset Dengan perbedaan – perbedaan antara smartphone dan desktop computer, adabaiknya untuk mengubah pola pikir menjadi pola pikir mobile sebelum memulai merancang. a.
Be focused: Banyak tidak selalu lebih baik. Ada baiknya mengurangi fitur – fitur yang tidak diperlukan atau tidak berhubungan dengan tujuan aplikasi.
30
b. Be unique: Akan terdapat banyak sekali aplikasi sejenis yang telah ada ataupun yang akan muncul maka harus terdapat keunikan pada aplikasi sehingga user memiliki alasan untuk memilih aplikasi tersebut. c.
Be charming: Mobile devicespada dasarnya bersifat pribadi. Untuk itu membuat aplikasi yang mudah untuk digunakan, memberikan kesan yang menyenangkan dan nyaman ketika menggunakan aplikasi tesebut sangatlah penting.
d. Be
considerate:
Para
developer
aplikasi
jarang
sekali
memikirkan mengenai apa yang akan menyenangkan untuk dikembangkan
sehingga
pemikiran
yang
tercipta
ketika
mengembangkan aplikasi hanya tentang tujuan bisnis pribadi. Tempatkan diri pada posisi user sehingga menciptakan pengalaman yang menarik pada aplikasi. 2.
Mobile Context Sebelum memposisikan diri sebagai user, penting untuk mengetahui tiga konteks utama tujuan user menggunakan aplikasi. Tiga konteks tersebut, yaitu: a.
Bored:
Banyak
orang
menggunakan
smartphone
untuk
menghabiskan waktu luangnya untuk itu dalam konteks ini dibutuhkan aplikasi yang dapat mengisi waktu luang tersebut. Contohnya: games dan social-networking. b. Busy: Kemampuan untuk menjalankan tugas – tugas sederhana dengan cepat dan memungkinkan digunakan dengan satu tangan akan membuat user dalam konteks ini memilih menggunakan aplikasi tersebut karena bisa digunakan di tengah kesibukannya. Contohnya: kalender, kalkulator, banking. c.
Lost: User yang berada pada konteks ini merupakan useryang sering bepergian ke tempat menarik yang belum pernah didatangi sebelumnya. Untuk itu konektivitas dan daya tahan baterai menjadi hal yang sangat diperhatikan. Contohnya: Maps dan Foursquare.
31
3.
Global Guidelines Terdapat perbedaan pada pendekatan, desain dan teknik dari masing – masing aplikasi. Untuk itu terdapat ketentuan umum yang harus diperhatikan ketika merancang aplikasi: a.
Responsiveness:Kecepatanaplikasi
dengan
tingkat
respons
aplikasi itu berbeda, contoh dari aplikasi yang responsif ketika user berinteraksi pada aplikasi, aplikasi dapat segera memberi feedback kepada user tersebut. Jika terdapat operasi yang memakan waktu, hal tersebut tidak menjadi masalah dengan memberitahu user apa yang sedang dilakukan. b. Polish: Polesan yang diberikan pada aplikasi sangatlah berharga. Memperhatikan hingga detail – detail yang kecil akan disadari dan sangat dihargai oleh user. c.
Thumbs: Dalam merancang aplikasi harus diperhatikan juga kenyamanan user berinteraksi menggunakan jempolnya, bahkan ketika memakai kedua tangan kebanyakan orang lebih suka menggunakan jempolnya untuk melakukan interaksi pada aplikasi.
d. Targets: Desain tombol perlu diperhatikan seperti besar jempol dengan User Interface Elements, yang umumnya berukuran 44 pixels. Dan penting untuk memperhatikan penempatan fungsi – fungsi pada aplikasi, misalnya meletakkan tombol backspace bersebelahan
dengan
tombol
send
pada
aplikasiShortMessageService(SMS). e.
Content: Meminimalisir penggunaan elemen interface seperti buttons, tab, bars, checkboxes, sliders dan masih banyak lagi. Dengan
meminimalisir
penggunaan
elemen
tersebut
memungkinkan user lebih fokus konten aplikasi. f.
Controls: Saat aplikasi membutuhkan kontrol letakkan di bawah dari konten utama, sehingga user tidak terganggu ketika sedang memperhatikan konten. Contoh yang paling sering ditemui adalah komputer yang letak kontrolnya di bawah dari letak display.
32
g.
Scrolling: Hindari scrolling. Karena dengan tidak memakai scrolling pada layar aplikasi akan terlihat lebih solid dan tingkat penelusuran user terhadap keseluruhan screenakan lebih tinggi sehingga user mendapatkan informasi secara menyeluruh. Sehingga, mencegah user kehilangan informasi pada screen yang memakai scrolling.
4.
Navigation Models Terdapat beberapa model navigasi untuk aplikasi mobile, yaitu: a.
None: Merupakan aplikasi single-screen seperti aplikasi cuaca pada Android.
b. Tab bar: Memiliki tiga sampai enam bar pada bagian atas aplikasi. Contohnya seperti aplikasi mobile Twitter. c.
Drill down: Aplikasi terbentuk menyerupai sebuah daftar. Contohnya settings pada Android.
5.
UserInput Buatlah user lebih mudah dan nyaman dalam melakukan input. Ada banyak variasi keyboard yang terkenal pada smartphone, pilihlah jenis keyboard yang nantinya akan berguna pada saat user melakukan input. Hindari penggunaan auto-correct dan autocapitalisation karena terkadang hal tersebut membuat user merasa terganggu. Jika pada aplikasi meminta user banyak melakukan pengetikan, pastikan aplikasi tersebut mendukung landscape sehingga memudahkan dalam mengetik input yang diminta.
33
6.
Gestures Salah satu yang terpenting dalam perancangan interface layar sentuh adalah gestures. Beberapa gesture yang umumnya digunakan, yaitu: a.
Invisible: Ada banyak gesture yang dapat dilakukan, seperti flick dan swipe. Untuk mengeksekusi gesture perlu adanya informasi terhadap user, sehingga user tidak mengalami kebingungan saat menjalankan aplikasi.
b. Twohands:Smartphone
sekarang
ini
memungkinkan
usermelakukan multi-touch. Gesture ini seringkali digunakan untuk aplikasi yang membutuhkan zoom in/out, seperti pada aplikasi image viewer. 7.
Orientation Layar yang berorientasi portrait sejauh ini merupakan orientasi terpopuler, Tetapi jika terdapat banyak pengetikan pada aplikasi sudah seharusnya aplikasi dapat memberi support orientasi layar landscape. Ketika orientasi layar berubah secara tidak diduga itu hal yang wajar, Tetapi ketika aplikasi tersebut digunakan dalam waktu yang lama seperti e-book reader tambahkan pengunci orientasi layar agar tidak berubah-ubah ketika sedang digunakan.
8.
Communications Komunikasi antara aplikasi dan user sangat diperlukan ketika membuat sebuah aplikasi. Untuk itu ada beberapa jenis komunikasi yang dapat diterapkan pada aplikasi: a.
Provide feedback: Memberikan feedback instan ketika user melakukan
interaksi
pada
aplikasi.
Jika
aplikasi
tidak
memberikan feedback, user dapat mengira bahwa aplikasi tidak berjalan dengan baik. Feedback tersebut bisa saja berupa respon terhadap indera peraba user seperti getaran ketika memilih sebuah icon atau dalam bentuk visual seperti icon berubah warna (hover) ketika user memilih icon tersebut. Jika aksi user memiliki waktu yang panjang untuk dikerjakan oleh aplikasi,
34
beritahu bahwa aplikasi sedang mengerjakannya contohnya dengan memberi spinner atau loading pada aplikasi. b. Modal
alerts:
Pada
dasarnya
modalalerts akan
sangat
mengganggu user ketika sedang menggunakan aplikasi, untuk itu gunakan modalalerts hanya pada saat terjadi sesuatu yang penting seperti terdapat error atau crash pada aplikasi. Ingat untuk tidak menggunakan modal alerts hanya untuk memberi informasi – informasi sederhana. c.
Confirmations: Ketika user akan melakukan aksi yang penting dalam aplikasi, sebaiknya berikan konfirmasi kepada user apakah akan melanjutkan aksi tersebut atau tidak. Contohnya ketika user akan melakukan aksi delete pada aplikasi sebaiknya ditanyakan apakah user yakin untuk melakukan aksi tersebut atau tidak, sehingga mencegah user melakukan kesalahan.
9.
Launching Ketika user kembali ke aplikasi setelah digunakan sebelumnya, sebaiknya user dapat melanjutkan operasi seperti saat sebelum user meninggalkannya. Sehingga akan memberikan kesan lebih cepat dan responsif. Jika memungkinkan, ketika aplikasi dibuka tampilan awal usahakan bukan tampilan yang berisi konten – konten utama dari aplikasi bisa berupa gambar saja. Jika tidak, akan memberi kesan bahwa interface dapat berinteraksi tetapi tidak dapat memberi reaksi yang sebenarnya dikarenakan aplikasi sedang dalam tahap loading.
10. First Impression Kesan pertama yang diberikan oleh aplikasi juga salah satu hal penting yang perlu diperhatikan. Hal yang paling pertama sekali dilihat oleh user adalah icon dari aplikasi itu sendiri. Dengan menggunakan
teks
sedikit
mungkin
dan
menggunakan
penggambaran yang sesuai dengan aplikasi sehingga dengan icon yang menarik membuat user berpikir bahwa aplikasi tersebut juga menarik. Selain itu juga userinterface yang mudah untuk dimengerti dan ditelusuri oleh user juga penting, karena ketika pertama kali
35
usermemakai aplikasi ternyata membingungkan dan membuat frustasi maka user tidak akan berpikir untuk memakainya kembali. 2.1.4
Agile Software Development Agile
Software
Development
adalah
suatu
metodologi
pengembangan aplikasi yang sangat mementingkan kepuasan customer, selalu memberikan perkembangan aplikasi secara bertahap kepada customer, dan selalu menjalin komunikasi yang berlanjutan antara developer dan customer untuk menghasilkan aplikasi yang sesuai dengan keinginan (Pressman, 2010:66). 2.1.4.1 Feature Driven Development (FDD) Menurut
Pressman
(2010:86-87),
Feature
Driven
Development (FDD) pertama kali disusun oleh Peter Coad dan rekannya sebagai proses model yang object-oriented. Lalu kemudian dikembangkan oleh Stephen Palmer dan John Felsing sebagai proses model yang adaptif dan agile. Cocok untuk diterapkan padaproject yang berskala besar. Feature Driven Development (FDD) merupakan proses model yang dirancang dalam serangkaian fitur dan setiap fitur dapat diselesaikan dalam waktu kurang dari 2 (dua) minggu. Oleh karena itu, maka akan mempermudah dalam menjelaskan alur aplikasi berdasarkan fitur dan lebih mudah dalam melakukan progress tracking. Coad dan rekannya menyarankan untuk menggunakan template di bawah ini dalam merancang suatu fitur, yaitu: the [a(n)]
