Bab II Tinjauan Pustaka

6

Bab II Tinjauan Pustaka

II.1 Rekayasa Perangkat Lunak

Definisi perangkat lunak menurut [11] adalah: perintah (program komputer) yang bila dieksekusi memberikan fungsi dan unjuk kerja seperti yang diinginkan, struktur data yang memungkinkan program memanipulasi informasi secara proporsional, dan dokumen yang menggambarkan operasi dan kegunaan program.

Berdasarkan [13], rekayasa perangkat lunak berkaitan dengan teori, metode dan kakas yang dibutuhkan untuk mengembangkan perangkat lunak untuk komputer-komputer ini. Dalam sebagian besar kasus, sistem perangkat lunak yang dikembangkan adalah sistem yang besar dan kompleks.

Object-Oriented atau Berorientasi Objek adalah suatu teknik dalam pemodelan sistem, dimana sistem dimodelkan sebagai sejumlah objek-objek yang berinteraksi [9]. OOSE (Object Oriented Software Engineering) atau Rekayasa Perangkat Lunak Berorientasi Objek adalah sebuah bahasa pemodelan objek dan metodologi [5]. OOSE dikembangkan oleh Ivar Jacobson pada 1992 ketika di Objectory AB. OOSE merupakan metodologi perancangan berorientasi objek pertama yang memakai use case untuk memicu perancangan perangkat lunak. Model proses OOSE dapat dilihat pada Gambar II.1 dan diagram hubungannya pada Gambar II.2.

7

Penjelasan tiap fase-fase pada model proses OOSE:

- Analysis bertujuan untuk memperoleh pemahaman dari suatu aplikasi. Pemahaman tergantung hanya pada kebutuhan persyaratan sistem.

- Construction berarti bahwa model analysis dirancang dan diimplementasikan dalam bentuk source code.

- Testing tidak jauh berbeda dengan sistem yang dikembangkan dengan metode lain. Pada fase ini sistem diverifikasi untuk memastikan bahwa sistem dirancang sesuai dengan spesifikasinya.

Gambar II.2 Diagram hubungan OOSE [9]

OOSE bekerja dengan lima model yang berbeda:

- Requirement model bertujuan untuk menangkap persyaratan fungsional. - Analysis model bertujuan untuk memberikan sistem suatu ketahanan dan

struktur objek yang dapat diubah.

- Design model bertujuan untuk mengambil dan memperhalus struktur objek ke lingkungan implementasi saat ini.

- Implementation model bertujuan untuk mengimplementasikan sistem. - Test model bertujuan untuk memverifikasi sistem.

8

II.2 Perawatan Perangkat Lunak

Perawatan perangkat lunak merupakan fase terakhir dalam siklus pengembangan perangkat lunak. Fase ini berfokus pada perubahan yang dihubungkan dengan kesalahan, penyesuaian yang dibutukan ketika lingkungan perangkat lunak berkembang, serta perubahan sehubungan dengan perkembangan yang disebabkan oleh perubahan kebutuhan pelanggan [11].

Definisi umum tentang perawatan yaitu aktifitas “after-the-fact” [10]. Berdasarkan definisi ini, tidak ada aktifitas perawatan yang terjadi selama usaha pengembangan perangkat lunak. Perawatan terjadi setelah produk beroperasi.

Gambar II.3 Proses Perawatan Perangkat Lunak [12]

Perawatan perangkat lunak menurut [10] dibagi menjadi tiga kategori:

- Korektif: perubahan diperlukan untuk memperbaiki error atau bugs yang terjadi di dalam sistem.

- Adaptif: usaha apapun yang dilakukan sebagai hasil dari perubahan di dalam lingkungan dimana sistem perangkat lunak harus beroperasi. Pada tesis ini, terdapat suatu usulan untuk memigrasi sistem perangkat lunak ke versi yang dapat diakses melalui perangkat nirkabel, tidak hanya berbasis web.

- Perfektif: semua perubahan, penambahan, penghapusan, modifikasi, perluasan dan peningkatan dibuat ke sistem untuk memenuhi kebutuhan pengguna yang meluas.

9

- Preventif: perawatan dilakukan dengan tujuan untuk mencegah masalah sebelum terjadi. Pada kasus di tesis ini, maka dilakukan suatu usaha untuk merekayasaulang suatu perangkat lunak agar pada suatu saat terjadi perubahan maka akan lebih mudah dirawat.

Menurut [4], sejumlah faktor yang memotivasi untuk melakukan perawatan perangkat lunak, yaitu:

- Untuk menyediakan kelanjutan layanan. - Untuk mendukung keperluan upgrade.

- Untuk mendukung permintaan pengguna untuk penyempurnaan. - Untuk memudahkan pekerjaan perawatan di masa mendatang.

Jika sistem digunakan, maka perawatan tidak akan pernah berakhir karena sistem akan terus berkembang untuk memenuhi kebutuhan dari lingkungan yang berubah dimana sistem beroperasi [4].

Kegiatan perawatan dirasakan sulit, karena ada beberapa kendala menurut [10], yaitu: - Produk atau proses yang membuat produk tidak dapat dilacak.

- Perubahan tidak terdokumentasi. - Sulit untuk melacak perubahan.

- Munculnya efek riak(ripple effect) ketika melakukan perubahan.

Kurangnya perhatian selama proses pengembangan mengakibatkan kekurangan kemampuan pelacakan, bahkan dalam melacak kesalahan ataupun melakukan perbaikan. Pada akhirnya akan sulit untuk memahami spesifikasi dan kebutuhan pengguna. Akibatnya, perawatan menjadi sulit dan pemahaman pengguna akan perawatan perangkat lunak juga menyebabkan perawatan adalah hal yang sulit untuk dilaksanakan.

10

II.3 Rekayasa Ulang (Reengineering)

Reengineering menurut arti dalam kamus adalah rekayasa ulang suatu produk yang telah ada untuk membuatnya agar lebih berguna. Sedangkan Software Reengineering itu sendiri menurut [13] adalah reorganisasi dan memodifikasi sistem perangkat lunak yang telah ada untuk membuatnya lebih mudah dirawat, menurut [12] Software Reengineering itu adalah suatu bentuk modernisasi yang meningkatkan kemampuan dan/atau kemampurawatan dari sistem lama dengan memperkenalkan teknologi dan praktek modern. Reengineering dapat sebagian atau keseluruhan dari sistem yang akan direkayasa ulang.

Reverse engineering Program documentation Data reengineering Original data Program structure improvement Program modularisation Structured program Reengineered data Modularised program Original program Source code translation

Gambar II.4 Proses Reengineering [12]

Bentuk-bentuk reengineering:

- Retargeting: migrasi sistem lama ke platform perangkat keras yang baru. - Revamping: mengganti antarmuka pengguna

- Penggunaan komponen komersil: komponen yang andal dan terpercaya mampu menggantikan komponen fungsional, dapat meningkatkan kualitas dan performansi dari sistem perangkat lunak yang dibangun.

- Penerjemahan kode sumber: mengubah dari bahasa pemrograman lama ke bahasa pemrograman modern.

- Pengurangan kode: membuang kode-kode yang tidak berguna di dalam program.

11

- Transformasi fungsional: termasuk peningkatan struktur program, modularisasi program dan data reengineering.

Keuntungan dari Reengineering:[13]

- Pengurangan Risiko: ada suatu risiko yang tinggi dalam pengembangan perangkat lunak yang baru. Masalah ini mungkin dalam hal pengembangan, staff dan spesifikasi.

- Pengurangan Biaya: biaya dari Reengineering ini sering kali lebih kecil daripada biaya pengembangan perangkat lunak yang baru.

Proses reengineering terdiri dari Reverse Engineering, kemudian Forward Engineering. Reverse Engineering yaitu menganalisa perangkat lunak dengan pandangan ke pemahaman disain dan spesifikasinya [13]. Setelah Reverse Engineering dilakukan, kemudian melakukan Forward Engineering yaitu rekayasa kembali mulai dari tahap kebutuhan sampai tahap akhir (implementasi).

Gambar II.5 Siklus Forward dan Reverse Engineering[12]

II.4 Refactoring

Dalam istilah matematika, factoring atau faktorisasi adalah dekomposisi suatu objek menjadi ekspresi objek-objek yang lebih kecil. Menurut [3], Refactoring adalah proses penulisan ulang terhadap materi tertulis tersebut untuk memperbaiki readibilitas atau struktur, dengan tujuan eksplisit menjaga makna atau behavior-nya. Software refactoring adalah restructuring (menyusun ulang) kode yang ada dengan mengubah struktur internal tanpa mengubah perilaku eksternalnya. Ini bertujuan untuk menghindari duplikasi.

12 Keuntungan utama menggunakan refactoring:

‐ Memperbaiki rancangan perangkat lunak. ‐ Membuat kode agar lebih mudah dimengerti. ‐ Membantu membuat program lebih cepat. ‐ Membantu mencari bugs.

‐ Mempercepat software reengineering.

Refactoring dibutuhkan pada saat:

‐ Prinsip tiga aturan, yaitu: jika melakukan hal yang sama dan berulang sampai tiga kali, sebaiknya melakukan refactor.

‐ Menambah fungsionalitas baru. ‐ Memperbaiki bugs.

‐ Sebagaimana melakukan kajian terhadap kode.

Masalah yang timbul dalam refactoring:

‐ Basis data: kebanyakan aplikasi bisnis secara ketat terkait ke skema basis data yang mendukungnya.

‐ Perubahan antarmuka.

‐ Perubahan rancangan yang menyebabkan sulit untuk refactor. ‐ Ada saat-saat tertentu yang seharusnya tidak melakukan refactor.

Bad Smell atau disebut kode busuk yaitu kode-kode program yang diindikasi buruk dan perlu untuk di-refactor. Beberapa nama smell yang dikenal tertera pada Tabel II.1.

Tabel II.1 Bad smell dan teknik mengatasinya [3]

Nama Smell Pengertian Teknik mengatasinya

Duplicated Code

Struktur kode yang sama di lebih dari satu tempat

Extract Method, Pull Up Field, Form Template Method, Substitute Algorithm, Extract Class

13

Tabel II.1 Bad smell dan teknik mengatasinya [3] (lanjutan)

Nama Smell Pengertian Teknik mengatasinya

Long Method Jumlah baris program yang sangat banyak di dalam suatu method

Extract Method, Replace Temp with Query, Introduce Parameter Object, Preserve Whole Object, Replace Method with Method Object, Decompose Conditional Large Class Kelas dengan jumlah field yang banyak

dan jumlah method yang banyak, melakukan pekerjaan yang banyak

Extract Class, Extract Subclass, Extract Interface, Duplicate Observed Data Long Parameter List

Method dengan jumlah parameter yang banyak, biasanya sulit untuk dimengerti karena akan menjadi tidak konsisten dan sulit digunakan

Replace Parameter with Method, Preserve Whole Object, Introduce

Parameter Object Dead Code Bagian kode yang sama sekali tidak

terpakai. Kelas, field, method yang tidak terpakai juga tergolong dalam Dead Code.

Remove Field, Remove Method, Remove Class, Hapus beberapa bagian kode

Inconsistency names

Masalah penamaan dalam variabel, kelas, field yang menyebabkan kurang konsisten.

Rename Class, Rename Method, Rename Fied Divergent

Change

Suatu kelas pada umumnya diubah dalam cara yang berbeda untuk alasan yang berbeda. Pada perubahan ini, satu kelas mendapatkan banyak jenis

perubahan. Misalnya tiga method harus diubah ketika didapatkan basis data yang baru.

Extract Class

Shotgun Surgery

Ketika ingin melakukan perubahan, maka harus melakukan perubahan itu di kelas-kelas lain karena suatu perubahan dapat mempengaruhi kelas-kelas lain untuk diubah.

Move Method, Move Field, Inline Class

Feature Envy Suatu kelas yang method-nya itu ternyata lebih perhatian untuk

melakukan pekerjaan kelas lain daripada kelas itu sendiri.

Move Method, Extract Method,

Data Clumps Item-item data yang terlihat selalu ada dan secara bersama-sama muncul dalam banyak method signature atau di dalam beberapa method

Extract Class, Introduce Parameter Object, Preserve Whole Object

14

Tabel II.1 Bad smell dan teknik mengatasinya [3] (lanjutan)

Nama Smell Pengertian Teknik mengatasinya

Data Class Kelas yang memiliki field dengan method setter dan getter yang sederhana tanpa adanya filtering.

Encapsulate Field

Switch/If-Else Statement

Kode dalam bahasa pemrograman berorientasi objek yang mengandung pernyataan-pernyataan kondisional dan di dalam pernyataan tersebut dapat terjadi duplikasi terhadap kode yang seharusnya dapat disederhanakan.

Extract Method, Move Method, Replace Conditional with Polymorphism Parallel Inheritence Hierarchies

Yaitu kasus khusus dalam Shotgun Surgery. Setiap waktu ingin membuat subclass dari satu kelas, maka perlu untuk membuat subclass lainnya.

Move Method, Move Field

Lazy Class Kelas yang dibuat tetapi perhatiannya sangat kurang, bahkan pada akhirnya tidak digunakan sama sekali

Collapse Hierarchy, Inline Class

Aktivitas-aktivitas refactoring:

‐ Identifikasi dimana software seharusnya di-refactor.

‐ Tentukan refactoring mana yang seharusnya digunakan ke tempat yang telah ditentukan.

‐ Menjamin bahwa refactoring yang dipakai mempertahankan behavior. ‐ Gunakan refactoring tersebut.

‐ Perkirakan efek refactoring dari karakteristik kualitas terhadap software (seperti kompleksitas, understandabilitas, kemampurawatan) atau proses (produktivitas, biaya, usaha ).

‐ Pelihara konsistensi antara kode program yang telah di-refactor dengan artifak software lainnya (dokumentasi, dokumen disain, spesifikasi kebutuhan, pengujian, dsb).

II.5 SMS (Short Message Service)

Menurut [7], SMS kepanjangan dari Short Message Service, yaitu teknologi yang memungkinkan untuk mengirim dan menerima pesan antara telepon selular. SMS

15

pertama kali muncul di Eropa pada 1992 dan termasuk di dalam hak GSM (Global System for Mobile Communications) pada permulaan. Kemudian dipindah ke teknologi nirkabel seperti CDMA dan TDMA. Standar SMS dan GSM pada awalnya dikembangkan oleh ETSI (European Telecommunications Standards Institute). Sekarang 3GPP (Third Generation Partnership Project) bertanggung jawab untuk pengembangan dan perawatan standar GSM dan SMS.

Sesuai dengan namanya “Short Message Service” atau “Layanan Pesan Singkat”, data yang dapat ditangani oleh pesan SMS sangat terbatas. Satu pesan SMS dapat mengandung paling banyak 140 byte (1120 bits) data, sehingga satu pesan SMS dapat mengandung:

1. 160 karakter jika encoding 7-bit karakter digunakan. (cocok untuk karakter latin seperti alphabet dalam Bahasa Inggris)

2. 70 karakter jika encoding 16-bit Unicode UCS2 character digunakan. (cocok untuk karakter non-Latin seperti karakter dalam bahasa Cina).

Keuntungan utama dari SMS ini adalah didukung oleh 100% telepon selular. Hampir semua rencana abodemen disediakan oleh layanan selular termasuk layanan pesan SMS yang murah.

Satu kekurangan teknologi SMS adalah satu pesan SMS hanya dapat membawa jumlah data yang sangat terbatas. Untuk mengatasi kelemahan ini, sebuah perluasan dikenal sebagai concatenated SMS (juga dikenal sebagai SMS panjang) dikembangkan. Sebuah concatenated SMS dapat mengandung lebih dari 160 karakter. Cara kerjanya yaitu pengirim pesan memecah pesan panjang menjadi bagian-bagian yang lebih kecil dan mengirim bagian-bagian itu sebagai pesan SMS tunggal. Ketika pesan SMS meraih tujuannya, penerima akan menggabungkan ke satu pesan panjang. Kelemahan dari concatenated SMS ini kurang didukung secara luas oleh kebanyakan perangkat nirkabel.

16

II.6 WAP (Wireless Application Protocol)

Menurut [1], WAP (Wireless Application Protocol) adalah suatu protokol aplikasi yang memungkinkan Internet dapat diakses oleh telepon selular dan perangkat nirkabel lainnya. WAP membawa informasi secara online melewati Internet menuju ke telepon selular atau klien WAP lainnya. Dengan adanya WAP, berbagai informasi dapat diakses setiap saat hanya dengan menggunakan telepon selular.

Ada tiga bagian utama dalam akses WAP, yaitu perangkat nirkabel yang mendukung WAP, WAP Gateway sebagai perantara dan server sebagai sumber dokumen. Dokumen yang berada dalam web server dapat berupa dokumen HTML maupun WML. Dokumen WML khusus ditampilkan melalui browser dari perangkat WAP. Sedangkan dokumen HTML yang seharusnya ditampilkan melalui web browser, sebelum dibaca melalui browser WAP diterjemahkan terlebih dahulu oleh gateway agar dapar menyesuaikan dengan perangkat WAP.

Saat telepon selular ingin meminta sebuah informasi yang ada di server, telepon selular harus melalui WAP Gateway. Proses pengiriman informasi dari telepon selular ke WAP Gateway dan sebaliknya menggunakan jaringan komunikasi nirkabel yang masih memiliki keterbatasan, terutapa pada kecilnya bandwith yang ada. KEcilnya bandwith tersebut tidak cocok jika dipergunakan untuk memproses informasi lewat protokol HTTP. Protokol HTTP berfungsi untuk mengatur pengiriman informasi dari client menuju server dan sebaliknya. Untuk mengatasi kesenjangan ini, diciptakanlah WAP Gateway. Fungsi WAP Gateway adalah untuk meneruskan permintaan informasi dari telepon selular menuju server lewat HTTP request dan sebaliknya dari server menuju telepon selular lewat HTTP response.

17

Gambar II.6 Ilustrasi kerja WAP [1]

Keuntungan WAP:

1. Tidak adanya kepemilikan metode dalam mengakses Internet dengan standar WAP baik pada isi maupun layanan.

2. Jaringan yang independen karena WAP bekerja pada seluruh jaringan selular yang ada, seperti CDPD, CDMA, GSM, PDC, PHS, TDMA, ReFLEX, Iden, TETRA, DECT, DataTAC, MebiTex, dan jaringan selular masa depan yang saat ini sedang dikembangkan seperti GPRS dan 3G.

3. Metode WAP telah diadopsi oleh hamper 95% produsen telepon selular di seluruh dunia dalam memanfaatkan wireless internet access dan sedang diimplementasikan pada semua frekuensi.

4. WAP adalah standar protokol dan aplikasinya, yakni WAP browser yang dapat digunakan pada seluruh sistem operasi terkenal termasuk Palm OS, EPOC, Windows SE, FLEXOS, OS/9, Java OS, dan sebagainya.

5. Dengan menggunakan teknologi GPRS, perhitungan biaya aksesnya berkisar antara Rp.1,1-12 per kilo byte.

Kelemahan WAP:

1. Konfigurasi telepon selular untuk layanan WAP masih termasuk sulit. 2. Jumlah telepon selular yang mendukung WAP masih terhitung sedikit.

18

3. Protokol lain seperti SIM Application Toolkit dan MexE (Mobile Station Application Execution Environment) secara luas didukung dan didisain untuk bersaing dengan WAP.

II.7 Servicing Database

Berdasarkan pengalaman para pengembang aplikasi dan pemahaman kode sumber, jika dilihat secara umum Servicing Database adalah suatu aplikasi yang berguna untuk manajemen jadwal. Kata Servicing yang berarti pelayanan, maksudnya untuk memberikan pelayanan terhadap klien. Aplikasi ini dapat tergolong sebagai CRM (Client Relationship Management) atau Pengelolaan Hubungan dengan Pelanggan, menurut [6] kegiatan ini meliputi Acquire (mendapatkan), Enhance (meningkatkan) dan Retain (mempertahankan) pelanggan. Maksudnya adalah bagaimana dapat memperoleh pelanggan baru, meningkatkan pelayanan dan mempertahankan pelanggan yang sudah ada. Kegiatan CRM dipakai sebagai sarana penghubung dari suatu perusahaan ke pelanggannya. Dalam aplikasi Servicing Database, klien disini yaitu pelanggan yang melakukan investasi ke perusahaan FPI untuk memperoleh layanan finansial.

Para adviser dari berbagai cabang yang ada dalam lingkungan internal perusahaan multinasional Financial Partners International Ltd (FPI) memiliki sejumlah klien dengan total lebih dari 10.000 klien, baik dari negara di dalam maupun di luar cabang internal perusahaan. Klien dengan jumlahnya yang banyak itu perlu diatur pertemuannya untuk memberikan pelayanan yang optimal terhadap kliennya. Istilah pertemuan adviser dengan klien pada Servicing Database sering kali disebut dengan Strategic Review (SR). Adviser melakukan Strategic Review terhadap klien untuk melakukan kajian/evaluasi terhadap laporan bisnis dan investasi yang dilakukan oleh klien.

19

Kelas-kelas pengguna pada Servicing Database pada umumnya sama seperti aplikasi web lain dalam perusahaan ini, yaitu terdiri dari Adviser, Branch dan Central. Adviser hanya dapat melihat data-data kliennya sendiri dan tidak dapat melihat data-data klien pada adviser lainnya. Branch dapat melihat data-data adviser pada suatu branch tertentu jika diberi otoritas terhadap branch mana yang dapat diakses. Central memiliki otoritas paling tinggi diantara Adviser dan Branch karena dipercaya untuk dapat melakukan perawatan terhadap data-data klien dan jadwal yang telah ada.

Tabel II.2 Kelas Pengguna Servicing Database

Hak akses Lihat data klien Lihat data adviser lain Pemeliharaan data klien Adviser klien dari adviser itu

sendiri

Tidak dapat Tidak dapat Branch Semua klien dibawah

bimbingan adviser yang berasal dari branch tertentu

Adviser dari branch yang diberi otoritas

Tidak dapat

Central Semua klien dari semua branch

Adviser dari semua branch

Dapat

Perusahaan multinasional ini terdiri dari cabang: - Hong Kong - China - Malaysia - Indonesia - UAE - Thailand - India

Setelah ditelusuri lebih dalam lagi melalui eksekusi program dan pemahaman kode sumber secara keseluruhan, Servicing Database tidak hanya sekedar untuk pengaturan jadwal saja, tetapi juga untuk manajemen data-data klien yang ada dalam lingkungan internal perusahaan multinasional ini. Klien-klien yang dimiliki di dalam lingkungan internal perusahaan ini dikelompokkan dalam suatu kelas-kelas berdasarkan suatu kriteria tertentu. Adviser itu sendiri sebenarnya adalah klien, hanya

20

saja terdapat karakteristik khusus yang membedakan dengan klien-klien biasa. Pada sistem lama sebelum permintaan perubahan diajukan pada bulan Mei 2007, klien-klien dikelompokkan menjadi enam kategori, yaitu:

1. Local Active: adviser dari klien ini bukan CRM (Client Relationship Manager) dan klien berasal dari negara yang merupakan cabang internal dari perusahaan.

2. Local Passive: adviser dari klien ini adalah CRM (Client Relationship Manager) dan klien berasal dari negara yang bukan cabang internal dari perusahaan.

3. Overseas Active: adviser dari klien ini bukan CRM (Client Relationship Manager) dan klien berasal dari negara yang merupakan cabang internal dari perusahaan.

4. Overseas Passive: adviser dari klien ini adalah CRM (Client Relationship Manager) dan klien berasal dari negara yang bukan cabang internal dari perusahaan.

5. Lost Contact: klien ini kehilangan kontak dengan adviser sehingga pada akhirnya tidak dapat ditemui oleh adviser-nya.

6. Execution Only: klien pada kategori ini biasanya merupakan adviser (adviser dari klien itu adalah klien itu sendiri) atau staf dari Central (adviser dari klien itu adalah Central).

Klien dengan kategori nomor 5 dan 6, biasanya tidak akan memiliki jadwal terhadap advisernya. Kesimpulannya bahwa klien dengan kategori dengan nomor 5 dan 6 tidak akan ditemui oleh adviser. Klien dengan kategori selain 5 dan 6 dapat saja tidak memiliki jadwal atau tidak akan ditemui oleh adviser setelah dilakukan usulan untuk menolak Strategic Review terhadap klien itu, biasa disebut dengan Decline SR atau No SR.

Pada sistem baru saat ini (setelah permintaan perubahan diajukan pada bulan Mei 2007), klien memiliki kategori A, B, C, D, E dan F. Kategori ini ditentukan dari pihak

21

manajemen. Kategori A adalah kategori dengan kelas tertinggi, kategori F adalah kelas terendah.

Client Category pada sistem lama menggunakan kategori seperti Local Active, Local Passive, Overseas Active, Overseas Passive, Lost Contact dan Execution Only. Sedangkan pada sistem baru sekarang ini menggunakan A, B, C, D, E dan F. Client Category pada sistem lama saat ini masih dapat dipakai, hanya pada basis data nama fisiknya berbeda, sedangkan untuk sistem baru nama fisiknya tetap hanya saja nilainya A, B, C, D, E dan F, nilai itu dapat diusulkan perubahannya oleh adviser setelah disetujui oleh General Manager. Adviser melakukan usulan perubahan Client Category terhadap klien setelah melakukan kajian terhadap hasil bisnis yang dilakukan oleh kliennya.