Dewi Syifa Andini

11190930000018
4A APSI - TP 1 Resume Teori dan Contoh Penerapan (Bagian 2)

BAB V Analisa Sistem

5. Analisa Sistem
5.1. Pendahuluan
Analisis Sistem merupakan teknik pemecahan masalah yang menguraikan sistem
menjadi bagian-bagian komponennya untuk tujuan mempelajari seberapa baik bagian-
bagian komponen bekerja dan berinteraksi untuk mencapai tujuan mereka.
Analisis sistem juga memiliki pengertian teknik pemecahan masalah yang terurai
sistem ke dalam komponen buah untuk tujuan mempelajari seberapa baik bagian-bagian
komponen bekerja dan berinteraksi untuk mencapai tujuan mereka.
Orang yang melakukan perbaikan atau perancangan suatu sistem disebut dengan
sistem analis. Sistem analis dalah Analis sistem adalah spesialis yang mempelajari
masalah dan kebutuhan sebuah organisasi untuk menentukan bagaimana orang, data,
proses dan teknologi informasi dapat mencapai kemajuan terbaik untuk bisnis. Sistem
analis juga yang bertanggung jawab dalam proses analisa ataupun perancangan dalam
sebuah sistem informasi
Sistem analis harus mempunyai keahlian berkomunikasi dengan pihak-pihak lain
seperti pengguna komputer, manajemen, teknisi, bagian administrasi, programmer,
penyedia hardware dan software dan database administrator.

Tugas utama dari menganalisis sistem adalah sebagai berikut :

a) Menentukan ruang lingkup sistem

b) Mengumpulkan fakta
c) Menganalisis fakta
d) Mengkomunikasikan temuan-temuan tersebut melalui laporan analisis sistem
 (gambar konteks analisis sistem)

5.2. Konsep Analisis Sistem

Analis sistem merupakan teknik pemecahan masalah yang menguraikan sistem
menjadi bagian-bagian komponennya untuk tujuan mempelajari seberapa baik bagian-
bagian komponen bekerja dan berinteraksi untuk mencapai tujuan mereka[ CITATION
Jef07 \l 1057 ]. Defenisi ini menunjukkan sebuah pendekatan sistematis dan metodik
untuk melakukan analisis, dan mungkin perbaikan terhadap hal-hal yang sifatnya
spesifik yang diakibatkan oleh proses bisnis.

Berikut ini adalah langkah yang dilakukan dalam menganalisis sebuah sistem :

1. Identify (mengidentifikasi masalah)

Mengidentifikasi masalah merupakan langkah pertama yang dilakukan dalam
menganalisis sistem. Masalah yang diidentifikasi ini merupakan masalah yang
menyebabkan tujuan dari sistem tidak tercapai. Oleh karena itu identifikasi masalah
sangat penting dilakukan terlebih dahulu sebelum masalah yang lain terjadi.
Tugas yang harus dilakukan oleh analis sistem pada tahap ini adalah :
a) Mengidentifikasi penyebab masalah
b) Mengidentifikasi keputusan
c) Mengidentifikasi personil-personil kunci

2. Understand (Memahami Kerja Sistem)

Langkah ini merupakan langkah untuk memahami dan memperlajari dengan rinci
bagaimana sebuah sistem beroperasi. Hal ini dapat dilakukan dengan cara
mengumpulkan data dari penelitian. Apabila di tahap perencanaan sudah pernah
diadakan penelitian, maka sifatnya masih penelitian pendahuluan (preliminary
survey). Sedangkan pada tahap analisis sistem, penelitiannya bersifat penelitian
terinci (detailed survey).
 Analisis sistem ini penting dilakukan untuk mempelajari bagaiana sistem operasi
menganalisis permasalahan kelemahan dan kebutuhan pemakai sistem untuk dapat
memberikan rekomendasi pemecahannya. Data perlu dikumplkan dengan
menggunakan tenik pengupulan data seperti wawancara, oberservasi, daftar
pertanyaan dan pengambilan sampel
Tugas yang perlu dilakukan oleh analis sistem pada langkah ini adalah :
a. Menentukan jenis penelitian
b. Merencanakan jadual penelitian
c. Mengatur jadual wawancara
d. Mengatur jadual observasi
e. Mengatur jadual pengambilan sampel
f. Membuat penugasan penelitian
g. Membuat agenda wawancara
h. Mengumpulkan hasil penelitian
3. Analyze System (Menganalisis Sistem)
Langkah ini dilakukan berdasarkan pda data yang telah didapatkan dari hasil
penelitian
yang telah dilakukan, seperti :
a. Menganalisis kelemahan sistem
b. Menganalisis Kebutuhan Informasi Pemakai / Manajemen
4. Report (Membuat Laporan Hasil Analisis)
Pada langkah ini laporan dari hasil analisis diserahkan kepada Panitia Pengarah
(Steering Committee) yang nantinya akan diteruskan ke manajemen. Kemudian
panitia pengarah dengan manajemen mempelajari temuan dan analisis yang
dilakukan analis sistem.
Tujuan utama dari penyerahan laporan ini kepada manajemen adalah :
a. Analisis telah selesai dilakukan
b. Meluruskan kesalah-pengertian mengenai apa yang telah ditemukan dan
dianalisis oleh analis sistem tetapi tidak sesuai menurut manajemen
c. Meminta pendapat dan saran dari pihak manajemen
d. Meminta persetujuan kepada pihak manajemen untuk melakukan tindakan
selanjutnya (dapat berupa meneruskan ke tahap disain sistem atau menghentikan
proyek bila dipandang tidak layak lagi)

5.3 Scope Definition

Scope adalah batas-batas suatu proyek bidang-bidang bisnis yang dapat (atau
mungkin tidak) ditangani oleh suatu proyek[ CITATION Jef07 \l 1057 ]. Scope Definition
merupakan sebuah proses yang dilakukan untuk membuat deskripsi secara detail dari
proyek dan produk. Selama perencanaan berlangsung project scope mendefinisikan dan
mendeskripsikan proyek dengan spesifikasi yang detail melebihi informasi yang telah
digunakan dari proyek tersebut.
 Salah satu tugas paling penting dari fase scope definition adalah menetapkan garis
dasar awal dari masalah, peluang, dan / atau arahan yang memicu proyek. Berikut ini
adalah fase-fase yang terjadi pada scope definition :
1) Mengidentifikasi masalah dan peluang dasar
Yaitu penjelasan mengenai masalah awal, yang terdiri dari masalah, peluang,
dan arahan yang diidentifikasi yang nantinya pernyataan tersebut di simpan
dalam repositori untuk digunakan dalam proyek.
2) Menegosiasikan ruang lingkup baseline
Yaitu mendefinisikan batas proyek-aspek-aspek bisnis yang akan dan akan
dimasukkan dalam proyek.Lingkup dapat berubah selama proyek, namun,
rencana proyek awal harus menetapkan ruang lingkup awal atau dasar.
Seorang analis sistem senior atau manajer proyek biasanya memimpin tugas
ini.
3) Menilai kelayakan proyek baselin
Yaitu, tahap menilai segala aspek kelayakan untuk projek
4) Menyusun jadwal dan anggaran dasar
Jika proyek dianggap layak untuk dilanjutkan, maka yang berikutnya adalah
merencanakan proyek secara mendalam. Rencana proyek awal harus terdiri
dari setidaknya :
 Rencana induk awal yang mencakup jadwal dan penugasan sumber
daya untuk seluruh proyek. Rencana ini akan diperbaharui pada akhir
setiap fase proyek
 Rencana dan jadwal terperinci untuk menyelesaikan fase proyek
berikutnya
5) Mengomunikasikan rencana proyek
Membuka jalur komunikasi adalah hal yang penting untuk penyelidikan awal.
Untuk alasan ini, kami menganjurkan "praktik terbaik" melakukan acara
kickoff proyek dan membuat intranet project web site. Pertemuan awal
proyek terbuka untuk seluruh komunitas bisnis, bukan hanya unit bisnis yang
terpengaruh dan tim proyek. Situs web proyek intranct membentuk portal
komunitas untuk semua berita dan dokumentasi yang tidak sensitif yang
berkaitan dengan proyek.
 (Fase Scope Definition)

Input scope definition meliputi :

1. Scope Management Process

a. Scope Planning
Yaitu Merencanakan verifikasi waktu yang digunakan untuk memulai dan
menyelesaikan proses yang sedang berlangsung. Menjelaskan bagaimana
scope didefinisikan, diuji, dan diawasi serta melihat bagaimana sebuah
Work Breakdown Structute (WBS) tersebut
b. Scope Definition
Yaitu, Mendefinisikan tujuan dari proyek, bagaimana pemanfaatannya,
dan bagaimana benefit/ keuntungan yang didapat dari proyek tersebut.
Serta Menentukan pekerjaan yang dibutuhkan oleh proyek dan hasil utama
yang didapat adalah deliverable definition table dan deliverable structure
chart
c. Scope Verification
Memastikan proyek dapat dijakankan dengan akurat, tepat dan benar.
Scope verification ini melibatkan persetujuan secara formal project scope
yang telah diselesaikan oleh stakeholders.
2. Project Time Management
a. Activity Definition, yaitu mengidentifikasi aktivitas yang harus dilakukan
untuk mendelivered project scope
b. Activity Sequencing, yaitu Menentukan apakah aktivitas dapat
diselesaikan secara berurutan atau paralel.
c. Activity Resource Estimation, yaitu Identifikasi tipe sumber daya
(manusia, teknologi, fasilitas) dan kuantitas sumber daya yang dibutuhkan
untuk melaksanakan aktivitas proyek

Teknik estimasi pendekatan manajemen proyek tradisional, adalah sebagi

berikut :

a. Guesstimating Estimasi untuk mendapatkan jadwal proyek dan anggaran.

b. Delphi Technique Melakukan perhitungan, membandingkan sampai
estimasi mendekati.
c. Time Boxing Estimasi biaya dengan menyesuaikan waktu deadline.

3. Problem Statement
a. Penyampaian informasi antar anggota atau internal belum berjalan dengan
lancar.
b. Penyampaian informasi dengan pihak luar atau eksternal belum berjalan
dengan lancar
c. Pegelolaan sebuah dokumen atau arsip belum dapat berjalan dengan baik.

4. Initial Scope of Project

Agar dapat mengatasi masalahnya, maka harus memilih solusi agar dapat
mengatasi dan mengsignifikansinya, yaitu :
a. Penyampaian informasi antar anggota perusahaan yang belum berjalan
dengan lancar.
Solusinya : Pengembangan modul repository online dan manajemen news.
b. Penyampaian informasi antara perusahaan dengan pihak luar (eksternal)
belum berjalan dengan lancar.
Solusinya : Pengembangan modul pelayanan respond online, repository
online, dan manajemen news.
c. Pengelolaan dokumen atau arsip belum berjalan dengan baik.
Solusinya : Pengembangan modul repository online.
 Maka dapat dikembangkan sistem informasi dan document management system
yang akan mendukung fungsi-fungsi berikut :

a. Repository online. Memungkinkan perusahaan menyimpan dokumen,

menemukan dokumen yang telah tersimpan, serta upload dokumen arsip agar
dapat diakses.
b. Pelayanan Respond Online. Memungkinkan pihak eksternal mengkontak
bidang tertentu secara online, memungkinkan perusahaan untuk memberikan
respon secara online, dan memungkinkan pihak eksternal untuk membaca
respon secara online.
c. Manajemen News. Memungkinkan BEM UI untuk mempublikasikan berita
kepada pihak internal ataupun kepada pihak eksternal.

5.4 Problem Analysis

Problem analysis merupakan kemampuan yang digunakan untuk mengenalkan
elemen-elemen ke dalam situasi permasalahan dan memahami komponen apa saja
secara kritis. Kemampuan ini digunakan untuk mengenal aktivitas kritis yang dilakukan
agar dapat mengurutkan (breakdown) proses proses aktivitas tersebut dalam beberapa
komponen aktivitas. Oleh karena itu, menganalisis suatu situasi atau masalah yang ada
untuk menemukan cara yang terbaik dalam menangani masalah (problem solving).
Tujuan dari fase analisis masalah adalah untuk mempelajari dan memahami
domain masalah dengan cukup baik untuk menganalisis masalah, peluang, dan kendala
secara menyeluruh. Untuk menganalisis masalah ini dapat juga menggunakan kerangka
kerja PIECES.
Tahap analisis masalah biasanya mencakup tugas-tugas berikut :
a. Memahami domain masalah
b. Menganalisis masalah dan peluang
c. Menganalisa proses bisnis
d. Menetapkan tujuan perbaikan sistem
e. Memperbarui atau memperbaiki rencana proyek.
f. Mengkomunikasikan temuan dan rekomendasi.
 (Tugas untuk Analisis Masalah Fase Analisis Sistem)

5.5 Requirement Analysis

Tahap requirement analysis adalah tahap interaksi intensif diantara analis sistem
dengan komunitas pemakai sistem (end-user), dimana tim pengembangan sistem
menunjukkan keahliannya untuk mendapatkan tanggapan dan kepercayaan pemakai,
sehingga mendapat partisipasi yang bai[ CITATION Riz17 \l 1057 ].
Requiremrent analysis yaitu mendefinisikan harapan pengguna untuk aplikasi
yang akan dibangun atau dimodifikasi. Requirements Analysis melibatkan semua tugas
yang dilakukan untuk mengidentifikasi kebutuhan pemangku kepentingan yang
berbeda. Oleh karena itu Requirements Analysis berarti menganalisis,
mendokumentasikan, memvalidasi, dan mengelola persyaratan perangkat lunak atau
sistem. Persyaratan berkualitas tinggi didokumentasikan, dapat ditindaklanjuti, dapat
diukur, diuji, dapat dilacak, membantu mengidentifikasi peluang bisnis, dan
didefinisikan untuk memfasilitasi desain sistem.
Tahap analisis persyaratan biasanya mencakup tugas-tugas berikut :
a. Identifikasi dan ungkapkan persyaratan sistem
b. Memprioritaskan persyaratan sistem
c. Memperbarui atau memperbaiki rencana proyek
d. Komunikasikan pernyataan persyaratan
 (Tugas untuk Tahap Analisis Persyaratan)
Ada beberapa teknik yang digunakan untuk Analisis Kebutuhan. Dibawah ini adalah
daftar Teknis Analisis Persyaratan, yaitu :
a. Business process modeling notation (BPMN)
Teknik ini mirip dengan membuat diagram alur proses, meskipun BPMN
memiliki simbol dan elemen sendiri. Pemodelan dan notasi proses bisnis
digunakan untuk membuat grafik untuk proses bisnis. Grafik-grafik ini
menyederhanakan pemahaman proses bisnis. BPMN sangat populer sebagai
metodologi peningkatan proses.
b. UML (Unified Modeling Language)
UML terdiri dari serangkaian diagram terintegrasi yang dibuat untuk
menentukan, memvisualisasikan, membangun, dan mendokumentasikan artefak
sistem perangkat lunak. UML berguna saat membuat perangkat lunak
berorientasi objek dan bekerja dengan proses pengembangan perangkat lunak.
Dalam UML, notasi grafis digunakan untuk mewakili desain proyek perangkat
lunak. UML juga membantu memvalidasi desain arsitektur perangkat lunak.
c. Flowchart technique
Flowchart technique menggambarkan aliran berurutan dan logika kontrol dari
serangkaian aktivitas yang terkait. Diagram alir berada dalam format yang
berbeda seperti linear, lintas fungsional, dan top-down. Diagram alir dapat
mewakili interaksi sistem, aliran data, dll. Diagram alir mudah dipahami dan
dapat digunakan oleh anggota tim teknis dan non-teknis. Teknik flowchart
membantu dalam menunjukkan atribut kritis dari suatu proses.
 d. Data flow diagram
Teknik ini digunakan untuk secara visual mewakili sistem dan proses yang rumit
dan sulit untuk dijelaskan dalam teks. Diagram aliran data mewakili aliran
informasi melalui suatu proses atau sistem. Ini juga mencakup input dan output
data, penyimpanan data, dan berbagai subproses di mana data bergerak. DFD
menjelaskan berbagai entitas dan hubungannya dengan bantuan notasi dan
simbol terstandarisasi. Dengan memvisualisasikan semua elemen sistem, lebih
mudah untuk mengidentifikasi segala kekurangan. Kekurangan ini kemudian
dihilangkan dalam upaya menciptakan solusi yang kuat.
e. Role Activity Diagrams (RAD)
Role Activity Diagrams (RAD) adalah model proses berorientasi peran yang
mewakili diagram peran-aktivitas. Diagram aktivitas peran adalah pandangan
tingkat tinggi yang menangkap dinamika dan struktur peran organisasi. Peran
digunakan untuk mengelompokkan kegiatan bersama menjadi unit tanggung
jawab. Kegiatan adalah bagian dasar dari suatu peran. Suatu kegiatan dapat
dilakukan secara terpisah atau mungkin memerlukan koordinasi dengan kegiatan
lain dalam peran tersebut.
f. Gantt Charts
Gantt chart digunakan dalam perencanaan proyek karena mereka memberikan
representasi visual dari tugas-tugas yang dijadwalkan bersama dengan jadwal.
Grafik Gantt membantu untuk mengetahui apa yang dijadwalkan akan selesai
pada tanggal mana. Tanggal mulai dan berakhirnya semua tugas dalam proyek
dapat dilihat dalam satu tampilan.
g. IDEF (Integrated Definition for Function Modeling)
Definisi teknik terintegrasi untuk pemodelan fungsi (IDEFM) mewakili fungsi
dari suatu proses dan hubungannya dengan sistem anak dan orang tua dengan
bantuan kotak. Ini memberikan cetak biru untuk mendapatkan pemahaman
tentang sistem organisasi.
h. Gap Analysis
Gap Analysis adalah teknik yang membantu untuk menganalisis kesenjangan
dalam kinerja aplikasi perangkat lunak untuk menentukan apakah persyaratan
bisnis dipenuhi atau tidak. Ini juga melibatkan langkah-langkah yang harus
diambil untuk memastikan bahwa semua persyaratan bisnis terpenuhi dengan
sukses. Gap menunjukkan perbedaan antara kondisi sekarang dan status target.
Analisis kesenjangan juga dikenal sebagai analisis kebutuhan, penilaian
kebutuhan atau analisis kesenjangan kebutuhan

5.6 Logical Design

 Logical design merupakan perancangan yang dilakukan tanpa ketergantungan
dengan platform atau teknologi yang ada. Perancangan ini biasa dilakukan sebelum
menentukn teknologi apa yang akan digunakan dalam sebuah sistem. Setelah teknlogi
itu diterapkan maka selanjutnya dioalh oleh physical design[ CITATION Riz15 \l 1057 ].
Logical design juga merupakan bagian dari fase desain dalam SDLC dimana
semua fitur-fitur fungsional dari sistem dipilih dari tahapan analisis dideskripsikan
terpisah dari platform komputer yang nanti digunakan. Tujuan dari tahapan ini adalah
mentransformasikan kebutuhan bisnis dari fase requirements analysis kepada system
model yangakan dibangunnantinya. Dengan kata lain pada fase ini akan
menjawabpertanyaan-pertanyaan seputar penggunaan teknologi (data, process,interface)
yang menjamin usability,reliability, completeness, performance,dan quality yang akan
dibangun didalamsystem.

Fase desain logis biasanya mencakup tugas-tugas berikut :

a. Persyaratan fungsional struktur
b. Persyaratan fungsional prototipe
c. Validasi persyaratan fungsional
d. Tetapkan kasus uji penerimaan.

(Tugas untuk Fase Desain Logis Analisis Sistem)

5.7 Decision Analysis

 Decision Analysis merupakan kegiatan yang sangat penting bagi manusia, khususnya
bagi seorang manajer di sebuah perusahaan. Decision Analysis mempertimbangkan
beberapa kandidat dari perangkatlunak dan keras yang nantinya akan dipilih dan dipakai
dalam implementasikan sebuah sistem sebagai solusi atas problems dan requirements
yang sudahdidefinisikan padatahapan-tahapan sebelumnya.

Daftar Pustaka

Blog Seputar APSI (ANALISIS PERANCANGAN SISTEM INFORMASI). (2018, April 10).
Diambil kembali dari analisiperancangsisteminformasi.blogspot.com:
http://analisiperancangsisteminformasi.blogspot.com/

Amelia, R. N. (2017, September 27). Requirement Analysis (Analisis Kebutuhan). Diambil

kembali dari rizkanuramelia.blogspot.com:
http://rizkanuramelia.blogspot.com/2017/09/requirement-analysis-analisis-
kebutuhan.html

Binadarma. (2017). Analisis Perancangan Sistem Informasi. Diambil kembali dari

eprints.binadarma.ac.id: http://eprints.binadarma.ac.id/684/1/ANALISIS%20PERANC.
%20SISTEM%20INFORM%20materi%209.pdf

Dewi, R. K. (2015, Maret 30). Analisis Dan Perancangan Sistem Informasi. Diambil kembali
dari thykadewi22.blogspot.com: http://thykadewi22.blogspot.com/2015/03/analisis-dan-
perancangan-sistem.html

Priyanto, R. A. (2015, November 11). Logical Design Data Warehouse. Diambil kembali dari
rizqianangp.blogspot.com: http://rizqianangp.blogspot.com/2015/11/logical-design-data-
warehouse-rizqi.html

Vhyo17. (2010, Mei 3). Analisis dan Perancangan Sistem Informasi. Diambil kembali dari
vhyo17.blogspot.com: http://vhyo17.blogspot.com/2010/05/analisis-dan-perancangan-
sistem.html

Whitten, J. L., & Bentley, L. D. (2007). System Analysis & Design Methods. New York:
McGraw-Hill Irwin.
 BAB VI Fact Finding Untuk Menemukan Kebutuhan

6. Fact Finding Untuk Menemukan Kebutuhan

6.1. Pendahuluan
Dalam mengembangkan sebuah sistem, yang harus dilakukan pertama kali adalah
mengoreksi dan mengidentifikasi, menganalisis, dan memahami apa persyaratan
pengguna atau apa yang pengguna inginkan untuk dilakukan oleh sistem. Proses dan
teknik yang digunakan sistem analis untuk mengidentifikasi, menganalisis, dan
memahami persyaratan sistem disebut sebagai penemuan kebutuhan. Dalam hal ini
penemuan persyaratan itu melibatkan sistem analis yang bekerja dengan pengguna dan
pemilik sistem selama fase pengembangan sistem sebelumnya untuk mendapatkan
pemahaman terperinci mengenai persyaratan bisnis dari sistem informasi.
Untuk mempelajari sistem analis perlu dilakukan pengumpulan fakta-fakta dan
semua informasi yang relevan. Fakta jika dinyatakan dalam bentuk data kuantitatif
disebut sebagai data. Keberhasilan proyek apapun tergantung pada keakuratan data yang
tersedia. Informasi yang akurat dapat dikumpulkan dengan bantuan metode / teknik
tertentu. Metode-metode tertentu untuk mencari informasi dari sistem yang disebut
teknik menemukan fakta (Fact Finding Technique). Teknik menemukan fakta ini terdiri
dari Wawancara, Kuesioner, Rekam View dan Observasi. Fact-Finding merupakan
sebuah proses untuk mengenali dan mendefinisikan masalah yang dihadapi oleh
organisasi sebagai dasar acuan untuk menyusun langkah selanjutnya sebagai masukan
kebijakan bagi pihak manajemen. Hal lazim yang dilakukandalam tahap fact finding
adalah kegiatan research.
Requirements Discover (Penemuan Kebutuhan) adalah teknik yang digunakan
oleh sistem analis untuk mengidentifikasi atau mengekstrak masalah sistem dan
kebutuhan solusi dari pengguna masyarakat. Dalam hal ini harus sesuai dengan System
Requirements atau Kebutuhan Sistem, dimana dalam hal tersebut menentukan apa yang
harus dilakukan sistem informasi atau properti atau kualitas apa yang harus dimiliki
sistem. Kebutuhan sistem yang menentukan apa yang harus dilakukan sistem informasi
sering disebut sebagai kebutuhan fungsional. Kebutuhan sistem yang menentukan
properti atau kualitas yang harus dimiliki sistem sering disebut kebutuhan
nonfungsional.
Tujuan dari penemuan kebutuhan dan manajemen adalah untuk mengidentifikasi
dengan benar pengetahuan, proses, dan kebutuhan kerjasama untuk para pengguna
sistem baru. Kegagalan untuk mengidentifikasi kebutuhan sistem secara konektif dapat
mengakibatkan satu atau lebih dari yang berikut menurut buku (Jeffrey & Lonnie,
2007) :
 Sistem mungkin lebih mahal dari yang diproyeksikan
 Sistem dapat dikirimkan lebih lambat dari yang dijanjikan
 Sistem mungkin tidak memenuhi harapan pengguna, dan ketidakpuasan itu dapat
menyebabkan mereka tidak menggunakannya
  Sekali dalam produksi, biaya pemeliharaan dan peningkatan sistem mungkin
terlalu tinggi
 Sistem mungkin tidak dapat diandalkan dan rentan terhadap kesalahan dan
downtime
 Reputasi staf IT di tim ternoda karena setiap kegagalan, terlepas dari siapa yang
bersalah, akan dianggap sebagai kesalahan oleh tim

6.2. Proses Penemu Kebutuhan

Proses penemuan kebutuhan terdiri dari kegiatan berikut :
1) Penemuan dan analisis masalah
Persyaratan seorang sistem analis agar berhasil adalah harus memiliki keterampilan
dalam kegiatan analisis masalah. Salah satu kesalahan paling umum yang dibuat
analis sistem ketika mencoba menganalisis masalah adalah mengidentifikasi gejala
sebagai masalah. Akibatnya, mereka dapat merancang dan mengimplementasikan
solusi yang kemungkinan besar tidak menyelesaikan masalah nyata atau yang dapat
menyebabkan masalah baru.
Alat populer yang digunakan oleh tim pengembangan untuk mengidentifikasi,
menganalisis, dan menyelesaikan masalah adalah diagram Ishikawa, diagram ini
merupakan diagram yang berbentuk tulang ikan yang digunakan untuk
mengidentifikasi, mengeksplorasi dan menggambarkan suatu masalah, sebab dan
akibat dari masalah [ CITATION Sup17 \l 1057 ]

(Gambar Diagram Tulang Ikan Ishikawa)

2) Persyaratan Penemuan
Setelah dilakukan pemahaman masalah, maka analis sistem dapat mulai
mendefinisikan persyaratan. Agar analis sistem saat ini berhasil dalam
mendefinisikan persyaratan sistem, mereka harus terampil dalam metode yang
efektif untuk mengumpulkan informasi dan fakta. Pencarian fakta (Fact Finding)
adalah teknik yang digunakan di seluruh siklus pengembangan, tetapi sangat penting
dalam fase analisis persyaratan.
Setelah pencarian fakta telah selesai, alat-alat seperti kasus penggunaan, model data,
model proses, dan model objek akan digunakan untuk mendokumentasikan fakta,
dan kesimpulan akan diambil dari fakta.
Fact finding adalah proses formal yang menggunakan penelitian, pertemuan,
wawancara, kuesioner, pengambilan sampel, dan teknik lainnya untuk
mengumpulkan informasi tentang masalah, persyaratan, dan preferensi sistem. Ini
juga disebut pengumpulan informasi atau pengumpulan data.

3) Mendokumentasikan dan menganalisis masalah

Dengan menggunakan teknik Fact Finding, lalu sistem analis melakukan
pengumpulan atau mendokumentasikan informasi yang dikumpulkan dengan
terorganisir, dapat dimengerti, dan bermakna. Berikut ini adalah beberapa tahap yang
digunakan, yakni :
 Mendokumentasikan persyaratan/kebutuhan rancangan
Sistem analis mendokumentasikan temuan awal mereka dalam bentuk
draftdengan berbagai alat, mereka menulis use case untuk menggambarkan
fungsi sistem dari perspektif pengguna eksternal dan dengan cara dan
terminologi yang dipahami pengguna. Tabel keputusan digunakan untuk
mendokumentasikan kebijakan bisnis yang kompleks organisasi dan aturan
pengambilan keputusan, dan tabel persyaratan digunakan untuk
mendokumentasikan setiap persyaratan spesifik.
 Menganalisa Persyaratan/ Kebutuhan
kegiatan pencarian fakta menghasilkan kebutuhan yang bertentangan satu
sama lain. Ini karena kebutuhan diminta dari berbagai sumber dan setiap
orang memiliki pendapatnya sendiri dan keinginan untuk fungsi dan fitur
sistem baru. Tujuan dari kegiatan analisis persyaratan adalah untuk
menemukan dan menyelesaikan masalah dengan persyaratan dan mencapai
kesepakatan tentang modifikasi untuk memuaskan para pemangku
kepentingan. Fokus pada tahap ini adalah mencapai kesepakatan tentang
kebutuhan pemangku kepentingan.
 Formalisasi Kebutuhan
Kebutuhan sistem biasanya didokumentasikan dengan cara formal untuk
mengkomunikasikan persyaratan kepada pemangku kepentingan utama
 sistem. Dokumen ini berfungsi sebagai kontrak antara pemilik sistem dan tim
pengembangan tentang apa yang akan diberikan dalam hal sistem baru.
Dengan demikian, mungkin harus melalui banyak revisi dan ulasan sebelum
semua orang menyetujui dan mengesahkan isinya.

4) Manajemen Persyaratan Kebutuhan

Merupakan proses mengelola perubahan pada persyaratan. Selama masa proyek,
sangat umum untuk kebutuhan baru muncul dan kebutuhan yang ada untuk berubah
setelah dokumen definisi persyaratan telah disetujui. Untuk membantu meringankan
banyak masalah yang terkait dengan perubahan permintaan, perlu untuk melakukan
manajemen persyaratan. Manajemen persyaratan mencakup kebijakan, prosedur, dan
proses yang mengatur bagaimana perubahan terhadap persyaratan ditangani.

6.3. Teknik Fact Finding

Menurut [ CITATION Sya14 \l 1057 ] teknik fact-finding ada 6 cara yang dilakukan, yaitu :

(Gambar. Teknik-teknik
fact- finding)

 Background Reading
jika ada seorang yang baru ingin mempelajari sebuah sistem maka salah satu cara
yang disarankan adalah Background Reading dengan membaca laporan
perusahaan, strukur organisasi, manual kebijakan, rincian pekerjaan, dan
dokumentasi yang ada.
 Kuesioner
 merupakan teknik pengumpulan informasi yang memungkinkan penganalisis
sistem mempelajari sikap-sikap, keyakinan, karakteristik, dan perilaku beberapa
orang utamadalam organisasi yang bisa berpengaruh oleh sistem yang diajukan
atau oleh sistem yang sudah ada. Dengan menggunakan kuesioner, penganalisis
berupaya mengukur apa yang ditemukandalam wawancara. Selain itu, kuesioner
juga bisa digunakan digunakan untuk menentukanseberapa luas atau terbatasnya
sentimen yang diekspresikan dalam suatu wawancara.
 Prototyping
merupakan metode dalam pengembangan sistem yang menggunakan pendekatan
dengan cepat dan pertahap, sehingga segera dapat dievaluasi oleh pemakai.
Prototype juga merupakan teknik pengumpulan data yang sangat berguna dalam
melengkapi siklus hidup pembangunan sistem tradisional

(Gambar Langkah-
langkah Prototyping)

 Document Sampling
merupakan segala kegiatan yang melingkupi investigasi, wawancara, dan
observasi dalam metode pengumpulan data merupakan keputusan-keputusan
penting karena berkaitan dengan apa yang diamati dan siapa yang ditanya atau
diobservasi. Penganalisis sistem membuat berbagai keputusan ini berdasarkan
suatu pendekatan unsur yang terstruktur yang dinamakan document sampling.
 Interview
merupakan suatu percakapan yang dibuat secara langsung dengan tujuan tertentu
berdasarkan format tanya jawab. Dalam hal ini penganalis sistem harus
mendapatkan orang yang ingin diwawancarai, serta perasaannya tentang kondisis
sistem yang ada saat itu, tujuan-tujuan pribadi dan organisasional, serta prosedur-
prosedur informal
 Observation
 merupakan cara dalam fact-finding dengan memperhatikan bagaimana cara orang
melakukan pekerjaan mereka. Dalam observasi ini, seorang analis juga dapat
mengetahui informasi apa saja yang dibutuhkan oleh pengguna untuk melakukan
dan memudahkan pekerjaannya

6.4. Strategi Fact Finding

Seorang analis membutuhkan metode yang terorganisir untuk mengumpulkan fakta,
analis yang tidak berpengalaman akan sering langsung melakukan wawancara. Dalam
hal ini, hal tersebut bisa dianggap sebagai hal yang buang-buang waktu. Membuang-
buang waktu pengguna akhir adalah membuang-buang uang perusahaan mereka. Untuk
memanfaatkan sebagian besar waktu yang dihabiskan dengan pengguna akhir, analis
tidak boleh langsung melakukan wawancara. Analis pertama-tama harus mengumpulkan
semua fakta yang mereka dapat dengan menggunakan metode lain. Berikut strategi-
strategi dan langkah demi langkah dalam fact finding :
 Belajar dari dokumen, formulir, laporan, dan file yang ada. Analis dapat belajar
banyak tanpa ada kontak orang.
 Jika perlu, perhatikan sistem yang sedang beraksi.
 Mengingat semua fakta yang telah dikumpulkan, rancang dan distribusikan
kuesioner untuk menjernihkan hal-hal yang tidak sepenuhnya dipahami.
 Melakukan wawancara (atau sesi kerja kelompok). Karena sebagian besar fakta
terkait telah dikumpulkan dengan metode kontak rendah, wawancara dapat
digunakan untuk memverifikasi dan mengklarifikasi masalah dan masalah yang
paling sulit. (Atau, pertimbangkan untuk menggunakan teknik JRP untuk
menggantikan wawancara pelengkap).
 (Opsional). Bangun prototipe penemuan untuk persyaratan fungsional apa pun yang
tidak dipahami atau untuk persyaratan yang perlu divalidasi.
 Tindak lanjut Gunakan teknik pencarian fakta yang tepat untuk memverifikasi fakta
(biasanya wawancara atau observasi).

Dalam hal ini, strategi tersebut tidaklah mutlak, meskipun strategi pencarian fakta
harus dikembangkan untuk setiap fase pengembangan sistem yang terkait, setiap
proyek adalah unik. Terkadang observasi dan kuesioner mungkin tidak sesuai.
Tetapi idenya harus selalu mengumpulkan fakta sebanyak mungkin sebelum
menggunakan wawancara
 Daftar Pustaka

Dengen, N., & Hatta, H. R. (2009, Febuary). Perancangan Sistem Informasi Terpadu Pemerintah
Daerah Kabupaten Paser. Jurnal Informatika Mulawarman, IV, 47.

Supriyadi, D. (2017). Teknik Penemuan Fakta dan Penemuan Persyaratan Sistem. Diambil
kembali dari docplayer.info: https://docplayer.info/31847049-Teknik-penemuan-fakta-
dan-penemuan-persyaratan-sistem-didi-supriyadi-pertemuan-ke-6-sim-s1-informatika-
st3-telkom-purwokerto.html

Top, S. M. (2014). Metode Fact Finding Requirement. Diambil kembali dari

www.academia.edu:
https://www.academia.edu/7478543/Metode_Fact_Finding_Requirement

Whitten, J. L., & Bentley, L. D. (2007). System Analysis & Design Methods. New York:
McGraw-Hill Irwin.
 BAB VII Use Case Modelling

7. Fact Finding Untuk Menemukan Kebutuhan

7.1. Pendahuluan
Salah satu tantangan utama dalam desain sistem proses adalah kemampuan untuk
memperoleh yang benar dan perlu persyaratan sistem dari para pemangku kepentingan
dan tentukan mereka dengan cara yang dapat dimengerti oleh mereka sehingga mereka
persyaratan dapat diverifikasi dan divalidasi.
 Data dan model proses, prototipe, persyaratan spesifikasi.
 Dipahami oleh desainer tetapi tidak oleh pengguna.
 Mengarah pada cakupan desain, penjadwalan proses, pembengkakan biaya.

(gambar contoh development project track record)

Pengembangan yang berpusat pada pengguna (User Centered Development) merupakan

suatu proses sistem pengembangan berdasarkan pemahaman kebutuhan pemangku
kepentingan dan alasan mengapa sistem seharusnya dikembangkan.

Use case modelling merupakan proses pemodelan fungsi sistem dalam hal acara bisnis,
siapa mencetuskan event, dan bagaimana sistem merespon peristiwa tersebut.
 Pemodelan use-case berakar pada pemodelan berorientasi objek.
 Mendapatkan popularitas di lingkungan pengembangan non-objek karena
kegunaannya dalam berkomunikasi dengan pengguna.
  Alat pemodelan tradisional.

7.2. Pengantar Use Case Modelling

Pemodelan use-case berakar pada pemodelan berorientasi objek, dan lebih banyak
tentang bagaimana menerapkan pemodelan use case dalam analisis berorientasi objek
dan bab desain, tetapi telah mendapatkan popularitas di lingkungan pengembangan non-
objek. emodelan use-case melengkapi analisis sistem tradisional dan alat desain seperti
pemodelan data dan pemodelan proses serta memberikan dasar untuk keputusan
arsitektur dan keputusan desain antarmuka pengguna.
Pemodelan use-case awalnya diciptakan oleh Dr. Ivar Jacobson pada tahun 1986 dan
mendapatkan popularitas setelah ia menerbitkan bukunya, Obfect-Ortented Softuare
Engineer, pada tahun 1992 Dr. Jacobson menggunakan pemodelan use-case sebagai
kerangka kerja untuk metodologi objektifnya, yang ia berhasil digunakan untuk
mengembangkan sistem informasi berorientasi objek.

Pemodelan Usecase telah terbukti menjadi bantuan yang berharga dalam memenuhi
tantangan menentukan apa yang harus dilakukan sistem dari perspektif pengguna dan
pemangku kepentingan. Sekarang dikenal secara luas sebagai praktik terbaik untuk
mendokumentasikan dan memahami persyaratan fungsional sistem informasi.
Menggunakan pemodelan use case memfasilitasi dan mendorong keterlibatan pengguna,
yang merupakan salah satu faktor penentu keberhasilan utama untuk memastikan
keberhasilan proyek.

Berikut ini adalah manfaat pemodelan Use Case :

1) Menyediakan alat untuk menangkap persyaratan fungsional
2) Membantu dalam menguraikan ruang lingkup sistem menjadi bagian-bagian yang
lebih mudah dikelola
3) Menyediakan sarana untuk berkomunikasi dengan pengguna dan pemangku
kepentingan lainnya mengenai fungsionalitas sistem. Use case yang ada mudah
dipahami oleh berbagai pemangku kepentingan
4) Menyediakan sarana untuk mengidentifikasi, menyelaraskan, melacak,
mengendalikan, dan mengelola kegiatan pengembangan sistem, khususnya
pengembangan bertahap dan berulang
5) Memberikan bantuan dalam memperkirakan ruang lingkup proyek, upaya, dan
jadwal
6) Memberikan dasar untuk pengujian dalam hal menentukan rencana pengujian dan
kasus uji
7) Menyediakan garis dasar untuk sistem bantuan pengguna dan manual serta bahasa
umum sistem yang merupakan dokumentasi pengembangan
8) Menyediakan alat untuk keterlacakan persyaratan
 9) Menyediakan titik awal untuk identifikasi objek atau entitas data
10) Menyediakan spesifikasi fungsional untuk merancang antarmuka pengguna dan
sistem
11) Menyediakan cara mendefinisikan persyaratan akses basis data dalam hal
penambahan, perubahan, penghapusan, dan pembacaan
12) Menyediakan kerangka kerja untuk mengarahkan proyek pengembangan sistem.

7.3. Konsep Sistem Use Case Modeling

Terdapat dua artefak utama yang terlibat saat melakukan pemodelan use-case, yaitu :
1) Diagram Use Case
Yang pertama adalah diagram use-case, yang secara grafis menggambarkan sistem
sebagai kumpulan use case, aktor (pengguna), dan hubungan mereka. Diagram ini
berkomunikasi pada tingkat tinggi ruang lingkup acara bisnis yang harus diproses
oleh sistem.

(Gambar Diagram Use Case)

Gambar tersebut menunjukkan setiap fungsi sistem, atau acara bisnis (di elips), dan
aktor, atau pengguna sistem yang berinteraksi dengan fungsi-fungsi itu. Seperti yang
terlihat pada Gambar contoh use case diatas, aktor dapat ditempatkan di kedua sisi
himpunan angka usecase dan dapat berinteraksi dengan satu atau lebih kasus
penggunaan. Diagram use-case sangat sederhana. Tetapi ia memulai proses penting
yang disebut dekomposisi fungsional, yaitu tindakan memecah sistem menjadi
beberapa subkomponennya. Dimungkinkan untuk memahami keseluruhan sistem
sekaligus, tetapi dimungkinkan untuk memahami dan menentukan setiap bagian dari
sistem.

 Use Case
 Use cases menggambarkan fungsi sistem dari perspektif pengguna eksternal
dan dalam anner dan terminologi yang mereka pahami. Untuk mencapai hal
ini secara akurat dan tuntas, diperlukan tingkat keterlibatan pengguna yang
tinggi dan pakar subjek yang memiliki pengetahuan tentang proses atau
peristiwa bisnis. Casing penggunaan diwakili secara grafis oleh elips
horisontal dengan nama use case muncul di atas, di bawah, atau di dalam
elips. Sebuah use case mewakili satu tujuan sistem dan menggambarkan
serangkaian kegiatan dan interaksi pengguna dalam mencoba mencapai
tujuan.
 Actor
Use case di prakarsai atau dipicu oleh pengguna eksternal yang disebut aktor.
Seorang aktor memulai aktivitas sistem, dan kasus penggunaan untuk tujuan
menyelesaikan beberapa tugas bisnis yang menghasilkan sesuatu yang
bernilai terukur.
Contoh seorang mahasiswa yang mendaftar untuk kursus semester musim
gugur. Aktornya adalah siswa, dan use case nya adalah akan Mendaftar di
Kursus.
Faktanya, seorang aktor tidak harus manusia. Ini dapat berupa organisasi,
sistem informasi lain, perangkat eksternal seperti sensor panas, atau bahkan
konsep waktu (yang akan dibahas sedikit kemudian). Aktor diwakili secara
grafis sebagai figur tongkat yang dilabeli dengan nama peran yang dimainkan
aktor[ CITATION Jef07 \l 1057 ].
Terdapat 4 jenis aktor, yaitu :
1. Pelaku bisnis utama, yaitu pemangku kepentingan yang terutama
mendapat manfaat dari pelaksanaan use case dengan menerima sesuatu
yang nilainya terukur atau teramati.
2. Pelaku sistem primer, yaitu pemangku kepentingan yang secara langsung
berinteraksi dengan sistem untuk memulai atau memicu bisnis acara
sistem. Pelaku sistem primer dapat berinteraksi dengan pelaku bisnis
utama untuk tujuan menggunakan sistem yang sebenarnya. Mereka
memfasilitasi acara melalui penggunaan langsung sistem untuk
kepentingan pelaku bisnis utama
3. Aktor server eksternal, yaitu pemangku kepentingan yang menanggapi
permintaan dari kasus penggunaan (misalnya, biro kredit yang
mengesahkan pengisian dengan kartu kredit)
4. Aktor penerima eksternal, yaitu pemangku kepentingan yang bukan aktor
utama tetapi menerima sesuatu yang bernilai terukur atau dapat diamati.
(output) dari use case (misalnya, gudang yang menerima pesanan
pengepakan untuk mempersiapkan pengiriman setelah pelanggan
melakukan pemesanan)
  Relationships
Suatu hubungan digambarkan sebagai garis antara dua simbol pada diagram
use-case. Arti hubungan mungkin berbeda tergantung pada bagaimana garis
digambar dan jenis simbol apa yang dihubungkan. Di bagian berikut ini kami
akan mendefinisikan hubungan berbeda yang ditemukan pada diagram use-
case.

2) Use Case Narrative

Disebut Usecase Narrative, karena mengisi rincian setiap peristiwa bisnis dan
menentukan bagaimana pengguna berinteraksi dengan sistem selama peristiwa itu.

7.4. Kebutuhan Proses Uses Case Modelling

Tujuannya adalah untuk memperoleh dan menganalisis persyaratan yang cukup
informasi untuk menyiapkan model dengan baik seperti :
 Mengkomunikasikan apa yang dibutuhkan dari perspektif pengguna.
 Bebas dari rincian spesifik tentang bagaimana sistem akan dibangun atau
diimplementasikan.
Untuk memperkirakan dan menjadwalkan proyek secara efektif, mungkin perlu
termasuk “asumsi implementasi sistem” pendahuluan (Jacobson, Booch, & Rumbaugh,
1996).
Langkah-langkah nya adalah :
1. Identifikasi pelaku bisnis
Siapa atau apa yang menyediakan sistem, siapa yang menjalankan proses.
2. Identifikasi kasus penggunaan bisnis.
Selama analisis persyaratan, berusaha untuk mengidentifikasi dan hanya
mendokumentasikan yang paling kritis, kompleks, dan kasus penggunaan penting,
sering disebut kasus penggunaan penting.
3. Buat diagram use-case model.
Membuat diagram use case sesuai dengan proses yang ada dalam perusahaan
tersebut dan membuat dengan efektif dengan apa yang diminta
4. Dokumen persyaratan bisnis narasi kasus penggunaan.
Dokumentasikan terlebih dahulu pada level tinggi untuk mendapatkan pemahaman
tentang peristiwa dan besarnya sistem.

Daftar Pustaka

Jacobson, Boach, I., Rumbaugh, G., & James. (1996). The Unified Modeling Language.
University Video Communications.
Kurniawan, & A, T. (2018). Pemodelan Use Case (UML): Evaluasi Terhadap beberapa
Kesalahan dalam Praktik. Jurnal Teknologi Informasi dan Ilmu Komputer (JTIIK), 5, 77-
86.

Rambough, Boach, O., Jacobson, O., & OOSE. (1991). Object Modeling Technique.

Whitten, J. L., & Bentley, L. D. (2007). System Analysis & Design Methods. New York:
McGraw-Hill Irwin.

BAB VIII Analisa dan Modeling Data

8.1. Pendahuluan
Data merupakan komponen utama dari sistem informasi perusahaan karena semua
informasi untuk pengambilan keputusan berasal dari data. Oleh karena itu sudah
sewajarnya jika pengolahan data dipandang sebagai kebutuhan primer oleh perusahaan.
Pengelolaan data yang buruk dapat mengakibatkan tidak tersedianya data penting yang
digunakan untuk menghasilkan informasi yang diperlukan dalam pengambilan
keputusan. Untuk mengolah data menjadi bentuk yang lebih bermanfaat dibutuhkan
analisis yang baik dan tajam. Analisis data merupakan metode yang digunakan untuk
mengetahui bagaimana menggambarkan data, hubungan data, semantik data dan batasan
data yang ada pada suatu sistem informasi. Ada banyak cara dalam menganalisis dan
memodelkan suatu data, salah satunya adalah dengan menggunakan Entity Relationship
Diagram (ERD).

8.2. Apa Itu Data Modelling

Ada beberapa pendapat mengenai definisi data, sebuah sumber menyebutkan
bahwa data adalah fakta-fakta, pemikiran, atau pendapat yang tidak atau belum memiliki
arti kegunaan”. Sedangkan pengertian lain dari data yaitu didefinisikan sebagai
kelompok teratur simbol-simbol yang mewakili kuantitas, tindakan, benda, dan
sebagainya”. Data terbentuk dari karakter yang dapat berupa alfabet, angka, maupun
simbol khusus dan merupakan bentuk yang masih mentah sehingga perlu diolah lebih
lanjut melalui suatu model untuk menghasilkan informasi
Pemodelan data adalah proses yang digunakan untuk mendefinisikan dan
menganalisis kebutuhan data yang diperlukan untuk mendukung proses bisnis dalam
lingkup sistem informasi yang sesuai dalam organisasi. Oleh karena itu, proses
pemodelan data melibatkan pemodel data profesional bekerja sama dengan pemangku
kepentingan bisnis, serta pengguna potensial dari sistem informasi.
Macam-macam model data
1) OBDM (Object Based Data Model) = Model Data berbasis Obyek
 2) RBDM (Record Based Data Model) = Model data berbasis Record
3) PBDM ( Physical Based Data Model) = Model data berbasis Fisik

8.3. Konsep Sistem Data Modelling

Ada beberapa catatan mengenai pemodelan data. Model yang aktual disebut
dengan entity relationship diagram ERD. Karena model ini menjelaskan data dalam
konteks entitas dan hubungan yang digambarkan oleh data tersebut.
1) Entitas
Entiti atau entitas adalah sesuatu yang diperlukan bisnis untuk menyimpan data.
Entitas digambarkan dengan bentuk persegi.
2) Atribut
Jika entitas digunakan untuk menyimpan data maka kita mengidentifikasi bagian
data spesifik yang ingin kita simpan dari setiap entitas tertentu.kita dapat
menyebut data ini sebagai atribut.
3) Domain
Saat menganalisis sebuah sistem kita mendefenisikan nilai-nilai atribut yang sah
atau yang memiliki sistem bisnis. Nilai untuk atribut didefinisiikan dalam tiga
property yaitu tipe data, domain dan default.
4) Hubungan
Secara konseptual entitas dan atribut tidak terpisah. Hal yang dinyatakan saling
berintekrasi da mempengaruhi untuk saling mendukung tujuan bisnis.
Relationship atau hubungan adalah hubungan bisnis alami yang ada antara satu
atau lebih entitas.

Atribut dan atribut gabungan terdiri dari :

1) Compound attribute
Atribut yang terdiri dari atribut lain. Sinonimnya dalam berbagai bahasa
pemodelan data sangat banyak.
2) Data tipe
Properti sebuah atriut yang mendefenisikan tipe data apa yang dapat disimpan
pada atribut.
3) Domain
Saat menganalisis sebuah sistem kita mendefenisikan nilai-nilai atribut yang sah
atau yang memiliki sistem bisnis. Nilai untuk atribut didefinisikan dalam tiga
property yaitu tipe data, domain dan default.
4) Default falue
Nilai yang akan digunakan jika nilai tersebut tidak ditetapkan oleh pengguna.
5) Key
Atribut atau kelompok atribut yang mengasumsikan nilai unik untuk setiap
contoh entitas atau disebut dengan identifier.
6) Concatenated key
Atribut atau kelompok atribut yang mendefenisikan nilai unik untuk setiap
contoh entitas.

Macam-macam key :
1) Candidate key
Satu dari sekian banyak key yang berlaku sebagai primery key suatu
entitas. Sering disebut dengan candidate identifier.%.
2) Primary key
Candidate key yang paling umum digunakan untuk mengidentifikasi
contoh entitas tunggal.
3) Alternate key
Candidate key yang terpilih menjadi pimery key. Sinonimnya adalah
secondary key.
4) Subseting kriteria
Atribut yang nilai terbatasnya membagi contoh entitas. Sering disebut
inversion entry.
Cardinalitity
Kardinalitas mendefenisikan jumlah kemunculan baik minimum maupun
maksimum satu entitas yang dapat dihubungkan dengan kemunculan tunggal
entitas lainnya.
Degree
Degree hubungan adalah jumblah entitas yang berperan dalam hubungan.
Hubungan juga terdapat dalam contoh yang berbeda dan dalam entitas yang sama
(recursive relationship atau hubungan rekursif). Dan juga terdapat associtive
entity yang artinya sebuah entitas yang mendapatkan primery key dari lebih dari
satu entitas lain (prent).
Foreign key
Hubungan mengimpikasikan bahwa satu entitas dihubungkan dengan
entitas lain. Foreign key adalah pimery key pada entitas yang berikan ke entitas
lain untuk mengidentifikasi contoh hubungan.
Identifing relationship
Hubungan teridentifikasi adalah hubungan dimana entitas induk
menyerahkan primery key nya menjadi bagian entitas primery key anak. Entitas
anak untuk setiap hubungan teridentifikasi sering disebut weak entity karena
identifikasinya tergantung pada keberadaan entitas induk. Untuk entitas asosiatif,
kardinalitas dari anak keinduk dan selalu satu dan hanya satu.
Generalisasi
Generalisasi adalah pendekatan untuk menemukan dan mengekploitasi
kesamaan antara entitas. Generalisasi adalah teknik dimana atribut yang umum
 bagi beberap tipe entitas, misalnya sekolah yang umum. Super tipe entitas adalah
entitas yang contohnya menyimpan atribut yang umum bagi satu atau lebih
subtipe entitas dankemudian menambahkan atribut-atribut lain yang unik
kesebuah contoh subtipe tersebut. Analisis persyaratan menghasilkan model data
logika yang dikembangkan kedalam tahapan membuat data konteks untuk
menentukan lingkup proyek. Selanjutnya model data key based akan digambarkan
dan dibuat data model fully atributed. Kemampuan adaptasi dan fleksibilitas
model data lengkap dianalisis melalui proses yang disebut normalisasi

8.4. Bagaimana Konstruksi Data Modelling

Melalui proses Pemodelan Data Logis kemudian pemodelan data dtrategis dimana
banyak organisasi memilih proyek pengembangan IS berdasarkan rencana strategis.
Termasuk visi dan arsitektur untuk sistem informasi
Kemudian mengidentifikasi dan memprioritaskan pengembangan proyek.
Termasuk model data perusahaan sebagai titik awal untuk proyek dan pemodelan data
selama analisis sistem.
Model data untuk sistem informasi tunggal disebut model data aplikasi. Dan
model data konteks hanya mencakup entitas dan hubungan.
Tahapan Pengembangan Model Logis
 Model data konteks
Untuk menetapkan ruang lingkup proyek
 Model data dasar-kunci
Hilangkan hubungan tidak spesifik
Tambahkan entitas asosiatif
Sertakan kunci utama dan alternative
Kardinalitas yang tepat
 Model data yang sepenuhnya dikaitkan
Semua atribut yang tersisa
Kriteria berlangganan
Model data yang dinormalisasi

8.5. Analisa Data Modelling serta Penjelasan ERD dan Normalisasi

8.5.1. Analisa Data Modelling
Terdapat 5 macam model teknik analisis data yaitu:
1) Model Analisis Interaktif Miles & Huberman.
2) Analisis Isi (Content Anlysis).
3) Teknik Analisis Domain (Domain Analysis).
4) Teknik Analisis Taksonomik (Taksonomic Analysis).
5) Teknik Analisis Komparatif Konstan (Constant Comparative Analysis).
Model Analisis Interaktif Miles & Huberman
Model analisis interaktif menurut Miles dan Huberman yaitu dalam penelitian
kualitatif memungkinkan dilakukan analisis data ketika peneliti berada di lapangan
ataupun sesudah kembali dari lapangan baru di adakan analisis. Dalam penelitian ini
analisis data telah dilakukan bersamaan dengan proses pengumpulan data. Sebagaimana
yang diungkapkan oleh Miles dan Huberman, alur analisis mengikuti model analisis
interaktif. Dalam penelitian proses analisis ini dilakukan melalui 4 tahap, berikut ini:
- Pengumpulan Data
Data yang didapat dari hasil wawancara, observasi dan dokumentasi dicatat
pada catatan lapangan yang terdiri atas 2 bagian yaitu bagian deskriptif dan bagian
reflektif. Pengertian catatan deskriptif yaitu catatan alami, (merupakan catatan
mengenai apa yang disaksikan, didengar, dilihat dan dialammmi sendiri oleh peneliti
tanpa adanya penafsiran dan pendapat dari peneliti terhadap fenomena yang
dialaminya). Catatan reflektif adalah catatan yang isinya kesan, pendapat, komentar
serta tafsiran peneliti mengenai apa penemuan yang dijumpai. Selain itu merupakan
bahan rencana pengumpulan data untuk tahap selanjutnya.
- Reduksi Data
Selanjutnya sesudah data terkumpul dibuat reduksi data, untuk menentukan
data yang relevan dan mempunyai maka, memfokuskan data yang mengarah pada
pemecahan masalah, penemuan, pemaknaan atau untuk menjawab pertanyaan
penelitian. Selanjutnya melakukan penyederhanaan serta menyususn secara sistematis
dan menjabarkan hal-hal penting mengenai hasil penemuan dan maknanya. Dalam
proses reduksi data, hanya temuan data atau temuan yang berkaitan dengan
permasalahan penelitian yang direduksi. Sedangkan untuk data yang tidak ada
kaitannya dengan masalah penelitian dibuang. Atau dengan kata lain reduksi data
dipakai untuk analisis yang mengarahkan, menggolongkan, menajamkan dan
membuang yang tidak penting danmengorganisasikan data. Dengan begitu maka akan
mempermudahkan peneliti untuk menarik sebuah kesimpulan.
- Penyajian Data
Penyajian data bisa berbentuk tulisan, gambar, tabel dan grafik. Tujuan
penyajian data untuk menggabungkan informasi sehingga bisa memberikan gambaran
terhadap keadaan yang terjadi. Dalam hal ini, supaya peneliti tidak mengalami
kesulitan dalam penguasaan informasi secara baik dan menyeluruh dan juga bagian-
bagian tertentu dari hasil peneltian. Maka dari itulah peneliti harus membuat naratif,
grafik atau matrik untuk mempermudah penguasaan data atau informasi tersebut.
Dengan cara seperti itu maka peneliti bisa tetap menguasai data dan tidak tenggelam
dalam kesimpulan informasi yang bisa membosankan. Hal seperti ini dilakukan
karena data yang tersususun kurang baik dapat mempengaruhi peneliti dalam
mengambil kesimpulan yang memihak dan dalam bertindak secara ceroboh, dan tidak
mendasar. Mengenai display data harus dissadari sebagai bagian di dalam analisis
data.
 - Penarikan Kesimpulan
Penarikan kesimpulan dilakukan selama berlangsungnya penelitian, seperti
halnya proses reduksi data, sesudah data telah terkummpul memadai maka akan dapat
diperoleh kesimpulan sementara, dan sesudah data benar-benar lengkap maka dapat
diperoleh kesimpulan akhir.

Mulai dari awal penelitian, peneliti selalu ingin berusaha menemukan makna
data yang terkumpul. Oleh sebab itu perlu untuk menemukan tema, pola, persamaan,
hubungan, hipotesis, hal-hal yang sering muncul dan lain-lain. Awalnya kesimpulan
yang diperoleh bersifat kabur, tentatif dan diragukan namun dengan bertambahnya
data baik itu dari hasil observasi maupun wawancara dan dari diperolehnya
keseluruhan data hasil penelitian. Maka kesimpulan-kesimpulan tersebut harus
diklarifikasikan dan diverifikasikan selama berlangsungya penelitian.
Selanjutnya data-data yang ada disatukan ke dalam unit-unit informasi yang
menjadi rumusan kategori-kategori dengan berpegang pada prinsip holistik dan bisa
ditafsirkan tanpa adanya informasi tambahan. Data tentang informasi yang dirasa
sama disatukan dalam satu kategori, sehingga memberikan kemungkinan munculnya
kategori baru dari kategori yang telah ada.

8.5.2. Entity Relation Diagram (ERD)

Entity Relationship Diagram (ERD) merupakan model jaringan data
yang menekankan pada struktur-struktur dan relationship data. Diagram
hubungan entitas atau yang lebih dikenal dengan E-R diagram, adalah notasi
grafik dari sebuah model data atau sebuah model jaringan yang menjelaskan
tentang data yang tersimpan (storage data) dalam sistem secara abstrak.
Beberapa elemen yang ada di dalam ERD adalah sebagai berikut:
1) Entity adalah sesuatu apa saja yang ada di dalam sistem, nyata maupun
abstrak dimana data tersimpan atau dimana terdapat data. Entitas diberi
nama dengan kata benda dan dapat dikelompokkan dalam empat jenis nama,
yaitu orang, benda, lokasi, kejadian (terdapat unsur waktu di dalamnya).
2) Relationship adalah hubungan alamiah yang terjadi antara entitas. Pada
umumnya penghubung (Relationship) diberi nama dengan kata kerja
dasar, sehingga memudahkan untuk melakukan pembacaaan relasinya
(bisa dengan kalimat aktif atau pasif).
3) Atribut Secara umum atribut adalah sifat atau karakteristik dari tiap
entitas maupun tiap relationship. Maksudnya, atribut adalah sesuatu yang
menjelaskan apa sebenarnya yang dimaksud entitas maupun relationship,
sehingga sering dikatakan atribut adalah elemen dari setiap entitas dan
relationship.
 4) Kardinalitas (Cardinality) menunjukan jumlah maksimum tupel yang dapat
berelasi dengan entitas pada entitas yang lain. Terdapat tiga macam
kardinalitas relasi, yaitu:
 One to One Tingkat hubungan satu ke satu, dinyatakandengan satu
kejadian pada entitas pertama, hanya memepunyai satu hubungan
dengan satu kejadian pada entitas yang kedua dan sebaliknya.
 One to Many atau Many to One Tingkat hubungan satu ke banyak adalah
sama dengan banyak ke satu. Tergantung arah mana hubungan
tersebut dilihat. Untuk satu kejadian pada entitas yang pertama dapat
mempunyai banyak hubungan kejadian pada entitas yang kedua
maupun sebaliknya.
 Many to Many Tingkat hubungan banyak ke banyak terjadi jika tiap
kejadian pada sebuah entitas akan mempunyai banyak hubungan dengan
kejadian pada entitas lainnya. Baik dilihat dari sisi entitas.

8.5.3. Normalisasi
Pengertian normalisasi adalah suatu teknik analisa data yang
mengorganisir data ke dalam suatu kelompok untuk membentuk kesatuan data
yang nonredundant, stabil, fleksibel, dan adaptif beberapa bentuk normalisasi
diantaranya adalah bentuk tidak normal (unnormalize), bentuk normal pertama
(1NF), bentuk normal kedua (2NF), normal ketiga (3NF), dan seterusnya.
Suatu file yang terdiri dari beberapa group elemen yang berulang-ulang
perlu diorganisasikan kembali. Proses untuk mengorganisasikan file dengan
menghilangkan group elemen yang berulang atau sebuah langkah atau proses
untuk menyederhanakan sebuah relationship antar elemen data didalam tuple
(record) ini disebut dengan normalisasi. Normalisasi juga banyak dilakukan dalam
merubah bentuk database dari suatu struktur pohon atau struktur jaringan menjadi
struktur hubungan.
1) Bentuk Tidak Normal (unnormalize)
Bentuk tidak normal (unnormalized) merupakan kumpulan data yang
direkam tidak ada keharusan dengan mengikuti suatu format tertentu.
Pada bentuk tidak normal terdapat repeating group (Pengulangan Group),
sehingga pada kondisi ini data menjadi permasalahan dalam melakukan
manipulasi data (insert, update, dan delete) atau biasa disebut anomali.
Contoh:
2) Normal Pertama (1 NF)
Dalam relational database tidak diperkenankan adanya repeating group
karena dapat berdampak terjadinya anomali. Oleh karena itu tahap unnormal
akan menghasilkan bentuk normal tahap pertama (1 NF) yang dapat di
definisikan sebagai suatu relasi atau tabel memenuhi normal pertama jika dan
hanya jika setiap setiap atribut dari relasi tersebut hanya memiliki nilai tunggal
dalam satu baris (record).
Tiap field hanya satu pengertian, bukan merupakan kumpulan kata yang
mempunyai arti ganda dan tidak ada set atribut yang berulang-ulang atau
atribut bernilai ganda.
Pada data tabel sebelumnya data belum normal sehingga harus diubah
kedalam bentuk normal pertama dengan cara membuat baris berisi kolom
jumlah yang sama dan setiap kolom hanya mengandung satu nilai.
Berikut perubahannya:

Bentuk normalisasi pertama (1 NF) ini mempunyai ciri yaitu setiap data
dibentuk file datar atau rata (flat file), data dibentuk dalam satu record demi satu
record dan nilai-nilai dari field-field berupa nilai yang tidak dapat dibagi-bagi
lagi.

3) Normal Kedua (2 NF)

Dalam perancangan database relational tidak diperkenankan adalah
partial kepada primary key, karena dapat berdampak terjadinya anomali. Oleh
karena itu tahap normalisasi pertama akan menghasilkan bentuk normal kedua
(2 NF) yang dapat didefinisikan sebagai suatu relasi memenuhi relasi kedua
jika dan hanya jika relasi tersebut memenuhi normal pertama dan setiap atribut
yang bukan kunci (non key) bergantung secara fungsional terhadap kunci
utama (Primary key).
Berikut perubahannya:
 Bentuk normal kedua ini mempunyai syarat yaitu bentuk data yang telah
memenuhi kriteria bentuk normal pertama. Atribut bukan kunci haruslah
bergantung secara fungsional pada kunci utama (primary key), sehingga untuk
membentuk normal kedua haruslah sudah ditentukan kunci-kunci field.

4) Normal Ketiga (3 NF)

Dalam perancangan database relational tidak diperkenankan adanya
transitive dependency karena dapat berdampak terjadinya anomali. Oleh karena
itu harus dilakukan normalisasi tahap ketiga (3 NF) yang didefinisikan sebagai
suatu relasi memenuhi normal ketiga jika dan hanya jika relasi tersebut
memenuhi normal kedua dan setiap atribut bukan kunci (non key) tidak
mempunyai transitive functional dependency kepada kunci utama (primary
key).
Berikut perubahannya:

Bentuk normal ketiga (3 NF) ini relasi haruslah dalam bentuk normal kedua dan
semua atribut bukan kunci utama tidak punya hubungan transitif. Artinya setiap atribut
 bukan kunci harus bergantung hanya pada primary key secara keseluruhan, dan bentuk
normalisasi ketiga sudah didapat tabel yang optimal.

Daftar Pustaka

Edi, D., & Betshani, S. (2009). Analisis Data dengan Menggunakan ERD dan Model Konseptual
Data Warehouse. Jurnal Informatika, 5(1), 71-85.
Hasugian, H., & Shidiq, A. N. (2012). Rancang Bangun Sistem Informasi Industri Kreatif
Bidang Penyewaan Sarana Olahraga. Semantik, 2(1).
Muarie, M. S. (2015). Rancang Bangun Sistem Ujian Online pada SMP Negeri 8 Sekayu. Jurnal
TIPS: Jurnal Teknologi Informasi dan Komputer Politeknik Sekayu, 2(1), 28-40.
Endayan, P. (n.d). Pemodelan dan Analisis Data.
Nadhira, M. (2017). Pemodelan Data.
Metopenkomp. (2017). Model-model Analisis Data.
Setiadi, M.F. (2017). Aturan dan Teknik dalam Melakukan Normalisasi Data.