UAS REKAYASA PERANGKAT LUNAK. Software Quality Assurance HANSI ADITYA KURNIAWAN

Transkripsi

1 UAS REKAYASA PERANGKAT LUNAK Software Quality Assurance HANSI ADITYA KURNIAWAN PROGRAM MAGISTER MANAJEMEN TEKNOLOGI INFORMASI INSTITUT TEKNOLOGI SEPULUH NOPEMBER SURABAYA 2007

2 Tujuan dari topik Software Quality Assurance (SQA) sebenarnya adalah untuk menghasilkan suatu produk perangkat lunak (software) yang berkualitas tinggi. SQA merupakan salah satu aktivitas yang harus dijalani dalam suatu proses pengembangan software seperti dapat terlihat pada Gambar 1.1. Common process framework Framework activities Task Sets Tasks Milestones, Deliverables SQA Points Umbrella activities Gambar 1.1 Proses Pengembangan Software SQA meliputi beberapa konsep sebagai berikut: 1. Pendekatan kualitas manajemen, 2. Teknologi rekayasa perangkat lunak yang efektif (metode dan tools yang digunakan), 3. Tinjauan teknis secara formal yang diaplikasikan melalui proses pengembangan software, 4. Strategi uji coba software yang multitier, 5. Kontrol terhadap dokumentasi software dan perubahannya, 6. Prosedur untuk memastikan pemenuhan standar pengembangan software, jika software tersebut diaplikasikan, dan 7. Mekanisme pengukuran dan laporan.

3 KONSEP KUALITAS Kontrol terhadap kualitas yang umum digunakan adalah kontrol terhadap variasi. Maksudnya adalah meminimalkan variasi terhadap sesuatu sehingga kualitas suatu produk dapat terjaga. Hal ini berlaku juga pada pengembangan software. Dari satu proyek pengembangan software ke proyek lainnya, maka sedapat mungkin diminimalkan perbedaan antara sumber daya yang diperkirakan dengan sumber daya yang sesungguhnya digunakan dalam proyek seperti staf, peralatan, waktu, dan sebagainya. Selain itu, pada umumnya, kontrol kualitas ini berlaku juga pada uji coba software dari versi satu ke pengembangan versi berikutnya. Tidak hanya meminimalkan kesalahan (bugs / errors) dari sebuah versi, akan tetapi juga harus dapat menurunkan kesalahan ketika mengembangkan versi berikutnya. Hal yang lain berhubungan dengan kontrol terhadap kualitas suatu software dapat terlihat pada minimalisasi terhadap perbedaan kecepatan dan akurasi dari respon dukungan masalah yang dialami customer. Kualitas Kualitas suatu software dapat diukur melalui karakteristiknya, seperti kompleksitas, kohesi, jumlah function points (FP), jumlah kode baris (lines of codes (LOC)), dan masih banyak lagi. Ketika dilakukan pengukuran terhadap karakteristik-karakteristik tersebut, maka akan muncul 2 jenis kualitas yaitu sebagai berikut: Quality of design Kualitas ini sangat erat hubungannya dengan desain dari suatu produk software. Tingkat material, toleransi, dan performa suatu spesifikasi berkontribusi besar kepada kualitas. Selama semakin tinggi tingkat material yang digunakan, semakin ketat toleransinya, dan semakin tinggi performa level yang dispesifikasikan, maka kualitas software semakin meningkat, jika produk tersebut sesuai spesifikasi pembuatannya. Dalam pengembangan software, hal ini meliputi kebutuhan user, spesifikasi, dan desain sistem.

4 Quality of conformance Kualitas ini sangat erat hubungannya dengan tingkat spesifikasi desain yang digunakan selama pembuatan software. Semakin tinggi tingkat spesifikasinya, maka semakin tinggi pula kualitasnya. Dalam pengembangan software, hal ini fokus pada implementasi. Jika implementasi software mengikuti desain, dan hasilnya memenuhi kebutuhan user serta mencapai tujuan, maka kualitas software tersebut semakin tinggi. Akan tetapi, tidak hanya kedua jenis kualitas tersebut yang harus diperhatikan oleh para software engineers. Menurut Robert Glass, lebih dari sekedar itu, yaitu: User satisfaction = compliant product + good quality + delivery within budget and schedule Menurut Glass, yang terpenting adalah kepuasan user, lebih dari hanya sekedar kualitas yang bagus. Kualitas bagus tetapi user tidak puas, maka semuanya sia-sia. Kontrol Kualitas Kontrol kualitas dilakukan dengan inspeksi, review, dan pengujian untuk memastikan suatu produk telah memenuhi kebutuhan yang diinginkan. Kontrol kualitas termasuk feedback, yang berjalan terus menerus dalam proses menciptakan suatu produk. Kombinasi dari pengukuran dan feedback dapat membantu menghindarkan kegagalan proses untuk memenuhi kebutuhan. Aktivitas pada kontrol kualitas dapat dilakukan secara otomatis, manual, atau kombinasi dari keduanya. Jaminan Kualitas Jaminan kualitas terdiri dari proses audit dan melaporkan fungsi dari manajemen. Tujuannya adalah untuk menyediakan data yang diperlukan kepada manajemen tentang kualitas produk dan menunjukkan bahwa produk tersebut sudah memenuhi kebutuhan yang ingin dicapai.

5 Biaya Kualitas Studi tentang biaya kualitas menyediakan dasar dari biaya kualitas itu sendiri, mengidentifikasi peluang untuk mengurangi biaya kualitas, dan menyediakan normalisasi perbandingan. Biaya kualitas dapat dibagi menjadi beberapa biaya yang berkaitan dengan pencegahan, penilaian, dan kegagalan. Yang termasuk biaya pencegahan adalah: Perencanaan kualitas Review teknis formal Perlengkapan pengujian Pelatihan Yang termasuk biaya penilaian adalah aktivitas untuk mendapatkan informasi tentang kondisi produk dari setiap proses. Contohnya adalah: Inspeksi proses dan antar-proses Pengujian dan perawatan peralatan Pengujian Biaya kegagalan adalah biaya yang akan dihilangkan ketika tidak ada kerusakan produk saat diberikan ke konsumen. Biaya kegagalan dibagi menjadi 2 yaitu biaya kegagalan internal dan eksternal. Biaya kegagalan internal muncul ketika produk diberikan kepada konsumen. Yang termasuk dalam biaya kegagalan internal adalah: Pengerjaan ulang Perbaikan Analisis kegagalan Biaya kegagalan eksternal berkaitan dengan kerusakan produk setelah produk tersebut sudah sampai kepada konsumen. Contoh dari biaya kegagalan eksternal adalah:

6 Adanya komplain konsumen Pengembalian dan penggantian produk Dukungan bantuan Jaminan SOFTWARE QUALITY ASSURANCE Banyak literatur yang mengungkapkan definisi dari kualitas software. Salah satunya, kualitas software didefinisikan sebagai pemenuhan kebutuhan fungsional dan performansi, yang secara eksplisit didokumentasikan sesuai standar yang ada, serta secara implisit merupakan pemenuhan harapan dari para pengembang software. Latar Belakang Seperti sudah disinggung sedikit di atas, jaminan kualitas adalah suatu aktivitas tambahan dari semua bisnis yang menghasilkan produk untuk digunakan oleh orang lain, yang sudah menjadi tanggung jawab dari pembuat produk tersebut. Pada jaman sekarang ini, setiap perusahaan mempunyai mekanisme masing-masing untuk menjamin kualitas dari produk tersebut, dimana hal ini sudah menjadi kepedulian dari perusahaan. Sejarah dari SQA berkembang secara paralel dengan sejarah dari kualitas hardware. SQA diperkenalkan pertama kali pada saat kontrak pembuatan software di bidang militer pada tahun 1970an, dimana kemudian berkembang ke dunia komersial. Sebelumnya pada tahun 1950an dan 1960an, jaminan kualitas suatu software merupakan tanggung jawab tunggal dari seorang programmer. Akan tetapi, sekarang jaminan kualitas software sudah menjadi tanggung jawab beberapa pihak, seperti software engineer, manajer proyek software, konsumen, produsen, distributor, dan masing-masing individu yang terkait dengan produk tersebut.

7 Aktivitas SQA SQA mengandung bermacam-macam tugas yang berhubungan dengan konstituensi yang berbeda, dimana para pembuat software akan mengerjakan pekerjaan-pekerjaan teknikal sedangkan grup SQA mempunyai tanggung jawab untuk merencanakan penilaian kualitas software, pencatatan, analisis, dan pembuatan laporan atas kualitas software yang telah dibuat. Dari sini, kualitas para pembuat software dapat dinilai melalui ukuran-ukuran dan metode-metode tertentu, serta melalui pengujian-pengujian software. Oleh karena itu, para pembuat software diharapkan dapat membuat suatu produk software yang berkualitas tinggi. Berikut adalah aktivitas-aktivitas SQA: Mempersiapkan perencanaan SQA untuk sebuah proyek. Berpartisipasi dalam pengembangan sebuah deskripsi proyek software. Meninjau aktivitas pembuatan software untuk memverifikasi pemenuhan kebutuhan software yang telah didefinisikan sebelumnya. Melakukan audit terhadap produk software untuk memverifikasi pemenuhan kebutuhan software yang telah didefinisikan sebelumnya. Memastikan deviasi dari pengerjaan software dan produknya didokumentasikan sesuai format yang ditentukan. Mencatat adanya ketidaksesuaian dan masalah yang terjadi untuk dilaporkan ke manajemen senior. Berikut akan dijelaskan satu studi kasus tentang SQA yang digunakan di Departemen Pertahanan Energi Nuklir. Departemen ini merasa adanya masalah yang terjadi dan dibutuhkan suatu SQA untuk melakukan audit dan analisis terhadap masalah tersebut. Tools yang digunakan di studi kasus ini adalah Integrated Safety Management (IST).

8 STUDI KASUS SOFTWARE QUALITY ASSURANCE (SQA) YANG BERKAITAN DENGAN KEAMANAN DI DEPARTEMEN PERTAHANAN ENERGI NUKLIR Pendahuluan Departemen Energi dan kontraktornya melakukan pekerjaan berbahaya yang diperlukan untuk keamanan negara dan memperbaiki lingkungan di fasilitas produksi energi pertahanan nuklir. Performa dari pekerjaan ini yang paling penting adalah perlindungan keselamatan bagi publik, pekerja, dan lingkungan itu sendiri. Kunci dan tools yang digunakan untuk mencapai tujuan tersebut adalah Integrated Safety Management (ISM), yaitu suatu sistem yang didesain untuk menjamin syarat suatu keamanan yang terintegrasi dengan perencanaan dan eksekusi suatu pekerjaan. Fungsi dari ISM adalah melakukan analisis tingkat bahaya yang muncul dari pekerjaan tersebut dan mengidentifikasi kontrol tindakan pencegahannya. Tujuan dari software quality assurance (SQA) di sini adalah untuk memastikan bahwa software yang dibuat dapat memenuhi syarat yang disebutkan di ISM. Kode-kode komputer dan model-model serta data yang berhubungan merupakan data yang penting untuk digunakan. Semuanya itu digunakan sebagai pendekatan untuk menentukan SQA ketika software tersebut diimplementasikan. SQA menyediakan ukuran yang didesain untuk memastikan suatu software berjalan sesuai fungsinya secara konsisten dan modifikasi terhadap software tersebut tidak menghasilkan suatu masalah yang besar. Ukuran tersebut harus dipakai sepanjang pengembangan software secara sistematik, mulai testing, dokumentasi, sampai eksekusi suatu software, dan saat pemeliharaan software. Adanya pengarahan yang tidak jelas terhadap standar dan kebutuhan dari SQA dan penggunaannya memunculkan bahaya yang harus segera dianalisis. Dari sini, beberapa aspek ISM yang dapat digunakan sebagai tools SQA adalah sebagai berikut:

9 Definisi dan batasan kerja harus diprioritaskan sebagai basis yang signifikan untuk keamanan, dimana sering diputuskan dengan menggunakan bantuan tools software. Analisis terhadap bahaya membutuhkan kode berkualitas tinggi untuk estimasi kepentingan dan konsekuensi akan potensi terjadinya kecelakaan. Identifikasi terhadap kontrol membutuhkan kode berkualitas tinggi untuk diputuskan terhadap kontrol administrasi dan signifikasi terhadap sistem, struktur, dan komponen akan adanya keamanan. Tingkah laku kerja yang aman membutuhkan konfidensi yang tinggi dimana software komputer yaitu Software Instrumentation and Control (I&C) akan beroperasi lebih tangguh. Status SQA Sekarang Software di Departemen Pertahanan Energi Nuklir Suatu integrasi dan infrastruktur yang efektif untuk implementasi SQA belum ada di Departemen Pertahanan Energi Nuklir. Suatu infrastruktur yang efektif termasuk riset yang sedang berjalan dan pengembangan dari kode-kode program, program kontrol konfigurasi kode, pelatihan yang terstandar, dan petunjuk dari kode-kode program tersebut. Dengan hal-hal ini, yang ditunjang dengan elemen-elemen lainnya dapat diintegrasikan menjadi suatu infrastruktur yang dapat memperbaiki masalah SQA di Departemen tersebut. Berikut adalah fokus detail yang dilakukan: Kode-kode untuk analisis masalah Kode-kode tersebut digunakan untuk menghitung adanya konsekuensi terjadinya masalah untuk mendukung identifikasi dan klasifikasi kontrol serta analisis bahaya. Software Instrumentation and Control (I&C) Software ini digunakan untuk kontrol terhadap kinerja serta menyediakan informasi tentang status proses atau sistem secara fisik.

10 Perbedaan (Gap) Infratruktur di Departemen Pertahanan Energi Nuklir Sumber masalah yang dialami Departemen ini adalah tidak adanya infrastruktur yang efektif untuk melakukan SQA. Fungsi umum dari SQA sudah didefinisikan, akan tetapi tidak dijalankan secara efektif secara teknikal. Selain itu tidak ada panduan dan training terhadap penggunaan kode-kode yang ada di Departemen tersebut. Berikut adalah tindakan-tindakan yang dapat digunakan untuk mengembangkan SQA menjadi lebih baik: Cari keuntungan dari penemuan Accident Phenomenology and Consequence (APAC). APAC adalah suatu metodologi program yang dibuat pada tahun 1994 yang digunakan untuk memastikan penggunaan kode-kode untuk analisis keselamatan dan dapat digunakan untuk pengembangan kode-kode di masa mendatang. Tanggung jawab SQA terhadap hal ini adalah: - Performa verifikasi dan validasi setelah pengembangan kode analisis masalah. - Perawatan dan distribusi dari kode analisis masalah. - Identifikasi lingkup analisis masalah dimana kode yang sekarang tidak ada dan tidak sesuai, sehingga dibutuhkan teknik dan tools. - Pengarahan dari riset dan pengembangan yang sesuai dan fokus pada pengembangan kode baru untuk memenuhi kebutuhan lingkup analisis masalah yang sudah didefinisikan sebelumnya dan menjamin SQA diintegrasikan ke dalamnya. Mengintegrasikan semua usaha dan program Departemen yang terkait dengan SQA, seperti usaha untuk memperoleh efek yang produktif dan realisasi yang kompleks. Berikut adalah pengukuran yang dapat dilakukan: - Pengembangan atau identifikasi dari standar verifikasi dan validasi, serta menyetujui kriteria yang wajar di dalam penggunaannya. - Memindahkan putusan kepada Departemen untuk memilih standar SQA yang akan digunakan di dalam operasinya. Termasuk di dalamnya adalah dengan menggunakan sistem software I&C.

11 Kesimpulan Karena di Departemen Pertahanan Energi Nuklir masih belum ada SQA yang dijalankan, maka diharapkan Departmen dapat melakukan SQA dengan menggunakan tools ISM. Untuk menerapkan hal tersebut, maka pihak Departemen membutuhkan hal-hal sebagai berikut: Membuat standar di Departemen untuk secara praktis diterapkan di SQA. Mengidentifikasi semua elemen organisasi yang seharusnya terlibat peda pembuatan, pengujian, dokumentasi, perawatan, serta eksekusi software. Menyediakan dana yang cukup untuk menjalankan SQA. Menediakan manajemen proyek yang fokus dan terintegrasi untuk menjalankan SQA.

12 LAMPIRAN Berikut adalah lampiran beberapa hasil yang didapatkan dari program APAC. Tabel-tabel tersebut diambil dari informasi pembuat kode, organisasi, dan status SQA dari kode. Pada bagian kolom Status SQA/V&V merupakan status dari SQA yang ada di Departemen hasil dari analisa APAC pada Departemen tersebut.

13

14 Keterangan: Code adalah kode yang menjalankan suatu fungsi tertentu, sebagai contoh adalah MACCS2 (MELCOR Accident Consequence Code System 2) adalah suatu kode yang digunakan untuk menghitung kesehatan dan konsekuensi ekonomi ketika ada kecelakaan akibat radioaktif. Code Developer / Sponsor adalah pembuat kode atau sponsor dari pembuat kode Current Owner / Technical Support adalah pemilik dari pembuat kode. Status Of SQA/V&V adalah status dari SQA suatu kode General Comments adalah komentar dari internal Departemen

15 DAFTAR PUSTAKA Defense Nuclear Facility Safety Board (2000), Quality Assurance For Safety- Related Software At Department Of Energy Defense Nuclear Facility, Technical Report Pressman, R. (2005), Software Engineering : A Practitioner Approach, McGraw- Hill