Menghindari tambal sulam di dalam pengembangan Software

Tadi sore ada pertanyaan soal ini:

Terkadang saya masih bertanya-tanya mas bagaimana sebenarnya desain arsitektur software dan juga database yang baik. Setidaknya, ketika ada pengembangan menjadi lebih mudah utk dikembangkan.
Apalagi kaitannya dengan perubahan atau penambahan struktur database yang terkadang menyebabkan perubahan coding (sering sy alami)

Pertanyaan cukup menarik.

Berdasarkan pengalaman, jangan terburu-buru masuk ke tahap development.

Kekeliruan kebanyakan developer, menurut saya, terlalu prematur tahapan rancangan, langsung lompat ke tahap development.

Saya selalu menghindari hal tersebut, alasannya karena rancangan arsitektur yang tidak matang menyebabkan sistem yang akan dibangun ntar jadi tambal sulam

eh iya ada yang ketinggalan, tambahin dulu deh tabel databasenya”,
waduh, ternyata di tabel lama sudah ada kolomnya, apa direfactoring aja ya…”, jadinya njelimet.

Pahami “Design thinking“. Yaitu, ajak tim melakukan brainstorming, duduk bareng mendefinisikan masalah dan scope pekerjaan, kemudian di-breakdown menjadi task-task, dan duduk bareng dengan orang-orang yang biasa mendesain rancangan arsitektur software, mendesain rancangan database, dan mendesain rancangan antarmuka, melakukan coret-coret UML-nya (use case dan activity diagram), bikin physical data model database-nya, dan coret-coret wireframe/mockup desainnya.

Setelah itu, diskusikan lagi bareng-bareng lebih lanjut, ajak juga si klien, sambil jelaskan design flow sistemnya seperti apa, biar kelihatan nanti kekeliruan mendesain arsitektur software-nya di mana, pemilihan teknologi, service yang dipakai, database yang dipakai, nanti kelihatan semua yang perlu dikoreksi di mana.

Biasanya nanti ada sanggahan dari klien..

Misal “saya gak pengen flownya seperti itu, pengennya seperti ini”, nah ini jangan langsung manut, ajak orang UX, kasih tau UX jaman now untuk software yang dibangun kayak gimana, UX di software/aplikasinya seperti apa.
Paling mudah sih, kasih pembanding, pembanding dengan software serupa yang sudah ada di dunia ini, jadi si klien bisa percaya kalau usulan dia keliru.

Dan terkadang ada sanggahan lagi dari klien terkait teknologi, “wah, pake teknologi itu biayanya mahal ya, uang kami tidak cukup”, nah, untuk kasus yang kayak gini, kasih alternatif teknologi yang gratis misalnya atau yang lebih murah lagi, sambil kasih tau apa kekurangannya jika ada.
Kalau misal nanti ketemu kendala, “wah teknologi yang dipakai kalau yang handal sih X, tapi masalahnya belum punya pengalaman soal itu”, nah yang kayak gini harus pandai memposisikan diri “mau rekrut personil yang ahli di teknologi tersebut” atau “alokasikan waktu dengan tim buat mempelajari” (masing-masing ada resikonya)
Advertisements

Tips buat para klien yang hendak merekrut pekerja TI

Ada banyak sekali permasalahan di dalam manajemen proyek.

Salah satu yang menarik adalah ketika klien salah memilih vendor/tim developer yang menyebabkan project amburadul. Atau karena tim developer baru sadar keliru di dalam merancang design arsitektur software yang sudah terlanjur dibuat.

Dan biasanya ujung-ujungnya dicarilah penyelamat proyek.

Setidaknya sudah lebih dari 3x saya diminta jadi “penyelamat proyek”

Dulu, klien personal dari PLN Sumatera Utara, meminta saya develop aplikasi pelanggan dalam waktu semalam, padahal si klien ini dadakan mengabarkan.

Pernah juga, ada teman yang ditinggal developernya, saya diminta menggarap aplikasi fintech dalam waktu 2 minggu. (Dulu app-nya pernah saya share juga di facebook)

Pernah juga, ada startup marketplace yang sourcecodenya berantakan akhirnya susah dimaintain yang akhirnya meminta saya refactoring code tersebut.

Permasalahan seperti ini akar masalahnya kebanyakan adalah menganggap bahwa membuat software itu tanpa perlu monitoring di setiap prosesnya. Cukup perintah ke developer untuk kerjakan karena merasa sudah bayar mereka. Dan penyebab lainnya adalah keliru menunjuk developer yang ahli di dalam mengatasi permasalahan si klien.

Ingat, developer software di dunia ini banyak sekali, tetapi tidak semuanya ahli atau memahami permasalahan yang dihadapi si klien.

Klien yang awam yang mungkin bisa “dikibulin” developer, si developernya “menggampangkan” permasalahan, padahal ia tidak paham masalahnya. Nah, untuk mencegah hal kayak gini, kudu cari “penasehat” atau “konsultan” yang bisa menilai kemampuan para developer yang direkrut. Karena bisa jadi, developer yang direkrut dikira si klien memang memahami permasalahan, ternyata malah “penurut” dan tidak paham permasalahan sebenarnya. Tidak mampu memberikan “insight” yang tepat buat klien, dll. 

Atau, klien sebaiknya minta tim developer yang direkrut menunjukkan portofolionya, ceritakan portofolionya dan kalau sampai si klien berkata, “nah, ini masalaha saya, mas. Serupa yang pernah mas ceritakan dan mas kerjakan barusan”, berarti kemungkinan besar developer tersebut adalah orang yang tepat.

Dan perlu diperhatikan juga Kunci keberhasilan proyek itu adalah komunikasi, kolaborasi antar stakeholder (end-user, vendor, klien, dll) yang terlibat. Tidak bisa lepas tangan begitu saja, begitu menjelang deadline, baru perhatian dan kocar-kacir cari Superman.

Komunikasi efektifpun bukan komunikasi antara juragan dengan pembantu, atau master dengan slave, atau raja dengan prajurit, melainkan kerjasama, ya kerjasama, saling bekerja bersama-sama mencapai tujuan, menciptakan hubungan baik dan siap beradaptasi dengan segala kondisi atau kendala yang mungkin dihadapi di tengah tahap pengembangan berlangsung (yang sudah pasti tentu tidak slamanya berjalan mulus).

Jika mampu berkolaborasi asik seperti itu, tidak ada lagi masalah ditinggal kabur developer, salah nentuin, krn mesti akan ketahuan di awal.

Tidak Semua Bisa Latah “Agile”, Tergantung Permasalah dan Sikon Perusahaan

eberapa waktu lalu, saya dapat pelajaran berharga dari salah satu perusahaan…

di mana perusahaan ini mengikuti trend yang ada.

“kita akan gunakan agile metodology!”

Sontak yg lain girang “wah, keren nih…itu gw denger metodologi kekinian dlm pengembangan software… waterfall so yesterday”

Lantas, seiring waktu berjalanlah..
yang dianut paham scrum fundamentalist, namun yang terjadi adalah mentalitas kerja yang silo abis.

Tau apa itu mentalitas silo?
Itu loh, contohnya di lembaga pemerintahan, masing-masing lembaga pasang pagar berduri, tidak mau bersinergi satu sama lain, alhasil antar lembaga negara format data dan standarisasinya berbeda-beda…kecenderungan tertutupnya, yang kudu digarisbawahi. Alhasil ketika mencoba mengintegrasikan sistem atau sinkronisasi data menjadi tersendat, yang berakhir membuat database tersendiri yang tidak realtime.

Antar anggota tim dan antar tim di dalam perusahaan tidak memikirkan standarisasi, ada yang bikin database formatnya kayak begini, ada yg bikin backend kayak begitu, ada yangmemanfaatkan komunikasi tim menggunakan tool ini, ada tim lain yang menggunakan tool itu..dan yang terjadi adalah tidak sinkron antar departemen/lembaga di dalam perusahaan.

Ibarat membangun sebuah rumah, masing-masing tim memiliki kamar yang tidak menentu ukuran kamarnya, ukuran pintunya, bentuk pintunya, dll. Jadi semua bergerak sendiri-sendiri. Tidak akan terasa betapa “chaos”-nya nanti pada saat ada yang ngomong “kita mau nyoba nyatuin semua layanan yg dibuat tim A dan B” | “waduh, pak…masalah e tim B bikinnya pake anu..iki aku malah bingung integrasiinnya piye?” | “bikin ulang po?” | “walah”

Jangan heran kalo ada perusahaan yang setiap tahun ganti platform. 😀 

Beberapa waktu lalu saya dapat artikel menarik juga mengenai hal ini, dan mengenai silo busting.
Apa itu silo busting? Secara garis besar silo busting dapat diartikan sebagai bentuk memecah pembatas kolaborasi antar tim/lembaga di dalam perusahaan.

Berikut artikelnya; sila klik tautan

  1. Forget Agile vs Waterfall, It’s Silo Busting.
  2. dan How to boost collaboration.

Mengapa waktu proyek tidak dapat dihitung dengan pasti?

Pengembangan software ataupun aplikasi itu tidak pernah menggunakan ilmu pasti.

Untuk waktu pengerjaan proyek dan biaya proyek juga selalu menggunakan estimasi: estimasi waktu dan estimasi harga.

Di luar sana, selalu menggunakan pendekatan “agile”, di mana interaksi antara tim pengembang dengan tim user ataupun klien lebih penting daripada proses.

Mengapa demikian? dengan kita berinteraksi, persepsi tim pengembang dengan tim “user”/klien akan selalu seirama.
Itulah mengapa terkadang walau sudah kita definisikan rancangan sistem dari “software” ataupun aplikasi di awal, pas di proses terkadang ada saja perubahan atau tidak tepat 100% sesuai dengan rancangan awal, mesti ada yang bergeser. Ini dikarenakan apa yang ditangkap tim pengembang dengan apa yang disampaikan tim “user”/klien ketika menyampaikan “scope” pekerjaan ataupun masalah yang harus diselesaikan, tidak semuanya 100% sama.

Contoh: tim klien meminta dibuatkan rumah yang ada tangganya. Tim developer menerjemahkan maksud dari si tim klien tangga kayu vertikal. Padahal, yang dimaksud tim klien adalah tangga spiral terbuat dari besi (ini contoh sederhana saja).

Jika di awal terlalu detail mendefinisikan semua, yang ada waktu akan banyak terbuang. Itulah mengapa pekerjaan pengembangan software dilakukan bertahap dan ada batas waktu, selanjutnya ya tinggal evaluasi bersama. Dan penting juga bagi tim developer memahami apa masalah klien dan apa solusi yang tepat (tidak harus menuruti 100% keinginan klien, karena terkadang sebenarnya klien juga tidak memahami masalahnya sendiri).

Nah, itulah mengapa pentingnya dipahami bersama jika waktu dan harga proyek itu tidak bulat sama dengan yang direncanakan di awal, mesti ada perubahan, ya lazimnya kalau ada tambahan “task”, di-charge di akhir, biar fair. Atau dibuat per fase, jadi kalau ada pekerjaan tambahan, dilanjutkan di fase kedua (tergantung prioritas).

Demi mencapai hal tersebut, biasanya ada “daily meeting/call”, “weekly meeting/call”, laporan dwi-mingguan, dll. demi mencapai target yang diinginkan agar semua tetap pada tempo-nya, pada prinsip yang sama, dan tetap “on-track” sesuai “task” pekerjaannya.

Tim klien juga harus menyadari, tidak bisa menuntut “loh, kok molor, kan di kontrak kerja targetnya tanggal sekian” | “pak, itu yang di proposal kami dan di kontrak kerja sudah kami sampaikan kalau itu estimasi. Bapak juga mestinya paham, di tengah proses pengembangan kemarin, bapak minta perubahan di bagian form tertentu, itu tentu memakan waktu dan mempengaruhi timeline dari pekerjaan ini. Tidak bisa sama waktunya, pak. Ibarat bapak bangun rumah, bapak minta tambahin garasi mobil, yang sebelumnya minta garasi motor, tentu akan merubah requirement yang sudah disepakati, meskipun sama-sama garasi”.

Di tambah lagi, terkadang di tengah proses, ntah tim klien ataupun tim developer, “discover” sesuatu yang lebih baik, ntah berdasarkan “feedback” dari “end-user”-nya, ntah karena sudah terlihat wujud desainnya, dirasa kurang pas, dan lain sebagainya.

—————————————-

Apakah perubahan di tengah proses dapat diatasi dengan menambah personil? belum tentu, terkadang “transfer knowledge” sampai dengan progress terakhir itu butuh waktu bagi personil baru, dan bahkan untuk “menyamakan tempo” saja butuh keahlian khusus, tidak semua bisa. Paling aman ya waktunya yang bergeser, atau personil baru mengerjakan “task-task minor”.

Oleh karena itu, penting dipahami bersama, masalah waktu dan harga di dalam proyek itu hanya bisa dihitung sebatas estimasi saja (lazimnya seperti itu), dan harus mengetahui resiko-resiko(resiko teknis, “scope” pekerjaan, SDM, man hour, dll) dari setiap keputusan perubahan yang diambil di dalam pengembangan aplikasi atau software.

Port Forwarding In Nintendo Switch

For those who has a problem when playing Splatoon 2 on Nintendo Switch, i think i figured it out the problem.

The problem is when you got NAT type “C” or worst type “E”, you could connecting to Splatoon multiplayer match. The game uses P2P for connection management, and if the required ports is closed, you could join any match in the game. So basically, the NAT type on Nintendo Switch is represent what port and protocol that open for playing this game. If all the required ports and protocol open, you will get NAT type “A”, and if several ports and protocol open, you will get NAT type “B” or “C”, and if the required ports and protocol are close, you will get NAT type “D” or “E”.

So how to upgrade your internet NAT type to NAT “B” or the best “A”?

Here’s the method to do that:

Access your router configurations using web browser (usually on IP: 192.168.1.1), login and search the configuration of “Port-forwarding”. After that, you need to open ports range between 45000 till 65535, and don’t forget to using UDP protocol. Make sure that your port range and protocol input is correct, and then restart your router. And then check your Nintendo Switch Internet connection again. Goodluck!

 

Port-forwarding

Penjelasan Soal NAT di Dalam Nintendo Switch Beserta Penanganannya

Kalo ada orang jaringan (network engineer) di sini mesti bisa jelasin lebih mudah apa itu NAT. Apalagi yang sudah CCNA certified
Jadi begini, apa itu NAT?
NAT atau Network Address Translation adalah suatu metode atau salah satu protocol di dalam jaringan untuk menghubungkan lebih dari satu device ke jaringan internet dengan menggunakan satu alamat IP (melalui router).
Router internetmu akan menggunakan NAT tersebut untuk menyimpan setiap catatan (log) dari semua request device yang terhubung ke jaringan router tersebut, dan kemudian mengirimkan semua request tersebut ke server yang dituju (dalam hal ini server Nintendo) di internet. Request ini kalau dalam game bisa berupa request ID/user ide pemain di dalam game multiplayer, request data pergerakan pemain, dsb. Ketika routermu menerima respon dari server (dari internet), kemudian router tersebut mengirimkan respon-nya ke perangkat yang sesuai. Ya, yang request si Switch yang nerima juga tentu si Switch.
Dengan banyaknya request tersebut dan banyaknya perangkat yang terhubung ke internet dan terutama server Nintendo, untuk itulah diperlukan pengklasifikasian NAT (NAT juga dapat membedakan mana IP public dan mana IP static).
Mengapa pengklasifikasian NAT dilakukan? salah satunya, agar menjamin komunikasi antar device (dalam hal ini Switch) dapat berjalan lancar sesuai dengan type NAT-nya.
Mengapa Nintendo, Sony, dan Microsoft melakukan klasifikasi NAT ini? ya karena beberapa provider internet tidak mengizinkan NAT dibuka (biasanya port diblokir), atau bahkan dibatasi oleh vendor tersebut, jadi kalau NAT-nya gak OPEN ya bakal susah melakukan koneksi ke server.
Nah, di dalam dunia games Nintendo Switch, klasifikasi NAT adalah sebagai berikut:
    1. NAT type A (dalam hal ini OPEN): artinya kamu akan mendapatkan skala 1:1 mapping port di dalam jaringan, koneksi tidak terblokir. Buat nge-game splatoon gak masalah.
    2. NAT type B (dalam hal ini OPEN tapi mengerucut ke MODERATE): artinya koneksi tetap berlangsung dari device ke server namun terjadi di belakang NAT, dalam hal ini console Switch bakal terkoneksi ke server STUN punya Nintendo. Buat nge-game Splatoon mestinya masih OK, gak masalah.
    3. NAT type C (dalam hal ini MODERATE, yang mengerucut ke Strict): artinya koneksi terbatas hanya pada port yang dibuka saja, jadi kalau ada gamer dengan koneksi dan port yang sama ya dapat terhubung. Sayangnya Splatoon menggunakan port yang acak, jadi ya kalau port-nya gak cocok gak bakal bisa konek ke server Splatoon (gak bisa main multiplayer). Buat nge-game Splatoon ya nasib-nasib-an.
    4. NAT type D & E (dalam hal ini STRICT): artinya routernya tidak ada pengaturan NAT, alias sepenuhnya diatur oleh ISP (provider internet-nya), yang model gini biasanya sangat-sangat terbatas.

Klasifikasi NAT
Untuk tipe NAT C sampai dengan B, sebenarnya ada cara dan masih memungkinkan untuk bisa naik ke type A. Karena NAT ini berhubungan dengan settingan Port, maka kamu harus melakukan port-forwarding.
Apa itu port-forwarding?
Fitur dari router di mana fungsi ini akan membuka akses terhadap perangkat pada jaringan lokal untuk bisa diakses dari internet) di router ISP-mu. Bila di console sebelah dikasih tau port berapa aja yang harus dibuka untuk device tertentu, sayangnya di Nintendo Switch sampai saat ini belum diketahui (Nintendo belum memberitahukan port apa saja dan protocol apa saja yang harus dibuka).
Nah, langkah lain adalah membuka semua port untuk koneksi yang masuk dari internet.
Biasanya di pengaturan router ada yang namanya pengaturan NAT type: “full-cone NAT”, yang berarti semua tipe NAT di mana port-nya dibuka secara permanen (OPEN) dan mengizinkan permanently open and mengizinkan semua koneksi dari luar.
Namun, ada beberapa router tidak menyediakan hal tersebut, akan tetapi menyediakan menu untuk pengaturan port-forwarding. Di menu port-forwarding tersebut, kita diminta mengisi IP address device dan port yang ingin dibuka, seperti pada gambar di bawah ini:
Contoh pengaturan PORT FORWARDING untuk console sebelah
Nah, seperti yang sudah dituliskan;disampaikan sebelumnya kalau kita tidak mengetahui port berapa saja yang harus dibuka. (*ada pembaharuan tulisan ini, cek di bawah ya untuk pengaturan port-forwarding di Nintendo Switch)
Untuk itu, pengaturan lain agar dapat mengubah type NAT menjadi OPEN, adalah dengan membuat pengaturan DMZ server.
DMZ atau DeMilitarized Zone sederhananya adalah fitur yang memungkinkan perangkat dibalik router untuk diakses dari internet.
Jadi, kalau tadi kita sudah tahu kalau port-forwarding hanya akan membuka akses sesuai dengan port yang dibuka dan bisa digunakan terhadap beberapa IP, nah sedangkan DMZ akan membuka seluruh port sebuah IP lokal untuk bisa diakses dari internet dan hanya bisa membuka satu ip local saja (satu perangkat, dalam hal ini Switch).
Perlu diperhatikan juga, karena DMZ ini membuka semua port tanpa terkecuali, oleh karena itu jangan sekali-kali membuat koneksi DMZ host untuk PC/laptop, karena akan sangat rawan diserang intruder/cracker. Untuk Switch, sampai saat ini masih relative aman lah.
Bagaimana pengaturan DMZ server di router? Berikut ini langkah-langkahnya:
        1. Login ke routernya: biasanya menggunakan IP 192.168.1.1 (buka dari browser). Atau kalau tidak tahu IP routernya, cek di pengaturan Network di OS PC/Laptop, biasanya ada keterangan IP router/gateway (untuk TCP/IP)
        2. Pilih menu DMZ host atau DMZ server seperti di gambar ini (biasanya di dalam menu Application):

          DMZ Host
        3. Nyalakan Nitendo Switch, masuk ke Pengaturan>Internet, cek Mac Address Switch kamu, seperti pada gambar di bawah ini:
          Cek mac address di Nintendo Switch

          Mengapa menggunakan Mac Address? karena Mac Address ini sifatnya permanen, berbeda dengan IP (apalagi cuma punya IP dinamis) yang berubah-ubah setiap ganti koneksi/restart koneksi. Jadi, tidak perlu setting ulang IP di DMZ Host, karena yang dikenali Mac Address-nya si Switch.

        4. Input MAC Address dari Switch ke DMZ Host dengan cara memberi tanda centang “Enable Mac Mapping” dan mengisi alamat Mac Address Switch tersebut, setelah itu submit.
        5. Jika sudah selesai langkah-langkah di atas, lakukan restart router dan koneksi ulang Switch kamu ke internet rumahmu melalui router tersebut. Semestinya sih dari B bisa naik ke A.

Updated, Port Forwarding:

Bagaimana pengaturan port forwarding di Nintendo Switch?

Berdasarkan informasi yang beredar di forum reddit dan nintendo, port yang harus dibuka untuk koneksi ke server Nintendo adalah dari port 45000 sampai dengan port 65535, dan protocol UDP.
Bagaimana caranya?
  1. Login ke routernya: biasanya menggunakan IP 192.168.1.1 (buka dari browser). Atau kalau tidak tahu IP routernya, cek di pengaturan Network di OS PC/Laptop, biasanya ada keterangan IP router/gateway (untuk TCP/IP)
  2. Masuk ke Menu Application>Port Forwarding seperti pada gambar berikut:

    Menu Port-forwarding
    Menu Port-forwarding
  3.  Centang tombol enable, beri nama, misal “Switch”, Protocol UDP, WAN host IP address start dan end biarkan kosong, kemudian pilih WAN Connection “pppoe_1”, WAN start port, input angka “45000”, dan WAN end port, input angka “65535” (berlaku juga untuk LAN Host port start dan end), kemudian centang “Enable MAC Mapping”, dan masukkan Mac Address Switch (*untuk cara mengetahui mac address switch, cek tulisan di atas ya, dibahas di pengaturan DMZ, atau search aja di tulisan ini dengan mengetik “mac address”). Jika sudah, pastikan yang diinput benar, seperti pada gambar berikut:
    Pengaturan port-forwarding Switch
  4. Tekan tombol “Add”, selesai, selanjutnya restart router dan coba koneksi ulang dari Switch ke Router.
Sekianlah tulisan singkat, semoga bermanfaat.
Referensi :

Pentingnya memahami penamaan “assets” di dalam desain

Apa itu “aset desain” atau Design Assets ?
Aset desain adalah resources tertentu di dalam UI/UX yang digunakan ke dalam proses pengembangan perangkat lunak atau aplikasi.

Apa saja yang termasuk “aset desain”?

Yang termasuk di dalam UI aset desain adalah color palettes(codes/hexa/rgb), styles (tema), icons (icon yang akan dipasang), fonts (font yang digunakan), images (gambar, baik itu background komponen desain, background halaman, banner, gambar header, footer, dsb), animation (animasi transisi halaman), audio (suara ketika klik tombol, dsb), video (video panduan penggunaan software, video iklan) dan setiap elemen yang digunakan untuk memvisualisasikan aplikasi atau software.

Dalam pembahasan kali ini difokuskan mengenai masalah penamaan file, karena ada beberapa kasus di mana designer tidak memberikan nama yang pas untuk assets desain yang ia desain. Alhasil, untuk tracing assets design (misal: icon) ataupun memanggil assetsnya di codingan menjadi membingungkan.

Ditambah lagi, ada beberapa assets design yang nama filenya sama dengan assets design yang lain. Tentu ini akan membuat frustasi developer yang menggunakannya.

Penamaan file di dalam assets design itu sangat penting, itu akan memudahkan designer maupun developer yang akan memindahkan desain ke dalam codingan.

Umumnya, penamaan assets design itu menggunakan prefix, sama halnya dengan penamaan tabel di database, menggunakan prefix atau suffix:
Contoh
ic_email => menandakan ini icon untuk email.
bg_email => menandakan ini background untuk halaman email.
ic_email_selected => menandakan ini icon email ketika dipilih.
ic_email_pressed => menandakan ini icon email ketika ditekan.

Ya, menggunakan prefix ic_ untuk icon, bg_ untuk background, suffix _selected untuk icon yg dipilih, suffix _pressed untuk icon yang ditekan, dan lain sebagainya.

Dan ada pula yang ditaruh ke dalam sub folder tertentu untuk background di dalam folder tersendiri, untuk icon di dalam folder tersendiri, dan lain-lain.

Dengan begitu, manajemen assets design jadi tertata dengan baik