Apabila penelitian sudah sampai tinjauan pustaka, kemudian akan memastikan bahwa metode penelitian yang dilakukan sudah benar, maka perlu validasi riset. Langkah apa sajakah yang dilakukan dalam validasi ini? Silakan simak video berikut.
[embedyt] https://www.youtube.com/watch?v=UAUDMoqdUfg[/embedyt]
[embedyt] https://www.youtube.com/watch?v=qmI6Lp8uOr4[/embedyt]
Aplikasi pembelajaran bagi anak usia dibawah usia remaja tentunya mempunyai kebutuhan khusus. Oleh karenanya, pengembangan aplikasinya pun mempunyai cara tertentu agar kebutuhan dalam penyajian aplikasi dapat dipenuhi. Seperti apakah itu? Silakan simak pada video meetup edisi bulan Maret di atas.
[embedyt] https://www.youtube.com/watch?v=X2NDIva9a2k[/embedyt]
Pada meetup edisi Januari 2021, dibahas serba-serbi mengenai metode penelitian.
Pandemi COVID-19 yang telah berlangsung sejak bulan Maret 2020 memberi dampak pada kegiatan sehari-hari masyarakat. Beberapa diantaranya adalah masyarakat harus mematuhi peraturan untuk menghindari kegiatan di luar rumah untuk mengurangi risiko penularan virus yang tinggi. Karena hal tersebut, masyarakat disarankan untuk bisa bekerja dan belajar dari rumah atau sering dikenal dengan istilah Work From Home. Hal ini juga berdampak pada tren pelaksanaan acara yang tadinya bersifat luring bergeser menjadi bersifat daring.
Sebuah acara tentunya membutuhkan dokumentasi dan pengarsipan yang cukup kompleks. Proses dalam sebuah acara didalamnya tentu perlu memerhatikan proses sebelum dan sesudah acara yang harus dilakukan. Proses pra-acara misalnya adalah membuat acara, menyebarkan informasi acara, memberikan notifikasi pelaksanaan acara, pendaftaran dan pembayaran acara. Sedangkan proses pasca-acara meliputi memberikan umpan balik untuk pihak penyelenggara, pengambilan data peserta yang telah hadir dengan indikator peserta mengisi umpan balik. Sekaligus dapat memanfaatkan data peserta tersebut untuk kebutuhan lain seperti menyebarkan e-certificate dan materi. Kedua proses itu tentunya diharapkan dapat dilakukan pada satu sistem atau dapat disebut dengan istilah all-in-one solution. Dimana kedua proses tersebut dapat dikelola secara terintegrasi sehingga akan memudahkan kedua peran dalam acara, yakni peserta dan penyelenggara acara.
Untuk menjawab permasalahan tersebut, perlu adanya sistem terintegrasi yang dapat memfasilitasi pengelolaan acara. Online Event Management System (OEMS) dikembangkan untuk memfasilitasi penyelenggara dan peserta acara utamanya untuk acara yang bersifat daring. Perancangan desain antarmuka website OEMS dengan metode Design Thinking. Proses perancangan dimulai dengan mengumpulkan requirement yang didapatkan melalui wawancara dengan calon pengguna dengan kriteria peserta dan penyelenggara acara yang bersifat daring. Setelah proses pengumpulan requirement, langkah selanjutnya adalah mengelompokkan requirement tersebut dan menentukan solusi yang tepat bagi setiap requirement yang telah dibuat sebelumnya. Solusi tersebut kemudian dibuat menjadi desain prototipe. Setelah desain prototipe berhasil dibuat, maka perlu adanya pengujian yang dilakukan dengan metode usability testing dan pengisian assessment System Usability Scale (SUS) untuk mengukur kebergunaan desain antarmuka dari sistem OEMS. Pengujian dilakukan dengan kedua kelompok calon pengguna, yakni peserta dan penyelenggara acara. Setelah dilakukan pengujian, hasil yang didapatkan adalah seluruh tugas yang diberikan saat usability testing berhasil dilakukan. Skor hasil pengisian SUS pun mencapai hasil 89 atau pada skor B (Excellent) dari sisi peserta dan 73 atau pada skor C (Good) dari sisi penyelenggara. Kedua hasil tersebut menunjukkan bahwa desain yang telah dibuat layak untuk bisa diimplementasikan pada website OEMS.
Langkah selanjutnya adalah proses pengembangan website dilakukan dengan bantuan metode Scrum sebagai Software Development Life Cycle. Pengembangan website dimulai dengan membuat product backlog yang berisi detail kebutuhan-kebutuhan serta target yang perlu dicapai dalam waktu tertentu. Kebutuhan tersebut dituangkan dalam bentuk dokumen yang dinamakan Product Requirement Document (PRD) yang berisi user story dari tiap-tiap fitur. Setelah Product Backlog selesai dibuat, maka tahap selanjutnya adalah melakukan sprint planning untuk menentukan product backlog apa saja yang perlu dilakukan dalam satu sprint. Hasil dari sprint planning ini berupa sprint backlog. Selama melakukan sprint dilakukan daily scrum untuk memberikan update tugas setiap harinya, sprint review dan retrospective untuk melakukan evaluasi. untuk Dalam pengembangan aplikasi front-end dan back-end menggunakan teknologi ASP.NET Core dengan model rangka kerja pengembangan aplikasi yang dipilih adalah Model View Controller (MVC).
Hasil dari pengembangan terdiri dari dua bagian fitur utama yakni dari segi pra dan pasca acara. Pada bagian pra-acara, dari sisi admin dan penyelenggara dapat memembuat, dan mengedit acara sedangkan dari sisi peserta dapat mendaftar dan melakukan pembayaran. Untuk pasca-acara, admin atau penyelenggara dapat mengunduh daftar peserta dan hasil umpan balik yang telah ditulis oleh peserta. Pada sisi peserta, bagian pasca-acara dapat mengisi formulir umpan balik bagi penyelenggara.
Selain fitur utama dalam alur penyelenggaraan acara, juga terdapat fitur pendukung seperti pendaftaran akun dan login untuk masuk ke dalam sistem, melihat event baik yang diadakan maupun yang akan diikuti. Peserta juga dapat mengunduh event calendar yang nantinya dapat dipasang reminder di ponsel pengguna. Pada sisi admin, juga terdapat fitur untuk mengelola profil dan role bagi penyelenggara.
Setelah hasil pengembangan website selesai dilakukan kemudian dilakukan pengujian Blackbox Testing untuk menguji fungsionalitas dari website OEMS. Hasil yang didapatkan adalah dari 26 poin test case untuk peserta dan 50 poin test case untuk penyelenggara seluruhnya dinyatakan lulus tahap pengujian. Kemudian untuk pengujian sistem back-end dilakukan melalui dua proses, yaitu validasi dan verifikasi. Proses validasi dilakukan untuk mengukur waktu yang dibutuhkan sistem dalam mengakses sebuah resource dari aplikasi, sedangkan verifikasi digunakan untuk melihat apakah program yang dibangun telah memenuhi spesifikasi kebutuhan sistem yang sebelumnya telah dirancang. Hasil yang didapatkan adalah rata-rata response time mencapai 370,2ms. Hal ini menunjukkan bahwa performa response time dari aplikasi OEMS masuk dalam kategori di atas rata-rata (539ms). Berdasarkan hasil pengujian tersebut maka dapat disimpulkan sistem OEMS pada tahap pengembangan pertama sudah layak untuk dipakai dan dikembangkan lebih lanjut kedepannya.
Dalam proses pengembangan OEMS, penulis menyadari adanya kekurangan yang dapat diperbaiki maupun dikembangkan untuk tahap selanjutnya. Oleh karena itu, kami juga memberikan saran seperti:
1. Pengembangan front-end dengan responsivitas layout yang lebih baik agar dapat digunakan pada berbagai macam ukuran layar browser. Selain itu juga menambah variasi warna untuk desain antarmuka.
2. Fitur generate certificate yang dapat dilakukan langsung di sistem OEMS dan dapat menghasilkan id tertentu agar dapat dibuktikan keasliannya serta dapat diintegrasikan dengan Linkedin atau platform serupa.
—
Peneliti : Ridwan Afwan, Nadia Jasmine, Ridi Ferdiana, Silmi Fauziati
Tahun: 2021
Proses pengembangan aplikasi dalam lingkup kerangka kerja Agile membutuhkan pendefinisian produk secara cepat dan iteratif untuk mengembangkan produk secara berkala. Proses Requirement Elicitation dalam pengembangan produk merupakan proses penting dalam desain produk yang dilaksanakan oleh Product Manager dengan klien. Untuk menghasilkan perkembangan yang dilakukan secara iteratif, proses Requirement Elicitation perlu dilakukan secara rutin sesuai dengan durasi sprint pada metodologi Agile dalam bentuk meeting antara Product Manager dengan klien. Perkembangan yang terjadi pada setiap iterasi perlu didefinisikan secara jelas dan ringkas untuk dapat didokumentasikan menggunakan aplikasi development tools untuk mencatat perkembangan dan pembagian kerja secara tepat waktu dalam mengembangkan aplikasi sesuai dengan kebutuhan klien. Dalam lingkungan Agile, biasanya analis/Product Manager akan mendeskripsikan kebutuhan pengguna ke dalam daftar user story. User story ini mendeskripsikan kebutuhan-kebutuhan apa saja yang dimiliki oleh sistem.
Percakapan yang terjadi pada saat diskusi dalam sebuah meeting antara Product Manager dengan klien tidak akan selalu berjalan secara lancar. Pada umumnya, terdapat kesenjangan pemahaman ataupun pola bahasa yang digunakan oleh klien dengan Product Manager sehingga muncul kebutuhan yang dapat diatasi oleh penengah berupa aplikasi otomatis yang mendeteksi user story berdasarkan pola-pola yang muncul dari pembicaraan kedua belah pihak. Selain itu, permasalahan yang juga sering terjadi adalah ketidaklengkapan user story yang dihasilkan oleh Product Manager atau analis. Masalah-masalah ini tentu dapat menyebabkan produk atau output dari proyek pengembangan yang dilakukan tidak sesuai dan banyak kebutuhan pengguna yang tidak ikut disertakan oleh tim pengembang aplikasi.
Penyusunan user story didasarkan pada format Connextra yang dipopulerkan oleh Mike Cohn. Format Connetra merupakan user story yang tersusun atas 3R berupa role, requirement, reason dengan contoh pola kalimat statik seperti berikut:
“As a <Role> , I want to <Requirement>, so that I <Reason>.”
Menggunakan format yang dipopulerkan oleh Mike Cohn tersebut, program akan menyeleksi kalimat masukan dan menyesuaikan masukan semirip mungkin dengan format Connextra. Role sebagai masukan peran pengguna tidak selalu diutarakan dalam percakapan dengan klien sehingga perlu ditentukan secara manual. Kemudian, Requirement muncul pada saat klien mengutarakan keinginan atau kebutuhan dalam percakapan sehingga dapat dilacak klasifikasinya menggunakan keyword analysis. Reason pada percakapan muncul setelah pengutaraan modal verb diucapkan oleh pengguna sehingga membagi kalimat yang berpotensi menjadi user story menjadi dua komponen klausa.
Pengumpulan dataset dilakukan pada golongan Product Manager berpengalaman yang dapat mensimulasikan meeting Requirement, dengan menggunakan bahasa Inggris. Product Manager terkait kemudian memberikan hasil user story yang valid dari transkrip meeting sebagai tolok ukur yang dapat dibandingkan dengan keluaran akurasi. Rekaman meeting disimpan dalam format .wav sebagai bentuk format yang dapat dikerjakan oleh API Speech to Text.
Pengolahan dataset dimulai dengan cara mengakomodasi artefak rekaman supaya dapat diproses oleh program Java, API Azure Cognitive Service, dan aplikasi pengolah file Excel. Artefak rekaman meeting pada umumnya berukuran sekitar 120 MB, dengan durasi sekitar 10 menit, sehingga perlu dikenakan kompresi file menggunakan Audacity untuk mengecilkan bitrate file audio dari 32 kHz menjadi 8 kHz dengan hasil kompresi file dari ukuran semula sebesar 75%. Kemudian program Java diberikan konfigurasi pada file ‘application.properties’ supaya Servlet dapat mengakomodasi file hingga ukuran maksimal yaitu <100 MB. Artefak rekaman meeting kemudian diproses menggunakan API Azure Cognitive Services Speech to Text untuk menghasilkan transkripsi teks yang dapat diolah menggunakan punctuation dan sentence splitter. Untuk setiap kalimat yang dikembalikan oleh API menggunakan listener pada method startContinuousRecognitionAsync(), aplikasi akan menjalankan algoritma generasi user story yang mendeteksi penekanan kata kunci atau keyword analysis dari kata “want” dan “need” untuk mengenerasi user story. Penekanan kata “want, need” ditentukan sesuai dengan format Connextra yang mencontohkan format menggunakan “want” atau “need” pada kalimat user story. Jika kata “want, need” terdeteksi, maka program akan menjalankan fungsi yang disediakan oleh java.lang.String.split() untuk mencari modal verb untuk membagi kalimat menjadi dua klausa yang dibagi berdasarkan posisi modal verb. Kedua klausa tersebut akan dicakup oleh dua ArrayList yang kemudian disusun ulang menjadi user story yang mana hasil basis data dapat dikonversi menjadi file Excel menggunakan Apache POI HSSF.
Uji akurasi transkripsi menggunakan pendekatan Word Error Rate (WER). WER merupakan pendekatan standar yang digunakan untuk mengevaluasi sistem large vocabulary continuous speech recognition (LVCSR). Pendekatan ini memperhitungkan total pergantian kata (s), penambahan kata (i), pengurangan kata (d), dan total kata sebenarnya pada audio (n).
WER yang bernilai 5-10% tergolong memiliki kualitas yang cukup baik dan layak untuk digunakan dan WER yang berada diatas 20% masih harus membutuhkan training tambahan.
Kesimpulan pertama dari uji akurasi ini adalah nilai WER yang dihasilkan dari keempat pengujian tergolong baik dan layak digunakan sebagai transkrip untuk diolah menjadi kandidat-kandidat user story.
Pengujian akurasi kandidat user story dilakukan dengan membandingkan output yang dihasilkan sistem dan user story yang dihasilkan langsung dari partisipan atau product manager. Dari hasil ringkasan didapat bahwa rata-rata akurasi kandidat user story yang dihasilkan dari pengujian ini memiliki nilai 76.17%.
Beberapa user story yang tidak berhasil dihasilkan sistem dikarenakan terdapat kesimpulan-kesimpulan secara tersirat yang didapatkan oleh partisipan, klien tidak secara eksplisit
mengatakannya, atau klien tidak menggunakan kata-kata yang menjelaskan keinginannya menggunakan kata want atau need. Beberapa output yang dihasilkan sistem bukan merupakan
kandidat user story yang dapat digunakan oleh pengguna. Namun karena penggunaan kata want yang diucapkan oleh klien, sistem otomatis mengambil dan mengira bahwa kalimat tersebut dapat digunakan sebagai kandidat user story. Kesalahan-kesalahan dari kandidat user story seperti ini dapat dengan mudah diabaikan oleh pengguna, sehingga pengguna disarankan hanya mengambil kandidat user story yang cukup relevan untuk digunakan dalam proses pengembangan produk mereka. Nilai akurasi yang dihasilkan dari pengujian ini terbilang cukup untuk pengembangan pertama dan dapat dikembangkan lebih lanjut kedepannya.
Pembentukan user story dari meeting yang dilakukan pada proses Requirement Elicitation dalam metodologi Agile dapat diotomatisasi menggunakan aplikasi pembangkit user story, Aplikasi tersebut menggunakan algoritma yang didasarkan pada keyword analysis yang memberikan penekanan pada keinginan atau kebutuhan pengguna dan modal verb untuk membentuk user story sesuai dengan format Connextra.
Penulis juga menyadari dalam proses dan hasil implementasi masih terdapat beberapa penyempurnaan yang dapat dikembangkan seperti:
Peneliti: Meilisa H. Narpati Nadi, Ridi Ferdiana, Selo
Tahun 2021
Dalam mengembangkan perangkat lunak dilakukan oleh software development team, langkah awal yang dilakukan tim adalah mengidentifikasi scope dan vision dimana didalamnya termasuk planning, definisi tujuan dan inti proyek, dan persetujuan formal terkait proyek. Setelah itu tim akan mengidentifikasi kebutuhan dari user yang akan digunakan sebagai dasar pengembangan sistem, hasil identifikasi akan diperoleh apakah perangkat lunak merupakan sistem informasi konvensional atau membutuhkan machine learning. Proses ini membutuhkan waktu yang panjang dan detail, karena terdapat perbedaan alur pengembangan jika proyek merupakan pengembangan yang membutuhkan machine learning.
Oleh karena itu dalam mengidentifikasi membutuhkan requirement specialist yang memahami karakteristik kebutuhan user, akan tetapi tidak semua tim memiliki requirement specialist sehingga proses identifikasi requirement berdasarkan knowledge dan subyektifitas dari analyst atau project manager. Hal ini inkonsistensi karena tidak terdapat landasan yang pasti dan membutuhkan proses panjang dari inception untuk mendapatkan definisi kebutuhan yang diinginkan user tentu saja hal ini tidak efisien untuk kinerja software development team.
Faktanya requirement dalam pengembangan perangkat lunak berbasis ML maupun sistem informasi konvensional memiliki perbedaan pada user story yang dihasilkan. Fitur atau goals yang diinginkan user pada user story dapat dijadikan kata kunci pembeda dalam melakukan proses klasifikasi jenis proyek, kata kunci ini dapat diketahui dengan penggunaan text mining yaitu klasifikasi teks.
Dalam memilih model yang tepat literatur review telah dilakukan, dan diperoleh model deep learning memiliki hasil akurasi yang cukup bagus dalam melakukan klasifikasi teks. Sehingga penelitian ini menggunakan deep learning LSTM dan GRU. Alasan pemilihan LSTM adalah dari hasil literatur model deep learning dalam klasifikasi teks, LSTM memperoleh akurasi diatas 80%. Sedangkan pemilihan GRU untuk menjadi pembanding, karena GRU memiliki arsitektur yang lebih efiisen dibandingkan LSTM. Apakah efisiensi struktur membuat akurasi lebih tinggi atau tidak. Permasalahan utama adalah dataset user story, dataset ini cukup krusial dan tidak sembarang dipublish sehingga alternatif cara adalah melakukan survey dengan teknik think aloud dan jutifikasi expert untuk menghindari bias.Dari hasil survey diperoleh 500 user story dengan 250 user story machine learning dan 25 user story sistem informasi konvensional. Dari user story yang diperoleh dikumpulkan kata kunci 60 untuk kebutuhan machine learning dan 60 kata kunci untuk kebutuhan sistem informasi biasa.
Penelitian ini berhasil membuktikan bahwa model deep learning dapat digunakan sebagai salah satu cara untuk efisiensi kinerja software development team, selain itu user story ternyata dapat digunakan dalam mengklasifikasikan kebutuhan machine learning dan non machine learning. Akurasi yang diperoleh dari model LSTM juga cukup baik yaitu sekitar 96%.
Reference : Peneliti : Irdina Wanda Syahputri, Ridi Ferdiana, Sri Suning Kusumawardani
Tahun : 2021
