Fase Pembuatan Aplikasi

Banyak jalan menuju Roma," demikian pepatah lama berkata. Tetapi, Anda tentunya lebih memilih menuju Roma menggunakan pesawat terbang daripada berjalan kaki. Pesan moralnya adalah Anda harus mengambil jalan terbaik untuk tujuan Anda, demikian juga dalam pembuatan aplikasi.

Terdapat banyak jalan dan cara untuk menghasilkan aplikasi sehingga dapat dijalankan oleh pengguna. Tetapi dengan tahap-tahap pembuatan aplikasi yang jelas, Anda dapat menciptakan aplikasi yang baik dan mudah untuk dikembangkan.

Pembuatan Aplikasi Sebagai Life Cycle
Pembuatan aplikasi tidak melulu seni menulis ratusan atau bahkan ribuan baris kode program, Anda harus memperlakukannya sebagai sebuah proyek, yang memiliki tahapan-tahapan tertentu. Terdapat cukup banyak  referensi mengenai tahapan pembuatan aplikasi dan bisa jadi sedikit berbeda satu sama lain, tetapi satu hal yang sama adalah semuanya menggambarkan rentetan tahapan tersebut sebagai suatu siklus hidup (life cycle).

Tentunya Anda membuat aplikasi agar dapat digunakan oleh orang lain. Semakin lama dan sering digunakan, akan timbul kebutuhan baru yang merupakan nafas bagi suatu aplikasi untuk ikut berkembang. Di sini tahapan yang Anda susun selama pembuatan aplikasi akan memegang peranan penting.

Secara umum, tahapan yang digunakan dalam pembuatan aplikasi memiliki paling tidak tahapan sebagai berikut:

1.    Requirement Gathering.
Pulpen, buku catatan, dan sebuah map khusus adalah alat yang Anda butuhkan pada tahap Requirement Gathering, yang merupakan tahap awal dari proyek Anda. Menulis seluruh fitur yang dibutuhkan oleh aplikasi yang akan dibuat dan memahaminya adalah kunci sukses pada tahap ini.

2.    Functional Spesification.
Anggaplah aplikasi yang Anda ciptakan merupakan sebuah kotak hitam atau black box, suatu istilah untuk menggambarkan proses yang tidak terlihat. Suatu proses memerlukan input untuk diproses, dan menghasilkan output dari proses tersebut.

Input dan output inilah yang perlu Anda dokumentasikan pada tahap ini. Functional Specifications meramu dokumen yang didapat dari Requirement Gathering secara lebih spesifik, akan lebih baik jika Anda menganalisis input dan output untuk masing-masing fitur yang dibutuhkan aplikasi.

3.    Architecture and Design.
Tahap ini mirip dengan pembuatan blue print saat Anda membangun sebuah rumah. Di sini Anda mendefinisikan dengan detail arsitektur meliputi teknologi, bagas pemrograman, database, komponen, hardware, dan hal lain yang diperlukan.

Dokumen design merupakan dokumen terakhir yang harus dipersiapkan untuk memasuki fase programming, di sini Anda membuat draft user interface dan struktur database yang akan digunakan.

Salah satu hal yang penting untuk didefinisikan pada tahap ini adalah waktu pengerjaan aplikasi atau timeline

4.    Implementation and Coding.
Tahap ini merupakan tugas utaman programmer untuk menerjemahkan dokumen-dokumen design ke dalam bahasa pemrograman, biasanya merupakan tahap terpanjang yang harus dilalui.

Hindari untuk langsung menginjak tahap ini sementara dokumen-dokumen pada tahap sebelumnya belum sempurna. Hal ini membatasi pengembangan aplikasi itu sendiri. Karena dalam membuat aplikasi yang sekecil dan sesederhana apapun, Anda harus memiliki visi untuk pengembangannya.

Sebaiknya Anda memiliki pedoman standarisasi umum untuk pengodean, misalnya untuk penamaan variabel atau function/procedure.

Mungkin Anda pernah mengamati satu persamaan yang ditemui pada berbagai bahasa pemrograman, yaitu semuanya menyediakan fasilitas untuk menyisipkan keterangan/komentar pada baris-baris kode. Untuk apakah disediakan fasilitas ini?

Jawabannya jelas, yaitu untuk digunakan! Selalu berikan komentar pada baris kode yang Anda anggap perlu, percayalah Anda sendiri akan sangat terbantu dengan adanya komentar, demikian juga dengan orang lain yang mungkin memodifikasi atau meneruskan pekerjaan Anda.

Bukanlah suatu hal yang aneh jika selama fase coding ditemukan permasalahan secara teknikal ataupun perubahan kebutuhan. Karena itu melakukan tinjau ulang secara berkala akan tetap menjaga proyek Anda agar tetap pada jalurnya. Perubahan timeline mungkin dapat terjadi saat sebuah masalah ditemukan dan memerlukan waktu lebih lama untuk menyelesaikannya.

5.    Testing.
Produk yang baik selalu melewati apa yang disebut Quality Control (QC) atau Quality Assurance (QA), tidak terkecuali produk software aplikasi. Testing dapat terbagi menjadi:
a. Unit Testing.
Melakukan testing pada satu modul atau satu komponen dari keseluruhan aplikasi.
b. Sanity Testing.
Melakukan tes apakah keseluruhan modul/komponen berjalan dengan baik.
c. Regression/Stress Testing.
Setiap aplikasi memiliki “sifat” tersendiri. Regression/Stress Testing melakukan tes terhadap kecendrungan aplikasi setelah berjalan beberapa lama. Hal ini dapat terjadi karena kesalahan alokasi memory, overflow, dan lain-lain.
d. Functional Testing.
Test untuk memastikan bahwa fungsi-fungsi aplikasi telah berjalan dengan baik. Fungctional Testing tidak dilakukan oleh programmer, karena kesalahan justru lebih mudah dilihat dan ditemukan oleh orang lain yang bertugas untuk menguji aplikasi tersebut.

Penguji dapat melakukan testing dengan berpedoman pada dokumen Functional Specifications yang telah dibuat pada tahap sebelumnya.

Beberapa poin untuk mempersiapkan laporan testing ini adalah:
a. Deskripsi tes.
b. Bagaimana tes dilakukan.
c. Hasil yang diinginkan.
d. Hasil yang didapatkan.
e. Penjelasan jika terdapat kondisi tertentu untuk keperluan testing tersebut.

6.    Software Releases.
Kini saatnya Anda membuat promosi seperti “Hari ini telah diluncurkan operating system masa depan!”, walaupun aplikasi yang Anda ciptakan belum sebombastis itu (tetapi siapa tahu?), tetapi paling tidak inilah saatnya aplikasi Anda memasuki pasaran dan siap digunakan.

Sebuah nomor versi perlu diberikan untuk menandakan lahirnya aplikasi Anda. Pengembangan masih terus dilanjutkan di mana nomor versi akan terus bertambah sejalan dengan perkembangan aplikasi, misalnya dengan adanya fitur baru, atau perbaikan bugs.

Tidak perlu berkecil hati jika masih ditemukan banyak bugs pada aplikasi Anda walaupun telah melewati berbagai macam tes, perusahaan software besar sekalipun masih terus melakukan perbaikan-perbaikan terhadap produk-produknya.

7.    Documentation.
Secara umum, dokumentasi akhir terbagi lagi menjadi 3 (tiga) jenis dokumentasi sebagai berikut:
a. Technical Development Documentation.
Merupakan rangkuman dokumentasi selama proses development, meliputi dokumen arsitektur, design, dan functional. Dokumen ini diperlukan untuk pengembangan lebih lanjut di masa datang, perbaikan bugs, ataupun penambahan fitur.
b. Technical Support Documentation.
Berisi manual untuk customer support. Informasi yang tercakup pada dokumentasi ini lebih bersifat teknis dan tidak untuk dimengerti oleh pengguna akhir (end user). Dokumen ini lebih diarahkan agar customer support dapat membantu permasalahan yang dihadapi pengguna.
d. End User Manuals and Guides.
Dokumentasi untuk menuntun pengguna untuk memulai dan menggunakan aplikasi.

8.    Support and New Features (Maintenance).
Pengguna aplikasi Anda memerlukan pelayanan support untuk tetap menggunakan aplikasi Anda. Misalnya mengenai cara instalasi dan memulainya, perbaikan bugs yang ditemukan, dan penambahan fitur.

Skema Versi Aplikasi
Dengan adanya pengembangan aplikasi yang terus-menerus, Anda harus memberikan pengenal terhadap setiap versi aplikasi yang diluncurkan. Terdapat cukup banyak jenis skema yang dikenal. Di antaranya adalah:

1. Skema Numerik.
   Anda mengenal Adobe Acrobat 6.0, Quick Time 3.0, bahkan bahasa pemrograman yang Anda gunakan mungkin juga memiliki versi dengan angka dibelakangnya. Skema penamaan dengan numerik yang umum adalah mengikuti format major.minor[.revision[.build]]. atau major.minor[.maintenance[.build]]. Sehingga jika dituliskan aplikasi XYZ versi 2.6.10 berarti aplikasi XYZ telah memasuki versi 2 (mayor), 6 (minor), dan 10 (revisi). Mayor, minor, dan revisi menandakan perubahan, dari perubahan besar hingga perubahan kecil.
   
   Perubahan mayor menandakan suatu lompatan perubahan secar fungsional pada aplikasi. Perubahan minor menandakan penambahan fitur kecil atau perbaikan aplikasi. Sementar nomor revisi bertambah setiap kali bug kecil yang bersifat minor berhasil diperbaiki.
   
   Pada umumnya, setiap aplikasi yang dirilis pertama kali ditandai dengan versi 1.0. Versi dibawah 1 sering diartikan sebagai versi alpha atau beta selama aplikasi masih pada tahap testing atau masih digunakan secara personal.
   
   Penggunaan huruf juga sering ditemukan, misalnya versi 1.2b, 1.3rc4, dan seterusnya. Pada umumnya huruf 'a' menunjukkan versi alpha, 'b' menunjukkan versi beta, 'rc' menunjukkan versi releases candidate, di mana aplikasi telah dianggap stabil dan siap dirilis.
2. Skema Tanggal.
   Menggunakan tanggal sebagai pengenal versi aplikasi. Di mana digunakan digit tahun diikuti digit bulan dan digit tanggal. Misalnya "WNE 20040505".
3. Skema Tahun.
   Menggunakan tahun sebagai pengenal versi aplikasi. Contohnya "Adobe Illustration 88", "Microsoft Office 2003".
4. Skema Huruf.
   Menggunakan kata sebagai pengenal versi aplikasi. "Contohnya Windows Me", "Windows XP", "Windows Vista".

Baris Komentar
Seperti telah disebutkan, penulisan baris komentar pada kode program merupakan hal yang penting bagi pemeliharaan program itu sendiri. Tidak ada pedoman resmi untuk memberikan komentar, tetapi ada baiknya Anda memberikan komentar sederhana yang merepresentasikan apa yang dikerjakan oleh sekumpulan baris kode yang rumit.

Baris komentar juga disarankan untuk setiap awal modul program, selain bertujuan untuk dapat memahami tujuan modul tersebut, komentar di sini juga bermanfaat untuk dokumentasi. Beberapa hal yang memerlukan komentar/keterangan pada modul antara lain adalah:

1. Function/Purpose.
   Berisi penjelasan mengenai apa yang dikerjakan modul tersebut.
2. Author.
   Kapan dan oleh siapa modul tersebut dibuat, bagian ini dapat terus ditambahkan oleh developer yang mengembangkan modul tersebut di kemudian hari.
3. Requirement.
   Menulis apa yang dibutuhkan oleh modul tersebut jika menggunakan modul atau library lain, yang diperlukan dalam proses kompilasi.
4. Usage.
   Menuliskan bagaimana penggunaan modul tersebut.
5. Limitation.
   Tuliskan jika terdapat keterbatasan modul yang digunakan, contohnya jika modul tersebut hanya dapat berjalan dengan kondisi tertentu.
   

Baris komentar juga dapat ditulis untuk menjelaskan suatu procedure/function. Beberapa hal yang dapat diberikan keterangan antara lain adalah:

1. Function/Purpose.
   Kegunaan function/procedure yang dibuat.
2. Parameter.
   Menjelaskan masing-masing parameter yang digunakan, baik parameter input yang memberikan nilai maupun parameter output yang mengembalikan nilai.
3. Side Effects.
   Menjelaskan jika function/procedure yang bersangkutan melakukan suatu perubahan yang berpengaruh terhadap function/procedure lain, misalnya melakukan update terhadap suatu variabel.
4. Error Conditions.
   Jika sebuah error terjadi, berikan penjelasan bagaimana function/procedure mengatasinya. Sebagai contoh, penjelasan mengenai kode kesalahan yang dikirimkan kepada pemanggil jika ditemukan error.
5. Pre-conditions.
   Penjelasan jika terdapat suatu kondisi yang harus dilakukan terlebih dahulu sebelum pemanggilan function/procedure, misalnya jika terdapat variabel-variabel yang harus diisi terlebih dahulu.
6. Algorithm.
   Penjelasan jika function/procedure mengimplementasikan suatu algoritma yang rumit.
   

User Friendly untuk Pengguna
Membuat kode program Anda menjadi user friendly untuk pengembangan lebih lanjut memang penting, tetapi tidak kalah pentingnya membuat interface aplikasi Anda menjadi user firendly bagi pengguna.

Aplikasi secanggih apapun, akan terasa kurang jika tidak memperhatikan faktor user friendly. Penelitian pasar menampung kebutuhan customer, sementara aplikasi Anda merupakan jawabannya. Sehingga tdak dapat dipungkiri customer yang akan menjadi faktor penentu pengembangan lebih lanjut dari aplikasi Anda.

Beberapa hal yang perlu Anda pertimbangkan untuk membuat aplikasi Anda menjadi user friendly bagi pengguna:

1. Membuat Progress Bar.
   Jika aplikasi Anda mengerjakan sesuatu pada background dalam waktu yang lama, tampilkan progress bar ataupun presentase proses yang berjalan.
2. Cursor Hourglass.
   Untuk proses yang tidak memakan waktu lama, gunakan cursor yang menandakan bahwa sedang terjadi proses, cursor yang umum dikenal adalah cursor dengan bentuk hourglass.
3. Navigasi yang mudah.
   Sering kali sebuah aplikasi memiliki banyak form dan fitur. Gunakan navigasi yang mudah untuk mengakses masing-masing form ataupun fitur. Contohnya dengan menggunakan menu pull-down. Hindari perpindahan dari satu form ke form lain yang terlalu panjang.
4. Pesan Konfirmasi.
   Menambahkan konfirmasi untuk beberapa proses yang vital akan berperan untuk menghindari kesalahan klik mouse oleh pengguna. Misalnya konfirmasi untuk proses hapus data, atau proses keluar aplikasi.
5. Tampilkan Pesan Kesalahan.
   Adanya bugs merupakan hal yang umum ditemukan pada sebuah aplikasi. Sebuah pesan kesalahan yang muncul setiap terjadi suatu error akan lebih baik daripada membiarkan aplikasi keluar begitu saja.
6. Help.
   Memberikan fasilitas help akan sangat membantu penggunaan aplikasi Anda.

Menciptakan Siklus
Seiring dengan berjalannya waktu, sebuah aplikasi kecil dapat berubah menjadi aplikasi besar yang banyak digunakan setelah melewati beberapa siklus pengembangan. Karena itu, ciptakan siklus pengembangan aplikasi dengan selalu melihat kebutuhan pasar dan pengguna. Akhir kata, selamat mengembangkan aplikasi!

Lebih Lanjut

• http://www/faqs.org/docs/Idev/0130091154_24.htm
• http://en.wikipedia.org/wiki/Version
• http://www.aivosto.com/vbtips/codedoc.html