Dalam hal ini, programer/developer mirip dengan penjahit yang membuat pakaian secara khusus, tugas system analyst dan database administrator dapat diibaratkan dengan desainer pakaian yang merancangnya terlebih dahulu.
Hanya saja, tidak semua software development berjalan dengan mulus. Software terhenti di tengah jalan, dirombak ulang, selesai tapi tidak memuaskan, merupakan cerita-cerita hitam yang bukan jarang-jarang terjadi. Sementara waktu dan materi telah banyak dikorbankan untuk itu.
Hubungi Developer!
Pak Kumis membuka sebuah toko sederhana, saat pelanggan semakin banyak dan penjualan meningkat, Pak Kumis mulai berpikir untuk membuat dan menerapkan sistem komputerisasi untuk mengembangkan bisnisnya.
Jalan pertama yang ingin diambil oleh Pak Kumis tentu jalan yang termurah dan termudah (kalau ada mengapa tidak), Pak Kumis mendengar di Internet banyak terdapat software yang dapat diperoleh dengan cuma-cuma. Maka, dalam waktu relative singkat Pak Kumis telah mengumpulkan cukup banyak software yang berhasil di-download.
Pak Kumis kemudian mencoba software tersebut satu demi satu, ada yang tidak sesuai dengan keinginan Pak Kumis karena terlalu kompleks, sebaliknya ada juga yang terlalu sederhana, ada yang berbahasa asing dan tidak dapat dimengerti, ada yang membuat komputer Pak Kumis hang, dan seterusnya sampai akhirnya tidak ada satupun software yang sesuai.
Akhirnya, Pak Kumis memutuskan untuk menyewa seorang programer/developer yang dapat mewujudkan sistem yang diidamkan oleh Pak Kumis, setelah melalui negosiasi harga yang cukup ketat, maka dimulai pembuatan software kustomisasi atau sering juga disebut tailor made.
Tersedia cukup banyak skenario yang mungkin terjadi menyusul kesepakatan antara Pak Kumis dan pihak developer. Tetapi, hanya ada dua pilihan akhir yang mungkin terjadi, happy ending atau sad ending. Happy ending kalau software buatan sang developer sesuai dengan keinginan Pak Kumis, sad ending kalau software tersebut tidak pernah sesuai dengan keinginan Pak Kumis.
Pada artikel ini, kita akan fokus pada pembahasan sad ending, bukan untuk menceritakan hal-hal yang memprihatinkan, tetapi bagaimana untuk belajar dan menghindari hal tersebut.
Menebak Wajah Software
Pakaian dapat digambar sebelum dibuat sehingga customer dapat membayangkan hasil akhirnya. Sebuah rumah juga dapat dibuat cetak birunya sehingga customer dapat mereka strukturnya, tetapi membayangkan wajah software yang belum ada kadang hampir sama sulitnya dengan membayangkan wajah bayi yang belum dilahirkan.
Tentunya, desain software dapat dibuat agar mampu memberikan gambaran bagaimana wujud software tersebut. Bahkan beberapa customer dapat membuat user requirement sedemikian rupa, lengkap dengan desain tampilan dan alur yang sangat jelas. Tetapi, sebagian customer tidak memiliki bayangan sedikit pun bagaimana mengimplementasikan sistem manualnya ke dalam sistem komputer. Bahkan mungkin tidak juga sepenuhnya memahami desain software yang dibuat oleh system analyst.
Kejadian seperti ini dapat terjadi bahkan dalam ruang lingkup sistem yang relatif kecil, dan kita tidak dapat menyalahkan salah satu pihak jika software yang ingin dibangun gagal untuk didesain terlebih dahulu, yang jelas merupakan sebuah kesalahan besar untuk memaksakan membuat software yang belum diketahui dengan jelas desain sistemnya.
Menyamakan persepsi akan sistem yang akan dibangun merupakan suatu proses yang relatif dapat berlangsung cukup lama, dikarenakan pihak customer dan developer harus berkolaborasi menyusun sistem tersebut. Dari sisi developer, tentunya sudah memiliki background pengetahuan tahap-tahap pengembangan software, bagaimana siklus hidup software, dan seterusnya. Sedangkan dari sisi customer, memiliki pengetahuan mengenai proses bisnis yang digelutinya.
Mempertemukan dua hal ini merupakan awal yang sangat menentukan untuk melahirkan software yang sesuai. Tetapi, untuk menyatukannya tidak semudah membalikkan telapak tangan, bisa diakibatkan karena background yang berbeda serta tingkat komunikasi yang kurang baik.
Komunikasi merupakan bagian penting agar sebuah kerja sama dapat berjalan dengan baik, skill teknikal yang luar biasa tidak menjamin developer selalu mampu menghasilkan software yang dibutuhkan. Sebaliknya juga komunikasi yang baik jika tidak didukung dengan teknikal yang memadai, tidak akan menghasilkan produk yang memuaskan.
Untuk bersama-sama menghasilkan gambaran software yang akan di-develop, ada kalanya diperlukan pihak konsultan teknologi informasi (IT Consultant) untuk menjembatani antara customer dan developer. Konsultan tersebut harus memahami proses bisnis customer dan mampu menyarankan solusi TI yang perlu dikembangkan oleh developer.
Developer atau Konsultan?
Sering terdapat kerancuan antara tugas developer dan konsultan. Beberapa customer memiliki anggapan bahwa pihak developer harus bertugas dan berlaku sebagai konsultan bisnisnya, selain tentunya membuat program.
Hal ini kadang kala berbuntut dengan kerugian bagi kedua belah pihak. Hal pertama karena pihak developer seharusnya tidak merangkap sebagai IT consultant tanpa kesepakatan yang jelas, hal kedua karena pihak developer belum tentu memahami sudut pandang customer dari sisi bisnis dan kebutuhan.
Karena itu jika pihak developer merangkap sebagai konsultan, maka pihak developer harus memiliki kapasitas sebagai konsultan dan perlu dipahami oleh customer bahwa proses konsultasi dan proses development merupakan dua proses dan tanggung-jawab yang terpisah.
Pihak konsultan juga dapat merupakan pihak ketiga yang disewa oleh customer untuk membantu mengembangkan bisnisnya. Solusi yang ditawarkan tidak selalu merupakan pengembangan software, tetapi juga dapat berupa perbaikan infrastruktur, penggunaan teknologi tertentu, peningkatan keamanan sistem, dan seterusnya.
Metodologi
Sebuah metologi pengembangan sistem software dapat dijadikan sebagai patokan developer untuk melakukan tahap-tahap pembuatan software. Metodologi yang umum dikenal adalah System Development Life Cycle (biasa disingkat DSLC atau SLC) yang didefinisikan US Departement of Justice. SDLC menjelaskan tahapan pembuatan software, di antaranya adalah perencanaan, analisis, desain, development, testing, deployment, implementasi, dan maintenance. Idealnya SDLC diharapkan menghasilkan sistem berkualitas yang memenuhi (atau kalau perlu melebihi) harapan customer dan sesuai dengan estimasi biaya dan waktu.
Sebuah metodologi lainnya adalah Extreme Programming atau disingkat XP di http://www.extremeprogramming.org, yang membagi tahapan ke dalam empat bagian besar, yaitu Planning, Designing, Coding, dan Testing. XP menekankan peran customer sebagai bagian dari keberhasilan sistem. Tentunya bukan bertugas sebagai developer, tetapi untuk berperan serta menuliskan skenario (User Stories) tanpa harus menggunakan istilah teknis. User stories ini nantinya akan mengarah pada User Acceptance Test (UAT).
Bagaimanapun, SDLC dan metodologi lainnya hanya merupakan sebuah alat bantu untuk mengarahkan pengembangan sistem yang baik. Di dalam perjalanan pengembangan software tersebut, sering kali terdapat berbagai kendala, terutama di dalam sistem yang besar dan terbagi-bagi atas beragam subsistem.
Software Tambal Sulam
Berikut ini adalah cerita yang cukup umum terjadi. Seorang developer datang ke kantor customer dan melakukan entah instalasi, perbaikan bug, ataupun maintenance rutin. Customer kemudian meminta developer untuk menambahkan suatu modul ringan, developer yang kebetulan memiliki source code software tersebut kemudian mendemonstrasikan kepiawaiannya dengan membuat modul tersebut hanya dalam hitungan menit.
System Development Life Cycle.
Kadang kala untuk membuat modul ringan tersebut, developer mengambil jalan pintas yang termudah, dengan tujuan utama adalah menghasilkan modul yang diminta dengan cepat, tanpa harus banyak mengubah kode program. Tetapi, sangat disayangkan jika untuk mencapai hal tersebut, developer mengabaikan konsep dan prinsip software development yang seharusnya diketahuinya.
Praktik seperti ini, baik dalam skala kecil maupun besar akhirnya dapat merugikan developer maupun customer. Pihak customer harus memiliki pengertian bahwa perubahan modul kecil pada sistem sering kali bukanlah sebuah pekerjaan kecil, dan pihak developer harus tetap berpegang pada desain system yang benar.
Jangan ragu-ragu untuk kembali pada metodologi awal yang digunakan. Sebuah requirement baru biasanya akan melahirkan perencanaan yang baru, dan bisa jadi mengubah estimasi waktu dan biaya awal.
Perubahan Spesifikasi
Cukup umum terjadi, desain yang telah dirancang pada awalnya kemudian harus diubah karena berbagai sebab. Bisa jadi karena terdapat kasus-kasus yang tidak terpikirkan sebelumnya, ataupun dikarenakan perubahan kebijaksanaan yang dilakukan customer terhadap proses bisnisnya, dan seterusnya.
Saat hal ini terjadi, komunikasi yang baik akan memegang peranan yang sangat penting. Karena sering kali customer dan developer sama-sama merasa rugi dan tidak mau disalahkan atas terjadinya perubahan spesifikasi sistem.
Karena itu, jauh sebelum pihak customer dan developer mencapai kata sepakat, sebelumnya perlu dipahami bahwa iterasi atau pengulangan merupakan hal yang sangat wajar pada pengembangan software. Termasuk pengulangan requirement, perencanaan, dan bisa jadi mempengaruhi estimasi biaya dan waktu.
Jika salah satu pihak tidak siap dengan hal tersebut, maka pihak tersebut juga belum siap untuk melahirkan sebuah sistem.
Implementasi
Saat software telah mencapai tahap akhir development dan akan masuk pada tahap production, jangan buru-buru membuat setup installer software yang rapi karena bisa jadi masih akan terjadi cukup banyak perubahan saat dipergunakan end user.
Karena itu, perencanaan sistem yang baik tentunya telah memperhitungkan level pengguna, dari pihak customer juga harus mampu memberikan deskripsi detail kebutuhan-kebutuhan user.
Jika end user merupakan staf perusahaan yang harus mengoperasikan sistem tersebut, maka dapat terjadi perubahan cara kerja yang cukup signifi kan. Sering kali implementasi awal system memerlukan proses manual dan proses komputerisasi berjalan secara paralel untuk menguji sistem.
Tentunya, dari pihak developer harus terlebih dahulu melakukan tes hingga pada unit terkecil untuk mengurangi tingkat kegagalan sistem saat implementasi. Berubahnya rutinitas kerja terkadang dikeluhkan oleh user yang merasa pekerjaannya bertambah (tetapi gaji tidak bertambah), sementara keberhasilan suatu sistem harus didukung sepenuhnya oleh pihak-pihak terkait, termasuk pengguna sistem tersebut.
Karena itu, diperlukan pengarahan dan training yang mendukung user untuk menggunakan sistem dengan nyaman dan memberikan pengertian bahwa sistem diciptakan justru akan membantu pekerjaan manual dan memperbaiki sistem yang lama.
Penutup
Dari awal hingga akhir software development, cobaan terbesar pada umumnya adalah menghadapi iterasi atau pengulangan. Biasanya proyek yang tidak selesai adalah sistem yang terhenti pada suatu titik bukan karena ketidaksanggupan untuk melanjutkan development secara teknis (walaupun mungkin saja terjadi pada beberapa kasus tertentu), tetapi karena berputar-putar dalam sebuah lingkaran karena adanya konflik kepentingan. Salah satu buah simalakama yang sering terjadi adalah sebagai berikut:
Developer memiliki pengetahuan, prosedur, dan tools yang baik untuk membangun sistem komputerisasi yang baik, memenuhi standar pengembangan software sesuai dengan buku teks dan literatur.
Di pihak lain, calon customer tidak selalu datang dari background teknologi informasi, mungkin memiliki budget relative rendah, dengan skala bisnis menengah ke bawah. Sering kali yang dikejar kedua pihak adalah kata deal, di mana developer mungkin akhirnya menawarkan biaya murah tetapi bertekad membuat software secara instan, atau pihak customer menyanggupi biaya yang diajukan tetapi menuntut sistem harus memuaskan tanpa kriteria yang jelas. Salah satu solusinya adalah dengan menerapkan software development dimulai dari skala dan modul yang terbatas, dimana budget dapat diterima dan kualitas software dapat dipertanggungjawabkan.
Kesuksesan sebuah software tercermin dari penggunaan software itu sendiri, dimulai dari skala yang relatif kecil.
Sebuah contoh yang jelas adalah operating system Windows Vista saat ini, bukankah merupakan hasil perjalanan panjang dari sistem operasi MS-DOS yang demikian sederhana dibandingkan Windows Vista?
Software development dibuat untuk melahirkan sebuah sistem yang lebih baik, karena itu sudah seharusnya software development menjadi merupakan perjalanan yang menyenangkan baik bagi developer, customer, dan pengguna.
No comments:
Post a Comment