Tugas Mata Kuliah
SISTEM INFORMASI MANAJEMEN
“URGENSI MAINTAINABILITY DALAM PENGEMBANGAN
SOFTWARE”
Oleh:
SYAHFITRI SURYANINGSI WELKOM NIM.P056122011.50E
Kelas E-48
Dosen:
Dr. Ir. Arif Imam Suroso, MSc (Cs)
PROGRAM PASCASARJANA MANAJEMEN DAN BISNIS INSTITUT PERTANIAN BOGOR
i DAFTAR ISI
DAFTAR ISI ... i
DAFTAR GAMBAR ... ii
BAB I PENDAHULUAN ... 1
1.1 Latar Belakang Masalah ... 1
1.2 Perumusan Masalah ... 1
1.3 Tujuan ... 2
BAB II PEMBAHASAN... 3
2.1 Definisi Software Maintenance/ Maintainability dan Tahapannya ... 3
2.2 Permasalahan Software Maintenance/ Maintainability ... 5
2.3 Solusi Permasalahan Software Maintenance/ Maintainability ... 8
BAB III PENUTUP ... 10
3.1 Kesimpulan ... 10
3.2 Saran ... 10
ii DAFTAR GAMBAR
Gambar 1 Proses Software Maintenance ... 4 Gambar 2 Biaya Perbaikan Errors ... 7
1 BAB I
PENDAHULUAN
1.1 Latar Belakang Masalah
Maintainability software merupakan kemampuan software untuk bisa diperbaiki, baik dalam bentuk perbaikan errors maupun defisiensi, bisa dikembangkan atau dikerucutkan, bisa memfasilitasi perubahan permintaan atau kepuasan yang baru dengan cara pengembangan fungsi-fungsi yang telah ada sebelumnya, modifikasi untuk hardware upgrades, maupun dengan memperbaiki code errors.
Pengoptimalan software maintenance kemudian menjadi masalah besar dalam pengembangan software yang menimbulkan kekhawatiran yang mendasar bagi organisasi karena proses perawatan ini membutuhkan biaya yang sangat mahal. Lientz dan Swanson (1980, Coleman et al. 1994 dalam Kulkarni et al. 2009) menyatakan bahwa biaya perawatan software biasanya lebih dari separuh biaya total yang dikeluarkan untuk penggunaan software tersebut. Arthur (1988 dalam Kulkarni et al. 2009) lebih jauh mengatakan bahwa pada siklus hidup yang dasar, lebih dari 75% dari investasi dalam sebuah sistem software terjadi setelah sistem diimplementasikan. Pigoski (1997 dalam Midha et al. 2010) menggambarkan porsi pengeluaran industri untuk perawatan sistem/ software adalah sebesar 40% di awal tahun 1970-an, 55% di awal tahun 1980-an, 75% di akhir tahun 1980-an, dan 90% di awal tahun 1990-an.
Biaya perawatan software yang tinggi tersebut membuat organisasi harus lebih memperhatikan proses perawatan ataupun maintainability. Oleh karena kebutuhan selalu berubah-ubah seiring dengan perkembangan zaman yang semakin dinamis, maka sudah seharusnya sejak awal pengembangan, sebuah software telah disiapkan untuk proses maintenance setelah software dijalankan. Ketidaksiapan sebuah software dalam menghadapi perubahan akan menyebabkan besarnya biaya maintenance.
1.2 Perumusan Masalah
Berdasarkan latar belakang masalah yang telah dikemukakan sebelumnya, maka permasalahan dalam makalah ini dapat dirumuskan sebagai berikut:
1. Bagaimana permasalahan software maintenance atau maintainability dalam pengembangan software?
2 2. Bagaimana solusi permasalahan software maintenance atau maintainability dalam
pengembangan software?
1.3 Tujuan
Sesuai latar belakang dan perumusan masalah, maka tujuan dari makalah ini adalah:
1. Untuk mengetahui permasalahan software maintenance atau maintainability dalam pengembangan software.
2. Untuk mengetahui solusi permasalahan software maintenance atau maintainability dalam pengembangan software.
3 BAB II
PEMBAHASAN
2.1 Definisi Software Maintenance/ Maintainability dan Tahapannya
Maintainability didefinisikan oleh Martin dan McClure (1983 dalam Schneidewind 1987) sebagai suatu kemudahan dimana sebuah sistem software bisa diperbaiki ketika terjadi kesalahan atau kekurangan dan bisa dikembangkan atau disusutkan untuk memenuhi kebutuhan yang baru. Sedangkan definisi perawatan (maintenance) adalah modifikasi atas sebuah produk software yang telah dijalankan untuk memperbaiki kecacatan/ kesalahannya, mengembangkan daya guna atau atribut lainnya, atau untuk menyesuaikan produk tersebut dengan perubahan lingkungan (Schneidewind 1987).
Evans dan Reddy (2002 dalam Kulkarni et al. 2009) mengatakan bahwa tanpa maintenance, sebuah software akan berada dalam ancaman menjadi usang/ kuno. Sehingga tidak mengherankan jika kebanyakan model siklus pengembangan software secara eksplisit memasukan maintenance untuk meningkatkan kualitasnya. Salah satu model yang paling umum digunakan adalah system development life cycle (SDLC).
Software maintenance merupakan aktivitas yang luas. Ketika sasaran perawatan yang spesifik dibuat, pertama-tama para personel perawatan harus memahami apa yang akan dimodifikasi untuk memenuhi sasaran perawatan. Setelah pemodifikasian, mereka harus memastikan bahwa pemodifikasin ini tidak berefek pada bagian program yang lain. Dan akhirnya mereka harus melakukan test terhadap program tersebut. Semua aktivitas ini nampak pada empat tahapan pada proses perawatan software pada Gambar 1(Yau dan Collofello 1980).
4 Gambar 1 Proses Software Maintenance
Sumber: Yau dan Collofello (1980)
Menurut O’Brien dan Marakas (2011: 516), sekali memulai fase perawatan, maka siklus hidupnya pun akan dimulai kembali. Kebutuhan yang baru pun akan diekspresikan, dianalisis, didisain, dicek fisibilitasnya, diuji, dan kemudian diterapkan. Mereka kemudian mengidentifikasi kegiatan perawatan ke dalam empat kategori, yaitu: a. Corrective
Corrective berfokus pada perbaikan bugs dan logic errors yang tidak terdeteksi selama periode pengujian.
5 b. Adaptive
Adaptive merujuk pada kegiatan yang berhubungan dengan pemodifikasian fungsi-fungsi yang telah ada atau menambah fungsi-fungsi baru untuk menampung perubahan dalam lingkungan bisnis atau operasi.
c. Perfective
Perfective menyangkut kegiatan merubah sistem yang sudah ada dengan maksud untuk memperbaiki/ meningkatkan daya guna/ kinerja fungsi atau interface.
d. Preventive
Preventive merupakan kegiatan yang menyangkut pengurangan peluang akan kegagalan sistem atau memperluas kapasitas dari kegunaan sistem yang sudah ada saat ini. Meskipun preventive adalah kegiatan perawatan yang prioritasnya paling rendah, namun kegiatan ini merupakan penambahan nilai fungsi yang tinggi dan vital dalam mewujudkan nilai yang optimal dari investasinya di dalam sistem.
Aktivitas perawatan juga mencakup proses melihat kembali pasca penerapan (postimplementation review) untuk memastikan bahwa sistem baru yang telah diimplementasikan sesuai dengan tujuan bisnis yang telah ditentukan. Kesalahan dalam pengembangan atau penggunaan harus diperbaiki dalam proses perawatan. Hal ini termasuk periode review atau audit sistem untuk memastikan bahwa ini telah dioperasikan dengan semestinya dan telah sesuai dengan tujuannya. Audit ini merupakan tambahan untuk memonitor secara kontinyu sebuah sistem baru untuk masalah yang potensial dan memerlukan perubahan (O’Brien dan Marakas 2011: 516).
2.2 Permasalahan Software Maintenance/ Maintainability
Saat ini software maintenance telah menjadi kekhawatiran penting dalam industri software. Tan dan Mookerjee (2005) mengatakan ada dua isu besar yang menyebabkan begitu penting dan urgennya masalah maintenance ini, yaitu biayanya dan kompleksitasnya. Lebih dari 50% dari total biaya dalam sistem software adalah untuk biaya perawatannya/ maintenance. Banker et al. (1998 dalam Kulkarni et al. 2009) mengindikasikan bahwa kompleksitas software adalah faktor kunci yang menghubungkan keputusan disain dan pengembangan untuk efek hilir pada perawatan
6 software. Hal ini berarti bahwa sebuah sistem software yang mudah dipahami maka juga akan mudah perawatannya.
Mahalnya biaya perawatan software disebabkan karena adanya perubahan organisasi. Perubahan internal yang besar dalam struktur atau kepemimpinan, atau perubahan yang datang dari lingkungan sekitar akan menyebabkan kebutuhan baru akan informasi. Kemudian kompleksitas software juga menjadi salah satu penyebab lainnya yang diukur dari jumlah dan ukuran dari hubungan program-program software dan sub-subprogram serta kompleksitas aliran program logic diantara mereka (Banker et al. 1993 dalam Laudon dan Laudon 2002: 439).
Mazzucchelli (1985 dalam Laudon dan Laudon 2002: 439) menulis masalah maintenance yang lainnya yaitu perawatan yang lama (long-term maintenance) yang disebabkan oleh kesalahan disain dan analisis sistem, khususnya analisis kebutuhan informasi. Beberapa studi dari sistem TPS besar yang dilakukan oleh TRW, Inc., menemukan bahwa sebagian besar dari sistem errors (64%) dihasilkan pada awal analisis (error analysis). Pada Gambar 2, Laudon dan Laudon (2002: 440) mengilustrasikan biaya perbaikan eror yang didasarkan pada pengalaman dari konsultan-konsultan yang dimuat dalam literatur. Jika eror dapat dideteksi lebih awal selama analisis dan disain, maka biaya pengembangan sistem akan kecil. namun jika eror tidak ditemukan sampai setelah progamming, testing, atau conversion telah selesai, biayanya bisa melambung tinggi. Sebagai contoh, sebuah logic error yang ringan yang memakan waktu satu jam perbaikan dalam tahap analisis dan disain, bisa memakan waktu 10, 40, dan 90 kali lebih lama untuk masing-masing perbaikan selama tahap programming, conversion, dan postimplementation.
7 Gambar 2 Biaya Perbaikan Errors
Sumber: Laudon dan Laudon (2002: 440)
Schneidewind (1987) mengatakan bahwa adanya permasalahan dalam maintenance dikarenakan oleh hal-hal berikut:
75-80% dari software yang ada adalah sebelumnya diproduksi dengan maksud untuk penggunaan program yang telah terstruktur.
sulit untuk memastikan apakah sebuah perubahan dalam code akan berdampak sesuatu
sulit untuk menghubungkan kegiatan programming yang spesifik dengan code yang spesifik
Zvegintzov (1983 dalam Schneidewind 1987) juga menyatakan bahwa hampir semua software adalah bersifat immortal. Semua survei tentang pendistribusian effort antara sistem yang baru dengan sistem yang telah ada menunjukan pembagian yang rata, yaitu 50-50 split. Hal ini karena adanya pertimbangan sebagai berikut:
fungsi-fungsi adalah ditambahkan, bukan diganti
setiap fungsi yang baru harus terikat pada sistem yang telah ada
tidak semua sistem yang diganti, kecuali untuk alasan ekonomi atau teknikal
organisasi mengupayakan keserasian/ kelayakan dalam sistem, bukan kesempurnaan Salah satu kasus besar dalam permasalahan maintenance ini terjadi pada saat menjelang tahun 2000. Permasalahan ini dikenal dengan masalah Y2K. Sebelum tahun 2000, banyak program-program komputer yang menyimpan sistem penanggalannya dalam enam digit (MM-DD-YY) untuk penyimpanan computer storage space, sehingga
8 ini tidak bisa digunakan untuk penanggalan setelah tahun 1999. Hal ini menyebabkan komputer akan menafsirkan tahun-tahun setelah 1999 bukan sebagai tahun 2000-an (20xx), melainkan tahun 19xx, sehingga akan menyebabkan errors pada setiap software yang peka terhadap waktu. Laudon dan Laudon (2002: 195) mengatakan bahwa untuk mengatasi masalah Y2K, sebelum tahun 2000, organisasi-organisasi menyisir program-program mereka untuk melokalisir semua coding untuk penanggalan yang mereka gunakan sebelumnya, dan ini diperkirakan menghabiskan total biaya di seluruh dunia sebesar $400 milyar sampai $600 milyar untuk mengatasi masalah ini.
2.3 Solusi Permasalahan Software Maintenance/ Maintainability
Turban et al. (2002: 615) mengatakan bahwa oleh karena biaya perawatan mahal, maka penting untuk mendisain dan mengembangkan tahapan sistem produksi yang mencakup semua fungsi yang esensial dalam initial vertions. Para pengembang juga seharusnya menggunakan metodologi software engineering yang layak dan membuat dokumentasi yang baik untuk sistem, sehingga perawatan pasti akan lebih mudah.
Schneidewind (1987) mengklasifikasikan beberapa usulan dari para penulis tentang perbaikan maintainability dari software, yaitu:
a. Design approach
design software with maintainability in mind
mengembangkan kriteria disain untuk mencapai maintainability kesederhanaan sebaiknya lebih diutamakan daripada kesempurnaan
membatasi dampak terhadap tahapan maintenance atas perubahan tahapan disain memastikan efek ripple pada modul lain atas perubahan modul umum; variabel
global dan modul-modul yang menggunakan atau digunakan oleh modul umum memastikan efek ripple pada sebuah modul atas perubahan pada variabel lokal mengevaluasi disain yang terlalu kompleks/ rumit
b. Maintenance practices
pada change management: memulai dengan perubahan yang paling mudah, mengubah satu modul dalam satu waktu, memeriksa perubahan usulan untuk masing-masing tipe dari efek, kemudian lakukan regression tests pada setiap perubahan
9 membuat petunjuk-petunjuk untuk modifikasi software dan pengujian kembali menyediakan informasi untuk mendukung penilaian atas dampak dari perubahan
dalam berbagai bagian software.
mengidentifikasi sumber laporan yang telah diubah dengan sebuah ukuran yang berhubungan dengan permintaan perubahan
mempelajari pembacaan program (alien code) keep diaries of bugs dan isu-isu maintenance
memusatkan keterangan-keterangan variabel dalam sebuah program
memusatkan pendefinisian database secara simbolik dalam komputer dengan kamus data
c. Management policies
melibatkan maintainer dalam disain dan testing
menerapkan ketegasan yang sama baik dalam standar disain maupun maintenance merotasi personel dalam bagian disain dan maintenance
menyediakan dokumentasi disain untuk maintainer memperhatikan design tools dalam maintenance
menggunakan prosedur permintaan perubahan dan konfigurasi management membangun hubungan komunikasi antar users dan maintenance
memasangkan sasaran software dengan tujuan organisasi
memasangkan reward software maintenance dengan kinerja organisasi menggabungkan personel software maintenance dalam tim operasional menciptakan anggaran maintenance yang discretionary perfective menciptakan pendapatan ekstra atas kepemilikan software
10 BAB III
PENUTUP
3.1 Kesimpulan
Ada dua permasalahan utama maintainability yang urgen dalam pengembangan software, yaitu masalah biaya perawatan software (maintenance) yang tinggi dan masalah kompleksitas. Masalah kompleksitas sendiri bisa menyebabkan sulitnya melakukan perawatan software yang kemudian menyebabkan lamanya waktu dan tingginya biaya perawatan itu sendiri. Pengembangan sebuah sistem software sebaiknya memperhatikan design approach, maintenance practices, dan management policies untuk mengoptimalkan software maintenance.
3.2 Saran
Pengembangan software sebaiknya memperhatikan masalah maintainability software, sehingga software bisa dengan mudah di-update, diperbaiki, ataupun dikembangkan dalam waktu yang singkat dan biaya yang rendah serta bisa digunakan dalam jangka yang panjang.
11 DAFTAR PUSTAKA
Kulkarni VG, Kumar S, Mookerjee VS, Sethi SP. 2009. Optimal allocation of effort to software maintenance: A queuing theory approach. Production and Operations Management. 18(5): 506-515.
Laudon KC, Laudon JP. 2002. Management Information Systems: Managing the Digital Firm. 7th Edition. New Jersey: Prentice-Hall, Inc.
Midha V, Palvia P, Singh R, Kshetri N. 2010. Improving open source software maintenance. The Journal of Computer Information Systems. 50(3): 81-90.
O’Brien JA, Marakas GM. 2011. Management Information Systems. 10th Edition. New York: McGraw-Hill/ Irwin.
Schneidewind NF. 1987. The state of software maintenance. IEEE Transactions on Software Engineering. 13(3): 303-310.
Tan Y, Mookerjee VS. 2005. Comparing uniform and flexible policies for software maintenance and replacement. IEEE Transactions on Software Engineering. 31(3): 238-255.
Turban E, Mclean E, Wetherbe J. 2002. Information Technology for Management: Transforming Business in the Digital Economy. 3rd Edition. New York: John Wiley & Sons, Inc.
Yau SS, Collofello JS. 1980. Some stability measures for software maintenance. IEEE Transactions on Software Engineering. 6(6): 545-552.
