Dokumen ini membahas manajemen dan kualitas perangkat lunak dalam mata kuliah IKP321, termasuk komponen penilaian dan perspesi kehadiran. Selain itu, dijelaskan contoh-contoh nyata terkait masalah perangkat lunak dan kesalahan yang dapat terjadi selama pengembangan, serta pentingnya pengujian dan dokumentasi yang baik. Fokus utama adalah memahami penyebab kesalahan perangkat lunak dan bagaimana cara mencegahnya untuk meningkatkan kualitas perangkat lunak.

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
 Fukushima's 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
 User's guide
 Developer's 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