Software Vaganza 2

Ya, setelah beberapa tahun kosong, tahun ini KK RPLD STEI ITB (Kelompok Keilmuan Rekayasa Perangkat Lunak dan Data) kembali akan mengadakan Software Vaganza. Kegiatan ini direncanakan untuk dilaksanakan menjelang akhir tahun ajaran ini (akhir semester ini). Kegiatan utamanya adalah pameran dan demo berbagai software hasil karya para mahasiswa Prodi Teknik Informatika ITB. Meskipun tidak ditutup kemungkinan untuk menerima peserta pameran dari luar juga.

Cita-cita kami adalah menumbuhkan ‘budaya’ membangun software dengan cara yang benar, serta memupuk kreativitas untuk membuat berbagai produk software.

OK, bagi yang ingin berpartisipasi, silahkan bersiap-siap…

Berubah !!

Tahukah kamu ? (15)

Perkembangan bahasa pemrograman memang makin banyak memberikan kemudahan bagi programmer. Coba lihat perkembangan berikut:

• first generation programming language (1GL): bahasa mesin; kita ‘terpaksa’ harus memahami bagaimana mesin bekerja
• second generation programming language (2GL): bahasa assembler; kita mulai dibantu dengan kode simbolik seperti PUSH, POP, dll
• third generation programming language (3GL) atau bahasa tingkat tinggi: bahasa Pascal, C, C++, Java; bahasa yang digunakan sudah lebih ‘manusiawi’. Satu statement 3GL mewakili 5 – 10 statement bahasa assembler
• fourth generation programming language (4GL): mis. visual programming language; satu statement-nya mewakili 30 – 50 statement bahasa assembler

Nah, dengan bantuan yang lebih baik tersebut, idealnya, programmer sekarang harus lebih produktif dibandingkan programmer masa lalu ya…

Kompleksitas RTS

Karakteristik RTS (Real Time System) membuatnya menjadi suatu sistem yang punya tingkat kompleksitas tinggi. Untuk kategori real time embedded system, software yang kita bangun harus bisa berkomunikasi efektif dengan hardware dimana software tersebut ‘ditanam’. Pemrograman level rendah pasti banyak diperlukan. Kita tidak di-support lagi oleh OS (operating system), dan bahkan harus membangun ’semacam’ OS khusus untuk hardware tersebut.

Untuk kategori real time control system, software harus mampu menangani data yang masuk dari berbagai sensor. Masing-masing sensor dapat membangkitkan sinyal/data secara periodik atau aperiodik. Sinyal/data aperiodik harus bisa diprediksi kemunculannya. Sinyal/data dari berbagai sensor mungkin harus diproses secara konkuren. Software juga harus mampu membangkitnya sinyal untuk berbagai actuator. Belum lagi kalau yang dikembangkan adalah sistem terdistribusi. Koordinasi dan komunikasi antar subsistem akan jadi persoalan tersendiri.

Untuk kategori real time critical system, design harus dibuat sedemikian rupa agar worst case untuk setiap response time atau execution time bisa diprediksi. Tapi juga tidak bisa terlalu pesimis sehingga jadi over design…

Dan tentunya masih banyak aspek lain yang mengakibatkan RTS ini makin kompleks. Tidak heran kalau khusus untuk RTSE (real time software engineering), pernah dibuat Program Studi tersendiri yang melibatkan ITB (dulu diwakili Departemen Teknik Informatika), IPTN (sekarang PT DI), dan Universite Thomson (Prancis)…

Yang sulit itu…

Setelah terlibat dalam beberapa proyek pembangunan perangkat lunak pendukung sistem informasi, saya bisa menarik kesimpulan seperti ini: teknis software development-nya relatif tidak sulit, karena umumnya berupa pengolahan data sederhana. Software-nya biasanya bisa jadi dengan cepat.

Berikutnya, yang sulit adalah memastikan bahwa software yang sudah kita buat akhirnya bisa digunakan. Migrasi data dari sistem lama (yang bisa saja masih manual sehingga perlu effort untuk data entry) ke sistem baru adalah ‘hutan rimba’ tersendiri. Orang tidak akan mau kehilangan data historis karena masih membutuhkannya.

Yang sulit lainnya adalah memastikan bahwa setiap kategori user bisa melakukan tugasnya dengan baik. Kadang-kadang membutuhkan banyak negoisasi, sosialisasi, pelatihan, atau bahkan modifikasi terhadap software yang sudah jadi tadi. Memastikan bahwa pihak manajemen mendukung pengubahan SOP sebagai akibat diterapkannya sistem baru, juga butuh trik tersendiri…

Jadi, beberapa aspek teknis umumnya bisa segera dicari solusinya, tapi aspek non teknis bisa mengakibatkan software kita tidak jadi digunakan…

What do you think ?

WAE to UML

Untuk membantu membuat model WebApp yang lebih lengkap, didefinisikan WAE to UML (WebApp Extention to UML), yaitu notasi UML khusus untuk memodelkan beberapa elemen WebApp. Tanpa notasi ini, model design kita tidak lengkap dan agak sulit untuk segera diimplementasikan dengan bahasa pemrograman tertentu.

Notasi WAE to UML yang dapat digunakan dibagi dalam dua view, yaitu logical view dan component view. Logical view element membantu kita memodelkan aspek lojik aplikasi, yaitu dalam bentuk server page, client page, dan HTML form. Ketiga elemen ini dimodelkan dalam bentuk stereotyped class, sehingga masing-masing punya atribut dan methods. Component view element membantu kita memodelkan komponen dan organisasinya, yaitu dalam bentuk static page, dynamic page, dan physical root. Elemen pada component view ini akan merealisasikan elemen-elemen pada logical view.

Nah, dengan modal tambahan notasi untuk membuat UX model (sudah dibahas di sini) dan notasi WAE to UML ini, model WebApp kita jadi makin jelas dan lengkap…

Hampir 20 tahun…

Saya adalah alumni IF angkatan ‘89. Jadi, tahun depan, 20 tahun sudah berlalu sejak terdaftar sebagai mahasiswa tahap sarjana di ITB. Rencananya akan ada reuni 20 tahun ITB 1989 tahun depan. Sebagai antisipasinya, IF89 melaksanakan semacam pra-reuni di De Ranch Lembang sebelum bulan Ramadhan lalu. Sayangnya, hanya 8 dari 54 orang yang berhasil hadir. Tapi lumayan juga serunya, karena beberapa dari kami membawa ‘pasukan’ tambahan…

Setelah 20 tahun berlalu, apa yang sudah anda lakukan ?? Rasanya, saya belum melakukan apa-apa

Ini dia 8 dari 54 yang hadir itu:

Real Time System

Real Time System (RTS) adalah sistem dimana kebenaran fungsional sistem tergantung pada output-nya dan waktu saat output tersebut dihasilkan. Jadi, meski output-nya sudah benar, jika meleset dari deadline, maka fungsional sistem bisa dianggap gagal. Memang ada yang sangat strict terhadap batasan waktu ini (hard real time), dan ada yang masih memberi sedikit toleransi (soft real time).

RTS umumnya punya karakteristik berikut:

• biasanya merupakan embedded system
• biasanya membutuhkan pemrosesan konkuren untuk sejumlah input yang masuk, sehingga perlu didefinisikan sejumlah task untuk memrosesnya, serta perlu strategi khusus untuk menjadwalkan eksekusi setiap task
• harus bisa menangani input yang sinkron maupun asinkron
• punya kebutuhan yang tinggi terhadap reliability dan safety, sehingga fault tolerance dan exception handling jadi hal yang penting
• seringkali melibatkan berbagai hardware sehingga ada kebutuhan untuk mendefinisikan antarmuka yang baik

Elemen RTS umumnya terdiri dari:

1. Sensor control processes; yaitu proses yang menerima input dari berbagai sensor
2. Data processor; yaitu proses yang akan melakukan komputasi terhadap data-data yang diterima dari berbagai sensor
3. Actuator control processes; yaitu proses yang akan membangkitkan sinyal untuk berbagai actuator

Sensor dan actuator ini adalah sarana untuk melakukan monitoring dan control, salah satu ativitas yang banyak dibantu dengan RTS…

Automation…

S/W Quality: Dependability (2)

Menyambung tulisan sebelumnya di sini, berikut adalah penjelasan tiga elemen dependability :

Attributes:

1. Availability – readiness for correct service
2. Reliability – continuity of correct service
3. Safety – absence of catastrophic consequences on the user(s) and the environment
4. Integrity – absence of improper system alteration
5. Maintainability – ability to undergo modifications and repairs

Threats:

1. Fault: A fault (which is usually referred to as a bug for historic reasons) is a defect in a system. The presence of a fault in a system may or may not lead to a failure, for instance although a system may contain a fault its input and state conditions may never cause this fault to be executed so that an error occurs and thus never exhibits as a failure.
2. Error: An error is a discrepancy between the intended behaviour of a system and its actual behaviour inside the system boundary. Errors occur at runtime when some part of the system enters an unexpected state due to the activation of a fault. Since errors are generated from invalid states they are hard to observe without special mechanisms, such as debuggers or debug output to logs.
3. Failure: A failure is an instance in time when a system displays behaviour that is contrary to its specification. An error may not necessarily cause a failure, for instance an exception may be thrown by a system but this may be caught and handled using fault tolerance techniques so the overall operation of the system will conform to the specification.

Means:

1. Prevention; deals with preventing faults being incorporated into a system. This can be accomplished by use of development methodologies and good implementation techniques.
   
2. Removal; can be sub-divided into two sub-categories: Removal During Development and Removal During Use. Removal during development requires verification so that faults can be detected and removed before a system is put into production. Once systems have been put into production a system is needed to record failures and remove them via a maintenance cycle.
   
3. Forecasting; predicts likely faults so that they can be removed or their effects can be circumvented.
   
4. Tolerance; deals with putting mechanisms in place that will allow a system to still deliver the required service in the presence of faults, although that service may be at a degraded level.

Untuk sebuah faktor kualitas saja, kajiannya lumayan juga ya…