Monday, March 11, 2013

Software Documentation Hierarchy


Disclaimer: kontent posting ini adalah opini dari penulis dan merupakan konten yang experimental, oleh karena itu sangat boleh untuk didebat dan penulis tidak diwajibkan untuk mempertahankannya.

Sewaktu melihat artikel wikipedia tentang software documentation, menurut Saya diperlukan konsep yang berbeda untuk kategorisasi dokumentasi software sebagai komplemen dari kategorisasi yang sudah dikemukakan di artikel tersebut. 

Konsep kategori pada artikel tersebut dibuat dari perspektif pengembangan, sehingga untuk situasi dan kondisi tertentu justu akan kontra-produktif. Misalnya, ada seorang programmer yang ingin mencari tau bagaimana cara install open source software X, kemudian dia mengambil dokumentasi mengenai arsitektur. Dia hanya akan dibombardir oleh informasi-informasi yang belum dia butuhkan, yang mungkin sekali akan membuatnya bingung.

Oleh karena itu, perlu dibuatkan lagi kategorisasi software documentation yang dirancang berdasarkan kebutuhan, situasi dan kondisi user, kategori tersebut yakni:
  1. Dokumentasi yang membuat pembaca bisa menggunakan software
  2. Dokumentasi yang membuat pembaca bisa meng-install software
  3. Dokumentasi yang membuat pembaca bisa mengkonfigurasi software
  4. Dokumentasi yang membuat pembaca bisa meng-compile/build software
  5. Dokumentasi yang membuat pembaca bisa mengembangkan software
Dengan kategorisasi diatas, dapat dilihat bahwa kategori tersebut merupakan konsep hirarki dokumentasi. Hirarki yang dibangun berdasarkan dependencies dari pengetahuan mengenai perangkat lunak tersebut dan kebutuhan user. Dengan begini, pembaca dokumentasi bisa mendapatkan gambaran mengenai informasi-informasi apa saja yang akan didapat sesuai dengan hirarkinya.

Terkait dengan kebutuhan project, perlu dianlisis terlebih dahulu sampai mana kebutuhan dokumentasi yang diperlukan, karena semakin dalam kebutuhan yang ada, akan semakin mahal membuatnya. Analisis ini dapat mempertimbangkan juga profil user project tersebut, apabila tidak ada programmer atau developer didalam jajaran user, maka hirarki Level 3 (Konfigurasi Software) adalah level terdalam yang masih efektif untuk dibuat.

Monday, March 4, 2013

Pentingnya Performance dalam Software


Abis nonton video disini: http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-046j-introduction-to-algorithms-sma-5503-fall-2005/video-lectures/lecture-1-administrivia-introduction-analysis-of-algorithms-insertion-sort-mergesort/

Baru 25 menit nonton, sudah mendapatkan pencerahan yang outstanding. Ada alasannya memang, kenapa MIT terkenal sebagai salah satu universitas Top di Dunia, kuliah undergraduate-nya saja masih bisa memberikan pencerahan kepada salah satu lulusan S2 ITB. 

25 menit awal tersebut membicara performance. Professor tersebut menanyakan hal apa yang lebih penting dari performance? beberapa mahasiswa menjawab:
  • Correctness. Benar atau tidaknya program
  • Stability/ Robustness. Robust atau tidaknya program
  • Programmer Time. Waktu yang dihabiskan untuk membuat program
  • Scalability. apakah program bisa di scale-up-kan atau tidak
  • User-Friendliness. Apakah program mudah digunakan atau tidak
  • Security. Keamanan dari program
Kemudian professor tersebut menambahkan lagi:
  • Modularity. Modularitas program, agar bug/perubahan di satu tempat tidak mempengaruhi tempat lain
  • Functionality. Apakah program memiliki fitur-fitur yang lengkap atau tidak
Ternyata banyak parameter yang lebih penting dari performance. Lantas mengapa justru performance yang dipelajari?
Melihat parameter-parameter lain diatas yang lebih penting dari performa, apabila ditelusuri lebih dalam, sebenarnya membutuhkan performa. Sebagai contoh:
  • User-Friendliness. Program jadi not so user friendly kalo ada lag ato musti nunggu lama
  • Correctness. Bila ada kebutuhan 'real-time', performance kurang baik yang mengakibatkan ada delay 1 menit akan membuat program tersebut not so realtime
Oleh karena itu, performa adalah mata uang dalam program. Dengan performa, security bisa diaplikasikan. Dengan performa, user-friendliness bisa dicapai, dengan performa, correctness bisa dipenuhi. Parameter-parameter lain dipenuhi oleh performa. Parameter-parameter lain di-'beli' oleh performa. Perfoma by itself tidak penting, namun menjadi salah satu paling penting jika digunakan untuk mengadakan parameter-parameter lain. Mirip dengan uang, by itself uang tidak bisa dimakan, dikenakan, ditinggali, namun uang bisa digunakan untuk mengadakan makanan, baju, tempat tinggal dan lain-lain.

Semoga bermanfaat, dan please do visit link diatas jika ada waktu senggang.

Friday, November 2, 2012

Salah Satu Ahli Surga

Dapet cerita waktu ceramah Idul Adha, ceritanya inspiratif, setidaknya menurut gw. Credits untuk yang pertama kali menceritakan ini, dan Uztad yang ceramah di Idul Adha Jatiwaringin Asri Blok E deket puskesmas tempat gw sholat ied, hehe.

 ---------------------------

Alkisah pada suatu waktu, Rasulullah SAW sedang menunggu sholat dzuhur di mesjid bersama sahabat-sabahat-nya. Ditengah-tengah menunggu adzan, Beliau berkata sebentar lagi seorang ahli surga akan melewati pintu mesjid. Sahabat-Sahabat kemudian memperhatikan pintu tersebut, kemudian didapati seorang pemuda Anshor yang nampak biasa-biasa saja, bukan termasuk sahabat terdekat Rasulullah.

Kejadian ini berulang sampai beberapa kali, Rasulullah SAW mengatakan ahli surga akan masuk melewati pintu mesjid, dan didapati pemuda tersebut lagi yang muncul. Singkat kata, memang pemuda tersebut yang dimaksud Rasulullah SAW sebagai ahli surga.

Kemudian salah satu sahabat sangat penasaran dan berniat mengetahui alasan mengapa pemuda tersebut dikatakan ahli surga. Sahabat tersebut mendatangi pemuda untuk meminta izin menginap di rumah pemuda tersebut beberapa hari dengan alasan tidak bisa pulang ke rumahnya sendiri. Sang Pemuda mengizinkan dengan senang hati.

Sahabat mengamati betul Sang Pemuda, diikuti gerak-geriknya dirumah atau diluar rumah, untuk mencari amalan khusus apa yang dilakukan sang pemuda sampai Rasulullah SAW menyebutkan ahli surga. Setelah beberapa hari mengamati, Sang Sahabat tidak menemukan amalan khusus tersebut. Ia memutuskan untuk berhenti mengamati dan akan pamit kepada Sang Pemuda.

Ketika berpamitan, Sang Sahabat mengatakan sejujurnya bahwa sebenarnya ia sedang mengamati Sang Pemuda untuk mencari amalan khusus, dan tidak ditutupi kekecewaaannya karena tidak menemukan amalan tersebut. Sang Pemuda tersebut menjawab, memang beginilah apa adanya dirinya, dan amalan-amalan yang ia lakukan tidak ada yang belum dilihat oleh Sang Sahabat.

Namun ketika Sang Sahabat hendak pergi, Sang Pemuda mengatakan bahwa ia selalu bersyukur, puas dan merasa cukup atas nikmat Allah yang diberikan kepadanya, terus gigih berjuang mengejar nikmat-nikmat Allah lainnya dan tidak pernah sekalipun merasa iri atau tamak atas nikmat Allah untuk orang lain yang tidak dimilikinya atau tidak diberikan Allah kepadanya.

Mendengar perkataan Sang Pemuda, Sang Sahabat sadar bahwa inilah kualitas yang Sang Pemuda yang menjadikannya seorang Ahli Surga.
---------------------------

Setidaknya sekarang gw tau, ada  1 lagi kualitas seorang muslim yang perlu dimiliki. Semoga dapat mencapainya 100%, aamiin.

Thursday, August 2, 2012

Hikmah Dari Upaya Contribute Ke Open Source

Sudah menjadi knowledge umum di internet kalau cara termudah untuk bekerja sama dengan orang-orang brilian di seluruh dunia adalah dengan bergabung ke open-source project mereka. Project-project open-source tertentu memang ada yang sarat dengan ilmu, dan Bombermaaan salah satunya.

Awalnya ngeliat bombermaaan dari game di liberkey, karena dulu waktu kecil suka bermain game itu, maka di download-lah dan dimainkan. Begitu ditekahui bombermaaan itu open source, iseng-iseng checkout source-code-nya, ngeliat to-do list-nya, mau mencoba implement team-mode.

And that turns out to be a good decision, ngeliat code-based-nya project bombermaaan, akhirnya sadar betapa bergunanya komentar kode yang konsisten dan extensive. Author-author sebelumnya seperti memulai coding dengan pseudocode, setelah rampung baru dicoding ke bahasa spesifik (C++). Pseudocode tersebut akhirnya menjadi komentar-komentar yang sangat membantu dalam pembacaan kode, penelusuran kode, dan tentunya dalam memahami apa yang terjadi pada kode.

Selama ini Saya berpikir bahwa naming variabel, method dan class yang baik cukup untuk membuat suatu kode nyaman dibaca. Namun setelah melihat kode bombermaan, hal tersebut saya sadari salah karena meskipun kode tersebut memiliki naming yang baik, komentar-komentar yang berupa pseudocode-nya lah yang paling membantu saya dalam memahami kode.

Saat ini sedang menunggu balasan author-nya untuk request agar mereka melihat hasilnya dan meminta feedback. Semoga lancar dan akhirnya kode dicommit, sehingga bisa dihitung telah benar-benar contribute kode ke open source project.
-------
Update: Author sudah me-reply, dia menyarankan untuk melakukan fork-ing terhadap project ini karena memang tidak ada aktivitas lagi di project ini dari original author-author-nya. Sayang sekali saya belum berpikir untuk memaintain suatu open source project. Berarti saatnya hunting open source project lain untuk berkontribusi. Ada ide?




Monday, January 2, 2012

Manajemen Proyek Pragmatis dan Agile

Bulan lalu beres baca buku ini, dan mau berbagi pemahaman yang didapat dari buku tersebut. Karena pemahaman yang akan di-share, maka isinya sebenarnya jauh sekali dari kualitas dan detail level-nya antara buku tersebut dengan artikel berikut. Jika tertarik, saran Saya, bacalah bukunya.

Disini pembahasan dibagi menjadi dua section, yaitu Starting Project dan Doing Project

Starting Project
Pada suatu project akan terdapat ekspektasi dari customer & sponsor, serta batasan yang harus dipenuhi. Contoh daftar ekspektasi dan batasan adalah sebagai berikut:


  • Harus selesai dibulan Januari
  • Memiliki fitur A, B, C, D
  • Biaya tidak lebih dari 10 juta
  • Mudah digunakan
  • Bug-free
  • High performance
  • Dan lain-lain

Masing-masing item pada daftar yang dibuat untuk suatu project, diprioritaskan berdasarkan kepentingannya, dan dibagi menjadi 3 kategory. Driver, Constraint, dan Float.

Driver
Driver adalah item utama yang memberi nilai pada project. Kegagalan memenuhi Driver dapat menghilangkan seluruh nilai dari Project. Hanya ada 1 item pada daftar yang boleh dikategorikan sebagai Driver. Lebih dari 1 Driver, maka project akan kacau.

Sebagai contoh, terdapat suatu project yang diharuskan selesai pada bulan desember, fitur/harga/kualitas seperti apapun tidak ada artinya jika belum selesai desember. Maka project Driver-nya adalah waktu.

Constraint
Beberapa item dengan prioritas tinggi namun dibawah Driver dapat dikategorikan Constraint. Kategori constraint boleh diberikan ke lebih dari 1 item.

Constraint perlu dipenuhi agar customer/sponsor. Apabila Constraint dengan Driver saling konflik, Constraint bisa tidak dipenuhi, namun akan menbuat customer/sponsor tidak senang. Apabila seluruh Constraint tidak terpenuhi, nilai project akan hilang seluruhnya, seperti halnya jika Driver tidak terpenuhi.

Constraint idealnya dua, lebih dari itu project menjadi un-managable. Kurang dari itu, project akan kacau karena seakan terdapat dua Driver.

Float
Float kategori item yang penting untuk dipenuhi, namun memiliki fleksibilitas dalam pencapaiannya dan dapat dinegosiasi dengan customer/sponsor mengenai targetnya.

Sama seperti Constraint, kategori Float dapat diberikan kepada lebih dari 1 item, idealnya 3. Tidak memenuhi seluruh Float akan mengakibatkan costumer/sponsor tidak senang, memenuhi seluruh Float akan membangun reputasi yang baik.



Release Criteria
Berbekal daftar Driver, Constraint, dan Float, tuliskan kondisi done untuk project, yang disebut dengan Release Criteria. Release Criteria harus Specific, Measurable, Achievable, Relevant dan Trackable ke daftar Driver, Constraint dan Float. Baik customer, sponsor, management dan pelaksana perlu mengetahui dan menyetujui Release Criteria.

Contoh Release Criteria:

  • Software Release tanggal 1 januari
  • Normal Skenario untuk fitur A, B, C tanpa bug-free
  • Halaman D, E, F dapat diakses hanya dengan 2 kali click.


Product Backlog
Last but not least, tuliskan dokumen Product Backlog. Product Backlog adalah dokumen yang berisikan daftar fitur sistem yang diberi angka prioritas. Prioritas diberikan oleh pemiliki sistem, dengan pertimbangan ROI bisnis. Perhatikan bahwa 1 angka hanya untuk 1 fitur, tidak boleh terdapat dua fitur yang memiliki angka prioritas yang sama.


Doing Project
Project dilaksanakan dengan life cycle iterative incremental. Berbekal Product Backlog yang dimiliki sebelumnya, project dilakukan dengan:

  1. Melaksanakan Iteration Planning Meeting di awal iterasi, yang melakukan
    1. Memilih fitur-fitur dengan angka prioritas tertinggi yang belum selesai
    2. Merencanakan waktu  1 iterasi dengan maksimal waktu 2 minggu
    3. Lakukan requirement gathering untuk fitur-fitur yang dipilih bila perlu
    4. Mem-breakdown fitur tersebut dengan task-task kecil yang dapat diselesaikan maksimal 8 jam.
    5. Mengestimasi man-hour untuk setiap task
    6. Membuat perencanaan dan target selesai untuk seluruh task tersebut
  2. Melaksanakan pertemuan harian untuk memantau pencapain rencana sepanjang iterasi
  3. Melaksanakan Iteration Review Meeting di akhir iterasi, yang:
    1. Apabila target tercapai, demokan fitur-fitur tersebut
    2. Apabila target tidak tercapai, lakukan evaluasi, targetkan demo untuk iterasi berikutnya

Lakukan kegiatan diatas berulang sampai Release Criteria terpenuhi


Change Request
Perubahan prioritas Product Backlog ataupun perubahan fitur-fitur yang ada pada Product Backlog dapat dilakukan kapan saja selama fitur tersebut bukan merupakan fitur yang sedang dalam pengerjaan iterasi.

Perubahan pada fitur yang telah diselesaikan iterasi sebelumnya menjadi prioritas utama untuk dikerjakan pada iterasi berikutnya.



----------

Sebenarnya buku tersebut membahas jauh lebih detail dan memberikan banyak sekali contoh kasus. Buku yang menurut Saya must-read untuk developer yang ingin mengetahui konsep agile project management, yang dilakukan dengan Pragmatic Way. Semoga bermanfaat.