Proses Pengembangan Sistem : Pengantar Siklus Hidup Pengembangan Sistem

Proses Pengembangan Sistem : Pengantar Siklus Hidup Pengembangan Sistem

 I.      SIKLUS HIDUP PENGEMBANGAN SISTEM

Banyak perusahaan berukuran moderat dan besar memiliki sebuah kelompok servis komputer internal yang merancang sistem komputer menurut pesanan (kebutuhan) untuk memenuhi kebutuhan sistem informasi yang unik dari organisasi. Sistem-sistem ini dikembangkan melalui sebuah proses yang formal yang disebut siklus hidup pengembangan sistem (system development life cycle, disingkat SDLC).

SDLC merupakan sebuah proses tujuh tahap yang terdiri atas dua tahap utama: pengembangan sistem dan pemeliharaan.

Pengembangan sistem

Enam tahap pertama dalam SDLC menjelaskan aktivitas-aktivitas yang harus dijalani oleh semua sistem baru. Pengembangan sistem baru melibatkan lima langkah: mengidentifikasi masalah, memahami apa yang telah dilakukan, mempertimbangkan solusi alternatif, memilih solusi yang terbaik, dan menerapkan solusi.

Pemeliharaan

Pemeliharaan berarti mengubah sistem untuk mengakomodasi perubahan dalam kebutuhan pemakai. Dalam batas tertentu pekerjaan ini cukup sepele, misalnya memodifikasi sistem untuk menghasilkan sebuah laporan baru atau mengubah panjang field data. Pemeliharaan dapat juga lebih luas dari itu, seperti misalnya melakukan perubahan besar pada logika aplikasi dan alat penghubung sistem (interface) yang dimiliki pemakai.

Pemeliharaan mewakili pengeluaran sumber daya yang signifikan dibandingkan biaya pengembangan awal. Selama masa hidup sebuah sistem, 80 sampai 90 persen dari total biayanya terserap dalam tahap pemeliharaan.

Pihak-pihak yang terkait dalam SDLC                                                                        

Pihak pihak yang terkait dalam pengembangan sistem dapat diklasifikasikan dalam tiga kelompok besar: profesional sistem, pemakai akhir, dan stakeholders. Profesional sistem adalah analisa sistem, desainer sistem, dan pemrograman. Mereka mengumpulkan fakta tentang masalah-masalah yang terdapat dalam sistem saat ini, menganalisa fakta-fakta ini dan merumuskan sebuah solusi untuk memecahkan masalah.

Pemakai akhir adalah mereka yang menjadi tujuan dibangunnya sebuah sistem. Terdapat banyak pemakai di semua tingkat dalam organisasi. Termasuk dalam hal ini adalah para manajer, personel operasi, akuntan, dan auditor internal.

Stakeholders adalah individu-individu yang terdapat di luar maupun dalam organisasi, yang memiliki kepentingan terhadap sistem tersebut tetapi bukan merupakan pemakai akhir. Termasuk dalam hal ini adalah akuntan, auditor internal, auditor eksternal, dan komite pengawas internal yang mengawasi pengembangan sistem-sistem tersebut.

II.      MEMPERBAIKI PENGEMBANGAN SISTEM MELALUI OTOMATISASI

            SDLC mengalami tiga masalah yang menjadi penyebab kegagalan sebagian besar sistem. Masalah-masalah tersebut adalah:

1.      Persyaratan sistem yang tidak dispesifikasi dengan baik. Proses ini melibatkan komunikasi manusia dan saling menukar gagasan di antara pemakai dan profesional sistem. Pertukaran informasi ini sering kali terjadinya tidak sempurna, kesalahan-kesalahan sering kali dilakukan dalam usaha mengidentifikasi masalah dan kebutuhan.

2.      Teknik-teknik pengembangan sistem yang tidak efektif. Dalam skenario yang paling buruk, perangkat pengembangan sistem hanya berupa selembar kertas, pensil, penggaris, dan penghapus. Sistem ini diperbaiki dengan adanya perangkat lunak grafis yang berbasiskan PC (personal komputer), yang memungkinkan pembuatan desain awal dan perubahan-perubahannya dilakukan secara elektronik.

3.      Kurangnya keterlibatan pemakai dalam pengembangan sistem. Penyebab utama kegagalan sistem adalah keterlibatan pemakai akhir dalam tahap-tahap pengembangan yang kritikal. Pada satu waktu, pengembangan sistem komputer dianggap wilayah eksklusif dari para profesional sistem. Selama periode tersebut, para pemakai (termasuk para akuntan) melepaskan tanggung jawab tradisional mereka untuk desain sistem.

Pembuatan prototipe

            Pembuatan prortotipe adalah teknik untuk memberikan versi pekerjaan pendahuluan dari sistem kapada pemakai. Tujuan teknik adalah bahwa prototipe itu mewakili "spesifikasi fungsional yang tidak ambigu, menjadi kendaraan untuk mengorganisasikan dan belajar, dan berproses untuk nantinya berkembang secara perlahan-lahan menjadi sistem yang diterapkan sepenuhnya". Ketika para pemakai sistem bekerja dengan prototipe dan memberikan usulan perubahan, baik pemakai maupun profesional sistem mengembangkan pemahaman yang lebih baik tentang apa yang sebenarnya dibutuhkan oleh sistem tersebut.

Pendekatan Kasus

            Teknologi rekayasa teknologi perangkat keras yang dibantu oleh komputer (computer-aided software engineering-CASE) melibatkan penggunaan sistem komputer untuk membangun sistem komputer. Perangkat CASE merupakan produk-produk perangkat lunak komersial yang berisi aplikasi-aplikasi integratif yang mendukung aktivitas SDLC secara luas. Metodologi ini dikembangkan untuk meningkatkan produktivitas profesional sistem, memperbaiki kualitas desain sistem, dan memperlancar SDLC.

            Jantung sistem CASE adalah repositori (tempat penyimpanan) sentral. Pada dasarnya, ini merupakan database yabg berisi atribut-atribut, relasi-relasi, dan elemen-elemen yang menjelaskan semua aplikasi yang dibuat oleh sistem CASE. Termasuk dalam item-item ini adalah:

1.      Definisi semua database

2.      Dokumentasi sistem, seperti diagram konteks, diagram arus data, dan grafik struktur.

3.      Kode program

4.      Modul-modul program yang dapat dipakai ulang.

5.      Layar prototipe pemakai.

            Sistem repositori sentral membantu untuk mengintegrasikan aktivitas-aktivitas desainer sistem yang bekerja pada proyek yang sama atau pada proyek-proyek yang terpusat tetapi saling berkaitan.

Model CASE

Model diagram arus data

            DAD menggunakan serangkaian simbol yang mewakili proses, sumber data, arus data, dan urutan proses sistem yang ada saat ini atau sistem yang diusulkan. Sebagai sebuah perangkat desain sistem, DAD digunakan untuk mewakili bermacam-macam tingkat rincian sistem.

Model prototipe

            Model prototipe mendukung konsep pembuatan prototipe. Model ini sangat membantu memastikan bahwa kebutuhan pemakai dipenuhi. Profesional sistem dapat segera memberikan layar input dan format-format laporan kepada para pemakai. karenanya pemakai dapat  memvisualisasikan fitur-fitur tertentu dari sistem tersebut sebelum nantinya benar-benar dirancang dan mengevaluasi sistem yang diusulkan.

Model desain

            Logika model desain didasarkan pada konsep (penguraian) sistem. Setiap sistem dapat diuraikan atau didekomposisikan dari atas ke bawah dalam bentuk sub-subsistem yang lebih kecil dan lebih kecil lagi. Diagram struktur menunjukkan keseluruhan relasi di antara modul-modul yang membentuk sistem tersebut. Setiap modul mewakili sebuah program terpisah yang harus dikodekan, kecuali jika model itu sudah ada sebagai modul program yang dapat dipakai berulang.

Model pengkodean

            Salah satu keunggulan CASE dalam menghemat tenaga kerja adalah fasilitasnya untuk mentransformasikan diagram struktur ke dalam modul-modul komputer. Banyak program CASE top-end menghasilkan kode sumber program, seperti COBOL, C, dan C++. Program-program sumber ini kemudian dikompilasikan (diterjemahkan) ke dalam modul-modul kode mesin yang dapat dijalankan. Pendekatan kode non-sumber memiliki dua implikasi untuk akuntan, auditor, dan pihak-pihak manajemen. Pertama adalah masalah kontrol potensial. Kode sumber program merupakan bagian dari dokumentasi sistem. Untuk merancang prosedur pengujian dengan benar, para auditor perlu mempelajari kode sumber. Jika kode sumber tidak ada, hal ini akan menghalangi pengujian dan mendesak auditor untuk menggunakan prosedur alternatif yang kurang efisien dan menuntut biaya yang lebih besar. Kedua, pendekatan kode non-sumber dapat mempengaruhi komitmen perusahaan pada perangkat CASE dan pemasok pengembangan, aplikasi-aplikasi tetap independen dari sistem CASE. Jika pihak manajemen memutuskan untuk beralih ke pemasok lain, aplikasi yang dipakai saat ini tetap dapat dipertahankan.

Model Pemeliharaan

            Model pemeliharaan CASE memfasilitasi pemeliharaan program dan sangat mempengaruhi efek gunung es. Aplikasi-aplikasi yang pada awalnya dikembangkan menurut sistem CASE relatif mudah dipelihara. Program pemeliharaan mempelajari dokumentasi untuk aplikasi tersebut dan merupakan dokumentasi untuk aplikasi tersebut dan melakukan perubahan yang diperlukan di tingkat konseptual pada DAD.

Keunggulan CASE

1.      Mengurangi kompleksitas sistem

2.      Meningkatkan fleksibilitas.

3.      Kapasitas untuk mempelajari desain-desain alternatif.

4.      Proses pemgembangan yang lebih cepat

5.      Mempromosikan keterlibatan pemakai.

6.      Kode program dan dokumentasi yang dapat dipakai berulang kali

7.      Mengurangi biaya pemeliharaan.

Kelemahan CASE

1.      Biaya produk yang mahal.

2.      Waktu dan biaya memulai yang banyak.

3.      Perangkat CASE yang tidak sesuai

4.      Program yang tidak sesuai.

 III.      PERENCANAAN SISTEM DAN ANALISIS SISTEM

            Tujuan perencanaan sistem adalah untuk menghubungkan proyek-proyek atau aplikasi-aplikasi sistem individual dengan tujuan-tujuan strategis. Perencanaan sistem terbagi atas dua tingkat: perencanaan sistem strategis dan perencanaan proyek. Perencanaan sistem strategis melibatkan alokasi sumber daya sistem di tingkat makro. Aktivitas ini biasanya dilakukan dalam kerangka waktu tiga sampai lima tahun.

           

Ada tiga pembenaran untuk perencanaan sistem strategis:

1.      Sebuah rencana yang berubah secara konstan lebih baik daripada tidak ada rencana sama sekali. Perencanaan strategis menunjukkan jalan yang akan diikuti perusahaan untuk mewujudkan tujuan sistem informasi.    

2.      Perencaanaan strategis mengurangi komponen-komponen krisis dalam pengembangan sistem. Sebuah perencanaan formal merupakan sebuah model untuk mengidentifikasi dan memprioritaskan kebutuhan pemakai.

3.      Perencanaan sistem strategis menyediakan kontrol otorisasi untuk SDLC. SDLC serupa dengan sistem aktiva tetap. Dalam kasus ini, aktiva tetap merupakan sistem baru dan proses akuisisi adalah SDLC.

            Tujuan Perencanaan proyek adalah untuk mengalokasi sumber daya pada aplikasi-aplikasi individual di dalam kerangka perencanaan strategis. Hal ini melibatkan pengidentifikasian wilayah-wilayah kebutuhan pemakai, menyiapkan proposal, mengevaluasi setiap kelayakan proposal dan sumbangannya bagi perencanaan bisnis, memprioritaskan proyek individual, menjadwalkan pekerjaan yang harus dilakukan.

Peran Akuntan dalam Perencanaan Sistem

            Selama proses perencanaan, para kuntan sering diminta untuk memberikan keahlian mereka dalam mengevaluasi kelayakan sebuah proyek. Keahlian mereka diperlukan untuk menspesifikasi aspek-aspek kelayakan ekonomi dan hukum. Dalam peran mereka sebagai auditor, para akuntan harus mempelajari tahap perencanaan sistem dari SDLC secara rutin. Para akuntan eksternal dan internal berkepentingan untuk memastikan bahwa perencanaan sistem yang memadai telah dilakukan.

Peran Akuntan dalam Analisis bisnis

         Sebagai langkah pendahuluan untuk setiap audit keuangan, para akuntan mensurvei sistem untuk memahami elemen-elemen penting dari sistem yang digunakan saat ini. Pengalaman dan pengetahuan akuntan di bidang ini dapat menjadi sumber yang berharga bagi analisis sistem. Auditor perusahaan (eksternal dan internal) adalah stakeholders dalam sistem yang diusulkan.

 IV.      DESAIN SISTEM KONSEPTUAL

            Tujuan dari tahap desain konseptual adalah untuk memastikan beberapa sistem konseptual alternatif yang memuaskan persyaratan sistem yang telah diidentifikasi selama analisis sistem. Bagian ini menjelaskan dua pendekatan untuk desain sistem konseptual: pendekatan desain terstruktur dan pendekatan desain yang berorientasi objek.

            Pendekatan desain terstruktur merupakan sebuah cara yang disiplin untuk mendesain sistem dari atas ke bawah. Dengan pendekatan ini, proses bisnis yang sedang dirancang biasanya didokumentasikan menurut arus data dan diagram data.

            Pendekatan desain yang berorientasi objek adalah untuk membangun sebuah sistem informasi dari komponen-komponen atau objek-objek standar yang dapat digunakan berulang kali.

Peran Akuntan dalam desain sistem konseptual

            Akuntan bertanggung jawab untuk sistem konseptual (arus informasi logis), dan profesional sistem bertanggung jawab untuk setiap fisik (pekerjaan teknis untuk membangun sistem). Sementara berpartisipasi dalam proses desain konseptual, akuntan harus menyadari bahwa setiap sistem alternatif harus dikontrol secara memadai, jejak audit harus dilestarikan, dan konvensi-konvensi akuntansi dan persyaratan hukum harus dipahami. Auditor merupakan stakeholders dalam semua sistem keuangan dan karenanya memiliki kepentingan dalam tahap desain konseptual dari sistem tersebut. Auditabilitas sebuah sistem sebagian bergantung pada karakteristik desainnya. Sebagian teknik-teknik audit komputer mensyaratkan bahwa sistem didesain dengan fitur-fitur audit spesial yang menyatu dengan sistem tersebut.