Anda di halaman 1dari 26

SYSTEMS DEVELOPMENT AND PROGRAM CHANGE ACTIVITIES

2.1 Peserta dalam Pengembangan Sistem/Participants In System Development


Para peserta dalam pengembangan sistem dapat diklasifikasikan ke dalam empat
kelompok besar: profesional sistem, pengguna akhir, pemangku kepentingan. dan
akuntan / auditor.
1 Sistem profesional adalah analis sistem, insinyur sistem. dan programmer. Orang-
orang 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. Di 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 tentang kebutuhan mereka.
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. Tentu saja, seperti dibahas dalam Bab 1, undang-
undang SOX melarang auditor eksternal dari keterlibatan langsung dalam kegiatan
pengembangan Sistem klien audit.
2.1.1 Mengapa Akuntan dan Auditor Terlibat dengan SDLC?/Why Are Accountantts And
Auditors Involved With SDLC?
1 Penciptaan sistem in!ormasi memerlukan transaksi keuangan yang signifikan
2 Perhatian kedua dan yang lebih mendesak untuk akuntan dan auditor adalah dengan
si!at produk yang muncul dari SDLC
2.1.2 Bagaimana Akuntan Terlibat dengan SDLC?/How Are Accountants Involved With
The SDLC?
1 Akuntan adalah pengguna
2 Akuntan berpartisipasi dalam pengembangan sistem sebagai anggota tim
pengembangan
3 Akuntan terlibat dalam pengembangan sistem sebagai auditor. Sistemin informasi
akuntansi harus dapat diaudit
2.2 Akuisisi Sistem Informasi/Information System Acquisition
Organisasi biasanya memperoleh sistem informasi dengan dua cara (1) mereka
mengembangkan sistem khusus in-house melalui kegiatan pengembangan sistem formal
dan (2) mereka membeli sistem komersial dari vendor perangkat lunak.
2.2.1 Pengembangan In-House/In-House Development
Banyak organisasi membutuhkan sistem yang sangat canggih untuk operasi unik mereka.
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.
2.2.2 Sistem Komersial/Commercial System
Semakin banyak sistem yang 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 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 yang menargetkan perangkat lunak mereka untuk
kebutuhan jenis bisnis tertentu;
3 Meningkatnya permintaan dari bisnis yang terlalu kecil untuk membeli staf
pengembangan sistem in-house dan
4 Tren ke arah perampingan unit organisasi dan langkah 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

1 Sistem turnkey sepenuhnya selesai dan sistem teruji yang siap untuk implementasi
2 Sistem akuntansi umum dirancang untuk melayani berbagai kebutuhan pengguna
3 sistem tujuan khusus yang menargetkan segmen ekonomi tertentu
4 Sistem otomatisasi kantor adalah sistem komputer yang meningkatkan produktivitas
pekerja kantor
5 Sistem tulang punggung menyediakan struktur sistem dasar untuk membangun
6 Sistem yang didukung oleh vendor adalah gabungan dari sistem khusus dan
perangkat lunak komersial

Keuntungan Perangkat Lunak Komersial

1 Waktu implementasi
2 Biaya
3 Keandalan

Kerugian Perangkat Lunak Komersial

1 Kemandirian
2 Kebutuhan sistem yang disesuaikan
3 Pemeliharaan
2.3 Siklus Hidup Pengembangan Sistem/The Systems Development Life Cycle
Pengembangan sistem baru melibatkan langkah-langkah konseptual yang dapat
diterapkan untuk setiap proses penyelesaian masalah:
o mengidentifikasi masalah,
o Memahami apa yang perlu dilakukan,
o Pertimbangkan solusi alternative
o Pilih solusi terbaik, dan, akhirnya
o Mengimplementasikan solusinya
2.3.1 Perencanaan Sistem – Fase I/Systems Planning – Phase I
A. Siapa yang Harus Dilakukan Perencanaan Sistem?
Tanggung jawab khas untuk komite pengarah 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. Biasanya berkaitan dengan kerangka waktu 3 sampai 5 tahun. Proses ini mirip
dengan sumber anggaran untuk kegiatan strategis lainnya, seperti pengembangan
produk, perluasan tanaman, riset pasar, dan teknologi manufaktur.
Secara teknis, perencanaan sistem strategis bukan bagian dari SDLC karena SDLC
berkaitan dengan aplikasi tertentu. Sistem strategis rencana berkaitan dengan alokasi
sumber daya seperti sistem sebagai karyawan (jumlah sistem profesional untuk
dipekerjakan), hardware (jumlah workstation, minicomputer, dan mainframe yang akan
dibeli), perangkat lunak (dana yang akan dialokasikan untuk proyek-proyek baru dan
sistem untuk sistem pemeliharaan), dan telekomunikasi (dana yang dialokasikan untuk
jaringan dan EDI). Adalah penting bahwa rencana strategis menghindari detail yang
berlebihan. Rencana harus memungkinkan spesialis sistem untuk membuat keputusan
dengan mempertimbangkan faktor-faktor yang relevan seperti harga, ukuran kinerja,
ukuran, keamanan, dan kontrol.
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
1 Tujuan dari perencanaan proyek adalah untuk mengalokasikan sumber daya untuk
aplikasi individual dalam kerangka rencana strategis.
2 Usulan proyek menyediakan manajemen dengan dasar untuk memutuskan apakah
akan melanjutkan proyek tersebut.
a) Merangkum temuan dari studi yang dilakukan ke titik ini menjadi rekomendasi
umum untuk sistem baru atau diubah.
b) Proposal menguraikan keterkaitan antara tujuan dari sistem yang diusulkan
dan tujuan bisnis perusahaan, terutama yang digariskan dalam rencana
strategis IT
c) Jadwal proyek merupakan komitmen manajemen untuk proyek.
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/Systems Analysis – Phase II
a) Langkah Survei
1 Kekurangan Survei Sistem sekarang
a. Current physical pit tar
b. Berpikir di dalam kotak.
2 Keuntungan dari Survei Sistem sekarang
a. Mengidentifikasi aspek apa dari sistem lama harus disimpan.
b. Memaksa Sistem analis untuk memahami sistem.
c. Mengisolasi akar gejala masalah
b) Mengumpulkan fakta (Gathering Facts)
Survey sistem saat ini pada dasarnya adalah kegiatan pengumpulan fakta. Fakta-
fakta yang dikumpulkan oleh analis adalah potongan – potongan data yang
menggambarkan fitur-fitur utama, situasi, dan hubungan sistem. Fakta sistem
termasuk dalam kelas luar berikut ini.
1. Sumber data, ini termasuk entitas eksternal, seperti pelanggan atau vendor, serta
sumber internal dari departemen lain
2. Pengguna, ini termasuk manajer dan pengguna operasi
3. Penyimpanan data, adalah file, database, akun, dan dokumen sumber yang
digunakan dalam sistem.
4. Proses, tugas pemrosesan adalah operasi manual atau komputer yang mewakili
keputusan atau tindakan yang dipicu oleh informasi.
5. Aliran data, aliran data diwakili oleh perpindahan dokumen dan laporan antara
sumber data, penyimpanan data, tugas pemrosesan, dan pengguna.aliran data juga
dapat direpresentasikan dalam kontrol diagram UML.
6. Pengendalian, termasuk pengendalian akuntansi dan operasional. Dapat juga
berupa prosedur manual atau pengendalian komputer.
7. Volume transaksi, seorang analis harus mendapatkan ukuran volume transaksi
untuk periode waktu tertentu. Banyak sistem diganti karena mereka telah mencapai
kapasitas mereka, Memahami karakteristik volume transaksi sistem dan laju
pertumbuhannya merupakan elemen penting dalam menilai kapasitas yang
memerlukan pengaturan untuk sistem baru.
8. Tingkat kesalahan, tingkat kesalahan erat kaitannya dengan volume transaksi.
Ketika sistem mencapai kapasitasnya, tingkat kesalahan meningkat ke tingkat yang
tidak dapat ditoleransi meskipun tidak ada sistem yang sempurna. Analis harus
menentukan batas toleransi kesalahan yang dapat diterima untuk biaya sumber
daya baru.
9. Biaya sumber daya, biaya sumber daya yang digunakan oleh sistem saat ini
termasuk biaya tenaga kerja, waktu komputer, bahan baku, dan overhead
langsung. Setiap biaya sumber daya yang hilang ketika sistem saat ini adalah iklim
yang disebut dengan escapable costs, nantinya ketika analis melakukan analisis
biaya manfaat, biaya escapable akan diperlakukan sebagai manfaat dari sistem
baru
10. Bottlenecks sistem baru dan operasi yang berlebihan,
seorang analis harus mencatat titik – titik dimana data terendah bersatu membentuk
bottlenecks. Inid apat mengakibatkan penundaan dan meningkatkan kesalahan
pemrosesan. Demikian juga, penundaan mungkin disebabkan oleh redundant.
c) Teknik Pengumpulan Fakta
Seorang analis sistem menggunakan beberapa teknik untuk mengumpulkan berbagia
fakta yang sebelumnya telah disebutkan. Teknik – teknik yang digunakan meliputi
observasi, melibatkan diri dalam pekerjaan, wawancara personal, serta mengkaji
berbagai dokumen penting.
1. Observasi, observasi melibatkan oengamatan secara pasif berbagia prosedur fisik
dalam sistem. Observasi memungkinkan analis menentukan hal apa saja yang
dilaksanakan, siapa yang melaksanakan, kapan dilakukan, bagaimana cara
melakukan, mengapa melakukan, dan seberapa lama waktu yang dibutuhkan.
2. Keterlibatan dalam pekerjaan, keterlibatan adalah perluasan dari observasi,
dimana analis mengambil peran aktif dalam melakukan pekerjaan pengguna. Hal
ini memungkinkan analis mendapatkan pengalaman langsung dengan berbagai
masalah yang dilibatkan dalam operasi sistem yang ada.
3. Wawancara personal, Wawancara merupakan metode untuk mengekstraksi fakta
mengenai sistem yang ada dan persepsi pengguna mengenai berbagai kebutuhan
akan sistem yang baru.instrumen yang digunkana untuk mengumpulkan berbagai
fakta tersebut dapat berupa pertanyaan dengan jawaban terbuka atau kuisionel
 Pertanyaan dengan jawaban terbuka memungkinkan para pengguna untuk
meneliti masalah ketika munculdan memberikan saran serta rekomendasi.
 Kuesioner digunakan untuk menanyakan beberapa pertanyaan yang lebih
spesifik dan terperinci serta untuk membatasi berbagai respons dari para
pengguna.
4. Mengkaji Dokumen Sumber, dokumen-dokumen perusahaan adalah sumber lain
fakta mengenai sistem yang sedang disurvey. Beberapa contoh dari dokumen ini
meliputi :
 Struktur organisasi
 Deskripsi pekerjaan
 Catatan akuntansi
 Daftar akun
 Pernyataan kebijakan
 Deskripsi prosedur
 Laporan keuangan
 Laporan kinerja
 Bagan alir sistem
 Dokumen sumber
 Daftar transaksi
 Anggaran
 Prediksi
 Pernyataan misi
d) Tahap Analisis
Analsiis sistem adalah proses intelektual yang berbaur dengan pengumpulan fakta.
Analis secara simultan akan menganalisis ketika dia melakukan pengumpulan fakta.
Pengetahuan akan suatu masalah saja menunjukkan adanya pemahaman mengenai
norma atau kondisi yang diinginkan. Oleh karena itu sulit untuk mendefinisikan saat
dimana survey beakhir dan analisis dimulai
e) Laporan Analisis sistem
Peristiwa yang menandai selesainya tahapan analisis sistem adalah pembuatan
laporan analisis sistem formal. Laporan ini menyajikan pihak manajemen atau komite
pengarah berbagai temuan survei, masalah yang diidentifikasi dalam sistem yang ada,
kebutuhan pengguna, dan kebutuhan sistem yang baru.
Laporan analisis sistem tidak menspesifikasikan desain terperinci dari sistem yang
diusulkan. Laporan ini tidak menyajikan metode pemrosesan, media penyimpanan,
struktur record, dan berbagai perincian lainnya yang dibutuhkan untuk mendesain
sistem fisiknya. Sebagai gantinya, laporan tersebut tetap berada pada tingkatan tujuan
untuk menghindari adanya pembatasan buatan dalam tahap desain konseptual.
f) Peran Auditor dalam Analisis Sistem
Auditor perusahaan adalah pemegang kepentingan dalam sistem yang diusulkan.
Sering kali berbagai fitur audit lanjutan tidak dapat dengan mudah ditambahkan ke
sistem yang ada. Oleh karena itu, akuntan/auditor harus dilibatkan dalam analisis
kebutuhan sistem yang diusulkanuntuk menentukan apakah sistem tersebut
merupakan kandidat yang baik untuk fitur audit lanjutan dan jika memang demikian,
fitur mana saja yang paling sesuai untuk sistem tersebut.
2.3.3 Desain Sistem Konspetual – Tahap III/Conseptual System Design – Phase III
Tujuan dari tahap desain konseptual sistem adalah untuk menghasilkan bebrapa alternatif
konsep sistem yang memenuhi berbagai kebutuhan yang teridentifikasi dalam analsisi
sistem. Bagian ini menjelaskan dua pendekatan untuk desain konseptual sistem yaitu
pendekatan terstruktur dan dan pendekatan berorientasi objek.
1. Pendekatan Desain Terstruktur
pendekatan ini merupakan cara yang disiplin untuk mendesian sistem dari atas ke
bawah. Pendekatan ini dimulai dengan gambaran umum sistem yang diusulkan yang
kemudian secara bertahap akan diuraikan menjadi semakin terperinci hingga sistem
terkait dipahami secara penuh. Dalam pendekatan ini, proses bisnis yang sedang di
desain biasanya di dokumentasikan melalui diagram aliran data dan diagram struktur.
Tahapan desain konseptual harus menunjukkan perbedaan antara fitur-fitur yang
sangat penting sistem yang saling bersaing satu sama lain, bukan menunjukkan
persamaan sistem-sistem tersebut.oleh karena itu, desain sistem pada titik ini
seharusnya bersifat umum. Desain tersebut seharusnya mengidentifikasi semua input,
output, proses, dan fitur khusus yang dibutuhkan untuk membedakan suatu alternatif
dari alternatif lainnya.
2. Pendekatan Berorientasi Objek ( Objec Oriented Design – OOD)
Pendekatan ini mengembangkan sistem informasi dari berbagai komponen atau objek
standar yang dapat digunakan kembali. Pendekatan ini dapat disetarakan dengan
proses membuat mobil.
Metode OOD sering kali juga dikaitkan dengan pendekatan alternatif dalam tahapan
desainnya, bukan berupa pendekatan yang seperti air terjun, atau proyek yang
selesai. Jadi pendekatan ini melihat keseluruhan proyek dan membagi proses
kedalam berbagai fungsi objek , seperti yang digambarkan secara garis besar.
Peran auditor dalam Desain Konseptual Sistem
Auditor adalah pemegang kepentingan dalam semua sistem keuangan dan
karenanya, memiliki kepentingan dalam tahap desain konseptual sistem. Dapat
tidaknya suatu sistem diaudit tergantung sebagian pada karakteristik desainnya.
2.3.4 Evaluasi dan Pemilihan Sistem/System Evaluation And Selection – Phase IV
Tahap evaluasi dan pemeliharaan sistem adalah proses optimalisasi yang bertujuan
mengidentifikasi sistem yang terbaik.keputusan ini mewakili tahap yang paling penting
dalam SLDC. Tujuan dari prosedur evaluasi dan pemeliharaan sistem adalah untuk
menstrukturisasi proses pengambian keputusan ini dan karenanya mengurangi
ketidakpastian dan risiko adanya keputusan yang kurang baik. Proses ini memiliki dua
tahap yaitu :
1. Melakukan studi kelayakan yang terperinci
 Kelayakan teknis
Berhubungan dengan apakah sistem dapat dikembangkan dengan teknologi yang
ada ataukah dibutuhkan teknologi yang baru.dari sudut pandang ketersediaan,
kelayakan teknis biasanya bukan menjadi masalah. Bagi kebanyakn perusahaan
masalah utama adalah keinginan dan kemampuan perusahaan untuk
mengaplikasikan teknologi yang tersedia. Karena teknologi adalah dasar fisik bagi
kebanyakan fitur desain sistem, aspek ini sangat diperhatikan dalam keseluruhan
kelayakan berbagai alternatif sistem yang ada.
 Kelayakan hukum
Kelayakan hukum mengidentifikasikan konflik antar konsep sistem dengan
kemampuan perusahaan untuk melaksanakan tanggung jawab hukumnya.
Pembuat keputusan harus memastikan bahwa sistem yang diusulkan tidak
melanggar batasan hukum yang ada
 Kelayakan operasional
Kelayakan operasional menunjukkan kesesuaian antara prosedur perusahaan
yang ada dengan berbagai keahlian serta kebutuhan opersional sistem yang baru.
Mengimplementasikan sistem yang baru dapat membutuhkan adopsi prosedur
baru dan pelatihan ulang personal operasional.
 Kelayakan jadwal
 Kelayakan jadwal berhubungan dengan kemampuan perusahaan untuk
mengimplementasikan proyek tersebut dalam waktu yang dapat ditoleransi. Faktor
kelayakan ini berdampak pada lingkup proyek dan apakah proyek sistem tersebut
akan dikembangkan secara internal atau dibeli dari vendor peranti lunak.
2. Melakukan analisis dan biaya manfaat
 Mengidentifikasi biaya
Salah satu metode untuk mengidentifikasi biaya adalah dengan membaginya
kedalam dua kategori yaitu biaya yang hanya timbul sekali dan biaya yang berulang.
Biaya yang timbul sekali meliputi biaya investasi awal untuk mengembangkan dan
mengimplementasikan sistem. Biaya berulang meliputi biaya operasional dan
pemeliharaan yang terus berulang selama masa hidup sistem terkait.
a) Biaya yang hanya timbul sekali meliputi :
 Biaya pengadaan peranti keras
 Persiapan lokasi
 Pengadaan peranti lunak
 Desain sistem
 Pemrograman dan pengujian
 Konversi data
 Pelatihan
b) Biaya yang berulang dapat meliputi :
 Pemeliharaan piranti keras
 Pemeliharaan peranti lunak
 Asuransi
 Pasokan
 Biaya personel
 Identifikasi Manfaat (Identify Benefits)
Langkah selanjutnya dalam analisis biaya-manfaat adalah mengidentifikasi manfaat
sistem. Ini bisa berwujud maupun tidak berwujud.
 Manfaat nyata (Tangible benefits) terbagi dalam dua kategori : yang meningkatkan
pendapatan dan yang mengurangi biaya. Misalnya, anggap 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 pengurangan biaya. Sistem yang diusulkan
akan menggunakan lebih sedikit sumber daya (inventaris) daripada sistem saat ini.
Nilai manfaat ini adalah Peningkatan penjualan yang diperkirakan karena layanan
pelanggan yang lebih baik adalah manfaat peningkatan pendapatan.
 Perbandingan Biaya dan Manfaat (Compare Costs and Benefits).
Langkah terakhir dalam analisis biaya-manfaat adalah untuk membandingkan biaya
dan manfaat yang diidentifikasi dalam dua langkah pertama. Dua metode yang paling
umum digunakan untuk mengevaluasi sistem informasi adalah net present value dan
payback. Di bawah metode net present value, nilai sekarang dari biaya dikurangkan
dari nilai sekarang dari manfaat selama umur sistem. Proyek dengan net present value
positif layak secara ekonomi. Ketika membandingkan proyek yang bersaing, pilihan
operasional adalah proyek dengan net present value terbesar.
 Menyiapkan Laporan Pemilihan Sistem (Prepare Systems Selection Report)
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 manfaat tidak berwujud untuk setiap desain
alternatif.
 Peran Auditor dalam Evaluasi dan Seleksi (The Auditor’s Role in Evaluation and
Selection)
Perhatian utama bagi auditor adalah bahwa kelayakan ekonomi dari sistem yang
diusulkan diukur seakurat mungkin. Secara khusus, auditor harus memastikan lima
hal:
1. Hanya biaya lolos yang digunakan dalam perhitungan manfaat penghematan
biaya.
2. Suku bunga yang wajar digunakan dalam mengukur nilai sekarang dari arus kas.
3. Biaya satu kali dan berulang dilaporkan secara lengkap dan akurat.
4. Umur manfaat realistis digunakan dalam membandingkan proyek yang bersaing.
5. Manfaat tidak berwujud diberikan nilai finansial yang wajar.

Kesalahan, kelalaian, dan penyajian yang keliru dalam akuntansi untuk item-item
tersebut dapat mendistorsi analisis dan dapat mengakibatkan keputusan yang cacat
secara material.

2.3.5 Fase Desain Terperinci (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. Laporan ini merupakan seperangkat cetak biru yang
menentukan format layar input, tata letak laporan output, struktur database, dan logika
proses. Rencana yang telah selesai ini kemudian dilanjutkan ke tahap akhir dalam
implementasi sistem SDLC-dengan sistem yang dibangun secara fisik.
 Lakukan Panduan Desain Sistem (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.
 Tinjau Dokumentasi Sistem (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).
2.3.6 Pemrograman dan Pengujian Aplikasi (Application Programming And Testing –
Phase VI)
Program Perangkat Lunak Aplikasi (Program the Application Software)
Tahap selanjutnya dari SDLC adalah memilih bahasa pemrograman dari antara berbagai
bahasa yang tersedia dan cocok untuk aplikasi tersebut. Ini termasuk bahasa prosedural
seperti COBOL, bahasa yang digerakkan oleh peristiwa seperti Visual Basic, atau
pemrograman berorientasi objek (OOP) bahasa seperti Java atau C ++. Bagian ini
menyajikan tinjauan singkat tentang berbagai pendekatan pemrograman. Sistem
profesional akan membuat keputusan berdasarkan standar in-house, arsitektur, dan
kebutuhan pengguna.
 Bahasa Prosedural (Procedural Languages)
Bahasa prosedural mengharuskan programmer untuk menentukan lebih sering disebut
bahasa generasi ketiga (3GLs). COBOL memiliki kemampuan hebat untuk berkinerja
tinggi operasi terperinci pada catatan data individual dan menangani file besar dengan
sangat efisien.
 Bahasa Berbasis Acara (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. Microsoft's Visual Basic adalah contoh paling populer dari bahasa
yang digerakkan oleh peristiwa. Sintaks bahasanya sederhana namun kuat. Visual
Basic digunakan untuk membuat aplikasi waktu nyata dan batch yang dapat
memanipulasi file datar atau database relasional.
 Bahasa Berorientasi Objek (Object-Oriented Languages)
Inti untuk mencapai manfaat dari pendekatan berorientasi objek adalah
mengembangkan perangkat lunak dalam bahasa pemrograman berorientasi objek
(OOP). Sebagian besar perusahaan tidak siap untuk membuang jutaan baris kode
COBOL tradisional dan melatih kembali staf pemrograman mereka untuk menerapkan
sistem berorientasi objek.
 Memprogram Sistem (Programming the System)
Terlepas dari bahasa pemrograman yang digunakan, program modern harus
mengikuti pendekatan modular. Teknik ini menghasilkan program kecil yang
melakukan tugas yang didefinisikan secara sempit. Tiga manfaat berikut ini terkait
dengan pemrograman modular.
1. Efisiensi pemrograman. Modul dapat dikodekan dan diuji secara independen,
yang sangat mengurangi waktu pemrograman.
2. Efisiensi pemeliharaan. Modul kecil lebih mudah untuk dianalisis dan diubah,
yang mengurangi waktu start-up selama pemeliharaan program
3. Kontrol. Dengan menjaga modul kecil, mereka cenderung mengandung
kesalahan material dari logika penipuan. Karena setiap modul terpisah dari
yang lain, kesalahan terdapat di dalam modul.
 Uji Perangkat Lunak Aplikasi (Test the Application Software)
Semua modul program harus diuji secara menyeluruh sebelum diterapkan. Ada
beberapa konsep yang terbukti tentang pengujian yang harus diikuti oleh pengembang
sistem, dan dipertimbangkan oleh auditor dalam melakukan audit.
 Metodologi Pengujian (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.

 Menguji Offline Sebelum Menggunakan Online (Testing Offline Before Deploying


Online)
Titik pertama yang sangat penting untuk dicoba adalah jangan pernah meremehkan
sistem tanpa menguji offline dalam undangan bencana. salah satu perusahaan e-
commerce online yang keluar dari bisnis karena menerapkan sistem online tanpa
mengujinya offline terlebih dahulu, dan secara tidak sengaja membiarkan server web
rentan terbuka terhadap serangan dari cracker.
 Data Uji (Test Data)
Membuat data uji yang bermakna adalah aspek pengujian program yang sangat
memakan waktu. Namun, kegiatan ini dapat memberikan manfaat di masa depan.
Misalnya, jika suatu program tidak mengalami perubahan pemeliharaan sejak
penerapan aslinya, hasil pengujian dari audit harus identik dengan hasil pengujian asli.
Memiliki dasar untuk perbandingan, auditor dapat dengan cepat memverifikasi
integritas kode program. Namun, jika ada perubahan, data pengujian asli dapat
memberikan bukti tentang perubahan ini. Auditor karenanya dapat memusatkan
perhatian pada bidang-bidang tersebut.
2.3.7 Sistem Implementasi (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. Proses implementasi melibatkan upaya
perancang, pemrogram, administrator basis data, pengguna, dan akuntan.
 Menguji Keseluruhan Sistem (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. Keluaran sistem kemudian direkonsiliasi dengan hasil yang telah ditentukan,
dan pengujian didokumentasikan untuk memberikan bukti kinerja sistem.
 Mendokumentasikan Sistem (Documenting the system)
Dokumentasi sistem memberi auditor informasi penting tentang cara kerja sistem.
Persyaratan dokumentasi dari tiga kelompok - perancang dan pemrogram sistem,
operator komputer, dan pengguna akhir - sangat penting.
 Dokumentasi Desainer dan Programmer. Perancang dan pemrogram sistem
membutuhkan dokumentasi untuk men-debug kesalahan dan melakukan
pemeliharaan pada sistem. Setiap program dalam bagan alur sistem diwakili oleh
bagan alur program yang terpisah, seperti yang ditunjukkan pada Gambar 5.9.

 Dokumentasi Pengguna (User Documentation).


Pengguna perlu dokumentasi yang menjelaskan cara menggunakan sistem. Tugas
pengguna mencakup hal-hal seperti memasukkan input untuk transaksi, mengajukan
pertanyaan tentang saldo akun, memperbarui akun, dan menghasilkan laporan
keluaran. Sifat dokumentasi pengguna akan tergantung pada tingkat kecanggihan
pengguna dengan komputer dan teknologi.
o Para pemula memiliki sedikit atau tanpa pengalaman dengan komputer dan
malu untuk bertanya. Pelatihan dan dokumentasi pengguna untuk pemula harus
luas dan terperinci.
o Pengguna sesekali pernah memahami sistem tetapi lupa beberapa perintah dan
prosedur penting.
o Pengguna cahaya yang sering terbiasa dengan aspek-aspek terbatas dari
sistem. Meskipun fungsional, mereka cenderung tidak mengeksplorasi di bawah
permukaan dan tidak memiliki kedalaman pengetahuan.
o Pengguna listrik yang sering memahami sistem yang ada dan siap beradaptasi
dengan sistem baru.
 Buku Pegangan Pengguna (User Handbook)
Dokumentasi pengguna seringkali berbentuk buku pedoman pengguna, serta
dokumentasi online. Buku pedoman pengguna biasa akan berisi item-item berikut:
o Tinjauan umum sistem dan fungsi utamanya
o Instruksi untuk memulai
o Deskripsi prosedur dengan referensi visual langkah demi langkah
o Contoh layar input dan instruksi untuk memasukkan data
o Daftar lengkap kode dan deskripsi pesan kesalahan
o Referensi manual perintah untuk menjalankan sistem
o Glosari istilah-istilah utama
o Informasi layanan dan dukungan

Dokumentasi online akan memandu pengguna secara interaktif dalam penggunaan


sistem. Beberapa fitur online yang umum ditemukan termasuk tutorial dan fitur bantuan.

 Tutorial (Tutorials)
Tutorial online dapat digunakan untuk melatih pemula atau pengguna sesekali.
Keberhasilan teknik ini didasarkan pada tingkat realisme tutorial. Tutorial tidak boleh
membatasi pengguna dari akses ke fungsi yang sah.
 Fitur Bantuan (Help Features)
Fitur bantuan online berkisar dari yang sederhana hingga yang canggih. Fitur bantuan
sederhana mungkin tidak lebih dari pesan kesalahan yang ditampilkan di layar.
 Converting the Database
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. Beberapa kegiatan konversi membutuhkan data untuk
dimasukkan ke dalam basis data baru secara manual. Dalam hal apa pun, konversi
data berisiko dan harus dikontrol dengan hati-hati. Tindakan pencegahan berikut harus
diambil:
1. Validasi. Basis data lama harus divalidasi sebelum konversi. Ini membutuhkan
analisis setiap kelas data untuk menentukan apakah harus direproduksi dalam
database baru.
2. Rekonsiliasi. Setelah tindakan konversi, database baru harus direkonsiliasi dengan
yang asli. Kadang-kadang ini harus dilakukan secara manual, merekam dengan
catatan dan bidang demi bidang. Dalam banyak kasus, proses ini dapat diotomatisasi
dengan menulis sebuah program yang akan membandingkan dua set data.
3. Cadangkan. Salinan file asli harus disimpan sebagai cadangan terhadap perbedaan
dalam data yang dikonversi. Jika file saat ini sudah dalam bentuk magnetik, mereka
dapat didukung dan disimpan dengan nyaman. Namun, dokumen kertas dapat
menyebabkan masalah penyimpanan. Ketika pengguna merasa yakin tentang
keakuratan dan kelengkapan basis data baru, ia dapat menghancurkan dokumen
kertas.
 Converting to the New System
Konversi ke Sistem Baru Proses konversi dari sistem lama ke yang baru disebut
cutover. Pergantian sistem biasanya akan mengikuti salah satu dari tiga pendekatan:
cold turkey, phased, atau operasi paralel.
Cold turkey cutover. Di bawah pendekatan pemotongan cold turkey (juga disebut
pendekatan "Big Bang"), perusahaan beralih ke sistem baru dan secara bersamaan
mengakhiri sistem lama. Ketika menerapkan sistem sederhana, ini sering kali
merupakan pendekatan yang paling mudah dan paling murah. Dengan sistem yang lebih
kompleks, ini adalah yang paling berisiko. Kesalahan sistem yang tidak terdeteksi
selama langkah-langkah penelusuran dan pengujian dapat terjadi secara tak terduga.
Tanpa sistem cadangan, suatu organisasi dapat menemukan dirinya tidak dapat
memproses transaksi dan memenuhi kewajibannya kepada pelanggan dan kreditor.
Phased Cutover. Terkadang seluruh sistem tidak dapat, atau tidak perlu, dipotong
sekaligus. Cutover bertahap mulai mengoperasikan sistem baru dalam modul. Kita dapat
menerapkan suatu sistem, dimulai dengan subsistem penjualan, diikuti oleh subsistem
kontrol inventaris, dan akhirnya subsistem pembelian. Pendekatan bertahap dapat
menciptakan ketidakcocokan antara subsistem baru dan subsistem lama yang belum
diganti. Masalah ini dapat diatasi dengan mengimplementasikan sistem konversi khusus
yang menyediakan antarmuka sementara selama periode peralihan.
Pharallel Operation Cutover. Cutover Operasi Paralel. Pemotongan operasi paralel
melibatkan menjalankan sistem lama dan sistem baru secara bersamaan untuk periode
waktu tertentu. Pendekatan ini, yang merupakan yang paling memakan waktu dan
mahal dari ketiganya. Menjalankan dua sistem secara paralel pada dasarnya
menggandakan konsumsi sumber daya. Selama periode cutover, kedua sistem
mengkonsumsi dua kali sumber daya dari satu sistem. Ini termasuk dua kali dokumen
sumber, dua kali waktu pemrosesan, dua kali basis data, dan dua kali keluaran produk.
Keuntungan dari pengurangan paralel adalah pengurangan risiko. Dengan menjalankan
dua sistem, pengguna dapat merekonsiliasi output untuk mengidentifikasi kesalahan dan
kesalahan debug sebelum menjalankan sistem solo baru.
 Peran Auditor dalam Implementasi Sistem
Auditor eksternal dilarang oleh undang-undang SOX dari keterlibatan langsung dalam
implementasi sistem. Namun, telah disarankan, peran auditor internal dalam fase desain
dan implementasi rinci harus signifikan. Menjadi pemangku kepentingan dalam semua
sistem keuangan, auditor internal harus meminjamkan keahlian mereka untuk proses ini
untuk memandu dan membentuk sistem yang sudah selesai. Secara khusus, auditor
internal dapat terlibat dalam cara-cara berikut:
Memberikan Keahlian Teknis. Fase desain terperinci melibatkan spesifikasi prosedur,
aturan, dan konvensi yang tepat untuk digunakan dalam sistem. Dalam hal AIS,
spesifikasi ini harus mematuhi GAAP, GAAS, peraturan SEC, dan kode IRS. Kegagalan
untuk mematuhi dapat menyebabkan paparan hukum untuk perusahaan. Misalnya,
memilih metode depresiasi yang benar atau teknik penilaian aset membutuhkan latar
belakang teknis yang tidak harus dimiliki oleh para profesional sistem. Auditor dapat
memberikan keahlian ini untuk proses desain sistem.
Tentukan Standar Dokumentasi. Dalam fase implementasi, auditor berperan dalam
menentukan dokumentasi sistem. Karena sistem keuangan harus diaudit secara
berkala, mereka harus didokumentasikan secara memadai. Auditor harus secara aktif
mendorong kepatuhan pada standar dokumentasi yang efektif.
Verifikasi Kecukupan Kontrol dan Kepatuhan dengan SOX. Aplikasi AIS yang
muncul dari SDLC harus memiliki kontrol yang memadai. Selain itu, kepatuhan terhadap
undang-undang SOX mensyaratkan manajemen untuk menyatakan keberadaan dan
keefektifan kontrol tersebut. Selama proses implementasi, fungsi audit internal
memainkan peran kunci dalam kegiatan verifikasi dan kepatuhan ini.
 Post-Implementation Review.
Tinjauan ini dilakukan oleh tim penyidik independen untuk mengukur keberhasilan
sistem dan proses setelah debu hilang. Meskipun profesional sistem berusaha untuk
menghasilkan sistem yang sesuai anggaran, tepat waktu, dan memenuhi kebutuhan
pengguna, tujuan ini tidak selalu tercapai. Tinjauan pasca-implementasi sistem yang
baru diinstal dapat memberikan wawasan kepada manajemen tentang cara-cara untuk
memperbaiki proses untuk sistem di masa depan. Ini juga dapat memberikan auditor
(baik internal dan eksternal) bukti tentang kecukupan SDLC secara umum dan risiko
yang terkait dengan sistem tertentu.
Berikut ini adalah contoh bukti pasca implementasi yang berharga:
Kecukupan Desain Sistem. Fitur fisik sistem harus ditinjau untuk melihat apakah
mereka memenuhi kebutuhan pengguna. Peninjau harus mencari jawaban untuk jenis
pertanyaan berikut:
 Apakah output dari sistem memiliki karakteristik informasi seperti relevansi, ketepatan
waktu, kelengkapan, akurasi, dan sebagainya?
 Apakah output dalam format yang paling berguna dan diinginkan oleh pengguna
(seperti tabel, grafik, elektronik, hard copy, dan sebagainya)?
 Apakah databasenya akurat, lengkap, dan dapat diakses?
 Apakah data hilang, rusak, atau digandakan oleh proses konversi?
 Apakah formulir dan layar input dirancang dengan baik dan memenuhi kebutuhan
pengguna?
 Apakah pengguna menggunakan sistem dengan benar?
 Apakah pemrosesan tampaknya benar?
 Dapatkah semua modul program diakses dan dieksekusi dengan benar, atau apakah
pengguna pernah terjebak dalam satu lingkaran?
 Apakah dokumentasi pengguna akurat, lengkap, dan mudah diikuti?
 Apakah sistem menyediakan bantuan dan tutorial yang memadai kepada pengguna?

Keakuratan waktu, biaya, estimasi manfaat. Dalam memperkirakan waktu, biaya, dan
manfaat untuk sistem yang diusulkan dipersulit oleh ketidakpastian. Semakin banyak
variabel dalam proses, semakin besar kemungkinan kesalahan material dalam estimasi.
Oleh karena itu, peninjauan kinerja aktual dibandingkan dengan jumlah yang
dianggarkan memberikan input penting untuk keputusan penganggaran di masa depan.
Pertanyaan-pertanyaan berikut memberikan beberapa wawasan:
 Apakah biaya aktual sesuai dengan biaya yang dianggarkan?
 Apa bidang keberangkatan signifikan dari anggaran?
 Apakah keberangkatan dari anggaran dapat dikendalikan (internal) dalam jangka
pendek atau tidak dapat dikendalikan (misalnya, masalah pemasok)?
 Apakah perkiraan jumlah baris kode program akurat?
 Apakah tingkat pengerjaan ulang karena kesalahan desain dan pengkodean dapat
diterima?
 Apakah pengguna menerima manfaat yang diharapkan dari sistem?
 Apakah nilai yang diberikan untuk manfaat berwujud dan, terutama, tidak berwujud
akurat?

2.3.8 System Maintenance – Phase VIII


Setelah suatu sistem diimplementasikan, ia memasuki fase akhir dalam siklusnya.
Pemeliharaan sistem adalah proses formal dimana program aplikasi mengalami
perubahan untuk mengakomodasi perubahan dalam kebutuhan pengguna. Pemeliharaan
juga bisa ekstensif, seperti membuat perubahan besar pada logika aplikasi dan antarmuka
pengguna. Tergantung pada organisasi, periode pemeliharaan sistem dapat bertahan 5
tahun atau lebih. Sistem dalam lingkungan bisnis yang sangat kompetitif melihat masa
hidup sistem yang jauh lebih pendek. Ketika tidak lagi layak bagi organisasi untuk terus
mempertahankan sistem penuaan, itu dihilangkan, dan siklus pengembangan sistem baru
dimulai.
Pemeliharaan merupakan pengeluaran sumber daya yang signifikan dibandingkan
dengan biaya pengembangan awal. Selama masa hidup sistem, sebanyak 80 hingga 90
persen dari total biaya mungkin dikeluarkan pada tahap pemeliharaan.
2.4 Controlling And Auditing The SDLC (System Development Life Cycle)
Bab ini meninjau proses yang sangat kompleks yaitu SDLC. Secara sederhana, tujuan
audit keuangan adalah untuk memberikan pendapat ahli tentang penyajian laporan
keuangan yang adil. Untuk memberikan pendapat, auditor harus melakukan tes audit
tertentu. Dalam lingkungan CBIS, data keuangan diproses (diakses, disimpan, dan
dimutakhirkan) oleh aplikasi komputer. Keakuratan dan integritas program-program ini
secara langsung mempengaruhi keakuratan data keuangan klien.
Proses pemeliharaan sistem memastikan bahwa hanya perubahan sah yang dibuat untuk
aplikasi dan bahwa perubahan tersebut juga diuji sebelum diimplementasikan. Proses ini
membangun keakuratan aplikasi baru dan menjaga integritasnya selama periode yang
ditinjau. Jika auditor dapat memverifikasi bahwa proses-proses ini dikendalikan secara
efektif, ia dapat membatasi tingkat pengujian aplikasi yang perlu dilakukan. Namun, jika
bukti audit menunjukkan kontrol SDLC menjadi lemah dan diterapkan secara tidak
konsisten, pengujian aplikasi dan pengujian substantif tidak dapat dikurangi. Dalam
beberapa situasi, bahkan mungkin perlu untuk memperluas ruang lingkup audit.
2.4.1 Controlling New System Development
Lima aktivitas pertama yang dapat dikontrol dibahas selanjutnya dengan otorisasi,
pengembangan, dan implementasi sistem asli. Dua aktivitas terkendali terakhir yang
berkaitan dengan prosedur pemeliharaan sistem.
1. Kegiatan Otorisasi Sistem.
Semua sistem harus diberi wewenang dengan benar untuk memastikan pembenaran
dan kelayakan ekonomi mereka. Seperti halnya semua transaksi material, otorisasi
pengembangan sistem informasi baru harus menjadi langkah formal dalam proses.
2. Aktivitas Spesifikasi Pengguna.
Pengguna harus secara aktif terlibat dalam proses pengembangan sistem.
Keterlibatan mereka tidak boleh diredam karena sistem yang diusulkan secara teknis
rumit. Terlepas dari teknologi yang terlibat, pengguna dapat dan harus memberikan
uraian tertulis terperinci tentang kebutuhan logis yang harus dipenuhi oleh sistem.
3. 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 yang terperinci. Kecukupan kegiatan ini diukur dengan kualitas
dokumentasi yang muncul dari setiap fase. Dokumentasi merupakan kontrol dan bukti
kontrol dan sangat penting untuk keberhasilan jangka panjang sistem.
4. Partisipasi Audit Internal.
Auditor internal memainkan peran penting dalam pengendalian kegiatan
pengembangan sistem, khususnya di organisasi yang penggunanya tidak memiliki
keahlian teknis. Auditor internal dapat berfungsi sebagai penghubung antara
pengguna dan profesional sistem untuk memastikan transfer pengetahuan yang
efektif. Grup audit internal, yang pandai dalam teknologi komputer dan dengan
pemahaman yang kuat tentang masalah bisnis pengguna, dapat membuat kontribusi
yang berharga untuk semua aspek proses SDLC.
5. Tes Pengguna dan Prosedur Penerimaan.
Tepat sebelum implementasi, modul individual dari sistem harus diuji sebagai satu
kesatuan. Tim uji yang terdiri dari personel pengguna, profesional sistem, dan
personel audit internal menerapkan sistem pengujian yang ketat. Setelah tim
pengujian puas bahwa sistem memenuhi persyaratan yang dinyatakan, sistem secara
formal diterima oleh departemen pengguna.
6. Tujuan Audit Terkait dengan Pengembangan Sistem Baru.
 Pastikan kegiatan SDLC diterapkan secara konsisten dan sesuai dengan kebijakan
manajemen.
 Tentukan bahwa sistem dan penipuan.
 Konfirmasikan bahwa sistem dinilai perlu dan dibenarkan di berbagai titik
pemeriksaan di seluruh SDLC.
 Verifikasi bahwa dokumentasi sistem cukup akurat dan lengkap untuk memfasilitasi
kegiatan audit dan pemeliharaan.
7. Prosedur Audit Terkait dengan Pengembangan Sistem Baru.
Auditor harus memilih sampel proyek yang diselesaikan (diselesaikan pada periode
berjalan dan periode sebelumnya) dan meninjau dokumentasi untuk bukti kepatuhan
dengan kebijakan SDLC. Poin spesifik untuk peninjauan harus mencakup menentukan
hal-hal berikut:
 Manajemen pengguna dan layanan komputer mengotorisasi proyek dengan benar.
 Sebuah studi kelayakan awal menunjukkan bahwa proyek itu pantas.
 Analisis rinci kebutuhan pengguna dilakukan yang menghasilkan desain umum
alternatif.
 Analisis biaya-manfaat dilakukan dengan menggunakan angka yang cukup akurat.
 Dokumentasi proyek menunjukkan bahwa desain terperinci adalah solusi yang tepat
dan akurat untuk masalah pengguna.
 Hasil pengujian menunjukkan bahwa sistem diuji secara menyeluruh pada modul
individu dan tingkat total sistem sebelum implementasi. (Untuk mengkonfirmasi hasil
tes ini, auditor dapat memutuskan untuk menguji ulang elemen aplikasi yang dipilih.)
 Ada daftar periksa masalah khusus yang terdeteksi selama periode konversi,
bersama dengan bukti bahwa mereka diperbaiki pada fase pemeliharaan.
 Dokumentasi sistem sesuai dengan persyaratan dan standar organisasi.

2.4.2 The Controlling System Maintenance


Dua aktivitas terkendali terakhir berkaitan dengan pemeliharaan sistem. Setelah
implementasi, sistem memasuki fase pemeliharaan SDLC. Jika suatu aplikasi telah
melakukan perawatan (dan bahkan jika itu belum), integritasnya mungkin telah terganggu
sejak implementasi. Oleh karena itu, tinjauan auditor dapat meluas ke fase pemeliharaan
untuk menentukan bahwa integritas aplikasi masih utuh.
 Otorisasi, Pengujian, dan Dokumentasi Pemeliharaan.
Manfaat yang diperoleh dari mengendalikan pengembangan sistem baru dapat hilang
jika pemeliharaan sistem kontrol tidak berlanjut ke fase itu. Akses ke sistem untuk tujuan
pemeliharaan meningkatkan kemungkinan kesalahan sistem. Untuk meminimalkan
potensi paparan, semua tindakan pemeliharaan harus membutuhkan, minimal, empat
kontrol: otorisasi formal, spesifikasi teknis dari perubahan, menguji ulang sistem, dan
memperbarui dokumentasi.
 Sumber Program Kontrol Perpustakaan.
Terlepas dari prosedur pemeliharaan sebelumnya, integritas aplikasi dapat
dioptimalisasi oleh individu yang memperoleh akses tidak sah ke program. Sisa dari
bagian ini berkaitan dengan teknik kontrol dan prosedur untuk mencegah dan
mendeteksi akses tidak resmi ke program aplikasi.
 Situasi Kasus Terburuk: Tidak Ada Kontrol.
1. Akses ke program sama sekali tidak dibatasi. Pemrogram dan yang lain dapat
mengakses program apa pun yang disimpan di perpustakaan, dan tidak ada
ketentuan untuk mendeteksi intrusi yang tidak sah.
2. Karena kelemahan kontrol ini, program dapat berubah tanpa izin Oleh karena itu,
tidak ada dasar untuk mengandalkan efektivitas kontrol lain (otorisasi pemeliharaan,
pengujian program, dan dokumentasi). Dengan kata lain, tanpa ketentuan untuk
mendeteksi akses tidak sah ke SPL, integritas program tidak dapat diverifikasi.
 Lingkungan SPL Terkendali.
Untuk mengontrol SPL, fitur dan prosedur pelindung harus ditangani secara eksplisit,
dan ini membutuhkan penerapan sistem manajemen SPL (SPLMS). Perangkat lunak ini
digunakan untuk mengontrol empat fungsi rutin tetapi penting: (1) menyimpan program
pada SPL, (2) mengambil program untuk tujuan pemeliharaan, (3) menghapus program
yang tidak terpakai dari perpustakaan, dan (4) mendokumentasikan perubahan program
ke memberikan jejak audit perubahan.
 Kontrol Kata Sandi.
Menetapkan kata sandi menyediakan satu bentuk kontrol akses atas SPL. Ini mirip
dengan kontrol kata sandi yang digunakan dalam DBMS untuk melindungi file data.
Setiap program penting secara finansial yang disimpan dalam SPL dapat diberi kata
sandi terpisah.
 Perpustakaan Uji terpisah.
Peningkatan pada pendekatan kata sandi bersama melalui pembuatan pustaka (atau
direktori) yang dikendalikan kata sandi terpisah untuk setiap programmer. Di bawah
konsep ini, program disalin ke perpustakaan programmer untuk pemeliharaan dan
pengujian. Akses langsung ke SPL produksi terbatas pada pustakawan resmi yang
harus menyetujui semua permintaan untuk memodifikasi, menghapus, dan menyalin
program.
 Jejak Audit dan Laporan Manajemen.
Fitur penting dari perangkat lunak manajemen SPL adalah pembuatan laporan yang
meningkatkan kontrol manajemen dan fungsi audit. Yang paling berguna dari ini 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 perubahan
program selama masa aplikasi.
 Nomor Versi Program.
SPLMS memberikan nomor versi secara otomatis ke setiap program yang disimpan di
SPL. Ketika program pertama kali ditempatkan di perpustakaan (setelah implementasi),
mereka diberi nomor versi 0. Dengan setiap modifikasi pada program, nomor versi
ditingkatkan dengan 1. Perubahan yang tidak sah ditandai dengan nomor versi pada
modul beban produksi yang tidak dapat direkonsiliasi dengan jumlah perubahan yang
diotorisasi.
 Mengontrol Akses ke Perintah Perawatan.
Sistem manajemen SPL menggunakan perintah perawatan yang kuat untuk mengubah
atau menghilangkan kata sandi program, mengubah nomor versi pro (modifikasi), dan
sementara memodifikasi program tanpa membuat catatan modifikasi.

Tujuan Audit Terkait dengan Pemeliharaan Sistem.


Mendeteksi pemeliharaan program yang tidak sah (yang mungkin mengakibatkan
kesalahan pemrosesan yang signifikan atau penipuan). Menentukan bahwa (1) prosedur
pemeliharaan melindungi aplikasi dari perubahan yang tidak sah, (2) aplikasi bebas dari
kesalahan material, dan (3) perpustakaan program dilindungi dari akses yang tidak sah.

Prosedur Audit Terkait dengan Pemeliharaan Sistem.


 Identifikasi Perubahan 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:
 merekonsiliasi nomor versi program.
 konfirmasi otorisasi pemeliharaan.
 Identifikasi Kesalahan Aplikasi.
Auditor dapat menentukan bahwa program bebas dari kesalahan material dengan
melakukan tiga jenis tes kontrol:
 merekonsiliasi kode sumber,
 meninjau hasil pengujian, dan
 menguji ulang program.
 Uji Akses ke Perpustakaan.
Keberadaan perpustakaan program yang aman adalah pusat untuk mencegah
kesalahan dan penipuan program. Salah satu metode adalah untuk menetapkan hak
akses perpustakaan secara eksklusif untuk individu yang bertindak sebagai pustakawan.
Fungsinya untuk mengambil aplikasi dari perpustakaan program untuk pemeliharaan
dan mengembalikan program yang dimodifikasi ke perpustakaan. Auditor harus
menetapkan bahwa perpustakaan program dan perpustakaan pribadi dilindungi dari
akses yang tidak sah dengan melakukan tes kontrol berikut ini:
 Tinjau tabel otoritas programmer.
Auditor dapat memilih sampel programmer dan meninjau otoritas akses mereka.
Otorisasi ini harus disesuaikan dengan otoritas pemeliharaan programmer untuk
memastikan tidak ada penyimpangan yang ada.
 Uji tabel otoritas. Auditor harus mensimulasikan hak akses programmer dan
kemudian melanggar aturan otorisasi dengan mencoba mengakses perpustakaan
yang tidak sah. Upaya apa pun harus ditolak oleh sistem operasi. .