Embed Size (px)
Citation preview
PENGEMBANGAN BUSINESS TRIP MANAGEMENT SYSTEM
MENGGUNAKAN WORKFLOW ENGINE
(STUDI KASUS PT AMN INDONESIA)
YURIZAL ROSA ANDIKA
DEPARTEMEN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
INSTITUT PERTANIAN BOGOR
BOGOR
2018
PERNYATAAN MENGENAI SKRIPSI DAN
SUMBER INFORMASI SERTA PELIMPAHAN HAK CIPTA
Dengan ini saya menyatakan bahwa skripsi berjudul Pengembangan Business
Trip Management System Menggunakan Workflow Engine (Studi Kasus PT AMN
Indonesia) adalah benar karya saya dengan arahan dari komisi pembimbing dan
belum diajukan dalam bentuk apa pun kepada perguruan tinggi mana pun. Sumber
informasi yang berasal atau dikutip dari karya yang diterbitkan maupun tidak
diterbitkan dari penulis lain telah disebutkan dalam teks dan dicantumkan dalam
Daftar Pustaka di bagian akhir skripsi ini.
Dengan ini saya melimpahkan hak cipta dari karya tulis saya kepada Institut
Pertanian Bogor.
Bogor, Juli 2018
Yurizal Rosa Andika
NIM G64144068
ABSTRAK
YURIZAL ROSA ANDIKA. Pengembangan Business Trip Management Sytem
Menggunakan Workflow Engine (Studi Kasus PT AMN Indonesia). Dibimbing oleh
IRMAN HERMADI.
Perjalanan dinas merupakan aktivitas perjalanan yang dilakukan oleh
karyawan dengan tujuan peningkatan profit perusahaan. Perjalanan dinas yang
dilakukan melalui dua tahap yaitu pengajuan rencana perjalanan dan pelaporan
hasil perjalanan. Tahap pengajuan perjalanan dilakukan dengan membuat rencana
perjalanan. Setelah perjalanan dilakukan setiap karyawan akan memberikan laporan
hasil perjalanan. PT AMN Indonesia selaku konsultan dalam bidang teknologi
informasi mengusulkan solusi pengelolaan perjalanan bisnis yang disebut Business
Trip Management System (BTMS) yang memiliki 2 fungsi utama yaitu Travel
Application yang digunakan untuk membuat pengajuan rencana perjalanan dan
Settlement untuk membuat laporan pertanggungjawaban perjalanan. Penelitian ini
mengembangkan salah satu fungsi tersebut yaitu fungsi Travel Application. Fungsi
Travel Application diintegrasikan dengan workflow engine. Fungsi Travel
Application telah berhasil dikembangkan dan diuji. Pengembangan dilakukan
dengan tiga tahapan yaitu perancangan arsitektur, perancangan prototipe dengan
metode Evolutionary Prototyping, dan pengembangan sistem dengan metode
Incremental. Pengujian yang dilakukan mencakup integrasi antara fungsi Travel
Application dan workflow engine.
Kata kunci: perjalanan dinas, Evolutionary Prototyping, Incremental, workflow
ABSTRACT
YURIZAL ROSA ANDIKA. Business Trip Management System Development
Using Workflow Engine (Case Study PT AMN Indonesia). Supervised by IRMAN
HERMADI.
Business travel is travel activity undertaken by employees with the aim of
increasing corporate profits. Business travel go through two phases there is travel
plan and travel reporting. Travel plans submission doing by create some travel
plans. After the trip is done employee will provide reports on the results of travel.
PT AMN Indonesia as a consultant of information technology proposed a business
travel management solution called Business Trip Management System (BTMS)
which has two main functions there is Travel Application which is used to make
the travel plan and Settlement to make travel account report. This research develop
one of them that is Travel Application function. Travel Application function is
integrated with workflow engine. The Travel Application function has been
successfully developed and tested. The development is done by three stages there
is architecture design, prototype design with Evolutionary Prototyping method, and
system development with Incremental method. Tests conducted include the
integration between the Travel Application function and workflow engine.
Keywords: business travel, Evolutionary Prototyping, Incremental, workflow
Skripsi
sebagai salah satu syarat untuk memperoleh gelar
Sarjana Komputer
pada
Departemen Ilmu Komputer
PENGEMBANGAN BUSINESS TRIP MANAGEMENT SYSTEM
MENGGUNAKAN WORKFLOW ENGINE
(STUDI KASUS PT AMN INDONESIA)
YURIZAL ROSA ANDIKA
DEPARTEMEN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
INSTITUT PERTANIAN BOGOR
BOGOR
2018
Penguji :
1 Dean Apriana Ramadhan, SKomp MKom
2 Firman Ardiansyah, SKom MSi
Judul Skripsi : Pengembangan Business Trip Management System Menggunakan
Workflow Engine (Studi Kasus PT AMN Indonesia)
Nama : Yurizal Rosa Andika
NIM : G64144068
Disetujui oleh
Irman Hermadi, SKom MS PhD
Pembimbing
Diketahui oleh
Prof Dr Ir Agus Buono, MSi MKom
Ketua Departemen
Tanggal Lulus:
PRAKATA
Puji dan syukur penulis panjatkan kepada Allah subhanahu wa ta’ala atas
segala karunia-Nya sehingga karya ilmiah ini berhasil diselesaikan. Terima kasih
kepada kedua orang tua ku, Ibu Eti Rohaeti dan Bapak Syahrial Ambun Suri yang
senantiasa mendoakan dan menyayangi, tidak ada balasan sebesar apapun yang
dapat mengganti segala yang telah mereka berikan. Terima kasih kepada kakakku
Jumiati Roza Prihatini dan adikku Rizki Rosa Buana Putra yang senantiasa men-
support dan menyayangi. Terima kasih kepada Bapak Ruslan dan Bapak Heru yang
senantiasa memberikan nasihat terbaik untuk penulis dalam berbagai aspek. Terima
kasih kepada Nurul Safitri dan keluarga yang juga senantiasa memberikan
dukungan dan doanya. Terima kasih kepada Kusuma Indra Putra, Muhammad Arief
Kalbuadi, Herdian Septa, Ahmad Isyfalana Amin, dan Dian Purnamasari yang
dengan sabar dan ikhlas membantu penulis dalam menyelesaikan karya ini. Terima
kasih kepada Bapak Harry Saputra Kartono yang telah mengajarkan banyak hal
kepada penulis. Terima kasih kepada Bapak Irman Hermadi, SKom MS PhD atas
bimbingannya selama ini.
Penelitian ini diambil dari contoh kasus yang diberikan oleh PT AMN
Indonesia sebagai bentuk challenge untuk menguji produk yang diproduksi oleh
penulis. Contoh kasus yang diberikan adalah kasus business trip untuk menguji
produk yang telah dikembangkan oleh penulis, yaitu produk Azka Framework,
Azka Code Generator, dan Azka Workflow Engine (Azka-WF). Kasus business trip
dipilih untuk menguji kemampuan workflow dalam mengakomodir kebutuhan
perusahaan yang memiliki workflow yang berbeda-beda.
Penelitian ini juga dilakukan untuk mencari dan menguji metode yang tepat
yang dapat digunakan dalam software development khususnya di Indonesia.
Teknologi yang telah dikembangkan oleh penulis akan dicoba dengan metode
dalam penelitian ini untuk melihat kecocokan antara teknologi yang telah
dikembangkan dan metode pengembangannya.
Semoga karya ilmiah ini bermanfaat.
Bogor, Juli 2018
Yurizal Rosa Andika
DAFTAR ISI
DAFTAR GAMBAR vi
PENDAHULUAN 1
Latar Belakang 1
Perumusan Masalah 2
Tujuan Penelitian 3
Manfaat Penelitian 3
Ruang Lingkup Penelitian 3
METODE 3
Tahapan Penelitian 3
Perancangan Arsitektur Software 3
Perancangan Prototipe dengan Metode Evolutionary Prototyping 4
Pengembangan Sistem dengan Metode Incremental 5
Lingkungan Pengembangan 6
HASIL DAN PEMBAHASAN 7
Perancangan Arsitektur Software 7
Perancangan Prototipe Iterasi 1 10
Perancangan Prototipe Iterasi 2 12
Pengembangan Back-End dengan Metode Incremental 13
Pengembangan Back-End Iterasi 1 15
Pengembangan Back-End Iterasi 2 17
SIMPULAN DAN SARAN 21
Simpulan 21
Saran 22
DAFTAR PUSTAKA 22
RIWAYAT HIDUP 23
DAFTAR GAMBAR
3 Tahapan Penelitian 3 4 Evolutionary Prototyping 4 5 Incremental 5 6 Arsitektur Software 7 7 Token Request dan Resource Request 9
8 Contoh konfigurasi service dummy 9 9 Use case diagram Business Trip Management System 11
10 Prototipe Travel Application iterasi 1 12
11 Prototipe Travel Application iterasi 2 13 12 Class diagram Business Trip Management System 14 13 Unit Test Explorer 15 14 Method sebelum refactoring 16
15 Method hasil refactoring 17 16 Method setelah refactoring 17 17 Registrasi Tipe Dokumen 18 18 Registrasi web service pada workflow engine 19
19 Konfigurasi email pada workflow engine 19 20 Konfigurasi workflow 20
21 Registrasi instance workflow 20
PENDAHULUAN
Latar Belakang
Business travel atau perjalanan dinas didefinisikan sebagai aktivitas
perjalanan yang dilakukan oleh karyawan perusahaan dengan tujuan meningkatkan
profit perusahaan. Aktivitas perjalanan yang memiliki potensi peningkatan profit
diantaranya negosiasi, pameran produk, pelatihan, kongres, konferensi, dan lain-
lain (Rocholl 2012). Perjalanan yang akan dilakukan memerlukan rincian kegiatan
dan rincian biaya untuk menunjang perjalanan, rincian biaya yang diperlukan
diantaranya biaya transportasi, hotel, konsumsi, dan lain-lain.
Business travel yang dikelola oleh berbagai perusahaan pada umumnya
terbagi menjadi 2 tahap yaitu tahap perencanaan dan pertanggungjawaban
perjalanan. Proses perencanaan perjalanan yang dilakukan pada umumnya adalah
membuat rencana perjalanan serta rincian biaya perjalanan yang dibutuhkan selama
kegiatan business travel berlangsung. Perjalanan yang telah dilakukan akan
dilaporkan kembali kepada perusahaan, laporan tersebut mencakup kegiatan dan
penggunaan biaya yang dikeluarkan selama perjalanan.
Pengajuan rencana perjalanan akan dilakukan oleh requester. Requester
adalah pihak yang bertanggungjawab mendefinisikan rencana perjalanan dan
kebutuhan biaya yang akan digunakan. Rencana yang telah dibuat akan dikaji oleh
approver. Approver merupakan pihak yang akan memeriksa seluruh kebutuhan
biaya yang diajukan serta menentukan perjalanan yang diajukan dapat terlaksana
atau tidak.
Perjalanan yang telah disetujui dan dilaksanakan perlu dibuat laporan
perjalanan. Laporan perjalanan yang dibuat mencakup perincian penggunaan biaya
yang telah digunakan. Jika laporan biaya yang digunakan memiliki sisa, maka pihak
yang terlibat dalam kegiatan akan mengembalikan sisa biaya kepada perusahaan,
namun ketika biaya yang dilaporkan lebih besar maka perusahaan akan mengganti
kekurangan biaya tersebut dengan pertimbangan tertentu.
Permasalahan pengelolaan business travel membutuhkan sebuah solusi untuk
menangani perencanaan dan pertanggungjawaban perjalanan. PT AMN Indonesia
selaku perusahaan yang berfokus pada pengembangan software mengusulkan
sebuah solusi business travel yang disebut sebagai Business Trip Management
System (BTMS) yang berfungsi mengelola pengajuan rencana perjalanan dan
pertanggungjawabannya. BTMS yang dikembangkan didesain generic sebagai
software as a service (SaaS) agar dapat digunakan oleh berbagai bentuk
perusahaan.
BTMS akan memiliki 2 fungsi utama yaitu Travel Application dan
Settlement. Travel Application akan digunakan untuk mengajukan rencana
perjalanan yang akan dilakukan. Settlement digunakan untuk memberikan laporan
hasil perjalanan. Penelitian ini mengembangkan salah satu fungsi tersebut yaitu
fungsi Travel Application.
Pengembangan BTMS sebagai SaaS memerlukan penelitian yang serius. Hal
ini dikarenakan sistem yang dikembangkan harus mampu melayani berbagai bentuk
perusahaan. BTMS sendiri pada dasarnya memiliki kesamaan antara satu
2
perusahaan dengan perusahaan lainnya, namun pada standard operating procedure
(SOP) dalam pengelolaannya memiliki perbedaan yang signifikan.
SOP yang berbeda-beda perlu diakomodasi diluar sistem BTMS, untuk itu
BTMS perlu diintegrasikan dengan sistem lain. Penelitian ini akan
mengintegrasikan BTMS dengan workflow engine. Workflow engine akan
digunakan untuk mengelola SOP yang dibutuhkan oleh perusahaan. Workflow
berisi deskripsi bisnis proses yang ada di dalam sebuah organisasi serta informasi
mengenai task yang harus dilakukan oleh masing-masing individu di dalam sebuah
organisasi (Georgakopoulos 1995).
Fungsi Travel Application dan workflow dirancang terpisah, pemisahan
dilakukan untuk menghindari terjadinya tighly coupled antara proses workflow dan
proses bisnis pada aplikasi. Tighly coupled merupakan keterikatan yang erat antar
modul dalam hal implementasi kode program. Keadaan tighly coupled akan
menghasilkan isu yang cukup sulit ditangani ketika dibutuhkan perubahan pada sisi
workflow. Pemisahan antara aplikasi utama dan workflow akan menghasilkan
keadaan loosely coupled. Loosely coupled merupakan kondisi keterikatan yang
rendah antar modul di dalam aplikasi, keadaan ini memberikan kemudahan ketika
terjadi perubahan workflow, perubahan alur dapat dilakukan hanya pada sisi
workflow tanpa mempengaruhi proses bisnis yang ada pada aplikasi (Buschman
2007).
Workflow engine yang digunakan adalah Azka Workflow Engine (Azka-WF).
Azka-WF merupakan produk SaaS yang menyediakan layanan workflow yang
dinamis. Azka-WF pada penelitian ini digunakan untuk menangani workflow yang
dinamis di dalam BTMS, sehingga workflow yang ada pada BTMS dapat diubah
sesuai kebutuhan perusahaan yang menggunakan layanan BTMS.
Selain workflow engine penelitian ini akan dikerjakan menggunakan tools
Azka Code Generator. Tools tersebut digunakan untuk membuat prototipe dan kode
dasar seperti fungsi create, read, update, dan delete (CRUD). Diharapkan
penggunaan tools tersebut akan memberikan kemudahan dalam pengembangan
sistem dan mempersingkat waktu pengembangan.
Perumusan Masalah
Pengelolaan business travel pada berbagai perusahaan umumnya memiliki
tahapan yang sama yaitu perencanaan dan pertanggungjawaban perjalanan.
Meskipun memiliki tahap yang hampir sama namun memiliki perbedaan SOP yang
signifikan. Perbedaan SOP ini berpotensi menghasilkan isu yang cukup sulit
ditangani ketika SOP digabungkan dengan aplikasi utama secara langsung. PT
AMN Indonesia mengusulkan sebuah solusi bisnis dalam bentuk sistem informasi
yang dinamakan Business Trip Management System (BTMS) yang dapat
memberikan layanan pengelolaan business trip pada berbagai jenis perusahaan.
Layanan yang akan dikembangkan adalah sistem yang mampu mengakomodir
perbedaan SOP dari berbagai perusahaan.
3
Tujuan Penelitian
Tujuan dari penelitian ini adalah mengembangkan sebuah layanan untuk
fungsi Travel Application pada Business Trip Management System (BTMS)
menggunakan workflow engine yang dapat digunakan oleh berbagai perusahaan.
Manfaat Penelitian
Setiap perusahaan dapat menggunakan layanan Travel Application pada
Business Trip Management System (BTMS) sesuai dengan SOP masing-masing
perusahaan.
Ruang Lingkup Penelitian
Penelitian ini akan mengembangkan fungsi Travel Application yang ada di
dalam BTMS yang diintegrasikan dengan workflow engine. Selain pengembangan
fungsi Travel Application, penelitian ini akan membahas secara singkat mengenai
penggunaan workflow dalam menangani kebutuhan BTMS sebagai SaaS.
METODE
Tahapan Penelitian
Penelitian dilakukan dalam 3 tahapan yaitu perancangan arsitektur software,
membuat prototipe sistem dengan metode Evolutionary Prototyping, dan
pengembangan sistem dengan metode Incremental. Tahapan penelitian
diilustrasikan pada Gambar 1.
Perancangan Arsitektur Software
Perancangan arsitektur yang dilakukan mencakup perancangan layering dan
pemilihan design pattern yang digunakan. Layering merupakan salah satu teknik
yang digunakan oleh software designer yang digunakan untuk memecah tingkat
kompleksitas yang ada di dalam sistem (Fowler 2003). Layering ini memiliki
keuntungan yaitu adanya standarisasi dan meminimalisir keterikatan antar layer.
Layering akan memberikan kemudahan dalam pencarian kesalahan ketika software
telah selesai dibuat. Design pattern merupakan solusi-solusi yang telah dihasilkan
dari permasalahan-permasalahan yang sering terjadi dalam pengembangan
software.
Gambar 1 Tahapan Penelitian
Tahapan Penelitian
Tahapan Penelitian
Tahapan Penelitian
4
Perancangan Prototipe dengan Metode Evolutionary Prototyping
Metode Evolutionary Prototyping merupakan salah satu metode iterative
yang biasa digunakan untuk mengembangkan software yang kebutuhan fungsi dan
fiturnya belum jelas. Metode ini digunakan untuk menggali informasi kebutuhan
sistem yang akan dikembangkan, informasi tersebut mencakup fungsi, fitur, dan
interaksi yang terjadi antara user dengan sistem (Pressman 2010). Penggunaan
metode ini digunakan untuk mendesain user interface dan kebutuhan sistem yang
nantinya akan dideskripsikan dalam document specification. Tahapan yang
dilakukan yaitu communication, quick plan, prototyping, dan feedback yang
diilustrasikan pada Gambar 2.
1. Communication
Proses komunikasi yang dilakukan pada kasus ini dilakukan dalam bentuk
wawancara kepada Bapak Harry Saputra Kartono selaku Software Architect dan
penanggungjawab dalam penelitian ini. Proses komunikasi bertujuan untuk
menggali informasi kebutuhan sistem BTMS, penggalian informasi mencakup
target pengguna, penggunaan sistem, dan aturan bisnis yang akan
diimplementasikan pada BTMS.
2. Quick Plan
Setelah permasalahan telah teridentifikasi melalui proses komunikasi,
dilakukan perencanaan terhadap kebutuhan sistem yang akan dikembangkan,
perencanaan tersebut mencakup breakdown modul apa saja yang akan
dikembangkan dan penjadwalan terhadap pengembangan modul.
3. Prototyping
Pada fase prototyping akan dibuat user interface yang akan digunakan oleh user.
Fungsi yang ditampilkan masih belum memiliki logika dari proses bisnis
aplikasi yang akan dikembangkan, pada tahap ini user interface hanya
menampilkan alur penggunaan aplikasi.
4. Feedback
Prototipe yang telah dibuat akan dipresentasikan, pada tahap ini akan
didapatkan feedback dari prototipe yang telah diajukan. Jika masih terdapat
perubahan, maka akan dilakukan iterasi berikutnya untuk mendapatkan
kesepakatan antar kedua belah pihak.
Fase prototyping ini dilakukan maksimum dalam 3 iterasi, iterasi 1 akan
berfokus pada perancangan prototipe dengan tingkat medium fidelity, pada tahap ini
prototipe dibuat menggunakan Azka Code Generator. Iterasi 2 akan dikembangkan
prototipe dengan tingkat high fidelity, pada tahap ini prototipe akan dijalankan
Gambar 2 Evolutionary Prototyping
5
diatas Azka Presentation Engine, presentation engine ini menyediakan dummy
services yang dapat terintegrasi langsung dengan prototipe yang telah dibuat, serta
memberikan simulasi proses CRUD pada aplikasi. Iterasi 3 akan dilakukan jika
hasil prototipe pada iterasi 2 memerlukan perubahan.
Pengembangan Sistem dengan Metode Incremental
Metode Incremental digunakan untuk mengembangkan sistem yang
kebutuhannya sudah cukup jelas. Metode ini menggabungkan elemen-elemen
linear dan proses paralel pada fase pengembangannya. Increemental menghasilkan
produk pada setiap iterasinya, iterasi pertama akan didapatkan kebutuhan dasar
sistem, fitur lainnya akan didapatkan pada iterasi selanjutnya sehingga pada setiap
iterasi tidak langsung menghasilkan seluruh fitur (Pressman 2010). Tahapan yang
dilakukan dalam setiap iterasi adalah requirement, development, testing, code
review, retesting, dan implementation, tahapan metode Incremental diilustrasikan
pada Gambar 3.
1. Requirement
Tahap requirement dilakukan oleh business analyst, tahap ini dilakukan
perancangan kebutuhan sistem yang akan dikembangkan, pada tahap ini dibuat
document specification sebagai panduan pengembangan fungsi. Kebutuhan
sistem didapatkan dari hasil metode sebelumnya, pada metode sebelumnya
dijelaskan bahwa prototipe yang telah dihasilkan akan dideskripsikan pada
document specification.
2. Development
Document specification yang telah selesai diserahkan kepada programmer
untuk diimplementasikan ke dalam kode program komputer. Programmer akan
mengimplementasikan sistem sesuai dengan document specification. Sistem
yang telah diimplementasikan tidak langsung diserahkan kepada tester untuk
diuji, progammer akan melakukan pengujian terlebih dahulu pada saat
development sebelum masuk ke dalam tahap testing. Pengujian yang dilakukan
pada saat development menggunakan unit test untuk menguji setiap fungsi yang
telah dibuat. Unit test merupakan bagian dari kode program berupa method-
method yang memanggil method lainnya untuk menguji kebenaran dari method
yang dipanggil dengan melakukan perbandingan return value dari method yang
dipanggil dengan nilai asumsi yang diharapkan (Osherove 2014).
Gambar 3 Incremental
6
3. Testing
Sistem yang telah selesai dikembangkan akan dilakukan pengujian oleh tester.
Tester akan menguji sistem sesuai dengan testing scenario yang ada di dalam
document specification. Tahap ini akan menghasilkan 2 status yaitu need bugfix
atau done. Status need bugfix akan segera diserahkan kembali kepada
programmer untuk segera dilakukan perbaikan.
4. Code Review
Tahap code review dilakukan oleh tim arsitek, ditahap ini kode program yang
telah dibuat oleh programmer akan dievaluasi, evaluasi dilakukan pada sisi
logika program dan struktur kode program pada setiap fungsi. Hasil review akan
diberikan kepada programmer untuk dilakukan refactoring terhadap spaghetti
code dan fungsi-fungsi yang kurang efisien, sehingga diharapkan mampu
menghasilkan program yang berkualitas dengan performance yang baik.
5. Retesting
Tahap pengujian ulang dilakukan setelah proses code review, tahapan ini
dilakukan ulang oleh tester dengan tujuan memastikan hasil code review tidak
mengganggu fungsi yang telah ada, jika terjadi bugs maka akan langsung
dilakukan perbaikan oleh programmer.
6. Implementation
Tahap ini dilakukan deployment sistem di server, deployment yang dilakukan
mencakup setup database, webserver, dan setup konfigurasi sistem. Tahap ini
juga dilakukan pengujian terhadap hasil deployment, pengujian tersebut
diantaranya memastikan koneksi webserver ke dalam database telah berhasil,
konfigurasi sistem telah sesuai, dan seluruh data di dalam master data telah siap
digunakan.
Lingkungan Pengembangan
Spesifikasi minimum perangkat keras dan perangkat lunak yang dibutuhkan
untuk penelitian ini adalah:
1 Perangkat Keras
a. Processor : Intel Core i3
b. RAM : 8 GB
c. Hardisk : 256 GB
d. VGA : 512 MB
2 Perangkat Lunak
a. IDE untuk front-end : Visual Studio Code
b. IDE untuk back-end : Visual Studio 2017 Community Edition
c. DBMS : Microsoft SQL Server 2014
d. UML Case Tools : Visual Paradigm Community Edition
e. Workflow engine : Azka Workflow Engine (Azka-WF)
f. Web browser : Google Chrome
g. Package manager : npm
7
HASIL DAN PEMBAHASAN
Perancangan Arsitektur Software
BTMS yang akan dikembangkan sebagai SaaS memerlukan sebuah arsitektur
software yang digunakan dalam pengembangannya. Arsitektur dirancang untuk
melakukan standarisasi dalam fase pengembangan sistem. Arsitektur yang
dihasilkan diharapkan mampu mengakomodir kebutuhan dalam pengembangan
sistem BTMS dan memberikan kemudahan dalam maintenance.
Aplikasi yang dikembangkan dibagi menjadi 2 bagian yaitu front-end dan
back-end. Front-end dikembangkan menggunakan Angular 5, front-end bertindak
sebagai presentation layer yang akan berinteraksi langsung dengan user. Arsitektur
front-end terbagi menjadi 5 layer yaitu service, component, view, model, dan model
filter. Arsitektur pada back-end terbagi menjadi 6 layer yaitu object relational
mapping (ORM), model, model filter, data access object (DAO), service, dan Web
API. Arsitektur software diilustrasikan pada Gambar 4.
1. Front-End Arsitektur
a. View
View merupakan HTML Template yang akan ditampilkan kepada user
sebagai media interaksi antara sistem dan user (Angular 2018).
Gambar 4 Arsitektur Software
Component
Service
View
Mo
del
Mo
del
Fil
ter
Front-End
HTTP Request (POST / GET)
JSON Format
DBMS
Users
8
b. Components
Components merupakan class yang menghubungkan data pada aplikasi
dengan view. Data yang didapat oleh component akan ditampilkan melalui
HTML Template yang didefinisikan sebagai view (Angular 2018).
c. Services
Services digunakan untuk melakukan sharing data antar components, serta
melakukan post dan get data ke dalam resource server (Angular 2018).
d. Model
Model merupakan representasi dari object yang ada di dalam aplikasi.
Model yang ada pada front-end didesain mirip dengan model yang ada pada
back-end.
e. Model Filter
Model filter merepresentasikan filter apa saja yang dapat dilakukan pada
resource server.
2. Back-End Arsitektur
a. Web API
Web API berperan sebagai layer yang akan menerima request dan
memberikan response melalui protokol HTTP. Request yang diterima oleh
Web API akan diteruskan ke service layer untuk dikelola terlebih dahulu,
kesimpulan akhir yang didapat dari service layer akan dikembalikan sebagai
hasil response.
b. Service
Service pada back-end merupakan layer yang mengimplementasikan proses
bisnis dari aplikasi yang dibuat (Fowler 2003). Layer ini akan melakukan
validasi terhadap object serta melakukan manipulasi object sesuai aturan
yang telah ditentukan sebelum dilakukan proses CRUD.
c. Data Access Object (DAO)
Data Access Object (DAO) merupakan layer yang bertugas melakukan
proses CRUD ke database (Fowler 2003).
d. Object Relational Mapping (ORM)
Object Relational Mapping (ORM) memiliki tugas memetakan antara
property pada object terhadap field yang ada pada table di database (Fowler
2003).
e. Model
Model merupakan representasi dari object yang ada di dalam aplikasi.
f. Model Filter
Model filter pada back-end merupakan representasi filter yang dapat
dilakukan untuk melakukan query data ke database. Model filter pada back-
end akan mengkonversi property yang ada ke dalam bentuk fluent query.
Back-end yang dikembangkan terbagi menjadi 2 yaitu authorization server
dan resource server. Authorization server bertanggungjawab memberikan akses
token kepada user setelah user melakukan otorisasi ke dalam sistem, token yang
diberikan berisi string yang digunakan untuk autentikasi pada saat melakukan
request data pada resource server. Resource server merupakan server yang
memberikan layanan informasi yang dapat diakses aplikasi lainnya, untuk
mengakses data pada resource server pada umumnya memerlukan akses token
namun ada beberapa resource yang dapat diakses tanpa akses token. Akses token
yang dikirimkan ke dalam resource server akan berisi informasi user yang
9
melakukan request data, informasi user akan digunakan untuk autentikasi hak akses
(OAUTH 2016). Proses request token dan resource diilustrasikan pada Gambar 5.
Pembagian antara front-end dan back-end memberikan kemudahan dalam
pengembangan prototipe dan algoritma sistem. Tahap prototyping yang pertama
dikembangkan hanya front-end, pengembangan prototipe dengan arsitektur ini akan
menghasilkan prototipe yang siap digunakan dan diintegrasikan dengan back-end.
Prototype akan dijalankan menggunakan Azka Presentation Engine, presentation
engine ini memungkinkan menjalankan prototype pada tingkat penggunaan high
fidelity. Presentation engine menyediakan beberapa service dummy yang dapat
digunakan untuk mensimulasikan proses CRUD, service dummy akan
menghasilkan file JavaScript Object Notation (JSON) dengan struktur object yang
sama dengan model-nya. Sebelum menggunakan service dummy perlu dilakukan
definisi konfigurasi service dummy, contoh definisi service dummy yang dibuat
diilustrasikan pada Gambar 6.
Gambar 6 Contoh konfigurasi service dummy
Gambar 5 Token Request dan Resource Request
10
Model layer pada arsitektur back-end diimplementasikan lazy loading pattern.
Pattern ini memberikan kemudahan dalam melakukan loading terhadap property
yang me-reference ke model lainnya. Penggunaan lazy loading akan memperkecil
penggunaan memory, hal ini terjadi karena pada lazy loading data tidak langsung
di-load seluruhnya, data yang di-load hanya data-data yang diperlukan (Fowler
2002).
DAO layer pada method get data diimplementasikan eager loading pattern.
Eager loading merupakan lawan dari lazy loading. Eager loading me-load seluruh
data reference sampai kedalaman tertentu. Eager loading pada DAO layer
memberikan keuntungan performance yang lebih tinggi saat mengakses property
yang me-reference ke-object lain, hal ini terjadi karena saat melakukan query ke
database dilakukan hanya 1 kali query.
Layer back-end juga mengimplementasikan inversion of control (IoC) dan
dependency injection pattern. IoC menyimpan informasi tertentu dalam sebuah
container, dalam hal ini IoC digunakan untuk menyimpan informasi implementasi
dari interface service dan DAO. Dependency injection akan mengisi instance object
tertentu dengan implementasi object yang sesuai dengan interface-nya.
Perancangan Prototipe Iterasi 1
Komunikasi yang dilakukan pada Iterasi 1 dilakukan untuk menggali
informasi kebutuhan dasar dari BTMS. Analisa yang didapat dari hasil komunikasi
adalah BTMS memerlukan 2 fungsi utama yaitu fungsi Travel Application (TA)
dan Settlement. Penelitian ini akan mengembangkan satu fungsi utama tersebut
yaitu fungsi Travel Application. Fungsi Travel Application yang diberikan
merupakan fitur pengajuan rencana perjalanan yang dilakukan oleh pegawai
perusahaan.
Pengajuan rencana perjalanan yang dilakukan oleh pegawai memerlukan
informasi perjalanan yang cukup detail. Informasi yang dibutuhkan oleh
perusahaan pada umumnya diantaranya:
1. Penanggung Jawab
Penanggung jawab adalah pegawai yang ditunjuk oleh perusahaan untuk
mengajukan rencana perjalanan dan memberikan laporan hasil perjalanan
kepada perusahaan.
2. Tanggal Pelaksanaan
Tanggal pelaksanaan merupakan informasi tanggal perjalanan yang akan
dilaksanakan oleh para pegawai perusahaan untuk melaksanakan tugasnya
diluar kantor.
3. Kategori Perjalanan
Kategori perjalanan merupakan informasi jenis perjalanan apa yang akan
dilakukan untuk kepentingan tertentu. Kategori perjalanan ini juga berisi
informasi perjalanan dilakukan 2 arah pulang-pergi atau 1 arah (one way
trip/two way trip). Perjalanan 2 arah biasanya perjalanan yang dilakukan pada
periode yang pendek dengan waktu yang telah terukur, contohnya adalah
kegiatan seminar, kegiatan marketing, kunjungan perusahaan, dan lain-lain.
Sedangkan perjalanan 1 arah biasanya dilakukan untuk perjalanan yang waktu
kedatangan atau waktu kembali tidak terdefinisi dengan cukup jelas, yang
memiliki potensi perpanjangan perjalanan dalam waktu yang lama, contohnya
11
adalah penugasan seorang pegawai ke daerah yang berbeda dari tempat asalnya,
perjalanan ini dimaksudkan hanya dalam lingkup internal perusahaan sehingga
sifatnya mengirim atau memulangkan pegawai dari 1 cabang perusahaan ke
cabang lainnya, perjalanan yang dilakukan pun biasanya bersifat mancanegara.
4. Kota Tujuan
Kota tujuan merupakan informasi kota yang akan dikunjungi oleh pegawai.
5. Tim yang Terlibat
Perjalanan yang dilakukan melibatkan 1 atau lebih pegawai, sehingga
diperlukan informasi siapa saja yang akan ikut terlibat dalam perjalanan
tersebut.
6. Informasi Hotel
Perjalanan yang dilaksanakan lebih dari 1 hari maka diperlukan tempat untuk
menginap, informasi tempat penginapan akan dicatat sebagai informasi hotel.
7. Informasi Tiket Pesawat
Perjalanan antar kota, provinsi, maupun antar negara dengan jarak tempuh yang
jauh memerlukan penggunaan layanan pesawat terbang untuk mengefisiensi
waktu perjalanan.
8. Travel Allowance
Informasi kebutuhan biaya akan dicatat sebagai travel allowance, informasi ini
akan memberikan detail kebutuhan biaya untuk mendukung aktitas pegawai
dalam melaksanakan pekerjaannya.
Aktivitas yang dilakukan pada modul Travel Application adalah aktivitas
pengajuan dan aktivitas persetujuan. Proses pengajuan dan persetujuan dilakukan
oleh 2 aktor yang disebut requester dan approver. Requester memiliki peran untuk
membuat pengajuan, merevisi, dan meng-cancel pengajuan perjalanan. Approver
berperan dalam memeriksa dan menyetujui suatu perjalanan. Master data yang
dibutuhkan oleh modul Travel Application perlu di-mantain oleh Administrator
yang memiliki akses penuh dalam pengelolaan master data. Use case diagram pada
modul Travel Application diilustrasikan pada Gambar 7. Use case merupakan unit
fungsional yang dinyatakan sebagai transaksi yang dilakukan antara aktor dan
subjeknya (Rumbaugh et al 2005).
Gambar 7 Use case diagram Business Trip Management System
12
Informasi yang telah didapat dibuat rancangan struktur object-nya yang
selanjutnya akan dibuat dalam bentuk prototipe. Prototipe yang akan dikembangkan
pada iterasi 1 merupakan desain rancangan user interface dengan tingkat
penggunaan medium fidelity. Pengembangan prototipe dilakukan menggunakan
tools Azka Code Generator.
Prototipe yang telah dibuat dipresentasikan kepada bapak Harry, hasil
prototipe yang ditampilkan diilustrasikan pada Gambar 8. Prototipe yang
ditampilkan merupakan bentuk halaman input yang akan dikembangkan, prototipe
ini menampilkan bentuk input-an serta posisi input-an. Prototipe yang telah
ditampilkan dilakukan review untuk melihat apakah masih ada input data yang
kurang atau tidak. Jika ada input-an yang kurang maka bisa dilakukan perbaikan
pada saat itu juga. Pada kasus ini bapak Harry telah menyetujui seluruh input-an
yang telah didefinisikan dan ditampilkan. Setelah disetujui maka dilanjutkan pada
iterasi 2.
Perancangan Prototipe Iterasi 2
Iterasi 2 dilakukan pembuatan prototipe pada level high fidelity, proses
pembuatan prototipe dilakukan dengan men-generate dan men-download hasil
prototipe yang telah dibuat pada iterasi 1. Hasil yang didapat dari hasil generate
code ini adalah source code front-end dan source code back-end. Source code yang
telah didapat selanjutnya dilakukan editing pada beberapa object-nya yaitu pada
object travel destination yang terdapat pada object itinerary dan travel allowance,
proses editing ini perlu dilakukan karena sumber data yang di-generate diambil dari
data yang didapat dari service travel destination yang telah dibuat, sedangkan pada
Gambar 8 Prototipe Travel Application iterasi 1
13
modul ini data yang diambil seharusnya tidak bersumber dari service melainkan
bersumber dari data yang di-input di tab travel destination.
Setelah dilakukan penyesuaian, selanjutnya dilakukan build terhadap source
code yang ada dan men-deploy ke dalam deployment Azka Presentation Engine.
Serta meng-copy seluruh konfigurasi bahasa dan konfigurasi service prototipe yang
ada dalam paket yang telah ter-download sebelumnya. Azka Presentation Engine
menyediakan sebuah environment yang menyediakan dummy services yang dapat
langsung terintegrasi dengan service yang ada pada prototipe. Hasil prototipe iterasi
2 dipresentasikan ulang kepada bapak Harry, hasil prototipe yang dipresentasikan
diilustrasikan pada Gambar 9, feedback yang didapat dari hasil presentasi berupa
feedback positif dari AMN sehingga dapat langsung dilanjutkan pada tahap
pengembangan tanpa perlu melakukan prototipe iterasi 3.
Pengembangan Back-End dengan Metode Incremental
Fase pengembangan back-end dilakukan menggunakan metode Incremental,
yang menghasilkan 2 iterasi. Iterasi pertama adalah menghasilkan back-end dari
modul Travel Application, iterasi kedua menghasilkan back-end dari modul travel
application yang telah terintegrasi dengan workflow engine. Tahap pengembangan
dengan metode Incremental pada awalnya akan menghasilkan class diagram yang
disimpulkan dari hasil prototyping pada metode sebelumnya. Class diagram yang
dihasilkan diilustrasikan pada Gambar 10.
Gambar 9 Prototipe Travel Application iterasi 2
14
Gambar 10 Class diagram Business Trip Management System
15
Pengembangan Back-End Iterasi 1
Iterasi 1 dilakukan fase requirement berdasarkan prototipe yang telah dibuat,
fase ini menghasilkan produk document specification yang berisi informasi proses
bisnis dari modul travel application. Informasi proses bisnis yang ada di dalam
dokumen mencakup deskripsi singkat dari modul yang akan dikembangkan,
domain model, use case description, dan testing scenario. Domain model pada
document specification berisi informasi struktur object pada modul tertentu, pada
domain model dijelaskan class yang akan dikembangkan dan pemetaan antara
property object terhadap field-field di database. Use case description yang ada pada
document specification akan menjelaskan aktor-aktor yang berperan, serta aturan-
aturan yang ada di dalam sistem. Testing scenario berisi langkah-langkah pengujian
sistem termasuk hasil testing yang harus dicapai dalam setiap point pengujian.
Document specification yang telah selesai selanjutnya masuk dalam fase
development, fase development pada iterasi pertama dilakukan dengan melakukan
modifikasi source code yang telah ter-generate. Modifikasi yang dilakukan berada
pada service layer dengan melakukan penyesuaian proses bisnis berdasarkan
document specification. Penyesuaian dilakukan dengan penambahan fungsi-fungsi
untuk melakukan pemetaan object destination yang terdapat pada property
destination dalam object itinerary dan travel allowance, serta melakukan
penyesuaian pada sisi validasi data terhadap data yang dikirimkan.
Hasil development yang telah selesai tidak langsung diberikan kepada tester
untuk diuji. Hasil development akan diuji oleh programmer untuk memastikan
seluruh fungsi yang dikembangkan telah sesuai dengan output fungsi yang benar.
Pengujian yang dilakukan menggunakan unit testing yang dibuat untuk menguji
fungsi-fungsi yang telah dikembangkan. Hasil dari unit test akan keluar pada panel
test explorer yang ditandakan dengan tanda silang atau ceklis. Tanda silang
menunjukkan adanya kesalahan dari hasil pengujian. Tanda ceklis menunjukkan
fungsi sudah sesuai dengan output yang diharapkan. Contoh unit test pada test
explorer yang telah dibuat diilustrasikan pada Gambar 11.
Gambar 11 Unit Test Explorer
16
Hasil development yang telah selesai selanjutnya dilakukan pengujian pada
fase testing, pengujian yang dilakukan berdasarkan testing scenario yang telah
ditentukan pada document specification. Hasil pengujian menghasilkan 2 jenis
status pada masing-masing point testing-nya yaitu status done atau need bug fix.
Status done menandakan aplikasi telah sesuai berdasarkan testing scenario yang
diinginkan, status need bug fix menandakan adanya bug di dalam aplikasi. Kondisi
need bug fix akan langsung diserahkan kepada programmer untuk segera dilakukan
perbaikan, kondisi ini berlangsung hingga seluruh fungsi telah sesuai dengan testing
scenario yang ditentukan.
Fase code review yang dilakukan adalah memeriksa seluruh source code yang
telah dikembangkan, pada fase 1 dilakukan refactoring pada method-method
pemetaan object itinerary dan travel allowance yang tadinya berada di dalam 1
method dibagi menjadi 2 method terpisah. Selain itu dilakukan pemisahan terhadap
fungsi-fungsi validasi yang sifatnya khusus seperti pengecekan duplikasi
destination. Penentuan kode program yang akan di-refactoring dilakukan dengan
beberapa alasan diantaranya kode yang duplikat, kode program yang terlalu panjang,
dan looping yang bertingkat dengan kedalaman looping yang terlalu dalam
(McConnell 2004). Contoh refactoring yang dilakukan diilustrasikan pada Gambar
12 yang merupakan kode program sebelum dilakukan refactoring, Gambar 13
method-method hasil refactoring, Gambar 14 method yang telah mengalami
refactoring.
Fase retesting dilakukan seperti halnya fase testing, hal ini dilakukan untuk
memastikan seluruh kegiatan refactoring tidak berdampak terhadap proses bisnis
yang telah dibuat sebelumnya. Setelah software telah memenuhi seluruh testing
scenario, dilakukan persiapan implementation sistem di server. Proses
implementasi dilakukan dengan mempersiapkan query yang siap dieksekusi pada
DBMS dan men-deploy aplikasi pada server production.
Gambar 12 Method sebelum refactoring
17
Pengembangan Back-End Iterasi 2
Iterasi kedua dilakukan dengan penambahan informasi integrasi antara
aplikasi dan workflow pada document specification. Informasi yang ditambahkan
adalah tata cara mengintegrasikan aplikasi dengan workflow, serta aturan bisnis
mengenai kondisi dokumen saat diberikan aksi approve, reject, request for revision,
dan cancel.
Fase development pada iterasi kedua dilakukan dengan menambahkan
beberapa web service yang disediakan untuk diakses oleh workflow, untuk
menangani setiap action yang dipilih pada workflow. Method yang dikembangkan
pada penelitian ini adalah method untuk menangani proses authentication, approve,
reject, request for revision, dan cancel.
Gambar 13 Method hasil refactoring
Gambar 14 Method setelah refactoring
18
Proses authentication dilakukan dengan cara melakukan pengecekkan header
information berupa informasi API key yang dikirimkan dari workflow engine.
Workflow engine akan menyimpan informasi API key yang digunakan untuk meng-
invoke API pada sisi aplikasi BTMS. Header key yang menyimpan informasi API
key adalah “api_key”.
Workflow yang dikembangkan selanjutnya akan menyesuaikan kebutuhan
masing-masing perusahaan. Pada penelitian ini dibuat contoh kasus untuk
mensimulasikan integrasi antara workflow dan aplikasi BTMS. Proses simulasi
dilakukan dengan menggunakan contoh kasus proses approval pada pengajuan
Travel Application. Tahapan yang dilakukan pada sisi workflow diantaranya
mendefinisikan tipe dokumen, meregistrasikan web service yang telah dibuat,
melakukan konfigurasi email, dan mendefinisikan workflow.
Tipe dokumen pada workflow engine didaftarkan pada modul WF Document
Type pada Azka-WF. Pada kasus ini dokumen didaftarkan dengan nama “Travel
Application” yang disertakan dengan informasi company. Registrasi tipe dokumen
diilustrasikan pada Gambar 15.
Method-method approval yang dibuat diregistrasikan ke dalam workflow
engine melalui modul WS Configuration yang ada pada Azka-WF. Data yang
diregistrasikan pada modul tersebut adalah informasi alamat web service dan API
key. Method yang telah diregistrasikan dapat langsung dilakukan pengujian koneksi
ke dalam API yang dituju dengan melakukan pengecekan web service pada halaman
tersebut. Halaman registrasi web service pada workflow engine diilustrasikan pada
Gambar 16.
Kebutuhan pengiriman email pada sisi workflow dilakukan dengan
meregistrasikan alamat email yang digunakan untuk mengirimkan email pada
modul WF Mail Configuration. Konfigurasi yang di-support pada workflow adalah
menggunakan Simple Mail Transfer Protocol (SMTP) atau menggunakan layanan
SendGrid. Halaman konfigurasi email untuk kebutuhan pengiriman email
diilustrasikan pada Gambar 17.
Pendefinisian workflow dilakukan dengan membuat konfigurasi workflow
pada modul WF Configuration. Konfigurasi yang dibuat dapat ditentukan untuk
siapa saja workflow akan diimplementasikan, pilihan pengimplementasian yang
disediakan terdapat 4 pilihan yaitu user, group, position, atau all. Setiap garis yang
didefinisikan pada workflow engine merupakan action yang dapat dipilih. Masing-
masing garis pada workflow memiliki definisi algoritma yang berbeda-beda sesuai
Gambar 15 Registrasi Tipe Dokumen
19
kebutuhan masing-masing perusahaan. Definisi konfigurasi workflow diilustrasikan
pada Gambar 18.
Gambar 16 Registrasi web service pada workflow engine
Gambar 17 Konfigurasi email pada workflow engine
20
Konfigurasi yang didefinisikan pada WF Configuration akan disimpan dalam
bentuk JSON. JSON akan di-generate ke dalam bentuk kode program dan di-
compile secara on the fly saat instance berjalan. Sehingga instance yang berjalan
akan berjalan sesuai alur yang telah ditentukan. Proses edit terhadap suatu
konfigurasi akan menghasilkan versi yang berbeda. Saat WF Configuration
dilakukan editing maka instance yang sedang berjalan tidak akan mengikuti
konfigurasi yang baru melainkan akan menggunakan konfigurasi yang lama,
sedangkan instance yang baru akan mengikuti konfigurasi yang paling terakhir.
Konfigurasi yang dibuat dapat dilakukan simulasi pada modul WF Instance.
Modul WF Instance merupakan modul yang digunakan untuk me-monitoring, me-
mantain, dan menguji instance workflow. Pengujian dilakukan dengan membuat 1
instance dengan memberikan informasi company, initiator, dan document type.
Pembuatan instance pada modul WF Instance diilustrasikan pada Gambar 19.
Gambar 19 Registrasi instance workflow
Gambar 18 Konfigurasi workflow
21
Setiap action yang telah didefinisikan dalam Azka-WF dapat di-invoke
melalui API yang disediakan dari Azka-WF. Method yang ada telah dienkapsulasi
di dalam library AzkaWFClient. Method yang ada pada AzkaWFClient diantaranya
CancelInstance untuk mengbatalkan instance workflow, ExecuteInstance untuk
menjalankan instance workflow berdasarkan action tertentu, CreateInstance untuk
membuat sebuah instance workflow untuk dokumen tertentu, GetInbox untuk
mengambil daftar inbox dari user, dan lain-lain.
Aplikasi BTMS yang telah terintegrasi akan berjalan dengan beberapa
tahapan. User akan membuat request Travel Application yang di-submit ke dalam
sistem BTMS. Sistem BTMS akan meng-invoke API pada workflow engine untuk
membuat sebuah instance baru pada Azka-WF. Instance akan dijalankan sesuai
rules yang ada pada workflow engine. Workflow engine akan menjalankan instance
workflow dari pengajuan yang dikirimkan dan meng-update status dokumen sesuai
dengan pilihan yang diambil oleh para approver. Proses update status dokumen
terjadi ketika workflow engine meng-invoke method yang ada pada BTMS, method
yang di-invoke adalah approve, reject, atau request for revision.
Fase testing pada iterasi kedua dilakukan dengan 2 keadaan, yaitu pengujian
pada server lokal dan pengujian pada server yang telah bisa diakses dari public.
Pengujian sisi komputer lokal dilakukan dengan meng-inject data langsung ke
dalam web service melalui aplikasi rest client, hal ini dilakukan karena service dari
Azka-WF saat ini belum memungkinkan melakukan inject web service ke dalam
komputer lokal. Setelah setiap fungsi telah dipastikan sesuai, maka dilakukan
pengujian pada server yang telah bisa diakses dari public. Fase code review dan
retesting tidak dilakukan pada iterasi 2 karena method yang dikembangkan cukup
sederhana dan tidak adanya spaghetti code yang ditemukan pada iterasi 2.
SIMPULAN DAN SARAN
Simpulan
Fungsi Travel Application pada Business Trip Management System (BTMS)
telah selesai diimplementasikan. Pengembangan dilakukan menggunakan 2 metode
yaitu Evolutionary Prototyping dan Incremental. Metode Evolutionary Prototyping
memberikan kemudahan dalam analisis kebutuhan sistem, implementasi metode di
dalam penelitian ini menghasilkan prototipe sistem sesuai dengan kebutuhan,
prototipe yang dihasilkan siap dikembangkan tanpa membuang prototipe yang telah
ada. Metode Incremental yang digunakan memberikan kemudahan dalam fase
pengembangan fungsi, fungsi dapat diselesaikan dengan beberapa iterasi tanpa
mengganggu pengembangan fungsi lainnya, karena setiap iterasi menghasilkan
produk fungsi yang berbeda.
Fungsi yang dikembangkan telah terintegrasi dengan workflow engine.
Integrasi antara Travel Application dan workflow engine telah berhasil diuji coba,
pengujian yang dilakukan diantaranya proses pembuatan instance yang di-invoke
dari Travel Application ke dalam workflow engine, proses approval yang dilakukan
melalui Travel Application telah berhasil dilakukan dan bersesuaian dengan alur
yang telah didefinisikan di dalam workflow engine, proses cancel instance yang
dilakukan pada Travel Application telah berhasil mematikan instance workflow
22
yang berjalan pada workflow engine, dan method yang ada pada Travel Application
telah berhasil di-invoke oleh workflow engine melalui web api. Pemisahan antara
Travel Application dan workflow engine memberikan kemudahan modifikasi
workflow setiap perusahaan sesuai dengan kebutuhan masing-masing perusahaan
tanpa perlu mengubah logika program pada fungsi Travel Application.
Saran
Peneletian selanjutnya dapat dilakukan pengembangan fungsi Settlement
yang digunakan untuk membuat laporan pertanggungjawaban perjalanan.
DAFTAR PUSTAKA
[Angular]. 2018. Angular Architecture Overview [Internet]. [diakses tanggal 22 Juli
2018]. Tersedia pada: https://angular.io/guide/architecture
Buschmann F, Henney K, Schmidt DC. 2007. Pattern-Oriented Software
Architecture a Pattern Language for Distributed Computing. Volume ke-4.
West Sussex (EN): John Wiley & Sons Ltd.
Fowler M. 2003. Patterns of Enterprise Application Architecture. Boston (US):
Pearson Education, Inc.
[Fowler]. 2014. Unit Test [Internet]. [diakses tanggal 22 Juli 2018]. Tersedia pada:
https://martinfowler.com/bliki/UnitTest.html
Georgakopoulos D, Hornick M. 1995. An Overview of Workflow Management:
From Process Modeling to Workflow Automation Infrastructure. Boston (NL):
Kluwer Academic Publishers.
McConnell S. 2004. Code Complete. Volume ke-2. Washington (US): Microsoft
Press.
[OAUTH]. 2016. Definitions - OAuth 2.0 Servers [Internet]. [diakses tanggal 22
Juli 2018]. Tersedia pada: https://www.oauth.com/oauth2-servers/definitions/
Osherove R. 2014. The Art of Unit Testing. Volume ke-2. New York (US): Manning
Publications Co.
Pressman RS. 2010. Software Engineering a Practitioner’s Approach. Volume ke-
7. New York (US): McGraw-Hill.
Rocholl A. 2009. Business Travel Management Strategies. Ways to establish an
efficient business travel management program and successfully react to future
trends. Deutschland (DE).
Rumbaugh J, Jacobson I, Booch G. 2005. The Unified Modeling Language
Reference Manual. Volume ke-2. Massachusetts (US): Addison-Wesley.
23
RIWAYAT HIDUP
Yurizal Rosa Andika lahir pada tanggal 26 Juni 1992 di Bogor. Penulis
merupakan anak ke dua dari tiga bersaudara dari pasangan Bapak Syahrial Ambun
Suri dan Ibu Eti Rohaeti. Tahun 2010 penulis menyelesaikan pendidikan dari SMA
PGRI 4 Bogor. Tahun yang sama penulis melanjutkan pendidikan pada program
D3, jurusan Management Informatika, Institut Pertanian Bogor. Tahun 2013
penulis menyelesaikan program D3. Tahun 2015 penulis lulus seleksi masuk
program Sarjana Alih Jenis, Departemen Ilmu Komputer, Fakultas Matematika dan
Ilmu Pengetahuan Alam, Institut Pertanian Bogor.
