Belajar Komputer

Belajar komputer itu mudah dan gratis

Software Quality Management


References :

  • Daniel Galin, Software Quality Assurance: from Theory to Implementation, Pearson Addison Wesley, 2004
  • G. Gordon Schulmeyer, et al., The Handbook of Software Quality Assurance, 3rd Edition, Prentice Hall, New Jersey, 1999
  • Frank P. Ginac, Customer Oriented Software Quality Assurance, Prentice Hall PTR, 1997
  • IEEE Standard on SQA, 1998

Objectives :

  • Membentuk dan menumbuhkan pengetahuan mengenai semua komponen dan atribut kualitas perangkat lunak, kemampuan menerapkan metode dan tools yang dibutuhkan sehingga pemahaman yang dimiliki dapat digunakan untuk meningkatkan kualitas perangkat lunak
  • Pada akhir kuliah, mahasiswa diharapkan mampu mengelola dan mengukur perangkat lunak dari sisi kualitasnya

Materials :

  • Prinsip dan Konsep Kualitas Perangkat Lunak
  • Metriks dan Komponen Kualitas Perangkat Lunak (1)
  • Metriks dan Komponen Kualitas Perangkat Lunak (2)
  • Komponen Software Quality Assurance (SQA) dalam Daur Hidup Proyek
  • Pengujian, Validasi, dan Verifikasi Perangkat Lunak

Evolusi perangkat lunak (PL) :

Pengembangan PL : requirements, specifications, design, coding, testing, inspection

  • Requirements : kebutuhan dari user
  • Specifications : analisis apa saja kebutuhan user
  • Design : buat model data dan model proses
  • Coding : coding desain
  • Testing : untuk menguji kelayakan PL, ada error atau tidak
  • Inspection : maintenance

Perawatan PL : proses memperpanjang waktu pakai PL

Migrasi PL : proses perpindahan PL ke setting yang baru

Evolusi PL harus bisa :

  • Memenuhi requirement yang baru, contoh : menyediakan user interface yang berbasis web
  • Mengurangi kompleksitas, biaya mendatang dan waktu ke pasaran
  • Menggunakan bahasa yang modern
  • Mengurangi defect : menyediakan violation standar coding

Definisi Perangkat Lunak :

Menurut Pressman

  • Instruksi atau program komputer yang ketika dijalankan menyediakan fungsi dan performanceyang diinginkan dan
  • Struktur data yang memungkinkan program memanipulasi informasi dan
  • Dokumen yang menggambarkan cara menggunakan dan mengoperasikan program tersebut

Menurut IEEE & ISO 1997

  • Program komputer (code)
  • Prosedur
  • Dokumentasi
  • Data yang diperlukan untuk mengoperasikan sistem PL

Dalam perspektif Software Quality Assurance (SQA) / Jaminan Kualitas PL

Perangkat Lunak adalah gabungan program komputer (code), prosedur, dokumentasi dan data yang diperlukan untuk mengoperasikan sistem PL

  • Kombinasi keempat komponen ini diperlukan untuk menjamin kualitas proses pengembangan PL sebagus kepastian perawatan dalam jangka panjang.

Kesalahan Perangkat Lunak :

Software error : bagian code yang sebagiannya atau keseluruhannya salah, yang diakibatkan oleh kesalahan gramatical, logical, atau kesalahan lain yang dibuat oleh analis sistem, programmer atau anggota lain yang terlibat dalam tim pengembangan PL

Software defect : bagian PL yang tidak memenuhi dokumentasi pengembangan PL

Software fault : software error yang menyebabkan kesalahan fungsional

Software failure : kesalahan PL yang terjadi ketika user meminta bagian PL yang fault. Sumbersoftware failure adalah software error.

Definisi kualitas Perangkat Lunak :

Menurut IEEE

  • Derajat sistem, komponen, atau proses yang sesuai dengan spesifikasi atau
  • Derajat sistem, komponen, atau proses yang memenuhi kebutuhan customer atau ekspektasinya

Menurut Pressman

  • Kesesuaian kebutuhan fungsional dan performance, adanya dokumentasi standar, dan memiliki sifat yang diharapkan oleh semua profesional pengembang PL

 

Definisi SQA :

Menurut IEEE

  • Pola yang terencana dan sistematis dari semua tindakan yang diperlukan untuk menyediakan kepercayaan yang cukup terhadap suatu item atau produk disesuaikan ke kebutuhan teknis

Kumpulan aktivitas yang didesain untuk mengevaluasi proses di mana produk dihasilkan

Definisi lanjut

  • Kumpulan aktivitas yang sistematis dan terencana untuk menyediakan proses pembangunan PL atau proses perawatan dari produk sistem PL yang memenuhi kebutuhan teknis fungsional, seperti halnya dengan kebutuhan managerial untuk memelihara jadwal dan operasi dalam anggaran yang terbatas

 

Tujuan SQA :

Software development (process-oriented)

  • Menjamin suatu level penerimaan bahwa PL sesuai dengan requirement fungsional
  • Menjamin suatu level penerimaan bahwa PL sesuai dengan jadwal managerial dan kebutuhan biaya
  • Menginisialisasi dan mengatur aktivitas perbaikan dan peningkatan efisiensi pengembangan PL dan aktivitas SQA

Software maintenance (product oriented)

  • Menjamin dengan level penerimaan bahwa aktivitas perawatan PL akan sesuai dengan kebutuhan fungsional
  • Menjamin dengan level penerimaan bahwa aktivitas perawatan PL akan sesuai dengan jadwal dan kebutuhan biaya
  • Menginisialisasi dan mengatur aktivitas perbaikan dan peningkatan efisiensi perawatan PL dan aktivitas SQA

 

Alasan memperhatikan kualitas PL : karena kualitas adalah :

· Masalah persaingan

· Penting supaya dapat survive

· Penting untuk global marketing

· Mengefektifkan biaya

· Mempertahankan customer dan meningkatkan keuntungan

Reaksi berantai Deming

clip_image001

Kualitas produk adalah :

· Kesesuaian dengan kebutuhan

· Kelayakan untuk digunakan

· Bebas dari error dan failure

· Kepuasan customer

Parameter kualitas PL :

  • Parameter teknis (objektif) : solusi teknis

Correctness : ukuran tingkat defect

Reliability : ukuran failure

Capability : ukuran requirement coverage

Performance : ukuran kecepatan dan penggunaan sumber daya

Maintainability : ukuran change log

  • Parameter user (subjektif) : solusi non teknis

Usability : berapa % user senang dengan interface dan kemudahan penggunaan

Installability : jumlah masalah instalasi yang dilaporan per instalasi

Documentation : berapa % user senang dengan dokumentasi

Availability : berapa % user melaporkan masalah akses

 

Prinsip-prinsip dasar :

  • Pencapaian kualitas : tidak terjadi karena kebetulan, harus direncanakan sejak awal dan dimonitor setiap hari
  • Tiga prinsip dasar :

– Mengetahui apa yang sebaiknya dilakukan

– Apa yang sedang dilakukan

– Bagaimana mengukur perbedaan

Dukungan kualitas meliputi :

· Dokumentasi user

· Package dan penyusunan distribusi

· Training

· Help desk assistance

· Error reporting and correction

· Perbaikan

 

Beberapa model faktor kualitas perangkat lunak (PL) :

· Model klasik (Mc Call) : 11 faktor kualitas

· Model Deutsch dan Willis : 12 – 15 faktor kualitas

· Model Evans dan Marciniak

 

Model Mc Call, 11 faktor kualitas PL dikelompokkan menjadi tiga kategori :

  • Faktor operasi produk

Correctness : daftar sistem PL yang memberikan output yang benar sesuai dengan spesifikasi kebutuhan PL

Reliability : maksimum terjadi failure yang dibolehkan

Efficiency : berhubungan dengan sumber daya hardware untuk
melakukan semua fungsi sistem PL dalam melayani kebutuhan

Integrity : berhubungan dengan security sistem, pencegahan akses untuk orang-orang yang tidak berhak, pembedaan user yang dapat melakukan create, read, update, delete (CRUD)

Usability : berhubungan dengan sumber daya pegawai yang diperlukan untuk melatih pegawai baru dan mengoperasikan sistem PL

  • Faktor revisi produk

Maintainability : mendefinisikan usaha yang diperlukan user dan personil perawatan untuk mengidentifikasi alasan software failure dan membuktikan keberhasilan perbaikan

Flexibility : kemampuan dan usaha yang diperlukan untuk mendukung aktivitas adaptive maintenance

Testability : berhubungan dengan testing

  • Faktor transisi produk

Portability : adaptasi sistem PL dengan lingkungan lain yang mencakup perbedaan hardware, sistem operasi, dll

Reusability : berhubungan dengan penggunaan modul asli PL yang didesain untuk project baru yang dibangun

Interoperability : fokus pada pembuatan interface dengan sistem PL lain atau dengan peralatan perusahaan lain

Jenis-jenis maintenance PL :

· Corrective maintenance : koreksi error-error yang muncul pada saat PL mulai digunakan

· Adaptive maintenance : adaptasi terhadap perubahan-perubahan, new release, tidak merubah fungsi atau unjuk kerja

· Perfective maintenance : PL masih OK, tapi dibutuhkan fungsi-fungsi / fitur-fitur baru

· Preventive maintenance : reverse engineering dan re-engineering

Komponen SQA :

· Pre-proyek

· Daur hidup proyek PL

· Pencegahan kesalahan infrastruktur dan perbaikannya

· Manajemen Kualitas Perangkat Lunak (MKPL)

· Standarisasi, sertifikasi, dan penilaian SQA

· Manajemen SQA -> komponen manusia

Pre-proyek

  • Review kontrak

– Klarifikasi kebutuhan pengguna

– Review jadwal proyek dan menaksir kebutuhan sumber daya

– Evaluasi kapasitas staf yang profesional untuk menyelesaikan proyek

– Evaluasi kapasitas pelanggan untuk memenuhi kewajibannya

– Evaluasi risiko pengembangan

  • Rencana pengembangan

– Jadwal

– Kebutuhan manpower dan sumber daya hardware

– Evaluasi risiko

– Organisasi issue : anggota tim, sub kontraktor, dan partnership

  • Rencana kualitas

– Tujuan kualitas dalam lingkup yang terukur

– Kriteria untuk memulai dan mengakhiri setiap tahap proyek

– List review, tes, verifikasi dan validasi

Daur hidup proyek PL :

· Review

· Pendapat ahli

· Pengujian PL

· Perawatan PL

· Jaminan kualitas sub kontraktor dan kesediaan pengguna

Pencegahan kesalahan infrastruktur dan perbaikannya :

· Prosedur dan petunjuk kerja

· Template dan checklist

· Training staf, training ulang, dan sertifikasi

· Langkah preventif dan korektif

· Manajemen konfigurasi

· Kontrol dokumentasi

Manajemen Kualitas Perangkat Lunak (MKPL) :

  • Kontrol progress proyek

– Penggunaan sumber daya

– Jadwal

– Manajemen risiko

– Anggaran

  • Metrik kualitas PL

– Aktivitas pengembangan dan perawatan kualitas PL

– Produktivitas tim pengembangan

– Help desk dan produktivitas tim perawatan

– Fault density PL

– Perbedaan jadwal

  • Biaya kualitas PL

Standarisasi, sertifikasi, dan penilaian SQA :

  • Tujuan :

– Penggunaan pengetahuan profesional internasional

– Perbaikan koordinasi dengan kualitas sistem organisasi lain

– Evaluasi profesional dan pengukuran pencapaian kualitas sistem organisasi

  • Standar manajemen kualitas : ISO 9001 & ISO 9000-3
  • Standar proses proyek : IEEE 1012 & ISO / IEC 12207

Manajemen SQA -> komponen manusia

  • Definisi kebijakan kualitas
  • Tindak lanjut efektif pelaksanaan kebijakan kualitas
  • Alokasi kecukupan sumber daya untuk melaksanakan kebijakan kualitas
  • Penugasan staf yang mampu
  • Meninjak lanjuti pemenuhan prosedur manajemen kualitas
  • Penyelesaian jadwal, anggaran, dan hubungan pelanggan yang sulit

Tahapan dan proses kontrak review

– Tahap 1 : review draft proposal untuk pelanggan (proposal draft review)

– Tahap 2 : review draft proposal sebelum ditandatangani (contract draft review)

Tujuan review kontrak :

  • Tujuan review draft proposal

– Klarifikasi dan dokumentasi kebutuhan pengguna

– Pendekatan alternatif untuk menyelesaikan proyek telah diuji

– Aspek formal hubungan pelanggan dan perusahaan pengembang perangkat lunak (PL) ditentukan

– Identifikasi pembangunan risiko

– Penilaian sumber daya proyek dan jadwal telah cukup disiapkan

– Pengujian kapasitas perusahaan berkenaan dengan proyek

– Pengujian kapasitas pelanggan untuk memenuhi komitmennya

– Definisi partner dan kondisi-kondisi keikutsertaan sub kontraktor

– Definisi dan perlindungan hak kepemilikan

  • Tujuan review draft kontrak

– Tidak ada isu yang tidak diperjelas di draft kontrak

– Semua pengertian yang disepakati di proposal didokumentasikan

– Tidak ada perubahan baru, tambahan atau pengurangan yang dimasukkan ke draft kontrak

Pelaksanaan review kontrak :

  • Faktor yang mempengaruhi tingkat tinjauan review kontrak

– Proyek penting atau besar, selalu mengukur sumber daya man-month

– Kompleksitas teknikal proyek

– Derajat tingkat pengetahuan staf dan pengalaman lingkup proyek

– Kompleksitas organisasi proyek

  • Siapa yang melakukan kontrak review

– Pimpinan atau anggota lain dalam tim proyek

– Anggota tim proposal

– Profesional luar atau staf perusahaan yang tidak menjadi anggota tim proposal

– Anggota ahli dari luar

  • Pelaksanaan kontrak review untuk proposal utama

– Review kontrak seharusnya dijadwalkan

– Tim seharusnya membawa review kontrak

– Pimpinan tim kontrak review seharusnya ditetapkan

Review kontrak untuk proyek internal :

· Suatu proposal cukup untuk proyek internal

· Menggunakan proses review kontrak yang tepat untuk proyek internal

· Kesepakatan yang sesuai antara pelanggan internal dan supplier internal

Rencana kualitas dan pengembangannya :

  • Tujuan rencana kualitas dan pengembangannya :

– Jadwal aktivitas pengembangan akan mendorong ke arah penyelesaian yg tepat waktu, kesuksesan proyek, perkiraan anggaran, & sumber daya tenaga kerja yg diperlukan

– Merekrut anggota dan mengalokasikan sumber daya pengembangan

– Penyelesaian risiko pengembangan

– Penerapan aktivitas SQA

– Penyediaan manajemen dengan data yang diperlukan untuk kendali proyek

  • Elemen rencana pengembangan
  • Produk proyek, mencakup produk-produk :

– Dokumen perancangan, menetapkan waktu penyelesaian, mengindikasikan materi yang dikirim ke pelanggan

– Training, menentukan tanggal, peserta, dan tempat

  • Interface proyek

– Interface dengan package PL yang ada

– Interface dengan PL lain atau tim pengembangan hardware yang bekerja pada sistem atau proyek yang sama

– Interface dengan hardware yang ada

  • Metodologi proyek dan tools pengembangan yang dimasukkan ke setiap fase proyek
  • Standar dan prosedur pengembangan PL
  • Pemetaan proses pengembangan

– Perkiraan lamanya aktivitas

– Rangkaian logis pada setiap aktivitas yang dilakukan

– Jenis sumber daya profesional yang dibutuhkan dan perkiraan berapa banyak sumber daya yang diperlukan untuk setiap aktivitas

  • Milestone proyek
  • Pengaturan staf proyek

– Struktur organisasi : definisi anggota tim dan pekerjaan, terdiri dari sub kontraktor, pekerja sementara

– Kebutuhan profesional : sertifikasi, pengalaman dalam bahasa pemrograman tertentu atautools pengembangan

– Jumlah orang yang dibutuhkan untuk setiap periode waktu

– Nama pimpinan dan anggota tim

  • Fasilitas pengembangan
  • Risiko pengembangan

– Gap teknologi

– Kekurangan staf

– Ketergantungan elemen organisasi

  • Metode pengendalian
  • Perkiraan biaya proyek

Elemen rencana kualitas

  • Daftar tujuan kualitas
  • Aktivitas review :

Lingkup, jenis, dan jadwal aktivitas review

Prosedur khusus yang ditambahkan

Siapa yang bertanggung jawab melaksanakan aktivitas review

  • Rencana pengujian PL

Pengujian unit, integrasi, atau keseluruhan sistem

Jenis aktivitas pengujian yang dipakai, termasuk spesifikasi PL yang diuji

Jadwal rencana pengujian

Prosedur khusus yang ditambahkan

Siapa yang bertanggung jawab melaksanakan pengujian

  • Test penerimaan
  • Prosedur dan tools manajemen konfigurasi

Rencana kualitas dan pengembangan untuk proyek kecil dan internal

  • Rencana pengembangan
  • Produk proyek (indikasi -> setoran)
  • Benchmark proyek
  • Pengembangan risiko
  • Perkiraan anggaran proyek
  • Tujuan kualitas

 

Komponen Software Quality Assurance (SQA) :

· Pre-proyek

· Penilaian aktivitas daur hidup proyek

· Pencegahan dan perbaikan infrastruktur proyek

· Manajemen Kualitas Perangkat Lunak (MKPL)

· Standarisasi, sertifikasi, dan penilaian dalam sistem SQA

· Organisasi SQA -> komponen manusia

Pre-proyek menjamin atas :

· Komitmen bahwa proyek sesuai dengan sumber daya, jadwal, dan anggaran yang telah ditentukan

· Pembangunan dan rencana kualitas telah ditentukan dengan benar

Pre-proyek terdiri dari :

Kontrak review

  • Klarifikasi kebutuhan pelanggan
  • Review jadwal proyek dan perkiraan kebutuhan sumber daya
  • Evaluasi kemampuan staf profesional untuk melaksanakan proyek
  • Evaluasi kemampuan pelanggan untuk memenuhi kewajibannya

Pembangunan dan rencana kualitas

  • Jadwal
  • Kebutuhan manpower dan sumber daya hardware
  • Evaluasi risiko
  • Persoalan organisasi : anggota tim, sub kontraktor, dan rekanan
  • Metodologi proyek, tools pengembangan, dll
  • Rencana penggunaan ulang perangkat lunak (PL)
  • Penilaian aktivitas daur hidup proyek ada dua tahap, yaitu :

Tahap siklus hidup pengembangan : mendeteksi kesalahan desain dan programming

  • Review
  • Pendapat ahli
  • Pengujian PL
  • Jaminan kualitas untuk pekerjaan sub kontraktor dan kesediaan pelanggan

Tahap operasi maintenance

– Corrective maintenance

– Adaptive maintenance

– Functionality improvement maintenance

  • Komponen pre-maintenance :

– Maintenance kontrak review

– Rencana maintenance

  • Komponen infrastruktur SQA :

– Prosedur maintenance dan instruksi

– Dukungan perlengkapan kualitas

– Maintenance pelatihan staf, pelatihan ulang, dan sertifikasi

– Tindakan preventive dan corrective maintenance

– Manajemen konfigurasi

– Kontrol dokumentasi maintenance dan laporan kualitas

  • Kontrol manajerial komponen SQA :

– Kontrol maintenance servis

– Metriks maintenance kualitas

– Biaya maintenance kualitas

Pencegahan dan perbaikan infrastruktur proyek :

  • Tujuan utama : untuk melenyapkan atau mengurangi error yang didasarkan atas pengalaman SQA organisasi
  • Mencakup :

– Prosedur dan instruksi pekerjaan

– Template dan checklist

– Pelatihan staf, pelatihan ulang, dan sertifikasi

– Tindakan pencegahan dan perbaikan

– Kontrol dokumentasi

Manajemen Kualitas Perangkat Lunak (MKPL) :

  • Merupakan pelengkap dari beberapa tujuan, salah satunya adalah mengontrol aktivitas pembangunan dan perawatan serta memperkenalkan lebih awal dukungan manajerial untuk mencegah atau meminimalisir kegagalan jadwal dan anggaran serta akibatnya
  • Terdiri dari :

Kontrol progress proyek (mencakup kontrol kontrak maintenance)

– Penggunaan sumber daya

– Jadwal

– Aktivitas manajemen risiko

– Anggaran

Metriks kualitas PL

– Kualitas pembangunan PL dan aktivitas maintenance

– Pembentukan kelompok produktivitas

– Help desk dan maintenance tim produktivitas

– Tingkat kegagalan PL

– Selisih jadwal

Biaya kualitas PL

Standarisasi, sertifikasi, dan penilaian sistem SQA :

  • Tujuan :
    • Pengetahuan profesional internasional
    • Perbaikan koordinasi kualitas sistem organisasi dengan organisasi lain yang sejenis
    • Penilaian pencapaian kualitas sistem sesuai dengan skala umum

Standar yang digunakan :

– Standar manajemen kualitas : SEI CMM, ISO 9001, dan ISO 9000-3

– Standar proses proyek : IEEE 1012, ISO / IEC 12207

Organisasi SQA -> komponen manusia :

  • Memiliki aktor-aktor :

– Manajer

– Personal pengujian

– Unit dan praktisi SQA yang tertarik pada kualitas PL

  • Tujuan utama :

– Memulai dan mendukung pelaksanaan komponen SQA

– Mendeteksi deviasi dari prosedur SQA dan metodologi

– Mengusulkan perbaikan komponen SQA

Peran manajemen dalam SQA :

· Mendefinisikan kebijakan dalam kualitas

· Secara efektif menindaklanjuti pelaksanaan kebijakan kualitas

· Alokasi kecukupan sumber daya untuk melaksanakan kebijakan kualitas

· Menugaskan staf yang mampu

· Menindaklanjuti pemenuhan prosedur jaminan kualitas

· Penyelesaian jadwal, anggaran, dan kesulitan hubungan dengan pelanggan

Unit SQA :

· Menyiapkan laporan program kualitas

· Konsultasi dengan staf dan ahli dari luar dalam permasalahan kualitas PL

· Memimpin internal audit jaminan kualitas

· Kepemimpinan dari panitia jaminan kualitas

· Mendukung komponen infrastruktur jaminan kualitas yang ada dan memperbaruinya serta membangun komponen baru

Pengawas, panitia, dan forum SQA :

· Penyelesaian tim atau unit lokal masalah kualitas

· Mendeteksi deviasi dari prosedur kualitas dan instruksi

· Menginisialisasi perbaikan komponen SQA

· Pelaporan ke unit SQA tentang permasalahan kualitas di dalam tim atau unit

Issue utama dalam panitia :

· Solusi masalah kualitas PL

· Analisis masalah dan laporan kegagalan sebaik laporan lain, diikuti inisialisasi tindakan perbaikan dan pencegahan yang tepat

· Inisialisasi dan pembangunan prosedur baru, pelaksanaan dan perbaharuan bahan yang ada

· Inisialisasi dan pembangunan komponen SQA yang baru serta perbaikan komponen yang ada

Definisi pengujian perangkat lunak (PL) :

  • Menurut Myers (1979)

Proses menjalankan program dengan maksud menemukan kesalahan

  • Menurut IEEE (1990)

– Proses sistem operasi atau komponen menurut kondisi tertentu, pengamatan atau pencatatan hasil dan mengevaluasi beberapa aspek sistem atau komponen

– Proses analisis item PL untuk mendeteksi perbedaan antara kondisi yang ada dengan yang diinginkan dan mengevaluasi fitur item PL

  • Definisi lanjut

Proses formal yang ditentukan oleh tim pengujian yang meliputi unit PL, beberapa unit PL terintegrasi atau seluruh package PL yang ditentukan oleh program yang berjalan di komputer. Seluruh tes saling terkait dan adanya prosedur pengujian dan kasus pengujian.

Tujuan pengujian PL :

  • Tujuan langsung

– Identifikasi dan menemukan beberapa kesalahan yang mungkin ada dalam PL yang diuji

– Setelah PL dibetulkan, diidentifikasi lagi kesalahan dan dites ulang untuk menjamin kualitas level penerimaan

– Membentuk tes yang efisien dan efektif dengan anggaran dan jadwal yang terbatas

  • Tujuan tidak langsung

Mengumpulkan daftar kesalahan untuk digunakan dalam daftar pencegahan kesalahan (tindakancorrective dan preventive)

Strategi pengujian PL :

· Big bang testing : menguji PL keseluruhan, sekali untuk semua package yang ada

· Incremental testing : menguji PL per bagian dalam modul (unit testing), dilanjutkan dengan menguji integrasi tiap modul (integration test), selanjutnya seluruh package diuji (system testing)

Incremental testing :

Dibentuk dari dua dasar strategi :

  • Top-down

§ Modul pertama yang diuji : modul utama (tertinggi)

§ Modul terakhir yang diuji : modul pada level paling rendah

§ Keuntungan : memperlihatkan keseluruhan fungsi program (semua modul lengkap)

§ Kerugian : sulit menyiapkan potongan program dan menganalisis hasil tes

  • Bottom-up : kebalikan top-down

§ Keuntungan : relatif mendorong performance

§ Kerugian : menghambat program sebagai suatu keseluruhan modul

  • Keduanya menganggap package PL dibangun berdasarkan hirarki modul PL

Pengelompokan berdasarkan konsep pengujian :

· Black box (functionality) testing : mengidentifikasi kesalahan yang berhubungan dengan kesalahan fungsionalitas PL yang tampak dalam kesalahan output

· White box (structural) testing / glass box testing : memeriksa kalkulasi internal path untuk mengidentifikasi kesalahan

Definisi menurut IEEE :

  • Black box testing

Pengujian yang mengabaikan mekanisme internal sistem atau komponen dan fokus semata-mata pada output yang dihasilkan yang merespon input yang dipilih dan kondisi eksekusi

Pengujian yang dilakukan untuk mengevaluasi pemenuhan sistem atau komponen dengan kebutuhan fungsional tertentu

  • White box testing

Pengujian yang memegang perhitungan mekanisme internal sistem atau komponen

White box testing memiliki empat kategori :

Data processing and calculations correctness test : melakukan pengecekan data processing untuk setiap kasus tes

  • Pendekatan yang digunakan :

§ Path coverage : rencana tes yang mencakup semua kemungkinan path, di mana coveragediukur dengan berapa % path dicover

§ Line coverage : rencana tes yang mencakup semua baris kode program, di mana coveragediukur dengan berapa % line dicover

  • Correctness test & path coverage

§ Path yang berbeda dalam modul PL akan dibentuk oleh pilihan kondisional statementseperti IF-THEN-ELSE / DO WHILE / DO UNTIL.

§ Untuk full line coverage, tiap line dieksekusi min 1 kali selama proses pengujian, contoh : Imperial Taxi Service (ITS) taximeter ada 24 test case

  • Software qualification test
  • Maintainability test
  • Reusability test

Mc Cabe’s cyclomatic complexity metric (1976) :

· Tujuan : mengukur kompleksitas program atau modul pada waktu yang sama sebagai jumlah maksimumindependent path yang dibutuhkan untuk mencapai full line coverage pada program

· Dasar ukuran : teori graph dan dihitung berdasarkan kesesuaian sifat program yang dicapture oleh program flow graph

  • Independent path : setiap path pada program flow graph sedikitnya satu baris yang tidak dibentuk oleh independent path lain
  • Rumus : V(G) = R = E – N + 2 = P + 1
  • Keterangan :

V(G) = cyclometic complexity graph

R = jumlah region dalam program flow graph

E = jumlah edge

N = jumlah node

P = jumlah decision (percabangan)

  • Contoh kasus : Imperial Taxi Services (ITS) :

V(G) = R = 6

V(G) = E – N + 2 = 21 – 17 + 2 = 6

V(G) = P + 1 = 5 + 1 = 6

sumber : http://blog.its.ac.id/dyah03tc

2 responses to “Software Quality Management

  1. awan 14 April 2010 pukul 11:36 PM

    brooww., kalo komponen dan instrumen SQA apa aja..?
    suruh bikin makalah., tapi ga tau apa yang harus ditulis., bisa bantu..? thx b4

  2. zake 31 Oktober 2012 pukul 1:41 AM

    Nice gan..
    Dosen ane pakek referensi Daniel Galin, Software Quality Assurance. Tp sygnya bahasa inggris.
    Ini membantu ane belajar …
    Thanks

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: