Sebetulnya UTS hari ini (jam 9 nanti) tentang intelejensia kolektif yang bahannya tentang EA (evolutionary algorithm) dan ACO (ant colony optimization), tapi yang dibaca sebelum tidur malah buku Practical Software Maintenance-nya Tom Pigoski. Kebetulan memang untuk kuliah pengujian perangkat lunak kebagian bab tentang testing pada saat maintenance. Baru baca bab-bab awal. Persepsi awal tentang isinya lumayan menarik sambil merefleksikan masa-masa yang pernah dialami (sebetulnya istilah pengalaman lebih singkat tapi punya makna konotasi yang bisa baik bisa juga jelek :D).

Singkat kata, dari bacaan awal bisa diceritakan bahwa perawatan (padanan untuk maintenance) seringkali memiliki banyak interpretasi. Perawatan bisa jadi merupakan pengeluaran yang kecil dibanding biaya pengembangan atau justru menjadi pengeluaran utama dibanding biaya pengembangan. Interpretasi pertama dicirikan dengan adanya alokasi sekitar 10% untuk 'support & maintenance', sedangkan interpretasi kedua mengalokasikan 80% untuk hal tersebut. Pertanyaan pertama yang muncul adalah "Yang mana yang lebih baik? untuk developer, maintainer, dan customer" (pengguna dibedakan dengan customer dan dikesampingkan dulu karena berdasarkan buku tsb, tersangka utama penyedot biaya perawatan adalah pengguna).

Pihak yang melakukan perawatan pun bisa jadi bukan pengembang perangkat lunak awal melainkan pihak lain yang mengkhususkan diri di bidang perawatan perangkat lunak (itu cerita di bukunya dengan situasi di US, kalau di Indonesia ada tidak yah (organisasi spesialis perawatan)?).

Sebelum mencoba menjawab pertanyaan di atas, cerita lain tentang isi buku tsb adalah bahwa aktivitas yang dilakukan dalam proses perawatan bisa digolongkan menjadi 3 kelompok, yaitu:

  • corrective
  • adaptive
  • perfective/improvement

Kunci dari keberhasilan proses perawatan (lagi-lagi berdasarkan buku tsb.) adalah mengklasifikasikan hal-hal yang perlu berubah ke dalam kelompok tersebut. Pengklasifikasian di atas disusun berdasarkan prioritas dan resikonya. Kisaran proporsi ketiga kelompok tersebut berturut-turut 20%, 25%, dan 55%. intinya, kebanyakan dari perawatan adalah improvement. Celakanya permintaan atas improvement ini nggak melihat struktur perangkat lunak ada. Jadi ingat pernah ada yang minta ganti grid (standar VCL Delphi) biar tampak lebih menarik (Dibandinginnya dengan DataGrid defaultnya Flex). Ibaratnya, lagi nyetir mobil kecepatan tinggi tiba-tiba punggung itu gatal!.

IMHO, situasinya akan lebih enak kalau deskripsi sistem yang mau dibikin itu bisa selesai di 10% (lebih enak lagi kalau verifikasi kesesuaian dengan spesifikasinya bisa dilakukan otomatis menggunakan metode formal) waktu total pengembangan sistem sehingga 90 persen sisanya adalah proses maintenance & testing untuk menyesuaikan dengan kebutuhan yang diyakini selalu berubah. Aspek adaptif dan perfektif berhubungan dengan antarmuka dengan sistem lain (infrastruktur perangkat keras, API, sistem operasi, target deployment platform), dan manusia (user interaction).

Saya sendiri sebetulnya lebih tertarik ke interaksi. Bayangan saya adalah user interface yang dinamis (bukan sekedar style/theme yang hanya mencakup aspek estetis, tetapi juga struktur hierarki, tata letak, dan pemilihan komponen interaksi) yang menyesuaikan dengan target deployment platform (desktop, web, mobile) dan selera pengguna. Untuk itu diperlukan tool untuk membantu perancang interaksi (paradigma Microsoft) atau menjadi fasilitas yang terintegrasi dengan sistem yang digunakan oleh pengguna (end-user development). Satu hal yang pasti dengan adanya sistem antarmuka yang dinamis dan universal ini lahir kebutuhan baru yaitu pembuatan manual penggunaan yang otomatis juga.

Kalau diinventarisasi, untuk menyelesaikan persoalan di atas (pembangkitan antarmuka dan manual ~ user interface and instruction manual generation) perlu beberapa hal berikut:

  • pemodelan domain arsitektur informasi, interaksi, dan kapabilitas platform (domain spesific modeling, MDA) termasuk model pembangkitan teks narasi untuk menceritakan skenario interaksi(natural language processing) menjadi bahasa spesifik (domain spesific language).
  • teknik kompilasi, khususnya untuk proses generation dari domain spesific language ke kode target platform
  • pengetahuan tentang interaksi (teori aktivitas dan teori kognitif) yang menjadi batasan pada proses pencarian solusi
  • Teknik optimasi kombinatorial untuk menghasilkan solusi berupa konfigurasi yang diharapkan
Tampak terlalu besar cakupannya untuk dijadikan tesis (mungkin harusnya jadi program riset kk/unggulan?) dengan sisa waktu kurang dari satu semester. Mungkin bisa dibatasi lagi supaya lebih layak mengingat masih ada konsep-konsep yang sifatnya vague.
Share this post: | | | |