Menempatkan Seorang system analyst.

Mengapa Saya Harus Mencari seorang System analyst?


Membangun sebuah tim, bukanlah pekerjaan mudah. dan mempertahankannya bisa jadi lebih sulit. Seperti halnya programer, database engineer, atau qa staff yang tidak ada di tempatnya, seorang system analyst menjadi top wanted, ketika kita memulai project lifecyle kita, setidaknya sampai seorang business analyst telah siap dengan business requirement. Tidak adanya role ini menyisakan lubang dalam puzzle mesin pengembangan yang harus kita persiapkan dari awal.

Menghadapi Renegoisasi Team Member, Fokus pada Tujuan

Sudah lazim sebuah proyek mengalami berbagai kejadian yang dinamis, yang berpengaruh terhadap keseluruhan proyek, baik pengaruh baik maupun buruk terhadap tujuan akhir proyek. Kasus yang sangat umum terjadi ialah ancaman mundurnya seorang anggota kunci.

Menjaga Komitmen Tim Bukan Hanya Tugas Team Leader

Salah satu hal yang penting dalam  project yang bersifat mission critical ialah memastikan anggota tim tetap commit dan loyal sepanjang masa proyek.

Dan hal ini tidak mudah. Memastikan programer tetap di tempatnya, bukan hanya tugas Team Leader, tetapi merupakan tugas keseluruhan Project Member, Stakeholder dan Top Level Management.

Draft Manajemen Administrasi Source Code

Dalam proses pengembangan Software, diperlukan sebuah konsep yang memadai untuk mengelola source code.

Berikut adalah rancangan konsepnya.

Poin-poin Prosedur

1. Memuat daftar komponen/aplikasi yang beserta source codenya.
2. Perlu disusun sistematika dan hirarkhi lokasi penyimpanan setiap source code, khususnya produk yang memuat lokasi source code
3. Memetakan daftar PIC developer setiap source code.
4. Memuat keterangan setiap source code per release atau per update/patch.
5. Memuat versi produk
6. Menuliskan dependency file/komponen.
7. Memberikan semacam file README, yang berisi ringkasan poin-poin penting seperti poin 3 -6 di atas.

Media Penyimpanan

1. Menyiapkan lokasi utama source code
2. Menyusun struktur folder penyimpanan per produk
3. Menyiapkan lokasi backup source code
4. Scheduling backup, untuk membackup secara rutin file source code.

Manajemen Update Kode

Disini developer menggunakan SVN sebagai alat bantu untuk menyimpan source code di Server. Letak setiap folder akan disusun berdasarkan

1. First Copy: Mengumpulkan semua source code ke dalam folder SVN yang telah dibuatkan.
2. Update Copy/ Saat Maintain Perubahan Aplikasi: Mengambil Source Code Terbaru dan Mengeditnya.

Pada saat menyelesaikan update kode, setelah mengumpulkan ke SVN. Masing-masing developer juga men-cc kan scenario testing ke PIC dokumentasi release, bersama dengan README yang mengandung informasi update/patch untuk release tersebut.

note: untuk SVN, silakan melihat referensi dari s/w ini.

Simple Web

Web sederhana untuk mengecek latest source code berdasarkan produk, feature, dan, dependency. Dimaintain oleh PIC dokumentasi release. Sehingga informasi awal keberadaaan sebuah source code bisa segera diketahui.

Prosedur Administrasi Kode

Developer:

1. Login ke SVN dan CheckOut untuk mengambil source code terbaru
2. Mengupdate Kode dan Mengetes hasil perubahan Source Code.
3. Melakukan Commit ke SVN untuk mengirim perubahan source code ke Server
4. Membuat README file seperti poin pada bagian Konsep Dokumentasi
5. Mengirim notifikasi email ke PIC Dokumentasi

PIC Dokumentasi:

1. Mengkopi README file source code untuk selanjutnya di-load ke database administrasi source code.
2. Memastikan repository server dengan SVN berjalan dengan baik.
3. Melakukan backup dengan Scheduling.
4. Memberikan notifikasi kepada Developer secara periodik ada tidaknya update source code berdasarkan status yang ada di repository.
5. Mengupdate daftar ringkasan jumlah dan status Source Code secara periodik

Isi README file

1. Nama PIC developer

2. Menuliskan keterangan setiap source code per release/per update/patch

3. Memuat versi produk

4. Menuliskan dependency file/komponen.

Testing <> development schedule : best practice

Pengujian atau Testing merupakan bagian yang tidak terpisahkan di dalam proses development/pengembangan sebuah produk Software atau perangkat lunak. Development disini secara spesifik merujuk pada proses pengkodean semua logika bisnis ke dalam kode program. Sebagaimana ditekankan di dalam berbagai kesempatan dan tulisan, pengujian sebagai sebuah upaya dalam proses pengendalian kualitas produk adalah untuk memastikan bahwa software yang dihasilkan benar-benar sesuai dengan keinginan atau harapan dari konsumen, yang pada akhirnya layak dipasarkan atau digunakan dalam dunia bisnis yang sebenarnya, dalam kata-kata wikipedia:

“In engineering and manufacturing, quality control and quality engineering are involved in developing systems to ensure products or services are designed and produced to meet or exceed customer requirements.” http://en.wikipedia.org/wiki/Quality_control

Untuk mencapai tujuan di atas, maka tentu saja diperlukan pendekatan yang bersifat lintas-fungsional, dengan melibatkan bidang bisnis dan engineering lainnya. Poin dari pembicaraan ini ialah untuk memasukkan quality control ini di dalam masa pengembangan. Ini berarti, pengujian sebagai salah satu tugas quality control memerlukan sebuah pendekatan praktis bagaimana proses ini dilakukan. Dalam kaitan ini perlu diatur sebuah mekanisme agar seluruh tahap pengujian dilaksanakan sembari melihat watak sebuah proses produksi, dimana timeframe, dan budget menjadi faktor tradeoff yang tidak bisa ditawar. Sebuah praktek yang amat baik untuk dilakukan dalam masa pengembangan sebuah produk ialah manajemen pengujian/testing yang baik.

Berikut adalah sedikit dari beberapa best-practice dalam proses pengujian.

1. Menyusun tim yang baik. Apakah menyusun tim yang baik itu:
1. Memperhitungkan jumlah tim tester sesuai dengan jumlah produk atau fitur yang dites. Sebaiknya dihindari perbandingan jumlah tester dan produk yang terlalu mencolok. Beberapa produk dengan masa pengembangan yang berdekatan sangat tidak baik, apabila dilakukan hanya oleh satu orang tester, sebagai contoh, karena seorang tester di Departemen QA harus benar-benar fokus kepada setiap detail fitur sebuah produk. Karena ia akan menjadi pintu keluar utama sebuah software dirilis ke klien.
2. Mengoptimalkan sistem rolling yang baik, apabila tim tester amat terbatas, sementara kondisi manajemen tidak memungkinkan adanya tambahan tenaga.

2. Menyusun jadwal Pengujian dengan baik. Maksudnya:
1. Prosedur Pengujian harus dimasukkan dalam jadwal proyek.
2. Jadwal Pengujian harus sinkron dengan jadwal pengembangan.

Jadwal Pengujian yang sinkron dengan jadwal pengembangan berarti waktu pengujian tidak bisa diletakkan secara sembarangan tanpa memperhitungkan jadwal pelaksanaan dari pengembangan. Seringkali kita terlalu fokus dengan jadwal pengembangan, tetapi kurang memperhatikan alokasi waktu untuk pengujian ini.

Pada beberapa kasus sering dijumpai sebuah tim proyek tidak bisa atau tidak menentukan jadwal testing ini. Dan ketika tiba pada suatu waktu dimana pengujian harus dilakukan, Tim Pengujian menemukan masalah, melempar list of error ke tim Developer! Sayang mereka telah terikat dengan jadwal di proyek lainnya.

Who kills who! Sementara UAT, user acceptance test, di tempat klien telah di depan mata, maka mau tidak mau developer harus menginterupsi pekerjaannya dan kembali ke produk atau fitur dari produk yang saat itu harus dites oleh tester. Akibatnya, seandainya ditemukan error, dan diperlukan update, maka ia harus sesegera mungkin melakukan koding ulang, dan akibat lebih buruk jadwal yang ada menjadi tergeser. Efek domino dalam keseluruhan aktivitas operasional menjadi terpengaruh.

Pada skala lokal, Sebuah tim developer yang mempunyai tanggungjawab lebih dari satu produk software, akan sangat terpengaruh produktivitasnya dengan buruknya manajemen Pengujian di departemen Pengujian. Pada skala lebih luas, terhadap keseluruhan proses produksi akan terdapat dampak yang cukup besar, bahkan amat mungkin pada overhead cost, demikian asumsi kasar yang bisa digambarkan. Walaupun belum saya temukan riset mengenai korelasi dan dampaknya secara statistik.

widya, 20 feb 2008