Saturday 25 January 2014

Pengamanan (Security) pada Komunikasi Data

Tujuan dari tulisan ini, lebih kurang akan memberikan gambaran yang cukup sederhana mengenai aspek pengamanan, jika kita ingin membangun sebuah solusi yang menuntut adanya komunikasi data antar sistem atau institusi. Tulisan ini tidak menyajikan aspek teknis yang cukup detail, tetapi mencoba mengkaji beberapa hal yang akan menciptakan keamanan yang optimal bagi data atau informasi yang kita memiliki terutama pada saat data atau informasi tersebut harus kita kirimkan ke institusi yang lain.

Kita sering menjumpai suatu kondisi dimana proyek perangkat lunak, lebih banyak berdiskusi tentang functional design dari aplikasi yang sedang dikembangkan. Sementara itu, diskusi mengenai aspek pengamanan terkadang luput dari item yang seharusnya menjadi kunci jika aplikasi yang sedang kita kembangkan berkaitan dengan komunikasi data dengan pihak luar, baik interaksi dengan menggunakan internet atau komunikasi yang dedicated host-to-host.

Terdapat beberapa item pengamanan yang harus kita perhatikan atau kita pertanyakan dalam setiap proyek yang melibatkan komunikasi dengan pihak luar. Tujuan utama dari tulisan ini adalah, kita mencoba melihat topik atau item apa saja yang harus kita perhatikan dalam pengamanan data kita dan pilihan pengamanan yang ada dalam rekayasa perangkat lunak.

Tujuan Pengamanan Data

Dalam pengaman, kita akan berhubungan dengan koncep yang sering kita sebut Cryptography. Cryptography adalah sebuah study atau kajian praktis dalam menggunakan teknik matematika atau lebih dikenal sebagai algoritma untuk mengamankan data atau informasi yang kita miliki.

Dalam cryptography, ada beberapa mekanisme atau tujuan yang ingin kita capai dalam pengamanan data/informasi. Secara sederhana, makna atau tujuan dari sebuah pengamanan data memiliki 4 hal, yaitu data integrity, confidentiality, authentication dan non-repudiation.

Data Integrity Data integrity dalam cryptography adalah sebuah mekanisme untuk menjamin bahwa data yang kita transfer atau kirimkan dari satu titik ke titik lainnya tidak akan mengalami perubahan selama proses transmisi. Jika kita mengirimkan sebuah berita untuk "kiriman uang sejumlah satu juta rupiah", kita tentu berharap data tersebut tidak mengalami perubahan selama proses transmisi. Sangat tidak diharapkan, jika kemudian berita tersebut berubah selama proses transmisi menjadi "kiriman uang sejumlah lima juta rupiah". 
Ilmu cryptography mencoba menciptakan mekanisme untuk menjamin sang penerima berita bahwa data yang telah dia terima tidak mengalami perubahan selama perjalanannya.

Confidentiality
Kita tidak dapat mencegah orang lain untuk "mencuri" data yang kita miliki, baik tercuri pada saat transmisi maupun dari tempat penyimpanan data. Cryptography mengkaji bagaimana agar data yang kita miliki hanya dapat dimengerti oleh pihak-pihak yang berkepentingan. Layaknya sebuah sandi atau kode rahasia dalam surat yang kita kirimkan kepada pihak luar. Dengan menuliskan informasi yang kita miliki dengan menggunakan sandi atau kode rahasia, maka kita berharap jika seandainya data kita tercuri, pihak yang mencoba melakukan niat jahat ini tetap tidak akan berhasil untuk mengerti isi dari berita yang kita kirimkan.

Authentication
Pada saat kita menerima surat, dokumen atau berita dari pihak lain, pernahkah kita bertanya bahwa pengirim berita tersebut sebenarnya telah dikirimkan oleh orang lain dengan menggunakan nama yang kita kenal. Dalam keseharian, kita sering menggunakan tanda tangan secara cara untuk melihat apakah sebuah surat benar-benar dari pihak yang kita harapkan. Tetapi kita akan tetap memiliki kesulitan untuk benar-benar menjamin apakah tanda tangan tersebut adalah otentik atau palsu. Cryptography mencoba memberikan beberapa alternatif solusi untuk melakukan identifikasi apakah sang pengirim adalah otentik atau pengirim palsu.

Non-Repudiation
Pada saat kita menerima sebuah dokumen atau berita, kita terkadang langsung meng-eksekusi berita tersebut. Tetapi kemudian, pihak pengirim mengatakan bahwa dia tidak pernah merasa mengirim berita yang kita maksudkan. Dalam Cryptography, terdapat kajian untuk meminimalkan situasi seperti ini, dengan mengenalkan konsep non-repudiation.


Metode/Teknik Pengaman Informasi

Setelah kita mengetahui secara garis besar tujuan dari Cryptography, mari kita melihat secara sederhana mengenai teknik pengaman atau dikenal dengan Cryptography Primitive. Cryptography Primitive adalah algorima matematika atau kumpulan instruksi yang dapat kita gunakan untuk mengamankan data atau informasi yang kita miliki.

Encryption
adalah sebuah proses untuk melakukan transformasi dari sebuah "plaintext" (text atau data yang dapat dibaca dan dimengerti) menjadi sesuatu yang tidak bisa dimengerti kecuali pihak yang kita inginkan. Umumnya akan menggunakan kunci-kunci (key) tertentu untuk melakukan ini.

Gambar di bawah ini contoh yang cukup sederhana dari implementasi "encryption". Jika saya ingin mengirimkan data "Kusuma", saya mencoba untuk meng-encrypt data saya dengan cara menggeser urutan abjad. Dalam hal ini, saya menggunakan kunci(key) yang bernilai "2". Huruf "K", jika saya geser 2 langkah dari abjad, akan menjadi huruf "M". 


Tentu saya, ilmu Cryptography memiliki algoritma yang jauh lebih komplek dan rumit. Yang saya coba tampilkan disini adalah sebuah contoh sederhana mengenail enkripsi data. Teknik ini, dapat kita gunakan untuk mewujudkan salah satu tujuan dari funsi cryptography yang telah kita lihat sebelumnya, yaitu "confidentiality". Jika akhirnya data ini tercuri oleh pihak lain, mereka tetap akan kesulitan untuk mengerti makna dari berita tersebut.

Hash Function
Sebuah fungsi matematika yang melakukan konversi dari sekumpulan data/text yang panjang menjadi sebuah kode tertentu. Teknik ini menggunakan formula matematika yang cukup komplek. Seluruh isi berita yang kita miliki akan digunakan sebagai input pada saat formula ini dijalankan. Formula ini kemudian akan menghasilkan kode tertentu (dalam contoh gambar di bawah ini, menghasilkan kode dalam 6 digit). Kode 6 digit ini kemudian yang kita kenal sebagai Hash Number.


Dalam implementasi komunikasi data, kita dapat menyertakan kode Hash Number ini sebagai attachment atau sebagai trailer/header dari berita yang kita kirimkan. Dalam komunikasi data kita mengenal istilah "envelope" dalam komunikasi data untuk membedakan antara berita yang kita kirimkan dengan informasi tambahan mengenai surat kita. Dalam keseharian, kita sering membungkus surat kita dengan amplop, dimana amplop digunakan untuk memberikan informasi mengenai penerima, alamatnya dan informasi lainnya (misal apakah ini kiriman kilat, rahasia dan lain-lain).

Kode HASH ini, dapat kita gunakan dalam rangka implementasi "Data Integrity" yang menjadi salah satu tujuan dalam cryptography. Pada saat kita menerima berita di aplikasi kita, kode hash ini akan kita coba hitung ulang untuk memastikan bahwa data tidak berubah selama proses transmisi.

Terkadang juga kita pernah mendengar istilah 'CHECKSUM' yang memiliki kesamaan dengan konsep HASH ini. Pada saat kita akan men-download sebuah file dari internet, penyedia file terkadang mencantumkan kode checksum, sehingga kita dapat mengidentifikasi atau yakin bahwa hasil download file kita adalah valid.

Message Authentication Code (MAC)
Metode ini hampir sama dengan metode HASH, tetapi akan menggunakan kunci atau key tertentu dalam proses perhitungannya. Untuk memberikan pengamanan yang lebih kuat, kita dapat menambah kunci (key) sebagai input tambahan dari formula atau algoritma Hash. Key ini akan tersimpan pada setiap pihak yang punya kepentingan terhadap data tersebut. Key ini, juga bisa bersifat bilateral yang hanya berlaku antara dua pihak.

Dengan adanya tambahan key atau kunci ini, kita juga bisa menjamin proses "Authentication" yang menjadi salah satu tujuan cryptography. Hal ini karena, kita meyakini bahwa kunci ini hanya berlaku dalam kalangan terbatas.


Pada saat, kita menerima berita dengan tambahan MAC, kita dapat menjamin bahwa data tidak mengalami perubahan selama transmisi dan kita juga yakin bahwa data tersebut dari orang yang kita kenali karena memiliki kunci yang telah disepakati.

Digital Signature
Adalah mekanisme atau algoritma untuk menunjukan otentikasi terhadap sebuah data atau dokumen digital. Beberapa algoritma yang kita kenal seperti RSA, DSA, ECDSA, ElGamal.

Dalam teknik ini, kita akan mengenail adanya "Private Key" dan "Public Key". Konsep yang sederhana adalah, pada saat sebuah data terbungkus oleh apmplop yang dikunci dengan "Private Key", maka hanya orang yang memiliki "pasangan Public Key" yang dapat membukanya. Sebelum implementasi ini, semua pihak akan membuat pasangan kunci "Private" dan "Public". "Private Key" akan disimpan dalam kondisi yang paling aman oleh pemiliknya. Sedangkan "Public Key" akan diberika kepada pihak-pihak dalam kalangan terbatas.


Sesuai dengan namanya, teknik ini digunakan untuk menjamin bahwa berita yang kita terima berasal dari orang yang otentik. Karena berita ini tadinya terkunci oleh sebuah private key yang dimiliki oleh satu pihak tertentu dan kita menggunakan sebuah public key yang kita terima dari pihak tertentu. Dengan metode algoritma tertentu, data tersebut dapat terbuka dengan menggunakan public key yang kita miliki.

Mekanisme ini, juga dapat digunakan untuk "non-repudiation", karena kita menjamin bahwa hanya satu orang yang memiliki private key dan private key adalah sesuatu yang unik dan tersimpan dengan baik oleh pemiliknya.


--------
Link:
Topik tentang mengenai kehidupan di Singapura: Kehidupan di Singapura 
Topik tentang mengenali teknologi informasi: Mengenali Teknologi Informasi


Semoga Bermanfaat
Singapore, Januari 2014
"Di publish dari dalam Tampines Library, sambil menunggu anak saya yang sedang mengikuti kegiatan tidak jauh dari perpustakaan ini."



Friday 24 January 2014

Bekerja dan Hidup di Singapura

Kemungkinan di antara kita sedang menjalani interview atau sedang mencoba untuk mencari pekerjaan di luar negeri. Tulisan ini mencoba untuk memberikan semacam gambaran bagaimana proses awal hingga sekilas kehidupan yang saya jalani selama bekerja di Singapura serta memberikan beberapa fakta official tentang Singapura.

Awalnya saya tidak pernah memiliki cita-cita atau angan-angan untuk bekerja di luar negeri. Jangan tanyakan berapa score TOEFL saya, karena saya sendiri tidak pernah mengikuti ujian TOEFL secara formal, saya tidak memiliki sertifikat yang menunjukkan score TOEFL saya.

Hingga pada suatu, ada seorang teman saya (kami sama-sama pernah bekerja pada sebuah Bank BUMN) mengirimkan saya berita bahwa dia mendapatkan informasi tentang adanya kebutuhan tenaga SWIFT (sebuah infrastruktur perbankan berbasis teknologi informasi global yang memungkinkan seluruh bank di dunia saling berinteraksi). Hanya sebuah kiriman singkat "ada yang butuh SWIFT di Singapura, kalau minat tolong kirimkan CV ke saya".

Dari sinilah, saya akan mencoba berbagi mengenai liku-liku interview, proses menjadi tenaga kerja dan hal lainnya berkaitan dengan dunia kerja dan kehidupan di Singapura.

Proses Interview

Ada seorang teman, beliau juga mendapatkan tawaran kerja di sebuah bank di Singapura. Beliau tidak menetap di Singapura, tetapi masih bekerja di salah satu bank di Jakarta. Pada saat interview, beliau mendapatkan tiket Singapore Airline dan menginap di salah satu hotel kawasan Orchad. Interview dilakukan secara face-to-face di kantor Singapura. Walaupun akhirnya beliau tidak jadi bekerja di bank ini, walaupun pihak bank telah menerima beliau dengan gaji yang telah disepakati, pihak Bank tidak menuntut pengembalian atas biaya interview. Kami sempat ngobrol semalaman sambil menikmati kopi di Orchad untuk saling bertukar pikiran.

Saya sendiri tidak melakukan interview face-to-face. Setelah saya mengirimkan CV, keesokan harinya teman saya mengatakan untuk siap-siap ditelpon besok. Jadinya saya menjalani beberapa interview melalui percakapan telpon dengan beberapa orang di Singapura sementara saya sendiri masih di Jakarta. Saya sama sekali tidak berhubungan dengan pihak-pihak di Jakarta. Beberapa hari kemudian, saya mendapatkan konfirmasi melalui telpon dan email bahwa mereka tertarik untuk memperkerjakan saya.

Jika saat ini, anda tertarik bekerja di Singapura dan masih bekerja di Indonesia, saya melihat 2 kemungkinan proses interview yang akan anda jalani seperti yang saya ungkapkan di atas. Anda akan diminta terbangbke Singapura untuk menjalani interview face-to-face atau melalui fasilitas telpon.

Saya cukup "surprise" jika akhirnya saya mendapatkan kesempatan untuk dapat bekerja di luar negeri. Ada satu pesan yang ingin saya sampaikan melalui tulisan ini adalah "maksimalkan belajar anda, apapun pekerjaan yang anda jalani hari ini". Maksud dari statement saya ini adalah, jika pada saatnya kita memiliki kesempatan, kita siap untuk menyambutnya pada saat itu juga. Terkadang kesempatan itu datang dengan tiba-tiba dan memiliki batas waktu yang sempit. Saya yang tidak pernah membayangkan sama sekali untuk bekerja keluar negeri, tiba-tiba mendapatkan pintu yang terbuka secara lebar.

Kalau saya boleh menambahkan, temen yang memberitahu saya bahwa ada peluang di Singapura, adalah orang yang tidak kuliah di jurusan yang berkaitan dengan dunia IT, terlebih lagi beliau ini adalah seorang yang mendapatkan gelar master di bidang finance. Tanpa diduga, beliau ditugaskan di divisi IT. Apa yang terjadi kemudian? Beliau ini sangat siap untuk belajar dari awal lagi tentang IT dan benar-benar melakukan hand-on, sehingga kemampuan teknikal IT sangat tinggi dan akhirnya memegang beberapa sertifikat teknis dalam bidang IT. Skill ini yang kemudian berperan besar baginya untuk selanjutnya berkarir di Singapura dan saat ini berdomisili di Kanada.

O ya, teman saya yang diminta untuk terbang ke Singapura untuk melakukan interview seperti yang saya ceritakan di atas adalah sarjana hukum dan master di bidang hukum. Tapi beliau ini, belajar wealth management (private banking) selama bekerja di bank. Ilmu wealth management ini yang kemudian dilirik oleh salah satu bank di Singapura untuk melakukan interview.

Sekali lagi, kalau saya boleh membuat statement seperti layaknya seorang motivator, maka saya ingin menitipkan pesan ini "maksimalkan belajar anda, apapun pekerjaan yang anda jalani hari ini", walaupun anda merasa bahwa anda tidak puas dengan apa yang anda lakukan hari ini, tetaplah untuk selalu belajar daripada waktu itu terbuang untuk mengeluh karena ketidakpuasan.

Jika anda memang sangat tertarik untuk kerja di Singapura, anda dapat saja mencari lewat media online. Terdapat banyak sekali portal yang menawarkan job di Singapura, anda tentu saja bisa mencarinya lewat search engine (seperti Google). Anda bisa mencari misalnya dengan "working in Singapore" dan lain sebagainya. Maaf, saya tidak ingin menyebutkan "nama" di sini.

Employment Pass

Seperti biasa, setelah konfirmasi kita terima, maka selanjutnya kita diminta untuk mengirimkan beberapa dokumen sebabai syarat seperti ijazah dan lain-lain. Untuk dapat bekerja di Singapura, pihak perusahaan akan membantu kita dalam mendapatkan Employment Pass (EP) dari MoM (Minister of Manpower).

Dalam hal ini, saya hanya diminta untuk meng-suply dokumen yang diperlukan untuk penyelesain EP. Tidak ada biaya satu sen pun yang harus saya keluarkan dalam proses ini. Pihak penerima saya, juga menyatakan bahwa mereka juga siap untuk mengurus "Dependent Pass" buat keluarga saya tanpa dipungut biaya. Dan selama proses pengajuan EP, saya masih berada di Jakarta. Saya tidak perlu datang ke Singapura selama pengurusan EP. 

Apakah fungsi EP ?
Setiap orang asing yang bekerja do Singapura melalui jalur profesional, diharuskan memiliki EP yang dikeluarkan oleh MoM. EP ini dapat berperan sebagai layaknya sebuah kartu penduduk. Pada saat anda membuka rekening di bank, anda bisa menggunakan kartu ini sebagai ID resmi anda. Hal yang sama akan terjadi pula pada saat kita berlangganan kartu telpon, menyewa rumah, mencatatkan nama anda ke KBRI (Kedutaan Besar Republik Indonesia) dan hal-hal lain yang bersifat legal.

Apakah EP memiliki golongan/tingkatan ?
Pada saat kita mendapatkan EP dari MoM, terdapat 3 tingkatan EP seperti gambar yang saya tampilkan dari website resmi MoM di bawah ini yaitu P1, P2 dan Q1. Salah satu komponen penentu golongan EP adalah besarnya basic salary minimum yang kita terima per bulan. Jika kita melihat seseorang memegang kartu kartu P1, itu berarti yang bersangkutan memiliki gaji minimum $8000 per bulan. Tetapi jika gaji kita perbulan misalnya $4750, MoM dapat saja memberikan kita P2 atau Q1 berdasarkan pertimbangan lainnya.

Sebagai catatan tambahan, sebenarnya di bawah EP ini, masih ada yang namanya S-Pass. Untuk lebih detailnya silahkan berkunjung ke website resmi MoM.


Apakah anggota keluarga boleh ikut ?
Untuk pemegang EP, kita diperkenankan untuk membawa keluarga kita untuk turut serta tinggal bersama di Singapura. Anggota keluarga kita ini, akan mendapatkan kartu yang namanya Dependent Pass, yang juga dapat digunakan sebagaimana layaknya EP untuk keperluan hal-hal yang bersifat legal, misal mendaftarkan diri untuk menjadi anggota library, sekolah dan lainnya.



Apakah pengajuan EP dapat ditolak ?Tidak senua proses pengajuan EP akan mendapatkan approval dari MoM. Dan MoM berhak untuk tidak akan memberikan alasan official mengenai penolakan ini. Walaupun pihak perusahaan telah menerima kita, tetapi jika MoM tidak mengizinkan atau menolak EP yang telah diajukan, maka otomatis pihak perusahaan tidak dapat memperkerjakan kita di Singapura.

Apa yang terjadi jika kita pindah perusahaan ?
EP akan selalu melekat kepada perusahaan yang menjadi sponsor kita. Jika kita keluar dari perusahaan tersebut, secara otomatis EP akan ditarik. Dan jika pindah dari satu perusahaan ke perusahaan lainnya, maka perusahaan berikutnya, akan menjadi sponsor kita untuk mendapatkan EP yang baru.

Saya pernah mendapatkan pengalaman menarik dari teman. Beliau ini bekerja pada perusahaan A dan  memutuskan untuk menerima tawaran perusahaan B. Kedua perusahaan ini berdomisili di Singapura. Maka proses EP mulai berlangsung. Perusahaan A menarik EP pada saat hari terakhir di kantor tersebut. Pada saat yang sama, perusahaan B akan sedang mempersiapkan untuk mengajukan EP pengganti. Umumnya setelah 2-3 minggu, approval EP sudah didapat, tetapi hal ini belum terjadi terhadap teman saya ini hingga melewati 1 bulan. Akhirnya, beliau ini mendapatkan panggilan untuk interview (saya sendiri belum pernah menjalani interview untuk mendapatkan EP). Setelah beberapa hari kemudian, EP teman saya ini dinyatakan ditolak.

Outsourcing, Head Hunter atau Langsung

Pada saat kita berhubungan pertama sekali dengan pihak yang menawarkan pekerjaan kepada kita, ada beberapa kemungkinan yang akan kita hadapi. Kemungkinan pertama adalah perusahaan yang akan merekrut anda akan langsung berhubungan dengan anda. Tetapi tidak jarang bahwa yang menghubungi anda adalah seorang dari sebuah perusahaan outsourcing atau head hunter.

Jika yang menghubungin kita pertama sekali adalah sebuah perusahaan outsourcing, umumnya kita akan bekerja pada sebuah klien-nya dan kita akan menjadi pegawai perusahaan outsourcing ini. Hubungan kita dengan perusahaan outsourcing ini dapat berupa kontrak atau menjadi pegawai tetap sangat tergantung negoisasi antara kita dengan mereka. Anda akan diinterview oleh pihak klien untuk menguji apakah anda adalah orang yang tepat sesuai dengan skill yang diharapkan. Jika klien merasa cocok, klien akan menghubungi perusahaan outsourcing ini. Selanjutnya, anda akan diinterview dengan perusahaan outsourcing ini untuk bernegoisasi masalah gaji, hak cuti dan lain sebagainya yang bersifat administrasi. Dengan pola ini, klien membayar jasa anda ke perusahaan outsourcing dan anda akan digaji oleh perusahaan outsourcing. EP anda akan diberikan kepada perusahaan outsourcing. 

Jika anda ditemukan pertama sekali dengan head hunter, anda akan langsung diinterview oleh klien baik dari kemampuan skill sampai masalah gaji, hak cuti, asuransi dan hal administrasi lainnya. Jika pihak klien cocok, maka head hunter akan memperoleh sejumlah uang atas jasa menemukan anda. Hubungan anda dengan head hunter akan terputus. Dan status anda akan menjadi pegawai klien. Tidak ada uang yang harus anda keluarkan kepada pihak head hunter, karena semua biaya selama proses rekruitmen akan ditanggung oleh klien.

Pola kerja sama dengan perusahan outsourcing
Kebetulan, saat ini saya sering berhubungan dengan perusahaan outsourcing, karena saya sering membutuhkan tenaga kerja dari eksternal yang selalu melibatkan perusahaan outsourcing, sehingga saya mencoba untuk berbagi sedikit pengalaman tentang hubungan ini dan kemungkinan akan berdampak bagi karier anda di masa-masa berikutnya, jika anda memiliki rencana yang panjang untuk tetap bekerja di Singapura. Tentu saja ini hanya pengalaman pribadi dan saya tidak terlalu berani untuk mengatakan hal ini akan berlaku di semua perusahaan, tapi paling tidak ada sesuatu yang mungkin bisa menjadi pertimbangan anda dalam bernegoisasi dengan perusahaan outsourcing.

Saya mencoba menyebutnya pola "strategic partnership" dan "non strategic partnership". Sekitar sebelum tahun 2007 sebelum adanya krisis ekonomi di Eropa, jika tim sedang membutuhkan tenaga eksternal, kita akan memberitahukan beberapa perusahaan outsourcing tentang kebutuhan tenaga eksternal dan memberikan speakfikasi skill yang dibutuhkan. Kita memakai metode "first-come-first-serve". Jadi semua perusahaan outsourcing terbuka untuk menawarkan kandidat mereka dan kami yang menentukan orang yang tetap. Ini yang saya sebut sebagai "non strategic partnership".

Pendekatan tersebut kini sudah berubah dan dan saya menyebutkannya sebagai strategic partnership yaitu menjalin kerja sama tunggal dengan sebuah perusahaan outsourcing. Dengan metode ini, setiap ada kebutuhan eksternal, kita tinggal memberikan skill yang kita butuhkan, kemudian kontrak dibuat untuk kebutuhan skill tersebut dengan perusahaan outsourcing. Kontrak berfokus kepada kebutuhan skill bukan terhadap perorangan.

Apa keuntungan dari perusahaan dengan pola outsourcing semacam itu? Kita membangun kontrak berdasarkan spesifikasi skill yang kita butuhkan yang harus dipenuhi oleh pihak outsourcing. Katakan, saat ini perusahaan outsourcing memiliki A yang bekerja untuk memenuhi skill tersebut. Setelah beberapa saat bekerja di dalam proyek, A mengajukan resign dari perusahaan outsourcing tersebut, maka pihak outsourcing harus mencari penggantinya sesuai dengan skill yang telah disepakati dalam kontrak. Perusahaan outsourcing harus menyiapkan pengganti dari A dan A juga harus melakukan transfer knowledge kepada penggantinyas sehingga dia benar-benar siap untuk menggantikan A pada saat A keluar. Umunya, pola ini akan menekan biaya untuk mendapatkan tenaga eksternal. Ini berbeda dengan pola "non strategic partnership", karena pada saat A mengajukan resign, maka kita akan mem-publish ulang kebutuhan tenaga eksternal kepada beberapa perusahaan outsourcing.

Apa dampak strategic atau non strategic terhadap anda dengan perusahaan outsourcing
Berdasarkan pengamatan pribadi, jika perusahaan outsourcing TIDAK menjalin kerja sama strategik dengan klien, umumnya anda memiliki kesempatan lebih besar untuk menjadi menjadi pegawai tetap pihak klien. Misal saat ini anda bekerja sebagai programmer berstatus tenaga eksternal pada sebuah klien. Jika sewaktu-waktu, klien ini merasa bahwa kebutuhan programmer adalah sebuah kebutuhan yang permanen, maka anda akan mendapatkan prioritas yang tinggi untuk dikonversi dari tenaga eksternal menjadi pegawai tetap klien tanpa melalui proses percobaan. Pihak klien akan membeli anda dari perusahaan outsourcing tempat anda bernaung. Tentu saja pihak outsourcing akan meminta harga yang tinggi dan ini umum terjadi pada saat-saat ekonomi Singapura cukup bagus.

Pada perusahaan yang menjalin kerja sama strategik, mereka umumnya akan memasukkan syarat bahwa anda tidak diperbolehkan pindah dan menjadi pegawai klien (umumnya terdapat batas waktu tertentu, misal 6 bulan atau 1 tahun).

Saya hanya ingin mengatakan, ada baiknya anda menanyakan kondisi ini sebelum anda memutuskan untuk mengambil tawaran tersebut jika berhadapan dengan perusahaan outsourcing. Menurut saya anda berhak dan itu bukan merupakan hal yang tabu untuk menanyakan secara langsung nama klien dimana anda akan ditempatkan. Anda juga berhak menanyakan apakah terdapat larangan bagi anda untuk pindah ke klien. Umumnya, perusahaan yang tidak menjalin kerja sama strategik dengan klien, mereka sering mengatakan hal ini pada saat interview awal "jika performance anda bagus, sangat dimungkinkan klien kita akan mengankat anda menjadi pegawai tetap". Kalimat ini tentu saja, untuk menanamkan minat anda untuk bergabung dengan mereka.

Mengawali Hidup dan Kerja di Singapura

Akhirnya, lebih kurang 2-3 minggu, saya mendapatkan kabar dari contact person saya di Singapura bahwa EP saya telah di-approve oleh MoM. Sehingga saya mulai mempersiapkan diri untuk berangkat ke Singapura dan memulai hidup dan bekerja di kota ini.

MoM akan memberikan surat "pre-approval", untuk menunjukkan bahwa mereka menyetujui permohonan EP. Surat ini akan dikirimkan oleh contact person saya di Singapura lewat pos. Surat ini saya bawa pasa saat terbang ke Singapura dan saya menunjukkan surat ini kepada petugaa imigrasi Singapura di bandara untuk memberi tahukan mereka kalau saya tidak masuk sebagai turis, melainkan sebagai orang yang akan bekerja dan menetap di Singapura. 

Keesokan harinya, passport saya diminta untuk proses mendapatkan kartu EP (seperti layaknya sebuah KTP). Semua proses dipersiapkan dan dijalankan oleh perusahaan saya di Singapura. Selang beberapa hari kemudian, saya mendapatkan kartu EP tanpa mengeluarkan satu sen pun dan tidak berhubungan langsung dengan MoM. Berdasarkan informasi yang pernah saya dengar, jika kategori EP yang diajukan adalah Q, pihak MoM meminta kita untuk melakukan test kesehatan. 

Apa kemudahan yang saya peroleh selama menjadi hari-hari baru di Singapura

Sebagai orang baru di Singapura saya memperoleh fasilitas kamar selama 2 minggu pertama yang ditanggung oleh pihak perusahaan. Jika kita punya saudara, mungkin kita tidak memerlukan fasilitas ini. Saya sendiri menginap di hotel selama seminggu pertama, karena kebetulan saya mendapat tempat tinggal sendiri dengan dengan mengontrak setelah itu dengan menggunakan uang pribadi saya. 

Seluruh biaya pesawat, fiskal (dahulu saya harus membayar fiskal satu juta rupiah) termasuk airport tax ditanggung oleh perusahaan Singapura. Kalau tidak salah, saya memilih Garuda pada saat itu dan perusahaan mengganti semua biaya tersebut di Singapura. Di samping itu, saya juga diperkenankan untuk mendapatkan 50% gaji pertama diawal, jika saya mengingininya guna membiayai segala kebutuhan awal seperti kontrak rumah, saldo awal untuk membuka account bank dan lain sebagainya.

Kebetulan fasilitas tersebut adalah bagian dari kontrak awal saya dengan pihak Singapura, tetapi saya tidak tahu persis apakah hal tersebut akan berlaku secara umum. 


Pajak di Singapura

Pada saat saya diinterview pertama sekali oleh pihak Singapura, mereka sudah mengatakan bahwa pajak di Singapura adalah rendah atau mungkin terendah di kawasan ASEAN. Saya menampilkan tabel yang saya dapatkan dari website resmi IRAS. Jika misalnya gaji setahun yang kita dapatkan adalah $80,000 (atau lebih kurang 60 juta per bulan dengan kurs lebih kurang 9000 Rupiah), maka pajak paling tinggi 7%.


Pajak sendiri akan dibayarkan setiap tahun oleh kita. Umumnya, kita tidak mendapatkan tunjangan pajak di dalam slip gaji, melainkan kita harus membayar sendiri setiap tahunnya. Ada proses perhitungan pajak yang akan dikeluarkan oleh IRAS berdasarkan gaji yang kita peroleh di tahun sebelumnya.

Pembayaran pajak tahunan ini dapat dilakukan dengan cara "one-time", dimana kita melakukan transfer sejumlah uang yang telah ditetapkan oleh IRAS. Atau kita bisa mengajukan pembayaran bulanan melalui mekanisme GIRO ke pihak bank dimana kita memiliki account. Ada form yang harus kita isi, untuk memberi wewenang kepada IRAS, sehingga uang kita akan dikurangi tiap bulan (auto debet) sebesar  jumlah pajak yang kita bayarkan dibagi selama 12 bulan, tapi terkadang kita tidak perlu membayar sisa bulan ke 12. Dalam hal ini, menggunakan GIRO memberikan kemundahan dan keuntungan bagi kita pembayar pajak. Jika jumlah tagihan pajak kita $6000, maka akan terjadi auto-debet $500 per bulan dan terkadang di bulan ke 12, uang kita tidak di debet.

Sebagai tambahan, terkadang pula pemerintah Singapura memberikan pengurangan terhadap pajak yang kita bayarkan. Misal pada tahun pajak 2012, pemerintah Singapura memberikan pengurangan sebesar 3% dari tagihan pajak atau maksimum $1500. Jika tagihan pajak tahun sebelumnya adalah $6000, maka pajak yang harus kita bayarkan pada tahun ini adalah $6000 - $1500 = $4500.


CPF

Ini adalah sebuah lembaga negara yang mengelola "tabungan masyarakat", saya menggunakan istilah ini, karena semua penduduk Singapura akan memiliki account di CPF. Besaran tabungan yang akan kita setorkan lebih kurang 16% dibayarkan oleh perusahaan dan 20% diambil dari gaji kita. Jika kita mendapatkan gaji $1000 per bulan, maka 20% dari gaji tersebut ($200) harus kita tabung ke dalam account CPF. Kemudian, perusahaan akan menambahkan tabungan CPF kita sebanyak 16% ($160). Artinya setiap bulan, uang yang kita bawa pulang sebagai gaji adalah $800 dan account CPF kita akan bertambah menjadi $360.

Tabungan $360 tersebut akan masuk ke dalam 3 sub-account yaitu ordinary, special dan medisave. Uang yang terkumpul di dalam ordinary account dapat kita ambil untuk hal-hal yang di-approve oleh badan CPF, misal digunakan untuk membeli rumah, mengangsur kredit rumah, biaya pendidikan dan lain-lain. Uang yang terkumpul dalam medisave account, dapat kita gunakan untuk biaya kesehatan kita misal biaya rumah sakit atau membeli asuransi kesehatan. Sedangkan tabungan di special account, hanya dapat diambil pada saat kita memasuki masa pensiun. Di bawah ini, saya tampillkan sebuah tabel mengenai besaran konstribusi dan jumlah yang masuk ke setiap account. Tabel ini saya peroleh dari website resmi CPF.


Apakah kita wajib untuk mengikuti program CPF
Program CPF hanya diwajibkan bagi penduduk Singapore yang berstatus PR (Permanent Resident) atau warga negara Singapura. Jika kita masih menggunakan EP sebagai sebagai kartu penduduk, kita tidak diwajibkan mengikuti program ini.

Saya termasuk beruntung, karena pada saat saya masih memegang EP dan tidak mengikuti program CPF, kantor saya memberikan besaran 16% yang mereka harus serahkan kepada CPF kepada saya sebagai tambahan gaji. Hal ini tidak berlaku di semua perusahaan, jika anda mendapatkan perusahaan seperti ini, jika negoisasi basic salary anda adalah $5000 per bulan, akan ada tambahan cash sebenar 16%  ($800), maka gaji yang anda bawa pulang adalah $5,800. Nilai $800 itu, dapat saja ditulis sebagai "program pensiun" di dalam item slip gaji.

Konversi dari EP menjadi PR
Jika akhirnya kita memutuskan untuk menjadi PR, ada beberapa hal yang perlu dicatat terkait masalah CPF ini, karena tidak semua perusahaan memiliki "program pensiun" selama anda memegang EP. Bagi perusahaan yang telah memberikan dana program pensiun selama memegang EP, maka perusahaan akan mengalihkan dana tersebut kepada CPF.

Kemungkinan akan terjadi negoisasi, jika pada saat anda memegang EP perusahaan tidak memberikan uang pensiun. Hal ini karena perusahaan berkewajiban untuk mengalokasi dana tambahan bagi anda sebesar 16% yang sangat dimungkinkan belum dibicarakan selama proses kontrak awal. 

Negoisasi ini sangat mungkin terjadi pada saat anda meminta surat sponsor dari perusahaan anda. Untuk meng-konversi EP menjadi PR, kita diminta untuk mengisi sebuah form yang harus ditandatangani dan distempel oleh perusahaan. Pada saat anda meminta surat ini, di saat itulah negoisasi bisa terjadi. Perusahaan terkadang meminta anda untuk membayar 16% kontribusi ke CPF dari gaji anda, jika seandainya PR anda di-approve, artinya 36% tabungan CPF akan secara penuh berasal dari gaji anda.

Title Jabatan

Pada topik ini, sangat hanya ingin melakukan sharing bahwa title jabatan di setiap perusahaan memiliki makna atau level yang berbeda. Andai title jabatan adalah salah satu pertimbangan anda dalam memilih pekerjaan, anda mungkin perlu juga mempertimbangkan level yang sebenarnya dari title tersebut. Saya akan mencoba melihat ini dari pengalaman saya di dunia banking.

Di banking, umumnya terdapat tiga atau lebih title utama yaitu director, vice president, associate. Terdapat bank yang memiliki 2 level director yaitu Managing Director dan Director. Sementara di bank yang lain, terdapat 3 level director yaitu Managing Director, Director dan Aasociate Director. Pada title dibawah Director yaitu Vice President, juga dimungkinkan terdapat 3 level yaitu Senior Vice President, Vice President dan Assistant Vice President. Tetapi, ada juga bank yang hanya memiliki 2 level yaitu Vice President dan Assistant Vice President.

Ada seorang teman kerja saya yang cukup senior dengan title Assistant Vice President, beliau pindah ke bank lain dengan title Vice President. Pada saat kami saling menyapa, beliau ini bilang bahwa di kantor yang baru ternyata langkah untuk menjadi Director tetap tidak langsung, karena setelah masuk ke sana, di atas Vice Presdient masih ada Senior Vice President sebelum masuk ke Director. Sedangkan di kantor saya, di atas Vice President adalah langsung Director. Pada kesempatan yang berbeda, saya bertemu seseorang yang akan diinterview di kantor saya dengan title Director. Saat itu, beliau ini akan diinterview untuk sebuah jabatan dengan title Vice President di kantor saya. Saya bertanya kenapa beliau menerima tawaran head hunter untuk ikut interview, jawaban yang saya dapat adalah karena berdasarkan struktur  yang ada, title Director itu ternyata sama levelnya dengan title Vice President di tempat saya. Saya berpendapat bahwa hal ini juga terjadi di industri yang lain, tidak hanya di industri banking.

Terkadang juga, role atau jabatan yang menjadi tanggung jawab kita, akan memilik level title yang berbeda. Misal seseorang yang memiliki jabatan atau tanggung jawab sebagai Lead Technical terkadang memiliki title sebagai Assistant Vice President, sementara itu pada bank yang lain role seorang Lead Technical memiliki title sebagai Vice President atau Senior Vice President.

Sebagai sebuah kota yang memiliki banyak perusahaan global, umumnya perusahaan global ini menggunakan pendekatan global sehingga sangat dimungkian title itu berbeda-beda di setiap perusahaan tergantung kebijakan global yang mereka miliki.

Akhirnya, saya hanya ingin mengatakan bahwa jika memang title adalah bagian yang penting bagi anda, sebaiknya klarifikasi terlebih dahulu struktur level jabatan yang sebenarnya di perusahaan tersebut. 


--------
Link:
Topik tentang mengenai kehidupan di Singapura: Kehidupan di Singapura 
Topik tentang mengenali teknologi informasi: Mengenali Teknologi Informasi


Monday 20 January 2014

Metode SCRUM pada Pendekatan Rekayasa Perangkat Lunak AGILE

SCRUM adalah salah satu metode rekayasa perangkat lunak dengan menggunakan prinsip-prinsip pendekatan AGILE, yang bertumpu pada kekuatan kolaborasi tim, incremental product dan proses iterasi untuk mewujudkan hasil akhir.



Scrum sendiri bukan satu-satunya metode yang menggunakan pendekatan AGILE. Mungkin kita juga pernah mendengar metode Extreme Programming (XP) yang juga menggunakan pendekatan AGILE dalam rekayasa perangkat lunak. Masing-masing metode memiliki fokus atau penekanan yang berbeda yang tentu saja dapat dikombinasika untuk menghasilkan proses yang optimal. 

Jika metode XP lebih berfokus kepada framework yang memberikan kerangka mengenai praktek-praktek teknis dalam membangun program menggunakan pendekatan AGILE, seperti para programmer yang diharapkan untuk bekerja pada station yang sama sehingga dapat menggunakan library yang sama dan lain sebagainya. 

Sedangkan metode SCRUM lebih berfokus kepada project management yang memberikan kerangka kerja bagaimana mengelola sebuah proyek yang berbasis AGILE. Metode ini memberikan pola "ceromony" apa saja yang harua dilaksanakan, "role" apa saja yang ada dalam SCRUM termasuk tugas yang harus diperankannya dan masih banyak hal lainnya. Tulisan ini akan mencoba untuk mengupas metode SCRUM ini.

Di dalam setiap iterasi scrum, semua anggota tim saling berkolaborasi untuk menyelesaikan setiap incremental product yang telah direncanakan dan disepakati bersama. Dalam proses, setiap iterasi juga akan melakukan kegiatan analisis, merencanakan desain dan selanjutnya program siap untuk dikembangkan. Setelah program selesai, program juga akan diuji melalui proses testing yang telah direncanakan oleh tim, sehingga akhirnya program tersebut menjadi sebuah incremental product yang siap untuk di-deploy dan di-integrasi-kan dengan semua program yang telah dibuat sebelumnya. 

Semua kegiatan diatas akan dilakukan oleh tim dengan konsep self-organizing, artinya semua anggota tim akan bekerja sama untuk mengelola kerja mereka sesuai dengan kesepakatan mereka. Mereka bertanggung jawab untuk menghasilkan incremental product dengan membagi tugas secara bersama dan berdiskusi tanpa ada hirarki. Seorang yang berpengalaman testing, sangat dimungkinkan untuk berkonstribusi ditahap analisa dan desain. Atau seorang programmer akan membantu aktifitas testing. Secara sederhana, anggota tim akan merencanakan tugas secara bersama dan melakukannya secara bersama sebagai sebuah kolaborasi tim.




ROLE (Fungsi) dalam Scrum

Scrum akan berjalan pada tim dengan jumlah orang yang tidak terlalu banyak, kira-kira berjumlah lebih kurang 7 orang. Setiap orang dalam tim scrum akan memiliki role atau fungsi tertentu. Dan hanya dikenal 3 role atau fungsi dalam menjalankan proyek berbasis scrum :

Product Owner
Product owner adalah orang yang bertanggung jawab terdapat definisi produk yang akan dibuat. Dengan kata lain, product owner adalah tim yang menciptakan "APA" yang harus dimiliki oleh aplikasi. Mereka bertugas untuk menuliskan semua item yang harus dimiliki oleh aplikasi. Item-item tersebut memiliki "story" yang akan disampaikan oleh product owner. 
Product owner, juga bertanggung jawab untuk memberikan prioritas kepada setiap story, sehingga seluruh anggota tim SCRUM mengetahui apa yang sebaiknya harus dibuat pada setiap iterasi. 
Sebagai representatif dari pengguna, product owner akan menjadi kunci apakah hasil dari sebuah iterasi dapat di-deploy atau diimplementasikan.

Scrum Master
Ini adalah seseorang yang akan berperan sebagai fasilitator dalam setiap proses atau ceremony yang ada dalam scrum seperti layaknya seorang project manager. 

Scrum Development Team
Tim inilah yang akan setiap iterasi menghasilkan suatu incremental product yang telah disepakati bersama. Mereka bertanggung jawab untuk membuat program dan menguji program tersebut(testing) sehingga hasil dari setiap iterasi dapat digunakan dan diimplementasikan.
Tim ini harus mengatur dirinya sendiri (self-organized), dari proses analisa, design, coding dan akhirnya diujikan. Mereka harus berkolaborasi bersama sehingga keluaran dari setiap iterasi adalah sebuah program yang benar-benar teruji dan sesuai dengan harapan product owner.

Proses Membangun Incremental Product

Product Backlog Item
Adalah list dari 'user story' untuk menggambarkan fungsi atau feature apa saja yang harus tersedia di dalam aplikasi. Product Owner akan membuat user story untuk selanjutnya dibawa dalam sebuah diskusi bersama untuk melihat lebih detail terkait dengan skala prioritas dan acceptance criteria.

Beberapa contoh user story pada Product Backlog Item
  • Jika user mencoba 3 kali password secara salah, maka user akan di lock.
  • Menghasilkan report nilai semester mahasiswa.
  • Report alokasi ruangan kelas dan mampu memberikan alert sehingga jadwal kuliah tidak konflik dengan jumlah ruangan yang ada.
Seluruh Story Form akan didiskusikan untuk selanjutkan diurutkan sebagai Product Backlog Item, sekaligus sebagai urutan incremental product pada setiap iterasi atau sprint. Di dalam scrum, kita akan lebih sering menggunakan istilah sprint dibandingkan iterasi.



Sprint Backlog
Adalah sebuah hasil diskusi bersama berdasarkan skala prioritas untuk melakukan mapping setiap Product Backlog Item(PBI) ke jadwal sprint. Dengan adanya Sprint Backlog, maka semua member dalam scrum akan mengetahui apa target pada setiap sprint atau setiap iterasi. Sangat dimungkinkan sebuah PBI akan dipecah menjadi 2 bagian atau lebih menjadi item yang lebih kecil sehingga dapat dikerjanan dalam sebuah sprint atau iterasi. Pemecahan ini tetap menjalankan prinsip bahwa item tersebut adalah independent dan testable.

Sprint Tasks
Team akan melakukan identifikasi pada setiap sprint backlog dan berdiskusi bersama tugas-tugas apa saja yang harus dilakukan pada setiap sprint atau iterasi. Misal, telah ditetapkan bahwa kita akan membuat report nilai semester siswa pada sebuah sprint/iterasi tertentu. Selanjutnya kita mulai melakukan identifikasi tugas-tugas yang harus dikerjakan agar kita mampu menyesaikan iterasi tersebut. Contoh tugas-tugas yang harus kita lakukan dalm iterasi tersebut adalah membuat form report, menganalisa database, mendesain bagaimana layar user untuk keperluan input, melakukan testing dan lain-lain.



Aktifitas Scrum

Kita juga dapat menyebut aktifitas scrum ini sebagai Scrum Ceremony. Sebagaimana di awal tulisan ini, scrum berfokus kepada manajemen proyek yang didalamnya terdapat framework tentang bagaimana mengelola dan menjalankan proyek rekayasa perangkat lunak menggunakan prinsip agile.


Gambar di atas, menunjukan bagaimana proses rekayasa perangkat lunak menggunakan metode scrum akan berlangsung. Dimulai dengan kegiatan untuk melakukanidentifikasi backlog (atau user story) dan selanjutnya kegiatan akan bergerak dari satu iterasi ke iterasi selanjutnya guna membangun incremental product. Di dalam setiap iterasi, terdapat juga kegiatan harian yang akan dilakukan oleh semua anggota tim scrum.

Backlog Refinement Meeting
Semua proyek perangkat lunak selalu memiliki item yang akan digunakan untuk membantu pengguna aplikasi dalam menjalankan kesehariannya. Meeting ini digunakan bersama oleh seluruh tim scrum untuk mengetahui feature atau fungsi apa saja yang akan terdapat pada aplikasi yang sedang dikembangkan. Hasil dari meeting adalah sebuah Product Backlog Item. 
Meeting ini harus dilakukan sebelum tim mulai bekerja pada tahapan iterasi atau sprint. Setiap list akan direview apakah scope-nya masih terlalu luas atau perlu di-split atau dibagi-bagi lagi menjadi potongan yang lebih kecil, sehingga dapat dengan mudah untuk di-mapping ke dalam suatu iterasi/sprint. 
Tim juga akan berdiskusi tingkat kesulitan dan prioritas dari masing-masing item, sehingga tim bisa membuat schedule yang tepat untuk melakukan mapping mengenai item yang akan dikerjakan lebih dahulu sehingga tim memiliki perencanaan item apa saja yang akan dikerjakan untuk setiap iterasi.
Dan tentu saja, pada tahap ini tim mencoba untuk menyamakan persepsi mengenai acceptance criteria yaitu kriteria apa saja untuk mengatakan bahwa iterasi dan incremental product yang dihasilkan adalah sesuai harapan.

Sprint Planning Meeting
Meeting ini dijalankan pada hari pertama pada setiap sebuah iterasi akan dimulai. Dengan menggunakan Product Backlog Item yang telah ditetapkan pada saat Backlog Refinement Meeting, maka tim sudah mengetahui feature apa yang akan mereka selesaikan pada iterasi. Dan tim mulai melakukan identifikasi tugas atau task apa saja yang harus dikerjakan guna menyelesaikan feature yang telah ditetapkan pada setiap iterasi atau sprint. Selanjutnya tim mulai membagi tugas atau task tersebut kepada seluruh anggota scrum.

Daily Scrum 
Kini tiba saatnya sebuah iterasi dimulai. Semua anggota tim scrum sudah bersepakat feature apa yang akan dihasilkan pada iterasi ini. Mereka juga sudah memiliki rencana kolaborasi dan setiap anggota tim telah sepakat dengan tugasnya masing-masing. Setiap hari, semua anggota tim akan melakukan meeting lebih kurang 20 menit dan masing-masing anggota harus melaporkan 3 point. Point-point tersebut adalah apa yang telah dilakukan kemarin, apa yang akan dilakukan hari ini dan kendala yang dihadapi untuk menyelesaikan tugas. Meeting ini didesain untuk dilakukan secara singkat, jika ada sesuatu yang detail, anggota tim bisa berdiskusi lebih detail diluar meeting ini dengan orang-orang terkait.


Setiap harinya, sprint backlog akan selalu mereflekasikan status dari semua tugas yang telah ditetapkan pada setiap iterasi. Semua tugas yang telah diidentifikasi, akan dimasukkan ke dalam kolom "Not Started". Selanjutnya tugas-tugas tersebut akan mengalami progress dan didiskusikan dalam daily meeting.

Sprint Review Meeting
Kini tiba saatnya akhir dari sebuah sprint, seluruh tim akan berdiskusi lagi untuk melakukan final review untuk menyatakan apakah mereka telah berhasil memenuhi ekspektasi yang ditetapkan oleh product owner. Product Owner akan menjadi orang kunci yang akan menentukan apakah incremental product yang telah dibuat dalam sprint tersebut dapat diterima atau dinyatakan gagal sehingga perlu adanya diskusi lanjutan untuk menentukan langkah selajutnya. 

Meeting ini tidak lagi berdiskusi mengenai status, incremental product yang telah dikembangkan selama satu periode sprint akan didemokan dan diujikan sebagai final review untuk menyatakan bahwa  sebuah user-story atau sebuah product backlog item telah benar-benar selesai sesuai dengan target sprint yang telah disepakati.

Jika sebuah user story telah dinyatakan gagal di dalam sebuah iterasi, tim bisa saja memutuskan untuk menunda terlebih dahulu user-story ini, untuk selanjutnya akan ditinjau kembali pada iterasi mendatang. Atau tim juga bisa menentukan, jika user-story ini akan dilakukan kembali pada iterasi selanjutnya sehingga jadwal user-story yang telah direncanakan sebelumnya akan ditunda terlebih dahulu, untuk menyelesaikan user-story yang masih belum yang belum berhasil.

Sebagaimana karakteristik dari metode scrum, tim scrum adalah self-organization, sehingga tim yang akan menentukan langkah yang paling tepat bagi mereka.

Sprint Restrospective Meeting
Ini adalah meeting untuk melakukan instropeksi dengan melihat kembali perjalanan selama sprint berlangsung. Diskusi lebih berfokus kepada upaya untuk membangun sebuah timyang efektif dan optimal guna menyelesaikan sprint-sprint berikutnya. Mungkin perlu perbaikan dalam pola komunikasi antar tim, atau terdapat sebuah proses yang mungkin bisa dihilangkan karena justru menyulitkan tim tetapi efek terharap hasil akhir tidak sesuai dengan effort yang dikeluarkan atau banyak hal lainnya.

Dengan adanya meeting ini, diharapkan hubungan antar tim akan semakin baik, kolaborasi menjadi lebih efektif dan optimal serta pengetahuan akan product akan semakin bertambah sehingga memudahkan sprint-sprint berikutnya.


--------
Link:
Topik tentang mengenai kehidupan di Singapura: Kehidupan di Singapura 
Topik tentang mengenali teknologi informasi: Mengenali Teknologi Informasi


Semoga Bermanfaat
Singapore, Januari 2014

"Dipublish di atas MRT dalam perjalanan pulang dari kantor ke rumah. Ditulis/dipersiapkan kira-kira seminggu lebih, guna mengisi waktu kosong di atas MRT"







Friday 10 January 2014

Rekayasa Perangkat Lunak Melalui Mendekatan AGILE

Dalam beberapa kasus pengembangan aplikasi perangkat lunak, mungkin kita pernah mengalami situasi sebagai berikut.

Kita berharap user atau calon pengguna aplikasi mampu meng-artikulasikan dan menggambarkan dengan tepat ekspektasi yang dia harapkan dari aplikasi yang sedang dikembangkan. Kemudian orang IT mencoba untuk meng-interpretasikan itu sebagai user requirement dan mulai men-desain. Dalam beberapa kasus, terjadi gap yang lebar antara tim IT dengan kemampuan imajinasi user, sehingga tim IT terkadang menggunakan asumsi berdasarkan pengalaman pribadinya. Akhirnya, desain selesai dan pembuatan program berjalan sesuai desain dan tiba saatnya bagi tim IT untuk menunjukkan hasil kerjanya. Dan yang terjadi, user mendapat banyak hal yang diluar bayangannya dan yang kadang justru menjadi tidak puas dengan hasilnya.

Situasi di atas telah menjadi sesuatu yang sering terjadi saat ini, karena begitu banyaknya pilihan teknologi yang tersedia dan semakin kompleknya proses bisnis di sebuah enterprise. Orang-orang bekerja pada industri IT kini memiliki kesulitan untuk selalu mengejar kecepatan perubahan yang muncul dari kemajuan dan banyaknya pilihan yang tersedia. Sedangkan pengguna teknologi, akan semakin mengalami kesulitan untuk meng-artikulasi dan berimajinasi untuk membuat sebuah user requirement apalagi jika aplikasi yang dibangun adalah sebuah proses dari titik nol.

Kini pada para praktisi rekayasa perangkat lunak mencoba untuk mencari semacam framework (kerangka kerja) yang sesuai untuk mengakomodasi situasi di atas sehingga proyek dapat berjalan dan menghasilkan sesuatu seperti yang diharapkan oleh user dan orang IT dapat menurunkan resiko akan kegagalan sebuah proyek.

Tulisan ini mencoba membuka sedikit wawasan mengenai pendekatan baru dalam rekayasa perangkat lunak. Cerita akan dimulai dengan melihat salah satu pendekatan rekayasa lunak yang sering disebut sebagai waterfall model dan telah digunakan selama cukup lama dalam rekayasa perangkat lunak. Dan kita mencoba melihat beberapa point sehingga waterfall model tidak selamanya bisa menjadi "satu obat mujarab untuk semua jenis penyakit". Setelah itu, baru kita mencoba melihat salah satu "obat alternatif" yang dapat kita pergunakan dalam rekayasa perangkat lunak, yang saat ini lebih dikenal dengan metode "AGILE".

Model Rekayasa Perangkat Lunak "Waterfall"

Hampir beberapa dekade, kita telah mengenal dan menerapkan pengembangan atau rekayasa perangkat lunak menggunakan pendekatan warerfall. Pendekatan ini secara sederhana membagi proses rekayasa perangkat lunak menjadi lebih kurang 5 tahapan inti.


  • Analisis, adalah tahapan dimana tim IT berdiskusi dengan user untuk mendapatkan kebutuhan user dan ekspektasi user terhadap aplikasi yang akan dibuat. Secara ringkat, tahapan ini akan menghasilkan sebuah dokumen yang bisa kita sebut sebagai User Requirement.
  • Desain, adalah tahapan dimana tim IT mulai menterjemahkan user requirement yang telah diserahkan atau disetujui oleh user. Biasanya, proses ini akan menghasilkan dokumen yang dapat kita sebut sebagai Technical Design. Kalo kita sedang merencanakan pembuatan rumah, tahap ini lebih kurang sama dengan proses pembuatan dokumen arsitek.
  • Coding, pada saat ini pengembangan yang sesungguhnya dari aplikasi dimulai. Program-program mulai dikerjakan, tentu saya programmer yang bertugas membuat software akan selalu mengacu kepada dokumen Technical Design. Tahap ini dinyatakan selesai jika semua program telah selesai dibuat dan/atau di-'package'. Aplikasi telah selesai dan disiap untuk dilakukan proses pengujian.
  • Testing, kini tiba waktunya untuk melakukan testing apakah aplikasi yang dibuat telah sesuai dengan yang sudah dituangkan dalam user requirement. Biasanya keluaran dari tahapan ini adalah dokumen pernyataan tentang "User Acceptance Test".
  • Deploy, setelah tahapan testing selesai, kini tiba waktunya untuk menginstall program tersebut dan aplikasi mulai dioperasikan serta bekerja sesuai fungsinya.
Kini kita mencoba melihat berbagai kondisi nyata dalam proyek rekayasa perangkat lunak, sehingga terkadang metode waterfall ini tidak bisa menjadi obat mujarab untuk semua proyek rekayasa perangkat lunak. Ini tidak berarti bahwa waterfall tidak relevan lagi, tapi lebih tepatnya adalah kita harus melihat kenyataan bahwa warerfall bukan satu-satunya pendekatan yang harus dijalankan dalam setiap proyek rekayasa perangkat lunak.

Pendekatan Waterfall jarang sekali terjadi kolaborasi yang cukup kuat dan konsisten antara satu tim dengan tim lainnya. Pada setiap stage atau tahapan diatas, sangat mungkin tim yang bertanggung jawab terhadap tahapan tersebut menggunakan asumsi-asumsi yang berbeda dengan tim yang bertanggung jawab pada proses sebelumnya yang bisa disebabkan karena berbagai alasan seperti perbedaan domain knowledge, pengalaman industri dan lain sebagai. Orang- orang yang bertanggung jawab membuat user requirement, umumnya domain knowledgenya adalah business process pada industri tertentu. Pada saat orang desain mulai melakukan technical design, sangat dimungkinkan dia memiliki pengetahuan business process yang sama levelnya dengan tim yang membuat user requirement, sehingga dia bisa menggunakan asumsi yang mungkin berbeda pada saat user requirement dibuat. 

Apa yang dihasilkan oleh satu tahapan, merupakan "kontrak kerja untuk tahapan selanjutnya, umumnya dilegitimasi dengan istilah sign-off. Jadi jika User Requirement telah di sign-off pada tahap analisis, dokumen ini menjadi kontrak kerja bagi tahapan desain untuk menghasilkan technical design. Programmer yang bekerja pada saat coding, akan menggunakan techinal design yang telah mendapatkan sign-off sebagai kontrak kerja. Beberapa kemungkinan masalah yang dapat muncul kemudian adalah:
  • Kesalahan atau kekurangan yang terjadi pada tahap awal akan mengakibatkan kesalahan berantai ditahap-tahap selanjutnya.
  • Karena testing (UAT) baru mulai dilakukan setelah semua program selesai, respon terhadap kesalahan akan sangat terlambat sehingga proses perbaikan akan jauh lebih lama.
  • Proses ini cenderung lambat untuk "time-to-market", sehingga pada saat aplikasi selesai dan siap beroperasi, lingkungan bisnis telah berubah sehingga aplikasi tersebut tidak bisa menggali pasar yang diharapkan sebelum aplikasi dibuat.
Perangkat input dari aplikasi berkembang pesat seperi card reader, scanner, kamera dan lainnya. Perangakat outputnya, juga semakin beragam, mulai dari tampilan grafis, resolusi warna, video dan lain sebagainya. Jika dulu, Sistem Informasi Manajemen (SIM), umumnya tampil dalam bentuk 'text mode' dengan 'menu driven'-nya. Pada saat itu, para user dan tim IT dapat dengan mudah untuk berdiskusi tentang User Requirement. Kini pilihan yang teknologi semakin banyak ditambah bisnis proses yang semakin komplek, user mengalami kesulitan untuk membuat sebuah user requirement yang menyeluruh dan tim IT juga harus memahami juga pilihan IT yang ada.

Banyak sekali proyek IT yang cenderung gagal karena hasilnya tidak sesuai ekspektasi atau waktu yang berjalan molor. Para praktisi rekayasa perangkat lunak melihat bahwa pendekatan waterfall sangat cocok, jika user dan tim IT sangat tahu persis tentang proses bisnis dan pilihan teknologi yang akan digunakan. Kondisi ini akan menghasilkan user requirement dan technical design yang komprehensif dan terstruktur dengan baik.

Waterfall model akan mengalami kesulitan pada saat user dan tim IT berada pada situasi yang komplek untuk membuat user requirement dan technical design karena minimnya pengalaman terhadap aplikasi yang sedang dibuat. Praktisi rekayasa perangkat lunak mencoba mencari merode lain, dimana aplikasi dikembangkan secara bertahap, berkolaborasi secara total dan adanya learning curve selama proyek berjalan. Pada bagian selanjunya kita akan melihat model alternatif yang mungkin dapat kita gunakan dalam proyek rekayasa perangkat lunak kita. Pendekatan ini kemudian sering kita kenal sebagai pendekatan AGILE.

Model Rekayasa Perangkat Lunak "AGILE"

Rekayasa perangkat lunak menggunakan AGILE sering juga disebut sebagai "iterative method" dan dapat juga disebut sebagai "incremental product development". Pada saat, tim IT dan tim user mengalami kesulitan untuk mendefinisikan kebutuhan mereka secara komprehensif, kemungkinanan cara ini akan lebih efektif. 

Proses pengembangan berjalan secara 'incremental', artinya aplikasi tidak harus diselesaikan secara sekaligus, melainkan bertahap. Disaat yang saman, 'incremental' ini juga terkain dengan kegiatan yang berulang-ulang ('iterative'). Dan hal yang terpenting adalah kolaborasi penuh antara semua personal proyek.

Mari kita lihat sebuah ilustrasi sederhana rekayasa perangkat lunak menggunakan AGILE :
  • Tim agile tidak menuntut jumlah personal yang banyak, secara efektif sekitar 7 orang. Mereka terdiri dari orang bisnis (sering disebut sebagai product owner), orang-orang IT dan fasilitator AGILE.
  • Mereka kemudian menetapkan waktu iterasi, jika kita menggunakan Scrum, iterasi ini disebut juga sebagai sprint (Scrum adalah salah satu metode implementasi AGILE. Selain agile ada juga Extreme Programming - mungkin pada topik mendatang saya akan mencoba untuk melihat lebih detail mengenai hal ini). 
  • Sprint ini adalah waktu yang pendek, mungkin sekitar 2 minggu. 
  • Pada saat tim agile menetapkan sprint atau iterasi selama 2 minggu, tim ini kemudian menetapkan 'incremental product'.
  • Misal, iterasi pertama (2 minggu pertama), tim menetapkan untuk membuat 'screen untuk input data pegawai', iterasi kedua kemudian tim menetapkan incremental kedua dan seteruskan.
  • Selama 2 minggu ini, tim Agile berkolaborasi secara terus menerus dan mereka memiliki meeting harian lebih kurang 15 menit. 
  • Pada tim agile, semuanya bertanggung jawab terhadap incremental product. Mereka adalah satu kesatuan sebagai tim (orang bisnis, orang IT dan fasilitator). Selama 2 minggu itu, mereka berdiskusi, mendesain, membuat program dan testing secara bekerja sama sehingga incremental product itu siap untuk di deploy. 
  • Umumnya, konsep ini akan berjalan sangat baik jika semua anggota agile berada pada lokasi yang sama. Mereka harus berdiskusi tiap hari lebih kurang 15 menit dengan 3 agenda utama (apa yang telah dikerjakan kemaren, apa yang akan dikerjakan hari ini dan kendala apa yang bisa menghambat progress).




Pada pendekatan waterfall, seolah-olah terdapat kontrak kerja antara pihak User dan IT yang dituangkan dalam user requirement. Pada metode Agile, User dan IT berkolaborasi bersama. Mereka menetapkan secara bersama apa yang ingin dibangun pada setiap iterasi, mereka sama-sama melakukan testing dan mereka bersama-sama belajar dari satu iterasi ke iterasi berikutnya. Setiap iterasi mereka selalu menghasilkan incremental produk yang tentu saya workable, tested dan membangun integrasi dari satu iterasi ke iterasi berikutnya.

Mari kita lihat beberapa kelebihan yang ditawarkan oleh pendekatan ini.
  • Selalu terdapat RUNNING version. Sejak dari  iterasi pertama selesai, kita telah memilki versi yang sudah berjalan dan dapat kita manfaatkan. Misal, kita telah memiliki fungsi untuk memasukkan data.
  • Error dapat lebih mudah untuk diidentifikasi. Karena tim bekerja secara kolaborasi dan incremental, error akan mudah terdeteksi lebih awal dan perbaikan dan dikerjakan secara cepat. 
  • Respon terhadap error menjadi lebih cepat karena tim user dan IT saling berkolaborasi sebagai satu tim tanpa ada sekat. Sehingga proses perbaikan menjadi lebih cepat dan tepat.
  • Agile juga menjadikan aplikasi "time-to-market". Respon terhadap kebutuhan pun menjadi lebih cepat. Karena prioritas incremental item pada setiap iterasi dapat menyesuaikan kebutuhan di market dan tim dapat memberikan respon yang cepat.

Summary 

AGILE sangat cocok digunakan pada tim IT dan user berada pada kondisi "uncertain requirement combined with unpredictable technology". User dan IT berkolaborasi bersama untuk memcoba menggali solusi secara bertahap dan terdapat proses pembelajaran dati setiap iterasi.

Jika user mampu untuk menggambarkan user requirement secara terstruktur dan menyeruh, serta diikuti oleh tim IT yang sagat familiar dengan proses bisnis dari aplikasi yang sedang dikembangkan, waterfall model akan memberikan solusi yang effisien. Hal ini karena, tim IT dan user dapat memprediksi hasil akhir jauh lebih terstruktur dan bisa mempersiapkan solusi yang cepat dan tepat guna menyelesaikan aplikasi tersebut.

NEXT

Semoga tulisan ini dapat memberikan gambaran tentang adanya pendekatan rekayasa perangkat lunak AGILE sebagai alternatif pendekatan Waterfall yang sudah kita kenal luas. Selanjutnya, saya akan mencoba untuk mempersiapkan tulisan berikutnya untuk memberikan gambaran yang lebih detail dan beberapa metode yang dapat digunakan untuk mengimplementasikan AGILE.
  • Karakteristik dari pengembangan AGILE, apa saja prinsip pokok dari sebuah implementasi AGILE dan manisfesto AGILE
  • Agile Menggunakan Extreme Programming (XP), metode ini berfokus pada programming practices
  • Agile Menggunakan Scrum, metode ini, metode ini berfokus pada project management
  • Lean Development dan Kanban, metode ini mencoba mengadapsi proses manufaktur yang diperkenalkan oleh TOYOTA dalam rekayasa perangkat lunak.


--------
Link:
Topik tentang mengenai kehidupan di Singapura: Kehidupan di Singapura 
Topik tentang mengenali teknologi informasi: Mengenali Teknologi Informasi

Semoga Bermanfaat

Singapore, Januari 2014
"Dipersiapkan selama perjalanan rumah-kantor di atas MRT (pengguna setia MRT)"


Catatan Pendidikan Menengah (SMP) atau Secondary School di Singapura

Perjalanan pendidikan atau education journey yang akan dilalui oleh lulusan SD atau Primary School akan berlanjut ke jenjang berikutnya yang...