Cleanroom Software Engineering, oleh Kiki L H [5105 100 129]

Pendekatan Cleanroom
Cleanroom software engineering merupakan sebuah pendekatan untuk memenuhi kebutuhan akan software yang bebas kesalahan sejak masih dalam tahap pengembangan. Alih-alih menggunakan siklus klasik (analisis, desain, coding, pengetesan, dan proses debugging), pendekatan cleanroom menggunakan sudut pandang yang berbeda. Filosofinya adalah menghilangkan proses debugging yang memerlukan biaya cukup besar dengan meningkatan kebenaran penulisan kode sejak awal dan memverifikasinya kebenarannya sebelum pengetesan dilakukan. Model prosesnya ditunjang dengan sertifikasi kualitas statistikal peningkatan jumlah baris kode saat diakumulasikan dengan sistem.
Meskipun di awal digunakannya pendekatan ini pada rekayasa perangkat lunak menunjukkan hasil yang menjanjikan, pendekatan tersebut belum digunakan secara luas. Henderson [HEN95] mengemukakan tiga alasan yang mungkin:
1. Kepercayaan bahwa metodologi cleanroom terlalu teoritis, terlalu matematis, dan terlalu radikal
2. Tidak membutuhkan unit pengetesan oleh pengembang tetapi menggantinya dengan verifikasi kebenaran dan quality control statistikal—konsep yang sungguh asing bagi pengembangan software saat ini
3. Industri pengembangan software belum siap untuk mengaplikasikan teknik ini. Kematangan industri pengembangan software sangat dibutuhkan karena pada pendekatan ini, aplikasi proses terdefinisi banyak sekali digunakan dalam semua fase siklus hidup. Suatu hal yang sangat sulit dilakukan mengingat sebagian besar pengembang masih beroperasi pada level ad hoc.


Model Proses Cleanroom
Pendekatan cleanroom menggunakan incremental software model versi khusus. Pipeline software increment dikembangkan oleh tim kecil perekayasaan perangkat lunak secara independen. Setelah setiap increment tersertifikasi, kemudian semua increment tersebut digabungkan. Urutan kerja cleanroom untuk setiap increment diilustrasikan dalam gambar 1. Semua requirement sistem dikembangkan dengan metode perekayasaan sistem (system engineering methods). Ketika fungsionalitas telah diberikan, pipeline increment cleanroom dimulai.

kiki1
[gambar 1]

Rangkaian kerja untuk setiap increment:
Increment planning. Fungsionalitas setiap increment, proyeksi ukurannya, dan jadwal pengembangan cleanroom dibuat. Rencana kerja ini dikembangkan sebelum increment dimulai.
Requirements gathering. Deskripsi lebih detail tentang level requirement customer untuk setiap increment dikembangkan.
Box structure spesification. Metode spesifikasi yang menggunakan struktur boks [HEV93] digunakan untuk mendeskripsikan spesifikasi fungsional. Secara singkat, struktur boks mengisolasi dan memisahkan definisi tentang perilaku, data, dan prosedur (fungsi) pada tiap level perbaikan. Akan dijelaskan lebih lanjut di bagian lain pembahasan ini.
Formal design. Meskipun dimungkinkan untuk membedakan secara jelas antara dua aktivitas, spesifikasi (disebut black box) berulang-ulang tetap dilakukan.
Correctness verification. Sesuai dengan filosofi yang telah disebutkan sebelumnya, tim cleanroom melakukan banyak sekali akktivitas verifikasi kebenaran. Verifikasi dilakukan dimulai dari level teratas struktur boks hingga ke detail desain dan kode.
Code generation, inspection, and verification. Spesifikasi struktur boks diterjemahkan ke dalam bahasa pemrograman. Teknik inspeksi digunakan untuk memastikan kesesuaian kode dan struktur boks dan kebenaran sintaks kode. Kemudian verifikasi kebenaran dilakukan pada source code.
Statistical test planning. Proyeksi penggunaan software dianalisa dan serangkaian test case direncanakan dan didesain. Aktivitas ini berjalan paralel dengan spesifikasi, verifikasi, dan code generation.
Statistical use testing. Teknik statistical use mengeksekusi serangkaian tes yang diturunkan dari sample statistikal dari semua kemungkinan eksekusi program oleh semua pengguna dari populasi target.
Certification. Ketika verifikasi, inspeksi, dan tes penggunaan selesai dilakukan, increment disertifikasi, yang berarti bahwa siap untuk diintegrasikan dengan increment lain.

Keunikan Cleanroom
Perbedaan perekayasaan software cleanroom dengan perekayasaan software konvensional dan berorientasi objek:
1. Penggunaan secara eksplisit quality control statistikal
2. Pemverifikasian spesifikasi desain menggunakan bukti kebenaran berbasis matematik
3. Sangat bergantung pada testing statistikal untuk menemukan error yang mungkin berakibat fatal
4. Meminimalkan peran unit testing dan debugging (dan secara dramatis mengurangi aktivitas testing oleh pengembang software)

Spesifikasi Fungsional
Cleanroom software engineering sesuai dengan prinsip analisis operasional dengan menggunakan metode yang disebut dengan box structure spesification. Boks mengenkapsulasi sistem (atau beberapa aspek dari sistem) pada suatu level detail. Melalui perbaikan proses bertahap, boks-boks disusun secara hirarki, di mana setiap boks memiliki transparansi referensial. Dengan begitu spesifikasi dari masing-masing boks sudah cukup untuk mendefinisikan refinement, tanpa bergantung pada implementasi boks yang lain.
kiki2
[gambar 2]

a. Black box
Black box menspesifikasikan perilaku sistem atau bagian dari sistem. Sistem (atau bagian dari sistem) merespon stimuli (event) dengan mengaplikasikan aturan transisi yang memetakan stimuli ke respon (seperti dalam relasi himpunan, setiap stimuli berkorespondensi dengan respon yang sesuai). Itulah mengapa, boks teratas ini disebut black box. Karena pada level ini untuk sebuah even yang terjadi, kita hanya tahu sebatas respon yang akan diberikan oleh sistem, atau bagian dari sistem, tanpa tahu proses apa sebenarnya yang terjadi di dalam box.
kiki3
[gambar 3]

Banyak konsep yang diperkenalkan untuk sistem berorientasi objek juga bisa diaplikasikan untuk black box. Black box mengenkapsulasi abstraksi data dan operasi yang berhubungan dengan data abstrak. Seperti pada hirarki class, boks pada level bawah bisa mewarisi property dari boks yang lebih atas menurut struktur tree.

b. State box
State box mengenkapsulasi data state dan operasinya. Di state box ini, input pada state-box (stimuli) dan output (respon) direpresentasikan. State box juga merepresentasikan “stimulus history” dari black box; data yang dienkapsulasi dalam state box yang harus dijaga selama terjadi transisi diimplikasikan. State box merespon stimuli dengan membuat transisi dari current state ke beberapa state baru. State box menggunakan data abstraksi untuk menentukan transisi ke state selanjutnya dan aksi (respon) yang akan terjadi sebagai konsekuensi transisi.
kiki4
[gambar 4]

c. Clear box
Clear box merupakan level terendah dalam box structure. Fungsi transisi yang dipanggil oleh state box didefinisikan di clear box (clear box berisi desain prosedural dari state box). Clear box berhubungan erat dengan pemrograman terstruktur. Spesifikasi prosedural yang terdapat pada struktur hirarki clear box dapat dibuktikan kebenarannya (akan dijelaskan pada bagian selanjutnya).
kiki5
[gambar 5]

Desain Cleanroom
Pendekatan desain yang digunakan pada perekayasaan software cleanroom banyak sekali menerapkan filosofi pemrograman terstruktur (terutama pada pendefinisian fungsi). Konsep enkapsulasi data, information hiding, dan pemilihan tipe data yang tepat digunakan untuk membuat desain data. Pada setiap level refinement, tim cleanroom melakukan verifikasi kebenaran formal. Keuntungan dilakukannya verifikasi desain:
Ò Mengurangi verifikasi pada finite process
Ò Memungkinkan tim cleanroom memverifikasi setiap baris desain dan kode
Ò Menghasilkan level defek mendekati nol. Ini merupakan hal yang terpenting karena proses debugging (penghilangan defek) merupakan aktivitas yang sangat membuang waktu dan mahal
Ò Menghasilkan kode yang lebih baik dibandingkan dengan kode yang dihasilkan unit testing

Pengetesan Cleanroom
Tujuan pengetesan cleanroom adalah untuk memvalidasi kebutuhan software dengan mendemonstrasikan bahwa sampel statistik use-case dapat dilakukan dengan sukses, yang akan menghasilkan sertifikasi pada komponen software. Komponen software reusable dapat disimpan bersama dengan skenario penggunaan, stimuli program, dan distribusi probabilitas. Pendekatan sertifikasi meliputi lima langkah:
1. Skenario penggunaan harus dibuat
2. Profil penggunaan harus dispesifikasikan
3. Test case dibangkitkan dari profil tersebut
4. Tes dijalankan dan data kesalahan dicatat dan dianalisa
5. Reliabilitas dikomputasikan dan disertifikasikan

Sertifikasi untuk perekayasaan software cleanroom membutuhkan dibuatnya tiga model berikut:
1. Model sampling. Software testing mengeksekusi m random test case dan akan memperoleh sertifikasi jika tidak ada error atau tidak lebih dari batas toleransi error
2. Model komponen. Sebuah sistem yang terdiri dari n komponen akan disertifikasikan. Model komponen memungkinkan analis untuk menentukan kemungkinan komponen tersebut akan gagal saat penyelesaian
3. Model sertifikasi. Reliabilitas sistem keseluruhan diproyeksikan dan disertifikasikan

2 Responses to “Cleanroom Software Engineering, oleh Kiki L H [5105 100 129]”


  1. 1 Mayang Januari 10, 2009 pukul 1:26 pm

    Mas, disini disebutkan cleanroom SE menggunakan metode berbasis matematis dan statistikal..
    di mana sisi matematisnya dan statistikalnya?
    di source yang saya baca juga tidak di deskripsikan secara detail sisi matematisnya..
    apa ada rumus khusus untuk verifikasi dalam cleanroom ini atau menggunakan metode verifikasi yang sudah ada?
    saya mau bahas Cleanroom SE ini dalam TA saya.. tapi masih banyak yang di bingungin.. udah mau deadline nih TA nya hihi.. mohon bantuannya ya mas.. tx u =)

  2. 2 Pram Februari 9, 2010 pukul 1:34 am

    mas, cleanroom SE berpengaruh gk seh sama gaya coding kita? apa harus pake OOP?


Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s




Arsip

RSS My Blog

  • Pindahan! Februari 13, 2012
    Para pembaca sekalian, mulai hari ini blog ini pindah ya.. alamatnya di www.handyeka.com Posting-posting terbaru akan muncul di alamat baru tersebut. Terima kasih :)
  • Selamat Tahun Baru 2012! Januari 26, 2012
    Selamat tahun baru 2012!! Bagaimana tahun 2011 yang baru saja kita lewati ini? pasti banyak up-and-down nya. Biasanya orang kalau ngomongin tahun baru mesti nanyain resolusi tahun baru, tapi kali ini saya ga mau nanya-nanya tentang resolusi, hahaha.. kenapa? karena … Continue reading →
  • Adele – Someone Like You Oktober 10, 2011
    Pernahkah Anda merasakan jatuh cinta.. namun pada akhirnya Anda hanya bisa mengagumi dia yang Anda cinta karena Anda berdua sayangnya tidak bisa bersatu.. namun ia akhirnya bisa bahagia.. meskipun bukan bersama Anda.. Sakit.. dan penuh emosi jiwa pastinya.. tapi apakah … Continue reading →

RSS Recipee World

  • Sebuah galat telah terjadi; umpan tersebut kemungkinan sedang anjlok. Coba lagi nanti.

RSS Indonesia Travel Guide

  • Sebuah galat telah terjadi; umpan tersebut kemungkinan sedang anjlok. Coba lagi nanti.

RSS Music Info Online

  • Sebuah galat telah terjadi; umpan tersebut kemungkinan sedang anjlok. Coba lagi nanti.

%d blogger menyukai ini: