7 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
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
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.
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
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.
(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.
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:
• 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.
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.
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.
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)
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.
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
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.
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)
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
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
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
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
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.
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.
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.
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.
• 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.
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.
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
jawab kepada siapa, jadi terdapat suatu pertanggung jawab apa yangakandikerjaka
