Systems Development and Program Change Activities

Tugas Mata Kuliah

Auditing EDP

Oleh:
Yudhistira Dewa Kartika Hediansyah (200810301036)
Rizky Nugroho Santoso (200810301113)
Alfath Dhafin (200810301157)

Program Studi Akuntansi

Fakultas Ekonomi dan Bisnis
Universitas Jember
2023
SURAT PERNYATAAN INTEGRITAS PENYUSUNAN RESUME

Yang bertanda tangan di bawah ini :

Nama : Rizky Nugroho Santoso

NIM : 200810301113

Sebagai perwakilan anggota kelompok 8, dengan ini menyatakan bahwa resume

materi yang berjudul “Systems Development & Program Change Activities” merupakan
karya orisinal kelompok dan tidak menjiplak hasil pekerjaan orang lain.

Jika di kemudian hari ditemukan ketidakbenaran informasi, maka anggota kelompok

bersedia menerima segala konsekuensi yang diberikan oleh dosen pengampu mata
kuliah Audit EDP.

Jember, 2 April 2023

Rizky Nugroho Santoso

PENDAHULUAN:
Jelaskan:
1. Apa yang akan kelompok saudara tulis?
Jawab : Kelompok kami akan menulis sebuah resume yang berjudul “Systems
Development & Program Change Activities”, dimana dalam resume ini akan
membahas berbagai macam tahapan dalam SDLC (systems development life
cycle), serta mendeskripsikan masalah umum yang dapat menyebabkan
kegagalan dalam proses pengembangan sistem.

2. Mengapa topik tersebut menarik untuk dipelajari?

Jawab : Menurut kelompok kami, topik ini menarik untuk dipelajari karena salah
satu aset paling berharga dari organisasi bisnis modern adalah sistem informasi
yang responsif dan berorientasi pada pengguna. Sistem yang dirancang dengan
baik dapat meningkatkan produktivitas, mengurangi persediaan, menghilangkan
aktivitas yang tidak bernilai tambah, meningkatkan layanan pelanggan dan
keputusan manajemen, serta mengoordinasikan aktivitas di seluruh organisasi.
1. PARTICIPANTS IN SYSTEMS DEVELOPMENT
Peserta dalam pengembangan sistem dapat diklasifikasikan menjadi empat
kelompok besar:
a. Systems professionals
Ini merupakan analis sistem, insinyur sistem, dan pemrogram.
b. End users
Ini adalah mereka yang sistemnya dibangun. Ada banyak pengguna di
semua tingkatan sebuah organisasi.
c. Stakeholders.
Stakeholder adalah individu baik di dalam maupun di luar organisasi yang
memiliki tertarik pada sistem tetapi bukan pengguna akhir.
d. Accountants/Auditors
Akuntan/Auditor adalah profesional yang menangani pengendalian,
akuntansi, dan masalah audit untuk pengembangan sistem. Keterlibatan ini
harus mencakup auditor internal dan auditor TI.
● Why Are Accountants and Auditors Involved with SDLC?
Proses SDLC menarik bagi akuntan dan auditor karena dua alasan.
Pertama, penciptaan sistem informasi memerlukan transaksi keuangan
yang signifikan. Secara konseptual, system pengembangan seperti
setiap proses manufaktur yang menghasilkan produk yang kompleks
melalui rangkaian tahapan.
Perhatian kedua dan lebih mendesak bagi para akuntan dan auditor
adalah sifat produk yang muncul dari SDLC. Kualitas informasi
akuntansi bertumpu langsung pada kegiatan SDLC yang menghasilkan
sistem informasi akuntansi (SIA). Sistem ini memberikan informasi
akuntansi kepada pengguna internal dan eksternal.
● How Are Accountants Involved with the SDLC?
Akuntan terlibat dalam pengembangan sistem dalam tiga cara. Pertama,
akuntan pengguna. Semua sistem yang memproses transaksi keuangan
berdampak pada fungsi akuntansi beberapa cara. Seperti semua
pengguna, akuntan harus memberikan gambaran yang jelas tentang
masalah mereka dan kebutuhan sistem profesional.
Kedua, akuntan berpartisipasi dalam pengembangan sistem sebagai
anggota tim pengembangan. Keterlibatan mereka seringkali melampaui
 pengembangan aplikasi AIS yang ketat. Sistem yang tidak memproses
transaksi keuangan secara langsung mungkin masih menarik
data akuntansi.
Ketiga, akuntan terlibat dalam pengembangan sistem sebagai auditor.
Akuntansi dalam sistem formasi harus dapat diaudit. Beberapa teknik
audit komputer membutuhkan khusus
fitur yang perlu dirancang ke dalam sistem selama SDLC.
2. INFORMATION SYSTEMS ACQUISITION
Organisasi biasanya memperoleh sistem informasi dengan dua cara: (1)
mereka mengembangkan sistem yang disesuaikan secara in-house melalui
kegiatan pengembangan sistem formal dan (2) mereka membeli sistem
komersial dari vendor perangkat lunak. Bagian teks ini membahas dua alternatif
ini.
a. In-House Development
Banyak organisasi membutuhkan sistem yang sangat disesuaikan dengan
operasi unik mereka. Perusahaan-perusahaan ini merancang sistem
informasi mereka sendiri melalui kegiatan pengembangan sistem in-house.
b. Commercial Systems
Semakin banyak sistem yang dibeli dari vendor perangkat lunak.
Berhadapan dengan banyak paket bersaing, masing-masing dengan fitur
dan atribut unik, manajemen harus memilih sistem dan vendor yang paling
melayani kebutuhan organisasi. Membuat pilihan yang optimal
mengharuskan ini menjadi keputusan yang tepat.
Trends in Commercial Software
Empat faktor telah mendorong pertumbuhan pasar perangkat lunak
komersial: (1) biaya perangkat lunak komersial umum yang relatif rendah
dibandingkan dengan perangkat lunak yang disesuaikan; (2) munculnya
vendor khusus industri yang menargetkan perangkat lunak mereka untuk
kebutuhan jenis usaha tertentu; (3) meningkatnya permintaan dari bisnis
yang terlalu kecil untuk membayar staf pengembangan sistem internal; dan
(4) tren ke arah perampingan unit organisasi dan hasil yang bergerak ke
arah lingkungan pemrosesan data terdistribusi, yang telah membuat opsi
perangkat lunak komersial lebih menarik bagi organisasi yang lebih besar.
Types of Commercial Systems
a) Turnkey Systems
 b) General Accounting Systems
c) Special-Purpose Systems
d) Office Automation Systems
e) Backbone Systems
f) Vendor-Supported Systems
Advantages of Commercial Software
● Implementation time
● Cost
● Reliability
Disadvantages of Commercial Software
a. Independence
b. The need for customized systems
c. Maintenance
3. THE SYSTEMS DEVELOPMENT LIFE CYCLE

a. Systems Planning—Phase I
Tujuan perencanaan sistem adalah untuk menghubungkan proyek atau
aplikasi sistem individual ke tujuan strategis perusahaan. Bahkan, dasar
untuk rencana sistem adalah rencana bisnis organisasi, yang menentukan
ke mana perusahaan akan pergi dan bagaimana cara mencapainya.
b. Systems Analysis—Phase II
Analisis sistem sebenarnya adalah proses dua langkah yang pertama
melibatkan survei sistem saat ini dan kemudian analisis system kebutuhan
pengguna. Masalah bisnis harus dipahami sepenuhnya oleh analis sistem
sebelumnya dia dapat merumuskan solusi. Analisis yang tidak lengkap atau
cacat akan menyebabkan solusi yang tidak lengkap atau cacat. Oleh karena
itu, analisis sistem merupakan dasar untuk SDLC lainnya.
The Survey Step
Sebagian besar sistem tidak dikembangkan dari awal. Biasanya, beberapa
bentuk sistem informasi dan prosedur terkait saat ini di tempat. Analis
sering memulai analisis dengan menentukan elemen apa, jika ada, dari
sistem saat ini harus dipertahankan sebagai bagian darinya sistem baru. Ini
melibatkan survei sistem yang agak rinci. Fakta yang berkaitan dengan
pertanyaan awal tentang sistem dikumpulkan dan dianalisis.
Gathering Facts
Survei sistem saat ini pada dasarnya adalah kegiatan pengumpulan fakta.
Fakta-fakta yang dikumpulkan oleh analis adalah potongan-potongan data
yang menjelaskan ciri-ciri utama, situasi, dan hubungan system.
a) Data sources
b) Users
c) Data stores
d) Processes
e) Data flows
f) Controls
g) Transiction volumes
h) Error rates
i) Resource costs
j) Bottlenecks and redundant operations
Fact-Gathering Techniques
 Analis sistem menggunakan beberapa teknik untuk mengumpulkan fakta
yang dikutip sebelumnya. Teknik yang umum digunakan ialah.
a. Observation
b. Task participation
c. Personal Interviews
d. Reviewing Key Documents
The Analysis Step
Analisis sistem adalah proses intelektual yang bercampur dengan
pengumpulan fakta. Itu analis secara bersamaan menganalisis saat dia
mengumpulkan fakta. Pengakuan belaka suatu masalah mengandaikan
beberapa pemahaman tentang norma atau keadaan yang diinginkan. Oleh
karena itu sulit untuk mengidentifikasi di mana survei berakhir.
Systems Analysis Report
Acara yang menandai kesimpulan dari fase analisis sistem adalah
persiapan laporan analisis sistem formal. Laporan ini menyajikan kepada
manajemen atau panitia pengarah temuan survei, masalah yang
diidentifikasi dengan sistem saat ini, kebutuhan pengguna, dan persyaratan
sistem baru.
The Auditor’s Role in Systems Analysis
Auditor perusahaan (baik eksternal maupun internal) adalah pemangku
kepentingan dalam sistem yang diusulkan. CAATT tertentu (seperti modul
audit tertanam dan fasilitas pengujian terintegrasi) harus dirancang ke
dalam sistem selama SDLC. Seringkali, fitur audit tingkat lanjut tidak dapat
dengan mudah ditambahkan ke sistem yang sudah ada. Oleh karena itu,
akuntan/auditor harus dilibatkan dalam analisis kebutuhan sistem yang
diusulkan untuk menentukan apakah kandidat yang baik untuk fitur audit
lanjutan dan, jika ya, fitur mana yang paling cocok untuk sistem tersebut.

Conceptual Systems Design - Phase III

Tujuan dari fase kerangka konseptual ialah untuk membuat beberapa alternatif
sistem konseptual yang disesuaikan dengan persyaratan sistem yang telah
diidentifikasi pada analisis sistem. Dengan menunjukkan pengguna dengan beberapa
alternatif, ahli sistem dapat menghindari pemaksaan kendala yang telah terbentuk
sebelumnya. Pengguna akan mengevaluasi kerangka konsepual dan menentukan
alternatif mana yang paling menarik. Model alternatif ini selanjutnya menuju fase
pemilihan sistem dari SLDC dimana biaya serta manfaat dibandingkan dan
dilakukannya pemilihan. Terdapat dua pendekatan pada kerangka konseptual sistem,
diantaranya adalah:
a. Structured Design Approach
Pendekatan ini menekankan bahwa sistem dibuat atau didesain secara top-
down.
b. The Object-Oriented Approach
Pendekatan ini menyatakan bahwa sistem informasi dibuat dengan
menggunakan komponen standar atau objek yang telah ada.

System Evaluation and Selection - Phase IV

Fase ini merupakan proses pengoptimalan guna mengidentifikasi sistem mana
yang merupakan sistem terbaik. Keputusan ini merupakan titik kritis dalam SDLC.
Dalam fase ini, terdapat ketidakpastian terhadap sistem dan keputusan yang salah
akan berdampak sangat besar. Tujuan dari evaluasi formal dan prosedur pemilihan
ialah untuk mengstrukturisasi dari proses pengambilan keputusan dan untuk
merendahkan ketidakpastian serta risiko dari pengambilan keputusan yang salah.
Proses ini dilakukan dengan dua langkah, yaitu:
1. Melakukan studi kelayakan yang terperinci
2. Mengkaji dan menganalisis biaya-manfaat

Detailed Design - Phase V

Tujuan dari fase ini ialah untuk menghasilkan deskripsi yang detail terkait
sistem yang diajukan yang disesuaikan dengan persyaratan sistem dan keselarasan
dengan kerangka konseptual. Setiap komponen sistem secara rinci ditentukan. Pada
akhirnya, komponen ini dilaporkan secara formal. Laporan tersebut merupakan
beberapa pasang cetak biru yang menjelaskan input screen format, output report
layouts, struktur database, dan process logic. Proses ini dilakukan dengan dua langka,
yaitu:
1. Perform a system design walkthrough
2. Review system documentation

Application Programming and Testing - Phase VI

Langkah selanjutnya dari SDLC ialah untuk memilih bahasa programming dari
berbagai bahasa pemograman yang ada dan terdapat pada aplikasi. Hal ini juga
terdapat bahasa prosedur seperti COBOI, event-driven languages seperti Visual Basic,
atau object-oriented programming languages seperti Java atau C++. Langkah ini
dilakukan berbagai observasi dari berbagai pendekatan programming. Profesional
sistem akan membuat keputusan berdasarkan standar internal, arsitektur, dan
kebutuhan pengguna. Semua modul program harus diuji secara menyeluruh sebelum
diimplementasikan. Ada beberapa konsep yang terbukti tentang pengujian yang harus
diikuti oleh pengembang sistem, dan dipertimbangkan oleh auditor dalam melakukan
audit.

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.

1. 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.

2. 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.

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. 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.

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.

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

REFERENSI
James A. Hall. 2011. Information Technology Auditing and Assurance. Cengage
Learning.