V-1

BAB V IMPLEMENTASI DAN PENGUJIAN

5.1 Implementasi Perangkat Lunak

Bab Implementasi Perangkat Lunak ini berisi uraian mengenai lingkungan implementasi,

batasan implementasi, tahapan implementasi, dan hasil implementasi kelas untuk studi kasus

yang telah dijelaskan pada BAB IV.

5.1.1 Lingkungan Implementasi

Studi kasus Virtual Research Center dikembangkan dalam lingkungan perangkat keras yang

memiliki spesifikasi perangkat kerassebagai berikut:

1. Prosesor Intel® Pentium® M 1,60 GHz

2. Memori 2.0 GB RAM DDR PC2700

3. Harddisk 60 GB

Sementara spesifikasi perangkat lunak lingkungan pengembangan adalah sebagai berikut:

1. Sistem Operasi Microsoft Windows XP Professional SP2

2. Java SDK Standard Edition versi 1.5.0 update 6 (untuk menjalankan Intalio BPMS)

3. Java SDK Standard Edition versi 1.6.0

4. Netbeans IDE 6.0 dengan Java SDK Enterprise Edition versi 6, framework JAX-WS

versi 2.1 dan web server Glassfish V2

5. Intalio BPMS Community Edition 5.0 RC1, yang terdiri atas Intalio BPMS Designer

dan Intalio BPMS Server.

6. XAMPP for Windows dengan Apache PHP Web Server versi 4.4.4 dan MySQL

Server versi 5.0.27

7. Library NuSOAP versi 0.7.2

5.1.2 Batasan Implementasi

Batasan dari implementasi studi kasis VRC adalah sebagai berikut:

1. Konfigurasi basis data harus dilakukan secara manual dengan memanfaatkan file

dump SQL.

2. Aspek sekuritas tidak menjadi pertimbangan dalam implementasi sehingga data yang

dipertukarkan dan disimpan tidak dienkripsi dan penggunaan web service tanpa

melakukan autentikasi.

V-2

5.1.3 Tahapan Implementasi

Mengacu pada Tabel III-2, aktivitas implementasi dilakukan dalam beberapa tahap sebagai

berikut:

1. Implementasi service

Implementasi service menghasilkan kelima web service yang dibangun dengan

teknologi Java dan PHP

2. Implementasi proses bisnis

Implementasi proses bisnis menghasilkan definisi proses bisnis dalam BPMN dan

menyimpan hasil konversinya dalam server BPMS agar siap dijalankan.

3. Implementasi perangkat lunak client

Implementasi perangkat lunak client menghasilkan sebuah aplikasi web yang

berfungsi untuk menjadi antarmuka ke pengguna untuk menjalankan service dan

proses bisnis yang ada.

Ketiga tahapan ini dilakukan secara iteratif, sehingga setiap tahap dapat tetap diperbaiki

hingga akhir pengerjaan.

5.1.4 Kendala Implementasi

Dari hasil implementasi studi kasus yang dilakukan pada tugas akhir ini, didapatkan beberapa

kendala sebagai berikut:

1. Intalio BPMS, kakas yang digunakan untuk menjadi komponen BPMS baru bisa

mendukung teknologi web service JAX-WS setelah mencapai versi 5.0, yang

dikeluarkan pada akhir Agustus 2007.

2. Eksekusi proses bisnis pada Intalio BPMS tidak mendukung adanya input di tengah

proses bisnis berjalan, yang mana dibutuhkan untuk proses pengajuan proposal. Oleh

karena itu, proses bisnis pengajuan proposal akhirnya dipecah menjadi sepuluh

proses, seperti dijelaskan pada Bab 4.1.2.

3. Mekanisme upload file pada awalnya direncanakan menggunakan teknologi WS-

Attachment, namun dikarenakan sulitnya implementasi dan sedikit sumber untuk

mempelajarinya maka diganti menjadi mekanisme copy file antar server yang

dilakukan oleh WSFileManagement.

5.1.5 Hasil Implementasi

Hasil implementasi pada studi kasus ini dapat dibagi menjadi dua bagian, sesuai dengan

analisis dan perancangan yang telah dilakukan, yaitu adalah implementasi pada perangkat

lunak client dan implementasi pada service. Keduanya akan dijelaskan pada bagian berikut.

V-3

5.1.5.1 Hasil Implementasi Service

Hasil implementasi service dapat dibagi menjadi dua bagian, yaitu implementasi proses dan

implementasi web service.

Hasil implementasi proses sebuah file yang menggambarkan proses BPMN. Untuk

menjalankan file tersebut, maka akan dibuat file eksekusinya dalam kode BPEL. Nama

Proses, file BPMN, dan file executable dari seluruh proses yang diimplementasi dapat dilihat

pada Tabel V-1.

Tabel V-1 Hasil Implementasi Proses

No. Nama Proses Nama File BPMN Nama File Executable

1. SubmitProposal SubmitProposal.bpm SubmitProposal- Process.bpel

2. DekanApproval DekanApproval.bpm DekanApproval-Process.bpel

3. KetuaKKApproval KetuaKKApproval.bpm KetuaKKApproval-Process.bpel

4. PPApproval PPApproval.bpm PPApproval-Process.bpel

5. ChooseReviewer ChooseReviewer.bpm ChooseReviewer-Process.bpel

6. ReviewerApproval ReviewerApproval.bpm ReviewerApproval-Process.bpel

7. SubmitReview SubmitReview.bpm SubmitReview-Process.bpel

8. PPOfferBudget PPOfferBudget.bpm PPOfferBudget-Process.bpel

9. PenelitiApproval PenelitiApproval.bpm PenelitiApproval-Process.bpel

10. OpenResearch OpenResearch.bpm OpenResearch-Process.bpel

Selain itu juga dihasilkan beberapa file lain yang berfungsi untuk mendukung jalannya

proses-proses di atas. Tabel V-2 File Pendukung Proses Bisnis

No. Nama File Deskripsi

1. ProcessScema.xsd Menyimpan skema XML yang dibutuhkan untuk masukan dan keluaran proses

2. WSProposalService_schema1.xsd Menyimpan skema XML untuk web service WSProposal

3. WSProposalService.wsdl Menyimpan kode WSDL web service WSProposal

4. WSResearchService_schema1.xsd Menyimpan skema XML untuk web service WSResearch

5. WSResearchService.wsdl Menyimpan kode WSDL web service WSResearch

6. WSRFPService_schema1.xsd Menyimpan skema XML untuk web service WSRFP

7. WSRFPService.wsdl Menyimpan kode WSDL web service WSRFP

Sementara itu, pembangunan web service dilakukan dengan pembuatan kode program dalam

Java dan PHP. Detil nama kelas, nama file fisik, dan file eksekusi ntuk web service yang

diimplementasi dalam Java dapat dilihat pada Tabel V-3.

V-4

Tabel V-3 Hasil Implementasi Kelas Untuk Service dalam Java

No. Nama Kelas Nama File Fisik Nama File Executable

Paket database

Folder: <loc>/src/database

1. DBConnector DBConnector.java DBConnector.class

Paket entitybeans

Folder: <loc>/src/entitybeans

2. Proposal ListApproval.java ListApproval.class

3. RFP ViewApproval.java ViewApproval.class

4. Research Research.java Research.class

5. Review Review.java Review.class

6. User User.java User.class

7. Negotiation Negotiation.java Negotiation.class

Paket webservices

Folder: <loc>/src/webservices

8. WSProposal WSProposal.java WSProposal.class

9. WSRFP WSRFP.java WSRFP.class

10. WSResearch WSResearch.java WSResearch.class

11. WSUser WSUser.java WSUser.class

Sementara implementasi web service dalam PHP dapat dilihat pada Tabel V-4.

Tabel V-4 Hasil Implementasi Kelas untuk Web Service dalam PHP

No. Nama Kelas Nama File Fisik Nama File Executable

1. WSFileManagement wsfilemgmt.php wsfilemgmt.php

2. Downloader downloader.php downloader.php

3. Script script.inc.php script.inc.php

5.1.5.2 Hasil Implementasi Perangkat Lunak Client

Kelas perancangan diimplementasikan dalam kode Java dengan menggunakan teknologi

Servlet. Hasil implementasi tersebut dapat dilihat pada .

Tabel V-5 Hasil Implementasi Kelas Perangkat Lunak Client

No. Nama Kelas Nama File Fisik Nama File Executable

Paket servlets

Folder: <loc>/src/servlets

1. Authentication Authentication.java Authentication.class

V-5

No. Nama Kelas Nama File Fisik Nama File Executable

2. Dashboard Dashboard.java Dashboard.class

3. Logout Logout.java Logout.class

4. Approval Approval.java Approval.class

5. Negotiation Negotiation.java Negotiation.class

6. Proposal Proposal.java Proposal.class

7. RFP RFP.java RFP.class

8. Research Research.java Research.class

9. Review Review.java Review.class

Adapun contoh tampilan antarmuka dari perangkat lunak dapat dilihat pada Gambar V-1.

Gambar V-1 Screenshot antarmuka perangkat lunak client

5.2 Pengujian Perangkat Lunak

5.2.1 Pengujian Fungsionalitas Perangkat Lunak

Seperti telah dideskripsikan pada BAB IV, perangkat lunak studi kasus ini memiliki delapan

spesifikasi kebutuhan yang dapat dilihat pada Tabel IV-1. Seluruh kebutuhan perangkat lunak

tersebut telah berhasil diimplementasi dengan baik sesuai dengan hasil analisis dan

perancangan yang telah dilakukan.

V-6

5.2.2 Pengujian Pengubahan Proses Bisnis

Pada tugas akhir ini, dilakukan pengujian perubahan proses bisnis untuk membuktikan bahwa

arsitektur SOA yang menerapkan BPM, seperti dituangkan menjadi model dalam Bab 3.1,

memiliki keunggulan dalam proses perubahan tersebut.

Dalam kasus pengajuan proposal, yang menjadi studi kasus dalam tugas akhir ini, akan

dilakukan tiga jenis pengubahan sehingga proses dapat menjadi lebih cepat dan efektif.

Adapun perubahan-perubahan yang dilakukan terdiri atas:

1. Menghilangkan hirarki penungguan persetujuan Ketua Kelompok Keahlian dan Dekan,

sehingga proposal akan langsung masuk terlebih dahulu ke Pusat Penelitian, lalu baru

diminta persetujuan secara parallel terhadap keduanya

2. Menghilangkan mekanisme pemilihan reviewer oleh Pusat Penelitian. Pusat Penelitian

dianggap telah memilih sejumlah reviewer yang bertugas memberi review terhadap

proposal yang berkaitan dengan bidang ilmunya. Pemilihan reviewer akan dilakukan

secara otomatis oleh sistem

3. Menambahkan task pembuatan dokumen kontrak penelitian dalam format PDF saat

pembukaan penelitian.

Pada umumnya, perubahan proses bisnis dilakukan dengan melakukan analisis terhadap

kenyataan yang terjadi di lapangan saat proses tersebut dijalankan. Namun ketiga pengubahan

ini dilakukan tanpa berlandaskan itu. Pengubahan tersebut dilakukan hanya untuk

menunjukkan proses pengubahan proses bisnis.

5.2.2.1 Pengubahan Proses Bisnis Tanpa SOA dan BPMS

Sebelum melangkah ke pengujian perubahan, terlebih dahulu dilakukan analisis terhadap

pengubahan proses bisnis pada arsitektur yang tidak berbasis SOA dan BPMS, agar dapat

dilihat perbandingannya dalam pengubahan proses bisnis pada yang menggunakan model

tersebut dan tidak.

Perangkat lunak yang tidak menerapkan SOA maupun BPMS umumnya berupa perangkat

lunak yang terdiri atas sekumpulan komponen atau modul. Proses bisnis biasanya tertulis

dalam bentuk kode program pada modul-mdul perangkat lunak tersebut.

Untuk melakukan pembandingan antara pengubahan proses bisnis tanpa menggunakan SOA

dan BPMS, akan diambil langkah-langkah yang telah dilakukan penulis dalam

mengembangkan aplikasi Virtual Research Center ini sebelumnya, yakni versi yang telah

digunakan saat ini. Proses pengajuan proposal ini terdapat di dalam aplikasi tersebut, namun

dituliskan dalam bentuk kode program.

V-7

Pengubahan proses bisnis pada aplikasi VRC lama itu dilakukan dengan langkah-langkah

sebagai berikut:

1. Pengubahan kode program dari modul atau komponen yang berkaitan dengan proses

bisnis yang ingin diubah

2. Melakukan deployment terhadap modul atau komponen yang telah berubah

3. Melakukan pengujian terhadap modul atau komponen dengan membuat driver atau

dengan kakas pengujian lainnya

4. Melakukan penyesuaian dan pengujian terhadap modul atau komponen lain yang

mengakses modul tersebut. Contoh paling sederhana adalah tampilan aplikasi.

5.2.2.2 Pengubahan Proses pada Model Penerapan BPMS pada SOA

Seperti telah dijelaskan sebelumnya, pada pengujian ini akan terdapat tiga buah pengujian

pengubahan proses bisnis. Dalam melakukan proses pengubahan tersebut dilakukan beberapa

langkah, yakni sebagai berikut:

1. Pengubahan rancangan proses bisnis dalam BPMS. Jika terdapat web service baru

yang terlibat maka harus ditambahkan ke dalam project proses bisnis tersebut.

2. Melakukan deployment proses bisnis yang baru ke dalam server BPMS

3. Melakukan pengujian proses bisnis dengan memanfaatkan kakas pengujian proses

bisnis yang dimiliki BPMS, jika ada.

4. Melakukan penyesuaian dan pengujian terhadap aplikasi client yang mengakses

proses bisnis tersebut.

Pengujian langkah-langkah ini akan dilakukan terhadap ketiga perubahan tersebut dijelaskan

pada Bab 5.2.2.2.1 sampai 5.2.2.2.3.

5.2.2.2.1 Penghilangan Hirarki Persetujuan Ketua Kelompok Keahlian dan Dekan

Dalam proses bisnis yang ada sebelumnya, sebelum proposal dapat sampai ke Pusat

Penelitian, dibutuhkan persetujuan dari Ketua Kelompok Keahlian dan Dekan terlebih dahulu,

tergantung alur dari RFP yang ditetapkan. Proses ini melahirkan tiga buah implementasi

proses bisnis, yakni KetuaKKApproval dan DekanApproval. Keduanya dapat dilihat pada

Gambar V-3 dan Gambar V-4.

V-8

Gambar V-2 Proses Bisnis SubmitProposal

Pada Gambar V-2 dapat dilihat bahwa terdapat empat pencabangan untuk pengiriman

proposal, yang menunjukkan alur proposal. Proposal dapat dikirim diubah statusnya menjadi

menunggu persetujuan Ketua KK, Dekan, dan Pusat Penelitian. Tergantung alur dari RFP

yang telah didefinisikan. Misalkan jika proposal diajukan dengan alur KK-Dekan-PP, maka

status proposal akan diubah menjadi “kk pending”, yang berarti menunggu persetujuan dari

Ketua KK. Status yang lain adalah “dekan pending” dan “pp pending”, yang masing-

masingnya berarti menunggu persetujuan dari Dekan dan Pusat Penelitian.

Gambar V-3 Proses Bisnis KetuaKKApproval

Pada Gambar V-3 dapat dilihat bahwa persetujuan dekan dapat terjadi setelah Ketua KK

setuju. Jika alur yang dipilih tidak melalui persetujuan dekan, proposal dapat masuk ke Pusat

Penelitian setelah Ketua KK setuju.

V-9

Gambar V-4 Proses Bisnis DekanApproval

Pada Gambar V-4, proses bisnis DekanApproval, juga terlihat bahwa proposal dapat masuk

ke Pusat Penelitian jika telah disetujui oleh Dekan. Proses persetujuan proposal yang tidak

melalui dekan tidak akan memanggil proses ini.

Pengubahan yang dilakukan adalah dengan menghilangkan hirarki dalam persetujuan dekan

dan Ketua KK, yakni dengan memasukkan proposal terlebih dahulu ke Pusat Penelitian, baru

diminta persetujuan secara paralel kepada Ketua KK dan Dekan terkait, sehingga harapannya

proses pengajuan proposal dapat berlangsung lebih cepat.

Proses ini menghilangkan hirarki keterurutan Ketua KK dan Dekan, sehingga Pusat Penelitian

dapat melihat proposal sebelum disetujui oleh Ketua KK dan Dekan, dan Dekan dapat melihat

proposal sebelum disetujui oleh Ketua KK. Akibatnya proses bisnis SubmitProposal dapat

berubah menjadi seperti Gambar V-5.

Gambar V-5 Proses Bisnis SubmitProposal Baru

V-10

Dekan dan Ketua KK dapat dianggap sebagai reviewer, sehingga pengubahan proses bisnis

ini dapat memanfaatkan proses bisnis dan fungsi web service yang telah ada.

Untuk penambahan reviewer, sistem ini memiliki proses bisnis ChooseReviewer. Proses

bisnis ini dapat dimanfaatkan untuk menambahkan KetuaKK dan Dekan menjadi reviewer,

lalu proses persetujuan Ketua KK dan Dekan dilakukan dengan mengubah kedua proses awal

menjadi perubahan status menjadi setuju atau tidak setuju, tetapi dengan memanfaatkan

fungsi dari review.

Proses bisnis baru untuk persetujuan Ketua KK dan Dekan dapat dilihat padaGambar V-6.

Proses bisnis ini dinamakan DekanKetuaKKApproval. Proses ini menerima masukan id Ketua

KK atau Dekan yang dibutuhkan persetujuannya, dan sikap dari mereka, apakah setuju atau

tidak setuju. Lalu selanjutnya menyimpan informasi tersebut.

Gambar V-6 Proses Bisnis DekanKetuaKKApproval

Setelah proses bisnis ini didefinisikan, tahapan selanjutnya adalah melakukan deploy terhadap

proses ini dan mengujinya. Setelah memastikan proses ini berjalan, dilakukan pencocokan

terhadap aplikasi client.

Dekan dan Ketua KK harus melakukan persetujuan dengan mengakses aplikasi VRC.

Informasi tersebut ditampilkan oleh kelas Approval, dengan melakukan pemanggilan ke web

service WSProposal dan memanfaatkan operasi getProposalList. Pada proses bisnis baru,

pemanggilan tersebut diganti dengan pememanggilan operasi getReviewList yang terdapat di

WSProposal untuk mengambil Proposal apa saja yang harus mereka setujui atau tidak.

Untuk proses persetujuan, jika sebelumnya dilakukan pemanggilan terhadap DekanApproval

dan KetuaKKApproval, sesuai dengan posisi user, maka pada proses baru cukup dilakukan

pemanggilan ke proses DekanKetuaKKApproval.

V-11

5.2.2.3 Penghilangan Mekanisme Pemilihan Reviewer

Pada proses sebelumnya, seorang reviewer bertanggung jawab memberikan review jika

dipilih oleh Pusat Penelitian. Pada proses baru, diasumsikan Pusat Penelitian telah memiliki

reviewer untuk bidang ilmu masing-masing. Jadi pemilihan reviewer akan dilakukan secara

otomatis oleh sistem. Reviewer perlu melakukan persetujuan atau tidak, sebab ia memang

bertanggungjawab untuk itu.

Pada proses sebelumnya, proses pemilihan dilakukan dengan memanggil proses

ChooseReviewer. Proses tersebut menerima masukan berupa username dari reviewer yang

dipilih oleh Pusat Penelitian. Proses tersebut akan menyimpan reviewer dan

tanggungjawabnya terhadap proposal apa, dan informasi bahwa ia belum menyetujui perintah

itu. Gambar dari proses ini dapat dilihat pada Gambar V-7.

Gambar V-7 Proses Bisnis ChooseReviewer

Pada proses sebelumnya, status belum menyetujui, sudah menyetujui, dan memberi review

harus dilakukan dengan membuat status pada pemanggilan addReviewer. Pada saat

pemilihan reviewer, status dibuat menjadi “pending”, dikarenakan reviewer belum

menentukan apakah dia setuju untuk memberi review atau tidak. Ilustrasi ini dapat dilihat

pada Gambar V-8.

V-12

Gambar V-8 Assignment status dari reviewer pada proses lama

Pada proses baru, dikarenakan reviewer langsung harus menyetujui, maka assignment status

“pending” akan diganti ke “belum review”, yang menandakan bahwa reviewer belum

memberikan review. Datpat dilihat pada Gambar V-9.

Gambar V-9 Pengubahan status menjadi "belum review"

Setelah proses tersebut di-deploy dan diuji, maka akan dilakukan penyesuaian pada bagian

client. Sebelumnya jika pusat penelitian menilai bahwa proposal dapat diterima dan

dilanjutkan ke tahap review, maka akan dilanjutkan ke halaman pemilihan reviewer, maka

dengan proses yang baru proses pemindahan ke halaman pemilihan reviewer ini akan

memanggil proses bisnis ChooseReviewer setelah sebelumnya mengambil nama-nama

reviewer yang mungkin dengan memanfaatkan web service WSUser.

Perubahan pada client yang dilakukan adalah menambah mekanisme pengambilan reviewer.

Reviewer dipilih berdasarkan kelompok keahliannya. Setiap reviewer yang memiliki

kelompok keahlian yang cocok dengan RFP proposal terkait akan dimasukkan sebagai

reviewer proposal tersebut. Misalkan terdapat sebuah proposal untuk RFP dengan bidang ilmu

kelompok keahlian Rekayasa Perangkat Lunak dan Data, maka seluruh reviewer yang berasal

dari kelompok keahlian Rekayasa Perangkat Lunak dan Data akan dimasukkan menjadi

reviewer.

5.2.2.4 Penambahan Task Pembuatan Dokumen PDF Sebagai Kontrak Penelitan

Pada proses sebelumnya, pembukaan penelitian dilakukan dengan proses OpenResearch.

Proses ini hanya memanggil operasi createResearch pada web service WSResearch dan

mengubah status proposal menjadi sudah disetujui. Proses tersebut dapat dilihat pada Gambar

V-10.

V-13

Proses bisnis baru membutuhkan adanya pembuatan dokumen PDF sebagai kontrak penelitian

saat pemanggilan proses pembukaan penelitian. Pembuatan dokumen ini merupakan fungsi

baru yang tidak dimiliki oleh sistem sebelumnya. Untuk memfasilitasi ini, dibuat sebuah web

service baru yang bernama WSDocument, lalu disediakan operasi createResearchContract di

dalamnya.

Gambar V-10 Proses Bisnis OpenResearch

Untuk memasukkan proses pembuatan dokumen ini di dalam proses OpenResearch, maka

akan ditambahkan pemanggilan ke operasi createResearchContract di dalamnya. Hasilnya

dapat dilihat pada Gambar V-11.

Gambar V-11 Proses OpenResearch dengan Pembuatan Dokumen

V-14

Proses baru lalu dapat di-deploy dan diuji. Untuk proses ini tidak dibutuhkan penyesuaian

terhadap client karena parameter pemanggilan dan penggunaan proses OpenResearch sama

dengan sebelumnya.

5.2.3 Hasil Pengujian

Dari hasil pengujian pengubahan proses bisnis terhadap tiga kasus di atas, dapat dilihat bahwa

model penerapan BPMS pada SOA seperti telah didefinisikan pada Bab 3.1 dapat

memfasiltasi pengubahan proses bisnis dengan menerapkan langkah-langkah yang dianalisis

pada Bab 5.2.2.

Hasil pengujian tersebut juga menunjukkan bahwa keempat langkah tersebut tidak selalu

harus dilaksanakan semua. Cukup langkah-langkah yang diperlukan saja. Hal ini dapat dilihat

pada uraian berikut:

1. Pada pengujian pertama, pada Bab 5.2.2.1, proses ChooseReviewer yang lama

akhirnya digunakan ulang untuk memfasilitasi proses bisnis baru, sehingga tidak

perlu membuat proses bisnis baru.

2. Pada pengujian ketiga, pada Bab 5.2.2.3, aplikasi client yang mengakses

OpenResearch tidak perlu mengalami modifikasi, dikarenakan yang berubah hanya

proses bisnis yang terjadi di dalamnya. Aplikasi client tidak perlu tahu detil proses

yang berlangsung dari proses bisnis yang dipanggilnya.

Selain itu, usaha yang cukup kecil untuk merancang ulang proses bisnis ChooseReviewer

pada pengujian kedua, dapat menjadi sebuah nilai tambah, dikarenakan secara umum untuk

mengubah proses, hal yang harus dilakukan hanya mengubah parameternya saja.

Seperti dijelaskan pada Bab 5.2.2.1, untuk melakukan pengubahan proses bisnis pada sistem

tanpa SOA dan BPMS dibutuhkan empat langkah. Langkah yang sama juga dibutuhkan untuk

pengubahan proses bisnis pada model BPMS dan SOA, seperti dijelaskan pada Bab 5.2.2.2.

Keduanya memiliki langkah-langkah yang dapat dibilang sejenis, oleh karena itu dapat dilihat

perbandingan dari kedua langkah-langkah tersebut pada Tabel V-6.

Tabel V-6 Perbandingan Kedua Model

No. Umum BPM pada SOA Perbandingan dan Catatan 1 Mengubah kode

modul atau komponen, menambah dan mengurangi komponen jika dibutuhkan

Mengubah rancangan proses bisnis, menambah dan mengurangi web service yang terlibat

• Model BPM pada SOA memiliki keunggulan dalam visualisasi, sehingga lebih mudah dan memfasilitasi pihak-pihak yang tidak bisa melakukan pemrograman untuk merancang proses bisnis.

• Pada Model BPM pada SOA proses bisnis dapat digunakan ulang, tidak harus diubah.

• Effort yang dilakukan pada model BPM pada SOA relatif lebih sedikit.

2. Melakukan deployment modul

Membuat kode BPEL dari rancangan dan

• BPMS memberi kemudahan untuk melakukan deployment proses bisnis.

V-15

No. Umum BPM pada SOA Perbandingan dan Catatan atau komponen melakukan deployment

ke server BPMS, yang ditangani oleh BPMS

• Deployment komponen pada model umum dapat menggunakan kakas atau dilakukan secara manual

3. Melakukan pengujian terhadap modul atau komponen

Melakukan pengujian proses bisnis dengan memanfaatkan kakas pengujian dari BPMS

• Pengujian umum dilakukan dengan membuat driver, driver dapat dibuat dengan kakas, misalnya jUnit.

• Untuk BPMS tertentu, kakas pengujian sudah tersedia sehingga proses bisnis dapat dipanggil secara simulasi dengan memasukkan parameter yang diinginkan.

4. Melakukan penyesuaian dan pengujian terhadap modul atau komponen lain yang mengakses modul atau komponen yang berubah

Melakukan penyesuaian dan pengujian terhadap modul atau komponen yang mengakses proses bisnis

• Pada model BPM pada SOA, pengubahan kode program dilakukan hanya pada sisi lapisan teratas, yaitu client. Pengubahan itu pun tidak harus selalu dilakukan.

• Pada model yang tidak menerapkan BPM pada SOA, pengubahan lebih dimungkinkan untuk terjadi, kecuali perangkat lunak tersebut memiliki rancangan yang baik.

Dari hasil di atas dapat dilihat bahwa model BPMS pada SOA memiliki keunggulan terhadap

model tanpa penggunaan SOA dan BPMS dalam hal pengubahan proses bisnisnya,

dikarenakan adanya visualisasi untuk mengubah proses bisnis, usaha lebih kecil untuk

melakukan pengubahan proses bisnis, dan meminimalkan pengerjaan pengubahan kode

program, sehingga memfasilitasi pihak-pihak yang tidak menguasai pemrograman dan

mendukung pengubahan proses bisnis yang mungkin akan sering terjadi.