Pengembangan Sistem Informasi Akuntansi: Modul Enterprise, Database dan Interface



Pengembangan Sistem Informasi Akuntansi: Modul Enterprise, Database dan Interface!

Sejumlah paket perangkat lunak akuntansi tersedia menawarkan berbagai fitur. Harganya jauh lebih murah daripada biaya perangkat lunak akuntansi khusus. Namun, paket perangkat lunak ini ­hanya menawarkan struktur untuk sistem informasi akuntansi. Paling banyak, mereka mengurangi upaya pemrograman untuk sistem informasi akuntansi.

Gambar milik: bestsmallbizhelp.com/wp-content/uploads/2011/07/1018910261.jpg

Perkembangan sistem informasi akuntansi lebih dari sekadar perangkat lunak untuk posting buku besar dan pembuatan laporan. Ini juga melibatkan penetapan prosedur untuk menangkap data dan distribusi, serta analisis informasi akuntansi.

Perkembangan sistem informasi akuntansi ­dijelaskan dengan referensi khusus untuk kebutuhan perusahaan bisnis skala menengah hingga besar. Namun, langkah-langkah ini akan menjadi umum untuk sebagian besar sistem informasi lainnya dalam sebuah perusahaan bisnis.

1. Modul Perusahaan:

Modul perusahaan pengembangan sistem informasi melibatkan identifikasi entitas dasar dan keterkaitannya, identifikasi aktivitas dasar dan mengelompokkan kembali aktivitas ini ke dalam sub sistem. Kemudian, prioritas diputuskan berdasarkan analisis biaya-manfaat untuk perusahaan.

Mengidentifikasi Entitas:

Sejumlah besar entitas ada di perusahaan bisnis dan daftarnya beragam seperti aktivitas bisnisnya. Namun, pada tahap ini, perhatian utama adalah untuk mengidentifikasi entitas yang luas, yang masing-masing berisi ­sekelompok entitas elementer. Kerner 5 menunjukkan enam entitas dasar dalam sebuah perusahaan bisnis.

Mereka adalah pelanggan, produk, ­vendor, personel, fasilitas, dan uang. Dalam sistem informasi akuntansi terdapat tiga entitas dasar yaitu transaksi, akun, dan periode pemrosesan. Keterkaitan antar entitas ini dapat dinyatakan dengan menggunakan diagram ER seperti yang ditunjukkan Gambar 8.2.

Transaksinya bisa bermacam-macam, seperti penerimaan, pembayaran ­, penjualan, pembelian, perolehan aset atau pembayaran kembali kewajiban, dll. Dan masing-masing dari mereka dapat disebut entitas tingkat rendah. Demikian pula, akun dapat dari jenis yang berbeda, seperti aset, kewajiban, pendapatan, dan beban.

Masing-masing kepala ini dapat memiliki entitas tingkat yang lebih rendah ­seperti aset tetap dan aset lancar. Entitas ini dapat dibagi lagi menjadi entitas tingkat yang lebih rendah seperti tanah dan bangunan, pabrik dan mesin, dll. Namun, pada tahap ini, entitas yang luas perlu diidentifikasi. Detailnya dikerjakan pada saat mendesain database.

Entitas diidentifikasi berdasarkan dan dengan maksud untuk menentukan ­ruang lingkup dan fokus sistem informasi. Misalnya, jika sistem informasi dipandang sebagai sistem informasi strategis, entitas luas harus diidentifikasi berdasarkan dorongan strategis yang direncanakan perusahaan untuk diberikan pada aktivitasnya dengan bantuan sistem informasi.

Dorongan ini dapat berupa minimisasi biaya, layanan pelanggan, diferensiasi produk, dan aliansi strategis. Entitas dasar dalam kasus seperti itu adalah ­pelanggan, saluran, perusahaan pesaing, produk, dll.

Analisis Aktivitas:

Aspek penting lainnya dari modul perusahaan adalah identifikasi aktivitas yang terkait dengan entitas. Kegiatan ini secara luas diidentifikasi dalam bentuk hubungan dalam diagram ER. Namun ­, detail diperoleh dengan bantuan analisis aktivitas. Struktur organisasi yang ada merupakan sumber informasi yang penting mengenai luasnya kegiatan yang dilakukan oleh perusahaan.

Namun, untuk mengembangkan sistem informasi yang independen dari struktur organisasi saat ini, penting untuk mendasarkan ­analisis aktivitas pada entitas dasar yang telah diidentifikasi di atas. Tingkat selanjutnya dari analisis aktivitas melibatkan identifikasi aktivitas siklus hidup. Dalam kasus ‘transaksi’ menjadi salah satu entitas dasar dalam sistem informasi akuntansi, ada empat kegiatan siklus hidup yang luas, yaitu:

  1. Siklus hidup pembelian
  2. Siklus hidup produksi
  3. Siklus hidup pendapatan
  4. Siklus hidup investasi

Demikian pula, periode pemrosesan memiliki dua aktivitas siklus hidup dasar, yaitu:

sebuah. Merencanakan dan mengontrol siklus hidup

  1. Siklus hidup pelaporan internal dan eksternal

Aktivitas siklus hidup ini adalah aktivitas yang sedang berlangsung dan dilakukan secara terus menerus. Masing-masing kegiatan ini mungkin berhubungan secara berurutan dengan beberapa kegiatan lainnya. Level ketiga dari analisis aktivitas melibatkan pemisahan aktivitas siklus hidup menjadi fungsi.

Misalnya, setiap jenis transaksi harus dimulai dan dikenali; maka data mengenai transaksi harus ditangkap, dikodekan untuk klasifikasi di masa mendatang ­, diklasifikasikan, dirangkum dan dilaporkan. Fungsi-fungsi ini harus dilakukan secara berbeda untuk jenis transaksi yang berbeda. Proses mendefinisikan fungsi hanya berfokus pada aktivitas yang membuat, memperbarui, atau menggunakan informasi dalam database perusahaan.

Pada level analisis aktivitas ini, aktivitas bersifat mandiri ­, telah didefinisikan dengan jelas awal dan akhir peristiwa atau simpul dan orang yang dapat diidentifikasi atau sekelompok orang yang bertanggung jawab untuk melakukan fungsi tersebut.

Fungsi-fungsi ini kemudian dapat dibagi menjadi sub-fungsi sampai fungsi-fungsi tersebut cukup spesifik untuk mendefinisikan modul untuk program komputer. Pemisahan aktivitas siklus hidup ke dalam fungsi dan subfungsi membantu dalam mengidentifikasi fungsi yang berulang di lebih dari satu aktivitas siklus hidup.

Misalnya, fungsi klasifikasi data yang diambil dapat dilakukan dalam siklus hidup pembelian dan pemasaran. Analisis aktivitas semacam itu membantu dalam mengidentifikasi peluang untuk meningkatkan desain yang ada dengan:

  1. menghilangkan fungsi yang berlebihan
  2. menggabungkan fungsi yang digandakan
  3. menyederhanakan dan meningkatkan metode pengolahan

Redundansi dapat diidentifikasi dengan analisis aktivitas yang cermat ­. Kegiatan yang cenderung menawarkan peluang untuk meningkatkan pemrosesan meliputi kegiatan:

sebuah. Itu dilakukan di tempat lain juga

  1. Itu bisa digabung dengan kegiatan lain
  2. Itu bisa ditangani oleh orang lain juga
  3. Itu dapat dilakukan pada beberapa tahap lain dari siklus hidup yang tidak menambah nilai apapun pada produk atau layanan ­sistem informasi.

Peringatan di sini adalah bahwa tidak semua redundansi itu buruk. Faktanya, beberapa redundansi atau duplikasi mungkin sengaja dibiarkan menyusup ke dalam sistem. Hal ini dapat dilakukan untuk meningkatkan ­kinerja dan keandalan sistem.

Misalnya, beberapa duplikasi mungkin diperlukan untuk memastikan kesederhanaan prosedur dan meningkatkan kecepatan pemrosesan. Penghapusan redundansi dapat mengakibatkan ‘meletakkan semua telur dalam satu keranjang’ dan dengan demikian dapat mempengaruhi keandalan. Risiko implikasi tak terduga dan pengembalian yang rendah dari metode atau prosedur baru yang diusulkan adalah faktor lain yang perlu diperhatikan sebelum perubahan diusulkan dalam sistem informasi.

Mengelompokkan Aktivitas ke dalam Sub Sistem:

Setelah kegiatan didefinisikan menggunakan pendekatan top-down yang diadopsi di atas, mereka dikelompokkan kembali untuk membentuk sub sistem. Keputusan penting yang harus diambil pada tahap ini berkaitan dengan dasar pengelompokan. Mungkin tidak ada satu kriteria objektif tunggal untuk menentukan subsistem yang termasuk dalam suatu kegiatan.

Struktur organisasi saat ini dapat memberikan salah satu dasar untuk pengelompokan kegiatan. Namun, struktur organisasi saat ini ­dapat mengalami perubahan dan kegunaan sistem informasi dapat hilang.

Untuk mengelompokkan kegiatan ke dalam sub sistem, kami mengambil bantuan dari teori organisasi. Salah satu fitur penting dari setiap struktur organisasi yang baik adalah bertujuan untuk memfasilitasi ­koordinasi kegiatan.

Sistem komunikasi yang efektif sangat ­diperlukan untuk koordinasi yang lebih baik. Oleh karena itu, penting untuk mengelompokkan kegiatan sedemikian rupa sehingga komunikasi difasilitasi dalam kelompok dan kebutuhan komunikasi antar kelompok diminimalkan.

Untuk tujuan merepresentasikan dan mendokumentasikan pengelompokan aktivitas ke dalam sub sistem, diagram struktur atau diagram blok hirarkis digunakan. Gambar 8.3 memberikan bagan struktur yang menunjukkan komponen-komponen siklus pendapatan.

Bagan struktur serupa dapat disiapkan untuk kelompok kegiatan lainnya dan, akhirnya, sub sistem ini terintegrasi satu sama lain yang menyediakan blok bangunan untuk sistem informasi akuntansi.

Sub sistem yang diidentifikasi oleh pengelompokan aktivitas adalah ­pesaing serius untuk menjadi entitas dalam struktur organisasi. Kelebihan metode clustering untuk pengelompokan kegiatan adalah pengelompokan dilakukan berdasarkan fungsi dan sumber daya, bukan berdasarkan wilayah geografis.

Pengelompokan berdasarkan fungsi seperti itu memastikan homogenitas di antara anggota kelompok orang yang terkait dengan masing-masing sub sistem. Dampak ­organisasi sistem informasi terhadap struktur organisasi tidak jarang.

Seringkali, pengenalan sistem informasi disertai ­dengan perubahan dalam struktur organisasi karena fakta bahwa sistem informasi baru mengubah cara orang bekerja dalam suatu organisasi.

Oleh karena itu, semakin penting bahwa perancang sistem informasi bekerja dalam asosiasi aktif dengan orang-orang pengembangan organisasi sementara pengelompokan kegiatan ke dalam kelompok dan sub sistem sedang dilakukan. Hal ini memastikan tidak hanya struktur baru yang lebih pragmatis tetapi juga lebih dapat diterima oleh masyarakat. Dalam kasus seperti itu, transisi dari sistem lama ke sistem baru tidak terlalu menyakitkan dan lebih murah.

Menetapkan prioritas:

Setelah sub sistem diidentifikasi dan diintegrasikan secara keseluruhan, prioritas perlu ditentukan di antara berbagai sub sistem dan fitur di setiap sistem. Sistem informasi ­akan membutuhkan komitmen sumber daya keuangan.

Selain itu, mungkin ada biaya implisit dari sistem baru dalam hal perubahan yang diperlukan dalam proses operasi. Oleh karena itu, ­penting untuk menimbang pro dan kontra dari setiap sub sistem dan sub-sub sistem sebelum dirancang dan diimplementasikan.

Setiap sub sistem dievaluasi berdasarkan kriteria evaluasi yang terdefinisi dengan baik yang didefinisikan dalam hal faktor penentu keberhasilan (CSF). Faktor-faktor ini telah diidentifikasi dalam Bagian 8.2.

Metode lainnya adalah, brainstorming, dimana orang-orang yang relevan dalam organisasi berkumpul untuk mengidentifikasi faktor-faktor yang perlu dipertimbangkan dalam menentukan prioritas. Aliran ide bebas ­didorong pada tahap pertama.

Prinsip dasarnya, di sini, adalah tidak ada ide yang konyol atau tidak relevan pada tahap ini. Selama tahap kedua, proses eliminasi dimulai dan setelah diskusi, ­saran diselesaikan.

Setelah daftar faktor selesai, bobot relatif diberikan dan fungsi kriteria didefinisikan untuk mengevaluasi setiap komponen sistem informasi akuntansi yang diusulkan.

2. Modul Basis Data:

Sistem informasi akuntansi memproses volume data yang besar. Mengelola data, dengan demikian, merupakan salah satu pertimbangan utama dalam proses pengembangannya. Ada dua pendekatan dasar untuk desain data, yaitu:

sebuah. Tradisional, pendekatan berorientasi aplikasi, dan

  1. Pendekatan basis data.

Pendekatan tradisional:

Pendekatan tradisional untuk desain data berorientasi pada aplikasi dalam arti bahwa untuk setiap aplikasi, ­kumpulan file data terpisah dihasilkan sesuai kebutuhannya. Dengan kata lain, file data didedikasikan untuk aplikasi tertentu dan dengan cara ‘dimiliki’ oleh aplikasi tersebut.

Misalnya, aplikasi piutang ­harus memiliki file data induk pelanggan, file transaksi penjualan dan tanda terima dari file transaksi pelanggan. File data ini hanya digunakan untuk aplikasi piutang.

Pendekatan ini cocok untuk sistem informasi akuntansi yang lebih kecil karena kesederhanaannya. Namun, seiring ­berkembangnya sistem informasi dalam hal volume data dan kompleksitas analisis, hal itu juga menimbulkan masalah tertentu.

Masalah mendasar dengan pendekatan tradisional adalah bahwa program aplikasi bergantung pada file data yang mereka gunakan dan manipulasi. Akibatnya, setiap perubahan pada file data (dalam hal penambahan atau penghapusan item data) memerlukan perubahan pada semua program yang menggunakan file data tersebut.

Ketergantungan data ini tidak ­memungkinkan perubahan pada file data yang menyebabkan ketidakfleksibelan. Jika tidak ada alat untuk melakukan aktivitas pengelolaan data tipe rutin pada data, fasilitas tersebut harus disertakan dalam program yang menggunakan file data. Ini mempersulit program. Masalah lain terkait dengan memenuhi kueri ad hoc.

Untuk permintaan yang tidak terduga, program khusus perlu ditulis. Program khusus semacam itu membutuhkan waktu untuk dikembangkan dan hanya digunakan sekali dan dengan demikian, mahal. Banyak terjadi duplikasi dalam pencatatan data barang.

Misalnya, item data seperti nama pelanggan, nomor faktur, harga, dll. Dapat dimasukkan dalam file transaksi untuk aplikasi pemrosesan pesanan penjualan, serta aplikasi piutang ­. Hal ini menyebabkan redundansi dalam data.

Redundansi data mengakibatkan penggunaan media penyimpanan yang tidak efisien. Ini juga memengaruhi kualitas data karena pembaruan item data yang diberikan mungkin tidak terjadi di semua file tempat item data disimpan.

Pendekatan basis data:

Pendekatan modern untuk desain data adalah ­pendekatan basis data. Pendekatan ini didasarkan pada asumsi bahwa beberapa aplikasi memerlukan kumpulan data yang memiliki banyak kesamaan. Oleh karena itu, lebih baik untuk memiliki tempat penyimpanan data yang memenuhi persyaratan data dari setiap aplikasi dalam sistem informasi.

Repositori umum disebut database dan dikelola oleh sistem manajemen yang disebut Database Management System (DBMS). DBMS adalah perangkat lunak yang dirancang khusus untuk mengelola data dalam basis data sesuai dengan permintaan dari program aplikasi, maupun dari yang datang langsung dari pengguna. Desain konseptual lingkungan database ditunjukkan dengan bantuan Gambar. 8.5.

Pendekatan basis data menangani masalah ­pendekatan aplikasi. Ini memastikan independensi data karena DBMS menangani aliran data dari database ke program aplikasi. Aplikasi pengguna tidak perlu repot tentang lokasi data dalam database. Kamus data dipelihara dan data dapat dipanggil menggunakan kata-kata yang ditentukan dalam kamus data.

Pendekatan basis data ­juga mengurangi ukuran dan kompleksitas program aplikasi karena jenis operasi pemrosesan data rutin seperti pengurutan dilakukan oleh DBMS. DBMS juga digunakan untuk melayani kebutuhan query ad hoc. DBMS menggunakan Structured Query Language (SQL) sebagai bahasa komunikasi antara pengguna dan database.

Bahasanya sangat sederhana dan cukup dekat dengan bahasa Inggris. Ini memastikan bahwa pengguna dapat memperoleh informasi dari database jika diperlukan. Jumlah pelatihan yang dibutuhkan oleh manajer untuk membuat permintaan ad hoc minimal dan beberapa jam pelatihan dapat memberikan keterampilan dasar untuk menggunakan bahasa tersebut. Mungkin, keuntungan terpenting dari pendekatan basis data adalah pengurangan redundansi dalam basis data.

Ada banyak model yang umum digunakan dalam desain database. Namun, pendekatan modern mengikuti Model ER dari desain basis data. Pendekatan ini adalah pendekatan top-down dan grafik ER yang digambar sebelumnya di Enterprise Module menjadi ­titik awal.

Untuk setiap entitas dan relasi, atribut diidentifikasi dan didokumentasikan dalam diagram ER Diperpanjang (diagram EER). Dalam sistem informasi akuntansi, EER dapat ditarik untuk setiap entitas (transaksi dan akun) dan hubungan (efek) untuk akun transaksi ditunjukkan dalam diagram ER. Misalnya ­, untuk transaksi penjualan, atribut dapat ditentukan dan didokumentasikan seperti yang ditunjukkan pada Gambar. 8.6.

Atribut ini menjadi item data (field) dalam record di file data untuk setiap entitas (dalam hal ini file transaksi penjualan). Demikian pula, untuk entitas dan relasi lain, diagram Extended ER (EER) seperti ­itu digambar.

Setelah atribut ini diidentifikasi, kemungkinan beberapa atribut akan sama dalam bagan EER yang berbeda. Untuk menghindari duplikasi atribut umum tersebut, dilakukan normalisasi data.

3. Modul Antarmuka:

Modul antarmuka menentukan sumber item data dan format layar ­input/output dan dialog yang akan digunakan dalam sistem. Ini juga mendefinisikan format laporan dan layar untuk navigasi dari satu bagian sistem informasi ke bagian lainnya.

Dengan kata lain, modul berkaitan dengan mendefinisikan antarmuka antara pengguna dan mesin. Pentingnya modul antarmuka telah meningkat karena meningkatnya komunikasi antara pengguna dan sistem informasi.

Entri data dan kueri data menjadi interaktif. Dalam banyak kasus, formulir input dihilangkan dari proses dan entri data dilakukan secara langsung. Persyaratan permintaan data yang berubah membuat banyak formulir laporan menjadi terlalu kaku. Layar laporan interaktif memberikan fleksibilitas yang lebih besar dalam kueri data dan mengizinkan format laporan yang ditentukan pengguna untuk dilihat dan dicetak.

Layar masukan:

Layar input didefinisikan berdasarkan ­proses alami aktivitas bisnis. Oleh karena itu, mereka bergantung terutama pada formulir yang digunakan untuk merekam data secara manual saat pertama kali diterima oleh perusahaan. Formulir-formulir ini, dalam sistem informasi akuntansi, dapat mencakup faktur, pesanan pembelian, pesanan penjualan, voucher pengeluaran, dll.

Jadi, dalam modul antarmuka, formulir juga ditinjau; didesain ulang dan layar input didefinisikan berdasarkan bentuk yang digunakan oleh perusahaan. Dalam sistem informasi akuntansi ­, seseorang perlu lebih berhati-hati dalam hal desain layar.

Peningkatan kecil pada layar input yang menyimpan entri data dapat menghasilkan penghematan yang besar karena frekuensi penggunaan layar entri data sangat besar. Faktor-faktor berikut dapat diingat saat merancang layar masukan:

(a) Mencocokkan dengan formulir:

Format layar masukan harus sesuai dengan formulir masukan. Kadang-kadang, mengadopsi format yang sama dengan yang digunakan oleh formulir input akan bermanfaat. Sedapat mungkin, bahkan warna latar belakang ­layar dapat dicocokkan dengan warna formulir input.

(b) Interaktif:

Layar input harus interaktif. Ini harus menunjukkan kesalahan dalam entri data tepat pada saat entri dan mengizinkan koreksi ­. Setiap item data harus memiliki beberapa kondisi validasi data dan setiap pelanggaran terhadap kondisi validasi data tersebut harus secara otomatis disorot pada saat entri data.

Misalnya, layar entri data untuk entri faktur harus menunjukkan kesalahan dalam entri tanggal jika tanggal tersebut tidak valid. Tanggal mungkin tidak valid karena berada di luar periode akuntansi atau bulan yang dimasukkan lebih besar dari dua belas.

(c) Konsistensi:

Layar masukan harus konsisten dalam menentukan istilah dan lokasi untuk jenis item data umum tertentu. Ini membantu dalam mengurangi waktu pelatihan karena meningkatkan keakraban; misalnya , tanggal ­transaksi selalu dapat ditempatkan di sudut kanan setiap dokumen transaksi.

(d) Kesederhanaan:

Salah satu fitur dasar dari layar input yang baik adalah kesederhanaannya. Terlalu banyak bagian yang disorot, kedipan nilai atau ­penghargaan, atau meletakkan terlalu banyak kotak dan garis bawah hanya menambah kerumitan dan kebingungan. Terkadang, bunyi bip digunakan untuk menunjukkan kesalahan entri data. Harus ada penggunaan bip seperti itu secara bijaksana dan umumnya, ini harus dihindari.

(e) Fleksibilitas:

Layar input harus dapat dimodifikasi ­. Ini harus memungkinkan pengguna untuk melakukan modifikasi dalam hal penambahan atau penghapusan dan relokasi item data. Prosedur untuk modifikasi harus sederhana. Saat ini, Screen Generators yang tersedia dari berbagai produsen perangkat lunak menawarkan fitur-fitur seperti menyeret dan memperbaiki/melepas item data apa pun dari layar dengan menggunakan perangkat penunjuk biasa seperti mouse.

(f) Dibuat khusus:

Layar harus dibuat khusus untuk setiap kategori ­pengguna. Ini akan mengurangi prosedur mulai dan masuk yang terlalu lama.

Layar laporan:

Laporan dapat disiapkan untuk analisis lebih lanjut oleh beberapa program komputer lain atau oleh pengguna itu sendiri. Data yang diarahkan untuk diproses oleh program komputer, seperti spreadsheet, paket statistik, pengolah kata, disimpan dalam file data.

Lebih baik menempatkannya dalam format data standar sehingga dapat diakses dengan mudah. Laporan yang dimaksudkan untuk pengguna biasanya disimpan dalam bentuk teks, tabel, dan grafik. Upaya harus dilakukan untuk ­memastikan bahwa laporan dibuat dan dikomunikasikan tepat waktu, akurat, jelas dan dengan biaya rendah.

Layar dialog:

Layar dialog adalah layar yang digunakan untuk mengidentifikasi dan melakukan tugas-tugas dalam sistem informasi. Mereka menentukan apa yang dapat dilakukan dengan bantuan sistem informasi ­, bagaimana menavigasi dari satu tugas/prosedur ke yang lain dan bagaimana melakukan berbagai tugas yang diizinkan oleh sistem informasi.

Layar ini harus sederhana dan tidak ambigu. Kesederhanaan dapat diperkenalkan dengan menyediakan Graphic User Interface (GUI) dan membatasi jumlah item menu dalam satu layar. Prosedur navigasi dari satu menu ke menu lainnya harus sederhana, dalam urutan yang benar dan mudah diikuti. Ini juga harus menunjukkan kesalahan dalam menjalankan opsi dan segera memperbaiki prosedur.

Alat KASUS untuk desain layar:

Berbagai alat KASUS tersedia ­untuk merancang formulir, layar, dan laporan. Alat-alat ini memiliki keunggulan menawarkan lingkungan perancangan yang fleksibel dan mudah dipahami bahkan untuk pengguna baru.

Karena alat-alat ini memiliki fasilitas prototyping layar, memungkinkan keterlibatan pengguna yang lebih besar dalam proses perancangan layar. Tentu saja, alat tersebut memungkinkan perubahan cepat dan meningkatkan produktivitas pemrogram dengan membuat kode untuk implementasi akhir. Hal ini menyebabkan berkurangnya waktu pengembangan.

Setelah form, layar input/output dan layar dialog siap, mereka harus diuji dan dimodifikasi sesuai kebutuhan. Bentuk dan layar yang dirancang menggunakan alat CASE dapat dengan mudah dimodifikasi. Oleh ­karena itu, upaya harus dilakukan untuk meningkatkan penerimaan sistem dengan pengujian yang tepat dan modifikasi formulir dan layar.

4. Modul Aplikasi:

Modul ini memperluas sub sistem yang telah diidentifikasi dalam ­modul perusahaan. Untuk setiap sub sistem yang diidentifikasi dalam bagan struktur, prosedur pemrosesan terperinci ditentukan dalam modul ini.

Dengan kata lain, modul aplikasi terutama berkaitan dengan proses yang terlibat dalam mengubah data input menjadi nilai yang akan menjadi bagian dari laporan seperti yang didefinisikan dalam modul antarmuka. Dapat dicatat bahwa hanya proses-proses itu yang harus didefinisikan

(a) Mengubah nilai dalam database, atau

(b) Itu bukan bagian dari database tetapi diperlukan di ­port yang didefinisikan dalam modul antarmuka.

Nilai-nilai yang sudah ada dalam database dapat diakses menggunakan bahasa query DBMS sesuai kebutuhan pengguna ­tanpa pengembangan program untuk tujuan ini. Dengan demikian, tugas modul aplikasi dikurangi dengan pekerjaan yang sudah dilakukan dalam desain database dan desain layar.

Diagram aliran data:

Peran pengelola dalam modul ini pada dasarnya ­mengidentifikasi prosedur pemrosesan dasar. Algoritma rinci umumnya didefinisikan dan didokumentasikan oleh profesional sistem informasi, tentu saja, dengan bantuan aktif dari manajer.

Alat yang digunakan untuk menyatakan proses-proses yang akan dilakukan untuk mengubah ­data masukan menjadi keluaran adalah Data Flow Diagram (DFD). Ini menggambarkan aliran data. Ini mendefinisikan apa yang harus dilakukan dan mengabaikan bagaimana hal itu harus dilakukan atau bagaimana hal itu dilakukan sebelumnya. Pendekatan ini memungkinkan perubahan sistem dan kelemahan sistem yang ada dapat dihilangkan dengan mengikuti pendekatan ini.

Simbol DFD:

Ada empat simbol dasar yang digunakan dalam DFD. Mereka:

(i) Terminator:

Terminator adalah sumber eksternal aliran data atau sink data eksternal. Ini adalah entitas atau objek eksternal seperti pelanggan, vendor, pemegang saham, dll. Karena terminator adalah entitas eksternal, komunikasi antara terminator ­dikecualikan dari sistem. Terminator dilambangkan dengan persegi panjang (umumnya, dibayangi) dan label ditempatkan di dalam persegi panjang.

(ii) Aliran data:

Aliran data membawa serangkaian item data mengenai peristiwa yang diprakarsai oleh terminator. Disimbolkan dengan anak panah pada DFD dan arah aliran ditunjukkan dengan arah panah. Panah, umumnya, diberi label kecuali jika diarahkan ke atau dari file data. Seperti yang ditunjukkan sebelumnya, aliran data antara dua terminator tidak termasuk dalam DFD dan dengan demikian, data tidak dapat mengalir langsung antara dua terminator.

(iii) Proses:

Proses mengubah data yang masuk untuk dialihkan ­ke penyimpanan data atau terminator. Itu dilambangkan dengan persegi panjang dengan sudut membulat atau lingkaran. Itu diberi label dengan kata kerja, tentu saja.

(iv) Penyimpanan data:

File adalah penyimpanan data dalam sistem informasi dan direpresentasikan dalam DFD dalam bentuk persegi panjang terbuka. Umumnya, mereka sesuai dengan tabel di database. Gambaran parsial diagram aliran data untuk pemrosesan pesanan penjualan disajikan pada Gambar 8.7.

Dapat dicatat bahwa beberapa simbol tambahan dan variasi kecil ­dalam simbol yang mewakili berbagai komponen DFD juga digunakan. Simbol di atas adalah yang paling umum digunakan dan sesuai dengan konvensi grafik yang disarankan oleh Gane dan Sarson.

Sering kali, seorang manajer menganggap menggambar DFD sangat sulit dan pengalaman yang membuat frustrasi. Setiap kali seseorang menggambar DFD, ia menemukan bahwa ada satu atau aspek lain dari aliran data yang diabaikan. Untungnya, alat KASUS yang tersedia memiliki fasilitas untuk membuat dan memodifikasi DFD. Namun, pemula disarankan untuk mengikuti langkah-langkah berikut untuk mengatasi masalah ini:

(a) Identifikasi semua aliran data input dan aliran data output secara terpisah bersama dengan terminator, letakkan aliran data input di sisi kiri dan aliran data output di sisi kanan.

(b) Beri label terminator menggunakan kata benda aliran data atau nama kata sifat.

(c) Mengidentifikasi proses maju dari aliran data input dan mundur dari aliran data output sampai bertemu di tengah.

(d) Beri label proses menggunakan nama kata kerja.

Seorang manajer harus siap menggambar ulang DFD karena sering kali, aliran data menjadi jelas bagi manajer hanya setelah menggambar DFD. Keterlibatan pengguna pada tahap ini sangat berguna tidak hanya dalam mengurangi upaya pihak manajer tetapi juga dalam meningkatkan DFD.

Pengujian DFD:

Disarankan bahwa DFD harus diuji secara menyeluruh sebelum diselesaikan. Berikut ini adalah beberapa ­kesalahan umum dalam desain DFD:

sebuah. Label terminator mungkin nama seseorang atau ­hadiah masuk, bukan kelas. Misalnya, terminator dapat diberi label sebagai M/s. BR Ltd. bukan vendor tunggal. Kesalahan lain bisa jadi pembawa ditempatkan sebagai terminator alih-alih entitas eksternal yang terkait langsung dengan aliran data.

  1. Data dapat mengalir langsung dari satu terminator ke terminator lainnya ­.
  2. Tidak ada aliran data yang dapat diindikasikan ke atau dari suatu proses.
  3. Aliran data ditunjukkan dari terminator ke penyimpanan data (file) atau dari file ke terminator, atau antara dua file tanpa pemrosesan.
  4. Proses diberi label sebagai objek, seperti faktur atau kata benda seperti petugas pemesanan.

Setelah DFD digambar untuk setiap sub sistem, detail pemrosesan di masa mendatang dapat ditulis dan dijelaskan dalam bahasa Inggris terstruktur (psedo-codes). Kode-psedo ini nantinya digunakan untuk pengkodean ­aplikasi. Peran manajer dalam proses ini terbatas hanya untuk membantu profesional sistem informasi dalam mengidentifikasi dan memahami algoritma yang terlibat dalam pemrosesan.

5. Modul Implementasi:

Modul ini terutama berkaitan dengan pengujian sistem, melatih ­pengguna dan instalasi sistem.

Menguji Sistem:

Pengujian berbagai modul dilakukan pada berbagai tahap ­proses pengembangan. Aturan emas yang harus diingat saat pengujian adalah bahwa pengujian harus dilakukan dengan maksud untuk mengidentifikasi cara-cara di mana sistem kemungkinan akan gagal. Seharusnya tidak dengan tujuan untuk membuktikan bahwa sistem akan bekerja sesuai dengan spesifikasi desain. Pengujian sistem adalah proses mencari jawaban atas dua pertanyaan dasar:

  1. Apakah sistem informasi melayani kebutuhan informasi perusahaan? Proses yang mencari jawaban atas pertanyaan ­ini disebut oleh para profesional sistem informasi sebagai proses validasi sistem.
  2. Apakah sistem informasi berfungsi dengan baik? Proses verifikasi mencari jawaban atas pertanyaan ini.

Karena sifat dan tingkat keseriusan kesalahan berbeda pada tahap pengembangan sistem yang berbeda, pengujian yang berbeda dilakukan ­pada modul yang berbeda dan pada sistem secara keseluruhan.

Tes unit:

Tes yang digunakan pada tingkat modul dapat disebut tes unit. Tes ini dilakukan untuk mendeteksi kesalahan pada antarmuka, basis data, operasi aritmatika, dan logika kontrol. Mereka dilakukan dengan ­menjalankan modul sistem informasi pada data uji yang dirancang khusus untuk menguji apakah sistem:

sebuah. Menerima tipe data yang salah (misalnya menerima nilai numerik untuk nama);

  1. Menerima dari rentang data yang valid (misalnya menerima tanggal dengan bulan lebih besar dari 12);
  2. Menyebabkan lompatan yang salah dari satu prosedur ke prosedur lain.

Tes sistem:

Karena pengujian unit dilakukan secara terpisah, ­pengujian integrasi harus dilakukan untuk memeriksa apakah unit ini bekerja dengan benar atau tidak sebagai sebuah kelompok. Karena keragaman sifat kesalahan, strategi pengujian yang berbeda harus diikuti untuk memeriksa validitas dan memverifikasi sistem. Fertuck menyarankan tiga strategi untuk menguji sistem informasi:

(a) Pengujian kotak bening:

Dalam strategi ini, pengujian dirancang untuk menentukan ­apakah prosedur yang diikuti untuk pemrosesan sesuai dengan persyaratan aplikasi. Hal ini dapat dicapai dengan bantuan review oleh sesama profesional sistem informasi yang tidak terkait langsung pada tahap pengembangan.

Sebagai alternatif ­, metode penelusuran terstruktur dapat digunakan. Dalam metode ini, sekelompok orang meninjau prosedur, pertama melihat bagian rawan kesalahan dan mengidentifikasi koreksi yang perlu dilakukan. Kemudian, anggota kelompok menilai keluaran yang akan ditawarkan sistem untuk jenis masukan tertentu dan menguji apakah keluaran sistem itu benar atau tidak.

(b) Pengujian kotak hitam:

Dalam strategi ini, sistem diuji untuk data yang tidak valid atau data yang dapat menyebabkan kesalahan dalam fungsi sistem. Output diperiksa untuk menentukan apakah ada kesalahan yang ­terjadi. Misalnya, data mungkin berisi nilai negatif untuk kuantitas yang dipesan atau nilai pecahan untuk variabel yang hanya dapat mengambil nilai keseluruhan.

(c) Pengujian kotak centang:

Strategi ini mengasumsikan bahwa tidak mungkin memberikan sistem informasi yang benar-benar bebas dari kesalahan. Dengan demikian, setelah semua pengujian dan modifikasi, perlu untuk memperkirakan jumlah kesalahan yang masih tersisa di sistem. Untuk memperkirakan jumlah ini, beberapa kesalahan mungkin sengaja dimasukkan ke dalam sistem. Kemudian tes kembali dilakukan untuk mendeteksi kesalahan.

Proporsi kesalahan yang diperkenalkan yang terdeteksi diambil sebagai perkiraan ­proporsi kesalahan nyata yang terdeteksi selama pengujian sebelumnya. Jadi, jika 90% dari kesalahan yang diperkenalkan terdeteksi selama pengujian kotak centang sementara total 450 kesalahan terdeteksi pada awalnya selama pengujian kotak kosong dan pengujian kotak hitam, itu berarti bahwa 50 kesalahan nyata tetap tidak terdeteksi di sistem.

Instalasi:

Instalasi adalah proses mengganti sistem lama dengan sistem baru. Secara umum, ada empat pendekatan untuk instalasi. Instalasi ‘dingin’ dilakukan ketika sistem lama segera dihentikan ­dan diganti dengan sistem baru.

Instalasi seperti itu memiliki keuntungan penyesuaian psikologis yang lebih cepat dengan fakta bahwa sistem baru akan digunakan. Namun, pendekatan seperti itu mungkin tidak sesuai jika data lama dari sistem sebelumnya berharga atau sistem baru memiliki beberapa masalah. Untuk menginstal sistem informasi akuntansi ­, pendekatan ini belum dapat diterima. Pendekatan alternatif meliputi:

(a) Instalasi percontohan:

Suatu sistem dapat diinstal untuk digunakan hanya oleh kelompok pengguna perwakilan terpilih yang menguji sistem dengan benar-benar menggunakannya. Pengguna lain terus menggunakan sistem lama. Ketika masalah dalam sistem teratasi, pengguna lain juga mulai menggunakan sistem. Pendekatan ini juga tidak terlalu populer untuk sistem informasi akuntansi karena seluruh ­basis data akuntansi harus diperbarui sebelum dapat digunakan oleh pengguna.

Persyaratan informasi pengguna melintasi batas departemen dan divisi dalam bagan organisasi. Namun, pendekatan ini dapat digunakan untuk entitas akuntansi yang lengkap seperti cabang, kantor wilayah, dll. Dengan demikian, sistem informasi akuntansi dapat digunakan oleh cabang-cabang tertentu. Setelah ditemukan bebas dari kesalahan, mereka dapat digunakan oleh cabang lain juga.

(b) Instalasi bertahap:

Di bawah pendekatan ini, instalasi berlangsung secara bertahap. Tahapan ini merupakan komponen independen dari sistem informasi. Jadi, siklus hidup pendapatan dari ­sistem informasi penghitungan akun mungkin pertama kali dipasang dan siklus hidup lainnya dapat mengikuti satu demi satu. Pendekatan ini membantu dalam memfokuskan pada bagian yang dipilih dari sistem. Ini membantu dalam meningkatkan penerimaan sistem di antara pengguna karena memungkinkan pengguna untuk mengatasi perubahan dengan mudah.

(c) Pemasangan paralel:

Instalasi paralel berarti menjalankan sistem lama dan baru secara bersamaan untuk jangka waktu tertentu sampai utilitas sistem baru terbukti. Metode ini paling populer untuk sistem informasi akuntansi karena ini yang paling aman dari semua metode lainnya. Satu-satunya kesulitan di sini adalah biaya lari paralel dan kecenderungan untuk memperpanjang periode lari paralel oleh mereka yang menolak perubahan.

Tinjauan Pasca Implementasi:

Setiap sistem harus ditinjau setelah implementasi selesai. Tinjauan semacam itu tidak hanya membantu mengidentifikasi kelemahan sistem tetapi juga menyiapkan agenda untuk modifikasi di masa mendatang. Sebenarnya, ini adalah proses belajar. Audit sistem juga dapat dilakukan untuk menguji seberapa sukses sistem tersebut, dalam hal biaya, jadwal pengiriman, kelengkapan dan kualitas.

Related Posts