winarto a 2
Post on 09-Jan-2016
219 Views
Preview:
DESCRIPTION
TRANSCRIPT
-
9
BAB II
LANDASAN TEORI
2.1 Service Oriented Architecture
Definisi Service Orientation Architecture (SOA) menurut Open Group
adalah sebuah model arsitektur yang mendukung service orientation (John
Erickson, Keng Siau, 2008). Definisi tersebut terfokus pada model arsitektur,
service orientation, service serta fitur fitur yang menonjol pada SOA.
Organization for Advancement of Structured Information Standards (OASIS)
mendefinisikan SOA sebagai paradigma yang digunakan untuk mengatur dan
memanfaatkan kemampuan terdistribusi yang mungkin berada di bawah
kendali kepemilikan suatu domain yang berbeda (John Erickson, Keng Siau,
2008). Definisi OASIS disebut sebagai reference model yang selanjutnya
diperluas dan diformalkan.
SOA didefinisikan oleh World Wide Web Consortium (W3C) sebagai
suatu bentuk arsitektur sistem terdistribusi yang pada umumnya ditandai
dengan logical view, message orientation, description orientation, granularity
dan platform neutrality (John Erickson, Keng Siau, 2008). XML.com pada
tahun 2007 mendefinisikan SOA sebagai sebuah gaya arsitektur yang
memiliki tujuan untuk mencapai loosely couple antara agen perangkat lunak
yang berinteraksi (John Erickson, Keng Siau, 2008). Service adalah satuan
kerja yang dilakukan oleh penyedia service untuk mencapai hasil akhir yang
-
10
diinginkan kepada consumer service. Empat karakteristik yang dimiliki oleh
SOA berdasarkan Raghu Kodali antara lain :
a. Antarmuka yang disusun dengan XML yang menggunakan WSDL
b. Skema XML yang disebut dengan XSD yang harus digunakan untuk
mengolah pesan
c. Registry UDDI berdasarkan pada penyimpanan daftar service yang
disediakan
d. setiap service harus mempertahankan tingkat kualitas yang ditetapkan
untuk melalui persyaratan keamanan QoS.
IBM mengusulkan bahwa SOA menggambarkan gaya arsitektur yang
memperlakukan komponen perangkat lunak sebagai service set (UNL IBM
system in Global Innovation Hub, 2007). Definisi tersebut ditegaskan sebagai
kebutuhan bisnis yang harus mengendalikan definisi dari service dan nilai
tujuan harus terfokus dengan reusability dan fleksibilitas service yang telah
didefinisikan (John Erickson, Keng Siau, 2008).
2.2 Prinsip Prinsip Service Orientation
Pendekatan Service Oriented Architecture (SOA) tidak memiliki prinsip
prinsip yang baku digunakan untuk pengembangan SOA tersebut. Beberapa
prinsip yang seringkali digunakan terkait dengan pendekatan SOA terdapat
pada pembahasan di bawah ini (Thomas Erl, 2008, p290-310):
i. Prinsip 1 : Service dapat digunakan kembali (Reusability)
-
11
Pengembangan sistem yang menggunakan pendekatan SOA, service
dirancang secara khusus untuk mendukung penggunaan kembali sesuai
dengan kebutuhannya.
ii. Prinsip 2 : Service merupakan formal specifation
Service tidak membutuhkan suatu pembagian apa pun di dalam
pengembangan yang menggunakan pendekatan SOA untuk dapat
berinteraksi dengan service. Service membutuhkan sebuah kontrak yang
formal yang dapat mendeskripsikan setiap service yang telah ada dan
menentukan persyaratan yang dibutuhkan pada pertukaran informasi yang
terjadi.
iii. Prinsip 3 : Service merupakan loosely couple
Service secara khusus pada pendekatan SOA dirancang untuk dapat
berkomunikasi dengan antar service tanpa perlu saling ketergantungan.
iv. Prinsip 4 : Inti sari service berdasarkan logika
Satu satunya bagian dari service yang terlihat di dunia luar pada
penerapan pendekatan SOA merupakan hal hal yang ditampilkan
melalui kontrak service tersebut. Logika dasar yang melampui hal tersebut
dinyatakan ke dalam deskripsi yang terdiri dari kontrak yang tidak nyata
dan tidak relevan dengan permintaan dari service tersebut.
-
12
v. Prinsip 5 : Decomposition Service
Penggunaan SOA menyebabkan service dapat menyusun service yang
lain. Hal ini memungkinkan logika yang dapat digambarkan pada tingkat
granularity yang berbeda dan mempromosikan penggunaannya kembali
serta penyusunan dari inti sari yang berada pada layer.
vi. Prinsip 6 : Service bersifat otonomi
Logika yang menggunakan pendekatan SOA dipengaruhi oleh sebuah
service yang diletakan pada sebuah batasan yang tidak dapat dilihat.
Service tersebut akan mengontrol batas tersebut dan untuk
mengeksekusinya tidak perlu bergantung dengan service lain.
vii. Prinsip 7 : Service bersifat stateless
Service yang berbasiskan SOA tidak harus membutuhkan pengaturan
informasi state. Hal ini dikarenakan state tersebut dapat menghalangi
kemampuan service untuk bergabung atau berintegrasi.
viii. Prinsip 8 : Service tidak terdeteksi
Service yang dirancang harus dapat memungkinkan deskripsi
mengenai diri service sendiri di dalam sistem yang telah menerapkan SOA
untuk dapat menemukan servicenya tersebut dan dapat dimengerti oleh
-
13
manusia dan pemohon service tersebut yang dapat menggunakan logika
dalam service tersebut.
2.3 Service Oriented Modeling and Architecture (SOMA)
Sebagai metode pengembangan perangkat lunak lifecycle untuk
mengembangkan solusi berbasis SOA, atau solusi dengan menggunakan prinsip
berorientasi layanan, SOMA mendefinisikan teknik kunci dan menjelaskan peran
pada sebuah proyek SOA dan Work Breakdown Structure (WBS). SOMA sendiri
dikemukakan oleh IBM (IBM Global Services, 2004, p2-3). WBS meliputi tugas,
input dan hasil output, serta prescriptive guidance yang diperlukan untuk rincian
analisis, desain, implementasi, dan deployment of services, komponen, dan flow yang
dibutuhkan untuk membangun lingkungan SOA kuat dan dapat digunakan kembali.
Metode SOA dalam SOMA meliputi tujuh fase utama ditunjukkan pada Gambar 2.1.
Fractal phases menjelaskan kapabilitas yang dapat disesuaikan dengan kebutuhan
dalam berbagai situasi. SOMA mengaplikasikan metode komponen dengan cara
rekursif kepada dirinya sendiri dalam rilis kecil atau siklus iterasi, dan juga fokus
pada pengelolaan resiko teknis dan menghasilkan perangkat lunak yang berguna
secara bisnis.) Realisasinya, sebagai contoh pengembangan semua tahap. Tidak ada
urutan yang baku. Dalam fractal model, fase akan terdiri dari kapabilitas yang
mungkin dipergunakan oleh fase lainnya. SOMA memberikan dukungan dan
hubungan terhadap dua aspek utama pengelolaan: desain-waktu dan tata olah
runtime.
-
14
2.4 Fractal Model untuk Pengembangan Perangkat Lunak
SOMA terdiri dari beberapa pola yang mewakili kemampuan teknik untuk
diterapkan ke dalam metode. Setiap isi pola dijalankan atau diterapkan ke dalam
semua tahap dalam SOMA dengan tingkat elaborasi dan presisi yang berbeda.
Sebagai salah satu contoh, dengan membuat paparan keputusan berdasarkan pada
informasi yang kita tahu tentang services selama identifikasi dan kemudian kita
gabungkan dan sempurnakan paparan keputusan di fase spesifikasi ketika kita tahu
lebih banyak tentang persyaratan nonfunctional dari services. Contoh kedua adalah
dengan menganalisa aset yang ada ke dalam fase identifikasi untuk mengidentifikasi
sistem serta fungsi sistem yang dapat dimanfaatkan dalam pemberntukan services,
serta diperluas lebih lanjut mengenai analisis dalam fase spesifikasi untuk
mengidentifikasi komponen-komponen yang ada dan objek dan operasi yang dapat
dipergunakan kembali untuk mewujudkan services. Dan sebagai contoh ketiga, model
dibuat berdasarkan dependensi antar services yang didefinisikan ke dalam portofolio
services dimana selanjutnya dependensi antar services dengan komponen dan fisik
sistem diuraikan dan diidentifikasi untuk mewujudkan services.
-
15
Gambar 2.1 Fractral Model Development Software (A. Arsanjani, 2008, p382)
Prinsip dari pengembangan perangkat lunak fraktal adalah iterasi berturut-
turut. Konsep siklus pengembangan iteratif dan incremental kehidupan telah ada
untuk waktu yang lama. Fokus pada prioritas dan mitigation faktor risiko dalam
rangka menjamin kualitas produk dari solusi. Ini berakar dalam model spiral
pengembangan perangkat lunak oleh Boehm. Iterasi yang berurutan dihubungkan
dengan gagasan evolusi services dan menyiratkan fokus tidak hanya pada risiko yang
terkait dengan implementasi, tetapi juga dengan dependensi yang terkait dengan
portofolio services sebagai evolusi services dalam lifecycle.
2.5 SOMA Lifecycle
-
16
Siklus SOMA mengilustrasikan urutan proses dalam pelaksanaan metode
SOMA dengan business proses yang ada.
Gambar 2.2 SOMA Lifecycle (A. Arsanjani, 2008, p383)
2.5.1 SOMA Step 1 : Business Modeling dan Transformasi
Tahapan pertama dari metodologi SOMA ini, kondisi proses bisnis sekarang
dimodelkan, simulasi, dan dioptimalkan, dan area fokus transformasi diidentifikasi
yang akan mendorong serangkaian proyek selanjutnya menggunakan serangkaian
tahapan yang ditunjukkan pada Gambar 2.2 dimana hasilnya akan membentuk proses
bisnis baru yang merupakan hasil dari Business Process Reengineering.
Menurut Michael R dan Boris L (Applied SOA) Business process modeling
dapat dilakukan dengan penggunaan Value Chain, process diagram dan use case
diagram. Pembahasan Teori mengenai Value Chain, process diagram dan use case
-
17
terdapat pada sub bab ini. Untuk pemilihan prioritas dari business component, IBM
(2005) merekomendasikan dapat menggunakan Component Business Model yang
dijelaskan pada sub bab 2.5.1.1.
2.5.1.1 Component Business Model
Komponen model bisnis menawarkan pendekatan yang terbukti
mengarahkan secara fokus baik secara internal maupun eksternal. Secara
internal, komponen membantu perusahaan-perusahaan memikirkan kembali
pengaruh yang dapat terjadi dengan aset dan kapabilitasnya sendiri. Secara
eksternal, komponen membantu perusahaan untuk mendokumentasikan
kapabilitas secara spesifik dimana tidak dapat terbentuk dengan sendirinya.
Ini adalah komponen industri tertentu dimana perusahaan tidak dapat
menciptakan sendiri (Misalnya perusahaan dapat membuatnya dengan
bantuan perusahaan eksternal atau organisasi publik). Menggabungkan jenis
spesialisasi memungkinkan perusahaan untuk mendefinisikan kembali posisi
kompetitif mereka dalam menghadapi perubahan besar dalam industrinya,
sementara secara bersamaan mendapatkan keuntungan persaingan secara
skala, fleksibilitas dan efisiensi. CBM memungkinkan perusahaan untuk
mengevaluasi tujuan dan strategi perusahaan untuk mengambil keuntungan
secara simultan dari internal dan eksternal spesialisasi. Tanpa meningkatnya
kompleksitas, model ini memungkinkan organisasi untuk memperluas dan
berkembang sekaligus mengurangi risiko, mendorong kinerja bisnis,
-
18
meningkatkan produktivitas, mengendalikan biaya dan meningkatkan efisiensi
modal dan prediktabilitas keuangan.
Gambar 2.3 Component Business Diagram (George Pohle, 2005, p7)
2.5.1.2 Use Case Diagram
Menurut Whitten et al. (2004, p271), use case diagram adalah diagram
yang menggambarkan interaksi antara system, external system dan user.
Dengan kata lain, digram ini menjelaskan siapa yang akan menggunakan
sistem tersebut dan bagaimana cara user tersebut berinteraksi dengan sistem.
Gambar 2.4 Use Case Diagram (Joseph Schmuller, 1999, p385)
2.5.1.3 Value Chain
-
19
Menurut Michael, R. (2008, p125), value chain pertama kali
dipopulerkan oleh Michael Porter dan diagram ini biasanya digunakan untuk
menggambarkan proses bisnis utama dari suatu organisasi dan manajemen
bisnis perusahaan yang terbagi menjadi dua bagian yaitu aktivitas utama dan
aktivitas pendukung.
Gambar 2.5 Porters Diagram of Value Chain (Michael, R., 2008, p125)
2.5.1.4 Process Diagram
Process Diagram digunakan untuk menggambarkan satu tingkat lebih
detail dari proses bisnis utama dimana user dan proses dibuat detail untuk satu
alur proses pekerjaan dan kemungkinan yang dapat terjadi. Skenario yang
terjadi tersebut yang menggambarkan satuan proses bisnis dari suatu bagian
kegiatan. Contoh process diagram yaitu sebagai berikut :
-
20
Gambar 2.6 Process Diagram (R. Mike, 2008, p510)
2.5.2 SOMA Step 2 : Manajemen Solusi
Tahapan kedua dari metodologi SOMA ini, solusi SOA biasanya mencakup
beberapa jenis solusi di dalamnya. Hal ini karenakan services diidentifikasi dan
ditetapkan selama fase awal SOMA yang dapat direalisasikan dalam fase berikutnya
SOMA dalam skenario yang berbeda, seperti pengembangan secara kustomisasi,
legacy integration dan transformasi, serta integrasi paket aplikasi.
SOMA dirancang untuk mendukung solusi SOA dalam mengatur kegiatan
dan bimbingan yang khusus untuk implementasi setiap jenis solusi di atas. Dalam
metode SOMA, berisi metode umum untuk semua jenis solusi SOA yang dipisahkan
dari konten metode variabel dimana bergantung pada jenis solusi yang spesifik.
Metode variabel konten yang spesifik untuk masing-masing jenis didefinisikan dan
externalized sebagai template metode yang disebut solution template. Pada saat
-
21
realisasi keputusan untuk pembuatan services biasanya menemukan pilihan jenis
solusi yang dibutuhkan untuk membangun solusi SOA bagi klien. Kegiatan dan tugas
dari solution template yang terpilih dimasukkan ke dalam poin ekstensi standar pada
metode SOMA untuk menyediakan suatu proses yang komprehensif untuk proses
pengabungan dan realisasi. Secara keseluruhan tahapan kedua ini terdiri dari tiga
bagian yaitu pembentukan project management activities, pemilihan solution
template, dan diskusi pemilihan metode untuk dipergunakan.
2.5.3 SOMA Step 3 : Identifikasi
Tahapan ketiga dari metodologi SOMA ini, berkaitan dengan identifikasi dari
tiga fundamental dasar SOA: services, components, dan flows. Praktek terbaiknya
adalah dengan menggunakan seperangkat teknik identifikasi services yang saling
melengkapi. Mengandalkan suatu teknik tertentu cenderung menghasilkan
serangkaian services yang tidak lengkap. Informasi diawal sangat penting dalam
pengembangan lifecycle, sering kali menjadi solusi atas pembiayaan yang lebih besar
pada service lifecycle nanti dimana juga memerlukan upaya yang lebih besar pada
service refactoring. Selain itu, ini sering mengarah kepada kegagalan dalam
mengidentifikasi dependensi antar servis diawal, yang berdampak pada perencanaan
realisasi dan penyelesaian proyek.
Rekomendasinya adalah dengan mulai dari penyelarasan services dengan
tujuan bisnis, yang disebut dengan Goal Service Modeling (GSM). Hal ini sejalan
antara eksekusi IT dengan business drivers, imperatif, dan tujuan yang sama halnya
-
22
dengan pemantauan dan pengelolaan ruang lingkup pemodelan proses bisnis lebih
lanjut dan analisis aset.
Tahap identifikasi SOMA adalah proses identifikasi calon services dan
menciptakan portofolio services bisnis-blok services TI yang secara kolektif
mendukung proses bisnis dan tujuan organisasi. Hal ini dilakukan melalui proses
penilaian fungsi yang ada untuk melihat apakah dapat ditempatkan dalam pemodelan
services, dan dengan menentukan kapabilitas IT yang hilang dimana akan diperlukan
untuk mendukung penyelarasan strategi bisnis, tujuan, dan proses.
Gambar 2.7 Goal Service Modelling (A. Arsanjani, 2008, p386)
2.5.4 SOMA Step 4 : Spesifikasi
Tahapan keempat dari metodologi SOMA ini, SOA dirancang. Rancangan
tingkat tinggi sama halnya dengan bagian-bagian penting dari rincian desain
komponen service diselesaikan dalam fase ini. Selama fase spesifikasi, pemanfaatkan
aset yang ada dan penggabungan services, flows, dan komponen dari tahap
identifikasi secara iteratif dan inkremental untuk membantu pencapaian realisasi
-
23
keputusan. Model services akan dibahas lebih lanjut dalam hal dependensi antara
services, flows dan komposisi, event, peraturan dan kebijakan, operations, dan pesan.
Dalam melakukan spesifikasi, diperlukan fokus pada desain pesan services
yang meliputi input, output, dan pesan kesalahan. Untuk menghilangkan beberapa
transformasi data pada lapisan services, praktik terbaiknya adalah dengan
menggunakan model pesan umum yang disetujui semua pihak. Model ini
mendefinisikan aliran pesan dalam lapisan services. Dalam canonical message model,
pemilihan format pesan (misalnya, Extensible Markup Language atau record fixed-
length) dan pendefinisian set tipe, elemen, dan atribut yang mewakili entitas bisnis
dan atribut bisnis masing masing pesan. Jenis pesan yang digunakan sebagai
pembatas untuk input, output, dan pesan kesalahan untuk services. Spesifikasi model
services dan analisa subsystem secara sederhana dibentuk ke dalam Domain Model.
Refactoring dari aset dan kode yang ada sebagai persiapan untuk membuat
keputusan tentang bagaimana realisasi services yang diberikan harus dengan
pemikiran yang cermat dan matang. Analisis antarmuka sistem dan parameter
masukan dan keluaran dari sistem yang ada serta pemetaan yang baik dan terarah
pada services untuk transaksi aplikasi tertentu atau proses batch. Pemetaan
menyimpulkan suatu rangkaian potensi realisasi keputusan untuk SOA tersebut.
Pemanfaatan aset yang ada melalui refactoring dan pemetaan ke services adalah
aspek kunci dari orientasi services. Sebagai contoh, diperlukan identifikasi duplikasi
kode, kode yang tidak terstruktur, dan kode yang tidak terpakai sebelum
-
24
dirasionalisasi dan enkapsulasi fungsionalitas yang terpapar sebagai services bersama
antar channels.
Gambar 2.8 Domain Model (Craig Larman, 2002, p129)
2.5.5 SOMA Step 5 : Realisasi
Tahapan kelima dari metodologi SOMA ini memerlukan validasi keputusan
realisasi dengan mengeksplorasi kelayakan teknis yang bertujuan untuk
melaksanakan keputusan arsitektur dan faktor risiko tertinggi proyek melalui
prototipe extensible yang dirancang dan dikembangkan sebelumnya. Selection awal
dikembangkan dan instantiation pola merupakan dasar untuk realisasi SOA yang
berhasil dan berulang. Pemilihan kategori pola yang sesuai untuk menangani
beberapa masalah domain termasuk pola pelayanan informasi untuk realisasi
-
25
informasi, Enterprise Service Bus (ESB) pola untuk skenario integrasi, dan pola
aturan untuk realisasi aturan. Tahapan pengambilan keputusan dan proses percobaan
dapat disederhanakan ke dalam tahapan prototyping, di samping itu detail layer SOA
tergambarkan lewat SOA Reference Architecture.
2.5.6 SOMA Step 6 : Implementasi
Tahapan keenam dari metodologi SOMA ini, mulai dilakukan pembentukan
servis servis yang sudah didefine sebelumnya dan semua servis dinaikkan ke tahap
testing dimana unit test yang bertugas seperti Quality Control / Quality Assurance
dan Developer melakukan testing terhadap servis yang ada. Tidak dilupakan untuk
testing sistem integrasi dengan pihak luar jika ada dan sistem secara keseluruhan
dapat dipastikan berjalan lancar dimana dapat digabungkan dalam tahapan Unit
Testing.
2.5.7 SOMA Step 7 : Deployment, Monitoring dan Management
Tahapan ketujuh dari metodologi SOMA ini, mulai dilakukan deployment
terhadap semua services ke tingkat production setelah dilakukan application
acceptance test dimana user melakukan testing secara keseluruhan dan memberikan
tanda bahwa proses sistem berjalan benar. Setelah deployment services, perlu
dilakukan monitoring akan proses dan perfoma stabilitas sistem.
2.6 Web Services
-
26
Web Service merupakan sebuah sistem perangkat lunak yang didesain untuk
mendukung interaksi operasi mesin-ke-mesin melalui jaringan. Memiliki antarmuka
yang dijelaskan dalam format mesin yang dapat diproses (Web Services Description
Language / WSDL). Sistem lain berinteraksi dengan web service dengan cara yang
ditentukan oleh deskripsi menggunakan pesan SOAP, biasanya disampaikan
menggunakan HTTP dengan serialisasi XML dalam hubungannya dengan standar
Web-terkait lainnya. Web Service biasanya menggunakan Extensible Markup
Language (XML) pesan yang mengikuti standar SOAP dan telah populer dengan
perusahaan tradisional. Dalam sistem seperti itu, sering kali ada deskripsi dapat
dibaca oleh mesin operasi yang ditawarkan oleh layanan ditulis dalam Web Services
Description Language (WSDL)
2.7 Penggunaan Service Berulang
Penggunaan Berulang merupakan salah satu keuntungan SOA dimana
perusahaan dapat menekan biaya yang tidak diperlukan. Penggunaan kembali pola
teknik bisa digunakan untuk model driven architecture (MDA), model-driven design
(MDD) dan penggunaan dalam dekomposisi model industri.Arsitek akan membentuk
business services baru dan melakukan peningkatan pada business services yang ada
dengan penggunaan kembali model dan pola yang sudah ada. Pendekatan lainnya
disebut "aset analisis yang sudah ada" Analisis aset merupakan suatu pendekatan
yang digunakan untuk memeriksa aset seperti aplikasi warisan yang ada dan
menentukan leverage untuk mewujudkan fungsi layanan. Ketika transisi ke SOA,
-
27
khususnya, ada empat area sistem warisan untuk mempertimbangkan menggunakan
kembali dan mengubah yang logika fungsional itu sendiri, aturan bisnis legacy dalam
logika fungsional, alur kerja fungsi, dan data antarmuka. Dengan bermigrasi aset
warisan ke layanan reuseable, itu akan mengendalikan jumlah besar waktu, tenaga
dan biaya yang telah diinvestasikan oleh perusahaan menjadi sesuatu yang reuseable
sekarang dan ke masa depan
2.8 Customer Service
Customer Service adalah suatu rangakain kegiatan yang dirancang untuk
meningkatkan nilai kepuasan pelanggan yang meliputi tingkat kepercayaan dan
informatif. Dari sudut pandang bisnis, Customer Service memberikan pengaruh yang
cukup penting dalam meningkatkan pendapatan dari suatu perusahaan atas barang
atau jasa yang dijual kepada konsumen.
2.9 Insurance
Asuransi adalah suatu istilah yang digunakan untuk menggambarkan suatu bisnis
perlindungan keuangan yang meliputi Jiwa, Property, Kesehatan, dan lain
sebagainya. Bentuk perlindungan yang ditawarkan meliputi jaminan ganti rugi atas
segala jenis kejadian seperti kematian, kehilangan, kerusakan, sakit dan lain
sebagainya dengan syarat adanya jaminan pembayaran premi secara berkala yang
dilakukan oleh tertanggung kepada pihak penanggung.
-
28
2.10 Life Insurance
Asuransi jiwa atau yang biasa disebut juga dengan polis asuransi jiwa, adalah
sebuah bentuk bisnis dimana perusahaan asuransi / penanggung wajib untuk
membayar manfaat atas kematian orang yang diasuransikan / tertanggung. Asuransi
Jiwa diberikan untuk perorangan maupun kumpulan dan diberikan daman bentuk
polis. Asuransi Jiwa terbagi ke dalam 3 jenis :
a. Asuransi Jiwa Berjangka
Asuransi Jiwa Berjangka memberikan manfaat kematian jika tertanggung
meninggal dalam suatu jangka waktu tertentu.
b. Asuransi Jiwa Tetap (Seumur Hidup)
Asuransi Jiwa Tetap memberikan pertanggungan asuransi jiwa seumur hidup
bagi tertanggung dan juga memiliki unsur tabungan. Sejalan dengan premi
yang dibayarkan untuk polis ini, maka jumlah tabungan terakumulasi
disebut nilai tunai polis yang terkumpul secara bertahap.
c. Asuransi Jiwa Dwiguna
Asuransi jiwa Dwiguna memberikan mafaat polis yang dibayar pada saat
tertanggung meninggal atau pada tanggal yang ditentukan jika tertanggung
masih hidup sampai dengan tanggal tersebut.
top related