Sistem Pengembangan dan Program

Ubah Kegiatan
TUJUAN PEMBELAJARAN
Setelah mempelajari bab ini, Anda harus:
• Mampu mengidentifikasi tahapan dalam SDLC.
• Terbiasa dengan masalah umum yang dapat menyebabkan kegagalan dalam
pengembangan sistem
proses.
• Memahami pentingnya perencanaan sistem strategis.
• Memiliki pemahaman umum tentang bagaimana akuntan berpartisipasi dalam SDLC.
• Mampu mengidentifikasi fitur dasar baik yang terstruktur dan berorientasi
objek
pendekatan untuk desain sistem.
• Mampu mengidentifikasi dan mendiskusikan langkah-langkah utama yang terlibat
dalam analisis biaya-manfaat
sistem informasi yang diusulkan.
• Memahami kelebihan

PESERTA DALAM PENGEMBANGAN SISTEM

1. Profesional sistem adalah analis sistem, insinyur sistem, dan pemrogram.
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 di
sebuah organisasi. Ini termasuk manajer, 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
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
tertarik pada sistem tetapi bukan pengguna akhir. Ini termasuk akuntan,
internal dan
auditor eksternal, dan komite pengarah internal yang mengawasi sistem
pengembangan.
4. Akuntan / Auditor adalah para profesional yang menangani kontrol,
akuntansi,
dan masalah 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

Proses SDLC menarik bagi akuntan dan auditor karena dua alasan. Pertama,
penciptaan sistem informasi memerlukan transaksi keuangan yang signifikan.
Secara konseptual, sistem
pengembangan seperti proses manufaktur yang menghasilkan produk yang kompleks
melalui a
serangkaian tahapan. Transaksi tersebut harus direncanakan, disahkan,
dijadwalkan, dipertanggungjawabkan,
dan dikendalikan. Akuntan sama peduli dengan integritas proses ini seperti
mereka
dengan setiap proses manufaktur yang memiliki implikasi sumber daya keuangan.
Karena mereka
latar belakang, pengalaman, dan pelatihan, akuntan dan auditor adalah ahli di
bidang keuangan
transaksi dan dengan demikian dapat memberikan input penting ke dalam sistem
mengenai kontrol, integritas,
ketepatan waktu, dan sejumlah aspek penting lainnya dari transaksi keuangan.
Kekhawatiran kedua dan lebih mendesak bagi akuntan dan auditor adalah dengan
sifat produk yang muncul dari SDLC. Kualitas informasi akuntansi
bersandar langsung pada kegiatan SDLC yang menghasilkan sistem informasi
akuntansi (AIS).
Sistem ini memberikan informasi akuntansi kepada pengguna internal dan
eksternal. Tanggung jawab akuntan adalah untuk memastikan bahwa sistem
menggunakan konvensi akuntansi yang tepat
dan aturan, dan memiliki kontrol yang memadai. Karena itu, akuntan sangat
peduli
dengan kualitas proses yang menghasilkan AIS. Misalnya, sistem pesanan
penjualan yang dihasilkan oleh SDLC yang rusak dapat menderita dari kelemahan
kontrol serius yang diperkenalkan
kesalahan ke dalam catatan akuntansi keuangan, atau memberikan peluang untuk
penipuan
Pelajari pengucapannya

Akuntan terlibat dalam pengembangan sistem dalam tiga cara. Pertama, akuntan
pengguna. Semua sistem yang memproses transaksi keuangan berdampak pada fungsi
akuntansi di
entah bagaimana. Seperti semua pengguna, akuntan harus memberikan gambaran
yang jelas tentang masalah mereka dan
172 Bab 5: Pengembangan Sistem dan Kegiatan Perubahan Program
Hak Cipta 2011 Cengage Learning, Inc. Semua Hak Dilindungi Undang-Undang.
Tidak boleh disalin, dipindai, atau digandakan, seluruhnya atau sebagian.
perlu untuk para profesional sistem. Sebagai contoh, akuntan harus menentukan
akuntansi
teknik yang akan digunakan, persyaratan kontrol internal (seperti jalur
audit), dan khusus
algoritma (seperti model depresiasi).
Kedua, akuntan berpartisipasi dalam pengembangan sistem sebagai anggota tim
pengembangan. Keterlibatan mereka sering melampaui pengembangan aplikasi AIS.
Sistem yang tidak memproses transaksi keuangan secara langsung mungkin masih
menarik
data akuntansi. Akuntan dapat dikonsultasikan untuk memberikan saran atau
untuk menentukan apakah
sistem yang diusulkan merupakan risiko pengendalian internal. Dalam semua
kasus, tingkat auditor
Partisipasi dibatasi oleh masalah independensi dalam standar dan etika
profesional.
Ketiga, akuntan terlibat dalam pengembangan sistem sebagai auditor. Sistem
informasi akuntansi harus diaudit. Beberapa teknik audit komputer memerlukan
khusus
fitur yang perlu dirancang ke dalam sistem selama SDLC. Kami memeriksa itu
alat audit dan penggunaannya dalam Bab 7 dan 8. Auditor memiliki kepentingan
dalam semua sistem
dan harus dilibatkan sejak awal dalam desain mereka, terutama terkait dengan
kemampuan audit, keamanan, dan kontrol mereka.
AKUISISI SISTEM INFORMASI
Pengembangan In-House
 Pengembangan in-house membutuhkan pemeliharaan staf sistem penuh waktu di
analis dan programmer yang mengidentifikasi kebutuhan informasi pengguna dan
memenuhi kebutuhan mereka
dengan sistem khusus.
Sistem Komersial
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
sesuai 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 gerakan yang dihasilkan ke arah lingkungan pemrosesan data
terdistribusi,
yang telah membuat opsi perangkat lunak komersial lebih menarik bagi
organisasi yang lebih besar. Memang, organisasi yang memiliki staf
pengembangan sistem in-house mereka sendiri akan sering
membeli perangkat lunak komersial ketika diperlukan
Jenis Sistem Komersial
Sistem turnkey sepenuhnya selesai dan sistem teruji itu
siap untuk implementasi. Ini sering merupakan sistem tujuan umum atau sistem
yang disesuaikan untuk industri tertentu
Sistem akuntansi umum dirancang untuk melayani a
berbagai macam kebutuhan pengguna.
Sistem Tujuan Khusus. Beberapa vendor perangkat lunak membuat sistem tujuan
khusus
yang menargetkan segmen terpilih dari sistem otomasi economice office adalah
sistem komputer itu
meningkatkan produktivitas pekerja kantor.
Sistem tulang punggung menyediakan struktur sistem dasar untuk
membangun. Sistem backbone hadir dengan semua modul pemrosesan utama yang
diprogram.
Sistem yang didukung oleh vendor adalah gabungan dari sistem khusus dan
perangkat lunak komersial

Keuntungan Perangkat Lunak Komersial

• Waktu Implementasi. Sistem kustom seringkali membutuhkan waktu lama untuk
dikembangkan. Bulan
atau bahkan bertahun-tahun dapat berlalu sebelum sistem bea cukai dapat
dikembangkan melalui in-house
Prosedur
• Biaya. Seorang pengguna harus sepenuhnya menyerap biaya pengembangan in-
house. Namun sejak itu
biaya perangkat lunak komersial tersebar di banyak pengguna, biaya unit
berkurang
untuk sebagian kecil dari biaya sistem yang dikembangkan di rumah.
• Keandalan. Sebagian besar paket perangkat lunak komersial terkemuka diuji
secara menyeluruh sebelum dirilis ke pasar konsumen
Kemerdekaan. Membeli sistem yang didukung vendor membuat perusahaan bergantung
vendor untuk pemeliharaan
Kebutuhan akan sistem yang disesuaikan. Keuntungan utama dari pengembangan in-
house adalah
kemampuan untuk menghasilkan aplikasi dengan spesifikasi yang tepat.
Pemeliharaan. Sistem informasi bisnis sering mengalami perubahan. Jika
pengguna
perlu diubah, mungkin sulit atau bahkan tidak mungkin untuk memodifikasi
perangkat lunak komersial

SIKLUS HIDUP PEMBANGUNAN SISTEM

Tujuan dan urutan kegiatan siklus hidup pengembangan sistem (SDLC) adalah
logis dan diterima secara umum oleh para pakar dalam komunitas sistem, dan
umumnya
diperlakukan sebagai "praktik terbaik" untuk pengembangan sistem. Namun, nomor
dan namanya
tahapan spesifik dalam proses ini adalah masalah beberapa ketidaksepakatan.
Pengembangan sistem baru melibatkan langkah-langkah konseptual yang dapat
diterapkan
proses pemecahan masalah: mengidentifikasi masalah, memahami apa yang perlu
dilakukan,
pertimbangkan solusi alternatif, pilih solusi terbaik, dan, akhirnya, terapkan
solusi
Langkah kedelapan,
pemeliharaan sistem, merupakan prosedur perubahan program organisasi; Itu
dimulai setelah tujuh fase selesai dan sistem sepenuhnya diimplementasikan

SIKLUS HIDUP PEMBANGUNAN SISTEM

Tujuan dan urutan kegiatan siklus hidup pengembangan sistem (SDLC) adalah
logis dan diterima secara umum oleh para pakar dalam komunitas sistem, dan
umumnya
diperlakukan sebagai "praktik terbaik" untuk pengembangan sistem. Namun, nomor
dan namanya
tahapan spesifik dalam proses ini adalah masalah beberapa ketidaksepakatan.
Pengembangan sistem baru melibatkan langkah-langkah konseptual yang dapat
diterapkan
proses pemecahan masalah: mengidentifikasi masalah, memahami apa yang perlu
dilakukan,
pertimbangkan solusi alternatif, pilih solusi terbaik, dan, akhirnya, terapkan
solusi
Langkah kedelapan,
pemeliharaan sistem, merupakan prosedur perubahan program organisasi; Itu
dimulai setelah tujuh fase selesai dan sistem sepenuhnya diimplementasikan.
Perencanaan Sistem — Fase I
Khas
tanggung jawab untuk komite pengarah meliputi:
• Mengatasi konflik yang muncul dari sistem baru
• Meninjau proyek dan menetapkan prioritas
• Menganggarkan dana untuk pengembangan sistem
• Meninjau status masing-masing proyek yang sedang dikembangkan
• Menentukan di berbagai pos pemeriksaan di seluruh SDLC apakah akan
melanjutkan
proyek atau menghentikannya
SIKLUS HIDUP PEMBANGUNAN SISTEM
Tujuan dan urutan kegiatan siklus hidup pengembangan sistem (SDLC) adalah
logis dan diterima secara umum oleh para pakar dalam komunitas sistem, dan
umumnya
diperlakukan sebagai "praktik terbaik" untuk pengembangan sistem. Namun, nomor
dan namanya
tahapan spesifik dalam proses ini adalah masalah beberapa ketidaksepakatan.
Pengembangan sistem baru melibatkan langkah-langkah konseptual yang dapat
diterapkan
proses pemecahan masalah: mengidentifikasi masalah, memahami apa yang perlu
dilakukan,
pertimbangkan solusi alternatif, pilih solusi terbaik, dan, akhirnya, terapkan
solusi
Langkah kedelapan,
pemeliharaan sistem, merupakan prosedur perubahan program organisasi; Itu
dimulai setelah tujuh fase selesai dan sistem sepenuhnya diimplementasikan.
Perencanaan Sistem — Fase I
Khas
tanggung jawab untuk komite pengarah meliputi:
• Mengatasi konflik yang muncul dari sistem baru
• Meninjau proyek dan menetapkan prioritas
• Menganggarkan dana untuk pengembangan sistem
• Meninjau status masing-masing proyek yang sedang dikembangkan
• Menentukan di berbagai pos pemeriksaan di seluruh SDLC apakah akan
melanjutkan
proyek atau menghentikannya
Perencanaan Sistem Strategis
Perencanaan sistem strategis melibatkan alokasi sumber daya sistem di makro
tingkat. Biasanya berkaitan dengan jangka waktu 3 hingga 5 tahun
Secara teknis, perencanaan sistem strategis bukan bagian dari SDLC karena SDLC
berkaitan dengan aplikasi spesifik.
Ada empat justifikasi untuk perencanaan sistem strategis:
1. Rencana yang berubah terus-menerus lebih baik daripada tidak ada rencana
sama sekali. Bagan perencanaan strategis
jalur yang akan diikuti perusahaan untuk mencapai tujuan sistem informasinya.
2. Perencanaan strategis mengurangi komponen krisis dalam pengembangan sistem.
Rencana formal
adalah model untuk mengidentifikasi dan memprioritaskan kebutuhan pengguna
3. Perencanaan sistem strategis memberikan kontrol otorisasi untuk SDLC.
Rencana sistem strategis menjabarkan aturan otorisasi untuk memastikan bahwa
keputusan untuk mengembangkan sistem tertentu
kongruen dengan tujuan perusahaan
4. Manajemen biaya. Secara historis, perencanaan sistem telah terbukti efektif
dari segi biaya
sarana mengelola proyek sistem dan pengembangan aplikasi.

Perencanaan proyek
Tujuan perencanaan proyek adalah untuk mengalokasikan sumber daya ke aplikasi
individual di dalamnya
kerangka kerja rencana strategis
Proposal proyek memberikan dasar kepada manajemen untuk memutuskan apakah akan
lanjutkan dengan proyek.
Jadwal proyek mewakili komitmen manajemen terhadap proyek. Itu
jadwal proyek adalah anggaran waktu dan biaya untuk semua fase SDLC.
Peran Auditor dalam Perencanaan Sistem
Auditor secara rutin memeriksa fase perencanaan sistem SDLC. Perencanaan
sangat
mengurangi risiko bahwa suatu organisasi telah menghasilkan yang tidak
dibutuhkan, tidak efisien, tidak efektif,
dan sistem penipuan. Oleh karena itu, auditor internal dan eksternal tertarik
memastikan bahwa perencanaan sistem yang memadai terjadi.

Analisis Sistem — Fase II

Analisis sistem sebenarnya adalah proses dua langkah yang melibatkan pertama
survei sistem saat ini dan kemudian analisis
kebutuhan pengguna. Masalah bisnis harus dipahami sepenuhnya oleh analis
sistem sebelumnya
dia dapat merumuskan solusi
Analis sering memulai analisis dengan
menentukan elemen apa, jika ada, dari sistem saat ini harus dipertahankan
sebagai bagian dari
sistem baru. Ini melibatkan survei sistem yang agak rinci.
Kerugian Survei Sistem Saat Ini
• Lubang tar fisik saat ini. Istilah ini digunakan untuk menggambarkan
kecenderungan pada bagian
analis untuk "tersedot" dan kemudian "macet" dengan tugas mensurvei
sistem dinosaurus saat ini.1
• Berpikir di dalam kotak. Beberapa berpendapat bahwa survei sistem saat ini
menahan ide-ide baru. Oleh
mempelajari dan memodelkan sistem lama, analis dapat mengembangkan gagasan
terbatas
tentang bagaimana sistem yang baru seharusnya berfungsi.
Keuntungan dari Survei Sistem Saat Ini
• Mengidentifikasi aspek apa dari sistem lama yang harus disimpan. Beberapa
elemen sistem mungkin berfungsi secara fungsional dan dapat memberikan fondasi
bagi sistem baru.
• Memaksa analis sistem untuk sepenuhnya memahami sistem. Ketika sistem baru
diterapkan, pengguna harus melalui proses konversi di mana mereka secara
formal
melepaskan diri dari sistem lama dan pindah ke yang baru.
• Mengisolasi akar gejala masalah. Dengan mensurvei sistem saat ini, analis
dapat menentukan secara meyakinkan penyebab gejala masalah yang dilaporkan.

Mengumpulkan Fakta
 Fakta sistem termasuk dalam kelas luas berikut.
• Sumber data. Ini termasuk entitas eksternal, seperti pelanggan atau vendor,
juga
sebagai sumber internal dari departemen lain.
• Pengguna. Ini termasuk manajer dan pengguna operasi.
• Menyimpan data. Menyimpan data adalah file, database, akun, dan dokumen
sumber
digunakan dalam sistem.
• Proses. Tugas pemrosesan adalah operasi manual atau komputer yang mewakili
keputusan atau tindakan yang dipicu oleh informasi.
• Aliran data. Aliran data diwakili oleh perpindahan dokumen dan laporan
antara sumber data, penyimpanan data, tugas pemrosesan, dan pengguna. Aliran
data juga bisa
direpresentasikan dalam diagram UML.
• Kontrol. Ini termasuk kontrol akuntansi dan operasional dan dapat berupa
prosedur manual atau kontrol komputer.
• Volume transaksi. Analis harus mendapatkan ukuran volume transaksi untuk
periode waktu tertentu. Banyak sistem diganti karena mereka telah mencapai
kapasitasnya
 Tingkat kesalahan. Kesalahan transaksi terkait erat dengan volume transaksi.
Ketika sistem mencapai kapasitas, tingkat kesalahan meningkat ke tingkat yang
tidak dapat ditoleransi
Biaya sumber daya. Sumber daya yang digunakan oleh sistem saat ini termasuk
biaya tenaga kerja,
waktu komputer, bahan (seperti faktur), dan overhead langsung
• Kemacetan dan operasi yang berlebihan. Analis harus mencatat titik di mana
data
Aliran datang bersama untuk membentuk hambatan

Teknik Pengumpulan Fakta

Pengamatan melibatkan secara pasif menonton prosedur fisik
sistem. Ini memungkinkan analis untuk menentukan apa yang akan dilakukan,
siapa yang melakukan tugas,
ketika mereka melakukannya, bagaimana mereka melakukannya, mengapa mereka
melakukannya, dan berapa lama mereka melakukannya
Partisipasi Tugas. Partisipasi adalah perpanjangan dari pengamatan, di mana
analis
mengambil peran aktif dalam melakukan pekerjaan pengguna. Ini memungkinkan
analis untuk mengalami
tangan pertama masalah yang terlibat dalam pengoperasian sistem saat ini
Wawancara Pribadi. Wawancara adalah metode mengekstraksi fakta tentang arus
persepsi sistem dan pengguna tentang persyaratan untuk sistem baru
• Pertanyaan terbuka memungkinkan pengguna untuk menguraikan masalah seperti
yang mereka lihat dan
menawarkan saran dan rekomendasi.
 Kuisioner digunakan untuk mengajukan pertanyaan yang lebih spesifik dan
terperinci dan untuk membatasi
tanggapan pengguna.
Meninjau Dokumen Kunci
• Bagan organisasi
• Deskripsi pekerjaan
• Catatan akuntansi
• Bagan akun
• Pernyataan kebijakan
• Deskripsi prosedur
• Laporan keuangan
• Laporan kinerja
• Diagram alir sistem
• Dokumen sumber
• Daftar transaksi
• Anggaran
• Prakiraan
• Pernyataan misi
Langkah Analisis
Analisis sistem adalah proses intelektual yang bercampur dengan pengumpulan
fakta. Itu
Analis secara bersamaan menganalisis ketika dia mengumpulkan fakta
Laporan Analisis Sistem
Peristiwa yang menandai akhir dari fase analisis sistem adalah persiapan a
laporan analisis sistem formal.
Peran Auditor dalam Analisis Sistem
Auditor perusahaan (baik eksternal maupun internal) adalah pemangku
kepentingan dalam sistem yang diusulkan
Sering,
fitur audit lanjutan tidak dapat dengan mudah ditambahkan ke sistem yang ada

Desain Sistem Konseptual — Fase III

Tujuan dari fase desain konseptual adalah untuk menghasilkan beberapa
alternatif konseptual
sistem yang memenuhi persyaratan sistem yang diidentifikasi selama analisis
sistem
Pengguna akan mengevaluasi ini
model konseptual dan tentukan alternatif yang tampak paling masuk akal dan
menarik. Desain alternatif ini kemudian menuju ke tahap pemilihan sistem SDLC,
di mana
biaya dan manfaatnya masing-masing dibandingkan dan dipilih satu desain
optimal.
Pendekatan Desain Terstruktur
Pendekatan desain terstruktur adalah cara disiplin merancang sistem dari atas
turun. Ini terdiri dari mulai dengan "gambaran besar" dari sistem yang
diusulkan yang secara bertahap didekomposisi menjadi lebih dan lebih detail
sampai sepenuhnya dipahami.
Desain harus mengidentifikasi semua input, output, proses, dan
fitur khusus yang diperlukan untuk membedakan satu alternatif dari yang lain
 Misalnya, mereka tidak memasukkan ini perlu
komponen:
• Struktur catatan basis data
• Memproses rincian
• Teknik kontrol khusus
• Format untuk layar input dan dokumen sumber
• Output format laporan

Pendekatan Berorientasi Objek

Pendekatan desain berorientasi objek (OOD) adalah untuk membangun sistem
informasi dari komponen atau objek standar yang dapat digunakan kembali.
Pendekatan ini dapat disamakan dengan proses
membangun mobil. Pabrikan mobil tidak membuat setiap model baru dari awal.
Peran Auditor dalam Desain Sistem Konseptual
Auditor adalah pemangku kepentingan dalam semua sistem keuangan dan, dengan
demikian, memiliki kepentingan dalam tahap desain konseptual sistem

Evaluasi dan Seleksi Sistem — Fase IV

Sistem
tahap evaluasi dan seleksi adalah proses optimisasi yang berupaya
mengidentifikasi
sistem terbaik. Keputusan ini merupakan titik kritis dalam SDLC.
Proses evaluasi dan seleksi melibatkan dua langkah:
1. Melakukan studi kelayakan terperinci
2. Melakukan analisis biaya-manfaat
Lakukan Studi Kelayakan Lengkap
Diskusi berikut menguraikan lima aspek kelayakan proyek yang perlu
dipertimbangkan. Setiap proyek yang bersaing akan dinilai dengan cara yang
sama.
Kelayakan teknis berkaitan dengan apakah sistem dapat
dikembangkan di bawah teknologi yang ada atau jika teknologi baru diperlukan
Kelayakan ekonomi berkaitan dengan ketersediaan dana untuk
selesaikan proyek.
Kelayakan hukum mengidentifikasi setiap konflik antara sistem konseptual dan
kemampuan perusahaan untuk melepaskan tanggung jawab hukumnya
Kelayakan operasional menunjukkan tingkat kompatibilitas antara prosedur yang
ada perusahaan dan keterampilan personil dan persyaratan operasional sistem
baru
Jadwal kelayakan berkaitan dengan kemampuan perusahaan untuk
mengimplementasikan
proyek dalam waktu yang dapat diterima

Lakukan Analisis Biaya-Manfaat

Identifikasi Biaya. Salah satu metode untuk mengidentifikasi biaya adalah
untuk membaginya menjadi dua kategori:
biaya satu kali dan biaya berulang.
• Akuisisi perangkat keras
• Persiapan lokasi
• Akuisisi perangkat lunak
• Desain sistem
• Pemrograman dan pengujian
• Konversi data.
• Pelatihan
Biaya berulang meliputi:
• Perawatan perangkat keras.
• Pemeliharaan perangkat lunak
• Asuransi.
• Persediaan
• Biaya personil

Identifikasi Manfaat
Manfaat nyata terbagi dalam dua kategori: yang meningkatkan pendapatan dan
yang
mengurangi biaya
Bandingkan Biaya dan Manfaat. Langkah terakhir dalam analisis biaya-manfaat
adalah membandingkan biaya dan manfaat yang diidentifikasi dalam dua langkah
pertama.
Menyiapkan Laporan Pemilihan Sistem
Produk yang dapat dikirim dari proses pemilihan sistem adalah laporan
pemilihan sistem
Peran Auditor dalam Evaluasi dan Seleksi
 auditor harus memastikan lima hal:
1. Hanya biaya yang dapat digunakan 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. Masa manfaat realistis digunakan dalam membandingkan proyek yang bersaing.
5. Manfaat tidak berwujud diberikan nilai keuangan yang wajar.

Desain Detail — Fase 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. Pada fase ini, semua komponen sistem
(pengguna
pandangan, tabel basis data, proses, dan kontrol) ditentukan dengan cermat.
Lakukan Panduan Desain Sistem
tim pengembangan biasanya melakukan penelusuran desain sistem untuk memastikan
bahwa desain bebas dari kesalahan konseptual yang bisa terjadi
diprogram ke dalam sistem final.

Tinjau Dokumentasi Sistem

• 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 relationship (ER) yang
menggambarkan
hubungan data dalam sistem, diagram konteks untuk keseluruhan sistem, data
tingkat rendah
diagram alir proses sistem tertentu, diagram struktur untuk modul program
dalam sistem — termasuk termasuk deskripsi pseudocode dari setiap modul.
• Kamus data terbaru yang menjelaskan setiap elemen data dalam database.
• Memproses logika (diagram alur)

Pemrograman dan Pengujian Aplikasi — Fase VI

Programkan Perangkat Lunak Aplikasi
Bahasa prosedural mengharuskan programmer untuk menentukan
urutan tepat di mana logika program dijalankan
Bahasa yang dikendalikan oleh acara tidak lagi bersifat prosedural. Dibawah
model ini, kode program tidak dieksekusi dalam urutan yang telah ditentukan.
Pusat untuk mencapai manfaat dari objek yang berorientasi
Pendekatan mengembangkan perangkat lunak dalam bahasa pemrograman berorientasi
objek (OOP)
Memprogram Sistem. Terlepas dari bahasa pemrograman yang digunakan, modern
program harus mengikuti pendekatan modular
1. Efisiensi pemrograman
2. Efisiensi pemeliharaan.
3. Kontrol.
Uji Perangkat Lunak Aplikasi
Metodologi Pengujian
Menguji Offline Sebelum Menyebarkan Online
Data Uji

Implementasi Sistem — Fase VI

Menguji Keseluruhan Sistem
Ketika semua modul telah dikodekan dan diuji, mereka harus disatukan dan diuji
secara keseluruhan. Personil pengguna harus mengarahkan pengujian di seluruh
sistem sebagai awal formal
implementasi sistem.
Mendokumentasikan Sistem
Dokumentasi sistem memberi auditor informasi penting tentang caranya
sistem bekerja
Dokumentasi Desainer dan Programmer
Dokumentasi Operator
• Nama sistem, seperti Sistem Pembelian
• Jadwal lari (harian, mingguan, waktu, dan sebagainya)
• Perangkat keras yang diperlukan (kaset, disk, printer, atau perangkat keras
khusus)
• Persyaratan file yang menentukan semua file transaksi (input), file master,
dan output
file yang digunakan dalam sistem
• Instruksi run-time yang menjelaskan pesan kesalahan yang mungkin muncul,
tindakan yang harus dilakukan
diambil, dan nama dan nomor telepon programmer yang dipanggil, harus
sistem gagal
• Daftar pengguna yang menerima output dari proses
Dokumentasi Pengguna
• Para pemula memiliki sedikit atau tanpa pengalaman dengan komputer dan malu
untuk bertanya
pertanyaan
• Pengguna sesekali pernah memahami sistem tetapi telah melupakan beberapa
perintah dan prosedur penting
• 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
• Pengguna listrik yang sering memahami sistem yang ada dan akan mudah
beradaptasi dengan yang baru
sistem
Buku Pegangan Pengguna
• Tinjauan umum sistem dan fungsi utamanya
• Instruksi untuk memulai
• Deskripsi prosedur dengan referensi visual langkah demi langkah
• Contoh layar input dan instruksi untuk memasukkan data
• Daftar lengkap kode dan deskripsi pesan kesalahan
• Manual referensi perintah untuk menjalankan sistem
• Glosari istilah-istilah utama
• Informasi layanan dan dukungan
 fitur termasuk tutorial dan fitur bantuan
Tutorial online
Fitur bantuan online

Mengkonversi Basis Data

Ini adalah transfer dari
data dari bentuk saat ini ke format atau media yang dibutuhkan oleh sistem
baru. Itu
tingkat konversi tergantung pada lompatan teknologi dari sistem lama ke yang
baru
satu
Tindakan pencegahan berikut
harus diambil:
1. Validasi.
2. Rekonsiliasi
3. Cadangan.
Konversi ke Sistem Baru
Di bawah pendekatan cutover kalkun dingin (juga disebut "Besar."
Bang "pendekatan), perusahaan beralih ke sistem baru dan secara bersamaan
mengakhiri
sistem lama. Ketika menerapkan sistem sederhana, ini seringkali yang paling
mudah dan paling murah
pendekatan
Cutover bertahap mulai mengoperasikan sistem baru dalam modul
operasi cutover paralel melibatkan menjalankan yang lama
sistem dan sistem baru secara bersamaan untuk suatu periode waktu
Peran Auditor dalam Implementasi Sistem
Berikan Keahlian Teknis. Fase desain terperinci melibatkan spesifikasi
prosedur, aturan, dan konvensi yang tepat untuk digunakan dalam sistem.
Tentukan Standar Dokumentasi. Dalam fase implementasi, auditor berperan
peran dalam menentukan dokumentasi sistem
Verifikasi Kecukupan Kontrol dan Kepatuhan dengan SOX. Aplikasi AIS itu
muncul dari SDLC harus memiliki kontrol yang memadai.
Ulasan Pasca Implementasi
Kecukupan Desain Sistem.
• Apakah keluaran dari sistem memiliki karakteristik informasi seperti
relevansi, ketepatan waktu, kelengkapan, keakuratan, dan sebagainya?
• Apakah output dalam format paling bermanfaat dan diinginkan oleh pengguna
(seperti tabel,
grafik, elektronik, hard copy, dan sebagainya)?
• Apakah basis data 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
pernah dilakukan pengguna
terjebak dalam satu lingkaran?
• Apakah dokumentasi pengguna akurat, lengkap, dan mudah diikuti?
• Apakah sistem memberikan bantuan dan tutorial yang memadai kepada pengguna?
Ketepatan Estimasi Waktu, Biaya, dan Manfaat.
• Apakah biaya aktual sesuai dengan biaya yang dianggarkan?
• Apa saja bidang keberangkatan signifikan dari anggaran?
• Apakah keberangkatan dari anggaran dapat dikontrol (internal) dalam jangka
pendek atau tidak terkendali (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-nilai yang diberikan untuk manfaat berwujud dan, terutama,
tidak berwujud akurat?

PENGENDALIAN DAN AUDIT SDLC

Mengontrol Pengembangan Sistem Baru
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 prosesnya
Aktivitas Spesifikasi Pengguna
Pengguna harus terlibat aktif dalam proses pengembangan sistem. Keterlibatan
mereka
jangan dihambat karena sistem yang diusulkan secara teknis rumit
Kegiatan Desain Teknis
Kegiatan desain teknis menerjemahkan spesifikasi pengguna ke dalam serangkaian
spesifikasi teknis terperinci dari sistem yang memenuhi kebutuhan pengguna
Partisipasi Audit Internal
Auditor internal memainkan peran penting dalam pengendalian kegiatan
pengembangan sistem, khususnya di organisasi yang penggunanya tidak memiliki
keahlian teknis
Tes Pengguna dan Prosedur Penerimaan
Tepat sebelum implementasi, modul individual dari sistem harus diuji sebagai:
a
kesatuan utuh
Tujuan Audit Terkait dengan Pengembangan Sistem Baru
• Pastikan kegiatan SDLC diterapkan secara konsisten dan sesuai dengan
kebijakan manajemen.
• Menentukan bahwa sistem yang semula diterapkan bebas dari kesalahan materi
dan penipuan.
• Konfirmasikan bahwa sistem dinilai perlu dan dibenarkan di berbagai pos
pemeriksaan di seluruh SDLC.
• Pastikan dokumentasi sistem cukup akurat dan lengkap untuk memfasilitasi
kegiatan audit dan pemeliharaan.
Prosedur Audit Terkait Pengembangan Sistem Baru
• Pengguna dan manajemen layanan komputer mengotorisasi proyek dengan
semestinya.
• Studi kelayakan awal menunjukkan bahwa proyek tersebut layak.
• Analisis terperinci tentang kebutuhan pengguna dilakukan yang menghasilkan
alternatif umum
desain.
• Analisis biaya-manfaat dilakukan dengan menggunakan angka yang cukup akurat.
• Dokumentasi proyek menunjukkan bahwa desain rinci sesuai dan
solusi 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 dikoreksi dalam fase pemeliharaan.
• Dokumentasi sistem sesuai dengan persyaratan dan standar organisasi

Pemeliharaan Sistem Kontrol

Otorisasi, Pengujian, dan Dokumentasi Pemeliharaan
Manfaat yang diperoleh dari mengendalikan pengembangan sistem baru dapat
dengan cepat hilang selama pemeliharaan sistem jika kontrol tidak berlanjut ke
fase itu.
Terlepas dari prosedur pemeliharaan sebelumnya, integritas aplikasi dapat
terancam oleh individu yang mendapatkan akses tidak sah ke program.
Situasi Kasus Terburuk: Tidak Ada Kontrol
1. Akses ke program sama sekali tidak dibatasi.
2. Karena kelemahan kontrol ini, program dapat berubah tanpa izin.
Lingkungan SPL Terkendali
Kontrol Kata Sandi. Menetapkan kata sandi menyediakan satu bentuk kontrol
akses atas
SPL.
Perpustakaan Uji terpisah
Jejak Audit dan Laporan Manajemen. Fitur penting dari manajemen SPL
perangkat lunak adalah pembuatan laporan yang meningkatkan kontrol manajemen
dan fungsi audit
Nomor Versi Program. SPLMS memberikan nomor versi secara otomatis ke
setiap program disimpan di SPL.
Mengontrol Akses ke Perintah Perawatan. Penggunaan sistem manajemen SPL
perintah pemeliharaan yang kuat untuk mengubah atau menghilangkan kata sandi
program, mengubah nomor versi program (modifikasi), dan sementara memodifikasi
program tanpa membuat catatan modifikasi

Tujuan Audit Terkait dengan Pemeliharaan Sistem

• Mendeteksi pemeliharaan program yang tidak sah (yang mungkin mengakibatkan
signifikan
memproses kesalahan atau penipuan). Menentukan bahwa (1) prosedur perawatan
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.
• Rekonsiliasi nomor versi program
• Konfirmasikan otorisasi pemeliharaan
Identifikasi Kesalahan Aplikasi.
• Rekonsiliasi kode sumber.
• Rekonsiliasi kode sumber.
• Uji ulang program

Uji Akses ke Perpustakaan. Keberadaan perpustakaan program yang aman adalah

pusat dari
mencegah kesalahan dan penipuan program.
• Tinjau tabel otoritas pemrogram
• Uji tabel otoritas