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.com, kaskus.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