7
LANDASAN TEORI
2.1 Natural User Interface
Natural User Interface (NUI) adalah salah satu cara yang lebih alami untuk berinteraksi dengan teknologi. NUI mengacu pada input sensorik seperti sentuhan, suara dan gerakan yang lebih mendalam (Kaushik & Jain, 2014:141).
Menurut Widgor dan Wixon (2011:9), natural mempunyai maksud untuk meniru dunia nyata. Elemen natural pada natural user interface tidak mengacu pada desain antar muka. Natural merujuk pada cara-cara user atau pengguna produk berinteraksi dengan produk yang dipakainya serta dapat merasakan apa yang mereka lakukan dan gunakan.
2.2 Multimedia
Multimedia adalah kombinasi antara teks, grafik, audio, animasi dan video yang dibawakan kepada pengguna menggunakan komputer atau dimanipulasi secara digital oleh alat elektronik lain (Vaughan, 2011:1).
1. Teks
Penggunaan teks dalam berkomunikasi sudah dilakukan manusia sejak 6000 tahun yang lalu. Teks berperan untuk menyampaikan informasi dalam aplikasi multimedia. Dalam multimedia, teks sering muncul pada judul, menu, navigasi, serta narasi atau isi.
2. Grafik
Sebuah grafik atau gambar dapat memiliki banyak arti. Penggunaan grafik atau gambar digunakan sebagai simbol terhadap suatu informasi. Dengan menggunakan grafik, tampilan pada aplikasi menjadi lebih bervariasi dibandingkan hanya menggunakan teks.
3. Audio
Audio merupakan elemen penting dalam multimedia. Audio bisa berbentuk pidato, bisikan, bahkan jeritan. Contoh penggunaan audio dalam aplikasi
multimedia adalah sebagai latar belakang musik, efek spesial, dan latar belakang suasana. Pemilihan jenis audio yang tepat dapat meningkatkan kualitas dari aplikasi multimedia. Sebaliknya, pemilihan audio yang tidak tepat dapat menghancurkan multimedia itu sendiri (Vaughan, 2011:104).
4. Animasi
Animasi dapat terjadi karena sebuah fenomena biologis yang disebut persistence of vision dan fenomena psikologis yang dinamakan phi. Objek yang terlihat oleh mata akan tetap tergambar pada retina mata selama beberapa saat setelah melihat. Dengan dikombinasikan dengan pikiran manusia, sebuah gambar yang berubah secara cepat, dapat terlihat menyatu menjadi sebuah ilusi gerakan. Animasi dapat membuat sebuah presentasi yang statis menjadi hidup. Dengan menggunakan software dan teknik yang tepat, sebuah gambar dapat dianimasikan dalam berbagai cara. Animasi yang sederhana banyak terjadi pada bidang 2D. Animasi yang lebih rumit dapat ditemukan pada bidang 2½D yang memberikan kesan efek bayangan, cahaya, dan perspektif. Sedangkan animasi 3D merupakan animasi yang mempunyai 3 sumbu (X, Y, dan Z) sehingga terlihat lebih nyata. 5. Video
Pada masa sekarang, video merupakan elemen multimedia yang dapat menarik perhatian penonton. Video digital merupakan alat multimedia yang dapat membawa pengguna lebih dekat dengan dunia nyata. Dengan menggunakan video, sebuah informasi dapat tersampaikan secara efektif dan penonton tetap tertarik untuk menontonnya (Vaughan, 2011:164).
2.3 Interaksi Manusia dan Komputer
Interaksi manusia dan komputer adalah disiplin ilmu yang mengaplikasikan metode-metode psikologi ke dalam alat-alat ilmu komputer untuk melayani kebutuhan manusia (Shneiderman & Plaisant, 2010:22).
2.3.1 Delapan Aturan Emas Perancangan Antar Muka Aplikasi
Menurut Shneiderman dan Plaisant (2010:88-89) terdapat 8 (delapan) aturan emas perancangan desain antar muka aplikasi yang harus diperhatikan, yaitu:
1. Strive for consistency
Aturan agar tetap konsisten merupakan aturan yang paling sering dilanggar dan sulit ditaati karena ada banyak bentuk konsistensi. Serangkaian aksi harus konsisten dalam situasi-situasi yang sejenis, seperti pada prompt, menu, layar bantuan, penggunaan warna, layout, jenis huruf, huruf kapital, dll.
2. Cater to universal usability
Mengenali kebutuhan berbagai pengguna yang berbeda merupakan suatu panduan dalam merancang desain. Perbedaan tingkat pengguna (novice / expert), rentang umur, dan keanekaragaman teknologi adalah perbedaan yang sering dijumpai. Sebagai contoh, kebutuhan novice user berbeda dengan expert user. Novice user membutuhkan penjelasan terhadap cara memakai aplikasi, sedangkan penambahan fitur seperti shortcut dalam menjalankan suatu aksi dibutuhkan oleh expert user. Contoh seperti di atas dapat memperkaya desain antar muka dan meningkatkan kualitas sistem.
3. Offer informative feedback
Untuk setiap tindakan yang dilakukan pengguna harus ada sebuah umpan balik yang informatif sehingga pengguna dapat mengetahui apa yang telah dilakukan. Untuk tindakan yang sifatnya minor dan sering dilakukan, respons yang diberikan dapat berupa respons yang sederhana. Sedangkan tindakan yang sifatnya mayor dan jarang dilakukan, respons yang diberikan harus lebih jelas. 4. Design dialogs to yield closure
Serangkaian tindakan harus diorganisasikan ke dalam suatu kelompok yang terdiri dari awal, pertengahan, dan akhir. Umpan balik yang informatif pada akhir dari serangkaian tindakan tersebut membuat pengguna merasa puas dan lega sehingga pengguna dapat merancang tindakan selanjutnya. Contohnya adalah sebuah website e-commerce yang terdiri dari beberapa langkah mulai dari memilih produk sampai mengakhiri transaksi (check out), yang diakhiri dengan sebuah konfirmasi yang jelas terhadap transaksi yang telah dilakukannya.
Perancangan desain antar muka harus sebisa mungkin mencegah pengguna melakukan kesalahan (error). Contohnya adalah tidak mengizinkan karakter alfabet pada entri field numerik. Jika pengguna melakukan kesalahan, desain antar muka harus dapat mendeteksi kesalahan tersebut dan menawarkan penanganan yang sederhana dan jelas
6. Permit easy reversal of actions
Tindakan-tindakan yang dilakukan pengguna harus dapat dikembalikan ke keadaan semula. Fitur seperti ini dapat mengurangi kecemasan pengguna, karena kesalahan (error) dapat dikembalikan ke keadaan sebelum terjadi kesalahan. Selain itu, dengan adanya suatu tindakan reversal, pengguna dapat terdorong untuk mengeksplorasi berbagai macam pilihan yang terdapat pada aplikasi. 7. Support internal locus of control
Pengguna aplikasi yang sudah berpengalaman menginginkan suatu perasaan bahwa mereka mempunyai kendali penuh terhadap desain antar muka dan desain antar muka dapat merespons suatu tindakan yang dilakukan. Sebuah respons yang tidak sesuai dengan keinginan pengguna dapat membuat kekhawatiran dan ketidakpuasan. Rancangan desain harus memposisikan pengguna sebagai inisiator dibandingkan sebagai responden dari suatu aksi.
8. Reduce short term memory load
Manusia mempunyai keterbatasan mengingat dan memproses informasi dalam jangka pendek. Oleh karena itu, suatu rancangan desain antar muka harus dibuat secara sederhana. Penggabungan beberapa halaman menjadi satu halaman, pengurangan frekuensi pergerakan tampilan, dan pemberian waktu pelatihan dalam menggunakan code, mnemonic, dan perurutan langkah merupakan cara untuk mengatasi keterbatasan manusia tersebut.
2.3.2 Lima Faktor Manusia Terukur
Shneiderman dan Plaisant (2010:32) juga menyatakan terdapat 5 (lima) faktor manusia terukur yang harus diperhatikan dalam merancang desain antar muka, di antaranya:
1. Time to learn
Berapa lama waktu yang dibutuhkan oleh pengguna untuk mempelajari tindakan-tindakan dalam mencapai suatu tujuan?
2. Speed of performance
Berapa lama waktu yang dibutuhkan aplikasi dalam menyelesaikan suatu tugas? 3. Rate of errors by users
Berapa banyak dan jenis kesalahan apa yang paling sering dilakukan pengguna aplikasi?
4. Retention over time
Seberapa baik pengguna aplikasi menjaga pengetahuannya setelah menggunakan aplikasi dalam jangka waktu tertentu?
5. Subjective satisfaction
Bagaimana tingkat kepuasan pengguna terhadap penggunaan aspek-aspek pada desain antar muka? Tingkat kepuasan pengguna dapat didapat dari wawancara atau kuesioner.
2.4 Rekayasa Perangkat Lunak
Roger S. Pressman (2015:15) mendefinisikan rekayasa perangkat lunak sebagai penerapan sistematis, disiplin dan pendekatan kuantitatif untuk pengembangan, operasi, dan pemeliharaan perangkat lunak.
Rekayasa perangkat lunak mempunyai 4 (empat) layer atau adalah sebagai berikut :
1. Tools
Menyediakan dukungan otomatis atau semi otomatis untuk proses dan metode. Tools diintegrasikan sehingga informasi yang dibuat oleh suatu tools dapat dipakai oleh yang lain, yang disebut dengan computer-aided software engineering.
2. Methods
Menyediakan cara-cara teknis dalam membangun sebuah software. Methods berisi tugas-tugas yang terdiri dari komunikasi, analisis kebutuhan, pemodelan desain, pembuatan program, pengujian, dan pendukungan.
3. Process
Merupakan fondasi dalam rekayasa perangkat lunak. Process mendefinisikan sebuah kerangka kerja yang harus dilakukan pada teknologi rekayasa perangkat lunak untuk penyampaian yang efektif. Pada layer process dilakukan kontrol
manajemen pada proyek software, penentuan metode teknis yang diterapkan, produk kerja yang dihasilkan (model, dokumen, data, laporan, formulir, dll), pembuatan milestone, penjaminan kualitas, dan pengaturan perubahan.
4. A quality focus
Merupakan lapisan dasar pada rekayasa perangkat lunak yang berfokus pada kualitas dari suatu software dengan standar tertentu.
Gambar 2.1 Empat Lapisan Rekayasa Perangkat Lunak
(Sumber: Software Engineering a Practitioners Approach, Pressman, 2014:16)
2.5 Scrum
Scrum merupakan salah satu agile software development. Agile software development merupakan metode yang dapat merespons dan menangani perubahan dengan cepat. Dengan menggunakan agile software development, ketika terdapat perubahan requirement, developer dapat mengadaptasi requirement baru ke dalam pengembangan yang sedang dikerjakan dengan cepat (Pressman, 2015:78). Scrum, menurut Ken Schwaber & Jeff Sutherland (2013:3) adalah sebuah kerangka kerja untuk menyelesaikan permasalahan kompleks yang senantiasa berubah, pada saat bersamaan dapat menghasilkan produk dengan nilai setinggi mungkin secara kreatif dan produktif. Scrum adalah kerangka proses yang telah digunakan untuk mengelola perkembangan produk kompleks semenjak awal tahun 1990. Scrum bukanlah sebuah proses ataupun teknik untuk mengembangkan produk, melainkan sebuah kerangka kerja di mana di dalamnya dapat dimasukkan beragam proses dan teknik yang dapat menangani permasalahan kompleks yang senantiasa berubah dengan cepat.
Gambar 2.2 Tahap-tahap Metodologi Scrum (Sumber: www.methodsandtools.com)
2.5.1 Tim Scrum
Tim scrum terdiri dari seorang pemilik produk, tim pengembang, dan seorang scrum master. Tim scrum mengatur dirinya sendiri dengan menentukan cara terbaik untuk menyelesaikan pekerjaannya, tidak diatur oleh pihak lain yang berada di luar anggota tim. Tim harus memiliki semua kompetensi yang dibutuhkan untuk menyelesaikan pekerjaan tanpa pihak lain yang berada di luar anggota tim. Model tim di dalam scrum dirancang sedemikian rupa untuk mengoptimalisasi fleksibilitas, kreatifitas dan produktifitas.
2.5.1.1 Pemilik Produk
Pemilik produk adalah orang yang bertanggung jawab untuk memaksimalkan nilai produk dan hasil kerja tim pengembang. Pemilik produk merupakan orang yang bertanggung jawab untuk mengelola product backlog.
2.5.1.2 Tim Pengembang
Tim pengembang terdiri dari para profesional yang bekerja untuk menghasilkan tambahan potongan produk yang disebut juga inkremental.
2.5.1.3 Scrum Master
Scrum master bertanggung jawab untuk memastikan scrum telah dipahami dan dilaksanakan mengikuti teori, praktik dan aturan main scrum. Scrum master adalah seorang yang melayani tim scrum dan membantu pihak di luar tim scrum untuk memahami apakah interaksi mereka dengan tim scrum bermanfaat atau tidak.
2.5.2 Scrum Artifacts
Scrum artifacts merepresentasikan pekerjaan atau nilai yang bertujuan untuk menyediakan transparansi, dan kesempatan untuk melakukan peninjauan dan adaptasi. Artifact yang didefinisikan oleh scrum secara khusus dirancang untuk meningkatkan transparansi dari informasi yang penting sehingga semua pihak dapat memiliki pemahaman yang sama terhadap artifact.
2.5.2.1 Product Backlog
Product backlog adalah daftar terurut dari setiap hal yang berkemungkinan dibutuhkan dalam produk dan merupakan sumber utama dari daftar kebutuhan mengenai semua hal yang perlu dilakukan terhadap produk. Product backlog bersifat tidak pernah selesai dan dinamis. Pada awal pembuatannya, product backlog hanya menjabarkan daftar kebutuhan yang paling dipahami pada saat itu. Seiring waktu, product backlog berkembang dan berubah sehingga produk menjadi layak, kompetitif di pasar, dan bermanfaat bagi penggunanya. Berdasarkan buku “Scrum and XP from trenches” yang ditulis oleh Henrik Kniberg (2007:9), product backlog terdiri dari kolom-kolom berikut ini:
a. ID
Merupakan identifikasi unik berisikan nomor-nomor auto increment untuk menghindari kehilangan jejak item backlog jika nama dari item backlog diganti.
b. Nama
Nama dari item backlog yang deskriptif dan cukup jelas dan bagi tim scrum. c. Kepentingan
Derajat kepentingan yang diberikan pemilik terhadap item backlog. Pengisian angka yang lebih besar menandakan item backlog semakin penting. Misalnya 10, 20, atau 150.
d. Perkiraan Awal
Perkiraan awal tim scrum tentang banyaknya kerja yang diperlukan untuk mengimplementasikan backlog item yang dibicarakan dan backlog item yang lainnya. Unit perkiraan banyaknya kerja biasanya dihitung sebagai man days atau satu hari kerja oleh satu orang. Untuk menghitung perkiraan ini, tim pengembang akan memberikan perkiraan berapa waktu yang dibutuhkan untuk menyelesaikan backlog item tersebut dalam kondisi semua tim scrum mengerjakan secara bersama tanpa gangguan. Contohnya adalah jika 3 orang dapat menyelesaikan satu backlog item dengan kondisi yang terpenuhi dalam 4 hari, maka perkiraan nilainya adalah 12 poin (3x4=12).
e. Demo
Demo menjelaskan cara item backlog yang telah diselesaikan dapat didemokan pada saat sprint demo.
f. Catatan
Informasi lain yang mungkin diperlukan, diklarifikasi, dan direferensi ke informasi lain yang akan dijabarkan cukup panjang dan mendetail.
Gambar 2.3 Contoh Product Backlog
2.5.2.2 Sprint Backlog
Sprint backlog adalah sekumpulan item backlog yang telah dipilih untuk dikerjakan sepanjang sprint beserta rencana untuk mengembangkan potongan produk dan merealisasikan tujuan sprint. Sprint backlog adalah perkiraan mengenai fungsionalitas apa yang akan tersedia di inkremen atau sprint selanjutnya dan pekerjaan yang perlu dikerjakan untuk mengantarkan fungsionalitas tersebut menjadi potongan tambahan produk yang lengkap. Sprint backlog bersifat dinamis dan dapat berubah kapan pun juga sepanjang sprint disesuaikan dengan rencana dan wawasan tim yang meningkat untuk mencapai tujuan sprint.
2.5.2.3 Inkremen
Inkremen adalah gabungan dari semua item product backlog yang diselesaikan pada waktu sprint berjalan dan nilai dari inkremen seluruh sprint sebelumnya. Pada akhir sprint, inkremen harus “Selesai”, yang artinya berada dalam kondisi yang berfungsi penuh dan memenuhi definisi “Selesai” yang dibuat oleh tim scrum. Contoh: Selesai apabila telah di-deploy pada server tes.
2.5.3 Scrum Events
Scrum events adalah acara-acara yang wajib dihadiri dalam scrum untuk mendukung berjalannya sprint, menciptakan sebuah kesinambungan dan mengurangi adanya acara-acara lain yang tidak tercantum dalam scrum. Setiap acara di dalam scrum selalu mempunyai batasan waktu untuk memastikan agar waktu digunakan secukupnya tanpa ada yang terbuang sia-sia. Semua scrum events akan dibungkus ke dalam batasan waktu yang disebut sprint.
Sprint merupakan sebuah batasan waktu selama satu bulan atau kurang. Sebuah inkremen yang “Selesai” di dalam sprint harus berfungsi, berpotensi untuk dirilis dan dikembangkan. Sprint biasanya memiliki durasi yang konsisten sepanjang proses pengembangan produk dan dibatasi selama satu bulan menurut kalender. Bila jangka waktu sprint terlalu panjang, maka definisi mengenai apa yang akan dibangun akan berubah, kompleksitas dapat meningkat, dan risiko dapat bertambah. Sprint meningkatkan prediktabilitas karena adanya peninjauan dan pengadaptasian terhadap
perkembangan, setidaknya setiap satu bulan sekali. Setiap sprint yang dijalankan akan memuat scrum events yang terdiri dari Sprint Planning, Daily Scrum, Sprint Review, dan Sprint Retrospective.
2.5.3.1 Sprint Planning
Sprint planning bertujuan untuk merencanakan pekerjaan yang akan dilakukan di dalam sprint. Perencanaan ini dibuat secara kolaboratif oleh seluruh anggota tim scrum dengan batasan waktu 8 (delapan) jam. Berikut merupakan hal-hal yang perlu dilakukan dalam perencanaan sprint (Henrik Kniberg, 2007:19): 1. Menentukan tujuan sprint
Tujuan sprint merupakan komponen penting dalam perencanaan sprint. Tujuan sprint dapat mencegah anggota dari tim pengembang kebingungan atas apa yang seharusnya mereka lakukan.
2. Menentukan panjang sprint
Salah satu hasil dari sprint planning adalah panjang sprint atau penetapan tanggal demo. Sebuah sprint yang pendek memungkinkan perusahaan menjadi lebih lincah, lebih sering melakukan delivery, dan lebih banyak memberikan umpan balik. Namun, sebuah sprint yang panjang juga memiliki kelebihan yaitu tim memiliki lebih banyak waktu untuk membangun momentum serta memiliki ruang yang cukup untuk menyelesaikan masalah dan mencapai tujuan sprint. Dari dua batasan waktu di atas, menentukan waktu yang tepat untuk sprint merupakan hal yang penting untuk dilakukan. Menurut eksperimen yang dilakukan Henrik Kniberg (2007:20), 3 (tiga) minggu merupakan waktu yang cukup tepat untuk memberikan kelincahan kepada perusahaan, dan cukup panjang bagi tim untuk memperoleh irama kerja dan menyelesaikan masalah-masalah yang timbul pada saat sprint berlangsung.
3. Melakukan perkiraan waktu pengerjaan dan memecah item backlog ke ukuran yang lebih kecil jika diperlukan
Perkiraan waktu pengerjaan sangat dibutuhkan untuk menyamakan nilai estimasi yang telah dipikirkan oleh pemilik produk pada product backlog yang tidak sesuai dengan tim pengembang. Perkiraan besarnya nilai estimasi akan lebih mudah dan akurat bila dipecah ke dalam bentuk yang lebih kecil.
Gambar 2.4 Pembagian Story
(Sumber: Scrum and XP From The Trenches, 2007:31)
4. Memutuskan item backlog yang akan diikutkan dalam sprint
Salah satu aktivitas utama dalam perencanaan sprint adalah menentukan item backlog yang akan diikutkan dalam sprint. Aktivitas ini akan mengubah product backlog menjadi sprint backlog.
Gambar 2.5 Mengubah Product Backlog Menjadi Sprint Backlog (Sumber: Scrum and XP From The Trench, 2007:21)
Berdasarkan gambar di atas, setiap persegi panjang merepresentasikan item backlog yang diurutkan berdasarkan derajat kepentingan. Ukuran dari setiap persegi panjang merepresentasikan poin pada perkiraan awal product backlog. Tinggi dari kurung kurawal biru merepresentasikan perkiraan kecepatan pengerjaan tim. Kecepatan yang dimaksud adalah jumlah item backlog yang diperkirakan dapat dikerjakan tim selama sprint yang akan datang. Sprint backlog pada bagian kanan gambar merupakan sebagian kecil dari product backlog yang akan dikerjakan dalam sprint. Tim pengembang yang akan memilih item backlog akan diikutkan ke dalam sprint selanjutnya. Untuk memutuskan item backlog yang akan diikutkan tim dapat menggunakan teknik perhitungan kecepatan yang terdiri dari 2 (dua) tahap yaitu :
a. Memutuskan perkiraan kecepatan
Untuk memutuskan perkiraan kecepatan, pertama yang harus dilakukan adalah menghitung man days yang dimiliki oleh tim pengembang. Cara perhitungannya adalah dengan mengalikan hari kerja dalam sprint dengan jumlah tim pengembang. Contoh: panjang sprint yang ditetapkan 3 (tiga) minggu atau 18 (delapan belas) hari kerja dengan anggota tim pengembang 3 (tiga) orang, maka didapatkan perhitungan man days = 18 x 3 = 54.
Jumlah man days yang didapatkan merupakan jumlah kecepatan tim ideal ketika kondisi pengerjaan tidak mendapat gangguan. Namun hal itu sulit terjadi dikarenakan adanya kejadian-kejadian tidak terduga yang dialami tim pengembang, salah satu contohnya adalah sakit atau waktu terbagi dengan aktivitas pengembangan lain. Oleh karena itu, menurut Henrik Kniberg (2007:26-28), sebuah focus factor dibutuhkan untuk menangani masalah ini. Focus factor adalah estimasi tingkat fokus tim. Tingkat focus factor yang kecil menunjukkan tim mendapatkan banyak gangguan atau memperkirakan waktu pengerjaan dengan terlalu optimis. Cara terbaik menentukan focus factor adalah melihat performa dari sprint sebelumnya.
Gambar 2.6 Rumus Menghitung Focus Factor (Sumber: Scrum and XP From The Trench, 2007:27)
Contoh: perkiraan kecepatan awal dari sprint sebelumnya adalah 54 (lima puluh empat) man days dan kecepatan pengerjaan tim yang sebenarnya adalah 27 (dua puluh tujuh) man days. Maka nilai dari focus factor adalah 27/54 = 50%. Untuk sprint pertama, nilai dari default focus factor adalah 70%. Setelah focus factor dan perkiraan waktu ideal ditentukan, maka perkiraan kecepatan dapat ditentukan dengan rumus berikut:
Gambar 2.7 Rumus Menghitung Kecepatan Sprint (Sumber: Scrum and XP For The Trench, 2007:26)
Contoh: Perkiraan man days pada perkiraan ideal di atas dikalikan dengan focus factor yang telah disepakati yaitu 70% sehingga perkiraan kecepatan tim pada sprint adalah 54 x 70% = 38.
b. Menghitung banyak item backlog yang akan ditambahkan tanpa melebihi perkiraan kecepatan yang telah ditentukan.
Setelah mendapatkan perkiraan kecepatan tim pada sprint, tim akan memilih item backlog yang akan diikutkan ke dalam sprint selanjutnya dengan pertimbangan pemilik produk. Pertimbangan yang akan dilakukan oleh pemilik produk bersifat tidak wajib diikuti, karena yang bertanggung jawab dalam penentuan item backlog dalam sprint adalah tim pengembang.
5. Memecah Item Backlog menjadi Task
Item Backlog yang telah dimasukkan pada sprint backlog akan dipecah atau dijabarkan menjadi task. Hal ini akan mempermudah tim scrum dalam pengerjaan item backlog.
2.5.3.2 Daily Scrum
Daily scrum adalah kegiatan dengan batasan waktu maksimum selama 15 (lima belas) menit dengan tujuan agar tim pengembang dapat menyinkronkan pekerjaan mereka dan membuat perencanaan untuk 24 (dua puluh empat) jam ke depan. Daily scrum juga digunakan untuk meninjau perkembangan menuju tujuan sprint dan meninjau tren perkembangan menuju selesainya pekerjaan yang ada dalam sprint. Untuk meninjau perkembangan menuju perkembangan sprint, Henrik Kniberg (2007:62) membuat sebuah grafik burndown pada setiap akhir daily scrum sebagai alat pembantu .
Gambar 2.8 Grafik Burndown
Grafik burndown pada gambar 2.8 akan menunjukkan performa tim setiap harinya, contoh:
1. Hari pertama sprint, tanggal 1 Agustus, tim memperkirakan bahwa ada sekitar 70 (tujuh puluh) story poin yang perlu diselesaikan berdasarkan perhitungan kecepatan tim.
2. Pada tanggal 16 Agustus, grafik menunjukkan bahwa hanya tersisa 15 (lima belas) story poin. Garis lurus putus-putus dari kiri ke kanan merupakan garis tren yang menunjukkan performa dari tim. Jika garis biru yang menunjukkan jumlah story poin yang tersisa berada di sekitar garis tren ini maka tim akan menyelesaikan semua tugas tepat pada waktunya.
2.5.3.3 Sprint Review
Sprint review adalah acara dengan batasan waktu 4 (empat) jam yang diadakan di akhir sprint untuk meninjau inkremen dan mengubah product backlog yang diperlukan. Sprint review akan membahas apa saja yang telah dikerjakan dalam sprint yang baru saja selesai. Berdasarkan hasil pembahasan dan perubahan product backlog akan ditentukan tindakan yang perlu dikerjakan berikutnya untuk mengoptimalkan nilai produk. Hasil dari acara ini adalah revisi product backlog yang mendefinisikan kemungkinan item product backlog untuk sprint berikutnya.
2.5.3.4 Sprint Retrospective
Sprint retrospective adalah acara dengan batasan waktu 3 (tiga) jam yang digunakan oleh tim scrum sebagai kesempatan untuk meninjau dirinya sendiri dan membuat perencanaan mengenai peningkatan yang akan dilakukan di sprint berikutnya. Sprint retrospective memiliki tujuan sebagai berikut :
1. Meninjau bagaimana sprint yang telah selesai berlangsung, termasuk hal-hal yang berkaitan dengan orang-orang, hubungan antara orang, proses dan perangkat kerja.
2. Mengidentifikasi dan mengurutkan hal-hal utama yang berjalan baik dan hal-hal yang berpotensi untuk ditingkatkan.
3. Membuat rencana implementasi dengan tujuan untuk meningkatkan cara-cara kerja tim scrum.
2.6 Model View Controller
Model View Controller (MVC) adalah salah satu tipe arsitektur yang memisahkan tampilan pengguna dengan fungsionalitas dan konten informasi. Pola MVC membagi aplikasi menjadi 3 (tiga) modul yaitu sebagai berikut (Pressman, 2015:384):
1. Model
Model berisikan semua konten spesifik aplikasi, logika proses, isi dari objek dan akses ke eksternal atau sumber data.
2. View
View berisikan semua fungsi tampilan, dari tampilan dan semua proses fungsionalitas yang akan ditampilkan pada pengguna.
3. Controller
Controller merupakan penghubung antara model dan view. Controller juga menangani akses dan alur data antara model dan view.
2.7 Storyboard
Menurut Husnin et. al. (2013:47), storyboard adalah teknik prototyping berteknologi rendah yang biasanya diimplementasikan pada awal tahap sebelum produksi dan juga digunakan sebagai sarana untuk menemukan ide. Pembuatan storyboard dikatakan berteknologi rendah dikarenakan hanya dapat dibuat hanya dengan menggunakan papan, kertas, tanah liat, atau spidol berwarna.
Storyboard berupa gambar hitam putih beresolusi rendah yang diatur secara berurutan. Penampilan storyboard akan diberi catatan dan spesifikasi dari desain tersebut (Vaughan, 2011:301).
Gambar 2.9 Contoh Storyboard Beserta Hasil Akhirnya (Sumber: Multimedia Making It Work, Vaughan, 2011:301)
Perancangan storyboard menawarkan berbagai keuntungan dalam tahap perencanaan proyek, terutama ketika permintaan bisnis dan teknikal tidak dapat tersampaikan dengan baik. Pertama, perancangan storyboard dapat digunakan dalam tahap awal pembuatan proyek dan digunakan sebagai dokumen untuk meninjau kembali proses pengembangan software. Kedua, proses perancangan storyboard menghabiskan dana yang sedikit, memerlukan waktu beberapa jam saja untuk dibuat dan memerlukan pena dan kertas saja dalam proses pembuatanny0061. Ditambah lagi, kreativitas tim dapat ditangkap dan dimanfaatkan selama proses perancangan berlangsung sehingga tim dapat berdiskusi dengan antusias dan alur tim akan
menjadi lancar dengan adanya ide-ide yang terus disalurkan dan masalah yang terus digali, seperti perbedaan pengetahuan (Doyle, Farley, & Martin, 2013:250).
2.8 Unified Modeling Language
Unified Modeling Language (UML) adalah sekumpulan kaidah pemodelan yang digunakan untuk menentukan dan menjelaskan sistem perangkat lunak dengan menggunakan istilah objek atau berbasiskan objek (Whitten & Bentley, 2007:371).
2.8.1 Activity Diagram
Activity Diagram adalah diagram yang dapat digunakan untuk
menggambarkan secara grafis alur dari proses bisnis, langkah dari use case, atau logika dari kelakuan objek (Whitten & Bentley, 2007:390).
Gambar 2.10 Contoh Activity Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:393)
Activity diagram memiliki notasi sebagai berikut: 1. Initial node
Notasi ini adalah pertanda sebuah proses dimulai, digambarkan dengan sebuah lingkaran bulat berisi.
Gambar 2.11 Contoh Initial Node pada Activity Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:393)
2. Actions
Notasi ini digambarkan menggunakan persegi panjang bersudut tumpul yang melambangkan satu langkah atau tahapan.
Gambar 2.12 Contoh Actions pada Activity Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:246)
3. Flow
Notasi flow digambarkan dengan panah, notasi ini mengindikasikan perkembangan dari action. Kebanyakan dari notasi flow tidak membutuhkan kata-kata untuk mengidentifikasikan dirinya kecuali notasi berasal dari notasi decision.
Gambar 2.13 Contoh Flow pada Activity Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:392)
4. Decision
Notasi decision digambarkan dengan bentuk belah ketupat beserta 1 (satu) flow masuk dan 2 (dua) atau lebih flow yang keluar. Flow yang keluar menandakan kondisi-kondisi yang ada.
Gambar 2.14 Contoh Decision pada Activity Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:392)
5. Merge
Notasi merge digambarkan dengan bentuk belah ketupat beserta 2 atau lebih flow masuk dan 1 flow yang keluar. Flow yang dikombinasikan merupakan flow yang dipisahkan oleh decision.
Gambar 2.15 Contoh Merge pada Activity Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:392)
6. Fork
Notasi fork digambarkan dengan garis hitam dengan 1 flow masuk dan 2 atau lebih flow keluar. Action yang ada pada paralel flow menandakan action bisa terjadi dalam waktu yang bersamaan.
Gambar 2.16 Contoh Fork pada Activity Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:392)
7. Join
Notasi join digambarkan dengan garis hitam dengan 2 atau lebih flow masuk dan 1 flow keluar yang menandakan semua proses yang berlangsung berakhir. Semua action yang bergabung dalam join harus selesai sebelum melanjutkan ke action berikutnya.
Gambar 2.17 Contoh Join pada Activity Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:392)
8. Activity Final
Notasi ini menandakan akhir dari proses atau activity dan digambarkan dengan sebuah lingkaran bulat padat dengan garis lingkaran di sekitarnya.
Gambar 2.18 Contoh Activity Final pada Activity Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:392)
Activity diagram dapat dipisahkan berdasarkan pelaku (class atau actor) dari action agar lebih spesifik. Pemisahan tersebut sering disebut swimlane. Satu activity diagram dapat mempunyai dua atau lebih swimlane tergantung actor yang terlibat.
2.8.2 Use Case Diagram
Use case diagram adalah diagram yang menggambarkan secara grafis sebuah interaksi antara sistem dan eksternal sistem dan pengguna. Use case diagram secara grafis menjelaskan siapa yang akan menggunakan sistem dan dengan cara apa pengguna berinteraksi dengan sistem (Whitten & Bentley, 2007:246).
Gambar 2.19 Contoh Use Case Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:246)
Use case diagram mempunyai komponen-komponen yang membantu proses penggambaran sistem. Komponen-komponen berikut adalah sebagai berikut:
2.8.2.1 Use Case
Pemodelan use case menggunakan sebuah alat yang disebut use case untuk mengidentifikasikan dan menjelaskan fungsi-fungsi yang ada pada sistem. Use case adalah urutan langkah-langkah perilaku atau skenario terotomatisasi atau manual yang bertujuan untuk menyelesaikan sebuah tugas bisnis. Use case mendeskripsikan
fungsi-fungsi sistem berdasarkan sudut pandang dari pengguna luar dengan menggunakan cara dan peristilahan yang dimengerti pengguna. Use case diagram menggambarkan use case secara grafis dalam bentuk elips horizontal dengan nama use case yang berada di dalam elips tersebut (Whitten & Bentley, 2007:246).
Gambar 2.20 Contoh Use Case pada Use Case Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:246)
2.8.2.2 Actor
Use case akan dipicu oleh pengguna eksternal atau actor. Actor adalah segala sesuatu yang perlu berinteraksi dengan sistem untuk bertukar informasi. Actor memulai sebuah aktivitas sistem atau use case dengan tujuan menyelesaikan beberapa tugas bisnis atau untuk menghasilkan sesuatu yang bernilai. Actor merepresentasikan peran yang terpenuhi dengan adanya interaksi pengguna dengan sistem. Istilah actor dalam hal ini tidak hanya merepresentasikan manusia saja, tetapi juga organisasi, sistem lain atau konsep waktu. Use case diagram menggambarkan use case secara grafis dalam bentuk stick figure yang di bawahnya terdapat nama dari actor atau peran yang dimainkan (Whitten & Bentley, 2007:247).
Gambar 2.21 Contoh Actor pada Use Case Diagram
Terdapat 4 (empat) tipe actor yaitu: 1. Primary Business Actor
Pemangku kepentingan utama yang menerima keuntungan utama dari pelaksanaan use case dengan menerima sesuatu yang dapat diukur dan diamati nilainya. Primary business actor dapat mendapatkan hal tersebut dengan memulai ataupun tanpa memulai business event.
2. Primary System Actor
Pemangku kepentingan yang secara langsung berinteraksi dengan sistem untuk memulai atau memicu business event atau system event. Primary business actor dan primary system actor dapat saling berinteraksi dengan tujuan untuk menggunakan sistem yang sebenarnya.
3. External Server Actor
Pemangku kepentingan yang menanggapi permintaan data dari use case. 4. External Receiver Actor
Pemangku kepentingan yang bukan sebagai actor utama melainkan penerima sesuatu yang dapat diukur dan diamati nilainya dari use case.
2.8.2.3 Relationship
Sebuah relationship menggambarkan garis antara 2 simbol yang ada pada use-case diagram. Arti dari relationship tesebut dapat berbeda tergantung bagaimana garis digambar dan simbol apa yang dihubungkan. Berikut adalah tipe-tipe relationship yang ada pada use-case diagram (Whitten & Bentley, 2007:248):
1. Associations
Relationship antara actor dan use case yang menjelaskan adanya interaksi antara kedua simbol tersebut. Association dimodelkan sebagai garis padat yang menghubungkan actor dan use case.
Gambar 2.22 Contoh Association pada Use Case Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:248)
Association yang mempunyai mata panah (Gambar 2.22 nomor 1) menunjukkan bahwa use case dimulai atau diinisiasi oleh actor yang ada di ujung garis. Association yang tidak memiliki mata panah (Gambar 2.22 nomor 2) mengindikasikan interaksi antara use case dengan external server atau receiver actor. Ketika actor-actor dihubungkan dengan use case, dapat dikatakan actor berkomunikasi secara unidirectional atau bideractional menggunakan use case sebagai media.
2. Extends
Sebuah use case dapat memiliki fungsi yang rumit yang terdiri dari beberapa langkah yang membuat logika dari use case menjadi lebih sulit dimengerti. Dengan tujuan menyederhanakan use case dan membuatnya lebih mudah dimengerti, langkah-langkah dalam use case dapat dipecah menjadi use case sendiri. Use case hasil dari pemecahan tersebut disebut extension use case. Relationship antara extension use case dengan use case yang diperpanjang fungsinya disebut extends relationsip. Use case diperbolehkan untuk mempunyai banyak extend relationship, namun extension use case hanya diperbolehkan dipicu oleh use case yang diperpanjang. Extends relationship direpresentasikan sebagai garis dengan mata panah yang menunjuk pada use case dan di ujung lainnya pada extension use case. Setiap extend relationship ditandai dengan “<<extends>>” di samping atau di atas garisnya.
Gambar 2.23 Contoh Extends pada Use Case Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:249)
3. Uses
Pada penggunaan use-case diagram, sering kali 2 (dua) atau lebih use case melakukan langkah yang fungsinya sama. Untuk mengurangi perulangan ini, maka akan lebih baik bila langkah yang sama dipecah menjadi use case sendiri yang disebut abstract use case. Relationship antara abstract use case dan use case yang menggunakan abstract use case disebut uses relationship. Uses relationship digambarkan dengan garis bermata panah yang bermula pada use case asli yang menunjuk pada use case yang digunakan. Setiap uses relationship ditandai dengan “<<uses>>” di samping atau di atas garisnya.
Gambar 2.24 Contoh Uses pada Use Case Diagram
4. Depends on
Relationship depends on adalah sebuah relationship yang menandakan ketergantungan antar use case. Relationship ini menunjukkan bahwa sebuah use case tidak dapat dijalankan sebelum use case lain selesai dijalankan. Depends on relationship digambarkan sebagai garis dengan mata panah yang dimulai dari 1 (satu) use case yang menunjuk ke use case yang digantungkan. Setiap garis depends relationship ditandai dengan “<<depends on>>”.
Gambar 2.25 Contoh Depends On pada Use Case Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:250)
5. Inheritance
Ketika 2 (dua) atau lebih actor mempunyai perilaku yang sama, maka akan lebih baik jika perilaku tersebut diberikan kepada sebuah abstract actor terlebih dahulu untuk mengurangi perulangan. Inheritance adalah sebuah relationship antar actor yang dibuat untuk menyederhanakan penggambaran di mana abstract actor mewariskan perannya ke beberapa actor sebenarnya. Inheritance relationship digambarkan seperti berikut:
Gambar 2.26 Contoh Inheritance pada Use Case Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:250)
2.8.3 Use Case Narrative
Use case narrative merupakan sebuah deskripsi tekstual dari suatu business event dan cara-cara pengguna berinteraksi dengan sistem untuk menyelesaikan suatu tugas (Whitten & Bentley, 2007:246). Use case narrative digunakan untuk mendapatkan pemahaman event dan seluk beluk sistem secara cepat dan baik.
High level use case narrative mempunyai bagian-bagian sebagai berikut: 1. Author
Nama-nama individu yang berkontribusi terhadap penulisan use case dan yang menyediakan kontak untuk siapa saja yang membutuhkan informasi tambahan tentang use case.
2. Date
Tanggal terakhir dilakukannya perubahan terhadap use case. 3. Version
Versi use case yang sedang digunakan sekarang. 4. Use-case name
Nama dari use case. Nama use case harus merepresentasikan tujuan yang ingin dicapai dari suatu use case. Nama use case tersebut harus dimulai dengan kata kerja.
5. Use-case type
Tipe atau jenis use case yang digunakan. Dalam pemodelan use case, business requirement use case merupakan use case yang dibuat terlebih dahulu karena memiliki fokus pada visi strategis dan tujuan dari berbagai stakeholder. Tipe use case ini berorientasi bisnis dan merefleksikan tampilan high-level dari kelakuan sistem yang diinginkan. Use case ini juga bebas dari detail teknis dan bisa berisi aktivitas manual yang akan dibuat menjadi otomatis. Business requirement use case menyediakan pemahaman umum dari cakupan dan ruang lingkup masalah tetapi tidak mencakup detail-detail yang dibutuhkan oleh developer terhadap tugas sistem yang harus dilakukan.
6. Use-case ID
Sebuah identifier yang secara unik mengidentifikasi suatu use case. 7. Priority
Priority mempunyai tujuan untuk menandakan tingkat pentingnya dari suatu use case dalam terminologi low, medium, atau high.
8. Source
Source mendefinisikan entitas yang memicu pembuatan suatu use case. Source bisa berbentuk requirement, dokumen, atau stakeholder.
9. Primary business actor
Primary business actor adalah stakeholder yang mendapatkan keuntungan dari pengeksekusian suatu use case dengan menerima suatu nilai yang dapat diukur dan diobservasi.
10. Other participating actors
Aktor-aktor lain yang berpartisipasi dalam use case untuk mencapai tujuannya, termasuk initiating actors, facilitating actors, server/receiver actors, dan secondary actors.
11. Interested stakeholder(s)
Stakeholder adalah siapa saja yang mempunyai kepentingan dalam pengembangan dan pengoperasian dari sistem software. Sedangkan interested stakeholder adalah seseorang selain actor yang tertarik secara pribadi terhadap tujuan dari use case.
12. Description
Ringkasan deskriptif singkat yang terdiri dari beberapa baris berisi maksud dari use case dan aktivitasnya.
Gambar 2.27 Contoh Use Case Narrative
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:257)
Setiap high-level use case yang diidentifikasi harus diperluas atau dikembangkan dengan memasukkan typical course dan alternate course dari suatu event. Typical course merupakan deskripsi langkah-langkah dari awal inisialisasi sampai akhir dari business event. Sedangkan bagian alternate course adalah sebuah exception atau pencabangan kondisi dari suatu use case. Berikut ini adalah bagian-bagian tambahan pada use case narrative:
1. Precondition
Precondition adalah batasan pada status sistem sebelum use case dieksekusi. Secara umum, precondition mengacu pada use case lain yang sebelumnya harus di eksekusi.
2. Trigger
Trigger adalah suatu event yang memicu pengeksekusian use case. Biasanya berupa physical action, seperti pelanggan berjalan menuju kasir. Waktu juga bisa menjadi sebuah trigger terhadap suatu use case.
3. Typical Course of Events
Typical course of events adalah urutan aktivitas yang dilakukan actor dan sistem untuk mencapai tujuan dari use case.
4. Alternate Course
Alternate course adalah perilaku dari use case jika terjadi sebuah exception atau variasi pada typical course. Alternate course dapat terjadi ketika terdapat sebuah kondisi pencabangan dalam use case atau sebuah exception yang membutuhkan langkah tambahan di luar lingkup typical course.
5. Conclusion
Conclusion dijelaskan ketika suatu use case telah selesai dibuat. Dalam kata lain, ketika primary actor telah mendapatkan suatu nilai yang dapat diukur.
6. Postcondition
Postcondition adalah batasan pada status sistem setelah suatu use case telah selesai dieksekusi. Postcondition dapat berupa data yang telah disimpan dalam database atau tanda terima yang dikirimkan ke pelanggan.
7. Business Rules
Business rules menspesifikasikan kebijakan dan prosedur bisnis di dalam sistem yang baru.
8. Implementation Constraints and Specifications
Implementation constraints and specifications menjelaskan kebutuhan-kebutuhan non-fungsional yang mungkin berdampak pada realisasi dari use case dan dapat berguna pada perancangan dan pencakupan arsitektur.
9. Assumptions
Assumptions dibuat oleh pembuat use case ketika membuat use case. 10. Open Issues
Pertanyaan-pertanyaan atau masalah-masalah yang harus dipecahkan atau diinvestigasi sebelum use case disetujui.
Gambar 2.28 Contoh Use Case Narrative
2.8.4 Class Diagram
Class diagram adalah sebuah penggambaran struktur objek statis dari sebuah sistem yang menunjukkan class objek bahwa sistem telah disusun dan hubungannya antara class objek. Pada class diagram terdapat multiplicity, hubungan generalization / specialization, dan hubungan aggregation (Whitten & Bentley, 2007:400).
1. Menentukan associations dan multiplicity
Associations antara dua class adalah sesuatu yang “perlu diketahui” dari suatu objek pada objek lainnya sehingga sebuah objek dalam suatu class dapat saling merujuk dan mengirim pesan satu sama lain. Setelah associations ditentukan, multiplicity dari associations juga harus ditentukan. Multiplicity merupakan objek class yang berhubungan dengan class lainnya. Multiplicity dapat dinyatakan dalam integer bernilai negatif atau integer dengan jarak tertentu. Multiplicity bernilai “0..1” berarti ada 0 atau 1 objek pada class yang dituju.
Gambar 2.29 Contoh Aggregations dan Multiplicity pada Class Diagram (Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:406)
2. Menentukan hubungan generalization / specialization
Hubungan generalization / specialization, yang disebut juga sebagai hierarki penggolongan atau hubungan “is a”, terdiri atas class supertype (abstract atau parent) dan class subtype (concrete atau child). Class supertype berisi atribut dan behavior umum dari sebuah hierarki sedangkan class subtype berisi atribut dan behavior khusus pada suatu objek namun mewarisi atribut dan behavior dari class supertype. Hubungan generalization / specialization dapat ditentukan
dengan melihat adanya suatu hubungan antara dua class yang memiliki multiplicity one-to-one di sebuah class diagram. Class yang memiliki atribut dan behavior yang umum juga dapat disatukan menjadi class supertype yang baru.
Gambar 2.30 Contoh Hierarki Generalization / Specialization pada Class Diagram
3. Menentukan hubungan aggregation / composition
Aggregation adalah tipe hubungan yang unik, dengan sebuah objek merupakan “bagian” dari objek lainnya yang biasa disebut sebagai hubungan whole / part dan dapat dinyatakan sebagai “Objek A berisi objek B dan objek B adalah bagian dari objek A.” Meskipun hubungan aggregation adalah hubungan asimetris, hubungan ini tidak menerapkan inheritance yang menyatakan bahwa objek B mewarisi behavior atau atribut dari objek A. Behavior yang dinyatakan pada objek yang merupakan whole akan secara otomatis dinyatakan pada objek yang merupakan part. Misalnya saja jika objek A yang merupakan whole dikirimkan ke pelanggan, maka objek B yang merupakan part juga akan dikirimkan.
Gambar 2.31 Contoh Class Diagram
2.8.5 Sequence Diagram
Sequence diagram adalah sebuah diagram UML untuk merancang logika use case dengan menggambarkan interaksi pesan antar objek dalam urutan waktu (Whitten & Bentley, 2007:659).
Gambar 2.32 Contoh Sequence Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:659)
Menurut Whitten dan Bentley (2007:660) terdapat 8 (delapan) notasi yang digunakan dalam sequence diagram:
a. Actor
Aktor yang berinteraksi dengan user interface dinyatakan dengan simbol actor. Terkadang actor tidak ditampilkan untuk mempersingkat pembuatan sequence diagram. Terkadang actor dinyatakan dengan sebuah kotak seperti class dengan notasi <<actor>>. Garis vertikal putus-putus yang menjulur di bawah actor mengindikasikan waktu hidup dari sequence diagram.
Gambar 2.33 Contoh Actor pada Sequence Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:662)
b. Interface Class
Code user interface class dinyatakan dengan sebuah kotak dengan notasi <<interface>>. Notasi titik dua (:) merupakan notasi sequence diagram standar untuk menyatakan “instance” class yang sedang berjalan. Garis vertikal putus-putus yang menjulur di bawah actor mengindikasikan waktu hidup dari sequence diagram.
Gambar 2.34 Contoh Interface Class pada Sequence Diagram (Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:662)
c. Controller Class
Controller class dinyatakan dengan sebuah kotak dengan notasi <<controller>>. Notasi titik dua (:) merupakan notasi sequence diagram standar untuk menyatakan “instance” class yang sedang berjalan. Garis vertikal putus-putus yang menjulur di bawah actor mengindikasikan waktu hidup dari sequence diagram.
Gambar 2.35 Contoh Controller Class pada Sequence Diagram (Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:662)
d. Entity Classes
Entity classes dinyatakan dengan sebuah kotak. Notasi titik dua (:) menunjukkan instance dari sebuah objek.
Gambar 2.36 Contoh Entity Class pada Sequence Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:662)
e. Messages
Messages yang dikirim ke class dinyatakan dengan panah horizontal. Setiap pesan akan memanggil behavior atau class yang dituju oleh mata panah. Kaidah UML untuk menuliskan messages adalah dengan menuliskan kata pertama dengan huruf kecil dan menambahkan kata kedua dengan huruf kapital pada huruf pertamanya tanpa spasi. Jika ada tanda kurung, masukan parameter yang perlu disampaikan dengan kaidah penamaan yang sama dan pisahkan parameter yang satu dan lainnya dengan tanda koma.
Gambar 2.37 Contoh Message pada Sequence Diagram
f. Activation Bars
Activation bars adalah persegi panjang yang mengindikasikan periode waktu selama sebuah objek digunakan. Biasanya, objek dibuat sebagai respon dari message yang diterima.
Gambar 2.38 Contoh Activation Bars pada Sequence Diagram (Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:662)
g. Return Messages
Return messages dinyatakan dengan garis horizontal putus-putus. Setiap behavior akan mengembalikan sesuatu namun untuk menyederhanakan sequence diagram, return message sering tidak ditampilkan dalam sequence diagram.
Gambar 2.39 Contoh Return Message pada Sequence Diagram (Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:662)
h. Self-call
Adalah sebuah objek yang memanggil method-nya sendiri.
Gambar 2.40 Contoh Self Call pada Sequence Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:662)
i. Frame
Frame digunakan untuk mengindikasikan bahwa controller perlu mengulang (loop) semua item yang digunakan.
Gambar 2.41 Contoh Frame pada Sequence Diagram
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:659)
2.9 Object Oriented Design
Object Oriented Design adalah sebuah pendekatan yang digunakan untuk menjelaskan solusi software dalam bentuk kolaborasi dari objek, atribut, dan method. Aplikasi bekerja dengan menggunakan class yang mengirim dan menerima pesan dari class lain. Tujuan dari Object Oriented Design adalah untuk menjelaskan objek dan pesan dari sistem (Whitten & Bentley, 2007:648).
2.9.1 Entity Classes
Entity classes biasanya merepresentasikan benda-benda pada dunia nyata dan mengandung informasi yang biasa dikenal dengan nama atribut. Entity classes juga mengenkapsulasi suatu behavior / tingkah laku yang menjaga informasi atau atributnya. Oleh karena itu, entity classes adalah suatu object class yang mengandung informasi bisnis dan mengimplementasikan analisis class (Whitten & Bentley, 2007:648).
2.9.2 Interface Classes
Interface classes adalah object class yang mempunyai maksud agar suatu actor dapat berinteraksi dengan sistem. Sebagai contoh, sebuah window, dialog box, dan layar. Untuk actor yang bukan manusia, sebuah Application Program Interface (API) ialah interface class. Interface class juga biasa disebut dengan nama boundary class. Interface class mempunyai dua tanggung jawab utama, yaitu (Whitten & Bentley, 2007:648):
1. Menerjemahkan input user menjadi informasi yang dapat dimengerti sistem dan digunakan untuk memproses business event.
2. Mengambil data yang dibutuhkan business event dan menerjemahkan data agar dapat ditampilkan sesuai dengan pengguna.
2.9.3 Control Classes
Control classes adalah object class yang mengandung logika aplikasi. Contoh logika aplikasi adalah business rule dan kalkulasi-kalkulasi yang melibatkan entitas-entitas object class. Control classes mengoordinasikan pesan-pesan antara interface classes dan entity classes dan urutan dari pesan yang terjadi (Whitten & Bentley, 2007:649).
2.9.4 Persistence Classes
Persistence classes adalah object class yang menyediakan fungsi untuk membaca dan menulis attribut-attribut dalam sebuah database. Attribut dari suatu entitas secara umum adalah persistent; attribut tersebut tetap berada di luar ketika sistem sedang berjalan (Whitten & Bentley, 2007:649).
2.9.5 System Classes
System classes adalah object class yang menangani fungsionalitas tertentu dari suatu sistem operasi. Jika sistem dipindahkan ke sistem operasi lain, hanya system classes dan mungkin interface classes yang harus diubah (Whitten & Bentley, 2007:649).
2.9.6 Design Relationships
Dalam object oriented design, terdapat relationship lanjut yang digunakan untuk menspesifikasikan komponen software secara akurat (Whitten & Bentley, 2007:650). Relationship tersebut adalah:
1. Dependency Relationships
Dependency relationship digunakan untuk menggambarkan asosiasi antara dua class dalam dua contoh. Pertama, untuk mengindikasikan ketika terjadi perubahan pada satu class, perubahan itu akan mempengaruhi class lain. Kedua, untuk mengindikasikan asosiasi antara persistent class dan transient class. Dependency relationship diilustrasikan dengan garis panah putus-putus.
Gambar 2.42 Contoh Dependency Relationships pada Object Oriented Design
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:650)
2. Navigability
Secara umum asosiasi antara dua class adalah dua arah; masing-masing class dapat saling mengirimkan pesan. Navigability digunakan untuk membatasi arah pengiriman pesan menjadi satu arah saja. Navigability diilustrasikan dengan tanda panah pada arah pesan yang dikirim.
Gambar 2.43 Contoh Navigability pada Object Oriented Design (Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:650)
2.9.7 Attribute dan Method Visibility
Visibility adalah tingkat akses dari suatu objek eksternal yang mempunyai attribute atau method (Whitten & Bentley, 2007:650). Terdapat tiga tingkat visibility, yaitu:
1. Public
Sebuah attribute dan method public pada suatu class dapat diakses dan dipanggil oleh method pada class yang berbeda. Public visibility dinotasikan dengan simbol +.
2. Protected
Sebuah attribute dan method protected pada suatu class dapat diakses dan dipanggil oleh method dalam classnya sendiri atau pada subclass dari class tersebut. Protected visibility dinotasikan dengan simbol #.
3. Private
Sebuah attribute dan method private pada suatu class hanya dapat diakses dan dipanggil oleh method pada class itu sendiri.
Gambar 2.44 Contoh Visibility pada Object Oriented Design
(Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:651)
2.10 Software Testing
Software testing bertujuan untuk menemukan kesalahan. Sebuah tes yang bagus adalah tes yang memiliki kemampuan yang tinggi dalam menemukan kesalahan. Sebuah software dapat dites dengan 2 cara (Pressman, 2015:497-499), yaitu:
1. Tes dilakukan oleh seorang yang mengetahui fungsi produk sesuai dengan yang dirancang (Black Box Testing)
2. Tes dilakukan oleh seorang yang mengetahui proses kerja internal sebuah produk (White Box Testing)
2.10.1 White Box Testing
Testing white box, yang disebut juga sebagai testing glass box atau testing structural, adalah filosofi desain kasus uji yang menggunakan struktur kendali sebagai bagian dari desain komponen untuk memperoleh kasus uji. Dengan menggunakan metode white box, maka kasus uji dapat berupa (Pressman, 2015:500): 1. Memastikan semua jalur pada modul yang bersangkutan telah dicoba minimal
sekali
2. Mencoba semua keputusan logika baik dalam nilai benar maupun salah
3. Menjalankan semua perulangan yang ada dalam cakupan dan cakupan operasionalnya
4. Memastikan kebenaran dari semua struktur data internal
2.10.2 Black Box Testing
Testing black box, yang disebut juga sebagai testing behavioral atau testing functional, berfokus pada kebutuhan fungsional dari software yang dirancang. Testing black box mencari kesalahan dalam kategori (Pressman, 2015:509):
1. Kesalahan atau kehilangan fungsi 2. Kesalahan interface
3. Kesalahan dalam struktur data atau akses data eksternal 4. Kesalahan tingkah laku atau performa
5. Kesalahan inisialisasi dan penghentian
Jika testing white box dilaksanakan pada awal proses percobaan, maka testing black box dilaksanakan pada tahap akhir percobaan.
2.11 Kinect
. Kinect merupakan sekumpulan teknologi yang membuat manusia dapat berinteraksi secara alami dengan komputer tanpa menggunakan alat perantara. Menurut Yang et. al. (2014:59), Kinect adalah kamera sensor gerakan 3D yang
melacak dan menafsirkan berbagai pergerakan dan gerakan tubuh. Kinect memungkinkan pengguna agar dapat berinteraksi dengan Xbox tanpa memerlukan controller game khusus, melalui Natural User interface yang menggunakan gerakan tubuh dan perintah suara (González-Jorge et. al., 2014:207). Sistem kerja pada Kinect menggunakan kamera yang dapat menangkap gambar kerangka (skeleton) dari pengguna dan motion sensor yang bertugas untuk mendeteksi gerakan. Kinect juga memiliki speech recognition yang dapat mengerti perintah lisan dan gesture recognition yang dapat mengikuti serta menangkap gerakan pengguna (microsoft.com, 2014).
2.12 File Based System
Menurut Connolly dan Begg (2015:55) file based system merupakan kumpulan dari program aplikasi yang menyediakan layanan kepada pengguna seperti pembuatan laporan. Setiap program mendefinisikan dan mengatur datanya masing-masing.
2.13 .NET Framework
.NET Framework adalah teknologi yang mendukung pembuatan aplikasi generasi mendatang dan layanan web XML. .NET Framework terdiri dari Common Language Runtime dan .NET Framework class library.
Common Language Runtime merupakan fondasi utama yang bekerja sebagai agen yang mengatur code pada saat eksekusi. Common Language Runtime bertanggung jawab menyediakan layanan-layanan penting seperti mengatur memory, thread execution, manajemen thread, eksekusi code, verifikasi terhadap keamanan code, kompilasi code, remoting, dan juga peningkatan keamanan. Common Language Runtime menggunakan prinsip code management. Code yang menggunakan runtime ini atau aplikasi yang menggunakan .NET Framework biasanya disebut sebagai managed code. Sedangkan code yang tidak menggunakan runtime tersebut atau aplikasi luar disebut unmanaged code. Adapun keuntungan yang diberikan common language runtime adalah seperti :
b. Kemampuan untuk menggunakan komponen yang dikembangkan pada bahasa lain
c. Menyediakan fitur seperti inheritance, interface, dan overloading untuk pemrograman berorientasi objek
d. Mendukung pembuatan aplikasi multithread e. Mendukung exception handling
f. Garbage collection
Class library merupakan kumpulan dari reuseable type dan berorientasikan objek. Class library digunakan untuk mengembangkan aplikasi mulai dari aplikasi command line sederhana sampai aplikasi graphical user interface (GUI), seperti Web Forms dan XML Web Services (msdn.microsoft.com,2014).
2.14 C#
C# merupakan bahasa pemrograman berorientasi objek yang memungkinkan developer untuk membangun berbagai macam aplikasi pada .NET Framework. Umumnya C# digunakan untuk membuat aplikasi Windows client, layanan web XML, aplikasi client-server, aplikasi database, dan lain-lain. C# mempunyai fitur yang tidak terdapat pada bahasa pemrograman Java seperti nullable value types, enumerations, delegates, lambda expressions dan direct memory access. C# mendukung generic method dan generic type, yang memberikan peningkatan keamanan tipe dan kinerja. Selain itu C# juga mendukung pembuatan custom iterator untuk digunakan pada kumpulan class (msdn.microsoft.com, 2014).
2.15 Windows Forms
Windows Forms adalah sebuah platform berbasis .NET Framework untuk pengembangan aplikasi Microsoft Windows. Framework ini berorientasi pada objek dan menggunakan sekumpulan class yang dapat membangun berbagai macam aplikasi Windows yang memiliki banyak fitur. Sebagai tambahan, Windows Forms dapat menjadi user interface lokal pada multi-tier distributed solution.
Sebuah form biasanya berbentuk persegi, digunakan untuk menampilkan informasi kepada pengguna dan menerima input dari pengguna. Windows Forms dapat berbentuk standar Windows, multiple document interface (MDI) Windows, dan dialog box. Cara yang paling mudah dalam merancang user interface pada form adalah dengan menaruh kontrol pada tampilan terdepan. Windows Forms merupakan sebuah objek yang mempunyai properti untuk mendefinisikan penampilannya, method untuk mendefinisikan tingkah lakunya, dan event untuk mendefinisikan interaksinya dengan pengguna (msdn.microsoft.com, 2014).
2.16 Windows Presentation Foundation
Windows Presentation Foundation (WPF) merupakan sistem presentasi generasi mendatang dalam membangun aplikasi client Windows dengan penampilan user experience yang mengagumkan. WPF dapat membuat berbagai macam aplikasi baik standalone maupun browser-hosted.
WPF tidak bergantung pada resolusi dan menggunakan mesin rendering yang berbasis vector. WPF menggunakan kumpulan dari fitur application-development seperti Extensible Application Markup Language (XAML), controls, data binding, layout, grafik 2D dan 3D, animasi, style, template, dokumen, media, teks, dan typography. WPF termasuk dalam Microsoft .NET Framework sehingga WPF masih dapat berhubungan dengan elemen dari .NET Framework (msdn.microsoft.com,2014).
2.17 Extensible Markup Language
XML atau eXtensible Markup Language adalah sebuah metalanguage (sebuah bahasa untuk mendeskripsikan bahasa lain) yang memperbolehkan desainer untuk membuat custom tag mereka sendiri yang tidak tersedia pada Hypertext Markup Language (HTML). XML telah menjadi standar de facto untuk komunikasi data dalam industri software. Beberapa analis mempercayai bahwa XML akan menjadi bahasa untuk membuat dan menyimpan dokumen, baik online maupun
