Pertemuan 11

​

Konsep Kualitas Perangkat Lunak

Dosen: Zahra Azizah, S.Kom., M.I.S., Ph.D.

​

Politeknik Negeri Jakarta (PNJ)

Software Quality

• Pada tahun 2005, ComputerWorld [Hil05] menyesalkan bahwa:
• "perangkat lunak yang buruk mengganggu hampir setiap organisasi yang menggunakan komputer, menyebabkan jam kerja yang hilang selama downtime komputer, data yang hilang atau rusak, peluang penjualan yang terlewatkan, dukungan TI yang tinggi dan biaya pemeliharaan, dan kepuasan pelanggan yang rendah.”
• Setahun kemudian, InfoWorld [Fos06] menulis tentang
• "keadaan kualitas perangkat lunak yang menyedihkan" melaporkan bahwa masalah kualitas tidak menjadi lebih baik.
• Saat ini, kualitas perangkat lunak tetap menjadi masalah, tetapi siapa yang harus disalahkan?
• Customer menyalahkan Developer, dengan alasan bahwa praktik ceroboh mengarah pada perangkat lunak berkualitas rendah.
• Developer menyalahkan Customer (dan stakeholder lainnya), dengan alasan bahwa tanggal pengiriman yang tidak rasional dan aliran perubahan yang berkelanjutan memaksa mereka untuk mengirimkan perangkat lunak sebelum sepenuhnya divalidasi

2

Quality

• The American Heritage Dictionary defines quality as
• “a characteristic or attribute of something.”
• For software, two kinds of quality may be encountered:
• Quality of design encompasses requirements, specifications, and the design of the system.
• Quality of conformance is an issue focused primarily on implementation.
• User satisfaction = compliant product + good quality + delivery within budget and schedule

3

Quality—A Philosophical View

Robert Persig [Per74] commented on the thing we call quality:

• Quality . . . you know what it is, yet you don't know what it is. But that's self-contradictory. But some things are better than others, that is, they have more quality. But when you try to say what the quality is, apart from the things that have it, it all goes poof! There's nothing to talk about. But if you can't say what Quality is, how do you know what it is, or how do you know that it even exists? If no one knows what it is, then for all practical purposes it doesn't exist at all. But for all practical purposes it really does exist. What else are the grades based on? Why else would people pay fortunes for some things and throw others in the trash pile? Obviously some things are better than others . . . but what's the betterness? . . . So round and round you go, spinning mental wheels and nowhere finding anyplace to get traction. What the hell is Quality? What is it?

4

Quality—A Pragmatic View

• Pandangan transendental berpendapat bahwa kualitas adalah sesuatu yang segera Anda kenali, tetapi tidak dapat secara eksplisit mendefinisikan
• Tampilan pengguna melihat kualitas dalam hal tujuan spesifik pengguna akhir. Jika suatu produk memenuhi tujuan tersebut, itu menunjukkan kualitas.
• Pandangan pabrikan mendefinisikan kualitas dalam hal spesifikasi asli produk. Jika produk sesuai dengan spesifikasi, itu menunjukkan kualitas.
• Tampilan produk menunjukkan bahwa kualitas dapat dikaitkan dengan karakteristik yang melekat (misalnya, fungsi dan fitur) dari suatu produk.
• Akhirnya, pandangan berbasis nilai mengukur kualitas berdasarkan seberapa banyak pelanggan bersedia membayar untuk suatu produk. Pada kenyataannya, kualitas mencakup semua pandangan ini dan banyak lagi

5

Software Quality

Software quality can be defined as:

Proses perangkat lunak yang efektif diterapkan dengan cara yang menciptakan produk yang bermanfaat yang memberikan nilai terukur bagi mereka yang memproduksinya dan mereka yang menggunakannya.

6

Effective Software Process

• Proses perangkat lunak yang efektif menetapkan infrastruktur yang mendukung segala upaya untuk membangun produk perangkat lunak berkualitas tinggi.
• Aspek manajemen proses menciptakan checks and balances yang membantu menghindari kekacauan proyek — kontributor utama kualitas buruk.
• Praktik rekayasa perangkat lunak memungkinkan pengembang untuk menganalisis masalah dan merancang solusi yang solid — keduanya penting untuk membangun perangkat lunak berkualitas tinggi.
• Akhirnya, kegiatan payung seperti manajemen perubahan dan tinjauan teknis memiliki banyak hubungannya dengan kualitas seperti bagian lain dari praktik rekayasa perangkat lunak

7

Useful Product

• Produk yang bermanfaat memberikan konten, fungsi, dan fitur yang diinginkan pengguna akhir
• Tetapi yang sama pentingnya, ini memberikan aset ini dengan cara yang andal dan bebas kesalahan.
• Produk yang bermanfaat selalu memenuhi persyaratan yang telah dinyatakan secara eksplisit oleh stakeholder.
• Selain itu, memenuhi serangkaian persyaratan implisit (misalnya, kemudahan penggunaan) yang diharapkan dari semua perangkat lunak berkualitas tinggi.

8

Adding Value

• Dengan menambahkan nilai bagi produsen dan pengguna produk perangkat lunak, perangkat lunak berkualitas tinggi memberikan manfaat bagi organisasi perangkat lunak dan komunitas pengguna akhir.
• Organisasi perangkat lunak mendapatkan nilai tambah karena perangkat lunak berkualitas tinggi membutuhkan lebih sedikit upaya pemeliharaan, lebih sedikit perbaikan bug, dan berkurangnya dukungan customer.
• Komunitas pengguna mendapatkan nilai tambah karena aplikasi menyediakan kemampuan yang berguna dengan cara yang mempercepat beberapa proses bisnis.
• Hasil akhirnya adalah:
• pendapatan produk perangkat lunak yang lebih besar,
• profitabilitas yang lebih baik ketika aplikasi mendukung proses bisnis, dan / atau
• peningkatan ketersediaan informasi yang sangat penting bagi bisnis.

9

Quality Dimensions

David Garvin [Gar87]:

• Performance Quality. Apakah perangkat lunak memberikan semua konten, fungsi, dan fitur yang ditentukan sebagai bagian dari model persyaratan dengan cara yang memberikan nilai kepada pengguna akhir?
• Feature quality. Apakah perangkat lunak menyediakan fitur yang mengejutkan dan menyenangkan end user pertama kali?
• Reliability. Apakah perangkat lunak memberikan semua fitur dan kemampuan tanpa kegagalan? Apakah tersedia saat dibutuhkan? Apakah itu memberikan fungsionalitas yang bebas dari kesalahan?
• Conformance. Apakah perangkat lunak sesuai dengan standar perangkat lunak lokal dan eksternal yang relevan dengan aplikasi? Apakah itu sesuai dengan konvensi desain dan pengkodean de facto? Misalnya, apakah antarmuka pengguna sesuai dengan aturan desain yang diterima untuk pemilihan menu atau input data

10

Quality Dimensions

• Durability. Dapatkah perangkat lunak dipertahankan (diubah) atau diperbaiki (debugged) tanpa menghasilkan efek samping yang tidak diinginkan secara tidak sengaja? Apakah perubahan akan menyebabkan tingkat kesalahan atau keandalan menurun seiring waktu?
• Serviceability. Dapatkah perangkat lunak dipertahankan (diubah) atau diperbaiki (debugged) dalam jangka waktu singkat yang dapat diterima. Dapat mendukung staf memperoleh semua informasi yang mereka butuhkan untuk membuat perubahan atau memperbaiki cacat?
• Aesthetics. Sebagian besar dari kita akan setuju bahwa entitas estetika memiliki keanggunan tertentu, aliran yang unik, dan "kehadiran" yang jelas yang sulit untuk diukur tetapi tetap terbukti.
• Perception. Dalam beberapa situasi, Anda memiliki serangkaian prasangka yang akan memengaruhi persepsi Anda tentang kualitas.

11

McCall’s Quality Factors

• McCall dan Walters [McC77] mengusulkan cara yang berguna untuk memikirkan dan mengatur faktor-faktor yang mempengaruhi kualitas perangkat lunak.
• Faktor kualitas McCall memberikan dasar untuk perangkat lunak rekayasa yang memberikan tingkat kepuasan pengguna yang tinggi dengan berfokus pada pengalaman pengguna secara keseluruhan yang disampaikan oleh produk perangkat lunak.

12

ISO 25010 Quality Factors

• Model mutu ISO 25010 adalah standar terbaru (dibuat pada tahun 2011 dan direvisi pada tahun 2017).
• Standar ini mendefinisikan dua model kualitas.
• Model kualitas penggunaan menggambarkan lima karakteristik yang sesuai ketika mempertimbangkan untuk menggunakan produk dalam konteks tertentu (misalnya, menggunakan produk pada platform tertentu oleh manusia).
• Model kualitas produk menggambarkan delapan karakteristik yang berfokus pada sifat statis dan dinamis dari sistem komputer.

13

ISO 25010 Quality Factors

• Quality in Use Model
• Effectiveness. Accuracy and completeness with which users achieve goals
• Efficiency. Resources expended to achieve user goals completely with desired accuracy
• Satisfaction. Usefulness, trust, pleasure, comfort
• Freedom from risk. Mitigation of economic, health, safety, and environmental risks
• Context coverage. Completeness, flexibility
• Product Quality
• Functional suitability. Complete, correct, appropriate
• Performance efficiency. Timing, resource utilization, capacity
• Compatibility. Coexistence, interoperability

14

ISO 25010 Quality Factors

• Usability. Appropriateness, learnability, operability, error protection, aesthetics, accessibility
• Reliability. Maturity, availability, fault tolerance, recoverability
• Security. Confidentiality, integrity, accountability, authenticity
• Maintainability. Modularity, reusability, modifiability, testability
• Portability. Adaptability, installability, replaceability

15

The Software Quality Dilemma

• Jika Anda menghasilkan sistem perangkat lunak yang memiliki kualitas buruk, Anda kalah karena tidak ada yang mau membelinya.
• Jika di sisi lain Anda menghabiskan waktu tak terbatas, usaha yang sangat besar, dan sejumlah besar uang untuk membangun perangkat lunak yang benar-benar sempurna, maka itu akan memakan waktu lama untuk diselesaikan dan akan sangat mahal untuk diproduksi sehingga Anda akan gulung tikar.
• Entah Anda melewatkan jendela pasar, atau Anda hanya menghabiskan semua sumber daya Anda.
• Jadi orang-orang di industri mencoba untuk sampai ke jalan tengah ajaib di mana produk cukup baik untuk tidak langsung ditolak, seperti selama evaluasi, tetapi juga bukan objek dari begitu banyak perfeksionisme dan begitu banyak pekerjaan yang akan memakan waktu terlalu lama atau biaya terlalu banyak untuk menyelesaikannya. [Ven03]

16

“Good Enough” Software

• Perangkat lunak yang cukup baik memberikan fungsi dan fitur berkualitas tinggi yang diinginkan pengguna akhir, tetapi pada saat yang sama memberikan fungsi dan fitur lain yang lebih tidak jelas atau khusus yang mengandung bug yang diketahui.
• Argumen menentang “Good Enough.“
• Memang benar bahwa "cukup baik" dapat bekerja di beberapa domain aplikasi dan untuk beberapa perusahaan perangkat lunak besar. Lagi pula, jika sebuah perusahaan memiliki anggaran pemasaran yang besar dan dapat meyakinkan cukup banyak orang untuk membeli versi 1.0, itu telah berhasil mengunci mereka.
• Jika Anda bekerja untuk perusahaan kecil, waspadalah terhadap filosofi ini. Jika Anda memberikan produk yang "cukup baik" (buggy), Anda berisiko merusak reputasi perusahaan Anda secara permanen.
• Anda mungkin tidak pernah mendapatkan kesempatan untuk memberikan versi 2.0 karena buzz buruk dapat menyebabkan penjualan Anda anjlok dan perusahaan Anda melipat.
• Jika Anda bekerja di domain aplikasi tertentu (misalnya, real time embedded software, perangkat lunak aplikasi yang terintegrasi dengan perangkat keras dapat lalai dan membuka perusahaan Anda untuk litigasi mahal

17

Cost of Quality

• Prevention costs include
• quality planning
• formal technical reviews
• test equipment
• Training
• Internal failure costs include
• rework
• repair
• failure mode analysis
• External failure costs are
• complaint resolution
• product return and replacement
• help line support
• warranty work

18

Cost

• Biaya relatif untuk menemukan dan memperbaiki kesalahan atau cacat meningkat secara dramatis saat kita beralih dari pencegahan ke deteksi ke kegagalan internal ke biaya kegagalan eksternal

19

Quality and Risk

• “Orang-orang mempertaruhkan pekerjaan mereka, kenyamanan mereka, keselamatan mereka, hiburan mereka, keputusan mereka, dan kehidupan mereka pada perangkat lunak komputer. Lebih baik benar.”
• Contoh:

Sepanjang bulan November 2000 di sebuah rumah sakit di Panama, 28 pasien menerima overdosis sinar gamma selama pengobatan untuk berbagai jenis kanker. Pada bulan-bulan berikutnya, lima dari pasien ini meninggal karena keracunan radiasi dan 15 lainnya mengalami komplikasi serius. Apa yang menyebabkan tragedi ini? Paket perangkat lunak, yang dikembangkan oleh perusahaan AS, dimodifikasi oleh teknisi rumah sakit untuk menghitung dosis radiasi yang dimodifikasi untuk setiap pasien.

20

Kelalaian dan Kewajiban

• Ceritanya terlalu umum. Entitas pemerintah atau perusahaan menyewa pengembang perangkat lunak besar atau perusahaan konsultan untuk menganalisis persyaratan dan kemudian merancang dan membangun "sistem" berbasis perangkat lunak untuk mendukung beberapa aktivitas utama.
• Sistem ini mungkin mendukung fungsi perusahaan besar (misalnya, manajemen pensiun) atau beberapa fungsi pemerintahan (misalnya, administrasi kesehatan atau keamanan dalam negeri).
• Pekerjaan dimulai dengan niat terbaik di kedua sisi, tetapi pada saat sistem disampaikan, semuanya menjadi buruk.
• Sistem terlambat, gagal memberikan fitur dan fungsi yang diinginkan, rawan kesalahan, dan tidak memenuhi persetujuan customer.
•  Litigasi pun terjadi.

21

Quality and Security

Gary McGraw comments [Wil05]:

• “Keamanan perangkat lunak berhubungan sepenuhnya dan sepenuhnya dengan kualitas. Anda harus berpikir tentang: security, reliability, availability, dependability—at the beginning, in the design, architecture, test, and coding phases, all through the software life cycle [process]. Bahkan orang-orang yang sadar akan masalah keamanan perangkat lunak telah berfokus pada hal-hal siklus hidup yang terlambat. Semakin awal Anda menemukan masalah perangkat lunak, semakin baik. Dan ada dua jenis masalah perangkat lunak. Salah satunya adalah bug, yang merupakan masalah implementasi. Yang lainnya adalah kelemahan perangkat lunak — masalah arsitektur dalam desain. Orang terlalu memperhatikan bug dan tidak cukup pada kekurangan.”

22

Achieving Software Quality

 Critical success factors:

•  Software Engineering Methods
•  Project Management Techniques
•  Quality Control
•  Quality Assurance

23

Terima Kasih

LATIHAN

1. Jelaskan bagaimana Anda akan menilai kualitas universitas sebelum mendaftar. Faktor apa yang penting? Mana yang akan kritis?
2. Apa itu perangkat lunak "cukup baik"? Sebutkan perusahaan tertentu dan produk spesifik yang Anda yakini dikembangkan menggunakan filosofi yang cukup baik.
3. Mempertimbangkan masing-masing dari empat aspek biaya kualitas, mana yang menurut Anda paling mahal dan mengapa?
4. Lakukan pencarian Web dan temukan tiga contoh lain dari "risiko" kepada publik yang dapat langsung ditelusuri ke kualitas perangkat lunak yang buruk. Pertimbangkan untuk memulai pencarian Anda di http://catless.ncl .ac.uk/risks.

25