Your SlideShare is downloading. ×
  • Like
ikp321-01
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

ikp321-01

  • 521 views
Published

 

Published in Education , Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
521
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
18
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Manajemen dan Kualitas Perangkat Lunak IKP321 Pendahuluan
  • 2. Administratif Perkuliahan Komponen Penilaian  10% Kuis  20% Tugas  30% UTS (18 April 2012, Open notes)  40% UAS (20 Juni 2012, Open book)  5% Bonus (aktifitas, kreatifitas, inovasi)
  • 3. Administratif Perkuliahan Kehadiran  Kenyamanan dan Kemudahan bersama  30 menit toleransi keterlambatan bagi mahasiswa dan dosen  Minimum partisipasi kehadiran 70% sepanjang semester Prasyarat  Rekayasa Perangkat Lunak  Basis Data
  • 4. Administratif Perkuliahan 12 pekan  Senin  13.20 – 15.49 WIB
  • 5. Contoh Kejadian Nyata Denver International Airport (DIA)  Opens February 1995  Planned to serve 110 000 000 passengers annually by 2020  Planned to handle 1750 flights daily  200 gates  12 operating runways
  • 6. Contoh Kejadian Nyata Operations at DIA were delayed by 16 months,  mainly due to the failure of the software-based baggage handling system  estimated total losses of $2 billion  the baggage handling system finally put into service  substantially downscaled in comparison to the system originally specified
  • 7. Contoh Lain Arianne  Floating point rounding error Fukushimas power plant cooling system  Backup system failed to work properly  14 days to cool down
  • 8. Software Software  Quality Assurance  Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of computer systems Code  Instruksi bahasa pemrograman Procedures  Urutan langkah di dalam program (algoritme)  Metode instalasi  User role
  • 9. Software Documentation  Users guide  Developers guide  Maintenance personnel Data  Configuration files  Testing suite
  • 10. Software errors, faults and failures Lessons learned from DIA case  Software failure Software failure  The origin of software failures lies in a software error made by a programmer.  grammatical error  Runtime error  logical error
  • 11. Software errors, faults and failures Tidak semua kesalahan software (error) menyebabkan software faults Kesalahan software dapat menyebabkan  Software tidak berfungsi sebagaimana mestinya (failure)  Kesalahan "dinetralisasi" oleh baris-baris program berikutnya Fokus pembahasan IKP321  Software failures yang menghentikan penggunaan software  Sebab-sebabnya  Bagaimana mencegahnya
  • 12. Software Quality Software Quality  Assurance Poor software quality, Software failure Penyebab software failure Tindakan pencegahan Software error  Code error  Procedural error  Documentation error  Data error
  • 13. Penyebab Software Error To Err is Human  Alexander Pope, (1688-1744) Humans  System analysts  Programmer  Software tester  Documentation experts  Clients and representatives Bagaimana dengan Kompilator?
  • 14. Penyebab Software Error To Err is Human  Alexander Pope, (1688-1744) Humans  System analysts  Programmer  Software tester  Documentation experts  Clients and representatives Bagaimana dengan Kompilator?  Compiler is software  Made by humans
  • 15. Munculnya Error dalam Tahapan Pengembangan Software Faulty requirements definition Client-developer communication failures Deliberate deviations from software requirements Logical design errors Coding errors Non-complieance with documentation and coding guidelines Shortcomings of testing process Procedure errors Documentation errors
  • 16. Faulty software requirements Biasanya dibuat oleh klien Definisi kurang jelas atau salah Deskripsi kebutuhan tidak jelas Kebutuhan yang penting justru tidak terdokumentasi Kebutuhan yang tidak penting justru terdokumentasi
  • 17. Client-developer communication failure Defective communication  Perbedaan umur  Perbedaan latar belakang ilmu Kesalahpahaman  Salah memahami instruksi klien  Salah memahami definisi klien  Salah memahami permintaan perubahan  Klien salah memahami keterbatasan development  Disampaikan secara tertulis maupun lisan
  • 18. Deliberate deviations from software requirements Software requirement sengaja tidak dipenuhi Time pressure, Budget pressure Situasi yang sering terjadi  Reuse previous software, without sufficient analysis for changes  Mengabaikan required functionality  Menambahkan improvement yang tidak ada dalam software requirement
  • 19. Logical design errors Sofware requirements dibuat oleh pihak developer  Software architects  System analysts  Software engineers Situasi yang umum ditemukan  Mendefinisikan software requirements dengan algoritma yang kurang tepat  Definisi proses yang memuat kesalahan urutan
  • 20. Logical design errors Definisi boundary kurang tepat Menghilangkan kondisi sistem yang justru penting untuk disertakan Menghilangkan definisi yang terkait dengan reaksi sistem terhadap illegal operation
  • 21. Coding errors Beragam alasan dan sebab Salah memahami dokumentasi Linguistic error pada bahasa pemrograman Error pada development tools yang digunakan Kesalahan dalam menggunakan data dsb
  • 22. Non-compliance with docs and coding instructions Documentation and Coding standards  Mendefinisikan isi, urutan, dan format dokumen  Mendefinisikan penulisan program  Penamaan variabel, package  Template documents  Coding instructions Anggota tim harus mengikuti standar yang ditentukan
  • 23. Non-compliance with docs and coding instructions Kualitas "non-complying" software  Mungkin masih tolerable  Meningkatkan resiko munculnya error Masalah komunikasi antar anggota tim  Anggota tim yang perlu berkoordinasi dengan anggota "non-complying" akan banyak menemui masalah  Anggota baru yang menggantikan anggota "non- complying" akan sulit memahami hasil kerja mereka
  • 24. Non-compliance with docs and coding instructions The design review team will find it more difficult to review a design prepared by a non-complying team The test team will find it more difficult to test the module; consequently, their efficiency is expected to be lower, leaving more errors undetected Maintenance teams required to contend with the “bugs” detected by users and to change or add to the existing software will face difficulties when trying to understand the software and its documentation
  • 25. Shortcomings of the testing process Testing process yang diabaikan membuat jumlah error yang undetected atau uncorrected bertambah besar Sebab-sebab testing process diabaikan  Incomplete test plans  Kegagalan mendokumentasikan dan melaporkan error dan fault yang sempat terdeteksi  Negligence or time pressures
  • 26. Procedure errors Procedures mengarahkan user untuk mengikuti tahapan-tahapan dalam menggunakan software Sangat penting perannya dalam sistem software yang kompleks Ada langkah-langkah yang harus dilakukan bertahap Setiap tahap bergantung kepada data yang dihasilkan dari tahap sebelumnya
  • 27. Documentation errors Design documents Documentation integrated into the body of the software Memunculkan error baru dalam pengembangan berikutnya dan dalam pemeliharaan
  • 28. Documentation errors User manuals yang kurang lengkap Online help yang kurang lengkap Software functions yang tidak terdokumentasi Kesalahan dalam memberikan penjelasan Kesalahan dalam memberikan instruksi Software functions yang belum terupdate di versi software yang baru
  • 29. Pustaka Daniel Galin, "Software Quality Assurance: From Theory to Implementation" tjerdastangkas.blogspot.com/search/label/ikp321