BAB V IMPLEMENTASI DAN PENGUJIAN
advertisement
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-1 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 WSAttachment, 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 masingmasingnya 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. 1 Umum Mengubah kode modul atau komponen, menambah dan mengurangi komponen jika dibutuhkan BPM pada SOA Mengubah rancangan proses bisnis, menambah dan mengurangi web service yang terlibat Perbandingan dan Catatan • • • 2. Melakukan deployment modul Membuat kode BPEL dari rancangan dan • 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. BPMS memberi kemudahan untuk melakukan deployment proses bisnis. V-15 No. Umum atau komponen 3. 4. Melakukan pengujian terhadap modul atau komponen Melakukan penyesuaian dan pengujian terhadap modul atau komponen lain yang mengakses modul atau komponen yang berubah BPM pada SOA Perbandingan dan Catatan melakukan deployment ke server BPMS, yang ditangani oleh BPMS Melakukan pengujian proses bisnis dengan memanfaatkan kakas pengujian dari BPMS • Deployment komponen pada model umum dapat menggunakan kakas atau dilakukan secara manual • Melakukan penyesuaian dan pengujian terhadap modul atau komponen yang mengakses proses bisnis • 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. 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.
