URGENSI MAINTAINABILITY DALAM PENGEMBANGAN SOFTWARE

Transkripsi

1 Tugas Mata Kuliah SISTEM INFORMASI MANAJEMEN URGENSI MAINTAINABILITY DALAM PENGEMBANGAN SOFTWARE Oleh: SYAHFITRI SURYANINGSI WELKOM NIM.P E Kelas E-48 Dosen: Dr. Ir. Arif Imam Suroso, MSc (Cs) PROGRAM PASCASARJANA MANAJEMEN DAN BISNIS INSTITUT PERTANIAN BOGOR 2014

2 DAFTAR ISI DAFTAR ISI... DAFTAR GAMBAR... i ii BAB I PENDAHULUAN Latar Belakang Masalah Perumusan Masalah Tujuan... 2 BAB II PEMBAHASAN Definisi Software Maintenance/ Maintainability dan Tahapannya Permasalahan Software Maintenance/ Maintainability Solusi Permasalahan Software Maintenance/ Maintainability... 8 BAB III PENUTUP Kesimpulan Saran DAFTAR PUSTAKA i

3 DAFTAR GAMBAR Gambar 1 Proses Software Maintenance... 4 Gambar 2 Biaya Perbaikan Errors... 7 ii

4 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 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? 1

5 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. 2

6 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). 3

7 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. 4

8 b. Adaptive Adaptive merujuk pada kegiatan yang berhubungan dengan pemodifikasian fungsifungsi yang telah ada atau menambah 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 5

9 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 subsubprogram serta kompleksitas aliran program logic diantara mereka (Banker et al 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. 6

10 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 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 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 7

11 ini tidak bisa digunakan untuk penanggalan setelah tahun 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 programprogram 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 8

12 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 memperbaiki image negatif dari software maintenance 9

13 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. 10

14 DAFTAR PUSTAKA Kulkarni VG, Kumar S, Mookerjee VS, Sethi SP Optimal allocation of effort to software maintenance: A queuing theory approach. Production and Operations Management. 18(5): Laudon KC, Laudon JP Management Information Systems: Managing the Digital Firm. 7 th Edition. New Jersey: Prentice-Hall, Inc. Midha V, Palvia P, Singh R, Kshetri N Improving open source software maintenance. The Journal of Computer Information Systems. 50(3): O Brien JA, Marakas GM Management Information Systems. 10 th Edition. New York: McGraw-Hill/ Irwin. Schneidewind NF The state of software maintenance. IEEE Transactions on Software Engineering. 13(3): Tan Y, Mookerjee VS Comparing uniform and flexible policies for software maintenance and replacement. IEEE Transactions on Software Engineering. 31(3): Turban E, Mclean E, Wetherbe J Information Technology for Management: Transforming Business in the Digital Economy. 3 rd Edition. New York: John Wiley & Sons, Inc. Yau SS, Collofello JS Some stability measures for software maintenance. IEEE Transactions on Software Engineering. 6(6):