Recruitment

Create your own user feedback survey

Senin, 08 Desember 2008

Manfaat perlindungan HAKI bagi Industri software di Indonesia

Masa Tekhnologi informasi sudah banyak mencetak bilioner baru, dan kebanyakan dari mereka masih berumur sangat muda pada saat mulai. Seperti Bill Gate pemilik Microsoft, Larry Ellison pemilik oracle, Marc Benioff pemilik salesforce.com dan banyak lagi deretan nama nama pemain TI yang menjadi billioner.
Mungkin masih banyak lagi calon calon bilioner baru yang akan bermunculan, melalui TI baik itu di industri TI atau pengguna TI seperti amazone.com. Sejak komputer diciptakan mengubah banyak pola kehidupan masyarakat, komputer sudah dipakai di hampir segala bidang karena memang sifatnya sebagai alat kontrol yang dapat digunakan di berbagai kehidupan manusia. Penggunaan komputer ini akan berfungsi berfungsi optimal bila ada software didalam. Hal inilah yang memicu permintaan akan pembuatan software meningkat dengan pesat. Contohnya seperti :
• Membantu administrasi di perusahaan
• Automation
• Mobil
• Handphone
• Rumah
• Peralatan untuk mendesign
• Hiburan
• Dan masih banyak lagi lainnya

Dengan kemungkinan penggunaan yang cukup luas tersebut, pasar software makin lama akan makin berkembang, disamping jumlah pemakainya yang semakin banyak, jumlah aplikasinyapun bertambah banyak. Disinilah kesempatan untuk menjadi bilioner dibidang TI masih sangat luas sekali.

The law of increasing return
Di dunia software terutama industri software, biaya pembuatan software sangat mahal karena harus di tulis satu per satu dengan jumlah baris yang cukup banyak, sehingga memerlukan banyak tenaga dan waktu. Tetapi kalau software itu sudah dapat dijual, maka biaya penggandaannya murah sekali. Maka dari itu di industri software dikenal apa yang disebut dengan Law of Increasing return, makin banyak software produk yang terjual, makin murah biaya variabelnya.


Pembagian Pasar dunia TI
Gambar pembagian pasar dunia TI seperti pada gambar dibawah ini :







Software Produk, adalah perusahaan yang membuat software dan dijual secara masal. Di kategori ini ada dua jenis yaitu Mass Market software dan Enterprise software.






Bagaimana potensi software di Indonesia
Potensi pasar software di Indonesia bisa kita lihat dari tingkat pembajakan dan kerugian akibat pembajakan di Indonesia.
IDC report 2008



Tingkat pembajakan di Indonesia turun dari 85% menjadi 84% dan kerugian akibat pembajakan naik dari 350 juta mencapai 411 juta, terjadi kenaikan kerugian sebesar 61 juta. Angka ini menunjukkan bahwa pangsa software di Indonesia naik sangat pesat, walaupun tingkat pembajakan turun namun kerugian naik.
Bila jumlah pembajakan berkurang, dan nilai kerugian ini dapat diisi dengan software lokal maka potensi penghasilan software lokal menjadi besar sekali.

Bagaimana mensiasatinya ?
Untuk mengembangkan industri software perlu adanya insentif, dengan jumlah pembajakan yang cukup besar maka tidak ada lagi insentif bagi pemula untuk membuat software. Karena hasil pemikiran mereka tidak akan dihargai akan selalu dibandingkan dengan nilai software yang murah hasil bajakan.
Banyak memang yang berargumentasi, dengan banyaknya bajakan maka harga software menjadi murah dan memberi kesempatan bagi para pelaku TI untuk belajar. Pertanyaan berikutnya adalah kalau sudah dapat membuat program, bagaimana cara menjualnya ? karena harga software yang begitu murah, tidak ada lagi gairah atau insentif yang didapatkan dalam membuat software tersebut.
Salah satu negara dengan tingkat pembajakan paling tinggi ada di urutan ke 3 adalah Cina di tahun 2003 dengan tingkat pembajakan mencapai 92%. Dan pada saat Cina mau mengembangkan industri TI yang dilakukan adalah menurunkan tingkat pembajakan data dibawah ini adalah hasilnya setelah bekerja selama 3 tahun. Pada tahun 2003 mencapai 92% dan turun sangat drastis pada tahun 2006 menjadi 82%, penurunan 10 % ini pasar software lokal tumbuh hampir mencapai 1.2 billion USD di tahun 2006. (sumber dari allbusiness, Worldwide Software Piracy Rate Holds Steady at 35%; Global Losses Up 15%. Tanggal 15 mei 2007)
Sekarang Cina menduduki ranking ke 4 dalam software export, hampir menyamai India yang sudah terlebih dahulu menjadikan software industri. Padahal Cina mempunyai hambatan bahasa.

Strategi Pengembangan Software

Dalam pengembangan suatu software, waktu merupakan salah satu faktor yang krusial. Sering sekali pengembang software dalam membuat suatu software memerlukan waktu yang lebih lama dibandingkan dengan rencana pembuatan. Faktor yang menyebabkan pengembangan software ini membengkak merupakan hal yang sangat menarik untuk di kaji terutama oleh kalangan pengembang software. Dengan memperpendek waktu pengembangan berarti time-to-market akan lebih cepat dan efeknya adalah keadaan keuangan perusahaan akan lebih baik.
Sehingga sekarang pertanyaannya adalah bagaimana cara membuat suatu software yang tepat waktu ? Agar tepat waktu bagaimana dengan estimasi waktu pembuatan software apakah sudah menggunakan cara yang benar, kalau tidak berarti estimasinya sendiri juga salah, sehingga kalau dituntut agar pembuatan software tepat waktu juga sulit.
Faktor yang lainnya adalah dokumentasi kebutuhan pemakai, sering terjadi pada saat software sudah diserahkan, masih memerlukan banyak perubahan. Sehingga sering pengembang melakukan kerja ulang (Rework). Sering sekali pengembang tidak mengikuti SDLC (System Development Life Cycle) yang sesuai dengan project yang dikerjakan. Pemilihan SDLC yang tepat merupakan salah satu cara untuk dapat menyelesaikan proyek tepat waktu. Dibawah ini adalah hasil survey yang disajikan oleh Steve McConnel dalam bukunya Code Complete. Dari tabel tersebut dibawah ini jelaslah bahwa di proyek yang kecil waktu yang paling banyak digunakan adalah coding, sedangkan pada proyek yang besar, waktu yang paling banyak digunakan adalah desain.


Dapat disimpulkan agar kita dapat mengembangkan software dengan sesuai jadwal yang baik, pertama cara pembuatan schedule yang tepat sehingga schedule tidak dibuat dengan estimasi yang sebarang. Kedua kita harus dapat menentukan SDLC yang tepat, yang dilihat dari berbagai sudut, seperti apakah usernya mengetahui kebutuhannya, apakah ada dateline yang ketat. Ketiga kita harus perhatikan tim pengembang yang ada, seperti apakah kita dapat mengetahui progress pengembangan, sering kali progress pengembangan tidak diketahui oleh kepala tim pengembang. Kalau hal ini terjadi kepala tim tidak dapat memperbaiki hal hal yang rawan ditengah proyek itu berlangsung, setelah proyek selesai baru akan diketahui atau setelah dateline, baru muncul persoalan-persoalannya.
Pada edisi bulan depan akan dilanjutkan dengan bagaimana kita dapat membuat estimasi jadual pembuatan program, metoda apa yang harus digunakan agar proyek yang dikerjakan dapat tepat waktu.

Membuat estimasi jadual proyek
Ada beberapa cara untuk membuat estimasi suatu pengembangan software, dengan menggunakan function point, dengan menggunakan jumlah baris dalam program, atau dibandingkan dengan proyek yang sejenis yang pernah dibuat sebelumnya.
Cara function point, setelah desain selesai, kita tentukan berapa banyak function point yang ada untuk input, output, inquiry kemudian function point tersebut dikelompokan lagi menjadi mudah, sedang dan komplek. Dari hasil perhitungan statistik Jones dalam bukunya Applied Software Measurement membuat suatu tabel seperti berikut dibawah ini :


Setelah semua function point dihitung jumlahnya dan dimasukan kedalam tabel diatas, lalu dikalikan dengan faktor tersebut, hasil perkaliannya dijumlahkan semuanya maka akan mendapatkan angka total function point. Angka total tersebut dikalikan dengan influence multiplier antara 0,65 – 1,35. Function point multiplier ini ditentukan berdasarkan faktor faktor yang mempengaruhi dalam pengembangan software tersebut seperti data communication, penggunaan technologi baru, tim yang relatif masih belum pengalaman dalam mengerjakan proyek yang akan dikerjakan.
Hasil perkalian antara total function point dengan influence multiplier akan mendapatkan nilai function point. Agar didapat jumlah hari, maka kita gunakan data data yang ada selama mengerjakan proyek berapa lama rata-rata untuk mengerjakan 100 function point.

Pemilihan SDLC yang tepat
Sering sekali kita menjumpai perusahaan memanggil pengembang software untuk membuatkan suatu aplikasi, dan kebutuhan yang diinginkan tidak dapat dijelaskan dengan baik. Karena mungkin maunya banyak atau mungkin tidak tahu persis sistem yang dikehendaki, tahunya adalah ingin komputerisasi sehingga memudahkan pekerjaannya.
Bila kebutuhan user sulit ditangkap maka sebaiknya digunakan evolutionary prototyping, atau anjurkan saja menggunakan paket software yang sudah ada. Karena dengan menggunakan paket software yang ada paling tidak mereka akan dapat mempelajari, dan bila cocok dapat menggunakan paket software yang sudah jadi.
Dengan evolutionary prototyping pihak pengembang akan banyak pekerjaan diawal karena pada saat selesai survey kebutuhan, dibuatlah protype software yang akan dibuat, kemudian dari prototype tersebut dikembangkan disesuaikan dengan kebutuhan user. Setelah sesuai dengan kebutuhannya barulah dikerjakan programmnya. Cara ini akan menghemat banyak waktu di dalam coding, karena bila coding sudah selesai, sedikit perubahan yang dilakukan akan berakibat pada modul-modul yang lainnya. Sehingga akan memakan banyak waktu untuk mengerjakan ulang.
Bila dateline menjadi suatu hal yang sangat penting, maka SDLC design-to-schedule lebih tepat. Dalam menggunakan SDLC ini, salah satu syaratnya adalah kebutuhan user harus jelas benar. Kemudian ditentukan mana fungsi-fungsi yang harus dikerjakan terlebih dahulu, kemudian fungsi tersebut diurutkan berdasarkan prioritas. Sehingga bila pada saat dateline sudah tercapai maka fungsi-fungsi yang paling penting sudah diselesaikan, hanya fungsi-fungsi tambahan yang belum diselesaikan.
Dan masih banyak lagi SDLC dan bahkan kita dapat mengembangkan sendiri SDLC yang sesuai dengan pengembangan yang ditempat kita masing-masing.

Faktor-faktor penghambat lainnya
Sering sekali kita ditawarkan oleh tool pengembangan software yang dapat mempercepat waktu pengembangan, tetapi kita lupa bahwa dalam menggunakan tool baru, tim pengembang harus mempelajarinya terlebih dahulu. Pergantian tool baru ditengah proyek akan menghambat jadual pembuatan software.
Developer Gold Platting, programmer banyak menghabiskan waktunya untuk memperbaiki hal-hal yang berkaitan dengan tampilan program, padahal proses dari program itu sendiri belum selesai dikerjakan. Masalah yang sering terjadi juga adalah feature creep, yaitu feature suatu software yang sedang dalam pengembangan bertambah terus, hal ini terjadi biasanya kalau perusahaan yang mempunyai tim pengembang sendiri, sehingga kita sering mendengar perusahaan yang mempunyai tim pengembang waktu pembuatan relatif lebih lama dibanding dengan di buat oleh pengembang luar.
Kadang-kadang pihak manajemen pengembangan software merasa bila proyeknya ingin cepat perlu ditambah orang, pada saat proyek sudah berjalan. Penambahan anggota tim di tengah berlangsungnya suatu proyek dapat menjadi faktor penghambat juga, karena anggota baru tersebut harus dapat menyesuaikan diri pada tim, disamping pengetahuan anggota baru tersebut terhadap proyek yang sedang dikerjakan.

Kesimpulan
Manajemen pengembangan software cukup menarik untuk dikaji, hal diatas masih mencakup seputar cara pengembangan software. Padahal didalam pengembangan software kita juga tidak lepas dari fungsi Quality Assurance. Walaupun sudah mengikuti beberapa cara diatas, tetapi kalau tidak ditunjang dengan QA yang baik, waktu pengerjaan juga akan menjadi lama, yang mengakibatkan time delivery juga menjadi lambat.
Didalam pengembangan software ini ukuran sangatlah penting diperhatikan, dikatakan bahwa “what can be measured can be improved”, sehingga apabila kita ingin memperbaiki cara kita membangun suatu software haruslah kita ketahui ukuran-ukuran apa yang harus diterapkan. Salah mengambil pengukuran akan menjadikan arah pengembangan yang salah pula. Sebagai contoh bila didalam menentukan kualitas adalah jumlah bug yang ditemukan didalam program, jelas ini merupakan suatu ukuran yang tidak tepat. Jadi harus dapat mencari ukuran lain dalam kita menentukan qualitas suatu program.