Rtm 5_kelompok 1_edp D.docx

Systems Development and Program Changes Activities

Tugas Mata Kuliah Auditing EDP

Oleh: Kelompok 2

Wasilah Agustina

160810301054

Annas Miftahurrahman

160810301066

Didana Kalagustakega

160810301094

Program Studi Akuntansi Fakultas Ekonomi Dan Bisnis Universitas Jember 2019

BAB I Pendahuluan

Pengembangan sistem dan program perubahan aktivitas merupakan sebuah program yang berguna bagi akuntan dan auditor karena dengan adanya program ini, akuntan dan auditor dimudahkan dalam hal-hal yang berkaitan dengan sistem informasi yang juga membutuhkan adanya transaksi keuangan serta perlunya sebuah perencanaan, otorisasi, penjadwalan, pertanggungjawaban, serta pengendalian yang harus benar-benar dilaksanakan dengan baik dan sesuai dengan prosedur yang ada. Tujuan perencanaan sistem sebenarnya untuk menghubungkan proyek atau aplikasi sistem individual dengan tujuan strategis perusahaan. Untuk itu, perlu adanya kerjasama yang baik supaya tujuan strategis perusahaan dengan perencanaan sistem yang termasuk dalam pengembangan sistem dan program perubahan aktivitas dapat berjalan beriringan sesuai dengan apa yang direncanakan oleh perusahaan. Maka dari itu, apapun tujuan perusahaan pastinya membutuhkan sebuah perencanaan yang baik karena apa guna sebuah tujuan tanpa adanya perencanaan yang baik, meskipun telah didukung dengan adanya sebuah program yang lebih canggih. Pengembangan sistem dan program perubahan aktivitas diharapkan dapat membantu auditor serta pihak terkait untuk bisa menyelaraskan dengan tujuan perusahaan. Materi ini menarik untuk dipelajari karena sebagai calon auditor, kita perlu memiliki pemahaman umum tentang akuntan berpartisipasi dalam SDLC dan dapat mengidentifikasi ciri-ciri dasar terstruktur maupun berorientasi objek pendekatan desain sistem.

BAB II Pembahasan

Pengguna dalam Pengembangan Sistem Pengguna dalam pengembangan sistem dapat diklasifikasikan menjadi empat kelompok besar, yaitu: 1. Profesional sistem, pengguna akhir, pemangku kepentingan, dan akuntan auditor. 2. Pengguna akhir adalah mereka yang membangun sistem. 3. Stakeholder adalah individu baik di dalam atau di luar organisasi yang memiliki kepentingan dalam sistem tetapi bukan pengguna akhir. 4. Akuntan/Auditor adalah para profesional yang menangani kontrol, dan masalah audit untuk pengembangan sistem. Mengapa Akuntan dan Auditor Terlibat dengan SDLC? Proses SDLC menarik bagi akuntan dan auditor karena dua sebab. Pertama, proses suatu sistem informasi memerlukan transaksi keuangan yang signifikan. Secara konseptual, pengembangan sistem sama seperti manufaktur. Produk melalui serangkaian proses yang menghasilkan suatu tahapan yang kompleks. Transaksi seperti itu harus direncanakan, diotorisasi, dijadwalkan, dipertanggungjawabkan, dan dikendalikan. Akuntan sangat peduli dengan integritas proses ini seperti halnya mereka dengan proses manufaktur yang memiliki implikasi sumber daya keuangan. Karena latar belakang, pengalaman, dan pelatihan mereka, akuntan dan auditor sangat berpengalaman dalam transaksi keuangan dan dengan demikian dapat memberikan masukan penting ke dalam sistem mengenai kontrol, integritas, ketepatan waktu, dan sejumlah aspek penting lainnya dari transaksi keuangan. Kedua dan lebih mendesak untuk akuntan dan auditor adalah dengan sifat produk yang muncul dari informasi akuntansi bersandar langsung pada kegiatan SDLC yang menghasilkan sistem informasi akuntansi. Sistem ini memberikan informasi akuntansi kepada pengguna internal dan eksternal. Bagaimana akuntan terlibat dengan SDLC? Akuntan terlibat dalam pengembangan sistem dengan tiga cara. Pertama, akuntan adalah pengguna. Semua sistem yang memproses transaksi keuangan berdampak pada fungsi akuntansi dalam beberapa cara. Seperti semua pengguna, akuntan harus memberikan gambaran yang jelas tentang masalah mereka dan perlu sistem

profesional. Kedua, akuntan berpartisipasi dalam pengembangan sistem sebagai anggota tim pengembangan. Ketiga, akuntan terlibat dalam pengembangan sistem sebagai auditor. Akuntansi dalam sistem informasi harus dapat diaudit. SISTEM INFORMASI AKUISISI Organisasi biasanya memperoleh sistem informasi dalam dua cara: (1) mengembangkan sistem terpadu di rumah melalui kegiatan pengembangan sistem formal dan (2) membeli sistem komersial dari vendor perangkat lunak. Bagian teks ini membahas dua alternatif ini diantaranya: In-house development Membutuhkan pemeliharaan staf sistem penuh waktu dari analis dan programer yang mengidentifikasi kebutuhan informasi pengguna dan memenuhi kebutuhan mereka dengan sistem custom. Sistem Komersial Semakin banyak sistem dibeli dari vendor perangkat lunak. Dihadapkan dengan banyak paket yang bersaing, masing-masing dengan fitur dan atribut unik, manajemen harus memilih sistem dan vendor yang paling memenuhi kebutuhan organisasi. Membuat pilihan yang optimal mengharuskan ini menjadi keputusan berdasarkan informasi. 

Kecenderungan dalam Perangkat Lunak Komersial Empat faktor telah mendorong pertumbuhan dalam perangkat lunak komersial: (1) biaya perangkat lunak komersial umum yang relatif rendah dibandingkan dengan perangkat lunak yang dikustomisasi; (2) munculnya vendor khusus industri yang menargetkan perangkat lunak mereka untuk kebutuhan jenis bisnis tertentu (3) permintaan yang meningkat dari bisnis yang terlalu kecil untuk membeli staf pengembangan sistem in-house dan (4) kecenderungan terhadap penurunan unit organisasi organisasi dan hasil yang dihasilkan ke arah lingkungan pemrosesan data terdistribusi, yang telah membuat opsi perangkat lunak komersial lebih menarik bagi organisasi yang lebih besar.



Jenis Sistem Komersial Sistem Turnkey, Sistem turnkey benar-benar selesai dan sistem teruji yang siap untuk diimplementasikan. Sistem Akuntansi Umum, Sistem akuntansi umum dirancang untuk melayani berbagai macam kebutuhan pengguna. Dengan memproduksi secara massal

sistem standar, vendor mampu mengurangi biaya unit. Sistem ini ke sebagian kecil dari biaya pengembangan in-house. Sistem Tujuan Khusus, Beberapa vendor perangkat lunak membuat sistem tujuan khusus yang menargetkan segmen ekonomi tertentu. Sistem Otomasi Kantor, Sistem otomasi kantor adalah sistem komputer yang meningkatkan produktivitas pekerja kantor. Contoh sistem otomasi kantor dalam genggaman pengolah kata kasar, sistem manajemen basis data, program spreadsheet, dan sistem penerbitan desktop. Sistem Backbone, Sistem ini menyediakan struktur sistem dasar yang akan dibangun. Sistem ini dilengkapi dengan semua model pemrosesan utama yang diprogram. Sistem yang Didukung Vendor, Sistem yang didukung vendor adalah hibrida dari sistem custom dan perangkat lunak komersial. Dengan pendekatan ini, vendor mengembangkan (dan mempertahankan) sistem custom untuk kliennya. Sistem itu sendiri adalah produk khusus, tetapi layanan pengembangan sistem disediakan secara komersial. 

Keuntungan Perangkat Lunak Komersial 1.

Waktu pelaksanaan. Sistem custom sering membutuhkan waktu lama untuk dikembangkan. Berbulan-bulan atau bahkan bertahun-tahun dapat berlalu sebelum sistem khusus dapat dikembangkan melalui prosedur inhouse.

2.

Biaya. Seorang pengguna tunggal harus sepenuhnya menyerap biaya pengembangan

in-house.

Namun, karena biaya perangkat lunak

komersial tersebar di banyak pengguna maka biaya unit dikurangi menjadi sebagian kecil dari biaya sistem yang dikembangkan in-house. 3.

Keandalan. Sebagian besar paket perangkat lunak komersial terkemuka benar-benar diuji sebelum dirilis ke pasar konsumen. Kesalahan sistem apapun yang tidak ditemukan selama pengujian kemungkinan akan ditemukan oleh organisasi pengguna segera setelah rilis dan dikoreksi. Meskipun tidak ada sistem yang disertifikasi sebagai bebas dari kesalahan, perangkat lunak komersial lebih kecil kemungkinannya memiliki kesalahan daripada sistem internal yang setara.



Kekurangan Perangkat Lunak Komersial 1.

Independensi. Membeli sistem yang didukung vendor akan membuat perusahaan bergantung pada vendor untuk segi pemeliharaan. Pengguna

menjalankan risiko bahwa vendor akan berhenti mendukung sistem atau bahkan keluar dari bisnis. Ini mungkin menjaid kerugian terbesar sistem yang didukung vendor. 2.

Kebutuhan untuk sistem yang disesuaikan. Keuntungan utama dari pembangunan in-house adalah kemampuan untuk menghasilkan aplikasi dengan spesifikasi yang tepat. Keuntungan ini juga menjelaskan kerugian dari perangkat lunak komersial. Terkadang, kebutuhan pengguna adalah unik dan rumit, dan perangkat lunak yang tersedia secara komersial terlalu umum atau terlalu tidak fleksibel.

3.

Perawatan. Sistem informasi bisnis sering mengalami perubahan. Jika pengguna perlu perubahan, mungkin sulit atau bahkan tidak mungkin untuk memodifikasi perangkat lunak komersial.

SIKLUS PENGEMBANGAN SISTEM Baik pengembangan in-house maupun opsi paket komersial masing-masing memiliki kelebihan dan kekurangan. Namun, itu bukan proposisi yang saling menguntungkan. Perusahaan dapat memenuhi beberapa kebutuhan informasinya dengan perangkat lunak dan meminjamkan sistem lain di dalam perusahaan. Pendekatan ditingkatkan dengan prosedur formal yang terstruktur ke proses pengambilan keputusan. Siklus hidup pengembangan sistem yang dijelaskan selanjutnya umumnya terkait dengan pengembangan internal, tetapi banyak fase, terutama yang melibatkan analisis kebutuhan dan spesifikasi sistem dapat digunakan secara efektif bahkan ketika sistem akhir dibeli dari vendor luar. Tujuan dan urutan siklus hidup pengembangan sistem (SDLC) adalah logis dan umumnya diterima oleh para ahli dalam komunitas sistem, dan umumnya diperlakukan sebagai praktik terbaik untuk pengembangan sistem. Perencanaan Sistem - Tahap I Tujuan perencanaan sistem adalah untuk menghubungkan proyek atau aplikasi sistem individual dengan tujuan strategis perusahaan. Sebenarnya, dasar untuk rencana sistem adalah rencana bisnis organisasi, yang menentukan dimana perusahaan berencana untuk pergi dan bagaimana ia akan sampai di sana. Secara khusus, proyek sistem dianalisis dengan menggunakan rencana strategis TI, yang dikembangkan dari dan selaras dengan rencana bisnis organisasi.



Siapa yang Harus Melakukan Perencanaan Sistem? Sebagian besar perusahaan yang mengambil perencanaan sistem secara

serius membentuk komite pengarah sistem untuk memberikan panduan dan meninjau status proyek sistem. Komposisi komite dapat mencakup ketua pelaksana, kepala bagian keuangan, kepala bagian informasi, manajemen senior dari area pengguna, auditor internal, dan manajemen senior dari layanan komputer. Pihak eksternal, seperti manajemen konsultan dan auditor eksternal perusahaan, dapat juga melengkapi komite. Tanggungjawab umum untuk komite pengarah termasuk yang berikut: 1. Menyelesaikan konflik yang muncul dari sistem baru. 2. Meninjau proyek dan menetapkan prioritas dana 3. Penganggaran untuk pengembangan sistem 4. Meninjau status masing-masing proyek yang sedang dalam tahap pengembangan 5. Menentukan di berbagai pos pemeriksaan sepanjang SDLC apakah akan melanjutkan proyek atau menghentikannya Perencanaan sistem terjadi pada dua tingkatan, yaitu Perencanaan Sistem Strategis dan Perencanaan Proyek. 

Perencanaan Sistem Strategis Sistem strategis melibatkan alokasi sumber daya sistem pada tingkat makro.

Biasanya berkaitan dengan jangka waktu 3 hingga 5 tahun. Proses ini mirip dengan sumber daya anggaran untuk kegiatan strategis lainnya, seperti pengembangan produk, perluasan pabrik, riset pasar, dan teknologi manufaktur. Secara teknis, perencanaan sistem strategis bukan bagian dari SDLC karena SDLC memungkinkan aplikasi spesifik. Rencana sistem strategis berkaitan dengan alokasi sumber daya sistem seperti karyawan (jumlah profesional sistem yang akan disewa), perangkat keras (jumlah workstation, minicomputer, dan mainframe yang akan dibeli), perangkat lunak (dana yang akan digunakan) dialokasikan untuk proyek-proyek sistem baru dan untuk pemeliharaan sistem), dan telekomunikasi (dana dialokasikan untuk jaringan dan EDI). Adalah penting bahwa rencana strategis menghindari detail yang berlebihan. Rencana tersebut harus memungkinkan spesialis sistem untuk membuat keputusan berdasarkan informasi dengan mempertimbangkan faktor-faktor yang relevan seperti harga, ukuran kinerja, ukuran, keamanan, dan kontrol.

Mengapa Melakukan Perencanaan Sistem Strategis? Mungkin tidak ada aspek kegiatan bisnis perusahaan yang bergejolak dan tidak dapat diprediksi sebagai perencanaan sistem informasi. Siapa yang dapat melihat 5 tahun ke depan dan memprediksi secara akurat status teknologi sistem? Karena volatilitas ini, rencana jangka panjang apa pun yang dibuat perusahaan cenderung berubah. Bagaimana, oleh karena itu, apakah perusahaan dapat melakukan perencanaan sistem strategis? Kenapa harus begitu? Terdapat empat pembenaran untuk perencanaan sistem strategis: (1) Sebuah rencana yang berubah secara konstan, (2) Perencanaan strategis mengurangi komponen krisis dalam pengembangan sistem, (3) Perencanaan sistem strategis menyediakan pengendalian untuk SDLC, dan (4) Manajemen biaya. 

Perencanaan Proyek Tujuan dari perencanaan proyek adalah untuk mengalokasikan sumber daya

untuk aplikasi individu dalam kerangka rencana strategis. Ini melibatkan identifikasi area kebutuhan pengguna, menyusun proposal, mengevaluasi kelayakan

dan

kontribusi

masing-masing

proposal

ke

rencana

bisnis,

memprioritaskan proyek individu, dan menjadwalkan pekerjaan yang harus dilakukan. Dasar dari perencanaan proyek adalah mengalokasikan sumber daya yang langka ke proyek-proyek tertentu. Produk fase ini terdiri dari dua dokumen formal, yaitu proposal proyek dan jadwal proyek. 

Peran Auditor dalam Perencanaan Sistem Auditor secara rutin memeriksa fase perencanaan sistem dari SDLC.

Perencanaan

yang

sangat

mengurangi

risiko

bahwa

organisasi

telah

menghasilkan sistem yang tidak dibutuhkan, tidak efisien, tidak efektif, dan curang. Oleh karena itu, baik auditor internal dan eksternal tertarik untuk memastikan bahwa perencanaan sistem yang memadai terjadi. Analisis Sistem - Tahap II Sekarang beralih ke fase kedua dalam SDLC. Analisis sistem merupakan proses dua langkah yang melibatkan survei pertama dari sistem saat ini dan kemudian analisis kebutuhan pengguna. Masalah bisnis harus sepenuhnya dipahami oleh analis sistem sebelum dia dapat merumuskan solusi. Analisis yang tidak lengkap atau cacat akan mengarah pada solusi yang tidak lengkap. Oleh karena itu, analisis sistem adalah fondasi untuk sisa SDLC. Penyampaian dari fase ini adalah laporan analisis sistem formal, yang menyajikan temuan analisis dan rekomendasi untuk sistem baru.



Langkah Survei Sebagian besar sistem tidak dikembangkan dari awal. Biasanya, beberapa

bentuk sistem informasi dan prosedur terkait saat ini sudah ada. Analis sering memulai analisis dengan menentukan elemen apa, jika ada, dari sistem saat ini harus dilestarikan sebagai bagian dari sistem baru. Ini melibatkan survei sistem yang agak rinci. Kerugian Survei Sistem Terkini 1.

Lubang non fisik saat ini. Istilah ini digunakan untuk menggambarkan kecenderungan pada bagian analis untuk "tersedot" dan kemudian macet oleh tugas survei sistem dinosaurus.

2.

Thinking inside the Box. Beberapa berpendapat bahwa survei sistem saat ini menghambat ide-ide baru. Mempelajari dan memodelkan sistem lama, analis dapat mengembangkan gagasan terbatas tentang bagaimana sistem baru harus berfungsi. Hasilnya adalah sistem lama yang ditingkatkan daripada pendekatan baru yang radikal.

Keuntungan Survei Sistem Terkini 1.

Mengidentifikasi aspek apa dari sistem lama. Beberapa elemen dari sistem mungkin berfungsi dengan baik dan dapat memberikan fondasi untuk sistem baru. Dengan memahami sistem saat ini, analis dapat mengidentifikasi aspekaspek yang layak dipertahankan atau dimodifikasi untuk digunakan dalam sistem baru.

2.

Analis

untuk

sepenuhnya

memahami

sistem.

Ketika

sistem

baru

disempurnakan, pengguna harus melalui proses konversi dimana mereka secara formal melepaskan diri dari sistem lama dan pindah ke yang baru. Analis harus menentukan tugas, prosedur, dan data apa yang akan dihapus dengan sistem lama dan yang akan berlanjut. Untuk menentukan prosedur konversi ini, analis harus tahu, tidak hanya apa yang harus dilakukan oleh sistem baru, tetapi juga apa yang telah dilakukan oleh sistem lama. 3.

Mengisolasi akar gejala masalah. Dengan mensurvei sistem saat ini, analis dapat menentukan secara pasti penyebab gejala masalah yang dilaporkan. Mungkin saja akar masalahnya bukanlah sistem informasi, mungkin masalah manajemen atau karyawan yang dapat diselesaikan tanpa mendesain ulang sistem informasi. Kami mungkin tidak dapat mengidentifikasi akar penyebab masalah jika kami membuang sistem pembuangan tanpa penyelidikan gejala.



Mengumpulkan Fakta-Fakta Survei tentang sistem saat ini pada dasarnya merupakan kegiatan

pengumpulan fakta. Fakta-fakta yang dikemukakan oleh analis adalah potonganpotongan data yang menggambarkan fitur-fitur utama, situasi, dan hubunganhubungan sistem. Berikut merupakan fakta yang terdapat di dalam sistem: 1.

Sumber data. Ini termasuk entitas eksternal, seperti pelanggan atau vendor, serta sumber internal dari departemen lain.

2.

Pengguna. Ini termasuk para manajer dan pengguna operasi.

3.

Penyimpanan data: file, basis data, akun, dan dokumen sumber yang digunakan dalam sistem.

4.

Proses. Memproses tugas adalah operasi manual atau komputer yang mewakili suatu keputusan atau tindakan yang dipicu oleh arus informasi data.

5.

Aliran data. Aliran data diwakili oleh pergerakan dokumen dan laporan antara sumber data, penyimpanan data, tugas pemrosesan, dan pengguna.

6.

Kontrol. Ini termasuk pengendalian akuntansi dan operasional dan mungkin prosedur manual atau kontrol komputer.

7.

Volume transaksi. Analis harus mendapatkan ukuran volume transaksi untuk jangka waktu tertentu. Banyak sistem diganti karena mereka telah mencapai kapasitas mereka. Memahami karakteristik volume transaksi sistem dan laju pertumbuhannya merupakan elemen penting dalam menilai persyaratan kapasitas untuk sistem baru.

8.

Tingkat kesalahan. Kesalahan transaksi erat kaitannya dengan volume transaksi. Ketika sebuah sistem mencapai kapasitas, tingkat kesalahan meningkat ke tingkat yang tak tertahankan. Meskipun tidak ada sistem yang sempurna, analis harus menentukan toleransi kesalahan yang dapat diterima untuk sistem baru.

9.

Biaya Sumber Daya. Sumber daya yang digunakan oleh sistem saat ini termasuk biaya tenaga kerja, waktu komputer, bahan (seperti faktur), dan biaya langsung. Setiap biaya sumber daya yang hilang ketika sistem saat ini dihapus disebut biaya yang dapat dilewati. Kemudian, ketika melakukan analisis biaya-manfaat, biaya yang dapat dilalui akan diperlakukan sebagai manfaat dari sistem baru.

10. Hambatan dan operasi berlebihan. Analis harus mencatat titik-titik dimana arus data bersatu membentuk kemacetan. Pada periode beban puncak, ini dapat menyebabkan penundaan dan meningkatkan kesalahan pemrosesan.

Demikian juga, penundaan dapat disebabkan oleh operasi yang berlebihan, seperti persetujuan atau persetujuan yang tidak perlu. 

Teknik Pengumpulan Fakta Analis sistem menggunakan beberapa teknik untuk mengumpulkan fakta yang

dikutip sebelumnya. Teknik yang digunakan adalah teknik observasi, partisipasi tugas, wawancara pribadi, dan meninjau dokumen-dokumen kunci. 

Langkah Analisis Sistem analisis merupakan proses intelektual yang bercampur dengan

pengumpulan

fakta.

Analis

secara

bersamaan

menganalisis

saat

dia

mengumpulkan fakta. Pengenalan masalah semata-mata mengandaikan beberapa pemahaman tentang norma yang diinginkan. Oleh karena itu sulit diidentifikasi atau dimulai. 

Laporan Analisis Sistem Hal ini yang menandai akhir dari fase analisis sistem adalah penyusunan

laporan analisis sistem formal. Dokumen ini merupakan kontrak yang resmi menentukan tujuan dan sasaran sistem. Laporan analisis sistem harus dilist dalam hal sumber data, pengguna, file data, proses umum, aliran data, kontrol, dan kapasitas volume transaksi. Laporan analisis sistem tidak menentukan desain rinci dari sistem yang diusulkan. Sebagai contoh, itu tidak menentukan metode pengolahan, media penyimpanan, struktur catatan, dan rincian lain yang diperlukan untuk merancang sistem fisik. 

Peran Auditor dalam Analisis Sistem Auditor perusahaan (eksternal dan internal) adalah pemangku kepentingan

dalam sistem yang diusulkan. Seringkali, fitur audit lanjutan tidak dapat dengan mudah ditambahkan ke sistem yang ada. Maka dari itu, akuntan atau auditor harus dilibatkan dalam analisis kebutuhan sistem yang diusulkan untuk menentukan apakah itu kandidat yang baik untuk fitur audit lanjutan, dan jika demikian, fitur mana yang paling cocok untuk sistem. Desain Konseptual Sistem – Tahap III Tujuan dari tahap ini adalah untuk menghasilkan beberapa alternatef konsep sistem yang memenuhi berbagai kebutuhan yang teridentifikasi dalam analis sistem. Dengan memberikan kenyamanan kepada para pengguna dengan sejumlah alternatif yang masuk akal, para professional sistem menghindarkan diri dari memunculkan kendala yang sudah ada sebelumnya pada sistem baru. Pengguna akan mengevaluasi

model konseptual ini dan menentukan alternatif yang tampak paling masuk akal dan menarik. Desain alternatif ini kemudian menuju ke tahap pemilihan sistem SDLC, dimana biaya dan manfaatnya masing-masing dibandingkan dan desain optimal tunggal dipilih. Sistem konseptual yang muncul berlanjut ke fase akhir SDLC, dimana ia dirancang secara rinci dan diimplementasikan. Bagian ini menjelaskan dua pendekatan untuk desain sistem konseptual: pendekatan terstruktur dan pendekatan berorientasi objek. Pendekatan terstruktur mengembangkan setiap sistem baru dari awal dari atas ke bawah. Desain berorientasi objek (OOD) membangun sistem dari bawah ke atas melalui perakitan modul yang dapat digunakan kembali daripada membuat setiap sistem dari awal. 

Pendekatan desain terstruktur (Structured Design) Pendekatan desain terstruktur adalah cara disiplin merancang sistem dari atas

ke bawah. Ini terdiri dari mulai dengan "gambaran besar" dari sistem yang diusulkan yang sekutu terurai menjadi lebih dan lebih detail sampai sepenuhnya dipahami. Dibawah pendekatan ini, proses bisnis dalam desain biasanya didokumentasikan oleh aliran data dan diagram struktur. Fase desain konseptual harus menyoroti perbedaan antara fitur-fitur penting dari sistem yang bersaing daripada kesamaannya. Oleh karena itu, desain sistem pada titik ini harus bersifat umum. Desain harus mengidentifikasi semua input, output, proses, dan fitur khusus yang diperlukan untuk membedakan satu alternatif dari yang lain. Desain memang memiliki detail yang cukup untuk menunjukkan bagaimana kedua sistem secara konseptual berbeda dalam fungsinya. 

Pendekatan berorientasi Objek (Object-oriented design-OOD) Pendekatan desain berorientasi objek (OOD) adalah untuk membangun

sistem informasi dari komponen atau objek standar yang dapat digunakan kembali. Pendekatan ini dapat disamakan dengan proses membangun mobil. Pabrikan mobil tidak membuat setiap model baru dari awal. Model-model baru sebenarnya dibangun dari komponen standar yang juga masuk ke model lain. Misalnya, setiap model mobil yang diproduksi oleh pabrikan tertentu dapat menggunakan jenis mesin, gearbox, alternator, gandar belakang, radio, dan sebagainya yang sama. Beberapa komponen mobil akan menjadi produk standar industri yang digunakan oleh pabrikan lain. Hal-hal seperti roda, ban, busi, dan lampu utama termasuk dalam kategori ini. Bahkan, mungkin satu-satunya komponen yang benar-benar dibuat dari awal untuk model mobil baru adalah bodi.

Industri mobil beroperasi dengan cara ini untuk tetap kompetitif. Dengan menggunakan komponen standar, pabrikan mobil meminimalkan biaya produksi dan perawatan. Pada saat yang sama, mereka dapat tetap responsif terhadap permintaan konsumen untuk produk-produk baru dan menjaga fleksibilitas manufaktur dengan mencampur dan mencocokkan komponen sesuai dengan spesifikasi pelanggan. Konsep usabilitas adalah inti dari pendekatan berorientasi objek untuk sistem tanda. Setelah dibuat, modul standar dapat digunakan dalam sistem lain dengan kebutuhan serupa. Idealnya, profesional sistem organisasi akan membuat perpustakaan (inventaris) modul yang dapat digunakan oleh perancang sistem lain di dalam perusahaan. Manfaat dari pendekatan ini termasuk pengurangan waktu dan biaya untuk pengembangan, pemeliharaan, dan pengujian serta peningkatan dukungan pengguna dan fleksibilitas dalam proses pengembangan. 

Peran Auditor dalam Desain Konseptual Sistem Auditor adalah pemangku kepentingan dalam semua sistem keuangan dan,

dengan demikian, memiliki kepentingan dalam tahap desain konsep sistem. Auditabilitas suatu sistem sebagian tergantung pada karakteristik desainnya. Beberapa teknik audit komputer membutuhkan sistem untuk dirancang dengan fitur audit khusus yang merupakan bagian integral dari sistem. Fitur audit ini harus ditentukan pada tahap desain konseptual. Evaluasi dan Pemilihan Sistem – Tahap IV Fase berikutnya dalam SDLC adalah prosedur untuk memilih satu sistem dari set desain konseptual alternatif yang akan menuju ke fase desain terperinci. Tahap evaluasi

dan

pemilihan

sistem

adalah

proses

optimisasi

yang

berupaya

mengidentifikasi sistem terbaik. Keputusan ini merupakan titik kritis dalam SDLC. Pada titik ini, ada banyak ketidakpastian tentang sistem, dan keputusan yang buruk disini bisa menjadi disastrous. Tujuan dari evaluasi formal dan prosedur seleksi adalah untuk menyusun proses pengambilan keputusan ini dan dengan demikian mengurangi ketidakpastian dan risiko membuat keputusan yang buruk. Proses evaluasi dan seleksi melibatkan dua langkah: Melakukan studi kelayakan yang terperinci Diskusi berikut menguraikan lima aspek kelayakan proyek yang perlu dipertimbangkan. Setiap proyek yang bersaing akan dinilai dengan cara yang sama. Dengan menilai kendala utama pada sistem yang diusulkan, manajemen

dapat mengevaluasi kemungkinan proyek untuk berhasil.Faktor-faktor yang dinilai dalam tahapan ini adalah: a.

Kelayakan teknis Apakah sistem dapat dikembangkan dengan teknologi yang ada atau membutuhkan teknologi yang baru.

b.

Kelayakan hukum Mengidentifikasi konflik antara konsep sistem dengan kemampuan perusahaan untuk melaksanakan tanggung jawab hukumnya

c.

Kelayakan operasional Tingkat kesesuaian antara prosedur perusahaan yang ada dengan berbagai keahlian serta kebutuhan operasional sistem yang baru.

d.

Kelayakan jadwal Kemampuan perusahaan untuk mengimplementasikan proyek tersebut dalam waktu yang dapat ditoleransi.

Lakukan Analisis Biaya-Manfaat Analisis biaya-manfaat membantu manajemen menentukan apakah (dan seberapa banyak) manfaat yang diterima dari sistem yang diusulkan akan melebihi biayanya. Teknik ini sering digunakan untuk memperkirakan nilai keuangan investasi bisnis yang diharapkan. Namun, dalam hal ini, investasi adalah sistem informasi, dan biaya dan manfaatnya lebih sulit untuk diidentifikasi dan diukur daripada proyek modal tradisional. Meskipun tidak sempurna untuk pengaturan ini, analisis biaya-manfaat digunakan karena kesederhanaannya dan tidak adanya alternatif yang jelas lebih baik. Terlepas dari keterbatasannya, analisis biayamanfaat, dikombinasikan dengan faktor-faktor kelayakan, adalah alat yang berguna untuk membandingkan desain sistem pesaing. Ada tiga langkah dalam penerapan analisis biaya-manfaat: mengidentifikasi biaya, mengidentifikasi manfaat, dan membandingkan biaya dan manfaat. Kami mendiskusikan masingmasing langkah di bawah ini. a.

Identifikasi Biaya Salah satu metode untuk mengidentifikasi biaya adalah dengan membagi mereka menjadi dua kategori: biaya satu kali dan biaya berulang. Biaya satu kali termasuk investasi awal untuk mengembangkan dan menerapkan sistem. Biaya berulang termasuk biaya operasi dan pemeliharaan yang berulang selama masa pakai sistem. Biaya satu kali yaitu:



Akuisisi perangkat keras Biaya ini termasuk biaya mainframe, minicomputer, mikrokomputer, dan peralatan periferal, seperti tape drive dan paket disk. Angka-angka biaya ini dapat diperoleh dari vendor.



Persiapan situs Biaya ini melibatkan biaya yang sering diabaikan seperti modifikasi bangunan (misalnya, menambahkan AC atau membuat perubahan struktural), instalasi peralatan (yang mungkin termasuk penggunaan alat berat), dan biaya pengiriman. Perkiraan biaya ini dapat diperoleh dari vendor dan subkontraktor yang melakukan instalasi.



Akuisisi perangkat lunak Biaya ini berlaku untuk semua perangkat lunak yang dibeli untuk sistem yang diusulkan. Perkiraan biaya ini dapat diperoleh dari vendor.



Desain sistem Biaya ini adalah biaya yang dikeluarkan oleh profesional sistem yang melakukan fungsi perencanaan, analisis, dan desain. Secara teknis, biaya yang dikeluarkan hingga titik ini "tenggelam" dan tidak relevan dengan keputusan tersebut. Analis harus memperkirakan hanya biaya yang diperlukan untuk menyelesaikan desain rinci.



Pemrograman dan pengujian Biaya pemrograman didasarkan pada perkiraan jam personil yang diperlukan untuk menulis program baru dan memodifikasi program yang ada untuk sistem yang diusulkan. Biaya pengujian sistem melibatkan menyatukan semua modul program individual untuk pengujian sebagai keseluruhan sistem. Ini harus menjadi latihan yang ketat jika ingin bermakna. Pengalaman perusahaan di masa lalu adalah dasar terbaik untuk memperkirakan biaya-biaya ini.



Konversi data Biaya-biaya ini timbul dalam transfer data dari satu media penyimpanan ke media lainnya. Sebagai contoh, catatan akuntansi dari sistem manual harus diubah menjadi bentuk magnetik ketika sistem menjadi berbasis komputer. Ini bisa mewakili tugas yang signifikan. Dasar untuk memperkirakan biaya konversi adalah jumlah dan ukuran file yang akan dikonversi.



Pelatihan Biaya ini melibatkan mendidik pengguna untuk mengoperasikan sistem baru. Personil internal dapat melakukan ini dalam program pelatihan ekstensif yang disediakan oleh organisasi luar di lokasi terpencil atau melalui pelatihan di tempat kerja.

Sedangkan Biaya berulang yaitu: 

Pemeliharaan perangkat keras Biaya ini melibatkan peningkatan komputer (meningkatkan memori), serta pemeliharaan dan perbaikan preventif ke komputer dan peralatan periferal. Organisasi dapat membuat kontrak pemeliharaan dengan vendor

untuk

meminimalkan

dan

menganggarkan

biaya-biaya

ini. Perkiraan biaya ini dapat diperoleh dari vendor dan kontrak yang ada. 

Perawatan perangkat lunak Biaya ini termasuk upgrade dan debugging sistem operasi, aplikasi yang

dibeli,

dan

aplikasi

yang

dikembangkan

di

dalam

perusahaan. Kontrak perawatan dengan vendor perangkat lunak dapat digunakan untuk menentukan biaya ini dengan cukup akurat. Perkiraan pemeliharaan di rumah dapat berasal dari data historis. 

Asuransi Biaya ini mencakup bahaya dan bencana seperti kebakaran, kegagalan perangkat keras, vandalisme, dan kehancuran oleh karyawan yang tidak puas.



Persediaan Biaya ini terjadi melalui konsumsi rutin barang-barang seperti kertas, disk magnetik, CD, dan perlengkapan kantor umum.



Biaya personil Ini adalah gaji individu yang merupakan bagian dari sistem informasi. Beberapa biaya karyawan bersifat langsung dan mudah diidentifikasi,

seperti

gaji

personil

operasi

yang secara

eksklusif

digunakan sebagai bagian dari sistem yang sedang dianalisa. b.

Identifikasi Manfaat Langkah

selanjutnya

dalam

analisis

biaya-manfaat

adalah

mengidentifikasi manfaat sistem. Ini mungkin nyata dan tidak nyata. Manfaat yang nyata terbagi dalam dua kategori: yang meningkatkan pendapatan dan yang mengurangi biaya. Misalnya, menganggap sistem EDI yang diusulkan

akan memungkinkan organisasi untuk mengurangi persediaan dan pada saat yang sama meningkatkan layanan pelanggan dengan mengurangi kehabisan stok. Pengurangan

persediaan

adalah

manfaat

yang

mengurangi

biaya. Sistem yang diusulkan akan menggunakan lebih sedikit sumber daya (persediaan) daripada sistem saat ini. Nilai dari manfaat ini adalah jumlah dolar dari biaya tercatat yang disimpan oleh pengurangan inventaris tahunan. Perkiraan peningkatan penjualan karena layanan pelanggan yang lebih baik adalah manfaat peningkatan pendapatan. Ketika mengukur penghematan biaya, penting untuk memasukkan hanya biaya yang dapat diandalkan dalam analisis. Biaya yang dapat dilepas secara langsung terkait dengan sistem, dan mereka tidak ada lagi ketika sistem berhenti ada. Beberapa biaya yang tampaknya dapat diandalkan oleh pengguna tidak benar-benar dapat dihindari dan, jika dimasukkan, dapat menyebabkan analisis yang salah. Sebagai contoh, pusat pemrosesan data sering "mengisi kembali" biaya operasi mereka ke konstituensi pengguna mereka melalui alokasi biaya. Tingkat pengembalian biaya yang mereka gunakan untuk ini mencakup biaya tetap (dialokasikan untuk pengguna) dan biaya langsung yang dibuat oleh aktivitas pengguna individu. Sistem profesional memanfaatkan banyak sumber dalam upaya untuk mengukur manfaat yang tidak berwujud dan memanipulasinya ke dalam istilah keuangan. Beberapa teknik umum termasuk survei opini pelanggan (dan karyawan), analisis statistik, teknik nilai yang diharapkan, dan model simulasi. Meskipun para profesional sistem mungkin berhasil menghitung sebagian dari manfaat tak berwujud ini, lebih sering mereka harus puas hanya menyatakan manfaatnya tepat seperti izin penilaian yang baik. c.

Bandingkan Biaya dan Manfaat Langkah terakhir dalam analisis biaya-manfaat adalah membandingkan biaya dan manfaat yang diidentifikasi dalam dua langkah pertama. Dua metode yang paling umum digunakan untuk mengevaluasi sistem informasi adalah nilai sekarang bersih dan pengembalian. Berdasarkan metode nilai bersih saat ini, nilai sekarang dari biaya dikurangi dari nilai sekarang dari manfaat selama umur sistem. Proyek dengan

nilai

sekarang

bersih

positif

secara

ekonomi

layak. Ketika

membandingkan proyek yang bersaing, pilihan optimal adalah proyek dengan nilai net present value terbesar.

Metode pengembalian adalah variasi analisis titik impas. Titik impas tercapai ketika total biaya sama dengan total manfaat Kurva biaya total terdiri dari biaya satu kali ditambah nilai sekarang dari biaya berulang selama umur proyek. Kurva manfaat total adalah nilai sekarang dari manfaat nyata. Perpotongan garis-garis ini menunjukkan jumlah tahun ke depan ketika proyek mencapai titik impas, atau membayar untuk dirinya sendiri. Area yang diarsir antara kurva manfaat dan kurva total biaya mewakili nilai sekarang dari laba masa depan yang diperoleh oleh sistem. Dalam memilih sistem informasi, kecepatan pengembalian sering menjadi faktor penentu. Dengan siklus hidup produk yang singkat dan kemajuan teknologi yang pesat, kehidupan yang efektif dari sistem informasi cenderung pendek. Persiapkan Laporan Pemilihan Sistem Produk yang dapat dikirimkan dari proses pemilihan sistem adalah laporan pemilihan sistem. Dokumen formal ini terdiri dari studi kelayakan yang direvisi, analisis biaya-manfaat, dan daftar serta penjelasan tentang manfaat tidak nyata untuk setiap desain alternatif. Peran Auditor dalam Evaluasi dan Seleksi Perhatian utama untuk auditor adalah bahwa kelayakan ekonomi dari sistem yang

diusulkan

diukur

seakurat

mungkin. Secara

khusus,

auditor

harus

memastikan lima hal: a.

Hanya biaya yang dapat diandalkan digunakan dalam perhitungan manfaat penghematan biaya.

b.

Suku bunga yang wajar digunakan dalam mengukur nilai sekarang dari arus kas.

c.

Biaya satu kali dan berulang dilaporkan secara lengkap dan akurat.

d.

Kehidupan bermanfaat yang realistis digunakan dalam membandingkan proyek yang bersaing.

e.

Manfaat tidak berwujud diberikan nilai keuangan yang wajar. Kesalahan, kelalaian, dan misrepresentasi dalam akuntansi untuk barang-

barang tersebut dapat merusak analisis dan dapat mengakibatkan keputusan yang cacat secara material.

Desain Terperinci - Tahap V Tujuan desain terperinci adalah untuk menghasilkan penjelasan terperinci sistem yang diusulkan yang dapat memenuhi kebutuhan sistem yang telah diidentifikasi selama analisis sistem dan yang sesuai dengan desain konseptual. Dalam tahap V, semua komponen sistem (tampilan pengguna, tabel basis data, proses dan pengendalian) secara lengkap. Akhir tahap ini, berbagai komponen akan disajikan secara formal dalam laporan desain terperinci. Laporan tersebut akan membentuk serangkaian cetak biru yang memfokuskan pada format layar input, tata letak laporan ouput, struktur basis data, dan logika proses. Setelah berbagai rencana dilengkapi kemudian diteruskan ke tahap akhir SDLC yakni implementasi sistem, di mana sistem akan secara fisik dibangun. Melakukan Percobaan Desain Sistem Tahap desain terperinci telah selesai, selanjutnya tim pengembangan biasanya melakukan percobaan desain sistem untuk memastikan bahwa desain tersebut bebas dari kesalahan konseptual yang dapat diprogram masuk ke dalam sistem. Banyak perusahaan memiliki percobaan formal dan terstruktur yang dilakukan oleh kelompok penjamin mutu. Kelompo ini adalah kelompok independen yang terdiri atas programmer, analisis, pengguna, dan auditor internal. Pekerjaan dari kelompok ini adalah menyimulasikan operasi sistem terkait untuk mengungkapkan kesalahan, penghilangan, dan ambiguitas dalam desain. Kesalahan sistem banyak bersumber dari desain yang kurang baik, bukan kesalahan dari pemrograman. Mengkaji Dokumentasi Sistem Laporan desain terperinci akan mendokumentasikan dan menjelaskan sistem. Laporan tersebut meliputi berbagai hal berikut: 

Desain semua input dan dokumen sumber untuk sistem.



Desain semua output, laporan, dan dokumen operasional.



Data yang dinormalisasi untuk tabel basis data, yang menspesifikasikan semua elemen data.



Struktur dan diagram basis data, dimana dalam diagram relasi entitas yang menjelaskan

hubungan

data

dalam

sistem,

diagram

konteks

untuk

keseluruhan sistem, diagram aliran data tingkat rendah untuk proses sistem tertentu, diagram struktur untuk modul program dalam sistem, termasuk penjelasan kode semu untuk tiap modul. 

Kamus data terbaru yang menjelaskan setiap elemen data dalam basis data.



Logika pemrosesan (bagan alir).

Kelompok penjamin mutu memeriksa berbagai dokumen ini dan kesalahan apa pun yang terdeteksi akan dicatat dalam laporan percobaan. Desain sistem akan diterima tanpa perubahan, diterima karena adanya perubahan kesalahan kecil, atau ditolak karena kesalahan yang material. Selanjutnya keputusan akan dibuat untuk mengembalikan sistem terkait agar diberikan tambahan desain atau meneruskan ke tahap berikutnya yakni pengodean dan pengujian sistem.

Pemrograman dan Pengujian Program-Tahap VI Memprogram Perangkat Lunak Aplikasi Tahap selanjutnya dari SDLC adalah memilih bahasa pemrograman dari berbagai bahasa yang tersedia dan yang sesuai dengan aplikasi. Bahas tersebut meliputi bahasa professional seperti COBOL, bahasa yang digerakkan peristiwa seperti visual basic ataupun bahasa pemrograman berorientasi objek seperti java atau C++. pemrograman

Bagian ini menyajikan gambaran singkat berbagai pendekatan dan

para

professional

sistem

akan

membuat

keputusan

berdasarkan berbagai standar internal, arsitektur, dan kebutuhan pengguna. 

Bahasa prosedural. Mengharuskan programmer untuk menentukan secara tepat susunan logika yang akan dijalankan. Contoh bahasa prosedural atau bahasa generasi ketiga (third-generation language-3GL) yakni COBOL, FORTRAN, dan PL1. COBOL memiliki kemampuan yang sangat baik untuk melakukan operasi yang sangat terperinci pada setiap record data dan menangani file besar secara efisien. Namun, bahasa ini sangat “ banyak katakatanya” sehingga membuat pemrograman menjadi pekerjaan yang sangat memakan waktu.



Bahasa yang digerakkan peristiwa. Dalam model ini, kode program tidak dijalankan sesuai urutan yang telah ditetapkan. Dimana, tindakan eksternal atau peristiwa yang dilakukan oleh pengguna akan menentukan arus pengendalian program. Visual basic dari Microsoft adalah contoh yang paling terkenal dalam bahasa yang digerakkan oleh peristiwa. Visual basic digunakan untuk membuat aplikasi real-time dan batch yang dapat memproses file datar atau basis data relasional. Dimana bahasa ini memiliki fitur screen-painting yang sangat bagus untuk memfasilitasi pembuatan antarmuka pengguna grafis yang canggih.



Bahasa berorientasi objek. Tujuan dari mewujudkan manfaat pendekatan ini adalah

mengembangkan

perangkat

lunak

menggunakan

bahasa

pemrograman berorientasi objek (object-oriented programming-OOP). Bahasa OOP yang terkenal dan paling murni adalah Java dan Smalltalk. Namun, kurva pembelajaran bahasa OOP sangat curam. Waktu dan biaya untuk pekerjaan ulang dengan OOP adalah penghambat terbesar dalam proses transisi. Oleh karena itu, sebagai kompromi untuk memudahkan transisi telah dikembangkan bahasa hibrida, seperti Object COBOL, Object Pascal, dan C++. 

Pemrograman

Sistem.Apapun

bahasa

pemrograman

yang

digunakan,

program modern seharusnya mengikuti pendekatan modular. Teknik ini menghasilkan beberapa program kecil yang melakukan pekerjaan kecil yang telah ditentukan. Terdapat tiga manfaat terkait pemrograman modular, yaitu: 1.

Efisiensi pemrograman. Beberapa modul dapat dikodekan dan diuji secara independen sehingga akan mengurangi waktu pemrograman. Perusahaan dapat menugaskan beberapa programmer untuk sebuah sistem sehingga beberapa modul akan mampu disatukan menjadi sistem yang utuh.

2.

Efisiensi pemeliharaan. Beberapa modul kecil akan lebih mudah untuk dianalisis dan diubah, hingga dapat mengurangi waktu memulai selama pemeliharaan.

Perubahan

yang

luas

dapat

dibagi

ke

beberapa

programmer secara simultan untuk mempersingkat waktu pemeliharaan. 3.

Pengendalian. Dengan menjaga berbagai modul tetap kecil, maka modul tersebut tidak akan terlalu banyak berisi kesalahan yang besar atau logika yang mengarahkan pada penipuan. Karena setiap modul independen dari modul lainnya, kesalahan yang ada akan berada di modul terkait saja.

Pengujian Perangkat Lunak Aplikasi Semua

modul

program

harus

diuji

secara

menyeluruh

sebelum

diimplementasikan. Terdapat beberapa konsep yang terbukti berhasil mengenai pengujian dan yang harus diikuti pengembangan sistem serta dipertimbangkan auditor dalam melakukan audit. 

Metodologi pengujian. Hasil dari berbagai pengujian akan dibandingkan dengan hasil yang telah ditentukan untuk mengidentifikasi kesalahan pemrograman dan logika.



Melakukan pengujian offline sebelum digunakan secara online.Poin pertama yang sangat penting dalam pengujian adalah tidak pernah meremehkan prinsip pengujian offline sebelum menerapkan sistem online. Menerapkan suatu sistem tanpa pengujian offline adalah cara untuk mengundang bencana.



Data uji. Membuat data uji merupakan hal yang memakan waktu dari aspek pengujianprogram. Akan tetapi dapat memberikan manfaat di masa datang.

Implementasi Sistem-Tahap VII Tahap implementasi sistem dalam proses pengembangan sistem, struktur basis data akan dibuat dan diisi dengan data perlengkapan yang akan dibeli dan diinstal, karyawan dilatih, sistem didokumentasikan, dan sistem yang baru diinstal. Proses implementasi melibatkan berbagai usaha dari para desainer, programer, administrator basis data, pengguna, dan akuntan. Segala aktivitas dalam tahp ini melibatkan biaya yang besar dan sering kali akan menghasbiskan banyak jam kerja personel daripada berbagai tahapan lainnya sebelum implementasi dalam SDLC, jika digabungkan menjadi satu. Menguji Keseluruhan Sistem Semua model yang telah dikodekan dan diuji, selanjutnya modul harus disatukan dan diuji sebagai satu kesatuan. Prosedur ini melibatkan penggunaan sistem untuk memproses data fiktif. Mendokumentasikan Sistem Dokumentasi sistem memberi auditor informasi mendasar mengenai cara sistem bekerja. Kebutuhan dokumentasi untuk tiga kelompok, yaitu: 1.

Dokumentasi desainer dan programer. Desainer dan programer sistem membutuhkan dokumentasi untuk melakukan debug atas kesalahan dan melakukan pemeliharaan sistem. Bagian ini dilibatkan dalam sistem pada tingkat yang sangat teknis hingga membutuhkan informasi umum dan terperinci. Beberapa dari informasi ini disediakan melalui diagram alir data, diagram relasi entitas (ER) dan diagram struktur.

2.

Dokumentasi operator. Operator menggunakan dokumentasi sebagai petunjuk pengoperasian yang menjelaskan cara untuk menjalankan sistem. Isi yang umum dalam sebuah petunjuk pengoperasian terdiri dari : -

nama sistem (sistem pembelian);

-

jadwal pengoperasian (harian, mingguan, jam pada hari kerja);

-

peralatan perangkat keras yang dibutuhkan (pita, disket, printer, atau perangkat keras khusus);

-

kebutuhan file yang menspesifikasikan semua file transaksi (input), file master dan file output yang digunakan dalam sistem;

-

instruksi run-time yang menjelaskan berbagai pesan kesalahan yang mungkin muncul, tindakan yang harus diambil, dan nama serta nomor telpon programmer yang harus dihubungi jika sistem gagal; dan

3.

daftar pengguna yang menerima output dari pengoperasian tersebut.

Dokumentasi pengguna. Para pengguna membutuhkan dokumentasi yang menjelaskan cara untuk menggunakan sistem. Tugas dari pengguna seperti memasukkan input untuk berbagai transaksi, memeriksa saldo akun, memperbarui akun, dan membuat laporan output. Sifat pendokumentasian ini akan tergantung pada tingkat kecanggihan pengguna dalam hal komputer dan teknologi. Jadi, dalam mendesai dokumentasi pengguna, professional sistem harus menilai dan mengklasifikasikan tingkat keahlian pengguna. Terdapat beberapa skema klasifikasi yang mungkin: 

Pemula, hanya memiliki sedikit atau tidak memiliki pengalaman dengan komputer sehingga perlu pelatihan pengguna dan dokumentasi secara ekstensif dan terperinci.



Mantan pengguna, adalah orang yang pernah memahami sistem terkait namun telah lupa pada beberapa perintah dan prosedur penting, sehingga membutuhkan lebih sedikit pelatihan dan dokumentasi daripada pemula.



Pengguna dengan frekuensi penggunaan rendah, mengenal sistem terkait sebatas pada beberapa aspek tertentu saja.



Pengguna sering dan canggih, memahami sistem yang ada dan akan siap untuk beradaptasi dengan sistem yan baru.

4.

Buku Pegangan Pengguna. Dengan pertimbangan klasifikasi tersebut dokumentasi pengguna sering berbentuk buku serta dokumentasi online. Buku pegangan pengguna biasanya berisi gambaran umum sistem dan fungsi utamanya, instruksi untuk memulai, penjelasan prosedur dengan berbagai referensi visual tahap demi tahap, berbagai contoh layar input dan instruksi untuk memasukkan data, daftar lengkap terkait berbagai kode pesan kesalahan dan penjelasannya, buku petunjuk untuk menjalankan sistem, glosarium berbagai istilah penting serta informasi layanan dan dukungan.

5.

Tutorial. Tutorial online dapat digunakan untuk melatih pengguna pemula atau mantan pengguna. Keberhasilan teknik ini berdasarkan pada tingkat realisme tutorial.

6.

Fitur bantuan. Fitur bantuan online berkisar dari yang sederhana sampai yang canggih. Fitur bantuan sederhana dapat berupa tidak lebih dari pesan kesalahan yang ditampilkan di layar.

Mengonversi Basis Data Merupakan tahap yang sangat penting dalam tahap implementasi. Konversi adalah transfer data dari bentuk tertentu keformat atau media yang dibutuhkan oleh sistem yang baru. Tingkat konversi tergantung dari loncatan teknologi dari sistem yang lama ke sistem yang baru. Beberapa aktivitas konversi sangat membutuhkan tenaga kerja karena mengharuskan data dimasukkan ke dalam basis data secara manual. Konversi data sangat berisiko dan harus dikendalikkan dengan hati-hati. Terdapat beberapa peringatan yang harus diterapkan antara lain: 

Validasi. Basis data yang lama harus divalidasi sebelum di konversi. Hal ini membutuhkan analisis pada setiap kelas data untuk menentukan apakah data tersebut harus direproduksi dalam basis data yang baru atau tidak.



Rekonsiliasi. Selanjutnya, basis data yang baru harus di rekonsiliasi dengan aslinya. Dapat dilakukan secara manual, per record, dan per field.



Pencadangan. Salinan file asli harus disimpan sebagai cadangan untuk memeriksa penyimpangan dalam data yang dikonversi.

Konversi ke Sistem yang Baru Proses konversi dari sistem lama ke sistem yang baru disebut sebagai perpindahan. Perpindahan sistem biasanya akan didasarkan pada salah satu dari ketiga pendekatan berikut: 

Perpindahan melalui Operasi Langsung. Perusahaan berpindah ke sistem yang baru dan secara dimultan menghentikan sistem yang lama. Jika dalam mengimplementasi sistem yang sederhana, pendekatan ini merupakan cara termudah dan paling murah. dalam sistem yang kompleks, pendekatan ini yang paling beresiko, karena perpindahan ini sejenis melakukan skydiving tanpa memiliki parasut cadangan.



Perpindahan Bertahap. Dengan membagi sistem baru ke dalam beberapa modul, maka risiko kegagalan sistem akan dapat dikurangi. Namun, pendekatan ini dapat menimbulkan ketidaksesuaian antara subsistem yang

baru dengan subsisem lama yang nantinya akan digantikan tetapi belum diganti. 

Perpindahan Operasi Paralel. Melibatkan pengoperasian sistem lama dan sistem baru secara simultan untuk suatu periode waktu. Keunggulan dari pendekatan ini adalah pengurangan risiko. Dengan menjalankan dua sistem, pengguna dapat merekonsiliasi output untuk mengidentifikasi berbagai kesalahan dan melakukan debug atas kesalahan sebelum menjalankan sistem baru itu secara independen. Gambar 5.11 mengilustrasikan

Peran Auditor dalam Implementasi Sistem Banyak kegagalan sistem disebabkan desain yang kurang baik dan implementasi yang tidak tepat. Sebagai pemegang kepentingan dalam semua sistem keuangan, auditor internal harus memberikan keahliannya dalam proses ini untuk membimbing dan membentuk sistem jadinya. Secara khusus, auditor internal mungkin terlibat dengan cara berikut: 

Menyediakan Keahlian Teknis. Tahap desain terperinci melibatkan spesifikasi tepat berbagai prosedur, aturan, dan konvensi yang akan digunakan dalam sistem terkait.



Menspesifikasi Standar Dokumentasi. Auditor memiliki peran penting dalam hal ini, karena sistem keuangan harus secara teratur diaudit, maka sistem ini harus cukup terdokumentasikan.



Memverifikasi Kecukupan Pengendalian dan Kepatuhan dengan SOX. Aplikasi AIS yang muncul dari SDLC harus memproses kontrol yang memadai. Selain itu, kepatuhan terhadap undang-undang SOX mensyaratkan manajemen untuk menyatakan keberadaan dan keefektifan kontrol tersebut. Selama dalam proses implementasi, fungsi audit internal memainkan peran kunci dalam kegiatan verifikasi dan kepatuhan ini.

Pemeliharaan Sistem - Tahap VIII Pemeliharaan sistem melibatkan perubahan sistem untuk mengakomodasi perubahan dalam kebutuhan pengguna. Perubahan bisa sangat sederhana seperti modifikasi sistem untuk menghasilkan laporan baru atau mengubah panjang field data. Pemeliharaan dapat ekstensif seperti melakukan perubahan besar atas logika aplikasi dan antarmuka pengguna. Periode pemeliharaan sistem dapat berjalan 5 hingga 10 tahun tergantung oleh perusahaan. Pemeliharaan merupakan pengeluaran sumber daya yang signifikan dibandingkan denganmengembangkan- biaya mentawal.Selama rentang hidup sistem ini, sebanyak 80 sampai 90 persen dari total biaya yang mungkintimbul dalam tahap pemeliharaan. PENGENDALIAN DAN AUDIT THE SDLC Dalam bab ini kita telah meninjau proses yang sangat teknis dan kompleks terkait tentang SDLC. SDLC ini berguna menempatkan hal-hal material dalam perspektif yang berkaitan dengan tujuan audit. Secara sederhana, tujuan dari audit keuangan adalah untuk memberikan pendapat ahli mengenai penyajian wajar laporan keuangan.Untuk membuat seperti pendapat itu,auditor ahli harus melakukan tes pemeriksaan tertentu. Tentu, keakuratan data keuangan dalam database klien bergantung pada opini auditor. Dalam lingkungan CBIS, data keuangan diproses (diakses, disimpan, dan diperbarui) oleh aplikasi komunikasi komputer. Keakuratan dan integritas program ini secara langsung mempengaruhi keakuratan data keuangan klien.Aplikasi keuangan yang material cacat dapat merusak data keuangan, yang kemudian menimbulkan kesalahan pelaporan dalam laporan keuangan. Pengembangan

sistem

dan

pemeliharaan

proses

umum

untuk

semua

aplikasi.Sebuah proses pengembangan sistem berfungsi dengan baik memastikan

bahwa hanya aplikasi yang dibutuhkan yang dibuat, sudah ditentukan dengan benar, memiliki kontrol yang memadai, dan sudah benar-benar diuji sebelum aplikasi tersebut diimplementasikan.Proses pemeliharaan sistem memastikan bahwa hanya perubahan yang sah yang dibuat untuk aplikasi dan bahwa perubahan tersebut juga diuji sebelum diimplementasikan. Bersama-sama, proses ini menetapkan akurasi aplikasi baru dan menjaga integritas mereka sepanjang periode laporan. Jika auditor dapat memverifikasi bahwa proses ini dikendalikan secara efektif, ia dapat membatasi tingkat pengujian aplikasi yang perlu dilakukan. Namun, jika bukti audit menunjukkan SDLC Kontrol menjadi lemah dan tidak konsisten diterapkan, pengujian aplikasi dan pengujian substantive tidak dapat dikurangi. Dalam beberapa situasi, bahkan mungkin diperlukan untuk ruang lingkup audit. Pengendalian Pengembangan Sistem Baru Ada lima kegiatan pertama yang dapat dikendalikan yang dibahas selanjutnya berkaitan dengan otorisasi, pengembangan, dan implementasi sistem asli. dua kegiatan terakhir yang dapat dikendalikan berkaitan dengan prosedur pemeliharaan sistem. 1.

Aktivitas Sistem Otorisasi. Sistem ahli harus diotorisasi untuk memastikan pembenaran ekonomi mereka. Seperti dengan semua transaksi material, otorisasi pengembangan infomasi baru system harus menjadi langkah formal dalam proses. Biasanya, ini mensyaratkan bahwa setiap permintaan sistem baru disampaikan secara tertulis oleh pengguna dengan sistem profesional yang memiliki keahlian dan kewenangan untuk mengevaluasi dan menyetujui (atau menolak) permintaan.

2.

Aktivitas Spesifikasi Pengguna. Pengguna harus secara aktif terlibat dalam proses pengembangan sistem. Keterlibatan mereka tidak harus tertahan karena sistem yang diusulkan secara teknis yang kompleks. Terlepas dari teknologi yang terlibat, pengguna harus memberikan penjelasan tertulis secara rinci kebutuhan logis yang harus dipenuhi oleh sistem. Penciptaan pengguna dokumentasi sering melibatkan upaya bersama dari pengguna dan sistem profesional. Namun, hal ini sangat penting bahwa dokumen ini tetap sebuah pernyataan dari kebutuhan pengguna. Ini harus menggambarkan pandangan pengguna dari masalah, bukan bahwa sistem profesional.

3.

Aktivitas Desain Teknis. Kegiatan desain teknis menerjemahkan spesifikasi pengguna ke dalam satu teknis rinci spesifikasi dari sistem yang memenuhi kebutuhan pengguna. Ruang lingkup kegiatan ini meliputi analisis sistem, secara umum desain sistem, analisis kelayakan, dan rincian sistem desain. Kecukupan kegiatan ini diukur dengan kualitas dokumentasi yang muncul dari setiap fase. Dokumentasi merupakan sebuah kontrol dan bukti kontrol dan sangat penting untuk keberhasilan sistem jangka panjang.

4.

Partisipasi Audit Internal. Internal auditor yang memainkan peran penting dalam pengendalian pengembangan sistem khususnya di organisasi yang penggunanya tidak memiliki keahlian teknis. Internal Auditor dapat berfungsi sebagai penghubung antara pengguna dan sistem profesional untuk memastikan transfer pengetahuan secara efektif. Sebuah kelompok audit internal, cerdik dalam teknologi komputer dan dengan pemahaman yang kuat tentang masalah bisnis pengguna, dapat membuat kontribusinya yang berharga untuk semua aspek dari proses SDLC. Auditor harus terlibat diawal dari proses untuk membuat saran konseptual tentang persyaratan sistem dan kontrol. Keterlibatan auditor harus terus seluruh tahapan mengembangkan proses ke tahap pemeliharaan.

5.

Uji Pengguna dan Prosedur Penerimaan. Tepat sebelum pelaksanaan, modul individu dari sistem harus diuji sebagai suatu kesatuan yang utuh. Sebuah tim uji yang terdiri dari personel pengguna, sistem profesional, dan internal personil audit subyek sistem untuk pengujian ketat. Setelah tim uji puas bahwa sistem memenuhi persyaratan yang dinyatakannya, sistem ini secara resmi diterima oleh pengguna departemen. Pengujian formal dan penerimaan sistem oleh pengguna dianggap oleh banyak auditor menjadi kontrol yang paling penting selama SDLC. Ini adalah titik terakhir di mana pengguna dapat menentukan bahwa sistem cukup memenuhi kebutuhannya. Meskipun menemukan cacat besar pada saat ini dapat

mahal,

menemukan

cacat

kemudian,

selama

operasi,

dapat

menghancurkan. Penerimaan pengguna sistem baru harus didokumentasikan secara resmi. Tujuan Audit Terkait dengan Pengembangan Sistem Baru: 1.

Memverifikasi bahwa kegiatan SDLC diterapkan secara konsisten dan sesuai dengan kebijakan manajemen.

2.

Menentukan bahwa sistem seperti awalnya dilaksanakan bebas dari

kesalahan material dan penipuan. 3.

Mengkonfirmasi bahwa sistem ini dinilai perlu dan dibenarkan di berbagai titik pemeriksaan di seluruh SDLC.

4.

Memverifikasi bahwa dokumentasi sistem cukup akurat dan lengkap untuk memfasilitasi kegiatan audit dan pemeliharaan.

Prosedur Audit Terkait dengan Pengembangan Sistem Baru Auditor harus memilih sampel proyek yang sudah selesai (selesai baik dalam periode saatini dan periode sebelumnya) dan meninjau dokumentasi untuk bukti kepatuhan dengankebijakan SDLC. Poin khusus untuk peninjauan harus mencakup penentuan hal-hal berikut: 1.

Pengguna dan manajemen layanankomputer diotorisasi proyek.

2.

Sebuah studi kelayakan awal menunjukkan bahwa proyek telah layak.

3.

Sebuah

analisis

rinci

dari

kebutuhan

pengguna

dilakukan

yang

mengakibatkan desain alternatif. 4.

Sebuah analisis biaya-manfaat dilakukan menggunakan angka yang cukup akurat.

5.

Dokumentasi proyek menunjukkan bahwa desain rinci adalah yang tepat dan solusi akurat untuk masalah pengguna.

6.

Hasil tes menunjukkan bahwa sistem ini benar-benar teruji baik pada individu tingkat sistem total sebelum pelaksanaan. (Untuk mengkonfirmasi hasil tes tersebut, auditor dapat memutuskan untuk menguji ulang elemen yang dipilih dari aplikasi.)

7.

Adadaftar

masalah

tertentu

terdeteksi

selama

periode

konversi,

bersama dengan bukti bahwa mereka dikoreksi dalam tahap pemeliharaan. 8.

Sistem dokumentasi sesuai dengan persyaratan organisasi dan standar.

Pengendalian Sistem Pemeliharaan Dua kegiatan terkendali terakhir berkaitan dengan pemeliharaan sistem.Setelah implementasi sistem memasuki fase pemeliharaan SDLC.Ini adalah periode terpanjang dalam SDLC, sering mencakup beberapa tahun.Hal ini penting untuk menyadari bahwa sistem tidaktetap statis selama periode ini.Sebaliknya, mereka mungkin mengalami perubahan substansialyang merupakan pengeluaran keuangan berkali-kali biaya asli mereka.Jika aplikasi memiliki umur pemeliharaan (dan bahkan jika belum), integritas mungkin telah dikompromikan sejak saat implementasi. Review auditor mungkin, oleh

karena itu, meluas ke pemeliharaantahapuntuk menentukan bahwa integritas aplikasi yang masih utuh. Pada bagian ini, kita melihat bagaimana perubahan program yang tidak terkontrol dapat meningkatkan sikap perusahaan terhadap salah saji keuangan karena kesalahan pemrograman. Beberapa kesalahan pemrograman yang halus, sehingga dalam penciptaan dan distribusi informasi yang salah yang tidakterdeteksi oleh pengguna. Bentuk

lain

dari

kesalahan

yang

lebih

jelas

dan

mengakibatkansistem

kegagalanyang dapat mengganggu pengolahan data dan bahkan membawa operasi berhenti. Selaineksposur ini, penipuan program dapat berakar dilingkungan kurang terkontrol pemeliharaandan bisa tidak terdeteksi selama bertahun-tahun. Pemeliharaan Otorisasi, Pengujian, dan Dokumentasi Manfaat dicapai dari pengendalian pengembangan sistem baru dapat cepat hilang pemeliharaan sistem jika kontrol tidak berlanjut ke tahap itu. Akses ke sistem untuk tujuan pemeliharaan meningkatkan kemungkinan kesalahan sistem. Untuk meminimalkan potensi paparan, semua tindakan pemeliharaan harus memerlukan, sebagai minimum, empat kontrol: otorisasi formal, spesifikasi teknis dari perubahan, pengujian ulang sistem,dan memperbarui dokumentasi. Dengan kata lain, kegiatan pemeliharaan harusdiberikan dasarnya perlakuan yang sama seperti pembangunan baru. Luasnya perubahan dandampak potensial terhadap sistem

harus

mengatur

tingkat

kontrol

diterapkan.

Ketika

pemeliharaan

menyebabkan perubahan yang luas untuk logika program, Kontrol tambahan, sepertiketerlibatan oleh auditor internal dan pelaksanaan uji pengguna dan prosedur penerimaan, mungkin diperlukan.

Sumber Program Perpustakaan Kontrol Terlepas dari prosedur perawatan sebelumnya, integritas aplikasi dapat jeopar-dized oleh individu yang mendapatkan akses tidak sah ke program. Sisa dari ini bagian berkaitan dengan teknik kontrol dan prosedur untuk mencegah dan mendeteksi program aplikasi. Dalam sistem komputer yang lebih besar, kode sumber program aplikasi disimpan pada magnetik disk yang disebut Program Sumber Perpustakaan (SPL). Untuk menjalankan aplikasi produksi, terlebih dahulu harus disusun dan dihubungkan

untuk

membuat

modulbeban

yang

dapat

memproses

Komputer.Sebagai masalah praktis, modul beban yang menyembuhkandan bebas dari ancaman modifikasi yang tidak sah. Perubahan program yang dicapai dengan pembuatan pertama perubahandengansourcecode yang tersimpan di SPL dan kemudian mengkompilasi ulang dan menghubungkan programuntuk membuat modul beban baru yang menggabungkan kode berubah. Oleh karena itu, SPL merupakan daerah sensitif, yang, untuk menjaga integritas aplikasi, harus dengan dikontrol dengan baik.

The Worst-Case Situasi: Tidak ada Kontrol Susunan ini memiliki potensi untuk menciptakan berikut dua bentuk serius dari paparan (lihat daftar berikut): Akses ke program benar-benar dibatasi. Programmer dan lain-lain dapat mengakses program yang tersimpan di perpustakaan, dan tidak ada ketentuan untuk mendeteksi. Oleh karena itu, tidak ada dasar untuk mengandalkan efektivitas Kontrol lainnya. Dengan kata lain, dengan tidak ada ketentuan untuk mendeteksi akses tidak sah ke SPL, integritas Program tidak dapat diverifikasi.

Sebuah Controlled SPL Lingkungan Untuk mengontrol SPL, fitur pelindung dan prosedur harus secara eksplisit ditangani,

dan

ini

membutuhkan

penerapan

sistem

manajemen

SPL

(SPLMS).Software ini digunakan untuk mengontrol empat fungsi rutin tapi penting: (1) menyimpan program pada SPL, (2) mengambil program untuk tujuan pemeliharaan, (3) menghapus program solete dari perpustakaan, dan (4) mendokumentasikan perubahan program untuk memberikanjejak audit dari perubahan. Anda mungkin telah mengakui kesamaan antara sistem manajemen SPL dan sistem manajemen database.Ini adalah analogi yang valid, perbedaan adalah bahwa SPLSoftware mengelola file program dan DBMS mengelola file data. Kehadiran sebuah SPLMS tidak menjamin integritas Program.Sekali lagi, kita dapat menarik analogi dengan DBMS.Untuk mencapai integritas data, DBMS harus benar digunakan; kontrol tidak datang secara otomatis, hal itu harus direncanakan. Demikian juga, sebuahSPL memerlukan teknik perencanaan dan pengendalian khusus untuk memastikan integritas Program. 

Control password. Menetapkan password menyediakan salah satu bentuk kontrol akses atas

SPL. Hal ini mirip dengan Kontrol sandi yang digunakan dalam DBMS untuk melindungi file data. Setiap program finansial yang signifikan disimpan dalam SPL dapat diberi sandi terpisah. Seperti dibahas sebelumnya, password memiliki kelemahan. Sebagai personel lebih berwenang memiliki kebutuhan untuk mengetahui password, potensi kehilangan kontrol password meningkat. Karena tanggungjawab kerahasiaan dari Bersama password terletak dengan kelompok bukan dengan individu, akuntabilitas pribadi berkurang,dan individu dalam kelompok mungkin memakan waktu kurang hati dalam melindungi password. 

Terpisah Uji Perpustakaan Melalui konsep ini, program akan disalin keprogrammerperpustakaan untuk pemeliharaan dan pengujian. Akses langsung ke SPL produksi terbatas untuk seorang pustakawan yang berwenang yang harus menyetujui semua permintaan untuk memodifikasi, menghapus, dan program copy.Selanjutnya, password untuk mengakses program dapat berubah secara teratur dan ditutup hanya atas dasar kebutuhan-untuk-tahu. Sebuah peningkatan yang relatif bebas biaya untuk fitur kontrol ini adalah implementasi darikonvensi Programpenamaan.Nama ditugaskan program jelas membedakannyasebagaibaik tes atau program produksi. Ketika program disalin dari SPLke perpustakaan programmer, itu diberikan sebuah “test” nama sementara. Ketika programdikembalikan ke SPL, itu berganti nama dengan nama produksi aslinya. Teknik ini sangat mengurangi risiko sengaja menjalankan versi belum teruji dari sebuah programdi tempat program produksi.



Audit Trail dan Laporan Manajemen. Sebuah fitur penting dari manajemen SPL Softwareadalah pembuatan laporan yang meningkatkan kontrol manajemen dan audit function. Yang paling digunakan adalah laporan modifikasi program, yang menjelaskan secara rinci semua perubahan program (penambahan dan penghapusan) untuk setiap modul. Laporan-laporan ini harus menjadi bagian dari file dokumentasi setiap aplikasi untuk membentuk jejak audit dari program perubahanselama hidup aplikasi. Selama audit, laporan ini dapat di damaikan terhadap permintaan pemeliharaan program untuk memverifikasi bahwa hanya perubahan yang diminta dan disahkan benar-benar dilaksanakan.



Nomor Program Versi. The SPLMS memberikan nomor versi otomatis untuk setiap program yang tersimpan di SPL. Ketika program pertama kali ditempatkan di perpustakaan (setelah pelaksanaan), mereka ditugaskan nomor versi 0. Dengan setiap modifikasi program, nomor versi bertambah 1.



Mengontrol Akses ke Maintenance Commands. Sistem

manajemen

SPL

menggunakan

pemeliharaan

perintah

untukmengubah atau menghilangkan password Program, mengubah versi program(modifikasi) nomor, dan memodifikasi sementara program tanpa Star ExcursionBalance.Ada alasan teknis yang sah mengapa system desainer dan administrator perlu perintah ini. Jika tidak dikontrol perintah membuka kemungkinan tidak tercatat, dan mungkin tidak sah modifikasi program. Oleh karena itu, akses ke perawatan perintah sendiri harus sandi yang dikendalikan, dan wewenang untuk menggunakannya harus dikontrol oleh manajemen atau grup keamanan.Tujuan Audit Terkait Pemeliharaan Sistem :Deteksi program pemeliharaan yang tidak sah (yang mungkin telah mengakibatka nsignifikan kesalahan Pengolahan atau penipuan). Menentukan bahwa (1) prosedur perawatan melindungi aplikasidari perubahan yang tidak sah,

(2)

aplikasi

bebas

dari

kesalahan

material,

dan

(3)

perpustakaan.Program dilindungi dari akses yang tidak sah.Perludicatat bahwa tanpa SPL Software, biassulit untuk mencapai Audit ini objectives.

Prosedur Audit Terkait dengan Pemeliharaan Sistem 

Identifikasi Perubahan tidak sah Untuk menetapkan bahwa perubahan program yang disahkan, auditor harus memeriksa jejak audit dari perubahan program untuk komplikasiyang telah mengalami perawatan.Auditor dapat mengkonfirmasi bahwa otorisasi dengan melakukan pengujian berikut: a.

Rekonsiliasi Program nomor versi. File permanen aplikasi harusberisi perubahanProgram dokumen otorisasi yang sesuai dengan saat ini nomorversi dari aplikasi produksi.

b.

Mengidentifikasi Kesalahan Aplikasi. Auditor dapat menentukan bahwa program bebas darikesalahan material dengan melakukan tiga jenis tes Controls: mendamaikankode sumber,meninjau hasil tes, dan pengujian ulang program.



Identifikasi Gangguan Aplikasi Auditor dapat menentukan bahwa program bebas dari kesalahan materi dengan melakukan tiga jenis tes kontrol: Rekonsiliasi kode sumber, Hasil Tes Ulasan, dan menguji ulang program.



Uji Akses ke Perpustakaan Adanya program perpustakaan aman adalah Central untukmencegah kesalahan

dan

penipuan

Program.

Salah

satu

metode

adalah

untukmenetapkan hak akses perpustakaankepada individu yang bertindak sebagai pustakawan. Fungsi mereka adalah untuk mengambil aplikasidari perpustakaanprogram pemeliharaan dan memulihkan program dimodifikasi untukperpustakaan.Auditor harus menetapkan bahwa program perpustakaan danperpustakaan swasta dideteksi dari akses yang tidak sah dengan melakukan pengujian berikut Kontrol.Ulasan otoritas programmer tabel. Auditor dapat memilih sampelProgrammerdan meninjau otoritas akses mereka.

Tabel

otoritas

spesifikasi

programmerperpustakaan

dapat

mengakses. Otorisasi ini harus dicocokkanotoritas pemeliharaan programmer untuk memastikan bahwa tidak adapenyimpangan.

BAB III KESIMPULAN

Pengembangan sistem dapat di kelompokkan menjadi empat kelompok besar: yaitu

sistematis

profesional,

pengguna

akuntan/auditor.Sistem profesional

akhir,

pemangku

kepentingan,

dan

sendiriada sistem analis, sistem insinyur, dan

programmer. Sedangkan pengguna akhir mereka untuk siapa sistem ini dibangun. Pemangku kepentingan adalah individu baik di dalam atau di luar organisasi yang memiliki kepentingan dalam sistem tetapi tidak pengguna akhir.Ini termasuk akuntan, internal dan auditoreksternal, dan komite pengarah internal yang mengawasi system pengembangan.Sedangkan

Akuntan/Auditor-orang

profesional

yang

menangani

Controls, akuntansi,dan isu-isu audit untuk pengembangan sistem. Keterlibatan ini harus mencakupantarauditor internal dan auditor IT. Auditor juga memiliki peran yang sangat penting dalam hal ini, yaitu auditor adalah pemangku kepentingan di semua sistem keuangan dan, dengan demikian, memiliki minat dalam mengkonsep tahap desain sistem. The auditability dari sistem sebagian bergantung pada desain. Karakteristik beberapa teknik audit Komputer memerlukan sistem yang akan dirancang dengan fitur-fitur audit khusus yang merupakan bagian integral sistem. Fitur Audit ini harus spesifik pada tahap desain konseptual. Prosedur audit dalam sistem pembangunan yaitu auditor harus memilih sampel proyek yang diselesaikan (selesai pada kedua

berjalan periodedan periode

sebelumnya) dan meninjau dokumentasi untuk bukti kepatuhan terhadap kebijakan SDLC.

REFERENSI

James A. Hall. 2011. Information Technology Auditing and Asurance. Cengage Learning.