Bab 2

LANDASAN TEORI

2.1 Lembaga Agama

Lembaga Agama adalah adalah organisasi yang terbentuk dimasyarakat yang

memiliki tujuan untuk mengatur kehidupan dan perilaku manusia yang ber-

hungan dengan keyakinan atau keagamaan di masyarakat yang dianutnya agar

senantiasa dapat hidup saling harmonis dalam kerukunan, berbangsa, dan ber-

negara. Adapun contoh lembaga agama adalah sebagai berikut :

1. Islam : Majelis Ulama Indonesia (MUI)

2. Kristen : Persekutuan Gereja-Gereja Indonesia (PGI)

3. Katolik : Konferensi Wali Gereja Indonesia (KWI)

4. Hindu : Parisada Hindu Dharma Indonesia (PHDI)

5. Buddha : Perwakilan Umat Buddha Indonesia (Walubi)

6. Khonghucu : Majelis Tinggi Agama Khonghucu Indonesia (Matakin)

2.2 Teori Software Development

Software developtment adalah proses pengembangan perangkat lunak mela-

lui beberapa tahapan yang tersusun secara sistematis sehingga menghasilkan

produk yang berkualitas. Di dunia developer istilah teori ini sering disebut

dengan Software Development Live Cycle (SDLC). SDLC merupakan siklus

hidup dari pengembangan software. Tujuan dari penggunaan SDLC adalah

untuk membangun sebuah sistem informasi yang direncanakan dengan baik

agar memenuhi target produk yang akan dibuat. Fungsi yang pertama dari

5
 6

SDLC adalah membantu komunikasi antar tim developer dalam pengembang-

an sistem. Hal ini sangat penting, karena untuk mengurangi terjadinya kesalah

pahaman antar tim. Contoh kasus dari sisi UI/UX Designer misalknya menja-

lankan tugas untuk membuat rancangan awal desain sebuah website. Kemudi-

an, pada sisi front end developer dapat menjalankan tugasnya untuk membuat

tampilan sebuah website dari hasil rancangan desain murni dari UI/UX De-

signer. Dan dari sisi back end dapat menguruhs bagian database dan server

untuk dipakai oleh front end. Kemudian fungsi kedua yaitu untuk membe-

rikan tampilan yang jelas mengenai input dan output dalam berbagai tahap

pengembangan perangkat lunak. Tampilan sangat diperlukan untuk menge-

tahui peran dan tugas setiap tim serta membantu meningkatkan kepercayaan

dari klien. Hal tersebut sanga penting, karena dapat meningkatkan kualitas

dalam hal pengerjaan setiap proyek.

2.2.1 Tahap SDLC

SDLC mempunyai beberapa tahapan yang bersifat eksibel dan setiap per-

usahaan memiliki sistem pengembangan perangkat lunak yang berbeda. Hal

ini karena untuk tahap software development disesuaikan dengan kebutuhan

pengembangan produk atau tampilan sistem yang sesuai dengan permintaan

klien. Berikut ini tahapan dari SDLC :

1. Analyze (Analisis). Pada tahap ini berfungsi untuk merencanakan ran-

cangan pembuatan software atau aplikasi. Dimula dari perencanaan alo-

kasi sumber daya, biaya, estimasi waktu pengerjaan, kebutuhan tim, adn

lain-lain.

2. Design (Desain). Setelah melakukan perencanaan dengan baik, tahap

selanjutnya adalah proses design. Pada tahap ini, developer akan meren-

canakan seluruh sistem dan merencanakan alur algoritma dengan baik.

Proses design tidahk hanya menentukan alur algoritma program, namun

pembuatan design awal tampilan akan diperhatikan agar saat masuk pa-

da tim developer dapat mengimplementasikan dengan sempurna.

3. Implementation (Implementasi). Tahap selanjutnya adalah implementa-

si program yang diserahkan pada tim developer. Tim software developer

akan dibagi dua tim besar yaitu front end dan back end. Pada tahap

ini dilakukan penulisan kode dengan menggunakan bahasa pemrograman

tertentu.
 7

4. Testing (Pengujian), Setelah menyelesaikan pembuatan program, maka

akan masuk pada tahap pengujian atau testing. Testing disini lebih pa-

da pengujian program yang dibuat untuk mencari berbagai kesalahan

seperti bug, error, ataupun permasalahn lain yang muncul dari software

tersebut. Pada beberapa perusahaan ataupun startup, biasanya menem-

patkan tim khusus untuk menangani testing. Quality Assurance (QA)

merupakan posisi untuk menangani pengujian software. Pengujian dapat

dilakukan dengan metode black box atau white box.

2.3 Requirements Engineering

Requirements Enginering adalah fase terdepan dari proses rekayasa perangkat

lunak (software engineering), dimana software requirements (kebutuhan) dari

user (pengguna) dan customer (pelanggan) dikumpulkan, dipahami dan dite-

tapkan. Para pakar software engineering sepakat bahwa requirements enginee-

ring adalah suatu pekerjaan yang sangat penting. Fakta membuktikan bahwa

kebanyakan kegagalan pengembangan software disebabkan karena adaya keti-

dak konsistenan (inconsistent), ketidaklengkapan (incomplete), maupun keti-

dakbenaran (incorrect) dari requirements specication (spesikasi kebutuhan).

2.3.1 Metode Pengumpulan Requirement

Pengumpulan requirement bertujuan untuk melakukan survey terhadap ke-

inginan pemakai dan menjelaskan sistem informasi yang ideal. Berikut ini

metode pengumpulan requirement.

1. Interviews (Tanya Jawab). Metode ini dapat mengukur respon melalui

pertanyaan dan menyeseuaikannya sesuai situasi yang terjadi. Metode

ini baik untuk permasalahan yang tidak terstruktur.

2. Kuesioner. Metode ini mudah untuk mensitensis hasil sejal pembuatan

dan dapat meminimalkan biaya untuk semua end-user.

3. Observasi. Secara perobadi seorang analisis mengunjungi lokasi penga-

matan. Analisis merekam kejadian dalam lokasi pengamatan termasuk

volume dan pengolahan lembar kerja.

4. Prosedur Analisis. Melalui observasi, analis mempelajari kenyataan

daripada mendeskripsikan volume distribusi (tinggi, rendah, sedang) dan

apa yang selanjutnya dikerjakan terhadap salinan dari dokumen aslinya.

 8

5. Pengamatan Dokumen. Metode ini dapat meminimalkan interupsi

dari fungsi operasionalnya.

2.4 Stakeholder
Stakeholder adalah pihak individu, kelompok, ataupun komunitas tertentu

yang mempunyai kepentingan dalam suatu perusahaan. Stakeholder mempu-

nyai potensi untuk bisa memengaruhi ataupun dipengaruhi oleh bisnis yang

ada didalamnya. Menurut ISO 26000 SR stakeholder adalah individu atau

kelompok yang berkepentingan terhadap aktivitas dan keputusan organisasi.

Beberapa contoh dari pihak stakeholder adalah pegawai, pelanggan, pemasok,

investor, komunitas, dan Pemerintah. Setiap stakeholder tersebut tentunya

memiliki kepentingannya masing-masing dalam suatu perusahaan. Untuk itu,

pihak manajemen perusahaan harus bisa mendapatkan cara terbaik untuk bisa

menyinergikan tujuan bisnis dengan kepentingan stakeholder tersebut. Pada

umumnya, stakeholder akan terbagi berdasarkan posisi, kekuatan, serta pe-

ngaruhnya. Berikut ini adalah jenis-jenis stakeholder tersebut.

1. Stakeholder Utama (Primer), adalah stakeholder yang erat kaitannya

dengan penyusunan kebijakan, proyek, dan program. Mereka adalah pi-

hak penentu yang paling utama dalam aktivitas pengambilan keputusan

perusahaan. Beberapa contoh stakeholder primer ini adalah masyarakat

dan tokoh masyarakat, serta manajer publik.

2. Stakeholder Pendukung (Sekunder), adalah pihak yang tidak akan ber-

hubungan langsung atas suatu program, kebijakan atau suatu proyek.

Tapi, stakeholder primer memiliki rasa keprihatinan dan kepedulian, se-

hingga mereka turut serta dalam mengatakan pendapatnya yang berpo-

tensi mampu mengubah sikap stakeholder primer dan keputusan resmi

pemerintah. Contoh dari stakeholder sekunder yaitu Lembaga Pemerin-

tahan yang berada dalam suatu wilayah tertentu, Perguruan Tinggi, dan

Pengusaha.

3. Stakeholder Kunci, merupakan kelompok eksekutif yang memiliki wewe-

nang resmi atas pengambilan keputusan. Beberapa contoh dari stake-

holder kunci dalam suatu proyek pemerintah daerah kabupaten adalah

Pemerintah Kabupaten, DPRD Kabupaten, dan Dinas yang bertang-

gung jawab langsung atas pengerjaan proyek tersebut.

 9

2.5 BPMN
BPMN adalah singkatan dari Business Process Modeling Notation, yaitu suatu

metode pemodelan proses bisnis, dan juga sebagai alat desain pada sistem yang

berbasis pesan (message-based). Tujuan utama dari BPMN adalah menyedia-

kan notasi yang mudah digunakan dan bisa dimengerti oleh semua orang yang

terlibat dalam bisnis. Terdapat 4 kategori dari elemen-elemen dalam BPMN,

yaitu :

2.5.1 Flow Objects

1. Events, sebuah event direpresentasikan dengan lingkaran, digunakan un-

tuk menggambarkan sesuatu yang terjadi selama berlangsungnya proses

bisnis. Events dapat berupa Start, Intermediate, atau End.

Gambar 2.1: Simbol Event

2. Activity, sebuah aktivitas direpresentasikan dengan persegi panjang, di-

gunakan untuk memperlihatkan pekerjaan yang dilakukan.

Gambar 2.2: Simbol Activity

3. Gateway, sebuah gateway direpresentasikan dengan belah ketupat dan

memperlihatkan pilihan yang berbeda.

Gambar 2.3: Simbol Gateway

 10

2.5.2 Connecting Object

Connecting Object adalah elemen yang menghubungkan ow object.

1. Sequence Flow, sequence ow digambarkan dengan garis lurus dengan

panah tertutup dan menjelaskan mengenai urutan aktivitas yang akan

dijalankan.

Gambar 2.4: Simbol Sequence Flow

2. Message Flow, message ow direpresentasikan dengan garis putus-putus

dan panah terbuka. Message ow menjelaskan pertukaran pesan yang

sedang terjadi.

Gambar 2.5: Simbol Message Flow

2.5.3 Swimlanes
Elemen yang memisahkan dan mengelompokan aktor.

1. Pool yang digunakan untuk mewakili partisipan dalam sebuah proses

2. Lane merupakan bagian lebih mendetail dari pool dugunakan untuk

mengatur dan mengakategorika aktivitas.

Gambar 2.6: Simbol Pool dan Lane

 11

2.5.4 Artifacts
1. Data Object, data object digunakan untuk menjelaskan mengenai data

yang dibutuhkan atau dihasilkan dari sebuah aktivitas.

Gambar 2.7: Simbol Data Object

2.6 Use Case Diagram

Use case diagram adalah satu jenis dari diagram UML (Unied Modelling La-

nguage) yang menggambarkan hubungan interaksi antara sistem dan aktor.

Use Case dapat mendeskripsikan tipe interaksi antara pengguna sistem de-

ngan sistemnya. Use case diagram merupakan langkah awal untuk melakukan

pemodelan yang mampu menjabarkan aksi aktor dengan aksi sistem.

Adapun, fungsi dari use case diagram sebagai berikut :

1. Berguna memperlihatkan proses aktivitas secara urut dalam sistem

2. Mampu menggambarkan proses bisnis, bahkan menampilkan urutan ak-

tivitas pada sebuah proses.

Simbol - simbol pada use case diagram :

 12

Gambar 2.8: Simbol Use Case Diagram

2.7 Integration Denition Language (IDEF)

IDEF merupakan sekelompok metode pemodelan yang dapat digunakan untuk

menetapkan model-model data dan proses bisnis. IDEF bertujuan untuk ke-

giatan pemodelan yang diperlukan untuk mendukung analisis sistem, desain,

peningkatan atau integrasi.

2.7.1 IDEF0
IDEF0 digunakan untuk memodelkan keputusan, tindakan, dan aktivitas dari

suatu organisasi atau sistem, untuk mengkomunikasikan perspektif fungsional

dari suatu sistem. IDEF0 memungkinkan user untuk menggambarkan sebuah

sudut pandang proses meliputi :

1. Input, yaitu sumber daya yang dikonsumsikan atau ditransformasikan

 13

oleh proses.

2. Output, yaitu hal-hal yang dihasilkan selama konsumsi atau transformasi

input oleh proses.

3. Control, yaitu hal-hal yang memandu proses : kebijakan, panduan, stan-

dar, hukum.

4. Mechanis, yaitu perantara yang menyelesaikan aksi yang membatasi pro-

ses.

Gambar 2.9: Diagram Umum IDEF0

Notasi IDEF0 terdiri dari box (kotak), seperti pada gambar 2.9 yang menya-

takan aktivitas dalam sistem dan arrow (anak panah) yang menggambarkan

hubungan antara aktivitas (Davis 1995).

2.7.2 IDEF1
IDEF1 merupakan metode untuk menganalisis struktur informasi dalam suatu

sistem. Tujuan dari metode ini adalah mengidentikasikan informasi apa yang

tersedia dalam organisasi, mengidentikasikan permasalahan-permasalahan

yang disebabkan oleh tidak adanya manajemen informasi yang sesuai dan me-

rincikan infromasi yang harus dikelola dalam implementasi.

 14

Gambar 2.10: Diagram Umum IDEF1

2.8 Proto Persona

Proto Persona adalah coretan kasar yang memuat informasi sederhana seperti

umur, jenis kelain, pendidikan, hobi, kepribadian, user's goals dan paint point.

Fungsi Proto Persona adalah memberikan gambaran singkat tentang target

pengguna produk kepada para pemangku kepentingan pada tahap brainstor-

ming ide. Tahap ini penting untuk menarik minat pemimpin perusahaan agar

memahami untuk siapa sistem itu diciptakan sekaligus menyelaraskan keingin-

an mereka terkait sistem. Terdapat empat bagian yang harus digambarkan

dalam sebuah Proto persona terdiri dari sketsa dan nama, informasi demogra-

 perilaku, permasalahan dan kebutuhan, dan solusi potensial. Ada juga yang

terdiri dari informasi sketsa dan biogra sederhana, demogra kebutuhan dan

tujuan.

2.9 Task Model

Task model merupakan deskripsi dari kegiatan yang akan dilakukan dalam

mencapai tujuan akhir. Tujuan dari task pemodelan adalah unuk memba-

ngun sebuah model yang menggambarkan tepatnya hubungan antara berbagai

task yang diidentikasi. Task model biasanya disusun sedemikian rupa untuk

mencapai berbagai logical level. Dalam hal itu task model memerlukan in-

formasi yang banyak sehingga dapat menangkap semua kegiatan utama yang

harus dilakukan untuk mencapai tujuan yang diinginkan. Task Model ada-

lah deskripsi logis dari kegiatan yang akan dilakukan untuk mencapai tujuan

pengguna (Paterno, 2000). Task Model menggambarkan bagaimana aktivi-

tas dapat dilakukan untuk mencapai tujuan pengguna saat beriteraksi dengan

aplikasi yang dipertimbangkan. Tujuan Task Model adalah salah satu modikasi
 15

yang diinginkan dari keadaan aplikasi atau upaya untuk mengambil beberapa

informasi dari suatu aplikasi seperti mengakses database penerbangan untuk

menambah pemesanan baru memerlukan modikasi dari aplikasi. Setiap task

dapat dikaitkan dengan satu tujuan, yaitu tujuan dicapai dengan melakukan

task. Dalam beberapa kasus dimungkinkan untuk memilih antar task yang

berbeda untuk mencapai tujuan tertentu. Tujuan dari analisis task adalah

untuk mengidentikasi apa saja task yang relevan. Hasil analisis dari Task

Model dapat digunakan untuk mengembangkan berbagai jenis abstraksi se-

perti skenario, model domain, task model, sifat, penggun, dan model system.

Sejumlah pendekatan untuk Task Model telah dikembangkan, salah satu pen-

dekatan yang sangat menarik untuk diperkenalkan yaitu HTA. Hierarchical

Task Analysis atau HTA merupakan suatu metode analisis sederhana yang

menggambarkan pemecahan tugas secara hirarkis dan dapat dibagi menjadi

beberapa sub tugas. Hasil dari HTA adalah sekumpulan tugas dan sub tugas

yang tersusun secara hirarki dan perencanaan atau yang melukiskan semua

kondisi dari pekerjaan tugasnya.

2.10 Hierarchical Task Analysis (HTA)

Hierarchical Task Analysis (HTA) pertama kali diusulkan pada akhir tahun

1960-an sebagai pendekatan umum untuk memeriksa tugas. Dalam HTA, tu-

gas diwakili dalam bentuk hirarki ofgoals dan subgoals, menggunakan gagasan

rencana untuk menunjukan kapan subgoals perlu dilakukan (Shepherd, 2001).

HTA membutuhkan pemahaman rinci tentang tugas-tugas pengguna, hal ini

dapat dicapai dengan beberapa cara sebagai berikut (Hornsby, 2010).

1. Mengidentikasi tujuan utama pengguna

2. Mengidentikasi secara rinci langkah-langkah yang harus dilakukan peng-

guna untuk mencapai tujuan mereka.

Berikut Gambar 2.11 yang merupakan ilustrasi dari contoh Hierarchical Task

Analysis dengan contoh tugas yaitu pemesanan buku.

 16

Gambar 2.11: Contoh Hierarchical Task Analysis (Hornsby, 2010)

Dalam analisis Hierarchical Task Analysis diatas, terdapat tugas yang me-

miliki beberapa subtugas, untuk menjelaskan hubungan antara tugas utama

dengan subtugas menggunakan skema penomoran. Hierarchical Task Analysis

berdasarkan pada sudut pandang pengguna. Hierarchical Task Analysis dapat

menjelaskan tentang langkah-langkah tugas yang akan dilakukan pengguna.

2.11 Wireframe
Wireframe aplikasi bekerja untuk tujuan yang sama seperti gambar rangka kla-

sik. Menawarkan tampilan yang jelas dari kerangka desain, termasuk hal-hal

seperti sistem navigasi. Tujuannya adalah untuk menciptakan fondasi yang ko-

koh, memvalidasi fungsi inti produk sebelum menyempurnakan desain.Dalam

produk web, ada berbagai macam taktik dan pendekatan yang dapat diterapk-

an seseorang tanpa merusak kegunaan desain. Namun, di ponsel cerdas, ruang

layar yang terbatas dapat membatasi cara seseorang dapat menggunakan pro-

duk.

Manfaat gambar Wireframe Wireframe aplikasi lebih dari sekadar

langkah tambahan sederhana dalam proses desain. Sebenarnya,wireframe apli-

kasi memainkan peran yang sangat penting, membantu tim menciptakan fon-

dasi yang kuat untuk seluruh produkMeskipun mungkin tergoda untuk terjun

langsung ke prototipe high-delity yang halus, terburu-buru dalam memba-

ngun desain dapat menyebabkan bencana besar. Argumen paling meyakinkan

yang mendukung wireframing desain aplikasi adalah kemampuan untuk meng-

ujinya saat dibuat.