BAB 2 LANDASAN TEORI

Transkripsi

1 BAB 2 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 7

2 8 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).

3 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. 5. Prevent errors

4 10 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 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 tindakantindakan dalam mencapai suatu tujuan?

5 11 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

6 12 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 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.

7 13 Gambar 2.2 Tahap-tahap Metodologi Scrum (Sumber: 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 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.

8 Tim Pengembang Tim pengembang terdiri dari para profesional yang bekerja untuk menghasilkan tambahan potongan produk yang disebut juga inkremental 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 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 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.

9 15 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 (Sumber: Scrum and Xp From The Trenches, 2007:10)

10 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 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 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

11 17 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 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 halhal 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.

12 18 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)

13 19 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.

14 20 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.

15 21 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 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 (Sumber: Scrum and XP From The Trenches, 2007:61)

16 22 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 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 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.

17 23 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).

18 24 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

19 25 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) 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).

20 26 Gambar 2.10 Contoh Activity Diagram (Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:393)

21 27 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.

22 28 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.

23 29 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.

24 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: 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

25 31 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) 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 (Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:247)

26 32 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 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.

27 33 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.

28 34 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 (Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:249)

29 35 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:

30 36 Gambar 2.26 Contoh Inheritance pada Use Case Diagram (Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:250) 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.

31 37 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.

32 38 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 bagianbagian 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.

33 39 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.

34 40 Gambar 2.28 Contoh Use Case Narrative (Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007: )

35 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

36 42 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 (Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:404)

37 43 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.

38 44 Gambar 2.31 Contoh Class Diagram (Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:406)

39 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.

40 46 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 putusputus 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)

41 47 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 (Sumber: Systems Analysis & Design Methods, Whitten & Bentley, 2007:662)

42 48 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.

43 49 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.

44 50 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) 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).

45 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 Control Classes Control classes adalah object class yang mengandung logika aplikasi. Contoh logika aplikasi adalah business rule dan kalkulasi-kalkulasi yang melibatkan entitasentitas object class. Control classes mengoordinasikan pesan-pesan antara interface classes dan entity classes dan urutan dari pesan yang terjadi (Whitten & Bentley, 2007:649) 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) 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).