top down

8

BAB II

TINJAUAN PUSTAKA

2.1. Definisi Sistem Informasi, Administrasi, dan Skripsi

Sistem informasi terdiri dari dua suku kata, yaitu sistem dan informasi.

Sistem adalah serangkaian komponen yang saling berinteraksi untuk mencapai

suatu tujuan. Setiap sistem memiliki karakter yang unik yang membedakan sistem

tersebut dengan sistem lainnya. Setiap komponen dalam sistem memiki kontribusi

penting bagi sistem dan hilangnya salah satu komponen dalam sistem memiliki

dampak cukup besar terhadap perilaku sistem dalam mencapai tujuannya, (Belle,

2003).

Sedangkan definisi informasi menurut Davis dalam Gaol (2008) adalah data

yang telah diproses atau diolah ke dalam bentuk yang sangat berarti untuk

penerimanya dan merupakan nilai yang sesungguhnya atau dipahami dalam

tindakan atau keputusan yang sekarang atau nantinya. Sedangkan menurut

Murdick dalam Gaol (2008), informasi terdiri atas data yang telah didapatkan,

diolah / diproses, atau sebaliknya yang digunakan untuk tujuan

penjelasan/penerangan, uraian, atau sebagai dasar untuk pembuatan peramalan

atau pembuatan keputusan.

Sistem informasi adalah suatu sistem yang mengumpulkan dan mengolah

data untuk menghasilkan suatu informasi yang ditujukan kepada penggunanya,

(Belle, 2003). Definisi lain dari sistem informasi menurut O’Brien dalam

Christian (2010) adalah sistem terorganisisir dan terintegrasi yang

ADLN – PERPUSTAKAAN UNIVERSITAS AIRLANGGA

SKRIPSI ANALISIS DAN PERANCANGAN ... RENDRA BOMANTARA

9

mengumpulkan, memasukkan, dan memproses data serta menyimpan, mengelola,

mengontrol dan menyampaikan informasi, yang digunakan oleh organisasi untuk

mencapai tujuannya.

Haryadi (2009) berpendapat bahwa administrasi adalah kegiatan

penyusunan dan pencatatan data dan informasi secara sistematis dengan tujuan

untuk menyediakan keterangan serta memudahkan memperolehnya (informasi)

kembali secara keseluruhan dan dalam satu hubungan satu sama lain. Sedangkan

skripsi adalah karya tulis mahasiswa mengenai hasil penelitian eksploratif,

deskriptif, atau eksperimental untuk melatih mahasiswa dalam menuangkan hasil

kegiatan penelitiannya secara metodologis, logis, dan sistematis ke dalam suatu

karya ilmiah tertulis, (Pedoman Proposal dan Skripsi Fakultas Sains dan

Teknologi Universitas Airlangga, 2010).

2.2. Pengembangan sistem informasi

Pengembangan sistem informasi dapat diartikan menyusun suatu sistem

informasi yang baru untuk menggantikan sistem informasi yang lama secara

keseluruhan atau memperbaiki sistem yang telah ada. Menurut Belle (2003),

tahapan-tahapan dalam pengembangan sistem informasi antara lain :

a. Perencanaan Sistem

Pada tahap perencanaan sistem pengembang menentukan tujuan pembuatan

sistem baru, batasan sistem baru, mengidentifikasi permasalahan utama yang

menyebabkan organisasi membutuhkan adanya sistem baru dan memeriksa

solusi yang mungkin atas permasalahan tersebut.



10

b. Analisis Sistem

Pada tahap analisis sistem pengembang mengidentifikasi spesifikasi kebutuhan

sistem dari pengguna dan mengembangkan konsep penyelesaian permasalahan.

c. Perancangan Sistem

Pada tahap perancangan sistem pengembang membuat suatu rancangan

berdasarkan spesifikasi kebutuhan sistem dari pengguna yang diperoleh pada

tahap analisis.

d. Pembangunan Sistem

Pada tahap pembangunan sistem pengembang membangun sistem dengan

melakukan penerjemahan rancangan sistem yang dibuat pada tahap

perancangan ke dalam bentuk kode program.

e. Implementasi Sistem

Pada tahap implementasi sistem pengembang melakukan instalasi sistem baru

pada lingkungan pengguna, serta memberikan pelatihan pengguna mengenai

penggunaan sistem baru.

f. Pemeliharaan Sistem

Pada tahap pemeliharaan sistem pengembang melakukan permeliharaan sistem

yaitu dengan memperbaiki sistem jika terdapat fitur sistem yang mengalami

error.



11

2.3. Metode pengembangan sistem informasi

Menurut Sommerville dalam Booch (1994), metode pengembangan sistem

informasi terbagi atas 3 jenis metode yaitu :

a. Top-down structured design

Metode top-down structured design menerapkan algorithmic decomposistion

dalam penanganan masalah kompleksitas dalam pengembangan suatu sistem.

Algorithmic decomposistion fokus pada urutan atau prosedur sistem sehingga

kurang mendukung adanya perubahan dalam sistem, namun sebagian besar

sistem dan perangkat lunak telah dikembangkan dengan metode

perngembangan ini.

b. Data-driven design

Dalam metode data-driven design struktur sistem yang akan dikembangkan

berasal dari pemetaan sistem input dan output. Seperti metode terstruktur,

metode ini telah cukup banyak diterapkan oleh para pengembang, seperti pada

pengembangan sistem informasi manajemen yang melibatkan hubungan secara

langsung antara input dengan output pada sistem.

c. Object-oriented analysis and design

Metode object-oriented analysis and design menerapkan object-oriented

decomposistion dalam penanganan masalah kompleksitas dalam

pengembangan suatu sistem. Object-oriented decomposistion fokus pada

subjek dan operasi yang ditangani oleh subjek. Metode ini memodelkan sistem

sebagai kumpulan dari objek dimana objek itu sendiri merupakan bentuk

instance dari kelas dan kelas tersebut merupakan bagian dari hirarki kelas.



12

2.4. Metode Berorientasi Objek

2.4.1. Istilah-istilah penting dalam metode berorientasi objek

Menurut Booch (1994), terdapat tiga istilah penting yang melekat dalam

pengembangan metode berorientasi objek, yaitu :

a. Object-oriented analysis (OOA)

Object-oriented analysis adalah salah satu metode analisis yang

mengidentifikasi kebutuhan sistem dari perspektif kelas dan objek yang

ditemukan dalam pendefinisian masalah. Sedangkan menurut Nugroho (2005),

Object-oriented analysis adalah tahapan perangkat lunak dengan menentukan

spesifikasi sistem.

b. Object-oriented design (OOD)

Object-oriented design adalah salah satu metode perancangan yang meliputi

proses object-oriented decomposition dan bentuk notasi yang menggambarkan

struktur dari kelas dan objek serta rancangan arsitektur dari tiap modul dan

proses dalam sistem. Contoh bentuk notasi adalah Unified Modelling Language

(UML).

c. Object-oriented programming (OOP)

Object-oriented programming adalah salah satu metode implementasi dimana

setiap program diorganisasikan sebagai kumpulan dari objek dimana setiap

objek merupakan bentuk instance dari kelas dan kelas kelas tersebut

merupakan bagian dari hirarki kelas yang disatukan melaui hubungan

inheritance atau pewarisan.



13

2.4.2. Kelas dan objek

Kelas adalah sekumpulan objek yang berbagi struktur dan perilaku yang

sama. Objek adalah bentuk instance dari kelas. Setiap objek memiliki suatu

kondisi, perilaku dan identitas yang unik. Objek yang memiliki kemiripan dalam

perilaku didefinisikan dalam kelas yang sama (Booch,1994).

2.4.3. Elemen-elemen penting dalam metode berorientasi objek

Menurut Booch (1994), terdapat empat istilah penting yang melekat dalam

pengembangan metode berorientasi objek, yaitu :

a. Abstraction

Abstraction menggambarkan karakteristik penting dari suatu objek yang

membedakannya dengan objek lainnya serta dengan tegas memberikan batas-

batas konseptual yang relative dengan perspektif pembaca.

b. Encapsulation

Encapsulation adalah proses pengelompokkan elemen-elemen dalam proses

abstraksi yang membentuk struktur dan perilaku objek. Sedangkan menurut

Nugroho (2005), encapsulation merupakan penggabungan potongan-potongan

informasi dan perilaku-perilaku spesifik yang bekerja pada informasi tersebut

kemudian mengemasnya menjadi sesuatu yang disebut sebagai objek.

c. Modularity

Modularity adalah properti dari sistem yang telah didekomposisi menjadi

serangkaian kohesif dan kumpulan modul.



14

d. Hierarchy

Hierarchy adalah suatu pemeringkatan atau pengurutan dari abstraksi.

2.5. Unified Modeling Language (UML)

UML singkatan dari Unified Modelling Language yang berarti sebagai

bahasa pemodelan standar. Dalam pembuatan model menggunakan konsep UML

terdapat beberapa aturan yang harus diikuti seperti bagaimana membuat elemen-

elemen dalam model saling berhubungan harus mengikuti standar yang ada

(Widodo dkk, 2011). Widodo dkk (2011) mengatakan bahwa UML diaplikasikan

untuk beberapa tujuan tertentu, antara lain :

a. Merancang perangkat lunak.

b. Sarana komunikasi antara perangkat lunak dengan proses bisnis.

c. Menjabarkan sistem secara rinci untuk analisis dan mencari apa yang

dibutuhkan sistem.

d. Mendokumentasi sistem yang ada, proses-proses dan organisasinya.

UML menyediakan beberapa diagram sebagai model seperti use case

diagram, class diagram, activity diagram, sequence diagram, deployment

diagram, dan lain sebagainya.

2.5.1. Use Case Diagram

Use case diagram adalah diagram yang memperlihatkan himpunan use-case

dan actor yang menampilkan spesifikasi fungsional untuk mengorganisasikan dan

memodelkan perilaku sistem dan aksi yang menangkap seluruh kebutuhan



15

pengguna (Nugroho, 2005). Berikut adalah objek yang ada dalam use case

diagram :

a. Actor

Actor adalah seseorang atau sesuatu yang berinteraksi dengan sistem yang

sedang dikembangkan. Actor dapat berupa sebuah perangkat keras/komputer,

orang maupun obyek lain dalam sistem yang sama. Biasanya yang dilakukan

oleh actor adalah memberikan informasi pada sistem dan/atau memerintahkan

sistem untuk melakukan sesuatu. Actor disimbolkan dengan Gambar 2.1.

Gambar 2.1. Actor

b. Use Case

Use case adalah peringkat tertinggi dari fungsionalitas yang dimiliki oleh

sistem. Use case menggambarkan bagaimana actor akan menggunakan atau

memanfaatkan sistem. Use case disimbolkan dengan Gambar 2.2.

Gambar 2.2. Use Case

c. Asociation Relationship

Asociation Relationship adalah relasi yang terjadi antara actor dengan use case

yang berupa asosiasi, yang digambarkan dengan garis lurus dengan panah di

salah satu ujungnya. Asosiation Relationship disimbolkan dengan Gambar 2.3.



16

Gambar 2.3. Asociation Relationship

d. Include Relationship

Include relationship adalah relasi cakupan yang memungkinkan suatu use-case

menggunakan fungsionalitas yang disediakan use-case lain. Include

relationship disimbolkan dengan Gambar 2.4

Gambar 2.4 Include Relationship

e. Extends Relationship

Extend Relationship adalah relasi yang memungkinkan use case dapat

memperluas fungsionalitas yang disediakan use case lain. Extend relationship

disimbolkan dengan Gambar 2.5.

Gambar 2.5. Extend Relationship

f. Generalisation

Generalisation adalah relasi yang digunakan untuk memperlihatkan bahwa

beberapa actor atau use case memiliki sesuatu yang bersifat umum. Dengan

cara ini akan mengelompokkan sifat umum dari beberapa actor atau use case

Use-Case Use-Case 1

<<include>>

UseCase1UseCase

<<extend>>



17

menjadi actor atau use case tunggal yang dapat mewariskan sifat umumnya

kepada yang lain. Generalisation disimbolkan dengan Gambar 2.6.

Gambar 2.6. Generalisation

2.5.2 Activity diagram

Menurut Nugroho (2005), activity diagram adalah suatu cara untuk

memodelkan event-event yang terjadi dalam suatu use case. Diagram ini secara

esensial mirip dengan diagram alir (flowchart), memperlihatkan kendali aliran

kendali dari suatu aktifitas ke aktifitas lainnya. Berikut adalah elemen yang ada

pada activity diagram :

a. Activity State

Activity State adalah suatu aktivitas yang terjadi dalam sistem. Activity State

juga berperan dalam menggambarkan langkah-langkah dalam aliran kerja.

Activity state disimbolkan dengan Gambar 2.7.

Gambar 2.7. Activity State



18

b. Start State

Start State menggambarkan awal dimulainya suatu aliran kerja sistem sehingga

dalam pembuatan suatu activity diagram. Start state disimbolkan dengan

Gambar 2.8.

Gambar 2.8. Start State

c. End State

End State adalah penanda berakhirnya aliran kerja sistem sehingga dalam

pembuatan suatu activity diagram. End state disimbolkan dengan Gambar 2.9.

Gambar 2.9. End State

d. State Transition

State Transition memperlihatkan lintasan dari satu aksi atau aktifitas ke aksi

atau aktifitas berikutnya. State transition disimbolkan dengan Gambar 2.10.

Gambar 2.10. State Transition

e. Decision

Decision memperlihatkan dimana keputusan perlu diambil selama terjadi

aliran-aliran kerja. Decision disimbolkan dengan Gambar 2.11.



19

Gambar 2.11. Decision

f. Fork

Fork adalah fasilitas yang membagi aliran kerja tunggal menjadi dua atau lebih

aliran kerja. Fork digambarkan berupa sebuah bar dengan satu masukan transisi

dan dua atau lebih transisi keluaran. Fork disimbolkan dengan Gambar 2.12.

Gambar 2.12. Fork

g. Join

Join menggambarkan sinkronisasi dari dua atau lebih aliran kendali yang

konkuren. Join mungkin memiliki satu atau lebih transisi yang masuk dan

memiliki satu aliran keluar. Join disimbolkan dengan Gambar 2.13.

Gambar 2.13. Join

h. Swimlane

Swimlane memperlihatkan siapa yang bertanggung jawab untuk melaksanakan

tugas-tugas tertentu pada activity diagram. Swimlane disimbolkan dengan

Gambar 2.14.



20

Gambar 2.14. Swimlane

2.5.3 Class diagram

Menurut Nugroho (2005), Class diagram dapat memperlihatkan himpunan

kelas-kelas, antarmuka-antarmuka, kolaborasi-kolaborasi serta relasi-relasi. Selain

itu, diagram ini juga dibuat untuk melihat melihat hubungan antar kelas. Berikut

adalah beberapa unsur dalam class diagram :

a. Stereotype kelas

Stereotype kelas adalah mekanisme yang digunakan unutk menggolongkan

kelas-kelas (Nugroho, 2005). Berikut adalah beberapa unsur stereotype kelas :

1. Boundary class

Boundary class adalah kelas-kelas yang berada pada batasan antara sistem

dengan lingkungan. Kelas-kelas ini mencakup form-form, laporan-laporan,

antarmuka-antarmuka ke perangkat-perangkat keras seperti printer atau

scanner, serta antarmuka ke sistem yang lain. Boundary class disimbolkan

dengan Gambar 2.15.

Gambar 2.15. Boundary Class



21

2. Control Class

Control class merupakan kelas yang bertanggung jawab untuk

mengkordinasi upaya-upaya yang dilakukan kelas-kelas lainnya. Kelas ini

bersifat optional, kelas ini digunakan untuk mengendalikan urutan-urutan

event yang mengalir pada use-case. Control class disimbolkan dengan

Gambar 2.16.

Gambar 2.16. Control Class

3. Entity Class

Entity Class adalah kelas yang memelihara informasi-informasi yang akan

disimpan oleh sistem ke dalam tempat penyimpanan. Entity class

disimbolkan dengan Gambar 2.17.

Gambar 2.17. Entity Class

b. Atribut dan operasi

Atribut adalah informasi-informasi yang berkaitan dengan suatu kelas.

Sedangkan operasi merupakan perilaku yang berhubungan dengan suatu kelas

(Nugroho, 2005). Atribut dan operasi dapat memiliki salah satu sifat berikut :

1. Private

Atribut atau operasi yang bersifat private tersembunyi dari kelas-kelas lain

sehingga kelas-kelas lain tidak dapat mengakses dan memanfaatkannya.



22

Atribut atau operasi yang bersifat private, pada notasinya tedapat gambar

gembok.

2. Protected

Atribut atau operasi yang bersifat protected hanya dapat diakses oleh

anggota kelas yang bersangkutan serta kelas-kelas lain yang menjadi

turunannya dalam hierarki pewarisan (inheritance). Atribut atau operasi

yang bersifat protected, pada notasinya tedapat gambar kunci.

3. Public

Atribut atau operasi yang bersifat public tampak bagi semua kelas sehingga

dapat diakses dan dimanfaatkan oleh semua kelas yang ada.dapat dipanggil

oleh siapa saja.

c. Relasi antar Class

1. Assosiation Relationship

Assosiation relationship adalah koneksi semantik antara suatu kelas dengan

kelas yang lainnya (Nugroho, 2005). Bentuk notasinya digambarkan dengan

garis lurus yang menghubungkan antar kelas.

2. Dependency

Dependency merupakan relasi dimana suatu kelas menggunakan atau

memiliki pengetahuan terhadap kelas lainnya (Widodo, 2011). Bentuk

notasinya digambarkan dengan garis panah putus-putus dengan ujung panah

terbuka yang menghubungkan antar kelas.



23

3. Agregasi

Agregasi merupakan bentuk yang lebih kuat dari asosiasi. Agregasi adalah

relasi antara suatu keseluruhan ke bagian-bagiannya (Nugroho, 2005).

Bentuk notasinya digambarkan dengan garis panah dengan ujung panah

terbuka yang menghubungkan kelas keseluruhan (ditandai dengan tanda

intan atau diamond ) dengan kelas-kelas bagiannya.

4. Realizes Relationship

Realizes relationship digunakan untuk memperlihatkan relasi antara suatu

kelas dengan interface-nya, antara paket dengan interface-nya, antara

komponen dengan interface-nya, atau antara use case dengan realisasi use

case yang bersangkutan (Nugroho, 2005). Bentuk notasinya digambarkan

dengan garis panah putus-putus dengan ujung panah tertutup yang

menghubungkan antar kelas.

5. Generalisasi

Generalisasi diperlukan untuk memperlihatkan relasi atau hubungan

pewarisan antar unsur dalam diagram kelas (Nugroho, 2005). Bentuk

notasinya digambarkan dengan garis panah dengan ujung panah tertutup

yang mengubungkan kelas induk dengan kelas-kelas turunannya.

d. Multiplisitas relasi

Multiplisitas memberi petunjuk tentang banyaknya instansiasi suatu kelas

berhubungan dengan satu instansiasi kelas yang lain pada suatu waktu tertentu

(Nugroho, 2005). Notasi multiplisitas relasi dapat dilihat pada Tabel 2.1.



24

Tabel 2.1. Notasi Multiplisitas Relasi

Multiplitas Arti

* Banyak

0 Nol

1 Satu

0..* Nol atau banyak

1..* Satu atau banyak

0..1 Nol atau satu

1..1 Hanya satu

2.5.4 Sequence diagram

Sequence diagram memperlihatkan event-event yang berurutan sepanjang

berjalannya waktu. Setiap sequence diagram menggambarkan aliran-aliran pada

suatu use case. Diagram ini dapat dibaca dengan melihat pada objek-objek dan

pesan-pesan yang tergambar dalam diagram. Pesan-pesan diagambarkan diantara

garis hidup yang dimiliki dua objek untuk memperlihatkan bagaimana objek-

objek itu saling berkomunikasi (Nugroho, 2005). Berikut adalah beberapa elemen

yang ada pada sequence diagram :

a. Object

Object dalam diagram ini diambil dari class-class dalam class diagram. Notasi

object disimbolkan dengan Gambar 2.18.



25

Gambar 2.18. Object

b. Object Message

Object Message menggambarkan pesan antara dua objek. Bentuk notasinya

digambarkan dalam bentuk panah dengan ujung terbuka yang menhubungkan

objek satu dengan objek lain.

c. Message to Self

Message to Self menggambarkan pesan yang menuju objek itu sendiri. Bentuk

notasinya digambarkan dalam bentuk panah dengan ujung terbuka yang

menhubungkan objek satu dengan objek itu sendiri.

2.5.5 Component diagram

Component diagram memperlihatkan organisasi serta kebergantungan

sistem pada komponen-komponen yang telah ada sebelumnya. Diagram ini

berhubungan dengan diagram kelas dimana komponen secara tipikal dipetakan ke

dalam satu atau lebih kelas-kelas, antarmuka-antarmuka (interfaces), serta

kolaborasi-kolaborasi (Nugroho, 2005). Berikut adalah elemen yang ada pada

component diagram :

a. Component

Component adalah modul fisik kode. Component menggambarkan modul

perangkat lunak dengan antarmuka. Notasi component digambarkan pada

Gambar 2.19.



26

Gambar 2.19 : Component

b. Dependency

Hanya ada satu jenis relasi antar komponen, yaitu dependency, yang

menggambarkan bahwa suatu komponen bergantung pada komponen (atau

komponen-komponen lainnya). Notasi dependency digambarkan sebagai tanda

panah dengan garis putus-putus. Notasi dependency digambarkan pada Gambar

2.20.

Gambar 2.20 : Dependency

2.6. Evaluasi Rancangan

Perangkat lunak yang baik adalah hasil desain yang baik berdasarkan

requirements yang baik. Requirements yang berkualitas merupakan hasil dari

komunikasi yang efektif dan kerjasama antara pengembang dan pengguna

(Wiegers, 2010). Salah satu penentu kualitas perangkat lunak adalah validasi dari

kepuasan pengguna untuk memenuhi kebutuhan. Untuk mengetahui tingkat

kepuasan pengguna dapat digunakan metode wawancara atau komunikasi.

Komunikasi digunakan untuk mengetahui tingkat pemenuhan kebutuhan

pengguna. Dimana dalam proses komunikasi tersebut pengguna dapat

memberikan masukan dan saran guna pengembangan sistem yang lebih baik,

Component



27

sehingga dari metode komunikasi diperoleh gambaran yang rinci (Nugroho,

2005).

2.7. Prototipe

Prototipe adalah usaha untuk mewujudkan segala aspek dari konten

perangkat lunak. Aspek lain dari prototipe meliputi : current state of the art,

requirements, dan content (Arent dkk, 2007). Menurut wiegers (2010), terdapat

tiga tujuan utama dari prototipe yaitu memperjelas dan melengkapi kebutuhan,

mencari desain alterrnatif untuk perangkat lunak, dan sebagai cikal bakal produk

yang berkembang sehingga menjadi ultimate product. Wiegers (2010)

mengklasifikasikan prototype menjadi beberapa jenis antara lain :

1. Horizontal prototypes

Horizontal prototypes merupakan prototipe yang menggambarkan perilaku

sistem. Prototipe jenis ini disebut horisontal karena tidak menjelaskan ke dalam

semua lapisan arsitektur atau ke rincian sistem melainkan menggambarkan

antarmuka pengguna. Horisontal prototipe dapat menunjukkan pilihan

fungsional pengguna yang tersedia, tampilan dari antarmuka pengguna (warna,

tata letak, grafis, kontrol), dan arsitektur informasi (struktur navigasi).

2. Vertical prototypes

Vertical prototypes disebut juga sebagai prototipe struktural, prototype jenis ini

bekerja seperti sistem nyata karena menyentuh pada semua tingkat

implementasi sistem. Vertical prototypes bertujuan untuk mengetahui tentang

optimalisasi algoritma, mengevaluasi skema database.



top down

Documents