Minggu, 27 Mei 2012

clean room


Cleanroom Software Engineering

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.


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.






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.
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.


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).



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
Cleanroom Testing
  • Rekayasa software dengan metode cleanroom adalah pendekatan formal ke pengembangan software yang dapat membawa ke software yang memiliki kualitas yang tinggi.
  • Tujuan clean room testing
    • Tujuan clean room testing adalah untuk memvalidasi persyaratan software dengan memperlihatkan bahwa suatu sampel statistik dari kasus-kasus penggunaan telah dieksekusi dengan baik.
 




Tidak ada komentar:

Posting Komentar