7 BAB 2
TINJAUAN PUSTAKA
2.1 Unified Modelling Language (UML)
Unified Modelling Language (UML) ditetapkan sebagai standar utama bahasa pemodelan dalam bidang object-oriented software engineering. Standar ini dibuat dan dikelola oleh Object Management Group (OMG). UML pertama kali dimasukkan ke daftar OMG pada tahun 1997, dan sejak itu menjadi standar industri untuk pemodelan sistem software. UML mencakup seperangkat teknik notasi grafis untuk menciptakan model visual dari sistem software berorientasi objek (Lee, 2012, pp. 159).
Dengan menggunakan UML, developer dapat membuat model untuk semua jenis aplikasi software, di mana aplikasi tersebut dapat berjalan pada hardware, sistem operasi dan jaringan apapun serta ditulis dalam bahasa pemrograman apapun. Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan syntax. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram software, di mana setiap bentuk memiliki makna tertentu. Sementara itu, UML syntax mendefinisikan bagaimana bentuk-bentuk dalam suatu diagram UML dapat dikombinasikan. Notasi UML sebagian besar diturunkan dari tiga notasi yang telah ada sebelumnya, yaitu Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering) (Connolly dan Begg, 2005, pp. 343).
1.1.1. Use Case Diagram
Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan dalam use case diagram adalah ‘Apa’ yang dilakukan oleh sistem, dan bukan ‘Bagaimana’. Use case diagram mempresentasikan sebuah interaksi antara aktor dengan sistem. Use case diagram merepresentasikan sebuah proses tertentu seperti login ke sistem, membuat sebuah draft, dan sebagainya. Aktor dalam use case diagram merupakan sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu (Booch, dkk, 2005, pp. 119, 283).
Use case diagram sangat membantu dalam menyusun requirement sebuah sistem, mengkomunikasikan rancangan kepada client, dan merancang test case untuk sebuah sistem.
Gambar 2.1 Use Case Diagram (Connolly dan Begg, 2005, pp. 840)
Pada umumnya, use case diagram dilengkapi dengan adanya use case narrative. Tujuan dari penggunaan use case narrative adalah untuk menceritakan bagaimana sistem dan aktor bekerja bersama untuk mencapai tujuan tertentu. Use case narrative dapat dikembangkan pada berbagai tingkat detail mulai dari rancangan yang sederhana, mengidentifikasi flow dasar dan varian yang paling penting melalui spesifikasi yang sangat rinci dan komprehensif yang mendefinisikan semua action, input dan output yang terlibat dalam melakukan use case (Jacobson, dkk, 2011, pp. 47).
1.1.2. Activity Diagram
Activity diagram menggambarkan alur atau jalan suatu aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alur berawal, decision yang mungkin terjadi, dan bagaimana aktivitas berakhir. Activity diagram dapat pula menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi (Booch, dkk, 2005, pp. 120, 311).
Activity diagram merupakan varian khusus dari state diagram, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya. Oleh karena itu, activity diagram tidak menggambarkan behavior internal sebuah sistem secara eksak, tetapi lebih menggambarkan proses-proses dan alur-alur aktivitas dari level atas secara umum. Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Activity diagram menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas.
Sama seperti state diagram, standar UML menggunakan segi empat dengan sudut membulat untuk menggambarkan suatu aktivitas. Decision symbol digunakan untuk menggambarkan behavior pada kondisi tertentu. Untuk mengilustrasikan proses-proses paralel, digunakan titik sinkronisasi berupa titik, garis horizontal atau garis vertikal. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.
Gambar 2.3 Activity diagram dengan swimlane (Booch, dkk, 2005, pp. 320)
2.2 Data Flow Diagram (DFD)
Data Flow Diagram merupakan alat pemodelan yang memungkinkan developer untuk menggambarkan sebuah sistem sebagai jaringan proses fungsional yang terhubung satu sama lain dengan ‘pipeline’. Data Flow Diagram adalah salah satu alat pemodelan sistem yang paling umum dan paling banyak digunakan untuk menggambarkan sistem operasional, di mana fungsi sistem menjadi bagian yang penting dan lebih kompleks daripada data yang dimanipulasi oleh sistem (Yourdon, 2006, pp. 147).
Gambar 2.4 Data Flow Diagram (Yourdon, 2006, pp. 171)
Berikut ini merupakan beberapa istilah yang digunakan dalam DFD: − Process ditunjukkan dengan lingkaran di dalam diagram. Process
mewakili berbagai fungsi individual yang dimiliki sistem. Fungsi-fungsi ini mengubah input menjadi output.
− Flows digambarkan dengan garis melengkung dengan arah panah. Flows melambangkan hubungan antar proses di dalam DFD dan menggambarkan informasi sebagai input maupun output dari sistem. − Data Stores digambarkan dengan dua garis paralel atau bentuk elips.
Data stores menunjukkan kumpulan data yang harus diingat oleh sistem untuk jangka waktu tertentu.
− Terminator, yang menunjukkan entitas eksternal yang dapat berkomunikasi dengan sistem.
2.3 Entity Relationship Diagram (ERD)
Entity Relationship Diagram (ERD) merupakan diagram yang digunakan untuk memodelkan data dalam suatu organisasi. ERD biasanya dirancang oleh system analyst dalam tahap analisis requirement pengembangan sistem (Yourdon, 2006, pp. 243).
Komponen Entity Relationship Diagram:
− Entities, biasanya dituliskan dengan kata benda tunggal dan digambarkan dengan persegi panjang. Entities terdiri dari beberapa atribut, di mana pada setiap entities umumnya terdapat satu atribut unik yang biasa disebut primary key.
− Relationship, merupakan hubungan di antara beberapa entitas dan digambarkan dengan garis lurus yang menghubungkan antar entitas. − Attributes, yang berfungsi untuk mendeskripsikan karakteristik dari
entitas.
Gambar 2.5 Entity Relationship Diagram (Whitten dan Bentley, 2007, pp. 163)
2.4 Systems Development Life Cycle (SDLC)
Untuk mengelola suatu proyek dengan berbagai tahapan analisis, desain, dan kegiatan pengembangan lainnya, diperlukan sebuah project management framework untuk mengarahkan dan mengkoordinasikan pekerjaan di dalam tim. Systems Development Life Cycle merupakan keseluruhan kegiatan yang dilakukan untuk membangun, meluncurkan, dan memelihara suatu sistem informasi. Pada umumnya SDLC mencakup semua aktivitas atau kegiatan yang merupakan bagian dari analisis sistem, desain sistem, pemrograman, pengujian, dan pemeliharaan sistem serta proses manajemen project lainnya yang diperlukan untuk dapat menghasilkan sistem informasi baru (Satzinger, Jackson, dan Burd, 2012, pp. 5).
Terdapat enam proses utama yang diperlukan dalam mengembangkan aplikasi baru, yaitu:
• Mengidentifikasi masalah atau kebutuhan dan mendapatkan persetujuan untuk memproses permasalahan yang ada.
• Merencanakan dan memantau project, kegiatan-kegiatan yang harus dilakukan, cara pelaksanaannya, dan siapa yang melaksanakannya.
• Menemukan dan memahami rincian permasalahan dan kebutuhan sistem. • Mendesain komponen sistem yang dapat menyelesaikan masalah atau
memenuhi kebutuhan.
• Mengembangkan, menguji, dan mengintegrasikan komponen sistem.
• Menguji sistem yang sudah dibuat dan mendistribusikan sistem yang dihasilkan.
Ada banyak cara untuk mengimplementasikan enam proses utama dari SDLC ini. Information systems development process merupakan pendekatan aktual yang digunakan untuk mengembangkan sistem informasi tertentu. Kebanyakan sistem informasi yang akan dikembangkan dibangun untuk memecahkan masalah organisasi yang biasanya sangat kompleks sehingga sulit untuk dilakukan perencanaan dan melaksanakan pengembangan project (Satzinger, Jackson, dan Burd, 2012, pp. 6).
2.4.1 Agile Software Development
Software development merupakan suatu cara yang terorganisasi untuk memberikan/membawakan atau menyampaikan produk dengan cara yang lebih cepat, lebih baik dan lebih murah. Terdapat banyak penelitian dan saran dalam meningkatkan proses pengembangan. Baru-baru ini muncul metode pengembangan perangkat lunak baru yang disebut Agile Software Development. Metode Agile sendiri berfokus pada solusi pengembangan yang cepat dan efisien (Rao, dkk, 2011, pp. 35).
Pendekatan Agile dimaksudkan untuk menghasilkan sistem software yang lebih cepat sekaligus mengantisipasi dan menerima perubahan-perubahan dalam kebutuhan user. Oleh karena itu, dapat dimengerti jika persyaratan seperti waktu yang dibutuhkan oleh penyelesaian projek, kompleksitas dan stabilitas muncul sebagai kebanyakan faktor yang berpengaruh dalam organisasi dalam memutuskan untuk menggunakan pendekatan agile (Vijayasarathy dan Turk, 2008, pp. 4).
2.4.1.1 Definisi Agile Software Development
Agile Software Development merupakan pendekatan yang relatif baru dalam pengembangan perangkat lunak. Definisi Agile Development bervariasi dari satu sumber dengan lain sumber lainnya. Beberapa sumber mendefinisikan Agile Development sebagai: “Pendekatan iteratif dan inkremental untuk software development yang dilakukan dengan cara yang sangat kolaboratif oleh tim yang dapat mengatur dirinya sendiri dalam sebuah framework yang efektif yang menghasilkan software dengan kualitas tinggi dengan efektif dan tepat waktu yang mampu memenuhi perubahan kebutuhan stakeholders (Hajjdiab dan Taleb, 2011, pp. 1).
Agile development methods terdefinisi dalam empat nilai, yang disebut Agile Manifesto, yaitu:
• Interaksi dan personel lebih penting daripada proses dan alat. Artinya, dalam metode agile, interaksi antar personel sangatlah penting, karena tanpa interaksi yang baik proses development tidak dapat berjalan dengan baik.
• Software yang berfungsi lebih penting daripada dokumentasi yang lengkap. Artinya, pada saat melakukan demonstrasi kepada klien atau user, software yang berjalan dengan baik akan lebih berguna daripada dokumentasi yang lengkap namun software tidak berjalan dengan baik. • Kolaborasi dengan klien lebih baik daripada negosiasi kontrak, karena
software yang dikembangkan didasarkan pada kebutuhan user.
• Respon terhadap perubahan lebih penting daripada perencanaan, karena metode agile lebih berfokus kepada respon tim ketika klien ingin melakukan perubahan saat proses development.
Terdapat beberapa model-model Agile Method, di antaranya: − Extreme Programming (XP)
− Adaptive Software Development (ASD)
− Dynamic Systems Development Method (DSDM) − Scrum Methodology
− Crystal
− Feature Driven Development (FDD) − Agile Modeling (AM)
− Rational Unified Process 2.4.1.2 Scrum
Scrum menggunakan pendekatan iteratif yang membutuhkan waktu komunikasi dan kerjasama dari semua pihak dan anggota tim projek. Scrum merupakan metode ringan yang digunakan dalam pengembangan perangkat lunak. Scrum menekankan pentingnya meeting antara anggota tim dan stakeholders untuk membahas kemajuan proses pengembangan suatu software dan langkah-langkah selanjutnya yang perlu dilakukan (Thakur dan Kaur, 2013, pp. 89).
Terdapat tiga peran penting yang membantu proses scrum berjalan dengan baik, yaitu:
− Product Owner, yakni pihak yang bertanggung jawab untuk mengelola product backlog, mewakili bisnis, klien atau user, dan mengarahkan tim dalam melakukan pengembangan produk yang benar.
− Scrum Master, yang dapat dianggap sebagai pemimpin tim dan berperan membantu anggota tim dalam melaksanakan proses scrum dengan lebih baik lagi.
− Development Team, merupakan para ahli yang melakukan pengembangan software. Development team dapat mengatur dan mengelola pekerjaannya secara mandiri (Deemer, dkk., 2012, pp. 3-4).
Aktivitas-aktivitas yang dilakukan dalam metode scrum terdiri dari: − Product Backlog, merupakan inti dari scrum, yang pada dasarnya
merupakan daftar prioritas kebutuhan atau fitur yang akan dikembangkan.
− Sprint Planning, merupakan pertemuan awal berkaitan dengan pengembangan yang akan dilakukan. Jika sprint planning dilakukan dengan tidak baik, maka keseluruhan sprint menjadi kacau.
− Sprint, merupakan pekerjaan yang diperlukan untuk memenuhi kebutuhan yang ditetapkan dalam backlog sesuai dengan batas waktu yang ditetapkan.
− Daily Scrum merupakan pertemuan singkat yang dilakukan agar development team dapat mensinkronisasikan pekerjaan yang mereka
lakukan dengan kebutuhan user dan membuat perencanaan untuk dua puluh empat jam kedepan.
− Sprint Demo merupakan kegiatan yang dilakukan untuk mendemonstrasikan software yang telah dikembangkan.
− Sprint Retrospective merupakan sebuah kesempatan bagi tim scrum untuk melakukan evaluasi dan membuat perencanaan mengenai peningkatan yang akan dilakukan pada sprint berikutnya (Deemer, dkk., 2012, pp. 5-14).
2.5 Software Testing Techniques
Software testing merupakan teknik yang sering digunakan untuk memverifikasi dan memvalidasi kualitas software dikembangkan dengan tujuan untuk menemukan errors. Software testing techniques dibagi menjadi black box testing dan white box testing. Black box testing disebut juga functional testing, di mana test case didasarkan pada informasi dan spesifikasi. Sementara itu, white box testing disebut juga structural testing atau glass box testing, yang merancang test case berdasarkan informasi yang diperoleh dari source code (Nidhra dan Dondeti, 2012:29).
White box dan black box testing dianggap saling melengkapi satu sama lain. Software testing terlibat dalam setiap tahap siklus hidup software, tetapi cara pengujian yang dilakukan pada setiap tahap dalam software development berbeda dan memiliki tujuan yang berbeda.
Tabel 2.1 Berbagai jenis software testing (Nidhra dan Dondeti, 2012:30). Testing
Type Opacity Specification
Who will do this testing? General Scope Unit White Box Testing Low-Level Design Actual Code structure Generally Programmers who write code they test For small unit of code generally no larger than a class Integration White & Black Box Testing
Low and High Level Design Generally Programmers who write code they For multiple classes
test Functional Black Box Testing High Level Design Independent Testers will Test For entire product System Black Box Testing Requirements Analysis Phase Independent Testers will Test For entire product in representative environment Acceptance Black Box Testing Requirements Analysis Phase Customer Side Entire product in customer’s environment Beta Black Box Testing Client Adhoc Request Customer Side Entire product in customer’s environment Regression White & Black Box Testing Changed Documentation High-Level Design Generally Programmers who write code they test This can be for any of the
above
Unit testing merupakan pengujian yang berbasis pada code yang dilakukan oleh developers. Pengujian ini dilakukan untuk menguji masing-masing unit secara terpisah. Pengujian ini dapat dilakukan untuk sebagian kecil dari code atau yang umumnya tidak lebih besar dari class (Nidhra dan Dondeti, 2012:30).
Sementara itu, User Acceptance Testing (UAT) merupakan pengujian akhir terhadap sistem sebelum user melakukan “sign off”. Testing ini sering dilakukan oleh para user sendiri, meskipun di beberapa organisasi atau perusahaan, business analyst yang melakukan testing ini (Howard, 2009:293).
2.5.1 White Box Testing
White box testing pada umumnya dilakukan untuk mendeteksi logical error yang terdapat dalam program. Hal ini digunakan untuk debugging code, menemukan kesalahan dalam pengetikan, dan mengungkap asumsi pemrograman yang salah.
White box testing dilakukan pada tahap awal pengembangan dan penerapan source code. Hal ini dapat dilakukan pada semua tingkat system development terutama pada unit, system dan integration testing. White box testing dapat digunakan untuk proses pengembangan lainnya seperti analisis kebutuhan, perancangan, dan uji kasus (Nidhra dan Dondeti, 2012:38).
2.5.2 Black Box Testing
Black box testing mengasumsikan bahwa penguji tidak tahu apa-apa tentang pemrograman atau code yang terdapat pada program. Test case dibuat berdasarkan kisaran input nilai yang program harus terima (atau tolak) dan nilai-nilai output yang diharapkan.
Karena tidak ada pengetahuan tentang kode program, satu-satunya cara untuk mengetahui ketepatan program adalah dengan mengamati efek dari kumpulan input yang telah ditentukan dan melihat respon sistem terhadap input tersebut. Dengan kata lain, developer harus menguji setiap kemungkinan nilai input dan setiap kondisi yang dapat dialami sistem (Clifton, 2013:124).
2.6 Lima Faktor Manusia Terukur (Measurable Human Factors Issues) Terdapat lima faktor yang perlu diperhatikan untuk mengevaluasi perancangan interface suatu sistem. Kelima faktor itu adalah:
− Waktu untuk belajar, merupakan ukuran berapa lama yang dibutuhkan seorang user untuk mempelajari fungsi-fungsi di dalam sebuah aplikasi hingga pada akhirnya dapat menggunakannya dengan baik.
− Kecepatan performa, merupakan ukuran berapa lama suatu fungsi atau serangkaian tugas di dalam aplikasi tersebut dilakukan.
− Tingkat error yang dilakukan user, merupakan ukuran berapa banyak dan jenis error yang dilakukan oleh pengguna di dalam melakukan tugas.
− Daya ingat user, merupakan ukuran berapa lama user mempertahankan ingatan dan pengetahuannya setelah beberapa jam, hari, atau bahkan minggu.
− Kepuasan subjektif, merupakan ukuran seberapa puas pengguna atas berbagai aspek dari suatu sistem (Shneiderman dan Plaisant, 2010, pp.32-33).
2.7 Common Business-Oriented Language (COBOL)
Common Business-Oriented Language (COBOL) adalah bahasa
pemrograman tingkat tinggi seperti C, C#, Java, Pascal, atau BASIC dengan fokus khusus dan sejarah yang panjang. Hierarki program COBOL terdiri dari Divisions, Sections, Paragraphs, Sentences, dan Statements (Coughlan, 2014:1).
2.7.1 Divisions
Division adalah elemen struktural utama dalam bahasa COBOL. Division dalam COBOL dibagi menjadi empat, yaitu Identification Division, Environment Division, Data Division, dan Procedure Division.
Identification Division menyediakan informasi mengenai program kepada user, compiler, dan linker. Paragraf PROGRAM-ID merupakan satu-satunya entri yang diperlukan. Pada umumya, entri ini diperlukan dalam setiap program.
Environment Division menggambarkan environment tempat program akan dijalankan. Sementara itu, Data Division digunakan untuk menggambarkan data-data yang diproses oleh program. Data division dibagi menjadi empat section yaitu File Section, Working-Storage Section, Linkage Section, dan Report Section. File dan Working-Storage section merupakan section utama, sedangkan Linkage Section hanya digunakan dalam subprogram dan Report Section hanya digunakan saat menghasilkan report.
Procedure Division merupakan tempat di mana semua data yang ada di dalam Data Division di proses dan dihasilkan. Procedure Division merupakan tempat untuk menggambarkan atau meletakkan algoritma program (Coughlan, 2014:23).
2.7.2 Sections
Sebuah Section terdiri dari satu atau lebih Paragraph. Sebuah Section diawali dengan nama Section dan berakhir di posisi di mana nama Section selanjutnya ditemui atau di akhir penulisan program. Nama Section terdiri dari nama yang diberikan oleh programmer atau didefinisikan langsung oleh program, diikuti dengan kata “Section” dan diakhiri dengan tanda titik (.).
Di tiga Division pertama (Identification Division, Environment Division dan Data Division), Section adalah sebuah struktur yang terorganisasi yang didefinisikan oleh program. Sementara itu, di dalam
Procedure Division, Sections dan Paragraphs digunakan untuk
mengidentifikasi deretan kode yang bisa dieksekusi dengan menggunakan keyword PERFORM ataupun GO TO.
2.7.3 Paragraphs
Sebuah Paragraph terdiri dari satu atau lebih Sentences. Paragraph diawali dengan nama Paragraph dan diakhiri dengan posisi di mana Section atau Paragraph selanjutnya dimulai atau dimana akhir dari program ditemui. Dalam tiga Division pertama (Identification Division, Environment Division dan Data Division), Paragraph adalah struktur yang terorganisasi yang sudah didefinisikan langsung oleh program, namun pada Procedure Division, Paragraphs digunakan untuk mengidentifikasi deretan kode yang bisa dieksekusi dengan menggunakan PERFORM ataupun GO TO.
2.7.4 Sentences
Sebuah Sentence terdiri dari satu atau lebih Statements dan dipisahkan dengan tanda titik (.). Di dalam satu Paragraph harus terdapat minimal satu Sentence, di mana setiap Sentence dihubungkan dengan tanda titik (.).
2.7.5 Statements
Di dalam program berbahasa COBOL, istilah Statement mengacu pada kata kerja. Sebuah Statement diawali dengan nama kata kerja yang diikuti dengan operand akhir atau operand yang mengerjakan kata kerja tersebut.
Bahasa COBOL ditujukan untuk operasi pengolahan data, seperti membaca data, memproses data, dan menghasilkan output berupa informasi. Penggunaan COBOL sebagai bahasa pemrograman yang dikhususkan untuk bisnis terlihat dari kemampuan COBOL untuk menghasilkan laporan keuangan yang kompleks, penentuan dan penyimpanan data desimal dan karakter secara presisi, serta kemampuan untuk menspesifikasikan operasi aritmatika yang melibatkan bilangan desimal. Hal ini membuat program COBOL dapat melakukan perhitungan bisnis dengan tingkat ketelitian yang tinggi (Sebesta, 2013, pp. 78).
2.8 Asuransi
Definisi Asuransi Jiwa menurut Undang-Undang Nomor 2 Tahun 1992 “Asuransi atau Pertanggungan adalah perjanjian antara dua pihak atau lebih, dengan mana pihak penanggung mengikatkan diri kepada tertanggung, dengan menerima premi asuransi, untuk memberikan penggantian kepada tertanggung karena kerugian, kerusakan atau kehilangan keuntungan yang diharapkan, atau tanggung jawab hukum kepada pihak ketiga yang mungkin akan diderita tertanggung, yang timbul dari suatu peristiwa yang tidak pasti, atau untuk memberikan suatu pembayaran yang didasarkan atas meninggal atau hidupnya seseorang yang dipertanggungkan.”
Selanjutnya, di dalam pasal 2 menjelaskan mengenai objek asuransi: “Objek Asuransi adalah benda atau jasa, jiwa dan raga, kesehatan manusia, tanggung jawab hukum, serta semua kepentingan lainnya yang dapat hilang, rusak, rugi, dan atau berkurang nilainya.”
Dari kedua pasal tersebut bisa disimpulkan bahwa jiwa adalah salah satu hal yang bisa diasuransikan. Sehingga asuransi jiwa bisa diartikan dengan perjanjian antara dua pihak atau lebih, dengan mana pihak penanggung mengikatkan diri kepada tertanggung, dengan menerima premi asuransi, untuk memberikan suatu pembayaran yang didasarkan atas meninggal atau hidupnya seseorang yang dipertanggungkan. Penanggung yang dimaksud disini adalah perusahaan asuransi jiwa, yaitu perusahaan yang memberikan jasa dalam penanggulangan risiko yang dikaitkan dengan hidup atau meninggalnya seseorang yang dipertanggungkan.
