TOGAF 9

Belum lama ini, 4 Februari 2010 telah dirilis TOGAF versi 9.

TOGAF merupakan singkatan The Open Group Architecture Framework yaitu framework maupun metodologi untuk arsitektur IT atau sering disebut Enterprise Architecture (EA). Bisa dikatakan TOGAF merupakan acuan (guide) untuk merancang atau membangun sebuah EA.

Dokumen TOGAF versi 9 bisa diunduh dari website The Open Group setelah melakukan registrasi.

TAM (Technical Achitecture Modeling) = FMC + UML

Buat anda yang sering mendesain software, tentu sudah terbiasa dengan menggunakan diagram untuk menggambarkan arsitektur dari sistem yang dibangun. Anda pasti kenal UML (Unified Modeling Language). Jika anda merasa bahwa UML tidak cukup representatif untuk menggambarkan konsep arsitektur sistem yang akan dibangun, tenang saja anda tidak sendiri.

Sudah banyak orang setuju bahwa UML cukup representatif untuk menggambarkan detail desain. Tapi untuk menggambarkan arsitektur, mungkin ada baiknya anda menengok FMC (Fundamental Modeling Concept), sebuah alternatif untuk mengambarkan diagram arsitektur, hubungan antar module/elemen dan flow proses.

Dibawah ini adalah gambar yang mengilustrasikan dimana FMC "mengisi batas" antara proses perancangan architecture dengan detail design dalam proses pembangunan software.


FMC seperti halnya UML memiliki beberapa jenis diagram, untuk menggambarkan arsitektur pada tataran konsep (high level) anda bisa gunakan block diagram.

Block diagram pada FMC bersama-sama dengan diagram lain dalam UML telah menjadi standar dalam perusahaan SAP dan diberinama TAM (Technical Achitecture Modeling). Berikut ini contoh sebuah block diagram:


Gambar diambil dari artikel "How to communicate architecture – Technical Architecture Modeling at SAP"

Berikut beberapa artikel tentang TAM:

• Standardized Technical Architecture Modeling, Conceptual and Design Level
• How to communicate architecture – Technical Architecture Modeling at SAP (part 1 & Part 2)
  

Beberapa tools untuk menggunakan TAM:

• Rangkuman diagram pada TAM (pdf)
  
• Visio stencil
  

Silo: Siloed applications, siloed systems, siloed information. Apa artinya?

Akhir-akhir ini sering dengar istilah silo dan digunakan pada kata lain sehingga menjadi siloed applications, siloed systems atau siloed information.

Sebenarnya silo adalah sebuah tangki silinder vertikal. Sebuah aplikasi atau sistem yang memiliki fungsi tertentu biasanya digambarkan sebagai sebuah silinder vertikal dan aplikasi atau sistem dengan fungsi yang berbeda digambarkan oleh silinder vertikal lain. Dalam sebuah perusahaan aplikasi yang digunakan dengan fungsi yang berbada biasanya banyak dan tiap aplikasi memiliki data/informasi tersendiri. Mereka independent, tidak terintegrasi atau tidak saling berkomunikasi sehingga sulit untuk membuat rekonsiliasi antar sistem. Paradigma arsitektur itulah yang disebut sebagai siloed systems atau siloed applications.

Ensiklopedia PC Magazine ditulis tentant siloed application:

An application that does not interact with other applications or information systems. A siloed application is any software that functions on its own to solve a problem. Such applications are often found within the many departments of large enterprises.

Sedangkan di wikipedia ditulis tentang information silo:

An information silo is a management system incapable of reciprocal operation with other, related management systems.

Manajer proyek harus tau jika bawahannya overload

Salah satu kemapuan yang harus dimiliki seorang manajer proyek (PM) adalah jeli melihat kondisi bawahan atau timnya. Kondisi anggota timnya yang overload bisa sangat memperngaruhi kinerja keseluruhan, oleh karena itu dia harus jeli melihat secara personal dari masing-masing anggota timnya. Kemampuan ini tidaklah mudah karena menyangkut psikologi manusia, seorang PM sering pula mengabaikan masalah overload ini.

Mengapa kadang sulit mengetahui seseorang overload atau tidak? Pertama adalah masalah kepedulian. PM sering tidak peduli dengan anggota timnya, yang dipikirkan PM hanyalah proyek yang selesai tepat waktu. Padahal nilai suatu proyek tidak bisa dilihat dari selesai tidaknya saja. Dalam dunia software, pekerjaan yang selesai tapi dengan kualitas yang buruk akan menjadi bom waktu bagi perusahaan. Klien menjadi tidak puas, biaya akan membengkak, tim bisa acak-acakan karena ada yang keluar dan anggota baru dan efek-efek lain yang merugikan perusahaan.

Secara psikologis, keadaan overload seorang programmer akan secara langsung mempengaruhi kualitas kerja dan otomatis mempengaruhi kualitas software yang dihasilkan. Tapi sayangnya banyak programmer yang tidak sadar dirinya overload. Programmer yang tidak sadar dirinya overload atau tidak mau mengakui dirinya overload, sayangnya sangat disukai oleh PM. Sebaiknya justru PM harus jeli melihat tipe programmer seperti ini.

Programmer atau anggota tim apapun posisinya harus dihindari dari overload. Lembur sekali dua kali dalam sebulan adalah hal yang wajar dan mungkin belum bisa dibilang overload, oleh karena itu PM juga harus punya kejelian kapan overload terjadi. Lembur hampir tiap hari yang terjadi dalam satu bulan pun bisa dikatakan tidak overload. Overload tergantung dari apa yang dikerjakan anggota tim atau individu bukan dilihat dari banyaknya kerja diluar batas waktu atau lembur.

Akses CVS dengan SSH tunneling

Dalam tulisan ini saya akan menjelaskan bagaimana menggunakan koneksi SSH untuk mengakses repository CVS dengan menggunakan CVS client. Tulisan ini berdasarkan pengalaman yang telah saya lakukan. Mesin untuk CVS server yang saya gunakan adalah Linux dan mesin yang saya gunakan sebagai client adalah Windows.

Pertama saya install CVS server di mesin Linux kemudian membuat repository. Kemudian setup cvs pserver yaitu membuat configurasi xinetd untuk membuka service untuk cvspserver.

Dengan menggunakan PuTTYgen saya membuat public key dan private key. Dari program tersebut saya dapatkan text untuk dimasukan ke file authorized_key di server, seperti ini:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIBMFXliQrC16kZwFH1YOl/n3leI5aK13gFYiPFKFSBCFikNzJL5Su9PrJB0fJ7ZgSHKc/2
s+tWaXvfS6yWsGTQ81T49YidfQu/M14QgHTvpe23h8NaBRr+HuxDil0euUnolOcFchXraS5APe+yrqNIKSotGAxpfyPDpXTAZsAgdhQ== 
rsa-key-20061115

dan sebuah file yang disave bernama cvsadmin_private_key.ppk

Di server Linux saya dimana CVS diinstall, saya buat user cvsadmin kemudian pada home direktori user cvsadmin saya buat direktori .ssh/ kemdian di direktory tersebut saya but file authorized_key dengan isi seperti contoh diatas.

Kemudian saya buat kofigurasi untuk SSH daemon (sshd) di /etc/ssh dengan cara mengkopi konfigurasi yang sudah ada kemudian memodifikasinya. File konfigurasi yang baru ini saya beri nama sshd_config_ext.

Bagian penting dari isi file configurasi tersebut (tidak semua dicantumkan disini) adalah:

Port 4321
Protocol 2
PasswordAuthentication no
AllowTcpForwarding yes
AllowUsers cvsadmin

Saya menggunakan port 4321 yang tidak biasa dipakai untuk service ssh. Authentication menggunakan password saya set 'no' untuk meningkatkan keamanan karena authentication yang saya buat akan menggunakan key pair yang telah dibuat menggunakan PuTTYgen.

Setelah itu saya jalankan sshd dengan menggunakan file configurasi tesebut:

    /usr/sbin/sshd -f /etc/ssh/sshd_config_ext

Di sisi client untuk koneksi ke server CVS menggunakan tunneling, saya menggunakan program PuTTY. Saya buat session baru untuk koneksi ke server CVS. Saya lakukan setting SSH connection pada bagian 'Auth' dengan menspesifikasikan file private key yaitu file cvsadmin_private_key.ppk yang telah saya buat sebelumnya.

Saya juga set SSH connection pada bagian 'Tunnels' dengan menambahkan port forwarding rule. Saya isi source port dengan 2401 yaitu port yang digunakan untuk CVS pserver di server Linux dan saya isi destination dengan '127.0.0.1:2401' yaitu mesin destop saya yang akan saya gunakan untuk development. 2401 adalah standar port untuk CVS pserver.

Hasil yang saya dapatkan setelah menambahkan seting port forwarding tersebut adalah:

L2401 127.0.0.1:2401

Dengan membuat session tersebut di PuTTY, setiap saya melakukan koneksi menggunakan session tersebut maka di lokal mesin saya akan dibukan port 2401. Port tersebut seolah-olah adalah port 2401 di mesin CVS. Koneksi ke mesin CVS sebenarnya tidak menggunakan port 2401 tetapi port 5000 dengan protokol SSH. Inilah tunneling.

Akhirnya setelah saya berhasil melakukan login (koneksi) menggunakan session pada PuTTY, saya dapat menggunakan CVS saya. Yang saya lakukan pada CVS client, dalam hal ini saya menggunakan Eclipse development tool, saya buat koneksi CVS pserver ke localhost port 2401.

Dengan cara seperti ini transaksi dengan CVS server menjadi aman. Server CVS juga dapat dipindah-pindah tanpa perubahan apapun di CVS client.

Rencanakan dokumentasi anda!

Saat ini aya berada di sebuah proyek software (integrasi sistem) dengan beberapa technical lead, senior architect dan lain-lain. Pada awal proyek telah dijelaskan bahwa akan ada dokumen: requirement specification, functional specification dan design specification. Itu saja.

Setelah requirement spec selesai, saya rasa mereka semua bingung dengan struktur dari dokumen functional spec. Kenapa? saya pikir ini karena tidak direncanakannya dokumentasi yang akan dibuat. Buat saya requirement spec yang telah dibuat lebih menyerupai functional spec. Requirement spec yang kita buat berisi section yang dibagi berdasarkan fungsionalitasnya. Dalam tiap section terdiri dari beberapa sub-section yaitu

• Description yang menjelaskan sedikit mengenai fungsi yang ditulis dalam judul section
  
• Assumptions
  
• Use case diagram yang berisi sequence diagram (dalam terminologi UML), yang memperlihatkan interaksi antar system yang akan dibangun
• Requirements, yang mejelaskan dengan kata-kata diagram yang ada di sub-section sebelumnya atau menjelaskan kebutuhan dengan sedikit mendetail.
  
• Impacts

Bahkan di requirement spec dituliskan :

It also contains a detailed analysis of business, process, functional and operational model in order to provide context and background to the approach.

Bisa dilihat bahwa requirement spec sebenarnya adalah functional spec. Sehingga ketika kita dituntut untuk membuat functional spec yang terjadi adalah kebingung.

Kebingunan bertambah setelah seorang senior architecht yang 'dituakan' mengirimkan contoh functional spec dari project lain yang jelas-jelas di judul dokumen tersebut tertera ".... architectural documentation." Buat saya functional spec sangat berbeda dengan architectural spec.

Itulah sebabnya saya rasa perencanaan terhadap dokumen yang akan dibuat penting. Perencanaan dokumen tidak hanya merencanakan dokumen apa saya yang akan dibuat atau diberikan ke klien tapi lebih dari itu kita perlu merencakan struktur dan isinya.

Perencanaan menjadi penting juga karena biasanya tiap orang yang terlibat dalam proyek memiliki persepsi yang berbeda-beda tentang suatu dokumen. Kita tahu juga banyak sekali bentuk-bentuk dokumen standar yang digunakan dalam software development, misalnya standar IEEE, ISO, atau bahkan standar dari perusahaan. Kita bisa saja menggunakan standar dokumen yang ada tetapi sebaiknya selalu disesuaikan dengan proyek yang dijalankan.

Jangan refactor kode orang lain tanpa memberitahukannya.

Refactor adalah pekerjaan yang baik, tetapi jangan lakukan jika refactor menyangkut kode orang lain tanpa memberitahukan detil apa yang telah di-refactor kepada orang yang telah menuliskan kode tersebut.

Refactor yang dilakukan tanpa diketahui orang yang menulis kode tersebut akan menyebabkan produktifitas menurun. Ini karena orang yang menuliskan kode pertama harus mempelajari kembali dan melakukan pelacakan perubahan. Lebih baik lagi jika perubahan selalu diinformasikan kepada semua anggota tim.

Component/dependecy analyst

Setelah selesai membuat suatu program/software, ada baiknya Anda lakukan analisis komponen yaitu analisis ketergantungan antar modul atau komponen yang ada pada program/software Anda untuk kemudian anda dapat me-refactor kode program sehingga hubungan antar komponen menjadi lebih teratur (nggak jelimet).

Beberapa aplikasi untuk component/dependecy analyst untuk program Java diantaranya:

http://clarkware.com/software/JDepend.html
http://www.kirkk.com/Main/JarAnalyzer

Permasalah requirement.

Dari hasil pengalaman, saya tuliskan dibawah ini beberapa kendala yang terjadi pada saat proses menspesifikasikan requirement:

• Requirement melibatkan beberapa orang dari client yang memiliki pendapat yang berbeda mengenai suatu masalah. Kadang-kadang malah VISI yang mereka punya berbeda-beda.
• Proses requirement tidak melibatkan end user yang benar-benar akan menggunakan software/system yang dibuat.
• Client terlalu sibuk, dikerjar dengan pekerjaan rutinnya shingga meeting untuk requirement terganggu.
• Business analyst menjdi frustasi karena suatu requirement yang telah dibahas panajang lebar di-drop oleh menajer client.
• Business analyst terpatok pada satu cara/teknik requirement gathering yaitu meeting/interview (berdikusi secara langsung dengan user).
• Meeting tidak efektif karena tidak mempertimbangkan siapa saja yang seharusnya hadir dan siapa saja yang seharusnya tidak ikut dalam meeting.
• Manajer yang memiliki kemampuan untuk memutuskan melakukan pengambilan keputusan yang sebenarnya tidak dapat dijalankan secara teknis oleh bawahannya. hal ini bisa terjadi karena sebenarnya manajer tidak mengetahui secara detail bagaimana proses bekerja di tingkat bawah.
• Client yang merupakan narasumber requirement, tidak mengetahui susahnya proses requirement gathering dan tidak mengetahui masalah-masalah yang akan timbul selama proses. Sehingga client mengalami frustasi sebelum proyek selesai.
• Adanya requirement yang tertinggal, biasanya adalah non-functional requirement misalnya adanya SLA (Service Level Agreement) seberapa cepat suatu proses harus selesai. Kadang-kadang business analyst memberikan solusi yang canggih tetapi tidak memikirkan waktu yang dibutuhkan untuk proses tersebut.
• Istilah yang digunakan tiap orang (client) berbeda-beda (lack of communication).
• Client tidak benar-benar mau melakukan review terhadap requirement yang didokumentasikan. Client malas untuk membaca SRS.

Prinsip Pareto atau prinsip 80/20

Satu nilai lagi yang saya dapat dari Dynamic Systems Development Method (DSDM) adalah Pareto Principle.

Tanpa sengaja minggu ini saya jalan-jalan ke toko buku dan menemukan buku, "Living the 80/20 Way" yang ditulis Richard Koch. Hal ini berarti tepat ketika pada hari yang sama saya baca sebelumnya di Internet tentang prinsip yang sama yaitu prinsip pareto yang digunakan sebagai nilai pada DSDM. Awalnya saya ragu apa yang dimaksud buku tersebut adalah pareto principle yang saya baca di Internet karena di buku tersebut tidak ada penjelasan sejarah tentang prinsip tersebut. Setelah beberapa bagian penting buku dibaca, ternyata itu buku kedua Koch tentang prinsip 80/20. Tidak lama saya menemukan buku pertamanya yaitu "The 80/20 Principle", dan dibuku tersebut dijelaskan mengenai prinsip 80/20 mulai dari awal. Barulah jelas bahwa prinsip yang dimaksud adalah memang prinsip pareto.

DSDM percaya pada filosofi prinsip Pareto ini, seperti yang dinyatakan dalam pernyataan berikut:

"A fundamental assumption of the DSDM approach is that nothing is built perfectly first time, but that 80% of the solution can be produced in 20% of the time it would take to produce the total solution."

Prioritaskan dengan MoSCoW

Saya belum pernah mempelajari Dynamic Systems Development Method (DSDM), sebuah Agile methology yang banyak dipakai di Eropa (karena memang metodologi ini lahir disana). Tapi proses belajar saya pada Agile methodology, mengantarkan kepada cara memprioritaskan dengan metode metode MoSCoW yang ada pada DSDM.

Methode MoSCoW merupakan cara pembagian prioritas dengan level yang ditentukan untuk suatu kebutuhan (requirement/customer need), fungsi dari produk ataupun bagian dari proyek yang akan dibuat. MoSCoW sebenarnya adalah singkatan dari Must, Should, Can, Won't yang merupakan tingkatan pada suatu item yang diprioritaskan.

• MUST berarti sesuatu yang harus dimiliki (MUST have this)
• SHOULD berarti harus dimiliki jika memungkinkan (SHOULD have this if at all possible)
• CAN berarti dapat dimiliki jika tidak berefek pada yang lain (CAN have this if it does not effect anything else)
• WON'T berarti tidak perlu dimiliki, tapi mungkin nanti (WON'T have this time but would like in the future)

Pemriositasan sebaiknya dilakukan pada fungsi ditingkat yang tinggi (high level fungtionality) yaitu kebutuhan/fungsi yang belum didetailkan (masih general) misalnya waktu menentukan kebutuhan modul-modul utama pada aplikasi, dan juga pada tingkatyang lebih rendah yaitu kebutuhan/fungsi yang lebih spesifik.

Melakukan prioritas, baik dilakukan untuk menentukan bagian mana yang akan dikerjakan atau tidak, juga untuk menentukan mana akan dikerjakan lebih dulu.Prioritas fungsi atau kebutuhan pada high-level juga membantu kita untuk menentukan yang bagian mana yang merupakan out-of-scope dari project.

Komponen penting yang menjadi pertimbangan prioritas adalah project scope, kualitas, waktu, resources, dan resiko [referensi]. Komponen tersebut bisa saling berbenturan sehingga melakukan prioritas bukan hal yang mudah.

Kadang-kadang project scope tidak didefinisikan dengan detail atau jelas pada saat proyek mulai berjalan. Klien atau customer juga cenderung ingin semuanya kebutuhannya dipenuhi. Hal ini semua menyulitkan kita dalam memprioritaskan kebutuhan.

Dalam perjalanannya, prioritas suatu kebutuhan/fungsi sangat mungkin sering berubah sehingga meprioritaskan kembali (reprioritisation) jangan menjadi hal tabu. Yang perlu diwaspadai adalah banyaknya perubahan prioritas yang drastis misalnya dari level WON'T ke level MUST. Jika hal itu terjadi maka ada sesuatu yang salah dengan awal proses prioritisasi atau tujuan awal (goal) dari proyek.

Feature-Driven Development (FDD)

FDD diinisialisasi oleh Jeff De Luca dan diperkenalkan ke publik lewat buku "Java Modeling In Color With UML" pada chapter 6, "Feature-Driven Development"

** Proses

FDD terdiri dari 5 proses atau aktifitas yaitu:

1. Pembuatan model keseluruhan (Develop an Overall Model)
2. Buat daftar fitur (Build a Feature List)
3. Rencanakan dengan fitur (Plan By Feature)
4. Desain dengan fitur (Design By Feature)
5. Membangun dengan fitur (Build By Feature)


Dan proses tambahan yang tidak kalah penting adalah (Track by Feature)

Domain Walkthough | Design | Design Inspection | Code | Code Inspection | Promote to build

** Best practises

# Domain Object Modeling
# Developing by Feature
# Individual Class (Code) Ownership
# Feature Teams
# Inspections
Inspeksi/review merupakan suatu hal yang penting dalam FDD. [http://www.featuredrivendevelopment.com/node/566]
# Regular Builds
# Configuration Management.
# Reporting / Visibility of Results

UI screen design is not a prototype.

Di perusahaan tempat saya bekerja sekarang, hampir dalam setiap proyeknya selalu membuat prototipe. Prototipe biasanya berupa screen yang dibuat dengan HTML dan javascript. Seiring dengan berjalannya proses requirement gathering dan pembuatan dokumentasi requirement, prototipe tersebut diubah-ubah mengikuti kebutuhan. Prototipe tersebut kemudian di capture dan dimasukan dalam dokumen desain software.

Apa yang client lihat adalah screen capture dari prototipe dalam sebuah dokumen. Client tidak benar-benar bisa menyentuh atau menggunakan prototipe tersebut. Biasanya client tidak jeli (malas) untuk me-review dokumen. Apalagi membayangkan 'flow of process' dari fungsionalitas software dengan hanya melihat screen-capture dan penjelasan teks. Hal ini membuat client setuju untuk mendatangani dokumen tanpa pernah merasakan bagaimana nantinya dia akan menggunakan software tersebut.

Hasilnya setelah software selesai dibuat, bisa terjadi banyak kekurangan-kekurangan yang dirasakan oleh client pada software yang diberikan (deliver). Kita bisa saja berargumen bahwa memang seperti itulah software yang diberikan, telah tertera dalam dokumentasi dan telah ditandatangani. Tapi akibatnya adalah ketidakpuasan client terhadap software yang kita berikan, karena bisa jadi kekurangan yang ada pada software adalah common functionality seperti misalnya fungsi menghapus (delete) pada suatu item.

Hal tersebut bisa terjadi sebenarnya karena prototyping sebenarnya tidak dilakukan.
Kesalahnya adalah:

• User tidak dibiarkan menggunakan sendiri 'prototype software'
• Prototipe berubah wujud menjadi UI screen design, karena hanya menjadi screen-capture yang ada dalam dokumentasi.
• Menggap tanda tangan adalah segalanya (sign-off is everything). Yaitu aggapan selama sudah dokumen sudah ditandatangani maka semuanya yang ada didokumentasi menjadi 'argueable' dan perubahan/tambahan terhadap feature akan menjadi change request.
  

Oleh karen aitu kita bisa meminimalisasi kesalah tersebut dengan membuat prototipe dan membiarkan user (client) menggunakan prototipe tersebut. Kita sebagai vendor sebaiknya hanya memberikan asistensi saat user mencoba protipe. Kesalahan atau kekurangan pada prototipe akan lebih mudah diterima oleh client dibanding, bugs yang ada pada software yang sudah diberikan atau dirilis.

Hasil UAT

Saya baru saja menyelesaikan UAT, dan dibawah ini beberapa kendala yang dihadapi:

• Software yang masih memiliki banyak bug karena kurang intensifnya internal test.
• Tim UAT dari client hanya terdiri dari 4 orang dan yang benar-benar terlibat hanya sastu orang.
• Tester hanya satu orang dan merupakan orang baru (orang yang tidak mengerti betul requirement)
• Tidak ada kontrol yang ketat dari project owner terhadap tester.
• Tim UAT dari vendor juga hanya satu orang, yang pekerjaannya adalah mengenalkan software, membantu testing secara teknis dan bug fixing.
• Tidak ada test scenario, yang ada adalah list modul yang akan ditest.
• Tidak menggunakan tools untuk test, sehingga retesting memakan waktu yang tidak sedikit.
• Test dilakukan di tempat client dengan keterbatasan evirontment seperti, tidak tersambungnya komputer development dengan test server.
• Repository berada di tempat saya bekerja (vendor) sementara development fase kedua yang masih berlangsung ketika UAT fase pertama dapat mengakibatkan perubahan dari code yang dihasilkan dari fase pertama.
• Birokrasi yang lama di tempat client seperti saat meminta account email untuk test.
  

Hasil keseluruan: UAT selesai dengan sukses.
Bagaimana bisa? Bisa, kuncinya adalah:

• Close relationship dengan client. Beri impresi bahwa kita selalu working on improvement.
• Selalu cepat untuk fixing bug atau solve issues.
• Jangan tekan client karena keterbatasan-keterbatasan atau problem internal yang mereka hadapi, selama mereka tidak menekan kita.
• Berikan pengertian, bahwa kendala/masalah tidak hanya datang dari vendor tapi juga dari client. Sehingga mereka tidak selalu menyalahkan kita. (Intinya sih cari alasan yang tepat deh)
• Jangan memberikan ide-ide baru untuk testing, biarkan apa yang mereka mau test tapi jangan tambah degan item yang seharusnya mereka test.
• Fokus pada fungsi utama, jika ada bug dan tidak menghalangi test berikutnya, lanjutkan test berikutnya.
• Restest semua fungsi (secara cepat) saat akhir UAT.
  

Catatan, sukses disini berarti client happy (paling tidak, mereka tidak kecewa) dan kita sebagai vendor juga akhirnya happy :-)

Sekilas tentang metodologi pembuatan software, SCRUM

Scrum adalah suatu metodologi yang mengatur (manage) proses pembuatan software.
Scrum yang dikategorikan pada agile software development methodology.
Lihat agile manifesto, untuk mengerti filosofi dibalik kata agile pada konteks software development methodology atau project management.

** Kenapa Scrum?

Scrum menarik karena scrum lebih condong pada cara me-manage proyek secara praktikal (practical process model). Lebih menuntun tim untuk melakukan hal-hal yang perlu dan menyarankan hal-hal yang tidak perlu dalam menginspeksi proses dan melakukan adaptasi terus meneus untuk menyetir arah dari proses. Tidak seperti metodologi manajemen proyek lain yang cenderung deskriptif dan heavyweight.

** Scrum Role
Orang yang terlibat dalam proses scrum dibagi menjadi 3 jenis peran (role), yaitu:

• Product Owner yaitu orang yang menentukan spesifikasi atau feature dari software yang akan di-deliver.
• ScrumMaster yang bertanggung jawab untuk mengatur scrum process selama proyek berjalan. Oleh karena itu ScrumMaster harus menguasai Scrum process. ScrumMaster adalah fasilitator, yang mempersiapkan dan memimpin pertemuan (meeting)
• Project Team (tim 7 plus minus 2) yang merupakan self-organizing team yang menjalankan project, seperti business analyst, software architect, developer, tester dan lain-lain.
  

** Teminologi ayam dan babi (chickens and pigs)

Terminologi ini dapat dijelaskan dengan lelucon dibawah ini:

A chicken and a pig decide to start a restaurant.
The pig says, "What should we call it?"
The chicken says, "How about 'Ham & Eggs'?"
The pig says, "No thanks. I'd be committed, but you'd just be involved."

Terminologi ayam (chicken) berarti orang yang berkepentingan terhadap proyek (involved) tapi tidak sepenuhnya terlibat dalam proyek.
Terminologi babi (pig) adalah orang yang terlibat sepenuhnya dalam proyek. Yang termasuk dalam kategori pig adalah anggota project team.


** Proses

Proses eksekusi proyek dengan menggunakan scrum, dapat dilihat pada gambar ini

• First meeting
• Proses scrum diawli dengan pebuatan tujuan yang akan dicapai dan product backlog.
  Product backlog dikuantisasi waktu dengan satuan hari (antara 1-20 hari)
  Product backlog merupakan ombinasi antara story-based work (pekerjaan yang berbasis use case/product feature) dan task-based work misalnya "Tambahkan validasi pada semua form"
  Product backlog diprioritaskan oleh product owner.
  
• Product backlog yang berisi list yang diprioritaskan dari fitur-fitur atau perubahan yang akan ada pada produk.

• Sprint planning meeting
• Meeting untuk product owner, scrum team dan orang-orang yg berkepentingan.
  
• Menentukan sprint goal yaitu tujuan yang ingin dicapai pada scrum sprint berikutnya (30 hari kedepan).
  Sprint goal biasa adalah minimum fungsinalitas yang harus dicapai.
  Jika sprint goal tidak dicapai maka dilakukan abnormal termination
• Membuat sprint backlog yaitu list dari pekerjaan yang akan dilakukan selama sprint.
  Sprint backlog merupakan bagian produck backlog yang didetailkan.
  Sprint backlog dikuantisasi waktu berdasarkan jam (bukan hari yaitu antara 1-16).
  Sprint backlog harus tranparan untuk semua orang dalam tim
• Meeting yang tidak lebih dari 8 jam saja.
  Dengan 4 jam pertama adalah waktu yang digunakan untuk Product Owner menjelaskan atau presentasi tentang prioritas dari product backlog.
  Kemudian tanya jawab dari tim tetang isi, maksud, tujuan dari item yang ada di product backlog.
• Empat jam berikutnya adalah sesi untuk tim merencanakan Sprint.
• Fokus pada melakukan pekerjaan bukan berfikir mengenai bagaimana mengerjakannya.
  

• Daily Scrum meeting (Inspect and adapt cycle)
• Meeting harian selama tidak lebih dari 15 menit
• Yang boleh bicara dalam tim ini adalah scrum master dan anggota tim (pigs)
• Orang lain yang bekepentingan (chickens) dapat ikut dalam tim tetapi tidak boleh berkomunikasi (berbicara)
• Scrum master menanyakan 3 pertanyaan dari kepada anggota tim:
• Apa yang sudah kamu lakukan kemarin (selama 24 jam kebelakang)?
• Apa yang akan dikerjakan pada esok hari (24 jam mendatang)?
• Hal apa yang bisa menghentikan pekerjaan besok hari (kendala)?
  

• Sprint review meeting
• Meeting setelah aktivitas selama 2 minggu atau 1 bulanan (Sprint) berakhir, yang kemudian diikuti oleh sprint planning meeting untuk Sprint berikutnya.
• Meeting sebagai review atas Sprint yang sudah dilaksanakan.
• Memperbarui (update) sprint backlog yang merefleksikan berapa lama waktu yg dibutuhkan untuk menyelesaikan pekerjaan (task)
  

• Sprint retrospective meeting
• Meeting setelah sprint review meeting dan sprint planning meeting ScrumMaster dengan tim untuk merevisi proses dan cara kerja Scrum, proses development agar Sprint berikutnya lebih efektif dan enjoyable.
• Meeting ini sebaiknya tidak lebih dari 3 jam.
  

** Burndown charts

Burndown charts adalah grafik yang menunjukan seberapa banyak waktu yang dibutuhkan untuk menyelesaikan proyek. Grafik ini merefleksikan progress dari proyek.

Y-axis: Sisa waktu yang diperlukan untuk menyelesaikan pekerjaan (dalam jam)
atau jumlah item pekerjaan yang masih harus diselesaikan
X-Axis: Tanggal

Referensi tentang burndown chart yang cukup detail bisa dibaca di artikel "Earned-Value and Burn Charts"

** Artikel lain
Adaptive Project Management Using Scrum.
File presentasi yang bagus tentang SCRUM

Pentingnya template

Aku baru saja melihat seorang teman memiliki beberapa template file bahkan file-file (jamak) dalam suatu direktori. Direktori tersebut juga sebuah template, template dari suatu proyek. Jadi terbersit hati ingin menulis betapa pentingnya template. Kadang kita secara sadar membuat template tapi kadang kita lupa hal-hal yang hampir selalu terjadi dikemudian hari tidak terpikir untuk dibuatkan template-nya.

Template bisa berupa file (dokumen, source code), folder/directory, database schema, script yang harus dijalankan dll.

Beberapa tips untuk membut tempalate:

• Sebaiknya perbaiki terus template yang kita punya.
• Seperti juga source code, ada baiknya membuat versi-versi dari template.
• Buatlah isi template selengkap mungkin sehingga pada saat diperlukan, bagian yang tidak diperlukan dapat dengan mudah dihilangkan.
• Berilah deskrispsi dari masing-masing bagian yang perlu diisi pada tempalte.
• Kalo perlu beri contoh isi pada bagian-bagian yang harus diisi/di-customize.

Karakteristik RIA

Karakteristik RIA (Rich Internet Applications) :

• Poses di server dan komunikasi client-server (network traffic) direduksi dengan sebisa mungkin melakukan proses di client
• Mendukung cross platform (operating system, device) di client
• Richness of the media (audio, grphics, video/animation)
• Bisa membuat grafik atau media file lainya secara on the fly
• Membutuhkan plugin
• Data dapat dicache di client- Responsive
• Control yang lebih bervariasi dan responsif seperti pada aplikasi desktop biasa (date picker, gauges, slider, dan lain-lain)
• Tampilan dan proses konsisten karena dapat dibuat tidak tergantung browser.
• Beberapa masih menggunakan browser dengan teknologi HTML + javascript
• Dapat menyimpan state/data yang lebih besar di client (teknologi cookie dan session pada web bisa ditinggalkan)

Beberapa teknologi RIA:

• Eclipse Rich Client Platform (Eclipse RCP)
• JDesktop Network Components (JDNC)
• XML User Interface Language (XUL)

Kekurangan apliksi WEB (diambil dari majalah SDAAsia versi Indonesia) :

• Mekanisme pemnyimpanan data di client sangat terbatas, biasanya memanfaatkan cookie dan session dari mekanisme HTTP.
• Tiap pemrosesan logika biasanya dilakukan di server sehingga respon aplikasi menjadi lambat, selain itu menambah beban di server dan memperbesar data bandwidth jaringan.
• Tiap alur proses dari aplikai menghasilkan respon halaman web terdiri dari code HTML yang harus di kirim ke client secara lengkap berulang kali, meskipun masih menampilkan halaman yg sama.
• Validasi dan proses logika di client biasanya memanfaatkan JavaScript, yang dapat diutak-atik atau dinonaktifkan sehingga tidak berfungsi.
• Efek-efek tampilan atau proses logika di client sering kali mendayagunakan DHTML atau JavaScript yang terkadang tidak compatible dengan browser tertentu. Misalnya menu pop-up muncul di Internet Explorer tetapi tidak tampak atau tidak berfungsi dengan baik di Mozilla.
• Komponen GUI dari web form terbatas.

Change request

Ceritanya...

Setelah kita selesai dengan dokumen-dokumen (business requirement, software design & spefication dan lain-lain) yang disetujui oleh client, kita mulai dengan membangun (develop) apa yang tertulis. Tapi kadang apa yang kita desain salah atau kurang tepat sehingga kita harus mengubah software yang telah kita buat. Perubahan juga bisa terjadi karena kesalahan pengertian terhadap bisnis proses atau memang karena proses bisnis yang berubah.

Perubahan bisnis proses akan membuat kita pusing kepala karena harus merubah aplikasi (software) yang kita buat, karena itu diperlukan "change request document" yang berguna untuk mengontrol perubahan selama project yang dapat mengakibatkan perubahan biaya, waktu, resource dan kualitas. Tanpa perjanjian yang jelas pada scope of project dan manajemen dokumen yang baik, perubahan bisnis akan lebih membuat kita pusing kepala. Oleh karena itu dokumen dan pengesahan (approval) terhadap dokumen menjadi penting.

Isi dokumen change request harus menjelaskan secara lengkap tentang perubahan yang terjadi. Komponen-komponen yang penting untuk ditulis dalam dokumen tersebut adalah:

• Requestor, orang yang menginisialisasi perubahan
• Waktu permintaan perubahan
  
• List dokumen yang terkait, dokumen lain yang berubah (document affected) akibat dokumen change request atau dokumen tambahan yang memperjelas
• Detail / deskripsi perubahan
  
• Penyebab perubahan
• Detail analisis
• Hasil evaluasi, keuntungan dan kerugian yang ditimbulkan dari change request
  
• Pengaruh adanya perubahan (impact)
• Pengaruh jika perubahan tidak dilakukan
• Pengaruh terhadap system/modul lain
  
• Solusi yang digunakan
• Perubahan biaya
• Perubahan resource (jumlah orang yang terlibat dalam proyek)
  
• Perubahan waktu pengerjaan (plan)
  
• List reviewer dan approver
• Status dokument, misalnya: Open, Approved for analysis, Approved for implementation, Rejected, Deffered, Closed
• Waktu selesai implementasi
  

Baik juga jika kita menambahakan atribut pengkategorian dari perubahan yang diminta, misalnya pengkategorian impact yang menunjukan seberapa besar pengaruh yang diakibatkan karena perubaha tersebut , scope of change yang menunjukan jenis perubahan, apakah perubahan bisnis, perubahan desain atau perubahan yang lain.

Pengalaman pribadi saya yang membuat "bete" adalah kejadian ketika client meminta untuk adanya perubahan kemudian kita mulai merespon perimtaan tersebut dengan membuka diskusi. Diskusi mulai panas dan memajang dengan pengaruh yang besar disana sini. Saat diskusi kita selalu memikirkan solusi detail yang akan dilakukan, karena client cukup educated maka kadang diskusi sampai pada desain interface secara umum. Kemudian kita mulai membuat dokumen change request berlembar-lembar, untuk memperjelas dibuat juga gambar-gambar dari mock-up screen yang akan dibuat.Cukup melelahkan. Kemudian setelah dokumen selesai kita mulai men-submit ke orang yang berhak melalukan approval. Karena impact-nya cukup besar, cost-nya pun besar, nah dengan mudahnya sang approver me-reject dokumen atau meminta diskusi ulang untuk solusi yang sederhana (solusi yang diambil dengan toleransi proses bisnis disana-sini). Bagaimana dengan kerjaan, waktu yang telah terbuang sebelumnya?? Inilah yang membuat saya "bete". Karenanya step "approved for analysis" sebelum kita mulai panjang lebar mediskusikan perubahan. Tapi ini terjadi pada proyek saya dimana tim bertindak sebagai kosultan tapi juga implementor.

Best Practices

Blog ini akan penuh dengan best practices, tip dan trik. Kenapa?

Saat kita melakukan development suatu sistem hanya dengan dasar pemrograman (bisa memprogram) saja tidak cukup. Apalagi jika menggunakan suatu framework baru, kita tidak hanya perlu belajar bagaimana menggunakannya tapi juga bagaimana menggunakan framework tersebut secara baik dalam arti efektif juga efisien. Oleh karena itu best practices sangat diperlukan. Best practice tidak akan didapat ketika kita pertama kali melakukan permrograman.

Best practice sering didaptkan justru karena kita telah sering melakukan hal-hal yang sama, melakukan tes kemudian mendapatkan masalah. Best practices bisa dianalogikan dengan dengan design pattern dan sering ditemukan setelah kita melakukan beberapa kali refactoring kode.

lebih dari itu best practice dalam proses development tidak hanya berlaku pada kode program saja. Tapi lebih dari itu best practices juga menyangkut proses manajement proyek. Karena pentingnya best practices, maka kita perlu mendokumentasikannya. Selain bermanfaat untuk diri sendiri, dokumen best practice akan berguna bagi pemula untuk dapat dengan cepat belajar dari pengalaman orang lain.

Topik yang menarik kan? Saya akan cari sumber bacaan untuk ini, dan mari kita sharing.

UMLGraph: Tools untuk membuat diagram UML berbasis teks

Saat ini UMLGraph hanya bisa membuat class diagram dan sequence diagram. Kita bisa membuat class diagram lewat yang dispesifikasikan di javadoc. Untuk membuat class diagram program ini menggunakan declarative language yang mudah untuk dimengerti, sedangkan untuk sequence diagram-nya menggunakan imperative language seperti ini:

# Define the objects
object(O,"o:Toolkit");
placeholder_object(P);
step();

# Activation and messages
active(O);
message(O,O,"callbackLoop()");
create_message(O,P,"p:Peer");
message(O,P,"handleExpose()");
active(P);
return_message(P,O,"");
inactive(P);
destroy_message(O,P);
inactive(O);

# Complete the lifeline of O
step();
complete(O);

Sulit dibaca kan? Lebih langkapnya lihat saja website UMLGraph

Tool lain untuk membuat sequence diagram SEQUENCE, jAdvice SEQUENCE

Produk kecil tersebut mungkin jauh dibandingkan dengan XDE, RationalRose, Together dll tapi tetap menarik untuk dicoba.