You are on page 1of 5

Proses Pemodelan Proses Logika

Perencanaan Sistem Strategis Perencanaan Strategis merupakan proyek terpisah yang menghasilkan rencana strategi sistem informasi, yang mendefinisikan visi dan arsitektur keseluruhan untuk sistem informasi. Arsitektur ini sering meliputi model proses perusahaan. Model proses perusahaan ini biasanya hanya mengidentifikasi area dan fungsi bisnis. Kejadian dan proses detail jarang diselidiki. Area dan fungsi bisnis selanjutnya diprioritaskan menjadi pengembangan proyek aplikasi. Prioritas biasanya didasarkan pada area, fungsi, dan aplikasi pendukung bisnis mana yang akan memberikan nilai terbesar pada nilai bisnis secara keseluruhan. Pemodelan Proses Untuk Desain Ulang Proses Bisnis Business Process Redesign (BPR) adalah menganalisii proses bisnis dan kemudian mendesain ulang proses tersebut untuk menghilangkan ketidakefisiean dan birokrasi sebelum aplikasi ulang teknologi informasi. Untuk mendesain ulang proses bisnis, pertama-tama kita harus mempelajari proses yang ada. Model proses memainkan peran integral dalam BPR. Sebagian proses tersebut merupakan persilangan antara diagram aliran data dan flowchart. Diagram tersebut cenderung bersifat fisik karena tim BPR berusaha mengisolasi keanehan implementasi yang menyebabkan ketidakefisienan dan mengurangi nilai. Diagram aliran data/flowchart BPR dapat menyertakan simbol dan informasi baru untuk berusaha menyederhanakan proses dan aliran data dama usaha memaksimalkan efisiensi dan menghasilkan nilai tertinggi organisasi. Pemodelan Proses Selama Analisis Sistem Dalam kerangka kerja sisterm informasi anda, model proses logika fokus pada proses dam perspektif SYSTEM OWNER dam Atau SYSTEM USER. Proses logika tersebut biasanya tidak berkaitan dengan detail atau teknologi implementasi, maka dapat dibuat dari perangkat lunak aplikasi yang ada, tetapi teknologi ini kurang matang dan andal dibanding teknologi reberse data engineering. Pada masa kejayaan pengguna metodologi analisis terstruktur awalm pemodelan proses juga dilakukan dalam fase analisis sistem. Analisis akan membuat model proses fisik dari sistem yang ada, model logika dari sistem yang ada, dan model logika dari sistem target. Tiap model akan dibuat top-down dari model yang sangat umum ke model yang sangat detail. Sekalipun terdengar sangat konseptual, pendekatan ini akan menimbulkan pemodelan yang berlebihan dan penundaan proyek yang signifikan, sehingga guru teknik terstruktur ed yourdon menyebutnya analisis paralysis. Saat ini, sebagian besar strategi analisis terstruktur modern memusatkan perhatian pada pengembangan model logika pada sistem target. Model tersebut tidak dibangun dengan top-down atau bottom-up, melainkan diatur berdasarkan strategi yang masuk akal yang disebut even partitioning yaitu memfaktorkan sistem menjadi subsistem berdasar kejadia dan respon bisnis terhadap kejadian tersebut.

Penemuan Fakta Dan Pengumpulan Informasi Untuk Pemodelan Proses Model proses tidak dapat dibuat tanpa fakta dan informasi yang tepat yang dikirim oleh komunitas pengguna. Fakta tersebut dapat dikumpulkan melalui sebuah teknik sampling terhadap form dan file yang ada, riset terhadap sistem yang serupa, survei terhadap pengguna dan manajemen, wawancara pengguna manajemen. Metode tercepat pengumpulan fakta dan informasi dan secara serempak membuat dan menguji model proses disebut joint requirements planning (JRP). JRP menggunakan pertemuan kelompok yag difasilitasi dengan seksama untuk mengumpulkan fakta, membuat model, menguji model tersebut biasana satu atau dua sesi satu hari penuh. Computer-Aided Systems Engineering (CASE) untuk Permodelan Proses Dengan menggunakan produk CASE, anda dapat dengan mudah membuat model proses yang terbaca dan profesional , tanpa menggunakan kertas, pensil, penghapus dan template. Model tersbeut dapat dengan mudah dimodifikasiuntuk merefleksikankoreksi dan perubahan yang disarankan oleh pengguna akhir. Sebagian besar roduk CASE juga menyediakan alat analisi yang powerful yang dapat memeriksa kesalahan mekanis, kelengkapan dan konsistensi pada model anda. Beberapa produkCASE bahkan dapat membantu anda menganalisis konsistensi, kelengkapan dan fleksibilitas pada model data. Penghematan waktu dan kualitasnya sangat substansial. Alat CASE memiliki batasan, tidak semua konvesi model proses didiukung oleh semua produk CASE. Oleh karena itu, sebagian produk mungkin memaksa perusahaan untuk menyesuaikan simbol atau pendekatan metodologi pemodelan prosesnya sehingga dapat bekerja dala batasan alat CASE-nya.

Membuat Model Proses


Diagram Aliran Data Konteks Dalam kerangka kerja sistem informasi anda, lingkup didefinisikan sebagai fokus COMMUNICATION dari perspektif SYSTEM OWNER. Hal ini didokumentasikan dengan context data low diagram/diagram aliran data konteks. Kami menyarankan strategi untuk mendokumentasikan batasan dan lingkup sistem sebagai berikut : 1. Pikirkanlah sistem sebagai kontainer untuk dapat membedakan antara bagian dalam dan bagian luarnya. Abaikan sistem kerja kontainer tersebut. Hal ini sering disebut pemikiran kotak hitam 2. Tanyalah pengguna akhir sisteem anda, transaksi bisnis seperti apa yang harus direpons oleh sistem. Inilah net input untuk sistem. Untuk tiap net input, tentukan sumbernya. Sumber akan menjadi agen external dalam diagram aliran data konteks. 3. Tanyalah pengguna akhir anda, respons apa yang harus dihasilkan sistem. Inilah net output bagi sistem. Untuk ssetiap net output, tentukan tujuannya. Tujuan juga akan menjadi agen eksternal. Persyaratan untuk laporan dan pertanyaan dapat mengacaukan diagram. Pertimbangankan untuk menggabungkannya menjadi aliran data campuran.

4. Identifikasi tiap data store eksternal. Banyak sistem membutuhkan akses ke file atau database sistem lain. Sistem dapat menggunakan data dalam file atau database tersebut. 5. Gambar diagram konteks dari semua informasi sebelumnya. Jika anda mencoba memasukkan semua input dan output antara sistem dan bisnis dan dunia luar, maka diagram aliran data konteks biasa akan menunjukkan sekita 50 atau lebih aliran data. Diagram seperti ini hanya akan memiliki sedikit, jika ada, nilai komunikasi. Event-Response atau Use-Case List Beberapa input pada diagram konteks diasosiakan dengan kejadian, akan tetapi diagram konteks jarang menunjukkan semua kejadian itu. Pada dasarnya, ada tiga tipe kejadian: o External event (kejadian eksternal), dinamakan demikian karena diinisiasi oleh agen eksternal. Pada saat kejadian ini berlangsung, muncul aliran data input untuk sistem. Misalnya, kejadian CUSTOMER PLACES A NEW ORDER dikenali dalam bentuk aliran data input ORDER dari agen eksternalCustomer. o Temporal Event (kejadian sementara) memicu proses pada basis waktu, atau sesuatu yang terjadi. Pada saat kejadian ini berlangsung, terjadi input aliran kontrol. o State Event (kejadian keadaaan) memicu proses berdasarkan perubahan sistem dari suatu keadaan atau kondisi ke keadaan lain. Sebagaimana kejadian sementara, kejadian keadaan akan ditunjukkan sebagai input aliran kontrol. Sistem Informasi biasanya merespons terutama pada kejadia eksternal dan sementara. Kejadian keadaaan biasanya diasosiasikan dengan sistem real time, seperti levator atau robot. Satu pendekatan yang lebih popular dan berhasil untuk penelusuran dan pengidentifikasian kejadian dan respons adalah teknik yang disebut use case, yang dikembangkan oleh Dr. Ivar Jacobson. Teknik ini berakar pada analisis berorientasi objek, tetapi sangat mudah diadaptasikan dengan analisis terstruktur dan pendiagram aliran data. Analisis use-case adalah proses pengidentifikasian dan pemodelan kejadian bisnis, siapa yang menginisiasi dan bagaimana sistem meresponnya. Analisis use-case menyediakan metode untuk membagi seluruh lingkuo fungsionalitas sistem menjadi banyak pernyataan fungsionalitas sistem yang lebih kecil yang disebut usecase. Aktor/perilaku adalah segala sesuatu yang perlu berinteraksi dengan sistem untuk mempertukarkan informasi. Pelaku dapat berupa seorang pelanggan, pengguna, departemen, organisasi atau sistem yang lain.pelaku mengawali suatu proses. Pelaku tidak selalu merupakan individu tunggal atau jenis pekerjaan.

Diagram Kejadian Event diagram/ diagram kejadian adalah diagram konteks untuk kejadian tunggal. Diagram ini menunjukkan interaksi input, output, dan data store untuk kejadian tersebut. Dengan menggambarkan diagram kejadian untuk tiap proses, pengguna tidak akan kewalahan dengan ukuran keseluruhan sistem. Mereka akan menyelidiki tiap use-case sebagai diagram konteks tersendiri. Sebagian besar diagram kejadian terdiri dari proses tunggal prose yang sama yang disebutkan untuk menangani kejadian dalam diagram dekomposisi tersebut. Untuk tiap kejadian, gambarkan hal berikut : Input dan sumbernya. Sumber digambarkan sebagai agen eksternal. Struktur data untuk tiap input seharusnya dicatat dalam penyimpanan. Output dan tujuannya. Tujuan digambarkan sebagai agen eksternal. Struktur data untuk tiap output harus dicatat dalam penyimpanan. Data store, yang darinya record dibaca, yang harus ditambahkan pada diagram kejadian. Aliran data harus ditambahkan dan dinamai sesuai data yang dibaca oleh proses. Data store, yang didalamnya record dibuat, dihapus atau diperbarui, harus dimasukkan dalam diagram kejadia. Aliran data ke data store harus dinamai untuk merefleksikan sifat pembaruan tersebut.

Tiap proses kejadian harus diuraikan ke penyimpanan CASE dengan sifat sebagai berikut: o o o o o Kalimat kejadian- untuk perspektif bisnis Persyaratan trought volume input per beberapa periode waktu Persyaratan waktu respons seberapa cepat kejadian harus dikendalikan Persyaratan keamanan, pemeriksaan dan kontrol Persyaratan yang henda dicapai

Diagram Sistem Diagram sistem menyajikan konteks yang berarti bagi pengguna untuk mensahkan akurasi tiap kejadian yang harus direspons sistem. Tetapi kejadian tersebut tidak terisolasi. Kejadian tersebut secara kolektif mendefinisikan sistem dan subsistem. Oleh karena itu, sangatlah berguna untuk membuat satu atau lebih diagram sistem yang menunjukkan semua kejadian dalam sistem atau subsistem. Balancing/keseimbangan adalah mensinkronisasi diagram aliran data pada level detail yang berbeda untuk menjaga konsistensi dan kelengkapan model. Keseimbangan adalah teknik yang menjamin kualitas. Keseimbangan mengharuskan bahwa, jika anda mampu mengembangkan proses k DFD lain untuk menyatakan hal lebih detail, maka anda harus memasukkan aliran data dan data store yang sama pada diagram anak yang anda sertakan dalam proses awal diagram induk.

Diagram Primitif Beberapa proses kejadian pada diaggram sistem mungkin dikembangkan menjadi diagram aliran data primitif untuk menyatakan lebih banyak detail. Hal ini terutama benar untuk proses transaksi bisnis yang lebih kompleks.kejadian lain, seperti pembuatan laporam, cukup sederhana sehingga tidak memerlukan pengembangan lebih lanjut. Kombinasi digram konteks, diagram sistem, diagram kejadian dan diagram primitif melengkapi model proses kita. Semua ini adalah model proses. Model proses yang memadai dan lengkap dapat secara efektif mengkomunikasikan yang sering muncul dalam desain sistem, pemrograman, dan implementasinya.

Sinkronisasi model sistem


Sisnkronisasi model Hubungan antara model proses dan data hampir dapat diterima secara universal oleh semua metodologi utama. Singkatnya ada satu data store dalam model proses pada tiap entitas model data. Beberapa metodologi mengecualikan entittas asosiasi untuk persyaratan ini, tetapi kita percaya metodelogi ini lebih sederhana untuk mengaplikasikan aturan semua entitas pada model data. Matriks itu menyediakan pemeriksaan kualitas sederhana yang lebih mudah dibaca daripada model data atau proses. Tentu saja, eror dan penghapusan seharusnya dicatat dalam matriks dan dalam model data dan proses untuk menjamin sinkronisasi yang sesuai. Distribusi Proses Model proses mengilustrasikan pekerjaan esensial yang dilakukan oleh sistem secara keseluruhan. Akan tetapi, proses itu harus didisbusikan ke lokasi dimana pekerjaan tersebut dilakukan. Beberapa pekerjaan mungkin unik bagi satu lokasi dan pekerjaan lain dilakukan di beberapa lokasi. Sebelum mendesain sistem informasi, kita harus mengidentifikasi dan mendokumentasikan proses apa yang seharusnya dilakukan di tempat itu. Hal ini dapat dilakukan dengan matriks process to location association. Process to location association matrix/ matriks process to location association adalah tabel dengan barus mengindikasikan proses, kolom mengindikasikan lokasi, dan sel mendokumentasikan proses yang harus dilakukan di suatu lokasi. Beberapa metodologi dan alat CASE mendukung gambaran model proses yang tepat untuk suatu lokasi.