Bicara tentang Reverse Engineering
Gue rasa proyek reverse engineering termasuk proyek-proyek umum yang terjadi di industri, gak cuma software sebenernya. Dalam hubungannya dengan reverse engineering software, harus mulai dari mana? Dokumentasi bisnis prosesnya? gambar diagram-diagram dari setiap use case, modul, aktivitas, fungsi, fitur, database? Kalo kita sudah punya itu semua, apakah artinya kita pasti bisa implementasi ulang produk tersebut dan bisa jadi, setidaknya secara fungsional, sama persis?
Ngebahas diagram dan bisnis proses. apabila kita ngejalanin bisnis proses analysis salah satu diagram yang umum dihasilkan itu ya bisnis proses diagram. Bentuknya lebih mirip activity atau flow diagram di uml daripada use case. bisnis proses gak terus langsung bisa dipakai buat bikin aplikasi. Dalam hasil analisa bisnis proses kita bisa pertimbangkan mana yang bisa di support menggunakan aplikasi (bentuknya bisa macem2 gak cuma software, mungkin alat berat, perkakas atau bangunan). Disitu kita juga bisa mempertimbangkan optimalisasi. ngelihat mana proses yang perlu dibuang atau ditambahkan. bahkan kadang disitu kita bisa melihat, menemukan atau mempertimbangkan potensi bisnis baru.
Apakah untuk reverse engineer aplikasi tersebut perlu dibuat dokumentasi bisnis proses nya terlebih dahulu? buat gue ya belon tentu perlu. Mungkin kalo alasannya supaya ke depannya semua stakeholder (bisnis, tehnik, provider, dll) bisa berpegang sama satu informasi dasar yang sama, bisa jadi dibutuhkan. Kalo memang dibutuhkan ya time & budgetnya tentu harus disesuaikan. Itupun harus diperhatikan mo seberapa yang di analisa, banyak bisnis, terutama yang baru start, punya bisnis proses yang cepat berubah karena harus menyesuaikan sama kondisi. Perusahaan2 besar banyak yang punya departemen yang bisnis prosesnya jelas bahkan kadang tersertifikasi. Kantor pemerintahan punya banyak proses yang sudah jelas. Tapi begini pun kadang bisa berubah juga. misalnya regulasi baru di reformasi birokrasi. Dan jangan lupa analisa bisnis proses itu bukan analisa untuk bikin aplikasi software loh. Dari point ini niat awal reverse engineering sebenernya masih jauh.
So sekarang katakan lah lo dah punya informasi dasar dari bisnis proses. kira2 udah tahu aplikasi yang mo di reverse engineer itu meng cover bisnis proses bagian mana. Selanjutnya ngapain? Pada dasarnya (pada dasarnya loh ya). Bisa mulai requirement engineering. mulai lihat aplikasinya bisa apa aja, tanya sama yang pake ini fitur buat apa, kenapa bisa kok fitur ini dibikin begini? apa alasannya? itupun belon tentu semua yang pake atau yang berhubungan sama aplikasi itu tahu kenapa aplikasi itu dulu dibuat seperti itu.
Terus gimana? hajar requirement engineering. kumpulin semua fitur, modul, dlsb, dari situ design sistim dan software arsitekturnya, kalo uda jadi kita punya dokumen beratus2/beribu2 halaman
penuh dengan diagram2 UML cantik. kita kasih ke developer dan mereka pasti dengan bahagianya implementasi-in buat kita karena semuanya sudah "jelas" terdokumentasi dengan baik di tahap awal.
Hal seperti ini bisa saja dilakukan, tapi gue sih prediksi projekt seperti ini lebih dekat ke ambang kegagalan dari pada on time & on budget. Lo gak akan pernah tahu apakah requirement yang lo kumpulin itu sudah pasti cover semua yang ada di dalam aplikasi itu. lo ga akan pernah tahu juga apakah arsitektur yang di desain itu sudah pasti sesuai dan meng cover semua requirement. Dan lo yakin developer bakal bahagia kalo kerjaannya "tinggal" implementasi? Yakin pada baca ga? uda ditulis & digambar panjang lebar :D buat gue ini mimpi indah :) Bisa jadi ada developer kaya gini, dan mungkin juga banyak. Tapi buat gue sih ini developer males mikir, gak punya niat belajar, dan gak suka menghadapi tantangan.
Definisi flexible itu harus jelas. Fleksibilitas itu selalu trade off dengan kompleksitas. Buat gue, gak ada end product yang flexible. Setiap produk pasti punya tujuan, tujuan ini jadi value produkt tersebut. kalau sebuah produk dibuat untuk digunakan menciptakan produk, bisa saja kita anggap produk itu "fleksibel". Tapi pada dasarnya ya enggak. produk itu memang dibuat untuk menciptakan produk. itu tujuannya dan value yang ada di dalamnya.
Kalo lo buat aplikasi "fleksibel", liat lagi, ini dibuat fleksibel karena lo bingung client/user "maunya apa" atau ada value yang jelas dari fleksibilitas tersebut. Kalopun "maunya" jelas dan terang benderang, liat lagi value nya. apa perlu buang uang, tenaga, pikiran untuk hal yang dipakai setaon belon tentu sekali misalnya. kalo itu bisnis critical ya silahkan.
Saran gue? kerjakan bertahap secara iterativ. kumpulkan requirement berupa user stories, mo gambar UML silahkan, sesuai kebutuhan aja. libatkan arsitek dan developer dalam estimasi waktu implementasi dan delivery. tentukan most viable product / feature. tentukan release time box yang pendek (dibawah 1 bulan). Release often, get feedback often. user harus menggunakan aplikasi yang lama & yang baru secara bersamaan dalam menjalankan proses bisnis. time box nya ditentukan saja bersama. tujuannya kan dengan aplikasi baru proses bisnis / output bisa berjalan seperti menggunakan aplikasi lama. Dokumentasi bisnis proses, requirement engineering, arsitektur atau dokumen teknikal lainnya bukan untuk mendukung user manual. kalo user manual dirasa belum cukup ya diperbaiki atau aktualisasi user manualnya. informasi yang dirasa perlu diketahui di masukkan. belum tentu semua orang yang mo tahu cara pake aplikasi itu perlu baca UML diagram kok.
Ngebahas diagram dan bisnis proses. apabila kita ngejalanin bisnis proses analysis salah satu diagram yang umum dihasilkan itu ya bisnis proses diagram. Bentuknya lebih mirip activity atau flow diagram di uml daripada use case. bisnis proses gak terus langsung bisa dipakai buat bikin aplikasi. Dalam hasil analisa bisnis proses kita bisa pertimbangkan mana yang bisa di support menggunakan aplikasi (bentuknya bisa macem2 gak cuma software, mungkin alat berat, perkakas atau bangunan). Disitu kita juga bisa mempertimbangkan optimalisasi. ngelihat mana proses yang perlu dibuang atau ditambahkan. bahkan kadang disitu kita bisa melihat, menemukan atau mempertimbangkan potensi bisnis baru.
Apakah untuk reverse engineer aplikasi tersebut perlu dibuat dokumentasi bisnis proses nya terlebih dahulu? buat gue ya belon tentu perlu. Mungkin kalo alasannya supaya ke depannya semua stakeholder (bisnis, tehnik, provider, dll) bisa berpegang sama satu informasi dasar yang sama, bisa jadi dibutuhkan. Kalo memang dibutuhkan ya time & budgetnya tentu harus disesuaikan. Itupun harus diperhatikan mo seberapa yang di analisa, banyak bisnis, terutama yang baru start, punya bisnis proses yang cepat berubah karena harus menyesuaikan sama kondisi. Perusahaan2 besar banyak yang punya departemen yang bisnis prosesnya jelas bahkan kadang tersertifikasi. Kantor pemerintahan punya banyak proses yang sudah jelas. Tapi begini pun kadang bisa berubah juga. misalnya regulasi baru di reformasi birokrasi. Dan jangan lupa analisa bisnis proses itu bukan analisa untuk bikin aplikasi software loh. Dari point ini niat awal reverse engineering sebenernya masih jauh.
So sekarang katakan lah lo dah punya informasi dasar dari bisnis proses. kira2 udah tahu aplikasi yang mo di reverse engineer itu meng cover bisnis proses bagian mana. Selanjutnya ngapain? Pada dasarnya (pada dasarnya loh ya). Bisa mulai requirement engineering. mulai lihat aplikasinya bisa apa aja, tanya sama yang pake ini fitur buat apa, kenapa bisa kok fitur ini dibikin begini? apa alasannya? itupun belon tentu semua yang pake atau yang berhubungan sama aplikasi itu tahu kenapa aplikasi itu dulu dibuat seperti itu.
Terus gimana? hajar requirement engineering. kumpulin semua fitur, modul, dlsb, dari situ design sistim dan software arsitekturnya, kalo uda jadi kita punya dokumen beratus2/beribu2 halaman
penuh dengan diagram2 UML cantik. kita kasih ke developer dan mereka pasti dengan bahagianya implementasi-in buat kita karena semuanya sudah "jelas" terdokumentasi dengan baik di tahap awal.
Hal seperti ini bisa saja dilakukan, tapi gue sih prediksi projekt seperti ini lebih dekat ke ambang kegagalan dari pada on time & on budget. Lo gak akan pernah tahu apakah requirement yang lo kumpulin itu sudah pasti cover semua yang ada di dalam aplikasi itu. lo ga akan pernah tahu juga apakah arsitektur yang di desain itu sudah pasti sesuai dan meng cover semua requirement. Dan lo yakin developer bakal bahagia kalo kerjaannya "tinggal" implementasi? Yakin pada baca ga? uda ditulis & digambar panjang lebar :D buat gue ini mimpi indah :) Bisa jadi ada developer kaya gini, dan mungkin juga banyak. Tapi buat gue sih ini developer males mikir, gak punya niat belajar, dan gak suka menghadapi tantangan.
Definisi flexible itu harus jelas. Fleksibilitas itu selalu trade off dengan kompleksitas. Buat gue, gak ada end product yang flexible. Setiap produk pasti punya tujuan, tujuan ini jadi value produkt tersebut. kalau sebuah produk dibuat untuk digunakan menciptakan produk, bisa saja kita anggap produk itu "fleksibel". Tapi pada dasarnya ya enggak. produk itu memang dibuat untuk menciptakan produk. itu tujuannya dan value yang ada di dalamnya.
Kalo lo buat aplikasi "fleksibel", liat lagi, ini dibuat fleksibel karena lo bingung client/user "maunya apa" atau ada value yang jelas dari fleksibilitas tersebut. Kalopun "maunya" jelas dan terang benderang, liat lagi value nya. apa perlu buang uang, tenaga, pikiran untuk hal yang dipakai setaon belon tentu sekali misalnya. kalo itu bisnis critical ya silahkan.
Saran gue? kerjakan bertahap secara iterativ. kumpulkan requirement berupa user stories, mo gambar UML silahkan, sesuai kebutuhan aja. libatkan arsitek dan developer dalam estimasi waktu implementasi dan delivery. tentukan most viable product / feature. tentukan release time box yang pendek (dibawah 1 bulan). Release often, get feedback often. user harus menggunakan aplikasi yang lama & yang baru secara bersamaan dalam menjalankan proses bisnis. time box nya ditentukan saja bersama. tujuannya kan dengan aplikasi baru proses bisnis / output bisa berjalan seperti menggunakan aplikasi lama. Dokumentasi bisnis proses, requirement engineering, arsitektur atau dokumen teknikal lainnya bukan untuk mendukung user manual. kalo user manual dirasa belum cukup ya diperbaiki atau aktualisasi user manualnya. informasi yang dirasa perlu diketahui di masukkan. belum tentu semua orang yang mo tahu cara pake aplikasi itu perlu baca UML diagram kok.
Comments