7

BAB 2

LANDASAN TEORI

2.1 Teori Umum

` 2.1.1 Analisa Menurut Mc Leod (2007:74), Analisa adalah penelitian terhadap

System yang telah ada dengan tujuan untuk merancang sistem baru atau

memperbaharui sistem yang telah ada tersebut.

2.1.2. Perancangan Menurut Satzinger (2014:5) Perancangan Terdiri dari Ulasan

kegiatan-kegiatan yang memungkinkan seseorang untuk menjelaskan secara

rinci sistem yang memecahkan permasalahan

2.1.3 Teknologi Menurut O’Brien (2005:28) “Teknologi adalah sistem dari berbagai

komponen pemrosesan informasi yang menggunakan berbagai jenis

hardware, software, manajemen data, dan teknologi jaringan

telekomunikasi.”

2.1.4 Sistem informasi Menurut Satzinger (2012:6) “Sistem adalah kumpulan dari komponen

yang saling terkait yang berfungsi bersama – sama untuk mencapai beberapa

tujuan dan sistem informasi secara sederhana mengartikan sebuah sistem

yang mengolah informasi.”

2.1.5 Analisa Perancangan Sistem Informasi Menurut Mohamad Subhan(2012:17) dalam bukunya yang

berjudul Analisa Perancangan Sistem mengungkapkan:

“Sistem informasi merupakan kumpulan data yang diolah menjadi bentuk

yang lebih berguna dan lebih berarti bagi yang menerima. Tanpa suatu

8

informasi, suatu sistem tidak akan berjalan dengan lancar dan akhirnya bisa

mati. Dengan kata lain sumber dari informasi adalah data. Data

menggambarkan suatu kejadian yang sering terjadi, dimana data tersebut akan

diolah dan akan diterapkan dalam sistem menjadi input yang berguna dalam

suatu sistem. Data merupakan bentuk yang belum dapat memberikan manfaat

yang besar bagi penerimanya, sehingga perlu suatu model yang nantinya akan

dikelompokkan dan diproses untuk menghasilkan inFormasi“.

2.1.6 OOAD (Object-Oriented Analysis and design Menurut Whitten et al (2007:25), Object-Oriented Analysis and

Design (OOAD) merupakan suatu kumpulan alat dan teknik untuk

mengembangkan suatu sistem yang akan menggunakan teknologi objek untuk

membangun sebuah sistem dan piranti lunak. Metode OOAD memiliki

beberapa kelebihan, diantaranya adalah lebih mudah digunakan dalam

pembangunan sistem, Tidak ada pemisahan antara fase desain dan analisis,

sehingga meningkatkan komunikasi antara user dan developer. Komunikasi

terjadi mulai dari awal hingga akhir pembangunan sistem dan relasi obyek

dengan entitas umumnya dapat di-mapping dengan baik seperti kondisi pada

dunia nyata dan keterkaitan dalam sistem. Hal ini memudahkan dalam

memahami desain.

2.1.7 OOD (Object-Oriented and design Menurut Satzinger (2010:60) pengertian Object-Oriented Design

(OOD) adalah semua jenis objek yang diperlukan untuk berkomunikasi

dengan orang dan perangkat dalam sistem, menunjukan bagaimana objek

berinteraksi untuk meyelesaikan tugas, dan menyempurnakan definisi dari

masing-masing jenis objek sehingga dapat diimplementasikan dengan bahasa

tertentu.

2.1.8 OOA (Object-Oriented Analysis) Menurut Satzinger (2010:60) Object-Orientied Analysis (OOA)

adalah semua jenis objek yang melakukan pekerjaan dalam sistem dan

menunjukan interaksi pengguna apa yang 21 dibutuhkan untuk

9

menyelesaikan tugas-tugas. Objek diartikan sebagai suatu hal dalam sistem

komputer yang dapat merespon pesan-pesan

2.1.9 Object Oriented Design Model and process Menurut Satzinger (2014:272) Object Oriented design model

and process adalah untuk mengidentifikasi dan menentukan semua objek

yang harus bekerja bersamaan untuk melaksanakan setiap Use Case

2.1.10 Domain Class Diagram Domain model Class Diagram menurut Satzinger (2010:184), adalah

sebuah UML Class Diagram yang menggambarkan cara kerja problem

domain Class es, associations, dan attributes.

10

Gambar 2.1 Contoh Domain Class Diagram 1

2.1.11 System Sequence Diagram Menurut Satzinger (2010:242) Sequence Diagram (SSD) digunakan

untuk menggambarkan alur informasi yang masuk dan keluar dari sistem

secara otomatis. Sistem adalah suatu objek yang mewakili sistem secara

keseluruhan, didalam SSD dan semua Diagram interaksi suatu analisis

menggunakan notasi objek, di mana notasi tersebut menunjukan bahwa kotak

11

mengacu pada objek individu. Dalam Diagram interaksi, pesan yang dikirim

dan diterima yaitu oleh objek individu bukan oleh Class .

Gambar 2.2 : System Sequence Diagram

2.1.12 Package Diagram Menurut Satzinger, Jackson, dan Burd (2004,339), Package

Diagram adalah Diagram high-level sederhana yang memungkinkan

perancang menghubungkan semua Class dalam grup terkait. Notasi

Package Diagram dalam bentuk tab persegi panjang. Nama Package

ditampilkan dalam tab. Dalam gambar 2.1, semua Class dalam Package

ditempatkan dalam tab persegi panjang.

Gambar 2.3 Contoh Package Diagram sumber: Satzinger, Jackson, dan Burd

12

(2004, 341)

2.1.13 Human Resource (HR) Menurut mayo (2004:120) sumber daya manusia atau human

Resource memiliki lima komponen yaitu individual

capability,individual motivation, leadership, the organizational

climate, dan workgroup effectiveness

2.1.14 Keuangan Menurut gitman (2012:4) adalah “finance can be defined as

the science and art of managing money” yang artinya adalah

keuangan dapat didefinisikan sebagai seni dan ilmu mengelola uang.

2.1.16 Project Planning Menurut schwable (2004:45-46) Project

Planning memungkinkan aktifitas-aktifitas yang diatur dengan

manajemen waktu. Perencanaan yang diminta pada aktifitas tersebut

dengan bentuk sistem terkirim suatu laporan pelaksanaan yang

tercatat. Hal ini untuk memandu dan menjamin pelaksanaan proyek

perangkat lunak.

2.1.17 Implementation Defenisi Implementasi menurut Kadir, A dalam

bukunya “Perancangan Sistem informasi” Andi , Yogyakarta, 2003.

“Implementasi adalah kegiatan yang dilakukan untuk menguji

data dan menerapkan sistem yang diperoleh dari kegiatan seleksi”.

Implementasi merupakan salah satu unsur pertahapan dari

keseluruhan pembangunan sistem komputerisasi, dan unsur yang

harus dipertimbangkan dalam pembangunan sistem komputerisasi

yaitu masalah perangkat lunak (software), karena perangkat lunak

yang digunakan haruslah sesuai dengan masalah yang akan

diselesaikan, disamping masalah perangkat keras (hardware) itu

sendiri.

13

2.1.18 System Development Life Cycle (SDLC) Menurut Satzinger (2005:59), System Development Life Cycle

(SDLC) adalah seluruh proses yang membangun, menyebarkan,

menggunakan, dan memperbarui sistem informasi.

Berikut ini adalah Fase-fase Sistem Development Life Cycle (SDLC) meliputi : A. Perencanaan Sistem (Systems Planning)

Lebih menekankan pada aspek studi kelayakan pengembangan

sistem (feasibility study). Aktivitas-aktivitas yang ada meliputi :

• Pembentukan dan konsolidasi tim pengembang

• Mendefinisikan tujuan dan ruang lingkup pengembangan

• Mengidentifikasi apakah masalah-masalah yang ada bisa

diselesaikan melalui pengembangan sistem.

• Menentukan dan evaluasi strategi yang akan digunakan dalam

pengembangan sistem.

• Penentuan prioritas teknologi dan pemilihan aplikasi.

B. Analisis Sistem (Systems Analysis)

Analisa sistem adalah tahap di mana dilakukan beberapa aktivitas

berikut:

• Melakukan studi literatur untuk menemukan suatu kasus yang bisa

ditangani oleh sistem.

• Brainstorming dalam tim pengembang mengenai kasus mana yang

paling tepat dimodelkan dengan sistem.

• Mengklasifikasikan masalah, peluang, dan solusi yang mungkin

diterapkan untuk kasus tersebut.

• Analisa kebutuhan pada sistem dan membuat batasan sistem.

• Mendefinisikan kebutuhan sistem.

C. Perancangan Sistem (Systems Design)

Pada tahap ini, features dan operasi-operasi pada sistem

dideskripsikan secara detail. Aktivitas-aktivitas yang dilakukan

adalah:

14

• Menganalisa interaksi obyek dan fungsi pada sistem.

• Menganalisa data dan membuat skema database.

• Merancang user interface.

D. Implementasi Sistem (Systems Implementation)

Tahap berikutnya adalah implementasi yaitu mengimplementasikan

rancangan dari tahap-tahap sebelumnya dan melakukan uji coba.

Dalam implementasi, dilakukan aktivitas-aktivitas sebagai berikut:

• Pembuatan database sesuai skema rancangan.

• Pembuatan aplikasi berdasarkan desain sistem.

• Pengujian dan perbaikan aplikasi (debugging).

E. Pemeliharaan Sistem (Systems Maintenance)

Dilakukan oleh admin yang ditunjuk untuk menjaga sistem tetap

mampu beroperasi secara benar melalui kemampuan sistem dalam

mengadaptasikan diri sesuai dengan kebutuhan.

2.1.19 User Interface Design Concepts Menurut Satzinger, Jackson, dan Burd (2012:193), dalam

merancang sebuah user interface tentu tidak lepas dari kaidah–kaidah

penulisan serta aturan yang baik untuk menghasilkan user interface

yang baik pula. Delapan Aturan Emas (Eight golden rules) merupakan

delapan aturan untuk merancang layar antarmuka yang interaktif dan

mendukung fungsi kegunaan.

2.1.20 CRUD Matrix Menurut Scott A. Bernard (2007:310) crud Matrix ialah

sebuah kegiatan atau bahan Matrix dikembangkan oleh entitas data

yang dipengaruhi oleh garis yang berhubungan dengan kegiatan

usaha. Sering disebut crud Matrix karena mengidentifikasi jenis dasar

transformasi yang dilakukan pada data (create, read, update, delete)

melalui proses bisnis.

15

2.1.21 Metode perancangan Software Menurut IEEE (Institute of electrical and electronics

Engineers , Pengembangan software (software engineering ) adalah :

Aplikasi sistematik, disiplin, pendekatan kuantitatif untuk

pengembangan, operasi dan pemeliharaan dari software,

dengan kata lain software engineering merupakan sebuah metodologi

pengembangan perangkat lunak (software) yang membahas semua

aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi

sistem hingga pada tahap pemeliharaan sistem setelah digunakan

dengan tujuan untuk membuat perangkat lunak yang tepat dengan

metode yang tepat.

Berikut tahapan pembuatan software:

1. Metode

Metode software engineering memberikan tehnik-tehnik

bagaimana membentuk software. Terdiri dari serangkaian tugas

seperti perencanaan dan estimasi proyek/ Software merupakan bagian

terbesar dari sistem, sehingga pekerjaan dimulai dengan cara

menerapkan kebutuhan semua elemen sistem dan mengalokasikan

sebagian kebutuhan tersebut ke software. Pandangan terhadap sistem

adalah penting, terutama pada saat software harus berhubungan

dengan elemen lain, seperti hardware, software lain dan database.

2. Analisis kebutuhan sistem dan software

Merupakan suatu proses pengumpulan kebutuhan software

untuk mengerti sifat -sifat program yang dibentuk software

engineering, atau analis harus mengerti fungsi software yang

diinginkan, performance dan interfase terhadap elemen lainnya. Hasil

dari analisis ini didokumentasikan dan ditinjau bersama-sama klien.

16

3. Desain struktur data

Desain software sesungguhnya adalah proses multi step

(proses yang terdiri dari banyak langkah) yang memfokuskan pada 3

atribut program yang berbeda, yaitu struktur data, arsitektur software

dan rincian prosedur.

* Arsitektur program dan prosedur algoritma

Proses desain menterjemahkan kebutuhan kedalam

representasi software yang dapat diukur kualitasnya sebelum coding

dimulai. Hasil dari desain ini didokumentasikan dan menjadi bagian

dari konfigurasi software.

* Coding

Merupakan proses penterjemahan desain ke dalam bentuk

yang dapat dibaca oleh mesin.

* Testing dan pemeliharaan

Setelah objek program dihasilkan, testing program dimulai.

Proses testing difokuskan pada logika internal software. Jaminan

bahwa semua pernyataan atau statements sudah dites dan lingkungan

external menjamin bahwa definisi input akan menghasilkan output

yang diinginkan. Sementara proses pemeliharaaan atau maintenance

dilakukan karena software mengalami error, atau harus diadaptasi

untuk menyesuaikan dengan lingkungan external.

2.2 Product and Services

Tingkat kedua ini mengidentifikasi layanan bisnis produk dari

perusahaan dan mengkontribusi teknologi untuk mendukung sebuah proses

bisnis.

17

EA Artifacts :

a. Business Plan

Business Plan adalah perencanaan yang menghasilkan fungsi

bisnis dan strategi financial yang sejalan dengan tujuan

perusahaan Business plan memiliki beberapa item pendukung

Bernard (2012:127) yaitu:

• Business overview.

• Executive team profile.

• Relationship of Business activities to strategic goal.

• Organizational structure.

• Market outlook and competitive strategy.

• Business cycles.

• Capitalization strategy.

• Financial strategy.

• Current financial status summar.

• Business partnerships and alliance1

b. Swim Lane Process Diagram

Menurut Bernard (2012:291) Diagram ini memakai Format

“Swim Lanes” untuk mengatur para stakeholder dengan

menggunakan baris, dan kerangka waktu dengan kolom,

kemudian meliputi aktivitas dengan simbol flowchart.

Gambar 2.2 Swim Lane Process Diagram Sumber : (Bernard, 2012, 291)

18

Gambar 2.2 Sari dan Asniar mengatakan pada jurnal Analisis dan

Pemodelan Proses Bisnis Prosedur Pelaksanaan Proyek Akhir

Sebagai Alat Bantu Identifikasi Kebutuhan Sistem (2015)

Swimlanes Diagram atau cross – functional Diagram adalah

flowchart proses yang menyediakan inFormasi yang lebih banyak

mengenai siapa melakukan apa. Hal ini juga dapat diperluas untuk

menunjukkan waktu ketika tugas yang dilakukan dan berapa lama

mereka ambil.

c. Business Process Diagram

Menurut Bernard (2012:292) Business Process Diagram

menunjukkan pengelompokan rinci dari suatu kegiatan, termasuk

bagaimana setiap langkah dalam kegiatan tersebut berhubungan

dengan yang lain. B-4 Diagram mengikuti IDEF-0 teknik

pemodelan untuk menunjukkan apa yang input, kontrol, keluaran,

dan mekanisme untuk setiap langkah dalam proses.

Gambar 2.3 Business Process Diagram

19

Dari penjelasan Bernard (2012) gambar tersebut :

• Inputs: Produk yang memulai memicu kegiatan dan berubah,

dikonsumsi, atau menjadi bagian.

• Control: Panduan atau mengatur kegiatan, biasanya

menunjukkan bagaimana sebuah proses akan dilakukan.

• Outputs: Hasil yang dihasilkan oleh aktivitas, alasan yang

proses dilakukan.

• Mechanisme: Sistem, orang, dan peralatan yang digunakan

untuk melakukan kegiatan tersebut.

d. Usecase Narrativeand Diagram

Menurut Bernard (2012:242) Usecase Narative mengikuti sebuah

Format Unified Modelling Language (UML) untuk

mengidentifikasi bisnis, kebutuhan, aktor, dan peraturan bisnis itu

sendiri yang berinteraksi dengan sistem.

Usecase Diagram menurut Satzinger et el, (2010:242) adalah

suatu aktivitas yang dilakukan pada sistem, biasanya merupakan

sebuah respon untuk permintaan daripenguna sistem.

Gambar 2.4 Use Case Diagram

Sumber : (Bernard, 2012, 294)

20

Menurut Haviluddin pada jurnal Memahami Penggunaan UML

(Unified Modelling Language) 2011 mengatakan Use Case

Diagram menggambarkan actor, Use Case dan relasinya sebagai

suatu urutan tindakan yang memberikan nilai terukur untuk aktor.

Sebuah Use Case digambarkan sebagai elips horizontal dalam suatu

Diagram UML Use Case .

Use Case memiliki dua istilah yaitu :

a. System Use Case ; interaksi dengan sistem.

b. Business Use Case ; interaksi bisnis dengan konsumen atau

kejadian nyata

1.2.3 Data and Information

Mendokumentasikan bagaimana informasi saat ini sedang digunakan

dalam perusahaan dan bagaimana masa depan arus inFormasi akan terlihat.

EA Artifacts :

a. Object State-Transition Diagram

Menurut Bernard (2012:298). Object state trasition Diagram adalah

menggunakan notasi dari Unified Modelling Language (UML)

menjelaskan siklus hidup dari sebuah data objek secara spesifik.

Diagram ini memperlihatkan perubahan pada atribut, hubungan, dan

objek “On-Line Order” yang menghasilkan kejadian sistem internal

atau eksternal untuk memicu perubahan dalam keadaan

b. Object Event Trace Diagram

Menurut Bernard (2012:129).Juga disebut sebagai Object

“Sequence” Diagram, Diagram D-5 mendukung pelacakan aksi

dalam serangkaian skenario atau thread operasional. Setiap model

harus fokus kepada urutan kritis dari kejadian dan deskripsi dari

skenario ini harus mengikuti model.

21

c. Logical Data Model

Menurut Bernard (2012:300) Model data semantik dapat

dikembangkan menggunakan metode terstruktur tradisional dan

symbol Entity Relationship Diagram (ERD) yang menghasilkan

Diagram kelas/objek.

Menurut Satzinger et al. (2010, 168) Class Diagram digunakan untuk

menunjukkan objek Class untuk sistem. Notasinya dari Unified Modelling

Language (UML), yang telah menjadi standar untuk model yang digunakan

dengan pengembangan System Object Oriented .

Setiady dan Yulistia mengatakan pada jurnalnya berjudul Sistem InFormasi

Pemesanan Dan Penjualan Berbasis Web Pada Dewi Florist (2013) Diagram

Class atau kelas Diagram menggambarkan struktur sistem dari segi

pendefinisian kelas-kelas yang akan dibuatuntuk membangun sistem. Di

bawah inimerupakan gambar Class Diagram untukmenggambarkan struktur

sistem yang akan dibuat untuk membangun sistem.

Gambar 2.5 Logical Data Model

Sumber : (Bernard, 2012, 300)

22

Menurut Haviluddin Memahami Penggunaan Unified Modelling

Language (UML) Class Diagram menggambarkan struktur statis

dari kelas dalam sistem anda dan menggambarkan atribut, operasi

dan hubungan antara kelas. Class Diagram membantu dalam

memvisualisasikan struktur kelas-kelas dari suatu sistem dan

merupakan tipe Diagram yang paling banyak dipakai.Selama tahap

desain, Class Diagram berperan dalam menangkap struktur dari

semua kelas yang membentuk arsitektur sistem yang dibuat.

Class memiliki tiga area pokok :

• Nama (dan stereotype)

• Atribut

• Method

d. Physical Data Model

Menurut Bernard (2012:301) Model data fisik ialah untuk

menjabarkan bagaimana informasi ditampilkan di dalam model

data logika yang secara sudah terimplementasi secara otomatis

dalam sistem informasi.

Model Data Fisikal menampilkan :

• Format Pesan:

� Referensi Standar

� Tipe pesan

� Isi pesan dengan representasi

� Map dari model data logika untuk isi pesan

• Struktur File

� Referensi standar

� Sejarah dan deskripsi file

� Map dari model data logika untuk sejarah isi pesan

• Skema fisikal

� Notasi DDL atau ERA dengan detil untuk kebutuhan

skema

23

� Map dari model data logika untuk model data fisikal

dengan rasional

e. Activity/Entity (CRUD) Matrix

Menurut Bernard (2012, 310) Sebuah Kegiatan atau Badan Matrix

dikembangkan oleh entitas data yang dipengaruhi oleh garis yang

berhubungan dengan kegiatan usaha. Sering disebut 'CRUD' Matrix

karena mengidentifikasi jenis dasar transFormasi yang dilakukan

pada data (Create, Read, Update, Delete) melalui proses bisnis.

f. Data Dictionary

Menurut Bernard (2012:303) kamus datamenyatakan kamus data

menyediakan perbandingan list dari entitas data yang didapatkan

dari perusahaan, termasuk panjang field atribut, key, dan hubungan

antar data.

Muhbib mengatakan dijurnalnya berjudul Implementasi

Desktop Sistem Inventasi Pada Hudi Motor Karangrayung Grobogan

bahwaKamus data atau Data Dictionary (DD) adalah katalog fakta

tentang data dan kebutuhan-kebutuhan inFormasi dari suatu sistem

inFormasi.Pada tahap perancangan sistem, kamus data digunakan

untuk merancanginput, laporan dan database. Kamus data dibuat

berdasarkan arus data yang ada di Data Flow Diagram (DFD)

sifatnya global, sedangkan keterangan lebih lanjut tentang struktur

dari arus data.

Wibowo mengatakan pada jurnalnya berjudul Perancangan

Aplikasi Gudang Pada PT. Pakan Ternak Sejati (2014) Kamus data

adalah suatu daftar data elemen yang terorganisir dengan definisi yang

tetap dan sesuai dengan sistem, sehingga user dan analis sistem

mempunyai pengertian yang sama tentang input, output, dan

komponen data store. Kamus data ini sangat membantu analis sistem

dalam mendefinisikan data yang mengalir di dalam sistem, sehingga

pendefinisian data itu dapat dilakukan dengan lengkap dan

24

terstruktur.Pembentukan kamus data dilaksanakan dalam tahap

analisis dan perancangan suatu sistem. Pada tahap analisis, kamus

data merupakan alatkomunikasi antara user dan analis sistem tentang

data yangmengalir di dalam sistem, yaitu tentang data yang masuk

kesistem dan tentang informasi yang dibutuhkan oleh user. Sementara

itu, pada tahap perancangan sistem kamus data digunakan untuk

merancang input, laporan dan database.

Menurut Muhbib, Implementasi Desktop Sistem Inventasi

Pada Hudi Motor Karangrayung Grobogan (2013) Tabel ini

menjelaskan dengan Merupakan gambaran dari seluruh atributyang

ada dan diambil secara langsung dari formulir atau slip pada objek

penelitian, misalnya data tamu, data kamar dan sebagainya.

g. Knowledge Management Plan

Menurut Bernard (2012:) Knowledge Management plan

menghasilkan deskripsi detail dari bagaimana ilmu, informasi, dan

data saling dibagikan dalam proses bisnis. Didalam knowledge

management plan termasuk deskripsi dan Diagram-Diagram dari

inFormasi yang dibagikan antara sistem, aplikasi, basis ilmu, dan

basis data.

Menurut Wulantika dalam jurnalnya berjudul Knowledge

Management Dalam Meningkatkan Kreasi dan Inovasi Perusahaan

(2014) Knowledge management merupakan kegiatan organisasi dalam

mengelola pengetahuan sebagai aset, dimana dalam berbagai

strateginya ada penyaluran pengetahuan yang tepat kepada orang yang

tepat dan dalam waktu yang cepat, hingga mereka bisa saling

berinteraksi, berbagi pengetahuan dan mengaplikasikannya dalam

pekerjaan sehari-hari demi peningkatan kinerja organisasi.

2.2.4 Systems & Application

a. System Interface Diagram

Menurut Bernard (2012:304) System Interface Diagram

bergunamenampilkan logika dan/atau fisik tampilan antarmuka

25

antara sistem informasi perusahaan, produksi, dan lain-lain. Dimana

informasi dan/atau sumber daya saling bertukar.

Gambar 2.6 System Interface Diagram

Sumber : (Bernard,2012, 304)

Gambar 2.6 ini menurut Bernard (2012) menjelaskan dengan

adanya System Interface Diagram, data dari sumber daya dan

inFormasi dapat ditampilkan baik logika maupun fisik tampilan

antar muka dalam sistem inFormasi. Diagram ini mampu

menampilkan sistem tampilan antarmuka dalam seluruh

departemen yang telah terintegrasi. System Interface Diagram

juga menampilkan sistem yang terintegrasi internal maupun

koneksi eksternal.

b. Data Flow Diagram

Menurut Bernard (2012:307) edata flow Diagram lebih dikenal

dengan “Data Flow Diagram” (DFD) yang menampilkan seluruh

proses aliran data dari sistem dan bagaimana pertukaran data

26

terjadi. DFD sangat membantu pengguna untuk memahami sistem

secara logika, terstruktur dan jelas. Artefak SA-4 System Data

Flow Diagram terhubung dengan B-4 Bussines Process Diagram,

dan dapat diuraikan untuk menampilkan detil tambahan.

Dengen dan Hatta mengatakan dalam jurnal berjudulPerancangan

Sistem InFormasi TerpaduPemerintah Daerah Kabupaten Paser (2009),

bahwa Data Flow Diagram (DFD) merupakan alat pemodelan dari proses

analisis kebutuhan perangkat lunak. Dalam DFD dibahas fungsi-fungsi apa

saja yang diperlukan oleh suatu sistem dan aliran data yang terdapat diantara

proses di dalamnya. DFD berguna sebagai alat untuk verifikasikan apakah

sistem yang akan dibangun sudah memenuhi kriteria yang diinginkan oleh

user atau belum. Data flow Diagram dapat dikembangkan dari levelpaling

rendah ke level lebih tinggi.Context Diagram (Diagram level 0) merupakan

pengembangan dari Diagram konteks, DFD level 1 (Diagram rinci)

merupakan pengembangan dari DFD level 0. Tiap proses dari DFD dapat

dikembangkan lagi menjadi lebih detail sampaiprosestersebut tidak dapat

dikembangkanlagi.Context Diagram (CD) memperlihatkan sistem yang

dirancang secara keseluruhan, semua external entity harus digambarkan

sedemikian rupa, sehingga dapat terlihat aliran data pada input-proses-output.

CD menggunakan tiga buah simbol yaitu: simbol untuk melambangkan

external entity, simbol untuk melambangkan data flow dan simbol untuk

melambangkan process. CD hanya dapat terdiri dari satu proses saja, tidak

boleh lebih, dan pada CD tidak digambarkan data store. Proses pada CD

biasanya tidak diberi nomor.

Menurut Jogiyanto (2010:700) dalam bukunya berjudul Analisis dan

Desain Sistem Infromasi, menjelaskan bahwa:”Data Flow Diagram

digunakan untuk menggambarkan suatu sistem yang telah ada atau

pengembangan sistem baru secara logika tanpa mempertimbangkan

lingkungan fisik dimana data tersebut mengalir atau lingkungan fisik dimana

data tersebut akan disimpan. Data Flow Diagram juga digunakan pada

metodologi pengembangan dengan sistem terstruktur.

27

Tabel 2.1 Simbol Data Flow Diagram 1

No

Simbol Keterangan

1. External Entity

2. Arus / Aliran Data

3. Proses / Subsistem

4. Data Store

Sumber : (Jogiyanto, 2010, 700)

Menurut Jogiyanto (2010)Tabel ini adalah suatu simbol-simbol untuk

mengambarkan sebuah Data Flow Diagram (Diagram Aliran Data) bisa juga

disebut System Data Flow Diagram sehingga simbol-simbol tersebut saling

terhubung dengan satu sama lain.

28

Gambar 2.7 Data Flow Diagram

Sumber : (Bernard, 2012, 304)

Menurut S. Pressman (2012) Gambar ini menjelaskan

memperlihatkan gambaran tentang masukan-proses-keluaran dari suatu

sistem/perangkat lunak, yaitu obyek-obyek data mengalir ke dalam perangkat

lunak, kemudian ditransFormasi oleh elemen-elemen pemrosesan, dan obyek-

obyek data hasilnya akan mengalir keluar dari sistem/perangkat lunak.

Obyek-obyek data dalam penggambaran DFD biasanya direpresentasikan

menggunakan tanda panah berlabel, dan transFormasi-transFormasi biasanya

direpresentasikan menggunakan lingkaran-lingkaran yang sering disebut

sebagai gelembung-gelembung

• System Flow Description

Menurut Bernard (2012:305), bagaimana data berkomunikasi

antara sistem di seluruh perusahaan dan termasuk penentuan links,

paths, Networks, dan media.

29

Gambar 2.8 System Flow Description

Sumber : (Bernard, 2012, 305)

Gambar ini menurut Bernard (2012) menjelaskan bagaimana

NODE 1 dan NODE 2 terhubung, Node 1 yang berada di regional

Timur Utara yang menggunakan jaringan LAN untuk

menghubungkan kedua sistem yang ada di perusahaan. Pada

Node 2 Regional barat, menggunakan sistem selular untuk

berinteraksi di dalam perusahaan. Jaringan yang menghubungkan

Node 1 dengan Node 2 adalah Node 3. Node 3 adalah kantor

pusat yang menghubungkan jaringan antara Node 1 dengan Node

2. Node 3 juga membuat Firewall (Penjaga Sistem ) agar tidak

bisa di akses oleh perusahaan ataupun pihak – pihak luar yang

tidak bertanggung mengakses data perusahaan.

30

• Web Application Diagram

Menurut Bernard (2012:312) Web Application Diagram

menunjukkan sebuah hubungan secara logis antara layanan

inFormasi berbasis web, dalam kasus ini menunjukkan Diagram

yang didetailkan dari layanan yang berinteraksi melalui protokol

dan antar muka standar yang mendukung pertukaran data

platForm independen

2.2.5 Security a. Security and Privacy Plan

Menurut Bernard (2012,328), perencanan keamanan menyediakan

baik tingkat tinggi dan deskripsi rinci dari program keamanan

yang berlaku di seluruh perusahaan. Ini termasuk personil data

fisik dan elemen keamanan operasional dan prosedur.

b. Disaster Recovery Plan

Menurut Bernard (2012:324). Rancangan pemulihan bencana

adalah rancangan matriks dan beberapa prosedur untuk menangani

resiko didalam berbagai bisnis dan/atau teknologi kapabilitas yang

tidak memenuhi entrepretasi untuk relokasi dalam

operasional.Resiko dapat berupa bencana alam atau kesalahan

manusia itu sendiri.

Contoh:

1. Aktivasi pemulihan bencana. Kondisi dalam aktivasi COOP

2. Peran pemulihan dan tanggung jawab. Matriks dai peran dan

tanggung jawab dalam semua personil dalam entrepretasi siapa

yang ikut serta dalam aktivasi COOP.

3. Hasil bencana dan tugas pemulihan. Matriks standar untuk

identifikasi tipe dan durasi dari resiko, baik dalam sistem dan

fungsi di dalam entreprtasi yang tergabung. Bergantung dalam tipe

resiko dan durasi resiko, prosedur pemulihan dapat berbeda-beda.

31

4. Prosedur pemulihan. Prosedur yang dipakai untuk memulihkan

bisnis dan/atau fungsi sistem yang menghalangi. Contoh

termasuk:

• Resiko kelistrikan

• Resiko pendingin/penghangat

• Kerusakan gedung(api, banjir, gempa)

• Kerusakan ruangan(api, banjir, gempa)

• Sistem inFormasi terinvesi virus

• Kehilangan internal atau eksternal komunikasi data

• Kehilangan internal atau eksternal komunikasi telepon

c. Security Solution Description

Menurut Bernard (2012:)Deskripsi solusi keamanan menunjukan

pandangan tingkat tinggi dari bagaimana keamanan membuktikan

dalam sumber daya pilihan yang terdapat di perusahaan. Solusi ini

meliputi empat dimensi keamanan: fisik, data, perorangan, dan

operasional dan mungkin termasuk Diagram dan matriks.

d. System Accreditation Document

Menurut Bernard (2012:322) System Accreditation Document

menggunakan Format standar untuk mengevaluasi status

keamanan dari sistem informasi dalam perusahaan

e. Continuity of Operations Plan

Continuity of Operations Plan (COOP) menggunakan standar

Format untuk mendeskripsikan kemana semua atau sebagian

perusahaan akan direlokasikan jika lokasi operasi normal tidak

dapat digunakan untuk beberapa waktu (lebih dari beberapa hari)

akibat kejadian alam.

32

2.2.6 Workforce a. Workforce Plan

Menurut Bernard (2012:327), menyediakan sebuah deskripsi

tingkat tinggi tentang bagaimana modal manusia diatur melalui

perusahaan. Workforce Plan termasuk strategi yang dapat

memperkerjakan, penyimpanan, dan pengembangan profesional di

manajemen eksekutif, dan tingkatan pegawai perusahaan.

b. Organization Chart

Menurut Bernard (2012:328), Menunjukan bagaimana posisi dan

personil terorganisir di dalam Diagram hiraki atau Format

matriks. Struktur organisasi membantu untuk menunjukan garis

otoritas, hubungan pekerjaan, baik juga kepemilikan sumber daya,

produk, dan proses.

Gambar 2.9 Organizational Chart

Sumber:(Bernard,2012,328)

Pada gambar tersebut menurut Bernard (2012) Struktur

organisasi dapat menggambarkan secara jelas pemisahan

kegiatan dari pekerjaan antara ke satu dengan kegiatan kelainnya

dan juga bagaimana hubungan antara aktivitas dan fungsi dibatasi.

Di dalam struktur organisasi yang baik harus dapat menjelaskan

hubungan antara wewenang siapa melapor atau bertanggung

33

jawab kepada siapa, jadi terdapat suatu pertanggung jawab apa

yangakandikerjaka

34