BAB 3
PELAKSANAAN KERJA MAGANG
3.1 Kedudukan dan Organisasi
Penulis berkedudukan sebagai Software Engineer yang bekerja pada Full Stack Development yang disupervisi oleh Mohamad Toufik yang menjabat seba- gai Direktur Finansial. Penulis berkoordinasi dan berkomunikasi dengan Direk- tur lainnya, yakni adalah Direktur Pemasaran dan Direktur Utama, untuk menen- tukan aplikasi yang akan dibuat serta perencanaan dari aplikasi tersebut. Selain berkomunikasi dengan Direktur, penulis juga berkomunikasi dan berdiskusi dengan karyawan-karyawan yang ada di kantor mengenai permasalahan yang ada, serta apa yang dapat dilakukan untuk menyelesaikan permasalahan tersebut. Setelah menda- patkan persetujuan dari seluruh karyawan kantor dan Direktur, dilaksanakan perte- muan atau meeting bersama agar semua pihak memahami aplikasi yang akan dibuat.
Setelah pertemuan selesai, penulis langsung melakukan aktivitas coding un- tuk merealisasikan sistem atau aplikasi yang sudah direncakan sebelumnya. Se- lama pengerjaan aplikasi, penulis bekerja secara hybrid, dan penulis melaporkan progress secara berkala. Setelah aplikasi selesai dibangun, penulis memberikan aplikasi kepada kantor serta memberikan pelatihan kepada karyawan yang ada di kantor, sekaligus melakukan fase beta-testing. Apabila ada fitur tambahan yang di- inginkan atau apabila ada bug, penulis akan memperbaikinya dan mengulangi fase beta-testingdan pengujian dari awal, sampai aplikasi menyenangkan kepada semua pihak.
3.2 Tugas yang Dilakukan
Penulis adalah mengerjakan semua tugas yang diberikan pada saat proses kerja magang secara mandiri, teratur, dan terstruktur. Penulis mengerjakan seluruh bagian, mulai dari front-end, back-end, mobile, sampai pada tahap deployment (full- stack developer). Selama proses kerja magang, tugas yang diberikan kepada penulis terbagi menjadi tiga buah tugas, yakni adalah sebagai berikut:
• Pembuatan aplikasi berbasis mobile yang dinamakan Operational Business Dashboard;
• Pembuatan progressive web application yang dinamakan Skifindo Database:
Full Stack; dan
• Melakukan pemrograman Python, Node.js, dan Shell untuk melakukan utility scriptingdan migrasi data dari Ms. Excel ke MongoDB.
Operational Business Dashboard adalah sebuah aplikasi berbasis mobile yang digunakan untuk mengecek dan mengawasi alur dari keluar masuknya barang dalam perusahaan. Aplikasi yang dibuat sengaja dibuat berbasis mobile agar dapat diakses di mana pun dan kapan pun. Karena faktor pembuatan yang menggunakan aplikasi mobile, pertimbangan utama dari aplikasi adalah faktor kecepatan, efisiensi, data, dan tampilan yang menarik.
Aplikasi ini sendiri memiliki beberapa fitur, yakni adalah sales, untuk meli- hat dan melakukan investigasi terhadap keluarnya barang dari perusahaan untuk dijual kepada pelanggan. Fitur orders, yang mana digunakan untuk melihat arus masuknya barang ke perusahaan, atau dalam artian di bagian ini, perusahaan yang membeli barang. Selain itu, ada pula fitur stock notification, atau dikenal juga de- ngan nama restock, yang berisi inventaris barang kantor yang kurang yang harus segera dibeli kepada pihak penyuplai. Adapula fitur health checker, yang mana se- tiap orang dapat melihat data kondisi keuangan sampai pada hari aplikasi tersebut dibuka. Pengguna juga dapat mengakses sistem basis data / PWA yang dibuat pada proyek kedua (Skifindo Database: Full-Stack) melalui aplikasi ini. Fitur lain yang ada dalam aplikasi ini adalah clean, yang berfungsi untuk melakukan pembersihan atas cache yang ada selama penggunaan aplikasi.
Skifindo Database: Full Stackadalah sebuah situs yang bersifat progressive web application, dalam artian memiliki front-end, back-end, dan memiliki kom- patibilitas untuk digunakan secara native pada telepon pintar. Aplikasi digunakan untuk mengelola dan melakukan manajemen dari inventaris dan transaksi stok dari perusahaan. Manajemen inventaris yang dimaksud disini adalah kemampuan untuk melakukan operasi data pada entitas transaksi dan entitas stok secara praktis dan cepat. Aplikasi juga memiliki kemampuan untuk berganti tema, dari mode gelap menjadi mode terang, dan sebaliknya. Aplikasi dibuat dengan cara pemrograman berbasis API, yang berarti front-end dan back-end dari aplikasi dibuat secara ter- pisah untuk separation of concerns dan kemudahan perawatan di masa mendatang.
Aplikasi dilindungi dengan sistem autentikasi berbasis token yang dilengkapi de- ngan access / user control roles yang dapat dibilang modern pada tanggal penulisan laporan ini, yakni adalah JSON Web Tokens.
Proyek untuk melakukan scripting dilakukan dengan cara menggunakan ba- hasa pemrograman Python untuk melakukan migrasi dari data jenis CSV men- jadi data bentuk JSON untuk dapat dipindahkan kedalam MongoDB. Data tersebut merupakan perpindahan dari sistem basis data yang lama yang sudah dimiliki oleh perusahaan sebelumnya. Proses coding pada saat pembuatan aplikasi dan bahasa yang digunakan dalam aplikasi seluruhnya dilakukan dalam bahasa Inggris.
3.3 Uraian Pelaksanaan Magang
Uraian pelaksanaan kerja magang akan dijelaskan setiap proyek, dalam ar- tian akan dijelaskan proyek secara detail, serta diberikan informasi mengenai ar- sitektur sistem dengan diagram ERD, diagram DFD, diagram use-case, diagram alir (flowchart), cara kerja, tangkapan layar dari aplikasi (jika ada), dan teknologi yang digunakan untuk pembuatan aplikasi. Secara detail, kegiatan setiap minggu dari seluruh kegiatan dari kerja magang diuraikan seperti pada Tabel 3.1.
Tabel 3.1. Pekerjaan selama magang
Minggu Kegiatan
1 - Penerimaan untuk bekerja di perusahaan.
- Pencarian kebutuhan dan mengetahui pekerjaan atau aplikasi apa yang dibutuhkan oleh perusahaan.
- Pembuatan catatan/dokumentasi untuk melakukan proyek per- tama, yakni adalah melakukan migrasi dari sistem basis data yang lama.
- Pembuatan catatan dan dokumentasi untuk melakukan proyek ke- dua, yakni adalah membuat aplikasi mobile business dashboard.
2 - Pembuatan back-end dari API dengan menggunakan Express.js.
- Mengintegrasikan sistem basis data MongoDB Atlas sebagai sis- tem basis data utama dalam back-end yang akan dibuat.
- Dalam pembuatan back-end sudah dilengkapi dengan utilities seperti error handling, asynchronous try-catch, invalid routes, planned routes, serta method not found routes.
3 - Pembuatan migrasi basis data akan ditunda terlebih dahulu menu- rut pembimbing lapangan.
- Pembuatan desain dan mockup untuk aplikasi mobile business dashboard dengan menggunakan Android Studio.
- Pembuatan fungsionalitas dasar dari aplikasi mobile dengan Kotlin.
Tabel 3.1. Pekerjaan selama magang (lanjutan)
Minggu Kegiatan
- Mengintegrasikan Firebase Firestore dan Firebase Cloud Storage pada aplikasi.
- Mengimplementasikan fitur Kamera dan image compression pada aplikasi.
4 - Mengimplementasikan fitur untuk menambahkan fitur orders dan menambahkan fitur sales pada aplikasi yang telah dibuat.
- Mengimplementasikan fitur untuk propagasi data sesuai dengan kategori yang diinginkan, baik orders maupun sales.
- Mengintegrasikan autentikasi dengan teknologi Firebase Authen- tication.
- Menulis dokumentasi tentang aplikasi yang telah dibuat dan melakukan integration testing agar aplikasi berjalan dengan sem- purna.
5 - Memberikan training kepada orang-orang kantor tentang aplikasi mobileyang sudah dibuat.
- Melakukan bug-fixing, beta-testing, serta menambahkan fitur baru yang diminta, yakni adalah stock notification.
- Melakukan build application dan mendistribusikannya kepada karyawan.
- Melakukan finalisasi beta-testing dan menyelesaikan proyek se- cara sempurna.
6 - Melanjutkan proses pengerjaan dari proyek kedua, yakni Skifindo Database.
- Mengimplementasikan entitas yang ada dalam perangkat lunak tersebut (pengguna, inventaris, dan transaksi) pada back-end.
- Mengimplementasikan fitur Create, Read, Update, Delete untuk setiap entitas yang relevan.
7 - Mengimplementasikan autentikasi dengan menggunakan JSON Web Tokens.
- Melengkapi pengembangan sistem dengan GitHub Actions, Post- man, dan Heroku.
- Meningkatkan keamanan dari API dengan menggunakan middle- waresyang ada dalam Express.js dan pengamanan lainnya.
8 - Merancang dan membuat mock up dari front-end aplikasi.
- Melakukan riset tentang PWA dan cara mengimplementasikan- nya.
- Menyambungkan antara back-end dan front-end dari aplikasi yang telah dibuat.
9 - Melakukan perancangan front-end aplikasi dari awal hingga sele- sai menggunakan React dan TypeScript.
- Mengintegrasikan service worker agar aplikasi menjadi PWA.
Tabel 3.1. Pekerjaan selama magang (lanjutan)
Minggu Kegiatan
- Menambahkan fitur baru pada proyek pertama untuk dapat bisa mengakses proyek kedua.
- Melakukan deployment pada Heroku.
- Melakukan pembetulan galat.
10 - Melakukan user acceptance testing, revisi, serta melakukan pelatihan kepada orang-orang yang ada di kantor.
- Melakukan migrasi data dari Ms. Excel (CSV) ke MongoDB dengan menggunakan Python.
- Melakukan scripting untuk melakukan ping secara periodik dan melakukan backup data menggunakan Node.js dan Shell.
- Melakukan pembetulan galat.
11 - Melanjutkan migrasi data secara sempurna pada sistem basis data MongoDB milik perusahaan.
- Melakukan finalisasi pada ketiga proyek yang dibuat.
- Melakukan deployment dan build application untuk rilis secara resmi.
3.3.1 Operational Business Dashboard
Uraian di bawah ini akan menjelaskan tentang proyek pertama yang dikerjakan oleh penulis.
A. Diagram Interaksi
Gambar 3.1 menunjukkan sebuah use-case diagram dari apli- kasi yang telah dibuat. Terlihat pada Gambar 3.1 ada tiga buah enti- tas, yakni adalah departemen finansial, departemen operasional dan pemasaran, serta direksi. Setiap departemen disini yang dimaksud adalah departemen atau entitas dalam perusahaan.
Gambar 3.1. Use-case diagram dari Operational Business Dashboard
Terlihat bahwa pekerjaan setiap entitas atau divisi sudah ter- lihat pada Gambar 3.1. Departemen finansial berfungsi untuk men- gonfirmasi data penjualan dan pembelian, departemen operasional atau pemasaran berfungsi untuk mengisi stok yang kosong untuk segera diisi kembali, serta memasukkan data pembelian dan pen- jualan. Direksi berfungsi untuk mengontrol operasional. Setiap pi- hak atau departemen dapat melakukan aktivitas yakni adalah melihat kondisi keuangan, mengontrol stok kosong, mengakses sistem ba- sis data (yang dibuat pada proyek kedua), serta membersihkan cache yang mungkin terdapat selama penggunaan aplikasi ini.
B. Diagram Alir Aplikasi
Diagram alir akan dibagi menjadi beberapa modul / proses bisnis yang esensial yang ada pada aplikasi, yakni sales, orders,
dan restock. Untuk modul clean, database, dan exit tidak dibuat dalam bentuk diagram alir karena prosesnya yang sangat singkat dan hanya melakukan sebuah aktivitas singleton. Sebelum melanjutkan ke dalam submodul, proses menu utama dijabarkan diagram alir pada Gambar 3.2.
Gambar 3.2. Diagram alir utama untuk proses aplikasi
Gambar 3.2 menjelaskan tentang proses utama dari aplikasi.
Ketika berada di dalam menu utama, seorang pengguna dapat men- gakses submodul yang ada di dalam aplikasi.
Gambar 3.3. Diagram alir untuk proses bisnis Sales
Pada Gambar 3.3, terlihat bahwa setiap kali pengguna men- coba melakukan input data, pengguna harus masuk ke dalam menu yang bersangkutan terlebih dahulu. Kemudian, pengguna wajib mengisi data secara benar, serta pengguna juga wajib mengambil gambar bukti transaksi, yang mana akan di-compress untuk keper- luan penyimpanan.
Apabila pengguna sudah mengisi data, maka status sales akan berpindah posisi menjadi in progress. Ketika sudah ada di posisi ini, pengguna dapat melakukan penggantian pada deskripsi.
Pengguna juga dapat melihat data dari penjualan tersebut secara de- tail. Ketika pengguna sudah yakin bahwa penjualan tersebut sudah terkirim dan atau konsumen sudah membayar down payment (sesuai dengan proses bisnis dan SOP perusahaan), maka penjualan terse- but akan berpindah status menjadi receivables. Dalam menu ini, pengguna hanya tinggal menunggu pembayaran dibayarkan, dan ke- mudian status dari penjualan tersebut dapat diubah menjadi finished.
Setiap masukan akan dilakukan input sanitization oleh back-end.
Gambar 3.4. Diagram alir untuk proses bisnis Orders
Pada Gambar 3.4, terlihat bahwa proses bisnis untuk mem- beli barang sangat mirip dengan proses bisnis untuk menjual barang.
Pada awalnya, pengguna dapat memilih untuk memasukkan pembe- lian baru pada sistem dengan mengisi data yang benar. Apabila data benar, data akan berpindah status menjadi in-progress. Apabila su- dah ada kejelasan mengenai barang dan apabila barang tersebut su- dah dikirim kepada perusahaan, status data tersebut akan berpindah menjadi payable. Arti dari status ini adalah berarti barang sudah sampai di perusahaan dan pembelian hanya perlu dibayar. Ketika su- dah dibayar, data akan berpindah menjadi status finished dan dapat dilihat pada riwayat yang terdapat pada aplikasi.
Gambar 3.5. Diagram alir untuk proses bisnis Restock
Pada Gambar 3.5, proses bisnis terlihat dengan cara mema- sukkan data stok atau inventaris yang perlu dilakukan pengisian ulang. Apabila data yang dimasukkan benar atau sahih, maka data akan berpindah menjadi status in-progress. Di saat di status inilah orang-orang dapat melihat dan memeriksa data inventaris yang perlu dilakukan pengisian atau pemesanan ulang. Ketika sebuah stok su- dah terisi ulang, maka data akan dihapus dari sistem basis data dan harus dilakukan pengisian data ulang apabila ada stok yang diper- lukan.
C. Diagram Relasi Entitas
Struktur dari sistem basis data yang digunakan pada aplikasi ini adalah sebagai berikut, terlampir pada Gambar 3.6.
Gambar 3.6. Basis data untuk Operational Business Dashboard
Pada dasarnya, sistem basis data memiliki tiga buah tabel utama, yakni adalah Sales, Orders, dan Restock. Tabel Sales dan Or- dersmenyimpan atribut data yang mirip, antara lain karakter identi- fikasi, tanggal dibuat dan tanggal selesai (dalam bentuk angka karena disimpan dalam bentuk waktu UNIX), status, total harga, nama pem- beli atau nama penyuplai, deskripsi, nomor faktur, dan foto faktur.
Untuk tabel Restock, atribut yang disimpan adalah karakter iden- tifikasi, tanggal diciptakan, deskripsi, serta nama stok yang perlu segera dibeli kembali.
Secara teknis, pembuatan nomor identifikasi untuk sistem basis data digunakan metode UUID dengan tipe UUID V4 karena memiliki algoritme generasi yang unik dan memiliki kemungkinan tabrakan yang sangat kecil, hingga mencapai kemungkinan 2.71 kuintiliun per pembuatan untuk mendapatkan duplikat [9], yang no- tabene merupakan angka yang sangat langka [10].
Untuk atribut yang berjudul ‘status’, implementasi di Fire- store adalah menggunakan tipe data ‘enum’ dan bukan membuat tabel baru untuk kenyamanan dan kemudahan penggunaan. Selu- ruh tabel merupakan tabel yang digunakan untuk menyimpan data dan integritasnya dijaga, dalam artian data tidak bisa dilakukan pem- baruan atau penghapusan tanpa izin, sesuai dengan permintaan pe- rusahaan.
D. Diagram Alir Data
Data-Flow Diagrampada pembuatan aplikasi ini akan dibagi menjadi dua, yakni adalah Context Diagram dan DFD Level 0.
Gambar 3.7. Diagram konteks
Terlihat bahwa diagram konteks sudah memberikan data yang dibutuhkan oleh aplikasi.
Gambar 3.8. Diagram alir data level 0
Gambar 3.7 dan 3.8 merupakan diagram alir data yang menje- laskan aliran data aplikasi ini. Ada tiga buah subsistem yang esensial dalam aplikasi ini, yakni adalah sales, orders, dan restock. Ada se- buah subsistem yang bernama authentication yang digunakan untuk menjelaskan aliran data untuk melakukan autentikasi bagi pengguna aplikasi. Data yang diberikan kepada subsistem umumnya adalah an- tara data baru atau modifikasi data untuk entitas tersebut. Data yang diberikan dari pangkalan data kepada subsistem umumnya adalah data yang relevan terhadap entitas tersebut, sesuai dengan kebutuhan.
E. Teknologi
Teknologi yang digunakan dalam pembuatan aplikasi opera- tional business dashboard ini adalah sebagai berikut:
• Bahasa pemrograman Kotlin;
• Android Studio sebagai IDE;
• Gradle sebagai dependency manager;
• Firebase Authentication sebagai authenticator dan penga- man untuk mengakses resource dalam aplikasi;
• Firebase Cloud Storage untuk menyimpan gambar yang ter- buat saat menggunakan aplikasi;
• Firebase Firestore Database untuk menyimpan data opera- sional perusahaan, seperti data penjualan dan pembelian barang; dan
• Git dan GitHub sebagai version control system untuk men- jaga agar kode sumber dari aplikasi tetap aman.
Bahasa pemrograman Kotlin digunakan sebagai bahasa utama dalam perancangan. Android Studio dan Gradle digunakan sebagai alat untuk melakukan dependency management dan untuk melakukan kompilasi dari kode sumber yang ada. Sistem basis data yang digunakan adalah Google Firebase, yang mana adalah back- end as a service yang memungkinkan orang-orang untuk menggu- nakan back-end yang sudah dibuat dan dirancang oleh Google. Ada- pun yang digunakan adalah Authentication (untuk melakukan ses- sion management), Cloud Storage (untuk menyimpan gambar), dan Firestore (untuk menyimpan data). Git dan GitHub digunakan un- tuk menjaga agar kode sumber selalu bisa dikembalikan ke bentuk sebelumnya, demi menjaga keamanan dan kenyamanan saat bekerja.
Dalam pembuatan aplikasi, selalu diusahakan untuk menggu- nakan best-practices yang diketahui oleh penulis, seperti konsep in- ternationalization, dependency updates, dokumentasi yang lengkap, dan lain sebagainya.
F. Alur Kerja
Alur kerja yang dilakukan adalah dengan cara melakukan metode Git-flow. Pada umumnya, metode ini berarti adalah selalu melakukan branching agar tidak mengganggu main branch dari kode sumber aplikasi. Seluruh pengerjaan dari aplikasi ini dikerjakan pada GitHub Organizationmiliki CV. Skifindo Integra Selaras.
Setiap kali penulis menambahkan fitur baru, yang dilakukan adalah melakukan checkout, kemudian melakukan coding untuk menyelesaikan fitur tersebut, lalu melakukan pull request pada repos- itori tersebut. Belum ada Continuous Integration / Continuous De- livery(CI/CD) yang dipasang pada repositori tersebut, yang menye- babkan kode sumber tidak bisa langsung dicek untuk permasalahan formatatau kesalahan lainnya (linting).
G. Implementasi
Berikut adalah tampilan awal dari aplikasi yang telah dibuat.
Tampilan awal diawali dengan splash screen, lalu kemudian akan berlanjut ke dalam authentication activity dimana aplikasi akan meminta kepada pengguna untuk mengisikan informasi autentikasi pada aplikasi.
Gambar 3.9. Autentikasi pada aplikasi
Apabila berhasil memasukkan kredensial dengan benar, yang muncul adalah menu seperti pada Gambar 3.10. Menu su- dah diberikan kode warna sesuai dengan permintaan perusahaan agar memudahkan perusahaan untuk mengetahui kegunaan masing- masing menu. Di bagian atas aplikasi, terdapat tampilan yang me- nunjukkan status kondisi keuangan perusahaan pada saat aplikasi ini dibuka, yang merupakan permintaan dari perusahaan.
(a) Menu utama (b) Lanjutan menu Gambar 3.10. Menu aplikasi
Ketika membuka menu sales, akan muncul barisan menu lagi yang memberikan informasi terkait mengenai masing-masing pen- jualan barang. Terlihat bahwa sudah ada new sale, in progress, receivables, dan finished. Apabila membuka menu orders, akan muncul barisan menu new orders, in progress, payables, dan fin- ished. Apabila membuka menu restock, akan muncul barisan menu new restock dan in progress. Yang ditampilkan di laporan ini adalah tampilan sales, serta tampilan form yang dapat diakses apabila mem- buka new sale.
Apabila membuka menu clean, yang dilakukan adalah apli- kasi membersikan cache yang ada selama penggunaan aplikasi.
Menu database berguna untuk mengakses sistem basis data atau pro- gressive web applicationyang dibuat pada proyek kedua. Menu exit digunakan untuk keluar dari aplikasi.
(a) Menu sales (b) Form sales baru Gambar 3.11. Menu sales pada aplikasi dan form
Gambar 3.12 adalah tampilan dari salah satu detail stok yang berada dalam status in progress. Dalam aplikasi, status terdiri dari in progress, receivables, dan finished. Umumnya, tampilan dari mereka sama, yang membedakan hanya status stok nya saja. Ketika salah satu objek ditekan, maka akan muncul detail stok yang mana tampilannya adalah seperti pada Gambar 3.12. Detail stok akan menampilkan nomor faktur, nama pelanggan, total harga, deskripsi penjualan, foto faktur, serta tanggal dibuat sesuai dengan diagram relasi entitas. Pada sisi di kiri atas, tertera status dari penjualan.
Gambar 3.12. Detail stok
Apabila pengguna mencoba mengakses menu seperti tampi- lan in progress, receivables / payables, atau finished, umumnya tampilan akan terlihat seperti Gambar 3.13, yang membedakan hanya kode warnanya saja yang mana memang sudah ditentukan oleh pe- rusahaan.
Gambar 3.13. Tampilan finished sales
Sebagai fitur tambahan pada aplikasi, ketika setiap kali se- lesai melakukan aksi apapun dalam aplikasi, akan muncul sebuah push notification yang kurang lebih akan memiliki tampilan seperti pada Gambar 3.14. Push notification ini digunakan agar pengguna bisa mendapatkan feedback selain melalui snackbar saja dalam apli- kasi, yang merupakan salah satu implementasi konsep dari desain rancangan antarmuka dan user experience yang baik.
Gambar 3.14. Contoh tampilan push notification
3.3.2 Skifindo Database Full Stack
Uraian di bawah ini akan menjelaskan tentang proyek kedua yang dikerjakan oleh penulis. Untuk proyek selanjutnya, penulis memanfaatkan Raspberry Pi yang dimiliki oleh CV. Skifindo Integra Selaras untuk berbagai keperluan, seperti membuat testing environment, cron scripts, dan sebagai alat untuk melakukan migrasi data di proyek ketiga, yang akan dijelaskan kemudian. Gambar 3.15 merupakan device yang dimiliki dan sedang aktif di perusahaan.
Gambar 3.15. Raspberry Pi sebagai utilitas dan alat bantu
A. Diagram Interaksi
Gambar 3.16 menunjukkan sebuah use-case diagram dari aplikasi yang telah dibuat. Sama seperti proyek sebelumnya, setiap departemen merupakan entitas tersendiri.
Gambar 3.16. Use-case dari Skifindo Database: Full Stack
Terlihat bahwa entitas departemen finansial dapat melihat transaksi dari satu stok serta melihat seluruh transaksi yang pernah terjadi selama ini. Entitas operasional dan pemasaran dapat menam- bah data stok, memasukkan data transaksi, serta mencari stok yang diperlukan. Direksi bertugas untuk mengontrol operasional secara keseluruhan. Setiap departemen dalam perusahaan dapat melihat seluruh sesi dan dapat pula mengganti tema dari aplikasi.
Perlu diperhatikan bahwa use-case merupakan penggu- naan aplikasi sesuai dengan departemen dan tugas masing-masing dalam perusahaan, tetapi dalam praktisnya, setiap pengguna dapat melakukan apapun dalam aplikasi kecuali mengakses dan menggu- nakan protected API routes.
B. Diagram Alir Aplikasi
Pada bagian ini, akan dijelaskan diagram alir aplikasi yang meliputi beberapa modul esensial yang terdapat pada aplikasi ini, yakni menambah inventaris serta melakukan transaksi. Sebelum pembahasan subsistem tersebut, penjabaran proses utama dari pro- gram adalah terdapat seperti Gambar 3.17.
Gambar 3.17. Diagram alir lengkap aplikasi
Gambar 3.17 menunjukkan alir utama dari aplikasi. Sebelum masuk ke dalam sistem, pengguna harus memiliki autentikasi dan otorisasi. Setelah mendapatkan kedua hal tersebut, pengguna da- pat mengakses beberapa modul yang merupakan inti dari aplikasi, seperti inventaris dan transaksi.
Gambar 3.18. Diagram alir untuk stok
Gambar 3.18 merupakan diagram alir yang digunakan untuk menjelaskan proses menambahkan data. Umumnya, menambahkan data dilakukan dengan cara memasukkan nama stok, kuantitas, serta tipe stok yang ada. Setelah itu, apabila input sahih, data akan lang- sung dimasukkan ke dalam sistem basis data MongoDB via API, dan karenanya langsung dapat dioperasikan dan dilihat di aplikasi.
Gambar 3.19. Diagram alir untuk transaksi
Gambar 3.19 merupakan diagram alir yang digunakan untuk menjelaskan proses transaksi. Menambahkan transaksi dilakukan dengan cara mengisi data nomor faktur, nama pelanggan / penyu- plai, harga pokok penjualan, kuantitas, karyawan yang mengisi data ini ke dalam sistem basis data, dan tipe transaksi baik itu penjualan maupun pembelian. Dalam proses pengisian data, terdapat validasi inputyang akan menolak input apabila tidak benar. Validasi berlang- sung pada API.
Diagram alir untuk proses autentikasi, baik itu login maupun access controltidak ditunjukkan karena sifatnya yang sensitif. Pada dasarnya, autentikasi dalam aplikasi menggunakan konsep JSON Web Tokens [11] yang mana merupakan salah satu cara yang paling aman untuk melakukan proses otorisasi dan autentikasi. JSON Web Tokens bekerja dengan cara melakukan enkripsi data yang berkai- tan dengan pengguna dengan menggunakan algoritme tertentu, serta menyimpannya ke dalam cookies dengan opsi tertentu agar tidak bisa di-spoof oleh pihak ketiga. Seluruh generasi token dilakukan de- ngan berbagai macam secret yang memiliki entropi acak yang sangat tinggi.
C. Diagram Relasi Entitas
Entity Relationship Diagram dari sistem basis data yang di- gunakan adalah sebagai berikut.
Gambar 3.20. ERD dari Skifindo Database: Full Stack
Diagram relasi entitas memiliki empat buah tabel utama (total ada tujuh tabel yang sisanya sebagai tabel pendukung), yakni adalah tabel User, Stock, Transaction, dan Token. Tabel pendukung yang ada adalah Role, Type, dan Agent. Tabel User menyimpan atribut data yakni adalah karakter identifikasi, username, password, status aktivasi, created date, serta role untuk pengguna tersebut. Dalam kasus ini, role dibagi menjadi dua buah, yakni adalah admin dan user. Sesuai dengan permintaan perusahaan, user adalah pengguna default, sedangkan admin hanya digunakan apabila ada keperluan mendesak untuk melakukan manipulasi data.
Tabel Stock memiliki atribut data yakni adalah karakter iden- tifikasi, nama stok, kuantitas, created date, dan tipe stok. Tipe stok sendiri dibagi menjadi beberapa tipe yang disesuaikan dengan keper- luan perusahaan.
Tabel Transaction memiliki atribut data yakni adalah karak- ter identifikasi, pelanggan / penyuplai, kuantitas, nomor faktur, harga pokok penjualan, tanggal transaksi, stok yang bersangkutan, tipe transaksi (penjualan atau pembelian), serta agen atau karyawan yang memasukkan data ke dalam sistem basis data.
Tabel Token (tidak ditampilkan) memiliki atribut data yakni adalah karakter identifikasi, dan atribut-atribut khusus autentikasi yang digunakan untuk melakukan verifikasi sesi yang dimiliki oleh pengguna. Hal ini digunakan untuk menunjang autentikasi dalam aplikasi.
Secara teknis, pembuatan nomor identifikasi semua dilakukan dengan menggunakan tipe data ObjectID khas MongoDB, yang menyediakan low-collision identifiers, dan setiap tabel dibuat men- jadi tipe data ‘enum’, karena merupakan NoSQL, digunakan untuk memanfaatkan kecepatan karena tidak perlu melakukan JOIN SQL clause.
Seluruh tabel merupakan tabel yang digunakan untuk me- nyimpan data dan integritasnya dijaga, dalam artian data tidak bisa dilakukan pembaruan atau penghapusan tanpa izin, sesuai dengan permintaan perusahaan.
D. Diagram Alir Data
Aplikasi ini memiliki aliran data sebagai berikut:
Gambar 3.21. Diagram konteks Skifindo Dashboard
Gambar 3.21 merupakan diagram konteks yang mana meng- hasilkan data pada masing-masing subsistem esensial sebagai berikut.
Gambar 3.22. DFD level 0 Skifindo Dashboard
Gambar 3.22 merupakan DFD dari aplikasi yang merupakan high-level overview. Tiga buah subsistem yang esensial adalah stok (inventaris), transaksi, dan autentikasi. Data yang diberikan kepada subsistem umumnya adalah data baru atau data modifikasi yang sesuai dengan skema masing-masing data store pada setiap subsis- tem. Seperti proyek sebelumnya, data yang diberikan dari pangkalan data untuk entitas adalah data yang relevan dengan permintaan dari subsistem, sesuai dengan kebutuhan.
E. Teknologi
Teknologi yang digunakan untuk mengerjakan proyek ini adalah sebagai berikut:
• Bahasa pemrograman JavaScript dan TypeScript;
• MongoDB sebagai sistem basis data;
• Express.js sebagai API framework dari aplikasi;
• React.js sebagai web framework dari aplikasi;
• Node.js sebagai web server dari aplikasi;
• ChakraUI sebagai UI framework dari aplikasi;
• Yarn sebagai dependency manager;
• Postman sebagai alat untuk menguji API endpoints;
• Heroku sebagai alat untuk melakukan deployment aplikasi pada cloud platform;
• Raspberry Pi sebagai alat untuk membangun environment dan melakukan utility scripting;
• GitHub Actions sebagai alat untuk melakukan Continuous Integration / Continuous Delivery(CI/CD;
• Git dan GitHub sebagai version control system untuk men- jaga agar kode sumber dari aplikasi tetap aman.
F. Alur Kerja
Seperti pada proyek sebelumnya, alur kerja yang dilakukan adalah dengan cara melakukan metode Git-flow. Metode ini meng- haruskan penulis untuk melakukan branching dan selalu membuat pull requests untuk mengintegrasikan kode kepada main branch.
Pengerjaan aplikasi dikerjakan pada GitHub Organization milik CV.
Skifindo Integra Selaras.
Berbeda dengan proyek sebelumnya, dalam proyek kali ini, penulis menambahkan CI dengan mengimplementasikan GitHub Ac- tions. Setiap kali penulis melakukan pull request, maka kode akan dilakukan format check, type check, serta lint check, baik itu di front- endmaupun di back-end. Hal ini menyebabkan penulis menulis kode dengan rapi dan bisa langsung mengetahui kesalahan yang mungkin tidak sengaja dibuat selama pengerjaan aplikasi. Ketika pull-request sudah di-merge, yang dilakukan oleh CI tersebut adalah langsung melakukan deployment pada Heroku, sehingga live-version dari apli- kasi sudah dapat langsung terlihat.
Setiap penulisan kode wajib didokumentasikan dengan metode JSDoc, yang mana merupakan metode standar JavaScript maupun TypeScript untuk mendokumentasikan fungsi-fungsi atau kode sumber agar menjadi maintainable dan lebih mudah dibaca.
G. Implementasi
Berikut adalah beberapa tampilan layar dari aplikasi yang su- dah dibangun.
Ketika pertama kali mengakses aplikasi, akan muncul tampi- lan seperti Gambar 3.23. Aplikasi memiliki dua tema, yakni adalah mode terang dan mode gelap yang dapat diatur sesuai selera peng-
guna.
Gambar 3.23. Tampilan home dari aplikasi
Pengguna harus melakukan login terlebih dahulu untuk bisa mengakses seluruh fitur dalam aplikasi. Apabila pengguna tidak ter- autentikasi, maka tidak dapat menggunakan aplikasi karena setiap routeatau page dalam aplikasi akan mengembalikan status code 401 yang berarti adalah unauthorized dan dikembalikan kepada home page. Gambar 3.24 adalah tampilan login.
Gambar 3.24. Tampilan autentikasi dari Skifindo Dashboard
Ketika pengguna sudah terautentikasi, tampilan home akan berubah menjadi memiliki beberapa tautan untuk mengarah ke be- berapa halaman lain dalam aplikasi, seperti inventaris, transaksi, dan sesi. Ketika mengakses transaksi, maka pengguna disajikan dengan tampilan seperti pada Gambar 3.25.
Gambar 3.25. Tampilan inventaris dari Skifindo Dashboard
Pengguna dapat melakukan navigasi antar page. Data yang disajikan dalam aplikasi sudah memiliki paginasi, karena jumlah data yang besar. Pengguna juga dapat melakukan pencarian terhadap sebuah inventaris dengan menggunakan search bar yang berada di atas tampilan.
Gambar 3.26. Tampilan pencarian dari Skifindo Dashboard
Terlihat pada Gambar 3.26 bahwa pencarian stok dengan kata kunci ‘147’ akan menghasilkan seluruh data stok dengan kata kunci
‘147’. Paginasi dihilangkan ketika menggunakan fitur ini untuk kenyamanan pengguna.
Gambar 3.27. Tampilan penambahan stok dari Skifindo Dashboard
Pada Gambar 3.27 terlihat sebuah modal apabila pengguna ingin menambahkan stok pada aplikasi. Pengguna hanya perlu memasukkan data dan secara otomatis data stok atau inventaris akan ditambahkan ketika pengguna menekan tombol ‘Submit’.
Gambar 3.28. Tampilan detail stok dari Skifindo Dashboard
Gambar 3.28 tampilan bila pengguna menekan salah satu kartu stok yang ada pada tampilan sebelumnya. Disini, pengguna dapat melihat segala informasi tentang stok, mulai dari nomor kode famili, kuantitas, penyuplai/tipe, serta seluruh data transaksi yang stok tersebut pernah mengalami. Pengguna dapat menekan tombol
‘Transaction’ untuk menambahkan transaksi baru untuk stok terse- but, yang mana akan menghasilkan modal seperti Gambar 3.29.
Segala macam input sudah sesuai dengan diagram relasi entitas.
Gambar 3.29. Tampilan penambahan transaksi
Selanjutnya, pengguna yang terautentikasi dapat melakukan akses terhadap seluruh jenis transaksi yang pernah terjadi selama
penggunaan aplikasi ini (dan transaksi lama yang sudah dimigrasikan ke aplikasi ini pada proyek ketiga), seperti terlihat pada Gambar 3.30.
Data disensor demi privasi.
Gambar 3.30. Tampilan transaksi
Selain itu, pengguna juga dapat melakukan akses sessions un- tuk saling melakukan verifikasi pengguna yang sedang menggunakan aplikasi. Karena sifatnya yang sensitif, maka tidak ditampilkan pada laporan ini.
Aplikasi ini merupakan progressive web application, yang berarti aplikasi dapat di-install secara natural dan dapat digunakan layaknya native mobile application, baik di sistem operasi Android, iOS, dan lain sebagainya. Gambar 3.31 menunjukkan tampilan dari PWA yang telah dibuat (mengakses aplikasi pada mobile). Salah satu fitur unik dari PWA adalah kemampuan untuk mengadaptasi native device feature, seperti pada kasus ini adalah offline notification yang memberi tahu apabila pengguna tidak terkoneksi pada jaringan inter- net.
(a) Tampilan PWA utama (b) Contoh offline notification Gambar 3.31. Tampilan PWA pada aplikasi
3.3.3 Scripting
Pembuatan proyek yang ini tidak menggunakan arsitektur dan diagram-diagram seperti ERD dan semacamnya karena hanya merupakan scriptinguntuk melakukan otomasi dan migrasi data.
A. Diagram Alir Aplikasi
Diagram alir yang akan dijelaskan pada proyek ini adalah proses bisnis dan proses program secara keseluruhan untuk melakukan migrasi dari bentuk data CSV menjadi bentuk data JSON agar dapat diadaptasikan pada sistem basis data MongoDB.
Gambar 3.32. Diagram alir dari proyek Scripting
Gambar 3.32 menujukkan proses dari program yang dibuat untuk proyek ini. Pada awalnya, program akan membaca file CSV untuk data riwayat pemesanan dan penjualan. Setelah membaca ri- wayat pemesanan dan penjualan, data akan dibersihkan sesuai de- ngan format yang diminta oleh perusahaan. Dalam aktivitas pember- sihan data, dilakukan beberapa adaptasi karena ada beberapa data yang belum terstruktur secara benar. Beberapa kolom dari CSV yang perlu dibersihkan adalah tanggal, tipe transaksi, nomor faktur, serta karyawan yang memasukkan data ke dalam file CSV tersebut.
Pembersihan data dilakukan sesuai dengan arahan oleh pembimb- ing lapangan untuk dapat membuat keseluruhan data menjadi lebih rapi dan terstruktur, serta disesuaikan dengan skema basis data yang dibuat pada proyek Skifindo Database: Full Stack.
Setelah proses pembersihan data riwayat transaksi selesai, se- lanjutnya akan dilakukan pembacaan data dari file CSV untuk data stok dari perusahaan yang pernah ada sebelumnya. Data akan diber- sihkan dengan cara melakukan manipulasi kolom ‘tipe’, karena ada beberapa tipe yang tidak seragam namanya. Setelah dibersihkan, masing-masing data stok akan diberikan sebuah ObjectID yang khas
untuk MongoDB.
Seusai data secara lengkap telah diproses dan dibersihkan, se- lanjutnya adalah melakukan pengikatan atau linking dari data stok dan data transaksi. Dalam perusahaan, sebuah transaksi memiliki satu stok (memiliki mapping one-to-one) seperti foreign key. Cara untuk melakukan pengikatan adalah dengan cara menyamakan an- tara kolom nama dari stok dan kolom stok dari transaksi, kemu- dian mengubah kolom stock tersebut dengan ObjectID dari stok yang bersangkutan. Cara ini memastikan bahwa setiap transaksi yang terikat memiliki sebuah stok sendiri.
Ada beberapa data transaksi dan stok yang memang tidak memiliki kesamaan (tidak bisa disamakan kolom nama stok dan kolom stok dari transaksi) karena sudah pernah berganti nama. Oleh sebab itu, pembimbing lapangan dan perusahaan memutuskan untuk membuang data yang sudah seperti itu saja, karena umumnya sudah merupakan data yang lama (sejak tahun 2018 dan 2019). Cara untuk melakukan verifikasi integritas data adalah dengan cara melakukan verifikasi ObjectID masing-masing transaksi (pada kolom stok).
Seusai memproses, membersihkan, dan memverifikasi data, yang dilakukan adalah melakukan export dari data tersebut menjadi bentuk file JSON, agar dapat dimasukkan ke dalam sistem basis data MongoDB. Data tersebut langsung dimasukkan ke dalam sistem ba- sis data dan langsung digunakan pada Skifindo Database: Full Stack yang telah dibuat sebelumnya.
B. Teknologi
Teknologi yang digunakan pada proyek ini adalah sebagai berikut:
• Bahasa pemrograman Python, untuk melakukan proses data CSV menjadi bentuk JSON untuk dapat dimasukkan ke dalam MongoDB.
• Bahasa pemrograman Node.js, yang mana melanjutkan dari proyek sebelumnya. Node.js digunakan untuk memasukkan data yang sudah diolah menjadi bentuk JSON ke dalam sis- tem basis data MongoDB agar mampu melakukan migrasi
sistem basis data dengan sempurna sesuai dengan skema yang sudah diciptakan sebelumnya.
• Poetry sebagai package manager untuk Python yang digu- nakan.
• Sistem operasi Linux dan Raspberry Pi untuk menjalankan seluruh script yang telah dibuat.
• Git dan GitHub untuk version control system.
C. Implementasi
Berikut adalah beberapa tangkapan layar implementasi dari proyek ini.
Gambar 3.33. Data dari riwayat transaksi
Gambar 3.33 menunjukkan data riwayat transaksi yang masih merupakan bentuk CSV dan ditampilkan dengan aplikasi pengolah lembar kerja. Data ini akan diproses dan dibersihkan oleh script yang akan dibuat dengan algoritme sebelumnya untuk menyatukan dan membersihkan beberapa atribut atau kolom data.
Gambar 3.34. Data kasar dari inventaris perusahaan
Gambar 3.34 menunjukkan data inventaris stok yang masih merupakan bentuk CSV yang dibuka secara as it is pada aplikasi code editor. Sama seperti data riwayat transaksi, data akan diproses dan dibersihkan oleh script yang akan dibuat sesuai dengan algoritme yang telah dijelaskan pada bagian sebelumnya.
Gambar 3.35. Data stok yang sudah diproses
Gambar 3.35 menunjukkan data stok yang sudah diolah dan
menghasilkan data dalam bentuk JSON yang siap untuk dimasukkan ke dalam sistem basis data MongoDB.
Gambar 3.36. Data transaksi yang sudah diproses
Gambar 3.36 menunjukkan data transaksi yang sudah diolah
dan merupakan bentuk JSON dan siap untuk dimasukkan ke dalam basis data.
Gambar 3.37. Migrasi data secara sempurna
Pada akhirnya, Gambar 3.37 juga menunjukkan bahwa basis data sudah berhasil diperbarui dan sudah dapat menggunakan proyek Skifindo Database: Full Stack dengan basis data yang lama yang berasal dari Ms. Excel (dalam bentuk CSV) yang sudah digunakan selama bertahun-tahun. Gambar 3.38 menunjukkan sampel data stok bahwa seluruh data yang bersangkutan sudah berhasil dimasukkan ke dalam MongoDB Atlas.
Gambar 3.38. Sampel data dalam MongoDB Atlas
3.4 Kendala dan Solusi yang Ditemukan
Ada beberapa kendala beserta solusi yang ditemukan saat mengerjakan proyek pertama, yakni adalah sebagai berikut:
• Tidak adanya Continuous Integration / Continuous Delivery (CI/CD) yang dipasang dalam repositori kode sumber. Hal ini menyebabkan terkadang penulis harus melakukan double-check agar kode yang dimasukkan ke dalam repositori sudah bekerja dengan baik, serta memiliki format yang baik. So- lusi dari permasalahan ini adalah dengan melakukan double-check, karena mengimplementasikan CI/CD untuk aplikasi berbasis mobile akan membu- tuhkan waktu yang agak lama.
• Tidak adanya unit-testing atau dedicated testing lainnya seperti end-to-end testing, load testing, dan lain sebagainya. Karena terkendala oleh waktu yang menyebabkan belum sempatnya membuat unit-testing, terkadang sulit untuk
memastikan apakah sebuah fungsi dalam aplikasi sudah sesuai dengan yang diinginkan atau belum. Terkadang pula, bisa muncul beberapa galat atau ke- salahan yang tidak diduga sebelumnya (biasanya karena masalah tipe data atau typo). Solusi dari permasalahan ini adalah melihat kode sumber kembali dan memastikan bahwa tidak ada galat dengan melakukan soft testing.
• Perbedaan versi Android antara karyawan di kantor. Pada awalnya, aplikasi di-desain untuk hanya mendukung Android dengan tingkat API 26 ke atas.
Akan tetapi, ada beberapa orang di kantor yang menggunakan Android de- ngan tingkat API 25 ke bawah, yang menyebabkan tidak bisa menggunakan aplikasi yang dibuat (pada awalnya). Solusi dari permasalahan ini adalah dengan cara melakukan downgrade pada compiler yang berada di Android Studio.
Ada beberapa kendala beserta solusi yang ditemukan saat mengerjakan proyek kedua, yakni adalah sebagai berikut:
• Tidak adanya unit-testing karena keterbatasan waktu. Solusi dari permasa- lahan ini adalah dengan melihat kode sumber kembali dan memastikan bahwa tidak ada galat dengan melakukan soft testing.
• Kurangnya resource mengenai service workers dan konsep PWA dengan menggunakan React. Oleh karena itu, penyelesaian dari permasalahan ini adalah dengan cara melihat kode sumber dari service worker yang dimiliki oleh React dan mempelajarinya.
• Hosting provider masih menggunakan Heroku (karena tahap eksperimental), maka dari itu apabila tidak menerima traffic untuk beberapa waktu, dia akan mati dan membutuhkan waktu untuk diakses kembali. Permasalahan ini di- selesaikan dengan cara membuat ping script yang dijadwalkan setiap interval waktu tertentu dengan menggunakan cronjob dengan bantuan Raspberry Pi.
Untuk bagian mengerjakan scripting, ada beberapa kendala yang ditemukan, yakni adalah sebagai berikut:
• Ada beberapa data yang kurang terstruktur dan tidak bisa dikaitkan karena tidak ada referensinya. Hal ini terjadi karena ada beberapa inventaris yang sudah berganti nama. Solusi dari permasalahan ini adalah membuang data kotor tersebut sesuai dengan permintaan pembimbing lapangan.
• Ada beberapa kendala yang dihadapi saat memilih alat yang digunakan untuk memroses data dari Ms. Excel (CSV) menjadi JSON untuk dimasukkan ke dalam MongoDB. Akhirnya, pilihan jatuh kepada Python dan Node.js karena sudah ada fitur dalam bahasa pemrograman tersebut untuk memroses CSV.
