Bab III Analisis Sistem Saat Ini Pada Bab 3 ini memberikan gambaran dan penjelasan mengenai fungsi-fungsi yang ada di sistem yang saat ini masih berjalan. Aspek-aspek apa saja yang menjadi masalah sehingga suatu sistem perlu direkayasa ulang, terutama pada struktur programnya. Setelah perbaikan struktur program, maka dapat dipilih beberapa bagian yang diusulkan untuk ditingkatkan kebutuhan nonfungsionalnya dalam hal aksesibilitasnya. Spesifikasi kebutuhan perangkat lunak menjadi suatu hal yang penting dalam pembangunan sebuah sistem. Kebutuhan perangkat lunak dapat dibagi dua kategori besar yaitu kebutuhan fungsional dan kebutuhan non fungsional. Kebutuhan fungsional meliputi kegiatan atau proses bisnis yang harus diimplementasikan di dalam perangkat lunak, sedangkan kebutuhan non fungsional meliputi semua komponen yang mendukung proses bisnis tersebut. Cara pengumpulan kebutuhan dilakukan dengan cara observasi terhadap sumber dokumentasi yang tersedia dan berdasarkan pengalaman dalam mengembangkan aplikasi itu.
III.1 Tentang Financial Partners International, LTD (FPI) Berdasarkan referensi [8], Financial Partners adalah kelompok layanan finansial lepas pantai yang terkemuka dengan kehadiran yang kuat di Asia Pasifik dan Timur Tengah. Dengan tim-tim terdedikasi dari adviser dan wealth manager yang terpercaya, dan lebih dari 1 milyar USD dibawah bimbingan, dari 250 juta USD di dalam struktur hak milik, FPI mengantarkan level tertinggi dari perencanaan finansial dan layanan manajemen kekayaan ke klien-klien lebih dari 70 negara di dunia.
Perusahaan ini memiliki sejarah sejak 1989 ketika dimulai sebagai enam perusahaan laporan finansial yang independen. Pada 2002, perusahaan-perusahaan ini bergabung menjadi Financial Partners International Ltd. Setelah berkembang dari kekuatan ke kekuatan, perusahaan ini pada 2007 menamakan kembali sebagai Financial Partners dan membentuk perusahaan induk, Financial Partners Bank (FP Bank). FP Bank dijalankan untuk menjadi bank offshore terkemuka
22
dan akan memperkenalkan sebuah rangkaian pasar terkemuka dari suatu badan hukum dan layanan bank eceran di akhir 2008.
Financial Partners mengenali bank-bank yang mentalitasnya masih beku dalam meraih pasar eceran atau pasar dengan nilai keuntungan tinggi. Pengaturan posisi campuran ini dirancang untuk menangkap tiga kedudukan yang berbeda. -
Pertumbuhan segmen expatriate.
-
Kenaikan tren kekayaan individu secara gesit di Timur Tengah dan daerah Asia Pasifik.
-
Pertumbuhan bangsa dari SME.
Gambar III.1 Target Market Chart [8]
Bagian kekayaan lapisan tengah yang tergambar di Gambar III.1 mengacu ke pasar pribadi dan bersama. Ini berarti target sweet spot mencakup kemakmuran yang tampak (klien dengan kemampuan penghematan 1000 USD per bulan) dan kemakmuran besar individual (klien dengan jumlah aset yang diinvestasi antara 100.000 sampai 500.000 USD) dan ukuran menengah perusahaan pada perjalanannya untuk menjadi perusahaan yang lebih besar.
Dengan lebih dari 120 adviser dan wealth manager terpercaya, Financial Partners menyediakan perencanaan finansial best-of-breed, wealth management dan layanan legal ke klien dasar lebih dari 13.000. Dengan menggunakan mesin kembar dari platform teknologi status suatu seni dan layanan tinggi yang disesuaikan, FP menyediakan 24/7 akses balance sheet, dalam kajian 23
portfolio face-to-face yang strategis, seminar World Tour untuk klien untuk bertemu dengan fund manager yang mengatur dananya dan iuran gratis ke majalah dua bulanan yang bernama MoneyMatter, untuk berita dan wawasan pada pasar dan tren investasi. Layanan ini lebih jauh ditingkatkan dengan sistem manajemen risiko bisnis tersentralisasi yang memungkinkan untuk mengelola klien dan hubungan produk-provider di dalam lingkungan yang dipercayakan ke pengaturan dan penyesuaian bersama.
Sementara itu, jaringan cabang FPI yang ada ini beroperasi sebagai fondasi untuk strategi distribusi yang lebih luas, terpisah ke model langsung dan tak langsung. Produk dan layanan didistribusikan menggunakan sebuah kombinasi dari dua model yang bertujuan untuk memaksimumkan keberadaan brand ketika menyediakan distribusi yang efisien yang jauh melampaui kompetisi ini.
III.2 Struktur Menu Aplikasi Berdasar Pengguna Diagram struktur organisasi tergambar pada Lampiran C mulai halaman C-2 dan C-3. Diagram pada lampiran tersebut diperoleh dengan melihat struktur menu ketika login dengan tiga kelas pengguna. Kemudian pada bagian ini akan diberikan deskripsi mengenai item-item menu tersebut. Menu-menu yang dimiliki oleh kelompok Central: 1. Report a. SF i. SF001: melihat jadwal adviser terpilih terhadap klien dalam suatu periode terpilih, yaitu SR Date yang lebih tua dari Next Review Date dan SR Date yang lebih muda dari Next Review Date, baik yang sudah dipenuhi maupun belum. ii. SF002: melihat jumlah klien yang ada pada tiap adviser yang ada pada suatu branch terpilih dalam periode Bulan-Tahun, ini adalah summary dari SF001. iii. SF003: melihat jumlah klien yang ada pada tiap branch dalam periode Bulan-Tahun, ini adalah summary dari SF002. 24
b. Client list: melihat report semua jadwal adviser terhadap klien-klien, yaitu client category, Last SR, Next Review Date dan SR Date. c. Client Without SR: melihat report mengenai daftar nama-nama klien pada adviser terpilih beserta dengan periode pertemuannya (dalam bulan), dimana daftar klien yang ada di daftar adalah klien yang jadwalnya belum dipenuhi atau Next Review Date yang sudah dilengkapi dengan SR Date. d. List of Execution Only: melihat report mengenai daftar nama-nama klien yang tidak akan ditemui oleh adviser. e. SR-General Report: melihat report umum berisi summary per branch tentang statistik jumlah jadwal-jadwal klien yang terlayani dan jumlah klien aktif yang SR Date-nya lebih muda dari Next Review Date. f. Reschedule: melihat daftar jadwal-jadwal pada periode terpilih yang sudah pernah digeser dari jadwal yang sebelumnya pernah ditetapkan. 2. Maintenance a. Feeding: entri data otomatis yang sumber datanya berasal dari bentuk mentah (dari excel yang sudah dalam bentuk file txt). b. Client Data: untuk modifikasi data-data klien. 3. Manual a. Feeding: user manual tentang tata cara melakukan feeding. 4. Home: kembali ke halaman utama yang terdapat jumlah klien yang dikelompokkan per branch dan kategori. 5. Log Off
Menu-menu yang dimiliki oleh kelompok Adviser: 1. Editor a. Schedule Editor: mengedit jadwal yang sudah ada untuk diubah sendiri oleh adviser. 2. Report a. Printable Schedule: sama seperti SF001 hanya saja dapat melihat jadwaljadwalnya sendiri dan tidak dapat melihat jadwal adviser lain. 25
b. Client list: Daftar nama semua klien dan jadwalnya dari adviser yang sedang login. c. Schedule Aging: melihat daftar jadwal klien yang belum ditemui dalam rentang kurun waktu tertentu yang diberi indikator khusus. 3. Log Off 4. Help: berisi user manual untuk pengguna Adviser.
Menu-menu yang dimiliki oleh kelompok Branch: 1. Report a. SF002: melihat jumlah klien yang ada pada adviser tertentu yang ada pada suatu branch terpilih dalam periode Bulan-Tahun. Jika hyperlink nama branch diklik maka akan menampilkan daftar nama adviser dari branch terpilih dan nilai berupa jumlah klien dikelompokkan per client category. 2. Home: menampilkan total klien yang dikelompokkan per branch dan dari tiap branch dikelompokkan kategori klien itu. Hyperlink tersedia pada nama branch jika diklik maka akan menampilkan report berupa daftar semua adviser beserta total kliennya pada branch terpilih. 3. Log Off. 4. Help: berisi user manual untuk pengguna Branch.
III.3 Tabel-Tabel Basis Data Tabel III.1 Deskripsi tabel-tabel basis data Servicing
Nama Tabel
Deskripsi
TblMastClientList
tabel master yang menyimpan data-data klien, baik klien yang aktif maupun klien yang sudah tidak aktif atau drop off
TblMastSF001
tabel
master
yang
berisi
pertemuan klien dengan adviser
26
jadwal-jadwal
Tabel III.1 Deskripsi tabel-tabel basis data Servicing (lanjutan)
Nama Tabel
Deskripsi
TblExcelSearchList
tabel sementara yang berisi data-data mentah dari sumber file (excel) utama yang telah ditransformasikan ke format SQL Server
TblExcelExtend
tabel sementara yang berasal dari sumber file (excel) kedua yang merupakan hasil dari tim Data Processing dan telah ditransformasikan ke format SQL Server
TblChangeCategory
tabel yang menyimpan permintaan-permintaan terhadap perubahan client category, baik yang sudah diproses maupun belum diproses
TblLogChangeCategory
tabel yang mencatat log dari transaksi yang berhubungan dengan perubahan client category
TblHistory
tabel yang mencatat log dari transaksi yang berhubungan dengan perubahan jadwal
TblDeclineSR
tabel untuk menyimpan permintaan mengenai Decline SR
M_ActTakenCode
tabel statis yang berisi kode-kode mengenai nama-nama
aksi
beserta
langkah
yang
dilakukan berikutnya terhadap aksi itu
Tabel III.1 menjelaskan sekilas mengenai tabel-tabel yang dibutuhkan pada basis data Servicing. Untuk struktur dari keseluruhan tabel diatas dan deskripsinya, dapat dilihat pada Lampiran A. Diagram hubungan antar entitas dapat dilihat pada Gambar III.2.
27
Gambar III.2 ERD Servicing Database
III.4 Definisi Properti Umum Pada Servicing Database terdapat properti-properti umum yang digunakan untuk report dan form, keterangannya dapat dilihat pada Tabel III.2.
Tabel III.2 Definisi properti umum
No 1
Nama Field Date Last Seen
2
NRD
Keterangan tanggal terakhir kali bertemu dengan klien jadwal yang ditetapkan pertama kali pada saat memasukkan jadwal baru. Nilai ini akan menjadi konstan karena agar 28
Tabel III.2 Definisi properti umum (lanjutan)
No
Nama Field
3
Counter
4
SR Date Scheduled atau Next Review
5
Actual SR Date atau sering disebut SR Date
6
Indicator
7
SR Attached
8
Last Review
9
Last SR
10
Servicing Frequency atau SR Frequency
11
SR Frequency Notes 29
Keterangan diketahui bahwa jadwal yang ditetapkan pada saat ini pada awalnya ditetapkan Nilai yang menunjukkan berapa kali jadwal tersebut dipindahpindah jadwal yang ditetapkan pada saat ini, pada inisialisasi nilai ini akan sama seperti NRD tanggal sebenarnya dari seorang adviser bertemu dengan klien itu. Bagian ini akan ada nilainya jika adviser benar-benar sudah memenuhi jadwal pertemuannya dengan klien. berupa warna (transparan, hijau, kuning, merah) yang menandakan umur jadwal dari awal pembentukan (NRD) sampai sekarang. Transparan berarti umur jadwal muda, warna merah berarti umur jadwal tua Menandakan apakah suatu jadwal sudah dipenuhi atau belum jadwal sebelumnya yang dibentuk sebelum jadwal pada Next Review dibentuk tanggal seorang adviser menemui klien sebelum jadwal pada Next Review dibentuk perioda klien menemui advisernya dalam satuan bulan mulai dari bulan sekarang sampai bulan berikutnya. catatan terhadap klien apakah ditolak atau tidak untuk SR
Tambahan dari Tabel III.2 diatas ada properti bernama ActionTaken, ActionRequired dan Comment yang terdapat pada halaman jadwal yang dapat diedit (Schedule Editor). Pilihan yang ada pada ActionTaken, tergantung pilihan dari Action Required dan dapat dilihat pada Tabel III.3. Kemudian nilai Comment juga akan dibangkitkan otomatis setelah SR Date Scheduled diubah nilainya. Tabel III.3 Tabel Action Taken dan Action Required
Action Taken Attempt Attempt to Make Contact Attempt to Make Passive
Contact No Contact No SR Online Strategic Review
Strategic Review
Action Required As Per Active As Per Active Option As Per Passive Option Made Contact Unable to Make Contact None Made Emailed/Telephone/Mail None Forward Date Meeting Done Meeting Booked Forward Date Meeting Done Meeting Booked
Dari properti yang dimiliki oleh suatu report, maka dapat diturunkan menjadi berbagai macam report tergantung dari kebutuhan. Inti dari report tersebut adalah interaksi antara klien dengan jadwal yang menyertainya.
III.5 Proses Bisnis Pada bagian ini akan dibahas proses bisnis umum yang diperoleh dari eksekusi program, pembelajaran kode sumber dan dokumentasi yang tersedia. Proses bisnis yang akan dianalisis ini dapat memberikan informasi-informasi tambahan mengenai keadaan sistem saat ini dan sebagai tambahan terhadap dokumentasi program yang disediakan seadanya. 30
Rincian semua halaman web dalam bentuk gambar dan keterangan tertentu, dapat dilihat pada Lampiran M. Halaman-halaman web pada Lampiran M dikelompokkan berdasarkan pengguna dari sistem ini, tiap-tiap tampilan halaman web dijelaskan secara rinci untuk diketahui fungsionalitas dari sistem saat ini. Untuk mengetahui struktur organisasi file web, dapat dilihat pada Lampiran C halaman C-1. Struktur organisasi ini menunjukkan bagaimana file-file itu disimpan secara fisik pada suatu subdirectory agar mudah dilacak file itu jika ingin melakukan suatu perubahan.
Setelah melakukan pembelajaran terhadap kode sumber yang ada pada aplikasi Servicing Database, bahwa dapat diambil kesimpulan fungsi-fungsi utama yang dimiliki Servicing Database, yaitu: 1. Melihat laporan jadwal klien: laporan jadwal klien berupa jadwal yang telah ditetapkan, tanggal sebenarnya dalam memenuhi jadwal itu, tanggal terakhir kali bertemu dengan klien dan jadwal klien sebelum jadwal baru ditetapkan. Dari informasi yang ada itu dapat diturunkan menjadi laporan-laporan dalam bentuk lain, seperti a. Summary dari jumlah jadwal klien yang dilayani oleh tiap adviser kemudian diagregasikan untuk melihat per branch. b. Informasi mengenai klien yang tidak akan ditemui oleh adviser. c. Informasi mengenai jadwal yang digeser. d. Informasi mengenai jadwal klien yang belum dipenuhi. e. Informasi jadwal klien yang pemenuhannya terlambat dari jadwal yang telah ditetapkan. f. Informasi mengenai indikator umur jadwal yang telah ditetapkan pertama kali sebelum digeser. 2. Modifikasi/menggeser jadwal: atas alasan tertentu, jadwal pertemuan antara adviser dengan klien dapat saja digeser dari jadwal yang telah ditetapkan pada awalnya. 3. Modifikasi data-data klien, baik secara manual maupun otomatis (sistem Feeding).
31
Dari fungsionalitas yang telah dijelaskan di atas, maka dapat dibentuk diagram Use Case seperti pada Gambar III.3.
Melihat Report SF001
Feeding Data
Mengubah jadwal
Adviser
Permintaan Perubahan Client Category
<
>
Menolak Perubahan Client Category
<<extend>>
Branch
Konfirmasi Perubahan Client Category
Edit Data Client
<<extend>> Menyetujui Perubahan Client Category
Central
Melihat Report SF002
Melihat Report SF003
Gambar III.3 Diagram Use Case Servicing Database Tabel III.4 Deskripsi Use Case Servicing Database
No 1 2 3 4 5 6
Nama Use Case Melihat Report SF001
Deskripsi Melihat report berupa jadwal-jadwal adviser terhadap klien Mengubah jadwal Memodifikasi data-data jadwal, termasuk menggeser jadwal ke suatu tanggal tertentu Permintaan Perubahan Client Usulan yang dilakukan untuk meng-upgrade client Category category ke kelas yang lebih atas Melihat Report SF002 Melihat report berupa summary dari jadwal-jadwal adviser terhadap klien yang dikelompokkan per adviser Melihat Report SF003 Melihat report berupa summary dari SF002 yang dikelompokkan per branch Menolak Perubahan Client Menolak usulan tentang permintaan upgrade client 32
Tabel III.4 Deskripsi Use Case Servicing Database (lanjutan)
No 7 8 9
Nama Use Case Deskripsi Category category Menyetujui Perubahan Client Menyetujui usulan tentang permintaan upgrade client Category category Edit Data Client Mengubah data-data klien yang telah ada secara manual Feeding Data Pengentrian data secara otomatis yang mentransformasi data dari bentuk mentah ke basis data
Peraturan-peraturan yang dapat diambil melalui pembelajaran dari kode sumber dan pengalaman para pengembang: 1. Penambahan data klien baru hanya lewat entri otomatis yang disebut dengan sistem Feeding. 2. Kegiatan transaksi pada Servicing Database dihentikan selama dalam proses Feeding. Sebelum melakukan Feeding, harus dilakukan backup terlebih dahulu agar pada saat terjadi kegagalan dapat dilakukan recovery untuk menjaga konsistensi dan integritas dari basis data itu. 3. Formulir yang ada untuk modifikasi data klien, tidak dapat menambah data klien baru, melainkan hanya dapat mengubah beberapa properti dari klien. 4. Untuk klien baru dengan kategori bukan Execution Only atau Lost Contact, akan memiliki jadwal baru. 5. Setiap klien yang masih diperbolehkan untuk Strategic Review (akan ditemui oleh adviser) dapat memiliki lebih dari satu jadwal, tetapi hanya satu jadwal saja yang diacu untuk dipenuhi, jadwal sebelumnya yang telah terpenuhi akan menjadi data-data historis. 6. Setelah suatu jadwal klien dipenuhi, maka secara otomatis akan dibuatkan jadwal baru untuk klien itu jika tidak ada jadwal lainnya. Aliran kerja dapat dilihat pada Gambar III.4. 7. Jadwal yang sudah ditetapkan dapat digeser dan tanggal tidak akan lebih tua dari tanggal hari ini. Jadwal pada awal pembentukan akan disimpan dan dihitung umurnya serta diberikan indikator khusus. 8. Jika terdapat permintaan Decline SR terhadap klien, maka Central akan melakukan update terhadap data klien dan mengubah statusnya menjadi No SR, yang berarti klien ditolak untuk Strategic Review atau tidak akan ditemui oleh adviser. Jika klien ditolak 33
untuk Strategic Review dan masih ada data jadwal ke depan, maka jadwal itu secara otomatis akan dihapus. Aliran kerja dapat dilihat pada Gambar III.5. 9. Permintaan mengenai perubahan client category terhadap suatu klien akan dianggap sudah diproses jika telah disetujui oleh General Manager dan Central telah melakukan update manual terhadap data client category. Aliran kerja dapat dilihat pada Gambar III.6.
Gambar III.4 Aliran kerja proses pemenuhan jadwal
Entri data klien yang ada dalam Servicing Database ini dapat bersifat otomatis dan manual. Entri otomatis ini dilakukan dengan cara Feeding yang mencakup insert, update dan delete terhadap data jadwal. Data klien pada entri otomatis tidak dihapus, melainkah hanya diberi flag saja. Entri manual biasanya dilakukan oleh Central melalui halaman “Client Data”, operasi yang dilakukan hanyalah update beberapa properti klien yang ada dan sebagian besar adalah data jadwal, operasi insert dan delete hanyalah terhadap jadwal yang dimiliki oleh klien itu. Perbandingan antara Sistem Feeding dan Manual dapat dilihat pada Tabel III.5.
34
Tabel III.5 Perbandingan Sistem Feeding dan Manual
Kemampuan
Sistem Feeding
Sistem Manual (form)
Tambah data klien baru
Ya
Tidak
Hapus data klien
Tidak, klien ditandai dengan Tidak tersedia flag “drop off”
Tambah jadwal klien
Satu jadwal untuk tiap klien Dapat lebih dari satu jadwal, baik baru, kecuali frequent=0
Menggeser, komentar aksi/tindakan
memberikan Tidak
klien baru maupun lama Ya
serta terhadap
jadwal Update data master klien
Semua field
SR Frequency, Completed SR within the last 12 month, Client Category (atas persetujuan General Manager)
Gambar III.5 Diagram proses Decline SR
35
Gambar III.6 Diagram proses perubahan client category
Feeding adalah update data (insert/update/delete) otomatis terhadap data master yang telah ada dengan sumber data mentah berasal dari excel yang sudah ditransformasi menjadi format txt. Tabel master yang terpengaruh untuk di-update yaitu TblMastClientList (data klien) dan TblMastSF001 (data jadwal). Tabel-tabel yang menyimpan log juga terpengaruh seperti TblLogChangeCategory dan TblHistory. Sumber data untuk melakukan feeding terdiri dari dua buah file, yaitu 1. SearchList.txt: report yang dibangkitkan oleh suatu aplikasi desktop khusus bernama NAV yang biasa digunakan oleh staf untuk entri data-data. Khusus report ini hanya berisi 36
data-data klien saja yang dibutuhkan untuk meng-update tabel master untuk klien, kemudian dari tabel master untuk client akan meng-update tabel master untuk jadwal. 2. ExcelExtend.txt: report berupa excel yang sudah diedit oleh tim data processing, berisi informasi tambahan mengenai klien yang akan di-update nilainya, tabel master untuk jadwal tidak di-update.
Berikut ini akan dijelaskan proses-proses utama dalam Feeding, baik itu Feeding yang sumber file utama berasal dari SearchList (file pertama) maupun dari ExcelExtend (file kedua). Gambar III.7 dan III.8 akan mendeskripsikan proses-proses Feeding yang utama, berikut dengan keterangannya.
Gambar III.7 Proses feeding untuk sumber data dari file kedua
37
Gambar III.8 Diagram proses feeding untuk sumber data dari file utama
Berdasarkan diagram pada Gambar III.8, maka tahapan-tahapan feeding untuk sumber data dari file utama (SearchList.txt) : 38
1. Modifikasi data master klien a. Set flag ke drop off jika daftar klien di master ada dan di file sumber tidak ada. b. Set flag ke old jika daftar klien di master sudah drop off tetapi di file sumber ada (aktivasi klien yang sudah drop off). c. Update data-data klien yang sudah ada berdasarkan pada sumber file jika ada properti dari klien yang diubah nilainya (seperti nama adviser, branch, alamat, dan sebagainya). 2. Modifikasi data master jadwal a. Tambahkan jadwal baru untuk klien yang belum memiliki jadwal, baik itu klien baru maupun klien dropoff yang telah diaktifkan. b. Update data-data jadwal yang sudah ada berdasarkan informasi yang ada di master klien jika ada perubahan. c. Hapus jadwal-jadwal ke depan (tanggal lebih muda dari sekarang) untuk klien yang dropoff dan memiliki status bahwa klien tersebut tidak akan ditemui. Berdasarkan diagram pada Gambar III.7, tahapan-tahapan feeding untuk sumber data dari sumber file kedua (ExcelExtend.txt) 1. Update semua field kecuali clientcategory, field yang mengandung client category pada feeding dari excelsearchlist, diabaikan dan tidak dipakai. 2. Update client category yg nilai asal null (new client atau penyesuaian dari yg lama). 3. Update client category yang ada flag #special# jika sudah lebih dari satu tahun. 4. Update client category yang tidak mengandung flag #special#.
III.6 Gambaran Umum Kode Awal Aplikasi ini dibangun dengan bahasa pemrograman ASP.NET dengan development tools-nya menggunakan Ms Visual Studio.NET 2005 dengan basis datanya menggunakan Ms SQL Server 2005. Bahasa pemrograman ini adalah bahasa pemrograman yang berorientasi objek, tetapi pada prakteknya belum mengembangkan aplikasi berorientasi objek dengan baik.
39
Pada lampiran B didaftarkan kelas-kelas utama lengkap dengan semua field dan method-nya. Diagram hubungan antarkelas pada awalnya belum terlihat jelas. Kelas-kelas utama seperti AdviserView, BranchView dan CentralView adalah penamaan kelas berdasarkan aktor yang melakukan pekerjaan itu. Kelas tersebut adalah kelas-kelas besar yang memiliki jumlah field dan method yang banyak. Kelas lainnya adalah Feeding dan ClientCategoryChange yang melakukan pekerjaan sesuai dengan fungsinya. Tiap-tiap kelas utama yang ada belum memiliki field atau method dengan tipe data berbentuk suatu kelas. Tipe data utama yang digunakan pada field itu adalah tipe data primitif atau tipe data khusus yang disediakan oleh Ms Visual Studio .NET. Tipe data khusus yang biasa digunakan adalah tipe data untuk DataTable. Method yang ada pada umumnya memiliki satu parameter atau tanpa parameter. Tipe data keluaran untuk method itu rata-rata berbentuk DataTable, beberapa field diberikan assignment dari nilai field keluaran hasil query. Tiap method yang melakukan update atau memuat suatu data biasanya memanggil suatu store procedure.
III.7 Deteksi Smells Aplikasi Smells dapat dideteksi setelah melalui beberapa proses pengamatan terhadap kelas dan kodekodenya berdasarkan gejala-gejala bad smell yang telah dipelajari pada [3]. Bagian program yang merupakan bad smells adalah bagian dari suatu program yang perlu direkayasaulang, setelah itu dapat dipilih kombinasi dari salah satu atau lebih teknik refactoring yang telah dipelajari sebelumnnya pada [2]. Pada Tabel III.6 terdapat smell yang telah terdeteksi pada aplikasi ini dengan mengacu pada Tabel II.1 mengenai gejala-gejala bad smell dan teknik mengatasinya.
Tabel III.6 Daftar smells terdeteksi dan teknik pendeteksiannya
Nama Smell
Terdeteksi
Teknik pendeteksian (jika terdeteksi)
Duplicated Code
Ya
Dengan melihat pola kode yang sama pada program
Long Method
Tidak
40
Tabel III.6 Daftar smells terdeteksi dan teknik pendeteksiannya (lanjutan)
Nama Smell
Terdeteksi
Teknik pendeteksian (jika terdeteksi)
Large Class
Ya
Dengan melihat jumlah field dan method pada kelas
Long Parameter List
Tidak
-
Dead Code
Ya
Dengan bantuan Reflector diperiksa “used by” dari tiap-tiap method
Inconsistency Ya names
Dengan harus mengetahui semantik dari tiap-tiap nama field dari kelas
Divergent Change
Ya
Dengan memperhatikan method/kode yang sama pada tiap-tiap bagian aplikasi
Shotgun Surgery
Tidak
-
Feature Envy Ya
Dengan harus mengetahui semantik dari method yang dimiliki oleh tiap-tiap kelas.
Data Clumps
Tidak
-
Data Class
Ya
Dengan bantuan Reflector diperiksa tiap field yang ada pada tiap kelas apakah dari setter/getter yang dimiliki digunakan oleh bagian program
Switch Statement
Ya
Dengan memperhatikan pola-pola pada switch/if statement
Dari ke-14 smells diatas hanya delapan smells yang terdeteksi. Alasan-alasan smells lain belum terdeteksi, yaitu: 1.
Long method tidak terdeteksi karena jika diperhatikan jumlah baris pada method itu sudah cukup dan tidak terlalu banyak. 41
2. Long parameter list tidak terdeteksi karena pada method yang sudah ada biasanya terdapat tanpa parameter dan maksimal satu parameter. 3. Data Clumps tidak terdeteksi karena tidak terlihat adanya lebih dari dua item berada bersamaan dalam daftar parameter yang ada pada method. Method yang ada rata-rata tidak memiliki parameter dan maksimal hanya satu parameter dan tidak ada pendeklarasian lebih dari dua item yang sama dalam suatu method. 4. Shotgun Surgery tidak terdeteksi karena perubahan yang terjadi tidak mengharuskan mengubah banyak kelas. Jumlah kelas-kelas utama yang ada tidak terlalu banyak dan hubungan antarkelas tidak terlihat jelas hubungannya. Jadi, jika ingin mengubah suatu kelas tidak perlu mengubah kelas-kelas yang lainnya. 5. Lazy Class tidak terdeteksi karena semua kelas yang ada terpakai semua. Pada proses refactoring dapat menimbulkan efek Lazy Class yang pada akhirnya kelas tersebut tidak digunakan. 6. Parallel Inheritance Hierarchies tidak terdeteksi karena kelas-kelas utama pada awal pembentukannya tidak terlihat jelas hubungannya dan kelas-kelas tersebut terlihat independen, sehingga jika ingin membuat subclass baru maka dapat langsung fokus di subclass itu saja tanpa harus membuat subclass baru yang sejajar.
III.7.1 Large Class Dari Lampiran B dapat terlihat daftar nama-nama kelas utama yang digunakan, lengkap dengan keterangan tentang kelas itu dan daftar nama-nama field dan method dari kelas itu.
Jika diurutkan dari jumlah method paling banyak sampai paling sedikit,urutannya adalah kelas CentralView, Feeding, AdviserView, BranchView dan ClientCategoryChange. Sedangkan dari jumlah field terbanyak sampai paling sedikit, urutannya adalah kelas Feeding, CentralView, AdviserView, BranchView dan ClientCategoryChange. Kelas yang memiliki jumlah field paling banyak dan jumlah method paling banyak adalah kelas yang berukuran paling besar. Kelas dengan urutan mulai paling besar itu perlu untuk di-refactor. Kelas Feeding dan CentralView diindikasi sebagai kelas besar dan dapat juga disebut God Class karena dapat melakukan
42
segalanya. Jumlah field pada CentralView dan AdviserView masih tergolong banyak dan perlu untuk dipecah-pecah agar menjadi kelas yang kecil.
III.7.2 Dead Code Cara pendeteksian Dead Code dapat dilihat pada Lampiran D dengan bantuan tools yang bernama Reflector. Cara ini juga berlaku untuk mendeteksi field atau properti yang sama sekali tidak digunakan. Mulai dari halaman Feeding.aspx, ada sejumlah method yang tidak terpakai. Setelah methodmethod itu dihapus, maka di kelas Feeding dapat dideteksi sejumlah method yang merupakan kode mati, jika sejumlah method itu dihapus maka akan terdapat field yang juga tidak terpakai dan perlu untuk dihapus. Di kelas AdviserView method yang tidak terpakai yaitu: FormatingDate, GetActualSRDate dan UpdateActionTakenDetail. Field eMonthYear pada kelas AdviserView tidak terpakai. Pada
BranchHome.aspx,
method
yang
tidak
terpakai,
yaitu:
LocalPassive(String), LostContact(String), ExecutionOnly(String),
LocalActive(String),
OverseasActive(String),
OverSeasPassive(String). Pada kelas BranchView ada method yang tidak terpakai, yaitu: GetNewSF002Data dan GetSF002Data. Pada
CentralHome.aspx,
method
yang
tidak
terpakai,
yaitu:
LocalActive(String),
LocalPassive(String), LostContact(String), ExecutionOnly(String),
OverseasActive(String),
OverSeasPassive(String).
tidak
Pada
ClientDetail.aspx,
method
yang
terpakai
yaitu:
AdaJadwalKedepan dan PopulateActionRequired(String). Method tidak terpakai pada kelas CentralView, yaitu: CheckScheduleAfter, ListOfActionRequired, ListOfSF002Data, dan ListOfSFGeneralReport. III.7.3 Duplikasi Jika bagian kode yang merupakan Dead Code telah tereliminasi, maka duplikasi yang terkandung di dalamnya juga ikut tereliminasi. Kasus duplikasi terdiri dari: a. Pada Kelas ClientDataHistorys, beberapa potongan kode di method getHistoryByCentral dan getHistoryByBranch terlihat ada code style yang sama diulang-ulang. 43
b. Pada
ClientDataHistory.aspx,
beberapa
potongan
kode
di
method
GetCentralHistoryDetail dan GetBranchHistoryDetail terlihat ada code style yang sama diulang-ulang. c. Pada BranchSummary.aspx dan CentralSummary.aspx, method nilaiCatA, nilaiCatB, nilaiCatC, nilaiCatD, nilaiCatE dan nilaiCatF terlihat code style yang sama diulangulang. d. Pada
AdviserHome.aspx,
antara
method
DefaultNRDComment
dengan
DefaultSRDComment terlihat code style yang sama dan yang beda hanya parameter. e. Pada ScheduleAging.aspx di method getSQLUnion terdapat kondisi kondisional yang terlihat code style yang sama diulang dan yang beda hanya nilai tertentu. f. Pada
kelas
AdviserView,
GetDefaultListZ_D
terlihat
method memiliki
GetDefaultList, code
style
GetDefaultListZ
yang
sama.
Antara
dan method
MultiUpdateSchedule dan UpdateSchedule terlihat adanya pengulangan kode walaupun pada method satunya lagi terdapat beberapa baris kode. g. Pada kelas BranchView, method GetNewSF002DataZ_GT, GetNewSF002DataZ_D dan GetNewSF002Data_GT terlihat memiliki code style yang sama. h. Pada
kelas
CentralView,
method
ListOfSF003Data,
ListOfSF003DataZ
dan
ListOfSF003DataZ_D terlihat memiliki code style yang sama. i. Pada
kelas
AdviserView,
tampak
terjadi
duplikasi
sebagian
antara
method
UpdateSchedule dan MultiUpdateSchedule. Dari kasus yang telah disebutkan, maka rincian lebih lengkap mengenai kode mana yang terduplikasi, dapat dilihat pada Lampiran E. Selain duplikasi di bagian kode, juga ada duplikasi di suatu field. Daftar kelas yang disebutkan pada Lampiran B, terlihat ada memiliki field yang sama dan seharusnya dimiliki oleh satu kelas.
III.7.4 Data Class Semua field pada semua kelas yang ada, terdapat method setter dan getter yang sederhana tanpa filtering. Nilai yang diperbolehkan untuk field itu dapat langsung diterima apa adanya, padahal seharusnya ada nilai yang tidak diperbolehkan untuk field itu. Field yang ada pada kelas tidak
44
semuanya harus memiliki method setter atau getter karena beberapa field ada yang tidak melakukan penyetelan nilai di luar kelas ataupun perolehan nilai field langsung dari luar kelas.
III.7.5 Penamaan Tidak Konsisten Masalah penamaan yang ditemukan yaitu dalam penamaan field. Penamaan dalam field ada yang secara semantik sama, tetapi diberikan nama yang berbeda. Seperti SalesPersonName dengan Adviser, Office dengan Branch. Kelas BranchView yang terlihat pada Lampiran B memiliki nama field yang tidak konsisten. Ini membuat kesulitan dalam melakukan refactor baik dengan cara extract class ataupun extract superclass yang kemudian melakukan pull-up field. Pada kelas AdviserView ada field yang secara semantik sama seperti field yang dimiliki oleh kelas ClientCategoryChange, yaitu NewServiceCategory dengan NewClientCategory dan ServiceCategory dengan CurrentClientCategory. III.7.6 Masalah kondisional if-else Pada ScheduleAging.aspx di method GetSQLUnion terdapat logika kondisional yang seharusnya dapat disederhanakan. Logika kondisional ini dapat menyebabkan duplikasi kode yang tidak perlu. Ketika akan menambah kondisi baru, maka bagian kode tertentu terpaksa diulang-ulang kembali. III.7.7 Divergent Change Method untuk BranchFiller dan AdviserFiller yang identik juga dengan lstBranch dan lstAdviser, selalu tersebar di beberapa halaman web yang mengandung dropdownlist berisi daftar nama Branch dan Adviser. Bagian-bagian web yang terdapat lstBranch, yaitu: a. Central_CentralSummary_Sub b. Central_ClientListPlusNRD c. Central_R_ClientWOSR d. Central_R_SF001 e. Central_R_SF002 f. Central_R_ZeroServicingPeriod g. Central_R_Reschedule 45
Bagian-bagian yang terdapat lstAdviser yaitu: point a, b, c, d, e, g diatas ditambah dengan Branch_SF002. Method getCurrentPeriod yang meminta untuk menyetel nilai periode berdasarkan tanggal hari ini juga biasa diulang-ulang di beberapa halaman. Bagian web yang terdapat periode yaitu: point d, e, g, Central_R_SF003, Branch_SF002 dan Central_R_SRGeneralReport Pada bagian yang telah disebutkan, jika ingin membuat halaman baru yang mengandung kontrol untuk memuat nama-nama branch, adviser atau periode, maka harus membuat kode duplikat yang sama. Jika terjadi perubahan dalam kode untuk memuat kontrol tersebut, maka halamanhalaman lainnya juga harus mengganti kode tersebut. III.7.8 Feature Envy a. Pekerjaan yang seharusnya dilakukan oleh ClientCategoryChange ada yang dilakukan di kelas
AdviserView,
terutama
method
GetChangeCategory_for_sent_to_GM
dan
InsertToChangeCategory. b. Pekerjaan yang harusnya tanggung jawab kelas ClientCategoryChange ada yang dilakukan oleh kelas CentralView, yaitu method CentralProcessChangeCategory dan ChangeCategory. c. Method ComparingDate dan CustomDate tampaknya merupakan method umum yang dapat digunakan oleh semua kelas, tidak hanya AdviserView saja. d. GetLatestNRD dan GetLatestDLS pada ClientList.aspx tampaknya merupakan method umum yang dapat digunakan oleh semua kelas.
III.8 Evaluasi Smell Selain bad smell yang telah terdeteksi berdasarkan gejala-gejalanya, struktur program secara keseluruhan belum terlihat sebagai bahasa berorientasi objek yang baik. Penggunaan adanya hubungan antar kelas yang menyebabkan inheritance, agregasi, polymorphism sebagai konsep dasar berorientasi objek masih belum terlihat dengan jelas hubungannya. Penempatan method pada suatu kelas masih terlihat kurang sesuai dengan maknanya. Pembuatan kelas umum biasanya dikelompokkan berdasarkan aktor atau kelompok pengguna yang menggunakan sistem itu seperti AdviserView, BranchView dan CentralView. Kelas lain yang dibuat berdasarkan 46
peranan seperti kelas Feeding yang khusus menangani Feeding dan kelas ClientCategoryChange khusus untuk proses yang berhubungan dengan perubahan Client Category. Dari smells yang telah disebutkan diatas, maka terlihat beberapa bagian dari suatu aplikasi yang perlu untuk direkayasaulang untuk memenuhi tujuan kemampurawatannya.
III.9 Usulan Pengembangan Aplikasi Untuk Aksesibilitas Usulan ini diperlukan agar suatu perangkat lunak yang pada awalnya diakses melalui web, dapat diakses melalui perangkat nirkabel, baik melalui WAP ataupun SMS. Penyajian informasi dengan media bergerak ini diharapkan dapat meningkatkan pelayanan terhadap suatu klien karena kapan pun dan dimana pun pengguna dapat mengakses informasi tanpa harus berada di meja kerja yang terhubung ke internet.
III.9.1 Berbasis WAP Setelah dideskripsikan semua menu-menu yang terdapat pada versi berbasis web, maka dapat ditentukan beberapa halaman yang akan dibuat versi WAP-nya. Informasi yang dibutuhkan untuk diakses via WAP, yaitu: laporan jadwal klien berupa jadwal yang telah ditetapkan, tanggal sebenarnya dalam memenuhi jadwal itu, tanggal terakhir kali bertemu dengan klien dan jadwal klien sebelumnya sebelum jadwal yang baru itu ditetapkan. Dari informasi yang ada itu dapat diturunkan menjadi laporan-laporan dalam bentuk lain, seperti a. Summary dari jumlah jadwal klien yang dilayani oleh tiap adviser kemudian diagregasikan untuk melihat per branch. b. Informasi mengenai klien yang tidak akan ditemui oleh adviser. c. Informasi mengenai jadwal yang digeser. d. Informasi mengenai jadwal klien yang belum dipenuhi. e. Informasi jadwal klien yang pemenuhannya terlambat dari jadwal yang telah ditetapkan. f. Informasi mengenai indikator umur jadwal yang telah ditetapkan pertama kali sebelum digeser.
47
III.9.2 Berbasis SMS Perintah yang disajikan lewat SMS itu diharapkan dapat menyajikan informasi yang singkat, tepat dan jelas. Berikut ini adalah daftar informasi yang dibutuhkan: 1. Mengetahui nama klien dari suatu kode klien. 2. Mengetahui kode klien dari suatu nama klien. 3. Mengetahui adviser dari suatu klien. 4. Mengetahui jadwal awal klien (NRD) yang dibentuk sebelum digeser, jadwal awal ini dibentuk dan akan menjadi acuan untuk dipenuhi jadwalnya. 5. Mengetahui jadwal klien sekarang ini yang akan dipenuhi (Next Review Date). 6. Mengetahui berapa kali jadwal klien sekarang ini digeser. 7. Mengetahui kapan terakhir kali seorang klien bertemu dengan adviser. 8. Mengetahui client category dari klien tertentu. 9. Mengetahui status klien, apakah merupakan klien baru, lama atau drop off. 10. Mengetahui jumlah bulan yang menunjukkan periode klien bertemu adviser. 11. Mengetahui klien mana yang memiliki jadwal pada suatu periode tertentu dari seorang adviser. 12. Mengetahui daftar klien-klien yang dimiliki oleh seorang adviser.
Dari daftar informasi yang dibutuhkan, maka dapat dibentuk perintah-perintah SMS seperti pada Lampiran G. Untuk mengakses informasi tertentu dalam SMS, dibutuhkan untuk login. Tetapi ada juga perintah SMS yang tidak memerlukan login.
48
