BAB III

METODOLOGI

3.1. Analisis Sistem Berjalan

Analisis Sistem Berjalan
Analisis sistem adalah sebuah teknik pemecahan masalah yang
menguraikan sebuah sistem menjadi bagian-bagian komponen dengan tujuan
mempelajari seberapa bagus bagian-bagian komponen tersebut bekerja dan
berinteraksi untuk meraih tujuan mereka. (Whitten, Bentley, dan Dittman).
Analisis sistem berjalan merupakan tahap awal dari tahap pemecahan
masalah. Tahap analisis sistem berjalan memberi gambaran umum proses yang
sedang berjalan. Dari analisis proses yang berjalan, didapat informasi mengenai
gambaran dan kelemahann yang ada pada proses sehingga bisa dicari solusi
pemecahan masalahh yang ada. Hasil dari analisis sistem berjalan digunakan
sebagai bahan rancangan sistem usulan.

Analisis Proses Bisnis

Jadwal pelaksanaan pencacahan SKTr dilakukan selama satu bulan setelah

masa masing-masing triwulan selesai, yaitu pada April, Juli, Oktober, dan Januari

pada tahun berikutmya. Pengolahan memakan waktu paling lama yaitu selama 2
bulan.
Poses alur dokumen SKTr dimulai dengan BPS RI mengirim kuesioner ke
BPS Provinsi, kemudian kuesioner didistribusikan ke BPS Kabupaten/Kota.
Kuesioner yang telah selesai diisi oleh perusahaan kemudian diperiksa oleh
pengawas BPS Kabupaten/Kota lalu dikirim ke BPS Provinsi untuk diperiksa dan
dikirim ke BPS RI. Kuesioner tersebut dikirim dalam beberapa kali pengiriman.
Di BPS RI kuesioner tersebut diperiksa untuk di entri dan dibuat publikasi dengan
nama Indikator Konstruksi Triwulan Tahun 2016Gambaran dari sistem berjalan
ditunjukkan dengan gambar berikut..
Pada Subdit Statistik Konstruksi,

dokumen-dokumen tersebut di kelompokkan berdasarkan provinsi,

kemudian di cek kecocokan jumlah dokumen yang diterima dengan surat laporan.
Dokumen tersebut kemudian dibagikan kepada petugas-petugas untuk di entri.
Sebelum entri data, harus dilakukan respon dokumen terlebih dahulu. Dengan
respon dokumen, didapat informasi perusahaan-perusahaan yang masih aktif, non
respon, tutup atau kosong, dan perusahaan yang ter survei dua kali.
Ada dua kondisi dokumen, yaitu

dokumen perusahaan aktif dan

perusahaan non respon. Untuk dokumen perusahaan aktif, ada dua kategori, yaitu
ada isian (isian kuesioner) ada proyek dan ada isian tidak ada proyek. Jika
dokumen perusahaan tersebut ada isian tidak ada proyek, makan blok III
kuesioner tersebut harus kosong. Blok III berisi Nilai Pekerjaan dan Realisasi

Fisik Pekerjaan. Jika perusahaan non respon, ada beberapa kategori alasan, yaitu
perusahaan tutup, pindah, atau kosong. Untuk perusahaan non-respon, tidak
dilakukan entrian data, berhenti di proses respon. Perusahaan-perusahaan yang
non respon akan dikeluarkan dari daftar sampel utama. Perusahaan-perusahaan
tersebut akan diganti oleh perusahaan terpilih dari daftar sampel pengganti.

Gambar 3.1. Bisnis Proses Berjalan

Analisis Proses Bisnis
Analisis Proses bisnis memberi gambaran umum proses yang akan
dibangun atau dikembangkan. Hasil dari analisis proses bisnis digunakan sebagai

bahan dasar rancangan sistem usulan. Gambaran proses sistem yang diusulkan
ditunjukkan dengan gambar berikut.

Gambar 3.2. Bisnis Proses Respon Dokumen

Kode Proses

Keterangan
(2)

(1)

Batching per Provinsi

Input: Dokumen survei
Output: Dokumen survei telah dikelompokkan dan
P01

diberi nomor
Pada proses ini petugas melakukan pengelompokkan
dokumen survei berdasarkan provinsi dan memberi
nomor kelompok.
Perusahaan ada di DSU?
Pada proses ini petugas melakukan pengecekan tiaptiap dokumen survei, apakah perusahaan yang didata
ada didalam Data Sampel Utama. Jika ada, catat

D01
kondisi

dokumen

tersebut

apakah

termasuk

dokumen yang dapat dientri atau tidak. Jika tidak,

lanjutkan
D02

proses

berikutnya.

Lihat

klasifikasi

kondisi dokumen pada P04

Perusahaan ada di List Frame?
Jika perusahaan tidak ada di DSU, namun ia terpilih
sebagai sampel, periksa apakah perusahaan ada di
List Frame. Jika ada, berarti perusahaan telah

berganti. Tuliskan perusahaan yang diganti beserta

alasan penggantian pada proses 02. Jika tidak ada,
periksa lagi apakah perusahaan ada di Database
Konstruksi.
Ada di Database Direktori Konstruksi?
Jika

perusahaan

ada

di

Database

Direktori

Konstruksi, Tuliskan perusahaan yang diganti dan

D03

yang

menggantikan.

Jika

tidak

ada,

maka

perusahaan termasuk perusahaan baru. Tambahkan

perusahaan sebagai perusahaan baru.
Tuliskan perusahaan yang diganti beserta alasan
P02

Input: Perusahaan pengganti

Output: Perusahaan yang diganti dan keterangan
Masuk ke Tambahan Perusahaan Baru

P03

Input: Informasi perusahaan

Output: Data perusahaan sebagai perusahaan baru

Catat Kondisi Dokumen

Input: Kode kondisi dokumen
Output: Halaman Tambahkan Perusahaan dan
Daftar Perusahaan
P04

Untuk

dokumen

yang

dapat

dientri

akan

menampikan halaman daftar perusahaan untuk

menambahkan data konstruksi perusahaan triwulan
baru. Jika dokumen tidak dapat di entri, cek
dokumen berikutnya.

Analisis Permasalahan
Masalah-masalah

yang

ditemukan

digambarkan pada diagram ishikawa berikut.

pada

proses

sistem

berjalan

Gambar 3.3x. Ishikawa Diagram atau Ddiagram Ffishbone

1. Proses entri data menggunakan desktop-based. Proses entri data survei saat
ini menggunakan applikasi berbasis desktop. Petugas harus menginstall
aplikasi baru setiap ada perubahan rule.
2. Daerah masih menggunakan rule validasi versi lama. Karena di daerah
terkadang terlambat informasi, rule validasi yang digunakan adalah rule
validasi versi yang lama. Sementara itu, di pusat sudah menggunakan rule
validasi versi yang terbaru. Jadi, terjadi ketidak cocokan hasil.
3. Aplikasi untuk respon dokumen SKTr 2016 tidak ada. Pada tahun 2016,
Subdit Statistik Konstruksi menerapkan sistem baru untuk respon
dokumen. Belum ada aplikasi yang sesuai dengan sistem yang berlaku saat
ini.
4. Sistem Respon dan Entri pada aplikasi terpisah, untuk suatu kuesioner,
pilih menu respon lalu cari perusahaan kemudian lakukan respon
dokumen, berikutnya pilih menu entri data lalu cari lagi perusahaan
tersebut untuk dientri. Proses ini tidak efektif untuk kegiatan entri data
yang membutuhkan kecepatan.
5. Dibutuhkan waktu lama untuk penerimaan dokumen dari BPS Provinsi ke
BPS RI. Karena banyaknya dokumen di masing-masing provinsi,
dokumen survei dari BPS Provinsi dikirim menjadi beberapa kali
pengiriman.
6. Sedikitnya petugas entri. Ada 2800 dokumen yang akan dientri setiap kali
survei, belum termasuk dokumen Survei Perusahaan Konstruksi Tahunan,
sementara petugas di subdit Statistik Konstruksi hanya satu orang untuk
respon dokumen dan beberapa orang untuk entri data.Menunggu
penerimaan dokumen survei dari daerah. Proses pengiriman dan

penerimaan dokumen hasil survey memakan waktu yang lama untuk

sampai ke pusat.
7. Pusat harus memperbaiki data dengan rule validasi yang baru. Karena data
yang dikirim dari pusat masih menggunakan rule validasi versi yang lama,
sehingga data-data tersebut harus diedit agar sesuai dengan rule validasi
yang baru.
8. Daerah telat informasi. Daerah-daerah terkadang terlambat mendapatkan
informasi terbaru.
Tidak dapat memonitor progress entrian data survei. Tidak ada fasilitas untuk
memonitor progress di daerah.
Analisis Kebutuhan

3.1. Metode Pengumpulan Data

Metode pengumpulan data yang peneliti gunakan adalah metode
wawancara dan observasi. Wawancara adalah sebuah metode yang dilakukan
melalui tatap muka dan tanya jawab secara pribadi bersama narasumber (subject
matter) yang menangani data-data yang berkaitan dengan sistem yang akan dibuat.
Wawancara dilakukan dengan tujuan mendapatkan informasi-informasi yang
dibutuhkan dalam penelitian serta pengembangan sistem yang akan dibuat. Dalam
penelitian ini, pihak yang bertindak sebagai nara sumber adalah Subdirektorat
Statistik Konstruksi BPS RI.
Observasi dilakukan dengan suatu pengamatan atau kegiatan sistematis
terhadap objek yang dituju secara langsung dengan menggunakan indera mata.

Dalam penelitian ini, observasi dilakukan dengan mengamati aplikasi respon

dokumen dan entri data yang pernah digunakan.

Solusi Permasalahan
Berdasarkan

uraian

mengenai

analisis

sistem

berjalan,

analisis

permasalahan, dan solusi alternative, maka dapat diputuskan solusi untuk

menyelesaikan permasalahan yang ada.
Tabel 3.2. Solusi alternatif (dari Informant Communications Group and Microsoft
Corporation (2002))

1. Sistem

Solusi
berbasis

desktop

Kelebihan
Memiliki performance

Sulit

yang

oleh pengguna dimana

unggul

disesuaikan

karena
dengan

spesifikasi hardware
Tidak
membutuhkan
waktu

Kekurangan
untuk diakses

dan kapan saja berada

Sulit
untuk
di
aplikasikan

pada

pengiriman

banyak

pengguna

data dari server ke

karena

harus

client atau sebaliknya

melakukan

instalasi

terlebih dahulu pada

komputer client
Sulit jika ada update
Memiliki spesifikasi
hardware

tertentu

sehingga

ada

kemungkinan

mesin

2. Sistem

berbasis

web

aplikasi hanya di install

pengguna bisa berbeda

di server side
Pekerjaan lebih mudah

tergantung

browser

karena sistem dapat di

yang digunakan
Bergantung

akses

kecepatan internet di

oleh
dimana

terpusat,

Bersifat

yang tidak cocok

Tampilan ke setiap

secara

online

pengguna
dan

kapan

saja.
Tidak perlu melakukan
instalasi program.

tempat
Dibutuhkan

pada

sistem

keamanan yang tinggi

karena banyak orang
dapat mengaksesnya

Berdasarkan hasil wawancara dengan subject matter, subdit Statistik

Konsntruksi menyarankan pengembangan sistem entri data SKTr berbasis web.
Selain itu dengan mempertimbangkan kelebihan dan kekurangan kedua
solusi berbasis desktop dan web, peneliti menetapkan solusi pengembangan
sistem berbasis web sebagai solusi masalah.

Rancangan Proses Bisnis

Untuk menggambarkan proses bisnis sistem yang akan dibuat, dijelaskan
melalui diagram use case dan activity diagram berikut.
Use Case

Gambar 3.4. Diagram Use Case Rancangan Sistem

Tabel 3.x. Deskripsi Use Case Menambahkan akun
Nama Use :
ID Use Case :
Prioritas :
Pelaku :
Deskripsi :

Menambahkan Akun
Tipe Use Case :
SDE-UC001
Desain Sistem
Tinggi
Administrator
Use case ini mendeskripsikan kejadian admin

Prakondisi :
Sasaran :

menambahkan akun petugas

Admin login
Membuat akun petugas

Bidang

khas

suatu Kegiatan Pelaku

Langkah 1: Pelaku login

Respons Sistem
Langkah 2: Sistem

event :
menampilkan form
pembuatan akun baru

Bidang Alternatif :

Langkah 3: Pelaku

Langkah 4: Sistem

mengisi form pembuatan

meyimpan informasi

akun baru
akun kedalam database
Alt-Langkah 4: Jika ada isian yang tidak sesuai
format, sistem memberikan peringatan kepada
pelaku

Kesimpulan :

Use case ini menyimpulkan akun petugas telah

Postkondisi :

dibuat
Informasi akun baru telah dibuat

Tabel 3.x. Deskripsi Use Case Respon Dokumen

Nama Use :
ID Use Case :
Prioritas :
Pelaku :
Deskripsi :
Prakondisi :
Sasaran :
Bidang
khas

Respon Dokumen
Tipe Use Case :
SDE-UC002
Desain Sistem
Tinggi
Petugas
Use case ini mendeskripsikan kejadian petugas
melakukan respon dokumen
Petugas login
Respon dan kondisi dokumen telah disimpan
suatu Kegiatan Pelaku
Respons Sistem
Langkah 1: Pelaku login Langkah 2: Sistem

event :
dan memilih menu Respon menampilkan halaman
Dokumen

Respon Dokumen

Langkah 3: Pelaku

Langkah 4: Sistem

mengisi form respon dan

mengalihkan ke

Bidang Alternatif :

menekan tombol Simpan

halaman entri data
Alt-Langkah 4: Jika dokumen perusahaan nonrespon,
sistem kembali ke halaman Respon Dokumen

Kesimpulan :
Postkondisi :

Use case ini menyimpulkan kondisi perusahaan

Dialihkan ke halaman entri dan/atau halaman respon

Tabel 3.x. Deskripsi Use Case Entri Data

Nama Use :
ID Use Case :
Prioritas :
Pelaku :
Deskripsi :
Prakondisi :
Sasaran :
Bidang
khas

Entri Data
Tipe Use Case :
SDE-UC003
Desain Sistem
Tinggi
Petugas dan Administrator
Use case ini mendeskripsikan kejadian petugas
melakukan entri data
Petugas login dan telah melakukan respon dokumen
Data Perusahaan Triwulanan dapat ditambahkan
suatu Kegiatan Pelaku
Respons Sistem
Langkah 1: Pelaku telah Langkah 2: Sistem

event :
melakukan

respon

dan menampilkan halaman

akan entri data

Entri Data blok II

Langkah 3: Pelaku

Langkah 4: Sistem

mengisi form blok II, III,

mengalihkan ke

IV, dan V dan menekan

halaman blok III,IV,

tombol simpan

dan V.
Sistem berhasil

Bidang Alternatif :

menyimpan data.
Alt-Langkah 4: Jika ada isian yang tidak sesuai
format, sistem memberikan peringatan kepada

Kesimpulan :

pelaku
Use case ini menyimpulkan informasi perusahaan
telah tersimpan

Postkondisi :

Dialihkan ke halaman respon

Tabel 3.x. Deskripsi Use Case Memverifikasi Perusahaan

Nama Use :
ID Use Case :
Prioritas :
Pelaku :
Deskripsi :

Memverifikasi Perusahaan
Tipe Use Case :
SDE-UC004
Desain Sistem
Tinggi
Administrator
Use case ini mendeskripsikan kejadian admin
menganalisa penambahan perusahaan baru dan

Prakondisi :
Sasaran :
Bidang
khas
event :

menerima permintaan penambahan data perusahaan

Perusahaan akan menambahkan perusahaan
Data perusahaan baru berhasil ditambahkan
suatu Kegiatan Pelaku
Respons Sistem
Langkah 1: Pelaku login Langkah 2: Sistem
dan

memilih

menu menampilkan halaman

Verifikasi Perusahaan
Langkah
menganalisa
dan

3:

Verifikasi Perusahan

Pelaku Langkah 4: Sistem

perusahaan mengubah status

mengubah

status perusahaan menjadi

perusahaan tersebut dari accept

Bidang Alternatif :

pending menjadi accept

-

Kesimpulan :

Use case ini menyimpulkan perusahaan baru harus di

analisa oleh admin terlebih dahulu dan diterima

Postkondisi :

sebagai perusahaan baru

Dialihkan ke daftar perusahaan

Tabel 3.x. Deskripsi Use Case Menambahkan Perusahaan

Nama Use :

Menambahkan Perusahaan

Tipe Use Case :

ID Use Case :
Prioritas :
Pelaku :
Deskripsi :

SDE-UC005
Desain Sistem
Tinggi
Petugas dan Administrator
Use case ini mendeskripsikan kejadian pegawai dan
admin menambahkan perusahaan sebagai perusahaan

Prakondisi :
Sasaran :
Bidang
khas
event :

baru maupun perusahaan pengganti

Pelaku login
Perusahaan sebagai perusahaan baru
suatu Kegiatan Pelaku
Respons Sistem
Langkah 1: Pelaku login Langkah 2: Sistem
dan

memilih

menu menampilkan halaman

Tambah Perusahaan

form Tambah

Langkah

3:

Perusahan
Pelaku Langkah 4: Sistem

mengisi

form

tambah menampilkan pesan

perusahaan dan menekan informasi telah dikirim

tombol Simpan

ke admin dan
menunggu konfirmasi

Bidang Alternatif :

admin
Alt-Langkah 4: Jika ada isian yang tidak sesuai
format, sistem memberikan peringatan kepada
pelaku

Kesimpulan :

Use case ini menyimpulkan penambahan perusahaan

Postkondisi :

baru kedalam database

Sistem kembali ke halaman Tambah Perusahaan

Tabel 3.x. Deskripsi Use Case Menghapus Akun

Nama Use :
ID Use Case :
Prioritas :

Menghapus akun
SDE-UC006
Tinggi

Tipe Use Case :

Desain Sistem

Pelaku :
Deskripsi :
Prakondisi :
Sasaran :
Bidang
khas

Administrator
Use case ini mendeskripsikan kejadian admin
menghapus akun petugas
Pelaku login
Menghapus akun petugas
suatu Kegiatan Pelaku
Respons Sistem
Langkah 1: Pelaku login Langkah 2: Sistem

event :
dan memilih menu Daftar menampilkan daftar
Petugas

petugas serta informasi

Langkah

3:

mencari

nama

menekan

tombol

Pelaku Langkah 4: Sistem

petugas, menampilkan
hapus peringatan apakah

dan menekan OK pada yakin akan menghapus

peringatan dari sistem

Sistem menghapus
petugas dari database
akun?

Bidang Alternatif :

Kesimpulan :

Use case ini menyimpulkan informasi petugas telah

Postkondisi :

dihapus dari database

Sistem menampilkan halaman daftar petugas

Diagram Aktivitas
Diagram aktivitas digunakan untuk menjelaskan alur aktivitas sistem
ketika suatu use case dijalankan. Oleh karena itu, diagram aktivitas dibangun
berdasarkan use case yang telah dibentuk sebelumnya. Diagram aktivitas
menggambarkan berbagai aliran aktivitas dalam sistem yang dirancang,

bagaimana masing-masing aliran berawal, keputusan yang mungkin terjadi

dalam aliran tersebut, dan bagaimana aliran-aliran tersebut berakhir.

Gambar 3.5. Diagram Aktivitas Menambahkan akun

Gambar 3.6. Diagram Aktivitas Respon Dokumen

Gambar 3.7. Diagram Aktivitas Entri Data

Gambar 3.8. Diagram Aktivitas Memverifikasi Perusahaan

Gambar 3.9. Diagram Aktivitas Menambahkan Perusahaan

Gambar 3.10. Diagram Aktivitas Menghapus Akun

Rancangan Basisdata
Rancangan basisdata dilakukan dalam tiga tahapan, yaitu rancangan
konseptual. rancangan logical, dan rancangan fisikal.
1. Rancangan Konseptual
Tabel 3.x.
No
(1)
11
2
3
4

Nama Entitas
(2)
User
Perusahaan
Blok_II

Deskripsi
(3)
Berisi data pengguna sistem
Berisi informasi perusahaan
Berisi informasi mengenai tenaga

Blok_III

Kerja, balas jasa, dan rata-rata upah

Berisi informasi mengenai nilai
Pekerjaan

dan

realisasi

fisik

Blok_IV

pekerjaan
Berisi informasi mengenai kondisi

Blok_V

dan prospek perusahaan

Berisi
informasi

Respon_dokumen

permasalahan kinerja perusahan

Berisi informasi terkait kondisi

mengenai

dokumen

2. Rancangan Logika
Rancangan logika merupakan tahapan dalam mengidentifikasi
entitas-entitas beserta atribut-atributnya yang sebelumnya dibentuk pada
tahap rancangan konseptual. Dalam rancangan logika, akan ditentukan
primary key dan foreign key dari masing-masing entitas.

User (username,,password,role,firstname,lastname,user_id)
Primary Key (user_id)
Perusahaan
(kip,nama,contact_person,telepon_fax,email,hp,kabupaten_kota,provinsi,
kecamatan,desa,blok_sensus,status)
Primary Key (kip)
Blok_II (Sum_pekerja_tetap, Sum_pekerja_outsourcing,
sum_balas_jasa_pekerja_tetap, Sum_balas_jasa_pekerja_outsourcing
Avg_upah_pekerja_harian_oh,
avg_upah_tukang_oh,avg_pembantu_tukang_oh,avg_instalir_jaringan_li
strik_oh,avg_jaringan_telekomunikasi_oh,avg_instalir_jaringan_pipa_air
_bersih_oh,triwulan,kip_perusahaan,id)
Primary Key(id)
Foreign Key kip_perusahaan references perusahaan(kip)
Blok_III
(nama_pekerjaan,nilai_kontrak_pekerjaan,np_subkontrak,sum_jumlah_u
pah_harian,biaya_bahan,kumulatif_realisasi,kumulatif_rencana,triwulan,
kip_perusahaan,id)
Primary Key (id)
Foreign Key kip_perusahaan references perusahaan (kip)
Blok_IV
(pendapatan_usaha,
nilai_pekerjaan_yang_selesai,
order_bahan_bangunan,harga_bahan_bangunan,sum_pekerja_tetap,flag,a
vg_gaji_pekerja_tetap,sum_pekerja_harian_lepas,upah_pekerja_harian_o
h,triwulan,kip_perusahaan,id)
Primary Key (id)
Foreign Key kip_perusahaan references perusahaan (kip)
Blok_V (akses_kredit, suku_bunga_pinjam, kenaikan_harga_bangunan,

penurunan_permintaan,
SDM_terampil,

persaingan,

kesulitan_pasokan_bagunan,

birokrasi_adm_pemerintah,

politik_keamanan,

k3,

kip_perusahaan,triwulan,id)
Primary Key (id)
Foreign Key kip_perusahaan references perusahaan (kip)
Respon_dokumen
(jabatan_pemeriksa,telp_pemeriksa,nip_pemeriksa,
nip_pemeriksa,

nama_pemeriksa,

nip_pencacah,

nama_pencacah,

jabatan_pencacah,
jenis_dokumen,

telp_pencacah,

kondisi_dokumen,

tanggal_entri, triwulan, id, kip_perusahaan)

Primary Key (id)
Foreign Key kip_perusahaan references perusahaan (kip)

Tabel 3.x. Rincian atribut Entitas

No

Nama Field

Tipe

Panjang

.
1
2
3
4
6
8
10

KIP
Nama
alamat
kabupaten_kota
kecamatan
Desa
No_blok_sensus

Integer
Varchar
Text
Varchar
Varchar
Varchar
Varchar

Karakter
10
255
65k
255
255
255
255

11
12
13
14
15
15
16
17
18
19

Sum_pekerja_tetap
Sum_pekerja_outsourcing
Sum_balas_jasa_pekerja_tetap
Sum_balas_jasa_pekerja_outsourcing
Avg_upah_pekerja_harian_oh
Avg_upah_kepala_tukang_oh
Avg_upah_tukang_oh
Avg_pembantu_tukang_oh
Avg_instalatir_jaringan_listrik_oh
Avg_instalatir_jaringan_komunikasi_o

Integer
Integer
Integer
Integer
Integer
Integer
Integer
Integer
Integer
Integer

10
10
10
10
10
10
10
10
10
10

Keterangan
Primary Key

20
21

h
Avg_instalatir_jaringan_komputer_oh
Avg_instalatir_jaringan_pipa_air_bersi

Integer
Integer

5
5

22
23

h_oh
triwulan
Kip_perusahaan

Integer
Varchar

1
10

Foreign Key
table

24

Nama_pekerjaan

Varch

25

Nilai_kontrak_pekerjaan

ar
Intege

11

26

Np_subkontrak

r
Intege

11

27

Sum_jumlah_upah_harian

r
Intege

11

28

Biaya_bahan

r
Intege

11

29

Kumulatif_realisasi

r
Doubl

30

Kumulatif_rencana

e
Doubl

31

Triwulan

e
Intege

32

Kip_perusahaan

r
Varch

10

Pendapatan_usaha

ar
Varch

255

Nilai_pekerjaan_yang_selesai

ar
Varch

255

Order_bahan_bangunan

ar
Varch

255

33
34
35

ar

255

Perusahaan
Promary
Key

FK

table

Perusahaan

36

Harga_bahan_bangunan

Varch

255

37

Sum_pekerja_tetap

ar
Varch

255

38

Avg_gaji_pekerja_tetap

ar
Varch

255

39

Sum_pekerja_harian_lepas

ar
Varch

255

40

Upah_pekerja_harian_lepas_oh

ar
Varch

255

41

Triwulan

ar
Intege

Kip_perusahaan

r
Varch

10

Akses_kredit

ar
Varch

255

Suku_bunga_pinjam

ar
Varch

255

45

Kenaikan_harga_bangunan

ar
Varch

255

46

Penurunan_permintaan

ar
Varch

255

47

Persaingan

ar
Varch

255

48

Kesulitan_pasokan_bangunan

ar
Varch

255

49

SDM_terampil

ar
Varch

255

50

Birokrasi_adm_pemerintah

ar
Varch

255

Politik_keamanan

ar
Varch

255

42
43
44

51

ar

FK

table

Perusahaan

52

K3

Varch

255

53

Kip_perusahaan

ar
Varch

10

FK

54

Kip

ar
Varch

10

perusahaan
PK

55

nama

ar
Varch

255

56

Alamat

ar
Varch

255

57

Contact_person

ar
Varch

255

Telepon_fax

ar
Varch

20

Email

ar
Varch

255

Hp

ar
Varch

20

61

Id_kabupaten_kota

ar
Intege

62

Id_propinsi

r
Intege

63

Id_kecamatan

r
Intege

64

Id_desa_kelurahan

r
Intege

Id_blok_sensus

r
Intege

58
59
60

65

1. R F

table

Gambar 3.11. Diagram Entity Relationship

Rancangan Antarmuka
Rancangan Halaman Login

Gambar 3.1x. Rancangan Halaman Login

Rancangan Tambah Data Perusahaan

Data
Rancangan

Gambar 3.1x Rancangan Antar muka Tambah Perusahaan

Rancangan Antar Muka Respon Dokumen

Gambar 3.1x. Rancangan Antar Muka Respon Dokumen

Gambar 3.1x Rancangan Antar Muka Respon Dokumen (2)

Rancangan Antar Muka Entri Blok II
Rancangan Antar Muka Entri Blok III
Rancangan Antar Muka Entri Blok IV
Rancangan Antar Muka Entri Blok V
Rancangan Antar Muka Daftar Pengguna

Gambar 3.15. Rancangan Antar Muka Daftar Pengguna

Rancangan Antar Muka Validasi Perusahaan

Gambar 3.1x. Rancangan Antar Muka Validasi Perusahaan