1

SYSTEMS DEVELOPMENT AND

PROGRAM CHANGE ACTIVITIES

Tugas Mata Kuliah

Auditing EDP

Oleh Kelompok 9:

1. Diaz Lucky F (180810301036)

2. Brilyan Wahyu G (180810301241)
3. Hamzah Dwi M (180810301247)

PROGRAM STUDI AKUNTANSI

FAKULTAS EKONOMI DAN BISNIS
UNIVERSITAS JEMBER
2021
 2

BAB 1.PENDAHULUAN

Saat ini, penerapan teknologi sangat penting guna menunjang kegiatan organisasi.
Akuntan memiliki beberapa peran dalam pengembangan sistem dewasa ini seperti
Akuntan dilibatkan sebagai Users, akuntan juga berpartisipasi dalam pengembangan
sistem sebagai anggota tim pengembangan, hingga akuntan berpartisipasi dalam
pengembangan sistem sebagai auditor. Sistem informasi akuntansi harus diaudit.
Selain itu, Sebuah perusahaan dapat memenuhi beberapa kebutuhan informasinya
dengan membeli perangkat lunak komersial dan mengembangkan sistem lain secara
internal. Kedua pendekatan tersebut diperkuat oleh prosedur formal yang memberikan
struktur pada proses pengambilan keputusan
Perkembangan operasional perusahaan sangatlah berpengaruh terhadap
sistem yang ada. Sistem dibentuk dan diperoleh dari dua cara yaitu sistem yang dibuat
sendiri atau warisan dan sistem yang dibeli dari pihak ketiga. Suatu sistem juga tetap
harus diuji bagaimana pengembangan sistemnya. Dari rencana pengembangan sistem
sampai evaluasi sangat lah diperlukan. Maka dari itu dengan adanya resume ini
kebutuhan akan pengetahuan mengenai sistem perusahaan sangatlah perlu untuk
dilakukan. Mengingat hal tersebut menjadi kunci akan keefektifan, efesiensi dan
ekonomis suatu perusahaan.
Dalam sistem pemerintahan para partisipan dalam pengembangan sistem
dapat diklasifikasikan menjadii empat kelompok besar seperti profesionalsistem,
pengguna akhir, pemangku kepentingan, dan akuntan atau auditor.Proses SDLC
adalah kepentingan untuk akuntan dan auditor karena ada dua alasan. Pertama, yaitu
penciptaan suatu sistem informasi memerlukan transaksi keuangan yang signifikan.
Secara konseptual, pengembangan sistem adalah seperti proses manufaktur yang
menghasilkan produk yang kompleks melalui serangkaiantahapan. Transaksi tersebut
harus direncanakan, diotorisasi, dijadwalkan, diperhitungkan, dan dikendalikan.
Akuntan yang peduli dengan integritas proses ini seperti mereka dengan setiap proses
manufaktur yang memiliki implikasi sumber daya finansial. Karena latar belakang,
pengalaman, dan pelatihan, akuntan dan auditor yang ahli dalam transaksikeuangan
dan dengan demikian dapat memberikan masukan penting ke dalam sistem mengenai
kontrol, integritas, ketepatan waktu, dan sejumlah aspek penting lain dari transaksii
keuangan.Perhatian kedua dan lebih mendesak untuk akuntan dan auditor adalah
denganmendatangkan produk yang muncul dari SDLC. Kualitas informasi akuntansi
 3

bersandar langsung pada kegiatan SDLC yang menghasilkan sistem informasi

akuntansi (AIS).
Organisasi biasanya memperoleh sistem informasi dalam dua cara yaitu
mereka mengembangakan sistem khusus di rumah melalui kegiatan pengembangan
sistem formal dan mereka membeli sistem komersial dari vendor software.Tujuan dan
urutan systems development life cycle (SDLC) kegiatan yanglogis dan berlaku umum
oleh para ahli dalam komunitas sistem, dan umumnyadiperlakukan sebagai “praktik
terbaik” untuk pengembangan sistem. Namun, jumlah dan nama-namatahap tertentu
dalam proses ini adalah masalah beberapa ketidaksepakatan. Otoritas yang berbeda
telah diusulkan model SDLC dengan sesedikit 4 dan sebanyak 14 kegiatan khusus.
 4

BAB 2. PEMBAHASAN

2.1 Participants In Systems Development

Para partisipan dalam pengembangan sistem dapat diklasifikasikan menjadii
empat kelompok besar seperti profesionalsistem, pengguna akhir, pemangku
kepentingan, dan akuntan / auditor.
1. Profesional sistem adalah analis sistem, insinyur sistem, dan programmer.
Orang-orang ini benar-benar membangun sistem. Mereka mengumpulkan fakta
tentang masalah dengan sistem saat ini, menganalisis fakta-fakta ini, dan
merumuskan solusi untuk memecahkan masalah.Produk dari upaya mereka
adalah sistem baru.
2. Pengguna akhir yang untuk siapa sistem ini dibangun. Ada banyak pengguna di
semua tingkatan dalam suatu organisasi. Ini termasuk manajer, personil operasi,
akuntan, dan internal auditor. Dalam beberapa organisasi, sulit untuk
menemukan seseorang yang bukan pengguna. Selama pengembangan sistem,
profesional sistem bekerja dengan pengguna utama untuk memperoleh
pemahaman tentang masalah pengguna dan pernyataan yang jelas dari
kebutuhan mereka.
3. Pemangku kepentingan adalah individu baik di dalam atau di luar organisasi
yang memiliki kepentingan dalam sistem tetapi bukan pengguna akhir. Ini
termasuk akuntan, internal dan eksternal auditor, dan komite pengarah internal
yang mengawasi pengembangan sistem.
4. Akuntan / Auditor adalah orang profesional yang menangani masalah kontrol,
akuntansi, dan audit untuk pengembangan sistem. Keterlibatan ini harus
mencakup antar auditor internaldan auditor TI. Tentu saja, seperti yang dibahas
dalam Bab 1, undang-undang SOX melarang auditor eksternal dari keterlibatan
langsung dalam audit klien kegiatan pengembangan sistem.
2.1.1 Mengapa Akuntan dan Auditor Terlibat dengan SDLC?
Proses SDLC adalah kepentingan untuk akuntan dan auditor karena ada dua
alasan. Pertama, yaitu penciptaan suatu sistem informasi memerlukan transaksi
keuangan yang signifikan. Secara konseptual, pengembangan sistem adalah seperti
proses manufaktur yang menghasilkan produk yang kompleks melalui
serangkaiantahapan. Transaksi tersebut harus direncanakan, diotorisasi, dijadwalkan,
diperhitungkan, dan dikendalikan. Akuntan yang peduli dengan integritas proses ini
seperti mereka dengan setiap proses manufaktur yang memiliki implikasi sumber daya
 5

finansial. Karena latar belakang, pengalaman, dan pelatihan, akuntan dan auditor yang
ahli dalam transaksikeuangan dan dengan demikian dapat memberikan masukan
penting ke dalam sistem mengenai kontrol, integritas, ketepatan waktu, dan sejumlah
aspek penting lain dari transaksi keuangan.
Perhatian kedua dan lebih mendesak untuk akuntan dan auditor adalah dengan
mendatangkan produk yang muncul dari SDLC. Kualitas informasi akuntansi bersandar
langsung pada kegiatan SDLC yang menghasilkan sistem informasi akuntansi (AIS).
Sistem ini memberikan informasi akuntansi untuk pengguna internal dan eksternal.
Tanggung jawab akuntan adalah untuk memastikan bahwa sistem menggunakan
konvensi dan aturan akuntansi yang tepat, dan memprosesi kontrol yang memadai.
Oleh karena itu, akuntan sangat prihatin dengan kualitas proses yang menghasilkan
AIS. Sebagai contoh, sistem order penjualan diproduksi oleh sebuah SDLC yang rusak
dapat menderita dari kelemahan pengendalian serius yang menyebabkan kesalahan
dalam akuntansi keuangan, catatan, atau memberikan kesempatan untuk kecurangan.
2.1.2 Bagaimana Akuntan Terlibat dengan SDLC?
Akuntan yang terlibat dalam pengembangan sistem dalam tiga cara, yaitu:
1. Akuntan pengguna. Semua sistem yang memproses transaksi keuangan
berdampak fungsi akuntansi dalam beberapa cara. Seperti semua pengguna,
akuntan harus memberikan gambaran yang jelas tentang masalah dan
kebutuhan mereka pada para professional sistem. Sebagai contoh, akuntan
harus menentukan teknik akuntansi yang akan digunakan, persyaratan
pengendalian internal (seperti audit), dan khusus algoritma (seperti model
depresiasi).
2. Akuntan berpartisipasi dalam pengembangan sistem sebagai anggota tim
pengembangan. Keterlibatan mereka sering melampaui perkembangan ketat
komplikasi AIS .Sistem yang tidak memproses transaksi keuangan secara
langsung mungkin masih menarik dari data akuntansi. Akuntan dapat
berkonsultasi untuk memberikan saran atau untuk menentukan apakah sistem
yang diusulkan merupakan risiko pengendalian internal. Dalam semua kasus,
tingkat auditor partisipasi dibatasi oleh isu-isu kemandirian dalam standar
profesional dan etika.
3. Akuntan yang terlibat dalam pengembangan sistem sebagai auditor.
Pembentukan sistem akuntansi harus diaudit. Beberapa teknik audit komputer
memerlukan fitur khusus yang perlu dirancang ke dalam sistem selama SDLC.
Auditor memiliki kepentingan dalam semua sistem dan harus terlibat di awal
 6

desain mereka, terutama yang berkaitan dengan kemampuan audit, keamanan,

dan kontrol.

2.2 Informatiom Systems Acquistion

Organisasi biasanya memperoleh sistem informasi dalam dua cara yaitu mereka
mengembangakan sistem khusus di rumah melalui kegiatan pengembangan sistem
formal dan mereka membeli sistem komersial dari vendor software.
2.2.1 In-House Development
Banyak organisasi memerlukan sistem yang sangat sesuai untuk operasi mereka
yang unik. Perusahaan-perusahaan ini merancang sistem informasi mereka sendiri
melalui kegiatan pengembangkan sistem in-house. Pengembangan in-house
membutuhkan mempertahankan staf sistem penuh waktu dari analis dan programmer
yang mengidentifikasi kebutuhan informasi pengguna dan memenuhi kebutuhan
mereka dengan sistem kustom.
2.2.2 Commercial Systems
Semakin banyak sistem dibeli dari vendor software. Dihadapkan dengan banyak
paket bersaing, masing-masing dengan fitur unik dan atribut, manajemen harus
memilih sistem dan vendor yang terbaik untuk melayani kebutuhan organisasi.
Membuat pilihan yang mensyaratkan bahwa ini menjadi keputusan.
a. Tren pada Software Komersial
Empat faktor yang mendorong pertumbuhan pasar Software komersial:
1. Biaya yang relatif rendah untuksoftware komersial umum dibandingkan
dengan software khusus.
2. Munculnya vendor spesifik-industri yang menargetkan software mereka
untuk kebutuhan jenis bisnis tertentu.
3. Meningkatnya permintaan dari bisnis yang terlalu kecil untuk membeli di
staf pengembangan sistem in-house.
4. Kecenderungan ke arah pengecilan unit organisasi dan langkah yang
dihasilkan terhadap lingkungan pemrosesan data terdistribusi, yang telah
membuat opsi software komersial lebih menarik bagi organisasi yang lebih
besar.
b. Jenis Sistem Komersial
1. Turnkey System. Sistem turnkey sepenuhnya selesai dan sistem teruji
yang siap untuk implementasi. Ini sering merupakan sistem tujuan umum
atau sistem yang disesuaikan untuk industri tertentu. Sistem turnkey
 7

biasanya dijual hanya sebagai modul disusun,dan pengguna memiliki

kemampuan untuk menyesuaikan mereka dengan kebutuhan khusus
merekaterbatas. Beberapa sistem turnkey memiliki pilihan Software yang
memungkinkan pengguna untuk menyesuaikan input, output dan beberapa
pengolahan melalui pilihan menu. Vendor sistem turnkey lainnya akan
menjualpelanggan mereka kode sumber jika perubahan program yang
diinginkan. Untuk biaya, pengguna atau vendorkemudian dapat
menyesuaikan sistem dengan memprogram ulang kode sumber asli.
2. General Accounting System. Sistem akuntansi umum yang dirancang untuk
melayani berbagai kebutuhan pengguna. Dengan memproduksi secara
massal sistem standar, vendor dapat mengurangi biaya unit sistem ini
menjadi sebagian kecil dari biaya pengembangan in-house. Sistem
semacam ini dapat diperoleh untuk di bawah $ 2.000.
3. Special-Purpose system. Beberapa vendor perangkat lunak menciptakan
sistem tujuan khusus yang menargetkan segmen ekonomi yang dipilih.
Misalnya, bidang medis,industri perbankan,dan lembaga pemerintah yang
memiliki prosedur akuntansi unik, peraturan, dan bahwa sistem akuntansi
tujuan umum tidak selalu mengakomodasi. Software vendor telah demikian
mengembangkan sistemstandar untuk menangani prosedur industri
tertentu.
4. Office Automation Systems. Sistem otomatisasi kantor adalah sistem
komputer yang meningkatkan produktivitas pekerja kantor. Contoh sistem
otomatisasi kantor termasuk kata pemrosesan, sistem manajemen
database, program spreadsheet, dan sistem desktop publishing.
5. Backbone System. Sistem Backbone menyediakan struktur sistem dasar
untuk membangun. Sistem Backbone datang dengan semua pengolahan
primer modul pemrograman. Vendor desain dan program antarmuka
pengguna sesuai dengan kebutuhan klien. Beberapa sistem seperti
Enterprise Resource Planning (ERP) menawarkan susunan yang luas dari
modul dengan hampir setiap proses bisnis dibayangkan, dan semua yang
dihubungkan mulus ke dalam sistem tunggal.
6. Vendor-Supported Systems. Sistem vendor yang didukung adalah
campuran sistem kustom dan software komersial. Dalam pendekatan ini,
vendor mengembangkan (dan mempertahankan) sistem kustom untuk
klien. Sistem itu sendiri adalah produk kustom, tetapi sistem layanan
 8

pengembangan secara komersial disediakan. Pilihan ini populer

diperawatan kesehatan dan industri layanan hukum. Sejak vendor
berfungsi sebagai organisasi sistem in-house, pengembangan staf
organisasi klien harus bergantung pada vendor untuk menyediakan
pemeliharaan di tempat sistem.
c. Keuntungan Sistem Komersial
1. Waktu implementasi. Sistem kustom sering mengambil waktu yang lama
untuk berkembang. Beberapa bulan atau bahkan bertahun-tahun mungkin
berlalu sebelum sistem kustom dapat dikembangkan melalui di prosedur
rumah. Kecuali organisasi berhasil mengantisipasi informasi
perkembangan kebutuhan masa depan dan jadwal aplikasi yang sesuai,
mungkin mengalami kebutuhan periode panjang. Namun, software
komersial dapat dilaksanakan segera setelah kebutuhan diakui. Pengguna
tidak perlu menunggu.
2. Biaya. Pengguna tunggal harus sepenuhnya menyerap biaya
pembangunan rumah. Namun, karena biaya software komersial tersebar di
banyak pengguna, biaya unit berkurang untuk sebagian kecil dari biaya
sistem yang dikembangkan di rumah.
3. Keandalan. Kebanyakan paket software komersial terkemuka yang diuji
secara menyeluruh kedepan pembebasan mereka ke pasar konsumen.
Setiap sistem kesalahan tidak ditemukan selama pengujian kemungkinan
akan ditemukan oleh organisasi pengguna lama setelah rilis dan dikoreksi.
d. Kekurangan Sistem Komersial
1. Kebebasan. Ketika membeli sistem dari vendor maka dalam hal tersebut
dapat membuat perusahaan tergantung pada vendor dalam system
pemeliharaannya. Pengguna menjalankan risiko bahwa vendor akan
berhenti mendukung sistem atau bahkan keluar dari bisnis. Ini mungkin
kerugian terbesar dari sistem vendor-supported.
2. Kebutuhan untuk sistem disesuaikan. Keuntungan utama dari
pembangunan in-house adalah kemampuan untuk menghasilkan aplikasi
dengan spesifikasi yang tepat. Keuntungan ini juga menjelaskan k
elemahan dari software komersial. Kadang-kadang, kebutuhan pengguna
yang unik dalam ketersediaan software seringnya terlalu umum atau
kurang fleksibel.
3. Pemeliharaan. Sistem informasi bisnis sering mengalami perubahan. Jika
 9

kebutuhan pengguna berubah, mungkin akan sulit atau bahkan tidak

mungkin untuk memodifikasi software komersial. Maksudnya adalah dalam
pengembangan in-house, bagaimanapun harus menyediakan aplikasi
khusus yang dapat dipertahankan secara ekonomis.

2.3 The Systems Development Life Cycle

Baik pembangunan in-house dan pilihan paket komersial memiliki kelebihan dan
kekurangan. Mereka tidak, bagaimanapun, proposisi saling eksklusif. Sebuah
perusahaan dapat memenuhi beberapa kebutuhan informasi dengan membeli
Software komersial dan develop sistem lain di rumah. Kedua pendekatan diperkuat
oleh prosedur formal yang meminjamkan struktur dengan proses pengambilan
keputusan. The system development life cycle atau siklus hidup pengembangan sistem
pada umumnya terkait dengan pembangunan in house, tapi dalam siklus ini banyak
melalui fase atau proses, terutama yang melibatkan analisis kebutuhan dan spesifikasi
sistem, dapat secara efektif digunakan bahkan ketika sistem final dibeli dari vendor
luar.
Tujuan dan urutan systems development life cycle (SDLC) kegiatan yang logis
dan berlaku umum oleh para ahli dalam komunitas sistem, dan umumnya diperlakukan
sebagai “praktik terbaik” untuk pengembangan sistem. Namun, jumlah dan nama-nama
tahap tertentu dalam proses ini adalah masalah beberapa ketidaksepakatan. Otoritas
yang berbeda telah diusulkan model SDLC dengan sesedikit 4 dan sebanyak 14
kegiatan khusus. Dari sudut pandang audit, jumlah tahap sebenarnya tidak ada impor
tertentu. Kami prihatin tentang substansi dan aplikasi yang konsisten dari proses ini,
namun didefinisikan.
Tujuh fase pertama dari SDLC menggambarkan semua kegiatan yang harus
dijalani sistem baru. Pengembangan sistem baru melibatkan langkah-langkah
konseptual yang dapat berlaku untuk setiap proses pemecahan masalah: seperti
mengidentifikasi masalah, memahami apa yang perlu dilakukan, pertimbangkan solusi
alternatif, memilih solusi terbaik, dan akhirnya, menerapkan solusi. Setiap fase dalam
SDLC menghasilkan satu set dokumentasi yang diperlukan yang bersama-sama
merupakan tubuh bukti audit tentang kualitas keseluruhan SDLC. Langkah kedelapan,
pemeliharaan sistem, yang merupakan prosedur perubahan program organisasi. Ini
dimulai setelah tujuh fase yang lengkap dan sistem ini sepenuhnya dilaksanakan.
2.3.1 Sistem Perencanaan-Tahap I
Tujuan perencanaan sistem adalah untuk menghubungkan proyek sistem
 10

individual atau aplikasi untuk tujuan strategis perusahaan. Bahkan, dasar untuk
rencana sistem adalah rencana bisnis yang menentukan di mana perusahaan
berencana untuk pergi dan bagaimana hal itu akan sampai ke sana. Secara khusus,
proyek sistem dianalisis dengan menggunakan rencana strategis TI, yang terbuka dari
dan sebangun dengan rencana bisnis organisasi. Harus ada keselarasan antara
proyek-proyek individu dan rencana bisnis, atau perusahaan mungkin gagal untuk
memenuhi tujuannya. Perencanaan sistem yang efektif memberikan keselarasan dari
tujuan ini.
2.3.2 Siapa yang Harus Lakukan Sistem Perencanaan?
Sebagian besar perusahaan yang mengambil sistem perencanaan untuk
membentuk pengendalian system komite untuk memberikan bimbingan dan meninjau
status proyek sistem. Komposisi komite pengarah mungkin termasuk CEO, CFO,
petugas kepala informasi, manajemen senior dari daerah pengguna, auditor internal,
dan manajemen senior dari layanan komputer. Pihak eksternal, seperti manajemen
konsultan dan auditor eksternal perusahaan, juga dapat melengkapi komite. Tanggung
jawab untuk komite pengarah meliputi:
a. Menyelesaikan konflik yang timbul dari sistem baru
b. Meninjau proyek dan menetapkan prioritas
c. Penganggaran dana untuk pengembangan system
d. Mengkaji status masing-masing proyek dalam pengembangan
e. Menentukan di berbagai pos pemeriksaan di seluruh SDLC apakah akan
melanjutkan dengan proyek atau mengakhiri.
Sistem perencanaan terjadi pada dua tingkat: sistem perencanaan strategis dan
proyek perencanaan.
2.3.3 Sistem Perencanaan Strategis
Sistem perencanaan strategis melibatkan alokasi sumber daya sistem ditingkat
makro. Ini biasanya berhubungan dengan jangka waktu 3 sampai 5 tahun. Proses ini
mirip dengan anggaran sumber daya untuk kegiatan strategis lainnya, seperti
pengembangan produk, diskusi, riset pasar, dan teknologi manufaktur.
Secara teknis, sistem perencanaan strategis adalah bukan bagian dari SDLC
karena SDLC untuk aplikasi khusus. Rencana sistem strategis berkaitan dengan
alokasi sumber daya seperti sistem sebagai karyawan (jumlah sistem profesional untuk
dipekerjakan), perangkat keras (jumlah workstation, minicomputer, dan mainframe
untuk dilakukan), software (dana untuk dialokasikan untuk proyek-proyek sistem baru
dan untuk sistem pemeliharaan), dan telekomunikasi (dana yang dialokasikan untuk
 11

jaringan dan EDI). Hal ini adalah penting bahwa rencana strategis menghindari detail
yang berlebihan. Rencana harus memungkinkan sistem spesialisuntuk membuat
keputusan dengan mempertimbangkan faktor-faktor yang relevan seperti harga,
langkah-langkah pengukuran, keamanan, dan kontrol.
Mengapa Lakukan Sistem Perencanaan Strategis? Mungkin tidak ada
spekbisnis perusahaan kegiatanadalahsebagai volatile dan tak terduga sebagai
perencanaan sistem informasi. Siapa yang dapat melihat 5 tahun ke depan dan akurat
memprediksi negara sistem teknologi? Karena volatilitas ini, setiap jangka panjang
merencanakan merek perusahaan cenderung berubah. Bagaimana, oleh karena itu,
dapat suatu perusahaan melakukan perencanaan sistem strategis? Mengapa harus?
2.3.4 Proyek Perencanaan
Tujuan dari perencanaan proyek adalah untuk mengalokasikan sumber daya
untuk aplikasi individual dalam kerangka rencana strategis. Ini melibatkan identifikasi
bidang kebutuhan pengguna, mempersiapkan proposal, evaluasi kelayakan setiap
usulan dan kontribusi terhadapbisnis, rencana memprioritaskan proyek-proyekindividu,
dan penjadwalan pekerjaan yang harus dilakukan.Tujuan dariperencanaan proyek
adalah untuk mengalokasikan sumber daya yang langka untuk proyek-proyek tertentu.
Produk dari fase ini terdiri dari dua dokumen resmi: proposal proyek dan jadwal proyek.
Proposal proyek menyediakan manajemen dengan dasar untuk memutuskan
apakah akanmelanjutkan proyek tersebut. Proposal resmi melayani dua tujuan.
Pertama, merangkumtemuan dari penelitian yang dilakukan ke titik ini menjadi
rekomendasi umum untuk sebuah sistem baru atau diubah. Hal ini memungkinkan
manajemen untuk mengevaluasi masalah yang dirasakan bersama dengan sistem
yang diusulkan sebagai solusi yang layak. Kedua, proposal menjelaskan
hubunganantara tujuan dari sistem yang diusulkan dan tujuan bisnisperusahaan,
terutama yang digariskan dalam rencana strategis TI. Hal ini menunjukkan bahwa baru
yang diusulkan sistemmelengkapi arah strategis perusahaan.
Jadwal proyek merupakan komitmen manajemen untuk proyek.Jadwalproyek
adalah anggaran dari waktu dan biaya untuk semua tahapan SDLC. Sebuah proyek
dipilih dari sistem profesional, pengguna akhir, dan spesialis lain seperti akuntan dan
auditor internal akan menyelesaikan fase-fase ini. Komposisi tim
dan kompetensi dan dedikasi anggotanya sangat penting untuk keberhasilan
sistem baru.
2.3.5 Peran Auditor dalam Sistem Perencanaan
Auditor secara rutin memeriksa fase perencanaan sistem SDLC. Perencanaan
 12

sangat mengurangi risiko bahwa suatu organisasi telah menghasilkan yang tidak
dibutuhkan, tidak efisien, tidak efektif, dan sistem penipuan. Oleh karena itu, auditor
baik internal dan eksternal tertarik dalam memastikan bahwa sistem yang memadai
perencanaan berlangsung.
2.3.6 Systems Analysis-Tahap II
Sekarang Kami beralih ke tahap kedua di SDLC. Analisis sistem sebenarnya
adalah sebuah dua langkah proses melibatkan pertama survei dari sistem saat ini dan
kemudian analisis pengguna. Kebutuhan sebuah masalah bisnis harus sepenuhnya
dipahami oleh analis sistem sebelum dia dapat merumuskan solusi. Sebuah analisis
yang tidak lengkap atau rusak akan menyebabkan solusi tidak lengkap atau rusak.
Oleh karena itu, analisis sistem adalah dasar untuk sisa SDLC. Hasil dari fase ini
adalah laporan analisis sistem formal, yang menyajikan temuan dari analisis dan
rekomendasi untuk sistem yang baru.
2.3.7 Langkah Survei
Kebanyakan sistem tidak dikembangkan dari awal. Biasanya, beberapa bentuk
sistem informasi dan prosedur terkait saat ini di tempat. Analis sering dimulai analisis
dengan menentukan unsur-unsur apa, jika ada, dari sistem saat ini harus
dipertahankan sebagai bagian dari sistem baru. Hal ini melibatkan survei sistem yang
agak rinci. Fakta yang berkaitan dengan pertanyaan liminaris tentang sistem
dikumpulkan dan dianalisis. Sebagai analis memperoleh lebih mendalam pemahaman
masalah, ia mengembangkan yang lebih spesifik pertanyaan yang lebih banyak fakta
harus dikumpulkan. Proses ini dapat berlangsung melalui beberapa iterasi. Ketika
semua fakta yang relevan telah dikumpulkan dan dianalisis, analis tiba pada penilaian
di sistem saat ini. Survei sistem saat ini memiliki kelebihan dan keuntungan.
1. Kekurangan Survei Current System
a. Current physical tar pit. Istilah ini digunakan untuk menggambarkan
kecenderungan pada bagian analisis untuk menjadi “tersedot” dan
kemudian “macet” oleh tugas survey sistemdinosaurus saat ini.
b. Thinking inside the box. Beberapa berpendapat bahwa survei sistem saat
menahan ide-ide baru. Dengan mempelajari dan pemodelan sistem yang
lama, analis dapat mengembangkan gagasan dibatasi tentang bagaimana
sistem baru harus berfungsi. Hasilnya adalah sistem lama ditingkatkan
daripada pendekatan baru yang radikal.
2. Keuntungan dari Survei Current System
a. Mengidentifikasi aspek apa dari sistem lama harus disimpan. Beberapa
 13

elemen dari sistemmungkin fungsional suara dan dapat memberikan dasar

untuk sistem baru. Dengan sepenuhnya memahami sistem saat ini, analis
dapat mengidentifikasi aspek-aspek layak melestarikan atau memodifikasi
untuk digunakan dalam sistem baru.
b. Memaksa analis sistem untuk memahami sistem. Ketika sistem baru im-
diimplementasikan ini, pengguna harus melalui proses konversi dimana
mereka secara resmi melepaskan diri dari sistem lama dan pindah ke yang
baru. Analis harus menentukanapa tugas, prosedur, dan data akan dihapus
dengan sistem lama dan yang akan terus berlanjut. Untuk menentukan
prosedur konversi ini, analis harus mengetahui tidak hanya apa yang harus
dilakukan oleh sistem baru, tetapi juga apa yang dilakukan oleh yang lama.
Hal ini memerlukan pemahaman yang menyeluruh dari sistem saat ini.
c. Mengisolasi akar gejala masalah. Dengan mengamati sistem saat ini,
analis dapat menentukan secara meyakinkan penyebab gejala masalah
yang dilaporkan. Mungkinakar masalah adalah bukan sistem informasi
sama sekali; mungkin manajemen atau masalahkaryawan yang dapat
diselesaikan tanpa mendesain ulang sistem informasi. Kita mungkin tidak
dapat mengidentifikasi akar penyebab masalah jika kita membuang mantan
system tanpa penyelidikan gejala.
2.3.8 Mengumpulkan Fakta
Survei dari sistem saat ini pada dasarnya adalah kegiatan pengumpulan fakta.
Fakta-fakta yang dikumpulkan oleh analis adalah potongan-potongan data yang
menjelaskan fitur kunci, situasi, dan hubungan sistem. Fakta sistem termasuk dalam
kelas luas berikut:
1. Sumber data. Ini termasuk entitas eksternal, seperti pelanggan atau vendor,
serta sumber internal dari departemen lain.
2. Pengguna. Ini termasuk kedua manajer dan pengguna operasi data.
3. Tokodata. Toko data adalah file, database, rekening, dan dokumen sumberyang
digunakan dalam sistem.
4. Proses. Tugas pengolahan yang operasi manual atau komputer yang mewakili
keputusannya atau tindakan dipicu oleh informasi.
5. Arus data. Arus data yang diwakili oleh gerakan dokumen dan laporan antara
sumber data, toko data, tugas pengolahan, dan pengguna. Arus data juga dapat
direpresentasikan dalam diagram UML.
6. Kontrol. Ini termasuk baik akuntansi dan kontrol operasional dan mungkin
 14

manusia prosedurual atau kontrol komputer.

7. Volume transaksi. Analis harus mendapatkan ukuran transaksi volumeuntuk
jangka waktu tertentu. Banyak sistem yang diganti karena mereka telahmencapai
kapasitas mereka. Memahami karakteristik transaksi sistemvolumedan laju
pertumbuhan merupakan elemen penting dalam menilai kapasitas persyaratan
bagi sistem baru.
8. Tingkat kesalahan. Kesalahan transaksi terkait erat dengan volume transaksi.
Sebagai sistematis 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 yang sistembaru.
9. Biaya sumber daya. Sumber daya yang digunakan oleh sistem saat ini meliputi
biaya tenaga kerja, waktu komputer, bahan (seperti faktur), dan overhead
langsung. Setiap biaya sumber daya yang hilang saat sistem saat dihilangkan
disebut biaya escapable. Kemudian, ketika kita melakukan analisis biaya-
manfaat, biaya escapable akan diperlakukan sebagai manfaat dari sistem baru.
10. Kemacetan dan operasi berlebihan. Analis harus mencatat poin di manaarus
data yang datang bersama untuk membentuk kemacetan. Pada periode puncak-
beban, ini dapat mengakibatkan penundaan dan mempromosikan kesalahan
pengolahan. Demikian juga, penundaan mungkin disebabkan oleh operasi
berlebihan, seperti persetujuan yang tidak perlu atau sign-off. Dengan
mengidentifikasiarea masalah iniselama fase survei, analis dapat menghindari
membuat kesalahan yang sama dalam desain sistem baru.

2.4 Controling and Auditing The SDLC

Pengembangan sistem (SDLC) adalah metodologi yang dapat digunakan untuk
mengembangkan atau memodifikasi sistem aplikasi. Setiap organisasi harus
menetapkan metodologi SDLC dan menetapkan tanggung jawab untuk setiap fase
siklus sehingga desain sistem, pengembangan, dan pemeliharaan dapat berkembang
dengan lancar dan akurat. Siklus ini dimulai dengan kebutuhan yang dirasakan dan
meluas melalui studi kelayakan, desain dan pengembangan, pengujian, implementasi,
penerimaan dan persetujuan sistem, tinjauan pasca-implementasi, dan pemeliharaan
aplikasi dan perangkat lunak sistem. Mengikuti setiap fase siklus ini memastikan
bahwa perangkat lunak baru atau yang direvisi memenuhi kebutuhan organisasi,
bahwa kontrol internal yang memadai konsisten dengan tujuan manajemen, dan
bahwa aplikasi tersebut diimplementasikan dengan benar.
 15

Program audit ini mengasumsikan bahwa sistem aplikasi dikembangkan oleh staf
pemrograman in-house. Namun, sistem aplikasi yang digunakan oleh banyak lembaga
negara tidak dikembangkan sendiri melainkan dibeli. Dalam hal ini, semua langkah
yang dilakukan selama pengembangan in-house dari suatu aplikasi tidak berlaku untuk
perangkat lunak yang dibeli. Secara khusus, standar sistem dan pemrograman, dan
spesifikasi file dan pemrograman tidak diperlukan.
 16

BAB 3. KESIMPULAN

Banyak organisasi memerlukan sistem yang sangat sesuai untuk operasi

mereka. Perusahaan-perusahaan ini merancang sistem informasi mereka sendiri
melalui kegiatan pengembangkansistem in-house. Pengembangan in-house
membutuhkan mempertahankan staf sistem penuh waktu dari analis dan programmer
yang mengidentifikasi kebutuhan informasi pengguna dan memenuhi kebutuhan
mereka dengan sistem kustom.Perusahaan-perusahaan ini merancang sistem
informasi mereka sendiri melalui kegiatan pengembangkan sistem in-house.
Pengembangan ini house membutuhkan mempertahankan staf sistem penuh waktu
dari analis dan programmer yang mengidentifikasi kebutuhan informasi pengguna dan
memenuhi kebutuhan mereka dengan sistem kustom.
Tujuan perencanaan sistem adalah untuk menghubungkan proyek sistem
individualatau aplikasi untuk tujuan strategis perusahaan. Bahkan, dasar untuk
rencana sistem adalah rencana bisnis yang menentukan di mana perusahaan
berencana untuk pergi dan bagaimana hal itu akan sampai ke sana. Secara khusus,
proyek sistem dianalisis dengan menggunakan rencana strategis TI, yang terbuka dari
dan sebangun dengan rencana bisnis organisasi. Harus ada keselarasan antara
proyek-proyek individu dan rencana bisnis, atau perusahaan mungkin gagal untuk
memenuhi tujuannya. Perencanaan sistem yang efektif memberikan keselarasan
tujuan ini.
 17

DAFTAR PUSTAKA

Hall, James A. 2011. Information Technology Auditing and Assurance. Third

Edition. USA: Cengage Learning. Ebook.