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 2010/2/22 Tjiputra Yapeter <tjiput...@gmail.com> > > > 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 :) > > > 2010/2/19 Endy Muhardin <endy.muhar...@gmail.com> > >> 2010/2/19 Niksen Harjanto <milis.java.ko...@gmail.com> >> >> >> > 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. >> > >> >> 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 Martinus 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 >> >> -- >> Endy Muhardin >> http://endy.artivisi.com >> Y! : endymuhardin >> -- life learn contribute -- >> >> >> ------------------------------------ >> >> Kalau mau keluar dari mailing list ini, caranya kirim sebuah email ke >> jug-indonesia-unsubscr...@yahoogroups.com. >> >> Jangan lupa, website JUG Indonesia adalah http://www.jug.or.id >> >> Yahoo! Groups Links >> >> >> >> > > -- HaQQi YM: xp_guitarist Twitter: http://www.twitter.com/haqqi Site: http://www.fauzilhaqqi.net
