SISTEM INFORMASI AKUNTANSI DAN PENGANTAR PENGEMBANGAN SISTEM

SISTEM INFORMASI AKUNTANSI DAN PENGANTAR PENGEMBANGAN SISTEM

A. PENDAHULUAN

Salah satu harta yang paling berharga bagi organisasi bisnis modern adalah sebuah sistem informasi yang berorientasi pada pemakai dan responsif. Sebuah sistem yang dirancang dengan baik dapat meningkatkan produktivitas, mengurangi persediaan, menghilangkan aktivitas yang tidak menambah nilai, memperbaiki pela-yanan pelanggan dan keputusan manajemen, dan mengkoordinasi aktivitas-aktivitas di seluruh organisasi.

Modul ini terdiri dari beberapa topik yang saling berkaitan.

• Pertama, memperkenalkan siklus hidup pengembangan sistem (systems develop-ment life cycle -- SDLC). Prosedur dengan banyak tahap ini digunakan untuk mengarahkan pengembangan sistem informasi dalam organisasi.
• Kedua mempelajari dua teknik otomatis yang memperbaiki proses pengembang-an sistem. Teknik ini menghasilkan prototipe dan hasil dari rekayasa teknologi perangkat lunak yang dibantu dengan komputer.
• Ketiga menjelaskan tujuan dan kegiatan yang berkaitan dengan dua tahap pertama dalam proses SDLC perencanaan sistem dan analisis sistem

B. PENGEMBANGAN SISTEM IN-HOUSE

Biasanya organisasi mendapatkan sistem informasi dalam dua cara: 

1. Mengembangkan sistem in-house yang dibakukan melalui aktivitas pengem-bangan sistem formal. 
2. Membeli sistem komersial dari pemasok-pemasok perangkat lunak. 

Pemasok komersial menawarkan sistem informasi umum berkualitas tinggi. Pemasok ini melayani kebutuhan generik organisasi. Biasanya, klien telah memiliki praktik bisnis yang standar sehingga dapat membeli sistem informasi yang sebelum-nya sudah dirancang dan menggunakannya tanpa modifikasi. Namun, banyak orga-nisasi memerlukan sistem yang sesuai kegiatan spsesifik operasional. Perusahaan ini merancang sistem informasi melalui pengembangan sistem in-house.

Siklus Hidup Pengembangan Sistem

Beberapa perusahaan memiliki sebuah kelompok servis komputer internal yang merancang sistem komputer menurut pesanan (kebutuhan) untuk memenuhi kebutuhan spesifik sistem informasi organisasi. Sistem ini melalui proses formal yang disebut siklus hidup pengembangan sistem (systen development life cycle -- SDLC), seperti dalam Gambar 13-1

Suatu SDLC secara logis dan umum diterima oleh para ahli komunitas sistem. Namun, jumlah dan nama tahapan proses ini masih diperdebatkan. SDLC dengan paling sedikit 4 sampai paing banyak 14 aktivitas. Dari perspektif akuntansi, jumlah tahapan aktual tidak terlalu penting. Terpenting adalah pada substansi dan konsis-tensi aplikasi dari proses. SDLC Gambar 13-1 merupakan sebuah proses tujuh tahap yang terdiri dua tahap utama: pengembangan sistem dan pemeliharaan sistem.

v Pengembangan Sistem Baru

Enam tahap pertama SDLC merupakan aktivitas yang harus dijalani oleh semua sistem baru. Pengembangan sistem baru melibatkan lima langkah: mengidentifi-kasi masalah, memahami apa yang telah dilakukan, mempertimbangkan solusi alternatif, memilih solusi terbaik dan menerapkan solusi. Setiap tahap SDLC menghasilkan dokumentasi yang menandai diselesaikannya tahap tersebut.

v Pemeliharaan

Ketika sistem sudah diimplementasi, sistem tersebut memasuki tahap kedua dari siklus hidupnya -- pemeliharaan. Pemeliharaan (maintenance) berarti mengubah sistem untuk mengakomodasi perubahan dalam kebutuhan pemakai. Misalnya memodifikasi sistem untuk menghasilkan sebuah laporan baru atau mengubah panjang field data. Pemeliharaan dapat lebih luas dari itu, misalnya melakukan perubahan besar pada logika aplikasi dan alat penghubung sistem (interface) yang dimiliki pemakai. Periode pemeliharaan sistem dari SDLC dapat bertahan dari 5 - 10 tahun. Namun, bisnis yang menanggapi perubahan secara berkala dalam teknologi atau proses bisnis memiliki kehidupan sistem yang lebih pendek. 

Pemeliharaan mewakili pengeluaran sumber daya yang signifikan dibanding biaya pengembangan awal. Selama masa hidup sebuah sistem, 80 sampai 90 persen dari total biayanya terserap dalam tahap pemeliharaan. 

Front End dan Back End

Empat tahap pertama SDLC disebut aktivitas front end. Kegiatan tersebut berkaitan dengan apa yang harus dilakukan oleh sistem tersebut. Tiga tahap pertama adalah aktivitas back end. Tahap ini berkaitan dengan masalah teknis tentang bagaimana sistem fisik akan mencapai tujuannya.

Pihak-pihak yang Terlibat dalam Pengembangan Sistem

Pihak yang terlibat dalam pengembangan sistem diklasifikasikan dalam tiga kelompok besar : profesional sistem, pemakai akhir, dan stakeholders.

• Profesional sistem adalah analis sistem, desainer sistem, dan pemrogram. Inilah yang membangun sebuah sistem. Mengumpulkan fakta tentang masalah sistem saat ini, menganalisa fakta-fakta, dan merumuskan solusi untuk me-mecahkan masalah. Hasilnya adalah sebuah sistem baru.
• Pemakai akhir adalah mereka yang menjadi tujuan dibangunnya sistem. Ada banyak pemakai di semua tingkatan organisasi. Seperti para manajer, personel operasi, akuntan, dan auditor internal. Hampir semua personel dalam organisasi adalah pemakai sistem. 
• Stakeholders adalah individu yang terdapat di dalam maupun luar organisasi, yang memiliki kepentingan terhadap sistem tersebut tetapi bukan merupakan pemakai akhir. Seperti para akuntan, auditor internal, auditor eksternal, dan komite pengawas internal yang mengawasi pengernbangan sistem-sistem tersebut.

Mengapa Para Akuntan Terlibat dalam SDLC?

Proses SDLC menjadi kepentingan para akuntan untuk dua alasan.

• Pertama, sebuah sistem informasi mewakili sebuah transaksi keuangan yang mengkonsumsi sumber daya keuangan dan manusia. Pengembangan sistem seperti proses manufaktur yang memproduksi sebuah produk melalui serangkaian tahapan. Transaksinya direncanakan, diotorisasi, dijadwalkan, dipertanggung-jawabkan, dan dikontrol. Akuntan berkepentingan terhadap integritas proses ini seperti setiap proses manufaktur yang memiliki implikasi sumber daya keuangan.
• Kedua, perhatian akuntan adalah kualitas sistem informasi akuntansi sebagai aktivitas produksi SDLC. Sistem ini digunakan untuk mengirimkan informasi akun-tansi kepada pemakai internal dan eksternal. Tanggung jawab akuntan adalah me-mastikan bahwa sistem tersebut menerapkan dengan benar konvensi dan per-aturan akuntansi, dan memiliki kontrol yang memadai. Sehingga, akuntan berke-pentingan terhadap kualitas proses yang menghasilkan sistem informasi akuntansi.

Bagaimana Para Akuntan Terlibat dalam SDLC?

Para akuntan terlibat dalam pengembangan sistem dalam tiga cara. 

• Pertama, akuntan adalah pemakai sistem. Semua sistem yang memproses trans-aksi keuangan dalam batas tertentu mempengaruhi fungsi akuntansi. Seperti pemakai lainnya, akuntan harus menggambaran dengan jelas tentang masalah dan kebutuhan mereka kepada profesional sistem. Misalnya, para akuntan harus menentukan teknik akuntansi yang digunakan, persyaratan ke-butuhan internal (seperti jejak audit), dan algoritma khusus (seperti model-model penyusutan).
• Kedua, para akuntan berpartisipasi dalam pengembangan sistem sebagai ang-gota dari tim pengembangan. Sistem yang tidak memproses transaksi keuangan tetap dapat mengambil data akuntansi. Para akuntan bisa diminta keterangannya untuk memberikan nasihat atau untuk menentukan jika sistem yang diusulkan ternyata berisiko kontrol internal.
• Ketiga, akuntan yang terlibat dalam pengembangan sistem sebagai auditor. Sistem informasi akuntansi harus bisa diaudit. Sebagian teknik audit memerlukan fitur-fitur spesifikasi yang harus didesain ke dalam sistem. Auditor/akuntan memiliki kepentingan dalam sistem seperti itu dan harus terlibat sejak awal pembuatannya.

C. PENGEMBANGAN SISTEM MELALUI OTOMATISASI

Proyek pengembangan sistem tidak selalu merupakan cerita sukses. Kenyata-annya, pada saat diimplementasikan, sebagian sistem menjadi usang atau rusak dan harus diganti. SDLC mengalami tiga masalah penyebab kegagalan sebagian besar sistem. Masalah-masalah tersebut didiskusikan di bawah ini.

1. Persyaratan sistem yang tidak dispesifikasi dengan baik. Pengembangan sistem melibatkan komunikasi manusia dan saling menukar gagasan antara pemakai dan profesional sistem. Pertukaran informasi ini sering terjadi tidak sempurna. Ke-salahan sering dilakukan dalam usaha mengidentifikasi masalah dan kebutuhan. Gagasan baru timbul ketika sifat baru dan masalah tersingkap, dan orang dapat mudah berubah pikiran tentang apa yang mereka inginkan dan butuhkan dari sistem tersebut.

Karena ketidakpastian ini, SDLC cenderung merupakan proses yang lancar, lurus, di mana satu tahap diselesaikan sebelum melangkah ke tahap baru. Dalam kenyataannya, proses tersebut bersifat siklis dan berulang. Dengan sifat siklis ini, suatu langkah awal yang salah akan banyak menghabiskan waktu, banyak kerja berulang, dan tekanan dari segala penjuru, mendesak agar pekerjaan tersebut cepat selesai. Sering kali, hasilnya adalah sistem yang dirancang secara buruk, anggaran berlebih, dan terlambat dari jadwal yang sudah ditentukan.

2. Teknik-teknik pengembangan sistem yang tidak efektif. Masalah yang dijelaskan di atas menjelaskan teknik yang tidak efektif untuk menyajikan, mendokumen-tasikan, dan memodifikasi spesifikasi sistem. Dalam skenario yang paling buruk, perangkat pengembangan sistem hanya berupa selembar kertas, pensil, penggaris, dan penghapus. Situasi ini diperbaiki dengan adanya perangkat lunak gratis yang berbasiskan PC (Personal Computer), yang memungkinkan pembuat-an desain awal dan perubahannya dilakukan secara elektronik. 

3. Kurangnya keterlibatan pemakai dalam pengembangan sistem. Pengembangan sistem komputer dianggap wilayah eksklusif dari para profesional sistem. Para memakai (termasuk akuntan) melepaskan tanggung jawab mereka untuk desain sistem. Hal ini juga menimbulkan masalah bisnis karena desain sistem men-cerminkan persepsi analis terhadap kebutuhan informasi, bukannya persepsi pa akuntan dan pemakai lainnya. Sistem seperti ini sering kali kurang memiliki kontrol dan jejak audit yang memadai.

Pembuatan Prototipe

Pembuatan prototipe adalah teknik untuk memberikan versi pekerjaan penda-huluan dari sistem kepada pemakai. Prototipe dibuat dengan cepat dan tidak malah dengan tujuan nantinya akan dimodifikasi. Ketika para pemakai sistem bekerja dengan prototipe dan memberikan usulan perubahan, baik pemakai maupun profesional sistem mengembangkan pemahaman yang lebih baik tentang apa yang sebenarnya dibutuhkan oleh sistem tersebut.

Biaya untuk membuat sebuah prototipe model dijaga tetap rendah dengan mengurangi fitur-fiturnya sampai pada elemen-elemen yang mendasar saja. Misal-nya, sistem prototipe tidak akan berisi kode kompleks yang diperlukan untuk melaku-kan validasi transaksi, kapabilitas penanganan-pengecualian, dan kontrol internal. Biasanya, prototipe dibatasi pada layar input pemakai, laporan output, dan beberapa fungsi utama.

Ketika sampai pada tahap-tahap front end dari SDLC, pembuatan prototipe menjadi alat yang efektif untuk membentuk apa yang diinginkan pemakai dari sistem. Ketika itu sudah didapatkan, prototipe dibuang. Prototipe yang sudah di-buang ini digunakan untuk mengembangkan aplikasi terstruktur, seperti sistem akun-tansi. Sebuah teknik alternatif meneruskan proses pembuatan prototipe sampai sistem itu selesai dibuat. Pendekatan ini digunakan untuk mengembangkan sistem pendukung keputusan. Gambar 13-2 menggambarkan model prototipe tersebut.

Pendekatan CASE

Teknologi rekayasa teknologi perangkat keras yang dibantu oleh komputer (Computer­Aided Software Engineering-CASE) melibatkan penggunaan sistem komputer untuk membangun sistem komputer. Perangkat CASE merupakan produk-produk pe-rangkat lunak komersial yang berisi aplikasi integratif yang mendukung aktivitas SDLC secara luas. Metodologi ini dikembangkan untuk meningkatkan produktivitas profesional sistem, memperbaiki kualitas desain sistem, dan memperlancar SDLC.

Kebanyakan produk CASE terdiri atas perangkat atau aplikasi yang lebih tinggi atau lebih rendah. Perangkat CASE yang lebih tinggi mendukung aktivitas konseptual yang berkaitan dengan implementasi sistem dan pemeliharaan program. Gambar 13 - 3 menyajikan spektrum dukungan CASE dalam kaitannya dengan tahap-tahap SDLC. Perangkat CASE digunakan untuk mendefinisikan kebutuhan pe-makai, menciptakan database fisik dari perspektif pemakai konseptual, menghasilkan spesifikasi desain sistem, secara otomatis menghasilkan kode program komputer, dan memfasilitasi pemeliharaan program yang dibuat baik oleh CASE maupun teknik non-CASE. Gambar 13 - 4 menyajikan diagram ulasan tentang sistem CASE secara komprehensif. Berikut ini akan menjelaskan poin-poin penting dari diagram tersebut.

Repositori Sentral

Jantung sistem CASE adalah repositori (tempat penyimpanan) sentral. Pada dasarnya, ini merupakan database yang berisi atribut-atribut, relasi-relasi, dan elemen-elemen yang menjelaskan semua aplikasi yang dibuat oleh sistem CASE. Termasuk dalam item-item ini adalah:

1. Definisi semua database.
2. Dokumentasi sistem, seperti diagram konteks, diagram arus data, dan grafik struktur. 
3. Kode program.
4. Modul-modul program yang dapat dipakai ulang.
5. Layar prototipe pemakai.

Sistem repositori sentral membantu untuk mengintegrasikan aktivitas-akti-vitas desainer sistem yang bekerja pada proyek yang sama atau pada proyek-proyek yang terpisah tetapi saling berkaitan. Misalnya, jika ukuran atau nama dari atribut-atribut data harus diubah, maka semua aplikasi yang menggunakan atribut itu juga harus diubah. Dalam perusahaan­perusahaan yang berukuran sedang, hal ini melibat-kan ratusan program. Biasanya, dibutuhkan berhari-hari untuk mencari program-program yang dipengaruhi secara manual. Namun demikian, sistem repositori sentral dapat dengan cepat mengidentifikasi dan membuat daftar aplikasi yang meng-gunakan atribut yang diubah tersebut. 

Model CASE

Produk-produk CASE menggunakan beberapa model fungsional yang dapat di-gunakan untuk mendukung aktivitas dalam tahap-tahap yang berbeda dari SDLC. Sebagian model tersebut ditampilkan di bawah ini.

Model Diagram arus Data. Kami memperkenalkan diagram arus data (data flow diagram, selanjutnya disingkat menjadi DAD). DAD menggunakan serangkaian simbol yang mewakili proses, sumber data, arus data, dan urutan proses sistem yang ada saat ini atau sistem yang diusulkan.

Sebagai sebuah perangkat desain sistem, DAD digunakan untuk mewakili ber-macam­-macam tingkat rincian sistem. Dari sistem yang paling umum ke sistem yang paling rumit, berturut-turut, tingkat konteks, tingkat menengah, dan tingkat dasar.

DAD Tingkat Konteks. Analis dapat menggunakan DAD tingkat konteks untuk menyajikan sebuah model aktivitas bisnis dan transaksi-transaksi primer yang diproses oleh sistem tersebut. Gambar 13-5 menyajikan sebuah contoh dari diagram konteks dari siklus pendapat sebuah perusahaan. Diagram konteks merupakan representasi tingkat tinggi dari sebuah sistem. Diagram ini tidak berisi definisi file data dan prosedur secara rinci, melainkan fokusnya dipusatkan pada relasi kese-luruhan di antara entitas (data, sumber data, dan proses). Relasi ini diwakili oleh simbol-simbol, garis-garis, dan anak panah yang menunjukkan arah dari arus data.

DAD Tingkat Menengah. Langkah berikutnya adalah meluaskan DAD tingkat konteks ke dalam satu atau lebih DAD tingkat menengah, seperti yang diilustrasikan dalam Gambar 13-6. Perhatikan bagaimana Proses 1.0 dalam Gambar 13-5 diuraikan ke dalam sub-subproses berikut ini.

1.1 Persetujuan Penjualan

1.2 Pengiriman Barang-barang 

1.3 Penagihan Pelanggan

1.4 Pembaruan Piutang Dagang

Beberapa tingkat DAD menengah mungkin diperlukan untuk menyajikan rincian secara memadai kepada profesional sistem dan pemakai agar dapat sepenuhnya memahami sistem, Dalam contoh ini, kami menunjukkan hanya satu tingkat menengah.

DAD Tingkat Dasar. Gambar 13-7 menyajikan DAD tingkat dasar untuk Proses 1.3 dalam Gambar 13-6. Suatu DAD tingkat dasar menyediakan definisi yang jelas dan tepat untuk semua elemen sistem. Contoh ini, Proses 1.3 (penagihan pelanggan) dijelas-kan secara rinci. DAD tingkat dasar lainnya akan diperlukan untuk Proses 1.1, 1.2, dan 1.4

Persiapan DAD dalam lingkungan non-CASE dapat memakan banyak waktu analis. Karena perubahan-perubahan spesifikasi yang tidak dapat dihindari selama pengem-bangan sistem, seorang analis dapat menghasilkan banyak versi dari dokumen DAD sebelum sampai ke produk final. Kapabilitas grafik, yaitu fungsi-fungsi pelabelan, modifikasi, dan pengaturan kembali, yang dimiliki perangkat CASE sangat memperlancar pekerjaan ini. Namun demikian, DAD CASE lebih dari sekadar gambar grafik dari sebuah sistem. Gambar 13-8 menunjukkan sebuah diagram struktur untuk DAD tingkat dasar dalam Gambar 13-7. Diagram struktur menunjukkan relasi keseluruhan di antara modul-modul yang membentuk sistem tersebut. Setiap model ini menampilkan sebuah program terpisah yang harus diberi kode, kecuali jika program itu sudah ada sebagai modul program yang dapat dipakai berulang.

Model Prototipe. Model prototipe mendukung konsep pembuatan prototipe yang telah dijelaskan sebelumnya. Model ini sangat membantu memastikan bahwa kebutuhan pe-makai dipenuhi. Profesional sistem dapat segera memberikan layar input dan format-format laporan kepada para pemakai. Karenanya pemakai dapat memvisualisasikan fitur-fitur tertentu dart sistem tersebut sebelum nantinya benar-benar diraneang dan mengevaluasi sistem yang diusulkan. Setiap perubahan dapat diimplementasikan se-belum sistem ini dirancang dan dengan tanpa mengorbankan jadwal proyek.

Model Desain. Logika model desain didasarkan pada konsep dekomposisi (pe-nguraian). Setiap sistem dapat diuraikan atau didekomposisikan dari atas ke bawah dalam bentuk sub-subsistem yang lebih: kecil dan lebih kecil lagi, masing-masing dengan fungsi spesifik. DAD merupakan sebuah model sistem konseptual, dan diagram struktur me-rupakan model kode program yang membentuk sistem fisik. Gambar 13-8 menunjukkan diagram struktur untuk DAD tingkat dasar dalam Gambar 13-7. Diagram struktur me-nunjukkan keseluruhan relasi di antara modul-modul yang membentuk sistem tersebut. Setiap modul mewakili sebuah program terpisah yang harus dikodekan, keeuali jika modul itu sudah ada sebagai modul program yang dapat dipakai berulang. 

Banyak perangkat CASE mendokumentasikan rincian setiap modul dalam bentuk kode­kode samaran. Kode-kode samaran tersebut memberitahukan para pengamat (analis, auditor, atau pemrogram) tentang diagram struktur persis seperti yang akan dilakukan oleh modul, apa pun bahasa program yang digunakan. 

Model Pengkodean. Salah satu keunggulan CASE dalam menghemat te-naga kerja adalah fasilitasnya untuk mentransformasikan diagram struktur ke dalam modul-modul komputer. Banyak perangkat CASE top-end menghasilkan kode sumber program, seperti COBOL, C, dan C++. Program-program sumber ini kemudian harus dikompilasi-kan (diterjemahkan) ke dalam modul-modul kode mesin yang dapat dijalankan.

Model Pemeliharaan. Delapan puluh sampai sembilan puluh persen dari total biaya sistem dihabiskan selama tahap pemeliharaan SDLC. Hal ini sering kali disebut sebagai "efek gunung es." Gambar 13-9 menggambarkan fenomena ini. Semua sistem harus dipelihara selama masa hidup mereka, dan efek gunung es ini memang tidak bisa dihindari. Namun demikian, sistem­sistem yang dirancang dengan buruk berpeluang besar untuk menimbulkan masalah ini. Untuk membuat perubahan pada program kom-puter yang berada dalam lingkungan non­-CASE, pemrogram pemeliharaan (maintenance programmer) pertama-tama harus mempelajari secara menyeluruh kode program dalam usahanya memahami logika pemrogram awal. Hal ini sering kali memerlukan banyak waktu dan ini diperlama oleh logika program yang berlebihan, tidak efisien, dan kaku. Bahkan, perusahaan yang menggunakan perang-kat CASE memiliki kemungkinan memiliki sistem yang dirancang dengan buruk. Sering kali sistem­sistem tersebut sudah usang dan mendahului pemakaian CASE.

Model pemeliharaan CASE memfasilitasi pemeliharaan program dan sangat mengurangi efek gunung es. Aplikasi-aplikasi yang awalnyadikembangkan menurut sistem CASE relatif mudah dipelihara. Pemrogram pemeliharaan mempelajari doku-mentasi untuk aplikasi tersebut dan melakukan perubahan yang diperlukan, di tingkat konseptual, pada DAD. Sistem CASE kemudian membuat perubahan pada diagram-diagram struktur dan kode program secara otomatis. Akhirnya, pemrogram akan menguji secara menyeluruh dan memasang aplikasi yang sudah dimodifikasi.

Perangkat CASE dapat digunakan untuk memelihara aplikasi yang awalnya tidak dikembangkan oleh sistem CASE. Model pemeliharaan sistem akan menye-diakan perangkat seperti itu untuk tujuan ini: membalikkan teknologi dan rekayasa teknologi. Pembalikan ekstrak teknologi dari kode sumber akan merancang spesifi-kasi yang dapat digunakan pemrogram pemeliharaan untuk memahami logika apli-kasi. Rekayasa teknologi merestrukturisasi dan mendokumentasikan logika kode sumber yang lama agar sesuai dengan standar-standar CASE. Termasuk dalam hal ini adalah menyiapkan DAD dan diagram struktur. Jadi, pemeliharaan sistem di masa depan diteruskan jika aplikasi tersebut raJa awalnya dibuat menurut sistem CASE.

Keunggulan CASE

1. Mengurangi kompleksitas sistem. 
2. Meningkatkan fleksibilitas. 
3. Kapasitas untuk mempelajari desain-desain alternatif. 
4. Proses pengembangan yang lebih cepat. 
5. Mempromosikan keterlibatan pemakai. 
6. Kode program dan dokumentasi yang dapat dipakai berulang kali. 
7. Mengurangi biaya pemeliharaan. 

Kelemahan CASE

1. Biaya produk. 
2. Waktu dan biaya memulai. 
3. Perangkat CASE yang tidak sesuai. 
4. Program yang tidak efisien. 

D. 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.

SISTEM INFORMASI AKUNTANSI DAN PENGANTAR PENGEMBANGAN SISTEM 2017-03-20T09:53:00-07:00 Rating: 4.5 Diposkan Oleh: frf