1
ANALISIS
3.1 Analisis Model Business Process Outsourcing
Dari beberapa penjelasan mengenai model Business Process Outsourcing (BPO) pada subbab 2.3.1, diajukan Gambar III.1 sebagai gambaran umum dari BPO pada Tugas Akhir ini. Beberapa alasan dasar dalam mengajukan gambar tersebut adalah karena:
1. BPO memiliki dua aktor utama sebagai pelaku bisnis yaitu perusahaan pengguna layanan BPO dan penyedia layanan BPO, sehingga pada Gambar III.1 perusahaan pengguna layanan BPO digambarkan sebagai sebuah kotak bergaris bernama
Company, sedangkan penyedia layanan BPO digambarkan sebagai sebuah kotak
bergaris dengan nama Outsourcing Company.
2. Hubungan antara kedua aktor tersebut adalah pengerjaan business process dari perusahaan pengguna yang bukan merupakan core-competence-nya oleh penyedia layanan BPO.
Pada Gambar III.1, akan digambarkan hubungan BPO antara perusahaan-perusahaan pengguna layanan dan penyedia layanan. Pada gambar tersebut, business process digambarkan sebagai sebuah elips yang terdapat keterangan core untuk core-competence perusahaan, dan non core untuk business process yang bukan merupakan core-competence perusahaan tersebut.
Gambar III.1 B usiness Process Outsourcing secara umum
BPO Company #2 Core Business P rocess Core Business P rocess Core Business P rocess Non Core
Business P rocess Company #n Core Business P rocess Core Business P rocess Core Business P rocess Non Core Business P rocess Company #1 Core Business P rocess Core Business P rocess Core Business P rocess Non Core Business P rocess Outsourcing Company Non Core Business P rocess Non Core Business P rocess Non Core Business P rocess
Pada Gambar III.1, terdapat dua aktor utama BPO, yaitu: perusahaan (Company) dan penyedia layanan (Outsourcing Company). Setiap perusahaan memiliki banyak business
process, namun tidak semua business process tersebut adalah core-competence dari
perusahaan pengguna layanan. Dengan menggunakan konsep BPO, business process yang bukan merupakan core-competence perusahaan pengguna akan diserahkan atau dikerjakan oleh penyedia layanan BPO (dalam hal ini business process digambarkan sebagai elips dengan garis putus-putus). Panah pada gambar dari Company menuju Outsourcing Company artinya perpindahan pengerjaan business process dari perusahaan pengguna menuju perusahaan penyedia layanan BPO. Hasil pengerjaan business process tersebut akan diserahkan kembali pada perusahaan pengguna layanan BPO, digambarkan dengan panah dari
Outsourcing Company menuju Company.
3.2 Analisis Model Business Process Reporting Service
Berdasarkan teori pada subbab 2.2, 2.3, dan 2.4, Business Process Reporting Service diajukan sebagai contoh aplikasi yang mendukung Business Process Outsourcing (BPO) dalam bidang pelaporan data. Mengacu pada Gambar II.2 , pelaporan data termasuk dalam jenis dataprocessing yang bukan merupakan non-core business process perusahaan, sehingga dapat
dilakukan outsourcing untuk hal ini.
Definisi Business Process Reporting Service ini adalah sebuah aplikasi yang akan menangani pemodelan pembuatan laporan suatu perusahaan. Secara umum, fungsi dari aplikasi ini adalah membuat pelaporan data suatu perusahaan dengan menggunakan konsep BPO.
Sesuai dengan definisi BPO pada subbab 3.1, terdapat dua aktor pada Business Process
Reporting Service, yaitu: penyedia layanan BPO dan pengguna layanan. Berikut adalah
pembagian peran antara penyedia layanan dan pengguna layanan pada Business Process
Reporting Service:
1. Penyedia layanan BPO:
a. Menyediakan media penyimpanan data mentah.
b. Menyediakan mekanisme pengumpulan data mentah dari konsumen layanan. c. Menyediakan fungsi-fungsi yang dibutuhkan untuk mengolah data mentah
menjadi laporan.
d. Menyediakan fasilitas untuk mendefinisikan proses pengolahan data mentah menjadi laporan.
e. Membangkitkan laporan dari data mentah yang diolah berdasarkan definisi proses (d).
f. Menjaga kode etik kerahasiaan data agar hanya bisa diakses oleh pihak yang berhak mengakses data tersebut, baik data mentah maupun laporan yang bernilai informasi.
2. Pengguna layanan (perusahaan): a. Mendefinisikan data mentah.
b. Mendefinisikan proses pengolahan data mentah menjadi laporan.
c. Mengumpulkan data mentah ke penyedia layanan dengan menggunakan mekanisme yang telah disediakan.
Dengan model seperti ini, diharapkan akan didapat beberapa keuntungan bagi pengguna layanan:
1. Data mentah terkumpul secara sistematis dan aman.
2. Mudah mengubah atau menambah proses pembuatan laporan.
3. Tidak perlu membuat divisi tersendiri yang mengurusi proses pembuatan laporan. 4. Laporan bisa didapat kapan saja dan dimana saja (dengan syarat media untuk
mengakses layanan tersedia).
Mengacu pada subbab 3.1 dan pembagian peran pengguna layanan dan penyedia layanan pada Business Process Reporting Service, didapatkan keterhubungan bahwa perusahaan pengguna layanan BPO hanya perlu memberikan business process berupa laporan kepada perusahaan penyedia layanan BPO kemudian akan mendapatkan hasil berupa laporan. Oleh karena itu, pada Business Process Reporting Service dibutuhkan bagian yang menangani pemodelan business process perusahaan pengguna layanan, dan dibutuhkan pula bagian yang akan membangkitkan laporan sesuai dengan pemodelan tersebut.
Berdasarkan kebutuhan bagian-bagian seperti yang telah dijelaskan diatas, Business Process
Reporting Service yang diajukan pada dasarnya terdiri dari tiga subsistem yang saling
berkaitan yang dapat dilihat gambaran umumnya pada Gambar III.2, yaitu: 1. Subsistem pemodelan definisi proses pembuatan laporan perusahaan.
2. Subsistem penerimaan data mentah melalui FTP yang merupakan bahan untuk membuat laporan, pengolahan data tersebut, serta pembangkitan laporan dengan mengacu pada definisi proses pembuatan laporan yang dihasilkan subsistem pada nomor 1.
3. Subsistem penerimaan data mentah melalui SMS yang merupakan bahan untuk membuat laporan, pengolahan data tersebut, serta pembangkitan laporan dengan mengacu pada definisi proses pembuatan laporan yang dihasilkan subsistem pada nomor 1.
Gambar III.2 B usiness Process Reporting Service
Keterangan Gambar III.2:
1. Bagian ini menjelaskan bahwa Business process sebuah perusahaan akan digambarkan dalam bentuk gambar-gambar service pada subsistem pertama dengan memanfaatkan daftar fungsi pengolahan laporan yang disediakan oleh subsistem kedua dan subsistem ketiga, sehingga hasil dari aplikasi subsistem pertama adalah definisi proses pengolahan laporan.
2. Bagian ini menjelaskan bahwa data yang berukuran besar akan diterima oleh subsistem dua melalui media FTP, kemudian berdasarkan definisi proses pengolahan laporan yang diterima dari subsistem satu, data tersebut akan diolah untuk membangkitkan laporan.
3. Bagian ini menjelaskan bahwa data yang berukuran kecil akan diterima oleh subsistem tiga melalui media SMS, kemudian berdasarkan definisi proses pengolahan laporan yang diterima dari subsistem satu, data tersebut akan diolah untuk membangkitkan laporan. Subsistem 2 Data Mentah (FTP) Laporan Subsistem 3 Data Mentah (SMS) Laporan Business Process Subsistem 1 Definisi Proses Pengolahan Laporan Daftar Fungsi Pengolahan Laporan Daftar Fungsi Pengolahan Laporan
1
2
3
3.2.1 Arsitektur Sistem
Sesuai dengan gambaran umum mengenai pembagian subsistem Business Process Reporting
Service pada Gambar III.2, didapatkan bahwa arsitektur sistem secara keseluruhan terbagi
menjadi tiga subsistem. Hubungan antara setiap subsistem berupa penyediaan fungsi pengolahan laporan serta definisi proses pengolahan laporan. Tiga subsistem dari Business
Process Reporting Service meliputi pemodelan definisi proses pembuatan laporan perusahaan,
penerimaan data mentah melalui FTP, dan penerimaan data mentah melalui SMS. Dari ketiga subsistem tersebut terdapat bagian-bagian yang sama dan digunakan oleh masing-masing subsistem seperti:
1. Untuk membangkitkan laporan berdasarkan definisi proses pengolahan laporan, subsistem kedua dan ketiga membutuhkan bagian pembangkit laporan. Dalam kasus ini bisa disebut dengan Report Generator.
2. Untuk menyediakan daftar fungsi pengolahan laporan yang akan digunakan oleh subsistem pertama, subsistem kedua dan ketiga membutuhkan bagian penyedia fungsi. Dalam kasus ini bisa disebut dengan FunctionProvider.
3. Data mentah yang diterima oleh subsistem kedua dan ketiga perlu untuk disimpan dalam basis data. Oleh karena itu, dibutuhkan bagian yang akan menyimpan data mentah dalam basis data. Dalam kasus ini bisa disebut dengan Database.
Sedangkan bagian-bagian yang berbeda pada setiap subsistem adalah:
1. Bagian untuk memodelkan business process pembuatan laporan suatu perusahaan menjadi definisi proses pengolahan laporan pada subsistem pertama. Dalam kasus ini bisa disebut dengan Business Process Generator.
2. Bagian untuk menerima data mentah dari FTP pada subsistem kedua. Dalam kasus ini bisa disebut dengan FTP Server.
3. Bagian untuk menerima data mentah dari SMS pada subsistem ketiga. Dalam kasus ini bisa disebut dengan SMS Gateway.
Oleh karena itu, jika dijumlah akan didapatkan 6 bagian penting pada Business Process
Reporting Service yaitu 3 bagian yang sama untuk setiap subsistem, dan 3 bagian berbeda
untuk masing-masing subsistem.
Untuk lebih jelasnya, pada Gambar III.3 ditampilkan arsitektur sistem secara lebih detil dari
FTP Server SMS Gateway
Database
Function Provider Business Process Generator
Report Generator Business Process Reporting Service
Reporter
Reporter
Reporter
Reporter
Report Getter
Gambar III.3 Arsitektur Sistem Busi ness Process Reporting Service
Gambar III.3 mewakili gambaran umum dari Business Process Outsourcing yang diajukan pada Gambar III.1, di mana perusahaan pengguna layanan BPO berada diluar sistem (Report
Getter). Report Getter akan mendefinisikan proses pembuatan laporan berdasarkan business process perusahaannya dan mendapatkan laporan hasil olahan aplikasi. Gambar III.1 juga
menjelaskan arsitektur lebih detil dari penjelasan pada Gambar III.2, dimana terdapat 6 bagian dari Business Process Reporting Service. Penjelasan setiap bagian secara detailnya adalah sebagai berikut:
a. Report Getter
Report Getter merupakan pihak yang menjadi klien dari layanan pembuatan laporan.
Pihak ini akan menggunakan komputer untuk:
1 Mendefinisikan data mentah yang akan disimpan.
2 Mendefinisikan proses pengolahan data mentah menjadi laporan. 3 Mendapatkan laporan.
b. Reporter
Reporter merupakan pihak yang bertanggung jawab untuk mengirim data mentah
untuk disimpan di layanan pembuatan laporan. Reporter dapat mengirimkan data mentah melalui SMS maupun FTP
c. Report Generator (RG)
Report Generator merupakan bagian dari sistem yang bertanggung jawab untuk
mengolah data mentah dan membuat laporan. RG akan menerima data mentah dan
a b c d e f g h
definisi proses pengolahan data mentah menjadi laporan. Ketika Report Getter meminta laporan, RG akan mengambil data mentah dari database kemudian mengolahnya menggunakan fungsi-fungsi yang disediakan oleh Function Provider berdasarkan definisi proses pengolahan data dari Business Process Generator.
d. Business Process Generator (BPG)
Business Process Generator merupakan bagian yang bertanggung jawab untuk
mendefinisikan proses pengolahan data mentah menjadi laporan. Fungsi-fungsi untuk mendefinisikan proses pengolahan data tersebut didapatkan dari Function Provider melalui hubungan web service.
e. Function Provider (FP)
Function Provider merupakan bagian yang bertanggung jawab untuk menyediakan
fungsi-fungsi pengolahan data mentah. Fungsi-fungsi di sini bisa ditambah, dikurangi dan diubah sesuai dengan keperluan..
f. FTP Server
FTP Server merupakan bagian yang bertanggung jawab untuk menerima data mentah yang berukuran besar. Bagian ini akan melakukan validasi pada data mentah, sehingga data yang masuk adalah valid. Setelah melakukan validasi, FTP Server akan memasukkan data mentah tersebut ke database.
g. SMS Gateway
SMS Gateway merupakan bagian yang bertanggung jawab untuk menerima data mentah yang berformat SMS. Bagian ini akan melakukan validasi pada data mentah, sehingga data yang masuk adalah valid. Setelah melakukan validasi, SMS Gateway akan memasukkan data mentah tersebut ke database.
h. Database
Database merupakan bagian yang bertanggung jawab untuk menyimpan data mentah
klien. Semua data mentah yang masuk disimpan di sini.
Karena Tugas Akhir ini bertujuan untuk membuat salah satu subsistem dari Business Process
Reporting Service yaitu SMS Based Service, maka dibutuhkan suatu server SMS untuk
mengirim maupun menerima pesan singkat. Untuk itulah terdapat SMS Gateway pada arsitektur sistem. Arsitektur sistem pada Business Process Reporting Service subsistem SMS
3.2.2 Analisis BPEL-like XML
Sistem besar Business Process Reporting Service menggunakan BPEL untuk mendefinisikan proses pengolahan datanya. Namun terdapat beberapa kerumitan dalam tahap implementasi seperti:
1. Untuk merepresentasikan definisi proses pengolahan data tidak diperlukan tag-tag yang harus sesuai dengan BPEL karena tidak akan dieksekusi oleh BPEL Engine yang sudah ada. Selain itu, konsep dasar dari definisi proses pengolahan data ini adalah pemanggilan fungsi-fungsi web service yang disediakan oleh subsistem SMS
Based Service dan FTP Based Service sehingga tidak perlu membuat tag yang sesuai
dengan BPEL.
2. Tag BPEL harus sesuai dengan standar OASIS[OAS08] sehingga dibutuhkan effort lebih untuk mendaftarkan tag baru yang sesuai dengan Tugas Akhir ini kepada OASIS.
3. Implementasi subsistem Business Process Generator cukup sulit apabila harus memenuhi kaidah-kaidah pembuatan BPEL, karena harus membuat kode-kode yang sesuai dengan engine BPEL yang sudah ada, sehingga subsistem Business Process
Generator ini dibuat sendiri tanpa memanfaatkan engine BPEL yang telah ada.
Maka dari itu, didefinisikan Tag BPEL-like dengan tujuan menyesuaikan dengan kebutuhan aplikasi subsistem Business Process Generator dan memudahkan pertukaran data.
Tag BPEL-like dibangun dengan mengadopsi konsep BPEL yang telah dijelaskan pada
subbab 2.6.2. Beberapa contoh pengadopsian tersebut adalah penggunaan tag untuk memanggil fungsi web service seperti pada contoh tag <invoke> dari BPEL menjadi tag <function> , kemudian parameter setiap fungsi yang terdapat pada tag <invoke> akan dibuat menjadi tag sendiri yaitu <parameter> untuk merepresentasikan parameter fungsi pengolahan data. Tag BPEL-like ini disimpan dalam sebuah file XML yang merepresentasikan definisi proses pengolahan data yang didapatkan dari subsistem Business
Process Generator. Tag-tag tersebut dibangun sebagai berikut:
1. <report>
Tag ini digunakan sebagai root tag untuk mendefinisikan laporan yang akan
dibangkitkan.
2. <function>
Tag ini digunakan untuk memanggil fungsi yang telah disediakan oleh subsistem FTP Based Service dan SMS Based Service. Function memiliki attribut nama fungsi.
3. <tabel>
Tag ini digunakan untuk menyimpan tabel basis data perusahaan.
4. <parameter>
Tag ini digunakan untuk menyimpan parameter sebuah fungsi.
Tag-tag ini akan disimpan dalam sebuah file .xml yang akan menjadi masukan bagi Business Process Reporting Service subsistem SMS Based Service untuk mengolah data mentah.
Sebagai contoh, format Tag BPEL-like untuk memanggil fungsi dari SMS Based Service untuk melihat total barang1 yang disimpan di gudang perusahaan Budi adalah sebagai berikut: <?xml version="1.0" encoding="ISO-8859-1"?> <report> <function name="sumByValues"> <tabel>budi</tabel> <parameter>simpan</parameter> <parameter>barang1</parameter> </function> </report>
Fungsi sumByValues adalah fungsi yang mengembalikan laporan jumlah barang (dalam contoh diatas adalah barang1) sesuai dengan perintah sms yang diterima (dalam contoh diatas adalah simpan) pada tabel database perusahaan (dalam contoh diatas adalah budi)
3.2.3 Analisis Fitur Sistem
3.2.3.1 Perbandingan dengan Aplikasi Sejenis
Aplikasi perangkat lunak yang mempunyai fitur penanganan pembuatan laporan tidak hanya dimiliki oleh Business Process Reporting Service saja, tetapi terdapat aplikasi lain yang sudah ada terlebih dahulu seperti: BIRT dan LogiReport.
BIRT adalah aplikasi pengolah laporan berbasiskan open source yang merupakan plugin dari
Eclipse, salah satu Integrated Desktop Environment (IDE) populer dalam pengembangan
aplikasi berbasiskan Java. Beberapa fitur dari BIRT adalah [BRT08]:
1. Jenis chart yang bisa ditampilkan berbagai macam bisa berupa list, chart, crosstabs,
letters & documents, business logic, dan presentasi.
2. BIRT merupakan plugin dari IDE Eclipse
3. BIRT merupakan API java yang bisa menghasilkan berbagai jenis laporan. 4. Dapat ditampilkan dalam bentuk web.
Gambar III.4 Skema B IRT pada pe mbuatan lapor an
Sedangkan LogiReport adalah aplikasi pengolah laporan berbasiskan web yang dibuat oleh perusahaan LOGIXML. Beberapa fitur dari LogiReport adalah [LGR08]:
1. Dapat membuat berbagai jenis presentasi laporan, seperti chart, tabel, dan sebagainya. 2. Laporan dapat diekspor ke dalam bentuk lain, baik itu pdf, excel, dan sebagainya. 3. Laporan dapat dibangun sesuai dengan kode program.
4. Dapat ditampilkan dalam bentuk web.
Dari kedua aplikasi diatas, terdapat beberapa kekurangan yang dapat dituliskan sebagai berikut:
1. BIRT merupakan API pembuat laporan sehingga dibutuhkan aplikasi diatasnya untuk membuat suatu laporan.
2. Data laporan didapat dari database, tidak ada fitur terintegrasi yang mengumpulkan data tersebut.
3. Sistem yang ada merupakan sistem untuk organisasi/perusahaan, bukan merupakan layanan outsourcing dimana siapapun yang menginginkan layanan tersebut bisa menyewa untuk beberapa waktu.
4. Fleksibilitas pendefinisian proses pembuatan laporan kurang (laporan hanya menampilkan data yang ada di database, tidak mengolah data mentah hingga menjadi laporan jadi).
3.2.3.2 Fitur Sistem
Sesuai dengan penjelasan pada subbab 3.2.3.1, Business Process Reporting Service diajukan sebagai aplikasi pembuatan laporan berdasar konsep BPO di antaranya yaitu:
1. Fitur Fungsional
Berikut adalah fitur fungsional yang dimiliki oleh sistem Business Process Reporting
a. Pengumpulan data mentah
Sistem memiliki fitur dimana pengguna layanan bisa mengumpulkan data mentah yang dimiliki untuk diolah menjadi laporan. Salah satu metode pengumpulan data mentah yang akan diimplementasikan pada tugas akhir ini adalah pengumpulan data melalui SMS.
b. Validasi masukan data mentah
Aplikasi akan melakukan validasi data mentah yang dikirimkan sesuai dengan format yang telah ditentukan.
c. Kemampuan menghasilkan laporan sesuai dengan definisi proses pengolahan data yang diterima.
Menghasilkan laporan berformat pdf dengan menggunakan fungsi-fungsi yang dapat didefinisikan sendiri proses pengolahan datanya. Template laporan akan disediakan oleh sistem.
d. Pengaturan layanan yang aktif.
Mengatur layanan-layanan pembuatan laporan yang aktif, meliputi pembuatan layanan baru, menonaktifkan layanan yang ada, dan sebagainya. e. Pengaturan Report Getter.
Mengatur orang-orang yang bisa melihat atau mendapatkan laporan yang telah dibuat.
f. Daftar fungsi pengolahan laporan agar bisa dibaca oleh Business Process
Generator .
Membuat daftar fungsi pengolahan laoran tersedia yang bisa dibaca oleh subsistem Business Process Generator.
2. Fitur Non-Fungsional
Aspek-aspek penting yang perlu diperhatikan dalam pembangunan sebuah aplikasi layanan adalah:
a. Kenyamanan dan kemudahan penggunaan.
Aplikasi outsourcing harus memiliki tampilan antarmuka yang nyaman digunakan serta mudah dipelajari dan digunakan.. Hal ini mengingat aplikasi ini dibuat untuk banyak pelanggan yang umum, tidak dibuat secara spesifik untuk pelanggan tertentu.
b. Dokumentasi penggunaan dan pengembangan
Aplikasi outsourcing dilengkapi dengan manual penggunaan dan pengembangan aplikasi lebih lanjut untuk digunakan mengembangkan layanan maupun bug tracking.
c. Keamanan data
Aplikasi harus memiliki sistem autentikasi yang akan membedakan hak akses setiap pengguna untuk mengamankan data.
3.3 Analisis Subsistem SMS Based Service
3.3.1 Arsitektur Sistem Subsistem SMS Based Service
Arsitektur subsistem SMS Based Service dapat digambarkan seperti dalam Gambar III.5.
SMS Gateway
Database
Function Provider Business Process Generator
Report Generator Business Process Reporting Service subsistem SMS Based
Service
Reporter
Reporter
Report Getter
Gambar III.5 Arsitektur Busine ss Process Reporting Service subsistem S MS Based Service
Gambar III.5 adalah gambar arsitektur Business Process Reporting service yang telah disederhanakan dari sebelumnya pada Gambar III.3. Penjelasan dari setiap bagian pada Gambar III.5 terdapat pada subbab 3.2.1, dengan tambahan informasi bahwa bagian Business
Process Generator berada diluar subsistem SMS Based Service karena bagian tersebut
menjadi aktor pada subsistem ini. Sedangkan bagian FTP Server tidak disertakan karena bagian tersebut tidak berhubungan dengan subsistem ini.
1 2 3 4 5 6 7 8
Aliran proses subsistem SMS Based Service pada Business Process Reporting Service dalam membangkitkan laporan dapat dijelaskan pada setiap garis panah bernomor pada Gambar III.5 yang akan dijelaskan sebagai berikut:
1. Business Process Generator (BPG) mengambil daftar fungsi-fungsi pengolahan data yang tersedia dari Function Provider melalui web service. BPG menampilkan fungsi-fungsi tersebut dalam diagram gambar yang bisa diatur sedemikian rupa oleh Report
Getter untuk mendefinisikan proses pengolahan data.
2. BPG menyimpan definisi proses pengolahan data tersebut untuk digunakan oleh
Report Generator (RG) dalam membangkitkan laporan.
3. RG dapat memberikan format input benar kepada SMS Gateway untuk memastikan bahwa input data mentah sesuai dengan aturan. Tetapi jika tidak, SMS Gateway sendiri sudah memiliki validasi untuk menangani format SMS yang diterima.
4. Reporter mengirim SMS ke SMS Gateway. SMS Gateway akan mengecek SMS masuk apakah sesuai dengan constraint yang telah didefinisikan oleh RG.
5. Jika format input benar, SMS Gateway menyimpan data mentah tersebut ke dalam
database.
6. RG mengambil data mentah dari database.
7. RG mengambil fungsi dari Function Provider, kemudian mengolahnya hingga menjadi laporan.
8. Report Getter menerima laporan.
3.3.2 Fitur Subsistem SMS Based Service
Berdasarkan fitur sistem yang telah dijelaskan pada subbab 3.2.3.2, dibuat Software Requirement Specification (SRS) yang dapat dilihat lebih detil pada Tabel III.1dan Tabel III.3. Sedangkan keterhubungan antara fitur sistem yang sudah pernah dibahas sebelumnya dengan SRS dapat dilihat pada Tabel III.4.
Berikut adalah fitur yang harus dimiliki oleh sistem Business Process Reporting Service subsistem SMS Based Service adalah sebagai berikut:
1. Fitur Fungsional
Pada Tabel III.1 terdapat penjelasan fitur yang diajukan untuk memenuhi kebutuhan fungsional perangkat lunak.
Tabel III.1. SRS Fungsional Perangkat Lunak
SRS Fungsional Ke terangan
SRS-F-01 Admin istrator aplikasi dapat melihat list dari pengguna aplikasi. SRS-F-02 Admin istrator aplikasi dapat mela kukan pena mbahan pengguna. SRS-F-03 Admin istrator aplikasi dapat mela kukan pengubahan data pengguna. SRS-F-04 Admin istrator aplikasi dapat menghapus pengguna.
Tabel III.2. SRS Fungsional Perangkat Lunak (lanjutan)
SRS Fungsional Ke terangan
SRS-F-06 Admin istrator aplikasi dapat mela kukan pengubahan informasi perusahaan.
SRS-F-07 Admin istrator aplikasi dapat menghapus perusahaan.
SRS-F-08 ReportGetter dapat melihat list BPEL yang masuk ke da la m aplikasi
sesuai dengan perusahaannya.
SRS-F-09 Report Getter dapat melihat list SMS yang masuk ke dala m aplikasi
sesuai dengan perusahaannya.
SRS-F-10 Aplikasi dapat menerima defin isi proses pengolahan data yang dikirimkan oleh Business Process Generator.
SRS-F-11 Aplikasi dapat menerima SMS dari Reporter.
SRS-F-12 Aplikasi dapat me laku kan validasi input SMS dan me masukkan dala m database perusahaan yang bersesuaian.
SRS-F-13 Aplikasi menyediakan web service berupa method-method yang akan digunakan oleh Business Process Generator.
SRS-F-14 Aplikasi dapat mena mpilkan in formasi apakah laporan sudah diproses atau belum.
SRS-F-15 Report Getter dapat me milih definisi p roses pengolahan data mana
yang akan diproses sesuai dengan perusahaannya.
SRS-F-16 Report Getter dapat menerima laporan dari hasil pe mrosesan oleh
aplikasi.
SRS-F-17 Aplikasi dapat me mbuat laporan sesuai dengan kema mpuan library yang digunakan yaitu Jasper Report.
2. Fitur Non Fungsional
Pada Tabel III.3 terdapat penjelasan fitur yang diajukan untuk memenuhi kebutuhan non fungsional perangkat lunak.
Tabel III.3. SRS Non Fungsional Perangkat Lunak
SRS Non Fungsional Ke terangan
SRS-NF-01 Aplikasi harus me laku kan autentifikasi terhadap pengguna. SRS-NF-02 Aplikasi me mberikan ta mpilan yang me mudahkan pengguna
dala m menga mbil laporan
Tabel III.4. Tr aceability SRS Per angkat Lunak de ngan Fitur Sistem
No Fitur Sistem SRS
1 Pengumpulan data mentah SRS-F-11 2 Validasi masukan data mentah SRS-F-12 3 Ke ma mpuan menghasilkan laporan sesuai
dengan aturan yang didefinisikan oleh
Report Getter
SRS-F-17, SRS-F-16
4 Pengaturan layanan yang aktif SRS-F-15, SRS-F-14, SRS-F-08, SRS-F-09 5 Pengaturan Report Getter SRS-F-01, SRS-F-02, SRS-F-03, SRS-F-04,
SRS-F-05, SRS-F-06. 6 Daftar fungsi pengolahan laporan agar
bisa dibaca oleh Businesses Process
Generator
SRS-F-10, SRS-F-13
7 Kenyamanan dan ke mudahan penggunaan SRS-NF-02 8 Kea manan Data SRS-NF-01 9 Doku mentasi penggunaan dan
pengembangan
Tidak ada – Na mun men jadi kebutuhan laporan acuan teknis
3.3.3 Format Pesan SMS
Format pesan SMS yang digunakan pada Tugas Akhir ini dibangun berdasarkan penjelasan format pesan SMS beberapa aplikasi pada subbab 2.7.3 dimana setiap pesan terdapat identifikasi dan jarak antar perintah maupun pesan dipisahkan oleh spasi. Format pesan tersebut adalah sebagai berikut:
<company><spasi><perintah><spasi><key><spasi><value>
Dimana key dan value dapat berulang.
1. <company>
Berisi string singkat yang mengidentifikasikan perusahaan yang menggunakan layanan Business Process Reporting Service. Identifikasi ini dilakukan karena setiap pengguna telepon selular dapat mengirimkan SMS ke perusahaan yang berbeda.
2. <perintah>
Berisi perintah-perintah yang digunakan untuk mengidentifikasikan data mentah melalui SMS. Perintah-perintah ini akan didefinisikan pada subsistem Business
Process Generator.
3. <key>
Berisi kunci string yang digunakan pada suatu perintah, digunakan sebagai string yang merepresentasikan suatu produk perusahaan.
4. <value>
Berisi nilai data dari kunci string yang digunakan pada suatu perintah, digunakan sebagai string yang merepresentasikan kuantitas suatu produk perusahaan.
Sebagai contoh adalah format SMS berikut:
budi simpan barang1 12
Artinya adalah pesan untuk mengindikasikan penyimpanan barang1 dengan jumlah 12 pada perusahaan budi berhasil dilakukan. Kata simpan pada contoh diatas artinya adalah penyimpanan barang.
3.3.4 Laporan yang Dihasilkan
Karena aplikasi subsistem SMS Based Service ini menggunakan library dari Jasper Report, maka untuk membangkitkan laporan cukup dengan melakukan pengubahan pada file .jrxml yang dimiliki oleh Jasper Report. File .jrxml ini akan membutuhkan masukan resource data yaitu hasil olahan data aplikasi subsistem SMS Based Service untuk membangkitkan laporan.
File .jrxml pada Tugas Akhir ini akan disediakan manual dengan dua jenis:
1. report.jrxml. File ini berguna untuk membangkitkan template laporan rekapitulasi data dengan teks.
2. chart.jrxml. File ini berguna untuk membangkitkan template laporan rekapitulasi data dengan chart.
Dua template laporan ini bersifat generik sehingga akan dapat diisi dengan data mentah dengan isi yang berbeda-beda untuk menghasilkan laporan.
Sebagai contoh, dari data mentah hasil pemrosesan data mengenai laporan penyimpanan barang, pada perusahaan Budi, dihasilkan laporan yang dapat dilihat contohnya pada Gambar III.6 dan Gambar III.7.
Gambar III.6 Contoh lapor an rekapitulasi data de ngan teks
3.3.5 Fungsi Pengolahan Data
Sesuai dengan arsitektur subsistem yang telah dijelaskan pada subbab 3.3.1, aplikasi subsistem SMS Based Service ini akan menyediakan fungsi-fungsi untuk dapat diakses oleh subsistem Business Process Generator dalam mendefinisikan proses pengolahan datanya. Fungsi-fungsi ini direncanakan agar bisa dengan mudah ditambahkan, dikurangi, maupun dimodifikasi oleh pengguna aplikasi, sehingga bentuk masukan dan keluaran fungsi ini haruslah umum. Berikut adalah contoh-contoh fungsi tersebut:
1. Fungsi untuk menjumlahkan value sebuah key dan sebuah perintah dari satu SMS yang diterima. Masukan fungsi ini adalah perintah dan key.
2. Fungsi untuk menjumlahkan value sebuah key dan sebuah perintah dari semua SMS yang diterima. Masukan fungsi ini adalah perintah dan key.
3. Fungsi untuk menjumlahkan value setiap key dari sebuah perintah dari semua SMS yang diterima. Masukan fungsi ini adalah perintah.
4. Fungsi untuk menjumlahkan setiap value setiap key dari setiap perintah dari semua SMS yang diterima.
5. Fungsi untuk menambahkan antar hasil fungsi 1-4. 6. Fungsi untuk mengurangi antar hasil fungsi 1-4.
7. Fungsi untuk mengalikan hasil fungsi 1-4 dengan konstanta tertentu. 8. Fungsi untuk membagi hasil fungsi 1-4 dengan konstanta tertentu.
Dari fungsi-fungsi diatas, untuk fungsi 1-4 juga diperlukan pada tanggal tertentu, oleh karena itu akan ditambahkan fungsi yang sama dengan fungsi 1-4 namun dengan tambahan masukan tanggal yang diinginkan.
Hasil perancangan fungsi ini akan dijelaskan pada subbab 4.1.4.
3.3.6 Pemodelan Kebutuhan Perangkat Lunak
Untuk memberikan gambaran yang lebih jelas mengenai perangkat lunak yang akan dibangun pada Tugas Akhir ini, dilakukan pemodelan perangkat lunak yang mencakup pemodelan fungsionalitas, pemodelan interaksi elemen dalam sistem, dan pemodelan kelas potensial. Pemodelan perangkat lunak dilakukan sebagai bagian dari aktivitas analisis dan perancangan perangkat lunak.. Pemodelan fungsionalitas menghasilkan diagram use case. Skenario use
case dan sequence diagram dihasilkan dari pemodelan interaksi elemen dalam sistem.
Sedangkan pemodelan kelas potensial menghasilkan identifikasi paket dan kelas analisis.
3.3.6.1 Pemodelan Fungsionalitas
Diagram use case menggambarkan fitur yang dicakup perangkat lunak yang akan dikembangkan. Realisasi fitur perangkat lunak dalam bentuk diagram use case digambarkan
pada Gambar III.8, sedangkan penjelasan mengenai aktor dan use case terkait serta keterhubungan antara use case dengan spesifikasi kebutuhan dapat dilihat pada Tabel III.5, Tabel III.6, dan Tabel III.7.
Tabel III.5. Definisi Aktor Business Process Reporting Service
No Aktor Deskripsi
1 Administrator Pengguna yang bertugas untuk mela kukan pengelolaan pengguna aplikasi.
2 Report Getter Pengguna aplikasi yang me rupakan client dari sistem, d isebut juga dengan Company.
3 Reporter Aktor in i adalah piha k dari Company, yang akan
mengirimkan data untuk diolah mela lui SMS. Dapat berupa
customer maupun pegawai dari Co mpany.
4 Business Process Generator Aktor in i me rupakan subsistem la in dari Business Process
Reporting Service yang akan menga mbil service subsistem SMS Based Servicedan menyediakan definisi proses
pengolahan laporan.
Tabel III.6. Definisi Use Case B usiness Process Reporting Service
No Use Case Deskripsi
UC-01 Membangkit kan laporan Report Getter akan me mbangkitkan laporan berdasarkan
definisi proses pengolahan data yang diterima, dengan data mentah berupa SMS.
UC-02 Melihat laporan Report Getter akan me lihat laporan pengolahan data dari
SMS baik da la m bentuk pdf maupun tamp ilan web. UC-03 Memonitor pengolahan
laporan
Report Getter dapat mela kukan mon itoring laporan pada
aplikasi Business Process Reporting Service, apakah laporan sudah diproses atau belum.
UC-04 Melihat daftar fungsi pengolahan laporan
Sistem akan menyedia kan service berupa daftar fungsi pengolahan laporan untuk digunakan oleh Business
Process Generator.
UC-05 Menyediakan definisi proses pengolahan laporan
Business Process Generator menyediakan definisi proses
pengolahan laporan untuk dija lankan oleh aplikasi. UC-06 Mengirimkan Data Mentah Reporter mengirimkan SMS berisi data untuk diolah o leh
aplikasi . UC-07 Mengelola data pengguna
aplikasi
Admin istrator dapat mela kukan pengolahan data pengguna aplikasi
Tabel III.7. Ke terhubungan SRS de ngan Use Case.
Nomor SRS Nomor Use case
SRS-F-01, SRS-F-02, SRS-F-03, SRS-F-04, SRS-F-05, SRS-F-06, SRS-F-07 UC-07 SRS-F-11, SRS-F-12 UC-06 SRS-F-10 UC-05 SRS-F-13 UC-04 SRS-F-14 UC-03 SRS-F-16, SRS-F-17 UC-02 SRS-F-08, SRS-F-09, SRS-F-15 UC-01
Pada setiap use case, dibutuhkan autentikasi pengguna yang sebenarnya berasal dari kebutuhan non fungsional sistem. Hal ini diperlukan untuk membedakan hak akses antara pengguna satu dengan yang lain sehingga keamanan data tetap terjaga.
Untuk setiap use case yang terdefinisi, didefinisikan pula skenario use case, baik untuk kasus normal maupun alternatif. Untuk skenario use case secara lengkap terdapat pada Lampiran A Subbab 2.3.4.
System
Report Getter
Business Process Generator
Administrator
Reporter
Melihat Laporan
Memonitor pengolahan laporan Mengelola data pengguna aplikasi
Mengirimkan Data Mentah
Melihat daftar fungsi pengolahan laporan Menyediakan definisi proses pengolahan laporan
Membangkitkan laporan
Gambar III.8. Di agram Use Case Subsistem S MS Base d Ser vice
3.3.6.2 Pemodelan Interaksi Elemen
Pemodelan interaksi elemen dilakukan dengan membuat sequence diagram. Sequence
diagram menggambarkan interaksi antara user dengan sistem maupun interaksi antar elemen/
objek dalam sistem.
Untuk setiap skenario use case, didefinisikan sequence diagram. Skenario alternatif akan digambarkan menjadi satu dengan skenario normal. Skenario alternatif dijelaskan pada skenario normal use case di mana skenario alternatif dapat terjadi pada kondisi tertentu. Sedangkan mengenai kasus error yang tidak berhubungan dengan aplikasi tidak akan dijelaskan pada skenario use case. Untuk skenario aliran proses telah dijelaskan sebelumnya pada subbab 3.3.1.
Sequence diagram aplikasi Business Process Reporting Service subsistem SMS Based Service
sequence diagram. Salah satu contoh penggunaan sequence diagram dari skenario use case
Membangkitkan Laporan dapat dilihat pada Gambar III.9.
Nama use case : Membangkitkan Laporan
Precondition : Pengguna telah melakukan autentikasi untuk memasuki sistem.
Post condition : Sistem membangkitkan laporan sesuai dengan definisi proses
pengolahan data yang diterima dari Business Process Generator. Skenario utama :
Aksi Aktor Reaksi Sistem
1. Me milih untuk melihat list definisi proses pengolahan data yang diterima.
2. Mena mpilkan hala man list definisi proses pengolahan data yang diterima.
3. Mengklik salah satu definisi proses yang belun dija lankan oleh aplikasi
3a.a lternatif: UC-02-A-01 3b.alternatif: UC-02-A-02
4. Mena mpilkan pesan bahwa proses pengolahan data berhasil
4a.a lternatif: UC-02-A-03
Skenario alternatif :
No. skenario alternatif : UC-02-A-01
Aksi Aktor Reaksi Sistem
1. Mengklik proses data
2. Mena mpilkan pesan bahwa data telah diproses, namun laporan belu m dapat didownload karena belum diproses.
No. skenario alternatif : UC-02-A-02
Aksi Aktor Reaksi Sistem
1. Mengklik proses laporan
2. Mena mpilkan pesan bahwa laporan telah diproses sehingga dapat didownload.
No. skenario alternatif : UC-02-A-03
Aksi Aktor Reaksi Sistem
1. Jika terdapat kesalahan dala m pe mrosesan, sistem akan mena mp ilkan pesan bahwa terjadi kesalahan.
Skenario utama sd Skenario alternatif1 sd Skenario alternatif2 sd Skenario alternatif3 sd
: Report Getter : User : Processor : Report Controller : Report : SMS Controller : SMS : Company Controller : Company : BPEL Controller : BPEL 1 : showReport() 2 : processReport() 3 : getDataReport() 4 : getData() 5 : Report() 6 : getDataSMS() 7 : getSMS() 8 : SMS() 9 : getDataCompany() 10 : getCompanyDetail() 11 : Company() 12 : getDataBP() 13 : getBP() 14 : BP() 15 : process() 16 : processData() 17 : getData() 18 : report() 19 : show() 20 : processReport() 21 : show() 22 : showReport() 23 : processReport() 24 : getDataReport() 25 : getData() 26 : report() 27 : getDataSMS() 28 : getSMS() 29 : SMS() 30 : getDataCompany() 31 : getCompanyDetail() 32 : Company() 33 : getDataBP() 34 : getBP() 35 : BP() 36 : process() 37 : show()
Gambar III.9. Seque nce Diagram untuk Use Case Me mbangkitkan Lapor an
3.3.6.3 Pemodelan Paket dan Kelas Analisis
Pada tahap analisis perangkat lunak ini, setiap bagian pada arsitektur Business Process
Reporting Service subsistem SMS Based Service dari subbab 3.3.1 yang memiliki kesamaan
penggunaan, dibedakan menjadi paket-paket tersendiri. Sebagai contoh adalah bagian penerimaan SMS, bagian penerimaan definisi proses pengolahan data, serta bagian pembangkit laporan. Bagian manajemen aplikasi ditambahkan untuk memudahkan pengelolaan pengguna aplikasi subs istem SMS Based Service.
Pada akhirnya teridentifikasi 5 Paket yang dapat dilihat penjelasannya pada Tabel III.8. Hubungan antara penjelasan detail dari arsitektur subsistem pada Gambar III.5 dengan
paket-paket yang akan dibuat, dapat dilihat pada Tabel III.9. Berdasarkan objek yang teridentifikasi dalam pendefinisian sequence diagram, diperoleh kelas-kelas yang terdapat pada Tabel III.10. Secara garis besar keterhubungan antar paket yang memuat kelas tersebut digambarkan pada Gambar III.10. Untuk diagram kelas analisis dapat dilihat pada Gambar III.11. Keterhubungan antar kelas dalam paket secara terperinci digambarkan pada Lampiran A Gambar 3-11, Gambar 3-12, Gambar 3-13, Gambar 3-14, dan Gambar 3-15.
Tabel III.8. Identifikasi Paket Analisis Aplikasi Business Process Re por ting Ser vice subsistem SMS Base d Ser vice
No Nama Paket Use case Terkait Ke terangan
1. SMS Receiver UC-07 Merupakan bagian sistem yang menerima SM S. 2. BPEL Receiver UC-05, UC-06 Merupakan bagian sistem
yang menerima BPEL. 3. Processor UC-02, UC-04 Merupakan pemroses
laporan dan berhubungan dengan service.
4. Manajemen Aplikasi UC-01, UC-08 Merupakan bagian sistem yang menangani pengguna. 5. Report Display UC-03 Merupakan bagian sistem
yang mena mpilkan laporan.
Tabel III.9. Hubung an Antara Paket Analisis dengan Bagian-bagian Business Process Reporting Service
No Nama B agian Nama Paket Ke terangan
1. Report Getter - Merupakan Company pengguna aplikasi, d idefin isikan sebagai aktor. 2. Reporter - Merupakan pihak yang akan
mengirimkan data untuk dilaporkan, didefinisikan sebagai aktor.
3. Report Generator Processor, Report Display Merupakan pengolah laporan untuk ditamp ilkan.
4. Business Process
Generator
- Merupakan bagian sistem yang menghasilkan defin isi proses pengolahan data dalam bentuk BPEL-lik e, didefinisikan sebagai aktor.
5. Function Provider Processor Merupakan bagian sistem yang akan me mbe rikan service untuk
digunakan oleh Business Process
Generator.
6. SMS Gateway SMS Receiver Merupakan bagian sistem yang menerima data laporan me lalu i med ia SM S.
7. Database SMS Receiver, BPEL
Receiver, Report Display,
Manajemen Aplikasi Pengguna
Bagian sistem yang menggunakan database sebagai tempat
Manajemen Aplikasi
SMS Receiver BPEL Receiver
Processor
Report Display
Gambar III.10. Diagr am Paket Aplikasi Business Process Reporti ng Service subsistem S MS Based Ser vice
Company SMS
BPEL SMS Controller
BPEL Controller Report Controller
Company Controller
Report
Processor
SMS Receiver BPEL Receiver Reporter
Service Interface
User Controller
User
Gambar III.11. Diagr am Kel as Analisis
Tabel III.10. Kel as Analisis Aplikasi Business Process Reporting Ser vice subsistem S MS Base d Service
No. Nama Kelas Jenis
Paket SMS Receiver
1 SMS Interface Boundary
2 SMS Controller Controller
3 SMS Entity
Paket BPEL Receiver
4 BPELInterface Boundary
5 BPELController Controller
6 BPEL Entity
Paket Processor
Tabel III.11. Kel as Analisis Aplikasi Business Process Reporting Ser vice subsistem S MS Base d Service (l anjutan)
No. Nama Kelas Jenis
8 Service Interface Boundary
Paket Report Display
9 Report Controller Controller
10 Reporter Boundary
11 Report Entity
Paket Manajemen Aplikasi
12 User Interface Boundary
13 Company Controller Controller
14 User Controller Controller
15 Company Entity
