Dokumentasi Wawancara

Wawancara adalah salah satu teknik pengumpulan data, terutama dalam pembuatan user requirement yang diperlukan dalam proses analisis sistem yang akan dikembangkan.

Suatu pekerjaan wawancara tidaklah lengkap, jika belum didokumentasikan. Pendokumentasian sangatlah diperlukan dan mutlak harus dilakukan, karena dokumentasi merupakan bukti tertulis dari hasil wawancara. Dokumen requirement merupakan landasan kerja untuk tahap pengembangan aplikasi, dibutuhkan dari tahap analisis sampai dengan tahap testing. Dokumen requirement selalu diacu oleh setiap tahap, untuk memastikan bahwa setiap tahap dikerjakan memenuhi requirement dari user.

Read the rest of this entry »

Advertisements

Tahap Analisis Data

Tahap analisis data dalam tahapan pekerjaan analisis adalah proses mengidentifikasi , elemen demi elemen, kebutuhan data suatu fungsi. Setiap elemen data ditentukan dari sisi bisnis, diidentifikasi siapa yang memilikinya, diidentifikasi juga pengguna datanya, dan diidentifikasi juga sumber dari data tersebut.

Elemen-elemen data ini kemudian dikelompokkan menjadi sebuah record dan suatu struktur data dibuat untuk menunjukkan ketergantungan data.

Analisis data memfokuskan kepada 2 aspek, yaitu data yang saat ini digunakan dan data yang akan atau mungkin dibutuhkan pada masa mendatang.

Read the rest of this entry »

Software Untuk Otomasi Program dan Otomasi Pengujian

Ternyata pemilihan keyword pada saat ‘searching’ di Google benar-benar sangat memperngaruhi hasil. Sampai dengan tahun 2006 lalu, penulis tidak berhasil mendapatkan suatu link yang membawa kepada proses otomasi di lingkungan Windows. Penulis pada saat itu membutuhkan software untuk melakukan otomasi pengujian software yang freeware.

Penulis baru mendapatkan ‘mainan’ baru untuk bisa melakukan otomasi pengujian dengan menggunakan software yang tepat guna, yaitu AutoIt. Proses mendapatkannya pun tidak sengaja, dan penulis sendiri tidak ingat kapan mendapatkan link ini. Read the rest of this entry »

Waktu Kerja Pengembang Aplikasi

Waktu kerja pengembang aplikasi, baik per orangan atau pun tim, harus dimanaje dengan baik dan benar. Kita tidak boleh menganggap ringan atau menyepelekan masalah waktu kerja; apalagi dengan asumsi bahwa tim pengembang telah berpengalaman mengembangkan berbagai macam software-software yang kompleks.

Pekerjaan pengembangan software memerlukan manajemen yang baik, terutama dari sisi waktu. Umumnya dikerjakan sebagai satu projek. Suatu projek harus selalu menghasilkan suatu produk yang ditunggu untuk dapat digunakan untuk membantu kerja, dan selalu memiliki deadline. Apalagi jika projek yang dikerjakan, merupakan projek pengembangan software untuk pihak lain, bukan untuk sendiri.

Proses pengembangan software, bisa dikatakan merupakan pekerjaan tim, bukan pekerjaan individu. Banyak hal yang harus dikerjakan, dari menyiapkan lingkungan kerja, pekerjaan pengembangannya itu sendiri, sampai dengan pengujian dari software yang berhasil dikembangkan.

Koordinasi antar anggota tim, harus ada, dan harus dilakukan, agar yang dikerjakan dapat menjadi sinergi. Waktu untuk koordinasi harus ditentukan secara rutin. Selain waktu rutin, koordinasi juga dapat dilakukan sewaktu-waktu, sesuai dengan kebutuhan.

Pekerjaan pengembangan software perlu memiliki rangka waktu, karena hampir semua pekerjaan dapat diukur; kecuali jika jenis pekerjaan tersebut belum pernah dikerjakan. Suatu pekerjaan pembuatan software akan sulit diukur apabila pekerjaan tersebut belum pernah sama sekali dikerjakan atau dicoba, tingkat kesulitan atau kemudahan dari pekerjaan memang menjadi tidak diketahui sama sekali. Kita hanya akan memperkirakan waktu yang dibutuhkan, dengan tingkat pencapaian yang 50:50, tepat:meleset.

Salah kaprah sering terjadi, pengembang aplikasi sering disamakan dengan seniman, kerjanya sering berdasarkan ‘mood’. Mengapa? Karena banyak yang bekerja dengan tidak kenal waktu, layaknya seniman, jika sedang ‘mood’, maka kerja akan lancar sekali, dan bisa cepat selesai. Tetapi, jika tidak ada ‘mood’, maka pekerjaan, bisa jadi, tidak akan dapat diharapkan bisa cepat selesai.

Kita bisa atau boleh saja menganggap pekerjaan membangun atau  mengembangkan software, seperti pekerjaan seni. Paradigma seperti seniman ini, sering kali dimaklumi oleh kebanyakan orang yang sering melihat gaya kerja para pengembang yang bisa dikatakan ‘gila’ kerja. Tidak kenal waktu, sampai dengan jarang pulang, bahkan tempat kerja menjadi rumah pertama.

Tipe pengembang yang gila kerja, mirip seniman, tidak akan menjadi masalah dalam satu tim kerja, yang mengembangkan software, apabila pengembang tersebut berlaku demikian di tempat kerja. Pengembang selalu ada di tempat; dan bisa diketahui progress kerjanya.

Tetapi jika kita memiliki satu orang pengembang, yang mirip seniman, secara ‘mood’, tetapi tidak mau kerja di tempat kerja, inginnya di rumah, atau di tempat lain, ini harus diwaspadai.  Mengapa? Karena pengembang tidak selalu ada di tempat kerja, sehingga kita sulit berkoordinasi, apalagi sampai bisa mengetahui kemajuan pekerjaan yang dikerjakannya secara objektif.

Kerja seni yang dilakukan oleh seniman, bisa dikatakan hampir tidak memiliki deadline waktu. Mengapa? Karena hasilnya selalu berkait dengan rasa dari seniman tersebut. Jika seniman telah merasa cukup bahwa hasilnya layak menjadi karya seni, maka selesailah proses menciptanya. Jika belum dirasa cukup, maka pekerjaan bisa ditunda sampai dengan bisa dilanjutkan lagi, jika sudah ada rasa atau ‘mood’.

Kerja pengembangan software komputer, adalah kerja membuat produk yang bisa digunakan. Bukan untuk dinikmati, seperti karya seni. Jadi akan menjadi salah besar, jika ada toleransi terhadap proses kerja yang dilakukan oleh pengembangnya, memperlakukan pekerjaan pembuatan produk, semata seperti pekerjaan seni.

Setiap bagian atau komponen yang digunakan untuk membuat software, seharusnya dapat diukur waktu untuk menyelesaikannya. Waktu untuk menyelesaikan pekerjaan secara keseluruhan harus disampaikan kepada semua anggota tim, sehingga setiap anggota tim dapat memiliki perkiraan untuk menyelesaikan pekerjaannya.

Setiap anggota tim harus menyadari keberadaan dirinya di dalam tim. Apabila ada anggota yang memiliki tugas/kewajiban untuk membuat librari fungsi atau prosedur, maka dia harus menyadari bahwa pekerjaan yang dilakukannya akan menjadi penentu kecepatan kemajuan pekerjaan. Jika librari diselesaikan dengan waktu yang terlambat, maka semua pekerjaan akan menjadi terlambat juga.

Manajer projek sangat berperan dalam proses pengembangan software, harus dapat dengan cepat memperkirakan suatu pekerjaan akan menjadi terlambat atau tidak, dengan selalu mengadakan pertemuan secara rutin. Pertemuan secara rutin tidak harus melibatkan seluruh anggota tim, tetapi cukup sampai dengan level koordinator. Setiap koordinator harus memiliki waktu juga untuk berkoordinasi dengan timnya.

Setiap anggota tim harus menyadari tentang waktu kerja. Waktu kerja telah ditetapkan oleh perusahaan. Perkara bahwa ada anggota tim yang terkadang membutuhkan waktu kerja khusus, seperti dapat efektif bekerja pada malam hari, maka itu menjadi tanggung jawab dari anggota tersebut. Perusahaan hanya mengetahui akan waktu kerja yang resmi dan target waktu atas hasil yang harus diserahkan oleh setiap anggota tim. Anggota tim harus dapat mengatur waktu kerja, yang disesuaikan dengan batasan yang telah ditentukan oleh perusahaan; yaitu waktu resmi untuk bekerja yang telah ditetapkan.

Backup Berhistori

Backup berhistori adalah istilah tentang backup yang perlu memiliki riwayat. Backup harus dilakukan oleh setiap pengguna  komputer, untuk berjaga-jaga agar file hasil kerja tidak hilang karena kerusakan media tempat penyimpanannya.

Backup harus dilakukan dengan menggunakan banyak media. Jangan melakukan backup pada media yang sama, pada direktori yang sama dengan nama yang berbeda atau pada direktori yang berbeda, tetapi media yang sama (atau harddisk yang sama). Jika backup dilakukan pada media yang sama, maka dikhawatirkan pekerjaan membuat backup menjadi sia-sia. Mengapa? Karena apabila media (misalnya harddisk) secara fisik sudah tidak bisa diakses sama sekali, maka data yang ada di dalamnya, bisa jadi tidak dapat diselamatkan. Kita tidak memiliki backup sama sekali.

Selain kita harus melakukan backup pada media yang berbeda, maka kita harus juga memiliki catatan tentang kondisi terakhir dari file data tersebut. Secara default, sistem telah menyimpankan data tanggal terakhir dari file yang dibackup tersebut. Tetapi sering kali informasi tanggal terakhir dari setiap file tidak bisa diandalkan. Mengapa? Karena bisa jadi telah terjadi perubahan yang sangat penting dan banyak pada backup tersebut, yang perlu diketahui dengan cepat.

Pada organisasi yang telah cukup mapan, maka umumnya organisasi memiliki komputer sendiri yang berfungsi sebagai server file dan server backup. Server file adalah sebuah komputer yang dikhususkan untuk menjadi pusat penyimpanan file; sedangkan server backup adalah sebuah komputer yang digunakan untuk menjadi backup (salinan) seluruh data dari file server. Setiap kali ada perubahan pada file server, maka akan secara otomatis akan disalinkan juga ke dalam server backup.

Setiap pengguna komputer harus selalu menyimpankan semua file yang dimilikinya ke dalam server file. Server file adalah tempat menyimpan salinan (backup) dari file yang dimiliki oleh setiap penggunanya. Setiap kali pengguna memiliki sebuah file baru atau mengubah suatu file, maka hasil kerjanya harus disimpankan ke dalam server file.

Backup harus dilakukan secara berlapis, tidak hanya satu backup saja, tetapi sangat disarankan untuk lebih dari satu. Server file dan server backup adalah salah satu solusi yang disediakan perusahaan, agar operasional kerja tidak terganggu. Solusi ini adalah solusi online. Secara offline, perusahaan umumnya memiliki operator yang bertugas untuk melakukan backup ke dalam media lain, seperti ke dalam tape, CD, atau DVD.

Kini mekanisme backup, terutama untuk backup file tidaklah cukup dengan menggunakan server file dan server backup, tetapi juga harus bisa memberikan informasi tentang perubahan dari setiap file yang dibackup. Histori isi dari file dan siapa yang melakukan perubahan file ini harus dapat diketahui dengan cepat dan mudah.

Mekanisme backup dapat dilakukan dengan menggunakan perintah copy biasa atau menggunakan utilitas backup yang disediakan untuk memudahkan pekerjaan.

Agar kita dapat memiliki suatu backup yang berhistori, maka kita harus menggunakan tools tambahan yang dapat digunakan untuk melakukan proses backup yang lebih mudah. Tools yang harus digunakan berupa software untuk melakukan pengendalian versi software dan tools clientnya. Software yang disarankan untuk melakukan pengendalian versi software saat ini adalah subversion, dengan tortoise sebagai software yang akan digunakan oleh penggunanya. Subversion harus dipasang pada server file, sebagai penunjang dari keberadaan server file itu sendiri.

Software subversion lebih banyak dikenal dalam kerangka bagaimana agar membuat suatu proses pengembangan aplikasi dapat memiliki histori pengembangan yang lengkap. Dari versi awal pengembangan sampai dengan versi terakhir dapat direkonstruksi dengan mudah. Karena kemampuan software subversion ini, yang bisa membuat histori dan rekonstruksi dengan mudah dari suatu pengembangan software, penulis pilih untuk menjadi solusi untuk proses backup file dari pengguna, dengan memanfaatkan sebagian kecil dari kemampuan subversion.

Dengan memiliki sistem yang memungkinkan backup berhistori, maka pengguna dapat dengan leluasa untuk melakukan perubahan tanpa harus khawatir dengan adanya kesalahan atau kehilangan file atau pun data kerja. Kunci kesuksesan agar memiliki backup berhistori adalah ‘harus berdisiplin untuk menjalankan prosedur backup’.

Dokumentasi Program

Setiap program yang dibuat, seharusnya memiliki dokumentasi.

Mengapa?

Karena program yang telah selesai dibuat belum tentu dapat langsung sempurna, sesuai dengan yang diperlukan oleh penggunanya. Perlu ada :

  • pengembangan untuk dapat memenuhi keperluan penggunanya.
  • Terkadang program harus ada perbaikan, jika ternyata pada saat digunakan ditemukan kesalahan.

Dokumentasi juga berguna untuk menginformasikan tentang proses yang ada dalam program, sehingga jika ada pertanyaan tentang program yang dibuat memiliki kemampuan apa saja, kita dapat mengetahui atau menjelaskan berdasarkan dokumentasi.

Dokumentasi program sangat diperlukan oleh pemilik aplikasi, jika ingin mengembangkan aplikasinya bukan oleh pengembang yang sama. Pengembang lain yang diserahi tugas untuk mengembangkan aplikasi dapat dengan cepat mempelajari dari dokumentasi tersebut.

Macam dokumentasi program

Macam dokumentasi program:

  • dokumentasi spesifikasi program
  • dokumentasi teknis program
  • dokumentasi penggunaan program 

Dokumentasi spesifikasi program

Dokumentasi spesifikasi program seharusnya sudah ada sebelum program dibuat. Dibuat oleh perancang aplikasi (sering kali dibuat oleh analis sistem). Berdasarkan dokumentasi inilah program dibuat.

Dokumentasi spesifikasi program ini dibuat untuk memberikan panduan tentang logika program yang harus dibuat. Harus ada proses apa saja, bagaimana flow prosesnya. Pemrogram dapat melakukan coding dengan lebih mudah.

Akan tetapi, sering terjadi, dokumentasi spesifikasi program tidak dibuatkan oleh perancang aplikasinya. Perancang aplikasi hanya menjelaskan tentang program, spesifikasi program yang ada adalah spesifikasi secara lisan. Akibatnya adalah seringkali program tidak sesuai dengan yang diinginkan, karena pemrogram bekerja dengan mengandalkan ingatannya, bukan berdasarkan panduan dokumen spesifikasi. (Bahasa guyonnya adalah dokumentasi by lisan).

Ketiadaan dokumentasi bisa menyebabkan komunikasi antara perancang aplikasi dan pemrogram menjadi tidak baik, karena bisa jadi akan ada perselisihan akibat ketidakjelasan akan apa yang dikerjakannya.

Dokumentasi spesifikasi program harus ada, walaupun secara global. Setidaknya ada informasi tentang poin-poin yang harus ada dalam program, kemudian bagaimana urutan prosesnya.

Dokumentasi spesifikasi program menjadi pegangan bersama antara perancang, pemrogram, dan penguji. Untuk memastikan bahwa program yang dibuat sudah sesuai dokumentasi.

Dokumentasi Kode Program

Dokumentasi kode program, merupakan dokumentasi yang harus ada dalam program, untuk memberikan penjelasan kepada setiap baris atau pun blok perintah dalam program.

Dokumentasi program diperlukan bagi programmer itu sendiri, untuk dapat menelusuri logika program. Karena biasanya, pemrogram akan lupa akan alur programnya sendiri. Apalagi jika sudah lama sudah ditinggalkan, karena mengerjakan pekerjaan lain. Pada saat harus memperbaiki atau menyempurnakan, programmer sering harus mempelajari terlebih dahulu alur programnya sendiri, baru kemudian baru bisa melakukan modifikasi sesuai dengan yang diinginkan.

Dari sisi lain, dokumentasi juga diperlukan untuk memudahkan untuk memvalidasi apakah program yang telah dikembangkan, sudah sesuai dengan yang dispesifikasikan atau belum. Proses validasi ini akan dilakukan oleh tim penguji (validator).

Dokumentasi kode program merupakan pelengkap dokumentasi spesifikasi, karena menjelaskan bagaimana dari spesifikasi diterjemahkan ke dalam program.

Jika dokumentasi spesifikasi tidak ada maka dokumentasi kode program akan menjadi dokumentasi yang sangat berharga, karena bukan menjadi dokumen pelengkap tetapi menjadi dokumentasi utama.

Dokumentasi dalam kode program umumnya dilakukan dengan menuliskan baris-baris komentar dalam kode sumber programnya. Isi dari dokumentasi kode program, setidaknya terdiri atas:

  • langkah-langkah dalam program untuk menyelesaikan masalah
  • komentar dituliskan pada setiap awal modul atau fungsi,
  • jika mungkin komentar ditulis pada setiap blok program, jika tidak maka ditulis pada blok-blok yang penting saja. Lebih baik lagi jika setiap baris ada komentarnya.
  • Informasi tentang siapa yang membuat, kapan pertamakali dibuat, kapan terakhir diperbaiki, jika mungkin informasi perubahan dari waktu ke waktu

Cara menuliskan komentar harus mengikut kepada cara penulisan yang baku. Jika menggunakan bahasa pemrograman Java, maka dapat menggunakan format yang telah ditetapkan oleh javadoc.

Dokumentasi Penggunaan Program

Dokumentasi penggunaan program sangat diperlukan untuk dapat memberitahu kepada pengguna bagaimana cara menggunakan program yang telah dibuat. Jika tidak dibuatkan cara menggunakan programnya, dikhawatirkan program menjadi tidak dapat dipakai, apalagi jika programnya kurang interaktif.

Banyak program yang dibuat, cara pemakaiannya sesuai dengan alur logika pemrogramnya. Bukan berdasarkan alur logika pengguna program. Karenanya harus dibuatkan dokumentasi cara menggunakan program, agar pengguna tahu bagaimana cara menggunakan dengan benar.

Tools

Jika kita hanya memiliki dokumentasi kode program, maka kita dapat mengambil dokumentasi dari kode program tersebut untuk menjadi seolah-olah dokumentasi spesifikasi program. Kita harus menggunakan tools untuk melakukan pengambilan dokumentasi kode program dengan menggunakan tools.

Agar dokumentasi dalam kode program dapat diambil oleh tools yang akan digunakan, maka cara penulisan dokumentasi harus mengikuti standar tertentu. Jika kita menggunakan Java, maka kita dapat menggunakan javadoc untuk mengambil dokumentasinya. Untuk bahasa pemrograman lain ada juga toolsnya. Masing-masing memiliki tools yang membantu untuk membuatkan dokumentasi dari dokumentasi kode program.

Beberapa tools yang umum digunakan adalah:

  • javadoc
  • delphidoc
  • doxygen

doxygen (http://www.doxygen.org/) adalah tools open source yang paling umum digunakan, yang digunakan untuk membuat dokumentasi dari source program.

Persiapan Pengujian Software

Pengujian software (software testing) membutuhkan persiapan, sebelum pengujian dilakukan.

Mengapa? Karena proses testing harus dilakukan secara sistematis, tidak bisa secara sembarang, karena software yang dihasilkan harus bebas dari error, untuk mengurangi resiko kerugian yang akan diderita oleh penggunanya. Produk software harus menguntungkan penggunanya pada saat digunakan.

Berikut persiapan yang dapat dilakukan untuk dapat melakukan proses testing:

  •  membuat checklist
    • list yang akan ditest
    • list requirement
    • list rancangan
    • list spesifikasi
    • list manual, jika sudah ada – biasanya diperlukan untuk pengujian oleh user
  • pembuatan test case
    • merupakan elemen dasar yang harus ditesting
    • merupakan list yang independent
  • pembuatan grup test case
    • kumpulan dari beberapa test case
    • merupakan list yang akan memiliki status hasil test
  • pembuatan modul test
    • pembuatan skenario testing
    • terdiri atas beberapa grup test case
    • diasosiasikan dengan fungsionalitas modul
    • mengacu kepada dokumen requirement dan desain/spec program
  • pembuatan package testing
  • pembuatan produk test

Dengan dimilikinya checklist, kita akan dapat mengetahui progress dari kegiatan testing itu sendiri. Mana yang sudah selesai dilakukan test, mana yang belum. Mana yang sudah dilakukan test pun, bisa diketahui mana yang benar modulnya sudah selesai, dan mana yang belum selesai. Jadi tidak sekedar mengetahui mana yang sudah dan mana yang belum.

Pekerjaan persiapan juga membutuhkan software yang dapat membantu proses persiapan testing ini. Yang paling sederhana adalah dengan menggunakan Excel, jika memungkin menggunakan aplikasi yang dirancang khusus. Produk yang open source adalah TestLink.