SIAPASI

ANALISA & PERANCANGAN SISTEM INFORMASI
Program Studi Sistem Informasi | DST@2020

KATA PENGANTAR
Bismillaahirrahmaanirrahiim
Alhamdulillahirobbil‘alamiin serta Puji dan Syukur penulis panjatkan kehadirat Allah

SWT atas segala Rahmat dan Ridho-Nya penulis dapat menyelesaikan Modul
Pembelajaran mata kuliah Analisa & Perancangan Sistem Informasi ini sebagai salah satu
bahan referensi untuk mendukung proses belajar mengajar mahasiswa.
Modul ini dirancang khusus untuk membantu mahasiswa memahami hal-hal yang
berkaitan dengan Analisa & Perancangan Sistem Informasi yang merupakan salah satu
mata kuliah wajib yang ada di Program Studi Sistem Informasi, Universitas Bina Sarana
Informatika.
Tujuan penulis membuat modul pembelajaran ini dimaksudkan sebagai literatur
teori dasar tentang Analisa & Perancangan Sistem Informasi. Isi modul ini disesuaikan
dengan silabus mata kuliah untuk pembahasan dalam satu semester.
Dalam penulisan dan menyelesaikan Modul Pembelajaran ini, penulis banyak
mendapat masukan dari berbagai pihak, dan secara khusus dalam kesempatan ini,
dengan segala kerendahan dan keikhlasan hati penulis mengucapkan rasa hormat dan
terima kasih yang sebesar-besarnya kepada :
1. Orang tua serta Saudara tercinta yang telah banyak memberikan bantuan dan
dorongan selama penulis menyelesaikan penulisan modul ini
2. Istri dan Anak-anak ku tercinta yang selalu memberikan dorongan dan motivasi bagi
penulis selama penyelesaian Modul ini.
3. Rekan-rekan dan Sahabat baik berada didalam maupun diluar lingkungan saya yang
telah memberi kritik, komentar maupun saran yang membangun untuk perbaikannya,
penulis mengucapkan terima kasih. Saran dan kritik yang sangat membantu dan
berguna adalah untuk penyelesaian isi dari modul ini.
Dengan izin dan ridho Allah SWT, semoga Modul Pembelajaran ini dapat memberikan
manfaat khususnya bagi penulis pribadi dan dapat memberikan sumbangsih ilmu bagi
mahasiswa dan orang lain yang membutuhkannya, dengan harapan akan semakin
berkembang wawasan dan keberagaman ilmu khususnya di bidang Analisa &
Perancangan Sistem Informasi.
Semua yang baik sumbernya dari Sang Maha Ilmu, Allah SWT...
Semua yang kurang baik sumbernya dari kealpaan dan kekhilafan hamba sebagai
makhluk-Nya...
Pontianak, Maret 2020

Penulis
Dedi Saputra, S.Pd, M.Kom
ii
DAFTAR ISI
KATA PENGANTAR ............................................................................................ ii

DAFTAR ISI.......................................................................................................... iii
PENDAHULUAN .................................................................................................. 1
BAB I TERMINOLOGI SISTEM ........................................................................... 1

1.1 Terminologi Analisa Sistem Informasi ................................................... 1
1.2 Konsep Dasar Sistem ............................................................................... 3
A. Definisi Sistem ..................................................................................... 3
B. Karakteristik Sistem ............................................................................ 4
C. Klasifikasi Sistem ................................................................................ 6
D. Pengembangan Sistem ....................................................................... 7
E. Prinsip Pengembangan Sistem .......................................................... 9
F. Siklus Hidup Pengembangan Sistem ................................................. 10
G. Pendekatan Pengembangan Sistem .................................................. 13
H. Metodologi Pengembangan Sistem ................................................... 17
I. Tools Pengembangan Sistem ............................................................. 17
J. Fungsi Analisis Sistem ........................................................................ 19
BAB II METODE PENGEMBANGAN SISTEM .................................................... 22

2.1 Metode Pengembangan Sistem ............................................................... 22
A. Definisi .................................................................................................. 22
B. Jenis Metode Pengembangan Sistem................................................ 22
2.2 Model Waterfall ......................................................................................... 24
2.3 Model Prototyping .................................................................................... 28
2.4 Model RAD (Rapid Application Development) ....................................... 29
2.5 Model Spiral .............................................................................................. 32
2.6 Model Iteratif ............................................................................................. 34
2.7 Object Oriented Technology .................................................................... 36
2.8 Metode End-User Devlopment ................................................................. 38
BAB III ANALISA SISTEM INFORMASI .............................................................. 39

3.1 Pendekatan Analisa Model Driven .......................................................... 39
3.2 Analisa Kebutuhan Sistem ...................................................................... 40
3.3 Metode Pengumpulan Data ..................................................................... 40
3.4 Perumusan Proses Bisnis ....................................................................... 43
BAB IV ENTITY RELATIONSHIP DIAGRAM (ERD), SPESIFIKASI FILE DAN

PENGKODEAN ................................................................................................ 45
4.1 Entity Relationship Diagram (ERD) ......................................................... 45
4.2 Spesifikasi File .......................................................................................... 52
4.3 Teknik Pengkodean .................................................................................. 53
BAB V UNIFIED MODELLING LANGUAGE (UML) ............................................ 56

5.1 Terminologi UML ...................................................................................... 56
5.2 Diagram Use Case .................................................................................... 58
5.3 Diagram Class ........................................................................................... 58
Program Studi Sistem Informasi | DST@2020 iii
5.4 Package dan Object.................................................................................. 60

5.5 Diagram Sequence ................................................................................... 61
5.6 Diagram Collaboration ............................................................................. 62
5.7 Diagram State Chart ................................................................................. 62
5.8 Diagram Activity ....................................................................................... 63
5.9 Diagram Component dan Deployment.................................................... 65
BAB VI ANALISA PERANCANGAN INPUT DAN OUTPUT ............................... 66

6.1 Perancangan Input ................................................................................... 66
6.2 Perancangan Output ................................................................................ 67
BAB VII PENGUJIAN PERANGKAT LUNAK ...................................................... 71

7.1 Pengujian Perangkat Lunak ..................................................................... 71
7.2 Pengujian Functional (Black Box) ........................................................... 74
7.3 Pengujian Structural (White Box) ............................................................ 75
7.4 Pengujian Basis Path ............................................................................... 75
Daftar Pustaka ..................................................................................................... 78
iv
PENDAHULUAN
Mata kuliah Analisa & Perancangan Sistem Informasi ini memiliki bobot 4 SKS adalah
salah satu Mata kuliah Wajib di Program Studi Sistem Informasi.
KOMPETENSI :
Setelah mengikuti mata kuliah ini, mahasiswa diharapkan akan terampil dalam:
1. Mengetahui dan memahami peranan konsep analisa sistem dan perancangan sistem
informasi
2. Mampu membuat dan menjelaskan konsep pengembangan system.
3. Mampu menggambarkan system baik yang berjalan maupun usulan dengan
menggunakan diagram alir data dan mengaplikasikannya dalam bentuk kamus data
serta merancang dokumen masukan maupun keluaran.
4. Mahasiswa mampu membuat presentasi yang menarik dan atraktif.
5. Mahasiswa mampu bekerja sama dalam kelompok kerja untuk menyelesaikan
makalah tugas ujian akhir semester (UAS).
6. Membuat presentasi dan memaparkan hasil riset di depan kelas kepada dosen
pengajar dengan sistematika yang baik dan tepat.
DESKRIPSI MATA KULIAH :

Matakuliah ini membahas materi tentang analisa system dan teknik merancang pada
sistem yang sudah terkomputerisasi maupun yang masih manual sehingga mampu
menggambarkan sistem secara konsep dan membuat analisa dalam bentuk makalah
secara berkelompok serta mampu mempresentasikan hasil analisa tersebut di kelas.
TUJUAN UMUM :
1. Mahasiswa mampu membuat makalah tentang sistem informasi manajemen pada
sebuah Organisasi.
2. Mahasiswa mampu mengaplikasikan satu model pengembangan system.
3. Mahasiswa mampu menggambarkan satu prosedur kemudian membuat gambar DFD
dan membuat rancangan input dan output baik internal maupun eksternal pada
sebuah organisasi, membuat kamus data untuk masing-masing dokumen dari
dokumen yang sudah di riset dan membuat contoh HIPo dan program flowchart dari
DAD usulan
BAB I
TERMINOLOGI SISTEM
1.1 Terminologi Analisa Sistem Informasi

Analisa berasal dari kata Yunani Kuno “analusis” yang berarti melepaskan. Analusis
terbentuk dari dua suku kata yaitu “ana” yang berarti kembali dan “luein” yang berarti
melepas. Sehingga pengertian analisa yaitu suatu usaha dalam mengamati secara detail
pada suatu hal atau benda dengan cara menguraikan komponen-komponen
pembentuknya atau menyusun komponen tersebut untuk dikaji lebih lanjut. Kata analisa
atau analisis banyak digunakan dalam berbagai bidang ilmu pengetahuan, baik ilmu
bahasa, alam dan ilmu sosial. Untuk mengkaji suatu permasalahan, dikenal dengan suatu
metode yang disebut dengan metode ilmiah. Disimpulkan analisa adalah suatu kegiatan
yang dimulai dari proses awal didalam mempelajari serta mengevaluasi suatu bentuk
permasalahan (case) yang ada.
Program Studi Sistem Informasi | DST@2020 1

Pengertian Analisa Menurut Para Ahli

Menurut Gorys Keraf, analisa adalah sebuah proses untuk memecahkan sesuatu
ke dalam bagian-bagian yang saling berkaitan satu sama lainnya. sedangkan menurut
Komarrudin mengatakan bahwa analisis merupakan suatu kegiatan berfikir untuk
menguraikan suatu keseluruhan menjadi komponen sehingga dapat mengenal tanda-
tanda dari setiap komponen, hubungan satu sama lain dan fungsi masing-masing dalam
suatu keseluruhan yang terpadu. Menurut kamus akuntansi yaitu bahwa analisa
merupakan sebuah kegiatan untuk evaluasi terhadap kondisi dari ayat-ayat yang berkaitan
dengan akuntansi dan alasan tentang perbedaan yang bisa muncul. Terakhir yaitu
menurut Robert J. Schreiter (1991) mengatakan analisa merupakan membaca teks,
dengan menempatkan tanda-tanda dalam interaksi yang dinamis dan pesan yang
disampaikan.
Dari beberapa pengertian analisa diatas dapat ditarik kesimpulan bahwa analisa
merupakan sekumpulan kegiatan, aktivitas dan proses yang saling berkaitan untuk
memecahkan masalah atau memecahkan komponen menjadi lebih detail dan
digabungkan kembali lalu ditarik kesimpulan. Bentuk dari kegiatan analisa salah satunya
yaitu merangkum data mentah menjadi sebuah informasi yang bisa disampaikan ke
khalayak. Segala macam bentuk analisis menggambarkan pola-pola yang konsisten di
dalam data, sehingga hasil analisa dapat dipelajari dan diterjemahkan dengan singkat dan
penuh makna. Analisa juga dapat diartikan sebagai sebuah penyelidikan terhadap suatu
peristiwa dengan tujuan mengetahui keadaan yang sebenarnya terjadi.
Belajar dari Para ahli yang telah mendefinisikan pengertian analisa maka sebuah
analisis data, proses dan hasil dari analisa biasanya dilakukan meliputi kegiatan seperti
mengorganisasikan data, mengelompokkan data, mengklasifikasi data, memaparkan data
dan menarik kesimpulan dari keseluruhan data tersebut. Mengorganisasikan data yaitu
berarti mengatur data-data yang telah diperoleh peneliti selama kegiatan penelitian
sedang berlangsung, sedangkan pengelompokan data yaitu mengelompokkan data mana
yang hendak dipakai dan data mana yang tidak dipakai. Mengklasifikasi data juga
mengelas-ngelaskan data sesuai kebutuhan. Memaparkan data yaitu menyampaikan hasil
proses analisis data dan menarik kesimpulan atas informasi dari data yang telah
disampaikan.
Sistem : hubungan satu unit dengan unit-unit lainnyayang saling berhubungan
satu sama lainnya dan yang tidak dapat dipisahkan serta menuju suatu
kesatuan dalam rangka mencapai tujuan yang telah ditetapkan Chr.
Jimmy L. Gaol (2008:9).
Informasi : data yang telah diklasifikasikan atau diolah atau di interpretasikan

untuk digunakan dalam proses pengambilan keputusan (Sutabri,
2012:22).
Analisis Sistem : Penguraian dari suatu sistem informasi yang utuh ke dalam bagian-
bagian komponennya dengan maksud untuk mengidentifikasikan dan
mengevaluasi permasalahan, kesempatan, hambatan yang terjadi dan
kebutuhan yang diharapkan sehingga dapat diusulkan perbaikan.

Tahap analisis dilakukan setelah tahap perencanaan sistem dan sebelum tahap
desain sistem. Tahap ini merupakan tahap yang kritis dan sangat penting, karena
kesalahan dalam tahap ini menyebabkan kesalahan pada tahap selanjutnya. Contoh :
Misalkan anda dihadapkan pada suatu sistem untuk menentukan seberapa jauh sistem
tersebut telah mencapai sasarannya. Jika sistem mempunyai beberapa kelemahan, anda
harus dapat menemukannya. Tugas ini yang disebut sebagai analisis sistem.
Tugas utama dari menganalisis sistem meliputi :
1. Menentukan lingkup sistem
2. Mengumpulkan fakta
3. Menganalisis fakta
4. Mengkomunikasikan temuan-temuan tersebut melalui laporan analisis sistem.
1.2 Konsep Dasar Sistem

A. Definisi Sistem
Sistem berasal dari bahasa Latin (systema) dan bahasa Yunani (sustema) adalah
suatu kesatuan yang terdiri komponen atau elemen yang dihubungkan bersama untuk
memudahkan aliran informasi, materi atau energi. Istilah ini sering dipergunakan untuk
menggambarkan suatu entitas yang berinteraksi.
Sistem juga merupakan kesatuan bagian-bagian yang saling berhubungan yang
berada dalam suatu wilayah serta memiliki item-item penggerak, contoh umum misalnya
seperti negara. Negara merupakan suatu kumpulan dari beberapa elemen kesatuan lain
seperti provinsi yang saling berhubungan sehingga membentuk suatu negara dimana
yang berperan sebagai penggeraknya yaitu rakyat yang berada dinegara tersebut.
Kata "sistem" banyak sekali digunakan dalam percakapan sehari-hari, dalam forum diskusi
maupun dokumen ilmiah. Kata ini digunakan untuk banyak hal, dan pada banyak bidang
pula, sehingga maknanya menjadi beragam. Dalam pengertian umum menurut beberapa
ahli bahwa definisi sistem adalah merupakan sekelompok elemen yang terintegrasi dan
bekerja sama untuk mencapai suatu tujuan. Jadi yang dimaksud dengan sistem bisa
berbentuk apa saja dan berada dimana saja. Sistem adalah kumpulan / group / komponen
apapun baik phisik yang saling berhubungan satu sama lain dan bekerja sama secara
harmonis untuk mencapai satu tujuan tertentu.
Terdapat dua kelompok pendekatan didalam mendefinisikan sistem, yaitu yang
menekankan pada prosedurnya dan yang menekankan pada komponen atau elemennya.
Pendekatan sistem yang lebih menekankan pada prosedur mendefinisikan sistem sebagai
berikut ini : “Suatu sistem adalah suatu jaringan kerja dari prosedur-prosedur yang saling
berhubungan, berkumpul bersama-sama untuk melakukan suatu kegiatan atau untuk
menyelesaikan suatu sasaran yang tertentu.”
Menurut Jerry Fitzgerald, Ardra F. Fitzgerald dan Warren D. Stallings, Jr.,
mendefinisikan prosedur sebagai berikut : Suatu prosedur adalah urut-urutan yang tepat
dari tahapan-tahapan instruksi yang menerangkan Apa (What) yang harus dikerjakan,
Siapa (Who) yang mengerjakannya, Kapan (When) dikerjakan dan Bagaimana (How)
mengerjakannya.
Pendekatan sistem yang lebih menekankan pada elemen atau komponennya
mendefiniskan sistem sebagai berikut ini : “Sistem adalah kumpulan dari elemen-elemen
yang berinteraksi untuk mencapai suatu tujuan tertentu.”
Kedua kelompok definisi tersebut adalah benar dan tidak bertentangan, yang
berbeda adalah cara pendekatannya. Pendekatan sistem yang merupakan kumpulan
elemen-elemen atau komponen-komponen atau subsistem-subsistem merupakan definisi
yang lebih luas. Definisi ini lebih banyak diterima, karena kenyataannya suatu sistem

dapat terdiri dari beberapa subsistem atau sistem bagian. Sebagai misal, sistem akuntansi
dapat terdiri dari beberapa subsistem-subsistem, yaitu subsistem akuntansi penjualan,
subsistem akuntansi pembelian, subsistem akuntansi penggajian, subsistem akuntansi
biaya dan lain sebagainya.
Apa itu Subsistem ? Subsistem sebenarnya hanyalah sistem di dalam suatu sistem,
ini berarti bahwa sistem berada pada lebih dari satu tingkat. Pemisalan lainnya, mobil
adalah suatu sistem yang terdiri dari sistem-sistem bawahan seperti sistem mesin, sistem
badan mobil dan sistem rangka. Masing-masing sistem ini terdiri dari sistem tingkat yang
lebih rendah lagi. Misalnya, sistem mesin adalah kombinasi dari sistem karburator, sistem
generator, sistem bahan bakar dan seterusnya.
Apa itu Supersistem ? Walaupun istilah supersistem jarang digunakan, sistem
seperti ini ada. Jika suatu sistem adalah bagian dari sistem yang lebih besar, sistem yang
lebih besar itu adalah supersistem. Contohnya, pemerintahan kota adalah suatu sistem,
tetapi ia juga merupakan bagian dari sistem yang lebih besar – pemerintahan propinsi.
Pemerintahan propinsi adalah supersistem dari pemerintahan kota dan juga merupakan
subsistem dari pemerintahan nasional. Dari definisi dan penjelasan diatas dapatlah
diambil kesimpulan, suatu sistem terdiri dari elemen yang bisa berbentuk individu atau
bagian-bagian yang terpisah, kemudian berinteraksi satu sama lain untuk mencapai
tujuan. Mobil terdiri dari bagian-bagian sistem yang berinteraksi/kerjasama untuk tujuan
mobil tersebut bergerak ke suatu arah. Keluarga, pertama kali terdiri dari 2 individu yang
terpisah yang mana individu itu sendiri merupakan suatu sistem yang terdiri dari
subsistem-subsistem, kemudian bersatu membentuk keluarga untuk mencapai suatu
tujuan. Keluarga itu sendiri merupakan subsistem dari sistem Rukun Tetangga (RT), RT
merupakan subsistem dari Rukun Warga (RW), RW subsistem dari suatu Kelurahan,
Kelurahan subsistem dari suatu Kecamatan, dan demikian seterusnya.
B. Karateristik Sistem
Suatu sistem mempunyai karakteristik atau sifat-sifat tertentu, yaitu
mempunyai komponen-komponen, batas sistem, lingkungan luar sistem, penghubung,
masukkan (input), keluaran (output), pengolahan(prosessing) dan sasaran(objectiv) atau
tujuan(goal). Gambaran dari karakteristik sistem dapat dilihat pada gambar berikut ini:
Gambar 1. Karakteristik suatu sistem

1. Komponen Sistem
Suatu sistem terdiri dari sejumlah komponen yang saling berinteraksi, yang artinya saling
bekerja sama membentuk satu kesatuan. Komponen-komponen sistem atau elemen-
elemen sistem dapat berupa suatu subsistem atau bagian-bagian dari sistem. Setiap
sistem tidak perduli betapapun kecilnya, selalu mengandung komponen-komponen atau
subsistem-subsistem. Setiap subsistem mempunyai sifatsifat dari sistem untuk
menjalankan suatu fungsi tertentu dan mempengaruhi proses sistem secara keseluruhan.
Jadi, dapat dibayangkan jika dalam suatu sistem ada subsistem yang tidak
berjalan/berfungsi sebagaimana mestinya. Tentunya sistem tersebut tidak akan berjalan
mulus atau mungkin juga sistem tersebut rusak sehingga dengan sendirinya tujuan sistem
tersebut tidak tercapai
2. Batas Sistem (Boundary)

Batas sistem (boundary) merupakan daerah yang membatasi antara suatu sistem dengan
sistem yang lainnya atau dengan lingkungan luarnya. Batas sistem ini memungkinkan
suatu sistem dipandang sebagai satu kesatuan. Batas suatu sistem menunjukkan ruang
lingkup (scope) dari sistem tersebut.
3. Lingkungan Luar Sistem (Environments)

Lingkungan luar dari suatu sistem adalah apapun diluar batas dari sistem yang
mempengaruhi operasi sistem. Lingkungan luar sistem dapat bersifat menguntungkan dan
dapat juga bersifat merugikan sistem tersebut. Lingkungan luar yang menguntungkan
merupakan energi dari sistem dan dengan demikian harus tetap dijaga dan dipelihara.
Sedang lingkungan luar yang merugikan harus ditahan dan dikendalikan, kalau tidak maka
akan menggangu kelangsungan hidup dari sistem.
4. Penghubung (Interface)
Sistem Penghubung sistem merupakan media penghubung antara satu subsistem dengan
subsistem lainnya. Melalui penghubung ini memungkinkan sumber-sumber daya mengalir
dari satu subsistem ke yang lainnya. Keluaran (output) dari satu subsistem akan menjadi
masukan (input) untuk subsistem lainnya dengan melalui penghubung. Dengan
penghubung satu subsistem dapat berintegrasi dengan subsistem yang lainnya
membentuk satu kesatuan.
5. Masukan (Input)
Sistem Masukan sistem adalah energi yang dimasukkan ke dalam sistem. Masukan dapat
berupa masukan perawatan (maintenance input) dan masukan sinyal (signal input).
Maintenance input adalah energi yang dimasukkan supaya sistem tersebut dapat
beroperasi. Signal input adalah energi yang diproses untuk didapatkan keluaran. Sebagai
contoh didalam sistem komputer, program adalah maintenance input yang digunakan
untuk mengoperasikan komputernya dan data adalah signal input untuk diolah menjadi
informasi.
6. Keluaran (Output)
Sistem Keluaran sistem adalah hasil dari energi yang diolah dan diklasifikasikan menjadi
keluaran yang berguna dan sisa pembuangan. Keluaran dapat merupakan masukan untuk
subsistem yang lain atau kepada supersistem. Misalnya untuk sistem komputer, panas
yang dihasilkan adalah keluaran yang tidak berguna dan merupakan hasil sisa
pembuangan, sedang informasi adalah keluaran yang dibutuhkan.

7. Pengolah (Process)
Sistem Suatu sistem dapat mempunyai suatu bagian pengolah yang akan merubah
masukan menjadi keluaran. Suatu sistem produksi akan mengolah masukan berupa
bahan baku dan bahan-bahan yang lain menjadi keluaran berupa barang jadi. Sistem
akuntansi akan mengolah data-data transaksi menjadi laporan-laporan keuangan dan
laporan-laporan lain yang dibutuhkan oleh manajemen.
8. Sasaran (Objectives) atau Tujuan (Goal)

Suatu sistem pasti mempunyai tujuan atau sasaran. Kalau suatu sistem tidak mempnyai
sasaran, maka operasi sistem tidak akan ada gunanya. Sasaran dari sistem sangat
menentukan sekali masukan yang dibutuhkan sistem dan keluaran yang akan dihasilkan
sistem. Suatu sistem dikatakan berhasil bila mengenai sasaran atau tujuannya.
Perbedaan suatu sasaran (objectives) dan suatu tujuan (goal) adalah, goal biasanya
dihubungkan dengan ruang lingkup yang lebih luas dan sasaran dalam ruang lingkup yang
lebih sempit. Bila merupakan suatu sistem utama, seperti misalnya sistem bisnis
perusahaan, maka istilah goal lebih tepat diterapkan. Untuk sistem akuntansi atau sistem-
sistem lainnya yang merupakan bagian atau subsistem dari sistem bisnis, maka istilah
objectives yang lebih tepat. Jadi tergantung dari ruang lingkup mana memandang sistem
tersebut. Seringkali tujuan (goal) dan sasaran (objectives) digunakan bergantian dan tidak
dibedakan
C. Klasifikasi Sistem
Sistem dapat diklasifikasikan dari beberapa sudut pandang, diantaranya sebagai
berikut ini :
1. Sistem diklasifikasikan sebagai sistem abstrak (abstract system) dan sistem fisik
(physical system). Sistem abstrak adalah sistem yang berupa pemikiran atau ide-
ide yang tidak tampak secara fisik. Misalnya sistem teologia, yaitu sistem yang
berupa pemikiran-pemikiran hubungan antara manusia dengan Tuhan. Sistem fisik
merupakan sistem yang ada secara fisik. Misalnya sistem komputer, sistem
akuntansi, sistem produksi dan lain sebagainya.
2. Sistem diklasifikasikan sebagai sistem alamiah (natural system) dan sistem buatan
manusia (human made system) Sistem alamiah adalah sistem yang terjadi melalui
proses alam, tidak dibuat manusia. Misalnya sistem perputaran bumi. Sistem
buatan manusia adalah sistem yang dirancang oleh manusia. Sistem buatan
manusia yang melibatkan interaksi antara manusia dengan mesin disebut dengan
human-machine system atau ada yang menyebut dengan man-machine system.
Sistem informasi merupakan contoh man-machine system, karena menyangkut
penggunaan komputer yang berinteraksi dengan manusia.
3. Sistem diklasifikasikan sebagai sistem tertentu (deterministic system) dan sistem
tak tentu (probabilistic system) Sistem tertentu beroperasi dengan tingkah laku
yang sudah dapat diprediksi. Interaksi diantara bagian-bagiannya dapat dideteksi
dengan pasti, sehingga keluaran dari sistem dapat diramalkan. Sistem komputer
adalah contoh dari sistem tertentu yang tingkah lakunya dapat dipastikan
berdasarkan programprogram yang dijalankan. Sistem tak tentu adalah sistem yang
kondisi masa depannya tidak dapat diprediksi karena mengandung unsur
probabilitas.
4. Sistem diklasifikasikan sebagai sistem tertutup (closed system) dan sistem terbuka
(open system) Sistem tertutup merupakan sistem yang tidak berhubungan dan tidak
terpengaruh dengan lingkungan luarnya. Sistem ini bekerja secara otomatis tanpa

adanya turut campur tangan dari pihak diluarnya. Secara teoritis sistem tertutup ini
ada, tetapi kenyataannya tidak ada sistem yang benar-benar tertutup, yang ada
hanyalah relatively closed system (secara relatif tertutup, tidak benar-benar
tertutup). Sistem terbuka adalah sistem yang berhubungan dan terpengaruh
dengan lingkungan luarnya. Sistem ini menerima masukan dan menghasilkan
keluaran untuk lingkungan luar atau subsistem yang lainnya. Karena sistem
sifatnya terbuka dan terpengaruh oleh lingkungan luarnya, maka suatu sistem
harus mempunyai suatu sistem pengendalian yang baik. Sistem yang baik harus
dirancang sedemikian rupa, sehingga secara relatif tertutup karena sistem tertutup
akan bekerja secara otomatis dan terbuka hanya untuk pengaruh yang baik saja.
Klasifikasi sistem terbuka dan tertutup dapat digambarkan sebagai berikut :
Gambar 2. Sistem Terbuka
Gambar 3. Sistem Tertutup
Suatu sistem yang dihubungkan dengan lingkungannya melalui arus sumber daya disebut
sistem terbuka. Sebuah sistem pemanas atau pendingin ruangan, contohnya,
mendapatkan input-nya dari perusahaan listrik, dan menyediakan panas/dinginnya bagi
ruangan yang ditempatinya. Dengan menggunakan logika yang sama, suatu sistem yang
tidak dihubungkan dengan lingkungannya adalah sistem tertutup. Sebagai contohnya,
sistem tertutup hanya terdapat pada situasi laboratorium yang dikontrol ketat.
D. Pengembangan Sistem
Pengembangan sistem (systems development) dapat berarti menyusun suatu sistem
yang baru untuk menggantikan sistem yang lama secara keseluruhan atau memperbaiki
sistem yang telah ada. Sistem yang lama perlu diperbaiki atau diganti disebabkan karena
beberapa hal, yaitu sebagai berikut ini:
a. Adanya permasalahan-permasalahan (problems) yang timbul di sistem yang lama
yang dapat berupa ketidakberesan. Ketidakberesan dalam sistem yang lama
menyebabkan sistem yang lama tidak dapat beroperasi sesuai dengan yang
diharapkan. Ketidakberesan ini dapat berupa :
▪ kecurangan-kecurangan disengaja yang menyebabkan tidak amannya harta
kekayaan perusahaan dan kebenaran dari data menjadi kurang terjamin;

▪ kesalahan-kesalahan yang tidak disengaja yang juga dapat menyebabkan

kebenaran dari data kurang terjamin;
▪ tidak efisiennya operasi;
▪ tidak ditaatinya kebijaksanaan manajemen yang telah ditetapkan.
Pertumbuhan organisasi Pertumbuhan organisasi yang menyebabkan harus

disusunnya sistem yang baru. Pertumbuhan organisasi diantaranya adalah kebutuhan
informasi yang semakin luas, volume pengolahan data semakin meningkat, perubahan
prinsip akuntansi yang baru. Karena adanya perubahan ini, maka menyebabkan
sistem yang lama tidak efektif lagi, sehingga sistem yang lama sudah tidak dapat
memenuhi lagi semua kebutuhan informasi yang dibutuhkan manajemen.
b. Untuk meraih kesempatan-kesempatan (opportunities)

Teknologi informasi telah berkembang dengan cepatnya. Perangkat keras komputer,
perangkat lunak dan teknologi komunikasi telah begitu cepat berkembang. Organisasi
mulai merasakan bahwa teknologi informasi ini perludigunakan untuk meningkatkan
penyediaan informasi sehingga dapat mendukung dalam proses pengambilan
keputusan yang akan dilakukan oleh manajemen. Dalam keadaaan pasar bersaing,
kecepatan informasi atau efisiensi waktu sangat menentukan berhasil atau tidaknya
strategi dan rencana-rencana yang telah disusun untuk meraih kesempatan-
kesempatan yang ada. Bila pesaing dapat memanfaatkan teknologi ini, maka
kesempatan-kesempatan akan jatuh ke tangan pesaing. Kesempatan-kesempatan ini
dapat berupa peluang-peluang pasar, pelayanan yang meningkat kepada langganan
dan lain sebagainya.
c. Adanya instruksi-instruksi (directives)

Penyusunan sistem yang baru dapat juga terjadi karena adanya instruksi-instruksi dari
atas pimpinan ataupun dari luar organisasi, seperti misalnya peraturan pemerintah.
Berikut ini dapat digunakan sebagai indikator adanya permasalahanpermasalahan dan
kesempatan-kesempatan yang dapat diraih, sehingga menyebabkan sistem yang
lama harus diperbaiki, ditingkatkan bahkan diganti keseluruhannya. Indikator-indikator
ini diantaranya adalah sebagai berikut : keluhan dari langganan; pengiriman barang
yang sering tertunda; pembayaran gaji yang terlambat; laporan yang tidak tepat
waktunya; isi laporan yang sering salah; tanggung jawab yang tidak jelas; waktu kerja
yang berlebihan; ketidakberesan kas; produktifitas tenaga kerja yang rendah;
banyaknya pekerja yang menganggur; kegiatan yang tumpang tindih; tanggapan yang
lambat terhadap langganan; kehilangan kesempatan kompetisi pasar; kesalahan-
kesalahan manual yang tinggi; persediaan barang yang terlalu tinggi; pemesanan
kembali barang yang tidak efisien; biaya operasi yang tinggi; file-file yang kurang
teratur; keluhan dari supplier karena tertundanya pembayaran; bertumpuknya back-
order (tertundanya pengiriman karena kurangnya persediaan barang); investasi yang
tidak efisisen; peramalan penjualan dan produksi tidak tepat; kapasitas produksi yang
menganggur (idle capasities); pekerjaan manajer yang terlalu teknis; dll.
Proses pengembangan sistem dapat digambarkan sebagai berikut :

Gambar 4. Proses Pengembangan Sistem
Dengan telah dikembangkannya sistem yang baru, maka diharapkan akan terjadi
peningkatan-peningkatan di sistem yang baru. Peningkatan-peningkatan ini berhubungan
dengan Performance, Information, Economy, Control, Efficiency, and Service (PIECES).
▪ Performance (kinerja), peningkatan terhadap kinerja (hasil kerja) sistem yang baru
sehingga menjadi lebih efektif. Kinerja dapat diukur dari throughput dan response time.
Throughput adalah jumlah dari pekerjaan yang dapat dilakukan suatu saat tertentu.
Response time adalah rata-rata waktu yang tertunda diantara dua transaksi atau
pekerjaan ditambah dengan waktu response untuk menanggapi pekerjaan tersebut.
▪ Information (informasi), peningkatan terhadap kualitas informasi yang disajikan.
▪ Economy (ekonomis), peningkatan terhadap manfaat-manfaat atau
keuntungankeuntungan atau penurunan-penurunan biaya yang terjadi.
▪ Control (pengendalian), peningkatan terhadap pengendalian untuk mendeteksi dan
memperbaiki kesalahan-kesalahan serta kecurangan-kecurangan yang dan akan
terjadi.
▪ Efficiency (efisiensi), peningkatan terhadap efisiensi operasi. Efisiensi berbeda dengan
ekonomis. Bila ekonomis berhubungan dengan jumlah sumber daya yang digunakan,
efisiensi berhubungan dengan bagaimana sumber daya tersebut digunakan dengan
pemborosan yang paling minimum. Efisiensi dapat diukur dari outputnya dibagi dengan
inputnya.
▪ Services (pelayanan), peningkatan terhadap pelayanan yang diberikan oleh sistem.
E. Prinsip Pengembangan Sistem

1. Sistem yang dikembangkan adalah untuk manajemen
2. Sistem yang dikembangkan adalah investasi modal yang besar a. Semua alternatif
yang ada harus diinvestigasi b. Investasi yang terbaik harus bernilai
3. Sistem yang dikembangkan memerlukan orang yang terdidik
4. Tahapan kerja dan tugas-tugas yang harus dilakukan dalam proses pengembangan
sistem
5. Proses pengembangan sistem tidak harus urut
6. Jangan takut membatalkan proyek
7. Dokumentasi harus ada untuk pedoman dalam pengembangan sistem

F. Siklus Hidup Pengembangan Sistem

Pengembangan sistem informasi yang berbasis komputer dapat merupakan tugas
kompleks yang membutuhkan banyak sumber daya dan dapat memakan waktu berbulan-
bulan bahkan bertahun-tahun untuk menyelesaikannya. Proses pengembangan sistem
melewati beberapa tahapan dari mulai sistem itu direncanakan sampai dengan sistem
tersebut diterapkan, dioperasikan dan dipelihara. Bila operasi sistem yang sudah
dikembangkan masih timbul kembali permasalahan-permasalahan yang kritis serta tidak
dapat diatasi dalam tahap pemeliharaan sistem, maka perlu dikembangkan kembali suatu
sistem untuk mengatasinya dan proses ini kembali ke tahap yang pertama, yaitu tahap
perencanaan sistem. Siklus ini disebut dengan siklus hidup suatu sistem (systems life
cycle). Daur atau siklus hidup dari pengembangan sistem merupakan suatu bentuk yang
digunakan untuk menggambarkan tahapan utama dan langkah-langkah di dalam tahapan
tersebut dalam proses pengembangannya. Dari sekian banyak siklus pengembangan
sistem menurut beberapa penulis sejak tahun 1970-an, diambil salah satu yang akan
menjadi acuan kita mengenai pengembangan sistem ini, yaitu menurut John Burch, Gary
Grudnitski, Information Systems, Theory and Practice (New York: John Wiley & Sons)
yang menuliskan tahapan pengembangan sistem sebagai berikut :
1. Kebijakan dan perencanaan sistem (system policy and planning).
2. Pengembangan sistem (system development)
a. Analisis sistem (system analysis)
b. Desain sistem secara umum (general system design)
c. Penilaian sistem (system evaluation)
d. Desain sistem terinci (detailed system design)
e. Implementasi sistem (system implementation)
3. Manajemen sistem dan operasi (system management and operation)
Gambar 5. Tahapan Pengembangan Sistem
1. Kebijakan dan perencanaan sistem (system policy and planning).

Sebelum suatu sistem informasi dikembangkan, umumnya terlebih dahulu dimulai
dengan adanya suatu kebijakan dan perencanaan untuk mengembangkan sistem itu.

Tanpa adanya perencanaan sistem yang baik, pengembangan sistem tidak akan
dapat berjalan sesuai dengan yang diharapkan. Tanpa adanya kebijakan
pengembangan sistem oleh manajemen puncak (top management),
makapengembangan sistem tidak akan mendapat dukungan dari manajemen puncak
ini. Padahal dukungan dari manajemen puncak sangat penting artinya. Kebijakan
sistem (systems policy) merupakan landasan dan dukungan dari manajemen puncak
untuk membuat perencanaan sistem. Perencanaan sistem (systems planning)
merupakan pedoman untuk melakukan pengembangan sistem. Kebijakan untuk
mengembangkan sistem informasi dilakukan oleh manajemen puncak karena
manajemen menginginkan untuk meraih kesempatan-kesempatan yang ada yang
tidak dapat diraih oleh sistem yang lama atau sistem yang lama mempunyai banyak
kelemahan-kelemahan yang perlu diperbaiki (misalnya untuk meningkatkan efektifitas
manajemen, meningkatkan produktivitas atau meningkatkan pelayanan yang lebih
baik kepada langganan). Partisipasi dan keterlibatan manajemen puncak masih
diharapkan untuk keberhasilan sistem yang akan dikembangkan. Untuk itu
manajemen puncak dilengkapi dengan suatu tim penasehat yang disebut dengan
komite pengarah (steering commitee) yang umumnya dibentuk dari wakil-wakil
pimpinan dari masing-masing departemen pemakai sistem seperti misalnya manajer-
manajer departemen atau manajer-manajer divisi. Seringkali komite ini diketuai sendiri
oleh direktur utama. Tugas komite ini adalah sebagai berikut :
a. Mengkaji, menyetujui atau membuat rekomendasi yang berhubungan dengan
perencanaan sistem, proyek-proyek sistem serta pengadaan perangkat keras,
perangkat lunak dan fasilitas-fasilitas lainnya.
b. Mengkoordinasi pelaksanaan proyek sistem sesuai dengan rencananya.
c. Memonitor atau mengawasi kemajuan dari proyek sistem.
d. Menilai kinerja dari fungsi-fungsi sistem yang telah dikembangkan.
e. Memberikan saran-saran dan petunjuk-petunjuk terhadap proyek sistem yang
sedang dikembangkan, terutama yang berhubungan dengan pencapaian sasaran
sistem, sasaran perusahaan dan juga terhadap kendala-kendala yang dihadapi.
Setelah manajemen puncak menetapkan kebijakan untuk mengembangkan sistem
informasi, sebelum sistem ini sendiri dikembangkan, maka perlu direncanakan
terlebih dahulu dengan cermat. Perencanaan sistem (systems planning) ini
menyangkut estimasi dari kebutuhan-kebutuhan fisik, tenaga kerja dan dana yang
dibutuhkan untuk mendukung pengembangan sistem ini serta untuk mendukung
operasinya setelah diterapkan. Perencanaan sistem dapat terdiri dari perencanaan
jangka pendek (short-range) dan perencanaan jangka panjang (long-range).
Perencanaan jangka pendek meliputi periode 1 sampai 2 tahun. Perencanaan
jangka panjang melingkupi periode sampai dengan 5 tahun. Karena
perkembangan teknologi komputer yang sangat cepat, maka perencanaan
pengembangan sistem informasi untuk periode yang lebih dari 5 tahun sudah tidak
tepat lagi.
Proses perencanaan sistem dikelompokkan menjadi 3 proses utama, yaitu :

1. Merencanakan proyek-proyek sistem yang akan dilakukan oleh staf perencana sistem.
2. Menentukan proyek-proyek sistem yang akan dikembangkan yang dilakukan oleh
komite.
3. Mendefinisikan proyek-proyek sistem dikembangkan yang dilakukan oleh analis
sistem.

Tahapan dari proses perencanaan sistem untuk ketiga bagian tersebut dapat dilihat pada
gambar berikut ini :
Gambar 6. Tahapan Perencanaan Sistem
2. Pengembangan sistem (system development)

a. Analisis sistem (system analysis)
Penelitian atas sistem yang telah ada dengan tujuan untuk merancang sistem yang
baru atau diperbarui.
b. Desain sistem secara umum (general system design)
Tujuan dari desain sistem secara umum adalah untuk memberikan gambaran
secara umum kepada user tentang sistem yang baru.
c. Penilaian sistem (system evaluation)
Hasil desain sistem secara umum tentunya harus menjadi pertimbangan pihak
manajemen apakah melanjutkan pengembangan sistem yang baru berdasarkan
gambaran desain sistem secara umum atau menolak rancangan baru tersebut.
d. Desain sistem terinci (detailed system design)
Dengan memahami sistem yang ada dan persyaratan-persyaratan sistem baru,
selanjutnya adalah penentuan proses dan data yang diperlukan oleh sistem baru.
Jika sistem itu berbasis komputer, rancangan harus menyertakan spesifikasi jenis
peralatan yang akan digunakan.
e. Implementasi sistem (system implementation) Merupakan kegiatan memperoleh
dan mengintegrasikan sumber daya fisik dan konseptual yang menghasilkan suatu
sistem yang bekerja.
3. Manajemen sistem dan operasi (system management and operation)
Pemeliharaan sistem (systems maintenance ) dilaksanakan untuk 3 alasan :
a. Memperbaiki kesalahan Penggunaan sistem mengungkapkan kesalahan (bugs)
dalam program atau kelemahan rancangan yang tidak terdeteksi dalam pengujian
sistem. Kesalahan-kesalahan ini dapat diperbaiki.

b. Menjaga kemutakhiran sistem Dengan berlalunya waktu, terjadi perubahan-

perubahan dalam lingkungan sistem yang mengharuskan modifikasi dalam
rancangan atau perangkat lunak. Contohnya, pemerintah mengubah rumus
perhitungan pajak jaminan sosial.
c. Meningkatkan sistem Saat sistem digunakan, akan ditemukan cara-cara membuat
peningkatan sistem. Saran-saran ini diteruskan kepada spesialis informasi yang
memodifikasi sistem sesuai saran tersebut. Pada titik tertentu, modifikasi sistem
akan menajdi sedemikian rupa, sehingga lebih baik memulai dari awal. Lalu, siklus
hidup sistem akan terulang.
G. Pendekatan Pengembangan Sistem

Terdapat beberapa pendekatan untuk mengembangkan sistem, yaitu sebagai berikut
ini :
1. Pendekatan klasik lawan pendekatan terstruktur (dipandang dari metodologi yang
digunakan) Metodologi pendekatan klasik mengembangkan sistem dengan
mengikuti tahapan-tahapan di systems life cycle. Pendekatan ini menekankan
bahwa pengembangan sistem akan berhasil bila mengikuti tahapan di systems life
cycle. Akan tetapi sayangnya, didalam praktek, hal ini tidaklah cukup, karena
pendekatan ini tidak memberikan pedoman lebih lanjut tentang bagaimana
melakukan tahapan-tahapan tersebut dengan terinci karena pendekatan ini tidak
dibekali dengan alat-alat dan teknik-teknik yang memadai. Sedangkan pendekatan
terstruktur yang baru muncul sekitar awal tahun 1970-an pada dasarnya mencoba
menyediakan kepada analis sistem tambahan alat-alat dan teknik-teknik untuk
mengembangkan sistem disamping tetap mengikuti ide dari systems life cycle.
Karena sifat dari sistem informasi sekarang menjadi lebih kompleks, pendekatan
klasik tidak cukup digunakan untuk mengembangkan suatu sistem informasi yang
sukses dan akan menimbulkan beberapa permasalahan. Permasalahan-
permasalahan yang dapat timbul di pendekatan klasik antara lain adalah sebagai
berikut :
a. Pengembangan perangkat lunak akan menjadi sulit Pendekatan klasik kurang
memberikan alat-alat dan teknik-teknik di dalam mengembangkan sistem dan
sebagai akibatnya proses pengembangan perangkat lunak menjadi tidak terarah
dan sulit untuk dikerjakan oleh pemrogram. Lain halnya dengan pendekatan
terstruktur yang memberikan alat-alat seperti diagram arus data (data flow
diagram), kamus data (data dictionary), tabel keputusan (decision table),
diagram IPO dan bagan terstruktur (structured chart) dan lain sebagainya yang
memungkinkan pengembangan perangkat lunak lebih terarah berdasarkan alat-
alat dan teknik-teknik tersebut.
b. Biaya perawatan atau pemeliharaan sistem akan menjadi lebih mahal Biaya
pengembangan sistem yang termahal adalah terletak di tahap perawatannya.
Mahalnya biaya perawatan di pendekatan klasik ini disebabkan karena
dokumentasi sistem yang dikembangkan kurang lengkap dan kurang terstruktur.
Dokumentasi ini merupakan hasil dari alat-alat dan teknik-teknik yang
digunakan. Karena pendekatan klasik kurang didukung dengan alat-alat dan
teknik-teknik, maka dokumentasi menjadi tidak lengkap dan walaupun ada tetapi
strukturnya kurang jelas, sehingga pada waktu pemeliharaan sistem menjadi
kesulitan.
c. Kemungkinan kesalahan sistem besar Pendekatan klasik tidak menyediakan
kepada analis sistem cara untuk melakukan pengetesan sistem, sehingga

kemungkinan kesalahan-kesalahan sistem akan menjadi lebih besar. Berbeda

dengan pendekatan terstruktur yang pengembangan sistemnya dilakukan dalam
bentuk modul-modul yang terstruktur. Modul-modul ini akan lebih mudah dites
secara terpisah dan kemudian pengetesan dapat dilakukan pada integrasi
semua modul untuk meyakinkan bahwa interaksi antar modul telah berfungsi
semestinya. Pengetesan sistem sebelum diterapkan merupakan hal yang kritis
karena koreksi kesalahan sistem setelah diterapkan akan mengakibatkan
pengeluaran biaya yang lebih besar. Beberapa penelitian menunjukkan bahwa
sistem yang tidak dites selama tahap pengembangannya merupakan sumber
utama dari kesalahan-kesalahan sistem.
d. Keberhasilan sistem kurang terjamin Penekanan dari pendekatan klasik adalah
kerja dari personil-personil pengembang sistem, bukan pada pemakai sistem,
padahal sekarang sudah disadari bahwa dukungan dan pemahaman dari
pemakai sistem terhadap sistem yang sedang dikembangkan merupakan hal
yang vital untuk keberhasilan proyek pengembangan sistem pada akhirnya.
Salah satu kontribusi utama pendekatan terstruktur adalah partisipasi dan
dukungan dari pemakai sistem. Pendekatan klasik mengasumsikan bahwa
analis sistem telah mengerti akan kebutuhan-kebutuhan pemakai sistem dengan
jelas dan benar. Pengalaman telah menunjukkan bahwa di beberapa kasus,
kebutuhan-kebutuhan pemakai sistem tidaklah selalu jelas dan benar menurut
analis sistem. Pendekatan klasik kurang melibatkan pemakai sistem dalam
pengembangan sistem, maka kebutuhan-kebutuhan pemakai sistem menjadi
kurang sesuai dengan yang diinginkan dan sebagai akibatnya sistem yang
diterapkan menjadi kurang berhasil.
e. Masalah dalam penerapan sistem Karena kurangnya keterlibatan pemakai
sistem dalam tahapan pengembangan sistem, maka pemakai sistem hanya
akan mengenal sistem yang baru pada tahap diterapkan saja. Sebagai
akibatnya pemakai sistem akan menjadi kaget dan tidak terbiasa dengan sistem
baru yang tiba-tiba dikenalkan. Sebagai akibat lebih lanjut, pemakai sistem akan
menjadi frustasi karena tidak dapat mengoperasikan sistem dengan baik.
2. Pendekatan sepotong lawan pendekatan sistem (dipandang dari sasaran yang

akan dicapai) Pendekatan sepotong (piecemeal approach) merupakan pendekatan
pengembangan sistem yang menekankan pada suatu kegiatan atau aplikasi
tertentu saja. Pada pendekatan ini, kegiatan atau aplikasi yang dipilih,
dikembangkan tanpa memperhatikan posisinya di sistem informasi atau tanpa
memperhatikan sasaran keseluruhan dari organisasi. Pendekatan in hanya
memperhatikan sasaran dari kegiatan atau aplikasi itu saja. Lain halnya dengan
pendekatan sistem (systems approach) yang memperhatikan sistem informasi
sebagai satu kesatuan terintegrasi untuk masing-masing kegiatan atau aplikasinya.
Pendekatan sistem ini juga menekankan pada pencapaian sasaran keseluruhan
dari organisasi, tidak hanya menekankan pada sasaran dari sistem informasi itu
saja.
3. Pendekatan bawah-naik lawan pendekatan atas-turun (dipandang dari cara

menentukan kebutuhan dari sistem) Pendekatan bawah naik (bottom-up approach)
dimulai dari level bawah organisasi, yaitu level operasional dimana transaksi
dilakukan. Pendekatan ini dimulai dari perumusan kebutuhan-kebutuhan untuk
menangani transaksi dan naik ke level atas dengan merumuskan kebutuhan

informasi berdasarkan transaksi tersebut. Pendekatan ini juga merupakan ciri-ciri

dari pendekatan klasik. Pendekatan bawah-naik bila digunakan pada tahap analisis
sistem disebut juga dengan istilah data analysis, karena yang menjadi tekanan
adalah data yang akan diolah terlebih dahulu, informasi yang akan dihasilkan
menyusul mengikuti datanya. Pendekatan atas-turun (top-down approach)
sebaliknya dimulai dari level atas organisasi, yaitu level perencanaan strategi.
Pendekatan ini dimulai dengan mendefinisikan sasaran dan kebijaksanaan
organisasi. Langkah selanjutnya dari pendekatan ini adalah dilakukannya analisis
kebutuhan informasi. Setelah kebutuhan informasi ditentukan, maka proses turun
ke pemrosesan transaksi, yaitu penentuan output, input, basis data, prosedur-
prosedur operasi dan kontrol. Pendekatan ini juga merupakan ciri-ciri dari
pendekatan terstruktur. Pendekatan atas-turun bila digunakan pada tahap analisis
sistem disebut juga dengan istilah decision analysis, karena yang menjadi tekanan
adalah informasi yang dibutuhkan untuk pengambilan keputusan oleh manajemen
terlebih dahulu, kemudian data yang perlu diolah didefinisikan menyusul mengikuti
informasi yang dibutuhkan.
4. Pendekatan sistem-menyeluruh lawan pendekatan moduler (dipandang dari cara

mengembangkannya) Pendekatan sistem-menyeluruh (total-system approach)
merupakan pendekatan yang mengembangkan sistem serentak secara
menyeluruh. Pendekatan ini kurang mengena untuk sistem yang komplek, karena
akan menjadi sulit untuk dikembangkan. Pendekatan ini juga merupakan ciri-ciri
dari pendekatan klasik. Pendekatan moduler (modular approach) berusaha
memecah sistem yang rumit menjadi beberapa bagian atau modul yang sederhana,
sehingga sistem akan lebih mudah dipahami dan dikembangkan. Akibat lebih lanjut
adalah sistem akan dapat dikembangkan tepat pada waktu yang telah
direncanakan, mudah dipahami oleh pemakai sistem dan mudah untuk dipelihara.
Pendekatan ini juga merupakan ciri-ciri dari pendekatan terstruktur.
5. Pendekatan lompatan-jauh lawan pendekatan berkembang (dipandang dari

teknologi yang akan digunakan Pendekatan lompatan-jauh (great loop approach)
menerapkan perubahan menyeluruh secara serentak menggunakan teknologi
canggih. Perubahan ini banyak mengandung resiko, karena teknologi komputer
begitu cepat berkembang dan untuk tahun-tahun mendatang sudah menjadi usang.
Pendekatan ini juga terlalu mahal, karena memerlukan investasi seketika untuk
semua teknologi yang digunakan dan pendekatan ini juga sulit untuk
dikembangkan, karena terlalu komplek. Pendekatan berkembang (evolutionary
approach) menerapkan teknologi canggih hanya untuk aplikasi-aplikasi yang
memerlukan saja pada saat itu dan akan terus dikembangkan untuk periode-
periode berikutnya mengikuti kebutuhannya sesuai dengan perkembangan
teknologi yang ada. Pendekatan berkembang menyebabkan investasi tidak terlalu
mahal dan dapat mengikuti perkembangan teknologi yang cepat, sehingga
teknologi yang digunakan tidak cepat menjadi usang.
H. Metodologi Pengembangan Sistem

Metodologi adalah kesatuan metode-metode, prosedur-prosedur, konsep-konsep
pekerjaan, aturanaturan dan postulat-postulat yang digunakan oleh suatu ilmu
pengetahuan, seni atau disiplin lainnya. Metode adalah suatu cara/teknik yang sistematik

untuk mengerjakan sesuatu. Metodologi pengembangan sistem yang ada biasanya dibuat
atau diusulkan oleh : penulis buku, peneliti, konsultan, systems house, pabrik software.
Metodologi pengembangan sistem diklasifikasikan menjadi 3 golongan:
1. Functional Decomposition Methodologies (Metodologi Pemecahan Fungsional).
Metodologi ini menekankan pada pemecahan dari sistem ke dalam subsitem-
subsistem yang lebih kecil, sehingga akan lebih mudah untuk dipahami, dirancang
dan diterapkan. Yang termasuk dalam kelompok metodologi ini adalah :
- HIPO (Hierarchy plus Input-Process-Output)
- SR (Stepwise Refinement) atau ISR (Iterative Stepwise Refinement)
- Information-Hiding.
2. Data Oriented Methodologies (Metodologi Orientasi Data) Metodologi ini
menekankan pada karakteristik dari data yang akan diproses. Metodologi ini dapat
dikelompokkan kembali ke dalam dua kelas, yaitu :
a. Data-flow oriented methodologies Metodologi ini secara umum didasarkan pada
pemecahan dari sistem kedalam modulo-modul berdasarkan dari tipe elemen
data dan tingkah-laku logika modul tersebut di dalam sistem. Dengan
metodologi ini, sistem secara logika dapat digambarkan secara logika dari arus
data dan hubungan antar fungsinya di dalam modul-modul disistem. Yang
termasuk dalam metodologi ini adalah - SADT (Structured Analisys and Design
Techniques) - Composite Design - SSAD (Structured Systems Analysis and
Design).
b. Data structure oriented methodologies Metodologi ini menekankan struktur dari
input dan output di sistem. Struktur ini kemudian akan digunakan sebagai dasar
struktur dari sistemnya. Hubungan fungsi antar modul atau elemen-elemen
sistem kemudian dijelaskan dari struktur sistemnya. Yang termasuk dalam
metodologi ini adalah : - JSD (Jackson’s systems development) - W/O (Warnier
/ Orr).
3. Prescriptive Methodologies
Yang termasuk dalam metodologi ini adalah :
▪ ISDOS (Information Systems Design and Optimization System) Kegunaannya
adalah mengotomatisasi proses pengembangan sistem informasi. ISDOS
mempunyai 2 komponen :
a. PSL Merupakan komponen utama dari ISDOS, yaitu suatu bahasa untuk
mencatat kebutuhan pemakai dalam bentuk machine-readable form, sehingga
output yang dihasilkannya dapat dianalisis oleh PSA. PSL merupakan bahasa
untuk menggambarkan sistemnya dan bukan merupakan bahasa pemrograman
prosedural.
b. PSA Merupakan paket perangkat lunak yang mirip dengan kamus data (data
dictionary) dan digunakan untuk mengecek data yang dimasukkan, yang
disimpan , yang dianalisis dan yang dihasilkan sebagai output laporan dengan
pemanfaatan DBMS dalam penyimpanan datanya. Kegunaan dan hasil dari
PSA adalah : PSA menganalisis PSL untuk kesalahan-kesalahan sintak dan
akan menghasilkan laporan-laporan dalam bentuk data dictionary, function
dictionary serta analisis dari hubungan-hubungan proses. Laporan dalam
bentuk grafik, seperti laporan yang menggambarkan hubungan dari proses
termasuk apakah suatu proses merupakan bagian dari porses yang lain atau
suatu proses mempunyai komponen proses-proses lain. PSA akan melakukan
analisis jaringan untuk mengecek kelengkapan dari semua hubungan data dan

proses-proses. PSA juga akan melakukan analisis dari hubungan

ketergantungan waktu dari data dan analisis dari spesifikasi volume.
▪ PLEXSYS Kegunaannya adalah untuk melakukan transformasi suatu statemen
bahasa komputer tingkat tinggi ke suatu executable code untuk suatu
konfigurasi perangkat keras yang diinginkan. PLEXSYS merupakan tambahan
untuk ISDOS. Kalau ISDOS digunakan pada aspek penntuan kebutuhan,
PLEXSYS digunakan pad aspek penghasil kode program secar otomatis.
▪ PRIDE Merupakan perangkat lunak terpadu yang baik untuk analisis/disain
sistem terstruktur, manajemen data, manajemen proyek dan
pendokumentasian.
▪ SDM/70 Merupakan suatu perangkat lunak yang berisi kumpulan metode,
estimasi, dokumentasi dan petunjuk administrasi guna membantu pemakai
untuk mengembangkan dan merawat sistem yang efektif.
▪ SPECTRUM Perangkat lunak ini mempunyai beberapa versi untuk keperluan
yang berbeda, semacam SPECTRUM-1 untuk life cycle konvensional,
SPECTRUM-2 untuk sistem manajemen proyek terstruktur, SPECTRUM-3
untuk on-line interactive estimator.
▪ SRES (Software Requirement Engineering System) dan SREM (Software
Requirement Engineering Methodology) DBO (Design By Objective), PAD
(Program Analysis Diagram), HOS (Higher Order Software), MSR (Meta
Stepwise Refinement), PDL (Program Design Language)
I. Tools Pengembangan Sistem

Untuk dapat melakukan langkah-langkah sesuai dengan yang diberikan oleh
metodologi pengembangan sistem yang terstruktur, maka dibutuhkan alat dan teknik untuk
melaksanakannya. Alat-alat yang digunakan dalam suatu metodologi umumnya berupa
suatu gambar atau diagram atau grafik. Selain berbentuk gambar, alat-alat yang
digunakan juga ada yang tidak berupa gambar atau grafik (nongraphical tools), seperti
misalnya data dictionary, structured english, pseudocode serta formulir-formulir untuk
mencatat dan menyajikan data.
Alat-alat pengembangan sistem yang berbentuk grafik diantaranya adalah sebagai
berikut ini :
a. HIPO diagram Hierarchy plus Input-Process-Output, HIPO, adalah alat dokumentasi
program yang berbasis pada fungsi, yaitu tiap-tiap modul di dalam sistem
digambarkan oleh fungsi utamanya.
b. Data flow diagram Digunakan untuk menggambarkan suatu sistem yang telah ada
atau sistem baru yang akan dikembangkan secara logika tanpa mempertimbangkan
lingkungan fisik dimana data tersebut mengalir (misalnya lewat telpon, surat dan
sebagainya) atau lingkungan fisik dimana data tersebut akan disimpan (misalnya file
kartu, microfile, harddisk, tape, diskette dan lain sebagainya).
c. Structured chart Digunakan untuk mendefinisikan dan mengilustrasikan organisasi dari
sistem informasi secara berjenjang dalam bentuk modul dan submodul dengan
menunjukkan hubungan elemen data dan elemen kontrol antara hubungan modulnya,
sehingga memberikan penjelasan lengkap dari sistem dipandang dari elemen data,
elemen kontrol, modul dan hubungan antar modulnya.
d. SADT Structured Analysis and Design Technique, SADT, memandang suatu sistem
terdiri dari dua hal : benda (obyek, dokumen atau data) dan kejadian (kegiatan yang
dilakukan oleh orang, mesin atau perangkat lunak). Menggunakan dua tipe diagram

yaitu, diagram kegiatan (activity diagrams, disebut actigrams) dan diagram data (data
diagrams, disebut datagrams)
e. Jackson’s diagram Jackson’s Systems Development (JSD), membangun suatu model
dari dunia nyata (real world) yang menyediakan subyek-subyek permasalahan dari
sistem. Disamping alat-alat berbentuk grafik yang digunakan pada suatu metodologi
tertentu, masih terdapat beberapa alat berbentuk grafik yang sifatnya umum, yaitu
dapat digunakan di semua metodologi yang ada. Alat-alat ini berupa suatu bagan
yang dapat diklasifikasikan sebagai berikut :
1. Bagan untuk menggambarkan aktivitas (activity charting):
a. Bagan alir sistem (systems flowchart)
b. Bagan alir program (program flowchart) yang dapat berupa bagan alir logika
program (program logic flowchart), bagan alir program komputer terinci
(detailed computer program flowchart)
c. Bagan alir kertas kerja (paperwork flowchart)
d. Bagan alir proses (process flowchart)
e. Gantt chart
2. Bagan untuk menggambarkan tataletak (layout charting)
3. Bagan untuk menggambarkan hubungan personil (personal relationship charting):
a. Bagan distribusi kerja (working distribution chart)
b. Bagan organisasi (organization chart)
Teknik-teknik dalam pengembangan sistem yang dapat digunakan antara lain:

a. Teknik manajemen proyek, yaitu CPM (Critical Path Method) dan PERT (Program
Evaluation and Review Technique) Teknik ini digunakan untuk penjadwalan waktu
pelaksanaan suatu proyek.
b. Teknik menemukan fakta (fact finding techniques) Yaitu teknik yang dapat digunakan
untuk mengumpulkan data dan menemukan fakta-fakta dalam kegiatan mempelajari
sistem yang ada. Teknik-teknik ini diantaranya adalah:
▪ wawancara (interview) wawancara memungkinkan analis sistem sebagai
pewawancara (interviewer) untuk mengumpulkan data secara tatap muka
langsung dengan orang yang diwawancarai (interviewee).
▪ observasi (observation) observasi adalah pengamatan langsung suatu kegiatan
yang sedang dilakukan yang mana pada waktu observasi analis sistem dapat ikut
juga berpartisispasi dengan orang-orang yang sedang melakukan suatu kegiatan
tersebut.
▪ daftar pertanyaan (questionaires) adalah suatu daftar yang berisi dengan
pertanyaan-pertanyaan untuk tujuan khusus yang memungkinkan analis sistem
untuk mengumpulkan data dan pendapat dari responden-responden yang dipilih.
▪ pengumpulan sampel (sampling) pengambilan sampel adalah pemilihan sejumlah
item tertentu dari seluruh item yang ada dengan tujuan mempelajari sebagian item
tersebut untuk mewakili seluruh itemnya dengan pertimbangan biaya dan waktu
yang terbatas.
c. Teknik analisis biaya/manfaat (cost-effectiveness analysis atau cost-benefit analysis)
Teknik ini menilai dari sisi kelayakan ekonomis suatu pengembangan sistem
informasi.
d. Teknik untuk menjalankan rapat Selama proses pengembangan sistem dilakukan,
seringkali rapat-rapat diadakan baik oleh tim pengembangan sistem sendiri atau rapat
antara tim pengembangan sistem dengan pemakai sistem dan manajer, sehingga

kemampuan analis sistem untuk memimpin atau berpartisipasi di dalam suatu rapat
merupakan hal yang penting terhadap kesuksesan proyek pengembangan sistem.
e. Teknik inspeksi/walkthrough Inspeksi merupakan kepentingan dari pemakai sistem
dan walkthrough merupakan kepentingan dari analis sistem. Analis sistem melakukan
walkthrough untuk maksud supaya dokumentasi yang akan diserahkan kepada
pemakai sistem secara teknik tidak mengalami kesalahan dan dapat dilakukan dengan
diverifikasi terlebih dahulu oleh analis sistem yang lain. Pemakai sistem melakukan
inspeksi untuk maksud menilai dokumentasi yang diserahkan oleh analis sistem
secara teknik tidak mengandung kesalahan.
Penyebab kegagalan pengembangan sistem :
▪ Kurangnya penyesuaian pengembangan sistem
▪ Kelalaian menetapkan kebutuhan pemakai dan melibatkan pemakai sistem
▪ Kurang sempurnanya evaluasi kualitas analisis biaya
▪ Adanya kerusakan dan kesalahan rancangan
▪ Penggunaan teknologi komputer dan perangkat lunak yang tidak direncanakan
dan pemasangan teknologi tidak sesuai
▪ Pengembangan sistem yang tidak dapat dipelihara
▪ Implementasi yang direncanakan dilaksanakan kurang baik
J. Fungsi Analis Sistem

Analis sistem (systems analyst) adalah orang yang menganalisis sistem (mempelajari
masalah-masalah yang timbul dan menentukan kebutuhan-kebutuhan pemakai sistem)
untuk mengidentifikasikan pemecahan yang beralasan. Sebutan lain untuk analis sistem
ini adalah analis informasi (information analyst), analis bisnis (business analyst),
perancang sistem (systems designer), konsultan sistem (systems consultant) dan ahli
teknik sistem (systems engineer). Analis sistem berbeda dengan pemrogram. Pemrogram
(programmer) adalah orang yang menulis kode program untuk suatu aplikasi tertentu
berdasarkan rancang bangun yang telah dibuat oleh analis sistem. Akan tetapi ada juga
analis sistem yang melakukan tugas-tugas seperti pemrogram dan sebaliknya ada juga
pemrogram yang melakukan tugas-tugas yang dilakukan oleh analis sistem. Orang yang
melakukan tugas baik sebagai analis sistem maupun pemrogram disebut
analis/pemrogram (analyst/programmer) atau pemrogram/analis (programmer/analyst).
Tugas dan tanggung jawab analis sistem dan pemrogram adalah berbeda dan dapat
dilihat pada tabel berikut :
Tabel 1. Tugas dan Tanggung Jawab Pemogram dan Analis Sistem
PEMOGRAM ANALIS SISTEM

1. Tanggung jawab pemrogram terbatas 1. Tanggung jawab analis sistem tidak
pada pembuatan program komputer. hanya pada pembuatan program
2. Pengetahuan pemrogram cukup terbatas komputer saja, tetapi pada sistem
pada teknologi komputer. secara keseluruhan.
3. Pekerjaan pemrogram sifatnya teknis dan 2. Pengetahuan analis sistem harus
harus tepat dalam pembuatan instruksi- luas, tidak hanya pada teknologi
instruksi program. komputer, tetapi juga pada bidang
4. Pekerjaan pemrogram tidak menyangkut aplikasi yang ditanganinya.
hubungan dengan banyak orang, terbatas 3. Pekerjaaan analis sistem dalam
pada sesama pemrogram dan analis pembuatan program terbatas pada
sistem yang mempersiapkan rancang pemecahan masalah secara garis

bangun (spesifikasi) programnya. besar.

4. Pekerjaan analis sistem melibatkan
hubungan banyak orang, tidak
terbatas pada sesama analis sistem,
pemrogram, tetapi juga pemakai
sistem dan manajer.
Seorang Analis sistem harus mempunyai pengetahuan yang luas dan keahlian
yang khusus. Beberapa analis sistem setuju bahwa pengetahuan-pengetahuan dan
keahlian berikut ini sangat diperlukan bagi seorang analis sistem yang baik :
1. Pengetahuan dan keahlian tentang teknik pengolahan data, teknologi komputer dan
pemrograman komputer a. Keahlian teknis yang harus dimiliki adalah termasuk
keahlian dalam penggunaan alat dan teknik untuk pengembangan perangkat lunak
aplikasi serta keahlian dalam menggunakan komputer. b. Pengetahuan teknis yang
harus dimiliki meliputi pengetahuan tentang perangkat keras komputer, teknologi
komunikasi data, bahasa-bahasa komputer, sistem operasi, utilities dan paket-paket
perangkat lunak lainnya.
2. Pengetahuan tentang bisnis secara umum Aplikasi bisnis merupakan aplikasi yang
sekarang paling banyak diterapkan, maka analis sistem harus mempunyai
pengetahuan tentang ini. Pengetahuan ini dibutuhkan supaya analis sistem dapat
berkomunikasi dengan pemakai sistem. Pengetahuan tentang bisnis ini meliputi
akuntansi keuangan, akuntansi biaya, akuntansi manajemen, sistem pengendalian
manajemen, pemasaran, produksi, manajemen personalia, keuangan, tingkah laku
organisasi, kebijaksanaan perusahaan dan aspek-aspek bisnis lainnya.
3. Pengetahuan tentang metode kuantitatif Dalam membangun model-model aplikasi,
analis sistem banyak menggunakan metode-metode kuantitatif, seperti misalnya
pemrograman linier (linier programming), pemrograman dinamik (dynamic
programming), regresi (regresion), network, pohon keputusan (decision tree), trend,
simulasi dan lain sebagainya.
4. Keahlian pemecahan masalah Analis sistem harus mempunyai kemampuan untuk
meletakkan permasalahanpermasalahan komplek yang dihadapi oleh bisnis,
memecah-mecah masalah tersebut ke dalam bagian-bagiannya, menganalisisnya dan
kemudian harus dapat merangkainya kembali menjadi suatu sistem yang dapat
mengatasi permasalahanpermasalahan tersebut.
5. Keahlian komunikasi antar personil Analis sistem harus mempunyai kemampuan
untuk mengadakan komunikasi baik secara lisan maupun secara tertulis. Keahlian ini
diperlukan di dalam wawancara, presentasi, rapat dan pembuatan laporan-laporan.
6. Keahlian membina hubungan antar personil Manusia merupakan faktor yang kritis di
dalam sistem dan watak manusia satu dengan yang lainnya berbeda. Analis sistem
yang kaku dalam membina hubungan kerja dengan personil-personil lainnya yang
terllibat, akan membuat pekerjaannya menjadi tidak efektif. Apalagi bila analis sistem
tidak dapat membina hubungan yang baik dengan pemakai sistem, maka akan tidak
mendapat dukungan dari pemakai sistem atau manajemen dan kecenderungan
pemakai sistem akan mempersulitnya.
Dalam sebuah proyek pengembangan sistem, pembentukan sebuah Tim

Pengembangan Sistem dalam skala kecil dan sederhana, kemungkinan hanya ada
seorang analis sistem yang merangkap sebagai pemrogram (analis/pemrogram) atau
seorang pemrogram yang merangkap sebagai analis sistem (pemrogram/analis). Akan

tetapi untuk proyek pengembangan sistem yang besar atau komplek, pekerjaan ini
biasanya dilakukan oleh sejumlah orang dalam bentuk tim. Anggota dari tim
pengembangan sistem ini tergantung dari besar-kecilnya ruang-lingkup proyek yang kaan
ditangani. Tim ini secara umum dapat terdiri dari personil-personil sebagai berikut ini :
1. Manajer analisis sistem, Manajer analisis sistem (manager of systems analysis) ini
disebut juga sebagai koordinator proyek dan mempunyai tugas dan tanggung jawab:
a. Sebagai ketua/koordinator tim pengembangan sistem
b. Mengarahkan, mengontrol dan mengatur anggota tim pengembangan sistem
lainnya
c. Membuat jadwal pelakasanaan proyek pengembangan sistem yang akan dilakukan
d. Bertanggungjawab dalam mendefinisikan masalah, studi kelayakan, disain sistem
dan penerapannya
e. Memberikan rekomendasi-rekomendasi perbaikan sistem
f. Mewakili tim untuk berhubungan dengan pemakai sistem dalam hal perundingan-
perundingan dan pemberian-pemberian nasehat kepada manajemen dan pemakai
sistem
g. Membuat laporan-laporan kemajuan proyek (progress report)
h. Mengkaji ulang dan memeriksa kembali hasil kerja dari tim
2. Ketua analis sistem, Ketua analis sistem (lead systems analyst) biasanya menjabat
sebagai wakil dari manajer analisis sistem. Tugasnya adalah membantu tugas dari
manajer analisis sistem dan mewakilinya bila manajer analisis sistem berhalangan.
3. Analis sistem senior, Analis sistem senior (senior systems analyst) merupakan analis
sistem yang sudah berpengalaman.
4. Analis sistem Analis sistem (systems analyst) merupakan analis sistem yang cukup
berpengalaman dan dapat bekerja sendiri tanpa bimbingan dari analis sistem senior.
5. Analis sistem yunior Analis sistem yunior (junior systems analyst) merupakan analis
sistem yang belum berpengalaman dan masih membutuhkan bimbingan-bimbingan
dari analis sistem yang lebih senior. Analis sistem yunior ini sering juga disebut
dengan analis sistem yang masih dilatih (systems analyst trainee).
6. Pemrogram aplikasi senior Pemrogram aplikasi senior (senior applications
programmer) merupakan pemrogram komputer yang sudah berpengalaman dengan
tugas merancang spesifikasi dari program aplikasi dan mengkoordinasi kerja dari
pemrogram yang lainnya. Pemrogram aplikasi senior ini kadang-kadang juga disebut
dengan pemrogram/analis.
7. Pemrogram aplikasi Pemrogram aplikasi (applications programmer) merupakan
pemrogram komputer yang cukup berpengalaman dan dapat melakukan tugasnya
tanpa harus dibimbing secara langsung lagi.
8. Pemrogram aplikasi yunior Pemrogram aplikasi yunior (junior applications
programmer) merupakan pemrogram komputer yang belum berpengalaman dan
masih dibawah bimbingan langsung dari pemrogram yang lebih senior. Pemrogram
aplikasi yunior biasanya hanya dilibatkan pada pembuatan modul-modul program
yang sederhana, seperti misalnya pembuatan bentuk-bentuk I/O. Pemrogram aplikasi
yunior ini sering juga disebut dengan pemrogram aplikasi yang masih dilatih
(applications programmer trainee).

BAB II
METODE PENGEMBANGAN SISTEM
2.1 Metode Pengembangan Sistem

A. Definisi
Metode pengembangan system adalah suatu proses pengembangan system yang
formal dan presisi yang mendefinisikan serangkaian aktivitas, metode, best
practices dan tools yang terautomasi bagi para pengembang danmanager proyek dalam
rangka mengembangkan dan merawat sebagai keseluruhan system informasi
atau software. Alasan perlunya metode pengembangan sistem adalah:
a. Menjamin adanya konsistensi proses
b. Dapat diterapkan dalam berbagai jenis proyek
c. Mengurangi resiko kesalahan dan pengambilan jalan pintas.
d. Menuntut adanya dokumentasi yang konsisten yang bermanfaat bagi personal baru
dalam tim proyek.
B. Jenis Metode Pengembangan System

1. Metode System Development Life Cycle (SDLC)
SDLC atau Software Development Life Cycle atau System Development Life Cycle
adalah proses mengembangkan atau mengubah suatu sistem perangkat lunak
dengan menggunakan model-model atau metodologi yang digunakan orang untuk
mengembangkan sistem-sistem perangkat lunak sebelumnya (Rosa dan
Shalahuddin). Metode ini adalah metode pengembangan sistem informasi yang
pertama kali digunakan makanya disebut dengan metode tradisional. Metode ini
prototype, adalah tahap-tahapan pekerjaan yang dilakukan oleh analis sistem dan
programer dalam membangun sistem informasi.
Tahap-tahap SDLC yaitu:

• Melakukan survey dan menilai kelayakan proyek pengembangan sistem informasi.
• Mempelajari dan menganalisis sistem informasi yang sedang berjalan.
• Menentukan permintaan pemakai sistem informasi.
• Memilih solusi atau pemecahan masalah yang paling baik.
• Menentukan perangkat keras dan perangkat lunak computer.
• Merancang sistem informasi baru.
• Mengkomunikasikan dan mengimplementasikan sistem informasi baru.
• Memelihara dan melakukan perbaikan/peningkatan sistem informasi baru.
22
Gambar 7. Tahapan SDLC
Gambar8. Siklus SDLC

Kelebihan
• Mudah diaplikasikan.
• Memberikan template tentang metode analisis, desain, pengkodean, pengujian, dan
pemeliharaan.
Kekurangan
• Jarang sekali proyek riil mengikuti aliran sekuensial yang dianjurkan model karena
model ini bisa melakukan itersi tidak langsung.
• Pelanggan sulit untuk menyatakan kebutuhan secara eksplisit sehingga sulit untuk
megakomodasi ketidakpastian pada saat awal proyek.

• Pelanggan harus bersikap sabar karena harus menunggu sampai akhir proyek
dilalui. Sebuah kesalahan jika tidak diketahui dari awal akan menjadi masalah
besar karena harus mengulang dari awal.
• Pengembang sering malakukan penundaan yang tidak perlu karena anggota tim
proyek harus menunggu tim lain untuk melengkapi tugas karena memiliki
ketergantungan hal ini menyebabkan penggunaan waktu tidak efesien.
2.2 Model WATERFALL

Sering juga disebut model Sequential Linier. Beberapa pengertian dan pendapat ahli
tentang Metode Air Terjun ( waterfall) dapat diuraikan berikut ini :
Menurut Pressman (2015:42), model waterfall adalah model klasik yang bersifat
sistematis, berurutan dalam membangun software. Nama model ini sebenarnya adalah
“Linear Sequential Model”. Model ini sering disebut juga dengan “classic life cycle” atau
metode waterfall. Model ini termasuk ke dalam model generic pada rekayasa perangkat
lunak dan pertama kali diperkenalkan oleh Winston Royce sekitar tahun 1970 sehingga
sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai dalam
Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan
berurutan. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus
menunggu selesainya tahap sebelumnya dan berjalan berurutan. Fase-fase dalam
Waterfall Model menurut referensi Pressman :
Gambar 9. Tahapan Waterfall Model Pressman
a. Communication (Project Initiation & Requirements Gathering) Sebelum memulai

pekerjaan yang bersifat teknis, sangat diperlukan adanya komunikasi dengan
customer demi memahami dan mencapai tujuan yang ingin dicapai. Hasil dari
komunikasi tersebut adalah inisialisasi proyek, seperti menganalisis permasalahan
yang dihadapi dan mengumpulkan data-data yang diperlukan, serta membantu
mendefinisikan fitur dan fungsi software. Pengumpulan data-data tambahan bisa juga
diambil dari jurnal, artikel, dan internet.
b. Planning (Estimating, Scheduling, Tracking) Tahap berikutnya adalah tahapan
perencanaan yang menjelaskan tentang estimasi tugas-tugas teknis yang akan
dilakukan, resikoresiko yang dapat terjadi, sumber daya yang diperlukan dalam
membuat sistem, produk kerja yang ingin dihasilkan, penjadwalan kerja yang akan
dilaksanakan, dan tracking proses pengerjaan sistem.
c. Modeling (Analysis & Design) Tahapan ini adalah tahap perancangan dan permodelan
arsitektur sistem yang berfokus pada perancangan struktur data, arsitektur software,
tampilan interface, dan algoritma program. Tujuannya untuk lebih memahami
gambaran besar dari apa yang akan dikerjakan.

d. Construction (Code & Test) Tahapan Construction ini merupakan proses

penerjemahan bentuk desain menjadi kode atau bentuk/bahasa yang dapat dibaca
oleh mesin. Setelah pengkodean selesai, dilakukan pengujian terhadap sistem dan
juga kode yang sudah dibuat. Tujuannya untuk menemukan kesalahan yang mungkin
terjadi untuk nantinya diperbaiki.
e. Deployment (Delivery, Support, Feedback) Tahapan Deployment merupakan tahapan
implementasi software ke customer, pemeliharaan software secara berkala, perbaikan
software, evaluasi software, dan pengembangan software berdasarkan umpan balik
yang diberikan agar sistem dapat tetap berjalan dan berkembang sesuai dengan
fungsinya. (Pressman, 2015:17)
Kapan sebaiknya metode waterfall digunakan?

Ada teori-teori yang menyimpulkan beberapa hal, yaitu :
1. Ketika semua persyaratan yang diajukan sudah dipahami dengan baik pada awal
pengembangan program.
2. Definisi produk bersifat stabil dan tidak ada perubahan yang dilakukan saat
pengembangan untuk alasan apapun. Oleh karena itu, teknologi yang digunakan juga
harus sudah dipahami dengan baik.
3. Menghasilkan produk baru, atau produk dengan versi baru. Sebenarnya, jika
menghasilkan produk dengan versi baru maka itu sudah termasuk incremental
development, yang setiap tahapannya sama dengan metode waterfall kemudian
diulang-ulang.
4. Port-ing produk yang sudah ada ke dalam platform baru.
Dengan demikian, metode waterfall dianggap pendekatan yang lebih cocok digunakan
untuk proyek pembuatan sistem baru dan juga pengembangan software dengan tingkat
resiko yang kecil serta waktu pengembangan yang cukup lama. Tetapi salah satu
kelemahan paling mendasar adalah menyamakan pengembangan hardware dan software
dengan meniadakan perubahan saat pengembangan. Padahal, error diketahui saat
software dijalankan, dan perubahan-perubahan akan sering terjadi.
Keuntungan menggunakan metode waterfall adalah prosesnya lebih terstruktur, hal ini
membuat kualitas software baik dan tetap terjaga. Dari sisi user juga lebih
menguntungkan, karena dapat merencanakan dan menyiapkan kebutuhan data dan
proses yang diperlukan sejak awal. Penjadwalan juga menjadi lebih menentu, karena
jadwal setiap proses dapat ditentukan secara pasti. Sehingga dapat dilihat jelas target
penyelesaian pengembangan program. Dengan adanya urutan yang pasti, dapat dilihat
pula perkembangan untuk setiap tahap secara pasti. Dari sisi lain, model ini merupakan
jenis model yang bersifat dokumen lengkap sehingga proses pemeliharaan dapat
dilakukan dengan mudah.
Kelemahan menggunakan metode waterfall adalah bersifat kaku, sehingga sulit
melakukan perubahan di tengah proses. Jika terdapat kekurangan proses/prosedur dari
tahap sebelumnya, maka tahapan pengembangan harus dilakukan mulai dari awal lagi.
Hal ini akan memakan waktu yang lebih lama. Karena jika proses sebelumnya belum
selesai sampai akhir, maka proses selanjutnya juga tidak dapat berjalan. Oleh karena itu,
jika terdapat kekurangan dalam permintaan user maka proses pengembangan harus
dimulai kembali dariawal. Karena itu, dapat dikatakan proses pengembangan software
dengan metode waterfall bersifat lambat. Kelemahan lainnya menggunakan metode
waterfall adalah membutuhkan daftar kebutuhan yang lengkap sejak awal. Tetapi,
biasanya jarang sekali customer yang dapat memenuhi itu. Untuk menghindari

pengulangan tahap dari awal, user harus memberikan seluruh prosedur, data, dan laporan
yang diinginkan mulai dari tahap awal pengembangan. Tetapi pada banyak kondisi, user
sering melakukan permintaan ditahap pertengahan pengembangan sistem. Dengan
metode ini, maka development harus dilakukan mulai lagi dari tahap awal. Karena
development disesuaikan dengan desain hasil user pada saat tahap pengembangan awal.
Di sisi lain, user tidak dapat mencoba sistem sebelum sistem benar-benar selesai. Selain
itu, kinerja personil menjadi kurang optimal karena terdapat proses menunggu suatu tahap
selesai terlebih dahulu. Oleh karena itu, seringkali diperlukan personil yang “multi-skilled”
sehingga minimal dapat membantu pengerjaan untuk tahapan berikutnya. (Pressman,
2015:42-43)
Menurut Rosa A.S dan M. Shalahuddin (2015:28-30) Model SDLC air terjun (waterfall)
sering juga disebut model sekuensial linier (sequential linier) atau alur hidup klasik (classic
life cycle). Model air terjun menyediakan pendekatan alur hidup perangkat lunak secara
sekuensial atau terurut dimulai dari analisis, desain, pengodean, pengujian, dan tahap
pendukung (support).
Gambar 10. Tahapan Waterfall
Berikut langkah-langkah yang penting dalam model ini sebagai berikut:

a. Analisis kebutuhan perangkat lunak
Proses pengumpulan kebutuhan dilakukan secara intensif untuk menspesifikasikan
kebutuhan perangkat lunak agar dapat dipahami perangkat lunak seperti apa yang
dibutuhkan oleh user. Spesifikasi kebutuhan perangkat lunak pada tahap ini perlu
didokumentasikan.
b. Desain
Desain perangkat lunak adalah proses multi langkah yang fokus pada desain
pembuatan program perangkat lunak termasuk struktur data, arsitektur perangkat
lunak, representasi antarmuka, dan prosuder pengodean. Tahap ini mentranslasi
kebutuhan perangkat lunak dari tahap analisis kebutuhan ke representasi desain agar
dapat diimplementasikan menjadi program pada tahap selanjutnya. Desain perangkat
lunak yang dihasilkan pada tahap ini juga perlu didokumentasikan.
c. Pembuatan kode program

Desain harus ditranslasikan ke dalam program perangkat lunak. Hasil dari tahap ini
adalah program computer sesuai desain yang telah dibuat pada tahap desain.

d. Pengujian
Pengujian focus pada perangkat lunak secara dari segi lojik dan fungsional dan
memastikan bahwa semua bagian sudah diuji. Hal ini dilakukan untuk meminimalisir
kesalahan (error) dan memastikan keluaran yang dihasilkan sesuai dengan yang
diinginkan.
e. Pendukung (support) atau pemeliharaan (maintenance)

Tidak menutup kemungkinan sebuah perangkat lunak mengalami perubahan ketika
sudah dikirimkan ke user. Perubahan bisa terjadi karena adanya kesalahan yang
muncul dan tidak terdeteksi saat pengujian atau perangkat lunak harus beradaptasi
dengan lingkungan baru. Tahap pendukung atau pemeliharaan dapat mengulangi
proses pengembangan mulai dari analisis spesifikasi untuk perubahan perangkat
lunak yang sudah ada, tapi tidak untuk membuat perangkat lunak baru.
Kelebihan Waterfall :
Keuntungan pengembangan dengan metode waterfall adalah metode ini memungkinkan
untuk departementalisasi dan kontrol. proses pengembangan model fase satu per satu,
sehinggameminimalis kesalahan-kesalahan yang mungkin akan terjadi. Pengembanganya
bergerak dari konsep, yaitu melalui desain, implementasi, pengujian, instalasi,
troubleshooting, dan berakhir di operasi dan pemeliharaan.
a. Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh
pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan
tertentu.
b. Document pengembangan system sangat terorganisir, karena setiap fase
harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.
Jadi setiap fase atau tahapan akan mempunyai dokumen tertentu.
c. Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno,
daripada menggunakan pendekatan asal-asalan. Selain itu, metode ini juga
masih masuk akal jika kebutuhan sudah diketahui dengan baik.
Kerugian Waterfall :
a. Kerugian pembangunan menggunakan metode waterfall adalah tidak
memungkinkan untuk banyak refleksi atau revisi jika terjadi kesalahan. Karna
setelah aplikasi ini dalam tahap pengujian, sangat sulit untuk kembali dan
mengubah sesuatu yang tidak terdokumentasi dengan baik dalam tahap
konsep.
b. Diperlukan majemen yang baik, karena proses pengembangan tidak dapat
dilakukan secara berulang sebelum terjadinya suatu produk.
c. Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal
pengembangan yang berakibat pada tahapan selanjutnya.
d. Pelanggan sulit menyatakan kebutuhan secara eksplisit sehingga tidak dapat
mengakomodasi ketidak pastian pada saat awal pengembangan.
e. Pelanggan harus sabar, karena pembuatan perangkat lunak akan dimulai
ketika tahap desain sudah selesai. Sedangkan pada tahap sebelum desain
bisa memakan waktu yang lama.
Pada kenyataannya, jarang mengikuti urutan sekuensial seperti pada teori. Iterasi sering
terjadi menyebabkan masalah baru

2.3 Model Prototyping

Prototype adalah salat satu metode pengembangan perangkat lunak yang banyak
digunakan. Prototyping adalah proses iterative dalam pengembangan sistem dimana
requirement diubah ke dalam sistem yang bekerja (working system) yang secara terus
menerus diperbaiki melalui kerjasama antara user dan analis. Prototype juga bisa
dibangun melalui beberapa tool pengembangan untuk menyederhanakan proses. Dengan
menggunakan Metode prototyping ini, pengembang dan pelanggan dapat saling
berinteraksi selama proses pembuatan sistem. Sering terjadi seorang pelanggan
hanya mendefinisikan secara umum apa yang dibutuhkan, pemrosesan dan data-data apa
saja yang dibutuhkan. Sebaliknya, disisi pengembang kurang memperhatikan efisiensi
Algoritma. Kemampuan sistem operasi dan interface yang menghubungkan manusia
dengan komputer.
Pada prototyping model kadang-kadang klien hanya memberikan beberapa kebutuhan
umum software tanpa detail input, proses atau detail output dilain waktu mungkin tim
pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan ,
tingkat adaptasi terhadap sistem operasi atau rancangan form user interface . Ketika
situasi seperti ini terjadi, model prototyping sangat membantu proses pembangunan
software. Proses pada prototyping dapat digambarkan pada gambar berikut ini :
Gambar 11. Proses Prototipe
1. Mendengarkan Pelanggan
Pada tahap ini dilakukan pengumpulan kebutuhan dari sistem dengan cara
mendengar keluhan dari pelanggan. Untuk membuat suatu sistem yang sesuai
kebutuhan, maka harus diketahui terlebih dahulu bagaimana sistem yang sedang
berjalan untuk kemudian mengetahui masalah yang terjadi.
2. Merancang dan Membuat Mockup
Pada tahapan ini, dilakukan perancangan dan pembuatan prototype system . Mockup/
Prototype yang dibuat disesuaikan dengan kebutuhan sistem yang telah didefinisikan
sebelumnya dari keluhan pelanggan atau pengguna.
3. Uji Coba
Pada tahap ini, Mockup/ Prototype dari sistem di uji coba oleh pelanggan atau
pengguna. Lalu dilakukan evaluasi kekurangan-kekurangan dari kebutuhan

pelanggan. Pengembangan kemudian kembali mendengarkan keluhan dari pelanggan

untuk memperbaiki Prototype yang ada.
Mock-up adalah sesuatu yang digunakan sebagai model desain untuk mengajar,
demonstrasi, evaluasi desain, promosi atau keperluan lain yang mempu menyediakan
atau mendemonstrasikan sebagian besar fungsi perangkat lunak dan memungkinkan
pengujian desain perangkat lunak
Rangkuman Tahapan-tahapan Model Prototyping

• Pengumpulan Kebutuhan
• Membangun Prototyping
• Menggunakan Sistem
• Mengkodekan Sistem
• Menguji Sistem
• Evaluasi Sistem
• Evaluasi Protoptyping
Kelebihan
• Prototype melibatkan user dalam analisa dan desain.
• Punya kemampuan menangkap requirement secara konkret.
• Digunakan untuk memperluas SDLC.
Kekurangan
• Proses analisis dan perancangan terlalu singkat.
• Mengesampingkan alternatif pemecahan masalah.
• Bisanya kurang fleksible dalam mengahdapi perubahan.
• Protitype yang dihasilkan tidak selamanya mudah dirubah dan cepat selesai.
2.4 Model RAD (Rapid Application Development)

Rapid application development (RAD) adalah metode yang berfokus pada
pengembangan aplikasi secara cepat, melalui pengulangan dan feedback berulang-
ulang. RAD diajukan oleh IBM pada tahun 1980 sampai 1990-an, ketika permintaan
terhadap aplikasi semakin meningkat. Dengan banyaknya demand, orang-orang di dunia
IT harus mencari solusi untuk memenuhi permintaan tersebut.
Metode ini merupakan semacam cikal bakal agile project management, karena bisa
mengikuti pace bisnis yang terus berkembang dan juga kebutuhan pasar yang terus
meningkat. Pengembangan software pada umumnya seperti waterfall model
membutuhkan perencanaan yang terbilang cukup kaku. Klien atau pelanggan seakan
‘dipaksa’ untuk menyetujui banyak hal di awal, tetapi mereka tidak bisa melihat proses
pembuatannya. RAD adalah penggabungan beberapa metode atau teknik terstruktur.
RAD menggunakan metode prototyping dan teknik terstruktur lainnya untuk menentukan
kebutuhan user dan perancangan sistem informasiselain itu RAD menekankan siklus
perkembangan dalam waktu yang singkat (60 sampai 90 hari) dengan pendekatan
konstruksi berbasis komponen.

Gambar 12. Model RAD
Gambar13. Model RAD
Seperti yang terlihat pada gambar di atas, terdapat 3 tim yang bekerja dalam sebuah
proyek. Seperti yang telah dijelaskan di atas, 3 tim tersebut melakukan tahapan-tahapan
yang sama namun setiap tim mengerjakan fungsi dari suatu proyek yang berbeda-beda.
Berikut adalah penjelasan tahapan-tahapan diatas.
Bussiness Modeling
Pada tahap ini, kebutuhan-kebutuhan dari pelanggan dijelaskan secara detail dalam
bentuk fungsi-fungsi yang akan dikerjakan. Kata Bussiness Modeling bukan berarti

mewakili kebutuhan-kebutuhan dari pelanggan yang bersifat bisnis saja. Nama tersebut
hanya mewakili sebagian kecil dari kebutuhan-kebutuhan yang ada.
Data Modeling
Pada tahapan ini, data-data yang ada pada fungsi-fungsi tersebut (fungsi yang telah
dijelaskan pada tahap Bussiness Modeling) akan dijelaskan. Kemudian akan diproses
lebih lanjut pada tahapan selanjutnya yaitu Process Modeling.
Process Modeling
Seluruh data-data dan juga bahan-bahan yang lainnya akan diproses dan diolah pada
tahapan ini. Hasil proses tersebut berupa informasi-informasi yang dapat berguna bagi
pelanggan dan juga dapat berguna untuk tahapan selanjutnya.
Application Modeling
Pada tahapan ini, program mulai dibuat. Informasi-informasi yang telah didapatkan dari
tahapan-tahapan sebelumnya digunakan oleh programmer selama pembuatan program.
Seluruh konsep yang sudah didapatkan juga dijadikan sebagai acuan oleh programmer
dalama pembuatan program.
Testing & Turnover

Pada tahap ini, program yang telah jadi akan diuji coba satu per satu dari masing-masing
tim. Apabila ada salah satu tim tidak lulu dalam pengujian, maka tim tersebut harus
menyelesaikannya dengan cepat. Setelah program dari seluruh tim lulus dalam pengujian,
maka program-program tersebut akan disatukan menjadi satu program utuh yang sesuai
dengan permintaan pelanggan.
Kelebihan Model RAD:

1. Adanya pembagian tugas secara tim, membuat model RAD menjadi sangat ideal
dalam mengerjakan proyek yang membutuhkan waktu singkat sebab waktu yang
dibutuhkan dalam menyelesaikan sebuah proyek relatif singkat. Hanya sekitar 60 – 90
hari waktu yang dibutuhkan sedangkan secara umum, penyelesaian sebuah proyek
memakan waktu sekitar 180 hari. Nominal angka tersebut hanyalah sebagian contoh
yang menunjukkan bahwa dengan menggunakan model RAD maka sebuah proyek
akan jauh lebih cepat selesai, bahkan bisa mengurangi setengah dari waktu normal.
2. Proses pengembangan ulang tidak memakan waktu yang lama, sebab fungsi-fungsi
sudah terbagi secara merata untuk setiap tim sehingga pengembangan dari fungsi-
fungsi tersebut tidak membutuhkan waktu yang banyak. Apabila fungsi pada tim 1
yang akan dikembangkan misalnya, maka hanya pada tim 1 saja yang akan
melakukan proses pengembangan ulang. Sedangkan tim 2, tim 3, tidak perlu
melakukan pengembangan ulang.
Kekurangan RAD:
1. Memerlukan banyak sumber daya dalam mengerjakan sebuah proyek. Karena adanya
pembagian secara tim berarti membutuhkan orang yang cukup banyak. Misalnya
dalam 1 tim berisi 5 orang, apabila sebuah proyek terbagi atas 4 tim maka dibutuhkan
paling sedikit 20 orang untuk mengerjakan proyek tersebut. Selain itu, juga diperlukan
banyak sumber daya yang lain yang akan diperlukan untuk setiap tim.
2. Tidak cocok untuk proyek berskala besar. Pengerjaan proyek berskala besar tentunya
akan cepat selesai. Namun, semakin besar proyek maka tim yang akan terbagi
semakin banyak. Dengan kata lain, sumber daya yang diperlukan akan semakin

31
banyak baik dari segi sumber daya manusianya (jumlah orang yang diperlukan)
maupun sumber daya lainnya. Hal ini dapat menyebabkan biaya pengerjaan proyek
menjadi membengkak.
3. Adanya keterbatasan dalam mengambil sebuah proyek. Selain proyek-proyek
berskala besar yang sebaiknya tidak diambil, proyek-proyek yang tidak dapat dipecah
(di modularisasi ) secara fungsi tidak dapat dikerjakan pada model ini.
4. Penggabungan hasil dari setiap tim sangat memerlukan kerja keras. Sebab setiap tim
mungkin memiliki konsep yang berbeda selama pengerjaan. Sehingga apabila
hasilnya mau digabungkan, maka seluruh tim harus berkumpul dan saling bekerja
sama dalam menggabungkan hasil agar menjadi satu program yang utuh.
2.5 Model Spiral

Model Spiral (spiral model) adalah salah satu bentuk dari Metode Pengembangan
Perangkat Lunak atau yang disebut SDLC (Software Development Life Cycle), yang
sangat populer digunakan dalam bidang teknologi informasi. Model Spiral adalah
gabungan dari Model Prototyping dan Model Waterfall dengan penekanan yang tinggi
pada analisis risiko tiap tahapannya. Tahun 1986, model ini dikenalkan pertama kali oleh
Barry Boehm pada makalahnya yang berjudul “A Spiral Model of Software Development
and Enhancement”. Makalah tersebut menjelaskan tentang sebuah diagram yang
dihasilkan dari berbagai publikasi yang mendiskusikan tentang model spiral ini. Model ini
merupakan model yang sudah lama, tetapi sangat berguna untuk melakukan
pembangunan proyek-proyek besar. Pada makalah awal yang dibuatnya, Barry Boehm
menganggap bahwa model Spiral adalah suatu model proses yang berhubungan dengan
inkrementasi, Model Waterfall dan Model Prototyping. Namun dalam publikasi selanjutnya,
Boehm menjelaskan bahwa model Spiral sebagai model proses generator yang mana
pilihan berdasarkan risiko proyek untuk menghasilkan suatu model proses yang tepat
untuk proyek tersebut. Dengan demikian, inkrementasi, Model Waterfall dan Model
Prototyping adalah kasus khusus dengan pola risiko proyek tertentu dari Model Spiral.
Model iteratif ditandai dengan tingkah laku yang memungkinkan pengembang
mengembangkan versi perangkat lunak yang lebih lengkap secara bertahap. Model Spiral
dibagi menjadi beberapa kerangka aktivitas atau disebut juga wilayah kerja (task region).
Cocok digunakan untuk mengembangkan aplikasi dengan skala besar tetapi target waktu
dan biaya tidak terlalu tinggi.

Gambar 14. Model Spiral
a. Komunikasi dengan Pelanggan (customer Communication), Untuk membangun

komunikasi yang efektif antara pengembang (developer) dan pelanggan (customer).
b. Perencanaan (Planning), Untuk mendefinisikan sumber daya, waktu, dan informasi
yang terkait dengan proyek.
c. Analisa Resiko (Risk Analysis),Diperlukan untuk memperkirakan resiko dari segi teknis
maupun manajemen.
d. Rekayasa, Diperlukan untuk membangun satu atau lebih representasi dari aplikasi
perangkat lunak (dapat juga berupa prototipe).
e. Konstruksi dan Peluncuran (Construction and release), Dibutuhkan untuk
mengonstruksi, menguji, melakukan instalasi, dan menyediakan dukungan terhadap
user.
f. Evaluasi Pelanggan (customer Evaluation), Untuk mendapatkan umpan balik
berdasarkan evaluasi representasi perangkat lunak yang dihasilkan dari proses
rekayasa dan diimplementasikan pada tahap instalasi.

Kelebihan
• Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak
komputer.
• Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar
• Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap
resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses
• Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiap
keadaan di dalam evolusi produk.
• Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan
memasukkannya ke dalam kerangka kerja iterative.
• Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi
resiko sebelum menjadi permaslahan yang serius.
Kekurangan
• Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa
dikontrol.
• Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang
serius jika resiko mayor tidak ditemukan dan diatur.
• Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang
absolute
2.6 Model Iteratif

Mengkombinasikan proses-proses pada model air terjun dan iteratif pada model prototipe
yang menghasilkan versi-versi perangkat lunak yang sudah mengalami penambahan
fungsi untuk setiap pertambahannya. Model ini cocok untuk pengembang dengan turnover
staf yang tinggi. Model Inkremental dibuat untuk mengatasi kelemahan model waterfall
yang tidak mengakomodasi iterasi dan mengatasi kelemahan dari metode prototipe yang
memiliki proses terlalu pendek.
Gambar15. Model Iteratif

Pengembangan iteratif dan inkremental adalah kombinasi dari iterative

model dan incremental build model dalam pengembangan software. Dalam
pengembangan perangkat lunak pada model ini, bisa terdapat lebih dari satu siklus
pengulangan yang berjalan dalam waktu bersamaan. Proses ini lah yang dimaksud
dengan incremental.
Dalam incremental model, kebutuhan dan persyaratan yang ada dikerjakan dalam
beberapa bagian. Setiap iterasi, pengembangan melewati fase requirement, design,
implementation, dan testing. Setiap rilis akan selalu ada penambahan fungsi dibandingkan
versi sebelumnya. Proses berlanjut sampai sistem lengkap siap sesuai kebutuhan.
Kunci keberhasilan dalam saat menggunakan siklus ini ialah validasi prasyarat
yang diverifikasi san diuji dalam setiap siklusnya. Ketika software berkembang melalui
siklus yang beruntun, pengujian harus diulang dan diperluas untuk memverifikasi setiap
versi yang dikembangkan.
Sebagaimana model lainnya dalam Software Development Life Cycle lainnya,
penggunaan model ini memiliki beberapa kondisi untuk memaksimalkan hasilnya. Adapun,
model ini paling sering digunakan dalam skenario-skenario berikut :
a. Persyaratan dan kebutuhan sistem yang akan dibangun terdefinisi dengan jelas dan
dipahami dengan baik.
b. Persyaratan utama harus ditentukan. Namun demikian, beberapa fungsi atau
peningkatan lain yang ingin ditambahkan dapat berkembang seiring berjalannya
waktu.
c. Ada waktu dan batasan pasar.
d. Tim yang mengerjakan sedang belajar dan menggunakan teknologi baru saat
menjalankan proyeknya.
e. Tenaga ahli dengan keahlian yang dibutuhkan tidak ada dan hanya akan bergabung
pada saat iterasi tertentu, berdasarkan kontrak.
f. Ada fitur-fitur dengan risiko tinggi yang mungkin berubah di masa depan.
Keuntungan dari model ini adalah adanya metode yang daoat bekerja dan
menunjukkan kekurangan desain dan fungsi pada tahap pengembangan yang sangat dini.
Menemukan permasalahan sedini mungkin memungkinkan pengembang untuk mengambil
tindakan korektif dalam anggaran terbatas.
Kerugian model SDLC ini adalah bahwa iterative model hanya dapat dilakukan pada
pengembangan software berskala besar. Ini diikarenakan, sulitnya memecah sistem
perangkat lunak sederhana.
Keuntungan dari Iterative dan Incremental SDLC Model adalah sebagai berikut :
a. Memungkinkan pengerjaan dan pengembangan fungsi-fungsi yang ingin dijalankan
secara cepat dalam tahap awal pengerjaan.
b. Hasil diperoleh awal dan berkala.
c. Pengembangan paralel dapat direncanakan.
d. Kemajuan yang dapat diukur.
e. Sumber daya untuk mengubah ruang lingkup / persyaratan lebih sedikit.
f. Mudah melakukan pengujian dan perbaikan pada pengulangan spesifik.
g. Risiko diidentifikasi dan diselesaikan selama iterasi; setiap iterasi
merupakan milestones yang mudah dikelola.
h. Lebih mudah mengelola risiko – Bagian berisiko tinggi dilakukan terlebih dahulu.
i. Dengan setiap peningkatan, operasional produk dikirimkan.

j. Masalah, tantangan, dan risiko yang diidentifikasi dari setiap kenaikan dapat
dimanfaatkan / diterapkan pada kenaikan berikutnya.
k. Analisis risiko lebih baik.
l. Mendukung perubahan persyaratan.
m. Waktu pengoperasian awal cenderung singkat.
n. Cocok untuk proyek-proyek besar dan penting.
o. Selama siklus, software dihasilkan lebih awal, memberikan ruang evaluasi dan umpan
balik pelanggan.
Kerugian dari SDLC iterative model adalah sebagai berikut:

a. Kemungkinan memerlukan lebih banyak sumber daya.
b. Meskipun biaya perubahan lebih rendah, tetapi tidak terlalu cocok untuk mengubah
persyaratan.
c. Dibutuhkan lebih banyak perhatian manajemen.
d. Arsitektur sistem atau masalah desain mungkin muncul karena tidak semua
persyaratan dikumpulkan pada awal seluruh siklus hidup.
e. Menentukan peningkatan mungkin memerlukan definisi sistem yang lengkap.
f. Tidak cocok untuk proyek yang lebih kecil.
g. Kompleksitas manajemen lebih banyak.
h. Risiko pada proyek akhir mungkin kurang diketahui.
i. Memerlukan sumber daya yang terampil untuk analisis risiko.
j. Kemajuan proyek sangat tergantung pada fase analisis risiko.
2.7 Object Oriented Technology

Object Oriented Technology merupakan cara pengembangan perangkat lunak
berdasarkan abstraksi objek-objek yang ada di dunia nyata. Dasar pembuatan adalah
Objek, yang merupakan kombinasi antara struktur data dan perilaku dalam satu entitas.
Filosofi Object Oriented sangat luar biasa sepanjang siklus pengenbangan perangkat
lunak (perencanaan, analisis, perancangan dan implementasi) sehingga dapat diterapkan
pada perancangan sistem secara umum: menyangkut perangkat lunak, perangkat keras
dan sistem secara keseluruhan.
Kosep-konsep Object Oriented :

1. Kelas
Kelas adalah konsep OO yang mengencapsulasi/membungkus data dan abstraksi
prosedural yang diperlukan untuk menggambarkan isi dan tingkah laku berbagai
entitas. Kelas juga merupakan deskripsi tergeneralisir (misl template, pola, cetak biru)
yang menggambarkan kumpulan objek yang sama.
2. Objek
Objek digambarkan sebagai benda, orang, tempat dan sebagainya yang ada di dunia
nyata yang penting bagi suatu aplikasi. Objek mempunyai atribut dan metoda.
3. Atribut
Atribut menggambarkan data yang dapat memberikan informasi kelas atau objek
dimana atribut tersebut berada.
4. Metoda/Servis/Operator
Metoda adalah prosedur atau fungsi yang tergabumh dalam objek bersama dengan
atribut. Metode ini digunakan untuk pengaksesan terhadap data yang terdapat dalam
objek tersebut.

5. Message
Message adalah alat komunikasi antar objek. Hubungan antar objek ditentukan oleh
problem domain dan tanggung jawab sistem.
6. Event
Event adalah suatu kejadian pada waktu yang terbatas yang menggambarkan
rangsangan (stimulus) dari luar sistem.
7. State
State adalah abstraksi dari nilai atribut dan link dalam sebuah objek. State merupakan
tanggapan dari objek terhadap event-event masukan.
8. Skenario
Skenario adalah urutan event yang terjadi sepanjang eksekusi sistem
Karakteristik-karakteristik yang terdapat dalam metode pengembangan sistem berorientasi

objek adalah:
a. Encapsulation
Encapsulation merupakan dasar untuk membatasi ruang lingkup program terhadap
data yang diproses. Data dan prosedur dikemas dalam suatu objek sehingga prosedur
lain dari luar tidak dapat mengaksesnya. Data akan terlindungi dari prosedur atau
objek lain.
b. Inheritance
Inheritance (pewarisan) adalah teknik yang menyatakan bahwa anak dari objek akan
mewarisi data/atribut dan metode dari induknya langsung. Suatu kelas dapat
ditentukan secara umum, kemudian ditentukan secara spesifik menjadi subkelas.
Setiap subkelas mempunyai hubungan atau mewarisi semua sifat yang dimiliki kelas
induknya dan ditambah dengan sifat nik yang dimilikinya.
c. Polymorphism
Polymorphism menyatakan bahwa sesuatu yang sama dapat mempunyai bentuk dan
perilaku berbeda. Polimorfisme juga menyatakan bahwa operasi yang sama mungkin
mempunyai perbedaan kelas.
Tahapan-Tahapan Object Oriented Technology

Pada Object Oriented Technology ada beberapa metode yang digunakan dalam
pengembangan sistem. Salah satu yang terkenal adalah OMT (Object Modelling
Technique). Aktivitas-aktivitas yang dilakukan dalam OMT ini adalah:
• Model Objek
• Model Dinamis
• Model Fungsional
Kelebihan
• Uniformity, OMT memungkinkan merancangn user interface secara terintegrasi
bersama dengan perancangan perangkat lunak sekaligus dengan perancangan
basis data.
• Understandability, Kode-kode yang dihasilkan dapat diorganisasi ke dalam kelas-
kels yang berhubungan dengan masalah sesungguhnya sehingga lebih mudah
dipahami.
• Stability, Kode program yang dihasilkan relatif stabil sebab mendekati
permasalahn sesungguhnya dilapangan.
• Reusability, Dimungkinkan penggunaan kembali kode-kode sehingga akan
mempercepat waktu pengembangan perangkat lunak.

Kelemahan
Metode berorientasi objek merupakan konsep yang relatif baru sehingga belum ada
standar yang diterima semua pihak dalam menentukan tool apa yang digunakan sebagai
dasar analisi serat perancangan perangkat lunak.
2.8 Metode End-user Development

Disini pengembangan dilakukan langsung oleh end-user. Keterlibatan langsung end-user
sangat menguntungkan, karena memahami benar bagaimana sistem bekerja. Artinya
tahap analisis sistem dapat dilakukan lebih cepat. Kelemahan adalah pada pengendalian
mutu dan kecenderungan tumbuhnya “private”sistem informasi. Integrasi dengan sistem
yang lain menjadi sulit.
Tahapan-tahapan EUD
• Tahap inisasi (initiation), Yaitu tahap dimana organisasi(perusahaan) mulai pertama
kali mngenal teknologi informasi.
• Tahap ketularan (contagion)
• Tahap kendali (control)
• Tahap matang (mature)
Kelebihan
• Dapat menghindari permasalahan kemacetan di departemen sistem informasi.
• Kebutuhan pemakai sistem dapat lebih terpenuhi karena dapat dikembangkan
sendiri oleh pemakai.
• Menambah atau meningkatkan partisifasi aktif pemakai dalam proses
pengembangan sistemnya sehingga akan ada kepuasan sendiri dari pemakai
sistem.
• Dapat menambah kualitas pemahaman pemakai terhadap aplikasi yang
dikembangkan serta teknollogi yang digunakan dalam sistem.
Kekurangan
• Karena pemakai sistem harus mengembangkan aplikasinya sendiri, maka dalam
hal ini pemakai sekaligus pengembang sistem dituntut untuk memiliki pemahaman
mengenai teknologi informasi (computer literacy) serta pemahaman tentang
pengembangan sistem infomasi.
• End user computing memiliki resiko dapat menggangu bahkan merusak system
informasi di luar yang dikembangkan oleh pemakai sistem.
• End user computing pasti akan berhadapan dengan maslah kemampuan teknis
pemakai sekaligus pengembang sistem.

BAB III
ANALISA SISTEM INFORMASI
3.1 Pendekatan Analisi Model Driven

Analisis sistem merupakan salah satu tahapan penting dalam pengembangan sistem.
Analisis sistem adalah teknik pemecahan masalah yang menguraikan bagian-bagian
komponen tersebut bekerja dan berinteraksi untuk mencapai tujuan mereka (Al Fatta,
2007). Analisis sistem merupakan tahapan paling awal dari pengembangan sistem yang
menjadi fondasi menentukan keberhasilan sistem informasi yang dihasilkan nantinya.
Tahapan ini sangat penting karena menentukan bentuk sistem yang harus dibangun.
Proses pengembangan sistem sangat tergantung pada hasisl analisis sistem. Ketika salah
analaisis, maka tahapan berikutnya akan ikut salah yang bisa mengakibatkan gagalnya
proses pengembangan sistem. Tahap analisis sistem merupakan fase awal dalam
pengembanagan sistem informasi yang difokuskan pada permasalahan sistem lama, dan
kebutuhan bisnis sistem, terlepas dari teknologi apapun yang akan digunakan untuk
mengimplementasikan sousi pada masalah tersebut.
Tujuan utama dari analisis sistem informasi, adalah:
1. Menentukan kelemahan dari proses-proses bisnis pada sistem lama.
2. Menentukan kebutuhan dari sistem baru untuk mengatasi permasalahan pada sistem
lama.
3. Menentukan tingkat kelayakan kebutuhan sistem baru ditinjau dari beberapa aspek,
diantaranya ekonomi, teknik, operasional, dan hukum.
Model driven adalah analisis yang menggunakan gambar untuk mengkombinasikan

masalah-masalah, persyaratan-persyaratan, dan solusi-solusi bisnis. Contoh model yang
dipakai adalah flowchart dan DFD. Contoh dari analisis dengan pendekatan model driven
adalah:
a. Analisis Terstruktur
Analisis ini terfokus pada aliran data dan proses bisnis dan perangkat lunak yang
disebut dengan process oriented. Analisis terstruktur sederhana dalam konsep. Para
analis menggambarkan serangkaian proses dalam bentuk diagram alir data data flow
diagram yang menggambarkan proses yang ada atau yang diusulkan bersama-sama
dengan input, output dan file mereka.
b. Rekayasa Informasi dan Pemodelan Data
Rekayasa informasi dulu terfokus pada struktur data yang tersimpan pada sebuah
sistem yang disebut dengan data centered. Model-model data dalam rekayasa
informasi disebut entity relationship. Rekayasa informasi dikatakan berpusat pada data
karena menekankan pada pembelajaran dan analisis persyaratan data sebelum
persyaratan- persyaratan proses. Hal ini didasarkan pada tingkat kepercayaan bahwa
data dan pengetahuan adalah sumber daya perusahaan yang harus direncanakan dan
dipelihara. Akibatnya analis menggambarkan model data mentah ke dalam hubungan
entitas, baru kemudian membuat diagram aliran data yang menjelaskan proses-proses
yang terjadi.
c. Analisis Berorientasi Objek
Sebagian besar pendekatan pengembangan sistem telah memisahkan pengetahuan
data dari proses. Teknik objek muncul untuk memisahkan menghilangkan pemisahan
data dan proses ini. Sebaliknya data dan proses spesifik yang membuat, membaca,
memperbaharui atau menghapus data itu diintegrasikan ke dalam konstruksi yang

disebut data atau objek. Satu-satunya cara untuk membuat, membaca, memperbaharui
atau menghapus data adalah dengan cara proses perlekatan embeded yang disebut
metode OOA adalah teknik yang model driven yang mengintegrasikan data dan proses
yang disebut objek. Model OOA adalah gambar-gambar yang mengilustrasikan objek-
objek sistem dari berbagai perspektif, seperti struktur, perilaku dan interasi antar objek.
Contoh yang paling terkenal adalah UML Unified Modelling Language.
3.2 Analisis Kebutuhan Sistem

Analisis kebutuhan sistem merupakan tahapan awal dan utama untuk membuat
pondasi dalam langkah pengembangan sistem. Hasil dari analisa kelemahan sistem dapat
digunakan untuk merekomendasikan analisa kebutuhan sistem (requirement system) dan
juga rekomendasi fungsionalitas apa saja yang dibutuhkan sistem baru. Analisis
kebutuhan sistem mencakup dua hal pokok yaitu analisis kebutuhan fungsional dan
analisis kebutuhan nonfungsional. Analisis kebutuhan fungsional mempunyai tujuan untuk
mendapatkan informasi terkait kebutuhan yang berisi proses-proses apa saja yang
nantinya dilakukan sistem informasi perwalian mahasiswa ini. Analisis kebutuhan
nonfungsional mempunyai perbedaan dengan analisis sebelumnya, yaitu untuk
mendapatkan informasi terkait dengan kebutuhan-kebutuhan yang meliputi properti
perilaku-perilaku yang dimiliki oleh sistem
Tujuan dari analisis pebutuhan sistem yaitu memahami sebenar-benar kebutuhan
sistem yang baru, yang dapat juga diartikan:
1. Pernyataan tentang apa yang harus dikerjakan oleh sistem
2. Pernyatan tentang karakterisktik yang harus dimiliki sistem
Tipe tipe Kebutuhan sistem:

1. Operasional yang menjelaskan teknis bagaimana sistem baru akan beroperasi.
2. Kinerja yang menjelaskan seberapa bagus kinerja perangkat lunak yang
dikembangkan dalam mengolah data, menampilkan informasi, dan secara
keseluruhan menyelesaikan proses bisnis.
3. Keamanan, berisi pernyataan tentang mekanisme pengamanan aplikasi, data,
maupun transaksi yang akan diimplementasikan pada sistem.
4. Politik dan Budaya, isinya menyangkut atau berhubungan dengan isu politik dan
budaya yang tidak menimbulkan persepsi negatif terhadap sistem.
Tahap requirement analysis adalah tahap interaksi intensif antara analis sistem
dengan komunitas pemakai sistem (end-user), dimana team pengembangan sistem
menunjukkan keahliannya untuk mendapatkan tanggapan dan kepercayaan pemakai,
sehingga mendapat partisipasi yang baik. Merupakan pekerjaan sulit untuk mendapatkan
kesepakatan (skeptical) pemakai tentang kebutuhan mereka dari sebuah sistem informasi,
karena mungkin pemakai mengalami kegagalan sistem informasi sebelumnya. Tahap awal
dalam requirement system adalah melakukan survey terhadap keinginan pemakai dan
menjelaskan sistem informasi yang ideal. Ideal disini merupakan konsep daripada
kenyataan, artinya bahwa tidak ada sistem yang ideal (tidak ada sistem informasi yang
sempurna) tetapi bersifat subyektif saja.
3.3 Metode Pengumpulan Data

Perlunya pemilihan metode pengumpulan data yang tepat selama melakukan
requirement system. Metode pengumpulan data berupa suatu pernyataan (statement)
tentang sifat keadaan, kegiatan tertentu dan sejenisnya. Pengumpulan data dilakukan

untuk memperoleh informasi yang dibutuhkan dalam rangka mencapai tujuan penelitian
(Gulo, 2002 : 110). Proses pengumpulan data (PULTA) yang dilakukan pada Pembahasan
Sistem Berjalan dalam fase tahap analisa ini, merupakan proses awal yang sangat penting
untuk mendapatkan data yang akurat.
Metode tersebut adalah interviews, questionnaires, observation, procedure analysis,
dan document survey. Setiap metode akan dijelaskan secara mendalam sebagai berikut:
1. Tanya jawab (Interviews)
a. Bagaimana metode itu digunakan.
▪ Pemilihan potential interviewees.
▪ Membuat perjanjian terhadap potential interview.
▪ Menyiapkan struktur pertanyaan yang lengkap dan jelas.
▪ Memilih person yang di interview secara pribadi dan merekamnya.
b. Target dari metode.
▪ Kunci pribadi dalam proses DFD.
▪ Kadangkala melibatkan orang luar, seperti pelanggan atau vendors.
c. Keuntungan metode.
▪ Pewawancara dapat mengukur respon melalui pertanyaan dan
menyesuaikannya sesuai situasi yang terjadi.
▪ Baik untuk permasalahan yang tidak terstruktur, seperti mengapa anda berpikir
hal ini dapat terjadi ?.
▪ Menunjukkan kesan interviewer secara pribadi.
▪ Memunculkan respons yang tinggi sejak penyusunan pertemuan.
d. Kerugian metode.
▪ Membutuhkan waktu dan biaya yang tidak sedikit.
▪ Membutuhkan pelatihan dan pengalaman khusus dari pewawancara.
▪ Sulit membandingkan laporan wawancara karena subyektivitas alamiah.
e. Kapan metode tersebut baik digunakan.
▪ Mendapatkan penjelasan atau pandangan dari personel kunci.
▪ Test kredibilitas dari interviewees.
▪ Mencari interview yang unsureness atau contradictions.
▪ Memantapkan kredibilitas team. Beberapa faktor penting dalam interview yang
baik, yaitu objektives, audience, format, weighting dan combining responses,
and docummentation.
2. Kuesioner (Questionnaires)
▪ Mendisain dengan menggunakan standar kuesioner.
▪ Kuesioner dikirimkan ke lingkungan kerja end-users.
▪ Struktur respon diringkas dalam statistik distribusi.
b. Target dari metode
▪ Semua end-user dengan wawasannya akan dilibatkan dalam proses solusi
pemecahan sistem.
▪ End-user dihubungkan dengan proses pemakaian simbol-simbol dalam DFD.
▪ Murah dan cepat dari pada interviews.
▪ Tidak membutuhkan investigator yang terlatih (hanya satu ahli yang dibutuhkan
untuk mendesain kuesioner untuk end-user yang terpilih.
▪ Mudah untuk mensintesis hasil sejak pembuatan kuesioner.
▪ Dengan mudah dapat meminimalkan biaya untuk semua end-user.

d. Kerugian metode.
▪ Tidak dapat membuat pertanyaan yang spesifik bagi end-user.
▪ Analis melibatkan kesan sehingga tidak dapat menampakkan pribadi end-user.
▪ Tanggapan yang rendah karena tidak adanya dorongan yang kuat untuk
mengembalikan kuesioner.
▪ Tidak dapat menyesuaikan pertanyaan ke end-user secara spesifik.
▪ Pertanyaannya sederhana, dan tidak memiliki arti mendua.
▪ Membutuhkan wawasan yang luas dari end-user.
▪ Bila memiliki sedikit waktu dan biaya.
3. Observasi (Observation)
▪ Secara pribadi seorang analis mengunjungi lokasi pengamatan.
▪ Analis merekam kejadian dalam lokasi pengamatan, termasuk volumen dan
pengolahan lembar kerja.
▪ Lokasi proses secara geografis ditunjukkan dalam DFD (Data Flow Diagram)
▪ Mendapatkan fakta records daripada pendapat (opinion).
▪ Tidak membutuhkan konstruksi pertanyaan.
▪ Tidak menganggu atau menyembunyikan sesuatu (end-users tidak mengetahui
bahwa mereka sedang diamati).
▪ Analis tidak bergantung pada penjelasan lisan dari end-users.
d. Kerugian metode
▪ Jika terlihat, analis mungkin mengubah operasi (end-user merasa diamati).
▪ Dalam jangka panjang, fakta yang diperoleh dalam satu observasi mungkin
tidak tepat (representative) dalam kondisi harian atau mingguan.
▪ Membutuhkan pengalaman dan kehlian khusus dari analis.
▪ Membutuhkan gambaran kuantitatif seperti waktu, volume dan sebagainya.
▪ Kecurigaan bahwa end-user mengatakan suatu kejadian yang sebenarnya tidak
terjadi (dibuat-buat).
4. Sumber data
a. Data Primer
Data penelitian yang diperoleh sendiri melalui: Wawancara, Observasi, Tes,
kuesioner (Daftar Pertanyaan), Pengukuran Fisik, Percobaan Laboratorium.
b. Data Sekunder
Data yang diperoleh dari sumber kedua, dokumentasi lembaga: Biro Pusat Statistik
(BPS), Rumah sakit, Lembaga atau institusi.
5. Pengamatan Dokumen (Document Survey)

▪ Mengidentifikasikan dokumen utama dan laporan (physical data flow diagram).
▪ Mengumpulkan salinan dokumen aktual dan laporan.
▪ Setiap dokumen atau laporan, digunakan untuk record data, meliputi field
(ukuran dan tipe), frekuensi penggunaan dan struktur kodingnya (coding
structure).


Aliran data kunci ditunjukkan dalam data flow diagram (DFD).
▪ Meminimalkan interupsi dari fungsi operasionalnya.
▪ Permulaan elemen kamus data.
▪ Seringkali, dapat mempertimbangkan modifikasi major procedural.
d. Kerugian metode
Membutuhkan waktu yang cukup (terdapat organisasi bisnis yang mengalami
kebanjiran dokumen dan laporan).
Harus dikerjakan jika sebuah sistem akan didesain (selama kegiatan analisis,
dalam memperjelas desain sistem yang baru dan analisis dokumen dapat
membantu untuk menentukan tugas perancangan selanjutnya).
6. Sampling
Sampling dapat membantu mengurangi waktu dan biaya. Perlu kecermatan untuk
memilih sample dari populasi, sehingga membutuhkan keahlian statistik supaya tidak
mengalami kegagalan atau ancaman.
7. Dokumen Analisis Kebutuhan

a. Arahan (conduct) analisis
▪ Hubungan dengan pemakai akhir
▪ Menganalisa records, forms dan laporan
▪ Pengamatan proses.
▪ Menganalisa metode yang digunakan.
▪ Permasalahan dalam pengumpulan data.
b. Kebutuhan pemakai.
▪ Apa yang menjadi kebutuhan sebenarnya.
▪ Kebutuhan laporan (jenis dan frekuensinya).
▪ Kebutuhan pelatihan.
▪ Pengaruh sistem baru.
c. Kendala sistem.
▪ Menjelaskan kendala waktu, biaya, keahlian, teknologi dan faktor ekternal.
▪ Realistik sistem.
d. Dokumentasi.
▪ Intrumen pengumpulan data (kebutuhan kuesioner, interview).
▪ Konsensus statistik.
▪ Aliran data secara logikal dan phisik.
▪ Element awal dalam kamus data.
3.4 Perumusan Proses Bisnis

Bisnis Proses adalah suatu kumpulan pekerjaan yang saling terkait untuk
menyelesaikan suatu masalah tertentu. Suatu proses bisnis dapat dipecah menjadi
beberapa subproses yang masing-masing memiliki atribut sendiri tapi juga berkontribusi
untuk mencapai tujuan dari superprosesnya. Analisis proses bisnis umumnya melibatkan
pemetaan proses dan subproses di dalamnya hingga tingkatan aktivitas atau kegiatan.
Beberapa karakteristik umum yang dianggap harus dimiliki suatu proses bisnis adalah:
a. Definitif: Suatu proses bisnis harus memiliki batasan, masukan, serta keluaran yang
jelas.

b. Urutan: Suatu proses bisnis harus terdiri dari aktivitas yang berurut sesuai waktu dan
ruang.
c. Pelanggan: Suatu proses bisnis harus mempunyai penerima hasil proses.
d. Nilai tambah: Transformasi yang terjadi dalam proses harus memberikan nilai tambah
pada penerima.
e. Keterkaitan: Suatu proses tidak dapat berdiri sendiri, melainkan harus terkait dalam
suatu struktur organisasi.
f. Fungsi silang: Suatu proses umumnya, walaupun tidak harus, mencakup beberapa
fungsi.
Contoh Proses Bisnis

1. Pendaftaran Anggota.
Seorang calon anggota yang belum menjadi anggota perpustakaan dapat
mendaftarkan diri dengan mengisi formulir pendaftaran. Setelah mengisi formulir
tersebut, maka data calon anggota dapat di input kedalam sistem oleh pustakawan.
Pustakawan mencetak kartu anggota dan menyerahkan ke anggota perpustakaan.
2. Pengolahan
Pustakawan harus memasukkan data koleksi bahan pustaka yang dibelinya ke dalam
sistem. Proses pengelolan akan dilaksanakan dan pustakawan dapat mencetak label
koleksi untuk masing-masing koleksi bahan pustaka.
3. Peminjaman.
Koleksi bahan pustaka yang telah melalui proses pengolahan, dapat dipinjamkan
kepada anggota. Saat seorang anggota meminjam koleksi bahan pustaka,
pustakawan harus memasukkan nomor keanggotaan, dan sistem akan menyimpan
data peminjaman serta menampilkan form untuk menambahkan data lengkap
peminjaman. Pustakawan mengisikan nomor dari koleksi bahan pustaka yang akan
dipinjam dan tanggal pengembalian.
4. Pengembalian.
Pustakawan harus mencatat data pengembalian, pada saat anggota mengembalikan
buku pinjamannya. Pustakawan mengisikan nomor dari koleksi bahan pustaka yang
dikembalikan pada form Pengembalian. Pada form ini terdapat informasi seperti
anggota peminjam, koleksi bahan pustaka yang telah dipinjam tapi belum
dikembalikan, tanggal pengembalian, denda yang harus dibayar, dan perpanjangan
waktu peminjaman.

BAB IV
ENTITY RELATIONSHIP DIAGRAM (ERD), SPESIFIKASI FILE
DAN PENGKODEAN
4.1 ERD (Entity Relationship Diagram)

ERD (Entity Relationship Diagram) adalah suatu model untuk menjelaskan hubungan
antar data dalam basis data berdasarkan objek-objek dasar data yang mempunyai
hubungan antar relasi.ERD untuk memodelkan struktur data dan hubungan antar data,
untuk menggambarkannya digunakan beberapa notasi dan simbol.
Menurut salah satu para ahli, Brady dan Loonam (2010), Entity Relationship Diagram
(ERD) merupakan teknik yang digunakan untuk memodelkan kebutuhan data dari suatu
organisasi, biasanya oleh System Analys dalam tahap analisis persyaratan proyek
pengembangan system. Sementara seolah-olah teknik diagram atau alat peraga
memberikan dasar untuk desain database relasional yang mendasari sistem informasi
yang dikembangkan. ERD bersama-sama dengan detail pendukung merupakan model
data yang pada gilirannya digunakan sebagai spesifikasi untuk database.
Atau pengertian sempitnya adalah sebuah konsep yang mendeskripsikan hubungan
antara penyimpanan (database) dan didasarkan pada persepsi dari sebuah dunia nyata
yang terdiri dari sekumpulan objek yaitu disebut sebagai entity dan hubungan atau relasi
antar objek- objek tersebut.
Tahapan ERD :
• Tahap pertama pada desain sistem informasi menggunakan model ER adalah
menggambarkan kebutuhan informasi atau jenis informasi yang akan disimpan dalam
database. Teknik pemodelan data dapat digunakan untuk menggambarkan setiap
ontologi (yaitu gambaran dan klasifikasi dari istilah yang digunakan dan hubungan
anatar informasi) untuk wilayah tertentu.
• Tahap berikutnya disebut desain logis, dimana data dipetakan ke model data yang
logis, seperti model relasional. Model data yang loguis ini kemudian dipetakan menjadi
model fisik , sehingga kadang-kadang, Tahap kedua ini disebut sebagai “desain fisik”.
Metodologi ERD :
Tabel 2. Metode ERD

Simbol-simbol ERD :
Gambar16. Simbol-simbol ERD
a. Entitas
Entiti merupakan objek yang mewakili sesuatu yang nyata dan dapat dibedakan dari
sesuatu yang lain. Simbol dari entiti ini biasanya digambarkan dengan persegi panjang.
b. Atribut
Setiap entitas pasti mempunyai elemen yang disebut atribut yang berfungsi untuk
mendes-kripsikan karakteristik dari entitas tersebut. Isi dari atribut mempunyai sesuatu
yang dapat mengidentifikasikan isi elemen satu dengan yang lain. Gambar atribut diwakili
oleh simbol elips.
• Atribut Key
Atribut Key adalah satu atau gabungan dari beberapa atribut yang dapat membedakan
semua baris data ( Row/Record ) dalam tabel secara unik. Dikatakan unik jika pada atribut
yang dijadikan key tidak boleh ada baris data dengan nilai yang sama
Contoh : Nomor pokok mahasiswa (NPM), NIM dan nomor pokok lainnya
• Atribut simple
atribut yang bernilai atomic, tidak dapat dipecah/ dipilah lagi
Contoh : Alamat, penerbit, tahun terbit, judul buku.
• Atribut Multivalue
nilai dari suatu attribute yang mempunyai lebih dari satu (multivalue) nilai dari atrribute
yang bersangkutan
Contoh : dari sebuah buku, yaitu terdapat beberapa pengarang.
• Atribut Composite
Atribut composite adalah suatu atribut yang terdiri dari beberapa atribut yang lebih kecil
yang mempunyai arti tertentu yang masih bisah dipecah lagi atau mempunyai sub
attribute.

Contoh : dari entitas nama yaitu nama depan, nama tengah, dan nama belakang
• Atribut Derivatif
Atribut yang tidak harus disimpan dalam database Ex. Total. atau atribut yang
dihasilkan dari atribut lain atau dari suatu relationship. Atribut ini dilambangkan dengan
bentuk oval yang bergaris putus-putus
c. Hubungan / Relasi
Hubungan antara sejumlah entitas yang berasal dari himpunan entitas yang berbeda.
Gambar17. Kardinalitas ERD
One to One (1:1)

Setiap anggota entitas A hanya boleh berhubungan dengan satu anggota entitas B, begitu
pula sebaliknya.
Gambar 18. One to One
One to many (1: M / Many)

Setiap anggota entitas A dapat berhubungan dengan lebih dari satu anggota entitas B
tetapi tidak sebaliknya.
Gambar19. One to Many

Many to Many (M:M)

Setiap entitas A dapat berhubungan dengan banyak entitas himpunan entitas B dan
demikian pula sebaliknya
Gambar 20. Many to Many
Contoh Kasus 1 :
Pada saat mendaftar menjadi anggota perpustakaan Fakultas, dicatatlah nama, nomor
mahasiswa dan alamat mahasiswa. Setelah itu mereka baru bisa meminjam buku di
perpustakaan. Buku-buku yang dimiliki perpustakaan banyak sekali jumlahnya. Tiap buku
memiliki data nomor buku, judul, pengarang, penerbit, tahun terbit. Satu buku bisa ditulis
oleh beberapa pengarang. Tentukan entitas, atribut dan relasi dari deskripsi di atas,
dengan menggambar ERD nya.
Jawab:
Entitas : Mahasiswa, KAP (Kartu Anggota Perpustakaan), Buku
Atribut : Nama, no.mahasiswa, Alamat mahasiswa, No.buku, Judul, Pengarang,
Penerbit dan tahun terbit.
Relasi : Daftar dan Pinjam
Gambar ERD dalam peminjaman buku di perpustakaan
Gambar 21. ERD Contoh Kasus 1

contoh Kasus 2 :
Seperti soal nomor 1, namun ada beberapa tambahan penjelasan seperti berikut :
Mahasiswa kadang-kadang terlambat mengembalikan buku, sehingga dikenakan denda.
Besarnya denda adalah Rp 500,- per hari keterlambatan. Mahasiswa dianggap terlambat
jika mengembalikan buku lebih lama dari 1 minggu.
Gambarkan ERDnya:
Gambar 22. ERD contoh kasus 2
Contoh Kasus 3 :
Sebuah perusahaan mempunyai beberapa bagian. Masing-masing bagian mempunyai
pengawas dan setidaknya satu pegawai. Pegawai ditugaskan paling tidak di satu bagian
(dapat pula dibeberapa bagian). Paling tidak satu pegawai mendapat tugas di satu proyek.
Tetapi seorang pegawai dapat libur dan tidak dapat tugas di proyek.
Menentukan entitas
Entitasnya : pengawas, bagian, pegawai, proyek
Menentukan relasi dengan matrik relasi
Tabel 3. Contoh Kasus 3
Hubungkan entitas sesuai dengan matrik relasi yang dibuat
49
Gambar 23. Hubungan Entitas contoh kasus 3
Mengisi kardinalitas
Dari gambaran permasalahan dapat diketahui bahwa:
• masing-masing bagian hanya punya satu pengawas
• seorang pengawas bertugas di satu bagian
• masing-masing bagian ada minimal satu pegawai
• masing-masing pegawai bekerja paling tidak di satu bagian
• masing-masing proyek dikerjakan paling tidak oleh satu pegawai
Mengisi kardinalitas
Menentukan kunci utama :
Kunci utamanya: Nomor Pengawas, Nama Bagian, Nomor Pegawai, Nomor Proyek
Gambar 24. Hubungan Entitas
50
Menentukan Kunci Utama

Menggambar ERD berdasarkan kunci
Ada dua relasi many to many pada ERD sementara, yaitu antara bagian dengan pegawai,
pegawai dengan proyek, oleh sebab itu kita buat entitas baru yaitu bagian -pegawai dan
pegawai-proyek Kunci utama dari entitas baru adalah kunci utama dari entitas lain yang
akan menjadi kunci tamu di entitas yang baru.
Gambar25. ERD berdasarkan Kunci
Menggambar ERD berdasarkan kunci

Menentukan atribut
Atribut yang diperlukan adalah: nama bagian, nama proyek, nama pegawai, nama
pengawas, nomor proyek, nomor pegawai, nomor pengawas
Memetakan atribut
▪ Bagian : Nama bagian
▪ Proyek: Nama proyek
▪ Pegawai:Nama pegawai
▪ Pengawas: Nama pengawas
▪ Proyek-Pegawai : Nomor proyek, Nomor pegawai
▪ Pengawas: Nomor pengawas
Menggambar ERD dengan atribut
51
Gambar 26. ERD berdasarkan Atribut
Periksa apakah masih terdapat redundasi. ERD akhir: untuk pemodelan data pada sistem.
4.2 Spesifikasi File

Menjelaskan tentang file atau tabel yang terbentuk dari transformasi ERD (dan atau filefile
penunjang untuk web). File-file ini tersimpan pada <<namaDatabase>> dengan
parameter-parameter yang telah ditentukan.
Contoh Spesifikasi File

• Spesifikasi File Buku
Nama File : Buku
Akronim : buku.MYD
Tipe File : File Master
Acces File : Random
Panjang Record : 250 bytes
Field Key : kd_buku
Software : MySQL

Tabel 4. Spesifikasi File
4.3 Teknik Pengkodean

Kode digunakan untuk mengklasifikasikan data, memasukan data ke dalam komputer
dan untuk mengambil bermacam-macam informasi yang berhubungan dengannya. Kode
dapat berupa kumpulan angka, huruf dan karakter khusus.
Maksud Pengkodean :
1. Menjaga hubungan dengan sesuatu
Maksud dari pengkodean ini hanya untuk mengenali seseorang, tempat atau hanya
sesuatu untuk menjaga hubungan dengan informasi yang diwakili, yaitu :
a. Urutan kode sederhana, yaitu nomor yang ditandai untuk sesuatu jika memerlukan
penomoran yang tidak memerlukan hubungan dengan dirinya sendiri.
Contoh: 5676 Rocking Chair/with Leather
5677Dining Room Chair/Upholstered
b. Kode Deviasi Abjad, pada umumnya dipakai pendekatan dalam identifikasi suatu
nomor rekening dan untuk mencetak label surat.

Contoh: 15417TNG7533TGP
15417 menunjukkan kode pospelanggan
YNT menujukkan nama pelanggan
7533 menujukkan alamat pelanggan
TGP menujukkan kode majalah
2. Klasifikasi Informasi
Menghasilkan kemampuan untuk membedakan diantara kelas-kelas item, yaitu :
a. Klasifikasi Kode, yaitu pengelompokan untuk membedaan diantara kelas-kelas
item.
Contoh: kelas F
kelas S
F menunjukkan Freshman 1-30 jam kredit
S menunjukkan Sophomore 31-60 jam kredit
b. Blok urutan kode, yaitu untuk menbedakan satu grup data dengan karakteristik
khusus lainnya yang bisa berupa hurup tunggal atau angka.
Contoh: I menunjukkan Interest Payment

M menunjukkan Medical Payments
3. Merahasiakan Informasi Yang digunakan untuk merahasiakan atau menyembunyikan

informasi yang kita tidak ingin orang lain mengetahuinya, yaitu : Kode Chiper yaitu
substitusi langsung satu hurup untuk lainnya, satu angka untuk lainnya atau satu hurup
untuk suatu angka.
Contoh: BLEACHMIND
1234567890
4. Mengumumkan informasi Yang digunakan untuk mengumumkan informasi melalui

suatu kode sehingga membuat informasi data lebih berarti, yaitu :
a. Kode subset digit-signifikasi, yaitu memungkinkan untuk menjelaskan suatu produk
dengan baik dari kategorinya di dalam beberapa grup.
contoh: 202-395-40-10
202= Departement, 395 = Produk
40 = Warna 10 = Ukuran
b. Kode Mnemonik, yaitu menggunakan kombinasi hurup dan simbol untuk mudah
diingat dan dimengerti
Contoh: BDG = Bandung

JKT= Jakarta
Petunjuk Pembuatan Kode

1. Meringkas
2. Menjaga kode tidak berubah
3. Memastikan bahwa kode adalah unik

4. Membiarkan kode dapat diurut

5. Menghindari kode yang mirip
6. Menjaga kode yang seragam
7. Membolehkan modifikasi kode
8. Membuat kode berarti
9. Menggunakan kode
Contoh Format Kode
Gambar 27. Format Pengkodean

BAB V
UNIFIED MODELLING LANGUAGE (UML)
5.1 Terminologi UML

UML (Unified Modeling Language) adalah sebuah bahasa yang berdasarkan grafik/
gambar untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian
dari sebuah sistem pengembangan software berbasis OO (Object-Oriented). UML sendiri
juga memberikan standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis
proses, penulisan kelas-kelas dalam bahasa program yang spesifik, skema database, dan
komponenkomponen yang diperlukan dalam sistem software. UML adalah salah satu tool /
model untuk merancang pengembangan software yang berbasis object oriented. UML
sebagai sebuah bahasa yang memberikan vocabulary dan tatanan penulisan kata-kata
dalam ‘MS Word’ untuk kegunaan komunikasi. Sebuah bahasa model adalah sebuah
bahasa yang mempunyai vocabulary dan konsep tatanan / aturan penulisan serta secara
fisik mempresentasikan dari sebuah sistem.
UML adalah sebuah bahasa standard untuk pengembangan sebuah software yang
dapat menyampaikan bagaimana membuat dan membentuk model-model, tetapi tidak
menyampaikan apa dan kapan model yang seharusnya dibuat yang merupakan salah satu
proses implementasi pengembangan software. UML tidak hanya merupakan sebuah
bahasa pemograman visual saja, namun juga dapat secara langsung dihubungkan ke
berbagai bahasa pemograman, seperti JAVA, C++, Visual Basic, atau bahkan
dihubungkan secara langsung ke dalam sebuah object-oriented database. Begitu juga
mengenai pendokumentasian dapat dilakukan seperti; requirements, arsitektur, design,
source code, project plan, tests, dan prototypes. Untuk dapat memahami UML
membutuhkan bentuk konsep dari sebuah bahasa model, dan mempelajari 3 (tiga) elemen
utama dari UML seperti building block, aturan-aturan yang menyatakan bagaimana
building block diletakkan secara bersamaan, dan beberapa mekanisme umum (common).
Hubungan / Relationship.
Ada 4 macam hubungan didalam penggunaan UML, yaitu;
1. Dependency, adalah hubungan semantik antara dua benda/things yang mana
sebuah benda berubah mengakibatkan benda satunya akan berubah pula.
Umumnya sebuah dependency digambarkan sebuah panah dengan garis terputus-
putus.
2. Association, hubungan antar benda struktural yang terhubung diantara obyek.
Kesatuan obyek yang terhubung merupakan hubungan khusus, yang
menggambarkan sebuah hubungan struktural diantara seluruh atau sebagian.
Umumnya assosiation digambarkan dengan sebuah garis yang dilengkapi dengan
sebuah label, nama, dan status hubungannya.
3. Generalizations, adalah menggambarkan hubungan khusus dalam obyek
anak/child yang menggantikan obyek parent / induk. Dalam hal ini, obyek anak
memberikan pengaruhnya dalam hal struktur dan tingkah lakunya kepada obyek
induk. Digambarkan dengan garis panah.
4. Realizations, merupakan hubungan semantik antara pengelompokkan yang
menjamin adanya ikatan diantaranya. Hubungan ini dapat diwujudkan diantara
interface dan kelas atau elements, serta antara use cases dan collaborations.
Model dari sebuah hubungan realization.

Bagan/Diagram
UML sendiri terdiri atas pengelompokkan diagram-diagram sistem menurut aspek atau
sudut pandang tertentu. Diagram adalah yang menggambarkan permasalahan maupun
solusi dari permasalahan suatu model. UML mempunyai 9 diagram, yaitu; use-case, class,
object, state, sequence, collaboration, activity, component, dan deployment diagram.
1. Use Case Diagram, menggambarkan sekelompok use cases dan aktor yang
disertai dengan hubungan diantaranya. Diagram use cases ini menjelaskan dan
menerangkan kebutuhan / requirement yang diinginkan/ dikehendaki
user/pengguna, serta sangat berguna dalam menentukan struktur organisasi dan
model dari pada sebuah sistem.
2. Class Diagram, yang memperlihatkan struktur statis dari kelas actual didalam
sistem.
3. Object Diagram, yang merupakan varian dari kelas diagram yang memperlihatkan
lebih detail banyaknya obyek yang mengintantiasi (instances) kelas.
4. State Diagram, yang memperliatkan semua keadaan (state) yang dapat dimiliki oleh
kelas dan event yang dapat merubah keadaan tersebut.
5. Sequence Diagram, yang memperlihatkan kolaborasi dinamik antara objek-objek
dengan suatu urutan pesan (a sequence of message) antar objek tersebut.
6. Collaboration Diagram, yang memperlihatkan kolaborasi dinamik antar objek tanpa
memperhatikan aspek waktu.
7. Activity Diagram, yang memperlihatkan aliran urutan aktifitas.
8. Component Diagram, yang memperlihatkan struktur fisik dari source code dalam
terminology code components. Komponen berisi informasi tentang logical class
dapat berupa komponen source code, komponen biner atau komponen yang dapat
dieksekusi.
9. Deployment Diagram, yang memperlihatkan arsitektur fisik dari hardware dan
software pada sistem.
Pemecahan masalah utama dari Object Oriented biasanya dengan penggambaran
dalam bentuk model. Model abstrak (semu) merupakan gambaran detail dari inti masalah
yang ada, umumnya sama seperti refleksi dari problem yang ada pada kenyataan.
Beberapa modeling tool yang dipakai adalah bagian dari dasar UML, kependekan dari
United Modeling Language.
Semakin kompleks bentukan sistem yang akan dibuat, maka semakin sulit komunikasi
antara orang-orang yang saling terkait dalam pembuatan dan pengembangan software
yang akan dibuat. Pada masa lalu, UML mempunyai peranan sebagai software blueprint
(gambaran) language untuk analisis sistem, designer, dan programmer. Sedangkan pada
saat ini, merupakan bagian dari software trade (bisnis software). UML memberikan jalur
komunikasi dari sistem analis kemudian designer, lalu programmer mengenai rancangan
software yang akan dikerjakan. Salah satu pemecahan masalah Object Oriented adalah
dengan menggunakan UML. Oleh karena itu orang-orang yang berminat dalam
mempelajari UML harus mengetahui dasar-dasar mengenai Object Oriented Solving
(pemecahan masalah OO). Tahap pertama, pembentukan model. Model adalah
gambaran abstrak dari suatu dasar masalah. Dan dunia nyata atau tempat dimana
masalah itu timbul bisa disebut dengan domain. Model mengandung obyek-obyek yang
beraktifitas dengan saling mengirimkan messages (pesan-pesan). Obyek mempunyai
sesuatu yang diketahui (atribut /attributes) dan sesuatu yang dilakukan (behaviors atau
operations). Attributes hanya berlaku dalam ruang lingkup obyek itu sendiri (state). Lalu
“blue print” dari suatu obyek adalah Classes (kelas). Obyek merupakan bagian-bagian dari
kelas.

5.2 Diagram Use Case

Diagram Use Case menggambarkan apa saja aktifitas yang dilakukan oleh suatu
sistem dari sudut pandang pengamatan luar. yang menjadi persoalan itu apa yang
dilakukan bukan bagaimana melakukannya. Diagram Use Case dekat kaitannya dengan
kejadian-kejadian. Kejadian (scenario) merupakan contoh apa yang terjadi ketika
seseorang berinteraksi dengan sistem. untuk lebih memperjelas lihat gambaran suatu
peristiwa untuk sebuah klinik kesehatan di bawah ini :
“Pasien menghubungi klinik untuk membuat janji (appointment) dalam pemeriksaan
tahunan. Receptionist mendapatkan waktu yang luang pada buku jadwal dan
memasukkan janji tersebut ke dalam waktu luang itu.” contoh kegiatan pasien yang
membuat janji.
Gambar 28. Contoh Use Case Kegiatan Pasien Membuat Janji
Diagram Use Case berguna dalam tiga hal :

1. Menjelaskan fasilitas yang ada (requirements) Use Case baru selalu menghasilkan
fasilitas baru ketika sistem di analisa, dan design menjadi lebih jelas.
2. Komunikas dengan klien Penggunaan notasi dan simbol dalam diagram Use Case
membuat pengembang lebih mudah berkomunikasi dengan klien-kliennya.
3. Membuat test dari kasus-kasus secara umum Kumpulan dari kejadian-kejadian
untuk Use Case bisa dilakukan test kasus layak untuk kejadian-kejadian tersebut.
5.3 Diagram Class

Diagram Class memberikan pandangan secara luas dari suatu sistem dengan
menunjukan kelas-kelasnya dan hubungan mereka. Diagram Class bersifat statis;
menggambarkan hubungan apa yang terjadi bukan apa yang terjadi jika mereka
berhubungan. Diagram Class mempunyai 3 macam relationalships (hubungan), sebagai
berikut :
1. Association Suatu hubungan antara bagian dari dua kelas. Terjadi association
antara dua kelas jika salah satu bagian dari kelas mengetahui yang lainnya dalam
melakukan suatu kegiatan. Di dalam diagram, sebuah association adalah
penghubung yang menghubungkan dua kelas.
2. Aggregation Suatu association dimana salah satu kelasnya merupakan bagian dari
suatu kumpulan. Aggregation memiliki titik pusat yang mencakup keseluruhan
bagian. Sebagai contoh : OrderDetail merupakan kumpulan dari Order.
3. Generalization Suatu hubungan turunan dengan mengasumsikan satu kelas
merupakan suatu superClass (kelas super) dari kelas yang lain. Generalization
memiliki tingkatan yang berpusat pada superClass. Contoh : Payment adalah
superClass dari Cash, Check, dan Credit.

Untuk tambahan bahwa association mempunyai 2 titik. Salah satu titik bisa memiliki
label untuk menjelaskan association tersebut, contoh : OrderDetail adalah line Item untuk
setiap permintaan.
Panah navigability (pengatur alur arah) dalam suatu association menggambarkan arah
mana association dapat ditransfer atau disusun. Seperti dalam contoh : OrderDetail dapat
disusun dari item-nya, namun tidak bisa sebaliknya. Panah ini juga menjelaskan siapa
“memiliki” implementasi dari association; dalam kasus ini OrderDetail memiliki Item.
Association tanpa arah panah merupakan bidirectional (bolak-balik).
Multiplicity dari suatu titik association adalah angka kemungkinan bagian dari
hubungan kelas dengan single instance (bagian) pada titik yang lain. Multiplicity berupa
single number (angka tunggal) atau range number (angka batasan). Pada contoh, hanya
bisa satu ‘Customer’ untuk setiap ‘Order’, tapi satu ‘Customer’ hanya bisa memiliki
beberapa ‘Order’.
Tabel di bawah mengenai multiplicity yang sering digunakan :
Tabel 5. Multiplicity
Setiap diagram Class memiliki Class (kelas), association, dan multiplicity. Sedangkan
navigability (alur arah) dan role (kegiatan) merupakan optional (tidak diharuskan).
Contoh Diagram Class transaksi Pembelian barang.
Gambar 29. Contoh Diagram Class transaksi Pembelian barang.

5.4 Package dan Object

Untuk mengatur pengorganisasian diagram Class yang kompleks, dapat dilakukan
pengelompokan kelas-kelas berupa package (paket-paket). Package adalah kumpulan
elemen-elemen logika UML. Gambar di bawah ini mengenai model bisnis dengan
pengelompokan kelas-kelas dalam bentuk paket-paket :
Gambar 30. Contoh Pengelompokan Kelas
Ada jenis khusus dari diagram Class yaitu diagram Object. Kegunaannya untuk
penjelasan yang sedikit dengan relasi yang sulit, khususnya relasi rekursif. Lihat gambar
dibawah, diagram Class kecil menunjukkan bahwa ‘department’ dapat mengandung
banyak ‘department’ yang lain.
Gambar 31. Contoh Diagram Class kecil
Setiap tingkatan pada diagram berpengaruh pada single instance (bagian tunggal). Nama
bagian digarisbawahi dalam diagram UML. Untuk Class name (nama kelas) maupun
instance name (nama bagian) bisa mengambil dari diagram Object selama arti diagram
tersebut masih jelas.

Gambar 32. Contoh diagram Class
5.5 Diagram Sequence

Diagram Class dan diagram Object merupakan suatu gambaran model statis. Namun
ada juga yang bersifat dinamis, seperti Diagram Interaction. Diagram sequence
merupakan salah satu diagram Interaction yang menjelaskan bagaimana suatu operasi itu
dilakukan; message (pesan) apa yang dikirim dan kapan pelaksanaannya. Diagram ini
diatur berdasarkan waktu. Obyek-obyek yang berkaitan dengan proses berjalannya
operasi diurutkan dari kiri ke kanan berdasarkan waktu terjadinya dalam pesan yang
terurut. Di bawah ini adalah diagram Sequence untuk pembuatan Hotel Reservation.
Obyek yang mengawali urutan message adalah ‘aReservation Window’.
Contoh 33. Diagram Sequence ‘Pemesanan kamar di Hotel’.
‘Reservation window’ mengirim pesan makeReservation() ke ‘HotelChain’. Kemudian

‘HotelChain’ mengirim pesan yang sama ke ‘Hotel’. Bila ‘Hotel’ punya kamar kosong,
maka dibuat ‘Reservation’ dan ‘Confirmation’. Lifeline adalah garis dot (putus-putus)
vertikal pada gambar, menerangkan waktu terjadinya suatu obyek. Setiap panah yang ada
adalah pemanggilan suatu pesan. Panah berasal dari pengirim ke bagian paling atas dari
batang kegiatan (activation bar) dari suatu pesan pada lifeline penerima. Activation bar
menerangkan lamanya suatu pesan diproses. Pada gambar diagram, terlihat bahwa
‘Hotel’ telah melakukan pemanggilan diri sendiri untuk pemeriksaan jika ada kamar

kosong. Bila benar, maka ‘Hotel’ membuat ‘Reservation’ dan ‘Confirmation’. Pemanggilan
diri sendiri disebut dengan iterasi. Expression yeng dikurung dengan “[ ]”, adalah condition
(keadaan kondisi). Pada diagram dapat dibuat note (catatan). Pada gambar, terlihat
seperti selembar kertas yang berisikan teks. Note bisa diletakan dimana saja pada
diagram UML.
5.6 Diagram Collaboration

Diagram Collaboration juga merupakan diagram interaction. Diagram membawa
informasi yang sama dengan diagram Sequence, tetapi lebih memusatkan atau
memfokuskan pada kegiatan obyek dari waktu pesan itu dikirimkan.
Contoh 34. Diagram Collaboration ‘Pemesanan kamar di Hotel’.
Kotak kegiatan obyek diberi label dengan nama kelas atau obyek (atau keduanya). Nama
kelas dibatasi dengan colons /titik dua ( : ). Setiap pesan pada diagram Collaboration
mempunyai angka yang terurut. Pesan yang tingkatannya tertinggi adalah angka 1. Pesan
yang berada pada tingkat yang sama memiliki prefix yang sama, namun suffix berbeda
bergantung pada posisinya; hanya untuk angka 1, 2, dan seterusnya.
5.7 Diagram StateChart

Behaviors dan state dimiliki oleh obyek. Keadaan dari suatu obye kbergantung pada
kegiatan dan keadaan yang berlaku pada saat itu. Diagram StateChart menunjukan
kemungkinan dari keadaan obyek dan proses yang menyebabkan perubahan pada
keadaannya. Untuk lebih jelas, contoh yang digunakan model diagram untuk login yang
merupakan bagian dari Online Banking System. Logging in terdiri atas masukan input
Social Security Number dan Personal Id Number yang berlaku, lalu memutuskan kesahan
dari informasi tersebut.

Contoh 35. Diagram StateChart ‘Sistem Perbankkan secara Online’
Logging in dapat dibagi menjadi empat tahapan proses, yaitu :

• Getting SSN (masukkan SSN),
• Getting PIN (masukkan PIN),
• Validating (periksa kesahannya), dan
• Rejecting (keluar).
Proses peralihan digambarkan dengan panah dari satu state ke yang lainnya. Event
(peristiwa) atau condition (keadaan) yang menyebabkan perubahan dituliskan pada
samping panah. Diagram ini mengandung dua self-transition (transisi sendiri), satu pada
getting SSN dan lainnya pada getting PIN. Keadaan awal Start (black circle /lingkar hitam)
adalah dummy (model) untuk memulai action (kegiatan). Keadaan akhir juga keadaan
model yang menghentikan kegiatan. Aksi yang terjadi sebagai hasil dari suatu peristiwa
atau keadaan ditandai dalam bentuk /action. Pada Validating State, obyek tidak menunggu
peristiwa dari luar untuk menyebabkan suatu perubahan. Sebagai gantinya melakukan
suatu activity (aktifitas). Hasil dari aktifitas tersebut menentukan keadaan berikutnya dari
obyek tersebut.
5.8 Diagram Activity

Pada dasarnya diagram Activity sering digunakan oleh flowchart. Diagram ini
berhubungan dengan diagram Statechart. Diagram Statechart berfokus pada obyek yang
dalam suatu proses (atau proses menjadi suatu obyek), diagram Activity berfokus
pada aktifitas-aktifitas yang terjadi yang terkait dalam suatu proses tunggal. Jadi dengan
kata lain, diagram ini menunjukkan bagaimana aktifitas-aktifitas tersebut bergantung satu
sama lain. Sebagai contoh, perhatikan proses yang terjadi. “Pengambilan uang dari bank
melalui ATM.” Ada tiga aktifitas kelas (orang, dan lainnya) yang terkait yaitu : Customer,
ATM, and Bank. Proses berawal dari lingkaran start hitam pada bagian atas dan berakhir
di pusat lingkaran stop hitam/putih pada bagian bawah. Aktivitas digambarkan dalam
bentuk kotak persegi. Lihat gambar di bawah ini, agar lebih jelas :

Contoh 36. Diagram Activity ‘Pengambilan Uang melalui ATM’.
Diagram Activity dapat dibagi menjadi beberapa jalur kelompok yang menunjukkan obyek
yang mana yang bertanggung jawab untuk suatu aktifitas. Peralihan tunggal (single
transition) timbul dari setiap adanya activity (aktifitas), yang saling menghubungi pada
aktifitas berikutnya. Sebuah transition (transisi) dapat membuat cabang ke dua atau lebih
percabangan exclusive transition (transisi eksklusif). Label Guard Expression (ada di
dalam [ ]) yang menerangkan output (keluaran) dari percabangan. percabangan akan
menghasilkan bentuk menyerupai bentuk intan. transition bisa bercabang menjadi
beberapa aktifitas paralel yang disebut Fork. Fork beserta join (gabungan dari hasil output
fork) dalam diagram berbentuk solid bar (batang penuh).

5.9 Diagram Component dan Deployment

Component adalah sebuah code module (kode-kode module). Diagram Component
merupakan fisik sebenarnya dari diagram Class. Diagram Deployment menerangkan
bahwa konfigurasi fisik software dan hardware. Gambar 2.10 menerangkan hubungan
sekitar komponen software dan hardware yang berperan dalam ruang lingkup real estate.
Contoh 37. Diagram Deployment ‘Sistem Real Estate’
Fisik hardware berbentuk seperti node-node. Setiap komponen merupakan bagian dari
node. Pada gambar komponen berbentuk dua kotak tersusun yang terletak di sebelah kiri
atas.

BAB VI
ANALISA PERANCANGAN INPUT DAN OUTPUT
6.1 Perancangan INPUT

Merupakan awal dimulainya proses informasi. Bahan mentah dari informasi
adalah data yang terjadi dari transaksi-transaksi yang dilakukan oleh organisasi. Formulir
adalah perangkat penting untuk mengendalikan aliran kerja dan digunakan untuk
menangkap (capture) data yang terjadi sering juga disebut Dokumen Dasar.
Tujuan perancangan input :
a. Membuat penyelesaian input yang mudah dan efisien
b. Menjamin input akan memenuhi tujuan yang diharapkan
c. Menjamin penyelesaian yang tepat.
d. Membuat tampilan layar dan formulir yang menarik
e. Membuat input yang tidak rumit
f. Membuat tampilan layar dan formulir yang konsisten
Terdapat beberapa hal yang perlu diperhatikan dari dokumen dasar.
A. Fungsi dokumen dasar :
1. Dapat menunjukan macam dari data
2. Dapat dicatat dengan jelas, konsisten dan akurat
3. Bertindak sebagai pendistribusian data
4. Membantu pembuktian terjadinya transaksi
5. Dapat digunakan sebagai back up
6. Petunjuk merancang dokumen dasar
7. Kertas yang digunakan
8. Ukuran dari dokumen dasar
9. Warna yang digunakan
10. Judul dokumen dasar
11. Nomor dokumen dasar
12. Nomor urut dokumen dasar
13. Nomor dan jumlah halaman
14. Spasi
15. Pembagian area
16. Caption, yaitu box caption, yes no chech off caption, horizontal check off caption,
blocked spaces caption, scannable from caption
B. Instruksi dalam dokumen dasar :

1. Membuat formulir mudah diisi, yaitu dengan memperhatikan aliran formulir,
pengelompokan tujuh bagian sebuah formulir, pembuatan judul.
2. Memastikan bahwa formulir akan memenuhi tujuan yang telah dibuat
3. Membuat formulir yang memastikan penyelesaian tepat.
4. Buatlah formulir yang menarik
C. Cara mengurangi masukan

Ada beberapa cara yang dapat digunakan untuk mengurangi jumlah masukan, cara
yang dapat dilakukan adalah :
1. menggunakan kode
2. data yang relatif konstan yang disimpan di file induk
3. jam dan tanggal dapat diambil dari sistem
4. rutin perhitungan dilakukan oleh sistem.

D. Rancangan Input di Screen
Contoh 38. Contoh Rancangan Input
6.2 Perancangan OUTPUT
Rancangan Output merupakan hasil dari adanya inputan data yang akan diberikan kepada
entitas luar. Output adalah informasi yang dikirim kepada pengguna melalui sistem
informasi yang dapat berupa : Print, Screen, Audio, CD-ROM or CD-RW, DVD, E-mail,
World Wide Web, Electronic output.
Tujuan dibuat rancangan output adalah :

a. Merancang output untuk tujuan tertentu
b. Membuat output bermanfaat bagi para pengguna
c. Mengirim jumlah output yang tepat
d. Menyediakan distribusi output yang tepat
e. Menyediakan output tepat waktu
f. Memilih metoda output yang paling tepat dan paling efektif
Tipe output :
a. Output internal
b. Output eksternal

a. Bentuk Laporan
1. Laporan berbentuk tabel
• Notice Report : merupakan bentuk laporan yang memerlukan perhatian khusus.
Laporan ini harus dibuat sesederhana mungkin, tetapi jelas, karena dimaksudkan
supaya permasalahan-permasalahan yang terjadi tampak dengan jelas sehingga
dapat langsung ditangani.
Tabel 6. Contoh. Notice Report
LAPORAN PENURUNAN PENJUALAN MENURUT

JENIS BARANG BULAN DESEMBER 2017
Daerah Penjualan X Penurunan
Pontianak 10,00 X
Kubu Raya 45,00 X
Singkawang 12,50 X
• Equiposed Report : Laporan ini biasanya digunakan untuk maksud perencanaan.

Dengan disajikannya informasi yang berisi hal-hal bertentangan, maka dapat
dijadikan sebagai dasar di dalam pengambilan keputusan.
Tabel 7. Contoh. Equipost Report
LAPORAN PERENCANAAN MEMASUKI PASAR YANG BARU

DAERAH PONTIANAK UNTUK TAHUN FISKAL 2017
Jelek Baik
Penjualan
Rp 1.000.000 Rp 1.750.000
Harga pokok penjualan Rp 600.000 Rp 1.050.000
Laba Kotor Rp 400.000 Rp 700.000
Biaya penjualan Rp 300.000 Rp 350.000
Biaya Administrasi Rp 125.000 Rp 150.000
Laba (Rugi) (Rp 25.000) Rp 200.000
• Variance Report : Macam laporan ini menunjukkan selisih (variance) antara

standar yang sudah ditetapkan dengan hasil kenyataannya atau sesungguhnya.

Tabel 8. Contoh. Variance Report
LAPORAN KINERJA DEPARTEMEN PEMBELIAN

BULAN DESEMBER 2017
Barang di Beli Unit Harga Sesungguhnya Harga Standar Selisih Harga Total Selisih
di Beli
IBM PC XT 10 1.200.000 1.050.000 150.000 1.500.000 R
Monitor Color 8 415.000 365.000 50.000 400.000 R
Hard Disk 30 MB 5 595.000 625.000 30.000 150.000 L
Total 170.000 1.750.000 R
• Comparative Report : membandingkan antara satu hal dengan hal yang lainnya.
Misalnya pada laporan rugi/laba atau neraca dapat dibandingkan antara nilai-
nilai elemen tahun berjalan dengan tahun-tahun sebelumnya.
Tabel 9. Contoh Comparative Report
NERACA
31 DESEMBER 2017
(DALAM RIBUAN RUPIAH)
AKTIVA 31-12-2016 31-12-2017 Selisih
Aktiva lancar 45.000 75.000 30.000 66,67%
Aktiva Tetap 155.000 225.000 70.000 45,16%
Total Aktiva 200.000 300.000 100.000 50,00 %
PASIVA
Hutang Lancar 10.000 15.000 5.000 50,00 %
Hutang Jangka
37.500 30.000 (7.500) (20,00%)
Panjang
Modal Saham 130.000 200.000 70.000 53,85%
Latta ditahan 22.500 55.000 32.500 144,44%
Total Pasiva 200.000 300.000 100.000 50,00%
2. Laporan berbentuk grafik

• Garis
Pada bagan garis (line chart), variasi dari data ditunjukkan dengan suatu garis
atau kurva
• Batang
Nilai-nilai data dalam bagan batang (bar chart ) digambarkan dalam bentuk
batang-batang vertikal ataupun batang-batang horisontal.

• Pastel
Bagan pastel (pie chart) merupakan bagan yang berbentuk lingkaran menyerupai
kue pastel (pie). Tiap tiap potong dari pie dapat menunjukkan bagian dari data.
b. Mengatur tata letak isi output :

Cara penggambaran bagan tata letak printer :
1. Bentuk dari literal dapat ditulis apa adanya
2. Nilai suatu data yang berasal dari suatu field atau variabel ditunjukan oleh bentuk
edit-mask
3. Nomor dapat digunakan sebagai acuan nilai data di kamus data output
4. Panah kebawah menunjukan cara penggambaran spasi di bagan tata letak printer,
yaitu :
• Spasi tunggal
• Spasi dua/lebih
• Dengan baris tertentu
• Kombinasi percetakan
Langkah-langkah untuk menyiapkan prototipe output berbasis layar :

1. Menentukan kebutuhan akan laporan tersebut.
2. Menentukan pengguna.
3. Menentukan item-item data yang dimasukan
4. Mengestimasi ukuran laporan secara keseluruhan
5. Judul laporan
6. Nomor halaman
7. Memasukan tanggal persiapan laporan
8. Memberi label setiap kolom data secara tepat.
9. Menentukan data-data varabel
10. Menunjukan tempat baris-baris kosong
11. Mengulas laporan-laporan prototype
Petunjuk untuk merancang layar :

1. Buatlah layar yang sederhana
2. Buatlah presentasi layar tetap konsisten
3. Fasilitasi gerakan pengguna di antara layar
4. Ciptakan suatu layar yang menarik

BAB VII
PENGUJIAN PERANGKAT LUNAK DAN PEMELIHARAAN SISTEM
7.1 PENGUJIAN PERANGKAT LUNAK

Pengujian perangkat lunak (bahasa Inggris: software testing) merupakan suatu
investigasi yang dilakukan untuk mendapatkan informasi mengenai kualitas dari produk
atau layanan yang sedang diuji (under test). Pengujian perangkat lunak memberikan
pandangan mengenai perangkat lunak secara obyektif dan independen. Pengujian
Perangkat Lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan
merepresentasikan kajian pokok dari spesifikasi, desain dan pengkodean.
Dasar-dasar Pengujian Perangkat Lunak

Pengembang perangkat lunak sesuai dengan sifatnya dasar mereka adalah
manusia pembangun. Pengujian mengharuskan pengembang membuang pemikiran-
pemikiran sebelumnya mengenai “kebenaran” perangkat lunak yang baru saja
dikembangkan dan mengatasi konflik minat yang terjadi pada saat kesalahan ditemukan.
Sasaran Pengujian
1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan
kesalahan.
2. Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk
menemukan kesalahan yang belum pernah ditemukan sebelumnya.
3. Pengujian yang sukses adalah pengujian yang mengungkapkan semua kesalahan
yang belum pernah ditemukan sebelumnya.
Prinsip Pengujian
1. Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan.
2. Pengujian harus direncanakan lama sebelum pengujian itu mulai.
3. Prinsip Pareto berlaku untuk pengujian perangkat lunak.
4. Pengujian harus mulai “dari yang kecil” dan berkembang menjadi pengujian
“yang besar”
5. Pengujian yang mendalam tidak mungkin.
6. Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak ketiga yang
independen.
Karakteristik pengujian perangkat lunak :

1. Operabilitas, Semakin baik dia bekerja, semakin efisien dia dapat diuji.
2. Obsaikervabilitas, “Apa yang anda lihat adalah apa yang anda uji”.
3. Kontralabilitas, “Semakin baik kita dapat mengontrol perangkat lunak, semakin
banyak pengujian yang dapat diotomasisasi dan dioptimalkan”.
4. Dekomposabilitas, “Dengan mengontrol ruang lingkup pengujian, kita dapat dengen
lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara lebih
halus”.
5. Kesederhaaan, “Semakin sedikit yang kita uji, semakin cepat kita dapat mengujinya
6. Stabilitas, “Semakin sedikit perubahan, semakin sedikit gangguan dalam
pengujian’.
7. Kemampuan untuk dapat dipahami, “Semakin banyak informasi yang kita miliki,
semakin halus pengujian yang akan dilakukan’.

Tujuan Pengujian
1. Menemukan kesalahan (fault) sebanyak mungkin dari perangkat lunak yang diuji
2. Membuat perangkat lunak yang diuji, setelah perbaikan dilakukan, menjadi
perangkat lunak yang berkualitas
3. Melakukan pengujian secara efektif dan efisien
4. Mengumpulkan kesalahan yang terjadi dan menggunakannya untuk tindakan
preventif
Strategi Pengujian
1. Big Bang Pengujian perangkat lunak secara keseluruhan, setelah seluruh
komponen perangkat lunak selesai dibuat
2. Incremental Pengujian secara bertahap
Gambar 39. Strategi Pengujian
1. Unit testing: pengujian komponen individual (modul dipemrograman prosedural atau

class di OOP).
2. Integration testing: pengujian terhadap koleksi dari komponen-komponen yang bekerja
bersamaan.
3. Validation testing: pengujian aplikasi terhadap kebutuhan pengguna.
4. System testing: pengujian aplikasi secara keseluruhan.
Gambar 40. Strategi Incremental

Atribut-atribut pengujian yang baik :

1. Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan.
2. Pengujian yang baik tidak redudan.
3. Pengujian yang baik seharusnya “jenis terbaik”,
4. Pengujian yang tidak boleh terlalu sederhana atau terlalu kompleks.
Desain Test Case

Desain test case merupakan metode pengujian untuk perangkat lunak untuk memastikan
kelengkapan pengujian dan memberikan kemungkinan tertinggi untuk mengungkap
kesalahan pada perangkat lunak. Semua produk yang direkayasa dapat diuji dengan satu
atau dua cara:
1. Dengan mengetahui fungsi yang ditentukan dimana produk yang dirancang untuk
melakukanya, pengujian dapat dilakukan untuk memperlihatkan bahwa masing-
masin fungsi beroperasi sepenuhnya, pada waktu yang sama mencari kesalahan
pada setiap fungsi.
2. Dengan mengetahui kinerja internal suatu produk, maka pengujian dapat dilakukan
untuk memastikan bahwa semua roda gigi berhubungan, yaitu operasi internal
bekerja sesuai dengan spesifikasi dan semua komponen internal telah diamati
dengan baik.
Metode Pengujian Perangkat Lunak

1. Black-box testing
▪ Mengetahui fungsi tertentu suatu produk yang telah dirancang untuk dijalankan,
menguji untuk melihat apakah fungsi sepenuhnya bisa beroperasi dan bebas dari
error.
▪ Test dilakukan termasuk interface perangkat lunak
▪ Tidak peduli dengan struktur logis internal dari perangkat lunak
2. White-box testing
▪ Mengetahui kerja internal dari suatu produk, tes yang semua operasi internal
dilakukan sesuai dengan spesifikasi dan semua komponen internal telah dieksekusi
▪ Melibatkan test yang berkonsentrasi pada pemeriksaan detail prosedural
▪ Logical patch perangkat lunak diuji
▪ Uji kasus latihan dari kondisi dan loop tertentu
Gambar 41. Metode Pengujian Perangkat Lunak

7.2 Pengujian Functional (Black Box)

Menurut Sukamto & Shalahuddin (2015:275-276), “Black-box Testing yaitu menguji
perangkat lunak dari segi spesifikasi fungsional tanpa menguji perangkat lunak dari segi
spesifikasi fungsional tanpa menguji desain dan kode program”.
1. Fokus pada output yang dihasilkan dengan memberikan input dan kondisi eksekusi
2. Membandingkan kesesuaian output dengan spesifikasi kebutuhan fungsional
Gambar 42. Pengujian Fuctional
3. Melengkapi pengujian white box dengan mengungkap kelas yang berbeda dari
kesalahan
4. Berfokus pada persyaratan fungsional dan domain informasi dari perangkat lunak
5. Digunakan selama tahap akhir dari pengujian setelah white box testing telah
dilakukan
6. Tester mengidentifikasi serangkaian kondisi masukan yang sepenuhnya akan
melaksanakan semua persyaratan fungsional untuk program
7. Memenuhi uji kasus berikut:
▪ Mengurangi, dengan jumlah lebih besar dari satu, jumlah uji kasus tambahan
harus dirancang untuk mencapai pengujian yang wajar
▪ Mampu memberitahukan tentang keberadaan atau tidak adanya kelas
kesalahan, yang terkait hanya dengan tugas tertentu.
8. Salah atau hilang fungsi
9. Kesalahan Interface
10. Kesalahan pada struktur data atau akses database eksternal
11. Perilaku atau kinerja kesalahan
12. Inisialisasi dan terminasi kesalahan
Pengujian blackbox berusaha menemukan :

1. Fungsifungsi yang tidak benar atau hilang
2. Kesalahan interface
3. Kesalahan dalam struktur data atau akses database eksternal.
4. Kesalahan kinerja
5. Inisialisasi dan kesalahan terminasi.

Dengan mengaplikasikan teknik blackbox maka kita menarik serangkaian test case yang
memenuhi kriteria beirkut:
1. Test case yang mengurangi, dengan harga lebih dari satu, jumlah test case
tambahan yang harus didesain untuk mencapai pengujian yang dapat
dipertanggung jawabkan
2. Test case yang memberi tahu kita sesuatu mengenai kehadiran atau ketidak
hadiran kelas kesalahan, daripada member tahu kesalahan yang berhubungan
hanya dengan pengujian spesifik.
Kelebihan Black Box Testing

1. Dapat memilih subset test secara efektif dan efisien
2. Dapat menemukan cacat
3. Memaksimalkan testing investmen
Kelemahan Black Box Testing

Tester tidak pernah yakin apakah Perangkat Lunak tersebut benar – benar lulus uji.
7.3 Pengujian Struktural (White Box)

Pengujian White Box adalah metode desain test case yang menggunakan struktur
control desain procedural untuk memperoleh test case. Disebut juga pengujian glassbox.
Pengujian white box adalah pengujian yang didasarkan pada pengecekan terhadap detil
perancangan, menggunakan struktur kontrol dari desain program secara procedural untuk
membagi pengujian ke dalam beberapa kasus pengujian Dengan pengujian whitebox,
perekayasa dapat melakukan:
1. Memberikan jaminan bahwa semua jalur independen pada suatu modul
telah digunakan paling tidak satu kali.
2. Menggunakan semua keputusan logis pada sisi true and false.
3. Mengeksekusi semua loop pada batasan mereka dan pada batas operasional
mereka.
4. Menggunakan struktur data internal untuk menjamin validitasnya.
Kelebihan White Box Testing

1. Kesalahan logika. Digunakan pada sintaks ‘if’ dan pengulangan. Dimana White Box
Testing akan mendeteksi kondisi-kondisi yang tidak sesuai dan mendeteksi kapan
proses pengulangan akan berhenti.
2. Ketidaksesuaian asumsi. Menampilkan asumsi yang tidak sesuai dengan
kenyataan, untuk di analisa dan diperbaiki.
3. Kesalahan ketik. Mendeteksi bahasa pemrograman yang bersifat case sensitive.
Kelemahan White Box Testing

Untuk perangkat lunak yang tergolong besar, White Box Testing dianggap sebagai
strategi yang tergolong boros, karena akan melibatkan sumber daya yang besar untuk
melakukannya
7.4 Pengujian Basis Path

Pengujian basis path adalah teknik uji coba white box yg diusulkan Tom McCabe.
Metode ini memungkinkan perancang test case mendapatkan ukuran kompleks logical
dari perancangan prosedural dan menggunakan ukuran ini sebagai petunjuk untuk
mendefinisikan himpunan jalur (Basis Set) yang akan diuji. Basis Path menggunakan

notasi graph atau flow graph untuk menggambarkan aliran kontrolnya. Test case yang
dilakukan untuk menggunakan basis set tersebut dijamin untuk menggunakan setiap
statemen di dalam program paling tidak sekali selama pengujian. Notasi yang digunakan
untuk menggambarkan jalur eksekusi adalah notasi diagram alir (atau grafik program),
yang menggunakan notasi lingkaran (simpul atau node) dan anak panah (link atau edge).
Notasi ini menggambarkan aliran control logika yang digunakan dalam suatu bahasa
pemrograman. Perangkat yang digunakan :
a) Notasi Diagram Alir
Tabel 10. Notasi Diagram Alir
Untuk menggambarkan pemakaian diagram alir diberikan contoh perancangan prosedural

dalam bentuk flowchart
Gambar 43. Diagram Alir

Selanjutnya diagram alir diatas dipetakan ke grafik alir
Gambar 44. Grafik Alir
b) Cyclomatic Complexity (Kompleksitas Siklomatis)

Cyclomatic complexity adalah metrik PL yang menyediakan ukuran kuantitatif dari
kekompleksan logikal program. Apabila digunakan dalam kontek metode uji coba basis
path, nilai yang dihitung untuk cyclomatic complexity menentukan jumlah jalur independen
dalam basis set suatu program dan memberi batas atas untuk jumlah uji coba yang harus
dikerjakan untuk menjamin bahwa seluruh perintah sekurang-kurangnya telah dikerjakan
sekali. Pada Basis Path Testing, hasil dari cyclomatic complexity digunakan untuk
menentukan banyaknya independent paths. Independent path adalah sebuah kondisi
pada program yang menghubungkan node awal dengan node akhir.
c) Melakukan Test Case
Metode uji coba basis path juga dapat diterapkan pada perancangan prosedural rinci
atau program sumber. Pada bagian ini akan dijelaskan langkah-langkah uji coba basis
path.
Langkah-Iangkah pembuatan test case:
1. Dengan mempergunakan perancangan prosedural atau program sumber sebagai
dasar, digambarkan diagram alirnya.
2. Tentukan cyclomatic complexity untuk diagram alir yang telah dibuat.
3. Tentukan independent path pada flowgraph
4. Buat test case yang akan mengerjakan masing-masing path pada basis set. Data
yang dipilih harus tepat sehingga setiap kondisi dari predicate node dikerjakan
semua. d) Graph Metrik Graph metrik merupakan PL yang dikembangkan untuk
membantu uji coba basis path atau struktur data. Graph metrik adalah matrik empat
persegi yang mempunyai ukuran (sejumlah baris dan kolom) yang sama dengan
jumlah node pada flowgraph. Masing-masing baris dan kolom mempunyai
hubungan dengan node yang telah ditentukan dan pemasukan data matrik
berhubungan dengan hubungan (edge) antanode

DAFTAR PUSTAKA
Adhani, M., Abdillah, L. A., & Widayati, Q. (2015). Analisa dan perancangan sistem informasi
penerimaan siswa baru dan pembayaran SPP menggunakan Zachman Framework.
Seminar Nasional Informatika 2015 (SNIf2015). Universitas Potensi Utama
Akbar, F., Setiaji, S., Ishak, R., Saputra, D., & Masruri, B. (2020). RANCANG BANGUN SISTEM
INFORMASI KARANG TARUNA MENGGUNAKAN METODE WATERFALL. Jurnal
Khatulistiwa Informatika, 8(1).
Al Fatta, H. (2007). Analisis dan Perancangan Sistem Informasi untuk keunggulan bersaing
perusahaan dan organisasi modern. Penerbit Andi.
Bell, D. (2003). UML basics: An introduction to the Unified Modeling Language. The Rational Edge.
Gaol Jimmy, L. (2008). Sistem Informasi Manajemen: Pemahamanan Aplikasi. PT Grasindo.
Ibrahim, N., Ibrahim, R., Saringat, M. Z., Mansor, D., & Herawan, T. (2011). Definition of
Consistency Rules between UML Use Case and Activity Diagram. International Conference
on Ubiquitous Computing and Multimedia Applications, 498–508. Springer.
Jogiyanto, H. M. (2017). Analisis dan Desain (Sistem Informasi Pendekatan Terstruktur Teori dan
Praktek Aplikasi Bisnis). Penerbit Andi.
Kendall, K. E., & Kendall, J. E. (2018). Analisis dan Perancangan sistem. Jakarta: PT INDEKS
Kelompok GRAMEDIA.
Li, Q., & Chen, Y.-L. (2009). Entity-relationship diagram. In Modeling and Analysis of Enterprise
and Information Systems (pp. 125–139). Springer.
Mulyani, S. (2017). Metode Analisis dan Perancangan Sistem. Abdi Sistematika.
Nidhra, S., & Dondeti, J. (2012). Black box and white box testing techniques-a literature review.
International Journal of Embedded Systems and Applications (IJESA), 2(2), 29–50.
Quatrani, T., & Evangelist, U. M. L. (2003). Introduction to the Unified modeling language. A
Technical Discussion of UML, 6(11), 3.
Raymond Jr, M. (2001). Sistem Informasi Manajemen Studi Sistem Informasi Berbasis Komputer.
Versi Bahasa Indonesia, Edisi Ketujuh Jilid II, PT. Prenhallindo, Jakarta.
Saputra, D., Irmayani, W., & Martias, M. (2019). PERANCANGAN SISTEM PELAYANAN
KESEHATAN (SIYANA) PADA PUSKESMAS MENSIKU DESA BINJAI HULU KABUPATEN
SINTANG KALIMANTAN BARAT. Jurnal Mantik Penusa, 3(3).
Saputra, D., Irmayani, W., Martias, M., Sidauruk, J., Haryani, H., Jayanti, W. E., Rahman, A.
(2020). Application of Web-Based Competency Test (UKSI) with Framework Code Igniter
(CI). International Journal of Advanced Science and Technology, 29(No.4 (2020)), 4500–
4520. Retrieved from http://sersc.org/journals/index.php/IJAST/article/view/24856
Sukamto, R. A., & Shalahuddin, M. (2018). Rekayasa Perangkat Lunak (Edisi Revisi). Bandung:
Informatika Bandung.
Sutabri, T. (2012). Analisis sistem informasi. Penerbit Andi.

SIAPASI

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

SIAPASI

Diunggah oleh

Hak Cipta:

Format Tersedia

ANALISA & PERANCANGAN SISTEM INFORMASI

Program Studi Sistem Informasi | DST@2020

Alhamdulillahirobbil‘alamiin serta Puji dan Syukur penulis panjatkan kehadirat Allah

Pontianak, Maret 2020

Dedi Saputra, S.Pd, M.Kom

KATA PENGANTAR ............................................................................................ ii

BAB I TERMINOLOGI SISTEM ........................................................................... 1

BAB II METODE PENGEMBANGAN SISTEM .................................................... 22

BAB III ANALISA SISTEM INFORMASI .............................................................. 39

BAB IV ENTITY RELATIONSHIP DIAGRAM (ERD), SPESIFIKASI FILE DAN

BAB V UNIFIED MODELLING LANGUAGE (UML) ............................................ 56

5.4 Package dan Object.................................................................................. 60

BAB VI ANALISA PERANCANGAN INPUT DAN OUTPUT ............................... 66

BAB VII PENGUJIAN PERANGKAT LUNAK ...................................................... 71

Daftar Pustaka ..................................................................................................... 78

DESKRIPSI MATA KULIAH :

1.1 Terminologi Analisa Sistem Informasi

Program Studi Sistem Informasi | DST@2020 1

Pengertian Analisa Menurut Para Ahli

Informasi : data yang telah diklasifikasikan atau diolah atau di interpretasikan

Program Studi Sistem Informasi | DST@2020 2

1.2 Konsep Dasar Sistem

Program Studi Sistem Informasi | DST@2020 3

Gambar 1. Karakteristik suatu sistem

Program Studi Sistem Informasi | DST@2020 4

2. Batas Sistem (Boundary)

3. Lingkungan Luar Sistem (Environments)

Program Studi Sistem Informasi | DST@2020 5

8. Sasaran (Objectives) atau Tujuan (Goal)

Program Studi Sistem Informasi | DST@2020 6

Gambar 2. Sistem Terbuka

Gambar 3. Sistem Tertutup

Program Studi Sistem Informasi | DST@2020 7

▪ kesalahan-kesalahan yang tidak disengaja yang juga dapat menyebabkan

Pertumbuhan organisasi Pertumbuhan organisasi yang menyebabkan harus

b. Untuk meraih kesempatan-kesempatan (opportunities)

c. Adanya instruksi-instruksi (directives)

Proses pengembangan sistem dapat digambarkan sebagai berikut :

Program Studi Sistem Informasi | DST@2020 8

Gambar 4. Proses Pengembangan Sistem

E. Prinsip Pengembangan Sistem

Program Studi Sistem Informasi | DST@2020 9

F. Siklus Hidup Pengembangan Sistem

3. Manajemen sistem dan operasi (system management and operation)

Gambar 5. Tahapan Pengembangan Sistem

1. Kebijakan dan perencanaan sistem (system policy and planning).

Program Studi Sistem Informasi | DST@2020 10

Proses perencanaan sistem dikelompokkan menjadi 3 proses utama, yaitu :

Program Studi Sistem Informasi | DST@2020 11

Gambar 6. Tahapan Perencanaan Sistem

2. Pengembangan sistem (system development)

Program Studi Sistem Informasi | DST@2020 12

b. Menjaga kemutakhiran sistem Dengan berlalunya waktu, terjadi perubahan-

G. Pendekatan Pengembangan Sistem

Program Studi Sistem Informasi | DST@2020 13

kemungkinan kesalahan-kesalahan sistem akan menjadi lebih besar. Berbeda

2. Pendekatan sepotong lawan pendekatan sistem (dipandang dari sasaran yang

3. Pendekatan bawah-naik lawan pendekatan atas-turun (dipandang dari cara

Program Studi Sistem Informasi | DST@2020 14

informasi berdasarkan transaksi tersebut. Pendekatan ini juga merupakan ciri-ciri

4. Pendekatan sistem-menyeluruh lawan pendekatan moduler (dipandang dari cara

5. Pendekatan lompatan-jauh lawan pendekatan berkembang (dipandang dari