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.