PERENCANAAN SISTEM DAN ANALIS SISTEM SECARA UMUM

PERENCANAAN SISTEM DAN ANALIS SISTEM

Sekarang kita siap untuk memulai pembahasan kita tentang SDLC. Sebuah tahap dalam SDLC pada batas tertentu ditingkatkan oleh teknik-teknik yang di-diskusikan dalam bagian sebelumnya. Dalam praktiknya, sebagian dipengaruhi oleh teknik lainnya, tetapi tidak ada yang hanya bergantung pada teknik-teknik ini. Oleh karena itu, kita akan memperlakukan masalah SDLC secara konseptual. Yaitu, fokus kita lebih pada apa yang dilakukan, bukan pada bagaimana dilakukannya. Sisa bab ini akan diberikan untuk tiga tahap pertama dalam SDLC (lihat Gambar 13-10). Dalam bagian ini, kita akan mempelajari tahap satu dan dua ­-- perencanaan sistem dan analisis sistem. Kita akan mempelajari tahap ketiga SDLC -- desain sistem konseptual-dalam bagian terakhir.

Perencanaan Sistem

Tujuan perencanaan sistem adalah untuk menghubungkan proyek-proyek atau aplikasi­aplikasi sistem individual dengan tujuan-tujuan strategis. Pada kenyata-annya, basis untuk perencanaan sistem adalah perencanaan bisnis organisasi, yang menspesifikasi ke mara arah rencana-rencana perusahaan dan bagaimana perusaha-an akan mewujudkannya. Gambar 13-11 menyajikan relasi di antara rencana-rencana ini dan tujuan strategis perusahaan. Harus ada kecocokan antara proyek-proyek individual dan rencana bisnis, atau perusahaan tidak akan mencapai tujuannya. Perencanaan sistem yang efektif akan memberikan kecocokan tujuan ini.

Siapa yang Harus Merencanakan Sistem?

Kebanyakan perusahaan yang melakukan perencanaan sistem dengan serius membentuk sebuah komite pengawas (steering committee) untuk memberikan pe-tunjuk dan mengkaji sta­tus proyek-proyek sistem. Komposisi dari sebuah komite pengawas dapat terdiri atas seorang pejabat kepala eksekutif, pejabat kepala ke-uangan, pejabat kepala informasi, manajemen senior dari wilayah pemakai, auditor internal, dan manajemen senior dari jasa komputer. Komite ini bisa juga memasuk-kan pihak-pihak luar, seperti konsultan manajemen dan audi­tor eksternal perusaha-an. Tanggung jawab tipikal untuk sebuah komite pengawas antara lain:

1. Menentukan konflik-konflik yang timbul dari sistem baru.
2. Mengkaji proyek-proyek dan menetapkan prioritas.
3. Dana anggaran untuk pengembangan sistem.
4. Mengkaji status proyek-proyek individual yang sedang dikembangkan.
5. Menentukan berbagai titik pengecekan di seluruh SDLC, apakah akan menerus-kan proyek tersebut atau menghentikannya.

Perencananan sistem terjadi pada dua tingkat: perencanaan sistem strategis dan perencanaan proyek.

Perencanaan Sistem Strategis

Perencanana sistem strategis melibatkan alokasi sumber daya sistem di tingkat makro. Aktivitas ini biasanya dilakukan dalam kerangka waktu tiga sampai lima tahun. Prosesnya sangat mirip dengan penganggaran sumber daya untuk akti-vitas strategis lainnya, seperti misalnya pengembangan produk, perluasan pabrik, riset pasar, dan teknologi manufaktur.

Secara teknis, perencanaan sistem strategis bukan merupakan bagian dari SDLC karena SDLC berkaitan dengan aplikasi tertentu. Perencanaan sistem strategis berkenaan dengan alokasi sumber daya sistem, seperti karyawan (jumlah profesional sistem yang akan dipekerjakan), perangkat keras (jumlah stasiun kerja, komputer-mini, dan mainframe yang akan dibeli), perangkat keras (dana yang di-alokasikan ke proyek-proyek sistem dan untuk pemeliharaan sistem), dan tele-komunikasi (dana yang dialokasikan ke jaringan kerja dan Pertukaran Data Elektronis atau Electronic Data Interchanges-EDI). penting sekali untuk diingat bahwa sebaik-nya perencanaan strategis jangan terlalu rind. Perencanaan itu harus memungkinkan spesialis sistem mengambil keputusan-keputusan yang bermutu dengan mempertim-bangkan faktor-faktor relevan seperti harga, penilaian kinerja, ukuran, keamanan, dan kontrol.

Mengapa Melakukan Perencanaan Sistem Strategis?

Mungkin tidak ada aspek aktivitas bisnis perusahaan yang begitu rentan dan tidak dapat diduga seperti perencanaan sistem informasi. Siapa yang dapat melihat lima tahun ke depan dan secara akurat memperkirakan keadaan teknologi sistem? Karena kerentanan ini, setiap rencana jangka panjang yang dilakukan perusahaan selalu ada kemungkinan berubah. Oleh karena itu, bagaimana sebuah perusahaan dapat melakukan perencanaan sistem strategis? Mengapa perusahaan harus me-lakukannya?

Ada tiga pembenaran untuk perencanaan sistem strategis:

1. Sebuah rencana yang berubah secara konstan lebih baik daripada tidak ada rencana sama sekali. 
2. Perencanaan strategis mengurangi komponen-komponen krisis dalam pengem-bangan sistem. 
3. Perencanaan sistem strategis menyediakan kontrol otorisasi untuk SDLC.

Perencanaan Proyek

Tujuan perencanaan proyek adalah untuk mengalokasi sumber daya pada aplikasi-aplikasi individual di dalam kerangka perencanaan strategis. Hal ini melibatkan pengidentifikasian wilayah-wilayah kebutuhan pemakai, menyiapkan proposal, meng-evaluasi setiap kelayakan proposal dan sumbangannya bagi perencanaan bisnis, memprioritaskan proyek individual, menjadwalkan pekerjaan yang harus dilakukan. Produk dalam tahap ini terdiri atas dua dokumen resmi: proposal proyek dan jadwal proposal.

Sisa bagian ini akan membahas perencanaan proyek, yang di dalamnya terdiri atas:

1. Mengenal masalah.
2. Mendefinisikan masalah.
3. Menentukan tujuan-tujuan sistem.
4. Menentukan kelayakan proyek.
5. Menyiapkan proposal proyek formal.
6. Mengevaluasi dan memprioritaskan proposal-proposal yang saling bersaing. 
7. Menghasilkan sebuah jadwal proyek.
8. Mengumumkan proyek sistem yang baru.

Peran Akuntan Dalam Perancanaan Sistem

Selama proses perencanaan, para akuntan diminta memberikan advice dalam mengevaluasi kelayakan sebuah proyek. Keahlian ini diperlukan untuk menspesifikasi aspek-aspek kelayakan ekonomi dan hukum. Peran mereka sebagai auditor, para akuntan harus mempelajari tahap perencanaan sistem dari SDLC secara rutin. Sejarah telah menunjukkan bahwa sistem yang direncanakan dengan hati-hati men-jadi suatu teknik kontrol yang efektif dalam proses pengembangan sistem. Peren-canaan akan mengurangi risiko yang dihasil sistem yang tidak diperlukan, tidak di-inginkan, tidak efisien, dan tidak efektif. Para akuntan internal dan eksternal ber-kepentingan untuk memastikan bahwa perencanaan sistem yang memadai telah dilakukan.

Analis Sistem

Analisis sistem pada kenyataannya merupakan proses dua langkah yang melibatkan, pertama, survei terhadap sistem yang ada saat ini, dan kemudian, analisis kebutuhan pemakai. Masalah­masalah bisnis harus sepenuhnya dipahami oleh analis sistem sebelum dia dapat merumuskan sebuah solusi. Analisis yang tidak lengkap atau cacat akan menghasilkan solusi yang tidak lengkap atau cacat. Oleh karena itu, analisis sistem menjadi dasar bagi seluruh proses SDLC.

Produk yang dihasilkan tahap ini adalah sebuah laporan analisis sistem formal, yang menyajikan temuan-temuan analisis dan rekomendasi untuk sistem yang baru.

Langkah Survei

Kebanyakan sistem tidak dikembangkan dari nol. Biasanya, sebagian bentuk sistem informasi dan prosedur-prosedur yang berkaitan dengannya sudah ada. Analis sering kali memulai analisis dengan menentukan elemen-elemen mana, jika ada, dari sistem saat ini yang harus dipertahankan sebagai bagian dari sistem baru. Hal ini melibatkan sebuah survei sistem yang agak rind. Fakta-fakta yang berkaitan dengan pertanyaan-pertanyaan pendahuluan tentang sistem tersebut dikumpulkan dan dianalisis. Ketika analis mendapatkan pemahaman yang lebih mendalam tentang masalah-masalah, dia mengembangkan pertanyaan-pertanyaan yang lebih spesifik tentang fakta-fakta yang harus dikumpulkan. Proses ini akan mengalami beberapa pengulangan penekanan. Ketika semua fakta relevan telah dikumpulkan dan dianalisis, analis sampai pada penilaian terhadap sistem saat ini. Mensurvei sistem yang digunakan saat ini memiliki keunggulan sekaligus kelemahan.

Kelemahan Mensurvei Sistem yang Digunakan Saat Ini

Argumentasi yang mungkin paling kuat menentang survei terhadap sistem yang digunakan saat ini terletak pada fenomena yang disebut current physical tar pit. Yaitu, kecenderungan analis untuk "tenggelam" dan kemudian "dihambat" oleh pekerjaan mensurvei sistem yang digunakan saat ini.

Sebagian orang berpendapat bahwa survei sistem menghambat ide-ide baru. Dengan mempelajari dan membuat model dari sistem lama, analis dapat mengem-bangkan sebuah pendapat yang terbatas ten tang bagaimana sistem baru seharus-nya berfungsi. Salah satu contohnya adalah implementasi sistem ERP. Tugas untuk mempelajari prosedur organisasi saat ini bisa jadi tidak bermanfaat apa-apa karena keberhasilan implementasi ERP bergantung pada rekayasa teknologi terhadap proses-proses ini untuk menerapkan praktik bisnis terbaik dalam industri.

Keunggulan Mensurvei Sistem yang Digunakan Saat Ini

Ada tiga keunggulan dalam mempelajari sistem saat ini. Pertama, tindakan ini merupakan salah satu jalan untuk mengidentifikasi aspek-aspek sistem lama yang harus dipertahankan. Sebagian elemen dari sistem ini mungkin masih berfungsi baik dan dapat menjadi dasar bagi sistem yang baru. Dengan sepenuhnya memahami sistem yang di-gunakan saat ini, analis dapat mengidentifikasi aspek-aspek yang berharga untuk diper-tahankan atau memodifikasinya untuk digunakan dalam sistem yang baru.

Kedua, ketika sistem baru diimplementasikan, pemakai harus menjalani pro-ses konversi di mana mereka dengan resmi memutuskan hubungan dengan sistem lama dan beralih ke sistem baru. Analis harus menentukan pekerjaan-pekerjaan, prosedur, dan data yang akan dibuang dari sistem lama dan mana yang akan diteruskan. Untuk men-spesifikasi prosedur konversi ini, analis harus mengetahui tidak hanya apa yang akan dilakukan oleh sistem baru, tetapi juga apa yang telah dilakukan oleh sistem lama. Hal ini memerlukan pemahaman yang menyeluruh terhadap sistem yang ada saat ini.

Akhirnya, dengan mensurvei sistem yang digunakan saat ini, analis dapat me-nentukan secara meyakinkan penyebab dari gejala-gejala masalah yang dilaporkan. Mungkin akar masalahnya bukan dalam sistem informasi; mungkin merupakan masalah manajemen dan karyawan yang dapat dipecahkan tanpa perlu mendesain kembali sistem informasi. Mungkin saja kita jadi tidak bisa mengidentifikasi penyebab utama masalah jika kita membuang sistem yang digunakan saat ini tanpa terlebih dulu memeriksa gejala-gejala tersebut.

Setelah tahap pengumpulan fakta, analis dengan resmi mendokumentasikan kesan-kesan dan pemahamannya tentang sistem tersebut. Tindakan ini dapat berupa catatan, diagram arus sistem, dan berbagai tingkat DAD.

Langkah Analisis

Analisis sistem merupakan sebuah proses intelektual yang dilakukan ber-samaan dengan pengumpulan fakta. Analis secara simultan melakukan analisis ketika dia mengumpulkan fakta. Hanya mengetahui adanya masalah saja menunjukkan adanya pemahaman akan norma atau situasi yang diinginkan. Oleh karena itu sulit untuk menentukan di titik mana survei akan berakhir dan analisis dimulai.

Laporan Analisis Sistem

Peristiwa yang menandai ditutupnya tahap analisis sistem adalah persiapan sebuah laporan analisis sistem formal. Laporan ini menyajikan temuan survei, masalah yang diidentifikasi, kebutuhan pemakai, dan kebutuhan sistem baru, kepada pihak manajemen atau komite pengawas. Gambar 13-5 berisi format yang mungkin untuk laporan ini. Tujuan utama melakukan analisis sistem adalah untuk meng-identifikasi kebutuhan pemakai dan menentukan kebutuhan sistem baru. Laporan ini harus ditulis dengan rinci tentang apa yang harus dilakukan sistem, bukan bagai-mana melakukannya. Pernyataan dalam laporan tersebut membentuk saling pe-ngertian antara profesional sistem, pihak manajemen, pemakai, dan stakeholders lainnya. Laporan analisis sistem ini harus dituliskan dengan istilah-istilah yang jelas untuk sumber data, pemakai, file data, proses umum, arus data, kontrol, dan kapa-sitas volume transaksi.

Peran Akuntan Dalam Analisis Sistem

Akuntan memiliki latar belakang dan mendapatkan pelatihan untuk secara signifikan berperan dalam proses analisis sistem. Sebagai langkah pendahuluan untuk setiap audit keuangan, para akuntan mensurvei sistem untuk memahami elemen penting dari suatu sistem. Pengalaman dan pengetahuan akuntan menjadi sumber berharga bagi analis sistem. Pemahaman akuntan terhadap kebutuhan infor-masi pemakai akhir, standar kontrol internal, kebutuhan jejak audit, dan prosedur dimandatkan jelas merupakan tugas-tugas penting untuk menentukan persyaratan sistem yang baru.

Auditor perusahaan (eksternal dan internal) adalah stakeholders dalam sistem yang diusulkan. Oleh karena itu, akuntan/auditor harus terlibat dalam analisis kebutuhan untuk sistem yang diusulkan.

E. DESAIN SISTEM KONSEPTUAL

Tujuan tahap desain konseptual adalah menghasilkan beberapa sistem kon-septual alternatif yang telah diidentifikasi selama analisis sistem. Dengan menyajikan sejumlah alternatif yang masuk akal, profesional sistem terhindar dari batasan-batas-an yang sudah diduga sebelumnya pada sistem baru. Pemakai akan mengevaluasi dan menetapkan alternatif. Bagian ini menjelaskan dua pendekatan untuk desain sistem konseptual: pendekatan desain terstruktur dan pendekatan desain yang berorientasi-objek. 

Pendekatan Desain Terstruktur

Pendekatan desain terstruktur merupakan sebuah cara yang disiplin untuk mendesain sistem dari atas ke bawah. Pendekatan ini dimulai dari gambar besar" sistem yang diusulkan, yang sedikit demi sedikit diuraikan atau didekomposisikan ke dalam bagian sistem yang lebih rind dan lebih rinci lagi sampai semuanya dimengerti sepenuhnya. Dengan pendekatan ini, proses bisnis yang sedang dirancang biasanya didokumentasikan menurut arus data dan diagram data (telah didiskusikan sebelum-nya dalam bab ini). Gambar 13-16 menunjukkan penggunaan teknik ini untuk menggambarkan dekom-posisi atas-bawah dari proses bisnis hipotetis.

Gambar 13-17 menunjukkan dua desain konseptual alternatif untuk sistem pem-belian. Desain ini kurang memiliki rincian yang diperlukan untuk mengimplementasikan sistem. Misalnya, mereka tidak memasukkan komponen-komponen yang diperlukan seperti: 

• Struktur record database.
• Rincian pemrosesan.
• Teknik-teknik kontrol spesifik.
• Format untuk layar input dan dokumen sumber.
• Format laporan output.

Pendekatan Desain Yang Berorientasi-Objek

Pendekatan desain yang berorientasi objek adalah untuk membangun sebuah sistem informasi dari komponen atau objek standar yang dapat digunakan berulang kali. Pendekatan ini bisa disamakan dengan proses pembuatan sebuah mobil. Para pabrikan mobil tidak menbuat sistem-sistem baru dari nol. Kenyataannya, model-model baru dibuat dari komponen standar yang juga digunakan untuk model lain. Misalnya, setiap model mobil yang dihasilkan oleh pabrikan tertentu biasanya meng-gunakan mesin, kotak-gigi, alternator, paras roda, radio, dan lain-lain yang jenisnya sama. Sebagian komponen-komponen merupakan produk standar industri yang digunakan oleh pabrikan lainnya. Produk-produk seperti roda, ban, busi, dan lampu besar termasuk dalam kategori ini. Pada kenyataannya, komponen yang benar-benar dibuat dari not untuk sebuah model mobil baru adalah kerangka mobilnya.

Elemen-elemen Pendekatan Desain yang Berorientasi-Objek

Karakteristik distingtif dari pendekatan desain yang berorientasi objek adalah baik data dan logika pemrograman, seperti uji integritas, peraturanakuntansi, dan prosedur pembaruan data, dilambangkan dalam modul-modul untuk mewakili objek. Diskusi berikut ini berkenaan dengan elemen-elemen utama dari pendekatan ini.

Objek. Objek ekuivalen dengan kata benda dalam Bahasa Inggris. Misalnya, pemasok, pelanggan, persediaan, dan akun-akun, semuanya merupakan objek. Objek-objek ini memiliki dua karakteristik: atribut dan operasi. Atribut-atribut ekuivalen dengan kata sifat (adjektif) dalam Bahasa Inggris dan menjelaskan objek. Operasi ekuivalen dengan kata kerja dan menunjukkan tindakan-tindakan yang dilakukan Pada objek dan dapat mengubah atribut­atribut mereka. Gambar 13-18 mengilustrasikan karakteristik dengan sebuah contoh non­keuangan. Objek dalam contoh ini adalah mobil yang atributnya adalah membuat, model, tahun, ukuran me sin, jarak mil, dan warna. Operasi (juga disebut metode-metode) yang dapat dilakukan terhadap objek ini adalah mengemudi, memarkir, mengunci, dan mencuci. Perhatikan bahwa jika kita melakukan operasi mengemudi Pada objek tersebut, atribut jarak mil akan berubah.

Gambar 13-19 mengilustrasikan poin-poin ini dengan sebuah contoh akun-tansi persediaan. Contoh ini, objeknya adalah persediaan dan atributnya adalah nomor suku cadang, keterangan, kuantitas di tangan, titik pemesanan kembali, dan nomor pemasok. Kegiatan operasi ini yang dapat dilakukan Pada persediaan adalah mengurangi persediaan (dari penjualan produk), memeriksa kuantitas di tangan yang tersedia, dan titik pemesanan kembali persediaan (ketika jumlah kuantitas di tangan kurang dari titik pemesanan kembali). Perhatikan kembali bahwa melakukan setiap kegiatan operasi tersebut akan mengubah atribut kuantitas di tangan

Kelas dan Contoh (Instances). Sebuah kelas objek adalah pengelompokan logis untuk objek-­objek individual yang atribut dan kegiatan operasinya sama. Contoh adalah peristiwa tunggal dari sebuah objek dalam sebuah kelas. Misalnya, Gambar 13-20 menunjukkan kelas persediaan yang terdiri atas beberapa contoh atau jenis persediaan spesifik.

Warisan. Warisan berarti bahwa setiap contoh objek mewarisi atribut dan operasi dari kelasnya. Misalnya, semua contoh dalam hierarki kelas persediaan memiliki atribut nomor suku cadang, keterangan, dan kuantitas di tangan. Atribut-atribut ini akan didefinisikan sekali dan hanya sekali untuk objek persediaan. Jadi, contoh objek, penghubung roda, pompa air, dan alternator akan mewarisi atribut-atribut ini. Sebaliknya, contoh ini akan mewarisi operasi (mengurangi, memeriksa, memesan kembali, dan menggantikan) yang didefinisikan untuk kelas tersebut.

Kelas-kelas objek dapat juga mewarisi dari kelas objek lainnya. Misalnya, Gambar 13-21 menunjukkan suatu hierarki objek yang dibuat dari kelas objek yang disebut kontrol dan tiga sub-subkelas yang disebut utang dagang, piutang dagang, dan persediaan.

Ketiga sub-subkelas objek tersebut memiliki kesamaan dalam operasi kontrol tertentu. Misalnya, tidak ada akun yang diperbarui tanpa pertama-tama memverifikasi kunci primer (yaitu, No. Pemasok, No.Pelanggan, dan No. Suku Cadang) dari record yang sedang diperbarui. Operasi ini (dan lainnya) dapat ditentukan untuk objek kontrol (sekali saja dan hanya sekali saja) dan kemudian diwariskan ke semua sub-kelas objek yang menerapkan metode ini.

Diagram Relasi Entitas

Diagram Relasi Entitas (RE) sebagai teknik dokumentasi untuk desain database yang juga digunakan untuk menampilkan sistem yang berorientasi pada objek. Gambar 13-22 mengilustrasikan penggunaan diagram RE untuk menggambarkan desain berorientasi-objek untuk sebuah sistem pesanan penjualan.

Berikut ini adalah langkah-langkah yang menjelaskan proses tersebut:

• Setiap pelanggan menempatkan satu atau lebih pesanan pelanggan.
• Banyak pesanan (dalam batches) memulai proses transaksi.
• Satu atau lebih item persediaan diambil dari persediaan dan dikirim ke setiap pelanggan. 
• Proses transaksi memperbarui banyak record akuntansi dan menyiapkan banyak faktur.
• Record akuntansi dan objek dalam faktur mewarisi banyak atribut kontrol dan operasi dari objek kontrol.
• Satu atau lebih faktur dikirimkan ke setiap pelanggan.

Pada tahap implementasi dalam SDLC, pemrogram yang menggunakan program yang berorientasi-objek (objek-oriented programming--OOP) akan memrogramkan atribut. atribut dan operasi-operasi yang membentuk modul-modul objek yang ditampilkan dalam diagram RE. Modul-modul yang dihasilkan itu akan memberi lambang pada atribut-atribut dan operasi yang unik bagi kelas objek. Misalnya, mengacu ke Gambar 13-22 dan Langkah 5, operasi kontrol diperlukan oleh objek-objek yang memperbarui record piutang dagang dan persediaan dan menyiapkan faktur yang diwariskan dari modul objek kontrol.

Karena desain berorientasi objek mendukung tujuan dapat digunakan berulang kali, bagian sistem atau seluruh sistem, dapat diciptakan dari modul-modul yang se-belumnya sudah ada. Misalnya, setiap sistem di masa depan yang mensyaratkan atribut-atribut kontrol dan operasi yang ditentukan menurut modul kontrol yang sudah ada (rnisalnya, menverifikasi kunci primer sebelum memperbarui record) dapat mewariskan operasi ini. Pendekatan desain berorientasi objek juga mempromosikan kemudahan pemeliharaan. Perubahan tunggal pada atribut atau operasi dalam satu kelas objek secara otomatis mengubah semua contoh objek dan sub-subkelas yang mewarisi atribut tersebut.

Peran Akuntan Dalam Desain Sistem Konseptual

Akuntan berperan penting dalam mendesain sistem secara konseptual. Men-desain sebuah SIA mempakan upaya bersama antara fungsi akuntansi dari sebuah organisasi dan profesional sistem. Akuntan bertanggung jawab untuk sistem konseptual (ams informasi logis), dan profesional sistem bertanggung jawab untuk sistem fisik (pekerjaan teknis untuk membangun sistem). Jika pertimbangan­pertimbangan akuntansi yang penting tidak dikonseptualisasikan Pada titik ini, mereka bisa benar-benar diabaikan, nantinya berpotensi menghadapkan organisasi Pada kemgian finansial dan litigasi (proses hukum). Sementara berpartisipasi dalam proses desain konseptual, akuntan harus menyadari bahwa setiap sistem alternatif harus dikontrol secara memadai, jejak audit harus dilestarikan, dan konvensi-konvensi akuntansi dan persyaratan hukum harus dipahami. Ini tidak berarti bahwa masalah ini harus dispesifikasi secara rinci pada titik ini. Melainkan maksudnya adalah, bahwa mereka harus dikenal sebagai item-item yang diperhatikan selama tahap desain terperinci dalam sistem tersebut.

Auditor mempakan stakeholder dalam semua sistem keuangan dan, karenanya, memiliki kepentingan dalam tahap desain konseptual dari sistem tersebut. Auditabilitas sebuah sistem sebagian bergantung Pada karakteristik desainnya. Sebagian teknik-teknik audit komputer mensyaratkan bahwa sistem didesain dengan fitur-fitur audit spesial yang menyatu dengan sistem tersebut. Untuk sistem-sistem seperti itu, fitur-fitur audit ini harus dimasukkan dalam desain konseptual.

PERENCANAAN SISTEM DAN ANALIS SISTEM SECARA UMUM 2017-03-20T09:45:00-07:00 Rating: 4.5 Diposkan Oleh: frf