Audit Teknologi SI (Audit Proyek Perusahaan)
Audit Teknologi Sistem Informasi
Audit Proyek Perusahaan
(Auditing Company Projects)
Disusun Oleh :
Kelompok 11 :
1. Ardy Rizaldy (11114510)
2. Nuke Maynika (18114114)
3. Sapto Prasetyo (1A114015)
Kelas : 4KA09
Dosen : Priyo Sarjono Wibowo
UNIVERSITAS GUNADARMA
SISTEM INFORMASI
PTA 2017/2018
Audit Proyek Perusahaan
Pendahuluan
Berikut ini akan dibahas hal-hal yang harus dicari pada saat mengaudit proses-proses pengelolaan proyek perusahaan, termasuk memahami hal-hal berikut yang berkaitan dengan manajemen proyek audit teknologi informasi:
• Kunci keberhasilan manajemen proyek
• Kebutuhan pengumpulan dan desain awal
• Perancangan dan pengembangan sistem
• Pengujian
• Implementasi
• Pelatihan
• Wrap up proyek
Sebelum sistem atau proses dapat diimplementasikan, sebuah proyek harus didanai dan dikelola terlebih dahulu untuk dapat dikembangkan atau mendapatkan sistem atau proses tersebut. Jika disiplin yang benar tidak diberlakukan selama proyek berlangsung, kemungkinan kegagalan dalam memenuhi persyaratan dan atau penggunaan aset perusahaan yang tidak efisien sangat meningkat.
Latar belakang
Teknik manajemen proyek yang tepat merupakan elemen penting dalam keberhasilan usaha perusahaan. Teknik-teknik ini membantu memastikan bahwa persyaratan terkait dikumpulkan dan diuji, sumber daya proyek digunakan secara efisien, dan semua elemen sistem diuji dengan benar. Tanpa teknik seperti itu, kemungkinan sistemnya yang dikembangkan tidak akan berfungsi atau tidak akan berjalan seperti yang diharapkan oleh pemangku kepentingan utama. Hal ini menyebabkan pengerjaan ulang dan biaya tambahan bagi perusahaan (dan terkadang dapat menyebabkan orang kehilangan pekerjaan mereka). Manajemen proyek yang baik tidak menjamin kesuksesan, namun meningkatkan peluang keberhasilan.
Maksud dari penulisan ini adalah menyediakan daftar risiko dasar yang harus ditinjau saat mengaudit proyek sistem untuk memastikan bahwa disiplin manajemen proyek yang paling penting sedang diikuti.
Tujuan
Tingkat Tinggi Audit Proyek Audit proyek dilakukan untuk mengidentifikasi risiko terhadap keberhasilan proyek perusahaan. Di sini membahas secara khusus proyek TI (seperti pengembangan perangkat lunak, penyebaran infrastruktur, dan penerapan aplikasi bisnis), namun konsep tersebut dapat diterapkan pada proyek apa pun.
Berikut adalah beberapa tujuan tingkat tinggi dari audit proyek:
• Memastikan bahwa semua pemangku kepentingan terkait terlibat dalam pengembangan persyaratan dan pengujian sistem dan komunikasi yang sering dan efektif terjadi dengan semua pemangku kepentingan. Kegagalan untuk mengumpulkan persyaratan pelanggan dan untuk mendapatkan keterlibatan pelanggan yang berkelanjutan dan pembelian mengarah pada perangkat lunak, sistem, dan proses yang sedang dikembangkan atau dibeli yang tidak sesuai dengan kebutuhan bisnis.
• Memastikan bahwa masalah proyek, anggaran, tonggak sejarah, dan sebagainya, dicatat, diputuskan, dan dilacak. Tanpa mekanisme ini, proyek lebih cenderung membahas anggaran dan jadwal dengan masalah yang belum terselesaikan.
• Pastikan pengujian yang efektif mencakup semua persyaratan sistem. Pengujian yang tidak memadai menyebabkan sistem yang tidak stabil dan bermutu rendah yang gagal memenuhi kebutuhan pelanggan.
• Pastikan dokumentasi yang tepat dikembangkan dan dipelihara. Dokumentasi teknis dan pengguna yang tidak lengkap atau ketinggalan zaman dapat meningkatkan waktu biaya dan siklus untuk mempertahankan perangkat lunak, meningkatkan biaya dukungan dan pelatihan, dan membatasi kegunaan sistem kepada pelanggan.
• Pastikan bahwa pelatihan yang memadai diberikan kepada pengguna akhir pada saat pelaksanaan. Pelatihan yang tidak memadai mengarah pada sistem, proses, dan perangkat lunak yang tidak terpakai atau digunakan dengan tidak semestinya.
Pendekatan Dasar untuk Audit Proyek
Dua pendekatan dasar dapat dilakukan dengan audit proyek. Pendekatan pertama adalah pendekatan cepat dan singkat. Pendekatan kedua mengambil pandangan jangka panjang dari proyek ini dan sebuah pendekatan yang lebih konsisten.
Pendekatan jangka pendek bisa menjadi tantangan; auditor memilih satu titik dalam proyek untuk melakukan audit mereka, dan kemudian mereka meninjau proyek tersebut pada saat itu dan membuat keputusan berdasarkan apa yang telah terjadi dan apa yang direncanakan. Pendekatan ini memiliki dua kekurangan utama.
Pertama, sulit bagi auditor untuk mempengaruhi fase yang telah selesai. Misalnya, tahap pengujian penerimaan pengguna adalah saat yang buruk untuk mengetahui bahwa proses yang kurang terkontrol digunakan selama fase definisi proyek. Tim proyek harus meninjau kembali dan mengolah ulang untuk memperbaiki tugas sebelumnya atau melangkah maju, mengetahui bahwa ada masalah dan berharap mendapatkan yang terbaik. Either way, masukan auditor tidak terlalu tepat waktu dan bahkan dapat dilihat sebagai hubungan kontraproduktif dan merusak antara auditor dan pelanggannya.
Kedua, tahap evaluasi sepenuhnya yang belum dimulai sulit dilakukan. Auditor mungkin dapat meninjau rencana pengujian penerimaan pengguna pada awal proyek, misalnya, namun sampai rencana tersebut dikembangkan sepenuhnya dan dijalankan, auditor akan merasa sulit untuk mengevaluasi keefektifan sebenarnya mereka.
Keterlibatan jangka panjang, atau keterlibatan yang konsisten, memungkinkan auditor untuk melakukan beberapa kegiatan penilaian selama setiap tahap utama proyek. Setiap audit mengevaluasi proses dalam fase saat ini sambil menilai dan memberikan masukan pada rencana untuk fase yang akan datang. Ini adalah cara efektif untuk mengaudit proyek dan mengarah pada pendekatan kolaboratif dengan pelanggan audit.
Di sisi negatif, pendekatan ini membentang di luar audit dalam jangka waktu yang panjang dan sulit untuk dijadwal. Namun, memiliki hal positif jauh lebih banyak daripada yang negatif.
Jika proyek ini mencakup periode waktu yang sangat lama, auditor mungkin mempertimbangkan salah satu dari dua pendekatan berikut:
• Melepaskan laporan audit interim setelah setiap tahap proyek utama sehingga informasi dalam laporan tidak menjadi terlalu basi.
• Bertemu dengan manajer proyek untuk mendiskusikan masalah secara reguler (seperti setiap dua minggu). Pada pertemuan ini, auditor dapat mengkomunikasikan risiko baru terhadap proyek yang ditemukan sejak pertemuan terakhir dan juga menindaklanjuti status isu-isu sebelumnya untuk menentukan apakah remediasi telah selesai. Jika, menurut pendapat auditor, risiko proyek meningkat ke tingkat yang tidak memuaskan, atau jika masalah tidak diatasi, auditor dapat meningkat ke tingkat manajemen yang lebih tinggi atas kebijaksanaan mereka sendiri. Auditor harus memiliki hak untuk mengeluarkan laporan audit secara skala penuh setiap saat, namun dengan mencoba bekerja sama dengan manajer proyek terlebih dahulu, masalah akan dipecahkan tanpa eskalasi dan tanpa dikeluarkannya laporan audit sementara.
Tujuh Bagian Utama Proyek Audit
Proyek dapat dipisahkan menjadi tujuh bagian utama, masing-masing memerlukan disiplin dan kontrol yang akan kita evaluasi selama audit proyek. :
1. Keseluruhan manajemen proyek.
Mekanisme yang harus digunakan sepanjang proyek, seperti pelacakan isu, dokumentasi proyek, dan manajemen perubahan.
2. Permulaan proyek, pengumpulan kebutuhan, dan desain awal.
Meliputi permulaan proyek: di mana kebutuhan akan proyek ditetapkan, persyaratan dikumpulkan, dan desain awal dan studi kelayakan dilakukan.
3. Desain dan pengembangan sistem.
Meliputi "isi" proyek: di mana kode ditulis, produk dibeli atau diimplementasikan, prosesnya dikembangkan, dan seterusnya.
4. Pengujian.
Sistem, perangkat lunak, atau proses diuji untuk memastikan memenuhi persyaratan.
5. Implementasi.
Sistem, perangkat lunak, atau proses diimplementasikan atau dipasang ke lingkungan produksi.
6. Pelatihan.
Meliputi kegiatan untuk melatih pengguna akhir dalam menggunakan sistem, perangkat lunak, atau proses yang telah dikembangkan dan diimplementasikan.
7. Wrap-up proyek.
Meliputi kegiatan pasca-implementasi.
Unsur-unsur proyek ini tidak harus dilakukan dalam urutan yang tepat, dan juga tidak akan dilakukan secara berurutan. Beberapa iterasi setiap fase mungkin ada, dan beberapa mungkin dilakukan sejajar satu sama lain (misalnya, pelatihan pengguna sering dilakukan bersamaan dengan pengujian dan implementasi). Namun, hampir setiap proyek harus memiliki beberapa dari masing-masing elemen ini.
Bagian selanjutnya dari bab ini akan berfokus pada langkah-langkah audit utama dan tes untuk dilakukan berkenaan dengan tujuh kategori ini.
Langkah-langkah Uji untuk mengaudit Proyek Perusahaan
Untuk menyediakan beberapa konteks dan struktur, langkah-langkah uji di bagian ini disediakan sesuai dengan tahap proyek. Namun, langkah-langkahnya tidak selalu berjalan semulus apa yang telah ditata; setiap proses memiliki situasi dan persyaratan yang unik untuk dipertimbangkan. Misalnya, waktu untuk mengatasi langkah dari bagian pengujian mungkin terjadi selama fase pengumpulan-permintaan.
Anda harus melakukan setiap langkah pada titik di proyek yang paling masuk akal, berdasarkan bagaimana proyek dijalankan.Sangat penting bagi auditor untuk memahami metodologi proyek dan menyesuaikan pendekatannya dengan tepat. Misalnya, jika proyek menggunakan pengembangan inkremental, di mana setiap fase proyek dieksekusi berkali-kali, Anda mungkin perlu mengaudit setiap fase secara bersamaan atau bahkan mungkin berkali-kali.
Kontrol yang diperlukan untuk sebuah proyek umumnya akan sama terlepas dari metodologi proyek, namun sesuai dengan fase audit terhadap proyek dan mengkoordinasikan waktunya akan lebih sulit untuk beberapa jenis proyek daripada proyek lainnya. Bagian dari proses perencanaan harus melibatkan pemahaman metodologi proyek yang digunakan dan menentukan waktu dan metode yang tepat untuk menyelesaikan langkah-langkah dalam program ini.
Saat merencanakan audit, Anda harus menentukan alat manajemen proyek apa yang digunakan oleh tim proyek dan menjadi terbiasa dengan alat dan terminologinya. Ini akan memungkinkan Anda untuk "berbicara bahasa yang sama" sebagai orang yang Anda audit dan selanjutnya meningkatkan kredibilitas. Selain itu, beberapa langkah ini mungkin berlebihan untuk proyek yang lebih kecil. Anda harus menggunakan penilaian dalam menentukan risiko mana yang cukup material untuk ditangani untuk setiap proyek tertentu.
Akhirnya, langkah-langkah ini ditulis sehingga bisa digunakan untuk proyek TI apa pun, apakah melibatkan perolehan atau pengembangan perangkat lunak, pengadaan teknologi baru, atau pengembangan proses. Gunakan penilaian Anda untuk menentukan langkah mana yang paling sesuai dengan jenis proyek yang diaudit.
Keseluruhan Manajemen Proyek
Langkah-langkah dalam bagian ini biasanya harus dilakukan secara menyeluruh pada awal proyek dan sekali lagi ringan selama setiap tahap proyek untuk memastikan bahwa disiplin ilmu masih diikuti. Manajemen proyek mungkin mulai kuat, tapi sering kali berkurang saat orang menjadi sibuk dan berjuang untuk memenuhi tenggat waktu.
1. Pastikan dokumentasi proyek dan dokumentasi pengembangan perangkat lunak yang memadai (jika ada) telah dibuat. Pastikan standar metodologi proyek perusahaan diikuti. Dokumentasi semacam ini akan meningkatkan kemungkinan bahwa proyek tersebut dilaksanakan secara disiplin dan mengikuti standar dan metodologi yang ditetapkan perusahaan Anda. Hal ini, pada gilirannya, sangat meningkatkan kemungkinan bahwa proyek akan berhasil dilaksanakan dan akan menghasilkan nilai bisnis yang diinginkan. Dokumentasi ini juga dapat menguntungkan proyek-proyek masa depan, yang memungkinkan perusahaan memanfaatkan usaha masa lalu. Akhirnya, perusahaan Anda mungkin memiliki standar khusus untuk melaksanakan proyek berbasis, baik dalam persyaratan internal maupun peraturan.
Bagaimana caranya? Tinjau salinan dokumentasi proyek yang ada dan membandingkannya dengan standar dan persyaratan perusahaan Anda. Dokumen yang dibutuhkan akan bervariasi oleh perusahaan, namun mencari dokumen yang mencakup area seperti tonggak, struktur rincian pekerjaan (work breakdown structure / WBS), pendekatan proyek, pernyataan kerja (SOW), persyaratan, rencana uji, dan dokumen desain. Dapatkan salinan standar metodologi proyek perusahaan Anda dan bandingkan dengan metodologi yang sedang dijalankan pada proyek yang sedang ditinjau. Saat meninjau dokumentasi ini, carilah bukti perencanaan proyek dan sumber daya yang memadai. Melakukan langkah ini bukanlah ilmu pasti; Anda mencoba mengembangkan nuansa untuk keseluruhan tingkat dokumentasi dan proses yang ditetapkan untuk proyek ini. Beberapa dokumentasi ini akan diperiksa secara lebih rinci pada langkah selanjutnya. Dalam langkah ini, auditor harus memperoleh dokumen yang merupakan rencana proyek dasar dan menentukan apakah kebutuhan, kiriman, sasaran, dan cakupan pelanggan didefinisikan secara jelas.
2. Tinjau prosedur untuk memastikan bahwa dokumentasi proyek selalu diperbarui. Untuk alasan yang disebutkan di langkah sebelumnya, dokumentasi ini meningkatkan kualitas proyek saat ini dan masa depan. Namun, jika dibiarkan menjadi usang, dengan cepat menjadi tidak berguna.
Bagaimana caranya? Lakukan wawancara dengan tim proyek, pahami proses yang ada untuk memperbarui dokumen-dokumen ini bila diperlukan. Carilah bukti bahwa pembaruan telah dilakukan.
3. Evaluasi proses manajemen keamanan dan perubahan untuk dokumentasi proyek kritis. Jika kontrol keamanan dan perubahan yang benar tidak dilakukan, perubahan yang tidak sah, tidak akurat, dan / atau tidak perlu dapat dilakukan pada dokumentasi proyek.
Bagaimana caranya? Pastikan bahwa file yang berisi dokumentasi proyek dikunci dan dapat dimodifikasi hanya oleh subkumpulan personil proyek yang sesuai (menggunakan teknik yang dijelaskan pada Bab 6 untuk file Windows dan Bab 7 untuk file Unix atau Linux). Wawancara personil proyek untuk memahami proses perubahan dokumen proyek kritis. Pastikan proses persetujuan diperlukan sebelum perubahan dilakukan terhadap dokumen proyek yang signifikan dan bahwa proses persetujuan tidak dapat dielakkan. Dokumen-dokumen yang merupakan rencana proyek dasar (seperti kebutuhan pelanggan, kiriman, sasaran, cakupan, anggaran, risiko, dan strategi komunikasi) harus dimulai pada awal proyek sehingga tidak dapat diubah tanpa persetujuan dari semua pemangku kepentingan utama.
4. Mengevaluasi prosedur untuk memback up perangkat lunak dan dokumentasi proyek kritis. Pastikan bahwa backup disimpan di luar lokasi dan prosedur terdokumentasi ada untuk pemulihan. Jika proses ini tidak berjalan, sistem crash atau bencana data center dapat mengakibatkan hilangnya permanen perangkat lunak dan dokumentasi proyek.
Bagaimana caranya? Review proses atau skrip yang menunjukkan bahwa data proyek dicadangkan dan disimpan di luar kantor. Tinjau prosedur pemulihan tertulis, pastikan mereka menentukan langkah-langkah apa yang harus dilakukan untuk pemulihan, urutan langkah-langkah tersebut, dan siapa yang harus melakukan setiap langkahnya. Perhatikan bahwa prosedur pemulihan tertulis ini mungkin tidak dibuat dan unik untuk proyek tertentu. Mereka mungkin malah menjadi bagian dari prosedur pemulihan standar tim TI untuk file yang hilang. Pertimbangkan untuk meminta pemulihan uji materi proyek kritis.
5. Pastikan proses yang efektif ada untuk menangkap isu-isu proyek, meningkatkan isu-isu tersebut sebagaimana mestinya, dan melacaknya sesuai resolusi. Selama proyek apapun, masalah pasti akan timbul mengenai proyek itu sendiri atau sistem, proses, atau perangkat lunak yang sedang dikembangkan. Tanpa metode yang kuat untuk menangkap dan menyelesaikan masalah tersebut, beberapa masalah kemungkinan akan "lolos dari celah" dan tidak dapat diselesaikan, yang mengakibatkan kegagalan dalam produk atau kegagalan dalam pelaksanaan proyek.
Bagaimana caranya? Tinjau ulang masalah database, spreadsheet, atau metode lain yang ada untuk mencatat dan melacak masalah. Pastikan alat pelacak masalah mencatat informasi yang memadai mengenai setiap masalah, termasuk deskripsi masalah, tingkat prioritas, tanggal jatuh tempo, status terbaru, dan informasi resolusi. Pastikan kontrol ada di atas alat yang digunakan untuk melacak masalah, seperti backup dan keamanan untuk mencegah pembaruan yang tidak sah. Tinjau ulang proses untuk mengatasi masalah dan untuk memastikan bahwa isu dilacak ke resolusi. Tinjau daftar masalah untuk bukti bahwa masalah sedang ditutup. Wawancara pelanggan untuk memastikan prosesnya berjalan.
6. Pastikan ada proses yang efektif untuk menangkap permintaan perubahan proyek, memprioritaskan, dan memposisikannya. Selama sebagian besar proyek, permintaan untuk fungsi tambahan akan muncul setelah proyek dimulai dan persyaratan telah ditetapkan dan disetujui. Tanpa metode untuk memastikan bahwa permintaan ini diprioritaskan dan diposisikan, permintaan ini mungkin akan hilang, dan / atau ruang lingkup proyek akan terus bergeser, sehingga tidak mungkin melaksanakan proyek secara efektif. Proses permintaan perubahan akan membantu mencegah creep lingkup dan menyediakan diskusi yang sedang berlangsung dengan pelanggan proyek mengenai bagaimana perubahan permintaan akan berdampak pada anggaran dan jadwal proyek.
Bagaimana caranya? Kaji ulang proses manajemen perubahan dan memastikan bahwa ia menyediakan penyisihan untuk memasukkan, memberi peringkat, dan menyetujui permintaan perubahan. Verifikasi bahwa hal itu mencakup perubahan pada lingkup, jadwal, anggaran, persyaratan, desain, dan sebagainya (yaitu, semua elemen utama proyek). Pastikan informasi tersebut mencatat informasi yang memadai mengenai setiap permintaan perubahan, termasuk deskripsi permintaan, tingkat prioritas, status terbaru, persetujuan, dan informasi resolusi. Pilih contoh permintaan perubahan, dan jalanilah mereka melalui proses tersebut, pastikan persetujuan yang benar telah diterima sebelum resolusi akhir.
7. Pastikan jadwal proyek telah dibuat dan berisi detail yang cukup berdasarkan ukuran proyek. Pastikan bahwa ada proses untuk memantau kemajuan dan melaporkan penundaan yang signifikan. Jadwal proyek digunakan untuk memastikan bahwa proyek berjalan dengan baik, sumber daya digunakan secara efektif, dan semua tugas telah dicatat dan dijadwalkan.
Bagaimana caranya? Tinjau jadwal proyek, dan mencari item seperti rincian pekerjaan, tanggal tonggak, dependensi tugas, dan jalur kritis. Carilah bukti bahwa jadwal diikuti dan selalu up-to-date. Carilah penjelasan untuk delta yang signifikan. Pastikan bahwa prosedur eskalasi ada untuk jadwal yang signifikan atau overruns sumber daya, dan tinjau kembali bukti bahwa proses tersebut telah digunakan. Salah satu cara potensial untuk memastikan pemenuhan jadwal adalah membuat titik strategis dalam siklus hidup dimana proyek melewati proses "pintu gerbang". Pada titik-titik ini, tim proyek melapor ke panel tinjauan untuk menyampaikan status proyek , keberhasilan dan isu, dan kemajuan dibandingkan jadwal dan anggaran. Ini membantu mengidentifikasi perjuangan dan kegagalan dengan cepat saat terjadi.
8. Pastikan bahwa ada metode untuk melacak biaya proyek dan melaporkan overruns. Pastikan semua biaya proyek, termasuk tenaga kerja, dipertimbangkan dan dilacak. Tanpa mekanisme ini, anggaran proyek seringkali dapat terlampaui, dan seringkali tingkat pengelolaan yang sesuai tidak diketahui masalah ini. Manajemen mungkin telah menempatkan topi pada pendanaan untuk proyek tertentu. Jika semua biaya yang relevan tidak dilacak, manajemen tidak akan mengetahui jika batas tersebut telah terlampaui dan oleh karena itu, tidak dapat mengambil keputusan mengenai bagaimana melanjutkan.
Bagaimana caranya? Dapatkan salinan anggaran, dan membandingkannya dengan biaya sampai saat ini. Carilah penjelasan untuk delta yang signifikan. Pastikan anggaran mencakup semua biaya yang terkait dengan proyek, termasuk tenaga kerja, perangkat lunak, dan perangkat keras. Pastikan prosedur eskalasi ada untuk overruns biaya yang signifikan, dan meninjau bukti bahwa proses telah digunakan.
9. Evaluasi struktur kepemimpinan proyek untuk memastikan bahwa bisnis dan TI diwakili secara memadai. Kecuali untuk beberapa proyek infrastruktur murni, sebagian besar proyek dilakukan sesuai permintaan bisnis untuk memenuhi kebutuhan bisnis. Jika pemangku kepentingan bisnis utama bukan bagian dari struktur kepemimpinan dan persetujuan keseluruhan untuk proyek ini, kemungkinan proyek tersebut tidak dapat dilacak dari kebutuhan bisnis, karena informasi dan keputusan tentang proyek akan ditangani oleh orang-orang TI, yang mungkin tidak memiliki perspektif yang diperlukan untuk membuat semua keputusan. Ingatlah bahwa TI ada untuk mendukung bisnis, dan karena itu organisasi TI seharusnya tidak membuat keputusan mengenai kebutuhan TI bisnis dalam ruang hampa. Sebaliknya, personel IT juga harus menjadi bagian dari struktur, karena pada umumnya mereka membawa pengetahuan dan perspektif penting mengenai unsur-unsur kesuksesan proyek yang berhubungan dengan TI. Mereka dapat membantu memastikan bahwa sistem dirancang dengan cara yang efektif yang memungkinkan dukungan jangka panjang. Sistem yang dikembangkan tanpa keterlibatan TI jauh lebih mungkin memiliki masalah dengan skalabilitas, interoperabilitas, dan dukungan. Mereka juga lebih cenderung mengalami masalah penyebaran, yang mengakibatkan dampak negatif pada jadwal proyek.
Bagaimana caranya? Dapatkan salinan struktur kepemimpinan proyek, dan mencari bukti bahwa pemimpin bisnis dan TI dan pemangku kepentingan diwakili.
Project Start-up: Persyaratan Gathering dan Initial Design
10. Pastikan proses persetujuan proyek yang tepat diikuti sebelum inisiasi proyek. Proyek tidak boleh dimulai tanpa persetujuan dari anggota manajemen yang tepat yang berwenang untuk mengalokasikan sumber daya dan dana ke proyek baru.
Bagaimana caranya? Kaji ulang bukti bahwa proyek tersebut melewati proses persetujuan standar perusahaan. Jika tidak ada proses seperti itu, tinjau bukti bahwa manajer yang tepat menyetujui proyek sebelum memulai. Carilah bukti bahwa analisis alternatif dan biaya-manfaat dilakukan. Pastikan analisis biaya-manfaat tidak hanya mempertimbangkan biaya start-up proyek tetapi juga biaya yang terus berlanjut, seperti pemeliharaan perangkat lunak, perawatan perangkat keras, biaya dukungan (tenaga kerja), persyaratan daya dan pendinginan untuk perangkat keras sistem, dan faktor lainnya. Unsur ini sering dihilangkan secara keliru, yang menyebabkan keputusan salah informasi. Biaya awal hanya sebagian kecil dari total biaya yang dikeluarkan untuk menerapkan sistem baru. Multiyears (lima tahun sering menjadi target yang baik) model biaya total harus dikembangkan sebagai bagian dari analisis awal proyek.
11. Pastikan bahwa analisis kelayakan teknis telah dilakukan bersamaan dengan, jika ada, sebuah analisis kelayakan oleh departemen hukum perusahaan. Sebelum memulai proyek TI, arsitek teknis yang berkualitas, personil jaringan, administrator database, dan pakar IT lainnya harus setuju bahwa konsep yang diajukan akan sesuai dengan lingkungan perusahaan. Jika para ahli ini dibawa awal, kemungkinan profesional teknis dapat menemukan cara untuk membuat konsep tersebut berjalan. Namun, jika dibawa setelah elemen kunci dari sistem telah dikembangkan atau dibeli, mungkin ditentukan bahwa solusinya tidak layak secara teknis, menyebabkan pengerjaan ulang atau penghentian proyek yang mahal. Demikian juga, penting untuk melibatkan tim hukum untuk memastikan bahwa persyaratan peraturan dipertimbangkan dalam proyek.
Bagaimana caranya? Tinjau ulang bukti bahwa personil teknis dan hukum yang sesuai terlibat dalam proposal proyek awal dan mereka menyetujui kelayakan proyek tersebut.
12. Tinjau dan mengevaluasi dokumen persyaratan. Tentukan apakah dan bagaimana persyaratan pelanggan untuk proyek diperoleh dan didokumentasikan sebelum pembangunan berlangsung. Pastikan pelanggan menandatangani persyaratan dan persyaratan mencakup elemen standar TI. Sistem, perangkat lunak, dan proses harus dibangun berdasarkan persyaratan pengguna akhir. Jika persyaratan pengguna akhir tidak ditangkap dan disetujui oleh pelanggan, produk tersebut kemungkinan tidak akan memenuhi kebutuhan pelanggan, memerlukan pengerjaan ulang dan perubahan. Selain itu, elemen standar TI tertentu harus disertakan dalam definisi persyaratan sistem apapun. Pelanggan mungkin tidak menyadari unsur-unsur ini dan oleh karena itu memerlukan bimbingan dari tim TI. Menetapkan persyaratan yang didefinisikan dengan jelas juga akan membantu dalam diskusi di jalan mengenai apa yang diperbaiki bug (yaitu saat sistem tidak berfungsi sebagaimana mestinya) dan apakah permintaan peningkatan (yaitu, ketika sistem berfungsi seperti yang dirancang namun pelanggan ingin melakukan perubahan), yang bisa menjadi perbedaan penting tergantung pada model dukungan dan pendanaan organisasi TI Anda.
Bagaimana caranya? Tinjau dokumentasi proyek untuk bukti bahwa persyaratan pelanggan dikumpulkan. Pastikan semua pemangku kepentingan utama, termasuk sponsor proyek, terlibat dalam proses ini. Carilah bukti bahwa pemangku kepentingan utama menyetujui daftar persyaratan akhir. Tinjau persyaratan pelanggan untuk memastikan bahwa mereka mendokumentasikan persyaratan bisnis dan tidak mendikte solusi. Seringkali, pemimpin bisnis akan berbicara kepada vendor atau membaca artikel dan memutuskan untuk membuat sebuah proyek dengan tujuan menerapkan produk atau teknologi tertentu. Namun, produk tertentu itu mungkin bukan yang paling banyak cocok untuk situasi perusahaan Anda. Misalnya, mungkin tidak sepenuhnya memenuhi kebutuhan bisnis, namun mungkin berlebihan dengan produk lain yang saat ini digunakan di lingkungan, atau mungkin tidak terlalu sesuai dengan teknologi perusahaan yang ada. Sangat penting bahwa fokus pelanggan pada menentukan dan mendokumentasikan persyaratan bisnis dan memungkinkan organisasi TI fleksibilitas untuk menentukan alat apa yang paling sesuai dengan persyaratan tersebut.
Pastikan persyaratan mencakup elemen TI standar seperti berikut ini:
Persyaratan pemrosesan terdistribusi dan tersentralisasi (misalnya, lokasi penyimpanan dan pemrosesan dalam arsitektur multitier)
|
Perjanjian tingkat layanan (misalnya, ketersediaan sistem, kecepatan respons terhadap masalah)
|
Waktu respon (untuk transaksi online)
|
Persyaratan antarmuka
|
Keamanan
|
Persyaratan Backup/ Restart/Recovery
|
Frekuensi eksekusi
|
Restorasi Kebutuhan perangkat keras
|
Persyaratan penyimpanan data
|
Kapasitas, termasuk kebutuhan untuk pertumbuhan yang diantisipasi di masa depan
|
Persyaratan untuk keluaran distribusi
|
Toleransi kesalahan dan redundansi
|
Definisi layar
|
Jika proyek ini dimaksudkan untuk mengganti sistem yang ada, cari bukti bahwa analisis sistem saat ini dilakukan untuk menentukan apa yang bekerja dengan baik dan mana yang tidak. Juga, carilah bukti bahwa sistem yang ada telah dianalisis dengan seksama dan semua kasus penggunaan (fungsi) yang ada yang dipenuhi dipenuhi dengan sistem yang baru. Hasil analisis ini harus tercermin dalam dokumentasi persyaratan. Kesalahan log dan permintaan backlog dari sistem lama dapat membantu dalam upaya menentukan apa yang sebenarnya tidak bekerja dengan baik
13. Evaluasi proses untuk memastikan bahwa semua kelompok yang terkena dampak yang akan membantu mendukung sistem, perangkat lunak, atau proses terlibat dalam proyek dan akan menjadi bagian dari penandatanganan proses, menunjukkan kesiapan mereka untuk mendukungnya. Beberapa organisasi di lingkungan TI biasanya terlibat dalam mendukung sistem baru, termasuk dukungan jaringan, dukungan sistem operasi, dukungan basis data, personil pusat data, keamanan TI, dan meja bantuan. Jika organisasi-organisasi ini tidak terlibat dalam proyek sejak awal, mereka mungkin tidak siap untuk mendukung sistem setelah sistem siap, dan / atau sistem mungkin tidak sesuai dengan standar dan kebijakan yang berlaku.
Bagaimana caranya? Tinjau kembali bukti bahwa organisasi TI yang terkena dampak telah diberitahu tentang proyek tersebut dan merupakan bagian dari proses persetujuan (yang berkaitan dengan kesiapan mereka untuk mendukungnya).
14. Tinjau kembali proses penetapan prioritas persyaratan. Seringkali, lebih banyak persyaratan sistem ada daripada yang dapat tercakup dalam proyek (atau setidaknya pada tahap awal proyek). Persyaratan yang paling penting harus diidentifikasi, diprioritaskan, dan diterapkan.
Bagaimana caranya? Cari bukti bahwa persyaratan diprioritaskan dan pemegang saham utama menyetujui prioritasnya.
15. Tentukan apakah persyaratan sistem dan desain awal memastikan bahwa elemen pengendalian internal dan keamanan yang tepat akan dirancang ke dalam sistem, proses, atau perangkat lunak. Kontrol internal diperlukan untuk melindungi sistem perusahaan dan memastikan integritas mereka. Jauh lebih mudah membangun kontrol ke sistem baru di depan daripada mencoba menambahkannya pasca implementasi.
Bagaimana caranya? Auditor perlu menentukan jenis kontrol apa yang akan dia audit sistem untuk penerapan di masa depan dan memastikan bahwa kontrol tersebut dirancang ke dalam sistem. Kontrol aplikasi dan kontrol infrastruktur yang tepat harus dipertimbangkan. Selain itu, mungkin tepat untuk menetapkan auditor keuangan / operasional ke proyek tersebut untuk memastikan bahwa pengendalian bisnis yang tepat dibangun ke dalam logika sistem dan alur kerja.
16. Jika proyek melibatkan pembelian perangkat lunak, teknologi, atau layanan eksternal lainnya, tinjau dan evaluasi proses seleksi vendor dan kontrak terkait. Membeli produk dari vendor luar biasanya merupakan investasi yang signifikan dan merupakan komitmen terhadap produk vendor itu. Jika proses pemilihan vendor tidak memadai atau kontrak tidak memberi perusahaan perlindungan yang memadai, hal itu dapat menyebabkan pembelian produk yang tidak memenuhi persyaratan proyek dan kurangnya jalur hukum.
Bagaimana caranya? Tinjau proses seleksi vendor untuk elemen seperti ini:
• Pastikan produk dari beberapa vendor dievaluasi mengenai kemampuan mereka untuk memenuhi semua persyaratan proyek dan kompatibilitasnya dengan lingkungan TI perusahaan. Ini tidak hanya membantu Anda memilih produk terbaik untuk kebutuhan Anda, namun penawarannya kompetitif dan harga yang lebih rendah.
• Pastikan analisis biaya telah dilakukan pada produk yang sedang dievaluasi. Analisis ini harus mencakup semua biaya yang relevan, termasuk biaya produk, biaya startup satu kali, biaya perangkat keras, biaya perizinan, dan biaya perawatan.
• Menentukan apakah stabilitas keuangan vendor diselidiki sebagai bagian dari proses evaluasi. Kegagalan untuk melakukannya dapat mengakibatkan perusahaan Anda mendaftar dengan vendor yang gulung tikar, menyebabkan gangguan yang signifikan pada operasi Anda saat Anda mencoba memindahkannya ke vendor lain.
• Tentukan apakah pengalaman vendor dengan memberikan dukungan untuk produk untuk perusahaan sejenis di industri ini dievaluasi. Ini mungkin termasuk mendapatkan dan mewawancarai referensi dari perusahaan yang saat ini menggunakan produk. Anda umumnya ingin menggunakan vendor yang telah menunjukkan bahwa mereka dapat melakukan jenis layanan yang Anda butuhkan pada skala yang serupa dengan Anda.
• Pastikan kemampuan dukungan teknis vendor dipertimbangkan dan dievaluasi.
• Pastikan setiap vendor dibandingkan dengan kriteria yang telah ditentukan, memberikan evaluasi yang obyektif.
• Tentukan apakah ada keterlibatan personil pengadaan yang tepat untuk membantu menegosiasikan kontrak, personil operasi untuk memberikan evaluasi ahli mengenai kemampuan vendor untuk memenuhi persyaratan, dan personil hukum untuk memberikan panduan mengenai potensi peraturan dan konsekuensi hukum lainnya.
• Setelah vendor dipilih, pastikan kontrak mengidentifikasi dengan jelas kiriman, persyaratan, dan tanggung jawab. Kontrak harus menentukan bagaimana kinerja akan diukur dan denda untuk kinerja yang tidak kinerja atau tertunda. Ini juga harus memberikan syarat untuk mengakhiri kesepakatan. Pada dasarnya, apa pun yang Anda harapkan dari vendor perlu dijelaskan secara khusus dalam kontrak.
• Pastikan bahwa kontrak berisi klausul nondisclosure yang mencegah vendor untuk mengungkapkan informasi perusahaan.
• Pastikan bahwa kontrak berisi klausul "hak untuk mengaudit" yang memungkinkan Anda mengaudit aktivitas vendor yang penting bagi perusahaan Anda.
• Bila memungkinkan, pastikankode tersebut dimasukkan ke dalam escrow untuk melindungi dari ketidaktersediaan jika vendor tersebut gulung tikar dan bahwa strategi exit yang tepat ada jika hubungan antara perusahaan Anda dan vendor dihentikan karena alasan apa pun.
Desain dan Pengembangan Sistem Terperinci
17. Pastikan bahwa semua persyaratan dapat dipetakan ke elemen desain. Proses yang didefinisikan untuk melacak persyaratan pada perancangan sistem akan memberikan kepastian bahwa semua persyaratan ditangani, termasuk elemen TI standar seperti antarmuka, waktu respon, dan kapasitas.
Bagaimana caranya? Jika ada daftar jejak persyaratan, tinjau dan verifikasi bahwa semua persyaratan diwakili dan dipetakan ke elemen desain. Jika peta jejak tidak ada, tinjau proses untuk memastikan bahwa semua persyaratan tercakup.
18. Verifikasi bahwa pemangku kepentingan utama telah menandatangani dokumen desain rinci atau katalog "use case". Dokumen desain rinci digunakan untuk perancangan sistem, perangkat lunak, atau proses. Katalog "use case" dapat dibuat untuk pelanggan proyek sebagai dokumen teknis kurang yang merinci desain sistem dari sudut pandang yang lebih fungsional (yaitu, merinci dengan tepat bagaimana setiap fungsi sistem yang dibutuhkan akan diterapkan). Dokumen ini akan menentukan kriteria keberhasilan dan kegagalan untuk setiap skenario dalam aplikasi. Misalnya, check out pelanggan untuk aplikasi e-commerce akan menjadi kasus penggunaan yang akan menghasilkan banyak langkah (seperti memverifikasi bahwa pengguna masuk, memvalidasi alamat pengiriman, dan sebagainya), yang kesemuanya akan didokumentasikan. secara terperinci. Jika pemangku kepentingan utama belum menandatangani dokumen yang sesuai ini, kemungkinannya lebih besar bahwa output dari proyek mungkin tidak sesuai dengan kebutuhan mereka.
Bagaimana caranya? Cari dokumen desain rinci yang setara sebagai bukti persetujuan pelanggan. Perhatikan bahwa personil nonteknis mungkin tidak dalam posisi untuk memahami dokumen desain terperinci, tergantung pada bagaimana penulisannya. Jika demikian, pastikan bahwa review desain kompensasi atau katalog "use case" telah dikembangkan yang memungkinkan pemangku kepentingan memahami elemen desain yang direncanakan.
19. Tinjau kembali proses untuk memastikan keterlibatan pelanggan yang berkelanjutan dengan memprioritaskan tugas pada proyek. Sebagian besar proyek mengalami fluiditas, dengan persyaratan awal yang jarang berakhir sebagai persyaratan akhir. Jika pemangku kepentingan utama tidak terlibat dalam keseluruhan proyek, proyek ini berisiko tersesat dari persyaratan pelanggan, dan keputusan dapat dibuat yang tidak sesuai dengan keinginan pelanggan.
Bagaimana caranya? Tentukan apakah kelompok pengaturan arah telah ditetapkan dan berisi kunci pelanggan dan apakah mereka terlibat dalam keputusan proyek secara reguler. Menipu Sider mewawancarai sejumlah kecil pelanggan untuk mendapatkan pendapat mereka mengenai keterlibatan pelanggan. Carilah bukti pertemuan review proyek berkala dan komunikasi berkala dengan pemangku kepentingan utama.
20. Carilah bukti peer review dalam desain dan pengembangan. Disiplin kontrol kualitas ini, yang melibatkan peninjauan kode dan konfigurasi oleh rekan-rekan pengembang, dapat membantu meningkatkan peluang bahwa sistem akan dirancang dengan logika suara dan minimal kesalahan.
Bagaimana caranya? Tentukan apakah peer review diperlukan oleh proses, dan mencari bukti bahwa mereka benar-benar terjadi.
21. Pastikan pengendalian internal dan keamanan yang tepat telah dirancang ke dalam sistem. Lihat langkah 15 untuk informasi lebih lanjut.
Bagaimana caranya? Validasi (baik melalui wawancara atau ulasan desain) bahwa masukan yang Anda berikan pada langkah 15 telah tercakup dalam perancangan sistem.
Pengujian
22. Pastikan desain dan pengujian sedang terjadi di lingkungan pengembangan / uji dan tidak di lingkungan produksi. Kegagalan dalam melakukan desain dan uji kerja di lingkungan yang berdedikasi dapat mengakibatkan terganggunya kegiatan bisnis normal.
Bagaimana caranya? Lihat bukti bahwa lingkungan yang digunakan selama pengembangan dan pengujian terpisah dari lingkungan yang digunakan untuk produksi. Melihat tata letak arsitektur, dan memvalidasi segregasi lingkungan. Melihat anggota proyek masuk ke berbagai lingkungan, dan memastikan bahwa server yang digunakan untuk desain, pengujian, dan produksi sesuai dengan tata letak arsitektur. Juga, pastikan bahwa lingkungan uji erat mencerminkan lingkungan produksi. Jika tidak, tes kode yang berhasil di lingkungan pengujian mungkin bukan indikator bahwa kode tersebut akan bekerja di lingkungan produksi atau akan terukur dengan beban produksi.
23. Tinjau dan mengevaluasi proses pengujian. Pastikan bahwa proyek memiliki rencana uji yang memadai dan mengikuti rencana uji ini. Menguji sistem, perangkat lunak, atau proses akan memberikan kepastian bahwa ia bekerja sebagaimana mestinya.
Bagaimana caranya? Kaji rencana uji untuk beberapa elemen.
Pertama, tentukan apakah rencana uji meliputi:
• Pengujian unit Pengujian modul sistem individual atau unit atau kelompok unit terkait
• Pengujian integrasi Pengujian beberapa modul atau unit untuk memastikannya bekerja sama dengan benar
• Pengujian sistem Pengujian keseluruhan sistem oleh tim pengembang
• Uji penerimaan Pengujian yang dilakukan oleh pengguna akhir untuk memvalidasi bahwa sistem memenuhi persyaratan dan dapat diterima
• Pengujian regresi Retestasi area pilih untuk memastikan bahwa perubahan yang dilakukan pada satu bagian sistem tidak menyebabkan masalah pada bagian lain sistem.
Kemudian tinjau rencananya berikut ini:
• Pastikan bahwa rencana uji dan prosedur dan uji kasus yang terkait dapat diulang sehingga dapat digunakan untuk pengujian regresi dan untuk rilis di masa mendatang.
• Pastikan bahwa rencana dan kasus uji coba dilakukan melalui peer review untuk memastikan kualitas.
• Tentukan apakah rencana pengujian mencakup pengujian data yang buruk / tidak benar, penanganan kesalahan sistem, dan pemulihan sistem.
• Tentukan apakah rencana pengujian mencakup pengujian keamanan dan pengendalian internal.
• Pastikan hasil pengujian didokumentasikan secara lengkap.
• Pastikan bahwa kesenjangan yang diidentifikasi selama pengujian didokumentasikan, dilacak, dipecahkan, dan diuji ulang. Pastikan proses gap/bug-tracking disetujui di depan. Proses ini perlu disederhanakan dan sistem perubahan terkontrol terbentuk dengan cepat, atau bisa menjadi berantakan, dengan kode ditarik masuk dan keluar dari produksi sembarangan.
• Pastikan tim proyek telah menyetujui metrik yang akan ditangkap dan dilaporkan selama pengujian dan bahwa metrik ini dilaporkan secara tepat waktu kepada anggota kepemimpinan proyek yang sesuai.
• Pastikan bahwa rencana pengujian mencakup pengujian persyaratan kinerja dan ambang batas.
• Pastikan setiap kasus uji mengidentifikasi produk, komponen, atau modul yang sedang diuji.
• Evaluasi proses untuk memastikan bahwa semua fungsi utama diuji dan semua jalur logika kunci diidentifikasi dan diuji. Jika katalog use case digunakan, evaluasi proses untuk memastikan semua elemen dari semua kasus penggunaan diuji.
• Pastikan data uji telah dibuat dan pelanggan setuju bahwa data uji valid.
• Tentukan apakah langkah-langkah uji menentukan hasil yang diharapkan dan kriteria penerimaan pelanggan.
• Pastikan semua tugas tes diidentifikasi dan ditetapkan sebagai pemilik dan bahwa "siapa, kapan, dan kapan" pengujian telah diidentifikasi dengan jelas untuk semua pihak yang terlibat.
• Pastikan bahwa tanda tangan yang sesuai telah diperoleh untuk rencana tersebut.
• Tentukan apakah rencana uji mencantumkan urutan di mana langkah-langkah uji harus dilakukan.
• Pastikan bahwa perencanaan pengujian mencakup identifikasi dan rencana untuk mendapatkan perangkat keras dan perangkat lunak yang diperlukan untuk pengujian.
• Jika menggunakan kombinasi perangkat lunak vendor dan kode yang dikembangkan secara internal, tentukan apakah sebuah proses telah ditetapkan untuk memastikan kode kedua belah pihak akan digabungkan dengan cara yang terkoordinasi dengan baik.
24. Pastikan semua persyaratan dapat dipetakan ke dalam kasus uji. Proses yang didefinisikan untuk melacak persyaratan ke rencana uji akan memberikan kepastian bahwa semua persyaratan ditangani dan diuji.
Bagaimana caranya? Jika ada daftar jejak persyaratan, tinjau dan verifikasi bahwa semua persyaratan diwakili dan dipetakan ke kasus uji. Jika peta jejak tidak ada, tinjau proses untuk memastikan bahwa semua persyaratan diuji.
25. Pastikan pengguna terlibat dalam pengujian dan setujui bahwa sistem tersebut memenuhi persyaratan. Ini harus mencakup personil TI yang akan mendukung sistem dan personil TI yang terlibat dalam melakukan studi kelayakan teknis awal untuk proyek tersebut. Sistem, perangkat lunak, atau proses sedang dikembangkan untuk memenuhi kebutuhan bisnis yang spesifik. Proyek ini tidak bisa sukses jika pemangku kepentingan utama tidak puas. Oleh karena itu, mereka harus dilibatkan dalam pengujian dan harus menandatangani sistem sebelum melakukan implementasi. Selain itu, seperti yang disebutkan pada langkah 13, beberapa organisasi di lingkungan TI biasanya akan terlibat dalam mendukung sistem baru, termasuk dukungan jaringan, dukungan sistem operasi, dukungan basis data, personil pusat data, keamanan TI, dan meja bantuan. Jika organisasi-organisasi ini tidak dilibatkan dalam pengujian dan penghentian sistem, mereka mungkin tidak siap untuk mendukungnya, dan / atau sistem mungkin tidak sesuai dengan standar dan kebijakan yang berlaku.
Bagaimana caranya? Cari bukti pengujian penerimaan pengguna. Pastikan pemegang saha, utama yang terlibat dalam meminta dan menyetujui proyek dan dalam menentukan persyaratan sistem (termasuk organisasi TI yang terkena dampak) juga terlibat dalam pengujian proyek dan sign-off.
26. Pertimbangkan untuk berpartisipasi dalam pengujian penerimaan pengguna dan memvalidasi bahwa keamanan sistem dan pengendalian internal berfungsi sebagaimana mestinya. Hal ini diperlukan untuk alasan yang sama yang diuraikan pada langkah 15. Dengan berpartisipasi dalam pengujian, Anda dapat memvalidasi kontrol ini secara independen.
Bagaimana caranya? Selama langkah awal, Anda seharusnya sudah bekerja dengan tim proyek untuk mengidentifikasi pengendalian internal yang harus dibangun di dalam sistem, perangkat lunak, atau proses. Tinjau kembali rencana pengujian untuk memastikan pengujian tersebut mencakup pengujian terhadap kontrol internal tersebut. Berpartisipasi sebagai tester penerimaan dari kasus uji tersebut.
Implementasi
27. Pastikan bahwa ada proses yang efektif untuk mencatat, melacak, meningkatkan, dan menyelesaikan masalah yang timbul setelah implementasi. Masalah yang tidak terduga muncul setelah implementasi hampir semua sistem baru. Tanpa metode yang kuat untuk menangkap dan menyelesaikan masalah tersebut, masalah dapat "lolos dari celah" dan tidak dapat diselesaikan secara tepat waktu. Juga diperlukan sistem pelacak masalah untuk memastikan bahwa isu diprioritaskan dan diperbaiki sesuai dengan kepentingannya.
Bagaimana caranya? Tinjau ulang database masalah, menerbitkan spreadsheet, atau metode lain yang telah ditetapkan untuk merekam dan melacak masalah pasca implementasi. Pastikan alat yang mengeluarkan catatan mencatat informasi yang memadai mengenai setiap masalah, termasuk deskripsi masalah, tingkat prioritas, tanggal jatuh tempo, status terbaru, dan informasi resolusi. Pastikan kontrol ada di atas alat yang digunakan untuk melacak masalah, seperti backup dan keamanan untuk mencegah pembaruan yang tidak sah. Tinjau ulang proses untuk mengatasi masalah dan untuk memastikan bahwa isu dilacak ke resolusi. Tinjau daftar masalah untuk bukti bahwa masalah sedang ditutup. Wawancara pelanggan untuk memastikan prosesnya berjalan.
28. Tinjau dan mengevaluasi rencana konversi proyek. Pastikan bahwa proyek memiliki rencana konversi yang memadai dan mengikuti rencana ini. Jika proyek yang ditinjau melibatkan penggantian sistem yang ada, pada titik tertentu, pengguna akan beralih ke sistem yang baru. Sangat penting bahwa data yang ada berhasil dikonversi ke sistem baru sebelum waktu ini untuk memastikan transisi yang mulus.
Bagaimana caranya? Tinjau rencana konversi, dan mencari elemen seperti berikut ini:
• Pastikan semua data penting diidentifikasi dan dipertimbangkan untuk konversi.
• Mengkaji ulang kontrol untuk memastikan bahwa semua data dikonversi sepenuhnya dan akurat. Contoh mekanisme kontrol semacam itu bisa jadi kontrol totalbidang kunci, catatan, dan prosedur rekonsiliasi pengguna.
• Tentukan apakah semua program konversi diuji sepenuhnya dengan keterlibatan pengguna dan hasil tes didokumentasikan.
• Jika data historis tidak dikonversi, pastikan metode dikembangkan untuk mengakses data jika diperlukan. Misalnya, jika data keuangan dilibatkan, data keuangan historis mungkin diperlukan di masa depan untuk pelaporan pajak.
• Meninjau dan mengevaluasi rencana pemrosesan paralel atau metode fallback lainnya jika terjadi kesulitan dalam transisi ke sistem yang baru.
• Pastikan bahwa proses konversi mencakup penetapan data yang tidak digunakan dalam sistem warisan. Misalnya, catatan di sistem baru mungkin berisi bidang yang tidak terdapat dalam catatan serupa tentang sistem warisan. Pertimbangan harus diberikan untuk mengisi bidang baru ini.
• Meninjau dan mengevaluasi rencana untuk "akhir pekan konversi." Rencana terperinci harus berisi kriteria dan pos pemeriksaan untuk membuat keputusan "go / no-go".
29. Tinjau kembali rencana untuk mengubah dukungan sistem atau perangkat lunak baru dari tim proyek ke tim dukungan operasional. Setelah proyek selesai, kemungkinan personil proyek akan dipindah-tangankan ke proyek lain. Oleh karena itu penting untuk menjalankan / mempertahankan personil pendukung agar dilatih dengan benar dalam fungsionalitas sistem sehingga mereka siap untuk mendukungnya saat pengguna mengidentifikasi masalah atau meminta penyempurnaan. Ini adalah salah satu elemen proyek yang paling sering diabaikan.
Bagaimana caranya? Lakukan wawancara atau peninjauan dokumentasi, cari bukti bahwa personil pendukung telah diidentifikasi, terlibat secara memadai dalam proyek, dan dilatih secara tepat terhadap sistem dan fungsinya.
30. Pastikan dokumentasi yang memadai telah dibuat untuk penggunaan sistem atau proses yang sedang dikembangkan dan pemeliharaan sistem atau perangkat lunak. Evaluasi proses agar dokumentasi tetap up-to-date. Evaluasi kontrol dan keamanan perubahan atas dokumentasi itu. Dokumentasi teknis dan pengguna yang tidak lengkap atau ketinggalan jaman dapat meningkatkan biaya dan waktu siklus untuk mempertahankan perangkat lunak, meningkatkan biaya dukungan dan pelatihan, dan membatasi kegunaan sistem, proses, atau perangkat lunak kepada pelanggan.
Bagaimana caranya? Dapatkan salinan dokumentasi yang ada, dan mengevaluasi kecukupannya. Carilah bukti yang akan menunjukkan bahwa dokumentasi telah diperbarui saat sistem telah berubah, dan meninjau proses untuk memastikan pemeliharaan dokumentasi yang sedang berlangsung. Pastikan file yang berisi dokumentasi dikunci dan hanya dapat diubah oleh personil yang tepat. Wawancara personil yang tepat untuk memahami proses perubahan dokumen kritis. Pastikan proses persetujuan diperlukan sebelum perubahan dilakukan terhadap dokumen penting dan bahwa proses persetujuan tidak dapat dielakkan.
Pelatihan
31. Tinjau kembali rencana untuk memastikan bahwa semua pengguna yang terkena dampak dilatih dalam penggunaan sistem, perangkat lunak, atau proses yang baru. Pelatihan merupakan elemen penting untuk mempersiapkan pengguna akhir mengenai fungsionalitas dan nuansa sistem yang baru dikembangkan. Jika pelatihan tidak diberikan atau tidak memadai, sistem, perangkat lunak, atau proses baru kemungkinan akan disalahgunakan, digunakan secara tidak efektif, atau dihindari.
Bagaimana caranya? Tinjau rencana pelatihan dan mewawancarai pengguna untuk mengembangkan opini tentang kecukupannya. Bandingkan daftar penerima pelatihan yang direncanakan dengan populasi pengguna akhir untuk memastikan tidak ada kesenjangan yang signifikan.
32. Pastikan bahwa proses telah dilakukan untuk menjaga materi pelatihan tetap up-to-date. Evaluasi kontrol perubahan dan keamanan materi pelatihan. Karena karyawan baru dan pengguna baru perlu menggunakan sistem ini, mereka ingin memanfaatkan materi pelatihan tersebut. Jika materi pelatihan ini sudah usang (misalnya, karena perubahan sistem), efektivitas materi pelatihan akan terbatas.
Bagaimana caranya? Cari bukti yang menunjukkan bahwa pelatihan telah diperbarui saat sistem telah berubah, dan meninjau proses untuk memastikan pemeliharaan dokumentasi yang sedang berlangsung. Pastikan file yang berisi dokumentasi dikunci dan hanya dapat dimodifikasi oleh personil yang tepat. Wawancara personil yang tepat untuk memahami proses perubahan dokumen kritis. Pastikan proses persetujuan diperlukan sebelum perubahan dilakukan terhadap dokumen penting dan bahwa proses persetujuan tidak dapat dielakkan.
Wrap-up Proyek
33. Pastikan sebuah proses ada untuk menutup proyek dan mencatat pelajaran yang dipetik dan bahwa prosesnya diikuti. Dokumentasi proyek akhir dan pelajaran terekam dapat digunakan untuk membantu efektivitas dan efisiensi proyek perusahaan masa depan. Langkah ini sering tidak terjawab, karena tim proyek dengan cepat beralih ke tugas lain setelah sukses diimplementasikan.
Bagaimana caranya? Tinjau dokumentasi proyek, dan memastikan bahwa semua dokumen yang relevan telah selesai dan telah ditetapkan sebelumnya. Carilah bukti bahwa daftar akhir pelajaran yang dipetik dari proyek telah didokumentasikan.
Sumber:
Davis, Chris. Schiller, Mike. Wheeler, Kevin. 2011. IT Auditing: Using Controls to Protect Information Assets Second Edition. New York. The McGraw-Hill Companies.
