apsi pert 1 - 7

84
TUJUAN INSTRUKSIONAL UMUM : Agar Mahasiswa dapat mengenal dan memahami tahapan-tahapan-dalam analisa sistem global, menggambarkan flow sistem, Detail sistem, implementasi detail sistem dengan menggunakan bahasa pemrograman dan membuat laporan dari sistem komputerisasi sebagai landasan dalam membuat tugas akhir. ANALISA DAN PERANCANGAN SISTEM INFORMASI

Upload: tendi

Post on 16-Jan-2016

82 views

Category:

Documents


3 download

DESCRIPTION

APSI

TRANSCRIPT

TUJUAN INSTRUKSIONAL UMUM :

Agar Mahasiswa dapat mengenal dan memahami tahapan-tahapan-dalam analisa sistem global, menggambarkan flow sistem, Detail sistem, implementasi detail sistem dengan menggunakan bahasa pemrograman dan membuat laporan dari sistem komputerisasi sebagai landasan dalam membuat tugas akhir.

ANALISA DAN PERANCANGAN SISTEM INFORMASI

BENTUK EVALUASI :

Partisipasi 10% Tugas 20% Ujian Tengah Semester 30% Ujian Akhir Semester 40%

J u m l a h 100%

MATERI KULIAH

Konsep Dasar Sistem Informasi Analisis dan metodologi pengembangan system Pemodelan Proses Pemodelan Data Studi Kasus HIPO Desain Antarmuka Testing, Implementasi dan Pemeliharaan Sistem Melaporkan Dokumentasi Pengujian Studi Kasus

1.Cris Gane dan Trish Sarson, Structured System Analysis: NJ : Prentice Hall, 1990

2. H.M Jogiyanto, Analisis dan Desain Sistem Informasi: Pendekatan Terstruktur Teori dan Praktek Aplikasi Bisnis, Andi Offset Yogyakarta, 2002

BUKU REFERENSI

Definisi Sistem

Suatu sistem adalah suatu jaringan kerja dari prosedur-prosedur yang saling berhubungan, berkumpul bersama-sama untuk melakukan suatu kegiatan atau untuk menyelesaikan suatu sasaran yang tertentu

Sistem adalah kumpulan dari elemen-elemen yang berinteraksi untuk mencapai suatu tujuan tertentu.

Misalnya :

Sistem akuntansi dapat terdiri dari beberapa subsistem-subsistem, yaitu

subsistem akuntansi penjualan, subsistem akuntansi pembelian, subsistem akuntansi penggajian, subsistem akuntansi biaya, dan lain sebagainya.

Karakteristik Sistem

Karakteristik atau sifat-sifat tertentu dari suatu sIstem terdiri dari :

Komponen-komponen (components) Batas sIstem (boundary) Lingkungan luar system (environments) Penghubung (interface) Masukan (input) Keluaran (output) Pengolah (process) Sasaran (objectives) atau tujuan (goal)

Klasifikasi Sistem

Sistem abstrak (abstract system) dan sistem fisik(physical system)

Sistem alamiah (natural system) dan sistem buatan manusia (human made system).

Sistem tertentu (deterministic system) dan sistem taktentu (probabilistic system)

Sistem tertutup (closed system) dan sistem terbuka (open system)

SIKLUS HIDUP SISTEM

PENGERTIAN SIKLUS HIDUP SISTEM

Metodologi adalah suatu cara yang disarankan untuk melakukan suatu hal. Pendekatan sistem adalah metodologi dasar untuk memecahkan masalah.

SIKLUS HIDUP SISTEM (System Life Cycle-SLC)

Adalah penerapan pendekatan sistem untuk pengembangan sistem atau subsistem informasi berbasis komputer.

TAHAP-TAHAP SIKLUS HIDUP

Empat tahap siklus hidup sistem adalah

perencanaan, analisis, rancangan dan penerapan

Pengembangan Sistem (PS)

PS adalah menyusun suatu sistem yang baru untuk menggantikan sistem yang lama secara keseluruhan atau memperbaiki sistem yang telah ada.

Dengan adanya PS akan terdapat peningkatan yang berhubungan dengan

P I E C E S, yaitu : P erformance atau kinerjaI nformation atau informasiE conomy atau ekonomisC ontrol atau pengendalianE fficiency atau efisienS ervices atau pelayanan

Prinsip Pengembangan Sistem Sistem yang dikembangkan untuk manajemen Sistem yang dikembangkan adalah modal yang

besar Sistem yang dikembangkan memerlukan tenaga

ahli Sistem yang dikembangkan sebagai tahapan

kerja melalui proses pengambangan Proses pengembangan tidak harus berurutan Jangan takut membatalkan proyek Dokumentasi harus ada untuk pedoman dalam

pengembangan.

Metodologi Pengembangan Sistem

Functional Decomposition Methodologies, contoh HIPO

Data Oriented Methodologies terbagi Data Flow Oriented Method dan Data Structure Oriented Method

Prescriptive Methodologies (Information System Design & Optimization System [ISDOS])

Teknik Pengembangan Sistem

Manajemen Proyek, contoh CPM Menemukan Fakta Analisis Biaya dan Manfaat Mengadakan rapat Inspeksi

Gambar. Daur Hidup Pengembangan Sistem

Pengertian Analisis Sistem

Analisis sistem adalah studi sistem bisnis yang sedang berjalan dan permasalahannya, menentukan aktivitas bisnis dan permintaan-permintaan pemakai sistem dan melakukan evaluasi terhadap berbagai alternatf solusi.1

1 Azhar Susanto, Pengantar Aplikasi Komputer (edisi pertama: Lingga Jaya, Bandung, 2001) hal 255

Analisis sistem adalah penguraian dari suatu sistem informasi yang utuh ke dalam bagian-bagian komponennya dengan maksud untuk mengidentifikasikan dan mengevaluasi permasalahan-permasalahan, kesempatan-kesempatan, hambatan-hambatan yang terjadi dan kebutuhan-kebutuhan yang diharapkan sehingga dapat diusulkan perbaikan-perbaikannya. 2

2 Jogiyanto HM, Analisis dan Perancangan Sistem Informasi : Pendekatan Terstruktur (Edisi pertama Cetakan ke 3, Andi Offset, Jogyakarta, 1993) hal 129

Analis sistem adalah orang yang bertanggung jawab untuk mempelajari informasi yang berhubungan dengan masalah-masalah yang timbul dan mampu memberi jalan keluar sesuai dengan masalah yang dihadapi.

Tugas Utama Analis sistem adalah menganalisis sistem yang telah ada, mengembangkannya, dan menyusun sistem baru terutama pada sub sistem yang bermasalah dengan bantuan teknologi komputer.

Mengapa perlu diperbaiki ?

Terdapat beberapa alasan mengapa sistem perlu diperbaiki, yaitu :

Adanya permasalahan, sebagai akibat dari Ketidakberesan atau pertumbuhan organisasi

Untuk meraih kesempatan Adanya instruksi

Pengetahuan & keahlian yangdibutuhkan oleh Analis Sistem :

Teknik Pengolahan data, teknologi komputer dan pemrograman komputer

Bisnis secara umum Metode Kuantitatif Pemecahan Masalah Komunikasi antar personal Membina hubungan antar personal.

Team Pengembangan Sistem Manajer Analis Sistem, berfungsi sebagai koordinator Ketua Analis Sistem, berfungsi sebagai wakil

koordinator Analis Sistem Senior, adalah analis sistem yang

sudah berpengalaman Analis Sistem, adalah analis sistem yang cukup

berpengalaman Analis Sistem Junior, adalah analis sistem belum

berpengalaman Pemrogram Aplikasi Senior, adalah pemrogram yang

sudah berpengalaman Pemrogram Aplikasi, adalah pemrogram yang cukup

berpengalaman Pemrogram Aplikasi Junior, adalah pemrogram yang

belum berpengalaman

Kebijakan & Perencanaan Sistem (KPS)

KPS merupakan landasan dan dukungan dari manajemen puncak untuk membuat perencanaan sistem.

Langkah yang diambil dalam KPS adalah : Mengkaji, menyetujui/ membuat rekomendasi Mengkoordinasi pelaksanaan Memonitor / mengawasi kemajuan Menilai kinerja dari fungsi-fungsi sistem Memberikan saran-saran dan petunjuk

Proses Perencanaan Sistem, terbagi :

Merencanakan proyek-proyek sistem,

dilakukan oleh staf perencana sistem Mempersiapkan proyek-proyek sistem yang

akan dikembangan, dilakukan oleh komite pengarah

Mendefinisikan proyek-proyek sistem yang dikembangkan, dilakukan oleh analis sistem.

Sistem yang akan dipelajari adalah sistem terotomasi, sebagai bagian dari sistem buatan manusia dan berinteraksi oleh satu atau lebih komputer sebagai bagian dari sistem yang digunakan oleh masyarakat modern.

Komponen Sistem Terotomasi :

perangkat keras seperti cpu, disk,jaringan komputer, printer

perangkat lunak seperti sistem operasi, sistem basis data, program pengontrol komunikasi, program aplikasi

sumber daya manusia seperti orang yang mengoperasikan sistem, penyedia masukan pengguna masukan dan keluaran serta aktivitas manual yang mendukung sistem

data, yaitu yang harus tersimpan dalam sistem selama jangka waktu tertentu

prosedur seperti intruksi dan kebijakan untuk mengoperasikan sistem

Kategori Sistem Terotomasi :

On-line system adalah sistem yang menerima langsung input pada area dimana input tersebut direkam dan menghasilkan output yang dapat berupa hasil komputasi

Real-time system adalah mekanisme pengontrolan perekaman data pemrosesan yang sangat cepat

Decision Support System+strategic Planning System adalah sistem yang memproses transaksi organisasi secara harian dan membantu para manajer mengambil keputusan mengevaluasi dan menganalisis tujuan organisasi

Knowledge-based System adalah program komputer yang dibuat mendekati kemampuan seorang pakar

Sistem secara prinsip dasar terbagi dalam

Sistem TerspesialisasiSistem BesarSistem sebagai bagian sistem lainSistem berkembang

Pelaku Sistem

Pemakai Manajemen Pemeriksa Analis Sistem Perancangan sistem Programmer Personil Pengoperasian

Perangkat Analisis Terstruktur dengan menggunakan Model sebagai berikut :

Data Flow Diagram (menggambarkan fungsi sistem) bisa juga untuk penurunan level/leveled yaitu Context Diagram

Entity Relationship Diagram (menggambarkan entiti dan hubungan antar entiti dalam sistem)

State Transition diagram (memetakan hubungan antar tingkah laku sistem dan ketergantungan terhadap waktu)

Perubahan dalam analisis sistem

analisis terstruktur, dengan cara me representasikan spesifik sistem

perubahan dalam analisis sistem terstruktur klasik, mencakup eliminasi proses mempelajaris sistem lama, penggabungan model fisik dan lojik, penerapan time dependent untuk membantu memetakan sinkronisasi dan koordinasi dalam pemodelan serta penggabungan perangkat pemodelan

Perangkat analisis terotomasi misal CASE (Computer Aided Software engineering) yang mempunyai fungsi pengecekan kesalahan

Penggunaan protipe, umumnya menitikberatkan pemodelan hanya pada aspek human interface dalam perancangan sistem

Penggabungan analisis dan Perancangan sistem, sebagai cara tepat agar tidak terjadi salah pengertian antara pelaku sistem

Perangkat Pemodelan Sistem

Statement of Purpose Event List Data Flow Diagram Context Level (Context Diagram) Data Flow Diagram Levelled Data Dictionary Process Specifications Entity-Relationship Diagram Relasi Dependensi dan Kunci Normalisasi State-Transition Diagram Block Chart Diagram System Procedure Diagram Menyeimbangkan Model

3 alasan yang melakukan pemodelan sistem, yaitu.

Dapat memfokuskan perubahan pada hal-hal penting dalam sistem tanpa terlibat terlalu jauh.

Mendiskusikan perubahan dan koreksi terhadap kebutuhan pemakai dengan resiko dan biaya minimal.

Menguji pengertian analis sistem terhadap kebutuhan pemakai dan membantu Perancang sistem dan pemrogram membangun sistem.

Terdapat banyak bentuk model yang dapat kita gunakan dalam perancangan :

antara lain model narasi, model prototipe, model grafis, dan lain-lain.

Mengenai Model mana yang akan digunakan, yang penting harus mampu merepresentasikan visualisasi bentuk sistem yang diinginkan pemakai,

Pada dunia pemodelan sistem terdapat sejumlah cara yang merepresentasikan sistem dengan diagram misalnya,

Flowcharts, HIPO (hierarchy input process output), decision tables, system flowcharts, state-transition diagram, decision trees, entity relation program, dan banyak model lainnya

Pada dasarnya kita dapat menggunakan model apa saja tergantung dari situasi.

Sejumlah sistem mungkin saja membutuhkan lebih dari satu cara pemodelan, dan setiap model difokuskan pada aspek tertentu saja yang sifatnya terbatas.

Kebanyakan sistem yang dibuat pada masa ini mempunyai fungsi spesifik kompleks, struktur data kompleks dan ketergantungan pada waktu yang juga kompleks.

Secara garis besar karakteristik pemodelan yang seharusnya digunakan yaitu;

Dibuat dalam bentuk grafis dan tambahan keterangan secara tekstual; dengan grafis lebih banyak yang dapat dijelaskan dibandingkan pemodelan dengan narasi.

Dapat diamati dengan pola top-down dan partitioned; sangat panting bagi sistem yang berukuran besar, karena bagi sistem yang dapat dijelaskan dengan satu atau dua halaman, hal ini tidak jadi macalah.

Memenuhi persyaratan minimal redundancy; karena sistem relatif selalu berubah maka perubahan akan lebih mudah jika dilakukan pada sejurnlah aspek lokal tanpa mengaitkannya dengan aspek lain yang memang tidak perlu diubah.

Dapat merepresentasikan tingkah laku sistem dengan cara yang transparan. Sebagai model yang baik, persyaratan lain yang harus dipenuhi adalah mudah dibaca, sehingga lebih mudah dari sistem itu sendiri.

1. Statement of Purpose

Statement of Purpose (STP), yang berisi deskripsi tekstuai fungsi sistem. Hal ini berguna bagi hampir semua level antara lain 'level puncak, level pemakai, dan level lain yang tidak terlibat secara langsung dalam pengembangan sistem.

contoh satu STP:

Kegunaan sistem pemrosesan buku adalah menangani semua aspek data pemesanan buku oleh pelanggan, seperti pengiriman, pembayaran dan pengembalian bukti pembayaran pelanggan. Informasi buku tersebut juga disediakan bagi sistem lain seperti pemasaran, penjualan, dan keuangan.

STP dapat :

hanya terdiri dari satu, dua atau lebih kalimat.

Tetapi sebaiknya tidak lebih dari satu paragraf, karena tidak digunakan untuk mendeskripsikan sistem secara terinci.

Deskripsi terinci menjadi tanggung-jawab aspek pemodelan berikutnya.

Akibat penggambaran yang terlalu global, penggunaan STP akan memancing banyak pertanyaan seperti:

Informasi seperti apa yang harus disediakan untuk sistem keuangan, sistem penjualan dan sistem pemasaran dari sistem pemesanan?

Bagaimana menetapkan kelayakan pelanggan memperoleh kredit, apakah sistem pemesanan yang menentukan atau harus mendapat kontirmasi sistem keuangan?

Bagaimana sistem pemesanan siap dengan data buku yang telah diterbitkan dan siap dijual?

Pertanyaan lain yang lebih mendasar adalah :Apakah sistem pemesanan melakukan

fungsi penggajian personil? Kita dapat dengan mudah mengatakan tidak, karena lingkup penggajian secara logika tentu berada di bawah sistem keuangan

Apakah sistem pemesanan bertanggung jawab dalam memberikan bukti transaksi pada pelanggan? Jawabannya bisa tidak tetapi bisa juga ya, sehingga menjadi tidak jelas dan harus dijelaskan dalam STP.

Apakah sistem pemesanan bertanggung-jawab terhadap stok?

Hal ini diperlukan untuk memberikan nilai transaksi yang tidak melebihi batas stok, dan hal ini sulit dijelaskan dalam STP karena secara faktual yang digunakan sistem pemesanan adalah informasinya dan bukan pertanggung-jawabannya.

2. Data Flow Diagram Context Level (Context Diagram)

Context Diagram (CD) adalah kasus khusus DFD (bagian dari DFD yang berfungsi memetakan model lingkungan), yang direpresentasikan dengan lingkaran tunggal yang mewakili keseluruhan sistem.

Gambar 1 di bawah ini merupakan contoh CD sistem pemesanan buku.

Gambar 1. Diagram Konteks sistem pemesanan buku

CD menyoroti sejumlah karakteristik penting sistem yaitu:

Kelompok pamakai, organisasi atau sistem lain dimana sistem kita melakukan komunikasi yang disebut juga sebagai Entitas Luar.

Data masuk, data yang diterima sistem dari lingkungan dan harus diproses dengan cara tertentu.

Data keluar, data yang dihasilkan sistem kita dan diberikan ke dunia luar

Penyimpanan data (data store) yang digunakan secara bersama antara sistem kita dengan Entitas Luar.

Data ini dapat dibuat oleh sistem dan digunakan oleh lingkungan atau sebaliknya, dibuat oleh lingkungan dan digunakan oleh sistem kita. Hal ini berarti pembuatan simbol data store dalam CD dibenarkan, dengan syarat simbol tersebut merupakan bagian dari dunia di luar sistem.

Batasan antara sistem kita dart lingkungan (rest of the world).

CD dimulai dengan penggambaran Entitas Luar, aliran data, aliran kontrol, penyimpanan, dan proses tunggal yang merepresentasikan keseluruhan sistem.

Bagian termudah adalah menetapkan proses yang hanya terdiri dari satu lingkaran dan diberi nama yang mewakili sistem.

Nama dalam hal ini dapat menjelaskan proses atau pekerjaaan atau dalam kasus ekstrim berupa nama perusahaan yang dalam hal ini mewakili proses yang dilakukan keseluruhan organisasi.

Gambar 2. Lambang sebuah sistem

Gambar 3. Komunikasi langsung dan tak langsung

Entitas Luar direpresentasikan. dalam bentuk persegi panjang dan berkomunikasi langsung dengan sistem melalui aliran data atau tidak langsung sehingga harus melalui penyimpanan ekstemal.

Antara Entitas Luar tidak diperbolehkan komunikasi langsung.

Pada kenyataannya hubungan antara terminator mungkin dilakukan, tetapi secara definitif karena terminator adalah bagian lingkungan maka tidak relevan jika dibahas dalam CD.

Jika melalui komunikasi dengan pemakai disimpulkan bahwa hubungan itu esensial, maka entitas luar akan merupakan bagian dari sistem ian seharusnya sudah dianggap ada dalam lingkaran.

Gambar 4. Contoh diagram konteks yang salah

Gambar 5. Duplikasi terminator

Aturan-aturan CD jika terdapat luar entitas luar yang mempunyai banyak

masukan dan keluaran, diperbolehkan untuk digambarkan lebih dari satu kali sehingga mencegah penggambaran yang terlalu rumit, dengan ditandai secara khusus untuk menjelaskan bahwa entitas yang dimaksud adalah identik. Tanda tersebut dapat berupa asterik(*) atau garis silang #.

Jika entitas luar mewakili individu (personil) sebaiknya diwakili oleh peran yang dimainkan personil tersebut. Alasan pertama adalah, personil yang berfungsi untuk melakukan itu dapat berganti sedangkan CD harus tetap akurat walaupun personil berganti. Alasan kedua adalah seorang personil dapat memainkan lebih dari satu peran.

Karena fokus utama kita adalah mengembangkan model esensi maka panting untuk membedakan sumber (sources) dan pelaku (handler).

Pelaku adalah mekanisme, perangkat, atau media fisik yang mentransportasikan data keadaari sistem. Karena pelaku seringkali familiar dengan pemakai dalam implementasi sistem berjalan, maka sering menonjol sebagai sesuatu yang harus digambarkan lebih dari sumber data itu sendiri.

Sedangkan sistem baru dengan konsep pengembangan teknologinya membuat pelaku menjadi sesuatu yang tidak perlu digambarkan.

Aliran dalam CD_memodelkan masukan ke sistem dan keluaran dari sistem, seperti halnya sinyal kontrol yang diterima atau dibuat sistem.

Aliran data hanya digambarkan jika diperlukan untuk mendeteksi kejadian dalam lingkungan dirnana sistem harus memberikan respon atau membutuhkan data untuk menghasilkan respon.

Selain itu aliran data dibutuhkan untuk menggambarkan transportasi antara sistem dan terminator.

Dengan kata lain aliran data digambarkan jika data tersebut diperlukan untuk menghasilkan respon pada kejadian tertentu.

Dalam hal ini kita seharusnya menggambar CD dengan asumsi bahwa masukan disebabkan dan diinisiasi oleh entitas luar, sedangkan keluaran disebabkan dan diinisiasi oleh sistem.

Hal itu dilakukan dengan mencegah interaksi yang tidak perlu (extraneous prompts) yang berorientasi pada implementasi masukan-keluaran, dan mengkonsentrasikan pemodelan pada aliran data yang esensial saja.

Gambar 6. Entitas Luar sebagai sumber, pelaku, dan sumber sekaligus pelaku

Kadang-kadang diperlukan dialog karena Entitas tidak tahu kapan sistem memerlukan masukan. Sebaliknya suatu sistem tidak menghasilkan keluaran, karena tidak tahu Entitas membutuhkannya

Dalam hal ini interaksi menjadi diperlukan dan diasumsikan menjadi bagian esensi sistem sebagaimana

Gambar.8. Sebagai catatan, kita dapat menggunakan dua panah atau satu panah dengan dua kepala untuk menggambarkan dialog antara sistem dan Entitas

Event List (EL) adalah daftar narasi stimuli (daftar kejadian) yang terjadi dalam lingkungan mempunyai hubungan dengan respon yang diberikan sistem.

Sebagai contoh EL bagi diagram konteks pada Gambar 1 sistem pemesanan buku adalah:

Pelanggan memesan (ke sistem, F) Pelanggan membatalkan pemesanan (ke sistem, F) Manajemen membutuhkan laporan penjualan (dari sistem,

T) Buku yang sudah dicetak dikirim ke gudang (ke sistem, C)

Lambang F merupakan singkatan dari (F) low-oriented-event yang mempunyai arti kejadian berorientasi pada aliran data.

Huruf T disingkat dari (T)emporal-event, yang menunjukkan bahwa kejadian tersebut bersifat sementara, misalnya laporan penjualan diberikan setiap akhir bulan.

Simbol C adalah (C)ontrol-event, artinya fungsi pengontrolan terhadap kegiatan-kegiatan yang udah dilakukan.

Control-event merupakan kasus khusus temporal-event, hanya saja tidak dapat dipastikan waktu kejadiannya.

Control-event biasanya digunakan dalam engineering system dan bukan pada business system.

Secara umum setiap aliran data dalam CD adalah kejadian atau event, tepatnya aliran data Mengindikasikan terjadinya kejadian, atau aliran data dibutuhkan oleh sistem untuk melakukan proses.

Aturan-aturan dalam EL antara lain daftar kejadian yang dibuat dan digambarkan dalam bentuk tekstual sederhana yang berfungsi memodelkan kejadian dalam lingkungan dimana sistem harus memberikan respon

Ketika membuat EL maka harus yakin perbedaan antara kejadian (event) dan kejadian yang berelasi dengan aliran (event-related flow).

Sebagai contoh, kalimat berikut bukan merupakan penggambaran kejadian yang tepat:

Pemesanan-pelanggan diterima oleh sistem Karena yang terjadi adalah masuknya data dengan

sistem sebagai pelaku, maka kalimat yang lebih tepat digunakan adalah:

Pelanggan memesan

Jika mendeskripsikan kejadian dari sudut pandang sistem, maka bisa jadi akan membuat kesalahan dalam mengidentifikasi aliran masuk yang sebenamya bukan merupakan kejadian, tetapi diperlukan dalam proses yang berkaitan dengan kejadian lain.

Karena itu seharusrya selalu mendeskripsikan kejadian dari sudut pandang lingkungan.

Cara termudah untuk mengidentifikasi kejadian yang relevan bagi sistem adalah memvisualisasikan sistem secara aksi (action).

Uji setiap entitas dan mencoba mengevaluasi aksi entitas yang terjadi pada sistem dimana pemakai berperan.

Bagaimanapun juga harus hati-hati dalam membedakan kejadian spesifik (discrete event) yang secara tak sengaja menyatu dalam paket yang sama. Perhatikan contoh berikut:

Pelanggan memesan langsung ke sistem Pelanggan memesan melalui personil penjualanmaka, yang pertama tidak membutuhkan data penjual

sedangkan yang kedua membutuhkan data penjual. Maka akan lebih sesuai jika dibedakan kejadiannya menjadi

Pelanggan memesan, dan Penjual memberikan data pemesanan pelanggan.

Harus tetap diingat bahwa kejadian yang dimodelkan bukan hanya interaksi normal antara sistem dan terminator, karena situasi dimana interaksi gagal mungkin membutuhkan konfirmasi atau minimal harus diketahui.

Karena itu ketika semua kejadian dengan interaksi normal telah dibuat, harus mangevaluasi kebutuhan sistem untuk merespon kejadian yang gagal (fails event).

Dalam Gambar 1 (Diagram Konteks) seandainya pengiriman ke gudang tidak sampai, maka harus mendefinisikan apa yang akan dilakukan sistem dengan melacak mengapa terjadi penundaan (delay) dalam pencetakan.

Pada dasarnya tidak jadi masalah model apa yang harus dibuat terlebih dahulu, asalkan satu sama lain terjamin konsistensinya. Umumnya ketika memulai pembuatan CD, maka sukar untuk langsung mengidentifikasi entitas, aliran masukan dan keluaran yang bervariasi.

Setelah kedua model tersebut selesai maka sebaiknya mengkonfirmasikannya dengan aturan berikut ini.

Setiap aliran masukan memang dibutuhkan oleh sistem untuk mengenali kejadian yang berlangsung, atau untuk menghasilkan respon bagi kejadian yang lain atau kedua-duanya.

Setiap aliran keluaran sebaiknya merupakan respon sistem terhadap kejadian

Setiap kejadian yang tidak tergantung pada waktu tertentu dalam daftar kejadian sebaiknya mempunyai aliran masukan agar sistem dapat mendeteksi kejadian yang berlangsung.

Setiap kejadian sebaiknya menghasilkan keluaran langsung sebagai respon, atau disimpan dalam penyimpanan untuk bahan masukan kemudian, sebagai respon atau bagian dari respon dalam kejadian lain, atau menyebabkan perubahan keadaan sistem (system state) yang diindikasi dalam model.

Data Flow Diagram Levelled

Model ini menggambarkan sistem sebagai jaringan kerja Antar fungsi yang berhubungan satu lain dengan aliran dan penyimpanan data (selanjutnya disebut dengan DFD).

Sebagai perangkat analisis, model ini hanya mampu memodelkan sistem dari satu sudut pandang yaitu sudut pandang fungsi.

Ada empat komponen dalam model ini yaitu

1. PROSES; Proses menunjukkan transformasi dari masukan menjadi keluaran, dlm hal ini sejumlah masukan dapat menjadi hanya satu keluaran ataupun sebaliknya. Proses direpresentasikan berbentuk lingkaran (bisa juga oval, atau bujursangkar dengan sudut melengkung, ( dalam materi ini digunakan lingkaran).

Gambar 9 Contoh proses

2. ALIRAN; direpresentasikan dengan panah yang menuju ke/ dari proses menggambarkan gerakan paket data atau informasi dari satu bagian ke bagian lain dari sistem dimana penyimpanan mewakili lokasi penyimpanan data. Ujung panah menunjukkan kemana data bergerak ke/dari proses, penyimpanan ataupun entitas atau keduanya. Aliran yang digambarkan sebagai panah dengan dua ujung menggambarkan terjadinya dialog.

3.PENYIMPANAN: untuk memodelkan kumpulan data atau paket data. Notasi yang digunakan adalah garis sejajar, segi empat dengan sudut melengkung, atau persegi panjang. Dalam materi itu kita akan menggunakan segi empat dengan sudut melengkung.

4. KESATUAN LUAR/ENTITAS LUAR;

direpresentasikan menggunakan persegi panjang, yang mewakili entiti luar dimana sistem berkomunikasi. Biasanya notasi ini melambangkan orang atau kelompok orang misalnya organisasi di luar sistem, grup, departemen, perusahaan pemerintah, dan berada di luar kontrol sistem yang dimodelkan.

Level paling tinggi dalam DFD hanya punya 1 lingkaran yang memodelkan seluruh sistem, sedangkan aliran memodelkan hubungan sistem dengan kesatuan luar

Level ini disebut Context-Diagram (diagram konteks). berperan pemberian nomor pada setiap lingkaran pada DFD yang berguna untuk memudahkan penurunan DFD ke level lebih rendah. Penurunan ini mengacu pada aturan yaitu;Setiap penurunan ke level yang lebih rendah harus

mampu merepresentasikan proses tersebut dalam spesifikasi proses yang jelas. Shg seandainya belum cukup jelas maka seharusnya diturunkan ke level yang lebih rendah.

Setiap penurunan harus dilakukan hanya jika perlu.

Tidak semua bagian dari sistem harus diturunkan dengan jumlah level yang sama karena yang kompleks bisa saja diturunkan, dan yang sederhana mungkin tidak perlu diturunkan.Selain itu, karena tidak semua proses dalam level yang sama punya derajat kompleksitas yang sama juga.

Konfirmasikan DFD yang telah dibuat pada pemakai dengan cara top-down.

Aliran data yang masuk dan keluar pada suatu proses di level x harus berhubungan dengan aliran data yang masuk dan keluar pada level x+1. Dimana level x+1 tersebut mendefinisikan sub-proses pada level x tersebut.

Penyimpanan yang muncul pada level x harus didefinisikan kembali pada level x+1, sedangkan penyimpanan yang muncul pada level x tidak harus muncul pada level x-1 karena penyimpanan tersebut bersifat lokal.

Ketika mulai menurunkan DFD dari level tertinggi, cobalah untuk mengidentifikasi external events dimana sistem harus memberikan respon. External events dalam hal ini berarti suatu kejadian yang berkaitan dengan pengolahan data di luar sistem, dan menyebabkan sistem kita memberikan respon

Gambar Top Level (CD), Level 0 dan Level 1 (berturut-turut)