Rabu, 13 Juni 2012
Minggu, 10 Juni 2012
Kamis, 07 Juni 2012
Rabu, 06 Juni 2012
Selasa, 05 Juni 2012
Chapter 7 - Integrating SQA to PLC
C7 Integrating SQA to PLC
View more presentations from Ika Nurkasanah.
Referensi :
Referensi :
Galin, Daniel. 2004. Software Quality Assurance From Theory to Implementation.
Kamis, 31 Mei 2012
Rabu, 30 Mei 2012
Chapter 4 -- The components of the software quality assurance system – overview
C4 the components of the software quality
View more presentations from Ika Nurkasanah.
Untuk memperjelas gambar SQA Architecture, klik kanan >> view image pada gambar di bawah ini :
Untuk memperjelas gambar SQA Architecture, klik kanan >> view image pada gambar di bawah ini :
Rabu, 16 Mei 2012
Software Quality Metrics
Untuk mengukur kualitas suatu software, dapat digunakan pendekatan melalui metrics pengukuran. Berdasarkan referensi pada buku Galin, maka terdapat Software Quality Metrics, yaitu suatu pendekatan untuk mengukur kualitas software yang terbagi dalam 2 kalsifikasi besar, yaitu Product Metrics dan Process Metrics. Dari kedua klasifikasi tersebut, terdapat pengukuran yang lebih detail lagi, yang digambarkan melalui mindmap di bawah ini :
Berikut ini hasil zoom in bagi yang belum jelas membaca gambar di atas
Berikut ini hasil zoom in bagi yang belum jelas membaca gambar di atas
Part 3
Part 4
Rabu, 22 Februari 2012
Klasifikasi Penyebab Error pada Software
Oleh :
Ika Nurkasanah
Riskha Dwi Anggraeni
Faults atau kesalahan sendiri merupakan suatu cacat dalam perangkat lunak. Yang bisa mengakibatkan suatu perangkat lunak berjalan tidak sesuai dengan apa yang diharapkan, atau dengan kata lain, perangkat lunak tersebut rusak.
Penting melakukan analisa penyebab software error, hal ini dilakukan untuk melakukan pencegahan. Software error dapat karena “ koding error ” “kesalahan prosedur”, “kesalahan dokumentasi” atau “kesalahan data software”. Error pada software (perangkat lunak) ini sebagian besar berasal dari human error, entah dari sistem analis, programmer, tester, dokuemntasi, dan sering kali dari client.
Terdapat 9 penyebab error pada perangkat lunak,
1. Kesalahan dalam pendefinisian kebutuhan.
2. Kesalahan komunikasi antara client dan developer.
3. Penyimpangan kebutuhan Perangkat Lunak secara sengaja
4. Kesalahan Design Logika
5. Kesalahan Koding
6. Ketidak sesuaian antara dokumentasi dengan koding.
7. Kekurangan dari proses pengujian
8. Kesalahan Prosedur
9. Kesalahan Dokumentasi
Untuk memahami lebih lanjut berikut terdapat video dari IAG Consulting yang menjelaskan alasan kenapa project mengalami kegagalan.
Dari video tersebut dapat dilihat bahwa point pendefinisian kebutuhan merupakan point penting dalam pembuatan perangkat lunak.
Faulty requirement definition
Disini saya akan menjelaskan lebih lanjut terkait penyebab error pada perangkat lunak karena kesalahan dalam pendefinisian kebutuhan.
What is requirement ?
Requirements merupakan jabaran dari apa yang harus ada, apa yang harus dipenuhi, dan apa yang menjadi batasan dalam suatu proses rekayasa. Dengan kata lain requirements menjabarkan apa dan bagaimana harapan dari suatu sistem yang akan dibuat tanpa menyertakan bagaimana cara sistem tersebut mencapainya. Requirement dibagi menjadi 2, yaitu :
- Requirements fungsional , adalah suatu requirements yang mendefinisikan proses bisnis.
- Requirements non fungsional adalah restriction atau batasan yag haru ada pada sistem dan bagaimana dalam membentuk sistem tersebut. Contoh : aksesibilitas, security.
Terdapat beberapa kesalahan yang umum terjadi pada requirement documentation :
- Kekeliruan mendefinisikan requirement. Biasanya terjadi karena pihak dokumentasi tidak dapat mengakses informasi yang relefan atau informasi tersebut tidak ada.
- Kurang jelasnya tingkat prioritas pada requirement. Banyak requirement yang terlewatkan dikarenakan hanya terfokus pada satu bagian dari sistem seperti fungsional requirement tanpa memperdulikan bagian lain seperti performance requirement.
- Kelengkapan pendefinisian requirement. Bahaya dari hal ini adalah kemungkinan kesalahpahaman pada maksud.
- Menyertakan requirement yang tidak dibutuhkan dalam waktu dekat. Hal ini disebabkan oleh penulisan banyak requirement tanpa dilakukan kembali suatu review apakah setiap requirement tersebut benar-benar diperlukan atau tidak sebelum baselining requirement dilakukan.
- Writing implementation (how) instead requirement (what). Suatu spesifikasi haruslah menyatakan apa yang dibutuhkan bukan bagaimana hal itu dipenuhi.
- Unverifiable. Hal ini dapat terjadi karena pemakaian istilah-istilah yang ambigu.
Berikut adalah illustrasi betapa pentingnya requirement documentation.
Dari ilustrasi diatas dapat dilihat akan terjadi kesalahan fatal jika tidak dilakukan requirement documentation dengan baik. Selain itu kesalahan yang sering terjadi pada fase eksekusi adalah kesalahan dalam memahami logika design dan kesalahan dalam koding. Berikut ini akan membahas terkait kesalahan pada logical design.
Logical design errors
Logical Error merupakan jenis kesalahan yang cukup sulit untuk ditemukan penyebabnya. Karena aplikasi yang mengandung Logical Error berjalan tanpa pesan kesalahan, tetapi mengeluarkan hasil yang tidak diharapkan, misalnya jika aplikasi Anda menghasilkan perhitungan yang salah.
Logical Error baru dapat diketahui setelah Anda melakukan testing dan meninjau hasilnya. Logical Error dapat diperbaiki dengan memeriksa alur program dan nilai variabel yang dihasilkan.
Logical Error baru dapat diketahui setelah Anda melakukan testing dan meninjau hasilnya. Logical Error dapat diperbaiki dengan memeriksa alur program dan nilai variabel yang dihasilkan.
Kesalahan umum pada logical design error adalah:
- Pendefinisian algoritma yang salah.
- Kesalahan pada fase sequence. Karena pada dasarnya programmer lebih mudah menterjemahkan desaign melalui dokumen sequence.
- Kekeliruhan dalam mendefinisikan batasan proses bisnis.
- Kelalaian terhadap sistem perangkat lunak yang dibutuhkan.
- Kelalaian definisi mengenai tindakan yang akan dijalankan pada sistem perangkat lunak.
Coding errors
Kesalahan yang paling sering ditemukan pada saat membuat program adalah kesalahan coding atau coding error, dimana perintah atau statemen yang diketikkan menyalahi aturan pengkodean yang dimiliki oleh bahasa pemrograman yang digunakan.
Error code merupakan jenis kesalahan yang paling sering ditemui, tetapi juga pada umumnya paling mudah untuk ditanggulangi. Error code cukup mudah diketahui dan diperbaiki jika bahasa pemrograman yang kita gunakan menunjukkan baris kesalahan dengan tepat, dan menampilkan pesan kesalahan yang benar. Pada beberapa bahasa pemrograman, disediakan fasilitas Auto Syntax Check, dimana muncul sebuah pesan peringatan ketika Anda mengetikkan sintaks yang salah.
Kesalahan koding ini biasanya berawal dari kesalahpahaman dokumentasi desain, kesalahan linguistik dalam bahasa pemrograman, kesalahan dalam penerapan CASE dan tools develop lainnya, kesalahan dalam pemilihan data, dan sebagainya.
Sebuah bahasa pemrograman memiliki aturan pengkodean tersendiri yang harus dipatuhi yang jika tidak menuliskannya sesuai aturan, program akan menampilkan pesan Error code pada saat dijalankan. Kesalahan penulisan parameter pada sebuah function/procedure juga termasuk dalam kategori Syntax Error. Setiap bahasa pemrograman memiliki keyword, yaitu perintah-perintah baku yang digunakan. Kesalahan penulisan keyword juga merupakan Syntax Error.
Case study
The Explosion of the Ariane 5
On June 4, 1996 an unmanned Ariane 5 rocket launched by the European Space Agency exploded just forty seconds after its lift-off from Kourou, French Guiana.
The rocket was on its first voyage, after a decade of development costing $7 billion. The destroyed rocket and its cargo were valued at $500 million. A board of inquiry investigated the causes of the explosion and in two weeks issued a report. It turned out that the cause of the failure was a software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,767, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed.
The following paragraphs are extracted from the report of the Inquiry Board. An interesting article on the accident and its implications by James Gleick appeared in The New York Times Magazine of 1 December 1996. The CNN article reporting the explosion, from which the above graphics were taken, is also available.
On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off its flight path, broke up and exploded.
The failure of the Ariane 501 was caused by the complete loss of guidance and attitude information 37 seconds after start of the main engine ignition sequence (30 seconds after lift-off). This loss of information was due to specification and design errors in the software of the inertial reference system.
The internal SRI* software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer.
*SRI stands for Système de Référence Inertielle or Inertial Reference System.
Requirement terkait "Apa yang seharusnya dilakukan suatu sistem ? Apa kebutuhan yang harus dipenuhi oleh sistem ?". Sedangkan desain berarti menentukan "Bagaimana suatu sistem seharusnya memenuhi kebutuhan tersebut ? Dan bisa dipaparkan secara spesifikasi desain atau dalam bentuk source.
Error Analysis :
· Awalnya kecelakaan Ariane dianggap sebagai “bug” atau kesalahan dalam pemrograman.
· Secara teknikal, pada saat kecelakaan komputer mengeluarkan nilai hasil konversi yang terlalu besar yaitu konversi data 64 bit floating point ke 16 bit integer hal ini bukan sesuatu yang baik. sehingga konversi dianggap mengalami kegagalan hingga program otomatis melakukan penanganan kesalahan yaitu sesuai dengan aturan, maka kedua komputer akan segera dimatikan. Sehingga tak ada lagi informasi untuk sistem navigasi dan terjadilah bencana tersebut.
Tetapi bug disini ternyata bukanlah sekedar kesalahan pemrograman. Komputer ini mensadur dari model pendahulunya, Ariane 4. Roket Ariane 5 ini sebelumnya belum pernah dilakukan pembandingan dan pengujian secara langsung dengan Ariane 4.
Proses perlindungan ini hanya dilakukan pada variabel-variabel penting. sebelum memutuskan untuk tak melindungi variabel tersebut, telah membuktikan secara matematis bahwa tak ada kesalahan yang dapat timbul pada variabel yang tak terproteksi tersebut. Sehingga pada kondisi ini programmer tak dapat disalahkan begitu saja. Namun yang terjadi adalah pembuktian matematis untuk variabel tak terproteksi tersebut hanya valid untuk pola jalur lintas Ariane 4. Dan belum dilakukan pembuktian pada Ariane 5.
Kesalahan suatu sistem dapat diklasifkasikan menjadi tiga kategori
- Kesalahan murni perangkat keras, misal kerusakan transistor. Kesalahan ini hanya dapat didiagnosis ketika terjadi. Perbaikan dilakukan dengan penggantian perangkat keras. K
- Kesalahan tingkat menengah. Secara teoritis kesalahan ini dapat diketahui sebelum terjadi dan dihindari. Salah satu permasalahan yang menjadi kesalahan tingkat menengah namun juga dapat dikatakan untuk tingkat tinggi adalah priority inversion yang menyebabkan kondisi reset dan penundaan pelaksanaan misi.
- Kesalahan requirement. Berbeda dengan tingkat menengah, requirement atau paparan kebutuhan tidak dapat diverifikasi secara matematis. Kesalahan requirement hanya dapat ditemukan pada pengujian menyeluruh (all-up test). Pada kasus Ariane kesalahan juga terletak pada definisi kebutuhan (software requirement) perangkat lunak dan bukan pada jenis kesalahan pada siste. Kecelakaan tersebut dapat juga terjadi pada sistem yang kecil.
Case solution :
· Sistem mission-critical system sudah sepatutnya diprogram sehingga dapat menangani kondisi ketika nilai masukan atau keluaran yang tidak sesuai yang menimbulkan kerusakan sistem.
· Recovery mechanism merupakan tidakan recovery pada perangkat lunak namun merupakan bagian dari seluruh sistem. Keseluruhan perangkat lunak ini harus diimplementasikan secara benar. Namun yang dikhawatirkan adalah semakin banyak mekanisme perbaikan yang disertakan pada suatu sistem semakin besar pula kemungkinan kesalahan implementasi mekanisme tersebut.
· Software reuse akan berhasil jika telah dilakukan analisa dan uji coba dengan seksama. Sebaiknya dilakukan pembandingan dengan perangkat lunak yang sbeelumnya, untuk mendapatkan nilai pembanding. Kasus Ariane telah menunjukkan sejauh mana suatu analisis kebutuhan perangkat lunak seharusnya dilaksanakan. Namun pada kasus ini kesalahan kisaran nilai hanyalah sebuah gejala bukan penyebab.
Daftar Pustaka
Galin, Daniel. 2004. Software Quality Assurance From Theory to Implementation.
Selasa, 21 Februari 2012
Software Quality Assurance Factors
Assalamualaikum Sobat..!!!
Setelah sebelumnya saya meng-upload presentasi untuk topik Tantangan Software Quality Assurance, kali ini akan berlanjut ke Faktor - Faktor yang diperhatikan untuk melakukan penjaminan mutu suatu software. Langsung saja mainkan PREZI yang berisi ppt saya. Terima Kasih ^_^
Semoga bermanfaat...
Setelah sebelumnya saya meng-upload presentasi untuk topik Tantangan Software Quality Assurance, kali ini akan berlanjut ke Faktor - Faktor yang diperhatikan untuk melakukan penjaminan mutu suatu software. Langsung saja mainkan PREZI yang berisi ppt saya. Terima Kasih ^_^
Semoga bermanfaat...
Sabtu, 18 Februari 2012
Langganan:
Postingan (Atom)