Resume Audit Sistem Informasi Week 5: system development and program change activities PDF

Preview

Summary

RESUMEAUDIT SISTEM INFORMASISYSTEMS DEVELOPMENT AND PROGRAM CHANGEACTIVITIESAnggota Kelompok1. Yustica Rachma A 0417113330752. Achmad Bahari Ilmi 0417113331273. I Komang Gede R. G. 0417113331914. Siti Arifah 0419113330105. Dedy Faturachman 0419113331636. Nadiah Fajriati 041911333186PROGRAM STUDI S1 ...

Description

RESUME AUDIT SISTEM INFORMASI SYSTEMS DEVELOPMENT AND PROGRAM CHANGE ACTIVITIES

Anggota Kelompok 1. Yustica Rachma A

041711333075

2. Achmad Bahari Ilmi

041711333127

3. I Komang Gede R. G. 041711333191 4. Siti Arifah

041911333010

5. Dedy Faturachman

041911333163

6. Nadiah Fajriati

041911333186

PROGRAM STUDI S1 AKUNTANSI FAKULTAS EKONOMI DAN BISNIS UNIVERSITAS AIRLANGGA 2021

PARTICIPANTS IN SYSTEMS DEVELOPMENT Para peserta dalam pengembangan sistem dapat diklasifikasikan ke dalam empat kelompok besar: 1. Sistem profesional adalah analis sistem, insinyur sistem. dan programmer. Orangorang ini sebenarnya membangun sistem. Mereka mengumpulkan fakta tentang masalah dengan sistem saat ini, menganalisis fakta-fakta ini, dan merumuskan solusi untuk menyelesaikan masalah. Produk dari upaya mereka adalah sistem baru. 2. Pengguna akhir adalah mereka yang sistemnya dibangun. Ada banyak pengguna di semua tingkatan dalam suatu organisasi. Ini termasuk mengelola, personel operasi, akuntan, dan auditor internal. 3. Stakeholder adalah individu baik di dalam atau di luar organisasi yang memiliki minat dalam sistem tetapi bukan pengguna akhir. Ini termasuk akuntan, auditor internal dan eksternal, dan komite pengarah internal yang mengawasi pengembangan sistem. 4. Akuntan / Auditor adalah profesional di bidangnya yang menangani masalah kontrol, akuntansi, dan audit untuk pengembangan sistem. Keterlibatan ini harus mencakup auditor internal dan auditor TI.

INFORMATION SYSTEMS ACQUISITION Pengembangan In-House Development SDM ini merancang sistem informasi mereka sendiri melalui kegiatan pengembangan sistem in-house. Pengembangan in-house membutuhkan pemeliharaan staf sistem penuh waktu, analis dan programmer yang mengidentifikasi kebutuhan informasi pengguna dan memenuhi kebutuhan mereka dengan sistem biasa. Sistem Komersial/Commercial System Semakin banyak sistem yang dibeli dari vendor perangkat lunak. Dihadapkan dengan banyak paket yang bersaing, manajemen harus memilih sistem dan vendor yang paling baik ketika melayani kebutuhan organisasi. Empat faktor telah merangsang pertumbuhan pasar perangkat lunak komersial: 1. Biaya yang relatif rendah untuk perangkat lunak komersial umum dibandingkan dengan perangkat lunak yang disesuaikan 2. Munculnya vendor khusus industri 3. Meningkatnya permintaan dari bisnis yang terlalu kecil untuk membeli staf pengembangan sistem in-house

4. Tren ke arah perampingan unit organisasi dan langkah yang dihasilkan ke arah lingkungan pemrosesan data terdistribusi. Jenis Sistem Komersial ● Turnkey Systems ● General Accounting Systems ● Special-Purpose Systems ● Office Automation Systems ● Backbone Systems ● Vendor-Supported Systems. THE SYSTEMS DEVELOPMENT LIFE CYCLE Pengembangan sistem baru melibatkan langkah-langkah konseptual yang dapat diterapkan untuk setiap proses penyelesaian masalah: 1) mengidentifikasi masalah, 2)Memahami apa yang perlu dilakukan, 3)Pertimbangkan solusi alternative 4) Pilih solusi terbaik, dan, akhirnya 5) Mengimplementasikan solusinya. Systems Planning—Phase I Who Should Do Systems Planning? Tanggung jawab khas untuk komite pengarah meliputi berikut ini: ● Menyelesaikan konflik yang timbul dari sistem baru ● Meninjau proyek dan menetapkan prioritas ● Dana Anggaran untuk pengembangan sistem ● Mengkaji status proyek individu dalam pengembangan ● Menentukan di berbagai pos pemeriksaan di seluruh SDLC apakah akan melanjutkan dengan proyek atau mengakhiri itu Strategic Systems Planning Perencanaan sistem strategis melibatkan alokasi sumber daya sistem di tingkat makro. Biasanya berkaitan dengan kerangka waktu 3 sampai 5 tahun. Rencana strategis harus memungkinkan spesialis sistem untuk membuat keputusan dengan mempertimbangkan faktor-faktor yang relevan seperti harga, ukuran kinerja, ukuran, keamanan, dan kontrol. Why Do System Strategic Planning? Ada empat alasan untuk perencanaan sistem strategis: ● Sebuah rencana yang berubah secara konstan lebih baik daripada tidak ada rencana sama sekali. ● Perencanaan strategis mengurangi komponen krisis dalam pengembangan sistem.

● Perencanaan sistem Strategis menyediakan kontrol otorisasi untuk SDLC. ● Biaya manajemen. Project Planning Perencanaan proyek bertujuan untuk mengalokasikan sumber daya ke aplikasi individu dalam kerangka kerja rencana strategis. Tahap ini akan menghasilkan 2 dokumen yaitu proposal proyek dan jadwal proyek. The Auditor’s Role in Systems Planning Auditor secara rutin memeriksa tahap perencanaan sistem dari SDLC. Perencanaan mengurangi risiko bahwa organisasi menghasilkan sistem yang tidak dibutuhkan, tidak efisien, tidak efektif, dan curang.

SYSTEMS ANALYSIS - PHASE II The Survey Step Dalam mengembangkan sistem baru, Analis sering memulai analisis dengan menentukan elemen apa, jika ada, dari sistem saat ini yang harus dipertahankan sebagai bagian dari sistem baru. Analisis ini melibatkan survei sistem yang rinci. Gathering Facts Fakta sistem yang dikumpulkan termasuk dalam kelas berikut : ● Data sources

● Transaction volumes

● Users

● Error rates

● Data stores

● Resource costs

● Processes

● Bottlenecks

● Data flows

and

redundant

operations

● Controls Fact-Gathering Techniques ● Observation, analis mengamati prosedur fisik dari sistem secara pasif. ● Task participation, merupakan perpanjangan dari observasi dimana analis mengambil peran aktif dalam melakukan pekerjaan pengguna. ● Personal interviews, metode penggalian fakta tentang sistem yang ada dan persepsi pengguna tentang persyaratan untuk sistem baru. Instrumen yang digunakan untuk mengumpulkan fakta ini dapat berupa pertanyaan terbuka atau kuesioner formal. ● Reviewing key documents, mereview dokumen-dokumen kunci organisasi seperti bagan organisasi, deskripsi pekerjaan, catatan akuntansi, dll.

The Analysis Step Merupakan proses intelektual yang dibarengi dengan pengumpulan fakta. Analis secara bersamaan menganalisis saat dia mengumpulkan fakta. Pengakuan belaka atas suatu masalah mengasumsikan beberapa pemahaman tentang norma atau keadaan yang diinginkan. Systems Analysis Report Laporan analisis sistem menyajikan temuan survei, masalah yang diidentifikasi pada sistem saat ini, kebutuhan pengguna, dan persyaratan sistem baru. Gambar dibawah menunjukkan format dari laporan ini

The Auditor’s Role in Systems Analysis Auditor perusahaan (baik eksternal dan internal) adalah pemangku kepentingan dalam sistem yang diusulkan. akuntan / auditor harus dilibatkan dalam analisis kebutuhan sistem yang diusulkan untuk menentukan apakah itu adalah kandidat yang baik untuk fitur audit tingkat lanjut dan, jika demikian, fitur mana yang paling sesuai untuk sistem.

CONCEPTUAL SYSTEMS DESIGN - PHASE III Tahap ini bertujuan untuk menghasilkan beberapa alternatif sistem konseptual yang memenuhi persyaratan sistem yang diidentifikasi selama analisis sistem. The Structured Design Approach Pendekatan desain terstruktur adalah cara disiplin merancang sistem dari atas ke bawah. Ini terdiri dari memulai dengan "gambaran besar" dari sistem yang diusulkan yang secara bertahap diuraikan menjadi lebih detail hingga dipahami sepenuhnya.

The Object-Oriented Approach Pendekatan orientasi objek untuk desain sistem, pendekatan ini memungkinkan klien untuk menggunakan desain sistem yang sama dengan beberapa modifikasi untuk desain sistem lainnya. Hal ini dapat mengurangi biaya, waktu, pengetesan, dan perawatan.

SYSTEM EVALUATION AND SELECTION - PHASE IV Perform a Detailed Feasibility Study ● Technical Feasibility yang meliputi apakah menggunakan teknologi lama atau baru ● Economic Feasibility meliputi apakah terdapat dana untuk mengembangkannya ● Legal Feasibility ● Operational Feasibility meliputi apakah operasi dan personel skill perusahaan mampu ● Schedule Feasibility meliputi apakah perusahaan mampu menerapkan pada jadwal tertentu Perform a Cost-Benefit Analysis ● Identify Cost meliputi one time cost termasuk investasi awal untuk mengembangkan dan menerapkan sistem. Recurring cost mencakup biaya pengoperasian dan pemeliharaan yang berulang selama umur sistem. Tabel 5.1 menunjukkan rincian biaya satu kali dan biaya berulang. ● Identify Benefits

a. Tangible benefits meliputi increase revenue (meningkatkan penjualan dan dapat ekspansi pada berbagai pasar) dan reduce cost (meliputi pengurangan karyawan, biaya operasi yang menurun, penggunaan persediaan yang efisien, mengurangi peralatan yang mahal, dan mengurangi perawatan peralatan). b. Intangible Benefits yaitu manfaat yang tidak dapat ditentukan nilainya seperti peningkatan kepuasan pelanggan dan karyawan, meningkatkan pembuatan keputusan, etc. ● Compare Cost and Benefits dengan menggunakan teknik net present value (present value of cost deducted present value of the benefits) dan payback method yang menyajikan seberapa lama biaya dapat impas dengan manfaat. Prepare System Selection Report format dokumen mengacu pada studi kelayakan, analisis manfaat dan biaya, dan daftar manfaat intangible serta perbandingan beberapa alternatif desain. The Auditors Role In Evaluation and Selection, auditor seharusnya memperhatikan kelayakan ekonomi dari sistem yang diusulkan. Lima hal yang harus dipastikan yaitu hanya biaya escapable yang digunakan dalam penghematan biaya manfaat, tingkat bunga yang masuk akal, one time dan recurring cost dilaporkan secara akurat, masa manfaat yang realistis, dan intangible benefits diberikan nilai moneter yang wajar.

Detailed Design – Phase V Tujuan dari fase desain terperinci adalah untuk menghasilkan deskripsi terperinci tentang sistem yang diusulkan yang memenuhi persyaratan sistem yang diidentifikasi selama analisis sistem dan sesuai dengan desain konseptual. Dalam fase ini, semua komponen sistem (tampilan pengguna, tabel database, proses, dan kontrol) ditentukan dengan cermat. Pada akhir fase ini, komponen-komponen ini disajikan secara formal dalam laporan desain terperinci. ● Perform a System Design Walkthrough Banyak perusahaan memiliki langkah-langkah formal dan terstruktur yang dilakukan oleh kelompok penjaminan kualitas. Sebagian besar kesalahan sistem berasal dari desain yang buruk daripada kesalahan pemrograman. Mendeteksi dan memperbaiki kesalahan dalam fase desain dengan demikian mengurangi pemrograman ulang yang mahal nantinya. ● Review System Documentation Laporan desain yang terperinci mendokumentasikan dan menjelaskan sistem ke titik ini. Laporan ini meliputi: ➢ Desain untuk semua input layar dan sumber dokumen untuk sistem. ➢ Desain semua output layar, laporan, dan dokumen operasional.

➢ Data yang dinormalisasi untuk tabel database, menentukan semua elemen data. ➢ Struktur dan diagram basis data: diagram Entity Relations (ER) yang menggambarkan hubungan data dalam sistem, diagram konteks untuk keseluruhan sistem, diagram alir data tingkat rendah dari proses sistem tertentu, diagram struktur untuk modul program dalam sistem-termasuk termasuk deskripsi kode semu masing-masing modul. ➢ Kamus data terbaru yang menjelaskan setiap elemen data dalam database. ➢ Pemrosesan logika (diagram alur). Application Programming And Testing – Phase VI Tahap selanjutnya dari SDLC adalah memilih bahasa pemrograman dari antara berbagai bahasa yang tersedia dan cocok untuk aplikasi tersebut. ● Procedural Languages Bahasa prosedural mengharuskan programmer untuk menentukan lebih sering disebut bahasa generasi ketiga (3GLs) ● Event-Driven Languages Bahasa yang dikendalikan oleh acara tidak lagi bersifat prosedural. Di bawah model ini, kode program tidak dieksekusi dalam urutan yang telah ditentukan. Alih-alih, tindakan eksternal atau "peristiwa" yang diprakarsai oleh pengguna menentukan aliran kontrol program. ● Object-Oriented Languages Inti untuk mencapai manfaat dari pendekatan berorientasi objek adalah mengembangkan perangkat lunak dalam bahasa pemrograman berorientasi objek (OOP). ● Programming the System Terlepas dari bahasa pemrograman yang digunakan, program modern harus mengikuti pendekatan modular. Tiga manfaat berikut ini terkait dengan pemrograman modular: 1. Efisiensi pemrograman 2. Efisiensi pemeliharaan 3. Kontrol ● Test the Application Software Semua modul program harus diuji secara menyeluruh sebelum diterapkan. ● Testing Methodology Proses itu sendiri memiliki langkah-langkah terstruktur untuk diikuti. Hasil tes kemudian dibandingkan dengan hasil yang telah ditentukan untuk mengidentifikasi kesalahan pemrograman dan logika.

● Testing Offline Before Deploying Online

Titik pertama yang sangat penting untuk dicoba adalah jangan pernah meremehkan sistem tanpa menguji offline. ● Test Data Membuat data uji yang bermakna adalah aspek pengujian program yang sangat memakan waktu. Namun, kegiatan ini dapat memberikan manfaat di masa depan. System Implementation – Phase VII Dalam fase implementasi sistem dari proses pengembangan sistem, struktur basis data dibuat dan diisi dengan data, peralatan dibeli dan diinstal, karyawan dilatih, sistem didokumentasikan, dan sistem baru dipasang. ● Testing the entire system Ketika semua modul telah dikodekan dan diuji, mereka harus disatukan dan diuji secara keseluruhan. Prosedur ini melibatkan pemrosesan data hipotetis melalui sistem. ● Documenting the system Dokumentasi sistem memberi auditor informasi penting tentang cara kerja sistem. Persyaratan dokumentasi dari tiga kelompok sangat penting. 1. Designers and Programmers Documentation 2. Operator Documentation 3. User Documentation ● Converting the databases Mengkonversi Basis Data Konversi basis data merupakan langkah penting dalam fase implementasi yang berarti transfer data dari bentuk saat ini ke format atau media yang diperlukan oleh sistem baru. Tingkat konversi tergantung pada lompatan teknologi dari sistem yang lama ke yang baru. Dalam hal apa pun, konversi data berisiko dan harus dikontrol dengan hati-hati. Tindakan pencegahan berikut harus diambil: 1. Validation 2. Reconciliation 3. Backup ● Converting to The New Sistem Pergantian sistem biasanya akan mengikuti salah satu dari tiga pendekatan: 1. Cold turkey cutover 2. Phased cutover 3. Parallel operation cutover The Auditor’s Role in System Implementation Peran auditor internal dalam tahap desain dan implementasi rinci harus signifikan. Menjadi pemangku kepentingan di semua sistem keuangan, auditor internal harus memberikan keahlian mereka untuk proses ini untuk memandu dan membentuk sistem jadi. ● Memberikan Keahlian Teknis, Fase desain rinci melibatkan ketepatan prosedur, aturan, dan konvensi yang akan digunakan dalam sistem. Dalam kasus SIA,

spesifikasi ini harus sesuai dengan peraturan GAAP, GAAS, SEC, dan IRS kode. Kegagalan untuk mematuhi dapat menyebabkan eksposur hukum bagi perusahaan. ● Tentukan Standar Dokumentasi Dalam tahap implementasi, auditor berperan dalam menentukan dokumentasi sistem. Karena sistem keuangan harus secara berkala diaudit, mereka harus di dokumentasikan secara memadai. ● Verifikasi Kecukupan Kontrol dan Kepatuhan dengan SOX, Selama proses implementasi, fungsi audit internal memainkan kunci peran dalam verifikasi dan kegiatan kepatuhan ini.

Post- Implementation Review Tinjauan pasca implementasi adalah langkah penting yang terjadi berbulan-bulan kemudian. Dilakukan oleh tim independen untuk mengukur keberhasilan sistem dengan mengumpulkan bukti tentang kecukupan dan risiko. ● Kecukupan desain sistem Fitur fisik ditinjau untuk melihat apakah mereka memenuhi kebutuhan pengguna. ● Ketepatan perkiraan waktu, biaya, dan manfaat Review jumlah aktual vs dianggarkan memberikan input penting untuk keputusan penganggaran di masa depan.

SYSTEMS MAINTENANCE - PHASE VIII ● Proses formal dimana program aplikasi mengalami perubahan untuk mengakomodasi perubahan dalam kebutuhan pengguna. ● Dapat luas dan masa pemeliharaan bisa 5 tahun atau lebih di beberapa organisasi.Ketika mempertahankan sistem lama tidak lagi layak, itu dihapus dan SDLC baru dimulai. ● Merupakan pengeluaran sumber daya yang signifikan.Sebanyak 80% - 90% dari total biaya mungkin dikeluarkan pada tahap pemeliharaan.

Controlling New Systems Development ● Otorisasi sistem, spesifikasi pengguna, dan kegiatan desain teknis. ● Partisipasi audit internal: ○ Perencanaan dan analisis sistem. ○ Desain sistem konseptual berdampak pada kemampuan audit. ○ Kelayakan ekonomi perlu diukur secara akurat.

○ Implementasi sistem. ○ Memberikan keahlian teknis berkaitan dengan aturan akuntansi. ○ Tentukan standar dokumentasi. ○ Verifikasi kecukupan kontrol dan kepatuhan dengan SOX. ● Sebelum implementasi, modul individual harus diuji secara keseluruhan. Pengujian formal dan penerimaan pengguna yang dianggap oleh banyak auditor sebagai kontrol paling penting atas SDLC. ● Tujuan audit adalah untuk memverifikasi: ○ Kegiatan SDLC diterapkan secara konsisten dan sesuai dengan kebijakan manajemen. ○ Sistem asli bebas dari kesalahan materi dan penipuan. ○ Sistem dinilai perlu dan dibenarkan. ○ Dokumentasi memadai dan lengkap. ● Prosedur audit harus menentukan: ○ Pengguna akhir yang tepat dan otorisasi manajemen TI. ○ Studi kelayakan awal menunjukkan proyek memiliki prestasi. ○ Analisis terperinci atas kebutuhan pengguna dilakukan. ○ Analisis biaya-manfaat yang akurat dilakukan. ○ Pengujian sistem terjadi sebelum implementasi. ○ Daftar periksa masalah tertentu yang ditentukan selama konversi diperbaiki selama pemeliharaan. ○ Dokumentasi sistem sesuai dengan standar. The Controlling System Maintenance ● Akses ke sistem untuk pemeliharaan meningkatkan kemungkinan kesalahan sistem. Untuk meminimalkan paparan, semua perawatan harus membutuhkan: otorisasi formal, spesifikasi teknis perubahan, pengujian ulang sistem dan memperbarui dokumentasi. ● Kontrol pustaka program sumber. Kode sumber program disimpan pada disk magnetik yang disebut perpustakaan program sumber (SPL) yang harus dikontrol dengan baik untuk menjaga integritas aplikasi.

The Worst Case Situation: No Controls 1. Akses ke program yang tidak dibatasi sama sekali 2. Karena kelemahan pengendalian, program menjadi rentan akan perubahan yang tidak diotorisasi Lingkungan SPL Terkontrol Untuk mengendalikan SPL, fitur protektif dan prosedur harus ditangani secara eksplisit, dan memerlukan implementasi software sistem manajemen SPL (SPLMS). Software ini digunakan untuk mengendalikan 4 fungsi rutin yang penting: (1) menyimpan program dalam SPL, (2) mengambil program untuk keperluan perawatan, (3) menghapus program yang tidak diperlukan dari library, dan (4) mendokumentasikan perubahan program untuk menyediakan jejak perubahan audit. Berikut merupakan teknik pengendalian untuk menangani area yang rawan dan sebaiknya dipertimbangkan sebagai pengendalian minimum: 1. Pengendalian password 2. Perpustakaan pengujian yang terpisah 3. Laporan manajemen dan jejak audit 4. Nomor versi program 5. Akses pengendalian ke perintah perawatan

Tujuan Audit terkait Perawatan Sistem 1. Mengidentifikasi perubahan yang tidak diotorisasi 2. Mengidentifikasi error pada aplikasi 3. Akses pengujian ke perpustakaan...