JAMINAN KUALITAS PERANGKAT LUNAK (SQA)

Document Sample
JAMINAN KUALITAS PERANGKAT LUNAK (SQA) Powered By Docstoc
					IF0554 - REKAYASA PERANGKAT LUNAK                           1/7 - MODUL 10


       JAMINAN KUALITAS PERANGKAT LUNAK (SQA)
Pengantar
 Tujuan daripada perangkat lunak adalah untuk menghasilkan perangkat lunak
  berkualitas tinggi
 SQA merupakan aktivitas yang memayungi keseluruhan proses rekayasa
  perangkat lunak.
 Jaminan Kualitas merupakan aktivitas dasar untuk setiap bisnis yang
  menghasilkan produk untuk digunakan oleh pihak lain.
 Pertama kali diperkenalkan oleh Bell Labs ( 1916 )
 Tahun 1950-1960-an, jaminan kualitas merupakan tanggung jawab dari
  pemrograman.
 Bakuan SQA untuk kontrak militer dibuat 1970 lalu dipergunakan secara luas
  di dunia komerasial.
 Sekarang tanggung jawab SQA terdapat pada SE, PM, Custommer, Bagian
  Penjualan yang tergabung dalam SQA group.
 SQA group berfungsi sebagai representatif dari pembeli. Orang-orang dalam
  SQA group harus memandang perangkat lunak dengan kacamata pembeli.
  Dan memastikan apakah perangkat lunak sudah memenuhi faktor kualitas?
  Apakah perangkat lunak dikembangkan sesuai bakuan ?

Aktivitas SQA
 Penerapan motode teknis             Penggunaan Bakuan
 Review / inspeksi                   Pengukuran
 Pengujian Perangkat Lunak           Pengontrolan Perubahan
 Pengumpulan Data ( Pelapor )


 Dimulai dengan penggunaan metode teknis dan alat bantu untuk analis
  (menghasilkan spesifikasi berkualitas) dan perancang ( menghasilkan
  rancangan berkualitas )
 Setelah spesifikasi dan rancangan dibuat dilakukan formal technical review
  (FTR) u/ menyingkap masalah-masalah kualitas.
 Selama/setelah produk dibuat dilakukan pengujian perangakat lunak.
 Pengkajian terhadap penerapan bakuan dan prosedur dapat dilakukan
  sebagai bagian dari FTR.
 Perubahan dapat mengakibatkan error yang lain. Untuk itu perlu dilakukan
  kontrol terhadap perubahan ( bagian dari SCM )
 Pengukuran merupakan aktivitas yang mencakup keseluruhan proses
  rekayasa. Data-data sehubungan dengan software metrics perlu dikumpulkan
 Data-data mengenai hasil setiap aktivitas SQA perlu dikumpulkan sebagai
  catatan sejarah proyek.




Versi 1.0                   STIMIK PERBANAS                      Maret 2003
IF0554 - REKAYASA PERANGKAT LUNAK                                             2/7 - MODUL 10


Beberapa hal Pokok
 Kebutuhan perangkat lunak merupakan pondasi pengkuran kualitas.
  Kekurangan dalam hal pemenuhan kebutuhan berarti kekurangan dalam hal
  kualitas.
 Perlu bakuan yang mendefinisikan sekumpulan kriteria pengembangan yang
  menjadi petunjuk bagaimana perangkat lunak direkayasa. Jika kriteria tidak
  diikuti, perangkat lunak yang dihasilkan cenderung tidak bermutu.

Faktor dan Ukuran Kualitas Perangkat Lunak ( McCall )
 Berfokus pada tiga hal pokok :
    Karakteristik operasional
    kemampuan mengatasi perubahan
    Kemampuan beradaptasi pada lingkungan baru




 Maintainability (Can I fix it?)                          Portability (Will I be able to use it on
 Flexibility     (Can I change it?)                                    another machine?)
 Testability     (Can I tes it?)                          Reusability (Will I be able to reuse
                                                                       some of the software?)
                                                          Interoperability (Will I be able to Inter-
                                                                     face it with another system?)


                                  Product
                                 Revision          Product
                                                   Transition



                                       Product
                                       Operation



             Correctness     (Does it do what I want?)
             Reliability     (Does it do it accurately all of the time?)
             Efficiency      (Will it run on my harware as well as it can?)
             Integrity       (Is it secure?)
             Usability       (Is it designed for the user?)




Versi 1.0                             STIMIK PERBANAS                                Maret 2003
IF0554 - REKAYASA PERANGKAT LUNAK                                    3/7 - MODUL 10



                                Software




                                                                     Interoperability
                                               Maintanibility
                              Quality Metric




                                               Correctness




                                                                     Reusability
                                                                     Testability
                                                                     Portability
                                               Efficiency
                                               Reliability
       No




                                               Flexibility




                                                                     Usability
                                               Integrity
               Quality
               Factor

        1   Audibility                                     V         V
        2   Accuracy                               V
        3   Communication Commonality                                          V
        4   Completeness                       V
        5   Complexity                             V             V V
        6   Concision                                V         V V
        7   Consistency                            V V         V V
        8   Data Commonality                                                   V
        9   Error Tolerance                        V
       10   Executuin Efficiency                       V
       11   Expandability                                        V
       12   Generality                                           V       V V V
       13   Hardware Independency                                        V V
       14   Instrumentation                                V V       V
       15   Modularity                             V           V V V V V V
       16   Operability                                V                           V
       17   Security                                       V
       18   Self Documentation                                 V V V V V
       19   Simplicity                             V           V V V
       20   System Independency                                          V V
       21   Traceability                       V
       22   Trainning                                                              V


Karakteristik Operasional
 CORRECTNESS ukuran apakah perangkat lunak yang dihasilkan memenuhi
   spesifikasi yang diharuskan dan maksud/tujuan pemakai.
 RELIABILITY ukuran yang menyatakan nilai kemungkinan suatu program
   bekerja dengan baik menurut spesifikasi yang dipersyaratkan dalam kurun
   waktu tertentu




Versi 1.0                      STIMIK PERBANAS                           Maret 2003
IF0554 - REKAYASA PERANGKAT LUNAK                            4/7 - MODUL 10


 EFFICIENCY ukuran yang menyatakan banyaknya sumber daya yang
  diperlukan untuk proses komputasi dan instruksi yang terdapat pada program
  untuk menjalankan suatu fungsi tertentu.
 INTEGRITY ukuran yang manyatakan sejauh mana pemakai atau akses dari
  pemakai yang tidak berwenang terhadap program dan data dapat
  dikendalikan.
 USABILITY ukuran sejauh mana usaha yang diperlukan untuk mempelajari
  mengoperasikan, menyiapkan data masukan dan menginterprestasikan
  keluaran suatu program.

Karakteristik Kamampuan terhadap Perubahan
 MAINTAINABILITY : usaha yang diperlukan untuk mencari dan menemukan
   kesalahan program serta memperbaikinya.
 FLEXIBILITY : usaha yang diperlukan untuk memodifikasi program yang telah
   jadi atau telah jalan.
 TESTABILITY : usaha yang diperlukan untuk menguji suatu program, apakah
   sesuai dengan fungsi yang diharapkan/dipersyaratkan.

Karakteristik Kamampuan Beradaptasi
 PORTABILITY : usaha yang diperlukan untuk mentransfer suatu program dari
   satu perangkat keras dan/atau perangkat lunak ke lainnya.
 REUSABILITY : tolok ukur yang menggambarkan seberapa banyak bagian
   dari program dapat dipergunakan kembali pada program yang lainnya.
 INTEROPERABILITY : usaha yang diperlukan untuk menghubungkan suatu
   program dengan sistem komputer/program lain.

Pengukuran Faktor Kualitas
 Sukar untuk mengukur faktor-faktor di atas secara langsung. Perlu disusun
  sekumpulan ukuran yang membentuk ekspresi terhadap masing-masing
  faktor sbb :

              Fq = c1 * m1 + c2 * m2 + ……. + cn * mn

    Fq = faktor kualitas perangkat lunak
    cn = koefisien regresi
    mn = ukuran yang berpengaruh terhadap faktor kualitas.
    Penilaian dilakukan subyektif dengan memberi angka antara 0 sampai 10.
    Correctnees = F ( completeness, consistenscy. Traceability )
    Efficiency = F ( concision , execution efficiency. Operability )

Ukuran yang mempengaruhi Faktor Kualitas
1. AUDITABILITY : Tingkat kemudahan untuk memeriksa apakah perangkat
   lunak yang dikembangkan memenuhi pembakuan yang diperyaratkan.
2. ACCURACY : tingkat keakuratan dari proses komputasi dan kendali.




Versi 1.0                   STIMIK PERBANAS                       Maret 2003
IF0554 - REKAYASA PERANGKAT LUNAK                            5/7 - MODUL 10


3. COMUNICATION         COMMONALITY           :   tingkat kemampuan     untuk
    mempergunakan antar muka dan protokol komunikasi yang baku.
4. COMPLETENESS : sejauh mana tingkat pencapaian implementasi dari
    fungsi yang dibutuhkan.
5. COMPLEXITY : Kompleksitas algoritma
6. CONCISION : Keringkasan, banyak sedikitnya baris program, modul, dll.
7. CONSISTENCY : tingkat penggunaan teknik perancangan dan dokumentasi
    yang seragam dalam mengembangkan perangkat lunak.
8. DATA COMMONALITY : tingkat penggunaan struktur dan tipe data yang
    baku di dalam program.
9. ERROR TOLERANCE : tingkat kerusakan yang timbul bila program
    memenuhi kesalahan.
10. EXECUTION EFFICIENCY : kinerja program pada saat berjalan.
11. EXPANDABILITY : tingkat pengembangan rancangan arsitektur, data dan
    prosedur dari perangkat lunak.
12. GENERALITY : luasnya kemungkinan penerapan bagian-bagian dan program
    pada program yang lainnya.
13. HARDWARE INDEPENDENCE : tingkat kemandirian program terhadap
    perangkat lunak dimana program tersebut dijalankan.
14. INTRUMENTATION : tingkat kemampuan program untuk mengendalikan dan
    mengenali kesalahan yang timbul dalam menoperasikan program tersebut.
15. MODULARITY : sejauh mana komponen setiap program dapat mandiri ( tidak
    bergantung satu dengan yang lainya )
16. OPERABILITY : tingkat kemudahan untuk mengoperasikan program.
17. SECURITY : tingkat ketersediaannya mekanisme untuk mengendalikan dan
    melindungi program dan data.
18. SELF DOCUMENTATION : ukuran yang mengembangkan seberapa jauh
    dokumentasi program sumber memberikan arti jelas.
19. SIMPLICITY : seberapa jauh suatu program dapat dimengerti tanpa
    memperoleh kesukaran.
20. SOFTWARE SYSTEM INDEPENDENCE : seberapa jauh suatu program
    tidak bergantung pada karakteristik sistem oprasi.
21. TRACEABILITY : tingkat kemungkinan untuk menelusuri kembali rancangan
    program atau komponen program sampai ke rincian spesifikasi atau
    kebutuhan perangkat lunak, yang telah ditentukan sebelumnya.
22. TRAINING : sejauh mana perangkat lunak dapat membimbing pemakai untuk
    menggunakan perangkat lunak itu sendiri. Bimbingan yang diberikan
    misalnya berupa : menu pilihan, petunjuk singkat pengoperasian dll.

Software Review
 Review diterapkan pada beberapa titik dalam pengembangan perangkat
   lunak dan dilakukan untuk mencari defect (kesalahan).

Penguatan dan Penghilangan Cacat (Defect Amplification)
Digunakan untuk mendeteksi kesalahan pada tahap rancangan preliminary,
rancangan detail, dan coding.



Versi 1.0                   STIMIK PERBANAS                       Maret 2003
  IF0554 - REKAYASA PERANGKAT LUNAK                                           6/7 - MODUL 10



                              Langkah Pengembangan
                           Cacat             Deteksi
                              Kesalahan yg
 Kesalahan                    terlewatkan                   Persen                Kesalahan yg
dari langkah                                               efisiensi              dilewatkan ke
sebelumnya              Kesalahan diperkuat 1 : x                                     langkah
                                                         untuk deteksi
                                                          kesalahan                 berikutnya
                            Kesalahan baru
                              dihasilkan
                       Gambar 10.1. Defect Amplification Model

  Contoh :
  Pada gambar 10.2. dan 10.3, suatu kasus dengan asumsi bahwa setiap tahap
  pengujian ditemukan 50% kesalahan kemudian dibetulkan. Gambar 10.3, untuk
  kajian ulang tidak dilakukan, dengan sepuluh kesalahan pada tahap desain awal
  kemudian diperkuat samapi 94 kesalahan sebelum pengujian dimulai, akhirnya
  setelah melalui tahap pengujian dilepas 12 kesalahan laten ke lapangan.
  Sedangkan pada gambar 10.2, jika kajian ulang dilakukan, maka dengan 3
  kesalahan pada desain awal kemudian diperkuat menjadi 24 kesalahan sebelum
  pengujian, akhirnya hanya 3 kesalahan laten yang dilepas ke lapangan. Di
  samping itu kesalahan yang ditemui pada setiap tahap pengujian juga semakin
  sedikit, hal ini tentu saja mengurangan waktu dan biaya pembetulan kesalahan.

               0                              Detail design
                              3        2
               0        70%                     2                         Code / unit test
                                   1                           15     5
               10                            1 . 1,5     50%                10
                                                                     10                      24
                                               25                          10.3        60%
                                                                             25

     24       Integration test
                                                                                     Ke integrasi
                                               Validation test
                                  12
                   0      50%                                               System test
                   0                                             6
                                                    0     50%
                                                                                              3
                                                    0                         0         50%

                                                                              0

                                                                                        Kesalahan
                                                                                        laten
              Gambar 10.2. Defect Amplification (dilakukan kajian ulang)



  Versi 1.0                                STIMIK PERBANAS                           Maret 2003
 IF0554 - REKAYASA PERANGKAT LUNAK                                      7/7 - MODUL 10


      Preliminary design
             0                            Detail design
                          10       6
             0      0%                       6                   Code/unit test
                               4          4 x 1.5          37
             10                           x = 1.5
                                                     0%             10
                                                                   27 x 3            94
                                            25                     x=3         20%

94    Integration test                                              25

                                        Validation test                     Ke integrasi
                          47
             0      50%                                           System test
             0                                             24
                                            0        50%
                                                                                     12
                                            0                       0          50%
       Preliminary design
                                                                    0

                                                                            Kesalahan
                                                                            laten
      Gambar 10.3. Defect Amplification (tanpa dilakukan kajian ulang)


 Keuntungan Software Review
  Defect dapat ditemukan dan dikoreksi sebelum masuk ke tahapan berikutnya.
  Aktivitas perancangan memberikan 50-65% dari keseluruhan defect dalam
   pengembangan perangkat lunak.
  Teknik FTR 75 % efektif untuk menyingkap kesalahan yang terjadi. Dan ini
   dapat menghemat banyak biaya

 Justifikasi Software Review
  Untuk melakukan review, memerlukan waktu, usaha dari biaya. Tetapi
    dengan mengadakan review dapat menghemat biaya.

 SQA Standards
  DOD-STD-2167A               : Software Engineering
  DOD-STD-2168                : Software quality evaluation standard
  FAA-STD-O18                 : SQA standard for the FAA
  IEEE Std. 730-1984          : SQA plans
  IEEE Std. 983-1986          : SQA planning
  IEEE Std. 1028-1088         : Software review and audits
  IEEE Stf. 1012-1986         : Software verification and validation plans.




 Versi 1.0                             STIMIK PERBANAS                      Maret 2003

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:37
posted:11/5/2012
language:Indonesian
pages:7