Apa Itu Bug??

Sebuah bug adalah istilah umum yang digunakan untuk menggambarkan kesalahan, cacat, kesalahan, kegagalan, atau kesalahan dalam sebuah program komputer atau sistem yang menghasilkan hasil yang benar atau tidak diharapkan, atau menyebabkan

ia berperilaku dengan cara yang tidak disengaja. Kebanyakan bug timbul dari kesalahan dan kesalahan yang dibuat oleh orang-orang baik dalam kode sumber program atau desain, dan beberapa disebabkan oleh kompiler menghasilkan kode yang salah. Sebuah program yang berisi sejumlah besar bug, dan / atau bug yang serius mengganggu fungsi-nya , dikatakan buggy. Laporan merinci bug di program yang biasa dikenal sebagai laporan bug, laporan kesalahan, laporan masalah, laporan masalah, perubahan permintaan, dan sebagainya

Efek

Bugs memicu Tipe I dan tipe II error yang pada gilirannya dapat memiliki berbagai efek riak, dengan berbagai tingkat ketidak nyamanan kepada pengguna program.Beberapa bug hanya memiliki efek halus pada fungsionalitas program, dan dengan demikian dapat berbohong tidak terdeteksi untuk waktu yang lama. Lebih bug serius dapat menyebabkan program untuk crash atau membekukan mengarah kepenolakan layanan. Lainnya memenuhi syarat sebagai bug keamanan dan mungkin misalnya memungkinkan pengguna jahat untuk mlewati kontrol akses untuk mendapatkan hak istimewa yang tidak sah.

Hasil bug mungkin sangat serius. Bug di kode mengendalikan Therac-25 mesinterapi radiasi secara langsung bertanggung jawab atas beberapa kematian pasienpada 1980-an. Pada tahun 1996 menjadi $ 1 milyar prototipe Badan Antariksa Eropa AS Ariane 5 roket hancur kurang dari satu menit setelah peluncuran, karenabug dalam program komputer bimbingan on-board. Pada bulan Juni 1994, sebuahRoyal Air Force Chinook jatuh ke dalam Mull of Kintyre, membunuh 29. Ini awalnya dianggap sebagai kesalahan pilot, tetapi sebuah investigasi oleh Komputer Weekly menemukan bukti yang cukup untuk meyakinkan House of Lords penyelidikan yang mungkin telah disebabkan oleh system bug dalam komputer kontrol mesin pesawat.

Pada tahun 2002, sebuah studi yang diprakarsai oleh Departemen Perdagangan AS 'Institut Nasional Standar dan Teknologi menyimpulkan bahwa software bug,atau kesalahan, sangat lazim dan begitu merugikan bahwa biaya mereka ekonomi AS sekitar $ 59 miliar per tahun, atau sekitar 0,6 persen dari produk domestik bruto

Pencegahan

Bugs adalah konsekuensi dari sifat faktor manusia dalam tugas pemrograman.Mereka timbul dari kelalaian atau kesalahpahaman saling dilakukan oleh tim software selama spesifikasi, desain, coding, entri data dan dokumentasi. Sebagai contoh: Dalam membuat sebuah program yang relatif sederhana untuk mengurutkan daftar kata ke dalam urutan abjad, desain seseorang mungkin gagal untuk mempertimbangkan apa yang harus terjadi ketika kata mengandung tanda hubung. Mungkin, ketika mengubah desain abstrak ke dalam bahasa pemrograman yang dipilih, satu tidak sengaja dapat membuat off-per-satu kesalahan dan gagal untuk mengurutkan kata terakhir dalam daftar. Akhirnya, saat mengetik program yang dihasilkan ke dalam komputer, orang mungkin sengaja tipe '<' where '>' yang dimaksudkan, mungkin mengakibatkan kata-kata yang disortir ke dalam urutan abjad mundur. Lebih bug kompleks dapat timbul dari interaksi yang tidak diinginkan antara bagian-bagian berbeda dari sebuah program komputer. Hal ini sering terjadi karena program komputer dapat menjadi kompleks-jutaan baris panjang dalam beberapa kasus-sering yang telah diprogram oleh banyak orang lebih panjang besar waktu, sehingga programmer tidak dapat mental melacak setiap cara yang mungkin di mana bagian dapat berinteraksi. Kategori lain bug disebut kondisi lomba datang tentang baik ketika proses berjalan di lebih dari satu thread atau dua atau lebih proses berjalan secara bersamaan, dan urutan yang tepat dari pelaksanaan urutan kritis kode belum benar disinkronkan.Industri perangkat lunak telah menempatkan banyak usaha dalam menemukan metode untuk mencegah programmer dari secara tidak sengaja memperkenalkan bug saat menulis perangkat lunak Ini termasuk.:Pemrograman gayaSementara kesalahan ketik pada kode program yang sering tertangkap oleh compiler, bug biasanya muncul ketika programmer membuat kesalahan logika.Berbagai inovasi dalam gaya pemrograman dan pemrograman defensif dirancang untuk membuat bug kurang mungkin, atau lebih mudah untuk spot. Dalam beberapa bahasa pemrograman, kesalahan ketik apa yang disebut, terutama dari simbol atau operator logika / matematika, sebenarnya merupakan kesalahan logika, karena konstruksi mistyped diterima oleh compiler dengan arti lain daripada yang dimaksudkan programmer.Teknik pemrogramanBugs sering membuat inkonsistensi dalam data internal program yang berjalan.Program dapat ditulis untuk memeriksa konsistensi data internal mereka sendiri sambil berlari. Jika ketidakkonsistenan ditemui, program ini dapat segera menghentikan, sehingga bug dapat ditemukan dan tetap. Atau, program ini hanya dapat menginformasikan kepada user, upaya untuk memperbaiki inkonsistensi, dan terus berjalan.Pengembangan metodologiAda beberapa skema untuk mengelola aktivitas programmer, sehingga lebih sedikit bug yang dihasilkan. Banyak dari ini jatuh di bawah disiplin rekayasa perangkat lunak (yang membahas masalah-masalah software desain juga).Sebagai contoh, spesifikasi program yang formal digunakan untuk menyatakan perilaku yang tepat dari program, sehingga bug desain dapat dihilangkan.Sayangnya, spesifikasi formal tidak praktis atau tidak mungkin untuk apa pun tetapi program terpendek, karena masalah ledakan kombinatorial dan ketidakpastian.Dukungan bahasa pemrogramanBahasa pemrograman sering termasuk fitur yang membantu programmer mencegah bug, seperti sistem jenis statis, ruang nama terbatas dan pemrograman modular, antara lain. Sebagai contoh, ketika seorang programmer menulis (pseudocode) LET REAL_VALUE PI = "THREE AND A BIT", walaupun ini mungkin sintaksis benar, kode tersebut gagal cek tipe. Tergantung pada bahasa dan pelaksanaan, ini mungkin ditangkap oleh kompilator atau pada saat runtime.Selain itu, bahasa yang baru saja ditemukan banyak sengaja tidak termasuk fitur yang dapat dengan mudah menimbulkan kesalahan, pada biaya pembuatan kode lebih lambat daripada perlu: prinsip umum adalah bahwa, karena hukum Moore, komputer bisa lebih cepat dan insinyur perangkat lunak mendapatkan lebih lambat, ini hampir selalu lebih baik untuk menulis kode sederhana, lebih lambat dari kode "pintar", bisa ditebak, terutama mengingat bahwa biaya pemeliharaan yang besar.Sebagai contoh, bahasa pemrograman Java tidak mendukung aritmetik pointer; implementasi dari beberapa bahasa seperti Pascal dan bahasa scripting sering memiliki batasan pemeriksaan runtime array, paling tidak dalam debugging membangun.Kode analisisAlat untuk analisis kode membantu pengembang dengan memeriksa teks program luar kemampuan compiler untuk menemukan masalah potensial. Meskipun secara umum masalah menemukan kesalahan pemrograman semua diberikan spesifikasi tidak dipecahkan (lihat menghentikan masalah), alat ini memanfaatkan fakta bahwa programmer manusia cenderung membuat jenis yang sama kesalahan saat menulis perangkat lunak.InstrumentasiAlat untuk memantau kinerja perangkat lunak seperti yang sedang berjalan, baik khusus untuk menemukan masalah seperti kemacetan atau memberikan jaminan untuk benar bekerja, dapat tertanam dalam kode eksplisit (mungkin yang sederhana seperti PRINT pernyataan yang mengatakan "Aku Disini"), atau disediakan sebagai alat. Ini sering merupakan kejutan untuk menemukan di mana sebagian besar waktu diambil oleh sepotong kode, dan ini penghapusan asumsi dapat menyebabkan kode yang akan ditulis ulang.

Debugging
Menemukan dan memperbaiki bug, atau "debugging", telah selalu menjadi bagian utama dari pemrograman komputer. Maurice Wilkes, seorang pelopor komputasi awal, dijelaskan realisasi di akhir 1940-an bahwa banyak dari sisa hidupnya akan dihabiskan menemukan kesalahan dalam program-program sendiri Sebagaimana program komputer tumbuh. Lebih kompleks, bug menjadi lebih umum dan sulit untuk memperbaiki. Seringkali programmer menghabiskan lebih banyak waktu dan usaha menemukan dan memperbaiki bug daripada menulis kode baru. Software penguji profesional tugas utamanya adalah menemukan bug, atau menulis kode untuk mendukung pengujian. Pada beberapa proyek, sumber daya lebih dapat digunakan untuk pengujian daripada dalam mengembangkan program.Biasanya, bagian paling sulit debugging adalah menemukan bug dalam kode sumber. Setelah ditemukan, mengoreksi biasanya relatif mudah. Program yang dikenal sebagai debugger ada untuk membantu programmer menemukan bug dengan mengeksekusi baris demi baris kode, menonton nilai-nilai variabel, dan fitur lainnya untuk mengamati perilaku program. Tanpa debugger, kode dapat ditambahkan sehingga pesan atau nilai-nilai dapat ditulis ke konsol (misalnya dengan printf dalam bahasa pemrograman C) atau ke file jendela atau log untuk melacak nilai-nilai pelaksanaan program atau show.Namun, bahkan dengan bantuan debugger, menemukan bug adalah sesuatu yang seni. Hal ini tidak biasa bagi sebuah bug dalam salah satu bagian dari program untuk menyebabkan kegagalan dalam bagian yang sama sekali berbeda, sehingga membuatnya sangat sulit untuk melacak (misalnya, kesalahan dalam grafis rendering menyebabkan rutin file I / O rutin gagal) , dalam bagian tampaknya tidak terkait dari sistem.Kadang-kadang, sebuah bug bukan cacat terisolasi, tetapi merupakan kesalahan dari pemikiran atau perencanaan pada bagian programmer. kesalahan logika seperti ini membutuhkan suatu bagian dari program yang akan dirombak atau ditulis ulang. Sebagai bagian dari proses review Code, melangkah melalui kode pemodelan proses eksekusi di kepala seseorang atau di atas kertas sering dapat menemukan kesalahan tanpa pernah perlu untuk mereproduksi bug seperti itu, jika dapat ditunjukkan ada beberapa logika yang salah dalam pelaksanaannya.Tapi lebih biasanya, langkah pertama dalam menemukan sebuah bug untuk mereproduksi itu andal. Setelah bug tersebut telah direproduksi, programmer dapat menggunakan debugger atau alat lain untuk memantau pelaksanaan program di daerah yang salah, dan menemukan titik di mana program sesat.Hal ini tidak selalu mudah untuk mereproduksi bug. Ada yang dipicu oleh masukan kepada program yang mungkin sulit bagi programmer untuk menciptakan kembali.Salah satu penyebab kematian mesin-25 radiasi Therac adalah bug (khusus, kondisi lomba) yang terjadi hanya ketika operator mesin yang sangat cepat memasuki rencana pengobatan, itu mengambil hari praktek untuk menjadi mampu melakukan hal ini, maka bug itu tidak terwujud dalam pengujian atau ketika produsen berusaha untuk duplikat. bug lain mungkin hilang ketika program tersebut dijalankan dengan debugger, ini adalah heisenbugs (bercanda dinamai prinsip ketidakpastian Heisenberg.)Debugging masih merupakan tugas yang membosankan memerlukan upaya yang cukup. Sejak 1990-an, terutama setelah bencana Ariane 5 Penerbangan 501, telah terjadi minat baru dalam pengembangan alat bantu otomatis yang efektif untuk debugging. Sebagai contoh, metode analisis kode statis dengan interpretasi abstrak telah membuat prestasi signifikan, sementara masih tersisa banyak pekerjaan yang sedang berjalan.Seperti tindakan kreatif, kadang-kadang flash inspirasi akan menunjukkan solusi, tapi ini jarang dan, menurut definisi, tidak dapat diandalkan.Ada juga kelas bug yang tidak ada hubungannya dengan kode itu sendiri. Jika, misalnya, satu mengandalkan dokumentasi yang salah atau perangkat keras, kode dapat ditulis sempurna dengan benar untuk apa dokumentasi kata, tetapi bug yang benar-benar terletak pada dokumentasi atau perangkat keras, tidak kode. Namun, adalah umum untuk mengubah kode bukan bagian lain dari sistem itu, karena biaya dan waktu untuk mengubahnya umumnya kurang. Embedded sistem sering memiliki workarounds untuk bug perangkat keras, karena untuk membuat versi baru dari ROM adalah jauh lebih murah daripada remanufaktur perangkat keras, terutama jika mereka item komoditas.

Bug Management
Ini adalah praktek yang umum untuk perangkat lunak akan dirilis dengan bug diketahui yang dianggap non-kritis, yaitu, yang tidak mempengaruhi pengalaman utama sebagian besar pengguna dengan produk. Sementara produk perangkat lunak mungkin, menurut definisi, mengandung sejumlah bug yang tidak diketahui, pengukuran selama pengujian dapat memberikan perkiraan jumlah kemungkinan bug yang tersisa; ini menjadi lebih handal semakin lama suatu produk diuji dan dikembangkan ("jika kita memiliki 200 bug terakhir minggu, kita harus memiliki 100 minggu ini "). Kebanyakan proyek software besar mempertahankan dua daftar "bug dikenal" - yang dikenal untuk tim perangkat lunak, dan mereka yang diberitahu kepada pengguna. Ini bukan penipuan, namun pengguna tidak peduli dengan cara kerja internal produk. Daftar kedua menginformasikan pengguna tentang bug yang tidak tetap dalam rilis saat ini, atau tidak tetap sama sekali, dan solusi yang dapat ditawarkan.Ada berbagai alasan untuk tidak memperbaiki bugs:Para pengembang sering tidak punya waktu atau tidak ekonomis untuk memperbaiki semua bug tidak parah.Bug dapat diperbaiki dalam versi baru atau patch yang belum dirilis.Perubahan pada kode yang diperlukan untuk memperbaiki bug bisa menjadi besar, mahal, atau menunda penyelesaian proyek.Bahkan tampaknya sederhana membawa perbaikan kesempatan memperkenalkan bug baru yang tidak diketahui ke dalam sistem. Pada akhir tes / siklus memperbaiki beberapa manajer hanya dapat mengizinkan bug paling kritis yang harus diperbaiki.Pengguna mungkin bergantung pada perilaku, tidak berdokumen buggy, terutama jika script atau macro mengandalkan perilaku, hal itu mungkin memperkenalkan perubahan melanggar.Ini "bukan bug". Sebuah kesalahpahaman telah timbul antara perilaku yang diharapkan dan diberikanDiberikan di atas, sering dianggap tidak mungkin untuk menulis sepenuhnya perangkat lunak bug-bebas dari kerumitan nyata. Jadi bug dikategorikan oleh keparahan, dan rendah-beratnya bug non-kritis ditoleransi, karena mereka tidak mempengaruhi operasi yang tepat dari sistem bagi kebanyakan pengguna. NASA SATC berhasil mengurangi jumlah kesalahan untuk kurang dari 0,1 per 1000 baris kode (SLOC) Tetapi ini tidak dirasakan layak untuk proyek-proyek dunia nyata.Tingkat keparahan sebuah bug tidak sama pentingnya untuk memperbaiki, dan dua harus diukur dan dikelola secara terpisah. Pada sistem Windows Microsoft layar biru kematian agak berat, tetapi jika hanya terjadi dalam keadaan ekstrim, terutama jika mereka juga didiagnosis dan dihindari, mungkin kurang penting untuk memperbaiki dari ikon tidak mewakili fungsi dengan baik, yang meskipunmurni estetika dapat membingungkan ribuan pengguna setiap hari. Keseimbangan ini, tentu saja, tergantung pada banyak faktor; pengguna ahli memiliki harapan yang berbeda dari pemula, ceruk pasar berbeda dari pasar konsumen umum, dan sebagainya. Untuk lebih mencapai keseimbangan ini, beberapa pengembang perangkat lunak menggunakan proses triage bug diformalkan (meminjam istilah medis), di mana setiap bug baru diberi prioritas berdasarkan, frekuensi keparahan risiko, dan faktor-faktor yang telah ditentukan lain.Sebuah sekolah pemikiran dipopulerkan oleh Eric S. Raymond sebagai Hukum Linus mengatakan bahwa populer software open-source memiliki lebih banyak kesempatan untuk memiliki beberapa bug atau tidak dari perangkat lunak lain, karena "bola mata cukup diberikan, semua bug yang dangkal". Pernyataan initelah diperdebatkan, namun: spesialis keamanan komputer Elias Levy menulis bahwa "mudah untuk menyembunyikan kerentanan di kompleks, kurang dipahami dan kode sumber yang tidak berdokumen," karena, "bahkan jika orang meninjau kode, itu tidak berarti mereka memenuhi syarat untuk melakukannya ".Seperti bagian lain dari manajemen teknik, manajemen bug harus dilakukan dengan hati-hati dan cerdas karena "apa yang diukur akan dilakukan" dan mengelola murni dengan jumlah bug dapat memiliki konsekuensi yang tidak diinginkan. Jika, misalnya, pengembang dihargai dengan jumlah bug yang mereka memperbaiki, mereka alami akan memperbaiki bug termudah pertama meninggalkan yang paling sulit, dan mungkin paling berisiko atau kritis, untuk saat-saat terakhir mungkin ("Saya hanya punya satu bug pada saya daftar tetapi mengatakan "Membuat matahari terbit di Barat"). Jika etos manajemen adalah pahala jumlah bug tetap, maka beberapa pengembang cepat dapat menulis kode ceroboh mengetahui bahwa mereka dapat memperbaiki bug nanti dan diberi hadiah untuk itu, sedangkan hati-hati, mungkin "lambat" pengembang tidak mendapatkan imbalan atas bug yang pernah ada.