ENGEMBANGAN SISTEM MELALUI OTOMATISASI

ENGEMBANGAN SISTEM MELALUI OTOMATISASI

Proyek pengembangan sistem tidak selalu merupakan cerita sukses. Kenyata-annya, pada saat diimplementasikan, sebagian sistem menjadi usang atau rusak dan harus diganti. SDLC mengalami tiga masalah penyebab kegagalan sebagian besar sistem. Masalah-masalah tersebut didiskusikan di bawah ini.

1. Persyaratan sistem yang tidak dispesifikasi dengan baik. Pengembangan sistem melibatkan komunikasi manusia dan saling menukar gagasan antara pemakai dan profesional sistem. Pertukaran informasi ini sering terjadi tidak sempurna. Ke-salahan sering dilakukan dalam usaha mengidentifikasi masalah dan kebutuhan. Gagasan baru timbul ketika sifat baru dan masalah tersingkap, dan orang dapat mudah berubah pikiran tentang apa yang mereka inginkan dan butuhkan dari sistem tersebut.

Karena ketidakpastian ini, SDLC cenderung merupakan proses yang lancar, lurus, di mana satu tahap diselesaikan sebelum melangkah ke tahap baru. Dalam kenyataannya, proses tersebut bersifat siklis dan berulang. Dengan sifat siklis ini, suatu langkah awal yang salah akan banyak menghabiskan waktu, banyak kerja berulang, dan tekanan dari segala penjuru, mendesak agar pekerjaan tersebut cepat selesai. Sering kali, hasilnya adalah sistem yang dirancang secara buruk, anggaran berlebih, dan terlambat dari jadwal yang sudah ditentukan.

2. Teknik-teknik pengembangan sistem yang tidak efektif. Masalah yang dijelaskan di atas menjelaskan teknik yang tidak efektif untuk menyajikan, mendokumen-tasikan, dan memodifikasi spesifikasi sistem. Dalam skenario yang paling buruk, perangkat pengembangan sistem hanya berupa selembar kertas, pensil, penggaris, dan penghapus. Situasi ini diperbaiki dengan adanya perangkat lunak gratis yang berbasiskan PC (Personal Computer), yang memungkinkan pembuat-an desain awal dan perubahannya dilakukan secara elektronik. 

3. Kurangnya keterlibatan pemakai dalam pengembangan sistem. Pengembangan sistem komputer dianggap wilayah eksklusif dari para profesional sistem. Para memakai (termasuk akuntan) melepaskan tanggung jawab mereka untuk desain sistem. Hal ini juga menimbulkan masalah bisnis karena desain sistem men-cerminkan persepsi analis terhadap kebutuhan informasi, bukannya persepsi pa akuntan dan pemakai lainnya. Sistem seperti ini sering kali kurang memiliki kontrol dan jejak audit yang memadai.

Pembuatan Prototipe

Pembuatan prototipe adalah teknik untuk memberikan versi pekerjaan penda-huluan dari sistem kepada pemakai. Prototipe dibuat dengan cepat dan tidak malah dengan tujuan nantinya akan dimodifikasi. 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.

Biaya untuk membuat sebuah prototipe model dijaga tetap rendah dengan mengurangi fitur-fiturnya sampai pada elemen-elemen yang mendasar saja. Misal-nya, sistem prototipe tidak akan berisi kode kompleks yang diperlukan untuk melaku-kan validasi transaksi, kapabilitas penanganan-pengecualian, dan kontrol internal. Biasanya, prototipe dibatasi pada layar input pemakai, laporan output, dan beberapa fungsi utama.

Ketika sampai pada tahap-tahap front end dari SDLC, pembuatan prototipe menjadi alat yang efektif untuk membentuk apa yang diinginkan pemakai dari sistem. Ketika itu sudah didapatkan, prototipe dibuang. Prototipe yang sudah di-buang ini digunakan untuk mengembangkan aplikasi terstruktur, seperti sistem akun-tansi. Sebuah teknik alternatif meneruskan proses pembuatan prototipe sampai sistem itu selesai dibuat. Pendekatan ini digunakan untuk mengembangkan sistem pendukung keputusan. Gambar 13-2 menggambarkan model prototipe tersebut.

Pendekatan CASE

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 pe-rangkat lunak komersial yang berisi aplikasi integratif yang mendukung aktivitas SDLC secara luas. Metodologi ini dikembangkan untuk meningkatkan produktivitas profesional sistem, memperbaiki kualitas desain sistem, dan memperlancar SDLC.

Kebanyakan produk CASE terdiri atas perangkat atau aplikasi yang lebih tinggi atau lebih rendah. Perangkat CASE yang lebih tinggi mendukung aktivitas konseptual yang berkaitan dengan implementasi sistem dan pemeliharaan program. Gambar 13 - 3 menyajikan spektrum dukungan CASE dalam kaitannya dengan tahap-tahap SDLC. Perangkat CASE digunakan untuk mendefinisikan kebutuhan pe-makai, menciptakan database fisik dari perspektif pemakai konseptual, menghasilkan spesifikasi desain sistem, secara otomatis menghasilkan kode program komputer, dan memfasilitasi pemeliharaan program yang dibuat baik oleh CASE maupun teknik non-CASE. Gambar 13 - 4 menyajikan diagram ulasan tentang sistem CASE secara komprehensif. Berikut ini akan menjelaskan poin-poin penting dari diagram tersebut.

Repositori Sentral

Jantung sistem CASE adalah repositori (tempat penyimpanan) sentral. Pada dasarnya, ini merupakan database yang 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-akti-vitas desainer sistem yang bekerja pada proyek yang sama atau pada proyek-proyek yang terpisah tetapi saling berkaitan. Misalnya, jika ukuran atau nama dari atribut-atribut data harus diubah, maka semua aplikasi yang menggunakan atribut itu juga harus diubah. Dalam perusahaan­perusahaan yang berukuran sedang, hal ini melibat-kan ratusan program. Biasanya, dibutuhkan berhari-hari untuk mencari program-program yang dipengaruhi secara manual. Namun demikian, sistem repositori sentral dapat dengan cepat mengidentifikasi dan membuat daftar aplikasi yang meng-gunakan atribut yang diubah tersebut. 

Model CASE

Produk-produk CASE menggunakan beberapa model fungsional yang dapat di-gunakan untuk mendukung aktivitas dalam tahap-tahap yang berbeda dari SDLC. Sebagian model tersebut ditampilkan di bawah ini.

Model Diagram arus Data. Kami memperkenalkan diagram arus data (data flow diagram, selanjutnya disingkat menjadi DAD). 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 ber-macam­-macam tingkat rincian sistem. Dari sistem yang paling umum ke sistem yang paling rumit, berturut-turut, tingkat konteks, tingkat menengah, dan tingkat dasar.

DAD Tingkat Konteks. Analis dapat menggunakan DAD tingkat konteks untuk menyajikan sebuah model aktivitas bisnis dan transaksi-transaksi primer yang diproses oleh sistem tersebut. Gambar 13-5 menyajikan sebuah contoh dari diagram konteks dari siklus pendapat sebuah perusahaan. Diagram konteks merupakan representasi tingkat tinggi dari sebuah sistem. Diagram ini tidak berisi definisi file data dan prosedur secara rinci, melainkan fokusnya dipusatkan pada relasi kese-luruhan di antara entitas (data, sumber data, dan proses). Relasi ini diwakili oleh simbol-simbol, garis-garis, dan anak panah yang menunjukkan arah dari arus data.

DAD Tingkat Menengah. Langkah berikutnya adalah meluaskan DAD tingkat konteks ke dalam satu atau lebih DAD tingkat menengah, seperti yang diilustrasikan dalam Gambar 13-6. Perhatikan bagaimana Proses 1.0 dalam Gambar 13-5 diuraikan ke dalam sub-subproses berikut ini.

1.1 Persetujuan Penjualan

1.2 Pengiriman Barang-barang 

1.3 Penagihan Pelanggan

1.4 Pembaruan Piutang Dagang

Beberapa tingkat DAD menengah mungkin diperlukan untuk menyajikan rincian secara memadai kepada profesional sistem dan pemakai agar dapat sepenuhnya memahami sistem, Dalam contoh ini, kami menunjukkan hanya satu tingkat menengah.

DAD Tingkat Dasar. Gambar 13-7 menyajikan DAD tingkat dasar untuk Proses 1.3 dalam Gambar 13-6. Suatu DAD tingkat dasar menyediakan definisi yang jelas dan tepat untuk semua elemen sistem. Contoh ini, Proses 1.3 (penagihan pelanggan) dijelas-kan secara rinci. DAD tingkat dasar lainnya akan diperlukan untuk Proses 1.1, 1.2, dan 1.4

Persiapan DAD dalam lingkungan non-CASE dapat memakan banyak waktu analis. Karena perubahan-perubahan spesifikasi yang tidak dapat dihindari selama pengem-bangan sistem, seorang analis dapat menghasilkan banyak versi dari dokumen DAD sebelum sampai ke produk final. Kapabilitas grafik, yaitu fungsi-fungsi pelabelan, modifikasi, dan pengaturan kembali, yang dimiliki perangkat CASE sangat memperlancar pekerjaan ini. Namun demikian, DAD CASE lebih dari sekadar gambar grafik dari sebuah sistem. Gambar 13-8 menunjukkan sebuah diagram struktur untuk DAD tingkat dasar dalam Gambar 13-7. Diagram struktur menunjukkan relasi keseluruhan di antara modul-modul yang membentuk sistem tersebut. Setiap model ini menampilkan sebuah program terpisah yang harus diberi kode, kecuali jika program itu sudah ada sebagai modul program yang dapat dipakai berulang.

Model Prototipe. Model prototipe mendukung konsep pembuatan prototipe yang telah dijelaskan sebelumnya. Model ini sangat membantu memastikan bahwa kebutuhan pe-makai dipenuhi. Profesional sistem dapat segera memberikan layar input dan format-format laporan kepada para pemakai. Karenanya pemakai dapat memvisualisasikan fitur-fitur tertentu dart sistem tersebut sebelum nantinya benar-benar diraneang dan mengevaluasi sistem yang diusulkan. Setiap perubahan dapat diimplementasikan se-belum sistem ini dirancang dan dengan tanpa mengorbankan jadwal proyek.

Model Desain. Logika model desain didasarkan pada konsep dekomposisi (pe-nguraian). Setiap sistem dapat diuraikan atau didekomposisikan dari atas ke bawah dalam bentuk sub-subsistem yang lebih: kecil dan lebih kecil lagi, masing-masing dengan fungsi spesifik. DAD merupakan sebuah model sistem konseptual, dan diagram struktur me-rupakan model kode program yang membentuk sistem fisik. Gambar 13-8 menunjukkan diagram struktur untuk DAD tingkat dasar dalam Gambar 13-7. Diagram struktur me-nunjukkan keseluruhan relasi di antara modul-modul yang membentuk sistem tersebut. Setiap modul mewakili sebuah program terpisah yang harus dikodekan, keeuali jika modul itu sudah ada sebagai modul program yang dapat dipakai berulang. 

Banyak perangkat CASE mendokumentasikan rincian setiap modul dalam bentuk kode­kode samaran. Kode-kode samaran tersebut memberitahukan para pengamat (analis, auditor, atau pemrogram) tentang diagram struktur persis seperti yang akan dilakukan oleh modul, apa pun bahasa program yang digunakan. 

Model Pengkodean. Salah satu keunggulan CASE dalam menghemat te-naga kerja adalah fasilitasnya untuk mentransformasikan diagram struktur ke dalam modul-modul komputer. Banyak perangkat CASE top-end menghasilkan kode sumber program, seperti COBOL, C, dan C++. Program-program sumber ini kemudian harus dikompilasi-kan (diterjemahkan) ke dalam modul-modul kode mesin yang dapat dijalankan.

Model Pemeliharaan. Delapan puluh sampai sembilan puluh persen dari total biaya sistem dihabiskan selama tahap pemeliharaan SDLC. Hal ini sering kali disebut sebagai "efek gunung es." Gambar 13-9 menggambarkan fenomena ini. Semua sistem harus dipelihara selama masa hidup mereka, dan efek gunung es ini memang tidak bisa dihindari. Namun demikian, sistem­sistem yang dirancang dengan buruk berpeluang besar untuk menimbulkan masalah ini. Untuk membuat perubahan pada program kom-puter yang berada dalam lingkungan non­-CASE, pemrogram pemeliharaan (maintenance programmer) pertama-tama harus mempelajari secara menyeluruh kode program dalam usahanya memahami logika pemrogram awal. Hal ini sering kali memerlukan banyak waktu dan ini diperlama oleh logika program yang berlebihan, tidak efisien, dan kaku. Bahkan, perusahaan yang menggunakan perang-kat CASE memiliki kemungkinan memiliki sistem yang dirancang dengan buruk. Sering kali sistem­sistem tersebut sudah usang dan mendahului pemakaian CASE.

Model pemeliharaan CASE memfasilitasi pemeliharaan program dan sangat mengurangi efek gunung es. Aplikasi-aplikasi yang awalnyadikembangkan menurut sistem CASE relatif mudah dipelihara. Pemrogram pemeliharaan mempelajari doku-mentasi untuk aplikasi tersebut dan melakukan perubahan yang diperlukan, di tingkat konseptual, pada DAD. Sistem CASE kemudian membuat perubahan pada diagram-diagram struktur dan kode program secara otomatis. Akhirnya, pemrogram akan menguji secara menyeluruh dan memasang aplikasi yang sudah dimodifikasi.

Perangkat CASE dapat digunakan untuk memelihara aplikasi yang awalnya tidak dikembangkan oleh sistem CASE. Model pemeliharaan sistem akan menye-diakan perangkat seperti itu untuk tujuan ini: membalikkan teknologi dan rekayasa teknologi. Pembalikan ekstrak teknologi dari kode sumber akan merancang spesifi-kasi yang dapat digunakan pemrogram pemeliharaan untuk memahami logika apli-kasi. Rekayasa teknologi merestrukturisasi dan mendokumentasikan logika kode sumber yang lama agar sesuai dengan standar-standar CASE. Termasuk dalam hal ini adalah menyiapkan DAD dan diagram struktur. Jadi, pemeliharaan sistem di masa depan diteruskan jika aplikasi tersebut raJa awalnya dibuat menurut sistem CASE.

Keunggulan CASE

1. Mengurangi kompleksitas sistem.
2. Meningkatkan fleksibilitas.
3. Kapasitas untuk mempelajari desain-desain alternatif.
4. Proses pengembangan 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.
2. Waktu dan biaya memulai.
3. Perangkat CASE yang tidak sesuai.
4. Program yang tidak efisien.

ENGEMBANGAN SISTEM MELALUI OTOMATISASI 2017-03-20T09:48:00-07:00 Rating: 4.5 Diposkan Oleh: frf