BAB III ANALISIS. 3.1 Analisis Model Business Process Outsourcing

Transkripsi

1 BAB III ANALISIS 3.1 Analisis Model Outsourcing Dari beberapa penjelasan mengenai model 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. Company #1 Core Core Core Non Core Outsourcing Company Non Core Non Core Non Core BPO Company #2 Core Core Core Non Core Company #n Core Core Core Non Core Gambar III.1 Outsourcing secara umum 1

2 III-2 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 Reporting Service Berdasarkan teori pada subbab 2.2, 2.3, dan 2.4, Reporting Service diajukan sebagai contoh aplikasi yang mendukung Outsourcing (BPO) dalam bidang pelaporan data. Mengacu pada Gambar II.2, pelaporan data termasuk dalam jenis data processing yang bukan merupakan non-core business process perusahaan, sehingga dapat dilakukan outsourcing untuk hal ini. Definisi 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 Reporting Service, yaitu: penyedia layanan BPO dan pengguna layanan. Berikut adalah pembagian peran antara penyedia layanan dan pengguna layanan pada 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.

3 III-3 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 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 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, 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.

4 III-4 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. 1 Business Process Daftar Fungsi Pengolahan Laporan Subsistem 1 Daftar Fungsi Pengolahan Laporan Data (FTP) Mentah Definisi Proses Pengolahan Laporan Data (SMS) Mentah Subsistem 2 Subsistem 3 Laporan Laporan 2 3 Gambar III.2 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.

5 III Arsitektur Sistem Sesuai dengan gambaran umum mengenai pembagian subsistem 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 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 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 Reporting Service.

6 III-6 Reporting Service g e d Reporter SMS Gateway Function Provider Generator Reporter Report Getter a Reporter FTP Server f Database h Report Generator c Reporter b Gambar III.3 Arsitektur Sistem Reporting Service Gambar III.3 mewakili gambaran umum dari 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 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

7 III-7 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 Generator. d. Generator (BPG) 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 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 Reporting Service subsistem SMS Based Service yang akan dijelaskan pada subbab

8 III Analisis BPEL-like XML Sistem besar 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 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 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 Generator dan memudahkan pertukaran data. Tag BPEL-like dibangun dengan mengadopsi konsep BPEL yang telah dijelaskan pada subbab 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.

9 III-9 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 "?> <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) Analisis Fitur Sistem Perbandingan dengan Aplikasi Sejenis Aplikasi perangkat lunak yang mempunyai fitur penanganan pembuatan laporan tidak hanya dimiliki oleh 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.

10 III-10 Gambar III.4 Skema BIRT pada pembuatan laporan 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) Fitur Sistem Sesuai dengan penjelasan pada subbab , Reporting Service diajukan sebagai aplikasi pembuatan laporan berdasar konsep BPO di antaranya yaitu: 1. Fitur Fungsional Berikut adalah fitur fungsional yang dimiliki oleh sistem Reporting Service:

11 III-11 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 Generator. Membuat daftar fungsi pengolahan laoran tersedia yang bisa dibaca oleh subsistem 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.

12 III-12 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 Arsitektur Sistem Subsistem SMS Based Service Arsitektur subsistem SMS Based Service dapat digambarkan seperti dalam Gambar III.5. Reporting Service subsistem SMS Based Service Reporter 4 SMS Gateway 3 Function Provider 1 Generator Reporter Database Report Generator Report Getter Gambar III.5 Arsitektur Reporting Service subsistem S MS Based Service Gambar III.5 adalah gambar arsitektur 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.

13 III-13 Aliran proses subsistem SMS Based Service pada Reporting Service dalam membangkitkan laporan dapat dijelaskan pada setiap garis panah bernomor pada Gambar III.5 yang akan dijelaskan sebagai berikut: 1. Generator (BPG) mengambil daftar fungsi-fungsi pengolahan data yang tersedia dari Function Provider melalui web service. BPG menampilkan fungsifungsi 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 Fitur Subsistem SMS Based Service Berdasarkan fitur sistem yang telah dijelaskan pada subbab , 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 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 Keterangan SRS-F-01 Administrator aplikasi dapat melihat list dari pengguna aplikasi. SRS-F-02 Administrator aplikasi dapat melakukan penambahan pengguna. SRS-F-03 Administrator aplikasi dapat melakukan pengubahan data pengguna. SRS-F-04 Administrator aplikasi dapat menghapus pengguna. SRS-F-05 Administrator aplikasi dapat melakukan penambahan perusahaan.

14 III-14 Tabel III.2. SRS Fungsional Perangkat Lunak (lanjutan) SRS Fungsional SRS-F-06 SRS-F-07 SRS-F-08 SRS-F-09 SRS-F-10 SRS-F-11 SRS-F-12 SRS-F-13 SRS-F-14 SRS-F-15 SRS-F-16 SRS-F-17 Keterangan Administrator aplikasi dapat melakukan pengubahan informasi perusahaan. Administrator aplikasi dapat menghapus perusahaan. ReportGetter dapat melihat list BPEL yang masuk ke dalam aplikasi sesuai dengan perusahaannya. Report Getter dapat melihat list SMS yang masuk ke dalam aplikasi sesuai dengan perusahaannya. Aplikasi dapat menerima definisi proses pengolahan data yang dikirimkan oleh Generator. Aplikasi dapat menerima SMS dari Reporter. Aplikasi dapat melakukan validasi input SMS dan memasukkan dalam database perusahaan yang bersesuaian. Aplikasi menyediakan web service berupa method-method yang akan digunakan oleh Generator. Aplikasi dapat menampilkan informasi apakah laporan sudah diproses atau belum. Report Getter dapat memilih definisi proses pengolahan data mana yang akan diproses sesuai dengan perusahaannya. Report Getter dapat menerima laporan dari hasil pemrosesan oleh aplikasi. Aplikasi dapat membuat laporan sesuai dengan kemampuan 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 SRS-NF-01 SRS-NF-02 Keterangan Aplikasi harus melakukan autentifikasi terhadap pengguna. Aplikasi memberikan tampilan yang memudahkan pengguna dalam mengambil laporan Tabel III.4. Traceability SRS Perangkat Lunak dengan Fitur Sistem No Fitur Sistem SRS 1 Pengumpulan data mentah SRS-F-11 2 Validasi masukan data mentah SRS-F-12 3 Kemampuan menghasilkan laporan sesuai SRS-F-17, SRS-F-16 dengan aturan yang didefinisikan oleh Report Getter 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 Daftar fungsi pengolahan laporan agar SRS-F-10, SRS-F-13 bisa dibaca oleh Businesses Process Generator 7 Kenyamanan dan kemudahan penggunaan SRS-NF-02 8 Keamanan Data SRS-NF-01 9 Dokumentasi penggunaan dan pengembangan Tidak ada Namun menjadi kebutuhan laporan acuan teknis

15 III Format Pesan SMS Format pesan SMS yang digunakan pada Tugas Akhir ini dibangun berdasarkan penjelasan format pesan SMS beberapa aplikasi pada subbab 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 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 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.

16 III-16 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 laporan rekapitulasi data dengan teks Gambar III.7 Contoh laporan rekapitulasi data dengan chart

17 III 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 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 Fungsi untuk mengurangi antar hasil fungsi 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 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 Pemodelan Fungsionalitas Diagram use case menggambarkan fitur yang dicakup perangkat lunak yang akan dikembangkan. Realisasi fitur perangkat lunak dalam bentuk diagram use case digambarkan

18 III-18 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 Reporting Service No Aktor Deskripsi 1 Administrator Pengguna yang bertugas untuk melakukan pengelolaan pengguna aplikasi. 2 Report Getter Pengguna aplikasi yang merupakan client dari sistem, disebut juga dengan Company. 3 Reporter Aktor ini adalah pihak dari Company, yang akan mengirimkan data untuk diolah melalui SMS. Dapat berupa customer maupun pegawai dari Company. 4 Generator Aktor ini merupakan subsistem lain dari Reporting Service yang akan mengambil service subsistem SMS Based Servicedan menyediakan definisi proses pengolahan laporan. Tabel III.6. Definisi Use Case Reporting Service No Use Case Deskripsi UC-01 Membangkitkan laporan Report Getter akan membangkitkan laporan berdasarkan definisi proses pengolahan data yang diterima, dengan data mentah berupa SMS. UC-02 Melihat laporan Report Getter akan melihat laporan pengolahan data dari SMS baik dalam bentuk pdf maupun tampilan web. UC-03 UC-04 Memonitor pengolahan laporan Melihat daftar fungsi pengolahan laporan Report Getter dapat melakukan monitoring laporan pada aplikasi Reporting Service, apakah laporan sudah diproses atau belum. Sistem akan menyediakan service berupa daftar fungsi pengolahan laporan untuk digunakan oleh Business Process Generator. UC-05 Menyediakan definisi proses pengolahan laporan Generator menyediakan definisi proses pengolahan laporan untuk dijalankan oleh aplikasi. UC-06 Mengirimkan Data Mentah Reporter mengirimkan SMS berisi data untuk diolah oleh aplikasi. UC-07 Mengelola data pengguna aplikasi Administrator dapat melakukan pengolahan data pengguna aplikasi Tabel III.7. Keterhubungan SRS dengan Use Case. Nomor SRS SRS-F-01, SRS-F-02, SRS-F-03, SRS-F-04, SRS-F-05, SRS-F-06, SRS-F-07 SRS-F-11, SRS-F-12 SRS-F-10 SRS-F-13 SRS-F-14 SRS-F-16, SRS-F-17 SRS-F-08, SRS-F-09, SRS-F-15 UC-07 UC-06 UC-05 UC-04 UC-03 UC-02 UC-01 Nomor Use case 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.

19 III-19 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 System Mengelola data pengguna aplikasi Melihat Laporan Administrator Membangkitkan laporan Memonitor pengolahan laporan Report Getter Reporter Mengirimkan Data Mentah Menyediakan definisi proses pengolahan laporan Generator Melihat daftar fungsi pengolahan laporan Gambar III.8. Diagram Use Case Subsistem S MS Based Service 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 Sequence diagram aplikasi Reporting Service subsistem SMS Based Service digambarkan secara lengkap pada Lampiran A Subbab 3.1. Secara keseluruhan, terdapat 12

20 III-20 sequence diagram. Salah satu contoh penggunaan sequence diagram dari skenario use case Membangkitkan Laporan dapat dilihat pada Gambar III.9. Nama use case Precondition Post condition Skenario utama : : Membangkitkan Laporan Aksi Aktor 1. Memilih untuk melihat list definisi proses pengolahan data yang diterima. 3. Mengklik salah satu definisi proses yang belun dijalankan oleh aplikasi 3a.alternatif: UC-02-A-01 3b.alternatif: UC-02-A-02 : Pengguna telah melakukan autentikasi untuk memasuki sistem. : Sistem membangkitkan laporan sesuai dengan definisi proses pengolahan data yang diterima dari Generator. Reaksi Sistem 2. Menampilkan halaman list definisi proses pengolahan data yang diterima. 4. Menampilkan pesan bahwa proses pengolahan data berhasil 4a.alternatif: UC-02-A-03 Skenario alternatif : No. skenario alternatif : UC-02-A-01 Aksi Aktor 1. Mengklik proses data Reaksi Sistem 2. Menampilkan pesan bahwa data telah diproses, namun laporan belum dapat didownload karena belum diproses. No. skenario alternatif : UC-02-A-02 Aksi Aktor 1. Mengklik proses laporan Reaksi Sistem 2. Menampilkan pesan bahwa laporan telah diproses sehingga dapat didownload. No. skenario alternatif : UC-02-A-03 Aksi Aktor Reaksi Sistem 1. Jika terdapat kesalahan dalam pemrosesan, sistem akan menampilkan pesan bahwa terjadi kesalahan.

21 III-21 : Report Getter : Report Controller : Report : User : SMS Controller : SMS : Company Controller : Company : BPEL Controller : BPEL : Processor sd Skenario utama 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() sd Skenario alternatif1 16 : processdata() 17 : getdata() 19 : show() 18 : report() sd Skenario alternatif2 20 : processreport() 21 : show() sd Skenario alternatif3 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. Sequence Diagram untuk Use Case Membangkitkan Laporan Pemodelan Paket dan Kelas Analisis Pada tahap analisis perangkat lunak ini, setiap bagian pada arsitektur Reporting Service subsistem SMS Based Service dari subbab 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 subsistem 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-

22 III-22 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 Tabel III.8. Identifikasi Paket Analisis Aplikasi Reporting Service subsistem SMS Based Service No Nama Paket Use case Terkait Keterangan 1. SMS Receiver UC-07 Merupakan bagian sistem yang menerima SMS. 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 menampilkan laporan. Tabel III.9. Hubungan Antara Paket Analisis dengan Bagian-bagian Reporting Service No Nama Bagian Nama Paket Keterangan 1. Report Getter - Merupakan Company pengguna aplikasi, didefinisikan 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 ditampilkan. 4. Generator - Merupakan bagian sistem yang menghasilkan definisi proses pengolahan data dalam bentuk BPEL-like, didefinisikan sebagai aktor. 5. Function Provider Processor Merupakan bagian sistem yang akan memberikan service untuk digunakan oleh Generator. 6. SMS Gateway SMS Receiver Merupakan bagian sistem yang menerima data laporan melalui media SMS. 7. Database SMS Receiver, BPEL Receiver, Report Display, Manajemen Aplikasi Pengguna Bagian sistem yang menggunakan database sebagai tempat penyimpanan data.

23 III-23 SMS Receiver BPEL Receiver Processor Manajemen Aplikasi Report Display Gambar III.10. Diagram Paket Aplikasi Reporting Service subsistem S MS Based Service SMS Receiver BPEL Receiver Reporter BPEL Controller BPEL Report Controller Report SMS SMS Controller Processor Company Controller Company Service Interface User User Controller Gambar III.11. Diagram Kelas Analisis Tabel III.10. Kelas Analisis Aplikasi Reporting Service subsistem S MS Based 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 7 Processor Controller

24 III-24 Tabel III.11. Kelas Analisis Aplikasi Reporting Service subsistem S MS Based Service (lanjutan) 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 16 User Entity