0 Teknik Praktis Analisis Posted on : 2/26/2009 07:20:00 AM

Di Cinox Media Insani, kami sering 'berganti-ganti formasi' dalam setiap pengerjaan sebuah project. Kadang, setelah progress berjalan, developer kami perannya digantikan oleh developer kami yang lain. Hal ini sangat mudah dilakukan karena kami semua mempergunakan framework aplikasi yang sama, dan kami sudah memahami standarisasi code yang ditetapkan oleh perusahaan, juga kami sudah tau karakteristik coding masing-masing rekan yg duduk di samping kami.

Beberapa minggu belakangan, gw melihat sebuah 'potensi baru' dalam tim kami yang solid ini. Gw mo latihan switch-role ke definisi jenjang yang berbeda. Bukan substitusi antar coder, tapi substitusi di level query building, di level art-designing, dan di level architecting. Permasalahan umum-nya yg dihadapi, apakah ada standarisasi di aspek query building, art-designing, dan bahkan architecting? Bukankah hal-hal tersebut adalah aspek-aspek subyektif yang *so-pasti* berbeda klo ditangani oleh orang-orang yang berbeda?

Betul sekali.

Maksut gw sebenarnya bukan substitusi dalam arti di tengah2 permainan sang architect diganti ama architect lain. Bukan begitu. Tapi formasi tempur Cinox pada "starting line-up" nya utk posisi-posisi architect, query-builder, art-designer -- seyogyanya jangan melulu di-isi oleh orang-orang yang sama terus. Bosan. Gag ada variasi-nya. Jadi, maksut gw, substitusi di sini adalah memberikan kesempatan bagi bro-bro dan sis-sis Cinoxers yang lain untuk "ikut merasakan" gimana sengsara-nya jadi Software Architect, atau jadi Art-Designer, atau jadi Query Developer.

Oke, deal!

Project yang jadi 'kelinci percobaan' udah ditentukan. Yang dijadikan case-study adalah aplikasi manajemen penerimaan pajak daerah. Gw lirik-lirik dokumen output yg diharapkan, cukup simpel. Dan gw coba utk project ini, gw hibahkan role Software Architect ke Bro Ali Hanifa. Hehehe.. sekalian belajar buat dia. Udah selayaknya dia naik 'pangkat' jadi Programmer/Analyst mengingat potensi besar yang dia tunjukin "kadang-kadang" udah cukup bagus utk di-upgrade ke level selanjutnya.

Eh, tau-tau... selang beberapa hari setelah dia nyoba ngebikin Spesifikasi Aplikasi, nongol imel dari dia yang isinya *curhat* -- dia kebingungan. BINGOENG ABIEZZ mo mulai nge-trace dari mana, sementara apa yang dia dapat hanya satu bundel format reporting yang diberikan ama Dinas Pendapatan Daerah.

Terlalu raw. Terlalu mentah.

Akhirnya, gw coba share-share dikit tentang teknik praktis analisis sebagai berikut (gw co-pas aja dari imel yg gw tulis utk beliau via milis staff@cinox.co.id) :

Sebenarnya "merumuskan spec" dari data2 mentah seperti format laporan itu adalah fungsi dari Software Architect berpusing-pusing ria di awal. hehehe...

klo data mentah masih kurang menggambarkan requirements? yang (biasa gw) bisa lakukan adalah :

1. tanya ke marketing kita atau "penghubung kita" --> apa sih yg elo janji-in ke client? itu akan jadi patokan dasar pembuatan spec kita. Dokumen kontrak kerjasama sebenarnya harus diberikan ke SA (oke lah, silakan sensor bagian tentang nominal project) -- karena dari situ kita bisa dapatkan scope pekerjaan. Batasan, scope, sampai di garis mana seorang SA boleh berimajinasi tentang struktur aplikasi yg bakal dihasilkan. Jangan sampe, marketing bilang ke client "sampe pendataan pajak" -- eh si S.A. berfantasi sampe ke "Wikimapia untuk informasi subyek pajak secara GIS" hehehe... -- atau sebaliknya. Scope yang dijanjiin sampe di state ini, tp spec yang dibuat ngga nyampae ke sono. Ini berbahaya. Sangat berbahaya.
   
2. bikin prototype trus ajukan ke client, klo begini kurangnya di mana?
3. klo client abstain ato malah bingung dengan spec prototype, kita tanyakan penilaian spec kita ke orang lain yg lebih 'terampil' : pegawai-nya client. Soalnya kebanyakan client itu adalah top-management. Sedangkan kebanyakan aplikasi yg kita bikin itu adalah aplikasi yg bakal dikonsumsi ama level low-management.
4. bingung bikin prototype? pelajarin proposal dan spec orang. Google adalah sahabat Anda.
5. Juga cari referensi apakah ada produk opensource serupa yg pernah dibikin orang? ato walo gag opensource, ada gag produk orang yg ada live-demo-nya? SourceForge.Net adalah kekasih Anda utk urusan beginian..
   
6. baca-baca referensi non-teknis tentang kasus yg dihadapi itu banyak membantu pemahaman kita n mempengaruhi spec yg kita bikin. Misal : undang-undang perpajakan daerah, bacaan2 direktori pajak dari pajak.go.id, artikel2 di koran atau portal berita seputar pajak
7. dan cukup penting juga kita "berteman" ama orang2 yg bergumul dengan tema sistem yg mo kita kembangkan. Misal, gw : punya temen SMA yg skrg kerja di pajak, kerja di depkeu, yg dulu kuliah di FIA Negara atau Ekonomi -- obok2 Facebook & Friendster Anda utk mendapatkan contact teman2 lama Anda...
8. juga, cukup penting juga kita "berteman" ama sesama software developer yang mungkin pernah mbikin sistem/aplikasi serupa. Klo ini, Kaskus room 147, diskusiweb, dan milis-milis komunitas software developer adalah tempat yang tepat untuk scouting.
9. Pengalaman pribadi dalam bikin sistem serupa sebelumnya juga "sangat berharga bangedd" utk membentuk perspektif spec yang akan kita hasilkan.
   

begitulah bro... keep on rolling the eyes..

Untuk kasus aplikasi pajak daerah ini ini, mgkn bro Ali bisa bikin spec utk dinikmati ama Jeng Tika (query), Non Dety (desain), ama Suhu Dendie (coder) dengan berpatokan dari struktur-schema yang akan gw bikinkan. Tapi utk development-lifecycle yg bener, bikin spec IO ama bikin struktur-schema itu adalah responsibility dari SA secara keseluruhan --> karena dalam bikin IO n struktur itu dilakukan secara iteratif n bersamaan. Saling mengevaluasi satu sama lain.

gpp.. kita jadikan ini ajang buat belajar bareng aja.. -- siapatau ntar "dalam perjalanan" kita nge-development, kita bisa dapat pengalaman-pengalaman yg makin mematangkan perspektif kita tentang Software Engineering...

:-)

_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani

1 MySQL & General Public License Posted on : 2/02/2009 02:53:00 AM

Ada diskusi menarik di milis mysql-indonesia@googlegroups.com yang *mempertanyakan* seputar lisensi MySQL yang rada-rada ambigu. Kekhawatiran muncul apabila kita me-rilis aplikasi komersil -- apakah bentrok dengan GPL dan melanggar "kontrak-kontrak sosial" yang udah disepakati di dalamnya?


Adhari C. Mahendra -- tampaknya beliau bekerja di Sun Microsystems Indonesia memberikan tanggapan menarik. Gw co-pas aja conversation mereka di sini :


fansul wrote:

mau tanya tentang license mysql apakah benar2 gratis untuk dipakai
diperusahaan.

License MySQL by default adalah GPL, jadi impactnya, aplikasi yang anda bangun adalah GPL. Sun atau dulunya MySQL AB tidak menarik bayaran atas license, mereka hanya jualan support sekaligus memberikan hak kepada yang membeli support untuk merubah lisensi GPL ke lisensi lain.

Selain itu ada lisensi OEM jika anda hendak menjual branding produk anda yang didalamnya ada MySQL.

soalnya lagi mempertimbangkan mau pakai oracle atau mysql, di cabang2
karena ada rencana merubah program dari ver lama dos ke ver windows
dengan back end mysql/oracle.
klu harus beli, bisa beli dimana dan harganya berapa di hitung per
user atau bagaimana ?
tks.

Kalau anda hendak membeli support MySQL anda bisa menghubungi kantor Sun Microsystems Indonesia di Wisma Metropolitan I Lt 13, minta kontak sales software. Harga support tergantung level dari support yang dibeli dan dihitung per system terserah jumlah user dan jumlah CPU yang dimiliki per systemnya.

***
Ada lagi pendapat dari Abangkis (gw gag bs mengidentifikasikan siapa nama sebenarnya dari Bapak satu ini ^_^) yaitu :

Secara garis besar penggunaan MySQL bisa dibilang gratis. Sedangkan yang dijual oleh Sun adalah Support Subscription/SLA. Dengan membeli Support subscription maka anda akan mendapatkan Support dan beberapa fitur lain seperti :
- update berkala
- binary khusus
- software2 enterprise khusus yang amat membantu untuk memaintain database.
- dll

untuk lebih detailnya bisa dilihat di : http://globalspecials.sun.com/store/mysql/ContentTheme/pbPage.categoryEnterprise

SLA ini dihitung berdasarkan jumlah server, dan merupakan subscription  tahunan. Kalau oracle bisa per user atau per cpu. Untuk harga, bisa dibandingkan sendiri di  http://www.oracle.com/corporate/pricing/pricelists.html. Perbedaannya lumayan jauh :P

Nah kalau kita bicara license, seperti pak adhari bilang, license MySQL adalah GPL. Kalau aplikasi yang anda kembangkan adalah untuk internal perusahaan maka hal ini tidak akan terlalu berpengaruh. Karena source code aplikasi dimiliki oleh perusahaan anda juga.


***

Benar-benar conversation yang menarik. Gw pengen membahas GPL dari sisi "konteks" -- terlepas itu diberlakukan di MySQL atau di produk-produk opensource yang laen. Begini ceritanya...

Berbicara mengenai *gimana sebenarnya* lisensi MySQL untuk produk komersial yg kita bikin, memang sangat membingungkan... Simak pernyataan berikut yang dikutip dari artikel ini :

Q2: Does the FOSS License Exception apply to all Sun software products, including the MySQL database server?

A: No. The FOSS License Exception does not apply to Sun's MySQL database server or any Sun or MySQL software other than the GPL-licensed MySQL Client Libraries. 

 

Q4: Can commercial OEMs, ISVs or VARs combine and distribute commercial products with Sun's GPL-licensed MySQL software under the FOSS License Exception? Does this include the MySQL database server?

A: Distributors of commercial products that combine GPL-licensed MySQL software with commercially licensed software (i.e., software not licensed under a FOSS license) must comply with the terms of the GPL. This includes use and distribution of the GPL-licensed MySQL database
server and MySQL Client Libraries. The FOSS License Exception does not apply with respect to products licensed under any license other than the FOSS licenses listed in the section above titled "FOSS License List."

Di situ dijelaskan bahwa FOSS License hanya berlaku untuk MySQL Client Library. Bukan database-nya. Saya lebih "senang" (atau tenang?) menginterpretasikan masalah lisensi MySQL ini seperti yang Pak Adhari Mahendra dan Pak Abangkis jelaskan di atas. Bahwa aplikasi kita yang mempergunakan MySQL sebagai database/backend itu mempergunakan lisensi GPL ketika di-deploy ke client. Aplikasi GPL tidak selalu harus dibuat dari platform yang GPL juga (misal PHP/Python). Tapi aplikasi yg dibikin dari C++, Delphi, .NET, atau VB juga boleh di-rilis sebagai GPL.

Nah, yang jadi masalah itu sebenarnya adalah *pendapat awam* tentang GPL itu sendiri.. Itu bener2 jadi momok menakutkan bagi para coderpreneur (ini istilah gw sendiri utk "pengusaha" code) : "apakah klo saya makae MySQL, brarti aplikasi saya gag boleh dijual (dikomersilkan) ???" -- dan kebingungan massal ini juga sering dimanfaatkan oleh (calon) customer yang membutuhkan software aplikasi : "ini kan GPL? mestinya gratis donk... mahal amat ngejual-nya?" ^_^

Richard Stallman, pencetus GPL itu sendiri, pernah menganalogikan Open Source dan GPL itu begini : "this is not about FREE BEER. but consider this (open-source) as FREE SPEECH" -- *dalem bangedd maknanya.. Kita berhak memasang harga sebesar-besarnya untuk aplikasi yang kita buat. Karena itu artinya kita telah "bersikap adil" terhadap jerih-payah kita. *hanya saja* -- kalau suatu saat client kita meminta source-code kita, berikanlah... Itu adalah GPL. Kenapa? Dengan GPL, kita sebagai developer sebenarnya dimudahkan, karena *mungkin* yang perlu kita lakukan klo mau membuat custom-build application hanya perlu melakukan refactoring dari aplikasi yang sudah ada. Poin ini sebenarnya juga memiliki nilai investasi lebih bagi stakeholder (client), karena dia ngga perlu "membayar" developer sebelumnya untuk sekedar konsultasi mengenai arsitektur sistem-nya dahulu. Di sisi lain, programmer juga dilindungi "kepemilikannya" -- karena GPL melarang kita memodifikasi tanpa menyertakan credit title author asli di code program. Walaupun hal ini *amat sangat mudah* dihapus oleh developer selanjutnya, tapi kekuatan hukum-nya kuat bangedd apabila developer asli pengen menuntut-nya dengan menyertakan bukti copy asli code aplikasi tsb. (Entah gimana dengan hukum di Indonesia, bisa ngga mengakomodir masalah ini klo suatu ketika ada code yang di-meja-hijau-kan)

Klo interpretasi saya sendiri, IMHO :

1. aplikasi yg dikeluarkan under GPL, itu source-code-nya memang harus diserahkan ke publik. Tapi definisikan "publik" itu sendiri siapa? yaitu client kita... Client berhak dapat source-code dari aplikasi yang dia beli.
2. Kalo developer tetangga -- yang dalam arti lain sama dengan "kompetitor kita" -- boleh ngga "nyontek" source-code dari aplikasi2 yang kita? -- ini pertanyaan rumit. Tapi hadapi saja. Siapapun developer yang pengen tau isi source-code dari aplikasi2 GPL kita, beranikan diri untuk face-to-face datang dan minta sendiri. :P -- dan biarkan idealisme dan harga diri yang berbicara kemudian... ^_^
   
3. Kalo suatu saat definisi publik di poin 1 itu makin melebar ke publik = komunitas atau publik = masyarakat -- buka aja code-nya n taruh di repository publik. Toh, klo emang kita yang bener2 bikin ndiri ntu aplikasi, kita juga bisa bikin ulang lagi aplikasi itu kapanpun kita mau. Kekayaan intelektual kita ngga akan berkurang secuil-pun dengan melakukan hal itu. Malah ada peluang "nambah" -- dengan dapat feedback dari orang2... -- loe pikir, MySQL bisa sebesar ini karena coder-coder di MySQL AB doank apa? Power of community itu sama seperti cara Son Goku mengalahkan Iblis Bhu : mengumpulkan energi manusia se planet bumi dengan BOLA SEMANGAT.
4. Masalah finansial, -- setelah gw pelajari dari pengalaman-pengalaman gw -- ada banyak hal yang ternyata lebih valuable secara finance ketimbang aplikasi gw sendiri : CONTENT dan SUPPORT. Kalo gw bikin web-portal, duit bisa datang dari content (entah iklan, entah isi berita itu sendiri) -- dan kalo gw bikin aplikasi sistem informasi, kue terbanyak dari income adalah dari PELATIHAN, PENDAMPINGAN, dan CONSULTING. Bahkan dengan GPL -- kita bisa saling berbagi kue pelatihan/pendampingan/consulting itu dengan partner developer lain. Kita jadi trainer/consultant dari produk dia, dia jadi trainer/consultant dari produk kita.
   

Gw punya temen yang bijaksana bangedd, dia punya filosofi gini : "Developer Indonesia kalo mau bersaing, bersainglah di sisi materi/finansial -- tapi utk urusan teknologi, sebaiknya saling bahu-membahu" -- dia menyampaikan itu waktu berkunjung ke kantor gw pas malam lailatul qadar bulan ramadhan kemaren. Bener2 ILLUMINATING deh. Dia ngingetin gw lagi tentang apa alasan utama gw terjerembab di dunia code seperti sekarang ini : yaitu mengabdikan code-code gw untuk kemajuan negara ini.

Duit bisa dicari coyy.. - kalo emang kita baik ama orang, orang akan bantu kita -- dan Tuhan sendiri juga akan sayang ama kita...

(eh, makin OOT ya? -- kembali ke laptop deh)

tentang Lisensi MySQL, gw cukup mengutip tulisan di website-nya MySQL ini :

For users or organizations looking to maintain their own solutions, (if) I have :

• My own method of keeping my systems up to date and am comfortable upgrading and configuring MySQL.
• Time to monitor and adjust the MySQL settings that will tune, scale and maintain performance.
• Experience with database security so that I know when a security breach has occurred.
• Experience designing, setting-up and monitoring the status of MySQL replication.
• Time to identify and resolve technical issues for myself and others.
• Time to design and tune application code, database schemas and dynamic queries for optimal performance.

TAKE ME TO THE COMMUNITY DOWNLOADS

yang gw interpretasikan : "yeah, I just only need the Community Edition of that database server..."

Demikian sedikit "curhat" dari saya tentang MySQL Licensing ^_^
-- maaf klo banyak yg OOT atau mencederai perasaan temen-temen... (-_-)
_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani