Software Engineering Practices

1.     Tahapan-tahapan pengembangan perangkat lunak

1.      Pengenalan masalah.

2.      Merencanakan penyeleseian masalah (Pemodelan dan Desain Perangkat Lunak)

3.      Melaksanakan apa yang sudah direncanakan

4.      Melakukan evaluasi pada sistem yang telah dikembangkan (Quality Assurance Test)

2.     Pengenalan Masalah

Sebagai pengembang dari sebuah sistem maka perlu untuk melakukan analisa terhadap masalah yang harus diseleseikan dengan software yang kita bangun. Analisis tersebut bertujuan agar software yang kita hasilkan tepat untuk dapat menyeleseikan masalah yang sedang dihadapi.

Pengembang perangkat lunak secara umum terbagi menjadi 2. Yakni pengembang perangkat lunak yang mendapatkan tugas dari klien untuk menyeleseikan masalah yang dihadapi dan pengembang perangkat lunak yang melakukan inovasi untuk menyeleseikan masalah yang ada dilapangan. Pada kedua tipe pengembang ini maka proses yang harus dilakukan juga identik. Pada tahap pertama, mereka harus mampu untuk memetakan permasalahan yang akan diseleseikan dengan perangkat lunak.

Pemetaan masalah dapat dilakukan dengan cara sebagai berikut,

1.       Siapa pihak yang bertanggung jawab terhadap masalah yang sedang dihadapi?

Dengan mengetahui pihak yang bertanggung jawab, maka kita dapat menentukan dengan tepat personal-personal yang diindikasikan mampu memberikan informasi dengan jelas dan tepat tentang masalah yang dihadapi dan harapan yang diinginkan.

Bukan tidak mungkin kita harus melakukan investigasi permasalah lintas bidang jika memang sistem yang akan kita kembangkan terkait dengan bidang lain. Kita dapat meminta klien untuk menunjukkan siapa personal yang dapat dimintai keterangan terkait kebutuhan mereka.

2.       Apa yang kita tidak ketahui tentang masalah mereka?

Sebagai analis kita harus memiliki daftar informasi  tentang masalah yang sedang dihadapi. Kita harus menyusun daftar pertanyaan untuk menanyakan informasi-informasi yang kita tidak ketahui. Sehingga setelah proses identifikasi masalah selesai, kita sudah memiliki informasi yang komprehensif tentang masalah tersebut.

Paradigma seorang analis yang pintar tidak perlu melakukan wawancara terlalu banyak merupakan paradigm yang salah. Walaupun mungkin kita sudah memiliki gambaran tentang masalah yang dihadapi, namun kita diwajibkan untuk melakukan cross check langsung dengan klien. Hal ini dilakukan untuk menghindari terjadinya misunderstanding dari pihak analis. Dokumentasi hasil wawancara ataupun penggalian informasi harus mendapatkan persetujuan dari pihak klien. Dokumentasi tersebut dapat kita jadikan sebagai pedoman awal dalam menyusun rencana penyeleseian masalah.

3.       Memetakan masalah menjadi lebih detail dengan membuat sub-problem.

Setelah seluruh informasi kita dapatkan. Kita akan mendapatkan gambaran masalah secara helicopter view (General). Kita harus memecahkan masalah yang general tersebut ke sub-sub masalah yang lebih kecil. Pembagian masalah menjadi sub-sub bagian yang lebih kecil sekaligus berfungsi untuk lebih mendetailkan masalah yang dihadapi. Seringkali kita akan menemukan detail informasi yang terlupakan, sehingga kita dapat mengantisipasi kemungkinan tersebut diawal pekerjaan.

Selain itu, dengan memecah masalah menjadi sub bagian yang lebih kecil akan menjadi langkah awal kita dalam melakukan analisis pemecahan masalah yang akan kita ajukan. Pemecahan masalah bisa ditunjukkan secara spesifik untuk tiap-tiap detail unit. Serta pembagian masalah akan mendorong kita untuk memberikan solusi dengan sifat Object Oriented.

4.       Usahakan untuk merepresentasikan hasil analisa dengan bantuan gambar.

“Picture is more than thousand word” mungkin sebuah kata yang bisa merepresentasikan hal ini. Dengan menggunakan gambar sebagai media untuk menyederhanakan pola pikir kita maka akan mempermudah kita untuk berkomunikasi dengan pihak-pihak lain.

Perlu diketahui bahwa dalam melakukan interaksi kita sebagai analis tidak melulu berhubungan dengan programmer yang sangat teknis-oriented, terkadang kita harus juga untuk mempresentasikan hasil analisis yang kita lakukan kepada end-user. Maka penjelasan dalam bentuk gambar menjadi senjata yang sangat baik.

3.     Plan a solution (Modelling dan Desain perangkat lunak)

1.       Apakah ada masalah serupa yang sudah ditangani?

Permasalahan di dunia IT memiliki kemiripan-kemiripan. Sehingga dalam dunia IT sudah jamak jika kita menyusun penyeleseian masalah dengan berdasarkan database problem solving yang telah kita miliki.

Kita akan dapat bekerja lebih cepat dan proven dengan memanfaatkan dokumentasi dari masalah serupa yang telah kita kenal sebelumnya. Sehingga kita bisa langsung in dengan masalah tersebut tanpa perlu mempelajari lebih lama.

Oleh karena itu, sebagi IT analis professional, dokumentasi masalah dan solusi akan menjadi reusable resources yang sangat berharga dalam menunjang kegiatan pekerjaan.

2.       Apakah masalah tersebut sudah terseleseikan?

Jika dokumentasi masalah sudah kita miliki, kita juga harus memperhatikan apakah masalah tersebut sudah dapat terseleseikan / tersedia resources untuk menyeleseikan masalah tersebut. Solusi yang proven ini bisa diperoleh baik dari dokumentasi pribadi kita maupun solusi yang telah ada di luar.

Pada era sekarang, pengembang sistem sudah mengenal teknologi OOP. Dengan konsep OOP maka fungsi-fungsi yang telah kita kembangkan sebelumnya akan dapat kita jadikan sumberdaya untuk menyeleseikan suatu masalah. Konsep reusable resources ini yang memudahkan pengembang untuk mendevelop sistem yang besar dalam waktu yang relative singkat.

Selain solusi yang telah kita miliki sendiri, jika diluar telah tersedia solusi yang proven maka kita juga tidak haram untuk menggunakan solusi tersebut pada sistem kita. Kita harus memiliki planning yang tepat apakah dengan fully development sistem memberikan nilai efektivitas yang tinggi atau malah menimbulkan time consuming yang besar.

3.       Dapatkah kita menenteukan sub-problem?

Sepeti pada tahap analisis awal yang telah dikemukakan. Konsep pemecahan masalah menjadi unit-unit kecil merupakan pendekatan yang baik bagi kita untuk menyeleseikan suatu masalah.
Pendekatan OOP juga akan terbantu jika kita mampu untuk merepresentasikan solusi dengan membagi masalah menjadi sub-sub bagian masalah yang lebih spesifik.

4.       Dapatkah kita menampilkan solusi yang dapat diimplementasikan secara efektif?

Solusi yang kita tawarkan harus mampu untuk diimplementasikan secara efektif baik secara sumberdaya maupun ketepatan dalam memecahkan masalah.

4.     Execute the plan

1.       Apakah solusi yang dikerjakan sesuai dengan rencana yang telah dirumuskan?

Pada tahap implementasi fungsi sistem analis adalah harus memastikan bahwa para programming (eksekutor dari rencana) telah benar-benar mengkodekan sesuai dengan rencana yang telah ditentukan sebelumnya. Logika-logika liar diluar dari rencana yang telah ditentukan seminimal mungkin harus dihindarkan pada tahapan ini. Semua eksekusi pekerjaan harus disesuaikan dengan rencana (solusi yang telah dianalisa).

Oleh karena itu, pada tahap perancanaan harus dilakukan analisa yang komprehensif dan dalam agar dapat menghasilkan rencana yang baik.

Perlu diingat salah satu statement khas dari dunia engineering “If we failed to plan, we plan to fail”. Jika kita gagal dalam menyusun perencanaan dengan baik maka kita merencanakan sebuah kegagalan.

2.       Apakah source code dapat ditelusuri dan sesuai dengan model yang telah dibuat?

Source code yang dibuat harus dapat ditraceback kedalam model yang telah dibuat sebelumnya. Sehingga pada saat proses supervisory terhadap tim pengembang (programmer) maka analis dapat dengan mudah untuk menemukan kesalahan ataupun ketidaksesuaian implementasi dengan rencana yang telah disusun.

Selain itu, pada saat proses pemodelan sistem kita juga harus mampu untuk membuat modeling sistem yang sesuai dengan rencana eksekusi pekerjaan. Contohnya jika pada tahap pengembangan berencana menggunakan sistem yang menerapkan OOP (Object Oriented Programming) maka kita juga harus memodelkan sistem yang akan kita buat dengan menggunakan pendekatan modeling berbasis object.

3.       Apakah tiap bagian dari solusi telah dapat berfungsi dengan benar?

Pada tahap pengembangan ini kita juga dapat melakukan evaluasi awal dengan melakukan debugging untuk tiap-tiap bagian dari solusi yang telah dikerjakan. Pada tahapan ini jika memang ditemukan masalah maka kita dapat langsung melakun re-planning untuk sub sistem tersebut.

5.      Examine the result

1.       Apakah mungkin untuk melakukan test pada tiap bagian dari solusi yang dibuat?

Setelah sistem telah selesai dikembangkan maka kita harus melakukan pengecheckan sistem baik secara fungsionalitas maupun pengetestan dari tiap-tiap fungsi yang ada.

Pengetesan dari fungsi-fungsi menjadi sangat penting karena biasanya bug terjadi bukan pada fungsionalitas utama namun pada bagian-bagian kecil sistem yang telah kita kerjakan.

“The Devils is at the detail”

2.       Apakah telah memiliki dan mengimplementasikan metode testing yang baik?

Kita juga harus merencanakan dan memiliki metode testing yang terstandar untuk menguji perangkat lunak yang kita miliki. Metoda-metode testing yang digunakan harus dapat merepresentasikan segala kemungkinan yang terjadi pada sistem.

Eg. Pada saat melakukan testing aplikasi Sistem Informasi Akademik. Kita tidak boleh melakukan test hanya dengan mengunakan satu single user yang mengakses fungsional sistem. Namun kita juga harus mensimulasikan kondisi puncak jumlah pengakses sistem kita, sehingga kita dapat mengetahui batasan-batasan dari sistem yang telah kita buat. Setelah diketahui batasan tersebut, kita bisa merencanakan solusi yang tepat, baik dari sisi repairing sistem atau mengatur kebijakan (policy).

 

Resume kuliah Software Engineering by Mr. Arry Akhmad A.

http://kupalima.wordpress.com
================================================= kurangin tidur banyakin ngopi