![10. Interoperability
Kemampuan untuk membedakan system dan mengorganisasikan unuk bekerjasama
(inter operate). Dan interfacenya sangat compatible untuk bekerja dengan system
lainnya diwaktu ini ataupun dikemudianhari, tanpa implementasi.
11. Reuseability
Segmen dari sourcecode dapat digunakan kembali untuk menambahkan fungsi baru.
Pengukuran Perangkat Lunak
Pertanyaan pertama yang muncul ketika membahas pengukuran kualitas perangkat
lunak, adalah apa yang sebenarnya mau kita ukur.
Kualitas perangkat lunak dapat dilihat dari sudut pandang proses pengembangan
perangkat lunak (process) dan hasil produk yang dihasilkan (product).
Dan penilaian ini tentu berorientasi akhir ke bagaimana suatu perangkat lunak dapat
dikembangkan sesuai dengan yang diharapkan oleh pengguna. Hal ini berangkat dari
pengertian kualitas (quality) menurut IEEE Standard Glossary of Software
Engineering Technology [3] yang dikatakan sebagai:
The degree to which a system, component, or process meets customer or user
needs or expectation.
Dari sudut pandang produk, pengukuran kualitas perangkat lunak dapat menggunakan
standard dari ISO 9126 atau best practice yang dikembangkan para praktisi dan
pengembang perangkat lunak.
Taksonomi McCall adalah best practice yang cukup terkenal dan diterima banyak
pihak, ditulis oleh J.A. McCall dalam technical report yang dipublikasikan tahun
1977 [1].](https://image.slidesharecdn.com/softwaretesting-120417062418-phpapp01/85/Software-testing-12-320.jpg)
Software testing
- 1. PROSES TESTING Testing dan Implementasi Sistem Dosen : Mei P. Kurniawan Kelompok 3 Yulia Muharomah 09.12.4156 Zeptifa Wardani 09.12.4132 Ferry Dwi Laksono 09.12.4162 Dwi Sundari 09.12.4125 Tias Arini 09.12.4131 Sekolah Tinggi Ilmu Manajemen dan Komputer AMIKOM Yogyakarta 2012
- 2. PROSES TESTING A. Kesalahan Pengujian 1. Fault (Kekeliruan) Fault merupakan kesalahan pada sebuah baris kode atau lebih. Kesalahan bisa saja tidak tampak pada program dengan indikasi perangkat lunak bekerja sebagaimaa harapan pengembang. Bahkan mungkin untuk waktu yang lama, sebuah baris program bisa saja tidak tersentuh oleh eksekusi sehingga tidak tampak sebagai kekeliruan. 2. Eror (Kesalahan) Hal yang akan muncul pada saat terjadi kekeliruan adalah kesalahan. Bila kekeliruan dalam baris dieksekusi, perangkat lunak akan melakukan operasi yang tidak sesuai dengan keinginan pengembang sehingga menghasilkan respons yang salah. 3. Failure (Kegagalan) Dalam beberapa kasus, kekeliruan akan muncul sebagai kegagalan. Kegagalan perangkat lunak merupakan sederetan ketidakmampuan perangkat lunak untuk menjalankan fungsinya. Misalnya kesalahan keluaran perangkat lunak, proses eksekusi yang tidak normal, waktu eksekusi dan kapasitas penyimpanan yang membengkak, dan lain-lain. Kemudian failure masih dibagi lagi, yaitu : - Requirement faillure bug yang dilaporkan berhubungan dengan kegagalan sistem untuk memenuhi kebutuhan. - Non requirement failure
- 3. bug yang dilaporkan tidak memenuhi kebutuhan sistem, tetapi secara signifikan mempengaruhi kualitas sistem dengan cara yang tidak dapat diterima. - Waiver failure bug yang dilaporkan mendeskripsikan kegagalan, tetapi developer menuntut dan menganggap hal tersebut tidak signifikan mempengaruhi kualitas dan user experience. - External failure bug yang dilaporkan menunjukkan kegagalan karena faktor eksternal atau di luar kontrol dari sistem yang diuji. - Test failure developer meyakini bahwa pengujian yang dikembalikan adalah invalid error. B. Proses Pengujian Awal Pengujian kadang-kadang disalah pahami sebagai kegiatan after the fact, dilakukan setelah pemrograman sebuah produk dilakukan. Namun, pengujian harus dilakukan setiap tahapan pengembangan produk. Penetapan pengujian data harus diperoleh, kebenaran dan konsistesinya harus dipantau selama proses pengembangan. Jika kita membagi siklus hidup pengembangan perangkat lunak menjadi “Analisis Kebutuhan”,”Desain”,”Pemrograman/Konstruksi” dan “Operasi dan Pemeliharaan” maka pengujian harus dilakukan di setiap tahapan pengembangan tersebut jika pengujian menemukan kesalahan dan pernyataan masalah atau desain bisa mendatangkan biaya terlalu tinggi. Tidak hanya kesalahan utama yang harus diperbaiki, tetapi seluruh struktur dibangun diatasnya juga harus diubah. Oleh karena itu, pengujian tidak boleh terisolasi sebagai kegiatan inspeksi, tetapi harus melibatkan seluruh SDLC untuk menghasilkan produk yang berkualitas.
- 4. C. Proses Pengujian Akhir Proses pengujian akhir sulit untuk ditentukan karena kebanyakan aplikasi perankat lunak modern sangat kompleks dan berjalan sebagai lingkungan interdependen dan pengujian lengkap pun tidak pernah bisa dilakukan. Kapan menghentikan pengujian? Menjadi salah satu pertanyaan yang paling sulit bagi perekayasa penguji. Faktor uum dalam memutuskan untuk berhenti adalah : 1. Tenggat waktu (deadline) yaitu tenggat rilis dan pengujian 2. Kasus-kasus pengujian diselesaikan dengan presentase tertentu yang dilewatkan 3. Biaya pengujian habis 4. Pemenuhan kode/fungsionalitas/persyaratan menjangkau titik yang telah ditentukan 5. Tingkat pada bug yang dapat ditemukan terlalu kecil 6. Beta atau pengujian alfa telah berakhir periodenya 7. Risiko dalam proyek dapat diterima dibawah batas. Pada kenyataannya, keputusan menghentikan pengujian berdasarkan pada tingkat risiko yang dapat diterima oleh manajemen. Sebagai catatan, pengujian adalah proses yang tidak pernah berakhir dan tidak pernah mengaggap bahwa pengujian 100% telah selesai, kita hanya dapat meminimalkan risiko pegiriman produk kepada klien dengan X pengujian yang sudah diselesaikan. Risiko dapat diukur oleh aalisis risiko, tetapi durasi kecil/anggaran rendah/ randahnya sumber daya proyek, dapat disimpulkan dengan : 1. Mengukur pemenuhan pengujian
- 5. 2. Jumlah siklus pengujia 3. Jumlah bug prioritas tinggi D. Automatic Testing Otomatisasi testing adalah alat bantu yang digunakan untuk mempermudah proses dan dokumentasi tes, mengefisienkan eksekusi dari tes, dan mempermudah pengukuran pada tes. Sehingga diharapkan dapat memberikan peningkatan yang cukup besar dalam manajemen proses, meminimalkan keterlibatan manusia, dan replikasi pekerjaan. Otomatisasi testing adalah area yang paling tinggi tingkat perkembangannya dalam industri testing. Alasan untuk melakukan otomatisasi proses software adalah untuk meningkatkan kualitas dan produktifitas kerja. Organisasi membutuhkan suatu strategi otomatisasi untuk menuntun dalam menggunakan metode-metode dan teknik-teknik baru. Hal ini membutuhkan pengetahuan tentang apa yang dibutuhkan, pengetahuan terhadap apa yang fisibel, dan pengembangan suatu rencana yang telah ditetapkan. Alasan dibutuhkannya otomatisasi testing Mengapa otomatisasi testing dibutuhkan? Dari uraian singkat di atas, terdapat beberapa alasan pentingnya melakukan otomatisasi testing, adalah sebagai berikut: 1. Testing selalu diharapkan pada masalah jadwal yang ketat2. Testing sering diulang - ulang banyak sekali 3. Testing berkemungkinan untuk sijalankan 24 jam sehari, atau tidak pada jam kerja. 4. Testing dapat dilakukan dengan lebih cepat dan akurat, dimana ketidaksonsistenan manusai dapat diminimalkan. 5. Dokumentasi testing dapat dilakukan secara konsisten, sehingga dapat diaudit secara penuh dan berkala.
- 6. 6. Script testing dapat menjadi aset yang dapat digunakan kembali untuk testing yang sama pada proyek testing yang lain. 7. Mempercepat dalam peninjauan kembali terhadap testing itu sendiri 8. Dapat meningkatkan proses Dikarenakan ujicoba software menghabiskan sekitar 40% dari total usaha yang diperlukan untuk sebuah proyek pengembangan software, maka tools tools yang dapat mengurangi waktu uji sangat dibutuhkan. Dengan melihat manfaat potensialnya, maka dibentuklah generasi pertama dari automated test tools. Miller mendeskripsikannya menjadi beberapa kategori, diantaranya : 1. Static Analyzer, program sistem analisis ini mendukung untuk pembuktian dari pernyataan tanpa bukti statis, perintah-perintah yang lemah dalam struktur program dan format. 2. Code Auditors, sebuah filter dengan kegunaan khusus yang digunakan untuk memeriksa kualitas software untuk memastikan bahwa software tersebut telah memenuhi standars pengkodean minimum 3. Assertion Processors, sistem preprocessor/postprocessor ini digunakan untuk memberitahukan programmer dengan menyediakan klaim, yang disebut assertion, yaitu mengenai suatu perilaku program yang benar-benar ditemukan saat pelaksanaan program riil. 4. Test File Generators, merupakan pembangun processor, dan dipenuhi dengan definisi awal nilai, file masukan yang serupa untuk program yang sedang diujikan.
- 7. 5. Test Data Generators merupakan sistem analisis otomatis yang membantu pengguna aplikasi dalam memilih data uji yang menyebabkan program berperilaku khusus. 6. Test Verifiers, tool ini mengukur cakupan uji internal, terkadang berhubungan dengan uji struktur kontrol dari objek uji, dan melaporkan cakupan nilai untuk para ahli jaminan kualitas 7. Test Harnesses. Tools ini mendukung pemrosesan uji coba dengan (1) meng-instal program kandidat dalam lingkungan uji, (2) berikan input data, dan (3) simulasikan dengan menggunakan stubs perilaku dari modul-modul subordinat. 8. Output Comparators, tool ini membuatnya sangat memungkinkan untuk membantingkan sekumpulan output dari suatu program dengan sekumpulan output dari proses sebelumnya(yang telah diarsipkan) untuk menentukan perbedaan diantara keduanya. Dunn menambahkan tool otomatis diatas, dantaranya : 1. Symbolic Execution System, tool ini penampilkan ujicoba program dengan menggunakan input aljabar, dari pada nilai data numerik,. Software yang diuji akan menguji satu class data uji dari pada satu kasus uji spesifik. Output yang dihasilkan dalam bentuk aljabar dan dapat dibandingkan dengan output yang diharapkan yang telah ditulis dalam bentuk aljabar.
- 8. 2. Environment Simulator, merupakan tool untuk sistem berbasis komputer khusus, yang mampu untuk menguji model lingkungan eksternal dari suatu software realtme, dan mensimulasikan kondisi operasi sesungguhnya secara dinamis. 3. Data Flow Analyzer, tool ini melacak aliran data yang melewati sistem, dan berusaha untuk menemukandata reference yang belum didefinisikan , peng-indeks-an yang salah, dan kesalahan data terkait lainnya. Manual Testing VS Automated Testing Test Step Manual Autimated Precent Testing Testing Improve Test plan development 32 40 -25% Test case development 262 117 55% Test execution 466 23 95% Test result analyses 117 58 50% Defect tracking 117 23 80% Report creation 96 16 83% 1090 277 75% Total hours E. Kualitas Software
- 9. Kualitas Software didefinisikan sebagai kesesuaian yang diharapkan pada semua perangkat lunak yang dibangun berkaitan dengan fungsi perangkat lunak yang diutamakan dan untuk kerja perangkat lunak, standar pembangunan perangkat lunak yang terdokumentasi dan karakteristik yang ditunjukkan oleh perangkat lunak. Definisi ini menekankan pada tiga hal, yaitu : 1. Kebutuhan perangkat lunak adalah dasar ukuran kualitas perangkat lunak, jika perangkat lunak tidak sesuai dengan kebutuhan yang ditentukan, kualitasnya pun berkurang. 2. Jika menggunakan sebuah standar untuk pembangunan perangkat lunak, maka perangkat lunak dianggap kurang berkualitas jika tidak memenuhi standar tersebut. 3. Sering kali ada kualitas yang secara langsung diutarakan (tersurat) seperti kemudahan penggunaan dan pemeliharaan yang baik. Kualitas perangkat lunak dipertanyakan jika tidak memenuhi kebutuhan ini. Sedangkan definisi kualitas menurut The Internasional Standarts Organization (ISO) adalah totalitas fitur-fitur dan karakteristik-karakteristik dari produk atau layanan yang berpengaruh pada kemampuan untuk memenuhi kebutuhan tertentu atau kebutuhan yang tersirat. Faktor kualitas operasi produk 1. Correcnes Memperluas sebuah program yang memenuhi spesifikasi dan tujuan pengguna. 2. Portability.
- 10. Kemudahan pemindahan software ke platform lain. Portability pada software, sangat tergantung kepada teknologi yang digunakan. Pemilihan teknologi didasari oleh pertimbangan yang matang berdasarkan hasil analisis terhadap calon pengguna. Jika calon pengguna menggunakan platform yang heterogen, maka portability adalah hal yang sangat penting. Namun portability akan berkurang prioritasnya ketika calon pengguna menggunakan spesifikasi teknologi yang seragam. 3. Reliability. Software dapat diandalkan untuk melakukan apa yang seharusnya dilakukan. Reliability adalah atribut yang tidak dapat ditawar. Hal ini dapat dicapai dengan melakukan proses analisis kebutuhan calon pengguna dengan baik. Dengan menganalisa masalah calon pengguna, lalu menyimpulkan solusi dari maka engineer dapat lebih menjamin reliability dari suatu software. Selain dari sisi analisis kebutuhan, pengujian sistem dengan mekanisme yang baik juga dapat meningkatkan reliability software. Pengujian sistem adalah fase untuk memastikan bahwa sistem sudah dapat berjalan sesuai dengan yang diharapkan oleh pengembang perangkat lunak. 4. Efficiency. Software dapat melakukan pekerjaan dengan waktu kerja dan penggunaan resource yang ekonomis. Efficiency adalah atribut yang seringkali tidak diperhatikan. Umumnya hal tersebut terjadi, karena tim pengembang fokus kepada spesifikasi fungsional sistem. Ketika spesifikasi fungsional sudah terpenuhi, maka modul software dianggap telah mencapai kualitas yang baik. Efficiency seringkali tidak terasa dibutuhkan pada aplikasi sistem informasi yang tidak melakukan proses yang rumit. Namun untuk proses yang rumit, efficiency menjadi hal yang sangat penting untuk diperhatikan. Efficiency dapat dicapai dengan disain yang baik dan code review terhadap hasil implementasi disain yang dilakukan. Selain itu, pada saat
- 11. pengujian (testing), perlu dilakukan stress testing, suatu proses pengujian yang menekankan pada kemampuan software pada saat melakukan proses pada keadaan yang tersulit (contohnya adalah dikarenakan oleh data yang sangat banyak). 5. Maintainabily Software mudah dipelihara (maintain) dan diubah. 6. Testability. Software mudah dievaluasi dengan melakukan pengujian (testing). Testability akan berpengaruh terhadap reliability. Engineer dapat menyimpulkan bahwa suatu software sudah cukup reliable untuk direlease adalah berdasarkan hasil pengujian. Karena itu, testability adalah atribut yang sangat penting dalam pengembagan software. 7. Integrity Memperluas akses untuk perangkat lunak atau data tanpa diotorisasi dan tidak dikontrol 8. Fleksibelity Software mampu untuk beradaptasi dan bekerja dengan efektif sesuai dengan apa yang dibutuhkan user. 9. Useability Software mudah dipahami sehingga memudahkan proses pemeliharaan. Usaha yang dibutuhkan untuk mempelajari, mengoperasikan, mempersiapkan masukan, dan menerjemahkan keluaran
- 12. 10. Interoperability Kemampuan untuk membedakan system dan mengorganisasikan unuk bekerjasama (inter operate). Dan interfacenya sangat compatible untuk bekerja dengan system lainnya diwaktu ini ataupun dikemudianhari, tanpa implementasi. 11. Reuseability Segmen dari sourcecode dapat digunakan kembali untuk menambahkan fungsi baru. Pengukuran Perangkat Lunak Pertanyaan pertama yang muncul ketika membahas pengukuran kualitas perangkat lunak, adalah apa yang sebenarnya mau kita ukur. Kualitas perangkat lunak dapat dilihat dari sudut pandang proses pengembangan perangkat lunak (process) dan hasil produk yang dihasilkan (product). Dan penilaian ini tentu berorientasi akhir ke bagaimana suatu perangkat lunak dapat dikembangkan sesuai dengan yang diharapkan oleh pengguna. Hal ini berangkat dari pengertian kualitas (quality) menurut IEEE Standard Glossary of Software Engineering Technology [3] yang dikatakan sebagai: The degree to which a system, component, or process meets customer or user needs or expectation. Dari sudut pandang produk, pengukuran kualitas perangkat lunak dapat menggunakan standard dari ISO 9126 atau best practice yang dikembangkan para praktisi dan pengembang perangkat lunak. Taksonomi McCall adalah best practice yang cukup terkenal dan diterima banyak pihak, ditulis oleh J.A. McCall dalam technical report yang dipublikasikan tahun 1977 [1].
- 13. Di lain pihak, dari sudut pandang proses, standard ISO 9001 dapat digunakan untuk mengukur kualitas perangkat lunak. Dan diskusi tentang ini berkembang dengan munculnya tema kajian tentang CMM (The Capability Maturity Model) yang dikembangkan di Software Engineering Institute, Carnegie Mellon University serta beberapa kajian lain seperti SPICE (Software Process Improvement and Capability dEtermination) dan BOOTSTRAP. CMM, SPICE dan BOOTSTRAP mengukur kualitas perangkat lunak dari seberapa matang proses pengembangannya. Tulisan ini akan mencoba fokus ke bagaimana mengukur perangkat lunak dilihat dari sudut pandang produk. Parameter dan metode pengukuran When you can measure what you are speaking about, and express it in numbers, you know something about it. But when you can not measure it, when you can not express it in numbers, your knowledge is of a meagre and unsatisfactory kind. (Lord Kelvin) Pendekatan engineering menginginkan bahwa kualitas perangkat lunak ini dapat diukur secara kuantitatif, dalam bentuk angka-angka yang mudah dipahami oleh manusia. Untuk itu perlu ditentukan parameter atau atribut pengukuran. Menurut taksonomi McCall, atribut tersusun secara hirarkis, dimana level atas (high-level attribute) disebut faktor (factor), dan level bawah (low-level attribute) disebut dengan kriteria (criteria). Faktor menunjukkan atribut kualitas produk dilihat dari sudut pandang pengguna. Sedangkan kriteria adalah parameter kualitas produk dilihat dari sudut pandang perangkat lunaknya sendiri. Faktor dan kriteria ini memiliki hubungan sebab akibat (cause-effect) . Tabel 1 menunjukkan daftar lengkap faktor dan kriteria dalam kualitas perangkat lunak menurut McCall. Tabel 1: Faktor dan Kriteria dalam Kualitas Perangkat Lunak
- 14. Kualitas software diukur dengan metode penjumlahan dari keseluruhan kriteria dalam suatu faktor sesuai dengan bobot (weight) yang telah ditetapkan. Rumus pengukuran yang digunakan adalah: Fa = w1c1 + w2c2 + … + wncn Dimana: Fa adalah nilai total dari faktor a wi adalah bobot untuk kriteria i ci adalah nilai untuk kriteria i Kemudian tahapan yang harus kita tempuh dalam pengukuran adalah sebagai berikut: Tahap 1: Tentukan kriteria yang digunakan untuk mengukur suatu faktor Tahap 2: Tentukan bobot (w) dari setiap kriteria (biasanya 0 <= w <= 1) Tahap 3: Tentukan skala dari nilai kriteria (misalnya, 0 <= nilai kriteria <= 10) Tahap 4: Berikan nilai pada tiap kriteria Tahap 5: Hitung nilai total dengan rumus Fa = w1c1 + w2c2 + … + wncn CONTOH PENGUKURAN PERANGKAT LUNAK Untuk mempermudah pemahaman, akan diberikan sebuah contoh pengukuran kualitas perangkat lunak dari faktor usabilitas (usability). Yang akan diukur adalah dua buah perangkat lunak yang memiliki fungsi untuk mengkontrol peralatan elektronik (electronic device). Perangkat lunak yang pertama bernama TukangKontrol, sedangkan kedua bernama Caktrol. Contoh dan hasil pengukuran dapat dilihat pada Table 2 dan 3.
- 15. Tabel 2: Contoh Pengukuran Usabilitas Dua Perangkat Lunak Tabel 3: Hasil Pengukuran Usabilitas Dua Perangkat Lunak Dari penghitungan yang ada di Tabel 3, dapat kita simpulkan bahwa dari faktor usabilitas, kualitas dari perangkat lunak bernama TukangKontrol lebih baik daripada Caktrol. Nilai total TukangKontrol untuk faktor usabilitas adalah 16.8, sedangkan Caktrol adalah 10.2 (dari maksimum total nilai 20).
- 16. DAFTAR PUSTAKA S Presman, Roger.2002.Rekayasa Perangkat Lunak Pendekatan Praktisi.Penerbit Andi:Yogyakarta Simarmata, Janner.2010.Rekayasa Perangkat Lunak.Penerbit Andi:Yogyakarta