BAB IV PERANCANGAN SISTEM INFORMASI PDF

Sistem Informasi BAB IV PERANCANGAN SISTEM INFORMASI 4.1. Uraian Materi Perancangan sistem adalah proses mengembangkan model abstrak dari suatu sistem, dengan masing-masing model menyajikan pandangan atau perspektif yang berbeda dari sistem itu (Sommerville, 2011)....

Sistem Informasi BAB IV PERANCANGAN SISTEM INFORMASI 4.1. Uraian Materi Perancangan sistem adalah proses mengembangkan model abstrak dari suatu sistem, dengan masing-masing model menyajikan pandangan atau perspektif yang berbeda dari sistem itu (Sommerville, 2011). Pemodelan sistem umumnya berarti mewakili sistem menggunakan beberapa jenis notasi grafis, yang sekarang hampir selalu digunakan adalah notasi dalam Unified Modeling Language (UML). Namun, juga dimungkinkan untuk mengembangkan model formal lainnya dari suatu sistem, biasanya sebagai spesifikasi sistem yang terperinci. Model digunakan selama proses requirements engineering untuk membantu memperoleh persyaratan untuk suatu sistem, selama proses desain untuk menggambarkan sistem kepada developer yang mengimplementasikan sistem, dan setelah implementasi untuk mendokumentasikan struktur dan operasi sistem. Pemodelan dapat dikembangkan dari sistem yang ada dan sistem yang akan dikembangkan. a. Pemodelan Proses Pemodelan proses merupakan kegiatan membuat dokumentasi yang menjelaskan suatu proses sistem informasi yang kompleks ke dalam bagan, diagram, atau bentuk lainnya dengan tujuan agar lebih mudah dipahami. Pemodelan proses dapat dikembangkan dengan model yang berbeda untuk mewakili sistem dari perspektif yang berbeda. Sebagai contoh: Perspektif eksternal, dimana proses dimodelkan dari konteks atau lingkungan sistem. Perspektif interaksi, dimana proses dimodelkan dari interaksi antara sistem dan lingkungannya atau antara komponen sistem. Perspektif struktural, dimana proses dimodelkan dari organisasi sistem atau struktur data yang diproses oleh sistem. 47 Sistem Informasi Perspektif perilaku, dimana proses dimodelkan dari perilaku dinamis sistem dan bagaimana responsnya terhadap suatu. Pemodelan proses sistem informasi dapat mengadopsi pendekatan berorientasi pada prosedur, berorientasi pada objek, atau berorientasi pada layanan. 1. Pemodelan Berorientasi Prosedur (Data Flow Diagram/DFD) a) Pengertian DFD DFD adalah model dari sebuah sistem untuk menggambarkan pembagian sistem ke modul yang lebih kecil. Salah satu keuntungan menggunakan DFD adalah memudahkan pengguna yang kurang terbiasa dengan komputer untuk mengerti sistem yang akan dikerjakan. DFD dapat dibagi menjadi tiga bagian. 1) Diagram Konteks Diagram konteks adalah diagram yang terdiri dari suatu proses dan menggambarkan ruang lingkup suatu sistem. Diagram konteks merupakan level tertinggi dari DFD yang menggambarkan keseluruhan sistem. Sistem dibatasi oleh boundary. Dalam diagram konteks hanya boleh ada satu proses dan tidak boleh ada data store. 2) Diagram Zero (Overview Diagram) Diagram zero adalah diagram yang menggambarkan proses dari DFD. Diagram ini memberikan pandangan menyeluruh tentang sistem yang akan ditangani, menunjukkan fungsi-fungsi utama atau proses yang ada, aliran data dan entitas eksternal. Pada level ini sudah dimungkinkan adanya data store. Untuk proses yang tidak dirinci lagi pada level selanjutnya, symbol ‘*’ atau ‘P’ (functional primitive) dapat digunakan pada akhir nomor proses. Keseimbangan (balancing) input dan output antara diagram zero dengan diagram konteks harus dijaga. 48 Sistem Informasi 3) Diagram Rinci Diagram rinci adalah diagram yang menguraikan proses apa yang ada dalam diagram zero atau diagram yang berada di level atasnya. b) Balancing dalam DFD Aliran data yang masuk dan keluar dari suatu proses harus sama dengan aliran data yang masuk atau keluar dari rincian proses pada level di bawahnya. Hal–hal yang perlu diperhatikan adalah sebagai berikut: Harus ada keseimbangan input dan output antara satu level dan berikutnya Keseimbangan antara level 0 dan 1 dilihat pada input/output dari aliran data ke atau dari terminal pada level 0 sedangkan keseimbangan antara level 1 dan 2 dilihat pada input/output dari aliran data ke/dari proses yang bersangkutan Nama aliran data, data store, dan terminal pada setiap level harus sama jika objeknya sama c) Spesifikasi Proses Setiap proses di DFD harus memiliki spesifikasi proses. Tanpa ini kita tidak akan mengetahui apa yang terjadi di proses tersebut. Ada banyak cara untuk menggambarkan suatu proses. Hal ini tergantung dari level mana proses tersebut berada. Metode penggambaran proses di top level berbeda dengan yang berada di level paling bawah. Ada beberapa istilah yang digunakan untuk spesifikasi suatu proses: Mini_spec (spesifikasi singkat) Job_spec (spesifikasi tugas) Process description (deskripsi proses), dan lain-lain. Spesifikasi proses untuk level atas dapat menggunakan kalimat deskriptif namun pada level yang lebih rinci, yakni pada proses yang paling bawah (functional primitive) memerlukan spesifikasi yang lebih 49 Sistem Informasi terstruktur dengan menggunakan kaidah-kaidah tertentu. Spesifikasi proses akan menjadi pedoman bagi programmer dalam membuat program (coding). Metode yang digunakan untuk spesifikasi proses dapat berupa: Uraian proses dalam bentuk cerita Bahasa Indonesia/Inggris yang terstruktur Decision table Decision tree d) Elemen Dasar DFD 1) Kesatuan Luar (External Entity) Sesuatu yang berada di luar sistem, tetapi ia memberikan data ke atau dari dalam sistem disimbolkan dengan notasi kotak. Eksternal entity bukan termasuk bagian dari sistem. Bila sistem informasi dirancang untuk satu bagian maka bagian lainnya yang masih terkait menjadi external entity. 2) Arus Data (Data Flow) Arus data merupakan tempat mengalirnya informasi dan digambarkan dengan garis yang menghubungkan komponen dari sistem. Arus data ditunjukkan dengan arah panah dan garis dan diberi nama atas arus data yang mengalir. Arus data ini mengalir di antara proses, data store, dan menunjukkan arus data dari data yang berupa masukan untuk sistem atau hasil proses sistem. 3) Proses Proses adalah apa yang dikerjakan oleh sistem. Proses dapat mengolah data atau aliran data masuk menjadi aliran data keluar. Proses berfungsi mentransformasikan satu atau beberapa data output sesuai dengan spesifikasi yang diinginkan. Setiap proses memiliki satu atau beberapa masukan serta menghasilkan satu atau beberapa data output. Proses tersebut sering pula disebut bubble. 50 Sistem Informasi 4) Simpanan Data (Data Store) Simpanan data adalah tempat penyimpanan data yang ada di dalam sistem. Data store dapat disimbolkan dengan sepasang dua garis dengan salah satu sisi samping terbuka. Proses dapat mengambil data dari atau memberikan data ke database. 5) Kamus Data (Data Dictionary) Kamus data berfungsi membantu pengguna sistem untuk mengartikan aplikasi secara detail dan mengorganisasi semua elemen data yang digunakan dalam sistem secara akurat sehingga pemakai dan analis sistem mempunyai dasar pengertian yang sama tentang input, output, penyimpanan, dan proses. Kamus data sering disebut juga katalog fakta tentang data dan kebutuhan-kebutuhan informasi dari suatu sistem informasi. Dengan menggunakan kamus data seorang analis dapat mendefinisikan data yang mengalir di sistem, yakni tentang data yang masuk ke sistem dan tentang informasi yang dibutuhkan oleh pengguna sistem. Pada tahap perancangan sistem, kamus data dibuat untuk merancang input, laporan-laporan, dan basis data. Kamus data dibuat berdasarkan arus data yang ada di DFD. Arus datanya bersifat global dan hanya ditunjukkan nama arus datanya saja. Notasi yang digunakan pada DFD antara lain sebagai berikut. 51 Sistem Informasi Gambar 4.1. Notasi DFD e) Contoh Hasil Pemodelan DFD 52 Sistem Informasi Gambar 4.2. Contoh Diagram Konteks Gambar 4.3. Contoh Diagram Zero (Overview Diagram) Gambar 4.4. Contoh Diagram Rinci (DFD Level n) 2. Pemodelan Berorientasi Objek (Unified Modeling Language/UML) UML merupakan sekumpulan alat yang digunakan untuk melakukan abstraksi terhadap sebuah sistem atau perangkat lunak berbasis objek. UML juga menjadi salah satu cara untuk mempermudah pengembangan aplikasi yang berkelanjutan. Aplikasi atau sistem yang tidak terdokumentasi biasanya dapat menghambat pengembangan karena developer harus melakukan penelusuran dan mempelajari kode program. UML juga dapat menjadi alat bantu untuk mentransfer ilmu tentang sistem atau aplikasi yang akan 53 Sistem Informasi dikembangkan dari satu developer ke developer lainnya. Tidak hanya antar developer, stakeholder dan siapapun dapat memahami sebuah sistem dengan adanya UML. UML adalah bahasa untuk membuat spesifikasi, memvisualisasi, membangun, dan mendokumentasikan artifacts (bagian dari informasi yang dihasilkan oleh proses pembuatan perangkat lunak, artifact tersebut dapat berupa model, deskripsi, atau perangkat lunak) dari sistem perangkat lunak, seperti pada pemodelan bisnis dan sistem non perangkat lunak lainnya. Selain itu UML adalah bahasa pemodelan yang menggunakan konsep berorientasi objek. UML dibuat oleh Grady Booch, James Rumbaugh, dan Ivar Jacobson di bawah bendera Rational Software Corps. UML menyediakan notasi-notasi yang membantu memodelkan sistem dari berbagai perspektif. UML tidak hanya digunakan dalam pemodelan perangkat lunak, namun hampir dalam semua bidang yang membutuhkan pemodelan. Beberapa jenis diagram yang digunakan dalam UML antara lain: a) Use Case Diagram Diagram use case menggambarkan sejumlah aktor eksternal dan hubungannya ke use case yang diberikan oleh sistem. Use case adalah deskripsi fungsi yang disediakan oleh sistem dalam bentuk teks sebagai dokumentasi dari simbol use case namun dapat juga dilakukan dalam activity diagram. Use case digambarkan hanya yang dilihat dari luar oleh aktor (keadaan lingkungan sistem yang dilihat user) dan bukan bagaimana fungsi yang ada di dalam sistem. Notasi yang digunakan pada diagram use case adalah sebagai berikut: 54 Sistem Informasi 55 Sistem Informasi Gambar 4.5. Notasi Use Case Diagram Contoh Use Case Diagram: Gambar 4.6. Contoh Use Case Diagram b) Class Diagram Class Diagram menggambarkan struktur statis class di dalam sistem. Class merepresentasikan sesuatu yang ditangani oleh sistem. Class dapat berhubungan dengan yang lain melalui berbagai cara: associated (terhubung satu sama lain), dependent (satu class tergantung/menggunakan class yang lain), specialized (satu class merupakan spesialisasi dari class lainnya), atau package (grup bersama sebagai satu unit). Sebuah sistem biasanya mempunyai beberapa class 56 Sistem Informasi diagram. Notasi yang digunakan pada class diagram adalah sebagai berikut: Gambar 4.7. Notasi Class Diagram Struktur pada notasi class adalah: 57 Sistem Informasi Gambar 4.8. Struktur Class pada Notasi Class Diagram Contoh class diagram adalah sebagai berikut: Gambar 4.9. Contoh Class Diagram c) State Diagram State Diagram menggambarkan semua state (kondisi) yang dimiliki oleh suatu objek dari suatu class dan keadaan yang menyebabkan state berubah. State dapat berupa objek lain yang mengirim pesan. Class State tidak digambarkan untuk semua class, hanya yang mempunyai sejumlah state yang terdefinisi dengan baik dan kondisi class berubah oleh state yang berbeda. Adapun notasi yang digunakan pada state diagram adalah: 58 Sistem Informasi Gambar 4.10. Notasi State Diagram Contoh state diagram: Gambar 4.11. Contoh State Diagram d) Sequence Diagram Sequence Diagram menggambarkan kolaborasi dinamis antara sejumlah objek. Kegunaannya untuk menunjukkan rangkaian pesan yang dikirim antar objek dan juga interaksi antar objek, sesuatu yang terjadi pada titik tertentu dalam eksekusi sistem. Contoh notasi sequence diagram adalah sebagai berikut: 59 Sistem Informasi Gambar 4.12. Notasi Sequence Diagram Contoh sequence diagram: Gambar 4.13. Contoh Sequence Diagram e) Communication Diagram Communication Diagram menggambarkan kolaborasi dinamis seperti sequence diagram. Dalam menunjukkan pertukaran pesan, collaboration diagram menggambarkan objek dan hubungannya (mengacu ke konteks). Jika penekanannya pada waktu atau urutan maka gunakan 60 Sistem Informasi sequence diagrams, tapi jika penekanannya pada konteks gunakan collaboration diagram. Notasi pada collaboration diagram antara lain sebagai berikut: Simbol Keterangan Actor Object instance Objek yang dibuat, melakukan tindakan, dan/atau dimusnahkan selama lifeline Interaksi link Merupakan indikasi bahwa objek kejadian dan berkolaborasi aktor dan pertukaran pesan. Sinkronis pesan Seketika sebuah komunikasi antara objek-objek yang menyampaikan informasi, dengan harapan bahwa tindakan akan dimulai sebagai hasil. Berisi catatan, komentar, atau informasi tertulis 61 Sistem Informasi Gambar 4.14. Notasi Communication Diagram Contoh communication diagram adalah sebagai berikut: Gambar 4.15. Contoh Communication Diagram f) Activity Diagram Activity Diagram menggambarkan rangkaian aliran dari aktivitas yang digunakan untuk mendeskripsikan aktivitas yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk aktivitas lainnya seperti use case atau interaksi. Notasi pada activity diagram adalah: Simbol Keterangan Titik awal atau permulaan Titik akhir atau akhir dari aktivitas Aktivitas yang dilakukan oleh aktor Decision atau pilihan untuk mengambil keputusan Arah tanda panah alur proses 62 Sistem Informasi Gambar 4.16. Notasi Activity Diagram Contoh activity diagram: Gambar 4.17. Contoh Activity Diagram g) Component Diagram Component Diagram menggambarkan struktur fisik kode dari komponen. Komponen dapat berupa source code, komponen biner, atau executable component. Sebuah komponen berisi informasi tentang logic class atau class yang diimplementasikan sehingga membuat pemetaan dari logical view ke component view. Notasi yang digunakan pada component diagram adalah sebagai berikut: 63 Sistem Informasi Gambar 4.18. Notasi Component Diagram Contoh component diagram: Gambar 4.19. Contoh Component Diagram h) Deployment Diagram Deployment Diagram menggambarkan arsitektur fisik dari perangkat keras dan perangkat lunak sistem, menunjukkan hubungan komputer dengan perangkat (nodes) satu sama lain dan jenis hubungannya. Di dalam nodes, executable component dan object dialokasikan untuk memperlihatkan unit perangkat lunak yang dieksekusi 64 Sistem Informasi oleh node tertentu. Notasi pada deployment diagram adalah sebagai berikut: Gambar 4.20. Notasi Deployment Diagram 65 Sistem Informasi Contoh deployment diagram: Gambar 4.21. Contoh Deployment Diagram 3. Pemodelan Berorientasi Layanan (Service oriented architecture Modeling Language/ SoaML) Service Oriented Architecture (SOA) adalah paradigma arsitektur untuk mendefinisikan bagaimana orang, organisasi, dan sistem menyediakan dan menggunakan layanan untuk mencapai hasil. SoaML menyediakan cara standar untuk merancang dan memodelkan solusi SOA menggunakan UML. SoaML memungkinkan arsitektur layanan berorientasi bisnis dan berorientasi sistem untuk saling mendukung dan berkolaborasi dalam misi organisasi. SoaML mengintegrasikan kemampuan pemodelan untuk mendukung penggunaan SOA pada tingkat yang berbeda dan dengan metodologi yang berbeda. Khususnya dukungan untuk pendekatan "berbasis kontrak" dan "berbasis antarmuka" yang secara umum masing-masing mengikuti elemen "Service Contract" dan "Service Interface" dari profil SoaML. Pendekatan kontrak layanan mendefinisikan kontrak yang menentukan bagaimana penyedia dan konsumen bekerja sama untuk mencapai tujuan melalui penggunaan layanan. Kontrak layanan merupakan kesepakatan antara pihak- 66 Sistem Informasi pihak tentang bagaimana layanan akan disediakan dan dikonsumsi. Kesepakatan tersebut termasuk antarmuka, koreografi, syarat, dan ketentuan lainnya. Pendekatan berbasis antarmuka melibatkan penggunaan antarmuka sederhana dan antarmuka layanan. Antarmuka yang sederhana berfokus terutama pada penyampaian layanan satu arah yang tidak memerlukan protokol antar pihak. Antarmuka layanan memungkinkan untuk layanan dua arah. Penyedia (provider) dan konsumen (consumer) bekerja sama untuk menyelesaikan suatu layanan. Beberapa jenis diagram yang digunakan dalam UML antara lain: a) Service Interface Diagram Diagram antarmuka layanan adalah jenis diagram SoaML yang dikhususkan untuk definisi dan spesifikasi antarmuka sederhana dan antarmuka layanan. Notasi pada diagram antarmuka layanan adalah sebagai berikut: 67 Sistem Informasi 68 Sistem Informasi Gambar 4.22. Notasi Service Interface Diagram Contoh service interface diagram: Gambar 4.23. Contoh Service Interface Diagram b) Service Participant Diagram Service participant diagram berfokus pada orang, organisasi, sistem atau siapa saja yang mengambil bagian dalam arsitektur layanan. Pemodel menggunakan service participant diagram untuk mewakili participant ini serta antarmuka yang mereka butuhkan atau disediakan dalam menyelesaikan layanan. Perhatikan bahwa cara participant berinteraksi tidak dimodelkan dalam service participant diagram. Notasi pada service participant diagram adalah sebagai berikut: 69 Sistem Informasi 70 Sistem Informasi Gambar 4.24. Notasi Service Participant Diagram Contoh service interface diagram: Gambar 4.25. Contoh Service Participant Diagram c) Service Architecture Diagram 71 Sistem Informasi SoaML memungkinkan pemodel untuk membangun model arsitektur layanan yang menyatukan spesifikasi layanan dan peserta dan menunjukkan bagaimana orang, tim, dan organisasi bekerja bersama untuk mencapai tujuan. Notasi pada service architecture diagram adalah sebagai berikut: Gambar 4.26. Notasi Service Architecture Diagram Contoh service architecture diagram: 72 Sistem Informasi Gambar 4.27. Contoh Service Architecture Diagram d) Service Contract Diagram Diagram kontrak layanan dirancang untuk spesifikasi kontrak layanan. Pemodel biasanya menggabungkan penggunaan sequence diagram dan activity diagram dalam mewakili koreografi kontrak layanan. Notasi pada service contract diagram adalah sebagai berikut: 73 Sistem Informasi Gambar 4.28. Notasi Service Contract Diagram Contoh service contract diagram: 74 Sistem Informasi Gambar 4.29. Contoh Service Contract Diagram e) Service Categorization Diagram Kategorisasi diperlukan untuk mengatur konten model agar elemen model dapat digunakan untuk berbagai tujuan dan dilihat dari perspektif yang berbeda. Diagram kategorisasi layanan memungkinkan kategorisasi elemen SoaML dengan katalog, kategori, dan nilai kategori. Notasi pada service categorization diagram adalah sebagai berikut: Gambar 4.30. Notasi Service Categorization Diagram Contoh service categorization diagram: Gambar 4.31. Contoh Service Categorization Diagram 75 Sistem Informasi b. Perancangan Antarmuka Pengguna Desain antarmuka pengguna adalah bagian penting dari proses desain perangkat lunak. Desain antarmuka pengguna harus memastikan bahwa interaksi antara manusia dan mesin menyediakan operasi dan kontrol mesin yang efektif. Agar perangkat lunak mencapai potensi penuhnya, antarmuka pengguna harus dirancang agar sesuai dengan keterampilan, pengalaman, dan harapan pengguna (IEEE Computer Society, 2014). Perancangan antarmuka pengguna secara umum dibagi dua yaitu rancangan masukan dan rancangan keluaran. 1. Rancangan Masukan (Input) Input merupakan awal dimulainya proses pengolahan data. Bahan mentah dari informasi merupakan data yang dihasilkan dari transaksi tersebut akan menjadi input bagi sistem informasi. Hasil yang diperoleh tentunya tidak akan menyimpang jauh dari input tersebut. Kualitas input sangat menentukan kualitas output. Kalau yang masuk adalah sampah, maka yang keluarpun nantinya adalah sampah. Supaya bukan sampah yang dihasilkan, maka data input yang melalui formulir harus dirancang sedemikian rupa sehingga sampah tersebut bisa dihindari. Pedoman perancangan formulir input adalah sebagai berikut: Mempertimbangkan media pemasukan Layout formulir harus sesuai dengan yang diinginkan Formulir harus akurat Tampilan formulir harus atraktif Mudah diisi: ✓ Alur pengisian formulir teratur, dari kiri ke kanan atau dari atas ke bawah ✓ Komponen formulir jelas: judul, identifikasi dan akses, instruksi, isian, tanda tangan dan pengesahan. ✓ Menggunakan caption 76 Sistem Informasi Layar masukan bisa dirancang berdasarkan dokumen formulir. Dalam hal ini layar masukan dirancang semirip mungkin dengan dokumen formulir yang sudah ada. Jika tampilan pertanyaan pada formulir terlalu banyak, kita bisa menggunakan pendekatan parent-child (header-detail). Tampilan yang seimbang akan mudah dibaca. Ada beberapa cara yang dapat digunakan untuk mengurangi jumlah masukan, cara yang dapat dilakukan yaitu menggunakan kode, data yang relatif konstan disimpan di file induk, jam dan tanggal dapat diambil dari sistem, rutin perhitungan dilakukan oleh sistem. Empat garis pedoman untuk merancang formulir: a) Membuat formulir mudah diisi, yaitu dengan memperhatikan aliran formulir, pengelompokan bagian sebuah formulir, pembuatan judul. b) Memastikan bahwa formulir akan memenuhi tujuan yang telah dibuat. c) Membuat formulir yang memastikan penyelesaian tepat. d) Buatlah formulir yang menarik. Contoh rancangan masukan: 77 Sistem Informasi Gambar 4.32. Contoh Rancangan Masukan 2. Rancangan Keluaran (Output) Perancangan output atau keluaran merupakan hal yang tidak dapat diabaikan, karena laporan atau keluaran yang dihasilkan harus memudahkan bagi setiap unsur manusia yang membutuhkannya. Tujuan yang harus dicapai analisis sistem saat merancang output: Merancang output untuk tujuan tertentu Membuat output bermanfaat bagi para pengguna Menampilkan jumlah output yang tepat Menyediakan distribusi output yang tepat Menyediakan output yang tepat waktu Memilih metode output yang paling efektif. Berdasarkan tujuannya, output dapat dibedakan menjadi 2 tipe: a) Eksternal External Output bersifat keluar organisasi. Output ini ditujukan kepada konsumen, pemasok, mitra bisnis dan badan pemerintahan. Output external menyimpulkan dan melaporkan transaksi bisnis. Contoh dari external output ini antara lain faktur, nota pembelian barang, jadwal kursus, tiket pesawat, tagihan telepon dan lain sebagainya. Tujuan output untuk informasi di luar organisasi pemakai. Contoh: faktur, check, tanda terima pembayaran, dan sebagainya. b) Internal Internal output digunakan untuk para pemilik dan pengguna sistem dalam sebuah perusahaan. Internal output mendukung operasi bisnis sehari‐hari atau pengawasan manajemen dan pengambilan keputusan. 78 Sistem Informasi Contoh: laporan-laporan terinci, laporan-laporan ringkasan, dan sebagainya. Tiga jenis internal output adalah sebagai berikut: 1) Detailed Report, menyajikan informasi dengan sedikit atau tanpa dilakukan penyaringan atau pembatasan. Contoh: Daftar seluruh tagihan pelanggan. 2) Summary Report, berisi informasi dari manajer yang tidak perlu diperlihatkan keseluruhan laporan secara detail. Contoh: Laporan ringkasan total penjualan dalam hitungan bulanan dan grafik penjualan per‐tahun. 3) Exception Report, menyaring data sebelum ditunjukkan kepada manajer sebagai sebuah informasi. Contoh: Laporan persediaan barang yang hampir habis. Macam-Macam Bentuk Laporan a) Laporan Berbentuk Tabel Notice Report Notice report merupakan bentuk laporan yang memerlukan perhatian khusus. Laporan ini harus dibuat sesederhana mungkin, tetapi jelas, karena dimaksudkan agar permasalahan-permasalahan yang terjadi tampak dengan jelas, sehingga dapat langsung ditangani. Equipoised Report Isi dari equipoised report adalah hal-hal yang bertentangan. Laporan ini biasanya digunakan untuk maksud perencanaan. Dengan disajikan informasi yang berisi hal-hal bertentangan, maka dapat dijadikan sebagai dasar di dalam pengambilan keputusan. Variance Report 79 Sistem Informasi Laporan ini menunjukkan selisih (variance) antara standar yang sudah ditetapkan dengan hasil kenyataannya atau sesungguhnya. Comparative Report Isi laporan ini adalah membandingkan antara satu hal dengan hal yang lainnya. Misalnya pada laporan rugi/laba atau neraca dapat dibandingkan antara nilai-nilai elemen tahun berjalan dengan tahun- tahun sebelumnya. b) Laporan Berbentuk Grafik Bagan Garis Pada bagan garis (line chart), variasi dari data ditunjukkan dengan suatu garis atau kurva. Bagan garis mempunyai beberapa kebaikan, yaitu: ✓ Dapat menunjukkan hubungan antara nilai dengan baik. ✓ Dapat menunjukkan beberapa titik. ✓ Tingkat ketepatannya dapat diatur sesuai dengan skalanya. ✓ Mudah dimengerti. Disamping kebaikannya, bagan garis mempunyai beberapa kelemahan, yaitu:  Bila terlalu banyak garis atau kurva (sekitar lebih dari 4 buah garis atau kurva), maka akan tampak ruwet.  Hanya terbatas pada 2 dimensi.  Spasi dapat menyesatkan. Bagan Batang Nilai-nilai data dalam bagan batang (bar chart) digambarkan dalam bentuk batang-batang vertikal ataupun batang-batang horisontal. Kebaikan dari bagan batang adalah sebagai berikut: ✓ Baik untuk perbandingan. ✓ Dapat menunjukkan nilai dengan tepat. ✓ Mudah dimengerti. 80 Sistem Informasi Disamping kebaikannya, bagan batang mempunyai beberapa kelemahan, yaitu:  Terbatas hanya pada satu titik saja.  Spasi dapat menyesatkan. Bagan Pai Bagan pai (pie chart) merupakan bagan yang berbentuk lingkaran menyerupai kue pai (pie). Tiap-tiap potong dari pie dapat menunjukkan bagian dari data. Kebaikan dari bagan pai adalah sebagai berikut ini. ✓ Baik untuk perbandingan sebagian dengan keseluruhannya. ✓ Mudah dimengerti. Disamping kebaikannya, bagan pai mempunyai beberapa kelemahan, yaitu:  Penggunaannya terbatas  Ketepatannya kurang  Tidak dapat menunjukkan hubungan beberapa titik c) Laporan Untuk Level Manajemen yang Berbeda Laporan Berhirarki Laporan yang dibuat untuk masing-masing level manajemen untuk menerima informasi sesuai dengan permintaan khusus, tanpa memberikan detail yang tidak relevan. Para eksekutif akan melihat trend, kecenderungan, dan pola-pola dari laporan tersebut. Mereka ingin mengetahui apakah masing-masing bagian sudah mencapai tujuan. Ada dua macam laporan berhirarki: 1) Filter Report: laporan yang dirancang untuk memfilter elemen- elemen data yang dipilih dari database, sehingga pengambil keputusan akan memperoleh laporan yang sesuai dengan kebutuhannya. Biasanya data difilter pada level atas. 81 Sistem Informasi 2) Responsibility Report: laporan yang dibuat untuk memutuskan siapa yang bertanggung jawab terhadap suatu laporan, apakah CEO, manajer pemasaran, atau spesialis media, dll. Laporan Yang Membandingkan Data Laporan ini dibuat untuk membantu manajer dan user lain dalam memilih dua atau lebih item untuk menyusun kesamaan atau ketidaksamaan (perbedaan). Dengan perbandingan ini, user berada pada posisi terbaik untuk membuat keputusan yang rasional. Ada 3 macam laporan yang membandingkan data: 1) Horizontal Report: neraca dan laporan rugi laba menunjukkan laporan keuangan periodik yang meringkas ribuan transaksi dan elemen data menjadi output untuk beragam user. User akan memperoleh gambaran yang jelas dengan melihat perbandingan pada laporan. Hal ini dapat dilakukan dengan merancang horizontal report. Jumlah setiap item dibandingkan dengan item yang berhubungan pada satu atau lebih laporan sebelumnya. 2) Vertical Report: laporan yang membandingkan suatu bagian komponen dengan totalnya. 3) Counterbalance Report: setiap situasi dibandingkan dalam laporan. Contohnya, skenario yang terburuk, layak, dan terbaik dapat membantu para perencana menilai proyek-proyek yang berisiko, juga informasi berharga bagi para eksekutif dalam pengambilan keputusan. Laporan Untuk Monitor Variansi Data 1) Variance Report: laporan yang dibuat untuk membandingkan standar dengan hasil aktual yang diperoleh. Biasanya laporan ini dibuat sesuai dengan waktu atau selesainya suatu proses. 82 Sistem Informasi 2) Exception Report: laporan ini seperti variance report, tetapi beberapa kuota atau batasan dibuat untuk suatu proses atau aktivitas. Laporan ini dibuat hanya ketika beberapa proses atau aktivitas tidak sesuai dengan batasan atau kuota. Contoh: Daftar pelanggan yang sering menunggak pembayaran. Contoh rancangan keluaran: Gambar 4.33. Contoh Rancangan Keluaran c. Perancangan Arsitektur Desain arsitektur berkaitan dengan pemahaman bagaimana sistem harus diatur dan merancang struktur keseluruhan sistem itu. Ini adalah hubungan penting antara desain dan rekayasa persyaratan, karena mengidentifikasi komponen struktural utama dalam suatu sistem dan hubungan di antara mereka. Output dari proses desain arsitektur adalah 83 Sistem Informasi model arsitektur yang menggambarkan bagaimana sistem diatur sebagai satu set komponen yang berkomunikasi (Sommerville, 2011). Desain arsitektur perangkat lunak dibagi dua yaitu arsitektur dalam skala kecil dan arsitektur dalam skala besar: Arsitektur dalam skala kecil berkaitan dengan arsitektur program individu. Pada tingkat ini, kita berfokus dengan cara program individu didekomposisi menjadi komponen-komponen. Subbab ini sebagian besar berkaitan dengan arsitektur program. Arsitektur secara luas berkaitan dengan arsitektur sistem organisasi yang kompleks yang mencakup sistem lain, program, dan komponen program. Sistem organisasi ini didistribusikan melalui komputer yang berbeda, yang mungkin dimiliki dan dikelola oleh organisasi yang berbeda. 1. Keputusan Desain Arsitektur Desain arsitektur adalah proses kreatif di mana Anda merancang organisasi sistem yang akan memenuhi persyaratan fungsional dan non- fungsional suatu sistem. Karena merupakan proses kreatif, aktivitas dalam proses bergantung pada jenis sistem yang dikembangkan, latar belakang dan pengalaman arsitek sistem, dan persyaratan khusus untuk sistem. Oleh karena itu, berguna untuk memikirkan desain arsitektur sebagai serangkaian keputusan yang harus dibuat daripada urutan kegiatan. Selama proses desain arsitektur, arsitek sistem harus membuat sejumlah keputusan struktural yang sangat mempengaruhi sistem dan proses pengembangannya. Berdasarkan pengetahuan dan pengalaman mereka, mereka harus mempertimbangkan pertanyaan mendasar berikut tentang sistem: a) Apakah ada arsitektur aplikasi generik yang dapat bertindak sebagai template untuk sistem yang sedang dirancang? b) Bagaimana sistem akan didistribusikan ke sejumlah inti atau prosesor? 84 Sistem Informasi c) Pola atau gaya arsitektur apa yang mungkin digunakan? d) Apa pendekatan mendasar yang digunakan untuk menyusun sistem? e) Bagaimana komponen struktural dalam sistem didekomposisi menjadi subkomponen? f) Strategi apa yang akan digunakan untuk mengendalikan operasi komponen-komponen dalam sistem? g) Organisasi arsitektur apa yang terbaik untuk memenuhi kebutuhan non-fungsional dari sistem? h) Bagaimana desain arsitektur dievaluasi? i) Bagaimana seharusnya arsitektur sistem didokumentasikan? Untuk sistem dan sistem tertanam (embedded system) yang dirancang untuk komputer pribadi, biasanya hanya ada satu prosesor dan kita tidak perlu mendesain arsitektur terdistribusi untuk sistem tersebut. Namun, sebagian besar sistem sekarang adalah sistem terdistribusi di mana perangkat lunak sistem didistribusikan di banyak komputer yang berbeda. Pilihan arsitektur distribusi adalah keputusan kunci yang mempengaruhi kinerja dan keandalan sistem. 2. Pandangan Arsitektur Di bagian ini, dibahas mengenai pandangan atau perspektif apa yang berguna saat merancang dan mendokumentasikan arsitektur sistem dan notasi apa yang harus digunakan untuk menggambarkan model arsitektur. Ada empat pandangan yang dapat digunakan untuk merancang arsitektur, yaitu: a) Pandangan logis, yang menunjukkan abstraksi kunci dalam sistem sebagai objek atau kelas objek. Seharusnya dimungkinkan untuk menghubungkan persyaratan sistem dengan entitas dalam tampilan logis ini. b) Pandangan proses, yang menunjukkan bagaimana, pada saat run-time, sistem terdiri dari proses-proses yang berinteraksi. Pandangan ini 85 Sistem Informasi berguna untuk membuat penilaian tentang karakteristik sistem non- fungsional seperti kinerja dan ketersediaan. c) Pandangan pengembangan, yang menunjukkan bagaimana perangkat lunak didekomposisi untuk pengembangan, yaitu, menunjukkan perincian perangkat lunak menjadi komponen-komponen yang diimplementasikan oleh satu pengembang atau tim pengembangan. Tampilan ini berguna untuk manajer dan pemrogram perangkat lunak. d) Pandangan fisik, yang menunjukkan perangkat keras sistem dan bagaimana komponen perangkat lunak didistribusikan ke seluruh prosesor dalam sistem. Pandangan ini berguna untuk system engineer yang merencanakan penyebaran sistem. Ada perbedaan pandangan tentang apakah arsitek perangkat lunak harus menggunakan UML untuk deskripsi arsitektur. Sebuah survei pada tahun 2006 menunjukkan bahwa, ketika UML digunakan, sebagian besar diterapkan secara longgar dan informal. Oleh karena itu, sejumlah peneliti telah mengusulkan penggunaan bahasa deskripsi arsitektur (Architectural Description Languages/ADL) yang lebih khusus untuk menggambarkan arsitektur sistem. Elemen dasar ADL adalah komponen dan konektor, dan mereka termasuk aturan dan pedoman untuk arsitektur yang terbentuk dengan baik. Namun, karena sifatnya yang khusus, spesialis domain dan aplikasi merasa sulit untuk memahami dan menggunakan ADL. Hal ini membuat sulit untuk menilai kegunaannya untuk rekayasa perangkat lunak praktis. Namun, pada penerapannya model dan notasi informal, seperti UML, akan tetap menjadi cara yang paling umum digunakan untuk mendokumentasikan arsitektur sistem. 3. Pola Arsitektur Pada bagian ini, diperkenalkan pola arsitektur dan dijelaskan secara singkat pilihan pola arsitektur yang umum digunakan dalam berbagai jenis sistem. Pola arsitektur dapat dianggap sebagai deskripsi abstrak bergaya praktik yang baik, yang telah dicoba dan diuji dalam sistem dan lingkungan 86 Sistem Informasi yang berbeda. Jadi, pola arsitektur harus menggambarkan organisasi sistem yang telah berhasil dalam sistem sebelumnya. Itu harus mencakup informasi tentang kondisi yang cocok untuk menggunakan pola itu, serta kekuatan dan kelemahan pola itu. Tabel 4.1. Pola Model-View-Controller (MVC) Nama MVC (Model-View-Controller) Deskripsi Memisahkan presentasi dan interaksi dari data sistem. Sistem ini disusun menjadi tiga komponen logis yang berinteraksi satu sama lain. Komponen Model mengelola data sistem dan operasi terkait pada data tersebut. Komponen View mendefinisikan dan mengelola bagaimana data disajikan kepada pengguna. Komponen Controller mengelola interaksi pengguna (misalnya, penekanan tombol, klik mouse, dll.) dan meneruskan interaksi ini ke View dan Model. Lihat Gambar 4.34. Contoh Gambar 4.35 menunjukkan arsitektur sistem aplikasi berbasis web yang diatur menggunakan pola MVC. Kapan Digunakan ketika ada beberapa cara untuk melihat dan Digunakan berinteraksi dengan data. Juga digunakan ketika persyaratan masa depan untuk interaksi dan penyajian data tidak diketahui. Kekuatan Mengizinkan data berubah secara independen dari representasinya dan sebaliknya. Mendukung penyajian data yang sama dengan cara yang berbeda dengan perubahan yang dibuat dalam satu representasi yang ditampilkan pada keseluruhan. Kelemahan Dapat melibatkan kode tambahan dan kompleksitas kode ketika model data dan interaksinya sederhana. Sebagai contoh, Tabel 4.1 menjelaskan pola Model-View-Controller yang terkenal. Pola ini adalah dasar dari manajemen interaksi di banyak sistem berbasis web. Deskripsi pola mencakup nama pola, deskripsi singkat (dengan model grafis terkait), dan contoh jenis sistem dimana pola digunakan (sekali lagi, mungkin dengan model grafis). Anda juga harus memasukkan informasi tentang kapan pola harus digunakan dan kelebihan dan kekurangannya. Model 87 Sistem Informasi grafis arsitektur yang terkait dengan pola MVC ditunjukkan pada Gambar 4.34 dan Gambar 4.35. Ini menyajikan arsitektur dari tampilan yang berbeda. Gambar 4.34 adalah tampilan konseptual dan Gambar 4.35 menunjukkan kemungkinan arsitektur run-time ketika pola ini digunakan untuk manajemen interaksi dalam sistem berbasis web. Gambar 4.34. Organisasi MVC Gambar 4.35. Arsitektur Aplikasi Web Menggunakan Pola MVC a) Arsitektur Berlapis (Layered Architecture) Gagasan pemisahan dan kemandirian merupakan dasar desain arsitektur karena memungkinkan perubahan dilokalisasi. Pola MVC, ditunjukkan pada Tabel 4.1, memisahkan elemen sistem, memungkinkan 88 Sistem Informasi mereka untuk berubah secara independen. Misalnya, menambahkan tampilan baru atau mengubah tampilan yang ada dapat dilakukan tanpa perubahan apa pun pada data dasar dalam model. Pola arsitektur berlapis adalah cara lain untuk mencapai pemisahan dan kemandirian. Pola ini ditunjukkan pada Tabel 4.2. Di sini, fungsionalitas sistem diatur ke dalam lapisan yang terpisah, dan setiap lapisan hanya bergantung pada fasilitas dan layanan yang ditawarkan oleh lapisan tepat di bawahnya. Tabel 4.2. Pola Arsitektur Berlapis Nama Arsitektur Berlapis Deskripsi Mengatur sistem ke dalam lapisan dengan fungsionalitas terkait yang berasosiasi dengan setiap lapisan. Lapisan menyediakan layanan ke lapisan di atasnya sehingga lapisan tingkat terendah mewakili layanan inti yang mungkin digunakan di seluruh sistem. Lihat Gambar 4.36. Contoh Model berlapis dari sistem untuk berbagi dokumen hak cipta yang disimpan di perpustakaan yang berbeda, seperti yang ditunjukkan pada Gambar 4.37. Kapan Digunakan saat membangun fasilitas baru di atas sistem yang ada; Digunakan ketika pengembangan tersebar di beberapa tim dengan tanggung jawab masing-masing tim untuk lapisan fungsionalitas; ketika ada persyaratan untuk keamanan multi-level. Kekuatan Memungkinkan penggantian seluruh lapisan selama antarmuka dipertahankan. Fasilitas redundan (misalnya, otentikasi) dapat disediakan di setiap lapisan untuk meningkatkan ketergantungan sistem. Kelemahan Dalam praktiknya, memberikan pemisahan yang bersih antara lapisan seringkali sulit dan lapisan tingkat tinggi mungkin harus berinteraksi langsung dengan lapisan tingkat yang lebih rendah daripada melalui lapisan langsung di bawahnya. Performa dapat menjadi masalah karena beberapa tingkat interpretasi permintaan layanan saat diproses di setiap lapisan. 89 Sistem Informasi Gambar 4.36. Arsitektur Berlapis Generik Gambar 4.37. Arsitektur Sistem LIBSYS b) Arsitektur Repository (Repository Architecture) Arsitektur berlapis dan pola MVC adalah contoh pola dimana tampilan yang disajikan adalah organisasi konseptual dari suatu sistem. Contoh berikutnya, pola repository (Tabel 4.3), menjelaskan bagaimana sekumpulan komponen yang berinteraksi dapat berbagi data. Mayoritas sistem yang menggunakan data dalam jumlah besar diatur di sekitar database atau repository bersama. Oleh karena itu, model 90 Sistem Informasi ini cocok untuk aplikasi dimana data dihasilkan oleh satu komponen dan digunakan oleh komponen lain. Contoh jenis sistem ini termasuk sistem komando dan kontrol, sistem informasi manajemen, sistem CAD, dan lingkungan pengembangan interaktif untuk perangkat lunak. Tabel 4.3. Pola Repository Nama Repository Deskripsi Semua data dalam suatu sistem dikelola dalam repository pusat yang dapat diakses oleh semua komponen sistem. Komponen tidak berinteraksi secara langsung, hanya melalui repository. Contoh Gambar 4.38 adalah contoh IDE yang menggunakan komponen repository dari informasi desain sistem. Setiap alat perangkat lunak menghasilkan informasi yang kemudian tersedia untuk digunakan oleh alat lain. Kapan Pola ini harus digunakan ketika kita memiliki sistem di mana Digunakan sejumlah besar informasi dihasilkan yang harus disimpan untuk waktu yang lama. Kita juga dapat menggunakannya dalam sistem berbasis data di mana penyertaan data dalam repository memicu tindakan atau alat. Kekuatan Komponen dapat berdiri sendiri, tidak perlu mengetahui keberadaan komponen lain. Perubahan yang dilakukan oleh satu komponen dapat disebarkan ke semua komponen. Semua data dapat dikelola secara konsisten (misalnya, pencadangan dilakukan pada waktu yang sama) karena semuanya ada di satu tempat. Kelemahan Repository adalah satu titik kegagalan sehingga masalah dalam repository mempengaruhi keseluruhan sistem. Mungkin inefisiensi dalam mengatur semua komunikasi melalui repository. Mendistribusikan repository di beberapa komputer mungkin sulit. 91 Sistem Informasi Gambar 4.38. Arsitektur Repository untuk IDE c) Arsitektur Client-Server (Client–Server Architecture) Pola repository berkaitan dengan struktur statis suatu sistem dan tidak menunjukkan organisasi run-time-nya. Contoh berikutnya menggambarkan organisasi run-time yang sangat umum digunakan untuk sistem terdistribusi. Pola client-server dijelaskan pada Tabel 4.4. Sebuah sistem yang mengikuti pola client-server diatur sebagai satu set layanan dan server terkait, dan klien yang mengakses dan menggunakan layanan. Komponen utama dari model ini adalah: 1) Seperangkat server yang menawarkan layanan ke komponen lain. Contoh server termasuk server cetak yang menawarkan layanan pencetakan, server file yang menawarkan layanan manajemen file, dan server kompilasi, yang menawarkan layanan kompilasi bahasa pemrograman. 2) Sekumpulan klien yang memanggil layanan yang ditawarkan oleh server. Biasanya akan ada beberapa contoh program klien yang dijalankan secara bersamaan pada komputer yang berbeda. 3) Jaringan yang memungkinkan klien untuk mengakses layanan ini. Sebagian besar sistem client-server diimplementasikan sebagai sistem terdistribusi, terhubung menggunakan protokol Internet. 92 Sistem Informasi Tabel 4.4. Pola Client-Server Nama Client-Server Deskripsi Dalam arsitektur client-server, fungsionalitas sistem diatur ke dalam layanan, dengan setiap layanan dikirimkan dari server terpisah. Klien adalah pengguna layanan ini dan mengakses server untuk menggunakannya. Contoh Gambar 4.39 adalah contoh perpustakaan film dan video/DVD yang diatur sebagai sistem client-server. Kapan Digunakan ketika data dalam database bersama harus diakses dari Digunakan berbagai lokasi. Karena server dapat direplikasi, server juga dapat digunakan ketika beban pada sistem bervariasi. Kekuatan Keuntungan utama dari model ini adalah bahwa server dapat didistribusikan di seluruh jaringan. Fungsionalitas umum (misalnya, layanan pencetakan) dapat tersedia untuk semua klien dan tidak perlu diimplementasikan oleh semua layanan. Kelemahan Setiap layanan adalah satu titik kegagalan sehingga rentan terhadap serangan penolakan layanan atau kegagalan server. Kinerja mungkin tidak dapat diprediksi karena tergantung pada jaringan dan juga sistem. Mungkin masalah manajemen jika server dimiliki oleh organisasi yang berbeda. Gambar 4.39. Arsitektur Client-Server untuk Perpustakaan Film d) Arsitektur Pipa dan Filter (Pipe and filter architecture) Contoh terakhir dari pola arsitektur adalah pola pipa dan filter. Ini adalah model organisasi run-time dari suatu sistem di mana transformasi 93 Sistem Informasi fungsional memroses input mereka dan menghasilkan output. Data mengalir dari satu ke yang lain dan ditransformasikan saat bergerak melalui urutan. Setiap langkah pemrosesan diimplementasikan sebagai transformasi. Data input mengalir melalui transformasi ini sampai dikonversi menjadi output. Transformasi dapat dijalankan secara berurutan atau paralel. Data dapat diproses oleh setiap transformasi item demi item atau dalam satu batch. Nama 'pipe dan filter' berasal dari sistem Unix asli di mana dimungkinkan untuk menghubungkan proses menggunakan 'pipa'. Ini melewati aliran teks dari satu proses ke proses lainnya. Sistem yang sesuai dengan model ini dapat diimplementasikan dengan menggabungkan perintah Unix, menggunakan pipa dan fasilitas kontrol dari shell Unix. Istilah 'filter' digunakan karena transformasi 'menyaring' data yang dapat diproses dari aliran data inputnya. Tabel 4.5. Pola Pipa dan Filter Nama Pipa dan Filter Deskripsi Pemrosesan data dalam suatu sistem diatur sedemikian rupa sehingga setiap komponen pemrosesan (filter) bersifat diskrit dan melakukan satu jenis transformasi data. Data mengalir (seperti dalam pipa) dari satu komponen ke komponen lain untuk diproses. Contoh Gambar 6.13 adalah contoh sistem pipa dan filter yang digunakan untuk memproses faktur. Kapan Umumnya digunakan dalam aplikasi pemrosesan data (baik Digunakan berbasis batch maupun transaksi) di mana input diproses dalam tahapan terpisah untuk menghasilkan output terkait. Kekuatan Mudah dipahami dan mendukung transformasi penggunaan kembali. Gaya alur kerja cocok dengan struktur banyak proses bisnis. Evolusi dengan menambahkan transformasi sangatlah mudah. Dapat diimplementasikan sebagai sistem sekuensial atau bersamaan. 94 Sistem Informasi Nama Pipa dan Filter Kelemahan Format untuk transfer data harus disepakati antara transformasi komunikasi. Setiap transformasi harus mengurai inputnya dan mengurai output-nya ke bentuk yang disepakati. Ini meningkatkan overhead sistem dan mungkin berarti bahwa tidak mungkin untuk menggunakan kembali transformasi fungsional yang menggunakan struktur data yang tidak kompatibel. Gambar 4.40. Contoh Arsitektur Pipa dan Filter 4. Arsitektur Aplikasi Sistem aplikasi dimaksudkan untuk memenuhi kebutuhan bisnis atau organisasi. Semua bisnis memiliki banyak kesamaan, mereka perlu mempekerjakan orang, menerbitkan faktur, menyimpan rekening, dan sebagainya. Bisnis yang beroperasi di sektor yang sama menggunakan aplikasi khusus sektor yang sama. Oleh karena itu, seperti halnya fungsi bisnis umum, semua perusahaan telepon memerlukan sistem untuk menghubungkan panggilan, mengelola jaringan mereka, mengeluarkan tagihan kepada pelanggan, dll. Akibatnya, sistem aplikasi yang digunakan oleh bisnis ini juga memiliki banyak kesamaan. Arsitektur aplikasi dapat diimplementasikan kembali ketika mengembangkan sistem baru tetapi, untuk banyak sistem bisnis, penggunaan kembali aplikasi dimungkinkan tanpa implementasi ulang. Ini dilihat dalam pertumbuhan sistem Enterprise Resource Planning (ERP) dari perusahaan seperti SAP dan Oracle, dan paket perangkat lunak vertikal (COTS) untuk 95 Sistem Informasi aplikasi khusus di berbagai bidang bisnis. Dalam sistem ini, sistem generik dikonfigurasi dan disesuaikan untuk membuat aplikasi bisnis tertentu. Ada banyak jenis sistem aplikasi dan dalam beberapa kasus mungkin tampak sangat berbeda. Namun, banyak dari aplikasi yang sangat berbeda ini saat ini memiliki banyak kesamaan dan dengan demikian dapat diwakili oleh arsitektur aplikasi abstrak tunggal. Hal ini diilustrasikan dengan penjelasan arsitektur berikut dari dua jenis aplikasi: a) Aplikasi pemrosesan transaksi (transaction processing applications) adalah aplikasi yang berpusat pada basis data yang memroses permintaan pengguna untuk informasi dan memperbarui informasi dalam basis data. Ini adalah jenis sistem bisnis interaktif yang paling umum. Semua diatur sedemikian rupa sehingga tindakan pengguna tidak dapat saling mengganggu dan integritas database tetap terjaga. Kelas sistem ini mencakup sistem perbankan interaktif, sistem e- commerce, sistem informasi, dan sistem pemesanan. Gambar 4.41. Arsitektur Perangkat Lunak dari Sistem ATM b) Sistem pemrosesan bahasa (language processing systems) adalah sistem dimana maksud pengguna diekspresikan dalam bahasa formal (seperti Java). Sistem pemrosesan bahasa memproses bahasa ini ke dalam format internal dan kemudian menafsirkan representasi internal ini. Sistem pemrosesan bahasa yang paling terkenal adalah compiler, 96 Sistem Informasi yang menerjemahkan program bahasa tingkat tinggi ke dalam kode mesin. Namun, sistem pemrosesan bahasa juga digunakan untuk menginterpretasikan bahasa perintah untuk database dan sistem informasi, dan bahasa markup seperti XML. Gambar 4.42. Arsitektur Sistem Pemrosesan Bahasa 4.2. Rangkuman Pemodelan sistem umumnya berarti mewakili sistem menggunakan beberapa jenis notasi grafis, yang sekarang hampir selalu digunakan adalah notasi dalam Unified Modeling Language (UML). Pemodelan proses sistem informasi dapat mengadopsi pendekatan berorientasi pada prosedur, berorientasi pada objek, atau berorientasi pada layanan. Desain antarmuka pengguna harus memastikan bahwa interaksi antara manusia dan mesin menyediakan operasi dan kontrol mesin yang efektif. Perancangan antarmuka pengguna secara umum dibagi dua yaitu rancangan masukan dan rancangan keluaran. Desain arsitektur berkaitan dengan pemahaman bagaimana sistem harus diatur dan merancang struktur keseluruhan sistem itu. Ada empat 97 Sistem Informasi pandangan yang dapat digunakan untuk merancang arsitektur, yaitu pandangan logis, proses, pengembangan, dan fisik. Selain itu, dalam merancang arsitektur perlu memilih pola yang cocok digunakan sesuai dengan kondisi yang dihadapi dengan mempelajari kekuatan dan kelemahan masing- masing pola arsitektur. 4.3. Soal Latihan Buatlah Diagram Use Case berdasarkan stakeholder request “Diperlukan mekanisme monitoring dan evaluasi yang real-time dan komprehensif pada kegiatan pendataan Survei Biaya Hidup yang dilakukan BPS yang mampu mendeteksi wilayah mana yang belum dan sudah selesai dilakukan pendataan, mampu memberikan informasi berapa jumlah rumah tangga yang berhasil didata dan non respons, dan mampu menyajikan laporan data statistik konsumsi rumah tangga”. 4.4. Contoh Kasus BPS Provinsi Y membutuhkan suatu sistem yang dapat mengelola pertukaran data registrasi penduduk dengan sistem yang ada di Dinas Dukcapil setempat. Pertukaran data dilakukan dengan memanfaatkan jaringan internet dikarenakan tidak tersedia jalur VPN khusus. Data yang diperoleh akan ditampilkan dalam sebuah dashboard. Berdasarkan kebutuhan tersebut, pola arsitektur apa yang menurut Anda paling cocok diterapkan dan sertakan hasil rancangan arsitekturnya. Anda dapat menambahkan asumsi jika diperlukan. 98