Learn the Rules, Break The Rules, and Create the New Ones...

Hi... My name is Rizky Prihanto. You can call me RQ, or Rizky either. I am currently living on Bandung, Indonesia. Had a lot of works and research about Enterprise Information Systems (majoring on education and e-governments). I have bunch of interests (some friends call it 'freakz') about MySQL Opensource Database and now I am one of the administrator of MySQL Indonesia User Group - the opensource community initialized by Sun Microsystems Indonesia.

My Company PT Cinox Media Insani, Bandung, Indonesia. I work here since 2008 and I take responsibility as Chief of Software Architect. My job is about planning, imaginating, fantasy-ing, concepting, and build the infrastructure of the new information systems (or app engines) which going to be implemented.

This blog This is my blog that represent my current opinion, research and experiences about anything in Software Engineering. Written since 2007 (actually) and has been vaccum for a lot of while. And now I wanna ressurrect this blog (optimistically) from the long-long-hibernation with something fresh and new ideas -- still about MySQL, software engineering, development, and may be something managerial here.

About the tagline I've learned the statement above from some paper written by Kent Beck about Extreme Programming (XP) methodology -- some sort of practical software development methods which have no boundaries. That's very inspiring me a lot. I have written some article on this blog that tell my interpretation about that statement here.

My Another Blogs I have classifying my blogs into some sort of genre. The blog that you read here right now is my primary blog that tell you (majoring) about IT stuff. But if you wanna look another side of me, you can visit here, here, here,or here. Hope it'll be interesting for some of you.

Credits I would thanks to Blogger for this great blog platform. Skinpress who designed this Wordpress template (which is bloggerized by Free Blogger Templates). My appreciate is also going to you who give your generously time for visiting my blog.

Dampak Evaluasi Implementasi dalam SDLC

Di facebook gw, ada message di inbox yg berasal dari salah satu friend gw. Isinya *dia nanya* begini :
Maaf baru aja add tp dah repoti

need help u makalah gw, sebenernya sumber kesalahan suaru software tu dari mananya? apakah selalu desainnya, atau mungkin ga implementasinya? need referensi yang sahih buat dasarnya
thx 4 ur att.
Gw bukan mo mengomentari "kenapa beliau ngga nanya via imel aja? tp kenapa lewat FB yg mana fungsi utamanya bukan untuk imel-imel-an, melainkan untuk narcis-narcis-an.." ~ bukan. Gw mo nyoba jawab pertanyaan dia, coz sebenarnya gw juga sering (SERING-BANGEDD) mengalami masalah berupa kesalahan di software yg tim gw bikin, itu sebenarnya karena kita kurang evaluasi di faktor mana-nya?
Kira-kira begini hasil pemikiran gw :


Kalo dirunut-runut, ada beberapa tahap dasar dari sebuah siklus pengembangan sistem (SDLC), yaitu :
  1. Perencanaan
  2. Analisis
  3. Desain
  4. Konstruksi
  5. Implementasi
  6. Maintenance/support
Produk sistem yang dihasilkan itu sendiri, akan dinikmati oleh user di dalam fase IMPLEMENTASI (beda artinya dengan KONSTRUKSI -- walau banyak miskonsepsi mengenai ini dalam materi-materi Rekayasa Perangkat Lunak, bahwa proses "coding" itu adalah proses "implementasi". Bukan! Itu konstruksi.).
Nah, masalahnya -- seperti case yang coba dibedah temen gw tsb, kalo ada kesalahan dalam suatu produk software -- itu yang salah ada di fase mana?
Hmm... jawabannya : semua fase dalam SDLC selalu menimbulkan potensi munculnya sebuah kesalahan.
Yaa, kita ngga perlu membahas kalo programmer juga manusia, punya rasa punya hati, juga punya khilaf ^_^ ~ itu manusiawi. Tapi mari sekali-sekali kita simak bagaimana sebenarnya SDLC itu sendiri. Silakan perhatikan gambar di bawah ini : 
http://qvezst.googlepages.com/sdlc_feedback.JPG


Dari gambar di atas, dapat dideduksikan bahwa sebuah "perulangan" fase terjadi jika : 
  • kesalahan program (error/bug)
  • ketidakcocokan solusi sistem (software) dengan teknologi baru
  • terdapat masalah-masalah dan keperluan bisnis yang baru
  • solusi sistem (software) sudah tidak layak lagi
Untuk proses terjadinya "revisi" karena kesalahan program, step dalam SDLC yang harus di-ulangi adalah di fase KONSTRUKSI. Artinya, perbaiki code atau mungkin coding ulang.
Sedangkan kalo ketidak-cocokan solusi dengan teknologi baru -- misalnya, ekspansi pembayaran cash menjadi pembayaran debit/kartu kredit atau karena upgrading DBMS atau karena pengen dirombak ke platform teknologi terbaru (contohnya, yg tadinya di-coding-in under DOS menjadi di-coding-in under Windows, atau dibikin dari VB6 pengen diganti jadi .NET) -- fase DESAIN harus diulangi dan implikasinya, fase KONSTRUKSI juga harus diulangi.
Kalo terdapat masalah-masalah dan proses bisnis baru? Misalnya: ternyata sistem yg udah terimplementasi dengan baik ini diharuskan TERINTEGRASI dengan sistem di atasnya yg lebih besar; atau terdapat penambahan beberapa requirement baru yang belum terfasilitasi di sistem existing. Kalo itu yang terjadi, proses SDLC mau-ngga-mau harus diulangi dari fase ANALISIS, trus DESAIN lagi, trus CODING lagi deh...

Dan yang paling parah, yg ini nih : ternyata setelah IMPLEMENTASI sekian tahun lamanya, solusi sistem yang terimplementasi di aplikasi existing ini udah bener-bener usang dan ngga layak pakai. Mau tetap dipertahankan untuk dioperasikan, salah. Kalo itu yang terjadi, PERENCANAAN ULANG! ~ tapi, diambil sisi positifnya aja. Perencanaan ulang dan mengulang segalanya dari awal lagi, kan artinya PROJECT BARU. hehehe... loemayan laah daripada loe manyun. ^_^

Sebagaimana lagu PeterPan, memang benar bahwa TAK ADA YANG ABADI. Bahkan sistem dan aplikasi. Tahun 2000 lalu, seiring dengan launching-nya Windows Millennium, Bill Gates mengatakan : DOS udah mati. Sah-sah saja. Ngga ada yang benar-benar perlu disesali.

Kalo dapat komplain dari end-user atau stakeholder pemesan sistem yang kita bangun, syukurilah... Itu artinya kita tetap menjaga relasi dengan dia dan menjaga perputaran siklus development kita tetap berjalan. Stakeholder yang bijaksana, tentunya mengerti sedalam-dalamnya bahwa setiap terjadi perubahan sistem PASCA-IMPLEMENTASI akibat ini-itu, pasti ada biayanya. Dan pada kenyataannya pun, kita sebagai system-developer juga sering mbikin proposal bukan cuman judulnya "proposal pembuatan sistem" atau "proposal pengembangan sistem" -- tapi juga "proposal pemutakhiran sistem". Waaa, sering bangedd nie muncul di Media Indonesia tender-tender di instansi pemerintah yang bertemakan PEMUTAKHIRAN. Artinya : update sistem lama, entah starting point-nya dari re-code, re-design, re-analysis, atau ... REVOLUSI!


_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani

0 comments:

Posting Komentar