link: Mananging Consultant

Cari Blog Ini

Jumat, 17 Juni 2011

Google Translate

Using Google Translate From The Command Line

.
 
Submitted by mrashad (Contact Author) (Forums) on Fri, 2011-06-10 18:30. :: Linux

Using Google Translate From The Command Line

 1- Preliminary Note

 
- I'm using "Ojuba 4" Linux ("Fedora 13" based distribution).
- You don't need to be a root user to use this script.

2- What is the situation

I have found an article in one of the most famous Linux Arabic forums, it describes how to use Google Translate from the command line.

3- What is the problem

It is a good script but it is needed to write the language pairs every time and I used to make the computers work for me not to work for computers, so I didn't like to do that write every time I want to use the script, usually I translate from English to Arabic, sometimes from Arabic to English and fewer times form some other languages to Arabic or to English if I found the direct translation from that language to Arabic is not clear enough.

4- The solution

I have edited the script so now it checks the command arguments number, if it is 3 arguments it will use the first as the source language and the second as the destination language and the third is the words to translate.
But if it finds just one argument it will deal with is as the words to translate, and send to Google two times.
First to find out the source language and translate it into Arabic.
Then to find out the source language and translate it into English.
Then it ends.

5- The code itself

Here is the script after my modifications, create a new text file and call it "gtranslate" then copy and paste this code into it:
#!/bin/bash

if [ $# == 3 ]
then
echo "From: $1 To: $2"
lynx -dump "http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&q=$3&langpair=$1|$2"|awk -F'"' '{print $6}'

else
lynx -dump "http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&q=$1&langpair=|ar"|awk -F'"' '{print "From: "$10" To: ar \n"$6}';echo

lynx -dump "http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&q=$1&langpair=|en"|awk -F'"' '{print "From: "$10" To: en \n"$6}';echo

fi
Go to the terminal -command line window- and move to the same location that you saved the script in, then make it executable by doing this:
chmod a+x gtranslate
Then move it to the folder "/usr/bin/" if you have root access, or you can move it to your local bin folder "~/bin/" if your system supports it, otherwise you can move it to your home folder and call it from there directly like this - replace "rashad" with your Linux login name:
/home/rahsad/gtranslate
As you can see, it uses the "lynx" to dump the web page so you will need to install it if you don't have it installed but in that case you will need root user access, like this:
su -c "yum install lynx"

6- A test drive

And here are some examples:
The long/old/original way of use:
gtranslate ar fr "مجتمع لينوكس العربي"
From: ar To: fr
Société arabe pour Linux
The short/new/my way of use:
gtranslate "Société arabe pour Linux"
From: fr To: ar 
الجمعية العربية لينكس

From: fr To: en 
Arab Society for Linux
It works :), but if you can read Arabic you will find that the phrase that I start with "مجتمع لينوكس العربي" is not the same phrase that I got at the end: "الجمعية العربية لينكس" even that I just translate the same result he gave to me, that is one of the reasons that I don't trust the computer translation for all the time.

7- Thank you

Thank you for reading this and thanks for HowToForge to publish.


Belajar Java


Belajar Java Mulai Dari Mana?

(note:posting lama dari blog saya sebelumnya)
Terinspirasi oleh tulisan endy shaya juga mau cerita nih tentang pengalaman belajar java. Setiap orang punya jalab yang unik dalam belajar java, dengan melihat jalan-jalan ini orang yang baru belajar java dapat mengambil pelajaran untuk tidak melakukan kesalahan yang sama, atau dapat mengambil pelajaran yang berharga untuk diikuti.
First involvement in IT and computer
Gw berasal dari generasi yang ketemu dengan komputer primitif dengan 2 buah drive berukuran jumbo, disket 5″. pelajaran yang paling sering gw denger dari guru komputer smp gw adalah :
1. masukkan disket MS-DOS ke drive A,
2. nyalakan komputer, tunggu sampai a:\> muncul dilayar,
3. masukkan disket Word-star ke drive B,
4. ketik a:\>b:, kemudian ketik b:\>ws
Setelah itu anda dapat bekerja menggunakan editor WS, :O
My Early life in IT
Setelah masa-masa primitif komputer di SMP gw masuk ke masa-masa dimana komputer udah punya hardisk (wah ga perlu lagi masukin disket yha? dumb…) yang gw temukan di SMA. gw juga berkenalan dengan internet di SMA ini, setelah itu kena kecanduan chat akut!!
Di SMA gw belajar pascal sedikit-sedikit. pernah tuh di SMA ujian pascal ngerjainya ngasal2an sampe ada temen gw yg ngasih jawaban di lembar ujianya berpola, byar kelihatan keren katanya. misalnya A B C D E D C B A B C D E. yah karena pelajaran komputer ga akan masuk nilai di raport. tapi gw masih semangat, pernah ada kejadian yg agak sedikit memalukan. gw ngerjain soal ujian keterampilan komputer dengan model pilihan berganda cepet banged, ga sampe 30 menit, lha shaya ndak ngerti sama sekali soalnya… trus di depan kelas gw nanya sama ibu guru komputer gw, “bu ini gini yha cara njawabnya?”, ibunya “….” kaenya speechless liat kerjaan amburadul gw…
Saat SMA itu gw udah kecanduan banged sama IT, walau masih bl’oon, dan masih kecanduan ngenet, sampe pernah kelupaan bawa dompet ke warnet… akhirnya nggadein topi… aplikasi pertama yang gw oprek2 adalah jaringan peer-to-peer sharing mp3 penggantinya napster yang ditutup, yaitu gnutella, nggak sukses. karena cuma terbatas dari referensi gw di majalah IT, halah lupa namanya…
Dari SMA gw udah kepincut mau masuk mesin, karena dulu pas SMP nilai ketrampilan otomotif gw 9, dan suka banged oprek-oprek motor Kawasaki-GTO 2 tak punya babe gw, yang sering dipake nyari rumput kambing babe gw yg sekandang ituh. ( yeah dumb reason bwat masuk teknik mesin!!). Akhirnya manteb untuk menggabungkan dua keterkarikan gw dalam pilihan di UMPTN, pilihan pertama teknik mesin ITB, pilihan kedua Ilmu Komputer IPB.
Pas kelas 3 SMA beberapa bimbingan belajar masuk ke SMA gw untuk ngadain try-out gratis, seems that gw bisa pass tuh ke teknik mesin ITB, gimana kalo pilihan pertamanya dinaikin jadi TI ITB, pilihan kedua Teknik Mesin ITB? hmm.. seems doable. eh tapi akhirnya gw tahu juga ternyata di Teknik mesin ituh minim kaum hawanya… wah… masak 7 tahun gw bakalan ndekam di lingkungan minim kaum hawa?
Ternyata kenyataan jg malah memberikan gw pilihan yang jauh lebih sulit, ikut lomba atau UMPTN? kalo ikut lomba gw bisa jalan2 ke bombay + free pass ke IPB jurusan apapun, tapi ga bisa ikut UMPTN? ….hhhh… yah akhirnya gw memutuskan untuk ikut lomba dan melepaskan impian masuk ITB.
Akhirnya ya gini, sampe sekarang masih terdampar di Ilmu Komputer IPB yang gw cintai…
My IT Background
Di Ilmu Komputer IPB bahasa pemrograman pertama yang diajarkan adalah C, khususnya borland Turbo C 2.01, jadi pemahaman gw tentang pointer, Dynamic allocation memory dan Abstract Data Type cukup kuat, hal ini membantu gw memahami konsep class reference dan collection di java.
Perkenalan dengan java pertama kali pada waktu kuliah SBO, sistem berorientasi object, taon 2003. jaman itu sih java masih blom sebesar sekarang, terutama komunitas java. contoh-contoh pemrograman banyak yang menggunakan Java Applet. sekarang jarang deh orang yg nanya-nanya java applet.. :D
Setelah itu lebih banyak berkutat dengan VB dan championship manager… bwahahahah..
VB memberikan konsep databinding, event driven dan RAD yang sangat kuat ke gw. tapi yg gw rasakan paling kuat ketika jadi programmer VB adalah gw ga bisa ngehack VB component sampe dalem-dalemnya, kalo cari di internet, komponen VB rata-rata berbayar. serasa dibelenggu dalam penjara!! mau bikin ini itu ga bisa, cari ini itu di internet bayar!! ada pula pengalaman psoitifnya sperti VB yang menganut model dynamic variable binding memberikan pengalaman pemrograman yang berbeda dibanding C.
Gw juga belajar C++, bahkan waktu kuliah SBO itu gw bikin aplikasi simulasi dashboard mobil pake C++, masa-masa gw harus ngehack metode paint di layar hanya untuk menampilkan tombol!. paintfull!!. gw end up dengan nyaris 5000 line of code waktu dicompile…
Yang lebih parah lagi gw juga belajar Assembly di salah satu mata kuliah, can you emagine coding ratusan baris assembly pake notepad?? yeah that was dumb-me…!! use the simplest tool you can get and ask nobody!!
Gw juga belajar LISP, CLISP, PROLOG, ADA. haduh bahasa2 experimental and low level semua. mungkin karena ini gw masih suka ber-ketik-ketik ria dibanding ber-drag-and-drop, rasanya lebih macho! (endy, 2006)
Di akhir-akhir masa kuliah (hei!! inged lu kan blom lulus dodooll!) gw sempat membuat dua solusi berbeda dengan hasil berbeda pula, yang pertama semacam Point-of-Sales yang mencatat transaksi keluar masuk mobil di rental mobil Sriwijaya di jalan tole iskandar dinata depok, hehehe, dikembangkan menggunakan VB + Crystal report 9. sampe sekarang aplikasi itu masih Up and Running. :D
Aplikasi kedua adalah datawarehouse and reporting service untuk salah satu divisi di TikiJNE, ga sukses, pengembangan aplikasinya paintfull banged, masih blom ngerti query sama sekali, diambil semua datanya trus difilter di dalam array (List) PHP, dumb!. Reportnya menggunakan JPGraph dan FPdf, ini jg paintfull banged, ngepas-ngepasin reportnya pake methode setCellLocation(x,y)… 7 report satu bulan ga kelar!!
Semua pengalaman gw itu membuat gw mulai melirik ke java.
Pengalaman belajar java
Pengalaman kerja pertama gw ga ada hubunganya sama java. maintenance, debug and support financial app yang ditulis pake ASP + Com + Stored Procedure dimana 95% logic ada di T-SQL, ga gitu menarik secara teknologi. Tapi menarik untuk dipahami bahwa teknologi tersebut dapat menjalankan aplikasi dengan load yang sangat tinggi dan digunakan oleh puluhan concurent user. :D
So far sampe titik ini, gw blom punya pengalaman coding java secara extensive, hanya sebatas bikin aplikasi helo world! menggunakan netbeans 5.0 dari cd yang gw dapet di Sun developer day 2005.
Setelah menghadiri acara Sun Developer Day 2005 gw manteb untuk total belajar java, akhirnya gw mendaftarkan diri untuk ikut pelatihan java di brainmatics. Di sanalah gw ketemu Endy yang waktu itu jadi trainernya. Setelah itu gw mulai membaca-baca Java Howto Program dan SCJP preparation test dari Sun secara otodidak. Proses belajarnya hanya sebatas coba-coba dan mengingat-ingat konsep OOP yang dulu gw pelajari pas kuliah.
Di akhir kontrak kerja gw, gw dapet tawaran untuk kerja di badan penelitian kehutanan untuk membantu mengembangkan aplikasi simulasi hutan, SExI-FS, bwahahah namanya keren. Karena aplikasi ini dikembangkan menggunakan Java, gw ga mikir dua kali untuk menerima tawaran ini.
Setelah berhenti dari tempat kerja pertama, gw harus mengunggu proses administrasi dan kontrak kerja dengan tempat kerja baru selama 2 mingguan. Dalam waktu ini gw mati-matian membaca kata-per-kata modul SCJP preparation test dari Sun, karena modul ini menerangkan java language fundamental dengan sangat rinci, gw selingi dengan membaca Java Howto Program untuk latihan coding, yha karena kalo baca teruss ga ada latihan coding bisa bosen.
SCJP Preparation test module terdapat 9 chapter :
Chapter 1. Language Fundamentals
  • Java Programming Language Keywords
  • Literals and Ranges of All Primitive Data Types
  • Array Declaration, Construction, and Initialization
  • Using a Variable or Array Element That Is Uninitialized and Unassigned
  • Command-Line Arguments to Main
Chapter 2. Declarations and Access Control
  • Declarations and Modifiers
  • Declaration Rules
  • Interface Implementation
Chapter 3. Operators and Assignments
  • Java Operators
  • Logical Operators
  • Passing Variables into Methods
Chapter 4. Flow Control, Exceptions, and Assertions
  • Writing Code Using if and switch Statements
  • Writing Code Using Loops
  • Handling Exceptions
  • Working with the Assertion Mechanism
Chapter 5. Object Orientation, Overloading and Overriding,Constructors, and Return Types
  • Benefits of Encapsulation
  • Overridden and Overloaded Methods
  • Constructors and Instantiation
  • Legal Return Types
Chapter 6. Java.lang?The Math Class,Strings, and Wrappers
  • Using the java.lang.String Class
  • Using the java.lang.Math Class
  • Using Wrapper Classes
  • Using the equals() Method with Strings and Wrappers and Objects
Chapter 7. Objects and Collections
  • Overriding hashCode() and equals()
  • Collections
  • Garbage Collection
Chapter 8. Inner Classes
  • Inner Classes
  • Method-Local Inner Classes
  • Anonymous Inner Classes
  • Static Nested Classes
Chapter 9. Threads
  • Defining, Instantiating, and Starting Threads
  • Preventing Thread Execution
  • Synchronizing Code
  • Thread Interaction
Gw pribadi sih ga menyarankan kepada mahasiswa dan newbies untuk mempelajari modul ini secara otodidak, for the sake of your mental healthyness. ada banyak tempat kursus yang menyediakan kursus java language fundamental ini, nama modulnya SL275, lu-lu bisa cari modul ini dengan keyword “SL275 java” di google dan akan mendapatkan banyak search result mengenai materi ini.
Setelah selesai menguasai 9 chapter diatas, kita sudah mempunyai kuda-kuda yang kuat di dunia persilatan java, namun blom siap untuk membuat aplikasi java sama sekali? wow!! padahal 9 chapter itu ada sekitar 500 halaman!!, yup! face it, belajar java itu susah!!. Jika ingin belajar desktop java, kita masih perlu belajar mengenai Swing Component, Trigger-event-listener concept, JDBC, Java I/O dll. makanya Gw imbangi dengan Java Howto program yang sedikit-sedikit membahas swing application.
1 bulan pertama gw struggle beraat untuk get into java world, dan lagi gw harus belajar class-class di JDK + ratusan class library aplikasi SExI-FS. Untungnya ada proses hand-over dari orang yg gw gantiin disini selama 2 minggu. Konsep pertama yang gw pelajari di dunia swing adalah Trigger-event-listener concept dan Swing MVC, sebagai swing programmer konsep ini bisa dibilang kuda-kudanya ilmu swing, kalo nggak ngerti bakalan berdarah-darah develop aplikasi swing.
Hmm, learning curve belajar java memang berat dan panjang, jadi shaya menyarankan untuk setidaknya pernah membaca modul SL275 sebelum terjun kedunia kerja!! itu akan menghemat waktu belajar java di tempat kerja nanti.
Misalnya ada dosen yang membaca postingan ini, yha harapanya SL275 bisa dimasukkan ke dalam kurikulum kuliah, karena bisa menjadi modal yang sangat berharga bagi Fresh Grad yang akan terjun ke dunia kerja. langkah ini darurat sih, karena frans dan kawan-kawan sedang menyusun JENI, Java Edukasi Nasional Indonesia, (bener ga sih singkatanya?)
Ok, ini saran saya untuk memulai belajar java, berdasarkan path belajar java yang gw lalui
Kalo lu masih mahasiswa dan punya duit, ambil kursus SL275, banyak lembaga pelatihan menawarkan paket ini
Kalau gak punya cukup duit, cari buku yang mambahas java language fundamental, sperti Bruce eckle’s Thinking in java, Java Core 1 dan 2. tapi shaya tidak menyarankan Java Howto program.
Setelah java fundamentalnya kuat, cobalah membuat aplikasi kecil untuk belajar sambil membaca buku yang membahas pembuatan aplikasi java, sepeti Java Howto program, atau beberapa buku yang sudah tersedia di gramedia.
Cari kerja sebagai programmer java!! learning by doing is the best way.
Mulailah untuk aktif dalam komunitas java, sperti JUG-Indonesia, netbeans-indonesia atau JLinux. Dalam komunitas ini lu bisa bertanya jika ada kesulitan dan mengetes apakah pemahaman lu terhadap java sudah benar dengan menjawab pertanyaan atau menyatakan opini.
Kitab sakti untuk newbie yang ingin jadi programmer java :
  • Java SE Documentation
  • Java SE Tutorial
  • SL275 modul
  • Tinking in Java by Bruce Eckle
  • Java Education National Indonesia program dari diknas untuk memasukkan java ke dalam kurikulum pendidikan nasional. Sudah banyak materi pembelajaran java dalam bahasa indonesia.
Setelah mempunyai landasan kuat di java language fundamental dan mempunyai pengalaman terlibat dalam java, cobalah untuk mulai berfikir mengikuti Sertifikasi. Ini adalah langkah strategis untuk menaikkan kualitas kita sebagai java programmer.

SOP dan Pembagian Kerja


SOP dan Pembagian Kerja di Software House

Beberapa hari ini ada diskusi seru di milis JUG-indonesia, ada salah satu member JUG yang bertanya bagaimana membuat software house dan melakukan pembagian kerja. Dari satu posting berkembang menjadi panjang lebar sampai puluhan email dalam thread ini. Saya tergelitik untuk merangkup thread tersebut menjadi satu sesi QA agar lebih terurut informasinya.
Nah silahkan menyimak serunya thread ini….
Q : Ada yang bisa share gak gimana SOP dari software house tempat teman-teman? Gimana workflow-nya, dan pembagian tugasnya. Kapan sih orang management dan akuntansi dilibatkan dalam project?
A : Kalo di kantor, qta ada 1 orang head developer, dia yang me-manage proyek dari awal sampe akhir. Ada 1 orang analis + desainer aplikasi (database + modul2), trus ada programmer, trus ada tester/qc
Kalo dulu kerja bareng sama temen, kita bagi2 tugas siapa yang analisis + desain DB, sapa yang bikin SP, Trigger, View, sapa yang bikin front end.
A : Life Cycle project itu kira-kira gini :
1. Cari kabar dimana ada yang perlu aplikasi
2. Kalau ada, janjian untuk mendengarkan requirement
3. Menunjukkan bahwa anda bisa mengerjakan aplikasi sesuai
requirement. Caranya :
- paling gampang tunjukkan portofolio aplikasi yang pernah dibikin
- Paling efektif tunjukkan produk yang sesuai dengan requirement (ini agak sedikit mustahil)
- Presentasikan kembali requirement dalam bahasa yang sedikit lebih teknis
- Presentasikan SDLC dan proses pengembangan aplikasi di perusahaan anda. Gimana requirement gathering, prototyping, demo sampai ke user acceptance test (UAT). Trus garansi, change request management.
4. Biasanya point 2 dan 3 bisa dalam satu sesi meeting, tapi lebih sering sesi 3 dilaksanakan beberapa hari setelah sesi 2
5. Setelah point 3 disetujui biasanya sih ada proses nego harga dan termin pembayaran. Usahakan di termin pembayaran ada DP dan ada step2 pembayaran yang berdurasi pendek, misalnya setiap satu modul selesai dibayar sekian persenya.
6. kalau deal baru mulai developmet.
7. Requirement gathering dengan mewawancara client dan user yang akan menggunakan aplikasinya. Kemudian minta segala macem form, data, dokumen yang di print beserta semua dokumen bisnis.
8. Mulai develop
9. Demo setiap modul, jangan sampai demo di akhir saja untuk semua modul, kalau ada perubahan bisa berdarah2. Release often release fast.
10. Sign off modul yang udah disetujui, minta dibayar :D
11. Implementasi, biasanya ada proses migrasi data dari sistem lama atau dari excell kalau masih manual.
12. Bug fix dan maintenance
13. closing
14. makan2, jangan lupa saya ditraktir :D
Kalau saran saya sih ya, daripada memulai usaha menjadi software consultant mending mulai usaha untuk bikin web 2.0 service, kalau belum bisa secanggih facebook ya bikin seperti kaskus aja tuh, simple aja, install vbuletin :D . Atau bikin produk seperti accurate, zahir dan software untuk pendidikan ;)
Software consultant yang 100% bergantung kepada project base itu sangat rentan, model bisnisnya nggak survive, karena semua usaha kita ujung-ujungnya hanya menghasilkan upah, artinya kita jadi kuli aja. Berbeda halnya kalau km bikin produk, nanti kalau produknya sudah mapan, income tidak lagi bergantung pada berapa baris kode yang kita buat tapi berapa banyak lisensi yang kita buat. Nah kelihatan kan bedanya? kalau konsultant kita dibayar karena keringat yang kita keluarkan, tapi kalau bikin produk ya yang “nyari duit” produk kita. Jadi jerih payah kita terakumulasi ke produk tersebut, nggak bayar lepas seperti project ;) . Saya lihat bisnis model seperti ini cukup terbuka dengan adanya apple app store, bikin aplikasi kecil2 dijual
$1, sebulan kejual 600 buah aja udah cukup lah ya ;) Model bisnis lain yang cukup bagus adalah membuat “service” yang banyak digunakan orang dan bisa kita jual ke pengiklan, sepertidetik.comkaskus.us,indowebster.com dll. Kelemahanya ya butuh investor sih, harus ada yang bayarin bandwith, infrastruktur dll. Di US sana adaycombinator.com/faq.html yang mau nalangin, di indonesia masih blom ada sepertinya :( .
Bisa juga model bisnis “komisi per transaksi” seperti ATM bersama, atau bikin software loket pembayaran PLN, atau bikin marketplace yang transaksinya dikenakan fee. ;)
Bisnis model yang bagus tapi agak susah diimplementasikan adalah software as service (SAS) dengan model subscription, untuk mendapatkan layanan dari aplikasi tersebut, customer perlu membayar sekian rupiah
per satuan waktu (bulan, tahun). Di indonesia yang sudah jalan sepertinyahttp://www.asianbrain.com, cuman lebih ke jualan konten dibanding jualan layanan software. Di luar sana yang terkenal ya
salesforce.com, google application, http://www.fogcreek.com/FogBUGZ/. Bayarnya per user ;)
A : Pembagian perand dalam tim pengembangan perangkat lunak :
1. Tukang nanyain user apa yang mau dibikin
2. Tukang coding level jago, supaya bikinnya gak sembarangan
3. Tukang coding level pemula, supaya ada yang disuruh2 bagian coding yang boring seperti validasi, geser2 tombol, pasang icon, dsb
4. Tukang ngetes
5. Tukang ngurusin hal2 lain supaya tukang no. 1 sampe 4 bisa kerja dengan nyaman Misalnya: reimburse taksi, janjian meeting sama client, laporan progress ke client dan ke bos, cari pengganti kalo ada yang sakit/resign/cuti/dipecat, mengucapkan, “You’re fired” kalo ada yang gak bener
6. Tukang tagih invoice kalau sudah tiba masanya
Versi keren :
1. Business Analyst
2. Software Architect
3. Programmer
4. Tester
5. Project Manager
6. Biasanya sih dikerjain sama no. 5 juga
A : Kalo pengalamannya nol semua rada ribet ya… kalo mau n niat, bisa bikin pake tipe prototipe.
1. Tentuin mo bikin apa, scopenya sampe mana.
2. Kumpulin requirementsnya
3. Desain aplikasi + bikin prototipe
4. Menta komentar dari user, biasanya di sini user bikin ribet, ada requirements yang sebelomnya diomongin tau2 ada. Hal2 gaib terjadi di sini, makanya siapin dokumentasi requirements.
5. balik ke nomer 3, kalo user setuju, aplikasi di deliver.
Kalo ada waktu n produknya umum, aplikasi bisa dikembangin sendiri n disempurnakan.
Yang mesti diinget :
1. Siap2 cape n makan ati, maklum soalnya starter…
2. Jangan mikirin duitnya dulu, tapi pengalaman, produk, sama relasi dulu.
3. Komitmen tiap2 individu agar “perusahaan” jalan.
4. Profesionalitas, bedakan urusan teman sama pekerjaan.
Q : Nah, apa di software house itu ada semacam SOP tertulis, tentang pembagian kerja atau sebagainya? Bagaimana struktur businessnya? Kapan bagian management atau akuntansi ikut gabung?
A : Tergantung software housenya.
Kalau balicamp/sigma setahuku sudah menerapkan CMMi yang mendefinisikan berbagai macam dokumen yang harus dibuat dalam satu project. SOP dan resource management dijelaskan dengan tegas. Tapi kalau software house semacam yang kecil-kecil sih biasanya masih cowboy belum ada process yang jelas, SOP dan dokumen. Paling sih ada template bikin proposal, form untuk requirement, form untuk change request, berita acara UAT / testing, Invoice untuk nagih. Kayaknya udah cukup segitu.
Orang accounting sama management gak dilibatkan dalam project. Paling cuma nanya2 doank tentang konsep accounting, malah kadang2 kita diajarin sama usernya. Kalau buku besar ini begini tablenya, jurnal AR dan AP begini begitu dst.
Kalau di operasional perusahaan biasanya ada bagian administrasi perusahaan yang ngurusi accounting, awal2 cukup pekerjakan lulusan SMK saja untuk membuat dokumen2 di atas.
Q : Trus gimana menentukan lamanya waktu pengerjaan sebuah software misalkan membuat software accounting atau CBI?
A : Ada beberapa cara untuk menentukan project estimation
1. Cara kasar : tentukan deadline berdasarkan kebutuhan bisnis, misalnya: PT A akan memulai usahanya pada juli bulan ini, maka aplikasi harus selesau bulan juni. Pokoknya aplikasi harus selesai, :D
2. Cara Marketing : Ikut tender, terus dengarkan tim lain presentasi, hitung waktu penyelesaianya kirakira 40% lebih cepat dibanding pesaing. Kalau pesaing bilang 5 bulan, ya kita bilang 3 bulan :) ).
3. Cara logis : Tentukan kapan deadlinenya, kemudian tentukan feature apa yang diperlukan agar aplikasi Accounting bisa berjalan. Kemudian bentuk tim, training tim, setup teknologinya. Lalu bersama-sama dengan tim estimasi setiap feature berapa lama bisa dikerjakan. Kalau timnya berisi programmer berpengalaman dan pernah terlibat project development aplikasi serupa, peluang estimasi akurat bisa cukup
tinggi, kalau semuanya belum pernah membuat aplikasi tersebut ya coba tanya sama yang pernah bikin, kalau ada yang nggak tanya ya pura2 jadi mama laurent trus cari hari baik untuk deadline :D
Kalkulasi estimasi project bisa ditentukan dengan berbagai teknik ada yang dihitung berdasarkan table, banyak kolom, banyaknya screen, export-import modul, banyaknya report. Bisa menggunakan semacam poin untuk setiap item yang dihitung. Kemudian dibandingkan dengan history pengerjaan aplikasi, misalnya setelah dirata2 kecepatan pembuatan aplikasi ternyata 3 feature point per orang per hari, trus dari perhitungan feature point dari aplikasi dihasilkan 3000 feature point. Mandaysnya : 3000/3 = 1000 mandays, dikerjakan 5 orang jadinya 200 hari ;)
A : Estimasi pada intinya dibagi menjadi beberapa tahap :
1. Estimasi dulu seberapa besar aplikasi yang akan dibuat. Ada beberapa satuan yang umum digunakan untuk mengukur besarnya aplikasi, diantaranya Function Point dan Line of Code (LOC) LOC lebih akurat, tapi sulit diestimasi di awal project. FP lebih mudah, karena berkaitan langsung dengan requirement.
2. Setelah didapat besarnya aplikasi, estimasi effortnya. Berapa manday yang dibutuhkan untuk menyelesaikan. Perusahaan berpengalaman dan rajin ngumpulin data seperti Balicamp biasanya sudah punya data historis tentang kemampuan pasukannya. Satu FP bisa diselesaikan berapa manday. Nah dengan data ini, tinggal dibagi aja, berapa FP jadinya berapa manday.
3. Setelah manday didapat, estimasi durasi. Durasi adalah jumlah hari kalender untuk membuat aplikasi, satuannya hari kerja. Apa bedanya effort dan durasi? Misalnya satu fitur effortnya 8 manday. Ini belum tentu selesai dalam 1 hari. Mungkin saja durasinya bisa 4 hari, sbb :
2 jam meeting dengan client 2 jam coding.
2 hari clientnya lagi sibuk, sehingga gak bisa ngetes
2 jam UAT, dapat 10 bug
1 hari programmer mules-mules, gak bisa coding.
2 jam fixing
Total effort 8 jam, tapi durasi jadi 5 hari karena ada 2 hari nungguin user dan 1 hari programmer murus.
4. Setelah durasi dapat, baru bisa hitung cost. Misalnya durasi 4 bulan, berarti 4 kali gajian programmer, PM, tester, dsb. Kalo nyebrang lebaran, hitung juga THR, sehingga cost nambah.
Itu sederhananya. Mau yang rumit dan penuh jargon? Coba google function point calculation, wideband delphi, cocomo, planning game. Kalo saya sih yang gampang2 aja dan minim hype. Estimasi itu sederhana, tapi tidak mudah, karena butuh experience.
A : Klo ginian, enaknya dilihat dulu kapasitas team internal-nya spt apa. Maksud saya sih gini, coba lihat 1 orang itu sanggup bikin 1 screen CRUD standart + UI n DB validation brp jam. Nah dr situ dilihat kira2x brp form yg dibutuhin, trs hitung dengan cara yg udah dipaparin ama diatas . Nah masalah dr ngitung berdasarkan kompleksitas screen ini timbul klo misalkan client ga ada aplikasi sebelum-nya (manual abis, masih pakai excel) :D Nah klo udah masuk masalah ini, tergantung PM-nya gmn. Soalnya kadang-2x dr UI yg udah dibuat, ketika deliver iterasi 1 eh user-nya ngomong wah nih UI koq susah banget yah, klo diganti gmn ?? (gubrak ~_~’) Gmn cara ngitung-nya klo spt ini :D ^_^
A : Kalo soal screen design mah harusnya udah di waktu UReq dong, Khan dari requirement kita kasi mock up screen nya kayak apa, Lalu kalo di setujui, ntar kita estimate, bikin screen gituh bisa berapa lama, Nah kadang… consultant company is banking on the user to change their mind :p
Hahahaha
Believe me…
Jadi gitu user minta ganti UI… that’s it!
Time frame nya udah bisa di nego ulang… asal project nya udah di tangan toh?
Satu hal lagi, Buat management, 3000 feature point dengan 30 programmer jadi dalam 100 hari. Tapi apakah 3000 feature point dengan 60 programmer bisa jadi dalan 50 hari? Hal ini yang selalu bikin susah nih…
Q : Seberapa pentingnya kah orang yang benar-benar background marketing di software house?
Lebih menghasilkan mana, marketing online atau offline??
A : Kalau belum bisa gaji orang marketing, mending dikerjakan sendiri.
Kalau di perusahaan2 kecil marketing ini ibarat jantungnya software consulting, ngebul apa nggak dapur tergantung project yang diperoleh marketing.
Kalau masih pure tukang jait dan belum punya keunggulan kompetitif selain harga yang murah, sepertinya offline dengan pendekatan person to person lebih gampang. Kalau online lebih enak punya keunggulan kompetitif, misalnya punya nama yang dah dikenal banyak orang.
Offline dan online juga tergantung bussiness yang mau digarap. Kalau client besar seperti banking, telco, oil & gas dan pertambangan sepertinya lebih pendekatan ke personal. Masalahnya di industri ini cuma cukup untuk pemain-pemain besar saja, perusahaan masih baru mulai sih mana dipercaya.
Kalau mau mulai paling gampang nih, jadi sub kontraktor pengadaan software pemerintah :D . Ini project paling gampang, tapi paling berdarah2. Requirement tidak jelas, termin pembayaran tidak jelas, belum tentu aplikasi digunakan, dst dst.
Pikir-pikir dulu kalau mau bikin software consulting. Lebih enak kalau kerja dulu dan melihat industri apa yang bisa digarap. Kecuali km gak jadi consulting tapi bikin produk/service/framework dll
A : ArtiVisi udah jalan 3 tahun, tanpa ada orang ber-background marketing maupun orang yang dedicated untuk marketing. Nyatanya kita survive, project sih ada aja. Nah, kalo gitu penting gak marketing?
Menurut saya, reputasi lebih penting.
Q : Screen design dilakukan pada waktu UReq dan menghasilkan mock up screen, kalo di setujui, ntar kita estimate, bikin screen gituh bisa berapa lama. Proses ini biasanya software udah deal apa belum ya? sign kontrak dst?
A : Belom dong…
Khan biasa nya step nya tuh die undang buat presentation, Lalu di jelasin scope dasar nya, Ini masi blur nih tapi karna udah ada gambaran nya khan at least kita udah bisa sketch gambar screen, Nothing fancy nothing written on stone Cuma kayak kalo mo load data pasti ada search screen dulu, search screen nya di kasi criteria Cuma yang wildcard searchable di taro di tengah. Ntar ada border warna biru  Gitu2 ajah.
Kalo udah ada patokan ini khan udah ada screen mock up, Semua search screen akan kliatan seperti ini Tapi kalo tiba2 user nya mau ganti, Gak gini deh mau nya pake pop-up search, Lah ya bongkar toh? Ini lho maksud gue. Kalo udah beres screen mock up nya Tar kita kasi proposal, Tampilan nya gimana, Feature2 yang bisa kita throw in apa ajah, Time line nya berapa lama,  Harga nya berapa, Assumptions nya apa ajah, Report nya bisa apa ajah, Mesin nya musti apa ajah, Lalu baru di seleksi lagi, terakhir baru harga.
Nah ideal nya khan semua udah ada waktu nya Kayak tiba2 udah mau deliver user nya minta, wah report ginian gak ada nih, minta dong!, Lah ya kalo Cuma 1-2 ya gpp (mungkin) tapi kalo minta 30-40 report?
Q : Pernah coba terapkan agile methodology? user bisa mengerti methodology ini gak sih?
A : Sayang nya selama ini client2 gue kagak mau ngerti segala methodology ginian. U give the timeline, and I expect a stable product by that date, That’s it!  Hahahaha, Ya gue mah,  lu neken gue teken balik. Gak bole meleset ya lu gak bole banyak minta :p hahahaha
Q : Kalau semuanya masih mahasiswa dan belum pernah sama sekali masuk software house, ada saran ?
A : Disclaimer : Tidak bermaksud meruntuhkan semangat ataupun psywar bagi calon kompetitor ;p
Untuk bisa mendeliver sebuah aplikasi berkualitas production, sangat sulit. Apalagi kalo timnya semua fresh graduate, gak ada yang experienced.
Sebagai gambaran, Martinus bikin aplikasi kasir, Point of Sale, itu cuma 2 hari sudah komplit fiturnya, lengkap dengan print ke dot matrix. Tapi dari situ sampe aplikasi implement dan go live, butuh 3 minggu.
Pesan moralnya, deliver software jauh lebih banyak dari sekedar coding. Ada tarik-tarikan fitur/change, implementasi, training user, nagih invoice, dan urusan non teknis lainnya.
Coding itu sangat gampang, apalagi aplikasi bisnis. Paling cuma insert update delete database, nothing new.
Yang sulit itu :
- estimasi nilai project : butuh pengalaman
- menggali requirement di awal dengan lengkap supaya di belakang gak banyak hidden feature : butuh pengalaman
- mendesain aplikasi supaya adaptif terhadap perubahan : butuh jam terbang
- menerapkan change procedure supaya project tidak melebar : butuh skill negosiasi yang didapat dari pengalaman
Satu lagi, kalo core businessnya project, siap2 puasa berbulan-bulan. Cashflow perusahaan berbasis project sangat unpredictable. Bisa-bisa 4 bulan baru turun 1 termin. Nah selama itu biaya operasional dari mana?
Jadi, apa rekomendasi saya?
Kerja dulu di software house yang sudah mapan dengan tujuan sbb :
- belajar siklus mulai dari sales sampe project closing
- memperluas wawasan business process, misalnya akunting, procurement, dsb
- memperdalam kebijaksanaan dalam mendesain software
- menabung uang untuk modal bikin perusahaan
- menabung relasi untuk modal bikin perusahaan
- menabung reputasi biar gampang dapet orderan
Nanti setelah 2 – 3 tahun kerja, udah tau project dari kepala sampe buntut, baru deh bikin sendiri.
Hmm … jadi ingat thread sebelah tentang lulusan IT ;p
Coba baca ini dulu : http://endy.artivisi.com/blog/life/pengetahuan-wajib-buat-programmer/
Kalo mau buka software house, harus bisa solve problem, bukan cuma bisa coding.
Q : Nah, muncul satu lagi pertanyaan. Ntar yang bagian hubungan sama user, seberapa jauh harus mengerti teknis program yang kita buat?
A: Yang jelas harus ngerti bisnis process, dan ngerti behavior aplikasi yang dibuat. Jadi kalo user punya skenario, misalnya, gimana caranya kalo saya ada diskon dari supplier? Implementor bisa menjelaskan cara aplikasi mengakomodasinya. Bagian mana yang harus dikonfigurasi.
Q : Oia, untuk project management, tanya nih. Software apa saja yang bagus n gratisan yang untuk:
- project manager (misal: MS Project untuk yang punya mikocok)
- uml designer (power designer kan bayar)
- dll yang perlu lagi untuk software house
?
A : Uml jarang dperlukan. Ms project dipake tim yg ada Pm-nya, nggak ada manfaat praktis ke developer.
Yg penting tools itu versioning sistem spt subversion trus issue tracker spt trac atau redmine. Kl 2 itu dipake bnyak bantu developer.
klo emang ingin kerja tim, siapkan build tool yg bisa  ngurusin smua secara otomatis + nanganin masalah dependencies library :)   Nah enaknya lagi, di java ada 2 tool yg keren yaitu :
- Apache Ant (Automatic build tool, didlm ini jg bisa ditambahin custom  task utk kepentingan smua team)
- Apache Ant + Ivy ( Jika digabung ama ivy, bisa automatic dependencies  resolution :) )
- Apache Maven (Udah nge-cover smua yg disebutin diatas :D )
Nah pilih salah 1 aja :) Btw meskipun hal diatas ini kelihatan-nya sepele, tapi pengetahuan tool2x diatas diperlukan biar lebih nyaman klo mau beruusan ama subversion, release dan yg terkait dng versi aplikasi :)
A : Hmm… biasanya sih kita gak pake aplikasi Gantt chart model ginian. Berdasarkan pengalaman, aplikasi Gantt chart seperti ini kurang praktis. Soalnya kita jadi banyak berkutat mikirin dependensi antar task.
Padahal task di software development itu sangat dinamis.
Planning dan tracking di ArtiVisi tidak kompleks. Kita ngikutin fitur yang disediakan trac. Cuma ada milestone dan task. Milestone bisa dikasi tanggal deadline Satu milestone terdiri dari banyak task. Yang manapun task yang dikerjakan duluan tidak masalah.
UML juga tools yang kita gak pake. Mau presentasi class diagram ke siapa? Di ArtiVisi, karena client kita kebanyakan adalah end-user, kita tidak mendiskusikan hal2 teknis dengan client. Kita mau pakai surrogate atau natural key, client tidak perlu mikir. Kita mau pakai 1 tabel atau 10 tabel, bukan urusan client. Kita dibayar karena kita experienced dan bisa mengambil keputusan sendiri berkaitan dengan internal teknologi yang kita gunakan. So, ngapain lagi ngerecoki user dengan urusan jeroan?
Kita diskusi aplikasi dengan client menggunakan prototype UI. Kalo desktop, bikin pakai Swing, kalo web, ya langsung HTMLnya. Client memutuskan what to be built, kita memikirkan how to build.
Tools yang perlu lagi untuk software house :
- version control (kita pakai Subversion)
- Issue/task tracker, lebih sipp kalo ada version control browsernya (kita pakai Trac)
- IDE (kita pakai Netbeans)
- Skype, kita pake fitur share screennya, sangat berguna untuk remote discussion
- Aplikasi Email (Gmail sudah cukup, personally saya pakai TB)
- YM client
Intinya: stay simple, supaya bisa fokus ke kerjaan, bukan tools.
A : UML itu sepengalaman saya cocok digunakan untuk dokumentasi teknik yang dimengerti oleh developer, sedangkan user sebenarnya tidak mengerti UML, kecuali usernya mengerti IT. Kasus user yang mengerti IT
biasanya terjadi di project2 besar, sedangkan project web application, POS atau apliksi transaksi kecil hingga sedang tidak perlu UML. Malah lebih berguna Entity Relation Diagram (ERD).
User yang mengerti IT pun kalau berasal dari lingkungan nonOOP juga tidak familiar dengan UML.
Q : kalau mau manage project bareng-bareng, enak jelasin ke programmernya pake uml. Tentunya pake narasi di diagramnya. begitu ?
Ini adalah sesuatu yang mudah diucapkan tapi sulit dilakukan. Yang namanya programmer, akan lebih memilih coding daripada bikin UML. Soalnya dia akan mikir, daripada bikin UML lama, akan lebih cepat
kalau langsung dicoding. Dan jangan lupa, sesuatu yang dibuat harus dimaintain. Class diagram sih bisa direverse engineer biar tetap up to date, tapi narasinya?
ERD juga sesuatu yang kita gak pake. Gimana cara kita bikin diagram skema database? Bikin dulu aplikasinya, setelah selesai reverse engineer pakai Netbeans.
Kalau sesuatu terdengar indah di kuliah, belum tentu applicable di real project.
ERD, UML, kedengarannya keren dan mudah, kalau class/tabelnya < 10 Di aplikasi nyata, class biasanya > 100 dan tabel biasanya > 20. User management aja sudah 7 tabel sendiri : user, group, user_group,
permission, group_permission, user_session, user_preference.
UML tidak hanya class diagram. Yang lainnya adalah :
- Use Case Diagram : kayaknya terlalu simplistik untuk menjelaskan business process.
- Activity Diagram : ok lah ini mungkin bermanfaat untuk menjelaskanflow, sama aja kayak flowchart
- State Diagram : jarang dipakai kecuali untuk sesuatu yang state berubah misalnya status Order.
- Sequence Diagram : definetely for programmer, melihat invocation stack.
Saya gak bilang UML bad, crap, useless atau apa. Cuma gini aja, UML itu kan cara berkomunikasi. Jadi mau dipakai atau tidak ya tergantung pihak-pihak yang terlibat. Selama ini komunikasi kita lebih efektif dengan prototype screen, ya itu yang kita gunakan.
A : Gua juga pernah mau pakai UML sampai capai-capai baca beberapa buku. Terus latihan. Tapi ujung-ujungnya nggak kepakai. User lebih mengerti narasi dalam bentuk tulisan atau screen mock-up. Kalau menurut gua UML itu berguna sih tapi untuk skala proyek tertentu yang amat besar kalau menurut skala Indonesia. Untuk skala proyek normal di Indonesia UML adalah “overkill”/terlalu berlebihan.
Q : Gimana cara kita bikin diagram skema database?
A : Diagram ERD di kantor saya juga ga dipake, bukan ga mau ngikutin standar, tapi gmana cara bikin ERD untuk 35-40 database, tiap database > 100 tabel & > 50 view, tiap tabel/view kebanyakan > 20 field? Kita bikin desain tabel pake fasilitas diagram punya SQL Server 2000/2005.
Kalo saya dari sisi programmer keluarga DFD, ngeliat aplikasi itu berdasarkan fitur dan data. Fitur yang user mau apa? Data yang mo ditampilin apa? Data yang diinput apa? Nah dari situ baru bikin desain fitur, desain database, dll dsb sampe terakhir coding. Kalo coding dulu baru desain database terakhir ngikutin maunya program bakal lebih ribet pengembangan kedepannya.
A : Klo di tempat saya, urusan database pake ERWIN Data Modeller, support cukup banyak RDBMS.
Disana bisa dipecah-pecah berdasarkan subject area, cuma ya ada kemudahan, ya ada harga.
Jadi biar ada 1000 tabel pun, bisa dikelompokkan berdasarkan subject area. Manfaatnya dapat semua:
- Dokumentasi database
- Reverse / Forward Engineering
- dan mendukung semua fitur database yang disupport.
Ini yang paling basic dulu sih, semua kembali pada kedisplinan dan toleransi yang mengerjakan proyek. Klo gak disiplin jg bakal susah implementasi semua SOP Kerja yang ada, dan kembali ke dunia primitif.
Q : Yang namanya programmer, akan lebih memilih coding daripada bikin UML. Soalnya dia akan mikir, daripada bikin UML lama, akan lebih cepat kalau langsung dicoding. begitu?
A : Maaf kalo saya bilang ini programmer belom pengalaman megang aplikasi besar. Programmer yang pengalaman, dia bakal desain dulu aplikasinya ntar kaya gmana, butuh apa aja (fitur2nya), ada modul apa aja, hubungan antar modul gmana, data yang dibutuhin apa aja, nampilin data apa aja, desain databasenya gmana, kemungkinan evolusi aplikasi ke depannya gmana, permasalahan umum lainnya apa, dsb. Setelah desain udah jadi, baru coding. Kalo programmer yang langsung maen coding aja tanpa bikin desain, jamin deh dimasa depan pas pengembangan aplikasi (tambah fitur, tambah modul, integrasi modul lain) pasti lebih
kelimpungan daripada yang desainnya udah bagus.
A : Hmm.. saya tidak sepenuhnya setuju dengan yang diatas. Di company tempat saya sekarang aplikasi yang dibangun rata2 semuanya kompleks. Tapi di sini gak terpaku pada design formal (ada diagram pun paling oret oret di kertas ato gambar pake power point saja). System yang rumit2 aja docsnya gak perlu sebanyak yang diminta dosen saya waktu jaman mata kuliah Software Engineering.
Menurut saya kalo design yang sampai mendetail itu cocoknya kalau polanya system architect mendesign untuk “dijahit” oleh programmer, maka perlu design yang detail. Di tempat kami programmer semuanya tipe2 yang engineer, jadi design sendiri, coding sendiri, kadang2 konsultasi dengan rekan2, jadi design yang diperlukan cuma garis besarnya saja kira2 programnya mau dibuat bagaimana, sisanya improvisasi dipikir sambil dicoding.
Maintenance hell? Nggak juga, menurut saya malah lebih “agile” dari yang pakai SDLC tradisional – asalkan codingannya bagus dan kebaca, gak perlu design doc yang njelimet koq.
Design database? Kalau buat saya sih baca ERD sama baca schema (dengan asumsi schemanya rapi buatnya), gak banyak bedanya. Jadi perlu ERD kalau mau dikomunikasikan dengan client, dokumentasi, etc. saja. Jangan malah jadi “beban” karena merasa “wajib” buat diagram ini itu.
Jadi menurut saya, design kadang2 perlu, tapi nggak perlu yang extreme2 amat kecuali kalau mau dideliver ke pihak luar.
A : Perhatikan perbedaan antara *tidak melakukan desain* dan *tidak membuat dokumen desain* Yang saya bilang di atas, saya tidak bikin UML, DFD, ERD, and whatever dokumen desain yang orang lain biasa bikin. Lalu apa saya tidak melakukan desain? Tidak juga. Saat ini di ArtiVisi, yang biasanya mendesain aplikasi saya dan Martinus. Gini cara kerjanya.
1. Analisa UI prototype (kami tidak membuat SRS, URS, atau whatever *RS)
2. Tentukan tabel dan relasi (biasanya pada tahap ini cuma nama tabel, PK, dan FK) Ini tidak pakai tools apa2, cukup kertas dan pulpen.
3. Jalankan test scenario untuk berbagai variasi use case menggunakan sampel data sederhana, lihat apakah semua use case, baik untuk saat ini ataupun ke depan, sudah bisa terakomodasi oleh tabel dan relasi.
4. Revisi desain sesuai feedback dari step #3.
5. Repeat until done.
6. Setelah dirasa memuaskan, langsung coding domain class berikut relasinya (@Entity, @ManyToOne, @OneToMany, dsb)
7. Commit, kemudian buang kertasnya, pulpennya jangan.
Lalu apa kami sama sekali tidak pernah bikin gambar skema pakai tools? Pernah juga kadang2. Biasanya teman saya suka minta pendapat saya, atau saya pengen review skema yang dibikin Martinus. Gimana caranya? Generate dulu database pakai hbm2ddl, kemudian reverse engineer jadi diagram pakai whatever tools yang tersedia. Kalo gak ada tools, pakai ini aja
http://teethgrinder.co.uk/database-diagram/
Martinus kirim png ke saya. Saya komentar, kalo ada revisi langsung edit domain model. Regenerate png.
So, skema database itu dibuat secara reverse engineer, untuk keperluan komunikasi.
Begitu selesai, ya dibuang aja itu gambarnya, toh kalo perlu bisa dibikin lagi dengan mudah. Kalo perlu, generate pakai Ant aja dan masukkan ke build process.
Inilah interpretasi kami terhadap prinsip “the source code is the documentation” yang dianut Agile.
Kita tidak menganut pendekatan arsitek bikin gambar, programmer coding. Soalnya software itu dinamis, kalau desainnya pakai dokumen rigid semacam MS Word,nanti capek maintainnya. Kalo tiap nambah field, refactor nama tabel, add/remove relasi harus edit *doc, jaminan gak bakal dikerjain. Sudah jadi human nature males ngerjain gitu2an.
Jadi gini, dokumen itu ada untuk 2 purpose : komunikasi dan dokumentasi. Komunikasi itu untuk ngobrol sama orang lain. Dokumentasi itu untuk meringkas informasi biar gak harus ngetrace source code.
Yang untuk komunikasi, kita generate on demand. Abis komunikasi selesai ya dibuang, gak dimaintain.
Yang untuk dokumentasi, dibikin belakangan, setelah semua coding selesai. Kalo dibikin di depan, repot maintainnya, karena source code belum stabil. Masih banyak refactoring. Idealnya, setelah go live baru bikin dokumentasi. Jadi gak banyak rework. Tapi karena berhubungan dengan invoice, bisa juga dibuat pas UAT dimana perubahan sudah tidak signifikan lagi.
Sekali lagi, gak bikin dokumen desain bukan berarti tidak melakukan desain.
Nah sekarang, yang pada bikin ERD, DFD, UML, saya mau tanya? Kenapa Anda bikin diagram itu? Why? Asal ada manfaatnya no problem. Tapi kalo karena disuruh bos, di kuliah gitu, di buku dianjurkan demikian, think again. Apa gak sebaiknya masa remaja digunakan untuk hal2 yang lebih bermanfaat? :D
Akhirnya saya penasaran sendiri apa bisa diautomate, jadi saya google dan dapat ini :
http://schemaspy.sourceforge.net/
Bisa tuh dari Ant/Maven :
ant generate-skema-db
A : Yg ini bener banget neh.. kebanyakan kerjaan gw cuciin piring orang laen, jadi mana ada dokumentasi UML,ERD atau apapun juga.. Kalo gw milih dokumentasiin itu semua, bisa ga kelar-kelar kerjaan dan kehilangan pekerjaan gw.
Kalo menurut gw seh daripada pusing ngurusin UML dan segala macemnya itu lebih bagus belajar design pattern dulu dah. Buat make library dan mempelajari framework yang baru itu gampang, yg susah itu nerapin design pattern yang bagus buat applikasi kita. Kalo udah capek-capek bikin UML tapi design pattern nya ga diterapin juga pasti di jamin dalam pengembangan applikasinya nanti itu kelimpungan juga. yah kayanya emang UML lebih cocok untuk menjadi alat komunikasi antar programmer aja deh.. :D Gw bayangin presentasiin itu uml ke client gw :D   Bisa di ketawain + di goblok-goblokin + di keluarin Undang-undang garuda tuh..  Mana mo tau mereka urusan begituan.. Client butuh solusi bukan gambar-gambar gituan..
Kesimpulan
K : baru baca thread ini, sop di software house. tp jadinya menarik bahan diskusinya
ada beberapa hal menarik disini, seperti sharing dari Bung Ifma, dan Endy bagaimana mereka menerapkan development process di artivisi, menurut saya itu bagus banget dimana kita harus melihat skala perusahaan dan success level untuk menjadi sebuah result oriented company. tapi memang akan kurang cantik kelihatannya dari sisi documentation, inget technical team hate documentation, jadi rule of the gamenya sah2 aja.
Cerita Adelwin, ureq di indo jika bisa seindah itu…. gw demen banget deh. sayang sepanjang experience di project, belum pernah seindah itu, walaupun bisa sih di manage supaya ontime, tapi balik lagi, kemampuan business analyst, and project manager penting banget dalam hal ini.
about UML and development ini menarik banget untuk saya… karena saya sendiri berangkat dari dunia developer dan analyst dalam bekerja saat ini.
Dalam dunia development banyak yang menggunakan UML sebagai design and documentation. pake use case, class diagram, sequence dan activity diagram. di tempat saya sendiri bekerja saat ini, saya menggunakan UML terutama class diagram sebagai acuan dasar, karena saya menggunakan Model Driven Architecture. dimana class diagram sebagai design dasar untuk pengembangan application. klo ditanya kenapa sih butuh class diagram, kebetulan project kami menggunakan sekitar 200-400 domain model bahkan ada class yang memiliki attribute hingga 200, jadi tools cukup membantu dalam hal ini.
Tapi ada hal yang menarik mengenai diagram lain, seperti usecase dan sequence diagram. dimana diagram2 lain ini dapat dengan mudah digantikan oleh oret2 pencil, powerpoint, prototype maupun user stories. kebetulan sempat menggunakan 2 cara yang agak berbeda dalam menyampaikan apa yang harus dikerjakan developer :
satu team, selalu menggunakan use case scenario lengkap, prototype, hasilnya… programmer kesannya jadi jauh lebih manja, bahkan kemampuan analisa dan logika programmer kurang terasa. di team yang lain, kita mencoba menggunakan oret2 pencil, prototype atau simple scenario dapat juga verbal aja. hasilnya perkembangan developer yang ada, di team ini jauh lebih significant, kemampuan terhadap analisa dan logika lebih baik bahkan mereka tahu apa yang sebenarnya diminta oleh customer. Selain isu sense yang dimiliki oleh programmer bahwa mereka lebih berkembang dan tidak bosan dengan aktivitas mereka jauh lebih bagus dibandingkan dengan team yang lain.Jadi ini lebih kelihat sebagai dinamika team dalam software development :)
K : Wowowow.. ternyata topik ini jadi panjang juga yah. sebagai TS, saya harus berterima kasih nih, banyak ilmu dan pendapat yang saya bisa ambil dari sini.Saya memang newbie sih, belum pernah bikin aplikasi besar. Mungkin bagi yang sudah berpengalaman kayak om Endy, UML itu sudah nggak ada apa-apanya karena proses desain udah manteb di otak, tanpa perlu divisualisasikan. Itu juga dipengaruhi tingkat kerjasama tim dan pengalaman tim itu sendiri.
Tapi bagi saya yang jadi pemimpin tim programmer saya, saya masih perlu UML untuk menyampaikan desain aplikasi saya ke teman-teman. sebenarnya agak susah juga, karena semua harus dipikir di awal, agar nggak banyak perubahan seperti yang om Endy bilang. Tapi memang, efeknya ada bagusnya juga. Pengerjaan jadi lebih cepat karena si programmer nggak perlu susah-susah mikir desain-nya. Tapi ya kayak katanya om Tjiputra, akhirnya jadi males deh si programmer.
Dari sisi dokumentasi, rasanya UML patut diperhitungkan. Sayangnya saya belum ngerti gimana proses reverse engineer itu. Jadinya sekarang ini masih manual bikin UML, terus di share ke anggota, baru kalo ada perubahan ya tambal sulam diagramnya.
Oia, saya nemu tool gratisan yang cukup bagus. Saya pakai Visual Paradigm UML for Community. Itu gratisan juga, meski ada yang versi enterprise. Fiturnya cukup bagus, sayangnya agak lambat di Windows karena dia jalan pake Java.
Salam