9

BAB 2

LANDASAN TEORI

1

2.1 Proyek

Menurut jurnal Petr Rehacek (2014:289) tentang Standar ISO 21500

dan Panduan Project Management Body of Knowledge (PMBoK®) untuk

Manajemen Proyek, proyek merupakan kumpulan proses unik yang terdiri dari

kegiatan-kegiatan yang terkoordinasi dan terkendali dengan tanggal awal dan

akhir untuk mencapai tujuan tertentu. Definisi ini berbeda dengan pengertian

terakhir dari panduan PMBoK® yang menyatakan bahwa proyek merupakan

aktivitas yang memiliki tujuan untuk menghasilkan kiriman (deliverables).

2.2 Model Manajemen

Menurut jurnal Gilles Garel (2013:664) tentang Sejarah Model Proyek

Manajemen, proyek merupakan bagian dari aktivitas manusia yang terorganisir,

baik dalam bangunan yang didirikan untuk memuja dewa, pertahanan,

infrastruktur dan lain-lain. Jika mengamati praktek dari proyek sebelumnya,

maka akan ditemukan “sesuatu” yang selalu didokumentasikan sebelum

memulai pengerjaan. Proyek selalu menjadi obyek pengamatan dalam sejarah

teknik dan rekayasa, menjadi inovasi pemikiran dan sejarah perusahaan. Pada

abad ke-20 manajemen proyek dipisahkan dari bentuk-bentuk kegiatan untuk

dapat diidentifikasi, disorot dan digeneralisasi kedalam bentuk tersendiri, dan

kini telah menjadi model manajemen. Artikel mengenai manajer proyek

dipublikasi oleh Harvard Business Review oleh Paul Gaddis (1959) yang

menjelaskan bahwa manajer proyek adalah seseorang yang bertanggung jawab

untuk mengintegrasikan kontribusi dari departeman yang berbeda untuk

meningkatkan efisiensi pengembangan.

2.3 Manajemen Proyek

Menurut jurnal Petr Rehacek (2014:289) tentang Standar ISO 21500

dan Panduan PMBoK® untuk Manajemen Proyek, terdapat beberapa analisis

perbandingan antara ISO 21500 dan Panduan PMBoK®. ISO 21500

10

memberikan deskripsi tingkat tinggi dari konsep dan proses yang dianggap

membentuk praktek yang baik dalam manajemen proyek.

2.3.1 Grup Proses Manajemen Proyek

Proses proyek dibagi ke dalam lima grup proses. Perbandingan

antara ISO 21500 dengan Panduan PMBoK® dapat dilihat pada tabel 2.1

di bawah ini:

Tabel 1.1 Perbandingan Grup Proses ISO 21500 dan Panduan

PMBoK® (Sumber: Petr Rehacek, 2014:289)

ISO 21500 PMBoK® Guide

Initiating Initiating

Planning Planning

Implementing Executing

Controlling Monitoring and Controlling

Closing Closing

Perbedaan pada keduanya hanya pada penamaan, standar proses

tidak terlalu banyak berubah.

2.3.2 Grup Subjek

Knowledge areas pada Panduan PMBoK® telah diubah namanya

menjadi subjek (subjects) pada ISO 21500. Perbandingan keduanya

dapat dilihat pada tabel 2.2 di bawah ini:

Tabel 1.2 Perbandingan Subjek ISO 21500 dan Knowledge areas

Panduan PMBoK® (Sumber: Petr Rehacek, 2014:290)

ISO 21500 – Subjek PMBoK® Guide – Knowledge Areas

Integration Integration

Stakeholder X

Scope Scope

Resource Human Resources

11

Time Time

Cost Cost

Risk Risk

Quality Quality

Procurement Procurement

Communication Communication

Dari perbandingan diatas, dapat dilihat bahwa ISO 21500 dibuat

berdasarkan Panduan PMBoK®. ISO 21500 menambahkan Stakeholder

pada subjek. Knowledge area Human Resources diganti menjadi subjek

Resource dengan tujuan dapat mencakup sumber daya manusia dan

sumber daya proyek lainnya. Perbedaan utama dari kedua standar diatas

adalah dimana ISO 21500 tidak menyediakan deskripsi alat dan teknik.

Deskripsi pada ISO 21500 terdiri dari deskripsi umum dan tabel yang

berisi input dan output utama.

2.4 Analisa Sistem dan Perancangan Sistem

Dalam mengembangkan aplikasi, akan dibutuhkan analisis-analisis

mengenai sistem serta dibutuhkannya perancangan dalam membangun aplikasi

yang baik.

2.4.1 Pengertian Analisa Sistem

Menurut Whitten & Bentley (2007:160), analisis sistem

merupakan sebuah teknik problem-solving yang membagi sebuah

sistem ke dalam beberapa bagian komponennya sendiri yang bertujuan

untuk mempelajari sebagaimana baik bagian-bagian dari komponen

tersebut melakukan pekerjaan dan berinteraksi untuk mencapai tujuan

mereka.

Analisis sistem diawali dari permasalahan bisnis pada system

owners dan system users. Oleh karena itu, analisis tentang knowledge,

process dan communications harus berdasarkan perspektif system

owners dan system users.

12

Menurut Whitten & Bentley (2007:161-167), terdapat lima

pendekatan pemecahan masalah pada analisis sistem:

1. Pendekatan Analisis Model-Driven

Analisis model-driven adalah pendekatan pemecahan masalah yang

menekankan gambaran model sistem untuk dokumentasi dan

validasi sistem. Pada akhirnya, model sistem menjadi blueprint

untuk merancang dan membangun sistem yang lebih baik. Terdapat

tiga pendekatan model-driven yang populer dan sering digunakan:

a. Traditional Approaches

Berbagai pendekatan tradisional untuk analisis sistem dan desain

dikembangkan mulai tahun 1970-an. Salah satu pendekatan

formal yang pertama, yang masih banyak digunakan saat ini,

adalah structured analysis. Structured analysis berfokus pada

aliran data yang melalui proses bisnis dan perangkat lunak

b. Information Engineering (IE)

Information Engineering berfokus pada struktur data yang

tersimpan dalam suatu sistem bukan pada proses.

c. Object-Oriented Approach

Pendekatan object-oriented tidak melihat sistem informasi

sebagai data ataupun proses, tetapi merupakan suatu kumpulan

obyek yang merupakan rangkuman dari data dan proses.

2. Pendekatan Analisis Accelerated Systems

Discovery Prototyping dan Rapid Architected Development (RAD)

merupakan contoh dari pendekatan analisis accelerated systems

yang menekankan pembangunan prototype agar dapat mempercepat

proses identifikasi persyaratan bisnis dan user untuk sistem baru.

3. Metode Requirements Discovery

Baik pendekatan analisis model-driven maupun accelerated systems

mempunyai tujuan yang sama yaitu menggambarkan kebutuhan

user pada sistem baru, baik digambarkan menggunakan model

maupun prototype. Menggali kebutuhan (requirements) tergantung

pada kemampuan analis untuk menemukan masalah (problem) dan

kesempatan (opportunities) yang ada pada sistem sekarang.

Requirements discovery disini merupakan sebuah proses yang

13

digunakan sistem analis untuk mengindentifikasi masalah pada

sistem dan menentukan solusinya berdasarkan dengan kebutuhan

user.

4. Metode Business Process Redesign

Business process re-design (BPR) adalah metode analisis sistem

dengan tujuan untuk mengganti atau meningkatkan fundamental

dari proses bisnis dan organisasi. Pada proyek BPR, proses bisnis

akan dianalisis untuk menentukan bagian proses yang akan

dieliminasi atau dirampingkan. Metode BPR merupakan metode

yang sangat cocok untuk diterapkan pada proses bisnis yang

mengalami perubahan.

5. FAST Systems Analysis Strategies

Seperti kebanyakan metodologi pada umumnya, metodologi

FASTtidak menggunakan pendekatan tunggal pada analisis sistem.

Metodologi FAST mengintegrasikan semua pendekatan menjadi

sebuah kumpulan metode agile. Metode agile merupakan integrasi

dari berbagai pendekatan sistem analisis dan desain untuk

menemukan solusi yang tepat untuk menyelesaikan masalah.

2.4.2 Pengertian Perancangan Sistem

Menurut Whitten & Bentley (2007:160), perancangan sistem

merupakan perancangan yang dilakukan dalam menciptakan solusi yang

mendetil dan spesifik berbasis komputer. Perancangan sistem dapat

disebut juga dengan desain fisikal. Sistem analis ditugaskan untuk

mencari permasalahan bisnis, sedangkan sistem desain berfokus pada

teknikal atau implementasi sistem.

2.5 Rekayasa Perangkat Lunak

Dalam era teknologi saat ini, semua orang berharap untuk dapat

mengembangkan aplikasi-aplikasi yang bagus, dengan tujuan yang bermacam-

macam. Untuk pengembangan ini, secara praktis mereka harus mengerti

terlebih dahulu apa saja hal yang diperlukan, tentu saja rekayasa piranti lunak

ini berkaitan dengan pengembangan aplikasi.

14

2.5.1 Definisi Rekayasa Perangkat Lunak

Menurut Pressman & Maxim (2015:14), rekayasa piranti lunak

meliputi sebuah proses, sebuah koleksi dari metode-metode (praktek)

dan berbagai alat yang mengijinkan profesional-profesional untuk

membangun perangkat lunak komputer yang berkualitas tinggi

2.5.2 Model Proses Perangkat Lunak

Menurut Pressman & Maxim (2015:40), model proses

menyediakan sebuah road map yang spesifik untuk cara kerja rekayasa

piranti lunak. Model proses ini mendefinisikan alur dari seluruh

aktivitas, aksi dan pekerjaan, tingkat iterasi, produk, dan organisasi dari

pekerjaan yang harus diselesaikan.

1. Model Waterfall

Menurut Pressman & Maxim (2015:42), model waterfall disebut

juga sebagai classic life cycle, menganjurkan sebuah sistematik,

pendekatan sekuensial untuk pengembangan piranti lunak yang

dimulai dengan spesifikasi dari kebutuhan pelanggan dan proses-

proses melalui perencanaan, pemodelan, konstruksi, dan peluncuran,

memuncak pada bantuan yang sedang berjalan dari penyelesaian

suatu piranti lunak. Tahap-tahap dalam model waterfall antara lain:

a. Komunikasi

Pada tahap ini, tim melakukan pengumupulan data-data yang

berguna demi kepentingan proyek, lalu menginisiasi pembuatan

proyek.

b. Perencanaan

Pada tahap perencanaan, tim memperkirakan setiap detil yang

dibutuhkan dalam pembuatan proyek, penjadwalan dan

pelacakan terhadap proses yang sedang berjalan.

c. Pemodelan

Pada tahap ini, dilakukan analisa dan pemodelan, berikut

pembuatan desain, sesuai dengan kebutuhan proyek.

d. Konstruksi

15

Di tahap berikut ini, tim melakukan konstruksi pembuatan kode-

kode guna membangun proyek, serta melakukan percobaan pada

prototipe proyek.

e. Peluncuran

Pada tahap ini, dilaksanakannya penyampaian produk pada

pelanggan, menyediakan bantuan kepada para pengguna, dan

pengumpulan umpan balik demi memperbaiki dan memperbagus

produk terkait.

2.6 Unified Modeling Language (UML)

Menurut Whitten & Bentley (2007:371), UML adalah sebuah set

pemodelan konvensi yang digunakan untuk menspesifikasikan atau

mendeskripsikan suatu sistem perangkat lunak dalam hal obyek. Berikut adalah

penjelasan mengenai komponen-komponen UML:

2.6.1 Use Case Diagram

Menurut Whitten & Bentley (2007:246), use case diagram

adalah sebuah diagram yang menggambarkan interaksi antar sistem dan

pengguna. Dengan kata lain, diagram ini mendeskripsikan secara grafis,

siapa yang akan menggunakan sistem dan bagaimana cara yang

diekspektasikan pengguna untuk berinteraksi dengan sistem. Berikut

adalah contoh use case diagram:

Gambar 1.1 Use Case Diagram (Sumber: Whitten & Bentley,

2007:246)

Menurut Whitten & Bentley (2007:246-247), simbol-simbol

yang digunakan dalam pembuatan use case diagram yaitu:

16

1. Use case

Use case mendeskripsikan fungsi sistem dari perspektif pengguna

eksternal dan dengan cara dan terminologi yang mereka mengerti.

Use case direpresentasikan secara grafis dengan elips horizontal

beserta nama dari use case yang terdapat di bawah, atas atau di

dalam elips.

Gambar 1.2 Use case

2. Actors

Actors merupakan apapun yang dibutuhkan untuk berinteraksi

dengan sistem dan melakukan pertukaran informasi guna mencapai

sebuah tujuan yang diinginkan.

Gambar 1.3 Actor

Berikut adalah beberapa hal penting yang perlu untuk

diketahui, Actors memiliki empat tipe utama yaitu:

a. Primary business actor

Pemegang kepentingan yang mendapatkan keuntungan utama

dari hasil eksekusi dari use case dengan mendapatkan sesuatu

yang dapat diukur atau bernilai.

b. Primary system actor

Pemegang kepentingan yang berinteraksi langsung dengan

sistem untuk menginisiasi proses bisnis atau sistem.

c. External server actor

Pemegang kepentingan yang bertugas untuk menanggapi

permintaan dari use case.

d. External receiver actor

17

Pemegang kepentingan yang tidak merupakan aktor utama tetapi

mendapatkan sesuatu yang berharga atau bernilai dari use case.

3. Relationships

Menurut Whitten & Bentley (2007:248-250), relationships

digambarkan sebagai sebuah garis diantara dua atau lebih simbol

pada use case diagram. Makna dari relationships dapat berbeda-

beda, tergantung bagaimana garis itu digambarkan dan tipe simbol

apa yang dihubungkan. Berikut ini adalah penjelasan mengenai

beberapa relasi yang terdapat pada use case diagram:

a. Associations

Associations adalah sebuah hubungan interaksi yang terjadi

antara aktor dan use case.

b. Extends

Extends adalah hasil ekstrak dari use case yang telah

disederhanakan dari use case kompleks sebelumnya agar dapat

dimengerti dengan lebih mudah.

c. Uses (or include)

Uses or include adalah relasi antara abstract use case dan use

case yang menggunakannya. Abstract use case adalah sebuah

use case yang mengurangi redundansi antara dua atau lebih use

case dengan cara menggabungkan langkah-langkah yang

ditemukan pada cases.

d. Depends on

Depends on adalah sebuah relasi antar use case yang

mengindikasikan satu use case tidak dapat dikerjakan sebelum

use case sebelumnya telah dikerjakan.

e. Inheritance

Inheritance pada use case adalah sebuah relasi antara aktor

dibuat untuk menyederhanakan penggambaran ketika sebuah

aktor abstrak mewarisi peran dari banyak aktor aslinya.

2.6.2 Use Case Narrative

Menurut Whitten & Bentley (2007:246), use case narrative

adalah sebuah deskripsi tekstual dari business event dan bagaimana user

18

akan berinteraksi dengan sistem untuk menyelesaikan tugas. Contoh use

case narrative:

Gambar 1.4 Use Case Narrative (Sumber: Whitten & Bentley,

2007:257)

19

Menurut Whitten & Bentley (2007:257), notasi-notasi pada use

case narrative yang dideskripsikan pada event, antara lain:

1. Author

Nama dari individual yang berkontribusi untuk menuliskan use case

dan yang menyediakan sebuah kontak poin untuk siapapun

membutuhkan informasi tambahan mengenai use case.

2. Date

Tanggal yang menampilkan kapan use case terakhir kali

dimodifikasi.

3. Version

Menunjukkan versi dari use case yang masih berlaku untuk

digunakan pada saat ini.

4. Use case name

Nama daripada use case harus merepresentasikan tujuan dari use

case yang sedang dicoba untuk diselesaikan.

5. Use case type

Dalam mengerjakan use case modelling, use case kebutuhan bisnis,

yang mana berfokus pada visi dan tujuan stretegis dari beberapa

pemegang saham, dikonstruksi pada urutan pertama.

6. Use case ID

Sebuah tanda pengenal yang secara unik digunakan untuk

mengidentifikasi use case.

7. Priority

Prioritas mengomunikasikan kepentingan dari sebuah use case

dalam artian tinggi, sedang, atau rendah.

8. Source

Sumber yang menjelaskan entitas sebagai pemicu kreasi atau

pembuatan dari sebuah use case.

9. Primary business actor

Aktor bisnis primer merupakan pemegang saham yang memiliki

keuntungan utama dari eksekusi use case dengan menerima sesuatu

yang berharga atau bernilai.

10. Other participating actors

20

Aktor lain yang berpartisipasi dalam use case untuk menyelesaikan

tujuannya, yang mencakup aktor penginisiasi, aktor pemfasilitasi,

aktor pemberi/penerima, dan aktor sekunder.

11. Interested stakeholder(s)

Seorang pemegang saham merupakan siapapun yang memiliki

kuasa pada pengembangan dan operasi dari sebuah sistem piranti

lunak.

12. Description

Sebuah deskripsi rangkuman pendek, yang terdiri atas sekumpulan

kalimat, yang menguraikan tujuan dari use case dan aktivitasnya.

2.6.3 Activity Diagram

Menurut Whitten & Bentley (2007:390), activity diagram adalah

sebuah diagram yang dapat digunakan untuk menggambarkan alur dari

sebuah proses bisnis, langkah-langkah dari sebuah use case, atau logika

dari sebuah perilaku obyek (metode). Contoh activity diagram:

21

Gambar 1.5 Activity Diagram (Sumber: Whitten & Bentley,

2007:392)

Menurut Whitten & Bentley (2007:391), berikut ini adalah

ilustrasi dari notasi-notasi yang paling umum digunakan dalam

pembuatan activity diagram:

1. Initial node

Lingkaran padat hitam yang merepresentasikan awal dimulainya

sebuah proses.

Gambar 1.6 Initial node

22

2. Actions

Persegi panjang bersudut lingkaran yang merepresentasikan langkah

individual dan kegiatan yang sedang berjalan.

Gambar 1.7 Actions

3. Flow

Panah pada diagram mengindikasikan pergerakan dari action.

Gambar 1.8 Flow

4. Decision

Sebuah proses berbentuk diamond yang menggambarkan flow yang

masuk dan keluar, mengindikasikan kondisi yang terjadi, dimana

terbaginya flow menjadi beberapa jalur karena adanya aksi yang

berbeda.

Gambar 1.9 Decision

5. Merge

Sebuah proses berbentuk diamond yang menggambarkan flow yang

masuk dan keluar. Flow yang masuk mengindikasikan kondisi yang

terjadi, dimana flow bergabung menjadi satu jalur, dikarenakan flow

ini memiliki kondisi yang sama.

Gambar 1.10 Merge

23

6. Fork

Sebuah bar hitam dengan satu flow masuk dan dua atau lebih flow

keluar, dimana flow yang keluar ini mengindikasikan aksi-aksi yang

akan berjalan secara paralel.

Gambar 1.11 Fork

7. Join

Sebuah bar hitam dengan dua atau lebih flow masuk dan satu flow

keluar, mencatatkan akhir dari proses yang beriringan. Semua aksi

yang masuk ke dalam join harus selesai terlebih dahulu sebelum

prosesnya dilanjutkan.

Gambar 1.12 Join

8. Activity final

Lingkaran padat didalam sebuah lingkaran berongga

merepresentasikan akhir dari sebuah proses.

Gambar 1.13 Activity final

9. Subactivity indicator

Sebuah simbol yang mengindikasikan bahwa aksiini telah terpecah

dari activity diagram yang lain. Hal ini membantu agar activity

diagram tidak menjadi terlalu kompleks.

24

Gambar 1.14 Subactivity indicator

10. Connector

Sebuah huruf di dalam sebuah lingkaran yang memberikan alat

untuk mengatur kompleksitas. Sebuah flow yang datang ke sebuah

konektor, melompat menuju flow yang keluar dari sebuah konektor

dengan huruf yang sesuai.

Gambar 1.15 Connector

11. Swimlane

Swimlane adalah partisi-partisi yang mengelompokkan dan

menunjukkan aksi-aksi yang dilakukan oleh sebuah class atau aktor

yang spesifik pada activity diagram.

Gambar 1.16 Swimlane

2.6.4 Sequence Diagram

Menurut Whitten & Bentley (2007:394), system sequence

diagram adalah sebuah diagram yang menggambarkan interaksi antara

aktor dan sistem untuk sebuah skenario usecase. Contoh sequence

diagram:

A

25

Gambar 1.17 Sequence Diagram (Sumber:Whitten & Bentley,

2007:662)

Menurut Whitten & Bentley (2007:394-395), berikut ini adalah

beberapa ilustrasi dari notasi-notasi yang digunakan dalam pembuatan

system sequence diagram:

1. Actor

Aktor yang menginisiasi use case, ditampilkan dengan simbol aktor

yang sama pada use case.

Gambar 1.18 Actor

2. System

Kotak yang mengindikasikan sistem sebagai sebuah “Black Box”

atau sebagai keseluruhan. Colon (:) merupakan notasi standar untuk

mengindikasikan instansi sistem.

Gambar 1.19 System

26

3. Lifelines

Garis vertikal dan putus-putus yang memanjang ke bawah dari

simbol aktor dan sistem, garis ini mengindikasikan proses

kehidupan dari suatu sequence.

Gambar 1.20 Lifelines

4. Activation bars

Bars yang ditetapkan sesuai dengan lifelines mengindikasikan

periode waktu ketika partisipan sedang aktif dalam sebuah interaksi

antar sistem maupun aktor.

Gambar 1.21 Activation bars

5. Input messages

Panah horizontal yang mengarah dari aktor menuju sistem

mengindikasikan pesan-pesan yang dimasukkan.

Gambar 1.22 Input messages

6. Output messages

Panah horizontal dari sistem menuju aktor yang ditampilkan dengan

garis putus-putus. Mengindikasikan pesan yang masuk.

Gambar 1.23 Output messages

7. Receiver actor

Aktor lain atau sistem eksternal yang mendapatkan pesan dari

sistem, dapat dimasukkan ke dalam kategori receiver atau sebagai

penerima pesan.

27

Gambar 1.24 Receiver actor

8. Frame

Sebuah kotak yang berisikan satu atau lebih pesan bertujuan untuk

membagi fragmen atau sebuah bagian dari sequence.

Gambar 1.25 Frame

2.6.5 Class Diagram

Menurut Whitten & Bentley (2007:400), Class diagram adalah

sebuah gambaran grafik dari sebuah struktur obyek sistem statis,

menunjukkan kelas-kelas obyek yang mana sistem itu terdiri dari

hubungan antara obyek-obyek kelas. Contoh class diagram:

Gambar 1.26 Class Diagram (Sumber: Whitten & Bentley,

2007:406)

Menurut Whitten & Bentley (2007:372), berikut adalah elemen-

elemen dasar daripada class diagram:

1. Object

Sesuatu yang dapat dilihat, disentuh, ataupun dirasakan dan dimana

pengguna menyimpan data dan mengasosiasikan behavior.

28

2. Attribute

Data yang merepresentasikan karakteristik-karakteristik yang terkait

dengan sebuah obyek.

3. Object Instance

Setiap hal yang spesifik yang dapat berupa, orang, tempat, barang,

ataupun event, berikut nilai-nilai untuk atribut dari obyek tersebut.

4. Behavior

Sekumpulan dari sesuatu hal yang dapat dilakukan oleh obyek dan

dapat berkorespondensi ke fungsi-fungsi yang memiliki aksi atas

sebuah data obyek.

5. Encapsulation

Pengemasan dari sekelompok hal-hal ataupun barang-barang

menjadi satu kesatuan yang utuh.

Menurut Whitten & Bentley (2007:650), atribut dan metode-

metode yang dapat diakses oleh kelas lain dalam suatu class diagram,

didefinisikan oleh visibility. Visibility adalah sebuah tingkatan akses

yang dimiliki oleh sebuah obyek eksternal untuk sebuah atribut atau

metode. Visibility dibagi menjadi tiga tingkatan, yaitu:

1. Public

Tingkatan public mengijinkan sebuah atribut kelas untuk diakses

pihak mana saja dan metode kelas untuk dapat dipanggil oleh kelas

mana saja, dinotasikan dengan simbol “+”.

2. Protected

Tingkatan protected mengijinkan atribut dan metode untuk

dipanggil dan diakses oleh suatu kelas, dimana atribut/metode ini

merupakan sebuah subclasses dari kelas, dinotasikan dengan simbol

“#”.

3. Private

Tingkatan private dimana atribut dan metodenya hanya dapat

diakses dan dipanggil oleh kelas yang telah ditentukan, dinotasikan

dengan simbol “-“.

Menurut Whitten & Bentley (2007:400-401), berikut adalah

hubungan-hubungan yang paling umum terjadi pada suatu obyek kelas:

1. Associations

29

Asosiasi merupakan sebuah hubungan yang terjadi diantara obyek-

obyek kelas. Asosiasi antar obyek-obyek kelas ini perlu diketahui

untuk dapat mengidentifikasi multiplicity.

2. Multiplicity

Multiplisitas merupakan konsep yang mengatur mengenai angka

minimum dan maksimum aksi dari sebuah obyek kelas yang

behubungan.

3. Generalization

Konsep generalisasi menggabungkan atribut-atribut serta metode-

metode yang banyak memiliki kesamaan, menjadi satu kelas

tersendiri, yang disebut supertype.

4. Specialization

Konsep spesialisasi menggabungkan atribut-atribut beserta metode-

metode yang unik terhadap suatu obyek, tetapi yang masi mewarisi

atribut dan metode yang ada pada kelas supertype, kelas ini disebut

dengan subtype.

5. Aggregation

Agregasi merupakan sebuah hubungan unik yang terjadi dimana

satu obyek merupakan bagian dari obyek lain.

Menurut Whitten & Bentley (2007:378), pada UML 2.0, notasi dari

agregasi tidak lagi digunakan, karena pada hubungan komposisi

terdapat beberapa perbedaan-perbedaan yang telah terdefinisikan

secara jelas dan lebih banyak digunakan pada programming,

sedangkan agregasi tidak terdefinisikan dengan pasti dan jelas.

Karena hal tersebut, beberapa pengguna mempertimbangkan bahwa

agregasi tidak lagi bermakna dalam programming.

6. Composition

Komposisi merupakan sebuah hubungan dimana satu kesatuan

obyek memiliki hak penuh atas bagian-bagiannya (menambah atau

menghapus suatu obyek kelas).

Menurut Whitten & Bentley (2007:650), dalam pembuatan class

diagram, dibutuhkan sebuah hubungan yang lebih mendalam antar

obyek-obyek kelas agar dapat menentukan komponen-komponen dari

30

piranti lunak dengan lebih spesifik dan akurat sehingga pembuatan

diagram dapat lebih detil. Hubungan tersebut adalah:

1. Dependency Relationships

Sebuah dependency relationships dibutuhkan untuk pemodelan

asosiasi antara dua kelas yang saling mengandalkan di dalam dua

instansi:

a. Pertama, untuk mengindikasikan kapan sebuah perubahan

terjadi dalam suatu kelas, yang dapat mempengaruhi kelas lain.

b. Kedua, untuk mengindikasikan asosiasi antara sebuah kelas

yang bersifat tetap dengan kelas yang bersifat sementara.

2. Navigability

Navigability didefinisikan pada asosiasi-asosiasi sebagai notasi

untuk mengindikasikan perpindahan pesan-pesan antar kelas yang

saling berhubungan. Navigability ini dapat dibedakan menjadi dua

jenis, yaitu:

a. Uni-directional

Uni-directional merupakan sebuah hubungan antar kelas yang

terjadi secara satu arah. Uni-directional dilimitasi menjadi satu

arah dikarenakan adanya suatu tujuan khusus antar kelas yang

berhubungan. Uni-directional dinotasikan dengan sebuah tanda

panah yang mengarah dari sumber menuju target.

b. Bi-directional

Bi-directional merupakan sebuah hubungan antar kelas yang

terjadi secara dua arah. Pada dasarnya asosiasi-asosiasi antara

kelas telah didefinisikan sebagai bi-directional (dua arah), yang

berartikan bahwa salah satu dari tipe kelas dapat melakukan

navigasi (pengiriman pesan) kepada kelas-kelas lain yang

memiliki tipe berbeda.

2.7 Interaksi Manusia dan Komputer

2.7.1 Pengertian Interaksi Manusia dan Komputer

Menurut Shneiderman dan Plainsant (2010: 22), interaksi

manusia dan computer merupakan ilmu yang mempelajari

31

2.7.2 Eight Golden Rules

Menurut Shneiderman dan Plaisant (2010: 88-89), ada delapan

aturan emas yang dapat diaplikasikan dalam perancangan user

interface, yaitu:

1. Strive for consistency

Banyak bentuk dari konsistensi yang harus diperhatikan dalam

merancang user interface. Beberapa diantaranya adalah harus

memiliki konsistensi dalam urutan aksi di situasi yang serupa,

memiliki menu, warna, layout dan font yang sama.

2. Cater to universal usability

User interface harus dapat menjawab kebutuhan dari user yang

berbeda-beda. Contohnya dengan menambahkan fitur explanation

untuk novice user dan menambahkan fitur shortcut untuk expert

user.

3. Offer informative feedback

Untuk setiap aksi yang dilakukan diharapkan adanya suatu umpan

balik bagi user. Respon yang diberikan tergantung dari aksi yang

dilakukan oleh user.

4. Design dialog to yield closure

Urutan suatu aksi haruslah diorganisasi berdasarkan kelompok

tertentu dari awal, tengah dan akhir. Umpan balik yang informatif

pada akhir suatu aksi kepada user akan memberikan kepuasan

kepada user bahwa aksi yang mereka lakukan telah berhasil dengan

baik dan menjadi pertanda untuk melakukan aksi selanjutnya.

5. Prevent errors

Perancangan suatu sistem haruslah dibuat sedemikian rupa sehingga

user tidak melakukan kesalahan. Jika user melakukan kesalahan

maka sistem seharusnya dapat mendeteksi dan

menawarkan.recovery yang sederhana, konstruktif dan spesifik.

6. Permit easy reversal of actions

Setiap aksi haruslah dirancang sedemikian rupa, sehingga user dapat

kembali ke keadaan sebelum aksi dijalankan. Hal ini dapat membuat

user lebih berani untuk mengeksplorasi sistem yang dibuat dan

memilih options yang tidak familiar.

32

7. Support internal locus of control

User yang berpengalaman biasanya memiliki keyakinan bahwa

mereka bertanggung jawab terhadap sistem dan sistem akan

memberikan respon terhadap aksi yang mereka lakukan. Respon

yang mengejutkan, urutan yang aneh dalam memasukkan data dan

kesulitan dalam memperoleh informasi yang diperlukan serta

ketidakmampuan dalam mendapatkan hasil sesuai aksi tertentu akan

menimbulkan kekacauan dan keraguan bagi user.

8. Reduce short term memory load

Keterbatasan manusia dalam mengelola memori jangka pendek

membuat user membutuhkan suatu tampilan yang sederhana,

pengaturan dalam multipage, pergerakan window yang sesedikit

mungkin serta waktu training yang cukup dan optimal.

2.8 Fact-Finding Techniques

Menurut Whitten & Bentley (2007:212), Fact-Finding adalah proses

formal dari penelitian, pertemuan, wawancara, kuisioner, pengambilan sampel,

dan teknik-teknik lainnya untuk mengumpulkan informasi mengenai

permasalahan sistem, kebutuhan-kebutuhan dan preferensi.

Menurut Whitten & Bentley (2007:215), berikut ini adalah tujuh teknik

Fact-Finding yang umumnya digunakan:

1. Sampel dari dokumentasi

Teknik pengambilan sampel ini dilakukan dengan cara mengumpulkan

dokumen-dokumen sampel yang repre sentatif, form-form dan arsip-

arsip sesuai dengan kebutuhan.

2. Penelitian

Teknik ini dilakukan dengan mengunjungi perusahaan yang memiliki

masalah sejenis dan meminta persetujuan mereka untuk bisa mendapatkan

informasi untuk mengatasinya, dapat juga dengan melakukan pencarian

jurnal terkait.

3. Observasi

Teknik ini dilakukan dengan cara berpartisipasi langsung ataupun

mengamati seseorang yang tengah beraktivitas untuk mempelajari

sistem dan cara kerjanya.

33

4. Kuisioner

Teknik ini menggunakan sebuah dokumen yang mengijinkan analis untuk

mengumpulkan informasi dan pendapat dari para responden.

5. Wawancara

Teknik ini mengumpulkan informasi dari individual melalui interaksi

langsung, tanya jawab antara analis dan narasumbernya.

6. Prototipe

Teknik ini dilakukan dengan membangun sebuah model kerja dengan skala

kecil yang dapat merepresentasikan kebutuhan-kebutuhan pengguna

tersebut.

7. Perencanaan Kebutuhan Bersama

Teknik yang mana prosesnya membutuhkan sebuah pertemuan grup

yang terstruktur untuk melakukan analisa permasalahan dan

mendefinisikan kebutuhannya.

2.9 Hypertext Markup Language (HTML)

Menurut Robin Nixon (2014:1), Hypertext Markup Language (HTML)

adalah sebuah bahasa penulisan yang diciptakan oleh Berners Lee untuk

menampilkan halaman dari sebuah web browser. HTML disimpan dengan tipe

file .htm atau .html.

2.10 Model-View-Controller (MVC)

Menurut Martin Mugisha (2014:29-32), Model-View-Controller

merupakan pola arsitektur yang digunakan untuk mengimplementasikan user

interface. Perangkat lunak dibagi menjadi tiga bagian (Model, View dan

Controller) yang saling terhubung.

34

Gambar 1.27 Interaksi komponen MVC (Sumber: Martin Mugisha,

2014:29-32)

Berikut ini merupakan detail interaksi antara komponen dalam pola

perancangan MVC:

8. Controller

a. Controller terlibat dalam perubahan state model.

b. Controller mendapatkan input dari mouse dan keyboard dari user dan

mengarahkan model dan view untuk berubah sesuai kebutuhan.

c. Controller menginterpretasikan interaksi dari view dan

menerjemahkannya ke dalam aksi yang dilakukan oleh model.

d. Controller juga bertanggung jawab untuk menampilkan view yang

sesuai untuk user yang sesuai.

9. Model

a. Model merupakan objek yang merepresentasikan suatu aktifitas ataupun

tabel database.

b. Model mengelola behavior dan juga data dari aplikasi perangkat lunak.

c. Model menerima permintaan untuk mendapatkan informasi dan

merespon instruksi untuk mengubah state.

d. Model menampilkan data aplikasi beserta rule yang mengatur akses

untuk memperbarui data.

10. View

a. View merupakan representasi visual dari model state.

b. View menerjemahkan isi model dengan mengakses data dari model dan

menentukan cara untuk menampilkan data.

35

c. View mengatur representasi output grafis dan tekstual dari aplikasi

perangkat lunak.

2.11 Hypertext Preprocessor (PHP)

Menurut Robin Nixon (2014:45-50), PHP adalah bahasa yang

digunakan untuk membuat server memproduksi hasil-hasil yang dinamis yang

berpotensial berbeda-beda setiap sebuah browser membuka halaman baru.

Secara umum, dokumen PHP diakhiri dengan ekstensi .php. Ketika sebuah web

server menemukan ekstensi ini pada sebuah file, web server secara otomatis

akan memindahkannya ke prosesor PHP.

2.12 Yii 2.0

Menurut Jeff Reifman (2014), Yii merupakan framework PHP gratis

dan open-source yang memiliki fitur untuk mendukung rapid development.

Fitur-fitur yang terdapat dalam framework Yii adalah:

1. Model-View-Controller Architecture

2. Database Access Objects (DAO) and Active Record

3. Form input, Validation, and Ajax support.

4. Yii’s code generation tool, Gii

5. Extensions

6. Error handling, logging, and testing.

2.13 MySQL

Menurut Robin Nixon (2014:171-179), MyStructured Query Language

(MySQL) adalah sebuah sistem manajemen basis data yang paling populer

untuk web servers.

MySQL dikembangkan pada pertengahan tahun 1990, yang sekarang

merupakan teknologi yang paling banyak digunakan oleh tujuan internet yang

paling sering dikunjungi hari ini. Sebuah basis data MySQL, memiliki satu atau

lebih tabel, yang mana setiap tabelnya berisikan arsip-arsip atau baris. Dalam

deretan ini terdapat berbagai macam kolom yang berisikan data itu sendiri.

Contoh tabel 2.3 dan perintah MySQL sederhana:

36

Tabel 1.3 Contoh Tabel Sederhana (Sumber: Robin Nixon,

2014:162)

Author Title Type Year

Mark Twain The Adventures of Tom

Sawyer

Fiction 1876

Jane Austen Pride and Prejudice Fiction 1811

Charles Darwin The Origin of Species Non-Fiction 1856

Charles Dickens The Old Curiosity Shop Fiction 1841

William Shakespeare Romeo and Juliet Play 1594

SELECT title FROM publications WHERE author = ‘William Shakespeare’

Istilah-istilah yang penting untuk diingat dalam pembuatan basis data

adalah:

1. Database merupakan wadah keseluruhan yang memuat kumpulan data

MySQL.

2. Table merupakan sub wadah dalam basis data yang memuat data

sebenarnya.

3. Row merupakan sebuah catatan tunggal dalam sebuah tabel yang memuat

beberapa konten.

4. Column merupakan nama dari konten pada sebuah baris.

2.14 Javascript

Menurut Robin Nixon (2014:323-324), JavaScript adalah sebuah

bahasa pemrograman client-side scripting yang keseluruhannya berjalan di

dalam web browser. JavaScript membawa fungsionalitas yang dinamis pada

websites.

Setiap kali sebuah halaman baru muncul secara tiba-tiba pada browser

(yang sering sekali kita sebut dengan sebutan pop-up), atau ketika kita melihat

beragam teks yang baru, warna, maupun sebuah gambar yang muncul di

halaman, atau mengambil sebuah obyek pada halaman dan kemudian

memindahkannya ke lokasi baru, semua hal tersebut dilakukan oleh JavaScript.

Penggunaan JavaScript itu sendiri, dengan cara menempatkan awalan <script>

dan akhiran </script> di antara label HTML dan tanpa menggunakan

semicolon (;).

37

2.15 Cascading Style Sheet (CSS)

Menurut Robin Nixon (2014:423), Cascading Style Sheet (CSS),

mengaplikasikan tampilan-tampilan pada halaman web untuk membuatnya

terlihat sebagaimana yang diinginkan.

Robin Nixon (2014:428-429), menjelaskan ada beberapa macam

tampilan CSS yang berbeda dalam penggunaannya, dimulai dari tampilan

default yang telah disediakan oleh browser, melalui inline, sampai ke tampilan

eksternal.

Gaya tampilan-tampilan tersebut adalah:

1. Default styles: tampilan dasar yang diberikan oleh web browser pada

halaman web yang tidak memiliki CSS pada pembuatannya.

2. User styles: tampilan yang dibuat langsung oleh pengguna, yang kemudian

diimplementasikan ke dalam web browser.

3. External style sheet: tampilan yang dibuat pada lembar pemrograman yang

terpisah demi memproduksi tampilan berbeda untuk tujuan yang berbeda

juga, seperti menampilkan web pada umumnya di browser komputer atau

laptop, dan untuk ditampilkan pada sebuah mobile browser dengan layar

yang lebih kecil, untuk percetakan dan lainnya.

4. Internal styles: tampilan yang dibuat didalam tags <style>…. </style> dan

yang mana lebih diutamakan untuk digunakan dari semua gaya tampilan

yang ada.

5. Inline styles: tampilan yang dibuat dan ditujukan langsung kepada sebuah

elemen. Gaya tampilan ini merupakan gaya yang paling utama dari segala

jenis tampilan yang digunakan.

2.16 Rich Pictures

Menurut Gammack, Hobbs & Pigott (2011:120), Rich pictures adalah

sebuah teknik fleksibel untuk pembuatan diagram situasi permasalahan dan

menimbulkan pengetahuan serta perilaku. Idenya yaitu untuk mengekspresikan

dan merepresentasikan situasi dimana sebuah permasalahan itu dirasakan dan

pada akhirnya sebuah sistem informasi dapat menjadi relevan pada situasi

tersebut.

38

Rich pictures memiliki fitur-fitur sebagai berikut: Aspek struktural,

Proses dan alur, dan Kepentingan.

Gambar 1.28 Rich Pictures (Sumber: Gammack, Hobbs &

Pigott,2011:121)

2.17 Data Dictionary

Menurut Connoly & Begg (2015:63), data dictionary merupakan

pendeskripsian sifat dari database yang menyediakan data independence. Data

dictionary menjelaskan kegunaan atribut di setiap entity.