Metode Pengembangan
Metode Pengembangan
KATA PENGANTAR
Bismillaahirrahmaanirrahiim
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...
ii
Program Studi Sistem Informasi | DST@2020
ANALISA & PERANCANGAN SISTEM INFORMASI
DAFTAR ISI
iv
Program Studi Sistem Informasi | DST@2020
ANALISA & PERANCANGAN SISTEM INFORMASI
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.
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
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.
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:
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
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.
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 :
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;
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.
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.
Tahapan dari proses perencanaan sistem untuk ketiga bagian tersebut dapat dilihat pada
gambar berikut ini :
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
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)
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
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.
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
22
Program Studi Sistem Informasi | DST@2020
ANALISA & PERANCANGAN SISTEM INFORMASI
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.
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).
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.
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.
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
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
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
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.
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.
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
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.
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
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.
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
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.
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
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.
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.
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)
a. Bagaimana metode itu digunakan.
▪ 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.
c. Keuntungan metode.
▪ 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.
e. Kapan metode tersebut baik digunakan.
▪ Pertanyaannya sederhana, dan tidak memiliki arti mendua.
▪ Membutuhkan wawasan yang luas dari end-user.
▪ Bila memiliki sedikit waktu dan biaya.
3. Observasi (Observation)
a. Bagaimana metode itu digunakan.
▪ Secara pribadi seorang analis mengunjungi lokasi pengamatan.
▪ Analis merekam kejadian dalam lokasi pengamatan, termasuk volumen dan
pengolahan lembar kerja.
b. Target dari metode.
▪ Lokasi proses secara geografis ditunjukkan dalam DFD (Data Flow Diagram)
c. Keuntungan metode.
▪ 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.
e. Kapan metode tersebut baik digunakan.
▪ 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.
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.
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.
BAB IV
ENTITY RELATIONSHIP DIAGRAM (ERD), SPESIFIKASI FILE
DAN PENGKODEAN
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.
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
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:
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
49
Program Studi Sistem Informasi | DST@2020
ANALISA & PERANCANGAN SISTEM INFORMASI
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
50
Program Studi Sistem Informasi | DST@2020
ANALISA & PERANCANGAN SISTEM INFORMASI
51
Program Studi Sistem Informasi | DST@2020
ANALISA & PERANCANGAN SISTEM INFORMASI
Periksa apakah masih terdapat redundasi. ERD akhir: untuk pemodelan data pada sistem.
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: BLEACHMIND
1234567890
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
BAB V
UNIFIED MODELLING LANGUAGE (UML)
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.
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 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.
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.
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.
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.
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.
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.
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).
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
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.
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.
Pontianak 10,00 X
Singkawang 12,50 X
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
• 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.
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%
• Pastel
Bagan pastel (pie chart) merupakan bagan yang berbentuk lingkaran menyerupai
kue pastel (pie). Tiap tiap potong dari pie dapat menunjukkan bagian dari data.
BAB VII
PENGUJIAN PERANGKAT LUNAK DAN PEMELIHARAAN SISTEM
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.
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
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
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
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.
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 :
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.
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.
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.