PENGEMBANGAN SISTEM DAN KEGIATAN PERUBAHAN

PROGRAM

Tugas Mata Kuliah

Auditing EDP

Oleh :
Kelompok 1
1. Dita Ayu Pratiwi (170810301073)
2. Ghuirani Syabellail (170810301082)
3. Muhammad Hodaki (170810301151)
4. Ahmad Romli (170810301194)
5. Yulan Arias Tifany (170810301252)

PROGRAM STUDI AKUNTANSI

FAKULTAS EKONOMI
UNIVERSITAS JEMBER
2020
 BAB 1. PENDAHULUAN

Sebuah perusahaan merupakan gabungan dari berbagai sub sistem yang

memiliki fungsi khusus tersendiri untuk mendukung aktivitas perusahaan. Di jaman
modern ini, aktivitas perusahaan sangat komplek dan terperinci, terdiri dari berbagai
kegiatan dan subkegiatan yang saling mendukung satu sama lain baik secara
langsung maupun tidak langsung. Aktivitas-aktivitas tersebut dapat berupa,
pemrosesan transaksi, keuangan, dan sumber daya manusia. Dalam mengorganisir
berbagai kegiatan yang banyak dan kompleks tersebut, perusahaan memerlukan
sebuah sistem yang mempuni untuk mengakomodasi setiap kebutuhan dari pengguna.
Untuk membuat sistem yang baik dan dapat mengakomodir berbagai kebutuhan
diperlukan pengembangan sistem yang terencana dengan baik dan
berkesinambungan.

Belakangan ini, teknologi berkembang dengan sangat pesat terutama teknologi

informasi dan komunikasi. Hal tersebut menyebabkan opsi yang sangat memadai
untuk sebuah sistem dapat memenuhi kebutuhan pengguna dengan baik, terutama di
segmen integrasi dan kecepatan pemrosesan. Namun disisi lain perkembangan
teknologi yang amat pesat ini mengakibatkan perusahaan harus berkomitmen untuk
pengembangan sistem informasi dan pemrosesan transaksi secara berkelanjutan,
karena dengan pesatnya teknologi, suatu defice akan cepat menjadi terasa kuno dan
ketinggalan jaman, begitu pula sistem yang didukung oleh defice tersebut, sehingga
secara berkelanjutan diperlukan berbagai pengembangan di berbagai subsistem.
Proses pernggantian dan pengembangan sistem baru yang dilakukan secara
berkelanjutan disebut dengan Sistem Development Life Cycle (SDLC)

Topik ini menarik untuk diteliti karena Perkembangan akuntansi yang

menyangkut SIA berbasis komputer dalam menghasilkan laporan keuangan akan
mempengaruhi praktik pengauditan. Perubahan proses akuntansi akan mempengaruhi
proses audit karena audit merupakan suatu bidang praktik yang menggunakan laporan
keuangan (produk akuntansi) sebagai objeknya. Kemajuan TI juga mempengaruhi
perkembangan proses audit. Kemajuan software audit memfasilitasi pendekatan audit
berbasis komputer. Akuntan merupakan profesi yang aktivitasnya banyak berhubungan
dengan TI. Perkembangan SIA dan proses audit sebagai akibat dari adanya kemajuan
TI dan perkembangan akuntansi akan memunculkan peluang bagi akuntan.

1
 Peluang ini dapat dimanfaatkan oleh akuntan yang mempunyai pengetahuan
memadai tentang SIA dan audit berbasis komputer. Sebaliknya, akuntan yang tidak
mempunyai pengetahuan yang cukup tentang SIA dan audit berbasis komputer akan
tergusur posisinya karena tidak mampu memberikan jasa yang diperlukan oleh klien.

Salah satu aset perusahaan modern yang berharga adalah sistem informasi
yang responsif dan berorientasi pada pengguna. Sistem yang yang didesain dengan
baik dapat meningkatkan produktivitas, mengurangi persediaan, meniadakan aktivitas
tidak bernilai tambah, memperbaiki layanan pelanggan dan keputusan manajemen
serta mengkoordinasikan berbagai aktivitas di seluruh perusahaan. Tulisan ini
membahas mengenai Aktivitas Pengembangan dan Pemiliharaan Sistem yang dapat
memudahkan auditor dalam melakukan tugas pengauditannya.
 BAB 2. PEMBAHASAN

2.1 Peserta dalam Pengembangan Sistem

a) Profesional sistem adalah analis sistem, insinyur sistem, dan programer.
Mereka mengumpulkan fakta mengenai permasalahan sistem, kemudian
menganilisis fakta fakta tersebut, dan merumuskan solusi untuk
memecahkan masalah. Biasanya terdapat atau menghasilkan sistem baru;
b) Pengguna akhir yang untuk siapa sistem ini dibangun
Terdapat banyak pengguna pada semua tingkatan organisasi. Hal ini
termasuk manajer, personil operasi, akunta, dan auditor internal. Dalam
beberapa organisasi, sulit untuk menemukan seseorang yang bukan
pengguna. Selama pengembangan sistem, profesional sistem bekerja
dengan pengguna utama untukmemperoleh pemahaman tentang masalah
pengguna dan pernyataan yang jelas dari kebutuhan mereka;
c) Pemangku kepentingan
Merupakan individu baik dari dalam maupun dari luar organisasi yang
memiliki kepentingan dalam sistem tetapi bukan pengguna akhir;
d) Akuntan/ auditor
Orang profesional yang menangani masalah kontrol, akuntansi, dan audit
untuk pengembangan sistem.
2.1.1. Mengapa Akuntan dan Auditor Terlibat dengan SDLC
Proses SDLC merupakan kepentingan untuk akuntan dan auditor yang terdapat
dua alasan:
a) Penciptaan suatu informasi memerlukan transaksi keuangan yang
signifikan.
Seorang akuntan dan auditor yang ahli dalam bidang transaksi keuangan
dapat memberikan masukan penting mengenai sebuah kontrol sistem,
integritas, dan segala aspek penting lainnya dari transaksi keuangan;
b) Lebih mendesak untuk akuntan dan auditor dengan mendatangkan produk
yang muncul dari SDLC.
Kualitas informasi akuntansi mengacu langsung pada kegiatan SDLC yang
menghasilkan sistem informasi akuntansi. Sistem ini memberikan informasi
akuntansi untuk pengguna eksternal dan juga internal. Tanggung jawab
akuntan disini adalah untuk memastikan bahwa sistem menggunakan
 konvensi dan aturan akuntansi yang tepat. Sebagai contoh, sistem order
penjulan diproduksi oleh sebuah SDLC yang rusak, maka mengakibatkan
keslaahan dalam akuntansi keuanga, pencatatan, atau memberikan
kesempatan untuk melakukan kecurangan.
2.1.2. Bagaimana Akuntan Terlibat dengan SDLC
a) Akuntan pengguna. Semua sistem yang memproses transaksi
keuangan berdampak pada fungsi dalam beberapa cara;
b) Akuntan berpartisipasi dalam pengembangan sistem sebagai anggota
tim pengembangan. Akuntan dapat berkonsultasi untuk memberikan
saran atau untuk menentukan apakah sistem yang diusulkan
merupakan risiko pengendalian internal;
c) Akuntan yang terlibat dalam pengembangan sistem sebagai auditor.
Pembentukan sistem akuntansi harus diaudit. Beberapa teknik audit
komputer memerukan fitur husus yang perlu dirancang ke dalam sistem
SDLC. Auditor memiliki kepentingan dalam semua sistem dan harus
terlibat di awal desain mereka, terutama yang berkaitan dengan
kemampuan audit, keamanan, dan kontrol.
2.2 Akuisisi Sistem Informasi
2.2.1. Pengembangan In-House
Banyak organisasi memerlukan sistem yang sangat sesuai untuk
operasi mereka yang unik. Perusahaan perusahaan ini merancang sistem
informasi mereka sendiri melalui kegiatan pengembangan sistem In house.
Pengembangan in house membutuhkan staf dengan waktu penuh dari analis
dan programer yang mengidentifikasi kebutuhan informasi penguna dan
memenuhi kebutuhan mereka dengan sistem kustom.
2.2.2. Sistem Komersial
Terdapat empat faktor yang mendorong pertumbuhan software komersial:
1. Biaya yang relatif rendah untuk software komersial umum dibadingkan
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 lingungan pemrosesan data terdistribusi, yang telah
 membuat opsi software komersial lebih menarik bagi organisasi yang
leboh besar.
Jenis sistem komersial
a) Turnkey system. Sistem turnkey biasanya dijual hanya sebagai modul,
dan pengguna memliki kemampuan untuk menyesuaikan mereka
dengan kebutuhan husus. Sistem ini sepenuhnya sudah teruji dan siap
diimpelemntasikan, dan sistem ini juga terdapat beberapa pilihan
software yang memungkinkan pengguna untuk menyesuaikan input,
output, dan beberaoa pengolahan melalui pilihan menu;
b) General accounting system. Sistem akuntansi umum yang dirancang
untuk melayani berbagai kebutuhan pengguna. Dengan memproduksi
secara massal sistem standar, vedor dapat mengurangi biaya
pengembangan in house;
c) Special purpose system. Beberapa vendor perangkat lunak
menciptakan sistem tujuan khusus yangmenargetkan segmen ekonomi
yang dipilih. Misalnya, bidang industri perbankan dan lembaga
pemerintah uang memiliki prosedur akuntansi dan perutar khusus dan
tentunya berbeda;
d) Office automation system. Sistem otomatisasi kantor adalah sistem
komputer yang meningkatkan produktivitas pekerja kantor. Contoh
sistem otomatisasi kantor termasuk pemrosesan, sistem manajemen
database, program spreadsheet, dan sistem desktop publishing;
e) Backbond system. Sistem ini dilengkapi dengan semua pengolahan
primer modul pemograman. Vendor desain dan program antar muka
pengguna sesuai dengan kebutuhan klien. Beberapa sistem seperti
ERP menawarkan susunan yang luas dari modul dengan hampir setiap
bisnis;
f) Vendor supported system. Sistem vendor yang didukung adaah
campuran sistem kustom dan software komersial. Dalam pendekatan
ini, vendor mengembangan (dan mempertahankan) sistem kustom
untuk klien.
Keuntungan dan kekurangan sistem komersial
a) Keuntungan sistem komersial
1. Waktu implementasi. Software komersial dapat dilaksanakan
segera setelah kebutuhan diakui.
 2. Biaya. 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.
b) Kekurangan sistem komersial
1. Kebebasan. Membeli sistem vendor didukung membuat
perusahaan tergantung padavendor untuk pemeliharaan.
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. Kebutuhan pengguna
yangunik dan tersedia software adalah terlalu umum atau terlalu
tidak fleksibel.
3. Pemeliharaan. Sistem informasi bisnis sering mengalami
perubahan. Jika kebutuhan pengguna berubah, mungkin sulit
atau bahkan tidak mungkin untuk memodifikasi software
komersial. pengembangan in-house, bagaimanapun,
menyediakan pengguna dengan aplikasi khusus yang dapat
dipertahankan secara ekonomi.
2.3 Siklus Hidup Pengembangan Sistem
System Development Life Cycle adalah proses pembuatan dan pengubahan
sistem serta model dan metodologi yang digunakan untuk mengembangkan sistem-
sistem tersebut. Pengembangan sistem baru melibatkan langkah-langkah konseptual
yang dapat diterapkan untuk setiap proses pemecahan masalah. Pemeliharaan sistem,
merupakan prosedur perubahan program organisasi.

2.3.1. Perencanaan Sistem-Fase I

a) Siapa yang Harus melakukan Perencanaan Sistem?

Steering Committee yang terdiri dari direktur utama, kepala pejabat

keuangan, Chief Information Officer, manajemen senior dari area
pengguna, auditor internal dan manajemen senior dari layanan komputer

Tanggung jawab khas untuk steering committee meliputi berikut ini:

 1) Menyelesaikan konflik yang timbul dari sistem baru
2) Meninjau proyek dan menetapkan prioritas
3) dana Anggaran untuk pengembangan sistem
4) Mengkaji status proyek individu dalam pengembangan
5) Menentukan di berbagai pos pemeriksaan di seluruh SDLC apakah
akan melanjutkan dengan proyek atau mengakhiri itu
b) Perencanaan Strategis Sistem
Perencanaan sistem strategis melibatkan alokasi sumber daya sistem di
tingkat makro. Proses ini mirip dengan sumber anggaran untuk kegiatan
strategis lainnya, seperti pengembangan produk, perluasan tanaman, riset
pasar, dan teknologi manufaktur.
Mengapa Melakukan Perencanaan Strategis Sistem? Ada empat
pembenaran untuk perencanaan sistem strategis:
1) Sebuah rencana yang berubah secara konstan lebih baik daripada tidak
ada rencana sama sekali.
2) Perencanaan strategis mengurangi komponen krisis dalam
pengembangan sistem.
3) Perencanaan sistem Strategis menyediakan kontrol otorisasi untuk
SDLC.
4) Biaya manajemen.
c) Perencanaan proyek
Tujuan dari perencanaan proyek adalah untuk mengalokasikan sumber
daya untuk aplikasi individual dalam kerangka rencana strategis. Usulan
proyek menyediakan manajemen dengan dasar untuk memutuskan apakah
akan melanjutkan proyek tersebut.
d) Peran Auditor dalam Perencanaan Sistem
Auditor secara rutin memeriksa tahap perencanaan sistem SDLC.
Perencanaan sangat mengurangi risiko bahwa suatu organisasi telah
menghasilkan tidak dibutuhkan, tidak efisien, tidak efektif, dan penipuan
sistem. Oleh karena itu, auditor internal dan eksternal tertarik dalam
memastikan bahwa perencanaan sistem yang memadai berlangsung.

2.3.2. Analisis Sistem-Fase II

Analisis sistem sebenarnya adalah proses dua langkah yang melibatkan

pertama survei sistem saat ini dan kemudian analisis kebutuhan pengguna.
hasil dari fase ini adalah laporan analisis sistem formal, yang menyajikan
temuan analisis dan rekomendasi untuk sistem baru.

a) Langkah Survey
Mengidentifikasi aspek apa dari sistem lama harus disimpan.
Menghilangkan akar gejala masalah.
b) Pengumpulan fakta
 1. Sumber data
2. Pengguna
3. Proses
4. Aliran data
5. Kontrol
6. Volume transaksi
7. Tingkat Kesalahan
8. Biaya Sumber Daya
9. Hambatan dan operasi berlebihan
c) Teknik Untuk Mencari fakta
1. Observasi
2. Partisipasi Tugas
3. Wawancara Pribadi
a. Buka-berakhir pertanyaan
b. Quessionaires
4. Meninjau Dokumen Kunci

Dokumen organisasi adalah sumber lain dari fakta tentang sistem yang
disurvei. Contoh ini meliputi berikut ini:
1. grafik Organisasi
2. Deskripsi pekerjaan
3. catatan Akuntansi
d) Analisis Langkah
Analisis sistem adalah proses intelektual yang bercampur dengan
pengumpulan fakta. Analis secara bersamaan menganalisis karena ia
mengumpulkan fakta-fakta. Pengakuan belaka masalah mengandaikan
beberapa pemahaman tentang norma atau keadaan yang diinginkan. Oleh
karena itu sulit untuk mengidentifikasi di mana survei berakhir dan analisis
dimulai.
e) Analisis sistem Laporan
Tahap ini berakhir dengan penyusunan sistem analisis laporan resmi.
Laporan ini dibuat untuk manajemen atau steering komite tentang masalah
yang diidentifikasi dengan sistem saat ini, kebutuhan pengguna, dan
persyaratan sistem baru. Tujuan utama untuk melakukan analisis sistem
adalah untuk mengidentifikasi kebutuhan pengguna dan menentukan
persyaratan untuk sistem baru. Pernyataan persyaratan dalam laporan
menetapkan pemahaman antara sistem profesional, manajemen,
pengguna, dan pemangku kepentingan lainnya. Dokumen ini merupakan
kontrak resmi yang menentukan tujuan dan sasaran dari sistem. Sistem
analisis laporan harus membentuk segi jelas sumber data, pengguna, file
data, proses umum, arus data, kontrol, dan kapasitas volume transaksi.
f) Peran Auditor dalam Analisis Sistem
Auditor perusahaan (baik eksternal dan internal) merupakan pemangku
kepentingan dalam sistem yang diusulkan. Seringkali, fitur pemeriksaan
lanjutan tidak dapat dengan mudah ditambahkan ke sistem yang ada. Oleh
karena itu, akuntan / auditor harus terlibat dalam analisis kebutuhan sistem
yang diusulkan untuk menentukan apakah itu adalah calon yang baik untuk
 fitur audit yang canggih dan, jika demikian, yang fitur yang paling cocok
untuk sistem.

2.3.3. Desain Sistem Konseptual-Fase III

Tujuan dari tahap ini adalah untuk menghasilkan beberapa alternatif konsep
sistem yang memenuhi berbagai kebutuhan yang teridentifikasi dalam analis
sistem. Pendekatan untuk desain konseptual sistem:

a) Pendekatan desain terstruktur (Structured Design)

Teknik terstruktur merupakan pendekatan formal untuk memecahkan

masalah-masalah dalam aktivitas bisnis menjadi bagian-bagian kiecil
yang dapat diatur dan berhubungan untuk kemudian dapat disatukan
kembali menjadi satu kesatuan yang dapat dipergunakan untuk
memecahkan masalah.

b) Pendekatan berorientasi Objek (Object-oriented design-OOD)

Pendekatan berorientasi objek merupakan paradigma pemrograman

yang berorientasikan kepada objek. Semua data dan fungsi di dalam
paradigma ini dibungkus dalam kelas-kelas atau objek-objek.
Bandingkan dengan logika pemrograman terstruktur. Setiap objek dapat
menerima pesan, memproses data, dan mengirim pesan ke objek
lainnya.

Peran Auditor dalam Desain Konseptual Sistem

Auditor memiliki kepentingan dalam semua sistem keuangan oleh karena itu
auditor memiliki kepentingan dalam tahap desain konseptual sistem.

2.3.4. Evaluasi dan Seleksi Sistem-Fase IV

Merupakan proses optimalisasi yang bertujuan untuk mengidentifikasi

sistem yang terbaik dimana dapat dilakukan melalui dua tahapan:

a) Melakukan studi kelayakan yang terperinci

Penguji harus melakukan studi kelayakan terperinci(detailed feasibility

study). Objectivitas merupakan hal yang esensial bagi penilaian yang
adil bagi setiap desain. Kelompok ini harus terdiri dari menager proyek,
 seorang perwakilan pengguna sistem, dan profesional sistem yang
bukan merupakan bagian dari proyek tetapi memiliki keahlian dalam
bidang-bidang tertentu yang dicakup oleh study kelayakan.

b) Kelayakan Teknis

Dalam mengevaluasi kelayakan tekhnis, tekhnologi yang sudah mapan

dan dipahami, memiliki resiko yang lebih kecil dibandingkan dengan
teknologi yang belum dikenal sama sekali.

1. Kelayakan Hukum. Desain sistem yang berbeda akan mewakili

tingkat resiko yang berbeda dalam menghadapi data seperti itu.
Penilai harus peduli bahwa desain konseptual tersebut
mempertimbangan pengendalian utama, keamanan, dan masalah-
masalah jejak audit serta bahwa melanggar hukum yang berkaitan
dengan hak pribadi dan/atau pengguna dan distribusi informasi.

2. Kelayakan Operasional. Kelayakan operasional juga akan

mempengaruhi kelayakan ekonomi dari sistem tersebut akan
mngalami proses transisi yang lebih lancar ke sistem teknologi yang
lebih maju. Nilai kelayakan operasional untuk setiap desain
alternatif harus mencerminkan kemudahan proses transisi yang
diharapkan ini.

3. Kelayakan Jadwal. Pada titik ini dalam proses desain, penilai sistem
berada dalam posisi yang lebih baik untuk mengukur kemungkinan
bahwa sistem akan disesaikan sesuai dengan jadwal. Pengguna
CASE, JADE dan prototipe dapat mengurangi secara signifikan
waktu pengembangan yang dibutuhkan oleh setiap pilihan desain
sistem.

4. Kelayakan Ekonomi. Studi pendahuluan kelayakan ekonomi

dibatasi untuk menilai komitmen keuangan manajemen terhadap
keseluruhan proyek. Ini masih merupakan masalah yang relevan.
Jika iklim ekonomi berubah sejak study pendahuluan, atau jika satu
atau lebih desain yang bersaing tidak mendapat dukungan
menejemen, saat inilah hal tersebut ditentukan.
 c) Melakukan analisis biaya-manfaat.
Analisis ini dapat membantu pihak manajemen menentukan apakah
manfaat yang diterima dari sistem yang diusulkan akan melebihi
biayanya.
Tahap-tahap dalam analisis biaya-manfaat:
1. Mengidentifikasi biaya, yakni dengan membagi kedalam dua
kategori diantaranya biaya yang hanya timbul sekali dan biaya yang
berulang. Biaya yang hanya timbul sekali meliputi: Pengadaan
peranti keras, Persiapan lokasi, Pengadaan peranti lunak, Desain
sistem, Pemrograman dan pengujian, Konversi data, Pelatihan.
Biaya yang berulang dapat meliputi: Pemeliharaan peranti keras,
Pemeliharaan peranti lunak, Asuransi, Pasokan, Biaya personal
2. Mengidentifikasi manfaat, Dimana ada dua manfaat yang timbul:
a. Manfaat berwujud yang terdiri dari kenaikan pendapatan dalam
pasar yang ada, ekspansi ke pasar lain, pengurangan biaya,
pengurangan tenaga kerja, Pengurangan biaya operasi (seperti
pasokan dan overhead), Pengurangan persediaan,
Perlengkapan yang tidak terlalu mahal, dan Pengurangan
pemeliharaan perlengkapan.
b. Manfaat tidak berwujud yan terdiri dari Peningkatan kepuasan
pelanggan, Peningkatan kepuasan karyawan, Lebih banyak
informasi, Perbaikan dalam pengambilan keputusan, Respon
yang lebih cepat atas tindakan pesaing, Operasi yang lebih
efisien, Komunikasi internal dan eksternal yang lebih baik,
Perbaikan perencanaan, Fleksibilitas operasional, Perbaikan
lingkungan pengendalian, dan Membandingkan biaya dengan
manfaat
Dua metode yang digunakan dalam mengevaluasi sistem informasi:

1. Metode NPV dideduksi dari nilai manfaat sekarang selama masa

siklus hidup sistem terkait.
2. Payback method yang merupakan variasi analisis titik impas
dimana BEP terjadi pada saat Total Biaya sama dengan Manfaat
Total.
 Peran Auditor dalam evaluasi dan pemilihan

Auditor harus memastikan:

a. Hanya biaya yang dapat dihindari yang digunakan dalam

perhitungan manfaat dari penghematan biaya.
b. Penggunaan tingkat bunga yang wajar dalam mengukur nilai
sekarang arus kas
c. Biaya yang timbul sekali dan berulang dilaporkan secara lengkap
dan akurat
d. Adanya penggunaan umur hidup yang realistis dalam
membandingkan bebagai alternatif proyek
e. Manfaat tidak berwujud diberikan nilai finansial yang wajar

2.3.5. Desain yang Rinci-Fase V

Tujuan dalam tahapan ini adalah untuk menghasilkan penjelasan terperinci

sistem yang diusulkan dapat memenuhi kebutuhan sistem yang telah
diindentifikasi selama analisis sistem dan sesuai dengan desain konseptualnya.

Dalam tahap ini semua komponen sistem (tampilan pengguna, tabel basis
data, proses dan pengendalian) secara lengkap dispesifikasi. Pada akhir tahap
ini semua komponen diatas akan disajikan secara formal dalam laporan desain
terperinci.

a) Melakukan percobaan desain sistem

Setelah menyelesaikan tahap desain terperinci, tim pengembangan
biasanya melakukan percobaan (walkthrough) desain sitem untuk
memastikan bahwa desain tersebut bebas dari kesalahan konseptual
yang dapat diprogram masuk kedalam sistem. Banyak perusahaan
memiliki percobaan formal dan terstruktur yang dilakaukan oleh
kelompok penjaminan mutu (quality assurance group). Kelompok
independen ini terdiri tas programer, analis, pengguna dan auditor
internal. Pekerjaan kelompok ini adalah menyimulasikan operasi sitem
terkait untuk mengungkapkan kesalahan, penghilangan dan ambiguitas
 dalam deasain. Kebanyakan kesalahan bersumber dari desain yang
kurang baik, bukan dari kesalahan pemrograman.
b) Mengkaji dokumentasi sistem
Laporan desain terperinci (detailed design report) sejauh ini
mendokumentasikan dan menjelaskan sistem. Laporan ini meliputi
berbagai hal berikut ini;
1. Desain semua input dan dokumen sumber untuk sistem
2. Desain semua output dan dokumen sumber untuk sistem
3. Data yang dinomralisasi untuk tabel basis data
4. Struktur dan diagram basis data
a. Diagram relasi entitas
b. Diagram konteks
c. Diagram aliran data tingkat rendah
d. Diagram struktur modul program dalam sistem
5. Kamus data terbaru yang menjelaskan setiap elemen data
dalam basis data
6. Logika pemrosesan (bagan alir)
Kelompok penjamin mutu dimana auditor adalah salah satu anggotanya
akan memeriksa berbagai dokumen ini, dan kesalahn apapun yang
terdeteksi akan dicatat dalam laporan percobaan. Pada titik ini,
keputusan akan dibuat apakah sistem terkait dikembalikan untuk diberi
tambahan desain atau diteruskan ke tahap berikutnya yaitu
pemrograman dan pengujian sistem.

2.3.6. Pemrograman Aplikasi dan Pengujian-Fase VI

a) Pemilihan Bahasa pemrograman.

Tahap yang selanjutnya dari proses SDLC adalah proses pemilihan
berbagai Bahasa pemrograman yang cocok untuk untuk aplikasi yang
akan dikembangkan oleh perusahaan. Berikut ini Bahasa pemrograman
yang diperlukan dalam pemrograman alikasi.
1. Bahasa prosedural
2. Bahasa pemrograman berbasis kegiatan
3. Bahasa pemrograman berorientasi objek
4. Pemrograman sistem
a. Efisiensi pemrograman
 b. Efisiensi pemeliharaan
c. Pengendalian

b) Menguji software aplikasi

Pengujian aplikasi harus dilakukan secara menyeluruh sebelum
dimlementasikan untuk keentingan evaluasi engembang sistem dan
untuk kepentingan proses audit. Berikut beberapa pengujian yang harus
dilakukan sebelum proses implementasi
1. Pengujian metodologi
2. Pengujuan Offline sebelum disebarkan secara offline
3. Uji data

2.3.7. Implementasi Sistem-Fase VII

Pada tahap ini, struktur database yang dibuat diisi dengan data, peralatan yang
dibeli diinstal, karyawan dilatih, sistem didokumentasikan, dan sistem baru
dipasang. Proses pelaksanaan melibatkan upaya desainer, programmer,
database administrator, pengguna, dan akuntan. Berikut adalah proses
pengimplementasian sistem:

a) Menguji seluruh sistem

Prosedur ini melibatkan pengolahan data hipotesis melalui sistem.
Output dari sistem tersebut kemudian dibandingkan dengan hasil yang
telah ditentukan, dan hasil dari pengujian tersebut didokumentasikan
untuk memberikan bukti kinerja sistem.
b) Mendokumentasikan sistem
Dokumentasi ini sangat penting untuk kepentingan audit di masa depan
dalam menyediakan jejak audit untuk proses audit. Berikut ini hal-hal
penting yang harus didokumentasikan dalam pengembangan sistem:
1. Data tentang designer dan programmer sistem
2. Dokumentasi Operator
a. Nama dari sistem, seperti pembelian sistem
b. Jadwal run (harian, mingguan, waktu hari, dan sebagainya)
 c. Perangkat keras diperlukan dalam pengembangan dan
penggunaan sistem (Harddisk, flashdisk,kabel konektor, dan
lain-lain )
d. File yang menjadi persyaratan dalam menentukan semua
pemrosesan dan pencatatan transaksi, mulai dari file input, file
induk, dan file output yang digunakan dalam sistem , dan nama
serta nomor telepon dari programmer dan teknisi yang dapat
dihubungi jika ada kegagalan sistem.
e. Daftar pengguna yang menerima output dari pengolahan data
oleh sistem
3. Dokumentasi pengguna
a. Pengguna utama
b. Pengembang
c. Pengguna sesekali
d. Pengguna rutin
e. Penngguna yang sering menggunakan layanan sistem
4. Buku pegangan pengguna
5. Tutorial
6. Fitur bantuan
c) Mengkonversi Data
Pada proses ini, data dikonversi dari format lama ke format baru yang
diperlukan oleh sistem baru. Dallam konversi data, banyak resiko yang
menyertainya, seperti kehilangan data dan kerusakan data. Untuk
langkah penjegahan diperlukan prose validasi, rekonsisliasi, dan
backup.
d) Konversi ke sistem baru.
Proses ini sering disebut denganproses cutover. Terdapat tiga
pendekatan yang digunakan, yaitu:
1. Cold Turkey Cutover
2. Cutover bertahap
3. Paralel cutover
e) Peran auditor dalam pelaksanaan sistem
Di Amerika Serikat, melalui undang-undang SOX, auditor external
dilarang terlibat langsung dalam pelaksanaan sistem. Namun peran
 auditor internal sangat dibutuhkan dalam proses ini. Keterlibatannya,
meliputi:
1. Memberikan keahlian tekhnis.
2. Menetukan standar dokumentasi yang cukup untuk kepentingan
auditing.
3. Verifikasi pengendalian kecukupan dan kepatuhan terhadap hukum.

f) Review Pasca Impelementasi

1. Kecukupan Desain Sistem.
Proses ini mereview apakah sistem telah sesuai dengan yang
dibutuhkan pengguna. Tingkat kecukupan dari hal tersebut, dapat
diukur dengan menjawab pertanyaan berikut:
a. Apakah output dari sistem memiliki karakteristik informasi
seperti, relevansi, ketepatan waktu, kelengkapan, akurasi, dan
sebagainya? Dapatkah memenuhi output seperti grafik,
elektronik, hard copy, dan sebagainya?
b. Apakah apakah ada data yang hilang, rusak, atau digandakan
selama proses konversi?
c. Apakah bentuk input dan tampilan layar yang telah dirancang
sesuai dengan kebutuhan pengguna.
d. Apakah pengguna menggunakan sistem dengan benar?
e. Apakah pemrosesan ditampilkan dengan benar?
f. Dapatkah semua modul program diakses dan dieksekusi
dengan baik, atau apakah ada pengguna yang pernah
terjebak dalam satu lingkaran pemerosesan yang tak bisa
diselesaikan?
g. Apakah sistem menyediakan pengguna bantuan dan tutorial
yang memadai?
2. Akurasi waktu, perkiraan biaya, dan manfaat.

2.3.8. Perbaikan Sistem-Fase VIII

Pemeliharaan sistem terdiri dari program perbaikan, perubahan dan pergantian.

perbaikan adalah aktivitas memperbaiki berbagai kerusakan pada sistem
ataupun bagian sistem yang tidak berjalan sebagaimana mestinya. Perubahan
merupakan aktivitas untuk merubah berbagai komponen sistem yang dirasa
 sudah tidak dapat mengakomodasi kebutuhan pengguna. Sedangkan proses
pergantian yaitu mengganti berbagai komponen sistem yang sudah tidak dapat
menjalankan fungsinya lagi, namun tidak mungkin untuk dilakukan perbaikan.

2.4 Mengontrol dan Mengaudit SDLC

2.4.1 Mengontrol Pengembangan Sistem Baru
a) Kegiatan Otorisasi Sistem
Otorisasi pengembangan sistem informasi baru harus melalui langkah
formal dalam prosesnya, yaitu dengan mengharuskan setiap permintaan
sistem baru diajukan secara tertulis oleh pengguna ke para professional
di bidang sistem yang memiliki keahlian dan otoritas untuk mengevaluasi
dan menyetujui (atau menolak) permintaan tersebut.
b) Kegiatan Spesifikasi Pengguna
Pengguna harus secara aktif terlibat dalam proses pengembangan
system, yaitu dengan memberikan uraian tertulis yang terperinci tentang
kebutuhan logis yang harus dipenuhi oleh sistem.
c) Kegiatan Desain Teknis
Kegiatan desain teknis menerjemahkan spesifikasi pengguna ke dalam
serangkaian spesifikasi teknis terperinci dari sistem yang memenuhi
kebutuhan pengguna. Ruang lingkup kegiatan ini meliputi analisis sistem,
desain sistem umum, analisis kelayakan, dan desain sistem terperinci.
d) Partisipasi Internal Audit
Auditor internal dapat berfungsi sebagai penghubung antara pengguna
dan profesional sistem untuk memastikan transfer pengetahuan yang
efektif.
e) Tujuan Audit Terakait dengan Pengembangan Sistem Baru
1. Memastikan kegiatan SDLC diterapkan secara konsisten dan sesuai
dengan kebijakan manajemen.
2. Memastikan bahwa sistem yang diterapkan bebas dari kesalahan
materi dan penipuan.
 3. Mengkonfirmasi bahwa sistem dinilai perlu dan dibenarkan di
berbagai pos pemeriksaan di seluruh SDLC.
4. Memastikan dokumentasi sistem cukup akurat dan lengkap untuk
memfasilitasi kegiatan audit dan pemeliharaan.
f) Prosedur Audit Terkait dengan Pengembangan Sistem Baru
Auditor harus memilih sampel proyek yang diselesaikan (diselesaikan
pada periode saat ini dan periode sebelumnya) lalu meninjau
dokumentasi untuk bukti kepatuhan dengan kebijakan SDLC.

2.4.2 Pemeliharaan Sistem Pengendali

a) Otorisasi Pemeliharaan, Pengujian, dan Dokumentasi
Untuk meminimalkan potensi kesalahan sistem, semua tindakan
pemeliharaan harus diwajibkan yaitu dengan melakukan kontrol otorisasi
formal, spesifikasi teknis dari perubahan, pengujian ulang sistem, dan
memperbarui dokumentasi. Dengan kata lain, kegiatan perawatan
harus diberikan perlakuan yang sama seperti pengembangan baru.
b) Kontrol Pustaka Program Sumber
Pemeliharaan sistem ini berkaitan dengan teknik kontrol dan prosedur
untuk mencegah dan mendeteksi akses tidak sah ke program aplikasi.
Dalam sistem komputer yang lebih besar, kode sumber program aplikasi
disimpan pada disk magnetik yang disebut perpustakaan program
sumber (SPL).
c) Situasi Terburuk : Tidak Adanya Kontrol
1. Akses ke program sama sekali tidak dibatasi
Programmer dan lainnya dapat mengakses program apa pun yang
disimpan di perpustakaan, dan tidak ada ketentuan untuk
mendeteksi instruksi yang tidak sah.
2. Karena kelemahan kontrol ini program dapat berubah tanpa izin.
Oleh karena itu tanpa ketentuan untuk mendeteksi akses tidak sah
ke SPL, integritas program tidak dapat diverifikasi.
d) Lingkungan SPL yang Terkendali
1. Kontrol Kata Sandi
Menetapkan kata sandi menyediakan satu bentuk kontrol akses
atas SPL.
2. Perpustakaan tes yang terpisah
 Akses langsung ke SPL produksi terbatas pada pustakawan resmi
yang harus menyetujui semua permintaan untuk memodifikasi,
menghapus, dan menyalin program. Selain itu kata sandi untuk
mengakses program dapat diubah secara berkala dan hanya
diungkapkan berdasarkan kebutuhan.
3. Jejak audit dan laporan managemen
Fitur penting dari perangkat lunak manajemen SPL adalah
pembuatan laporan yang meningkatkan kontrol manajemen dan
fungsi audit. Yang paling berguna dari fitur ini adalah laporan
modifikasi program, yang menjelaskan secara rinci semua
perubahan program (penambahan dan penghapusan) untuk setiap
modul.
4. Nomor versi program
SPLMS memberikan nomor versi secara otomatis ke setiap
program yang disimpan di SPL. Fitur ini, ketika dikombinasikan
dengan laporan jejak audit, dapat memberikan bukti untuk
mengidentifikasi perubahan yang tidak sah pada modul program.
5. Mengendalikan akses ke perintah perawatan
Akses ke perintah perawatan harus dikontrol karena jika tidak, bisa
saja terdapat kemungkinan modifikasi program yang tidak
direkam, dan mungkin tidak sah. Oleh karena itu, akses ke
perintah perawatan harus dikontrol dengan kata sandi, dan otoritas
sedangkan untuk menggunakannya harus dikontrol oleh
manajemen atau kelompok keamanan.
e) Tujuan Audit Terkait dengan Pemeliharaan Sistem
Tujuan audit terkait dengan pemeliharaan sistem adalah guna
mendeteksi pemeliharaan program yang tidak sah (yang mungkin
mengakibatkan kesalahan pemrosesan yang signifikan dan penipuan)
dan untuk menentukan bahwa :
1. Prosedur perawatan melindungi aplikasi dari perubahan yang tidak
sah
2. Aplikasi bebas dari kesalahan material; dan
3. Perpustakaan program terlindungi dari akses yang tidak sah
f) Prosedur Audit terkait dengan Pemeliharaan Sistem
1. Mengidentifikasi perubahan yang tidak sah
 Untuk memastikan bahwa perubahan program disahkan, auditor
harus memeriksa jejak audit perubahan program untuk sampel
aplikasi yang telah menjalani pemeliharaan. Auditor dapat
mengkonfirmasi bahwa prosedur otorisasi diikuti dengan
melakukan tes kontrol berikut.
a. Merekonsiliasi pembuat versi program.
b. Mengkonfirmasikan otorisasi pemeliharaan

2. Mengidentifikasi Kesalahan Aplikasi.

Dalam mengidentifikasi kesalahan aplikasi seorang Auditor harus
dapat menentukan bahwa program bebas dari kesalahan material
dengan melakukan tiga jenis tes kontrol: merekonsiliasi kode
sumber, meninjau hasil tes, dan menguji ulang program.

.
 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. Tujuan perencanaansistemadalah untuk
menghubungkan proyek sistem individualatau aplikasi untuk tujuan strategis
perusahaan. Bahkan, dasar untuk rencana sistem adalah rencanabisnis 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.

REFERENSI

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

Serkikat : South-Western Cengage Learning